Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Monitor never blanks in Solaris 10

66 views
Skip to first unread message

Gary Mills

unread,
Mar 9, 2005, 12:08:17 PM3/9/05
to
One thing I noticed with Solaris 10 is that when the monitor is
displaying the dtgreet window, the screen never blanks. Is this
a bug, or something that I've missed? Once somebody is logged in,
screen blanking works normally.

We first noticed this on a Sun-Blade-100 workstation. Later, when
I installed Solaris 10 and Sun Ray Server 3.0 on an Ultra 2, the
same thing happens on the Sun Ray client. Screen blanking used to
work on both under Solaris 9, with the previous Sun Ray Server
version.


--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

Roland Mainz

unread,
Mar 9, 2005, 2:48:55 PM3/9/05
to
Gary Mills wrote:
>
> One thing I noticed with Solaris 10 is that when the monitor is
> displaying the dtgreet window, the screen never blanks. Is this
> a bug, or something that I've missed? Once somebody is logged in,
> screen blanking works normally.
>
> We first noticed this on a Sun-Blade-100 workstation. Later, when
> I installed Solaris 10 and Sun Ray Server 3.0 on an Ultra 2, the
> same thing happens on the Sun Ray client. Screen blanking used to
> work on both under Solaris 9, with the previous Sun Ray Server
> version.

Is it possible that dtlogin (CDE's version of xdm) now turns-off DPMS by
default ?

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)

Casper H.S. Dik

unread,
Mar 9, 2005, 3:10:04 PM3/9/05
to
Roland Mainz <roland...@nrubsig.org> writes:

