Re: [DIGImend-devel] Analysis of Gimp Issues and Proposed Solution

[Nikolai K. <sp...@gm...>]

Hi Dan,

On 02/22/2015 05:17 AM, Dan Roberts wrote:
> Hi Everyone,
>      I believe I've identified the condition under which Gimp does or does not work with my Huion H610, in line with earlier speculation. It seems that X.org is inconsistent when assigning XIDs to devices. I'm not certain why this is (could be in X.org, udev, or xf86-input-evdev, I believe it's not in the kernel), but I can show that this is the case. Attached is a log of my bash session during these tests. I will also copy the most relevant portions here.
>
> *The summary is that if the pen interface receives the lowest XID from X.org, Gimp works properly, otherwise it does not work properly. I propose a mitigation strategy below.*
> *
> *
> To test this I compared the output from xinput list-props {13..15} | grep "Button Labels" to whether Gimp functioned properly or not. I identified 13..15 as the correct XIDs using xinput prior to conducting this experiment.
>
> The following are the output for when Gimp functioned (confirmed multiple times, see logs):
>
> $ xinput list-props {13..15} | grep "Button Labels"
> *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)*
> Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
> Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
>
> The following are the output for when Gimp did not function:
>
> $ xinput list-props {13..15} | grep "Button Labels"
> Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
> *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)*
> Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
>
> $ xinput list-props {13..15} | grep "Button Labels"
> Button Labels (271):"Button 0" (285), "Button Unknown" (255), "Button Unknown" (255), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144)
> Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142), "Button Horiz Wheel Left" (143), "Button Horiz Wheel Right" (144), "Button Side" (256), "Button Extra" (257), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255), "Button Unknown" (255)
> *Button Labels (271):"Button Left" (138), "Button Middle" (139), "Button Right" (140), "Button Wheel Up" (141), "Button Wheel Down" (142)*
>
> As you can see the pen interface (with labels Button Left, Middle, Right, Wheel Up, Wheel Down only) having id 13 correlates with correct functioning of Gimp. I believe this is because Gimp (and Gtk+?) do not identify devices by anything more than their string name. You can open ~/.gimp-2.8/devicerc (or 2.6, I believe newer versions use ~/.config/gimp or similar) and observe that no identifying information other than the device name is stored.
>
> *Mitigation Strategy*
>
> To mitigate this problem, I propose renaming the pen interface in the kernel module, like in this simple patch:
>
> diff --git a/hid-uclogic.c b/hid-uclogic.c
> index 23fa0fb..697dca6 100644
> --- a/hid-uclogic.c
> +++ b/hid-uclogic.c
> @@ -838,6 +838,7 @@ static int uclogic_probe(struct hid_device *hdev, const struct hid_device_id *id
>                                  hid_err(hdev, "tablet enabling failed\n");
>                                  return rc;
>                          }
> +                       strlcat(hdev->name, " Pen", sizeof(hdev->name));
>                  }
>                  break;
>          case USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60:
>
> This simply appends Pen to the device name, disambiguating the device in Gimp's view. I have not been able to reproduce the Gimp issues when using this patched version of the module (and it doesn't require disabling the other interfaces). I have confirmed that Gimp functions properly even in cases where the Pen interface has a higher XID than the other interfaces. If my understanding of the issue is correct, then this does resolve the Gimp issues. I don't, however, know whether this breaks any kernel style rules, at the very least it's a handy hack I think is useful, and perhaps people who have had trouble with Gimp would be willing to try it. Any brave souls who wish to try it out can find the source here https://github.com/Ademan/digimend-kernel-drivers/archive/rename_pen.zip note it only works for devices with the same VID:PID as the H610 for the moment. I did not feel comfortable extending support to tablets I can't test.
>
> Attached are the raw logs of my bash session testing, with the exception of removing my hostname, and a slightly friendlier version where I removed redundant information. You can note from the dmesg output that the XIDs assigned don't appear to be dependent on dmesg's log order. Astute readers will notice messages from both the huion and uclogic modules. I re-conducted this test with the huion module removed, the results were identical. Raw logs may be found in the attached file rawlog-uclogic-only.txt
>
> Nick,
>     In particular I'd like your input on whether this is a viable mitigation
>     strategy. If I'm not mistaken, the abstract keyboard branch disables the
>     tablet buttons, whereas this allows users to have Gimp work correctly
>     *and* potentially have working tablet buttons.

Thanks for a thorough investigation, Dan!

I believe you're correct. This was a problem for a long while and there were
some patches to add clarifications to event device names in the past. I wanted
to implement something generic myself to avoid catering to each tablet, but
never got around to it.

Your approach is fine. However, I think we can go with patches Benjamin
Tissoires posted recently [1]. Those prepare the Huion driver for the current
libinput development and also add clarifications to event device names.

The effect will be the same, but the implementation will also include
future-proofing. I'm awaiting a pull request from him with those changes.

Nick

[1] http://www.spinics.net/lists/linux-input/msg36675.html