No subject

driver (like you've outlined in the patch below), we then need to get this
information into the X server so that the server doesn't repeat. XKB has a
per-key-repeat flag which we may be able to use but we need to also override
client-side key repeat setting (for this device only). XKB doesn't allow for
a repeat rate change request to fail, so we have to essentially tell client
they have succeeded in setting their repeat rate while using a completely
different one.
Technically, you can override the repeat setting requested by the client
if you simply send out an event when you change it back to the hardware
setting. This then looks like some other client has changed it but the
danger is that it may send stubborn clients into an infinite loop.

How much that really matters I don't know.

Letting clients know which device is an RC control at least means that the
overriding should be expected, but that brings us back to the labelling
issue.

But either way, to even get this to the "override" stage you need three
patches:
- evdev: recognise and flag the devices
- X server: introduce an API to pass this information on to the server
- X server: fixes to the XKB system to disable autorepeat for devices
  flagged accordingly and override requests to change the repeat rate.

Cheers,
  Peter