Re: [gpm] Untangling the sleep hotkey mess

[Dmitry Torokhov <dtor_core ameritech net>]

On Sunday 08 January 2006 20:14, Richard Hughes wrote:
> On Sun, 2006-01-08 at 14:13 +0000, Richard Hughes wrote:
> > On Sun, 2006-01-08 at 13:47 +0000, Matthew Garrett wrote:
> > > On Sun, Jan 08, 2006 at 12:58:44PM +0000, Richard Hughes wrote:
> > > 
> > > > Can we not go further and define Dock/UnDock,
> > > > BrightnessUp/BrightnessDown, Hibernate, etc?
> > > 
> > > BrightnessUp/BrightnessDown have keycodes defined in 
> > > /usr/src/linux/input.h, so that shouldn't be a problem. I suggested a 
> > > keycode for hibernate (KEY_SUSPEND, with suspend to RAM on KEY_SLEEP). 
> > 
> > Okay, that's good for me.
> > 
> > > I'm less convinced about Dock/Undock - that's a problem that's so far 
> > > from being solved I've no idea what sort of things userspace wants to 
> > > know :)
> > 
> > Sure, just an example of "other stuff". Lock is maybe a better example
> > as gnome-screensaver (or equiv) can respond to this.
> > 
> > The main problem now is implementation.
> 
> Further to the conversation on IRC, I've attached two ACPI patches to
> provoke discussion.
> 
> The first creates the /org/freedesktop/Hal/devices/acpi_uinput like I
> did for the toshiba specific HAL addon.
> The second uses the acpi events for creating uinput events that can be
> captured using gnome-keybindings, and also creates HAL ButtonPressed
> events so that DBUS aware applications (like g-v-m and g-p-m) can
> monitor the events.
>

I am sorry, but the scheme

	acpi->acpid->hal?->uinput->input_core->keyboard->...>userspace

is way too crazy.

Why don't we create an input handler that would feed certain events
from input layer to acpid via bus_acpi_generate_event(). This will
allow grateful migration of acpi buttons and other stuff to use
input layer:

	acpi->input_core->[new handler]->acpid


In the mean time hal can start using /dev/input/eventX to get those
events.

-- 
Dmitry