macintosh: move mac_hid driver to input/mouse.

Commit Message

Michal Suchánek May 9, 2017, 7:14 p.m. UTC

There is nothing mac-specific about this driver. Non-mac hardware with
suboptimal built-in pointer devices exists.

This makes it possible to use this emulation not only on x86 and ppc
notebooks but also on arm and mips.

Signed-off-by: Michal Suchanek <[e-mail]>
---
 drivers/input/mouse/Kconfig                  | 20 ++++++++++++++++++++
 drivers/input/mouse/Makefile                 |  1 +
 drivers/{macintosh => input/mouse}/mac_hid.c |  0
 drivers/macintosh/Kconfig                    | 17 -----------------
 drivers/macintosh/Makefile                   |  1 -
 5 files changed, 21 insertions(+), 18 deletions(-)
 rename drivers/{macintosh => input/mouse}/mac_hid.c (100%)

Comments

Dmitry Torokhov May 10, 2017, 12:43 a.m. UTC | #1

Hi Michal,

On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:
> There is nothing mac-specific about this driver. Non-mac hardware with
> suboptimal built-in pointer devices exists.
> 
> This makes it possible to use this emulation not only on x86 and ppc
> notebooks but also on arm and mips.

I'd rather we did not promote from drivers/macintosh to other platforms,
but rather removed it. The same functionality can be done from
userspace.

What hardware do you believe would benefit from this and why?

Thanks.

> 
> Signed-off-by: Michal Suchanek <[e-mail]>
> ---
>  drivers/input/mouse/Kconfig                  | 20 ++++++++++++++++++++
>  drivers/input/mouse/Makefile                 |  1 +
>  drivers/{macintosh => input/mouse}/mac_hid.c |  0
>  drivers/macintosh/Kconfig                    | 17 -----------------
>  drivers/macintosh/Makefile                   |  1 -
>  5 files changed, 21 insertions(+), 18 deletions(-)
>  rename drivers/{macintosh => input/mouse}/mac_hid.c (100%)
> 
> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
> index 89ebb8f39fee..5533fd3a113f 100644
> --- a/drivers/input/mouse/Kconfig
> +++ b/drivers/input/mouse/Kconfig
> @@ -12,6 +12,26 @@ menuconfig INPUT_MOUSE
>  
>  if INPUT_MOUSE
>  
> +config MAC_EMUMOUSEBTN
> +	tristate "Support for mouse button 2+3 emulation"
> +	depends on SYSCTL && INPUT
> +	help
> +	  This provides generic support for emulating the 2nd and 3rd mouse
> +	  button with keypresses.  If you say Y here, the emulation is still
> +	  disabled by default.  The emulation is controlled by these sysctl
> +	  entries:
> +	  /proc/sys/dev/mac_hid/mouse_button_emulation
> +	  /proc/sys/dev/mac_hid/mouse_button2_keycode
> +	  /proc/sys/dev/mac_hid/mouse_button3_keycode
> +
> +	  If you have an Apple machine with a 1-button mouse, say Y here.
> +
> +	  This emulation can be useful on notebooks with suboptimal touchpad
> +	  hardware as well.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called mac_hid.
> +
>  config MOUSE_PS2
>  	tristate "PS/2 mouse"
>  	default y
> diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
> index 56bf0ad877c6..dfaad1dd8857 100644
> --- a/drivers/input/mouse/Makefile
> +++ b/drivers/input/mouse/Makefile
> @@ -4,6 +4,7 @@
>  
>  # Each configuration option enables a list of files.
>  
> +obj-$(CONFIG_MAC_EMUMOUSEBTN)		+= mac_hid.o
>  obj-$(CONFIG_MOUSE_AMIGA)		+= amimouse.o
>  obj-$(CONFIG_MOUSE_APPLETOUCH)		+= appletouch.o
>  obj-$(CONFIG_MOUSE_ATARI)		+= atarimouse.o
> diff --git a/drivers/macintosh/mac_hid.c b/drivers/input/mouse/mac_hid.c
> similarity index 100%
> rename from drivers/macintosh/mac_hid.c
> rename to drivers/input/mouse/mac_hid.c
> diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
> index 97a420c11eed..011df09c5167 100644
> --- a/drivers/macintosh/Kconfig
> +++ b/drivers/macintosh/Kconfig
> @@ -159,23 +159,6 @@ config INPUT_ADBHID
>  
>  	  If unsure, say Y.
>  
> -config MAC_EMUMOUSEBTN
> -	tristate "Support for mouse button 2+3 emulation"
> -	depends on SYSCTL && INPUT
> -	help
> -	  This provides generic support for emulating the 2nd and 3rd mouse
> -	  button with keypresses.  If you say Y here, the emulation is still
> -	  disabled by default.  The emulation is controlled by these sysctl
> -	  entries:
> -	  /proc/sys/dev/mac_hid/mouse_button_emulation
> -	  /proc/sys/dev/mac_hid/mouse_button2_keycode
> -	  /proc/sys/dev/mac_hid/mouse_button3_keycode
> -
> -	  If you have an Apple machine with a 1-button mouse, say Y here.
> -
> -	  To compile this driver as a module, choose M here: the
> -	  module will be called mac_hid.
> -
>  config THERM_WINDTUNNEL
>  	tristate "Support for thermal management on Windtunnel G4s"
>  	depends on I2C && I2C_POWERMAC && PPC_PMAC && !PPC_PMAC64
> diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
> index 516eb65bcacc..ab8b1e74d160 100644
> --- a/drivers/macintosh/Makefile
> +++ b/drivers/macintosh/Makefile
> @@ -7,7 +7,6 @@
>  obj-$(CONFIG_PPC_PMAC)		+= macio_asic.o macio_sysfs.o
>  
>  obj-$(CONFIG_PMAC_MEDIABAY)	+= mediabay.o
> -obj-$(CONFIG_MAC_EMUMOUSEBTN)	+= mac_hid.o
>  obj-$(CONFIG_INPUT_ADBHID)	+= adbhid.o
>  obj-$(CONFIG_ANSLCD)		+= ans-lcd.o
>  
> -- 
> 2.10.2
>

Michal Suchánek May 10, 2017, 10:44 a.m. UTC | #2

On 2017-05-10 02:43, Dmitry Torokhov wrote:
> Hi Michal,
> 
> On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:
>> There is nothing mac-specific about this driver. Non-mac hardware with
>> suboptimal built-in pointer devices exists.
>> 
>> This makes it possible to use this emulation not only on x86 and ppc
>> notebooks but also on arm and mips.
> 
> I'd rather we did not promote from drivers/macintosh to other 
> platforms,
> but rather removed it. The same functionality can be done from
> userspace.

Why do we even have drivers/input? What in there cannot be done in 
userspace? We can just remove everything but uinput, right?

> 
> What hardware do you believe would benefit from this and why?

Many notebooks have built-in touchpad that has only two buttons, no or 
limited multitouch and is not built in a way that allows pressing both 
buttons together to trigger the X11 middle button emulation.

This is a facility that exists in the kernel already and allows mapping 
the missing button(s) to keys near the touchpad. Easy, works with 
anything that uses the Linux input events (ie does not depend on X11).

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek May 28, 2017, 9:47 a.m. UTC | #3

On Tue, 9 May 2017 17:43:27 -0700
Dmitry Torokhov <[e-mail]> wrote:

> Hi Michal,
> 
> On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:
> > There is nothing mac-specific about this driver. Non-mac hardware
> > with suboptimal built-in pointer devices exists.
> > 
> > This makes it possible to use this emulation not only on x86 and ppc
> > notebooks but also on arm and mips.  
> 
> I'd rather we did not promote from drivers/macintosh to other
> platforms, but rather removed it. The same functionality can be done
> from userspace.

What is the status of this?

Do you reply to every patch to drivers/input that is not the the core
infrastructure that you would rather drop the driver because it can be
done is in userspace?

It sure can be done. Remove everything but the bus drivers and uinput
from drivers/input and the rest can be done in userspace.

The question is who does it?

Are you saying that you will implement the userspace equivalent?

If not then please do your job as maintainer and accept trivial patches
for perfectly working drivers we have now.

If you want to move drivers/input into userspace I am not against it
but I am not willing to do that for you either.

> 
> What hardware do you believe would benefit from this and why?

Any touchpad hardware where you cannot press two buttons at once to
emulate the third button due to hardware design. And any touchpad
hardware on which some of the buttons are broken when it comes to it.

It is built into a notebook and works fine for moving the cursor but
due to lack of usable buttons you still need a mouse to use the
notebook.

Thanks

Michal

> 
> Thanks.
> 
> > 
> > Signed-off-by: Michal Suchanek <[e-mail]>
> > ---
> >  drivers/input/mouse/Kconfig                  | 20
> > ++++++++++++++++++++ drivers/input/mouse/Makefile
> > |  1 + drivers/{macintosh => input/mouse}/mac_hid.c |  0
> >  drivers/macintosh/Kconfig                    | 17 -----------------
> >  drivers/macintosh/Makefile                   |  1 -
> >  5 files changed, 21 insertions(+), 18 deletions(-)
> >  rename drivers/{macintosh => input/mouse}/mac_hid.c (100%)
> > 
> > diff --git a/drivers/input/mouse/Kconfig
> > b/drivers/input/mouse/Kconfig index 89ebb8f39fee..5533fd3a113f
> > 100644 --- a/drivers/input/mouse/Kconfig
> > +++ b/drivers/input/mouse/Kconfig
> > @@ -12,6 +12,26 @@ menuconfig INPUT_MOUSE
> >  
> >  if INPUT_MOUSE
> >  
> > +config MAC_EMUMOUSEBTN
> > +	tristate "Support for mouse button 2+3 emulation"
> > +	depends on SYSCTL && INPUT
> > +	help
> > +	  This provides generic support for emulating the 2nd and
> > 3rd mouse
> > +	  button with keypresses.  If you say Y here, the
> > emulation is still
> > +	  disabled by default.  The emulation is controlled by
> > these sysctl
> > +	  entries:
> > +	  /proc/sys/dev/mac_hid/mouse_button_emulation
> > +	  /proc/sys/dev/mac_hid/mouse_button2_keycode
> > +	  /proc/sys/dev/mac_hid/mouse_button3_keycode
> > +
> > +	  If you have an Apple machine with a 1-button mouse, say
> > Y here. +
> > +	  This emulation can be useful on notebooks with
> > suboptimal touchpad
> > +	  hardware as well.
> > +
> > +	  To compile this driver as a module, choose M here: the
> > +	  module will be called mac_hid.
> > +
> >  config MOUSE_PS2
> >  	tristate "PS/2 mouse"
> >  	default y
> > diff --git a/drivers/input/mouse/Makefile
> > b/drivers/input/mouse/Makefile index 56bf0ad877c6..dfaad1dd8857
> > 100644 --- a/drivers/input/mouse/Makefile
> > +++ b/drivers/input/mouse/Makefile
> > @@ -4,6 +4,7 @@
> >  
> >  # Each configuration option enables a list of files.
> >  
> > +obj-$(CONFIG_MAC_EMUMOUSEBTN)		+= mac_hid.o
> >  obj-$(CONFIG_MOUSE_AMIGA)		+= amimouse.o
> >  obj-$(CONFIG_MOUSE_APPLETOUCH)		+= appletouch.o
> >  obj-$(CONFIG_MOUSE_ATARI)		+= atarimouse.o
> > diff --git a/drivers/macintosh/mac_hid.c
> > b/drivers/input/mouse/mac_hid.c similarity index 100%
> > rename from drivers/macintosh/mac_hid.c
> > rename to drivers/input/mouse/mac_hid.c
> > diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
> > index 97a420c11eed..011df09c5167 100644
> > --- a/drivers/macintosh/Kconfig
> > +++ b/drivers/macintosh/Kconfig
> > @@ -159,23 +159,6 @@ config INPUT_ADBHID
> >  
> >  	  If unsure, say Y.
> >  
> > -config MAC_EMUMOUSEBTN
> > -	tristate "Support for mouse button 2+3 emulation"
> > -	depends on SYSCTL && INPUT
> > -	help
> > -	  This provides generic support for emulating the 2nd and
> > 3rd mouse
> > -	  button with keypresses.  If you say Y here, the
> > emulation is still
> > -	  disabled by default.  The emulation is controlled by
> > these sysctl
> > -	  entries:
> > -	  /proc/sys/dev/mac_hid/mouse_button_emulation
> > -	  /proc/sys/dev/mac_hid/mouse_button2_keycode
> > -	  /proc/sys/dev/mac_hid/mouse_button3_keycode
> > -
> > -	  If you have an Apple machine with a 1-button mouse, say
> > Y here. -
> > -	  To compile this driver as a module, choose M here: the
> > -	  module will be called mac_hid.
> > -
> >  config THERM_WINDTUNNEL
> >  	tristate "Support for thermal management on Windtunnel G4s"
> >  	depends on I2C && I2C_POWERMAC && PPC_PMAC && !PPC_PMAC64
> > diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
> > index 516eb65bcacc..ab8b1e74d160 100644
> > --- a/drivers/macintosh/Makefile
> > +++ b/drivers/macintosh/Makefile
> > @@ -7,7 +7,6 @@
> >  obj-$(CONFIG_PPC_PMAC)		+= macio_asic.o macio_sysfs.o
> >  
> >  obj-$(CONFIG_PMAC_MEDIABAY)	+= mediabay.o
> > -obj-$(CONFIG_MAC_EMUMOUSEBTN)	+= mac_hid.o
> >  obj-$(CONFIG_INPUT_ADBHID)	+= adbhid.o
> >  obj-$(CONFIG_ANSLCD)		+= ans-lcd.o
> >  
> > -- 
> > 2.10.2
> >   
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bastien Nocera May 28, 2017, 1:26 p.m. UTC | #4

On Sun, 2017-05-28 at 11:47 +0200, Michal Suchanek wrote:
> On Tue, 9 May 2017 17:43:27 -0700
> Dmitry Torokhov <[e-mail]> wrote:
> 
> > Hi Michal,
> > 
> > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:
> > > There is nothing mac-specific about this driver. Non-mac hardware
> > > with suboptimal built-in pointer devices exists.
> > > 
> > > This makes it possible to use this emulation not only on x86 and
> > > ppc
> > > notebooks but also on arm and mips.  
> > 
> > I'd rather we did not promote from drivers/macintosh to other
> > platforms, but rather removed it. The same functionality can be
> > done
> > from userspace.
> 
> What is the status of this?
> 
> Do you reply to every patch to drivers/input that is not the the core
> infrastructure that you would rather drop the driver because it can
> be
> done is in userspace?
> 
> It sure can be done. Remove everything but the bus drivers and uinput
> from drivers/input and the rest can be done in userspace.
> 
> The question is who does it?
> 
> Are you saying that you will implement the userspace equivalent?
> 
> If not then please do your job as maintainer and accept trivial
> patches
> for perfectly working drivers we have now.
> 
> If you want to move drivers/input into userspace I am not against it
> but I am not willing to do that for you either.

