Ok so the bug originates form the fact that the driver is not in initrd? I'm far from a kernel developper, so what could my next step be? -Do you have enough information for now, (ergo, I do nothing)? -Should I re-file this bug with the initrd guys? -Should I file a bug that the kernel Makefile default settings are not up to par (since 'make install' creates the initrd image)? -Or should I do something else? Op 08-07-15 om 16:55 schreef Jiri Kosina: > On Wed, 8 Jul 2015, Jiri Kosina wrote: > >>>>>> Bug as submitted on: https://bugzilla.kernel.org/show_bug.cgi?id=100631 >>>>>> >>>>>> Mailing it to this mailing list on advice of greg k-h >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> Cannot use the logitech k520 (046d:c52b) to unlock my luks disk at boot time >>>>>> >>>>>> Hitting keyboard keys of this specific kayboard does not register while entering the disk unlock password >>>>>> >>>>>> In the 3.x mail line kernels this does work. >>>>>> in the 4.1 mainline kernel a corded hid keyboard does work but this specific keyboard does not work anymore. >>>>>> >>>>>> The keybaord works fine after boot >> >> Do you have the driver (hid-logitech-hidpp) present in the initrd? It >> needs to be loaded at the time you are trying to use the keyboard. > > To be more specific -- prior to the commit you bisected to, the keyboard > has been driven (in basic mode) by generic HID driver ('hid'). > > After that commit, it's being driven (in a full-featured mode) by hid++ > driver (hid-logitech-hidpp), and therefore you need to have that driver > present in any environment you are willing to use the keyboard in. > > That should normally be handled by your mkinitrd (or whatever mechanism > you are using to generate the initrd) though. > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
