Ian Romanick wrote:
Keith Whitwell wrote:
Here's a patch that mainly works. I've still seen the odd case of the
texture apparently getting uploaded to the backbuffer.
...but *only* if you have a kernel module installed that understands
rectangle state. As it is, the code in
[This e-mail has been automatically generated.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
attention.
All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at
Am Montag, 23. Juni 2003 20:24 schrieb José Fonseca:
On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote:
These sourceforge backup server move is very annoying.
It's hindering open source so much.
Do we have other options?
I've never tried but isn't possible for non-developers
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
I'm rounding out the final bits of support for SGI_make_current_read.
I've hit a (hopefully) minor snag, and I'd like some advice on how to
proceede. At this point, *all* of the client-side support, both in
libGL.so and in at least
On Tue, 2003-06-24 at 23:42, Ian Romanick wrote:
Just by looking at how things are called, making these changes would
seem to be a binary compatability problem. Is that assessment correct?
It seems like I can, with a certain amount of pain and suffering, work
around the problem *if* I
Ian Romanick wrote:
I only noticed this because when I try to insmod the new radeon.o, it
fails on an undefined symbol mmu_cr4_features. The wierd part is that
/boot/System.map-2.4.21-rc2-ac2 shows it as being in global BSS
(c02ccd0c B mmu_cr4_features), *but* /proc/ksyms doesn't show it. I
here is a patch that works at least for multiarb.c
It is against HEAD from 19 June 2003
(I cleaned it up a bit but its not ready for merge:
still some questions...)
1) could someone with an 8MB or 16MB Radeon check if the
resulting max_texturesize is big enough?
(just use mesa's glxinfo: glxinfo
I just tried to fire up Quake III on a laptop with an Intel 830 chipset
and the i830 DRI snapshot from a couple of days ago. The game started,
but only displayed one frame (I think). I switched consoles, killed Q3,
and then got this message on the console:
[drm:i830_wait_ring] *ERROR* space:
I just saw this on extremetech today:
http://www.extremetech.com/article2/0,3973,1101038,00.asp
Looks like SiS is spinning off it's graphics chip division. perhaps
this could mean better access to databooks!
Now might be a good time to ask if they've considered it, get the idea
out there
I would like to help enable DRI for multiple head configurations but I
need a little direction to get started. I understand from previous
postings and comments I have seen in the source that DRI is currently
disabled in multiple head cfg's because of sync. problems but I am not
sure of the exact
I don't know what's involved in making the DRI work on multiple
physical graphics cards, but if you want HW accelerated 3D on a
dualheaded radeon card check out my mergedfb patch:
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=276
I'm not sure you'll be able to get dual independant 3D
Alex,
Thanks for the information. I will look thru the mergedfb patch code
asap. I think your idea of sharing one framebuffer as 2 virtual fb's
could work...thanks!
-dean andreakis
-Original Message-
From: Alex Deucher [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 3:27 PM
To:
you might want to move the framebuffer info up to the entity level and
then move the initialization of the DRI to the entity level rather than
the pScrn level. then when the individual pScrns map set up their
framebuffers and initialize the dri, it would basically just be a call
to some resource
On Tue, 2003-06-24 at 14:44, Michel Dänzer wrote:
On Tue, 2003-06-24 at 17:37, José Fonseca wrote:
But we really need to get a solution around the backup CVS server as it
really damages the beneficial intervention of non-commiters can have
since they are days behind what the commiters
Andreas Stenglein wrote:
here is a patch that works at least for multiarb.c
It is against HEAD from 19 June 2003
(I cleaned it up a bit but its not ready for merge:
still some questions...)
I've taken a quick peek at this patch, and I have a couple comments. I
hope to be able to look at it in
Jonathan Thambidurai wrote:
On Tue, 2003-06-24 at 14:44, Michel Dänzer wrote:
On Tue, 2003-06-24 at 17:37, José Fonseca wrote:
But we really need to get a solution around the backup CVS server as it
really damages the beneficial intervention of non-commiters can have
since they are days behind
16 matches
Mail list logo
