changing color depth in XFree86

changing color depth in XFree86

[Barry Gamblin]

I'm using Redhat 7.3 (kernel 2.4.18-19.7.x). I'm using the gnome 
desktop. I have a need to allow a user to change back and forth between 
24 bit color depth and 8 bit color depth. The XFree86 man page says I 
can use Ctl-Alt-Keypad-plus to go to the next mode in the config file. 
For me it is just changing the resolution, but not the color depth.

Here is my XF86Config-4 file:
-----
# XFree86 4.2.0 configuration generated by Xconfigurator 4.10.7

Section "ServerLayout"
        Identifier "XFree86 Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

# Red Hat Linux 6.0 and later use the xfs font server for improved
# interactive performance

Section "Files"
        FontPath "unix/:7100"
EndSection

# Module loading section

Section "Module"
        Load  "dbe"             # Double-buffering
#       Load  "GLcore"          # OpenGL support
#       Load  "dri"             # Direct rendering infrastructure
        Load  "glx"             # OpenGL X protocol interface
        Load  "extmod"          # Misc. required extensions
        Load  "v4l"             # Video4Linux
        # Load  "record"        # X event recorder
        # You only need the following two modules if you do not use xfs.
        # Load  "freetype"       # TrueType font handler
        # Load  "type1"         # Adobe Type 1 font handler
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbLayout" "us"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Device" "/dev/mouse"
        Option      "Protocol" "PS/2"
        Option      "Emulate3Buttons" "off"
        Option      "ZAxisMapping" "4 5"
EndSection

Section "Monitor"
        Identifier "HP P1130"
        VendorName "Unknown"
        ModelName  "Unknown"
        HorizSync 30 - 130
        VertRefresh 48 - 170
        Option "dpms"
EndSection

Section "Device"
        Identifier "NVIDIA GeForce 2 MX (generic)"
        Driver "nvidia"
        BoardName "Unknown"
EndSection

Section "Device"
        Identifier "Linux Frame Buffer"
        Driver "fbdev"
        BoardName "Unknown"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device "NVIDIA GeForce 2 MX (generic)"
        Monitor "HP P1130"
        DefaultDepth 24
        Subsection "Display"
                Depth 24
                Modes "1600x1200" "1280x1024"
        EndSubSection
        Subsection "Display"
                Depth 8
                Modes "1600x1200" "1280x1024"
        EndSubSection
EndSection

Section "DRI"
        Mode 0666
EndSection
-----

Could someone help me figure out how to make this work?

Thanks, Barry

Barry S. Gamblin, UNIX Administrator III, bgamblin@ucar.edu
High Altitude Observatory - National Center for Atmospheric Research
P.O.Box 3000, Boulder CO 80307-3000
voice - 303-497-1509  fax - 303-497-1589

Re: changing color depth in XFree86

[Glynn Clements]

Barry Gamblin wrote:

> I'm using Redhat 7.3 (kernel 2.4.18-19.7.x). I'm using the gnome 
> desktop. I have a need to allow a user to change back and forth between 
> 24 bit color depth and 8 bit color depth. The XFree86 man page says I 
> can use Ctl-Alt-Keypad-plus to go to the next mode in the config file. 
> For me it is just changing the resolution, but not the color depth.

You can't change the colour depth of a running X server.

OTOH, you can run multiple X servers simultaneously, e.g.

	startx -- :1 -depth 8

BTW, you can't change the framebuffer resolution (i.e. the size of the
root window) either; the resolution switching only affects the
displayed resolution (you end up displaying a scrolling window onto
the framebuffer).

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: changing color depth in XFree86

[Stewart]

Glynn Clements wrote:

> You can't change the colour depth of a running X server.
[...]
> BTW, you can't change the framebuffer resolution (i.e. the size of the
> root window) either; the resolution switching only affects the
> displayed resolution (you end up displaying a scrolling window onto
> the framebuffer).

