3 ms·

It’s the other way around: on X11, nVidia implements all the standard APIs, so window managers like i3 don’t need driver-specific code. For Wayland, nVidia onl

by secure 7y ago

It’s the other way around: on X11, nVidia implements all the standard APIs, so window managers like i3 don’t need driver-specific code. For Wayland, nVidia only implements the EGLStreams buffer management API, whereas other drivers implement the GBM API. Individual compositors (like sway) need to add support for EGLStreams. See also https://wiki.archlinux.org/index.php/Wayland#Requirements https://wiki.archlinux.org/index.php/Wayland#Requirements

iforgotpassword 7y ago
Oh dear, so right from the start there is unnecessary complication hindering adoption of Wayland in yet another way. After reading your comment I assumed at least all the other drivers would implement EGLStreams too but following your link reveals no, so you couldn't even implement a simple compositor that only supports one. Personally I avoid NVIDIA like the plague, but at work we have to support VMware running with 3d acceleration on all kinds of cards on Linux, including NVIDIA with proprietary drivers. Apart from VMware having announced no plans yet on supporting Wayland this seems like yet another small reason to stay with X11 until the end of time.
makomk 7y ago
Note that Wayland doesn't have a full driver abstraction layer in userland like X does. Every Wayland compositior is expected to call into the Linux kernel drivers for the graphics card directly. GBM is just a thin wrapper that hides the fact that Linux never standardised the buffer creation interface across different hardware - it assumes that all those driver-specific interfaces wrap essentially the same shared Linux buffer management code, and it doesn't abstract stuff like modesetting at all. NVidia managed to reimplement enough of the Linux modesetting interface that existing code mostly works, but their own buffer management infrastructure is apparently different enough that they couldn't make it look like the one existing Wayland compositors are expecting to use. So they ended up creating their own slightly higher-level API instead.

by secure 7y ago

iforgotpassword 7y ago

Oh dear, so right from the start there is unnecessary complication hindering adoption of Wayland in yet another way. After reading your comment I assumed at least all the other drivers would implement EGLStreams too but following your link reveals no, so you couldn't even implement a simple compositor that only supports one. Personally I avoid NVIDIA like the plague, but at work we have to support VMware running with 3d acceleration on all kinds of cards on Linux, including NVIDIA with proprietary drivers. Apart from VMware having announced no plans yet on supporting Wayland this seems like yet another small reason to stay with X11 until the end of time.

makomk 7y ago

Note that Wayland doesn't have a full driver abstraction layer in userland like X does. Every Wayland compositior is expected to call into the Linux kernel drivers for the graphics card directly. GBM is just a thin wrapper that hides the fact that Linux never standardised the buffer creation interface across different hardware - it assumes that all those driver-specific interfaces wrap essentially the same shared Linux buffer management code, and it doesn't abstract stuff like modesetting at all. NVidia managed to reimplement enough of the Linux modesetting interface that existing code mostly works, but their own buffer management infrastructure is apparently different enough that they couldn't make it look like the one existing Wayland compositors are expecting to use. So they ended up creating their own slightly higher-level API instead.