On Tue, 27 Mar 2012 14:25:12 +1000 David Seikel <onef...@gmail.com> said:

svn update. fixed. see my log. working for me in fb at the moment anyway (keys,
mouse - though no mouse pointer - would have to turn it on manually in
elementary - not there currently).

> I'm developing an embedded app under X, but the real app runs on the
> Linux frame buffer.  Part of the real hardware pretends to be a USB
> keyboard.  Some of the fake key events it sends need to be discarded if
> they are too old by the time the app gets around to process them.  Some
> need to be processed no matter how late they are.  So I'm relying on
> the Evas_Event_Key_Down->timestamp field that evas sends to my
> callback.  The idea is to compare that to the current time, and discard
> it if it's too old, if it's one of the ones that need to be filtered
> for age.
> 
> From what I can tell, frame buffer sets timestamp to ecore_time_get(),
> which is a double, the number of seconds since some undefined point in
> time. Though the timestamp is an unsigned int, so that gets implicitly
> rounded or truncated in whatever manner the compiler decides.
> 
> X stuffs XKeyEvent->time into timestamp, which looks like microseconds
> as an integer.  Orders of magnitude bigger than what ecore_time_get()
> returns.  I dunno if it's using the same time base though.  My tests so
> far seem to show it is the same time base.
> 
> This presents two problems - I need to write two versions of "get
> current time", one for X, and one for frame buffer, so that it will
> have the correct number for the comparison.  Frame buffer version can
> use ecore_time_get(), but I dunno where X get's it's timestamp from.
> 
> I want the code to have as little special casing as possible, so prefer
> the X and frame buffer code paths to be identical, or only as little
> difference as possible.
> 
> The second problem is that the frame buffer timestamp only has a
> resolution of whole seconds, which is not good.  Microseconds is good.
> 
> Now I understand why the X timestamp is being used, it's best if that
> timestamp is as close to the real time the key was actually pressed,
> for exactly the reasons I need, filtering out old key events.  X is
> supplying that, so it's a bit closer to the actual event time than what
> we can guess by the time it gets to us.  I guess the frame buffer does
> not supply a similar timestamp, so we have to generate one when we can.
> What I don't understand is why X is microseconds and frame buffer is
> seconds?
> 
> Can we change frame buffer to multiply ecore_time_get() by 1000 before
> it rounds it by stuffing it into an int?  And any other similar input
> type that uses ecore_time_get().  That will make things more consistent
> for people like me that are writing code that has to work the same
> across different canvas types.  As a bonus, a more useful resolution
> for frame buffer key event timings.
> 
> -- 
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to