I'd advise you to take it down a notch. We don't go yelling at each
other on this mailing-list.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov May 28, 2017, 5:55 p.m. UTC | #5

On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> On Tue, 9 May 2017 17:43:27 -0700
> Dmitry Torokhov <[e-mail]> wrote:
> 
> > Hi Michal,
> > 
> > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:
> > > There is nothing mac-specific about this driver. Non-mac hardware
> > > with suboptimal built-in pointer devices exists.
> > > 
> > > This makes it possible to use this emulation not only on x86 and ppc
> > > notebooks but also on arm and mips.  
> > 
> > I'd rather we did not promote from drivers/macintosh to other
> > platforms, but rather removed it. The same functionality can be done
> > from userspace.
> 
> What is the status of this?

The same as in above paragraph.

> 
> Do you reply to every patch to drivers/input that is not the the core
> infrastructure that you would rather drop the driver because it can be
> done is in userspace?
> 
> It sure can be done. Remove everything but the bus drivers and uinput
> from drivers/input and the rest can be done in userspace.
> 
> The question is who does it?
> 
> Are you saying that you will implement the userspace equivalent?

No, I spend my time mostly with the kernel.

> 
> If not then please do your job as maintainer and accept trivial patches
> for perfectly working drivers we have now.

I am doing my job as a maintainer right now. The driver might have been
beneficial 15 years ago, when we did not have better options, but I
would rather not continue expanding it's use.

The main problem with the driver is that the functionality it is not
easily discoverable by end users. And once you plumb it through
userspace to present users with options you might as well handle it all
in userspace.

> 
> If you want to move drivers/input into userspace I am not against it
> but I am not willing to do that for you either.

Then we are at impasse.

> 
> > 
> > What hardware do you believe would benefit from this and why?
> 
> Any touchpad hardware where you cannot press two buttons at once to
> emulate the third button due to hardware design. And any touchpad
> hardware on which some of the buttons are broken when it comes to it.
> 
> It is built into a notebook and works fine for moving the cursor but
> due to lack of usable buttons you still need a mouse to use the
> notebook.

Have you tried simply redefining keymap of your keyboard to emit
BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
updates from userspace/udev/hwdb and if there is a driver that does not
support it I will take patches fixing that.

Thanks.

Michal Suchánek May 29, 2017, 6:03 p.m. UTC | #6

On Sun, 28 May 2017 10:55:40 -0700
Dmitry Torokhov <[e-mail]> wrote:

> On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> > On Tue, 9 May 2017 17:43:27 -0700
> > Dmitry Torokhov <[e-mail]> wrote:

> > 
> > If not then please do your job as maintainer and accept trivial
> > patches for perfectly working drivers we have now.  
> 
> I am doing my job as a maintainer right now. The driver might have
> been beneficial 15 years ago, when we did not have better options,
> but I would rather not continue expanding it's use.
> 
> The main problem with the driver is that the functionality it is not
> easily discoverable by end users. And once you plumb it through
> userspace to present users with options you might as well handle it
> all in userspace.
> 
...
> 
> >   
> > > 
> > > What hardware do you believe would benefit from this and why?  
> > 
> > Any touchpad hardware where you cannot press two buttons at once to
> > emulate the third button due to hardware design. And any touchpad
> > hardware on which some of the buttons are broken when it comes to
> > it.
> > 
> > It is built into a notebook and works fine for moving the cursor but
> > due to lack of usable buttons you still need a mouse to use the
> > notebook.  
> 
> Have you tried simply redefining keymap of your keyboard to emit
> BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> updates from userspace/udev/hwdb and if there is a driver that does
> not support it I will take patches fixing that.

How is that more easily discoverable by users?

More importantly how is that mapping supposed to be represented in a
hwdb file?

The help text in the hwdb file says:

# Scan codes are specified as:
#   KEYBOARD_KEY_<hex scan code>=<key code identifier>
# The scan code should be expressed in hex lowercase. The key codes
# are retrieved and normalized from the kernel input API header.

So they are converted in some unspecified way.

The example below defines some mappings, presumably:

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
 KEYBOARD_KEY_a5=help                                   # Fn+F1
 KEYBOARD_KEY_a6=setup                                  # Fn+F2
 KEYBOARD_KEY_a7=battery                                # Fn+F3

/usr/include/linux/input-event-codes.h has occurence of battery in

#define KEY_BATTERY		236

meaning that the unspecified conversion is probably performed by

1) stripping KEY_ prefix
2) converting to lowercase

This is what systemd hwdb check script does in reverse when checking
the keycode values.

The BTN_LEFT 0x110 value does not conflict with KEY_* values, though.
So technically you could include it in the keymap. If you had a tool
for that. And if it is not rejected by the kernel. And if it does not
crash your X server which is very picky about receiving pointer events
from a keyboard or the other way around.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov May 30, 2017, 5:06 a.m. UTC | #7

On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek wrote:
> On Sun, 28 May 2017 10:55:40 -0700
> Dmitry Torokhov <[e-mail]> wrote:
> 
> > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> > > On Tue, 9 May 2017 17:43:27 -0700
> > > Dmitry Torokhov <[e-mail]> wrote:
> 
> > > 
> > > If not then please do your job as maintainer and accept trivial
> > > patches for perfectly working drivers we have now.  
> > 
> > I am doing my job as a maintainer right now. The driver might have
> > been beneficial 15 years ago, when we did not have better options,
> > but I would rather not continue expanding it's use.
> > 
> > The main problem with the driver is that the functionality it is not
> > easily discoverable by end users. And once you plumb it through
> > userspace to present users with options you might as well handle it
> > all in userspace.
> > 
> ...
> > 
> > >   
> > > > 
> > > > What hardware do you believe would benefit from this and why?  
> > > 
> > > Any touchpad hardware where you cannot press two buttons at once to
> > > emulate the third button due to hardware design. And any touchpad
> > > hardware on which some of the buttons are broken when it comes to
> > > it.
> > > 
> > > It is built into a notebook and works fine for moving the cursor but
> > > due to lack of usable buttons you still need a mouse to use the
> > > notebook.  
> > 
> > Have you tried simply redefining keymap of your keyboard to emit
> > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > updates from userspace/udev/hwdb and if there is a driver that does
> > not support it I will take patches fixing that.
> 
> How is that more easily discoverable by users?

It is not, but the benefit that it does not require a new driver and
uses standard tools to update the mapping.

> 
> More importantly how is that mapping supposed to be represented in a
> hwdb file?
> 
> The help text in the hwdb file says:
> 
> # Scan codes are specified as:
> #   KEYBOARD_KEY_<hex scan code>=<key code identifier>
> # The scan code should be expressed in hex lowercase. The key codes
> # are retrieved and normalized from the kernel input API header.
> 
> So they are converted in some unspecified way.
> 
> The example below defines some mappings, presumably:
> 
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
>  KEYBOARD_KEY_a5=help                                   # Fn+F1
>  KEYBOARD_KEY_a6=setup                                  # Fn+F2
>  KEYBOARD_KEY_a7=battery                                # Fn+F3
> 
> /usr/include/linux/input-event-codes.h has occurence of battery in
> 
> #define KEY_BATTERY		236
> 
> meaning that the unspecified conversion is probably performed by
> 
> 1) stripping KEY_ prefix
> 2) converting to lowercase
> 
> This is what systemd hwdb check script does in reverse when checking
> the keycode values.
> 
> The BTN_LEFT 0x110 value does not conflict with KEY_* values, though.
> So technically you could include it in the keymap. If you had a tool
> for that.

Hmm, sounds like you want a patch to udev/systemd. For the kernel there
is no difference between keys and buttons, except symbolic names. They
all go into dev->keybit and are reported with input_report_key().

> And if it is not rejected by the kernel.

It should not. setkeycodes definitely works on atkbd.

> And if it does not
> crash your X server which is very picky about receiving pointer events
> from a keyboard or the other way around.

Sounds like you want to make X server more resilient ;)

But really, it all is better solved in userspace, where you can surface
all options to the user. For example Chrome OS uses Alt + mouse button
(or tap) to do right click, I am sure Gnome or KDE has similar support
for right and middle buttons.

Solving this at kernel is wrong place, similarly how we avoid parsing
user gestures (edge scrolling, 2-finger scrolling, pitch/zoom, etc) in
kernel. Yes, we have legacy drivers (like mousedev) that are artefacts
of times when userspace support was not there and it made sense to
covert everything to emulated PS/2, but that time is long gone.

Thanks.

Michal Suchánek May 30, 2017, 9:34 a.m. UTC | #8

On Mon, 29 May 2017 22:06:06 -0700
Dmitry Torokhov <[e-mail]> wrote:

> On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek wrote:
> > On Sun, 28 May 2017 10:55:40 -0700
> > Dmitry Torokhov <[e-mail]> wrote:
> >   
> > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:  
> > > > On Tue, 9 May 2017 17:43:27 -0700
> > > > Dmitry Torokhov <[e-mail]> wrote:  
> >   
> > > > 
> > > > If not then please do your job as maintainer and accept trivial
> > > > patches for perfectly working drivers we have now.    
> > > 
> > > I am doing my job as a maintainer right now. The driver might have
> > > been beneficial 15 years ago, when we did not have better options,
> > > but I would rather not continue expanding it's use.
> > > 
> > > The main problem with the driver is that the functionality it is
> > > not easily discoverable by end users. And once you plumb it
> > > through userspace to present users with options you might as well
> > > handle it all in userspace.
> > >   
> > ...  
> > >   
> > > >     
> > > > > 
> > > > > What hardware do you believe would benefit from this and
> > > > > why?    
> > > > 
> > > > Any touchpad hardware where you cannot press two buttons at
> > > > once to emulate the third button due to hardware design. And
> > > > any touchpad hardware on which some of the buttons are broken
> > > > when it comes to it.
> > > > 
> > > > It is built into a notebook and works fine for moving the
> > > > cursor but due to lack of usable buttons you still need a mouse
> > > > to use the notebook.    
> > > 
> > > Have you tried simply redefining keymap of your keyboard to emit
> > > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > > updates from userspace/udev/hwdb and if there is a driver that
> > > does not support it I will take patches fixing that.  
> > 
> > How is that more easily discoverable by users?  
> 
> It is not, but the benefit that it does not require a new driver and
> uses standard tools to update the mapping.

The mac mouse emulation is not a new driver. It has been in the kernel
for ages. All I want is patch the Kconfig to make it possible to use
the driver when convenient.

> 
> > 
> > More importantly how is that mapping supposed to be represented in a
> > hwdb file?
> > 
> > The help text in the hwdb file says:
> > 
> > # Scan codes are specified as:
> > #   KEYBOARD_KEY_<hex scan code>=<key code identifier>
> > # The scan code should be expressed in hex lowercase. The key codes
> > # are retrieved and normalized from the kernel input API header.
> > 
> > So they are converted in some unspecified way.
> > 
> > The example below defines some mappings, presumably:
> > 
> > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
> > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
> > evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
> >  KEYBOARD_KEY_a5=help                                   # Fn+F1
> >  KEYBOARD_KEY_a6=setup                                  # Fn+F2
> >  KEYBOARD_KEY_a7=battery                                # Fn+F3
> > 
> > /usr/include/linux/input-event-codes.h has occurence of battery in
> > 
> > #define KEY_BATTERY		236
> > 
> > meaning that the unspecified conversion is probably performed by
> > 
> > 1) stripping KEY_ prefix
> > 2) converting to lowercase
> > 
> > This is what systemd hwdb check script does in reverse when checking
> > the keycode values.
> > 
> > The BTN_LEFT 0x110 value does not conflict with KEY_* values,
> > though. So technically you could include it in the keymap. If you
> > had a tool for that.  
> 
> Hmm, sounds like you want a patch to udev/systemd. For the kernel
> there is no difference between keys and buttons, except symbolic
> names. They all go into dev->keybit and are reported with
> input_report_key().

So the userspace is not ready for this while the kernel already has the
driver for ages and all that is needed is to enable it.

> 
> > And if it is not rejected by the kernel.  
> 
> It should not. setkeycodes definitely works on atkbd.
> 
> > And if it does not
> > crash your X server which is very picky about receiving pointer
> > events from a keyboard or the other way around.  
> 
> Sounds like you want to make X server more resilient ;)

This is an inherent design flaw in the X server known for years. It has
separate keyboard and pointer devices and while people are trying to
patch it up occasionally a bug pops out that crashes the Xserver when
an event is received from non-matching device type.

Once X server dies and is replaced be Y server or Z server or whatever
it will make life easier in so many ways.

> 
> But really, it all is better solved in userspace, where you can
> surface all options to the user. For example Chrome OS uses Alt +
> mouse button (or tap) to do right click, I am sure Gnome or KDE has
> similar support for right and middle buttons.

I do not consider Gnome or KDE more suitable driver for my keyboard
than the Linux kernel. In fact I find both very unsuitable as a driver,
heavyweight, and causing problems with graphical desktop usability. Not
to mention they cannot be used at all when not running a graphical
desktop and often cause system crashes due to stressing the graphics
hardware.

> 
> Solving this at kernel is wrong place, similarly how we avoid parsing
> user gestures (edge scrolling, 2-finger scrolling, pitch/zoom, etc) in
> kernel. Yes, we have legacy drivers (like mousedev) that are artefacts
> of times when userspace support was not there and it made sense to
> covert everything to emulated PS/2, but that time is long gone.

Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping is
something kernel can do, does, and should do.

The difference between the plain mapping and mac mouse emulation is
that mac mouse emulation probably creates a separate pointer device
which is as compatible with legacy software as it gets. Unlike
application-specific solutions it works in any software that accepts
input events including X. And unlike the systemd solution it works
today.

Given the state of userspace at this point I find using the mac mouse
emulation most sensible thing to do. Improving the keymap support in
systemd is certainly more flexible so it is the way to go long term but
if a patch is written and accepted today it will take years until
support is commonplace. On the other hand, the change required in Linux
is trivial and updating the kernel without breaking the whole system is
much more viable than updating systemd.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Benjamin Tissoires May 30, 2017, 10:33 a.m. UTC | #9

Hi Michal,

