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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

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

Signed-off-by: Michal Suchanek <[hidden email]>
---
 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dmitry Torokhov-4
Hi Michal,

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

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

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

Thanks.

>
> Signed-off-by: Michal Suchanek <[hidden email]>
> ---
>  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
>

--
Dmitry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Suchánek
On 2017-05-10 02:43, Dmitry Torokhov wrote:

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

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

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

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

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

Thanks

Michal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Suchánek
In reply to this post by Dmitry Torokhov-4
On Tue, 9 May 2017 17:43:27 -0700
Dmitry Torokhov <[hidden email]> 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 <[hidden email]>
> > ---
> >  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
> >  
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bastien Nocera
On Sun, 2017-05-28 at 11:47 +0200, Michal Suchanek wrote:

> On Tue, 9 May 2017 17:43:27 -0700
> Dmitry Torokhov <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dmitry Torokhov-4
In reply to this post by Michal Suchánek
On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote:

> On Tue, 9 May 2017 17:43:27 -0700
> Dmitry Torokhov <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

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

So what is next?

Thanks

Michal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dmitry Torokhov-4
On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:

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

Teach X11 to handle it properly.

Thanks.

--
Dmitry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Suchánek
On Wed, 7 Jun 2017 10:16:22 -0700
Dmitry Torokhov <[hidden email]> wrote:

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

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

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

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

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

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

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

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

Thanks

Michal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Peter Hutterer
On Wed, Jun 07, 2017 at 09:17:37PM +0200, Michal Suchánek wrote:

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

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

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

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

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

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

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

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

Cheers,
   Peter

> Anyway, this mapping is doable with hwdb provided the list of events is
> updated to include the BTN_* events. It is quite isolated change to one
> header but requires recompiling systemd, unfortunately.
>
> Thanks
>
> Michal
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Suchánek
On Thu, 8 Jun 2017 09:13:03 +1000
Peter Hutterer <[hidden email]> wrote:

> On Wed, Jun 07, 2017 at 09:17:37PM +0200, Michal Suchánek wrote:
> > On Wed, 7 Jun 2017 10:16:22 -0700
> > Dmitry Torokhov <[hidden email]> wrote:
> >  
> > > On Wed, Jun 07, 2017 at 06:53:51PM +0200, Michal Suchánek wrote:  
> > > > On Sun, 28 May 2017 10:55:40 -0700
> > > > Dmitry Torokhov <[hidden email]> 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 <[hidden email]> wrote:
   

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

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

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

This is what evtest reports about my keyboard:

Select the device event number [0-12]: 2
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111
Input device name: "DELL Dell USB Entry Keyboard"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 1 (KEY_ESC)
    Event code 2 (KEY_1)
    Event code 3 (KEY_2)
    Event code 4 (KEY_3)
...
    Event code 193 (KEY_F23)
    Event code 194 (KEY_F24)
    Event code 240 (KEY_UNKNOWN)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
  Event type 17 (EV_LED)
    Event code 0 (LED_NUML) state 1
    Event code 1 (LED_CAPSL) state 0
    Event code 2 (LED_SCROLLL) state 0
    Event code 3 (LED_COMPOSE) state 0
    Event code 4 (LED_KANA) state 0
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    250
    Repeat code 1 (REP_PERIOD)
      Value     33
Properties:

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

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

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

Which part broken by design do you mean, exactly?

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

Thanks

Michal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Peter Hutterer
On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote:

> This is what evtest reports about my keyboard:
>
> Select the device event number [0-12]: 2
> Input driver version is 1.0.1
> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111
> Input device name: "DELL Dell USB Entry Keyboard"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 1 (EV_KEY)
>     Event code 1 (KEY_ESC)
>     Event code 2 (KEY_1)
>     Event code 3 (KEY_2)
>     Event code 4 (KEY_3)
> ...
>     Event code 193 (KEY_F23)
>     Event code 194 (KEY_F24)
>     Event code 240 (KEY_UNKNOWN)
>     Event code 272 (BTN_LEFT)
>     Event code 273 (BTN_RIGHT)
>     Event code 274 (BTN_MIDDLE)
>   Event type 4 (EV_MSC)
>     Event code 4 (MSC_SCAN)
>   Event type 17 (EV_LED)
>     Event code 0 (LED_NUML) state 1
>     Event code 1 (LED_CAPSL) state 0
>     Event code 2 (LED_SCROLLL) state 0
>     Event code 3 (LED_COMPOSE) state 0
>     Event code 4 (LED_KANA) state 0
> Key repeat handling:
>   Repeat type 20 (EV_REP)
>     Repeat code 0 (REP_DELAY)
>       Value    250
>     Repeat code 1 (REP_PERIOD)
>       Value     33
> Properties:

