Hi Jiri, Eric,
On Tue, Jul 29, 2014 at 5:50 AM, Jiri Kosina <jkosina@xxxxxxx> wrote:
> On Thu, 24 Jul 2014, Éric Brunet wrote:
>
>> I have a HP EliteBook Revolve 810 (which is a hybrid laptop/tablet) with
>> the HP active pen that goes with it. I have installed fedora 20 (kernel
>> 3.15.6-200.fc20.x86_64) on this, and the pen does not work out of the box.
>> Playing with evtest, it appears that the kernel reports the X coordinate in
>> ABS_X and in ABS_Y, while the Y coordinate goes into ABS_Z and ABS_RX; here
>> are a few lines of output:
>>
>> Event: time 1406153996.865044, -------------- SYN_REPORT ------------
>> Event: time 1406153996.873047, type 3 (EV_ABS), code 0 (ABS_X), value 1087
>> Event: time 1406153996.873047, type 3 (EV_ABS), code 1 (ABS_Y), value 1087
>> Event: time 1406153996.873047, type 3 (EV_ABS), code 2 (ABS_Z), value 1599
>> Event: time 1406153996.873047, type 3 (EV_ABS), code 3 (ABS_RX), value 1599
>>
>> Of course, XOrg's evdev driver is confused and the pointer is stuck on the
>> diagonal X=Y.
>>
>> I guess this hardware needs a new quirk to usbhid, unless there is already
>> a way to correct it ?
>>
>> Here is the content of /sys/class/input/event8/device/uevent:
>>
>> PRODUCT=3/3eb/840b/111
>> NAME="Atmel Atmel maXTouch Digitizer Pen"
>> PHYS="usb-0000:00:1a.0-1.1/input0"
>> UNIQ=""
>> PROP=0
>> EV=1b
>> KEY=c01 1 0 0 0 0
>> ABS=100000f
>> MSC=10
>> MODALIAS=input:b0003v03EBp840Be0111-
>> e0,1,3,4,k100,140,14A,14B,ra0,1,2,3,18,m4,lsfw
>>
>> I hope I gave enough information on this. I don't read the mailing list,
>> please CC any answer.
>
> Does the patch below fix the problem for you please?
>
I have already seen this Atmel panel, and the problem was that they used twice X then twice Y to report coordinates:
0x05, 0x01, // Usage Page (Generic Desktop) 590
0x55, 0x0e, // Unit Exponent (-2) 592
0x65, 0x11, // Unit (Centimeter,SILinear) 594
0x35, 0x00, // Physical Minimum (0) 596
0x75, 0x10, // Report Size (16) 598
0x95, 0x02, // Report Count (2) 600
0x46, 0x00, 0x0a, // Physical Maximum (2560) 602
0x26, 0xff, 0x0f, // Logical Maximum (4095) 605
0x09, 0x30, // Usage (X) 608
0x81, 0x02, // Input (Data,Var,Abs) 610
0x46, 0xa0, 0x05, // Physical Maximum (1440) 612
0x26, 0xff, 0x0f, // Logical Maximum (4095) 615
0x09, 0x31, // Usage (Y) 618
0x81, 0x02, // Input (Data,Var,Abs) 620
I have no ideas why they did that, but this is a pretty bad idea. I thought at the time that it was just a prototype and that they would fix it for the release, but I was wrong.
I think, a better patch would simply consist in that:
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 2619f7f..b70d4c3 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -603,7 +603,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
if (field->flags & HID_MAIN_ITEM_RELATIVE)
map_rel(usage->hid & 0xf);
else
- map_abs(usage->hid & 0xf);
+ map_abs_clear(usage->hid & 0xf);
break;
case HID_GD_HATSWITCH:
-----
I have the report descriptors and some traces of it, so I could definitively make some more tests, but I will have to first finish the wacom bits I scheduled for today.
Eric, if you can give a shot to my patch (you can try Jiri's too, but I don't think it will work), that would simplify my process, and I will just have to reformat/submit it properly.
Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
