Tries to open X11 display on Wayland
Closed this issue · 13 comments
Even when running YaST with QT_QPA_PLATFORM=wayland, it tries to connect to the X server.
By removing the probeX11Display this can be fixed easily.
According to
Line 148 in 5b7a782
Ping.
Ping 2.
Ping 3.
@mvidner or @shundhammer can you check if probing is still needed?
AFAICS this might indeed be outdated these days. As a matter of fact, in my QDirStat I have a different strategy to get a more useful error message than a segfault which is the default if the display cannot be opened:
https://github.com/shundhammer/qdirstat/blob/master/src/Logger.cpp#L325
Yes, this is indeed in the logger which at first seems to be very much out of place, and it's pretty low-tech because it checks an error message for a specific string, but it's a pragmatic approach, and it works.
I am not sure if it can easily be handled the same in the YaST UI since there might be some more restraints, and we might to shut down things properly, but it will probably be worth a try. Maybe it's just a matter of throwing the right kind of exception and let it cascade all the way up to main() or slightly below that, then write an appropriate error message to stderr (it will already be in y2log at that point - just because it's an exception), then exit with an appropriate error code; but without a segfault which was the whole point of that probe function.
As a matter of fact, in my QDirStat I have a different strategy to get a more useful error message than a segfault which is the default if the display cannot be opened:
No! Qt does not segfault (and never did) if it's unable to connect to an X display. What it however did (until Qt 5.9.1 IIRC), was abort.
There's always been a useful error message printed to stderr by libxcb itself. This might not have been the case with the ancient xlib platform plugin, but that is not in use on any supported platform anymore.
Qt does not segfault (and never did) if it's unable to connect to an X display.
It wasn't a segfault, but it crashed with a core dump (after abort() which sends a SIGABRT); otherwise I would not have introduced that change.
What it however did (until Qt 5.9.1 IIRC), was abort.
Yes, that's what we were avoiding. These changes in libqt5-qtbase are relevant, thank you for that!
Sun Oct 8 13:54:30 UTC 2017 - lbeltrame@kde.org
- Update to 5.9.2
* For more details please see:
https://blog.qt.io/blog/2017/10/06/qt-5-9-2-released/
- Drop patches, now upstream:
* 0001-Fix-open-chmod-race-condition-in-QSaveFile.patch
* de63bbd2f806b0219a60775017899cedb121581f.patch
* 0001-Fix-at-spi2-build.patch
* 0001-Fix-Qt5DBusMacros.cmake-for-CMake-3.9.patch
* dont-abort-missing-display.patch
...
-------------------------------------------------------------------
Tue Jul 25 11:13:53 UTC 2017 - fabian@ritter-vogt.de
- Add patch to not abort if no $DISPLAY is available (boo#1050046)
* dont-abort-missing-display.patch
So let's remove probeX11Display.
BTW, a stupid question: How do I get a Wayland session? Does it work in Leap 42.x / 15 / Tumbleweed?
The most non-invasive way is probably a nested kwin_wayland session with:
dbus-launch kwin_wayland --windowed --xwayland &
Then you can start YaST with
QT_QPA_PLATFORM=wayland /usr/lib/YaST2/bin/y2base sw_single qt -
Whether the issue reported here is fixed can be tested quite easily:
DISPLAY= QT_QPA_PLATFORM=wayland /usr/lib/YaST2/bin/y2base sw_single qt -
this should not fail.
Oh btw, if you were trying to avoid an abort you were quite unsucessful. The YUIException thrown by probeX11Display never got caught so it ended up in std::terminate, causing an abort anyway:
terminate called after throwing an instance of 'YUIException'
what(): Can't open display
Aborted
... causing an abort anyway.
You're right. :-|
[testing with Wayland]
Thanks for the tips! This has worked for me on Leap 42.3:
- kwin_wayland says it cannot run Xwayland, but I can simply run
westoninstead. - I need to
zypper install libqt5-qtwayland QT_QPA_PLATFORM=wayland-egl .../y2base ...
Oh btw, if you were trying to avoid an abort you were quite unsucessful. The YUIException thrown by probeX11Display never got caught so it ended up in std::terminate, causing an abort anyway
Back when I rewrote the UI completely in 2006, that was intentional; there was not much useful to do other than to terminate YaST (but without a core dump, of course) in that situation, the idea being that the user obviously explicitly requested a Qt UI, so falling back to NCurses was not desired at that point.