Hyprland: Disabling a monitor causes it to no longer be detected

Disabling through either kanshi, wlr-randr, or hyperctl makes the monitor undetectable through either. So for example if I run hyprctl keyword monitor LVDS-1, disable , the monitor LVDS-1 can no longer be found through: hyprctl monitors, or wlr-randr. Thus making it impossible to re-enable. Perhaps the issue that is being alluded to all the way at the end of #453. Perhaps this is even introduced by the fix?

running latest git version.

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 21 (12 by maintainers)

Most upvoted comments

I’ve been investigating this a bit, but I have no time at the moment to fully understand how to implement something (will definitely try in the future), but I’ll post my findings here, maybe they help somebody else (or vaxry himself, I’ll tag him).

As mentioned, the problem is that apparently Hyprland is not exactly following the wayland protocol somewhere.

When a monitor is disabled, Hyprland is sending the finished and done signals via wl_roots (see my previous comment): this shouldn’t happen. It seems to me that the reason this is happening is in src/events/Monitors.cpp, in the last line of function listener_change. That call to wlr_output_manager_v1_set_configuration is what is (then) activating the wrong signals. I’m not sure whether this function shouldn’t be called at all in this case, or should be called but with a different CONFIG or g_pCompositor->m_sWLROutputMgr (aka wlr_output_manager_v1) state.

That said, I believe the problem is also in src/helpers/Monitor.cpp. I think the “actually completely destroy the monitor” signal is sent by wlr_output_manager_v1, whereas the current connection to wlr_output should be used for the “disabling monitor” signal. I’m not too sure about this, in general my plan is to read sway code to understand what they’re doing.

Once this is fixed, tools like kanshi or shikane can be correctly used in Hyprland too.

@vaxerski FYI

levnikmyskin on Oct 31, 2023

Hey, sorry to comment on a closed and “old” issue. Just wanted to report this conversation we’ve had on Gitlab regarding kind of the same problem. From the last comment of Hendrik Wolff (author of that Shikane tool):

I just went over to #wlroots on Libera Chat, asked around and emersion clarified that hyprland behaves incorrectly. Adding that “[…] the main difference between wl_output and wlr_output_management_head [is that] the former goes away when disabled, but not the latter”. The wayland server should send the enabled event (with the 0 value) instead. If you need more explanations just head over to the #wlroots IRC channel.

Do you think that it could be possible to “update” Hyprland behaviour, Vaxry? (I’m available to help if necessary). Thanks 😃

levnikmyskin on Jun 2, 2023