How does Xfree coordinate PCI resource mapping with the Linux kernel? When I
cat /proc/iomem or /proc/ioports none of my video hardware is assigned to a
device driver. Is it possible for XFree to move the location of PCI resources?
Shouldn't we add request_mem_region(addr, size, "driver") calls to
Solved. Read on..
On Tue, 21 Oct 2003, Felix Kühling wrote:
>
> glcontextmodes.o gets linked to libGL, not the driver. Apperently you
> have an outdated libGL installed.
Well, my regular libGL.so is as new as the driver and compiled from DRI.
And yes, _gl_context_modes_destroy is there accordi
On Tue, 2003-10-21 at 11:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam
On Tue, 2003-10-21 at 20:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam
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-21-10 17:07 ---
There is news for my p
http://people.freebsd.org/~anholt/dri/files/drm-unique-2.diff
Here's my first shot at the changes for unique handling in the DRI. It
includes a new ioctl, DRM_IOCTL_SET_VERSION. This takes in a struct
containing numbers for the major/minor version of the device independent
DRM interface and majo
Chris Ison wrote:
Is anyone aware, or know how to resolve the slowness of the current DRI
CVS, I'm only getting 30fps with glxgears compared to the 250+fps with
the SF dri cvs.
Check logs for reports of breakage... could be engine resetting itself a
whole lot or something.
Just a random thought
On Wed, 2003-10-22 at 00:06, Chris Ison wrote:
>
> For some reason its failing to open /dev/drm/card0, the SF version opens
> it without problems.
Even with the same DRM?
My best guess is still that this is related to the new DRM PCI probing
code which was committed last Friday. Maybe it can't
On Wed, 2003-10-22 at 00:58, Louis Garcia wrote:
> I'm running a radeon-7500 card and been playing wolfenstein and quake3
> just fine under Fedora Core 3 (redhat beta). I just got America's Army
> to try it. Well it runs fine but the 3D rendering is messed up. How can
> I tell if this is a dri bug
On Tue, 21 Oct 2003 09:51:29 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
> > glcontextmodes.o gets linked to libGL, not the driver. Apperently you
> > have an outdated libGL installed. Though this kind of binary
> > incompatibility shouldn't happen in the first place. Ian,
Is anyone aware, or know how to resolve the slowness of the current DRI
CVS, I'm only getting 30fps with glxgears compared to the 250+fps with
the SF dri cvs.
Note, Direct Rendering is enabled
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server
I'm running a radeon-7500 card and been playing wolfenstein and quake3
just fine under Fedora Core 3 (redhat beta). I just got America's Army
to try it. Well it runs fine but the 3D rendering is messed up. How can
I tell if this is a dri bug or a game bug? Is anyone playing this game?
This bug rep
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-21-10 18:43 ---
Thanks to everyone in
On Wed, 2003-10-22 at 01:59, Vladimir Dergachev wrote:
> >
> > Anyway, I think the most important point is that the DRM should be able
> > to deal with whatever you throw at it this way; the details can still be
> > changed later. Agreed?
>
> DRM and DRI drivers. :)
What do you mean? Old 3D driv
On Wed, 2003-10-22 at 00:55, Chris Ison wrote:
> > Have you done all the proper idiot checks?
> >
> > I hate to use the word that way, but that's how I'd phrase it if I were
> > speaking to myself...
> >
> > Have you checked to make sure /dev/dri/card0 exists, has the proper
> > major and minor
> > > > time.
> > >
> > > Any idea how soon that will be? I was originally hoping to sneak this
> > > into XFree86 4.4, but that's getting less likely by the day.
> >
> > No idea unfortunately. I'll be very busy the next three weeks and to make
> > tests I would need to port GATOS code to DRI CVS.
> Have you done all the proper idiot checks?
>
> I hate to use the word that way, but that's how I'd phrase it if I were
> speaking to myself...
>
> Have you checked to make sure /dev/dri/card0 exists, has the proper
> major and minor numbers, and is readable and writeable by root?
>
ok, /dev
On Tue, 2003-10-21 at 17:13, Vladimir Dergachev wrote:
> On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> > > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> > >
> > > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wro
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-
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I w
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> >
> > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> > >
> > > > 2) I would have expected SetFBLocation functi
Felix Kühling wrote:
glcontextmodes.o gets linked to libGL, not the driver. Apperently you
have an outdated libGL installed. Though this kind of binary
incompatibility shouldn't happen in the first place. Ian, there is a
symbolic link to lib/GL/glx/glcontextmodes.c in lib/GL/dri. I can only
guess t
forgot to mention I don't use radeonfb and ldmod shows the module not in
use
(null):/home/ceison# lsmod | grep radeon
radeon117648 0
(null):/home/ceison#
---
This SF.net email is sponsored by OSDN developer relations
Here's
On Tue, 2003-10-21 at 11:06, Keith Whitwell wrote:
>
> In r200_screen.c, you check for drmMinor >= 10 before issuing the FB_LOCATION
> ioctl, but it's not clear what happens if drmMinor < 10 -- will the driver
> function correctly? [...]
Yes. The driver determines the memory layout from the chi
On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> >
> > > 2) I would have expected SetFBLocation function to make sure that
> > > the card is idle. Maybe this is done
On Tue, 21 Oct 2003 13:23:52 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-10-20 at 23:46, Felix Kühling wrote:
> >
> > I attached a patch that adds color dithering and rounding options to the
> > radeon and r200 drivers. I'd like to hear some comments about the
> > semantics of t
On Tue, 2003-10-21 at 21:29, Michel Dänzer wrote:
> On Tue, 2003-10-21 at 16:03, Chris Ison wrote:
> >
> > Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting
> > kernel.
>
> This happens here when I insmod radeon.o instead of radeon.ko with a 2.6
> kernel. It still works though, wh
On Tue, 2003-10-21 at 16:03, Chris Ison wrote:
>
> Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting
> kernel.
This happens here when I insmod radeon.o instead of radeon.ko with a 2.6
kernel. It still works though, what happens if you try to load the
module manually? If you're usi
On Mon, 2003-10-20 at 23:46, Felix Kühling wrote:
>
> I attached a patch that adds color dithering and rounding options to the
> radeon and r200 drivers. I'd like to hear some comments about the
> semantics of the options I chose before I commit anything [...]
Is there a reason why dithering and
On Tue, 2003-10-21 at 05:14, Eric Anholt wrote:
>
> One small problem in radeon_fb_location ioctl: For OS-independence, so
> far filp has been an opaque void pointer. I'm wondering if maybe we
> want to pass the drm_file_t * as part of DRM_IOCTL_ARGS, or just
> resurrect DRM_PRIV to get the drm_
Michel Dänzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unle
please find attached the XFree86 log and config, also note that if I use
the old cvs from SF it works fine with the exact same config
Oct 21 23:56:47 (null) kernel: [drm] Module unloaded
Oct 21 23:56:51 (null) kernel: radeon: no version magic, tainting
kernel.
Oct 21 23:57:13 (null) gconfd (ceis
Felix Kühling wrote:
glcontextmodes.o gets linked to libGL, not the driver. Apperently you
have an outdated libGL installed. Though this kind of binary
incompatibility shouldn't happen in the first place. Ian, there is a
symbolic link to lib/GL/glx/glcontextmodes.c in lib/GL/dri. I can only
guess 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. :)
Michel Dänzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unle
glcontextmodes.o gets linked to libGL, not the driver. Apperently you
have an outdated libGL installed. Though this kind of binary
incompatibility shouldn't happen in the first place. Ian, there is a
symbolic link to lib/GL/glx/glcontextmodes.c in lib/GL/dri. I can only
guess that the intention is
36 matches
Mail list logo
