[patch] add keymap data to make random laptop vendor keys work
Bastien Nocera
hadess at hadess.net
Fri May 4 17:30:33 PDT 2007
On Fri, 2007-05-04 at 18:01 +0100, Richard Hughes wrote:
> On Fri, 2007-05-04 at 17:48 +0100, Bastien Nocera wrote:
> >
> > Lennart just told me he wrote a kernel module to export DMI
> > information
> > in modalias, so that driver that we could potentially load driver, and
> > keytables from udev rules, rather than from HAL.
>
> That's assuming we are just matching on dmi-data, what about the other
> data probers such as PMU (or other data sources like smapi)? We also
> want to be doing this at runtime as well (for instance plugging in a
> multimedia USB keyboard) rather than just at boot time.
What else did you want to match for? For non-PC-style systems (such as
G3/G4 laptops), they use ADB keyboards, and drivers, which have all
their keys working.
Newer revisions of the G4 laptops, and the Intel ones have builtin USB
keyboards, which already work properly. For all the other types of USB
keyboards, we can unbreak them in the kernel, in the drivers.
The only use-case of this hack is for PC-style laptops with AT
keyboards. For this particular case, given what a mess the AT keyboard
driver already is, I can understand that we'd want the matching in
user-space. But it's in a much better place in udev than it would be in
HAL.
I've changed my mind. This should be fixed at a lower-level...
> > It would also allow to load drivers such as ibm-laptop, sonypi, dcbdas
> > (or whatever that Dell module is called) automatically, without hacks
> > in startup scripts.
>
> Yes, I think loading modules is okay based on dmi data, but putting the
> DMI matching in shell in udev rules (each done once per file) is a
> little bit hackish (although I'm biased ;-) - also we would have to tell
> distros to update their udev packages every few weeks, rather than
> hal-info.
Same thing, they're just a bunch of files that bolt onto an existing
package. I'm sure the maintainer of udev for your favourite distro will
take whole files to add to the package :)
--
Bastien Nocera <hadess at hadess.net>
More information about the hal
mailing list