summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-08-13make lists after align-pads workHEADmasterChristian Linhart1-4/+10
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>
2015-07-04make support for server side stuff optionalChristian Linhart3-2/+18
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>
2015-07-04Link with winsock library for socket functions on MinGWJon TURNEY1-0/+9
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
2015-06-25Fix a thread hang with xcb_wait_for_special_event()Uli Schlachter2-0/+33
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>
2015-06-12Call _xcb_wake_up_next_reader from xcb_wait_for_special_eventMichel Dänzer1-0/+1
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>
2015-06-12send_fds(): Handle too many outstanding FDs to sendUli Schlachter1-3/+11
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>
2015-06-12Code generator: Use xcb_send_request_with_fds()Uli Schlachter1-2/+10
Signed-off-by: Uli Schlachter <psychon@znc.in>
2015-06-12Add xcb_send_request_with_fds() and *_with_fds64()Uli Schlachter2-9/+90
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>
2015-06-12send_fds(): Make sure no other thread interrupts usUli Schlachter1-0/+9
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.
2015-06-12xcb_send_fd(): Always close fdsUli Schlachter1-10/+34
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>
2015-05-30c_client.py: don't generate useless empty /** < */ commentsRan Benita1-42/+42
(This does not change doxygen's output or warnings). Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-05-30c_client.py: use pattern matching with enumerate()Ran Benita1-4/+3
Signed-off-by: Ran Benita <ran234@gmail.com>
2015-04-08expose 64-bit sequence numbers for XLibChristian Linhart4-1/+126
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>
2015-04-29Escape \n to display properly in xcb-requests man pageAlan Coopersmith1-3/+3
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>
2015-03-15c_client.py: make condition easier to follow in _c_complex()Ran Benita1-3/+1
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: don't add /* <name> */ before references to 'S'Ran Benita1-4/+2
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>
2015-03-15c_client.py: remove duplicated `cookie_type` argument for requestsRan Benita1-15/+15
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>
2015-03-15c_client.py: spell out keyword arguments in c_request() for clarityRan Benita1-9/+9
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: simplify _c_reply_has_fds()Ran Benita1-4/+1
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: remove commented debug statementsRan Benita1-3/+0
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: use C99 initializers instead of commentsRan Benita1-4/+4
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: remove end-of-function commentsRan Benita1-16/+0
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: no need to compare bools to True/FalseRan Benita1-2/+2
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: use "foo".join() instead of reduceRan Benita1-5/+4
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: fix indentationRan Benita1-7/+6
(Also remove unnecessary parens around the condition). Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: use comprehensions instead of map/filterRan Benita1-7/+7
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: use print as a function for python3 compatibilityRan Benita1-4/+4
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>
2015-03-15c_client.py: fix pyflakes errorsRan Benita1-12/+0
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>
2015-03-15c_client.py: simplify maximum expressionRan Benita1-2/+1
Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-03-15c_client.py: remove unneeded call to get_serialize_params()Ran Benita1-1/+0
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>
2015-02-22Adding accessors for requestsJaya Tiwari1-0/+1
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.
2015-02-10Merge http://git.demorecorder.com/git/free-sw/xcb/libxcbChristian Linhart1-58/+385
branch 'ParametrizedStruct-V7'
2014-11-03generator: support parametrized structsChristian Linhart1-20/+109
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>
2014-11-03generator: support listelement-refChristian Linhart1-4/+15
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>
2014-11-03generator: _c_accessor_get_length: remove buggy special caseChristian Linhart1-6/+1
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>
2014-11-03generator: generate accessors for events, tooChristian Linhart1-0/+4
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>
2014-11-03generator: no type-setup for eventcopies anymoreChristian Linhart1-1/+24
_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>
2014-11-03_c_helper_fieldaccess_expr: remove handling for empty sepChristian Linhart1-5/+0
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
2014-11-03function _c_helper_fieldaccess_expr: improve descriptionChristian Linhart1-2/+11
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
2014-11-03rename _c_helper_absolute_name to _c_helper_fieldaccess_exprChristian Linhart1-7/+7
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
2014-11-03generator: sumof with nested expressionChristian Linhart1-1/+24
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
2014-11-03generator: sumof: support any type, generate explicit codeChristian Linhart1-2/+24
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
2014-11-03generator: expressions can generate pre-codeChristian Linhart1-4/+120
This patch provides a mechanism for generating preparatory code for expressions. This is e.g. necessary when an expression needs computations which cannot be done in a C-Expression, like for-loops. This will be used for sumof expressions but may be useful elsewhere. Note: Patch 2 of this series has been removed during the review process. V2: adapt to changes in previous patches V3: some style and formatting changes according to suggestions from Ran Benita. Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-by: Ran Benita <ran234@gmail.com> Message-ID: <54562769.3090405@DemoRecorder.com> Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2 Patch-Set: ListInputDevices Patch-Number: libxcb 3/9 Patch-Version: V3
2014-11-03generator: fix absname for fields with only accessor functionChristian Linhart1-12/+52
Fix _c_helper_absolute_name for fields which cannot be accessed as a struct/union member but which can be accessed by an accessor function. The fix generates calls to the accessor function in these cases. Example: <struct name="AbsnameTest"> <field type="CARD32" name="len" /> <list type="CARD8" name="mylist1"> <fieldref>len</fieldref> </list> <list type="CARD8" name="mylist2"> <sumof ref="mylist1"/> </list> </struct> The sumof-expression ( <sumof ref="mylist1"/> ) refers to mylist1 which is only acessible by an accessor function. Previously, sumof was only used inside bitcases, where such lists are accessible by members of the deserialized parent struct. (there is a difference between deserialization of switches and structs.) V2 of this patch: * replaced "!= None" with "is not None" because that's more pythonic. (according to suggestion from Ran Benita) V3 of this patch: simplification: * fixed the recursion in _c_type_setup so that _c_helper_absolute_name does not need check a gazillion things as a workaround anymore. * simplified _c_helper_absolute_name - remove unneeded check for empty string before append of last_sep to prefix_str - removed those if-conditions which are not needed anymore after fixing the recursion in _c_type_setup. - extract functionality for checking whether a field needs an accessor ( and which type of accessor ) in functions. (also extracted from _c_accessors) - rearrange the condition branches and actions for more readability. V3 generates exactly the same *.c and *.h files as V2. V4 of this patch: * improve formatting as per suggestions of Ran Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-by: Ran Benita <ran234@gmail.com> Message-ID: <54562758.5090107@DemoRecorder.com> Patch-Thread-Subject: [Xcb] [PATCHSET] ListInputDevices revision 2 Patch-Set: ListInputDevices Patch-Number: libxcb 1/9 Patch-Version: V4
2014-10-30Merge branch 'NestedStructTypenames-V5' of ↵Peter Harris1-11/+41
http://infra-srv1.demorecorder.com/git/free-sw/xcb/libxcb
2014-10-20no typename for nested structsChristian Linhart1-1/+1
Nested structs which are generated for named case and bitcase do not get a typename anymore, i.e., they are anonymous structs. Reasons for this change: * Prior typenames have caused nameclashes * Prior typenames introduced names in the global namespace which did not start with the xcb prefix. This change is safe with respect to API compatibility because: I have searched for instances of named bitcases and there's only one place where they are used, and that's in xkb.xml: reply GetKbdByName. ( no need to search for <case> because it was introduced after the last release ) The reply GetKbdByName is broken in its current form in the xkb.xml anyways, so it is most probably not used anywhere. So, my conclusion is that we can safely omit named types for nested structs. No need for an attribute. Message-ID: <1409731849-51897-1-git-send-email-chris@demorecorder.com> Patch-Thread-Subject: Re: [Xcb] names of nested structs of named bitcase/case are prone to nameclashes. Solution? Patch-Set: NestedStructTypenames Patch-Number: libxcb 1/1 Patch-Version: V1 Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-By: Ran Benita <ran234@gmail.com>
2014-10-20generator: fix align-pads for switches which start at unaligned posChristian Linhart1-5/+21
Fix the alignment computation inside switches which start at an unaligned pos. This affects both explicit and implicit align pads. The alignment offset is derived from the lowest 3 bits of the pointer to the protocol-data at the start of the switch. This is sufficient for correcting all alignments up to 8-byte alignment. As far as I know there is no bigger alignment than 8-byte for the X-protocol. Example: struct InputState, where the switch starts after two 1-byte fields, which is a 2 byte offset for 4-byte and 8-byte alignment. The previous problem can be demonstrated when adding a <pad align="4"/> at the end of case "key". (Or when finding a testcase which reports the case "valuator" not at the last position of the QueryDeviceState-reply. I didn't find such a testcase, so I have used the pad align as described above.) V2: patch modified in order to fix bugs which I found when working on the next issue: * xcb_padding_offset has to be set 0 when xcb_block_len is set 0 * xcb_padding_offset cannot be "const" therefore * for unpack and unserialize, the padding_offset must computed from _buffer instead of from the aux_var. V3: patch revised according to suggestion by Ran Benita: * only create and use xcb_padding_offset for switch Message-ID: <1410298000-24734-1-git-send-email-chris@demorecorder.com> Patch-Thread-Subject: [Xcb] xinput:QueryDeviceState: full-support: generator and xml-changes Patch-Set: QueryDeviceState Patch-Number: libxcb 4/4 Patch-Version: V3 Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-By: Ran Benita <ran234@gmail.com>
2014-10-20generator: support lists of structs which contain a switchChristian Linhart1-2/+12
This essentially requires to have a correct sizeof-function for the struct. This in turn requires a sizeof-function for the switch, too. Making a sizeof-function for the switch is triggered by replacing "elif" by "if" in the first change of this patch. This way, c_need_sizeof is also set to True for switches if appropriate. The _c_serialize_helper_switch_field function has to support the context "sizeof": This is done in the second change of this patch The third change of this patch fixes an alignment error: It does not make sense to base the padding on the struct-type which is generated for switch because this struct does not represent the protocol. Rather it is the output of deserialization. ( The implicit padding for var-sized fields has other issues, IMHO, but I am not touching these now...) The effect on the generated code for the current xml-files is as follows: * several additional sizeof-functions are generated * the fix of the alignment error only changes one place in the XKB-extension for the GetKbdByName-reply. This is no problem because that reply in its current form is broken/unfinished anyways. Note: This patch also fixes a problem in the generator when a fixed-size list is the last field of a case or bitcase. Message-ID: <1408653356-21191-2-git-send-email-chris@demorecorder.com> Patch-Thread-Subject: [Xcb] xinput:QueryDeviceState: full-support: generator and xml-changes Patch-Set: QueryDeviceState Patch-Number: libxcb 2/3 Patch-Version: V1 Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-By: Ran Benita <ran234@gmail.com>
2014-10-03Move internal/private dependencies to Requires.privateEmil Velikov27-28/+28
Program using the xcb sub-modules has indirect compile and runtime dependency of core xcb. To ensure this out we currently list xcb in the Requires field of the pkg-config files. While this provides all the required dependencies for successful compilation this causes over-linking and hides potential linking miss-use against the xcb modules. By moving to Requires.private we retain the compilation and runtime compatibility and avoids any runtime problems. Cc: Keith Packard <keithp@keithp.com> Cc: Alan Coopersmith <alan.coopersmith@oracle.com> References: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq References: https://wiki.mageia.org/en/Overlinking_issues_in_packaging References: http://err.no/personal/blog/2008/Mar/25 Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Uli Schlachter <psychon@znc.in>
2014-09-09generator: support fixed size lists in var-sized structsChristian Linhart1-3/+7
V2: patch revised according to suggestions from Ran Benita: * removed blanks before an after parentheses of function-calls or tuples * replaced if by elif in "if field.type.is_list". ( this fixes old code ) Message-ID: <540B4D17.1080908@DemoRecorder.com> Patch-Thread-Subject: [Xcb] xinput:QueryDeviceState: full-support: generator and xml-changes Patch-Set: QueryDeviceState Patch-Number: libxcb 1/3 Patch-Version: V2 Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-By: Ran Benita <ran234@gmail.com>