Re: Graphic options for DS10L


"JF Mezei" <jfmezei.spamnot@xxxxxxxxxxxx> wrote in message
news:451399B5.43793DCA@xxxxxxxxxxxxxxx
Is there some "big picture" document that described how the OS interacts
with a graphics card ?


The BIG picture is the X11 programming interface. In general, the stuff
under the covers of X11 isn't as well documented - because, well - there are
very few of us who actually do it. But there are things floating around
from say, the late 80's when people tried to write it down.

Surf the web. Install RedHat on your PC and get the Xfree86 server sources.
You will find everything you need to know to get started. Once you master
that, and write your first Xfree86 DDX - even an XAA based one - send me a
copy, and I'll dig up the documentation on te VMS-specific things that are
done to support X11 graphics.

FredK mentioned that VMS for instance is likely to use 32 bits and use
the last 8 bits for special stuff like alpha value.


You take what the hardware gives you, and what the X11 server demands - and
then how much time you are willing to put into it. Packed 24-bit pixels
requires you to use *very* different logic than 32-bit pixels. It is
essentially unnatural in terms of programming - consider the user
application probably doesn't want to deal with packed 24-bits either (a
tribyte value is just a huge pain as an arreay of values). While I can
think of some cards that allow it - I can't think of many (well, actually
any) servers that tried to use it.

Why would you even try? Well, in the days when VRAM was expensive and
limited - it saved space. Today cards use cheap and generous sized DRAM.

The other 8-bits - well, that is really hardware dependent. They may be
useless on a 2D card - or they may select how the pixel is interpreted (for
example, this is how the TGA2 can do multiple simultanious depths). For
3D - it is a good place to store alpha transparency - heck some old cards
used it for Z. It really is very, very HW dependent.

If you have plenty of time, you might accelerate pixmaps by implementing an
offscreen pixmap memory manager - rather than using CFB which is what 80% of
all servers do. Perhaps you will instead cache font glyphs in offscreen
memory. Or maybe you punt it completely and leave offscreen memory unused.

Does the OS really have any control over how the graphics card behaves,
or does the graphics card have a variety of options and the OS chooses
one or the other ?


The "OS" doesn't - the server DDX and driver do. And yes, like almost every
device I know of - there are features that are used - and features that
aren't. Sometimes this is because the HW has modes that are designed for
the graphics semantics of Windows as well as X11. Sometimes - it's just
because using the feature is a whole lot of work and there isn't enough time
or resources to do it - say supporting the TV tuner and overlays. It all
depends.

Most cards support TrueColor 24-bit pixels directly. But oddly, most
servers/drivers program the DAC to 24-bit direct color and load a TrueColor
ramp. Another unused feature.

Another example: From what I have read, VMS does not enable/support the
DVI output of the Radeon 7500. Wouldn't it be a simple case of VMS
depositing a couple of values in a register and making an interrupt so
that the graphics cards turns on the DVI port ?


If it were a matter of "depositing a couple of values in a register and
making an interrupt so that the graphics cards turns on the DVI port" then
we would have done it. Programming of the DVI (and initialization itself)
is highly card dependent - and poorly documented. Why? Linux and UNIX tend
to use a BIOS emulator to do it... which is something we are working on for
Itanium. On Windows the card vendor writes the code - and they do *not*
like to expose their Windows source to anyone - crown jewels as it were.
The DVI port *works* if the card was initialized by the BIOS *and* if the
monitor was connected when the BIOS initialized. Unfortunately, the only
card you can depend on to be initialized by the BIOS is generally the card
used as the VGA console.

Or would VMS truly have to provide data in a very different way to the
graphics card in order for the DVI output to ne enabled ?


It is simply a matter of knowing how to perform some very card-specific
actions that aren't typically exposed in a well documented way to X11
Linux/UNIX developers.


And if VMS lacks the feature that enables the DVI port, is there
anything preventing a privileged user from accessing the graphics card
directly and making the interrupts/data transfer necessary to turn a
port on or off (DVI, or the composite video output) ?


