Re: [gpm] Untangling the sleep hotkey mess
- From: Richard Hughes <hughsient gmail com>
- To: Dmitry Torokhov <dtor_core ameritech net>
- Cc: gnome-power-manager-list gnome org, desktop_portables lists osdl org, hal lists freedesktop org, linux-acpi vger kernel org
- Subject: Re: [gpm] Untangling the sleep hotkey mess
- Date: Mon, 09 Jan 2006 09:43:28 +0000
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
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:
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
So in the kernel you want to put all the policy so that if
laptopmodel=foo and bios=bar and key=0x140 then output
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
Sorry if this sounds a bit like a rant.
] [Thread Prev