From: Hans de Goede <hdegoede@redhat.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>, linux-input@vger.kernel.org
Subject: Re: [PATCH FIX for 4.0 0/2] alps: Report alps v2 Dualpoint Stick events via the right event node
Date: Wed, 01 Apr 2015 18:14:43 +0200 [thread overview]
Message-ID: <551C1973.6060304@redhat.com> (raw)
In-Reply-To: <201504011811.03302@pali>
Hi,
On 01-04-15 18:11, Pali Rohár wrote:
> On Wednesday 01 April 2015 17:44:04 Hans de Goede wrote:
>> Hi Dmitry & Pali,
>>
>> While working on some libinput code to deal with trackpoints
>> of different model laptops having quite different speed /
>> sensitivity ootb, I noticed that with the current 4.0-rc#
>> kernels the trackpoint events on laptops with a PROTO_V2 alps
>> touchpad are no longer being send by the "Dualpoint Stick"
>> event node, instead a new "ALPS PS/2 Mouse" node gets created
>> and sends the trackpoint events.
>>
>> The cause of this is that the stick on these devices sends
>> bare ps/2 packets as data.
>>
>> Although this does not really break anything (atm, it does
>> break my libinput work), it is still wrong, esp. also since
>> the "Dualpoint Stick" node has the POINTING_STICK property
>> set, where as the "ALPS PS/2 Mouse" node which is actually
>> sending the stick events does not.
>>
>> If still possible I would like to see this fixes added to 4.0,
>> if not we should queue them up for stable.
>>
>> Regards,
>>
>> Hans
>
> Hi Hans, thanks for testing!
>
> I would like to see this observation also in alps protocol
> documentation, where is all information how are data from
> touchpads and tracksticks reported.
Good point, for today I'm already a bit late with logging
off, but I'll do a follow up patch for this tomorrow.
> Also for me it it makes sense to squash both patches into one.
I think having them separate is slightly better, but either
way is fine with me,
> And can you check if your change is needed only for
> ALPS_PS2_INTERLEAVED devices? For me it looks like that only
> those alps devices could mix both 3-bytes and 6-bytes packets...
That is what I expected in the beginning too, but no that is
not the case, this happens on my Latitude D620 too, and that
one does not use / set ALPS_PS2_INTERLEAVED.
Regards,
Hans
p.s.
Talking about ALPS_PS2_INTERLEAVED did you ever try that on the
current troublesome models which sometime get out of sync?
Maybe they are actually interleaving things again ?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-04-01 16:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 15:44 [PATCH FIX for 4.0 0/2] alps: Report alps v2 Dualpoint Stick events via the right event node Hans de Goede
2015-04-01 15:44 ` [PATCH 1/2] alps: Report bare packets coming from alps_handle_interleaved_ps2 via dev3 Hans de Goede
2015-04-01 15:44 ` [PATCH 2/2] alps: Report alps v2 Dualpoint Stick events via the right evdev node Hans de Goede
2015-04-01 16:11 ` [PATCH FIX for 4.0 0/2] alps: Report alps v2 Dualpoint Stick events via the right event node Pali Rohár
2015-04-01 16:14 ` Hans de Goede [this message]
2015-04-01 16:39 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=551C1973.6060304@redhat.com \
--to=hdegoede@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=pali.rohar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.