This used to be true, but as of XFree86 4.3.0 and the xrandr utility you 
can (finally!) change resolution and colour depth.

Frontends are forthcoming from your friendly neighborhood window|desktop 
management centres.

Upgrade and behold the goodness of a drop-shadowed mouse cursor (worth 
the price of admission, IMHO. ;> )

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."

Re: changing color depth in XFree86

[Glynn Clements]

Stewart wrote:

> > You can't change the colour depth of a running X server.
> [...]
> > BTW, you can't change the framebuffer resolution (i.e. the size of the
> > root window) either; the resolution switching only affects the
> > displayed resolution (you end up displaying a scrolling window onto
> > the framebuffer).
> 
> This used to be true, but as of XFree86 4.3.0 and the xrandr utility you 
> can (finally!) change resolution and colour depth.

The RandR documentation (doc/specs/Randr/protocol.txt) says:

: RandR as implemented and integrated into the XFree86 server differs in
: one substantial fashion from the design discussed in that paper: that
: is, RandR 1.0 does not implement the depth switching described in that
: document, and the support described for that in the protocol in that
: document and in the XFree86 implementationhas been removed from the
: protocol described here, as it has been overtaken by events.
: 
: These events include:
:       o Modern toolkits (in this case, GTK+ 2.x) have progressed to the point
:         of implementing migration between screens of arbitrary depths
:       o The continued advance of Moore's law has made limited amounts of VRAM
:         less of an issue, reducing the pressure to implement depth switching
: 	on laptops or desktop systems
:       o The continued decline of legacy toolkits whose design would have
:         required depth switching to support migration
:       o The lack of depth switchin implementation experience in the 
:         intervening time, due to events beyond our control
: 
: Additionally, the requirement to support depth switching might
: complicate other re-engineering of the device independent part of the
: X server that is currently being contemplated.
: 	
: Rather than further delaying RandR's widespread deployment for a
: feature long wanted by the community (resizing of screens,
: particularly on laptops), or the deployment of a protocol design that
: might be flawed due to lack of implementation experience, we decided
: to remove depth switching from the protocol.  It may be implementated
: at a later time if resources and interests permit as a revision to the
: protocol described here, which will remain a stable base for
: applications.  The protocol described here has been implemented in the
: main XFree86 server, and more fully in the TinyX implementation in the
: XFree86 distribution, which fully implements resizing, rotation and
: reflection.

The 4.3.0 release note says:

: Support for the RandR extension has been partially integrated into
: the XFree86 server, providing support for resizing the root window at
: run-time.

The problem with changing the depth is that the depth is guaranteed to
remain constant. That has been part of the interface since X'
inception, and no amount of code can change that.

Once an application queries the screen depth, it can safely assume
that the information remains valid for its lifetime. Changing the
depth of a running X server would cause existing applications to
either stop functioning correctly or crash outright.

Consequently, this feature can't be implemented with resorting to
historical revisionism. Unfortunately, given their past, I'm all too
willing to believe that XFree86 Inc would do this; it's about time
that they changed the name of their product so that it doesn't get
confused with a real X11 implementation.

Actually, the same is true of resizing the root window; however, fewer
applications actually care about that and, for those which do, any
failures are likely to be less critical.

> Frontends are forthcoming from your friendly neighborhood window|desktop 
> management centres.
> 
> Upgrade and behold the goodness of a drop-shadowed mouse cursor (worth 
> the price of admission, IMHO. ;> )

I'll choose compatibility over gimmicks any day.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: changing color depth in XFree86

[Stewart]

Glynn Clements wrote:

> : Support for the RandR extension has been partially integrated into
> : the XFree86 server, providing support for resizing the root window at
> : run-time.
> 
> The problem with changing the depth is that the depth is guaranteed to
> remain constant. That has been part of the interface since X'
> inception, and no amount of code can change that.
> 
> Once an application queries the screen depth, it can safely assume
> that the information remains valid for its lifetime. Changing the
> depth of a running X server would cause existing applications to
> either stop functioning correctly or crash outright.

