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.
Until this is in place, I tend towards claiming that multiple identical
devices aren't supported without configuration.
Cheers,
Peter
------------------------------------------------------------------------------
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
