wlroots status

[ddevault]

Planned and completed features, loosely sorted by priority:

• [ ] Backends
  • [x] DRM
  • [x] Hotplugging (PLEASE TEST - THAT MEANS YOU, GITHUB ISSUE READER)
  • [x] Legacy modesetting
  • [x] Atomic modesetting
  • [x] DPMS
  • [x] Rotation
  • [x] Hardware cursor
  • [x] DisplayPort MST - need additional hardware - #171
  • [x] Multi GPU
    • [x] Throw pixels over the fence
    • [x] Specify main GPU
    • [ ] Multi-GPU rendering
    • [ ] Switch main GPU at runtime
  • [x] libinput
  • [x] Keyboards
    • [x] Events
    • [x] Key maps
    • [x] LEDs
  • [x] Pointers
  • [x] Touch
    • [ ] Get mapped output from udev doesn't work on my hardware
  • [x] Tablet tool
  • [x] Tablet pad
  • [ ] Gesture
  • [x] Switch
  • [x] Wayland
  • [x] Output
    • [x] Multiple outputs
    • [x] Rotation
  • [x] Input devices
  • [x] X11
  • [x] RDP
  • [ ] fbdev
  • [x] headless
• [x] Session
  • [x] udev
  • [x] Multi GPU
  • [x] logind
  • [x] elogind
  • [x] VT switching
  • [x] Multi GPU
  • [x] Direct (forking)
  • [x] VT switching
  • [x] fork+setuid
  • [x] Multi GPU
• [ ] Wayland
  • [x] wl_output
  • [x] wl_compositor
  • [x] wl_surface
  • [x] wl_region
  • [x] wl_shm
  • [x] wl_drm
  • [x] wl_shell
  • [x] wl_shell_surface
  • [x] wl_subsurface
  • [x] wl_seat
  • [x] wl_keyboard
    • [x] key repeat
  • [x] wl_pointer
  • [x] wl_touch
  • [x] Multi-seat
  • [ ] Extra protocols
  • [x] xdg-shell v6
    • [x] surface
    • [x] toplevel
    • [x] popup
    • [x] positioner
  • [ ] xdg-shell v5
  • [x] xdg-shell
  • [x] gamma-control (orbital)
  • [x] screenshooter (weston)
  • [x] server-decoration (kde)
  • [x] layer-shell (wlroots)
  • [x] input-inhibitor (wlroots)
  • [x] input-method
  • [x] pointer-constraints
  • [x] presentation-time
  • [x] linux-dmabuf
  • [ ] viewporter
  • [ ] xwayland-keyboard-grab
  • [x] relative-pointer
  • [ ] xdg-foreign
  • [x] xdg-output
  • [x] tablet
  • [x] idle-inhibit
  • [ ] input-timestamps
  • [ ] keyboard-shortcuts-inhibit
  • [x] text-input
  • [x] pointer-gestures
  • [x] fullscreen-shell
  • [x] idle
  • [x] gtk-primary-clipboard
    • [x] Sync with Xwayland
  • [x] clipboard
  • [x] drag and drop
• [x] wlroots features
  • [x] wlr_cursor
  • [x] wlr_xcursor
  • [x] wlr_output_layout
  • [x] Output rotation
  • [x] Output mirroring
  • [x] Output damage
• [x] Scaling (hidpi)
  • [x] Integral
  • [x] Fractional
• [x] Rendering
  • [x] Primitives
  • [x] Textured quads
  • [x] Colored quads
  • [x] Colored ellipses
  • [x] Pixman
• [x] XWayland
  • [x] Initialization
  • [x] Clipboard sync
  • [x] Drag and drop
  • [x] Window management utilities
• [ ] Documentation ¯\_(ツ)_/¯

[ddevault]

@nyorain added support for output rotation and multihead to the WL backend. Leaving the other tasks to you for now. Thanks again, that backend is going to make things way easier for me to work on upcoming features.

[ddevault]

An additional point of discussion for the wayland backend: the compositor is going to hand us a keyboard layout. Should we give a shit? Right now wlroots doesn't bother with handling keyboard layouts and leaves that up to the user, we just hand it scancodes and the user feeds them to xkb. Maybe we could have a means for a wlr_keyboard to suggest a layout? XKB is going to source from the environment variables which would almost certainly be set in any case.

[ddevault]

Clarification: wayland hands entire XKB keymaps to the client. Maybe we should just move xkb code into wlroots...

[torpak]

Runtime switchable layouts would be nice in the long run.

[soredake]

How about relative-pointer protocol?

[ddevault]

Link?

[ascent12]

@soredake Yeah, I imagine we'll get most of the extra (currently unstable) things from wayland-protocols.

@SirCmpwn https://github.com/wayland-project/wayland-protocols/blob/master/unstable/relative-pointer/relative-pointer-unstable-v1.xml

[ddevault]

Yeah eventually we'll want that.

[martinetd]

