Re: [Linuxwacom-devel] [PATCH] HID: wacom: Force new name for Wacom Intuos4 WL PTK-540WL

2012-02-18 Thread Chris Bagwell
On Fri, Feb 17, 2012 at 11:47 AM, Przemo Firszt prz...@firszt.eu wrote:
 The name reported by Inutos4 WL connected by bluetooth is PTK-540WL and
 to make it consistent with other Wacom devices it has to be converted to
 Wacom Intuos4 WL. It also makes userland applications aware that it's
 a Wacom device.

 Signed-off-by: Przemo Firszt prz...@firszt.eu
 ---

Its worth noting this aligns naming of device to same used when this
device is plugged into USB port and controlled by USB wacom driver;
and thus helps align userland logic to route to apps like
xf86-input-wacom.

Reviewed-by: Chris Bagwell ch...@cnpbagwell.com

  drivers/hid/hid-wacom.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
 index acab74c..0621047 100644
 --- a/drivers/hid/hid-wacom.c
 +++ b/drivers/hid/hid-wacom.c
 @@ -518,6 +518,7 @@ static int wacom_probe(struct hid_device *hdev,
                wacom_poke(hdev, 1);
                break;
        case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
 +               sprintf(hdev-name, %s, Wacom Intuos4 WL);
                wdata-features = 0;
                wacom_set_features(hdev);
                break;
 --
 1.7.6.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-input in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


[Linuxwacom-devel] [PATCH] HID: wacom: Force new name for Wacom Intuos4 WL PTK-540WL

2012-02-18 Thread Przemo Firszt
The name reported by Inutos4 WL connected by bluetooth is PTK-540WL and
to make it consistent with other Wacom devices it has to be converted to
Wacom Intuos4 WL. It also makes userland applications aware that it's
a Wacom device.

Signed-off-by: Przemo Firszt prz...@firszt.eu
---
 drivers/hid/hid-wacom.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index acab74c..0621047 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -518,6 +518,7 @@ static int wacom_probe(struct hid_device *hdev,
wacom_poke(hdev, 1);
break;
case USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH:
+   sprintf(hdev-name, %s, Wacom Intuos4 WL);
wdata-features = 0;
wacom_set_features(hdev);
break;
-- 
1.7.6.4


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


Re: [Linuxwacom-devel] [PATCH v3] Enable LED status change through xsetwacom

2012-02-18 Thread Bastien Nocera
Peter Hutterer peter.hutterer@... writes:
 On Wed, Feb 08, 2012 at 08:30:58AM -0800, Jason Gerecke wrote:
  Any feedback on the changes or ideas on exposing the properties?
 
 sorry for the delay. short answer - I don't think we should merge this
 support as properties. properties are not well-suited for this, they are too
 generic and too much knowledge must reside in the client setting them.

Exactly. But the client should be the one handling the mode switching, and the
button actions in the first place. So I don't see what's wrong with exposing
it as a property. It would make it available now, and make it possible for me 
to make the mode switching work in GNOME 3.4 (I really don't want to have mode
switching enabled if I can't show the user that the mode has indeed switched).

So I'm in favour of one property per LED group, and a bitmask as to which one
is lit up (if even just an index, if we want to force 1 LED lit at all times).

 Instead, we should extend the protocol for XI 2.3 to add a LED class and the
 required requests to modify the LEDs support. This gives us
 more flexibility handling LEDs and less driver-dependent behaviour.

That's nice. It doesn't require using properties. but it does still require
the client having special knowledge of the device. It's not like one would set
the LEDs the same way on a Wacom tablet and a PS3 joypad for example.

Cheers


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel