[RFC/PATCH] input_id: add touchpad quirks rules file.

[RFC/PATCH] input_id: add touchpad quirks rules file.

[Peter Hutterer]

Some devices require special tagging to apply device-dependent configuration
in X. One example are the Dell Mini touchpads that have the buttons inside
the active touchpad area, causing cursor jumps and other inconveniences.

X checks INPUT_ID.tags for matches in the xorg.conf.d snippets, so check the
product_name and apply the tag accordingly.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---

I kind-of expect some more tags like this to appear in the future, so I
figured the generic name touchpad-quirks is better than have a dell-specific
one. Would something like this be appreciated in the upstream repo?

Looking at the Ubuntu sources for the synaptics driver, the choice there is
to simply tag with the model name (e.g. "inspiron_1011") and then have the
xorg.conf hook onto this.

There's two sides to it, the Ubuntu approach is more flexible if other
configuration options are needed too, the approach here only requires
updating udev for new models but not Xorg.

Any preferences?


 Makefile.am                              |    1 +
 extras/input_id/70-touchpad-quirks.rules |   15 +++++++++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 extras/input_id/70-touchpad-quirks.rules

diff --git a/Makefile.am b/Makefile.am
index 8d13f19..18da70a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -242,6 +242,7 @@ dist_udevrules_DATA += extras/floppy/60-floppy.rules
 extras_input_id_input_id_SOURCES = extras/input_id/input_id.c
 extras_input_id_input_id_LDADD = libudev/libudev-private.la
 libexec_PROGRAMS += extras/input_id/input_id
+dist_udevrules_DATA += extras/input_id/70-touchpad-quirks.rules
 
 # ------------------------------------------------------------------------------
 # path_id - compose identifier of persistent elements of the parent buses
diff --git a/extras/input_id/70-touchpad-quirks.rules b/extras/input_id/70-touchpad-quirks.rules
new file mode 100644
index 0000000..6c65c29
--- /dev/null
+++ b/extras/input_id/70-touchpad-quirks.rules
@@ -0,0 +1,15 @@
+ACTION!="add|change", GOTO="touchpad_quirks_end"
+KERNEL!="event*", GOTO="touchpad_quirks_end"
+
+ENV{ID_INPUT_TOUCHPAD}!="1", GOTO="touchpad_quirks_end"
+
+# model specific quirks
+
+# Dell Minis have a touchpad where the buttons and the touchpad area
+# overlap. Clicking a button thus moves the pointer, this requires special
+# Xorg configuration.
+
+ATTR{[dmi/id]product_name}="Inspiron 1011|Inspiron 1012", \
+  ENV{ID_INPUT.tags}="touchpad_button_overlap"
+
+LABEL="touchpad_quirks_end"
-- 
1.7.0.1

Re: [RFC/PATCH] input_id: add touchpad quirks rules file.

[Martin Pitt]

[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]

Hello Peter,

Peter Hutterer [2010-05-13 14:03 +1000]:
> I kind-of expect some more tags like this to appear in the future, so I
> figured the generic name touchpad-quirks is better than have a dell-specific
> one. Would something like this be appreciated in the upstream repo?

There's one more dimension to that, where those rules should be
maintained: We can ship them in udev proper (as your patch proposes),
or ship the udev rules in the package which will actually make use of
it, like xorg-input-synaptics (which is what Debian/Ubuntu are
currently doing).

My preference is that we should keep subsystem specific rules in the
subsystem daemon/libraries (like udisks/upower/X.org/libgphoto2)
instead of centrally managing them in udev, for three reasons:

 (1) The subsystem daemon maintainers are usually the experts, and know
     better how that particular hardware should be configured.
 
 (2) I hear that udevd will eventually go away, and its probers will
     be fanned out to the subsystem daemons, therefore leaving the
     udev package as a relatively stable library only.
 
 (3) udev rules and xorg.conf.d/ snippets would be maintained at the
     same place and can be updated in lockstep, instead of creating a
     tight dependency relation.

(3) particularly addresses your remark about the current distro
inconsistency between tag names.

If you do not want to maintain those rules in the synaptics package
for some reason, I would not object to committing them into udev, but
I think we are a lot less flexible that way.

> Looking at the Ubuntu sources for the synaptics driver, the choice there is
> to simply tag with the model name (e.g. "inspiron_1011") and then have the
> xorg.conf hook onto this.

This was by and large arbitrary, since it wasn't clear whether
different models would need different AreaBottomEdge values.

For the record, we also have two more quirks [1], which seem quite model
specific.

> There's two sides to it, the Ubuntu approach is more flexible if other
> configuration options are needed too, the approach here only requires
> updating udev for new models but not Xorg.

I agree that it's nicer to use more generic tag names where
appropriate, i. e. where more models are affected. Coordinating tag
addition, splitting, and merging would also be much easier if they
would be maintained at the same place, and shipped in the same tarball
release, etc.

