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

[lukeflo]

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

• niri version: niri 0.1.10 (unknown commit)

• Distro: Void Linux x86_64

• GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]

• CPU: 11th Gen Intel i5-1135G7 (8) @ 4.200GHz

[YaLTeR]

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

[lukeflo]

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

[YaLTeR]

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

[lukeflo]

Yes, but I'm not on systemd 😄

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]

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

[lukeflo]

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

[lukeflo]

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

That way, I was able to generate some output:

�[2m2024-11-11T09:49:02.530017Z�[0m �[32m INFO�[0m �[2mniri�[0m�[2m:�[0m starting version 0.1.10 (unknown commit)
�[2m2024-11-11T09:49:02.555131Z�[0m �[34mDEBUG�[0m �[2mniri_config�[0m�[2m:�[0m loaded config from "/home/lukeflo/.config/niri/config.kdl"
�[2m2024-11-11T09:49:02.687971Z�[0m �[32m INFO�[0m �[2mniri::backend::tty�[0m�[2m:�[0m using as the render node: "/dev/dri/renderD128"
�[2m2024-11-11T09:49:02.783252Z�[0m �[33m WARN�[0m �[2mniri::niri�[0m�[2m:�[0m error connecting to PipeWire, screencasting will not work: error creating Core

Caused by:
    Creation failed
�[2m2024-11-11T09:49:02.783938Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m device added: 57856 "/dev/dri/card0"
�[2m2024-11-11T09:49:03.108868Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m this is the primary node
�[2m2024-11-11T09:49:03.108892Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m this is the primary render node
�[2m2024-11-11T09:49:03.138577Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m device changed: 57856
�[2m2024-11-11T09:49:03.913924Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m new connector: eDP-1 "AU Optronics 0x208D Unknown"
�[2m2024-11-11T09:49:03.913955Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m new connector: HDMI-A-1 "Dell Inc. DELL P2412H TTMDG27O0NMU"
�[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"
�[2m2024-11-11T09:49:17.506030Z�[0m �[34mDEBUG�[0m �[2mniri::input�[0m�[2m:�[0m lid switch opened
�[2m2024-11-11T09:49:17.506139Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m connecting connector: eDP-1
�[2m2024-11-11T09:49:17.506182Z�[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:17.506223Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m set max bpc to 8
�[2m2024-11-11T09:49:17.510210Z�[0m �[34mDEBUG�[0m �[2mniri::niri�[0m�[2m:�[0m putting output eDP-1 at x=1920 y=0
�[2m2024-11-11T09:49:22.782456Z�[0m �[34mDEBUG�[0m �[2mniri::input�[0m�[2m:�[0m lid switch closed
�[2m2024-11-11T09:49:22.782512Z�[0m �[34mDEBUG�[0m �[2mniri::backend::tty�[0m�[2m:�[0m 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]

�[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]

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]

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]

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]

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]

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]

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

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

[lukeflo]

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]

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]

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).