[9fans] ati radeon support

[9fans] ati radeon support

[Hugo Santos]

Hi there,

I was trying to boot Plan9 on my laptop which has a ATI Radeon Mobility
7500 which doesn't seem to be supported.
Is there any support or work being done in Radeon support for Plan9?
My card pci is 1002/4c57.

Hugo Santos

Re: [9fans] ati radeon support

[mirtchov]

> Hi there,
>
> I was trying to boot Plan9 on my laptop which has a ATI Radeon Mobility
> 7500 which doesn't seem to be supported.
> Is there any support or work being done in Radeon support for Plan9?
> My card pci is 1002/4c57.
>
> Hugo Santos

Philippe Anel has written the radeon driver:

	http://mapage.noos.fr/philippe.anel/plan9rxxx.html

unfortunately the current drivers don't support the 7500 (which iswhat
I have, same as yours).  I provided him with as much info as possible
on on the model as I could (or as he needed) some time ago...

Re: [9fans] ati radeon support

[okamoto]

> I have, same as yours).  I provided him with as much info as possible
> on on the model as I could (or as he needed) some time ago...

I'm not Philippe, however, I think it's very hard to write vga dirver
when the developper has no access to that very card.   Those things
sometimes does not behave as written.

Kenji

Re: [9fans] ati radeon support

[Christian Grothaus]

The driver already works with the Radeon Mobility 7500, when
you connect a CRT to the laptop. What's missing yet is just
LCD/DFP support. Phillipe mailed me a while ago that he's
working on it, but I can imagine it's ungrateful work when
there are differences from card to card...

Christian

Re: [9fans] ati radeon support

[Christian Grothaus]

> LCD/DFP support. Phillipe mailed me a while ago that he's

s/Phillipe/Philippe/

I'm sorry!

Re: [9fans] ati radeon support

[Hugo Santos]

Shouldn't there be support for 'standard' VESA 2.0 if native support
isn't available? That way "all" the unsupported cards/chips would at
least have (poor slow) graphics.

Hugo


On Thursday, October 2, 2003, at 09:11 AM, Christian Grothaus wrote:

> The driver already works with the Radeon Mobility 7500, when
> you connect a CRT to the laptop. What's missing yet is just
> LCD/DFP support. Phillipe mailed me a while ago that he's
> working on it, but I can imagine it's ungrateful work when
> there are differences from card to card...
>
> Christian
>

Re: [9fans] ati radeon support

[mirtchov]

> Shouldn't there be support for 'standard' VESA 2.0 if native support
> isn't available? That way "all" the unsupported cards/chips would at
> least have (poor slow) graphics.
>

nobody cared enough to write it, though it has been discussed on the
list many times:

	http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=VESA&btnG=Google+Search&meta=group%3Dcomp.os.plan9

Re: [9fans] ati radeon support

[Douglas A. Gwyn]

mirtchov@cpsc.ucalgary.ca wrote:
> nobody cared enough to write it, though it has been discussed on the
> list many times:

Of course the ironic thing is that Plan 9 really doesn't need more
than VESA provides; all those 3D graphics features of today's cards
are being wasted under Plan 9.  A single VESA driver would have
prevented having to keep hacking drivers for each new card.

Re: [9fans] ati radeon support

[paurea]

> Of course the ironic thing is that Plan 9 really doesn't need more
> than VESA provides; all those 3D graphics features of today's cards
> are being wasted under Plan 9.  A single VESA driver would have
> prevented having to keep hacking drivers for each new card.

On last discussion I understood that there is a problem with hw cursor
(noone supports it even if the standard VESA does). Before using VESA,
someone has to write support for software cursor. Another issue may be
that VESA may not be as standard as one might expect (for example BIOS
bugs are card dependant). Take a look at the vesa X driver for example.


								Gorka

Re: [9fans] ati radeon support

[rog]

> On last discussion I understood that there is a problem with hw cursor
> (noone supports it even if the standard VESA does). Before using VESA,
> someone has to write support for software cursor.

you're right: the inferno stuff that forsyth posted relied on software
cursor support, something that plan 9 no longer has, i believe.

Re: [9fans] ati radeon support

[Charles Forsyth]

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

the code for that is in there (done by someone at Lucent)
but the connections in devdraw aren't there any more.
i thought the interface could be simpler.

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

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ati radeon support
Date: Fri, 3 Oct 2003 14:12:19 +0100
Message-ID: <543e21d05a66f04bff57ce80f26cffc5@vitanuova.com>

> On last discussion I understood that there is a problem with hw cursor
> (noone supports it even if the standard VESA does). Before using VESA,
> someone has to write support for software cursor.

