XVR-300 login screen screensaver problems - SUN

This is a discussion on XVR-300 login screen screensaver problems - SUN ; Greetings, We recently bought some Ultra 25 workstations for our student labs. The prototype machines we had from last year came with XVR-100 cards. Those machines are working as expected. The XVR-300 Ultra 25's mostly work. But there are two ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: XVR-300 login screen screensaver problems

  1. XVR-300 login screen screensaver problems

    Greetings,

    We recently bought some Ultra 25 workstations for our student labs.
    The prototype machines we had from last year came with XVR-100 cards.
    Those machines are working as expected. The XVR-300 Ultra 25's mostly
    work. But there are two quirks. One is that we have to install the
    drivers by hand post install. I suspect this is due to the fact the
    the guy who runs the jumpstart server is still using Solaris 10 U2. So
    maybe if we used something newer like U6 this wouldn't be required?
    For now I can install the drivers by hand. However... The screensaver
    never turns on when gdm is displayed. (We disable dtlogin and enable
    gdm) This only happens with the new XVR-300 cards.
    The XVR-100 cards hooked up to sun monitors seem to go into power save
    after like 10 or 20 minutes.

    Does anyone know a way around this? I suspect its because the "xset"
    program reports (xset q) that FBPM (Frame Buffer Power Management) is
    disabled on this hardware. I'm worried all the sun monitors we bought
    will burn in.

    Thanks for any ideas anyone might have! I tried running xset +dpms as
    root on the box in a cron job and it didn't work.

  2. Re: XVR-300 login screen screensaver problems

    In article <83f62440-ecac-4879-b629-e9a2c1554018@2g2000hsn.googlegroups.com> gsgatlin@eos.ncsu.edu writes:
    >Greetings,
    >
    >We recently bought some Ultra 25 workstations for our student labs.
    >The prototype machines we had from last year came with XVR-100 cards.
    >Those machines are working as expected. The XVR-300 Ultra 25's mostly
    >work. But there are two quirks. One is that we have to install the
    >drivers by hand post install. I suspect this is due to the fact the
    >the guy who runs the jumpstart server is still using Solaris 10 U2. So
    >maybe if we used something newer like U6 this wouldn't be required?
    >For now I can install the drivers by hand. However... The screensaver
    >never turns on when gdm is displayed. (We disable dtlogin and enable
    >gdm) This only happens with the new XVR-300 cards.


    Perhaps the Jumpstart profile just isn't loading SUNWnfb, SUNWnfbcf,
    and SUNWnfbw.

    >The XVR-100 cards hooked up to sun monitors seem to go into power save
    >after like 10 or 20 minutes.


    You mean that they come out of power saving mode, right? Oh yeah,
    we've seen this. We had a ticket open with Sun on it, and it turns
    out that they are working on a fix. But, we were able to figure
    out a work-around.

    Copy /usr/dt/config/Xsetup to /etc/dt/config/Xconfig. Append the
    following line to /etc/dt/config/Xconfig:

    $XDIR/xset s 600 0

    Screen blanking will now work properly.

    The default for the two timeouts is 600 seconds. What appears to be
    happening is that the screen blanks properly at 600 seconds, but at
    1200 seconds unblanks. The second timeout controls the "period to
    change the background pattern to avoid burn in." When this timeout
    occurs, the video is taken out of power saving mode by mistake. We
    work around this by telling Xsun to never change the background.

    >
    >Does anyone know a way around this? I suspect its because the "xset"
    >program reports (xset q) that FBPM (Frame Buffer Power Management) is
    >disabled on this hardware. I'm worried all the sun monitors we bought
    >will burn in.
    >
    >Thanks for any ideas anyone might have! I tried running xset +dpms as
    >root on the box in a cron job and it didn't work.


    The problem with this that root can't connect to the running X server
    with the default configuration. This can be changed, but probably
    shouldn't be.
    --
    Jeff Wieland

+ Reply to Thread