View source for Better handling of AUX/Power buttons

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Return to Better handling of AUX/Power buttons.

Personal tools

Introduction

The freerunner as only two hardware buttons: AUX and Power, here we discuss about a way to use them in the best way.

The Problem

A lot of distros uses the AUX and Power button in a very poor way: simple locking, suspend the device, and some other little things.

The real problem is that the big part of software read keyboard events from FSO or by the Input Event kernel interface while in some cases buttons are grabbed by the window manager.

That makes impossible to use the buttons in application contexts.

Proposals

Virtual keyboard events

We may simulate different key events combining short/long press of the two real buttons. For example:

  • short AUX press/release -> AUX itself
  • short POWER press/release -> POWER itself
  • long AUX press/release -> virtual key event "1"
  • long POWER press/release -> virtual key event "2"
  • AUX press, POWER press, AUX release, POWER release -> virtual key event "3"
  • AUX press, POWER press, POWER release, AUX release -> virtual key event "4"
  • short AUX double-press -> virtual key event "5"

and so on.

We may than use the long/combined press for global shortcuts, eg long AUX for locking, long POWER to bring up settings, etc. etc., and use the short events in application context.

Possible implementations:

Virtual uinput device

A daemon that grab /dev/input/events* and provide a virtual uinput keyboard, in a trasparent manner for the system.

X event daemon

A daemon that grab X11 events and iniects fake events in the X server it'self

Common improvements

  • injecting different events based on the the current running application.
  • listening for accelges gesture recognition dbus signals and injects another set of key events, that's will provide an immediate use of accelerometers for *any* existing application.