Then the applications will have to remove their legacy code and catch up 
with the needs of the users, rather than the programmers.

Moreover, if an application were to crash because it finds itself 
outside of the bounds of the screen, that application was poorly written 
to begin with. There's just no excuse for being *that* dependant on 
geometry with no protections in place.

Further, if and when the screen is resized, it's up to the 
window|desktop manager to align the windows according to a pre-defined 
set of guidelines (static or configurable), much like Windows Explorer 
and the Mac GUI.

For the sake of productivity, I should be able to seamlessly en/disable 
any of my monitors, alter any of their resolutions and/or colour depth, 
reposition their virtual layout, all without restarting my entire 
graphical environment and having to play with scripting, command-line 
switches and convoluted config files.

Don't get me wrong, I'm a long-time Linux admin and I find that textual 
config files are some of the most powerful means of managing daemons and 
system components, but realistically there has to be a front-end method 
that will allow me to perform any/all of these actions withOUT 
interrupting my train of thought.

>>Frontends are forthcoming from your friendly neighborhood window|desktop 
>>management centres.
>>
>>Upgrade and behold the goodness of a drop-shadowed mouse cursor (worth 
>>the price of admission, IMHO. ;> )
> 
> I'll choose compatibility over gimmicks any day.

"Gimmicks"? Changing resolution on the fly has come to be expected from 
any modern desktop environment. It's taken far too long, IMO, for 
XFree86.Org to catch up and implement such functionality in their 
server. I only hope they don't leave the job half complete.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."

Rant [Was: Re: changing color depth in XFree86]

[Glynn Clements]

Stewart wrote:

> > : Support for the RandR extension has been partially integrated into
> > : the XFree86 server, providing support for resizing the root window at
> > : run-time.
> > 
> > The problem with changing the depth is that the depth is guaranteed to
> > remain constant. That has been part of the interface since X'
> > inception, and no amount of code can change that.
> > 
> > Once an application queries the screen depth, it can safely assume
> > that the information remains valid for its lifetime. Changing the
> > depth of a running X server would cause existing applications to
> > either stop functioning correctly or crash outright.
> 
> Then the applications will have to remove their legacy code and catch up 
> with the needs of the users, rather than the programmers.

Oh right; we'll just re-write all of the existing X applications and
libraries. No problem.

> Moreover, if an application were to crash because it finds itself 
> outside of the bounds of the screen, that application was poorly written 
> to begin with. There's just no excuse for being *that* dependant on 
> geometry with no protections in place.
> 
> Further, if and when the screen is resized, it's up to the 
> window|desktop manager to align the windows according to a pre-defined 
> set of guidelines (static or configurable), much like Windows Explorer 
> and the Mac GUI.

You appear to have overlooked the fact that the two paragraphs which
you quote were referring to the *depth*; and to have also overlooked
this part of my previous message:

> Actually, the same is true of resizing the root window; however, fewer
> applications actually care about that and, for those which do, any
> failures are likely to be less critical.

Few applications (except window managers) are concerned with the
screen dimensions, and most of those which are will exhibit relatively
minor faults if the dimensions do change. The real problem is changing
the *depth*.

> For the sake of productivity, I should be able to seamlessly en/disable 
> any of my monitors, alter any of their resolutions and/or colour depth, 
> reposition their virtual layout, all without restarting my entire 
> graphical environment and having to play with scripting, command-line 
> switches and convoluted config files.

Sure, it would be nice, but it would require that applications had
been written to allow for that possibility, and they haven't been.

The amount of work involved in allowing for arbitrary changes in
colour depth is non-trivial. Any client-side data or server-side
objects (e.g. Pixmaps) which were generated for a particular depth
would have to be regenerated for the new depth. E.g. if you try to use
a Pixmap with the wrong depth, you get a BadMatch error (which is
fatal, like most X errors).

