On Tue, Jan 12, 2010 at 03:11:59PM +1000, Peter Hutterer wrote:
> On Tue, Jan 12, 2010 at 02:22:06PM +1030, Ron wrote:
> > > >> They are different (I don't have two identical ones at home). But I
> > > >> know they are different since I tested before (I don't trust my memory
> > > >> so much now once you asked :). I'll be sure tomorrow.
> > > >
> > > > AFAICT, neither the driver nor the server expose any API that can be
> > > > used to
> > > > identify different tablets. Since the naming is identical for hotplugged
> > > > devices, you'll get overlap for multiple devices of the same type.
> > >
> > > Peter is right (as always :). Identical devices get the same names.
> > > The logical port, as it used to be, is not a static source to identify
> > > the identical devices either. The ID can be used by xsetwacom to
> > > distinguish one tool from the other of two identical devices. But, it
> > > is not static among reboots. So, end users (I know there are quite a
> > > few) who have two or more identical devices would have to use Ron's
> > > linuxwacom.rules and to setup their specific options for each
> > > device/tool in /etc/X11/xorg.conf to get a static performance. Not a
> > > pretty solution for hotplogging. But it is a solution.
> >
> > I'm not sure if it actually is a solution in the present udev system
> > in Sid now, but it's probably the only basis for one we actually have :(
> >
> > So a quick recap of that hack then, so we're all on the same page:
> >
> > We have 3 interesting cases:
> >
> > - People with one tablet. They're easy, and almost everything should
> > work for them by default now. [I don't have multiple tools for my
> > tablet either, so that may need testing to confirm]
> >
> > - People with multiple tablets, all of different types. They're almost
> > easy. We can uniquely distinguish each tablet, and though any manual
> > tweaks they want to make are just a little more complicated than the
> > first group (they need to pick which tablet to tweak), it's intuitive
> > and robust.
> >
> > - People with multiple tablets where some are the same type.
> > Here we're almost totally screwed. Though wacom does have serial
> > numbers for some (all?) of their tools, the base tablets have no
> > unique identifier. So from the machine point of view, they _are_
> > identical, as there's nothing about them we can use to tell them
> > apart. [I've pleaded for years now to have this added, even if
> > it's just some old-school dip switches the user can flick to set
> > them apart ... but I know it's complicated, and not our decision
> > to make, so ... :/]
> >
> > We can however make reasonable use of a turing test. If the user
> > promises to always plug them into the same USB ports (not a totally
> > unintuitive demand), then we can identify them by the path to that
> > port. It's robust to the limit of PEBKAC, but kind of ugly if you
> > aren't a computer. So far it is still on the short list of things
> > udev hasn't actually managed to break gratuitously though ... ;)
> >
> > So the question now is, (how) can we (ab)use this still to give people
> > what they need? We don't really want people off manually specifying
> > the /dev/input path again -- but we do have ENV{ID_PATH} available to
> > us in udev... (which is how I'm currently passing the driver name but
> > we also did want to get rid of that too ...)
> >
> > If we can use that as a qualifier in the new xorg.conf snippets, then
> > that might give people what they need with existing tablets ...
> >
> > I think I'll punt to Peter for suggestions from that point ...
>
> the current plan for the input attributes is to add a tagging system instead
> of more custom matches. so you can set up udev to tag devices in a specific
> way and then apply the xorg.conf snippets based on these tags.
> so provided complicated enough rulesets you can have configuration for
> multiple wacom devices.
That'll be no worse than we have already, we already have udev rules for
all the important cases, so setting an extra var when they match will be
no biggie.
> Until this is in place, I tend towards claiming that multiple identical
> devices aren't supported without configuration.
I can probably pass them with the jcristau patched server in Sid.
I can definitely set things like ENV{x11_options.Type} with it, but I
don't think he wanted that to go upstream, it was just a stopgap to
get us through the HAL migration until the xorg.conf stuff is finalised.
I don't think we can use that usefully until the xorg.conf side of it
gets sorted out though, can we?
Ron
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
