Re: [PATCH 4.1 026/159] Input: synaptics - fix handling of disabling gesture mode

[Josh Boyer]

On Tue, Sep 29, 2015 at 8:53 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 29, 2015 at 08:27:14AM -0400, Josh Boyer wrote:
>> On Sat, Sep 26, 2015 at 4:54 PM, Greg Kroah-Hartman
>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> > 4.1-stable review patch.  If anyone has any objections, please let me know.
>> >
>> > ------------------
>> >
>> > From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
>> >
>> > commit e51e38494a8ecc18650efb0c840600637891de2c upstream.
>> >
>> > Bit 2 of the mode byte has dual meaning: it can disable reporting of
>> > gestures when touchpad works in Relative mode or normal Absolute mode,
>> > or it can enable so called Extended W-Mode when touchpad uses enhanced
>> > Absolute mode (W-mode). The extended W-Mode confuses our driver and
>> > causes missing button presses on some Thinkpads (x250, T450s), so let's
>> > make sure we do not enable it.
>> >
>> > Also, according to the spec W mode "... bit is defined only in Absolute
>> > mode on pads whose capExtended capability bit is set. In Relative mode and
>> > in TouchPads without this capability, the bit is reserved and should be
>> > left at 0.", so let's make sure we respect this requirement as well.
>> >
>> > Reported-by: Nick Bowler <nbowler@xxxxxxxxxx>
>> > Suggested-by: Gabor Balla <gaborwho@xxxxxxxxx>
>> > Tested-by: Gabor Balla <gaborwho@xxxxxxxxx>
>> > Tested-by: Nick Bowler <nbowler@xxxxxxxxxx>
>> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
>> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>>
>> I believe Dmitry is going to revert this commit very shortly.  See
>>
>> http://www.spinics.net/lists/linux-input/msg41176.html
>>
>> You might want to leave this one out of both 4.2.y and 4.1.1y.
>
> I prefer to wait for stuff like this to hit Linus's tree to keep in
> sync, bugs at all at times.

Wait, what?  You're going to release a stable kernel with a patch that
is known to be buggy just to keep it in sync with a buggy upstream
Linus tree?  That doesn't make sense to me.  I would maybe understand
if the upstream solution wasn't "revert this" and instead had a follow
on patch, but knowing upstream is going to revert and still including
it is confusing.

At any rate, distros may wish to queue up the revert on top of 4.1.9 and 4.2.2.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/