Re: [9fans] VGA Hell, what else?!

Re: [9fans] VGA Hell, what else?!

[jmk]

George Michaelson <ggm@dstc.edu.au>
	ok second take. during install phases, M$ drives the screen as a 640x480
	take-it-or-leave-it or is it even CGA 320x240?

	this implies all cards have some level of activity which works and supplies
	both bitmap and ASCII text services. 16 colours. flickery as hell. 

	wouldn't it make sense to wire the plan9 install floppies to this instead
	of any yeubeut higher-res, and do higher-res as a post-install?

Until aux/vga runs, the screen is in CGA mode, that's an 80 character wide
by 25 line text mode. You can do graphics in it and the Plan 9 2nd Edition
release did exactly that during the install phases. However, the predominant
depths used for graphics in the 2nd Edition were 1 and 4 bits, i.e. there wasn't
much colour. We were told often that we were not colourful enough so we ported
back the graphics model we did for Inferno, which was 8 bits deep and abandoned
the older stuff. Was that the right choice? I don't know but I'm happy enough
in that I don't need colour for what I do (I'm in CGA mode half the time).
Don't get me wrong, I'd love to have the NVIDIA and 3Dlabs cards I have lying
on the shelf working with Plan 9, but I don't have the time or inclination to
reverse-engineer an XFree86 driver without documentation. Does anyone else?

--jim

Re: [9fans] VGA Hell, what else?!

[George Michaelson]

  Until aux/vga runs, the screen is in CGA mode, that's an 80 character
  wide by 25 line text mode. You can do graphics in it and the Plan 9 2nd
  Edition release did exactly that during the install phases. However,
  the predominant depths used for graphics in the 2nd Edition were 1
  and 4 bits, i.e. there wasn't much colour. We were told often that we
  were not colourful enough so we ported back the graphics model we did
  for Inferno, which was 8 bits deep and abandoned the older stuff. Was
  that the right choice? I don't know but I'm happy enough in that
  I don't need colour for what I do (I'm in CGA mode half the time).
  Don't get me wrong, I'd love to have the NVIDIA and 3Dlabs cards I
  have lying on the shelf working with Plan 9, but I don't have the
  time or inclinationto reverse-engineer an XFree86 driver without
  documentation. Does anyone else?

I believe somebody else is working on the card I care about and when I
get back to the box with the boot floppy I will be following up on that
but I think this piece of history exposes a design decision which had
bad ramifcations for code in release to the wider userbase. adding flashy
drivers was good. loosing the ability to install on base CGA was bad.

Please don't get me wrong, I know why these kinds of decisions get made
and I'm not looking to hassle anyone to do work they don't have time for.

Have I missed something? If you are in CGA mode, does that mean that
the install phase could still be made to work in CGA mode?

-George

Re: [9fans] VGA Hell, what else?!

[Richard Miller]

> (it'd be greyscale, and the new colors really don't
> look good in grey).

I disagree: on my grey-scale Eizo (FlexScan) monitor I find the subtle shades
of grey to be pleasing and restful.  In particular working with acme is more
comfortable there than on a colour ThinkPad where the highlighting in window
bodies is nearly invisible.

-- Richard

Re: [9fans] VGA Hell, what else?!

[nigel]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

I have to agree with jmk. Well written though many of the XFree86 drivers are,
they still contain a worrying number of comments along the lines of "I seem to
need to do this", or "this is opposite to what the manual says", or "dunno it
just seems to work". This is not the authors' fault, believe me.

Add to this that just because a driver covers all chip revisions, it doesn't mean
that it has actually been tested. You could sit down and transcribe all the good
looking stuff into Plan 9 and find it makes no difference at all.

This appears to be true for my laptop.

Moral is, try XFree86 _before_ copying the changes.


[-- Attachment #2: Type: message/rfc822, Size: 2158 bytes --]

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] VGA Hell, what else?!
Date: Thu, 7 Dec 2000 21:18:23 -0500
Message-ID: <20001208021839.DB9D4199EB@mail.cse.psu.edu>

