Re: [Dri-devel] Re: any DRM update scheduled for 2.4.23-pre?
Marcelo Tosatti wrote: Does DRM 4.3 work with both XFree 4.2 and 4.3 ? I dont so, right? Unless somebody screwed up it should. If it is broken, we would, of course, like to hear about it. :) --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] per-screen client-side glx extensions
Ian Romanick wrote:
Ian Romanick wrote:
I'm also having second thoughts about allowing drivers to add function
calls to the GLX dispatch table. This is a global table that has no
way to identify the owner of a dispatch function. This
functionality is currently only used by a single feature of the r200
driver. I think we'd be better off adding proper support for
GLX_NV_vertex_array_range and GLX_MESA_agp_offset, hackish though they
are, than supporting __glXRegisterGLXFunction. There's just way too
much that can go wrong with it in a multi-card environment.
It should be easy enough to add entry-points for glXAllocateMemoryNV,
glXFreeMemoryNV, and glXGetAGPOffsetMESA to the __DriverAPIRec. Is
that okay with you, Keith?
I'm going to *strongly* vote that we axe these interfaces altogether.
Aparently, the folks at Nvidia didn't care too much about multi-card
environments when the created {GLX,WGL}_NV_vertex_array_range. The spec
says Because wglAllocateMemoryNV and wglFreeMemoryNV are not OpenGL
rendering commands, these commands do not require a current context.
However, there is no screen / display information passed into the
functions. How is the API supposed to identify the card to allocate
memory on?
GLX_MESA_agp_offset isn't any better. It has the same context free
nature and doesn't have any screen / display information. What about
the case of a AGP card and a PCI card w/PCIGART in the same system?
I know that this isn't the use-cases for which these extensions were
added to DRI, but we still have to support this stuff in the general
case. I am *very* open to suggestions of how to fix this *and* keep
everybody happy. :)
I'm happy to drop these once we have identified implemented a suitable
replacement.
Keith
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Build strangeness
Ian Romanick wrote: Nathan Gray wrote: Hello, I'm trying to build from CVS but I'm seeing something unexpected. The build is trying to link to X libraries outside of the DRI tree itself. In host.def I altered the ProjectRoot variable as so: /* Optionally turn this on to change the place where you install the build. * Warning: trailing blanks will cause build failures. */ #define ProjectRoot /usr/X11R6-n8dri When I run make World it tries to do this: + gcc -m32 -o ./libGL.so.1.2~ ... blah blah blah ... -L/usr/X11R6-n8dri/lib -lXext -lX11 -ldl -lXxf86vm -lc I could have sworn this was documented, but I sure couldn't find it. This should be added to the developer's FAQ. The DRI tree doesn't include all of XFree86. It would be too big and too much work to keep in sync. Because of that a DRI build requires that a bunch of the core X libraries and header files are installed on the system already. The only place that it knows to look for it is in ProjectRoot. If you have XFree86 already installed on your system and want to build to somewhere else, you have to copy your existing tree to the new place. Something like 'cp -a /usr/X11R6 /usr/X11R6-n8dri' should work. I'm not sure off the top of my head what the minimum set of required stuff is. Ok, I see. Thanks for the info. I've added this to the compilation questions section of the FAQ on dri.sourceforge.net. The *best* place to put this information would be in the comment above the ProjectRoot #define, IMHO. Thanks again, -n8 -- -- Nathaniel Gray -- Caltech Computer Science -- -- Mojave Project -- http://mojave.cs.caltech.edu -- --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Two Linux framebuffer patches, Radeon and Rage128
Jon Smirl wrote: These add all known Radeon and Rage128 PCI IDs to their respective framebuffer drivers. It also updates linux/pci_ids.h with these IDs. Both drivers will display pretty_name if CONFIG_PCI_NAMES is enabled, otherwise a name is generated. Please check over the chip family definitions in the framebuffer files. The Radeon ones are more likely to be wrong. I also made the Radeon FB claim secondary adapters but not do anything with them. This will make them display in /proc as being owned by the driver. For this to work right the devices ID have to be in the correct secondary family. I may not have these all right since I don't have the doc. I removed about 15 definitions from pci_ids.h that were wrong. The rage128 patch is newer than the last one. I had a typo in an IFDEF. Rage128 add PCI IDs and fixes bug when modprobe didn't work. Did you see a very similar patch that I sent to dri-devel a week or two ago? Isn't pci_ids.h generated automatically from drivers/pci/pci.ids? The patch that I sent to dri-devel updates / cleans-up drivers/pci/pci.ids and had a Python script to generate a table that looks very similar to the radeonfb_pci_table. It seems that automatically generating that data from pci.ids is a better solution that doing it by hand. I think using something more like my PCI ID structure would help cut out some code in the Radeon FB driver because instead of just having an enum in the table, you could have a pointer to a structure (such as the correct entry in the radeon_chip_info table) that would eliminate some of those extra switch-statements. My changes only cover the Radeon family. Once that much got into DRI I had plans to make similar changes for the Rage128 and MGA families of chips. Check: http://marc.theaimsgroup.com/?l=dri-develm=105979521324026w=2 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 62] RFE: Add support for DRI with Xinerama configurations
[EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 12:20 --- Because you're subscribed to the dri-devel list? Please don't reassign these bugs again without a reason. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Simple example fails w/direct rendering
Hello,
This is an example from an opengl tutorial that I'm trying out. If I run it
with LIBGL_ALWAYS_INDIRECT it works fine, but with direct rendering I just
get a blank window. I'm using the radeon driver from recent CVS (checked
out yesterday anonymously) on a Dell Inspiron 4150 w/Radeon Mobility M7.
Any ideas?
Thanks,
-n8
--
-- Nathaniel Gray -- Caltech Computer Science --
-- Mojave Project -- http://mojave.cs.caltech.edu --/*
gcc -o ex5 ex5.c -L/usr/X11R6/lib -I/usr/X11R6/include -lX11 -lGL -lGLU -lglut -lm
*/
#include stdio.h
#include GL/glut.h
void display (void) {
/* Called when OpenGL needs to update the display */
glClear (GL_COLOR_BUFFER_BIT); /* Clear the window */
glLoadIdentity ();
gluLookAt (0.0, 0.0, 5.0, /* Pos of camera */
0.0, 0.0, 0.0, /* Target to look at */
0.0, 1.0, 0.0); /* up vector */
glutWireCube(2.0);
}
void keyboard (unsigned char key, int x, int y) {
/* Called when a key is pressed */
if (key == 27) exit(0); /* 27 is Escape */
else printf(You pressed '%c' with the mouse at (%i, %i)\n, key, x, y);
}
void reshape (int w, int h) {
/* Called when the window is created, moved, or resized */
glViewport (0, 0, (GLsizei) w, (GLsizei) h);
glMatrixMode (GL_PROJECTION); /* Select the projection matrix */
glLoadIdentity(); /* Initialize it */
gluPerspective(60, (GLfloat)w / (GLfloat)h, 1.0, 100.0);
glMatrixMode (GL_MODELVIEW);/* Select the modelview matrix */
}
int main (int argc, char** argv) {
glutInit (argc, argv);
glutInitWindowSize (500, 500);
glutInitWindowPosition(100,100);
glutCreateWindow (ex5);
glutDisplayFunc (display); /* Register the display callback */
glutReshapeFunc (reshape); /* Register the reshape callback */
glutKeyboardFunc (keyboard);/* Register the keyboard callback */
/* Note that glutKeyboardFunc only works for keys with single
ascii codes. Arrow keys won't work. For that use
glutSpecialFunc */
glutMainLoop ();
return 0;
}
[Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
Larry McVoy wrote: That ought to be balanced with don't screw up the revision history, people use it. It's one thing to reformat code that is unreadable, for the most part this code didn't come close to unreadable. Granted. I wasn't suggesting that. I was saying if (expr) statement; // OK The test and the statement run together visually, which is it is preferred to put the statement on the following line. The exception I was saying was reasonable is if you are doing something like if (!pointer) return (-EINVAL); Short, sweet, readable, no worries. return is not a function ;-) Jeff --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 25] radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed.
[EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 12:40 --- Re-assign to dri-devel, as it's a DRI issue. Could anyone who has experienced the problem try the binary packages from http://dri.sourceforge.net/ to see if the problem is fixed in current CVS? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i810 compatibility fix upgraded to latest tree..
Okay I've updated Matthew's DRM compatibility fix for the top of DRI tree, http://www.skynet.ie/~airlied/patches/dri/i810_compat.diff I'll apply it in a couple of days as it seemed to be agreed previously that it solves the problem.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 131] Metabug - Mach64 DRI is not merged into the [DRI] trunk.
[EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-08 19:21 --- *** Bug 586 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
On Mon, Aug 11, 2003 at 01:53:17PM -0400, Jeff Garzik wrote:
Larry McVoy wrote:
are function calls at a 10-nanosecond glance. Also, having two styles
of 'if' formatting in your example just screams inconsistent to me :)
It is inconsistent, on purpose. It's essentially like perl's
return unless pointer;
which is a oneliner, almost like an assert().
Maybe this will help: I insist on braces on anything with indentation so
that I can scan them more quickly. If I gave you a choice between
if (!pointer) {
return (whatever);
}
if (!pointer) return (whatever);
which one will you type more often? I actually don't care which you use,
I prefer the shorter one because I don't measure my self worth in lines
of code generated, I tend to favor lines of code deleted :) But either
one is fine, I tend to use the first one if it has been a problem area
and I'm likely to come back and shove in some debugging.
Before you say lose the braces try reading more code and see how much faster
it is if all indented stuff has braces. You whiz through it.
Absolutely not. I'm cooler, so my opinion counts more.
You are in North Carolina, I'm in San Francisco. No competition, you are
sweating like a pig :)
Same for your eyes when you get to my age.
I bet when you were in school, you had to chip your homework into slate,
and dinner was brontosaurus-kebob, right?
Dinner? You got dinner? Damn, you were spoiled.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
