| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
This is needed due to various changes that were done to the XML schema.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Some systems (e.g. OpenBSD) have a rather small default socket send buffer
size of 4KB. The result is that sending requests with a largish payload
requires serveral writev(2) system calls. Make sure the socket send buffer
is at least 64KB such that we're likely to succeed with a single system
call for most requests. A similar change was made to the xtrans code
some time ago.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
|
|
Pads should not be serialized/deserialized to maintain
ABI compatibility when adding explicit align pads.
Therefore this pad switches off serialization of pads
unless it is enforced by serialize=true in the xml-definition
of that pad
Signed-off-by: Christian Linhart <chris@demorecorder.com>
|
|
Some rework done by Christian Linhart
Signed-off-by: Jaya Tiwari <tiwari.jaya18@gmail.com>
Signed-off-by: Christian Linhart <chris@demorecorder.com>
|
|
If a list is preceded by an align-pad, then
accessor for the end-iterator returned a wrong
value.
Reason: the length of the align-iterator was added
to a pointer of list-member type. Therefore, the length
was multiplied by the size of the list-member type,
due to C pointer arithmetic rules.
This has looked like the following, e.g., in
xcb_randr_get_crtc_transform_pending_params_end:
i.data = ((xcb_render_fixed_t *) prev.data) + ((-prev.index) & (4 - 1)) + (R->pending_nparams);
This bug was introduced with the following commit:
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=4033d39d4da21842bb1396a419dfc299591c3b1f
The fix handles this by casting to char* before adding the align,
and then casting the result to the member type.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
|
|
instead of using the lower bits of the pointer address.
This fixes a bug reported by Peter Hutterer in off-list communication
back in June 2015.
This requires the alignment-checker patches in xcb/proto.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
|
|
We've released 1.11.1 and new libX11 wants that or better. git master
will suffice, so bump the version number ahead of 1.11 branch.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Handle align-pads when generating an end-function
in the same way as handling them when generating
an accessor or iterator function.
Signed-off-by: Christian Linhart <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 <chris@demorecorder.com>
|
|
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
|
|
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 <psychon@znc.in>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
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 <bztdlinux@gmail.com>
Tested-by: Clément Guérin <geecko.dev@free.fr>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Before this patch, the following code caused an endless loop in send_fds(),
because the queue of FDs to send was eventually full, but _xcb_out_flush_to()
didn't make any progress, since there was no request to send:
while (1) { xcb_send_fd(conn, dup(some_fd)); }
Fix this by sending a sync when flushing didn't make any progress. That way we
actually have something to send and can attach the pending FDs.
Because send_fds() can now send requests, the code in
xcb_send_request_with_fds64() has to be changed. It has to call send_fds()
before it establishes a good sequence number for the request it wants to send.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Doing xcb_send_fd(), xcb_send_request() is racy. If two threads do this at the
same time, they could mix up their file descriptors. This commit makes it
possibly to fix this race by providing a single function which does everything
that is needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
|
|
Two threads trying to send fds at the same time could interfere. To guarantee a
correct ordering, we have to use correct locking. The code in send_fds() missed
one case: If there was another thread already writing requests, we slept on the
"done with writing" condition variable (c->out.cond). This would allow other
threads to re-acquire the iolock before us and could cause fds to be sent out of
order.
To fix this, at the beginning of send_fds() we now make sure that no other
thread is already writing requests. This is what prepare_socket_request() does.
Additionally, it gets the socket back in case xcb_take_socket() was called,
which is a good thing, too, since fds are only sent with corresponding requests.
|
|
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 <psychon@znc.in>
|
|
(This does not change doxygen's output or warnings).
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
While XCB uses 64-bit sequence number internally, it only exposes
"unsigned int" so that, on 32-bit architecture, Xlib based applications
may see their sequence number wrap which causes the connection to the X
server to be lost.
Expose 64-bit sequence number from XCB API so that Xlib and others can
use it even on 32-bit environment.
This implies the following API addition:
xcb_send_request64()
xcb_discard_reply64()
xcb_wait_for_reply64()
xcb_poll_for_reply64()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71338
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
|
|
In nroff, \n is a macro that "Interpolates number register x" (where x
is the character following the \n sequence), thus the man page currently
prints 0 instead of \n" in several lines, leading to output such as:
printf("The _NET_WM_NAME atom has ID %u0, reply->atom);
It needs to be escaped here, as \\n, as is done in other examples in
this man page already.
https://bugs.freedesktop.org/show_bug.cgi?id=90231
Reported-by: Stefan Merettig
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
The name can be understood from the type of S already.
For examples, look for 'S->' in xkb.c or xinput.c.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Rémi Cardona <remi@gentoo.org>
|
|
It is implied already inside the function by the `void` argument.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
(Also remove unnecessary parens around the condition).
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
This works for all python>=2.6, which is what configure requires.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
c_client.py:2: 'from xml.etree.cElementTree import *' used; unable to detect undefined names
c_client.py:3: 'basename' imported but unused
c_client.py:9: 'time' imported but unused
c_client.py:1437: local variable 'list_obj' is assigned to but never used
c_client.py:1745: local variable 'varfield' is assigned to but never used
c_client.py:2050: local variable 'length' is assigned to but never used
c_client.py:2416: local variable 'R_obj' is assigned to but never used
c_client.py:2441: local variable 'S_obj' is assigned to but never used
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
The results are not used, and the function doesn't have side effects.
Signed-off-by: Ran Benita <ran234@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
|
|
Added accessor functions for requests the same way they were added for
structs,events and replies.
Lists for replies have accessor functions now.
Signed-off-by: Jaya Tiwari <tiwari.jaya18@gmail.com>
Reviewed-by: Christian Linhart <chris@demorecorder.com>
Comment from the Reviewer Christian Linhart:
I have tested your patch after fixing the issues with the patch-format.
It looks good:
* only adds new functions, and does not modify existing functions.
Therefore it is API and ABI compatible.
* adds accessors for varsized-stuff in requests.
This is needed for server-side XCB and may be useful for implementing X11-protocol proxies.
|
|
branch 'ParametrizedStruct-V7'
|
|
Parametrized structs contain paramref expressions which
refer to the value of a field defined in the context
where the struct is used.
Implementing the parametrized structs turned out
to be somewhat easier than previously thought
because the generator already had some support for type-parametrization
because this is needed when case or bitcase refers to fields outside
of the switch.
So I decided to go with the flow and to implement the solution
which best fits the current implementation.
I did the following:
* I provided a way to specify fieldref with an explicitely given type:
This resulted in <paramref type="CARD8>fieldname</paramref>
A paramref is just a fieldref with an explicit type.
The type is necessary because there is no local field of that
name where the type can be derived from.
* then I tested it and made several changes in the generator
such that it really works.
Basically the generated code is as follows:
* The parameter appears on the parameter list of the
sizeof-function of the parametrized struct.
When that function gets called, an appropriate argument is supplied.
* The parameter also appears as an additional member of the iterator-struct
for the iterator of lists of that parametrized struct.
This way, the next-function can get the value of that parameter from the iterator.
When the iterator is created, this iterator-member is set accordingly.
* When the paramref appears in the length-expression of a list, then
the parameter appears on the parameterlist of the "length" and "end" functions.
When these functions get called, an appropriate argument is supplied.
Some comments:
* I did not implement inline structs.
This would probably have been more complicated, and at least some additional effort.
But that can be implemented later if needed.
(Inline structs could probably use some code from switch-case/bitcase which is already kind of
an inlined struct but one has to be careful not to break the functionality
of switch-case/bitcase. Support for inline structs inside lists must probably
be implemented from scratch...)
* The paramref expression refers to a field of the same name in the struct/request/...
where it is used.
So it is not possible to pass the value of arbitrary fields or even expressions
to the parametrized struct.
This would have been possible with the previously discussed <typearg>.
That can be added later, if needed.
( Wont be too complicated )
* So this is pretty much like the proposal from Ran Benita.
changes for V2 of this patch, according to suggestions from Ran Benita:
* replace map with list comprehension
because map returns an iterator instead of a list from Python 3 on,
so it cannot be added to a list anymore.
* removed "self" parameter of function additional_params_to_str
and accessed the variable additional_params from the outer
function directly.
changes for V2 of this patch:
* adapt to revision 2 of patchset ListInputDevices
* style fixes for similar things that Ran Benita has found in my previous patches
Message-ID: <54574397.4060000@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] parametrized structs implemented
Patch-Set: ParametrizedStruct
Patch-Number: libxcb 1/1
Patch-Version: V3
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
|
|
Support for listelement-ref needs the following three changes
(in the order as they appear in the patch):
* making the current list-element accessible with the variable
xcb_listelement which is a pointer to the list-element
* supporting lists of simple-type for sumof with a nested expression
* using the variable for resolving a listelement-ref expression
Changes for V2 of this patch:
- adapt to removal of patch "libxcb 2/6" from patchset "ListInputDevices".
Changes for V3 of this patch:
- adapt to V2 of patch "libxcb 5/6" from patchset "ListInputDevices"
Changes for V4 of this patch:
- adapt to revision 2 of the patchset "ListInputDevices"
Message-ID: <545743A0.50907@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 4/4
Patch-Version: V4
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
|
|
The function _c_accessor_get_length had a special case handling
for intermixed var and fixed size fields.
However:
* The implementation of that special case was buggy:
It tried to call a python-dict as a function which causes
Python to abort the program with a stacktrace and error message.
So this code was never used.
* The case it tried to handle is handeled elsewhere in the
meantime: in _c_helper_absolute_name by previous patches
made by me.
Message-ID: <1409845851-38950-3-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 3/4
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
|
|
Accessors are generally needed for var-sized fields
and fields after var-sized fields.
Generic events can have ver-sized fields.
Therefore they need accessors.
Message-ID: <1409845851-38950-2-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 2/4
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
|
|
_c_type_setup is not called for eventcopies anymore:
Reasons:
* the type-setup of an eventcopy would overwrite members of the original
event object such as c_type, ...
* it is needed for the next patch, i.e., generating accessors:
type_setup would create sizeof-etc funtions which called
undefined accessor functions.
Sizeof-functions are generated for compatibility:
Reason:
* Type-setup of eventcopies has previously generated
sizeof-functions for eventcopies.
So, we still need to generate these functions.
These new sizeof-functions simply call the sizeof-function
of the defining event of the eventcopy.
Message-ID: <1409845851-38950-1-git-send-email-chris@demorecorder.com>
Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
Patch-Set: PopcountList
Patch-Number: libxcb 1/4
Patch-Version: V1
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
|
|
The loop-variable "sep" is never empty in function
"_c_helper_fieldaccess_expr", after a fix elsewhere.
Therefore I removed the handling of the case of "sep" being empty.
Thanks to Ran Benita for the hint that this can be removed.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <545627C2.3050608@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 9/9
Patch-Version: V1
|
|
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <545627BA.1000909@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 8/9
Patch-Version: V1
|
|
The function _c_helper_absolute_name was named in
a misleading way.
It computes a C-expression for accessing a field of an xcb-type.
Therefore the name _c_helper_fieldaccess_expr is more appropriate.
Note: Patch 6 of this series has been removed during the review process.
Signed-off-by: Christian Linhart <chris@demorecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <545627AE.2040200@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 7/9
Patch-Version: V1
|
|
Support sumof with a nested expression.
The nested expression is computed for every list-element
and the result of the computation is added to the sum.
This way, sumof can be applied to a list of structs,
and, e.g., compute the sum of a specific field of that struct.
example:
<struct name="SumofTest_Element">
<field type="CARD16" name="foo" />
<field type="CARD16" name="bar" />
</struct>
<struct name="SumofTest_FieldAccess">
<field type="CARD32" name="len" />
<list type="SumofTest_Element" name="mylist1">
<fieldref>len</fieldref>
</list>
<list type="CARD16" name="mylist2">
<sumof ref="mylist1">
<fieldref>bar</fieldref>
</sumof>
</list>
</struct>
generated tmpvar:
int xcb_pre_tmp_1; /* sumof length */
int xcb_pre_tmp_2; /* sumof loop counter */
int64_t xcb_pre_tmp_3; /* sumof sum */
const xcb_input_sumof_test_element_t* xcb_pre_tmp_4; /* sumof list ptr */
generated code:
/* mylist2 */
/* sumof start */
xcb_pre_tmp_1 = _aux->len;
xcb_pre_tmp_3 = 0;
xcb_pre_tmp_4 = xcb_input_sumof_test_field_access_mylist_1(_aux);
for ( xcb_pre_tmp_2 = 0; xcb_pre_tmp_2 < xcb_pre_tmp_1; xcb_pre_tmp_2++) {
xcb_pre_tmp_3 += xcb_pre_tmp_4->bar;
xcb_pre_tmp_4++;
}
/* sumof end. Result is in xcb_pre_tmp_3 */
xcb_block_len += xcb_pre_tmp_3 * sizeof(uint16_t);
changes for V2 of this patch:
* explicitely set the member access operator in the prefix-tuple
passed to function _c_helper_field_mapping.
This enables us to simplify function "_c_helper_absolute_name"
(which will be renamed "_c_helper_fieldaccess_expr" soon)
V3: Changed style and formatting according to suggestions from Ran Benita
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <54562798.8040500@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 5/9
Patch-Version: V3
|
|
A sumof-expression now generates explicit code ( for-loop etc )
instead of calling xcb_sumof.
This way, it supports any type which can be added.
Previously, only uint_8 was supported.
Here's an example and the generated code:
xml:
<struct name="SumofTest">
<field type="CARD32" name="len" />
<list type="CARD16" name="mylist1">
<fieldref>len</fieldref>
</list>
<list type="CARD8" name="mylist2">
<sumof ref="mylist1"/>
</list>
</struct>
declaration of tempvars at the start of enclosing function:
int xcb_pre_tmp_1; /* sumof length */
int xcb_pre_tmp_2; /* sumof loop counter */
int64_t xcb_pre_tmp_3; /* sumof sum */
const uint16_t* xcb_pre_tmp_4; /* sumof list ptr */
code:
/* mylist2 */
/* sumof start */
xcb_pre_tmp_1 = _aux->len;
xcb_pre_tmp_3 = 0;
xcb_pre_tmp_4 = xcb_input_sumof_test_mylist_1(_aux);
for ( xcb_pre_tmp_2 = 0; xcb_pre_tmp_2 < xcb_pre_tmp_1; xcb_pre_tmp_2++) {
xcb_pre_tmp_3 += *xcb_pre_tmp_4;
xcb_pre_tmp_4++;
}
/* sumof end. Result is in xcb_pre_tmp_3 */
xcb_block_len += xcb_pre_tmp_3 * sizeof(uint8_t);
This patch is also a preparation for sumof which can access
fields of lists of struct, etc.
V2: Changed style and formatting according to suggestions from Ran Benita
Signed-off-by: Christian Linhart <chris@DemoRecorder.com>
Reviewed-by: Ran Benita <ran234@gmail.com>
Message-ID: <54562774.8030306@DemoRecorder.com>
Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2
Patch-Set: ListInputDevices
Patch-Number: libxcb 4/9
Patch-Version: V2
|
