1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

XVR-100 console output

Discussion in 'Sun Hardware' started by Martin Paul, Jan 9, 2004.

  1. Martin Paul

    Martin Paul Guest

    I just received some XVR-100 framebuffers that I ordered to
    replace the PGX64 in some machines which are connected to
    TFT-Displays with digital inputs (DVI-D) - I want to get
    rid of the analog graphics connection, for better image quality.

    Now I read this note in the XVR-100 manual:

    Note: Only the Sun XVR-100 graphics accelerator HD15 video output
    connector can provide console output. You cannot set the DVI video
    connector as the console.

    Can anybody confirm that this is true, and that it's not possible
    to change that ? This would mean that one wouldn't see console
    output at all if the display is hooked up to the machine with a
    digital connection. While I rarely need console output on desktop
    workstations, it means that in case of trouble (when working in
    the PROM) I'd have to temporarily attach an analog monitor.

    Martin Paul, Jan 9, 2004
    1. Advertisements

  2. Yes, we found this out the hard way with an XVR-100 on a Blade 2000.
    Presumably, it `just' needs a prom upgrade. We just use it in analog, it's
    just to scary to have a system that is blind during (possibly non-) bootup.

    Peter Bunclark, Jan 9, 2004
    1. Advertisements

  3. One workaround would be to set it to serial console and use a terminal
    or terminal server to monitor the boot process.

    Peter Radcliffe, Jan 9, 2004
  4. Martin Paul

    Martin Paul Guest

    In the meantime I confirmed it on a Blade 1500, too. That's a real
    nuisance, I wish I had known that before.
    I have at least one machine with a 1600x1200 21" TFT, where I can
    see a noticable difference between analog and digital, so I'd really
    prefer a digital connection. Same for a NEC LCD 1880SX on my desk,
    which already has a very good picture on an analog connection.

    In some situation a workaround can be to connect both the analog
    and the digital output to the display, and set the display to
    autosense on the inputs. It will use the analog (console) connection
    on bootup, and switch to the digital connection when the Xserver
    is started. Just hope it doesn't confuse the user when the autosense
    doesn't work, and he/she can't find it's login dialog later.

    Some people have two machines connected to their display here, though;
    in that case I can only let the one on the digital connection boot
    "blind". When I need to work in OBP I'll have to switch cables or
    bring in a monitor or use the serial connection. Not too much fun.

    It also seems that DDC doesn't work at all on the digital output,
    I always have to hard-code the display resolution with fbconfig.
    Switching monitors between machines now means I have to remember
    using fbconfig afterwards, and to add and maintain fbconfig setup
    in my jumpstart config (based on machine name).

    Another problem I have with the XVR-100: While it supports a 24+8 bit
    mode via the "fake8" option to fbconfig, it's not exactly the same
    as with the PGX64 (and its depth 32 option). The PGX64 uses an 8 bit
    Pseudocolor display as the default display, while the XVR-100 sets
    the default to 24 bit. 8-bit application will fail there, unless
    one modifies Xservers to set defdepth to 8, too. E.g. rdesktop won't
    work otherwise (it only works on 8-bit displays under Solaris, and
    has no -visual option either). One more thing to take care of ..

    I waited a long time for an affordable graphics card with DVD-D
    output for my Suns, now I'm a little disappointed (adding missing
    Solaris 9 support for the Blade 1500 and the killed Ultra 1 support
    in Solaris.Next, that's quite a lot of disappointment from Sun
    recently). Sorry for the rant.

    Martin Paul, Jan 12, 2004
  5. I think there are more disappointments on the XVR100 to add.

    The board is actually an ATI Radeon 7500 (Mac Edition) and has
    hardware support for a composite video out, and accelerated 3D
    graphics with double buffering and a Z buffer. Sun supports none
    of this.

    More generally Sun doesn't support the XV extenion extension to
    the X server to allow overlay support with variable gamma, again
    even when the hardware supports it. This makes any kind of multimedia

    I think its great that Sun is finally using commodity boards to keep
    costs down, but given that they charge twice the street price for
    this board I would at least expect them to a better job of supporting
    its feature set. If OS X on a Mac can do it, why not Solaris?
    Ken Mandelberg, Jan 12, 2004
  6. writes in comp.unix.solaris:
    |The board is actually an ATI Radeon 7500 (Mac Edition) and has

    7000 actually.
    Alan Coopersmith, Jan 12, 2004
  7. Martin Paul

    Jeff Wieland Guest

    Try rdesktop 1.3. Works fine under a 24 bit display, and also
    supports greater than 8 bit depth. It works great with the -a15
    option (for 15 bit color) when talking to Windows XP boxes.
    Jeff Wieland, Jan 14, 2004
  8. Martin Paul

    Martin Paul Guest

    What framebuffer and which command line options do you use ?

    I have rdesktop, but when trying to run it on default 24 bit visual
    I always get:

    X Error of failed request: BadMatch (invalid parameter attributes)
    Major opcode of failed request: 78 (X_CreateColormap)
    Serial number of failed request: 42
    Current serial number in output stream: 50

    rdekstop 1.3.0, with -K -g1024x768 -C (without -C the colors are strange)
    on an XVR-100 with xdpyinfo like:

    screen #0:
    dimensions: 1600x1200 pixels (451x338 millimeters)
    resolution: 90x90 dots per inch
    depths (3): 1, 24, 8
    number of visuals: 7
    default visual id: 0x23
    visual id: 0x23
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits

    I had tested on other framebuffers before, and always got the same
    error when the default visual was 24 bit.

    Martin Paul, Jan 15, 2004
  9. Martin Paul

    Jeff Wieland Guest

    The "-C" says to use a private colormap, which I suspect has no
    meaning with a 24 bit visual. I get the same error when I use
    the "-C" option with a 24 default visual.

    I run this on a Techsource GFX-32C, the PGX-64 in my 'Blade 150, and
    the PGX-24 in my Ultra-5 (running in 24 bit mode). When talking to
    an Windows 2000 server, I typically use

    rdesktop -g 1024x768 <hostname>

    When accessing a PC running Windows XP, I'll use

    rdesktop -a15 -g 1024x768 <hostname>

    I'm curious as to why you're using the -K option?
    Jeff Wieland, Jan 16, 2004
  10. rdesktop 1.3.0 has a bug with RGB-displays on BigEndian machines (and
    BGR-displays on LittleEndian machines). Use the CVS version or the
    version distributed through blastwave, which AFAIK has the necessary
    patch applied.
    If you just want the patch, look here:

    Michael Gernoth, Jan 16, 2004
  11. Hi together,
    yes, it has. ;-)

    Thomas Glanzmann, Jan 18, 2004
  12. Martin Paul

    Martin Paul Guest

    In a default 24 bit visual rdesktop didn't work at all (showed
    the error I mentioned in a previous post). With the patch to
    xwin.c posted by another reader, it works now (without -C).

    On a default 8 bit visual without -C rdesktop says:

    WARNING: Screen depth is 8 bits or lower: you may want to use -C
    for a private colourmap

    and the colors in the rdesktop window just look wrong.
    It's needed to make the special keys on the Sun keyboard work
    (Open, Close, etc. on the left side of the keyboard). I'm using
    these frequently.

    Martin Paul, Jan 19, 2004
  13. Martin Paul

    Martin Paul Guest

    Thanks a lot - this indeed fixes the problem I was describing.

    Now there's only one problem left - rdesktop doesn't seem to have
    code to select the "best" visual available, it always uses the
    default visual. Other applications are more intelligent there.

    As with some framebuffers the default visual is still 8 bit,
    I have to run rdesktop with -C there. If the default visual
    is 24 bit, though, rdesktop won't run with -C. I guess I could
    use a shell script wrapper which reads xdpyinfo output and looks
    for "depth of root window" to look for 8/24 bit (does anybody
    know a better way for that ?) and adds -C as needed.

    Is there a patch for rdesktop which enhances the selection of
    the visual it uses ? Or at least a fix which adds a -visual
    option so one can set the TrueColor visual manually.

    As 24 bit with rdesktop now works, one could set the defdepth to 24
    in Xservers, but I'd prefer not to change that on all my machines,
    as there might be other applications which don't like TrueColor

    Martin Paul, Jan 19, 2004
  14. Martin Paul

    Martin Paul Guest

    Not really - while the rdesktop window comes up fine, as soon as
    it is iconified and re-openend (or partly covered by another window
    and put to the front again) the rdesktop window isn't re-drawn, and
    stays black. Tested on a 24-bit visual on the XVR-100 on Solaris 8
    and 9 with recent Xsun patches.

    Martin Paul, Jan 19, 2004
  15. Ok, i improved that code a bit. Please test it.
    You can find the patch at:
    -C should be ignored when using 24 bit...
    Sourceforce CVS is down, so I can't fix this currently.

    Michael Gernoth, Jan 19, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.