According to Keven R. Pittsinger:
> Grant McDorman sayeth:
> > Both xv and xwd don't work with mixed visuals - i.e. if your default visual
> > is 8bpp, but you're grabbing windows that are 16 or 24 bits deep. If that
> > isn't the case, then they're fine; if, on the other hand, you do have that
> > case you get what you described - black images. They both work with 24 bits
> > - or, at least, the vanilla X11R6.3 and Solaris 2.5 xwd work with 24 bits. I
> > do not know about 16bpp.
>
> Um, *HOW* do you do mixed visuals in XFree? Enquring minds wanna know...
I don't know if XFree supports mixed visuals (not having access to a system
running Linux) - take a look at the output of xdpyinfo; if more than one
depth is listed, you've got multiple visuals. I do know that Sun systems
support multiple visuals - one system I've got here supports 1, 8, and 24
bit visuals, with the 8-bit PseudoColour and the 24-bit TrueColour being
displayable simultaneously (i.e. without colourmap flashing):
name of display: :0.0
version number: 11.0
vendor string: Sun Microsystems, Inc.
vendor release number: 3510
screen #0:
depths (2): 1, 8
number of visuals: 6
screen #1:
depths (3): 1, 8, 24
number of visuals: 11
[edited and cut for brevity]
On the other hand, the VNC server I'm using only supports one visual (depth
defined by a command-line option). It's based on the XFree sources, so XFree
itself may only support one visual, too.
-----
Going back to the original question - why xv/xwud dumps show up black -
there are several possiblities:
1) the grab is of pseudocolour (colourmapped) data but is interpreted as
TrueColour, resulting in small pixel values (but not black!)
2) the grab is of TrueColour but the program uses the wrong pixel size (i.e.
24 instead of 16, or 8 bits for each of R, G and B instead of about 5?),
also resulting in small pixel values (dark but not black)
3) the grab is of TrueColour but the program is interpreting it as
PseudoColour with a colourmap filled with 0 (black) values
4) something else is going on
The first two, of course, may not be that 'black'. Case 3 will be.
'xv' will tell you what sort of image it thinks it has - (for version 3.10)
use 'Image Info' from the 'Windows' menu. This should say something like
'Format: <24-bit internal>' and 'Colors: Using TrueColor visual'. You can
also pull up the colour editor window, which will not only tell you if the
image is colourmapped or not, but will shown you the colourmap, if
applicable.
xwd, of course, doesn't directly tell you what it got, but you can use xv on
the resulting file and look at the same things as above.
It's my guess that xv and xwd are confused by the depth-16 display. What
type of visual that might be I don't know - the Windows display drivers I've
seen only list 24 or 32 bit as 'TrueColor'; 16 bit is listed as 'HighColor',
whatever that means. Whatever it is, most X servers (and client programs)
did not, until the advent of XFree, have a 16 bit colour mode.
Xvfb *does* support a 16-bit mode; when run in 16-bit TrueColour, xwd grabs
work just fine. I can't test what xv does for this case, since I can't
interact with Xvfb.
When I set the screen to 16-bit 'highcolour' with a free X server for
Windows (
http://www.microimages.com/freestuf/mix/mix.htm), it reported
32-bit TrueColour to clients; when the screen was 8-bit, it reported a bunch
of visuals, including 8-bit PseudoColour and 8-bit TrueColour. This leads me
to suspect that 16-bit is a 'truecolour' mode (with about 5 for red, green
and blue).
--
Grant McDorman <grant_at_isgtec.com>
ISG Technologies, Inc. http://www.isgtec.com
Mississauga, Ontario, Canada
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
- application/pgp-signature attachment: stored
Received on Fri May 29 1998 - 16:00:21 BST