linuxwacom-devel

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

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

This allows for the configuration of dependent devices by creating the
appropriate match rules. Note that for the input attributes - just as for
the device name - the type is simply appended to the end of the product
name.

Signed-off-by: Peter Hutterer <pet...@wh...>
---
Note, this is the patch I sent out as RFC a few days or weeks back. Some
parts (duplication of attributes) have moved into the server, making the
patch a lot simpler. 

This requires an X server from git master.

 src/wcmValidateDevice.c |   33 ++++++++++++++++++++++++++++++++-
 1 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index eddc113..61abd8c 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -300,6 +300,26 @@ static void wcmFreeInputOpts(InputOption* opts)
 	}
 }
 
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
+/**
+ * Duplicate the attributes of the given device. "product" gets the type
+ * appended, so a device of product "Wacom" will then have a product "Wacom
+ * eraser", "Wacom cursor", etc.
+ */
+static InputAttributes* wcmDuplicateAttributes(LocalDevicePtr local,
+					       const char *type)
+{
+	InputAttributes *attr;
+	attr = DuplicateInputAttributes(local->attrs);
+							/* add one space, one \0 */
+	attr->product = realloc(attr->product, strlen(attr->product) + strlen(type) + 2);
+	strcat(attr->product, " ");
+	strcat(attr->product, type);
+
+	return attr;
+}
+#endif
+
 /**
  * Hotplug one device of the given type.
  * Device has the same options as the "parent" device, type is one of
@@ -310,15 +330,26 @@ static void wcmHotplug(LocalDevicePtr local, const char *type)
 {
 	DeviceIntPtr dev; /* dummy */
 	InputOption *input_options;
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
+	InputAttributes *attrs = NULL;
+#endif
 
 	input_options = wcmOptionDupConvert(local, type);
 
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
+	attrs = wcmDuplicateAttributes(local, type);
+#endif
+
 	NewInputDeviceRequest(input_options,
 #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
-				NULL,
+				attrs,
 #endif
 				&dev);
 	wcmFreeInputOpts(input_options);
+
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
+	FreeInputAttributes(attrs);
+#endif
 }
 
 void wcmHotplugOthers(LocalDevicePtr local)
-- 
1.6.5.2

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

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

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".
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.


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.

Cheers,
  Peter
---
 src/wcmValidateDevice.c |   84 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 83 insertions(+), 1 deletions(-)

diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 438cf38..3f668b4 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -295,6 +295,76 @@ static void wcmFreeInputOpts(InputOption* opts)
 	}
 }
 
+/* FIXME: should be different number */
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
+/**
+ * Duplicate the attributes of the given device. "product" gets the type
+ * appended, so a device of product "Wacom" will then have a product "Wacom
+ * eraser", "Wacom cursor", etc.
+ * And the type is added to the tags as well.
+ */
+static InputAttributes* wcmDuplicateAttributes(LocalDevicePtr local,
+					       const char *type)
+{
+	InputAttributes *new_attr = NULL;
+
+	InputAttributes *attr = local->attrs;
+	char **tag, **new_tag;
+	int ntags = 0;
+
+	new_attr = calloc(1, sizeof(InputAttributes));
+	new_attr->flags = attr->flags;
+	if (attr->vendor)
+		new_attr->vendor = strdup(attr->vendor);
+	if (attr->device)
+		new_attr->device = strdup(attr->device);
+
+	if (attr->product)
+	{
+							/* one space, one \0 */
+		new_attr->product = calloc(strlen(attr->product) + strlen(type) + 2, 1);
+		strcpy(new_attr->product, attr->product);
+	}
+	if (type) {
+		strcat(new_attr->product, " ");
+		strcat(new_attr->product, type);
+	}
+
+	tag = attr->tags;
+	while(*tag++)
+		ntags++;
+
+	new_attr->tags = calloc(ntags + 2, sizeof(char*));
+
+	tag = attr->tags;
+	new_tag = new_attr->tags;
+	while(*tag)
+	{
+		*new_tag = strdup(*tag);
+		tag++;
+		new_tag++;
+	}
+	*new_tag = strdup(type);
+	return new_attr;
+}
+
+static void wcmFreeAttributes(InputAttributes *attr)
+{
+	char **tag = attr->tags;
+	while(*tag)
+	{
+		free(*tag);
+		tag++;
+	}
+
+	free(attr->tags);
+	free(attr->product);
+	free(attr->vendor);
+	free(attr->device);
+	free(attr);
+}
+#endif
+
 /**
  * Hotplug one device of the given type.
  * Device has the same options as the "parent" device, type is one of
@@ -305,15 +375,27 @@ static void wcmHotplug(LocalDevicePtr local, const char *type)
 {
 	DeviceIntPtr dev; /* dummy */
 	InputOption *input_options;
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
+	InputAttributes *attrs = NULL;
+#endif
 
 	input_options = wcmOptionDupConvert(local, type);
 
