- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Core
- Operating System Release 1 (Zaxxon)
- Severity High
- Reported Version Hotfix 5
Attached to Project: OpenPandora Main OS
Opened by Stefan Nowak - 01.09.2011
Last edited by Michael Mrozek - 21.06.2012
Opened by Stefan Nowak - 01.09.2011
Last edited by Michael Mrozek - 21.06.2012
FS#259 - Hold switch does NOT lock keyboard! Especially crucial in closed lid mode!
Apps, which operate with the Pandora in closed lid mode, such as audio players, server processes, etc, in a button-press-probably environment (as i.e. your pocket) still CAN receive the shoulder button L + R key presses, and if they have a meaning in these programs, they could trigger undesired actions.
And also in the current implementation of the Low Power Mode (See: FS#260) key presses may still be received.
Therefore I strongly propose to implement the HOLD switch to en/dis-able a keyboard lock.
IN DETAIL: This shall be global, meaning that the input processing software (however this is implemented on the Pandora: kernel, driver, … ) keeps the lock state (on/off), and if the keyboard state is off,
a) discards all input, or
b) if it makes sense for some reason/applications (any ideas?) just writes them into a queue/buffer, which gets (partially) executed or made accessible to certain software after the keyboard gets unlocked again.
FYI: I have tested the hold switch with the Pandora Input-Tester, and it is recognized. So my report is definitely a software (and not an hardware) issue.