|
Bugzilla – Full Text Bug Listing |
| Summary: | Yast2 does not start under Wayland on Leap 15.0 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Joerg Roedel <jroedel> |
| Component: | YaST2 | Assignee: | Josef Reidinger <jreidinger> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | fcrozat, fvogt, hpj, jreidinger, lnussel, mvidner, nickfrom22nd, sreeves |
| Version: | Leap 15.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/JO64JjnP | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Joerg Roedel
2018-03-05 09:09:30 UTC
Martin, an idea? I only know https://github.com/libyui/libyui-qt/pull/76 but luckily enough, https://github.com/openSUSE/branding/pull/68 is linked from it which may point at the current problem. from an IRC chat in the factory channel the following is needed: - yast needs to switch to gui not only for $DISPLAY but also WAYLAND_DISPLAY - a new pam module or pam_xauth patches - the pam module needs to create and set XDG_RUNTIME_DIR for the target user - the pam module needs link the wayland socket of the origin user to the runtime dir of the target user a proper solution would need to revive SCR and separate UI from the backend :) It's also necessary to set QT_QPA_PLATFORM=wayland if (only) WAYLAND_DISPLAY is set to force Qt to use the wayland platform plugin. This should be done in a YaST startup script AFAICT. Why doesn't Qt do that by default? Anyways $DISPLAY would be exported if bug 1084737 leads to using xauth for Xwayland. (In reply to Ludwig Nussel from comment #6) > Why doesn't Qt do that by default? I don't know either. Until recently, the XCB plugin did actually abort() when connection failed, maybe that's why they didn't implement it yet. AFAIK this is planned for Qt 5.11 - maybe we can backport it. The question is: Do we want that? It would result in Qt applications on GNOME Wayland to use wayland instead of using Xwayland, which is a pretty big behaviour change. So I don't think so. > Anyways $DISPLAY would be exported if bug 1084737 leads to using xauth for > Xwayland. (In reply to Fabian Vogt from comment #7) > (In reply to Ludwig Nussel from comment #6) > > Why doesn't Qt do that by default? > > I don't know either. Until recently, the XCB plugin did actually abort() > when connection failed, maybe that's why they didn't implement it yet. > AFAIK this is planned for Qt 5.11 - maybe we can backport it. > > The question is: Do we want that? > It would result in Qt applications on GNOME Wayland to use wayland instead > of using Xwayland, which is a pretty big behaviour change. What's the benefit from running Qt apps under GNOME Wayland through the X compat layer? (In reply to Ludwig Nussel from comment #8) > (In reply to Fabian Vogt from comment #7) > > (In reply to Ludwig Nussel from comment #6) > > > Why doesn't Qt do that by default? > > > > I don't know either. Until recently, the XCB plugin did actually abort() > > when connection failed, maybe that's why they didn't implement it yet. > > AFAIK this is planned for Qt 5.11 - maybe we can backport it. > > > > The question is: Do we want that? > > It would result in Qt applications on GNOME Wayland to use wayland instead > > of using Xwayland, which is a pretty big behaviour change. > > What's the benefit from running Qt apps under GNOME Wayland through the X > compat layer? Many: 1) Not hitting missing features in the compositor 2) Not hitting missing features in the client 3) Not hitting missing features in the protocol (middle click paste?) 4) Not hitting protocol incompatibilities 5) Not hitting other behaviour changes - Qt applications will look different as the X font settings aren't used anymore, for instance Also, some applications might unconditionally expect an X connection, which means they just crash. Many applications (like YaST) didn't account for wayland which can result in missing window icons. Apart from comment #3 and comment #5, is there anything else that YaST needs to implement? In which exact circumstances should it do so? (In reply to Lukas Ocilka from comment #10) > Apart from comment #3 and comment #5, is there anything else that YaST needs > to implement? In which exact circumstances should it do so? Right now, nothing. There might be a point in the future when xdg-su is no longer the appropriate tool in the .desktop file, but for now (with the Xauthority patches for mutter and kwin_wayland) it works fine again. I guess you still want to add the check WAYLAND_DISPLAY in parallel to DISPLAY Just remember that it will still need to keep working with X11. This affects $DISPLAY vs. $WAYLAND_DISPLAY as well as using xdg-su; we still have to take desktops other than KDE / Plasma 5 / GNOME into account (Xfce, LXDE, Enligthenment and all the simpler, window-manager-only desktops). *** Bug 1086758 has been marked as a duplicate of this bug. *** note: I tested it now with plasma session with wayland and works without any modification. But it is true, that plasma have DISPLAY and also WAYLAND_DISPLAY defined. fix is in review: https://github.com/yast/yast-yast2/pull/720 notes from manual testing. xdg-su does not work for me, when DISPLAY is not defined. when Xwayland run, it also define DISPLAY and everything works even without patch. when only WAYLAND_DISPLAY is defined, then it works only with this patch and without using xdg-su. Screenshot from such run is in above mentioned pull request. and fix merged. Regarding that xdg-su if you know better alternative that works in both env and we want to support it for serious amount of time, then we can replace all entries in desktop files that use it. so overall fixed and if you want use for xdg-su own bug report. |