4 ms·

> angling to replace Xorg The Xrandr extension enabling all this functionality is defacto part of the X11 protocol for a long time and not just "Xorg". > Xorg

by sprash 6y ago

> angling to replace Xorg The Xrandr extension enabling all this functionality is defacto part of the X11 protocol for a long time and not just "Xorg". > Xorg could have just added Wayland support You already can run any Wayland client in Xorg with a simple Weston wrapper script. However since X11 supports DRI3 which is as efficient as Wayland will ever be it is completely pointless. > To me this is a good thing Speak for yourself. For me standardization is a good thing. The "Desktop" is essentially a solved problem. There is no reason to invent a new incompatible standard every week. What is happening here is the opposite of standardization.

d110af5ccf 6y ago
> The "Desktop" is essentially a solved problem. Serious question, what are the key differences and tradeoffs between the DRI3 and Wayland APIs? I've done some OpenGL programming, but always in a fully abstracted manner (ie using cross platform wrapper libraries). As a bystander, my impression is that the real issue (outside of refactoring a massive codebase & associated ecosystem on a volunteer basis) is one of security and efficiency. Without reworking the underlying protocol to require compositing, how do you properly sandbox applications from one another? And as long as you're making such a significant overhaul, why not throw out a bunch of cruft and split off any extra functionalities into their own standards? And as long as you're doing all that, why not completely restructure the protocol to handle things like minimized windows updating thumbnails of themselves at an interval determined by the compositor?
- sprash 6y ago
  > Serious question, what are the key differences and tradeoffs between the DRI3 and Wayland APIs? DRI3 gets you a file descriptor which can be used as a DMA-Buffer to directly render and present graphics. The Wayland protocol never clarifies how the compositor is supposed to implement the rendering but in practice the current implementations do exactly the same thing as DRI3 except in the case of GNOME and KDE on proprietary drivers from NVIDIA which use nvm_eglstreams. > As a bystander, my impression is that the real issue is one of security and efficiency. That is correct. As of now X11/Xorg has very broken security. > Without reworking the underlying protocol to require compositing, how do you properly sandbox applications from one another? There are many X11 security protocols already standardized [1,2,3] using access control hooks which lets you sandbox any aspect of your application but no client and/or toolkit ever adopted it. Also the current implementation of xinput invalidates many of those protocols. > And as long as you're making such a significant overhaul, why not throw out a bunch of cruft and split off any extra functionalities into their own standards? Wayland shows in a very painful way that those functionalities are strongly interdependent and untangling them leads only to more protocol overhead. > And as long as you're doing all that, why not completely restructure the protocol to handle things like minimized windows updating thumbnails of themselves at an interval determined by the compositor? That is a very specific problem, however A custom xcompmgr implementation would allow you do that today on X11. 1.: https://www.x.org/wiki/Development/Documentation/Security/ https://www.x.org/wiki/Development/Documentation/Security/ 2.: https://www.x.org/releases/current/doc/xextproto/security.html https://www.x.org/releases/current/doc/xextproto/security.ht... 3.: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserver/XACE-Spec.html https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...
  - d110af5ccf 6y ago
    Thanks for the detailed answer, those security protocols in particular are quite interesting. Regarding rendering callbacks (thumbnails & etc), it's perhaps not as specific a problem as it might seem. In classic OpenGL, the potential to block the render loop (and thus the entire window event system) when placing a swap buffer (ie present) call is incredibly frustrating. Also, particularly on resource constrained devices, an event driven approach can be quite useful (both for performance and battery reasons). It's generally just a much more flexible model overall. You mentioned a custom xcompmgr implementation. I didn't think X11 used a callback model though? Was I mistaken? (Again, I've only ever done cross platform OpenGL code using wrapper libraries. That's always involved a potentially blocking call to swap the buffer at the end of the render loop in my experience.)
zbuf 6y ago
> > Xorg could have just added Wayland support > You already can run any Wayland client in Xorg with a simple Weston wrapper script. However since X11 supports DRI3 which is as efficient as Wayland will ever be it is completely pointless. Far from completely pointless, it sounds useful to run Wayland applications on X11; and could well be a useful contingency or ease to transition. Do you have a link or more detail on which script and how to do this?

by sprash 6y ago

d110af5ccf 6y ago

> The "Desktop" is essentially a solved problem. Serious question, what are the key differences and tradeoffs between the DRI3 and Wayland APIs? I've done some OpenGL programming, but always in a fully abstracted manner (ie using cross platform wrapper libraries). As a bystander, my impression is that the real issue (outside of refactoring a massive codebase & associated ecosystem on a volunteer basis) is one of security and efficiency. Without reworking the underlying protocol to require compositing, how do you properly sandbox applications from one another? And as long as you're making such a significant overhaul, why not throw out a bunch of cruft and split off any extra functionalities into their own standards? And as long as you're doing all that, why not completely restructure the protocol to handle things like minimized windows updating thumbnails of themselves at an interval determined by the compositor?

sprash 6y ago
> Serious question, what are the key differences and tradeoffs between the DRI3 and Wayland APIs? DRI3 gets you a file descriptor which can be used as a DMA-Buffer to directly render and present graphics. The Wayland protocol never clarifies how the compositor is supposed to implement the rendering but in practice the current implementations do exactly the same thing as DRI3 except in the case of GNOME and KDE on proprietary drivers from NVIDIA which use nvm_eglstreams. > As a bystander, my impression is that the real issue is one of security and efficiency. That is correct. As of now X11/Xorg has very broken security. > Without reworking the underlying protocol to require compositing, how do you properly sandbox applications from one another? There are many X11 security protocols already standardized [1,2,3] using access control hooks which lets you sandbox any aspect of your application but no client and/or toolkit ever adopted it. Also the current implementation of xinput invalidates many of those protocols. > And as long as you're making such a significant overhaul, why not throw out a bunch of cruft and split off any extra functionalities into their own standards? Wayland shows in a very painful way that those functionalities are strongly interdependent and untangling them leads only to more protocol overhead. > And as long as you're doing all that, why not completely restructure the protocol to handle things like minimized windows updating thumbnails of themselves at an interval determined by the compositor? That is a very specific problem, however A custom xcompmgr implementation would allow you do that today on X11. 1.: https://www.x.org/wiki/Development/Documentation/Security/ https://www.x.org/wiki/Development/Documentation/Security/ 2.: https://www.x.org/releases/current/doc/xextproto/security.html https://www.x.org/releases/current/doc/xextproto/security.ht... 3.: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserver/XACE-Spec.html https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...
- d110af5ccf 6y ago
  Thanks for the detailed answer, those security protocols in particular are quite interesting. Regarding rendering callbacks (thumbnails & etc), it's perhaps not as specific a problem as it might seem. In classic OpenGL, the potential to block the render loop (and thus the entire window event system) when placing a swap buffer (ie present) call is incredibly frustrating. Also, particularly on resource constrained devices, an event driven approach can be quite useful (both for performance and battery reasons). It's generally just a much more flexible model overall. You mentioned a custom xcompmgr implementation. I didn't think X11 used a callback model though? Was I mistaken? (Again, I've only ever done cross platform OpenGL code using wrapper libraries. That's always involved a potentially blocking call to swap the buffer at the end of the render loop in my experience.)

zbuf 6y ago

> > Xorg could have just added Wayland support > You already can run any Wayland client in Xorg with a simple Weston wrapper script. However since X11 supports DRI3 which is as efficient as Wayland will ever be it is completely pointless. Far from completely pointless, it sounds useful to run Wayland applications on X11; and could well be a useful contingency or ease to transition. Do you have a link or more detail on which script and how to do this?