Record extension not sending events

[Chris D]

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

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
     Subsystem: Dell Device [1028:022f]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
     Subsystem: Dell Device [1028:022f]

[Bryce Harrington (bryce)]

Hi cdekter,

Please attach the output of `lspci -vvnn` too.

[This is an automated message. If this script has reached you erroneously, please accept our apologies; any reply to this message will be sufficient to prevent it from doing further automated processing.]

[Bryce Harrington (bryce)]

Created an attachment (id=23571)
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.

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

I'm pretty sure this is the root cause of bug 332716.

[Martin Pool (mbp)]

It's also happening (in bug 332716) on my desktop machine which is totally different, and I think it's also happening on my Thinkpad X61s.

00:00.0 Host bridge [0600]: Intel Corporation 82P965/G965 Memory Controller Hub [8086:29a0] (rev 02)
01:00.0 VGA compatible controller [0300]: nVidia Corporation G70 [GeForce 7600 GT] [10de:0391] (rev a1)

[Peter Hutterer (peter-hutterer)]

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.

[Bryce Harrington (bryce)]

From the upstream bug:
"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."

[Martin Pool (mbp)]

It would be nice if xorg was at least changed to not say that it supports xrecord until it actually supports it.

[nanotube (nanotube)]

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. :)

[Julien Cristau (jcristau)]

> --- Comment #3 from nanotube <email address hidden> 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

[nanotube (nanotube)]

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?

[hesa (hesa)]

> 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.

[Peter Hutterer (peter-hutterer)]

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.

[Chris D (cdekter)]

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.

[Timothy Alexander (dragonfyre13)]

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

[Timothy Alexander (dragonfyre13)]

Just an update.

Looking at the upstream comments, it looks like this *may* be fixed in 1.7. Sounds like the whole system broke between 1.5-1.6, so it's not an easy fix. However, here a few people are discussing who/when will fix it, if only briefly...
http://bugs.freedesktop.org/show_bug.cgi?id=20500
http://bugs.freedesktop.org/show_bug.cgi?id=21971

[kulight (kulight)]

this bug breaks GoldenDict translate from clipboard hotkey

[Bryce Harrington (bryce)]

Thanks for the update Timothy. Looking at the work going on upstream it appears to be focusing on xserver 1.7, which unfortunately appears to be shipping very late and may not make it in time for Karmic, which would be a shame for the sake of this bug.

I would encourage those of you interested in this bug and with some C skill to look into backporting the patch to the 1.6.x tree so we will be able to include it for Karmic, or determine whether it is at all feasible to backport (some of the upstream comments indicate maybe not). I'm going to be on leave for the month of September so would not have time to work on doing this myself.

[xylo (stefan-endrullis)]

cnee is also affected by this bug which keeps me from upgrading my system. Therefore I would very appreciate if someone could backport the patch (that is hopefully coming soon) to karmic.

For me it's quite an important issue, because even the XeviE extension (the only good alternative to RECORD) is broken / not available anymore (in Jaunty and Karmic).

[Chris D (cdekter)]

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.

[nanotube (nanotube)]

Hi Chris,

Great news - thanks a lot for taking this on! Please keep us posted :)

[PGScooter (pgscooter)]

 Dear Chris Dekter,

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

Best Regards

[Peter Hutterer (peter-hutterer)]

*** Bug 21971 has been marked as a duplicate of this bug. ***

[xylo (stefan-endrullis)]

Has somebody tried to install the last non-broken xserver (the one from hardy) in jaunty or karmic? Could this be a workaround until the Record extension has been fixed? I'm not sure if the dependencies allow such an downgrade.

[Peter Hutterer (peter-hutterer)]

Moving to 1.7.1, this won't be ready for 1.7.0

[Chris D (cdekter)]

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.

[Remi (remi)]

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

[hesa (hesa)]

