linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hutterer <peter.hutterer@who-t.net>
To: Dmitry Tunin <hanipouspilot@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>,
	linux-input <linux-input@vger.kernel.org>,
	Mathias Gottschlag <mgottschlag@gmail.com>
Subject: Re: Unusual Focaltech driver behavior
Date: Tue, 21 Apr 2015 15:35:20 +1000	[thread overview]
Message-ID: <20150421053520.GA19079@jelly.redhat.com> (raw)
In-Reply-To: <55312CA5.6090509@gmail.com>

On Fri, Apr 17, 2015 at 06:54:13PM +0300, Dmitry Tunin wrote:
> 
> 
> 17.04.2015 18:43, Benjamin Tissoires пишет:
> > On Fri, Apr 17, 2015 at 10:56 AM, Dmitry Tunin <hanipouspilot@gmail.com> wrote:
> >>
> >>
> >> 17.04.2015 17:49, Dmitry Tunin пишет:
> >>> 17.04.2015 16:57, Benjamin Tissoires пишет:
> >>>> On Fri, Apr 17, 2015 at 9:39 AM, Dmitry Tunin <hanipouspilot@gmail.com> wrote:
> >>>>>> Hi Dmitry,
> >>>>>>
> >>>>>> On Fri, Apr 17, 2015 at 5:56 AM, Dmitry Tunin <hanipouspilot@gmail.com> wrote:
> >>>>>>>> I noticed that myself and got some complaints like this.
> >>>>>>>> https://github.com/hanipouspilot/ubuntu-fixes/issues/2
> >>>>>>>>
> >>>>>>>> General issue is that when one finger is on the touchpad, movement of a second finger is ignored, if the first finger does not move.
> >>>>>>>> Usually with other touchpads, when you have one finger on the touchpad and move the other, it is recognized as two-finger scrolling.
> >>>>>>>> The device itself sends relative packages as normal in that case, but linux driver ignores them, until first finger is moved.
> >>>>>>>>
> >>>>>>>> I guess, Windows driver behaves same way. I can't test it, since I do not have Windows installed on that laptop.
> >>>>>>>>
> >>>>>>>> As I understood, Windows driver ignores that one finger is on button area and recognizes movement of the other as one-finger movement.
> >>>>>>>>
> >>>>>>>> It is clear that we do not know the full protocol or parameters of all touchpad models to have that button area always correct.
> >>>>>>>> But it looks like button area is set when 3rd byte in abs package is 00. There is a good chance that it is common for all touchpad models.
> >>>>>>>>
> >>>>>>>> Do you have ideas how to fix it the easiest way?
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Dmitry
> >>>>>>>>
> >>>>>>>
> >>>>>>> I looked at it some more and noticed that if I put one finger on touchpad, then another, then move the second one, rel packets are ignored.
> >>>>>>> But if keeping both fingers on touchpad, I move the first one, rel packets work OK.
> >>>>>>> This is wrong. I can't get what's wrong with the code at the moment.
> >>>>>>
> >>>>>>
> >>>>>> It looks like your touchpad is in the mouse emulation mode, not the
> >>>>>> raw touch mode. What you get is fed by the touchpad FW ans there is
> >>>>>> nothing we can do in userspace to fix that.
> >>>>>> That being said, there has been a lot of work with the focaltech
> >>>>>> drivers in the previous kernel releases, and maybe trying a v4.0 will
> >>>>>> switch your touchpad in the raw mode.
> >>>>>> Once it is in raw mode, the software buttons, scrolling and gestures
> >>>>>> are all treated in userspace and you will get the expected behavior.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Benjamin
> >>>>>>
> >>>>>
> >>>>> No, the mouse is in proprietary mode. Multitouch is supported. In emulation mode it is not supported at all.
> >>>>> I am testing actually the driver from kernel 4.0. Everything works great except this strange problem, when some relative packets are ignored.
> >>>>> I mentioned above the test case. Now I added some debug and trying to figure it out. But no success so far.
> >>>>>
> >>>>>
> >>>>
> >>>> If you are in absolute (raw) mode, then can you share the evemu-record
> >>>> of the gesture you are trying to support?
> >>>> We should be able to see what is going on and be able to pinpoint if
> >>>> this is a kernel problem or a user space problem.
> >>>>
> >>>> Cheers,
> >>>> Benjamin
> >>>>
> >>>
> >>> Here is the record. I put one finger on the touchpad and moved the other from top to bottom. This gesture is ignored.
> >>> But if I move first finger or both, it is recognized as scrolling
> > 
> > OK, this evemu-record is clean in term of protocol handling.
> > It looks like the first finger is in the middle of the touchpad.
> > Besides that I do not see any problems (and this works fine on Fedora
> > with libinput).
> > 
> > It must be a user-space problem. Can you tell us which distribution
> > you are using and which driver is handling the touchpad (xorg-evdev,
> > xorg-synaptics, xorg-libinput, wayland, mir)?
> > 
> > Benjamin
> 
> I am usung Ubuntu. I guess xorg-synaptics is handling the touchpad.

ok, in that case you'll need to file a bug, ideally in launchpad so we can
first rule out any ubuntu-specific patches. as Benjamin said, the recording
itself looks ok so this should work. You could try to give the
xf86-input-synaptics driver from git a try and see if it works.

either way, it doesn't look like a kernel problem at this point.

Cheers,
   Peter
--
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

      reply	other threads:[~2015-04-21  5:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17  8:44 Unusual Focaltech driver behavior Dmitry Tunin
2015-04-17  9:56 ` Dmitry Tunin
2015-04-17 13:33   ` Benjamin Tissoires
2015-04-17 13:39     ` Dmitry Tunin
2015-04-17 13:57       ` Benjamin Tissoires
2015-04-17 14:49         ` Dmitry Tunin
2015-04-17 14:56           ` Dmitry Tunin
2015-04-17 15:43             ` Benjamin Tissoires
2015-04-17 15:54               ` Dmitry Tunin
2015-04-21  5:35                 ` Peter Hutterer [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=20150421053520.GA19079@jelly.redhat.com \
    --to=peter.hutterer@who-t.net \
    --cc=benjamin.tissoires@gmail.com \
    --cc=hanipouspilot@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=mgottschlag@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).