looks like it's not tagged as ID_INPUT_MOUSE by the default udev rules
because for that we need x/y axes (either relative for real mice or absolute
ones for the VMWare USB mouse). This keyboard only has buttons though. So it
gets ID_INPUT_KEYBOARD for the keys, but no ID_INPUT_MOUSE.

Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard" but the
few pictures I can find all point to a keyboard that doesn't have any
physical mouse buttons at all. Does yours have buttons? Can you post a
picture of it somewhere?

Cheers,
   Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dmitry Torokhov-4
On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer <[hidden email]> wrote:

> On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote:
>> This is what evtest reports about my keyboard:
>>
>> Select the device event number [0-12]: 2
>> Input driver version is 1.0.1
>> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111
>> Input device name: "DELL Dell USB Entry Keyboard"
>> Supported events:
>>   Event type 0 (EV_SYN)
>>   Event type 1 (EV_KEY)
>>     Event code 1 (KEY_ESC)
>>     Event code 2 (KEY_1)
>>     Event code 3 (KEY_2)
>>     Event code 4 (KEY_3)
>> ...
>>     Event code 193 (KEY_F23)
>>     Event code 194 (KEY_F24)
>>     Event code 240 (KEY_UNKNOWN)
>>     Event code 272 (BTN_LEFT)
>>     Event code 273 (BTN_RIGHT)
>>     Event code 274 (BTN_MIDDLE)
>>   Event type 4 (EV_MSC)
>>     Event code 4 (MSC_SCAN)
>>   Event type 17 (EV_LED)
>>     Event code 0 (LED_NUML) state 1
>>     Event code 1 (LED_CAPSL) state 0
>>     Event code 2 (LED_SCROLLL) state 0
>>     Event code 3 (LED_COMPOSE) state 0
>>     Event code 4 (LED_KANA) state 0
>> Key repeat handling:
>>   Repeat type 20 (EV_REP)
>>     Repeat code 0 (REP_DELAY)
>>       Value    250
>>     Repeat code 1 (REP_PERIOD)
>>       Value     33
>> Properties:
>
> looks like it's not tagged as ID_INPUT_MOUSE by the default udev rules
> because for that we need x/y axes (either relative for real mice or absolute
> ones for the VMWare USB mouse). This keyboard only has buttons though. So it
> gets ID_INPUT_KEYBOARD for the keys, but no ID_INPUT_MOUSE.
>
> Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard" but the
> few pictures I can find all point to a keyboard that doesn't have any
> physical mouse buttons at all. Does yours have buttons? Can you post a
> picture of it somewhere?
>

Michal is using udev/hwdb to replace some of the keys on his keyboard
to generate BTN_RIGHT/BTN_MIDDLE trying to achive the same end result
as with mac_hid. It is not the default keyboard behavior. Having
another custom udev rule to mark the device as ID_INPUT_MOUSE is a
fair requirement in this case I think.

--
Dmitry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Suchánek
On Thu, 8 Jun 2017 16:18:28 -0700
Dmitry Torokhov <[hidden email]> wrote:

