Bug 20500

Summary: Record extension not sending event
Product: xorg Reporter: Bryce Harrington <bryce>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: adam, booiiing, cam, cdekter, dragonfyre13, hesa, indy2718, kai.kasurinen, nanotube, peter.hutterer, przanoni, remi, stefan, yselkowi
Version: 7.3 (2007.09)   
Hardware: All   
OS: Linux (All)   
URL: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/315456
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 24075    
Attachments:
Description Flags
interface.py
none
Patch archive (4 commits)
none
0001-Re-enable-RECORD-extension.patch
none
0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch
none
0001-Re-enable-the-RECORD-extension.patch
none
0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch
none
0001-Re-enable-RECORD-extension.patch none

Description Bryce Harrington 2009-03-05 16:28:06 UTC
Created attachment 23571 [details]
interface.py

Forwarding this bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/315456

"The Record extension appears to be broken somehow - it is not sending any events to Record clients (particularly XKeyPress, XKeyRelease and XButtonPress events). I am using the python-xlib library for my application. This library does not appear to have changed between Intrepid and Jaunty, and while Record works perfectly in Intrepid, in Jaunty it is broken as described. The relevant module from my application is attached."

Ubuntu version: Jaunty Alpha 2
python-xlib 0.14-2
xserver-xorg 1:7.4~5ubuntu9


Note, we've another bug that sounds similar, although the exact symptoms are a tad different -

https://bugs.edge.launchpad.net/ubuntu/+source/workrave/+bug/332716

xtrace from this second bug suggests that the XRecord fails to respond after a few interactions.
Comment 1 Martin Pool 2009-03-05 17:08:46 UTC
Regarding <https://bugs.edge.launchpad.net/ubuntu/+source/workrave/+bug/332716> I think the symptoms are the same.  (Though the sample code given for <https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/315456> is not complete so I can't test it.)

As I said there: the server reports that it supports RECORD, it allows creation of a context and parameters to be set up, and then it makes one single callback of XRecordStartOfData, then nothing more.

There is an xtrace file attached <http://launchpadlibrarian.net/23525937/workrave.trace> where you can see this.
Comment 2 Peter Hutterer 2009-03-08 23:52:45 UTC
RECORD is heavily broken at the moment and in desperate need of love. The
whole event delivery changed under it. How quickly that'll get fixed, I don't
know.
Comment 3 nanotube 2009-05-17 12:02:43 UTC
Just wondering if there's any progress on this bug?
There are quite a few projects that rely on the record extension (e.g., xnee, workrave)... Would be nice to know if there's anyone working on this. :)
Comment 4 Julien Cristau 2009-05-18 00:45:36 UTC
> --- Comment #3 from nanotube <nanotube@gmail.com>  2009-05-17 12:02:43 PST ---
> Just wondering if there's any progress on this bug?
> There are quite a few projects that rely on the record extension (e.g., xnee,
> workrave)... Would be nice to know if there's anyone working on this. :)

noone is, as far as i know.  feel free to send in a patch.
see http://www.x.org/wiki/Development/Documentation/SubmittingPatches
Comment 5 nanotube 2009-05-19 07:38:18 UTC
Hi
Thanks for your response.

Haven't dug into any xorg code before, I'll take a look at the developer docs... 

Would there be any docs somewhere, specifically as to what changed with the event delivery model from old version to new version, to make xrecord stop working?
Comment 6 Henrik Sandklef 2009-05-28 04:58:44 UTC
> Would there be any docs somewhere, specifically as to what changed with the
> event delivery model from old version to new version, to make xrecord stop
> working?

I am also willing to help out with this.

But some nice hints on were to find where to start. Whats has been changed in what mechanism that (probably) hinders RECORD.

I've done some 'engineering research' on the issue and think I know enough to get started..... once we got some hints.
Comment 7 Peter Hutterer 2009-05-28 05:06:05 UTC
There's a big FIXME in ProcessOtherEvent in Xi/exevents.c in the server
which is where one part of it goes. The other FIXME is I think in
DeliverEventsToWindow (or somewhere else in dix/events.c). 

