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.
> >>
> >> exc
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.
>
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
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
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
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 app
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 a
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 20
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 wh
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 PROTECTED
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 radeon
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 R200_NO_TCL
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
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=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=1556
[EMAIL PROTECTED] changed:
What|Removed |Added
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
> > loa
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 kn
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 e
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 bug
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
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 0xe800
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
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 IR
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...)
c
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
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
Howeve
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 o
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, glx
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/
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
Vers
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_f
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
33 matches
Mail list logo
