Hide ABS (especially multitouch) events

[agoode]

The keyboard exposes a huge number of irrelevant events. Here are a few:

    Event code 47 (ABS_MT_SLOT)
    Event code 48 (ABS_MT_TOUCH_MAJOR)
    Event code 49 (ABS_MT_TOUCH_MINOR)
    Event code 50 (ABS_MT_WIDTH_MAJOR)
    Event code 51 (ABS_MT_WIDTH_MINOR)
    Event code 52 (ABS_MT_ORIENTATION)
    Event code 53 (ABS_MT_POSITION_X)
    Event code 54 (ABS_MT_POSITION_Y)
    Event code 55 (ABS_MT_TOOL_TYPE)
    Event code 56 (ABS_MT_BLOB_ID)
    Event code 57 (ABS_MT_TRACKING_ID)
    Event code 58 (ABS_MT_PRESSURE)
    Event code 59 (ABS_MT_DISTANCE)
    Event code 60 (ABS_MT_TOOL_X)
    Event code 61 (ABS_MT_TOOL_Y)
    Event code 62 (?)
    Event code 63 (?)

The problem is that Chrome OS gets confused by the multitouch events and needs some special workarounds: https://code.google.com/p/chromium/issues/detail?id=430319

To cleanly fix this, it would be better to just not expose the EV_ABS events to userspace. I don't think they can ever be generated by the device anyway.

[lentinj]

The reason these are here is because the HID usage descriptor table mentions that they could come back. Lenovo/Chicony have just left a huge heap of events in there, presumably because they apply to some devices and it's faster for them to just re-use the usage table and not write it for the particular device.

Now the table (which is just a binary blob an input device sends to the OS when initalizing) can be rewritten, and we'll have to when fixing the horizontal scroll wheel events. However, I'm loath to hard-code too much of the table into Linux, because there may be multiple revisions with a different usage table that we might break by using a hard-coded table / binary patching.

Also, Lenovo/Chicony's attitude to the usage descriptor table is very common IME, so whilst hard-coding more of the usage table would stop Chrome OS getting confused, this is bound to be a problem again with some other HID input device.

[lentinj]

Actually, you don't need to modify the table to ignore these events, it's really easy, and much safer, to do this from input_mapping. These keyboards are unlikely to become touchscreen devices any time soon, so no harm in filtering them.

I still think that Chrome OS will need to cope with misleading usage descriptors generally though.