[PATCH] input: Add support for the Bamboo Touch trackpad

[PATCH] input: Add support for the Bamboo Touch trackpad

[Henrik Rydberg]

Add support for the Bamboo Touch trackpad, and make it work well with
both the Synaptics X Driver and the Multitouch X Driver. The device
uses MT slots internally, so the choice of protocol is a given.

Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
Hi Dmitry, Ping,

Here is a small patch which adds trackpad support for the Bamboo Touch. There are a couple if things to discuss:

1) It uses the MT slot protocol
2) It creates two input devices, but only one is useful
3) It works well with the synaptics and multitouch X drivers
4) It does not work well with the wacom X driver (!)

In particular the last point may seem upsetting, but my reasoning is
simply that the wacom X driver really supports tablets and not
trackpads. I might be convinced otherwise. :-)

Cheers,
Henrik

 drivers/input/tablet/wacom_wac.c |   76 ++++++++++++++++++++++++++++++++++++++
 drivers/input/tablet/wacom_wac.h |    6 +++
 2 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 40d77ba..61dbd5d 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -855,6 +855,52 @@ static int wacom_tpc_irq(struct wacom_wac *wacom, size_t len)
 	return retval;
 }
 
+static int wacom_bbt_irq(struct wacom_wac *wacom, size_t len)
+{
+	static int trkid;
+	struct input_dev *input = wacom->input;
+	unsigned char *data = wacom->data;
+	int i, sp = 0, sx = 0, sy = 0, count = 0;
+
+	if (len != WACOM_PKGLEN_BBTOUCH)
+		return 0;
+
+	for (i = 0; i < 2; i++) {
+		int p = data[9 * i + 2];
+		input_mt_slot(input, i);
+		if (p) {
+			int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
+			int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
+			input_report_abs(input, ABS_MT_PRESSURE, p);
+			input_report_abs(input, ABS_MT_POSITION_X, x);
+			input_report_abs(input, ABS_MT_POSITION_Y, y);
+			if (wacom->id[i] < 0)
+				wacom->id[i] = trkid++ & MAX_TRACKING_ID;
+			if (!count++)
+				sp = p, sx = x, sy = y;
+		} else {
+			wacom->id[i] = -1;
+		}
+		input_report_abs(input, ABS_MT_TRACKING_ID, wacom->id[i]);
+	}
+
+	input_report_key(input, BTN_TOUCH, count > 0);
+	input_report_key(input, BTN_TOOL_FINGER, count == 1);
+	input_report_key(input, BTN_TOOL_DOUBLETAP, count == 2);
+
+	input_report_abs(input, ABS_PRESSURE, sp);
+	input_report_abs(input, ABS_X, sx);
+	input_report_abs(input, ABS_Y, sy);
+
+	input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
+	input_report_key(input, BTN_MIDDLE, (data[1] & 0x06) != 0);
+	input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
+
+	input_sync(input);
+
+	return 0;
+}
+
 void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 {
 	bool sync;
@@ -900,6 +946,10 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 		sync = wacom_tpc_irq(wacom_wac, len);
 		break;
 
+	case BAMBOO_TOUCH:
+		sync = wacom_bbt_irq(wacom_wac, len);
+		break;
+
 	default:
 		sync = false;
 		break;
@@ -1076,6 +1126,22 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
 	case PENPARTNER:
 		__set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
 		break;
+
+	case BAMBOO_TOUCH:
+		__clear_bit(ABS_MISC, input_dev->absbit);
+		__set_bit(BTN_LEFT, input_dev->keybit);
+		__set_bit(BTN_MIDDLE, input_dev->keybit);
+		__set_bit(BTN_RIGHT, input_dev->keybit);
+
+		__set_bit(BTN_TOOL_FINGER, input_dev->keybit);
+		__set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
+
+		input_mt_create_slots(input_dev, 2);
+		input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, features->x_max, 4, 0);
+		input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, features->y_max, 4, 0);
+		input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, features->pressure_max, 16, 0);
+		input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, MAX_TRACKING_ID, 0, 0);
+		break;
 	}
 }
 
@@ -1213,11 +1279,19 @@ static const struct wacom_features wacom_features_0xE3 =
 	{ "Wacom ISDv4 E3",       WACOM_PKGLEN_TPC2FG,    26202, 16325,  255,  0, TABLETPC2FG };
 static const struct wacom_features wacom_features_0x47 =
 	{ "Wacom Intuos2 6x8",    WACOM_PKGLEN_INTUOS,    20320, 16240, 1023, 31, INTUOS };
+static const struct wacom_features wacom_features_0xD0_0 =
+	{ "Wacom Bamboo Touch",   WACOM_PKGLEN_BBTOUCH,   480,  320, 255, 0, BAMBOO_TOUCH };
+static const struct wacom_features wacom_features_0xD0_2 =
+	{ "Wacom Bamboo Boot",   WACOM_PKGLEN_BBFUN,     480,  320, 255, 0, BAMBOO_BOOT };
 
 #define USB_DEVICE_WACOM(prod)					\
 	USB_DEVICE(USB_VENDOR_ID_WACOM, prod),			\
 	.driver_info = (kernel_ulong_t)&wacom_features_##prod
 
+#define USB_DEVICE_WACOM_PROTO(prod, pr)				\
+	USB_DEVICE_INTERFACE_PROTOCOL(USB_VENDOR_ID_WACOM, prod, pr),	\
+	.driver_info = (kernel_ulong_t)&wacom_features_##prod##_##pr
+
 const struct usb_device_id wacom_ids[] = {
 	{ USB_DEVICE_WACOM(0x00) },
 	{ USB_DEVICE_WACOM(0x10) },
@@ -1277,6 +1351,8 @@ const struct usb_device_id wacom_ids[] = {
 	{ USB_DEVICE_WACOM(0xC6) },
 	{ USB_DEVICE_WACOM(0xC7) },
 	{ USB_DEVICE_WACOM(0xCE) },
+	{ USB_DEVICE_WACOM_PROTO(0xD0, 0) },
+	{ USB_DEVICE_WACOM_PROTO(0xD0, 2) },
 	{ USB_DEVICE_WACOM(0xF0) },
 	{ USB_DEVICE_WACOM(0xCC) },
 	{ USB_DEVICE_WACOM(0x90) },
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index 99e1a54..770909c 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -21,6 +21,7 @@
 #define WACOM_PKGLEN_INTUOS	10
 #define WACOM_PKGLEN_TPC1FG	 5
 #define WACOM_PKGLEN_TPC2FG	14
+#define WACOM_PKGLEN_BBTOUCH	20
 
 /* device IDs */
 #define STYLUS_DEVICE_ID	0x02
@@ -37,6 +38,9 @@
 #define WACOM_REPORT_TPC1FG		6
 #define WACOM_REPORT_TPC2FG		13
 
+/* largest reported tracking id */
+#define MAX_TRACKING_ID			0xfff
+
 enum {
 	PENPARTNER = 0,
 	GRAPHIRE,
@@ -57,6 +61,8 @@ enum {
 	WACOM_MO,
 	TABLETPC,
 	TABLETPC2FG,
+	BAMBOO_TOUCH,
+	BAMBOO_BOOT,
 	MAX_TYPE
 };
 
-- 
1.7.1

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Ping Cheng]

Hi Henrik,

Thank you for providing the MT support for Wacom's Bamboo touch only
device. Please see my comments inline.

Ping

On Sun, Aug 22, 2010 at 4:10 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Add support for the Bamboo Touch trackpad, and make it work well with
> both the Synaptics X Driver and the Multitouch X Driver. The device
> uses MT slots internally, so the choice of protocol is a given.
>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Dmitry, Ping,
>
> Here is a small patch which adds trackpad support for the Bamboo Touch. There are a couple if things to discuss:
>
> 1) It uses the MT slot protocol
> 2) It creates two input devices, but only one is useful

