digimend-devel Mailing List for DIGImend (Page 11)
Brought to you by:
spb_nick
Menu
▾
▴
digimend-devel — Development matters
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(27) |
Jul
(54) |
Aug
(54) |
Sep
(13) |
Oct
(20) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(3) |
Feb
(3) |
Mar
(6) |
Apr
(1) |
May
(8) |
Jun
(5) |
Jul
(4) |
Aug
(10) |
Sep
(44) |
Oct
(12) |
Nov
(5) |
Dec
(14) |
| 2014 |
Jan
(16) |
Feb
(3) |
Mar
(3) |
Apr
(5) |
May
(2) |
Jun
(14) |
Jul
(38) |
Aug
(15) |
Sep
(15) |
Oct
(12) |
Nov
(38) |
Dec
(31) |
| 2015 |
Jan
(73) |
Feb
(71) |
Mar
(57) |
Apr
(36) |
May
(33) |
Jun
(20) |
Jul
(4) |
Aug
(5) |
Sep
(1) |
Oct
(11) |
Nov
(2) |
Dec
(6) |
| 2016 |
Jan
(7) |
Feb
(3) |
Mar
(6) |
Apr
(2) |
May
(7) |
Jun
(5) |
Jul
(3) |
Aug
(5) |
Sep
(5) |
Oct
(8) |
Nov
(13) |
Dec
|
|
From: Benjamin T. <ben...@re...> - 2015-02-25 00:05:45
|
From: Nikolai Kondrashov <Nik...@re...>
Merge the hid-huion driver into hid-uclogic as all the devices supported
by hid-huion are in fact UC-Logic devices.
Signed-off-by: Benjamin Tissoires <ben...@re...>
---
Changed from the original patch:
- update Makefile, Kconfig accordingly
- remove one extra pr_err when kzalloc failed (raised by checkpatch.pl)
drivers/hid/Kconfig | 8 +-
drivers/hid/Makefile | 1 -
drivers/hid/hid-huion.c | 290 ----------------------------------------------
drivers/hid/hid-uclogic.c | 229 +++++++++++++++++++++++++++++++++++-
4 files changed, 229 insertions(+), 299 deletions(-)
delete mode 100644 drivers/hid/hid-huion.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 152b006..8a55fd7 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -286,12 +286,6 @@ config HID_GT683R
Currently the following devices are know to be supported:
- MSI GT683R
-config HID_HUION
- tristate "Huion tablets"
- depends on USB_HID
- ---help---
- Support for Huion 580 tablet.
-
config HID_KEYTOUCH
tristate "Keytouch HID devices"
depends on HID
@@ -314,7 +308,7 @@ config HID_UCLOGIC
tristate "UC-Logic"
depends on HID
---help---
- Support for UC-Logic tablets.
+ Support for UC-Logic and Huion tablets.
config HID_WALTOP
tristate "Waltop"
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 6f19958..9c399fe 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -41,7 +41,6 @@ obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtekff.o
-obj-$(CONFIG_HID_HUION) += hid-huion.o
obj-$(CONFIG_HID_HYPERV_MOUSE) += hid-hyperv.o
obj-$(CONFIG_HID_ICADE) += hid-icade.o
obj-$(CONFIG_HID_KENSINGTON) += hid-kensington.o
diff --git a/drivers/hid/hid-huion.c b/drivers/hid/hid-huion.c
deleted file mode 100644
index 61b68ca..0000000
--- a/drivers/hid/hid-huion.c
+++ /dev/null
@@ -1,290 +0,0 @@
-/*
- * HID driver for Huion devices not fully compliant with HID standard
- *
- * Copyright (c) 2013 Martin Rusko
- * Copyright (c) 2014 Nikolai Kondrashov
- */
-
-/*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option)
- * any later version.
- */
-
-#include <linux/device.h>
-#include <linux/hid.h>
-#include <linux/module.h>
-#include <linux/usb.h>
-#include <asm/unaligned.h>
-#include "usbhid/usbhid.h"
-
-#include "hid-ids.h"
-
-/* Report descriptor template placeholder head */
-#define HUION_PH_HEAD 0xFE, 0xED, 0x1D
-
-/* Report descriptor template placeholder IDs */
-enum huion_ph_id {
- HUION_PH_ID_X_LM,
- HUION_PH_ID_X_PM,
- HUION_PH_ID_Y_LM,
- HUION_PH_ID_Y_PM,
- HUION_PH_ID_PRESSURE_LM,
- HUION_PH_ID_NUM
-};
-
-/* Report descriptor template placeholder */
-#define HUION_PH(_ID) HUION_PH_HEAD, HUION_PH_ID_##_ID
-
-/* Fixed report descriptor template */
-static const __u8 huion_tablet_rdesc_template[] = {
- 0x05, 0x0D, /* Usage Page (Digitizer), */
- 0x09, 0x02, /* Usage (Pen), */
- 0xA1, 0x01, /* Collection (Application), */
- 0x85, 0x07, /* Report ID (7), */
- 0x09, 0x20, /* Usage (Stylus), */
- 0xA0, /* Collection (Physical), */
- 0x14, /* Logical Minimum (0), */
- 0x25, 0x01, /* Logical Maximum (1), */
- 0x75, 0x01, /* Report Size (1), */
- 0x09, 0x42, /* Usage (Tip Switch), */
- 0x09, 0x44, /* Usage (Barrel Switch), */
- 0x09, 0x46, /* Usage (Tablet Pick), */
- 0x95, 0x03, /* Report Count (3), */
- 0x81, 0x02, /* Input (Variable), */
- 0x95, 0x03, /* Report Count (3), */
- 0x81, 0x03, /* Input (Constant, Variable), */
- 0x09, 0x32, /* Usage (In Range), */
- 0x95, 0x01, /* Report Count (1), */
- 0x81, 0x02, /* Input (Variable), */
- 0x95, 0x01, /* Report Count (1), */
- 0x81, 0x03, /* Input (Constant, Variable), */
- 0x75, 0x10, /* Report Size (16), */
- 0x95, 0x01, /* Report Count (1), */
- 0xA4, /* Push, */
- 0x05, 0x01, /* Usage Page (Desktop), */
- 0x65, 0x13, /* Unit (Inch), */
- 0x55, 0xFD, /* Unit Exponent (-3), */
- 0x34, /* Physical Minimum (0), */
- 0x09, 0x30, /* Usage (X), */
- 0x27, HUION_PH(X_LM), /* Logical Maximum (PLACEHOLDER), */
- 0x47, HUION_PH(X_PM), /* Physical Maximum (PLACEHOLDER), */
- 0x81, 0x02, /* Input (Variable), */
- 0x09, 0x31, /* Usage (Y), */
- 0x27, HUION_PH(Y_LM), /* Logical Maximum (PLACEHOLDER), */
- 0x47, HUION_PH(Y_PM), /* Physical Maximum (PLACEHOLDER), */
- 0x81, 0x02, /* Input (Variable), */
- 0xB4, /* Pop, */
- 0x09, 0x30, /* Usage (Tip Pressure), */
- 0x27,
- HUION_PH(PRESSURE_LM), /* Logical Maximum (PLACEHOLDER), */
- 0x81, 0x02, /* Input (Variable), */
- 0xC0, /* End Collection, */
- 0xC0 /* End Collection */
-};
-
-/* Parameter indices */
-enum huion_prm {
- HUION_PRM_X_LM = 1,
- HUION_PRM_Y_LM = 2,
- HUION_PRM_PRESSURE_LM = 4,
- HUION_PRM_RESOLUTION = 5,
- HUION_PRM_NUM
-};
-
-/* Driver data */
-struct huion_drvdata {
- __u8 *rdesc;
- unsigned int rsize;
-};
-
-static __u8 *huion_report_fixup(struct hid_device *hdev, __u8 *rdesc,
- unsigned int *rsize)
-{
- struct huion_drvdata *drvdata = hid_get_drvdata(hdev);
- switch (hdev->product) {
- case USB_DEVICE_ID_HUION_TABLET:
- if (drvdata->rdesc != NULL) {
- rdesc = drvdata->rdesc;
- *rsize = drvdata->rsize;
- }
- break;
- }
- return rdesc;
-}
-
-/**
- * Enable fully-functional tablet mode and determine device parameters.
- *
- * @hdev: HID device
- */
-static int huion_tablet_enable(struct hid_device *hdev)
-{
- int rc;
- struct usb_device *usb_dev = hid_to_usb_dev(hdev);
- struct huion_drvdata *drvdata = hid_get_drvdata(hdev);
- __le16 *buf = NULL;
- size_t len;
- s32 params[HUION_PH_ID_NUM];
- s32 resolution;
- __u8 *p;
- s32 v;
-
- /*
- * Read string descriptor containing tablet parameters. The specific
- * string descriptor and data were discovered by sniffing the Windows
- * driver traffic.
- * NOTE: This enables fully-functional tablet mode.
- */
- len = HUION_PRM_NUM * sizeof(*buf);
- buf = kmalloc(len, GFP_KERNEL);
- if (buf == NULL) {
- hid_err(hdev, "failed to allocate parameter buffer\n");
- rc = -ENOMEM;
- goto cleanup;
- }
- rc = usb_control_msg(usb_dev, usb_rcvctrlpipe(usb_dev, 0),
- USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
- (USB_DT_STRING << 8) + 0x64,
- 0x0409, buf, len,
- USB_CTRL_GET_TIMEOUT);
- if (rc == -EPIPE) {
- hid_err(hdev, "device parameters not found\n");
- rc = -ENODEV;
- goto cleanup;
- } else if (rc < 0) {
- hid_err(hdev, "failed to get device parameters: %d\n", rc);
- rc = -ENODEV;
- goto cleanup;
- } else if (rc != len) {
- hid_err(hdev, "invalid device parameters\n");
- rc = -ENODEV;
- goto cleanup;
- }
-
- /* Extract device parameters */
- params[HUION_PH_ID_X_LM] = le16_to_cpu(buf[HUION_PRM_X_LM]);
- params[HUION_PH_ID_Y_LM] = le16_to_cpu(buf[HUION_PRM_Y_LM]);
- params[HUION_PH_ID_PRESSURE_LM] =
- le16_to_cpu(buf[HUION_PRM_PRESSURE_LM]);
- resolution = le16_to_cpu(buf[HUION_PRM_RESOLUTION]);
- if (resolution == 0) {
- params[HUION_PH_ID_X_PM] = 0;
- params[HUION_PH_ID_Y_PM] = 0;
- } else {
- params[HUION_PH_ID_X_PM] = params[HUION_PH_ID_X_LM] *
- 1000 / resolution;
- params[HUION_PH_ID_Y_PM] = params[HUION_PH_ID_Y_LM] *
- 1000 / resolution;
- }
-
- /* Allocate fixed report descriptor */
- drvdata->rdesc = devm_kmalloc(&hdev->dev,
- sizeof(huion_tablet_rdesc_template),
- GFP_KERNEL);
- if (drvdata->rdesc == NULL) {
- hid_err(hdev, "failed to allocate fixed rdesc\n");
- rc = -ENOMEM;
- goto cleanup;
- }
- drvdata->rsize = sizeof(huion_tablet_rdesc_template);
-
- /* Format fixed report descriptor */
- memcpy(drvdata->rdesc, huion_tablet_rdesc_template,
- drvdata->rsize);
- for (p = drvdata->rdesc;
- p <= drvdata->rdesc + drvdata->rsize - 4;) {
- if (p[0] == 0xFE && p[1] == 0xED && p[2] == 0x1D &&
- p[3] < sizeof(params)) {
- v = params[p[3]];
- put_unaligned(cpu_to_le32(v), (s32 *)p);
- p += 4;
- } else {
- p++;
- }
- }
-
- rc = 0;
-
-cleanup:
- kfree(buf);
- return rc;
-}
-
-static int huion_probe(struct hid_device *hdev, const struct hid_device_id *id)
-{
- int rc;
- struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
- struct huion_drvdata *drvdata;
-
- /* Allocate and assign driver data */
- drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
- if (drvdata == NULL) {
- hid_err(hdev, "failed to allocate driver data\n");
- return -ENOMEM;
- }
- hid_set_drvdata(hdev, drvdata);
-
- switch (id->product) {
- case USB_DEVICE_ID_HUION_TABLET:
- /* If this is the pen interface */
- if (intf->cur_altsetting->desc.bInterfaceNumber == 0) {
- rc = huion_tablet_enable(hdev);
- if (rc) {
- hid_err(hdev, "tablet enabling failed\n");
- return rc;
- }
- }
- break;
- }
-
- rc = hid_parse(hdev);
- if (rc) {
- hid_err(hdev, "parse failed\n");
- return rc;
- }
-
- rc = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
- if (rc) {
- hid_err(hdev, "hw start failed\n");
- return rc;
- }
-
- return 0;
-}
-
-static int huion_raw_event(struct hid_device *hdev, struct hid_report *report,
- u8 *data, int size)
-{
- struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
-
- /* If this is a pen input report */
- if (intf->cur_altsetting->desc.bInterfaceNumber == 0 &&
- report->type == HID_INPUT_REPORT &&
- report->id == 0x07 && size >= 2)
- /* Invert the in-range bit */
- data[1] ^= 0x40;
-
- return 0;
-}
-
-static const struct hid_device_id huion_devices[] = {
- { HID_USB_DEVICE(USB_VENDOR_ID_HUION, USB_DEVICE_ID_HUION_TABLET) },
- { HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_HUION_TABLET) },
- { }
-};
-MODULE_DEVICE_TABLE(hid, huion_devices);
-
-static struct hid_driver huion_driver = {
- .name = "huion",
- .id_table = huion_devices,
- .probe = huion_probe,
- .report_fixup = huion_report_fixup,
- .raw_event = huion_raw_event,
-};
-module_hid_driver(huion_driver);
-
-MODULE_AUTHOR("Martin Rusko");
-MODULE_DESCRIPTION("Huion HID driver");
-MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-uclogic.c b/drivers/hid/hid-uclogic.c
index 22dccce..397f1df 100644
--- a/drivers/hid/hid-uclogic.c
+++ b/drivers/hid/hid-uclogic.c
@@ -1,7 +1,8 @@
/*
* HID driver for UC-Logic devices not fully compliant with HID standard
*
- * Copyright (c) 2010 Nikolai Kondrashov
+ * Copyright (c) 2010-2014 Nikolai Kondrashov
+ * Copyright (c) 2013 Martin Rusko
*/
/*
@@ -15,6 +16,8 @@
#include <linux/hid.h>
#include <linux/module.h>
#include <linux/usb.h>
+#include <asm/unaligned.h>
+#include "usbhid/usbhid.h"
#include "hid-ids.h"
@@ -546,11 +549,90 @@ static __u8 twha60_rdesc_fixed1[] = {
0xC0 /* End Collection */
};
+/* Report descriptor template placeholder head */
+#define UCLOGIC_PH_HEAD 0xFE, 0xED, 0x1D
+
+/* Report descriptor template placeholder IDs */
+enum uclogic_ph_id {
+ UCLOGIC_PH_ID_X_LM,
+ UCLOGIC_PH_ID_X_PM,
+ UCLOGIC_PH_ID_Y_LM,
+ UCLOGIC_PH_ID_Y_PM,
+ UCLOGIC_PH_ID_PRESSURE_LM,
+ UCLOGIC_PH_ID_NUM
+};
+
+/* Report descriptor template placeholder */
+#define UCLOGIC_PH(_ID) UCLOGIC_PH_HEAD, UCLOGIC_PH_ID_##_ID
+
+/* Fixed report descriptor template */
+static const __u8 uclogic_tablet_rdesc_template[] = {
+ 0x05, 0x0D, /* Usage Page (Digitizer), */
+ 0x09, 0x02, /* Usage (Pen), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0x07, /* Report ID (7), */
+ 0x09, 0x20, /* Usage (Stylus), */
+ 0xA0, /* Collection (Physical), */
+ 0x14, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x75, 0x01, /* Report Size (1), */
+ 0x09, 0x42, /* Usage (Tip Switch), */
+ 0x09, 0x44, /* Usage (Barrel Switch), */
+ 0x09, 0x46, /* Usage (Tablet Pick), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x03, /* Input (Constant, Variable), */
+ 0x09, 0x32, /* Usage (In Range), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x81, 0x03, /* Input (Constant, Variable), */
+ 0x75, 0x10, /* Report Size (16), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xA4, /* Push, */
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x65, 0x13, /* Unit (Inch), */
+ 0x55, 0xFD, /* Unit Exponent (-3), */
+ 0x34, /* Physical Minimum (0), */
+ 0x09, 0x30, /* Usage (X), */
+ 0x27, UCLOGIC_PH(X_LM), /* Logical Maximum (PLACEHOLDER), */
+ 0x47, UCLOGIC_PH(X_PM), /* Physical Maximum (PLACEHOLDER), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x09, 0x31, /* Usage (Y), */
+ 0x27, UCLOGIC_PH(Y_LM), /* Logical Maximum (PLACEHOLDER), */
+ 0x47, UCLOGIC_PH(Y_PM), /* Physical Maximum (PLACEHOLDER), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0xB4, /* Pop, */
+ 0x09, 0x30, /* Usage (Tip Pressure), */
+ 0x27,
+ UCLOGIC_PH(PRESSURE_LM),/* Logical Maximum (PLACEHOLDER), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0xC0, /* End Collection, */
+ 0xC0 /* End Collection */
+};
+
+/* Parameter indices */
+enum uclogic_prm {
+ UCLOGIC_PRM_X_LM = 1,
+ UCLOGIC_PRM_Y_LM = 2,
+ UCLOGIC_PRM_PRESSURE_LM = 4,
+ UCLOGIC_PRM_RESOLUTION = 5,
+ UCLOGIC_PRM_NUM
+};
+
+/* Driver data */
+struct uclogic_drvdata {
+ __u8 *rdesc;
+ unsigned int rsize;
+};
+
static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
struct usb_interface *iface = to_usb_interface(hdev->dev.parent);
__u8 iface_num = iface->cur_altsetting->desc.bInterfaceNumber;
+ struct uclogic_drvdata *drvdata = hid_get_drvdata(hdev);
switch (hdev->product) {
case USB_DEVICE_ID_UCLOGIC_TABLET_PF1209:
@@ -621,15 +703,120 @@ static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc,
break;
}
break;
+ default:
+ if (drvdata->rdesc != NULL) {
+ rdesc = drvdata->rdesc;
+ *rsize = drvdata->rsize;
+ }
}
return rdesc;
}
+/**
+ * Enable fully-functional tablet mode and determine device parameters.
+ *
+ * @hdev: HID device
+ */
+static int uclogic_tablet_enable(struct hid_device *hdev)
+{
+ int rc;
+ struct usb_device *usb_dev = hid_to_usb_dev(hdev);
+ struct uclogic_drvdata *drvdata = hid_get_drvdata(hdev);
+ __le16 *buf = NULL;
+ size_t len;
+ s32 params[UCLOGIC_PH_ID_NUM];
+ s32 resolution;
+ __u8 *p;
+ s32 v;
+
+ /*
+ * Read string descriptor containing tablet parameters. The specific
+ * string descriptor and data were discovered by sniffing the Windows
+ * driver traffic.
+ * NOTE: This enables fully-functional tablet mode.
+ */
+ len = UCLOGIC_PRM_NUM * sizeof(*buf);
+ buf = kmalloc(len, GFP_KERNEL);
+ if (buf == NULL) {
+ hid_err(hdev, "failed to allocate parameter buffer\n");
+ rc = -ENOMEM;
+ goto cleanup;
+ }
+ rc = usb_control_msg(usb_dev, usb_rcvctrlpipe(usb_dev, 0),
+ USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
+ (USB_DT_STRING << 8) + 0x64,
+ 0x0409, buf, len,
+ USB_CTRL_GET_TIMEOUT);
+ if (rc == -EPIPE) {
+ hid_err(hdev, "device parameters not found\n");
+ rc = -ENODEV;
+ goto cleanup;
+ } else if (rc < 0) {
+ hid_err(hdev, "failed to get device parameters: %d\n", rc);
+ rc = -ENODEV;
+ goto cleanup;
+ } else if (rc != len) {
+ hid_err(hdev, "invalid device parameters\n");
+ rc = -ENODEV;
+ goto cleanup;
+ }
+
+ /* Extract device parameters */
+ params[UCLOGIC_PH_ID_X_LM] = le16_to_cpu(buf[UCLOGIC_PRM_X_LM]);
+ params[UCLOGIC_PH_ID_Y_LM] = le16_to_cpu(buf[UCLOGIC_PRM_Y_LM]);
+ params[UCLOGIC_PH_ID_PRESSURE_LM] =
+ le16_to_cpu(buf[UCLOGIC_PRM_PRESSURE_LM]);
+ resolution = le16_to_cpu(buf[UCLOGIC_PRM_RESOLUTION]);
+ if (resolution == 0) {
+ params[UCLOGIC_PH_ID_X_PM] = 0;
+ params[UCLOGIC_PH_ID_Y_PM] = 0;
+ } else {
+ params[UCLOGIC_PH_ID_X_PM] = params[UCLOGIC_PH_ID_X_LM] *
+ 1000 / resolution;
+ params[UCLOGIC_PH_ID_Y_PM] = params[UCLOGIC_PH_ID_Y_LM] *
+ 1000 / resolution;
+ }
+
+ /* Allocate fixed report descriptor */
+ drvdata->rdesc = devm_kzalloc(&hdev->dev,
+ sizeof(uclogic_tablet_rdesc_template),
+ GFP_KERNEL);
+ if (drvdata->rdesc == NULL) {
+ hid_err(hdev, "failed to allocate fixed rdesc\n");
+ rc = -ENOMEM;
+ goto cleanup;
+ }
+ drvdata->rsize = sizeof(uclogic_tablet_rdesc_template);
+
+ /* Format fixed report descriptor */
+ memcpy(drvdata->rdesc, uclogic_tablet_rdesc_template,
+ drvdata->rsize);
+ for (p = drvdata->rdesc;
+ p <= drvdata->rdesc + drvdata->rsize - 4;) {
+ if (p[0] == 0xFE && p[1] == 0xED && p[2] == 0x1D &&
+ p[3] < sizeof(params)) {
+ v = params[p[3]];
+ put_unaligned(cpu_to_le32(v), (s32 *)p);
+ p += 4;
+ } else {
+ p++;
+ }
+ }
+
+ rc = 0;
+
+cleanup:
+ kfree(buf);
+ return rc;
+}
+
static int uclogic_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
int rc;
+ struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+ struct uclogic_drvdata *drvdata;
/*
* libinput requires the pad interface to be on a different node
@@ -637,6 +824,26 @@ static int uclogic_probe(struct hid_device *hdev,
*/
hdev->quirks |= HID_QUIRK_MULTI_INPUT;
+ /* Allocate and assign driver data */
+ drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
+ if (drvdata == NULL)
+ return -ENOMEM;
+
+ hid_set_drvdata(hdev, drvdata);
+
+ switch (id->product) {
+ case USB_DEVICE_ID_HUION_TABLET:
+ /* If this is the pen interface */
+ if (intf->cur_altsetting->desc.bInterfaceNumber == 0) {
+ rc = uclogic_tablet_enable(hdev);
+ if (rc) {
+ hid_err(hdev, "tablet enabling failed\n");
+ return rc;
+ }
+ }
+ break;
+ }
+
rc = hid_parse(hdev);
if (rc) {
hid_err(hdev, "parse failed\n");
@@ -652,6 +859,21 @@ static int uclogic_probe(struct hid_device *hdev,
return 0;
}
+static int uclogic_raw_event(struct hid_device *hdev, struct hid_report *report,
+ u8 *data, int size)
+{
+ struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
+
+ /* If this is a pen input report */
+ if (intf->cur_altsetting->desc.bInterfaceNumber == 0 &&
+ report->type == HID_INPUT_REPORT &&
+ report->id == 0x07 && size >= 2)
+ /* Invert the in-range bit */
+ data[1] ^= 0x40;
+
+ return 0;
+}
+
static const struct hid_device_id uclogic_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UCLOGIC_TABLET_PF1209) },
@@ -667,6 +889,8 @@ static const struct hid_device_id uclogic_devices[] = {
USB_DEVICE_ID_UCLOGIC_WIRELESS_TABLET_TWHL850) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HUION, USB_DEVICE_ID_HUION_TABLET) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_HUION_TABLET) },
{ }
};
MODULE_DEVICE_TABLE(hid, uclogic_devices);
@@ -676,7 +900,10 @@ static struct hid_driver uclogic_driver = {
.id_table = uclogic_devices,
.probe = uclogic_probe,
.report_fixup = uclogic_report_fixup,
+ .raw_event = uclogic_raw_event,
};
module_hid_driver(uclogic_driver);
+MODULE_AUTHOR("Martin Rusko");
+MODULE_AUTHOR("Nikolai Kondrashov");
MODULE_LICENSE("GPL");
--
2.1.0
|
|
From: Benjamin T. <ben...@re...> - 2015-02-25 00:05:44
|
The Huion tablets show 3 interfaces. Only the first and the third
are currently used.
Also remove HID_QUIRK_MULTI_INPUT for the third interface to not
create more than needed input nodes.
Signed-off-by: Benjamin Tissoires <ben...@re...>
---
drivers/hid/hid-uclogic.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-uclogic.c b/drivers/hid/hid-uclogic.c
index 397f1df..c03e076 100644
--- a/drivers/hid/hid-uclogic.c
+++ b/drivers/hid/hid-uclogic.c
@@ -840,6 +840,11 @@ static int uclogic_probe(struct hid_device *hdev,
hid_err(hdev, "tablet enabling failed\n");
return rc;
}
+ } else if (intf->cur_altsetting->desc.bInterfaceNumber == 2) {
+ hdev->quirks &= ~HID_QUIRK_MULTI_INPUT;
+ } else {
+ /* Ignore all unused interfaces */
+ return -ENODEV;
}
break;
}
--
2.1.0
|
|
From: Benjamin T. <ben...@re...> - 2015-02-25 00:05:44
|
We append "Pen", "Pad", "Mouse" or "Keyboard" suffix to the appropriate
input node to match what the Wacom driver does and be more convenient for
the user to know which one is which.
Signed-off-by: Benjamin Tissoires <ben...@re...>
---
drivers/hid/hid-uclogic.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/hid/hid-uclogic.c b/drivers/hid/hid-uclogic.c
index c03e076..7042238 100644
--- a/drivers/hid/hid-uclogic.c
+++ b/drivers/hid/hid-uclogic.c
@@ -713,6 +713,45 @@ static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc,
return rdesc;
}
+static void uclogic_input_configured(struct hid_device *hdev,
+ struct hid_input *hi)
+{
+ char *name;
+ const char *suffix = NULL;
+ struct hid_field *field;
+ size_t len;
+
+ /* no report associated (HID_QUIRK_MULTI_INPUT not set) */
+ if (!hi->report)
+ return;
+
+ field = hi->report->field[0];
+
+ switch (field->application) {
+ case HID_GD_KEYBOARD:
+ suffix = "Keyboard";
+ break;
+ case HID_GD_MOUSE:
+ suffix = "Mouse";
+ break;
+ case HID_GD_KEYPAD:
+ suffix = "Pad";
+ break;
+ case HID_DG_PEN:
+ suffix = "Pen";
+ break;
+ }
+
+ if (suffix) {
+ len = strlen(hdev->name) + 2 + strlen(suffix);
+ name = devm_kzalloc(&hi->input->dev, len, GFP_KERNEL);
+ if (name) {
+ snprintf(name, len, "%s %s", hdev->name, suffix);
+ hi->input->name = name;
+ }
+ }
+}
+
/**
* Enable fully-functional tablet mode and determine device parameters.
*
@@ -906,6 +945,7 @@ static struct hid_driver uclogic_driver = {
.probe = uclogic_probe,
.report_fixup = uclogic_report_fixup,
.raw_event = uclogic_raw_event,
+ .input_configured = uclogic_input_configured,
};
module_hid_driver(uclogic_driver);
--
2.1.0
|
|
From: Benjamin T. <ben...@re...> - 2015-02-25 00:05:43
|
Based on a patch from: Nikolai Kondrashov <Nik...@re...> Most of the tablets handled by hid-uclogic already uses MULTI_INPUT. Fot the ones which are not quirked in usbhid/hidquirks, they have a custom report descriptor which contains only one report per HID interface. For those tablets HID_QUIRK_MULTI_INPUT is transparent. According to https://github.com/DIGImend/tablets, the only problematic tablet currently handled by hid-uclogic is the TWHA60 v3. This tablet presents different report descriptors from the ones currently quirked. This is not a problem per se, given that this tablet is not supported currently in this version (it needs the same command than a Huion to start forwarding events). Signed-off-by: Benjamin Tissoires <ben...@re...> --- Changes from the original patch: - apply HID_QUIRK_MULTI_INPUT for all devices - removed the quirks in usbhid/hid-quirks.c drivers/hid/hid-uclogic.c | 27 +++++++++++++++++++++++++++ drivers/hid/usbhid/hid-quirks.c | 4 ---- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/hid/hid-uclogic.c b/drivers/hid/hid-uclogic.c index fb8b516..22dccce 100644 --- a/drivers/hid/hid-uclogic.c +++ b/drivers/hid/hid-uclogic.c @@ -626,6 +626,32 @@ static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc, return rdesc; } +static int uclogic_probe(struct hid_device *hdev, + const struct hid_device_id *id) +{ + int rc; + + /* + * libinput requires the pad interface to be on a different node + * than the pen, so use QUIRK_MULTI_INPUT for all tablets. + */ + hdev->quirks |= HID_QUIRK_MULTI_INPUT; + + rc = hid_parse(hdev); + if (rc) { + hid_err(hdev, "parse failed\n"); + return rc; + } + + rc = hid_hw_start(hdev, HID_CONNECT_DEFAULT); + if (rc) { + hid_err(hdev, "hw start failed\n"); + return rc; + } + + return 0; +} + static const struct hid_device_id uclogic_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_PF1209) }, @@ -648,6 +674,7 @@ MODULE_DEVICE_TABLE(hid, uclogic_devices); static struct hid_driver uclogic_driver = { .name = "uclogic", .id_table = uclogic_devices, + .probe = uclogic_probe, .report_fixup = uclogic_report_fixup, }; module_hid_driver(uclogic_driver); diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c index 989c59a..75ca2de 100644 --- a/drivers/hid/usbhid/hid-quirks.c +++ b/drivers/hid/usbhid/hid-quirks.c @@ -106,12 +106,8 @@ static const struct hid_blacklist { { USB_VENDOR_ID_SYMBOL, USB_DEVICE_ID_SYMBOL_SCANNER_2, HID_QUIRK_NOGET }, { USB_VENDOR_ID_TPV, USB_DEVICE_ID_TPV_OPTICAL_TOUCHSCREEN, HID_QUIRK_NOGET }, { USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_TURBOX_KEYBOARD, HID_QUIRK_NOGET }, - { USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_PF1209, HID_QUIRK_MULTI_INPUT }, - { USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_WP4030U, HID_QUIRK_MULTI_INPUT }, { USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_KNA5, HID_QUIRK_MULTI_INPUT }, { USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_TWA60, HID_QUIRK_MULTI_INPUT }, - { USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_WP5540U, HID_QUIRK_MULTI_INPUT }, - { USB_VENDOR_ID_UCLOGIC, USB_DEVICE_ID_UCLOGIC_TABLET_WP8060U, HID_QUIRK_MULTI_INPUT }, { USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_MEDIA_TABLET_10_6_INCH, HID_QUIRK_MULTI_INPUT }, { USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH, HID_QUIRK_MULTI_INPUT }, { USB_VENDOR_ID_WALTOP, USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET, HID_QUIRK_MULTI_INPUT }, -- 2.1.0 |
|
From: Benjamin T. <ben...@re...> - 2015-02-25 00:05:43
|
Hi, So, this is a attempt to get a common base with the out of the tree driver for Huion and UC-Logic tablets here https://github.com/DIGImend/digimend-kernel-drivers I am CC-ing DIGImend-devel though the patches are aimed at Jiri's tree upstream. Nick, I changed a little bit the first patch compared to your version. I blindly applied HID_QUIRK_MULTI_INPUT. I don't expect anything to break with this, but I was not able to reinject all the devices you have through uhid to check. I'd like you to at least sign both first and second if you are happy with the code. The remaining bit for the tablet I have is the switch to the button reporting mode, but I think that will need a little bit more testing from the users of the DIDImend project. Cheers, Benjamin Benjamin Tissoires (4): HID: uclogic: Set quirks from inside the driver HID: uclogic: merge hid-huion driver in hid-uclogic HID: uclogic: present only the working interfaces on the Huion tablets HID: uclogic: name the input nodes based on their tool drivers/hid/Kconfig | 8 +- drivers/hid/Makefile | 1 - drivers/hid/hid-huion.c | 290 -------------------------------------- drivers/hid/hid-uclogic.c | 301 +++++++++++++++++++++++++++++++++++++++- drivers/hid/usbhid/hid-quirks.c | 4 - 5 files changed, 301 insertions(+), 303 deletions(-) delete mode 100644 drivers/hid/hid-huion.c -- 2.1.0 |
|
From: Peter H. <pet...@wh...> - 2015-02-24 21:46:05
|
On Tue, Feb 24, 2015 at 01:22:37PM +0200, Nikolai Kondrashov wrote: > On 02/24/2015 12:34 AM, Benjamin Tissoires wrote: > >On Feb 23 2015 or thereabouts, Peter Hutterer wrote: > >>yeah, but the thing is: those emails are only necessary _once_ per tablet. > >>if they're not in the database, you'll get those questions for the lifetime > >>of the tablet :) > >> > >>Also note that libwacom_new_from_path() has a fallback option, you can get a > >>generic tablet from it and then proceed as normal. gnome-settings-daemon > >>already uses this. > >> > > > >I also expects that the settings configuration tool under wayland will > >rely on the actual capability of the devices. This way, even if the > >tablet is not registered in libwacom, we will still be able to show a > >default configuration UI. > > > >I really believe the registering in libwacom will be just to have a > >prettier interface, not a requirement. > > Well, that sounds awesome! Just what I was looking for :) > > What about X.org though? Last time I tried I couldn't configure a > Wacom-handled Huion with the Gnome applet. hard to say, settings-daemon/control-center use the xorg wacom driver properties, so in theory it should work. Best to file a gnome bug for it and CC me on it, there's no obvious definitive answer I can think of right now. Cheers, Peter |
|
From: Nikolai K. <sp...@gm...> - 2015-02-24 11:28:02
|
On 02/24/2015 12:44 AM, Benjamin Tissoires wrote: > On Feb 19 2015 or thereabouts, Nikolai Kondrashov wrote: >> On 02/18/2015 10:04 PM, Benjamin Tissoires wrote: >>> On Feb 18 2015 or thereabouts, Nikolai Kondrashov wrote: > [snipped] >>> >>> OK, will respin the patches for your out of the tree driver. >> >> Thanks a lot, Benjamin! >> > > OK, so after a little bit of struggle, I think we need to work both > upstream and on the out of the tree driver. Most of the current patches > in the out of the tree driver can be included right now and there is no > need to make hundreds of tests for these. > > If you don't mind, I'll post them tomorrow with the follow up of the > patches I know will not break the tablets. Then, we can sync on the > digimend tree and ask users to test the "abstract buttons events" > reporting mode. It will help me and will also speed up the process of > having everything included sooner. > > How does that sound? Sure, go ahead and I'll help as much as I can. Thanks, Benjamin! Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-24 11:22:49
|
On 02/24/2015 12:34 AM, Benjamin Tissoires wrote: > On Feb 23 2015 or thereabouts, Peter Hutterer wrote: >> yeah, but the thing is: those emails are only necessary _once_ per tablet. >> if they're not in the database, you'll get those questions for the lifetime >> of the tablet :) >> >> Also note that libwacom_new_from_path() has a fallback option, you can get a >> generic tablet from it and then proceed as normal. gnome-settings-daemon >> already uses this. >> > > I also expects that the settings configuration tool under wayland will > rely on the actual capability of the devices. This way, even if the > tablet is not registered in libwacom, we will still be able to show a > default configuration UI. > > I really believe the registering in libwacom will be just to have a > prettier interface, not a requirement. Well, that sounds awesome! Just what I was looking for :) What about X.org though? Last time I tried I couldn't configure a Wacom-handled Huion with the Gnome applet. Nick |
|
From: Benjamin T. <ben...@re...> - 2015-02-23 22:44:46
|
On Feb 19 2015 or thereabouts, Nikolai Kondrashov wrote: > On 02/18/2015 10:04 PM, Benjamin Tissoires wrote: > >On Feb 18 2015 or thereabouts, Nikolai Kondrashov wrote: [snipped] > > > >OK, will respin the patches for your out of the tree driver. > > Thanks a lot, Benjamin! > OK, so after a little bit of struggle, I think we need to work both upstream and on the out of the tree driver. Most of the current patches in the out of the tree driver can be included right now and there is no need to make hundreds of tests for these. If you don't mind, I'll post them tomorrow with the follow up of the patches I know will not break the tablets. Then, we can sync on the digimend tree and ask users to test the "abstract buttons events" reporting mode. It will help me and will also speed up the process of having everything included sooner. How does that sound? Cheers, Benjamin |
|
From: Benjamin T. <ben...@re...> - 2015-02-23 22:35:05
|
On Feb 23 2015 or thereabouts, Peter Hutterer wrote: > On Sun, Feb 22, 2015 at 02:33:53PM +0200, Nikolai Kondrashov wrote: > > On 02/20/2015 07:34 AM, Peter Hutterer wrote: > > >On Thu, Feb 19, 2015 at 01:54:17PM +0200, Nikolai Kondrashov wrote: > > >[...] > > >>>>>Last, I think we could add these tablets in the libwacom project, so that there > > >>>>>will be a nice GUI to configure the buttons. > > >>>> > > >>>>That would be a very welcome change, without doubt, thank you. > > >>>> > > >>>>However, I can't help wondering, would it be more productive to allow libwacom > > >>>>to work with just any basic tablet, without the need to add each one to the > > >>>>database? > > >>> > > >>>Actually, libwacom is not tight to Wacom devices at all (or should not > > >>>be). It is just a database of devices to add what the kernel doesn't or > > >>>can not provide. The things that are in the db are for example how the > > >>>buttons are physically mapped on the device, what is the actual layout > > >>>(one svg file), if there are LEDs attached to the tablet. > > >>> > > >>>All this needs a fine per-device tuning. We can add a generic > > >>>Huion/UClogic tablet too, but having a specific per-device definition > > >>>allows to show the exact mapping of the buttons on the overlay when > > >>>setting the functions. > > >> > > >>I agree, that's a nice feature. However, I think being able to configure all > > >>the applicable Wacom driver features relatively comfortably, even if the > > >>tablet on screen doesn't exactly match your tablet, is still a win, compared > > >>to not being able to do it. > > >> > > >>For the unknown tablets we can just draw abstract tablets, emphasising that > > >>control locations on the screen don't map to the actual locations. For > > >>example, have the tablet drawn like an exploded diagram: surface, buttons, > > >>dials - all separate. Something like this: > > >> > > >> Buttons: * * * * * * * > > >> Dials: O O > > >> Work area: +------------+ > > >> | | > > >> | | > > >> | | > > >> +------------+ > > >> > > >>I think the users will be able to figure out the mapping by experimentation. > > >> > > >>While it's just about possible to keep an up-to-date database of Wacom > > >>tablets, I don't think we'll ever be able to list all those generic tablets > > >>out there. Meanwhile a lot of people are left in the cold of xsetwacom and > > >>xinput. > > > > > >not a reason to give up, IMO. most of these generic tablets are relatively > > >simple, so adding a libwacom entry should be a matter of minutes. > > >we'll never get full support of everything, but perfect is the enemy of good > > >here. > > > > Hmm, I see having all the tablets listed in the database as perfect and having > > generic tablet handling as more practical, i.e. the other way around. > > > > It might be easy for us to add a tablet entry, but not for the general user. > > They will need to figure out they need to add that entry first and they'll > > need to figure out what to put there and how. This will need to go through us > > in the end and we'll need to extract all the information from the user, which > > will likely require several e-mails for *each* tablet. > > yeah, but the thing is: those emails are only necessary _once_ per tablet. > if they're not in the database, you'll get those questions for the lifetime > of the tablet :) > > Also note that libwacom_new_from_path() has a fallback option, you can get a > generic tablet from it and then proceed as normal. gnome-settings-daemon > already uses this. > I also expects that the settings configuration tool under wayland will rely on the actual capability of the devices. This way, even if the tablet is not registered in libwacom, we will still be able to show a default configuration UI. I really believe the registering in libwacom will be just to have a prettier interface, not a requirement. Cheers, Benjamin > > > > Meanwhile most users just want to draw. > > > > I might be misunderstanding something, though. > > > > Regardless, Benjamin work is making it all better, I cannot complain :) > > > > Nick |
|
From: Peter H. <pet...@wh...> - 2015-02-22 23:28:31
|
On Sun, Feb 22, 2015 at 02:33:53PM +0200, Nikolai Kondrashov wrote: > On 02/20/2015 07:34 AM, Peter Hutterer wrote: > >On Thu, Feb 19, 2015 at 01:54:17PM +0200, Nikolai Kondrashov wrote: > >[...] > >>>>>Last, I think we could add these tablets in the libwacom project, so that there > >>>>>will be a nice GUI to configure the buttons. > >>>> > >>>>That would be a very welcome change, without doubt, thank you. > >>>> > >>>>However, I can't help wondering, would it be more productive to allow libwacom > >>>>to work with just any basic tablet, without the need to add each one to the > >>>>database? > >>> > >>>Actually, libwacom is not tight to Wacom devices at all (or should not > >>>be). It is just a database of devices to add what the kernel doesn't or > >>>can not provide. The things that are in the db are for example how the > >>>buttons are physically mapped on the device, what is the actual layout > >>>(one svg file), if there are LEDs attached to the tablet. > >>> > >>>All this needs a fine per-device tuning. We can add a generic > >>>Huion/UClogic tablet too, but having a specific per-device definition > >>>allows to show the exact mapping of the buttons on the overlay when > >>>setting the functions. > >> > >>I agree, that's a nice feature. However, I think being able to configure all > >>the applicable Wacom driver features relatively comfortably, even if the > >>tablet on screen doesn't exactly match your tablet, is still a win, compared > >>to not being able to do it. > >> > >>For the unknown tablets we can just draw abstract tablets, emphasising that > >>control locations on the screen don't map to the actual locations. For > >>example, have the tablet drawn like an exploded diagram: surface, buttons, > >>dials - all separate. Something like this: > >> > >> Buttons: * * * * * * * > >> Dials: O O > >> Work area: +------------+ > >> | | > >> | | > >> | | > >> +------------+ > >> > >>I think the users will be able to figure out the mapping by experimentation. > >> > >>While it's just about possible to keep an up-to-date database of Wacom > >>tablets, I don't think we'll ever be able to list all those generic tablets > >>out there. Meanwhile a lot of people are left in the cold of xsetwacom and > >>xinput. > > > >not a reason to give up, IMO. most of these generic tablets are relatively > >simple, so adding a libwacom entry should be a matter of minutes. > >we'll never get full support of everything, but perfect is the enemy of good > >here. > > Hmm, I see having all the tablets listed in the database as perfect and having > generic tablet handling as more practical, i.e. the other way around. > > It might be easy for us to add a tablet entry, but not for the general user. > They will need to figure out they need to add that entry first and they'll > need to figure out what to put there and how. This will need to go through us > in the end and we'll need to extract all the information from the user, which > will likely require several e-mails for *each* tablet. yeah, but the thing is: those emails are only necessary _once_ per tablet. if they're not in the database, you'll get those questions for the lifetime of the tablet :) Also note that libwacom_new_from_path() has a fallback option, you can get a generic tablet from it and then proceed as normal. gnome-settings-daemon already uses this. Cheers, Peter > > Meanwhile most users just want to draw. > > I might be misunderstanding something, though. > > Regardless, Benjamin work is making it all better, I cannot complain :) > > Nick |
|
From: Dan R. <ade...@gm...> - 2015-02-22 20:03:19
|
Hi Nick,
I noticed you CCed the list with some of that discussion, I apologize I
had only skimmed it and assumed the entire patch set was about the button
functionality. I'm happy to test (Huion H610, not sure if it's different
from the Pro Benjamin has) when Benjamin has rebased his patches against
the out-of-tree drivers.
Thanks,
Dan
On Sun, Feb 22, 2015 at 4:46 AM, Nikolai Kondrashov <sp...@gm...>
wrote:
> Hi Dan,
>
> On 02/22/2015 05:17 AM, Dan Roberts wrote:
>
>> Hi Everyone,
>> I believe I've identified the condition under which Gimp does or
>> does not work with my Huion H610, in line with earlier speculation. It
>> seems that X.org is inconsistent when assigning XIDs to devices. I'm not
>> certain why this is (could be in X.org, udev, or xf86-input-evdev, I
>> believe it's not in the kernel), but I can show that this is the case.
>> Attached is a log of my bash session during these tests. I will also copy
>> the most relevant portions here.
>>
>> *The summary is that if the pen interface receives the lowest XID from
>> X.org, Gimp works properly, otherwise it does not work properly. I propose
>> a mitigation strategy below.*
>> *
>> *
>> To test this I compared the output from xinput list-props {13..15} | grep
>> "Button Labels" to whether Gimp functioned properly or not. I identified
>> 13..15 as the correct XIDs using xinput prior to conducting this experiment.
>>
>> The following are the output for when Gimp functioned (confirmed multiple
>> times, see logs):
>>
>> $ xinput list-props {13..15} | grep "Button Labels"
>> *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button
>> Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)*
>> Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button
>> Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button
>> Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side"
>> (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown"
>> (255), "Button Unknown" (255), "Button Unknown" (255)
>> Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button
>> Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button
>> Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
>>
>> The following are the output for when Gimp did not function:
>>
>> $ xinput list-props {13..15} | grep "Button Labels"
>> Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button
>> Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button
>> Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
>> *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button
>> Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)*
>> Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button
>> Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button
>> Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side"
>> (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown"
>> (255), "Button Unknown" (255), "Button Unknown" (255)
>>
>> $ xinput list-props {13..15} | grep "Button Labels"
>> Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button
>> Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button
>> Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
>> Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button
>> Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button
>> Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side"
>> (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown"
>> (255), "Button Unknown" (255), "Button Unknown" (255)
>> *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button
>> Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)*
>>
>> As you can see the pen interface (with labels Button Left, Middle, Right,
>> Wheel Up, Wheel Down only) having id 13 correlates with correct functioning
>> of Gimp. I believe this is because Gimp (and Gtk+?) do not identify devices
>> by anything more than their string name. You can open ~/.gimp-2.8/devicerc
>> (or 2.6, I believe newer versions use ~/.config/gimp or similar) and
>> observe that no identifying information other than the device name is
>> stored.
>>
>> *Mitigation Strategy*
>>
>> To mitigate this problem, I propose renaming the pen interface in the
>> kernel module, like in this simple patch:
>>
>> diff --git a/hid-uclogic.c b/hid-uclogic.c
>> index 23fa0fb..697dca6 100644
>> --- a/hid-uclogic.c
>> +++ b/hid-uclogic.c
>> @@ -838,6 +838,7 @@ static int uclogic_probe(struct hid_device *hdev,
>> const struct hid_device_id *id
>> hid_err(hdev, "tablet enabling
>> failed\n");
>> return rc;
>> }
>> + strlcat(hdev->name, " Pen", sizeof(hdev->name));
>> }
>> break;
>> case USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60:
>>
>> This simply appends Pen to the device name, disambiguating the device in
>> Gimp's view. I have not been able to reproduce the Gimp issues when using
>> this patched version of the module (and it doesn't require disabling the
>> other interfaces). I have confirmed that Gimp functions properly even in
>> cases where the Pen interface has a higher XID than the other interfaces.
>> If my understanding of the issue is correct, then this does resolve the
>> Gimp issues. I don't, however, know whether this breaks any kernel style
>> rules, at the very least it's a handy hack I think is useful, and perhaps
>> people who have had trouble with Gimp would be willing to try it. Any brave
>> souls who wish to try it out can find the source here
>> https://github.com/Ademan/digimend-kernel-drivers/archive/rename_pen.zip
>> note it only works for devices with the same VID:PID as the H610 for the
>> moment. I did not feel comfortable extending support to tablets I can't
>> test.
>>
>> Attached are the raw logs of my bash session testing, with the exception
>> of removing my hostname, and a slightly friendlier version where I removed
>> redundant information. You can note from the dmesg output that the XIDs
>> assigned don't appear to be dependent on dmesg's log order. Astute readers
>> will notice messages from both the huion and uclogic modules. I
>> re-conducted this test with the huion module removed, the results were
>> identical. Raw logs may be found in the attached file
>> rawlog-uclogic-only.txt
>>
>> Nick,
>> In particular I'd like your input on whether this is a viable
>> mitigation
>> strategy. If I'm not mistaken, the abstract keyboard branch disables
>> the
>> tablet buttons, whereas this allows users to have Gimp work correctly
>> *and* potentially have working tablet buttons.
>>
>
> Thanks for a thorough investigation, Dan!
>
> I believe you're correct. This was a problem for a long while and there
> were
> some patches to add clarifications to event device names in the past. I
> wanted
> to implement something generic myself to avoid catering to each tablet, but
> never got around to it.
>
> Your approach is fine. However, I think we can go with patches Benjamin
> Tissoires posted recently [1]. Those prepare the Huion driver for the
> current
> libinput development and also add clarifications to event device names.
>
> The effect will be the same, but the implementation will also include
> future-proofing. I'm awaiting a pull request from him with those changes.
>
> Nick
>
> [1] http://www.spinics.net/lists/linux-input/msg36675.html
>
|
|
From: Nikolai K. <sp...@gm...> - 2015-02-22 19:32:35
|
Hi Damonn, Please keep the maillist in the CC. Thank you. On 02/22/2015 08:08 PM, Damonn Colon wrote: > I do still have access, but I've found another fault that seems to be a more > likely cause. After performing more checks on the hardware, I've discovered > that the RAM is failing on that computer (2 x 2GB DDR2 sticks). I have a > new setup prepped (8GB DDR3 with a better processor) for installation with > the same HD and install once one final part arrives this coming week. If > the problem persists, I'll provide the above information. I'll also let you > know if replacing the components (more+better RAM) corrects the problem > experienced. Sure. Please write if you still see the problem after that. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-22 12:46:47
|
Hi Dan, On 02/22/2015 05:17 AM, Dan Roberts wrote: > Hi Everyone, > I believe I've identified the condition under which Gimp does or does not work with my Huion H610, in line with earlier speculation. It seems that X.org is inconsistent when assigning XIDs to devices. I'm not certain why this is (could be in X.org, udev, or xf86-input-evdev, I believe it's not in the kernel), but I can show that this is the case. Attached is a log of my bash session during these tests. I will also copy the most relevant portions here. > > *The summary is that if the pen interface receives the lowest XID from X.org, Gimp works properly, otherwise it does not work properly. I propose a mitigation strategy below.* > * > * > To test this I compared the output from xinput list-props {13..15} | grep "Button Labels" to whether Gimp functioned properly or not. I identified 13..15 as the correct XIDs using xinput prior to conducting this experiment. > > The following are the output for when Gimp functioned (confirmed multiple times, see logs): > > $ xinput list-props {13..15} | grep "Button Labels" > *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)* > Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255) > Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144) > > The following are the output for when Gimp did not function: > > $ xinput list-props {13..15} | grep "Button Labels" > Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144) > *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)* > Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255) > > $ xinput list-props {13..15} | grep "Button Labels" > Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144) > Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255) > *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)* > > As you can see the pen interface (with labels Button Left, Middle, Right, Wheel Up, Wheel Down only) having id 13 correlates with correct functioning of Gimp. I believe this is because Gimp (and Gtk+?) do not identify devices by anything more than their string name. You can open ~/.gimp-2.8/devicerc (or 2.6, I believe newer versions use ~/.config/gimp or similar) and observe that no identifying information other than the device name is stored. > > *Mitigation Strategy* > > To mitigate this problem, I propose renaming the pen interface in the kernel module, like in this simple patch: > > diff --git a/hid-uclogic.c b/hid-uclogic.c > index 23fa0fb..697dca6 100644 > --- a/hid-uclogic.c > +++ b/hid-uclogic.c > @@ -838,6 +838,7 @@ static int uclogic_probe(struct hid_device *hdev, const struct hid_device_id *id > hid_err(hdev, "tablet enabling failed\n"); > return rc; > } > + strlcat(hdev->name, " Pen", sizeof(hdev->name)); > } > break; > case USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60: > > This simply appends Pen to the device name, disambiguating the device in Gimp's view. I have not been able to reproduce the Gimp issues when using this patched version of the module (and it doesn't require disabling the other interfaces). I have confirmed that Gimp functions properly even in cases where the Pen interface has a higher XID than the other interfaces. If my understanding of the issue is correct, then this does resolve the Gimp issues. I don't, however, know whether this breaks any kernel style rules, at the very least it's a handy hack I think is useful, and perhaps people who have had trouble with Gimp would be willing to try it. Any brave souls who wish to try it out can find the source here https://github.com/Ademan/digimend-kernel-drivers/archive/rename_pen.zip note it only works for devices with the same VID:PID as the H610 for the moment. I did not feel comfortable extending support to tablets I can't test. > > Attached are the raw logs of my bash session testing, with the exception of removing my hostname, and a slightly friendlier version where I removed redundant information. You can note from the dmesg output that the XIDs assigned don't appear to be dependent on dmesg's log order. Astute readers will notice messages from both the huion and uclogic modules. I re-conducted this test with the huion module removed, the results were identical. Raw logs may be found in the attached file rawlog-uclogic-only.txt > > Nick, > In particular I'd like your input on whether this is a viable mitigation > strategy. If I'm not mistaken, the abstract keyboard branch disables the > tablet buttons, whereas this allows users to have Gimp work correctly > *and* potentially have working tablet buttons. Thanks for a thorough investigation, Dan! I believe you're correct. This was a problem for a long while and there were some patches to add clarifications to event device names in the past. I wanted to implement something generic myself to avoid catering to each tablet, but never got around to it. Your approach is fine. However, I think we can go with patches Benjamin Tissoires posted recently [1]. Those prepare the Huion driver for the current libinput development and also add clarifications to event device names. The effect will be the same, but the implementation will also include future-proofing. I'm awaiting a pull request from him with those changes. Nick [1] http://www.spinics.net/lists/linux-input/msg36675.html |
|
From: Nikolai K. <sp...@gm...> - 2015-02-22 12:34:03
|
On 02/20/2015 07:34 AM, Peter Hutterer wrote: > On Thu, Feb 19, 2015 at 01:54:17PM +0200, Nikolai Kondrashov wrote: > [...] >>>>> Last, I think we could add these tablets in the libwacom project, so that there >>>>> will be a nice GUI to configure the buttons. >>>> >>>> That would be a very welcome change, without doubt, thank you. >>>> >>>> However, I can't help wondering, would it be more productive to allow libwacom >>>> to work with just any basic tablet, without the need to add each one to the >>>> database? >>> >>> Actually, libwacom is not tight to Wacom devices at all (or should not >>> be). It is just a database of devices to add what the kernel doesn't or >>> can not provide. The things that are in the db are for example how the >>> buttons are physically mapped on the device, what is the actual layout >>> (one svg file), if there are LEDs attached to the tablet. >>> >>> All this needs a fine per-device tuning. We can add a generic >>> Huion/UClogic tablet too, but having a specific per-device definition >>> allows to show the exact mapping of the buttons on the overlay when >>> setting the functions. >> >> I agree, that's a nice feature. However, I think being able to configure all >> the applicable Wacom driver features relatively comfortably, even if the >> tablet on screen doesn't exactly match your tablet, is still a win, compared >> to not being able to do it. >> >> For the unknown tablets we can just draw abstract tablets, emphasising that >> control locations on the screen don't map to the actual locations. For >> example, have the tablet drawn like an exploded diagram: surface, buttons, >> dials - all separate. Something like this: >> >> Buttons: * * * * * * * >> Dials: O O >> Work area: +------------+ >> | | >> | | >> | | >> +------------+ >> >> I think the users will be able to figure out the mapping by experimentation. >> >> While it's just about possible to keep an up-to-date database of Wacom >> tablets, I don't think we'll ever be able to list all those generic tablets >> out there. Meanwhile a lot of people are left in the cold of xsetwacom and >> xinput. > > not a reason to give up, IMO. most of these generic tablets are relatively > simple, so adding a libwacom entry should be a matter of minutes. > we'll never get full support of everything, but perfect is the enemy of good > here. Hmm, I see having all the tablets listed in the database as perfect and having generic tablet handling as more practical, i.e. the other way around. It might be easy for us to add a tablet entry, but not for the general user. They will need to figure out they need to add that entry first and they'll need to figure out what to put there and how. This will need to go through us in the end and we'll need to extract all the information from the user, which will likely require several e-mails for *each* tablet. Meanwhile most users just want to draw. I might be misunderstanding something, though. Regardless, Benjamin work is making it all better, I cannot complain :) Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-22 12:23:15
|
On 02/19/2015 06:41 PM, Yann Vernier wrote: >> The attached version uses pick, and thus reports (using input-events) stylus >> for the side button closer to the tip and stylus2 for the one further away. > > Upon a moment more testing, I think those two usages might be better swapped, > for consistency with the mouse mode. Or perhaps the mouse mode should have the > swap for consistency with other tablets. Right now the buttons swap meaning > between mouse and stylus modes. I would prefer the latter. I.e. have the lower side button report middle click and the upper one report right click to match other tablets. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-22 12:22:03
|
On 02/19/2015 06:19 PM, Yann Vernier wrote: > On Sat, 31 Jan 2015 12:35:28 +0200 > Nikolai Kondrashov <sp...@gm...> wrote: >> I'm not sure how repeated report ID items in a single collection even work. >> Also duplicate report IDs sound fishy. All-in-all, this is some really weird >> report descriptor and would be difficult to reason about. I would start from >> scratch, taking one of the fixed report descriptors from other tablets and >> adjusting it to the bit fields this one reports. > > I think it's some sort of indirect description, applying resolution multipliers > to the preexisting report 1, so as not to confuse the boot protocol interpretation. I have my doubts about this. First, boot protocol doesn't involve parsing the report descriptor. Then, the device is unlikely to actually need a resolution multiplier. What for? > However, I have not gotten the device to send the multiplier reports, and Linux > seems to happily ignore them. That's probably just some imagination/engineering gone wild and never implemented. >>> /* I expect patching in these values (from interface 2) >>> would get Xorg to use tablet mode: */ >>> 0x09, 0x42, /* Usage (Tip Switch), */ >>> 0x09, 0x44, /* Usage (Barrel Switch), */ >>> 0x09, 0x45, /* Usage (Eraser), */ /* Really on the barrel too */ >> >> I suggest to use "Tablet Pick" here. I added it to the kernel and use it for >> the second barrel button on all of the tablets. It will map to the third >> button. > > Certainly. Since this is a patch driver for Linux anyway, convention there takes > priority. I don't know if other tablets also abuse eraser like this. Yes, quite a lot of them do that. >>> /* The original usages should have mapped to mouse buttons, but Linux >>> happily reports them as buttons 10-12. */ >>> /* 0x05, 0x0f, / * Usage Page (Button), */ >>> /* 0x19, 0x01, / * Usage Minimum (01h), */ >>> /* 0x29, 0x03, / * Usage Maximum (03h), */ >>> /* End of Stylus button usage */ >> >> I think having six usages and only three reports wouldn't work. > > Those were simply commented out versions of what the device originally sent. Ah, sorry, didn't notice that. >>> 0x15, 0x00, /* Logical Minimum (0), */ >>> 0x25, 0x01, /* Logical Maximum (1), */ >>> 0x95, 0x03, /* Report Count (3), */ >>> 0x75, 0x01, /* Report Size (1), */ >>> 0x81, 0x02, /* Input (Variable), */ >>> 0x95, 0x05, /* Report Count (5), */ >>> 0x81, 0x01, /* Input (Constant), */ >>> 0x05, 0x01, /* Usage Page (Desktop), */ >>> 0x09, 0x30, /* Usage (X), */ >>> 0x09, 0x31, /* Usage (Y), */ >>> 0x15, 0x00, /* Logical Minimum (0), */ >>> 0x26, 0x00, 0x10, /* Logical Maximum (4096), */ >>> 0x35, 0x00, /* Physical Minimum (0), */ >>> 0x46, 0x00, 0x10, /* Physical Maximum (4096), */ >> >> Is the actual physical drawing area square? > > No. I believe it's meant to be 16:10 proportions. > A quick measurement by the printed border shows: > X: inner 103.65mm, outer 105mm > Y: inner 65.6mm, outer 66.45mm > This gives an aspect ratio somewhere from 1.56 to 1.60. Measuring the firmware limits > would be a bit harder (for instance, it doesn't measure the tip but the coil position). > I guess 105.6*66mm would be a reasonable approximation. This would be awfully low resolution and most likely scaled by firmware for compatibility. The oldest tablet I have (UC-Logic WP8060U) has higher resolution, I think. There's very little chance a non-square tablet would report equal coordinate range for both axes in hardware. There might be a way to get it to report real ranges over USB. I would try poking at those features in the report descriptor. There should have been a driver for this tablet doing that. Perhaps we can find it and take a look at the USB traffic. We can postpone it for later, though. > I have tried to put this data into the attached descriptor. BTW, the original descriptor for interface 2 seems to have the correct range and physical extents. You can take the extents from there at least, which seem to be 4x2.5 inches. > It would also be a little tricky to measure the unit of pressure, so I took the > push/pop example from one of the uc-logic descriptors. Sure. It would also be mostly pointless. I don't think any manufacturer really calibrates them. There is no kernel support for communicating the resolution and people just use pressure curves to adjust the behavior as necessary anyway. > The attached version uses pick, and thus reports (using input-events) stylus > for the side button closer to the tip and stylus2 for the one further away. > > It was tested to work smoothly in inkscape and krita. Since it overrides the > descriptor it doesn't care about the readout bugs, so it works on its own (but > still requires the unbinding of hid-generic from the relevant interface). Great! Yes, you need rebinding for out-of-tree drivers anyway. That's just the way kernel works. It won't be necessary if it gets merged into the kernel. Speaking of which, I think you need to make the report descriptor as simple as possible to make it easier to get into the kernel. Strip it down to the absolute minimum required to work. Remove unused report IDs and collections. > http://www.nybytt.se/zeniq-pen-tablet/ is a clear example of one of these tablets. > Mine happen to have the Leogics brand instead. Ah, another rebranding. I have some comments to the code below. > /* > * HID driver for Polostar devices not fully compliant with HID standard > * > * Copyright (c) 2010 Nikolai Kondrashov There's no need to put my copyright on here. > * Copyright (c) 2015 Yann Vernier > */ > > /* > * This program is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License as published by the Free > * Software Foundation; either version 2 of the License, or (at your option) > * any later version. > */ > > #include <linux/device.h> > #include <linux/hid.h> > #include <linux/module.h> > #include <linux/usb.h> > > #include "hid-ids.h" > /* Known as Zippy Technology Corp. in usbutils */ > #define USB_VENDOR_ID_POLOSTAR 0x099a > #define USB_DEVICE_ID_POLOSTAR_TABLET_PT1001 0x2620 > > /* Size of the original descriptor of PT-1001 tablets */ > #define PT1001_RDESC_ORIG_SIZE 317 > > /* Fixed PT1001 report descriptor */ > static __u8 pt1001_rdesc_fixed[] = { > 0x05, 0x01, /* Usage Page (Desktop), */ > 0x09, 0x02, /* Usage (Mouse), */ > 0xA1, 0x01, /* Collection (Application), */ > 0x05, 0x09, /* Usage Page (Button), */ > /* Report ID 1 is used for mouse mode and scroll */ > 0x85, 0x01, /* Report ID (1), */ > 0x19, 0x01, /* Usage Minimum (01h), */ > 0x29, 0x05, /* Usage Maximum (05h), */ > 0x95, 0x05, /* Report Count (5), */ > 0x75, 0x01, /* Report Size (1), */ > 0x15, 0x00, /* Logical Minimum (0), */ > 0x25, 0x01, /* Logical Maximum (1), */ > 0x81, 0x02, /* Input (Variable), */ > 0x95, 0x03, /* Report Count (3), */ > 0x81, 0x01, /* Input (Constant), */ > 0x05, 0x01, /* Usage Page (Desktop), */ > 0x09, 0x01, /* Usage (Pointer), */ > 0xA1, 0x00, /* Collection (Physical), */ > 0x09, 0x30, /* Usage (X), */ > 0x09, 0x31, /* Usage (Y), */ > 0x95, 0x02, /* Report Count (2), */ > 0x75, 0x10, /* Report Size (16), */ > 0x16, 0x01, 0x80, /* Logical Minimum (-32767), */ > 0x26, 0xFF, 0x7F, /* Logical Maximum (32767), */ > 0x81, 0x06, /* Input (Variable, Relative), */ > 0xC0, /* End Collection, */ > /* The multipliers do not seem to occur as reports. */ > /* They seem to relate to vertical and horisontal scroll. */ > 0xA1, 0x02, /* Collection (Logical), */ > 0x85, 0x02, /* Report ID (2), */ > 0x09, 0x48, /* Usage (Resolution Multiplier), */ > 0x15, 0x00, /* Logical Minimum (0), */ > 0x25, 0x01, /* Logical Maximum (1), */ > 0x95, 0x01, /* Report Count (1), */ > 0x75, 0x02, /* Report Size (2), */ > 0xB1, 0x02, /* Feature (Variable), */ > 0x85, 0x01, /* Report ID (1), */ > 0x09, 0x38, /* Usage (Wheel), */ > 0x15, 0x81, /* Logical Minimum (-127), */ > 0x25, 0x7F, /* Logical Maximum (127), */ > 0x75, 0x08, /* Report Size (8), */ > 0x95, 0x01, /* Report Count (1), */ > 0x81, 0x06, /* Input (Variable, Relative), */ > 0xC0, /* End Collection, */ > 0xA1, 0x02, /* Collection (Logical), */ > 0x85, 0x02, /* Report ID (2), */ > 0x09, 0x48, /* Usage (Resolution Multiplier), */ > 0x15, 0x00, /* Logical Minimum (0), */ > 0x25, 0x01, /* Logical Maximum (1), */ > 0x75, 0x02, /* Report Size (2), */ > 0xB1, 0x02, /* Feature (Variable), */ > 0x75, 0x04, /* Report Size (4), */ > 0xB1, 0x01, /* Feature (Constant), */ > 0x85, 0x01, /* Report ID (1), */ > 0x05, 0x0C, /* Usage Page (Consumer), */ > 0x0A, 0x38, 0x02, /* Usage (AC Pan), */ > 0x15, 0x81, /* Logical Minimum (-127), */ > 0x25, 0x7F, /* Logical Maximum (127), */ > 0x75, 0x08, /* Report Size (8), */ > 0x95, 0x01, /* Report Count (1), */ > 0x81, 0x06, /* Input (Variable, Relative), */ > 0xC0, /* End Collection, */ > 0xC0, /* End Collection, */ You can replace the multiplier fields with constant fields, if they're unused. Also get rid of nested collections and repeated report IDs, if you can. > /* Report 3 looks like the raw protocol. Unknown how to enable. */ > 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */ > 0x09, 0x01, /* Usage (01h), */ > 0xA1, 0x01, /* Collection (Application), */ > 0x85, 0x03, /* Report ID (3), */ > 0x19, 0x01, /* Usage Minimum (01h), */ > 0x29, 0x01, /* Usage Maximum (01h), */ > 0x95, 0x07, /* Report Count (7), */ > 0x81, 0x02, /* Input (Variable), */ > 0x19, 0x01, /* Usage Minimum (01h), */ > 0x29, 0x01, /* Usage Maximum (01h), */ > 0xB1, 0x02, /* Feature (Variable), */ > 0x09, 0x02, /* Usage (02h), */ > 0x15, 0x00, /* Logical Minimum (0), */ > 0x26, 0xFF, 0x00, /* Logical Maximum (255), */ > 0x75, 0x08, /* Report Size (8), */ > 0x95, 0x01, /* Report Count (1), */ > 0x91, 0x02, /* Output (Variable), */ > 0xC0, /* End Collection, */ It's better to remove it, if it's unused. You can always add it back if you figure out a way to make it work. > /* Report ID 5 is used for some periphery buttons */ > 0x05, 0x0C, /* Usage Page (Consumer), */ > 0x09, 0x01, /* Usage (Consumer Control), */ > 0xA1, 0x01, /* Collection (Application), */ > 0x85, 0x05, /* Report ID (5), */ > 0x95, 0x01, /* Report Count (1), */ > 0x75, 0x08, /* Report Size (8), */ > 0x81, 0x01, /* Input (Constant), */ > 0x15, 0x00, /* Logical Minimum (0), */ > 0x25, 0x01, /* Logical Maximum (1), */ > 0x75, 0x01, /* Report Size (1), */ > 0x95, 0x12, /* Report Count (18), */ > 0x0A, 0x83, 0x01, /* Usage (AL Consumer Control Config), */ > 0x0A, 0x8A, 0x01, /* Usage (AL Email Reader), */ > 0x0A, 0x92, 0x01, /* Usage (AL Calculator), */ > 0x0A, 0x94, 0x01, /* Usage (AL Local Machine Brwsr), */ > 0x0A, 0x21, 0x02, /* Usage (AC Search), */ > 0x0A, 0x23, 0x02, /* Usage (AC Home), */ > 0x0A, 0x24, 0x02, /* Usage (AC Back), */ > 0x0A, 0x25, 0x02, /* Usage (AC Forward), */ > 0x0A, 0x26, 0x02, /* Usage (AC Stop), */ > 0x0A, 0x27, 0x02, /* Usage (AC Refresh), */ > 0x0A, 0x2A, 0x02, /* Usage (AC Bookmarks), */ > 0x09, 0xB5, /* Usage (Scan Next Track), */ > 0x09, 0xB6, /* Usage (Scan Previous Track), */ > 0x09, 0xB7, /* Usage (Stop), */ > 0x09, 0xCD, /* Usage (Play Pause), */ > 0x09, 0xE2, /* Usage (Mute), */ > 0x09, 0xE9, /* Usage (Volume Inc), */ > 0x09, 0xEA, /* Usage (Volume Dec), */ > 0x81, 0x62, /* Input (Variable, No Preferred, Null State), */ > 0x95, 0x06, /* Report Count (6), */ > 0x75, 0x01, /* Report Size (1), */ > 0x81, 0x03, /* Input (Constant, Variable), */ > 0xC0, /* End Collection, */ > > /* Report 9 is the primary digitizer report. */ > 0x05, 0x0D, /* Usage Page (Digitizer), */ > 0x09, 0x01, /* Usage (Digitizer), */ > 0xA1, 0x01, /* Collection (Application), */ > 0x85, 0x09, /* Report ID (9), */ > 0x09, 0x20, /* Usage (Stylus), */ > 0xA1, 0x00, /* Collection (Physical), */ > > 0x09, 0x42, /* Usage (Tip Switch), */ > 0x09, 0x44, /* Usage (Barrel Switch), */ > 0x09, 0x46, /* Usage (Tablet Pick), */ /* Really on the barrel too */ > 0x15, 0x00, /* Logical Minimum (0), */ > 0x25, 0x01, /* Logical Maximum (1), */ > 0x95, 0x03, /* Report Count (3), */ > 0x75, 0x01, /* Report Size (1), */ > 0x81, 0x02, /* Input (Variable), */ > > 0x95, 0x05, /* Report Count (5), */ > 0x81, 0x01, /* Input (Constant), */ > > 0x05, 0x01, /* Usage Page (Desktop), */ If you put this usage page inside the push/pop pair, you won't need to restore the digitizer page explicitly later. > 0x15, 0x00, /* Logical Minimum (0), */ > 0x26, 0x00, 0x10, /* Logical Maximum (4096), */ > 0x75, 0x10, /* Report Size (16), */ > 0x95, 0x01, /* Report Count (1), */ > > 0xa4, /* Push */ > > 0x55, 0xfe, /* unit exponent -2: cm -> 0.1mm */ > 0x65, 0x11, /* SI linear centimeters */ > > 0x09, 0x30, /* Usage (X), */ > 0x35, 0x00, /* Physical Minimum (0), */ > 0x46, 0x20, 0x04, /* Physical Maximum (1056), */ > 0x81, 0x02, /* Input (Variable), */ > > 0x09, 0x31, /* Usage (Y), */ > 0x35, 0x00, /* Physical Minimum (0), */ There is no need to repeat physical minimum, but it might be easier to read this way. > 0x46, 0x94, 0x02, /* Physical Maximum (660), */ > 0x81, 0x02, /* Input (Variable), */ > > 0xb4, /* Pop (restore no unit) */ > > 0x05, 0x0D, /* Usage Page (Digitizer), */ > 0x09, 0x30, /* Usage (Tip Pressure), */ > 0x26, 0xFF, 0x03, /* Logical Maximum (1023), */ > 0x95, 0x01, /* Report Count (1), */ There's no need to repeat report count either. > 0x81, 0x02, /* Input (Variable), */ > 0xC0, /* End Collection, */ > 0xC0, /* End Collection */ > }; > > static __u8 *polostar_report_fixup(struct hid_device *hdev, __u8 *rdesc, > unsigned int *rsize) > { > struct usb_interface *iface = to_usb_interface(hdev->dev.parent); > __u8 iface_num = iface->cur_altsetting->desc.bInterfaceNumber; > > switch (hdev->product) { > case USB_DEVICE_ID_POLOSTAR_TABLET_PT1001: > if (iface_num==1 && *rsize == PT1001_RDESC_ORIG_SIZE) { There should be spaces around "==" according to the Linux Kernel Coding Style. > rdesc = pt1001_rdesc_fixed; > *rsize = sizeof(pt1001_rdesc_fixed); > } > break; > } > > return rdesc; > } > > static int polostar_probe(struct hid_device *hdev, const struct hid_device_id *id) > { > int rc; > > hdev->quirks |= id->driver_data; I would disable interface #2 here, if we can't make it work, with something like this: struct usb_interface *intf = to_usb_interface(hdev->dev.parent); if (intf->cur_altsetting->desc.bInterfaceNumber == 2) return -ENODEV; > rc = hid_parse(hdev); > if (rc) { > hid_err(hdev, "parse failed\n"); > return rc; > } > > rc = hid_hw_start(hdev, HID_CONNECT_DEFAULT); > if (rc) { > hid_err(hdev, "hw start failed\n"); > return rc; > } > > return 0; > } > > static const struct hid_device_id polostar_devices[] = { > { HID_USB_DEVICE(USB_VENDOR_ID_POLOSTAR, > USB_DEVICE_ID_POLOSTAR_TABLET_PT1001), > .driver_data = HID_QUIRK_MULTI_INPUT }, > { } > }; > MODULE_DEVICE_TABLE(hid, polostar_devices); > > static struct hid_driver polostar_driver = { > .name = "polostar", > .id_table = polostar_devices, > .probe = polostar_probe, > .report_fixup = polostar_report_fixup, > }; > module_driver(polostar_driver, hid_register_driver, hid_unregister_driver); > > MODULE_LICENSE("GPL"); > MODULE_VERSION("5"); BTW, can you make pull requests to digimend-kernel-drivers instead of sending files? Thank you. Nick |
|
From: Dan R. <ade...@gm...> - 2015-02-22 03:17:57
|
dan@REDACTEDHOSTNAME:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech G700 Laser Mouse id=11 [slave pointer (2)]
⎜ ↳ Logitech G700 Laser Mouse id=10 [slave pointer (2)]
⎜ ↳ HV 10594 id=13 [slave pointer (2)]
⎜ ↳ HV 10594 id=14 [slave pointer (2)]
⎜ ↳ HV 10594 id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ CM Storm Quick Fire PRO Keyboard id=9 [slave keyboard (3)]
↳ CM Storm Quick Fire PRO Keyboard id=8 [slave keyboard (3)]
↳ Eee PC WMI hotkeys id=12 [slave keyboard (3)]
dan@REDACTEDHOSTNAME:~$ xinput list-props 13
Device 'HV 10594':
Device Enabled (135): 1
Coordinate Transformation Matrix (137): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (263): 0
Device Accel Constant Deceleration (264): 1.000000
Device Accel Adaptive Deceleration (265): 1.000000
Device Accel Velocity Scaling (266): 10.000000
Device Product ID (252): 9580, 110
Device Node (253): "/dev/input/event17"
Evdev Axis Inversion (267): 0, 0
Evdev Axis Calibration (268): <no items>
Evdev Axes Swap (269): 0
Axis Labels (270): "Abs X" (338), "Abs Y" (339), "Abs Pressure" (340), "Rel Horiz Wheel" (261), "Rel Vert Wheel" (262)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Evdev Scrolling Distance (272): 1, 1, 1
Evdev Middle Button Emulation (273): 0
Evdev Middle Button Timeout (274): 50
Evdev Third Button Emulation (275): 0
Evdev Third Button Emulation Timeout (276): 1000
Evdev Third Button Emulation Button (277): 3
Evdev Third Button Emulation Threshold (278): 20
Evdev Wheel Emulation (279): 0
Evdev Wheel Emulation Axes (280): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (281): 10
Evdev Wheel Emulation Timeout (282): 200
Evdev Wheel Emulation Button (283): 4
Evdev Drag Lock Buttons (284): 0
dan@REDACTEDHOSTNAME:~$ xinput list-props 14
Device 'HV 10594':
Device Enabled (135): 1
Coordinate Transformation Matrix (137): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (263): 0
Device Accel Constant Deceleration (264): 1.000000
Device Accel Adaptive Deceleration (265): 1.000000
Device Accel Velocity Scaling (266): 10.000000
Device Product ID (252): 9580, 110
Device Node (253): "/dev/input/event16"
Evdev Axis Inversion (267): 0, 0
Evdev Axis Calibration (268): <no items>
Evdev Axes Swap (269): 0
Axis Labels (270): "Abs X" (338), "Abs Y" (339), "Abs Z" (566), "Abs Rotary X" (567), "Abs Pressure" (340)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Evdev Scrolling Distance (272): 0, 0, 0
Evdev Middle Button Emulation (273): 0
Evdev Middle Button Timeout (274): 50
Evdev Third Button Emulation (275): 0
Evdev Third Button Emulation Timeout (276): 1000
Evdev Third Button Emulation Button (277): 3
Evdev Third Button Emulation Threshold (278): 20
Evdev Wheel Emulation (279): 0
Evdev Wheel Emulation Axes (280): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (281): 10
Evdev Wheel Emulation Timeout (282): 200
Evdev Wheel Emulation Button (283): 4
Evdev Drag Lock Buttons (284): 0
dan@REDACTEDHOSTNAME:~$ xinput list-props 15
Device 'HV 10594':
Device Enabled (135): 1
Coordinate Transformation Matrix (137): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (263): 0
Device Accel Constant Deceleration (264): 1.000000
Device Accel Adaptive Deceleration (265): 1.000000
Device Accel Velocity Scaling (266): 10.000000
Device Product ID (252): 9580, 110
Device Node (253): "/dev/input/event18"
Evdev Axis Inversion (267): 0, 0
Evdev Axes Swap (269): 0
Axis Labels (270): "Rel X" (145), "Rel Y" (146), "Rel Horiz Wheel" (261)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Evdev Scrolling Distance (272): 1, 1, 1
Evdev Middle Button Emulation (273): 0
Evdev Middle Button Timeout (274): 50
Evdev Third Button Emulation (275): 0
Evdev Third Button Emulation Timeout (276): 1000
Evdev Third Button Emulation Button (277): 3
Evdev Third Button Emulation Threshold (278): 20
Evdev Wheel Emulation (279): 0
Evdev Wheel Emulation Axes (280): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (281): 10
Evdev Wheel Emulation Timeout (282): 200
Evdev Wheel Emulation Button (283): 4
Evdev Drag Lock Buttons (284): 0
dan@REDACTEDHOSTNAME:~$ xinput list-props 15 | grep "Button Labels"
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props 13 | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
dan@REDACTEDHOSTNAME:~$ xinput list-props 14 | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
dan@REDACTEDHOSTNAME:~$ xinput list-props 15 | grep "Button Labels"
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
unable to find device 13
unable to find device 14
unable to find device 15
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
dan@REDACTEDHOSTNAME:~$ dmesg -T | tail
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004B: Ignoring interface 1
[Sat Feb 21 17:46:35 2015] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.1/input/input74
[Sat Feb 21 17:46:35 2015] uclogic 0003:256C:006E.004B: input,hiddev0,hidraw5: USB HID v1.11 Mouse [HV 10594] on usb-0000:00:16.0-1/input1
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: Interface: 2 Product: 110
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: Interface Number: 2
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: got 14 byte string descriptor
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: Resolution: 40000x25000 Pressure: 2047
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: tablet enable succeeded.
[Sat Feb 21 17:46:35 2015] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.2/input/input75
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: input,hidraw6: USB HID v1.11 Keyboard [HV 10594] on usb-0000:00:16.0-1/input2
dan@REDACTEDHOSTNAME:~$ dmesg -T | tail
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004B: Ignoring interface 1
[Sat Feb 21 17:46:35 2015] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.1/input/input74
[Sat Feb 21 17:46:35 2015] uclogic 0003:256C:006E.004B: input,hiddev0,hidraw5: USB HID v1.11 Mouse [HV 10594] on usb-0000:00:16.0-1/input1
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: Interface: 2 Product: 110
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: Interface Number: 2
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: got 14 byte string descriptor
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: Resolution: 40000x25000 Pressure: 2047
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: tablet enable succeeded.
[Sat Feb 21 17:46:35 2015] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.2/input/input75
[Sat Feb 21 17:46:35 2015] huion 0003:256C:006E.004C: input,hidraw6: USB HID v1.11 Keyboard [HV 10594] on usb-0000:00:16.0-1/input2
dan@REDACTEDHOSTNAME:~$ dmesg -T | tail
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004B: Ignoring interface 1
[Sat Feb 21 17:46:34 2015] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.1/input/input74
[Sat Feb 21 17:46:34 2015] uclogic 0003:256C:006E.004B: input,hiddev0,hidraw5: USB HID v1.11 Mouse [HV 10594] on usb-0000:00:16.0-1/input1
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004C: Interface: 2 Product: 110
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004C: Interface Number: 2
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004C: got 14 byte string descriptor
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004C: Resolution: 40000x25000 Pressure: 2047
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004C: tablet enable succeeded.
[Sat Feb 21 17:46:34 2015] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.2/input/input75
[Sat Feb 21 17:46:34 2015] huion 0003:256C:006E.004C: input,hidraw6: USB HID v1.11 Keyboard [HV 10594] on usb-0000:00:16.0-1/input2
dan@REDACTEDHOSTNAME:~$ echo "didn't work, replugging"
didn't work, replugging
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ echo "Worked. replugging"
Worked. replugging
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
dan@REDACTEDHOSTNAME:~$ echo "Didn't work, replugging."
Didn't work, replugging.
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
dan@REDACTEDHOSTNAME:~$ echo "Worked."
Worked.
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ dmesg | tail
[333956.485089] huion 0003:256C:006E.0057: Ignoring interface 1
[333956.485450] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.1/input/input86
[333956.485680] uclogic 0003:256C:006E.0057: input,hiddev0,hidraw5: USB HID v1.11 Mouse [HV 10594] on usb-0000:00:16.0-1/input1
[333956.489079] huion 0003:256C:006E.0058: Interface: 2 Product: 110
[333956.489087] huion 0003:256C:006E.0058: Interface Number: 2
[333956.490981] huion 0003:256C:006E.0058: got 14 byte string descriptor
[333956.490989] huion 0003:256C:006E.0058: Resolution: 40000x25000 Pressure: 2047
[333956.490994] huion 0003:256C:006E.0058: tablet enable succeeded.
[333956.495209] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.2/input/input87
[333956.495388] huion 0003:256C:006E.0058: input,hidraw6: USB HID v1.11 Keyboard [HV 10594] on usb-0000:00:16.0-1/input2
dan@REDACTEDHOSTNAME:~$ echo "Worked"
Worked
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
dan@REDACTEDHOSTNAME:~$ dmesg | tail
[334053.536553] huion 0003:256C:006E.005A: Ignoring interface 1
[334053.536912] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.1/input/input89
[334053.537149] uclogic 0003:256C:006E.005A: input,hiddev0,hidraw5: USB HID v1.11 Mouse [HV 10594] on usb-0000:00:16.0-1/input1
[334053.540537] huion 0003:256C:006E.005B: Interface: 2 Product: 110
[334053.540544] huion 0003:256C:006E.005B: Interface Number: 2
[334053.542445] huion 0003:256C:006E.005B: got 14 byte string descriptor
[334053.542454] huion 0003:256C:006E.005B: Resolution: 40000x25000 Pressure: 2047
[334053.542458] huion 0003:256C:006E.005B: tablet enable succeeded.
[334053.546660] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.2/input/input90
[334053.546848] huion 0003:256C:006E.005B: input,hidraw6: USB HID v1.11 Keyboard [HV 10594] on usb-0000:00:16.0-1/input2
dan@REDACTEDHOSTNAME:~$ echo "Worked"
Worked
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
dan@REDACTEDHOSTNAME:~$ xinput list-props {13..15} | grep "Button Labels"
Button Labels (271): "Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)
Button Labels (271): "Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
dan@REDACTEDHOSTNAME:~$ dmesg | tail
[334115.142885] huion 0003:256C:006E.0060: Ignoring interface 1
[334115.143261] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.1/input/input95
[334115.143403] uclogic 0003:256C:006E.0060: input,hiddev0,hidraw5: USB HID v1.11 Mouse [HV 10594] on usb-0000:00:16.0-1/input1
[334115.146874] huion 0003:256C:006E.0061: Interface: 2 Product: 110
[334115.146882] huion 0003:256C:006E.0061: Interface Number: 2
[334115.148774] huion 0003:256C:006E.0061: got 14 byte string descriptor
[334115.148782] huion 0003:256C:006E.0061: Resolution: 40000x25000 Pressure: 2047
[334115.148787] huion 0003:256C:006E.0061: tablet enable succeeded.
[334115.153008] input: HV 10594 as /devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.2/input/input96
[334115.153139] huion 0003:256C:006E.0061: input,hidraw6: USB HID v1.11 Keyboard [HV 10594] on usb-0000:00:16.0-1/input2
dan@REDACTEDHOSTNAME:~$ echo "Didn't work."
Didn't work. |
|
From: Peter H. <pet...@wh...> - 2015-02-20 05:35:11
|
On Thu, Feb 19, 2015 at 01:54:17PM +0200, Nikolai Kondrashov wrote: [...] > >>>Last, I think we could add these tablets in the libwacom project, so that there > >>>will be a nice GUI to configure the buttons. > >> > >>That would be a very welcome change, without doubt, thank you. > >> > >>However, I can't help wondering, would it be more productive to allow libwacom > >>to work with just any basic tablet, without the need to add each one to the > >>database? > > > >Actually, libwacom is not tight to Wacom devices at all (or should not > >be). It is just a database of devices to add what the kernel doesn't or > >can not provide. The things that are in the db are for example how the > >buttons are physically mapped on the device, what is the actual layout > >(one svg file), if there are LEDs attached to the tablet. > > > >All this needs a fine per-device tuning. We can add a generic > >Huion/UClogic tablet too, but having a specific per-device definition > >allows to show the exact mapping of the buttons on the overlay when > >setting the functions. > > I agree, that's a nice feature. However, I think being able to configure all > the applicable Wacom driver features relatively comfortably, even if the > tablet on screen doesn't exactly match your tablet, is still a win, compared > to not being able to do it. > > For the unknown tablets we can just draw abstract tablets, emphasising that > control locations on the screen don't map to the actual locations. For > example, have the tablet drawn like an exploded diagram: surface, buttons, > dials - all separate. Something like this: > > Buttons: * * * * * * * > Dials: O O > Work area: +------------+ > | | > | | > | | > +------------+ > > I think the users will be able to figure out the mapping by experimentation. > > While it's just about possible to keep an up-to-date database of Wacom > tablets, I don't think we'll ever be able to list all those generic tablets > out there. Meanwhile a lot of people are left in the cold of xsetwacom and > xinput. not a reason to give up, IMO. most of these generic tablets are relatively simple, so adding a libwacom entry should be a matter of minutes. we'll never get full support of everything, but perfect is the enemy of good here. Cheers, Peter |
|
From: Yann V. <yan...@or...> - 2015-02-19 16:47:46
|
> The attached version uses pick, and thus reports (using input-events) stylus > for the side button closer to the tip and stylus2 for the one further away. Upon a moment more testing, I think those two usages might be better swapped, for consistency with the mouse mode. Or perhaps the mouse mode should have the swap for consistency with other tablets. Right now the buttons swap meaning between mouse and stylus modes. |
|
From: Yann V. <yan...@or...> - 2015-02-19 16:19:32
|
On Sat, 31 Jan 2015 12:35:28 +0200 Nikolai Kondrashov <sp...@gm...> wrote: > The code looks fine to me, but I have a few comments on the report descriptor. > > I think it is better to omit report ID's, features and fields that are not > used by the driver, for clarity. > > Physical extents are useless without units and probably don't even apply to > some usages below, like resolution multiplier, so it's better to remove them. > However, adding the units, unit exponent and physical extents to the pen > coordinates is useful. The result will be visible in "evtest" output and > likely used by Wayland. Okay. > I'm not sure how repeated report ID items in a single collection even work. > Also duplicate report IDs sound fishy. All-in-all, this is some really weird > report descriptor and would be difficult to reason about. I would start from > scratch, taking one of the fixed report descriptors from other tablets and > adjusting it to the bit fields this one reports. I think it's some sort of indirect description, applying resolution multipliers to the preexisting report 1, so as not to confuse the boot protocol interpretation. However, I have not gotten the device to send the multiplier reports, and Linux seems to happily ignore them. > > /* I expect patching in these values (from interface 2) > > would get Xorg to use tablet mode: */ > > 0x09, 0x42, /* Usage (Tip Switch), */ > > 0x09, 0x44, /* Usage (Barrel Switch), */ > > 0x09, 0x45, /* Usage (Eraser), */ /* Really on the barrel too */ > > I suggest to use "Tablet Pick" here. I added it to the kernel and use it for > the second barrel button on all of the tablets. It will map to the third > button. Certainly. Since this is a patch driver for Linux anyway, convention there takes priority. I don't know if other tablets also abuse eraser like this. > > /* The original usages should have mapped to mouse buttons, but Linux > > happily reports them as buttons 10-12. */ > > /* 0x05, 0x0f, / * Usage Page (Button), */ > > /* 0x19, 0x01, / * Usage Minimum (01h), */ > > /* 0x29, 0x03, / * Usage Maximum (03h), */ > > /* End of Stylus button usage */ > > I think having six usages and only three reports wouldn't work. Those were simply commented out versions of what the device originally sent. > > 0x15, 0x00, /* Logical Minimum (0), */ > > 0x25, 0x01, /* Logical Maximum (1), */ > > 0x95, 0x03, /* Report Count (3), */ > > 0x75, 0x01, /* Report Size (1), */ > > 0x81, 0x02, /* Input (Variable), */ > > 0x95, 0x05, /* Report Count (5), */ > > 0x81, 0x01, /* Input (Constant), */ > > 0x05, 0x01, /* Usage Page (Desktop), */ > > 0x09, 0x30, /* Usage (X), */ > > 0x09, 0x31, /* Usage (Y), */ > > 0x15, 0x00, /* Logical Minimum (0), */ > > 0x26, 0x00, 0x10, /* Logical Maximum (4096), */ > > 0x35, 0x00, /* Physical Minimum (0), */ > > 0x46, 0x00, 0x10, /* Physical Maximum (4096), */ > > Is the actual physical drawing area square? No. I believe it's meant to be 16:10 proportions. A quick measurement by the printed border shows: X: inner 103.65mm, outer 105mm Y: inner 65.6mm, outer 66.45mm This gives an aspect ratio somewhere from 1.56 to 1.60. Measuring the firmware limits would be a bit harder (for instance, it doesn't measure the tip but the coil position). I guess 105.6*66mm would be a reasonable approximation. I have tried to put this data into the attached descriptor. It would also be a little tricky to measure the unit of pressure, so I took the push/pop example from one of the uc-logic descriptors. The attached version uses pick, and thus reports (using input-events) stylus for the side button closer to the tip and stylus2 for the one further away. It was tested to work smoothly in inkscape and krita. Since it overrides the descriptor it doesn't care about the readout bugs, so it works on its own (but still requires the unbinding of hid-generic from the relevant interface). http://www.nybytt.se/zeniq-pen-tablet/ is a clear example of one of these tablets. Mine happen to have the Leogics brand instead. |
|
From: Nikolai K. <sp...@gm...> - 2015-02-19 11:54:27
|
On 02/18/2015 10:04 PM, Benjamin Tissoires wrote:
> On Feb 18 2015 or thereabouts, Nikolai Kondrashov wrote:
>> Hi Benjamin,
>>
>> I'm copying my reply to DIGImend-devel as well.
>>
>> On 02/18/2015 12:54 AM, Benjamin Tissoires wrote:
>>> Hi Nikolai,
>>>
>>> I know you are actually merging hid-huion and hid-uclogic, so we might not want
>>> to take this in this current state. We may need to postpone it when you have
>>> send the merge.
>>
>> I have it in the out-of-tree driver package [1], which I'll need to release
>> for users to test first.
>>
>>> This series makes the Huion tablet (a H610 Pro) behave like a Wacom one from the
>>> libinput point of view.
>>> It will introduce a change in the default behavior for the users (which I
>>> believe is a good change) where the pad part of the tablet will not send
>>> random keyboard shortcuts but actual button events.
>>
>> That's awesome, thanks a lot, Benjamin! I tried making something like that
>> [2], which seems to work reasonably. However, I was not up-to-date with
>> libinput changes and left the buttons in the same device with the pen. Then I
>> heard about input groups from Hans and planned to re-make it properly, but now
>> you did it. Thanks!
>
> Hmm... I should have checked more carefully your branches. I actually
> redid the reverse engineering and ended up with nearly the same patch
> you already have :)
>
> Sorry for not including you in the loop earlier. We were actually really
> focused on Wacom for the past few months and decided to look into the
> Huion and other tablets only last week.
No problem, I wasn't keeping up with your development myself as I should have.
> I believe not having the pad buttons separated in the huion tablets is not
> that much of a problem (for now, the buttons are quite separate from the
> stylus buttons), but in the Wacom world, we had some terrible overlapping
> and making those as 2 separate devices was the obvious change.
I think this is a good change, which will hopefully make things simpler.
>>> I'd be glad if you could validate the changes with the other huions you have
>>> (or the Digimend project), because, having only one PID for all their tablets
>>> is rather weird and difficult to support.
>>
>> I'll have to incorporate them into the out-of-tree driver [1] to simplify
>> testing for users. I'll leave some comments to the changes as well, if you
>> don't mind.
>
> Sure, no problem.
>
>>
>> Of course, it would help a lot, if you could contribute your patches to the
>> out-of-tree driver, from where we could then take them to upstream, after
>> testing. I can do it myself, though.
>
> OK, will respin the patches for your out of the tree driver.
Thanks a lot, Benjamin!
>>> Last, I think we could add these tablets in the libwacom project, so that there
>>> will be a nice GUI to configure the buttons.
>>
>> That would be a very welcome change, without doubt, thank you.
>>
>> However, I can't help wondering, would it be more productive to allow libwacom
>> to work with just any basic tablet, without the need to add each one to the
>> database?
>
> Actually, libwacom is not tight to Wacom devices at all (or should not
> be). It is just a database of devices to add what the kernel doesn't or
> can not provide. The things that are in the db are for example how the
> buttons are physically mapped on the device, what is the actual layout
> (one svg file), if there are LEDs attached to the tablet.
>
> All this needs a fine per-device tuning. We can add a generic
> Huion/UClogic tablet too, but having a specific per-device definition
> allows to show the exact mapping of the buttons on the overlay when
> setting the functions.
I agree, that's a nice feature. However, I think being able to configure all
the applicable Wacom driver features relatively comfortably, even if the
tablet on screen doesn't exactly match your tablet, is still a win, compared
to not being able to do it.
For the unknown tablets we can just draw abstract tablets, emphasising that
control locations on the screen don't map to the actual locations. For
example, have the tablet drawn like an exploded diagram: surface, buttons,
dials - all separate. Something like this:
Buttons: * * * * * * *
Dials: O O
Work area: +------------+
| |
| |
| |
+------------+
I think the users will be able to figure out the mapping by experimentation.
While it's just about possible to keep an up-to-date database of Wacom
tablets, I don't think we'll ever be able to list all those generic tablets
out there. Meanwhile a lot of people are left in the cold of xsetwacom and
xinput.
>>> However, not having the PID to discriminate between tablets is going to be a
>>> problem. Do you have any reliable way of knowing the model from the kernel
>>> or the user space?
>>
>> Unfortunately, not. You can take a look at the data I and the users gathered
>> on some of the Huion tablets [3]. The iProduct string can be used to some
>> extent, but I wouldn't rely on it to make much sense. Apart from Huion
>> tablets, there are also Yiynova tablets which work the same way, at least some
>> Ugee tablets and at least one UC-Logic tablet, but I expect more of the latter
>> work as well. Among them there is a mix of using dedicated and UC-Logic VIDs
>> and mostly reusing PIDs. There is something which seems to be an internal
>> model name in string descriptor 0x7a, but it also doesn't make much sense.
>>
>> All-in-all it's a mess. I've even seen a tablet with a typo in iManufacturer.
>>
>> Still, if we make libwacom work with generic tablets not contained in its
>> database, that wouldn't be a problem.
>
> I'll see what I can do. However, it looks like the iProduct and
> iManufacturer could help to some extend (until we find a big problem). I
> thought they were all labeled "HUION PenTablet" but actually only the
> H610 Pro and the Huion W58 share this name. The W58 does not have
> buttons so we night be able to remove the pad interface for them and
> then libwacom will be happy with only the name of the input node.
Yes it will work for some of them. I have no idea what numerous other models
have in their descriptors, though.
Nick
|
|
From: Nikolai K. <sp...@gm...> - 2015-02-19 11:37:34
|
On 02/18/2015 10:24 PM, Benjamin Tissoires wrote:
> On Feb 18 2015 or thereabouts, Nikolai Kondrashov wrote:
>> On 02/18/2015 12:54 AM, Benjamin Tissoires wrote:
>>> diff --git a/drivers/hid/hid-huion.c b/drivers/hid/hid-huion.c
>>> index 61b68ca..50fbda4 100644
>>> --- a/drivers/hid/hid-huion.c
>>> +++ b/drivers/hid/hid-huion.c
>>> @@ -34,6 +34,9 @@ enum huion_ph_id {
>>> HUION_PH_ID_NUM
>>> };
>>>
>>> +/* header of a button report sent through the Pen report */
>>> +static const u8 button_report[] = {0x07, 0xa0, 0x01, 0x01};
>>
>> Hmm, I see the second byte being 0xe0 on Huion H610, the rest is the same.
>> Considering this, the fact that bit 7 is always 1 and bit 6 is pen proximity,
>> I think we can assume that bit 5 in byte 2 indicates button reports and get
>> away with just a "data[1] & 0x20" test.
>
> that would be a nicer approach. Thanks for the analysis.
> Actually, I understood the difference. I tested the bits _after_ the
> driver reverts the in-range bit :)
Ah, I missed that.
> The raw data is {0x07, 0xe0, 0x01, 0x01} on the H610 Pro too.
That's good, less weirdness to handle :)
>>> /* Report descriptor template placeholder */
>>> #define HUION_PH(_ID) HUION_PH_HEAD, HUION_PH_ID_##_ID
>>>
>>> @@ -81,6 +84,31 @@ static const __u8 huion_tablet_rdesc_template[] = {
>>> HUION_PH(PRESSURE_LM), /* Logical Maximum (PLACEHOLDER), */
>>> 0x81, 0x02, /* Input (Variable), */
>>> 0xC0, /* End Collection, */
>>> + 0x05, 0x01, /* Usage Page (Desktop) */
>>> + 0x09, 0x07, /* Usage (Keypad) */
>>> + 0xa1, 0x01, /* Collection (Application) */
>>> + 0x85, 0x08, /* Report ID (8) */
>>> + 0x05, 0x0d, /* Usage Page (Digitizers) */
>>> + 0x09, 0x22, /* Usage (Finger) */
>>
>> I'd say "Finger" usage is wrong here. The spec says:
>>
>> Finger
>>
>> CL – Any human appendage used as a transducer, such as a finger
>> touching a touch screen to set the location of the screen cursor. A
>> digitizer typically reports the coordinates of center of the finger.
>> In the Finger collection a Pointer physical collection will contain
>> the axes reported by the finger.
>>
>> I.e. the buttons are not a pointing device. The specification contains another
>> collection usage which seems more suitable:
>>
>> Tablet Function Keys
>>
>> CL – These controls are located on the surface of a digitizing tablet,
>> and may be implemented as actual switches, or as soft keys actuated by
>> the digitizing transducer. These are often used to trigger
>> location-independent macros or other events.
>
> Actually, the kernel knows about it: HID_DG_TABLETFUNCTIONKEY.
> I don't think it should influence to have it set. The hid processing
> would work on the BTN usages, not on the physical.
>
> [5 min later]
>
> yep, just works :)
Cool :)!
>> However the kernel doesn't seem to know anything about it (but we can fix
>> that). In my version of this I simply used a keyboard with buttons:
>>
>> 0x05, 0x01, /* Usage Page (Desktop), */
>> 0x09, 0x06, /* Usage (Keyboard), */
>> 0xA1, 0x01, /* Collection (Application), */
>> 0x85, 0xF7, /* Report ID (247), */
>> 0x05, 0x09, /* Usage Page (Button), */
>> 0x75, 0x01, /* Report Size (1), */
>> 0x95, 0x18, /* Report Count (24), */
>> 0x81, 0x03, /* Input (Constant, Variable), */
>> 0x19, 0x01, /* Usage Minimum (01h), */
>> 0x29, 0x08, /* Usage Maximum (08h), */
>> 0x95, 0x08, /* Report Count (8), */
>> 0x81, 0x02, /* Input (Variable), */
>> 0xC0 /* End Collection */
>>
>> Although it might not be entirely correct either.
>
> Even if no-one but hid-core uses the report descriptor, I would rather
> not declare ourself as a keyboard. It's shooting on our own foot if
> someone decides to actually merge a keyboard and a tablet.
Yes, I think you're right.
>>> + 0xa0, /* Collection (Physical) */
>>> + 0x14, /* Logical Minimum (0) */
>>> + 0x25, 0x01, /* Logical Maximum (1) */
>>> + 0x75, 0x08, /* Report Size (8) */
>>> + 0x95, 0x03, /* Report Count (3) */
>>> + 0x81, 0x03, /* Input (Cnst,Var,Abs) */
>>> + 0x05, 0x09, /* Usage Page (Button) */
>>> + 0x19, 0x01, /* Usage Minimum (1) */
>>> + 0x29, 0x08, /* Usage Maximum (8) */
>>> + 0x14, /* Logical Minimum (0) */
>>> + 0x25, 0x01, /* Logical Maximum (1) */
>>> + 0x75, 0x01, /* Report Size (1) */
>>> + 0x95, 0x08, /* Report Count (8) */
>>> + 0x81, 0x02, /* Input (Data,Var,Abs) */
>>> + 0x75, 0x08, /* Report Size (8) */
>>> + 0x95, 0x03, /* Report Count (3) */
>>> + 0x81, 0x03, /* Input (Cnst,Var,Abs) */
>>> + 0xc0, /* End Collection */
>>> + 0xc0, /* End Collection */
>>
>> Which tool did you use to generate this?
>
> My own custom-made:
> https://github.com/bentiss/hid-replay/blob/master/tools/editor.py
>
> not 100% implemented, but it works for me :)
Ah, nice :) Here is mine: https://github.com/DIGImend/hidrd
>>> 0xC0 /* End Collection */
>>> };
>>>
>>> @@ -205,6 +233,25 @@ static int huion_tablet_enable(struct hid_device *hdev)
>>> }
>>> }
>>>
>>> + /* switch to the button mode reporting */
>>> + rc = usb_control_msg(usb_dev, usb_rcvctrlpipe(usb_dev, 0),
>>> + USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
>>> + (USB_DT_STRING << 8) + 0x7b,
>>> + 0x0409, buf, len,
>>> + USB_CTRL_GET_TIMEOUT);
>>
>> I'm a bit uncomfortable about reusing a buffer which was sized specifically
>> for another task, as it's confusing. But it will work as is, so it's OK.
>
> Yes, and no :)
>
> Actually, I would prefer that we stick to what the Windows driver do.
> But it requests 32 bytes in each requests, and we receive 14 and 22
> IIRC. The trick I exploited here is that the ctrl message answers back
> at most len data, so we are find in both cases because 12 is less than
> 14 and 22. I am not sure we should check at all the length of the
> returning buffer (though for the first command, we have to be sure that
> we received enough to get the values in the buffer).
In that case, if we want to mimic the Windows driver we can request 32 bytes
always and do a compile-time check that our parameters fit into that.
> Side note: the huion-abstract-keyboard branch uses usb_string() instead
> of a plain usb_control_msg(). I like this much better and I think we
> should change the first call with that. This way, it will be clear that
> the tablet is not fully HID compatible and that we need to keep the usb
> access.
No, we can't do that to the parameters string, because usb_string() does
utf16s_to_utf8s on the received data.
>>> + /* check for buttons events and change the report ID */
>>> + if (size >= sizeof(button_report) &&
>>> + !memcmp(data, button_report, sizeof(button_report)))
>>
>> So, yes, I think it's better to have a "data[1] & 0x20" test here instead.
>
> Yep, works just fine.
Nice :)
Nick
|
|
From: Benjamin T. <ben...@re...> - 2015-02-18 20:25:37
|
On Feb 18 2015 or thereabouts, Nikolai Kondrashov wrote:
> On 02/18/2015 12:54 AM, Benjamin Tissoires wrote:
> >@@ -81,6 +84,31 @@ static const __u8 huion_tablet_rdesc_template[] = {
> > HUION_PH(PRESSURE_LM), /* Logical Maximum (PLACEHOLDER), */
> > 0x81, 0x02, /* Input (Variable), */
> > 0xC0, /* End Collection, */
> >+ 0x05, 0x01, /* Usage Page (Desktop) */
> >+ 0x09, 0x07, /* Usage (Keypad) */
> >+ 0xa1, 0x01, /* Collection (Application) */
> >+ 0x85, 0x08, /* Report ID (8) */
>
> Oh, and it's probably safer to have a higher-number report ID in case some
> tablets use it for something else.
>
makes sense. Will amend.
Cheers,
Benjamin
> >+ 0x05, 0x0d, /* Usage Page (Digitizers) */
> >+ 0x09, 0x22, /* Usage (Finger) */
> >+ 0xa0, /* Collection (Physical) */
> >+ 0x14, /* Logical Minimum (0) */
> >+ 0x25, 0x01, /* Logical Maximum (1) */
> >+ 0x75, 0x08, /* Report Size (8) */
> >+ 0x95, 0x03, /* Report Count (3) */
> >+ 0x81, 0x03, /* Input (Cnst,Var,Abs) */
> >+ 0x05, 0x09, /* Usage Page (Button) */
> >+ 0x19, 0x01, /* Usage Minimum (1) */
> >+ 0x29, 0x08, /* Usage Maximum (8) */
> >+ 0x14, /* Logical Minimum (0) */
> >+ 0x25, 0x01, /* Logical Maximum (1) */
> >+ 0x75, 0x01, /* Report Size (1) */
> >+ 0x95, 0x08, /* Report Count (8) */
> >+ 0x81, 0x02, /* Input (Data,Var,Abs) */
> >+ 0x75, 0x08, /* Report Size (8) */
> >+ 0x95, 0x03, /* Report Count (3) */
> >+ 0x81, 0x03, /* Input (Cnst,Var,Abs) */
> >+ 0xc0, /* End Collection */
> >+ 0xc0, /* End Collection */
> > 0xC0 /* End Collection */
> > };
>
> Nick
|
|
From: Benjamin T. <ben...@re...> - 2015-02-18 20:04:33
|
On Feb 18 2015 or thereabouts, Nikolai Kondrashov wrote: > Hi Benjamin, > > I'm copying my reply to DIGImend-devel as well. > > On 02/18/2015 12:54 AM, Benjamin Tissoires wrote: > >Hi Nikolai, > > > >I know you are actually merging hid-huion and hid-uclogic, so we might not want > >to take this in this current state. We may need to postpone it when you have > >send the merge. > > I have it in the out-of-tree driver package [1], which I'll need to release > for users to test first. > > >This series makes the Huion tablet (a H610 Pro) behave like a Wacom one from the > >libinput point of view. > >It will introduce a change in the default behavior for the users (which I > >believe is a good change) where the pad part of the tablet will not send > >random keyboard shortcuts but actual button events. > > That's awesome, thanks a lot, Benjamin! I tried making something like that > [2], which seems to work reasonably. However, I was not up-to-date with > libinput changes and left the buttons in the same device with the pen. Then I > heard about input groups from Hans and planned to re-make it properly, but now > you did it. Thanks! Hmm... I should have checked more carefully your branches. I actually redid the reverse engineering and ended up with nearly the same patch you already have :) Sorry for not including you in the loop earlier. We were actually really focused on Wacom for the past few months and decided to look into the Huion and other tablets only last week. I believe not having the pad buttons separated in the huion tablets is not that much of a problem (for now, the buttons are quite separate from the stylus buttons), but in the Wacom world, we had some terrible overlapping and making those as 2 separate devices was the obvious change. > > >I'd be glad if you could validate the changes with the other huions you have > >(or the Digimend project), because, having only one PID for all their tablets > >is rather weird and difficult to support. > > I'll have to incorporate them into the out-of-tree driver [1] to simplify > testing for users. I'll leave some comments to the changes as well, if you > don't mind. Sure, no problem. > > Of course, it would help a lot, if you could contribute your patches to the > out-of-tree driver, from where we could then take them to upstream, after > testing. I can do it myself, though. OK, will respin the patches for your out of the tree driver. > > >Last, I think we could add these tablets in the libwacom project, so that there > >will be a nice GUI to configure the buttons. > > That would be a very welcome change, without doubt, thank you. > > However, I can't help wondering, would it be more productive to allow libwacom > to work with just any basic tablet, without the need to add each one to the > database? Actually, libwacom is not tight to Wacom devices at all (or should not be). It is just a database of devices to add what the kernel doesn't or can not provide. The things that are in the db are for example how the buttons are physically mapped on the device, what is the actual layout (one svg file), if there are LEDs attached to the tablet. All this needs a fine per-device tuning. We can add a generic Huion/UClogic tablet too, but having a specific per-device definition allows to show the exact mapping of the buttons on the overlay when setting the functions. > > >However, not having the PID to discriminate between tablets is going to be a > >problem. Do you have any reliable way of knowing the model from the kernel > >or the user space? > > Unfortunately, not. You can take a look at the data I and the users gathered > on some of the Huion tablets [3]. The iProduct string can be used to some > extent, but I wouldn't rely on it to make much sense. Apart from Huion > tablets, there are also Yiynova tablets which work the same way, at least some > Ugee tablets and at least one UC-Logic tablet, but I expect more of the latter > work as well. Among them there is a mix of using dedicated and UC-Logic VIDs > and mostly reusing PIDs. There is something which seems to be an internal > model name in string descriptor 0x7a, but it also doesn't make much sense. > > All-in-all it's a mess. I've even seen a tablet with a typo in iManufacturer. > > Still, if we make libwacom work with generic tablets not contained in its > database, that wouldn't be a problem. I'll see what I can do. However, it looks like the iProduct and iManufacturer could help to some extend (until we find a big problem). I thought they were all labeled "HUION PenTablet" but actually only the H610 Pro and the Huion W58 share this name. The W58 does not have buttons so we night be able to remove the pad interface for them and then libwacom will be happy with only the name of the input node. Cheers, Benjamin > > Nick > > [1] https://github.com/DIGImend/digimend-kernel-drivers > [2] https://github.com/DIGImend/digimend-kernel-drivers/blob/huion-abstract-keyboard/hid-huion.c > [3] https://github.com/DIGImend/tablets |
38 messages has been excluded from this view by a project administrator.
