comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » 16-bit colors in Linux (Re: 24 bit colors in IDL)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
16-bit colors in Linux (Re: 24 bit colors in IDL) [message #13547] Thu, 19 November 1998 00:00 Go to next message
G. Hugh SONG is currently offline  G. Hugh SONG
Messages: 3
Registered: November 1998
Junior Member
David Fanning wrote:

> Andy Bristow (ajbristow@dera.gov.uk) writes:
>
>> I was just getting my head round 24-bit, having been prompted by this
>> thread. So, at Philip's suggestion I went to
>>
>> http://www.dfanning.com/tips/colors24.html
>>
>> All well and good. Sounds relatively straightforward.
>>
>> So on my SGI (IRIX 6.5.1, IDL 5.1) I tried some of the
>> suggested code (immediatley after starting IDL up):
>>
>> device,decomposed=0
>> tvlct,[[255],[255],[0]],100
>> plot,randomu(10,10),color=100
>>
>> expecting the plot to be yellow, as advertised. Except no, _I_
>> get a medium-light shade of grey!
>>
>> Any suggestions?
>
> Oh, dear. I think this is one of those TrueColor/DirectColor
> tricks that SGI engineers like to play on people. This is
> a complication that I don't *even* want to know about.
>
> Try this. Type this:
>
> Device, Get_Visual_Name=thisName
> Print, thisName
>
> If thisName is "TrueColor" change it to "DirectColor":
>
> Device, DirectColor=24
>
> If thisName is "DirectColor" change it to "TrueColor":
>
> Device, TrueColor=24
>
> Do this *before* you open any graphics windows in IDL.
> Try the code above again. Different? The same?
>
> Please let us know. :-(
>
> Cheers,
>
> David
>
> Note: A copy of this article was e-mailed to the original poster.

Wow!

I really don't understand why this must be this much
complicated.
Originally whose fault is this for this complication
on different machines?

On my Linux, it appears that different XFree86 servers
have different color devices or whatever.
Admittedly, I don't know what is going on.

I simply want the color resources should not be
exhausted and be correctly displayed if I use more than
8-bit colors. Yet, IDL does not fire up without doing something
special at 16-bit colors.

Is this because there are variations such as
TrueColor and DirectColor on different Unix/X11
machines?

There must be a FAQ on this topic.
Can someone direct me to FAQ?

THanks

--
G. Hugh Song

PS: Please remove "Spamspoiler" when replying
Re: 16-bit colors in Linux (Re: 24 bit colors in IDL) [message #13548 is a reply to message #13547] Wed, 18 November 1998 00:00 Go to previous messageGo to next message
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
"G. Hugh SONG" <ghsong@\"Spamspoiler\"kjist.ac.kr> writes:

> I really don't understand why this must be this much
> complicated.

It's more fun this way.

> Originally whose fault is this for this complication
> on different machines?

I vote for Bill Gates, but I really don't know who
else is running.

> On my Linux, it appears that different XFree86 servers
> have different color devices or whatever.
> Admittedly, I don't know what is going on.

As I understand it, XFree86 servers only support 8
and 16 bit color. You *don't* want to use 16-bit color
because it is NOT supported at all by IDL. I'd shell
out the $25 or whatever and get a Linux driver from
someone who has written a driver for your particular
graphics card. You probably really want 24-bit color.

> I simply want the color resources should not be
> exhausted and be correctly displayed if I use more than
> 8-bit colors. Yet, IDL does not fire up without doing something
> special at 16-bit colors.

Yes. See above. :-)

> Is this because there are variations such as
> TrueColor and DirectColor on different Unix/X11
> machines?

No. It is because IDL does not support 16-bit color
on ANY platform, except accidentally on Windows.

> There must be a FAQ on this topic.
> Can someone direct me to FAQ?

Mike? Where are you when we need you? Here is the IDL
FAQ:

http://www.ivsoftware.com/idl_faq.html

Mike has been busy writing reviews for my book on Amazon.com,
so he may not have had time to get to this color thing yet. :-)

Cheers,

David

P.S. For those interested, the book has moved up to 85,022th
most popular book on the site. (Up from 172,345th.} Perhaps
soon they will actually take notice of me and place an
order with me. I've heard that several people have tried to
order from them, so far all without success. :-(

--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438
E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Progamming: http://www.dfanning.com/
Re: 16-bit colors in Linux [message #13665 is a reply to message #13547] Fri, 20 November 1998 00:00 Go to previous messageGo to next message
mallors is currently offline  mallors
Messages: 76
Registered: November 1997
Member
In article <7316c4$n6r$1@news.kjist.ac.kr>,
"G. Hugh SONG" <ghsong@\"Spamspoiler\"kjist.ac.kr> writes:
>
> BTW, using IDL /pv~Wave for scientific plotting works does not make
> much sense. But, I want full programmability. I don't need image
> manipulation. Is there any share-ware thing close to IDL/PV~Wave for
> this purpose? I have been thinking of getting out of the commercial
> program. Gnuplot cannot do 3-D(such as a sphere) as well as
> IDL/PV-wave. Can SCILAB do such a thing? If it does I am
> going to switch to SCILAB.
>

You might try yorick - it's an interpreted language,
and in some ways is quite like IDL. For example, the
following commands are valid yorick commands:

x = indgen(10)
print, x

There are significant differences too, though. For
example, yorick arrays are 1 indexed, like fortran :-(


ftp://icf.llnl.gov/pub/Yorick/yorick-ad.html



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
Robert S. Mallozzi 256-544-0887
Mail Code ES 84
Work: http://www.batse.msfc.nasa.gov/ Marshall Space Flight Center
Play: http://cspar.uah.edu/~mallozzir/ Huntsville, AL 35812
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
Re: 16-bit color [message #27928 is a reply to message #13547] Wed, 14 November 2001 02:57 Go to previous messageGo to next message
Nigel Wade is currently offline  Nigel Wade
Messages: 286
Registered: March 1998
Senior Member
James Kuyper wrote:

> Rick Towler wrote:
>>
>> You should be able to do this easily....
>>
>> If you are content with booting to the terminal and launching X manually
>> you
>> can specify what your desktop bit depth is. It has been a while since a
>> linux box sat on my desk (ahhh, those were the days....) but last time I
>> knew "startx -- -bpp 16" would get your 16bpp and as you can guess
>> "startx -- -bpp 24" would get you 24. If you are logged in and you need
>> to
>
> On my home machine, "startx -- -depth 24" is the appropriate command.
> The man page identifies "-bpp" as obsolete.
>
>> change it, you would have to quit your desktop manager, then restart X at
>> the appropriate bit depth. If your admin doesn't know how to change this
>> boot behavior, let me know. I may be able to dredge the name of the file
>> where you change the "boot to run level" setting out of my feeble brain.
>
> I've asked about this, but the sysadmins are unwilling to allow manual
> launching of X.
>

It's pretty hard to prevent.

Linux supports multiple displays on the same monitor in the same way that
it supports multiple consoles by using the virtual consoles.

You can start a second X server, running on display :1. You switch between
:0 and :1 with ctrl-alt-F7 and ctrl-alt-F8 (the second display uses the
next available virtual console by default). I'm not sure if you can have
more as I've only ever used :0 for 24bit and :1 for 8bit.

If does require that an XF86Config file is set up to handle multiple depths.

Unfortunately I've just upgraded to RedHat 7.2 and the XF86Config file I
had for multiple depths no longer works. I'll need to fiddle for a while to
get my IDL 8 bit display back again :-(.

--
-----------------------------------------------------------
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 2523568, Fax : +44 (0)116 2523555
Re: 16-bit color [message #27938 is a reply to message #13547] Tue, 13 November 2001 12:55 Go to previous messageGo to next message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
Rick Towler wrote:
>
> You should be able to do this easily....
>
> If you are content with booting to the terminal and launching X manually you
> can specify what your desktop bit depth is. It has been a while since a
> linux box sat on my desk (ahhh, those were the days....) but last time I
> knew "startx -- -bpp 16" would get your 16bpp and as you can guess
> "startx -- -bpp 24" would get you 24. If you are logged in and you need to

On my home machine, "startx -- -depth 24" is the appropriate command.
The man page identifies "-bpp" as obsolete.

> change it, you would have to quit your desktop manager, then restart X at
> the appropriate bit depth. If your admin doesn't know how to change this
> boot behavior, let me know. I may be able to dredge the name of the file
> where you change the "boot to run level" setting out of my feeble brain.

I've asked about this, but the sysadmins are unwilling to allow manual
launching of X.

> If you boot to XDM (or GDM or whatever your desktop flavor calls it) which
> is the graphical login manager, I don't think you can change the desktop bit

That's precisely my situation (with gdm).

--
James Kuyper
MODIS Level 1 Lead
Science Data Support Team
(301) 352-2150
Re: 16-bit color [message #27941 is a reply to message #13547] Tue, 13 November 2001 10:22 Go to previous messageGo to next message
Paul van Delst is currently offline  Paul van Delst
Messages: 364
Registered: March 1997
Senior Member
Rick Towler wrote:
>
> You should be able to do this easily....
>
> If you are content with booting to the terminal

some places (usually ones with lotsa big computey-type machines) don't allow you to do that
(here for example) so...

> and launching X manually you
> can specify what your desktop bit depth is.

thusly, can't do it. Wouldn't surprise me if GSFC was a place where the sysadmins rule this
option out. (I was talking to a sysadmin the other day that had a PC hacked into *while* she
was building linux on it! Man.)

paulv

--
Paul van Delst Religious and cultural
CIMSS @ NOAA/NCEP purity is a fundamentalist
Ph: (301)763-8000 x7274 fantasy
Fax:(301)763-8545 V.S.Naipaul
Re: 16-bit color [message #27942 is a reply to message #13547] Tue, 13 November 2001 09:30 Go to previous messageGo to next message
Rick Towler is currently offline  Rick Towler
Messages: 821
Registered: August 1998
Senior Member
You should be able to do this easily....

If you are content with booting to the terminal and launching X manually you
can specify what your desktop bit depth is. It has been a while since a
linux box sat on my desk (ahhh, those were the days....) but last time I
knew "startx -- -bpp 16" would get your 16bpp and as you can guess
"startx -- -bpp 24" would get you 24. If you are logged in and you need to
change it, you would have to quit your desktop manager, then restart X at
the appropriate bit depth. If your admin doesn't know how to change this
boot behavior, let me know. I may be able to dredge the name of the file
where you change the "boot to run level" setting out of my feeble brain.

If you boot to XDM (or GDM or whatever your desktop flavor calls it) which
is the graphical login manager, I don't think you can change the desktop bit
depth easily. But then again like I said, it has been a while since I have
had a linux box on my desk. Chek www.freshmeat.net for a tool that might do
this.

-Rick


"James Kuyper" <kuyper@gscmail.gsfc.nasa.gov> wrote in message
news:3BF1411E.59DB9CEA@gscmail.gsfc.nasa.gov...
> David Fanning wrote:
>>
>> James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes:
>>
>>> I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my
>>> system can be configured to run in 24bpp mode, but that configuration
>>> seems to be controlled by the sysadmins, and they've been slow to
>>> respond to my requests.
>>
>> Have you offered your first-born child? That
>> sometimes works.
>
> Unfortunately, I don't have one to offer. ;-)
>
> Luckily, it wasn't necessary; they've promised to switch it to 24-bit
> mode sometime this week. However, I've also asked for the ability to
> switch configurations myself, without their intervention - they didn't
> respond to that part of the request.
>
> --
> James Kuyper
> MODIS Level 1 Lead
> Science Data Support Team
> (301) 352-2150
Re: 16-bit color [message #27949 is a reply to message #13547] Tue, 13 November 2001 08:51 Go to previous messageGo to next message
Pavel A. Romashkin is currently offline  Pavel A. Romashkin
Messages: 531
Registered: November 2000
Senior Member
James Kuyper wrote:
>
> David Fanning wrote:
>>
>> Have you offered your first-born child? That
>> sometimes works.
>
> Unfortunately, I don't have one to offer. ;-)

You're welcome to borrow mine. I guarantee the sysadmin will do what you
need today, in 2-20 min. They will also pay you to take him back. The
only problem is, the UN may disapprove, since the method is inhumane :)

Cheers,
Pavel
Re: 16-bit color [message #27951 is a reply to message #13547] Tue, 13 November 2001 07:49 Go to previous messageGo to next message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
David Fanning wrote:
>
> James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes:
>
>> I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my
>> system can be configured to run in 24bpp mode, but that configuration
>> seems to be controlled by the sysadmins, and they've been slow to
>> respond to my requests.
>
> Have you offered your first-born child? That
> sometimes works.

Unfortunately, I don't have one to offer. ;-)

Luckily, it wasn't necessary; they've promised to switch it to 24-bit
mode sometime this week. However, I've also asked for the ability to
switch configurations myself, without their intervention - they didn't
respond to that part of the request.

--
James Kuyper
MODIS Level 1 Lead
Science Data Support Team
(301) 352-2150
Re: 16-bit color [message #27958 is a reply to message #13547] Mon, 12 November 2001 14:03 Go to previous messageGo to next message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes:

> I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my
> system can be configured to run in 24bpp mode, but that configuration
> seems to be controlled by the sysadmins, and they've been slow to
> respond to my requests.

Have you offered your first-born child? That
sometimes works.

Cheers,

David

--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
Re: 16-bit color [message #27961 is a reply to message #13547] Mon, 12 November 2001 13:33 Go to previous messageGo to next message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
Rick Towler wrote:
>
> Unless you are using IDL 5.5 16 bit displays are not supported. AFAIK, only
> 8 and 24 bit displays are supported on IDL 5.4 and below. My guess is that
> your previous workstation sported a 24 bpp display? Does your display
> adapter support 24 bpp? Maybe you can add a few lines to your XFree config
> file to include a 24bpp mode.

I'm using IDL 5.4.1. My previous display was a 24 bpp one. I think my
system can be configured to run in 24bpp mode, but that configuration
seems to be controlled by the sysadmins, and they've been slow to
respond to my requests.

--
James Kuyper
MODIS Level 1 Lead
Science Data Support Team
(301) 352-2150
Re: 16-bit color [message #27963 is a reply to message #13547] Mon, 12 November 2001 11:36 Go to previous messageGo to next message
Rick Towler is currently offline  Rick Towler
Messages: 821
Registered: August 1998
Senior Member
Unless you are using IDL 5.5 16 bit displays are not supported. AFAIK, only
8 and 24 bit displays are supported on IDL 5.4 and below. My guess is that
your previous workstation sported a 24 bpp display? Does your display
adapter support 24 bpp? Maybe you can add a few lines to your XFree config
file to include a 24bpp mode.

5.5 has improved support for "other" bit depths like 16 and 32.

-Rick


"James Kuyper" <kuyper@gscmail.gsfc.nasa.gov> wrote in message
news:3BF00F3F.831BD164@gscmail.gsfc.nasa.gov...
> I would like to display RGB images, with, for instance higher values for
> the Red component causing redder colors, and higher values of the blue
> component making them bluer. I used to be able to do that pretty easily,
> using the
>
> tv,image,/true
>
> However, since I've been moved to a Linux workstation, it doesn't work.
> I could provide detailed symptoms if you want, but it's obviously a
> configuration problem, so maybe the easiest way is to ask how I need to
> configure my IDL session to display these things properly. Attached is a
> copy of the xdpyinfo output for my system. What device commands should I
> use?
>
> --
> James Kuyper
> MODIS Level 1 Lead
> Science Data Support Team
> (301) 352-2150


------------------------------------------------------------ ----------------
----


> name of display: :0.0
> version number: 11.0
> vendor string: The XFree86 Project, Inc
> vendor release number: 3360
> maximum request size: 4194300 bytes
> motion buffer size: 256
> bitmap unit, bit order, padding: 32, LSBFirst, 32
> image byte order: LSBFirst
> number of supported pixmap formats: 2
> supported pixmap formats:
> depth 1, bits_per_pixel 1, scanline_pad 32
> depth 16, bits_per_pixel 16, scanline_pad 32
> keycode range: minimum 8, maximum 134
> focus: window 0x340000e, revert to PointerRoot
> number of extensions: 19
> BIG-REQUESTS
> DOUBLE-BUFFER
> DPMS
> LBX
> MIT-SCREEN-SAVER
> MIT-SHM
> MIT-SUNDRY-NONSTANDARD
> RECORD
> SECURITY
> SHAPE
> SYNC
> XC-APPGROUP
> XC-MISC
> XFree86-DGA
> XFree86-Misc
> XFree86-VidModeExtension
> XInputExtension
> XKEYBOARD
> XTEST
> default screen number: 0
> number of screens: 1
>
> screen #0:
> dimensions: 1152x864 pixels (390x293 millimeters)
> resolution: 75x75 dots per inch
> depths (1): 16
> root window id: 0x26
> depth of root window: 16 planes
> number of colormaps: minimum 1, maximum 1
> default colormap: 0x23
> default number of colormap cells: 64
> preallocated pixels: black 0, white 65535
> options: backing-store YES, save-unders YES
> largest cursor: 64x64
> current input event mask: 0xf8603f
> KeyPressMask KeyReleaseMask ButtonPressMask
> ButtonReleaseMask EnterWindowMask LeaveWindowMask
> ButtonMotionMask KeymapStateMask
SubstructureNotifyMask
> SubstructureRedirectMask FocusChangeMask PropertyChangeMask
> ColormapChangeMask
> number of visuals: 1
> default visual id: 0x22
> visual:
> visual id: 0x22
> class: TrueColor
> depth: 16 planes
> available colormap entries: 64 per subfield
> red, green, blue masks: 0xf800, 0x7e0, 0x1f
> significant bits in color specification: 6 bits
>
Re: 16-bit color [message #27974 is a reply to message #27958] Thu, 15 November 2001 05:18 Go to previous messageGo to next message
Logan Lindquist is currently offline  Logan Lindquist
Messages: 50
Registered: October 2001
Member
"David Fanning" <david@dfanning.com> wrote in message
news:MPG.1659f5118186501f989767@news.frii.com...
> James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes:


Do they teach sysadmins to make the process of getting their help to be
difficult as possible in order to keep the number of questions to a minimum?
Maybe if they had a task sheet that everyone could see and sign up for help,
we would be a lot less likely to think they are a bunch of power hungry lazy
ass-holes.

:)
Re: 16-bit color [message #28014 is a reply to message #27928] Wed, 14 November 2001 09:09 Go to previous messageGo to next message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
Nigel Wade wrote:
>
> James Kuyper wrote:
>
>> Rick Towler wrote:
...
>> I've asked about this, but the sysadmins are unwilling to allow manual
>> launching of X.
>>
>
> It's pretty hard to prevent.
>
> Linux supports multiple displays on the same monitor in the same way that
> it supports multiple consoles by using the virtual consoles.
>
> You can start a second X server, running on display :1. You switch between
> :0 and :1 with ctrl-alt-F7 and ctrl-alt-F8 (the second display uses the
> next available virtual console by default). I'm not sure if you can have
> more as I've only ever used :0 for 24bit and :1 for 8bit.
>
> If does require that an XF86Config file is set up to handle multiple depths.

The one for my machine at work isn't set up for multiple depths.
However, I'll try that on my home machine. I never really understood how
:1 works, more precisely, I was unaware that you could get to it by
switching virtual consoles. Thanks!

--
James Kuyper
MODIS Level 1 Lead
Science Data Support Team
(301) 352-2150
Re: 16-bit color [message #28064 is a reply to message #27974] Thu, 15 November 2001 06:57 Go to previous message
Paul van Delst is currently offline  Paul van Delst
Messages: 364
Registered: March 1997
Senior Member
Logan Lindquist wrote:
>
> Do they teach sysadmins to make the process of getting their help to be
> difficult as possible in order to keep the number of questions to a minimum?
> Maybe if they had a task sheet that everyone could see and sign up for help,
> we would be a lot less likely to think they are a bunch of power hungry lazy
> ass-holes.

My my. I think folks using computers with that sort of attitude get *special* attention from
sysadmins ;o\ My approach has been to learn something about the system(s) I'm using so that
when I do ask sysadmins a question, it's an intelligent one. And I'm not being flippant with
the "intelligent" remark - a lot of times it's hard to pose the question so that it targets the
problem rather than it's symptoms.

If your above post is indicative of the relationship/opinions you have of your local sysadmin,
I think you should supply them with tasty pastries every Friday morning for a month in apology.
:o)

paulv

--
Paul van Delst Religious and cultural
CIMSS @ NOAA/NCEP purity is a fundamentalist
Ph: (301)763-8000 x7274 fantasy
Fax:(301)763-8545 V.S.Naipaul
Re: 16-bit color [message #28068 is a reply to message #27974] Thu, 15 November 2001 06:33 Go to previous message
Nigel Wade is currently offline  Nigel Wade
Messages: 286
Registered: March 1998
Senior Member
Logan Lindquist wrote:

> "David Fanning" <david@dfanning.com> wrote in message
> news:MPG.1659f5118186501f989767@news.frii.com...
>> James Kuyper (kuyper@gscmail.gsfc.nasa.gov) writes:
>
>
> Do they teach sysadmins to make the process of getting their help to be
> difficult as possible in order to keep the number of questions to a
> minimum?

No, we learn that through having to solve users self-inflicted problems.

> Maybe if they had a task sheet that everyone could see and sign
> up for help, we would be a lot less likely to think they are a bunch of
> power hungry lazy ass-holes.
>
> :)

I think your sysadmin needs to introduce a new policy of expiring passwords
each week. That ought to help. ;-)

--
-----------------------------------------------------------
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 2523568, Fax : +44 (0)116 2523555
Re: 16-bit color [message #28070 is a reply to message #28014] Thu, 15 November 2001 06:10 Go to previous message
Nigel Wade is currently offline  Nigel Wade
Messages: 286
Registered: March 1998
Senior Member
James Kuyper wrote:

> Nigel Wade wrote:
>>
>> James Kuyper wrote:
>>
>>> Rick Towler wrote:
> ...
>>> I've asked about this, but the sysadmins are unwilling to allow manual
>>> launching of X.
>>>
>>
>> It's pretty hard to prevent.
>>
>> Linux supports multiple displays on the same monitor in the same way that
>> it supports multiple consoles by using the virtual consoles.
>>
>> You can start a second X server, running on display :1. You switch
>> between
>> :0 and :1 with ctrl-alt-F7 and ctrl-alt-F8 (the second display uses the
>> next available virtual console by default). I'm not sure if you can have
>> more as I've only ever used :0 for 24bit and :1 for 8bit.
>>
>> If does require that an XF86Config file is set up to handle multiple
>> depths.
>
> The one for my machine at work isn't set up for multiple depths.
> However, I'll try that on my home machine. I never really understood how
> :1 works, more precisely, I was unaware that you could get to it by
> switching virtual consoles. Thanks!
>

I've managed to get an secondary X server running with RH7.2. Unfortunately
it refuses all connections, even from the window manager. Not very useful.

The setup which used to work with vn. 4.0.1 of XFree86 no longer works with
the 4.1 version supplied with RH7.2. Whether that's a new "feature" or a
bug or a problem with the RH supplied rpms I don't know at the moment.

I had thought that it was possible for a user to run a second X server and
specify their own XF86onfig file, but it appears that the security of the X
server won't allow that. So you will need to get the cooperation of your
sys admin to have multiple screen depths.

--
-----------------------------------------------------------
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 2523568, Fax : +44 (0)116 2523555
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: CALL_EXTERNAL simple problem ?
Next Topic: 16-bit color

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:16:59 PDT 2025

Total time taken to generate the page: 0.00890 seconds