search

YaLTeR / niri

A scrollable-tiling Wayland compositor.
https://matrix.to/#/#niri:matrix.org
GNU General Public License v3.0
4.12k stars 123 forks source link

Despite closed LID on startup, bar is loaded on closed laptop screen #798

Open lukeflo opened 1 week ago

lukeflo commented 1 week ago

I recently upgraded to niri v.0.10.1 So far, everything works great despite one thing regarding the laptop LID.

Normally, when I boot my laptop, the LID is closed and I use my HDMI as main screen. Until the version upgrade I used a custom script to check if the LID is closed (which I wrote for my former sway setup). If so, the laptop screen was disabled and the HDMI was set as main output. It worked flawlessly with niri too.

Now, after the upgrade, I disabled the script because niri autodetects if the LID is opened. That works just fine regarding notifications and regular windows. But on startup my bar (yambar) is not shown on the HDMI screen. For some reasons it starts on the closed laptop screen.

I tried changing the way yambar is executed, but that doesn't change anything.

Its only working if I use my custom script again which now only on startup checks if the LID is open or closed and disables the laptop screen if needed.

After startup everything works fine with the new LID detection.

System Information

YaLTeR commented 1 week ago

Could you attach the full niri output when reproducing the issue?

lukeflo commented 1 week ago

Sure. Sorry for asking, how to access the output when running niri directly from my desktop manager and not from inside anther session?

YaLTeR commented 1 week ago

On systemd it's journalctl --user-unit=niri -b

lukeflo commented 1 week ago

Yes, but I'm not on systemd :smile:

I run Void Linux, with a locally merged PR for adding niri to xbps package manager.

I already checked the general logs of my distro, but are no error messages regarding niri. dmesg also doesn't show anything...

YaLTeR commented 1 week ago

Can you redirect the output? Like niri --session >niri.log

lukeflo commented 1 week ago

Have to try it. I'll come back to you as soon as I got some more informations

lukeflo commented 1 week ago

Can you redirect the output? Like niri --session >niri.log

That way, I was able to generate some output:

2024-11-11T09:49:02.530017Z  INFO niri: starting version 0.1.10 (unknown commit)
2024-11-11T09:49:02.555131Z DEBUG niri_config: loaded config from "/home/lukeflo/.config/niri/config.kdl"
2024-11-11T09:49:02.687971Z  INFO niri::backend::tty: using as the render node: "/dev/dri/renderD128"
2024-11-11T09:49:02.783252Z  WARN niri::niri: error connecting to PipeWire, screencasting will not work: error creating Core

Caused by:
    Creation failed
