There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:31 UTC (Fri) by intelfx (subscriber, #130118)
In reply to: There are things that do not work on Wayland yet by dskoll
Parent article: What’s new in GTK, winter 2025 edition

> But we don't want anything beyond a 2D desktop.

I thought that Wayland was supposed to have more users than just the LWN subscriber "dskoll". I might be wrong, of course.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:36 UTC (Fri) by dskoll (subscriber, #1630) [Link] (26 responses)

"We" is more than dskoll. It is, I'd wager, the vast majority of computer desktop users. Who especially are uninterested in experimental things when basic existing things don't work.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:42 UTC (Fri) by pizza (subscriber, #46) [Link]

> I'd wager, the vast majority of computer desktop users

The vast, vast majority of "computer desktop users" are using MS Windows and couldn't give two craps what this "Leenux" thing is.

The vast majority of the remaining folks are using MacOS, and similarly couldn't care less.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:42 UTC (Fri) by intelfx (subscriber, #130118) [Link] (24 responses)

Well, then who exactly are the "we" that you are so confidently speaking on behalf of? I highly doubt it's "the vast majority of computer desktop users". The vast majority of said computer desktop users are utterly uninterested in niche applications that want to do weird things with top-level window positioning.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:48 UTC (Fri) by dskoll (subscriber, #1630) [Link] (23 responses)

I'm speaking on behalf of everyone I know who uses a desktop. You claim top-level window positioning is "niche". Do you have data to back that up? If it's so niche, why is it the case that every single desktop environment supports it? Did they misread how "niche" it was?

There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:53 UTC (Fri) by intelfx (subscriber, #130118) [Link] (2 responses)

Good, because I'm speaking on behalf of everyone *I* know who uses a desktop. On behalf of those people, top-level window positioning *is* niche. Whose anecdata is better, and why should we pick yours?

So far, I have seen no indication that "we" is anything more than a rhetorical device. Thus, I will continue to treat it accordingly.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 21:08 UTC (Fri) by daroc (editor, #160859) [Link] (1 responses)

I think that the last few comments along this topic have not added much; let's stop the discussion here unless anyone has something genuinely new and interesting to add.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 21:09 UTC (Fri) by intelfx (subscriber, #130118) [Link]

You're right, sorry. I was happy to discuss and share technical details. This back-and-forth is something I shouldn't have tried to entertain.

There are things that do not work on Wayland yet

Posted Feb 7, 2025 20:55 UTC (Fri) by pizza (subscriber, #46) [Link] (19 responses)

> If it's so niche, why is it the case that every single desktop environment supports it?

Once upon a time, "every single desktop environment" had full root priveleges and any application could freely access the state of any other application.

That doesn't mean that either "feature" was a good idea.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 9:42 UTC (Mon) by paulj (subscriber, #341) [Link] (18 responses)

Note, this no longer seems to be the case for X11.

Least, I can not use xev to snoop on keyboard entry into other windows.

There are things that do not work on Wayland yet

Posted Feb 10, 2025 13:00 UTC (Mon) by pizza (subscriber, #46) [Link] (8 responses)

> Note, this no longer seems to be the case for X11.

xev only cares about events relating to its own window (or the root window). It doesn't report global keypresses or mouse events. However, this global input state is still clearly accessible, as xeyes continues to follow every cursor movement even as xev reports nothing happening.

(Reproduced just now on Fedora 41's GNOME Xorg session)

There are things that do not work on Wayland yet

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

xev should be able to watch any window, given there is the -id argument (and xwininfo to find IDs). Pass it the id of another window and see if you can see the keyboard input. On my system, xev will only receive keyboard events if watching the window it created - not other windows.

I'm just curious what mechanism is stopping xev from watching keyboard events on other windows? Did Xorg fix the X11 keyboard snooping issue? Is the "Security" extension? Is it something else? What are the limitations?

Additionally, I'd love to know what mechanism Seahorse is using. Is it X Security and seahorse is a trusted application somehow (where is that specified?)? Or is it just doing a normal X11 GrabKeyboard call, like any app can do? (E.g. the venerable "xterm" has a "Secure Keyboard" option in its ctrl-<left click> popup menu, which does a GrabKeyboard and enables reverse video so long as it holds - so you can be reasonable sure other X clients can not snoop.

There are things that do not work on Wayland yet

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

Further, googling (with whatever your preferred search engine is) suggests it is not really trivial to capture keyboard input from other applications. The one X11 based solution I can find involves creating a tiny little window and hoping the user doesn't notice it by placing it behind the target window, and catching when the user changes workspace. Xinput can be used to capture keyboard, e.g. xinput test-xi2 --root as a demo, however.

Setting other issues with the X code-base aside (lot of it due to its age?), the keyboard issue surely did not need a "empty the bathtub" approach of itself. Only a few applications need such a capability, and a mechanism to label a trusted set of such securely for the X server surely would have been possible, in terms of protocol.

There are things that do not work on Wayland yet

Posted Feb 11, 2025 17:33 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Only a few applications need such a capability, and a mechanism to label a trusted set of such securely for the X server surely would have been possible, in terms of protocol.

Maybe? But all the X maintainers moved to developing Wayland rather than doing so (and no one has stepped up to continue X maintenance in the interim).

There are things that do not work on Wayland yet

Posted Feb 11, 2025 18:00 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

It's not just the keyboard issue - the underlying driver for Wayland is that about 90% of the X11 core protocol is not used any more, and there's a large number of interacting extensions that have evolved over time and don't play as nicely with each other as you'd like in the areas where they overlap (MIT-SHM with DRI2 and DRI3, Xinerama with RandR, Composite and Damage with core) because people have evolved them independently. The consequence is that you have to "just know" that you must ask DRI3 to do something, not MIT-SHM, or that you should trust Damage over core protocol, because Damage is more precise.

And once you're going as far as removing large chunks of core protocol because they're no longer relevant, resetting extension behaviour to a sane shared state etc, you end up with effectively Wayland. You could have called it X12, but the X11 developers who created Wayland felt that it was sufficiently far from what X11 had become that it would be clearer to give it a whole new name, rather than calling it X Window System version 12.

There are things that do not work on Wayland yet

Posted Feb 11, 2025 18:21 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> rather than calling it X Window System version 12.

It wasn't that it was sufficiently far enough from X11, it was that there had already been an abortive X12 rewrite, and for whatever reason they didn't fancy X13 ...

Cheers,
Wol

There are things that do not work on Wayland yet

Posted Feb 11, 2025 19:51 UTC (Tue) by jem (subscriber, #24231) [Link]

I doubt the abandoned X12 rewrite had anything to do with why a new name was introduced for Wayland. Compare Wayland to the original X11, and you'll find that they are totally different. Yes, X.org has a lot of extensions bolted on that implement parts of how a Wayland implementation works, like compositing window managers and client rendering.

Using the name X12 or X13 would probably have provoked a lot of protests, since Wayland is *not* X. There is not direct lineage from X11 code to Wayland code (Wayland isn't even an implementation, just a specification), Wayland is totally lacking the core of X11, and the X11 and Wayland protocols are totally different, and have different roles. Calling Wayland X12 or X13 is simply wrong, since it is totally incompatible with Core X11.

There are things that do not work on Wayland yet

Posted Feb 11, 2025 18:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Only a few applications need such a capability, and a mechanism to label a trusted set of such securely for the X server surely would have been possible, in terms of protocol.

The problem with X has always been the server itself. It's a huge chunk of code written in an ancient C style, that shares the state across all applications. It also does complicated drawing operations, text rendering, etc.

There is simply no realistic way to make that mess secure. Adding ACLs on top of it is just like adding locks for a knee-high fence. Sun tried that with Solaris Trusted X-Windows thingie ( https://www.filibeto.org/sun/lib/solaris10-docs/trusted-e... ), but nobody really trusted it.

There are things that do not work on Wayland yet

Posted Feb 11, 2025 19:09 UTC (Tue) by farnz (subscriber, #17727) [Link]

There's a side problem that even if you rewrote the codebase in modern C++, Haskell, Rust, or something else, you'd be writing a lot of new code to handle cases that basically don't happen any more, but are required by X11's core protocol (which, after all, is from the 1980s). You'd have to handle 2D acceleration as done in the 1980s (not accelerated by modern GPUs), palette-based colour modes as well as truecolour modes, monochrome pointers, an assumption that sound is a bell controlled by the graphics terminal, pre-Unicode keyboard mapping and more.

And note that XACE tried to add the hooks needed to secure X11, but actually writing policies around those hooks to prevent malicious clients causing trouble, while not blocking off legitimate clients, is a tall order that nobody actually bothered to do; in many respects, being able to run multiple XWayland instances is a simpler solution to get to the same place.

There are things that do not work on Wayland yet

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

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.