Hello
Our touch screen driver unpredictably gets REPLY-blocked on Photon process
after several minutes of work (always in different moments). Debugging
shows that blocking happens on PhEmit call. System Blocking Graph in
Momentics shows that Photon process is RECEIVE-blocked in this moment on
Photon Channel 1. We cannot find any explanation to such behaviour of
Photon.
We are running 6.2.1. The following is an extract from source code, which
delivers touch events.
PhEvent_t event;
PhRect_t rect;
int sent_result;
memset(&event, 0x00, sizeof(event));
memset(&rect, 0x00, sizeof(rect));
ptr_ev->num_coord = 1;
event.type = Ph_EV_RAW;
event.subtype = Ph_EV_RAW_PTR;
event.num_rects = 1;
event.input_group = 1;
event.data_len = offsetof(PhRawPtrEvent_t, coord) + ptr_ev->num_coord *
sizeof(PhRawPtrCoord_t);
event.flags = Ph_EVENT_INCLUSIVE;
rect.ul.x = rect.ul.y = 0;
rect.lr.x = rect.lr.y = 0;
event.emitter.rid = Ph_DEV_RID;
PhEmit(
&event,
&rect,
ptr_ev);
Can anybody help to find solution?
Thanks
Taras Boyko
\
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/
Hello again
As it usually happens as soon as you ask for help problem is almost gone…
As I discovered Photon blocks sender thread (thread, which calls PhEmit)
if it tries to emit event with coordinates out of screen. Ugly “special
effect”. I would rather return error code 
Cheers
Taras Boyko
On Tue, 24 Jan 2006 11:27:21 +0100, Taras Boyko <tarasboyko@gmail.com>
wrote:
Hello
Our touch screen driver unpredictably gets REPLY-blocked on Photon
process after several minutes of work (always in different moments).
Debugging shows that blocking happens on PhEmit call. System Blocking
Graph in Momentics shows that Photon process is RECEIVE-blocked in this
moment on Photon Channel 1. We cannot find any explanation to such
behaviour of Photon.
We are running 6.2.1. The following is an extract from source code,
which delivers touch events.
PhEvent_t event;
PhRect_t rect;
int sent_result;
memset(&event, 0x00, sizeof(event));
memset(&rect, 0x00, sizeof(rect));
ptr_ev->num_coord = 1;
event.type = Ph_EV_RAW;
event.subtype = Ph_EV_RAW_PTR;
event.num_rects = 1;
event.input_group = 1;
event.data_len = offsetof(PhRawPtrEvent_t, coord) + ptr_ev->num_coord *
sizeof(PhRawPtrCoord_t);
event.flags = Ph_EVENT_INCLUSIVE;
rect.ul.x = rect.ul.y = 0;
rect.lr.x = rect.lr.y = 0;
event.emitter.rid = Ph_DEV_RID;
PhEmit(
&event,
&rect,
ptr_ev);
Can anybody help to find solution?
Thanks
Taras Boyko
–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/
Taras Boyko wrote:
Hello again
As it usually happens as soon as you ask for help problem is almost gone…
As I discovered Photon blocks sender thread (thread, which calls
PhEmit) if it tries to emit event with coordinates out of screen. Ugly
“special effect”. I would rather return error code >
Actually, no. Photon doesn’t really pay much attention to where your
screen is. PhEmit() should only block when a copy of the event is
enqueued to a process whose event queue is (or becomes) overflown. It
will stay blocked until the queue goes to 25% its limit or less.
There’s a flag you can use to prevent that, but then you’ll need some
other way to make sure that the overflown queue doesn’t consume all the
memory.
Could you run “phin ch” and post its output here so we can confirm that
that’s what’s happening in your system?
On Tue, 24 Jan 2006 18:37:34 +0100, Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
Taras Boyko wrote:
Hello again
As it usually happens as soon as you ask for help problem is almost
gone…
As I discovered Photon blocks sender thread (thread, which calls
PhEmit) if it tries to emit event with coordinates out of screen. Ugly
“special effect”. I would rather return error code >
Actually, no. Photon doesn’t really pay much attention to where your
screen is. PhEmit() should only block when a copy of the event is
enqueued to a process whose event queue is (or becomes) overflown. It
will stay blocked until the queue goes to 25% its limit or less. There’s
a flag you can use to prevent that, but then you’ll need some other way
to make sure that the overflown queue doesn’t consume all the memory.
Could you run “phin ch” and post its output here so we can confirm that
that’s what’s happening in your system?
Queue cannot be full because almost nothing is sent there (2-3 events,
while I am trying to reproduce problem touching screen). Here is “phin ch”
output:
phin ch
NID PID RID PRNT PS FLAG CH FLAG BLOCK CH PR NUMQ MAXQ BLEN PROGRAM
106515 0 V----- ----- 0 Photon
176149 4 0 -A—D --P-D 0 10 1064 j9
176149 8 0 -A—D --P-D 0 10 1064 j9
176149 9 8 -A—D --P-D 0 10 1064 j9
176149 10 9 -A—D --P-D 0 10 1064 j9
176149 11 10 -A—D --P-D 0 10 1064 j9
176149 12 11 -A—D --P-D 0 10 1064 j9
106515 1 0 V----- ----- 0 Photon
106515 3 1 V----- ----- 0 Photon
159760 2 3 ------ --PHD 4 4 53244 io-graphics
What also confuses me is that when Photon is blocked Momentics shows its
thread’s priority as 24r (usually is 10r). And there is no one other
thread in the system with such a priority.
I added boundary checking to my driver and everything runs well now.