(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.

[Peter Hutterer (peter-hutterer)]

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

[Peter Hutterer (peter-hutterer)]

Chris, mind attaching the latest patch here? It builds, maybe this way you
can get help debugging.

[Chris D (cdekter)]

Created an attachment (id=31922)
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.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=32426)
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.

[indy2718 (indy2718)]

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).

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=32452)
0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch

prerequisite patch, please apply before applying the actual patch.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=32453)
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.

[hesa (hesa)]

(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).
>

[indy2718 (indy2718)]

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.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=32464)
0001-dix-EventToCore-needs-to-copy-the-root-window-too.patch

Updated version, includes the required test updates now too. Thanks for reporting this.

[Peter Hutterer (peter-hutterer)]

any updates on the testing?

[indy2718 (indy2718)]

(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.

[Peter Hutterer (peter-hutterer)]

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.

[Chris D (cdekter)]

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.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=33231)
0001-Re-enable-RECORD-extension.patch

New patch, seems to work now. Please let me know if this one looks alright.

[indy2718 (indy2718)]

(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

[Mingming Ren (portis25)]

These two patches from upstream bug report together works.
So please add them to the ubuntu package.

[Mingming Ren (portis25)]

Second patch..

[Bryce Harrington (bryce)]

Thanks, added to ubuntu's xorg-server git tree and will go out in the next xorg-server update.

[Usama Akkad (damascene)]

seems that this is producible in Lucid
when I run goldendict from terminal I get this:
Xlib: extension "RECORD" missing on display ":0.0".

if clicked on the program icon:
Failed to initialize hotkeys monitoring mechanism.
Make sure your XServer has RECORD extension turned on.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.7.5-1ubuntu2

---------------
xorg-server (2:1.7.5-1ubuntu2) lucid; urgency=low

  [ Bryce Harrington ]
  [Timo Aaltonen]
  * Add 107_dont_filter_input_subsys.diff so for instance serial wacom
    devices are initialized by the udev backend (LP: #522318)

  [Bryce Harrington]
  * Add 108_reenable_record_ext.patch: Upstream patch to make the
    record callback work with the new internal core/Xi events mechanism
    instead of xEvents. With this fix, the record extension can be
    re-enabled.
    (LP: #315456)
 -- Timo Aaltonen <email address hidden> Tue, 02 Mar 2010 17:09:33 +0200

[booiiing (booiiing)]

(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.

[Peter Hutterer (peter-hutterer)]

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.

[booiiing (booiiing)]

(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?

[xylo (stefan-endrullis)]

This xnee/cnee bug has been confirmed on Launchpad yesterday: https://bugs.launchpad.net/ubuntu/+source/xnee/+bug/378648

[Julien Cristau (jcristau)]

> --- Comment #34 from Patric Schenke <email address hidden> 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.

[booiiing (booiiing)]

(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

[hesa (hesa)]

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.
>

[Peter Hutterer (peter-hutterer)]

> (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.

[Julien Cristau (jcristau)]

> --- Comment #34 from Patric Schenke <email address hidden> 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.

[Peter Hutterer (peter-hutterer)]

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.

[Javier López (javier-lopez)]

I'm running Lucid, xserver-common [ 2:1.7.6-2ubuntu7.6 ], I've checked the changelog in debian/ and even when it looks fixed (at least in the log), I still have the same errors.

I'm attaching a source file to reproduce it, it fails always.

Steps to Reproduce:
1.Compile a test program attached.
2.Run test program.
3.
Actual Results:

After I ran the test program, error messages was returned.
----------
RECORD extension for local server is version is 1.13
X Error of failed request: XRecordBadContext
Major opcode of failed request: 135 (RECORD)
Minor opcode of failed request: 5 (XRecordEnableContext)
Context in failed request: 0x17
Serial number of failed request: 10
Current serial number in output stream: 10
----------

[Javier López (javier-lopez)]

The test is working great in Ubuntu 11.04 natty