This isn't a simple "extension" (like e.g. GLX or shaped windows)
which is irrelevant to applications which don't wish to use it; every
application would have to be updated to allow for it.

> Don't get me wrong, I'm a long-time Linux admin and I find that textual 
> config files are some of the most powerful means of managing daemons and 
> system components, but realistically there has to be a front-end method 
> that will allow me to perform any/all of these actions withOUT 
> interrupting my train of thought.

I'm a long-time Linux user/admin/programmer who has progressively
become more sceptical of both Linux and free software generally;
primarily because of a growing tendency to sacrifice important factors
such as compatibility (both with previous versions and with real
Unix/X11 systems) in favour of non-critical features and gimmicks.

Every time that I hear the Slashdot crowd enthusing over the fact that
such-and-such now has an animated alpha-translucent drop-shadowed OK
button I just wonder which rational property was sacrificed for that
piece of nonsense. Performance? Reliability? Portability? Memory
consumption? "Who cares? - we have animated alpha-translucent
drop-shadowed OK buttons, yay!"

> > > Frontends are forthcoming from your friendly neighborhood window|desktop 
> > > management centres.
> > > 
> > > Upgrade and behold the goodness of a drop-shadowed mouse cursor (worth 
> > > the price of admission, IMHO. ;> )
> > 
> > I'll choose compatibility over gimmicks any day.
> 
> "Gimmicks"?

Note: I was specifically referring to the "drop-shadowed mouse cursor"
comment; to me, that's definitely a gimmick, and wouldn't be worth the
time it takes to type "rpm -U ...".

> Changing resolution on the fly has come to be expected from 
> any modern desktop environment.

That sounds like "Windows has it, therefore we should".

Well, plenty of software had to be updated when mode-switching was
added to Windows. Ditto for the way that they added anti-aliased font
support (by changing the semantics of the existing text rendering
functions rather than adding new ones).

In Microsoft's case, there's a business case for deliberately
obsoleting software and forcing your customers to buy upgrades. The
same is true to a lesser extent for other developers who use a
"publication" model.

For bespoke development (which is a much more common model on Unix,
particularly "big iron" Unix), the opposite is true. If the underlying
system changes, upgrading bespoke software is often prohibitively
expensive. The net result is that companies which rely upon bespoke
software tend to strenuously resist upgrades.

Needless to say, the only reason that I'm looking at upgrading my
current RedHat 6.2 installation is the fact that RedHat have stopped
releasing fixes for it; otherwise, I'd probably still be using it five
years hence. The lack of drop-shadowed mouse cursors doesn't bother me
in the slightest.

> It's taken far too long, IMO, for XFree86.Org to catch up and
> implement such functionality in their server.

When it comes to breaking compatibility, the longer they leave it the
better.

> I only hope they don't leave the job half complete.

Well, they did note:

:       o The continued advance of Moore's law has made limited amounts of VRAM
:         less of an issue, reducing the pressure to implement depth switching
: 	on laptops or desktop systems

I only hope they decide that this is one thing that they don't
actually need to break.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: Rant [Was: Re: changing color depth in XFree86]

[Bill Sneed]

Glynn Clements wrote:
> 

> > "Gimmicks"?
> 
> Note: I was specifically referring to the "drop-shadowed mouse cursor"
> comment; to me, that's definitely a gimmick, and wouldn't be worth the
> time it takes to type "rpm -U ...".
> 

well said & about time someone has....b....

Re: Rant [Was: Re: changing color depth in XFree86]

[Stewart]

Glynn Clements wrote:

>>Then the applications will have to remove their legacy code and catch up 
>>with the needs of the users, rather than the programmers.
> 
> Oh right; we'll just re-write all of the existing X applications and
> libraries. No problem.