I would like to keep the same wacom_features and usb_device_id
wacom_ids structures for Bamboo as we did for all the other models,
i.e., we define one entry for Bamboo although there could be more than
one logical devices (touch and pen) associated with it.

This may not make a difference for your Bamboo (a touch only device).
It would make the code easy to maintain for the other Bamboos (Product
ID: 0xd1, 0xd2, 0xd3, and 0xd4).

If you are not sure what I am talking about, please let me know.

> 3) It works well with the synaptics and multitouch X drivers

I guess it depends on what the plan is for MT support in the userland.
If our goal is to make the MT X driver generic, there would be no need
to have a Wacom X drvier for MT (I'd love to go with this route). If
the MT X driver is only a way to test the kernel driver, we'll have to
discuss what to do next.

> 4) It does not work well with the wacom X driver (!)

This would not be an issue if we (as a team working in the community)
can answer item 3 above properly.

> In particular the last point may seem upsetting, but my reasoning is
> simply that the wacom X driver really supports tablets and not
> trackpads. I might be convinced otherwise. :-)

As I said earlier, I would love to see MT supported by a generic X driver.

>
> Cheers,
> Henrik
>
>  drivers/input/tablet/wacom_wac.c |   76 ++++++++++++++++++++++++++++++++++++++
>  drivers/input/tablet/wacom_wac.h |    6 +++
>  2 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index 40d77ba..61dbd5d 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -855,6 +855,52 @@ static int wacom_tpc_irq(struct wacom_wac *wacom, size_t len)
>        return retval;
>  }
>
> +static int wacom_bbt_irq(struct wacom_wac *wacom, size_t len)
> +{
> +       static int trkid;
> +       struct input_dev *input = wacom->input;
> +       unsigned char *data = wacom->data;
> +       int i, sp = 0, sx = 0, sy = 0, count = 0;
> +
> +       if (len != WACOM_PKGLEN_BBTOUCH)
> +               return 0;
> +
> +       for (i = 0; i < 2; i++) {
> +               int p = data[9 * i + 2];
> +               input_mt_slot(input, i);
> +               if (p) {
> +                       int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
> +                       int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
> +                       input_report_abs(input, ABS_MT_PRESSURE, p);
> +                       input_report_abs(input, ABS_MT_POSITION_X, x);
> +                       input_report_abs(input, ABS_MT_POSITION_Y, y);
> +                       if (wacom->id[i] < 0)
> +                               wacom->id[i] = trkid++ & MAX_TRACKING_ID;
> +                       if (!count++)
> +                               sp = p, sx = x, sy = y;
> +               } else {
> +                       wacom->id[i] = -1;
> +               }
> +               input_report_abs(input, ABS_MT_TRACKING_ID, wacom->id[i]);
> +       }
> +
> +       input_report_key(input, BTN_TOUCH, count > 0);
> +       input_report_key(input, BTN_TOOL_FINGER, count == 1);
> +       input_report_key(input, BTN_TOOL_DOUBLETAP, count == 2);
> +
> +       input_report_abs(input, ABS_PRESSURE, sp);
> +       input_report_abs(input, ABS_X, sx);
> +       input_report_abs(input, ABS_Y, sy);
> +
> +       input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
> +       input_report_key(input, BTN_MIDDLE, (data[1] & 0x06) != 0);
> +       input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
> +
> +       input_sync(input);
> +
> +       return 0;
> +}
> +
>  void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  {
>        bool sync;
> @@ -900,6 +946,10 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>                sync = wacom_tpc_irq(wacom_wac, len);
>                break;
>
> +       case BAMBOO_TOUCH:
> +               sync = wacom_bbt_irq(wacom_wac, len);
> +               break;
> +
>        default:
>                sync = false;
>                break;
> @@ -1076,6 +1126,22 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>        case PENPARTNER:
>                __set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
>                break;
> +
> +       case BAMBOO_TOUCH:
> +               __clear_bit(ABS_MISC, input_dev->absbit);
> +               __set_bit(BTN_LEFT, input_dev->keybit);
> +               __set_bit(BTN_MIDDLE, input_dev->keybit);
> +               __set_bit(BTN_RIGHT, input_dev->keybit);
> +
> +               __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
> +               __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
> +
> +               input_mt_create_slots(input_dev, 2);
> +               input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, features->x_max, 4, 0);
> +               input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, features->y_max, 4, 0);
> +               input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, features->pressure_max, 16, 0);
> +               input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, MAX_TRACKING_ID, 0, 0);
> +               break;
>        }
>  }
>
> @@ -1213,11 +1279,19 @@ static const struct wacom_features wacom_features_0xE3 =
>        { "Wacom ISDv4 E3",       WACOM_PKGLEN_TPC2FG,    26202, 16325,  255,  0, TABLETPC2FG };
>  static const struct wacom_features wacom_features_0x47 =
>        { "Wacom Intuos2 6x8",    WACOM_PKGLEN_INTUOS,    20320, 16240, 1023, 31, INTUOS };
> +static const struct wacom_features wacom_features_0xD0_0 =
> +       { "Wacom Bamboo Touch",   WACOM_PKGLEN_BBTOUCH,   480,  320, 255, 0, BAMBOO_TOUCH };
> +static const struct wacom_features wacom_features_0xD0_2 =
> +       { "Wacom Bamboo Boot",   WACOM_PKGLEN_BBFUN,     480,  320, 255, 0, BAMBOO_BOOT };
>
>  #define USB_DEVICE_WACOM(prod)                                 \
>        USB_DEVICE(USB_VENDOR_ID_WACOM, prod),                  \
>        .driver_info = (kernel_ulong_t)&wacom_features_##prod
>
> +#define USB_DEVICE_WACOM_PROTO(prod, pr)                               \
> +       USB_DEVICE_INTERFACE_PROTOCOL(USB_VENDOR_ID_WACOM, prod, pr),   \
> +       .driver_info = (kernel_ulong_t)&wacom_features_##prod##_##pr
> +
>  const struct usb_device_id wacom_ids[] = {
>        { USB_DEVICE_WACOM(0x00) },
>        { USB_DEVICE_WACOM(0x10) },
> @@ -1277,6 +1351,8 @@ const struct usb_device_id wacom_ids[] = {
>        { USB_DEVICE_WACOM(0xC6) },
>        { USB_DEVICE_WACOM(0xC7) },
>        { USB_DEVICE_WACOM(0xCE) },
> +       { USB_DEVICE_WACOM_PROTO(0xD0, 0) },
> +       { USB_DEVICE_WACOM_PROTO(0xD0, 2) },
>        { USB_DEVICE_WACOM(0xF0) },
>        { USB_DEVICE_WACOM(0xCC) },
>        { USB_DEVICE_WACOM(0x90) },
> diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
> index 99e1a54..770909c 100644
> --- a/drivers/input/tablet/wacom_wac.h
> +++ b/drivers/input/tablet/wacom_wac.h
> @@ -21,6 +21,7 @@
>  #define WACOM_PKGLEN_INTUOS    10
>  #define WACOM_PKGLEN_TPC1FG     5
>  #define WACOM_PKGLEN_TPC2FG    14
> +#define WACOM_PKGLEN_BBTOUCH   20
>
>  /* device IDs */
>  #define STYLUS_DEVICE_ID       0x02
> @@ -37,6 +38,9 @@
>  #define WACOM_REPORT_TPC1FG            6
>  #define WACOM_REPORT_TPC2FG            13
>
> +/* largest reported tracking id */
> +#define MAX_TRACKING_ID                        0xfff
> +
>  enum {
>        PENPARTNER = 0,
>        GRAPHIRE,
> @@ -57,6 +61,8 @@ enum {
>        WACOM_MO,
>        TABLETPC,
>        TABLETPC2FG,
> +       BAMBOO_TOUCH,
> +       BAMBOO_BOOT,
>        MAX_TYPE
>  };
>
> --
> 1.7.1
>
> --
> 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
>
--
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

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Henrik Rydberg]

Hi Ping,
[...]
>> 1) It uses the MT slot protocol

>> 2) It creates two input devices, but only one is useful
> 
> I would like to keep the same wacom_features and usb_device_id
> wacom_ids structures for Bamboo as we did for all the other models,
> i.e., we define one entry for Bamboo although there could be more than
> one logical devices (touch and pen) associated with it.
> 
> This may not make a difference for your Bamboo (a touch only device).
> It would make the code easy to maintain for the other Bamboos (Product
> ID: 0xd1, 0xd2, 0xd3, and 0xd4).
> 
> If you are not sure what I am talking about, please let me know.


