On Fri, Jun 09, 2017 at 01:39:53PM +0200, Michal Suchánek wrote:

On Thu, 8 Jun 2017 16:18:28 -0700
Dmitry Torokhov [off-list ref] wrote:

quoted

On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
[off-list ref] wrote:

quoted

On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote:  

quoted

This is what evtest reports about my keyboard:

Select the device event number [0-12]: 2
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111
Input device name: "DELL Dell USB Entry Keyboard"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 1 (KEY_ESC)
    Event code 2 (KEY_1)
    Event code 3 (KEY_2)
    Event code 4 (KEY_3)
...
    Event code 193 (KEY_F23)
    Event code 194 (KEY_F24)
    Event code 240 (KEY_UNKNOWN)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
  Event type 17 (EV_LED)
    Event code 0 (LED_NUML) state 1
    Event code 1 (LED_CAPSL) state 0
    Event code 2 (LED_SCROLLL) state 0
    Event code 3 (LED_COMPOSE) state 0
    Event code 4 (LED_KANA) state 0
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    250
    Repeat code 1 (REP_PERIOD)
      Value     33
Properties:  

looks like it's not tagged as ID_INPUT_MOUSE by the default udev
rules because for that we need x/y axes (either relative for real
mice or absolute ones for the VMWare USB mouse). This keyboard only
has buttons though. So it gets ID_INPUT_KEYBOARD for the keys, but
no ID_INPUT_MOUSE.

Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard"
but the few pictures I can find all point to a keyboard that
doesn't have any physical mouse buttons at all. Does yours have
buttons? Can you post a picture of it somewhere?
 

Michal is using udev/hwdb to replace some of the keys on his keyboard
to generate BTN_RIGHT/BTN_MIDDLE trying to achive the same end result
as with mac_hid. It is not the default keyboard behavior. Having
another custom udev rule to mark the device as ID_INPUT_MOUSE is a
fair requirement in this case I think.

Which is done in different place, and uses device matching with
completely different patterns. So for this to work reasonably either

 - all devices should have all capabilities by default
 - the capabilities should be detected based on the events actually
   available on the device

And if my keyboard actually claimed to have relative axis because of
some great firmware engineering on the manufacturer's part and I found
how to remove them in hwdb it would not take effect either.

https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in
calls input-id which sets the ID_INPUT_* tags. If you modify the
capabilities after that happens, you need to call input-id again to get
updated udev properties.

There is no kernel facility to handle devices that change capabilities at
runtime. We discussed this a short while ago (search for SYN_CONFIG) but
it's ... tricky.

Cheers,
   Peter