PCBSD - Bug #9960 Xinerama Under Nvidia Causes Lumina to Crash 05/25/2015 09:11 PM - JT Pennington

PCBSD - Bug #9960 Xinerama under Nvidia causes Lumina to crash 05/25/2015 09:11 PM - JT Pennington

Status: Closed: Third party to resolve Priority: Expected Assignee: Ken Moore Category: Lumina Desktop Target version: Seen in: Description 1) Installed 10.1.2 with legacy Nvidia driver. 2) Booted into Lumina. 1 screen active 3) Used nvidia-settings to enable another screen and use Xinerama, saved xorg.conf and rebooted.

4) Login window appears, and three screens are on with background. When attempting to log in, The three screens go black, no wallpaper is loaded. The panel attempts to load, it is about 2" wide and only included the user name, time, and the system dashboard button. The Welcome window opens, then about a second later all three screens go black and then it shows the login window again. runtime.log has the following line at the end: Warning: The X11 connection broke (error 2). Did the X11 server die?

Drop to shell, delete /etc/X11/xorg.conf and reboot.

System self selects two screens and sets up xorg.conf for me. Two screens now work but are both using X screen 0. (No Xinerama)

If I set each screen to its own X screen and enable Xinerama, I get the behavior listed above. I can do Xinerama and multiple X screens under KDE on PCBSD 10.1.2 without a problem, so I believe the issue is a Lumina/Fluxbox one. Seems like there is something causing an incompatibility with Xinerama.

History #1 - 05/26/2015 10:20 AM - Ken Moore - Status changed from Unscreened to Investigation - Assignee set to Ken Moore

Look through this right now, but one thing I see right away is this in wm.log: Xlib: extension "RANDR" missing on display ":0". ...other stuff... Fluxbox: XIOError: lost connection to display. That seems to imply that Xorg is missing the RANDR extension, causing the entire X server to crash later on (probably when Fluxbox tries to use an RandR extension call).

In the runtime.log, it ends with something similar (as you mentioned previously): Warning: The X11 connection broke (error 2). Did the X11 server die? Other than that, everything looked fine/normal. This again seems to imply that X11 itself crashed instead of Lumina/Fluxbox.

I am still looking into this right now to see if there is something in the PCDM X11 initialization routine that we can change so this is better supported...

09/28/2021 1/4 #2 - 05/26/2015 10:27 AM - Ken Moore - Status changed from Investigation to 15

Ok, please check your /var/logl/Xorg.0.log file and see if you have a line like this somewhere near the top:

[ 17637.804] Initializing built-in extension RANDR

I have that on my system here, so it seem like the RANDR extension should be supported by the Xserver by default (although I am using an AMD APU at the moment, not an NVIDIA card).

#3 - 05/26/2015 12:10 PM - JT Pennington - File fluxbox-Xorg.0.log added - File kde-Xorg.0.log added - File lumina-Xorg.0.log added - File xorg.conf added

Understanding that I could be completely wrong, I had assumed since KDE is capable of running with xinerama enabled, that the xserver itself was fine. If there was a problem with the xserver; I would, perhaps incorrectly, assumed that KDE would have the same problems as Lumina. In an effort to dig into this a bit further, I went ahead and tested with Fluxbox and it works as expected.

KDE = Xinerama works properly Fluxbox = Xinerama works properly Lumina = Xinerama does not work.

If it is an issue with the Xserver itself, I very curious what it could be. Also, all three of these used the same xorg.conf file, which I will attach.

Also I will attach the Xorg.0.log files from each WM booting.

While poking around in log files to I also found this in /var/log/messages. This corresponds to me logging in/out of KDE and then trying to log into Lumina.

May 26 14:44:43 pcbsd-3992 kernel: pid 1403 (PCDM-session), uid 0: exited on signal 11 May 26 14:44:46 pcbsd-3992 devd: check_clients: dropping disconnected client May 26 14:44:46 pcbsd-3992 last message repeated 3 times May 26 14:44:59 pcbsd-3992 pulseaudio10645: [(null)] oss-util.c: '/dev/dsp2' doesn't support full duplex May 26 14:45:01 pcbsd-3992 kernel: pid 10366 (PCDM-session), uid 0: exited on signal 11 May 26 14:45:01 pcbsd-3992 kernel: pid 10397 (fluxbox), uid 1001: exited on signal 6 May 26 14:45:01 pcbsd-3992 devd: notify_clients: send() failed; dropping unresponsive client May 26 14:45:01 pcbsd-3992 last message repeated 4 times May 26 14:45:09 pcbsd-3992 console-kit-daemon1055: WARNING: Error waiting for native console 1 activation: Device not configured May 26 14:45:09 pcbsd-3992 console-kit-daemon1055: WARNING: Error waiting for native console 9 activation: Device not configured May 26 14:46:05 pcbsd-3992 devd: check_clients: dropping disconnected client May 26 14:46:05 pcbsd-3992 last message repeated 2 times May 26 14:46:39 pcbsd-3992 reboot: rebooted by q5sys

