Redesign of kernel graphics interface

Redesign of kernel graphics interface

[Jon Smirl]

At the X Developers Conference there was a discussion of the issues around
framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
discussion. I'm going to try and list all of the issues I've heard from all
sides so some of the proposed solutions are in conflict. The goal of this list
is to provide direction for a topic discussion at the Ottawa Kernel Summit.

The top item is that accessing the video hardware is a free for all. There are
two device drivers, FB and DRI, plus numerous user space apps, like X and
SVGlib, all trying to control the hardware. The result of this is that it is
easy to lock up your machine when switching between the different usages. X does
particularly nasty things to the hardware from user space without informing the
kernel.

First is a little background that should have been in my original post:
http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000399.html

Next is the orginal post:
http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000379.html

The reply thread on the kernel summit list is here:
http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/thread.html

Some talk about doing a better video memory manager and kgi is here:
http://marc.theaimsgroup.com/?l=dri-devel&r=1&b=200405&w=2

A major topic that I missed in the original list was how to handle BSD. DRM is
under the BSD license and FB is GPL. If these two code bases are merged, what
are we going to do about BSD? I don't know the appropriate BSD lists to post
this to so please forward as necessary.

Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.

After the flames from this settle down I'll try to write a document summarizing
the conclusions reached, if any. The best possible outcome would be a design
document for review at Kernel Summit.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Geert Uytterhoeven]

On Thu, 6 May 2004, Jon Smirl wrote:
> Another topic that I missed was, why did kgi fail and what can we do to avoid
> repeating the same path this time around.

IIRC, the main reasons were:
  - GGI wanted to do too much at once and was too intruisive (conclusion:
    always advance in small steps, not big leaps):
      o kernel graphics drivers (KGI)
      o new input subsystem (similar to what we're heading to now)
      o user space library (libggi, AFAIK the only part that's still alive)
  - fbdev was better in multi-platform handling (m68k -> PPC -> ia32 -> SPARC
    -> alpha -> ...)

Please correct me if I'm wrong ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Otto Solares]

On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
> At the X Developers Conference there was a discussion of the issues around
> framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
> discussion. I'm going to try and list all of the issues I've heard from all
> sides so some of the proposed solutions are in conflict. The goal of this list
> is to provide direction for a topic discussion at the Ottawa Kernel Summit.

I see as common sense that fbdev should become the low-level and unified
interface for graphics in Linux, it has too many advantages for us:

- Exists now.
- Multi-architecture.
- Very popular in embedded solutions.
- Interface to change video modes.
- Supports low-end hardware.
- It has an interface to control the hw from userspace.
- Can be enhanced or fixed.

Missing in fbdev:

- Memory management.
- Hardware lock to synch or flag changes in hardware.
  (Maybe with the DRM/FB merge we could reuse the lock.)
- sysfs (being fixed by Luca).
- Video-out port API.
- Video capture API (gatos).

I imply too that fbcon should not be considered as part of this low-level
layer, but a client of it, because it implements acceleration and other
stuff not related nor pertinent to a graphics layer per se.

I am not saying that everything should be in the kernel, just the necesary
API to properly have a Linux graphics state machine.  Anything else should
be in userspace, specially acceleration that could be provided by DRI,
directfb, fbcon, etc. which all will be clients of the low-level fbdev layer.

This path makes it feasible to implement graphics servers (like Xserver)
without implementing or duplicating the graphics layer details.  This
would lead to a sane and (with time) a stable graphics layer for linux in
the same way we have first-class networking, input and sound layers in Linux
now.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Jon Smirl]

--- Nicolas Souchu <nsouch@free.fr> wrote:
> > A major topic that I missed in the original list was how to handle BSD. DRM
> > is under the BSD license and FB is GPL. If these two code bases are merged,
> > what are we going to do about BSD? I don't know the appropriate BSD lists 
> > to post this to so please forward as necessary.
> 
> What is exactly your question concerning licenses?

FB is GPL licensed. DRM is BSD licensed. If FB and DRM are merged the end result
will be GPL licensed code because of the way the licenses work. To change that
you would have to get permission from every FB contributor to relicense their
contribution from GPL to BSD. I suspect that it is pratically impossible to
track all of the FB contributors down and what do you do if some won't
cooperate? If the FB/DRM combo is GPL it can't be merged back into the BSD
kernels. What we could do is build a merged driver and continue to have some of
the source files licensed BSD and some GPL.

The big reason for merging is memory management. If FB supports multiple heads
it is forced into doing memory management. DRI has memory management needs that
go far beyond what FB needs so a merged system has to use DRM memory management.
Ian has made proposals on how to do this and he is working on improving them. 

BenH and others have made proposals for pushing the mode setting code into a
user space library in order to reduce kernel footprint and ease debugging. Most
of the code needed for this library already exists in the current Linux FB
drivers. I'm not sure if this could be relicensed BSD when it is moved to user
space.


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> But who cares? Do you really intend to keep a common BSD and Linux API/code base?
> Offering both solutions under BSD and GPL would be good for suggesting correct
> license usage in the embedded world. GPL is too often bypassed.

What about a dual license.
 
> > The big reason for merging is memory management. If FB supports multiple heads
> > it is forced into doing memory management. DRI has memory management needs that
> > go far beyond what FB needs so a merged system has to use DRM memory management.
> > Ian has made proposals on how to do this and he is working on improving them. 
> 
> What is best? Bring modesetting to DRM or memory management to FB?

Bring mode setting to DRM since all FB does is mode setting, color maps 
and 3 accel functions for the console. With sysfs we could bring both 
together.

> > BenH and others have made proposals for pushing the mode setting code into a
> > user space library in order to reduce kernel footprint and ease debugging. Most
> > of the code needed for this library already exists in the current Linux FB
> > drivers. I'm not sure if this could be relicensed BSD when it is moved to user
> > space.
> 
> One advantage of true graphic drivers (opposed to VESA or more generally bios modes)
> is that they can boot some archs in graphic mode (no text mode) without bios.
> Exactly what linuxfb was originaly designed to. How do you perform this 
> from userspace?

The idea was to mount userland inside the kernel while booting and run a 
library to initialize the mode. We have two options:

1) Keep mode switching in the kernel. Merge DRI and fb together via 
   sysfs interface.

2) Ben suggestion that we mount userland inside the kernel during early 
   boot and use a userland library. If we would use a library then it MUST 
   be OpenGL. This would be the forced standard on all platforms. This 
   would mean Mesa would be needed to build the kernel. We could move over 
   Mesa into the kernel like zlib is in the tree right now.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Nicolas Souchu]

On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
> At the X Developers Conference there was a discussion of the issues around
> framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
> discussion. I'm going to try and list all of the issues I've heard from all
> sides so some of the proposed solutions are in conflict. The goal of this list
> is to provide direction for a topic discussion at the Ottawa Kernel Summit.

[...]
> A major topic that I missed in the original list was how to handle BSD. DRM is
> under the BSD license and FB is GPL. If these two code bases are merged, what
> are we going to do about BSD? I don't know the appropriate BSD lists to post
> this to so please forward as necessary.

What is exactly your question concerning licenses?

> Another topic that I missed was, why did kgi fail and what can we do to avoid
> repeating the same path this time around.

KGI failed to be accepted by linus/linux. You surely don't want repeating this ;)
Otherwise, its design is still valid, I believe.

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> > Another topic that I missed was, why did kgi fail and what can we do to avoid
> > repeating the same path this time around.
> 
> IIRC, the main reasons were:
>   - GGI wanted to do too much at once and was too intruisive (conclusion:
>     always advance in small steps, not big leaps):
>       o kernel graphics drivers (KGI)
>       o new input subsystem (similar to what we're heading to now)
>       o user space library (libggi, AFAIK the only part that's still alive)
>   - fbdev was better in multi-platform handling (m68k -> PPC -> ia32 -> SPARC
>     -> alpha -> ...)
> 
> Please correct me if I'm wrong ;-)

The KGI is way to complex. I attempted to write a driver using that system 
but I was totally lost. Fbdev, especially now is much easier to develope.
The input system we have is very similiar to what they had. I'm really 
glad we have a input system. As for the library. Well it has always been 
a dream to have a universal library by many people. It never happened and 
never will happen. When it comes it libraries you have issues like 
licenses and people fighting 




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> What is exactly your question concerning licenses?
> 
> > Another topic that I missed was, why did kgi fail and what can we do to avoid
> > repeating the same path this time around.
> 
> KGI failed to be accepted by linus/linux. You surely don't want repeating 
> this ;) Otherwise, its design is still valid, I believe.

My only complaint about KGI was the driver api was way to complex. I 
believe that one of the BSD use it. I forgot which one. The idea of only 
universal library never happened. Never will.





-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Nicolas Souchu]

On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
> --- Nicolas Souchu <nsouch@free.fr> wrote:
> > > A major topic that I missed in the original list was how to handle BSD. DRM
> > > is under the BSD license and FB is GPL. If these two code bases are merged,
> > > what are we going to do about BSD? I don't know the appropriate BSD lists 
> > > to post this to so please forward as necessary.
> > 
> > What is exactly your question concerning licenses?
> 
> FB is GPL licensed. DRM is BSD licensed. If FB and DRM are merged the end result
> will be GPL licensed code because of the way the licenses work. To change that
> you would have to get permission from every FB contributor to relicense their
> contribution from GPL to BSD. I suspect that it is pratically impossible to
> track all of the FB contributors down and what do you do if some won't
> cooperate? If the FB/DRM combo is GPL it can't be merged back into the BSD
> kernels. What we could do is build a merged driver and continue to have some of
> the source files licensed BSD and some GPL.

But who cares? Do you really intend to keep a common BSD and Linux API/code base?
Offering both solutions under BSD and GPL would be good for suggesting correct
license usage in the embedded world. GPL is too often bypassed.

> The big reason for merging is memory management. If FB supports multiple heads
> it is forced into doing memory management. DRI has memory management needs that
> go far beyond what FB needs so a merged system has to use DRM memory management.
> Ian has made proposals on how to do this and he is working on improving them. 

What is best? Bring modesetting to DRM or memory management to FB?

> BenH and others have made proposals for pushing the mode setting code into a
> user space library in order to reduce kernel footprint and ease debugging. Most
> of the code needed for this library already exists in the current Linux FB
> drivers. I'm not sure if this could be relicensed BSD when it is moved to user
> space.

One advantage of true graphic drivers (opposed to VESA or more generally bios modes)
is that they can boot some archs in graphic mode (no text mode) without bios.
Exactly what linuxfb was originaly designed to. How do you perform this from userspace?

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
http://www.freebsd.org/~nsouch/kgi4BSD


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Jon Smirl]

--- James Simmons <jsimmons@infradead.org> wrote:
> 2) Ben suggestion that we mount userland inside the kernel during early 
>    boot and use a userland library. If we would use a library then it MUST 
>    be OpenGL. This would be the forced standard on all platforms. This 
>    would mean Mesa would be needed to build the kernel. We could move over 
>    Mesa into the kernel like zlib is in the tree right now.

It is not true that it must be OpenGL. The suggestion is for an independent
library that would support mode setting and cursor control. Actually OpenGL does
not specify an API for these things, we would need to develop one.

But broader issues are at work. Microsoft has decided to recode all graphics in
Longhorn to use Direct3D. This was done to get at the performance gains provided
by D3D and hardware accelerated graphics. For example a Cairo implementation hat
uses X rendering vs Cairo on OpenGL was benchmarked at being a 100:1 faster.

A proposal has been made that OpenGL be promoted as the primary base graphics
API on Linux. Then things like Cairo and the xserver be implemented on top of
OpenGL.

1) OpenGL is the only fully accelerated API that Linux has. We don't have D3D or
anything else like it. Fully accelerated interfaces are a pain to build and it
would stupid to do another one.

2) OpenGL is extremely well documented. Just go to your local book store and you
can buy a manual for it. It is available on Linux, Mac, Windows, Solaris, etc.
Colleges teach classes on how to use it.

3) It is a high level interface, the framebuffer interface is way too low level
and is mostly impossible to accelerate. Only about half of OpenGL is currently
accelerated, over the next two or three chip generations it will probably become
100% accelerated. Using OpenGL as the API allows these features to be integrated
into hardware without disrupting the apps.

4) It makes life easy for Nvidia and ATI. This is actually an important one if
you want to use the latest hardware. Even though we don't like it this design
makes it easy to releaese a monolithic blob that only exposes the OpenGL API.

5) Don't think of this as 2D vs 3D. xserver and Cairo only use the 2D features
of OpenGL. Think of this as accelerated coprocessor vs programmed IO.

6) What about low memory embedded systems? mesa has an excellent implementation
of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already
supports running out of a dumb framebuffer. OpenGL-ES is small enough that
Qualcomm is putting it into phones. Of course you can always ignore the GUI
standard and do what you want in an embedded system.

7) Going to OpenGL does not mean the end of X or remote access. xserver,
http://www.freedesktop.org/Software/xserver, still talks the X protocol and
still supports xlib. It just uses OpenGL (when Keith gets it working) to draw
instead of XAA. If you use Glitz, http://www.freedesktop.org/Software/glitz, the
OpenGL Cairo implementation, it will draw direct rendered and by-pass the
xserver for local drawing.

8) If we don't get our act together soon, Longhorn is going to kick Linux's butt
on the desktop. Go look at some of the demos if you don't believe this.
http://www.osnews.com/topic.php?icon=37

Longhorn's Real Job: Trying to Gore Linux 
http://www.eweek.com/article2/0,1759,1580477,00.asp?kc=ewnws043004dtx1k0000599


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Keith Packard]

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


Around 17 o'clock on May 6, Jon Smirl wrote:

> A proposal has been made that OpenGL be promoted as the primary base graphics
> API on Linux. Then things like Cairo and the xserver be implemented on top of
> OpenGL.

I respectfully disagree with this plan.  OpenGL should be the sole API for 
accessing the graphics card for systems which support it, but I encourage 
application developers to continue coding to the X API so that there 
aren't unexpected "surprises" when run on a machine which doesn't support 
OpenGL.

That the X server will use OpenGL to talk to these graphics cards is an 
implementation detail which shouldn't be visible to applications.

-keith



[-- Attachment #2: Type: application/pgp-signature, Size: 228 bytes --]

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Jon Smirl]

--- Keith Packard <keithp@keithp.com> wrote:
> 
> Around 17 o'clock on May 6, Jon Smirl wrote:
> 
> > A proposal has been made that OpenGL be promoted as the primary base
> graphics
> > API on Linux. Then things like Cairo and the xserver be implemented on top
> of
> > OpenGL.
> 
> I respectfully disagree with this plan.  OpenGL should be the sole API for 
> accessing the graphics card for systems which support it, but I encourage 
> application developers to continue coding to the X API so that there 
> aren't unexpected "surprises" when run on a machine which doesn't support 
> OpenGL.
> 
> That the X server will use OpenGL to talk to these graphics cards is an 
> implementation detail which shouldn't be visible to applications.
> 

Read point #7

7) Going to OpenGL does not mean the end of X or remote access. xserver,
http://www.freedesktop.org/Software/xserver, still talks the X protocol and
still supports xlib. It just uses OpenGL (when Keith gets it working) to draw
instead of XAA. If you use Glitz, http://www.freedesktop.org/Software/glitz, the
OpenGL Cairo implementation, it will draw direct rendered and by-pass the
xserver for local drawing.


> -keith
> 
> 
> 

> ATTACHMENT part 2 application/pgp-signature 



=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Geert Uytterhoeven]

On Fri, 7 May 2004, Nicolas Souchu wrote:
> On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
> > BenH and others have made proposals for pushing the mode setting code into a
> > user space library in order to reduce kernel footprint and ease debugging. Most
> > of the code needed for this library already exists in the current Linux FB
> > drivers. I'm not sure if this could be relicensed BSD when it is moved to user
> > space.
>
> One advantage of true graphic drivers (opposed to VESA or more generally bios modes)
> is that they can boot some archs in graphic mode (no text mode) without bios.
> Exactly what linuxfb was originaly designed to. How do you perform this from userspace?

