Hi Sebastian, On Mon, 2006-11-27 at 13:29 +0100, Sebastian Fontius wrote:
> $ dlocate hal: | grep tosh > hal: /usr/share/hal/fdi/policy/10osvendor/10-toshiba-buttons.fdi > hal: /usr/lib/hal/hald-addon-acpi-buttons-toshiba > > $ lsof | grep tosh > hald-addo 4724 root mem REG 3,1 9212 > 149972 /usr/lib/hal/hald-addon-acpi-buttons-toshiba > > The lsof output gives the hint that HAL loads this addon (and indeed, > smbios.system.manufacturer is TOSHIBA, as specified in > /usr/share/hal/fdi/policy/10osvendor/10-toshiba-buttons.fdi), but it > does not appear to do anything. At least lshal -m does not utter a > single byte regarding to the keys, whereas it reacts to everything > else I tried: removing input devices, charging the battery, etc.pp. > > I also stopped fnfx from starting for this so as not to disturb HAL in > any way. > > I read some things about a virtual input device or something (again: > no knowledge, and if, then some rather dangerous half-knowledge ;)) > but did not find anything in the output of lshal or the source code of > the current version of HAL in testing. Ah, alright, just just fixed the bug ;-) The HAL addon hald-addon-acpi-buttons-toshiba and fnfxd are both consuming events form the Toshiba ACPI driver. Thus, kill one of them and the other one will receive all events. > > > BTW: I updated to linux 2.6.18.3 and the problem has not gone away. > > If you want to succeed I'd suggest breaking it down to the kernel > > version where it broke. If you can tell "it worked with 2.6.16.3 but > > stopped working with 2.6.1.16.4" you will have a realistic chance to > > find the culprit. > > Bah! (Read: "I know of course that you are right, but had hoped to > find a solution without resorting to bug hunting this way. I strongly > assume that with Linux 2.6.17 it worked and will try that now (albeit > not my homegrown version but the Debian one > linux-image-2.6.17-2-686... If that does not help I will have to > think of something because I do not backup my old kernel .configs). I > will report my findings shortly"... I am always surprised to find > what a simpe "Bah!" is able to convey ;)) Read above, you just found the culprit without going through this pain :-) Oh, and by the way. I doubt that hald-addon-acpi-buttons-toshiba is doing anything on its own (e.g. changing brightness). Thus, it might be very useless to run if you don't have any client as counterpart which receives the events and reacts on them. If you are about to spread word about the problem: The event interface of the Toshiba ACPI driver is implemented as a FIFO. Whenever one process consumes an event, another process will not be able to receive the same. Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