> On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> <[hidden email]> wrote:
> > On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote:  
> >> This is what evtest reports about my keyboard:
> >>
> >> Select the device event number [0-12]: 2
> >> Input driver version is 1.0.1
> >> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111
> >> Input device name: "DELL Dell USB Entry Keyboard"
> >> Supported events:
> >>   Event type 0 (EV_SYN)
> >>   Event type 1 (EV_KEY)
> >>     Event code 1 (KEY_ESC)
> >>     Event code 2 (KEY_1)
> >>     Event code 3 (KEY_2)
> >>     Event code 4 (KEY_3)
> >> ...
> >>     Event code 193 (KEY_F23)
> >>     Event code 194 (KEY_F24)
> >>     Event code 240 (KEY_UNKNOWN)
> >>     Event code 272 (BTN_LEFT)
> >>     Event code 273 (BTN_RIGHT)
> >>     Event code 274 (BTN_MIDDLE)
> >>   Event type 4 (EV_MSC)
> >>     Event code 4 (MSC_SCAN)
> >>   Event type 17 (EV_LED)
> >>     Event code 0 (LED_NUML) state 1
> >>     Event code 1 (LED_CAPSL) state 0
> >>     Event code 2 (LED_SCROLLL) state 0
> >>     Event code 3 (LED_COMPOSE) state 0
> >>     Event code 4 (LED_KANA) state 0
> >> Key repeat handling:
> >>   Repeat type 20 (EV_REP)
> >>     Repeat code 0 (REP_DELAY)
> >>       Value    250
> >>     Repeat code 1 (REP_PERIOD)
> >>       Value     33
> >> Properties:  
> >
> > looks like it's not tagged as ID_INPUT_MOUSE by the default udev
> > rules because for that we need x/y axes (either relative for real
> > mice or absolute ones for the VMWare USB mouse). This keyboard only
> > has buttons though. So it gets ID_INPUT_KEYBOARD for the keys, but
> > no ID_INPUT_MOUSE.
> >
> > Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard"
> > but the few pictures I can find all point to a keyboard that
> > doesn't have any physical mouse buttons at all. Does yours have
> > buttons? Can you post a picture of it somewhere?
> >  
>
> Michal is using udev/hwdb to replace some of the keys on his keyboard
> to generate BTN_RIGHT/BTN_MIDDLE trying to achive the same end result
> as with mac_hid. It is not the default keyboard behavior. Having
> another custom udev rule to mark the device as ID_INPUT_MOUSE is a
> fair requirement in this case I think.
>

Which is done in different place, and uses device matching with
completely different patterns. So for this to work reasonably either

 - all devices should have all capabilities by default
 - the capabilities should be detected based on the events actually
   available on the device

And if my keyboard actually claimed to have relative axis because of
some great firmware engineering on the manufacturer's part and I found
how to remove them in hwdb it would not take effect either.

Thanks

Michal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Peter Hutterer
On Fri, Jun 09, 2017 at 01:39:53PM +0200, Michal Suchánek wrote:

> On Thu, 8 Jun 2017 16:18:28 -0700
> Dmitry Torokhov <[hidden email]> wrote:
>
> > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > <[hidden email]> wrote:
> > > On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek wrote:  
> > >> This is what evtest reports about my keyboard:
> > >>
> > >> Select the device event number [0-12]: 2
> > >> Input driver version is 1.0.1
> > >> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version 0x111
> > >> Input device name: "DELL Dell USB Entry Keyboard"
> > >> Supported events:
> > >>   Event type 0 (EV_SYN)
> > >>   Event type 1 (EV_KEY)
> > >>     Event code 1 (KEY_ESC)
> > >>     Event code 2 (KEY_1)
> > >>     Event code 3 (KEY_2)
> > >>     Event code 4 (KEY_3)
> > >> ...
> > >>     Event code 193 (KEY_F23)
> > >>     Event code 194 (KEY_F24)
> > >>     Event code 240 (KEY_UNKNOWN)
> > >>     Event code 272 (BTN_LEFT)
> > >>     Event code 273 (BTN_RIGHT)
> > >>     Event code 274 (BTN_MIDDLE)
> > >>   Event type 4 (EV_MSC)
> > >>     Event code 4 (MSC_SCAN)
> > >>   Event type 17 (EV_LED)
> > >>     Event code 0 (LED_NUML) state 1
> > >>     Event code 1 (LED_CAPSL) state 0
> > >>     Event code 2 (LED_SCROLLL) state 0
> > >>     Event code 3 (LED_COMPOSE) state 0
> > >>     Event code 4 (LED_KANA) state 0
> > >> Key repeat handling:
> > >>   Repeat type 20 (EV_REP)
> > >>     Repeat code 0 (REP_DELAY)
> > >>       Value    250
> > >>     Repeat code 1 (REP_PERIOD)
> > >>       Value     33
> > >> Properties:  
> > >
> > > looks like it's not tagged as ID_INPUT_MOUSE by the default udev
> > > rules because for that we need x/y axes (either relative for real
> > > mice or absolute ones for the VMWare USB mouse). This keyboard only
> > > has buttons though. So it gets ID_INPUT_KEYBOARD for the keys, but
> > > no ID_INPUT_MOUSE.
> > >
> > > Google isn't overly forthcoming on "DELL Dell USB Entry Keyboard"
> > > but the few pictures I can find all point to a keyboard that
> > > doesn't have any physical mouse buttons at all. Does yours have
> > > buttons? Can you post a picture of it somewhere?
> > >  
> >
> > Michal is using udev/hwdb to replace some of the keys on his keyboard
> > to generate BTN_RIGHT/BTN_MIDDLE trying to achive the same end result
> > as with mac_hid. It is not the default keyboard behavior. Having
> > another custom udev rule to mark the device as ID_INPUT_MOUSE is a
> > fair requirement in this case I think.
> >
>
> Which is done in different place, and uses device matching with
> completely different patterns. So for this to work reasonably either
>
>  - all devices should have all capabilities by default
>  - the capabilities should be detected based on the events actually
>    available on the device
>
> And if my keyboard actually claimed to have relative axis because of
> some great firmware engineering on the manufacturer's part and I found
> how to remove them in hwdb it would not take effect either.