Melodrama isn't going to help your case, I dare say.

>>Actually, the same is true of resizing the root window; however, fewer
>>applications actually care about that and, for those which do, any
>>failures are likely to be less critical.
> 
> Few applications (except window managers) are concerned with the
> screen dimensions, and most of those which are will exhibit relatively
> minor faults if the dimensions do change. The real problem is changing
> the *depth*.

So it's not going to be done because it's "hard"?

Perhaps what I've been saying all along is true; OSS really isn't ready 
for prime-time desktop use.

If you're going to claim that the world's most revolutionary programming 
model is fundamentally flawed because it won't tackle "hard" problems - 
problems which are already overcome by all of their closed-source 
bretheren - then just come out and say it.

Or are you going to find a better reason why this is a bad idea?

> I'm a long-time Linux user/admin/programmer who has progressively
> become more sceptical of both Linux and free software generally;
> primarily because of a growing tendency to sacrifice important factors
> such as compatibility (both with previous versions and with real
> Unix/X11 systems) in favour of non-critical features and gimmicks.
> 
> Every time that I hear the Slashdot crowd enthusing over the fact that
[...]

And every time I hear a legacy supporter throwing the "Slashdot crowd" 
out as if it were a valid argument, I roll my eyes.

> such-and-such now has an animated alpha-translucent drop-shadowed OK
> button I just wonder which rational property was sacrificed for that
> piece of nonsense. Performance? Reliability? Portability? Memory
> consumption? "Who cares? - we have animated alpha-translucent
> drop-shadowed OK buttons, yay!"

We're talking about the X server, not KDE/GNOME. Focus.

>>Changing resolution on the fly has come to be expected from 
>>any modern desktop environment.
> 
> That sounds like "Windows has it, therefore we should".

No, actually, it means that these are desired (nay, required) features 
for many settings, and we don't have it.

>>It's taken far too long, IMO, for XFree86.Org to catch up and
>>implement such functionality in their server.
> 
> When it comes to breaking compatibility, the longer they leave it the
> better.

Compatability at the cost of being ten years obsolete, merely for the 
sake of compatability, is ridiculous.

Re: changing color depth in XFree86

[terry white]

on "4-19-2003" "Stewart" writ:

: Then the applications will have to remove their legacy code and catch up
: with the needs of the users, rather than the programmers.

... well pooh, pooh, pee doo:

    you make a wonderful case for the bane of poor programming.

    however , i got lost when you equated 'color-depth' and geometry.


: Changing resolution on the fly

    what, CTRL-ALT-(+|-) doesn't work for you ...



-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: changing color depth in XFree86

[Stewart]

terry white wrote:

>     you make a wonderful case for the bane of poor programming.
> 
>     however , i got lost when you equated 'color-depth' and geometry.

"equated" how? The fact that the ability to change either or both of 
them on the fly is desireable?

> : Changing resolution on the fly
> 
>     what, CTRL-ALT-(+|-) doesn't work for you ...

That creates a small window of a large surface, it doesn't change the 
resolution of my screen area.

Re: changing color depth in XFree86

[terry white]

on "4-20-2003" "Stewart" writ:

: >     however , i got lost when you equated 'color-depth' and geometry.

: "equated" how? The fact that the ability to change either or both of
: them on the fly is desireable?

... no, i think it was the transition from a discussion on 'color-depth'
to 'resolution' in a way that indicated you didn't appreciate the
distinction.


: > : Changing resolution on the fly

: >     what, CTRL-ALT-(+|-) doesn't work for you ...

: That creates a small window of a large surface, it doesn't change the
: resolution of my screen area.

    if that is in 'fact' the case, you have a hardware problem, and your
complaints without substance.  clearly, it's an error to 'judge' all
that's "X" based on a failed installation.  let me suggest the
handy-dandy 'Hardware-HOWTO' ...

-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: changing color depth in XFree86

[Stewart]

