Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try new xorg server (with patches) and gles-glamor on pinephone/lima #589

Closed
MerlijnWajer opened this issue Dec 10, 2021 · 8 comments
Closed

Comments

@MerlijnWajer
Copy link
Member

14:43 < uvos> Wizzup: so i seam to have lost the gles forcing patch, but its just forcing all context
              creation above here
https://github.com/maemo-leste-upstream-forks/xorg-server/blob/maemo/ascii/glamor/glamor_egl.c
14:44 < Wizzup> so just define GLAMOR_GLES2 ?
14:45 < uvos> no
14:45 < uvos> sry
14:45 < uvos> i linked that wrong
14:45 < uvos> because the code is different in older xserver
14:45 < uvos> sec
14:45 < uvos> https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L1021
14:45 < uvos> just make everything above that fail
14:45 < uvos> that creates a context
14:45 < uvos> (ie comment it out)
14:46 -!- sicelo_ [~sicelo@harlock.dyne.org] has joined #maemo-leste
14:46 -!- sicelo_ [~sicelo@harlock.dyne.org] has quit [Changing host]
14:46 -!- sicelo_ [~sicelo@user/sicelo] has joined #maemo-leste
14:46 < uvos> ie comment from
              https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L980
14:47 < uvos> to https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_egl.c#L1035
14:47 < uvos> should force gles
14:47 < uvos> alternative approche to just test if gles is better is just to rm libgl.so
14:48 < Wizzup> ok
14:48 < uvos> also note gles glamor has had quite a few bug fixes
14:48 < uvos> that are not in our old version
14:48 < Wizzup> yeah we probably want new X
14:50 < uvos> i dimly remember that gles on radon also only worked on latest master
14:50 < uvos> with some additional prs applied
14:51 < uvos> this one at least https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/401
14:51 < uvos> i think
14:51 < Wizzup> if someone tells me how to build xproto stuff I can do it in my lxc thing
14:51 < Wizzup> oh shit that's not even merged
14:52 < uvos> yeah and it ainchent
14:52 < uvos> and clearly correct
14:52 < uvos> i dont get these people
14:52 < Wizzup> well I get ignored by them so I'm not even going to bother
14:53 < uvos> right
14:53 < uvos> we might want to add an option to force gles in xorg.conf
14:53 < uvos> but yeah they proububly will ignore it
14:54 < freemangordon> Wizzup: could we discuss xorg tomorrow, I'll provide you glamor patches that
                       are needed, for d4 at least
14:54 < freemangordon> I don;t have time now
14:54 < uvos> im pretty confident that it worked with master and just that patch on mesa
14:54 < uvos> on llvm and on radeonsi
14:54 < Wizzup> yes, tomorrow is fine although I might be afk some of the time then
14:56 < freemangordon> me too, the point was that I cannot do it *now* :)
14:57 < freemangordon> uvos: no reason to not have the patches needed for SGX, agree?
14:57 < uvos> sure but he wants to test lima specificly
14:58 < uvos> the glfinish patches for sgx for instance are just sgx being buggy probuly for instance
14:58 < uvos> and just cause it to be slower
15:00 < Wizzup> uvos: I renamed libGL.so.something and I am not sure if that was a good idea :P
15:01 < Wizzup> let's do that later
@MerlijnWajer
Copy link
Member Author

So I did this, and the result is mostly the same, there is still the same problems where parts of the screen aren't being redrawn, or at least not the most recent frame is being drawn.

@MerlijnWajer
Copy link
Member Author

This is with mesa 21.2.5 and X 1.21

@MerlijnWajer
Copy link
Member Author

