Re: [Linuxwacom-devel] [RFC PATCH] Duplicate the InputAttributes for dependent devices.

[Peter H. <pet...@wh...>]

On Mon, May 24, 2010 at 10:08:45AM +0300, Alexia Death wrote:
> On Mon, May 24, 2010 at 5:47 AM, Peter Hutterer
> <pet...@wh...> wrote:
> > Now, what we need to decide on though is which path to chose for the extra
> > information (this patch implements both).
> > Approach 1 is to append the type to the product name - as we do with the
> > device name. So if the device has a product name of "Wacom Intuos", the
> > eraser will have a product name of "Wacom Intuos eraser".
> > This would lead to the following configuration:
> >  Section "InputClass"
> >        Identifier "Wacom eraser class"
> >        MatchProduct "Wacom"
> >        MatchProduct "eraser"
> >        Option "Foo" "bar"
> >  EndSection
> >
> > MatchProduct doesn't do regex, so a match of "Wacom*eraser" won't work, it
> > has to be two different lines.
> > The MatchProduct "Wacom" is just there so other devices that may have
> > "eraser" in their name won't get matched.
> >
> This is the better option I think.Think of the case of two erasers on
> one Intuos, a task I'm yet to tackle .  The type would need to be
> present in the name anyway to ensure uniqueness. 

fwiw, there's no requirement for uniqueness in device names. It's quite
common to have devices with the same name, many mouse/keyboard combos have
two or more devices with the same name and so do many touchscreens.

for your specific task - the option we talked about (I think on IRC) to
force tool types on the device is quite dependent on this feature.
otherwise, you can't really have independent configuration.

> It will make very
> much sense to have identifiers like: "Wacom Intuos airbrush eraser"
> where airbrush is the name set for a specific pen, so I know in GIMP
> and elsewhere what I'm configuring. This leads to wanting to configure
> it specifically so it only makes sense to have MatchProduct "Wacom
> Intuos airbrush eraser" in the sniplet.
> 
> >
> > Approach 2 is to append the type to the tags (tags are arbitrary names
> > assigned to devices by the config backend that can be mached against).
> > This would lead to the following configuration:
> >  Section "InputClass"
> >        Identifier "Wacom eraser class"
> >        MatchProduct "Wacom"
> >        MatchTag "eraser"
> >        Option "Foo" "bar"
> >  EndSection
> 
> This would essentially block my ability to configure a specific
> non-type defined dependent device unless  the dependent device name is
> somehow replicated in the tags and that is neither straightforward nor
> obvious from the user pov.

You're right, we don't have a config to assign tags, they are automagically
assigned by the backend. I completely forgot about this, I'd say this is
rather a problem for the tags approach.

Of course, another option would be to add an option to the server that
assigns tags, but the precedence order of that combined with attribute
matching makes my head spin :)

Cheers,
  Peter