nanogui: Thread: Difficulty Using GrInjectKeyboardEvent()

Hello,

 

I've been away from this list for quite a while and don't know whether
this issue has already been addressed.

 

I am using Nano-X version 0.91, server linked into application, and I am
trying to use GrInjectKeyboardEvent() to post an event to the main loop
of execution.  I am wondering whether there is a known problem with this
function or whether I'm using it incorrectly.

 

In one thread, I make the following calls:

 

...

status = GrOpen()     // Open another connection to the Nano-X server
(necessary?)

...

 

// Inject a keyboard event in order to wake up main loop in the main
thread.

GrInjectKeyboardEvent(GR_ROOT_WINDOW_ID, MWKEY_SYSREQ, 0, 0, GR_TRUE);

 

In the main thread:

 

// Wake up on ALL events for now.

GrSelectEvents(GR_ROOT_WINDOW_ID, GR_EVENT_MASK_ALL);

 

while (!done)

{

// Block, waiting for events.  INJECTED KEYBOARD EVENTS FROM THE OTHER
THREAD

// DO NOT TRIGGER THIS!

    GrGetNextEvent(&event);

...

}

 

Finally, is there another way to post events to the queue is
GrInjectKeyboardEvent() does not work the way I think it should?

 

Thanks very much!

 

Cheers,    

Gil Glass

Senior Software Engineer

JDSU, Communications Test and Measurement

Germantown, MD, USA

+1 (240) 404-2551

 

> GrInjectKeyboardEvent(GR_ROOT_WINDOW_ID, MWKEY_SYSREQ, 0, 0, GR_TRUE);

Take a close look at the code in nanox/srvevent.c::GsDeliverKeyboardEvent,
you'll see that there are issues with whether the mouse is in the window,
and focus issues that may cause the event to be discarded.

> Finally, is there another way to post events to the queue is
GrInjectKeyboardEvent() does not work the way I think it should?

 
There's no way currently to post arbitrary events to the queue.
Mouse events can be generated with GrInjectPointerEvent.
If you want arbitrary events, you'll probably have to call
something like nanox/srvevent.c::GsDeliverGeneralEvent(),
which isn't meant to be called by applications but is accessible
when LINK_APP_INTO_SERVER.

Regards,

Greg

Greg,

Thank you for the prompt reply.  I'll have a look at the code as you
suggested but, off the top of your head, do you know whether the fact
that our system has no mouse makes a difference?

Cheers,
Gil

-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Wednesday, August 27, 2008 6:58 PM
To: Gil Glass; ####@####.####
Subject: Re: [nanogui] Difficulty Using GrInjectKeyboardEvent()

> GrInjectKeyboardEvent(GR_ROOT_WINDOW_ID, MWKEY_SYSREQ, 0, 0, GR_TRUE);

Take a close look at the code in
nanox/srvevent.c::GsDeliverKeyboardEvent,
you'll see that there are issues with whether the mouse is in the
window,
and focus issues that may cause the event to be discarded.

> Finally, is there another way to post events to the queue is
GrInjectKeyboardEvent() does not work the way I think it should?

 
There's no way currently to post arbitrary events to the queue.
Mouse events can be generated with GrInjectPointerEvent.
If you want arbitrary events, you'll probably have to call
something like nanox/srvevent.c::GsDeliverGeneralEvent(),
which isn't meant to be called by applications but is accessible
when LINK_APP_INTO_SERVER.

Regards,

Greg

> off the top of your head, do you know whether the fact
that our system has no mouse makes a difference?

Shouldn't matter

Using debug messages, I've determined that the event IS being posted.
That is, execution of GsDeliverKeyboardEvent() reaches the point where
the event structure, ep, is populated.  Therefore, it is not discarding
the events.

What appears to be happening is that the keyboard events that I inject
using GrInjectKeyboardEvent() are being queued somewhere.  Once an
actual key is pressed, that keypress is recognized and then,
subsequently, all those queued events are "unleashed" and
GrGetNextEvent() unblocks one time for each event.  It's almost as if
there's something about a real keypress that says 

1.  create the keyboard event,
2.  queue it up, AND
3.  send it on to clients that are selecting on the event.

Using GrInjectKeyboardEvent() only does the first two things.

Cheers,
Gil

-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Thursday, August 28, 2008 12:21 PM
To: Gil Glass; ####@####.####
Subject: Re: [nanogui] Difficulty Using GrInjectKeyboardEvent()

