Why does a window manager developer have to support specific graphics hardware in Wayland? Isn't abstracting away that kind of detail the first responsibility of a windowing system and/or framebuffer manager?
Wayland does not have the "window manager" concept. The compositor (which, for the lack of a better term, well, composites windows) implements the display server protocol as well. It creates and hands off surfaces to the clients, and those clients directly render their contents there. So it's somewhat akin to a window manager + some display server parts.
(Note: I have written very little Wayland-related code, and quite some time ago, so do not put too much faith in the explanation below).
Managing device-accessible surfaces is very obviously hardware-specific, so it was abstracted behind a number of mechanisms. One of these is the GBM API, which is implemented (classically) by everyone except NVIDIA, and is the API that sway is going to use.
NVIDIA's proprietary drivers do not support GBM, and NVIDIA is pushing for its own solution called EGLStream. EGLStream does solve several problems that GBM has, but it seems to me that what makes it most attractive to NVIDIA is that it is theirs (it is an open standard but has only one serious commercial implementation, on a single vendor's devices, so at this point it might as well be closed). If you are curious, there is a wider discussion on the topic here: https://lwn.net/Articles/703749/ .
This is very useful context, thanks. I hope things standardize quickly, because having to worry about whether your terminal emulator is compatible with your desktop environment is compatible with your graphics card and kernel seems like it'd be a huge step backward for the Linux desktop. Xorg has been something I haven't had to even think about for the better part of a decade now, and that's the way it should be.
As GP has written: sway is a compositor not a window manager. Wayland compositors are like X11 server + X11 window manager. They use kernel interfaces directly.
