SDL Developers Weigh Reverting Wayland Over X11 For SDL 3.0

[ssokolow]

Nope, this doesn't require any special-casing for Xwayland in the compositor.

Given what a struggle (still ongoing) it's been to get a means allow Wayland applications to request to position their windows relative to each other, and how X11 applications fundamentally rely on that behaviour for things like menus and tooltips, I'm going to say "citation needed" for rootless XWayland not requiring special-casing.

(For the xdg-pip protocol proposal, there are people who want to build the browser's picture-in-picture window entirely in the compositor, supporting only controls defined in the protocol, to ensure that applications can't abuse it as a means to bypass Wayland's hardline stance on applications choosing how their windows get managed.)

[t1r0nama]

anyone but you cares XD
btw, which apps?

steam for example.

[oiaohm]

steam for example.

Not a good example. Steam you get into what is called valve time that never exactly good.

You are running a HDR game by steam you end up needing wayland. Valve is one of the few parties to make an application that is both X11 and Wayland at the same time.

Remember Steam binary on all other platforms other than Linux is 64 bit. That right we are stuck with 32 bit steam binary on Linux.

https://github.com/ValveSoftware/steam-for-linux/issues/3518

https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-267790879

The reason why steam binary by valve is so legacy is to from valve point of view is to force linux distributions to keep legacy interfaces so they can distribute legacy games without having to do new compatibility interfaces.

Do note steam binary is full testing with Xwayland so they are not forcing usage of bare metal X11 server.

Its really simple to forgot Valve sells lots of software to people want that are legacy software that nobody can update because the source code of that software has totally be lost to the sands of time with the legal state of the license in levels of questionable.

Steam binary will most likely be one of the last application on Linux to still be 32 bit that users are installing and will most likely be one of the last applications to be updated fully to Wayland this is just how Valve works. Please note fully to wayland. Valve wacky nature also means valve is one of the few parties that going todo hybrid X11/Wayland applications as in application running in both Wayland and X11 at the same time. Most parties are not going to do the hybrid X11/Wayland applications. Valve with steam is one of these really wacky exceptions in so many ways.

[Magissia]

Xorg trolls, do not celebrate yet.... Issues like this are GOOD, because they lead to the implementation of new protocols to solve them.... Eventually Wayland will be a rock solid default for SDL 3.0 . No matter how much you spread FUD and troll against Wayland, Xorg is dead. Deal with it.

Sure, I'm waiting for wayland to be good and not annihilate productivity.

[MrCooper]

Given what a struggle (still ongoing) it's been to get a means allow Wayland applications to request to position their windows relative to each other, and how X11 applications fundamentally rely on that behaviour for things like menus and tooltips,

That's not what Lysius asked about in https://www.phoronix.com/forums/foru...e3#post1452522 . They asked why the issues described in the article don't affect Xwayland. That's what "this" refers to in what you quoted from my post.

You claimed in https://www.phoronix.com/forums/foru...e3#post1452526 that it's due to special treatment of Xwayland by the Wayland compositor, which is incorrect.

I'm going to say "citation needed" for rootless XWayland not requiring special-casing.

Even for window placement, there's no special Wayland functionality available only to Xwayland, as you claimed in your post referenced above. It happens by way of the Wayland compositor acting as the X window manager.

[ssokolow]

Even for window placement, there's no special Wayland functionality available only to Xwayland, as you claimed in your post referenced above. It happens by way of the Wayland compositor acting as the X window manager.

Ahh, so the "special casing" is that only X11 has the APIs to request window positioning and the X11 APIs can't see Wayland windows to manipulate them... a fair distinction, but I'm not sure it makes much difference to end users, given that building an X11 window manager into the Wayland compositor looks like special-casing to the lay person.

When people ask about XWayland, they tend to be thinking about it more along the lines of "if rootless XWayland isn't special, it must be doing something like the 'fullscreen shaped window' trick that VirtualBox's rootless mode uses to punch holes wherever the VM's bare desktop would show through. Why can't a Wayland app do that to achieve positioning?" (Yes, that's what VirtualBox appears to be doing with the help of the guest extensions to identify "bare desktop". You can tell because all the virtual machine's windows act as a single window in the host WM's stacking order.)

[MrCooper]

Ahh, so the "special casing" is that only X11 has the APIs to request window positioning and the X11 APIs can't see Wayland windows to manipulate them... a fair distinction, but I'm not sure it makes much difference to end users, given that building an X11 window manager into the Wayland compositor looks like special-casing to the lay person.

A Wayland compositor can't really not perform X window manager duties for rootless Xwayland. It could in principle ignore positioning requests by X clients (just like any X window manager could on other X servers), I suspect most compositors will heed them though.