4 ms·

> 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-Bu

by 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.)

by sprash 6y ago

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.)