[Bug 10802] gl-117 Segmentation Fault on 945g
http://bugs.freedesktop.org/show_bug.cgi?id=10802 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from [EMAIL PROTECTED] 2007-07-03 01:52 PST --- It's working now with the latest source. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10802] gl-117 Segmentation Fault on 945g
http://bugs.freedesktop.org/show_bug.cgi?id=10802 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fw: Re: [Mesa3d-users] i915tex prerequisites
On Mon, 2007-07-02 at 16:55 -0400, Russell Harmon wrote:
(II) intel(0): Unable to use TTM-based memory manager with DRM version 1.6
You need the i915 kernel module built from the drm GIT tree.
I tried building the module from the git tree, and got errors...
[EMAIL PROTECTED] ~/src/drm/src/linux-core $ make
make -C /lib/modules/2.6.21-kamikaze6/source SUBDIRS=`pwd`
DRMSRCDIR=`pwd` modules
make[1]: Entering directory `/usr/src/linux-2.6.21-kamikaze6'
CC [M] /home/russ/src/drm/src/linux-core/i915_irq.o
/home/russ/src/drm/src/linux-core/i915_irq.c: In function
'i915_driver_irq_postinstall':
/home/russ/src/drm/src/linux-core/i915_irq.c:722: error: expected
expression before '{' token
make[2]: *** [/home/russ/src/drm/src/linux-core/i915_irq.o] Error 1
make[1]: *** [_module_/home/russ/src/drm/src/linux-core] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.21-kamikaze6'
make: *** [modules] Error 2
I just pushed a change that might fix this.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm modesetting-101 i945GM, testing and questions
Hi Jesse 2- I cloned the git/drm tree using branch modesetting-101 Compilation was fine, intel_fb loads and the drm/framebuffer appears in /proc/fb but I have some troubles / remarks Yeah, (2) is the right thing to do. The patches are out of date. Ok thank you, I have checked out the last release yesterday to make some new tests Hm, so it just defaults to 640x480... you'd have to add some debugging code to the i2c code that fetches the EDID data to see what's going on. I may just be that the timing is off somewhere, just enough to prevent the kernel from receiving the EDID block. I haven't done it yet, but I'll try to do some debugging soon Second, when the mode 640x480 is set the screen does not display anything good. I only get some black screen which is sometime replace with coloured snow (I don't know how to explain it better...). If I try mplayer -vo fbdev(2), I'm only able to get a black screen So, here are my questions : - Are you still working on this drm/fb (modesetting) ? Yes, though I haven't checked anything in for a few weeks. I hope to be back on it shortly (have a few other features to get working first). Great to hear that ! - Is there a place where I can find a full procedure to make reliable tests ? - Are you interested in feedbacks ? (do you want me to make some specific tests, do you want access to my computer, ...) - ... Yes, definitely. It's great that there's interest in the tree, and we're interested in hearing about problems or different usage models for the code, but keep in mind that it's *very* bleeding edge, so when it breaks you get to keep both pieces. :) No problem about bleeding edge code. I know the difference between stable code and very experimental code ;-) Anyway, I tried the last release of the modsetting-101 branch yesterday night and I wasn't able to make it work : - I compiled the code (everything was fine) - I inserted the drm module Jul 2 21:10:56 coreduo [drm] Initialized drm 1.1.0 20060810 - I inserted the i915 module Jul 2 21:11:10 coreduo ACPI: PCI Interrupt :00:02.0[A] - GSI 16 (level, low) - IRQ 16 Jul 2 21:11:10 coreduo PCI: Setting latency timer of device :00:02.0 to 64 Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable to read EDID block. Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable to read EDID block. Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable to read EDID block. Jul 2 21:11:10 coreduo i915 :00:02.0: LVDS: no EDID data Jul 2 21:11:11 coreduo i2c_adapter i2c-3: sendbytes: error - bailout. Jul 2 21:11:11 coreduo i2c_adapter i2c-3: unable to read EDID block. Jul 2 21:11:11 coreduo i915 :00:02.0: TMDS-1: no EDID data Jul 2 21:11:11 coreduo allocated 640x480 fb: 0x0002, bo f611c6c0 Jul 2 21:11:11 coreduo fb0: intelfb frame buffer device Jul 2 21:11:11 coreduo [drm] Initialized i915 1.9.0 20070209 on minor 0 Driver insertion seems fine except I still got the EDID trouble (I'll try to do some debug) When the driver is loaded, I get a blue screen on my hdmi/Plasma TV set showing the message No signal (that was not the case with previous release) If I try to remove the module i915 from the kernel, I get a big error : Jul 2 21:11:24 coreduo ACPI: PCI interrupt for device :00:02.0 disabled Jul 2 21:11:24 coreduo BUG: unable to handle kernel paging request at virtual address f8d82080 Jul 2 21:11:24 coreduo printing eip: Jul 2 21:11:24 coreduo f8d0e8a3 Jul 2 21:11:24 coreduo *pde = 37853067 Jul 2 21:11:24 coreduo *pte = Jul 2 21:11:24 coreduo Oops: 0002 [#1] Jul 2 21:11:24 coreduo SMP Jul 2 21:11:24 coreduo Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device tun thermal processor fan eth1394 ftdi_sio usbserial lirc_igorplugusb(F) lirc_dev ves1820 ohci1394 dvb_ttpci dvb_core saa7146_vv video_buf saa7146 videodev v4l2_common v4l1_compat tt pci_eeprom ieee1394 rtc_cmos rtc_core rtc_lib evdev pcspkr ehci_hcd uhci_hcd usbcore snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_all oc Jul 2 21:11:24 coreduo CPU:1 Jul 2 21:11:24 coreduo EIP:0060:[f8d0e8a3]Tainted: GF VLI Jul 2 21:11:24 coreduo EFLAGS: 00010282 (2.6.21-gentoo-r3-coreduo-nofb #5) Jul 2 21:11:24 coreduo EIP is at i915_driver_unload+0x48/0x185 [i915] Jul 2 21:11:24 coreduo eax: f8d8 ebx: ef0b6800 ecx: c17ff080 edx: c16bb860 Jul 2 21:11:24 coreduo esi: f00a8000 edi: ef0b6800 ebp: f8d16604 esp: ef381eb8 Jul 2 21:11:24 coreduo ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Jul 2 21:11:24 coreduo Process rmmod (pid: 20192, ti=ef38 task=f7d5a030 task.ti=ef38) Jul 2 21:11:24 coreduo Stack: ef0b6944 ef0b6818 f8d165a8 f8d16604 ef0b6800 f8d165a8 f8d165a8 f8d241f0 Jul 2 21:11:24 coreduo f8d165a8 f8d165a8 f8d243e0 f7f97000 c02467d7 f7f97048 c02917bd f7f97048 Jul 2 21:11:24 coreduo f7f88200 c0291cca f8d16600 f8d165a8 f8d165a8 c0400b40 ef38 c02913d8 Jul
Patched drm_sg_alloc to be accessible from the DRM
Hello,
attached are patches that restructurate drm_sg_alloc, by splitting it into an
ioctl wrapper, and a
function that actually does the work. This way drm_sg_alloc can be called from
inside the DRM, and
this is something I want to have to implement PCI DMA in Nouveau.
Please forgive the mess with the 4 files, I am new to git..
--
Greetings,
A.H.
From d245d656fc7bbd4476f2c546ffdeda3d94f60459 Mon Sep 17 00:00:00 2001
From: Arthur Huillet [EMAIL PROTECTED]
Date: Tue, 3 Jul 2007 01:43:05 +0200
Subject: [PATCH] modified drm_sg_alloc to be callable from inside the DRM -
drm_sg_alloc_ioctl is the ioctl wrapper
---
linux-core/drmP.h|2 +-
linux-core/drm_drv.c |2 +-
linux-core/drm_scatter.c | 48 -
3 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index dd3a69d..5fda31e 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -1137,7 +1137,7 @@ extern int drm_proc_cleanup(int minor,
/* Scatter Gather Support (drm_scatter.h) */
extern void drm_sg_cleanup(drm_sg_mem_t * entry);
-extern int drm_sg_alloc(struct inode *inode, struct file *filp,
+extern int drm_sg_alloc_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_sg_free(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index d5eb971..dcc16af 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -113,7 +113,7 @@ static drm_ioctl_desc_t drm_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)] = {drm_agp_unbind_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY},
#endif
- [DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC)] = {drm_sg_alloc,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY},
+ [DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC)] = {drm_sg_alloc_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY},
[DRM_IOCTL_NR(DRM_IOCTL_SG_FREE)] = {drm_sg_free,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY},
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK)] = {drm_wait_vblank, 0},
diff --git a/linux-core/drm_scatter.c b/linux-core/drm_scatter.c
index e5c9f87..a87c7e8 100644
--- a/linux-core/drm_scatter.c
+++ b/linux-core/drm_scatter.c
@@ -62,14 +62,10 @@ void drm_sg_cleanup(drm_sg_mem_t * entry)
# define ScatterHandle(x) (unsigned int)(x)
#endif
-int drm_sg_alloc(struct inode *inode, struct file *filp,
-unsigned int cmd, unsigned long arg)
+int drm_sg_alloc(drm_file_t * priv, drm_scatter_gather_t * request)
{
- drm_file_t *priv = filp-private_data;
- drm_device_t *dev = priv-head-dev;
- drm_scatter_gather_t __user *argp = (void __user *)arg;
- drm_scatter_gather_t request;
drm_sg_mem_t *entry;
+ drm_device_t *dev = priv-head-dev;
unsigned long pages, i, j;
DRM_DEBUG(%s\n, __FUNCTION__);
@@ -80,17 +76,13 @@ int drm_sg_alloc(struct inode *inode, struct file *filp,
if (dev-sg)
return -EINVAL;
- if (copy_from_user(request, argp, sizeof(request)))
- return -EFAULT;
-
entry = drm_alloc(sizeof(*entry), DRM_MEM_SGLISTS);
if (!entry)
return -ENOMEM;
memset(entry, 0, sizeof(*entry));
-
- pages = (request.size + PAGE_SIZE - 1) / PAGE_SIZE;
- DRM_DEBUG(sg size=%ld pages=%ld\n, request.size, pages);
+ pages = (request-size + PAGE_SIZE - 1) / PAGE_SIZE;
+ DRM_DEBUG(sg size=%ld pages=%ld\n, request-size, pages);
entry-pages = pages;
entry-pagelist = drm_alloc(pages * sizeof(*entry-pagelist),
@@ -142,12 +134,7 @@ int drm_sg_alloc(struct inode *inode, struct file *filp,
SetPageReserved(entry-pagelist[j]);
}
- request.handle = entry-handle;
-
- if (copy_to_user(argp, request, sizeof(request))) {
- drm_sg_cleanup(entry);
- return -EFAULT;
- }
+ request-handle = entry-handle;
dev-sg = entry;
@@ -196,6 +183,31 @@ int drm_sg_alloc(struct inode *inode, struct file *filp,
failed:
drm_sg_cleanup(entry);
return -ENOMEM;
+
+}
+
+int drm_sg_alloc_ioctl(struct inode *inode, struct file *filp,
+unsigned int cmd, unsigned long arg)
+{
+ drm_file_t *priv = filp-private_data;
+ drm_scatter_gather_t __user *argp = (void __user *)arg;
+ drm_scatter_gather_t request;
+ int ret;
+
+ if (copy_from_user(request, argp, sizeof(request)))
+ return -EFAULT;
+
+ ret = drm_sg_alloc(priv, request);
+ if ( ret ) return ret;
+
+ if (copy_to_user(argp, request, sizeof(request))) {
+ drm_sg_cleanup(priv-head-dev-sg);
+ return -EFAULT;
+ }
+
+
+ return 0;
+
}
int drm_sg_free(struct inode *inode, struct file *filp,
--
1.5.1.4
From b77e93929c406e3c72f7b7aeab1394c3d8ae0495 Mon Sep
Re: drm modesetting-101 i945GM, testing and questions
On Tuesday, July 3, 2007 5:26:07 Philippe Gaultier wrote:
Anyway, I tried the last release of the modsetting-101 branch
yesterday night and I wasn't able to make it work :
- I compiled the code (everything was fine)
- I inserted the drm module
Jul 2 21:10:56 coreduo [drm] Initialized drm 1.1.0 20060810
- I inserted the i915 module
Jul 2 21:11:10 coreduo ACPI: PCI Interrupt :00:02.0[A] - GSI 16
(level, low) - IRQ 16
Jul 2 21:11:10 coreduo PCI: Setting latency timer of device
:00:02.0 to 64 Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable
to read EDID block. Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable
to read EDID block. Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable
to read EDID block. Jul 2 21:11:10 coreduo i915 :00:02.0: LVDS:
no EDID data Jul 2 21:11:11 coreduo i2c_adapter i2c-3: sendbytes:
error - bailout. Jul 2 21:11:11 coreduo i2c_adapter i2c-3: unable to
read EDID block. Jul 2 21:11:11 coreduo i915 :00:02.0: TMDS-1:
no EDID data Jul 2 21:11:11 coreduo allocated 640x480 fb:
0x0002, bo f611c6c0 Jul 2 21:11:11 coreduo fb0: intelfb frame
buffer device
Jul 2 21:11:11 coreduo [drm] Initialized i915 1.9.0 20070209 on
minor 0
Driver insertion seems fine except I still got the EDID trouble (I'll
try to do some debug)
When the driver is loaded, I get a blue screen on my hdmi/Plasma TV
set showing the message No signal (that was not the case with
previous release)
That could be because the monitor wasn't detected and the driver had
trouble programming a good mode.
Jul 2 21:11:24 coreduo Call Trace:
Jul 2 21:11:24 coreduo [f8d241f0] drm_cleanup+0x7a/0x19b [drm]
Jul 2 21:11:24 coreduo [f8d243e0] drm_cleanup_pci+0x16/0x24 [drm]
Jul 2 21:11:24 coreduo [c02467d7] pci_device_remove+0x16/0x36
Jul 2 21:11:24 coreduo [c02917bd]
__device_release_driver+0x64/0x8d Jul 2 21:11:24 coreduo
[c0291cca] driver_detach+0xc3/0xc9 Jul 2 21:11:24 coreduo
[c02913d8] bus_remove_driver+0x63/0x81 Jul 2 21:11:24 coreduo
[c0291cf1] driver_unregister+0x8/0x1d Jul 2 21:11:24 coreduo
[c0246931] pci_unregister_driver+0xe/0x67 Jul 2 21:11:24 coreduo
[f8d243c8] drm_exit+0xb7/0xb9 [drm] Jul 2 21:11:24 coreduo
[c01367cb] sys_delete_module+0x138/0x19a Jul 2 21:11:24 coreduo
[c01493f5] remove_vma+0x36/0x3b
Jul 2 21:11:24 coreduo [c0149e3f] do_munmap+0x16e/0x1c3
Jul 2 21:11:24 coreduo [c0102702] sysenter_past_esp+0x5f/0x85
Jul 2 21:11:24 coreduo [c035] xfrm_state_add+0x13/0x1d0
I know there are some issues with module removal unless you have a
kernel with some additional fb patches (something like the attached,
which has been superceded by a better patch by Antonio).
If I do a shutdown -r now, the whole system seems to freeze (I'm
ssh'ing it because I dont have anything displayed on the console
since I inserted the i915 module)
Here is the log (after the shutdown -r now)
Jul 2 21:12:04 coreduo shutdown[1642]: shutting down for system
reboot Jul 2 21:12:04 coreduo init: Switching to runlevel: 6
I cannot get more information... from the system logs
Yeah, after a bug like the above, the kernel might have trouble doing
much else.
So here are some questions :
1. If I compile the source code, do I need to install libdrm.so/la
before doing the insmod
No, that's just the userspace library. You'll need it if you want to
use drm* calls for modesetting in your application, but it's not
strictly needed for the kernel stuff to work.
2. Is there a way to force the driver to keep the display on TMDS-1
?
It'll try to probe all available outputs, so if everything goes well,
TMDS-1 will be setup correctly. Using the modesetting ioctls, you can
control whether TMDS-1 is cloned, an extension of another output or has
its own CRTC.
Jesse
--- linux-2.6.21-rc4/drivers/video/fbmem.c 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/drivers/video/fbmem.c 2007-04-26 18:16:52.0 -0700
@@ -1349,6 +1349,8 @@
if (!registered_fb[i])
return -EINVAL;
+ event.info = fb_info;
+ fb_notifier_call_chain(FB_EVENT_FB_UNBIND, event);
if (fb_info-pixmap.addr
(fb_info-pixmap.flags FB_PIXMAP_DEFAULT))
kfree(fb_info-pixmap.addr);
--- linux-2.6.21-rc4/include/linux/fb.h 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/include/linux/fb.h 2007-04-26 17:33:07.0 -0700
@@ -525,6 +525,8 @@
#define FB_EVENT_MODE_CHANGE_ALL 0x0B
/* A software display blank change occured */
#define FB_EVENT_CONBLANK 0x0C
+/* Unbind from the console if possible */
+#define FB_EVENT_FB_UNBIND 0x0E
struct fb_event {
struct fb_info *info;
--- linux-2.6.21-rc4/include/linux/console.h 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/include/linux/console.h 2007-04-26 17:56:31.0 -0700
@@ -64,6 +64,7 @@
extern const struct consw newport_con; /* SGI Newport console */
extern const struct consw prom_con; /* SPARC PROM console */
+int
Re: Fw: Re: [Mesa3d-users] i915tex prerequisites
(II) intel(0): Unable to use TTM-based memory manager with DRM version 1.6
You need the i915 kernel module built from the drm GIT tree.
I tried building the module from the git tree, and got errors...
[EMAIL PROTECTED] ~/src/drm/src/linux-core $ make
make -C /lib/modules/2.6.21-kamikaze6/source SUBDIRS=`pwd`
DRMSRCDIR=`pwd` modules
make[1]: Entering directory `/usr/src/linux-2.6.21-kamikaze6'
CC [M] /home/russ/src/drm/src/linux-core/i915_irq.o
/home/russ/src/drm/src/linux-core/i915_irq.c: In function
'i915_driver_irq_postinstall':
/home/russ/src/drm/src/linux-core/i915_irq.c:722: error: expected
expression before '{' token
make[2]: *** [/home/russ/src/drm/src/linux-core/i915_irq.o] Error 1
make[1]: *** [_module_/home/russ/src/drm/src/linux-core] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.21-kamikaze6'
make: *** [modules] Error 2
I just pushed a change that might fix this.
Yep, that fixed it... thx
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11101] Running SPECViewPerf9.0 may crash X sometime.
http://bugs.freedesktop.org/show_bug.cgi?id=11101 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #10372|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11101] Running SPECViewPerf9.0 may crash X sometime.
http://bugs.freedesktop.org/show_bug.cgi?id=11101 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #7 from [EMAIL PROTECTED] 2007-07-03 15:26 PST --- Again, the log you posted appears to be from a freshly-started X Server. I've run SpecViewPerf past the bit of the log in comment #1 just fine. SPECViewPerf (like many testing apps other than xtest) does get confused if you run on a bare X Server like in comment #1. Run some app like xlogo to prevent server regens. So, is there an actual server crash involved? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11384] r300: (RS480) Some OpenGL applications have strange rendering characteristics
http://bugs.freedesktop.org/show_bug.cgi?id=11384 --- Comment #14 from [EMAIL PROTECTED] 2007-07-03 15:51 PST --- (In reply to comment #5) Ok. I tried the latest mesa+drm+xserver, and things are light years better. Many of the apps that failed before, now work. (most of the rss-glx-0.8.1.p-6.fc6 screensavers work, neverball works, neverputt works, nexuiz works) Most of the rss stuff works for me as well. Neverball is still broken, haven't tried neverputt, haven't tried nexuiz in months (though only tried it once on this machine with fglrx and remember it being _way_ too much for it to handle) mesa/progs/samples/wave: (The checkerboard pattern doesn't show up.) However, if you press 'l' (to disable lighting), the checkerboard pattern shows up. Ditto mesa/progs/samples/fog: The end of the cone is red with fglrx, but not with mesa. glMaterialfv(GL_BACK, GL_DIFFUSE, back_mat_diffuse); Ditto mesa/progs/samples/fogcoord: This appears as a brown square. (It also has some complaints about not supporting 'GL_EXT_fog_coord') Don't have this in my tree for some reason (updated today Jul 3) From rss-glx-0.8.1.p-6.fc6: /usr/bin/busyspheres A single sphere is visible in the lower left handcorner. (no cool pattern..) This works perfectly on mine, on the other hand The demo of Descent 3 in portage seems to work perfectly fine as well, provided the resolution is set to 640x480; nothing lower, nothing higher (else it exhibits some still different problems like seeing through walls) and with great framerate. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
