Announcement

Collapse
No announcement yet.

SDL Developers Weigh Reverting Wayland Over X11 For SDL 3.0

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MrCooper
    replied
    Originally posted by ssokolow View Post

    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by MrCooper View Post
    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.)
    Last edited by ssokolow; 31 March 2024, 10:16 AM.

    Leave a comment:


  • MrCooper
    replied
    Originally posted by ssokolow View Post

    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.

    Leave a comment:


  • Magissia
    replied
    Originally posted by TemplarGR View Post
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by t1r0nama View Post
    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.

    Currently, client asks for the 32 bit libraries installed. In distributions where this is not available (Centos 7), client will not load.

    Please provide a 64-bit Steam package, so that those of us on 64-bit distros don't have to install a gazillion 32-bit packages. (Ubuntu 12.04 64-bit here.)


    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.

    Leave a comment:


  • t1r0nama
    replied
    Originally posted by Blademasterz View Post

    anyone but you cares XD
    btw, which apps?
    steam for example.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by MrCooper View Post
    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.)

    Leave a comment:


  • MrCooper
    replied
    Originally posted by gufide View Post
    At this point would it make sense to implement the protocols, but fallback to X11 if those protocols are not implemented (aka you use gnome)?
    The protocols haven't landed in wayland-protocols yet, no compositor or client can support them before that happens.

    There are WIP mutter implementations of these protocols though (per the wayland-protocols governance process), so no clue where "except GNOME" is coming from. GNOME will most certainly be one of the early adopters of these protocols.​

    Originally posted by Lysius View Post
    How can XWayland get around those problems without the proposed new protocols? It obviously must have some way, otherwise using X11 (via XWayland) as default over native Wayland would not have any advantage on Wayland systems.
    Good question.

    Xwayland uses Wayland frame events for synchronizing presentation to the refresh cycle, and a fallback 1 Hz timer for cases when the compositor doesn't send frame events (mostly when the window isn't visible anywhere).

    In principle, Mesa could do the same thing itself. The problem is that doing so requires either blocking in Vulkan/GL API calls which aren't supposed to block, or offloading some work to a separate thread (which can't be done reliably for anything which requires committing Wayland surface state).

    With Xwayland, all of that is handled by it, so Mesa on the client side doesn't need to deal with it.​

    Originally posted by ssokolow View Post

    The compositor developers special-case it. The relevant APIs aren't available to other processes and, if you discover a way to get access to them, it's considered a hole/vulnerability to be patched.
    Nope, this doesn't require any special-casing for Xwayland in the compositor.​

    Leave a comment:


  • woddy
    replied
    Originally posted by t1r0nama View Post

    I do not care about HDR. I do not even have a screen that supports HDR. But i do have a screen and i want to display my apps on it, which wayland can't. It does not have basic functionality after 16 years of development. WTF?
    I understand you don't care about HDR, I don't care either, but my apps work great on wayland.
    Again, I understand that for some use cases wayland is still not good, which is why all distributions (or almost all) still offer a session with Xorg, but claiming that applications don't work in wayland is an exaggeration unless you refer to particular applications.

    Leave a comment:


  • Blademasterz
    replied
    Originally posted by t1r0nama View Post

    I do not care about HDR. I do not even have a screen that supports HDR. But i do have a screen and i want to display my apps on it, which wayland can't. It does not have basic functionality after 16 years of development. WTF?
    anyone but you cares XD
    btw, which apps?

    Leave a comment:

Working...
X