On 08/24/2010 08:01 AM, Greg KH wrote:
On Tue, Aug 24, 2010 at 07:51:32AM -0700, James wrote:
On 08/23/2010 08:55 PM, Greg KH wrote:
On Mon, Aug 23, 2010 at 08:19:44PM -0700, James wrote:

On 08/19/2010 05:10 PM, Greg KH wrote:

On Thu, Aug 19, 2010 at 04:28:39PM -0700, James wrote:

--- a/drivers/input/touchscreen/cy8ctmg110_ts.c
+++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
@@ -81,8 +81,13 @@ struct ts_event {
     * The touch driver structure.
     */
    struct cy8ctmg110 {
+#ifdef CONFIG_TOUCHSCREEN_CY8CTMG110_MULTIPLE_INPUT
+    struct input_dev *input[MAX_FINGERS];
+    char phys[MAX_FINGERS][32];
+#else
        struct input_dev *input;
        char phys[32];
+#endif


No #ifdefs in .c files please.


I'll work on an improvement.  Long term, I suspect this patch will
disappear in favor of a full multi-touch-protocol implementation.  However,
if you want to deploy an entire multi-touch stack *now*, user space doesn't
use the multi-touch protocol, so we're stuck with having to write the
driver to the legacy mechanism.

Doesn't that sound like a userspace bug?  Why are you trying to fix it
in the kernel?

Not a user space bug; a reality of software evolution.  To work with the
user space of today, the driver needs to expose what user space is written
to leverage.  This isn't fixing anything broken, its providing support to
user space, in a way that long term will likely change.
I still don't buy it.
Fortunately I gave the patch for free and without charge. Purchase isn't necessary. Just use and enjoy. :)
What will cause you to later change the kernel
driver here to not export the data in this way?
Deprecation of need.
Once you create this
kernel/user api, you had better not break it in the future.
Some in-tree drivers currently expose one contact point per /dev/input/event interface. That is not the way in which multi-touch is going to be exposed (per Documentation/input/mulit-touch-protocol.txt)

The patch being discussed is provided to work with the same set of user space applications that those drivers work with (in this case, any multi-touch application written using Qt) I didn't create the kernel/user api; I'm just providing a patch that lets the cy8ctmg110 driver use a mechanism others already are.

In the future, when XInput2.1 is fully supported through the toolkits, the need for this patch will cease.
So that would mean, just export the "correct" multitouch information to
userspace so that it can then be changed to properly handle the data and
then there is no "I'll do it sometime in the future" issue, right?
The full vertical stack supporting the new multi-touch-protocol is not available in user space. Eventually it will be, but it isn't now, so won't be in MeeGo 1.1. This patch, when combined with what *is* available in user space today, is available now, does work, and can be in MeeGo 1.1.

Thanks,
James
thanks,

greg k-h

_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Reply via email to