On Mon, 2006-11-27 at 15:07 +0100, Sebastian Fontius wrote: > Ah, that way round :). I already wondered... > > If I only start fnfxd it works. If I start dbus/HAL it starts again > missing key presses and if I kill hald-addon-acpi-toshiba it works > again (although I got the impression not 100%). I moved > /usr/share/hal/fdi/policy/10osvendor/10-toshiba-buttons.fdi away and > restarted everything (dbus, HAL, fnfxd) and it works 100% again. Cool > :).
It would be good to have the Debian developers aware of the fact that the Toshiba ACPI event should only be read by one process at a time to get it fixed properly. > So what should we do with this bug? Reassign it to hal? What does > hald-addon-acpi-toshiba do, anyway? Things like the power or the lid > button work without special Toshiba kernel module magic IIRC (and are > handled by acpid directly on my system), so I do not see a point in > shipping hald-addon-acpi-toshiba altogether. But of course I could be > mistaken. Uh, I have no idea how Debian is going to handle that, sorry. For the technical side: It might be the case that GNOME Power Manager is reacting on the events issued by hald-addon-acpi-toshiba. However, if you look at the code of that addon you will see that only passes some events, while FnFX takes care to report *all* events. Power-, lid- and sleep buttons are not affected. Those are covered by the ACPI spec, driven by the ACPI button driver and the events are reported via /proc/acpi/events (and on most distributions reported to all interested processes by acpid). Short: I do no see a point of having the hald-addon-acpi-toshiba addon either. Especially as it (a) does not report all events and (b) there are no client applications reacting on the events. Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
