wlroots status

[ddevault]

Is it done yet?

YES

This todo list is largely unordered and far from complete, but serves as a decent reference/list of things we should not forget to do.

• spin up the backend
• s/sway list_t/wlroots list_t/g
• Unify sway and wlroots logging
• Find and // todo all references to wlc
  • Stop linking to wlc entirely
• Configuration
  • Re-add command handling
  • Command list
• Tree
  • Configure wlr_output_layout for root_container
  • Outputs
    • Add to tree
    • Re-attach workspaces to hotplugged outputs
    • Handle output removal
    • Handle zero outputs
    • Create a workspace
    • Configure outputs
  • Containers
  • Add shell views to tree
    • xdg_shell
      • Handle popups
    • wl_shell
    • xwayland
  • Arrange windows
    • L_HORIZ
    • L_VERT
    • L_TABBED
    • L_STACKED
    • Floating
    • Gaps
• Workspaces
  • Use config file to reason about names
  • Switching between workspaces (focus)
• IPC
  • Run IPC server
  • get_version
  • command
  • subscribe
    • send notifications
  • get_tree
  • get_outputs
  • get_marks
  • get_inputs
  • get_workspaces
  • get_clipboard
• Rendering
  • Wire up frame loop
  • Render surfaces
    • xdg_shell
      • popups
    • wl_shell
    • xwayland
    • Layer shell
    • subsurfaces
  • Damage tracking
  • Window borders
• Drag and drop
• Refactor Sway's tree to support wlr structures
• Input
  • Enumerate devices
  • wlr_cursor
  • wl_seat
  • Focus semantics
    • Focus follows mouse
    • Focus going down the tree (Track focus throughout the tree for each seat #1582)
  • Device configuration
    • Support existing features
    • wlr_cursor configuration
    • Extended keyboard configuration
  • Drawing tablets
    • Simulate pointer events
    • tablet protocol
    • Bindings for pad buttons
  • Touch
    • wl_touch
    • Simulate pointer events
    • Gesture bindings
• HiDPI
• Mouse bindings
• Interactive move/resize
  • Floating
  • Tiling
• Sort out forking and privledged process
• Security config
• server-decorations
• Revert nvidia proprietary driver stuff
• Add modes to swaymsg -t get_outputs
• Side projects (all need to be converted to sway-protocols)
  • swaybg
  • swaybar
  • swaylock

Also just grep for "TODO WLR" on the wlr branch to find a bunch of notes I've left behind.

Test plan

For now I'm only using this space as a reminder to include the stuff I expect to break but might get forgotten.

• Test all IPC interactions and compare with i3
• Test the utter shit out of everything else

[jparsert]

How long is the wlroots transition expected to take ?

[Fale]

"[...] My goal is to ship sway 1.0 before the end of the year. [...]" from https://drewdevault.com/2017/10/09/Future-of-sway.html

[PeaceAlways]

Yeah, of course we are looking forward for it.

[ddevault]

Alright guys, it's go time. I have laid the foundation for a wlroots-based sway, and it's time to get everyone involved in working on porting it over. Remember to join the IRC channel, #sway-devel on freenode, for collaboration.

I added this to the OP to explain the approach we're taking:

Large swaths of Sway code has been moved to sway/old/ and include/sway/old/ for reference. There are now two directories, sway/desktop/ and sway/tree/, where most of the work is ongoing. The former is where sway touches wlroots - event listeners, shell handlers, and so on all live here, and it has ownership over all wlr_* resources. sway/tree/ is where the sway tree is being managed, and contains code for manipulating the tree.

The plan is to gradually re-implement features of sway here. We will gradually re-introduce parts of the code from the old directories and adapt them for use with wlroots, rewriting and refactoring as appropriate. I'm also taking this opportunity to do some cleanup of some of the codebase's bigger design problems - this is a good opportunity to tweak existing interfaces to be cleaner while we're refactoring everything anyway.

The next things I want to work on right now are, approximately in order:

• Spinning up the tree (getting workspaces, containers, and views into the tree)
• Spinning up the command subsystem and porting a few commands over
  • Using these to configure outputs
• Spinning up IPC
• Arranging the tree
• Rendering views

[ddevault]

Backend configuration spec:

backend add <type> [--name <name>] [args...]: spins up a backend of the given type with the given name (or a generated name: type-number e.g. libinput-0). [args...] is backend-specific, such as a path to a DRM device for the DRM backend, a DISPLAY for x11, an initial number of outputs for the wayland backend, etc.

backend del <name>: does what it says on the tin

backend <name> <subcommand> [args...]: runtime manipulation of backend-specific features

Subcommands

wayland

backend wayland-0 add-output

backend wayland-0 del-output <id>

x11

See wayland

headless

See wayland, plus

backend headless-0 add-input <caps...>

backend headless-0 del-input <id>

backend headless-0 input <id> <send-keys|depress|release|click|move> [...]

Example use-cases

• Add an RDP backend at runtime so your buddy can pair program with you
• Add a headless backend for scripting with
• Add a nested Wayland backend to your DRM session cause you're weird
• Add an x11 backend to your DRM session so you can switch TTYs to your x session and still manipulate your sway session

[ddevault]

We should probably also add sway --no-backend to start it up with an empty multi-backend so you can explicitly configure the backends you need at runtime.

[acrisci]

I wonder if we could support this use case with the mixed backends. I've wanted to try this out in my workflow for awhile.

I would like to "split" a monitor so it is treated as two separate sway outputs. So for instance, if I split one of my monitors in half, it will have two separate groups of workspaces (which I can assign to either output on the monitor), and when I fullscreen a container on one of the split monitors, it will only fullscreen on that half of the screen. It would also use the tree move logic for outputs when moving between them which is convenient sometimes.

The multi backend feature might allow me to use one of my outputs to have two wayland window outputs nested within them which are arranged tiled. That would give me what I want, except we would have to be careful to choose how keyboard events are delivered to the window.

[ddevault]

It might be better to write some kind of plugin that spins up a DRM backend separately from Sway's backend support code, then subdivides the outputs on it and exposes them back into the Sway tree and handles the rendering necessities.

[4e554c4c]

• Commands
  • Basics
    • bind
    • debuglog
    • include
    • exec
    • exec_always
    • exit
    • reload
    • set
  • New -- needs documentation
    • input
    • seat
  • Old
    • bar
    • border
    • client
    • floating
    • focus
    • font
    • fullscreen
    • gaps
    • kill
    • layout
    • mark
    • move
    • resize
    • scratchpad
    • split*
    • sticky
    • output
    • workspace
  • Other
    • Criteria matching

[natesymer]

Hey, what's some low-hanging fruit I could work on? I'm new to working on Sway.

[ddevault]

Development is organized on IRC, join us there.

[r3k2]

any news on this?

[Wolf480pl]

I think this should be updated to reflect #1735, specifically the "can I use it anyway? NO" part.

[ddevault]

Thanks @Wolf480pl

[moritz31]

Hey,
are there some easy things to do, where i can maybe help?

[ddevault]

Come join us in the IRC channel and ask for things to do:

http://webchat.freenode.net/?channels=sway-devel&uio=d4

#sway-devel on irc.freenode.net

[ddevault]

I have split the work that remains out into separate tickets. We're almost there!

[ddevault]

https://github.com/swaywm/sway/milestone/1

[asymmetric]

Should this be updated to say YES?

[ddevault]

Sure.