The problem I had with this is how that additional input device is presented in
userland. As long as the capabilities are set properly for each input device, I
have no problem using one catch-all match in the device id list.


>> 3) It works well with the synaptics and multitouch X drivers
> 
> I guess it depends on what the plan is for MT support in the userland.
> If our goal is to make the MT X driver generic, there would be no need
> to have a Wacom X drvier for MT (I'd love to go with this route). If
> the MT X driver is only a way to test the kernel driver, we'll have to
> discuss what to do next.


As you no doubt are aware, things are really moving regarding MT support in
Linux. The next Ubuntu release comes with gestures, and the Bamboo works in that
framework too. Real MT through X will become reality within the next six months.
I think it is safe to say that there is no need to add MT to the Wacom driver.

>> 4) It does not work well with the wacom X driver (!)
> 
> This would not be an issue if we (as a team working in the community)
> can answer item 3 above properly.
> 
>> In particular the last point may seem upsetting, but my reasoning is
>> simply that the wacom X driver really supports tablets and not
>> trackpads. I might be convinced otherwise. :-)
> 
> As I said earlier, I would love to see MT supported by a generic X driver.


Then so be it. :-)

Cheers,
Henrik

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Ping Cheng]

On Mon, Aug 23, 2010 at 7:30 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Ping,
> [...]
>>> 1) It uses the MT slot protocol
>
>>> 2) It creates two input devices, but only one is useful
>>
>> I would like to keep the same wacom_features and usb_device_id
>> wacom_ids structures for Bamboo as we did for all the other models,
>> i.e., we define one entry for Bamboo although there could be more than
>> one logical devices (touch and pen) associated with it.
>>
>> This may not make a difference for your Bamboo (a touch only device).
>> It would make the code easy to maintain for the other Bamboos (Product
>> ID: 0xd1, 0xd2, 0xd3, and 0xd4).
>>
>> If you are not sure what I am talking about, please let me know.
>
>
> The problem I had with this is how that additional input device is presented
> in  userland.

Pen and touch data are reported to the user space by different logical
ports. So, there is no confusion among the data between the ports. MT
X driver only needs to talk to the touch port.

> As long as the capabilities are set properly for each input device, I
> have no problem using one catch-all match in the device id list.

I think we are safe here. It has been working like this for sometime...

Ping

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Ping Cheng]

On Mon, Aug 23, 2010 at 7:30 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Ping,
> [...]
>>> 1) It uses the MT slot protocol
>
>>> 2) It creates two input devices, but only one is useful
>>
>> I would like to keep the same wacom_features and usb_device_id
>> wacom_ids structures for Bamboo as we did for all the other models,
>> i.e., we define one entry for Bamboo although there could be more than
>> one logical devices (touch and pen) associated with it.
>>
>> This may not make a difference for your Bamboo (a touch only device).
>> It would make the code easy to maintain for the other Bamboos (Product
>> ID: 0xd1, 0xd2, 0xd3, and 0xd4).
>>
>> If you are not sure what I am talking about, please let me know.
>
>
> The problem I had with this is how that additional input device is presented
> in  userland.

Pen and touch data are reported to the user space by different logical
ports. So, there is no confusion among the data between the ports. MT
X driver only needs to talk to the touch port.

> As long as the capabilities are set properly for each input device, I
> have no problem using one catch-all match in the device id list.

I think we are safe here. It has been working like this for sometime...

Ping

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Chris Bagwell]

Comments below.

On Sun, Aug 22, 2010 at 9:10 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Add support for the Bamboo Touch trackpad, and make it work well with
> both the Synaptics X Driver and the Multitouch X Driver. The device
> uses MT slots internally, so the choice of protocol is a given.
>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Dmitry, Ping,
>
> Here is a small patch which adds trackpad support for the Bamboo Touch. There are a couple if things to discuss:
>
> 1) It uses the MT slot protocol
> 2) It creates two input devices, but only one is useful

