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 b
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 mu
cfully ignored 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
>
>
> T
--- 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.
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 th
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 n
[ 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
shou
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 it when the relevant XFree86 developers ag
--- 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.
> > >
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 g
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.
> >
> T
--- 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 st
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
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. T
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
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
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
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,
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 ab
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 c
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,
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
--- 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 brought up).
> Notably, I'm not using pci_ids.h
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 Da
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 w
> The radeon driver already uses the family enum to tell secondary from primary
> adapters. This is done so that linux PCI utlities will show the Radeon driver
> as owning both devices. GET_SUGGESTED should be modified to return the family
> enum too. Then we could remove the PCI ID's and ifs in t
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. :)
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-
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 imple
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 machi
35 matches
Mail list logo