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.
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.
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.
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 #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
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?
> 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.
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.
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.
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
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.
Hi Chris, Great news - thanks a lot for taking this on! Please keep us posted :)
Dear Chris Dekter, Thank you for your help! I can't wait for this to work in Jaunty and Karmic. Best Regards
*** Bug 21971 has been marked as a duplicate of this bug. ***
Moving to 1.7.1, this won't be ready for 1.7.0
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.
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
(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.
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
Chris, mind attaching the latest patch here? It builds, maybe this way you can get help debugging.
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.
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.
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).
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.
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.
(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). >
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.
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.
any updates on the testing?
(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.
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.
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.
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.
(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
(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.
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.
(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?
This xnee/cnee bug has been confirmed on Launchpad yesterday: https://bugs.launchpad.net/ubuntu/+source/xnee/+bug/378648
> --- 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.
(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
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. >
> (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 #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.
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.