New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wlroots status #1390

Closed
SirCmpwn opened this Issue Oct 12, 2017 · 18 comments

Comments

Projects
None yet
10 participants
@SirCmpwn
Member

SirCmpwn commented Oct 12, 2017

Is it done yet?

NO

Can I use it anyway?

OKAY, BUT DON'T ASK US FOR HELP

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
  • 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 (#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

This comment has been minimized.

Show comment
Hide comment
@jparsert

jparsert Oct 31, 2017

How long is the wlroots transition expected to take ?

jparsert commented Oct 31, 2017

How long is the wlroots transition expected to take ?

@Fale

This comment has been minimized.

Show comment
Hide comment
@Fale

Fale Oct 31, 2017

Contributor

"[...] 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

Contributor

Fale commented Oct 31, 2017

"[...] 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

This comment has been minimized.

Show comment
Hide comment
@PeaceAlways

PeaceAlways Nov 15, 2017

Yeah, of course we are looking forward for it.

PeaceAlways commented Nov 15, 2017

Yeah, of course we are looking forward for it.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Nov 19, 2017

Member

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
Member

SirCmpwn commented Nov 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Dec 16, 2017

Member

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
Member

SirCmpwn commented Dec 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Dec 17, 2017

Member

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.

Member

SirCmpwn commented Dec 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@acrisci

acrisci Dec 17, 2017

Contributor

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.

Contributor

acrisci commented Dec 17, 2017

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.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Dec 17, 2017

Member

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.

Member

SirCmpwn commented Dec 17, 2017

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.

This was referenced Dec 19, 2017

@SirCmpwn SirCmpwn added the wlroots label Dec 20, 2017

4e554c4c added a commit to 4e554c4c/sway that referenced this issue Dec 31, 2017

@4e554c4c

This comment has been minimized.

Show comment
Hide comment
@4e554c4c

4e554c4c Jan 7, 2018

Contributor
  • 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
Contributor

4e554c4c commented Jan 7, 2018

  • 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

This comment has been minimized.

Show comment
Hide comment
@natesymer

natesymer Jan 12, 2018

Contributor

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

Contributor

natesymer commented Jan 12, 2018

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

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Jan 12, 2018

Member

Development is organized on IRC, join us there.

Member

SirCmpwn commented Jan 12, 2018

Development is organized on IRC, join us there.

@ReK2Fernandez

This comment has been minimized.

Show comment
Hide comment
@ReK2Fernandez

ReK2Fernandez Jan 21, 2018

any news on this?

ReK2Fernandez commented Jan 21, 2018

any news on this?

@Wolf480pl

This comment has been minimized.

Show comment
Hide comment
@Wolf480pl

Wolf480pl Apr 7, 2018

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

Wolf480pl commented Apr 7, 2018

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

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn
Member

SirCmpwn commented Apr 7, 2018

Thanks @Wolf480pl

@moritz31

This comment has been minimized.

Show comment
Hide comment
@moritz31

moritz31 Apr 13, 2018

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

moritz31 commented Apr 13, 2018

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

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Apr 13, 2018

Member

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

Member

SirCmpwn commented Apr 13, 2018

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

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Jul 23, 2018

Member

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

Member

SirCmpwn commented Jul 23, 2018

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

@SirCmpwn SirCmpwn removed the wlroots label Jul 26, 2018

@SirCmpwn SirCmpwn closed this Sep 3, 2018

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
Member

SirCmpwn commented Sep 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment