bugXnee - Bugs: bug #29539, XNEE related XLIB problem has been...

 
 

bug #29539: XNEE related XLIB problem has been fixed

Submitter:  Rami Ylimaki <rjy>
Submitted:  Tue 13 Apr 2010 10:48:02 AM UTC
   
 
Category:  libxnee Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Minor fault
Status:  In Progress Privacy:  Public
Assigned to:  hesa Open/Closed:  Open
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Mon 19 Apr 2010 07:45:52 AM UTC, comment #2: 

Well, the recording extension was definitely broken and disabled for a long time in Xorg. However, the inability to use separate control and data connections was caused by a bug in Xlib. Also, this report is not a bug report in the sense that you'd absolutely have to do fixes in order for things to work. I just wanted to notify you that the original functionality can be restored in the future.

If a distribution is using Xlib configured --without-xcb, it should be possible to use separate control and data connections without problems.

If Xlib is configured --with-xcb, which is the default, then the Xlib version needs to be higher than 1.3.3 for separate control and data connections to work (1.3.4 hasn't been released yet).

I don't know how to detect if Xlib was configured --with-xcb so maybe it would be best to just check if Xlib version is 1.3.3 or older in configure.ac and use same connection workaround in that case when building Xnee.

I haven't seen much discussion about recording problems in xorg-devel recently so I guess they have been fixed at least in 1.8 version of X server. I haven't checked this though. I guess the remaining problems were quite minor like sending events accidentally twice as core and extension events in some cases and things like that.

Rami Ylimaki <rjy>
Fri 16 Apr 2010 07:29:28 PM UTC, comment #1: 

Thanks for your report

I will have to do some tests on several platforms before releasing a new version.

But to start of with, can you clarify your report a bit? Are you saying that the version of Xorg has nothing to do with Xnee malfunctioning and Xnee should instead look if xcb is used and then take action (i.e use the same connection for control and data)... or?

BTW, you filed the report on my birthday :)


/h

.... when the "RECORD problem" is fixed it also means that I can finally begin working on XI2 :)

Henrik Sandklef <hesa>
Group administrator
Tue 13 Apr 2010 10:48:02 AM UTC, original submission:  

Hi,

A while back there were problems with multiple display connections in XNEE. Originally it was thought that it had something to do with broken record implementation in X server. It turns out that it was caused by a general synchronization problem in Xlib configured using --with-xcb option.

Reported bug: https://bugs.free ... _bug.cgi?id=27595
Patch: http://cgit.freed ... a303ba595b8ab106b

When the fixed Xlib is taken into use in distributions you can fix XNEE to start using separate connections again:

  if ( xnee_record_from_data_display(xd))
    {
      /*
       * From X.org 1.6.0 to ????
       *
       *   there seem to be something strange about
       *   the XRecordCreateContext call
       *   which causes the XRecordEnableContextAsync
       *   to fail ... ugly fix, but it works
       *
       */
      fprintf(stderr, "Workaround: Creating context on data display instead of control \n");
      fprintf(stderr, "            You can ignore this message\n");
      context_display = xd->data ;
    }

-- Rami

Rami Ylimaki <rjy>

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by hesa (Posted a comment)
  • -email is unavailable- added by rjy (Submitted the item)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    History

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-16 hesa Severity3 - Normal 5 - Blocker
        StatusNone In Progress
        Assigned toNone hesa

    Back to the top

    Powered by Savane 3.16-ed84.
    Corresponding source code