From: Rafi Rubin <rafi@seas.upenn.edu>
To: Rafi Rubin <rafi@seas.upenn.edu>
Cc: linux-input@vger.kernel.org, jkosina@suse.cz, chatty@enac.fr,
evilynux@gmail.com
Subject: Re: [PATCH] HID: Major update to N-Trig touchscreen
Date: Thu, 04 Feb 2010 23:16:11 -0500 [thread overview]
Message-ID: <4B6B9B8B.4080707@seas.upenn.edu> (raw)
In-Reply-To: <1265341963-5315-1-git-send-email-rafi@seas.upenn.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've tested this two machines with different firmwares and it seems to work well. I would certainly like to get some more testing
feedback.
I have a few questions about the right way to do things.
First, this patch breaks the older wacom userspace driver. I don't know how many people use that instead of evdev (I found the
wacom driver considerably nicer). An update to the latest driver does work and I've already posted a patch for the current HEAD.
How bad is that?
Also, the dev node that had worked well when the streams were multiplexed does not work as well with the split devices and one must
now use the eventXX nodes. Is that a reasonable change to thrust on users? In adding names to the input devs I suppose it would be
possible to have udev map the devices for easier configuration, but I haven't investigated yet.
As seemed to be the consensus a while back, the touch sensor emits both classical touchscreen events and mt events. Also both
sensors emit multiple styles of buttons (BTN_0 + BTN_TOUCH). evdev and wacom seem to catch different buttons to accomplish the same
actions, and so far I have not seen a downside to sending both.
What's the proper way to handle mt groups? Should all fingers be represented in events from each group? Should it just send up to
the max id, injecting ghost points for non-present fingers? Or should only live fingers show up?
I also have played with in kernel suppression for a machine which seems to seems to send off events sporadically. Is that something
that should be left entirely to userspace? Certainly I think it should be configurable if added to the kernel.
And one final note, there are a couple corner cases I left in. I need to do a bit more testing, I think those might not be
necessary with the 0xff0002 handling.
Rafi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktrm4gACgkQwuRiAT9o60/m+ACgyL2lVrlEZpOHTWIWkC4ra6l1
RrQAoMtoL1Li5nk0fNYTKyYxMljhJ3Ha
=n2B2
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-02-05 4:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-05 3:52 [PATCH] HID: Major update to N-Trig touchscreen Rafi Rubin
2010-02-05 4:16 ` Rafi Rubin [this message]
2010-02-05 5:53 ` Dmitry Torokhov
2010-02-05 7:27 ` Rafi Rubin
2010-02-05 10:39 ` Jiri Kosina
2010-02-06 0:50 ` Rafi Rubin
2010-02-05 9:40 ` Antonio Ospite
-- strict thread matches above, loose matches on Subject: below --
2010-02-06 0:44 Rafi Rubin
2010-02-06 0:57 ` Rafi Rubin
2010-02-06 0:56 Rafi Rubin
2010-02-06 1:01 Rafi Rubin
2010-02-06 1:03 ` Rafi Rubin
2010-02-08 15:49 ` Jiri Kosina
2010-02-08 16:45 ` Rafi Rubin
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=4B6B9B8B.4080707@seas.upenn.edu \
--to=rafi@seas.upenn.edu \
--cc=chatty@enac.fr \
--cc=evilynux@gmail.com \
--cc=jkosina@suse.cz \
--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 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).