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

[Ron <ro...@de...>]

On Sun, May 23, 2010 at 10:10:26PM -0700, Ping Cheng wrote:
> We need at least one more voter to break the tie - I like the second approach.

Uh oh :)  That was my first-blush impression too ...

MatchProduct "Wacom eraser"  seems pretty self-explanatory if it would work,
but having to split that into two matches, the double MatchProduct seems a
bit more confusing than matching on a 'product' and some sub-something of
that product.

I suspect I'd think differently if I was more intimate with the operation of
the config parser and the xorg device model, but I'm less sure that "it is
clearly documented in xorg.conf(5)" will make this less of a FAQ from users.

> Why? It uses MatchTag instead of MatchProduct. Eraser/Cursor/Pad is a
> tag/type not a product. Plus, duplicated MatchProduct confuses people
> IMO.
> 
> Let's see what the list would choose. My friends, it is time to show
> your support :)!
> 
> Ping
> 
> P.S., just kidding.  I don't have a strong preference in the
> names/tags as long as Wacom is in it :).

I likewise don't have a strong opinion about that though, so long as I can
set my eraser to relative mode and leave my stylus in absolute mode :)
I am swayed toward following Peter's best hunch if that most closely follows
the reality of what is actually being configured and keeps things a little
simpler for the same end result.

> On Sun, May 23, 2010 at 7:47 PM, Peter Hutterer
> <pet...@wh...> wrote:
> > Note that the patch below won't apply just yet, you'll need some changes to
> > the X server, marginal ones though. Also, hence the FIXME's the ABI number
> > needs to be bumped.
> >
> > The problem we face at the moment is that the driver can hotplug dependent
> > devices but the configuration options from the xorg.conf.d snippets only
> > apply to the first device (usually the stylus). It's not possible to use
> > xorg.conf.d snippets to configure the eraser, for example.
> >
> > With a proposed change to the X server to copy the input attributes into the
> > device file, we can counteract this by passing these attributes to the next
> > device. The attributes are essentially what we get from the config backend
> > (hal or udev) and contain some of the information exported by the kernel.
> > That's easy enough and the code is quite straightforward as you can see
> > below.
> >
> > 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".

Having a product name of "Wacom Intuos eraser" does seem simple and obvious.

> > This would lead to the following configuration:
> >  Section "InputClass"
> >        Identifier "Wacom eraser class"
> >        MatchProduct "Wacom"
> >        MatchProduct "eraser"
> >        Option "Foo" "bar"
> >  EndSection

But it's less obvious that this is what the above is designed to match
at first glance.

> > MatchProduct doesn't do regex, so a match of "Wacom*eraser" won't work, it
> > has to be two different lines.

Is it not feasible or reasonable to fix that limitation?
We already have things like:

MatchProduct "Wacom|WACOM"
MatchProduct "WACf|FUJ02e5|FUJ02e7"

So possibly some simple globbing, if not full regex support, would be
useful to have here?

> > The MatchProduct "Wacom" is just there so other devices that may have
> > "eraser" in their name won't get matched.
> >
> >
> > 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
> >
> > The MatchProduct "Wacom" is just there so other devices that may have the
> > same tag don't get matched.
> >
> > I personally prefer the first approach since the name is quite exposed
> > already anyway and it IMO makes for more obvious matching. But I'd like to
> > hear some comments on which one is preferable.

I'll temper all my comments above with the observation that what is 'obvious'
is also going to be relative to how similar devices do this sort of fine
configuration, and how these subdevices appear to tools like xinput etc.
It's sometimes better to trade a little bit of "immediately obvious" for a
measure of "works the same way everywhere".

The latter people will eventually learn, the former we seem to have already
proved to be a subjective fallacy by the split in the 'vote' ;)

Cheers,
Ron