Better handling of AUX and POWER buttons

[Nicola Mfb]

Hi!
I apologize if this is an old topic and was discussed many time before.
I tried hackable:1 some days ago, and I found that AUX/POWER buttons
is handled very nice. I suppose that it cames from 2007.2 neod, but I
was aware of it as I flashed my freerunner with ASU ASAP when it
arrived in my hands last year.
First of all the aux button is used to bring up the virtual keyboard,
and this is good as I hate to use touchscreen to open it with
application not "e" based that does not bring up it automagically when
text widgets get focus, while holding it brings up a menu that let you
rotate the screen, switch fullscreen mode and so on, and this is very
nice as if you go fullscreen with "e" AFAIK there is no possibility to
restore normal size or switch to other windows.
Second the power button let you close an application (this is nice
too!), and holding it brings up a menu to change power management,
screen light and turn on/off gps/wifi/bt/gsm and the entire device.
While experiencing with general not embedded oriented linux apps and
developing mines I feel all these features has to be restored together
with new ideas.
So for a couple of days I'm thinking on how implement and improve it
especially for FSO based distros.
The first enhancement I thought is to give to applications the
possibility to handle 4 cases:
*) aux press
*) power press
*) hold aux, then press power
*) hold power, then press aux
The second is to have holding aux, power or both for a long time
bringing system wide tasks (power menu, auxiliary menu, keyboard and
so on).
All that should be transparent to applications, e.g a special daemon
should grab the input and simulate the 7 events as 7 different keys,
so you may use the 1-4 directly in applications for their needs, and
5-7 for global shortcut handled for example by the windows manager or
some sort of background daemon to show system menus.
Actually I thinked at two solution:
1) a neod like daemon that grabs X events (XGrabKeyboard), handle key
presses and forward with XSendEvent the 7 different strokes to
applications or windows manager.
2) a daemon that grabs /dev/input/event* device in exclusive mode,
handle key events and emulate a new keyboard with uinput capable of 7
keys.

I like very much the second idea as it should be totally transparent
to the system, and may be used without X too while the first should be
more portable on different devices, and may be installed and used by a
non privileged user too.
I tryied to code a prototype for the first solution on my desktop, but
I got some problems as I do not know X at lower level, so I used
XGrabKeyboard to receive all key events and XSendEvent to forward them
to other windows, but not all apps are compatible with that, for
example Firefox does not accept text input in the navigation bar while
the grabbing is active. The second problem is that using X atom on the
wm to retrieve the last active window give me a short number (203, 31,
91 etc.), while XSendEvent wants some sort of different windows ID
(0x3000001f), so some help for experienced X developer is welcome :)
In the next days I'll try to implement a prototype for the second,
hoping that I'll encounter less problems :)
In the meaning I'd like to have comments about all that, and above all
I'd like to know if I'm wasting my time while similar solutions are
being developed underground :)

Best regards

    Nicola