There are things that do not work on Wayland yet

Posted Feb 10, 2025 13:19 UTC (Mon) by farnz (subscriber, #17727)
In reply to: There are things that do not work on Wayland yet by paulj
Parent article: What’s new in GTK, winter 2025 edition

xev only snoops on one window at a time - by default, its own window. To snoop on another window, you need to use xev -id $WINDOW_ID, or xev -root to snoop on the root window. Something like xwininfo -tree -root can be used to find all the windows on the system so that you can target your snooping.

X11 has never sent all keyboard events to all clients; the thing that's broken in the X11 model is that I can get the window IDs for all clients, and snoop on any window given that I know its ID.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 13:40 UTC (Mon) by paulj (subscriber, #341) [Link] (7 responses)

See sibling reply. xev -id is exactly the case I was referring to. Try it - it does not receive keyboard input. So... I'm wondering if Xorg server was modified to close that hole, or it's some other accident at play.

However, the Xinput2 extension does seem to expose this hole.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 13:50 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> See sibling reply. xev -id is exactly the case I was referring to. Try it - it does not receive keyboard input. So... I'm wondering if Xorg server was modified to close that hole, or it's some other accident at play.

It's probably the fact that the Xorg server no longer runs as root.

Cheers,
Wol

There are things that do not work on Wayland yet

Posted Feb 12, 2025 2:14 UTC (Wed) by whot (subscriber, #50317) [Link]

On the input side the only effect of the server running as root is that the xorg input driver (xf86-input-foo) can no longer call open() but instead gets the server to open and close the fd via logind. There is zero effect on the event delivery, that is several levels removed from any root/non-root requirements.

Or as an analogy: running grep as root doesn't change how grep's regular expressions work.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 14:06 UTC (Mon) by farnz (subscriber, #17727) [Link] (4 responses)

It absolutely does on my setup as long as I use the right window ID - note that xev does not change the requested event mask on windows belong to applications, so you can't just choose a window ID at random, but must choose one that's requested input.

Monitoring all input is thus a bit of a pain - you have to track all window IDs and monitor the "right" ones.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 14:15 UTC (Mon) by paulj (subscriber, #341) [Link] (3 responses)

Hmm.. can you expand on that? What I'm trying (On Fedora 40) is I use xwininfo in 1 xterm and click on the target xterm. I get the hexadecimal ID from "xwininfo: Window id: <hex id>" near the top, then I run 'xev -id <hex id>'. If I do this:

- xev /does/ receive all MotionNotify events as I move my mouse over the target xterm

- xev does /not/ receive any keyboard events as I type into the target xterm

What method are you using?

There are things that do not work on Wayland yet

Posted Feb 10, 2025 14:55 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

I run xterm, and find its details from xwininfo:


$ xwininfo -tree 

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x3a00012 "user@host:~"

  Root window id: 0x34b (the root window) (has no name)
  Parent window id: 0x20002d (has no name)
     1 child:
     0x3a00021 (has no name): ()  499x316+0+0  +3174+913
        1 child:
        0x3a00026 (has no name): ()  14x316+-1+-1  +3173+912

I then choose the child window of the named window, 0x3a00021, which I happen to know from past experience is the one that's actually receiving keypresses after I click inside the xterm window. Then, with xterm focused by a mouse click, I can type into the xterm and see:


KeyPress event, serial 21, synthetic NO, window 0x3a00021,
    root 0x34b, subw 0x0, time 43084264, (281,284), root:(3455,1197),
    state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
    XLookupString gives 1 bytes: (65) "e"
    XmbLookupString gives 1 bytes: (65) "e"
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0x3a00021,
    root 0x34b, subw 0x0, time 43084309, (281,284), root:(3455,1197),
    state 0x10, keycode 25 (keysym 0x77, w), same_screen YES,
    XLookupString gives 1 bytes: (77) "w"
    XFilterEvent returns: False

Note that I have to take a bit of care here to make sure that I'm looking at the right window in the stack belonging to xterm, and that the exact window that gets input will change depending on how I've focused xterm. A "real" malware would track all windows on the system (same way as xwininfo -root -tree does) and get events for all of them.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 15:13 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Aaaah... it's a child window getting the keypresses. That I had missed. That reproduces for me.

Thanks.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 15:19 UTC (Mon) by farnz (subscriber, #17727) [Link]

Knowing that it's a child window takes some experience of how xterm (unlike more modern applications) works; most applications just have a single window for their entire drawable area, and ask for all the interesting events, handling everything client-side, but xterm is old enough to have been optimized for doing everything over a 10BASE-2 LAN, and thus tries not to get keypress events if it's just going to ignore them.