On Sat, 22 Dec 2007 11:07:06 -0500 (EST)
"Jared D. McNeill" <jmcneill@invisible.ca> 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
> PSWITCH_HK_VENDOR_BUTTON.

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