From: "Pali Rohár" <pali.rohar@gmail.com>
To: Hans de Goede <hdegoede@redhat.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, 1 Apr 2015 18:39:34 +0200 [thread overview]
Message-ID: <201504011839.34984@pali> (raw)
In-Reply-To: <551C1973.6060304@redhat.com>
[-- Attachment #1: Type: Text/Plain, Size: 2763 bytes --]
On Wednesday 01 April 2015 18:14:43 Hans de Goede wrote:
> 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.
>
Ok. It really needs documentation.
And I'm also for including fix to 4.0 stable kernel as this is
regression for those dell models.
> 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
No, there are no interleaved packets. All packets are 6-bytes
length, but some have swapped bits... When I saw those lot of
invalid packets I thought it is similar to ALPS_PS2_INTERLEAVED.
But not.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2015-04-01 16:39 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
2015-04-01 16:39 ` Pali Rohár [this message]
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=201504011839.34984@pali \
--to=pali.rohar@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-input@vger.kernel.org \
/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.