[Xcb] proposal: events used in requests ( xinput:SendExtensionEvent, xproto:SendEvent, ... )

[Christian Linhart]

Hi all,

The only thing that is still missing for complete XInput coverage in my patches
is request SendExtensionEvent which contains a list of events.

In theory this could be defined with lots of code-duplication in xinput.xml
by redefining all XInput1-events in form of a huge switch-case in a struct
but that would neither be good nor elegant.

Therefore I propose to support that in the generator.

Here's my proposal:

Provide a way to define a struct which can be any event from a
given list of events.

This could look like.

<eventstruct name="EventForSend">
	<allowed extension="xinput" xge="false" opcode-min="0" opcode-max="16" />
</eventstruct>

This defines a struct-type which can hold one event of a type which matches any of the <allowed/> - rules.
In the example above it can contain any non-xge event with opcodes 0 to 16 from the xinput-extension.
( extension="xproto" would refer to core-protocol events. This could be used in the definition of core-request "SendEvent" )

An eventstruct can contain multiple <allowed/> - rules.

Request SendExtensionEvent can then be defined as follows:

    <request name="SendExtensionEvent" opcode="31">
        <field type="WINDOW" name="destination" />
        <field type="CARD8"  name="device_id" />
        <field type="BOOL"   name="propagate" />
        <field type="CARD16" name="num_classes" />
        <field type="CARD8"  name="num_events" />
        <pad bytes="3" />
        <list type="EventForSend" name="events">
            <fieldref>num_events</fieldref>
        </list>
        <list type="EventClass" name="classes">
            <fieldref>num_classes</fieldref>
        </list>
    </request>


The generated C-code for an eventstruct could be as follows:
* eventstruct is represented by a union which contains a type-field and a member for each allowed type of event.
* if an eventstruct is allowed to contain xge-events then it is a var-sized type, otherwise a fixed-sized type.
  ( with all consequences of either of that... )


In the example above the union could look like:

    typedef union xcb_input_event_for_send_t{
            uint8_t                                  response_type;
            xcb_input_device_valuator_event_t        device_valuator;
            xcb_input_device_key_press_event_t       device_key_press;
            xcb_input_device_key_press_event_t       device_key_release;
	    ...
            xcb_input_device_property_notify_event_t device_property_notify;
    } xcb_input_event_for_send_t;


If it may contain xge-events then it will contain a member xge-header as follows:

    typedef union xcb_input_foo_t{
	uint8_t response_type;
	struct{
            uint8_t               response_type; /**<  */
            uint8_t               extension; /**<  */
            uint16_t              sequence; /**<  */
            uint32_t              length; /**<  */
            uint16_t              event_type; /**<  */
	} xge_header;
	xcb_input_raw_touch_begin_event_t raw_touch_begin;
	...

or instead of nested struct xge_header it may simply contain a member of type xcb_ge_generic_event_t:

    typedef union xcb_input_foo_t{
	uint8_t response_type;
        xcb_ge_generic_event_t xge;
	xcb_input_raw_touch_begin_event_t raw_touch_begin;
	...

***

In think that adding support for that in the parser/generator will be pretty straightforward.

***

What do you think about this proposal?

Chris