3 ms·

Qt and GTK and responsible for implementing how all of their windows talk to each other. My point is that it is not reasonable to expect or require programs to

by hyperion2010 9y ago

Qt and GTK and responsible for implementing how all of their windows talk to each other. My point is that it is not reasonable to expect or require programs to depend on a widget toolkit just so they can get proper keyboard input. I realize this is a bit of an exaggeration, but X11 is more than something that draws windows and from my understanding wayland doesn't address many of the other parts. For example, from my understanding wayland does not provide a standard way to support window manager level keybinds that override the binds set by the developer of the window that currently has focus. For me this means that the primary way I interact with my computer is now broken on wayland unless every single program I use implements the ability to pass those custom keybinds to the program that actually handles them. Sure, everyone can implement their own way of dealing with window manager level keybinds but that completely defeats the purpose of having a standard in the first place. Probably the most salient issue with wayland is that it prevents programs from communicating with each other in the name of 'security' and 'sandboxing' when preventing those things at the display server level adds literally zero security and just makes everything more painful for application developers (imo to the point where they simply won't touch the stuff). If there were a 'windowing protocol' that went along with wayland that covered many of the things wayland does not then I do not think there would be as much of an issue, but the thought that we can force a new display server on people without the other bits as well seems at best naive. Again, I think that the absence of such a 'windowing protocol' from wayland is because one of the main use cases it was developed for often had literally one program running (car backup camera displays). I do not dispute that xwayland bridges the gap. But if people are using X right now then nvidia has no reason to support xwayland right now because there are no wayland only applications that their customers are demanding support for. Down the line that may change, but from a corporate decision making point of view there is zero reason to do this.

microcolonel 9y ago
> Qt and GTK and responsible for implementing how all of their windows talk to each other. My point is that it is not reasonable to expect or require programs to depend on a widget toolkit just so they can get proper keyboard input. You don't need to. Just like X11 has Xlib and libxcb, Wayland has libwayland. It is actually easier to get input from libwayland than it is to get it from Xlib, and about on par with libxcb. > I realize this is a bit of an exaggeration, but X11 is more than something that draws windows and from my understanding wayland doesn't address many of the other parts. For example, from my understanding wayland does not provide a standard way to support window manager level keybinds that override the binds set by the developer of the window that currently has focus. You're right about that, global keybindings will have to be allowed through the compositor, and I don't know if there's a protocol for that yet. Global keylogging is one of the things Wayland was designed to avoid, so the way we implement that feature will have to be a bit different. It's for good reasons though. > For me this means that the primary way I interact with my computer is now broken on wayland unless every single program I use implements the ability to pass those custom keybinds to the program that actually handles them. Sure, everyone can implement their own way of dealing with window manager level keybinds but that completely defeats the purpose of having a standard in the first place. I don't know that it defeats the purpose of a standard! I agree that these use cases need to be addressed, but I don't think the way to do that is to give every Wayland client the ability to globally change the way input reaches other clients without permission from the compositor. > Probably the most salient issue with wayland is that it prevents programs from communicating with each other in the name of 'security' and 'sandboxing' when preventing those things at the display server level adds literally zero security and just makes everything more painful for application developers (imo to the point where they simply won't touch the stuff). Yeah, I think that the XDG compositor extensions should loosen this stuff up a bit, or at least make it easy for an application to ask the user for permission to spoof everything. I'm unlikely to be displaying a hostile application on my machine. That said, doesn't exactly add "zero security" though. It is helpful for partially-isolated applications, like those in containers. I would like to be able to trust the isolation of applications some day so that I can run spotify on my workstation without breaking into a sweat. I think it would be perfectly adequate to have the application ask for permission to do the heinous boundary violations that make X11 fun and dynamic. > I do not dispute that xwayland bridges the gap. But if people are using X right now then nvidia has no reason to support xwayland right now because there are no wayland only applications that their customers are demanding support for. Down the line that may change, but from a corporate decision making point of view there is zero reason to do this. For what it's worth, NVIDIA is looking to support Wayland on desktop. They already support it commercially in their embedded products (especially targeted toward automotive). So it's not exactly accurate to say that they have no customers asking for Wayland-only application support. The question is, when will it be convenient on desktop Linux? and that's hard to say. It is somewhat surprising that they aren't currently planning to support acceleration in XWayland, given that they have at least put some effort into supporting Wayland in general.

microcolonel 9y ago

> Qt and GTK and responsible for implementing how all of their windows talk to each other. My point is that it is not reasonable to expect or require programs to depend on a widget toolkit just so they can get proper keyboard input. You don't need to. Just like X11 has Xlib and libxcb, Wayland has libwayland. It is actually easier to get input from libwayland than it is to get it from Xlib, and about on par with libxcb. > I realize this is a bit of an exaggeration, but X11 is more than something that draws windows and from my understanding wayland doesn't address many of the other parts. For example, from my understanding wayland does not provide a standard way to support window manager level keybinds that override the binds set by the developer of the window that currently has focus. You're right about that, global keybindings will have to be allowed through the compositor, and I don't know if there's a protocol for that yet. Global keylogging is one of the things Wayland was designed to avoid, so the way we implement that feature will have to be a bit different. It's for good reasons though. > For me this means that the primary way I interact with my computer is now broken on wayland unless every single program I use implements the ability to pass those custom keybinds to the program that actually handles them. Sure, everyone can implement their own way of dealing with window manager level keybinds but that completely defeats the purpose of having a standard in the first place. I don't know that it defeats the purpose of a standard! I agree that these use cases need to be addressed, but I don't think the way to do that is to give every Wayland client the ability to globally change the way input reaches other clients without permission from the compositor. > Probably the most salient issue with wayland is that it prevents programs from communicating with each other in the name of 'security' and 'sandboxing' when preventing those things at the display server level adds literally zero security and just makes everything more painful for application developers (imo to the point where they simply won't touch the stuff). Yeah, I think that the XDG compositor extensions should loosen this stuff up a bit, or at least make it easy for an application to ask the user for permission to spoof everything. I'm unlikely to be displaying a hostile application on my machine. That said, doesn't exactly add "zero security" though. It is helpful for partially-isolated applications, like those in containers. I would like to be able to trust the isolation of applications some day so that I can run spotify on my workstation without breaking into a sweat. I think it would be perfectly adequate to have the application ask for permission to do the heinous boundary violations that make X11 fun and dynamic. > I do not dispute that xwayland bridges the gap. But if people are using X right now then nvidia has no reason to support xwayland right now because there are no wayland only applications that their customers are demanding support for. Down the line that may change, but from a corporate decision making point of view there is zero reason to do this. For what it's worth, NVIDIA is looking to support Wayland on desktop. They already support it commercially in their embedded products (especially targeted toward automotive). So it's not exactly accurate to say that they have no customers asking for Wayland-only application support. The question is, when will it be convenient on desktop Linux? and that's hard to say. It is somewhat surprising that they aren't currently planning to support acceleration in XWayland, given that they have at least put some effort into supporting Wayland in general.