No biggy to userspace.  I'm assuming for unused input device that
hardware is still reporting a HID_USAGE_STYLUS and probably you could
catch that and not register that input device.

> 3) It works well with the synaptics and multitouch X drivers
> 4) It does not work well with the wacom X driver (!)

Once we finalize input events sent, I'm sure we could get
xf86-input-wacom to play nice with this synaptic-style input events.
The harder part is to develop userspace rules to assign this "wacom"
input device to something other than xf86-input-wacom; especially in
case were tablet has pen and touch input devices.

>
> In particular the last point may seem upsetting, but my reasoning is
> simply that the wacom X driver really supports tablets and not
> trackpads. I might be convinced otherwise. :-)
>
> Cheers,
> Henrik
>
>  drivers/input/tablet/wacom_wac.c |   76 ++++++++++++++++++++++++++++++++++++++
>  drivers/input/tablet/wacom_wac.h |    6 +++
>  2 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index 40d77ba..61dbd5d 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -855,6 +855,52 @@ static int wacom_tpc_irq(struct wacom_wac *wacom, size_t len)
>        return retval;
>  }
>
> +static int wacom_bbt_irq(struct wacom_wac *wacom, size_t len)

We need a generic name to represent this family of devices since this
code will eventually be extended for those as well.  You've chosen
BBTOUCH.  There are some devices in family that support pen-only as
well as pen&touch.

I'm personally fine with bbt/BBTOUCH/BAMBO_TOUCH but some may prefer
BBPT/BBPTOUCH/BAMBOO_PT to show super-set of features in family.

This is a generic comment that I'll not mention any more below.

> +{
> +       static int trkid;
> +       struct input_dev *input = wacom->input;
> +       unsigned char *data = wacom->data;
> +       int i, sp = 0, sx = 0, sy = 0, count = 0;
> +
> +       if (len != WACOM_PKGLEN_BBTOUCH)
> +               return 0;
> +
> +       for (i = 0; i < 2; i++) {
> +               int p = data[9 * i + 2];
> +               input_mt_slot(input, i);
> +               if (p) {
> +                       int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
> +                       int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
> +                       input_report_abs(input, ABS_MT_PRESSURE, p);
> +                       input_report_abs(input, ABS_MT_POSITION_X, x);
> +                       input_report_abs(input, ABS_MT_POSITION_Y, y);
> +                       if (wacom->id[i] < 0)
> +                               wacom->id[i] = trkid++ & MAX_TRACKING_ID;
> +                       if (!count++)
> +                               sp = p, sx = x, sy = y;
> +               } else {
> +                       wacom->id[i] = -1;
> +               }
> +               input_report_abs(input, ABS_MT_TRACKING_ID, wacom->id[i]);
> +       }
> +
> +       input_report_key(input, BTN_TOUCH, count > 0);
> +       input_report_key(input, BTN_TOOL_FINGER, count == 1);
> +       input_report_key(input, BTN_TOOL_DOUBLETAP, count == 2);
> +
> +       input_report_abs(input, ABS_PRESSURE, sp);
> +       input_report_abs(input, ABS_X, sx);
> +       input_report_abs(input, ABS_Y, sy);
> +
> +       input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);

This is hardest part were xf86-input-wacom will not want to play nice
(reporting button presses and touch events together).  Not a comment
against your code... Just pointing out the issue.  I'm up for helping
figure userland side out to allow for this.

> +       input_report_key(input, BTN_MIDDLE, (data[1] & 0x06) != 0);
> +       input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);

There are 4 buttons on your tablet, right?  Why did you map middle 2
buttons to  single BTN_MIDDLE?  Thats better for userspace I think.

If we wanted to be close to windows mappings then probably
BTN_RIGHT=0x1, BTN_LEFT=0x2, BTN_MIDDLE=0x4, BTN_4=0x8.... or
something like that.  The 2 button split layout makes it awkward for
user to guess what button order is though so not sure windows default
layout is required.

> +
> +       input_sync(input);
> +
> +       return 0;
> +}
> +
>  void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  {
>        bool sync;
> @@ -900,6 +946,10 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>                sync = wacom_tpc_irq(wacom_wac, len);
>                break;
>
> +       case BAMBOO_TOUCH:
> +               sync = wacom_bbt_irq(wacom_wac, len);
> +               break;
> +
>        default:
>                sync = false;
>                break;
> @@ -1076,6 +1126,22 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>        case PENPARTNER:
>                __set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
>                break;
> +
> +       case BAMBOO_TOUCH:
> +               __clear_bit(ABS_MISC, input_dev->absbit);
> +               __set_bit(BTN_LEFT, input_dev->keybit);
> +               __set_bit(BTN_MIDDLE, input_dev->keybit);
> +               __set_bit(BTN_RIGHT, input_dev->keybit);
> +
> +               __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
> +               __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
> +
> +               input_mt_create_slots(input_dev, 2);
> +               input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, features->x_max, 4, 0);
> +               input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, features->y_max, 4, 0);
> +               input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, features->pressure_max, 16, 0);
> +               input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, MAX_TRACKING_ID, 0, 0);
> +               break;
>        }
>  }
>
> @@ -1213,11 +1279,19 @@ static const struct wacom_features wacom_features_0xE3 =
>        { "Wacom ISDv4 E3",       WACOM_PKGLEN_TPC2FG,    26202, 16325,  255,  0, TABLETPC2FG };
>  static const struct wacom_features wacom_features_0x47 =
>        { "Wacom Intuos2 6x8",    WACOM_PKGLEN_INTUOS,    20320, 16240, 1023, 31, INTUOS };
> +static const struct wacom_features wacom_features_0xD0_0 =
> +       { "Wacom Bamboo Touch",   WACOM_PKGLEN_BBTOUCH,   480,  320, 255, 0, BAMBOO_TOUCH };
> +static const struct wacom_features wacom_features_0xD0_2 =
> +       { "Wacom Bamboo Boot",   WACOM_PKGLEN_BBFUN,     480,  320, 255, 0, BAMBOO_BOOT };

I'm curious why your breaking these out into 2 lines (not that its a
bad idea, I'm just curious)?  Other wacom devices with similar issue
would just define it a single time still.

Also, what does BOOT mean?  In Bamboo Pen&Touch device, this would be
the pen input.  So at minimum BAMBOO_PEN is more accurate name.

