swaywm/wlroots

wlroots status

ddevault opened this issue · 36 comments

ddevault commented

Planned and completed features, loosely sorted by priority:

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

@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 commented

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 commented

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

torpak commented

Runtime switchable layouts would be nice in the long run.

  • 👍3
soredake commented

How about relative-pointer protocol?

ddevault commented

Link?

ascent12 commented

@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 commented

Yeah eventually we'll want that.

martinetd commented

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 commented

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 commented

[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?

  • 👍1
ddevault commented

Added em

  • 👍1
ghallberg commented

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 commented

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.

ddevault commented

Sure.

L-as commented

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

ddevault commented

Yes, and it's already in this list.

emersion commented

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

  • 👍4
Kommynct commented

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

  • 👍2
emersion commented

No.

Kommynct commented

Okay, thank you.

ibrokemypie commented

is wayland-wall to be implemented?

valpackett commented

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 commented

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

  • 👎3
  • 😕3
emersion commented

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

  • 👍1
emersion commented

Done.

linkmauve commented

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 commented

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 commented

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 commented

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

  • 🎉5
  • ❤️1
bew commented

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

bew commented

Perfect thanks