On 30/11/2013 02:42 , Ben Gamari wrote:
Peter Hutterer <peter.hutte...@who-t.net> writes:
On Fri, Nov 22, 2013 at 09:53:11AM -0500, Ben Gamari wrote:
[snip]
you might want to build your server with debug symbols and install
libunwind-devel, it'd help greatly with the backtrace.
Done.
[snip]
Note how `ActivateEarlyAccept` is called even if the listener is of type
`POINTER_REGULAR`. This results in the bug. The most obvious change to
avoid this was this patch[2].
yeah, this does seem the right fix. Need to write some extra tests for this
but I've merged your patch for now (might rewrite the commit msg though).
Alright, good. Thanks!
Unfortunately this does not fix a second issue. Both before and after
the fix above, touches would often result in keyboard input pausing: any
key presses after the touch would not be registered until a mouse button
was pressed at which point the keypress events would be delivered
immediately. Sometimes, however, even a mouse events do not restore
keyboard function. Sadly, nothing is logged during these events. It
seems this is likely triggered by touches which change the focused
window.
this could be some stuck touch handling where the events aren't actually
released. If you can find a reliable test case that'd be great.
Opening two xterms in a bare xmonad session seems to reproduce
reliably with my setup. Attempting to touch the non-focused window
causes keyboard input to pause until a mouse button is pressed.
I've tried following the lost keyboard events through the xserver and
found that `DeliverFocusedEvent` (Xi/exevents.c) finds that
`keydb->focus->win == PointerRootWin`. This causes delivery to occur
through `DeliverDeviceEvents` (dix/events.c) which delivers nothing as
`IsMaster(dev) == 0`.
you need to check again here. each event is processed twice, once for the
device and once for the master. you need to make sure that kbd->name ==
"Virtual core keyboard", you can ignore the actual device for most purposes.
the actual device has PointerRootWin, usually, the VCK has the actual focus.
It seems that when keyboard input is in its paused state only the
device events are delivered. The core keyboard events are only
delivered after another mouse event has occurred.
ok, what's happening here is that (most likely) the device is frozen.
Event delivery works that for each event, dev->public.processInputProc
is called. That is usually ProcessOtherEvents(), but if the device is
frozen from a sync grab, that func is EnqueueEvents(). You'll likely
fine that the core keyboard events are going there. Once unfrozen, the
events are replayed as you see below.
most likely what's happening here is that the grab is stuck and xmonad
doesn't send the AllowEvents because it didn't get an event it expected.
the xscope output may help here to figure out what it is registering for.
Cheers,
Peter
> The backtrace while
the old keyboard events are being processed looks like,
Breakpoint 2, DeliverFocusedEvent (keybd=keybd@entry=0x7ff49474e640,
event=event@entry=0x7ff494a07a20, window=0x7ff4949d63c0) at
../../dix/events.c:4101
4101 {
2: keybd->name = 0x7ff49474ecd0 "Virtual core keyboard"
(gdb) bt
#0 DeliverFocusedEvent (keybd=keybd@entry=0x7ff49474e640,
event=event@entry=0x7ff494a07a20, window=0x7ff4949d63c0) at
../../dix/events.c:4101
#1 0x00007ff4928642e6 in ProcessDeviceEvent (device=0x7ff49474e640,
ev=0x7ff494a07a20) at ../../Xi/exevents.c:1779
#2 ProcessOtherEvent (ev=0x7ff494a07a20, device=0x7ff49474e640) at
../../Xi/exevents.c:1826
#3 0x00007ff49288b6e4 in XkbHandleActions (dev=dev@entry=0x7ff49474e640,
kbd=kbd@entry=0x7ff49474e640, event=event@entry=0x7ff494a07a20) at
../../xkb/xkbActions.c:1335
#4 0x00007ff49288bcc6 in XkbProcessKeyboardEvent
(event=event@entry=0x7ff494a07a20, keybd=keybd@entry=0x7ff49474e640) at
../../xkb/xkbPrKeyEv.c:146
#5 0x00007ff492884a25 in AccessXFilterPressEvent (event=0x7ff494a07a20,
keybd=0x7ff49474e640) at ../../xkb/xkbAccessX.c:576
#6 0x00007ff49278b974 in PlayReleasedEvents () at ../../dix/events.c:1258
#7 0x00007ff4927919e5 in ComputeFreezes () at ../../dix/events.c:1338
#8 0x00007ff4927920f2 in DeactivatePointerGrab (mouse=0x7ff494754b70) at
../../dix/events.c:1609
#9 0x00007ff49286447d in ProcessDeviceEvent (device=0x7ff494754b70,
ev=0x7fff1653d590) at ../../Xi/exevents.c:1786
#10 ProcessOtherEvent (ev=0x7fff1653d590, device=0x7ff494754b70) at
../../Xi/exevents.c:1826
#11 0x00007ff492885186 in ProcessPointerEvent (ev=0x7fff1653d590,
mouse=0x7ff494754b70) at ../../xkb/xkbAccessX.c:751
#12 0x00007ff4928b2a5d in mieqProcessDeviceEvent (dev=dev@entry=0x7ff4948d7060,
event=event@entry=0x7ff492b626c0 <event.15512>,
screen=screen@entry=0x7ff49468aca0) at ../../mi/mieq.c:565
#13 0x00007ff4928b2b77 in mieqProcessInputEvents () at ../../mi/mieq.c:627
#14 0x00007ff4927bffc9 in ProcessInputEvents () at
../../../../hw/xfree86/common/xf86Events.c:163
#15 0x00007ff492782f12 in Dispatch () at ../../dix/dispatch.c:357
#16 0x00007ff49277272a in main (argc=9, argv=0x7fff1653e3f8, envp=<optimized
out>) at ../../dix/main.c:298
Cheers,
- Ben
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
