--- Felix Kühling [EMAIL PROTECTED] wrote:
On Sun, 05 Sep 2004 20:14:43 -0400
Lee Revell [EMAIL PROTECTED] wrote:
On Sun, 2004-09-05 at 16:18, Patrick McFarland wrote:
[snip]
That shouldn't matter, should it? The userland stuff should never
lock
the machine up.
I'll test it
Most IMPORTANT is that some-one some-where there is a list of ALL of
these. These are best in the form of code comments so the the respective
places in the code can be changed.
--- Dave Airlie [EMAIL PROTECTED] wrote:
Dose the DRM varify that the cmds are in this order? Why not just
have
Patrick McFarland wrote:
On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote:
In some cases yes. The DRM is happy with the idea of the kernel being a
DRM client too.
Thats actually a pretty cool idea. For us that need to use the vesa
fbcon driver because
there is no native
Jon Smirl wrote:
They have to be merged. Cards with two heads need the mode set on each
head. fbdev only sets the mode on one head. If I teach fbdev how to
set the mode of the other head fbdev needs to learn about memory
management. The DRM memory management code is complex and is a big
chunk of
On Mon, 06 Sep 2004 14:12:08 -0400, Michel Dänzer [EMAIL PROTECTED] wrote:
You can test the r200_dri.so from the snapshot with the DRM from the
kernel...
And drum roll please...
The dri cvs snapshot works fine on both it's own kernel module, and
the one that comes
with 2.6.8.1. So now what?
On Tue, 7 Sep 2004 05:07:45 -0400, Patrick McFarland [EMAIL PROTECTED] wrote:
Lots of badly formatted text.
I do apologize for anyone who had to read that.
--
Patrick Diablo-D3 McFarland || [EMAIL PROTECTED]
Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be
Mike Mestnik wrote:
Most IMPORTANT is that some-one some-where there is a list of ALL of
these. These are best in the form of code comments so the the respective
places in the code can be changed.
--- Dave Airlie [EMAIL PROTECTED] wrote:
Dose the DRM varify that the cmds are in this order? Why
I've applied this ...
Dave.
On Mon, 6 Sep 2004, Philipp Klaus Krause wrote:
This patch enables GL_ARB_vertex_program and GL_NV_vertex_program
support in the r200 driver. Both extensions can be enabled via
options, GL_ARB_vertex_program is on by default, GL_NV_vertex_program
off. Option
On Maw, 2004-09-07 at 10:07, Patrick McFarland wrote:
Also, what happens to r200 users who happen to use Debian? Using dri
cvs snapshots
If Debian is currently shipping a buggy driver then Debian needs to ship
a working driver. Same as anyone else. You'll also need the newest
dri driver for
On Mon, 6 Sep 2004 20:16:12 -0400
Jon Smirl [EMAIL PROTECTED] wrote:
I decided my loop was too fancy so I just deleted it and replaced it
with a simple flag. If the driver uses permanent maps the flag gets
set and addmaps from user space have no effect. If the driver doesn't
use permanent
On Mon, 6 Sep 2004 19:56:49 -0400
Jon Smirl [EMAIL PROTECTED] wrote:
AddMap has the loop to find the existing mapping and replace it.
initmap doesn't have that loop so it allows multiple adds. I wanted to
just make AddMap refuse a REG/FB map request but I was trying to be
compatible while we
On Mon, 06 Sep 2004 23:09:34 +0100
Alan Cox [EMAIL PROTECTED] wrote:
On Llu, 2004-09-06 at 22:50, Felix Kühling wrote:
We want the description strings in all available languages to be
compiled into the 3D drivers. All these macros result in a small
XML-document which is looked up via
On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
I would also like to fix things so that we can have two logged in
users, one on each head. This isn't going to work if one them uses
fbdev and keeps swithing the chip to 2D mode while the other user is
Here's a new version that should be compatible with all of the cases:
1) multiple maps
2) old X doing AddMap
3) fixed X doing GetMap - X needs to switch to this after all the
drivers get fixed
4) drivers that have implemented permanent maps
4) drivers that have not implemented permanent maps
I
Jon Smirl wrote:
Here's a new version that should be compatible with all of the cases:
1) multiple maps
2) old X doing AddMap
3) fixed X doing GetMap - X needs to switch to this after all the
drivers get fixed
4) drivers that have implemented permanent maps
4) drivers that have not implemented
New version of same patch without the whitespace clean up
On Tue, 07 Sep 2004 16:59:09 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Ugh. If we're going to do whitespace changes can we do them seperately to
proper changes, please?
Keith
--
Jon Smirl
[EMAIL PROTECTED]
=
r200_context.c shows the following:
if(driQueryOptionb(rmesa-optionCache,
arb_vertex_program))
_mesa_enable_extension( ctx,
GL_ARB_vertex_program);
if(driQueryOptionb(rmesa-optionCache,
nv_vertex_program))
_mesa_enable_extension( ctx,
GL_NV_VERTEX_PROGRAM);
Should the nvidia extension be in
Michael Mazack schrieb:
r200_context.c shows the following:
if(driQueryOptionb(rmesa-optionCache,
arb_vertex_program))
_mesa_enable_extension( ctx,
GL_ARB_vertex_program);
if(driQueryOptionb(rmesa-optionCache,
nv_vertex_program))
_mesa_enable_extension( ctx,
GL_NV_VERTEX_PROGRAM);
Should the
Philipp Klaus Krause wrote:
So I'll add driconf options for both GL_ARB_vertex_program
(on by default) and GL_NV_vertex_program (off by default).
Maybe we should add the 1.4 extensions and make an option
for GL_ARB_depth_texture someday.
That might be useful. Add driconf options for For all GL
On 07.09.2004, at 18:54, Jon Smirl wrote:
I used sed:
sed -e 's/[ ]*$//' $TMP $1
to strip the trailing white space from all of the DRM files.
Any objections to a check in? Kernel rules for patches are no trailing
white space.
while you're at doing whitespace commits: there is a bunch of
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core
Jon Smirl wrote:
I'm a little concerned that we are doing a lot of work to support a
few people (100) using DRM on BSD. I suspicious that it is a very
small number since we get close to zero complaints about BSD even
though we break it continuously.
I think the difference may be that BSD users
Thanks. This reenables 3D accel on the Savage. I havn't tested it on any
other driver. But the patch looks good to me.
Regards,
Felix
On Tue, 7 Sep 2004 11:39:59 -0400
Jon Smirl [EMAIL PROTECTED] wrote:
Here's a new version that should be compatible with all of the cases:
1) multiple maps
I'd be interested to know if you can get permanent maps working in the
Savage driver. I sent the example of how the radeon does it.
On Tue, 7 Sep 2004 23:08:00 +0200, Felix Kühling [EMAIL PROTECTED] wrote:
Thanks. This reenables 3D accel on the Savage. I havn't tested it on any
other driver.
When we get to a point that there are no big patches pending I'd like
to run the whole thing through ident with the default kernel indent
rules. But doing that will break any pending patches.
Just stripping the white space off from the end shouldn't upset any development.
On Tue, 7 Sep 2004
I just checked and we have trailing blanks all over the place in the
kernel tree too. Instead of just fixing the trailing blanks maybe we
should bite the bullet and run indent over everthing. There are about
1,500 lines with trailing white space. You don't lose the blame
annotations, you just have
checking anything in. I'd prefer that route since it enforces style
rules. There's an approved set of parameters for using ident on the
kernel somewhere.
scripts/Lindent, I used it on the i915..
Dave.
On Wed, 8 Sep 2004 00:47:24 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote:
I
On Wed, 8 Sep 2004 02:34:24 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote:
scripts/Lindent, I used it on the i915..
You didn't check it in.
I'm game if you want to run it over the whole project. Let's merge
dyn-minor first so I don't have to rewrite it.
Are you ok with perm.patch going in?
sorry its in the kernel tarball...
I'm game if you want to run it over the whole project. Let's merge
dyn-minor first so I don't have to rewrite it.
Are you ok with perm.patch going in?
If it fixes up the savage put it in, the real work is starting to impinge
on my drm hacking at the
Sorry, I don't know why we are cross posting and including subscribers in
CC. This belongs on the DRI list, as it is only with 3rd party DRI-client
code that the problem exists.
--- Dave Airlie [EMAIL PROTECTED] wrote:
On Tue, 07 Sep 2004 09:07:11 +0200, Arjan van de Ven [EMAIL PROTECTED]
30 matches
Mail list logo
