If these lists are ok I can generate patches
xf86PciInfo.h is missing the following ids:
4136 Radeon IGP 320M A6
4164 Radeon R300 Ad Secondary (DVI) output
4336 Radeon Mobility U1 C6
4337 Radeon IGP 340M C7
496e Radeon R250 In [Radeon 9000] (Secondary)
4c6e Radeon R250 Ln [Radeon Mobility 900
Is anyone planning to update the apparently obsolete(*)
DRM drivers currently in 2.4.22-pre/rc for 2.4.23?
I noticed that the RH9 kernel applies a drm-4.3 patch,
so the code must be there, just not in Marcelo's tree :-(
(*) XFree86-4.3.0 tells me my radeon module from 2.4.22-pre10
is out of date,
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
framebu
the code S3/VIA released was against xfree86 4.2.0. several people
have built the source against 4.2.0. check tim roberts' savage mailing
list archive for instructions
(http://www.probo.com/mailman/listinfo/savage40 ). I don't think the
initial driver drop enabled hw acceleration on savage mx/i
http://bugs.xfree86.org/show_bug.cgi?id=271
--- Additional Comments From [EMAIL PROTECTED] 2003-08-08 12:47 ---
To make it easier for others, the screensavers in question are available at
http://rss-glx.sourceforge.net/. It also doesn't seem to want to build w/gcc
2.96, but gcc 3.3 s
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-08-08 23:35 ---
Created an attachment (id=483)
--> (http://bugs.xfree86.org/attachment.cgi?id=483&action=view)
Linux kernel 2.5.75 agpgart and drm driver patch for Radeon IGP chipsets
Thi
On Wednesday 06 August 2003 17:37, Arjan van de Ven wrote:
Hi Arjan,
> > It's a complete DRM-4.3 tree. He has to decide between an update of
> > existing 4.2 code or an addition of a new subdirectory drm-4.3 + proper
> > config.in entry.
> did you clean the tree up like in -ac's tree or did you t
I've recently upgraded to mandrake 9.1, and have since been unable to load the
radeon.o module when I've compiled it from the source. I'm using the same
compiler for the module as for the kernel (gcc 3.2).
Here's the output:
radeon.o: unresolved symbol mmu_cr4_features
I have high-mem enabled,
>> Ove Kaaven <[EMAIL PROTECTED]> writes:
> > Many OpenGL programmers ask immediately "is that software or
> > hardware?" The correct answer is "who cares?" What you want to
> > know is if that's fast or not.
>
> That's not always true. Benchmarks aren't everything. Even if the CPU
> co
Adam K Kirchhoff wrote:
>
> I get the blank window as well... However, when move the window
> around, I get a flickering glimpse of the cube as the window redraws.
I don't see this when moving the window, but if I move *another* window in
front of the opengl one I can sometimes see a few pieces
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-08-08 23:05 ---
Here is the latest version on my system.
Changes in this version:
1. RS100/200/250 Q3A texture problem is worked around.
2. RS100/200/250 FW is okay and can be enabled.
3. R
tor, 07.08.2003 kl. 12.21 skrev Marcelo E. Magallon:
> On Tue, Aug 05, 2003 at 12:43:51AM +0200, Ove Kaaven wrote:
>
> > I don't buy this argument. ValidateDevice doesn't do a lot of explaining
> > either. The interface it presents is not hard to implement. I'm only
> > asking for knowing at ru
12 matches
Mail list logo
