wl_seat v10 with compositor key repeat

[dcz-self]

This adds compositor-side key repeat from the just released wl_keyboard v10.

There are some problems:

1. Repeat events have the same serial
2. Filtering may be broken
3. Arming the repeat timeout is ugly

With the above in mind, I'm not sure if I plugged it in the correct place, so I'm marking this as a draft.

[dcz-self]

I fixed the serial generation by pushing the logic up a bit, close to where the backend receives the event.

The events go now like:

1. comp: Backend
2. smithay: Repeat registration -> transforms backend event into generic event, adds Repeated
3. comp (via callback): event handler
4. comp: filtering -> adds Serial
5. comp: forwarding
6. smithay: normal client handling

This means the repeating is global to the seat: switch from one client to the other and repeating continues. If repeating was per-client, then the compositor itself would not receive repeat events without making it look like a client (and I'm not ready for that level of rearchitecting). The good news is I think feels more natural :) The bad news is corner cases when switching because a Repeated event may not appear without a Pressed event according to wl_keyboard:

The key may only enter the repeated state after entering the pressed
state and before entering the released state.

I haven't tried to add those corner cases yet.

EDIT: I read the spec more carefully and this is not needed.

Does this design look right?

[dcz-self]

This still relies on unreleased wayland-rs, but I copleted and undrafted it to reflect my confidence.

[PolyMeilex]

wayland_protocols_experimental is now up on crates.io
wayland_rs is now up on crates.io

[dcz-self]

Updated, now using all upstream.

[dcz-self]

Bump - this is pretty solid I think.
It would make Smithay the first library supporting the key repeat, as far as I can tell.

[dcz-self]

Is there anything I can do to push this forward?

[PolyMeilex]

@Drakulix Could you take a look as well? I don't feel confident with merging this without a second opinion.

[dcz-self]

Rebased.

[dcz-self]

Updated to fix a failing pipeline.
The other failing pipelines seem to be the same on master, and I don't even know how to start fixing them.

[dcz-self]

Copying from Matrix the eplanation about why there are compositor-side API changes:

TL;DR: I don't think this should be transparent. That would mean forcing a design choice on downstreams

EventLoop is not the main reason for changing the downstream code. The main reason is the relationship between repeating and consuming events.
Right now, without repeat, when the compositor eats a buttondown event because it triggers some action, that event will not trigger repeating. That means two things: holding a button doesn't retrigger a compositor action, and after triggering and finishing a compositor action, the active application won't get repeats.
An alternative is to plug in repeats earlier, and have the compositor be able to trigger internal actions also on repeats.
Because there is no automatically right answer here, I decided to not hardcode it in smithay, but let the compositor author choose the behaviour. In anvil, I implemented the alternative pipeline with repeats before internal events.
Choosing behaviour is not transparent, so you get to call key_register_repeat and key_stop_repeat explicitly.
This is the real reason stuff shifted around: if I can reconstruct this correctly, process_key_event_windowed had to be separated from general event processing because it's now a callback that gets triggered on repeat.

[dcz-self]

Is there anything I can do to push this forward?