Jon Smirl wrote:
--- Alex Deucher [EMAIL PROTECTED] wrote:
As I recall, no. As it is now, only a single instance of Xfree86 can
use the DRI. I think it might be possible by adapting the resume code
to reinitialize state and agp on a VT switch, however, I may be wrong.
Am I right in thinking
Recently I upgraded xfree86 from 4.2.1 to 4.3.0-0pre1v3 (I use debian sid). I found
that tecplot (I use tecplot 9.2, which takes advantage of OpenGL to accelerate 3D
rendering.) can no longer render 3D graphics properly. For example, choosing contour
in 3D graphics has no effect at all. This
On Wed, 2003-10-15 at 13:03, happyluo79 wrote:
Recently I upgraded xfree86 from 4.2.1 to 4.3.0-0pre1v3 (I use debian
sid). I found that tecplot (I use tecplot 9.2, which takes advantage
of OpenGL to accelerate 3D rendering.) can no longer render 3D graphics
properly. For example, choosing
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
The reason mergedfb is enabled by default is to emulate the clone
behavior in the old driver. perhaps this should be changed in the
future?
In the mean time, I may switch back to validating the modes on crtc2
before crtc1. that was the
Michel Dnzer wrote:
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
The reason mergedfb is enabled by default is to emulate the clone
behavior in the old driver. perhaps this should be changed in the
future?
In the mean time, I may switch back to validating the modes on crtc2
before crtc1.
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
I've uploaded some screenshots as an example:
http://www.botchco.com/alex/2048-error/
the new version of xscreensaver displays a separate instance on each
head of a xinerama desktop. so in this case only the context running up
again the 2048
--- Charl P. Botha [EMAIL PROTECTED] wrote:
My first attempt at resume for the radeon resulted in the reinit hack
(which Michel has since turned into a fantastic piece of work). This
releases all resources at VT switch away and re-initialises them at VT
switch-to. With the reinit patch,
On Wed, 2003-10-15 at 16:56, Jon Smirl wrote:
--- Charl P. Botha [EMAIL PROTECTED] wrote:
My first attempt at resume for the radeon resulted in the reinit hack
(which Michel has since turned into a fantastic piece of work). This
releases all resources at VT switch away and re-initialises
On Wed, 2003-10-15 at 16:48, happyluo79 wrote:
Sorry about the non-wrapping lines.
I removed xlibmesa-dri and xlibmesa-gl, and then installed
xlibmesa-gl1-dri-trunk from
deb http://people.debian.org/~daenzer/dri-trunk-sid/./
but the problem persists.
So the r128 driver in current
On Wed, 2003-10-15 at 23:00, Michel D01nzer wrote:
So the r128 driver in current CVS still seems to be broken.
Yeah, I think so. And I hope our dear developers can manage to locate
and fix this bug.
--
Luo Chong [EMAIL PROTECTED]
---
On Wed, 15 Oct 2003 14:39:41 +0200
Ronald Baljeu [EMAIL PROTECTED] wrote:
Hi,
The current DRI drivers for i810 fail to work (both cvs source, and
snapshot). It looks like another expat problem.
This is what I get when running glxinfo:
# export LIBGL_DEBUG=verbose
# glxinfo
name of
I'll take a look at it if I get some free time this week.
Alex
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Hey guys,
That did it. I moved libint10.a out of the way on my linux
installation, and now X is failing to start just as it did under
FreeBSD
(while validating modes on
On Wed, 15 Oct 2003, Jon Smirl wrote:
If you are familar with the hardware please check that I got the PCI ID lists
right.
Please fix the fact that modern PCI is _not_ enumerated with just bus,
slot, function. A lot of machines are starting to have a domain number,
which allows fro multiple
It's still emulating the old clone mode. it just uses the mergefb
clone mode rather than the old clone mode since there were just about
the same code-wise. Clone mode was on by default in the old radeon
driver, so the mergedfb equivalent is on by default in mergedfb. the
reason for the default
That's fine with me. we can revert back to xfree86 CVS for the trunk
and I can move to a branch. I wouldn't have put it on the trunk if I
had know the mode stuff was cause so much trouble, but then again, it's
been working fine for me and those who initially tested it, so I need
to more testers
Sounds good. I may play around with it when I get a chance. Any other
thoughts on what it might be if not clears?
Alex
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
I've uploaded some screenshots as an example:
Alex Deucher wrote:
That's fine with me. we can revert back to xfree86 CVS for the trunk
and I can move to a branch. I wouldn't have put it on the trunk if I
had know the mode stuff was cause so much trouble, but then again, it's
been working fine for me and those who initially tested it, so I
John,
i gave your code a short review and found nothing worth a note.
In other words, if there is a problem at all
then i've overlooked that due to the speed i browsed it.
One thing to ask you: there is always those secondary PCI ID
on the current Radeon designs. Do you see some chance to get
--- Alexander Stohr [EMAIL PROTECTED] wrote:
One thing to ask you: there is always those secondary PCI ID
on the current Radeon designs. Do you see some chance to get
rid of irritating logfile messages that concern those 2nd ID.
The new code allows a different way of initializing XFree. For
On Wed, 2003-10-15 at 18:50, Felix Khling wrote:
Oops, xmlconfig.o gets linked into all drivers, even those that don't
use it. BTW, the same is true for all object files in
xc/lib/GL/mesa/src/drv/common. How should files in the common directory
be handled that are not used by all drivers?
perhaps for the time being I can set mergedfb to default to false
rather than the true clone mode it does now.
that should prevent the mergedfb code paths from being taken and those
that want to try it can simply turn it on.
I don't think anyone has had a problem with it turned off. speak up if
On Wed, 2003-10-15 at 19:12, Jon Smirl wrote:
The attached patch adds a new DRM IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. It
works by hooking into the OS PCI device detection at module load time. Each DRM
driver now contains the PCI IDs of all the cards that it supports. The OS then
matches these
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
Now assuming no xconfig file...
xfree loads, opens the first DRM device, and gets SUGGESTED_UNIQUE.
That will tell Xfree what video hardware to use.
Modes are all determined by the EDID/hardware exchange.
This should be enough to get xfree
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
perhaps for the time being I can set mergedfb to default to false
That's probably a good idea, but then it should default to clone mode as
pre-MergedFB. Driving both heads with a single CRTC is nasty.
--
Earthling Michel Dnzer \ Debian
On Wed, 15 Oct 2003, Michel Dänzer wrote:
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
This new scheme allows the entire PCI probing stage of xfree to be eliminated.
I'll believe it when the relevant XFree86 developers agree with you. :)
If they don't, they are clueless.
There's no way
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
perhaps for the time being I can set mergedfb to default to false
That's probably a good idea, but then it should default to clone mode
as
pre-MergedFB. Driving both heads with a single CRTC is
[ Following up to myself ]
On Wed, 15 Oct 2003, Linus Torvalds wrote:
Yes, XF86 may need to have some legacy module for backwards compatibility.
But thinking that X should try to probe on its own is just silly.
This is also relevant to 2D, since more and more graphics cards really
On Wed, 2003-10-15 at 22:58, Linus Torvalds wrote:
On Wed, 15 Oct 2003, Michel Dnzer wrote:
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
This new scheme allows the entire PCI probing stage of xfree to be eliminated.
I'll believe it when the relevant XFree86 developers agree with
On Wed, 2003-10-15 at 22:58, Alex Deucher wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
perhaps for the time being I can set mergedfb to default to false
That's probably a good idea, but then it should default to clone mode
as
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:58, Linus Torvalds wrote:
On Wed, 15 Oct 2003, Michel Dänzer wrote:
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
This new scheme allows the entire PCI probing stage of xfree to be
eliminated.
I'll believe
On Wed, 2003-10-15 at 14:40, Jon Smirl wrote:
Has any one checked the PC IDs in each driver? For example I'm not sure that
all of the cards I added to the MGA driver are 3D capable. I went through the
Xfree source trying to figure out an accurate list but sometime it wasn't
obvious.
I've got
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:58, Alex Deucher wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
perhaps for the time being I can set mergedfb to default to
false
That's probably a good idea,
Has any one checked the PC IDs in each driver? For example I'm not sure that
all of the cards I added to the MGA driver are 3D capable. I went through the
Xfree source trying to figure out an accurate list but sometime it wasn't
obvious.
=
Jon Smirl
[EMAIL PROTECTED]
On Wed, 2003-10-15 at 12:01, Jon Smirl wrote:
--- Alexander Stohr [EMAIL PROTECTED] wrote:
One thing to ask you: there is always those secondary PCI ID
on the current Radeon designs. Do you see some chance to get
rid of irritating logfile messages that concern those 2nd ID.
The new code
--- Eric Anholt [EMAIL PROTECTED] wrote:
If the Linux drivers go to probing PCI IDs, could it also start creating
/dev/dri/cardXs which are associated with a specific piece of hardware?
The get/set unique thing is a problem, though. It seems to me that we
ought to have /dev/dri/cardX start
This should make life easier for developers. You'll get annoying
warnings though. For my conscience: it is still a lot better than the
old scheme as the values from the environment are properly checked and
converted before use. :)
Regards,
Felix
On Wed, 15 Oct 2003 15:02:58 -0700
Felix
On Wed, 2003-10-15 at 14:57, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
If the Linux drivers go to probing PCI IDs, could it also start creating
/dev/dri/cardXs which are associated with a specific piece of hardware?
The get/set unique thing is a problem, though. It seems
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-15-10 18:17 ---
I just wanted to add
On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote:
Has any one checked the PC IDs in each driver? For example I'm not sure that
all of the cards I added to the MGA driver are 3D capable.
The driver only supports G200/G400/G550. Remove the rest.
I'm not sure about the G200 PCI entry.
On Thu, 2003-10-16 at 00:11, Felix Khling wrote:
This should make life easier for developers. You'll get annoying
warnings though. For my conscience: it is still a lot better than the
old scheme as the values from the environment are properly checked and
converted before use. :)
Yes, I think
My previous comment on irc about anisotropic filtering needing two mip
levels was crap. Fortunately I've since managed to figure out the real
details.
The good news is that G550 doesn't have any problems with anisotropic
filtering.
The bad news is that G4x0 chips need both texture units to pull
there's also this driver:
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP...
Alex
--- Ville_Syrjälä [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote:
Has any one checked the PC IDs
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote:
there's also this driver:
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP...
AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do
On Wed, 15 Oct 2003 21:53:17 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 18:50, Felix Kühling wrote:
Oops, xmlconfig.o gets linked into all drivers, even those that don't
use it. BTW, the same is true for all object files in
xc/lib/GL/mesa/src/drv/common. How
On Wed, 2003-10-15 at 16:15, Felix Kühling wrote:
On Wed, 15 Oct 2003 21:53:17 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2003-10-15 at 18:50, Felix Kühling wrote:
Oops, xmlconfig.o gets linked into all drivers, even those that don't
use it. BTW, the same is true for all
Slightly OT, but here's an article comparing XiG Summit, dri cvs and the
ATI driver on a radeon 9000pro.
http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to
the 3D drvier needs to be updated to mesa 5.x. Not much work has been
done on it and I think there are some issues with the 2D driver.
There's no way it will make it into 4.4.0. the current code is on a
branch in DRI cvs. If you are interested in helping, please do.
Alex
--- Tim Roberts
On Mer, 2003-10-15 at 21:07, Alex Deucher wrote:
the 3D drvier needs to be updated to mesa 5.x. Not much work has been
done on it and I think there are some issues with the 2D driver.
There's no way it will make it into 4.4.0. the current code is on a
branch in DRI cvs. If you are
Alan, that's the CLE266/via driver, right? the savage driver is still
barely touched as far as I know. there was some talk of shelving the
old savage_1-0-0 branch and starting a new one on savage_1-0-1 since
the old one needed so many changes to get synced up to the trunk.
Alex
--- Alan Cox
49 matches
Mail list logo
