Xorg broken on hammerhead (Nexus 5)

I gave

$ git clone https://gitlab.com/postmarketOS/pmbootstrap
$ cd pmbootstrap/
$ ./pmbootstrap.py init
$ ./pmbootstrap.py install --no-fde
$ ./pmbootstrap.py flasher flash_rootfs --partition userdata
$  sudo fastboot format system
$ ./pmbootstrap.py flasher flash_kernel

selecting mate, xfce4 and hildon respectively. On each of them Xorg failed to start apparently due to the lack of a library. Here is the full Xorg log

Actually I could not get any X11/wayland interface working on my device.

changed the description

By tallero on 2019-03-24T21:41:34

mentioned in issue #209

By tallero on 2019-03-24T21:43:12

changed the description

By tallero on 2019-03-24T22:10:30

changed the description

By tallero on 2019-03-24T22:13:28

changed the description

By tallero on 2019-03-24T22:17:50

changed the description

By tallero on 2019-03-24T22:20:40

changed the description

By tallero on 2019-03-24T22:43:53

The temp/mesa packaging uses this path _dri_driverdir=/usr/lib/dri. The upstream aport uses this path _dri_driverdir=/usr/lib/xorg/modules/dri. xserver expects it to be in the latter path.

By ryang on 2019-03-24T23:13:14

@ryang2678 The file swrast_dri.so said as missing in the log is not present anywhere in the system and sure not in /usr/lib/dri.

I have symlinked the content of /usr/lib/dri in /usr/lib/xorg/modules/dri but the result is the same since the aforementioned library is still missing on the system.

According to alpine website

the file belongs to mesa-dri-swrast which is listed as subpackage in the temp/mesa APKBUILD.

Do not know if it should, but apk list | grep mesa on the device only returns:

lg-hammerhead:/# apk list | grep mesa
WARNING: Ignoring APKINDEX.8b865e19.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.066df28d.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.b53994b4.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.30e6f5af.tar.gz: No such file or directory
mesa-gl-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]
mesa-gles-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]
mesa-gbm-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]
mesa-egl-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]
mesa-dri-freedreno-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]
mesa-glapi-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]
mesa-9999-r1 armv7 {mesa} (MIT SGI-B-2.0 BSL-1.0) [installed]

EDIT: I have installed mesa-dri-swrast and re-symlinked /usr/lib/dri in /usr/lib/xorg/modules/dri, but nothing has changed.

Here is the new Xorg.0.log.

By tallero on 2019-03-25T09:04:54

I was under the impression that hammerhead could use freedreno. I don't have any freedreno capable devices to test this myself. It is strange that xorg doesn't even appear to try to load that driver.

@craftyguy The dri drivers are installed to a different path than where xserver is trying to load them from. Was this intended for some reason?

By ryang on 2019-03-26T12:52:58

@ryang2678 hammerhead gpu should use freedreno.

By tallero on 2019-03-26T15:46:10

Please tell me, this issues will be fixed? Some devices can't play Xorg, like Nexus7.

By Kapper1224 on 2019-04-16T18:07:33

@craftyguy The dri drivers are installed to a different path than where xserver is trying to load them from. Was this intended for some reason?

No that was not intended.

By clayton craft on 2019-04-16T18:31:21

I did not have much time to analyze this right now. But I did just flash a fresh pmbootstrap rootfs with i3wm to the hammerhead, for good measure. It seemed to be stuck at displaying a black screen with _ in the top left corner, then I did something else, and as I was about to shut the device down - several minutes later! - all over sudden i3 appeared. Touch screen is not working, probably because the relevant xf86 package is not installed.

Maybe this datapoint is useful - it seems to load up, but only very slowly. Can others confirm this with other desktops, and does anybody have an idea of what to make from that?

By Oliver Smith on 2019-04-16T22:24:56

I can replicate this issue on the OnePlus One (bacon), running my fork of the kernel. I originally used XFCE to test with, but it also happens with i3. I've been chasing this issue down for some time, so I'm glad to know it's not just me experiencing it. In my experience, something about the newer version of Mesa (particularly related to DRI cursor planes, IIRC) freezes the GPU. The touchscreen doesn't appear to work, because the screen is frozen in a single frame.

I manually built an older version of Mesa, and everything seemed to work okay. I do have an Xorg config file that enables SWCursor and disables PageFlip, so there might be some differences without it.

I've attached several Xorg log files, from the old version of Mesa (18.3.5), and the version in pmaports. In one of them, I manually ran Xorg to get the console output, which includes an assertion failure in Freedreno.

Xorg-oldmesa.log

Xorg-newmesa-noswcursor.log

Xorg-newmesa-swcursor.log

Xorg-newmesa-swcursor-manual.log

By Julian Goldsmith on 2019-04-18T22:10:43

@ollieparanoid & @julian-goldsmith

I've noticed this same behaviour on Nexus 5 with xfce4 for many months now, but with success pictures being posted in that time I thought it was just me.

It seems a screen update isn't possible until the device experiences a period of inactivity (like the period of time that elapses after which the screen dims/locks on other mobile devices). Only after this period of inactivity can the screen be commanded to update, either automatically with msm-fb-refresher, or manually without msm-fb-refresher by a touch/button event. I don't know exactly how long the time period is but 10 mins is usually enough.

On xfce4 (and possibly others) touch does work, but appears not to due to the lack of regular screen updating.

Also, I think the wm may be loading in the expected amount of time but due to no screen update being possible until the necessary inactivity period has elapsed it's not obvious that the wm has loaded until many minutes after the fact.

Interestingly - noticing that the Sony Xperia Z2 (with same/similar SoC) was reportedly working fine, I replicated the x11() portion of the Z2's device APKBUILD file in the Nexus 5's just to test. It works great for approx 1-3 touch events but then the screen bugs out. The wm is also displayed quite quickly as opposed to @ollieparanoid 's i3wm experience mentioned above. Just thought I'd mention in case it proves useful for someone.

By fon eos on 2019-04-19T10:35:41

Thanks for the information @julian-goldsmith and @foneos. Unfortunately, I don't have a good idea how to proceed here, besides contacting the freedreno folks. I'm mostly focused on reviewing patches and pushing the much needed new binary repository forward, so maybe one of you can go down that path?

By Oliver Smith on 2019-04-21T22:25:37

I completely missed this issue somehow. The problem is that since having our own Mesa package, /usr/lib/xorg/modules/dri isn't used anymore while it should be. This means only Wayland DE's work. This is fixed in !359 (merged).

By Bart Ribbers on 2019-05-13T21:20:31

Oh thanks @PureTryOut for jumping in here, glad to hear that

Can somebody quickly try a new installation with the current mesa package, and confirm that this is fixed?

By Oliver Smith on 2019-05-14T20:12:48

I can confirm that the a new installation using the current master works on my Nexus 5. Thanks for fixing.

By Simon Richard Grint on 2019-05-23T18:51:53

What desktop are you using? Currently mesa-dri-freedreno isn't built for armv7, so I don't think it would be using Mesa at all on Xorg.

By Julian Goldsmith on 2019-05-23T18:51:53

Oh wow, I did not realize that we don't have a freedreno package for armv7. Thanks for pointing this out, this is a bug. I'll prepare a patch.

By Oliver Smith on 2019-05-24T22:54:59

!383 (merged)

By Oliver Smith on 2019-05-24T23:04:32