Hi Timo, Also, sprach Timo Hoenig am Montag, den 27. November 2006 um 12:45: > 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.
Not with me, no. I just killed anything fnfx-related:
$ command ps ax | grep fnfx
5959 ? Ss 0:01 wmtop -x
^((wm)?top|gkrellm|gnome-system-monitor|fnfxd?)$ -c
/usr/bin/gnome-system-monitor -a 3
6907 pts/0 S+ 0:00 grep --color=auto fnfx
The first is a top-like dockapp for Window Maker which has nothing to
do with fnfx (it should not display fnfx, though), the second is
obvious.
I then restarted HAL:
$ sudo invoke-rc.d dbus restart
Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Stopping Hardware abstraction layer: hald.
Stopping system message bus: dbus.
Starting system message bus: dbus.
Starting Hardware abstraction layer: hald.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
After that I tried lshal -m again with the same result: It worked for
(un)plugging hardware but did not for the keys.
Adding DAEMON_OPTS=--verbose=yes to /etc/default/hal does not bring up
something new:
$ sudo invoke-rc.d dbus restart
Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Stopping Hardware abstraction layer: hald.
Stopping system message bus: dbus.
Starting system message bus: dbus.
Starting Hardware abstraction layer: hald14:30:56.853 [I] hald.c:472: hal
0.5.8.1
14:30:56.854 [I] hald.c:481: Will daemonize
14:30:56.854 [I] hald.c:482: Becoming a daemon
.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Did I miss something? The HAL in unstable is the same as in testing
so it should not be something only available in a new version of HAL.
> > > > 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.
I thought so, yes. I use ivman for reacting to HAL events and had
hoped that it would be able to work here, too.
> 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.
I heard something like this. Is this FIFO a normal FIFO akin to the
ones generated by mkfifo(1)?
Greetings,
--
: Sebastian Fontius : www.fsfe.org : www.fsfe.org/en/fellows/smc
`--------+----------+--------------+-----------------------------------.
[] | "They that can give up essential liberty to obtain a little |
[][][] | temporary safety deserve neither liberty nor safety." |
|| : Benjamin Franklin, 1759 :
signature.asc
Description: Digital signature