On May 30 2017 or thereabouts, Michal Suchánek wrote:
> On Mon, 29 May 2017 22:06:06 -0700
> Dmitry Torokhov <[e-mail]> wrote:
> 
> > On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek wrote:
> > > On Sun, 28 May 2017 10:55:40 -0700
> > > Dmitry Torokhov <[e-mail]> wrote:
> > >   
> > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:  
> > > > > On Tue, 9 May 2017 17:43:27 -0700
> > > > > Dmitry Torokhov <[e-mail]> wrote:  
> > >   
> > > > > 
> > > > > If not then please do your job as maintainer and accept trivial
> > > > > patches for perfectly working drivers we have now.    
> > > > 
> > > > I am doing my job as a maintainer right now. The driver might have
> > > > been beneficial 15 years ago, when we did not have better options,
> > > > but I would rather not continue expanding it's use.
> > > > 
> > > > The main problem with the driver is that the functionality it is
> > > > not easily discoverable by end users. And once you plumb it
> > > > through userspace to present users with options you might as well
> > > > handle it all in userspace.
> > > >   
> > > ...  
> > > >   
> > > > >     
> > > > > > 
> > > > > > What hardware do you believe would benefit from this and
> > > > > > why?    
> > > > > 
> > > > > Any touchpad hardware where you cannot press two buttons at
> > > > > once to emulate the third button due to hardware design. And
> > > > > any touchpad hardware on which some of the buttons are broken
> > > > > when it comes to it.
> > > > > 
> > > > > It is built into a notebook and works fine for moving the
> > > > > cursor but due to lack of usable buttons you still need a mouse
> > > > > to use the notebook.    
> > > > 
> > > > Have you tried simply redefining keymap of your keyboard to emit
> > > > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > > > updates from userspace/udev/hwdb and if there is a driver that
> > > > does not support it I will take patches fixing that.  
> > > 
> > > How is that more easily discoverable by users?  
> > 
> > It is not, but the benefit that it does not require a new driver and
> > uses standard tools to update the mapping.
> 
> The mac mouse emulation is not a new driver. It has been in the kernel
> for ages. All I want is patch the Kconfig to make it possible to use
> the driver when convenient.

So is mousedev, and we recommend to not use it.

> 
> > 
> > > 
> > > More importantly how is that mapping supposed to be represented in a
> > > hwdb file?
> > > 
> > > The help text in the hwdb file says:
> > > 
> > > # Scan codes are specified as:
> > > #   KEYBOARD_KEY_<hex scan code>=<key code identifier>
> > > # The scan code should be expressed in hex lowercase. The key codes
> > > # are retrieved and normalized from the kernel input API header.
> > > 
> > > So they are converted in some unspecified way.
> > > 
> > > The example below defines some mappings, presumably:
> > > 
> > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
> > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
> > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
> > >  KEYBOARD_KEY_a5=help                                   # Fn+F1
> > >  KEYBOARD_KEY_a6=setup                                  # Fn+F2
> > >  KEYBOARD_KEY_a7=battery                                # Fn+F3
> > > 
> > > /usr/include/linux/input-event-codes.h has occurence of battery in
> > > 
> > > #define KEY_BATTERY		236
> > > 
> > > meaning that the unspecified conversion is probably performed by
> > > 
> > > 1) stripping KEY_ prefix
> > > 2) converting to lowercase
> > > 
> > > This is what systemd hwdb check script does in reverse when checking
> > > the keycode values.
> > > 
> > > The BTN_LEFT 0x110 value does not conflict with KEY_* values,
> > > though. So technically you could include it in the keymap. If you
> > > had a tool for that.  
> > 
> > Hmm, sounds like you want a patch to udev/systemd. For the kernel
> > there is no difference between keys and buttons, except symbolic
> > names. They all go into dev->keybit and are reported with
> > input_report_key().
> 
> So the userspace is not ready for this while the kernel already has the
> driver for ages and all that is needed is to enable it.

The problem is more that you can have your particular issue solved here
by using this particular driver. But then someone says that the mapping
for right/middle doesn't fit to his/her keyboard layout, and then we
will have to maintain an new set of fancy new features in a driver that
is just legacy.

I concede userspace doesn't have the feature, but you should really have
a look at libinput (i.e. open a bug on bugs.freedesktop.org) and request
the feature here.

> 
> > 
> > > And if it is not rejected by the kernel.  
> > 
> > It should not. setkeycodes definitely works on atkbd.
> > 
> > > And if it does not
> > > crash your X server which is very picky about receiving pointer
> > > events from a keyboard or the other way around.  
> > 
> > Sounds like you want to make X server more resilient ;)
> 
> This is an inherent design flaw in the X server known for years. It has
> separate keyboard and pointer devices and while people are trying to
> patch it up occasionally a bug pops out that crashes the Xserver when
> an event is received from non-matching device type.
> 
> Once X server dies and is replaced be Y server or Z server or whatever
> it will make life easier in so many ways.

We already have libinput that tends to replace the Xorg input part (at
least everything which is not protocol). So if the feature is in
libinput, it should be available in X.org directly, and you will be
saved.

> 
> > 
> > But really, it all is better solved in userspace, where you can
> > surface all options to the user. For example Chrome OS uses Alt +
> > mouse button (or tap) to do right click, I am sure Gnome or KDE has
> > similar support for right and middle buttons.
> 
> I do not consider Gnome or KDE more suitable driver for my keyboard
> than the Linux kernel. In fact I find both very unsuitable as a driver,
> heavyweight, and causing problems with graphical desktop usability. Not

Well, with wayland, the compositor embeds the input stack and part of
the graphic stack, and it's actually faster than X.

> to mention they cannot be used at all when not running a graphical
> desktop and often cause system crashes due to stressing the graphics
> hardware.

If you experience crashes, they are probably bugs, and please report
them to the appropriate project.

> 
> > 
> > Solving this at kernel is wrong place, similarly how we avoid parsing
> > user gestures (edge scrolling, 2-finger scrolling, pitch/zoom, etc) in
> > kernel. Yes, we have legacy drivers (like mousedev) that are artefacts
> > of times when userspace support was not there and it made sense to
> > covert everything to emulated PS/2, but that time is long gone.
> 
> Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping is
> something kernel can do, does, and should do.

Looks like we are all on the same page. Kernel does key mapping already
and doesn't do 2-finger scrolling and other gestures.

The difference in approach is that you want the kernel to emulate
devices when userspace has much more information to know how to emulate
those devices.

The kernel job is to forward events from the devices to userspace
without losing information and in a standard way. Anything beyond that
should be handled in userspace.

> 
> The difference between the plain mapping and mac mouse emulation is
> that mac mouse emulation probably creates a separate pointer device
> which is as compatible with legacy software as it gets. Unlike
> application-specific solutions it works in any software that accepts
> input events including X. And unlike the systemd solution it works
> today.

And we can argue that the issue with the mac mouse emulation is that
it filters on all connected keyboard.
Meaning that if you connect an external keyboard just from time to time,
those two keys will send the emulated buttons instead of sending plain
key events.

While on a libinput approach, the filtering will only affect the
internal keyboard, making the whole experience better.

> 
> Given the state of userspace at this point I find using the mac mouse
> emulation most sensible thing to do. Improving the keymap support in
> systemd is certainly more flexible so it is the way to go long term but
> if a patch is written and accepted today it will take years until
> support is commonplace. On the other hand, the change required in Linux
> is trivial and updating the kernel without breaking the whole system is
> much more viable than updating systemd.

With a libinput approach, the time to distro is much reduced (unless you
are running a *very* old libinput release that is not ABI compatible
anymore).

And we can return the argument for the kernel. The time for a new option
in the kernel to land in some distribution can also be counted in years.

Cheers,
Benjamin

> 
> Thanks
> 
> Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek May 30, 2017, 11:32 a.m. UTC | #10

On Tue, 30 May 2017 12:33:21 +0200
Benjamin Tissoires <[e-mail]> wrote:

> Hi Michal,
> 
> On May 30 2017 or thereabouts, Michal Suchánek wrote:
> > On Mon, 29 May 2017 22:06:06 -0700
> > Dmitry Torokhov <[e-mail]> wrote:
> >   
> > > On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek wrote:  
> > > > On Sun, 28 May 2017 10:55:40 -0700
> > > > Dmitry Torokhov <[e-mail]> wrote:
> > > >     
> > > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek
> > > > > wrote:    

> >   
> > >   
> > > > 
> > > > More importantly how is that mapping supposed to be represented
> > > > in a hwdb file?
> > > > 
> > > > The help text in the hwdb file says:
> > > > 
> > > > # Scan codes are specified as:
> > > > #   KEYBOARD_KEY_<hex scan code>=<key code identifier>
> > > > # The scan code should be expressed in hex lowercase. The key
> > > > codes # are retrieved and normalized from the kernel input API
> > > > header.
> > > > 
> > > > So they are converted in some unspecified way.
> > > > 
> > > > The example below defines some mappings, presumably:
> > > > 
> > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
> > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
> > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
> > > >  KEYBOARD_KEY_a5=help                                   # Fn+F1
> > > >  KEYBOARD_KEY_a6=setup                                  # Fn+F2
> > > >  KEYBOARD_KEY_a7=battery                                # Fn+F3
> > > > 
> > > > /usr/include/linux/input-event-codes.h has occurence of battery
> > > > in
> > > > 
> > > > #define KEY_BATTERY		236
> > > > 
> > > > meaning that the unspecified conversion is probably performed by
> > > > 
> > > > 1) stripping KEY_ prefix
> > > > 2) converting to lowercase
> > > > 
> > > > This is what systemd hwdb check script does in reverse when
> > > > checking the keycode values.
> > > > 
> > > > The BTN_LEFT 0x110 value does not conflict with KEY_* values,
> > > > though. So technically you could include it in the keymap. If
> > > > you had a tool for that.    
> > > 
> > > Hmm, sounds like you want a patch to udev/systemd. For the kernel
> > > there is no difference between keys and buttons, except symbolic
> > > names. They all go into dev->keybit and are reported with
> > > input_report_key().  
> > 
> > So the userspace is not ready for this while the kernel already has
> > the driver for ages and all that is needed is to enable it.  
> 
> The problem is more that you can have your particular issue solved
> here by using this particular driver. But then someone says that the
> mapping for right/middle doesn't fit to his/her keyboard layout, and
> then we will have to maintain an new set of fancy new features in a
> driver that is just legacy.

The mapping is dynamic. You specify which keycode you translate to
which button by writing a sysfs file and if you do not nothing is
translated. So far as plain mouse emulation goes this driver is
perfectly fine. It will probably not emulate a scrollwheel and other
fancy features but that can be solved in later more flexible solution
once it is finished. And once it is finished then is the time for
retiring this driver.

> 
> I concede userspace doesn't have the feature, but you should really
> have a look at libinput (i.e. open a bug on bugs.freedesktop.org) and
> request the feature here.
> 
> >   
> > >   
> > > > And if it is not rejected by the kernel.    
> > > 
> > > It should not. setkeycodes definitely works on atkbd.
> > >   
> > > > And if it does not
> > > > crash your X server which is very picky about receiving pointer
> > > > events from a keyboard or the other way around.    
> > > 
> > > Sounds like you want to make X server more resilient ;)  
> > 
> > This is an inherent design flaw in the X server known for years. It
> > has separate keyboard and pointer devices and while people are
> > trying to patch it up occasionally a bug pops out that crashes the
> > Xserver when an event is received from non-matching device type.
> > 
> > Once X server dies and is replaced be Y server or Z server or
> > whatever it will make life easier in so many ways.  
> 
> We already have libinput that tends to replace the Xorg input part (at
> least everything which is not protocol). 

And the protocol still has the split to pointer and keyboard. It is
technically possible to map mouse button presses with XKB but it only
works in X and is undocumented and really difficult to do. And it does
not work outside of X.

> So if the feature is in
> libinput, it should be available in X.org directly, and you will be
> saved.

Not everything uses libinput. So no, using libinput is not the answer.

Also libinput people suggest to use hwdb for mapping which is back
to where we were:
https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html

> 
> >   
> > > 
> > > But really, it all is better solved in userspace, where you can
> > > surface all options to the user. For example Chrome OS uses Alt +
> > > mouse button (or tap) to do right click, I am sure Gnome or KDE
> > > has similar support for right and middle buttons.  
> > 
> > I do not consider Gnome or KDE more suitable driver for my keyboard
> > than the Linux kernel. In fact I find both very unsuitable as a
> > driver, heavyweight, and causing problems with graphical desktop
> > usability. Not  
> 
> Well, with wayland, the compositor embeds the input stack and part of
> the graphic stack, and it's actually faster than X.

That's pointless when it does not work as a desktop in practice.

And it does not make GNOME or KDE a suitable driver for keyboard, even
if you run Wayland.

> 
> > to mention they cannot be used at all when not running a graphical
> > desktop and often cause system crashes due to stressing the graphics
> > hardware.  
> 
> If you experience crashes, they are probably bugs, and please report
> them to the appropriate project.

And the answer is they know it crashes but it's too much work to fix.
Or that it works for them and you are just unlucky that all of your
half dozen cards crash with their driver and they cannot do anything
about it.
Maybe next year. Or the year after. Or with different piece of
hardware. Who knows?

> 
> >   
> > > 
> > > Solving this at kernel is wrong place, similarly how we avoid
> > > parsing user gestures (edge scrolling, 2-finger scrolling,
> > > pitch/zoom, etc) in kernel. Yes, we have legacy drivers (like
> > > mousedev) that are artefacts of times when userspace support was
> > > not there and it made sense to covert everything to emulated
> > > PS/2, but that time is long gone.  
> > 
> > Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping is
> > something kernel can do, does, and should do.  
> 
> Looks like we are all on the same page. Kernel does key mapping
> already and doesn't do 2-finger scrolling and other gestures.
> 
> The difference in approach is that you want the kernel to emulate
> devices when userspace has much more information to know how to
> emulate those devices.

Any piece of software has the information when the user tells it. The
thing is the kernel is also able to emulate the device and the
userspace is not. And seriously, this is a hardware problem which is
simple to solve once for good in kernel. Do you advocate that instead
everyone should set up mouse emulation in N application frameworks and
implement it in those that miss it?

> 
> The kernel job is to forward events from the devices to userspace
> without losing information and in a standard way. Anything beyond that
> should be handled in userspace.
 
Then why do you do keycode translation at all? 
I guess because it is the job of the kernel to make the information
usable by the applications as well.

> 
> > 
> > The difference between the plain mapping and mac mouse emulation is
> > that mac mouse emulation probably creates a separate pointer device
> > which is as compatible with legacy software as it gets. Unlike
> > application-specific solutions it works in any software that accepts
> > input events including X. And unlike the systemd solution it works
> > today.  
> 
> And we can argue that the issue with the mac mouse emulation is that
> it filters on all connected keyboard.
> Meaning that if you connect an external keyboard just from time to
> time, those two keys will send the emulated buttons instead of
> sending plain key events.

Well, that's a limitation of simple solution. 

> 
> While on a libinput approach, the filtering will only affect the
> internal keyboard, making the whole experience better.

Unless it happens to crash the X server.

