From: "Henrik Rydberg" <rydberg@euromail.se> To: "Chung-Yih Wang (王崇懿)" <cywang@google.com> Cc: Chase Douglas <chase.douglas@canonical.com>, Daniel Kurtz <djkurtz@chromium.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, JJ Ding <dgdunix@gmail.com>, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48 Date: Fri, 20 Jul 2012 09:25:10 +0200 [thread overview] Message-ID: <20120720072510.GA986@polaris.bitmath.org> (raw) In-Reply-To: <CAM2ehZaLeJsxCOkqLv9jSko9y3Awix1jjobfTo5WQj8rcrYquA@mail.gmail.com> On Fri, Jul 20, 2012 at 11:14:25AM +0800, Chung-Yih Wang (王崇懿) wrote: > From our experiments, the assumption of "the slowest corner is the > stationary finger" is not always true. That is the major reason we want to > report the firmware data instead of semi-mt. Oh, but that was precisely the point; the reason it does not hold true is due to sensor and discretization errors. If we can improve upon this situation, we get a better model of reality. > The problem here will be how > to remove the pulling effect, we measured the pulling effect before and can > not get a good result as there could be IIR in firmware as well. It seems > not an easy job to remove the pulling effect cleanly. Probably a simple filter will work. If the bounding box is moving too fast for the tracked point to stay in the right corner, the solution is to use a smaller time step. In practise, keeping the tracked point as a state in the driver, and updating the bounding box using box -> (1 - m) box + m box_new. If the tracked point is in the right corner, let m = 1. If not, choose a smaller m. > > > * Add a new device property (INVALID_Y_AXIS_CROSSING?) that > > > describes the exact behavior of this device. I would be ok with this > > > if everyone else is, but only because proper clickpad behavior > > > (which I consider very importand) is broken without this knowledge. > > > Sounds good to me(but I would rather to have INVALID_CROSSING instead, > depending on the relative finger positions, it could still have wrong > tracking either in X or Y axis crossing) Propagating information about various sensor defects to userspace sounds horrid to me. The sooner we can forget about these devices, the better. > > > * Leave the device as SEMI_MT, but provide the real locations, and > > > allow userspace to determine the device vendor/model/etc. If > > > userspace knows that a specific device behaves in a specific way, it > > > can do its own quirking handling. Given the specificity of this > > > behavior to only some devices of one brand, this would be my > > > suggested resolution to the issue. > > > > A bit confused here, do you mean we report the real locations instead of > bounding box the current driver have? I am not quite sure if this will > affect other existing works in userspace for this semi-mt driver. I am not entirely opposed to this solution, but I would much rather see an attempt to improve the bounding box in the driver, since such a solution could be useful for other devices as well. Thanks, Henrik
WARNING: multiple messages have this Message-ID (diff)
From: "Henrik Rydberg" <rydberg@euromail.se> To: "Chung-Yih Wang (王崇懿)" <cywang@google.com> Cc: Chase Douglas <chase.douglas@canonical.com>, Daniel Kurtz <djkurtz@chromium.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, JJ Ding <dgdunix@gmail.com>, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48 Date: Fri, 20 Jul 2012 09:25:10 +0200 [thread overview] Message-ID: <20120720072510.GA986@polaris.bitmath.org> (raw) In-Reply-To: <CAM2ehZaLeJsxCOkqLv9jSko9y3Awix1jjobfTo5WQj8rcrYquA@mail.gmail.com> On Fri, Jul 20, 2012 at 11:14:25AM +0800, Chung-Yih Wang (王崇懿) wrote: > From our experiments, the assumption of "the slowest corner is the > stationary finger" is not always true. That is the major reason we want to > report the firmware data instead of semi-mt. Oh, but that was precisely the point; the reason it does not hold true is due to sensor and discretization errors. If we can improve upon this situation, we get a better model of reality. > The problem here will be how > to remove the pulling effect, we measured the pulling effect before and can > not get a good result as there could be IIR in firmware as well. It seems > not an easy job to remove the pulling effect cleanly. Probably a simple filter will work. If the bounding box is moving too fast for the tracked point to stay in the right corner, the solution is to use a smaller time step. In practise, keeping the tracked point as a state in the driver, and updating the bounding box using box -> (1 - m) box + m box_new. If the tracked point is in the right corner, let m = 1. If not, choose a smaller m. > > > * Add a new device property (INVALID_Y_AXIS_CROSSING?) that > > > describes the exact behavior of this device. I would be ok with this > > > if everyone else is, but only because proper clickpad behavior > > > (which I consider very importand) is broken without this knowledge. > > > Sounds good to me(but I would rather to have INVALID_CROSSING instead, > depending on the relative finger positions, it could still have wrong > tracking either in X or Y axis crossing) Propagating information about various sensor defects to userspace sounds horrid to me. The sooner we can forget about these devices, the better. > > > * Leave the device as SEMI_MT, but provide the real locations, and > > > allow userspace to determine the device vendor/model/etc. If > > > userspace knows that a specific device behaves in a specific way, it > > > can do its own quirking handling. Given the specificity of this > > > behavior to only some devices of one brand, this would be my > > > suggested resolution to the issue. > > > > A bit confused here, do you mean we report the real locations instead of > bounding box the current driver have? I am not quite sure if this will > affect other existing works in userspace for this semi-mt driver. I am not entirely opposed to this solution, but I would much rather see an attempt to improve the bounding box in the driver, since such a solution could be useful for other devices as well. Thanks, Henrik -- 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:[~2012-07-20 7:24 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-18 10:22 [PATCH v2] Input: synaptics - use firmware data for Cr-48 Chung-yih Wang 2012-07-18 15:38 ` Chase Douglas [not found] ` <CAM2ehZbftDja6CBGjhL3Jp+30DtYJj+8_4e=_wWcj3pCDGD7AA@mail.gmail.com> 2012-07-19 6:42 ` Dmitry Torokhov 2012-07-19 6:42 ` Dmitry Torokhov 2012-07-19 13:14 ` Henrik Rydberg 2012-07-19 16:16 ` Chase Douglas 2012-07-19 16:16 ` Chase Douglas 2012-07-19 17:05 ` Daniel Kurtz 2012-07-19 17:05 ` Daniel Kurtz 2012-07-19 17:34 ` Chase Douglas 2012-07-19 17:34 ` Chase Douglas 2012-07-19 18:44 ` Henrik Rydberg [not found] ` <CAM2ehZaLeJsxCOkqLv9jSko9y3Awix1jjobfTo5WQj8rcrYquA@mail.gmail.com> 2012-07-20 7:25 ` Henrik Rydberg [this message] 2012-07-20 7:25 ` Henrik Rydberg 2012-07-20 9:03 ` Daniel Kurtz 2012-07-20 9:03 ` Daniel Kurtz 2012-07-20 13:03 ` Henrik Rydberg 2012-07-20 18:31 ` Chase Douglas 2012-07-27 10:40 ` Daniel Kurtz
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=20120720072510.GA986@polaris.bitmath.org \ --to=rydberg@euromail.se \ --cc=chase.douglas@canonical.com \ --cc=cywang@google.com \ --cc=dgdunix@gmail.com \ --cc=djkurtz@chromium.org \ --cc=dmitry.torokhov@gmail.com \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@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: linkBe 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.