Re: current DRM CVS
Dave Airlie wrote: If I get a chance this evening or over the weekend, I think we need to split 2.4 and 2.6, they can pretty much share everything that isn't drm_stub.h and drm_drv.h from what I can see... I think linknig over files into a 2.4 build might help a lot... Jon most of the 2.6 specific stuff is in these files (or is it spreading out amoing the rest?)... I was going to suggest something similar - it looks like a split will help both 2.6 development and 2.4 stability. Keith --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: current DRM CVS
If I get a chance this evening or over the weekend, I think we need to split 2.4 and 2.6, they can pretty much share everything that isn't drm_stub.h and drm_drv.h from what I can see... I think linknig over files into a 2.4 build might help a lot... Jon most of the 2.6 specific stuff is in these files (or is it spreading out amoing the rest?)... Dave. On Thu, 23 Sep 2004, Jon Smirl wrote: > I just fixed DRM CVS so that it compiles again on 2.4 but it doesn't work. > > I'm open to clean solutions for making DRM(probe) in drm_stub.h work on 2.4. > 2.4 is missing all of the register_chrdev_region, cdev_init, cdev_add, > kobject stuff. > This is too complicated for stubbing things out with inlines to work. > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
current DRM CVS
I just fixed DRM CVS so that it compiles again on 2.4 but it doesn't work. I'm open to clean solutions for making DRM(probe) in drm_stub.h work on 2.4. 2.4 is missing all of the register_chrdev_region, cdev_init, cdev_add, kobject stuff. This is too complicated for stubbing things out with inlines to work. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
latest Mesa radeon crashing out...
I'm running Mesa top of CVS with S3TC on Radeon 9200, my app is crapping out with [drm:radeon_emit_packets] *ERROR* Packet size provided larger than data provided [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed in dmesg and drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) I'm running 2.6.8.1 from FC2, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
- Original Message - From: Alex Deucher <[EMAIL PROTECTED]> Date: Wed, 22 Sep 2004 14:02:16 -0400 To: Vladimir Dergachev <[EMAIL PROTECTED]> Subject: Re: [r300] - likely compatibility w rv360? > On Wed, 22 Sep 2004 13:27:23 -0400 (EDT), Vladimir Dergachev > <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, 22 Sep 2004, Dag Bakke wrote: [snip] > > > agpgart: Bridge couldn't do AGP x4. > > > agpgart: Putting AGP V3 device at :00:00.0 into 0x mode > > > agpgart: Putting AGP V3 device at :01:00.0 into 0x mode > > > [drm] Loading R300 Microcode > > > > I think I've seen this one - check your BIOS settings - maybe you need to > > enable something AGP related there. > > As I recall, since the X server doesn't have official 8x agp support > yet for radeons, you have to force the bridge into 4x mode in the bios > so it comes up in 4x mode. > > Alex Bingo. My rv360 now runs all the r300_demo tests. They look about the same as the snapshots on r300.sf.net. --triangles comes out a bit different than http://r300.sourceforge.net/files/how_it_looks.1.png I get one multicolored and one white triangle. But it does not hang the graphics. Looking forward to a steady stream of improvements! Thanks, Dag B --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
On Wed, Sep 22, 2004 at 09:18:55AM -0800, Dag Bakke wrote: > agpgart: Found an AGP 3.5 compliant device at :00:00.0. > agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a0a tmp:1f000a0a f > ell back to:- cmd:1f000a08 tmp:1f000a0a] > agpgart: Bridge couldn't do AGP x4. > agpgart: Graphic card couldn't do AGP x4. > agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a08 tmp:ff00021b f > ell back to:- cmd:1f000208 tmp:ff00021b] > agpgart: Bridge couldn't do AGP x4. > agpgart: Putting AGP V3 device at :00:00.0 into 0x mode > agpgart: Putting AGP V3 device at :01:00.0 into 0x mode Is this with a current (2.6.9rc2) kernel ? I thought I fixed this up a while back. If it is, can you mail me an lspci -x output please? > I have Cc:ed davej. > If he is in his normal mode (swamped by email), he'll read it really fast... > ..with the 'd' key. :-) I'm somewhat latent right now due to me being in the middle of a relocation, but I'm trying to stay on top of stuff I'm Cc'd on at least.. (Though no promises right now on turnaround time) Dave --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
Alex Deucher wrote: On Wed, 22 Sep 2004 18:56:40 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: I think I've seen this one - check your BIOS settings - maybe you need to enable something AGP related there. As I recall, since the X server doesn't have official 8x agp support yet for radeons, you have to force the bridge into 4x mode in the bios so it comes up in 4x mode. How very interesting. Alex - could you tell me what is involved in providing AGP 8x mode ? I thought the speed was invisible to software. This patch: http://penguinppc.org/~daenzer/DRI/radeon-agp8x.diff although I hear the speed difference between 4x and 8x is minimal...at least on r200 hardware. r300 may be different. I don't have an 8x motherboard to test. If someone could test the patch we should probably apply it at some point. That doesn't look though like it would fix (didn't test) the problem I have with agpgart: Sep 22 18:35:31 ZakTower kernel: agpgart: Found an AGP 3.5 compliant device at :00:0 0.0. Sep 22 18:35:31 ZakTower kernel: agpgart: Device is in legacy mode, falling back to 2.x Sep 22 18:35:31 ZakTower kernel: agpgart: Putting AGP V2 device at :00:00.0 into 0x mode Sep 22 18:35:31 ZakTower kernel: agpgart: Putting AGP V2 device at :01:00.0 into 0x mode Sep 22 18:35:31 ZakTower kernel: agpgart: Putting AGP V2 device at :01:00.1 into 0x mode Seems to happen with AGP 3.0 (or only 3.5? whatever that is) bridges and AGP 2.0 cards. Don't think though that's a radeon problem, not even sure it really is a problem (still works, though I don't know what happens if agpgart tries to set a 0x mode?), but it certainly is confusing... Roland --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
On Wed, 22 Sep 2004 18:56:40 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > >> I think I've seen this one - check your BIOS settings - maybe you need to > >> enable something AGP related there. > > > > As I recall, since the X server doesn't have official 8x agp support > > yet for radeons, you have to force the bridge into 4x mode in the bios > > so it comes up in 4x mode. > > How very interesting. Alex - could you tell me what is involved in > providing AGP 8x mode ? I thought the speed was invisible to software. This patch: http://penguinppc.org/~daenzer/DRI/radeon-agp8x.diff although I hear the speed difference between 4x and 8x is minimal...at least on r200 hardware. r300 may be different. I don't have an 8x motherboard to test. If someone could test the patch we should probably apply it at some point. Alex > > thank you ! > > Vladimir Dergachev > --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Question about FRONT BUFFER?
Is the frontbuffer shared between all contexts, or for each Context there will be a different frontbuffer? In direct rendering I understand that frontbuffer point to the visible framebuffer of the card (write to screen). Using at the end the position of the window and its clips mask you will write to the frontbuffer (framebuffer), correct me if I am wrong please! Amir Bukhari E-Mail: [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
I think I've seen this one - check your BIOS settings - maybe you need to enable something AGP related there. As I recall, since the X server doesn't have official 8x agp support yet for radeons, you have to force the bridge into 4x mode in the bios so it comes up in 4x mode. How very interesting. Alex - could you tell me what is involved in providing AGP 8x mode ? I thought the speed was invisible to software. thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
so it comes up in 4x mode. Alex Bingo. My rv360 now runs all the r300_demo tests. They look about the same as the snapshots on r300.sf.net. --triangles comes out a bit different than http://r300.sourceforge.net/files/how_it_looks.1.png I get one multicolored and one white triangle. Yep, that's how it is supposed to look - I changed the code around a bit. But it does not hang the graphics. Great ! Looking forward to a steady stream of improvements! If you want to play with this, e-mail me your SourceForge handle, so I can give you access to the CVS. best Vladimir Dergachev Thanks, Dag B --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
PATCH: DRM and sysfs
This code switches DRM off from class simple to it's own internal
sysfs code. You need to do this in order to add attributes. The
attached code adds a simple "version" attribute. More attributes are
planned once the initial framework is in place.
This code has a bunch of ifdef kernel versions in it. Is there a
better way to do this? It also contains some overall clean up on the
way to a drm_core model.
drm_sysfs.h is a GPL derivative of drivers/base/class_simple.c
Note the DRM() macros around function names can not be removed until
we convert to drm_core.
The register_chardev_range() is to free up some minor numbers for VGA
devices when the driver gets written. If VGA gets it's own major we
can switch back to register_chardev().
--
Jon Smirl
[EMAIL PROTECTED]
diff -Nru a/linux/Makefile b/linux/Makefile
--- a/linux/Makefile 2004-09-22 18:08:04 -04:00
+++ b/linux/Makefile 2004-09-22 18:08:04 -04:00
@@ -69,7 +69,8 @@
DRMTEMPLATES = drm_auth.h drm_bufs.h drm_context.h drm_dma.h drm_drawable.h \
drm_drv.h drm_fops.h drm_init.h drm_ioctl.h drm_irq.h \
-drm_lock.h drm_memory.h drm_proc.h drm_stub.h drm_vm.h
+drm_lock.h drm_memory.h drm_proc.h drm_stub.h drm_vm.h \
+drm_sysfs.h drm_core.h
DRMSHARED = drm.h drm_sarea.h
DRMHEADERS =drmP.h $(DRMSHARED)
diff -Nru a/linux/drmP.h b/linux/drmP.h
--- a/linux/drmP.h 2004-09-22 18:08:04 -04:00
+++ b/linux/drmP.h 2004-09-22 18:08:04 -04:00
@@ -56,7 +56,9 @@
#include /* For (un)lock_kernel */
#include
#include
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)
#include
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include /* For pte_wrprotect */
#endif
@@ -693,7 +695,7 @@
typedef struct drm_global {
unsigned int cards_limit;
drm_minor_t *minors;
- struct class_simple *drm_class;
+ struct drm_sysfs_class *drm_class;
struct proc_dir_entry *proc_root;
struct cdev drm_cdev;
} drm_global_t;
diff -Nru a/linux/drm_compat.h b/linux/drm_compat.h
--- a/linux/drm_compat.h 2004-09-22 18:08:04 -04:00
+++ b/linux/drm_compat.h 2004-09-22 18:08:04 -04:00
@@ -108,22 +108,25 @@
#define old_encode_dev(x) (x)
-struct class_simple;
+struct drm_sysfs_class;
struct device;
#define pci_dev_put(x) do {} while (0)
#define pci_get_subsys pci_find_subsys
-#define class_simple_device_add(...) do {} while (0)
+#define DRM(sysfs_device_add)(...) do {} while (0)
-static inline void class_simple_device_remove(dev_t dev){}
+static inline void DRM(sysfs_device_remove)(dev_t dev){}
-static inline void class_simple_destroy(struct class_simple *cs){}
+static inline void DRM(sysfs_destroy)(struct class_simple *cs){}
-static inline struct class_simple *class_simple_create(struct module *owner, char *name) { return (struct class_simple *)owner; }
+static inline struct drm_sysfs_class *DRM(sysfs_create)(struct module *owner, char *name) { return (struct class_simple *)owner; }
#ifndef pci_pretty_name
#define pci_pretty_name(x) x->name
+
+struct cdev {};
+
#endif
#endif
diff -Nru a/linux/drm_core.h b/linux/drm_core.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/linux/drm_core.h 2004-09-22 18:08:04 -04:00
@@ -0,0 +1,44 @@
+/*
+ * Copyright 2004 Jon Smirl <[EMAIL PROTECTED]>
+ * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved.
+ * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * VIA, S3 GRAPHICS, AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "drm_auth.h"
+#include "drm_agpsupport.h"
+#include "drm_bufs.h"
+#include "drm_context.h"
+#include "drm_dma.h"
+#include "drm_irq.h"
+#include "drm_drawable.h"
+#include "drm_drv.h"
+#include "drm_fops.h"
+#include "drm_init.h"
+#include "drm_ioctl.h"
+#include "drm_lock.h"
+#include "drm_memory.h"
+#include "drm_pci.h"
+#include "drm_proc.h"
+#include "drm_vm.h"
+#include "drm_sysfs.h"
+#include "drm_stub.h"
+#include "drm_scatter.h"
diff -Nru a
Re: exception testing in r200 driver
On Wed, 2004-09-22 at 13:21, Ian Romanick wrote: > Philipp Klaus Krause wrote: > > _mesa_test_os_sse_exception, executed upon start of any OpenGL > > application raises SIGFPE. Normally this is not a problem, > > applications continue to execute normally. > > > > However when using the jogl OpenGL Java binding programs exit. > > I tried both with Java 1.4 from Sun and sablevm. > > That's annoying. It seems like it must be a bug somewhere, but it's not > obvious to me where. Can you track down why / where the program > terminates? I looked at the code in check_os_sse_support > (src/mesa/x86/common_x86.c, line 143), and it doesn't look like there > should be any way for the signal to get past Mesa. > > Beyond that, the code in there *is* really awful. Is there a better way > on modern-ish Linux systems to do this? Comments in the code indicate > that a lot of the uglyness there is to workaround issues with certain > 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, > what's the right way on a 2.4 or a 2.6 kernel to determine if an app can > use SSE? What about BSD? On FreeBSD we just use a convenient little sysctl to pull out whether there's SSE and the kernel supports it. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
Philipp Klaus Krause wrote: _mesa_test_os_sse_exception, executed upon start of any OpenGL application raises SIGFPE. Normally this is not a problem, applications continue to execute normally. However when using the jogl OpenGL Java binding programs exit. I tried both with Java 1.4 from Sun and sablevm. That's annoying. It seems like it must be a bug somewhere, but it's not obvious to me where. Can you track down why / where the program terminates? I looked at the code in check_os_sse_support (src/mesa/x86/common_x86.c, line 143), and it doesn't look like there should be any way for the signal to get past Mesa. Beyond that, the code in there *is* really awful. Is there a better way on modern-ish Linux systems to do this? Comments in the code indicate that a lot of the uglyness there is to workaround issues with certain 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, what's the right way on a 2.4 or a 2.6 kernel to determine if an app can use SSE? What about BSD? It sure would be nice to be able to get rid of the exception check altogether. That would end the false bug reports from newbies, if nothing else. :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
On Wed, 22 Sep 2004 13:27:23 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > > On Wed, 22 Sep 2004, Dag Bakke wrote: > > > > [drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc RV350 > > AR [Radeon 9600] > > agpgart: Found an AGP 3.5 compliant device at :00:00.0. > > agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a0a tmp:1f000a0a f > > ell back to:- cmd:1f000a08 tmp:1f000a0a] > > agpgart: Bridge couldn't do AGP x4. > > agpgart: Graphic card couldn't do AGP x4. > > agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a08 tmp:ff00021b f > > ell back to:- cmd:1f000208 tmp:ff00021b] > > agpgart: Bridge couldn't do AGP x4. > > agpgart: Putting AGP V3 device at :00:00.0 into 0x mode > > agpgart: Putting AGP V3 device at :01:00.0 into 0x mode > > [drm] Loading R300 Microcode > > I think I've seen this one - check your BIOS settings - maybe you need to > enable something AGP related there. As I recall, since the X server doesn't have official 8x agp support yet for radeons, you have to force the bridge into 4x mode in the bios so it comes up in 4x mode. Alex > >best > > Vladimir Dergachev > > > --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
On Wed, 22 Sep 2004, Dag Bakke wrote: [drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc RV350 AR [Radeon 9600] agpgart: Found an AGP 3.5 compliant device at :00:00.0. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a0a tmp:1f000a0a f ell back to:- cmd:1f000a08 tmp:1f000a0a] agpgart: Bridge couldn't do AGP x4. agpgart: Graphic card couldn't do AGP x4. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a08 tmp:ff00021b f ell back to:- cmd:1f000208 tmp:ff00021b] agpgart: Bridge couldn't do AGP x4. agpgart: Putting AGP V3 device at :00:00.0 into 0x mode agpgart: Putting AGP V3 device at :01:00.0 into 0x mode [drm] Loading R300 Microcode I think I've seen this one - check your BIOS settings - maybe you need to enable something AGP related there. best Vladimir Dergachev --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
- Original Message - From: Vladimir Dergachev <[EMAIL PROTECTED]> Date: Wed, 22 Sep 2004 01:23:38 -0400 (EDT) To: Dag Bakke <[EMAIL PROTECTED]> Subject: Re: [r300] - likely compatibility w rv360? > > Hi Dag, > > Try this: before starting X switch to another console and execute: > > sleep 15 ; dmesg > dmesg.1 ; sync > > Then start X, wait 30 seconds and shutdown your machine after that - this > will let you look at dmesg messages. Indeed. [drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc RV350 AR [Radeon 9600] agpgart: Found an AGP 3.5 compliant device at :00:00.0. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a0a tmp:1f000a0a f ell back to:- cmd:1f000a08 tmp:1f000a0a] agpgart: Bridge couldn't do AGP x4. agpgart: Graphic card couldn't do AGP x4. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a08 tmp:ff00021b f ell back to:- cmd:1f000208 tmp:ff00021b] agpgart: Bridge couldn't do AGP x4. agpgart: Putting AGP V3 device at :00:00.0 into 0x mode agpgart: Putting AGP V3 device at :01:00.0 into 0x mode [drm] Loading R300 Microcode (last line) I have: Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT880 chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 128M @ 0xe000 I have Cc:ed davej. If he is in his normal mode (swamped by email), he'll read it really fast... ..with the 'd' key. :-) > Alternatively, it might be that these new chips need a new microcode, > the first thing to do would be to check BeOS drivers, this is one of the > public places where one can find R300 one. I checked the BeOS 5.1 driver. Don't think 9600XT is mentioned specificly, but the R300 ucode appears to cover anything [r|rv]3xx. > thank you for testing :) Thank you for coding! Dag B --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
On Mer, 2004-09-22 at 06:09, Eric Anholt wrote: > lines are GPLed of a file otherwise MIT-licensed). I was very bothered > by Jon's suggestion that a lot of the code could be GPLed by accident or > something, as if that license would have infected the entire DRM > (including shared bits) while nobody was looking. If someone feels that > there is GPLed code in there, it should be looked into and documented > immediately, or that vague stick should stop being waved. The GPL is intentionally very explicit about this situation "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " ["the Program" being the GPL code] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
Hi, On Wednesday 22 September 2004 00:45, Dag Bakke wrote: > If I load "dri" in my xorg.conf, the graphics gets wedged as soon > as I start X. I get more or less garbled stuff from the previous session. I > can move the cursor, but that's it. I can not exit from X with > ctrl-alt-backspace, or shift to the console with ctrl-alt-f1. I also tried > without radeonfb, just in case. I see no evidence of problems in the Xorg > log with dri, which I can review after rebooting via sysrq. Of course, if > the machine panicked, nothing got to the kernel log. And no, my wireless > keyboard does not have keyboard leds.. Whenever this has happened to me, it was caused by bad microcode. Check your syslog for a message "Loading Rx00 microcode", and make sure it says R300. If it does, then maybe this chip does need different microcode, as Vladimir said. cu, Nicolai pgpEXEqNbM9KJ.pgp Description: PGP signature
Re: DRM radeon i2c support and GPL
On Tue, 2004-09-21 at 02:48, Alan Cox wrote: > On Maw, 2004-09-21 at 08:58, Kean Johnston wrote: > > That's not a statement thats safe to make. BSD (or any other OS > > that XOrg supports) may not have Linux's I2C driver system. TODAY. > > What if, next week, BSD gets such a beast, or HP-UX does, or > > Well they can't use the low level Linux code anyway, because its GPL > licensed and likely to stay that way. Ugh. Of course that wouldn't happen. Not even implementing internal kernel interfaces, which is all that could apply for Kean's suggestion. > > If XOrg is trying to be "license agnostic", it is going to need > > to stay away from the GPL. The current MIT style license seems to > > be quite acceptable to GPL-centric projects. However, the reverse > > is not (always) true. > > Thats a shame. I guess its time to take DRI back out of the Xorg tree if > this kind of extremist view is the preferred one, or just keep the > kernel code in the Linux kernel and remove it from X.org ? I'll stick my two cents in here, as a BSD DRI maintainer. I don't think it matters if Linux-only DRM bits are GPLed, as long as they're clearly licensed appropriately (copyright header at the top, or describing which lines are GPLed of a file otherwise MIT-licensed). I was very bothered by Jon's suggestion that a lot of the code could be GPLed by accident or something, as if that license would have infected the entire DRM (including shared bits) while nobody was looking. If someone feels that there is GPLed code in there, it should be looked into and documented immediately, or that vague stick should stop being waved. IMO, X.Org should care about the DRM for its purposes as the kernel part of the DRI -- the 3d bits, not the i2c bits or whatever other linux bits, as long as X.Org and the DRI/DRM (drm/shared) remains portable to other platforms without depending on the GPLed bits, which I don't think is on the horizon at all. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
Hi Dag,
Try this: before starting X switch to another console and execute:
sleep 15 ; dmesg > dmesg.1 ; sync
Then start X, wait 30 seconds and shutdown your machine after that - this
will let you look at dmesg messages.
Also see below:
On Tue, 21 Sep 2004, Dag Bakke wrote:
I have tried the two patches for linux-2.6.9-rc2 and xorg-x11-6.8.0. A few
notes:
kernel patch:
Added my pci id to drm_pciids.txt, and got:
[drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc
RV350 AR [Radeon 9600]
Not sure if I should add the secondary pci id. The README doesn't say.
No, do not add secondary pci id. In fact, check that you added the primary
one: 4152
BTW: 2.6.9-rc2 shows a duplicate pci id in drm_pciids.h :
{0x1002, 0x4242, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x1002, 0x4242, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
# lspci
:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AR
[Radeon 9600]
:01:00.1 Display controller: ATI Technologies Inc RV350 AR [Radeon 9600]
(Secondary)
# lspci -n
:01:00.0 Class 0300: 1002:4152
:01:00.1 Class 0380: 1002:4172
But my card is an XT (rv360). I bought it as an XT. The print on the chip
says XT. And X agrees.
Ohh, these are just strings. I am not sure what XT means, but likely you
just got a faster clock speed - not enough change to warrant a different
pci id.
Xorg patch:
I added the patch on top of gentoo's 6.8.0-rc1. Gentoo do use a few patches
on top of vanilla Xorg...
Try starting bare X - say X, xterm and twm if you like it.
Also I suggest you try regular X.org. I got reports that this patch is
sensitive to other components - not sure why. If nothing helps, try
plain vanilla 6.7.0 with original 6.7.0 patch - you can configure
ProjectRoot to install in a directory different from /usr/X11 - just for
testing.
The first order of business is to make sure you can start X fine and
run simple programs like xterm or twm.
Alternatively, it might be that these new chips need a new microcode,
the first thing to do would be to check BeOS drivers, this is one of the
public places where one can find R300 one.
thank you for testing :)
Vladimir Dergachev
(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found
(--) Chipset ATI Radeon 9600XT AR (AGP) found
If I load "dri" in my xorg.conf, the graphics gets wedged as soon
as I start X. I get more or less garbled stuff from the previous session. I
can move the cursor, but that's it. I can not exit from X with
ctrl-alt-backspace, or shift to the console with ctrl-alt-f1. I also tried
without radeonfb, just in case. I see no evidence of problems in the Xorg
log with dri, which I can review after rebooting via sysrq. Of course, if
the machine panicked, nothing got to the kernel log. And no, my wireless
keyboard does not have keyboard leds..
I am currently without a secondary machine, so i am unable to (try to) log
in via the network to check the kernel log. Will do later this week.
I have attached a diff between Xlog with and without dri, in case it is of
any use to anyone.
dagb-home ~ # diff -u /var/log/Xorg.0.log /root/xlog.dri
--- /var/log/Xorg.0.log 2004-09-22 07:06:38.778552072 +0200
+++ /root/xlog.dri 2004-09-22 07:06:14.861188064 +0200
@@ -11,7 +11,7 @@
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 22 07:06:36
2004
+(==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 22 07:04:13
2004
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "configured by hand"
(**) |-->Screen "Screen 1" (0)
@@ -50,7 +50,7 @@
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
-(II) PCI: stages = 0x03, oldVal1 = 0x80008d48, mode1Res1 = 0x8000
+(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,0269 card 1043,8122 rev 80 class 06,00,00 hdr
80
(II) PCI: 00:00:1: chip 1106,1269 card 1043,8122 rev 00 class 06,00,00 hdr
00
@@ -338,6 +338,18 @@
(II) Module v4l: vendor="X.Org Foundation"
compiled for 6.8.0, module version = 0.0.1
ABI class: X.Org Video Driver, version 0.7
+(II) LoadModule: "dri"
+(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
+(II) Module dri: vendor="X.Org Foundation"
+ compiled for 6.8.0, module version = 1.0.0
+ ABI class: X.Org Server Extension, version 0.2
+(II) Loading sub module "drm"
+(II) LoadModule: "drm"
+(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
+(II) Module drm: vendor="X.Org Foundation"
+ compiled for 6.8.0, module version = 1.0.0
+ ABI class: X.Org Server Extension, version 0.2
+(II) Loading extension XFree86-DRI
(II) LoadMo
Re: Radeon M6 (r200) - [drm] drmAddMap failed
I appreciate the quick response! I just caught up with this e-mail chain and have not had a chance to try anything. My DRM is dated and broken among other things but it also looks like there's some vigorous activity on getting the DRI code patched as well. Let me know if I can assist in some way (testing maybe at this point) but it seems like you all took this and ran with it pretty well already. Jay On Mon, 2004-09-20 at 13:36, Jon Smirl wrote: Felix, I'm removing the size check from addmap with a permanent map. I've now encountered X asking for maps both smaller and larger that what the hardware allows. This is why we need to get this code out of X an into the driver. I'll fix the code to map the legal value for the hardware (from the permanent map) and return that info to X.