Event delivery model has changed _a lot_ since 1.5, but there's no
exhaustive documentation yet. The basics are in dix/getevents.c, where
GetPointerEvents() and friends create the internal events, then these are
added to the event queue.  mieqProcessInputEvents() in mi/mieq.c takes them
out again and sends the event once through the slave device, once through
the master device (if applicable). That's where it hits (after XKB)
ProcessOtherEvent() and from then on into the event delivery paths.
Comment 8 Chris Dekter 2009-07-06 05:32:06 UTC
Please please PLEASE, can something be done about this? I am prepared to work on it if someone will mentor me. There is no other reliable way to capture mouse and keyboard events on Linux, making any kind of decent desktop automation application impossible. You might say there are other ways, but if you look deeper:

Read EvDev devices directly - doesn't work for all devices (seems to be a side-effect of AutoAddDevices functionality in X).
GNOME AT-SPI - only works for Gnome apps.

That's it! If there are any other ways, I'd love to know about them.
Comment 9 Tim Alexander 2009-07-25 21:35:00 UTC
Looks like there has been some activity on this by greater minds than my own (my C hacking skills are lacking in a bad way...)

I currently use this for a variety of automation tasks on a few systems around the house, and used it for some tasks at work as well. Of course, that means forcing an old xorg version, which isn't exactly something I enjoy doing.

Just letting people know that there are still those of us without the Uber hackish skills of you xorg devs, but who do care about this. I appreciate everything that all of you are doing to further xorg in the first place, just hoping this keeps getting worked.

Looks like the major work is happening over here: https://bugs.freedesktop.org/show_bug.cgi?id=21971
Comment 10 Chris Dekter 2009-08-27 06:14:20 UTC
Work on this is ongoing. So far I have re-enabled the extension and verified a client can connect. I have a pretty good idea of how to get the events going again, so there should hopefully be some progress within a week or two.
Comment 11 nanotube 2009-08-27 20:53:51 UTC
Hi Chris,

Great news - thanks a lot for taking this on! Please keep us posted :)
Comment 12 Janison Kalawi 2009-08-29 14:43:42 UTC
 Dear Chris Dekter,

Thank you for your help! I can't wait for this to work in Jaunty and Karmic.

Best Regards
Comment 13 Peter Hutterer 2009-09-02 21:08:46 UTC
*** Bug 21971 has been marked as a duplicate of this bug. ***
Comment 14 Peter Hutterer 2009-09-21 22:52:02 UTC
Moving to 1.7.1, this won't be ready for 1.7.0
Comment 15 Chris Dekter 2009-10-26 03:30:29 UTC
Status update - device events are now working again (key events, mouse button and motion). A small amount of tweaking and debugging remains, but should be ready very soon.
Comment 16 RĂ©mi Cardona 2009-10-26 09:22:09 UTC
Hi Chris,

Got a branch or patches we could start reviewing? I don't use record myself but I'd still like to test them.

