On Thu, May 11, 2017 at 1:47 PM, Martin Kepplinger <martin.kepplinger@xxxxxxxxxxxxx> wrote: > > > On 2017-05-11 13:28, Benjamin Tissoires wrote: >> On Thu, May 11, 2017 at 1:22 PM, Martin Kepplinger >> <martin.kepplinger@xxxxxxxxxxxxx> wrote: >>> >>> >>> On 2017-05-11 12:12, Arek Burdach wrote: >>>> >>>> >>>> On 11.05.2017 11:48, Martin Kepplinger wrote: >>>>> >>>>> On 2017-05-10 11:36, Arek Burdach wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> On 10.05.2017 01:47, Andrew Duggan wrote: >>>>>>> HI Arek, >>>>>>> >>>>>>> On 05/09/2017 04:17 PM, Arek Burdach wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've tried described by you solution: >>>>>>>> >>>>>>>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c >>>>>>>> index 37084b645785..81f271554b6c 100644 >>>>>>>> --- a/drivers/hid/hid-core.c >>>>>>>> +++ b/drivers/hid/hid-core.c >>>>>>>> @@ -2510,6 +2510,7 @@ static const struct hid_device_id >>>>>>>> hid_ignore_list[] = { >>>>>>> You need to add this to the hid_have_special_driver[] and not the >>>>>>> hid_ignore_list[]. >>>>>> Nice score for me - two lines and one bug :-) >>>>>> >>>>>>> But, if you do success in binding hid-rmi to a touchscreen it won't >>>>>>> work. The firmware between touchpads and touchscreens are different >>>>>>> enough that the hid-rmi driver will be looking for data which does not >>>>>>> exist in touchscreen's HID report. These differences also mean that it >>>>>>> really isn't a good idea to try to support touchscreens with hid-rmi. >>>>>>> It would actually result in more transactions and be less efficient >>>>>>> then simply using hid-multitouch. That's why hid-core checks for the >>>>>>> HID_SCAN_FLAG_GD_POINTER in an attempt to make sure it's binding to a >>>>>>> touchpad and not a touchscreen. >>>>>> It was just like you predict. On rmi, after first tap on screen, hidraw >>>>>> produced infinite number of events and it is not usable anymore. >>>>>> >>>>>> >>>>>>>> On 09.05.2017 16:02, Benjamin Tissoires wrote: >>>>>>>>> On Tue, May 9, 2017 at 2:51 PM, Arek Burdach >>>>>>>>> <arek.burdach@xxxxxxxxx> wrote: >>>>>>>>>> On 09.05.2017 14:20, Benjamin Tissoires wrote: >>>>>>>>>>> On Tue, May 9, 2017 at 11:20 AM, Arek Burdach >>>>>>>>>>> <arek.burdach@xxxxxxxxx> >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for response. >>>>>>>>>>>> >>>>>>>>>>>> On 09.05.2017 10:35, Benjamin Tissoires wrote: >>>>>>>>>>>>> On Sat, May 6, 2017 at 9:28 PM, Arek Burdach >>>>>>>>>>>>> <arek.burdach@xxxxxxxxx> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> A week ago I've reported a bug: >>>>>>>>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=195625 Is there >>>>>>>>>>>>>> anybody >>>>>>>>>>>>>> that >>>>>>>>>>>>>> can >>>>>>>>>>>>>> help me with it? >>>>>>>>>>>>> I can have a look at it. >>>>>>>>>>>>> Please attach the full outputs of hid-recorder and evemu-record >>>>>>>>>>>>> in the >>>>>>>>>>>>> bugs, or it'll be difficult for us to debug it. >>>>>>>>>>>> I've attached full logs for two situations. More details in the >>>>>>>>>>>> issue. >>>>>>>>>>> Thanks, looks like a firmware issue (I'll comment in the bug). >>>>>>>>>> Sorry for my noob questions, but do you suggest that it can't be >>>>>>>>>> fixed by >>>>>>>>>> changes in kernel modules and I need to report it to the >>>>>>>>>> manufacturer? >>>>>>>>> Yes. Though Andrew, in CC, works for Synaptics and might give us >>>>>>>>> some pointers. >>>>>>>>> >>>>>>>>>> If it so, do you have an idea why it works well on Windows? Do they >>>>>>>>>> have >>>>>>>>>> some strange hacks in their drivers? >>>>>>>>> I have no ideas how well it works under Windows, and I have no ideas >>>>>>>>> if there are some strange hacks in the Windows nor in the Syanptics >>>>>>>>> driver (I would assume so). >>>>>>>>> >>>>>>> We don't provide any drivers for touchscreens on Windows. So I don't >>>>>>> know how Microsoft is handling a situation like this. >>>>>> Do you know what should be changed in firmware to make hid-touchscreen >>>>>> driver works correctly? Or maybe you know someone who is responsible for >>>>>> firmware for this device and whom I can call to gather this information? >>>>>> >>>>> In case there *really* is broken firmware out there, we can specifically >>>>> identify via struct input_id's version number for example, >>>> I thought that Benjamin identified this as a broken firmware. I've >>>> attached hidraw log in the issue and there is no release event, so it >>>> looks like a firmware bug. How do you suggest to handle this situation >>>> in kernel? We can identify the device but what to do next if we have no >>>> information if user released finger or not? >>>> >>>>> I want to >>>>> point out that I would accept adding a workaround in tslib's input-raw >>>>> module ( http://tslib.org ) if it won't be done in the kernel. >>>>> >>>>> So, in case you can and want to use tslib as a workaround here, feel >>>>> free to have a look and send the patches that make input-raw.c work for >>>>> you over there. >>>> I want to be as handy as I can but I'm not sure how tslib could help in >>>> this situation. If we have too much data, it can filter out unnecessary >>>> events but I don't think that it can help when there is lack of events >>>> or I'm missing something? >>> >>> Might as well be, I might not have thought it all through, but in >>> tslib's module_raw input you can can get totally creative: Why not start >>> *every* sync frame with BTN_TOUCH 1 and end it with BTN_TOUCH 0? You >>> *are* able to add stuff. Filters don't usually do it though. >> >> Ouch, please don't. You'll send an endless click/release sequence >> which will break drag and drop, double click and so on. >> > > ah you're right, that's nonsense. > >> Also, this won't solve the issue because the multitouch slot will not >> be released. >> >> The only solution (which i believe the Windows driver does, but I >> believed only for Windows 7 compatible touchscreen), is to arm a timer >> for each slot, and when you don't receive an update after let's say 5 >> seconds, you release the slot. >> >> It's awful and I always have been against adding such pain in the >> hid-multitouch driver. > > yes. still breaks "move after hold>5s" but would probably be the only > way to make this somewhat work. No, you won't have "move after hold>5s" broken. Because at the HID level, the device is supposed to send an update on every touch when reporting a touch (for Windows 8 devices). So if there are tiny movements filtered at the input level in the kernel, we will get those and I suspect the timeout will only appear when the finger actual leaves the surface. Cheers, Benjamin > > ________________________________ > > Ginzinger electronic systems GmbH > Gewerbegebiet Pirath 16 > 4952 Weng im Innkreis > www.ginzinger.com > > Firmenbuchnummer: FN 364958d > Firmenbuchgericht: Ried im Innkreis > UID-Nr.: ATU66521089 > -- 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