> 
> > 
> > Given the state of userspace at this point I find using the mac
> > mouse emulation most sensible thing to do. Improving the keymap
> > support in systemd is certainly more flexible so it is the way to
> > go long term but if a patch is written and accepted today it will
> > take years until support is commonplace. On the other hand, the
> > change required in Linux is trivial and updating the kernel without
> > breaking the whole system is much more viable than updating
> > systemd.  
> 
> With a libinput approach, the time to distro is much reduced (unless
> you are running a *very* old libinput release that is not ABI
> compatible anymore).

There is no libinput approach. They eschew mapping since there is one
in systemd and one in X already. 

> 
> And we can return the argument for the kernel. The time for a new
> option in the kernel to land in some distribution can also be counted
> in years.
> 

Indeed. However, running own kernel is much more likely to succeed than
running own systemd.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Benjamin Tissoires May 30, 2017, 12:02 p.m. UTC | #11

On May 30 2017 or thereabouts, Michal Suchánek wrote:
> On Tue, 30 May 2017 12:33:21 +0200
> Benjamin Tissoires <[e-mail]> wrote:
> 
> > Hi Michal,
> > 
> > On May 30 2017 or thereabouts, Michal Suchánek wrote:
> > > On Mon, 29 May 2017 22:06:06 -0700
> > > Dmitry Torokhov <[e-mail]> wrote:
> > >   
> > > > On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek wrote:  
> > > > > On Sun, 28 May 2017 10:55:40 -0700
> > > > > Dmitry Torokhov <[e-mail]> wrote:
> > > > >     
> > > > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek
> > > > > > wrote:    
> 
> > >   
> > > >   
> > > > > 
> > > > > More importantly how is that mapping supposed to be represented
> > > > > in a hwdb file?
> > > > > 
> > > > > The help text in the hwdb file says:
> > > > > 
> > > > > # Scan codes are specified as:
> > > > > #   KEYBOARD_KEY_<hex scan code>=<key code identifier>
> > > > > # The scan code should be expressed in hex lowercase. The key
> > > > > codes # are retrieved and normalized from the kernel input API
> > > > > header.
> > > > > 
> > > > > So they are converted in some unspecified way.
> > > > > 
> > > > > The example below defines some mappings, presumably:
> > > > > 
> > > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
> > > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
> > > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
> > > > >  KEYBOARD_KEY_a5=help                                   # Fn+F1
> > > > >  KEYBOARD_KEY_a6=setup                                  # Fn+F2
> > > > >  KEYBOARD_KEY_a7=battery                                # Fn+F3
> > > > > 
> > > > > /usr/include/linux/input-event-codes.h has occurence of battery
> > > > > in
> > > > > 
> > > > > #define KEY_BATTERY		236
> > > > > 
> > > > > meaning that the unspecified conversion is probably performed by
> > > > > 
> > > > > 1) stripping KEY_ prefix
> > > > > 2) converting to lowercase
> > > > > 
> > > > > This is what systemd hwdb check script does in reverse when
> > > > > checking the keycode values.
> > > > > 
> > > > > The BTN_LEFT 0x110 value does not conflict with KEY_* values,
> > > > > though. So technically you could include it in the keymap. If
> > > > > you had a tool for that.    
> > > > 
> > > > Hmm, sounds like you want a patch to udev/systemd. For the kernel
> > > > there is no difference between keys and buttons, except symbolic
> > > > names. They all go into dev->keybit and are reported with
> > > > input_report_key().  
> > > 
> > > So the userspace is not ready for this while the kernel already has
> > > the driver for ages and all that is needed is to enable it.  
> > 
> > The problem is more that you can have your particular issue solved
> > here by using this particular driver. But then someone says that the
> > mapping for right/middle doesn't fit to his/her keyboard layout, and
> > then we will have to maintain an new set of fancy new features in a
> > driver that is just legacy.
> 
> The mapping is dynamic. You specify which keycode you translate to
> which button by writing a sysfs file and if you do not nothing is
> translated. So far as plain mouse emulation goes this driver is
> perfectly fine. It will probably not emulate a scrollwheel and other
> fancy features but that can be solved in later more flexible solution
> once it is finished. And once it is finished then is the time for
> retiring this driver.

My bad. Still, it doesn't change the fact that this driver should be
pointless and retired, because it has to be done in userspace.

> 
> > 
> > I concede userspace doesn't have the feature, but you should really
> > have a look at libinput (i.e. open a bug on bugs.freedesktop.org) and
> > request the feature here.
> > 
> > >   
> > > >   
> > > > > And if it is not rejected by the kernel.    
> > > > 
> > > > It should not. setkeycodes definitely works on atkbd.
> > > >   
> > > > > And if it does not
> > > > > crash your X server which is very picky about receiving pointer
> > > > > events from a keyboard or the other way around.    
> > > > 
> > > > Sounds like you want to make X server more resilient ;)  
> > > 
> > > This is an inherent design flaw in the X server known for years. It
> > > has separate keyboard and pointer devices and while people are
> > > trying to patch it up occasionally a bug pops out that crashes the
> > > Xserver when an event is received from non-matching device type.
> > > 
> > > Once X server dies and is replaced be Y server or Z server or
> > > whatever it will make life easier in so many ways.  
> > 
> > We already have libinput that tends to replace the Xorg input part (at
> > least everything which is not protocol). 
> 
> And the protocol still has the split to pointer and keyboard. It is
> technically possible to map mouse button presses with XKB but it only
> works in X and is undocumented and really difficult to do. And it does
> not work outside of X.

I never talked about XKB. Libinput has a view on all input devices and
can redirect whatever events it sees into any other input device. From a
X perspective it's as if the emulated button would have been generated
by the touchpad itself.

> 
> > So if the feature is in
> > libinput, it should be available in X.org directly, and you will be
> > saved.
> 
> Not everything uses libinput. So no, using libinput is not the answer.

If you do not want to upgrade and use the latest development tools, then
sure, you can always use the mac_hid emulation. But we will not resurrect
it because it's something from the past.

> 
> Also libinput people suggest to use hwdb for mapping which is back
> to where we were:
> https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html

Libinput people are basically Peter Hutterer alone. And in the keyboard
layout mapping, yes users should use hwdb/systemd for that. In your precise
case, libinput should have a setting that redirect the incoming key onto
a button of a different device. It's not implemented, it's doable, but
you won't receive a NACK as you get here, because you have a valid use
case for it.

> 
> > 
> > >   
> > > > 
> > > > But really, it all is better solved in userspace, where you can
> > > > surface all options to the user. For example Chrome OS uses Alt +
> > > > mouse button (or tap) to do right click, I am sure Gnome or KDE
> > > > has similar support for right and middle buttons.  
> > > 
> > > I do not consider Gnome or KDE more suitable driver for my keyboard
> > > than the Linux kernel. In fact I find both very unsuitable as a
> > > driver, heavyweight, and causing problems with graphical desktop
> > > usability. Not  
> > 
> > Well, with wayland, the compositor embeds the input stack and part of
> > the graphic stack, and it's actually faster than X.
> 
> That's pointless when it does not work as a desktop in practice.
> 
> And it does not make GNOME or KDE a suitable driver for keyboard, even
> if you run Wayland.

I am just not following what is your use case. Do you want to enable
this feature in a TTY, in a full blown desktop, in a plain X that you
launched with "/usr/bin/Xorg"?

And if you just want Xorg with whatever desktop manager/environment, you
should already be using libinput given that xorg-xf86-libinput is now
the only maintained X driver for keyboards and touchpads.

> 
> > 
> > > to mention they cannot be used at all when not running a graphical
> > > desktop and often cause system crashes due to stressing the graphics
> > > hardware.  
> > 
> > If you experience crashes, they are probably bugs, and please report
> > them to the appropriate project.
> 
> And the answer is they know it crashes but it's too much work to fix.
> Or that it works for them and you are just unlucky that all of your
> half dozen cards crash with their driver and they cannot do anything
> about it.
> Maybe next year. Or the year after. Or with different piece of
> hardware. Who knows?
> 

But is this a reason to stop proposing patches to those projects or
report bugs?
We already told you the kernel is not the place. The kernel can do a
lot, true, but when the input maintainer tell you this is not the place,
you should have a pretty good hint that it is not the place.

> > 
> > >   
> > > > 
> > > > Solving this at kernel is wrong place, similarly how we avoid
> > > > parsing user gestures (edge scrolling, 2-finger scrolling,
> > > > pitch/zoom, etc) in kernel. Yes, we have legacy drivers (like
> > > > mousedev) that are artefacts of times when userspace support was
> > > > not there and it made sense to covert everything to emulated
> > > > PS/2, but that time is long gone.  
> > > 
> > > Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping is
> > > something kernel can do, does, and should do.  
> > 
> > Looks like we are all on the same page. Kernel does key mapping
> > already and doesn't do 2-finger scrolling and other gestures.
> > 
> > The difference in approach is that you want the kernel to emulate
> > devices when userspace has much more information to know how to
> > emulate those devices.
> 
> Any piece of software has the information when the user tells it. The
> thing is the kernel is also able to emulate the device and the
> userspace is not. And seriously, this is a hardware problem which is
> simple to solve once for good in kernel. Do you advocate that instead

It is a hardware problem that is not solvable in the kernel (or should
not). Would the keyboard had specific keys designed to send buttons,
yes, we would have do our best. But here you are trying to counter a
hardware design issue by using a hack at the wrong level. That's all we
are saying.

> everyone should set up mouse emulation in N application frameworks and
> implement it in those that miss it?

Well, given the amount of people involved in the input community, you
can be sure that adding this in libinput is just enough.

> 
> > 
> > The kernel job is to forward events from the devices to userspace
> > without losing information and in a standard way. Anything beyond that
> > should be handled in userspace.
>  
> Then why do you do keycode translation at all? 

Because keycode translations are used for fixing hardware when the
keycode sent is non standard, and instead of requiring people to send
kernel patches for it, it's better to ask them to drop a hwdb entry for
them. This doesn't contradict what I said: it helps forwarding a random
event from the device into a standard one.

keycode translation also helps setting layouts on TTY. Because when you
are on a TTY there is not much you can do in userspace to fix it.

> I guess because it is the job of the kernel to make the information
> usable by the applications as well.

Yes and no. The kernel forwards the information in a standard way to
applications. If you want to locally remap any key to any other event,
fine. But it shouldn't be the default.

> 
> > 
> > > 
> > > The difference between the plain mapping and mac mouse emulation is
> > > that mac mouse emulation probably creates a separate pointer device
> > > which is as compatible with legacy software as it gets. Unlike
> > > application-specific solutions it works in any software that accepts
> > > input events including X. And unlike the systemd solution it works
> > > today.  
> > 
> > And we can argue that the issue with the mac mouse emulation is that
> > it filters on all connected keyboard.
> > Meaning that if you connect an external keyboard just from time to
> > time, those two keys will send the emulated buttons instead of
> > sending plain key events.
> 
> Well, that's a limitation of simple solution. 
> 
> > 
> > While on a libinput approach, the filtering will only affect the
> > internal keyboard, making the whole experience better.
> 
> Unless it happens to crash the X server.

How can you know it'll crash the X server when the feature is not even
implemented?

Luckily, Peter is also in charge of XInput, so I guess if it crashes the
server, it will be detected/fixed way before it is public.

> 
> > 
> > > 
> > > Given the state of userspace at this point I find using the mac
> > > mouse emulation most sensible thing to do. Improving the keymap
> > > support in systemd is certainly more flexible so it is the way to
> > > go long term but if a patch is written and accepted today it will
> > > take years until support is commonplace. On the other hand, the
> > > change required in Linux is trivial and updating the kernel without
> > > breaking the whole system is much more viable than updating
> > > systemd.  
> > 
> > With a libinput approach, the time to distro is much reduced (unless
> > you are running a *very* old libinput release that is not ABI
> > compatible anymore).
> 
> There is no libinput approach. They eschew mapping since there is one
> in systemd and one in X already. 

Please see above. Open a bug and we can start talking.

> 
> > 
> > And we can return the argument for the kernel. The time for a new
> > option in the kernel to land in some distribution can also be counted
> > in years.
> > 
> 
> Indeed. However, running own kernel is much more likely to succeed than
> running own systemd.

And recompiling a local libinput is way faster than recompiling the
kernel. I never talked about systemd, but libinput.

Cheers,
Benjamin

> 
> Thanks
> 
> Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek May 30, 2017, 12:56 p.m. UTC | #12

On Tue, 30 May 2017 14:02:55 +0200
Benjamin Tissoires <[e-mail]> wrote:

> On May 30 2017 or thereabouts, Michal Suchánek wrote:
> > On Tue, 30 May 2017 12:33:21 +0200
> > Benjamin Tissoires <[e-mail]> wrote:
> >   
> > > Hi Michal,
> > > 
> > > On May 30 2017 or thereabouts, Michal Suchánek wrote:  
> > > > On Mon, 29 May 2017 22:06:06 -0700
> > > > Dmitry Torokhov <[e-mail]> wrote:
> > > >     
> > > > > On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek
> > > > > wrote:    
> > > > > > On Sun, 28 May 2017 10:55:40 -0700
> > > > > > Dmitry Torokhov <[e-mail]> wrote:
> > > > > >       
> > > > > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek
> > > > > > > wrote:      
> >   
> > > >     
> > > > >     
> > > > > > 
> > > > > > More importantly how is that mapping supposed to be
> > > > > > represented in a hwdb file?
> > > > > > 
> > > > > > The help text in the hwdb file says:
> > > > > > 
> > > > > > # Scan codes are specified as:
> > > > > > #   KEYBOARD_KEY_<hex scan code>=<key code identifier>
> > > > > > # The scan code should be expressed in hex lowercase. The
> > > > > > key codes # are retrieved and normalized from the kernel
> > > > > > input API header.
> > > > > > 
> > > > > > So they are converted in some unspecified way.
> > > > > > 
> > > > > > The example below defines some mappings, presumably:
> > > > > > 
> > > > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*
> > > > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr*
> > > > > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr*
> > > > > >  KEYBOARD_KEY_a5=help                                   #
> > > > > > Fn+F1
> > > > > > KEYBOARD_KEY_a6=setup                                  #
> > > > > > Fn+F2
> > > > > > KEYBOARD_KEY_a7=battery                                #
> > > > > > Fn+F3
> > > > > > 
> > > > > > /usr/include/linux/input-event-codes.h has occurence of
> > > > > > battery in
> > > > > > 
> > > > > > #define KEY_BATTERY		236
> > > > > > 
> > > > > > meaning that the unspecified conversion is probably
> > > > > > performed by
> > > > > > 
> > > > > > 1) stripping KEY_ prefix
> > > > > > 2) converting to lowercase
> > > > > > 
> > > > > > This is what systemd hwdb check script does in reverse when
> > > > > > checking the keycode values.
> > > > > > 
> > > > > > The BTN_LEFT 0x110 value does not conflict with KEY_*
> > > > > > values, though. So technically you could include it in the
> > > > > > keymap. If you had a tool for that.      
> > > > > 
> > > > > Hmm, sounds like you want a patch to udev/systemd. For the
> > > > > kernel there is no difference between keys and buttons,
> > > > > except symbolic names. They all go into dev->keybit and are
> > > > > reported with input_report_key().    
> > > > 
> > > > So the userspace is not ready for this while the kernel already
> > > > has the driver for ages and all that is needed is to enable
> > > > it.    
> > > 
> > > The problem is more that you can have your particular issue solved
> > > here by using this particular driver. But then someone says that
> > > the mapping for right/middle doesn't fit to his/her keyboard
> > > layout, and then we will have to maintain an new set of fancy new
> > > features in a driver that is just legacy.  
> > 
> > The mapping is dynamic. You specify which keycode you translate to
> > which button by writing a sysfs file and if you do not nothing is
> > translated. So far as plain mouse emulation goes this driver is
> > perfectly fine. It will probably not emulate a scrollwheel and other
> > fancy features but that can be solved in later more flexible
> > solution once it is finished. And once it is finished then is the
> > time for retiring this driver.  
> 
> My bad. Still, it doesn't change the fact that this driver should be
> pointless and retired, because it has to be done in userspace.
> 
> >   
> > > 
> > > I concede userspace doesn't have the feature, but you should
> > > really have a look at libinput (i.e. open a bug on
> > > bugs.freedesktop.org) and request the feature here.
> > >   
> > > >     
> > > > >     
> > > > > > And if it is not rejected by the kernel.      
> > > > > 
> > > > > It should not. setkeycodes definitely works on atkbd.
> > > > >     
> > > > > > And if it does not
> > > > > > crash your X server which is very picky about receiving
> > > > > > pointer events from a keyboard or the other way
> > > > > > around.      
> > > > > 
> > > > > Sounds like you want to make X server more resilient ;)    
> > > > 
> > > > This is an inherent design flaw in the X server known for
> > > > years. It has separate keyboard and pointer devices and while
> > > > people are trying to patch it up occasionally a bug pops out
> > > > that crashes the Xserver when an event is received from
> > > > non-matching device type.
> > > > 
> > > > Once X server dies and is replaced be Y server or Z server or
> > > > whatever it will make life easier in so many ways.    
> > > 
> > > We already have libinput that tends to replace the Xorg input
> > > part (at least everything which is not protocol).   
> > 
> > And the protocol still has the split to pointer and keyboard. It is
> > technically possible to map mouse button presses with XKB but it
> > only works in X and is undocumented and really difficult to do. And
> > it does not work outside of X.  
> 
> I never talked about XKB. Libinput has a view on all input devices and
> can redirect whatever events it sees into any other input device.
> From a X perspective it's as if the emulated button would have been
> generated by the touchpad itself.
> 
> >   
> > > So if the feature is in
> > > libinput, it should be available in X.org directly, and you will
> > > be saved.  
> > 
> > Not everything uses libinput. So no, using libinput is not the
> > answer.  
> 
> If you do not want to upgrade and use the latest development tools,
> then sure, you can always use the mac_hid emulation. But we will not
> resurrect it because it's something from the past.
> 
> > 
> > Also libinput people suggest to use hwdb for mapping which is back
> > to where we were:
> > https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html  
> 
> Libinput people are basically Peter Hutterer alone. And in the
> keyboard layout mapping, yes users should use hwdb/systemd for that.
> In your precise case, libinput should have a setting that redirect
> the incoming key onto a button of a different device. It's not
> implemented, it's doable, but you won't receive a NACK as you get
> here, because you have a valid use case for it.

Libinput is not the place either. Libinput is a library for using the
input subsystem, not the input subsystem. So while it might be
advisable to use it when you can there will always be applications that
do not use it and those should receive correct input as well.

> 
> >   
> > >   
> > > >     
> > > > > 
> > > > > But really, it all is better solved in userspace, where you
> > > > > can surface all options to the user. For example Chrome OS
> > > > > uses Alt + mouse button (or tap) to do right click, I am sure
> > > > > Gnome or KDE has similar support for right and middle
> > > > > buttons.    
> > > > 
> > > > I do not consider Gnome or KDE more suitable driver for my
> > > > keyboard than the Linux kernel. In fact I find both very
> > > > unsuitable as a driver, heavyweight, and causing problems with
> > > > graphical desktop usability. Not    
> > > 
> > > Well, with wayland, the compositor embeds the input stack and
> > > part of the graphic stack, and it's actually faster than X.  
> > 
> > That's pointless when it does not work as a desktop in practice.
> > 
> > And it does not make GNOME or KDE a suitable driver for keyboard,
> > even if you run Wayland.  
> 
> I am just not following what is your use case. Do you want to enable
> this feature in a TTY, in a full blown desktop, in a plain X that you
> launched with "/usr/bin/Xorg"?

All of them. Why should my pointer behave differently depending on the
application I run? Is that the 'usability' you had in mind?

Yes, current X server and Wayland uses libinput so those are covered.
Hopefully I will never need to test anything with X server so old that
it does not have libinput based drivers but who knows.

However, not all is X and there are applications using gpm or reading
events directly or whatever which do not run under X. Granted, I do not
use them often but do I have to figure out why the mouse is not working
in those every time I try?

I want a solution that works as uniformly across all system as possible.

> 
> And if you just want Xorg with whatever desktop manager/environment,
> you should already be using libinput given that xorg-xf86-libinput is
> now the only maintained X driver for keyboards and touchpads.
> 
> >   
> > >   
> > > > to mention they cannot be used at all when not running a
> > > > graphical desktop and often cause system crashes due to
> > > > stressing the graphics hardware.    
> > > 
> > > If you experience crashes, they are probably bugs, and please
> > > report them to the appropriate project.  
> > 
> > And the answer is they know it crashes but it's too much work to
> > fix. Or that it works for them and you are just unlucky that all of
> > your half dozen cards crash with their driver and they cannot do
> > anything about it.
> > Maybe next year. Or the year after. Or with different piece of
> > hardware. Who knows?
> >   
> 
> But is this a reason to stop proposing patches to those projects or
> report bugs?

The bugs are reported. I do not have a patch proposal to fix nouveau
locking so it does not trip over itself all the time nor a workaround
for ATOMBIOS bugs that crash the graphics under some less common
circumstances which unfortunately still happen and make affected system
unusable .. unless you are _very_ careful not to trigger them.

> We already told you the kernel is not the place. The kernel can do a
> lot, true, but when the input maintainer tell you this is not the
> place, you should have a pretty good hint that it is not the place.

And it has been clearly determined that if anything the place is
systemd using the in-kernel mapping. However, systemd does not have the
functionality while the mac mouse emulation does.

> 
> > >   
> > > >     
> > > > > 
> > > > > Solving this at kernel is wrong place, similarly how we avoid
> > > > > parsing user gestures (edge scrolling, 2-finger scrolling,
> > > > > pitch/zoom, etc) in kernel. Yes, we have legacy drivers (like
> > > > > mousedev) that are artefacts of times when userspace support
> > > > > was not there and it made sense to covert everything to
> > > > > emulated PS/2, but that time is long gone.    
> > > > 
> > > > Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping
> > > > is something kernel can do, does, and should do.    
> > > 
> > > Looks like we are all on the same page. Kernel does key mapping
> > > already and doesn't do 2-finger scrolling and other gestures.
> > > 
> > > The difference in approach is that you want the kernel to emulate
> > > devices when userspace has much more information to know how to
> > > emulate those devices.  
> > 
> > Any piece of software has the information when the user tells it.
> > The thing is the kernel is also able to emulate the device and the
> > userspace is not. And seriously, this is a hardware problem which is
> > simple to solve once for good in kernel. Do you advocate that
> > instead  
> 
> It is a hardware problem that is not solvable in the kernel (or should
> not). Would the keyboard had specific keys designed to send buttons,
> yes, we would have do our best. But here you are trying to counter a
> hardware design issue by using a hack at the wrong level. That's all
> we are saying.

And if the vendor put a LMB and RMB stickers on some keyboard keys then
it would be fine? I mean then it would be designed to send mouse
buttons even if it sends key events in practice, right :>

Then I can fix it and put a sticker on the key myself :>

> 
> > everyone should set up mouse emulation in N application frameworks
> > and implement it in those that miss it?  
> 
> Well, given the amount of people involved in the input community, you
> can be sure that adding this in libinput is just enough.
> 
> >   
> > > 
> > > The kernel job is to forward events from the devices to userspace
> > > without losing information and in a standard way. Anything beyond
> > > that should be handled in userspace.  
> >  
> > Then why do you do keycode translation at all?   
> 
> Because keycode translations are used for fixing hardware when the
> keycode sent is non standard, and instead of requiring people to send
> kernel patches for it, it's better to ask them to drop a hwdb entry
> for them. This doesn't contradict what I said: it helps forwarding a
> random event from the device into a standard one.
> 
> keycode translation also helps setting layouts on TTY. Because when
> you are on a TTY there is not much you can do in userspace to fix it.

So the kernel *is* responsible for translating the keys to whatever the
user sets up. Because it is the only place possible to make it work for
all applications.

> 
> > I guess because it is the job of the kernel to make the information
> > usable by the applications as well.  
> 
> Yes and no. The kernel forwards the information in a standard way to
> applications. If you want to locally remap any key to any other event,
> fine. But it shouldn't be the default.

And I do not propose for it to be the default. I just want that the
driver to send the different key not be arch-dependent. So you can
build it on any arch if you want to use it. You still have to configure
it to do the translation on your particular system because by default
it does nothing.

> 
> >   
> > >   
> > > > 
> > > > The difference between the plain mapping and mac mouse
> > > > emulation is that mac mouse emulation probably creates a
> > > > separate pointer device which is as compatible with legacy
> > > > software as it gets. Unlike application-specific solutions it
> > > > works in any software that accepts input events including X.
> > > > And unlike the systemd solution it works today.    
> > > 
> > > And we can argue that the issue with the mac mouse emulation is
> > > that it filters on all connected keyboard.
> > > Meaning that if you connect an external keyboard just from time to
> > > time, those two keys will send the emulated buttons instead of
> > > sending plain key events.  
> > 
> > Well, that's a limitation of simple solution. 
> >   
> > > 
> > > While on a libinput approach, the filtering will only affect the
> > > internal keyboard, making the whole experience better.  
> > 
> > Unless it happens to crash the X server.  
> 
> How can you know it'll crash the X server when the feature is not even
> implemented?

It may not, of course.

> 
> Luckily, Peter is also in charge of XInput, so I guess if it crashes
> the server, it will be detected/fixed way before it is public.

Sadly, such bugs escaped more than once and were only found by users
because the mappings which send key presses on a mouse or mouse button
presses on a keyboard are uncommon and not well tested.

> 
> >   
> > >   
> > > > 
> > > > Given the state of userspace at this point I find using the mac
> > > > mouse emulation most sensible thing to do. Improving the keymap
> > > > support in systemd is certainly more flexible so it is the way
> > > > to go long term but if a patch is written and accepted today it
> > > > will take years until support is commonplace. On the other
> > > > hand, the change required in Linux is trivial and updating the
> > > > kernel without breaking the whole system is much more viable
> > > > than updating systemd.    
> > > 
> > > With a libinput approach, the time to distro is much reduced
> > > (unless you are running a *very* old libinput release that is not
> > > ABI compatible anymore).  
> > 
> > There is no libinput approach. They eschew mapping since there is
> > one in systemd and one in X already.   
> 
> Please see above. Open a bug and we can start talking.
> 
> >   
> > > 
> > > And we can return the argument for the kernel. The time for a new
> > > option in the kernel to land in some distribution can also be
> > > counted in years.
> > >   
> > 
> > Indeed. However, running own kernel is much more likely to succeed
> > than running own systemd.  
> 
> And recompiling a local libinput is way faster than recompiling the
> kernel. I never talked about systemd, but libinput.

But you newer showed how implementing a feature in libinput fixes the
problem either.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Peter Hutterer May 31, 2017, 4:26 a.m. UTC | #13

On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote:
> > > > I concede userspace doesn't have the feature, but you should
> > > > really have a look at libinput (i.e. open a bug on
> > > > bugs.freedesktop.org) and request the feature here.
> > > >   
> > > > >     
> > > > > >     
> > > > > > > And if it is not rejected by the kernel.      
> > > > > > 
> > > > > > It should not. setkeycodes definitely works on atkbd.
> > > > > >     
> > > > > > > And if it does not
> > > > > > > crash your X server which is very picky about receiving
> > > > > > > pointer events from a keyboard or the other way
> > > > > > > around.      
> > > > > > 
> > > > > > Sounds like you want to make X server more resilient ;)    
> > > > > 
> > > > > This is an inherent design flaw in the X server known for
> > > > > years. It has separate keyboard and pointer devices and while
> > > > > people are trying to patch it up occasionally a bug pops out
> > > > > that crashes the Xserver when an event is received from
> > > > > non-matching device type.

fwiw, the pointer/keyboard split problem was fixed in xf86-input-libinput
with 1f43f3921f6c in late 2015. it's possible to fix it in the same manner
for the evdev driver, but someone would have to be very motivated.

> > > > > 
> > > > > Once X server dies and is replaced be Y server or Z server or
> > > > > whatever it will make life easier in so many ways.    
> > > > 
> > > > We already have libinput that tends to replace the Xorg input
> > > > part (at least everything which is not protocol).   
> > > 
> > > And the protocol still has the split to pointer and keyboard. It is
> > > technically possible to map mouse button presses with XKB but it
> > > only works in X and is undocumented and really difficult to do. And
> > > it does not work outside of X.  
> > 
> > I never talked about XKB. Libinput has a view on all input devices and
> > can redirect whatever events it sees into any other input device.
> > From a X perspective it's as if the emulated button would have been
> > generated by the touchpad itself.
> > 
> > >   
> > > > So if the feature is in
> > > > libinput, it should be available in X.org directly, and you will
> > > > be saved.  
> > > 
> > > Not everything uses libinput. So no, using libinput is not the
> > > answer.  
> > 
> > If you do not want to upgrade and use the latest development tools,
> > then sure, you can always use the mac_hid emulation. But we will not
> > resurrect it because it's something from the past.
> > 
> > > 
> > > Also libinput people suggest to use hwdb for mapping which is back
> > > to where we were:
> > > https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html  

Note: in this thread I specifically say that remapping for *broken* keys
should go in the hwdb, anything else needs to go into userspace.

> > Libinput people are basically Peter Hutterer alone. And in the
> > keyboard layout mapping, yes users should use hwdb/systemd for that.
> > In your precise case, libinput should have a setting that redirect
> > the incoming key onto a button of a different device. It's not
> > implemented, it's doable, but you won't receive a NACK as you get
> > here, because you have a valid use case for it.
> 
> Libinput is not the place either. Libinput is a library for using the
> input subsystem, not the input subsystem. So while it might be
> advisable to use it when you can there will always be applications that
> do not use it and those should receive correct input as well.

