Bug 21971 - RECORD extension (in X.Org version: 1.6.0) does not work anymore
Summary: RECORD extension (in X.Org version: 1.6.0) does not work anymore
Status: RESOLVED DUPLICATE of bug 20500
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xext (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-27 16:01 UTC by Henrik Sandklef
Modified: 2009-09-02 21:08 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Sandklef 2009-05-27 16:01:04 UTC
When executing GNU Xnee under

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    10402000
X.Org version: 1.4.2

everything is OK. …. but when I run cnee (part of GNU/Xnee) under

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    10600000
X.Org version: 1.6.0

it bails out. Seems as if there something strange going on in XRecordEnableContextAsync in the latest X.org release. This is because the context is faulty.... Seems as if you now have to create your record context on the data display instead of through the control display (RECORD terminology). This could work, but will end up in messy code for the RECORD users and also when recording a display (on a 'new' server) from one host (with an 'old' xlib) things will most likely go wrong.

The bug has been reported to me (in private) as well as on the GNU Xnee mailing lists. 

I am available for helping out with the bug.
Comment 1 Peter Hutterer 2009-05-28 22:42:21 UTC
event delivery has changed a lot between 1.5 and 1.6 and then again to 1.7. currently there are big FIXMEs in the code (ProcessOtherEvent() and DeliverDeviceEvent() I think). 

I'm planning to restore this feature for 1.7, but I'd appreciate any help you can provide since 1.6 is quite different and I'm a bit overloaded.
Comment 2 Rami Ylimaki 2009-06-09 04:55:11 UTC
(In reply to comment #0)
> Seems as if there something strange going on in
> XRecordEnableContextAsync in the latest X.org release.

Hi Henrik,

I bumped into this problem a while ago and have identified two problems with recording.

1. The xserver doesn't have callbacks for the actual events so nothing is reported to cnee. This is a different problem and is discussed in bug 20500.

2. Cnee fails with XRecordBadContext error. It seems to be a problem with cnee but for some reason I'm only able to reproduce it with newer xlib 1.2 if it's compiled with xcb support. Older xlib 1.1.5 works and also 1.2 works without xcb.

Cnee (3.02) starts recording by making XRecordCreateContext and XEnableContextAsync xlib calls. I was able to get rid of the XRecordBadContext error by forcing XFlush after XRecordCreateContext. I think that the flush could be needed because XRecordCreateContext and XRecordEnableContextAsync use different displays (cnee 3.02). Otherwise the following sequence is possible:
- XRecordCreateContext is called and placed into xlib output buffer for display A.
- Display A buffer isn't flushed because XRecordCreateContext requires no response from xserver.
- XRecordEnableContextAsync is called and placed into xlib output buffer for display B.
- XRecordEnableContextAsync reads a reply from xserver and therefore the xlib output buffer for display B is flushed.
- Xserver cannot handle the request because display A buffer is not flushed yet and therefore the context hasn't been created in xserver side yet.

I think that using a different display for the calls is OK but you have to make sure that xserver receives context creation request before it is enabled.
Comment 3 Tim Alexander 2009-07-25 21:37:51 UTC
Just commenting to ask about any progress those of you with a higher skillset may have done. My C skills are abysmal, and hopping in myself wouldn't be much help.

Just wanted to let those of you who may be working on this know, we're watching from the sidelines, and rooting for you.
Comment 4 Peter Hutterer 2009-09-02 21:08:46 UTC
marking as duplicate of 20500. It's unlikely a future fix will get backported for 1.6. sorry.

*** This bug has been marked as a duplicate of bug 20500 ***


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.