George Michaelson <ggm@dstc.edu.au>
	I don't mean to imply the code is worth pillaging (or not contrariwise
	in a tweedledee/tweedledum sense) but surely XFree86 drivers in effect
	codify the register and bitblt functions for all the chipsets people are
	seeking to dick with?

	Since the XFree86 code has to have a generalized ABI to call these, does
	this not mean there is a reductionist process to work back from the calls
	and work out what frobs to frib?

Oh, the XFree86 drivers are a wonderful resource but you'd be wrong to think
that the register functions are always codified, that the codifications mean
anything without a real datasheet or that there is always a way to work back
to an understanding.

--jim

Re: [9fans] VGA Hell, what else?!

[Russ Cox]

  > ok second take. during install phases, M$ drives the screen as a 640x480
  > take-it-or-leave-it or is it even CGA 320x240?
  > 
  This has been explained before, although I didn't pay enough attention at
  the time to recall correctly now :-(  But it should be in the mailing
  list archives.

You could set up 640x480x16, but it would require
a soft cursor, which we currently don't do.
You're going to be miserable in 640x480x16 anyway
(it'd be greyscale, and the new colors really don't
look good in grey).

The theory is that you're going to have to run with
a decent vga eventually, so we might as well deal with
it up front.  I think it's more frustrating to do the
whole install in text and then not be able to run the
system for lack of a graphics card.

  A graphic ABI (what's that "B"?  'Tused to be a "P", can someone explain
  the difference?) would be wonderful, but looking at the X11(3) man pages,

B is binary.  That would involve running other people's
binaries too.

Russ

Re: [9fans] VGA Hell, what else?!

[George Michaelson]

    A graphic ABI (what's that "B"?  'Tused to be a "P", can someone explain
    the difference?) would be wonderful, but looking at the X11(3) man pages,
  
  B is binary.  That would involve running other people's
  binaries too.

I dind't mean to imply doing that. I just meant that they were obviously
coding to one, and thus had the aPi written to abstract it, and so glue
could exist to aide detecting what frobs to frib. But if I am being told
there are more special cases here than grains of sand on the beach at bondi
I will concur and quietly stew in my own prunejuice a bit longer.

I have been playing with 9term on X meantimes. I know the wise sayeth 
'its intuitive' but I've been intuiting and intuiting until I got around tuit
and I still can't make it do what I thought I wanted it to do.

Could it be my brain has been wired up wrong by too many years of X11 madness?

The manual pages are for the cogniscenti. beginners need tutorials laid out
like for valley girls. draw pictures of the mouse. don't assume anything
with more than 2 sylabbles is spellable let alone understood. I just 
didn't get it. in limbo, I can make acme open more 2d decorated windows
than I care to imagine, each smaller than the next one but I can't make
the pig sing, or the horse drink the water.

oh well.

	-George

Re: [9fans] VGA Hell, what else?!

[Russ Cox]

  reasons, but what's the alternative?  What do the bell labs people do when
  they find themselves confronted with 't/huge-dir' that needs to be
  './huge-dir'?

The only times I find myself doing this is when
I have untarred an archive that had unexpected names in it.
Since I look at the names before untarring, this
is very rare.

There isn't the Unix plethora of places in which source
or binaries are kept, so it's not common that entire
trees move from one place to another.

  From the sound of it, a cross-directory rename not implemented for good
  reasons, but what's the alternative?  

The good reasons are good enough: how much more complicated
would 9P get in order to support this?  How much more complicated
would the kernel get?  Namec is hard enough to get right.
Since it is so rarely needed, it's not worth the effort.
Put things in the right place to begin with.

Russ

Re: [9fans] VGA Hell, what else?!

[jmk]

George Michaelson <ggm@dstc.edu.au>
	Have I missed something? If you are in CGA mode, does that mean that
	the install phase could still be made to work in CGA mode?

I beleive there are examples of people installing the system 'by hand', i.e.
editing plan9.ini manually and then issueing the neccessary commands to do the
install from the shell prompt. If that's what you want to do I'm sure someone
will either put me right or tell you what to do.

--jim

Re: [9fans] VGA Hell, what else?!

[jmk]

George Michaelson <ggm@dstc.edu.au>
	I don't mean to imply the code is worth pillaging (or not contrariwise
	in a tweedledee/tweedledum sense) but surely XFree86 drivers in effect
	codify the register and bitblt functions for all the chipsets people are
	seeking to dick with?

	Since the XFree86 code has to have a generalized ABI to call these, does
	this not mean there is a reductionist process to work back from the calls
	and work out what frobs to frib?