For the record, what I did to get the initial build going on the pinephone (this doesn't account for additional changes/patches)

#xorgproto
git clone https://salsa.debian.org/xorg-team/proto/xorgproto.git -b upstream-unstable
cd xorgproto
git fetch origin
git checkout -t origin/debian-unstable
git checkout -
git checkout debian-unstable debian
dpkg-buildpackage -b -uc
#dpkg -i ....



#libxi
git clone https://salsa.debian.org/xorg-team/lib/libxi -b upstream-unstable
cd libxi
git fetch origin debian-unstable
git checkout -t origin/debian-unstable
git checkout -
git checkout debian-unstable debian
dpkg-buildpackage -b -uc
#dpkg -i ...



#libxcvt
wget http://ftp.de.debian.org/debian/pool/main/libx/libxcvt/libxcvt-dev_0.1.1-1+b1_arm64.deb
wget http://ftp.de.debian.org/debian/pool/main/libx/libxcvt/libxcvt0_0.1.1-1+b1_arm64.deb
#dpkg -i ...



git clone https://salsa.debian.org/xorg-team/xserver/xorg-server -b upstream-unstable
cd xorg-server
git fetch origin debian-unstable
git checkout -t origin/debian-unstable
git checkout -
git checkout debian-unstable debian
dpkg-buildpackage -b -uc

@MerlijnWajer
Copy link
Member Author

12:28 < Wizzup> yeah many of the weird issues go away when the window is unredirected
12:28 < uvos> so its not glamor
12:28 < parazyd> Thanks
12:28 < Wizzup> let me check again
12:28 < uvos> probubly not xorg at all (though it still can be)
12:28 < uvos> and likely is hildons or mesas fault (probubly mesa)
12:29 < Wizzup> so maybe we can reproduce it with compmgr or something
12:29 < Wizzup> compton or whatever that is called now
12:29 < uvos> yeah sure
12:29 < uvos> try or kwin
12:29 < uvos> kwin is good because its also gles
12:30 < uvos> (if you configure it right)
12:30 < uvos> all others are opengl
12:30 < rafael2k> ok, just tested the X with accell
12:30 < Wizzup> h-d can use both too (clutter can rather)
12:30 < rafael2k> same behavior with the kernel Im using
12:30 < uvos> right so either try kwin gles
12:30 < uvos> or hildon opengl first
12:30 < Wizzup> rafael2k: not surprising, I see it even on latest X and stuff
12:31 < rafael2k> GL_VERSION: OpenGL ES 2.0 Mesa 20.3.5
12:31 < rafael2k> GL_RENDERER: Mali400
12:31 < Wizzup> I don't recall where we specify the hildon renderer
12:31 < rafael2k> restarting X with noaccell
12:31 < Wizzup> rafael2k: yes, I think we confirmed the bug is probably not in x11 or kernel
12:32 < Wizzup> uvos: fwiw:
12:32 < Wizzup> # cat /etc/hildon-desktop.env
12:32 < Wizzup> export COGL_RENDERER=egl_xlib
12:32 < Wizzup> export COGL_DRIVER=gles2
12:32 < rafael2k> but when I boot with accelleration things are sooo fast, firefox opens up in an
                  instant, terminal is sooo snappy
12:33 < Wizzup> rafael2k: yes, we just need to get this compositing bug fixed and it'll be awesome to
                use
12:33 < rafael2k> uhum
12:33 < Wizzup> rafael2k: with latest packages the virtual keyboard bugs are mostly fixed
12:33 < rafael2k> cool
12:33 < Wizzup> I suppose alteratively you could make some hildon-desktop frankenstein build that
                disables compositing all together, but it'll probably look weird
12:34 < _inky> uvos: i use pinebook with xorg, but pinebook is different hardware than pinephone. it's
               same as pinephone pro.
12:34 < uvos> thats impossible
12:34 < _inky> so glad to see these discussions!
12:34 < _inky> i'd like to use maemo on pinephone so much.
12:34 < uvos> _inky: sure but its the same mesa driver or?
12:34 < rafael2k> _inky: use it
12:34 < Wizzup> _inky: if you have a pinebook with xorg, what do you use on it
12:34 < _inky> windowmaker.
12:35 < Wizzup> never heard of it
12:35 < _inky> always. i always use that on anything.
12:35 < uvos> have you run some compositing window wm?
12:35 < _inky> it looks like nextstep.
12:35 < uvos> heh
12:35 < _inky> i tried enlightenment.
12:35 < _inky> it worked well. on xorg.
12:35 < Wizzup> e17 isn't compositing per se is it
12:35 < rafael2k> I use WM too... since before gnome or kde exist.
12:35 < _inky> much better than windowmaker may be. i tried to use pico compositor with windowmaker
               even.
12:35 < uvos> Wizzup: yes it is
12:35 < Wizzup> ok
12:35 < uvos> Wizzup: non compsiting was dropped
12:36 < uvos> Wizzup: in 2019 or so
12:36 < Wizzup> ok, would be good to confirm still
12:36 < Wizzup> I'm quite sure the bug isn't in h-d
12:36 < uvos> yeah it seams unlikely
12:36 < Wizzup> side note scrolling becomes much smoother with compositing turned off
12:36 < Wizzup> even on landscape (in apps at least)
12:36 < uvos> sure
12:36 < uvos> same on d4
12:37 < uvos> hildon-desktop is veeery hevy
12:37 < Wizzup> uvos: actually it is not compared to the rest :P
12:37 < uvos> well compositing  in a singe window wm is silly :P
12:37 < Wizzup> I imagine we can actually fix that later on but let's not get distracted
12:37 < uvos> would be very hard to fix
12:37 -!- alex1216 [~alex1216@95-28-49-175.broadband.corbina.ru] has quit [Ping timeout: 240 seconds]
12:38 < uvos> is very ingrained into its arch
12:38 < Wizzup> _inky: could you run some tests for us? it might require using another distro/image
12:38 < bencoh> I still believe we should allow disabling compositing easily :]
12:38 < _inky> with pleasure
12:38 < _inky> i have maemo on sdcard.
12:38 < Wizzup> bencoh: work on it and we'll allow it :P
12:38 < bencoh> :)
12:39 < Wizzup> uvos: so wrt tests, what would make the most sense other than 'run kwin'
12:39 < Wizzup> maybe we need some widely available application that is buggy
12:39 < Wizzup> the problems seems to occur when windows are stacked, it seems to me
12:39 < Wizzup> like virtual keyboard on top of xterm
12:39 < Wizzup> or conversations stacked window
12:40 < uvos> Wizzup: well run hildon on gl, try comption makes sense (ellimnate window redirection
              for compositing in xorg as a cause)
