On Mon, Jan 11, 2010 at 12:04:37PM -0800, Ping wrote:
> On Sun, Jan 10, 2010 at 9:22 PM, Peter Hutterer
> <[email protected]> wrote:
> > On Sun, Jan 10, 2010 at 08:41:26PM -0800, Ping wrote:
> >> On Sun, Jan 10, 2010 at 8:23 PM, Ron <[email protected]> wrote:
> >> > The ID's are a property of the tool/device, we could ignore them, but I
> >> > don't actually see any other way to address a tool in the case where
> >> > I had 2 identical tablets plugged in, as the long device names are going
> >> > to be the same, no? (I don't have 2 tablets the same, so I may be wrong)
> >>
> >> 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 ...
> I have to
> test the identical device case on the newer systems (with HAL now and
> udev in the future) to see how it works (don't have time to run these
> kind of testing now).
I have my doubts this will be working with the HAL system we released
for Lenny. There just isn't anywhere in the fdi or hal setup script
where we do anything to pass along the path. But hotplug actually
worked, so I took my 2 steps forward with my one back, and figured
we'd catch up with that again this time or so ;)
The xorg in current Sid will give you a udev system you can test with.
> >> > But I don't think we have much risk of overlap in those 3 namespaces
> >> > do we? If not, it doesn't really matter what order we search them,
> >> > if we do, well ++eww, I agree, but I'm sure we'll figure something out
> >> > ....
> >>
> >> I am with you - there is always a solution no matter which way we
> >> choose. We hope we could find and choose the better one instead of
> >> the ugly one as much as we could afford.
> >
> > we do not have to work around every possible configuration combination or
> > we'll be here all night. if we have a documented matching order, that will
> > be enough.
> > e.g. xsetwacom --get "stylus" ...
> > should first match a device named "stylus" or, if none exists, then a device
> > of the type stylus. If there are two devices of name "stylus", complain and
> > require the device id. if there are two stylus devices, complain and require
> > the device name or the device id.
> > I daresay, for the most setups where a single device is plugged in without
> > any funky configuration, the type match will work fine.
>
> I agree with you guys for this plan since special settings of
> identical devices would (probably) have to be dealt separately in
> xorg.conf, which would have a different dev_name for each tool anyway.
Ack. That's pretty much how I was imagining it.
Did we decide on whether backward compatibility here is needed?
What about 'list' vs '--list'? I like the idea of `xinput list`
and `xsetwacom list` doing exactly the same thing, and not having
to remember which of them needs -- for that option...
It's not a big deal, but if we want to fix this _and_ stay compatible
we could leave --list alone and only document 'list' in the user help.
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
