wayland drivers when?

Post Reply
miskol
Posts: 244
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 0
Been thanked: 12 times
Contact:

wayland drivers when?

Post by miskol » Thu Mar 14, 2019 4:33 pm

I know there is plan to release wayland drivers.
Are there any estimations? :)

GNOME 3.32 is out, Ubutu 19.04 is coming :)

User avatar
tobetter
Posts: 5080
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Has thanked: 159 times
Been thanked: 485 times
Contact:

Re: wayland drivers when?

Post by tobetter » Thu Mar 14, 2019 4:45 pm

miskol wrote:
Thu Mar 14, 2019 4:33 pm
I know there is plan to release wayland drivers.
Are there any estimations? :)

GNOME 3.32 is out, Ubutu 19.04 is coming :)
We are trying to get working Wayland, but still far away to be.
Since the kernel AMLogic is based on Android platform basically, we would need to change a lot...
Anyway, we are working on it.

miskol
Posts: 244
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 0
Been thanked: 12 times
Contact:

Re: wayland drivers when?

Post by miskol » Thu Mar 14, 2019 9:49 pm

I would like to try mainline kernel
so is it possible to release userspace library ?
as userspace library should be hw independent I think :)

User avatar
odroid
Site Admin
Posts: 34141
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 675 times
Been thanked: 614 times
Contact:

Re: wayland drivers when?

Post by odroid » Mon Mar 18, 2019 10:23 am

@miskol,

Have you tested any DRM/HDMI drivers with the mainline kernel on N2?
If it works stably, it will be a nice path to run the Wayland sooner.

miskol
Posts: 244
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 0
Been thanked: 12 times
Contact:

Re: wayland drivers when?

Post by miskol » Tue Mar 19, 2019 7:10 pm

@odroid
Are there any chance that ARM has big OpenGL drivers?
As base on this
https://en.wikipedia.org/wiki/Mali_(GPU)
They should support DirectX 11 so it is more than OpenGL 4 I think :)

I never ever found any article about this but as you probably have contact on ARM support maybe you can ask for that :)

User avatar
odroid
Site Admin
Posts: 34141
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 675 times
Been thanked: 614 times
Contact:

Re: wayland drivers when?

Post by odroid » Wed Mar 20, 2019 8:19 am

As far as I know, ARM has no plan to support normal OpenGL.
I think Panfrost seems to have much higher possibility.

But Panfrost also need a DRM HDMI driver.
So I hope some people can build & test it on N2.

miskol
Posts: 244
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 0
Been thanked: 12 times
Contact:

Re: wayland drivers when?

Post by miskol » Wed Mar 27, 2019 11:19 pm

wayland drivers
User-land Mali-G52 Wayland driver has been uploaded. Version number is r16p0.
https://dn.odroid.com/S922X/ODROID-N2/Wayland/

kernel part
https://github.com/superna9999/meson_g12a_mali_bifrost

elatllat
Posts: 1747
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2, C4
Has thanked: 44 times
Been thanked: 112 times
Contact:

Re: wayland drivers when?

Post by elatllat » Mon Apr 08, 2019 11:02 am


mxmilkb
Posts: 64
Joined: Fri Apr 26, 2019 9:28 am
languages_spoken: English
ODROIDs: N2
Has thanked: 23 times
Been thanked: 21 times
Contact:

Re: wayland drivers when?

Post by mxmilkb » Thu May 02, 2019 4:21 pm

Looking forward to running sway wayland compositor on the N2.
Last edited by mxmilkb on Sun May 05, 2019 4:41 pm, edited 2 times in total.

wallyz21
Posts: 137
Joined: Thu Apr 04, 2019 11:00 am
languages_spoken: english
ODROIDs: N2
Has thanked: 10 times
Been thanked: 16 times
Contact:

Re: wayland drivers when?

Post by wallyz21 » Thu May 02, 2019 4:55 pm

miskol wrote:
Wed Mar 27, 2019 11:19 pm
wayland drivers
User-land Mali-G52 Wayland driver has been uploaded. Version number is r16p0.
https://dn.odroid.com/S922X/ODROID-N2/Wayland/

kernel part
https://github.com/superna9999/meson_g12a_mali_bifrost
Is the combination of these user-land and kernel components adequate to run the desktop environment?
Walter Zambotti
N2 - Ubuntu Mate Desktop

brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Fri May 03, 2019 3:48 pm

wallyz21 wrote:
Thu May 02, 2019 4:55 pm
miskol wrote:
Wed Mar 27, 2019 11:19 pm
wayland drivers
User-land Mali-G52 Wayland driver has been uploaded. Version number is r16p0.
https://dn.odroid.com/S922X/ODROID-N2/Wayland/

kernel part
https://github.com/superna9999/meson_g12a_mali_bifrost
Is the combination of these user-land and kernel components adequate to run the desktop environment?
In wayland mode with some minor modifications to code such as gnome. X11 is not supported directly - only with wayland conversions. Once mainline kernel 5.2 is released we should see some more good progress.

Toggleton
Posts: 5
Joined: Mon May 27, 2019 5:39 pm
languages_spoken: english
ODROIDs: c2, N2
Has thanked: 1 time
Been thanked: 3 times
Contact:

Re: wayland drivers when?

Post by Toggleton » Sun Dec 15, 2019 5:41 am

Is there a Update for the Wayland Driver planed?
Since 2019-03-28 was there no Update to that Files
https://dn.odroid.com/S922X/ODROID-N2/Wayland/

I use it at the Moment with Sway on Archlinuxarm with Mainline Kernel. It works nice but the CPU usage is a little bit high :| That's why i hope that there is a Update

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Tue Jan 28, 2020 3:22 pm

Hi to everyone! So I got my new Odroid N2 Just today on the mailbox (was really excited :D), installed ArchLinuxARM, the linux-aarch64-rc kernel which is at version 5.5.0-rc7-1 and now I'm trying to get these wayland libraries working with no success so far...
Toggleton wrote:
Sun Dec 15, 2019 5:41 am
...
https://dn.odroid.com/S922X/ODROID-N2/Wayland/

