summaryrefslogtreecommitdiff
path: root/apps/Applications
authormickeyl <mickeyl>2004-01-08 23:22:51 (UTC)
committer mickeyl <mickeyl>2004-01-08 23:22:51 (UTC)
commit9fc7d401f1445c5f3d3d74e173dea6de2ea4784a (patch) (side-by-side diff)
tree2c5576c866e8e90a8e5e5efe53e1a5955156b6a5 /apps/Applications
parentb52dbdb9e992bd891d69601a6425086099e2ea04 (diff)
downloadopie-9fc7d401f1445c5f3d3d74e173dea6de2ea4784a.zip
opie-9fc7d401f1445c5f3d3d74e173dea6de2ea4784a.tar.gz
opie-9fc7d401f1445c5f3d3d74e173dea6de2ea4784a.tar.bz2
turn on the light after opening the hinge when 'display off' is configured as hinge action
NOTE: I think there's a bug in the Embedix kernel which either tells a wrong hinge value after suspend or sends out a double (bogus) keycode event on closing the hinge. How to reproduce: 1.) Configure "suspend" as closeHingeAction 2.) Close Display --> Device Suspends 3.) Open Display --> Device does nothing (needs a kernel patch to wake up automatically, but that's another story) 4.) Wakeup Device --> Device sends F14 to rotateApplet, rotateApplet reads hinge code... it's CLOSED(!) - which is wrong 5.) Device resuspends. 6.) Wakeup again --> Device sends F14 (huh, again?) to rotateApplet. rotateApplet reads hinge code... it's OPEN now - which is ok. Ideas?
Diffstat (limited to 'apps/Applications') (more/less context) (show whitespace changes)
0 files changed, 0 insertions, 0 deletions