you're right: the inferno stuff that forsyth posted relied on software
cursor support, something that plan 9 no longer has, i believe.

Re: [9fans] ati radeon support

[jmk]

On Fri Oct  3 09:10:45 EDT 2003, rog@vitanuova.com wrote:
> > On last discussion I understood that there is a problem with hw cursor
> > (noone supports it even if the standard VESA does). Before using VESA,
> > someone has to write support for software cursor.
>
> you're right: the inferno stuff that forsyth posted relied on software
> cursor support, something that plan 9 no longer has, i believe.

I haven't ever looked at VESA, so forgive me if this is a stupid question:
once you have used VESA to set up the hardware, if you know how to drive the
hardware cursor is there anything stopping you from doing that? Usually,
writing the code for a hardware cursor is fiddly but not hard.

Re: [9fans] ati radeon support

[rog]

> I haven't ever looked at VESA, so forgive me if this is a stupid question:
> once you have used VESA to set up the hardware, if you know how to drive the
> hardware cursor is there anything stopping you from doing that? Usually,
> writing the code for a hardware cursor is fiddly but not hard.

no...  just that if you're doing that, you still need to have *some*
sort of graphics-card specific driver, whereas the potential bonus of
using VESA graphics is that you can use almost any card regardless of
driver availability.

Re: [9fans] ati radeon support

[C H Forsyth]

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

yes, the problem with graphics cards is really the strange card-specific stuff
needed to put it into a reasonable large, deep linear colour mode.
if we had only to write code for the hw cursor for each one,
that would be much less of a problem.  even some of the hardware
drawing code doesn't look hard to exploit ... once the card is in a sensible mode.

the cursor code always seemed fairly similar, so it might not be too hard
to have a table of ids just for that if necessary, and certainly card-specific
code for that is fairly easy to write.  one of the changes i
was making to the software cursor in inferno is to bring it
into a common interface with the hardware one
(allowing for the need to interact a bit with devdraw re. screen access).

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

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ati radeon support
Date: Fri, 3 Oct 2003 10:34:29 -0400
Message-ID: <3308f46c395bce82502b731fc273af8b@plan9.bell-labs.com>

On Fri Oct  3 09:10:45 EDT 2003, rog@vitanuova.com wrote:
> > On last discussion I understood that there is a problem with hw cursor
> > (noone supports it even if the standard VESA does). Before using VESA,
> > someone has to write support for software cursor.
>
> you're right: the inferno stuff that forsyth posted relied on software
> cursor support, something that plan 9 no longer has, i believe.

I haven't ever looked at VESA, so forgive me if this is a stupid question:
once you have used VESA to set up the hardware, if you know how to drive the
hardware cursor is there anything stopping you from doing that? Usually,
writing the code for a hardware cursor is fiddly but not hard.

Re: [9fans] ati radeon support

[jmk]

On Fri Oct  3 13:57:55 EDT 2003, forsyth@vitanuova.com wrote:
> yes, the problem with graphics cards is really the strange card-specific stuff
> needed to put it into a reasonable large, deep linear colour mode.
> if we had only to write code for the hw cursor for each one,
> that would be much less of a problem.  even some of the hardware
> drawing code doesn't look hard to exploit ... once the card is in a sensible mode.
>
> the cursor code always seemed fairly similar, so it might not be too hard
> to have a table of ids just for that if necessary, and certainly card-specific
> code for that is fairly easy to write.  one of the changes i
> was making to the software cursor in inferno is to bring it
> into a common interface with the hardware one
> (allowing for the need to interact a bit with devdraw re. screen access).

The reason the software cursor disappeared form Plan 9 was, by the time
devdraw went in, the cursor and mouse code had accumulated so much cruft
after years of adapting to new graphics models and hardware that it was
a constant source of lockups and crashes. There was an attempt when changing
to devdraw to pare all that back and simplify it. The software cursor
was the cause of many of the problems.

The software cursor is OK for getting started, but I'd hate to use it
in earnest. The flicker when scrolling text was awful and I'm trying to
imagine what it would be like with vnc.

Re: [9fans] ati radeon support

[Charles Forsyth]

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

that code was indeed quite complicated (it seemed to wander back and
forth between draw, mouse and screen in a way that was probably straightforward
but always left me a little confused for a few passes).

for performance, i think it depends how it's done.  i didn't do the Inferno one, but i did
use it without obvious trouble with Inferno on a 486sx33 processor.  in one of my
own os's i did the software cursor in a process on a 386sx16 and
that was fine too, although that was only 16x16 in bits on a monochrome screen.
neither controlled it with the clock, though, which might have made it smoother.

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

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ati radeon support
Date: Fri, 3 Oct 2003 14:28:09 -0400
Message-ID: <92f0483b4252b9cd48e240d6d4122c65@plan9.bell-labs.com>

