mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Peter Hutterer <peter.hutterer@who-t.net>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [PATCH] macintosh: move mac_hid driver to input/mouse.
Date: Mon, 12 Jun 2017 15:27:33 +0200	[thread overview]
Message-ID: <20170612152733.1a14dbd7@kitsune.suse.cz> (raw)
In-Reply-To: <20170612134007.2e5e2772@kitsune.suse.cz>

On Mon, 12 Jun 2017 13:40:07 +0200
Michal Suchánek <msuchanek@suse.de> wrote:

> On Sat, 10 Jun 2017 12:00:22 +1000
> Peter Hutterer <peter.hutterer@who-t.net> wrote:
> 
> > 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 <dmitry.torokhov@gmail.com> wrote:
> > >     
> > > > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > > > <peter.hutterer@who-t.net> 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.    
> > 
> > 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.  
> 
> rules/50-udev-default.rules.in:SUBSYSTEM=="usb",
> ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id",
> IMPORT{builtin}="hwdb --subsystem=usb"
> rules/50-udev-default.rules.in:SUBSYSTEM=="input", ENV{ID_INPUT}=="",
> IMPORT{builtin}="input_id"
> rules/50-udev-default.rules.in:ENV{MODALIAS}!="",
> IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
> rules/60-evdev.rules:IMPORT{builtin}="hwdb --subsystem=input
> --lookup-prefix=evdev:", \
> rules/60-evdev.rules:ENV{ID_INPUT_KEY}=="?*", DRIVERS=="atkbd", \
> rules/60-evdev.rules:  IMPORT{builtin}="hwdb
> 'evdev:atkbd:$attr{[dmi/id]modalias}'", \
> rules/60-evdev.rules:KERNELS=="input*", IMPORT{builtin}="hwdb
> 'evdev:name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]modalias}'",
> \ rules/60-evdev.rules:KERNELS=="input*", IMPORT{builtin}="hwdb
> 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
> rules/60-persistent-input.rules:ENV{ID_INPUT_KEYBOARD}=="?*",
> ENV{.INPUT_CLASS}="kbd"
> rules/60-persistent-input.rules:ENV{ID_INPUT_MOUSE}=="?*",
> ENV{.INPUT_CLASS}="mouse"
> rules/60-persistent-input.rules:ENV{ID_INPUT_TOUCHPAD}=="?*",
> ENV{.INPUT_CLASS}="mouse"
> rules/60-persistent-input.rules:ENV{ID_INPUT_TABLET}=="?*",
> ENV{.INPUT_CLASS}="mouse"
> rules/60-persistent-input.rules:ENV{ID_INPUT_JOYSTICK}=="?*",
> ENV{.INPUT_CLASS}="joystick" rules/60-sensor.rules:
> IMPORT{builtin}="hwdb
> 'sensor:modalias:$attr{modalias}:$attr{[dmi/id]modalias}'", \
> rules/60-sensor.rules:SUBSYSTEM=="input",
> ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="acpi", \
> rules/60-sensor.rules:  IMPORT{builtin}="hwdb
> 'sensor:modalias:acpi:$attr{hid}:$attr{[dmi/id]modalias}'", \
> rules/60-sensor.rules:SUBSYSTEM=="input",
> ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="platform", \
> rules/60-sensor.rules:  IMPORT{builtin}="hwdb
> 'sensor:modalias:platform:$id:$attr{[dmi/id]modalias}'", \
> rules/70-mouse.rules:ENV{ID_INPUT_MOUSE}=="", GOTO="mouse_end"
> rules/70-mouse.rules:        IMPORT{builtin}="hwdb
> 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'",
> \ rules/70-mouse.rules:        IMPORT{builtin}="hwdb
> 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'",
> \ rules/70-mouse.rules:        IMPORT{builtin}="hwdb
> 'mouse:ps2::name:$attr{device/name}:'", \
> rules/70-touchpad.rules:ENV{ID_INPUT}=="", GOTO="touchpad_end"
> rules/70-touchpad.rules:ENV{ID_INPUT_TOUCHPAD}=="",
> GOTO="touchpad_end" rules/70-touchpad.rules:
> IMPORT{builtin}="hwdb
> 'touchpad:$env{ID_BUS}: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.

Oh man, there is no end of special-casing. 

When I assign a device
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_INPUT_MOUSE=1
it gets keyboard and pointer capabilities. When I replace
ID_INPUT_MOUSE with ID_INPUT_TABLET_PAD which would be logical class
for device with buttons and no axis it gets tablet-pad capability but
loses keyboard capability. I suppose this is not documented anywhere,
right? ID_INPUT_TABLET* actually means ID_INPUT_WACOM_TABLET* and will
not work for non-wacom devices.

Is there no support for non-wacom tablets?

Thanks

Michal

> 

      reply	other threads:[~2017-06-12 13:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-09 19:14 Michal Suchanek
2017-05-10  0:43 ` Dmitry Torokhov
2017-05-10 10:44   ` Michal Suchánek
2017-05-28  9:47   ` Michal Suchanek
2017-05-28 13:26     ` Bastien Nocera
2017-05-28 17:55     ` Dmitry Torokhov
2017-05-29 18:03       ` Michal Suchánek
2017-05-30  5:06         ` Dmitry Torokhov
2017-05-30  9:34           ` Michal Suchánek
2017-05-30 10:33             ` Benjamin Tissoires
2017-05-30 11:32               ` Michal Suchánek
2017-05-30 12:02                 ` Benjamin Tissoires
2017-05-30 12:56                   ` Michal Suchánek
2017-05-31  4:26                     ` Peter Hutterer
2017-06-07 12:29                       ` Michal Suchánek
2017-06-07 16:53       ` Michal Suchánek
2017-06-07 17:16         ` Dmitry Torokhov
2017-06-07 19:17           ` Michal Suchánek
2017-06-07 23:13             ` Peter Hutterer
2017-06-08 13:18               ` Michal Suchánek
2017-06-08 23:07                 ` Peter Hutterer
2017-06-08 23:18                   ` Dmitry Torokhov
2017-06-09 11:39                     ` Michal Suchánek
2017-06-10  2:00                       ` Peter Hutterer
2017-06-12 11:40                         ` Michal Suchánek
2017-06-12 13:27                           ` Michal Suchánek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170612152733.1a14dbd7@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=peter.hutterer@who-t.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®