digimend-devel Mailing List for DIGImend (Page 12)
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-02-18 18:12:33
|
Hi Jose, On 02/18/2015 07:36 PM, Jose Reyes wrote: > i hope you don't mind, > > i don't know how to do a command terminal for install drivers, help me? please thanks > > i am running Linux mint 17.1 xfce 64 bit Please write to DIG...@li... and perhaps someone will be able to help. Nick |
|
From: Jose R. <reb...@gm...> - 2015-02-18 17:36:23
|
i hope you don't mind, i don't know how to do a command terminal for install drivers, help me? please thanks i am running Linux mint 17.1 xfce 64 bit |
|
From: Nikolai K. <sp...@gm...> - 2015-02-18 12:23:26
|
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.
> + 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: Nikolai K. <sp...@gm...> - 2015-02-18 11:14:03
|
Forgot to CC the list.
-------- Forwarded Message --------
Subject: Re: [PATCH 2/2] HID: huion: split the stylus and pad in 2 nodes
Date: Wed, 18 Feb 2015 12:17:01 +0200
From: Nikolai Kondrashov <sp...@gm...>
To: Benjamin Tissoires <ben...@re...>, Jiri Kosina <jk...@su...>
CC: Peter Hutterer <pet...@wh...>, lin...@vg..., lin...@vg...
On 02/18/2015 12:54 AM, Benjamin Tissoires wrote:
> Libinput expects the pad node to be different from the stylus one.
> We can just use HID_QUIRK_MULTI_INPUT to separate the buttons of the
> pad than the actual stylus.
> We can also remove the unused interfaces.
> Last, we append "Pen" or "Pad" suffix to the appropriate input node
> to match what the Wacom driver does and be more convenient for the users
> to know which one is which.
This is very nice and a thing that users asked for and I wanted to add for a
long while. I overlooked the addition of the input_configured callback
support.
>
> Signed-off-by: Benjamin Tissoires <ben...@re...>
> ---
> drivers/hid/hid-huion.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/hid/hid-huion.c b/drivers/hid/hid-huion.c
> index 50fbda4..f298f66 100644
> --- a/drivers/hid/hid-huion.c
> +++ b/drivers/hid/hid-huion.c
> @@ -142,6 +142,33 @@ static __u8 *huion_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> return rdesc;
> }
>
> +static void huion_input_configured(struct hid_device *hdev,
> + struct hid_input *hi)
> +{
> + char *name;
> + const char *suffix = NULL;
> + struct hid_field *field = hi->report->field[0];
> +
> + switch (field->application) {
> + case HID_GD_KEYPAD:
> + suffix = "Pad";
> + break;
> + case HID_DG_PEN:
> + suffix = "Pen";
> + break;
> + }
> +
> + if (suffix) {
> + name = devm_kzalloc(&hi->input->dev,
> + strlen(hdev->name) + strlen(suffix) + 2,
> + GFP_KERNEL);
> + if (name) {
> + sprintf(name, "%s %s", hdev->name, suffix);
I would have preferred an snprintf here instead, with the buffer length
calculated once and specified explicitly.
> + hi->input->name = name;
> + }
> + }
> +}
> +
> /**
> * Enable fully-functional tablet mode and determine device parameters.
> *
> @@ -282,6 +309,9 @@ static int huion_probe(struct hid_device *hdev, const struct hid_device_id *id)
> hid_err(hdev, "tablet enabling failed\n");
> return rc;
> }
> + hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> + } else {
> + return -ENODEV;
> }
> break;
> }
> @@ -335,6 +365,7 @@ static struct hid_driver huion_driver = {
> .probe = huion_probe,
> .report_fixup = huion_report_fixup,
> .raw_event = huion_raw_event,
> + .input_configured = huion_input_configured,
> };
> module_hid_driver(huion_driver);
>
>
Thanks, Benjamin!
Nick
|
|
From: Nikolai K. <sp...@gm...> - 2015-02-18 11:13:42
|
Forgot to CC the list.
-------- Forwarded Message --------
Subject: Re: [PATCH 1/2] HID: huion: enable button mode reporting
Date: Wed, 18 Feb 2015 12:11:59 +0200
From: Nikolai Kondrashov <sp...@gm...>
To: Benjamin Tissoires <ben...@re...>, Jiri Kosina <jk...@su...>
CC: Peter Hutterer <pet...@wh...>, lin...@vg..., lin...@vg...
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.
> /* 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.
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.
> + 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?
> 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.
> + if (rc == -EPIPE) {
> + hid_err(hdev, "button mode switch not found\n");
> + rc = -ENODEV;
> + goto cleanup;
> + } else if (rc < 0) {
> + hid_err(hdev, "failed to switch to button mode: %d\n", rc);
> + rc = -ENODEV;
> + goto cleanup;
> + } else if (rc != len) {
> + hid_err(hdev, "invalid button mode switch\n");
> + rc = -ENODEV;
> + goto cleanup;
> + }
> rc = 0;
>
> cleanup:
> @@ -262,10 +309,16 @@ static int huion_raw_event(struct hid_device *hdev, struct hid_report *report,
> /* If this is a pen input report */
> if (intf->cur_altsetting->desc.bInterfaceNumber == 0 &&
> report->type == HID_INPUT_REPORT &&
> - report->id == 0x07 && size >= 2)
> + report->id == 0x07 && size >= 2) {
> /* Invert the in-range bit */
> data[1] ^= 0x40;
>
> + /* 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.
> + data[0] = 0x08;
> + }
> +
> return 0;
> }
>
>
Nick
|
|
From: Nikolai K. <sp...@gm...> - 2015-02-18 09:32:48
|
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! > 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. 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. > 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? > 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. 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 |
|
From: Sergey 'J. B. <ji...@me...> - 2015-02-17 22:40:22
|
Hi Vince, I had a chance to talk to Nick today. The version that you had is from the experimental huion-abstract-keyboard branch. Nick explained, that while it might work for us for now, it's a dead end because it can not go into mainline like this due to reasons related to libinput / X.org. So that clarifies where you got your version from and why it works while all others don't. Kind regards, Jin On Tue, Feb 17, 2015 at 02:56:02PM -0500, Vince Herried wrote: > I just installed update and checked huion.... > > [vince@desk2 ~]$ modinfo hid-huion > filename: > /lib/modules/3.18.7-200.fc21.i686+PAE/kernel/drivers/hid/hid-huion.ko.xz > license: GPL > description: Huion HID driver > author: Martin Rusko > alias: hid:b0003g*v00005543p0000006E > alias: hid:b0003g*v0000256Cp0000006E > depends: > intree: Y > vermagic: 3.18.7-200.fc21.i686+PAE SMP mod_unload 686 > signer: Fedora kernel signing key > sig_key: 37:4C:E8:E2:2C:69:56:56:B7:5E:D8:2B:C5:BE:C8:36:86:ED:8C:FA > sig_hashalgo: sha256 > [vince@desk2 ~]$ > > > and > [vince@desk2 ~]$ xsetwacom --list > HUION PenTablet stylus id: 8 type: STYLUS > HUION PenTablet stylus id: 9 type: STYLUS > HUION PenTablet eraser id: 13 type: ERASER > HUION PenTablet pad > > whats with that? > > when I install from my source file I only see two devices. > > > and > [vince@desk2 ~]$ xsetwacom --set 8 button 3 key n > [vince@desk2 ~]$ xsetwacom --set 8 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ xsetwacom --set 9 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ xsetwacom --set 10 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ xsetwacom --set 11 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ |
|
From: Sergey 'J. B. <ji...@me...> - 2015-02-17 20:03:34
|
Hi, sorry I did not try your source file yet, actually I wanted to figure out what it is first. Mainly: I do not see a point in using some outdated version that just works by accident. So was going to contact Nick and hopefully he will find some time to shed light on the matter. Imho we should be reporitng bugs against the latest master head, after all we want the fixed and working version of the driver to get into the mainline kernel. What you are writing below basically confirms my experience, so it was working for you only because you were using this "special" version of the driver and I'd be interested to hear from Nick what exactly this version was (i.e. some special debug version for trying things out, some hack for Huion, etc.). Kind regards, Jin On Tue, Feb 17, 2015 at 02:56:02PM -0500, Vince Herried wrote: > I just installed update and checked huion.... > > [vince@desk2 ~]$ modinfo hid-huion > filename: > /lib/modules/3.18.7-200.fc21.i686+PAE/kernel/drivers/hid/hid-huion.ko.xz > license: GPL > description: Huion HID driver > author: Martin Rusko > alias: hid:b0003g*v00005543p0000006E > alias: hid:b0003g*v0000256Cp0000006E > depends: > intree: Y > vermagic: 3.18.7-200.fc21.i686+PAE SMP mod_unload 686 > signer: Fedora kernel signing key > sig_key: 37:4C:E8:E2:2C:69:56:56:B7:5E:D8:2B:C5:BE:C8:36:86:ED:8C:FA > sig_hashalgo: sha256 > [vince@desk2 ~]$ > > > and > [vince@desk2 ~]$ xsetwacom --list > HUION PenTablet stylus id: 8 type: STYLUS > HUION PenTablet stylus id: 9 type: STYLUS > HUION PenTablet eraser id: 13 type: ERASER > HUION PenTablet pad > > whats with that? > > when I install from my source file I only see two devices. > > > and > [vince@desk2 ~]$ xsetwacom --set 8 button 3 key n > [vince@desk2 ~]$ xsetwacom --set 8 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ xsetwacom --set 9 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ xsetwacom --set 10 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ xsetwacom --set 11 button 8 key shift = > Invalid offset into Wacom Button Actions property. > [vince@desk2 ~]$ |
|
From: Vince H. <Vi...@Pl...> - 2015-02-17 19:56:09
|
I just installed update and checked huion.... [vince@desk2 ~]$ modinfo hid-huion filename: /lib/modules/3.18.7-200.fc21.i686+PAE/kernel/drivers/hid/hid-huion.ko.xz license: GPL description: Huion HID driver author: Martin Rusko alias: hid:b0003g*v00005543p0000006E alias: hid:b0003g*v0000256Cp0000006E depends: intree: Y vermagic: 3.18.7-200.fc21.i686+PAE SMP mod_unload 686 signer: Fedora kernel signing key sig_key: 37:4C:E8:E2:2C:69:56:56:B7:5E:D8:2B:C5:BE:C8:36:86:ED:8C:FA sig_hashalgo: sha256 [vince@desk2 ~]$ and [vince@desk2 ~]$ xsetwacom --list HUION PenTablet stylus id: 8 type: STYLUS HUION PenTablet stylus id: 9 type: STYLUS HUION PenTablet eraser id: 13 type: ERASER HUION PenTablet pad whats with that? when I install from my source file I only see two devices. and [vince@desk2 ~]$ xsetwacom --set 8 button 3 key n [vince@desk2 ~]$ xsetwacom --set 8 button 8 key shift = Invalid offset into Wacom Button Actions property. [vince@desk2 ~]$ xsetwacom --set 9 button 8 key shift = Invalid offset into Wacom Button Actions property. [vince@desk2 ~]$ xsetwacom --set 10 button 8 key shift = Invalid offset into Wacom Button Actions property. [vince@desk2 ~]$ xsetwacom --set 11 button 8 key shift = Invalid offset into Wacom Button Actions property. [vince@desk2 ~]$ |
|
From: Jiri K. <jk...@su...> - 2015-02-17 12:16:40
|
On Mon, 16 Feb 2015, Nikolai Kondrashov wrote: > On 02/14/2015 10:48 AM, mil...@gm... wrote: > > From: Milan Plzik <mil...@gm...> > > > > Genius PenSketch M912 digitizer tablet sends incorrect report descriptor by > > default. This patch replaces it with a corrected one. > > > > Signed-off-by: Milan Plzik <mil...@gm...> > > I reviewed this on digimend-devel a while ago, looks good to me. > Thanks, Milan! > > Reviewed-by: Nikolai Kondrashov <sp...@gm...> Applied, thanks. -- Jiri Kosina SUSE Labs |
|
From: Nikolai K. <sp...@gm...> - 2015-02-16 18:48:30
|
On 02/03/2015 02:54 AM, Masaru Hirano wrote: > Hello Nick > > Thanks for M1000L,M708,M860. > They work fine. > > We use ubuntu-studio 14.04 for driver and dump. > We use ubuntu-studio 12.04, 14.04, windows7, windows8.1 for application. > They are all deferent machine. > At first they are fresh install but there are many tablets to test. > So every device are connected same machine for test without re-install. > > We have out-lined memo for preparing testing-enviroment and procedure > as enclosed word file. > Red lines shows collected data. > > Additional tests data are zip file. > 1010B,EX07,M540,M708,M1000L,SP101(Penate10.1) > > If you need more data collection to work, please let me know. Ah, I see you made a copy to the maillist after all, thank you, Masaru. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-16 18:47:19
|
Hi Montero, On 02/13/2015 02:49 AM, montero wrote: > My OS is Ubuntu 14.4 and I have a tablet monitor Huion GT-220 (you can draw > on the screen directly with the stylus, Cintiq style). > > On Krita Sketch, the tablet works just perfect. I assume you mean you have pressure there. > On GIMP, it works good but the stylus can't use the Pressure Sensitivity. Did you set it up under "Input devices" in GIMP? > On Krita and Krita Gemini, the stylus don't work on drawing zone (ok with > menus) and the programs crashes always if I try to choose a tool and > drawing. This is interesting. > Please, tell me what I can do to help you to fix this problem. For the start, please send the output of "lsusb -v" and "xinput list" commands. Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-16 11:18:07
|
Hello Masaru,
Please don't forget to keep DIG...@li... in the CC so
we can have our conversation archived and accessible to others. Thank you.
On 02/02/2015 01:27 PM, Masaru Hirano wrote:
> Hello Nick
>
> Thanks for M1000L,M708,M860.
> They work fine.
>
> We use ubuntu-studio 14.04 for driver and dump.
> We use ubuntu-studio 12.04, 14.04, windows7, windows8.1 for application.
> They are all deferent machine.
> At first they are fresh install but there are many tablets to test.
> So every device are connected same machine for test without re-install.
>
> We have out-lined preparing testing-enviroment and procedure
> as enclosed word file.
> Red lines shows collected data.
>
> Additional tests data are zip file.
> 1010B,EX07,M540,M708,M1000L,SP101(Penate10.1)
>
> If you need more date to work, please let me know.
Thank you for comprehensive diagnostic dumps. They will come in useful for
future drivers.
However, I'd like to have a confirmation that M1000L, M708 and M860 work with
digimend-kernel-drivers [1] properly, before I add their support to a release.
From the evtest dumps you sent I see that M708 works correctly. Was it tested
with the digimend-kernel-drivers installed?
From the same dumps, I see that Ugee-1000L is *not* working properly. Was it
tested with the drivers installed?
I don't see M860 in the dumps you sent.
I need to have a proof they (M1000L, M708, M860) work, before I can release
their support. They must work *without* the WizardPen driver. Could you please
test them on a freshly installed machine? I'll try to outline the procedure.
1. Get a fresh install of a Linux distro.
2. Install the Ugee branch of digimend-kernel-drivers [1].
3. Install evtest.
4. Install a few drawing applications. At least The GIMP and MyPaint.
Optional, but good to do.
5. Connect the tablet.
6. Start evtest and select the pen interface (it's the one which reports data
on pen movement), do the pen coordinates sample [2], send me the resulting
file. The same as you did before, but this time making sure the driver is
installed.
7. Set up drawing applications and test that they can detect varied pressure
and all of the pen button clicks. Send a screenshot which shows strokes
with varied pressure. Optional, but good to do.
Thank you.
[1]: https://github.com/DIGImend/digimend-kernel-drivers/archive/ugee.zip
[2]: https://www.youtube.com/watch?v=ysYk8KLY98U
|
|
From: Nikolai K. <sp...@gm...> - 2015-02-16 10:10:27
|
On 02/14/2015 10:48 AM, mil...@gm... wrote: > From: Milan Plzik <mil...@gm...> > > Genius PenSketch M912 digitizer tablet sends incorrect report descriptor by > default. This patch replaces it with a corrected one. > > Signed-off-by: Milan Plzik <mil...@gm...> I reviewed this on digimend-devel a while ago, looks good to me. Thanks, Milan! Reviewed-by: Nikolai Kondrashov <sp...@gm...> Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-02-14 10:28:02
|
On 02/13/2015 09:30 PM, Vince Herried wrote: > Do you have a guess as to when your versions of huion and other devices > will make it into the kernel by default? The Huion driver should be in the kernel 3.17. I'm working on contributing Yiynova and the newer UC-Logic TWHA60 support. It should get into the kernel repos within a month and get released in the next release at the time. The Ugee state is unclear to me at the moment, I'll have to work on this. Nick |
|
From: <mil...@gm...> - 2015-02-14 08:48:55
|
From: Milan Plzik <mil...@gm...>
Genius PenSketch M912 digitizer tablet sends incorrect report descriptor by
default. This patch replaces it with a corrected one.
Signed-off-by: Milan Plzik <mil...@gm...>
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-kye.c | 140 ++++++++++++++++++++++++++++++++++++++++
drivers/hid/usbhid/hid-quirks.c | 1 +
4 files changed, 143 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8b63879..3c21c0d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1807,6 +1807,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_M912) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LCPOWER, USB_DEVICE_ID_LCPOWER_LC1000 ) },
#if IS_ENABLED(CONFIG_HID_LENOVO)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9243359..945943d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -528,6 +528,7 @@
#define USB_DEVICE_ID_KYE_MOUSEPEN_I608X 0x5011
#define USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2 0x501a
#define USB_DEVICE_ID_KYE_EASYPEN_M610X 0x5013
+#define USB_DEVICE_ID_KYE_PENSKETCH_M912 0x5015
#define USB_VENDOR_ID_LABTEC 0x1020
#define USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD 0x0006
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index 158fcf5..32e6d8d 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -268,6 +268,137 @@ static __u8 easypen_m610x_rdesc_fixed[] = {
0xC0 /* End Collection */
};
+
+/* Original PenSketch M912 report descriptor size */
+#define PENSKETCH_M912_RDESC_ORIG_SIZE 482
+
+/* Fixed PenSketch M912 report descriptor */
+static __u8 pensketch_m912_rdesc_fixed[] = {
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x08, /* Usage (00h), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0x05, /* Report ID (5), */
+ 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+ 0x09, 0x01, /* Usage (01h), */
+ 0x15, 0x81, /* Logical Minimum (-127), */
+ 0x25, 0x7F, /* Logical Maximum (127), */
+ 0x75, 0x08, /* Report Size (8), */
+ 0x95, 0x07, /* Report Count (7), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0xC0, /* End Collection, */
+ 0x05, 0x0D, /* Usage Page (Digitizer), */
+ 0x09, 0x02, /* Usage (Pen), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0x10, /* Report ID (16), */
+ 0x09, 0x20, /* Usage (Stylus), */
+ 0xA0, /* Collection (Physical), */
+ 0x09, 0x42, /* Usage (Tip Switch), */
+ 0x09, 0x44, /* Usage (Barrel Switch), */
+ 0x09, 0x46, /* Usage (Tablet Pick), */
+ 0x14, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x75, 0x01, /* Report Size (1), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x95, 0x04, /* Report Count (4), */
+ 0x81, 0x03, /* Input (Constant, Variable), */
+ 0x09, 0x32, /* Usage (In Range), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x75, 0x10, /* Report Size (16), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xA4, /* Push, */
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x55, 0xFD, /* Unit Exponent (-3), */
+ 0x65, 0x13, /* Unit (Inch), */
+ 0x14, /* Logical Minimum (0), */
+ 0x34, /* Physical Minimum (0), */
+ 0x09, 0x30, /* Usage (X), */
+ 0x27, 0x00, 0xF0, 0x00, 0x00, /* Logical Maximum (61440), */
+ 0x46, 0xE0, 0x2E, /* Physical Maximum (12000), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x09, 0x31, /* Usage (Y), */
+ 0x27, 0x00, 0xB4, 0x00, 0x00, /* Logical Maximum (46080), */
+ 0x46, 0x28, 0x23, /* Physical Maximum (9000), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0xB4, /* Pop, */
+ 0x09, 0x30, /* Usage (Tip Pressure), */
+ 0x14, /* Logical Minimum (0), */
+ 0x26, 0xFF, 0x07, /* Logical Maximum (2047), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0xC0, /* End Collection, */
+ 0xC0, /* End Collection, */
+ 0x05, 0x0D, /* Usage Page (Digitizer), */
+ 0x09, 0x21, /* Usage (Puck), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0x11, /* Report ID (17), */
+ 0x09, 0x21, /* Usage (Puck), */
+ 0xA0, /* Collection (Physical), */
+ 0x05, 0x09, /* Usage Page (Button), */
+ 0x75, 0x01, /* Report Size (1), */
+ 0x19, 0x01, /* Usage Minimum (01h), */
+ 0x29, 0x03, /* Usage Maximum (03h), */
+ 0x14, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x95, 0x04, /* Report Count (4), */
+ 0x81, 0x01, /* Input (Constant), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x0B, 0x32, 0x00, 0x0D, 0x00, /* Usage (Digitizer In Range), */
+ 0x14, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0xA4, /* Push, */
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x75, 0x10, /* Report Size (16), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x55, 0xFD, /* Unit Exponent (-3), */
+ 0x65, 0x13, /* Unit (Inch), */
+ 0x14, /* Logical Minimum (0), */
+ 0x34, /* Physical Minimum (0), */
+ 0x09, 0x30, /* Usage (X), */
+ 0x27, 0x00, 0xF0, 0x00, 0x00, /* Logical Maximum (61440), */
+ 0x46, 0xE0, 0x2E, /* Physical Maximum (12000), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x09, 0x31, /* Usage (Y), */
+ 0x27, 0x00, 0xB4, 0x00, 0x00, /* Logical Maximum (46080), */
+ 0x46, 0x28, 0x23, /* Physical Maximum (9000), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x09, 0x38, /* Usage (Wheel), */
+ 0x75, 0x08, /* Report Size (8), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x15, 0xFF, /* Logical Minimum (-1), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x34, /* Physical Minimum (0), */
+ 0x44, /* Physical Maximum (0), */
+ 0x81, 0x06, /* Input (Variable, Relative), */
+ 0xB4, /* Pop, */
+ 0xC0, /* End Collection, */
+ 0xC0, /* End Collection, */
+ 0x05, 0x0C, /* Usage Page (Consumer), */
+ 0x09, 0x01, /* Usage (Consumer Control), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0x12, /* Report ID (18), */
+ 0x14, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x75, 0x01, /* Report Size (1), */
+ 0x95, 0x08, /* Report Count (8), */
+ 0x05, 0x0C, /* Usage Page (Consumer), */
+ 0x0A, 0x6A, 0x02, /* Usage (AC Delete), */
+ 0x0A, 0x1A, 0x02, /* Usage (AC Undo), */
+ 0x0A, 0x01, 0x02, /* Usage (AC New), */
+ 0x0A, 0x2F, 0x02, /* Usage (AC Zoom), */
+ 0x0A, 0x25, 0x02, /* Usage (AC Forward), */
+ 0x0A, 0x24, 0x02, /* Usage (AC Back), */
+ 0x0A, 0x2D, 0x02, /* Usage (AC Zoom In), */
+ 0x0A, 0x2E, 0x02, /* Usage (AC Zoom Out), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x95, 0x30, /* Report Count (48), */
+ 0x81, 0x03, /* Input (Constant, Variable), */
+ 0xC0 /* End Collection */
+};
+
static __u8 *kye_consumer_control_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize, int offset, const char *device_name) {
/*
@@ -335,6 +466,12 @@ static __u8 *kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
*rsize = sizeof(easypen_m610x_rdesc_fixed);
}
break;
+ case USB_DEVICE_ID_KYE_PENSKETCH_M912:
+ if (*rsize == PENSKETCH_M912_RDESC_ORIG_SIZE) {
+ rdesc = pensketch_m912_rdesc_fixed;
+ *rsize = sizeof(pensketch_m912_rdesc_fixed);
+ }
+ break;
case USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE:
rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 104,
"Genius Gila Gaming Mouse");
@@ -418,6 +555,7 @@ static int kye_probe(struct hid_device *hdev, const struct hid_device_id *id)
case USB_DEVICE_ID_KYE_MOUSEPEN_I608X:
case USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2:
case USB_DEVICE_ID_KYE_EASYPEN_M610X:
+ case USB_DEVICE_ID_KYE_PENSKETCH_M912:
ret = kye_tablet_enable(hdev);
if (ret) {
hid_err(hdev, "tablet enabling failed\n");
@@ -457,6 +595,8 @@ static const struct hid_device_id kye_devices[] = {
USB_DEVICE_ID_GENIUS_GX_IMPERATOR) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE,
USB_DEVICE_ID_GENIUS_MANTICORE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE,
+ USB_DEVICE_ID_KYE_PENSKETCH_M912) },
{ }
};
MODULE_DEVICE_TABLE(hid, kye_devices);
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index b27b3d3..488ec99 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -126,6 +126,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X, HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2, HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X, HID_QUIRK_MULTI_INPUT },
+ { USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_M912, HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_DUOSENSE, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_LTS1, HID_QUIRK_NO_INIT_REPORTS },
--
2.2.2
|
|
From: Vince H. <Vi...@Pl...> - 2015-02-13 20:30:23
|
Do you have a guess as to when your versions of huion and other devices will make it into the kernel by default? --------------- Vince |
|
From: Masaru H. <mh...@ne...> - 2015-02-13 06:36:25
|
Hello Nick Thanks for helping ugee. Ugee has two PID, one is 5543 the other is 28bd. So I have tried for Ugee EX07 based huion. -hid-ugee.c is based huion.c -hid-ids is added EX07(VID:PID=28bd:0071)/ -digimend.conf is added override hid-ugee * extra. -Makefile is added /lib/modules/*/extra/hid-ugee.ko. EX07 started move but it workd as if only touchpad. Please recommend me to edit. Best Regards, Masaru Hirano -- ========================================= 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: montero <sin...@gm...> - 2015-02-13 00:49:54
|
Hello: My OS is Ubuntu 14.4 and I have a tablet monitor Huion GT-220 (you can draw on the screen directly with the stylus, Cintiq style). On Krita Sketch, the tablet works just perfect. On GIMP, it works good but the stylus can't use the Pressure Sensitivity. On Krita and Krita Gemini, the stylus don't work on drawing zone (ok with menus) and the programs crashes always if I try to choose a tool and drawing. Please, tell me what I can do to help you to fix this problem. Thank you! Encarnacion |
|
From: Masaru H. <mh...@ne...> - 2015-02-03 00:55:08
|
Hello Nick Thanks for M1000L,M708,M860. They work fine. We use ubuntu-studio 14.04 for driver and dump. We use ubuntu-studio 12.04, 14.04, windows7, windows8.1 for application. They are all deferent machine. At first they are fresh install but there are many tablets to test. So every device are connected same machine for test without re-install. We have out-lined memo for preparing testing-enviroment and procedure as enclosed word file. Red lines shows collected data. Additional tests data are zip file. 1010B,EX07,M540,M708,M1000L,SP101(Penate10.1) If you need more data collection to work, please let me know. Best regards, Masaru Hirano Neoblast Inc. On 2015���01���25��� 23:05, Nikolai Kondrashov wrote: > Hello Masaru, > > On 01/22/2015 01:40 PM, Masaru Hirano wrote: >> Hello Nick >> >> Thanks for waiting for my reply. > > Congrats on getting well! > >> Tests are over. >> I have atatced the result. >> >> M1000L,M708,M860 are work fine. >> Thanks. > > Good. Could you please explain your testing method? > It is important to be sure the driver really works. > Have you tested on a fresh Linux install? Which distro? > > Could you please send the output of "evtest" command for one of the working > tablets when you do the "pen coordinates sample" as shown here: > > https://www.youtube.com/watch?v=ysYk8KLY98U > >> Other products will be collected the data. >> >> If you have information how to modify source code, >> please let me know. > > Sure. > > Thank you. > > 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: Nikolai K. <sp...@gm...> - 2015-01-31 10:35:39
|
Hi Yann, On 01/28/2015 12:42 PM, Yann Vernier wrote: > On Mon, 26 Jan 2015 10:33:16 +0200 > Nikolai Kondrashov <sp...@gm...> wrote: >> Could you please keep the maillist in the CC? Thank you. > > Certainly. I made a mistake when hitting reply, for which I apologize. > It was not my intent to exclude the list. Sure, no problem :) >> Hmm, from your description it seems to me that Linux notices it is missing and >> actively drops the interface with a bad descriptor, doesn't it? Or did I >> understand you wrong? > > It only drops it after failing to parse uninitialized data. > > drivers/hid/usbhid/hid-core.c usbhid_parse and hid_post_reset both call > hid_get_class_descriptor, which does check the size, but gives up after > four tries. Even so, having received some data it returns the incomplete > descriptor, i.e. instead of error (negative) it returns rsize-1 (as the > last byte is missing). It never attempted a larger read, so it did not > work around the bug in the PT-1001. > > In usbhid_parse (and hid_post_reset), the return value is only checked > for negative, not for wrong size, so the error is lost at this point. > This subtle bug changes the meaning of the received descriptor from > incomplete (truncated) to corrupted (padded, in this case with zero, > but kmalloc does not guarantee that). > > Since the error was lost, Linux proceeds to hid_parse_report. As the last > byte was never received, it has an erroneous value, and that's when the > parsing fails. Linux attempted to parse a byte that did not come from the > device. Had the descriptor been different up to that point, the corruption > could have gone unnoticed, producing arbitrary results. Linux only detected > a problem because a C0 was required. Thank you for a detailed explanation. Yes, it seems the error handling needs to be improved here. >> I think it is intentional, although presents a Windows-compatibility problem. >> Basically, IIRC, if Linux encounters a field with usage which should be mapped >> to the same event as a field previously seen in the same report descriptor, it >> assigns this field a higher event number. This might be limited to some event >> types. The HID_QUIRK_MULTI_INPUT quirk is used to make the driver create >> separate event devices for different report IDs to avoid this. > > Interesting. MULTI_INPUT might be appropriate to separate mouse and tablet > mode in the PT-1001, as they produce different reports. Yes, it will help there. > The strange part, comparing to the report descriptors, is that the button > meanings generally don't match up at all, even on the second interface where > all buttons have usages and none collide. The anti-collission support one > might expect would allocate different generic buttons rather than six copies > of "unknown" sprinkled among a rather random selection. Yes, it's quite hairy. > I have attached an initial draft of a pt1001 descriptor patch driver, but > it still has some issues: > > For some reason, hid-generic still takes priority when choosing driver. > I have to unbind hid-generic to use this driver. Yes, the generic driver takes over everything it doesn't know about and the official solution for out-of-tree drivers is to rebind. For that reason digimend-kernel-drivers installs the rebinding script and udev rules. See hid-rebind.rules, and hid-rebind. > The button usages still don't show through, and worse, the stylus tip and > second barrel (reported as eraser) button both show as button 1. Using > input-events seems to explain this as them being reported as touch, > stylus and button 0; the expected set was stylus, barrel and eraser. > With this button setup xinput mapping cannot separate them. I'm not sure why, but Eraser usage (0x45) doesn't seem to be mapped explicitly and goes to the "unknown" label in hidinput_configure_usage(), probably being mapped to BTN_0 in map_key() from there. > multi_input did help in that both tablet and mouse mode work, and the > modified descriptor (with digitizer rather than pointer) makes tablet > mode function correctly except for the button SNAFU. > > I will probably pick this little project up again after FOSDEM. Cool, you're going to FOSDEM, I'm envious :) I'll be going to devconf.cz next week myself, so will likely reply even slower than usual. 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. 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 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. > /* 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. > 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? Nick |
|
From: Yann V. <yan...@or...> - 2015-01-28 10:43:06
|
On Mon, 26 Jan 2015 10:33:16 +0200 Nikolai Kondrashov <sp...@gm...> wrote: > Hi Yann, > > Could you please keep the maillist in the CC? Thank you. Certainly. I made a mistake when hitting reply, for which I apologize. It was not my intent to exclude the list. > On 01/26/2015 01:01 AM, Yann Vernier wrote: > > On Sun, 25 Jan 2015 16:41:04 +0200 > > Nikolai Kondrashov <sp...@gm...> wrote: > >> On 01/20/2015 03:46 PM, Yann Vernier wrote: > >>> Possible workarounds include patching in that extra byte or requesting more > >>> (both tested and work). A proper fix would probably include not trying to > >>> parse more descriptor data than the device actually returned. > >> > >> Well, such fix still wouldn't work with devices which would get a more > >> important part of their report descriptor lost. Then, making the parser handle > >> all the possible failures it introduces would make it too complicated. > > > > Yes, attempting to guess the missing data is a bad idea. The current behaviour > > of not even noticing that it is missing isn't really much better, however. > > However, if I just make sure to request a larger size I get the correct amount. > > Hmm, from your description it seems to me that Linux notices it is missing and > actively drops the interface with a bad descriptor, doesn't it? Or did I > understand you wrong? It only drops it after failing to parse uninitialized data. drivers/hid/usbhid/hid-core.c usbhid_parse and hid_post_reset both call hid_get_class_descriptor, which does check the size, but gives up after four tries. Even so, having received some data it returns the incomplete descriptor, i.e. instead of error (negative) it returns rsize-1 (as the last byte is missing). It never attempted a larger read, so it did not work around the bug in the PT-1001. In usbhid_parse (and hid_post_reset), the return value is only checked for negative, not for wrong size, so the error is lost at this point. This subtle bug changes the meaning of the received descriptor from incomplete (truncated) to corrupted (padded, in this case with zero, but kmalloc does not guarantee that). Since the error was lost, Linux proceeds to hid_parse_report. As the last byte was never received, it has an erroneous value, and that's when the parsing fails. Linux attempted to parse a byte that did not come from the device. Had the descriptor been different up to that point, the corruption could have gone unnoticed, producing arbitrary results. Linux only detected a problem because a C0 was required. > >>> I do suggest requesting more than the descriptor length by default, since > >>> this bug may be present in other devices (possibly as a misinterpretation of > >>> USB's use of a full frame to indicate more data is available). My own test > >>> was simply to add 1 to rsize and dev_rsize in kmalloc and > >>> hid_get_class_descriptor calls within drivers/hid/usbhid/hid-core.c, but > >>> that doesn't check how much was actually received. > >> > >> This would be one controversial solution. How much more would we need to > >> request? Would this encourage more sloppy HID descriptors in the future? When > >> should we stop requesting more and more? > > > > The descriptor isn't actually corrupt, only the transfer is incomplete. > > The descriptor is 317 bytes. > > Linux requests 317 bytes, and receives 316 bytes because of the device bug. > > Linux does not check the size received and therefore not only fails in > > parsing the descriptor but reports a different problem (failing to parse a > > byte that was never received in the first place). > > Windows requests 317+64 bytes, and receives 317 bytes. > > If I make Linux request 317+1 bytes, I get 317 bytes, forming the complete > > descriptor. > > > > The main reason I believe we could safely request a larger size from most > > HID devices is that Windows apparently already does. Then again, I would > > not be terribly surprised if a modern console used that behaviour to > > trigger weirdness (we've seen them abuse USB before). An alternative that > > could reasonably work is just attempting rsize+1 if we get an incomplete > > descriptor on the first try. The advantage is that it would only affect > > devices that were displaying bad behaviour in the first place. > > Sorry, I might have misunderstood you. I'll need to read the Linux USB code to > talk about this. > >>> That's not the end of the story, however. Even with proper parsing of the > >>> descriptors it seems the tablet only has one interface that reports a stylus, > >>> and it's not the one sending events. This causes the Xorg driver to deduce it > >>> is a touchpad, not a pen tablet, with all the resulting defects (relative > >>> mode, ignoring events when the nib isn't pressed). It also reports a rather > >>> mystifying set of buttons (from xinput list-props, but do come from kernel, > >>> as confirmed using input-events): > >>> Button Labels (276): "Button Left" (145), "Button Middle" (146), > >>> "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149), > >>> "Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151), > >>> "Button Side" (265), "Button Extra" (266), "Button Forward" (714), > >>> "Button Back" (715), "Button Task" (716), "Button Unknown" (264), > >>> "Button Unknown" (264), "Button Unknown" (264), "Button Unknown" (264) > >>> The second pointer device reported, which does not produce events, has an > >>> equally useless button map: > >>> "Button 0" (630), "Button Unknown" (264), "Button Unknown" (264), > >>> "Button Wheel Up" (148), "Button Wheel Down" (149) > >>> > >>> The actual buttons (nib and two side buttons on the stylus) are those > >>> reported as Forward, Back and Task. Remapping them with xinput set-button-map > >>> and setting absolute mode makes it usable but with the serious issue of not > >>> moving the pointer if the nib isn't pressed (the pressure level works in > >>> inkscape). I did not find a way to tell Xorg's evdev driver that the device > >>> is a tablet. > >> > >> Windows report descriptor parsing works quite differently from Linux and such > >> mapping issues happen often. > > > > I suspect there's actually a parsing bug in Linux here, as the kernel values > > barely have any similarities to the descriptors themselves. The first five on > > interface 1 match (being the boot protocol mouse buttons), as do the axis, > > but none of the other buttons do - interface 2 doesn't even have five > > buttons (it has four). I might try to figure out what the kernel HID parser > > did later. > > I think it is intentional, although presents a Windows-compatibility problem. > Basically, IIRC, if Linux encounters a field with usage which should be mapped > to the same event as a field previously seen in the same report descriptor, it > assigns this field a higher event number. This might be limited to some event > types. The HID_QUIRK_MULTI_INPUT quirk is used to make the driver create > separate event devices for different report IDs to avoid this. Interesting. MULTI_INPUT might be appropriate to separate mouse and tablet mode in the PT-1001, as they produce different reports. The strange part, comparing to the report descriptors, is that the button meanings generally don't match up at all, even on the second interface where all buttons have usages and none collide. The anti-collission support one might expect would allocate different generic buttons rather than six copies of "unknown" sprinkled among a rather random selection. I have attached an initial draft of a pt1001 descriptor patch driver, but it still has some issues: For some reason, hid-generic still takes priority when choosing driver. I have to unbind hid-generic to use this driver. The button usages still don't show through, and worse, the stylus tip and second barrel (reported as eraser) button both show as button 1. Using input-events seems to explain this as them being reported as touch, stylus and button 0; the expected set was stylus, barrel and eraser. With this button setup xinput mapping cannot separate them. multi_input did help in that both tablet and mouse mode work, and the modified descriptor (with digitizer rather than pointer) makes tablet mode function correctly except for the button SNAFU. I will probably pick this little project up again after FOSDEM. |
|
From: Nikolai K. <sp...@gm...> - 2015-01-26 08:33:30
|
Hi Yann, Could you please keep the maillist in the CC? Thank you. On 01/26/2015 01:01 AM, Yann Vernier wrote: > On Sun, 25 Jan 2015 16:41:04 +0200 > Nikolai Kondrashov <sp...@gm...> wrote: >> On 01/20/2015 03:46 PM, Yann Vernier wrote: >>> Possible workarounds include patching in that extra byte or requesting more >>> (both tested and work). A proper fix would probably include not trying to >>> parse more descriptor data than the device actually returned. >> >> Well, such fix still wouldn't work with devices which would get a more >> important part of their report descriptor lost. Then, making the parser handle >> all the possible failures it introduces would make it too complicated. > > Yes, attempting to guess the missing data is a bad idea. The current behaviour > of not even noticing that it is missing isn't really much better, however. > However, if I just make sure to request a larger size I get the correct amount. Hmm, from your description it seems to me that Linux notices it is missing and actively drops the interface with a bad descriptor, doesn't it? Or did I understand you wrong? >>> I do suggest requesting more than the descriptor length by default, since >>> this bug may be present in other devices (possibly as a misinterpretation of >>> USB's use of a full frame to indicate more data is available). My own test >>> was simply to add 1 to rsize and dev_rsize in kmalloc and >>> hid_get_class_descriptor calls within drivers/hid/usbhid/hid-core.c, but >>> that doesn't check how much was actually received. >> >> This would be one controversial solution. How much more would we need to >> request? Would this encourage more sloppy HID descriptors in the future? When >> should we stop requesting more and more? > > The descriptor isn't actually corrupt, only the transfer is incomplete. > The descriptor is 317 bytes. > Linux requests 317 bytes, and receives 316 bytes because of the device bug. > Linux does not check the size received and therefore not only fails in > parsing the descriptor but reports a different problem (failing to parse a > byte that was never received in the first place). > Windows requests 317+64 bytes, and receives 317 bytes. > If I make Linux request 317+1 bytes, I get 317 bytes, forming the complete > descriptor. > > The main reason I believe we could safely request a larger size from most > HID devices is that Windows apparently already does. Then again, I would > not be terribly surprised if a modern console used that behaviour to > trigger weirdness (we've seen them abuse USB before). An alternative that > could reasonably work is just attempting rsize+1 if we get an incomplete > descriptor on the first try. The advantage is that it would only affect > devices that were displaying bad behaviour in the first place. Sorry, I might have misunderstood you. I'll need to read the Linux USB code to talk about this. >> I would say we simply replace the device descriptor with a rewritten >> descriptor as is done for many other devices already. See hid-uclogic.c for >> example. > > That would allow us to clean it up for better describing the device (such as > it having a stylus), as you noted below. I'll set about doing so tomorrow, > I think. Great! >>> That's not the end of the story, however. Even with proper parsing of the >>> descriptors it seems the tablet only has one interface that reports a stylus, >>> and it's not the one sending events. This causes the Xorg driver to deduce it >>> is a touchpad, not a pen tablet, with all the resulting defects (relative >>> mode, ignoring events when the nib isn't pressed). It also reports a rather >>> mystifying set of buttons (from xinput list-props, but do come from kernel, >>> as confirmed using input-events): >>> Button Labels (276): "Button Left" (145), "Button Middle" (146), >>> "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149), >>> "Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151), >>> "Button Side" (265), "Button Extra" (266), "Button Forward" (714), >>> "Button Back" (715), "Button Task" (716), "Button Unknown" (264), >>> "Button Unknown" (264), "Button Unknown" (264), "Button Unknown" (264) >>> The second pointer device reported, which does not produce events, has an >>> equally useless button map: >>> "Button 0" (630), "Button Unknown" (264), "Button Unknown" (264), >>> "Button Wheel Up" (148), "Button Wheel Down" (149) >>> >>> The actual buttons (nib and two side buttons on the stylus) are those >>> reported as Forward, Back and Task. Remapping them with xinput set-button-map >>> and setting absolute mode makes it usable but with the serious issue of not >>> moving the pointer if the nib isn't pressed (the pressure level works in >>> inkscape). I did not find a way to tell Xorg's evdev driver that the device >>> is a tablet. >> >> Windows report descriptor parsing works quite differently from Linux and such >> mapping issues happen often. > > I suspect there's actually a parsing bug in Linux here, as the kernel values > barely have any similarities to the descriptors themselves. The first five on > interface 1 match (being the boot protocol mouse buttons), as do the axis, > but none of the other buttons do - interface 2 doesn't even have five > buttons (it has four). I might try to figure out what the kernel HID parser > did later. I think it is intentional, although presents a Windows-compatibility problem. Basically, IIRC, if Linux encounters a field with usage which should be mapped to the same event as a field previously seen in the same report descriptor, it assigns this field a higher event number. This might be limited to some event types. The HID_QUIRK_MULTI_INPUT quirk is used to make the driver create separate event devices for different report IDs to avoid this. >> Wow! This is the first tablet I see that is trying to actually convert >> various working area events into something else in *hardware*, i.e. on the >> device side. All others do this in the driver. > > I expect it's a firmware thing. Sure. > It does peculiar things including translating three virtual sliders into > different types of events (mouse scroll by emulated mouse buttons, volume > and zoom via keyboard keys) and plenty of regions send key combinations such > as Ctrl+C rather than a HID keycode with assigned meaning. Well, sending particular, Windows-oriented key combinations (at least for real on-the-frame buttons) is common among graphics tablets. > The PCB is marked 155-D, and has a Polostar controller marked TB92E and > A941K0420G1 (in the one I opened). The only other IC was an opamp. It might > have a command to report raw tablet data, like the Huion tablets, which would > make sense of interface 2. Finding it would be trickier since there is no > driver; it's clearly designed to operate with Windows' generic drivers. > http://www.polostar-tech.com/ appears to be the correct company. Thanks, I might take a look at them later. I think it's actually not a bad thing of them to try to make it work without a driver. >> This X.org heuristic is pretty hairy, yes, but we can still cater to it by >> using appropriate report descriptor(s). >> >> So, I think the path to a solution here should be making a separate HID driver >> for this tablet and having a new set of report descriptors written, replacing >> the original ones. Perhaps with some bit tweaking of the input reports as >> well. > > The formats described seem to work just fine; it just has a few more mystery > reports than I've observed in use. I'll try overriding the button usage codes. Alright. >> You can take hid-uclogic.c for boilerplate, as the most basic HID driver at >> the moment doing similar things. If you know how report descriptors work you >> can try making one yourself. I can suggest using my hidrd-convert [1] tool for >> authoring, although there are a few others. You can find some examples of >> rewritten descriptor XML sources in our tablets repo [2] - search for >> "fixed*.xml". > > The descriptors I attached to my first mail were decoded with hidrd-convert. Ah, sorry, forgot to look at the attachments in a hurry. > I should be able to alter them sensibly with the help of the public HID specs. Good. Don't hesitate to write, if something is not obvious there. Perhaps I'll be able to help. Nick |
|
From: Mike S. <mik...@gm...> - 2015-01-26 08:15:32
|
Nick, udevadm.log file is attached. Mike On 26/01/15 07:24, Nikolai Kondrashov wrote: > On 01/26/2015 12:36 AM, Mike Sapsard wrote: >> Nick, >> >> hid-rebind modified as requested. The syslog file is attached. > > Thank you. So it's not being called at all. > > Could you please disconnect the tablet, start this command: > > sudo udevadm monitor -p -k -u >udevadm.log > > connect the tablet, wait a second, stop the command with Ctrl-C and > send me > the resulting udevadm.log file? > > Thank you. > > Nick |
|
From: Nikolai K. <sp...@gm...> - 2015-01-26 07:31:11
|
Hi Vince, On 01/26/2015 06:33 AM, Vince Herried wrote: > Do you have a list of tablets that work with the wacom driver. > I have the kde incident. If you could send the hex ids brand name and model > I could add them to the incident. To see if they would add them to the kde > tablet setup. Sorry, I don't have a list. Judging from what I've seen xf86-input-wacom would more-or-less work with any tablet reporting pen proximity nowadays. Also, I don't think it is productive to even have such list. The Wacom developers can about manage the Wacom tablet list, but if we start tracking all tablets out there that would be a hit on our development time. I'd rather have the system judge the tablets by their actual capabilities than by IDs. Nick |
38 messages has been excluded from this view by a project administrator.
