nanogui: Thread: VTSWITCH vs. Timers vs. Sleep Mode

Hello,

 

I'd written a while back saying that I was unable to get
GrGetNextEventTimeout() to work correctly.  Greg suggested that I check
whether VTSWITCH was set to 'Y' in my config file and it turned out that
it was.  Not remembering why I'd set it to 'Y', I changed it to 'N' and,
all of a sudden, GrGetNextEventTimeout() began working correctly.

 

HOWEVER, I've come to realize that the reason I had VTSWITCH set to 'Y'
is because if it is not, then I cannot place my hardware into sleep mode
using the power manager, i.e. writing "mem" to /sys/power/state.  I
don't understand how VTSWITCH and the power state are connected but if I
have VTSWITCH set to 'N', then the unit just hangs up and does not enter
the sleep state.

 

I'm hoping someone can help.  Both the hardware sleep and the
GrGetNextEventTimeout() are quite critical to my project.

 

Thanks.

 

Gil Glass

Senior Software Engineer

Telecom Field Services Division

JDSU

Germantown, MD, USA

+1 (240) 404-2551

 

> HOWEVER, I've come to realize that the reason I had VTSWITCH set to 'Y'
is because if it is not, then I cannot place my hardware into sleep mode
using the power manager, i.e. writing "mem" to /sys/power/state.  I
don't understand how VTSWITCH and the power state are connected but if I
have VTSWITCH set to 'N', then the unit just hangs up and does not enter
the sleep state.

 Hmmm.  You should study the vtswitch.c code carefully, I can
think of a couple possibilities: perhaps without vtswitch, the system
never assigns a text console and it can't determine when the system
should sleep?  Also try commenting out a few lines of the vtswitch
code while enabled, (like the signal() calls, then ioctl()s).  This
will give a better understanding of what is required for your
power manager.

Regards,

Greg

Thanks, Greg.

I have come up with a hack that I THINK solves my problem.  I'm
wondering whether you know of any hidden gotchas that I may have
introduced.

The problem with having VTSWTICH enabled was that the 50 millisecond
timer created in srvmain.c to periodically check for VT switches was
superseding my 1000 millisecond timer created by my call to

GrGetNextEventTimeout(&e, 1000)

Since I never do any VT switching during operation of my application, I
went in and heartlessly commented out the

GdAddTimer(50, CheckVtChange, NULL)

calls in srvmain.c -- the one that initiates the VT switch checking and
the one that perpetuates it.  This means, AS I UNDERSTAND IT, that
Nano-X will not check for VT changes on a regular basis and I'm hoping
that his is OK!  

With this change in place, my GrEventGetNextTimeout() appears to work
and the hardware does enter sleep mode when I command it to do so.

I'm keeping my fingers crossed that I have not introduced some anomaly
that's going to come back to bite me when the planets align on the
second Tuesday in February.  ;-)

Cheers,
Gil

-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Thursday, November 30, 2006 6:55 PM
To: Gil Glass; ####@####.####
Subject: Re: [nanogui] VTSWITCH vs. Timers vs. Sleep Mode

> HOWEVER, I've come to realize that the reason I had VTSWITCH set to
'Y'
is because if it is not, then I cannot place my hardware into sleep mode
using the power manager, i.e. writing "mem" to /sys/power/state.  I
don't understand how VTSWITCH and the power state are connected but if I
have VTSWITCH set to 'N', then the unit just hangs up and does not enter
the sleep state.

 Hmmm.  You should study the vtswitch.c code carefully, I can
think of a couple possibilities: perhaps without vtswitch, the system
never assigns a text console and it can't determine when the system
should sleep?  Also try commenting out a few lines of the vtswitch
code while enabled, (like the signal() calls, then ioctl()s).  This
will give a better understanding of what is required for your
power manager.

Regards,

Greg

> GdAddTimer(50, CheckVtChange, NULL)
>  This means, AS I UNDERSTAND IT, that
Nano-X will not check for VT changes on a regular basis and I'm hoping
that his is OK!  

Yes, that should be OK.


> With this change in place, my GrEventGetNextTimeout() appears to work
and the hardware does enter sleep mode when I command it to do so.

Likely the reason you needed VTSWITCH=Y in the first
place has to do with it catching the SIGUSR1 signal.  There's
nothing else in the vtswitch code doing anything funny,
is there?


> I'm keeping my fingers crossed that I have not introduced some anomaly
that's going to come back to bite me when the planets align on the
second Tuesday in February.  ;-)

It would be interesting to learn why the vtswitch code is
required for your sleep mode.  Otherwise, you know how
programs are, one Tuesday the stars may align without
your permission...  I think you're fix will work for the
long term, however.

Regards,

Greg