Gary Faulkner
|
touchscreen events in gles1-kd-gears demo app
|
Gary Faulkner
12/17/2009 2:39 PM
post44051
|
touchscreen events in gles1-kd-gears demo app
Hello:
I'm trying to make sure that our touchscreen events are seen in an openkode/CM application. I have put a printf in the
case for KD_EVENT_INPUT_POINTER in the main event loop to indicate when touches occurr.
My problem is that what I'm getting in the app is different from what I get from the debug from my devi* driver. It
reports the correct coordinates/"button state", but two odd things are happening in the gles1-kd-gears application.
First, the touches seem to be "bunched". That is, I seem to get a group of 5 or 6 of them at a time, and they are not
happening immediately when I touch the screen.
Second, the values are, for the most part, wrong; except for the first value.
I'm doing this as testing prior to migrating our UI to CM.
This is on the stock 6.4.1 io-winmgr.
Any ideas on what is going on here, and how I can make these events get delivered "as they happen"?? Is there something
special that I need to do in my devi* driver (aside from obviously starting it with -r)?
Thanks!!
-garyf
|
|
|
Joel Pilon(deleted)
|
RE: touchscreen events in gles1-kd-gears demo app
|
Joel Pilon(deleted)
12/17/2009 2:52 PM
post44052
|
RE: touchscreen events in gles1-kd-gears demo app
You can try including "pointer-qsize = auto" or "pointer-qsize = 1" in the globals section of your winmgr.conf. There's
been some fixes to the framework for input drivers to help make them more responsive, unfortunately it requires that
each devi-* driver be recompiled with the libinput.a which contain these corrections. The idea case would be having the
devi-* driver compiled with a recent libinput.a and "pointer-qsize = auto". Without the fixes however the "auto" feature
won't function properly, and could explain the behavior your seeing.
-Joel
-----Original Message-----
From: Gary Faulkner [mailto:community-noreply@qnx.com]
Sent: Thu 12/17/2009 2:39 PM
To: cwm-graphics
Subject: touchscreen events in gles1-kd-gears demo app
Hello:
I'm trying to make sure that our touchscreen events are seen in an openkode/CM application. I have put a printf in the
case for KD_EVENT_INPUT_POINTER in the main event loop to indicate when touches occurr.
My problem is that what I'm getting in the app is different from what I get from the debug from my devi* driver. It
reports the correct coordinates/"button state", but two odd things are happening in the gles1-kd-gears application.
First, the touches seem to be "bunched". That is, I seem to get a group of 5 or 6 of them at a time, and they are not
happening immediately when I touch the screen.
Second, the values are, for the most part, wrong; except for the first value.
I'm doing this as testing prior to migrating our UI to CM.
This is on the stock 6.4.1 io-winmgr.
Any ideas on what is going on here, and how I can make these events get delivered "as they happen"?? Is there something
special that I need to do in my devi* driver (aside from obviously starting it with -r)?
Thanks!!
-garyf
_______________________________________________
CWM/OpenKODE
http://community.qnx.com/sf/go/post44051
|
|
|
Gary Faulkner
|
Re: RE: touchscreen events in gles1-kd-gears demo app
|
Gary Faulkner
12/17/2009 3:14 PM
post44063
|
Re: RE: touchscreen events in gles1-kd-gears demo app
Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto set in the winmgr.conf (as an aside, pointer
-qsize = 1 does not work for me - I don't get any events at all).
So, where would I get a fixed libinput.a? Especially since there isn't a new version of the devi ddk available for 6.4.
x?
> You can try including "pointer-qsize = auto" or "pointer-qsize = 1" in the
> globals section of your winmgr.conf. There's been some fixes to the framework
> for input drivers to help make them more responsive, unfortunately it requires
> that each devi-* driver be recompiled with the libinput.a which contain these
> corrections. The idea case would be having the devi-* driver compiled with a
> recent libinput.a and "pointer-qsize = auto". Without the fixes however the "
> auto" feature won't function properly, and could explain the behavior your
> seeing.
>
> -Joel
>
> -----Original Message-----
> From: Gary Faulkner [mailto:community-noreply@qnx.com]
> Sent: Thu 12/17/2009 2:39 PM
> To: cwm-graphics
> Subject: touchscreen events in gles1-kd-gears demo app
>
> Hello:
>
> I'm trying to make sure that our touchscreen events are seen in an openkode/CM
> application. I have put a printf in the case for KD_EVENT_INPUT_POINTER in
> the main event loop to indicate when touches occurr.
>
> My problem is that what I'm getting in the app is different from what I get
> from the debug from my devi* driver. It reports the correct coordinates/"
> button state", but two odd things are happening in the gles1-kd-gears
> application.
>
> First, the touches seem to be "bunched". That is, I seem to get a group of 5
> or 6 of them at a time, and they are not happening immediately when I touch
> the screen.
>
> Second, the values are, for the most part, wrong; except for the first value.
>
> I'm doing this as testing prior to migrating our UI to CM.
>
> This is on the stock 6.4.1 io-winmgr.
>
> Any ideas on what is going on here, and how I can make these events get
> delivered "as they happen"?? Is there something special that I need to do in
> my devi* driver (aside from obviously starting it with -r)?
>
> Thanks!!
>
> -garyf
>
>
>
> _______________________________________________
>
> CWM/OpenKODE
> http://community.qnx.com/sf/go/post44051
>
>
|
|
|
Joel Pilon(deleted)
|
RE: RE: touchscreen events in gles1-kd-gears demo app
|
Joel Pilon(deleted)
12/17/2009 3:31 PM
post44066
|
RE: RE: touchscreen events in gles1-kd-gears demo app
You might be able to ask your support rep for a recent build of libinput.a. Oh and I should of mentioned, that I believe
you should be start your devi-* driver with -r and -P. And note, the debug output of the devi-* may not always reflect
what you get from composition manager. The debug output is printing events going into the photon interface. Composition
manager uses the resource manager interface which is similar code patch to that of gfi. So in the end they should be
relatively similar, but something is going wrong after the code paths fork, it wouldn't be reflected in the debug output
. It's generally better to see what you get out of the raw res manager interface from input. E.g. /dev/devi/touch0.
-Joel
-----Original Message-----
From: Gary Faulkner [mailto:community-noreply@qnx.com]
Sent: December 17, 2009 3:15 PM
To: cwm-graphics
Subject: Re: RE: touchscreen events in gles1-kd-gears demo app
Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto set in the winmgr.conf (as an aside, pointer
-qsize = 1 does not work for me - I don't get any events at all).
So, where would I get a fixed libinput.a? Especially since there isn't a new version of the devi ddk available for 6.4.
x?
|
|
|
Gary Faulkner
|
Re: RE: RE: touchscreen events in gles1-kd-gears demo app
|
Gary Faulkner
12/17/2009 3:37 PM
post44067
|
Re: RE: RE: touchscreen events in gles1-kd-gears demo app
Thanks, Joel.
I've fired off that request (to get a recent build of libinput.a). Are there any docs or hints on seeing what is being
delivered on the resource manager interface? Is there any way (for example) to get this level of debug from io-winmgr
itself?
(as an aside, yes, I am starting my devi driver with -P and -r).
My current devi driver works just fine as an input source to gf (i.e. gfi). The output matches exactly what my gf_*
based UI code sees.
> You might be able to ask your support rep for a recent build of libinput.a. Oh
> and I should of mentioned, that I believe you should be start your devi-*
> driver with -r and -P. And note, the debug output of the devi-* may not always
> reflect what you get from composition manager. The debug output is printing
> events going into the photon interface. Composition manager uses the resource
> manager interface which is similar code patch to that of gfi. So in the end
> they should be relatively similar, but something is going wrong after the code
> paths fork, it wouldn't be reflected in the debug output. It's generally
> better to see what you get out of the raw res manager interface from input. E.
> g. /dev/devi/touch0.
>
> -Joel
>
> -----Original Message-----
> From: Gary Faulkner [mailto:community-noreply@qnx.com]
> Sent: December 17, 2009 3:15 PM
> To: cwm-graphics
> Subject: Re: RE: touchscreen events in gles1-kd-gears demo app
>
> Ahh.. yes, I should have mentioned that i already have pointer-qsize = auto
> set in the winmgr.conf (as an aside, pointer-qsize = 1 does not work for me -
> I don't get any events at all).
>
> So, where would I get a fixed libinput.a? Especially since there isn't a new
> version of the devi ddk available for 6.4.x?
|
|
|
Etienne Belanger(deleted)
|
Re: touchscreen events in gles1-kd-gears demo app
|
Etienne Belanger(deleted)
12/17/2009 3:45 PM
post44071
|
Re: touchscreen events in gles1-kd-gears demo app
Some things to keep in mind when working with OpenKODE events, especially pointer events:
1) The events aren't delivered; they are queried. Events just sit in a queue maintained by the composition manager until
an application requests for the next event in the queue. This is done by calling kdWaitEvent. If an application checks
the event queue once every second, all pointer events that happen during the interval will be bunched up until the next
kdWaitEvent call(s).
2) The coordinates are relative to the window, which is different from the screen coordinates that the debug messages
devi-hid prints out.
How fast is the gears application running (in fps) ?
|
|
|
Gary Faulkner
|
Re: touchscreen events in gles1-kd-gears demo app
|
Gary Faulkner
12/17/2009 3:51 PM
post44072
|
Re: touchscreen events in gles1-kd-gears demo app
Yup... got that (the first point). In fact, the kdWaitEvent is only delivering the events in a batched sequence...
about once every 5 seconds or so.
I'm running gles1-kd-gears in full-screen mode, so the screen coordinates should be at least close (and usually the
first one in the batch is -- even if I don't move my finger all that much).
I'm seeing 15+fps from the gears app (depending on which color-depth I use).
> Some things to keep in mind when working with OpenKODE events, especially
> pointer events:
>
> 1) The events aren't delivered; they are queried. Events just sit in a queue
> maintained by the composition manager until an application requests for the
> next event in the queue. This is done by calling kdWaitEvent. If an
> application checks the event queue once every second, all pointer events that
> happen during the interval will be bunched up until the next kdWaitEvent call(
> s).
>
> 2) The coordinates are relative to the window, which is different from the
> screen coordinates that the debug messages devi-hid prints out.
>
> How fast is the gears application running (in fps) ?
|
|
|
Gary Faulkner
|
Re: touchscreen events in gles1-kd-gears demo app
|
Gary Faulkner
12/18/2009 9:31 AM
post44121
|
Re: touchscreen events in gles1-kd-gears demo app
I have more info now.
I downloaded the i.mx25 bsp, which has a copy of libinput source in it.
Using that version of libinput (which *appears* to be relatively new), I find that in devi_read, it appears that the FD
that io-winmgr has open is marked as non-blocking. So, more often than not, devi-read returns EAGAIN.
Additionally, because of that, the devi* interface isn't queuing up the input packets; it gets into process_wait_queue()
, it sees nothing in the wait_queue, therefor, it just throws away the touch.
Does this ring a bell? First off, is io-winmgr really opening the devi interface non-blocking? I don't see devi_notify
ever getting called, so I am assuming that it's not doing a select/poll/etc.
|
|
|
|