Cheers
Comment 17 Henrik Sandklef 2009-10-26 13:09:17 UTC
(In reply to comment #15)
> Status update - device events are now working again (key events, mouse button
> and motion). A small amount of tweaking and debugging remains, but should be
> ready very soon.
> 

Great!!

I can start testing using the test suite of Xnee (which in turn uses RECORD).

Just give me a branch name.
Comment 18 Peter Hutterer 2009-10-27 20:04:47 UTC
I've pushed chris' current patch onto the record branch in my xserver repo. Feel free to clone from there to test. Chris mentioned the current patch gives duplicate events, I think I know why so expect the next patch to fix this.

http://cgit.freedesktop.org/~whot/xserver/log/?h=record
Comment 19 Peter Hutterer 2009-12-07 22:22:19 UTC
Chris, mind attaching the latest patch here? It builds, maybe this way you
can get help debugging.
Comment 20 Chris Dekter 2009-12-10 02:03:42 UTC
Created attachment 31922 [details]
Patch archive (4 commits)

Latest patch attached, in the form of my last 4 commits. Didn't have time to squash them, but they should apply cleanly to current xserver.
Comment 21 Peter Hutterer 2010-01-03 23:15:15 UTC
Created attachment 32426 [details] [review]
0001-Re-enable-RECORD-extension.patch

Chris' patches squashed together with a couple of minor fixes. cnee reports the events again now though I'm pretty sure some extra work is needed to get the master/slave device hierarchy right.

Meanwhile, any testing would be appreciated.
Comment 22 Chris 2010-01-04 19:50:09 UTC
Thank you Chris Dekter.
I applied Peter's patch to debian experimental xorg-server_1.7.3.901-1
Motion and button presses seem to work with my program that uses Record.   The root window field for motion notify does not seem to be valid though:

xrec_data->event.u.keyButtonPointer.root 

The actual root window by xwininfo: 0x25f
The values received seem to be invalid
21739440 (mostly), 
19763552, 0  (moving the cursor around).
Comment 23 Peter Hutterer 2010-01-04 21:59:15 UTC
Created attachment 32452 [details] [review]
0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch

prerequisite patch, please apply before applying the actual patch.
Comment 24 Peter Hutterer 2010-01-04 22:02:33 UTC
Created attachment 32453 [details] [review]
0001-Re-enable-the-RECORD-extension.patch

Previous patch missed out on the registered delivered events. The root window had random values as WriteEventsToClient still dealt with wire events, not InternalEvents. This was the cause for the garbage root window values. Changing it would require breaking the ABI and some additional rewriting to push InternalEvents closer to the wire processing.

This patch changes to wire events before passing into the callback, so that RECORD essentially gets the same data as before the break.
Comment 25 Henrik Sandklef 2010-01-05 01:22:13 UTC
(In reply to comment #22)
> Thank you Chris Dekter.
> I applied Peter's patch to debian experimental xorg-server_1.7.3.901-1

Great

Do you have (Debian/Lenny) debs that I can test?


> Motion and button presses seem to work with my program that uses Record.   The
> root window field for motion notify does not seem to be valid though:
> 
> xrec_data->event.u.keyButtonPointer.root 
> 
> The actual root window by xwininfo: 0x25f
> The values received seem to be invalid
> 21739440 (mostly), 
> 19763552, 0  (moving the cursor around).
> 

Comment 26 Chris 2010-01-05 10:36:25 UTC
There is a problem with using the 0001-dix-EventToCore patch and debian xorg-server-1.7.3.901
When running dpkg-buildpackage, one of the tests fails.

I don't use the latest git xorg server because of nvidia driver support.

/dix/input/init-valuators: OK
/dix/input/event-core-conversion: [dix] EventToCore: Not implemented yet 
[dix] EventToCore: Not implemented yet 
[dix] EventToCore: Not implemented yet 
**
ERROR:../../test/input.c:190:dix_event_to_core: assertion failed: (core.u.keyButtonPointer.root == 0)
/bin/bash: line 5:   854 Aborted                 (core dumped) ${dir}$tst
FAIL: input


As for building the package, here are some of the commands:
If nvidia drivers are installed, I removed them and 
sudo apt-get --reinstall install libgl1-mesa-dev

x@desktop: mkdir xorgsource
x@desktop:/home/x$ cp dl/0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch xorgsource/
x@desktop:/home/x$ cp dl/0001-Re-enable-the-RECORD-extension.patch xorgsource/
x@desktop:/home/x$ cd xorgsource/
x@desktop:/home/x/xorgsource$ apt-get source -t experimental xorg-server
x@desktop:/home/x/xorgsource$ cd xorg-server-1.7.3.901/
x@desktop:/home/x/xorgsource/xorg-server-1.7.3.901$ patch -p1 < ../0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch
x@desktop:/home/x/xorgsource/xorg-server-1.7.3.901$ patch -p1 < ../0001-Re-enable-the-RECORD-extension.patch
x@desktop:/home/x/xorgsource/xorg-server-1.7.3.901$ dpkg-buildpackage

then sudo dpkg -i the packages generated.

Comment 27 Peter Hutterer 2010-01-05 15:11:22 UTC
Created attachment 32464 [details] [review]
0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch

Updated version, includes the required test updates now too. Thanks for reporting this.
Comment 28 Peter Hutterer 2010-01-07 16:46:39 UTC
any updates on the testing?
Comment 29 Chris 2010-01-07 21:03:50 UTC
(In reply to comment #28)
> any updates on the testing?
> 

Works so far.  What I tested:
XRECORD gets input events, stores the events, then send using XTEST.  (XTestFake*)
Not using xnee.

MotionNotify, ButtonPress, ButtonRelease, KeyPress, KeyRelease work:
Mouse movement, mouse button 1,2, XF86Search, mouse wheel +/-
Keys:  random, modifiers (Left Right Alt, MOD, CTRL), Caps, modifier with key (shift etc).
Event server time is accurate: xrec_data->event.u.keyButtonPointer.time
Root is okay, using Xinerama only (didn't check multiple roots).

That's all I use.   

There is a another problem but I don't believe it is related to the record fixes. The experimental xserver freezes when starting up sometimes.  Haven't looked into why.

Thanks for the work.  Maybe these patches can be added to a future debian package instead of waiting for Xserver > 1.7.


Comment 30 Peter Hutterer 2010-01-10 22:11:43 UTC
Looks like Chris' patch did the right thing provided the dix-EventToCore patch is applied. I oversaw that record uses two different callbacks for the events (the naming is confusing for someone who's worked with input for a while) and the one for delivered events doesn't need fixing.

Checking with xnee again shows the right root window. Can you please confirm this? Chris patch wastes a lot less cpu cycles.
Comment 31 Chris Dekter 2010-01-10 22:29:06 UTC
I'd like to do some testing but just don't have the time to do a build due to current work commitments (things have moved on quite a bit since I did my last build). If any of the Debian/Ubuntu guys here could mash up a .deb I'd be glad to test it out.
Comment 32 Peter Hutterer 2010-02-10 22:40:31 UTC
Created attachment 33231 [details] [review]
0001-Re-enable-RECORD-extension.patch

New patch, seems to work now. Please let me know if this one looks alright.
Comment 33 Chris 2010-02-11 14:40:04 UTC
(In reply to comment #32)
> Created an attachment (id=33231) [details]
> 0001-Re-enable-RECORD-extension.patch
> 
> New patch, seems to work now. Please let me know if this one looks alright.
> 

So far it works.   

I privately made AMD64 xorg-7.4 debian packages and put them at the link below.  They are not from debian/ubuntu. 

http://cid-a5185bc49f5542a7.skydrive.live.com/browse.aspx/.Public/debian%20unofficial%20%5E5private%5E6%20xorg%20xserver%207.4%20with%202-11-2010%20RECORD%20patch%20bug%2020500
Comment 34 Patric Schenke 2010-03-12 10:38:20 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > Created an attachment (id=33231) [details] [details]
> > 0001-Re-enable-RECORD-extension.patch
> > New patch, seems to work now. Please let me know if this one looks alright.
> So far it works.   
> I privately made AMD64 xorg-7.4 debian packages and put them at the link below.
>  They are not from debian/ubuntu. 
i installed them on my testing/unstable and keep getting error 35 (Record memory failure) from xnee:

cnee --record --mouse -o /tmp/booiiing.xns
Error received:
	error type       0 (0x0)
	error code       143 (0x8f)
	error code major 134 (0x86)
	error code minor 5 (0x5)
	display          7231616 (0x6e5880)
 XRecordBadContext
This error can be ignored
Error number: 35
  Error:      Record memory failure
  Solution:   Xnee failed due to bad data received from RECORD extension

if i am using gnee, i also get "*** glibc detected *** gnee: malloc(): memory corruption:" when exiting the program after a record-attempt.
Comment 35 Peter Hutterer 2010-03-16 21:16:43 UTC
confirmed. Patrick, could you please open a new bug for this - the problem
is different to the one in this bug. This bug was concerned with the
extension not working at all (due to it being disabled) whereas your issue
is a 'normal' bug. Thanks.
Comment 36 Patric Schenke 2010-03-16 23:10:10 UTC
(In reply to comment #35)
> confirmed. Patric, could you please open a new bug for this - the problem
> is different to the one in this bug. This bug was concerned with the
> extension not working at all (due to it being disabled) whereas your issue
> is a 'normal' bug. Thanks.
yes, but it's maybe one of the reasons why it was disabled in the first place (didn't bother to look them up, though).

on the other hand, this bug might be related to something else, including xnee and glibc, so i think the correct procedure would be to wait for the patches in debian and then submit a bug-report against xnee there, maybe move it to x.org (if appropriate) and then submit it to upstream?
Comment 37 Stefan Endrullis 2010-03-17 02:44:09 UTC
This xnee/cnee bug has been confirmed on Launchpad yesterday: https://bugs.launchpad.net/ubuntu/+source/xnee/+bug/378648
Comment 38 Julien Cristau 2010-03-17 03:47:10 UTC
> --- Comment #34 from Patric Schenke <booiiing@gmail.com>  2010-03-12 10:38:20 PST ---
> cnee --record --mouse -o /tmp/booiiing.xns
> Error received:
>         error type       0 (0x0)
>         error code       143 (0x8f)
>         error code major 134 (0x86)
>         error code minor 5 (0x5)
>         display          7231616 (0x6e5880)
>  XRecordBadContext
> This error can be ignored
> Error number: 35
>   Error:      Record memory failure
>   Solution:   Xnee failed due to bad data received from RECORD extension
> 
i can reproduce this.  xtrace sees
000:<:000a:  8: RECORD-Request(139,5): EnableContext opcode=0x8b opcode2=0x05
unparsed-data=0x01,0x00,0x40,0x00;
but no CreateContext beforehand, for some reason.  Which I guess
explains the BadContext error.
Comment 39 Patric Schenke 2010-03-17 07:44:20 UTC
(In reply to comment #37)
> This xnee/cnee bug has been confirmed on Launchpad yesterday:
> https://bugs.launchpad.net/ubuntu/+source/xnee/+bug/378648
the corresponding debian-bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536491
Comment 40 Henrik Sandklef 2010-03-17 08:14:04 UTC
Can you PLEASE test with an older version of xnee, e.g.

  ftp://ftp.gnu.org/gnu/xnee/xnee-3.02.tar.gz

I suspect that xnee tries to (cleverly?) work around the bug in Xorg. Using an older version without the "workaround" would test RECORD I think.






(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #32)
> > > Created an attachment (id=33231) [details] [details] [details]
> > > 0001-Re-enable-RECORD-extension.patch
> > > New patch, seems to work now. Please let me know if this one looks alright.
> > So far it works.   
> > I privately made AMD64 xorg-7.4 debian packages and put them at the link below.
> >  They are not from debian/ubuntu. 
> i installed them on my testing/unstable and keep getting error 35 (Record
> memory failure) from xnee:
> 
> cnee --record --mouse -o /tmp/booiiing.xns
> Error received:
>         error type       0 (0x0)
>         error code       143 (0x8f)
>         error code major 134 (0x86)
>         error code minor 5 (0x5)
>         display          7231616 (0x6e5880)
>  XRecordBadContext
> This error can be ignored
> Error number: 35
>   Error:      Record memory failure
>   Solution:   Xnee failed due to bad data received from RECORD extension
> 
> if i am using gnee, i also get "*** glibc detected *** gnee: malloc(): memory
> corruption:" when exiting the program after a record-attempt.
> 

Comment 41 Peter Hutterer 2010-03-17 16:17:30 UTC
> (In reply to comment #35)
> > confirmed. Patric, could you please open a new bug for this - the problem
> > is different to the one in this bug. This bug was concerned with the
> > extension not working at all (due to it being disabled) whereas your issue
> > is a 'normal' bug. Thanks.
> yes, but it's maybe one of the reasons why it was disabled in the first place
> (didn't bother to look them up, though).

possibly. It got finally disabled (ifdef'd out) when I switched the server
to InternalEvents and didn't have time to fix up RECORD too at that point. I
am not aware of RECORD being broken before that point, so I'll just assume
it did the job.

but please guys, a new bug for this issue.
Comment 42 Julien Cristau 2010-04-13 06:03:01 UTC
> --- Comment #34 from Patric Schenke <booiiing@gmail.com>  2010-03-12 10:38:20 PST ---
> i installed them on my testing/unstable and keep getting error 35 (Record
> memory failure) from xnee:
> 
> cnee --record --mouse -o /tmp/booiiing.xns
> Error received:
>         error type       0 (0x0)
>         error code       143 (0x8f)
>         error code major 134 (0x86)
>         error code minor 5 (0x5)
>         display          7231616 (0x6e5880)
>  XRecordBadContext
> This error can be ignored
> Error number: 35
>   Error:      Record memory failure
>   Solution:   Xnee failed due to bad data received from RECORD extension
> 
so for the record (no pun intended), this was bug #27595 and is now
fixed in libX11 git.
Comment 43 Peter Hutterer 2010-04-15 23:40:39 UTC
I'm going to pretend this is all fixed now - at least how the bug claims it is.

If there are any leftovers they're probably real bugs and should be filed as separate bugreports. Thanks for everyone's help.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.