pbbuttonsd contains the following code:
sprintf(filename, "/dev/input/event%d", n);
if ((fd = open(filename, O_RDONLY)) >= 0) {
ioctl(fd, EVIOCGID, id);
venprod = (gpointer) (id[ID_VENDOR]<<16 | id[ID_PRODUCT]);
if ((g_list_find_custom (base->inputsources, venprod, cbEventDevices)) == NULL)
addInputSource (fd, event_handler, venprod, TRUE);
else
close(fd);
I suppose this is meant as an optimisation to save clearing the device
etc. Haha. What's the 'optimisation' anyway? One function call to remove
the device from the list. Doesn't even save a syscall! And not even in
any hot path (as if there were any in pbbuttonsd).
Well, it's also bogus (for obvious reasons [1]) and since the event
device numbering is essentially random when you hotplug a few things,
you loose. At best the eject key, or sometimes the rest of the hotkeys.
All depends on how the kernel feels like it should order the event
devices.
Now, does anyone still wonder why I kept complaining (on IRC) that
pbbuttonsd wasn't picking up my keypresses? Or that other people kept
complaining about non-working eject keys?
Did I ever say I hate stupid buggimisations?
johannes
[1] for those that need help: are you sure that the product and vendor
IDs are a unique key to all input devices you can plug in? Think again!
PS: I just realised that hal with the pmud addon and gnome-powermanager
together do almost everything that pbbuttonsd does except handling the
power button, eject key, volume keys and keyboard illumination, all of
which should be easily fixable. Oh and the video switch button that
never did a thing for me anyway. Hence, I've purged pbbuttonsd from my
system. Yay! :)
Attachment:
signature.asc
Description: This is a digitally signed message part