On Tue, Jan 13, 2009 at 12:54:06AM +0100, Jiri Kosina wrote: > > [ added Jiri Slaby to CC ] > > On Mon, 12 Jan 2009, Michael Tokarev wrote: > > > I tried to run a new (2.6.28) kernel today, to discover that > > my keyboard does not work anymore. After investigation it > > turned out the keyboard is now handled by a hid-sub-driver, > > hid-bright, and it does not work if this (mostly one-liner) > > driver module is not loaded. > > > > udev/m.i.t works fine, it's the initramfs which is broken. > > I.e., there's no keyboard during initramfs stage, only when > > udev runs and loads everything - as much as i hate it, it > > becomes more and more mandatory, but that's another story. > > > > Before 2.6.28, I used to include usbhid into initramfs. > > Now, it's not sufficient anymore. > > > > So I've two questions: > > > > 1) which drivers to include into ramfs and load for a > > "generic USB keyboard" to work? Maybe from now on one > > have to use usbkbd instead of usbhid? I just want to > > be able to do some rescue stuff before actual system > > startup in case a system does not boot for whatever > > reason (root fs is corrupt or wrong raid1 replacement > > disk or whatever). > > > > 2) why all those tiny "subdrivers" in the first place? > > I looked into several of them, and they're mostly sort > > of quirks or some additional features or additional key > > (re)mapping. Why can't it all be done in the main driver > > instead, just like it is done for PCI bus for example? > > The amount of real-work code is tiny, modules are much > > bigger - both the resulting .ko files and all the > > init/exit wrappers in .c files... > > I would agree with Michael here, it looks like we went a bit overboard with HID quirks. I think sensible solution would be to merge quirks into 3-4 files (one per device type) and maybe even compile keyboard quirks into hid core. Of course if we see that there are big sub-drivers appear we can still have them split out. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
