Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1652080 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Michal Suchanek <msuchanek@suse.de> - 2017-05-28 11:50 +0200
    Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Bastien Nocera <hadess@hadess.net> - 2017-05-28 15:30 +0200
    Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-28 20:00 +0200
      Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Michal Suchánek <msuchanek@suse.de> - 2017-05-29 20:10 +0200
        Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-30 07:10 +0200
          Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Michal Suchánek <msuchanek@suse.de> - 2017-05-30 11:40 +0200
            Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2017-05-30 12:40 +0200
              Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Michal Suchánek <msuchanek@suse.de> - 2017-05-30 13:40 +0200
                Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2017-05-30 14:10 +0200
                  Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Michal Suchánek <msuchanek@suse.de> - 2017-05-30 15:00 +0200
                    Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Peter Hutterer <peter.hutterer@who-t.net> - 2017-05-31 06:30 +0200
                      Re: [PATCH] macintosh: move mac_hid driver to input/mouse. Michal Suchánek <msuchanek@suse.de> - 2017-06-07 14:40 +0200

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

On Tue, 9 May 2017 17:43:27 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <msuchanek@suse.de>
> > ---
> >  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
> >   
> 

[toc] | [next] | [standalone]

#1652125

On Sun, 2017-05-28 at 11:47 +0200, Michal Suchanek wrote:
> On Tue, 9 May 2017 17:43:27 -0700
> Dmitry Torokhov <dmitry.torokhov@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#1652187

On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:
> On Tue, 9 May 2017 17:43:27 -0700
> Dmitry Torokhov <dmitry.torokhov@gmail.com> 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.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1652681

On Sun, 28 May 2017 10:55:40 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1652813

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 <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1653043

On Mon, 29 May 2017 22:06:06 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1653090

Hi Michal,

On May 30 2017 or thereabouts, Michal Suchánek wrote:
> On Mon, 29 May 2017 22:06:06 -0700
> Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1653142

On Tue, 30 May 2017 12:33:21 +0200
Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:

> Hi Michal,
> 
> On May 30 2017 or thereabouts, Michal Suchánek wrote:
> > On Mon, 29 May 2017 22:06:06 -0700
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1653165

On May 30 2017 or thereabouts, Michal Suchánek wrote:
> On Tue, 30 May 2017 12:33:21 +0200
> Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> 
> > Hi Michal,
> > 
> > On May 30 2017 or thereabouts, Michal Suchánek wrote:
> > > On Mon, 29 May 2017 22:06:06 -0700
> > > Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1653216

On Tue, 30 May 2017 14:02:55 +0200
Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:

> On May 30 2017 or thereabouts, Michal Suchánek wrote:
> > On Tue, 30 May 2017 12:33:21 +0200
> > Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> >   
> > > Hi Michal,
> > > 
> > > On May 30 2017 or thereabouts, Michal Suchánek wrote:  
> > > > On Mon, 29 May 2017 22:06:06 -0700
> > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1653828

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

[toc] | [prev] | [next] | [standalone]

#1659757

On Wed, 31 May 2017 14:26:52 +1000
Peter Hutterer <peter.hutterer@who-t.net> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web