terry white wrote:

> : "equated" how? The fact that the ability to change either or both of
> : them on the fly is desireable?
> 
> ... no, i think it was the transition from a discussion on 'color-depth'
> to 'resolution' in a way that indicated you didn't appreciate the
> distinction.

I've no idea what you're talking about, I'm afraid. You'll have to be a 
little more clear.

> : >     what, CTRL-ALT-(+|-) doesn't work for you ...
> 
> : That creates a small window of a large surface, it doesn't change the
> : resolution of my screen area.
> 
>     if that is in 'fact' the case, you have a hardware problem, and your
> complaints without substance.  clearly, it's an error to 'judge' all
> that's "X" based on a failed installation.  let me suggest the
> handy-dandy 'Hardware-HOWTO' ...

Ctrl-Alt-(+|-) creates a "ViewPort" of a larger screen area. It does not 
resize the desktop area, and in fact requires that one scroll the screen 
with one's mouse. This is by design. My hardware works fine; please 
don't patronize me. If you don't understand what's being discussed, 
please refrain from responding.

Re: changing color depth in XFree86

[terry white]

on "4-20-2003" "Stewart" writ:

: I've no idea what you're talking about, I'm afraid. You'll have to be a
: little more clear.

... so far, two of us have noticed, AND commented on the above issue.
now i lay no claim to being understandable, HOWEVER, glenn is. just how
many times do you think it will take for clarity to show up.


: "ViewPort" of a larger screen area.

    that is where you understanding fails.  a 'larger screen area' does
not exist.  what does, is memory dedicated to video rendering.  what you
see displayed is a window into that asset.  resolution is defined in
terms of pixels in the H and V planes.  color-depth adds a third
dimension to that matrix.

    the 'screen area' is what you see displayed.


: It does not resize the desktop area, and in fact requires that one
: scroll the screen with one's mouse.

    those two things are mutually exclusive.


    "If you don't understand what's being discussed, please refrain from
    responding."

    i make it a point not to, however, that is defined by 'my'
understanding of the material under discussion, and not your opinion
about that.
    it seems to me, this whole thing less about you 'getting' it, than it
is bitching about 'everything' "everyone" else isn't doing with
regard to X.  the inability to appreciate the implications of
color depth, or 'rewriting' the code, speaks for itself.

    finally.  the opportunity to engage in this kind of thing, from time
to time, a 'nice' respite from the mundane 'problem solving' and
'learning' that is so much the norm.  now, you add someone with little
obvious command of the material at hand, the desire to defend that
position, add a pinch of indignation, and you've got entertainment at its
finest.  all i can say, is 'thanks' ...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: changing color depth in XFree86

[Stewart]

terry white wrote:

>     it seems to me, this whole thing less about you 'getting' it, than it
> is bitching about 'everything' "everyone" else isn't doing with
> regard to X.  the inability to appreciate the implications of
> color depth, or 'rewriting' the code, speaks for itself.

I fully understand the implications. However, Linux, XFree86, et al. 
(the various poster boys for OSS and the software revolution in general) 
are supposed to be advanced, innovative coding models that are ahead of, 
rather than waiting several years, through periods of bitching, moaning, 
and innumerable code forks before somebody gets around to implementing a 
feature that users have come to expect from their systems for well over 
a decade. This core functionality can often take as long as a year to 
mature, at which point it is lauded as some sort of accomplishment.

XFree86 is in the process of being forked;

http://www.pclinuxonline.com/modules.php?name=News&file=article&sid=4717&mode=nested&order=0&thold=0

Why is it being forked? I'll let Mr. Packard explain it for me;

http://lwn.net/Articles/27673/

Note the paragraph, right at the outset, that reads "Designed in 1987, 
X11 hasn't seen any significant architectural work in well over a 
decade, and it really shows."

Since 1987, computer power has increased exponentially over and over 
again, and all that's changed in XFree86 is to become more bloated and 
require, yet not take advantage of newer hardware implementations.