2024-11-11T09:49:02.783938Z DEBUG niri::backend::tty: device added: 57856 "/dev/dri/card0"
2024-11-11T09:49:03.108868Z DEBUG niri::backend::tty: this is the primary node
2024-11-11T09:49:03.108892Z DEBUG niri::backend::tty: this is the primary render node
2024-11-11T09:49:03.138577Z DEBUG niri::backend::tty: device changed: 57856
2024-11-11T09:49:03.913924Z DEBUG niri::backend::tty: new connector: eDP-1 "AU Optronics 0x208D Unknown"
2024-11-11T09:49:03.913955Z DEBUG niri::backend::tty: new connector: HDMI-A-1 "Dell Inc. DELL P2412H TTMDG27O0NMU"
2024-11-11T09:49:03.914372Z DEBUG niri::backend::tty: connecting connector: eDP-1
2024-11-11T09:49:03.914388Z DEBUG niri::backend::tty: picking mode: Mode { name: "1920x1080", clock: 141000, size: (1920, 1080), hsync: (2028, 2076, 2104), vsync: (1090, 1100, 1116), hskew: 0, vscan: 0, vrefresh: 60, mode_type: ModeTypeFlags(PREFERRED | DRIVER) }
2024-11-11T09:49:03.914423Z DEBUG niri::backend::tty: set max bpc to 8
2024-11-11T09:49:03.917292Z DEBUG niri::niri: putting output eDP-1 at x=0 y=0
2024-11-11T09:49:03.917300Z DEBUG niri::backend::tty: connecting connector: HDMI-A-1
2024-11-11T09:49:03.917316Z DEBUG niri::backend::tty: picking mode: Mode { name: "1920x1080", clock: 148500, size: (1920, 1080), hsync: (2008, 2052, 2200), vsync: (1084, 1089, 1125), hskew: 0, vscan: 0, vrefresh: 60, mode_type: ModeTypeFlags(PREFERRED | DRIVER) }
2024-11-11T09:49:03.917337Z DEBUG niri::backend::tty: set max bpc to 8
2024-11-11T09:49:03.918629Z DEBUG niri::niri: putting output HDMI-A-1 at x=0 y=0
2024-11-11T09:49:03.918636Z DEBUG niri::niri: putting output eDP-1 at x=1920 y=0
2024-11-11T09:49:03.918704Z  INFO niri: listening on Wayland socket: wayland-1
2024-11-11T09:49:03.918707Z  INFO niri: IPC listening on: /run/user/1000/niri.wayland-1.999.sock
2024-11-11T09:49:03.936941Z  WARN niri::dbus: disabling screencast support because we couldn't start PipeWire
2024-11-11T09:49:03.938179Z  WARN niri::cursor: error loading xcursor default@24: no default icon
2024-11-11T09:49:03.992793Z  WARN niri::cursor: error loading xcursor default@48: no default icon
2024-11-11T09:49:11.573965Z DEBUG niri::input: lid switch closed
2024-11-11T09:49:11.574018Z DEBUG niri::backend::tty: disconnecting connector: "eDP-1"
2024-11-11T09:49:17.506030Z DEBUG niri::input: lid switch opened
2024-11-11T09:49:17.506139Z DEBUG niri::backend::tty: connecting connector: eDP-1
2024-11-11T09:49:17.506182Z DEBUG niri::backend::tty: picking mode: Mode { name: "1920x1080", clock: 141000, size: (1920, 1080), hsync: (2028, 2076, 2104), vsync: (1090, 1100, 1116), hskew: 0, vscan: 0, vrefresh: 60, mode_type: ModeTypeFlags(PREFERRED | DRIVER) }
2024-11-11T09:49:17.506223Z DEBUG niri::backend::tty: set max bpc to 8
2024-11-11T09:49:17.510210Z DEBUG niri::niri: putting output eDP-1 at x=1920 y=0
2024-11-11T09:49:22.782456Z DEBUG niri::input: lid switch closed
2024-11-11T09:49:22.782512Z DEBUG niri::backend::tty: disconnecting connector: "eDP-1"

I start yambar through a little script since it has to wait a second for pipewire. In the config its:

config.kdl:

spawn-at-startup "/home/lukeflo/.config/niri/scripts/load_yambar.sh"

The script itself has the following content:

load_yambar.sh:

#!/usr/bin/env bash
sleep 2
exec yambar --log-level none --backend wayland &

But its the same behaviour if I start yambar from the config.kdl with:

spawn-at-startup "yambar" "--log-level" "none"
YaLTeR commented 1 week ago 
�[2m2024-11-11T09:49:03.914372Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m connecting connector: eDP-1
�[2m2024-11-11T09:49:03.914388Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m picking mode: Mode { name: "1920x1080", clock: 141000, size: (1920, 1080), hsync: (2028, 2076, 2104), vsync: (1090, 1100, 1116), hskew: 0, vscan: 0, vrefresh: 60, mode_type: ModeTypeFlags(PREFERRED | DRIVER) }
�[2m2024-11-11T09:49:03.914423Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m set max bpc to 8
�[2m2024-11-11T09:49:03.917292Z�[0m �[34mDEBUG�[0m �[2mniri::niri�[0m�[2m:�[0m putting output eDP-1 at x=0 y=0
�[2m2024-11-11T09:49:03.917300Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m connecting connector: HDMI-A-1
�[2m2024-11-11T09:49:03.917316Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m picking mode: Mode { name: "1920x1080", clock: 148500, size: (1920, 1080), hsync: (2008, 2052, 2200), vsync: (1084, 1089, 1125), hskew: 0, vscan: 0, vrefresh: 60, mode_type: ModeTypeFlags(PREFERRED | DRIVER) }
�[2m2024-11-11T09:49:03.917337Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m set max bpc to 8
�[2m2024-11-11T09:49:03.918629Z�[0m �[34mDEBUG�[0m �[2mniri::niri�[0m�[2m:�[0m putting output HDMI-A-1 at x=0 y=0
�[2m2024-11-11T09:49:03.918636Z�[0m �[34mDEBUG�[0m �[2mniri::niri�[0m�[2m:�[0m putting output eDP-1 at x=1920 y=0
�[2m2024-11-11T09:49:03.918704Z�[0m �[32m INFO�[0m �[2mniri�[0m�[2m:�[0m listening on Wayland socket: wayland-1
�[2m2024-11-11T09:49:03.918707Z�[0m �[32m INFO�[0m �[2mniri�[0m�[2m:�[0m IPC listening on: /run/user/1000/niri.wayland-1.999.sock
�[2m2024-11-11T09:49:03.936941Z�[0m �[33m WARN�[0m �[2mniri::dbus�[0m�[2m:�[0m disabling screencast support because we couldn't start PipeWire
�[2m2024-11-11T09:49:03.938179Z�[0m �[33m WARN�[0m �[2mniri::cursor�[0m�[2m:�[0m error loading xcursor default@24: no default icon
�[2m2024-11-11T09:49:03.992793Z�[0m �[33m WARN�[0m �[2mniri::cursor�[0m�[2m:�[0m error loading xcursor default@48: no default icon
�[2m2024-11-11T09:49:11.573965Z�[0m �[34mDEBUG�[0m �[2mniri::input�[0m�[2m:�[0m lid switch closed
�[2m2024-11-11T09:49:11.574018Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m disconnecting connector: "eDP-1"

Seems like the lid close event arrives ~8 seconds after the compositor start

lukeflo commented 1 week ago

That would explain the positioning of the bar on the wrong screen. Any ideas what causes that? AFAIK I have no specific settings which might interfer with the lid. If you need more informations, especially because systemd free Void might not be the most common setup, I'll try to provide them...

YaLTeR commented 1 week ago

Not sure. Niri just listens to libinput, so it gets the event whenever libinput sends it.

Could your yambar setup maybe react to the screen disappearing and reposition itself to another screen?

lukeflo commented 1 week ago

Could your yambar setup maybe react to the screen disappearing and reposition itself to another screen?

Thats very unlikely. Yambar is not that dynamic. In the docs it states explicitly that the bar is only started for the current screen and has to be manually started for a second one.

Its strange that the event is send so late. I assume libinput is also responsible for setting /proc/acpi/button/lid/LID0/state which is were my script gets the lid state from. And that is accessible directly (otherwise it wouldn't work). I'll try to investigate it a little bit...

YaLTeR commented 1 week ago

Another thing you could do is bind lid-open and lid-close to restart yambar: https://github.com/YaLTeR/niri/wiki/Configuration:-Switch-Events#lid-close-lid-open

I believe libinput uses an evdev switch event for the lid switch.

lukeflo commented 1 week ago

Ok, interesting. If I start niri directly from a tty running dbus-run-session niri --session it works just fine. The bar appears on the correct screen and the LID events are also recognized correctly.

Thus, it might have something to do with my desktop manager emptty and my login manager elogind. The logs tell me that elogind is responsible for handling the LID events:

2024-11-11T11:08:06.96829 auth.info: Nov 11 12:08:06 elogind-daemon[984]: Watching system buttons on /dev/input/event1 (Lid Switch)

But I couldn't figure out the particular reason, since even when running from a tty there is a delay between starting niri and receiving the lid event. It just doesn't have any effect on the bar placement...

YaLTeR commented 1 week ago

Well I guess this doesn't look like a niri issue then.

Still, try restarting yambar using the niri lid switch bindings?

lukeflo commented 1 week ago

Well I guess this doesn't look like a niri issue then.

Yes, very likely not. Therefore, I close the issue.

Still, try restarting yambar using the niri lid switch bindings?

Is possible, but since there can be multiple instances of yambar running which are all visible, I need to always kill the running processes manually and restart it then. Its easier to start the bar manually. But I will investigate that further and report if I have a solution...

lukeflo commented 1 day ago

Seems like the lid close event arrives ~8 seconds after the compositor

I encountered an interesting behaviour regarding the moment the close event arrives.

If I wait a few seconds after starting niri before performing any action, the LID event is sent relativley late:

2024-11-21T08:44:25.684461ZDEBUGniri::backend::tty disconnecting connector: "eDP-1"
2024-11-21T08:44:33.198558ZDEBUGniri::input lid switch closed

But if I hit a key immidiatley after starting niri, the LID event is sent in the moment I release the key:

2024-11-21T08:46:15.853333ZDEBUGniri::backend::tty disconnecting connector: "eDP-1"
2024-11-21T08:46:16.172584ZDEBUGniri::input lid switch closed

This could actually indicate that the cause lies with niri, even I'm not sure about that. But a hint could be that libinput sends it events to other processes which are not related to niri (e.g. setting /proc/acpi/button/lid/LID0/state) immidiatley and not just after the first key event is sent.

Do you have any ideas how this event sequence could be related to niri?

YaLTeR commented 21 hours ago

Huh. Well, niri just listens for any libinput event via this helper in Smithay. All events are processed right away.

So this might be libinput for some reason not sending the lid switch until some other key press. Or it could be a bug in Smithay or in the libinput wrapper (although I'd say this is unlikely since then it would probably manifest in some other way too).