[Pkg-acpi-devel] Bug#521280: how to make acpid react to hotkeys now?

[Henrique de Moraes Holschuh]

On Mon, 20 Apr 2009, martin f krafft wrote:
> also sprach Henrique de Moraes Holschuh <hmh at debian.org> [2009.04.17.0608 +0200]:
> > You have to get the HAL source code, look at its input helper, and
> > WRITE the code to do it.  It just plain CANNOT do anything useful
> > with input events right now.
> 
> So essentially the oh-so-typical FLOSS development thing happened:
> someone decided that a working method is deprecated and just turns
> it off without even checking whether the functionality can be
> replaced by anything else.

All I know is that it is deprecated for two years(!) now in the kernel at
large, and that thinkpad-acpi is the only driver that used acpi events for
hotkeys in the first place (everything else, AFAIK, uses only input
devices).  I might be wrong on this one, if you know of other drivers that
also issued acpi events for hotkeys, please do tell.

That should teach me about just how much of a single-user
X-desktop-environment-driven coolaid that people is driking... I should have
tried to replace acpid with hal two years ago and raised a ruckus at that
time.

I dare say that _this_ time, it was not a matter of yanking the carpet
behind people's feet, but rather of people sleeping on their feet until the
time ran out, then scrambling to fix the fallout when it became clear that
there was a fallout to deal with :-(

There will be another one when /proc/acpi beats the dust.  You have been
warned.

> Where do we place our priorities again? I thought it was *users*. :)

Mine are on doing things correctly, actually.  If I have to chose between
the users or maintaining crap that will haunt me on the years to come, the
users will lose.

But that's not what happened here.  Not with a *two year* time window.  What
happened is that we do not pay proper attention to our system-wide
infrastructure anymore.  Everything is user-session-this,
desktop-environment-that nowadays.  So, nobody noticed the gaping lack of
key functionality in HAL (and since I don't like HAL very much, I didn't
notice it either).

> Thanks, Gregor for bootstrapping my HAL experience. I have that much
> working. But I really don't want to add an xkb symbol to trigger my
> *window manager* to call a script which invokes sudo to toggle my
> wifi on/off.

I don't like that, either.  I am a heavy user of system-wide stuff called by
hotkeys :)

That said, check rfkill-input.  It might, if you're lucky, take care of your
WiFi on/off needs.  Just make sure to issue KEY_WIFI instead of
KEY_BLUETOOTH (it can't drive more than one type because there is no such a
key defined).

If you want to propose a KEY_RFKILLTOGGLEALL to the kernel people, I will
second you on that one :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh