Search the Community
Showing results for tags 'keyboard'.
Found 1 result
Over time I have experienced problem that my keyboard does not work during early boot, the time where I am supposed to make key-map selection on system-rescue-cd, but - more important - at the time I am expected to enter encryption key to unlock my encrypted partitions. If I end up in rescue mode I can't do anything, not even ctrl-alt-delete to reboot. I have had the problem on my current and previous hardware if I am using debian-sources (4.8 and 4.14). I have this problem with all kernels I have tested with my present hardware (ASUS Prime Z370). Naturally it failes with my ordinary logitech k750 keyboard but it also fails with a ordinary plain USB cable connected USB-keyboard. I have played around with different settings in kernel (gentoo-sources) to build in or not support for USB, logitech modules, the fundamental USB HIDBP, etc and cannot observe any difference during boot (but I managed to disable mouse in KDE). I can see that the logitech modules are loaded when booting debian-kernel but it still wont work. This is the latest dmesg where HID is loaded [ 1.239301] hidraw: raw HID events driver (C) Jiri Kosina [ 1.239542] usbcore: registered new interface driver usbhid [ 1.239780] usbhid: USB HID core driver . . . [ 20.619928] logitech-djreceiver 0003:046D:C52B.0003: hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-5.1/input2 [ 20.732809] input: Logitech K750 as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.2/0003:046D:C52B.0003/0003:046D:4002.0005/input/input9 [ 20.732897] logitech-hidpp-device 0003:046D:4002.0005: input,hidraw2: USB HID v1.11 Keyboard [Logitech K750] on usb-0000:00:14.0-5.1:1 [ 21.154637] usbcore: registered new interface driver snd-usb-audio [ 25.298802] logitech-hidpp-device 0003:046D:4002.0005: HID++ 2.0 device connected. I am quite sure that luks is opened long before the 20 seconds and the HID is hidraw. The very same rows with the very same keyboard on a working setup where I can enter the password: One difference I found is that in a working boot (where keyboard is working) the same rows as above seems to happen earlier: Dec 30 09:20:37 nuffsan kernel: [ 2.440038] usb 8-2.1: new full-speed USB device number 4 using xhci_hcd Dec 30 09:20:37 nuffsan kernel: [ 2.624861] usb 8-2.1: New USB device found, idVendor=046d, idProduct=c52b Dec 30 09:20:37 nuffsan kernel: [ 2.624866] usb 8-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 30 09:20:37 nuffsan kernel: [ 2.624869] usb 8-2.1: Product: USB Receiver Dec 30 09:20:37 nuffsan kernel: [ 2.624872] usb 8-2.1: Manufacturer: Logitech Dec 30 09:20:37 nuffsan kernel: [ 2.628778] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb8/8-2/8-2.1/8-2.1:1.0/0003:046D:C52B.0001/input/input5 Dec 30 09:20:37 nuffsan kernel: [ 2.680543] hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input0 Dec 30 09:20:37 nuffsan kernel: [ 2.683897] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb8/8-2/8-2.1/8-2.1:1.1/0003:046D:C52B.0002/input/input6 Dec 30 09:20:37 nuffsan kernel: [ 2.735411] hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input1 Dec 30 09:20:37 nuffsan kernel: [ 2.738136] hid-generic 0003:046D:C52B.0003: hiddev1,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.0-2.1/input2 . . . Dec 30 09:20:38 nuffsan kernel: [ 12.393989] cryptsetup (4105) used greatest stack depth: 13648 bytes left Dec 30 09:20:38 nuffsan kernel: [ 20.241508] cryptsetup (4179) used greatest stack depth: 13520 bytes left Password was entered before 12 and 20 seconds. I use the very same and slightly modified linuxrc and initrd.scripts. Modification is an own luks open function that is similar but independent from the cryptroot-stuff. Instead I open encrypted partitions specified at kernel line in specified order right before BTRFS scan is performed. Eventually I might send a patch. I have tried the solution mentioned in https://forums.gentoo.org/viewtopic-t-1063372.html but it didn't work.