new modular hid?

new modular hid?

[Michael Tokarev]

Hello.

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...

Thanks!

/mjt

Re: new modular hid?

[Jiri Kosina]

[ 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...
> 
> Thanks!
> 
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Jiri Kosina
SUSE Labs

Re: new modular hid?

[Dmitry Torokhov]

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

Re: new modular hid?

[Jiri Kosina]

On Mon, 12 Jan 2009, Dmitry Torokhov wrote:

> 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.

It might seem a too bit too much fine-grained right now, but my 
longer-term plan was to have more sophisticated drivers also register 
themselves to the HID bus, make use of the common parser, etc (Wacom comes 
to mind, for example). 

Having the quirks grouped together rather than nicely separate would then 
bring us close to the previous total mess, when unrelated quirks were 
glued together randomly in the spaghetti-code-way, which I really would 
like to avoid as much as possible, it started to become unmaintainable.

-- 
Jiri Kosina

Re: new modular hid?

[Jiri Kosina]

On Tue, 13 Jan 2009, Jiri Kosina wrote:

> > 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.
> It might seem a too bit too much fine-grained right now, but my 
> longer-term plan was to have more sophisticated drivers also register 
> themselves to the HID bus, make use of the common parser, etc (Wacom comes 
> to mind, for example). 
> Having the quirks grouped together rather than nicely separate would then 
> bring us close to the previous total mess, when unrelated quirks were 
> glued together randomly in the spaghetti-code-way, which I really would 
> like to avoid as much as possible, it started to become unmaintainable.

That being said, we of course need to think about the initrd issue brought 
up by Michael.

Compiling everything into single driver back again in the end would of 
course be a solution, but I am afraid that it'd be quite difficult with 
the bus infrastructure in place.

-- 
Jiri Kosina
SUSE Labs

Re: new modular hid?

[Dmitry Torokhov]

On Tue, Jan 13, 2009 at 10:00:52AM +0100, Jiri Kosina wrote:
> On Tue, 13 Jan 2009, Jiri Kosina wrote:
> 
> > > 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.
> > It might seem a too bit too much fine-grained right now, but my 
> > longer-term plan was to have more sophisticated drivers also register 
> > themselves to the HID bus, make use of the common parser, etc (Wacom comes 
> > to mind, for example). 
> > Having the quirks grouped together rather than nicely separate would then 
> > bring us close to the previous total mess, when unrelated quirks were 
> > glued together randomly in the spaghetti-code-way, which I really would 
> > like to avoid as much as possible, it started to become unmaintainable.
> 
> That being said, we of course need to think about the initrd issue brought 
> up by Michael.
> 
> Compiling everything into single driver back again in the end would of 
> course be a solution, but I am afraid that it'd be quite difficult with 
> the bus infrastructure in place.

Not everything, just keyboards so they work even if userspace is not
quite there yet. We just need to make sure we initialize hid bus before
we register sub-drivers.

-- 
Dmitry

Re: new modular hid?

[Michael Tokarev]

Jiri Kosina wrote:
> On Tue, 13 Jan 2009, Jiri Kosina wrote:
> 
>>> 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.
>> It might seem a too bit too much fine-grained right now, but my 
>> longer-term plan was to have more sophisticated drivers also register 
>> themselves to the HID bus, make use of the common parser, etc (Wacom comes 
>> to mind, for example). 
>> Having the quirks grouped together rather than nicely separate would then 
>> bring us close to the previous total mess, when unrelated quirks were 
>> glued together randomly in the spaghetti-code-way, which I really would 
>> like to avoid as much as possible, it started to become unmaintainable.
> 
> That being said, we of course need to think about the initrd issue brought 
> up by Michael.
> 
> Compiling everything into single driver back again in the end would of 
> course be a solution, but I am afraid that it'd be quite difficult with 
> the bus infrastructure in place.

I'm not sure I understand.

Let's take a look at my example, hid_bright.  Without this module, my
keyboard does not work, even if usbhid&Co is loaded.  But this module
does exactly two things:

  hid_hw_start(hdev, HID_CONNECT_DEFAULT);
  usbhid_set_leds(hdev);

(modulo error checking and the like).  The leds (caps, scroll and num
locks) on this keyboard works without the last call (I just checked).
hid_hw_start() gets called from all other drivers too.  So *to me*
it looks like this subdriver does exactly nothing useful.  Yet
w/o it the (perfectly working before 2.6.28) keyboard does not
work.

Maybe, just maybe, it's possible to init stuff by default, and
get additional features or quirks later, when actually loading
the sub-driver?  But any way, this "doing nothing" driver thing
seems to be wrong...

It's even more (to me): I don't understand the "hid bus" thing to
start with.  How the autoload (with udev) works?  I don't see any
modalias things in this module, `modinfo hid_bright' shows nothing
useful, and there are no useful modalias files in /sys/bus/hid/
either.

What mess was before the split?  How it's different from the current
many-small-doing-nothing things?

Thanks!

/mjt

Re: new modular hid?

[Jiri Kosina]

On Wed, 14 Jan 2009, Michael Tokarev wrote:

> Let's take a look at my example, hid_bright.  Without this module, my 
> keyboard does not work, even if usbhid&Co is loaded.  But this module 
> does exactly two things:
> 
>   hid_hw_start(hdev, HID_CONNECT_DEFAULT);
>   usbhid_set_leds(hdev);
> Maybe, just maybe, it's possible to init stuff by default, and get 
> additional features or quirks later, when actually loading the 
> sub-driver?  But any way, this "doing nothing" driver thing seems to be 
> wrong...

Yes. And actually hid-bright and hid-dell drivers have been already 
removed in current Linus' tree, and the leds are handled in the generic 
code again. So in this particular case, things are exactly the same as 
they used to be before for your hardware.

Still, there are drivers that are more complicated and having the code in 
the generic code is not bearable, so we have to think about this and solve 
it anyway, even though this is not going to be a problem particularly for 
your system in 2.6.29.

-- 
Jiri Kosina