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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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
Comment by Antonio Rojas (arojas) - Monday, 11 June 2018, 07:39 GMT
Works fine here. Anything relevant in the logs?
Comment by Laurențiu Nicola (lnicola) - Monday, 11 June 2018, 07:42 GMT
No, nothing gets printed to the console.

But somebody on IRC mentioned they have the same issue.
Comment by Antonio Rojas (arojas) - Monday, 11 June 2018, 07:47 GMT
Please attach your server-side sshd_config and client-side ssh_config (remove all private data first)
Comment by Laurențiu Nicola (lnicola) - Monday, 11 June 2018, 07:54 GMT
Attached. I'm using ssh -Y to connect. Note that GTK apps still work.

Possibly related: https://bugs.archlinux.org/task/58791
Comment by Antonio Rojas (arojas) - Monday, 11 June 2018, 08:05 GMT
OK, I can reproduce with 'ssh -Y'. Does it work for you with 'ssh -X'? When did it start failing?
Comment by Laurențiu Nicola (lnicola) - Monday, 11 June 2018, 08:07 GMT
Ah, ok, ssh -X works for me. I was using ssh -Y out of habit, I suppose.

It's been like this for maybe a month or more. I don't do this too often.
Comment by James (thx1138) - Monday, 11 June 2018, 13:44 GMT
>  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.
Comment by James (thx1138) - Monday, 11 June 2018, 14:21 GMT
Hmm - I just tried downgrading mesa, which requires downgrading wayland:
[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.
Comment by James (thx1138) - Monday, 11 June 2018, 15:03 GMT
I have tried downgrading the X server:
[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.
Comment by James (thx1138) - Monday, 11 June 2018, 16:15 GMT
More mucking about with downgrading packages, my radeon problem re-appeared with the mesa downgrade, but tracks the xorg-server package upgrade from 1.19 to 1.20, which also requires the xf86-video-ati upgrade on this radeon hardware - just for reference.

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?
Comment by Antonio Rojas (arojas) - Monday, 11 June 2018, 16:21 GMT
> 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
Comment by James (thx1138) - Monday, 11 June 2018, 16:34 GMT
> 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.
Comment by Laurențiu Nicola (lnicola) - Tuesday, 12 June 2018, 06:44 GMT
For anyone using ssh -Y because ssh -X doesn't work, make sure you've installed xorg-xauth on the client.
Comment by Antonio Rojas (arojas) - Monday, 18 June 2018, 14:45 GMT Comment by Laurent Carlier (lordheavy) - Monday, 18 June 2018, 15:19 GMT
Please check with xorg-server-1.20.0-9 in testing
Comment by Laurențiu Nicola (lnicola) - Monday, 18 June 2018, 15:30 GMT
Works for me with xorg-server-1.20.0-9.

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.
Comment by James (thx1138) - Monday, 18 June 2018, 21:51 GMT
xorg-server 1.20.0-9

No change here. Qt apps over ssh still do not work.
Comment by Laurențiu Nicola (lnicola) - Monday, 18 June 2018, 21:55 GMT
That's on the client, right? You also need to log off and back in. Does ssh -X work for you?
Comment by Laurențiu Nicola (lnicola) - Monday, 18 June 2018, 21:56 GMT
I meant ssh -X.
Comment by Antonio Rojas (arojas) - Monday, 18 June 2018, 22:32 GMT
@thx1138 your issue was likely a different one from the start. Try 5.11.1, it has some other fixes relevant to ssh forwarding.
Comment by James (thx1138) - Monday, 18 June 2018, 22:52 GMT
> That's on the client, right?

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.
Comment by Laurențiu Nicola (lnicola) - Tuesday, 19 June 2018, 05:32 GMT
> Ah! The X server must be upgraded on the *local* side. Odd, since downgrading the *remote* qt5 had some effect.

That's normal. The remote app using Qt is connecting to your local X server. You don't even need X on the remote.

Loading...