+/* FIXME: should be different number */
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
+	attrs = wcmDuplicateAttributes(local, type);
+#endif
+
 	NewInputDeviceRequest(input_options,
 #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
-				NULL,
+				attrs,
 #endif
 				&dev);
 	wcmFreeInputOpts(input_options);
+
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
+	wcmFreeAttributes(attrs);
+#endif
 }
 
 void wcmHotplugOthers(LocalDevicePtr local)
-- 
1.7.0.1

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

[Ping C. <pin...@gm...>]

We need at least one more voter to break the tie - I like the second approach.

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 :).


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".
> 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.
>
>
> 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.
>
> Cheers,
>  Peter
> ---
>  src/wcmValidateDevice.c |   84 ++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 83 insertions(+), 1 deletions(-)
>
> diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
> index 438cf38..3f668b4 100644
> --- a/src/wcmValidateDevice.c
> +++ b/src/wcmValidateDevice.c
> @@ -295,6 +295,76 @@ static void wcmFreeInputOpts(InputOption* opts)
>        }
>  }
>
> +/* FIXME: should be different number */
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> +/**
> + * Duplicate the attributes of the given device. "product" gets the type
> + * appended, so a device of product "Wacom" will then have a product "Wacom
> + * eraser", "Wacom cursor", etc.
> + * And the type is added to the tags as well.
> + */
> +static InputAttributes* wcmDuplicateAttributes(LocalDevicePtr local,
> +                                              const char *type)
> +{
> +       InputAttributes *new_attr = NULL;
> +
> +       InputAttributes *attr = local->attrs;
> +       char **tag, **new_tag;
> +       int ntags = 0;
> +
> +       new_attr = calloc(1, sizeof(InputAttributes));
> +       new_attr->flags = attr->flags;
> +       if (attr->vendor)
> +               new_attr->vendor = strdup(attr->vendor);
> +       if (attr->device)
> +               new_attr->device = strdup(attr->device);
> +
> +       if (attr->product)
> +       {
> +                                                       /* one space, one \0 */
> +               new_attr->product = calloc(strlen(attr->product) + strlen(type) + 2, 1);
> +               strcpy(new_attr->product, attr->product);
> +       }
> +       if (type) {
> +               strcat(new_attr->product, " ");
> +               strcat(new_attr->product, type);
> +       }
> +
> +       tag = attr->tags;
> +       while(*tag++)
> +               ntags++;
> +
> +       new_attr->tags = calloc(ntags + 2, sizeof(char*));
> +
> +       tag = attr->tags;
> +       new_tag = new_attr->tags;
> +       while(*tag)
> +       {
> +               *new_tag = strdup(*tag);
> +               tag++;
> +               new_tag++;
> +       }
> +       *new_tag = strdup(type);
> +       return new_attr;
> +}
> +
> +static void wcmFreeAttributes(InputAttributes *attr)
> +{
> +       char **tag = attr->tags;
> +       while(*tag)
> +       {
> +               free(*tag);
> +               tag++;
> +       }
> +
> +       free(attr->tags);
> +       free(attr->product);
> +       free(attr->vendor);
> +       free(attr->device);
> +       free(attr);
> +}
> +#endif
> +
>  /**
>  * Hotplug one device of the given type.
>  * Device has the same options as the "parent" device, type is one of
> @@ -305,15 +375,27 @@ static void wcmHotplug(LocalDevicePtr local, const char *type)
>  {
>        DeviceIntPtr dev; /* dummy */
>        InputOption *input_options;
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> +       InputAttributes *attrs = NULL;
> +#endif
>
>        input_options = wcmOptionDupConvert(local, type);
>
> +/* FIXME: should be different number */
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> +       attrs = wcmDuplicateAttributes(local, type);
> +#endif
> +
>        NewInputDeviceRequest(input_options,
>  #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> -                               NULL,
> +                               attrs,
>  #endif
>                                &dev);
>        wcmFreeInputOpts(input_options);
> +
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> +       wcmFreeAttributes(attrs);
> +#endif
>  }
>
>  void wcmHotplugOthers(LocalDevicePtr local)
> --
> 1.7.0.1
>
>

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

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