I'm gonna chime in here and say that emulating button events from keys +
mouse events is (probably) not something I'd merge into libinput anyway.
I'd like to see the touchpads that are unable to even detect two fingers
first. I haven't seen one of those released in 8 years and the ones that are
left are probably at the end of their lifecycle. [However, you'll be happy to
know that with libiput 1.7 and 1.6.2 we added clickfinger support for the
apple onebutton touchpads. And that was only January this year. Both users
have been partying non-stop since, I suspect.]

Almost all touchpads these days are clickpads, i.e. they only have a single
(left) button and anything else is software emulated. So anything that
handles touchpads will have to deal with this before too long.

Spoiler alert: libinput was started not just because "Woo Wayland!" but
because the Wayland compositor model requires each compositor to reimplement
input handling. And handling input is hard, even if it doesn't look like it
from a high vantage point. So having this in one central place, ready to be
re-used is the way to go. Anything that doesn't want to use libinput is
welcome to do so but you'll have to mix the ingredients yourself before you
get to eat the cake.

> > > > > > But really, it all is better solved in userspace, where you
> > > > > > can surface all options to the user. For example Chrome OS
> > > > > > uses Alt + mouse button (or tap) to do right click, I am sure
> > > > > > Gnome or KDE has similar support for right and middle
> > > > > > buttons.    
> > > > > 
> > > > > I do not consider Gnome or KDE more suitable driver for my
> > > > > keyboard than the Linux kernel. In fact I find both very
> > > > > unsuitable as a driver, heavyweight, and causing problems with
> > > > > graphical desktop usability. Not    
> > > > 
> > > > Well, with wayland, the compositor embeds the input stack and
> > > > part of the graphic stack, and it's actually faster than X.  
> > > 
> > > That's pointless when it does not work as a desktop in practice.
> > > 
> > > And it does not make GNOME or KDE a suitable driver for keyboard,
> > > even if you run Wayland.  
> > 
> > I am just not following what is your use case. Do you want to enable
> > this feature in a TTY, in a full blown desktop, in a plain X that you
> > launched with "/usr/bin/Xorg"?
> 
> All of them. Why should my pointer behave differently depending on the
> application I run? Is that the 'usability' you had in mind?
> 
> Yes, current X server and Wayland uses libinput so those are covered.
> Hopefully I will never need to test anything with X server so old that
> it does not have libinput based drivers but who knows.
> 
> However, not all is X and there are applications using gpm or reading
> events directly or whatever which do not run under X. Granted, I do not
> use them often but do I have to figure out why the mouse is not working
> in those every time I try?
> 
> I want a solution that works as uniformly across all system as possible.

that puts you in a pickle. you want emulation of features not supported by
the hardware to be pushed into the kernel. I face a similar request most
days where users want features not supported by their toolkit or application
to be pushed into libinput because it's easier. It's not always a good case,
and often the answer is 'no' because long-term, it makes everything harder.

gpm *should* be able to handle this, and applications that read input
directly should handle input. Because there are plenty of other features
that have similar requirements. Have a look at consolation for example which
uses libinput to be similar to gpm
https://alioth.debian.org/projects/consolation/

> > And if you just want Xorg with whatever desktop manager/environment,
> > you should already be using libinput given that xorg-xf86-libinput is
> > now the only maintained X driver for keyboards and touchpads.
> > 
> > >   
> > > >   
> > > > > to mention they cannot be used at all when not running a
> > > > > graphical desktop and often cause system crashes due to
> > > > > stressing the graphics hardware.    
> > > > 
> > > > If you experience crashes, they are probably bugs, and please
> > > > report them to the appropriate project.  
> > > 
> > > And the answer is they know it crashes but it's too much work to
> > > fix. Or that it works for them and you are just unlucky that all of
> > > your half dozen cards crash with their driver and they cannot do
> > > anything about it.
> > > Maybe next year. Or the year after. Or with different piece of
> > > hardware. Who knows?

I don't know why you presume all these answers, but this is not a 
good way to improve the discussion. We don't just exist to make your
hardware work for free, any of us has more than enough work so we have to
select what we work on. This should not come as a surprise.

> > > > > > Solving this at kernel is wrong place, similarly how we avoid
> > > > > > parsing user gestures (edge scrolling, 2-finger scrolling,
> > > > > > pitch/zoom, etc) in kernel. Yes, we have legacy drivers (like
> > > > > > mousedev) that are artefacts of times when userspace support
> > > > > > was not there and it made sense to covert everything to
> > > > > > emulated PS/2, but that time is long gone.    
> > > > > 
> > > > > Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping
> > > > > is something kernel can do, does, and should do.    
> > > > 
> > > > Looks like we are all on the same page. Kernel does key mapping
> > > > already and doesn't do 2-finger scrolling and other gestures.
> > > > 
> > > > The difference in approach is that you want the kernel to emulate
> > > > devices when userspace has much more information to know how to
> > > > emulate those devices.  
> > > 
> > > Any piece of software has the information when the user tells it.
> > > The thing is the kernel is also able to emulate the device and the
> > > userspace is not. And seriously, this is a hardware problem which is
> > > simple to solve once for good in kernel. Do you advocate that
> > > instead  
> > 
> > It is a hardware problem that is not solvable in the kernel (or should
> > not). Would the keyboard had specific keys designed to send buttons,
> > yes, we would have do our best. But here you are trying to counter a
> > hardware design issue by using a hack at the wrong level. That's all
> > we are saying.
> 
> And if the vendor put a LMB and RMB stickers on some keyboard keys then
> it would be fine? I mean then it would be designed to send mouse
> buttons even if it sends key events in practice, right :>
> 
> Then I can fix it and put a sticker on the key myself :>

vendors already put a visual marker on touchpads to signal the left/right
button split but rely on software (libinput or xf86-input-synaptics) to
actually convert it to a right button click. I'm not sure what you're
expecting to achieve with these arguments.

> > > everyone should set up mouse emulation in N application frameworks
> > > and implement it in those that miss it?  
> > 
> > Well, given the amount of people involved in the input community, you
> > can be sure that adding this in libinput is just enough.
> > 
> > >   
> > > > 
> > > > The kernel job is to forward events from the devices to userspace
> > > > without losing information and in a standard way. Anything beyond
> > > > that should be handled in userspace.  
> > >  
> > > Then why do you do keycode translation at all?   
> > 
> > Because keycode translations are used for fixing hardware when the
> > keycode sent is non standard, and instead of requiring people to send
> > kernel patches for it, it's better to ask them to drop a hwdb entry
> > for them. This doesn't contradict what I said: it helps forwarding a
> > random event from the device into a standard one.
> > 
> > keycode translation also helps setting layouts on TTY. Because when
> > you are on a TTY there is not much you can do in userspace to fix it.
> 
> So the kernel *is* responsible for translating the keys to whatever the
> user sets up. Because it is the only place possible to make it work for
> all applications.

within reason. The kernel fixes keys that send *wrong* key events, but it
doesn't remap keys (well, layouts, but that's not the same).

> > Luckily, Peter is also in charge of XInput, so I guess if it crashes
> > the server, it will be detected/fixed way before it is public.
> 
> Sadly, such bugs escaped more than once and were only found by users
> because the mappings which send key presses on a mouse or mouse button
> presses on a keyboard are uncommon and not well tested.

sorry, but if you're expecting bug-free software, you're in the wrong
business. I'm not sure  what you're trying to achieve with these types of
arguments, software that doesn't crash will never happen. And it's
impossible to test all hardware combinations, though I'm sure you'll be
happy to know that libinput has several thousand test cases more than
the X input stack.

Cheers,
   Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek June 7, 2017, 12:29 p.m. UTC | #14

On Wed, 31 May 2017 14:26:52 +1000
Peter Hutterer <[e-mail]> wrote:

> On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote:
> > > > > I concede userspace doesn't have the feature, but you should
> > > > > really have a look at libinput (i.e. open a bug on
> > > > > bugs.freedesktop.org) and request the feature here.
> > > > >     
> > > > > >       
> > > > > > >       
> > > > > > > > And if it is not rejected by the kernel.        
> > > > > > > 
> > > > > > > It should not. setkeycodes definitely works on atkbd.
> > > > > > >       
> > > > > > > > And if it does not
> > > > > > > > crash your X server which is very picky about receiving
> > > > > > > > pointer events from a keyboard or the other way
> > > > > > > > around.        
> > > > > > > 
> > > > > > > Sounds like you want to make X server more
> > > > > > > resilient ;)      
> > > > > > 
> > > > > > This is an inherent design flaw in the X server known for
> > > > > > years. It has separate keyboard and pointer devices and
> > > > > > while people are trying to patch it up occasionally a bug
> > > > > > pops out that crashes the Xserver when an event is received
> > > > > > from non-matching device type.  
> 
> fwiw, the pointer/keyboard split problem was fixed in
> xf86-input-libinput with 1f43f3921f6c in late 2015. it's possible to
> fix it in the same manner for the evdev driver, but someone would
> have to be very motivated.

That is a good news. A problem considered unsurmountable for years is
finally overcome.

> 
> > > > > > 
> > > > > > Once X server dies and is replaced be Y server or Z server
> > > > > > or whatever it will make life easier in so many ways.      
> > > > > 
> > > > > We already have libinput that tends to replace the Xorg input
> > > > > part (at least everything which is not protocol).     
> > > > 
> > > > And the protocol still has the split to pointer and keyboard.
> > > > It is technically possible to map mouse button presses with XKB
> > > > but it only works in X and is undocumented and really difficult
> > > > to do. And it does not work outside of X.    
> > > 
> > > I never talked about XKB. Libinput has a view on all input
> > > devices and can redirect whatever events it sees into any other
> > > input device. From a X perspective it's as if the emulated button
> > > would have been generated by the touchpad itself.

As much as when it is generated by XKB. It is just different layer
inside the X server.

> > >   
> > > >     
> > > > > So if the feature is in
> > > > > libinput, it should be available in X.org directly, and you
> > > > > will be saved.    
> > > > 
> > > > Not everything uses libinput. So no, using libinput is not the
> > > > answer.    
> > > 
> > > If you do not want to upgrade and use the latest development
> > > tools, then sure, you can always use the mac_hid emulation. But
> > > we will not resurrect it because it's something from the past.
> > >   
> > > > 
> > > > Also libinput people suggest to use hwdb for mapping which is
> > > > back to where we were:
> > > > https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html    
> 
> Note: in this thread I specifically say that remapping for *broken*
> keys should go in the hwdb, anything else needs to go into userspace.

These keys are either broken by design or worn down. 
The touchpad contains switches under the touch surface and you press
keys by pressing the touch area and tilting it to one side making it
impossible to press both buttons at once. Or on touchpads that have
separate physical buttons the left button tends to get more use
and wears much faster resulting in different force required to trigger
those two buttons. In either case it is not possible to trigger
gestures that require both buttons pressed simultaneously such as the
X11 middle button emulation so other mapping for mouse buttons is
required.

> 
> > > Libinput people are basically Peter Hutterer alone. And in the
> > > keyboard layout mapping, yes users should use hwdb/systemd for
> > > that. In your precise case, libinput should have a setting that
> > > redirect the incoming key onto a button of a different device.
> > > It's not implemented, it's doable, but you won't receive a NACK
> > > as you get here, because you have a valid use case for it.  
> > 
> > Libinput is not the place either. Libinput is a library for using
> > the input subsystem, not the input subsystem. So while it might be
> > advisable to use it when you can there will always be applications
> > that do not use it and those should receive correct input as well.  
> 
> I'm gonna chime in here and say that emulating button events from
> keys + mouse events is (probably) not something I'd merge into
> libinput anyway. I'd like to see the touchpads that are unable to
> even detect two fingers first. I haven't seen one of those released
> in 8 years and the ones that are left are probably at the end of
> their lifecycle. [However, you'll be happy to know that with libiput
> 1.7 and 1.6.2 we added clickfinger support for the apple onebutton
> touchpads. And that was only January this year. Both users have been
> partying non-stop since, I suspect.]

On the other hand, I would like to see a single touchpad that can
detect two fingers reliably. In absence of such I want to use
multitouch as little as possible relying on input technology not broken
by design - such as physical separate buttons.

> 
> Almost all touchpads these days are clickpads, i.e. they only have a
> single (left) button and anything else is software emulated. So
> anything that handles touchpads will have to deal with this before
> too long.

I don't know where you live. Where I live about half of the notebooks I
coming from decent vendors have touchpads with actual physical
buttons. Two of them. I can understand that fitting something like a
scrollwheel and making it work reliably is too much of an engineering
challenge for laptop makers. So it is fine to use multitouch feature
instead of a scrollwheel. It is not fine to use multitouch for features
that can be feasibly implemented reliably such as multiple mouse
buttons.

> 
> Spoiler alert: libinput was started not just because "Woo Wayland!"
> but because the Wayland compositor model requires each compositor to
> reimplement input handling. And handling input is hard, even if it
> doesn't look like it from a high vantage point. So having this in one
> central place, ready to be re-used is the way to go. Anything that
> doesn't want to use libinput is welcome to do so but you'll have to
> mix the ingredients yourself before you get to eat the cake.

Not everyone writes in C so it is not always easy to use libinput with
their code.

Regardless of that the kernel documentation says that /dev/event* is
the preferred interface to Linux input subsystem. Hence libinput is
only an optional convenience library and correct events should be seen
when read from /dev/event* using libinput or not. If correct for a
particular piece of hardware means that scancode 70065 sends BTN_RIGHT
then applications reading from /dev/event* directly including tools
like evtest should see the scancode and BTN_RIGHT.

> 
> > > > > > > But really, it all is better solved in userspace, where
> > > > > > > you can surface all options to the user. For example
> > > > > > > Chrome OS uses Alt + mouse button (or tap) to do right
> > > > > > > click, I am sure Gnome or KDE has similar support for
> > > > > > > right and middle buttons.      
> > > > > > 
> > > > > > I do not consider Gnome or KDE more suitable driver for my
> > > > > > keyboard than the Linux kernel. In fact I find both very
> > > > > > unsuitable as a driver, heavyweight, and causing problems
> > > > > > with graphical desktop usability. Not      
> > > > > 
> > > > > Well, with wayland, the compositor embeds the input stack and
> > > > > part of the graphic stack, and it's actually faster than
> > > > > X.    
> > > > 
> > > > That's pointless when it does not work as a desktop in practice.
> > > > 
> > > > And it does not make GNOME or KDE a suitable driver for
> > > > keyboard, even if you run Wayland.    
> > > 
> > > I am just not following what is your use case. Do you want to
> > > enable this feature in a TTY, in a full blown desktop, in a plain
> > > X that you launched with "/usr/bin/Xorg"?  
> > 
> > All of them. Why should my pointer behave differently depending on
> > the application I run? Is that the 'usability' you had in mind?
> > 
> > Yes, current X server and Wayland uses libinput so those are
> > covered. Hopefully I will never need to test anything with X server
> > so old that it does not have libinput based drivers but who knows.
> > 
> > However, not all is X and there are applications using gpm or
> > reading events directly or whatever which do not run under X.
> > Granted, I do not use them often but do I have to figure out why
> > the mouse is not working in those every time I try?
> > 
> > I want a solution that works as uniformly across all system as
> > possible.  
> 
> that puts you in a pickle. you want emulation of features not
> supported by the hardware to be pushed into the kernel. I face a
> similar request most days where users want features not supported by
> their toolkit or application to be pushed into libinput because it's
> easier. It's not always a good case, and often the answer is 'no'
> because long-term, it makes everything harder.

