On pond?l? 2. ??jna 2017 13:28:30 CEST Peter Stuge wrote:> Michal Srb wrote: > > In case of DRI3, X server tries to pass file descriptor to the X > > client. That works over the unix socket between X server and SSH > > client, but of course can not be sent further over network. There > > is no way failure can be detected and the communication gets stuck > > forever. > > > > The ideal solution would be if ssh marked the connection as remote. > > Not forwarding/proxying also the fd to the remote SSH client?I am not sure what you are suggesting. The SSH client runs on the same machine as X server and it connects to it using the unix socket. From X server's point of view, the SSH client looks just like any other local X application. Except the fact that features like SHM and file descriptor passing does not work. Even worse, the file descriptors are passed successfully but then ignored. X server can work with both local and remote clients, but not with remote clients that pretend to be local. SSH should mark the connection as remote, so X server knows to not attempt things that can not work remotely. Maybe we could find some workaround that would allow the X server to recognize this specific case (DRI3 fd passing), but it is just matter of time when some new thing fails. Michal Srb
Michal Srb wrote:> > > The ideal solution would be if ssh marked the connection as remote. > > > > Not forwarding/proxying also the fd to the remote SSH client? > > I am not sure what you are suggesting. > > The SSH client runs on the same machine as X serverSorry - I meant the SSH server/X client.> SSH should mark the connection as remote, so X server knows to not > attempt things that can not work remotely.I was suggesting to make them work. But it depends on what the fd is of course. If it's a device handle then I think your suggestion is the only approach that makes sense. //Peter
On pond?l? 2. ??jna 2017 14:56:33 CEST Peter Stuge wrote:> > SSH should mark the connection as remote, so X server knows to not > > attempt things that can not work remotely. > > I was suggesting to make them work. But it depends on what the fd is of > course. If it's a device handle then I think your suggestion is the only > approach that makes sense.It is a device, usually /dev/dri/card0 or similar. Most applications do not really require DRI(3), they just try to use it for direct rendering. If DRI(3) is not available, they will render using other methods which work fine remotely. The same situation was so far with DRI2 or SHM, but attempts to use those at least gave an error, so the application knew to fallback to something else. DRI3 does not fail, the file descriptor just gets lost. Michal