>
>  #define USB_DEVICE_WACOM(prod)                                 \
>        USB_DEVICE(USB_VENDOR_ID_WACOM, prod),                  \
>        .driver_info = (kernel_ulong_t)&wacom_features_##prod
>
> +#define USB_DEVICE_WACOM_PROTO(prod, pr)                               \
> +       USB_DEVICE_INTERFACE_PROTOCOL(USB_VENDOR_ID_WACOM, prod, pr),   \
> +       .driver_info = (kernel_ulong_t)&wacom_features_##prod##_##pr
> +
>  const struct usb_device_id wacom_ids[] = {
>        { USB_DEVICE_WACOM(0x00) },
>        { USB_DEVICE_WACOM(0x10) },
> @@ -1277,6 +1351,8 @@ const struct usb_device_id wacom_ids[] = {
>        { USB_DEVICE_WACOM(0xC6) },
>        { USB_DEVICE_WACOM(0xC7) },
>        { USB_DEVICE_WACOM(0xCE) },
> +       { USB_DEVICE_WACOM_PROTO(0xD0, 0) },
> +       { USB_DEVICE_WACOM_PROTO(0xD0, 2) },
>        { USB_DEVICE_WACOM(0xF0) },
>        { USB_DEVICE_WACOM(0xCC) },
>        { USB_DEVICE_WACOM(0x90) },
> diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
> index 99e1a54..770909c 100644
> --- a/drivers/input/tablet/wacom_wac.h
> +++ b/drivers/input/tablet/wacom_wac.h
> @@ -21,6 +21,7 @@
>  #define WACOM_PKGLEN_INTUOS    10
>  #define WACOM_PKGLEN_TPC1FG     5
>  #define WACOM_PKGLEN_TPC2FG    14
> +#define WACOM_PKGLEN_BBTOUCH   20
>
>  /* device IDs */
>  #define STYLUS_DEVICE_ID       0x02
> @@ -37,6 +38,9 @@
>  #define WACOM_REPORT_TPC1FG            6
>  #define WACOM_REPORT_TPC2FG            13
>
> +/* largest reported tracking id */
> +#define MAX_TRACKING_ID                        0xfff
> +
>  enum {
>        PENPARTNER = 0,
>        GRAPHIRE,
> @@ -57,6 +61,8 @@ enum {
>        WACOM_MO,
>        TABLETPC,
>        TABLETPC2FG,
> +       BAMBOO_TOUCH,
> +       BAMBOO_BOOT,
>        MAX_TYPE
>  };
>
> --
> 1.7.1
>
> --
> 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
>
--
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

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Henrik Rydberg]

Hi Chris,

>> 1) It uses the MT slot protocol
>> 2) It creates two input devices, but only one is useful
> 
> No biggy to userspace.  I'm assuming for unused input device that
> hardware is still reporting a HID_USAGE_STYLUS and probably you could
> catch that and not register that input device.


The initial idea was to only use the trackpad usb endnode, but the device does
not work at all after boot unless the silent endnode is somehow taken into
account. I am not sure what your statement refers to.

>> 3) It works well with the synaptics and multitouch X drivers
>> 4) It does not work well with the wacom X driver (!)
> 
> Once we finalize input events sent, I'm sure we could get
> xf86-input-wacom to play nice with this synaptic-style input events.
> The harder part is to develop userspace rules to assign this "wacom"
> input device to something other than xf86-input-wacom; especially in
> case were tablet has pen and touch input devices.


Using udev rules, the pen device is picked up by the wacom X driver and the
touch device is picked up by the synaptics X driver. It does not seem anything
extra is needed here.

[...]

> +static int wacom_bbt_irq(struct wacom_wac *wacom, size_t len)

> 
> We need a generic name to represent this family of devices since this
> code will eventually be extended for those as well.  You've chosen
> BBTOUCH.  There are some devices in family that support pen-only as
> well as pen&touch.

>
> I'm personally fine with bbt/BBTOUCH/BAMBO_TOUCH but some may prefer

> BBPT/BBPTOUCH/BAMBOO_PT to show super-set of features in family.
> 
> This is a generic comment that I'll not mention any more below.


All irq handlers seem pretty codified, anyways.


[...]

>> +

>> +       input_report_key(input, BTN_TOUCH, count > 0);
>> +       input_report_key(input, BTN_TOOL_FINGER, count == 1);
>> +       input_report_key(input, BTN_TOOL_DOUBLETAP, count == 2);
>> +
>> +       input_report_abs(input, ABS_PRESSURE, sp);
>> +       input_report_abs(input, ABS_X, sx);
>> +       input_report_abs(input, ABS_Y, sy);
>> +
>> +       input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
> 
> This is hardest part were xf86-input-wacom will not want to play nice
> (reporting button presses and touch events together).


I am not sure what you are referring to here. I know of no confusion between the
touch events and actually clicking a button.

[...]

>> +       input_report_key(input, BTN_MIDDLE, (data[1] & 0x06) != 0);
>> +       input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
> 
> There are 4 buttons on your tablet, right?  Why did you map middle 2
> buttons to  single BTN_MIDDLE?  Thats better for userspace I think.


Because of the similarity with a three-button mouse. Clicking the "I am a
leftie" option will also revert the buttons properly.

> If we wanted to be close to windows mappings then probably
> BTN_RIGHT=0x1, BTN_LEFT=0x2, BTN_MIDDLE=0x4, BTN_4=0x8.... or
> something like that.  The 2 button split layout makes it awkward for
> user to guess what button order is though so not sure windows default
> layout is required.


Right.

>> @@ -1213,11 +1279,19 @@ static const struct wacom_features wacom_features_0xE3 =
>>        { "Wacom ISDv4 E3",       WACOM_PKGLEN_TPC2FG,    26202, 16325,  255,  0, TABLETPC2FG };
>>  static const struct wacom_features wacom_features_0x47 =
>>        { "Wacom Intuos2 6x8",    WACOM_PKGLEN_INTUOS,    20320, 16240, 1023, 31, INTUOS };
>> +static const struct wacom_features wacom_features_0xD0_0 =
>> +       { "Wacom Bamboo Touch",   WACOM_PKGLEN_BBTOUCH,   480,  320, 255, 0, BAMBOO_TOUCH };
>> +static const struct wacom_features wacom_features_0xD0_2 =
>> +       { "Wacom Bamboo Boot",   WACOM_PKGLEN_BBFUN,     480,  320, 255, 0, BAMBOO_BOOT };
> 
> I'm curious why your breaking these out into 2 lines (not that its a
> bad idea, I'm just curious)?  Other wacom devices with similar issue
> would just define it a single time still.


In the hope that it would work to register only the active endnode, plus getting
a natural definition of every endnode of the usb device. Since Ping had issues
with this too, I will change it to the read-and-modify-later approach used in
the rest of the driver.

> Also, what does BOOT mean?  In Bamboo Pen&Touch device, this would be
> the pen input.  So at minimum BAMBOO_PEN is more accurate name.


