Re: [PATCH v2 6/6] HID: uclogic: actually invert the in-range bit for huion tablets only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/03/2015 12:25 AM, Benjamin Tissoires wrote:
On Feb 28 2015 or thereabouts, Nikolai Kondrashov wrote:
On 02/26/2015 08:57 PM, Benjamin Tissoires wrote:
This hack is only needed for Huion tablets. It does not seem to have
any effect on the other tablets handled by this device right now, but
it's better to check for the product id sooner than discovering that
we have messed up one tablet later.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
---

New in v2

  drivers/hid/hid-uclogic.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-uclogic.c b/drivers/hid/hid-uclogic.c
index f44e72b..5f5c16e 100644
--- a/drivers/hid/hid-uclogic.c
+++ b/drivers/hid/hid-uclogic.c
@@ -930,7 +930,8 @@ static int uclogic_raw_event(struct hid_device *hdev, struct hid_report *report,
  	struct usb_interface *intf = to_usb_interface(hdev->dev.parent);

  	/* If this is a pen input report */
-	if (intf->cur_altsetting->desc.bInterfaceNumber == 0 &&
+	if (hdev->product == USB_DEVICE_ID_HUION_TABLET &&
+	    intf->cur_altsetting->desc.bInterfaceNumber == 0 &&
  	    report->type == HID_INPUT_REPORT &&
  	    report->id == 0x07 && size >= 2)
  		/* Invert the in-range bit */

Right, I completely forgot about this. That's why it's important to put these
things out for testing.

yes, and no. A thorough review can help detect these while it's a pain
to ask each and every users to test every possible device :)

Perhaps :)

However, this should be inverted not just for Huion tablets, but rather for
all "enabled" tablets. The UC-Logic TWHA60 v3 inverts that bit as well when
enabled, IIRC. We can filter enabled tablets by drvdata->rdesc != NULL, or add
an explicit flag.

I like the flag. It will remove the dependency to usb in raw_event()
which is always a plus.

Great!

Speaking of which. I started looking at these dependencies in the hid
subtree (like every year, in spring, these dependencies itches me).
I think we can find a preventive solution which would allow to reinject
through uhid any device even if the driver wants to talk to the usb
layer. This will require some more effort on my side but will allow us
to have at least some regressions tests in hid-uclogic too.

This sounds good. I was thinking about record/replay on HID level over uhid,
similar to evdev level, but as usual didn't have time to even think it through
(it's not my day job).

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




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux