Input does not draw after disconnect and reconnect keyboard by usb
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
does it register though? As in, you can log back in
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.
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.
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.
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.
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.
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.
Currently not an issue it seems.