On 2017-05-11 13:22, Martin Kepplinger 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?
I definitely haven't thought it through :) One would have to say it
diffently, and probably work on it properly:
for each sync frame, assume you got "pen_down" first, for this device.
take that sample (ts_sample or ts_sample_mt) and add a 2nd sample
containing only pen_up.
You are in tslib API world then, and should check the documentation on
how to use it.
but don't sue me if I'm just misleading you :)
martin
________________________________
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
