From: Nicolas Souchu <hidden> Date: 2004-05-07 00:30:29
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
quoted hunk
--- Nicolas Souchu <nsouch@free.fr> wrote:
quoted
quoted
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
From: James Simmons <hidden> Date: 2004-05-06 22:48:06
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.
quoted
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.
quoted
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
From: Jon Smirl <hidden> Date: 2004-05-07 00:50:40
--- 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
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
quoted
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
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-10 00:57:25
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
From: James Simmons <hidden> Date: 2004-05-10 16:14:04
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
--
From: Ville Syrjälä <syrjala@sci.fi> Date: 2004-05-10 16:28:37
On Mon, May 10, 2004 at 05:14:04PM +0100, James Simmons wrote:
quoted
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
From: Jon Smirl <hidden> Date: 2004-05-10 18:29:40
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:
quoted
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
From: Mike Mestnik <hidden> Date: 2004-05-10 19:16:08
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:
quoted hunk
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:
quoted
quoted
You are mixing things. Mode setting has nothing to do with
rendering. OpenGL
quoted
quoted
is a rendering client. It produces commands sent to the low level
kernel
quoted
quoted
driver and provides a 3D API, but it's not the only one. In this
regard,
quoted
quoted
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.
quoted
If we are to have a universal solution it needs to OpenGL. Either that
or
quoted
mode switching stays in the kernel.
Speaking of bloat in the kernel. When will the crypto and TCP/IP stack
be
quoted
moved to userspace. The networking code alone is over 17 megs in size.
quoted
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
__________________________________
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
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
From: James Simmons <hidden> Date: 2004-05-10 21:05:57
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-10 23:40:44
On Tue, 2004-05-11 at 02:14, James Simmons wrote:
quoted
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
From: James Simmons <hidden> Date: 2004-05-10 23:50:01
quoted
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.
quoted
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
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
From: Richard Smith <hidden> Date: 2004-05-11 22:13:57
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
From: Sven Luther <hidden> Date: 2004-05-14 17:20:11
On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
quoted hunk
--- James Simmons <jsimmons@infradead.org> wrote:
quoted
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
From: Alex Deucher <hidden> Date: 2004-05-14 17:35:56
--- Sven Luther <sven.luther@wanadoo.fr> wrote:
On Thu, May 06, 2004 at 05:50:40PM -0700, Jon Smirl wrote:
quoted
--- James Simmons <jsimmons@infradead.org> wrote:
quoted
2) Ben suggestion that we mount userland inside the kernel during
early
quoted
quoted
boot and use a userland library. If we would use a library
then it MUST
quoted
quoted
be OpenGL. This would be the forced standard on all platforms.
This
quoted
quoted
would mean Mesa would be needed to build the kernel. We could
move over
quoted
quoted
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
quoted
library that would support mode setting and cursor control.
Actually OpenGL does
quoted
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
quoted
Longhorn to use Direct3D. This was done to get at the performance
gains provided
quoted
by D3D and hardware accelerated graphics. For example a Cairo
implementation hat
quoted
uses X rendering vs Cairo on OpenGL was benchmarked at being a
100:1 faster.
quoted
A proposal has been made that OpenGL be promoted as the primary
base graphics
quoted
API on Linux. Then things like Cairo and the xserver be implemented
on top of
quoted
OpenGL.
1) OpenGL is the only fully accelerated API that Linux has. We
don't have D3D or
quoted
anything else like it. Fully accelerated interfaces are a pain to
build and it
quoted
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
From: Jon Smirl <hidden> Date: 2004-05-14 17:51:35
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
From: Ville Syrjälä <syrjala@sci.fi> Date: 2004-05-14 18:08:14
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
From: Sven Luther <hidden> Date: 2004-05-14 19:25:03
On Fri, May 14, 2004 at 10:35:56AM -0700, Alex Deucher wrote:
quoted
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.
quoted
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
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
From: Richard Smith <hidden> Date: 2004-05-14 19:41:47
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
From: Steve Longerbeam <hidden> Date: 2004-05-14 21:28:27
Richard Smith wrote:
Richard Smith wrote:
quoted
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
From: Richard Smith <hidden> Date: 2004-05-14 22:16:55
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
From: Steve Longerbeam <hidden> Date: 2004-05-14 22:48:32
Richard Smith wrote:
Steve Longerbeam wrote:
quoted
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
From: Richard Smith <hidden> Date: 2004-05-14 23:58:53
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
From: Steve Longerbeam <hidden> Date: 2004-05-15 00:22:56
Richard Smith wrote:
Steve Longerbeam wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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
From: Ville Syrjälä <syrjala@sci.fi> Date: 2004-05-15 00:42:54
On Fri, May 14, 2004 at 06:57:47PM -0500, Richard Smith wrote:
Steve Longerbeam wrote:
quoted
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
From: James Simmons <hidden> Date: 2004-05-18 22:06:24
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.
quoted
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.
quoted
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.
quoted
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
From: Richard Smith <hidden> Date: 2004-05-19 14:37:15
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
From: James Simmons <hidden> Date: 2004-05-19 22:20:32
quoted
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