The hardware has buttons. Kernel does mapping of hardware buttons to
logical buttons for *every* hardware, anyway. I want it to map my
particular piece of hardware in a way that makes it usable. In every
application.

> 
> gpm *should* be able to handle this, and applications that read input
> directly should handle input. Because there are plenty of other
> features that have similar requirements. Have a look at consolation
> for example which uses libinput to be similar to gpm
> https://alioth.debian.org/projects/consolation/

I was more concerned about applications that used to use GPM for event
input. However, main purpose of GPM was to normalize different mouse
protocols to one event format which the kernel already does with evdev.
GPM protocol did not offer many different events so applications
talking to GPM (if any still remain) can be ported to evdev quite
easily I would expect. Porting to libinput might be a different story
altogether.

> 
> > > And if you just want Xorg with whatever desktop
> > > manager/environment, you should already be using libinput given
> > > that xorg-xf86-libinput is now the only maintained X driver for
> > > keyboards and touchpads. 
> > > >     
> > > > >     
> > > > > > to mention they cannot be used at all when not running a
> > > > > > graphical desktop and often cause system crashes due to
> > > > > > stressing the graphics hardware.      
> > > > > 
> > > > > If you experience crashes, they are probably bugs, and please
> > > > > report them to the appropriate project.    
> > > > 
> > > > And the answer is they know it crashes but it's too much work to
> > > > fix. Or that it works for them and you are just unlucky that
> > > > all of your half dozen cards crash with their driver and they
> > > > cannot do anything about it.
> > > > Maybe next year. Or the year after. Or with different piece of
> > > > hardware. Who knows?  
> 
> I don't know why you presume all these answers, but this is not a 
> good way to improve the discussion. 

I do not presume them. I have seen them as answers to bug reports which
I or other users of the hardware filed.

> We don't just exist to make your
> hardware work for free, any of us has more than enough work so we
> have to select what we work on. This should not come as a surprise.

And it should not come as a surprise that I do not want to use a piece
of software which is huge, gets in the way of using the desktop
environment, and potentially crashes my system due to reliance on
unfinished GPU drivers as a driver for my input device.

I can see it will take huge amount of work to make it stable, and
another huge amount of work to make it usable for me. So I do not
use it and rather want the system base to be fixed so the software that
works right now is usable with the hardware available and right now.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek June 7, 2017, 4:53 p.m. UTC | #15

On Sun, 28 May 2017 10:55:40 -0700
Dmitry Torokhov <[e-mail]> wrote:

> On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> > On Tue, 9 May 2017 17:43:27 -0700
> > Dmitry Torokhov <[e-mail]> wrote:
> >   
> > > Hi Michal,
> > > 
> > > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:  
> > > > There is nothing mac-specific about this driver. Non-mac
> > > > hardware with suboptimal built-in pointer devices exists.
> > > > 
> > > > This makes it possible to use this emulation not only on x86
> > > > and ppc notebooks but also on arm and mips.    
> > > 
> > > I'd rather we did not promote from drivers/macintosh to other
> > > platforms, but rather removed it. The same functionality can be
> > > done from userspace.  
> > 
> > What is the status of this?  
> 
> The same as in above paragraph.
> 
> > 
> > Do you reply to every patch to drivers/input that is not the the
> > core infrastructure that you would rather drop the driver because
> > it can be done is in userspace?
> > 
> > It sure can be done. Remove everything but the bus drivers and
> > uinput from drivers/input and the rest can be done in userspace.
> > 
> > The question is who does it?
> > 
> > Are you saying that you will implement the userspace equivalent?  
> 
> No, I spend my time mostly with the kernel.
> 
> > 
> > If not then please do your job as maintainer and accept trivial
> > patches for perfectly working drivers we have now.  
> 
> I am doing my job as a maintainer right now. The driver might have
> been beneficial 15 years ago, when we did not have better options,
> but I would rather not continue expanding it's use.
> 
> The main problem with the driver is that the functionality it is not
> easily discoverable by end users. And once you plumb it through
> userspace to present users with options you might as well handle it
> all in userspace.
> 
> > 
> > If you want to move drivers/input into userspace I am not against it
> > but I am not willing to do that for you either.  
> 
> Then we are at impasse.
> 
> >   
> > > 
> > > What hardware do you believe would benefit from this and why?  
> > 
> > Any touchpad hardware where you cannot press two buttons at once to
> > emulate the third button due to hardware design. And any touchpad
> > hardware on which some of the buttons are broken when it comes to
> > it.
> > 
> > It is built into a notebook and works fine for moving the cursor but
> > due to lack of usable buttons you still need a mouse to use the
> > notebook.  
> 
> Have you tried simply redefining keymap of your keyboard to emit
> BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> updates from userspace/udev/hwdb and if there is a driver that does
> not support it I will take patches fixing that.

Indeed, they do support it. Such keymap update just does not work as
mouse button regardless of sending the BTN_* event. At least not in X11.

So what is next?

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov June 7, 2017, 5:16 p.m. UTC | #16

On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:
> On Sun, 28 May 2017 10:55:40 -0700
> Dmitry Torokhov <[e-mail]> wrote:
> 
> > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> > > On Tue, 9 May 2017 17:43:27 -0700
> > > Dmitry Torokhov <[e-mail]> wrote:
> > >   
> > > > Hi Michal,
> > > > 
> > > > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek wrote:  
> > > > > There is nothing mac-specific about this driver. Non-mac
> > > > > hardware with suboptimal built-in pointer devices exists.
> > > > > 
> > > > > This makes it possible to use this emulation not only on x86
> > > > > and ppc notebooks but also on arm and mips.    
> > > > 
> > > > I'd rather we did not promote from drivers/macintosh to other
> > > > platforms, but rather removed it. The same functionality can be
> > > > done from userspace.  
> > > 
> > > What is the status of this?  
> > 
> > The same as in above paragraph.
> > 
> > > 
> > > Do you reply to every patch to drivers/input that is not the the
> > > core infrastructure that you would rather drop the driver because
> > > it can be done is in userspace?
> > > 
> > > It sure can be done. Remove everything but the bus drivers and
> > > uinput from drivers/input and the rest can be done in userspace.
> > > 
> > > The question is who does it?
> > > 
> > > Are you saying that you will implement the userspace equivalent?  
> > 
> > No, I spend my time mostly with the kernel.
> > 
> > > 
> > > If not then please do your job as maintainer and accept trivial
> > > patches for perfectly working drivers we have now.  
> > 
> > I am doing my job as a maintainer right now. The driver might have
> > been beneficial 15 years ago, when we did not have better options,
> > but I would rather not continue expanding it's use.
> > 
> > The main problem with the driver is that the functionality it is not
> > easily discoverable by end users. And once you plumb it through
> > userspace to present users with options you might as well handle it
> > all in userspace.
> > 
> > > 
> > > If you want to move drivers/input into userspace I am not against it
> > > but I am not willing to do that for you either.  
> > 
> > Then we are at impasse.
> > 
> > >   
> > > > 
> > > > What hardware do you believe would benefit from this and why?  
> > > 
> > > Any touchpad hardware where you cannot press two buttons at once to
> > > emulate the third button due to hardware design. And any touchpad
> > > hardware on which some of the buttons are broken when it comes to
> > > it.
> > > 
> > > It is built into a notebook and works fine for moving the cursor but
> > > due to lack of usable buttons you still need a mouse to use the
> > > notebook.  
> > 
> > Have you tried simply redefining keymap of your keyboard to emit
> > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > updates from userspace/udev/hwdb and if there is a driver that does
> > not support it I will take patches fixing that.
> 
> Indeed, they do support it. Such keymap update just does not work as
> mouse button regardless of sending the BTN_* event. At least not in X11.
> 
> So what is next?

Teach X11 to handle it properly.

Thanks.

Michal Suchánek June 7, 2017, 7:17 p.m. UTC | #17

On Wed, 7 Jun 2017 10:16:22 -0700
Dmitry Torokhov <[e-mail]> wrote:

> On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:
> > On Sun, 28 May 2017 10:55:40 -0700
> > Dmitry Torokhov <[e-mail]> wrote:
> >   
> > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:  
> > > > On Tue, 9 May 2017 17:43:27 -0700
> > > > Dmitry Torokhov <[e-mail]> wrote:
> > > >     
> > > > > Hi Michal,
> > > > > 
> > > > > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek
> > > > > wrote:    
> > > > > > There is nothing mac-specific about this driver. Non-mac
> > > > > > hardware with suboptimal built-in pointer devices exists.
> > > > > > 
> > > > > > This makes it possible to use this emulation not only on x86
> > > > > > and ppc notebooks but also on arm and mips.      
> > > > > 
> > > > > I'd rather we did not promote from drivers/macintosh to other
> > > > > platforms, but rather removed it. The same functionality can
> > > > > be done from userspace.    
> > > > 
> > > > What is the status of this?    
> > > 
> > > The same as in above paragraph.
> > >   
> > > > 
> > > > Do you reply to every patch to drivers/input that is not the the
> > > > core infrastructure that you would rather drop the driver
> > > > because it can be done is in userspace?
> > > > 
> > > > It sure can be done. Remove everything but the bus drivers and
> > > > uinput from drivers/input and the rest can be done in userspace.
> > > > 
> > > > The question is who does it?
> > > > 
> > > > Are you saying that you will implement the userspace
> > > > equivalent?    
> > > 
> > > No, I spend my time mostly with the kernel.
> > >   
> > > > 
> > > > If not then please do your job as maintainer and accept trivial
> > > > patches for perfectly working drivers we have now.    
> > > 
> > > I am doing my job as a maintainer right now. The driver might have
> > > been beneficial 15 years ago, when we did not have better options,
> > > but I would rather not continue expanding it's use.
> > > 
> > > The main problem with the driver is that the functionality it is
> > > not easily discoverable by end users. And once you plumb it
> > > through userspace to present users with options you might as well
> > > handle it all in userspace.
> > >   
> > > > 
> > > > If you want to move drivers/input into userspace I am not
> > > > against it but I am not willing to do that for you either.    
> > > 
> > > Then we are at impasse.
> > >   
> > > >     
> > > > > 
> > > > > What hardware do you believe would benefit from this and
> > > > > why?    
> > > > 
> > > > Any touchpad hardware where you cannot press two buttons at
> > > > once to emulate the third button due to hardware design. And
> > > > any touchpad hardware on which some of the buttons are broken
> > > > when it comes to it.
> > > > 
> > > > It is built into a notebook and works fine for moving the
> > > > cursor but due to lack of usable buttons you still need a mouse
> > > > to use the notebook.    
> > > 
> > > Have you tried simply redefining keymap of your keyboard to emit
> > > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > > updates from userspace/udev/hwdb and if there is a driver that
> > > does not support it I will take patches fixing that.  
> > 
> > Indeed, they do support it. Such keymap update just does not work as
> > mouse button regardless of sending the BTN_* event. At least not in
> > X11.
> > 
> > So what is next?  
> 
> Teach X11 to handle it properly.
> 
> Thanks.
> 

That's actually libinputs fault. It marks devices with some random
capabilities and when the event does not match capability set it is
dropped.

Adding the capability with /etc/udev/rules.d/xxx-input.rules

ENV{ID_INPUT_KEYBOARD}=="1" ENV{ID_INPUT_MOUSE}="1"

resolves the problem. It must come very late in rules otherwise
something resets it back.

