Re: Is there anything missing when forwarding my X11 connections?
Le 09/02/2025 à 20:26, Carsten Haitzler a écrit : using mit-shm is entirely a choice by the x client itself. invariably the right thing to do is try use the mit-shm extension - set up a xshmimage ansds then try xshmattach and see if you get an error. if you do - it's not going to work (not local) so... fall back to ximages (not xshmimages). if the apps are not doing this... that's their problem. they are obviously then clients that will never be cappable of running remotely. Is there any minimalist XShm demo tool? (e.g like an xlogo++ ?)
Re: Is there anything missing when forwarding my X11 connections?
Le 09/02/2025 à 22:08, Vladimir Dergachev a écrit : This reminds me of the difference between ssh -X and ssh -Y options, maybe a look at ssh code will give you ideas. Indeed, ssh has several tricks to make the X11 forwarding with some restrictions between -X and -Y "... too many programs currently crash in this mode ... " (https://manpages.debian.org/bullseye/openssh-client/ssh.1.en.html#X) The code is unfortunately too complex for my skill level :-( https://github.com/openssh/openssh-portable/blob/85b3d68dd931416ede657f371f1d60cdc3a66f34/channels.c#L1300 But I still wonder why in my tests X clients get stuck waiting for the server. Best regards Christophe On Fri, 7 Feb 2025, Christophe Lohr wrote: Hello, Please excuse the naivety of my question; I'm trying to understand how things work. I try to forward a tcp X11 connection to the server's unix socket: $ socat TCP-LISTEN:6001,fork UNIX-CONNECT:/tmp/.X11-unix/X0 Then I can use it: $ DISPLAY=localhost:1 xeyes It works well... but only for simple applications (xlogo xeyes xclock xmessage xnest...) Surprisingly, this does not works for more complex applications (Xephyr wireshark ...) These applications stop, seemingly waiting for an event that doesn't come. Increasing socat's verbosity level doesn't help me to understand, nor does strace ltrace xtrace ... Well, this seems relating to the MIT-SHM extension. My assumption: If the server thinks the client is local (due to the use of a unix socket), it activates the MIT-SHM extension without further preliminary checks (and tries to send ancillary data (shm keys or file descriptor?) via the unix socket?). Right? As a workarround, I have to generate an "untrusted" xauth cookie. Is there a better way? (Note: I'm a fan of network transparency! A next time we'll talk about vsock;-) ) Best regards Christophe
Re: Is there anything missing when forwarding my X11 connections?
Le 09/02/2025 à 20:26, Carsten Haitzler a écrit : using mit-shm is entirely a choice by the x client itself. invariably the right thing to do is try use the mit-shm extension - set up a xshmimage ansds then try xshmattach and see if you get an error. If I guess correctly what's happening with my test: X clients never get this error, and so they wait. Is that it? if you do - it's not going to work (not local) so... fall back to ximages (not xshmimages). if the apps are not doing this... that's their problem. they are obviously then clients that will never be cappable of running remotely.
Re: Is there anything missing when forwarding my X11 connections?
On Mon, 10 Feb 2025 09:47:01 +0100 Christophe Lohr said: > Le 09/02/2025 à 20:26, Carsten Haitzler a écrit : > > using mit-shm is entirely a choice by the x client itself. invariably the > > right thing to do is try use the mit-shm extension - set up a xshmimage > > ansds then try xshmattach and see if you get an error. if you do - it's not > > going to work (not local) so... fall back to ximages (not xshmimages). if > > the apps are not doing this... that's their problem. they are obviously > > then clients that will never be cappable of running remotely. > > Is there any minimalist XShm demo tool? > (e.g like an xlogo++ ?) not that i know of... i've just written plenty of ximage + xshmimage code over the decades so know how it works and know how to do my fallbacks so it keeps working (just more slowly without shm) :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Is there anything missing when forwarding my X11 connections?
On Mon, 10 Feb 2025 09:02:40 +0100 Christophe Lohr said: > Le 09/02/2025 à 20:26, Carsten Haitzler a écrit : > > using mit-shm is entirely a choice by the x client itself. invariably the > > right thing to do is try use the mit-shm extension - set up a xshmimage > > ansds then try xshmattach and see if you get an error. > If I guess correctly what's happening with my test: X clients never get > this error, and so they wait. Is that it? they should... strace would be the next port of call - but i shall assume they are sitting in select/epoll waiting on something. find the simplest app you can that doesn't work and i guess it's time to dig. in fact trying your socat thing here.. a lot of things work. libreoffice works. gedit works. my stuff (that does ximage fallback) works. anything qt does not... in fact... i think i spotted the problem. simplest thing that doesn't work: glxgears i have not dug much, but it seems qt is trying to use gl ... and thus anything using qt is not working. gl is hanging. so there's your core problem... without digging more i can't be sure but getting gl to work remotely these days is not a great idea :) nothing to do with shm. it's opengl. :) > > if you do - it's not going to work > > (not local) so... fall back to ximages (not xshmimages). if the apps are not > > doing this... that's their problem. they are obviously then clients that > > will never be cappable of running remotely. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Is there anything missing when forwarding my X11 connections?
On 2/7/25 07:38, Christophe Lohr wrote: Then I can use it: $ DISPLAY=localhost:1 xeyes Try exporting the DISPLAY environment variable. I've run into programs that do things that work with the variable exported but don't work when it's not exported. -- Grant. . . .
Re: Is there anything missing when forwarding my X11 connections?
Le 10/02/2025 à 11:19, Carsten Haitzler a écrit : If I guess correctly what's happening with my test: X clients never get this error, and so they wait. Is that it? they should... strace would be the next port of call - but i shall assume they are sitting in select/epoll waiting on something. find the simplest app you can that doesn't work and i guess it's time to dig. in fact trying your socat thing here.. a lot of things work. libreoffice works. gedit works. my stuff (that does ximage fallback) works. anything qt does not... in fact... i think i spotted the problem. simplest thing that doesn't work: glxgears i have not dug much, but it seems qt is trying to use gl ... and thus anything using qt is not working. gl is hanging. so there's your core problem... without digging more i can't be sure but getting gl to work remotely these days is not a great idea :) nothing to do with shm. it's opengl. :) I wonder if there aren't two (similar but distinct) problems, one with GLX (or DRI?), the other with MIT-SHM - glxinfo (rather minimalist), seems to wait for some reply : $ DISPLAY=localhost:1 xtrace -n glxinfo ../.. 000:<:0009: 12: GLX-Request(152,19): glXQueryServerString context_tag=0x name=unknown:0x20f6 000:>:0009:40: Reply to glXQueryServerString: string='mesa' 000:<:000a: 12: Request(98): QueryExtension name='GLX' 000:>:000a:32: Reply to QueryExtension: present=true(0x01) major-opcode=152 first-event=95 first-error=158 000:<:000b: 12: Request(98): QueryExtension name='GLX' 000:>:000b:32: Reply to QueryExtension: present=true(0x01) major-opcode=152 first-event=95 first-error=158 000:<:000c: 12: GLX-Request(152,7): glXQueryVersion client_major_version=1 client_minor_version=4 000:>:000c:32: Reply to glXQueryVersion: server_major_version=1 server_minor_version=4 000:<:000d: 12: Request(98): QueryExtension name='DRI3' 000:<:000e: 16: Request(98): QueryExtension name='Present' 000:>:000d:32: Reply to QueryExtension: present=true(0x01) major-opcode=149 first-event=0 first-error=0 000:>:000e:32: Reply to QueryExtension: present=true(0x01) major-opcode=148 first-event=0 first-error=0 000:<:000f: 12: DRI3-Request(149,0): QueryVersion major_version=1 minor_version=2 000:<:0010: 12: Present-Request(148,0): QueryVersion majorVersion=1 minorVersion=2 000:>:000f:32: Reply to QueryVersion: major-version=1 minor-version=2 000:>:0010:32: Reply to QueryVersion: majorVersion=1 minorVersion=2 000:<:0011: 12: DRI3-Request(149,1): Open drawable=0x03e2 provider=0 000:>:0011:32: Reply to Open: nfd=1 ^C $ - Xephyr (not so minimalist but well known) : $ DISPLAY=localhost:1 xtrace -n Xephyr :20 ../.. 000:<:0010: 16: Request(98): QueryExtension name='MIT-SHM' 000:>:0010:32: Reply to QueryExtension: present=true(0x01) major-opcode=130 first-event=65 first-error=128 000:<:0011: 4: MIT-SHM-Request(130,0): QueryVersion 000:>:0011:32: Reply to QueryVersion: major-version=1 minor-version=2 uid=0 gid=0 pixmap-format=ZPixmap(0x02) 000:<:0012: 16: MIT-SHM-Request(130,7): UNKNOWN opcode=0x82 opcode2=0x07 unparsed-data=0x05,0x00,0x40,0x04,0x01,0x00,0x00,0x00,0x01,0x00,0x00,0x00; 000:>:0012:32: unexpected Reply: data1=0x01 data2=0x01 unparsed-data=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00; ^C $ But disabling SHM makes it working (slow, but works): $ DISPLAY=localhost:1 XEPHYR_NO_SHM=true xtrace -n Xephyr :20 - My very first need is for using wireshark (definitively not minimalist, and with Qt) It opens a window, but draws nothing. ... very mysterious to me... Unless there's some other underlying reason?
