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. What will cause you to later change the kernel
driver here to not export the data in this way? Once you create this
kernel/user api, you had better not break it in the future.
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?
thanks,
greg k-h
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
