Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Wayland Support #38
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Delapouite
commented
Jun 15, 2016
|
Should this alternative project be renamed wmonad? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
geekosaur
Jun 15, 2016
Contributor
Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.
Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc.
|
Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs. Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
vivid-synth
Aug 24, 2016
Looks like re-implementing for Wayland wouldn't be a giant project, though:
$ find . -type f | grep -v -e '\.git' -e '/tests/' | xargs wc -l | tail -1
4495 total
vivid-synth
commented
Aug 24, 2016
|
Looks like re-implementing for Wayland wouldn't be a giant project, though: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
IvanMalison
Dec 4, 2016
Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.
I can't say that I'm an expert on this topic, but I'd be surprised if there weren't any parts of the code can be reused. I would guess that StackSet might be eligible for reuse.
IvanMalison
commented
Dec 4, 2016
I can't say that I'm an expert on this topic, but I'd be surprised if there weren't any parts of the code can be reused. I would guess that StackSet might be eligible for reuse. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
geekosaur
Dec 4, 2016
Contributor
|
On Sun, Dec 4, 2016 at 1:04 AM, Ivan Malison ***@***.***> wrote:
I can't say that I'm an expert on this topic, but I'd be surprised if
there weren't any parts of the code can be reused. I would guess that
StackSet might be eligible for reuse.
StackSet's about the last thing you want to reuse, considering that it's
why e.g. floating windows behave insanely.
In Wayland, the layout becomes a plug-in for the compositor and much of the
rest goes into the client/application side theming. There is no "window
manager" as such. I'm not sure you can even *do* something like the
manageHook without introducing weird and potentially deadlock-y
interrelationships between them. (The "ports" of xmonad to native OS X
don't even try; there's nowhere to hook them in. It's much like Wayland.)
…--
brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
|
pjones
added
the
2.status: wontfix
label
Dec 9, 2016
pjones
closed this
Dec 9, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thekyriarchy
Sep 24, 2017
would it be worth a possible long-term rewrite for wayland support? it might be nice to adopt a client-server model like herbstluftwm in that case as well!
tangentially: https://github.com/abooij/sudbury
thekyriarchy
commented
Sep 24, 2017
|
would it be worth a possible long-term rewrite for wayland support? it might be nice to adopt a client-server model like herbstluftwm in that case as well! tangentially: https://github.com/abooij/sudbury |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
moljac024
Oct 15, 2017
Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc.
Total noob question but isn't Weston the reference compositor? AFAIK you don't write stuff on top of Weston, you write something LIKE weston. As I understand it, your compositor IS the window manager. Looks like some tiliing wms/compositors already exist, namely way cooler and sway.
moljac024
commented
Oct 15, 2017
Total noob question but isn't Weston the reference compositor? AFAIK you don't write stuff on top of Weston, you write something LIKE weston. As I understand it, your compositor IS the window manager. Looks like some tiliing wms/compositors already exist, namely way cooler and sway. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
geekosaur
Oct 15, 2017
Contributor
|
Maybe that's the current story. I can say for certain you do not write for
*Wayland*; Wayland is a protocol and a generic graphics API. You could
write a 'Wayland' implementation that sits on top of xcb; it would not be
compatible with what Red Hat has been working on, it would be a
Wayland-protocol interface to X11 APIs.
Then again, if they are handling this the same way they are handling Gtk
(explicitly not supporting non-Gnome, or even third party Gnome apps), they
probably don't see a reason to name something that they think shouldn't
exist, namely a general interface compatible with their 'reference'
implementation.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
mgsloan
Nov 9, 2017
Contributor
StackSet's about the last thing you want to reuse, considering that it's
why e.g. floating windows behave insanely.
What is insane about floating windows? Just that they occupy a position in the StackSet but are not tiled? It works just fine for me..
Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.
Not sure how much I buy this. True, you cannot guarantee full API compatibility, and currently the XMonad module re-exports Graphics.X11 and Graphics.X11.Xlib.Extras. However, XMonad configs tend to be quite high level and do not do anything very X11 specific. I think it is quite possible to support nearly everyone's XMonad config.
There are some things like KeyMask, etc that show up, but compatibility shims for that could be implemented.
So, basically, I think this is far too pessimistic. It is fine if you don't want to implement it, I probably don't want to either. However, if some sufficiently motivated individual came along, I don't think we should discourage them from adding a wayland flag to xmonad / xmonad-contrib. There would be huge API differences with this flag enabled, true, but I bet it could be done such that most configs require no changes.
I see that the "Way Cooler" project has a D-Bus extension protocol. I haven't looked into details, but perhaps a compositor implementation like this one might be able to delegate the window management to something external.
I am particularly interested in Wayland support for the following two reasons:
- It is now the default in Ubuntu, so it will probably be better maintained. It will probably take a while for the xorg side of things to drop in quality, but it might just happen.
- Wayland can make it way harder to do keylogging. AFAICT, modulo security bugs, keylogging will now require either the blessing of the wayland implementation, or it will require super user permissions.
"Way Cooler" does indeed seem cool. I've liked messing with Rust, it's my 2nd favorite language I think. Setting up a new laptop soon, gonna try out a few different linux distros - probably Manjaro or Antergos (basically, Arch made friendly), possibly NixOS, and newest ubuntu. If newest ubuntu wins then I'll probably give "Way Cooler" a shot.
What is insane about floating windows? Just that they occupy a position in the StackSet but are not tiled? It works just fine for me..
Not sure how much I buy this. True, you cannot guarantee full API compatibility, and currently the There are some things like So, basically, I think this is far too pessimistic. It is fine if you don't want to implement it, I probably don't want to either. However, if some sufficiently motivated individual came along, I don't think we should discourage them from adding a I see that the "Way Cooler" project has a D-Bus extension protocol. I haven't looked into details, but perhaps a compositor implementation like this one might be able to delegate the window management to something external. I am particularly interested in Wayland support for the following two reasons:
"Way Cooler" does indeed seem cool. I've liked messing with Rust, it's my 2nd favorite language I think. Setting up a new laptop soon, gonna try out a few different linux distros - probably Manjaro or Antergos (basically, Arch made friendly), possibly NixOS, and newest ubuntu. If newest ubuntu wins then I'll probably give "Way Cooler" a shot. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
geekosaur
Nov 9, 2017
Contributor
We don't wrap X11 much at all, and the few things we do expose Xlib (not xcb! which would make things easier) types.
Floating windows have lots of problems; try focusing one and watch the window stack rotate to something quasi-random (it will depend on what was focused on that screen when the float appeared). There are very few places where you could correct this by adjusting the StackSet; most of the hooks where you would want to do so run under control of XMonad.Operations.windows which is using its own (modified) copy of the StackSet which will replace the exposed one after the hook runs. (About the only hook that could actually modify the StackSet is handleEventHook).
sjanssen looked at both switching xmonad to use xcb and trying to change the StackSet to behave more sanely, and decided neither could be done without breaking existing configs. (I have to agree, at least in the case of StackSet; it was a horrid UI decision and I would like it to go away, but replacing it breaks too many things.)
In any case, the bigger problem is that there isn't a "window manager" by the X11 meaning of the term in Wayland; you'd have to split most configs into three pieces, and good luck getting them to work well together in their new homes if they need to interact in any way more involved than defaults (compositor for window placement, theme for window decoration, and a third user-written app for user interaction).
@Ongy has been working on a replacement for xmonad under Wayland, based on Sway. https://github.com/ongy/waymonad
|
We don't wrap X11 much at all, and the few things we do expose Xlib (not xcb! which would make things easier) types. Floating windows have lots of problems; try focusing one and watch the window stack rotate to something quasi-random (it will depend on what was focused on that screen when the float appeared). There are very few places where you could correct this by adjusting the sjanssen looked at both switching xmonad to use xcb and trying to change the In any case, the bigger problem is that there isn't a "window manager" by the X11 meaning of the term in Wayland; you'd have to split most configs into three pieces, and good luck getting them to work well together in their new homes if they need to interact in any way more involved than defaults (compositor for window placement, theme for window decoration, and a third user-written app for user interaction). @Ongy has been working on a replacement for xmonad under Wayland, based on Sway. https://github.com/ongy/waymonad |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
mgsloan
Nov 9, 2017
Contributor
I see! Thanks for the info @geekosaur .
sjanssen looked at both switching xmonad to use xcb and trying to change the StackSet to behave more sanely, and decided neither could be done without breaking existing configs. (I have to agree, at least in the case of StackSet; it was a horrid UI decision and I would like it to go away, but replacing it breaks too many things.)
Interesting! StackSet does strike be as being a bit too "clever". TBH I never found zippers to be all that nice to work with. Very clever, certainly.
I suppose I have had some issues with floating windows and when they are considered to be part of a particular workspace. Haven't seen any rotation of the StackSet on focusing though.
II wonder if sjanssen still has a wip version of that code laying around? Perhaps can do an XMonad 2.0 release that is free to break compatibility? I realize that XMonad's small core is one of the cool things about it, but I think some xmonad-contrib stuff could be made a bit more canonical and involved in the default config. Stuff like EZConfig and perhaps a few others.
Would require someone that was sufficiently motivated to do a bunch of good changes for an XMonad 2.0. Not me at this point.
In any case, the bigger problem is that there isn't a "window manager" by the X11 meaning of the term in Wayland; you'd have to split most configs into three pieces, and good luck getting them to work well together in their new homes if they need to interact in any way more involved than defaults (compositor for window placement, theme for window decoration, and a third user-written app for user interaction).
Indeed, it seems unfortunate that they did not make a protocol for window management. As is, the window managers will either also be compositors, or they will rely on a particular compositor.
|
I see! Thanks for the info @geekosaur .
Interesting! StackSet does strike be as being a bit too "clever". TBH I never found zippers to be all that nice to work with. Very clever, certainly. I suppose I have had some issues with floating windows and when they are considered to be part of a particular workspace. Haven't seen any rotation of the StackSet on focusing though. II wonder if sjanssen still has a wip version of that code laying around? Perhaps can do an XMonad 2.0 release that is free to break compatibility? I realize that XMonad's small core is one of the cool things about it, but I think some xmonad-contrib stuff could be made a bit more canonical and involved in the default config. Stuff like EZConfig and perhaps a few others. Would require someone that was sufficiently motivated to do a bunch of good changes for an XMonad 2.0. Not me at this point.
Indeed, it seems unfortunate that they did not make a protocol for window management. As is, the window managers will either also be compositors, or they will rely on a particular compositor. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Ongy
Nov 9, 2017
Indeed, it seems unfortunate that they did not make a protocol for window management. As is, the window managers will either also be compositors, or they will rely on a particular compositor
To my understanding, merging compositor, window manager and display manager (mostly input -> window translation) was one of the reasons they wanted to drop the X architecture.
Wayland is supposed to be more general than just a "desktop" window protocol.
Which becomes somewhat obvious when you realise the ivi shell existed for ever, and they are on the unstable v6 version of xdg_shell (the protocol on top of wayland that makes somewhat normal desktops possible).
As to, doing this over generic IPC with some existing compositor:
Since the architecture is shaping to be multiple compositors based on shared libraries (evdev, libdrm, kms) I doubt anyone will be happy to export the amount of control we want to have over such an IPC.
Simply because at that point it would be easier to just use the same libraries and write your own version.
This is what I'm currently investing way too much time and thought into.
BUT: this is a project on its own. I will break things. At least your config, probably some workflows.
I also won't make any promises/guarantees/estimates to when or even IF this will ever be at a state anyone who's less crazy than me can use.
If you have worries about how things will work out, feel free to create issues or join me in #waymonad on freenode (which I have been cheeky enough to create already) and talk with me.
Small correction: It's based on wlroots not sway itself.
wlroots is a subproject of sway created to replace wlc for them.
Ongy
commented
Nov 9, 2017
To my understanding, merging compositor, window manager and display manager (mostly input -> window translation) was one of the reasons they wanted to drop the X architecture. As to, doing this over generic IPC with some existing compositor: This is what I'm currently investing way too much time and thought into. Small correction: It's based on wlroots not sway itself. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
mgsloan
Nov 9, 2017
Contributor
@Ongy Really cool stuff!
Yes, I can see why we wouldn't want IPC to have access to all inputs. I was thinking that you'd somehow give special privileges to the window manager program. A really hacky way to do this would be to have the window manager be responsible for running the compositor, and then have it communicate over stdin / stdout. Hah!
The screen capture aspect of this stuff is interesting. It's another case where you want to be able to give a regular user program an extra capability, just as you want to give the user's window manager the capability to listen to key events and manage windows. I realize this potentially weakens the security. Maybe one way to make it more secure would be to only give the window manager access to input events when a particular key is held down!!
Avoiding userspace keyloggers is one of the big reasons I'm interested in Wayland. The non standard screenshot stuff sucks, though. For example, I use scrot (screen region -> png) and byzanz all the time (screen capture -> gif). I've got a crazy Rust side project that requires screen capture (uses xcb / xlib). It'd be nuts if it had to have an adapter for every Wayland compositor out there, ugh.
Misc side note: shared memory screenshots would be really cool. As little copying as possible. XCB has an api for that, but I couldn't get it to work :/ . I'd really like something like this for low overhead / low latency screenshots, even if it leaves artifacts where stuff is in the middle of rendering, I don't care, that'd actually be ideal if it's that close to the raw front buffer / back buffer, if that even exists with multiple GPU compositors. I realize shared memory doesn't quite cover GPU memory, heh
I will certainly give this a try if I give wayland a whirl, though. Keep up the good work!
|
@Ongy Really cool stuff! Yes, I can see why we wouldn't want IPC to have access to all inputs. I was thinking that you'd somehow give special privileges to the window manager program. A really hacky way to do this would be to have the window manager be responsible for running the compositor, and then have it communicate over stdin / stdout. Hah! The screen capture aspect of this stuff is interesting. It's another case where you want to be able to give a regular user program an extra capability, just as you want to give the user's window manager the capability to listen to key events and manage windows. I realize this potentially weakens the security. Maybe one way to make it more secure would be to only give the window manager access to input events when a particular key is held down!! Avoiding userspace keyloggers is one of the big reasons I'm interested in Wayland. The non standard screenshot stuff sucks, though. For example, I use scrot (screen region -> png) and byzanz all the time (screen capture -> gif). I've got a crazy Rust side project that requires screen capture (uses xcb / xlib). It'd be nuts if it had to have an adapter for every Wayland compositor out there, ugh. Misc side note: shared memory screenshots would be really cool. As little copying as possible. XCB has an api for that, but I couldn't get it to work :/ . I'd really like something like this for low overhead / low latency screenshots, even if it leaves artifacts where stuff is in the middle of rendering, I don't care, that'd actually be ideal if it's that close to the raw front buffer / back buffer, if that even exists with multiple GPU compositors. I realize shared memory doesn't quite cover GPU memory, heh I will certainly give this a try if I give wayland a whirl, though. Keep up the good work! |
xavier83 commentedJun 15, 2016
Since wayland is becoming the mainstream display server for linux and X will only be supported through xwayland, would it make sense to support wayland too?