[Chromebook Plus (GRU)] X11 Hardware acceleration fail

[apokalypz]

According to the archlinuxarm wiki page for the Samsung Chromebook Plus (GRU):
$this->bbcode_second_pass_quote('', 'T')he Mali T860MP4 GPU is not supported at this time. Therefore, no particular Xorg drivers are needed. The built in modesetting driver will correctly detect the display.

[gotarcher]

Hi,
A couple days ago, chromium added backward compatibility to the kernel for MALI drivers:
https://chromium.googlesource.com/chrom ... 908d4d40d1

Your workaround for droping r14 in the PKGBUILD won't be needed any more when this hits arch repo. At least it worked for me.

About xf86-video-armsoc. Seems to me that you need rockchip's xorg-server.
I built rockchip's xorg but hit a bug that froze the plasma desktop after about 10 minutes of inactivity time. Looks like rockchip's
software stack is quite integrated and parts don't like to be run independently from the others. Probably developed as a whole.
I didn't even try to load xf86-video-armsoc with their xorg, it may just support pre rk3399 boards.

[gotarcher]

Expanding a bit into the issue:
[url]From https://github.com/rockchip-linux/xf86- ... armsoc.man[/url]
$this->bbcode_second_pass_quote('', 's')upports the Mali-T400 & Mali-T60x

[apokalypz]

Thanks for the reply. I built what I could from the rockchip-linux repos, but they're kinda out of date (libDRM for instance is below the version cutoff for xserver). I think the reason rockchip has such a complicated and customized stack is because their xserver supports glamor on Mali and their DRM drivers support their RGA (2d raster acceleration for memory to memory). From all the issues and questions asked in their github, it doesn't look like their solution with glamor is very fast (its actually slower than software when dealing with small processes) and they say their RGA is only really for copying output from v4l2 to a separate area in memory (like an x window for instance). So their solutions are really to get their custom bits working.

Unfortunately I don't know enough about the x11 stack to really know what the issue is (or even why we need a compatible DDX to let Mali GLes target an X window. Since we're not using glx.) When I run with the modesetting driver and try to run glmark2-es2, I get 3000 or 3001 errors (if I remember from the odroid C2 Kodi development days, one of those errors means it can't get an egl surface to draw to.) Which implies there needs to be some glue between egl and the x window (I'm guessing through dri2? Which the xserver says the modesetting driver doesn't support. Probably because of missing exa stuffs?)

I'm learning a lot, and I can see why everyone wants to replace X with Wayland. X is so damn convoluted. It just kinda sucks that most software still relies on X and eventhough Wayland support is booming. Ten years from now, X is probably still gonna be sitting in the back, banging it's head on your seat screaming because it only has one friend (some dependency of a dependency of a friggin video codec.)

[gotarcher]

Couldn't agree more. I believe ARM is focusing on wayland and so is Rockchip.

EGL glamor is not very promising reading this:
https://lists.x.org/archives/xorg-devel/2016-January/048417.html

On the wayland side, weston launches fine (recognizes driver), plasma not so much. None of them start from sddm. es2_gears runs in weston, but it doesn't get a display in plasma.

<offtopic>
It's a pity, I guess there is not much userbase yet for this machine. In Europe you need to get it through american Amazon.
The specs/price ratio is impressive to me, should be a great candidate for a Linux laptop. I guess, eventually rk3399 will get there.
Collabora is also working on it, see:
https://lkml.org/lkml/2018/3/9/909
</offtopic>

[apokalypz]

As far as userbase goes. Its about to blow up: https://forum.odroid.com/viewtopic.php?t=29932

Hardkernel usually supports Arch on their SBCs and a whole lot of useful development has come out of their user base. So hopefully they'll figure things out and we'll have a working implementation soon ish.

Also, from the arch wiki on sddm:
$this->bbcode_second_pass_quote('', 'T')he Wayland windowing system is not yet fully supported [1]. Wayland sessions are listed, but SDDM runs on X11.

[cpwrunner]

Hi,

I have a cbplus that I am trying to run arch linux on. I have been using the PKGBUILD for the google chromeos kernel version 104. I have tried to use the drop in method of compiling opensource kernel drivers from the ARM mali website. I grabbed the r13 version of this driver because it seemed to correspond to the date of the userland driver available on the rockchip website. The r13 kernel driver appears to be loading correctly as I have a /dev/mali0 device when the cbplus boots up in arch. I also believe that for the most part the userland drivers are also installed correctly.

This is what the symlinks for the userland drivers look like:

lrwxrwxrwx 1 root root 10 Dec 15 03:06 libEGL.so -> libMali.so
lrwxrwxrwx 1 root root 10 Dec 15 03:06 libGLESv2.so -> libMali.so
lrwxrwxrwx 1 root root 10 Feb 12 18:21 libMali.so -> libmali.so
lrwxrwxrwx 1 root root 10 Dec 15 03:06 libgbm.so -> libMali.so
-rwxr-xr-x 1 root games 25214448 Feb 2 20:20 libmali-midgard-t86x-r13p0-gbm.so
-rwxr-xr-x 1 root games 25227344 Feb 2 20:20 libmali-midgard-t86x-r13p0-wayland.so
-rwxr-xr-x 1 root games 25227232 Feb 2 20:20 libmali-midgard-t86x-r13p0.so
lrwxrwxrwx 1 root root 29 Feb 12 19:24 libmali.so -> libmali-midgard-t86x-r13p0.so

I am using rockchip's xserver also which a created a PKGBUILD for manually.

Despite these measures I am still not able to get the glamor accelerated xserver to start. In my Xorg.0.log file I receive a message that says "eglGetDisplay() failed ... glamor initialization failed" and no more debugging information despite having compiled the rockchip xserver with debugging enabled. Also, I tried to use gdb to debug the xserver as suggested here: http://rockchip.wikidot.com/xserver, but I receive an error from gdb that the xserver is not the right "executable format" which seems to be just wrong (unless somehow the debugging symbols were never enable when compiling the xserver with the --enable-debug flags)

Anyway I would not mind recompiling a newer google cbplus kernel, so long as I have some reasonable amount of certainty that it will progress me towards my goal of obtaining a plasma linux desktop on the cbplus. From a broader perspective it seems like I do not have a good grasp of which graphical systems are likely to be supported by the archlinux community and rockchip nor what their capabilities are. For instance is using rockchip's version of linux development with their kernel a better method of achieving significant linux graphics functionality than using archlinux with the google cbplus kernel? (as suggested here: http://opensource.rock-chips.com/wiki_Linux_user_guide)

Anyway any guidance that someone on this forum could provide would be greatly appreciated. The cbplus seems to have a lot of potential, but unfortunately a bit behind on support documentation.

Thanks

[gotarcher]

Hi, I run plasma on the cbp.
what worked for me was using a chrome kernel

after:https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9614bc2e648a411a8d5b16ff637c24908d4d40d1
and before:https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e2cbf07110aa764869e9e2b4ae5bfcdc862933c5

in-between those together with rockchip's r14 userspace.
Rockchip's xorg (with r14) performed worse than arch xorg for me. Still, no glamor or hardware accel but a pretty usable experience.