https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in
calls input-id which sets the ID_INPUT_* tags. If you modify the
capabilities after that happens, you need to call input-id again to get
updated udev properties.

There is no kernel facility to handle devices that change capabilities at
runtime. We discussed this a short while ago (search for SYN_CONFIG) but
it's ... tricky.

Cheers,
   Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michal Suchánek
On Sat, 10 Jun 2017 12:00:22 +1000
Peter Hutterer <[hidden email]> wrote:

> On Fri, Jun 09, 2017 at 01:39:53PM +0200, Michal Suchánek wrote:
> > On Thu, 8 Jun 2017 16:18:28 -0700
> > Dmitry Torokhov <[hidden email]> wrote:
> >  
> > > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > > <[hidden email]> wrote:  
> > > > On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek
> > > > wrote:    
> > > >> This is what evtest reports about my keyboard:
> > > >>
> > > >> Select the device event number [0-12]: 2
> > > >> Input driver version is 1.0.1
> > > >> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version
> > > >> 0x111 Input device name: "DELL Dell USB Entry Keyboard"
> > > >> Supported events:
> > > >>   Event type 0 (EV_SYN)
> > > >>   Event type 1 (EV_KEY)
> > > >>     Event code 1 (KEY_ESC)
> > > >>     Event code 2 (KEY_1)
> > > >>     Event code 3 (KEY_2)
> > > >>     Event code 4 (KEY_3)
> > > >> ...
> > > >>     Event code 193 (KEY_F23)
> > > >>     Event code 194 (KEY_F24)
> > > >>     Event code 240 (KEY_UNKNOWN)
> > > >>     Event code 272 (BTN_LEFT)
> > > >>     Event code 273 (BTN_RIGHT)
> > > >>     Event code 274 (BTN_MIDDLE)
> > > >>   Event type 4 (EV_MSC)
> > > >>     Event code 4 (MSC_SCAN)
> > > >>   Event type 17 (EV_LED)
> > > >>     Event code 0 (LED_NUML) state 1
> > > >>     Event code 1 (LED_CAPSL) state 0
> > > >>     Event code 2 (LED_SCROLLL) state 0
> > > >>     Event code 3 (LED_COMPOSE) state 0
> > > >>     Event code 4 (LED_KANA) state 0
> > > >> Key repeat handling:
> > > >>   Repeat type 20 (EV_REP)
> > > >>     Repeat code 0 (REP_DELAY)
> > > >>       Value    250
> > > >>     Repeat code 1 (REP_PERIOD)
> > > >>       Value     33
> > > >> Properties:    
> > > >
> > > > looks like it's not tagged as ID_INPUT_MOUSE by the default udev
> > > > rules because for that we need x/y axes (either relative for
> > > > real mice or absolute ones for the VMWare USB mouse). This
> > > > keyboard only has buttons though. So it gets ID_INPUT_KEYBOARD
> > > > for the keys, but no ID_INPUT_MOUSE.
> > > >
> > > > Google isn't overly forthcoming on "DELL Dell USB Entry
> > > > Keyboard" but the few pictures I can find all point to a
> > > > keyboard that doesn't have any physical mouse buttons at all.
> > > > Does yours have buttons? Can you post a picture of it somewhere?
> > > >    
> > >
> > > Michal is using udev/hwdb to replace some of the keys on his
> > > keyboard to generate BTN_RIGHT/BTN_MIDDLE trying to achive the
> > > same end result as with mac_hid. It is not the default keyboard
> > > behavior. Having another custom udev rule to mark the device as
> > > ID_INPUT_MOUSE is a fair requirement in this case I think.
> > >  
> >
> > Which is done in different place, and uses device matching with
> > completely different patterns. So for this to work reasonably either
> >
> >  - all devices should have all capabilities by default
> >  - the capabilities should be detected based on the events actually
> >    available on the device
> >
> > And if my keyboard actually claimed to have relative axis because of
> > some great firmware engineering on the manufacturer's part and I
> > found how to remove them in hwdb it would not take effect either.  
>
> https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in
> calls input-id which sets the ID_INPUT_* tags. If you modify the
> capabilities after that happens, you need to call input-id again to
> get updated udev properties.