For the Bamboo Touch, pen is not accurate. Boot comes from the HID specification
(boot interface, mouse protocol), but no name seems appropriate since the node
should not even be there.

Henrik

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Chris Bagwell]

Hi Henrik,

On Mon, Aug 30, 2010 at 4:10 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Chris,
>
>>> 1) It uses the MT slot protocol
>>> 2) It creates two input devices, but only one is useful
>>
>> No biggy to userspace.  I'm assuming for unused input device that
>> hardware is still reporting a HID_USAGE_STYLUS and probably you could
>> catch that and not register that input device.
>
>
> The initial idea was to only use the trackpad usb endnode, but the device does
> not work at all after boot unless the silent endnode is somehow taken into
> account. I am not sure what your statement refers to.
>
>>> 3) It works well with the synaptics and multitouch X drivers
>>> 4) It does not work well with the wacom X driver (!)
>>
>> Once we finalize input events sent, I'm sure we could get
>> xf86-input-wacom to play nice with this synaptic-style input events.
>> The harder part is to develop userspace rules to assign this "wacom"
>> input device to something other than xf86-input-wacom; especially in
>> case were tablet has pen and touch input devices.
>
>
> Using udev rules, the pen device is picked up by the wacom X driver and the
> touch device is picked up by the synaptics X driver. It does not seem anything
> extra is needed here.

You mean your wacom touch device are being directed to synaptics X
driver without modifications to udev or similar rules?  On my
unmodified Fedora box, they both go to wacom X driver.

Not that it would be a difficult modification... I'd just need to make
those and work with distributions to also align.

[...]

>
> [...]
>
>> +static int wacom_bbt_irq(struct wacom_wac *wacom, size_t len)
>
>>
>> We need a generic name to represent this family of devices since this
>> code will eventually be extended for those as well.  You've chosen
>> BBTOUCH.  There are some devices in family that support pen-only as
>> well as pen&touch.
>
>>
>> I'm personally fine with bbt/BBTOUCH/BAMBO_TOUCH but some may prefer
>
>> BBPT/BBPTOUCH/BAMBOO_PT to show super-set of features in family.
>>
>> This is a generic comment that I'll not mention any more below.
>
>
> All irq handlers seem pretty codified, anyways.
>
>
> [...]
>
>>> +
>
>>> +       input_report_key(input, BTN_TOUCH, count > 0);
>>> +       input_report_key(input, BTN_TOOL_FINGER, count == 1);
>>> +       input_report_key(input, BTN_TOOL_DOUBLETAP, count == 2);
>>> +
>>> +       input_report_abs(input, ABS_PRESSURE, sp);
>>> +       input_report_abs(input, ABS_X, sx);
>>> +       input_report_abs(input, ABS_Y, sy);
>>> +
>>> +       input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
>>
>> This is hardest part were xf86-input-wacom will not want to play nice
>> (reporting button presses and touch events together).
>
>
> I am not sure what you are referring to here. I know of no confusion between the
> touch events and actually clicking a button.

If you remap the bamboo touchpad device to xf86-input-wacom, the
reason it doesn't play nice is because it expects only 1 "tool" to be
sent per EV_SYN.

It considers the touchpad buttons as one tool and uses BTN_TOOL_FINGER
to indicate when one or more buttons are pressed.  It considers the
fingers and their X/Y/pressure/etc to be another tool and uses one of
BTN_TOUCH/BTN_TOOL_DOUBLETAP/BTN_TOOL_TRIPLETAP to indicate one or
more fingers pressed.

In your patch, button presses do not get separated out with a
BTN_TOOL_FINGER and EV_SYN.  Since the intent is for this touchpad
device to go to synaptics X driver, no real issue with your patch.
I'll work with wacom X driver side so that if a synaptics-like input
device gets mapped to it by a generic "*wacom*" pattern, it handles it
gracefully.

[...]

>
> [...]
>
>>> +       input_report_key(input, BTN_MIDDLE, (data[1] & 0x06) != 0);
>>> +       input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
>>
>> There are 4 buttons on your tablet, right?  Why did you map middle 2
>> buttons to  single BTN_MIDDLE?  Thats better for userspace I think.
>
>
> Because of the similarity with a three-button mouse. Clicking the "I am a
> leftie" option will also revert the buttons properly.

I constantly switch between left and right handed input devices so
understand well that would be nice.  But the loss of that 4th button
will be a problem for end users.  Wacom tablet people seem to love
their buttons and custom assignments (often mapped to keystrokes
rather than button presses).

Userspace can simulate same above behavior for subset of times when
its useful by remapping the 2nd middle button to same as 1st middle
button and then toggling liftie option will work well.

[...]

>
>> If we wanted to be close to windows mappings then probably
>> BTN_RIGHT=0x1, BTN_LEFT=0x2, BTN_MIDDLE=0x4, BTN_4=0x8.... or
>> something like that.  The 2 button split layout makes it awkward for
>> user to guess what button order is though so not sure windows default
>> layout is required.
>
>
> Right.
>
>>> @@ -1213,11 +1279,19 @@ static const struct wacom_features wacom_features_0xE3 =
>>>        { "Wacom ISDv4 E3",       WACOM_PKGLEN_TPC2FG,    26202, 16325,  255,  0, TABLETPC2FG };
>>>  static const struct wacom_features wacom_features_0x47 =
>>>        { "Wacom Intuos2 6x8",    WACOM_PKGLEN_INTUOS,    20320, 16240, 1023, 31, INTUOS };
>>> +static const struct wacom_features wacom_features_0xD0_0 =
>>> +       { "Wacom Bamboo Touch",   WACOM_PKGLEN_BBTOUCH,   480,  320, 255, 0, BAMBOO_TOUCH };
>>> +static const struct wacom_features wacom_features_0xD0_2 =
>>> +       { "Wacom Bamboo Boot",   WACOM_PKGLEN_BBFUN,     480,  320, 255, 0, BAMBOO_BOOT };
>>
>> I'm curious why your breaking these out into 2 lines (not that its a
>> bad idea, I'm just curious)?  Other wacom devices with similar issue
>> would just define it a single time still.
>
>
> In the hope that it would work to register only the active endnode, plus getting
> a natural definition of every endnode of the usb device. Since Ping had issues
> with this too, I will change it to the read-and-modify-later approach used in
> the rest of the driver.

There are some possible benefits to splitting it but hiding an endnode
is not one.

My comment about HID_USAGE_STYLUS can be better said like this:  I'd
assume in wacom_probe() you can add an "if (!BAMBOO_BOOT)" around the
call to input_register_device() to hide the unneeded input device to
user.   If you switch to read-and-modify approach then
HID_USAGE_STYLUS maps to modify trigger and how to detect the useless
input device for Bamboo Touch's.

