Skip to content

Split interfaces into pointer/absolute/scroll/button and drop capabilities

Peter Hutterer requested to merge whot/libei:wip/interfaces-as-capabilities into main

Split the ei_pointer protocol interface into ei_pointer, ei_pointer_absolute, ei_scroll and ei_button.

This gets rid of the slightly awkward pointer vs pointer absolute handling. Those were two different capabilities but tied to the same interface in the protocol.

Then use that split to get rid of the capabilities enum.

Previously we had ei_seat.capabilities and ei_device.capabilities, both referring to the same enum. The seat caps were used to bind, the device caps were used to announce capabilities.

The device caps were already mostly superfluous as the information they carried was implicitly available by the set of interfaces the device announced - if the device has a keyboard interface it must also have the keyboard capability.

So let's drop the separate enum and make the capabilities the set of supported interfaces. In the device we can drop the event directly and just send the interface list. In the seat we have a capability event that sends each possible interface with a custom-assigned mask. The client can then use that mask to bind to the capability as before.

For example:

   <- ei_seat.capability(0x1, "ei_pointer")
   <- ei_seat.capability(0x4, "ei_keyboard")
   <- ei_seat.capability(0x8, "ei_touchscreen")
   <- ei_seat.done()
   -> ei_seat.bind(0x4 | 0x8)  # bind to keyboard and touchscreen
   <- ei_seat.device()
   -> ei_device.interface("ei_keyboard")
   -> ei_device.interface("ei_touchscreen")
   <- ei_device.done()

In the generated bindings we simply use the interface index to generate the masks, but the protocol at least states that the mask may not be constant.

Because the button/scroll interfaces are not exposed by the C API, some of the handling is a bit awkward since we need to use both depending whether we have pointer/pointer_absolute selected.

Fixes #28 (closed)

This is the last big protocol change that I had in mind. Once this is in we should be able to make the API and protocol stable.

cc @jadahl

Merge request reports