On Thu, May 11, 2017 at 4:30 PM, Arek Burdach [off-list ref] wrote:

On 11.05.2017 14:50, Martin Kepplinger wrote:

quoted

On 2017-05-11 14:28, Benjamin Tissoires wrote:

quoted

On Thu, May 11, 2017 at 1:47 PM, Martin Kepplinger
[off-list ref] wrote:

quoted

On 2017-05-11 13:28, Benjamin Tissoires wrote:

quoted

On Thu, May 11, 2017 at 1:22 PM, Martin Kepplinger
[off-list ref] wrote:

quoted

On 2017-05-11 12:12, Arek Burdach wrote:

quoted

On 11.05.2017 11:48, Martin Kepplinger wrote:

quoted

On 2017-05-10 11:36, Arek Burdach wrote:

quoted

Hi Andrew,

On 10.05.2017 01:47, Andrew Duggan wrote:

quoted

HI Arek,

On 05/09/2017 04:17 PM, Arek Burdach wrote:

quoted

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 :-)

quoted

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.

quoted

quoted

On 09.05.2017 16:02, Benjamin Tissoires wrote:

quoted

On Tue, May 9, 2017 at 2:51 PM, Arek Burdach
[off-list ref] wrote:

quoted

On 09.05.2017 14:20, Benjamin Tissoires wrote:

quoted

On Tue, May 9, 2017 at 11:20 AM, Arek Burdach
[off-list ref]
wrote:

quoted

Hi,

Thank you for response.

On 09.05.2017 10:35, Benjamin Tissoires wrote:

quoted

On Sat, May 6, 2017 at 9:28 PM, Arek Burdach
[off-list ref]
wrote:

quoted

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.

quoted

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?

quoted

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.

quoted

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