On Mon, Oct 18, 2004 at 01:32:22 -0400, Vladimir Dergachev wrote:
Just to be sure: will the microcode only be loaded if the device will
be used, e.g. by the X.org driver? Until now I just load the module and
Yes. In fact DRM driver needs Xserver to tell it which microcode to load.
OK, now
On Tue, Oct 12, 2004 at 06:25:55PM -0300, [EMAIL PROTECTED] wrote:
Because some chips(at least s3 DeltaChrome) can't use=20
system memory as DMA buffer(or vertex buffer),for pci card,we
use video memory as dma/vertex buffer. Then whether is it reasonable
to add a function like drm_addbufs_fb
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=1662
Summary: Unknown symbol: remap_page_range
Product: DRI
On Mon, 18 Oct 2004 16:07:05 -0300, Austin Yuan
[EMAIL PROTECTED] wrote:
On Tue, Oct 12, 2004 at 06:25:55PM -0300, [EMAIL PROTECTED] wrote:
Because some chips(at least s3 DeltaChrome) can't use=20
system memory as DMA buffer(or vertex buffer),for pci card,we
use video memory as dma/vertex
What I am missing?
You need the patch for the 2d driver - it is on the front page.
Try ati.patch.4.
Thanks again. Looks like I used the wrong 2d driver patch before
(xorg680.atipatch.r300). Now the glxinfo output looks right:
OpenGL renderer string: Mesa DRI R300 20040924 AGP 4x NO-TCL
However,
On Mon, Oct 18, 2004 at 09:13:57 +0200, Tino Keitel wrote:
[...]
Thanks again. Looks like I used the wrong 2d driver patch before
(xorg680.atipatch.r300). Now the glxinfo output looks right:
OpenGL renderer string: Mesa DRI R300 20040924 AGP 4x NO-TCL
However, glxgears only prints out
On Mon, 18 Oct 2004, Tino Keitel wrote:
On Mon, Oct 18, 2004 at 09:13:57 +0200, Tino Keitel wrote:
[...]
Thanks again. Looks like I used the wrong 2d driver patch before
(xorg680.atipatch.r300). Now the glxinfo output looks right:
OpenGL renderer string: Mesa DRI R300 20040924 AGP 4x NO-TCL
On Fri, Oct 15, 2004 at 11:40:30AM -0400, Jon Smirl wrote:
On Fri, 15 Oct 2004 15:19:41 +0100, José Fonseca
[EMAIL PROTECTED] wrote:
It doesn't say nothing and I found (partially) why: the dynamic lynking
is failing, so the call to drm_init(pci_driver, pciidlist, driver)
never reaches a
could someone try current radeon driver from mesa-cvs HEAD
to see if it works with gears/glxgears in tcl and non-tcl mode?
I was able to get instant reboots, deadlocks and hangs.
The driver before 25.Sep.2004 seems ok.
(you might switch off dma for all harddisks and do sync before trying...)
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
Am Dienstag, 12. Oktober 2004 20:24 schrieb Ian Romanick:
Dieter Nützel wrote:
NONE of your three versions gave me direct rendering?!
I've tested with and without your TLS-patch (progress?).
The symbols are in.
DRI-Mesa/Patches nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep
I can't get the drm module (radeon.ko) from cvs, linux-2.6 directory to
work.
I'm not sure since when it no longer works, I haven't updated it for ages...
Starting Xorg shows up in the kernel log as follows:
Oct 18 21:47:48 ZakTower kernel: mtrr: 0xe800,0x400 overlaps
existing
Do you have the new radeon framebuffer driver loaded? If so, try
loading the old one. Let me know and I'll check it out more here.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use
On Mon, 18 Oct 2004 22:05:17 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
I can't get the drm module (radeon.ko) from cvs, linux-2.6 directory to
work. I'm not sure since when it no longer works, I haven't updated it for ages...
You should also update to current cvs there have been bugs
Jon Smirl wrote:
Do you have the new radeon framebuffer driver loaded? If so, try
loading the old one. Let me know and I'll check it out more here.
No, I'm using the old vesa framebuffer (compiled in). I'll have radeonfb
compiled as a module, but it's not loaded.
(I'm basically using vesa due to
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=1657
--- Additional Comments From [EMAIL PROTECTED] 2004-10-18 14:10 ---
fglrx is
you can't have the fglrx driver loaded with the newer DRM's. They are
both trying to control the same piece of hardware.
On Mon, 18 Oct 2004 22:52:45 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Do you have the new radeon framebuffer driver loaded? If so, try
loading
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=1556
[EMAIL PROTECTED] changed:
What|Removed |Added
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=1509
[EMAIL PROTECTED] changed:
What|Removed |Added
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=1521
[EMAIL PROTECTED] changed:
What|Removed |Added
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=1504
[EMAIL PROTECTED] changed:
What|Removed |Added
Hi,
I was testing some apps on my PCI 9200. And I noticed that they run
terribly slow. But when i switched to wireframe mode the frame rate
seemed much better. This seemed strange. IIRC radeons are much faster in
rendering solid geometry than wireframe. So after a little thinking I
set
I don't load fglrx at the same time of course, I just want to be able to
load it from time to time (it used to garble the framebuffer console
completely if you used radeonfb, might even have caused lockups, can't
remember exactly).
I can of course try radeonfb instead of vesa with the new
What Radeon chip is is it? Maybe it doesn't have an i2c port on it. It
is the i2c conflict that is causing the module load to fail.
The code knows about VESAfb and works around it so that should be ok.
I believe both the new and old radeonfb drivers should work too.
--
Jon Smirl
[EMAIL
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
excuse my ignorance, but where would I get that new radeonfb driver?
btw I've also tried the linux-core version. Just the same:
Oct 19 02:26:26 ZakTower kernel: [drm] Initialized drm 1.0.0
On Tue, 19 Oct 2004, Roland Scheidegger wrote:
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
excuse my ignorance, but where would I get that new radeonfb driver?
Try latest 2.6.x kernel. You might need to apply the rc4 patch.
There is
Vladimir Dergachev wrote:
On Tue, 19 Oct 2004, Roland Scheidegger wrote:
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
excuse my ignorance, but where would I get that new radeonfb driver?
Try latest 2.6.x kernel. You might need to
On Tue, 19 Oct 2004 03:02:45 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Jon Smirl wrote:
What Radeon chip is is it? Maybe it doesn't have an i2c port on it. It
is the i2c conflict that is causing the module load to fail.
It's a rv250 (radeon 9000pro).
I have a radeon 9000pro with an
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=1668
Summary: DRM doesn't support buffers in video memory
Product: DRI
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=1668
--- Additional Comments From [EMAIL PROTECTED] 2004-10-18 19:39 ---
Created an
I fixed this segfault. It was an error path that hadn't been hit before.
It is checked into CVS.
On Tue, 19 Oct 2004 02:43:02 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
On Tue, 19 Oct 2004 03:12:36 +0200, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Vladimir Dergachev wrote:
On Tue, 19 Oct 2004, Roland Scheidegger wrote:
Jon Smirl wrote:
Does the new radeonfb driver in the kernel load? It uses the same I2C
initialization code.
excuse my ignorance, but
33 matches
Mail list logo
