Subject: Re: Hotkey support via powerd
To: Jared D. McNeill <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 12/22/2007 11:42:44
On Sat, 22 Dec 2007 11:07:06 -0500 (EST)
"Jared D. McNeill" <email@example.com> wrote:
> On Sat, 22 Dec 2007, Steven M. Bellovin wrote:
> > First -- and at this level -- where does the list of hotkeys come
> > from? Is that part of some standard or is it vendor- and
> > model-specific? For example, I'm pretty certain that on my T42, the
> > volume control and "Acess IBM" buttons are ACPI events -- at least,
> > I see things on the screen in Windows when I press them, but xev
> > doesn't think I've pressed anything. If they are vendor-specific,
> > the PSWITCH_HK_* defines are probably inappropriate; we'd need a
> > way to load the appropriate definitions.
> They are handled by the new thinkpad(4) driver, which uses
> IBM/Lenovo's HKEY interface. The hotkey driver is responsible for
> mapping its hotkey events to the generic PSWITCH_HK_* events. We can
> use pmf_platform to use the information from DMI tables to handle any
> quirks in the keymappings between models.
So other laptops would need their own model-specific driver? Wouldn't
that still necessitate something other than those #defines? (Or
rather, they should be in thinkpad.h, I'd guess.)
> Volume events don't need to be passed to userland -- pmf can handle
> them just fine in the kernel. The "Access IBM" button is the same as
> my "ThinkVantage" button, which is delivered to powerd as a
The question is user feedback. Many interfaces -- Windows, I think
Gnome/Ubuntu, my mobile phone, my television, etc., display something
to show the relative volume level when I change it. If the events
aren't passed to userlevel, displaying that is hard. Of course, I'm
not saying that powerd is the best way to pass that info to userlevel
-- see below -- but I think we need some way.
> > Second -- we're going to have to figure out some way for powerd to
> > invoke user-specific scripts, running with the user's permissions.
> > Realistically, on most NetBSD laptops that's not a big concern,
> > since the user probably has root, but architecturally it would be
> > nice. The more powerd can do, the more important this is.
> powerd runs scripts as root. We do, however, need to find out who is
> running X -- right now my scripts are pretty stupid and assume the
> owner of /dev/console is the X user.
I know it runs things as root now -- that's the problem... I want some
mechanism for user control on certain events. For example, the MUA I
use (pkgsrc/mail/claws-mail) gets unhappy if its local IP address
changes while it has connections open, but that happens frequently
after a suspend/resume. I'd like to run a command to tell it to go
offline when I suspend. Similarly, I sometimes like to run a command to
lock my screen when I suspend.
Figuring out who's running X is certainly a necessary step. The next
problem, though, is figuring out what scripts that particular user
wants to run. I'm looking for the analog of user crontabs.
--Steve Bellovin, http://www.cs.columbia.edu/~smb