github.com/login flashes the tab to all-grey with some Xorg video drivers

[martinwguy]

Bizarre. On this 32-bit laptop (Acer Aspire 5100), Browser to github.com/login flashes the login box and then makes the whole tab gray, then redisplays the login box then goes all gray forever. Same on 32-bit Debian buster.

The same live image running on a different machine (which has a 64-bit CPU) works fine, so it's not a 32/64-bit issue.

Theory: It depends on the graphics chip and X driver in use,

The laptop has NVidia G72M graphics and Xorg is selecting the nouveau driver, while the other machine has Radeon HD graphics and is using the modeset driver

Experiment: Remove xserver-xorg-video-nouveau, restart X and test.

Result: the Sign In page flashes irregularly circa 1 second between the Sign In page and a gray background. Clicking the username box puts the cursor in there but anything you type is ignored except for making it flash faster. Xorg is using the modeset driver, which says in Xorg.0.log:

(II) modeset(0): [DRI2] DRI driver: nouveau
(II) modeset(0): [DRI2] VDPAU driver: nouveau

which is the same as is used by the nouveau driver. The other machine uses modeset driver with DRI and VDPAU driver r600

Theory: it' depends on the nouveau DRI2 driver

Experiment: Disable the modeset driver, restart X and test. Not so easy, because modeset is part of xserver-xorg-core but we can move /usr/lib/xorg/modules/drivers/modesetting_drv.so to /tmp to disable it.

Result: The github login page now works, and Xorg is selecting the fbdev driver without DRI2.

Conclusion: It's caused by using the nouveau DRI2 module, which exists even when xserver-xorg-video-nouveau is not installed.

Possible fix: remove all accelerated xorg-video drivers (or just nouveau) and disable the modeset driver as above to force everyone to use the fbdev driver. After all, Sugar doesn't benefit much from graphics acceleration as far as I know. Are there video devices that are supported by the other xorg-video drivers but not by the kernel's fbdev?

[martinwguy]

The same happens at the sugarizer Login/New User page. However, if you blindly type your username and password at github, it does let you in, so it-s just a visualization issue.

[martinwguy]

Test images, to see if the bug affects your video card too, are under
https://sunjammer.sugarlabs.org/~martinwguy/test
Feedback is welcome to help isolate and fix the bug

[ghost]

From https://sunjammer.sugarlabs.org/~martinwguy/test/README.txt:

Either way, I would appreciate knowing the outcome and the info from: Ctrl-Alt-F1 (to get to a shell prompt)

I used the Terminal activity, but I think the result is the same.

lspci | grep VGA (to know the video card model)

-bash: lspci: command not found

grep DRI2 /var/log/Xorg.0.log (to know which driver and accelerator Xorg used)

[ 21.315] (II) modeset(0): [DRI2] Setup complete [ 21.315] (II) modeset(0): [DRI2] DRI driver: i965 [ 21.315] (II) modeset(0): [DRI2] VDPAU driver: i965 [ 21.332] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 21.333] (II) Initializing extension DRI2 So, Intel drivers. Both the github and sugarizer webpages worked as expected, with no flashing that I could see.

- Download sugar-live-build_2020-11-05_i386.iso and write it to a USB pen drive e.g. cat *.iso > /dev/sdb; sync

Years ago, even though I really knew better, I copied and pasted a similar example line from /usr/share/doc/syslinux-legacy/usbkey.txt or some such, trashing my root drive. I mostly blamed myself but on reflection realized that an example that included something much less likely to be a real but wrong drive identifier would have helped me too. In that vein I suggest at the very least changing /dev/sdb here to /dev/sdX I should have known better even then. We see incoming would-be participants who know even less about these things. I'd hate it if someone came in trying some of this out only to have trashed their system.

- Reboot the machine from that pendrive

