Pinebook Manjaro LXQt graphic speed



Someone would have to take over maintaining it then. I’m not a GTK guy.


Just to complete my experiments xterm is also slow …
So it is not what is shown in the window that slows things down.

I was thinking weather qt5 or gtk could make a difference, but I use Termite as terminal and that’s Gtk and also fast. Plus xterm in neither and still slow.


If I had a Pinebook and the skills I would be doing the maintaining of both DEs.


As I said before - as OB does not support -insert technical term for floating and redrawing windows or whatever- there still might be a slight performance gain from the similiar setting it does support - that of not resizing items in windows in real time.


I played around a bit more and here is a workaround: compton
If you install the compositor compton and run it from the terminal I get these error messages:

manjaro@archlinux ~> compton
[ 02/15/19 13:37:04.669 vsync_opengl_swc_swap_interval ERROR ] Your driver doesn't support SGI_swap_control nor MESA_swap_control, giving up.
[ 02/15/19 13:37:04.669 vsync_opengl_init ERROR ] Your driver doesn't support SGI_video_sync, giving up.
[ 02/15/19 13:37:04.669 session_init FATAL ERROR ] Failed to initialize the backend

However if you start it with --vsync none

manjaro@archlinux ~> compton  --vsync none
[ 02/15/19 13:38:31.892 vsync_opengl_swc_swap_interval ERROR ] Your driver doesn't support SGI_swap_control nor MESA_swap_control, giving up.

You still get an error but compton seems to be willing to live with that.
From now the window movement is always relative fluent, however I feel it’s not as smooth as QTerminal without compton. This probaby can be tuned further, as I actually don’t want display effects.

It might also be interesting to investigate the error messages that comption throws. How could they be avoided.

And while I am at it. How could I use GLX instead of xrenderer ?


When I was running XFCE on an old intel I used options like these:

# GLX backend
backend = "glx";
# vsync = "opengl-swc";
# sw-opti = true;
paint-on-overlay = true;
glx-no-stencil = true;
# glx-copy-from-front = false;
# glx-use-copysubbuffermesa = false;
glx-no-rebind-pixmap = false;
# glx-swap-method = "undefined";
# glx-use-gpushader4 = true;
xrender-sync = true;
xrender-sync-fence = true;

have fun!



I have been looking into this a bit.
I found the proprietary mali blobs, so when installing those together with the xf86-video-fbturbo-git driver smooths out the lagging of window dragging quite a bit.

The mali blobs package is not in the repo yet, but will be later, so you guys can install it and test.

PS: I still need to test some stuff, where I hopefully can get the mali kernel module going. But no promises though.

PPS: Written from my Pinebook.


Cool. @Strit

I have installed these packages, is that correct ?


Also written on my Pinebook :slight_smile:


That’s correct. Even though I’m not sure the pine64-libgl-x11 actually does anything to help.
It does contain the mali blobs though, so it’s there for future use at least.


Well, there is definitely a speed boost.
Firefox and lxqt-config (strangely another very slow window) are quite smooth now. There are sometimes some jumps, however it almost feels as if that could be the mouse/trackpad and not the graphic.

Interestingly compton still complains about missing glx functionality…

vsync_opengl_swc_swap_interval ERROR ] Your driver doesn't support SGI_swap_control nor MESA_swap_control, giving up.

How does that work together with the Lima driver ?

glxgears has become if anything slower btw, from ~23fps to ~19fps in full screen. (1080)
Does anybody know a good result that the Mali400 GPU should be able to achieve with glxgears (part of the mesa-demos package) ?

I admit I have now idea how this all plays together …
Is there some docu somewhere to see how this all adds up?


Getting better performance requires the mali driver to be functional I guess.