>
>> Also, what does BOOT mean?  In Bamboo Pen&Touch device, this would be
>> the pen input.  So at minimum BAMBOO_PEN is more accurate name.
>
>
> For the Bamboo Touch, pen is not accurate. Boot comes from the HID specification
> (boot interface, mouse protocol), but no name seems appropriate since the node
> should not even be there.

Ah, OK.  I understand BOOT now.

There are 3 main tablets in this family and your code should
eventually be extended to include all three.  1) Touch-only, 2) Pen
and Touch, 3) Pen-only.

It seems wacom uses same USB controller in all cases but in #1 and #3
just do not report data for unused feature.  So BAMBOO_TOUCH is
meaningless in #3 case but name has good meaning for #1 and #2.
Similar, I think BAMBOO_PEN is good for #2 and #3 even though for #1
its meaningless.

But BAMBOO_BOOT is also fine in place of BAMBOO_PEN as long as we
comment that we are talking USB terms and not hardware features.

Chris

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

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Peter Hutterer]

On Mon, Aug 30, 2010 at 11:19:49AM -0500, Chris Bagwell wrote:
> Hi Henrik,
> 
> On Mon, Aug 30, 2010 at 4:10 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> > Hi Chris,
> >
> >>> 1) It uses the MT slot protocol
> >>> 2) It creates two input devices, but only one is useful
> >>
> >> No biggy to userspace.  I'm assuming for unused input device that
> >> hardware is still reporting a HID_USAGE_STYLUS and probably you could
> >> catch that and not register that input device.
> >
> >
> > The initial idea was to only use the trackpad usb endnode, but the device does
> > not work at all after boot unless the silent endnode is somehow taken into
> > account. I am not sure what your statement refers to.
> >
> >>> 3) It works well with the synaptics and multitouch X drivers
> >>> 4) It does not work well with the wacom X driver (!)
> >>
> >> Once we finalize input events sent, I'm sure we could get
> >> xf86-input-wacom to play nice with this synaptic-style input events.
> >> The harder part is to develop userspace rules to assign this "wacom"
> >> input device to something other than xf86-input-wacom; especially in
> >> case were tablet has pen and touch input devices.
> >
> >
> > Using udev rules, the pen device is picked up by the wacom X driver and the
> > touch device is picked up by the synaptics X driver. It does not seem anything
> > extra is needed here.
> 
> You mean your wacom touch device are being directed to synaptics X
> driver without modifications to udev or similar rules?  On my
> unmodified Fedora box, they both go to wacom X driver.
> 
> Not that it would be a difficult modification... I'd just need to make
> those and work with distributions to also align.

50-wacom.conf sorts after 50-synaptics.conf and since we apply the wacom
driver to anything with Wacom in the product name, it overrides the
synaptics setting. not a big deal at all, just renaming it to 40-wacom.conf
should already do the job.

Cheers,
  Peter
--
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

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Chris Bagwell]

On Tue, Aug 31, 2010 at 12:44 AM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
> On Mon, Aug 30, 2010 at 11:19:49AM -0500, Chris Bagwell wrote:
>> Hi Henrik,
>>
>> On Mon, Aug 30, 2010 at 4:10 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> > Hi Chris,
>> >
>> >>> 1) It uses the MT slot protocol
>> >>> 2) It creates two input devices, but only one is useful
>> >>
>> >> No biggy to userspace.  I'm assuming for unused input device that
>> >> hardware is still reporting a HID_USAGE_STYLUS and probably you could
>> >> catch that and not register that input device.
>> >
>> >
>> > The initial idea was to only use the trackpad usb endnode, but the device does
>> > not work at all after boot unless the silent endnode is somehow taken into
>> > account. I am not sure what your statement refers to.
>> >
>> >>> 3) It works well with the synaptics and multitouch X drivers
>> >>> 4) It does not work well with the wacom X driver (!)
>> >>
>> >> Once we finalize input events sent, I'm sure we could get
>> >> xf86-input-wacom to play nice with this synaptic-style input events.
>> >> The harder part is to develop userspace rules to assign this "wacom"
>> >> input device to something other than xf86-input-wacom; especially in
>> >> case were tablet has pen and touch input devices.
>> >
>> >
>> > Using udev rules, the pen device is picked up by the wacom X driver and the
>> > touch device is picked up by the synaptics X driver. It does not seem anything
>> > extra is needed here.
>>
>> You mean your wacom touch device are being directed to synaptics X
>> driver without modifications to udev or similar rules?  On my
>> unmodified Fedora box, they both go to wacom X driver.
>>
>> Not that it would be a difficult modification... I'd just need to make
>> those and work with distributions to also align.
>
> 50-wacom.conf sorts after 50-synaptics.conf and since we apply the wacom
> driver to anything with Wacom in the product name, it overrides the
> synaptics setting. not a big deal at all, just renaming it to 40-wacom.conf
> should already do the job.
>
> Cheers,
>  Peter
>

Thanks for tip.  I verified its that easy.  I renamed to 40-wacom.conf
and on my Bamboo Pen&Touch, the tablet part is grabbed by
xf86-input-wacom and the touchpad part is grabbed by
xf86-input-synaptics.

Note I have the linuxwacom (out-of-tree) driver installed which makes
my Bamboo talk like the in-tree wacom Tablet PC logic.  And in this
case, I get no responses from the Bamboo touchpad and
xf86-input-synaptics combo.

I mention this because udev is reporting Tablet PC as a touchpad.  So
if we change to allow remapping Bamboo's to xf86-input-synaptics then
we either need to update Tablet PC logic to be synaptics-like in
kernel or we need an exception to allow older Tablet PC to continue to
be handled by xf86-input-wacom.

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

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Ping Cheng]

