I realize I should have sent this out earlier, but on Thursday I
committed a change to the manner that DRM devices are probed. Ideally
it won't have any effect on people, but there may have been problems.
Basically, the DRM only attaches now when it finds a device ID it knows
of. I think the
On Mon, 2003-10-20 at 14:52, Jon Smirl wrote:
Eric Anholt is in the middle of doing a generic fix for this problem. See the
Adding hardware detection to DRI drivers thread. The current DRM drivers now
do PCI ID detection on both Linux and BSD. He is also adding an enum for chip
family but I'm
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
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
Michel Dnzer 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)
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
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
also cut from syslog
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
Michel Dnzer 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)
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
On Mon, 2003-10-20 at 23:46, Felix Khling 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 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 using
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, what
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 the options
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 someplace
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 chip
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
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
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 function to make
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
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
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 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 numbers, and is readable and writeable by root?
ok,
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. There should be a
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 numbers, and
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 drivers work
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
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
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 or
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
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
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
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
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 {
int
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 {
int
34 matches
Mail list logo