This;

http://www.advogato.org/person/mharris/diary.html?start=5

is a good indication of the current state of affairs in desktop usage. 
When making a purchasing decision for a video card, a typical user would 
compare the features, memory, texture mapping capabilities, multi 
monitor support, etc.

When a Linux user makes a purchasing decision, they have to perform 
extensive research (mostly empirical) to figure out whether or not their 
system will remain *STABLE* for more than five minutes at a time if they 
enable so much as a portion of the card's capabilities. Even with 
vendor-supported drivers direct from the manufacturer, modern ATI cards 
are not to be considered "Penguin Friendly".

What about the other big alternative - nVidia? What happens when you 
speak to a developer about hard locks of your system? "Are you using an 
nVidia? Is the driver loaded?"

What does that say about the current state of affairs of the desktop in 
OSS systems? It says that we'll not only settle, but fight for mediocrity.

The arguments put forth by Glynn and yourself are only serving to 
further this notion.

> now, you add someone with little
> obvious command of the material at hand, the desire to defend that
> position, add a pinch of indignation, and you've got entertainment at its
> finest.  all i can say, is 'thanks' ...

That's funny, because all I can see are two people who have no apparent 
knowledge of the current needs/demands of computer users, or the 
advances in desktop environments that are sorely lacking from XFree86 
trying to tell me why it's infeasable to implement something that's 
second nature to every other major desktop platform in existance.

You stick to your legacy X11 system, I'll continue to champion for 
positive change. We'll see where XFree86 winds up in 3-5 years.

Meanwhile, if you're going to continue to stroke your respective egos 
and contribute nothing substantive, do us all a favour and save yourself 
from my twit filter.

Re: changing color depth in XFree86

[terry white]

on "4-21-2003" "Stewart" writ:

... first last:

    "do us all a favour and save yourself from my twit filter"

    am i to infer from that, that YOU are speaking for the entire list.
or is 'that' perhaps something of ego on your part.  and for the record,
i would be more than happy to trigger your twit filter.  there's no
discomfort in that at all.


    it's funny, but i personally, did not choose to run linux because i
expected a bleeding-edge gui.  in fact, when i started, that pretty much
out of the question.  further, i would hazard the guess most are more
concerned about running 'office' like applications, and from what i've
seen, those aproximations look pretty good.


: Since 1987, computer power has increased exponentially over and over
: again, and all that's changed in XFree86 is to become more bloated and
: require, yet not take advantage of newer hardware implementations.

    on the face of it, that's correct.  what, however, is not being
considered are the barriers faced by those writing software.  for
example, take logitech.  they have a line of webcams, but refuse to
release interface specifications to developers within the linux
community.


: What does that say about the current state of affairs of the desktop in
: OSS systems? It says that we'll not only settle, but fight for mediocrity.

    another way of looking at it, would suggest building on a stable
platform, that guarantees certail levels of operation.


: You stick to your legacy X11 system, I'll continue to champion for
: positive change. We'll see where XFree86 winds up in 3-5 years.

    you're long on talk, and full of enthusiasm, but is that all.  are
you willing to do something other than echo empty rhetoric.  is that the
limit of your contribution.  if so, your cause loses much of its nobility
...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: changing color depth in XFree86

[Milan P. Stanic]

On Mon, Apr 21, 2003 at 12:04:54AM -0700, terry white wrote:
>     "do us all a favour and save yourself from my twit filter"
> 
>     am i to infer from that, that YOU are speaking for the entire list.
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not really! Or at least, not for me.
My message to Stewart('s): look the signature!

> : Since 1987, computer power has increased exponentially over and over
  ^
Can you use usual "quote sign" (>), please?

Milan
------------------------------------------------------------------------
"Those who do not understand Unix are condemned to reinvent it, poorly."   

     -- Henry Spencer