On Fri Oct  3 13:57:55 EDT 2003, forsyth@vitanuova.com wrote:
> yes, the problem with graphics cards is really the strange card-specific stuff
> needed to put it into a reasonable large, deep linear colour mode.
> if we had only to write code for the hw cursor for each one,
> that would be much less of a problem.  even some of the hardware
> drawing code doesn't look hard to exploit ... once the card is in a sensible mode.
>
> the cursor code always seemed fairly similar, so it might not be too hard
> to have a table of ids just for that if necessary, and certainly card-specific
> code for that is fairly easy to write.  one of the changes i
> was making to the software cursor in inferno is to bring it
> into a common interface with the hardware one
> (allowing for the need to interact a bit with devdraw re. screen access).

The reason the software cursor disappeared form Plan 9 was, by the time
devdraw went in, the cursor and mouse code had accumulated so much cruft
after years of adapting to new graphics models and hardware that it was
a constant source of lockups and crashes. There was an attempt when changing
to devdraw to pare all that back and simplify it. The software cursor
was the cause of many of the problems.

The software cursor is OK for getting started, but I'd hate to use it
in earnest. The flicker when scrolling text was awful and I'm trying to
imagine what it would be like with vnc.

Re: [9fans] ati radeon support

[Charles Forsyth]

>>for performance, i think it depends how [software cursor] is done.

which doesn't mean that i prefer it to using a hardware cursor, which can do more
with less overhead and disturbance.

i don't really understand why graphics adapter makers can apparently
agree to change anything except the hopelessly obsolete VGA interface.
soon you'll need to visit three registers to collect enough bits for screen width.
i don't mind if there's a standard bit
	Think=	1<<0,	/* acquire a brain */
in a standard place that must be set to enable a more reasonable
interface for current and future displays and otherwise it defaults to 1983 say.

Re: [9fans] ati radeon support

[C H Forsyth]

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

i've put it in

	http://www.vitanuova.com/dist/vesa.tgz

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

From: Charles Forsyth <forsyth@caldo.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ati radeon support
Date: Fri, 3 Oct 2003 10:27:11 +0100
Message-ID: <0a5ffa61e305f29dcebbe41d2dde451f@caldo.demon.co.uk>

>>there is VESA32 standard with 32bit entries and linear framebuffer, but
>>I don't know how many cards support that thing...

roger used 16-bit mode in the bootstrap to set up
a linear framebuffer because nothing much actually supported
the 32-bit mode, even if you could trust the BIOS not to do
something silly.  it might have changed.  i was going to tar
up his code and put it on a web site, once i'd located the pieces
again, in case anyone was sufficiently keen.

Re: [9fans] ati radeon support

[Charles Forsyth]

>>there is VESA32 standard with 32bit entries and linear framebuffer, but
>>I don't know how many cards support that thing...

roger used 16-bit mode in the bootstrap to set up
a linear framebuffer because nothing much actually supported
the 32-bit mode, even if you could trust the BIOS not to do
something silly.  it might have changed.  i was going to tar
up his code and put it on a web site, once i'd located the pieces
again, in case anyone was sufficiently keen.

Re: [9fans] ati radeon support

[Atanas Bachvaroff]

[-- Attachment #1: Type: TEXT/plain, Size: 541 bytes --]

On  3 Oct, Tiit Lankots wrote:
> No wonder nobody has written a VESA driver -- VESA is loathsome.
> You only have a 64K (or maybe even less) sliding window into the
> framebuffer; to do any real work you need to regularly engage in
> "bank switching", which is *slow*.
>
> Not to mention all the real-mode 16-bit interupt goo. Yuck.
>

there is VESA32 standard with 32bit entries and linear framebuffer, but
I don't know how many cards support that thing...
--
BEATVSHOMOQVIINVENITSAPIENTIAMETQVIAFFLVITPRVDENTIALIVRILVCIFERIVS

[-- Attachment #2: Type: APPLICATION/pgp-signature, Size: 256 bytes --]

RE: [9fans] ati radeon support

[Tiit Lankots]

> A single VESA driver would have
>prevented having to keep hacking drivers for each new card.

No wonder nobody has written a VESA driver -- VESA is loathsome. 
You only have a 64K (or maybe even less) sliding window into the 
framebuffer; to do any real work you need to regularly engage in
"bank switching", which is *slow*.

Not to mention all the real-mode 16-bit interupt goo. Yuck.