[patch] add keymap data to make random laptop vendor keys work

Kay Sievers kay.sievers at vrfy.org
Wed May 9 05:35:47 PDT 2007


On 5/8/07, Lennart Poettering <mzuny at 0pointer.de> wrote:
> On Sun, 06.05.07 14:52, Richard Hughes (hughsient at gmail.com) wrote:
>
> > > > 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 :)
> >
> > Adding files to a SRPM will only fix the fedora case, which would
> > essentially get us to the same point that Ubuntu is at. This is the
> > wrong way to get hardware just working using patches to packages in a
> > non-cross-distro and non-cross-architecture way IMO.
>
> If I understood Kay correctly he'd be OK to add keyfuzz to his udev
> package as long as it is tiny. Not just now, since (as I mentioned
> before) during an initial phase the database will need to be updated
> often.

Sure, no problem to add a generic general useful tool. But udev
provides only infrastructure, and _very_ generic subsytem stuff
without any specific device-matches. It does not even provide "default
rules". All distros carry and install their own rules.

As already mentioned in this thread, it gets complicated if we start
to ship device-specific data, or vendor specific configurations with
udev. It does not do this today, and I think we don't want to do that
in the future.

Today there are two bigger repositories for device quirks, the kernel
and hal-info with it's fdi files. So I think new stuff like this
should go in the kernel, or in hal-info and not in just another
package we would need to update for new hardware. It's already a pain
with the so called "enterprise" releases; these old versions
constantly need to add support for new hardware, and that's already
hard enough.

I don't really care who is doing the configuration, be it udev or HAL,
whatever works better here, but I see a problem where the
vendor/device specific quirks are maintained.

What exactly is the problem with putting that into hal-info?

Thanks,
Kay


More information about the hal mailing list