All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Wacom Intuos4 LED and OLED control
@ 2011-04-08 22:54 Eduard Hasenleithner
  2011-04-13  9:08 ` Eduard Hasenleithner
  2011-05-06 15:52 ` Dmitry Torokhov
  0 siblings, 2 replies; 10+ messages in thread
From: Eduard Hasenleithner @ 2011-04-08 22:54 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input

This commit enables control of the LEDs and OLED displays found
on the Wacom Intuos4 M, L, and XL. For this purpose, a new "led"
attribute group is added to the sysfs entry of the input device.

This "led" group only shows up when the correct device (M, L,
or XL) is detected. Four write-only attributes are created:
* "luminance":
	array of three integers specfying
	* status led brightness when no button is pressed (0..127)
	* status led brightness when a button is pressed (0..127)
	* brightness of the OLED display (0..15)
* "status_select":
	specifies the id (0..3) of the status led, -1 = none
* "button_select":
	specifies the button id (0..7) of the image
* "button_rawimg":
	sets the raw image data of the button (binary, 1024 octets)

Signed-off-by: Eduard Hasenleithner <eduard@hasenleithner.at>
---
 drivers/input/tablet/wacom.h     |    9 +++
 drivers/input/tablet/wacom_sys.c |  105 ++++++++++++++++++++++++++++++++++++++
 drivers/input/tablet/wacom_wac.c |   67 ++++++++++++++++++++++++
 3 files changed, 181 insertions(+), 0 deletions(-)

diff --git a/drivers/input/tablet/wacom.h b/drivers/input/tablet/wacom.h
index 23317bd..580acba 100644
--- a/drivers/input/tablet/wacom.h
+++ b/drivers/input/tablet/wacom.h
@@ -114,10 +114,19 @@ struct wacom {
 	struct mutex lock;
 	bool open;
 	char phys[32];
+	struct wacom_led {
+		char select; /* status led selector (0..3, -1=none) */
+		char llv;    /* status led brightness no button */
+		char hlv;    /* status led brightness button pressed */
+		char img_lum;   /* OLED matrix display brightness */
+		char button_id; /* button_id for next wacom_led_putimage */
+	} led;
 };
 
 extern const struct usb_device_id wacom_ids[];
 
+int wacom_led_control(struct wacom *wacom);
+int wacom_led_putimage(struct wacom *wacom, const void *img);
 void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len);
 void wacom_setup_device_quirks(struct wacom_features *features);
 void wacom_setup_input_capabilities(struct input_dev *input_dev,
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 449c0a4..c573eef 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -465,6 +465,94 @@ static void wacom_remove_shared_data(struct wacom_wac *wacom)
 	}
 }
 
