Hello Mr. Dmitry ,
Thanks for the replies.
Yes you are right there is not enough backup for
addition of this feature.
So we can skip it as of now.
Thanks
On Tue, Jul 7, 2015 at 11:44 PM, Dmitry Torokhov
wrote:
> Hi Anshul,
>
> On Tue, Jul 07, 2015 at 07:30:23PM +0530, Anshul Garg wrote:
>> Hel
Hi Anshul,
On Tue, Jul 07, 2015 at 07:30:23PM +0530, Anshul Garg wrote:
> Hello Mr. Dmitry ,
>
> On Tue, Jul 7, 2015 at 4:18 AM, Dmitry Torokhov
> wrote:
> > Hi Anshul,
> >
> > On Mon, Jul 06, 2015 at 12:33:44PM -0700, Anshul Garg wrote:
> >> From: Anshul Garg
> >>
> >> As per current implement
Hello Mr. Dmitry ,
On Tue, Jul 7, 2015 at 4:18 AM, Dmitry Torokhov
wrote:
> Hi Anshul,
>
> On Mon, Jul 06, 2015 at 12:33:44PM -0700, Anshul Garg wrote:
>> From: Anshul Garg
>>
>> As per current implementation input driver can only
>> send ktime converted to timeval which user space again
>> have
Hi Anshul,
On Mon, Jul 06, 2015 at 12:33:44PM -0700, Anshul Garg wrote:
> From: Anshul Garg
>
> As per current implementation input driver can only
> send ktime converted to timeval which user space again
> have to convert.
Why? ktime is kernel construct and thus userspace has no business using
From: Anshul Garg
As per current implementation input driver can only
send ktime converted to timeval which user space again
have to convert.
In some cases input drivers need 64bit timestamp value
from driver only so that same value can be used by upper
layer without any manipulation.
Proposed im