> off the top of your head, do you know whether the fact
that our system has no mouse makes a difference?

Shouldn't matter

> 3.  send it on to clients that are selecting on the event.
> Using GrInjectKeyboardEvent() only does the first two things.

Of course...  the client thread is hanging on a real select() call
in srvmain.c::GsSelect(), and doesn't unblock just because
the other thread posted an event into a memory location.

We'll need some IPC method of having the calling thread
unblock the waiting thread when the event is posted.

The reason I think this works in the non LINK_APP_INTO_SERVER
case is because the server checks for events in application
queues and sends a byte across the pipe for any applications
which are currently blocked in GrGetNextEvent, which 
wakes them up by allowing them to read.

In your case, one simple approach would be to never
hang in GrGetNextEvent very long, that is, set a small
interval timeout, which will cause the thread to at
least loop once in GsSelect every so many milliseconds.

Regards,

Greg

On donderdag 28 augustus 2008, Greg Haerr wrote:
> > 3.  send it on to clients that are selecting on the event.
> > Using GrInjectKeyboardEvent() only does the first two things.
>
> Of course...  the client thread is hanging on a real select() call
> in srvmain.c::GsSelect(), and doesn't unblock just because
> the other thread posted an event into a memory location.
>
> We'll need some IPC method of having the calling thread
> unblock the waiting thread when the event is posted.
>
> The reason I think this works in the non LINK_APP_INTO_SERVER
> case is because the server checks for events in application
> queues and sends a byte across the pipe for any applications
> which are currently blocked in GrGetNextEvent, which
> wakes them up by allowing them to read.
>
> In your case, one simple approach would be to never
> hang in GrGetNextEvent very long, that is, set a small
> interval timeout, which will cause the thread to at
> least loop once in GsSelect every so many milliseconds.
>
> Regards,
>
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Hi,

I use nano-X together with TinyWidgets for a process (variables) display. Here 
the information is updated by the application, not by user input (most of the 
time). TinyWidgets normally would 'hang' in 

void
tnMainLoop (void)
{
GrMainLoop(EventResolveRoutine);
}

so my process variables are not handled.

I modfied tnMainLoop to

void
tnMainLoop (int flag)
{
 fd_set  rfds;
  int     setsize = 0;
   struct timeval wtime;

 wtime.tv_sec = 0;
 if(flag)
	 wtime.tv_usec = 1000;
 else
 	wtime.tv_usec = 0;

   FD_ZERO(&rfds);
     GrPrepareSelect(&setsize, &rfds);
     if(select(setsize+1, &rfds, NULL, NULL, &wtime) > 0)
         GrServiceSelect(&rfds, EventResolveRoutine);
}

This makes the application active contineously while checking for events to 
handle when it has time to.

regards

Kees

: This makes the application active contineously while checking for events 
to
: handle when it has time to.

The problem with this approach is that the application polls and uses
cpu time continuously.  This may work if only one application is running
but quickly becomes a bad design if multiple applications run using
the same approach.

Regards,

Greg 

Thanks.  I tried the implementation and the CPU hit was not too severe.  Still, as it turns out, I used a different approach entirely.  I created another thread and had it block read on one end of a pipe.  As such, the processing does not happen in my "main loop" but that's OK for what I'm doing.
 
Cheers,
Gil

________________________________

From: Greg Haerr ####@####.####
Sent: Fri 9/5/2008 10:01 PM
To: Kees Schoenmakers; ####@####.####
Cc: Gil Glass
Subject: Re: [nanogui] Difficulty Using GrInjectKeyboardEvent()



: This makes the application active contineously while checking for events
to
: handle when it has time to.

The problem with this approach is that the application polls and uses
cpu time continuously.  This may work if only one application is running
but quickly becomes a bad design if multiple applications run using
the same approach.

Regards,

Greg

On zaterdag 6 september 2008, Greg Haerr wrote:
> : This makes the application active contineously while checking for events
>
> to
>
> : handle when it has time to.
>
> The problem with this approach is that the application polls and uses
> cpu time continuously.  This may work if only one application is running
> but quickly becomes a bad design if multiple applications run using
> the same approach.
>
> Regards,
>
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Hi,
 It is just _one_ application that does a lot of things and as part of that it 
update data to be displayed and resfresh the  display.

Kees