[Alexia D. <ale...@gm...>]

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. 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.
-- 
--Alexia

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

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

[Alexia D. <ale...@gm...>]

On Mon, May 24, 2010 at 10:30 AM, Peter Hutterer
<pet...@wh...> wrote:
> 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.
This is interesting. So If I use xsetwacom with a shared name, who
gets the config?

For user tho differentiate his/her devices this name is all they can
go by so for practical reasons the uniqueness is required at least for
wacom devices.

> 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.

Well, some configuration can be applied with xsetwacom later but yes,
things that can only be set at load time do depend on this. ;)

-- 
--Alexia

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

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

On Mon, May 24, 2010 at 11:27:23AM +0300, Alexia Death wrote:
> On Mon, May 24, 2010 at 10:30 AM, Peter Hutterer
> <pet...@wh...> wrote:
> > 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.
> This is interesting. So If I use xsetwacom with a shared name, who
> gets the config?

no-one, xsetwacom will complain and require that you specify the ID instead
:)
 
> For user tho differentiate his/her devices this name is all they can
> go by so for practical reasons the uniqueness is required at least for
> wacom devices.

of course, I didn't imply that shared names were useful, just that they're
not impossible.

> > 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.
> 
> Well, some configuration can be applied with xsetwacom later but yes,
> things that can only be set at load time do depend on this. ;)

Cheers,
  Peter

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

[Chris B. <ch...@cn...>]

On Mon, May 24, 2010 at 4:00 AM, Peter Hutterer <pet...@wh...>wrote:

> On Mon, May 24, 2010 at 11:27:23AM +0300, Alexia Death wrote:
> > On Mon, May 24, 2010 at 10:30 AM, Peter Hutterer
> > <pet...@wh...> wrote:
> > > 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.
> > This is interesting. So If I use xsetwacom with a shared name, who
> > gets the config?
>
> no-one, xsetwacom will complain and require that you specify the ID instead
> :)
>
>
No strong opinions on my side either but my concerns are on how it effects
output of "xinput list".  Do I continue to see in that list what an "eraser"
is vs. a "touch"? Or would I need to issue a secondary command to see its
tags?

I've come to terms with duplicate device names (i.e. 2 erasers) since its
not unique to wacom.  So thats no biggy but it has been nice to immediately
see which part of tablet in its xinput name.

Also, thinking from a possible future configuration GUI perspective, it
would be nice if we could somehow bind a subset of devices together (a
unique value; maybe the xinput # of first device in chain; shared in a tag
or something).  That way you know what wacom "common" options are shared
among what other input devices.  This is especially useful for tablets that
have 2 input devices (such as Bamboo's) and so two sets of common options.

Chris

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

[Ping C. <pin...@gm...>]

The voting window is closed.  The official result is 3.5 to 1.5 (the
.5 is from Ron :).  Approach 1 gets approved (Signed-off-by:  Ping
Cheng)

Peter, go ahead and take your gang (of three and half :) with you to
get the job done!

I know I don't have friends here :(.

Ping

On Mon, May 24, 2010 at 6:13 AM, Chris Bagwell <ch...@cn...> wrote:
>
>
> On Mon, May 24, 2010 at 4:00 AM, Peter Hutterer <pet...@wh...>
> wrote:
>>
>> On Mon, May 24, 2010 at 11:27:23AM +0300, Alexia Death wrote:
>> > On Mon, May 24, 2010 at 10:30 AM, Peter Hutterer
>> > <pet...@wh...> wrote:
>> > > 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.
>> > This is interesting. So If I use xsetwacom with a shared name, who
>> > gets the config?
>>
>> no-one, xsetwacom will complain and require that you specify the ID
>> instead
>> :)
>>
>
> No strong opinions on my side either but my concerns are on how it effects
> output of "xinput list".  Do I continue to see in that list what an "eraser"
> is vs. a "touch"? Or would I need to issue a secondary command to see its
> tags?
>
> I've come to terms with duplicate device names (i.e. 2 erasers) since its
> not unique to wacom.  So thats no biggy but it has been nice to immediately
> see which part of tablet in its xinput name.
>
> Also, thinking from a possible future configuration GUI perspective, it
> would be nice if we could somehow bind a subset of devices together (a
> unique value; maybe the xinput # of first device in chain; shared in a tag
> or something).  That way you know what wacom "common" options are shared
> among what other input devices.  This is especially useful for tablets that
> have 2 input devices (such as Bamboo's) and so two sets of common options.
>
> Chris
>

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

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

On Mon, May 24, 2010 at 08:13:16AM -0500, Chris Bagwell wrote:
> On Mon, May 24, 2010 at 4:00 AM, Peter Hutterer <pet...@wh...>wrote:
> 
> > On Mon, May 24, 2010 at 11:27:23AM +0300, Alexia Death wrote:
> > > On Mon, May 24, 2010 at 10:30 AM, Peter Hutterer
> > > <pet...@wh...> wrote:
> > > > 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.
> > > This is interesting. So If I use xsetwacom with a shared name, who
> > > gets the config?
> >
> > no-one, xsetwacom will complain and require that you specify the ID instead
> > :)
> >
> >
> No strong opinions on my side either but my concerns are on how it effects
> output of "xinput list".  Do I continue to see in that list what an "eraser"
> is vs. a "touch"? Or would I need to issue a secondary command to see its
> tags?

