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

On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Such=C3=A1nek 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 absol=

ute

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.

--=20
Dmitry