Wlroots: Compositor ideas

Created on 15 Jun 2017  路  5Comments  路  Source: swaywm/wlroots

Starting a thread to dump ideas of things I want to be possible for wlroots-based compositors to implement. Here's a few of the ideas that have been bouncing around in my head:

  • [x] Let compositor handle focus semantics by just letting them attach an arbitrary number of input devices to an arbitrary number of clients
  • [x] Add or remove backends on the fly, including support for i.e. displaying an output on the wayland backend on an output running the DRM backend
  • [ ] Access to internal wlroots resources to implement pretty much any extensions you want
  • [x] Implementing custom versions of any type, like virtual outputs or remote input devices or anything else (compositor might optionally have plugin support that could take advantage of this too)
  • [x] Separate keyboard layouts for separate keyboards or even separate applications
  • [x] Multiple cursors and/or
  • [ ] simulated multitouch with multiple mice
  • [x] Rendering individual surfaces with arbitrary shaders or arbitrary transformations

Most of these shouldn't be explicitly supported features in wlroots, but rather should be possible as a consequence of its flexible design. Feel free to add more for discussion and we'll see if it makes sense for wlroots to accomodate these use-cases.

Most helpful comment

wlroots isn't actually going to render surfaces for you at all or even keep track of their x/y coordinates. You'll definitely be able to implement a feature like that, since most of the work will be on your side anyway.

All 5 comments

One of the features I would like to have for Way Cooler is to have multiple surfaces displaying content from the same client (and for them all to be able to be interacted with). This would allow me to implement tags (as an alternative to workspaces) and is currently not possible with wlc due to its strict one to one mapping of view to surface.

Do you think the surface creation code will be able to be exposed enough to make that possible in wlroots? Would it be able to be done in a backend agnostic way?

Here is an example of what I'm talking about implemented weston

wlroots isn't actually going to render surfaces for you at all or even keep track of their x/y coordinates. You'll definitely be able to implement a feature like that, since most of the work will be on your side anyway.

To clarify, wlroots will render surfaces for you if you ask it to. But it won't be automatic, it'll be a function you call during your output_frame handler and provide x/y coords and a surface to render.

I don't know where in the stack that needs support, but the rotation feature of weston is epic.
BTW does this wlroots complement or replace libweston and qtwayland?

@plfiorini: might be applicable to Liri OS?
@sardemff7: intersection/integration with wayland-wall?

All the stuff wlroots needs to implement to support rotation is already in place.

wlroots replaces libweston/qtwayland/wlc.

Don't expect much in the way of wayland-wall integrations.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

maletor picture maletor  路  4Comments

Ferdi265 picture Ferdi265  路  5Comments

m01 picture m01  路  3Comments

emersion picture emersion  路  5Comments

ddevault picture ddevault  路  5Comments