Oh, the XFree86 drivers are a wonderful resource but you'd be wrong to think
that the register functions are always codified, that the codifications mean
anything without a real datasheet or that there is always a way to work back
to an understanding.

--jim

Re: [9fans] VGA Hell, what else?!

[George Michaelson]

ok second take. during install phases, M$ drives the screen as a 640x480
take-it-or-leave-it or is it even CGA 320x240?

this implies all cards have some level of activity which works and supplies
both bitmap and ASCII text services. 16 colours. flickery as hell. 

wouldn't it make sense to wire the plan9 install floppies to this instead
of any yeubeut higher-res, and do higher-res as a post-install?

cheers
	-George

Re: [9fans] VGA Hell, what else?!

[Lucio De Re]

On Fri, Dec 08, 2000 at 12:28:50PM +1000, George Michaelson wrote:
> 
> ok second take. during install phases, M$ drives the screen as a 640x480
> take-it-or-leave-it or is it even CGA 320x240?
> 
This has been explained before, although I didn't pay enough attention at
the time to recall correctly now :-(  But it should be in the mailing
list archives.

> this implies all cards have some level of activity which works and supplies
> both bitmap and ASCII text services. 16 colours. flickery as hell. 
> 
Something to do with the hardware cursor?  Maybe not...

It is unfortunate that the Plan 9 developers are so serious :-)  Graphic
games are a significant aspect of the more popular operating systems, and
Plan 9 is sorely lacking in that direction.  Not that that isn't in
itself an advantage, keeping the more frivolous developers at bay, but it
does deter from serious developers applying their skills to port
otherwise solid, but graphic-demanding applications to Plan 9.

A graphic ABI (what's that "B"?  'Tused to be a "P", can someone explain
the difference?) would be wonderful, but looking at the X11(3) man pages,
I fall into the deepest despair.  A pity, really, I'd like Tcl/Tk to be
available in Plan 9.

Mind you, I'd like Expect even more, and I have no clue how to make
_that_ work, either.

++L

Re: [9fans] VGA Hell, what else?!

[Quinn Dunkan]

> It is unfortunate that the Plan 9 developers are so serious :-)  Graphic
> games are a significant aspect of the more popular operating systems, and
> Plan 9 is sorely lacking in that direction.  Not that that isn't in
> itself an advantage, keeping the more frivolous developers at bay, but it
> does deter from serious developers applying their skills to port
> otherwise solid, but graphic-demanding applications to Plan 9.
> 
> A graphic ABI (what's that "B"?  'Tused to be a "P", can someone explain
> the difference?) would be wonderful, but looking at the X11(3) man pages,
> I fall into the deepest despair.  A pity, really, I'd like Tcl/Tk to be
> available in Plan 9.

I don't have any particular desire for a buttons and menus style graphics
toolkit, but an opengl library would be really nice.  On the widget toolkit
front, I wonder if it would be practical to have a 'gfx server' that does for
graphical programs what acme does for text ones, or give acme the ability to
display bitmaps and positioned text, etc.  If there were to be a plan9 web
browser, it could be built on such a foundation.

Hey, maybe if we wish for these things enough they'll sort of materialize out
of thin air :)  Seriously, though, I don't think these things are lacking
because plan 9 developers all shun graphics, but because they take a lot of
work and there doesn't seem to be many swarms of eager developers around.  I
imagine that if someone did some solid work that added needed functionality,
it would get folded into the main distribution.