Just to let you know where I am on testing. It's been a long while since I booted sugar-live-build on real hardware, outside of a kvm virtual machine. I did a partial inventory of my various keychain drives yesterday and identified one to use for this and wrote the image to it. I'm not keen often to reboot my daily-driver laptop--usually it holds a great deal of ephemeral state (browser tabs, logged-in sessions, tmux windows with ssh or mosh sessions, etc). Same goes for my desktop. I've got some other hardware kicking around to try this on but, as noted, it's been a while so it'll take me time to remember what I have and where it is and where the various adapters are, etc. One such that was close at hand is the one I report above. Unfortunately, when I tried it yesterday I was reminded that it has wireless hardware that probably requires proprietary drivers not included in the image. So, it wasn't until today where I moved it to someplace I could reach it with an Ethernet cable. I've got all the wifi SSIDs in the house set as hidden. So, even when I get around to machines whose wifi hardware supports Linux, I'll probably have to come up with some wpa_supplicant commands to get it online enough to test. Anyway, hope that helps.

[martinwguy]

On 08/11/2020, Joe ***@***.***> wrote: -bash: lspci: command not found

oops

[ 21.315] (II) modeset(0): [DRI2] Setup complete [ 21.315] (II) modeset(0): [DRI2] DRI driver: i965 [ 21.315] (II) modeset(0): [DRI2] VDPAU driver: i965 [ 21.332] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 21.333] (II) Initializing extension DRI2 So, Intel drivers.

Thanks, that's eliminated another driver that works OK. It may just be with nouveau, but I suspect that enabling fbdev-only may be the "safe" option.

>e.g. cat *.iso > /dev/sdb; sync Years ago, I copied and pasted a similar example, trashing my root drive.

I understand.

I've got some other hardware kicking around to try this on

Well, that would be useful, but not if it's going to take up too much of your time.

wireless hardware that probably requires proprietary drivers

Hmm. On the one hand I'd like to get as much hardware working as possible, but on the other, SLB has "only open source software" as one of its features so I probably can't do much about that. My boot messages also say it's missing some firmware (for Radeon and some network card) but "seems to work". An alternative would be a Ubuntu-style mix, taking pure OSS and piling in prorietary stuff where necessary.

Anyway, hope that helps.

Appreciated. M

[quozl]

My guess is by mixing the now unmaintained combination of kernel and X drivers with 32-bit hardware, you've found a bitrot type of regression that unless someone reports or repairs may never be fixed. Rather than iterate through configuration settings, this kind of problem is better solved at its root, by downgrading kernel and X drivers until it comes good, then using git bisect on the kernel or X to find what change broke it. Then engage with the relevant project to try getting it fixed. It isn't likely to be a problem with Sugar or Sugar Live Build per se. Can be verified by running Epiphany inside an X session instead of Browse and Sugar. You might also consider the version of Metacity in use, as it has a compositor option in some versions. Can be verified by running another window manager.

[martinwguy]

Thanks. I've tried with some other WebKit browsers and other Window Managers:

      nouveau/xfce/Epiphany: Works.
      nouveau/xfce/Midori: Works.
      nouveau/xfce/Surf: Works.
      modeset/xfce/Epiphany: Works.
      modeset/xfce/Midori: Works.
      modeset/xfce/Surf: Works.

      nouveau/enlightenment/epiphany: Works.
      nouveau/enlightenment/Midori: Doesn't load the login page. All white.
      nouveau/enlightenment/Surf: Works.
      modeset/enlightenment/Epiphany: Works.
      modeset/enlightenment/Midori: Flashing between login box and all white
      modeset/enlightenment/Surf: Works.
      fbdev/enlightenment: The WM hangs as soon as you launch xterm.

      nouveau/sugar/Epiphany: Works.
      nouveau/sugar/Midori: Works.
      nouveau/sugar/Surf: Works.
      nouveau/sugar/Browser: Flashing to all gray.
      modeset/sugar/Browser: Flashing to all gray.
      fbdev/sugar/Browser: Works

Which all seems fairly random, but the modeset/enightenment/Midori failure shows that it's not a Sugar-only or Browser-only issue, which leaves the Xorg/kernel DRI2 nouveau driver, depending on how the WM or application use it. Nasty.

this kind of problem is better solved at its root, by downgrading kernel and X drivers
until it comes good, then using git bisect on the kernel or X to find what change broke it.

