hid-generic regression on existing distros

hid-generic regression on existing distros

[Jan Beulich]

Henrik, Jiri,

commit 8215d557e5f3a70e50e07c857d35c250fee62a73 results
in no keyboard or mouse during early boot on systems where
those are USB-based and HID=m, since nothing there can
possibly be aware that this new driver needs to be manually
loaded for e.g. interactive startup mode to be useful, as it would
have to make it into initrd, yet the mkinitrd machinery can't
reasonably know of it.

Imo, with the functionality having been previously provided
by usbhid.ko, that module should cause hid-generic to be
pulled in automatically.

(Also, just as a side note, a Kconfig default of 'y' is pointless
for a tristate option that depends on another tristate one,
when that one was already set to 'm' - the default really
should be the value of the depended upon symbol.)

Jan

Re: hid-generic regression on existing distros

[Henrik Rydberg]

Hi Jan,

> commit 8215d557e5f3a70e50e07c857d35c250fee62a73 results
> in no keyboard or mouse during early boot on systems where
> those are USB-based and HID=m, since nothing there can
> possibly be aware that this new driver needs to be manually
> loaded for e.g. interactive startup mode to be useful, as it would
> have to make it into initrd, yet the mkinitrd machinery can't
> reasonably know of it.

This is obviously distro-specific, since there are ramdisk programs
which make use of udev (mkinitcpio, for one).  The mkinitrd machinery
cannot reasonably know about HID either, and some distributions use
HID=y, which creates its own set of problems. Either way, your
question really boils down to whether module name changes and the
like, which affect manual initrd setups, are considered user-space
breakage or not. I will leave that question to Jiri.

> Imo, with the functionality having been previously provided
> by usbhid.ko, that module should cause hid-generic to be
> pulled in automatically.

The split was made especially to avoid this. The "hid" module used to
contain both the bus driver and the generic hid driver. It is now only
a bus driver, and the rest of the hid drivers optionally (and
automatically, using udev) hook on to that bus. Saying that all hid
devices carried over usb must load a certain driver is the same as
saying that all pci-based devices must be handled be the same
driver. Convenient, perhaps, but not very practical.

> (Also, just as a side note, a Kconfig default of 'y' is pointless
> for a tristate option that depends on another tristate one,
> when that one was already set to 'm' - the default really
> should be the value of the depended upon symbol.)

Thanks, overall the Kconfig seems to need updating. I will look into it.

Henrik