* Re: [RFC/PATCH] input_id: add touchpad quirks rules file.
2010-05-13 4:03 [RFC/PATCH] input_id: add touchpad quirks rules file Peter Hutterer
@ 2010-05-13 13:19 ` Martin Pitt
2010-05-13 13:29 ` Kay Sievers
2010-05-13 23:55 ` Peter Hutterer
2 siblings, 0 replies; 4+ messages in thread
From: Martin Pitt @ 2010-05-13 13:19 UTC (permalink / raw)
To: linux-hotplug
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [RFC/PATCH] input_id: add touchpad quirks rules file.
2010-05-13 4:03 [RFC/PATCH] input_id: add touchpad quirks rules file Peter Hutterer
2010-05-13 13:19 ` Martin Pitt
@ 2010-05-13 13:29 ` Kay Sievers
2010-05-13 23:55 ` Peter Hutterer
2 siblings, 0 replies; 4+ messages in thread
From: Kay Sievers @ 2010-05-13 13:29 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC/PATCH] input_id: add touchpad quirks rules file.
2010-05-13 4:03 [RFC/PATCH] input_id: add touchpad quirks rules file Peter Hutterer
2010-05-13 13:19 ` Martin Pitt
2010-05-13 13:29 ` Kay Sievers
@ 2010-05-13 23:55 ` Peter Hutterer
2 siblings, 0 replies; 4+ messages in thread
From: Peter Hutterer @ 2010-05-13 23:55 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 4+ messages in thread