Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes <hughsient gmail com>]

On Mon, 2006-01-09 at 00:07 -0500, Dmitry Torokhov wrote: 
> 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
> 

HAL does not require acpid to be running as it can listen to the socket
directly. Using HAL allows us to emit a ButtonPressed DBUS event for
session/system applications to listen for (like gnome-volume-manager and
gnome-power-manager) and also could use uinput so that stuff like the
"mute" hotkey can be caught by gnome-keybinding-properties so that the
session action could be taken.

So the call chain would look like this:

acpi->hal->gnome-volume-manager                (ButtonPressed)
acpi->hal->uinput->input_core->keyboard->g-k-p (uinput)

Plus, doing all the processing user-side, we can put the policy in HAL
(saying that hkey 0x140 is KEY_BRIGHTNESSDOWN), meaning we don't have to
update the kernel for every new laptop hotkey layout change.

> 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

What if the application wants a DBUS event rather than listening on /dev/input/X?

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

So in the kernel you want to put all the policy so that if
laptopmodel=foo and bios=bar and key=0x140 then output
KEY_BRIGHTNESSDOWN?

I've no problem using any input interface with HAL, as long as it's
unified between all the different acpi modules.

Even in the acpi kernel bits, there appears to be about half a dozen
different ways that buttons *could* get to userspace, without any
cooperation from the desktop guys and the kernel guys to an optimal
solution.

Sorry if this sounds a bit like a rant.

Richard.