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.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna

Martin Paul wrote:

>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.
>
>mp.
>  
>
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.

Pete.

Peter Bunclark  <psb@ast.cam.ac.uk> probably said:
>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.

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

P.

-- 
pir

In comp.unix.solaris Peter Bunclark <psb@ast.cam.ac.uk> wrote:
> Yes, we found this out the hard way with an XVR-100 on a Blade 2000.

In the meantime I confirmed it on a Blade 1500, too. That's a real
nuisance, I wish I had known that before.

> 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.

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.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna

In article <4002a110$0$16036$3b214f66@usenet.univie.ac.at>, Martin Paul <map@par.univie.ac.at> writes:
>
>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.
>

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
problematic.

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      | km@mathcs.emory.edu          
Emory University    | 
Dept of Math and CS | Phone: Voice (404) 727-7963 
Atlanta, GA 30322   |        FAX 727-5611

km@mathcs.emory.edu writes in comp.unix.solaris:
|The board is actually an ATI Radeon 7500 (Mac Edition) and has

7000 actually.

-- 
________________________________________________________________________
Alan Coopersmith                              alanc@alum.calberkeley.org
http://www.CSUA.Berkeley.EDU/~alanc/       aka: Alan.Coopersmith@Sun.COM
  Working for, but definitely not speaking for, Sun Microsystems, Inc.

In article <4002a110$0$16036$3b214f66@usenet.univie.ac.at> Martin Paul <map@par.univie.ac.at> writes:
>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 ..

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

In comp.unix.solaris Jeff Wieland <wieland@nospampurdue.edu> wrote:
> Try rdesktop 1.3.  Works fine under a 24 bit display, and also
> supports greater than 8 bit depth.  

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:
      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.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna

On 15 Jan 2004 10:02:19 GMT, Martin Paul wrote:
> 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:

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:
http://cvs.sourceforge.net/viewcvs.py/rdesktop/rdesktop/xwin.c?r1=1.134&r2=1.135&diff_format=u

Regards,
  Michael

Hi together,

> version distributed through blastwave, which AFAIK has the necessary
                              ~~~~~~~~~
> patch applied.

yes, it has. ;-)

	Thomas

In comp.unix.solaris Michael Gernoth <mike@gernoth.net> wrote:
> 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.

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
visuals.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna

In comp.unix.solaris Martin Paul <map@par.univie.ac.at> wrote:
> In comp.unix.solaris Michael Gernoth <mike@gernoth.net> wrote:
>> 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.
> 
> Thanks a lot - this indeed fixes the problem I was describing.

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.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna

On 19 Jan 2004 09:33:48 GMT, Martin Paul wrote:
> 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.

Ok, i improved that code a bit. Please test it.
You can find the patch at:
http://www.zerfleddert.de/rdesktop/rdesktop-visual.diff

> 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.

-C should be ignored when using 24 bit...
Sourceforce CVS is down, so I can't fix this currently.

Regards,
  Michael

Hi,

> Ok, i improved that code a bit. Please test it.
> You can find the patch at:
> http://www.zerfleddert.de/rdesktop/rdesktop-visual.diff

I just repackaged the blastwave version of rdesktop which will be
available within a day from all mirror sites.

	Thomas

In comp.unix.solaris Michael Gernoth <mike@gernoth.net> wrote:
> On 19 Jan 2004 09:33:48 GMT, Martin Paul wrote:
>> 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.
> 
> Ok, i improved that code a bit. Please test it.

Ok, I tested with the CVS version, which obviously contains all your
fixes as of now. rdesktop now indeed seems to select a TrueColor
visual, and basically works on this visual (tested on PGX64/Solaris 9,
Creator 3D/Solaris 9). Thanks for your efforts.

I still have problems on the XVR-100 (both Solaris 8/9 with up to date
XVR-100 driver patch and Xsun patch). When fake8 is enabled, the
backing store still has problems (rdesktop window isn't repainted).
xwininfo shows "Backing Store State: NotUseful" in that case.

If fake8 is disabled, xwininfo shows "Backing Store State: Always"
(which seems to be the correct thing) and the rdesktop window is
repainted correctly.

In both cases it displays some characters wrong (e.g.  'i' shows up as '!'). 
Hard to describe, so I put a screenshot onto:

  http://www.par.univie.ac.at/~martin/rdesktop.gif

No idea if this is a problem of rdesktop, a problem of the XVR-100
in 24-bit visuals, or a combination of both. Probably someone with
in-depth knowledge of both X11 and Sun's framebuffers can tell.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna

On 20 Jan 2004 09:36:47 GMT, Martin Paul wrote:
> I still have problems on the XVR-100 (both Solaris 8/9 with up to date
> XVR-100 driver patch and Xsun patch). When fake8 is enabled, the
> backing store still has problems (rdesktop window isn't repainted).
> xwininfo shows "Backing Store State: NotUseful" in that case.

In this case rdesktop should use its internal backing store, which
should work. (I tested it yesterday).
If it does not get activated, this would explain your problem.
You can force the internal backing-store by inserting
g_ownbackstore = True;
at line 795 of xwin.c. (simply copy line 794)

> In both cases it displays some characters wrong (e.g.  'i' shows up as '!'). 
> Hard to describe, so I put a screenshot onto:

This sounds like the usual Trident/ATI-driver hw-accel bug in XF86...
If you were using XFree86 you could set the XaaNoMono8x8PatternFillRect
option, which would solve it.

Regards,
  Michael

Michael Gernoth <mike@gernoth.net> wrote:
> On 20 Jan 2004 09:36:47 GMT, Martin Paul wrote:
>> I still have problems on the XVR-100 (both Solaris 8/9 with up to date
>> XVR-100 driver patch and Xsun patch). When fake8 is enabled, the
>> backing store still has problems (rdesktop window isn't repainted).
>> xwininfo shows "Backing Store State: NotUseful" in that case.
> 
> In this case rdesktop should use its internal backing store, which
> should work. (I tested it yesterday).
> If it does not get activated, this would explain your problem.

Indeed. Forcing internal backing-store fixes it. I checked output
of DoesBackingStore(g_screen), and it says "Always" - seems like
this is not true.

I guess this means there's something wrong in the card driver or
in Xsun, when it says it does backing store, but actually does not ?
xdpyinfo says "options: backing-store YES, save-unders YES".

If I can't find another work-around or fix for that, is it a good
idea to actually force g_ownbackstore to True in rdesktop, or will
that lower performance or anything ? I'd prefer to have one rdesktop
binary working on all machines/framebuffers, of course.

>> In both cases it displays some characters wrong (e.g.  'i' shows up as '!'). 
>> Hard to describe, so I put a screenshot onto:
> 
> This sounds like the usual Trident/ATI-driver hw-accel bug in XF86...
> If you were using XFree86 you could set the XaaNoMono8x8PatternFillRect
> option, which would solve it.

If someone from Sun is listening, I'd be interested if the bug is
already known, and if there's a similar workaround for Solaris, 
or a patch in progress.

Thanks a lot again.

mp.
-- 
Systems Administrator | Institute for Software Science | Univ. of Vienna