Can't temporarily disable monitor using external tools
Hyprland Version
System/Version info
Hyprland, built from branch at commit cba1ade848feac44b2eda677503900639581c3f4 ().
Date: 2024-05-04
Tag: , commits: @COMMITS@
flags: (if any)
System Information:
System name: Linux
Node name: upaya
Release: 6.6.30
Version: #1-NixOS SMP PREEMPT_DYNAMIC Thu May 2 14:32:50 UTC 2024
GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA controller])
os-release: BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="23.11.20240504.651b470"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 23.11 (Tapir)"
SUPPORT_END="2024-06-30"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="23.11 (Tapir)"
VERSION_CODENAME=tapir
VERSION_ID="23.11"
plugins:
Bug or Regression?
Bug
Description
With 0.39.1, you could disable or enable a monitor using other tools, e.g. kanshi or wdisplays. With 0.40, these tools no longer work. Once a monitor is disabled, hyprland immediately re-enables it. This is a problem for those us that regular get up from their desks and plug and unplug to external monitors multiple times a day. On Discord, it was suggested to just manually update hyprland config, but this isn't a great solution as it involves reloading hyprland, and a rebuild if you are on nixos.
How to reproduce
Have a laptop plugged into an external monitor. Use wdisplays to disable the laptop monitor. Note that it turns back on immediately.
Crash reports, logs, images, videos
No response
patch.txt try
Compiled and ran, same problem.
Can confirm, since hyprland v40, kanshi can no longer disable monitors permenantly. Hyprland immediatly reenables it.
Same issue here. FWIW, doing a git bisect shows that the issue was introduced somewhere between 8a2269272b6a9752cd48097e19c0bc0f3bdab191 and cba1ade848feac44b2eda677503900639581c3f4. (For some reason I couldn't build any of the in-between commits, sorry)
~~Does this issue also apply to laptop screen not "hibernating" when closing the lid?~~
Edit: turns out I didn't have hypridle properly configured. Thanks @tinmarr
I use hypridle/hyprlock and that seems to be working fine on my thinkpad.
I also have the other issues faced.
I'm investigating this.
When the WL client sends the request, Events::listener_monitorStateRequest is received. This calls Renderer::applyMonitorRule, which then sets g_pConfigManager->m_bWantsMonitorReload to true.
Now, while Monitor::onDisconnect is correctly called, and the monitor is disabled, the issue (unless I missed something) seems to be in the reload itself.
When CConfigManager::performMonitorReload is called, getMonitorRuleFor called on the disabled monitor returns the rule where the monitor was still enabled.
From what I see, the monitor activeMonitorRule is changed, but then this has no effect on the rules CConfigManager reads?
@vaxerski where would be the most appropriate place to change this so that CConfigManagermonitor rules are also updated?
listener_monitorStateRequest is not called here, furthermore, those events are ignored for real displays
Mmm yeah I was testing on a hyprland debug build, running as a window. But the rest of the calls should still happen right?
Anyway, I'll take another look later and come back either to this issue or open a PR if I find a fix :)
Hey everybody, could you check that my PR fixes this problem for you? https://github.com/hyprwm/Hyprland/pull/6136
Thanks @levnikmyskin, I'm trying to patch 0.40.0 on Nix and it fails to build. I'd try the main branch but that fails to build patched or not. Perhaps someone on a different OS could try it.
I have tested it on nixos and unfortunately it does not work. External screen keeps being reactivated it when disabled using wdisplays
Thanks @levnikmyskin, I'm trying to patch 0.40.0 on Nix and it fails to build. I'd try the main branch but that fails to build patched or not. Perhaps someone on a different OS could try it.
You shall be able to build it with the following overrides in your flake and using master as nixpkgs source:
hyprland = prev.hyprland.overrideAttrs (prev: rec {
version = "unstable";
src = final.fetchFromGitHub {
owner = "levnikmyskin";
repo = "hyprland";
fetchSubmodules = true;
rev = "2e74d4e4316fa251e04742ffe2fe2def3a54134b";
hash = "sha256-19tEW0II2ExxBQbfDGg6FL2lAdKzBC4AWADAK4zWyX8=";
};
});
hyprwayland-scanner = prev.hyprwayland-scanner.overrideAttrs
(prev: rec {
version = "0.3.8";
src = final.fetchFromGitHub {
owner = "hyprwm";
repo = "hyprwayland-scanner";
rev = "v0.3.8";
hash = "sha256-/DwglRvj4XF4ECdNtrCIbthleszAZBwOiXG5A6r0K/c=";
};
});
@aacebedo that's weird, are you sure you're not using any other tool to manage your monitors? It works for me. I've noticed though that when trying to re-enable the monitor through kanshi (on my branch), that doesn't work anymore, probably due to the changes I've made.
@aacebedo that's weird, are you sure you're not using any other tool to manage your monitors? It works for me. I've noticed though that when trying to re-enable the monitor through kanshi (on my branch), that doesn't work anymore, probably due to the changes I've made.
Double checked and confirm that it is not working. wdisplays crashes just after un click apply and the screen gets reenabled right after. I do not have any other software running that would change those settings
Interesting. Could you try with kanshi (that's what I'm using to test)? Just making sure that it is not a tool problem
Interesting. Could you try with kanshi (that's what I'm using to test)? Just making sure that it is not a tool problem
Same result with kanshi. Internal laptop screen does not stay off
are you on my latest commit? f596516f1a9099175bfedbc7f9bf3aab31035bc2
are you on my latest commit?
f596516f1a9099175bfedbc7f9bf3aab31035bc2
I was using the commit on your branch (2e74d4e4316fa251e04742ffe2fe2def3a54134b) and as you rebased on upstream master it shall be ok. I'll try 643193e52a3f146f620a3bc8bc93ac1f70a4b5d3
are you on my latest commit?
f596516f1a9099175bfedbc7f9bf3aab31035bc2
Unfortunately, same result with 643193e52a3f146f620a3bc8bc93ac1f70a4b5d3. Maybe somebody else could confirm?
Yes let's wait for somebody else to also report on this. You could share your logs in the mesntime, could be helpful
I can confirm that https://github.com/levnikmyskin/Hyprland/commit/07c342bfda933bc89191bef8a63b3d6b6b37da82 has fixed the issue for me - ~~kanshi is now working as expected~~ I can toggle displays on and off in wdisplays. Thank you @levnikmyskin!
Here are the logs, if useful: hyprland.log
Edit: Interestingly, kanshi doesn't seem to be working fully - It successfully applies the initial config, but it doesn't enable the laptop display upon unplugging my monitor. Looking at kanshi's output, it seems that it isn't detecting the HDMI cable being unplugged. Not sure if this is related to this issue or something entirely different. Will test on swaywm to see if this is a kanshi-specific or Hyprland-specific issue.
Happy to hear that :) @aacebedo could you attach your logs? I wouldn't know why it's not working on your side
@neelkarma could you check that it works if you manually ask kanshi to re-enable the monitor? For example, in your kanshi config, put something like:
profile onlyone {
output HDMI-something enable ...
output eDP-1 disable # this is your internal monitor
}
# probably good to also set positions here
profile both {
output HDMI-something enable ...
output eDP-1 enable
}
Then, once your monitor is disabled, run kanshictl switch both.
Edit: also, attach your logs when disconnecting HDMI. If it's related to my changes, I'll address this in the PR. Otherwise, it'd be better to open another issue
In this logfile, I:
- Opened hyprland (this starts kanshi as well)
- Unplugged the HDMI cable (kanshi does not detect this)
- Open a new terminal and type
kanshi switch undocked(I have different names for the profiles) - The profile switches successfully - Plug the HDMI cable back in (kanshi recognizes this, and applies the correct profile successfully)
- Exit hyprland
Hope this helps!
Also, I tried on sway, and it worked correctly, so this is probably a hyprland-specific issue.
@neelkarma mmh, I can see from the logs that the HDMI monitor is correctly destroyed by Hyprland. This should indeed send the finished event.
Could you run kanshi with WAYLAND_DEBUG=1 kanshi, unplug the monitor, and upload the logs here? I'll also check on my machine to see if Hyprland is sending the finished event correctly (looking at the code, it seems like it should)
Tested on 07c342bfda933bc89191bef8a63b3d6b6b37da82 and confirm it is working with kanshi now. However, when I unplug HDMI, internal monitor is not reenabled as for @neelkarma, I managed to do it using wdisplays though. That is still very unstable unfortunately.
@neelkarma mmh, I can see from the logs that the HDMI monitor is correctly destroyed by Hyprland. This should indeed send the finished event.
Could you run kanshi with
WAYLAND_DEBUG=1 kanshi, unplug the monitor, and upload the logs here? I'll also check on my machine to see if Hyprland is sending the finished event correctly (looking at the code, it seems like it should)
Could you guys try now (commit 2ad0038 (#6136))? I think the problem was that Hyprland was not sending the done event after the finished event. So, kanshi was basically waiting forever to receive it.
EDIT: PLEASE if it doesn't work, attach hyprland logs + kanshi logs (with WAYLAND_DEBUG=1 as before)
Edit: Interestingly,
kanshidoesn't seem to be working fully - It successfully applies the initial config, but it doesn't enable the laptop display upon unplugging my monitor. Looking atkanshi's output, it seems that it isn't detecting the HDMI cable being unplugged. Not sure if this is related to this issue or something entirely different. Will test on swaywm to see if this is a kanshi-specific or Hyprland-specific issue.
That seems like another issue that has existed much longer than this issue. In fact, I've never got hyprland working in this way. I think we should probably test with wlr-randr --output <output> off (and back on) at this time instead of testing whether recovering monitor is available during detaching output.