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! :)
signature.asc
Description: This is a digitally signed message part
