On Thu, 8 Jun 2017 16:18:28 -0700 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer > <peter.hutterer@xxxxxxxxx> wrote: > > On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote: > >> 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. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