Xwayland init can probably be checked. On top of the other two points, we might also want to add something about cursor as there look like we'll need some special cursor handling within our xwayland layer as well. I'm not sure if "window management utilities" is about stuff like move/resize/full screen/focus/title, if it isn't then will need another checkbox that that and please explain briefly what this actually is :)

[ddevault]

On top of the other two points, we might also want to add something about cursor as there look like we'll need some special cursor handling within our xwayland layer as well.

What do you mean?

I'm not sure if "window management utilities" is about stuff like move/resize/full screen/focus/title, if it isn't then will need another checkbox that that and please explain briefly what this actually is :)

Yes, that's what it is. Though it might make more sense for the compositor to just implement an X11 window manager themselves? Thoughts?

[martinetd]

[xwayland cursor handling]

What do you mean?

Actually not 100% sure, but there is code in both weston and wlc about cursors within their xwayland code. It looks like they send Xwayland cursor pixel maps so it will render it on the X side, but I do not understand yet why that is not redundant with the wayland-side rendering, or why it is useful.

[window management utilities]

Yes, that's what it is. Though it might make more sense for the compositor to just impl\ ement an X11 window manager themselves? Thoughts?

Hm. I think we should handle X11 events as close as possible to what xdg/wl shells do. For example, if I understand this correctly xdg_toplevel_move will be called when an wayland client asks to move the toplevel one way or another. sway in tiled mode will probably not care at all, since we enforce positions; but another compositor or in floating mode we will probably want to get notified when this happens.

That means we either need some kind of upcall vector for shells to notify the compositor something happened, or we need to store the request somewhere until the compositor processes the buffer in the next frame iterating. (I don't know if there already has been a decision for that, could be something else I guess)

I haven't given this much thought yet but at this point I would rather have xwayland behave like another shell and just notify the compositor something happened, so the 'xwm' would really just be something like an x shell handler.

Does that seem to make sense?

[Sunderland93]

What about presentation-time and viewporter protocols? https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time/presentation-time.xml https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/viewporter/viewporter.xml

[ddevault]

Added em

[ghallberg]

Is there a subset of these points that need to be implemented before "releasing" wlroots (starting to use it for sway for example). Or are you planning to finish all of these before that?

RDP for example feels like it's a lot of work, and not really needed for 99% of use cases.

Just asking out of curiosity, and to know where to apply any possible free time I have to spare for contributions.

[ddevault]

There is a subset, yes. Work on porting Sway to wlroots will begin soon. If you're interested in contributing to wlroots, please join us in the IRC channel for direction.

[Sunderland93]

Hello. Please add this protocols: xwayland-keyboard-grub, relative-pointer, xdg-foreign and xdg-output

[ddevault]

Sure.

[L-as]

Should (can) drag-and-drop be a part of wlroots?

[ddevault]

Yes, and it's already in this list.

[emersion]

We could add gtk-primary-selection for better clipboard support.

[Kommynct]

Would it be appropriate to put shadows for floating windows on this list?

[emersion]

No.

[Kommynct]

Okay, thank you.

[ibrokemypie]

is wayland-wall to be implemented?

[valpackett]

Looks like surface-layers will be used instead of wayland-wall's background/dock-manager/launcher-menu/notification-area.

But wayland-wall also has window-switcher, seems like a useful one (e.g. for rofi)

[andrewwakeling]

Are there any guides on how to install wlroots (in combination with sway), especially with Ubuntu?

[emersion]

From the Wayland ML:

In short, Xwayland will take the current wl_output mode, ignore any scale, and use the mode to configure the Xrandr monitors and the X11 screen. Since we want to make it possible to fix Xwayland to actually take the scale into account, while properly implement wl_output modes, as well as not cause any regressions, we introduced xdg_output (see wayland-protocols) which will actually make it possible to do things correctly by letting clients (read Xwayland) know about the logical size of a wl_output.

So xdg-output will probably allow better Xwayland HiDPI support in the future.

See https://bugzilla.gnome.org/show_bug.cgi?id=787363

Also see https://wiki.gnome.org/Initiatives/Wayland/XWayland

[Sunderland93]

Please add input-timestamps protocol https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/input-timestamps/input-timestamps-unstable-v1.xml and keyboard-shortcuts-inhibit https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml

[emersion]

Done.

[linkmauve]

linux-dmabuf is another very important protocol from wayland-protocols you are missing, it allows clients to create Wayland buffers from dmabuf fds in the most efficient way allowed by the drivers. You can find the two weston-simple-dmabuf-* test clients in Weston, and any recent Mesa will also implement it.

[emersion]

Yeah, that's true. Even if it's not on the list we talked about implementing it in the past. Thanks for the heads-up!

[ascent12]

It's probably to the point where we should just promise everything inside wayland-protocols, unless there is a specific reason we don't want to do it.

[ddevault]

I think this ticket has outlived its usefulness. wlroots is ready to build compositors with.

[bew]

So feature-wise it's complete, but is the API stable? (can we write language bindings without breakage)

[emersion]

See https://github.com/swaywm/wlroots/issues/1008

[bew]

Perfect thanks