[Gta04-owner] Touch screen patch for Android

[Dr. H. Nikolaus Schaller]

Am 30.07.2013 um 16:43 schrieb Radek Polak:

> On Tuesday, July 30, 2013 04:04:14 PM Dr. H. Nikolaus Schaller wrote:
>> Hi Paul,
>> many thanks!
>> 
>> Am 30.07.2013 um 15:20 schrieb Paul Kocialkowski:
>>> Le mardi 30 juillet 2013 à 15:10 +0200, Dr. H. Nikolaus Schaller a
>>> 
>>> écrit :
>>>> Hi,
>>>> a) the kernel.org people will just say that there is the ioctl()
>>>> and Android user space has to use it.
>>>> b) Android people will probably say that the kernel has to do it (as
>>>> it was apparently done by the Android kernels)
>>> 
>>> We HAVE TO patch the kernel for this, not the userspace. I am not going
>>> to accept any patch that modifies the framework for that purpose into
>>> Replicant.
>> 
>> Well that is what I have expected as the deadlock...
>> 
>> The Kenrel.org people have this in the latest kernel source:
>> 
>> 	event.time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ?
>> 				      mono : real);
>> 
>> And they will say they are not going to accept any patch that modifies this
>> fundamental function (being deployed from any x86 server to some IBM
>> mainframe). And we have to use the ioctl() intended for the same purpose.
>> 
>> So you have to wrestle with Linus :)
>> 
>> But there may be a solution: if the kernel doesn't support the ioctl() it
>> will most likely just be ignored. So adding a patch as suggested by Radek
>> won't hurt. Isn't it?
> 
> The patch is backported from newer android version (4.2?)

Most likely (since I don't guess that you did have early access to 4.3 :)

> but if Paul prefers 
> doing this in kernel i'd do it there - unless this breaks Xorg or qtmoko.

For Xorg it might work because it might be totally unused. The X protocol
has time stamps but since an evdev driver is much newer and X time stamps
did work 30 years ago without any kernel support, I suspect that Xorg simply
has its own timestamp mechanism built in the input drivers.

I.e. sort of "patch in the user space"...

So, technically I don't see a major problem with a kernel patch, but it breaks the
chance to get it upstream...

And if we upgrade to 4.2 at some (near?) future we can remove it again...

BR,
Nikolaus