Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 08:16:36PM +0100, Alan Cox wrote: On Sad, 2004-04-17 at 19:40, Ryan Underwood wrote: Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. It was specifically in response to the question about firmware, and whether it would be better if firmware was seperated. I don't know of any direct case law on embedding firmware and at what point it isn't mere aggregation So your advisor is saying that such a work is undistributable under the GPL, or are they saying that it is not distributable at all? I'm also curious if they would draw the same conclusion if you had some form of interpretable bytecode that is embedded into the binary. It doesn't run on any CPU, but nevertheless is classified software by most definitions since it executes in a virtual machine. You might say then that the bytecode is not the preferred form of modification according to the GPL, but if I wrote an interpreter and no other tools to go with it, it has no other form in which it can be modified. This is borderline pedantry, but boundary cases must be considered if we are to make wise decisions. I don't think any of this really addresses the DFSG though. Some Debian folks are removing firmware which is freely distributable and not being combined/aggregated with GPL drivers, on the basis that it is software and thus must be DFSG-free according to the social contract. One requirement to be DFSG-free is that source must be made available, so these firmware don't satisfy it and are removed. My opinion is that this only makes sense when the target is known to be a general purpose computer and the firmware image is known to contain a program that is executed by its CPU. Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] DRI/Xfree86 Merge
On Sun, 2004-04-18 at 04:19, Donnie Berkholz wrote: On Sat, 2004-04-17 at 07:54, Alan Hourihane wrote: On Sat, Apr 17, 2004 at 01:18:49AM +0200, Michel Dnzer wrote: On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote: I could merge in XFree86 4.3.99.902 which is before the license change Are you sure? AFAIK David applied the new license (or at least a similarly controversial one) to some files before it was publicly announced. Yes, I'm positive that 4.3.99.902 is unencumbered. I'm pretty sure the autoconfig work, under the X-Oz license (nearly identical to the problematic one), was in at that point. Right, that's what I was thinking of. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Questions about current status of DRI
On Sun, 2004-04-18 at 04:55, Vladimir Dergachev wrote: On Sun, 18 Apr 2004, Michel [ISO-8859-1] Dnzer wrote: On Sun, 2004-04-18 at 03:19, Vladimir Dergachev wrote: 3. Can anyone tell me what changes are required in order to enable idle DRI for R300 and above ? (I.e. DRM module starts up, 2d commands go through DRM , but Mesa driver does software rendering). The infamous CP microcode is needed. AFAIK, Benjamin Herrenschmidt got it from ATI. I might have it too, though one can never tell whether it works without experiment (i.e. it might just be a copy of R200 microcode). No, at least the 3D parts obviously have to be different, and IIRC Adam Kirchhoff tried the R200 microcode without success even for just 2D. I might have some success in figuring out CP sequences and present the result as a user-space library, but I doubt I will have time to dig inside Mesa. We have the docs, no need to guess... note that unprivileged user space processes can't emit CP commands directly but can only use higher level ioctls geared towards the 3D driver. May I ask what goal you are trying to achieve? Well, I wanted to make an example app that exercises as many 3d related capability as possible. With the hope that once this is published people with more knowledge of Mesa internals would be tempted to make a real driver. Ah. :) Disregard my comment above about CP docs then, I thought you were talking about R[12]00... Also, it is possible to access CP fifo via MMIO registers - if I remember this right. Yes. 5. I remember there was someone working to merge current GATOS code into DRI - did these changes made it into DRI CVS ? The GATOS DRM doesn't have anything that needs merging, does it? For the other code, the DRI tree isn't the right target IMHO. No, I meant the code that makes TV-in work. I was incredibly busy this year and did not have time to start porting to 4.4.0 codebase. You may want to discuss this with the X.Org foundation folks. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sul, 2004-04-18 at 07:52, Ryan Underwood wrote: So your advisor is saying that such a work is undistributable under the GPL, or are they saying that it is not distributable at all? They are saying that in their reading of the law it would be better if the firmware was kept seperate. Lawyers do not define the interpretation of law, especially in the absence of specific caselaw. Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive There is no difference between the two, but this is getting very off-topic --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] R200 t_vertex conversion
Keith Whitwell wrote:
Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use
t_vertex. It is only a conversion for SW TCL, and it's not quite
complete. I've managed to clean up all the crashes that I could find,
but I've only tested with gears, geartrain, and tunnel. There are
some known problems:
- The textures in tunnel are not quite right. They're sort of zig-zaggy.
- The colors of two of the gears in gears are swapped. The red gear
is blue and the blue gear is red. The green gear is correct.
I chopped out all of the _r200_render_stage stuff from r200_swtcl.c.
It is unused (due to bad interactions with UT2k3), and was only
confusing me. When this patch gets committed, that code can go back
in, I think.
There are two hacks that I had to do to get things working. Neither
of these needed to be done by the i830 or savage drivers. First, I
had to add a viewport matrix that remains an identity matrix. This
is because the Radeon chips do the viewport transform in hardware.
tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but
t_vertex apparently does not. Second, I had to force TNL to always
produce project coordinates. Again, the Radeon hardware can do the
final projection in hardware almost all the time, but due to the way
the i830 and savage drivers use use tnl-vb.NdcPtr (actually
VB-NdcPtr) I couldn't see a way around this. I may just be missing
something there.
Ah, ok. I see the problem. Basically this has to do with the fact that
choosing the hw vertex format has gone from being something (normally)
done ahead of time, prior to actually running the tnl pipeline, to
something done after that, and based on its results. The only problem
is that by this time, the pipeline has run, and it's too late to decide
whether or not to calculate projected coordinates. Oh well, it's not
too hard to do that ahead of time.
Here's an updated patch. In addition to the above, I've fixed up the way
'coloroffset' and the previously hardwired 'specoffset' are initialized. Most
stuff seems to work ok now, except tuxracer-demo, which has issues which are
probably related to polygon offset.
Keith
? diff
? drivers/dri/diff
? drivers/dri/common/diff
? drivers/dri/i830/diff
? drivers/dri/r200/diff
? drivers/dri/tdfx/diff
? tnl/backout
? tnl/c
? tnl/dead
? tnl/diff
? tnl_dd/diff
Index: drivers/dri/r200/r200_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v
retrieving revision 1.12
diff -u -r1.12 r200_context.h
--- a/drivers/dri/r200/r200_context.h 11 Mar 2004 20:35:40 - 1.12
+++ b/drivers/dri/r200/r200_context.h 18 Apr 2004 12:13:36 -
@@ -39,6 +39,7 @@
#ifdef GLX_DIRECT_RENDERING
#include inttypes.h
+#include tnl/t_vertex.h
#include drm.h
#include radeon_drm.h
#include dri_util.h
@@ -611,12 +612,13 @@
/* r200_swtcl.c
*/
struct r200_swtcl_info {
- GLuint SetupIndex;
- GLuint SetupNewInputs;
GLuint RenderIndex;
GLuint vertex_size;
- GLuint vertex_stride_shift;
- GLuint vertex_format;
+
+ struct tnl_attr_map vertex_attrs[VERT_ATTRIB_MAX];
+ GLuint vertex_attr_count;
+
+
GLubyte *verts;
/* Fallback rasterization functions
@@ -629,6 +631,11 @@
GLenum render_primitive;
GLuint numverts;
+ GLboolean needproj;
+
+ GLuint coloroffset;
+ GLuint specoffset;
+
struct r200_dma_region indexed_verts;
};
Index: drivers/dri/r200/r200_swtcl.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c,v
retrieving revision 1.9
diff -u -r1.9 r200_swtcl.c
--- a/drivers/dri/r200/r200_swtcl.c 20 Jan 2004 02:49:27 - 1.9
+++ b/drivers/dri/r200/r200_swtcl.c 18 Apr 2004 12:13:37 -
@@ -56,323 +56,185 @@
#include r200_swtcl.h
#include r200_tcl.h
-/***
- * Build render functions from dd templates *
- ***/
-
-
-#define R200_XYZW_BIT 0x01
-#define R200_RGBA_BIT 0x02
-#define R200_SPEC_BIT 0x04
-#define R200_TEX0_BIT 0x08
-#define R200_TEX1_BIT 0x10
-#define R200_PTEX_BIT 0x20
-#define R200_MAX_SETUP 0x40
static void flush_last_swtcl_prim( r200ContextPtr rmesa );
-static struct {
- void(*emit)( GLcontext *, GLuint, GLuint, void *, GLuint );
- interp_func interp;
- copy_pv_funccopy_pv;
- GLboolean (*check_tex_sizes)( GLcontext *ctx );
- GLuint vertex_size;
- GLuint vertex_format;
-} setup_tab[R200_MAX_SETUP];
-
-
-static int se_vtx_fmt_0[] = {
- 0,
-
- (R200_VTX_XY |
-R200_VTX_Z0 |
-(R200_VTX_PK_RGBA R200_VTX_COLOR_0_SHIFT)),
-
- (R200_VTX_XY |
-R200_VTX_Z0 |
-
Re: [Dri-devel] [r200] Viewperf-7.1.1 numbers - Not so good.
Am Montag, 5. April 2004 19:05 schrieb Dieter Nützel: dual Athlon MP 1900+ MSI K7D Master-L (AMD 760 MPX) 1 GB DDR266, CL2 (2x 512 MB) Radeon 8500QL, 64 MB Linux 2.6.4-44.9 (SuSE 9.0.42 with 2.6.5-rc-mm stuff) Latest DRI CVS trunk (Mesa-6.1) SMP in Mesa isn't working, today. (Since June 2003.) After Ian solved this I have some new numbers. They are some what better, maybe due to r200-maybe-flush-less. http://marc.theaimsgroup.com/?l=dri-develm=106668758605732w=2 Run All Summary -- sum_results/3dsmax/summary.txt 3dsmax-02 Weighted Geometric Mean = 6.352 -- sum_results/drv/summary.txt drv-09 Weighted Geometric Mean = 4.235 -- sum_results/dx/summary.txt dx-08 Weighted Geometric Mean = 29.728 -- sum_results/light/summary.txt light-06 Weighted Geometric Mean = 6.921 -- sum_results/proe/summary.txt proe-02 Weighted Geometric Mean = 4.412 -- sum_results/ugs/summary.txt ugs-03 Weighted Geometric Mean = 2.457 Viewperf-7.1.1 compiled with SMP support hangs immediately in drv09. http://marc.theaimsgroup.com/?l=dri-develm=105943067032345w=2 Sorry, this is still there: Three (???) threads are started. #8525, 8526, 8527 I could attach gdb from a remote system on them, but only got something out of #8525: #0 ioctl() /lib/i686/libc.so.6 #1 drmGetlock() top (with M) show this: rootradeon_lo X nuetzel schedule_ viewperf nuetzel get_signa viewperf 8526 is a cadaver Very bad regression (more than half down) in _all_ wireframe_ modes. (See below) Solved (due to r200-maybe-flush-less). Run All Summary -- sum_results/3dsmax/summary.txt 3dsmax-02 Weighted Geometric Mean = 5.556 -- sum_results/drv/summary.txt drv-09 Weighted Geometric Mean = 4.034 -- sum_results/dx/summary.txt dx-08 Weighted Geometric Mean = 28.699 -- sum_results/light/summary.txt light-06 Weighted Geometric Mean = 4.341 -- sum_results/proe/summary.txt proe-02 Weighted Geometric Mean = 3.304 -- sum_results/ugs/summary.txt ugs-03 Weighted Geometric Mean = 2.328 Greetings, Dieter --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Makefiles in the drm module
On Sun, 18 Apr 2004 01:53:40 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2004-04-14 at 16:19, Keith Whitwell wrote:
Michel Dänzer wrote:
Does anything speak against repo-moving Makefile.{bsd,linux} to
Makefile?
I can't think of any reason not to.
Turns out a simple repo-move doesn't work for Makefile.linux as it
contains some Makefile juggling hacks. The attached diff shows the
difference between Makefile.linux and the new Makefile which I'm going
to commit soon, unless someone objects.
Given this, I'm leaving Makefile.bsd to someone who can test it.
Also, should I try to fix up the snapshot scripts, or leave that to the
people dealing with the snapshots?
If you don't do it I'll take a look at it when I finish the snapshot
split (probably tomorrow). It should be as simple as changing the
install script to use Makefile.linux if available and Makefile
otherwise.
Felix
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70alloc_id638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
On Sun, Apr 18, 2004 at 01:33:41PM +0200, Michel Dänzer wrote: On Sun, 2004-04-18 at 04:19, Donnie Berkholz wrote: On Sat, 2004-04-17 at 07:54, Alan Hourihane wrote: On Sat, Apr 17, 2004 at 01:18:49AM +0200, Michel Dänzer wrote: On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote: I could merge in XFree86 4.3.99.902 which is before the license change Are you sure? AFAIK David applied the new license (or at least a similarly controversial one) to some files before it was publicly announced. Yes, I'm positive that 4.3.99.902 is unencumbered. I'm pretty sure the autoconfig work, under the X-Oz license (nearly identical to the problematic one), was in at that point. Right, that's what I was thinking of. Mmmm, things hotted up after the 4.3.99.902 release, but your right the file xf86AutoConfig.c does have the new license in that release. So that means dropping back to 4.3.99.901 or just let the individuals merge in DDX changes of their own accord, which may be the simpler approach. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon t_vertex conversion (was: R200 t_vertex conversion)
I tried to merge the r200 patch to the radeon driver.
Here is a snapshot.
(hopefully I didn't miss something while sorting out the r200 stuff from the diff.)
I tested:
glxgears works, quake3 works, ut2004demo works (at least to a certain extend)
progs/tests/projtex doesn't work as it should, yuvrect doesn't work as it should
best regards
Andreas
Index: Mesa/src/mesa/drivers/dri/radeon/radeon_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_context.c,v
retrieving revision 1.20
diff -u -r1.20 radeon_context.c
--- Mesa/src/mesa/drivers/dri/radeon/radeon_context.c 11 Mar 2004 20:35:41 -
1.20
+++ Mesa/src/mesa/drivers/dri/radeon/radeon_context.c 18 Apr 2004 22:06:58 -
@@ -168,7 +168,7 @@
*/
_radeon_texrect_stage,
- _radeon_render_stage,
+/* _radeon_render_stage, FIXME: disabled because of t_vertex.[ch] patch */
_tnl_render_stage, /* FALLBACK: */
0,
};
Index: Mesa/src/mesa/drivers/dri/radeon/radeon_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_context.h,v
retrieving revision 1.12
diff -u -r1.12 radeon_context.h
--- Mesa/src/mesa/drivers/dri/radeon/radeon_context.h 12 Mar 2004 20:03:54 -
1.12
+++ Mesa/src/mesa/drivers/dri/radeon/radeon_context.h 18 Apr 2004 22:06:59 -
@@ -41,6 +41,7 @@
#ifdef GLX_DIRECT_RENDERING
#include inttypes.h
+#include tnl/t_vertex.h
#include dri_util.h
#include drm.h
#include radeon_drm.h
@@ -531,12 +532,14 @@
/* radeon_swtcl.c
*/
struct radeon_swtcl_info {
- GLuint SetupIndex;
- GLuint SetupNewInputs;
GLuint RenderIndex;
GLuint vertex_size;
- GLuint vertex_stride_shift;
GLuint vertex_format;
+
+ struct tnl_attr_map vertex_attrs[VERT_ATTRIB_MAX];
+ GLuint vertex_attr_count;
+
+
GLubyte *verts;
/* Fallback rasterization functions
@@ -549,6 +552,11 @@
GLenum render_primitive;
GLuint numverts;
+ GLboolean needproj;
+
+ GLuint coloroffset;
+ GLuint specoffset;
+
struct radeon_dma_region indexed_verts;
};
Index: Mesa/src/mesa/drivers/dri/radeon/radeon_swtcl.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_swtcl.c,v
retrieving revision 1.9
diff -u -r1.9 radeon_swtcl.c
--- Mesa/src/mesa/drivers/dri/radeon/radeon_swtcl.c 27 Jan 2004 16:34:46 -
1.9
+++ Mesa/src/mesa/drivers/dri/radeon/radeon_swtcl.c 18 Apr 2004 22:07:00 -
@@ -53,207 +53,142 @@
#include radeon_swtcl.h
#include radeon_tcl.h
-/***
- * Build render functions from dd templates *
- ***/
-
-
-#define RADEON_XYZW_BIT0x01
-#define RADEON_RGBA_BIT0x02
-#define RADEON_SPEC_BIT0x04
-#define RADEON_TEX0_BIT0x08
-#define RADEON_TEX1_BIT0x10
-#define RADEON_PTEX_BIT0x20
-#define RADEON_MAX_SETUP 0x40
static void flush_last_swtcl_prim( radeonContextPtr rmesa );
-static struct {
- void(*emit)( GLcontext *, GLuint, GLuint, void *, GLuint );
- interp_func interp;
- copy_pv_funccopy_pv;
- GLboolean (*check_tex_sizes)( GLcontext *ctx );
- GLuint vertex_size;
- GLuint vertex_format;
-} setup_tab[RADEON_MAX_SETUP];
-
-
-#define TINY_VERTEX_FORMAT (RADEON_CP_VC_FRMT_XY | \
-RADEON_CP_VC_FRMT_Z | \
-RADEON_CP_VC_FRMT_PKCOLOR)
-
-#define NOTEX_VERTEX_FORMAT(RADEON_CP_VC_FRMT_XY | \
-RADEON_CP_VC_FRMT_Z | \
-RADEON_CP_VC_FRMT_W0 | \
-RADEON_CP_VC_FRMT_PKCOLOR |\
-RADEON_CP_VC_FRMT_PKSPEC)
-
-#define TEX0_VERTEX_FORMAT (RADEON_CP_VC_FRMT_XY | \
-RADEON_CP_VC_FRMT_Z | \
-RADEON_CP_VC_FRMT_W0 | \
-RADEON_CP_VC_FRMT_PKCOLOR |\
-RADEON_CP_VC_FRMT_PKSPEC | \
-RADEON_CP_VC_FRMT_ST0)
-
-#define TEX1_VERTEX_FORMAT (RADEON_CP_VC_FRMT_XY | \
-RADEON_CP_VC_FRMT_Z | \
-RADEON_CP_VC_FRMT_W0 | \
-RADEON_CP_VC_FRMT_PKCOLOR |\
-
[Dri-devel] RE: radeon t_vertex conversion (was: R200 t_vertex conversion)
sorry.. I missed to set tcl_mode=0, so the programs were running in HW-TCL mode. After setting tcl_mode to 0, glxgears and quake3 didnt work as expected. best regards, Andreas --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sun, Apr 18, 2004 at 09:20:00AM +0100, Alan Cox wrote: Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive There is no difference between the two, but this is getting very off-topic Its on-topic because the OP's work was generated specifically from the discussion on the Debian lists that I referenced. I still don't see where the boundary is drawn between data (which requires no source to be DFSG-free) and embedded executable code (which requires source to be DFSG-free). It seems that the interpretation is arbitrary depending on what 'feels' right in a particular case. I've no contest with people doing work to make things more flexible, but in this case the OP's work is being done because the unidentified matter is to be removed from the distribution, due to its suspected code-without-source nature. Why not do this work simply as a precursor to the event where someone identifies this binary blob as code-without-source in the future, and defer the actual removal to that future date if it ever arrives? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] RE: radeon t_vertex conversion (was: R200 t_vertex conversion)
On Mon, 2004-04-19 at 00:29, Andreas Stenglein wrote: After setting tcl_mode to 0, glxgears and quake3 didnt work as expected. glxgears looks like http://penguinppc.org/~daenzer/DRI/glxgears.png here; if I press the cursor keys, the inner colour changes, but not the geometry. Is this what you're seeing as well, or is this an architecture specific problem? bzflag is also completely broken here. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RE: radeon t_vertex conversion
Andreas Stenglein wrote: sorry.. I missed to set tcl_mode=0, so the programs were running in HW-TCL mode. After setting tcl_mode to 0, glxgears and quake3 didnt work as expected. Ah gack, my r200 changes haven't been tested for similar reasons... Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM pci ids
Okay I've come up with a method for generating the pci ids stuff for the
DRM for Linux and BSD,
put a txt file in shared or the format
[cardname]
vendid devid namestring
have two scripts in the scripts directory ones to create a linux
drm_pciids.h file of the format
#define cardname_PCI_IDS \
{ vendid, devid, 0 }, \
{ 0, 0, 0 }
with all the card IDs in the one file,
then change drm_drv.h to have..
#include drm_pciids.h
static drm_pci_id_list_t DRM(pciidlist)[] = {
DRM(PCI_IDS)
};
remove all the pciids from the drivers also ..
Then we can submit the generated header file to the kernel, and I can
modify the Linux code to grab a PCI name if they are compiled in and
switched on, so to add a new ID, you just edit the text file, we can run
the scripts as part of the make or if people think we need it we can just
check in the .h files and use the scripts to keep them updated..
let me know what you think I still have to fix up the Linux code on my
machine to get the PCI names if it can ..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
