| Unsupported X Windows visual [message #14303] |
Thu, 11 February 1999 00:00  |
Harald von der Osten-
Messages: 15
Registered: February 1999
|
Junior Member |
|
|
Hi all,
I have upgraded my OS to Linux 2.0.36 with window manager KDE. As soon
as graphical routines are called within IDL I get the error message
% Unsupported X Windows visual (class: StaticGray, depth:0)
% Substituting default (class: <UndefinedVisual>, Depth:0)
How can I handle this in IDL settings?
Thank you very very much for any hints.
Harald
|
|
|
|
|
|
|
|
| Re: unsupported X Window [message #16006 is a reply to message #14303] |
Tue, 22 June 1999 00:00  |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
Ramin Sina wrote:
>
> % Unsupported X Windows visual (class: StaticGray, depth: 0).
> Substituting default (class: <UndefinedVisual>, Depth: 0).
> % Execution halted at: $MAIN$
>
You are probably working with 32 bits colordepth which is not supported
by IDL. There have been a couple of postings recently about this, check
www.deja.com for more information. If you set your X server to 8 bpp
(e.g. startx -- -bpp 8) IDL should work fine. Better of course is 24
bpp, but there are other programs that cause trouble in this mode, and
for my graphics card (Permedia II) it didn't work.
Liam Gumley has written a tool to set the correct display parameters. I
hope he doesn't mind if I attach it here. Make sure you start with no
startup file, then call colorset at the beginning of your session. Then
call colors which defines a few drawing colors. Then try
plot,findgen(10),color=1
and you should get a magenta line.
(didn't work for me unfortunately)
Martin.
--
|||||||||||||||\\\\\\\\\\\\\-------------------///////////// //|||||||||||||||
Martin Schultz, DEAS, Harvard University, 29 Oxford St., Pierce 109,
Cambridge, MA 02138 phone (617) 496 8318 fax (617) 495 4551
e-mail mgs@io.harvard.edu web http://www-as/people/staff/mgs/
PRO COLORSET, RETAIN=RETAIN, DECOMPOSED=DECOMPOSED, QUIET=QUIET
;+
; NAME:
; COLORSET
;
; PURPOSE:
; Select true color (24 bit) if available, or pseudo color (8 bit) visual
; consistently on X, Windows, and Macintosh.
;
; CATEGORY:
; Startup utilities.
;
; CALLING SEQUENCE:
; COLORSET
;
; INPUTS:
; None
;
; OPTIONAL INPUTS:
; None
;
; KEYWORD PARAMETERS:
; RETAIN Specifies the default method used
; for backing store when creating new windows.
; 0 => No backing store
; 1 => Server or window system performs backing store
; 2 => Make IDL perform backing store (DEFAULT)
; DECOMPOSED Specifies the the way in which graphics
; color index values are interpreted when using displays with
; decomposed color (TrueColor or DirectColor visuals).
; 0 = > Color indices given by single 8 bit values (DEFAULT)
; 1 = > Color indices given by three 8 bit values
; QUIET If set, no color information is printed
; (default is to print the color table size, and number of colors)
;
; OUTPUTS:
; None
;
; OPTIONAL OUTPUTS:
; None
;
; COMMON BLOCKS:
; None
;
; SIDE EFFECTS:
; This routine changes the IDL visual for the rest of the IDL session.
;
; RESTRICTIONS:
; Only affects X, WIN, and MAC displays.
; Only has an effect if run before any windows have been
; created, and if no DEVICE commands have been executed.
;
; EXAMPLE:
; ;Execute the following command immediately after IDL startup.
; colorset
;
; MODIFICATION HISTORY:
; Written by: Liam.Gumley@ssec.wisc.edu
;-
rcs_id = "$Id: colorset.pro,v 1.2 1999/04/20 15:04:29 gumley Exp $"
;- Check keyword values
if n_elements( retain ) ne 1 then retain = 2
if n_elements( decomposed ) ne 1 then decomposed = 0
;- Check keyword flags
if not keyword_set( quiet ) then quiet = 0
;- Check if a window has been created previously
if !d.window ge 0 then begin
message, 'Window already created in this session - COLORSET may have no effect.', /continue
message, 'To ensure COLORSET works, call it before any windows are created.', /continue
endif
;- Test for supported displays
supported = 0
case 1 of
;- Windows case (visual cannot be changed)
!d.name eq 'WIN' : begin
device, decomposed=decomposed, retain=retain
supported = 1
end
;- X and Macintosh case (will revert to 8 bit visual if 24 bit fails)
!d.name eq 'X' or !d.name eq 'MAC' : begin
device, true_color=24, decomposed=decomposed, retain=retain
supported = 1
end
;- Unsupported display
else : message, 'Not supported on the ' + !d.name + ' device', /continue
endcase
;- If display supported, lock in window characteristics, and report what happened
if supported then begin
;- Create a window to lock in the visual type for this IDL session
old_window = !d.window
window, /free, /pixmap
wdelete, !d.window
if old_window ge 0 then wset, old_window
;- Report what happened
if not quiet then begin
print, 'Display device : ', !d.name
print, 'Color table size: ', strcompress( !d.table_size, /remove_all )
print, 'Number of colors: ', strcompress( !d.n_colors, /remove_all )
print, ''
endif
endif
END
PRO COLORS, START=START, NAMES=NAMES, VALUES=VALUES
;+
; NAME:
; COLORS
;
; PURPOSE:
; Load sixteen graphics colors into the color table.
;
; CATEGORY:
; Startup utilities.
;
; CALLING SEQUENCE:
; COLORS
;
; INPUTS:
; None
;
; OPTIONAL INPUTS:
; None
;
; KEYWORD PARAMETERS:
; START Start index in the color table where the graphics
; colors will be loaded (default = 0).
; NAMES If set to a named variable, returns an array of color names.
; VALUES If set to a named variable, returns an array of color index values.
;
; OUTPUTS:
; None
;
; OPTIONAL OUTPUTS:
; None
;
; COMMON BLOCKS:
; None
;
; SIDE EFFECTS:
; This routine modifies the color table.
;
; RESTRICTIONS:
; None
;
; EXAMPLE:
; ; Display a greyscale image with color text overlaid.
; device, decomposed=0
; window, /free, xs = 500, ys = 500
; colors, names=names
; bottom = 16B
; ncolors = !d.table_size - bottom
; loadct, 0, bottom=bottom, ncolors=ncolors
; tv, bytscl( dist(256), top=ncolors-1 ) + bottom
; for i=1,8 do xyouts, 30*i, 30*i, names[i], /device, charsize=1.5, color=i
;
; MODIFICATION HISTORY:
; Written by: Liam.Gumley@ssec.wisc.edu
;
; NOTES:
; The color table assignments are as follows
; Entry Color
; ----- -----
; 0 => Black
; 1 => Magenta
; 2 => Cyan
; 3 => Yellow
; 4 => Green
; 5 => Red
; 6 => Blue
; 7 => White
; 8 => Navy
; 9 => Gold
; 10 => Pink
; 11 => Aquamarine
; 12 => Orchid
; 13 => Gray
; 14 => Sky
; 15 => Beige
;-
rcs_id = "$Id: colors.pro,v 1.2 1999/04/20 15:14:45 gumley Exp $"
;- Check keyword values
if n_elements( start ) ne 1 then start = 0
;- Load graphics colors (derived from McIDAS)
r = [0,255,0,255,0,255,0,255,0,255,255,112,219,127,0,255]
g = [0,0,255,255,255,0,0,255,0,187,127,219,112,127,163,171]
b = [0,255,255,0,0,0,255,255,115,0,127,147,219,127,255,127]
tvlct, r, g, b, start
;- Set return keywords
names = [ $
'Black', 'Magenta', 'Cyan', 'Yellow', 'Green', 'Red', 'Blue', 'White', $
'Navy', 'Gold', 'Pink', 'Aquamarine', 'Orchid', 'Gray', 'Sky', 'Beige' ]
values = byte( indgen( 16 ) + start )
END
-
Attachment: colorset.pro
(Size: 3.27KB, Downloaded 94 times)
-
Attachment: colors.pro
(Size: 2.14KB, Downloaded 90 times)
|
|
|
|
|
|
|
|
| Re: Unsupported X Windows visual [message #35042 is a reply to message #14303] |
Fri, 09 May 2003 03:29 |
Nigel Wade
Messages: 286
Registered: March 1998
|
Senior Member |
|
|
Karl Schultz wrote:
>
> "Nigel Wade" <nmw@ion.le.ac.uk> wrote in message
> news:b9djf6$j1l$1@south.jnrs.ja.net...
>> Hannah Chenh wrote:
>>
>>> "Karl Schultz" <kschultz_no_spam@rsinc.com> wrote in message
>>>> The thread suggests that there is a patch available that solves a
> problem
>>>
>>> The specified patch(newer version) for solaris 8 was installed on the
>>> blade 100.
>>>
>>>> is not really listing this visual. Perhaps you can post the output
>>>> from
>>>> xdpyinfo? (This will give me some other clues)
>>>
>>> Here is the output of xdpyinfo on the blade:
>>>
>>
>> [dpyinfo snipped]
>>
>> Do you get the same output if you run xdpyinfo on the HP machine?
>> You should if X is really talking to the display on the blade.
>
> The top of the xdpyinfo output suggests that the information is indeed
> from
> the Sun server.
Of course it does - xdpyinfo was run on the Blade.
> The location of the client does not (should not) matter
> as long as the DISPLAY variable points to the server in question.
>
I know that, that was exactly my point. I want to be sure that when logged
onto the HP machine the DISPLAY enviroment variable is pointing correctly
back to the Blade. Providing the output of xdpyinfo *while logged onto the
HP* would demonstrate that, and show what info the X server on the Blade
was providing to clients.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
|
|
|
|
| Re: Unsupported X Windows visual [message #35044 is a reply to message #14303] |
Thu, 08 May 2003 20:01 |
hchenh
Messages: 5
Registered: May 2003
|
Junior Member |
|
|
After installing the newest patch 108606-31 for solaris 8 (108606-28
was installed before) and set "m64config -depth 32", the problem is
solved.
Thanks to Nigel Wade, Karl Schultz and Richard L. Hamilton.
Hannah
|
|
|
|
| Re: Unsupported X Windows visual [message #35046 is a reply to message #14303] |
Thu, 08 May 2003 17:18 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Hannah Chenh" <hchenh@ucsd.edu> wrote in message
news:ca36e435.0305081429.57cea684@posting.google.com...
>> Hannah, what DEVICE commands are being issued? (Make sure that you
check
>> startup files, etc)
>
> Here are the steps I used:
>
> 1. From SUN Blade terminal, login HP via SSH (IDL was installed on HP)
> 2. set DISPLAY to SUN's display
> 3. issue "xhost +" on SUN's terminal
> 4. start IDL
> 5. IDL> DEVICE,PSEUDO_COLOR=8
> 6. IDL> DEVICE,GET_VISUAL_DEPTH=DEPTH;PRINT,DEPTH
> % Unsupported X Windows visual (class: PseudoColor, depth: 8).
> Substituting default (class: TrueColor, Depth: 24).
> IDL>
>
> I got the same error if I use IDL_STARTUP file.
I sat down at the console of a Sun workstation and ran the same IDL
commands. The X server had several visuals, including a 24-bit TrueColor
and an 8-bit PseudoColor. The latter was the default visual on the X
server. So, the environment is pretty similar to the one on your Blade.
I didn't get the error message and the value of depth was 8, as expected.
I then started a new IDL session and just ran the DEVICE,
GET_VISUAL_DEPTH=depth command and got a value of 24 for depth.
So, things look OK on this machine. There may be something wrong with the X
server on your Blade machine. IDL is just calling XGetVisualInfo with the
Screen, Class, and Depth set in the template, and is getting no visuals in
the returned list. This seems broken to me.
There is only one Screen on your server, so I don't think it is
Screen-related.
I don't think that SSH is the problem, because you wouldn't have gotten a
Display connection if there was an SSH tunneling problem.
This code hasn't changed much in IDL over many releases, so I doubt that you
have something old enough that may have had a problem in this area.
If you are a programmer, it wouldn't be hard to write a short program that
opens an X connection and just calls XGetVisualInfo with the template set as
I mentioned above. If the list comes back empty, then you'd have something
concrete to report to Sun.
My last longshot suggestion is to try running IDL in 32-bit mode on the HP,
if you were trying it in 64-bit mode. You are sending X protocol over the
network, and there's a chance that there's a protocol encode/decode problem
someplace.
Karl
|
|
|
|
| Re: Unsupported X Windows visual [message #35048 is a reply to message #14303] |
Thu, 08 May 2003 15:29 |
hchenh
Messages: 5
Registered: May 2003
|
Junior Member |
|
|
> Hannah, what DEVICE commands are being issued? (Make sure that you check
> startup files, etc)
Here are the steps I used:
1. From SUN Blade terminal, login HP via SSH (IDL was installed on HP)
2. set DISPLAY to SUN's display
3. issue "xhost +" on SUN's terminal
4. start IDL
5. IDL> DEVICE,PSEUDO_COLOR=8
6. IDL> DEVICE,GET_VISUAL_DEPTH=DEPTH;PRINT,DEPTH
% Unsupported X Windows visual (class: PseudoColor, depth: 8).
Substituting default (class: TrueColor, Depth: 24).
IDL>
I got the same error if I use IDL_STARTUP file.
|
|
|
|
| Re: Unsupported X Windows visual [message #35051 is a reply to message #14303] |
Thu, 08 May 2003 09:32 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Nigel Wade" <nmw@ion.le.ac.uk> wrote in message
news:b9djf6$j1l$1@south.jnrs.ja.net...
> Hannah Chenh wrote:
>
>> "Karl Schultz" <kschultz_no_spam@rsinc.com> wrote in message
>>> The thread suggests that there is a patch available that solves a
problem
>>
>> The specified patch(newer version) for solaris 8 was installed on the
>> blade 100.
>>
>>> is not really listing this visual. Perhaps you can post the output from
>>> xdpyinfo? (This will give me some other clues)
>>
>> Here is the output of xdpyinfo on the blade:
>>
>
> [dpyinfo snipped]
>
> Do you get the same output if you run xdpyinfo on the HP machine?
> You should if X is really talking to the display on the blade.
The top of the xdpyinfo output suggests that the information is indeed from
the Sun server. The location of the client does not (should not) matter as
long as the DISPLAY variable points to the server in question.
> There's something definitely wrong in that the blade says the default
visual
> is 8bit PseudoColor yet IDL is using the default of 24bit TrueColor.
From the IDL help:
How IDL Selects a Visual Class
When opening the display, IDL asks the display for the following visuals, in
order, until a supported visual class is found:
1.. DirectColor, 24-bit
2.. TrueColor, 24-bit
3.. TrueColor, 16-bin (on Linux platforms only)
4.. PseudoColor, 8-bit, then 4-bit
5.. StaticColor, 8-bit, then 4-bit
6.. GrayScale, any depth
7.. StaticGray, any depth
You can override this behavior by using the DEVICE routine to specify the
desired visual class and depth before you create a window. For example, if
you are using a display that supports both the DirectColor, 24-bit-deep
visual, and an 8-bit-deep PseudoColor visual, IDL will select the
24-bit-deep DirectColor visual. To instead use PseudoColor, issue the
following command before creating a window:
DEVICE, PSEUDO_COLOR = 8
The colormap/visual class combination is chosen when IDL first connects with
the X Window server. Note that if you connect with the X server by creating
a window or using the DEVICE keyword to the HELP procedure, the visual class
will be set; it then cannot be changed until IDL is restarted. If you wish
to use a visual class other than the default, be sure to set it with a call
to the DEVICE procedure before creating windows or otherwise connecting with
the X Window server.
----
I'm not sure what's going on. IDL should have chosen the 24-bit DirectColor
visual as its default, yet the error message suggests that it is TrueColor.
Hannah, what DEVICE commands are being issued? (Make sure that you check
startup files, etc)
|
|
|
|
| Re: Unsupported X Windows visual [message #35054 is a reply to message #14303] |
Thu, 08 May 2003 05:44 |
Nigel Wade
Messages: 286
Registered: March 1998
|
Senior Member |
|
|
Hannah Chenh wrote:
> "Karl Schultz" <kschultz_no_spam@rsinc.com> wrote in message
>> The thread suggests that there is a patch available that solves a problem
>
> The specified patch(newer version) for solaris 8 was installed on the
> blade 100.
>
>> is not really listing this visual. Perhaps you can post the output from
>> xdpyinfo? (This will give me some other clues)
>
> Here is the output of xdpyinfo on the blade:
>
[dpyinfo snipped]
Do you get the same output if you run xdpyinfo on the HP machine?
You should if X is really talking to the display on the blade.
There's something definitely wrong in that the blade says the default visual
is 8bit PseudoColor yet IDL is using the default of 24bit TrueColor.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
|
|
|
|
| Re: Unsupported X Windows visual [message #35056 is a reply to message #14303] |
Wed, 07 May 2003 17:57 |
hchenh
Messages: 5
Registered: May 2003
|
Junior Member |
|
|
"Karl Schultz" <kschultz_no_spam@rsinc.com> wrote in message
> The thread suggests that there is a patch available that solves a problem
The specified patch(newer version) for solaris 8 was installed on the blade 100.
> is not really listing this visual. Perhaps you can post the output from
> xdpyinfo? (This will give me some other clues)
Here is the output of xdpyinfo on the blade:
hostname 163% xdpyinfo
name of display: hostname:10.0
version number: 11.0
vendor string: Sun Microsystems, Inc.
vendor release number: 3600
maximum request size: 262140 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, MSBFirst, 32
image byte order: MSBFirst
number of supported pixmap formats: 3
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 132
focus: window 0x1c00036, revert to PointerRoot
number of extensions: 21
AccessX
Adobe-DPS-Extension
DOUBLE-BUFFER
DPSExtension
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
Multi-Buffering
SHAPE
SUN_ALLPLANES
SUN_DGA
SUN_OVL
SUN_SME
SYNC
SolarisIA
X3D-PEX
XC-MISC
XIE
XInputDeviceEvents
XInputExtension
XTEST
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1280x1024 pixels (361x288 millimeters)
resolution: 90x90 dots per inch
depths (3): 1, 8, 24
root window id: 0x37
depth of root window: 8 planes
number of colormaps: minimum 1, maximum 5
default colormap: 0x34
default number of colormap cells: 256
preallocated pixels: black 1, white 0
options: backing-store YES, save-unders YES
largest cursor: 64x64
current input event mask: 0x78203f
KeyPressMask KeyReleaseMask ButtonPressMask
ButtonReleaseMask EnterWindowMask LeaveWindowMask
ButtonMotionMask SubstructureNotifyMask SubstructureRedirectMask
FocusChangeMask PropertyChangeMask
number of visuals: 16
default visual id: 0x20
visual:
visual id: 0x20
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x21
class: PseudoColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x22
class: StaticColor
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x23
class: StaticGray
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: GrayScale
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x25
class: TrueColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: DirectColor
depth: 8 planes
available colormap entries: 8 per subfield
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: StaticGray
depth: 8 planes
available colormap entries: 256
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x2e
class: PseudoColor
depth: 8 planes
available colormap entries: 224
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x2f
class: PseudoColor
depth: 8 planes
available colormap entries: 224
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x29
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x2a
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x2b
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x2c
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
visual:
visual id: 0x2d
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
|
|
|
|
| Re: Unsupported X Windows visual [message #35057 is a reply to message #14303] |
Wed, 07 May 2003 14:31 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
You might try looking at this thread on Google Groups. I found it by
searching for "sun blade visual".
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&a mp;oe=UTF-8&threadm=3b66f048
.0%40cfanews.harvard.edu&rnum=5&prev=/groups%3Fhl%3D en%26lr%3D%26ie%3DUTF-8%
26oe%3DUTF-8%26q%3Dsun%2Bblade%2Bvisual
The thread suggests that there is a patch available that solves a problem
with lack of 8-bit support on some Blade machines with certain mind-boggling
collections of graphics hardware. But the discussion seems to suggest that
the 8-bit PseudoColor visual does show up in xdpyinfo output if the visual
exists and does not show up in xdpyinfo if it is not there.
IDL throws that error message when it can't find the requested visual in the
result of a XGetVisualInfo call. This leads me to believe that your server
is not really listing this visual. Perhaps you can post the output from
xdpyinfo? (This will give me some other clues)
Karl
"Hannah Chenh" <hchenh@ucsd.edu> wrote in message
news:ca36e435.0305070943.381f9f57@posting.google.com...
> Nigel Wade <nmw@ion.le.ac.uk> wrote in message
news:<b9alis$par$2@south.jnrs.ja.net>...
>> Hannah Chenh wrote:
>>
>>> Hello,
>>>
>>> I'm getting the following message when I try to use PseudoColor depth
>>> 8:
>>>
>>> % Unsupported X Windows visual (class: PseudoColor, depth: 8).
>>> Substituting default (class: TrueColor, Depth: 24).
>>>
>>> IDL 5.5 is installed on an HP-UX 11.0 machine and I'm logging from a
>>> Blade 100 running solaris 8 to use IDL. The output of xdpyinfo on the
>>> Blade shows that it supports 8 bits color.
>>>
>>> Does anyone know what is the problem?
>>>
>>> Thank you very much,
>>>
>>> Hannah
>>
>> Is DISPLAY definitely pointing to the Blade's display before starting
IDL?
>>
>> If not IDL is going to try to open the HP display which may not support
>> PsuedoColor.
>
> Yes, DISPLAY is pointing to the Blade's display. I only have this
> problem with Blade 100 running solaris 8. Other machines (Ultra
> 10,30) are working fine with PsuedoColor.
>
> Hannah
|
|
|
|
| Re: Unsupported X Windows visual [message #35060 is a reply to message #14303] |
Wed, 07 May 2003 10:43 |
hchenh
Messages: 5
Registered: May 2003
|
Junior Member |
|
|
Nigel Wade <nmw@ion.le.ac.uk> wrote in message news:<b9alis$par$2@south.jnrs.ja.net>...
> Hannah Chenh wrote:
>
>> Hello,
>>
>> I'm getting the following message when I try to use PseudoColor depth
>> 8:
>>
>> % Unsupported X Windows visual (class: PseudoColor, depth: 8).
>> Substituting default (class: TrueColor, Depth: 24).
>>
>> IDL 5.5 is installed on an HP-UX 11.0 machine and I'm logging from a
>> Blade 100 running solaris 8 to use IDL. The output of xdpyinfo on the
>> Blade shows that it supports 8 bits color.
>>
>> Does anyone know what is the problem?
>>
>> Thank you very much,
>>
>> Hannah
>
> Is DISPLAY definitely pointing to the Blade's display before starting IDL?
>
> If not IDL is going to try to open the HP display which may not support
> PsuedoColor.
Yes, DISPLAY is pointing to the Blade's display. I only have this
problem with Blade 100 running solaris 8. Other machines (Ultra
10,30) are working fine with PsuedoColor.
Hannah
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