Yes, but how long do you think that would take? I already have immediate "solutions" to this issue and to the metacity bug (enable only fbdev and build for i386 only), and am trying to assess possible negative impacts of these.
I've never seen a 64-bit box that wouldn't boot a 32-bit system but am told they exist. I'm guessing they are rarer than old 32-bit crates (better info is welcome!). I'm also assuming that the Linux frame buffer, being old, probably works on a wide range of cards, including old ones, and that Sugar can live without DRI2 graphics acceleration..

Getting Debian to update metacity in stable (request already sent; no reply yet) or making Live Build compile that package with the patch... and now - gak! - bisecting Linux back to who-knows-when and maybe also X to isolate a bug in the kernel or X's DRI2 drivers... Sorry, but that's too much!

My objective is to make a working Sugar system that's easy to use for most people on cheap computers, but if that objective recedes into the future faster than I manage to get closer to it, the only thing that makes sense is to give up.

[martinwguy]

OK, now that I've let off steam... ;-)

You might also consider the version of Metacity in use, as it has a compositor option in some versions.

Can you point me where to look? If we can simply turn off use of DRI2 acceleration, that would be even simpler.

[martinwguy]

OK, I've found

gconftool -g /apps/metacity/general/compositing_manager
dconf read /org/gnome/metacity/compositing-manager
gsettings get org.gnome.metacity compositing-manager

of which the first is an obsolete gnome2 thing, dconf seems to be its replacement and gsettings an interface to dconf.

On a Debian buster installation, setting either of the second two to "false" and restarting X, it works OK.
(If you set either to "true" and then to "false", the bug remains until you log out of Sugar and log back in).

On SLB with either metacity-3.30 or metacity-3.34, only gsettings is installed and it says that c-m is false, but the github login box still flashes twice and disappears.
If I install packages dconf-cli and gconf2, dconf agrees with gsettings and gconftool says that compositing_manager is unset. If I set it explicitly to false and restart X, the github login box shows without flashing, but as soon as you click in the Username field, the tab goes gray and stays that way.

So now, between Debian buster's sucrose and SLB build from the same versions of the same packages with, apparently, the same drivers and settings, one can be made to work and the other not. I am out of theories.

But I'm still not happy about feeling the bar being raised each time I find a working solution. I'm not here to be pushed to learn. nor am I here to fix the whole open source world as far upstream as possible.
I'm here to obtain a concrete result that I think would help make Sugar more widely usable, and sugarlabs' support is useful to me only because if I should succeed, the work would benefit worldwide instead of just the few friends I hand out live CDs to.

If other sugarlabs members have other, grander objectives, that conflict with quickly making the Sugar system available to as many people as possible to try easily, then I wish them the best of luck in achieving them.

[quozl]

Know how you feel. I faced similar escalation issues with AbiWord, GTK, Telepathy, Metacity and other things that Sugar depends on. You're right, it can take a while. Fixing the AbiWord problem for instance took me about three weeks full time, and even then the AbiWord project didn't like how I fixed it and so my effort was partially wasted; though I did get to show them why it was the flickering problem was happening. I only started trying to fix it because neither Fedora, Ubuntu, nor Debian were willing to work on it, and the bug had been opened at AbiWord for months.

I'm not trying to raise the bar. Regarding objectives, I can't speak for other Sugar Labs members, and I'm off the oversight board once this election is called. You may need some more patience. There are so few active contributors. It can take a few weeks to get a response from some of them.

Sugar starts Metacity with an explicit disabling of the compositor. See src/jarabe/main.py.

https://github.com/sugarlabs/sugar/blob/master/src/jarabe/main.py#L187

There's no configuration feature in Sugar to change that; you'd have to change the source to test with the compositor enabled. I've not tested the compositing-manager configuration key, but it does appear in metacity:src/core/prefs.c ... though I don't know what priority it has over the command line option.

If changing the compositor, either way, does have an impact, then that points at a problem between GTK, X, and the video card drivers. Like a missing expose event and redraw. Or the recent changes to GTK default stylesheets.

[martinwguy]

On 10/11/2020, James Cameron ***@***.***> wrote: Know how you feel.