12:40 < uvos> Wizzup: then try clutter demos
12:40 < uvos> Wizzup: try and figure out what clutter calls cause the driver to trip up
12:40 < Wizzup> it seems like we can do that on pinephone
12:41 < Wizzup> does anyone remember the name for COGL_DRIVER for non-gles2?
12:41 < Wizzup> maybe just commenting COGL_DRIVER=gles2 works too

@MerlijnWajer
Copy link
Member Author

13:06 < Wizzup> uvos: hm there are still some oddities like things tend to 'bounce' a bit, like vkb
                will move up and down a bit for every key pressed
13:06 < Wizzup> uvos: this doesn't happen if the window below it is unredirected
13:08 < Wizzup> uvos: yeah calculator also is weird with compositing enabled, and that has no
                overlaying windows afaict, so that could be a good test case
13:09 < Wizzup> so I can observe: (1) calculator flickers with every key press with compositing (2)
                conversations scrolling in a conversations is a mess with compositing on (3) vkb
                bounces up and down on a composited osso-xterm

@MerlijnWajer
Copy link
Member Author

MerlijnWajer commented Dec 21, 2021

13:25 < Wizzup> uvos: (4) starting control panel applets in portrait mode makes them bounce
13:25 < Wizzup> for a while

At least "text input"

@MerlijnWajer
Copy link
Member Author

13:50 < uvos> Wizzup: ok yeah i would try compton and some clutter demos on pp next
13:50 < uvos> https://github.com/clutter-project/toys
13:50 < uvos> sor so

@MerlijnWajer
Copy link
Member Author

We figured this out with a few fixes to clutter and then a mesa patch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant