> CLOCK_MONOTONIC seems like the obvious choice and CLOCK_REALTIME seems like a
> really bad one. Replicating a mistake in qtmir seems will make it difficult to
> correct in both codebases:
>
> https://books.google.co.uk/books?id=sS7aPtrUuw4C&lpg=PA172&ots=-hd3SP-jyT&dq=9
> 7%20things%20two%20wrongs%20make%20a%20right&pg=PA172#v=onepage&q=97%20things%
> 20two%20wrongs%20make%20a%20right&f=false
Yes thats why I started the attempt to use steady_clock for everything. I am still investigating why qtmir at some point not longer copies the timestamps provided by mir...
We were using CLOCK_REALTIME since beginning of the android-input stack in mir. This MP is not addressing that yet. It fixes some naming problems and introduces the concept of a mirserver controlled clock to the input sources..
> CLOCK_MONOTONIC seems like the obvious choice and CLOCK_REALTIME seems like a /books. google. co.uk/books? id=sS7aPtrUuw4C &lpg=PA172& ots=-hd3SP- jyT&dq= 9 20two%20wrongs% 20make% 20a%20right& pg=PA172# v=onepage& q=97%20things% 20make% 20a%20right& f=false
> really bad one. Replicating a mistake in qtmir seems will make it difficult to
> correct in both codebases:
>
> https:/
> 7%20things%
> 20two%20wrongs%
Yes thats why I started the attempt to use steady_clock for everything. I am still investigating why qtmir at some point not longer copies the timestamps provided by mir...
We were using CLOCK_REALTIME since beginning of the android-input stack in mir. This MP is not addressing that yet. It fixes some naming problems and introduces the concept of a mirserver controlled clock to the input sources..