I use it at the Moment with Sway on Archlinuxarm with Mainline Kernel.
...
Can you detail how you setup that on archlinux for it to work? I wrote a basic PKGBUILD to install the provided mali/wayland libraries on ArchLinuxARM but I'm running out of luck... Here is what I did:

The PKGBUILD:

Code: Select all

pkgname=odroid-n2-wayland
pkgver=r16p0
pkgrel=1
pkgdesc="Wayland driver for Odroid N2."
arch=('aarch64')
url="https://dn.odroid.com/S922X/ODROID-N2/Wayland"
license=('UNKNOWN')
depends=()
provides=()
conflicts=(
  "mali-utgard-meson-libgl-fb"
  "mali-utgard-meson-libgl-x11"
  "odroid-c2-libgl-fb"
  "odroid-c2-libgl-x11"
)
source=(
  "mali-n2.conf"
  "https://dn.odroid.com/S922X/ODROID-N2/Wayland/wayland-drm_arm64.tar.gz"
)
md5sums=(
  '40f5104200cfceb12b4623d219646d4e'
  'SKIP'
)

package() {
  install -d $pkgdir/etc/ld.so.conf.d
  install -d $pkgdir/usr/lib/mali-egl

  cp -a wayland-drm_arm64/r16p0/wayland/drm/* $pkgdir/usr/lib/mali-egl/
  cp mali-n2.conf $pkgdir/etc/ld.so.conf.d/
}
The mali-n2.conf contents:

Code: Select all

/usr/lib/mali-egl
When I run sway I get:

Code: Select all

sway: symbol lookup error: /usr/lib/libwlroots.so.5: undefined symbol: gbm_bo_get_offset
and ldd /usr/lib/libwlroots.so.5 gives me:

Code: Select all

linux-vdso.so.1 (0x0000ffff8aa74000)
libwayland-server.so.0 => /usr/lib/libwayland-server.so.0 (0x0000ffff8a946000)
libwayland-client.so.0 => /usr/lib/libwayland-client.so.0 (0x0000ffff8a926000)
libwayland-egl.so.1 => /usr/lib/mali-egl/libwayland-egl.so.1 (0x0000ffff8a915000)
libEGL.so.1 => /usr/lib/mali-egl/libEGL.so.1 (0x0000ffff8a904000)
libGLESv2.so.2 => /usr/lib/mali-egl/libGLESv2.so.2 (0x0000ffff8a8f3000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0x0000ffff8a8cf000)
libgbm.so.1 => /usr/lib/mali-egl/libgbm.so.1 (0x0000ffff8a8be000)
libinput.so.10 => /usr/lib/libinput.so.10 (0x0000ffff8a863000)
libxkbcommon.so.0 => /usr/lib/libxkbcommon.so.0 (0x0000ffff8a810000)
libudev.so.1 => /usr/lib/libudev.so.1 (0x0000ffff8a7c9000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x0000ffff8a756000)
libm.so.6 => /usr/lib/libm.so.6 (0x0000ffff8a6aa000)
librt.so.1 => /usr/lib/librt.so.1 (0x0000ffff8a692000)
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x0000ffff8a680000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x0000ffff8a52c000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x0000ffff8a4f3000)
libxcb-xinput.so.0 => /usr/lib/libxcb-xinput.so.0 (0x0000ffff8a4bf000)
libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0x0000ffff8a4a6000)
libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x0000ffff8a3c8000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x0000ffff8a3b1000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000ffff8a381000)
libxcb-composite.so.0 => /usr/lib/libxcb-composite.so.0 (0x0000ffff8a36d000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x0000ffff8a34f000)
libxcb-errors.so.0 => /usr/lib/libxcb-errors.so.0 (0x0000ffff8a335000)
libxcb-icccm.so.4 => /usr/lib/libxcb-icccm.so.4 (0x0000ffff8a320000)
libc.so.6 => /usr/lib/libc.so.6 (0x0000ffff8a1b3000)
/usr/lib/ld-linux-aarch64.so.1 (0x0000ffff8aa46000)
libffi.so.6 => /usr/lib/libffi.so.6 (0x0000ffff8a19a000)
libmali.so.0 => /usr/lib/mali-egl/libmali.so.0 (0x0000ffff88fe5000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x0000ffff88fd1000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0000ffff88dc7000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000ffff88da3000)
libmtdev.so.1 => /usr/lib/libmtdev.so.1 (0x0000ffff88d8d000)
libevdev.so.2 => /usr/lib/libevdev.so.2 (0x0000ffff88d61000)
libwacom.so.2 => /usr/lib/libwacom.so.2 (0x0000ffff88d45000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x0000ffff88d31000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x0000ffff88d1b000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x0000ffff88ce5000)
liblz4.so.1 => /usr/lib/liblz4.so.1 (0x0000ffff88cb6000)
libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x0000ffff88bd9000)
libgudev-1.0.so.0 => /usr/lib/libgudev-1.0.so.0 (0x0000ffff88bbd000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x0000ffff88b45000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0000ffff889f1000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x0000ffff889be000)
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x0000ffff8894a000)
I would love to get some video hardware acceleration thru wayland, but I don't even know what I'm doing wrong or what is needed...

Payano
Posts: 17
Joined: Sat Mar 02, 2019 8:57 pm
languages_spoken: english
ODROIDs: XU4
N2
Has thanked: 9 times
Been thanked: 3 times
Contact:

Re: wayland drivers when?

Post by Payano » Tue Jan 28, 2020 5:38 pm

Hello jgmdev,

I think you need the libgbm-compat library, i unpacked the .deb file and found this:

Code: Select all

readelf -s libgbm-compat.so | grep gbm_bo_get_offset
13: 000005d1     4 FUNC    GLOBAL DEFAULT   11 gbm_bo_get_offset
I found the debian package in tobetter's repository: http://ppa.linuxfactory.or.kr/pool/main ... bm-compat/

Hope this helps.

/J
These users thanked the author Payano for the post:
jgmdev (Wed Jan 29, 2020 3:52 am)

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Tue Jan 28, 2020 6:56 pm

Thanks for the info! I downloaded the latest .deb file, extracted the libgbm-compat.so file and placed it on a directory, then added it to /etc/ld.so.preload but now I'm getting:

Code: Select all

[sway/server.c.47] Unable to create backendDRM deviceerererer
Tried to compile sway (and even wayfire) from git, but when the build is linking against libwlroot.so got undefined symbols again even with /etc/ld.so.preload including a line to the full path of libgbm-compat.so... seems I'm doing something wrong...

User avatar
mad_ady
Posts: 7909
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 502 times
Been thanked: 350 times
Contact:

Re: wayland drivers when?

Post by mad_ady » Tue Jan 28, 2020 8:11 pm

tobetter is providing an image with working wayland and gnome3, but I don't have the link handy. Search the forum a bit for it.

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Tue Jan 28, 2020 9:01 pm

I don't want to switch to Ubuntu, would rather like to know which stuff is needed to make it work so I can port the changes to archlinux. I prefer a rolling release distro which always has up to date software. Also, is easier to package software on ArchLinux when I need to.

I saw on the "mainline linux support" thread (page 11 IIRC), some user space meson dkms driver and the wayland libraries packages for ubuntu, will try to download them and see if repackaging is possible. But, an article detailing everything that is needed to get working wayland acceleration would be nice for people using other distros, maybe on the Other OS subtopic...

mxmilkb
Posts: 64
Joined: Fri Apr 26, 2019 9:28 am
languages_spoken: English
ODROIDs: N2
Has thanked: 23 times
Been thanked: 21 times
Contact:

Re: wayland drivers when?

Post by mxmilkb » Tue Jan 28, 2020 11:17 pm

jgmdev wrote:
Tue Jan 28, 2020 3:22 pm
Here is what I did:
FWIW, here is my wayland-mali and mesa-git-mali PKGBUILDs from this thread.
These users thanked the author mxmilkb for the post (total 2):
tobetter (Wed Jan 29, 2020 12:25 am) • jgmdev (Wed Jan 29, 2020 3:49 am)

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Wed Jan 29, 2020 6:04 am

Using /etc/ld.so.conf.d/ to overwrite existing libraries seems cleaner, but the positive about replacing the entire package is that it should fix the issue when compiling software. Now that I think, maybe one can use environment variables to overwrite default shared libraries path for compiler, (some searching later...) and yes as documented here: https://homepages.inf.ed.ac.uk/imurray2 ... inking.txt (at least for gcc)

To override shared libraries path:
export LIBRARY_PATH="/location/one:/location/two"

To override headers path:
export CPATH="/location/one:/location/two"

But when doing LD_PRELOAD (in the case of libgbm-compat which provides additional functionality) and compiling projects that don't directly link the to loaded libraries one would get undefined symbols... no idea how to fix that issue, maybe by exporting some LDFLAGS, but not all build systems support it I think...

I also saw here viewtopic.php?f=176&t=33993&start=500#p275725 the mali-bifrost-dkms package for ubuntu which I'm not sure how much needed it is with git version of mesa. I don't know anything about how the graphics stack works :( I'm trying to understand it in order to enable the accelerated graphics...

Also, I'm not sure if beside all the libraries above special user permissions are needed for video access.

brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Wed Jan 29, 2020 8:45 pm

jgmdev wrote:
Wed Jan 29, 2020 6:04 am
Using /etc/ld.so.conf.d/ to overwrite existing libraries seems cleaner, but the positive about replacing the entire package is that it should fix the issue when compiling software. Now that I think, maybe one can use environment variables to overwrite default shared libraries path for compiler, (some searching later...) and yes as documented here: https://homepages.inf.ed.ac.uk/imurray2 ... inking.txt (at least for gcc)

To override shared libraries path:
export LIBRARY_PATH="/location/one:/location/two"

To override headers path:
export CPATH="/location/one:/location/two"

But when doing LD_PRELOAD (in the case of libgbm-compat which provides additional functionality) and compiling projects that don't directly link the to loaded libraries one would get undefined symbols... no idea how to fix that issue, maybe by exporting some LDFLAGS, but not all build systems support it I think...

I also saw here viewtopic.php?f=176&t=33993&start=500#p275725 the mali-bifrost-dkms package for ubuntu which I'm not sure how much needed it is with git version of mesa. I don't know anything about how the graphics stack works :( I'm trying to understand it in order to enable the accelerated graphics...

Also, I'm not sure if beside all the libraries above special user permissions are needed for video access.
From my somewhat limited understanding it seems a dependency / configuration nightmare for a distribution. @tobetter made his repo / packages work very well in the Ubuntu way using dkms to recompile the kernel module when a different "kernel" is installed and also install the the mali userspace shared libraries (binary only) and install of @memeka gbm-compat shared library for compatibility.

- Firstly the dkms package, it handles the kernel side module build and install on demand when a kernel is being updated in the Ubuntu way. The mali kernel driver is not part of the actual mainline kernel source, it is built / compiled separate and on demand using dkms when a new kernel is installed to Ubuntu. This module needs to be compiled from source each time against the "exact" kernel being installed and dkms does this by using the same kernel's header packages. If mali kernel side is installed it should show up as "kbase_mali" using a lsmod however way it was compiled and installed.

- The mali userspace wayland binary drivers - we don't have source or headers so this is binary only based on amlogic / arm implementation. It is a vendor proprietary implementation of the egl standard https://www.khronos.org/egl so instead you can theoretically use normal mesa egl.h (Ubuntu libegl-dev?) to compile against instead. In Ubuntu repo's packages are compiled against mesa / libegl's version of egl.h so here it is wise to stick to the standard for the distro which other packages are compiled / developed against.

- gbm-compat this is @memeka compatibility library designed to work in conjunction with mali userspace binary drivers. It is preloaded at runtime before other libraries (including mali binaries) using LD_PRELOAD and allows some additional very simple objects to be defined at runtime to bring it compatible with current egl mesa standard. The way I understand it gbm-compat is not designed to be linked in with the ld system cache its only designed to be preloaded before it.
These users thanked the author brad for the post:
jgmdev (Thu Jan 30, 2020 4:08 am)

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 58 times
Contact:

Re: wayland drivers when?

Post by memeka » Wed Jan 29, 2020 9:11 pm

Regarding gbm compat:
I use Mesa headers to compile, which have the functions in gbm-compat defined. They are missing from vendor libgbm which is actually libmali - so it’s a runtime error (function not found). By preloading the .so you now have the functions defined :)

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Thu Jan 30, 2020 8:40 am

First of all thanks for sharing the information!
brad wrote:
Wed Jan 29, 2020 8:45 pm
The mali kernel driver is not part of the actual mainline kernel source.
Is this the case for the 4.9 kernel distributed by hardkernel? I tried to modprobe kbase_mali on that kernel but it wasn't found. These are all the references of mali I saw on the kernel modules directory:

Code: Select all

./include/config/mali
./drivers/gpu/arm/midgard/tests/mali_kutf_irq_test
./drivers/gpu/drm/bifrost/midgard/tests/mali_kutf_irq_test
Also tried to compile the dkms debian package under the 4.9 kernel using the dkms.conf make flags as follows but it failed:

Code: Select all

make SCONS_CFLAGS='\
-DCONFIG_MALI_MIDGARD=m \
-DCONFIG_MALI_DEVFREQ=y \
-DCONFIG_MALI_PLATFORM_NAME=meson \
-DCONFIG_MALI_PLATFORM_POWER_DOWN_ONLY=y' \
CONFIG_MALI_MIDGARD=m \
CONFIG_MALI_DEVFREQ=y \
CONFIG_MALI_PLATFORM_NAME=meson \
CONFIG_MALI_PLATFORM_POWER_DOWN_ONLY=y
The error message was (maybe related to sources been updated to 5.x kernels) :

Code: Select all

mali-bifrost-16.0/mali_kbase_mem_linux.c:1771:9: error: implicit declaration of function ‘vmf_insert_pfn’; did you mean ‘vm_insert_pfn’? [-Werror=implicit-function-declaration]
 1771 |   ret = vmf_insert_pfn(vma, addr << PAGE_SHIFT,
      |         ^~~~~~~~~~~~~~
      |         vm_insert_pfn
cc1: some warnings being treated as errors
I had to revert to the 4.9 kernel because when using petitboot I got a lower resolution than supported by my AOC display when booting with 5.5 kernel :( Also I got a wifi adapter from ameridroid (rtl8812au) that worked fine on the 4.9 kernel but seems to have been disabled on newer 5.x kernels so I also had to use the dkms strategy to get it working again:

PKGBUILD:

Code: Select all

pkgname=rtl8812au-dkms-gnab-git
_pkgbase=rtl8812au
pkgver=4.2.2.r130.g40eafac
pkgrel=1
pkgdesc="rtl8812AU chipset driver fixed for 5.x.x kernels"
arch=('i686' 'x86_64' 'aarch64')
url="https://github.com/gnab/rtl8812au"
license=('GPL2')
depends=('dkms' 'bc')
makedepends=('git')
conflicts=("${_pkgbase}" "${_pkgbase}-dkms-git")
source=("git+https://github.com/gnab/rtl8812au.git"
  'dkms.conf'
)
sha256sums=('SKIP'
	    'SKIP')

pkgver() {
  cd ${srcdir}/rtl8812au
  printf '%s.r%s.g%s' '4.2.2' "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

package() {
  cd ${srcdir}/rtl8812au
  mkdir -p ${pkgdir}/usr/src/${_pkgbase}-${pkgver}
  cp -pr * ${pkgdir}/usr/src/${_pkgbase}-${pkgver}
  cp ${srcdir}/dkms.conf ${pkgdir}/usr/src/${_pkgbase}-${pkgver}
  # Set name and version
  sed -e "s/@_PKGBASE@/${_pkgbase}-dkms/" \
    -e "s/@PKGVER@/${pkgver}/" \
    -i "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/dkms.conf
}
dkms.conf:

Code: Select all

PACKAGE_NAME="@PKGBASE@"
PACKAGE_VERSION="@PKGVER@"
BUILT_MODULE_NAME="8812au"
PROCS_NUM=$(nproc)
[ $PROCS_NUM -gt 16 ] && PROCS_NUM=16
MAKE="'make' ARCH=arm64 -j$PROCS_NUM KVER=${kernelver} 
KSRC=/lib/modules/${kernelver}/build"
CLEAN="'make' clean"
DEST_MODULE_LOCATION="/kernel/drivers/net/wireless"
AUTOINSTALL="yes"
REMAKE_INITRD=no
brad wrote:
Wed Jan 29, 2020 8:45 pm
- The mali userspace wayland binary drivers - we don't have source or headers so this is binary only based on amlogic / arm implementation.
So basically libmali implements all EGL/Wayland graphic functionality as was seen by all the symbolic links to it. I also saw symbolic links to some kind of placeholder library for vulkan. Using the new learned command readelf -s libmali.so I dont see any references to vulkan on libmali. Is there vulkan support? Seems like some of the android images have vulkan in place, does that library also works on a regular linux install? I read some time ago about Zink which is a mesa gallium driver that implements opengl in top of vulkan, if we can run vulkan from a regular linux install I guess that one could use this project to get accelerated Xserver support on the Odroid N2 without an X driver...
brad wrote:
Wed Jan 29, 2020 8:45 pm
- gbm-compat this is @memeka compatibility library designed to work in conjunction with mali userspace binary drivers.
I was able to almost run applications with gbm-compat (seems I'm missing the bifrost kernel driver to fully run them), but when compiling wlroots, even if it compiles well, it links to a version of libgbm that is missing funcitonality, when another applicaiton (in this case sway) links to wlroots it complains about missing symbols at compile time. Not sure how to fix that...

I think I'm understanding at least 0.1% of how this stuff works :)

mxmilkb
Posts: 64
Joined: Fri Apr 26, 2019 9:28 am
languages_spoken: English
ODROIDs: N2
Has thanked: 23 times
Been thanked: 21 times
Contact:

Re: wayland drivers when?

Post by mxmilkb » Thu Jan 30, 2020 9:49 am

If the existing driver is a blob, what exactly would/does dkms rebuild on each new kernel installation?

I had made the assumption previously that it wasn't worth trying the older blob driver with the new kernel, but tobetter's posts from a two or three weeks ago convinced me to try so I made those wayland-mali and mesa-git-mali PKGBUILDs, but then I stopped because tobetter said they couldn't get further theirself.

brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Thu Jan 30, 2020 10:27 am

jgmdev wrote:
Thu Jan 30, 2020 8:40 am
Is this the case for the 4.9 kernel distributed by hardkernel? I tried to modprobe kbase_mali on that kernel but it wasn't found. These are all the references of mali I saw on the kernel modules directory:
Im not actually 100% sure on 4.9 it may have been included by hardkernel with the actual kernel. I would have to check further. The dkms was aimed at newer 5.x kernel I believe.

Edit: Its for mainline only (not 4.9) - https://github.com/superna9999/meson_g12a_mali_bifrost "Amlogic G12A Mali support for Mali Bifrost based SoCs, for Mainline Linux only"
Last edited by brad on Thu Jan 30, 2020 10:34 am, edited 1 time in total.

brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Thu Jan 30, 2020 10:30 am

mxmilkb wrote:
Thu Jan 30, 2020 9:49 am
If the existing driver is a blob, what exactly would/does dkms rebuild on each new kernel installation?

I had made the assumption previously that it wasn't worth trying the older blob driver with the new kernel, but tobetter's posts from a two or three weeks ago convinced me to try so I made those wayland-mali and mesa-git-mali PKGBUILDs, but then I stopped because tobetter said they couldn't get further theirself.
So the kernel module is supplied with full source and this is what dkms used to compile when new kernel is installed. EG here is source https://github.com/superna9999/meson_g12a_mali_bifrost

The blob is the userspace component and supplied from hardkernel / amlogic. It provides shared libraries to the system to enable the features to userland. You could maybe call it the userspace driver.
These users thanked the author brad for the post:
mxmilkb (Thu Jan 30, 2020 1:55 pm)

User avatar
tobetter
Posts: 5080
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Has thanked: 159 times
Been thanked: 485 times
Contact:

Re: wayland drivers when?

Post by tobetter » Thu Jan 30, 2020 10:31 am

brad wrote:
jgmdev wrote:
Thu Jan 30, 2020 8:40 am
Is this the case for the 4.9 kernel distributed by hardkernel? I tried to modprobe kbase_mali on that kernel but it wasn't found. These are all the references of mali I saw on the kernel modules directory:
Im not actually 100% sure on 4.9 it may have been included by hardkernel with the actual kernel. I would have to check further. The dkms was aimed at newer 5.x kernel I believe.
4.9 kernel has built-in Mali driver, not a driver module. And not sure if dkms with 4.9 is fully supported...

"Tapatalk wishes you to have fun with ODROID"


brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Thu Jan 30, 2020 4:10 pm

jgmdev wrote:
Thu Jan 30, 2020 8:40 am
So basically libmali implements all EGL/Wayland graphic functionality as was seen by all the symbolic links to it. I also saw symbolic links to some kind of placeholder library for vulkan. Using the new learned command readelf -s libmali.so I dont see any references to vulkan on libmali. Is there vulkan support? Seems like some of the android images have vulkan in place, does that library also works on a regular linux install? I read some time ago about Zink which is a mesa gallium driver that implements opengl in top of vulkan, if we can run vulkan from a regular linux install I guess that one could use this project to get accelerated Xserver support on the Odroid N2 without an X driver...
brad wrote:
Wed Jan 29, 2020 8:45 pm
- gbm-compat this is @memeka compatibility library designed to work in conjunction with mali userspace binary drivers.
I was able to almost run applications with gbm-compat (seems I'm missing the bifrost kernel driver to fully run them), but when compiling wlroots, even if it compiles well, it links to a version of libgbm that is missing funcitonality, when another applicaiton (in this case sway) links to wlroots it complains about missing symbols at compile time. Not sure how to fix that...

I think I'm understanding at least 0.1% of how this stuff works :)
I don't believe vulkan is supported in linux although it is on Android but they are not compatible. I think we are waiting for the panfrost project (with open source Mali userspace) to support bifrost GPU's like in the N2. Midgard support has landed and bifrost should be next, it should support X.

As for the missing symbols in libgbm.so that is basically what gbm_compat is being used for as libgbm is also replaced by the arm binary versions I believe. eg: https://oph.mdrjr.net/memeka/bionic/gbm ... m_compat.c

Im really not sure how this would work with 4.9 though but I suspect it would work the same.

What were the symbols are you seeing as missing?

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Thu Jan 30, 2020 7:31 pm

So it seems I finally got further ahead after reading the info you guys provided plus re-reading the mailine-linux thread! This is my modules list now on kernel 5.4.15 which includes meson_drm :D

Code: Select all

rfcomm                 90112  16
fuse                  135168  2
8021q                  36864  0
garp                   16384  1 8021q
mrp                    20480  1 8021q
stp                    16384  1 garp
llc                    16384  2 stp,garp
cfg80211              790528  0
bnep                   32768  2
snd_soc_hdmi_codec     20480  0
rc_cec                 16384  0
dw_hdmi_cec            16384  0
dw_hdmi_i2s_audio      16384  0
btusb                  61440  0
btrtl                  24576  1 btusb
btbcm                  16384  1 btusb
btintel                32768  1 btusb
bluetooth             614400  37 btrtl,btintel,btbcm,bnep,btusb,rfcomm
ecdh_generic           16384  1 bluetooth
joydev                 32768  0
meson_dw_hdmi          28672  0
ecc                    36864  1 ecdh_generic
ir_nec_decoder         20480  0
meson_gxl              20480  0
dw_hdmi                45056  2 meson_dw_hdmi,dw_hdmi_i2s_audio
rfkill                 32768  5 bluetooth,cfg80211
meson_drm              61440  2 meson_dw_hdmi
cec                    69632  2 dw_hdmi_cec,dw_hdmi
drm_kms_helper        212992  5 meson_dw_hdmi,meson_drm,dw_hdmi
realtek                20480  1
dwmac_generic          16384  0
rc_odroid              16384  0
snd_soc_meson_g12a_tohdmitx    20480  0
drm                   573440  6 meson_dw_hdmi,meson_drm,drm_kms_helper,dw_hdmi
dwmac_meson8b          16384  0
mali_kbase            610304  0
stmmac_platform        24576  2 dwmac_meson8b,dwmac_generic
meson_ir               16384  0
meson_canvas           16384  1 meson_drm
rtc_meson_vrtc         20480  1
syscopyarea            16384  1 drm_kms_helper
stmmac                221184  3 dwmac_meson8b,stmmac_platform,dwmac_generic
rc_core                57344  7 rc_cec,ir_nec_decoder,meson_ir,cec,rc_odroid
sysfillrect            16384  1 drm_kms_helper
pwm_meson              20480  2
sysimgblt              16384  1 drm_kms_helper
mdio_mux_meson_g12a    16384  0
fb_sys_fops            16384  1 drm_kms_helper
mdio_mux               16384  1 mdio_mux_meson_g12a
phylink                40960  1 stmmac
snd_soc_meson_axg_sound_card    20480  0
snd_soc_meson_axg_tdm_interface    16384  1 snd_soc_meson_axg_sound_card
snd_soc_meson_axg_tdm_formatter    16384  1 snd_soc_meson_axg_tdm_interface
nvmem_meson_efuse      16384  0
8812au               1159168  0
crypto_user            16384  0
hid_logitech_hidpp     40960  0
hid_logitech_dj        28672  0
brad wrote:
Thu Jan 30, 2020 4:10 pm
As for the missing symbols in libgbm.so that is basically what gbm_compat is being used for as libgbm is also replaced by the arm binary versions I believe. eg: https://oph.mdrjr.net/memeka/bionic/gbm ... m_compat.c

Im really not sure how this would work with 4.9 though but I suspect it would work the same.

What were the symbols are you seeing as missing?
When compiling sway from git and linking to wlroots from git this is part of what I get:

Code: Select all

'sway/345c74e@@sway@exe/desktop_xwayland.c.o' -Wl,--as-needed -Wl,--no-undefined -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -g -fvar-tracking-assignments -fdebug-prefix-map=/home/alarm/.cache/yay/sway-git/src=/usr/src/debug -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--start-group common/libsway-common.a protocols/libserver_protos.a /usr/lib/libcairo.so /usr/lib/libjson-c.so /usr/lib/libevdev.so /usr/lib/libinput.so -lm /usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so /usr/lib/libharfbuzz.so /usr/lib/libpcre.so /usr/lib/libGLESv2.so /usr/lib/libpixman-1.so /usr/lib/libwayland-server.so /usr/lib/libwlroots.so /usr/lib/libxkbcommon.so /usr/lib/libxcb.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libpangocairo-1.0.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../common:$ORIGIN/../protocols' -Wl,-rpath-link,/home/alarm/.cache/yay/sway-git/src/build/common -Wl,-rpath-link,/home/alarm/.cache/yay/sway-git/src/build/protocols
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 3 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 4 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 5 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 6 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 7 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 8 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 9 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 3 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 4 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 5 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 6 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 7 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 8 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libEGL.so.1: .dynsym local symbol at index 9 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 3 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 4 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 5 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 6 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 7 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 8 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 9 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_surface_create_with_modifiers'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_offset'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_handle_for_plane'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_modifier'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_plane_count'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_stride_for_plane'
collect2: error: ld returned 1 exit status
[267/268] Compiling C object 'swaynag/183c222@@swaynag@exe/swaynag.c.o'.
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build()
Maybe this is happening because it is linking to mesa libraries instead of those in /usr/lib/mali-egl/ will try the LIBRARY_PATH enviroment trick to see what happens...

Edit:

So I tried the LIBRARY_PATH env var and things worked a bit better but still the linker complained :(, here is some output when compiling wayfire:

Code: Select all

[88/157] Linking target src/wayfire.
FAILED: src/wayfire 
c++  -o src/wayfire 'src/25a6634@@wayfire@exe/main.cpp.o' 'src/25a6634@@wayfire@exe/util.cpp.o' 'src/25a6634@@wayfire@exe/core_output-layout.cpp.o' 'src/25a6634@@wayfire@exe/core_object.cpp.o' 'src/25a6634@@wayfire@exe/core_opengl.cpp.o' 'src/25a6634@@wayfire@exe/core_plugin.cpp.o' 'src/25a6634@@wayfire@exe/core_core.cpp.o' 'src/25a6634@@wayfire@exe/core_img.cpp.o' 'src/25a6634@@wayfire@exe/core_wm.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_pointing-device.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_input-manager.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_keyboard.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_pointer.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_cursor.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_switch.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_tablet.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_touch.cpp.o' 'src/25a6634@@wayfire@exe/core_seat_seat.cpp.o' 'src/25a6634@@wayfire@exe/view_surface.cpp.o' 'src/25a6634@@wayfire@exe/view_subsurface.cpp.o' 'src/25a6634@@wayfire@exe/view_view.cpp.o' 'src/25a6634@@wayfire@exe/view_view-impl.cpp.o' 'src/25a6634@@wayfire@exe/view_xdg-shell.cpp.o' 'src/25a6634@@wayfire@exe/view_xwayland.cpp.o' 'src/25a6634@@wayfire@exe/view_layer-shell.cpp.o' 'src/25a6634@@wayfire@exe/view_view-3d.cpp.o' 'src/25a6634@@wayfire@exe/view_compositor-view.cpp.o' 'src/25a6634@@wayfire@exe/output_plugin-loader.cpp.o' 'src/25a6634@@wayfire@exe/output_output.cpp.o' 'src/25a6634@@wayfire@exe/output_render-manager.cpp.o' 'src/25a6634@@wayfire@exe/output_workspace-impl.cpp.o' 'src/25a6634@@wayfire@exe/output_wayfire-shell.cpp.o' 'src/25a6634@@wayfire@exe/output_gtk-shell.cpp.o' -Wl,--as-needed -Wl,--no-undefined -pie -rdynamic -Wl,-E -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--start-group proto/libwl_protos.a -ldl /usr/lib/libwayland-server.so /usr/lib/libwlroots.so /usr/lib/libxkbcommon.so /usr/lib/libinput.so /usr/lib/libpixman-1.so /usr/lib/libdrm.so /usr/lib/libEGL.so /usr/lib/libGLESv2.so /usr/lib/libwf-config.so /usr/lib/libjpeg.so /usr/lib/libpng16.so /usr/lib/libz.so /usr/lib/libwayland-client.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../proto' -Wl,-rpath-link,/home/alarm/.cache/yay/wayfire-git/src/wayfire/build/proto
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 3 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 4 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 5 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 6 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 7 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 8 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libwayland-egl.so.1: .dynsym local symbol at index 9 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 3 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 4 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 5 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 6 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 7 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 8 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/mali-egl/libgbm.so.1: .dynsym local symbol at index 9 (>= sh_info of 3)
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_surface_create_with_modifiers'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_modifier'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_stride_for_plane'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_plane_count'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_handle_for_plane'
/usr/bin/ld: /usr/lib/libwlroots.so: undefined reference to `gbm_bo_get_offset'
collect2: error: ld returned 1 exit status
No idea on how to fix the issue without patching the meson build file...

Edit #2

So after playing around a bit more I found that I just needed to disable /etc/ld.so.conf.d/mali.conf and remove /etc/ls.so.preload when compiling... So it is better to use LD_PRELOAD when launching stuff like weston-launch or sway with the libmali.so. Back to some more testing...

Edit #3

Some more testing and discovered that the DKMS kernel driver only compiles on kernel >=5 && <= 5.4. Tried to compile on kernel 5.5 but it failed... Weston seems to perform well, wayfire crashes when displaying background and cursor, sway crashes if trying to launch X application.
These users thanked the author jgmdev for the post:
Kernel (Fri Jan 31, 2020 4:09 pm)

brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Fri Jan 31, 2020 6:46 pm

jgmdev wrote:
Thu Jan 30, 2020 7:31 pm
Edit #2

So after playing around a bit more I found that I just needed to disable /etc/ld.so.conf.d/mali.conf and remove /etc/ls.so.preload when compiling... So it is better to use LD_PRELOAD when launching stuff like weston-launch or sway with the libmali.so. Back to some more testing...
Yes interesting it compiles but when being linked it looks at the mali blobs. This is where the dependencies issues come into it I guess on ubuntu I had to remove mali blob to install mesa dev packages to compile & link. (eg for mutter / clutter)
jgmdev wrote:
Thu Jan 30, 2020 7:31 pm
Edit #3

Some more testing and discovered that the DKMS kernel driver only compiles on kernel >=5 && <= 5.4. Tried to compile on kernel 5.5 but it failed... Weston seems to perform well, wayfire crashes when displaying background and cursor, sway crashes if trying to launch X application.
I haven't tried 5.5 yet so not sure of the kernel driver issue. Thinking about the crashing issue make sure your user has permission to /dev/dri/card0 & /dev/fb0

jgmdev
Posts: 65
Joined: Tue Jan 28, 2020 2:28 pm
languages_spoken: english, spanish
ODROIDs: U2, N2, C4
Has thanked: 18 times
Been thanked: 42 times
Contact:

Re: wayland drivers when?

Post by jgmdev » Mon Feb 03, 2020 3:56 pm

brad wrote:
Fri Jan 31, 2020 6:46 pm
Yes interesting it compiles but when being linked it looks at the mali blobs. This is where the dependencies issues come into it I guess on ubuntu I had to remove mali blob to install mesa dev packages to compile & link. (eg for mutter / clutter)
Yeah, maybe it is better to create a package only with libmali,so and libgbm-compat.so and a mali-exec script that does the preloading of the libraries for the executed binary, something like:

mali-exec:

Code: Select all

#!/bin/sh
LD_PRELOAD="/usr/lib/libmali,so /usr/lib/libgbm-compat.so" exec $@
That way it wouldn't conflict with mesa installation or compiling and no need to do the /etc/ld.so.preload stuff
brad wrote:
Fri Jan 31, 2020 6:46 pm
I haven't tried 5.5 yet so not sure of the kernel driver issue. Thinking about the crashing issue make sure your user has permission to /dev/dri/card0 & /dev/fb0
Verified and I did added my user to the video group and both /dev/dri/card0 & /dev/fb0 have the video group assigned to them. When running sway without libmali it did launched XWayland applications but overall rendering was obviously slower. Maybe I should now test compiling the latest kernel driver from ARM to see if it is compatible with newer 5.5 kernel, but as far as I understand the libmali.so file distributed by hardkernel is only compatible to the older kernel driver :(

brad
Posts: 1092
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 H2 (64 bit ftw)
Location: Australia
Has thanked: 41 times
Been thanked: 80 times
Contact:

Re: wayland drivers when?

Post by brad » Tue Feb 04, 2020 4:50 pm

jgmdev wrote:
Mon Feb 03, 2020 3:56 pm

Yeah, maybe it is better to create a package only with libmali,so and libgbm-compat.so and a mali-exec script that does the preloading of the libraries for the executed binary, something like:

mali-exec:

Code: Select all

#!/bin/sh
LD_PRELOAD="/usr/lib/libmali,so /usr/lib/libgbm-compat.so" exec $@
That way it wouldn't conflict with mesa installation or compiling and no need to do the /etc/ld.so.preload stuff
In this case we would need to modify everything that we wanted to accelerate, eg modifing systemd service files (eg for the desktop manager) and all the applications that make up the desktop which would be quiet extensive I think. Especially when we think of something like gnome.
jgmdev wrote:
Mon Feb 03, 2020 3:56 pm

Verified and I did added my user to the video group and both /dev/dri/card0 & /dev/fb0 have the video group assigned to them. When running sway without libmali it did launched XWayland applications but overall rendering was obviously slower. Maybe I should now test compiling the latest kernel driver from ARM to see if it is compatible with newer 5.5 kernel, but as far as I understand the libmali.so file distributed by hardkernel is only compatible to the older kernel driver :(
Unfortunately I don't think the arm version will run with mainline, what were the errors you were seeing compiling it against 5.5 kernel? I still haven't had a chance to attempt it yet. Neil is usually quiet quick to update the code base if there are incompatibilities with new kernels.

MajesticMagistrate
Posts: 16
Joined: Fri Feb 21, 2020 8:22 am
languages_spoken: english, hungarian
ODROIDs: ODROID N2
Has thanked: 0
Been thanked: 3 times
Contact:

Re: wayland drivers when?

Post by MajesticMagistrate » Tue Mar 03, 2020 6:45 am

brad wrote:
Tue Feb 04, 2020 4:50 pm
Unfortunately I don't think the arm version will run with mainline, what were the errors you were seeing compiling it against 5.5 kernel? I still haven't had a chance to attempt it yet. Neil is usually quiet quick to update the code base if there are incompatibilities with new kernels.
I've tested it on 5.5.6 (Manjaro's), the dkms compilation error said "undefined reference to mm_trace_rss_stat in mali_kbase.ko".
I didn't find any references to it in the dkms module, but found some information regarding a change around that (it seems to be some callback function that was added in 5.5):
https://lore.kernel.org/linux-mm/201911 ... gle.com/t/
In mali_kbase_mem_linux.c there are calls to add_mm_counter which calls mm_trace_rss_stat.
Just to test things out, I've added this empty function in mali_kbase_mem_linux.c after the includes, and it seems, that the dkms module compiles indeed:

Code: Select all

void mm_trace_rss_stat(struct mm_struct *mm, int member, long count) {}
However, my experience with graphics acceleration on KDE wayland wasn't promising, first I just replaced the libEGL, GLESv2 and wayland-egl's to symlinks to libmali.so, switched to wayland, the entire screen was black, graphics were drawn only in a 20x20 pixel rectangle around the mouse, or if I grabbed a window and moved it around, the window was rendered fully, and a ~20 pixel padding.
Then I realized I would still need the libgbm-compat, added it, put it in the ld-preload, and the desktop was drawn completely, but it was very-very slow.

Maybe I've made some mistakes while setting it up, or maybe just KDE didn't like the mali blob - I didn't try it yet with weston.

I'll try some things later, if I think of anything.

mxmilkb
Posts: 64
Joined: Fri Apr 26, 2019 9:28 am
languages_spoken: English
ODROIDs: N2
Has thanked: 23 times
Been thanked: 21 times
Contact:

Re: wayland drivers when?

Post by mxmilkb » Wed Mar 04, 2020 8:24 am

<@alyssa> My original plan was to make this my Secret Project(TM) for a while and then do a big splash when we got the first renders goin
<@alyssa> Of course you can't have secret projects when you do all development upstream-first ;)
<@alyssa> So now that the cat is out of the bag, and the bag didn't exist to begin with
<@alyssa> I'm still doing Midgard work and of course class so hours are limited but I've been pressing forward on Bifrost (initially focusing on G52) and we'll see what happens
<@alyssa> Estimating about a month until anything interesting happens but we'll see. Lots and lots of plumbing.
<@alyssa> The Midgard driver was developed very haphazardly and there was a lot of code that had to get rewritten sometimes multiple times due to initial oversights
<@alyssa> so I'm trying to use Bifrost as an opportunity to fix some of those big mistakes (type sizing issues are the #1 here, control flow is also high)
These users thanked the author mxmilkb for the post (total 3):
jgmdev (Wed Mar 04, 2020 9:15 am) • Sav (Wed Mar 04, 2020 5:32 pm) • odroidn2user (Thu Mar 05, 2020 7:09 pm)

MajesticMagistrate
Posts: 16
Joined: Fri Feb 21, 2020 8:22 am
languages_spoken: english, hungarian
ODROIDs: ODROID N2
Has thanked: 0
Been thanked: 3 times
Contact:

Re: wayland drivers when?

Post by MajesticMagistrate » Wed Mar 04, 2020 8:46 am

MajesticMagistrate wrote:
Tue Mar 03, 2020 6:45 am
Maybe I've made some mistakes while setting it up, or maybe just KDE didn't like the mali blob - I didn't try it yet with weston.
I've tried again, and it seems weston works GPU accelerated on 5.5.6 with the dkms module(with an added empty function), libgbm-compat, and libmali, glmark2-es2-wayland (in windowed mode) gave around 960 points. I also tested Sway, it starts, but when I press the hotkey (Super+D) to start an application, Sway crashes.

mxmilkb wrote:
Wed Mar 04, 2020 8:24 am
...
<@alyssa> I'm still doing Midgard work and of course class so hours are limited but I've been pressing forward on Bifrost (initially focusing on G52) and we'll see what happens
...
Wow, that's great news! Last time I've checked the git repository of mesa, there were 3-7 month gaps between commits on the bifrost driver, and thought no real progress will be made at this rate, but this is promising!

mxmilkb
Posts: 64
Joined: Fri Apr 26, 2019 9:28 am
languages_spoken: English
ODROIDs: N2
Has thanked: 23 times
Been thanked: 21 times
Contact:

Re: wayland drivers when?

Post by mxmilkb » Thu Apr 23, 2020 11:02 pm

These users thanked the author mxmilkb for the post:
Sav (Thu Apr 23, 2020 11:15 pm)

miskol
Posts: 244
Joined: Wed Jan 15, 2014 2:58 am
languages_spoken: english,slovak
Has thanked: 0
Been thanked: 12 times
Contact:

Re: wayland drivers when?

Post by miskol » Thu Apr 23, 2020 11:19 pm

panfrost is opengl and opengl es
arm mali is pure opengl es

so you will need to recompile some app to get proper support maybe

User avatar
tobetter
Posts: 5080
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Has thanked: 159 times
Been thanked: 485 times
Contact:

Re: wayland drivers when?

Post by tobetter » Thu Apr 23, 2020 11:20 pm

These users thanked the author tobetter for the post:
mxmilkb (Fri Apr 24, 2020 2:24 am)

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 0 guests