On Fri, Dec 8, 2017 at 2:24 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> On 12/08/2017 01:24 PM, Jason Gerecke wrote:
>> Sorry about the delay in getting back to you on this issue. It looks
>
> No problem at all. Thanks for looking into it!
>
>> like there are several different reasons that we could be getting
>> EREMOTEIO from the lower levels. Would you mind running the sysinfo.sh
>> script described at [1] and filing a bug to the project with the
>> output attached?
>
> Done:
> https://github.com/linuxwacom/wacom-hid-descriptors/issues/9
>
>> This should give me an idea of what kind of hardware
>> is present in your 920. You might also try doing the following to see
>> if anything interesting gets printed to the dmesg log:
>>
>> # echo "file drivers/i2c/*.c +p" > /sys/kernel/debug/dynamic_debug/control
>> # modprobe -r wacom
>> # modprobe wacom
>
> Seems to say:
>
> # echo "file drivers/i2c/*.c +p" > /sys/kernel/debug/dynamic_debug/control
> -bash: /sys/kernel/debug/dynamic_debug/control: Operation not permitted
>
>>
>> Some of the I2C modules (which I suspect your sensor is using) log
>> debug messages prior to returning EREMOTEIO. The above will cause
>> these debug messages to be printed to dmesg and then reload the wacom
>> module. With luck, we might gain a little more information about
>> what's triggering the error.
>
> Sadly not... but I will poke and it and see if I can figure out why it's
> not working.
>
> kevin
>
Thanks for the sysinfo output :) It looks like your system has the
sensor connected through a designware I2C controller. The only place I
see EREMOTEIO used within the designware driver is to signal that it
got a NAK at some point during the transfer. It is supposed to print
out additional details using dev_dbg, but that won't be useful until
the "Operation not permitted" error is overcome.
Some NAK conditions are transient, so its possible that our driver
just needs to retry the command. Please read the page at [1] for
instructions to compile out out-of-tree version of the wacom driver.
In place of the "Download" instructions on that page, use the
"Development" instructions. Once you're set, apply the attached patch
by running `git am /path/to/file.patch` from within the input-wacom
directory. Compile the driver and then load it in place of the system
driver by running `sudo modprobe -r wacom && sudo insmod
4.5/wacom.ko`. Check to see if there's any interesting dmesg output
and if the pen works.
[1]: http://linuxwacom.sourceforge.net/wiki/index.php/Input-wacom
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
From 1f846c7d78034b1946080cc9ffb6672f5cfe638c Mon Sep 17 00:00:00 2001
From: Jason Gerecke <killertofu@xxxxxxxxx>
Date: Mon, 11 Dec 2017 10:16:11 -0800
Subject: [PATCH input-wacom] TEST: Always retry in get/set report
---
4.5/wacom_sys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/4.5/wacom_sys.c b/4.5/wacom_sys.c
index 39aaab0..036b5bb 100644
--- a/4.5/wacom_sys.c
+++ b/4.5/wacom_sys.c
@@ -52,7 +52,7 @@ static int wacom_get_report(struct hid_device *hdev, u8 type, u8 *buf,
do {
retval = hid_hw_raw_request(hdev, buf[0], buf, size, type,
HID_REQ_GET_REPORT);
- } while ((retval == -ETIMEDOUT || retval == -EAGAIN) && --retries);
+ } while (--retries);
if (retval < 0)
hid_err(hdev, "wacom_get_report: ran out of retries "
@@ -69,7 +69,7 @@ static int wacom_set_report(struct hid_device *hdev, u8 type, u8 *buf,
do {
retval = hid_hw_raw_request(hdev, buf[0], buf, size, type,
HID_REQ_SET_REPORT);
- } while ((retval == -ETIMEDOUT || retval == -EAGAIN) && --retries);
+ } while (--retries);
if (retval < 0)
hid_err(hdev, "wacom_set_report: ran out of retries "
--
2.15.1
