Comment 24 for bug 1068994
Revision history for this message
| Carsten Haitzler (raster-rasterman) wrote | #24 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I can reproduce this bug with 100% reliability in E17.
http://
well ok - i'm using svn development, but i think last release (0.17.1 and efl 1.7.5) should produce the bug too as i noticed this issue just before 0.17 release too. install that (sorry source - there are ppa's but i dont know if there's an arm build. i compiled). i also have set up my n7 to run in portrait mode by default (~/.xsession sets it up).
now its installed, select enlightenment as your desktop (u may have to ln -s enlightenment.
DONT TOUCH that arrow... yet. notice u can click on most things and they work... now press that top-left arrow. its the "start button"... up comes a start menu... u can interact with it... and after that... clicks cease to work. this is 100% reliably reproduces on my nexus7/... it ALSO happens on my exopc too. so this is a general issue with xorg/xinput etc.
anyway - now i've spent some time digging into what's going on, and here's the low-down. wm's use passive button grabs (XGrabButton) for focus handling. they then do an XAllowEvents to allow the button grab to proceed to a child. after some sequence of mouse grabbing is done by popping up that menu, XAllowEvents ceases to ever work again (it never forwards a held button press event ever agin) for the duration of the xserver lifetime. i wrote a "test case" (attached) to show that the parent gets the events, simply calls xallowevents and it never goes to the child window ever again. this test client works fine until the "bug is triggered" then fails. (i shut down the wm but kept x alive and ran the test client to "prove this" - it works fine until the bug is triggered). unfortunately at this point i have yet to make a simple "trigger the bug" client, BUT i am sure it has something to do with a combination of:
1. button press handled after an xallowevents allowed it through
2. an xgrabpointer (unlikely an xgrabkeyboard).
3. some combination of user events (eg mouse/finger not being releases while the above allowevents and grab is going on).
after this "magic sequence" which also likely is race-condition sensitive, the xservers internal input handling is "busted" and xallowevents are broken until an xserver restart (restarting wm doesn't fix it - nor does totally killing the wm and bringing up test clients in its place as above).
so i'll have to say "sorry" in that i'm going to waste some peoples time by only having "more info" without a simple "reproduction case" in a simple contained src blob. i'd hope to have that, but currently don't. what i DO have is a 100% reliable "big fat bulky" reproduction case (e17+efl) AND... i have a simple test client to prove/show what the "stuck" thing is (allowevents of button press fails forever after triggering of the bug). given some more time/weekends i might be able to make such a client. the above was a saturday spent hunting for "what on earth is wrong", so not as much as i'd like to have. :( sorry.