1. 16 Oct, 2022 1 commit
  2. 20 Sep, 2021 1 commit
  3. 30 Jul, 2021 4 commits
  4. 07 Jan, 2019 1 commit
  5. 05 Jun, 2017 2 commits
  6. 11 Mar, 2017 2 commits
  7. 28 May, 2016 1 commit
  8. 01 Feb, 2016 1 commit
  9. 06 Jan, 2016 3 commits
  10. 13 Aug, 2015 1 commit
  11. 04 Jul, 2015 1 commit
  12. 12 Jun, 2015 1 commit
  13. 30 May, 2015 2 commits
  14. 15 Mar, 2015 16 commits
  15. 22 Feb, 2015 1 commit
    • Jaya Tiwari's avatar
      Adding accessors for requests · e3ec1f74
      Jaya Tiwari authored and Christian Linhart's avatar Christian Linhart committed
      
      
      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: default avatarJaya Tiwari <tiwari.jaya18@gmail.com>
      Reviewed-by: Christian Linhart's avatarChristian 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.
      e3ec1f74
  16. 03 Nov, 2014 2 commits
    • Christian Linhart's avatar
      generator: support parametrized structs · c6f3fb25
      Christian Linhart authored and Christian Linhart's avatar Christian Linhart committed
      
      
      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's avatarChristian Linhart <chris@DemoRecorder.com>
      c6f3fb25
    • Christian Linhart's avatar
      generator: support listelement-ref · 912cd97a
      Christian Linhart authored and Christian Linhart's avatar Christian Linhart committed
      
      
      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's avatarChristian Linhart <chris@DemoRecorder.com>
      912cd97a