3 ms·

Absolutely fascinating. Some questions... Would this mean that window managers themselves would have to be re-implemented in order to support the Wayland prot

Absolutely fascinating. Some questions... Would this mean that window managers themselves would have to be re-implemented in order to support the Wayland protocol? Is anyone working to create a non-reference optimized implementation of libwayland? Have the Wayland developers said anything about supporting multiple monitors yet?

exDM69 14y ago
> Would this mean that window managers themselves would have to be re-implemented in order to support the Wayland protocol? Yes, an a lot more than that will have to be partially or fully rewritten. Thankfully, many if not most desktop apps use a widget toolkit like GTK+ or Qt for UI, so it's enough to make the widget toolkits work on Wayland.
makomk 14y ago
Yep, the Wayland developers' solution to window management is for anyone who wants a different window manager to replace Wayland with a different compositor+window manager speaking the same protocol. Their suggested way of supporting proprietary graphics drivers is also replacing the compositor+window manager with one specific to that hardware which speaks the Wayland protocol, sort of like in the early days of X when there was a seperate X server binary for every piece of hardware. So your window management choices under Wayland depend on which graphics drivers you're using.
- 0x0 14y ago
  Wow, does that mean you could end up with a "KDE-only" nvidia driver and a "GNOME-only" ATI/AMD driver?
- JoshTriplett 14y ago
  Not quite. Wayland itself doesn't require any graphics-driver-specific code; it uses the standard kernel interfaces and graphics stack (Mesa, DRI, libdrm, KMS, etc). That also works fine with radeon and nouveau, and it would work fine with the proprietary drivers as long as they support the standard graphics stack. It just won't work with proprietary drivers that implement their own entirely un-integrated graphics stack, which seems unsurprising to me. Your window manager of choice can just link into Wayland/Weston and ignore all the underlying graphics driver bits; they'll Just Work.
  - tedunangst 14y ago
    It's been years and years since I knew the details, but at one point the nvidia drivers replaced pretty everything from libX11 down, and I don't think you could hook in at a middle point. (ie, they don't support the "standard" graphics stack.) Would appreciate if anyone could comment on how things stand today.
    - JoshTriplett 14y ago
      Somewhat better, but still awful. They don't replace libX11, but they do replace libGL, and they bypass the entire kernel graphics stack in favor of their own.
  - wmf 14y ago
    You're describing how it should work, but AFAIK the proprietary drivers don't support KMS and have even talked about never supporting it. But rather than hacking Weston to support proprietary drivers, I would advocate using it as a carrot to beat AMD/Nvidia into submission.
- alexlarsson 14y ago
  While its true that a new "WM" in wayland would be a diffent binary its not really the same as a different X server. All the stuff that X does wrt hardware and stuff is not really in the wayland compositor, but in the drivers, and they are the same with both WMs. And the WMs would link to the wayland server library, so a lot of code would be shared between them. I don't think properietary drivers need to have their own wayland server. However, they do need to add EGL support, so that wayland can use the driver outside of X, and a few specific GL extensions that wayland needs. See e.g: http://ppaalanen.blogspot.fr/2012/03/what-does-egl-do-in-wayland-stack.html http://ppaalanen.blogspot.fr/2012/03/what-does-egl-do-in-way...
alexlarsson 14y ago
libwayland being a reference implementation does not mean its not implemented. It just means that the specified thing is the protocol, not the library API. This is similar to libX11, its just a reference implementation, and other implementations like escher (a pure java X11 protocol implementation) exists. Most wayland servers will still use libwayland. There is nothing special about multiple monitors in wayland. The KMS/Mesa drivers allows setup and rendering to multiple monitors fine, then its up to the wayland server to decide what to draw on each monitor.
- wmf 14y ago
  then its up to the wayland server to decide what to draw on each monitor This is the kind of "mechanism without any policy" thinking that I was hoping to escape from. What does Weston actually do in the presence of multiple monitors?

exDM69 14y ago

> Would this mean that window managers themselves would have to be re-implemented in order to support the Wayland protocol? Yes, an a lot more than that will have to be partially or fully rewritten. Thankfully, many if not most desktop apps use a widget toolkit like GTK+ or Qt for UI, so it's enough to make the widget toolkits work on Wayland.

makomk 14y ago

Yep, the Wayland developers' solution to window management is for anyone who wants a different window manager to replace Wayland with a different compositor+window manager speaking the same protocol. Their suggested way of supporting proprietary graphics drivers is also replacing the compositor+window manager with one specific to that hardware which speaks the Wayland protocol, sort of like in the early days of X when there was a seperate X server binary for every piece of hardware. So your window management choices under Wayland depend on which graphics drivers you're using.

0x0 14y ago
Wow, does that mean you could end up with a "KDE-only" nvidia driver and a "GNOME-only" ATI/AMD driver?
JoshTriplett 14y ago
Not quite. Wayland itself doesn't require any graphics-driver-specific code; it uses the standard kernel interfaces and graphics stack (Mesa, DRI, libdrm, KMS, etc). That also works fine with radeon and nouveau, and it would work fine with the proprietary drivers as long as they support the standard graphics stack. It just won't work with proprietary drivers that implement their own entirely un-integrated graphics stack, which seems unsurprising to me. Your window manager of choice can just link into Wayland/Weston and ignore all the underlying graphics driver bits; they'll Just Work.
- tedunangst 14y ago
  It's been years and years since I knew the details, but at one point the nvidia drivers replaced pretty everything from libX11 down, and I don't think you could hook in at a middle point. (ie, they don't support the "standard" graphics stack.) Would appreciate if anyone could comment on how things stand today.
  - JoshTriplett 14y ago
    Somewhat better, but still awful. They don't replace libX11, but they do replace libGL, and they bypass the entire kernel graphics stack in favor of their own.
- wmf 14y ago
  You're describing how it should work, but AFAIK the proprietary drivers don't support KMS and have even talked about never supporting it. But rather than hacking Weston to support proprietary drivers, I would advocate using it as a carrot to beat AMD/Nvidia into submission.
alexlarsson 14y ago
While its true that a new "WM" in wayland would be a diffent binary its not really the same as a different X server. All the stuff that X does wrt hardware and stuff is not really in the wayland compositor, but in the drivers, and they are the same with both WMs. And the WMs would link to the wayland server library, so a lot of code would be shared between them. I don't think properietary drivers need to have their own wayland server. However, they do need to add EGL support, so that wayland can use the driver outside of X, and a few specific GL extensions that wayland needs. See e.g: http://ppaalanen.blogspot.fr/2012/03/what-does-egl-do-in-wayland-stack.html http://ppaalanen.blogspot.fr/2012/03/what-does-egl-do-in-way...

alexlarsson 14y ago

libwayland being a reference implementation does not mean its not implemented. It just means that the specified thing is the protocol, not the library API. This is similar to libX11, its just a reference implementation, and other implementations like escher (a pure java X11 protocol implementation) exists. Most wayland servers will still use libwayland. There is nothing special about multiple monitors in wayland. The KMS/Mesa drivers allows setup and rendering to multiple monitors fine, then its up to the wayland server to decide what to draw on each monitor.

wmf 14y ago
then its up to the wayland server to decide what to draw on each monitor This is the kind of "mechanism without any policy" thinking that I was hoping to escape from. What does Weston actually do in the presence of multiple monitors?