Note that this is `early userspace', in initramfs. Graphics would be
initialized a bit later than today, but (hopefully) still sufficiently early.

Even right now fbcon is initialized later than vgacon, because we need bus
probing before we can detect graphics cards.

If you really need kernel messages earlier, you have to fallback to vgacon
(ugh), a serial console, or an early boot console (like PPC BTEXT).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Geert Uytterhoeven]

On Thu, 6 May 2004, Jon Smirl wrote:
> 6) What about low memory embedded systems? mesa has an excellent implementation
> of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already
> supports running out of a dumb framebuffer. OpenGL-ES is small enough that
> Qualcomm is putting it into phones. Of course you can always ignore the GUI
> standard and do what you want in an embedded system.

What about performance on older systems? Current new embedded CE may be much
faster than an average PC from a few years ago.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Benjamin Herrenschmidt]

> 1) Keep mode switching in the kernel. Merge DRI and fb together via 
>    sysfs interface.
> 
> 2) Ben suggestion that we mount userland inside the kernel during early 
>    boot and use a userland library. If we would use a library then it MUST 
>    be OpenGL. This would be the forced standard on all platforms. This 
>    would mean Mesa would be needed to build the kernel. We could move over 
>    Mesa into the kernel like zlib is in the tree right now.

You are mixing things. Mode setting has nothing to do with rendering. OpenGL
is a rendering client. It produces commands sent to the low level kernel
driver and provides a 3D API, but it's not the only one. In this regard,
fbcon is a client too and XFree 2D accel is another one.

What I was proposing was a library that managed the desktop environment,
not involved in any rendering activities. The main reason why I halted my
work on this (except for lack of time) is that I figured out that there
were big issues to solve first about memory management of the framebuffer,
dealing with ownership of fb regions, ability to ask client to "evict"
their data (when a new mode requires a larger space) etc...

Ben.
 



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Redesign of kernel graphics interface

[Egbert Eich]

Jon Smirl writes:
 > At the X Developers Conference there was a discussion of the issues around
 > framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
 > discussion. I'm going to try and list all of the issues I've heard from all
 > sides so some of the proposed solutions are in conflict. The goal of this list
 > is to provide direction for a topic discussion at the Ottawa Kernel Summit.
 > 
 > The top item is that accessing the video hardware is a free for all. There are
 > two device drivers, FB and DRI, plus numerous user space apps, like X and
 > SVGlib, all trying to control the hardware. The result of this is that it is
 > easy to lock up your machine when switching between the different usages. X does
 > particularly nasty things to the hardware from user space without informing the
 > kernel.

Here it should be looked at why this is the case.

 > 
 > First is a little background that should have been in my original post:
 > http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000399.html
 > 
 > Next is the orginal post:
 > http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000379.html
 > 
 > The reply thread on the kernel summit list is here:
 > http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/thread.html
 > 
 > Some talk about doing a better video memory manager and kgi is here:
 > http://marc.theaimsgroup.com/?l=dri-devel&r=1&b=200405&w=2
 > 
 > A major topic that I missed in the original list was how to handle BSD. DRM is
 > under the BSD license and FB is GPL. If these two code bases are merged, what
 > are we going to do about BSD? I don't know the appropriate BSD lists to post
 > this to so please forward as necessary.

The problem is bigger than that. There are other OSes that take advantage of
the mode initialization code in X. Those people don't have their own mailing
lists but exchange informations on those of the X projects. Most of them
should be active on the XFree86 lists.

 > 
 > Another topic that I missed was, why did kgi fail and what can we do to avoid
 > repeating the same path this time around.
 > 
 > After the flames from this settle down I'll try to write a document summarizing
 > the conclusions reached, if any. The best possible outcome would be a design
 > document for review at Kernel Summit.
 > 

There are many considerations from the XFree86/X.Org Xserver side that people
here may only be marginally aware of. After all, these people were those who
were involved with some of the issues the most in the past.
It would be useful to give those people a chance to state their views, too.

Egbert.





-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> is a rendering client. It produces commands sent to the low level kernel
> driver and provides a 3D API, but it's not the only one. In this regard,
> fbcon is a client too and XFree 2D accel is another one.

But we are rendering to draw fonts, clearing a area of the screen,copyarea.
If we are to have a universal solution it needs to OpenGL. Either that or 
mode switching stays in the kernel.  

Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be 
moved to userspace. The networking code alone is over 17 megs in size. 
Bloat bloat bloat. 



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Ville Syrjälä]

On Mon, May 10, 2004 at 05:14:04PM +0100, James Simmons wrote:
> 
> > You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> > is a rendering client. It produces commands sent to the low level kernel
> > driver and provides a 3D API, but it's not the only one. In this regard,
> > fbcon is a client too and XFree 2D accel is another one.
> 
> But we are rendering to draw fonts, clearing a area of the screen,copyarea.
> If we are to have a universal solution it needs to OpenGL. Either that or 
> mode switching stays in the kernel.  

Rendering and mode switching are completely separate issues.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Jon Smirl]

It's not just bloat, the network code is used millions of times per second. Mode
setting happens occaisonally. 

The other problem is memory management. What is going to happen when fbdev
starts setting the mode for both heads? Who is going to mananage the VRAM when
the buffers get resized? OpenGL has a very complex memory management scheme
where things can migrate from VRAM to AGP to system memory.

--- James Simmons <jsimmons@infradead.org> wrote:
> 
> > You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> > is a rendering client. It produces commands sent to the low level kernel
> > driver and provides a 3D API, but it's not the only one. In this regard,
> > fbcon is a client too and XFree 2D accel is another one.
> 
> But we are rendering to draw fonts, clearing a area of the screen,copyarea.
> If we are to have a universal solution it needs to OpenGL. Either that or 
> mode switching stays in the kernel.  
> 
> Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be 
> moved to userspace. The networking code alone is over 17 megs in size. 
> Bloat bloat bloat. 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Mike Mestnik]

I could be wrong, but is not allocating framebuffers and mmaping memory
diffrent than setting up framebuffers and configuring DACs?

--- Jon Smirl <jonsmirl@yahoo.com> wrote:
> It's not just bloat, the network code is used millions of times per
> second. Mode
> setting happens occaisonally. 
> 
> The other problem is memory management. What is going to happen when
> fbdev
> starts setting the mode for both heads? Who is going to mananage the
> VRAM when
> the buffers get resized? OpenGL has a very complex memory management
> scheme
> where things can migrate from VRAM to AGP to system memory.
> 
> --- James Simmons <jsimmons@infradead.org> wrote:
> > 
> > > You are mixing things. Mode setting has nothing to do with
> rendering. OpenGL
> > > is a rendering client. It produces commands sent to the low level
> kernel
> > > driver and provides a 3D API, but it's not the only one. In this
> regard,
> > > fbcon is a client too and XFree 2D accel is another one.
> > 
> > But we are rendering to draw fonts, clearing a area of the
> screen,copyarea.
> > If we are to have a universal solution it needs to OpenGL. Either that
> or 
> > mode switching stays in the kernel.  
> > 
> > Speaking of bloat in the kernel. When will the crypto and TCP/IP stack
> be 
> > moved to userspace. The networking code alone is over 17 megs in size.
> 
> > Bloat bloat bloat. 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> > deliver higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > _______________________________________________
> > Mesa3d-dev mailing list
> > Mesa3d-dev@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 
> =====
> Jon Smirl
> jonsmirl@yahoo.com
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs  
> http://hotjobs.sweepstakes.yahoo.com/careermakeover 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Alan Cox]

On Llu, 2004-05-10 at 17:14, James Simmons wrote:
> Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be 
> moved to userspace. The networking code alone is over 17 megs in size. 

Not on my box. Nothing like it. Although to answer that question with a
definitive example ELKS (a Linux like 8086 kernel in 64K) has IP demux
in kernel space and tcp in user space. The v7 NCP stack also had much of
the protocol in user space.

So its a perfectly valid argument to build such hybrid systems for
display management too



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Otto Solares]

On Mon, May 10, 2004 at 10:39:50PM +0000, Nicolas Souchu wrote:
> Do apps manage their swap? No. I think the OS should be responsible for
> placing the data (vertices, textures, commands) at the right/best place
> for the HW 3D engine and the client should only fill virtual memory.

> http://www.freebsd.org/~nsouch/kgi4BSD

Browsing through kgi.sf.net I found that they have proper multihead
and DDC2 support.  They just lack DRI integrated into KGI and it will
rock from my user perspective.

Is true that the BSDs are adopting KGI as their unified kernel
graphics layer?

-otto



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> It's not just bloat, the network code is used millions of times per second. 
> Mode setting happens occaisonally. 
 
Using that logic then Sound cards shouldn't be in the kernel at all. I 
never use my sound card continuely. I use it as a module. Would it be 
acceptable if the mode setting was modular?  

> The other problem is memory management. What is going to happen when fbdev
> starts setting the mode for both heads? Who is going to mananage the VRAM when
> the buffers get resized? OpenGL has a very complex memory management scheme
> where things can migrate from VRAM to AGP to system memory.

I know problems like this are going to exist. So I guess the idea of the 
kernel supporting multi-desktops is out then. The ruby (linuxconsole) 
project has two independent workstations running on the G400 dual head 
cards. I guess that has to go :-( 




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Nicolas Souchu]

On Mon, May 10, 2004 at 11:29:40AM -0700, Jon Smirl wrote:
> It's not just bloat, the network code is used millions of times per second. Mode
> setting happens occaisonally. 

But necessary some times. I think of oops and debugger.

> The other problem is memory management. What is going to happen when fbdev
> starts setting the mode for both heads? Who is going to mananage the VRAM when
> the buffers get resized? OpenGL has a very complex memory management scheme
> where things can migrate from VRAM to AGP to system memory.

Do apps manage their swap? No. I think the OS should be responsible for
placing the data (vertices, textures, commands) at the right/best place
for the HW 3D engine and the client should only fill virtual memory.

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
http://www.freebsd.org/~nsouch/kgi4BSD


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Nicolas Souchu]

On Mon, May 10, 2004 at 07:28:37PM +0300, Ville Syrjälä wrote:
[...]
> 
> Rendering and mode switching are completely separate issues.

Indeed and I guess we can even use the VESA mode setting and the HW
engine of recent graphic boards "concurrently".

The console system is responsible for modesetting regarding the
needs of text apps vs graphic apps vs kernel and the current focus.

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
http://www.freebsd.org/~nsouch/kgi4BSD


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Benjamin Herrenschmidt]

On Tue, 2004-05-11 at 02:14, James Simmons wrote:
> > You are mixing things. Mode setting has nothing to do with rendering. OpenGL
> > is a rendering client. It produces commands sent to the low level kernel
> > driver and provides a 3D API, but it's not the only one. In this regard,
> > fbcon is a client too and XFree 2D accel is another one.
> 
> But we are rendering to draw fonts, clearing a area of the screen,copyarea.
> If we are to have a universal solution it needs to OpenGL. Either that or 
> mode switching stays in the kernel.  

Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me
that you can't make the difference between fbdev and fbcon now ;)

> Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be 
> moved to userspace. The networking code alone is over 17 megs in size. 
> Bloat bloat bloat. 

That has nothing to do with it. If you don't agree, come to KS or OLS
and talk to Linus. Your arguments & comparisons are pointless

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> > But we are rendering to draw fonts, clearing a area of the screen,copyarea.
> > If we are to have a universal solution it needs to OpenGL. Either that or 
> > mode switching stays in the kernel.  
> 
> Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me
> that you can't make the difference between fbdev and fbcon now ;)

That is not what I'm saying. I'm sayimng we could use opengl to draw the 
fonts in fbcon. Opengl coudl be the center piece library that does 
everything. 

> > Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be 
> > moved to userspace. The networking code alone is over 17 megs in size. 
> > Bloat bloat bloat. 
> 
> That has nothing to do with it. If you don't agree, come to KS or OLS
> and talk to Linus. Your arguments & comparisons are pointless

I think I'm going to have to.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[James Simmons]

> On Mon, May 10, 2004 at 10:39:50PM +0000, Nicolas Souchu wrote:
> > Do apps manage their swap? No. I think the OS should be responsible for
> > placing the data (vertices, textures, commands) at the right/best place
> > for the HW 3D engine and the client should only fill virtual memory.
> 
> > http://www.freebsd.org/~nsouch/kgi4BSD
> 
> Browsing through kgi.sf.net I found that they have proper multihead
> and DDC2 support.  They just lack DRI integrated into KGI and it will
> rock from my user perspective.
> 
> Is true that the BSDs are adopting KGI as their unified kernel
> graphics layer?

It looks like BSD is heading in the right direction. If this lame idea of 
a userland library goes threw I wil quite fbdev developement and go over 
to BSD then. Either that or fork the tree and start my company with my 
work.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Geert Uytterhoeven]

On Mon, 10 May 2004, Alan Cox wrote:
> On Llu, 2004-05-10 at 17:14, James Simmons wrote:
> > Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
> > moved to userspace. The networking code alone is over 17 megs in size.
>
> Not on my box. Nothing like it. Although to answer that question with a
> definitive example ELKS (a Linux like 8086 kernel in 64K) has IP demux
> in kernel space and tcp in user space. The v7 NCP stack also had much of
> the protocol in user space.

Sounds reasonable, since IP demux touches the hardware, and TCP not.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Redesign of kernel graphics interface

[Otto Solares]

On Tue, May 11, 2004 at 10:57:11PM +0000, Nicolas Souchu wrote:
> On Mon, May 10, 2004 at 02:47:42PM -0600, Otto Solares wrote:
> 
> > They just lack DRI integrated into KGI and it will
> > rock from my user perspective.
> 
> It's not DRI but GGI+KGI accel resource management. Mesa can work
> with GGI backend (the code has to be refreshed though).

Mesa's GGI backend was software only last time I check, I mean
hardware acceleration into mesa via KGI+DRI would be nice,
something like linux-solo but instead of the fbdev using the
KGI layer.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Redesign of kernel graphics interface

[Ville Syrjälä]

On Tue, May 11, 2004 at 10:57:11PM +0000, Nicolas Souchu wrote:
> On Mon, May 10, 2004 at 02:47:42PM -0600, Otto Solares wrote:
> > On Mon, May 10, 2004 at 10:39:50PM +0000, Nicolas Souchu wrote:
> > > Do apps manage their swap? No. I think the OS should be responsible for
> > > placing the data (vertices, textures, commands) at the right/best place
> > > for the HW 3D engine and the client should only fill virtual memory.
> > 
> > > http://www.freebsd.org/~nsouch/kgi4BSD
> > 
> > Browsing through kgi.sf.net I found that they have proper multihead
> > and DDC2 support.
> 
> True.

What does proper multihead mean here? If it means multihead with separate 
framebuffers it doesn't seem much better than fbdev. Proper multihead with 
shared framebuffer is a lot harder get right. It would need video memory 
management in the kernel.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Compiling Rage xlinit.c

[Richard Smith]

How does one get the rage xlinit stuff to work.  I've enabled it in my 
kernel build but it dosen't seem to be compiled and I don't see in the 
Makefile any attempt to compile it.

Does this get built for x86?

Any anycase my attempt to compile it yeild an structure member dosen't 
exist for pll->sclk_fb_div.  Checking the def for struct pll_ct shows 
that sclk_fb_div is not a member of pll_ct.  So I don't see how this 
would ever compile.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Redesign of kernel graphics interface

[Nicolas Souchu]

On Mon, May 10, 2004 at 02:47:42PM -0600, Otto Solares wrote:
> On Mon, May 10, 2004 at 10:39:50PM +0000, Nicolas Souchu wrote:
> > Do apps manage their swap? No. I think the OS should be responsible for
> > placing the data (vertices, textures, commands) at the right/best place
> > for the HW 3D engine and the client should only fill virtual memory.
> 
> > http://www.freebsd.org/~nsouch/kgi4BSD
> 
> Browsing through kgi.sf.net I found that they have proper multihead
> and DDC2 support.

True.

> They just lack DRI integrated into KGI and it will
> rock from my user perspective.

It's not DRI but GGI+KGI accel resource management. Mesa can work
with GGI backend (the code has to be refreshed though).

> Is true that the BSDs are adopting KGI as their unified kernel
> graphics layer?

It's a project, yes.

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
http://www.freebsd.org/~nsouch/kgi4BSD


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Sven Luther]

On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
> --- James Simmons <jsimmons@infradead.org> wrote:
> > 2) Ben suggestion that we mount userland inside the kernel during early 
> >    boot and use a userland library. If we would use a library then it MUST 
> >    be OpenGL. This would be the forced standard on all platforms. This 
> >    would mean Mesa would be needed to build the kernel. We could move over 
> >    Mesa into the kernel like zlib is in the tree right now.
> 
> It is not true that it must be OpenGL. The suggestion is for an independent
> library that would support mode setting and cursor control. Actually OpenGL does
> not specify an API for these things, we would need to develop one.
> 
> But broader issues are at work. Microsoft has decided to recode all graphics in
> Longhorn to use Direct3D. This was done to get at the performance gains provided
> by D3D and hardware accelerated graphics. For example a Cairo implementation hat
> uses X rendering vs Cairo on OpenGL was benchmarked at being a 100:1 faster.
> 
> A proposal has been made that OpenGL be promoted as the primary base graphics
> API on Linux. Then things like Cairo and the xserver be implemented on top of
> OpenGL.
> 
> 1) OpenGL is the only fully accelerated API that Linux has. We don't have D3D or
> anything else like it. Fully accelerated interfaces are a pain to build and it
> would stupid to do another one.

Notice that this is not really true, as there is no free OpenGL
acceleration for any of the newer graphic cards coming out right now.
The fastest graphic card with full free acceleration is the radeon 9000,
which is now two generations old. This means that there is no
acceleration outside of the x86 world, since neither ATI nor Nvidia are
ready to build their proprietary drivers on anything else than x86. 

As long as this doesn't change, stating that we have an accelerated API
for OpenGL in linux is not only dead wrong, but is leading us in a
dangerous direction, where we will depend on a non-free component in the
kernel and were we are going to forget about graphic support on anything
non-x86.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Alex Deucher]

--- Sven Luther <sven.luther@wanadoo.fr> wrote:
> On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
> > --- James Simmons <jsimmons@infradead.org> wrote:
> > > 2) Ben suggestion that we mount userland inside the kernel during
> early 
> > >    boot and use a userland library. If we would use a library
> then it MUST 
> > >    be OpenGL. This would be the forced standard on all platforms.
> This 
> > >    would mean Mesa would be needed to build the kernel. We could
> move over 
> > >    Mesa into the kernel like zlib is in the tree right now.
> > 
> > It is not true that it must be OpenGL. The suggestion is for an
> independent
> > library that would support mode setting and cursor control.
> Actually OpenGL does
> > not specify an API for these things, we would need to develop one.
> > 
> > But broader issues are at work. Microsoft has decided to recode all
> graphics in
> > Longhorn to use Direct3D. This was done to get at the performance
> gains provided
> > by D3D and hardware accelerated graphics. For example a Cairo
> implementation hat
> > uses X rendering vs Cairo on OpenGL was benchmarked at being a
> 100:1 faster.
> > 
> > A proposal has been made that OpenGL be promoted as the primary
> base graphics
> > API on Linux. Then things like Cairo and the xserver be implemented
> on top of
> > OpenGL.
> > 
> > 1) OpenGL is the only fully accelerated API that Linux has. We
> don't have D3D or
> > anything else like it. Fully accelerated interfaces are a pain to
> build and it
> > would stupid to do another one.
> 
> Notice that this is not really true, as there is no free OpenGL
> acceleration for any of the newer graphic cards coming out right now.
> The fastest graphic card with full free acceleration is the radeon
> 9000,
> which is now two generations old. This means that there is no
> acceleration outside of the x86 world, since neither ATI nor Nvidia
> are
> ready to build their proprietary drivers on anything else than x86. 
> 

There is the possiblity that graphics vendors may provide an open
source DRM and mode setting code and then closed source 3D libraries. 
this would at least allow you to at least get something on the screen. 

> As long as this doesn't change, stating that we have an accelerated
> API
> for OpenGL in linux is not only dead wrong, but is leading us in a
> dangerous direction, where we will depend on a non-free component in
> the
> kernel and were we are going to forget about graphic support on
> anything
> non-x86.

well what should we do then?  ignore graphics on linux since most
future graphics chips drivers closed source?  keep the same kludgey
xfree86 solution?  We can still provide a solution for non-x86 or chips
without 3D, it will just have to be software based (or marginally
accelerated using 2d). why re-invent openGL when we already have it? 
If we can provide a good system for graphics on linux perhaps more
vendors will use it.

Alex

> 
> Friendly,
> 
> Sven Luther
> 
> 



	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Jon Smirl]

Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
based) graphics.
http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
Within one or two generations the 2D box is going to be gone.

If Linux wants to stay current with technology we have to start using the
coprocessor features of the GPU. Most of the benchmarks I have seen show
coprocessor vs programmed at 100:1 speed differential. This is also a
competitive problem, Microsoft and Apple have both decided to go with the GPU
coprocessor this year. 

Lack of free drivers is no reason to ignore the GPU coprocessor. It just means
more effort needs to be put into mesa and prying the docs out of the graphics
chip vendors. If the current open drivers don't work on a non-x86 platform just
go fix them. All of the necessary data is available. Progress is being made with
ATI for getting the R300 specs now that the R400 series has shipped.

--- Sven Luther <sven.luther@wanadoo.fr> wrote:
> As long as this doesn't change, stating that we have an accelerated API
> for OpenGL in linux is not only dead wrong, but is leading us in a
> dangerous direction, where we will depend on a non-free component in the
> kernel and were we are going to forget about graphic support on anything
> non-x86.

I said OpenGL is the only accelerated API available on Linux. Can you name
another? There is a little acceleration in framebuffer, but I don't know of any
others. Also, software mesa works just fine to provide OpenGL on dumb 2D cards.

You have to choose. Either we stay with programmed IO and low speed 2D graphics
forever or we have to embrace the GPU coprocessor. No one is going to make you
buy a high end ATI or Nvidia card. But if you want to use one you have to deal
with the realities of the situation. ATI and Nvidia own their technology and if
they don't want to open it all we can do is complain to them or use their
proprietary drivers. 

If being free is critical to you then you won't be using any high graphics
cards. Stick with an R200 or less type card. Your system will work fine with the
OpenGL based xserver. But graphics cards are evolving and Linux can't ignore
them. We just have to hope that Nvidia and API can see the light someday and
open their specs.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Ville Syrjälä]

On Fri, May 14, 2004 at 10:51:35AM -0700, Jon Smirl wrote:
> Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
> based) graphics.
> http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
> Within one or two generations the 2D box is going to be gone.
> 
> If Linux wants to stay current with technology we have to start using the
> coprocessor features of the GPU. Most of the benchmarks I have seen show
> coprocessor vs programmed at 100:1 speed differential. This is also a
> competitive problem, Microsoft and Apple have both decided to go with the GPU
> coprocessor this year. 

I don't understand you GPU vs. PIO comparisons. You can use the 2D engine 
with DMA as well. And at least with older cards the 2D engine is clearly 
faster than the 3D engine (~100% faster for blits on my G400) so trying to 
bypass it is just stupid.

> I said OpenGL is the only accelerated API available on Linux. Can you name
> another?

DirectFB.

> There is a little acceleration in framebuffer, but I don't know of any
> others. Also, software mesa works just fine to provide OpenGL on dumb 2D cards.

Using unaccelerated OpenGL for 2D rendering doesn't sound exatly useful. 

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Ville Syrjälä]

On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
> --- Ville Syrjälä <syrjala@sci.fi> wrote:
> > > I said OpenGL is the only accelerated API available on Linux. Can you name
> > > another?
> > 
> > DirectFB.
> 
> Does DirectFB work on anything beside Matrox now?

It works on any card with a working fbdev driver (vga16fb excluded). 
Hardware acceleration is available on quite a few chips these days.

ati128  cyber5k  mach64  neomagic  nvidia  savage  tdfx
cle266  i810     matrox  nsc       radeon  sis315

That's the list of drivers in DirectFB cvs. Plus there is at least one 
driver outside the DirectFB tree.

I use matrox and mach64 drivers daily. It's been a few years since I 
seriously used XFree86.

> > > There is a little acceleration in framebuffer, but I don't know of any
> > > others. Also, software mesa works just fine to provide OpenGL on dumb 2D
> > cards.
> > 
> > Using unaccelerated OpenGL for 2D rendering doesn't sound exatly useful. 
> 
> There is much more to 2D rendering in things like the Mac UI and Longhorn than
> can be accomplished with BitBlt. You need transforms, filters and alpha
> blending. Hardware texturing is much faster than doing it in software. Some of
> the effects are achieved with pixel shaders. xserver features a fully composited
> window manager, it needs these features to have a fast response time.
> 
> OpenGL to me seems like the best pick for these reasons:
> 1) with have a good open source version, mesa
> 2) mesa supports a broad number of cards, basically everything there is doc for

Just about as broad as DirectFB.

> 3) OpenGL is a well published API, it is taught in universities and many books
> are available
> 4) It is likely that Nvidia and ATI will support standalone OpenGL stacks for
> their high end hardware on Linux
> 5) OpenGL is cross-platform. For example Cairo is being written with an OpenGL
> back end. OpenGL Cairo will run on Window and the Mac too. This will make Linux
> apps more portable.
> 6) The embedded market has OpenGL-ES which can run in less than 100K.
> 
> What would be reasons for picking another API?

DirectFB is good for a few reasons:
- Input handling
- Easy access to hardware overlays
- YUV formats
- Ease of porting DirectX applications
- Good acceleration
- Easy API / personal preference

I'm not suggesting that everyone start using DirectFB. Everyong should be 
able to use any API they want. The kernel should provide just enough to 
allow these APIs to be implemented.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Sven Luther]

On Fri, May 14, 2004 at 10:35:56AM -0700, Alex Deucher wrote:
> > Notice that this is not really true, as there is no free OpenGL
> > acceleration for any of the newer graphic cards coming out right now.
> > The fastest graphic card with full free acceleration is the radeon
> > 9000,
> > which is now two generations old. This means that there is no
> > acceleration outside of the x86 world, since neither ATI nor Nvidia
> > are
> > ready to build their proprietary drivers on anything else than x86. 
> > 
> 
> There is the possiblity that graphics vendors may provide an open
> source DRM and mode setting code and then closed source 3D libraries. 
> this would at least allow you to at least get something on the screen. 

Yes, that would be greatm but i have the feeling that they even see the
dma buffer handling stuff as highly proprietary or something such.

> > As long as this doesn't change, stating that we have an accelerated
> > API
> > for OpenGL in linux is not only dead wrong, but is leading us in a
> > dangerous direction, where we will depend on a non-free component in
> > the
> > kernel and were we are going to forget about graphic support on
> > anything
> > non-x86.
> 
> well what should we do then?  ignore graphics on linux since most

Well, what to do is a difficult thing, but the least we can do is not
handle this as if everything is all right, and let declaration as the
above pass without notice. Technically, it can even be argued that the
binary-only drm modules are breaking the GPL, altough i know that Linus
and the rest of the kernel crowd have decided not to pursue this.

So, pursue this issue as we are doing it, but clearly stating that the
current situation without free low level drivers is not acceptable to
us. I believe that we are now in a position to put some pressure to at
least some of the graphic companies to release at least a partial
integrated drm/fbdev module as free software, but this will not happen
if we don push for it. (But then, i have a vested interest in this,
since my main plateform is powerpc, both personally and proffesionnaly).

> future graphics chips drivers closed source?  keep the same kludgey
> xfree86 solution?  We can still provide a solution for non-x86 or chips
> without 3D, it will just have to be software based (or marginally
> accelerated using 2d). why re-invent openGL when we already have it? 
> If we can provide a good system for graphics on linux perhaps more
> vendors will use it.

Yes, but only if we don forget about non-x86 architectures, and don't
conform us with a proprietary solution. Remember that many folk build
the fbdev driver in the kernel to have early fbdev console, and this
will not be possible with a x86 binary only module.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Sven Luther]

On Fri, May 14, 2004 at 10:51:35AM -0700, Jon Smirl wrote:
> Just look at this picture and you can see the trend of 2D vs 3D (coprocessor
> based) graphics.
> http://www.de.tomshardware.com/graphic/20040504/images/architecture.gif
> Within one or two generations the 2D box is going to be gone.

Sorry, but i am not able to see this over the remote link i am having
now, i will look at it more in detail when i am back home on sunday.

> If Linux wants to stay current with technology we have to start using the
> coprocessor features of the GPU. Most of the benchmarks I have seen show
> coprocessor vs programmed at 100:1 speed differential. This is also a
> competitive problem, Microsoft and Apple have both decided to go with the GPU
> coprocessor this year. 

Fine with me, i believe that this is also the way to go, but saddly
this is probably not going to happen unless we put some pressure on the
graphic companies, and i somehow doubt that nvidia will go with it. I
only wanted to raise the problematic, so we don forget about where we
come from, and create a framework which would depend on non-free parts.

> Lack of free drivers is no reason to ignore the GPU coprocessor. It just means

Well, it probably means nonaccelerated drivers, if even that.

> more effort needs to be put into mesa and prying the docs out of the graphics
> chip vendors. If the current open drivers don't work on a non-x86 platform just
> go fix them. All of the necessary data is available. Progress is being made with
> ATI for getting the R300 specs now that the R400 series has shipped.
> 

If this is true, then it would be a great new, but still, if you want to
go forward with this plan, we have to get at least a partial
functionality open source drm/fbdev module for even the newer model of
graphic cards, and even from players like nvidia. They can hide all
their stuff in proprietary userland libraries afterward still, but the
right thing would be to have this integrated kernel driver be a real
GPLed driver, with source and all.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Richard Smith]

Richard Smith wrote:

> How does one get the rage xlinit stuff to work.  I've enabled it in my 
> kernel build but it dosen't seem to be compiled and I don't see in the 
> Makefile any attempt to compile it.
> 

Nobody responed to this.  Theres no way xlinit.c would have compiled.

Is it still maintained?

stevel@mvista.com is listed at the original author.




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Steve Longerbeam]

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



Richard Smith wrote:

> Richard Smith wrote:
>
>> How does one get the rage xlinit stuff to work.  I've enabled it in 
>> my kernel build but it dosen't seem to be compiled and I don't see in 
>> the Makefile any attempt to compile it.
>>
>
> Nobody responed to this.  Theres no way xlinit.c would have compiled.
>
> Is it still maintained?
>
> stevel@mvista.com is listed at the original author. 


Hi!

What kernel source tree and rev is this? Xlinit.c only supports the
Xpert98 card, nothing else, although it might be a simple matter
to get it working with other RageXL based cards. It has never been
ported to 2.6 either.

 From the above, it sounds as if the original patch got mangled somehow.
I've attached the original patch for 2.4.18.

Steve


[-- Attachment #2: atyfb-xpert98-2.4.18.patch --]
[-- Type: text/plain, Size: 44350 bytes --]

diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/Config.in linux-2.4.18/drivers/video/Config.in
--- linux-2.4.18.orig/drivers/video/Config.in	Thu Mar 28 14:31:54 2002
+++ linux-2.4.18/drivers/video/Config.in	Fri Mar 29 09:58:02 2002
@@ -135,6 +135,9 @@
 	 if [ "$CONFIG_FB_ATY" != "n" ]; then
 	    bool '    Mach64 GX support (EXPERIMENTAL)' CONFIG_FB_ATY_GX
 	    bool '    Mach64 CT/VT/GT/LT (incl. 3D RAGE) support' CONFIG_FB_ATY_CT
+	    if [ "$CONFIG_FB_ATY_CT" != "n" ]; then
+	       bool '    Xpert98 PCI support' CONFIG_FB_XPERT98
+	    fi
 	 fi
  	 tristate '  ATI Radeon display support (EXPERIMENTAL)' CONFIG_FB_RADEON
 	 tristate '  ATI Rage128 display support (EXPERIMENTAL)' CONFIG_FB_ATY128
diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/aty/Makefile linux-2.4.18/drivers/video/aty/Makefile
--- linux-2.4.18.orig/drivers/video/aty/Makefile	Thu Mar 28 14:31:54 2002
+++ linux-2.4.18/drivers/video/aty/Makefile	Fri Mar 29 10:01:31 2002
@@ -6,6 +6,7 @@
 obj-y				:= atyfb_base.o mach64_accel.o
 obj-$(CONFIG_FB_ATY_GX)		+= mach64_gx.o
 obj-$(CONFIG_FB_ATY_CT)		+= mach64_ct.o mach64_cursor.o
+obj-$(CONFIG_FB_XPERT98)	+= xlinit.o
 obj-m				:= $(O_TARGET)
 
 include $(TOPDIR)/Rules.make
diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/aty/atyfb.h linux-2.4.18/drivers/video/aty/atyfb.h
--- linux-2.4.18.orig/drivers/video/aty/atyfb.h	Thu Mar 28 14:31:54 2002
+++ linux-2.4.18/drivers/video/aty/atyfb.h	Fri Mar 29 10:01:31 2002
@@ -43,13 +43,17 @@
     u8 pll_ref_div;
     u8 pll_gen_cntl;
     u8 mclk_fb_div;
+    u8 mclk_fb_mult;    /* 2 or 4 */
+    u8 sclk_fb_div;
     u8 pll_vclk_cntl;
     u8 vclk_post_div;
     u8 vclk_fb_div;
     u8 pll_ext_cntl;
+    u8 spll_cntl2;
     u32 dsp_config;	/* Mach64 GTB DSP */
     u32 dsp_on_off;	/* Mach64 GTB DSP */
     u8 mclk_post_div_real;
+    u8 xclk_post_div_real;
     u8 vclk_post_div_real;
 };
 
@@ -94,6 +98,7 @@
     unsigned long frame_buffer_phys;
     unsigned long frame_buffer;
     unsigned long clk_wr_offset;
+    struct pci_dev *pdev;
     struct pci_mmap_map *mmap_map;
     struct aty_cursor *cursor;
     struct aty_cmap_regs *aty_cmap_regs;
@@ -105,6 +110,7 @@
     u32 ref_clk_per;
     u32 pll_per;
     u32 mclk_per;
+    u32 xclk_per;
     u8 bus_type;
     u8 ram_type;
     u8 mem_refresh_rate;
@@ -163,6 +169,7 @@
 #define M64F_EXTRA_BRIGHT	0x00020000
 #define M64F_LT_SLEEP		0x00040000
 #define M64F_XL_DLL		0x00080000
+#define M64F_MFB_TIMES_4	0x00100000
 
 
     /*
@@ -197,6 +204,34 @@
 #endif
 }
 
+static inline u16 aty_ld_le16(int regindex,
+			      const struct fb_info_aty *info)
+{
+    /* Hack for bloc 1, should be cleanly optimized by compiler */
+    if (regindex >= 0x400)
+    	regindex -= 0x800;
+
+#if defined(__mc68000__)
+    return le16_to_cpu(*((volatile u16 *)(info->ati_regbase+regindex)));
+#else
+    return readw (info->ati_regbase + regindex);
+#endif
+}
+
+static inline void aty_st_le16(int regindex, u16 val,
+			       const struct fb_info_aty *info)
+{
+    /* Hack for bloc 1, should be cleanly optimized by compiler */
+    if (regindex >= 0x400)
+    	regindex -= 0x800;
+
+#if defined(__mc68000__)
+    *((volatile u16 *)(info->ati_regbase+regindex)) = cpu_to_le16(val);
+#else
+    writew (val, info->ati_regbase + regindex);
+#endif
+}
+
 static inline u8 aty_ld_8(int regindex,
 			  const struct fb_info_aty *info)
 {
@@ -228,6 +263,19 @@
     return res;
 }
 
+/*
+ * CT family only.
+ */
+static inline void aty_st_pll(int offset, u8 val,
+			      const struct fb_info_aty *info)
+{
+    /* write addr byte */
+    aty_st_8(CLOCK_CNTL + 1, (offset << 2) | PLL_WR_EN, info);
+    /* write the register value */
+    aty_st_8(CLOCK_CNTL + 2, val, info);
+    aty_st_8(CLOCK_CNTL + 1, (offset << 2) & ~PLL_WR_EN, info);
+}
+
 
     /*
      *  DAC operations
diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/aty/atyfb_base.c linux-2.4.18/drivers/video/aty/atyfb_base.c
--- linux-2.4.18.orig/drivers/video/aty/atyfb_base.c	Thu Mar 28 14:31:54 2002
+++ linux-2.4.18/drivers/video/aty/atyfb_base.c	Fri Mar 29 10:01:31 2002
@@ -225,6 +225,9 @@
 #ifndef MODULE
 int atyfb_setup(char*);
 #endif
+#ifdef CONFIG_FB_XPERT98
+extern int atyfb_xl_init(struct fb_info_aty *info);
+#endif
 
 static int currcon = 0;
 
@@ -252,6 +255,7 @@
 static u32 default_vram __initdata = 0;
 static int default_pll __initdata = 0;
 static int default_mclk __initdata = 0;
+static int default_xclk __initdata = 0;
 
 #ifndef MODULE
 static char *mode_option __initdata = NULL;
@@ -297,7 +301,8 @@
 static char m64n_gtc_bp[] __initdata = "3D RAGE PRO (BGA, PCI)";
 static char m64n_gtc_pp[] __initdata = "3D RAGE PRO (PQFP, PCI)";
 static char m64n_gtc_ppl[] __initdata = "3D RAGE PRO (PQFP, PCI, limited 3D)";
-static char m64n_xl[] __initdata = "3D RAGE (XL)";
+static char m64n_xl_33[] __initdata = "3D RAGE (XL PCI-33MHz)";
+static char m64n_xl_66[] __initdata = "3D RAGE (XL PCI-66MHz)";
 static char m64n_ltp_a[] __initdata = "3D RAGE LT PRO (AGP)";
 static char m64n_ltp_p[] __initdata = "3D RAGE LT PRO (PCI)";
 static char m64n_mob_p[] __initdata = "3D RAGE Mobility (PCI)";
@@ -308,59 +313,64 @@
     u16 pci_id, chip_type;
     u8 rev_mask, rev_val;
     const char *name;
-    int pll, mclk;
+    int pll, mclk, xclk;
     u32 features;
 } aty_chips[] __initdata = {
 #ifdef CONFIG_FB_ATY_GX
     /* Mach64 GX */
-    { 0x4758, 0x00d7, 0x00, 0x00, m64n_gx,      135,  50, M64F_GX },
-    { 0x4358, 0x0057, 0x00, 0x00, m64n_cx,      135,  50, M64F_GX },
+    { 0x4758, 0x00d7, 0x00, 0x00, m64n_gx,      135,  50, 50, M64F_GX },
+    { 0x4358, 0x0057, 0x00, 0x00, m64n_cx,      135,  50, 50, M64F_GX },
 #endif /* CONFIG_FB_ATY_GX */
 
 #ifdef CONFIG_FB_ATY_CT
     /* Mach64 CT */
-    { 0x4354, 0x4354, 0x00, 0x00, m64n_ct,      135,  60, M64F_CT | M64F_INTEGRATED | M64F_CT_BUS | M64F_MAGIC_FIFO },
-    { 0x4554, 0x4554, 0x00, 0x00, m64n_et,      135,  60, M64F_CT | M64F_INTEGRATED | M64F_CT_BUS | M64F_MAGIC_FIFO },
+    { 0x4354, 0x4354, 0x00, 0x00, m64n_ct,      135,  60, 60, M64F_CT | M64F_INTEGRATED | M64F_CT_BUS | M64F_MAGIC_FIFO },
+    { 0x4554, 0x4554, 0x00, 0x00, m64n_et,      135,  60, 60, M64F_CT | M64F_INTEGRATED | M64F_CT_BUS | M64F_MAGIC_FIFO },
 
     /* Mach64 VT */
-    { 0x5654, 0x5654, 0xc7, 0x00, m64n_vta3,    170,  67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_MAGIC_FIFO | M64F_FIFO_24 },
-    { 0x5654, 0x5654, 0xc7, 0x40, m64n_vta4,    200,  67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_MAGIC_FIFO | M64F_FIFO_24 | M64F_MAGIC_POSTDIV },
-    { 0x5654, 0x5654, 0x00, 0x00, m64n_vtb,     200,  67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_GTB_DSP | M64F_FIFO_24 },
-    { 0x5655, 0x5655, 0x00, 0x00, m64n_vtb,     200,  67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL },
-    { 0x5656, 0x5656, 0x00, 0x00, m64n_vt4,     230,  83, M64F_VT | M64F_INTEGRATED | M64F_GTB_DSP },
+    { 0x5654, 0x5654, 0xc7, 0x00, m64n_vta3,    170,  67, 67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_MAGIC_FIFO | M64F_FIFO_24 },
+    { 0x5654, 0x5654, 0xc7, 0x40, m64n_vta4,    200,  67, 67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_MAGIC_FIFO | M64F_FIFO_24 | M64F_MAGIC_POSTDIV },
+    { 0x5654, 0x5654, 0x00, 0x00, m64n_vtb,     200,  67, 67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_GTB_DSP | M64F_FIFO_24 },
+    { 0x5655, 0x5655, 0x00, 0x00, m64n_vtb,     200,  67, 67, M64F_VT | M64F_INTEGRATED | M64F_VT_BUS | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL },
+    { 0x5656, 0x5656, 0x00, 0x00, m64n_vt4,     230,  83, 83, M64F_VT | M64F_INTEGRATED | M64F_GTB_DSP },
 
     /* Mach64 GT (3D RAGE) */
-    { 0x4754, 0x4754, 0x07, 0x00, m64n_gt,      135,  63, M64F_GT | M64F_INTEGRATED | M64F_MAGIC_FIFO | M64F_FIFO_24 | M64F_EXTRA_BRIGHT },
-    { 0x4754, 0x4754, 0x07, 0x01, m64n_gt,      170,  67, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4754, 0x4754, 0x07, 0x02, m64n_gt,      200,  67, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4755, 0x4755, 0x00, 0x00, m64n_gtb,     200,  67, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4756, 0x4756, 0x00, 0x00, m64n_iic_p,   230,  83, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4757, 0x4757, 0x00, 0x00, m64n_iic_a,   230,  83, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x475a, 0x475a, 0x00, 0x00, m64n_iic_a,   230,  83, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4754, 0x4754, 0x07, 0x00, m64n_gt,      135,  63, 63, M64F_GT | M64F_INTEGRATED | M64F_MAGIC_FIFO | M64F_FIFO_24 | M64F_EXTRA_BRIGHT },
+    { 0x4754, 0x4754, 0x07, 0x01, m64n_gt,      170,  67, 67, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4754, 0x4754, 0x07, 0x02, m64n_gt,      200,  67, 67, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4755, 0x4755, 0x00, 0x00, m64n_gtb,     200,  67, 67, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4756, 0x4756, 0x00, 0x00, m64n_iic_p,   230,  83, 83, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4757, 0x4757, 0x00, 0x00, m64n_iic_a,   230,  83, 83, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x475a, 0x475a, 0x00, 0x00, m64n_iic_a,   230,  83, 83, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_FIFO_24 | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
 
     /* Mach64 LT */
-    { 0x4c54, 0x4c54, 0x00, 0x00, m64n_lt,      135,  63, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP },
-    { 0x4c47, 0x4c47, 0x00, 0x00, m64n_ltg,     230,  63, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_LT_SLEEP | M64F_G3_PB_1024x768 },
+    { 0x4c54, 0x4c54, 0x00, 0x00, m64n_lt,      135,  63, 63, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP },
+    { 0x4c47, 0x4c47, 0x00, 0x00, m64n_ltg,     230,  63, 63, M64F_GT | M64F_INTEGRATED | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_LT_SLEEP | M64F_G3_PB_1024x768 },
 
     /* Mach64 GTC (3D RAGE PRO) */
-    { 0x4742, 0x4742, 0x00, 0x00, m64n_gtc_ba,  230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4744, 0x4744, 0x00, 0x00, m64n_gtc_ba1, 230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4749, 0x4749, 0x00, 0x00, m64n_gtc_bp,  230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_MAGIC_VRAM_SIZE },
-    { 0x4750, 0x4750, 0x00, 0x00, m64n_gtc_pp,  230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-    { 0x4751, 0x4751, 0x00, 0x00, m64n_gtc_ppl, 230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
-
-    /* 3D RAGE XL */
-    { 0x4752, 0x4752, 0x00, 0x00, m64n_xl, 230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_XL_DLL },
-
+    { 0x4742, 0x4742, 0x00, 0x00, m64n_gtc_ba,  230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4744, 0x4744, 0x00, 0x00, m64n_gtc_ba1, 230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4749, 0x4749, 0x00, 0x00, m64n_gtc_bp,  230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_MAGIC_VRAM_SIZE },
+    { 0x4750, 0x4750, 0x00, 0x00, m64n_gtc_pp,  230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+    { 0x4751, 0x4751, 0x00, 0x00, m64n_gtc_ppl, 230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT },
+#ifdef CONFIG_FB_XPERT98
+    /* 3D RAGE XL PCI-66/BGA */
+    { 0x474f, 0x474f, 0x00, 0x00, m64n_xl_66, 230, 83, 63, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_XL_DLL | M64F_MFB_TIMES_4 },
+    /* 3D RAGE XL PCI-33/BGA */
+    { 0x4752, 0x4752, 0x00, 0x00, m64n_xl_33, 230, 83, 63, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_XL_DLL | M64F_MFB_TIMES_4 },
+#else
+    /* 3D RAGE XL PCI-33/BGA */
+    { 0x4752, 0x4752, 0x00, 0x00, m64n_xl_33, 230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_SDRAM_MAGIC_PLL | M64F_EXTRA_BRIGHT | M64F_XL_DLL },
+#endif
     /* Mach64 LT PRO */
-    { 0x4c42, 0x4c42, 0x00, 0x00, m64n_ltp_a,   230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP },
-    { 0x4c44, 0x4c44, 0x00, 0x00, m64n_ltp_p,   230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP },
-    { 0x4c49, 0x4c49, 0x00, 0x00, m64n_ltp_p,   230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_EXTRA_BRIGHT | M64F_G3_PB_1_1 | M64F_G3_PB_1024x768 },
-    { 0x4c50, 0x4c50, 0x00, 0x00, m64n_ltp_p,   230, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP },
+    { 0x4c42, 0x4c42, 0x00, 0x00, m64n_ltp_a,   230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP },
+    { 0x4c44, 0x4c44, 0x00, 0x00, m64n_ltp_p,   230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP },
+    { 0x4c49, 0x4c49, 0x00, 0x00, m64n_ltp_p,   230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_EXTRA_BRIGHT | M64F_G3_PB_1_1 | M64F_G3_PB_1024x768 },
+    { 0x4c50, 0x4c50, 0x00, 0x00, m64n_ltp_p,   230, 100, 100, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP },
 
     /* 3D RAGE Mobility */
-    { 0x4c4d, 0x4c4d, 0x00, 0x00, m64n_mob_p,   230,  50, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_MOBIL_BUS },
-    { 0x4c4e, 0x4c4e, 0x00, 0x00, m64n_mob_a,   230,  50, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_MOBIL_BUS },
+    { 0x4c4d, 0x4c4d, 0x00, 0x00, m64n_mob_p,   230,  50, 50, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_MOBIL_BUS },
+    { 0x4c4e, 0x4c4e, 0x00, 0x00, m64n_mob_a,   230,  50, 50, M64F_GT | M64F_INTEGRATED | M64F_RESET_3D | M64F_GTB_DSP | M64F_MOBIL_BUS },
 #endif /* CONFIG_FB_ATY_CT */
 };
 
@@ -1249,7 +1259,10 @@
     u32 ref_clk_per;
     u8 pll_ref_div;
     u8 mclk_fb_div;
+    u8 sclk_fb_div;
     u8 mclk_post_div;		/* 1,2,3,4,8 */
+    u8 mclk_fb_mult;            /* 2 or 4 */
+    u8 xclk_post_div;		/* 1,2,3,4,8 */
     u8 vclk_fb_div;
     u8 vclk_post_div;		/* 1,2,3,4,6,8,12 */
     u32 dsp_xclks_per_row;	/* 0-16383 */
@@ -1302,14 +1315,17 @@
 	    clk.ref_clk_per = info->ref_clk_per;
 	    clk.pll_ref_div = pll->ct.pll_ref_div;
 	    clk.mclk_fb_div = pll->ct.mclk_fb_div;
+	    clk.sclk_fb_div = pll->ct.sclk_fb_div;
 	    clk.mclk_post_div = pll->ct.mclk_post_div_real;
+	    clk.mclk_fb_mult = pll->ct.mclk_fb_mult;
+	    clk.xclk_post_div = pll->ct.xclk_post_div_real;
 	    clk.vclk_fb_div = pll->ct.vclk_fb_div;
 	    clk.vclk_post_div = pll->ct.vclk_post_div_real;
 	    clk.dsp_xclks_per_row = dsp_config & 0x3fff;
 	    clk.dsp_loop_latency = (dsp_config>>16) & 0xf;
 	    clk.dsp_precision = (dsp_config>>20) & 7;
-	    clk.dsp_on = dsp_on_off & 0x7ff;
-	    clk.dsp_off = (dsp_on_off>>16) & 0x7ff;
+	    clk.dsp_off = dsp_on_off & 0x7ff;
+	    clk.dsp_on = (dsp_on_off>>16) & 0x7ff;
 	    if (copy_to_user((struct atyclk *)arg, &clk, sizeof(clk)))
 		    return -EFAULT;
 	} else
@@ -1324,14 +1340,17 @@
 	    info->ref_clk_per = clk.ref_clk_per;
 	    pll->ct.pll_ref_div = clk.pll_ref_div;
 	    pll->ct.mclk_fb_div = clk.mclk_fb_div;
+	    pll->ct.sclk_fb_div = clk.sclk_fb_div;
 	    pll->ct.mclk_post_div_real = clk.mclk_post_div;
+	    pll->ct.mclk_fb_mult = clk.mclk_fb_mult;
+	    pll->ct.xclk_post_div_real = clk.xclk_post_div;
 	    pll->ct.vclk_fb_div = clk.vclk_fb_div;
 	    pll->ct.vclk_post_div_real = clk.vclk_post_div;
 	    pll->ct.dsp_config = (clk.dsp_xclks_per_row & 0x3fff) |
 				 ((clk.dsp_loop_latency & 0xf)<<16) |
 				 ((clk.dsp_precision & 7)<<20);
-	    pll->ct.dsp_on_off = (clk.dsp_on & 0x7ff) |
-				 ((clk.dsp_off & 0x7ff)<<16);
+	    pll->ct.dsp_on_off = (clk.dsp_off & 0x7ff) |
+				 ((clk.dsp_on & 0x7ff)<<16);
 	    aty_calc_pll_ct(info, &pll->ct);
 	    aty_set_pll_ct(info, pll);
 	} else
@@ -1751,6 +1770,36 @@
 #endif /* CONFIG_PMAC_BACKLIGHT */
 
 
+static void __init aty_calc_mem_refresh(struct fb_info_aty *info,
+					u16 id,
+					int xclk)
+{
+	int i, size;
+	const int ragepro_tbl[] = {
+		44, 50, 55, 66, 75, 80, 100
+	};
+	const int ragexl_tbl[] = {
+		50, 66, 75, 83, 90, 95, 100, 105,
+		110, 115, 120, 125, 133, 143, 166
+	};
+	const int *refresh_tbl;
+
+	if (IS_XL(id)) {
+		refresh_tbl = ragexl_tbl;
+		size = sizeof(ragexl_tbl)/sizeof(int);
+	} else {
+		refresh_tbl = ragepro_tbl;
+		size = sizeof(ragepro_tbl)/sizeof(int);
+	}
+	
+	for (i=0; i < size; i++) {
+		if (xclk < refresh_tbl[i])
+			break;
+	}
+	
+	info->mem_refresh_rate = i;
+}
+
 
     /*
      *  Initialisation
@@ -1768,12 +1817,12 @@
     u16 type;
     u8 rev;
     const char *chipname = NULL, *ramname = NULL, *xtal;
-    int pll, mclk, gtb_memsize;
+    int pll, mclk, xclk, gtb_memsize;
 #if defined(CONFIG_PPC)
     int sense;
 #endif
     u8 pll_ref_div;
-
+    
     info->aty_cmap_regs = (struct aty_cmap_regs *)(info->ati_regbase+0xc0);
     chip_id = aty_ld_le32(CONFIG_CHIP_ID, info);
     type = chip_id & CFG_CHIP_TYPE;
@@ -1784,6 +1833,7 @@
 	    chipname = aty_chips[j].name;
 	    pll = aty_chips[j].pll;
 	    mclk = aty_chips[j].mclk;
+	    xclk = aty_chips[j].xclk;
 	    info->features = aty_chips[j].features;
 	    goto found;
 	}
@@ -1854,17 +1904,39 @@
 	}
     }
 #endif /* CONFIG_FB_ATY_GX */
+
 #ifdef CONFIG_FB_ATY_CT
     if (M64_HAS(INTEGRATED)) {
-	info->bus_type = PCI;
-	info->ram_type = (aty_ld_le32(CONFIG_STAT0, info) & 0x07);
-	ramname = aty_ct_ram[info->ram_type];
-	info->dac_ops = &aty_dac_ct;
-	info->pll_ops = &aty_pll_ct;
 	/* for many chips, the mclk is 67 MHz for SDRAM, 63 MHz otherwise */
 	if (mclk == 67 && info->ram_type < SDRAM)
 	    mclk = 63;
     }
+#endif
+    
+    if (default_pll)
+	pll = default_pll;
+    if (default_mclk)
+	mclk = default_mclk;
+    if (default_xclk)
+	xclk = default_xclk;
+
+    aty_calc_mem_refresh(info, type, xclk);
+    info->pll_per = 1000000/pll;
+    info->mclk_per = 1000000/mclk;
+    info->xclk_per = 1000000/xclk;
+
+#ifdef CONFIG_FB_ATY_CT
+    if (M64_HAS(INTEGRATED)) {
+	info->dac_ops = &aty_dac_ct;
+	info->pll_ops = &aty_pll_ct;
+	info->bus_type = PCI;
+#ifdef CONFIG_FB_XPERT98
+	if (IS_XL(type))
+		atyfb_xl_init(info);
+#endif
+	info->ram_type = (aty_ld_le32(CONFIG_STAT0, info) & 0x07);
+	ramname = aty_ct_ram[info->ram_type];
+    }
 #endif /* CONFIG_FB_ATY_CT */
 
     info->ref_clk_per = 1000000000000ULL/14318180;
@@ -1954,33 +2026,11 @@
 	    i |= gtb_memsize ? MEM_SIZE_8M_GTB : MEM_SIZE_8M;
 	aty_st_le32(MEM_CNTL, i, info);
     }
-    if (default_pll)
-	pll = default_pll;
-    if (default_mclk)
-	mclk = default_mclk;
 
-    printk("%d%c %s, %s MHz XTAL, %d MHz PLL, %d Mhz MCLK\n",
+    printk("%d%c %s, %s MHz XTAL, %d MHz PLL, %d Mhz MCLK, %d Mhz XCLK\n",
     	   info->total_vram == 0x80000 ? 512 : (info->total_vram >> 20),
-    	   info->total_vram == 0x80000 ? 'K' : 'M', ramname, xtal, pll, mclk);
-
-    if (mclk < 44)
-	info->mem_refresh_rate = 0;	/* 000 = 10 Mhz - 43 Mhz */
-    else if (mclk < 50)
-	info->mem_refresh_rate = 1;	/* 001 = 44 Mhz - 49 Mhz */
-    else if (mclk < 55)
-	info->mem_refresh_rate = 2;	/* 010 = 50 Mhz - 54 Mhz */
-    else if (mclk < 66)
-	info->mem_refresh_rate = 3;	/* 011 = 55 Mhz - 65 Mhz */
-    else if (mclk < 75)
-	info->mem_refresh_rate = 4;	/* 100 = 66 Mhz - 74 Mhz */
-    else if (mclk < 80)
-	info->mem_refresh_rate = 5;	/* 101 = 75 Mhz - 79 Mhz */
-    else if (mclk < 100)
-	info->mem_refresh_rate = 6;	/* 110 = 80 Mhz - 100 Mhz */
-    else
-	info->mem_refresh_rate = 7;	/* 111 = 100 Mhz and above */
-    info->pll_per = 1000000/pll;
-    info->mclk_per = 1000000/mclk;
+    	   info->total_vram == 0x80000 ? 'K' : 'M', ramname, xtal, pll,
+	   mclk, xclk);
 
 #ifdef DEBUG
     if (M64_HAS(INTEGRATED)) {
@@ -2196,6 +2246,8 @@
 	    if (!request_mem_region(res_start, res_size, "atyfb"))
 		continue;
 
+	    info->pdev = pdev;
+
 #ifdef __sparc__
 	    /*
 	     * Map memory-mapped registers.
@@ -2280,7 +2332,7 @@
 		j++;
 	    }
 
-	    if (pdev->device != XL_CHIP_ID) {
+	    if (!IS_XL(pdev->device)) {
 		    /*
 		     * Fix PROMs idea of MEM_CNTL settings...
 		     */
@@ -2390,7 +2442,7 @@
 		 *
 		 * where R is XTALIN (= 14318 or 29498 kHz).
 		 */
-		if (pdev->device == XL_CHIP_ID)
+		if (IS_XL(pdev->device))
 			R = 29498;
 		else
 			R = 14318;
@@ -2578,6 +2630,8 @@
 		default_pll = simple_strtoul(this_opt+4, NULL, 0);
 	else if (!strncmp(this_opt, "mclk:", 5))
 		default_mclk = simple_strtoul(this_opt+5, NULL, 0);
+	else if (!strncmp(this_opt, "xclk:", 5))
+		default_xclk = simple_strtoul(this_opt+5, NULL, 0);
 #ifdef CONFIG_PPC
 	else if (!strncmp(this_opt, "vmode:", 6)) {
 	    unsigned int vmode = simple_strtoul(this_opt+6, NULL, 0);
diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/aty/mach64.h linux-2.4.18/drivers/video/aty/mach64.h
--- linux-2.4.18.orig/drivers/video/aty/mach64.h	Thu Mar 28 14:31:54 2002
+++ linux-2.4.18/drivers/video/aty/mach64.h	Fri Mar 29 10:01:31 2002
@@ -849,7 +849,18 @@
 #define LI_CHIP_ID	0x4c49	/* RAGE LT PRO */
 #define LP_CHIP_ID	0x4c50	/* RAGE LT PRO */
 #define LT_CHIP_ID	0x4c54	/* RAGE LT */
-#define XL_CHIP_ID	0x4752	/* RAGE (XL) */
+
+#define GR_CHIP_ID	0x4752	/* RAGE XL, BGA, PCI33 */
+#define GS_CHIP_ID	0x4753	/* RAGE XL, PQFP, PCI33 */
+#define GM_CHIP_ID	0x474d	/* RAGE XL, BGA, AGP 1x,2x */
+#define GN_CHIP_ID	0x474e	/* RAGE XL, PQFP,AGP 1x,2x */
+#define GO_CHIP_ID	0x474f	/* RAGE XL, BGA, PCI66 */
+#define GL_CHIP_ID	0x474c	/* RAGE XL, PQFP, PCI66 */
+
+#define IS_XL(id) ((id)==GR_CHIP_ID || (id)==GS_CHIP_ID || \
+                   (id)==GM_CHIP_ID || (id)==GN_CHIP_ID || \
+                   (id)==GO_CHIP_ID || (id)==GL_CHIP_ID)
+
 #define GT_CHIP_ID	0x4754	/* RAGE (GT) */
 #define GU_CHIP_ID	0x4755	/* RAGE II/II+ (GTB) */
 #define GV_CHIP_ID	0x4756	/* RAGE IIC, PCI */
diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/aty/mach64_ct.c linux-2.4.18/drivers/video/aty/mach64_ct.c
--- linux-2.4.18.orig/drivers/video/aty/mach64_ct.c	Thu Mar 28 14:31:54 2002
+++ linux-2.4.18/drivers/video/aty/mach64_ct.c	Fri Mar 29 10:01:31 2002
@@ -4,6 +4,7 @@
  */
 
 #include <linux/fb.h>
+#include <linux/delay.h>
 
 #include <asm/io.h>
 
@@ -12,15 +13,14 @@
 #include "mach64.h"
 #include "atyfb.h"
 
+#undef DEBUG
 
 /* FIXME: remove the FAIL definition */
 #define FAIL(x) do { printk(x "\n"); return -EINVAL; } while (0)
 
-static void aty_st_pll(int offset, u8 val, const struct fb_info_aty *info);
-
 static int aty_valid_pll_ct(const struct fb_info_aty *info, u32 vclk_per,
 			    struct pll_ct *pll);
-static int aty_dsp_gt(const struct fb_info_aty *info, u8 bpp,
+static int aty_dsp_gt(const struct fb_info_aty *info, u32 bpp,
 		      struct pll_ct *pll);
 static int aty_var_to_pll_ct(const struct fb_info_aty *info, u32 vclk_per,
 			     u8 bpp, union aty_pll *pll);
@@ -28,34 +28,30 @@
 			     const union aty_pll *pll);
 
 
-
-static void aty_st_pll(int offset, u8 val, const struct fb_info_aty *info)
-{
-    /* write addr byte */
-    aty_st_8(CLOCK_CNTL + 1, (offset << 2) | PLL_WR_EN, info);
-    /* write the register value */
-    aty_st_8(CLOCK_CNTL + 2, val, info);
-    aty_st_8(CLOCK_CNTL + 1, (offset << 2) & ~PLL_WR_EN, info);
-}
-
-
 /* ------------------------------------------------------------------------- */
 
     /*
      *  PLL programming (Mach64 CT family)
      */
-
-static int aty_dsp_gt(const struct fb_info_aty *info, u8 bpp,
+static int aty_dsp_gt(const struct fb_info_aty *info, u32 bpp,
 		      struct pll_ct *pll)
 {
     u32 dsp_xclks_per_row, dsp_loop_latency, dsp_precision, dsp_off, dsp_on;
-    u32 xclks_per_row, fifo_off, fifo_on, y, fifo_size, page_size;
+    u32 xclks_per_row, fifo_off, fifo_on, y, fifo_size;
+    u32 memcntl, n, t_pfc, t_rp, t_ras, t_rcd, t_crd, t_rcc, t_lat;
+
+#ifdef DEBUG
+    printk(__FUNCTION__ ": mclk_fb_mult=%d\n", pll->mclk_fb_mult);
+#endif
+    
+    /* (64*xclk/vclk/bpp)<<11 = xclocks_per_row<<11 */
+    xclks_per_row = ((u32)pll->mclk_fb_mult * (u32)pll->mclk_fb_div *
+		     (u32)pll->vclk_post_div_real * 64) << 11;
+    xclks_per_row /=
+	    (2 * (u32)pll->vclk_fb_div * (u32)pll->xclk_post_div_real * bpp);
 
-    /* xclocks_per_row<<11 */
-    xclks_per_row = (pll->mclk_fb_div*pll->vclk_post_div_real*64<<11)/
-		    (pll->vclk_fb_div*pll->mclk_post_div_real*bpp);
     if (xclks_per_row < (1<<11))
-	FAIL("Dotclock to high");
+	FAIL("Dotclock too high");
     if (M64_HAS(FIFO_24)) {
 	fifo_size = 24;
 	dsp_loop_latency = 0;
@@ -70,35 +66,54 @@
 	dsp_precision++;
     }
     dsp_precision -= 5;
+
     /* fifo_off<<6 */
-    fifo_off = ((xclks_per_row*(fifo_size-1))>>5)+(3<<6);
+    fifo_off = ((xclks_per_row*(fifo_size-1))>>5); // + (3<<6);
 
     if (info->total_vram > 1*1024*1024) {
-	if (info->ram_type >= SDRAM) {
+	switch (info->ram_type) {
+	case WRAM:
+	    /* >1 MB WRAM */
+	    dsp_loop_latency += 9;
+	    n = 4;
+	    break;
+	case SDRAM:
+	case SGRAM:
 	    /* >1 MB SDRAM */
 	    dsp_loop_latency += 8;
-	    page_size = 8;
-	} else {
+	    n = 2;
+	    break;
+	default:
 	    /* >1 MB DRAM */
 	    dsp_loop_latency += 6;
-	    page_size = 9;
+	    n = 3;
+	    break;
 	}
     } else {
 	if (info->ram_type >= SDRAM) {
 	    /* <2 MB SDRAM */
 	    dsp_loop_latency += 9;
-	    page_size = 10;
+	    n = 2;
 	} else {
 	    /* <2 MB DRAM */
 	    dsp_loop_latency += 8;
-	    page_size = 10;
+	    n = 3;
 	}
     }
+
+    memcntl = aty_ld_le32(MEM_CNTL, info);
+    t_rcd = ((memcntl >> 10) & 0x03) + 1;
+    t_crd = ((memcntl >> 12) & 0x01);
+    t_rp  = ((memcntl >>  8) & 0x03) + 1;
+    t_ras = ((memcntl >> 16) & 0x07) + 1;
+    t_lat =  (memcntl >>  4) & 0x03;
+    
+    t_pfc = t_rp + t_rcd + t_crd;
+    
+    t_rcc = max(t_rp + t_ras, t_pfc + n);
+    
     /* fifo_on<<6 */
-    if (xclks_per_row >= (page_size<<11))
-	fifo_on = ((2*page_size+1)<<6)+(xclks_per_row>>5);
-    else
-	fifo_on = (3*page_size+2)<<6;
+    fifo_on = (2 * t_rcc + t_pfc + n - 1) << 6;
 
     dsp_xclks_per_row = xclks_per_row>>dsp_precision;
     dsp_on = fifo_on>>dsp_precision;
@@ -107,20 +122,27 @@
     pll->dsp_config = (dsp_xclks_per_row & 0x3fff) |
 		      ((dsp_loop_latency & 0xf)<<16) |
 		      ((dsp_precision & 7)<<20);
-    pll->dsp_on_off = (dsp_on & 0x7ff) | ((dsp_off & 0x7ff)<<16);
+    pll->dsp_on_off = (dsp_off & 0x7ff) | ((dsp_on & 0x7ff)<<16);
     return 0;
 }
 
+
 static int aty_valid_pll_ct(const struct fb_info_aty *info, u32 vclk_per,
 			    struct pll_ct *pll)
 {
+#ifdef DEBUG
+    int pllmclk, pllsclk;
+#endif
     u32 q, x;			/* x is a workaround for sparc64-linux-gcc */
     x = x;			/* x is a workaround for sparc64-linux-gcc */
-
+    
     pll->pll_ref_div = info->pll_per*2*255/info->ref_clk_per;
-
+    
     /* FIXME: use the VTB/GTB /3 post divider if it's better suited */
-    q = info->ref_clk_per*pll->pll_ref_div*4/info->mclk_per;	/* actually 8*q */
+
+    /* actually 8*q */
+    q = info->ref_clk_per*pll->pll_ref_div*4/info->mclk_per;
+
     if (q < 16*8 || q > 255*8)
 	FAIL("mclk out of range");
     else if (q < 32*8)
@@ -131,8 +153,40 @@
 	pll->mclk_post_div_real = 2;
     else
 	pll->mclk_post_div_real = 1;
-    pll->mclk_fb_div = q*pll->mclk_post_div_real/8;
+    pll->sclk_fb_div = q*pll->mclk_post_div_real/8;
+    
+#ifdef DEBUG
+    pllsclk = (1000000 * 2 * pll->sclk_fb_div) /
+	    (info->ref_clk_per * pll->pll_ref_div);
+    printk(__FUNCTION__ ": pllsclk=%d MHz, mclk=%d MHz\n",
+	   pllsclk, pllsclk / pll->mclk_post_div_real);
+#endif
+    
+    pll->mclk_fb_mult = M64_HAS(MFB_TIMES_4) ? 4 : 2;
+
+    /* actually 8*q */
+    q = info->ref_clk_per * pll->pll_ref_div * 8 /
+	    (pll->mclk_fb_mult * info->xclk_per);
 
+    if (q < 16*8 || q > 255*8)
+	FAIL("mclk out of range");
+    else if (q < 32*8)
+	pll->xclk_post_div_real = 8;
+    else if (q < 64*8)
+	pll->xclk_post_div_real = 4;
+    else if (q < 128*8)
+	pll->xclk_post_div_real = 2;
+    else
+	pll->xclk_post_div_real = 1;
+    pll->mclk_fb_div = q*pll->xclk_post_div_real/8;
+    
+#ifdef DEBUG
+    pllmclk = (1000000 * pll->mclk_fb_mult * pll->mclk_fb_div) /
+	    (info->ref_clk_per * pll->pll_ref_div);
+    printk(__FUNCTION__ ": pllmclk=%d MHz, xclk=%d MHz\n",
+	   pllmclk, pllmclk / pll->xclk_post_div_real);
+#endif
+    
     /* FIXME: use the VTB/GTB /{3,6,12} post dividers if they're better suited */
     q = info->ref_clk_per*pll->pll_ref_div*4/vclk_per;	/* actually 8*q */
     if (q < 16*8 || q > 255*8)
@@ -151,13 +205,14 @@
 
 void aty_calc_pll_ct(const struct fb_info_aty *info, struct pll_ct *pll)
 {
+    u8 xpostdiv = 0;
     u8 mpostdiv = 0;
     u8 vpostdiv = 0;
-
+    
     if (M64_HAS(SDRAM_MAGIC_PLL) && (info->ram_type >= SDRAM))
-	pll->pll_gen_cntl = 0x04;
+	    pll->pll_gen_cntl = 0x64; /* mclk = sclk */
     else
-	pll->pll_gen_cntl = 0x84;
+	pll->pll_gen_cntl = 0xe4; /* mclk = sclk */
 
     switch (pll->mclk_post_div_real) {
 	case 1:
@@ -166,9 +221,6 @@
 	case 2:
 	    mpostdiv = 1;
 	    break;
-	case 3:
-	    mpostdiv = 4;
-	    break;
 	case 4:
 	    mpostdiv = 2;
 	    break;
@@ -176,12 +228,34 @@
 	    mpostdiv = 3;
 	    break;
     }
-    pll->pll_gen_cntl |= mpostdiv<<4;	/* mclk */
+
+    pll->spll_cntl2 = mpostdiv << 4; /* sclk == pllsclk / mpostdiv */
+    
+    switch (pll->xclk_post_div_real) {
+	case 1:
+	    xpostdiv = 0;
+	    break;
+	case 2:
+	    xpostdiv = 1;
+	    break;
+	case 3:
+	    xpostdiv = 4;
+	    break;
+	case 4:
+	    xpostdiv = 2;
+	    break;
+	case 8:
+	    xpostdiv = 3;
+	    break;
+    }
 
     if (M64_HAS(MAGIC_POSTDIV))
 	pll->pll_ext_cntl = 0;
     else
-    	pll->pll_ext_cntl = mpostdiv;	/* xclk == mclk */
+	pll->pll_ext_cntl = xpostdiv;	/* xclk == pllmclk / xpostdiv */
+
+    if (pll->mclk_fb_mult == 4)
+	    pll->pll_ext_cntl |= 0x08;
 
     switch (pll->vclk_post_div_real) {
 	case 2:
@@ -234,24 +308,54 @@
 
 void aty_set_pll_ct(const struct fb_info_aty *info, const union aty_pll *pll)
 {
+#ifdef DEBUG
+    printk(__FUNCTION__ ": about to program:\n"
+	   "refdiv=%d, extcntl=0x%02x, mfbdiv=%d\n"
+	   "spllcntl2=0x%02x, sfbdiv=%d, gencntl=0x%02x\n"
+	   "vclkcntl=0x%02x, vpostdiv=0x%02x, vfbdiv=%d\n"
+	   "clocksel=%d\n",
+	   pll->ct.pll_ref_div, pll->ct.pll_ext_cntl,
+	   pll->ct.mclk_fb_div, pll->ct.spll_cntl2,
+	   pll->ct.sclk_fb_div, pll->ct.pll_gen_cntl,
+	   pll->ct.pll_vclk_cntl, pll->ct.vclk_post_div,
+	   pll->ct.vclk_fb_div, aty_ld_le32(CLOCK_CNTL, info) & 0x03);
+#endif
+
     aty_st_pll(PLL_REF_DIV, pll->ct.pll_ref_div, info);
+
+    aty_st_pll(PLL_EXT_CNTL, pll->ct.pll_ext_cntl, info);
+    aty_st_pll(MCLK_FB_DIV, pll->ct.mclk_fb_div, info); // for XCLK
+    
+    aty_st_pll(SPLL_CNTL2, pll->ct.spll_cntl2, info);
+    aty_st_pll(SCLK_FB_DIV, pll->ct.sclk_fb_div, info); // for MCLK
+
     aty_st_pll(PLL_GEN_CNTL, pll->ct.pll_gen_cntl, info);
-    aty_st_pll(MCLK_FB_DIV, pll->ct.mclk_fb_div, info);
+    
+    aty_st_pll(EXT_VPLL_CNTL, 0, info);
     aty_st_pll(PLL_VCLK_CNTL, pll->ct.pll_vclk_cntl, info);
     aty_st_pll(VCLK_POST_DIV, pll->ct.vclk_post_div, info);
     aty_st_pll(VCLK0_FB_DIV, pll->ct.vclk_fb_div, info);
-    aty_st_pll(PLL_EXT_CNTL, pll->ct.pll_ext_cntl, info);
 
     if (M64_HAS(GTB_DSP)) {
+	u8 dll_cntl;
+
 	if (M64_HAS(XL_DLL))
-	    aty_st_pll(DLL_CNTL, 0x80, info);
+	    dll_cntl = 0x80;
 	else if (info->ram_type >= SDRAM)
-	    aty_st_pll(DLL_CNTL, 0xa6, info);
+	    dll_cntl = 0xa6;
 	else
-	    aty_st_pll(DLL_CNTL, 0xa0, info);
+	    dll_cntl = 0xa0;
+	aty_st_pll(DLL_CNTL, dll_cntl, info);
 	aty_st_pll(VFC_CNTL, 0x1b, info);
 	aty_st_le32(DSP_CONFIG, pll->ct.dsp_config, info);
 	aty_st_le32(DSP_ON_OFF, pll->ct.dsp_on_off, info);
+
+	mdelay(10);
+	aty_st_pll(DLL_CNTL, dll_cntl, info);
+	mdelay(10);
+	aty_st_pll(DLL_CNTL, dll_cntl | 0x40, info);
+	mdelay(10);
+	aty_st_pll(DLL_CNTL, dll_cntl & ~0x40, info);
     }
 }
 
diff -Nuar -X /home/stevel/dontdiff linux-2.4.18.orig/drivers/video/aty/xlinit.c linux-2.4.18/drivers/video/aty/xlinit.c
--- linux-2.4.18.orig/drivers/video/aty/xlinit.c	Wed Dec 31 16:00:00 1969
+++ linux-2.4.18/drivers/video/aty/xlinit.c	Fri Mar 29 10:01:31 2002
@@ -0,0 +1,391 @@
+/*
+ *  ATI Rage XL Initialization. Support for Xpert98 and Victoria
+ *  PCI cards.
+ *
+ *  Copyright (C) 2002 MontaVista Software Inc.
+ *  Author: MontaVista Software, Inc.
+ *         	stevel@mvista.com or source@mvista.com
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
+ *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
+ *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
+ *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the  GNU General Public License along
+ *  with this program; if not, write  to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h> 
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/delay.h>
+#include <linux/selection.h>
+#include <linux/console.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/vt_kern.h>
+#include <linux/kd.h> 
+#include <asm/io.h>
+#include <video/fbcon.h>
+#include "mach64.h"
+#include "atyfb.h"
+
+#define MPLL_GAIN       0xad
+#define VPLL_GAIN       0xd5
+
+#define XPERT98_SUB_ID  0x8008
+#define VICTORIA_SUB_ID 0x0000
+
+enum {
+	VICTORIA = 0,
+	XPERT98,
+	NUM_XL_CARDS
+};
+
+extern const struct aty_pll_ops aty_pll_ct;
+
+static const struct xl_card_cfg_t {
+	int ref_crystal; // 10^4 Hz
+	int mem_type;
+	int mem_size;
+	u32 mem_cntl;
+	u32 ext_mem_cntl;
+	u32 mem_addr_config;
+	u32 bus_cntl;
+	u32 dac_cntl;
+	u32 hw_debug;
+	u32 custom_macro_cntl;
+	u8  dll2_cntl;
+	u8  pll_yclk_cntl;
+} card_cfg[NUM_XL_CARDS] = {
+	// VICTORIA
+	{	2700, SDRAM, 0x800000,
+		0x10757A3B, 0x64000C81, 0x00110202, 0x7b33A040,
+		0x82010102, 0x48803800, 0x005E0179,
+		0x50, 0x25
+	},
+	// XPERT98
+	{	1432,  WRAM, 0x800000,
+		0x00165A2B, 0xE0000CF1, 0x00200213, 0x7333A001,
+		0x8000000A, 0x48833800, 0x007F0779,
+		0x10, 0x19
+	}
+};
+	  
+typedef struct {
+	u8 lcd_reg;
+	u32 val;
+} lcd_tbl_t;
+
+static const lcd_tbl_t lcd_tbl[] = {
+	{ 0x01,	0x000520C0 },
+	{ 0x08,	0x02000408 },
+	{ 0x03,	0x00000F00 },
+	{ 0x00,	0x00000000 },
+	{ 0x02,	0x00000000 },
+	{ 0x04,	0x00000000 },
+	{ 0x05,	0x00000000 },
+	{ 0x06,	0x00000000 },
+	{ 0x33,	0x00000000 },
+	{ 0x34,	0x00000000 },
+	{ 0x35,	0x00000000 },
+	{ 0x36,	0x00000000 },
+	{ 0x37,	0x00000000 }
+};
+
+static inline u32 aty_ld_lcd(u8 lcd_reg, struct fb_info_aty *info)
+{
+	aty_st_8(LCD_INDEX, lcd_reg, info);
+	return aty_ld_le32(LCD_DATA, info);
+}
+
+static inline void aty_st_lcd(u8 lcd_reg, u32 val,
+			      struct fb_info_aty *info)
+{
+	aty_st_8(LCD_INDEX, lcd_reg, info);
+	aty_st_le32(LCD_DATA, val, info);
+}
+
+static void reset_gui(struct fb_info_aty *info)
+{
+	aty_st_8(GEN_TEST_CNTL+1, 0x01, info);
+	aty_st_8(GEN_TEST_CNTL+1, 0x00, info);
+	aty_st_8(GEN_TEST_CNTL+1, 0x02, info);
+	mdelay(5);
+}
+
+
+static void reset_sdram(struct fb_info_aty *info)
+{
+	u8 temp;
+
+	temp = aty_ld_8(EXT_MEM_CNTL, info);
+	temp |= 0x02;
+	aty_st_8(EXT_MEM_CNTL, temp, info); // MEM_SDRAM_RESET = 1b
+	temp |= 0x08;
+	aty_st_8(EXT_MEM_CNTL, temp, info); // MEM_CYC_TEST    = 10b
+	temp |= 0x0c;
+	aty_st_8(EXT_MEM_CNTL, temp, info); // MEM_CYC_TEST    = 11b
+	mdelay(5);
+	temp &= 0xf3;
+	aty_st_8(EXT_MEM_CNTL, temp, info); // MEM_CYC_TEST    = 00b
+	temp &= 0xfd;
+	aty_st_8(EXT_MEM_CNTL, temp, info); // MEM_SDRAM_REST  = 0b
+	mdelay(5);
+}
+
+static void init_dll(struct fb_info_aty *info)
+{
+	// enable DLL
+	aty_st_pll(PLL_GEN_CNTL,
+		   aty_ld_pll(PLL_GEN_CNTL, info) & 0x7f,
+		   info);
+
+	// reset DLL
+	aty_st_pll(DLL_CNTL, 0x82, info);
+	aty_st_pll(DLL_CNTL, 0xE2, info);
+	mdelay(5);
+	aty_st_pll(DLL_CNTL, 0x82, info);
+	mdelay(6);
+}
+
+static void reset_clocks(struct fb_info_aty *info, struct pll_ct *pll,
+			 int hsync_enb)
+{
+	reset_gui(info);
+	aty_st_pll(MCLK_FB_DIV, pll->mclk_fb_div, info);
+	aty_st_pll(SCLK_FB_DIV, pll->sclk_fb_div, info);
+
+	mdelay(15);
+	init_dll(info);
+	aty_st_8(GEN_TEST_CNTL+1, 0x00, info);
+	mdelay(5);
+	aty_st_8(CRTC_GEN_CNTL+3, 0x04, info);
+	mdelay(6);
+	reset_sdram(info);
+	aty_st_8(CRTC_GEN_CNTL+3,
+		 hsync_enb ? 0x00 : 0x04, info);
+
+	aty_st_pll(SPLL_CNTL2, pll->spll_cntl2, info);
+	aty_st_pll(PLL_GEN_CNTL, pll->pll_gen_cntl, info);
+	aty_st_pll(PLL_VCLK_CNTL, pll->pll_vclk_cntl, info);
+}
+
+
+int atyfb_xl_init(struct fb_info_aty *info)
+{
+	int i, err, xl_card;
+	u32 temp;
+	u16 temp16;
+	union aty_pll pll;
+	const struct xl_card_cfg_t * card;
+
+	pci_read_config_word(info->pdev, PCI_SUBSYSTEM_ID, &temp16);
+	switch (temp16) {
+	case XPERT98_SUB_ID:
+		xl_card = XPERT98;
+		break;
+	case VICTORIA_SUB_ID:
+		xl_card = VICTORIA;
+		break;
+	default:
+		printk("\n" __FUNCTION__ ": unknown adapter id 0x%04x\n",
+		       temp16);
+		return -ENODEV;
+	}
+	
+	card = &card_cfg[xl_card];
+
+	aty_st_8(CONFIG_STAT0, 0x85, info);
+	mdelay(10);
+
+	/*
+	 * The following needs to be set before the call
+	 * to var_to_pll() below. They'll be re-set again
+	 * to the same values in aty_init().
+	 */
+	info->ref_clk_per = 100000000UL/card->ref_crystal;
+	info->ram_type = card->mem_type;
+	info->total_vram = card->mem_size;
+	if (xl_card == VICTORIA) {
+		// the MCLK, XCLK are 120MHz on victoria card
+		info->mclk_per = 1000000/120;
+		info->xclk_per = 1000000/120;
+		info->features &= ~M64F_MFB_TIMES_4;
+	}
+
+	/*
+	 * Calculate mclk and xclk dividers, etc. The passed
+	 * pixclock and bpp values don't matter yet, the vclk
+	 * isn't programmed until later.
+	 */
+	if ((err = aty_pll_ct.var_to_pll(info, 39726, 8, &pll)))
+		return err;
+
+	aty_st_pll(LVDS_CNTL0, 0x00, info);
+	aty_st_pll(DLL2_CNTL, card->dll2_cntl, info);
+	aty_st_pll(V2PLL_CNTL, 0x10, info);
+	aty_st_pll(MPLL_CNTL, MPLL_GAIN, info);
+	aty_st_pll(VPLL_CNTL, VPLL_GAIN, info);
+	aty_st_pll(PLL_VCLK_CNTL, 0x00, info);
+	aty_st_pll(VFC_CNTL, 0x1B, info);
+	aty_st_pll(PLL_REF_DIV, pll.ct.pll_ref_div, info);
+	aty_st_pll(PLL_EXT_CNTL, pll.ct.pll_ext_cntl, info);
+	aty_st_pll(SPLL_CNTL2, 0x03, info);
+	aty_st_pll(PLL_GEN_CNTL, 0x44, info);
+
+	reset_clocks(info, &pll.ct, 0);
+	mdelay(10);
+
+	aty_st_pll(VCLK_POST_DIV, 0x03, info);
+	aty_st_pll(VCLK0_FB_DIV, 0xDA, info);
+	aty_st_pll(VCLK_POST_DIV, 0x0F, info);
+	aty_st_pll(VCLK1_FB_DIV, 0xF5, info);
+	aty_st_pll(VCLK_POST_DIV, 0x3F, info);
+	aty_st_pll(PLL_EXT_CNTL, 0x40 | pll.ct.pll_ext_cntl, info);
+	aty_st_pll(VCLK2_FB_DIV, 0x00, info);
+	aty_st_pll(VCLK_POST_DIV, 0xFF, info);
+	aty_st_pll(PLL_EXT_CNTL, 0xC0 | pll.ct.pll_ext_cntl, info);
+	aty_st_pll(VCLK3_FB_DIV, 0x00, info);
+
+	aty_st_8(BUS_CNTL, 0x01, info);
+	aty_st_le32(BUS_CNTL, card->bus_cntl | 0x08000000, info);
+
+	aty_st_le32(CRTC_GEN_CNTL, 0x04000200, info);
+	aty_st_le16(CONFIG_STAT0, 0x0020, info);
+	aty_st_le32(MEM_CNTL, 0x10151A33, info);
+	aty_st_le32(EXT_MEM_CNTL, 0xE0000C01, info);
+	aty_st_le16(CRTC_GEN_CNTL+2, 0x0000, info);
+	aty_st_le32(DAC_CNTL, card->dac_cntl, info);
+	aty_st_le16(GEN_TEST_CNTL, 0x0100, info);
+	aty_st_le32(CUSTOM_MACRO_CNTL, 0x003C0171, info);
+	aty_st_le32(MEM_BUF_CNTL, 0x00382848, info);
+
+	aty_st_le32(HW_DEBUG, card->hw_debug, info);
+	aty_st_le16(MEM_ADDR_CONFIG, 0x0000, info);
+	aty_st_le16(GP_IO+2, 0x0000, info);
+	aty_st_le16(GEN_TEST_CNTL, 0x0000, info);
+	aty_st_le16(EXT_DAC_REGS+2, 0x0000, info);
+	aty_st_le32(CRTC_INT_CNTL, 0x00000000, info);
+	aty_st_le32(TIMER_CONFIG, 0x00000000, info);
+	aty_st_le32(0xEC, 0x00000000, info);
+	aty_st_le32(0xFC, 0x00000000, info);
+
+	for (i=0; i<sizeof(lcd_tbl)/sizeof(lcd_tbl_t); i++) {
+		aty_st_lcd(lcd_tbl[i].lcd_reg, lcd_tbl[i].val, info);
+	}
+
+	aty_st_le16(CONFIG_STAT0, 0x00A4, info);
+	mdelay(10);
+
+	aty_st_8(BUS_CNTL+1, 0xA0, info);
+	mdelay(10);
+	
+	reset_clocks(info, &pll.ct, 1);
+	mdelay(10);
+
+	// something about power management
+	aty_st_8(LCD_INDEX, 0x08, info);
+	aty_st_8(LCD_DATA, 0x0A, info);
+	aty_st_8(LCD_INDEX, 0x08, info);
+	aty_st_8(LCD_DATA+3, 0x02, info);
+	aty_st_8(LCD_INDEX, 0x08, info);
+	aty_st_8(LCD_DATA, 0x0B, info);
+	mdelay(2);
+	
+	// enable display requests, enable CRTC
+	aty_st_8(CRTC_GEN_CNTL+3, 0x02, info);
+	// disable display
+	aty_st_8(CRTC_GEN_CNTL, 0x40, info);
+	// disable display requests, disable CRTC
+	aty_st_8(CRTC_GEN_CNTL+3, 0x04, info);
+	mdelay(10);
+
+	aty_st_pll(PLL_YCLK_CNTL, 0x25, info);
+
+	aty_st_le16(CUSTOM_MACRO_CNTL, 0x0179, info);
+	aty_st_le16(CUSTOM_MACRO_CNTL+2, 0x005E, info);
+	aty_st_le16(CUSTOM_MACRO_CNTL+2, card->custom_macro_cntl>>16, info);
+	aty_st_8(CUSTOM_MACRO_CNTL+1,
+		 (card->custom_macro_cntl>>8) & 0xff, info);
+
+	aty_st_le32(MEM_ADDR_CONFIG, card->mem_addr_config, info);
+	aty_st_le32(MEM_CNTL, card->mem_cntl, info);
+	aty_st_le32(EXT_MEM_CNTL, card->ext_mem_cntl, info);
+
+	aty_st_8(CONFIG_STAT0, 0xA0 | card->mem_type, info);
+
+	aty_st_pll(PLL_YCLK_CNTL, 0x01, info);
+	mdelay(15);
+	aty_st_pll(PLL_YCLK_CNTL, card->pll_yclk_cntl, info);
+	mdelay(1);
+	
+	reset_clocks(info, &pll.ct, 0);
+	mdelay(50);
+	reset_clocks(info, &pll.ct, 0);
+	mdelay(50);
+
+	// enable extended register block
+	aty_st_8(BUS_CNTL+3, 0x7B, info);
+	mdelay(1);
+	// disable extended register block
+	aty_st_8(BUS_CNTL+3, 0x73, info);
+
+	aty_st_8(CONFIG_STAT0, 0x80 | card->mem_type, info);
+
+	// disable display requests, disable CRTC
+	aty_st_8(CRTC_GEN_CNTL+3, 0x04, info);
+	// disable mapping registers in VGA aperture
+	aty_st_8(CONFIG_CNTL, aty_ld_8(CONFIG_CNTL, info) & ~0x04, info);
+	mdelay(50);
+	// enable display requests, enable CRTC
+	aty_st_8(CRTC_GEN_CNTL+3, 0x02, info);
+
+	// make GPIO's 14,15,16 all inputs
+	aty_st_8(LCD_INDEX, 0x07, info);
+	aty_st_8(LCD_DATA+3, 0x00, info);
+
+	// enable the display
+	aty_st_8(CRTC_GEN_CNTL, 0x00, info);
+	mdelay(17);
+	// reset the memory controller
+	aty_st_8(GEN_TEST_CNTL+1, 0x02, info);
+	mdelay(15);
+	aty_st_8(GEN_TEST_CNTL+1, 0x00, info);
+	mdelay(30);
+
+	// enable extended register block
+	aty_st_8(BUS_CNTL+3,
+		 (u8)(aty_ld_8(BUS_CNTL+3, info) | 0x08),
+		 info);
+	// set FIFO size to 512 (PIO)
+	aty_st_le32(GUI_CNTL,
+		    aty_ld_le32(GUI_CNTL, info) & ~0x3,
+		    info);
+
+	// enable CRT and disable lcd
+	aty_st_8(LCD_INDEX, 0x01, info);
+	temp = aty_ld_le32(LCD_DATA, info);
+	temp = (temp | 0x01) & ~0x02;
+	aty_st_le32(LCD_DATA, temp, info);
+
+	return 0;
+}
+

Re: Compiling Rage xlinit.c

[Richard Smith]

Steve Longerbeam wrote:

> What kernel source tree and rev is this? Xlinit.c only supports the
> Xpert98 card, nothing else, although it might be a simple matter
> to get it working with other RageXL based cards. It has never been
> ported to 2.6 either.
> 

Someone chopped on it then because the only place I've ever seen it was 
in the 2.6 tree.  In the 2.6 tree there is an xlinit.c file and a config 
option to compile it but it never shows up in the makefile and never 
gets compiled.  And if it did it would break anyway.

These patches do not appear to be in the 2.4.25 tree.

So I just assumed it was something added for 2.6.  That explains why it 
dosen't compile.  Also the 2.6 tree xlinit.c mentions the Victoria card 
as well as the Xpert98. Did someone add that?

I'm trying to adapt it to a Mobility M1 which is mach64 based.  I've 
ported it to a userspace app, fixed up the compile problems and tried to 
get all the register settings relevant to an M1.  In most cases they are 
identical.   The pll registers seem to be correct because my hsync and 
vsync are good and the right frequency but something still isn't right 
because I only get a blank screen.

If I then load the 2.4.25 atyfb and try to write an image I get a brief 
flash of some scrambled data and then back to a black screen.

Loading X appears to work fine and I have a big white square for a mouse 
cursor which moves around as it should  but still black screen.

I suspect that I have something messed up with my memory settings.




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Steve Longerbeam]

Richard Smith wrote:

> Steve Longerbeam wrote:
>
>> What kernel source tree and rev is this? Xlinit.c only supports the
>> Xpert98 card, nothing else, although it might be a simple matter
>> to get it working with other RageXL based cards. It has never been
>> ported to 2.6 either.
>>
>
> Someone chopped on it then because the only place I've ever seen it 
> was in the 2.6 tree.  In the 2.6 tree there is an xlinit.c file and a 
> config option to compile it but it never shows up in the makefile and 
> never gets compiled.  And if it did it would break anyway.
>
> These patches do not appear to be in the 2.4.25 tree.
>
> So I just assumed it was something added for 2.6.  That explains why 
> it dosen't compile.  Also the 2.6 tree xlinit.c mentions the Victoria 
> card as well as the Xpert98. Did someone add that? 


I added that originally, forgot to mention it. Yes, if you were
to by miracle get a hold of a Victoria card, you would see that
it gets initialized fine with xlinit. ATI lent me one for development.
It's very similar to the Xpert98, different video memory type and
pixel clocks though.

>
>
> I'm trying to adapt it to a Mobility M1 which is mach64 based.


Is the M1 Rage XL? If not, I'm not sure xlinit.c will be of much use
to you. Keep in mind that xlinit.c was a serious reverse engineering
hack job. I used a PCI bus analyzer to capture the bus I/O activity
created by the Xpert98's BIOS. Then converted the capture output
to C, and tried to make it look half sensible without breaking the
card init. Most of the delays in xlinit.c are the actual time deltas
reported by the bus analyzer between RageXL register accesses.
The point I'm trying to make is that xlinit.c is verbatim init
activity from specifically the Xpert98 card's BIOS. So I have
very little confidence that it will successfully init any other
type of mach64 card.

This reverse engineering job was necessary because ATI does not
publish documentation on how to initialize their chips, atleast not
for the mach64 family. Maybe that's changed now, but not when
I was doing the work.

Steve

>   I've ported it to a userspace app, fixed up the compile problems and 
> tried to get all the register settings relevant to an M1.  In most 
> cases they are identical.   The pll registers seem to be correct 
> because my hsync and vsync are good and the right frequency but 
> something still isn't right because I only get a blank screen.
>
> If I then load the 2.4.25 atyfb and try to write an image I get a 
> brief flash of some scrambled data and then back to a black screen.
>
> Loading X appears to work fine and I have a big white square for a 
> mouse cursor which moves around as it should  but still black screen.
>
> I suspect that I have something messed up with my memory settings.
>
>
>



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Richard Smith]

Steve Longerbeam wrote:

> Is the M1 Rage XL? If not, I'm not sure xlinit.c will be of much use
> to you. Keep in mind that xlinit.c was a serious reverse engineering
> hack job. I used a PCI bus analyzer to capture the bus I/O activity

Its not a XL directly but the programming manual is the same for all the 
Rage based chips.  I haven't done a register to register compare but 
most every thing seems to jive with the docs I have.

 > created by the Xpert98's BIOS. Then converted the capture output
 > to C, and tried to make it look half sensible without breaking the
 > card init. Most of the delays in xlinit.c are the actual time deltas

This explains/answers some of the next questions I was going to ask 
about the whys of what that code does.  Some of the settings are confusing.

> very little confidence that it will successfully init any other
> type of mach64 card.

That may be true...  But from what I've gone through so far the bit 
values that are in the registers are really close to what I think they 
should be from looking at the docs.  However, if the inter-register 
timing is crucial then that changes things.

> This reverse engineering job was necessary because ATI does not
> publish documentation on how to initialize their chips, atleast not
> for the mach64 family. Maybe that's changed now, but not when
> I was doing the work.

I think this has changed.  I've received code from ATI that can do a 
biosless init of a RAGE III and a RAGE Pro.  Both mach64 based.  I've 
also got permission from them to release whatever I end up with GPL.

That code however doesn't understand the M1 and its really, messy.  I've 
managed to port it over as well but I get the same damn black screen. 
Clocks are ok but no actual video output.

I've also got the VBIOS source kit.  But going through that code is very 
painful.  I'm good with assembly but it just sucks trying to figure out 
what they are doing register by freaking register.

I guess that's all I have left though, the VBIOS source and perhaps 
using a bus analyzer like you did.  The analyzer may be faster 
considering the level I'm already at where I think I just have a few 
bits messed up in a memory config register.

Ok well thanks for all your info.  Oh BTW what PCI analyzer did you use? 
  We don't have one.  Are there some simple ones that I can get for a 
few hundred dollars?




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Steve Longerbeam]

Richard Smith wrote:

> Steve Longerbeam wrote:
>
>> Is the M1 Rage XL? If not, I'm not sure xlinit.c will be of much use
>> to you. Keep in mind that xlinit.c was a serious reverse engineering
>> hack job. I used a PCI bus analyzer to capture the bus I/O activity
>
>
> Its not a XL directly but the programming manual is the same for all 
> the Rage based chips.  I haven't done a register to register compare 
> but most every thing seems to jive with the docs I have.
>
> > created by the Xpert98's BIOS. Then converted the capture output
> > to C, and tried to make it look half sensible without breaking the
> > card init. Most of the delays in xlinit.c are the actual time deltas
>
> This explains/answers some of the next questions I was going to ask 
> about the whys of what that code does.  Some of the settings are 
> confusing.
>
>> very little confidence that it will successfully init any other
>> type of mach64 card.
>
>
> That may be true...  But from what I've gone through so far the bit 
> values that are in the registers are really close to what I think they 
> should be from looking at the docs.  However, if the inter-register 
> timing is crucial then that changes things. 


well, maybe you can get it running with a little work then. One thing
I forgot to mention: xlinit.c is reading the PCI_SUBSYSTEM_ID and
looking for the xpert98/Victoria subid's - you should add a case for the M1
and a new xl_card_cfg_t table entry if you know those values for the M1.

>
>
>> This reverse engineering job was necessary because ATI does not
>> publish documentation on how to initialize their chips, atleast not
>> for the mach64 family. Maybe that's changed now, but not when
>> I was doing the work.
>
>
> I think this has changed.  I've received code from ATI that can do a 
> biosless init of a RAGE III and a RAGE Pro.  Both mach64 based.  I've 
> also got permission from them to release whatever I end up with GPL.
>
> That code however doesn't understand the M1 and its really, messy.  
> I've managed to port it over as well but I get the same damn black 
> screen. Clocks are ok but no actual video output.
>
> I've also got the VBIOS source kit.  But going through that code is 
> very painful.  I'm good with assembly but it just sucks trying to 
> figure out what they are doing register by freaking register.
>
> I guess that's all I have left though, the VBIOS source and perhaps 
> using a bus analyzer like you did.  The analyzer may be faster 
> considering the level I'm already at where I think I just have a few 
> bits messed up in a memory config register.
>
> Ok well thanks for all your info.  Oh BTW what PCI analyzer did you 
> use?  We don't have one.  Are there some simple ones that I can get 
> for a few hundred dollars? 


I don't remember the name of the analyzer I used, I will find out and 
let you know.

Steve




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Ville Syrjälä]

On Fri, May 14, 2004 at 06:57:47PM -0500, Richard Smith wrote:
> Steve Longerbeam wrote:
> 
> >Is the M1 Rage XL? If not, I'm not sure xlinit.c will be of much use
> >to you. Keep in mind that xlinit.c was a serious reverse engineering
> >hack job. I used a PCI bus analyzer to capture the bus I/O activity
> 
> Its not a XL directly but the programming manual is the same for all the 
> Rage based chips.  I haven't done a register to register compare but 
> most every thing seems to jive with the docs I have.

Looking at the specs the chips look quite similar. XC is the basic model, 
XL has a TDMS transmitter and Mobility has an LVDS transmitter + CRTC2.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Holger Waechtler]

Ville Syrjälä wrote:
> On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
> 
>>--- Ville Syrjälä <syrjala@sci.fi> wrote:
>>
>>>>I said OpenGL is the only accelerated API available on Linux. Can you name
>>>>another?
>>>
>>>DirectFB.
>>
>>Does DirectFB work on anything beside Matrox now?
> 
> 
> It works on any card with a working fbdev driver (vga16fb excluded). 
> Hardware acceleration is available on quite a few chips these days.
> 
> ati128  cyber5k  mach64  neomagic  nvidia  savage  tdfx
> cle266  i810     matrox  nsc       radeon  sis315

Keep in mind that beside the matrox driver almost none of them 
implements the full accelerated 2D API and that most are misusing the 3D 
engine to implement 2D functionality. Alpha blended stretch blits are 
almost always implemented using the 3D texture engines on PC graphics cards.

About one third of these drivers have been written using specs and 
documentation files that have never been officially released by the 
hardware vendors, so I'm not really sure whether they are much better 
from a security point of view than a closed source driver -- what's the 
point of a open source hardware driver without hardware specs? - you're 
not really able to review it seriously.

The specs for the remaining ones usually showed up as soon the hardware 
was getting outdated. Basically the same situation like the one you see 
with DRI drivers.


> That's the list of drivers in DirectFB cvs. Plus there is at least one 
> driver outside the DirectFB tree.
> 
> I use matrox and mach64 drivers daily. It's been a few years since I 
> seriously used XFree86.

Have you ever thought about the inherent security risks of memory mapped 
i/o registers when executing non-trusted applications? Imagine what 
happens if every single application is allowed to program the blitter 
and texture engines to copy host memory from anywhere in the system to 
graphics memory and back - a single misbehaving application can damage 
your entire system.

And do you really have the time to review every line of code you execute 
on your system?


>>>>There is a little acceleration in framebuffer, but I don't know of any
>>>>others. Also, software mesa works just fine to provide OpenGL on dumb 2D
>>>
>>>cards.
>>>
>>>Using unaccelerated OpenGL for 2D rendering doesn't sound exatly useful. 
>>
>>There is much more to 2D rendering in things like the Mac UI and Longhorn than
>>can be accomplished with BitBlt. You need transforms, filters and alpha
>>blending. Hardware texturing is much faster than doing it in software. Some of
>>the effects are achieved with pixel shaders. xserver features a fully composited
>>window manager, it needs these features to have a fast response time.
>>
>>OpenGL to me seems like the best pick for these reasons:
>>1) with have a good open source version, mesa
>>2) mesa supports a broad number of cards, basically everything there is doc for
> 
> 
> Just about as broad as DirectFB.

be honest.


>>3) OpenGL is a well published API, it is taught in universities and many books
>>are available
>>4) It is likely that Nvidia and ATI will support standalone OpenGL stacks for
>>their high end hardware on Linux
>>5) OpenGL is cross-platform. For example Cairo is being written with an OpenGL
>>back end. OpenGL Cairo will run on Window and the Mac too. This will make Linux
>>apps more portable.
>>6) The embedded market has OpenGL-ES which can run in less than 100K.
>>
>>What would be reasons for picking another API?

:) well - I could see one, but that's not the point here, as soon you 
have a secure low-level GPU interface you can place any API wrapper you 
want above this, OpenGL is just one of multiple choices. But probably 
the one that's most familiar to most of us.

Even a secure DirectFB port would be possible on top of this interface 
if you don't need any 3D graphics (you remember the DirectFB-on-SDL 
system target?).


> DirectFB is good for a few reasons:
> - Input handling
> - Easy access to hardware overlays
> - YUV formats
> - Ease of porting DirectX applications
> - Good acceleration
> - Easy API / personal preference
> 
> I'm not suggesting that everyone start using DirectFB. Everyong should be 
> able to use any API they want. The kernel should provide just enough to 
> allow these APIs to be implemented.

that would be always possible, don't worry.

Please keep in mind that we developed DirectFB at Convergence as API to 
access SettopBox and Game Console functionality in a convenient way, it 
was never intended and has not been designed for use in 
security-critical desktop or workstation environments.

Holger


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Ville Syrjälä]

On Sat, May 15, 2004 at 09:27:34AM +0200, Holger Waechtler wrote:
> Ville Syrjälä wrote:
> >On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
> >
> >>Does DirectFB work on anything beside Matrox now?
> >
> >
> >It works on any card with a working fbdev driver (vga16fb excluded). 
> >Hardware acceleration is available on quite a few chips these days.
> >
> >ati128  cyber5k  mach64  neomagic  nvidia  savage  tdfx
> >cle266  i810     matrox  nsc       radeon  sis315
> 
> Keep in mind that beside the matrox driver almost none of them 
> implements the full accelerated 2D API

cle266 is about the same level as matrox. I could get mach64 into this 
group with some modifications to the memory allocator. I think for some of 
the other drivers the biggest problem is lack of developers.

> and that most are misusing the 3D 
> engine to implement 2D functionality. Alpha blended stretch blits are 
> almost always implemented using the 3D texture engines on PC graphics cards.

I don't consider that mis-use, simply use.

> About one third of these drivers have been written using specs and 
> documentation files that have never been officially released by the 
> hardware vendors, so I'm not really sure whether they are much better 
> from a security point of view than a closed source driver -- what's the 
> point of a open source hardware driver without hardware specs? - you're 
> not really able to review it seriously.

I don't think the specs would help in that regard much. For all you know 
the specs could be all wrong. If you have the code and can see the 
expected results that usually means the code works correctly. And closed 
source kernel drivers could do a lot of other nasty stuff even without 
touching the hardware.

> The specs for the remaining ones usually showed up as soon the hardware 
> was getting outdated. Basically the same situation like the one you see 
> with DRI drivers.

Except now the specs are getting harder to get even for old hardware. The 
vendors seem to be returning to the old ways :(

> >I use matrox and mach64 drivers daily. It's been a few years since I 
> >seriously used XFree86.
> 
> Have you ever thought about the inherent security risks of memory mapped 
> i/o registers when executing non-trusted applications? Imagine what 
> happens if every single application is allowed to program the blitter 
> and texture engines to copy host memory from anywhere in the system to 
> graphics memory and back - a single misbehaving application can damage 
> your entire system.

I am aware of the risks. Currently it's not an issue for me. And if I 
limit myself to running only XDirectFB the risk is equal to running 
accelerated XFree86. Of course I would be glad to make it all secure but 
only without losing any of the nice features.

> And do you really have the time to review every line of code you execute 
> on your system?

Clearly not. There is some stuff you just have to trust (or not care).

> >>2) mesa supports a broad number of cards, basically everything there is 
> >>doc for
> >
> >
> >Just about as broad as DirectFB.
> 
> be honest.

I am. This is the list of drivers in Mesa cvs:
i810   mga     radeon  tdfx 
ffb    i830    r128  savage  unichrome
gamma  mach64  r200  sis

The list is almost the same as the DirectFB driver list. Granted that some 
of the Mesa drivers use more of the hardware's capabilities, but that's 
only because I don't have the hardware ;)

> >I'm not suggesting that everyone start using DirectFB. Everyong should be 
> >able to use any API they want. The kernel should provide just enough to 
> >allow these APIs to be implemented.
> 
> that would be always possible, don't worry.

I do worry a bit because of this OpenGL as the one and only API talk.

> Please keep in mind that we developed DirectFB at Convergence as API to 
> access SettopBox and Game Console functionality in a convenient way, it 
> was never intended and has not been designed for use in 
> security-critical desktop or workstation environments.

I am aware of that and that's why I don't recommend it to everyone. 
Personally I just find it to my liking. Even the code itself makes me 
a happy camper whereas XFree86 code gives me a headache...

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click

Re: Re: [Linux-fbdev-devel] Redesign of kernel graphics interface

[Alan Cox]

On Gwe, 2004-05-14 at 19:40, Jon Smirl wrote:
> Does DirectFB work on anything beside Matrox now?

Most cards, accelerated on quite a few including VIA. This is getting
into detail. If your 3D sucks you dont us OpenGL as the basis of your
whizzo console driver - just as MS plan to support the older UI for
older hardware.

> the effects are achieved with pixel shaders. xserver features a fully composited
> window manager, it needs these features to have a fast response time.

You need a 1mS response time at the most extreme. Indeed at 70Hz you
need a lot less

> What would be reasons for picking another API?

Its large, doesn't cover some functionality and doesn't map well to some
hardware. If you've got a DRI layer you don't have to *care*
what user space library is used and you certainly don't want to dictate
it



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[James Simmons]

Sorry about the delayed response. I recieved that patch along time ago. 
It was ported to 2.6.X and I placed it into the BK repo for fbdev.
Xui from tyan sent me a patch to get it going. Since you have the specs to 
boot from scratch I really like to work with you on this. The code for the 
mach64 is old. I have newer code in my BK repos. If you need a patch I can 
send it to you.


> > Is the M1 Rage XL? If not, I'm not sure xlinit.c will be of much use
> > to you. Keep in mind that xlinit.c was a serious reverse engineering
> > hack job. I used a PCI bus analyzer to capture the bus I/O activity
> 
> Its not a XL directly but the programming manual is the same for all the 
> Rage based chips.  I haven't done a register to register compare but 
> most every thing seems to jive with the docs I have.
> 
>  > created by the Xpert98's BIOS. Then converted the capture output
>  > to C, and tried to make it look half sensible without breaking the
>  > card init. Most of the delays in xlinit.c are the actual time deltas
> 
> This explains/answers some of the next questions I was going to ask 
> about the whys of what that code does.  Some of the settings are confusing.
> 
> > very little confidence that it will successfully init any other
> > type of mach64 card.
> 
> That may be true...  But from what I've gone through so far the bit 
> values that are in the registers are really close to what I think they 
> should be from looking at the docs.  However, if the inter-register 
> timing is crucial then that changes things.
> 
> > This reverse engineering job was necessary because ATI does not
> > publish documentation on how to initialize their chips, atleast not
> > for the mach64 family. Maybe that's changed now, but not when
> > I was doing the work.
> 
> I think this has changed.  I've received code from ATI that can do a 
> biosless init of a RAGE III and a RAGE Pro.  Both mach64 based.  I've 
> also got permission from them to release whatever I end up with GPL.
> 
> That code however doesn't understand the M1 and its really, messy.  I've 
> managed to port it over as well but I get the same damn black screen. 
> Clocks are ok but no actual video output.
> 
> I've also got the VBIOS source kit.  But going through that code is very 
> painful.  I'm good with assembly but it just sucks trying to figure out 
> what they are doing register by freaking register.
> 
> I guess that's all I have left though, the VBIOS source and perhaps 
> using a bus analyzer like you did.  The analyzer may be faster 
> considering the level I'm already at where I think I just have a few 
> bits messed up in a memory config register.
> 
> Ok well thanks for all your info.  Oh BTW what PCI analyzer did you use? 
>   We don't have one.  Are there some simple ones that I can get for a 
> few hundred dollars?
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 





-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[Richard Smith]

James Simmons wrote:

> Sorry about the delayed response. I recieved that patch along time ago. 
> It was ported to 2.6.X and I placed it into the BK repo for fbdev.
> Xui from tyan sent me a patch to get it going. Since you have the specs to 
> boot from scratch I really like to work with you on this. The code for the 
> mach64 is old. I have newer code in my BK repos. If you need a patch I can 
> send it to you.

Cool.  Hook me up.  Does the stuff in your BK contain all the M1 mods 
from recient 2.4?  I've tried your fbdiff patch but it wouldn't apply to 
2.6.6 so I just used what was stock in 2.6.6.

I don't think the newer Mach64 code will make any difference right now 
though.  If I run xlinit (with my mods) on a chip with only POR I don't 
get a sync yet.

So I'm  still missing something.  I've got some questions pending with 
ATI dev support and thier supposed to be trying to get me some info 
(other than the bios source) on bringing up the chip from scratch.




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Compiling Rage xlinit.c

[James Simmons]

> > Sorry about the delayed response. I recieved that patch along time ago. 
> > It was ported to 2.6.X and I placed it into the BK repo for fbdev.
> > Xui from tyan sent me a patch to get it going. Since you have the specs to 
> > boot from scratch I really like to work with you on this. The code for the 
> > mach64 is old. I have newer code in my BK repos. If you need a patch I can 
> > send it to you.
> 
> Cool.  Hook me up.  Does the stuff in your BK contain all the M1 mods 
> from recient 2.4?  I've tried your fbdiff patch but it wouldn't apply to 
> 2.6.6 so I just used what was stock in 2.6.6.

Yes. Plus a few extra features like power management.
 
> I don't think the newer Mach64 code will make any difference right now 
> though.  If I run xlinit (with my mods) on a chip with only POR I don't 
> get a sync yet.
> 
> So I'm  still missing something.  I've got some questions pending with 
> ATI dev support and thier supposed to be trying to get me some info 
> (other than the bios source) on bringing up the chip from scratch.

Okay. I will send you a patch soon for your use.





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click