Have at it. Find the HW documentation, PFN map the device and whack it.
You must feel we don't support it because we are lazy or just want to make
you unhappy. Hint: No interrupts needed - oh, wait - you think this is a
PC with an Int10.


On an old mac, I can dynamically change the screen size/resolution,
without impacting applications or having to reboot. On VMS, could this
be feasable ?


This is a generic problem in X11 - because applications need to (or can)
know to much about the pixel and screen format, there are issues (especially
if you change the depth). Could we change just the screen resolution
on-the-fly - probably without too much difficulty using some X11
extension... but IMHO the need to do this on-the-fly is more tied to things
like dual monitors on a Laptop - where it makes sense that you might
want/need to change the resolution on the fly.

Anything is possible given enough time and resources - and where there is a
reasonable payback.

Imagine your X11 application has started running, it opened the display -
found out that it had a 24-bit TrueColor pixel - but in the middle of your
application running - the pixel format changes to 8-bit pseudo color. Well,
either the X11 server then needs to emulate the 24-bit pixel depth for you
(very hard) - or it needs a way tell you that the pixel (and image) format
has changed - and you might not even then be able to run (for example you
might *need* 24-bit pixels). Or the X11 server can *always* run in 24-bit
mode and always *emulate* 8-bit and 16-bit modes (perhaps slow - but
possible - a Sun server once did this IIRC on a low-end card back in the day
that they had lots of people doing graphics engineering).

Or let's say the resolution is changed on the fly - and instead of
1920x1200 - you are now at 800x600 - and none of your windows fit on the
screen any more - less of a problem than the pixel format - but doable
(except for the odd really boneheaded application) using more-or-less
conventional X11 mechanisms.

When X11 was designed - hardware was slower and more limited, and there was
a belief that it needed to run on a toaster. So no floating point, no truly
complex problems were solved (KISS was the watchword). But the end result
was to enable applications to know far too much about the underlying
hardware.

Again - what exact issue are you trying to solve? You just want to have
that little application to play with to find the best resolution?

I assume one would have to access the graphics card to tell it to resize
the screen area, and somehow tell the X server to also resize the screen
area. Are there mechanisms to do that ?


There are no standard mechanisms. I believe that there may be an X11
extension on Linux that does something along these lines. The change in
size *has* to pass through the X11 server.

When the X server starts up, I realise that it looks at a bunch of
symbols and logicals to set a lot of the parameters (as opposed to a
control panel on a MAC that does this dynamically). But could the code
that does that be called at times other than X server startup ?


Again. Why? Give me a concrete reason that we should do this work. What
are you trying to solve? Frankly it has to be a *strong* reason. For
example, would you choose this over - say - a VNC server?


Seems like graphic cards are voodoo magic happening behind the scenes. I
would liek a better understanding.

Graphics cards *are* part engineering and part vodoo magic.



.

Relevant Pages

  • Re: Diagnosing infrequent X server crashes
    ... graphics card. ... I'm running the xorg X server: ... I'm getting infrequent crashes which lock up the X server completely. ... NVidia card I could use instead of the radeon, ...
    (uk.comp.os.linux)
  • Re: Do you need a video card to run an X server?
    ... Andrew Hardy wrote: ... Does the servers video card have any impact on the X server part of the ... I'd like to dump the card so that I have one less fan to listen to! ... Do you want to run the machine with no graphics card at all, ...
    (uk.comp.os.linux)
  • Re: Do you need a video card to run an X server?
    ... Does the servers video card have any impact on the X server part of the ... I'd like to dump the card so that I have one less fan to listen to! ... Do you want to run the machine with no graphics card at all, ...
    (uk.comp.os.linux)
  • Re: Do you need a video card to run an X server?
    ... Does the servers video card have any impact on the X server part of the ... I'd like to dump the card so that I have one less fan to listen to! ... Do you want to run the machine with no graphics card at all, ... Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org ...
    (uk.comp.os.linux)
  • RE: OT: Sparc not dead yet
    ... When the server reboots, it again starts taking ... I've implimented Load Broker and supplimented it with LAN/IP failover ... Since replacing a card in a set might only take 5-10 ... I thought in terms of NICs we said LAN ...
    (comp.os.vms)