Well, I can always just make it work on my own fork as seems most opportune, upload it to sunjammer and point at it from the Wiki. Then if you want to include those fixes in the main SLB you can look at that whenever you feel like it or wait for a more professional solution.

Sugar starts Metacity with an explicit disabling of the compositor. See `src/jarabe/main.py`.

Aha! So I guess Debian starts sugar in some different way, that leaves it possible to enable/disable it. I still don't have a clue though, as it was disabling it that made it work on pure Debian, so it it's always disabled in Live Sugar that should be the same, no? I dunno.

I've not tested the _compositing-manager_ configuration key, but it does appear in metacity:src/core/prefs.c ... though I don't know what priority it has over the command line option.

Thanks, I may look at that too, but don't understand the problem so I'll probably just make it use fbdev to cut the bull's head off, as they say here, so I can look at the few other, hopefully more tractable, problems. Cheers M

[quozl]

Aha! So I guess Debian starts sugar in some different way, that leaves it possible to enable/disable it. I still don't have a clue though, as it was disabling it that made it work on pure Debian, so it it's always disabled in Live Sugar that should be the same, no? I dunno.

It could be the same. You can prove it by starting Terminal and using ps axfww to look for the metacity process and the command line options that were given to it.

Thanks, I may look at that too, but don't understand the problem so I'll probably just make it use fbdev to cut the bull's head off, as they say here, so I can look at the few other, hopefully more tractable, problems. Cheers M

Sure, if you like. It sounds like the problem is specific to the Nvidia hardware. I don't have any of that, so I can't try to fix it further.

[martinwguy]

Trying to isolate the bug more closely...

Theory: It's caused by use of the DRI2 nouveau driver (as it's unlikely to be the VDPAU one, which speeds video decoding)

Experiment: Remove /usr/lib/i386-linux-gnu/dri/nouveau_dri.so and restart X

Result: Xorg.0.log says NOUVEAU(0): [DRI2] DRI driver nouveau but later AIGLX fails to dlopen that file and says "error: unable to load driver nouveau". No further errors are evident and the bug is gone.

Conslusion: The nouveau Xorg driver works and the bug is caused by using the nouveau DRI driver.

As to whether this is a better solution than ripping out all Xorg drivers except fbdev:

• Do accelerated chip-specific drivers really make a significant difference to Sugar or its Actiities?
• Are there any video cards that work with chip.specific drivers but not with fbdev?
• It's known that the accelerated Radeon r660 and Intel i945 DRI drivers work OK, but might there be other chipsets with this problem?

[quozl]

@martinwguy wrote:

• Do accelerated chip-specific drivers really make a significant difference to Sugar or its Actiities?

Thanks for the question.

Yes, very significant. But the change in performance might be invisible if it is an increase from 10 µs to 5000 µS for a typical drawing operation. Animation is the greatest cost, because it repeats. It is best to consider the question from the angle of GTK and other libraries. Sugar delegates all this to GTK. Activities mostly delegate this to GTK, to Pygame (SDL), to GStreamer, or to the WebKit browser library. If there's doubt, I suggest making performance measurements of Sugar and activity startup time, and animation frame rate.

[quozl]

@martinwguy, a recent mailing list thread suggests installing the firmware-linux-nonfree package. This package contains 279 firmware files for Nvidia products. There's also a xserver-xorg-video-nvidia package to try.

[martinwguy]

@martinwguy, a [recent mailing list thread](http://lists.sugarlabs.org/archive/sugar-devel/2021-January/058893.html) suggests installing the _firmware-linux-nonfree_ package. This package contains 279 firmware files for Nvidia products. There's also a _xserver-xorg-video-nvidia_ package to try.

Thanks, I hadn't thought of that as an alternative solution. If I were to make a ISO based on SLB but with various fixes, using non-free software (yuk), the size-reducing hacks hoping to get it under 1GB and so on, and put it up under ~martinwguy, would that be OK with you? M

[quozl]

As you've seen in the mailing list thread, I'm unwilling to use my membership of Sugar Labs to make these packages available for download without reviewing the licenses. If you're happy to do that, I won't stand in your way. It's up to you.