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]>
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 mo
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
> 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 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
> 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.
Hold off for a while, the problem with this is generating diffs against
the kernel gets mess
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 20:43
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
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 map
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 don
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 an
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 st
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 1.
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");
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 exte
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]
= linu
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 perm
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 hav
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
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 v
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 whil
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 permanen
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 Ra
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
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
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
al
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?
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 t
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 nativ
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
> hav
30 matches
Mail list logo
