Some touchpad has middle key and it will be indicated in bit 2 of packet[0].
We need to fix V4 formation's byte mask to prevent error decoding.
Signed-off-by: KT Liao <[email protected]>
---
drivers/input/mouse/elantech.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index fb4d902..f39dc66 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -799,7 +799,7 @@ static int elantech_packet_check_v4(struct psmouse *psmouse)
else if (ic_version == 7 && etd->info.samples[1] == 0x2A)
sanity_check = ((packet[3] & 0x1c) == 0x10);
else
- sanity_check = ((packet[0] & 0x0c) == 0x04 &&
+ sanity_check = ((packet[0] & 0x08) == 0x00 &&
(packet[3] & 0x1c) == 0x10);
if (!sanity_check)
--
2.7.4
Hi KT,
On Mon, May 28, 2018 at 07:33:02PM +0800, KT Liao wrote:
> Some touchpad has middle key and it will be indicated in bit 2 of packet[0].
> We need to fix V4 formation's byte mask to prevent error decoding.
Could you please let me know what devices this patch fixes? Are they
released or new hardware?
>
> Signed-off-by: KT Liao <[email protected]>
> ---
> drivers/input/mouse/elantech.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index fb4d902..f39dc66 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -799,7 +799,7 @@ static int elantech_packet_check_v4(struct psmouse *psmouse)
> else if (ic_version == 7 && etd->info.samples[1] == 0x2A)
> sanity_check = ((packet[3] & 0x1c) == 0x10);
> else
> - sanity_check = ((packet[0] & 0x0c) == 0x04 &&
> + sanity_check = ((packet[0] & 0x08) == 0x00 &&
> (packet[3] & 0x1c) == 0x10);
>
> if (!sanity_check)
> --
> 2.7.4
>
Thanks.
--
Dmitry
Hi Dmitry,
-----Original Message-----
From: Dmitry Torokhov [mailto:[email protected]]
Sent: Wednesday, May 30, 2018 2:05 AM
To: KT Liao
Cc: [email protected]; [email protected];
[email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [PATCH] Input: elantech - Fix V4 report decoding for module
with middle key
Hi KT,
On Mon, May 28, 2018 at 07:33:02PM +0800, KT Liao wrote:
> Some touchpad has middle key and it will be indicated in bit 2 of
packet[0].
> We need to fix V4 formation's byte mask to prevent error decoding.
Could you please let me know what devices this patch fixes? Are they
released or new hardware?
The primary target is Lenovo thinkpad P52 and it will be released in 6/M.
force_crc_enabled will fix the issue too because less bit-check in the
specific byte.
I guess Fujitsu H730/H760 in elantech_dmi_force_crc_enabled may have the
same issue.
I leave them in DMI table because I am not sure of it.
Thanks
KT
>
> Signed-off-by: KT Liao <[email protected]>
> ---
> drivers/input/mouse/elantech.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/elantech.c
> b/drivers/input/mouse/elantech.c index fb4d902..f39dc66 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -799,7 +799,7 @@ static int elantech_packet_check_v4(struct psmouse
*psmouse)
> else if (ic_version == 7 && etd->info.samples[1] == 0x2A)
> sanity_check = ((packet[3] & 0x1c) == 0x10);
> else
> - sanity_check = ((packet[0] & 0x0c) == 0x04 &&
> + sanity_check = ((packet[0] & 0x08) == 0x00 &&
> (packet[3] & 0x1c) == 0x10);
>
> if (!sanity_check)
> --
> 2.7.4
>
Thanks.
--
Dmitry
On Wed, May 30, 2018 at 03:03:50PM +0800, 廖崇榮 wrote:
> Hi Dmitry,
>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:[email protected]]
> Sent: Wednesday, May 30, 2018 2:05 AM
> To: KT Liao
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: Re: [PATCH] Input: elantech - Fix V4 report decoding for module
> with middle key
>
> Hi KT,
>
> On Mon, May 28, 2018 at 07:33:02PM +0800, KT Liao wrote:
> > Some touchpad has middle key and it will be indicated in bit 2 of
> packet[0].
> > We need to fix V4 formation's byte mask to prevent error decoding.
>
> Could you please let me know what devices this patch fixes? Are they
> released or new hardware?
>
>
> The primary target is Lenovo thinkpad P52 and it will be released in 6/M.
>
> force_crc_enabled will fix the issue too because less bit-check in the
> specific byte.
> I guess Fujitsu H730/H760 in elantech_dmi_force_crc_enabled may have the
> same issue.
> I leave them in DMI table because I am not sure of it.
OK, thank you for the info. Applied.
>
> Thanks
> KT
> >
> > Signed-off-by: KT Liao <[email protected]>
> > ---
> > drivers/input/mouse/elantech.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/mouse/elantech.c
> > b/drivers/input/mouse/elantech.c index fb4d902..f39dc66 100644
> > --- a/drivers/input/mouse/elantech.c
> > +++ b/drivers/input/mouse/elantech.c
> > @@ -799,7 +799,7 @@ static int elantech_packet_check_v4(struct psmouse
> *psmouse)
> > else if (ic_version == 7 && etd->info.samples[1] == 0x2A)
> > sanity_check = ((packet[3] & 0x1c) == 0x10);
> > else
> > - sanity_check = ((packet[0] & 0x0c) == 0x04 &&
> > + sanity_check = ((packet[0] & 0x08) == 0x00 &&
> > (packet[3] & 0x1c) == 0x10);
> >
> > if (!sanity_check)
> > --
> > 2.7.4
> >
>
> Thanks.
>
> --
> Dmitry
>
--
Dmitry
On Thu, Jun 21, 2018 at 5:16 PM Dmitry Torokhov
<[email protected]> wrote:
>
> OK, thank you for the info. Applied.
Ugh. Dmitry, please be more careful with author names.
Apparently you aren't in a proper utf-8 locale, and you messed up the
name in the git repository. So yoiu apparently tried to take KT Liao's
Chinese name: 廖崇榮, but did so in some wrong locale, and it ended up
being just '???' in the git repo.
And I only noticed when I did my shortlog for doing my 4.18-rc3 release notes.
I don't know what locale or tools you have, but please try to make
sure everything is utf-8 aware so that these kinds of name corruptions
don't happen..
Linus
On Sun, Jul 01, 2018 at 04:30:44PM -0700, Linus Torvalds wrote:
> On Thu, Jun 21, 2018 at 5:16 PM Dmitry Torokhov
> <[email protected]> wrote:
> >
> > OK, thank you for the info. Applied.
>
> Ugh. Dmitry, please be more careful with author names.
>
> Apparently you aren't in a proper utf-8 locale, and you messed up the
> name in the git repository. So yoiu apparently tried to take KT Liao's
> Chinese name: 廖崇榮, but did so in some wrong locale, and it ended up
> being just '???' in the git repo.
>
> And I only noticed when I did my shortlog for doing my 4.18-rc3 release notes.
>
> I don't know what locale or tools you have, but please try to make
> sure everything is utf-8 aware so that these kinds of name corruptions
> don't happen..
Yeah, I noticed that when preparing pull request, but did not want to
rebase the branch that I always keep stable, sorry.
The reason it got messed up is I switched to pulling patches from
patchwork.kernel.org as it collects Acked-by and Reviewed-by tags so I
do not have to add them manually, but unfortunately it does not do
proper UTF-8:
https://patchwork.kernel.org/patch/10431971/
I have since reworked by scripts to only take changelog from patchwork,
and take author name/email from the mail message and using "git
mailinfo" which worked well before. Should not happen again.
Thanks.
--
Dmitry
On Sun, Jul 1, 2018 at 4:44 PM Dmitry Torokhov
<[email protected]> wrote:
>
> The reason it got messed up is I switched to pulling patches from
> patchwork.kernel.org as it collects Acked-by and Reviewed-by tags so I
> do not have to add them manually, but unfortunately it does not do
> proper UTF-8:
Ugh.
I made an 'issue' of it for patchwork:
https://github.com/getpatchwork/patchwork/issues/194
and hopefully that can be fixed. It's sad when we corrupt names like this.
Linus
On July 1, 2018 5:00:03 PM PDT, Linus Torvalds <[email protected]> wrote:
>On Sun, Jul 1, 2018 at 4:44 PM Dmitry Torokhov
><[email protected]> wrote:
>>
>> The reason it got messed up is I switched to pulling patches from
>> patchwork.kernel.org as it collects Acked-by and Reviewed-by tags so
>I
>> do not have to add them manually, but unfortunately it does not do
>> proper UTF-8:
>
>Ugh.
>
>I made an 'issue' of it for patchwork:
>
> https://github.com/getpatchwork/patchwork/issues/194
>
>and hopefully that can be fixed. It's sad when we corrupt names like
>this.
Might not even be an issue with recent patchwork, but unfortunately the version that is running on kernel.org is ancient as far as I know.
Thanks.
--
Dmitry
Dmitry Torokhov <[email protected]> writes:
> On July 1, 2018 5:00:03 PM PDT, Linus Torvalds <[email protected]> wrote:
>>On Sun, Jul 1, 2018 at 4:44 PM Dmitry Torokhov
>><[email protected]> wrote:
>>>
>>> The reason it got messed up is I switched to pulling patches from
>>> patchwork.kernel.org as it collects Acked-by and Reviewed-by tags so
>>I
>>> do not have to add them manually, but unfortunately it does not do
>>> proper UTF-8:
>>
>>Ugh.
>>
>>I made an 'issue' of it for patchwork:
>>
>> https://github.com/getpatchwork/patchwork/issues/194
>>
>>and hopefully that can be fixed. It's sad when we corrupt names like
>>this.
>
> Might not even be an issue with recent patchwork, but unfortunately
> the version that is running on kernel.org is ancient as far as I know.
FWIW I use patchwork.kernel.org and I don't have any issues with UTF-8
characters in the From header. For example, here's one patch which I
recently applied:
https://git.kernel.org/linus/88001968245c
But of course it depends on what tools you use (I have my own patchwork
script which downloads and applies the patch) or what characters there
were etc.
Also I heard that we should get an upgrade to patchwork.kernel.org in
the near future, which is great. The current version has some quirks
which are quite annoying.
--
Kalle Valo
On 07/02/2018 05:12 AM, Kalle Valo wrote:
> Dmitry Torokhov <[email protected]> writes:
>
>> On July 1, 2018 5:00:03 PM PDT, Linus Torvalds <[email protected]> wrote:
>>> On Sun, Jul 1, 2018 at 4:44 PM Dmitry Torokhov
>>> <[email protected]> wrote:
>>>>
>>>> The reason it got messed up is I switched to pulling patches from
>>>> patchwork.kernel.org as it collects Acked-by and Reviewed-by tags so
>>> I
>>>> do not have to add them manually, but unfortunately it does not do
>>>> proper UTF-8:
>>>
>>> Ugh.
>>>
>>> I made an 'issue' of it for patchwork:
>>>
>>> https://github.com/getpatchwork/patchwork/issues/194
>>>
>>> and hopefully that can be fixed. It's sad when we corrupt names like
>>> this.
>>
>> Might not even be an issue with recent patchwork, but unfortunately
>> the version that is running on kernel.org is ancient as far as I know.
>
> FWIW I use patchwork.kernel.org and I don't have any issues with UTF-8
> characters in the From header. For example, here's one patch which I
> recently applied:
>
> https://git.kernel.org/linus/88001968245c
>
> But of course it depends on what tools you use (I have my own patchwork
> script which downloads and applies the patch) or what characters there
> were etc.
>
> Also I heard that we should get an upgrade to patchwork.kernel.org in
> the near future, which is great. The current version has some quirks
> which are quite annoying.
>
I don't know if it's better or different, but there is also
https://lore.kernel.org/patchwork/
--
~Randy
On Mon, Jul 2, 2018 at 5:13 AM Kalle Valo <[email protected]> wrote:
>
> FWIW I use patchwork.kernel.org and I don't have any issues with UTF-8
> characters in the From header. For example, here's one patch which I
> recently applied:
>
> https://git.kernel.org/linus/88001968245c
Well, that one actually has at least two reasons why it might work well:
- Rafał sends his patches with an explicit "From:" line in the body
of the email itself (probably because he has had problems with email
headers in the past). So his body itself has
From: Rafał Miłecki <[email protected]>
- Also, even ignoring that, he actually uses utf-8 in the headers
too, so his "From" header line looks like
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <[email protected]>
so it is already in UTF-8, it just is rfc2047-encoded.
I suspect it's that first reason that patchwork.kernel.org gets it
right, but it *migth* be the fact that the problematic email is using
the old 'big5' encoding:
From: =?big5?B?ufmxUrph?= <[email protected]>
anyway, it does look like a newer version of patchwork will fix this.
Linus