On Tue, 21 Oct 2003, Eric Anholt wrote:
What is the proper way to get the equivalent of pci_name(pdev) on
pre-2.5? Also, what is the cutoff where pci_name is available? Are the
values from pci_name decimal or hex?
The cut-off is 2.5.74 or so.
The numbers are hex, and it's really
On Wed, 2003-10-15 at 10:42, Linus Torvalds wrote:
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
Linus Torvalds writes:
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
On Tue, 2003-10-21 at 15:33, Linus Torvalds wrote:
On Tue, 21 Oct 2003, Eric Anholt wrote:
What is the proper way to get the equivalent of pci_name(pdev) on
pre-2.5? Also, what is the cutoff where pci_name is available? Are the
values from pci_name decimal or hex?
The cut-off is
Ville Syrj?l? [EMAIL PROTECTED] wrote:
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
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote:
Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches
are almost identical. Both against current bitkeeper source.
Can people in the know please check the PCI IDs for the other hardware? I'm
fairly sure Radeon, Rage128, and
On Thu, 2003-10-16 at 00:13, Eric Anholt wrote:
Seems like we need a set-understood-version ioctl. What I'm imagining
is an ioctl that takes in a DRM interface version and/or card-specific
DRM interface version. It can then adjust its response to other ioctls
appropriately. It would
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Alex
--- Martin Spott [EMAIL PROTECTED] wrote:
Ville Syrj?l? [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote:
there's also this driver:
On Thu, Oct 16, 2003 at 06:30:53AM -0700, Alex Deucher wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
I'll ask him - he moved to southern Germany earlier this year,
Martin.
--
Unix _IS_ user friendly - it's just selective
Alex Deucher [EMAIL PROTECTED] wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Sorry, currently he's forced to finish his dissertation. He says you
might have to wait at least a month until he'll be able to deal with
that,
Martin.
--
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote:
[...] a linux-2.4 port. The patches are almost identical.
For DRI CVS we need a single patch which works everywhere, see
drm_os_linux.h for examples how this is handled for other stuff.
The code
On Wed, 2003-10-15 at 18:08, Jon Smirl wrote:
Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches
are almost identical. Both against current bitkeeper source.
Can people in the know please check the PCI IDs for the other hardware? I'm
fairly sure Radeon, Rage128, and
no worries... I was just curious.
--- Martin Spott [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Sorry, currently he's forced to finish his dissertation. He says you
might
On Thu, 2003-10-16 at 12:41, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
I'm still working on cleaning the PCI ID stuff up to be portable, which
I'll commit as soon as I test (I'm trying to get a multihead setup going
to see if there are problems with that as Michel Daenzer
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote:
[...] a linux-2.4 port. The patches are almost identical.
For DRI CVS we need a single patch which works everywhere, see
drm_os_linux.h for examples how this is handled for other stuff.
What about the other points I raised?
Anyway, it seems Eric
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
in probing.
What do you think?
-Alex.
-Original Message-
From: Jon Smirl [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 19:12
To: dri-devel
Subject: Re: [Dri-devel] Adding hardware detection to DRI drivers
The attached patch adds a new DRM IOCTL
--- 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 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, 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
[ 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
--- 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
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
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
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.
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
Standalone Mesa doesn't have the Xfree code for walking the PCI bus so the
simplest way for me to find the hardware is to make the DRI drivers aware of
the OS's PCI probing support. I've already have PCI probing support added to
all of the DRI drivers, but I need to come up with an API that won't
33 matches
Mail list logo