On Monday, August 30, 2010, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Chris,
>
>>> 1) It uses the MT slot protocol
>>> 2) It creates two input devices, but only one is useful
>>
>> No biggy to userspace.  I'm assuming for unused input device that
>> hardware is still reporting a HID_USAGE_STYLUS and probably you could
>> catch that and not register that input device.
>
>
> The initial idea was to only use the trackpad usb endnode, but the device does
> not work at all after boot unless the silent endnode is somehow taken into
> account. I am not sure what your statement refers to.
>
>>> 3) It works well with the synaptics and multitouch X drivers
>>> 4) It does not work well with the wacom X driver (!)
>>
>> Once we finalize input events sent, I'm sure we could get
>> xf86-input-wacom to play nice with this synaptic-style input events.
>> The harder part is to develop userspace rules to assign this "wacom"
>> input device to something other than xf86-input-wacom; especially in
>> case were tablet has pen and touch input devices.
>
>
> Using udev rules, the pen device is picked up by the wacom X driver and the
> touch device is picked up by the synaptics X driver. It does not seem anything
> extra is needed here.
>
> [...]
>
>> +static int wacom_bbt_irq(struct wacom_wac *wacom, size_t len)
>
>>
>> We need a generic name to represent this family of devices since this
>> code will eventually be extended for those as well.  You've chosen
>> BBTOUCH.  There are some devices in family that support pen-only as
>> well as pen&touch.
>
>>
>> I'm personally fine with bbt/BBTOUCH/BAMBO_TOUCH but some may prefer
>
>> BBPT/BBPTOUCH/BAMBOO_PT to show super-set of features in family.
>>
>> This is a generic comment that I'll not mention any more below.
>
>
> All irq handlers seem pretty codified, anyways.
>
>
> [...]
>
>>> +
>
>>> +       input_report_key(input, BTN_TOUCH, count > 0);
>>> +       input_report_key(input, BTN_TOOL_FINGER, count == 1);
>>> +       input_report_key(input, BTN_TOOL_DOUBLETAP, count == 2);
>>> +
>>> +       input_report_abs(input, ABS_PRESSURE, sp);
>>> +       input_report_abs(input, ABS_X, sx);
>>> +       input_report_abs(input, ABS_Y, sy);
>>> +
>>> +       input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
>>
>> This is hardest part were xf86-input-wacom will not want to play nice
>> (reporting button presses and touch events together).
>
>
> I am not sure what you are referring to here. I know of no confusion between the
> touch events and actually clicking a button.
>
> [...]
>
>>> +       input_report_key(input, BTN_MIDDLE, (data[1] & 0x06) != 0);
>>> +       input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
>>
>> There are 4 buttons on your tablet, right?  Why did you map middle 2
>> buttons to  single BTN_MIDDLE?  Thats better for userspace I think.
>
>
> Because of the similarity with a three-button mouse. Clicking the "I am a
> leftie" option will also revert the buttons properly.
>
>> If we wanted to be close to windows mappings then probably
>> BTN_RIGHT=0x1, BTN_LEFT=0x2, BTN_MIDDLE=0x4, BTN_4=0x8.... or
>> something like that.  The 2 button split layout makes it awkward for
>> user to guess what button order is though so not sure windows default
>> layout is required.
>
>
> Right.
>
>>> @@ -1213,11 +1279,19 @@ static const struct wacom_features wacom_features_0xE3 =
>>>        { "Wacom ISDv4 E3",       WACOM_PKGLEN_TPC2FG,    26202, 16325,  255,  0, TABLETPC2FG };
>>>  static const struct wacom_features wacom_features_0x47 =
>>>        { "Wacom Intuos2 6x8",    WACOM_PKGLEN_INTUOS,    20320, 16240, 1023, 31, INTUOS };
>>> +static const struct wacom_features wacom_features_0xD0_0 =
>>> +       { "Wacom Bamboo Touch",   WACOM_PKGLEN_BBTOUCH,   480,  320, 255, 0, BAMBOO_TOUCH };
>>> +static const struct wacom_features wacom_features_0xD0_2 =
>>> +       { "Wacom Bamboo Boot",   WACOM_PKGLEN_BBFUN,     480,  320, 255, 0, BAMBOO_BOOT };
>>
>> I'm curious why your breaking these out into 2 lines (not that its a
>> bad idea, I'm just curious)?  Other wacom devices with similar issue
>> would just define it a single time still.
>
>
> In the hope that it would work to register only the active endnode, plus getting
> a natural definition of every endnode of the usb device.

We always get two logical ports for the pen and touch devices, which
are created by udev (or something in the kernel that I am not so
sure). The Wacom driver can not do much about it. I guess the firmware
of your touch-only Bamboo added the pen interface to the protocol.
That's why you see two ports (I can not access the device to test my
idea before next month).

> Since Ping had issues
> with this too, I will change it to the read-and-modify-later approach used in
> the rest of the driver.

Thank you for your consideration. Please use the existing approach so
we can maintain an unified interface. There should not be too much
confusion with the existing approach since pen and touch will not be
on the same logical port anyway.

>> Also, what does BOOT mean?  In Bamboo Pen&Touch device, this would be
>> the pen input.  So at minimum BAMBOO_PEN is more accurate name.
>
>
> For the Bamboo Touch, pen is not accurate. Boot comes from the HID specification
> (boot interface, mouse protocol), but no name seems appropriate since the node
> should not even be there.

Right now, we just tell users to ignore pen or touch if their device
does not support pen or touch (running an X server older than 1.4). In
the X Wacom driver for servers newer than 1.4, we check the valid
tools supported by the device before adding them. End users should not
need to worry about those details, at least in theory.

Maybe we can add this "tool type check method" into the evdev and/or
synaptics X driver as well?

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

Re: [PATCH] input: Add support for the Bamboo Touch trackpad

[Henrik Rydberg]

On 09/01/2010 12:48 PM, Ping Cheng wrote:

[...]

>> In the hope that it would work to register only the active endnode,
>> plus getting a natural definition of every endnode of the usb device.

> 
> We always get two logical ports for the pen and touch devices, which
> are created by udev (or something in the kernel that I am not so
> sure). The Wacom driver can not do much about it. I guess the firmware
> of your touch-only Bamboo added the pen interface to the protocol.
> That's why you see two ports (I can not access the device to test my
> idea before next month).


It should be fine, the extra device will only have mouse capabilities and will
not be used for anything.

>> Since Ping had issues
>> with this too, I will change it to the read-and-modify-later approach used in
>> the rest of the driver.
> 
> Thank you for your consideration. Please use the existing approach so
> we can maintain an unified interface. There should not be too much
> confusion with the existing approach since pen and touch will not be
> on the same logical port anyway.


Will send out a new version shortly.

>>> Also, what does BOOT mean?  In Bamboo Pen&Touch device, this would be
>>> the pen input.  So at minimum BAMBOO_PEN is more accurate name.
>>
>>
>> For the Bamboo Touch, pen is not accurate. Boot comes from the HID specification
>> (boot interface, mouse protocol), but no name seems appropriate since the node
>> should not even be there.
> 
> Right now, we just tell users to ignore pen or touch if their device
> does not support pen or touch (running an X server older than 1.4). In
> the X Wacom driver for servers newer than 1.4, we check the valid
> tools supported by the device before adding them. End users should not
> need to worry about those details, at least in theory.
> 
> Maybe we can add this "tool type check method" into the evdev and/or
> synaptics X driver as well?


Given the current and coming fixes to udev, I think we will be able to sort it
out well on that level, although it would not hurt if the X drivers were a bit
more selective during preinit.

Cheers,
Henrik