ghost
commented
5 years ago If you're using xwayland with sway on a Mali platform you also need this fix: https://github.com/swaywm/sway/pull/4537
Closed ghost closed 5 years ago
ghost
commented
5 years ago If you're using xwayland with sway on a Mali platform you also need this fix: https://github.com/swaywm/sway/pull/4537
valpackett
commented
5 years ago Will try panfrost next but it probably isn't ready yet
uh, it runs GNOME Shell and KDE Plasma 5. hacking workarounds for libmali seems like a waste of time at this point
Hi, after much suffering I managed to get wlroots, swaywm, alacritty, and firefox (wayland mode) working on the Samsung Chromebook Plus (aka gru-kevin) using its the Mali 860 GPU, booting from self-built coreboot+ec firmware so libMali is the only blob in the system, and panfrost will fix that soon.
The attached patch is not directly suitable for upstreaming, but I wanted to post it here to help other people using this laptop, or other rk3399 devices. The patch basically does two things:
Avoid using the gbm_bo_get_modifier(), gbm_bo_get_offset(), gbm_bo_get_plane_count(), and gbm_bo_get_stride_for_plane() extensions, since they are not part of the original core GBM API and are not required to be supported by all libgbm implementations. Since these functions are only called in a small number of places it might be best for wlroots to do a weak linking here and use dlsym() to invoke them if found, falling back to a single-plane assumption otherwise.
Roll back the patch that made DRM_FORMAT_ARGB8888 the "preferred" format; otherwise you just get a black screen. This is probably due to a bug in Rockchip's DRM incorrectly advertising support for it. I suggest wlroots add an environment variable that can be used to force a particular DRM mode in situations like this.
Firefox v68.0.1 works very well, but you have to build with --disable-dbus and --enable-default-toolkit=cairo-gtk3-wayland, then launch with MOZ_NO_REMOTE=1 and MOZ_ENABLE_WAYLAND=1. Can even run maps.google.com 3D view with webgl acceleration!
I found that alacritty will freeze up randomly unless sway is launched with -Dnoatomic. Unfortunately the libMali blob is very, very unforgiving, and the freezing is due to it crapping all over the call stack when it gets in a bad mood. It's almost impossible to debug what's going on there (it spawns a half-dozen mysterious pthreads in the alacritty process) but it's probably due to some obscure OpenGL ES lifetime rule that all the other GPU drivers are more-forgiving about. Alacritty also needs a patch, I'll post that as an issue in their github. ARM rejects libMali bug reports from anybody other than silicon vendors -- I think they know what a mess their codebase is.
In Alacritty I discovered that individual characters are rendered upside-down when it is run under sway on rk3399 -- but this bug does NOT occur when you use weston on rk3399 or sway on AMD/ATI! A very odd bug. For now I just kludge around it with a patch that flips them in the shader. Will post that to alacritty's github.
The Mali GPU blob used is libmali-midgard-t86x-r14p0-wayland.so with md5sum ca22dcf663199082161efb3bbc7c63ee. Will try panfrost next but it probably isn't ready yet.
Lastly, when sway runs into trouble (which happens less and less often) it leaves the kernel DRM display in a bad state; it doesn't respond to keyboard events. The only way to unwedge it I have found is to ssh in remotely and launch Xorg (!) which knows how to clean up the mess. Is there some simpler "reset the DRM state" utility that I can use? If so I'll bind it to one of the non-keyboard input switches on the device so I can recover from sway crashes without using a separate machine.
wlroots-rk3399-patch.txt