Ticket #1589 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

can not make Lock screen when option menu poping up During connecting a call

Reported by: regina_kim Owned by: zecke
Priority: normal Milestone: Om2008.8
Component: Qtopia Version:
Severity: normal Keywords:
Cc: raster@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:


kernel : 20080705-asu.stable-uImage.bin
rootfs : 20080708-asu.stable-rootfs.jffs2

summary : can not make Lock screen when option menu poping up During connecting a call

step :

  1. incoming a call
  2. answer call
  3. press option
  4. press AUX button

current result : when press AUX key will works for select menu

expected result : it should shows lock screen.

Change History

comment:1 Changed 11 years ago by roh

  • Owner changed from zecke@… to zecke

comment:2 Changed 11 years ago by zecke

  • Cc raster@… added

got a picture?

comment:3 Changed 11 years ago by raster

aaaah hmmm. well.. i can tell you exactly what is happening and why... and why it can't be fixed.


  1. aux is an x key. power is also a key in x (like a key on a keyboard).
  2. e uses passive key grabs (x's mechanism to bind keys - eg alt+tab for switching windows) to grab a key (or key combination) so whenever it is pressed e gets the event
  3. when it gets this event for this bound key, e reacts by looking up what actions are bound to it and then "running" those actions.

background 2:

  1. when you press "option" qtopia (qt) pops up a MENU.
  2. MENUS in ALL widget sets GRAB the keyboard. that means they grab the entire set of keys in x and all passive keygrabs are "disabled" as ALL key presses go to the client that grabbed. this is to allow key navigation of menus without affecting the focus policy of x and focus returns automaticaly in x when a grab is released.
  3. the menu grabs the keyboard thus stopping e from getting its bindings presses - it nver gets the event so it can never respond.

this is just how it "works". the only solution is disabling key grabs for menus in qt/qtopia - i am unsure of the repercussions within qt/qtopia of this. but as such it will break "key navigation" for menus in qtopia.

i'm tempted to say its "invalid" as actually this is intended behavior and design of qt (and gtk and every other toolkit) and x11. this is just how it works, either that or "wontfix". since we have no numberpad/keypad, disabling keygrabs MAY work for the freerunner - but for future devices that may have a keypad... this would then break so we're breaking a widget set for 1 specific device.

comment:4 Changed 11 years ago by will

regina, let's take a look at this tomorrow.
i don't really get whats going on here.

comment:5 Changed 11 years ago by will

  • Status changed from new to in_testing

last time we checked this was working.

comment:6 Changed 11 years ago by regina_kim

hey will today i check again. it does not working.press button just for select menu.
raster will not fix this. so, should i close this ???

comment:7 Changed 11 years ago by regina_kim

  • Status changed from in_testing to closed
  • Resolution set to fixed

kernel : 20080808 -asu.stable-uImage.bin
rootfs : 20080814-asu.stable-rootfs.jffs2

i will close this ticket because the function is actual design.

Note: See TracTickets for help on using tickets.