On Sun, Sep 05, 2004 at 11:33:53AM -0400, Jon Smirl wrote:
Then how am I going to merge fbdev and DRM so that we don't have two
drivers fighting over the same hardware? I was planning on adding
pieces of the existing fbdev code to DRM in order to implement printk
from the kernel. It seems
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-09-06 00:38 ---
hi,
the
There were reports (and I experienced it myself) of Radeon 9200-based
cards where the DVI output got disabled by DRI applications. After
exiting the 3D application, VT switching to another virtual terminal and
back to X restored the display. Are you using the DVI output on your
card? If yes, can
Both r200 and savage dri cvs snapshots for 20040905 fail to compile on
virgin 2.6.8.1
dri.log says
make DRM_MODULES=radeon.o modules
make[1]: Entering directory `/home/diablo/code/dri/dripkg/drm'
rm -f linux
ln -s . linux
make -C /lib/modules/2.6.8.1/source SUBDIRS=`pwd` DRMSRCDIR=`pwd`
On Sun, 05 Sep 2004 20:14:43 -0400
Lee Revell [EMAIL PROTECTED] wrote:
On Sun, 2004-09-05 at 16:18, Patrick McFarland wrote:
[snip]
That shouldn't matter, should it? The userland stuff should never lock
the machine up.
I'll test it anyhow, though.
No, it shouldn't. Anything that
On Sun, 05 Sep 2004 20:14:43 -0400, Lee Revell [EMAIL PROTECTED] wrote:
How to fix this is a pretty hot topic now.
Yow, I didn't mean to cause such an upset. ;)
Currently, the dri cvs snapshot for 20040905 doesn't compile with
2.6.8.1 for me (I've sent
a bug report to the dri-devel mailing list
Am Freitag, 27. August 2004 21:56 schrieb Philipp Klaus Krause:
The same as the patches I sent earlier, but as a single unified file.
For those that didn't read the original posting: This patch enables
GL_ARB_vertex_program support for the r200 driver. The vertex programs
are executed in
In file included from /home/diablo/code/dri/dripkg/drm/radeon_drv.c:47:
/home/diablo/code/dri/dripkg/drm/drm_drv.h: In function `radeon_release':
/home/diablo/code/dri/dripkg/drm/drm_drv.h:974: error: structure has no member n
amed `free_filp_private'
When will we see this in?
http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2
I've reviewed it and would be happy with it as well, but I would like a
driconf option to turn it off in case it some apps have issues..
adding a driconf option is explained at:
sn, 05,.09.2004 kl. 21.13 -0400, skrev Michel Dnzer:
On Fri, 2004-09-03 at 17:03 +0200, Luca Zini wrote:
I have an ati 9000 on a asus a7n8x-x.
the direct rendering works well, and I can use glxgears, celestia and
some other application that need it, but a lot of games don't work.
For
Am Montag, 6. September 2004 13:32 schrieb Dave Airlie:
In file included from /home/diablo/code/dri/dripkg/drm/radeon_drv.c:47:
/home/diablo/code/dri/dripkg/drm/drm_drv.h: In function `radeon_release':
/home/diablo/code/dri/dripkg/drm/drm_drv.h:974: error: structure has no
member n amed
Hi,
after upgrading the DRM (it has been a while since the last cvs update)
the Savage driver stopped working. I tracked it down to the DRM refusing
to create multiple framebuffer-type mappings. If it finds an existing mapping
it returns it instead of creating a new one. However, the Savage
As suggested I tried to connect a vga cable, and seem to work even in dvi mode.
Thanks for the info!
regards,
Luca
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free
Lee Revell [EMAIL PROTECTED] said:
[...]
Wrong and wrong. If you run Debian unstable (which is WAY more stable
than, say, FC2) then you can apt-get upgrade to the latest kernel.
What makes you say this? I've seen no stability problems with FC2.
--
Dr. Horst H. von Brand
Dave Airlie schrieb:
When will we see this in?
http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2
I've reviewed it and would be happy with it as well, but I would like a
driconf option to turn it off in case it some apps have issues..
adding a driconf option is explained at:
On Mon, 2004-09-06 at 07:01 -0400, Patrick McFarland wrote:
On Sun, 05 Sep 2004 20:14:43 -0400, Lee Revell [EMAIL PROTECTED] wrote:
How to fix this is a pretty hot topic now.
Yow, I didn't mean to cause such an upset. ;)
Currently, the dri cvs snapshot for 20040905 doesn't compile with
+0200
@@ -62,7 +62,7 @@
#include r200_vtxfmt.h
#include r200_maos.h
-#define DRIVER_DATE 20030328
+#define DRIVER_DATE 20040906
#include vblank.h
#include utils.h
@@ -166,6 +166,7 @@
_tnl_fog_coordinate_stage,
_tnl_texgen_stage,
_tnl_texture_transform_stage
/r200_context.c 2004-09-06 22:17:06 +0200
@@ -62,7 +62,7 @@
#include r200_vtxfmt.h
#include r200_maos.h
-#define DRIVER_DATE 20030328
+#define DRIVER_DATE 20040906
#include vblank.h
#include utils.h
@@ -166,6 +166,7 @@
_tnl_fog_coordinate_stage,
_tnl_texgen_stage
On Llu, 2004-09-06 at 21:58, Hamie wrote:
The fs - SCSI interface is a logical one.
We just have to make the fb and DRI to hardware one logical.
Unless you can have fb sitting on top of DRM of course... (I discount
DRM on-top of fb, because of the D == Direct... No other reason :)...
Does
On Llu, 2004-09-06 at 21:19, Philipp Klaus Krause wrote:
'Did some more testing and found bugs.
Here is the corrected patch.
Not having looked at this before - is there a reason for DRI_CONF_DESC
not using standard internationalisation functions.
Alan Cox wrote:
On Sul, 2004-09-05 at 23:11, Jon Smirl wrote:
What is the advantage to continuing a development model where two
groups of programmers work independently, with little coordination on
two separate code bases trying to simultaneously control the same
piece of hardware? This is a
I investigated the problem a bit before I returned that card. I was able to get
the same effect by running x11perf for a while. So I suspect it's not directly
related to DRI or the 3D engine but a general power supply or overheating problem
that occurs when the chip is stressed for some time.
I investigated the problem a bit before I returned that card. I was able to get
the same effect by running x11perf for a while. So I suspect it's not directly
related to DRI or the 3D engine but a general power supply or overheating problem
that occurs when the chip is stressed for some time.
Some examples of merging are turning two independent radeon
personality modules into a single one. Another thing I need to do is
to extract the printk support from the core fb module and put it
somewhere I can get to it from DRM. We can't have two cores trying to
attach to the same device and then
On Mon, 06 Sep 2004 21:21:00 +0100
Alan Cox [EMAIL PROTECTED] wrote:
On Llu, 2004-09-06 at 21:19, Philipp Klaus Krause wrote:
'Did some more testing and found bugs.
Here is the corrected patch.
Not having looked at this before - is there a reason for DRI_CONF_DESC
not using standard
Am Montag, 6. September 2004 22:19 schrieb Philipp Klaus Krause:
'Did some more testing and found bugs.
Here is the corrected patch.
Works fine.
Out for vacation, now.
Dieter
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE
On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote:
In some cases yes. The DRM is happy with the idea of the kernel being a
DRM client too.
Thats actually a pretty cool idea. For us that need to use the vesa
fbcon driver because
there is no native driver, it would probably be
Okay if nobody pops up with a problem I'll check it in later on today...
Dave.
On Mon, 6 Sep 2004, Philipp Klaus Krause wrote:
'Did some more testing and found bugs.
Here is the corrected patch.
Philipp
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at
Anyway, I suspect the behaviour of DRM(addmap) changed recently. The
only addmap-related comment I could find on dri-patches is this:
addmap-base-2 patch from Jon Smirl:
sets up the DRM to have the ability to have permanent maps while the driver is
loaded...
Is it really necessary
On Llu, 2004-09-06 at 22:50, Felix Khling wrote:
We want the description strings in all available languages to be
compiled into the 3D drivers. All these macros result in a small
XML-document which is looked up via dlopen/dlsym by the configuration
tool (or xdriinfo as a helper for script
The plan for the addMap changes is to get rid of the loop where the
user space code asks the driver where the resources are and then sets
those values back into the driver. Since the driver already knows
these values it should just create the maps itself. This removes the
possibility of the user
But does the new code deal with multiple mappings.. the radeon doesn't do
this at the moment they call multiple addmaps for the framebuffer,
A permanently mapped framebuffer, shouldn't stop you adding another
mapping for tiling/whatever... or should it..
Dave.
On Mon, 6 Sep 2004, Jon
AddMap has the loop to find the existing mapping and replace it.
initmap doesn't have that loop so it allows multiple adds. I wanted to
just make AddMap refuse a REG/FB map request but I was trying to be
compatible while we changed the drivers over.
Can we just switch the drivers over right now
I decided my loop was too fancy so I just deleted it and replaced it
with a simple flag. If the driver uses permanent maps the flag gets
set and addmaps from user space have no effect. If the driver doesn't
use permanent maps everything should work the old way.
If this looks good I can check it
On Mon, 6 Sep 2004 16:55:10 +0200, Felix Kühling [EMAIL PROTECTED] wrote:
after upgrading the DRM (it has been a while since the last cvs update)
the Savage driver stopped working. I tracked it down to the DRM refusing
to create multiple framebuffer-type mappings. If it finds an existing
35 matches
Mail list logo
