From mike at kmcardiff.com Mon Jun 1 15:00:22 2015 From: mike at kmcardiff.com (Michael Enright) Date: Mon, 1 Jun 2015 15:00:22 -0700 Subject: [Xcb] How to implement rectangle selection in XCB? In-Reply-To: References: Message-ID: Part of this is fundamentally knowing how to display a selection. That's described in graphics text books. The discussion will even cover how you don't permanently damage the graphics you drew before the selection process started. In reality the pixels on the screen MUST change, the engineering is in how to restore the original afterwards. Again, standard graphics text books. This one (http://www.amazon.com/Computer-Graphics-Principles-Practice-Edition/dp/0201848406) is an old, respected book and there's a newer edition. Part of this is deciding if your application uses mainly XCB (aka X-Windows) directly or does the graphics on something like a Cairo surface that you transfer to the screen using XCB. Because I don't know why you "want to use XCB to develop an application" I won't judge. I have done some simple apps directly with XCB or with XCB and a Cairo XCB Surface. However, some say that it's better to use higher level stuff like GTK or QT rather than XCB. On Sun, May 31, 2015 at 10:25 PM, Maeglin Vardamir wrote: > Hi guys, > > I am a newbie to XCB. I want to use XCB to develop an application. Here is > what I need to do: select part of one window and save the selected > content(picture) to a file. Later, I can use this file to check whether this > picture exists in the other window or not. > > Here I have one question about picture selection > Like GIMP, when I click the button of the mice and move it to another > position of the specified window, I should draw a rectangle from the point I > clicked to where I moved my mice. During the process, the rectangle is > growing up. Since I can't change data of the specified window, should I > create a transparent window over the target window? Or any other ideas? > > > Thanks, > Belcon > > _______________________________________________ > Xcb mailing list > Xcb at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xcb From belcon at gmail.com Mon Jun 1 19:23:32 2015 From: belcon at gmail.com (Bin Zhao) Date: Tue, 2 Jun 2015 10:23:32 +0800 Subject: [Xcb] How to implement rectangle selection in XCB? In-Reply-To: References: Message-ID: <38190B4E-5788-41B4-898A-7A6F30197065@gmail.com> Hi Michael, Thanks for your advice. The reason I chose XCB is that I want my application could be run on both Gnome and Qt. Even other desktop such as FVWM, TWM. I am not sure whether I am right or not. Perhaps Gtk/Gdk or Qt is also supported by other desktop. Thanks, Belcon > On Jun 2, 2015, at 6:00 AM, Michael Enright wrote: > > Part of this is fundamentally knowing how to display a selection. > That's described in graphics text books. The discussion will even > cover how you don't permanently damage the graphics you drew before > the selection process started. In reality the pixels on the screen > MUST change, the engineering is in how to restore the original > afterwards. Again, standard graphics text books. This one > (http://www.amazon.com/Computer-Graphics-Principles-Practice-Edition/dp/0201848406) > is an old, respected book and there's a newer edition. > Part of this is deciding if your application uses mainly XCB (aka > X-Windows) directly or does the graphics on something like a Cairo > surface that you transfer to the screen using XCB. > Because I don't know why you "want to use XCB to develop an > application" I won't judge. I have done some simple apps directly with > XCB or with XCB and a Cairo XCB Surface. However, some say that it's > better to use higher level stuff like GTK or QT rather than XCB. > > On Sun, May 31, 2015 at 10:25 PM, Maeglin Vardamir wrote: >> Hi guys, >> >> I am a newbie to XCB. I want to use XCB to develop an application. Here is >> what I need to do: select part of one window and save the selected >> content(picture) to a file. Later, I can use this file to check whether this >> picture exists in the other window or not. >> >> Here I have one question about picture selection >> Like GIMP, when I click the button of the mice and move it to another >> position of the specified window, I should draw a rectangle from the point I >> clicked to where I moved my mice. During the process, the rectangle is >> growing up. Since I can't change data of the specified window, should I >> create a transparent window over the target window? Or any other ideas? >> >> >> Thanks, >> Belcon >> >> _______________________________________________ >> Xcb mailing list >> Xcb at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xcb From tiwari.jaya18 at gmail.com Sun Jun 7 05:59:14 2015 From: tiwari.jaya18 at gmail.com (Jaya Tiwari) Date: Sun, 7 Jun 2015 18:29:14 +0530 Subject: [Xcb] [PATCH proto] xprint: Fix build of xprint extension In-Reply-To: <324858283.1355101.1432050502997.JavaMail.zimbra@redhat.com> References: <323382067.1056853.1432024102240.JavaMail.zimbra@redhat.com> <1432044251-13991-1-git-send-email-ofourdan@redhat.com> <555B531F.3010407@opentext.com> <324858283.1355101.1432050502997.JavaMail.zimbra@redhat.com> Message-ID: Hi Oliver, I guess if we explicitly define pad align as a variable part before list, we need to handle it in the end function, which is not handled currently I guess. (It is handled for functions accessing lists) diff --git a/src/c_client.py b/src/c_client.py index 9a7c67c..45ad2bf 100644 --- a/src/c_client.py +++ b/src/c_client.py @@ -1931,18 +1931,24 @@ def _c_accessors_list(self, field): if switch_obj is not None: _c(' i.data = %s + %s;', fields[field.c_field_name][0], _c_accessor_get_expr(field.type.expr, fields)) elif field.prev_varsized_field == None: _c(' i.data = ((%s *) (R + 1)) + (%s);', field.type.c_wiretype, _c_accessor_get_expr(field.type.expr, fields)) else: + (prev_varsized_field, align_pad) = get_align_pad(field) _c(' xcb_generic_iterator_t child = %s;', - _c_iterator_get_end(field.prev_varsized_field, 'R')) - _c(' i.data = ((%s *) child.data) + (%s);', field.type.c_wiretype, - _c_accessor_get_expr(field.type.expr, fields)) + _c_iterator_get_end(prev_varsized_field, 'R')) + if align_pad is not None: + _c(' i.data = ((%s *) child.data + (%s) + ((-child.index) & (4 - 1)) + %d);', field.type.c_wiretype, + _c_accessor_get_expr(field.type.expr, fields),field.prev_varsized_offset) + else: + _c(' i.data = ((%s *) child.data) + (%s);', field.type.c_wiretype, + _c_accessor_get_expr(field.type.expr, fields)) + _c(' i.rem = 0;') _c(' i.index = (char *) i.data - (char *) %s;', param) _c(' return i;') _c('}') else: With this, I could avoid the error. But I am not sure of the solution though, maybe someone can come up with a better handling for align pad list end accessors. Also, just the implicit length lists needs to be the last member, so list "options" can be kept as a length less list, But then, as for request, we have accessor functions for every fields , options_len (implicit length of options list) also has an accessor function named xcb_x_print_print_put_document_data_options_len ! So, instead of having an accessor for every field, we can have accessor for just the wire fields but only ones that need accessor (i,e the variable part of request) diff --git a/src/c_client.py b/src/c_client.py index 45ad2bf..3db313e 100644 --- a/src/c_client.py +++ b/src/c_client.py @@ -3097,15 +3097,22 @@ def c_request(self, name): else: # Request prototypes _c_request_helper(self, name, void=True, regular=False) _c_request_helper(self, name, void=True, regular=True) if self.c_need_aux: _c_request_helper(self, name, void=True, regular=False, aux=True) _c_request_helper(self, name, void=True, regular=True, aux=True) - _c_accessors(self, name, name) + for field in self.fields: + if not field.type.is_pad and field.wire: + print("My fields are : "+str(field.field_name)) + if _c_field_needs_list_accessor(field): + _c_accessors_list(self, field) + elif _c_field_needs_field_accessor(field): + _c_accessors_field(self, field) + # We generate the manpage afterwards because _c_type_setup has been called. # TODO: what about aux helpers? _man_request(self, name, void=not self.reply, aux=False) def c_event(self, name): ''' This was working fine previously, because there was no padding between lists of implicit length and a list having length. So this will solve the issue of un necessary accessor functions. Also, I am a little confused with the Implicit padding here. For the lists with implicit length, it has an implicit padding added because of the implicit length of list treated a variable sized field before the list. While, lists with a length field have their lengths as the fixed fields and hence have no such padding issues. Is this behavior expected? Can you please correct me in my understanding if I am getting something wrong here. Thank you Regards, Jaya On Tue, May 19, 2015 at 9:18 PM, Olivier Fourdan wrote: > Hi Peter, > > > Since you're fixing the protocol definition of this request, you could > > also change the comment to . ("pad > > align" is relatively recent, and I'm guessing whoever originally wrote > > xprint.xml was too lazy to put in the annoyingly large block > > required to do an alignment pad without "pad align"). > > If I add the statement, the generated code won't build > anymore :( > > It fails with: > > xprint.c: In function 'xcb_x_print_print_put_document_data_doc_format_end': > xprint.c:1338:36: error: 'None' undeclared (first use in this function) > xcb_generic_iterator_t child = None; > ^ > xprint.c:1338:36: note: each undeclared identifier is reported only once > for each function it appears in > xprint.c: In function 'xcb_x_print_print_put_document_data_options_end': > xprint.c:1362:36: error: 'None' undeclared (first use in this function) > xcb_generic_iterator_t child = None; > ^ > Not sure why padding does that... > > > That said, this looks good. With or without the > changes, > > Reviewed-by: Peter Harris > > Cheers! > Olivier > _______________________________________________ > Xcb mailing list > Xcb at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xcb > -- Regards, Jaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From lory.fulgi at infinito.it Tue Jun 9 08:28:28 2015 From: lory.fulgi at infinito.it (Lorenzo Beretta) Date: Tue, 09 Jun 2015 17:28:28 +0200 Subject: [Xcb] Bug#788232: /usr/include/xcb/xcb.h: xcb/xproto.h can't be included Message-ID: <20150609152828.10244.12097.reportbug@berry.homenet.telecomitalia.it> Package: libxcb1-dev Version: 1.10-3+b1 Severity: important File: /usr/include/xcb/xcb.h Dear Maintainer, the headers in libxcb1-dev have a bug that appears to have been fixed upstream and makes the package basically unusable: $ cat>test.c < int main() { return 0; } EOF $ gcc test.c In file included from /usr/include/xcb/xproto.h:15:0, from test.c:1: /usr/include/xcb/xcb.h:401:7: error: unknown type name ‘xcb_query_extension_reply_t’ const xcb_query_extension_reply_t *xcb_get_extension_data(xcb_connection_t *c, xcb_extension_t *ext); ^ /usr/include/xcb/xcb.h:437:7: error: unknown type name ‘xcb_setup_t’ const xcb_setup_t *xcb_get_setup(xcb_connection_t *c); ^ Probably same bug as 778307, except for people using the -dev package it's completely broken, not just a wishlist. Thanks, Lorenzo. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static Init: systemd (via /run/systemd/system) Versions of packages libxcb1-dev:amd64 depends on: ii libpthread-stubs0-dev 0.3-4 ii libxau-dev 1:1.0.8-1 ii libxcb1 1.10-3+b1 ii libxdmcp-dev 1:1.1.2-1 libxcb1-dev:amd64 recommends no packages. Versions of packages libxcb1-dev:amd64 suggests: pn libxcb-doc -- no debconf information From psychon at znc.in Wed Jun 10 00:32:31 2015 From: psychon at znc.in (Uli Schlachter) Date: Wed, 10 Jun 2015 09:32:31 +0200 Subject: [Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader In-Reply-To: <556BBEE5.3000204@daenzer.net> References: <1432543801-31649-2-git-send-email-michel@daenzer.net> <1432543974-1005-1-git-send-email-michel@daenzer.net> <5569AB77.7080600@znc.in> <556BBEE5.3000204@daenzer.net> Message-ID: <5577E80F.6050601@znc.in> Am 01.06.2015 um 04:09 schrieb Michel Dänzer: > On 30.05.2015 21:22, Uli Schlachter wrote: >> Am 25.05.2015 um 10:52 schrieb Michel Dänzer: >>> From: Michel Dänzer >>> >>> Fixes occasional deadlock when quitting the Mesa demo glthreads with >>> DRI3/Present. >>> >>> Signed-off-by: Michel Dänzer >>> --- >>> >>> v2: Fix indentation of closing curly brace. >>> >>> src/xcb_in.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/src/xcb_in.c b/src/xcb_in.c >>> index 322bed8..9a8cae1 100644 >>> --- a/src/xcb_in.c >>> +++ b/src/xcb_in.c >>> @@ -890,7 +890,14 @@ void _xcb_in_wake_up_next_reader(xcb_connection_t *c) >>> if(c->in.readers) >>> pthreadret = pthread_cond_signal(c->in.readers->data); >>> else >>> + { >>> + xcb_special_event_t *se; >>> + >>> pthreadret = pthread_cond_signal(&c->in.event_cond); >>> + for (se = c->in.special_events; se; se = se->next) { >>> + pthreadret = pthread_cond_signal(&se->special_event_cond); btw: This should be pthreadret |= ... >>> + } >>> + } >>> assert(pthreadret == 0); >>> } >> >> Hrm. This is basically a pthread_cond_broadcast() waking up all threads, even >> those for which we do not have a special event. >> >> Can you explain why this is necessary at all? The function event_special() >> should be handling this. This is called on all special events. It appends the >> event to the xcb_special_event_t's event queue and then calls >> pthread_cond_signal() on exactly this condition variable. >> >> In my understanding, that should be enough. Why would we need a "wake up all >> waiting threads and let them figure out if they have to do something themselves"? > > I can't explain why, but what you're saying applies to "normal" events > as well, doesn't it? _xcb_in_wake_up_next_reader() signals > c->in.event_cond, even though read_packet() already does the same. This > change is mirroring that for special events. Can you try changing your above pthread_cond_signal() into a pthread_cond_broadcast? Alternatively, change the pthread_cond_signal() in event_special() to pthread_cond_broadcast() and see if that helps. (The idea being: There are multiple threads in xcb_wait_for_special_event() concurrently.) I tried the reproducing program from [1] and while I can also reproduce the hang that your first patch fixes (and I can confirm that the patch fixes the problem), I cannot reproduce any hang that this patch would have to fix. (But this program has only two threads where one thread doesn't call any of xcb's special_event code. Perhaps if that program where extended to a greater level of parallelism where multiple threads wait for special events at the same time?) Since this is threading-related, something like "I can't explain why" doesn't really satisfy for fixing a missed wakeup, sorry. Cheers, Uli [1]: https://bugs.freedesktop.org/show_bug.cgi?id=84252 -- “I’m Olaf and I like warm hugs.” From michel at daenzer.net Wed Jun 10 03:00:59 2015 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Wed, 10 Jun 2015 19:00:59 +0900 Subject: [Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader In-Reply-To: <5577E80F.6050601@znc.in> References: <1432543801-31649-2-git-send-email-michel@daenzer.net> <1432543974-1005-1-git-send-email-michel@daenzer.net> <5569AB77.7080600@znc.in> <556BBEE5.3000204@daenzer.net> <5577E80F.6050601@znc.in> Message-ID: <55780ADB.3020706@daenzer.net> On 10.06.2015 16:32, Uli Schlachter wrote: > Am 01.06.2015 um 04:09 schrieb Michel Dänzer: >> On 30.05.2015 21:22, Uli Schlachter wrote: >>> Am 25.05.2015 um 10:52 schrieb Michel Dänzer: >>>> From: Michel Dänzer >>>> >>>> Fixes occasional deadlock when quitting the Mesa demo glthreads with >>>> DRI3/Present. >>>> >>>> Signed-off-by: Michel Dänzer >>>> --- >>>> >>>> v2: Fix indentation of closing curly brace. >>>> >>>> src/xcb_in.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/src/xcb_in.c b/src/xcb_in.c >>>> index 322bed8..9a8cae1 100644 >>>> --- a/src/xcb_in.c >>>> +++ b/src/xcb_in.c >>>> @@ -890,7 +890,14 @@ void _xcb_in_wake_up_next_reader(xcb_connection_t *c) >>>> if(c->in.readers) >>>> pthreadret = pthread_cond_signal(c->in.readers->data); >>>> else >>>> + { >>>> + xcb_special_event_t *se; >>>> + >>>> pthreadret = pthread_cond_signal(&c->in.event_cond); >>>> + for (se = c->in.special_events; se; se = se->next) { >>>> + pthreadret = pthread_cond_signal(&se->special_event_cond); > > btw: This should be > > pthreadret |= ... Thanks, updated locally. >>>> + } >>>> + } >>>> assert(pthreadret == 0); >>>> } >>> >>> Hrm. This is basically a pthread_cond_broadcast() waking up all threads, even >>> those for which we do not have a special event. >>> >>> Can you explain why this is necessary at all? The function event_special() >>> should be handling this. This is called on all special events. It appends the >>> event to the xcb_special_event_t's event queue and then calls >>> pthread_cond_signal() on exactly this condition variable. >>> >>> In my understanding, that should be enough. Why would we need a "wake up all >>> waiting threads and let them figure out if they have to do something themselves"? >> >> I can't explain why, but what you're saying applies to "normal" events >> as well, doesn't it? _xcb_in_wake_up_next_reader() signals >> c->in.event_cond, even though read_packet() already does the same. This >> change is mirroring that for special events. > > Can you try changing your above pthread_cond_signal() into a > pthread_cond_broadcast? Not that in contrast to what you wrote above, the code I'm adding isn't the same as pthread_cond_broadcast: My code calls pthread_cond_signal for each special event condition variable, waking up one random thread (or none) waiting for each of them. pthread_cond_broadcast wakes up all threads waiting for a condition variable. So, I'm confused why you're now asking me to try waking up even more threads, when you wrote above that waking any additional threads shouldn't be necessary. > Alternatively, change the pthread_cond_signal() in event_special() > to pthread_cond_broadcast() and see if that helps. > > (The idea being: There are multiple threads in xcb_wait_for_special_event() > concurrently.) That doesn't fix the first problem described below. > I tried the reproducing program from [1] and while I can also reproduce the hang > that your first patch fixes (and I can confirm that the patch fixes the > problem), I cannot reproduce any hang that this patch would have to fix. As described in the commit log, the test case for this patch is a different one: The Mesa demos program called glthreads, which creates several threads rendering with OpenGL (to one separate window each) concurrently. The problem fixed by this patch is that glthreads often hangs when trying to quit by pressing the Escape key. Note that glthreads also exhibits another problem, which none of the changes above fix: Sometimes when starting it, the windows stay black until I press any key. I'm including the backtrace corresponding to this hang at the end of this message. Another problem which I suspect might be related, but which isn't fixed by these changes, is https://bugs.freedesktop.org/show_bug.cgi?id=90798 All of these problems only occur when the OpenGL implementation uses the DRI3/Present extensions, which rely on special events. Thread 2 (Thread 0x7ff7ba9ce700 (LWP 5359)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007ff7c36ab3d5 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #2 0x00007ff7c36a6cad in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3 0x00007ff7c3d089bb in dri3_update_drawable (driDrawable=, loaderPrivate=0x7ff7ac0008c0) at ../../../src/glx/dri3_glx.c:1072 #4 dri3_get_buffers (driDrawable=, format=4098, stamp=, loaderPrivate=0x7ff7ac0008c0, buffer_mask=1, buffers=0x7ff7ba9cdb70) at ../../../src/glx/dri3_glx.c:1438 #5 0x00007ff7be9d7d60 in dri_image_drawable_get_buffers (statts_count=, statts=, images=, drawable=) at ../../../../../src/gallium/state_trackers/dri/dri2.c:279 #6 dri2_allocate_textures (ctx=0x10b8270, drawable=0x7ff7ac0009f0, statts=0x7ff7ac001048, statts_count=2) at ../../../../../src/gallium/state_trackers/dri/dri2.c:402 #7 0x00007ff7be9d3dbd in dri_st_framebuffer_validate (stctx=, stfbi=, statts=0x7ff7ac001048, count=2, out=0x7ff7ba9cdcd0) at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:83 #8 0x00007ff7be8bdfde in st_framebuffer_validate (stfb=0x7ff7ac000c00, st=st at entry=0x111cfb0) at ../../../src/mesa/state_tracker/st_manager.c:200 #9 0x00007ff7be8bf513 in st_api_make_current (stapi=, stctxi=0x111cfb0, stdrawi=0x7ff7ac0009f0, streadi=0x7ff7ac0009f0) at ../../../src/mesa/state_tracker/st_manager.c:769 #10 0x00007ff7be9d38f1 in dri_make_current (cPriv=, driDrawPriv=0x7ff7ac0009b0, driReadPriv=0x7ff7ac0009b0) at ../../../../../src/gallium/state_trackers/dri/dri_context.c:234 #11 0x00007ff7be9cf314 in driBindContext (pcp=, pdp=, prp=) at ../../../../../../src/mesa/drivers/dri/common/dri_util.c:538 #12 0x00007ff7c3d063da in dri3_bind_context (context=0x10b8090, old=, draw=, read=) at ../../../src/glx/dri3_glx.c:145 #13 0x00007ff7c3cd948e in MakeContextCurrent (gc_user=0x10b8090, read=39845893, draw=39845893, dpy=0xfd9c80) at ../../../src/glx/glxcurrent.c:228 #14 glXMakeCurrent (dpy=0xfd9c80, draw=39845893, gc=0x10b8090) at ../../../src/glx/glxcurrent.c:262 #15 0x0000000000402588 in draw_loop (wt=0x6045b8 ) at glthreads.c:243 #16 thread_function (p=0x6045b8 ) at glthreads.c:526 #17 0x00007ff7c32380a4 in start_thread (arg=0x7ff7ba9ce700) at pthread_create.c:309 #18 0x00007ff7c2f6604d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7ff7c46377c0 (LWP 5356)): #0 0x00007ff7c2f5d50d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ff7c0e3bfd2 in _xcb_conn_wait (c=0xfdb3d0, cond=, vector=0x0, count=0x0) at ../../src/xcb_conn.c:479 #2 0x00007ff7c0e3db6f in xcb_wait_for_event (c=0x7ffc7b991740) at ../../src/xcb_in.c:668 #3 0x00007ff7c36aafe8 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 0x00007ff7c369a078 in XNextEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #5 0x0000000000401ff5 in event_loop (dpy=) at glthreads.c:378 #6 main (argc=, argv=) at glthreads.c:684 -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From psychon at znc.in Wed Jun 10 03:56:50 2015 From: psychon at znc.in (Uli Schlachter) Date: Wed, 10 Jun 2015 12:56:50 +0200 Subject: [Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader In-Reply-To: <55780ADB.3020706@daenzer.net> References: <1432543801-31649-2-git-send-email-michel@daenzer.net> <1432543974-1005-1-git-send-email-michel@daenzer.net> <5569AB77.7080600@znc.in> <556BBEE5.3000204@daenzer.net> <5577E80F.6050601@znc.in> <55780ADB.3020706@daenzer.net> Message-ID: <557817F2.7080802@znc.in> Am 10.06.2015 um 12:00 schrieb Michel Dänzer: > On 10.06.2015 16:32, Uli Schlachter wrote: >> Am 01.06.2015 um 04:09 schrieb Michel Dänzer: >>> On 30.05.2015 21:22, Uli Schlachter wrote: [...] >>>> Hrm. This is basically a pthread_cond_broadcast() waking up all threads, even >>>> those for which we do not have a special event. >>>> >>>> Can you explain why this is necessary at all? The function event_special() >>>> should be handling this. This is called on all special events. It appends the >>>> event to the xcb_special_event_t's event queue and then calls >>>> pthread_cond_signal() on exactly this condition variable. >>>> >>>> In my understanding, that should be enough. Why would we need a "wake up all >>>> waiting threads and let them figure out if they have to do something themselves"? >>> >>> I can't explain why, but what you're saying applies to "normal" events >>> as well, doesn't it? _xcb_in_wake_up_next_reader() signals >>> c->in.event_cond, even though read_packet() already does the same. This >>> change is mirroring that for special events. >> >> Can you try changing your above pthread_cond_signal() into a >> pthread_cond_broadcast? > > Not that in contrast to what you wrote above, the code I'm adding isn't > the same as pthread_cond_broadcast: My code calls pthread_cond_signal > for each special event condition variable, waking up one random thread > (or none) waiting for each of them. pthread_cond_broadcast wakes up all > threads waiting for a condition variable. > > So, I'm confused why you're now asking me to try waking up even more > threads, when you wrote above that waking any additional threads > shouldn't be necessary. I got myself confused, sorry. The above shouldn't make a difference, but in the following... >> Alternatively, change the pthread_cond_signal() in event_special() >> to pthread_cond_broadcast() and see if that helps. >> >> (The idea being: There are multiple threads in xcb_wait_for_special_event() >> concurrently.) ... the idea was for a case where multiple threads are stuck in xcb_wait_for_special_event(). My current understanding is that _xcb_in_wake_up_next_reader() is needed for a case where multiple threads are waiting for events, replies or special events. To you know if Mesa ever does this? For the same kind of event or for different ones? > That doesn't fix the first problem described below. I understand this as "this doesn't fix any problem", but just to be sure: Do you mean "this fixes some problem, but not all"? >> I tried the reproducing program from [1] and while I can also reproduce the hang >> that your first patch fixes (and I can confirm that the patch fixes the >> problem), I cannot reproduce any hang that this patch would have to fix. > > As described in the commit log, the test case for this patch is a > different one: The Mesa demos program called glthreads, which creates > several threads rendering with OpenGL (to one separate window each) > concurrently. > > The problem fixed by this patch is that glthreads often hangs when > trying to quit by pressing the Escape key. Is there any easy way to get glthreads on debian that doesn't involve building something "big" like all of mesa? There doesn't seem to be a debian package for it. Does this hang have the same backtrace as what the example program demonstrates and that is fixed with patch 1: One thread stuck in _xcb_conn_wait() -> pthread_cond_wait and no other threads inside of libxcb? > Note that glthreads also exhibits another problem, which none of the > changes above fix: Sometimes when starting it, the windows stay black > until I press any key. I'm including the backtrace corresponding to this > hang at the end of this message. > > > Another problem which I suspect might be related, but which isn't fixed > by these changes, is https://bugs.freedesktop.org/show_bug.cgi?id=90798 I have no idea how XCB could have anything to do with this, nor do I know how this could happen at all, sorry. > All of these problems only occur when the OpenGL implementation uses > the DRI3/Present extensions, which rely on special events. > > > Thread 2 (Thread 0x7ff7ba9ce700 (LWP 5359)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007ff7c36ab3d5 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #2 0x00007ff7c36a6cad in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #3 0x00007ff7c3d089bb in dri3_update_drawable (driDrawable=, loaderPrivate=0x7ff7ac0008c0) at ../../../src/glx/dri3_glx.c:1072 > #4 dri3_get_buffers (driDrawable=, format=4098, stamp=, loaderPrivate=0x7ff7ac0008c0, buffer_mask=1, buffers=0x7ff7ba9cdb70) at ../../../src/glx/dri3_glx.c:1438 > #5 0x00007ff7be9d7d60 in dri_image_drawable_get_buffers (statts_count=, statts=, images=, drawable=) at ../../../../../src/gallium/state_trackers/dri/dri2.c:279 > #6 dri2_allocate_textures (ctx=0x10b8270, drawable=0x7ff7ac0009f0, statts=0x7ff7ac001048, statts_count=2) at ../../../../../src/gallium/state_trackers/dri/dri2.c:402 > #7 0x00007ff7be9d3dbd in dri_st_framebuffer_validate (stctx=, stfbi=, statts=0x7ff7ac001048, count=2, out=0x7ff7ba9cdcd0) at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:83 > #8 0x00007ff7be8bdfde in st_framebuffer_validate (stfb=0x7ff7ac000c00, st=st at entry=0x111cfb0) at ../../../src/mesa/state_tracker/st_manager.c:200 > #9 0x00007ff7be8bf513 in st_api_make_current (stapi=, stctxi=0x111cfb0, stdrawi=0x7ff7ac0009f0, streadi=0x7ff7ac0009f0) at ../../../src/mesa/state_tracker/st_manager.c:769 > #10 0x00007ff7be9d38f1 in dri_make_current (cPriv=, driDrawPriv=0x7ff7ac0009b0, driReadPriv=0x7ff7ac0009b0) at ../../../../../src/gallium/state_trackers/dri/dri_context.c:234 > #11 0x00007ff7be9cf314 in driBindContext (pcp=, pdp=, prp=) at ../../../../../../src/mesa/drivers/dri/common/dri_util.c:538 > #12 0x00007ff7c3d063da in dri3_bind_context (context=0x10b8090, old=, draw=, read=) at ../../../src/glx/dri3_glx.c:145 > #13 0x00007ff7c3cd948e in MakeContextCurrent (gc_user=0x10b8090, read=39845893, draw=39845893, dpy=0xfd9c80) at ../../../src/glx/glxcurrent.c:228 > #14 glXMakeCurrent (dpy=0xfd9c80, draw=39845893, gc=0x10b8090) at ../../../src/glx/glxcurrent.c:262 > #15 0x0000000000402588 in draw_loop (wt=0x6045b8 ) at glthreads.c:243 > #16 thread_function (p=0x6045b8 ) at glthreads.c:526 > #17 0x00007ff7c32380a4 in start_thread (arg=0x7ff7ba9ce700) at pthread_create.c:309 > #18 0x00007ff7c2f6604d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > Thread 1 (Thread 0x7ff7c46377c0 (LWP 5356)): > #0 0x00007ff7c2f5d50d in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x00007ff7c0e3bfd2 in _xcb_conn_wait (c=0xfdb3d0, cond=, vector=0x0, count=0x0) at ../../src/xcb_conn.c:479 > #2 0x00007ff7c0e3db6f in xcb_wait_for_event (c=0x7ffc7b991740) at ../../src/xcb_in.c:668 > #3 0x00007ff7c36aafe8 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #4 0x00007ff7c369a078 in XNextEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #5 0x0000000000401ff5 in event_loop (dpy=) at glthreads.c:378 > #6 main (argc=, argv=) at glthreads.c:684 This is a bug in libX11. To quote the source for _XReply(): /* We have the response we're looking for. Now, before * letting anyone else process this sequence number, we * need to process any events that should have come * earlier. */ if(dpy->xcb->event_owner == XlibOwnsEventQueue) { xcb_generic_reply_t *event; /* If some thread is already waiting for events, * it will get the first one. That thread must * process that event before we can continue. */ /* FIXME: That event might be after this reply, * and might never even come--or there might be * multiple threads trying to get events. */ while(dpy->xcb->event_waiter) { /* need braces around ConditionWait */ ConditionWait(dpy, dpy->xcb->event_notify); } while((event = poll_for_event(dpy))) handle_response(dpy, event, True); } So in the above case, _XReply() got the response that XSync() wants, but it also needs to handle any events that came "on the wire" before this response. XCB pretty much hides/destroys this order. To get it, this code wants to poll for events, but only one thread at a time can handle events and thus this first wants to wait for the other thread waiting for events to be done. This is also why pressing a key helps: Any event will wake up thread 1 and make it return from XNextEvent() and "on its way out" it will wake up thread 2 which is now allowed to make sure that no event came before this reply "on wire". I don't know what can be done about this problem, but it's a known threading bug in libX11. Cheers, Uli -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. From bugzilla-daemon at freedesktop.org Wed Jun 10 12:39:29 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 10 Jun 2015 19:39:29 +0000 Subject: [Xcb] [Bug 71338] Application crashes after many hours of drawing In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=71338 --- Comment #19 from jh4913895 at gmail.com --- Our QA team ran into this issue recently. Upon further testing, the XNoOp test still causes the IO error for a 32-bit program with libxcb 1.10-3 on Debian 8 and libxcb 1.10-2 on Ubuntu 14.04 LTS. I don't see any mention of a fix related to this issue in the libxcb 1.11 announcement. Are there any plans to make a fix for this? -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at daenzer.net Wed Jun 10 22:54:25 2015 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Thu, 11 Jun 2015 14:54:25 +0900 Subject: [Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader In-Reply-To: <557817F2.7080802@znc.in> References: <1432543801-31649-2-git-send-email-michel@daenzer.net> <1432543974-1005-1-git-send-email-michel@daenzer.net> <5569AB77.7080600@znc.in> <556BBEE5.3000204@daenzer.net> <5577E80F.6050601@znc.in> <55780ADB.3020706@daenzer.net> <557817F2.7080802@znc.in> Message-ID: <55792291.4080807@daenzer.net> On 10.06.2015 19:56, Uli Schlachter wrote: > Am 10.06.2015 um 12:00 schrieb Michel Dänzer: >> On 10.06.2015 16:32, Uli Schlachter wrote: > [...] >>> Alternatively, change the pthread_cond_signal() in event_special() >>> to pthread_cond_broadcast() and see if that helps. >>> >>> (The idea being: There are multiple threads in xcb_wait_for_special_event() >>> concurrently.) > > ... the idea was for a case where multiple threads are stuck in > xcb_wait_for_special_event(). My current understanding is that > _xcb_in_wake_up_next_reader() is needed for a case where multiple threads are > waiting for events, replies or special events. To you know if Mesa ever does > this? For the same kind of event or for different ones? Mesa doesn't spawn multiple threads processing X11 events by itself, however, applications can use OpenGL from multiple threads concurrently (like the glthreads Mesa demo), or use OpenGL in one thread and process X11 events in another thread. >> That doesn't fix the first problem described below. > > I understand this as "this doesn't fix any problem", [...] That's indeed what I meant. >> As described in the commit log, the test case for this patch is a >> different one: The Mesa demos program called glthreads, which creates >> several threads rendering with OpenGL (to one separate window each) >> concurrently. >> >> The problem fixed by this patch is that glthreads often hangs when >> trying to quit by pressing the Escape key. > > Is there any easy way to get glthreads on debian that doesn't involve building > something "big" like all of mesa? git clone git://anongit.freedesktop.org/mesa/demos cd demos ./autogen.sh make -C src/xdemos glthreads > Does this hang have the same backtrace as what the example program demonstrates > and that is fixed with patch 1: One thread stuck in _xcb_conn_wait() -> > pthread_cond_wait and no other threads inside of libxcb? No, here's the backtrace of the hanging threads: Thread 2 (Thread 0x7f3bfa91f700 (LWP 13505)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f3c0058c219 in _xcb_conn_wait (c=0x24641d0, cond=, vector=0x0, count=0x0) at ../../src/xcb_conn.c:447 #2 0x00007f3c0058dbd9 in xcb_wait_for_special_event (c=0x7f3bf400130c, c at entry=0x24641d0, se=0x80) at ../../src/xcb_in.c:761 #3 0x00007f3c03458e3f in dri3_find_back (priv=0x7f3bf40008c0, c=0x24641d0) at ../../../src/glx/dri3_glx.c:1268 #4 dri3_get_buffer (driDrawable=, loaderPrivate=0x7f3bf40008c0, buffer_type=dri3_buffer_back, format=4098) at ../../../src/glx/dri3_glx.c:1294 #5 dri3_get_buffers (driDrawable=, format=4098, stamp=, loaderPrivate=0x7f3bf40008c0, buffer_mask=, buffers=0x7f3bfa91eb40) at ../../../src/glx/dri3_glx.c:1473 #6 0x00007f3bfe127d60 in dri_image_drawable_get_buffers (statts_count=, statts=, images=, drawable=) at ../../../../../src/gallium/state_trackers/dri/dri2.c:279 #7 dri2_allocate_textures (ctx=0x24cbd60, drawable=0x7f3bf40009f0, statts=0x7f3bf4001048, statts_count=2) at ../../../../../src/gallium/state_trackers/dri/dri2.c:402 #8 0x00007f3bfe123dbd in dri_st_framebuffer_validate (stctx=, stfbi=, statts=0x7f3bf4001048, count=2, out=0x7f3bfa91eca0) at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:83 #9 0x00007f3bfe00dfde in st_framebuffer_validate (stfb=stfb at entry=0x7f3bf4000c00, st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_manager.c:200 #10 0x00007f3bfe00fbc5 in st_manager_validate_framebuffers (st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_manager.c:863 #11 0x00007f3bfdfc8e16 in st_validate_state (st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_atom.c:181 #12 0x00007f3bfdfd2821 in st_Clear (ctx=0x7f3c03cd7010, mask=18) at ../../../src/mesa/state_tracker/st_cb_clear.c:463 #13 0x00000000004025c7 in draw_loop (wt=0x604580 ) at glthreads.c:275 #14 thread_function (p=0x604580 ) at glthreads.c:526 #15 0x00007f3c029880a4 in start_thread (arg=0x7f3bfa91f700) at pthread_create.c:309 #16 0x00007f3c026b604d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f3c03d847c0 (LWP 13503)): #0 0x00007f3c029894db in pthread_join (threadid=139895583667968, thread_return=thread_return at entry=0x0) at pthread_join.c:92 #1 0x0000000000401f4a in clean_up () at glthreads.c:541 #2 main (argc=, argv=) at glthreads.c:686 >> Another problem which I suspect might be related, but which isn't fixed >> by these changes, is https://bugs.freedesktop.org/show_bug.cgi?id=90798 > > I have no idea how XCB could have anything to do with this, nor do I know how > this could happen at all, sorry. It's just a hunch, because the ingredients seem similar to the other problems we're discussing here: Multiple threads, DRI3/Present, X11 events related trouble. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From bugzilla-daemon at freedesktop.org Thu Jun 11 00:45:30 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 11 Jun 2015 07:45:30 +0000 Subject: [Xcb] [Bug 71338] Application crashes after many hours of drawing In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=71338 --- Comment #20 from Olivier Fourdan --- (In reply to jh4913895 from comment #19) > Our QA team ran into this issue recently. Upon further testing, the XNoOp > test still causes the IO error for a 32-bit program with libxcb 1.10-3 on > Debian 8 and libxcb 1.10-2 on Ubuntu 14.04 LTS. I don't see any mention of > a fix related to this issue in the libxcb 1.11 announcement. Because libxcb-1.11 predates the fix, see comment #18 > Are there any plans to make a fix for this? The fix is made of 2 different patches for 2 different packages. 1. XCB needs to expose the 64bit sequence number by an API addition, this is comment #18 2. Xlib needs to make use of it, that's a separate (bigger) patch for libX11. But for #2 to happen, it requires an official release of libxcb that includes #1 (not 1.11) so that libX11 can depend on the appropriate XCB version that exposes the 64bit API. -- You are receiving this mail because: You are on the CC list for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at DemoRecorder.com Thu Jun 11 08:23:06 2015 From: chris at DemoRecorder.com (Christian Linhart) Date: Thu, 11 Jun 2015 17:23:06 +0200 Subject: [Xcb] Pushed [PATCH libxcb 1/1] fix ABI/API compatibility problem in present In-Reply-To: <1432556078-61670-1-git-send-email-chris@demorecorder.com> References: <1432556078-61670-1-git-send-email-chris@demorecorder.com> Message-ID: <5579A7DA.8030207@DemoRecorder.com> Pushed to the lib/proto since there were no comments for more than two weeks. On 05/25/15 14:14, Christian Linhart wrote: > for function xcb_present_redirect_notify_sizeof > > removing the explicit length of the list that was added since the > last release with the following changeset: > http://cgit.freedesktop.org/xcb/proto/commit/?id=c9b1523b23af52087a6354730f86b8d19fa3c7c0 > > Removing the explicit length again is OK because > implicit length is allowed when a list is the last > field of a request or event. > > The compile problem that the prior change has tried to fix, > has been fixed in another way. Therefore removing the explicit length > is safe now. > > Signed-off-by: Christian Linhart > --- > src/present.xml | 10 +--------- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/src/present.xml b/src/present.xml > index 95fee01..513388c 100644 > --- a/src/present.xml > +++ b/src/present.xml > @@ -195,19 +195,11 @@ > > > > > > > > - > - > - > - length > - 18 > - > - 2 > - > - > + > > > From psychon at znc.in Thu Jun 11 09:50:02 2015 From: psychon at znc.in (Uli Schlachter) Date: Thu, 11 Jun 2015 18:50:02 +0200 Subject: [Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader In-Reply-To: <55792291.4080807@daenzer.net> References: <1432543801-31649-2-git-send-email-michel@daenzer.net> <1432543974-1005-1-git-send-email-michel@daenzer.net> <5569AB77.7080600@znc.in> <556BBEE5.3000204@daenzer.net> <5577E80F.6050601@znc.in> <55780ADB.3020706@daenzer.net> <557817F2.7080802@znc.in> <55792291.4080807@daenzer.net> Message-ID: <5579BC3A.7060504@znc.in> Hi, Am 11.06.2015 um 07:54 schrieb Michel Dänzer: [...] >>> As described in the commit log, the test case for this patch is a >>> different one: The Mesa demos program called glthreads, which creates >>> several threads rendering with OpenGL (to one separate window each) >>> concurrently. >>> >>> The problem fixed by this patch is that glthreads often hangs when >>> trying to quit by pressing the Escape key. >> >> Is there any easy way to get glthreads on debian that doesn't involve building >> something "big" like all of mesa? > > git clone git://anongit.freedesktop.org/mesa/demos > cd demos > ./autogen.sh > make -C src/xdemos glthreads Thanks, that was indeed relatively easy (and only required 7MiB of additional packages). Sadly, I cannot reproduce this hang, but I can easily reproduce the Xlib problem of "only progresses when an event is received" / "XNextEvent() in one threads blocks other threads from receiving a reply". I made it easier to work around this locally by adding PointerMotionMask to the window's event_mask. That allows me to just move the mouse pointer around to have the window update. :-) Not once did it hang after pressing escape at random times. The only problem I saw was with arguments "-t" once when changing textures: (gdb) run -t Starting program: /tmp/demos/src/xdemos/glthreads -t [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". glthreads: No explict locking. glthreads: Single display connection. XInitThreads() returned 1 (success) glthreads: creating windows glthreads: creating threads [New Thread 0x7fffefa3c700 (LWP 371)] glthreads: Created thread 0x7fffefa3c700 [New Thread 0x7fffef23b700 (LWP 372)] glthreads: Created thread 0x7fffef23b700 glthreads: 0: GL_RENDERER = Mesa DRI Mobile Intel® GM45 Express Chipset glthreads: 1: GL_RENDERER = Mesa DRI Mobile Intel® GM45 Express Chipset glthreads: malloc.c:3987: _int_free: Assertion `p->fd_nextsize->bk_nextsize == p' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffef23b700 (LWP 372)] 0x00007ffff6865107 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x00007ffff6865107 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff68664e8 in __GI_abort () at abort.c:89 #2 0x00007ffff68a80fd in __malloc_assert (assertion=assertion at entry=0x7ffff6996028 "p->fd_nextsize->bk_nextsize == p", file=file at entry=0x7ffff6992005 "malloc.c", line=line at entry=3987, function=function at entry=0x7ffff69923a3 <__func__.11561> "_int_free") at malloc.c:293 #3 0x00007ffff68a9b1e in _int_free (av=0x7ffff6bd3620 , p=, have_lock=0) at malloc.c:3987 #4 0x00007ffff29e7eee in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #5 0x00007ffff29cbc69 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #6 0x00007ffff29cc590 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #7 0x00007ffff2adac1b in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so #8 0x00000000004025a7 in draw_loop (wt=0x6045f8 ) at glthreads.c:275 #9 thread_function (p=0x6045f8 ) at glthreads.c:526 #10 0x00007ffff6be10a4 in start_thread (arg=0x7fffef23b700) at pthread_create.c:309 #11 0x00007ffff691604d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I'll just ignore this. >> Does this hang have the same backtrace as what the example program demonstrates >> and that is fixed with patch 1: One thread stuck in _xcb_conn_wait() -> >> pthread_cond_wait and no other threads inside of libxcb? > > No, here's the backtrace of the hanging threads: > > Thread 2 (Thread 0x7f3bfa91f700 (LWP 13505)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007f3c0058c219 in _xcb_conn_wait (c=0x24641d0, cond=, vector=0x0, count=0x0) at ../../src/xcb_conn.c:447 > #2 0x00007f3c0058dbd9 in xcb_wait_for_special_event (c=0x7f3bf400130c, c at entry=0x24641d0, se=0x80) at ../../src/xcb_in.c:761 > #3 0x00007f3c03458e3f in dri3_find_back (priv=0x7f3bf40008c0, c=0x24641d0) at ../../../src/glx/dri3_glx.c:1268 > #4 dri3_get_buffer (driDrawable=, loaderPrivate=0x7f3bf40008c0, buffer_type=dri3_buffer_back, format=4098) at ../../../src/glx/dri3_glx.c:1294 > #5 dri3_get_buffers (driDrawable=, format=4098, stamp=, loaderPrivate=0x7f3bf40008c0, buffer_mask=, buffers=0x7f3bfa91eb40) at ../../../src/glx/dri3_glx.c:1473 > #6 0x00007f3bfe127d60 in dri_image_drawable_get_buffers (statts_count=, statts=, images=, drawable=) at ../../../../../src/gallium/state_trackers/dri/dri2.c:279 > #7 dri2_allocate_textures (ctx=0x24cbd60, drawable=0x7f3bf40009f0, statts=0x7f3bf4001048, statts_count=2) at ../../../../../src/gallium/state_trackers/dri/dri2.c:402 > #8 0x00007f3bfe123dbd in dri_st_framebuffer_validate (stctx=, stfbi=, statts=0x7f3bf4001048, count=2, out=0x7f3bfa91eca0) at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:83 > #9 0x00007f3bfe00dfde in st_framebuffer_validate (stfb=stfb at entry=0x7f3bf4000c00, st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_manager.c:200 > #10 0x00007f3bfe00fbc5 in st_manager_validate_framebuffers (st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_manager.c:863 > #11 0x00007f3bfdfc8e16 in st_validate_state (st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_atom.c:181 > #12 0x00007f3bfdfd2821 in st_Clear (ctx=0x7f3c03cd7010, mask=18) at ../../../src/mesa/state_tracker/st_cb_clear.c:463 > #13 0x00000000004025c7 in draw_loop (wt=0x604580 ) at glthreads.c:275 > #14 thread_function (p=0x604580 ) at glthreads.c:526 > #15 0x00007f3c029880a4 in start_thread (arg=0x7f3bfa91f700) at pthread_create.c:309 > #16 0x00007f3c026b604d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > Thread 1 (Thread 0x7f3c03d847c0 (LWP 13503)): > #0 0x00007f3c029894db in pthread_join (threadid=139895583667968, thread_return=thread_return at entry=0x0) at pthread_join.c:92 > #1 0x0000000000401f4a in clean_up () at glthreads.c:541 > #2 main (argc=, argv=) at glthreads.c:686 [...] Well, yeah. One thread sitting in _xcb_conn_wait() waiting to be woken up by some other thread which "used to be" in _xcb_conn_wait() and is supposed to wake up this thread once its done using the fd. Thanks to this I finally figured out why we have this complicated wake up logic. :-) Multiple threads are waiting for things "coming from the X11 server". Only one thread can recv() from the socket at the same time (else we can't wake up other threads if we just received what they are waiting for). When a reply/error comes in, the thread waiting for this (if it exists) is woken up directly from read_packet() so that it can gets "its stuff" from our linked lists. For special events this is done by event_special(). So this is the "you can return to your caller now"-case. This case is working fine. When the current thread received what it wanted and is done, some other thread has to take over reading from the socket. This is done by _xcb_in_wake_up_next_reader(), but currently this doesn't wake up threads waiting for special events. This is the bug that is left (and which I cannot reproduce currently). (Also, your first bug was related to this code as well) However, since only one thread is allowed to recv() from the socket at any time, waking up "all" of them just so that most of them go back to sleep without changing anything isn't really effective. Instead, we'd need a linked list of threads waiting for special events, similar like we have with wait_for_reply() / insert_reader() / remove_reader() right now. Then, _xcb_in_wake_up_next_reader() could wake up exactly one thread waiting for a special event that will then take over reading from the socket. This all sounds relatively complicated and non-trivial. Should we instead just live with the "easy case" of waking up too many threads and let them go to sleep again? That'd be the patch that was originally proposed in this thread (and whose commit message might be enhanced with some explanation of the above). What do others think? Cheers, Uli -- “Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold.” – Anna From chris at demorecorder.com Thu Jun 11 09:58:38 2015 From: chris at demorecorder.com (Christian Linhart) Date: Thu, 11 Jun 2015 18:58:38 +0200 Subject: [Xcb] [PATCH libxcb 1/1] make support for server side stuff optional Message-ID: <1434041918-28113-1-git-send-email-chris@demorecorder.com> and make it disabled by default with an EXPERIMENTAL warning reason: this feature is unfinished and we want to have flexibility for ABI/API changes, while still being able to make a release soon Signed-off-by: Christian Linhart --- configure.ac | 4 ++++ src/Makefile.am | 6 ++++++ src/c_client.py | 10 ++++++++-- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 6e7e9c3..44feba3 100644 --- a/configure.ac +++ b/configure.ac @@ -239,14 +239,18 @@ if test "x$LAUNCHD" = xauto; then AC_CHECK_PROG(LAUNCHD, [launchd], [yes], [no], [$PATH$PATH_SEPARATOR/sbin]) fi if test "x$LAUNCHD" = xyes ; then AC_DEFINE(HAVE_LAUNCHD, 1, [launchd support available]) fi +AC_ARG_WITH(serverside-support, AS_HELP_STRING([--with-serverside-support], [Build with support for server-side usage of xcb. This is still EXPERIMENTAL! ABI/API may change! (default: no)]), [XCB_SERVERSIDE_SUPPORT=$withval], [XCB_SERVERSIDE_SUPPORT=no]) + +AM_CONDITIONAL(XCB_SERVERSIDE_SUPPORT, test "x$XCB_SERVERSIDE_SUPPORT" = "xyes") + AC_CONFIG_FILES([ Makefile doc/Makefile man/Makefile src/Makefile tests/Makefile ]) diff --git a/src/Makefile.am b/src/Makefile.am index 5a3c52a..e06e70b 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -244,13 +244,19 @@ noinst_HEADERS = xcbint.h BUILT_MAN_PAGES = man/xcb_* libmandir = $(LIB_MAN_DIR) libman_DATA = $(BUILT_MAN_PAGES) BUILT_SOURCES = $(EXTSOURCES) $(BUILT_MAN_PAGES) CLEANFILES = $(EXTSOURCES) $(EXTHEADERS) $(BUILT_MAN_PAGES) +C_CLIENT_PY_EXTRA_ARGS = +if XCB_SERVERSIDE_SUPPORT +C_CLIENT_PY_EXTRA_ARGS += --server-side +endif + $(EXTSOURCES): c_client.py $(XCBPROTO_XCBINCLUDEDIR)/$(@:.c=.xml) $(AM_V_GEN)$(PYTHON) $(srcdir)/c_client.py -c "$(PACKAGE_STRING)" -l "$(XORG_MAN_PAGE)" \ -s "$(LIB_MAN_SUFFIX)" -p $(XCBPROTO_XCBPYTHONDIR) \ + $(C_CLIENT_PY_EXTRA_ARGS) \ $(XCBPROTO_XCBINCLUDEDIR)/$(@:.c=.xml) $(BUILT_MAN_PAGES): $(EXTSOURCES) diff --git a/src/c_client.py b/src/c_client.py index 9a7c67c..50ca753 100644 --- a/src/c_client.py +++ b/src/c_client.py @@ -4,14 +4,17 @@ import getopt import os import sys import errno import re # Jump to the bottom of this file for the main routine +#config settings (can be changed with commandline options) +config_server_side = False + # Some hacks to make the API more readable, and to keep backwards compability _cname_re = re.compile('([A-Z0-9][a-z]+|[A-Z0-9]+(?![a-z])|[a-z]+)') _cname_special_cases = {'DECnet':'decnet'} _extension_special_cases = ['XPrint', 'XCMisc', 'BigRequests'] _cplusplus_annoyances = {'class' : '_class', @@ -3091,15 +3094,16 @@ def c_request(self, name): else: # Request prototypes _c_request_helper(self, name, void=True, regular=False) _c_request_helper(self, name, void=True, regular=True) if self.c_need_aux: _c_request_helper(self, name, void=True, regular=False, aux=True) _c_request_helper(self, name, void=True, regular=True, aux=True) - _c_accessors(self, name, name) + if config_server_side: + _c_accessors(self, name, name) # We generate the manpage afterwards because _c_type_setup has been called. # TODO: what about aux helpers? _man_request(self, name, void=not self.reply, aux=False) def c_event(self, name): ''' @@ -3202,29 +3206,31 @@ output = {'open' : c_open, 'error' : c_error, } # Boilerplate below this point # Check for the argument that specifies path to the xcbgen python package. try: - opts, args = getopt.getopt(sys.argv[1:], 'c:l:s:p:m') + opts, args = getopt.getopt(sys.argv[1:], 'c:l:s:p:m', ["server-side"]) except getopt.GetoptError as err: print(err) print('Usage: c_client.py -c center_footer -l left_footer -s section [-p path] file.xml') sys.exit(1) for (opt, arg) in opts: if opt == '-c': center_footer=arg if opt == '-l': left_footer=arg if opt == '-s': section=arg if opt == '-p': sys.path.insert(1, arg) + if opt == '--server-side': + config_server_side=True elif opt == '-m': manpaths = True sys.stdout.write('man_MANS = ') # Import the module class try: from xcbgen.state import Module -- 2.0.1 From chris at DemoRecorder.com Thu Jun 11 10:29:38 2015 From: chris at DemoRecorder.com (Christian Linhart) Date: Thu, 11 Jun 2015 19:29:38 +0200 Subject: [Xcb] [PATCH libxcb 1/1] Calculate length of length less lists In-Reply-To: <1429771654-16286-1-git-send-email-tiwari.jaya18@gmail.com> References: <20150328084421.GB474@ran> <1429771654-16286-1-git-send-email-tiwari.jaya18@gmail.com> Message-ID: <5579C582.6060200@DemoRecorder.com> Hi Jaya, This patch does not apply to the current HEAD of the official repo. Probably there were incompatibilities created by other patches. Can you please adapt your patch accordingly? (and please do the changes proposed by Ran in his pre-review) We probably need this patch for the upcoming release to get good accessor function-parameterlists for "xcb_present_redirect_notify...". With "good" I especially mean parameterlists that we will not want to change later. After a release, parameterlists are cut in stone for ABI/API compatibility reasons. Thank you, Chris P.S.: When trying to apply it with "patch", the errors are as follows: Hunk #1 succeeded at 646 (offset -1 lines). Hunk #2 succeeded at 753 (offset -1 lines). Hunk #3 succeeded at 770 (offset -1 lines). Hunk #4 succeeded at 795 (offset -1 lines). Hunk #5 succeeded at 985 (offset -1 lines). Hunk #6 succeeded at 1724 (offset -1 lines). Hunk #7 succeeded at 1805 (offset -1 lines). Hunk #8 FAILED at 1907. Hunk #9 FAILED at 1957. Hunk #10 succeeded at 2158 (offset -1 lines). Hunk #11 succeeded at 2349 (offset -1 lines). On 04/23/15 08:47, Jaya Tiwari wrote: > Signed-off-by: Jaya Tiwari > --- > src/c_client.py | 54 +++++++++++++++++++++++++++++++++++++++++------------- > 1 file changed, 41 insertions(+), 13 deletions(-) > > diff --git a/src/c_client.py b/src/c_client.py > index e55fc3c..2e3129c 100644 > --- a/src/c_client.py > +++ b/src/c_client.py > @@ -647,7 +647,7 @@ def get_expr_fields(self): > get the Fields referenced by switch or list expression > """ > def get_expr_field_names(expr): > - if expr.op is None: > + if expr.op is None or expr.op == 'calculate_len': > if expr.lenfield_name is not None: > return [expr.lenfield_name] > else: > @@ -754,6 +754,7 @@ def get_serialize_params(context, self, buffer_var='_buffer', aux_var='_aux'): > param_fields = [] > wire_fields = [] > > + dont_include_len = False > for field in self.fields: > if field.visible: > # the field should appear as a parameter in the function call > @@ -770,6 +771,8 @@ def get_serialize_params(context, self, buffer_var='_buffer', aux_var='_aux'): > if self.is_switch: > param_fields = get_expr_fields(self) > > + if self.is_list and self.type.expr.op == 'calculate_len': > + dont_include_len = True > # _serialize()/_unserialize()/_unpack() function parameters > # note: don't use set() for params, it is unsorted > params = [] > @@ -793,7 +796,7 @@ def get_serialize_params(context, self, buffer_var='_buffer', aux_var='_aux'): > pointerspec = p.c_pointer > add_param(params, (typespec, pointerspec, p.c_field_name)) > else: > - if p.visible and not p.wire and not p.auto: > + if p.visible and not p.wire and not p.auto and not dont_include_len: > typespec = p.c_field_type > pointerspec = '' > add_param(params, (typespec, pointerspec, p.c_field_name)) > @@ -983,7 +986,10 @@ def _c_serialize_helper_list_field(context, self, field, > if len(unresolved)>0: > raise Exception('could not resolve the length fields required for list %s' % field.c_field_name) > > - list_length = _c_accessor_get_expr(expr, field_mapping) > + if expr.op == 'calculate_len': > + list_length = field.type.expr.lenfield_name > + else: > + list_length = _c_accessor_get_expr(expr, field_mapping) > > # default: list with fixed size elements > length = '%s * sizeof(%s)' % (list_length, field.type.member.c_wiretype) > @@ -1719,7 +1725,7 @@ def _c_accessor_get_expr(expr, field_mapping): > return sumvar > elif expr.op == 'listelement-ref': > return '(*xcb_listelement)' > - elif expr.op != None: > + elif expr.op != None and expr.op != 'calculate_len': > return ('(' + _c_accessor_get_expr(expr.lhs, field_mapping) + > ' ' + expr.op + ' ' + > _c_accessor_get_expr(expr.rhs, field_mapping) + ')') > @@ -1800,6 +1806,7 @@ def _c_accessors_list(self, field): > > list = field.type > c_type = self.c_type > + dont_need_len = False > > # special case: switch > # in case of switch, 2 params have to be supplied to certain accessor functions: > @@ -1900,16 +1907,25 @@ def _c_accessors_list(self, field): > _hc('') > _hc('int') > spacing = ' '*(len(field.c_length_name)+2) > - add_param_str = additional_params_to_str(spacing) > + if field.type.is_list and field.type.expr.op == 'calculate_len': > + dont_need_len = True > + else: > + add_param_str = additional_params_to_str(spacing) > if switch_obj is not None: > _hc('%s (const %s *R /**< */,', field.c_length_name, R_obj.c_type) > _h('%sconst %s *S /**< */%s);', spacing, S_obj.c_type, add_param_str) > _c('%sconst %s *S /**< */%s)', spacing, S_obj.c_type, add_param_str) > - else: > + elif not dont_need_len: > _h('%s (const %s *R /**< */%s);', field.c_length_name, c_type, add_param_str) > _c('%s (const %s *R /**< */%s)', field.c_length_name, c_type, add_param_str) > + else: > + _h('%s (const %s *R /**< */);', field.c_length_name, c_type) > + _c('%s (const %s *R /**< */)', field.c_length_name, c_type) > _c('{') > - length = _c_accessor_get_expr(field.type.expr, fields) > + if field.type.expr.op == 'calculate_len': > + length = '(((R->length * 4) - sizeof('+ self.c_type + '))/'+'sizeof('+field.type.member.c_wiretype+'))' > + else: > + length = _c_accessor_get_expr(field.type.expr, fields) > _c(' return %s;', length) > _c('}') > > @@ -1950,19 +1966,26 @@ def _c_accessors_list(self, field): > _hc('') > _hc('%s', field.c_iterator_type) > spacing = ' '*(len(field.c_iterator_name)+2) > - add_param_str = additional_params_to_str(spacing) > + if field.type.expr.op != 'calculate_len': > + add_param_str = additional_params_to_str(spacing) > if switch_obj is not None: > _hc('%s (const %s *R /**< */,', field.c_iterator_name, R_obj.c_type) > _h('%sconst %s *S /**< */%s);', spacing, S_obj.c_type, add_param_str) > _c('%sconst %s *S /**< */%s)', spacing, S_obj.c_type, add_param_str) > - else: > + elif not dont_need_len: > _h('%s (const %s *R /**< */%s);', field.c_iterator_name, c_type, add_param_str) > _c('%s (const %s *R /**< */%s)', field.c_iterator_name, c_type, add_param_str) > + else: > + _h('%s (const %s *R /**< */);', field.c_iterator_name, c_type) > + _c('%s (const %s *R /**< */)', field.c_iterator_name, c_type) > _c('{') > _c(' %s i;', field.c_iterator_type) > > _c_pre.start() > - length_expr_str = _c_accessor_get_expr(field.type.expr, fields) > + if field.type.expr.op == 'calculate_len': > + length_expr_str = '(((R->length * 4) - sizeof('+ self.c_type + '))/'+'sizeof('+field.c_field_type+'))' > + else: > + length_expr_str = _c_accessor_get_expr(field.type.expr, fields) > > if switch_obj is not None: > _c_pre.end() > @@ -2152,6 +2175,7 @@ def _c_request_helper(self, name, void, regular, aux=False, reply_fds=False): > serial_fields = [] > # special case: list with variable size elements > list_with_var_size_elems = False > + have_field_len = False > > for field in self.fields: > if field.visible: > @@ -2342,9 +2366,13 @@ def _c_request_helper(self, name, void, regular, aux=False, reply_fds=False): > _c(' xcb_parts[%d].iov_base = (char *) %s;', count, field.c_field_name) > if field.type.is_list: > if field.type.member.fixed_size(): > - _c(' xcb_parts[%d].iov_len = %s * sizeof(%s);', count, > - _c_accessor_get_expr(field.type.expr, None), > - field.type.member.c_wiretype) > + if field.type.expr.op == 'calculate_len': > + lenfield = field.type.expr.lenfield_name > + else: > + lenfield = _c_accessor_get_expr(field.type.expr, None) > + > + _c(' xcb_parts[%d].iov_len = %s * sizeof(%s);', count, lenfield, > + field.type.member.c_wiretype) > else: > list_length = _c_accessor_get_expr(field.type.expr, None) > From zmike at samsung.com Thu Jun 11 11:23:00 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Thu, 11 Jun 2015 14:23:00 -0400 Subject: [Xcb] [PATCH XCB] Add reference counting support for connections Message-ID: <20150611142300.3967f3e3@Sir.Pimpleton> From: Josh Triplett Add a new xcb_reference function that adds a reference, and make xcb_disconnect do nothing until the reference count falls to 0. Commit by Josh Triplett and Jamey Sharp. Signed-off-by: Josh Triplett Signed-off-by: Jamey Sharp Signed-off-by: Mike Blumenkrantz --- src/Makefile.am | 2 +- src/xcb.h | 25 ++++++++++++++++++++----- src/xcb_conn.c | 23 +++++++++++++++++++++++ src/xcbint.h | 4 ++++ 4 files changed, 48 insertions(+), 6 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 5a3c52a..d884b95 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -18,7 +18,7 @@ nodist_libxcb_la_SOURCES = xproto.c bigreq.c xc_misc.c # * If you add an interface, increment current and age and set revision to 0. # * If you change or remove an interface, increment current and set revision # and age to 0. -libxcb_la_LDFLAGS = -version-info 2:0:1 -no-undefined @lt_enable_auto_import@ +libxcb_la_LDFLAGS = -version-info 3:0:2 -no-undefined @lt_enable_auto_import@ XCB_LIBS = libxcb.la diff --git a/src/xcb.h b/src/xcb.h index 86eb1bc..1ca70fd 100644 --- a/src/xcb.h +++ b/src/xcb.h @@ -495,7 +495,7 @@ int xcb_connection_has_error(xcb_connection_t *c); * xcb_auth_info_t @p auth_info. The file descriptor @p fd is * bidirectionally connected to an X server. If the connection * should be unauthenticated, @p auth_info must be @c - * NULL. + * NULL. The returned connection starts out with a single reference. * * Always returns a non-NULL pointer to a xcb_connection_t, even on failure. * Callers need to use xcb_connection_has_error() to check for failure. @@ -504,12 +504,23 @@ int xcb_connection_has_error(xcb_connection_t *c); */ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info); -/** - * @brief Closes the connection. + /** + * @brief Adds another reference to a connection. * @param c: The connection. * - * Closes the file descriptor and frees all memory associated with the - * connection @c c. If @p c is @c NULL, nothing is done. + * Adds a reference to the connection @p c; xcb_disconnect will not close the + * connection until it has no more outstanding references. + */ +xcb_connection_t *xcb_reference(xcb_connection_t *c); + + +/** ++ * @brief Removes a reference to a connection and closes it if it has no more references. ++ * @param c: The connection. ++ * ++ * Removes one reference to the connection @p c. If that was the last ++ * reference, closes the file descriptor and frees all memory associated ++ * with the connection @p c. If @p c is @c NULL, nothing is done. */ void xcb_disconnect(xcb_connection_t *c); @@ -551,6 +562,8 @@ int xcb_parse_display(const char *name, char **host, int *display, int *screen); * Callers need to use xcb_connection_has_error() to check for failure. * When finished, use xcb_disconnect() to close the connection and free * the structure. + * + * This function simply wraps xcb_connect_to_fd. */ xcb_connection_t *xcb_connect(const char *displayname, int *screenp); @@ -570,6 +583,8 @@ xcb_connection_t *xcb_connect(const char *displayname, int *screenp); * Callers need to use xcb_connection_has_error() to check for failure. * When finished, use xcb_disconnect() to close the connection and free * the structure. + * + * This function simply wraps xcb_connect_to_fd. */ xcb_connection_t *xcb_connect_to_display_with_auth_info(const char *display, xcb_auth_info_t *auth, int *screen); diff --git a/src/xcb_conn.c b/src/xcb_conn.c index 7d09637..98a2c54 100644 --- a/src/xcb_conn.c +++ b/src/xcb_conn.c @@ -349,9 +349,11 @@ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info) } c->fd = fd; + c->refcount = 1; if(!( set_fd_flags(fd) && + pthread_mutex_init(&c->reflock, 0) == 0 && pthread_mutex_init(&c->iolock, 0) == 0 && _xcb_in_init(&c->in) && _xcb_out_init(&c->out) && @@ -368,11 +370,30 @@ xcb_connection_t *xcb_connect_to_fd(int fd, xcb_auth_info_t *auth_info) return c; } +xcb_connection_t *xcb_reference(xcb_connection_t *c) +{ + if(c == NULL || is_static_error_conn(c)) + return c; + + pthread_mutex_lock(&c->reflock); + c->refcount++; + pthread_mutex_unlock(&c->reflock); + + return c; +} + void xcb_disconnect(xcb_connection_t *c) { if(c == NULL || is_static_error_conn(c)) return; + pthread_mutex_lock(&c->reflock); + if(--c->refcount != 0) + { + pthread_mutex_unlock(&c->reflock); + return; + } + free(c->setup); /* disallow further sends and receives */ @@ -386,6 +407,8 @@ void xcb_disconnect(xcb_connection_t *c) _xcb_ext_destroy(c); _xcb_xid_destroy(c); + pthread_mutex_unlock(&c->reflock); + pthread_mutex_destroy(&c->reflock); free(c); #ifdef _WIN32 diff --git a/src/xcbint.h b/src/xcbint.h index f89deba..aa2c32e 100644 --- a/src/xcbint.h +++ b/src/xcbint.h @@ -195,6 +195,10 @@ struct xcb_connection_t { /* This must be the first field; see _xcb_conn_ret_error(). */ int has_error; + /* reference counting */ + pthread_mutex_t reflock; + int refcount; + /* constant data */ xcb_setup_t *setup; int fd; -- 2.4.2 From zmike at samsung.com Thu Jun 11 11:24:47 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Thu, 11 Jun 2015 14:24:47 -0400 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify Message-ID: <20150611142447.55ad8dc6@Sir.Pimpleton> Commit by Josh Triplett and Jamey Sharp. Signed-off-by: Josh Triplett Signed-off-by: Jamey Sharp Signed-off-by: Mike Blumenkrantz --- src/OpenDis.c | 44 +++++++++++++++++++++++++++++++++++--------- src/Xxcbint.h | 3 +-- src/xcb_disp.c | 38 +++----------------------------------- 3 files changed, 39 insertions(+), 46 deletions(-) diff --git a/src/OpenDis.c b/src/OpenDis.c index 636860e..8f6d1ef 100644 --- a/src/OpenDis.c +++ b/src/OpenDis.c @@ -64,6 +64,7 @@ Display * XOpenDisplay ( register _Xconst char *display) { + xcb_connection_t *c; register Display *dpy; /* New Display object being created. */ register int i; int j, k; /* random iterator indexes */ @@ -110,26 +111,42 @@ XOpenDisplay ( if (_XIOErrorFunction == NULL) (void) XSetIOErrorHandler (NULL); /* + * Call the Connect routine to get the transport connection object. + * If NULL is returned, the connection failed. + */ + + c = _XConnectXCB(display, &iscreen); + if(!c || xcb_connection_has_error(c)) { + return NULL; + } + +/* * Attempt to allocate a display structure. Return NULL if allocation fails. */ - if ((dpy = Xcalloc(1, sizeof(Display))) == NULL) { - return(NULL); + if ((dpy = (Display *)Xcalloc(1, sizeof(Display) + sizeof(_X11XCBPrivate))) == NULL) { + xcb_disconnect(c); + return NULL ; } + dpy->fd = xcb_get_file_descriptor(c); + dpy->xcb = (_X11XCBPrivate *) (dpy + 1); + dpy->xcb->connection = c; + if ((dpy->display_name = strdup(display_name)) == NULL) { OutOfMemory(dpy); - return(NULL); + return NULL; } -/* - * Call the Connect routine to get the transport connection object. - * If NULL is returned, the connection failed. - */ + dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); - if(!_XConnectXCB(dpy, display, &iscreen)) { + dpy->xcb->event_notify = xcondition_malloc(); + dpy->xcb->reply_notify = xcondition_malloc(); + if (!dpy->xcb->event_notify || !dpy->xcb->reply_notify) { OutOfMemory(dpy); return NULL; } + xcondition_init(dpy->xcb->event_notify); + xcondition_init(dpy->xcb->reply_notify); /* Initialize as much of the display structure as we can. * Initialize pointers to NULL so that XFreeDisplayStructure will @@ -691,7 +708,16 @@ void _XFreeDisplayStructure(Display *dpy) Xfree (dpy->filedes); - _XFreeX11XCBStructure(dpy); + /* reply_data was allocated by system malloc, not Xmalloc */ + free(dpy->xcb->reply_data); + while(dpy->xcb->pending_requests) + { + PendingRequest *tmp = dpy->xcb->pending_requests; + dpy->xcb->pending_requests = tmp->next; + free(tmp); + } + xcondition_free(dpy->xcb->event_notify); + xcondition_free(dpy->xcb->reply_notify); Xfree (dpy); } diff --git a/src/Xxcbint.h b/src/Xxcbint.h index bf41c23..b4f8988 100644 --- a/src/Xxcbint.h +++ b/src/Xxcbint.h @@ -43,8 +43,7 @@ typedef struct _X11XCBPrivate { /* xcb_disp.c */ -int _XConnectXCB(Display *dpy, _Xconst char *display, int *screenp); -void _XFreeX11XCBStructure(Display *dpy); +xcb_connection_t *_XConnectXCB(_Xconst char *display, int *screenp); unsigned long _XNextRequest(Display *dpy); diff --git a/src/xcb_disp.c b/src/xcb_disp.c index 0fa40de..74f87c0 100644 --- a/src/xcb_disp.c +++ b/src/xcb_disp.c @@ -54,20 +54,14 @@ void XSetAuthorization(char *name, int namelen, char *data, int datalen) _XUnlockMutex(_Xglobal_lock); } -int _XConnectXCB(Display *dpy, _Xconst char *display, int *screenp) +xcb_connection_t *_XConnectXCB(_Xconst char *display, int *screenp) { char *host; int n = 0; xcb_connection_t *c; - dpy->fd = -1; - - dpy->xcb = Xcalloc(1, sizeof(_X11XCBPrivate)); - if(!dpy->xcb) - return 0; - if(!xcb_parse_display(display, &host, &n, screenp)) - return 0; + return NULL; /* host and n are unused, but xcb_parse_display requires them */ free(host); @@ -78,31 +72,5 @@ int _XConnectXCB(Display *dpy, _Xconst char *display, int *screenp) c = xcb_connect(display, NULL); _XUnlockMutex(_Xglobal_lock); - dpy->fd = xcb_get_file_descriptor(c); - - dpy->xcb->connection = c; - dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); - - dpy->xcb->event_notify = xcondition_malloc(); - dpy->xcb->reply_notify = xcondition_malloc(); - if (!dpy->xcb->event_notify || !dpy->xcb->reply_notify) - return 0; - xcondition_init(dpy->xcb->event_notify); - xcondition_init(dpy->xcb->reply_notify); - return !xcb_connection_has_error(c); -} - -void _XFreeX11XCBStructure(Display *dpy) -{ - /* reply_data was allocated by system malloc, not Xmalloc */ - free(dpy->xcb->reply_data); - while(dpy->xcb->pending_requests) - { - PendingRequest *tmp = dpy->xcb->pending_requests; - dpy->xcb->pending_requests = tmp->next; - free(tmp); - } - xcondition_free(dpy->xcb->event_notify); - xcondition_free(dpy->xcb->reply_notify); - Xfree(dpy->xcb); + return c; } -- 2.4.2 From zmike at samsung.com Thu Jun 11 11:25:21 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Thu, 11 Jun 2015 14:25:21 -0400 Subject: [Xcb] [PATCH Xlib 2/3] Improve connection error handling Message-ID: <20150611142521.761b86bf@Sir.Pimpleton> From: Josh Triplett Make _XConnectXCB translate error connections to NULL. Also, call xcb_disconnect on the error path. Commit by Josh Triplett and Jamey Sharp. Signed-off-by: Josh Triplett Signed-off-by: Jamey Sharp Signed-off-by: Mike Blumenkrantz --- src/OpenDis.c | 3 +-- src/xcb_disp.c | 4 ++++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/OpenDis.c b/src/OpenDis.c index 8f6d1ef..509060e 100644 --- a/src/OpenDis.c +++ b/src/OpenDis.c @@ -115,8 +115,7 @@ XOpenDisplay ( * If NULL is returned, the connection failed. */ - c = _XConnectXCB(display, &iscreen); - if(!c || xcb_connection_has_error(c)) { + if(!(c = _XConnectXCB(display, &iscreen))) { return NULL; } diff --git a/src/xcb_disp.c b/src/xcb_disp.c index 74f87c0..9ff650e 100644 --- a/src/xcb_disp.c +++ b/src/xcb_disp.c @@ -72,5 +72,9 @@ xcb_connection_t *_XConnectXCB(_Xconst char *display, int *screenp) c = xcb_connect(display, NULL); _XUnlockMutex(_Xglobal_lock); + if(xcb_connection_has_error(c)) { + xcb_disconnect(c); + return NULL; + } return c; } -- 2.4.2 From zmike at samsung.com Thu Jun 11 11:26:13 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Thu, 11 Jun 2015 14:26:13 -0400 Subject: [Xcb] [PATCH Xlib 3/3] Add XOpenXCBConnection() to create a Display object from xcb_connection Message-ID: <20150611142613.0219b18f@Sir.Pimpleton> also use xcb reference counting underneath Display connection functions to ensure matching connection object lifetimes Commit by Josh Triplett and Jamey Sharp. Signed-off-by: Josh Triplett Signed-off-by: Jamey Sharp Signed-off-by: Mike Blumenkrantz --- include/X11/Xlib-xcb.h | 1 + man/Makefile.am | 1 + man/XOpenDisplay.man | 10 +++- man/XOpenXCBConnection.man | 40 +++++++++++++ src/ClDisplay.c | 8 +++ src/OpenDis.c | 144 ++++++++++++++++++++++++++++++++------------- src/Xxcbint.h | 3 + 7 files changed, 163 insertions(+), 44 deletions(-) create mode 100644 man/XOpenXCBConnection.man diff --git a/include/X11/Xlib-xcb.h b/include/X11/Xlib-xcb.h index a21e2be..0ee8b47 100644 --- a/include/X11/Xlib-xcb.h +++ b/include/X11/Xlib-xcb.h @@ -11,6 +11,7 @@ _XFUNCPROTOBEGIN xcb_connection_t *XGetXCBConnection(Display *dpy); +Display *XOpenXCBConnection(xcb_connection_t *c); enum XEventQueueOwner { XlibOwnsEventQueue = 0, XCBOwnsEventQueue }; void XSetEventQueueOwner(Display *dpy, enum XEventQueueOwner owner); diff --git a/man/Makefile.am b/man/Makefile.am index ef1a745..ad54c93 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -118,6 +118,7 @@ libman_PRE = \ XNextEvent.man \ XNoOp.man \ XOpenDisplay.man \ + XOpenXCBConnection.man \ XOpenIM.man \ XOpenOM.man \ XParseGeometry.man \ diff --git a/man/XOpenDisplay.man b/man/XOpenDisplay.man index 30859b2..07abd38 100644 --- a/man/XOpenDisplay.man +++ b/man/XOpenDisplay.man @@ -131,7 +131,8 @@ returns a pointer to a .ZN Display structure, which is defined in -.hN X11/Xlib.h . +.hN X11/Xlib.h . The underlying connection object is reference counted, +and it will have a count of 1 upon returning from this call. If .ZN XOpenDisplay does not succeed, it returns NULL. @@ -157,7 +158,8 @@ see section 2.2.1. .LP The .ZN XCloseDisplay -function closes the connection to the X server for the display specified in the +function decrements the reference count of the underlying connection. +If the count reaches 0 it closes the connection to the X server for the display specified in the .ZN Display structure and destroys all windows, resource IDs .Pn ( Window , @@ -171,7 +173,9 @@ or other resources that the client has created on this display, unless the close-down mode of the resource has been changed (see .ZN XSetCloseDownMode ). -Therefore, these windows, resource IDs, and other resources should never be +Therefore, if +.ZN XCloseDisplay +returns 0 these windows, resource IDs, and other resources should never be referenced again or an error will be generated. Before exiting, you should call .ZN XCloseDisplay diff --git a/man/XOpenXCBConnection.man b/man/XOpenXCBConnection.man new file mode 100644 index 0000000..bbb9fc5 --- /dev/null +++ b/man/XOpenXCBConnection.man @@ -0,0 +1,40 @@ +.\" Copyright \(co 2010 Josh Triplett, Jamey Sharp +.\" +.\" Permission is hereby granted, free of charge, to any person obtaining +.\" a copy of this software and associated documentation files (the +.\" "Software"), to deal in the Software without restriction, including +.\" without limitation the rights to use, copy, modify, merge, publish, +.\" distribute, sublicense, and/or sell copies of the Software, and to +.\" permit persons to whom the Software is furnished to do so, subject to +.\" the following conditions: +.\" +.\" The above copyright notice and this permission notice shall be included +.\" in all copies or substantial portions of the Software. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS +.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. +.\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR +.\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +.\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +.\" OTHER DEALINGS IN THE SOFTWARE. +.\" +.TH XGetXCBConnection __libmansuffix__ __xorgversion__ "XLIB FUNCTIONS" +.SH NAME +XOpenXCBConnection \- create an Xlib Display for an existing XCB connection +.SH SYNTAX +.HP +#include +.HP +Display *XOpenXCBConnection(xcb_connection_t *\fIc\fP); +.SH ARGUMENTS +.IP \fIc\fP 1i +Specifies the xcb_connection_t to open a Display for. +.SH DESCRIPTION +The \fIXOpenXCBConnection\fP function returns the Xlib Display associated with +an XCB connection, creating that Display if none exists. The connection object +is reference counted and will only be deleted when all references are removed. +.SH "SEE ALSO" +XOpenDisplay(__libmansuffix__), +.br +\fIXlib \- C Language X Interface\fP diff --git a/src/ClDisplay.c b/src/ClDisplay.c index bddd773..3ad2d89 100644 --- a/src/ClDisplay.c +++ b/src/ClDisplay.c @@ -48,6 +48,12 @@ XCloseDisplay ( register _XExtension *ext; register int i; + if (dpy->xcb->refcount > 1) { + _XLockMutex(_Xglobal_lock); + dpy->xcb->refcount--; + _XUnlockMutex(_Xglobal_lock); + return 1; + } if (!(dpy->flags & XlibDisplayClosing)) { dpy->flags |= XlibDisplayClosing; @@ -69,6 +75,8 @@ XCloseDisplay ( XSync(dpy, 1); } xcb_disconnect(dpy->xcb->connection); + _XLockMutex(_Xglobal_lock); _XFreeDisplayStructure (dpy); + _XUnlockMutex(_Xglobal_lock); return 0; } diff --git a/src/OpenDis.c b/src/OpenDis.c index 509060e..d62cf14 100644 --- a/src/OpenDis.c +++ b/src/OpenDis.c @@ -54,6 +54,8 @@ static xReq _dummy_request = { 0, 0, 0 }; +static Display *dpy_head; + static void OutOfMemory(Display *dpy); /* @@ -66,11 +68,59 @@ XOpenDisplay ( { xcb_connection_t *c; register Display *dpy; /* New Display object being created. */ + char *display_name; /* pointer to display name */ + int iscreen; /* screen number */ + /* + * If the display specifier string supplied as an argument to this + * routine is NULL or a pointer to NULL, read the DISPLAY variable. + */ + if (display == NULL || *display == '\0') { + if ((display_name = getenv("DISPLAY")) == NULL) { + /* Oops! No DISPLAY environment variable - error. */ + return(NULL); + } + } + else { + /* Display is non-NULL, copy the pointer */ + display_name = (char *)display; + } + +/* + * Call the Connect routine to get the transport connection object. + * If NULL is returned, the connection failed. + */ + if(!(c = _XConnectXCB(display, &iscreen))) { + return NULL; + } + + dpy = XOpenXCBConnection(c); + /* Drop the reference taken by XOpenXCBConnection; Xlib owns this + * connection. */ + xcb_disconnect(c); + + if ((dpy->display_name = strdup(display_name)) == NULL) { + OutOfMemory(dpy); + return(NULL); + } + +/* + * Make sure default screen is legal. + */ + dpy->default_screen = iscreen; /* Value returned by ConnectDisplay */ + if (iscreen >= dpy->nscreens) { + OutOfMemory(dpy); + return(NULL); + } + + return dpy; +} + +static Display *_XOpenXCBConnection(xcb_connection_t *c) +{ + Display *dpy; /* New Display object being created. */ register int i; int j, k; /* random iterator indexes */ - char *display_name; /* pointer to display name */ char *setup = NULL; /* memory allocated at startup */ - int iscreen; /* screen number */ xConnSetupPrefix prefix; /* prefix information */ int vendorlen; /* length of vendor string */ union { @@ -86,22 +136,13 @@ XOpenDisplay ( long usedbytes = 0; /* number of bytes we have processed */ unsigned long mask; long int conn_buf_size; - char *xlib_buffer_size; + char *xlib_buffer_size, *display_name; - /* - * If the display specifier string supplied as an argument to this - * routine is NULL or a pointer to NULL, read the DISPLAY variable. - */ - if (display == NULL || *display == '\0') { - if ((display_name = getenv("DISPLAY")) == NULL) { - /* Oops! No DISPLAY environment variable - error. */ - return(NULL); - } - } - else { - /* Display is non-NULL, copy the pointer */ - display_name = (char *)display; - } + for (dpy = dpy_head; dpy; dpy = dpy->xcb->dpy_next) + if (dpy->xcb->connection == c) + return dpy; + + xcb_reference(c); /* * Set the default error handlers. This allows the global variables to @@ -111,15 +152,6 @@ XOpenDisplay ( if (_XIOErrorFunction == NULL) (void) XSetIOErrorHandler (NULL); /* - * Call the Connect routine to get the transport connection object. - * If NULL is returned, the connection failed. - */ - - if(!(c = _XConnectXCB(display, &iscreen))) { - return NULL; - } - -/* * Attempt to allocate a display structure. Return NULL if allocation fails. */ if ((dpy = (Display *)Xcalloc(1, sizeof(Display) + sizeof(_X11XCBPrivate))) == NULL) { @@ -130,12 +162,6 @@ XOpenDisplay ( dpy->fd = xcb_get_file_descriptor(c); dpy->xcb = (_X11XCBPrivate *) (dpy + 1); dpy->xcb->connection = c; - - if ((dpy->display_name = strdup(display_name)) == NULL) { - OutOfMemory(dpy); - return NULL; - } - dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); dpy->xcb->event_notify = xcondition_malloc(); @@ -147,6 +173,19 @@ XOpenDisplay ( xcondition_init(dpy->xcb->event_notify); xcondition_init(dpy->xcb->reply_notify); + /* Not necessarily correct, but this can only go wrong if opening an + * xcb_connection_t using a display_name other than $DISPLAY, *and* + * using XOpenXCBConnection rather than XOpenDisplay, *and* then + * attempting to reconnect to dpy->display_name. */ + display_name = getenv("DISPLAY"); + if (display_name != NULL) { + dpy->display_name = strdup(display_name); + if (!dpy->display_name) { + OutOfMemory(dpy); + return NULL; + } + } + /* Initialize as much of the display structure as we can. * Initialize pointers to NULL so that XFreeDisplayStructure will * work if we run out of memory before we finish initializing. @@ -215,7 +254,6 @@ XOpenDisplay ( dpy->savedsynchandler = NULL; dpy->request = 0; dpy->last_request_read = 0; - dpy->default_screen = iscreen; /* Value returned by ConnectDisplay */ dpy->last_req = (char *)&_dummy_request; /* Initialize the display lock */ @@ -501,14 +539,6 @@ XOpenDisplay ( */ /* - * Make sure default screen is legal. - */ - if (iscreen >= dpy->nscreens) { - OutOfMemory(dpy); - return(NULL); - } - -/* * get availability of large requests */ dpy->bigreq_size = xcb_get_maximum_request_length(dpy->xcb->connection); @@ -575,12 +605,37 @@ XOpenDisplay ( #ifdef XKB XkbUseExtension(dpy,NULL,NULL); #endif + + dpy->xcb->dpy_next = dpy_head; + dpy_head = dpy; + /* * and return successfully */ return(dpy); } +/* + * Construct a Display from an existing xcb_connection_t. + */ +Display *XOpenXCBConnection(xcb_connection_t *c) +{ + Display *dpy; +/* + * Set the default error handlers here to prevent deadlocks later. + * This allows the global variables to default to NULL for use with shared libraries. + */ + if (_XErrorFunction == NULL) (void) XSetErrorHandler (NULL); + if (_XIOErrorFunction == NULL) (void) XSetIOErrorHandler (NULL); + _XLockMutex(_Xglobal_lock); + dpy = _XOpenXCBConnection(c); + if (dpy) + dpy->xcb->refcount++; + _XUnlockMutex(_Xglobal_lock); + return dpy; +} + + /* XFreeDisplayStructure frees all the storage associated with a * Display. It is used by XOpenDisplay if it runs out of memory, * and also by XCloseDisplay. It needs to check whether all pointers @@ -592,6 +647,13 @@ XOpenDisplay ( void _XFreeDisplayStructure(Display *dpy) { + Display **dpy_cur; + for (dpy_cur = &dpy_head; *dpy_cur; dpy_cur = &(*dpy_cur)->xcb->dpy_next) + if (*dpy_cur == dpy) { + *dpy_cur = dpy->xcb->dpy_next; + break; + } + /* move all cookies in the EQ to the jar, then free them. */ if (dpy->qfree) { _XQEvent *qelt = dpy->qfree; diff --git a/src/Xxcbint.h b/src/Xxcbint.h index b4f8988..f0a9e6a 100644 --- a/src/Xxcbint.h +++ b/src/Xxcbint.h @@ -39,6 +39,9 @@ typedef struct _X11XCBPrivate { xcondition_t event_notify; int event_waiter; xcondition_t reply_notify; + + int refcount; + Display *dpy_next; } _X11XCBPrivate; /* xcb_disp.c */ -- 2.4.2 From alan.coopersmith at oracle.com Thu Jun 11 12:37:10 2015 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Thu, 11 Jun 2015 12:37:10 -0700 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify In-Reply-To: <20150611142447.55ad8dc6@Sir.Pimpleton> References: <20150611142447.55ad8dc6@Sir.Pimpleton> Message-ID: <5579E366.3070901@oracle.com> On 06/11/15 11:24 AM, Mike Blumenkrantz wrote: > Commit by Josh Triplett and Jamey Sharp. Why is this useful? It would really help if the commit comment had explanation, as suggested in http://who-t.blogspot.com/2009/12/on-commit-messages.html - otherwise it's a hard to review code dump, which for X, probably means it goes nowhere, as we don't have enough reviewers to reverse engineer code changes. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc From zmike at samsung.com Thu Jun 11 13:54:36 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Thu, 11 Jun 2015 16:54:36 -0400 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify In-Reply-To: <5579E366.3070901@oracle.com> References: <20150611142447.55ad8dc6@Sir.Pimpleton> <5579E366.3070901@oracle.com> Message-ID: <20150611165436.6f039e82@Sir.Pimpleton> On Thu, 11 Jun 2015 12:37:10 -0700 Alan Coopersmith wrote: > On 06/11/15 11:24 AM, Mike Blumenkrantz wrote: > > Commit by Josh Triplett and Jamey Sharp. > > Why is this useful? It would really help if the commit comment had > explanation, as suggested in > http://who-t.blogspot.com/2009/12/on-commit-messages.html - otherwise > it's a hard to review code dump, which for X, probably means it goes > nowhere, as we don't have enough reviewers to reverse engineer code > changes. > This is a prep commit for the function added later in the series. It refactors the code to reduce duplication later on when there are two functions which will be using the same code paths. From peter.hutterer at who-t.net Thu Jun 11 21:15:29 2015 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 12 Jun 2015 14:15:29 +1000 Subject: [Xcb] [PATCH proto] xinput: align XIChangeProperty data items correctly Message-ID: <20150612041529.GA14101@jelly.redhat.com> Items need to be 4-aligned, see also 055c13096d94953de9ca62017f917572bd0e3f56 Signed-off-by: Peter Hutterer --- src/xinput.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/xinput.xml b/src/xinput.xml index c729f20..6564f4c 100644 --- a/src/xinput.xml +++ b/src/xinput.xml @@ -1985,12 +1985,14 @@ This affects the following: num_items + 16Bits num_items + 32Bits -- 2.4.0 From psychon at znc.in Fri Jun 12 00:46:27 2015 From: psychon at znc.in (Uli Schlachter) Date: Fri, 12 Jun 2015 09:46:27 +0200 Subject: [Xcb] [PATCH v2 libxcb] Call _xcb_wake_up_next_reader from xcb_wait_for_special_event In-Reply-To: <1433124258-20421-1-git-send-email-michel@daenzer.net> References: <5569AA2F.1040600@znc.in> <1433124258-20421-1-git-send-email-michel@daenzer.net> Message-ID: <557A8E53.1080606@znc.in> Pushed as commit f85661c3bca97fa. Cheers, Uli Am 01.06.2015 um 04:04 schrieb Michel Dänzer: > From: Michel Dänzer > > All functions calling _xcb_conn_wait() must make sure that waiting > readers are woken up when we read a reply or event that they are waiting > for. xcb_wait_for_special_event() did not do so. This adds the missing > call to_xcb_in_wake_up_next_reader(). > > Fixes deadlock when waiting for a special event and concurrently > processing the display connection queue in another thread. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252 > Tested-by: Thomas Daede > Tested-by: Clément Guérin > Reviewed-by: Uli Schlachter > Signed-off-by: Michel Dänzer > --- > > Uli (or anyone), can you push this for me? Thanks. > > src/xcb_in.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/xcb_in.c b/src/xcb_in.c > index 623a0a8..322bed8 100644 > --- a/src/xcb_in.c > +++ b/src/xcb_in.c > @@ -761,6 +761,7 @@ xcb_generic_event_t *xcb_wait_for_special_event(xcb_connection_t *c, > if(!_xcb_conn_wait(c, &se->special_event_cond, 0, 0)) > break; > > + _xcb_in_wake_up_next_reader(c); > pthread_mutex_unlock(&c->iolock); > return event; > } > -- Homophobia - The fear that another man will treat you the way you treat women. From psychon at znc.in Fri Jun 12 00:47:16 2015 From: psychon at znc.in (Uli Schlachter) Date: Fri, 12 Jun 2015 09:47:16 +0200 Subject: [Xcb] [PATCH libxcb v3 1/5] xcb_send_fd(): Always close fds In-Reply-To: <5564D053.2070106@znc.in> References: <5564D053.2070106@znc.in> Message-ID: <557A8E84.4040905@znc.in> Since no one complained, I just pushed this whole series. Uli Am 26.05.2015 um 21:58 schrieb Uli Schlachter: > The API docs for xcb_send_fd() says "After this function returns, the file > descriptor given is owned by xcb and will be closed eventually". > > Let the implementation live up to its documentation. We now also close fds if fd > passing is unavailable (!HAVE_SENDMSG) and when the connection is in an error > state. > > (This also does sneak in some preparatory functions for follow-up commits and > thus does things in a more complicated way than really necessary.) > > Signed-off-by: Uli Schlachter > --- > src/xcb_out.c | 44 ++++++++++++++++++++++++++++++++++---------- > 1 file changed, 34 insertions(+), 10 deletions(-) > > diff --git a/src/xcb_out.c b/src/xcb_out.c > index 8cc5be8..722463e 100644 > --- a/src/xcb_out.c > +++ b/src/xcb_out.c > @@ -177,6 +177,34 @@ uint32_t xcb_get_maximum_request_length(xcb_connection_t *c) > return c->out.maximum_request_length.value; > } > > +static void close_fds(int *fds, unsigned int num_fds) > +{ > + for (unsigned int index = 0; index < num_fds; index++) > + close(fds[index]); > +} > + > +static void send_fds(xcb_connection_t *c, int *fds, unsigned int num_fds) > +{ > +#if HAVE_SENDMSG > + while (num_fds > 0) { > + /* FIXME: This will busy-loop when XCB_MAX_PASS_FD fds are sent at once */ > + while (c->out.out_fd.nfd == XCB_MAX_PASS_FD && !c->has_error) { > + /* XXX: if c->out.writing > 0, this releases the iolock and > + * potentially allows other threads to interfere with their own fds. > + */ > + _xcb_out_flush_to(c, c->out.request); > + } > + if (c->has_error) > + break; > + > + c->out.out_fd.fd[c->out.out_fd.nfd++] = fds[0]; > + fds++; > + num_fds--; > + } > +#endif > + close_fds(fds, num_fds); > +} > + > uint64_t xcb_send_request64(xcb_connection_t *c, int flags, struct iovec *vector, const xcb_protocol_request_t *req) > { > uint64_t request; > @@ -295,19 +323,15 @@ unsigned int xcb_send_request(xcb_connection_t *c, int flags, struct iovec *vect > void > xcb_send_fd(xcb_connection_t *c, int fd) > { > -#if HAVE_SENDMSG > - if (c->has_error) > + int fds[1] = { fd }; > + > + if (c->has_error) { > + close(fd); > return; > - pthread_mutex_lock(&c->iolock); > - while (c->out.out_fd.nfd == XCB_MAX_PASS_FD) { > - _xcb_out_flush_to(c, c->out.request); > - if (c->has_error) > - break; > } > - if (!c->has_error) > - c->out.out_fd.fd[c->out.out_fd.nfd++] = fd; > + pthread_mutex_lock(&c->iolock); > + send_fds(c, &fds[0], 1); > pthread_mutex_unlock(&c->iolock); > -#endif > } > > int xcb_take_socket(xcb_connection_t *c, void (*return_socket)(void *closure), void *closure, int flags, uint64_t *sent) > -- Homophobia - The fear that another man will treat you the way you treat women. From bugzilla-daemon at freedesktop.org Fri Jun 12 00:55:27 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 12 Jun 2015 07:55:27 +0000 Subject: [Xcb] [Bug 84252] DRI3 rendering gets stuck waiting for present idle notify event In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=84252 --- Comment #52 from Uli Schlachter --- Part of the patch was pushed: commit f85661c3bca97faa72431df92a3867be39a74e23 Author: Michel Dänzer Date: Mon Jun 1 11:04:18 2015 +0900 Call _xcb_wake_up_next_reader from xcb_wait_for_special_event All functions calling _xcb_conn_wait() must make sure that waiting readers are woken up when we read a reply or event that they are waiting for. xcb_wait_for_special_event() did not do so. This adds the missing call to_xcb_in_wake_up_next_reader(). Fixes deadlock when waiting for a special event and concurrently processing the display connection queue in another thread. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252 Tested-by: Thomas Daede Tested-by: Clément Guérin Reviewed-by: Uli Schlachter Signed-off-by: Michel Dänzer Signed-off-by: Uli Schlachter diff --git a/src/xcb_in.c b/src/xcb_in.c index 623a0a8..322bed8 100644 --- a/src/xcb_in.c +++ b/src/xcb_in.c @@ -761,6 +761,7 @@ xcb_generic_event_t *xcb_wait_for_special_event(xcb_connection_t *c, if(!_xcb_conn_wait(c, &se->special_event_cond, 0, 0)) break; + _xcb_in_wake_up_next_reader(c); pthread_mutex_unlock(&c->iolock); return event; } -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at DemoRecorder.com Fri Jun 12 01:25:38 2015 From: chris at DemoRecorder.com (Christian Linhart) Date: Fri, 12 Jun 2015 10:25:38 +0200 Subject: [Xcb] [PATCH proto] xinput: align XIChangeProperty data items correctly In-Reply-To: <20150612041529.GA14101@jelly.redhat.com> References: <20150612041529.GA14101@jelly.redhat.com> Message-ID: <557A9782.9070608@DemoRecorder.com> Hi Peter, These aligns will be put at the end of the XIChangeProperty request because the "case" branches are mutually exclusive. In that sense it differs from 055c13096d94953de9ca62017f917572bd0e3f56 where bitcase is used. But it is a good idea anyways to have proper alignment at the end of protocol entities. This will be especially important when we'll do automatic verification of protocol definitions. Therefore: Reviewed-by: Christian Linhart Cheers, Chris On 06/12/15 06:15, Peter Hutterer wrote: > Items need to be 4-aligned, see also 055c13096d94953de9ca62017f917572bd0e3f56 > > Signed-off-by: Peter Hutterer > --- > src/xinput.xml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/xinput.xml b/src/xinput.xml > index c729f20..6564f4c 100644 > --- a/src/xinput.xml > +++ b/src/xinput.xml > @@ -1985,12 +1985,14 @@ This affects the following: > > num_items > > + > > > 16Bits > > num_items > > + > > > 32Bits From chris at demorecorder.com Fri Jun 12 02:48:00 2015 From: chris at demorecorder.com (Christian Linhart) Date: Fri, 12 Jun 2015 11:48:00 +0200 Subject: [Xcb] [PATCH libxcb 1/1] Fix for alignment bug when xcb_align_to is 0 Message-ID: <1434102480-53563-1-git-send-email-chris@demorecorder.com> The aligment code in xcb looks like: xcb_pad = -(xcb_block_len + xcb_padding_offset) & (xcb_align_to - 1); if xcb_align_to == 0, then (xcb_align_to - 1) evaluates to INT_MAX. This causes alignments which may become too large. xcb_align_to can become 0 in certain cases. Actually, it is often initialized to 0. This patch fixes that by adding an "if" which causes alignment computations only for xcb_align > 1. We also exclude 1 because aligment 1 is a NOP. Therefore this fix improves performance, too. Thanks to Peter Hutterer for pointing out this problem to me. BTW, long term we should remove the implicit padding altogether. This was already consensus on the list, but it is significant work to ensure correctness. So it is postponed for now. Signed-off-by: Christian Linhart --- src/c_client.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/c_client.py b/src/c_client.py index 70f8429..eca18c8 100644 --- a/src/c_client.py +++ b/src/c_client.py @@ -814,22 +814,28 @@ def get_serialize_params(context, self, buffer_var='_buffer', aux_var='_aux'): if not p.type.fixed_size(): add_param(params, (p.c_field_const_type, '*', p.c_field_name)) return (param_fields, wire_fields, params) def _c_serialize_helper_insert_padding(context, code_lines, space, postpone, is_case_or_bitcase): code_lines.append('%s /* insert padding */' % space) + code_lines.append('%s if (xcb_align_to > 1) {' % space) if is_case_or_bitcase: code_lines.append( - '%s xcb_pad = -(xcb_block_len + xcb_padding_offset) & (xcb_align_to - 1);' + '%s xcb_pad = -(xcb_block_len + xcb_padding_offset) & (xcb_align_to - 1);' % space) else: code_lines.append( - '%s xcb_pad = -xcb_block_len & (xcb_align_to - 1);' % space) - code_lines.append('%s xcb_buffer_len += xcb_block_len + xcb_pad;' % space) + '%s xcb_pad = -xcb_block_len & (xcb_align_to - 1);' % space) + code_lines.append('%s xcb_buffer_len += xcb_block_len + xcb_pad;' % space) + code_lines.append('%s }' % space) + code_lines.append('%s else {' % space) + code_lines.append('%s xcb_pad = 0;' % space) + code_lines.append('%s xcb_buffer_len += xcb_block_len;' % space) + code_lines.append('%s }' % space) if not postpone: code_lines.append('%s if (0 != xcb_pad) {' % space) if 'serialize' == context: code_lines.append('%s xcb_parts[xcb_parts_idx].iov_base = xcb_pad0;' % space) code_lines.append('%s xcb_parts[xcb_parts_idx].iov_len = xcb_pad;' % space) -- 2.0.1 From chris at DemoRecorder.com Fri Jun 12 04:06:01 2015 From: chris at DemoRecorder.com (Christian Linhart) Date: Fri, 12 Jun 2015 13:06:01 +0200 Subject: [Xcb] Proposal: solution for alignment problem from using pointer addresses Message-ID: <557ABD19.7070301@DemoRecorder.com> Some time ago, I have implemented a compromise for implementing alignment in structs or switches which start at positions that start with an offset to alignment. That compromise uses the pointer address for finding out the alignment offset. see: http://cgit.freedesktop.org/xcb/libxcb/commit/?id=a7c75be5b1e2da32f7ce2c255972178e7d4b7598 The generally agreed assumption was that pointer addresses only come from properly aligned data such as read buffer for the display connection. It turned out that the assumption was false: In some cases the pointer addresses come from user-code, i.e., they are essentially random. Thanks to Peter Hutterer for pointing that out. So, we need another solution that does not require ABI/API changes. Here's what I propose: * Let the generator compute the initial alignment-offset for constructs. See for example the switch in in xinput.xml. It is possible to do such computations, but it is not entirely trivial. * Make the initial alignment-offset of a struct explicit in the XML for those structs that start with an alignment offset. (I don't have an example at hand but these kind of structs do exist somewhere as far as I know.) This solution will work under the condition that each specific struct or switch is used consistently with the same alignment offset everywhere. (Which is a good idea anyways.) Here's how this will look like for structs:: ... This means that struct Foo will start with a 2-byte offset with respect to 4-byte alignment. Default will be 0-byte offset with respect to 4-byte alignment. So, most of the XML does not need to be changed. For , no change in the xml will be necessary. What do you think about that? Chris From bugzilla-daemon at freedesktop.org Fri Jun 12 06:12:10 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 12 Jun 2015 13:12:10 +0000 Subject: [Xcb] [Bug 84252] DRI3 rendering gets stuck waiting for present idle notify event In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=84252 Uli Schlachter changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |psychon at znc.in --- Comment #53 from Uli Schlachter --- Created attachment 116462 --> https://bugs.freedesktop.org/attachment.cgi?id=116462&action=edit Another test that runs into a different, but quite similar hang -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psychon at znc.in Fri Jun 12 06:21:42 2015 From: psychon at znc.in (Uli Schlachter) Date: Fri, 12 Jun 2015 15:21:42 +0200 Subject: [Xcb] [PATCH] Fix a thread hang with xcb_wait_for_special_event() Message-ID: <557ADCE6.2050909@znc.in> Consider the following: - Two threads are calling xcb_wait_for_special_event() and xcb_wait_for_reply() concurrently. - The thread doing xcb_wait_for_reply() wins the race and poll()s the socket for readability. - The other thread will be put to sleep on the special_event_cond of the special event (this is done in _xcb_conn_wait() via the argument xcb_wait_for_special_event() gives it). - The first thread gets its reply, but does not yet receive any special event. In this case, the first thread will return to its caller. On its way out, it will call _xcb_in_wake_up_next_reader(), but that function cannot wake up anything since so far it did not handle xcb_wait_for_special_event(). Thus, the first thread stays blocked on the condition variable and no thread tries to read from the socket. A test case demonstrating this problem is available at the bug report. Fix this similar to how we handle this with xcb_wait_for_reply(): The function wait_for_reply() adds an entry into a linked list of threads that wait for a reply. Via this list, _xcb_in_wake_up_next_reader() can wake up this thread so that it can call _xcb_conn_wait() again and then poll()s the socket. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252 Signed-off-by: Uli Schlachter --- Michel, could you try if the test case at [0] also hangs for you and if this patch fixes both your original problem and this test? Thanks. [0]: https://bugs.freedesktop.org/attachment.cgi?id=116462&action=edit src/xcb_in.c | 32 ++++++++++++++++++++++++++++++++ src/xcbint.h | 1 + 2 files changed, 33 insertions(+) diff --git a/src/xcb_in.c b/src/xcb_in.c index 322bed8..bab4bc7 100644 --- a/src/xcb_in.c +++ b/src/xcb_in.c @@ -97,6 +97,11 @@ typedef struct reader_list { struct reader_list *next; } reader_list; +typedef struct special_list { + xcb_special_event_t *se; + struct special_list *next; +} special_list; + static void remove_finished_readers(reader_list **prev_reader, uint64_t completed) { while(*prev_reader && XCB_SEQUENCE_COMPARE((*prev_reader)->request, <=, completed)) @@ -475,6 +480,26 @@ static void remove_reader(reader_list **prev_reader, reader_list *reader) } } +static void insert_special(special_list **prev_special, special_list *special, xcb_special_event_t *se) +{ + special->se = se; + special->next = *prev_special; + *prev_special = special; +} + +static void remove_special(special_list **prev_special, special_list *special) +{ + while(*prev_special) + { + if(*prev_special == special) + { + *prev_special = (*prev_special)->next; + break; + } + prev_special = &(*prev_special)->next; + } +} + static void *wait_for_reply(xcb_connection_t *c, uint64_t request, xcb_generic_error_t **e) { void *ret = 0; @@ -750,17 +775,22 @@ xcb_generic_event_t *xcb_poll_for_special_event(xcb_connection_t *c, xcb_generic_event_t *xcb_wait_for_special_event(xcb_connection_t *c, xcb_special_event_t *se) { + special_list special; xcb_generic_event_t *event; if(c->has_error) return 0; pthread_mutex_lock(&c->iolock); + insert_special(&c->in.special_waiters, &special, se); + /* get_special_event returns 0 on empty list. */ while(!(event = get_special_event(c, se))) if(!_xcb_conn_wait(c, &se->special_event_cond, 0, 0)) break; + remove_special(&c->in.special_waiters, &special); + _xcb_in_wake_up_next_reader(c); pthread_mutex_unlock(&c->iolock); return event; @@ -889,6 +919,8 @@ void _xcb_in_wake_up_next_reader(xcb_connection_t *c) int pthreadret; if(c->in.readers) pthreadret = pthread_cond_signal(c->in.readers->data); + else if(c->in.special_waiters) + pthreadret = pthread_cond_signal(&c->in.special_waiters->se->special_event_cond); else pthreadret = pthread_cond_signal(&c->in.event_cond); assert(pthreadret == 0); diff --git a/src/xcbint.h b/src/xcbint.h index f89deba..acce646 100644 --- a/src/xcbint.h +++ b/src/xcbint.h @@ -142,6 +142,7 @@ typedef struct _xcb_in { struct event_list *events; struct event_list **events_tail; struct reader_list *readers; + struct special_list *special_waiters; struct pending_reply *pending_replies; struct pending_reply **pending_replies_tail; -- 2.1.4 From bugzilla-daemon at freedesktop.org Fri Jun 12 06:24:42 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 12 Jun 2015 13:24:42 +0000 Subject: [Xcb] [Bug 84252] DRI3 rendering gets stuck waiting for present idle notify event In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=84252 --- Comment #54 from Uli Schlachter --- Created attachment 116463 --> https://bugs.freedesktop.org/attachment.cgi?id=116463&action=edit Make _xcb_in_wake_up_next_reader() wake up threads in xcb_wait_for_special_event() Can someone check if this patch for libxcb also fixes the bug? This replaces half of Michel's patch, so you would still need this part from that other patch (this part is already committed to libxcb's git master, so you could also just test master + this patch): diff --git a/src/xcb_in.c b/src/xcb_in.c index 623a0a8..2ce5a56 100644 --- a/src/xcb_in.c +++ b/src/xcb_in.c @@ -761,6 +761,7 @@ xcb_generic_event_t *xcb_wait_for_special_event(xcb_connection_t *c, if(!_xcb_conn_wait(c, &se->special_event_cond, 0, 0)) break; + _xcb_in_wake_up_next_reader(c); pthread_mutex_unlock(&c->iolock); return event; } Thanks for testing -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at daenzer.net Sun Jun 14 23:29:45 2015 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Mon, 15 Jun 2015 15:29:45 +0900 Subject: [Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader In-Reply-To: <5579BC3A.7060504@znc.in> References: <1432543801-31649-2-git-send-email-michel@daenzer.net> <1432543974-1005-1-git-send-email-michel@daenzer.net> <5569AB77.7080600@znc.in> <556BBEE5.3000204@daenzer.net> <5577E80F.6050601@znc.in> <55780ADB.3020706@daenzer.net> <557817F2.7080802@znc.in> <55792291.4080807@daenzer.net> <5579BC3A.7060504@znc.in> Message-ID: <557E70D9.70906@daenzer.net> On 12.06.2015 01:50, Uli Schlachter wrote: > Am 11.06.2015 um 07:54 schrieb Michel Dänzer: > [...] >>>> As described in the commit log, the test case for this patch is a >>>> different one: The Mesa demos program called glthreads, which creates >>>> several threads rendering with OpenGL (to one separate window each) >>>> concurrently. >>>> >>>> The problem fixed by this patch is that glthreads often hangs when >>>> trying to quit by pressing the Escape key. >>> >>> Is there any easy way to get glthreads on debian that doesn't involve building >>> something "big" like all of mesa? >> >> git clone git://anongit.freedesktop.org/mesa/demos >> cd demos >> ./autogen.sh >> make -C src/xdemos glthreads > > Thanks, that was indeed relatively easy (and only required 7MiB of additional > packages). > > Sadly, I cannot reproduce this hang, but I can easily reproduce the Xlib problem > of "only progresses when an event is received" / "XNextEvent() in one threads > blocks other threads from receiving a reply". I get that when using DRI2 instead of DRI3. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From michel at daenzer.net Sun Jun 14 23:35:26 2015 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Mon, 15 Jun 2015 15:35:26 +0900 Subject: [Xcb] [PATCH v2 libxcb] Call _xcb_wake_up_next_reader from xcb_wait_for_special_event In-Reply-To: <557A8E53.1080606@znc.in> References: <5569AA2F.1040600@znc.in> <1433124258-20421-1-git-send-email-michel@daenzer.net> <557A8E53.1080606@znc.in> Message-ID: <557E722E.6040703@daenzer.net> On 12.06.2015 16:46, Uli Schlachter wrote: > Pushed as commit f85661c3bca97fa. Thank you Uli! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From michel at daenzer.net Mon Jun 15 03:03:02 2015 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Mon, 15 Jun 2015 19:03:02 +0900 Subject: [Xcb] [PATCH] Fix a thread hang with xcb_wait_for_special_event() In-Reply-To: <557ADCE6.2050909@znc.in> References: <557ADCE6.2050909@znc.in> Message-ID: <557EA2D6.5040500@daenzer.net> On 12.06.2015 22:21, Uli Schlachter wrote: > Consider the following: > > - Two threads are calling xcb_wait_for_special_event() and xcb_wait_for_reply() > concurrently. > - The thread doing xcb_wait_for_reply() wins the race and poll()s the socket for > readability. > - The other thread will be put to sleep on the special_event_cond of the special > event (this is done in _xcb_conn_wait() via the argument > xcb_wait_for_special_event() gives it). > - The first thread gets its reply, but does not yet receive any special event. > > In this case, the first thread will return to its caller. On its way out, it > will call _xcb_in_wake_up_next_reader(), but that function cannot wake up > anything since so far it did not handle xcb_wait_for_special_event(). > > Thus, the first thread stays blocked on the condition variable and no thread > tries to read from the socket. > > A test case demonstrating this problem is available at the bug report. > > Fix this similar to how we handle this with xcb_wait_for_reply(): > > The function wait_for_reply() adds an entry into a linked list of threads that > wait for a reply. Via this list, _xcb_in_wake_up_next_reader() can wake up this > thread so that it can call _xcb_conn_wait() again and then poll()s the socket. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252 > Signed-off-by: Uli Schlachter > --- > Michel, could you try if the test case at [0] also hangs for you and if this > patch fixes both your original problem and this test? Thanks. The answer to all of these questions is yes. :) > +static void insert_special(special_list **prev_special, special_list *special, xcb_special_event_t *se) > +{ > + special->se = se; > + special->next = *prev_special; > + *prev_special = special; > +} AFAICT this inserts the new special_list entry at the beginning of the linked list, so the thread corresponding to the last inserted entry will be woken up first, right? It might be fairer to make this a FIFO instead of a LIFO. Other than that, it looks good to me. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From mezin.alexander at gmail.com Mon Jun 15 06:35:41 2015 From: mezin.alexander at gmail.com (Alexander Mezin) Date: Mon, 15 Jun 2015 19:35:41 +0600 Subject: [Xcb] xcb_out.c:271: xcb_send_request_with_fds64: Assertion `(longlen & 3) == 0' failed. Message-ID: Hi I try to set one 8-bit value for a property using xcb_input_xi_change_property_aux. After calling the function I get: With xcb & xcb-proto from git: xcb_out.c:271: xcb_send_request_with_fds64: Assertion `(longlen & 3) == 0' failed With latest released versions: xcb_out.c:226: xcb_send_request: Assertion `(longlen & 3) == 0' failed. Looks like it's an issue in xcb and not my code -------------- next part -------------- An HTML attachment was scrubbed... URL: From psychon at znc.in Mon Jun 15 10:45:54 2015 From: psychon at znc.in (Uli Schlachter) Date: Mon, 15 Jun 2015 19:45:54 +0200 Subject: [Xcb] [PATCH] Fix a thread hang with xcb_wait_for_special_event() In-Reply-To: <557EA2D6.5040500@daenzer.net> References: <557ADCE6.2050909@znc.in> <557EA2D6.5040500@daenzer.net> Message-ID: <557F0F52.5000409@znc.in> Hi, Am 15.06.2015 um 12:03 schrieb Michel Dänzer: > On 12.06.2015 22:21, Uli Schlachter wrote: [...] >> +static void insert_special(special_list **prev_special, special_list *special, xcb_special_event_t *se) >> +{ >> + special->se = se; >> + special->next = *prev_special; >> + *prev_special = special; >> +} > > AFAICT this inserts the new special_list entry at the beginning of the > linked list, so the thread corresponding to the last inserted entry will > be woken up first, right? It might be fairer to make this a FIFO instead > of a LIFO. [...] Hm. Yes, you are right. However, changing this either requires traversing the linked list or adding a pointer to its tail. I don't really like either solution. This doesn't really matter for different xcb_special_event_t instances (we can't predict which one gets an event next anyway and event_special() will wake up the right one). If two threads call xcb_wait_for_special_event() on the same xcb_special_event_t instance, then there is a race anyway and I don't really see why we should guarantee anything at all. Also, I can't really think of any reason to call xcb_wait_for_special_event() concurrently. So I'm not really convinced we need some kind of fairness. What do you/others say? Cheers, Uli -- Bitte nicht mit dem verbleibenden Auge in den Laser gucken. - Vincent Ebert From psychon at znc.in Mon Jun 15 10:49:58 2015 From: psychon at znc.in (Uli Schlachter) Date: Mon, 15 Jun 2015 19:49:58 +0200 Subject: [Xcb] xcb_out.c:271: xcb_send_request_with_fds64: Assertion `(longlen & 3) == 0' failed. In-Reply-To: References: Message-ID: <557F1046.9000708@znc.in> Hi, Am 15.06.2015 um 15:35 schrieb Alexander Mezin: > Hi > > I try to set one 8-bit value for a property using > xcb_input_xi_change_property_aux. > > After calling the function I get: > With xcb & xcb-proto from git: xcb_out.c:271: xcb_send_request_with_fds64: > Assertion `(longlen & 3) == 0' failed > With latest released versions: xcb_out.c:226: xcb_send_request: Assertion > `(longlen & 3) == 0' failed. > > Looks like it's an issue in xcb and not my code do you have some (small) test program that demonstrates this? Looking at the generated code, this should correctly add the needed padding, so I don't know what is going on. Cheers, Uli -- Happiness can't be found -- it finds you. - Majic From mezin.alexander at gmail.com Mon Jun 15 12:45:38 2015 From: mezin.alexander at gmail.com (Alexander Mezin) Date: Tue, 16 Jun 2015 01:45:38 +0600 Subject: [Xcb] xcb_out.c:271: xcb_send_request_with_fds64: Assertion `(longlen & 3) == 0' failed. In-Reply-To: <557F1046.9000708@znc.in> References: <557F1046.9000708@znc.in> Message-ID: Minimal example. $ gcc test.c -lxcb -lxcb-input -o test $ ./test test: xcb_out.c:226: xcb_send_request: Assertion `(longlen & 3) == 0' failed. “./test” terminated by signal SIGABRT (Abort) 2015-06-15 23:49 GMT+06:00 Uli Schlachter : > Hi, > > Am 15.06.2015 um 15:35 schrieb Alexander Mezin: > > Hi > > > > I try to set one 8-bit value for a property using > > xcb_input_xi_change_property_aux. > > > > After calling the function I get: > > With xcb & xcb-proto from git: xcb_out.c:271: > xcb_send_request_with_fds64: > > Assertion `(longlen & 3) == 0' failed > > With latest released versions: xcb_out.c:226: xcb_send_request: Assertion > > `(longlen & 3) == 0' failed. > > > > Looks like it's an issue in xcb and not my code > > do you have some (small) test program that demonstrates this? Looking at > the > generated code, this should correctly add the needed padding, so I don't > know > what is going on. > > Cheers, > Uli > -- > Happiness can't be found -- it finds you. > - Majic > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 553 bytes Desc: not available URL: From mezin.alexander at gmail.com Mon Jun 15 13:04:44 2015 From: mezin.alexander at gmail.com (Alexander Mezin) Date: Tue, 16 Jun 2015 02:04:44 +0600 Subject: [Xcb] xcb_out.c:271: xcb_send_request_with_fds64: Assertion `(longlen & 3) == 0' failed. In-Reply-To: References: <557F1046.9000708@znc.in> Message-ID: Looks like [1] solves the problem. For both git master and 1.11. Is a new release of xcb-proto expected soon? [1] http://lists.freedesktop.org/archives/xcb/2015-June/010385.html 2015-06-16 1:45 GMT+06:00 Alexander Mezin : > Minimal example. > > $ gcc test.c -lxcb -lxcb-input -o test > $ ./test > test: xcb_out.c:226: xcb_send_request: Assertion `(longlen & 3) == 0' > failed. > “./test” terminated by signal SIGABRT (Abort) > > 2015-06-15 23:49 GMT+06:00 Uli Schlachter : >> >> Hi, >> >> Am 15.06.2015 um 15:35 schrieb Alexander Mezin: >> > Hi >> > >> > I try to set one 8-bit value for a property using >> > xcb_input_xi_change_property_aux. >> > >> > After calling the function I get: >> > With xcb & xcb-proto from git: xcb_out.c:271: >> > xcb_send_request_with_fds64: >> > Assertion `(longlen & 3) == 0' failed >> > With latest released versions: xcb_out.c:226: xcb_send_request: >> > Assertion >> > `(longlen & 3) == 0' failed. >> > >> > Looks like it's an issue in xcb and not my code >> >> do you have some (small) test program that demonstrates this? Looking at >> the >> generated code, this should correctly add the needed padding, so I don't >> know >> what is going on. >> >> Cheers, >> Uli >> -- >> Happiness can't be found -- it finds you. >> - Majic > > From michel at daenzer.net Mon Jun 15 19:10:09 2015 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Tue, 16 Jun 2015 11:10:09 +0900 Subject: [Xcb] [PATCH] Fix a thread hang with xcb_wait_for_special_event() In-Reply-To: <557F0F52.5000409@znc.in> References: <557ADCE6.2050909@znc.in> <557EA2D6.5040500@daenzer.net> <557F0F52.5000409@znc.in> Message-ID: <557F8581.4030909@daenzer.net> On 16.06.2015 02:45, Uli Schlachter wrote: > Am 15.06.2015 um 12:03 schrieb Michel Dänzer: >> On 12.06.2015 22:21, Uli Schlachter wrote: > [...] >>> +static void insert_special(special_list **prev_special, special_list *special, xcb_special_event_t *se) >>> +{ >>> + special->se = se; >>> + special->next = *prev_special; >>> + *prev_special = special; >>> +} >> >> AFAICT this inserts the new special_list entry at the beginning of the >> linked list, so the thread corresponding to the last inserted entry will >> be woken up first, right? It might be fairer to make this a FIFO instead >> of a LIFO. > [...] > > Hm. Yes, you are right. However, changing this either requires traversing the > linked list or adding a pointer to its tail. I don't really like either solution. > > This doesn't really matter for different xcb_special_event_t instances (we can't > predict which one gets an event next anyway and event_special() will wake up the > right one). If two threads call xcb_wait_for_special_event() on the same > xcb_special_event_t instance, then there is a race anyway and I don't really see > why we should guarantee anything at all. Also, I can't really think of any > reason to call xcb_wait_for_special_event() concurrently. FWIW, I don't think there's anything preventing that from happening with DRI3 when using OpenGL from several threads, such as in the glthreads demo app. Anyway, you've convinced me that the order in which these list entries are processed shouldn't matter much (more so since pthread_cond_signal doesn't wake up any specific thread but a random one waiting on the condition variable). The patch is Tested-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From helmut at subdivi.de Mon Jun 15 10:30:59 2015 From: helmut at subdivi.de (Helmut Grohne) Date: Mon, 15 Jun 2015 19:30:59 +0200 Subject: [Xcb] Bug#788861: unsatisfiable cross Build-Depends Message-ID: <20150615173058.GA23226@alf.mars> Source: libxcb Version: 1.10-3 Tags: patch User: helmutg at debian.org Usertags: rebootstrap Currently, trying to satisfy cross Build-Depends for libxcb fails, because the python dependency selects the host arch python and the python-xcbgen dependency requires the build arch python. The solution to this problem is to add ":native" (or ":any") to the python dependency. In addition, it would be nice if building check could be avoided. This requires marking the check dependency with the nocheck build profile. Please consider applying the attached patch. Helmut -------------- next part -------------- diff -u libxcb-1.10/debian/changelog libxcb-1.10/debian/changelog --- libxcb-1.10/debian/changelog +++ libxcb-1.10/debian/changelog @@ -1,3 +1,12 @@ +libxcb (1.10-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Make dependencies cross-sastifiable (closes: #-1). + + Mark python dependency with :native to pick an executable python. + + Do not build-depend on check when the nocheck profile is passed. + + -- Helmut Grohne Mon, 15 Jun 2015 15:24:14 +0200 + libxcb (1.10-3) unstable; urgency=medium * Add missing dependencies to libxcb-present-dev. Thanks, Michel Dänzer! diff -u libxcb-1.10/debian/control libxcb-1.10/debian/control --- libxcb-1.10/debian/control +++ libxcb-1.10/debian/control @@ -12,11 +12,11 @@ debhelper (>= 8.9.4~), pkg-config, xsltproc (>= 1.1.19), - check (>= 0.9.4-2), + check (>= 0.9.4-2) , python-xcbgen (>= 1.10), libtool, automake, - python, + python:native, dctrl-tools Build-Depends-Indep: # libxcb-doc From bugzilla-daemon at freedesktop.org Wed Jun 17 08:05:42 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 17 Jun 2015 15:05:42 +0000 Subject: [Xcb] [Bug 84252] DRI3 rendering gets stuck waiting for present idle notify event In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=84252 --- Comment #55 from Rex Dieter --- Fwiw, seeing what appear to be related deadlocks in plasma5 environment too, see downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1193742 and the proposed fix/workaround from comment #49 seems to help. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmike at samsung.com Wed Jun 17 12:28:30 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Wed, 17 Jun 2015 15:28:30 -0400 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify In-Reply-To: <20150611165436.6f039e82@Sir.Pimpleton> References: <20150611142447.55ad8dc6@Sir.Pimpleton> <5579E366.3070901@oracle.com> <20150611165436.6f039e82@Sir.Pimpleton> Message-ID: <20150617152830.20cc974b@Sir.Pimpleton> On Thu, 11 Jun 2015 16:54:36 -0400 Mike Blumenkrantz wrote: > On Thu, 11 Jun 2015 12:37:10 -0700 > Alan Coopersmith wrote: > > > On 06/11/15 11:24 AM, Mike Blumenkrantz wrote: > > > Commit by Josh Triplett and Jamey Sharp. > > > > Why is this useful? It would really help if the commit comment had > > explanation, as suggested in > > http://who-t.blogspot.com/2009/12/on-commit-messages.html - > > otherwise it's a hard to review code dump, which for X, probably > > means it goes nowhere, as we don't have enough reviewers to reverse > > engineer code changes. > > > > This is a prep commit for the function added later in the series. It > refactors the code to reduce duplication later on when there are two > functions which will be using the same code paths. To elaborate further, this patch series will be useful for anyone wishing to implement XWayland functionality using Xlib. The X11 connection must be opened from a file descriptor using XCB, and so some method of opening a Display object from that XCB connection is necessary. These patches add that method while reducing code duplication to a minimum and, hopefully, still allowing multithreaded Xlib connections to function as expected. From jstpierre at mecheye.net Wed Jun 17 13:09:00 2015 From: jstpierre at mecheye.net (Jasper St. Pierre) Date: Wed, 17 Jun 2015 13:09:00 -0700 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify In-Reply-To: <20150617152830.20cc974b@Sir.Pimpleton> References: <20150611142447.55ad8dc6@Sir.Pimpleton> <5579E366.3070901@oracle.com> <20150611165436.6f039e82@Sir.Pimpleton> <20150617152830.20cc974b@Sir.Pimpleton> Message-ID: Why not use -displayfd to get the display number to connect to? This patch is still a good idea, I think, but it's not required. On Wed, Jun 17, 2015 at 12:28 PM, Mike Blumenkrantz wrote: > On Thu, 11 Jun 2015 16:54:36 -0400 > Mike Blumenkrantz wrote: > >> On Thu, 11 Jun 2015 12:37:10 -0700 >> Alan Coopersmith wrote: >> >> > On 06/11/15 11:24 AM, Mike Blumenkrantz wrote: >> > > Commit by Josh Triplett and Jamey Sharp. >> > >> > Why is this useful? It would really help if the commit comment had >> > explanation, as suggested in >> > http://who-t.blogspot.com/2009/12/on-commit-messages.html - >> > otherwise it's a hard to review code dump, which for X, probably >> > means it goes nowhere, as we don't have enough reviewers to reverse >> > engineer code changes. >> > >> >> This is a prep commit for the function added later in the series. It >> refactors the code to reduce duplication later on when there are two >> functions which will be using the same code paths. > > To elaborate further, this patch series will be useful for anyone > wishing to implement XWayland functionality using Xlib. The > X11 connection must be opened from a file descriptor using XCB, and so > some method of opening a Display object from that XCB connection is > necessary. These patches add that method while reducing code > duplication to a minimum and, hopefully, still allowing multithreaded > Xlib connections to function as expected. > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Jasper From zmike at samsung.com Wed Jun 17 13:22:14 2015 From: zmike at samsung.com (Mike Blumenkrantz) Date: Wed, 17 Jun 2015 16:22:14 -0400 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify In-Reply-To: References: <20150611142447.55ad8dc6@Sir.Pimpleton> <5579E366.3070901@oracle.com> <20150611165436.6f039e82@Sir.Pimpleton> <20150617152830.20cc974b@Sir.Pimpleton> Message-ID: <20150617162214.0827ff59@Sir.Pimpleton> On Wed, 17 Jun 2015 13:09:00 -0700 "Jasper St. Pierre" wrote: > Why not use -displayfd to get the display number to connect to? This > patch is still a good idea, I think, but it's not required. > > On Wed, Jun 17, 2015 at 12:28 PM, Mike Blumenkrantz > wrote: > > On Thu, 11 Jun 2015 16:54:36 -0400 > > Mike Blumenkrantz wrote: > > > >> On Thu, 11 Jun 2015 12:37:10 -0700 > >> Alan Coopersmith wrote: > >> > >> > On 06/11/15 11:24 AM, Mike Blumenkrantz wrote: > >> > > Commit by Josh Triplett and Jamey Sharp. > >> > > >> > Why is this useful? It would really help if the commit comment > >> > had explanation, as suggested in > >> > http://who-t.blogspot.com/2009/12/on-commit-messages.html - > >> > otherwise it's a hard to review code dump, which for X, probably > >> > means it goes nowhere, as we don't have enough reviewers to > >> > reverse engineer code changes. > >> > > >> > >> This is a prep commit for the function added later in the series. > >> It refactors the code to reduce duplication later on when there > >> are two functions which will be using the same code paths. > > > > To elaborate further, this patch series will be useful for anyone > > wishing to implement XWayland functionality using Xlib. The > > X11 connection must be opened from a file descriptor using XCB, and > > so some method of opening a Display object from that XCB connection > > is necessary. These patches add that method while reducing code > > duplication to a minimum and, hopefully, still allowing > > multithreaded Xlib connections to function as expected. > > _______________________________________________ > > xorg-devel at lists.x.org: X.Org development > > Archives: http://lists.x.org/archives/xorg-devel > > Info: http://lists.x.org/mailman/listinfo/xorg-devel > > > That's a pretty reasonable suggestion, and I guess my answer is that I didn't think of it. Thanks! Regardless of whether it's needed, however, I'd still like to get this feature included in upstream. The patchset has been bitrotting on Josh's computer for several years, and it would be great to see it finally land. From josh at joshtriplett.org Wed Jun 17 13:35:55 2015 From: josh at joshtriplett.org (josh at joshtriplett.org) Date: Wed, 17 Jun 2015 13:35:55 -0700 Subject: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify In-Reply-To: References: <20150611142447.55ad8dc6@Sir.Pimpleton> <5579E366.3070901@oracle.com> <20150611165436.6f039e82@Sir.Pimpleton> <20150617152830.20cc974b@Sir.Pimpleton> Message-ID: <20150617203555.GA24079@cloud> On Wed, Jun 17, 2015 at 01:09:00PM -0700, Jasper St. Pierre wrote: > Why not use -displayfd to get the display number to connect to? This > patch is still a good idea, I think, but it's not required. This is useful for any API that wants to interoperate between XCB and Xlib without specifically receiving an Xlib Display. It means APIs can convert over to XCB without requiring that all their dependencies do so first. - Josh Triplett From jcristau at debian.org Thu Jun 18 22:27:28 2015 From: jcristau at debian.org (Julien Cristau) Date: Fri, 19 Jun 2015 07:27:28 +0200 Subject: [Xcb] Bug#788232: Bug#788232: /usr/include/xcb/xcb.h: xcb/xproto.h can't be included In-Reply-To: <20150609152828.10244.12097.reportbug@berry.homenet.telecomitalia.it> References: <20150609152828.10244.12097.reportbug@berry.homenet.telecomitalia.it> Message-ID: <20150619052728.GX2120@betterave.cristau.org> Control: severity -1 minor Control: tag -1 upstream fixed-upstream On Tue, Jun 9, 2015 at 17:28:28 +0200, Lorenzo Beretta wrote: > Package: libxcb1-dev > Version: 1.10-3+b1 > Severity: important > File: /usr/include/xcb/xcb.h > > Dear Maintainer, > > the headers in libxcb1-dev have a bug that appears to have been fixed > upstream and makes the package basically unusable: > $ cat>test.c < #include > int main() { return 0; } > EOF > $ gcc test.c > In file included from /usr/include/xcb/xproto.h:15:0, > from test.c:1: > /usr/include/xcb/xcb.h:401:7: error: unknown type name ‘xcb_query_extension_reply_t’ > const xcb_query_extension_reply_t *xcb_get_extension_data(xcb_connection_t *c, xcb_extension_t *ext); > ^ > /usr/include/xcb/xcb.h:437:7: error: unknown type name ‘xcb_setup_t’ > const xcb_setup_t *xcb_get_setup(xcb_connection_t *c); > ^ > > > Probably same bug as 778307, except for people using the -dev package > it's completely broken, not just a wishlist. > It's not "completely broken". Just include xcb.h first... Cheers, Julien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From owner at bugs.debian.org Thu Jun 18 22:30:06 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 19 Jun 2015 05:30:06 +0000 Subject: [Xcb] Processed: Re: Bug#788232: /usr/include/xcb/xcb.h: xcb/xproto.h can't be included References: <20150619052728.GX2120@betterave.cristau.org> <20150609152828.10244.12097.reportbug@berry.homenet.telecomitalia.it> Message-ID: Processing control commands: > severity -1 minor Bug #788232 [libxcb1-dev] /usr/include/xcb/xcb.h: xcb/xproto.h can't be included Severity set to 'minor' from 'important' > tag -1 upstream fixed-upstream Bug #788232 [libxcb1-dev] /usr/include/xcb/xcb.h: xcb/xproto.h can't be included Added tag(s) fixed-upstream and upstream. -- 788232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788232 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Thu Jun 18 22:33:04 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 19 Jun 2015 05:33:04 +0000 Subject: [Xcb] Processed: severity of 788861 is wishlist References: <1434691877-966-bts-jcristau@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > severity 788861 wishlist Bug #788861 [src:libxcb] unsatisfiable cross Build-Depends Severity set to 'wishlist' from 'normal' > thanks Stopping processing here. Please contact me if you need assistance. -- 788861: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788861 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From lory.fulgi at infinito.it Fri Jun 19 12:40:48 2015 From: lory.fulgi at infinito.it (Lorenzo) Date: Fri, 19 Jun 2015 21:40:48 +0200 Subject: [Xcb] Bug#788232: Bug#788232: /usr/include/xcb/xcb.h: xcb/xproto.h can't be included In-Reply-To: <20150619052728.GX2120@betterave.cristau.org> References: <20150609152828.10244.12097.reportbug@berry.homenet.telecomitalia.it> <20150619052728.GX2120@betterave.cristau.org> Message-ID: <55847040.8070604@infinito.it> On 06/19/2015 07:27 AM, Julien Cristau wrote: > Control: severity -1 minor > Control: tag -1 upstream fixed-upstream > > On Tue, Jun 9, 2015 at 17:28:28 +0200, Lorenzo Beretta wrote: > >> ... >> > It's not "completely broken". Just include xcb.h first... > > Cheers, > Julien > Good suggestion, but 1. I'm compiling code written by other people (just trying some window managers), and 2. The manpages say to #include But I'll admit that "completely broken" was a bit too much :) From bugzilla-daemon at freedesktop.org Thu Jun 25 11:40:49 2015 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 25 Jun 2015 18:40:49 +0000 Subject: [Xcb] [Bug 84252] DRI3 rendering gets stuck waiting for present idle notify event In-Reply-To: References: Message-ID: https://bugs.freedesktop.org/show_bug.cgi?id=84252 Uli Schlachter changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #56 from Uli Schlachter --- A second part of this was pushed as commit 5b40681c887192307f3ae147d2158870aa79c05f. This should hopefully fix this. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psychon at znc.in Thu Jun 25 11:41:18 2015 From: psychon at znc.in (Uli Schlachter) Date: Thu, 25 Jun 2015 20:41:18 +0200 Subject: [Xcb] [PATCH] Fix a thread hang with xcb_wait_for_special_event() In-Reply-To: <557F8581.4030909@daenzer.net> References: <557ADCE6.2050909@znc.in> <557EA2D6.5040500@daenzer.net> <557F0F52.5000409@znc.in> <557F8581.4030909@daenzer.net> Message-ID: <558C4B4E.30905@znc.in> Pushed, thanks for investigating and testing. Am 16.06.2015 um 04:10 schrieb Michel Dänzer: > On 16.06.2015 02:45, Uli Schlachter wrote: >> Am 15.06.2015 um 12:03 schrieb Michel Dänzer: >>> On 12.06.2015 22:21, Uli Schlachter wrote: >> [...] >>>> +static void insert_special(special_list **prev_special, special_list *special, xcb_special_event_t *se) >>>> +{ >>>> + special->se = se; >>>> + special->next = *prev_special; >>>> + *prev_special = special; >>>> +} >>> >>> AFAICT this inserts the new special_list entry at the beginning of the >>> linked list, so the thread corresponding to the last inserted entry will >>> be woken up first, right? It might be fairer to make this a FIFO instead >>> of a LIFO. >> [...] >> >> Hm. Yes, you are right. However, changing this either requires traversing the >> linked list or adding a pointer to its tail. I don't really like either solution. >> >> This doesn't really matter for different xcb_special_event_t instances (we can't >> predict which one gets an event next anyway and event_special() will wake up the >> right one). If two threads call xcb_wait_for_special_event() on the same >> xcb_special_event_t instance, then there is a race anyway and I don't really see >> why we should guarantee anything at all. Also, I can't really think of any >> reason to call xcb_wait_for_special_event() concurrently. > > FWIW, I don't think there's anything preventing that from happening with > DRI3 when using OpenGL from several threads, such as in the glthreads > demo app. > > Anyway, you've convinced me that the order in which these list entries > are processed shouldn't matter much (more so since pthread_cond_signal > doesn't wake up any specific thread but a random one waiting on the > condition variable). The patch is > > Tested-by: Michel Dänzer > > -- Sent from my Game Boy. From jon.turney at dronecode.org.uk Mon Jun 29 09:58:57 2015 From: jon.turney at dronecode.org.uk (Jon TURNEY) Date: Mon, 29 Jun 2015 17:58:57 +0100 Subject: [Xcb] [PATCH] Link with winsock library for socket functions on MinGW In-Reply-To: <552688E4.1020309@dronecode.org.uk> References: <1426614554-8548-1-git-send-email-jon.turney@dronecode.org.uk> <552688E4.1020309@dronecode.org.uk> Message-ID: <55917951.8050402@dronecode.org.uk> On 09/04/2015 15:12, Jon TURNEY wrote: > On 17/03/2015 17:49, Jon TURNEY wrote: >> --- >> configure.ac | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/configure.ac b/configure.ac >> index 6e7e9c3..cce0ddb 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -206,6 +206,15 @@ case $host_os in >> ;; >> esac >> >> +dnl Link with winsock for socket functions on MinGW >> +case $host_os in >> + *mingw*) >> + AC_CHECK_LIB([ws2_32],[main]) >> + ;; >> + *) >> + ;; >> +esac >> + >> XCB_EXTENSION(Composite, yes) >> XCB_EXTENSION(Damage, yes) >> XCB_EXTENSION(DPMS, yes) > > Ping? Ping?