[Bug] Login prompt not centered on boot #486

Have the same problem..

and only once i start typing in the details it gets centered.

For now, I can only guess this is a termbox problem (the library Ly uses for making a TUI interface).

Also is there a way to set one WM/Desktop as the first preference?

Ly should use the last-used entry as the default.

Me too. But it only does so when multiple monitors are connected, say two. Just as the default unpatched dwm cursor positions itself when the desktop is loaded. It defaults to center of the two monitors, so does ly. The login prompt would position itself right where the cursor would have been

This issue only started appearing for me after the last update to ly in the arch repo. That was on 2023-06-15 and the version is 0.6.0-1
https://archlinux.org/packages/?name=ly

Same issue here

Same. Started appearing in 0.6.0.

Same

I have the same issue on arch with a build of the current state on master. Any updates on this issue? I don't have a second monitor nor have I every connected one to this laptop so that's not the source of the issue for me @Pheon-Dev

At least now the bug can be zeroed down further. For now I'm using lemurs which is also a minimal login manager that has worked great for me so far

In trying (and succeeding) to change the colors of ly, I've stumbled upon a workaround fix for this issue. As the box centers as soon as I type the first character of my password, the following ExecStartPre not only changes the colors of ly (first hex is bg, second hex is fg) but also "simulates user input" I guess and therefore automatically centers the box:

# in /etc/systemd/system/display-manager.service
# ...
[Service]
# ...
ExecStartPre=/usr/bin/printf '%%b' '\e]P0DED8C9\e]P70E313A\ec'
ExecStart=/usr/bin/ly
# ...

I had the same issue with qtile on arch and nvidia graphics card, I noticed that after installing CUDA nvidia package from the repo fixed the problem. I don't know why tho.

Same issue here with Arch master. As others stated above, user input centers it back to normal.

Same issue - user input centers it.

Also getting same issue. It's rather frustrating because of the expectation of a clean TUI environment something like ly should have. Unsure why it doesn't centre until user input is given.

@cprin21 a bit late but I have since moved to greetd using tuigreet and it has been a flawless (if not better) substitute ever since. I recommend you give it a try if you fancy that ly aesthetic.

Thanks! Not late at all. Checked it out and haven't had any top-left greeter moments.

Any updates on this? I have the same problem, but even when typing the login pane isn't centered. I'm using Arch, as display managers I have dwm and Gnome

@marcocamilo Do you have 2 monitors with different resolutions, by any chance?

No, not at all. Im using it on my macbook. Do I have to set the definition somehow by default inside the tty?

Marco-Andrés Camilo-Pietri
On Aug 7, 2024 at 01:05 +0200, ShiningLea @.***>, wrote:

@marcocamilo Do you have 2 monitors with different resolutions, by any chance?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Hm, then that's an odd one. You shouldn't have to set the resolution in the TTY yourself since it should just pick the highest one available.

Not sure if there are several different issues causing problems for everyone here, but here's how I've gotten Ly to use the full 4k main monitor even though I have a smaller side monitor as well.

Seems like the smallest monitor's size is used to set the TTY frame buffer size (which is being mirrored on all displays). That is why you see Ly (or the console for that matter) taking up only a portion of your larger screen starting from top left.

I've fixed it on my Debian bookworm with a systemd service to resize the frame buffer just before Ly starts:

$ cat /etc/systemd/system/fbset.service
[Unit]
Description=Framebuffer resolution
Before=display-manager.service

[Service]
Type=oneshot
User=root
ExecStart=/usr/bin/fbset -xres 3840 -yres 2160 -match --all
RemainAfterExit=yes
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Don't forget to systemctl daemon-reload and systemctl enable fbset. I was also missing the util itself so had to apt install fbset.

Linking #366 here for reference

@Tadas Thank you! This fixed it for me on Arch. I have a monitor connected through an adapter which I suspect is constantly reporting itself as even when it's turned off as Ly, Lemurs, and Greetd were getting resized on my main monitor. Now Ly is perfectly centered, this did the trick.

Not sure if there are several different issues causing problems for everyone here, but here's how I've gotten Ly to use the full 4k main monitor even though I have a smaller side monitor as well.

Seems like the smallest monitor's size is used to set the TTY frame buffer size (which is being mirrored on all displays). That is why you see Ly (or the console for that matter) taking up only a portion of your larger screen starting from top left.

I've fixed it on my Debian bookworm with a systemd service to resize the frame buffer just before Ly starts:

$ cat /etc/systemd/system/fbset.service
[Unit]
Description=Framebuffer resolution
Before=display-manager.service

[Service]
Type=oneshot
User=root
ExecStart=/usr/bin/fbset -xres 3840 -yres 2160 -match --all
RemainAfterExit=yes
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Don't forget to systemctl daemon-reload and systemctl enable fbset. I was also missing the util itself so had to apt install fbset.

Linking #366 here for reference

I have the same problem with a 1440p main and a 1080p side monitor, I have adjusted the resolution in the service file accordingly but it still fails to start. In terminal it works fine. Any idea why it might be happening?

Feb 26 21:39:52 lp-linux fbset[632]: open /dev/fb0: No such file or directory
Feb 26 21:39:51 lp-linux systemd[1]: Starting Framebuffer resolution...
Feb 26 21:39:51 lp-linux systemd[1]: fbset.service: Main process exited, code=exited, status=1/FAILURE
Feb 26 21:39:51 lp-linux systemd[1]: fbset.service: Failed with result 'exit-code'.
Feb 26 21:39:51 lp-linux systemd[1]: Failed to start Framebuffer resolution.```

I believe this can be properly fixed by making the code multi-threaded, as any input seems to solve the issue (because it triggers a screen refresh).