rules/50-udev-default.rules.in:SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
rules/50-udev-default.rules.in:SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
rules/50-udev-default.rules.in:ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
rules/60-evdev.rules:IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=evdev:", \
rules/60-evdev.rules:ENV{ID_INPUT_KEY}=="?*", DRIVERS=="atkbd", \
rules/60-evdev.rules:  IMPORT{builtin}="hwdb 'evdev:atkbd:$attr{[dmi/id]modalias}'", \
rules/60-evdev.rules:KERNELS=="input*", IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]modalias}'", \
rules/60-evdev.rules:KERNELS=="input*", IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
rules/60-persistent-input.rules:ENV{ID_INPUT_KEYBOARD}=="?*", ENV{.INPUT_CLASS}="kbd"
rules/60-persistent-input.rules:ENV{ID_INPUT_MOUSE}=="?*", ENV{.INPUT_CLASS}="mouse"
rules/60-persistent-input.rules:ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{.INPUT_CLASS}="mouse"
rules/60-persistent-input.rules:ENV{ID_INPUT_TABLET}=="?*", ENV{.INPUT_CLASS}="mouse"
rules/60-persistent-input.rules:ENV{ID_INPUT_JOYSTICK}=="?*", ENV{.INPUT_CLASS}="joystick"
rules/60-sensor.rules:  IMPORT{builtin}="hwdb 'sensor:modalias:$attr{modalias}:$attr{[dmi/id]modalias}'", \
rules/60-sensor.rules:SUBSYSTEM=="input", ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="acpi", \
rules/60-sensor.rules:  IMPORT{builtin}="hwdb 'sensor:modalias:acpi:$attr{hid}:$attr{[dmi/id]modalias}'", \
rules/60-sensor.rules:SUBSYSTEM=="input", ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="platform", \
rules/60-sensor.rules:  IMPORT{builtin}="hwdb 'sensor:modalias:platform:$id:$attr{[dmi/id]modalias}'", \
rules/70-mouse.rules:ENV{ID_INPUT_MOUSE}=="", GOTO="mouse_end"
rules/70-mouse.rules:        IMPORT{builtin}="hwdb 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \
rules/70-mouse.rules:        IMPORT{builtin}="hwdb 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \
rules/70-mouse.rules:        IMPORT{builtin}="hwdb 'mouse:ps2::name:$attr{device/name}:'", \
rules/70-touchpad.rules:ENV{ID_INPUT}=="", GOTO="touchpad_end"
rules/70-touchpad.rules:ENV{ID_INPUT_TOUCHPAD}=="", GOTO="touchpad_end"
rules/70-touchpad.rules:        IMPORT{builtin}="hwdb 'touchpad:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \

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

