Hi, Grant,
I think you explained this to me before (about a year
ago), and I've been trying to figure out since.
I've done xdpyinfo on the 24-bit desktop, from which
I launch the viewer that unsuccessfully connects to
the 8-bit desktop. It is 32-bit, depth of 24. You'll
have to excuse my ignorance, but I thought the depth
and bit-per-pixel was the same. I assume that they
use a 32-bit word to store the 24 bits because it's
messy having data cross word boundaries.
That 24-bit display is my virtual "hardware". It isn't
actually bound to any real hardware. So I
assume that the "default" visual would be true
color, since the 24-bit desktop is true color.
There should be no reason by pseudocolor is
being used when I launch a viewer to connect to
8-bit true color display.
Most of the apps I use have no problem with an
8-bit true-color display, which was the default
for TightVNC1.2.2. I just had to live with very
coarse control in my syntax colorizing editor.
The only problem is when connecting to an 8-bit
display from a 24-bit display (a VNC server). And
only when the 24-bit display is on the sun. If I
connect to the 8-bit display from my laptop, things
are fine, no crashing of the 8-bit VNC server.
It may be that the crashing happens only when
the 8-bit display was started as a TightVNC1.2.2
server. I can't confirm that since I've overwritten
those binaries, but evidence enough is that I can
connect to 8-bit displays from 24-bit displays if
both are started using TightVNC1.2.7 binaries.
Unfortunately, serveral of my multi-week simulations
are (were) running on 1.2.2 servers. I've already killed
2 of the 3 simulations prematurely by
experimenting with the problem.
As for specifying a viewer depth of 8 when
connecting to 8-bits from 24-bits, I don't see
why this is just a hint when both are true color.
The conversion just requires truncation of the
the lower bits in each color plane. The
equivalent switch in the windows based-viewer
seems to be -8bit, which *does* cause the
8-bit VNC server to recognize an 8-bit
client in the server log. So the 8-bit server
only seems to ignore 8-bit requests from
sun-based viewers. Maybe the viewer just
doesn't forward the request.
Another hint is that the 8-bit server log reports
protocol version 3.3 when a sun-based viewer
connects, but reports version 3.5 when the
windows-based viewer connects. Is the sun
viewer code less up-to-date than the windows
viewer code? I vim-grepped the changed log
for 3\.\d\> and the latest occurance refers only
to 3.3.3r[12], 2000-10-26 at 12:19.
Fred
--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
Grant McDorman wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On December 17, 2002 04:09 am, Shing-Fat Fred Ma wrote:
Hello,
I thought I overcame the problem of 8-bit
desktops crashing as soon as a viewer connects
to it from a 24-bit desktop. I might have been
wrong. I just tried again and the 8-bit desktop
died. The only difference between
When I launch the viewer, I get the message
Connected to VNC server, using protocol version 3.3
VNC server default format:
8 bits per pixel.
True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6
This is the server, which is 8 bit TrueColour. Some applications may not like
this <grin>.
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Most significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8
blue 0
This is the local (viewer) machine, which has a TrueColour display. The pixel
information refers to the viewer's internal colour handling.
For comparison, the output from the latest RealVNC viewer on my Sun Sparc
connecting to a TrueColour windows machine is:
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap and visual, TrueColor, depth 24.
Using viewer's native pixel format:
32 bits per pixel.
Most significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
The output in this version is a little clearer.
Obviously, the 8bpp is for the server while the 32bpp is
for the desktop from which the viewer was launched.
This is strange, since the latter has 24bpp. The message
remains the same even if the viewer is invoked with
"-depth 8". And the log file for the 8bpp server shows
that client (i.e. the viewer) has 32bpp format, regardless
of whether the viewer was launched with "-depth 8".
The -depth option for the viewer could be better described as a 'hint'; i.e.
in your case, you're asking the viewer to use depth 8 *if possible*. However,
most hardware does not support multiple simutaneous depths (the only kind I
know of personally that does is some Sun Sparc display boards).
On top of that, the '-depth' option is pretty useless without the '-owncmap'
option. Lacking the latter, the viewer will still use the default colourmap
even if an 8 bit visual is available. So to get an 8-bit visual and
colourmap, you have to use '-depth 8 -owncmap'.
In my case, the output from 'vncviewer' with these options is:
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
PseudoColor visual with private colormap, depth 8.
Using viewer's native pixel format:
8 bits per pixel.
Colour map (not true colour).
Incidentally, in testing this I found a problem with the viewer: if there are
resources (xrdb -query) that specify colours for the controls in the viewer,
the viewer will crash.
- --
Grant McDorman <[EMAIL PROTECTED]>, Sr. Software Design Consultant
Cedara Software Corp. <URL:http://www.cedara.com>
(formerly I.S.G. Technologies Inc.)
Mississauga, Ontario, Canada
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (SunOS)
iD8DBQE9/0YKLVa+EmyjizARAmsIAJ42/qVppJQvFgbELEh4Fe4fO8nxdACaAhyW
jwp0FcKn2F46Te2qPoa17G8=
=AZFd
-----END PGP SIGNATURE-----
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list
