On Thu, May 11, 2017 at 4:30 PM, Arek Burdach <arek.burdach@xxxxxxxxx> wrote:
>
>
> On 11.05.2017 14:50, Martin Kepplinger wrote:
>>
>>
>> On 2017-05-11 14:28, Benjamin Tissoires wrote:
>>>
>>> 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.
>>
>> ok. sounds a little more like a solution in the kernel would be
>> justified. Isn't it? It still feels dangerously ugly.
>>
>> Mainly I wanted to point out that if you somehow have to stay with "no"
>> for such broken devices, tslib would be a garbage can for userspace
>> workarounds. (in this case, most probably a new device-specific hidraw
>> based module).
>
> Sorry for a stupid question, but do we still discussing a solution for this
> device until Synaptics will correct firmware? What do you understand by
> firmware? A code in C compiled to kernel's module handling IRQs? Or a BIOS?
The firmware is the piece of code that is embedded in the touchscreen
chip, so property of Synaptics. Everything we can do us developers
will be a workaround.
To upgrade the firmware, some times you need to upgrade the BIOS
(UEFI) of your laptop, sometimes there is a different (but poprietary)
way of doing it.
>
> Why we need to think about workarounds and not just solve the problem in the
> root? Will it take a long time and we want to have a quick fix for similar
> cases or for other reasons?
That's in Synaptics' hands. If they say, yes, there is a bug on our
side we will fix it in an upgrade, then we don't need to do anything.
But given that Windows somewhat manages to not be affected, I guess
Synaptics won't bother fixing this just for us, Linux users.
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