+static ssize_t led_select_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t count)
+{
+	long id;
+	int r = strict_strtol(buf, 10, &id);
+	if (r >= 0) {
+		struct wacom *wacom = dev_get_drvdata(dev);
+		wacom->led.select = id;
+		r = wacom_led_control(wacom);
+		if (r >= 0)
+			return count;
+		else
+			return r;
+	} else {
+		return r;
+	}
+}
+static DEVICE_ATTR(status_select, S_IWUSR, NULL, led_select_store);
+
+static ssize_t led_luminance_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t count)
+{
+	unsigned char llv, hlv, img_lum;
+	int r = sscanf(buf, "%hhu %hhu %hhu", &llv, &hlv, &img_lum);
+	if (r == 3) {
+		struct wacom *wacom = dev_get_drvdata(dev);
+		wacom->led.llv = llv & 0x7f;
+		wacom->led.hlv = hlv & 0x7f;
+		wacom->led.img_lum = img_lum & 0x7f;
+		r = wacom_led_control(wacom);
+		if (r >= 0)
+			return count;
+		else
+			return r;
+	} else {
+		return -EINVAL;
+	}
+}
+static DEVICE_ATTR(luminance, S_IWUSR, NULL, led_luminance_store);
+
+static ssize_t led_button_select(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t count)
+{
+	long id;
+	int r = strict_strtoul(buf, 10, &id);
+	if (r >= 0) {
+		struct wacom *wacom = dev_get_drvdata(dev);
+		wacom->led.button_id = id;
+		r = wacom_led_control(wacom);
+		if (r >= 0)
+			return count;
+		else
+			return r;
+	} else {
+		return r;
+	}
+}
+static DEVICE_ATTR(button_select, S_IWUSR, NULL, led_button_select);
+
+static ssize_t led_button_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t count)
+{
+	if (count == 1024) {
+		struct wacom *wacom = dev_get_drvdata(dev);
+		int r = wacom_led_putimage(wacom, buf);
+		if (r >= 0)
+			return count;
+		else
+			return r;
+	} else {
+		return -EINVAL;
+	}
+}
+static DEVICE_ATTR(button_rawimg, S_IWUSR, NULL, led_button_store);
+
+static struct attribute *wacom_led_attrs[] = {
+	&dev_attr_status_select.attr,
+	&dev_attr_luminance.attr,
+	&dev_attr_button_select.attr,
+	&dev_attr_button_rawimg.attr,
+	NULL
+};
+
+static struct attribute_group wacom_led_attr_group = {
+	.name = "led",
+	.attrs = wacom_led_attrs,
+};
+
 static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *id)
 {
 	struct usb_device *dev = interface_to_usbdev(intf);
@@ -557,6 +645,23 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
 	if (error)
 		goto fail4;
 
+	if (
+		wacom->wacom_wac.features.type >= INTUOS4 &&
+		wacom->wacom_wac.features.type <= INTUOS4L
+	) {
+		error = sysfs_create_group(&input_dev->dev.kobj,
+			&wacom_led_attr_group);
+		if (error)
+			dev_warn(&input_dev->dev,
+				"cannot create sysfs group err: %d\n", error);
+		/* init default values */
+		wacom->led.select = 0;
+		wacom->led.llv = 30;
+		wacom->led.hlv = 20;
+		wacom->led.img_lum = 10;
+		wacom_led_control(wacom);
+	}
+
 	/* Note that if query fails it is not a hard failure */
 	wacom_query_tablet_data(intf, features);
 
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 08ba5ad..1b58101 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1570,3 +1570,70 @@ const struct usb_device_id wacom_ids[] = {
 	{ }
 };
 MODULE_DEVICE_TABLE(usb, wacom_ids);
+
+#define WAC_CMD_RETRIES 10
+
+#define WAC_CMD_LED_CTRL 0x20
+#define WAC_CMD_ICON_START 0x21
+#define WAC_CMD_ICON_XFER 0x23
+
+static int wacom_command_xfer(struct usb_interface *intf,
+	unsigned char id, void *buf, int size)
+{
+	int rval, retries = WAC_CMD_RETRIES;
+	do rval = usb_control_msg(interface_to_usbdev(intf),
+		usb_sndctrlpipe(interface_to_usbdev(intf), 0),
+		0x09, USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+		0x300 | id, intf->altsetting[0].desc.bInterfaceNumber,
+		buf, size, 1000);
+	while ((rval == -ETIMEDOUT || rval == -EPIPE) && --retries > 0);
+
+	return rval;
+}
+
+int wacom_led_control(struct wacom *wacom)
+{
+	char buf[9] = {
+		WAC_CMD_LED_CTRL,
+		wacom->led.select >= 0 ? wacom->led.select|4 : 0,
+		wacom->led.llv,
+		wacom->led.hlv,
+		wacom->led.img_lum,
+		0, 0, 0, 0
+	};
+
+	return wacom_command_xfer(wacom->intf,
+		WAC_CMD_LED_CTRL, buf, sizeof buf);
+}
+
+static int wacom_icon_start(struct usb_interface *intf, int start)
+{
+	char buf[2] = { WAC_CMD_ICON_START, start };
+	return wacom_command_xfer(intf, WAC_CMD_ICON_START, buf, sizeof buf);
+}
+
+int wacom_led_putimage(struct wacom *wacom, const void *img)
+{
+	unsigned char *buf;
+	int i, rval;
+
+	buf = kzalloc(259, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+	rval = wacom_icon_start(wacom->intf, 1);
+	if (rval >= 0) {
+		buf[0] = WAC_CMD_ICON_XFER;
+		buf[1] = wacom->led.button_id & 0x07;
+		for (i = 0; i < 4; i++) {
+			buf[2] = i;
+			memcpy(buf+3, img + i*256, 256);
+			rval = wacom_command_xfer(wacom->intf,
+				WAC_CMD_ICON_XFER, buf, 259);
+			if (rval < 0)
+				break;
+		}
+	}
+	kfree(buf);
+	wacom_icon_start(wacom->intf, 0);
+	return rval;
+}
-- 
1.7.0.4


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-04-08 22:54 [PATCH] Wacom Intuos4 LED and OLED control Eduard Hasenleithner
@ 2011-04-13  9:08 ` Eduard Hasenleithner
  2011-05-06 15:52 ` Dmitry Torokhov
  1 sibling, 0 replies; 10+ messages in thread
From: Eduard Hasenleithner @ 2011-04-13  9:08 UTC (permalink / raw)
  To: Eduard Hasenleithner; +Cc: Dmitry Torokhov, linux-input

Hi Dmitry.

Did this new patch reach your inbox?

Thanks,
Eduard

2011/4/9 Eduard Hasenleithner <eduard@hasenleithner.at>:
> This commit enables control of the LEDs and OLED displays found
> on the Wacom Intuos4 M, L, and XL. For this purpose, a new "led"
> attribute group is added to the sysfs entry of the input device.
>
> This "led" group only shows up when the correct device (M, L,
> or XL) is detected. Four write-only attributes are created:
> * "luminance":
>        array of three integers specfying
>        * status led brightness when no button is pressed (0..127)
>        * status led brightness when a button is pressed (0..127)
>        * brightness of the OLED display (0..15)
> * "status_select":
>        specifies the id (0..3) of the status led, -1 = none
> * "button_select":
>        specifies the button id (0..7) of the image
> * "button_rawimg":
>        sets the raw image data of the button (binary, 1024 octets)
>
> Signed-off-by: Eduard Hasenleithner <eduard@hasenleithner.at>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-04-08 22:54 [PATCH] Wacom Intuos4 LED and OLED control Eduard Hasenleithner
  2011-04-13  9:08 ` Eduard Hasenleithner
@ 2011-05-06 15:52 ` Dmitry Torokhov
  2011-05-06 16:28   ` Eduard Hasenleithner
  1 sibling, 1 reply; 10+ messages in thread
From: Dmitry Torokhov @ 2011-05-06 15:52 UTC (permalink / raw)
  To: Eduard Hasenleithner; +Cc: linux-input

Hi Eduard,

On Sat, Apr 09, 2011 at 12:54:14AM +0200, Eduard Hasenleithner wrote:
> This commit enables control of the LEDs and OLED displays found
> on the Wacom Intuos4 M, L, and XL. For this purpose, a new "led"
> attribute group is added to the sysfs entry of the input device.
> 
> This "led" group only shows up when the correct device (M, L,
> or XL) is detected. Four write-only attributes are created:
> * "luminance":
> 	array of three integers specfying
> 	* status led brightness when no button is pressed (0..127)
> 	* status led brightness when a button is pressed (0..127)
> 	* brightness of the OLED display (0..15)

This violates "one value per attribute" sysfs principle. I think these
should be split into brightness on, brightness off, and display brightness.
I also wonder if status LED should be wired into LED subsystem... Not
sure though... The tablet does not allow controlling when LEDs are
activated, does it?

> * "status_select":
> 	specifies the id (0..3) of the status led, -1 = none

I think we should create 4 separate groups led0 .. led3 each containing
the attributes above instead of implementing the selector which is
inherently racy.

> * "button_select":
> 	specifies the button id (0..7) of the image
> * "button_rawimg":
> 	sets the raw image data of the button (binary, 1024 octets)

Same here, create as many binary attributes as needed (probably putting
into separate group).

Also please document these attributes in
Documentation/ABI/testing/sysfs-wacom

Thanks!

-- 
Dmitry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-05-06 15:52 ` Dmitry Torokhov
@ 2011-05-06 16:28   ` Eduard Hasenleithner
  2011-05-06 16:43     ` Dmitry Torokhov
  0 siblings, 1 reply; 10+ messages in thread
From: Eduard Hasenleithner @ 2011-05-06 16:28 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input

Hi Dmitry.

On 2011-05-06 17:52, Dmitry Torokhov wrote:
>> This "led" group only shows up when the correct device (M, L,
>> or XL) is detected. Four write-only attributes are created:
>> * "luminance":
>> 	array of three integers specfying
>> 	* status led brightness when no button is pressed (0..127)
>> 	* status led brightness when a button is pressed (0..127)
>> 	* brightness of the OLED display (0..15)
>
> This violates "one value per attribute" sysfs principle. I think these
> should be split into brightness on, brightness off, and display brightness.

The intention behind grouping these three together is that on the 
USB-protocol level they are always set at the same time. Furthermore, on 
the logical level they are very closely related. I have seen some other 
driver doing it like that: Writing individual settings into different 
properties, and then activating them at the same time by means of some 
"tigger" property. Would you be fine with that?

> I also wonder if status LED should be wired into LED subsystem... Not
> sure though... The tablet does not allow controlling when LEDs are
> activated, does it?

I'm not sure what you mean with "controlling". You can set the status 
LED at any time, other functions are not affected (at least as far I 
know.) But I would perfer of not putting the LED into the LED subsystem 
for several reasons:
1. It is harder from user-space to get the connection
	between LED-Device and Tablet-device
2. yet another interface to support in Kernel and User-Space, and
3. the four status LEDs are exclusive, only one of them can be
	"on" at a time.

>> * "status_select":
>> 	specifies the id (0..3) of the status led, -1 = none
>
> I think we should create 4 separate groups led0 .. led3 each containing
> the attributes above instead of implementing the selector which is
> inherently racy.

It selects the led which is "on", the others are implicitly off. So for 
the status led, there are five different settings, either 0..3, or -1 
for all LEDs to be off.  Maybe "selector" is not the best naming?

>> * "button_select":
>> 	specifies the button id (0..7) of the image
>> * "button_rawimg":
>> 	sets the raw image data of the button (binary, 1024 octets)
>
> Same here, create as many binary attributes as needed (probably putting
> into separate group).

Well "button_select" is different from "status_select". While 
status_select actually does something (change which led is on), 
button_select just pre-sets which button image will be overwritten at 
the next write.

I will change the interface to have "buttonN_rawimg" parameters, where N 
is the button number.

> Also please document these attributes in
> Documentation/ABI/testing/sysfs-wacom

I was already planning to add this to this patch, but hesitated to do it 
because the "README" tells to add the documentation when "interfaces are 
felt to be stable as the main development of this interface has been 
completed". Since we are still discussing the interface, I got the 
feeling it is not yet "stable".

Thanks for your comments,
Eduard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-05-06 16:28   ` Eduard Hasenleithner
@ 2011-05-06 16:43     ` Dmitry Torokhov
  2011-05-06 17:32       ` Eduard Hasenleithner
  0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Torokhov @ 2011-05-06 16:43 UTC (permalink / raw)
  To: Eduard Hasenleithner; +Cc: linux-input

On Fri, May 06, 2011 at 06:28:47PM +0200, Eduard Hasenleithner wrote:
> Hi Dmitry.
> 
> On 2011-05-06 17:52, Dmitry Torokhov wrote:
> >>This "led" group only shows up when the correct device (M, L,
> >>or XL) is detected. Four write-only attributes are created:
> >>* "luminance":
> >>	array of three integers specfying
> >>	* status led brightness when no button is pressed (0..127)
> >>	* status led brightness when a button is pressed (0..127)
> >>	* brightness of the OLED display (0..15)
> >
> >This violates "one value per attribute" sysfs principle. I think these
> >should be split into brightness on, brightness off, and display brightness.
> 
> The intention behind grouping these three together is that on the
> USB-protocol level they are always set at the same time.
> Furthermore, on the logical level they are very closely related. I
> have seen some other driver doing it like that: Writing individual
> settings into different properties, and then activating them at the
> same time by means of some "tigger" property. Would you be fine with
> that?

I think it just complicates the interface. Even though all
3 values are transmitted to the device at the same time we can let
userspace set them individually and when sending data to the device use
cached values to complement the newly set one.

> 
> >I also wonder if status LED should be wired into LED subsystem... Not
> >sure though... The tablet does not allow controlling when LEDs are
> >activated, does it?
> 
> I'm not sure what you mean with "controlling". You can set the
> status LED at any time, other functions are not affected (at least
> as far I know.) But I would perfer of not putting the LED into the
> LED subsystem for several reasons:
> 1. It is harder from user-space to get the connection
> 	between LED-Device and Tablet-device
> 2. yet another interface to support in Kernel and User-Space, and
> 3. the four status LEDs are exclusive, only one of them can be
> 	"on" at a time.

OK, fair enough.

> 
> >>* "status_select":
> >>	specifies the id (0..3) of the status led, -1 = none
> >
> >I think we should create 4 separate groups led0 .. led3 each containing
> >the attributes above instead of implementing the selector which is
> >inherently racy.
> 
> It selects the led which is "on", the others are implicitly off. So
> for the status led, there are five different settings, either 0..3,
> or -1 for all LEDs to be off.  Maybe "selector" is not the best
> naming?

Hmm, my understanding of the device is hazy then. So you can select a
LED that will be activated/deactivated when user presses a certain
button on the device and the rest are staying off?

> 
> >>* "button_select":
> >>	specifies the button id (0..7) of the image
> >>* "button_rawimg":
> >>	sets the raw image data of the button (binary, 1024 octets)
> >
> >Same here, create as many binary attributes as needed (probably putting
> >into separate group).
> 
> Well "button_select" is different from "status_select". While
> status_select actually does something (change which led is on),
> button_select just pre-sets which button image will be overwritten
> at the next write.
> 
> I will change the interface to have "buttonN_rawimg" parameters,
> where N is the button number.
> 
> >Also please document these attributes in
> >Documentation/ABI/testing/sysfs-wacom
> 
> I was already planning to add this to this patch, but hesitated to
> do it because the "README" tells to add the documentation when
> "interfaces are felt to be stable as the main development of this
> interface has been completed". Since we are still discussing the
> interface, I got the feeling it is not yet "stable".

OK, fair enough, but then there will be an extra roundrip at the time
when I feel I am ready to apply the patch.

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-05-06 16:43     ` Dmitry Torokhov
@ 2011-05-06 17:32       ` Eduard Hasenleithner
  2011-05-06 17:42         ` Dmitry Torokhov
  0 siblings, 1 reply; 10+ messages in thread
From: Eduard Hasenleithner @ 2011-05-06 17:32 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input

On 2011-05-06 18:43, Dmitry Torokhov wrote:
> I think it just complicates the interface. Even though all
> 3 values are transmitted to the device at the same time we can let
> userspace set them individually and when sending data to the device use
> cached values to complement the newly set one.

Ok, will be implemented this way.

>>>> * "status_select":
>>>> 	specifies the id (0..3) of the status led, -1 = none
>>>
>>> I think we should create 4 separate groups led0 .. led3 each containing
>>> the attributes above instead of implementing the selector which is
>>> inherently racy.
>>
>> It selects the led which is "on", the others are implicitly off. So
>> for the status led, there are five different settings, either 0..3,
>> or -1 for all LEDs to be off.  Maybe "selector" is not the best
>> naming?
>
> Hmm, my understanding of the device is hazy then. So you can select a
> LED that will be activated/deactivated when user presses a certain
> button on the device and the rest are staying off?

Apparently, for a device having only four LEDs wacom managed to 
implement a behaviour, which is not easy to explain. These four LEDs 
have two functions, one is the "status" LED function, the other is what 
I call the "wheel function indicator" LED function.

Devices before Intuos4 just had a single status LED with three luminance 
levels "high" and "low" and "off". When "off" it means that the device 
is not ready for use (e.g driver not loaded, or device not connected). 
When "low", this LED just says to the user "Driver loaded, ready for 
input". When the stylus then touches the tablet surface, it lights with 
the "high" level. The same behavior is also obvserved when the stylus is 
in proximity to the tablet, and a button on the stylus is pressed. In 
the end, having the status-LED at "high" level means that logically at 
least one stylus "button" is pressed, including the vitual "stylus has 
contact with tablet surface" button.

The Intuos4 adds the possibility to set the luminance levels for "high" 
and "low" states, with values from 0..127. low=32 and high=64 means that 
the status led will brighten during stylus contact, low=64 and high=32 
will cause the status LED to dim during stylus contact.

With Intuos4 wacom also added a touch wheel to the tablet. In the 
windows-driver it is possible to control four different "axes" with the 
single touch wheel. In order to know which axis is controlled, they 
could have simply added another four LEDs, with one of them being "on", 
giving a total of five leds. But they saved one LED, and put the status 
information to the one LED which shows the current wheel function 
"selection".

The wheel selection function is only implemented in the driver. Changing 
which LED is "on", does not change the events generated by the tabled. 
So in the end, there are four "wheel function indicator" LEDs on the 
device, with the active wheel function LED being also the status LED of 
the device.

>> I was already planning to add this to this patch, but hesitated to
>> do it because the "README" tells to add the documentation when
>> "interfaces are felt to be stable as the main development of this
>> interface has been completed". Since we are still discussing the
>> interface, I got the feeling it is not yet "stable".
>
> OK, fair enough, but then there will be an extra roundrip at the time
> when I feel I am ready to apply the patch.

So, as you are fine with it, I will add the ABI documentation with the 
next patch.

Thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-05-06 17:32       ` Eduard Hasenleithner
@ 2011-05-06 17:42         ` Dmitry Torokhov
  2011-05-06 17:57           ` Eduard Hasenleithner
  0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Torokhov @ 2011-05-06 17:42 UTC (permalink / raw)
  To: Eduard Hasenleithner; +Cc: linux-input

On Fri, May 6, 2011 at 10:32 AM, Eduard Hasenleithner
<eduard@hasenleithner.at> wrote:
> Apparently, for a device having only four LEDs wacom managed to implement a
> behaviour, which is not easy to explain. These four LEDs have two functions,
> one is the "status" LED function, the other is what I call the "wheel
> function indicator" LED function.
>
> Devices before Intuos4 just had a single status LED with three luminance
> levels "high" and "low" and "off". When "off" it means that the device is
> not ready for use (e.g driver not loaded, or device not connected). When
> "low", this LED just says to the user "Driver loaded, ready for input". When
> the stylus then touches the tablet surface, it lights with the "high" level.
> The same behavior is also obvserved when the stylus is in proximity to the
> tablet, and a button on the stylus is pressed. In the end, having the
> status-LED at "high" level means that logically at least one stylus "button"
> is pressed, including the vitual "stylus has contact with tablet surface"
> button.
>
> The Intuos4 adds the possibility to set the luminance levels for "high" and
> "low" states, with values from 0..127. low=32 and high=64 means that the
> status led will brighten during stylus contact, low=64 and high=32 will
> cause the status LED to dim during stylus contact.
>
> With Intuos4 wacom also added a touch wheel to the tablet. In the
> windows-driver it is possible to control four different "axes" with the
> single touch wheel. In order to know which axis is controlled, they could
> have simply added another four LEDs, with one of them being "on", giving a
> total of five leds. But they saved one LED, and put the status information
> to the one LED which shows the current wheel function "selection".

I see. Do all 4 leds share the settings for luminance?

-- 
Dmitry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-05-06 17:42         ` Dmitry Torokhov
@ 2011-05-06 17:57           ` Eduard Hasenleithner
  2011-06-02  9:51             ` San Vu Ngoc
  0 siblings, 1 reply; 10+ messages in thread
From: Eduard Hasenleithner @ 2011-05-06 17:57 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input


----- Ursprüngliche Mitteilung -----
> On Fri, May 6, 2011 at 10:32 AM, Eduard Hasenleithner
> <eduard@hasenleithner.at> wrote:

> > With Intuos4 wacom also added a touch wheel to the tablet. In the
> > windows-driver it is possible to control four different "axes" with the
> > single touch wheel. In order to know which axis is controlled, they
> > could have simply added another four LEDs, with one of them being
> > "on", giving a total of five leds. But they saved one LED, and put the
> > status information to the one LED which shows the current wheel
> > function "selection".
> 
> I see. Do all 4 leds share the settings for luminance?

Yes, Exactly.

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
  2011-05-06 17:57           ` Eduard Hasenleithner
@ 2011-06-02  9:51             ` San Vu Ngoc
       [not found]               ` <BANLkTi=E4BEpF0G90q4zNHtVLvpTDhWtvA@mail.gmail.com>
  0 siblings, 1 reply; 10+ messages in thread
From: San Vu Ngoc @ 2011-06-02  9:51 UTC (permalink / raw)
  To: linux-input

Eduard Hasenleithner <eduard <at> hasenleithner.at> writes:

> 
> 
> ----- Ursprüngliche Mitteilung -----
> > On Fri, May 6, 2011 at 10:32 AM, Eduard Hasenleithner
> > <eduard <at> hasenleithner.at> wrote:
> 
> > > With Intuos4 wacom also added a touch wheel to the tablet. In the
> > > windows-driver it is possible to control four different "axes" with the
> > > single touch wheel. In order to know which axis is controlled, they
> > > could have simply added another four LEDs, with one of them being
> > > "on", giving a total of five leds. But they saved one LED, and put the
> > > status information to the one LED which shows the current wheel
> > > function "selection".
> > 
> > I see. Do all 4 leds share the settings for luminance?
> 
> Yes, Exactly.
> 
> Eduard.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

I just wanted to say that I have tested the patch at

https://patchwork.kernel.org/patch/765792/

and (as a simple user) I find it great !
It works perfectly on my kubuntu 11.04
(after I chmod the files in /sys/class/input/input13/led to read-write)

A beginners' question: the device can be accessed by, for instance

/sys/class/input/input13

What is the best way to find out which number it is (here 13) ?

Thanks again for this great patch, for us, Intuos4 users.

San



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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Wacom Intuos4 LED and OLED control
       [not found]                 ` <20110817071724.GF29361@core.coreip.homeip.net>
@ 2011-09-02 21:48                   ` Eduard Hasenleithner
  0 siblings, 0 replies; 10+ messages in thread
From: Eduard Hasenleithner @ 2011-09-02 21:48 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input

Hi Dmitry.

It has been quite some time since our last conversation and I didn't
look in my inbox so frequent.

Thanks for reworking the patch to meet the requirements. The patch
appears to work for the status led, but not for the button images. I
tracked down the problem to a wrong command being used in
wacom_led_putimage. Please see inline. After I changed this line, the
kernel driver was also able to put images. I'd be happy to see the
patch in 3.2, but I'm not in a hurry.

Eduard

2011/8/17 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> +static int wacom_led_putimage(struct wacom *wacom, int button_id, const void *img)
> +{
> +       unsigned char *buf;
> +       int i, retval;
> +
> +       buf = kzalloc(259, GFP_KERNEL);
> +       if (!buf)
> +               return -ENOMEM;
> +
> +       /* Send 'start' command */
> +       buf[0] = WAC_CMD_ICON_START;
> +       buf[1] = 1;
> +       retval = wacom_set_report(wacom->intf, 0x03, WAC_CMD_ICON_START,
> +                                 buf, 2, WAC_CMD_RETRIES);
> +       if (retval < 0)
> +               goto out;
> +
> +       buf[0] = WAC_CMD_ICON_XFER;
> +       buf[1] = button_id & 0x07;
> +       for (i = 0; i < 4; i++) {
> +               buf[2] = i;
> +               memcpy(buf + 3, img + i * 256, 256);
> +
> +               retval = wacom_set_report(wacom->intf, 0x03, WAC_CMD_ICON_START,
> +                                         buf, 259, WAC_CMD_RETRIES);

Here is the error: WAC_CMD_ICON_START instead of the correct
WAC_CMD_ICON_XFER was used. Don't ask my why the command has to be
specified two times.

> +               if (retval < 0)
> +                       break;
> +       }
> +
> +       /* Send 'stop' */
> +       buf[0] = WAC_CMD_ICON_START;
> +       buf[1] = 0;
> +       wacom_set_report(wacom->intf, 0x03, WAC_CMD_ICON_START,
> +                        buf, 2, WAC_CMD_RETRIES);
> +
> +out:
> +       kfree(buf);
> +       return retval;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2011-09-02 21:48 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-08 22:54 [PATCH] Wacom Intuos4 LED and OLED control Eduard Hasenleithner
2011-04-13  9:08 ` Eduard Hasenleithner
2011-05-06 15:52 ` Dmitry Torokhov
2011-05-06 16:28   ` Eduard Hasenleithner
2011-05-06 16:43     ` Dmitry Torokhov
2011-05-06 17:32       ` Eduard Hasenleithner
2011-05-06 17:42         ` Dmitry Torokhov
2011-05-06 17:57           ` Eduard Hasenleithner
2011-06-02  9:51             ` San Vu Ngoc
     [not found]               ` <BANLkTi=E4BEpF0G90q4zNHtVLvpTDhWtvA@mail.gmail.com>
     [not found]                 ` <20110817071724.GF29361@core.coreip.homeip.net>
2011-09-02 21:48                   ` Eduard Hasenleithner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.