>
> There is no kernel facility to handle devices that change
> capabilities at runtime. We discussed this a short while ago (search
> for SYN_CONFIG) but it's ... tricky.

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

Thanks

Michal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

> On Sat, 10 Jun 2017 12:00:22 +1000
> Peter Hutterer <[hidden email]> wrote:
>
> > On Fri, Jun 09, 2017 at 01:39:53PM +0200, Michal Suchánek wrote:  
> > > On Thu, 8 Jun 2017 16:18:28 -0700
> > > Dmitry Torokhov <[hidden email]> wrote:
> > >    
> > > > On Thu, Jun 8, 2017 at 4:07 PM, Peter Hutterer
> > > > <[hidden email]> wrote:    
> > > > > On Thu, Jun 08, 2017 at 03:18:42PM +0200, Michal Suchánek
> > > > > wrote:      
> > > > >> This is what evtest reports about my keyboard:
> > > > >>
> > > > >> Select the device event number [0-12]: 2
> > > > >> Input driver version is 1.0.1
> > > > >> Input device ID: bus 0x3 vendor 0x413c product 0x2107 version
> > > > >> 0x111 Input device name: "DELL Dell USB Entry Keyboard"
> > > > >> Supported events:
> > > > >>   Event type 0 (EV_SYN)
> > > > >>   Event type 1 (EV_KEY)
> > > > >>     Event code 1 (KEY_ESC)
> > > > >>     Event code 2 (KEY_1)
> > > > >>     Event code 3 (KEY_2)
> > > > >>     Event code 4 (KEY_3)
> > > > >> ...
> > > > >>     Event code 193 (KEY_F23)
> > > > >>     Event code 194 (KEY_F24)
> > > > >>     Event code 240 (KEY_UNKNOWN)
> > > > >>     Event code 272 (BTN_LEFT)
> > > > >>     Event code 273 (BTN_RIGHT)
> > > > >>     Event code 274 (BTN_MIDDLE)
> > > > >>   Event type 4 (EV_MSC)
> > > > >>     Event code 4 (MSC_SCAN)
> > > > >>   Event type 17 (EV_LED)
> > > > >>     Event code 0 (LED_NUML) state 1
> > > > >>     Event code 1 (LED_CAPSL) state 0
> > > > >>     Event code 2 (LED_SCROLLL) state 0
> > > > >>     Event code 3 (LED_COMPOSE) state 0
> > > > >>     Event code 4 (LED_KANA) state 0
> > > > >> Key repeat handling:
> > > > >>   Repeat type 20 (EV_REP)
> > > > >>     Repeat code 0 (REP_DELAY)
> > > > >>       Value    250
> > > > >>     Repeat code 1 (REP_PERIOD)
> > > > >>       Value     33
> > > > >> Properties:      
> > > > >
> > > > > looks like it's not tagged as ID_INPUT_MOUSE by the default
> > > > > udev rules because for that we need x/y axes (either relative
> > > > > for real mice or absolute ones for the VMWare USB mouse). This
> > > > > keyboard only has buttons though. So it gets ID_INPUT_KEYBOARD
> > > > > for the keys, but no ID_INPUT_MOUSE.
> > > > >
> > > > > Google isn't overly forthcoming on "DELL Dell USB Entry
> > > > > Keyboard" but the few pictures I can find all point to a
> > > > > keyboard that doesn't have any physical mouse buttons at all.
> > > > > Does yours have buttons? Can you post a picture of it
> > > > > somewhere?
> > > >
> > > > Michal is using udev/hwdb to replace some of the keys on his
> > > > keyboard to generate BTN_RIGHT/BTN_MIDDLE trying to achive the
> > > > same end result as with mac_hid. It is not the default keyboard
> > > > behavior. Having another custom udev rule to mark the device as
> > > > ID_INPUT_MOUSE is a fair requirement in this case I think.
> > > >    
> > >
> > > Which is done in different place, and uses device matching with
> > > completely different patterns. So for this to work reasonably
> > > either
> > >
> > >  - all devices should have all capabilities by default
> > >  - the capabilities should be detected based on the events
> > > actually available on the device
> > >
> > > And if my keyboard actually claimed to have relative axis because
> > > of some great firmware engineering on the manufacturer's part and
> > > I found how to remove them in hwdb it would not take effect
> > > either.    
> >
> > https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in
> > calls input-id which sets the ID_INPUT_* tags. If you modify the
> > capabilities after that happens, you need to call input-id again to
> > get updated udev properties.  
>
> rules/50-udev-default.rules.in:SUBSYSTEM=="usb",
> ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id",
> IMPORT{builtin}="hwdb --subsystem=usb"
> rules/50-udev-default.rules.in:SUBSYSTEM=="input", ENV{ID_INPUT}=="",
> IMPORT{builtin}="input_id"
> rules/50-udev-default.rules.in:ENV{MODALIAS}!="",
> IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
> rules/60-evdev.rules:IMPORT{builtin}="hwdb --subsystem=input
> --lookup-prefix=evdev:", \
> rules/60-evdev.rules:ENV{ID_INPUT_KEY}=="?*", DRIVERS=="atkbd", \
> rules/60-evdev.rules:  IMPORT{builtin}="hwdb
> 'evdev:atkbd:$attr{[dmi/id]modalias}'", \
> rules/60-evdev.rules:KERNELS=="input*", IMPORT{builtin}="hwdb
> 'evdev:name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]modalias}'",
> \ rules/60-evdev.rules:KERNELS=="input*", IMPORT{builtin}="hwdb
> 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
> rules/60-persistent-input.rules:ENV{ID_INPUT_KEYBOARD}=="?*",
> ENV{.INPUT_CLASS}="kbd"
> rules/60-persistent-input.rules:ENV{ID_INPUT_MOUSE}=="?*",
> ENV{.INPUT_CLASS}="mouse"
> rules/60-persistent-input.rules:ENV{ID_INPUT_TOUCHPAD}=="?*",
> ENV{.INPUT_CLASS}="mouse"
> rules/60-persistent-input.rules:ENV{ID_INPUT_TABLET}=="?*",
> ENV{.INPUT_CLASS}="mouse"
> rules/60-persistent-input.rules:ENV{ID_INPUT_JOYSTICK}=="?*",
> ENV{.INPUT_CLASS}="joystick" rules/60-sensor.rules:
> IMPORT{builtin}="hwdb
> 'sensor:modalias:$attr{modalias}:$attr{[dmi/id]modalias}'", \
> rules/60-sensor.rules:SUBSYSTEM=="input",
> ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="acpi", \
> rules/60-sensor.rules:  IMPORT{builtin}="hwdb
> 'sensor:modalias:acpi:$attr{hid}:$attr{[dmi/id]modalias}'", \
> rules/60-sensor.rules:SUBSYSTEM=="input",
> ENV{ID_INPUT_ACCELEROMETER}=="1", SUBSYSTEMS=="platform", \
> rules/60-sensor.rules:  IMPORT{builtin}="hwdb
> 'sensor:modalias:platform:$id:$attr{[dmi/id]modalias}'", \
> rules/70-mouse.rules:ENV{ID_INPUT_MOUSE}=="", GOTO="mouse_end"
> rules/70-mouse.rules:        IMPORT{builtin}="hwdb
> 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'",
> \ rules/70-mouse.rules:        IMPORT{builtin}="hwdb
> 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'",
> \ rules/70-mouse.rules:        IMPORT{builtin}="hwdb
> 'mouse:ps2::name:$attr{device/name}:'", \
> rules/70-touchpad.rules:ENV{ID_INPUT}=="", GOTO="touchpad_end"
> rules/70-touchpad.rules:ENV{ID_INPUT_TOUCHPAD}=="",
> GOTO="touchpad_end" rules/70-touchpad.rules:
> IMPORT{builtin}="hwdb
> 'touchpad:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'",
> \
>
> Looking at the occurences of hwdb and ID_INPUT moving the call to
> input_id from rules/50-udev-default.rules to a
> separate file 60-input-id.rules would make it possible to put fixups
> in 60-evdev.rules hwdb calls and the 60-persistent-input.rules that
> depend on the settings would come after as well as the mouse and
> touchpad-specific rules.

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

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

Is there no support for non-wacom tablets?

Thanks

Michal

>
Loading...