This is inefficient to enable by default because libinput must create
a second shadow X11 device for devices that generate both input and
keyboard events. 
⎡ Virtual core pointer                   id=2   [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer         id=4   [slave  pointer  (2)]
⎜   ↳ DELL Dell USB Entry Keyboard       id=8   [slave  pointer  (2)]
⎜   ↳ PixArt Dell MS116 USB Optical Mouseid=9   [slave  pointer  (2)]
⎣ Virtual core keyboard                  id=3   [master keyboard (2)]
    ↳ Virtual core XTEST keyboard        id=5   [slave  keyboard (3)]
    ↳ Power Button                       id=6   [slave  keyboard (3)]
    ↳ DELL Dell USB Entry Keyboard       id=10  [slave  keyboard (3)]
    ↳ Power Button                       id=7   [slave  keyboard (3)]

Presumably it could infer the capabilities from the supported events
rather than hardcoding them in udev. Surely there are devices with
stub/broken features that do not actually generate events but that is
hopefully not the norm.

Anyway, this mapping is doable with hwdb provided the list of events is
updated to include the BTN_* events. It is quite isolated change to one
header but requires recompiling systemd, unfortunately.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Peter Hutterer June 7, 2017, 11:13 p.m. UTC | #18

On Wed, Jun 07, 2017 at 09:17:37PM +0200, Michal Suchánek wrote:
> On Wed, 7 Jun 2017 10:16:22 -0700
> Dmitry Torokhov <[e-mail]> wrote:
> 
> > On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:
> > > On Sun, 28 May 2017 10:55:40 -0700
> > > Dmitry Torokhov <[e-mail]> wrote:
> > >   
> > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:  
> > > > > On Tue, 9 May 2017 17:43:27 -0700
> > > > > Dmitry Torokhov <[e-mail]> wrote:
> > > > >     
> > > > > > Hi Michal,
> > > > > > 
> > > > > > On Tue, May 09, 2017 at 09:14:18PM +0200, Michal Suchanek
> > > > > > wrote:    
> > > > > > > There is nothing mac-specific about this driver. Non-mac
> > > > > > > hardware with suboptimal built-in pointer devices exists.
> > > > > > > 
> > > > > > > This makes it possible to use this emulation not only on x86
> > > > > > > and ppc notebooks but also on arm and mips.      
> > > > > > 
> > > > > > I'd rather we did not promote from drivers/macintosh to other
> > > > > > platforms, but rather removed it. The same functionality can
> > > > > > be done from userspace.    
> > > > > 
> > > > > What is the status of this?    
> > > > 
> > > > The same as in above paragraph.
> > > >   
> > > > > 
> > > > > Do you reply to every patch to drivers/input that is not the the
> > > > > core infrastructure that you would rather drop the driver
> > > > > because it can be done is in userspace?
> > > > > 
> > > > > It sure can be done. Remove everything but the bus drivers and
> > > > > uinput from drivers/input and the rest can be done in userspace.
> > > > > 
> > > > > The question is who does it?
> > > > > 
> > > > > Are you saying that you will implement the userspace
> > > > > equivalent?    
> > > > 
> > > > No, I spend my time mostly with the kernel.
> > > >   
> > > > > 
> > > > > If not then please do your job as maintainer and accept trivial
> > > > > patches for perfectly working drivers we have now.    
> > > > 
> > > > I am doing my job as a maintainer right now. The driver might have
> > > > been beneficial 15 years ago, when we did not have better options,
> > > > but I would rather not continue expanding it's use.
> > > > 
> > > > The main problem with the driver is that the functionality it is
> > > > not easily discoverable by end users. And once you plumb it
> > > > through userspace to present users with options you might as well
> > > > handle it all in userspace.
> > > >   
> > > > > 
> > > > > If you want to move drivers/input into userspace I am not
> > > > > against it but I am not willing to do that for you either.    
> > > > 
> > > > Then we are at impasse.
> > > >   
> > > > >     
> > > > > > 
> > > > > > What hardware do you believe would benefit from this and
> > > > > > why?    
> > > > > 
> > > > > Any touchpad hardware where you cannot press two buttons at
> > > > > once to emulate the third button due to hardware design. And
> > > > > any touchpad hardware on which some of the buttons are broken
> > > > > when it comes to it.
> > > > > 
> > > > > It is built into a notebook and works fine for moving the
> > > > > cursor but due to lack of usable buttons you still need a mouse
> > > > > to use the notebook.    
> > > > 
> > > > Have you tried simply redefining keymap of your keyboard to emit
> > > > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap
> > > > updates from userspace/udev/hwdb and if there is a driver that
> > > > does not support it I will take patches fixing that.  
> > > 
> > > Indeed, they do support it. Such keymap update just does not work as
> > > mouse button regardless of sending the BTN_* event. At least not in
> > > X11.
> > > 
> > > So what is next?  
> > 
> > Teach X11 to handle it properly.
> > 
> > Thanks.
> > 
> 
> That's actually libinputs fault. It marks devices with some random
> capabilities and when the event does not match capability set it is
> dropped.

just because it's not immediately apparent doesn't mean it's random.
We use ID_INPUT_* from udev to determine the device capabilities. In some
cases we override it when we have some information udev doesn't have. e.g.
we disable gestures on some touchpads known to be inaccurate for
multi-finger gestures. or on some devices we disable event codes because the
device doesn't actually have them. see my explanation here:
https://who-t.blogspot.com.au/2015/06/libinput-and-lack-of-device-types.html

the reason we do it this way is so that a) all of the stack can agree on a
device's device type and b) you can override many misdetections with a hwdb
entry or a custom udev rule rather than waiting for a new libinput release
that encodes the new magic.

> Adding the capability with /etc/udev/rules.d/xxx-input.rules
> 
> ENV{ID_INPUT_KEYBOARD}=="1" ENV{ID_INPUT_MOUSE}="1"
> 
> resolves the problem. It must come very late in rules otherwise
> something resets it back.
> 
> This is inefficient to enable by default because libinput must create
> a second shadow X11 device for devices that generate both input and
> keyboard events. 

false. xf86-input-libinput has to do this. libinput doesn't do it, it's
capable of one device having multiple capabilities. due to the previously
mentioned design restrictions in the X server, this is the most efficient
way to work around it. if xf86-input-evdev supported multi-type devices, it
would have to do the same thing.

> ⎡ Virtual core pointer                   id=2   [master pointer  (3)]
> ⎜   ↳ Virtual core XTEST pointer         id=4   [slave  pointer  (2)]
> ⎜   ↳ DELL Dell USB Entry Keyboard       id=8   [slave  pointer  (2)]
> ⎜   ↳ PixArt Dell MS116 USB Optical Mouseid=9   [slave  pointer  (2)]
> ⎣ Virtual core keyboard                  id=3   [master keyboard (2)]
>     ↳ Virtual core XTEST keyboard        id=5   [slave  keyboard (3)]
>     ↳ Power Button                       id=6   [slave  keyboard (3)]
>     ↳ DELL Dell USB Entry Keyboard       id=10  [slave  keyboard (3)]
>     ↳ Power Button                       id=7   [slave  keyboard (3)]
> 
> Presumably it could infer the capabilities from the supported events
> rather than hardcoding them in udev. Surely there are devices with
> stub/broken features that do not actually generate events but that is
> hopefully not the norm.

how do you think udev decides on the device type? it looks at the supported
events and then picks a type based on that.
https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-input_id.c
"presumably, it could..." is btw a perfect example of how everything looks
simple when viewed from enough distance...

Anyway, I'm done here. If you have any specific technical questions feel
free to ask, but this is enough time wasted arguing. The one question that
hasn't been asked yet though: what specific device are we talking about
here? That may put the "broken by design" claims into a better perspective.

Cheers,
   Peter

> Anyway, this mapping is doable with hwdb provided the list of events is
> updated to include the BTN_* events. It is quite isolated change to one
> header but requires recompiling systemd, unfortunately.
> 
> Thanks
> 
> Michal
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek June 8, 2017, 1:18 p.m. UTC | #19

On Thu, 8 Jun 2017 09:13:03 +1000
Peter Hutterer <[e-mail]> wrote:

> On Wed, Jun 07, 2017 at 09:17:37PM +0200, Michal Suchánek wrote:
> > On Wed, 7 Jun 2017 10:16:22 -0700
> > Dmitry Torokhov <[e-mail]> wrote:
> >   
> > > On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:  
> > > > On Sun, 28 May 2017 10:55:40 -0700
> > > > Dmitry Torokhov <[e-mail]> wrote:
> > > >     
> > > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek
> > > > > wrote:    
> > > > > > On Tue, 9 May 2017 17:43:27 -0700
> > > > > > Dmitry Torokhov <[e-mail]> wrote:
    
> > > > > >       
> > > > > > > 
> > > > > > > What hardware do you believe would benefit from this and
> > > > > > > why?      
> > > > > > 
> > > > > > Any touchpad hardware where you cannot press two buttons at
> > > > > > once to emulate the third button due to hardware design. And
> > > > > > any touchpad hardware on which some of the buttons are
> > > > > > broken when it comes to it.
> > > > > > 
> > > > > > It is built into a notebook and works fine for moving the
> > > > > > cursor but due to lack of usable buttons you still need a
> > > > > > mouse to use the notebook.      
> > > > > 
> > > > > Have you tried simply redefining keymap of your keyboard to
> > > > > emit BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards
> > > > > support keymap updates from userspace/udev/hwdb and if there
> > > > > is a driver that does not support it I will take patches
> > > > > fixing that.    
> > > > 
> > > > Indeed, they do support it. Such keymap update just does not
> > > > work as mouse button regardless of sending the BTN_* event. At
> > > > least not in X11.
> > > > 
> > > > So what is next?    
> > > 
> > > Teach X11 to handle it properly.
> > > 
> > > Thanks.
> > >   
> > 
> > That's actually libinputs fault. It marks devices with some random
> > capabilities and when the event does not match capability set it is
> > dropped.  
> 
> just because it's not immediately apparent doesn't mean it's random.
> We use ID_INPUT_* from udev to determine the device capabilities. In
> some cases we override it when we have some information udev doesn't
> have. e.g. we disable gestures on some touchpads known to be
> inaccurate for multi-finger gestures. or on some devices we disable
> event codes because the device doesn't actually have them. see my
> explanation here:
> https://who-t.blogspot.com.au/2015/06/libinput-and-lack-of-device-types.html
> 
> the reason we do it this way is so that a) all of the stack can agree
> on a device's device type and b) you can override many misdetections
> with a hwdb entry or a custom udev rule rather than waiting for a new
> libinput release that encodes the new magic.
> 
> > Adding the capability with /etc/udev/rules.d/xxx-input.rules
> > 
> > ENV{ID_INPUT_KEYBOARD}=="1" ENV{ID_INPUT_MOUSE}="1"
> > 
> > resolves the problem. It must come very late in rules otherwise
> > something resets it back.
> > 
> > This is inefficient to enable by default because libinput must
> > create a second shadow X11 device for devices that generate both
> > input and keyboard events.   
> 
> false. xf86-input-libinput has to do this. libinput doesn't do it,
> it's capable of one device having multiple capabilities. due to the
> previously mentioned design restrictions in the X server, this is the
> most efficient way to work around it. if xf86-input-evdev supported
> multi-type devices, it would have to do the same thing.

And that's argument just for the sake of arguing or what?

> 
> > ⎡ Virtual core pointer                   id=2   [master pointer
> > (3)] ⎜   ↳ Virtual core XTEST pointer         id=4   [slave
> > pointer  (2)] ⎜   ↳ DELL Dell USB Entry Keyboard       id=8
> > [slave  pointer  (2)] ⎜   ↳ PixArt Dell MS116 USB Optical
> > Mouseid=9   [slave  pointer  (2)] ⎣ Virtual core
> > keyboard                  id=3   [master keyboard (2)] ↳ Virtual
> > core XTEST keyboard        id=5   [slave  keyboard (3)] ↳ Power
> > Button                       id=6   [slave  keyboard (3)] ↳ DELL
> > Dell USB Entry Keyboard       id=10  [slave  keyboard (3)] ↳ Power
> > Button                       id=7   [slave  keyboard (3)]
> > 
> > Presumably it could infer the capabilities from the supported events
> > rather than hardcoding them in udev. Surely there are devices with
> > stub/broken features that do not actually generate events but that
> > is hopefully not the norm.  
> 
> how do you think udev decides on the device type? it looks at the
> supported events and then picks a type based on that.
> https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-input_id.c
> "presumably, it could..." is btw a perfect example of how everything
> looks simple when viewed from enough distance...

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:

> 
> Anyway, I'm done here. If you have any specific technical questions
> feel free to ask, but this is enough time wasted arguing. The one
So from the distance of evtest it looks like it supports mouse buttons
yet from the distance of libinput it does not. So maybe libinput needs
to take a step back from the keyboard to see that? 

Like maybe assigning the classes after it went through the hwdb fixups.

> question that hasn't been asked yet though: what specific device are
> we talking about here? That may put the "broken by design" claims
> into a better perspective.

Which part broken by design do you mean, exactly?

There are too many when it comes to input devices to be able to tell.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Peter Hutterer June 8, 2017, 11:07 p.m. UTC | #20

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?

Cheers,
   Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov June 8, 2017, 11:18 p.m. UTC | #21

On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer <[e-mail]> 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.

Michal Suchánek June 9, 2017, 11:39 a.m. UTC | #22

On Thu, 8 Jun 2017 16:18:28 -0700
Dmitry Torokhov <[e-mail]> wrote:

> On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> <[e-mail]> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Peter Hutterer June 10, 2017, 2 a.m. UTC | #23

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 <[e-mail]> wrote:
> 
> > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > <[e-mail]> 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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek June 12, 2017, 11:40 a.m. UTC | #24

On Sat, 10 Jun 2017 12:00:22 +1000
Peter Hutterer <[e-mail]> 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 <[e-mail]> wrote:
> >   
> > > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > > <[e-mail]> 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.

> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michal Suchánek June 12, 2017, 1:27 p.m. UTC | #25

On Mon, 12 Jun 2017 13:40:07 +0200
Michal Suchánek <[e-mail]> wrote:

> On Sat, 10 Jun 2017 12:00:22 +1000
> Peter Hutterer <[e-mail]> 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 <[e-mail]> wrote:
> > >     
> > > > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > > > <[e-mail]> 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

> 
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 89ebb8f39fee..5533fd3a113f 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -12,6 +12,26 @@  menuconfig INPUT_MOUSE
 
 if INPUT_MOUSE
 
+config MAC_EMUMOUSEBTN
+	tristate "Support for mouse button 2+3 emulation"
+	depends on SYSCTL && INPUT
+	help
+	  This provides generic support for emulating the 2nd and 3rd mouse
+	  button with keypresses.  If you say Y here, the emulation is still
+	  disabled by default.  The emulation is controlled by these sysctl
+	  entries:
+	  /proc/sys/dev/mac_hid/mouse_button_emulation
+	  /proc/sys/dev/mac_hid/mouse_button2_keycode
+	  /proc/sys/dev/mac_hid/mouse_button3_keycode
+
+	  If you have an Apple machine with a 1-button mouse, say Y here.
+
+	  This emulation can be useful on notebooks with suboptimal touchpad
+	  hardware as well.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called mac_hid.
+
 config MOUSE_PS2
 	tristate "PS/2 mouse"
 	default y
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 56bf0ad877c6..dfaad1dd8857 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -4,6 +4,7 @@ 
 
 # Each configuration option enables a list of files.
 
+obj-$(CONFIG_MAC_EMUMOUSEBTN)		+= mac_hid.o
 obj-$(CONFIG_MOUSE_AMIGA)		+= amimouse.o
 obj-$(CONFIG_MOUSE_APPLETOUCH)		+= appletouch.o
 obj-$(CONFIG_MOUSE_ATARI)		+= atarimouse.o
diff --git a/drivers/macintosh/mac_hid.c b/drivers/input/mouse/mac_hid.c
similarity index 100%
rename from drivers/macintosh/mac_hid.c
rename to drivers/input/mouse/mac_hid.c
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 97a420c11eed..011df09c5167 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -159,23 +159,6 @@  config INPUT_ADBHID
 
 	  If unsure, say Y.
 
-config MAC_EMUMOUSEBTN
-	tristate "Support for mouse button 2+3 emulation"
-	depends on SYSCTL && INPUT
-	help
-	  This provides generic support for emulating the 2nd and 3rd mouse
-	  button with keypresses.  If you say Y here, the emulation is still
-	  disabled by default.  The emulation is controlled by these sysctl
-	  entries:
-	  /proc/sys/dev/mac_hid/mouse_button_emulation
-	  /proc/sys/dev/mac_hid/mouse_button2_keycode
-	  /proc/sys/dev/mac_hid/mouse_button3_keycode
-
-	  If you have an Apple machine with a 1-button mouse, say Y here.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called mac_hid.
-
 config THERM_WINDTUNNEL
 	tristate "Support for thermal management on Windtunnel G4s"
 	depends on I2C && I2C_POWERMAC && PPC_PMAC && !PPC_PMAC64
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 516eb65bcacc..ab8b1e74d160 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -7,7 +7,6 @@ 
 obj-$(CONFIG_PPC_PMAC)		+= macio_asic.o macio_sysfs.o
 
 obj-$(CONFIG_PMAC_MEDIABAY)	+= mediabay.o
-obj-$(CONFIG_MAC_EMUMOUSEBTN)	+= mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID)	+= adbhid.o
 obj-$(CONFIG_ANSLCD)		+= ans-lcd.o