Decouple DPMS from wl_output globals

[Ongy]

Sorry, missed it before, but https://github.com/swaywm/wlroots/pull/549 does a something I feel like it shouldn't.

So this PR couples the wl_outupt globals to the enabled/disabled state of the output. This state also determines the DPMS state on DRM backend. IMO this isn't the best idea. The general hierarchy of output states I can think of is roughly:

• Enabled (DPMS/Renderloop on, in layout, wl_output exists)

• Sleep (DPMS/Renderloop off, in layout, wl_output exists) This is for powersaving

  Things like the desktop background, notification-daemon etc. shouldn't react to this. IMO clients shouldn't get to know at all (outside done callbacks)

• Disabled (DPMS/Renderloop off, wl_output may exist, not in layout) Plugged in, but not configured, should exist in whatever is going to replace xrandr.

  Desktop background/notifaction-daemon etc. should consider this as off, don't try to appear on it. Problem: I can't see an enabled flag in wl_output, so this may require the split protocols KDE has current

• Unplugged -- Doesn't exist, doesn't show up for xrandr-ish application.

IIRC the KDE protocol for setting this up had a custom information protocol attached as well, which could be used for the disabled state. Then the wl_output could be bound to the wlr_output_layout and have the disabled state controlled by the compositor removing the output from the layout.

[emersion]

I don't see why clients should be aware of sleeping outputs. That would break the screenshooter. Also, the wlr_output is not aware weather it's sleeping or disabled.

KDE has another interface (outputdevice) for outputs not exported as wl_outputs.

[Ongy]

I'd consider the screenshooter more of an edgecase here. I don't know the protocol, is there no way to tell the application it cant get this output? I'd prefer (and expect) other things that interact with wl_output not to react to powersave features. And there are more things that interact with wl_output e.g. xdg-shell fullscreen, I would expect surface_layers and probably others. (pointer constraints? Mapping drawing tablets to areas?)

And sure, I would bind the sleep/disabled states here (I just made the names up) to whether the output is in the wlr_output_layout or not. If that doesn't make sense/wouldn't work with wlroots, that's nothing important, just my current idea.

[Ongy]

One interaction that can be observed with what we currently have: Set an output-scale >1 Let the surface enter the output. Cycle DPMS (on->off->on). This destroys the output and creates a new one Set the output-scale to something different.

The surface will not associate the event on the new output with the output it originally entered. Neither will it associate any leaves that may occure later on with said output.

This could be fixed on the compositor side by going through all surfaces on the output and sending enter/leave events.

[ddevault]

I think we need a detailed spec of the entire output state machine and should change the codebase to be consistent with it.

[Ongy]

This is the current state of things. I did propose to change the wl_output handling. That would either give the compositor authority over the global or bind it to the output_layout (expecting the compositor to set up the output before it's added).

Going through this, I think it's also created too early. At this point position/scale/transform/mode can all be bogus.

output created/discoverd (wlroots)

1) output is enabled (wl_output global created) 2) backend.events.output_add is emitted Compositor is expected to set up output for IPC (swaymsg/keybinds etc.)

output livecycle (compositor)

• Set (custom) mode
• set position (indirect over wlr_output_layout)
• set scale
• set transform

wlroots will emit events to clients for any of these

• add/remove from output layout wlroots does nothing (except move possibly all outputs) compositor should move windows back into new area used
• wlr_output_update_enabled: Sets the enabled flag on struct wlr_output and creates/destroys the wl_output global.
• wlr_output_enable (dpms on drm backend). Inconsistency: 1) wayland has no implementation for enable and nothing happens 2) drm will call wlr_output_update_enabled which destroys/creates the wl_output global

output destroyed

• wlroots handles the wl_global
• compositor is required to clean up own state output_layout remove action should be taken

The compositor should hook the frame callback either on create or hook/unhook on enable events.

There's also a bit more around rendering/cursors but I think https://github.com/swaywm/wlroots/pull/571 changes that a little (damage events/tracking damage is new) should I add that?

[ddevault]

Also want to know how hotplugging is involved.

DPMS disable should not remove the wl_global

[Ongy]

Hotplug triggers transition from limbo (unplugged/non-existant) to/from livecycle over the respective way.

Hotpluginin will create a wlr_output and go over what I called created/discoverd. Then it's up to the compositor.

Hotunplug will clean up internal state emit the output_remove signal on the backend.

[ddevault]

Sounds correct to me.

[emersion]

So the only change to do is to expose functions to create/destroy the output global right? (And don't do it when enabling/disabling the output)