From: Peter Hutterer <peter.hutterer@who-t.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: [RFC/PATCH] input_id: add touchpad quirks rules file.
Date: Thu, 13 May 2010 23:55:16 +0000 [thread overview]
Message-ID: <20100513235516.GC5751@barra.redhat.com> (raw)
In-Reply-To: <20100513040347.GA16050@barra.bne.redhat.com>
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
prev parent reply other threads:[~2010-05-13 23:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100513235516.GC5751@barra.redhat.com \
--to=peter.hutterer@who-t.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.