09/28/2021 2/4 #4 - 05/28/2015 11:49 AM - Ken Moore - Status changed from 15 to Investigation

Ok, I am still looking into this but it might be a little bit before I can track down the issue (need to get a multi-monitor system setup for testing....)

#5 - 07/20/2015 11:21 AM - Ken Moore Ok, so I spent a good amount of time working on this and I think I may have found the cause of the problem:

Problem: The Qt screen detection/reporting methods go crazy approximately 1 second after Fluxbox gets started up (they start reporting 0 for everything related to screens - including resolutions and such).

I tracked it down a bit further, and discovered that the Fluxbox package was not built with Xinerama support (at least on FreeBSD/PC-BSD): causing it to "fake" the support and (possibly) causing the issue with the Qt system (which is why it appears to work in Fluxbox itself, but not in Lumina).

I just enabled that build option for the Fluxbox package on the PC-BSD package repositories, and will re-test once I have the new package available.

#6 - 07/28/2015 01:17 PM - Ken Moore - Status changed from Investigation to Closed: Third party to resolve

Update on this bug: I have tested this with the new build of Fluxbox as well as tried a couple other window managers and have narrowed it down to something within Qt5 itself which is causing the problem when the Xinerama extension is enabled. I have worked around some of the screen geometry issues by saving the screen geom structures before starting up the WM and falling back on those saved structures if the current Qt functions do not work, but that just causes the interface to be painted properly but all sorts of other issues (such as trying to popup the menu's) then appear - rendering Lumina completely useless. This seems to imply that there is a deeper issue within Qt5 (tested with 5.4.1) than a simple screen geometry calculation/routine. I am going to punt this bug for now, perhaps a later version of Qt will fix it, but in the meantime I recommend not using Xinerama (all the info I can find on it says it is old/obsolete compared to the RandR protocols anyway). I might add a "fake" Xinerama display to Lumina a bit later (using RandR), so that you can specify that you want one large desktop interface instead of a number of smaller ones. You should probably open up a new feature request about that though.

FYI: It is actually quite simple to reproduce this bug if others want to look into it:

QApplication app(); qDebug() << "Initial Screen Layout:" << app.desktop().screenCount() << app.desktop().screenGeometry(); QProcess proc; proc.start("fluxbox"); //another WM such as openbox will do as well for(int i=0; i<100; i++){ //Monitor status for 20 seconds total usleep(200000); //0.2 second pause each loop app.processEvents(); qDebug() << " - Status["+QString::number(i)+"]:" << app.desktop().screenCount() << app.desktop().screenGeometry(); //Note: the QScreen class in Qt5 exhibits this same error, not just QDesktopWidget } proc.stop(); return 0;

Then compile/run this small app within an "xinit" wrapper to kick off an X session with your designated settings to test it.

09/28/2021 3/4 #7 - 10/13/2015 03:08 PM - JT Pennington - File runtime.log-bak added - File wm.log-bak added - File xorg.conf-bak added

Re-tested this today on a system with two newer Quadro cards and found the same behavior. Only commenting here because I can also confirm in addition that this behavior occurs under the Nvidia's newer 'Base Mosaic' option.

I can run up to three screens fine, once a 4th one gets connected it will no longer start the desktop.

Files wm.log 2.01 KB 05/26/2015 JT Pennington runtime.log 1.88 KB 05/26/2015 JT Pennington fluxbox-Xorg.0.log 21.7 KB 05/26/2015 JT Pennington kde-Xorg.0.log 21.7 KB 05/26/2015 JT Pennington lumina-Xorg.0.log 21.7 KB 05/26/2015 JT Pennington xorg.conf 3.55 KB 05/26/2015 JT Pennington runtime.log-bak 2.18 KB 10/13/2015 JT Pennington wm.log-bak 1.68 KB 10/13/2015 JT Pennington xorg.conf-bak 5.15 KB 10/13/2015 JT Pennington

09/28/2021 4/4