tags are specific to the config backend only, they are not visible to any
client. In fact, right not they aren't even visible to drivers, but I'm
about to fix this ;)

> I've come to terms with duplicate device names (i.e. 2 erasers) since its
> not unique to wacom.  So thats no biggy but it has been nice to immediately
> see which part of tablet in its xinput name.
> 
> Also, thinking from a possible future configuration GUI perspective, it
> would be nice if we could somehow bind a subset of devices together (a
> unique value; maybe the xinput # of first device in chain; shared in a tag
> or something).  That way you know what wacom "common" options are shared
> among what other input devices.  This is especially useful for tablets that
> have 2 input devices (such as Bamboo's) and so two sets of common options.

This could be added to the wacom serial property, with one value being a
randomly assigned one for all tablets off one device.

Cheers,
  Peter
> 

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

[Ping C. <pin...@gm...>]

Acked-by: Ping Cheng <pin...@gm...>

Ping

On Mon, May 31, 2010 at 8:41 PM, Peter Hutterer
<pet...@wh...> wrote:
> This allows for the configuration of dependent devices by creating the
> appropriate match rules. Note that for the input attributes - just as for
> the device name - the type is simply appended to the end of the product
> name.
>
> Signed-off-by: Peter Hutterer <pet...@wh...>
> ---
> Note, this is the patch I sent out as RFC a few days or weeks back. Some
> parts (duplication of attributes) have moved into the server, making the
> patch a lot simpler.
>
> This requires an X server from git master.
>
>  src/wcmValidateDevice.c |   33 ++++++++++++++++++++++++++++++++-
>  1 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
> index eddc113..61abd8c 100644
> --- a/src/wcmValidateDevice.c
> +++ b/src/wcmValidateDevice.c
> @@ -300,6 +300,26 @@ static void wcmFreeInputOpts(InputOption* opts)
>        }
>  }
>
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
> +/**
> + * Duplicate the attributes of the given device. "product" gets the type
> + * appended, so a device of product "Wacom" will then have a product "Wacom
> + * eraser", "Wacom cursor", etc.
> + */
> +static InputAttributes* wcmDuplicateAttributes(LocalDevicePtr local,
> +                                              const char *type)
> +{
> +       InputAttributes *attr;
> +       attr = DuplicateInputAttributes(local->attrs);
> +                                                       /* add one space, one \0 */
> +       attr->product = realloc(attr->product, strlen(attr->product) + strlen(type) + 2);
> +       strcat(attr->product, " ");
> +       strcat(attr->product, type);
> +
> +       return attr;
> +}
> +#endif
> +
>  /**
>  * Hotplug one device of the given type.
>  * Device has the same options as the "parent" device, type is one of
> @@ -310,15 +330,26 @@ static void wcmHotplug(LocalDevicePtr local, const char *type)
>  {
>        DeviceIntPtr dev; /* dummy */
>        InputOption *input_options;
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> +       InputAttributes *attrs = NULL;
> +#endif
>
>        input_options = wcmOptionDupConvert(local, type);
>
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
> +       attrs = wcmDuplicateAttributes(local, type);
> +#endif
> +
>        NewInputDeviceRequest(input_options,
>  #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 9
> -                               NULL,
> +                               attrs,
>  #endif
>                                &dev);
>        wcmFreeInputOpts(input_options);
> +
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
> +       FreeInputAttributes(attrs);
> +#endif
>  }
>
>  void wcmHotplugOthers(LocalDevicePtr local)
> --
> 1.6.5.2
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Linuxwacom-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
>