Different tablet behaviors of compositors

I've recently implemented tablet support in my compositor and I looked at how other compositors behave. I found that there are significant differences between compositors. The protocol explicitly states that some behaviors are compositor specific so these are not bugs. But it might still be useful to try to make them more similar/to clarify the protocol to ensure a consistent user and app developer experience.

Also keep in mind that I have not looked at the source code of other implementations and my description of their behavior might be inaccurate.

Tablet Pads

My implementation

• Each tablet pad has an associated surface (possibly null).
• Whenever this surfaces changes, leave and enter events are sent.
• If no button is pressed, this surface is identical to the surface that has the keyboard focus.
• While any button is pressed, the pad's surface holds a grab of the pad. All pad events will be sent to that surface until all buttons are released.
• There are no unpaired button events (this follows from the grab.)

Sway and GNOME

• Tablet pad events are always sent to the surface that has the keyboard focus.
• Whenever this surface changes, leave and enter events are sent.
• Unpaired button events are sent to surfaces if a button was already pressed when the keyboard focus changed.

KDE

Almost the same as Sway and GNOME except that

• leave and enter events are generated lazily (only when a button event has to be sent to a surface that is not currently entered)

Tablet Tools

My implementation

• Button-down events cause the surface to grab the tool. All tool events will be sent to that surface until all buttons have been released.
• For this purpose, tip-down events behave just like another button (they also create a grab.)
• There are no unpaired tip-up/button-up events (this follows from the grab.)

Sway

• Tip-down creates a grab.
• Tip-down grabs can be broken by pressing a button twice while outside the grab surface. Pressing a button once causes some intermediate state that I did not fully understand.
• Button-down does not create a grab.
• There are no unpaired tip-up/button-up events.

GNOME

• Tip-down creates a grab.
• The tip-down grab can be broken by pressing a button while outside the grab surface.
• Button-down creates a grab.
• It's unclear if a tip-down outside a surface breaks a button-down grab. The behavior seemed buggy.

KDE

• There are no grabs whatsoever. If a tool leaves a surface, a proximity-out event is generated immediately regardless of whether the tip/a button is down.
• If the tool leaves a surface while the tip/a button is down, no corresponding up event is generated before the proximity-out event.
• If a tool enters a surface while the tip/a button is down, an unpaired up event is generated when the tip/the button is lifted.