On a somewhat-related topic, would it be possible to teach aux/vga to load
XF86 driver modules?  If it could, that would basically solve the vga driver
problem.  Or maybe it's less work to just add each card to aux/vga directly,
as is done currently?  I haven't looked at the spec for the modules, but
hopefully they're reasonably X-independent.

Also, on the subject of cross-directory renames that came up a while back, is
the plan9 position to just try to avoid having to move a large tree to a
different directory, and if you must, sit back while it copies and deletes?
 From the sound of it, a cross-directory rename not implemented for good
reasons, but what's the alternative?  What do the bell labs people do when
they find themselves confronted with 't/huge-dir' that needs to be
'./huge-dir'?

Obviously, bind can work nicely, but is only really appropriate for situations
where the "move" is temporary and only needs to be seen by procs in the same
namespace group.  I don't even know if there's a way to remove a file from the
namespace.  I know you could MREPL an empty directory over a directory, but a
single file?

Re: [9fans] VGA Hell, what else?!

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

in general, without the documents for the precise chips you've
got, you stand no chance of working with the vga code,
not because it doesn't use symbolic names, but because even
then you'll have no idea what the interpretation is, unless you
also copy the contents of each manual's register description
into the code as well.  different register numbers are used differently
by SVGA implementations, and in particular, ET4000 bears no
resemblance to S3 in the chip-dependent set (even within the S3
range you need the chip-specific books).  with the book to hand
(which as i've said you need anyway), for my own part, i find the use of numbers
eliminates a trip to the index for each one.  i suspect there's not
a standard naming scheme even for the common (ha!) subset that's VGA.

in fact, even with the documents for the precise chip, you've
still got your work cut out (in general, probably not in the case you mention).

>>I'm suffering from dreadful flicker trying to use 1024x768x8 on a

i find that sometimes happens to me when i drink too much,
which happens (funnily enough) each time i've had to work with svga.


[-- Attachment #2: Type: message/rfc822, Size: 2722 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] VGA Hell, what else?!
Date: Thu, 7 Dec 2000 10:23:34 +0200
Message-ID: <20001207102332.A20270@cackle.proxima.alt.za>

I'm suffering from dreadful flicker trying to use 1024x768x8 on a
multisync65, mostly because 1024x768x8i is utterly broken.  I'm
using what seems an old S3Virge/Diamond Stealth Pro.

I've hacked bits of "vga", if only to see what would happen, but
the results have been unpromising, no doubt because I've been using
some old ET 4000 documentation, inappropriate to the task.

So, two things: does anyone know where I can find S3 docs and would
it help any if I went to the trouble of relabelling all the register
numbers with what cobol programmers used to call "figurative
constants" (should that be all capitals, perhaps?) in the
sys/src/cmd/aux/vga directory?  I'm half hoping for a resounding
"no" to the second question :-)

++L

Re: [9fans] VGA Hell, what else?!

[George Michaelson]

I don't mean to imply the code is worth pillaging (or not contrariwise
in a tweedledee/tweedledum sense) but surely XFree86 drivers in effect
codify the register and bitblt functions for all the chipsets people are
seeking to dick with?

Since the XFree86 code has to have a generalized ABI to call these, does
this not mean there is a reductionist process to work back from the calls
and work out what frobs to frib?

-George
--
George Michaelson         |  DSTC Pty Ltd
Email: ggm@dstc.edu.au    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

[9fans] VGA Hell, what else?!

[Lucio De Re]

I'm suffering from dreadful flicker trying to use 1024x768x8 on a
multisync65, mostly because 1024x768x8i is utterly broken.  I'm
using what seems an old S3Virge/Diamond Stealth Pro.

I've hacked bits of "vga", if only to see what would happen, but
the results have been unpromising, no doubt because I've been using
some old ET 4000 documentation, inappropriate to the task.

So, two things: does anyone know where I can find S3 docs and would
it help any if I went to the trouble of relabelling all the register
numbers with what cobol programmers used to call "figurative
constants" (should that be all capitals, perhaps?) in the
sys/src/cmd/aux/vga directory?  I'm half hoping for a resounding
"no" to the second question :-)

++L