Re: [PATCH] macintosh: move mac_hid driver to input/mouse.

On Sat, 10 Jun 2017 12:00:22 +1000
Peter Hutterer [off-list ref] wrote:

On Fri, Jun 09, 2017 at 01:39:53PM +0200, Michal Such=C3=A1nek wrote:

quoted

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

quoted

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

quoted

On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Such=C3=A1nek
wrote:   =20

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:   =20

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?
  =20

=20
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

=20
Which is done in different place, and uses device matching with
completely different patterns. So for this to work reasonably either
=20
 - all devices should have all capabilities by default
 - the capabilities should be detected based on the events actually
   available on the device
=20
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. =20

=20
https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rule=

s.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.

rules/50-udev-default.rules.in:SUBSYSTEM=3D=3D"usb", ENV{DEVTYPE}=3D=3D"usb=
_device", IMPORT{builtin}=3D"usb_id", IMPORT{builtin}=3D"hwdb --subsystem=
=3Dusb"
rules/50-udev-default.rules.in:SUBSYSTEM=3D=3D"input", ENV{ID_INPUT}=3D=3D"=
", IMPORT{builtin}=3D"input_id"
rules/50-udev-default.rules.in:ENV{MODALIAS}!=3D"", IMPORT{builtin}=3D"hwdb=
 --subsystem=3D$env{SUBSYSTEM}"
rules/60-evdev.rules:IMPORT{builtin}=3D"hwdb --subsystem=3Dinput --lookup-p=
refix=3Devdev:", \
rules/60-evdev.rules:ENV{ID_INPUT_KEY}=3D=3D"?*", DRIVERS=3D=3D"atkbd", \
rules/60-evdev.rules:  IMPORT{builtin}=3D"hwdb 'evdev:atkbd:$attr{[dmi/id]m=
odalias}'", \
rules/60-evdev.rules:KERNELS=3D=3D"input*", IMPORT{builtin}=3D"hwdb 'evdev:=
name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]m=
odalias}'", \
rules/60-evdev.rules:KERNELS=3D=3D"input*", IMPORT{builtin}=3D"hwdb 'evdev:=
name:$attr{name}:$attr{[dmi/id]modalias}'", \
rules/60-persistent-input.rules:ENV{ID_INPUT_KEYBOARD}=3D=3D"?*", ENV{.INPU=
T_CLASS}=3D"kbd"
rules/60-persistent-input.rules:ENV{ID_INPUT_MOUSE}=3D=3D"?*", ENV{.INPUT_C=
LASS}=3D"mouse"
rules/60-persistent-input.rules:ENV{ID_INPUT_TOUCHPAD}=3D=3D"?*", ENV{.INPU=
T_CLASS}=3D"mouse"
rules/60-persistent-input.rules:ENV{ID_INPUT_TABLET}=3D=3D"?*", ENV{.INPUT_=
CLASS}=3D"mouse"
rules/60-persistent-input.rules:ENV{ID_INPUT_JOYSTICK}=3D=3D"?*", ENV{.INPU=
T_CLASS}=3D"joystick"
rules/60-sensor.rules:  IMPORT{builtin}=3D"hwdb 'sensor:modalias:$attr{moda=
lias}:$attr{[dmi/id]modalias}'", \
rules/60-sensor.rules:SUBSYSTEM=3D=3D"input", ENV{ID_INPUT_ACCELEROMETER}=
=3D=3D"1", SUBSYSTEMS=3D=3D"acpi", \
rules/60-sensor.rules:  IMPORT{builtin}=3D"hwdb 'sensor:modalias:acpi:$attr=
{hid}:$attr{[dmi/id]modalias}'", \
rules/60-sensor.rules:SUBSYSTEM=3D=3D"input", ENV{ID_INPUT_ACCELEROMETER}=
=3D=3D"1", SUBSYSTEMS=3D=3D"platform", \
rules/60-sensor.rules:  IMPORT{builtin}=3D"hwdb 'sensor:modalias:platform:$=
id:$attr{[dmi/id]modalias}'", \
rules/70-mouse.rules:ENV{ID_INPUT_MOUSE}=3D=3D"", GOTO=3D"mouse_end"
rules/70-mouse.rules:        IMPORT{builtin}=3D"hwdb 'mouse:$env{ID_BUS}:v$=
attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \
rules/70-mouse.rules:        IMPORT{builtin}=3D"hwdb 'mouse:$env{ID_BUS}:v$=
attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \
rules/70-mouse.rules:        IMPORT{builtin}=3D"hwdb 'mouse:ps2::name:$attr=
{device/name}:'", \
rules/70-touchpad.rules:ENV{ID_INPUT}=3D=3D"", GOTO=3D"touchpad_end"
rules/70-touchpad.rules:ENV{ID_INPUT_TOUCHPAD}=3D=3D"", GOTO=3D"touchpad_en=
d"
rules/70-touchpad.rules:        IMPORT{builtin}=3D"hwdb 'touchpad:$env{ID_B=
US}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \

Looking at the occurences of hwdb and ID_INPUT moving the call to
input_id from rules/50-udev-default.rules to a
separate file 60-input-id.rules would make it possible to put fixups in
60-evdev.rules hwdb calls and the 60-persistent-input.rules that depend
on the settings would come after as well as the mouse and
touchpad-specific rules.

=20
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.

I do not really want to change capabilities at any random moment. I
want the capabilities set up at add time. Presumably re-triggering the
device with udevadm will make it possible to update the capabilities
for devices that are built-in or impractical to remove.

Thanks

Michal