On Gwe, 2004-08-06 at 18:16, Jon Smirl wrote:
fbdev is in exactly this model and it isn't causing anyone problems.
The simple rule is that if you want to upgrade fbdev past the current
version you have to do it in entirety. You do that for fbdev but
pulling bk://fbdev.bkbits.net/. But Joe user
On Sat, Aug 07, 2004 at 01:11:21AM +0100, Dave Airlie wrote:
fbdev only has one distribution vector - the kernel, DRM has multiple
distribution vectors, kernel, DRI snapshots, X releases, they all contain
their own DRM modules, also people with older kernels should be able to
which is the root
On Fri, Aug 06, 2004 at 05:54:52PM +0100, Keith Whitwell wrote:
Yes, while I support the current rework and de-templatization of the code, I
don't support any attempt to split the drm modules to try and share code at
runtime - ie. I don't support a core/submodule approach.
We had that
On Fri, Aug 06, 2004 at 12:54:26AM +0100, Dave Airlie wrote:
I guess one (unpleasant) way to make it work would be to add the version to
all the symbols in the device-independent layer. Instead of drm_foo you'd
have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple
On Sat, Aug 07, 2004 at 02:31:07PM +0100, Alan Cox wrote:
And thats one of the big reasons its such a mess and doesn't work out.
Nobody is testing or reviewing it until some huge merge point occurs
at which point you run the risk of people saying Actually your design
sucks, or in the 2.6 case
On Fri, Aug 06, 2004 at 10:46:45AM -0700, Jon Smirl wrote:
There are three main ways to get a driver:
1) vendor release - most stable, I get one every two weeks
2) Linus bk - very up to date, not as well tested, once a day
3) copy DRM CVS into Linus bk - bleeding edge, hope you know what
On Thu, Aug 05, 2004 at 04:19:55PM -0700, Ian Romanick wrote:
module and the card dependant one.. I can see people building their own
card drivers from the DRM CVS and trying to load them vs a kernel with a
built-in DRM core.. my current thinking on this is we use the Kconfig to
try and
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into the
kernel. Why don't we just change the Makefile to default to copying the
CVS code into the kernel source tree and tell the user to rebuild his
kernel?
I don't think that will fly with Joe-user that just wants to
Dave Jones wrote:
On Thu, Aug 05, 2004 at 04:19:55PM -0700, Ian Romanick wrote:
module and the card dependant one.. I can see people building their own
card drivers from the DRM CVS and trying to load them vs a kernel with a
built-in DRM core.. my current thinking on this is we use the
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into the
kernel. Why don't we just change the Makefile to default to copying the
CVS code into the kernel source tree and tell the user to rebuild his
kernel?
I don't think that will fly with Joe-user
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into
the kernel. Why don't we just change the Makefile to default to
copying the CVS code into the kernel source tree and tell the
user to
Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into
the kernel. Why don't we just change the Makefile to default to
copying the CVS code into the kernel source tree and tell the
user to
The key here is that distributions release new kernels at a rapid pace.
This is not X where we get a new release every five years. The standard
mechanism for upgrading device drivers in Linux is to add them to the
kernel and wait for a release.
So, people have to reboot to install a new
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Sorry, I don't buy it. Graphics drivers are a special case and
people upgrade them with a passion... No new interfaces, thankyou.
I get a new kernel from Redhat about every two weeks. Redhat is at
2.6.7 and Linus is at 2.6.8. Nobody releases
--- Keith Whitwell [EMAIL PROTECTED] wrote:
The key here is that distributions release new kernels at a rapid
pace.
This is not X where we get a new release every five years. The
standard
mechanism for upgrading device drivers in Linux is to add them to
the
kernel and wait for a
On Fri, Aug 06, 2004 at 09:38:10AM -0700, Ian Romanick wrote:
For agpgart it hasn't really been an issue as all the development there
in the last year or two has been done in tree. Yes, there has been some
work on things like i915 out-of-tree, but that stuff has been merged up
pretty
fbdev is in exactly this model and it isn't causing anyone problems.
The simple rule is that if you want to upgrade fbdev past the current
version you have to do it in entirety. You do that for fbdev but
pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is
something only
Dave Airlie wrote:
The only thing I can think off is maybe adding this stuff to another C
file per driver but that probably isn't necessary ... the other idea I've
had is to perhaps separate the function table when we get the full table
done, then we can have tables per functionality group, i.e.
I looked at the code currently in CVS. Is it the most recent? I know CVS
commits to X.org servers are toast right now.
I've another bunch of changes pending on my PC at home, these get rid of
the kernel context switch stuff for the sparc and the context ctor/dtor
macros...
if (
Dave Airlie wrote:
I'd rather have drivers init all the functions to some generic, noop function.
I think that makes the code a lot cleaner to read.
I've thought about this and wasn't sure how acceptable adding a load of
NOP function calls would be.. I'm not sure too many of the current ptrs
are
[lk ppl have a look at the start of this thread in the dri-devel archives
on marc.theaimsgroup.com...]
I guess one (unpleasant) way to make it work would be to add the version to
all the symbols in the device-independent layer. Instead of drm_foo you'd
have drm_foo_100 or drm_foo_101 or
Since very few (any?) of the functions have a return value, couldn't you just
use the same function for all of them?
hmm at the moment 8 of them do return values, 5 don't .. not sure if all
the returns are necessary but I think they are...
Dave.
--
David Airlie, Software Engineer
On Thu, Aug 05, 2004 at 11:44:48PM +0100, Dave Airlie wrote:
if ( dev-fn_tbl.foo )
def-fn_tbl.foo();
I'd rather have drivers init all the functions to some generic, noop function.
I think that makes the code a lot cleaner to read.
I've thought about this and wasn't
The only thing I can think off is maybe adding this stuff to another C
file per driver but that probably isn't necessary ... the other idea I've
had is to perhaps separate the function table when we get the full table
done, then we can have tables per functionality group, i.e. adding the dma
Okay I've created a drm branch drmfntbl-0-0-1 and I've commited the work
I've done so far, i830, mach64, radeon and gamma should be working, I've
only tested the radeon really, I don't even own a gamma (but it causes a
lot of the issues :-)
The current patch is at
25 matches
Mail list logo
