ext Jason Mills wrote:
Bluetooth: * Could someone with some additional insight into the user input paths determine what about the hardware keys and/or touch-screen cause the OS layer to determine that the system remains active? (in relation to next question)
The dsme daemon on the device polls the event queues in /dev/input and resets the timer used for screen blanking on activity. Unfortunately it only checks the touchscreen and hardware key queues.
* Could that same keepalive mechanism be integrated into the Bluetooth HID driver layer, rather than the current kludge (as pointed out by the developer) of hammering on the Hildon-layer keepalive function for every single keystroke?
Not really. What can be done is to make dsme aware of new event queues forming and then also consider those for activity. At this point such modifications to a core component is unlikely, however it's something we'd like to look at in the future. Please keep in mind that Bluetooth keyboard support is not an officially supported feature at this moment.
* Is there any way to get the Bluetooth HID driver layer to coexist happily with the on-board HID driver layer, such that the tablet pen and hardware keys can still be used while a Bluetooth keyboard is active?
It's not a problem of drivers but of the GTK input method used. Currently you can have either Xim for keyboard input or hildon-im for the virtual onscreen keyboard. If you want both, hildon-im would have to be keyboard aware, passing the events through to the applications. Or Xim would need a virtual keyboard :)
I'm hoping someone comes along and develops an open source alternative GTK input method for Maemo, the interface for doing so is well defined in GTK. Then all sorts of experimental ways of doing input, like Hexinput which was discussed earlier on these lists, would be possible.
Regards, Tomas _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
