Detect when a output interface has been disconnected

[bphenriques]

Hi,

I successfuly setup a working solution that allows me to setup my outputs configuration (internal/external/extended). However, I often unplug the HDMI cable of my laptop while it is in docked mode, and as far as I can tell there is no way in niri directly to detect when that happens so that I can revert back to the internal display. Currently, when I unplug the cable, no output is displayed and there is nothing I can do without rebooting the laptop.

This is what happens when I unplugin the cable:

{"WorkspacesChanged":{"workspaces":[{"id":1,"idx":1,"name":"coding","output":null,"is_active":false,"is_focused":false,"active_window_id":3},{"id":2,"idx":2,"name":"browsing","output":null,"is_active":false,"is_focused":false,"active_window_id":5},{"id":3,"idx":3,"name":"gaming","output":null,"is_active":false,"is_focused":false,"active_window_id":null}]}}

All output are set to null which indicated that no output is available atm. I can work around so that I can listen to the event and enable eDP-1 again. However, it is a side-channel and not a dedicated channel to get the event I am looking for.

This led me to:

1. Would it make sense niri exposing events when outputs are connected/disconnected (at minimum)? I can run that on the background.
2. Or.. to avoid extra scripting, exposing a configuration that prompts niri to keep at least one output enabled if the current ones are disconnected. I noticed that niri does not safeguard against that when setting one to off which I think is reasonable by design.
3. Or...would it make sense for niri to have the notion of profiles similar to how keishin or similar tools (shikane). I ask this as I am unsure if my configuration should be mirrored on both niri or keishin/shikane configuration. I tried keishin but I found it unreliable but I don't have concrete proof. I will try shikane in the mean-time. It is likely out-of-scope for niri but feels worthwhile asking given that it is very common use-case.

Relates but not the same thing as:

• Layout selector for output? #834

[YaLTeR]

Hey! While niri doesn't expose output events in its own IPC (yet?), it does expose them via wlr-output-management. It's used by tools like kanshi. I see the tools you linked also use it.

[bphenriques]

Thank you, the important bit seems to be this one:

Whenever a head disappears (e.g. a monitor is unplugged), a wlr_output_head.finished event will be sent.

In your opinion would be tricky to extend niri to expose those events? I can try to contribute despite by lack of experience in Rust. It might be easier over figuring alternative interfaces (I hate shell scripting once it exceeds a certain complexity).

[bphenriques]

Ideally, option 2 but it might be out-of-scope. It would avoid adding background job that monitors the event.

[YaLTeR]

It's kind of plenty of effort. The IPC is backwards compatible so it needs to be carefully designed what we want to put into it. Then implementation is also a bit of effort.

So if the info is already exposed via wlr protocol, it's probably easier to just use that through some tool.

[bphenriques]

Thank you. At this point, I should probably revisit the external tools once again. I can share what I end up with, If I figure something out

[bphenriques]

I will opt for a "emergency" binding to keep things simple 😅 It will reenable the laptops monitor