Input does not draw after disconnect and reconnect keyboard by usb

[akunito]

Hi,

I have three monitors connected

Nvidia-dkms with suspend services enabled, following all steps from Hyprland wiki for Nvidia. (I feel there is a chance this is related to the issue)

lspci -k | grep -A 2 -E "(VGA|3D)"
01:00.0 VGA compatible controller: NVIDIA Corporation AD104 [GeForce RTX 4070] (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device 40ee
	Kernel driver in use: nvidia
--
11:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev cb)
	Subsystem: ASUSTeK Computer Inc. Device 8877
	Kernel driver in use: amdgpu

My hyprlock.conf is

#  _                      _            _    
# | |__  _   _ _ __  _ __| | ___   ___| | __
# | '_ \| | | | '_ \| '__| |/ _ \ / __| |/ /
# | | | | |_| | |_) | |  | | (_) | (__|   < 
# |_| |_|\__, | .__/|_|  |_|\___/ \___|_|\_\
#        |___/|_|                           
# 

background {
    monitor =
    path = $HOME/Pictures/system/lock3.png   # only png supported for now
    # all these options are taken from hyprland, see https://wiki.hyprland.org/Configuring/Variables/#blur for explanations
    blur_passes = 1 # 0 disables blurring
    blur_size = 2
    # noise = 0.0117
    # contrast = 0.8916
    brightness = 0.2
    # vibrancy = 0.1696
    # vibrancy_darkness = 0.0
}

input-field {
    monitor =
    size = 200, 50
    outline_thickness = 3
    dots_size = 0.33 # Scale of input-field height, 0.2 - 0.8
    dots_spacing = 0.15 # Scale of dots' absolute size, 0.0 - 1.0
    dots_center = true
    dots_rounding = -1 # -1 default circle, -2 follow input-field rounding
    outer_color = rgb(151515)
    inner_color = rgb(200, 200, 200)
    font_color = rgb(10, 10, 10)
    fade_on_empty = true
    fade_timeout = 1000 # Milliseconds before fade_on_empty is triggered.
    placeholder_text = <i>Input Password...</i> # Text rendered in the input box when it's empty.
    hide_input = false
    rounding = -1 # -1 means complete rounding (circle/oval)
    check_color = rgb(204, 136, 34)
    fail_color = rgb(204, 34, 34) # if authentication failed, changes outer_color and fail message color
    fail_text = <i>$FAIL <b>($ATTEMPTS)</b></i> # can be set to empty
    fail_transition = 300 # transition time in ms between normal outer_color and fail_color
    capslock_color = -1
    numlock_color = -1
    bothlock_color = -1 # when both locks are active. -1 means don't change outer color (same for above)
    invert_numlock = false # change color if numlock is off
    swap_font_color = false # see below
    position = 0, -20
    halign = center
    valign = center
}

label {
    monitor =
    text = cmd[update:1000] echo "$TIME"
    color = rgba(200, 200, 200, 1.0)
    font_size = 55
    font_family = Fira Semibold
    position = -100, -200
    halign = right
    valign = bottom
    shadow_passes = 5
    shadow_size = 10
}

label {
    monitor =
    text = $USER
    color = rgba(200, 200, 200, 1.0)
    font_size = 20
    font_family = Fira Semibold
    position = -100, 160
    halign = right
    valign = bottom
    shadow_passes = 5
    shadow_size = 10
}

I will update if I find any solution.

Thanks
BR

[vaxerski]

does it register though? As in, you can log back in

[ArtemSmaznov]

I am not sure what the reporters issue is exactly but I sounds a bit like what I am experiencing.
I am disconnecting my keyboard to use it with my work computer and while I'm working hypridle locks my screens with hypridle (as I want it to) but when I plug my keyboard back up there is a 50% change that I will not be able to type my password and have to switch to TTY to kill hyprlock.

Is this what you are experiencing? If so then I believe this might be the same issue as #101 but with USB reconnect rather than suspend (which probably is the same thing under the hood). I say so because I tried typing things, then killed hyprlock and saw my typed text in the browser input field so this does seem like a focus issue as was mentioned on that ticket.

Unless, of course, what you are experiencing is different.

PS

I haven't rebuilt in a week or two so can't say if this is still present in latest master. Hard to test as well given that this is not consistent. Maybe not having a window visible before lock make a difference - need to test it more.

[akunito]

I am not sure what the reporters issue is exactly but I sounds a bit like what I am experiencing. I am disconnecting my keyboard to use it with my work computer and while I'm working hypridle locks my screens with hypridle (as I want it to) but when I plug my keyboard back up there is a 50% change that I will not be able to type my password and have to switch to TTY to kill hyprlock.

Is this what you are experiencing? If so then I believe this might be the same issue as #101 but with USB reconnect rather than suspend (which probably is the same thing under the hood). I say so because I tried typing things, then killed hyprlock and saw my typed text in the browser input field so this does seem like a focus issue as was mentioned on that ticket.

Unless, of course, what you are experiencing is different.

PS

I haven't rebuilt in a week or two so can't say if this is still present in latest master. Hard to test as well given that this is not consistent. Maybe not having a window visible before lock make a difference - need to test it more.

Yes, it sounds exactly the same issue I have.
Yesterday however I didn't experienced this, so that would match too. I don't know in which percentage happens.
Switching TTY worked for me too, I didn't try to kill hyprlock but reboot. It just happened twice to me. Next time if it would happen, I will try to kill it.

[akunito]

After some days with the issue I can say that it happens always if I disconnect keyboard and then connect it again.
I tried to keep another keyboard connected, but It does not change anything.
When I come back, I cannot type anything.
I tried to change TTY and kill hyprlock, but that did't help at all. I had to restart.
For now I'm keeping idle inhibitor ON by Waybar, at least during the time I'm working and I need to switch the keyboard to the work computer.

I cannot think in any other solution. Probably I will have to change to swaylock or any alternative, but for now I will wait as it's not a blocker.

[ArtemSmaznov]

hm, strange that it doesn't happen to me 100% as well. Also, I had a very similar if not the same issue with swaylock so maybe this is the issue with hyprland or wayland itself rather than hyprlock.

[paradon]

I'm also seeing this (in 0.3.0), and I seem to be able to reproduce it pretty reliably by running "sleep 5; hyprlock" and disconnecting the keyboard before hyprlock activates.

If hyprlock activates before the keyboard is disconnected, the problem doesn't occur.

[ArtemSmaznov]

A few weeks ago I updated and been running v0.40.0-27-g5e7925ea (5e7925eaeba474cfc283e26b7aa3426ec97424f7) of hyprland and have not experienced this issue once. Not sure if it is fixed or if I have been incredibly lucky so far.

Also, before updating I was locking my screen before disconnecting the keyboard and that have been smooth for almost a month prior. Was having issue on the same version while letting it idle to lock while having keyboard disconnected.

Take it as you will.

[PaideiaDilemma]

Currently not an issue it seems.