On Sun, Jan 10, 2010 at 07:27:42PM -0800, Ping wrote: > On Sun, Jan 10, 2010 at 6:28 PM, Peter Hutterer > <[email protected]> wrote: > > >> > Peter: would it be worth accepting and matching on the type name for > >> > --get/set too? Or are those too likely to be ambiguous? We already > >> > >> What happens if we have more than one tablet or more than one tool > >> with the same type? Do we list all of the tool with the same type? > > > > xinput prints the following to stderr if that happens > > fprintf(stderr, > > "Warning: There are multiple devices named \"%s\".\n" > > "To ensure the correct one is selected, please use " > > "the device ID instead.\n\n", name); > > > > I think this would be a good enough solution for xsetwacom too. The same > > approach would work for specifying a type that's also a device name. > > I must have missed something here. Are we talking about xinput or > xsetwacom? I am talking about xsetwacom. Right now we check the > device name to decide which device (in fact it should be called tool > since it is only a tool that is associated with a physical device. > With so many confusing terms, let's still call it device for now :) we > need to set/get data to/from. If we make it to check type, we will > not check the name. Or will we?
Ah, I think I see where some lines of thought got crossed here :) We are talking about xsetwacom, but it is similar to xinput in several ways, and seems to have gained a few features from it already in its new incarnation. Right now, in the xf86 tree, xsetwacom will accept the long quoted name (which is only a part of the string that --list currently outputs), or it will also accept and match on a numeric id (assigned by xorg, similar to how the /dev/eventX numbers are selected). Running --list with -v will show those numeric assignments in the current HEAD code. > >> > accept the id number, and --get ERASER is a bit less horrible to type > >> > than the quoted monster above anyhow. I can send another patch for > >> > that if you think it's worth having... > >> > >> We don't have to use that "monster" :). But we do need a way to > >> get/set the specific tool's info with an unique parameter. Do you have > >> a suggestion? > > > > The ID matching doesn't go away though so that's always the last option if > > the more convenient parameters don't work. The only case where that'd break > > is if users assigns numerical device names to their devices. A case of > > "don't do that" :) > > I guess the ID is from xinput. How many different options do we need > to go through before we come to this last option? 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) How (did?) this work for the earlier drivers? > > Given that the majority of users don't have more than one tablet, I think > > having tutorials suggest things like "xsetwacom --get ERASOR foobar > > something" is a good idea, it applies to most tablets regardless of the > > device itself. > > This limits us to one tool of a type even we only use one tablet for > the whole X server. I have no problem for you guys to add this > option. But I am not convinced to replace > > xsetwacom --get "dev_name" foobar something > > with > > xsetwacom --get type foobar something > > Then the question is, how do we know which device option we are going > to check first: type or dev_name? This "monster" may be bigger than > the dev_name itself :). Are those ever going to be ambiguous? We have: Atom types from xorg: ERASER CURSOR STYLUS etc. device_names: '"Wacom Foo" eraser', '"Wacom Bar" cursor', '"Wacom Baz"', ... device ids: 8, 9, 10 ... The device names already have an odd case, because I get no explicit stylus device_name, just '"Wacom Graphire3"', but aside from that, they are unique if the tablet types are unique. The Atoms types will only be unique if the tool is unique. The ID's will uniquely address any tool, but will not stay constant if devices are unplugged or replugged. Ok. eww. We have some more to tidy up here than I thought ;) 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 ... 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
