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

[Dan R. <ade...@gm...>]

Hi Nick,
    I noticed you CCed the list with some of that discussion, I apologize I
had only skimmed it and assumed the entire patch set was about the button
functionality. I'm happy to test (Huion H610, not sure if it's different
from the Pro Benjamin has) when Benjamin has rebased his patches against
the out-of-tree drivers.

Thanks,
Dan

On Sun, Feb 22, 2015 at 4:46 AM, Nikolai Kondrashov <sp...@gm...>
wrote:

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