Thank you, and have a great day,

Martin


[1]
ATTR{[dmi/id]product_name}=="Inspiron 1120", ENV{ID_INPUT.tags}="inspiron_1120"
ATTR{[dmi/id]product_name}=="HP MiniNote 1000", ENV{ID_INPUT.tags}="mininote_1000"

Section "InputClass"
        Identifier "Dell Inspiron quirks"
        MatchTag "inspiron_1120"
        MatchDevicePath "/dev/input/event*"
        Driver "synaptics"
        Option "JumpyCursorThreshold" "250"
EndSection

Section "InputClass"
        Identifier "HP Mininote quirks"
        MatchTag "mininote_1000"
        MatchDevicePath "/dev/input/event*"
        Driver "synaptics"
        Option "JumpyCursorThreshold" "20"
EndSection


-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [RFC/PATCH] input_id: add touchpad quirks rules file.

[Kay Sievers]

On Thu, May 13, 2010 at 15:19, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Peter Hutterer [2010-05-13 14:03 +1000]:
>> I kind-of expect some more tags like this to appear in the future, so I
>> figured the generic name touchpad-quirks is better than have a dell-specific
>> one. Would something like this be appreciated in the upstream repo?

> My preference is that we should keep subsystem specific rules in the
> subsystem daemon/libraries (like udisks/upower/X.org/libgphoto2)
> instead of centrally managing them in udev, for three reasons:
>
>  (1) The subsystem daemon maintainers are usually the experts, and know
>     better how that particular hardware should be configured.

That's true. If there are packages that rely on these rules, it;s
usually better to have the rules installed by this package. We have
pretty bad experience with HAL with centralizing things nobody really
knew in the end if they are still needed or what they are really meant
to do.

>  (2) I hear that udevd will eventually go away, and its probers will
>     be fanned out to the subsystem daemons, therefore leaving the
>     udev package as a relatively stable library only.

Oh, that's interesting news. :) What makes you think of that? What
would match on and deliver all the kernel events to subcribers?

Kay

Re: [RFC/PATCH] input_id: add touchpad quirks rules file.

[Peter Hutterer]

On Thu, May 13, 2010 at 03:19:59PM +0200, Martin Pitt wrote:
> Peter Hutterer [2010-05-13 14:03 +1000]:
> > I kind-of expect some more tags like this to appear in the future, so I
> > figured the generic name touchpad-quirks is better than have a dell-specific
> > one. Would something like this be appreciated in the upstream repo?
> 
> There's one more dimension to that, where those rules should be
> maintained: We can ship them in udev proper (as your patch proposes),
> or ship the udev rules in the package which will actually make use of
> it, like xorg-input-synaptics (which is what Debian/Ubuntu are
> currently doing).
> 
> My preference is that we should keep subsystem specific rules in the
> subsystem daemon/libraries (like udisks/upower/X.org/libgphoto2)
> instead of centrally managing them in udev, for three reasons:
> 
>  (1) The subsystem daemon maintainers are usually the experts, and know
>      better how that particular hardware should be configured.
>  
>  (2) I hear that udevd will eventually go away, and its probers will
>      be fanned out to the subsystem daemons, therefore leaving the
>      udev package as a relatively stable library only.
>  
>  (3) udev rules and xorg.conf.d/ snippets would be maintained at the
>      same place and can be updated in lockstep, instead of creating a
>      tight dependency relation.
> 
> (3) particularly addresses your remark about the current distro
> inconsistency between tag names.
> 
> If you do not want to maintain those rules in the synaptics package
> for some reason, I would not object to committing them into udev, but
> I think we are a lot less flexible that way.

righty-o, I don't really have a problem with that, getting it into udev was
mostly to stop the duplication efforts. It'd be great though if we had a way
to sync up our rules files and that can simply be in the upstream synaptics
sources.

maintainerwise - anything in synaptics and not in udev is much easier to
maintain for me anyway ;)

> > Looking at the Ubuntu sources for the synaptics driver, the choice there is
> > to simply tag with the model name (e.g. "inspiron_1011") and then have the
> > xorg.conf hook onto this.
> 
> This was by and large arbitrary, since it wasn't clear whether
> different models would need different AreaBottomEdge values.
> 
> For the record, we also have two more quirks [1], which seem quite model
> specific.

yeah, I've seen that part but I think the jumpy cursor threshold could be
worked around in the driver so that that option isn't needed. I just need to
get the mini repaired and running to verify this, some preliminary patches I
had were promising.

fwiw, I'm also working on percentage option support for the X server, so
instead of having hardcoded model-specific values (e.g. 4000 as bottom edge)
you can just specify 20% off the bottom of the touchpad. That again makes
autoconfiguration more generic.

Cheers,
  Peter