>Is it possible that dtlogin (CDE's version of xdm) now turns-off DPMS by
>default ?

Seems to work fine for me.

Casper

Alan Coopersmith

unread,
Mar 9, 2005, 4:44:17 PM3/9/05
to
mi...@cc.umanitoba.ca (Gary Mills) writes in comp.unix.solaris:

|One thing I noticed with Solaris 10 is that when the monitor is
|displaying the dtgreet window, the screen never blanks. Is this
|a bug, or something that I've missed? Once somebody is logged in,
|screen blanking works normally.
|
|We first noticed this on a Sun-Blade-100 workstation. Later, when
|I installed Solaris 10 and Sun Ray Server 3.0 on an Ultra 2, the
|same thing happens on the Sun Ray client. Screen blanking used to
|work on both under Solaris 9, with the previous Sun Ray Server
|version.

We've had a few other people report that, but never seen it here - it
works fine on our machines.

--
________________________________________________________________________
Alan Coopersmith * al...@alum.calberkeley.org * Alan.Coo...@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.

Gary Mills

unread,
Mar 9, 2005, 5:29:00 PM3/9/05
to
In <d0nqnh$2hta$1...@agate.berkeley.edu> Alan Coopersmith <al...@alum.calberkeley.org> writes:

>mi...@cc.umanitoba.ca (Gary Mills) writes in comp.unix.solaris:
>|One thing I noticed with Solaris 10 is that when the monitor is
>|displaying the dtgreet window, the screen never blanks. Is this
>|a bug, or something that I've missed? Once somebody is logged in,
>|screen blanking works normally.

>We've had a few other people report that, but never seen it here - it


>works fine on our machines.

I'm assuming that the problem resides in /etc/power.conf.
However, I've been reading the man page and am not enlightened.
What I want is for the monitors to be blanked after some idle
time, but not to have the server shut down. Is this what the
`default' keyword implies?

Rich Teer

unread,
Mar 9, 2005, 6:20:22 PM3/9/05
to
On Wed, 9 Mar 2005, Alan Coopersmith wrote:

> We've had a few other people report that, but never seen it here - it
> works fine on our machines.

ISTR the same problem on my Creator 3D equipped Ultra 60, but I'm not
at home right now to test it. If I remember, I try it this weekend.

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Darren Dunham

unread,
Mar 9, 2005, 6:56:55 PM3/9/05
to
Gary Mills <mi...@cc.umanitoba.ca> wrote:

> I'm assuming that the problem resides in /etc/power.conf.

Probably not. When X is running, it takes over..

Device Power Management entries are only effective if there
is no user process controlling the device directly. For
example, X Windows systems directly control frame buffers.
The entries in the power.conf file are effective only when X
Windows is not running.

I would assume then that the X server running during the dtgreet doesn't
have a screenblank interval set. If you could send a 'xset s 300' or so
to it, it should blank and suspend. I'm not certain where to do that
though....

> However, I've been reading the man page and am not enlightened.
> What I want is for the monitors to be blanked after some idle
> time, but not to have the server shut down. Is this what the
> `default' keyword implies?

No, that only affect the default behavior for suspension of the entire
machine, not just the frame buffer.

--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

PM

unread,
Mar 10, 2005, 3:39:46 AM3/10/05
to
Alan Coopersmith wrote:
> We've had a few other people report that, but never seen it here - it
> works fine on our machines.

Same behavior (never blanking) here on some Ultra 2 and Ultra 60

PM

unread,
Mar 10, 2005, 3:47:20 AM3/10/05
to
Martin Paul wrote:
> % ptree
> ...
> 2196 /usr/dt/bin/dtlogin -daemon
> 10559 /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -audiobell -auth /var/d
> 10584 /usr/dt/bin/dtlogin -daemon
> 10597 dtgreet -display :0
> 10598 <defunct>
> 10585 /usr/openwin/bin/fbconsole -d :0
>
> Maybe something breaks before reading default settings for dtlogin; does
> anybody with the power management issue also see the defunct process ?
> Any information I could provide to help debugging the problem ?

only confirming (Ultra-2):

-------------
399 /usr/dt/bin/dtlogin -daemon
604 /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -auth
/var/dt/A:0-A_a4Xa
628 /usr/dt/bin/dtlogin -daemon
641 dtgreet -display :0
642 <defunct>
-------------

Martin Paul

unread,
Mar 10, 2005, 3:36:38 AM3/10/05
to
Rich Teer <rich...@rite-group.com> wrote:
> On Wed, 9 Mar 2005, Alan Coopersmith wrote:
>> We've had a few other people report that, but never seen it here - it
>> works fine on our machines.
>
> ISTR the same problem on my Creator 3D equipped Ultra 60, but I'm not
> at home right now to test it. If I remember, I try it this weekend.

I definitely see the same effect on my Ultra 10/Creator 3D. Could it
be connected to the defunct process under dtgreet:

% ptree
...
2196 /usr/dt/bin/dtlogin -daemon
10559 /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -audiobell -auth /var/d
10584 /usr/dt/bin/dtlogin -daemon
10597 dtgreet -display :0
10598 <defunct>
10585 /usr/openwin/bin/fbconsole -d :0

Maybe something breaks before reading default settings for dtlogin; does
anybody with the power management issue also see the defunct process ?
Any information I could provide to help debugging the problem ?

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

Gary Mills

unread,
Mar 10, 2005, 9:19:06 AM3/10/05
to
In <42300716$0$11610$3b21...@usenet.univie.ac.at> Martin Paul <m...@par.univie.ac.at> writes:

>I definitely see the same effect on my Ultra 10/Creator 3D. Could it
>be connected to the defunct process under dtgreet:

> % ptree
> ...
> 2196 /usr/dt/bin/dtlogin -daemon
> 10559 /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -audiobell -auth /var/d
> 10584 /usr/dt/bin/dtlogin -daemon
> 10597 dtgreet -display :0
> 10598 <defunct>
> 10585 /usr/openwin/bin/fbconsole -d :0

>Maybe something breaks before reading default settings for dtlogin; does
>anybody with the power management issue also see the defunct process ?
>Any information I could provide to help debugging the problem ?

I'm seeing the same defunct process:

1590 /usr/dt/bin/dtlogin -daemon
24375 /usr/openwin/bin/Xsun :2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -
24378 /usr/dt/bin/dtlogin -daemon
24431 dtgreet -display :2
24432 <defunct>

This is on an Ultra 2 with Sun Ray Server 3.0.

Rob Shepherd

unread,
Mar 10, 2005, 1:32:31 PM3/10/05
to


Me too... U10 Solaris 10 FCS M64

>ptree 3393
3393 /usr/dt/bin/dtlogin -daemon
3394 /usr/openwin/bin/Xsun :0 -defdepth 24 dpms v -s 1 -nobanner -auth
/var/dt/A:0-M
3478 /usr/dt/bin/dtlogin -daemon
3491 dtgreet -display :0
3492 <defunct>
3479 /usr/openwin/bin/fbconsole -d :0

I did have a go at fixing this this and tried various combo's of stuff in
/etc/dt/config/xservers

My current file supplies this line:

:0 Local local_uid@console root /usr/X11/bin/Xserver :0 dpms v -s 1 -nobanner

This blanks the screen using screensaver after one min, but strangely enough
when power saving kicks in ( I assume * ) the screen comes alive again.

I got bored of trying to fix it, and turned the screen off to avoid burn.

is this a bug then ?

Rob

* I did muck around with power settings originally thinking it was this the
result of which is /etc/power.conf looking like this,

device-dependency-property removable-media /dev/fb

# Auto-Shutdown Idle(min) Start/Finish(hh:mm) Behavior
autoshutdown 30 9:00 9:00 noshutdown

autopm enable
statefile //.CPR

This does suspend disks however not the screen....


--
Rap it up for the common good
Let us enlist the neighbourhood
It's OK, I've overstood
This is a wordy rappinghood. OK, bye.

Tomtomclub, 1980.

Fredrik Lundholm

unread,
Mar 10, 2005, 10:02:59 AM3/10/05
to
In article <d0nqnh$2hta$1...@agate.berkeley.edu>,

Alan Coopersmith <al...@alum.calberkeley.org> wrote:
>mi...@cc.umanitoba.ca (Gary Mills) writes in comp.unix.solaris:
>|One thing I noticed with Solaris 10 is that when the monitor is
>|displaying the dtgreet window, the screen never blanks. Is this
>|a bug, or something that I've missed? Once somebody is logged in,
>|screen blanking works normally.

>|We first noticed this on a Sun-Blade-100 workstation. Later, when

>We've had a few other people report that, but never seen it here - it


>works fine on our machines.

On my machine, Solaris 10 only blanks my primary head (of two) unless I login
and do a xset +dpms. (SB1000, 2xXVR-500)

/wfr
Fredrik

--
Fredrik Lundholm
dol @ ce.chalmers.se

Alan Coopersmith

unread,
Mar 10, 2005, 4:52:54 PM3/10/05
to
Martin Paul <m...@par.univie.ac.at> writes in comp.unix.solaris:

|Rich Teer <rich...@rite-group.com> wrote:
|> On Wed, 9 Mar 2005, Alan Coopersmith wrote:
|>> We've had a few other people report that, but never seen it here - it
|>> works fine on our machines.
|>
|> ISTR the same problem on my Creator 3D equipped Ultra 60, but I'm not
|> at home right now to test it. If I remember, I try it this weekend.
|
|I definitely see the same effect on my Ultra 10/Creator 3D. Could it
|be connected to the defunct process under dtgreet:
|
| % ptree
| ...
| 2196 /usr/dt/bin/dtlogin -daemon
| 10559 /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -audiobell
|-auth /var/d
| 10584 /usr/dt/bin/dtlogin -daemon
| 10597 dtgreet -display :0
| 10598 <defunct>
| 10585 /usr/openwin/bin/fbconsole -d :0

I don't think it's related - the defunct process is from a bug in the Motif
code that calls gunzip to load the new background pixmap for the login
screen. If it bothers you, you can gunzip the files and modify the
configuration to use the uncompressed forms, or switch back to the old
look-and-feel.

Message has been deleted
Message has been deleted

Martin Paul

unread,
Mar 11, 2005, 9:48:49 AM3/11/05
to
Alan Coopersmith <al...@alum.calberkeley.org> wrote:
> I don't think it's related - the defunct process is from a bug in the Motif
> code that calls gunzip to load the new background pixmap for the login
> screen. If it bothers you, you can gunzip the files and modify the
> configuration to use the uncompressed forms, or switch back to the old
> look-and-feel.

For testing I did that (gunzip /usr/dt/config/images/*.gz, remove .gz
extensions in /usr/dt/config/C/styleModern), and indeed the defunct
process disappeared. Thanks for the pointer/confirmation.

But as you say, it's not related to the original problem - the frame
buffer power management still doesn't kick in. A real show-stopper,
as I won't roll out Solaris 10 on my desktops before this is fixed,
because of ill effects on power usage and the LCD backlights.

BTW - I always wondered how to communicate with the Xsun on the login
screen (ie. when no user is logged in). I'm logging in as root remotely
and run "xset -display localhost:0 q", which just hangs forever. Is
there a working way ?

Darren Dunham

unread,
Mar 11, 2005, 11:29:48 AM3/11/05
to
Martin Paul <m...@par.univie.ac.at> wrote:
> BTW - I always wondered how to communicate with the Xsun on the login
> screen (ie. when no user is logged in). I'm logging in as root remotely
> and run "xset -display localhost:0 q", which just hangs forever. Is
> there a working way ?

I haven't looked at this in years, but I recall doing some research when
we were trying to roll out a kiosk type application.

My memory is that dtlogin launches the X server, gets the cookie
credentials and stores them somewhere so it can pass them off to the
account when someone logs in. If you have those credentials, then it's
pretty easy to talk to the DISPLAY.

However you said that yours just hangs forever. That implies that the
server's not doing an immediate permission rejection which is what I
would expect.... Hmm.. Perhaps things have changed a bit.

Gary Mills

unread,
Mar 11, 2005, 12:06:40 PM3/11/05
to
In <0IjYd.8071$C47....@newssvr14.news.prodigy.com> Darren Dunham <ddu...@redwood.taos.com> writes:

>Martin Paul <m...@par.univie.ac.at> wrote:
>> BTW - I always wondered how to communicate with the Xsun on the login
>> screen (ie. when no user is logged in). I'm logging in as root remotely
>> and run "xset -display localhost:0 q", which just hangs forever. Is
>> there a working way ?

>My memory is that dtlogin launches the X server, gets the cookie


>credentials and stores them somewhere so it can pass them off to the
>account when someone logs in. If you have those credentials, then it's
>pretty easy to talk to the DISPLAY.

Yes, that's correct. However, dtlogin itself should be able to do it.
I notice this in the Xserver man page in Solaris 10:

dpms enables DPMS (display power management services),
where supported. The default state is platform and
configuration specific.

-dpms disables DPMS (display power management services).
The default state is platform and configuration
specific.

It's not listed in the Xsun man page. I also notice that the running
Xsun looks like this:

root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun :2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms

I guess that explains why it's not working. So, the question now is how
to change that setting. In the case of SRSS 3.0, the X server is started
from this line in Xservers:

:2 SunRay local@none /etc/opt/SUNWut/basedir/lib/utxsun :2 -nobanner

`utxsun' is a shell script. It gets its option from another command
called `utxconfig'. For a local frame buffer, things should be
simpler.

Alan Coopersmith

unread,
Mar 11, 2005, 12:26:49 PM3/11/05
to
Martin Paul <m...@par.univie.ac.at> writes in comp.unix.solaris:
|BTW - I always wondered how to communicate with the Xsun on the login
|screen (ie. when no user is logged in). I'm logging in as root remotely
|and run "xset -display localhost:0 q", which just hangs forever. Is
|there a working way ?

dtlogin "grabs" the X server so it ignores all other clients, won't
even finish the connection handshake for them. You can disable this
via the Dtlogin*grabServer setting in /usr/dt/config/Xconfig.

Alan Coopersmith

unread,
Mar 11, 2005, 12:28:24 PM3/11/05
to
mi...@cc.umanitoba.ca (Gary Mills) writes in comp.unix.solaris:
|It's not listed in the Xsun man page. I also notice that the running
|Xsun looks like this:
|
| root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun
|:2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms
|
|I guess that explains why it's not working. So, the question now is how
|to change that setting. In the case of SRSS 3.0, the X server is started
|from this line in Xservers:

In the case of Sun Ray, the DPMS in the X server is never used, as the
Sun Ray terminal handles its own power management.

Darren Dunham

unread,
Mar 11, 2005, 12:34:42 PM3/11/05
to
Gary Mills <mi...@cc.umanitoba.ca> wrote:
> In <0IjYd.8071$C47....@newssvr14.news.prodigy.com> Darren Dunham <ddu...@redwood.taos.com> writes:

>>My memory is that dtlogin launches the X server, gets the cookie
>>credentials and stores them somewhere so it can pass them off to the
>>account when someone logs in. If you have those credentials, then it's
>>pretty easy to talk to the DISPLAY.

> It's not listed in the Xsun man page. I also notice that the running
> Xsun looks like this:

> root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun :2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms

duh.. There's the location of the MIT cookie authorization.

> I guess that explains why it's not working. So, the question now is how
> to change that setting. In the case of SRSS 3.0, the X server is started
> from this line in Xservers:

It may not explain it totally.

On a stock Sol10, the Xsun does not have -dpms, but the screensaver is
still disabled until login, so there may be multiple things involved.

Further, even with the authorization, I'm unable to communicate with the
Xserver.

Gary Mills

unread,
Mar 11, 2005, 12:37:29 PM3/11/05
to
In <d0skfo$q25$3...@agate.berkeley.edu> Alan Coopersmith <al...@alum.calberkeley.org> writes:

>mi...@cc.umanitoba.ca (Gary Mills) writes in comp.unix.solaris:
>|It's not listed in the Xsun man page. I also notice that the running
>|Xsun looks like this:
>|
>| root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun
>|:2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms

>In the case of Sun Ray, the DPMS in the X server is never used, as the


>Sun Ray terminal handles its own power management.

Okay, but it's not handling it for the display on my Sun Ray.
What could be wrong? It used to work under Solaris 9. I did
do the firmware upgrade, but that had no effect. Is there something
I can check or change on the Sun Ray?

Darren Dunham

unread,
Mar 11, 2005, 12:43:37 PM3/11/05
to
Alan Coopersmith <al...@alum.calberkeley.org> wrote:
> Martin Paul <m...@par.univie.ac.at> writes in comp.unix.solaris:
> |BTW - I always wondered how to communicate with the Xsun on the login
> |screen (ie. when no user is logged in). I'm logging in as root remotely
> |and run "xset -display localhost:0 q", which just hangs forever. Is
> |there a working way ?

> dtlogin "grabs" the X server so it ignores all other clients, won't
> even finish the connection handshake for them. You can disable this
> via the Dtlogin*grabServer setting in /usr/dt/config/Xconfig.

Bingo. That does it.

Okay, so with that modified, I can 'xset s 2' the display, and the
screen blanks.

So that's one way to do it.

Are there any "startup scripts" run by the dtlogin/dtgreet environment
where we can run the xset without going through this method?

Alan Coopersmith

unread,
Mar 11, 2005, 1:00:59 PM3/11/05
to
Darren Dunham <ddu...@redwood.taos.com> writes in comp.unix.solaris:

|Are there any "startup scripts" run by the dtlogin/dtgreet environment
|where we can run the xset without going through this method?

/usr/dt/config/Xsetup - see the dtlogin man page for details.

Gary Mills

unread,
Mar 11, 2005, 1:41:26 PM3/11/05
to
In <SEkYd.16842$OU1....@newssvr21.news.prodigy.com> Darren Dunham <ddu...@redwood.taos.com> writes:

>Gary Mills <mi...@cc.umanitoba.ca> wrote:

>> It's not listed in the Xsun man page. I also notice that the running
>> Xsun looks like this:

>> root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun :2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms

>> I guess that explains why it's not working. So, the question now is how


>> to change that setting. In the case of SRSS 3.0, the X server is started
>> from this line in Xservers:

>It may not explain it totally.

>On a stock Sol10, the Xsun does not have -dpms, but the screensaver is
>still disabled until login, so there may be multiple things involved.

Yes, I just noticed that:

# pargs 839
839: /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -auth /var/dt/A:0-bHaWsb
argv[0]: /usr/openwin/bin/Xsun
argv[1]: :0
argv[2]: -defdepth
argv[3]: 24
argv[4]: -nobanner
argv[5]: -auth
argv[6]: /var/dt/A:0-bHaWsb

So, we appear to have two distinct problems with the same symptom.

Darren Dunham

unread,
Mar 11, 2005, 2:12:04 PM3/11/05
to
Alan Coopersmith <al...@alum.calberkeley.org> wrote:
> Darren Dunham <ddu...@redwood.taos.com> writes in comp.unix.solaris:
> |Are there any "startup scripts" run by the dtlogin/dtgreet environment
> |where we can run the xset without going through this method?

> /usr/dt/config/Xsetup - see the dtlogin man page for details.

Right. So that's pretty trivial...

--- /usr/dt/config/Xsetup Fri Dec 17 11:19:45 2004
+++ /etc/dt/config/Xsetup Fri Mar 11 11:09:14 2005
@@ -81,3 +81,9 @@

+ #
+ # Reset Xserver screen blank to 5 minutes
#
+ $XDIR/xset s 300
+
+
+ #
# Switch Sun's Alt and Meta mod mappings to work with Motif


Works for me...

Oscar del Rio

unread,
Mar 11, 2005, 6:49:22 PM3/11/05
to
Darren Dunham wrote:

> +++ /etc/dt/config/Xsetup Fri Mar 11 11:09:14 2005
>

> + $XDIR/xset s 300
>
> Works for me...

That did it for our Ultra 30s as well. Thanks!
The monitors are now sleeping nicely :)

Roland Mainz

unread,
Mar 12, 2005, 1:11:23 PM3/12/05
to
Alan Coopersmith wrote:
> |It's not listed in the Xsun man page. I also notice that the running
> |Xsun looks like this:
> |
> | root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun
> |:2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms
> |
> |I guess that explains why it's not working. So, the question now is how
> |to change that setting. In the case of SRSS 3.0, the X server is started
> |from this line in Xservers:
>
> In the case of Sun Ray, the DPMS in the X server is never used, as the
> Sun Ray terminal handles its own power management.

Uhm... does that mean that using "xset" to set/get the DPMS state is a
NO-OP for SunRays ?

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)

Roland Mainz

unread,
Mar 12, 2005, 1:10:51 PM3/12/05
to
Alan Coopersmith wrote:
> |Rich Teer <rich...@rite-group.com> wrote:
> |> On Wed, 9 Mar 2005, Alan Coopersmith wrote:
> |>> We've had a few other people report that, but never seen it here - it
> |>> works fine on our machines.
> |>
> |> ISTR the same problem on my Creator 3D equipped Ultra 60, but I'm not
> |> at home right now to test it. If I remember, I try it this weekend.
> |
> |I definitely see the same effect on my Ultra 10/Creator 3D. Could it
> |be connected to the defunct process under dtgreet:
> |
> | % ptree
> | ...
> | 2196 /usr/dt/bin/dtlogin -daemon
> | 10559 /usr/openwin/bin/Xsun :0 -defdepth 24 -nobanner -audiobell
> |-auth /var/d
> | 10584 /usr/dt/bin/dtlogin -daemon
> | 10597 dtgreet -display :0
> | 10598 <defunct>
> | 10585 /usr/openwin/bin/fbconsole -d :0
>
> I don't think it's related - the defunct process is from a bug in the Motif
> code that calls gunzip to load the new background pixmap for the login
> screen. If it bothers you, you can gunzip the files and modify the
> configuration to use the uncompressed forms, or switch back to the old
> look-and-feel.

Ahhgrlll. OK... is there a bug filed in SunSolve ? IMHO it would be nice
if OpenSolaris people would be able to grab the Motif/CDE sources and
FIX[1] these issues (it's already the 2nd time I hear about this mess in
Solaris's Motif version (which also suffers from other issues - unfixed
since Solaris 2.7/MU4... xx@@!!!... ;-( )) ...

[1]=via using zlib&co. ...

Alan Coopersmith

unread,
Mar 12, 2005, 1:36:42 PM3/12/05
to
Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:

|Alan Coopersmith wrote:
|> In the case of Sun Ray, the DPMS in the X server is never used, as the
|> Sun Ray terminal handles its own power management.
|
|Uhm... does that mean that using "xset" to set/get the DPMS state is a
|NO-OP for SunRays ?

At the moment, I believe so.

Alan Coopersmith

unread,
Mar 12, 2005, 1:52:40 PM3/12/05
to
Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:
|Alan Coopersmith wrote:
|> I don't think it's related - the defunct process is from a bug in the Motif
|> code that calls gunzip to load the new background pixmap for the login
|> screen. If it bothers you, you can gunzip the files and modify the
|> configuration to use the uncompressed forms, or switch back to the old
|> look-and-feel.
|
|Ahhgrlll. OK... is there a bug filed in SunSolve ? IMHO it would be nice
|if OpenSolaris people would be able to grab the Motif/CDE sources and
|FIX[1] these issues (it's already the 2nd time I hear about this mess in
|Solaris's Motif version (which also suffers from other issues - unfixed
|since Solaris 2.7/MU4... xx@@!!!... ;-( )) ...

The fix for this is probably going to be part of ripping out Motif's
duplicate copy of the libXpm code and just making it use the libXpm
already in Solaris, and then making sure I've got the fix in libXpm.
That's being looked at now for the "Nevada" tree, which is the post-S10
development tree, where Solaris Express releases are coming from now.

Thomas Dehn

unread,
Mar 12, 2005, 2:12:36 PM3/12/05
to

"Roland Mainz" <roland...@nrubsig.org> wrote:
> Alan Coopersmith wrote:
> > |It's not listed in the Xsun man page. I also notice that the running
> > |Xsun looks like this:
> > |
> > | root 24286 1590 0 15:57:43 ? 2:49 /usr/openwin/bin/Xsun
> > |:2 -nobanner -auth /var/dt/A:2-JFaWgd -nobanner -dpms
> > |
> > |I guess that explains why it's not working. So, the question now is how
> > |to change that setting. In the case of SRSS 3.0, the X server is started
> > |from this line in Xservers:
> >
> > In the case of Sun Ray, the DPMS in the X server is never used, as the
> > Sun Ray terminal handles its own power management.
>
> Uhm... does that mean that using "xset" to set/get the DPMS state is a
> NO-OP for SunRays ?

Some xset commands are supposed to work on Sun Ray.


Thomas

Thomas Dehn

unread,
Mar 12, 2005, 2:22:25 PM3/12/05
to

There might easily be some late changes in
Solaris 10 Xsun about which the SRSS 3.0 knows nothing,
which then break Sun Ray's own power management
(which does work on Solaris 8 and 9).


Thomas

Fredrik Lundholm

unread,
Mar 12, 2005, 6:14:10 PM3/12/05
to
In article <39gtrrF...@individual.net>,
Thomas Dehn <thomas...@arcor.de> wrote:

>Some xset commands are supposed to work on Sun Ray.

'xset b off' works! :)

Martin Paul

unread,
Mar 15, 2005, 6:57:24 AM3/15/05
to
Darren Dunham <ddu...@redwood.taos.com> wrote:
> Alan Coopersmith <al...@alum.calberkeley.org> wrote:
>> Darren Dunham <ddu...@redwood.taos.com> writes in comp.unix.solaris:
>> |Are there any "startup scripts" run by the dtlogin/dtgreet environment
>> |where we can run the xset without going through this method?
>
>> /usr/dt/config/Xsetup - see the dtlogin man page for details.
>
> Right. So that's pretty trivial...
> ...
> Works for me...

Works for me, too. Thanks to both of you for your research, the fix and
that now at last I know how to communicate with dtlogin's Xsun.

I work around the issue via a finish script which installs Xsetup now.
Would be interesting though where and how the screen saver setting
got lost (esp. as it's not seen by everyone), and if we'll see a patch
for that.

Rob Shepherd

unread,
Mar 15, 2005, 9:11:51 AM3/15/05
to

Hmmmm, this still doesn't work for me on U10 with C3D.

The screensaver kicks in, but then after a while the screen comes on again.

All the other Solaris 8 and 9 machines suspend the monitors.

Can anybody work out what is happening and maybe think of a fix?

At present the machine is (as far as X is concerned) a clean 10 FCS install with
the Xserver patch from earlier posts in /etc/dt/config/Xsetup

Thanks

Rob

Darren Dunham

unread,
Mar 15, 2005, 11:01:33 AM3/15/05
to
Rob Shepherd <rob...@invalid.invalid> wrote:

> Hmmmm, this still doesn't work for me on U10 with C3D.

> The screensaver kicks in, but then after a while the screen comes on
again.

What's "after a while"? Is it random or consistent?

Any chance you've got a jittery mouse or something thats kicking it out?

Rob Shepherd

unread,
Mar 15, 2005, 11:26:28 AM3/15/05
to
Darren Dunham wrote:
> Rob Shepherd <rob...@invalid.invalid> wrote:
>
>
>>Hmmmm, this still doesn't work for me on U10 with C3D.
>
>
>>The screensaver kicks in, but then after a while the screen comes on
>
> again.
>
> What's "after a while"? Is it random or consistent?
>
> Any chance you've got a jittery mouse or something thats kicking it out?
>

"While" seems consistent, the said machine is not in my lab, and I havn't the
time to sit and watch it, I just go and check every so often.

The screensaver kicks in at [xset s n] n seconds.

After which between 5-10 minutes later the screen is back on. It never goes back
to screen save after this - unless I move the mouse, then after n seconds the
cycle repeats.

The screen is never suspended, only blanked.

I wonder if dpms is trying to suspend the monitor but failing. should
screensaver still be active though? or is the Xserver suspended also?

I will unplug the mouse and restart.

...Back in a short while with an update.

Rob Shepherd

unread,
Mar 15, 2005, 12:03:46 PM3/15/05
to
Rob Shepherd wrote:
> Darren Dunham wrote:
>
>> Rob Shepherd <rob...@invalid.invalid> wrote:
>>
>>
>>> Hmmmm, this still doesn't work for me on U10 with C3D.
>>
>>
>>
>>> The screensaver kicks in, but then after a while the screen comes on
>>
>>
>> again.
>>
>> What's "after a while"? Is it random or consistent?
>>
>> Any chance you've got a jittery mouse or something thats kicking it out?

Nope, mouse disconnected; same behaviour.

Any thoughts?

Darren Dunham

unread,
Mar 15, 2005, 12:13:48 PM3/15/05
to
Rob Shepherd <rob...@invalid.invalid> wrote:
> The screensaver kicks in at [xset s n] n seconds.

> After which between 5-10 minutes later the screen is back on. It never goes back
> to screen save after this - unless I move the mouse, then after n seconds the
> cycle repeats.

> The screen is never suspended, only blanked.

Right. So it does seem like the pm stuff isn't working instead of a
duff mouse. I don't think I have a c3d in my machines, so I can't tell
if it's particular for that framebuffer.

Rob Shepherd

unread,
Mar 16, 2005, 4:56:41 AM3/16/05
to
Darren Dunham wrote:
> Rob Shepherd <rob...@invalid.invalid> wrote:
>
>>The screensaver kicks in at [xset s n] n seconds.
>
>
>>After which between 5-10 minutes later the screen is back on. It never goes back
>>to screen save after this - unless I move the mouse, then after n seconds the
>>cycle repeats.
>
>
>>The screen is never suspended, only blanked.
>
>
> Right. So it does seem like the pm stuff isn't working instead of a
> duff mouse. I don't think I have a c3d in my machines, so I can't tell
> if it's particular for that framebuffer.
>

I added

-dev /dev/m640

to /etc/dt/config/Xservers and restated

Same behaviour :(

I'm now at a lost end.

0 new messages