Speaking about this, how to change the default behavior of the buttons in Om2009? I know that both of them come as X events and can be observed using xev, but the power button suspends the device even if you're not running X, so its action is probably controlled by power management. But APM doesn't seem to allow changing the behavior like ACPI does. Any hints?<br>
<br>Michal<br><br><div class="gmail_quote">2009/6/11 Nicola Mfb <span dir="ltr"><<a href="mailto:nicola.mfb@gmail.com">nicola.mfb@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi!<br>
I apologize if this is an old topic and was discussed many time before.<br>
I tried hackable:1 some days ago, and I found that AUX/POWER buttons<br>
is handled very nice. I suppose that it cames from 2007.2 neod, but I<br>
was aware of it as I flashed my freerunner with ASU ASAP when it<br>
arrived in my hands last year.<br>
First of all the aux button is used to bring up the virtual keyboard,<br>
and this is good as I hate to use touchscreen to open it with<br>
application not "e" based that does not bring up it automagically when<br>
text widgets get focus, while holding it brings up a menu that let you<br>
rotate the screen, switch fullscreen mode and so on, and this is very<br>
nice as if you go fullscreen with "e" AFAIK there is no possibility to<br>
restore normal size or switch to other windows.<br>
Second the power button let you close an application (this is nice<br>
too!), and holding it brings up a menu to change power management,<br>
screen light and turn on/off gps/wifi/bt/gsm and the entire device.<br>
While experiencing with general not embedded oriented linux apps and<br>
developing mines I feel all these features has to be restored together<br>
with new ideas.<br>
So for a couple of days I'm thinking on how implement and improve it<br>
especially for FSO based distros.<br>
The first enhancement I thought is to give to applications the<br>
possibility to handle 4 cases:<br>
*) aux press<br>
*) power press<br>
*) hold aux, then press power<br>
*) hold power, then press aux<br>
The second is to have holding aux, power or both for a long time<br>
bringing system wide tasks (power menu, auxiliary menu, keyboard and<br>
so on).<br>
All that should be transparent to applications, e.g a special daemon<br>
should grab the input and simulate the 7 events as 7 different keys,<br>
so you may use the 1-4 directly in applications for their needs, and<br>
5-7 for global shortcut handled for example by the windows manager or<br>
some sort of background daemon to show system menus.<br>
Actually I thinked at two solution:<br>
1) a neod like daemon that grabs X events (XGrabKeyboard), handle key<br>
presses and forward with XSendEvent the 7 different strokes to<br>
applications or windows manager.<br>
2) a daemon that grabs /dev/input/event* device in exclusive mode,<br>
handle key events and emulate a new keyboard with uinput capable of 7<br>
keys.<br>
<br>
I like very much the second idea as it should be totally transparent<br>
to the system, and may be used without X too while the first should be<br>
more portable on different devices, and may be installed and used by a<br>
non privileged user too.<br>
I tryied to code a prototype for the first solution on my desktop, but<br>
I got some problems as I do not know X at lower level, so I used<br>
XGrabKeyboard to receive all key events and XSendEvent to forward them<br>
to other windows, but not all apps are compatible with that, for<br>
example Firefox does not accept text input in the navigation bar while<br>
the grabbing is active. The second problem is that using X atom on the<br>
wm to retrieve the last active window give me a short number (203, 31,<br>
91 etc.), while XSendEvent wants some sort of different windows ID<br>
(0x3000001f), so some help for experienced X developer is welcome :)<br>
In the next days I'll try to implement a prototype for the second,<br>
hoping that I'll encounter less problems :)<br>
In the meaning I'd like to have comments about all that, and above all<br>
I'd like to know if I'm wasting my time while similar solutions are<br>
being developed underground :)<br>
<br>
Best regards<br>
<br>
Nicola<br>
<br>
_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
<br>
</blockquote></div><br>