FS#58962 - [xorg-server] SSH X11 forwarding no longer works for Qt apps
Attached to Project:
Arch Linux
Opened by Laurențiu Nicola (lnicola) - Monday, 11 June 2018, 06:52 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 19 June 2018, 06:23 GMT
Opened by Laurențiu Nicola (lnicola) - Monday, 11 June 2018, 06:52 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 19 June 2018, 06:23 GMT
|
Details
Description:
Trying to run Qt apps over SSH results in black windows, or no window at all. Tested with picard and calibre. Client was GNOME with either Xorg or Wayland (same result). xterm and firefox work fine (but don't use Qt). Setting QT_QPA_PLATFORM=xcb has no effect. |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Tuesday, 19 June 2018, 06:23 GMT
Reason for closing: Fixed
Additional comments about closing: xorg-server 1.20.0-9
Tuesday, 19 June 2018, 06:23 GMT
Reason for closing: Fixed
Additional comments about closing: xorg-server 1.20.0-9
But somebody on IRC mentioned they have the same issue.
Possibly related: https://bugs.archlinux.org/task/58791
sshd_config (3.5 KiB)
qt-ssh.png (11 KiB)
It's been like this for maybe a month or more. I don't do this too often.
FS#58791> @thx1138 do other Qt apps work for you?
I see the exact same behavior with qterminal, where, for instance, xterm works normally. So, yes, this seems to be a more general problem.
Something that may - or may not - be related, a problem - or a symptom - with the radeon driver, but only with one particular bit of hardware, "ATI Radeon HD 5570" (ChipID = 0x68d9), Redwood PRO, which started for me about the same time as this qt app problem: in the log, especially with kde and lxqt, I have repeating errors, often of the form
kernel: radeon 0000:05:00.0: evergreen_cs_track_validate_cb:481 cb[0] bo too small (layer size 15728640, offset 0, max layer 1, bo size 5242880, slice 61439)
kernel: radeon 0000:05:00.0: evergreen_cs_track_validate_cb:485 problematic surf: (3840 1024) (4 4 1 1 2 1024 2)
kernel: radeon 0000:05:00.0: evergreen_packet3_check:1948 invalid cmd stream 666
kernel: [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
Other errors can have the form:
kernel: [ 120.363996] radeon 0000:05:00.0: No GEM object associated to handle 0x0000000C, can't create framebuffer
This sometimes, not always, is associated with display corruption, scanning out memory in the wrong sequence, and losing track of the cursor, or even crashing the machine, with different symptoms every time X is restarted. The openbox window manager, normally used with lxqt is now unusable for me, though kwin sometimes works, with radeon "spamming" the log with gigabytes of repeated errors.
Alex - Alexander.Deucher@amd.com - insists that these errors are most likely mesa errors and not radeon errors: "Those are most likely related to a bug in mesa causing an invalid command stream error in the kernel. Similar to the other command stream parsing errors. Most likely someone made some change to mesa that requires relocation information in the command stream, but they did not update the command stream to include it. Best bet would be to bisect mesa."
My pacman.log has "[2018-04-14 05:04] [ALPM] upgraded mesa (17.3.6-1 -> 18.0.0-3)", which seems about when all these problems started.
So, just a suggestion, if there is any way that mesa could be interacting with X11 networking over ssh when using qt, that would be something to consider.
For instance, Wikipedia expresses: "In contrast, modern versions of X generally have extensions such as MESA allowing local display of a local program's graphics to be optimized to bypass the network model and directly control the video card, for use of full-screen video, rendered 3D applications, and other such applications."
Note that this qt app over X11 networking problem is more general than my radeon driver problem. It is sufficient to ssh to the local machine and then run a qt app on any hardware I have tried. Though, for me, the window is not "black" or absent. Instead, I see a "snapshot" of the underlying desktop at the moment when the window is opened. The window can be moved around on the desktop, but the window contents do not update. I am not seeing any difference between "ssh -Y" and "ssh -X". I have not tried reverting mesa yet.
[2018-06-11 07:57] [ALPM] downgraded wayland (1.15.0-1 -> 1.14.0-1)
[2018-06-11 07:57] [ALPM] downgraded mesa (18.1.1-1 -> 17.3.3-2)
It seems to have fixed my "Invalid command stream" errors, but does not help with the qt app display problem. So these are probably separate issues.
[2018-06-11 08:44] [ALPM] downgraded xorg-server (1.20.0-7 -> 1.19.6-2)
[2018-06-11 08:44] [ALPM] downgraded xf86-video-ati (1:18.0.1-2 -> 1:7.10.0-1)
The qt app problem persists, so probably not an X server issue.
I tried downgrading openssh:
[2018-06-11 09:43] [ALPM] downgraded openssh (7.7p1-1 -> 7.6p1-2)
No change.
I downgraded qt5-base and qt5-x11extras:
[2018-06-11 10:01] [ALPM] downgraded qt5-base (5.11.0-1 -> 5.10.1-8)
[2018-06-11 10:01] [ALPM] downgraded qt5-x11extras (5.11.0-1 -> 5.10.1-1)
That resolves the problem! The downgrade is required on the *remote* end of the ssh connection.
BTW, the new qt5-x11extras 5.11.0-1 somehow lost its qt5-base dependency. The upgrade proceeds, but the parts will not work with qt5-base 5.10. Maybe there is an implicit dependency buried in the other new package dependencies, but that is not good enough to make a lone upgrade work properly. pacman is not psychic.
Is this going upstream?
Upstream is aware of it and a fix is in the works
> BTW, the new qt5-x11extras 5.11.0-1 somehow lost its qt5-base dependency
Partial upgrades/downgrades are not supported. Qt packages should always be upgraded/downgraded simultaneously
That rather "presumes the conclusion", where the constraint "simultaneously" has no meaning in this context.
What exactly do you suppose a "simultaneously" pacman upgrade command would look like for qt5-x11extras?
The whole point of having "dependencies" is to automatically resolve dependency issues. pacman does not know how to follow "simultaneous" dependencies. If and after that feature is added to pacman, *then* you can leave off cascading dependencies. But for now, the mechanism just does not work that way.
See https://bugreports.qt.io/browse/QTBUG-68783
There are some error messages in the console, though:
QXcbShmImage: xcb_shm_create_segment() failed for size 4683096.
I'm not sure those should show up, since I imagine xcb_shm_create_segment() is expected to fail when MIT-SHM is not available. But that's what the Qt code does.
No change here. Qt apps over ssh still do not work.
Ah! The X server must be upgraded on the *local* side. Odd, since downgrading the *remote* qt5 had some effect.
So now, after upgrading the local X server, Qt apps are working normally. I can also say that upgrading the *remote* X server is not needed. This was before the qt 5.11.1 upgrade. But now, I also have the qt upgrade, and it ssh forwarding still works. Problem solved for me.
That's normal. The remote app using Qt is connecting to your local X server. You don't even need X on the remote.