digimend-devel Mailing List for DIGImend (Page 8)
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: Nikolai K. <sp...@gm...> - 2015-03-23 15:09:55
|
On 03/23/2015 05:07 PM, Nikolai Kondrashov wrote: > Hi Maki, > > On 03/23/2015 05:03 PM, Maki Jaderborg wrote: >> M 48 00 55 00 49 00 4F 00 4E 00 00 00 00 00 00 00 >> P 50 00 65 00 6E 00 74 00 61 00 62 00 6C 00 65 00 74 00 00 00 >> S 64 12 03 00 7D 20 4E 03 00 FF 07 A0 0F 08 00 00 00 00 00 >> S 65 04 03 20 A0 >> S 6E 04 03 00 30 >> S 79 0A 03 4D 00 35 00 30 00 38 00 >> S 7A 08 03 01 08 00 00 00 00 >> S 7B 0C 03 48 00 4B 00 20 00 4F 00 6E 00 > > Thanks for the diagnostics! > > Did you mean the model name to be "TS-6850"? Ah, sorry, got confused. It is indeed "TS-6580". > Can you also send the "sudo lsusb -v" output with your tablet plugged-in? We would still need the "sudo lsusb -v" output, though. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-03-23 15:08:03
|
Hi Maki, On 03/23/2015 05:03 PM, Maki Jaderborg wrote: > M 48 00 55 00 49 00 4F 00 4E 00 00 00 00 00 00 00 > P 50 00 65 00 6E 00 74 00 61 00 62 00 6C 00 65 00 74 00 00 00 > S 64 12 03 00 7D 20 4E 03 00 FF 07 A0 0F 08 00 00 00 00 00 > S 65 04 03 20 A0 > S 6E 04 03 00 30 > S 79 0A 03 4D 00 35 00 30 00 38 00 > S 7A 08 03 01 08 00 00 00 00 > S 7B 0C 03 48 00 4B 00 20 00 4F 00 6E 00 Thanks for the diagnostics! Did you mean the model name to be "TS-6850"? Can you also send the "sudo lsusb -v" output with your tablet plugged-in? Thank you. Nick |
|
From: Maki J. <ma...@gm...> - 2015-03-23 15:03:24
|
M 48 00 55 00 49 00 4F 00 4E 00 00 00 00 00 00 00 P 50 00 65 00 6E 00 74 00 61 00 62 00 6C 00 65 00 74 00 00 00 S 64 12 03 00 7D 20 4E 03 00 FF 07 A0 0F 08 00 00 00 00 00 S 65 04 03 20 A0 S 6E 04 03 00 30 S 79 0A 03 4D 00 35 00 30 00 38 00 S 7A 08 03 01 08 00 00 00 00 S 7B 0C 03 48 00 4B 00 20 00 4F 00 6E 00 --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com |
|
From: Nikolai K. <sp...@gm...> - 2015-03-22 21:56:29
|
On 03/22/2015 04:55 PM, Nikolai Kondrashov wrote: > On 03/17/2015 04:50 PM, Benjamin Tissoires wrote: >> On Mar 17 2015 or thereabouts, Nikolai Kondrashov wrote: >>> On 03/17/2015 03:13 PM, Benjamin Tissoires wrote: >>>> To have legacy xf86-input-wacom accepting the pad of the Huion tablets, >>>> we need to set some bits on the Pad interface even if they are not used. >>>> >>>> The following bits are activated: >>>> ABS_MISC, ABS_X, ABS_Y and BTN_STYLUS >>>> (because the Pad used to be a attached to the stylus interface, libwacom >>>> and others expect the Pad to look like a tablet) >>> >>> Can we just expand the pad report descriptor? >>> >> >> That's an idea. But that means that we will have to define those fake >> axes to every report descriptor we fix. Here, it will force it for every >> pad, no matter if the rdesc is fixed or not. >> >> Both solutions are tempting (I won't have the time to implement the pad >> fixup today though). > > Sorry for the delay, I'll be looking at your new patches today. > >> BTW, speaking about extending the report descriptor, I noticed yesterday >> that the tablets with 8 buttons have a 0x7a string with the byte 3 >> (starting from 0) set to 0x08. Those of pictures are not showing any >> buttons have this byte set to 0x00. > > That's a cool find! I'll check on the new dumps I received and perhaps add > that to uclogic-decode. I looked at some new dumps (see updates to the tablets repo) and it seems that if you get "HK On" for 0x7b string descriptor, the second byte of 0x7a bString is indeed the number of buttons. BTW, if you have any additions to the tablets repo, I'll be glad to accept patches :) Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-03-22 15:29:06
|
On 03/18/2015 11:19 PM, Benjamin Tissoires wrote: > Hi Nick, > > With the last hid_uclogic.ko patch I sent, I managed to get Gnome on > Fedora 21 happy. I pushed the required files on > http://people.freedesktop.org/~tissoire/huion-f21/ > > * 50-wacom.conf needs to be put in /etc/X11/xorg.conf.d > * huion-h610-pro.tablet needs to be put in /usr/share/libwacom/ > * huion-h610-pro.svg needs to be put in /usr/share/libwacom/layouts/ > * control-center-3.14.3-1.huion.1.fc21.src.rpm is built in the > following copr: https://copr.fedoraproject.org/coprs/bentiss/control-center-huion/ > > Once control-center is updated and the 3 other files put in the > correct place, restart X and the wacom panel in g-c-c should allow > to configure the tablet. > > I hope I did not forget anything while retrieving the various files on > my PC. > > The huion* files differ a little bit from the one I sent to libwacom > because I needed to add an extra match on the name, which is not > available in the current releases. > Also, that means that all Huion tablets will share the same layout to > configure the buttons, so think at this like something that should be > fixed soonish. I think we can try to rely on that button number in a string descriptor that you discovered. > All in all, I don't know if this should be added to one of your scripts > right now. I think it might be better to wait for upstream first, but > it's your call. Thanks, Benjamin. I would prefer to wait for upstream, if a release is coming soon. For now it would be good enough, if we could use UC-Logic tablets with xf86-input-wacom and be able to configure shortcuts, if only with xsetwacom. Which xf86-input-wacom version would be needed for that with your latest pad descriptor patch? We should update our xf86-input-wacom setup page [1][2]. Any takers? Nick [1] https://github.com/DIGImend/digimend.github.io/blob/master/support/howto/drivers/wacom/index.md [2] http://digimend.github.io/support/howto/drivers/wacom/ |
|
From: Nikolai K. <sp...@gm...> - 2015-03-22 15:09:58
|
On 03/18/2015 10:24 PM, Benjamin Tissoires wrote: > To have legacy xf86-input-wacom accepting the pad of the Huion tablets, > we need to set some bits on the Pad interface even if they are not used. > > The following bits are activated: > - ABS_MISC -> Digitizers | 0xff > - ABS_X -> Generic Desktop | X > - ABS_Y -> Generic Desktop | Y > - BTN_STYLUS -> Digitizers | Barrel Switch > (because the Pad used to be a attached to the stylus interface, libwacom > and others expect the Pad to look like a tablet) > > Not having the xf86-input-wacom driver handling the pad is not a > regression, so there is no absolute need for it upstream. > Plus, a device should not export axes it does not have. > It however makes sense to include this in the digimend-kernel-tree drivers > given that the purpose is to have users try the drivers with their current > setup. > > Note that if we add the BTN_RUBBER capability to the Pen interface, > gnome-control-center happily takes the device. However, this will break > users who have updated libwacom to current master, so better not export > such false capability. Looks good, thanks Benjamin! Merged with a shortened subject. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-03-22 14:55:58
|
On 03/17/2015 04:50 PM, Benjamin Tissoires wrote: > On Mar 17 2015 or thereabouts, Nikolai Kondrashov wrote: >> On 03/17/2015 03:13 PM, Benjamin Tissoires wrote: >>> To have legacy xf86-input-wacom accepting the pad of the Huion tablets, >>> we need to set some bits on the Pad interface even if they are not used. >>> >>> The following bits are activated: >>> ABS_MISC, ABS_X, ABS_Y and BTN_STYLUS >>> (because the Pad used to be a attached to the stylus interface, libwacom >>> and others expect the Pad to look like a tablet) >> >> Can we just expand the pad report descriptor? >> > > That's an idea. But that means that we will have to define those fake > axes to every report descriptor we fix. Here, it will force it for every > pad, no matter if the rdesc is fixed or not. > > Both solutions are tempting (I won't have the time to implement the pad > fixup today though). Sorry for the delay, I'll be looking at your new patches today. > BTW, speaking about extending the report descriptor, I noticed yesterday > that the tablets with 8 buttons have a 0x7a string with the byte 3 > (starting from 0) set to 0x08. Those of pictures are not showing any > buttons have this byte set to 0x00. That's a cool find! I'll check on the new dumps I received and perhaps add that to uclogic-decode. > Unfortunately, I would like to check on the new 1060pro+ (12 buttons) > and the H420 (3 buttons) to verify this theory. Anyway, we will have to > differentiate those 2 tablets in some way to export only the proper > buttons number. Sure. Thanks, Benjamin! Nick |
|
From: Benjamin T. <ben...@re...> - 2015-03-18 21:20:09
|
Hi Nick, With the last hid_uclogic.ko patch I sent, I managed to get Gnome on Fedora 21 happy. I pushed the required files on http://people.freedesktop.org/~tissoire/huion-f21/ * 50-wacom.conf needs to be put in /etc/X11/xorg.conf.d * huion-h610-pro.tablet needs to be put in /usr/share/libwacom/ * huion-h610-pro.svg needs to be put in /usr/share/libwacom/layouts/ * control-center-3.14.3-1.huion.1.fc21.src.rpm is built in the following copr: https://copr.fedoraproject.org/coprs/bentiss/control-center-huion/ Once control-center is updated and the 3 other files put in the correct place, restart X and the wacom panel in g-c-c should allow to configure the tablet. I hope I did not forget anything while retrieving the various files on my PC. The huion* files differ a little bit from the one I sent to libwacom because I needed to add an extra match on the name, which is not available in the current releases. Also, that means that all Huion tablets will share the same layout to configure the buttons, so think at this like something that should be fixed soonish. All in all, I don't know if this should be added to one of your scripts right now. I think it might be better to wait for upstream first, but it's your call. Happy testings, Benjamin |
|
From: Benjamin T. <ben...@re...> - 2015-03-18 20:24:09
|
To have legacy xf86-input-wacom accepting the pad of the Huion tablets,
we need to set some bits on the Pad interface even if they are not used.
The following bits are activated:
- ABS_MISC -> Digitizers | 0xff
- ABS_X -> Generic Desktop | X
- ABS_Y -> Generic Desktop | Y
- BTN_STYLUS -> Digitizers | Barrel Switch
(because the Pad used to be a attached to the stylus interface, libwacom
and others expect the Pad to look like a tablet)
Not having the xf86-input-wacom driver handling the pad is not a
regression, so there is no absolute need for it upstream.
Plus, a device should not export axes it does not have.
It however makes sense to include this in the digimend-kernel-tree drivers
given that the purpose is to have users try the drivers with their current
setup.
Note that if we add the BTN_RUBBER capability to the Pen interface,
gnome-control-center happily takes the device. However, this will break
users who have updated libwacom to current master, so better not export
such false capability.
---
changes in v2:
- tweak the exported PAD report descriptor, not the .input_configured() callback
hid-uclogic.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/hid-uclogic.c b/hid-uclogic.c
index cca77d8..c362ebd 100644
--- a/hid-uclogic.c
+++ b/hid-uclogic.c
@@ -630,6 +630,23 @@ static const __u8 uclogic_buttonpad_rdesc[] = {
0x29, 0x08, /* Usage Maximum (08h), */
0x95, 0x08, /* Report Count (8), */
0x81, 0x02, /* Input (Variable), */
+ 0x05, 0x0D, /* Usage Page (Digitizers), */
+ 0x09, 0x20, /* Usage (Stylus), */
+ 0x14, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x09, 0x44, /* Usage (Barrel Switch), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x81, 0x02, /* Input (Data,Var,Abs), */
+ 0x05, 0x01, /* Usage Page (Generic Desktop), */
+ 0x09, 0x30, /* Usage (X), */
+ 0x09, 0x31, /* Usage (Y), */
+ 0x95, 0x02, /* Report Count (2), */
+ 0x81, 0x02, /* Input (Data,Var,Abs), */
+ 0x05, 0x0D, /* Usage Page (Digitizers), */
+ 0x09, 0xFF, /* Usage (Vendor Usage 0xff), */
+ 0x75, 0x05, /* Report Size (5), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x81, 0x02, /* Input (Data,Var,Abs), */
0xC0, /* End Collection */
0xC0 /* End Collection */
};
--
2.3.1
|
|
From: Nikolai K. <sp...@gm...> - 2015-03-18 13:16:04
|
On 03/18/2015 02:57 PM, Masaru Hirano wrote: > Hello Nick > > Thanks for developing. > We have tested below. > Ugee1000L > Ugee1010B > UgeeEX07 > UgeeM540 > UgeeM708 > UgeeSP1001 > > If you need more information or additional test , please let us know. Thanks a lot, Masaru, that's really comprehensive and useful! Nick |
|
From: Masaru H. <mh...@ne...> - 2015-03-18 12:57:24
|
Hello Nick Thanks for developing. We have tested below. Ugee1000L Ugee1010B UgeeEX07 UgeeM540 UgeeM708 UgeeSP1001 If you need more information or additional test , please let us know. Best regards Masaru Hirano Neoblast Inc. On 2015年03月17日 06:47, Nikolai Kondrashov wrote: > Dear users of digimend-kernel-drivers, > > I'm writing to the DIGImend-users list and addressing a lot of people > directly > with a "blind" copy. > > Benjamin Tissoires and me are working on making digimend-kernel-drivers > compatible with current and future versions of the Wacom driver > (xf86-input-wacom), especially with regard to adding support for remapping > frame buttons to arbitrary key combinations. > > This concerns Huion, Yiynova, Ugee tablets, as well as UC-Logic TWHA60 v3 > tablet. > > We would like to ask everyone owning one of these tablets to please take > some > diagnostics information from their tablets and send them in reply to this > message. > > To do that please download, build or install the latest version of > uclogic-tools (previously huion-tools): > > https://github.com/DIGImend/uclogic-tools/releases/tag/v4 > > Find the bus number and device address of your tablet in "lsusb" output: > > $ lsusb > Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate > Matching Hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 004: ID 04f2:b2ea Chicony Electronics Co., Ltd > Integrated Camera [ThinkPad] > Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth > 4.0 [ThinkPad] > Bus 001 Device 008: ID 256c:006e > > Here, the last line is a Huion tablet. It is on bus 1, with device > address 8. > If you can't spot your tablet, try unplugging it, running "lsusb", > plugging it > back, running "lsusb" again and finding the new line. > > Execute uclogic-probe, supplying it with the bus number and device > address you > found. For the lsusb output above, and if you installed uclogic-tools, > it will > look like this: > > $ sudo uclogic-probe 1 8 > > If you just built it without installing, run from the build tree, like > this: > > $ sudo ./uclogic-probe 1 8 > > Please send the output of either of these commands, plus "lsusb -v" output. > > More information on uclogic-tools building, installation and usage is > available in its README.md: > > https://github.com/DIGImend/uclogic-tools/blob/master/README.md > > Thank you. > > Sincerely, > Nick > > -- ========================================= Masaru Hirano Neoblast Inc. Tokiwadai1-67-5-704, Itabashi-ku, Tokyo, Japan ZIP:174-0071 E-Mail:mh...@ne... Tel:+81-3-4570-7345 Mob:+81-70-6575-1732 Fax:+81-20-4623-9249 ========================================= |
|
From: Benjamin T. <ben...@re...> - 2015-03-17 14:50:28
|
On Mar 17 2015 or thereabouts, Nikolai Kondrashov wrote: > On 03/17/2015 03:13 PM, Benjamin Tissoires wrote: > >To have legacy xf86-input-wacom accepting the pad of the Huion tablets, > >we need to set some bits on the Pad interface even if they are not used. > > > >The following bits are activated: > >ABS_MISC, ABS_X, ABS_Y and BTN_STYLUS > >(because the Pad used to be a attached to the stylus interface, libwacom > >and others expect the Pad to look like a tablet) > > Can we just expand the pad report descriptor? > That's an idea. But that means that we will have to define those fake axes to every report descriptor we fix. Here, it will force it for every pad, no matter if the rdesc is fixed or not. Both solutions are tempting (I won't have the time to implement the pad fixup today though). BTW, speaking about extending the report descriptor, I noticed yesterday that the tablets with 8 buttons have a 0x7a string with the byte 3 (starting from 0) set to 0x08. Those of pictures are not showing any buttons have this byte set to 0x00. Unfortunately, I would like to check on the new 1060pro+ (12 buttons) and the H420 (3 buttons) to verify this theory. Anyway, we will have to differentiate those 2 tablets in some way to export only the proper buttons number. Cheers, Benjamin |
|
From: Nikolai K. <sp...@gm...> - 2015-03-17 13:15:59
|
On 03/17/2015 03:13 PM, Benjamin Tissoires wrote: > To have legacy xf86-input-wacom accepting the pad of the Huion tablets, > we need to set some bits on the Pad interface even if they are not used. > > The following bits are activated: > ABS_MISC, ABS_X, ABS_Y and BTN_STYLUS > (because the Pad used to be a attached to the stylus interface, libwacom > and others expect the Pad to look like a tablet) Can we just expand the pad report descriptor? Nick |
|
From: Benjamin T. <ben...@re...> - 2015-03-17 13:13:36
|
To have legacy xf86-input-wacom accepting the pad of the Huion tablets,
we need to set some bits on the Pad interface even if they are not used.
The following bits are activated:
ABS_MISC, ABS_X, ABS_Y and BTN_STYLUS
(because the Pad used to be a attached to the stylus interface, libwacom
and others expect the Pad to look like a tablet)
Not having the xf86-input-wacom driver handling the pad is not a regression,
so there is no absolute need for it upstream.
It however makes sense to include this in the digimend-kernel-tree drivers
given that the purpose is to have users try the drivers with their current
setup.
Note that if we add the BTN_RUBBER capability to the Pen interface,
gnome-control-center happily takes the device. However, this will break
users who have updated libwacom to current master, so better not export
such false capability.
---
I don't want to send this one upstream. I discussed with Peter about it,
and we both agree that the kernel should not advertise axes it does not have.
hid-uclogic.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/hid-uclogic.c b/hid-uclogic.c
index e7ea0e3..c259d79 100644
--- a/hid-uclogic.c
+++ b/hid-uclogic.c
@@ -793,6 +793,29 @@ static void uclogic_append_suffix(struct hid_device *hdev, struct hid_input *hi)
}
}
+static void uclogic_tweak_input(struct hid_device *hdev, struct hid_input *hi)
+{
+ struct input_dev *input_dev = hi->input;
+ struct hid_field *field;
+
+ field = hi->report->field[0];
+
+ /* xf86-input-wacom needs some more declarations */
+ if (field->application == HID_GD_KEYPAD) {
+ __set_bit(EV_ABS, input_dev->evbit);
+
+ /* forced to have legacy xf86-input-wacom working */
+ __set_bit(ABS_MISC, input_dev->absbit);
+
+ /* forced to have legacy xf86-input-wacom accepting the pad */
+ input_set_abs_params(input_dev, ABS_X, 0, 1, 0, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0, 1, 0, 0);
+
+ /* forced to have udev and libwacom accepting the pad */
+ __set_bit(BTN_STYLUS, input_dev->keybit);
+ }
+}
+
static void uclogic_input_configured(struct hid_device *hdev,
struct hid_input *hi)
{
@@ -802,6 +825,7 @@ static void uclogic_input_configured(struct hid_device *hdev,
uclogic_append_suffix(hdev, hi);
+ uclogic_tweak_input(hdev, hi);
}
/**
--
2.3.1
|
|
From: Benjamin T. <ben...@re...> - 2015-03-17 13:13:31
|
.input_configured() will be used to make the device appear like a Wacom
tablet. We need to have a separate call for appending the suffix to keep
the code clear.
---
Not sure this one needs to go upstream. It's only required for the next patch
which should not go upstream.
hid-uclogic.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/hid-uclogic.c b/hid-uclogic.c
index cca77d8..e7ea0e3 100644
--- a/hid-uclogic.c
+++ b/hid-uclogic.c
@@ -753,18 +753,13 @@ static int uclogic_input_mapping(struct hid_device *hdev, struct hid_input *hi,
return 0;
}
-static void uclogic_input_configured(struct hid_device *hdev,
- struct hid_input *hi)
+static void uclogic_append_suffix(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) {
@@ -798,6 +793,17 @@ static void uclogic_input_configured(struct hid_device *hdev,
}
}
+static void uclogic_input_configured(struct hid_device *hdev,
+ struct hid_input *hi)
+{
+ /* no report associated (HID_QUIRK_MULTI_INPUT not set) */
+ if (!hi->report)
+ return;
+
+ uclogic_append_suffix(hdev, hi);
+
+}
+
/**
* Enable fully-functional tablet mode and determine device parameters.
*
--
2.3.1
|
|
From: Nikolai K. <sp...@gm...> - 2015-03-16 19:45:09
|
On 03/15/2015 08:34 PM, Benjamin Tissoires wrote: > Based on a patch from: Nikolai Kondrashov <Nik...@re...> > > Enable abstract keyboard mode for Huion tablets, which makes them report > frame buttons using the pen interface and report ID. Divert these > reports to a virtual report ID describing them. > > This makes the tablet compatible with xf86-input-wacom and libinput, > but stops the frame buttons from reporting keyboard events. > --- > > changes in v2: > - renamed uclogic_buttonpad_rdesc_template into uclogic_buttonpad_rdesc > - amended comment above uclogic_buttonpad_rdesc Looks fine now. Only changed the tag in the subject to "uclogic", and merged. Thanks, Benjamin! Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-03-15 20:07:23
|
On 03/15/2015 07:18 PM, Benjamin Tissoires wrote: > > > > > ----- Original Message ----- >> From: "Nikolai Kondrashov" <sp...@gm...> >> To: "Benjamin Tissoires" <ben...@re...>, "DIGImend-devel" <DIG...@li...> >> Sent: Sunday, March 15, 2015 12:54:19 PM >> Subject: Re: [DIGImend-devel] [PATCH 2/2] huion: Switch to reporting abstract button events >> >> On 03/15/2015 06:02 PM, Nikolai Kondrashov wrote: >>> On 03/13/2015 11:28 PM, Benjamin Tissoires wrote: >>>> Based on a patch from: Nikolai Kondrashov <Nik...@re...> >>>> >>>> Enable abstract keyboard mode for Huion tablets, which makes them report >>>> frame buttons using the pen interface and report ID. Divert these >>>> reports to a virtual report ID describing them. >>>> >>>> This makes the tablet compatible with xf86-input-wacom and libinput, >>>> but stops the frame buttons from reporting keyboard events. >>>> --- >>>> >>>> Sorry it took so long to actually propose this patch. I am fixing at the >>>> moment >>>> gnome-control-center, gnome-settings-daemon and libwacom to be able to >>>> handle >>>> also the generic devices like the Huion ones. >>> >>> This is excellent news which we'll be welcome by all users, I'm sure. >>> >>>> I need to go through all the Huion known device and see what they answer >>>> when >>>> querying the string 0x7b, but I believe checking if "HK On" is returned >>>> should >>>> allow us to prevent activating a pad interface if the device does not >>>> support >>>> it. >>> >>> We can add requesting that string to huion-tools: >>> >>> https://github.com/DIGImend/huion-tools >> >> Added. >> >>> And then ask people to run it and report results. >> >> Can make a release, build packages and send the word out to people, if you >> think it's useful. >> > > I think it will definitively be useful. > I just made a quick test, and I think you should also warn users that they > need to unplug/replug the tablet after running the tool. It can switch the > tablet in the button reporting mode and kill the current keyboard interface > (and messed up the pen interface too). I added a note on this, thanks Benjamin. I've quickly thrown together a release: https://github.com/DIGImend/uclogic-tools/releases/tag/v4 I'll be sending out a message to the list and a few people to get the dumps, tomorrow. Nick |
|
From: Benjamin T. <ben...@re...> - 2015-03-15 18:34:29
|
No need to retrieve the USB handle in input_mapping() when we already do that in probe. It also allows to use the quirk without having to add the product ID matching. Sent upstream as: https://patchwork.kernel.org/patch/6013671/ --- changes in v2: - renamed ignore_pen_interface into ignore_pen_usage - updated commit message hid-uclogic.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/hid-uclogic.c b/hid-uclogic.c index 51333fa..4b4a190 100644 --- a/hid-uclogic.c +++ b/hid-uclogic.c @@ -627,6 +627,7 @@ struct uclogic_drvdata { __u8 *rdesc; unsigned int rsize; bool invert_pen_inrange; + bool ignore_pen_usage; }; static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc, @@ -719,16 +720,12 @@ static int uclogic_input_mapping(struct hid_device *hdev, struct hid_input *hi, struct hid_field *field, struct hid_usage *usage, unsigned long **bit, int *max) { - struct usb_interface *intf; - - if (hdev->product == USB_DEVICE_ID_HUION_TABLET) { - intf = to_usb_interface(hdev->dev.parent); + struct uclogic_drvdata *drvdata = hid_get_drvdata(hdev); - /* discard the unused pen interface */ - if ((intf->cur_altsetting->desc.bInterfaceNumber != 0) && - (field->application == HID_DG_PEN)) - return -1; - } + /* discard the unused pen interface */ + if ((drvdata->ignore_pen_usage) && + (field->application == HID_DG_PEN)) + return -1; /* let hid-core decide what to do */ return 0; @@ -910,6 +907,8 @@ static int uclogic_probe(struct hid_device *hdev, return rc; } drvdata->invert_pen_inrange = true; + } else { + drvdata->ignore_pen_usage = true; } break; case USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60: -- 2.3.1 |
|
From: Benjamin T. <ben...@re...> - 2015-03-15 18:34:29
|
Based on a patch from: Nikolai Kondrashov <Nik...@re...>
Enable abstract keyboard mode for Huion tablets, which makes them report
frame buttons using the pen interface and report ID. Divert these
reports to a virtual report ID describing them.
This makes the tablet compatible with xf86-input-wacom and libinput,
but stops the frame buttons from reporting keyboard events.
---
changes in v2:
- renamed uclogic_buttonpad_rdesc_template into uclogic_buttonpad_rdesc
- amended comment above uclogic_buttonpad_rdesc
hid-uclogic.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 98 insertions(+), 5 deletions(-)
diff --git a/hid-uclogic.c b/hid-uclogic.c
index 4b4a190..0080444 100644
--- a/hid-uclogic.c
+++ b/hid-uclogic.c
@@ -613,6 +613,27 @@ static const __u8 uclogic_tablet_rdesc_template[] = {
0xC0 /* End Collection */
};
+/* Fixed virtual pad report descriptor */
+static const __u8 uclogic_buttonpad_rdesc[] = {
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x09, 0x07, /* Usage (Keypad), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0xF7, /* Report ID (247), */
+ 0x05, 0x0D, /* Usage Page (Digitizers), */
+ 0x09, 0x39, /* Usage (Tablet Function Keys), */
+ 0xA0, /* Collection (Physical), */
+ 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 */
+ 0xC0 /* End Collection */
+};
+
/* Parameter indices */
enum uclogic_prm {
UCLOGIC_PRM_X_LM = 1,
@@ -628,6 +649,7 @@ struct uclogic_drvdata {
unsigned int rsize;
bool invert_pen_inrange;
bool ignore_pen_usage;
+ bool has_virtual_pad_interface;
};
static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc,
@@ -874,6 +896,70 @@ cleanup:
return rc;
}
+/**
+ * Enable actual button mode.
+ *
+ * @hdev: HID device
+ */
+static int uclogic_button_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);
+ char *str_buf;
+ size_t str_len = 16;
+ unsigned char *rdesc;
+ size_t rdesc_len;
+
+ str_buf = kzalloc(str_len, GFP_KERNEL);
+ if (str_buf == NULL) {
+ hid_err(hdev, "failed to allocate string buffer\n");
+ rc = -ENOMEM;
+ goto cleanup;
+ }
+
+ /* Enable abstract keyboard mode */
+ rc = usb_string(usb_dev, 0x7b, str_buf, str_len);
+ if (rc == -EPIPE) {
+ hid_info(hdev, "button mode setting not found\n");
+ rc = 0;
+ goto cleanup;
+ } else if (rc < 0) {
+ hid_err(hdev, "failed to enable abstract keyboard\n");
+ goto cleanup;
+ } else if (strncmp(str_buf, "HK On", rc)) {
+ hid_info(hdev, "invalid answer when requesting buttons: '%s'\n",
+ str_buf);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ /* Re-allocate fixed report descriptor */
+ rdesc_len = drvdata->rsize + sizeof(uclogic_buttonpad_rdesc);
+ rdesc = devm_kzalloc(&hdev->dev, rdesc_len, GFP_KERNEL);
+ if (!rdesc) {
+ rc = -ENOMEM;
+ goto cleanup;
+ }
+
+ memcpy(rdesc, drvdata->rdesc, drvdata->rsize);
+
+ /* Append the buttonpad descriptor */
+ memcpy(rdesc + drvdata->rsize, uclogic_buttonpad_rdesc,
+ sizeof(uclogic_buttonpad_rdesc));
+
+ /* clean up old rdesc and use the new one */
+ drvdata->rsize = rdesc_len;
+ devm_kfree(&hdev->dev, drvdata->rdesc);
+ drvdata->rdesc = rdesc;
+
+ rc = 0;
+
+cleanup:
+ kfree(str_buf);
+ return rc;
+}
+
static int uclogic_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
@@ -907,6 +993,9 @@ static int uclogic_probe(struct hid_device *hdev,
return rc;
}
drvdata->invert_pen_inrange = true;
+
+ rc = uclogic_button_enable(hdev);
+ drvdata->has_virtual_pad_interface = !rc;
} else {
drvdata->ignore_pen_usage = true;
}
@@ -947,12 +1036,16 @@ static int uclogic_raw_event(struct hid_device *hdev, struct hid_report *report,
{
struct uclogic_drvdata *drvdata = hid_get_drvdata(hdev);
- if ((drvdata->invert_pen_inrange) &&
- (report->type == HID_INPUT_REPORT) &&
+ if ((report->type == HID_INPUT_REPORT) &&
(report->id == UCLOGIC_PEN_REPORT_ID) &&
- (size >= 2))
- /* Invert the in-range bit */
- data[1] ^= 0x40;
+ (size >= 2)) {
+ if (drvdata->has_virtual_pad_interface && (data[1] & 0x20))
+ /* Change to virtual frame button report ID */
+ data[0] = 0xf7;
+ else if (drvdata->invert_pen_inrange)
+ /* Invert the in-range bit */
+ data[1] ^= 0x40;
+ }
return 0;
}
--
2.3.1
|
|
From: Benjamin T. <bti...@re...> - 2015-03-15 17:34:12
|
----- Original Message ----- > From: "Nikolai Kondrashov" <sp...@gm...> > To: "Benjamin Tissoires" <ben...@re...>, "DIGImend-devel" <DIG...@li...> > Sent: Sunday, March 15, 2015 12:02:41 PM > Subject: Re: [DIGImend-devel] [PATCH 2/2] huion: Switch to reporting abstract button events > > On 03/13/2015 11:28 PM, Benjamin Tissoires wrote: > > Based on a patch from: Nikolai Kondrashov <Nik...@re...> > > > > Enable abstract keyboard mode for Huion tablets, which makes them report > > frame buttons using the pen interface and report ID. Divert these > > reports to a virtual report ID describing them. > > > > This makes the tablet compatible with xf86-input-wacom and libinput, > > but stops the frame buttons from reporting keyboard events. > > --- > > > > Sorry it took so long to actually propose this patch. I am fixing at the > > moment > > gnome-control-center, gnome-settings-daemon and libwacom to be able to > > handle > > also the generic devices like the Huion ones. > > This is excellent news which we'll be welcome by all users, I'm sure. Yeah. It turns out that there was a little bit of work to do to be able to support these tablets. Most of the problem came from the fact that the tablets don't have an eraser and gnome-control-center rejected such tablets. I think I'll make an announce here once I got the bugs fixed, but I think it should be safe to assume that gnome 3.16 will be able to handle the Huion tablets seamlessly. And I'll make sure Fedora 22 get all the patches. We will need to upgrade libwacom too, and I already started adding the Huion H610 Pro (with the button layout) to it: http://sourceforge.net/p/linuxwacom/mailman/linuxwacom-devel/thread/1426281693-12291-3-git-send-email-benjamin.tissoires%40redhat.com/#msg33595219 We will then have to add the various tablets we want to have a nice Button mapping gui to libwacom. If the entry is not in libwacom, the button mapping won't be configurable by the user, but the tablet will show up in g-c-c. > > > I need to go through all the Huion known device and see what they answer > > when > > querying the string 0x7b, but I believe checking if "HK On" is returned > > should > > allow us to prevent activating a pad interface if the device does not > > support > > it. > > We can add requesting that string to huion-tools: > > https://github.com/DIGImend/huion-tools > > And then ask people to run it and report results. > > I should probably rename that to uclogic-tools, BTW. > > > I am quite tempted to send this one upstream directly too. So please, test > > it > > and report if there are obvious problems. > > I understand :) Once we get this merged and I clean up the general state and > update the README.md, I'll make a release and people will test it. > > Nick > > > Cheers, > > Benjamin > > > > hid-uclogic.c | 103 > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 98 insertions(+), 5 deletions(-) > > > > diff --git a/hid-uclogic.c b/hid-uclogic.c > > index 88c0914..ea57d9f 100644 > > --- a/hid-uclogic.c > > +++ b/hid-uclogic.c > > @@ -613,6 +613,27 @@ static const __u8 uclogic_tablet_rdesc_template[] = { > > 0xC0 /* End Collection */ > > }; > > > > +/* Fixed report descriptor template */ > > +static const __u8 uclogic_buttonpad_rdesc_template[] = { > > This isn't a template, but just a descriptor. I think it is better to drop > "template" from here. Sure, will fix. > > > + 0x05, 0x01, /* Usage Page (Desktop), */ > > + 0x09, 0x07, /* Usage (Keypad), */ > > + 0xA1, 0x01, /* Collection (Application), */ > > + 0x85, 0xF7, /* Report ID (247), */ > > + 0x05, 0x0D, /* Usage Page (Digitizers), */ > > + 0x09, 0x39, /* Usage (Tablet Function Keys), */ > > + 0xA0, /* Collection (Physical), */ > > + 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 */ > > + 0xC0 /* End Collection */ > > +}; > > + > > /* Parameter indices */ > > enum uclogic_prm { > > UCLOGIC_PRM_X_LM = 1, > > @@ -628,6 +649,7 @@ struct uclogic_drvdata { > > unsigned int rsize; > > bool invert_pen_inrange; > > bool ignore_pen_interface; > > + bool has_virtual_pad_interface; > > }; > > > > static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc, > > @@ -874,6 +896,70 @@ cleanup: > > return rc; > > } > > > > +/** > > + * Enable actual button mode. > > + * > > + * @hdev: HID device > > + */ > > +static int uclogic_button_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); > > + char *str_buf; > > + size_t str_len = 16; > > + unsigned char *rdesc; > > + size_t rdesc_len; > > + > > + str_buf = kzalloc(str_len, GFP_KERNEL); > > + if (str_buf == NULL) { > > + hid_err(hdev, "failed to allocate string buffer\n"); > > + rc = -ENOMEM; > > + goto cleanup; > > + } > > + > > + /* Enable abstract keyboard mode */ > > + rc = usb_string(usb_dev, 0x7b, str_buf, str_len); > > + if (rc == -EPIPE) { > > + hid_info(hdev, "button mode setting not found\n"); > > + rc = 0; > > + goto cleanup; > > + } else if (rc < 0) { > > + hid_err(hdev, "failed to enable abstract keyboard\n"); > > + goto cleanup; > > + } else if (strncmp(str_buf, "HK On", rc)) { > > + hid_info(hdev, "invalid answer when requesting buttons: '%s'\n", > > + str_buf); > > + rc = -EINVAL; > > + goto cleanup; > > + } > > + > > + /* Re-allocate fixed report descriptor */ > > + rdesc_len = drvdata->rsize + sizeof(uclogic_buttonpad_rdesc_template); > > + rdesc = devm_kzalloc(&hdev->dev, rdesc_len, GFP_KERNEL); > > + if (!rdesc) { > > + rc = -ENOMEM; > > + goto cleanup; > > + } > > + > > + memcpy(rdesc, drvdata->rdesc, drvdata->rsize); > > + > > + /* Append the buttonpad descriptor */ > > + memcpy(rdesc + drvdata->rsize, uclogic_buttonpad_rdesc_template, > > + sizeof(uclogic_buttonpad_rdesc_template)); > > + > > + /* clean up old rdesc and use the new one */ > > + drvdata->rsize = rdesc_len; > > + devm_kfree(&hdev->dev, drvdata->rdesc); > > + drvdata->rdesc = rdesc; > > + > > + rc = 0; > > + > > +cleanup: > > + kfree(str_buf); > > + return rc; > > +} > > + > > static int uclogic_probe(struct hid_device *hdev, > > const struct hid_device_id *id) > > { > > @@ -907,6 +993,9 @@ static int uclogic_probe(struct hid_device *hdev, > > return rc; > > } > > drvdata->invert_pen_inrange = true; > > + > > + rc = uclogic_button_enable(hdev); > > + drvdata->has_virtual_pad_interface = !rc; > > } else { > > drvdata->ignore_pen_interface = true; > > } > > I think the button enabling should also work on TWHA60 v3 handled in the > "case" just below. We can move it above and let it fall down into this when > bNumInterfaces == 3. I.e.: > > case USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60: > /* > * If it is not the pen interface of the three-interface > * version, which is known to respond to initialization. > */ > if (udev->config->desc.bNumInterfaces != 3) > break; > > case USB_DEVICE_ID_HUION_TABLET: > case USB_DEVICE_ID_YIYNOVA_TABLET: True. But upstream doesn't have support of the TWHA60 v3. So I'd prefer keep the patch in that way, and then add an extra commit for TWHA60 v3. Then the final support of TWHA60 v3 can be merged upstream too. > > Another nice thing to do here is to somehow disable the keyboard interface > (#2), but I'm not sure how to do that best. Not sure either. With the proper names, we have a lot of extra input nodes, but the user can easily ignore them seeing that one is "Keyboard". If Huion did not reused the same VID/PID for every tablets, things would have been easier :( > > > > @@ -947,12 +1036,16 @@ static int uclogic_raw_event(struct hid_device > > *hdev, struct hid_report *report, > > { > > struct uclogic_drvdata *drvdata = hid_get_drvdata(hdev); > > > > - if ((drvdata->invert_pen_inrange) && > > - (report->type == HID_INPUT_REPORT) && > > + if ((report->type == HID_INPUT_REPORT) && > > (report->id == UCLOGIC_PEN_REPORT_ID) && > > - (size >= 2)) > > - /* Invert the in-range bit */ > > - data[1] ^= 0x40; > > + (size >= 2)) { > > + if (drvdata->has_virtual_pad_interface && (data[1] & 0x20)) > > + /* Change to virtual frame button report ID */ > > + data[0] = 0xf7; > > + else if (drvdata->invert_pen_inrange) > > + /* Invert the in-range bit */ > > + data[1] ^= 0x40; > > + } > > > > return 0; > > } > > This is neat. > > Thanks, Benjamin! > You are welcome. Cheers, Benjamin |
|
From: Benjamin T. <bti...@re...> - 2015-03-15 17:18:13
|
----- Original Message ----- > From: "Nikolai Kondrashov" <sp...@gm...> > To: "Benjamin Tissoires" <ben...@re...>, "DIGImend-devel" <DIG...@li...> > Sent: Sunday, March 15, 2015 12:54:19 PM > Subject: Re: [DIGImend-devel] [PATCH 2/2] huion: Switch to reporting abstract button events > > On 03/15/2015 06:02 PM, Nikolai Kondrashov wrote: > > On 03/13/2015 11:28 PM, Benjamin Tissoires wrote: > >> Based on a patch from: Nikolai Kondrashov <Nik...@re...> > >> > >> Enable abstract keyboard mode for Huion tablets, which makes them report > >> frame buttons using the pen interface and report ID. Divert these > >> reports to a virtual report ID describing them. > >> > >> This makes the tablet compatible with xf86-input-wacom and libinput, > >> but stops the frame buttons from reporting keyboard events. > >> --- > >> > >> Sorry it took so long to actually propose this patch. I am fixing at the > >> moment > >> gnome-control-center, gnome-settings-daemon and libwacom to be able to > >> handle > >> also the generic devices like the Huion ones. > > > > This is excellent news which we'll be welcome by all users, I'm sure. > > > >> I need to go through all the Huion known device and see what they answer > >> when > >> querying the string 0x7b, but I believe checking if "HK On" is returned > >> should > >> allow us to prevent activating a pad interface if the device does not > >> support > >> it. > > > > We can add requesting that string to huion-tools: > > > > https://github.com/DIGImend/huion-tools > > Added. > > > And then ask people to run it and report results. > > Can make a release, build packages and send the word out to people, if you > think it's useful. > I think it will definitively be useful. I just made a quick test, and I think you should also warn users that they need to unplug/replug the tablet after running the tool. It can switch the tablet in the button reporting mode and kill the current keyboard interface (and messed up the pen interface too). Cheers, Benjamin |
|
From: Nikolai K. <sp...@gm...> - 2015-03-15 16:54:24
|
On 03/15/2015 06:02 PM, Nikolai Kondrashov wrote: > On 03/13/2015 11:28 PM, Benjamin Tissoires wrote: >> Based on a patch from: Nikolai Kondrashov <Nik...@re...> >> >> Enable abstract keyboard mode for Huion tablets, which makes them report >> frame buttons using the pen interface and report ID. Divert these >> reports to a virtual report ID describing them. >> >> This makes the tablet compatible with xf86-input-wacom and libinput, >> but stops the frame buttons from reporting keyboard events. >> --- >> >> Sorry it took so long to actually propose this patch. I am fixing at the moment >> gnome-control-center, gnome-settings-daemon and libwacom to be able to handle >> also the generic devices like the Huion ones. > > This is excellent news which we'll be welcome by all users, I'm sure. > >> I need to go through all the Huion known device and see what they answer when >> querying the string 0x7b, but I believe checking if "HK On" is returned should >> allow us to prevent activating a pad interface if the device does not support >> it. > > We can add requesting that string to huion-tools: > > https://github.com/DIGImend/huion-tools Added. > And then ask people to run it and report results. Can make a release, build packages and send the word out to people, if you think it's useful. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-03-15 16:02:46
|
On 03/13/2015 11:28 PM, Benjamin Tissoires wrote:
> Based on a patch from: Nikolai Kondrashov <Nik...@re...>
>
> Enable abstract keyboard mode for Huion tablets, which makes them report
> frame buttons using the pen interface and report ID. Divert these
> reports to a virtual report ID describing them.
>
> This makes the tablet compatible with xf86-input-wacom and libinput,
> but stops the frame buttons from reporting keyboard events.
> ---
>
> Sorry it took so long to actually propose this patch. I am fixing at the moment
> gnome-control-center, gnome-settings-daemon and libwacom to be able to handle
> also the generic devices like the Huion ones.
This is excellent news which we'll be welcome by all users, I'm sure.
> I need to go through all the Huion known device and see what they answer when
> querying the string 0x7b, but I believe checking if "HK On" is returned should
> allow us to prevent activating a pad interface if the device does not support
> it.
We can add requesting that string to huion-tools:
https://github.com/DIGImend/huion-tools
And then ask people to run it and report results.
I should probably rename that to uclogic-tools, BTW.
> I am quite tempted to send this one upstream directly too. So please, test it
> and report if there are obvious problems.
I understand :) Once we get this merged and I clean up the general state and
update the README.md, I'll make a release and people will test it.
Nick
> Cheers,
> Benjamin
>
> hid-uclogic.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 98 insertions(+), 5 deletions(-)
>
> diff --git a/hid-uclogic.c b/hid-uclogic.c
> index 88c0914..ea57d9f 100644
> --- a/hid-uclogic.c
> +++ b/hid-uclogic.c
> @@ -613,6 +613,27 @@ static const __u8 uclogic_tablet_rdesc_template[] = {
> 0xC0 /* End Collection */
> };
>
> +/* Fixed report descriptor template */
> +static const __u8 uclogic_buttonpad_rdesc_template[] = {
This isn't a template, but just a descriptor. I think it is better to drop
"template" from here.
> + 0x05, 0x01, /* Usage Page (Desktop), */
> + 0x09, 0x07, /* Usage (Keypad), */
> + 0xA1, 0x01, /* Collection (Application), */
> + 0x85, 0xF7, /* Report ID (247), */
> + 0x05, 0x0D, /* Usage Page (Digitizers), */
> + 0x09, 0x39, /* Usage (Tablet Function Keys), */
> + 0xA0, /* Collection (Physical), */
> + 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 */
> + 0xC0 /* End Collection */
> +};
> +
> /* Parameter indices */
> enum uclogic_prm {
> UCLOGIC_PRM_X_LM = 1,
> @@ -628,6 +649,7 @@ struct uclogic_drvdata {
> unsigned int rsize;
> bool invert_pen_inrange;
> bool ignore_pen_interface;
> + bool has_virtual_pad_interface;
> };
>
> static __u8 *uclogic_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> @@ -874,6 +896,70 @@ cleanup:
> return rc;
> }
>
> +/**
> + * Enable actual button mode.
> + *
> + * @hdev: HID device
> + */
> +static int uclogic_button_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);
> + char *str_buf;
> + size_t str_len = 16;
> + unsigned char *rdesc;
> + size_t rdesc_len;
> +
> + str_buf = kzalloc(str_len, GFP_KERNEL);
> + if (str_buf == NULL) {
> + hid_err(hdev, "failed to allocate string buffer\n");
> + rc = -ENOMEM;
> + goto cleanup;
> + }
> +
> + /* Enable abstract keyboard mode */
> + rc = usb_string(usb_dev, 0x7b, str_buf, str_len);
> + if (rc == -EPIPE) {
> + hid_info(hdev, "button mode setting not found\n");
> + rc = 0;
> + goto cleanup;
> + } else if (rc < 0) {
> + hid_err(hdev, "failed to enable abstract keyboard\n");
> + goto cleanup;
> + } else if (strncmp(str_buf, "HK On", rc)) {
> + hid_info(hdev, "invalid answer when requesting buttons: '%s'\n",
> + str_buf);
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + /* Re-allocate fixed report descriptor */
> + rdesc_len = drvdata->rsize + sizeof(uclogic_buttonpad_rdesc_template);
> + rdesc = devm_kzalloc(&hdev->dev, rdesc_len, GFP_KERNEL);
> + if (!rdesc) {
> + rc = -ENOMEM;
> + goto cleanup;
> + }
> +
> + memcpy(rdesc, drvdata->rdesc, drvdata->rsize);
> +
> + /* Append the buttonpad descriptor */
> + memcpy(rdesc + drvdata->rsize, uclogic_buttonpad_rdesc_template,
> + sizeof(uclogic_buttonpad_rdesc_template));
> +
> + /* clean up old rdesc and use the new one */
> + drvdata->rsize = rdesc_len;
> + devm_kfree(&hdev->dev, drvdata->rdesc);
> + drvdata->rdesc = rdesc;
> +
> + rc = 0;
> +
> +cleanup:
> + kfree(str_buf);
> + return rc;
> +}
> +
> static int uclogic_probe(struct hid_device *hdev,
> const struct hid_device_id *id)
> {
> @@ -907,6 +993,9 @@ static int uclogic_probe(struct hid_device *hdev,
> return rc;
> }
> drvdata->invert_pen_inrange = true;
> +
> + rc = uclogic_button_enable(hdev);
> + drvdata->has_virtual_pad_interface = !rc;
> } else {
> drvdata->ignore_pen_interface = true;
> }
I think the button enabling should also work on TWHA60 v3 handled in the
"case" just below. We can move it above and let it fall down into this when
bNumInterfaces == 3. I.e.:
case USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60:
/*
* If it is not the pen interface of the three-interface
* version, which is known to respond to initialization.
*/
if (udev->config->desc.bNumInterfaces != 3)
break;
case USB_DEVICE_ID_HUION_TABLET:
case USB_DEVICE_ID_YIYNOVA_TABLET:
Another nice thing to do here is to somehow disable the keyboard interface
(#2), but I'm not sure how to do that best.
> @@ -947,12 +1036,16 @@ static int uclogic_raw_event(struct hid_device *hdev, struct hid_report *report,
> {
> struct uclogic_drvdata *drvdata = hid_get_drvdata(hdev);
>
> - if ((drvdata->invert_pen_inrange) &&
> - (report->type == HID_INPUT_REPORT) &&
> + if ((report->type == HID_INPUT_REPORT) &&
> (report->id == UCLOGIC_PEN_REPORT_ID) &&
> - (size >= 2))
> - /* Invert the in-range bit */
> - data[1] ^= 0x40;
> + (size >= 2)) {
> + if (drvdata->has_virtual_pad_interface && (data[1] & 0x20))
> + /* Change to virtual frame button report ID */
> + data[0] = 0xf7;
> + else if (drvdata->invert_pen_inrange)
> + /* Invert the in-range bit */
> + data[1] ^= 0x40;
> + }
>
> return 0;
> }
This is neat.
Thanks, Benjamin!
Nick
|
|
From: Nikolai K. <sp...@gm...> - 2015-03-15 15:29:10
|
On 03/13/2015 11:28 PM, Benjamin Tissoires wrote: > No need to retrieve the USB handle in input_mapping() when we already > do that in probe. It also allows to use the quirk without having to > add the product ID matching. > > Sent upstream as: https://patchwork.kernel.org/patch/6006271/ Thanks, Benjamin. I'll wait for your answer to my comment upstream. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-03-15 15:17:09
|
Hi Yann, On 03/07/2015 09:35 PM, Yann Vernier wrote: > Nikolai Kondrashov <sp...@gm...> wrote: > >> 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. > > Okay, doing that. Great! >>>> 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. > > It is definitely scaled by firmware; the non-square area is reported as a full > 12 bit range. This works out to roughly 4096/(105.6/25.4)=985cpi. The soft buttons > are outside of this reported area and handled entirely in firmware. > Obviously the resolution runs out as this hits 4k monitors; quantisation errors > may be notable before that. > > In mouse mode, it reports a higher resolution at 16 bits, but takes steps of > about 7 counts, which works out to roughly 2200cpi. > > The tablet was designed to work with Windows default drivers, and did not come > with any drivers. I have no idea how to request raw data out of it. Well, we'll have to do with that then. >> 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. > > I find the HID encoding of units rather confusing. The descriptor seems > to read 4x2.5 English inches, with a mistaken unit of cubic inches. If I have > managed to figure out the system of HID correctly, the nibble value says what > the exponent is for a unit in that position, so the inches should be 0x31. > The only reason I didn't make the same mistake was that centimeters just > happened to be written under column 1 in the nearly unreadable table. Yes, the unit system is complicated and is not helped by the fact that the authors of the original HID descriptor tool have misinterpreted it, confusing all its users further. >> 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. > > Okay, stripping it down. Thanks! >> 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. > > I was mistaken about the resolution multiplier fields; the tablet really does > use one of them for scrolling events. The other looks like it's horisontal > scrolling, which there isn't a control for. > >> I would disable interface #2 here, if we can't make it work, with something >> like this: > > Done. > > >> BTW, can you make pull requests to digimend-kernel-drivers instead of sending >> files? > > I think I may have figured it out. > https://github.com/DIGImend/digimend-kernel-drivers/pull/11 Thanks, Yann. Reviewed now. Nick |
38 messages has been excluded from this view by a project administrator.
