[Dri-devel] moving i810 to texmem, testing...
i might be able to get time to move the i810 to texmem soon, firstly as Keith has let me know, I need to move the i810 to using its own texture formats (it's still stuck back in the mesa3.4 days)... so is there a set of comphrensive tests that I can run before and after to make sure that I haven't messed things up too badly... some sort of texture mapping tester... that covers most of the cases... thanks, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 07:21 --- Thank you Hui for doing this, The kernel patch does not apply cleanly to vanilla 2.4.18 neither 2.4.19. I applied it by hand against 2.4.18(*) whitch is the most close with your patch. The patch against xfree-cvs does not applied cleanly too (obviously as it's against a cvs version) against cvs of yesterday (2003-07-21), so I applied it by hand too. Now the kernel during boot gives me this nice info :) : Jul 22 02:35:51 matrix kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Jul 22 02:35:51 matrix kernel: agpgart: Maximum main memory to use for agp memory: 409M Jul 22 02:35:51 matrix kernel: agpgart: Detected ATI IGP330/340/345/350/M chipset Jul 22 02:35:51 matrix kernel: agpgart: AGP aperture is 64M @ 0xf400 Jul 22 02:35:51 matrix kernel: [drm] AGP 0.99 on Unknown @ 0xf400 64MB Jul 22 02:35:51 matrix kernel: [drm] Initialized radeon 1.1.1 20010405 on minor 0 But unfortunately after compiling xfree with the patch too, when starting X I get an kernel oops: Jul 22 02:36:17 matrix modprobe: modprobe: Can't locate module char-major-10-134 Jul 22 02:36:22 matrix modprobe: modprobe: Can't locate module char-major-81 Jul 22 02:36:22 matrix kernel: [drm:radeon_do_init_cp] *ERROR* could not find framebuffer! Jul 22 02:36:22 matrix kernel: Unable to handle kernel NULL pointer dereference at virtual address 0010 Jul 22 02:36:22 matrix kernel: printing eip: Jul 22 02:36:22 matrix kernel: c01c72e7 Jul 22 02:36:22 matrix kernel: *pde = 1b721067 Jul 22 02:36:22 matrix kernel: *pte = Jul 22 02:36:22 matrix kernel: Oops: Jul 22 02:36:22 matrix kernel: CPU:0 Jul 22 02:36:22 matrix kernel: EIP:0010:[radeon_do_cleanup_cp+55/320] Not tainted Jul 22 02:36:22 matrix kernel: EIP:0010:[c01c72e7]Not tainted Jul 22 02:36:22 matrix kernel: EFLAGS: 00013246 Jul 22 02:36:22 matrix kernel: eax: ebx: dd588180 ecx: edx: Jul 22 02:36:22 matrix kernel: esi: c1757800 edi: dc1b7f08 ebp: c1757800 esp: dc1b7eb8 Jul 22 02:36:22 matrix kernel: ds: 0018 es: 0018 ss: 0018 Jul 22 02:36:22 matrix kernel: Process X (pid: 1071, stackpage=dc1b7000) Jul 22 02:36:22 matrix kernel: Stack: c01c38b0 c170f388 dc61db80 dc61db80 dd588180 c01c6af6 c1757800 Jul 22 02:36:22 matrix kernel:00c4 0138 dc1b7f04 dc61dc40 dc1b7f08 c1757800 dcfb4c80 dc292400 Jul 22 02:36:22 matrix kernel:c01c7466 c1757800 dc1b7f08 0054 0001 0898 4000 Jul 22 02:36:22 matrix kernel: Call Trace: [radeon_alloc+80/128] [radeon_do_init_cp+134/2112] [radeon_cp_init+118/128] [rade on_ioctl+205/304] [sys_ioctl+185/448] Jul 22 02:36:22 matrix kernel: Call Trace: [c01c38b0] [c01c6af6] [c01c7466] [c01c1e0d] [c0143e39] Jul 22 02:36:22 matrix kernel:[system_call+51/56] Jul 22 02:36:22 matrix kernel:[c0107337] Jul 22 02:36:22 matrix kernel: Jul 22 02:36:22 matrix kernel: Code: 8b 50 10 85 d2 74 0b 8b 40 04 85 c0 0f 85 8a 00 00 00 8b 83 Maybe I've forgotten to include something in the kernel build? I have the framebuffer compiled in the kernel (not modular), the selected driver is radeon, but the same happens with vesafb too. But FWIK the kernel's framebuffer driver is not used by xfree so I can not understand this oops. Any sugestions welkomed. BTW, as for your comments about the patch working in agp4 only I added this in my XF86Config-4 (Including all the Device section for completeness): Section Device Identifier device1 VendorName ATI Technologies Inc BoardName ATI Radeon Driver radeon Option DPMS Option AGPMode 4- This is what I added EndSection I tried agptool too and here's the output with your patch: agptool by Dave Jones. [EMAIL PROTECTED] Found AGP host bridge. 1002:cab2 :-1002:cab2 Host capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but AGP transfers are currently disabled. Found AGP graphics card. 1002:4337 :-1002:4337 Card capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but AGP transfers are currently disabled. System is capable of doing x4 AGP. rate before: f000217 setting rate to f000214 Here's the output without your patch: agptool by Dave Jones. [EMAIL PROTECTED] Found AGP host bridge. 1002:cab2 :-1002:cab2 Host capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but is not initialised. Found AGP graphics card. 1002:4337 :-1002:4337 Card capabilities: Compliant with version 2.0 of the AGP standard. It is capable of doing x4 AGP, but is not initialised. System is capable of doing x4 AGP. Couldn't open /dev/agpgart (*) I tried the kernel patch to apply to vanilla 2.4.22-pre7 too but from kernel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 09:04 --- Hi Hui, I also tried your patches, but with different success. The kernel patch worked ok for me (vanilla 2.4.18, nu patch problems). AGP and DRM initialize fine. When I run the patched CVS X (4.3.99.8) it hardlocks on 2.4.18. I got it to load only once. When I checked the logfiles, there were some DRI/DRM error messages like '[drm] cannot open /dev/dri/card0: Device or resource busy' and '[dri] - driCreateScreen failed'. Or something like that. I haven't been able to reproduce the logs, because right now the whole thing hardlocks the system. The problem seems to be in the X build, because testgart and agptool work fine. Agptool output and XFree86 settings are exactly identical to Frederik Nosi's (see posting above). So I tried porting the agpgart driver to 2.5.73, which was pretty easy. Again no problems with testgart and agptool, and X starts without crashing. Sadly, still no direct rendering. The logfiles only said '[W] agp: AGP disabled' . Maybe this is because of a version check or something? Anyways I would like to keep testing new patches, especially with the driver ported to 2.5. Do you have an indication when your XFree patch is going to be merged into XFree-CVS? Wouter -- Configure bugmail: http://bugs.xfree86.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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 10:03 --- Thanks for testing. One thing I can think of about the error you got is that you might have loaded the original radeon dri module come with the Linux kernel source. This module is not patched and should not be used. You should use the patched one inside XFree86 source tree (either replace radeon.o in your default module path or insert the patched one manually). The kernel agpgart patch is built on the kernel source from a retail CD (just something handy on my system), it shouldn't be difficult to apply it manually as you did. The XFree radeon driver in CVS has been changed these two days, if you want the patch to be applied cleanly you can get the original version with xf-4_3_99_8 tag. -- Configure bugmail: http://bugs.xfree86.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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 10:22 --- Thanks for testing. Thank you for your work Hui, One thing I can think of about the error you got is that you might have loaded the original radeon dri module come with the Linux kernel source. This module is not patched and should not be used. Stupid me (good news for the patch :) ), I compiled (statically) the drm module of the kernel. Maybe I should not test things in 2:00 of the morning. You should use the patched one inside XFree86 source tree (either replace radeon.o in your default module path or insert the patched one manually). Sure, expect my reports tomorrow as from now I'll be offline. About the patches, it was trivial applying by hand them, so no problem, it was just to inform you. I wonder how happened to Wouter to apply cleanly, just now I downloaded the 2.4.18 vanilla and I get rejects ;) I forgot to run the Oops through ksymoops, here is the output just in case: EIP; c01c72e7 radeon_do_cleanup_cp+37/140 = Trace; c01c38b0 radeon_alloc+50/80 Trace; c01c6af6 radeon_do_init_cp+86/840 Trace; c01c7466 radeon_cp_init+76/80 Trace; c01c1e0d radeon_ioctl+cd/130 Trace; c0143e39 sys_ioctl+b9/1c0 Trace; c0107337 system_call+33/38 Code; c01c72e7 radeon_do_cleanup_cp+37/140 _EIP: Code; c01c72e7 radeon_do_cleanup_cp+37/140 = 0: 8b 50 10 mov0x10(%eax),%edx = Code; c01c72ea radeon_do_cleanup_cp+3a/140 3: 85 d2 test %edx,%edx Code; c01c72ec radeon_do_cleanup_cp+3c/140 5: 74 0b je 12 _EIP+0x12 Code; c01c72ee radeon_do_cleanup_cp+3e/140 7: 8b 40 04 mov0x4(%eax),%eax Code; c01c72f1 radeon_do_cleanup_cp+41/140 a: 85 c0 test %eax,%eax Code; c01c72f3 radeon_do_cleanup_cp+43/140 c: 0f 85 8a 00 00 00 jne9c _EIP+0x9c Code; c01c72f9 radeon_do_cleanup_cp+49/140 12: 8b 83 00 00 00 00 mov0x0(%ebx),%eax Bye, Fredi -- Configure bugmail: http://bugs.xfree86.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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 10:32 --- Hi Wouter, my previous message is the reply to Frederik Nosi (you got in before I sent). You may have the same problem as Frederik -- loaded the original radeon DRI kernel module (radeon.o) from the Linux kernel tree. Make sure you used the patched one in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ As for when the patch is going to be merged into XFree-CVS, it probably won't until it's merged into DRI project first and tested there. I used the XFree CVS code because that's somethng handy on my system. -- Configure bugmail: http://bugs.xfree86.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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 11:44 --- The correct thing to do then would be to bump the DRM minor version and only attempt to initialize the DRI on IGP chips if the DRM has high enough a minor version. -- Configure bugmail: http://bugs.xfree86.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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problems with dri-trunk on Tibook IV
On Tue, 2003-07-22 at 07:06, Leigh Dyer wrote:
I've just been lucky enough to get a 1Ghz Powerbook G4 with 64Mb Radeon
Mobility 9000 to work on,
Great machine, isn't it? :)
and I've been having a little trouble getting X and DRI working
nicely. The process so far has been:
1. Installed debian sid (following the branden's ibook page)
2. Installed Daniel Stone's XFree86 4.3.0 packages
3. Built and installed 2.4.21-ben2 kernel from source
4. Built and installed DRI trunk from CVS
BTW, are you not using my dri-trunk-sid packages intentionally?
[drm] AGP 0.99 aperture @ 0x 16MB
[drm] Initialized radeon 1.9.0 20020828 on minor 0
__ioremap(): phys addr 0 is RAM lr c0011be8
__ioremap(): phys addr 101000 is RAM lr c0011be8
__ioremap(): phys addr 102000 is RAM lr c0011be8
[drm:radeon_do_init_cp] *ERROR* could not find ioremap agp regions!
Your kernel lacks a vmap() implementation taking four arguments, which
the DRM requires for using agpgart with AGP bridges that don't provide
direct CPU access to the AGP aperture. The attached vmap-2.4.diff is
what I'm using for this; alternatively, you can try merging
http://penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff to the current
DRM.
Anyway, you exposed a couple of bugs:
* RADEONDRIFinishScreenInit() fails, so the DRI gets disabled, but
XAA has already been set up to use the CP for 2D acceleration.
This causes the CP errors you're seeing. The attached
radeon-accel-init.diff moves the RADEONAccelInit() call after
the RADEONDRIFinishScreenInit() call.
* AGP initialization in the DRM should really fail as early as
possible in this case, such that the DRI may be enabled using
PCI GART. The attached drm-agp-acquire.diff tries to achieve
this.
So, please try only the first patch first and verify that the X server
works correctly (the DRI will be disabled). Then, try the second patch
and verify that the DRI is enabled, but AGP is disabled.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.57
diff -p -u -r1.57 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 25 Mar 2003 11:19:52 - 1.57
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 22 Jul 2003 15:38:03 -
@@ -3969,29 +4525,6 @@ Bool RADEONScreenInit(int scrnIndex, Scr
}
}
-/* Acceleration setup */
-if (!xf86ReturnOptValBool(info-Options, OPTION_NOACCEL, FALSE)) {
- if (RADEONAccelInit(pScreen)) {
- xf86DrvMsg(scrnIndex, X_INFO, Acceleration enabled\n);
- info-accelOn = TRUE;
-
- /* FIXME: Figure out why this was added because it shouldn't be! */
- /* This is needed by the DRI and XAA code for shared entities */
- pScrn-pScreen = pScreen;
- } else {
- xf86DrvMsg(scrnIndex, X_ERROR,
- Acceleration initialization failed\n);
- xf86DrvMsg(scrnIndex, X_INFO, Acceleration disabled\n);
- info-accelOn = FALSE;
- }
-} else {
- xf86DrvMsg(scrnIndex, X_INFO, Acceleration disabled\n);
- info-accelOn = FALSE;
-}
-
-/* DGA setup */
-RADEONDGAInit(pScreen);
-
/* Backing store setup */
miInitializeBackingStore(pScreen);
xf86SetBackingStore(pScreen);
@@ -4042,8 +4575,6 @@ Bool RADEONScreenInit(int scrnIndex, Scr
xf86DPMSInit(pScreen, RADEONDisplayPowerManagementSet, 0);
#endif
-RADEONInitVideo(pScreen);
-
/* Provide SaveScreen */
pScreen-SaveScreen = RADEONSaveScreen;
@@ -4068,8 +4599,33 @@ Bool RADEONScreenInit(int scrnIndex, Scr
} else {
xf86DrvMsg(pScrn-scrnIndex, X_INFO, Direct rendering disabled\n);
}
#endif
+/* Acceleration setup */
+if (!xf86ReturnOptValBool(info-Options, OPTION_NOACCEL, FALSE)) {
+ if (RADEONAccelInit(pScreen)) {
+ xf86DrvMsg(scrnIndex, X_INFO, Acceleration enabled\n);
+ info-accelOn = TRUE;
+
+ /* This is needed by the XAA code for shared entities */
+ pScrn-pScreen = pScreen;
+ } else {
+ xf86DrvMsg(scrnIndex, X_ERROR,
+ Acceleration initialization failed\n);
+ xf86DrvMsg(scrnIndex, X_INFO, Acceleration disabled\n);
+ info-accelOn = FALSE;
+ }
+} else {
+ xf86DrvMsg(scrnIndex, X_INFO, Acceleration disabled\n);
+ info-accelOn = FALSE;
+}
+
+/* DGA setup */
+RADEONDGAInit(pScreen);
+
+/* XVideo setup */
+RADEONInitVideo(pScreen);
+
info-BlockHandler = pScreen-BlockHandler;
pScreen-BlockHandler = RADEONBlockHandler;
Index: programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_agpsupport.h
===
RCS file:
Memory layout, was: Re: [Dri-devel] [Bug 314] No 3D support for RadeonIGP chips
I don't think we can get away with breaking older clients, though this does look like it would only break the situation where you have old 3d client with new 2d driver, which is a slightly unusual situation. The real question is how much does the 3d client actually rely on the radeon memory layout? It gets pointers to most things it cares about in the initialization messages, these could be adjusted to point to the correct places in the new layout. Further, if a client is known to be old, the kernel can go through its commands adjust them for the new layout (assuming we can't dupe the client into using the right values for itself). I'd prefer this approach (in addition to the turn-on ioctl) to anything that involves bumping the major version. Keith --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 17:39 --- This could become a backwards compatibility nightmare, as the framebuffer aperture is currently hardcoded everywhere to be at 0. :\ At the very least, the DRM minor version must be bumped, new entries must only be added at the end of structs used for communication between components, and each component must be careful only to use them if they are known to contain valid values. However, as a different memory layout is desirable for other reasons like video capturing, we should make another attempt at a discussion to get it right once and for all, probably on dri-devel but at least including people like Ben Herrenschmidt and Vladimir Dergachev as well. Here's an idea for a scheme to preserve at least some level of backwards compatibility: Add a new ioctl for the X server to tell the DRM 'I want to use the new memory layout'. Unless this is called, everything keeps working as it is now (i.e. things like DRI on IGP chips or video capturing won't work). Otherwise, the DRM bumps its major version as well. The 3D driver is adapted to cope with both major DRM versions. This would provide backwards compatibility for the new 3D driver with old X servers / DRMs / hardware. Old 3D drivers would stop working with the combination of new X server and new DRM, but this might be as good as it gets in terms of backwards compatibility. Or maybe someone else has a better idea? --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Memory layout, was: Re: [Dri-devel] [Bug 314] No 3D supportfor Radeon IGP chips
On Tue, 2003-07-22 at 23:53, Keith Whitwell wrote: I don't think we can get away with breaking older clients, though this does look like it would only break the situation where you have old 3d client with new 2d driver, which is a slightly unusual situation. Yes, I think the 2D driver and in particular the DRM are much more likely to be old. The real question is how much does the 3d client actually rely on the radeon memory layout? It gets pointers to most things it cares about in the initialization messages, these could be adjusted to point to the correct places in the new layout. I'm afraid this doesn't work, e.g. - rmesa-hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = rmesa-state.color.drawOffset; + rmesa-hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = rmesa-state.color.drawOffset+rmesa-radeonScreen-fbBase; and rmesa-state.color.drawOffset = rmesa-radeonScreen-frontOffset; but rmesa-state.color.drawOffset probably needs to stay the same for software rendering? (it seems to be used as an offset into the framebuffer mapping) Further, if a client is known to be old, the kernel can go through its commands adjust them for the new layout This might actually work, nifty. :) I wonder how much effort this would take and/or whether it would have an impact on performance though. I'd prefer this approach (in addition to the turn-on ioctl) to anything that involves bumping the major version. Well, if this works, we might actually get away without bumping the major, which would be great... let's hope this works out taking into consideration everything including video capturing, radeonfb, ... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI only works as root ( mode 0666 in XF86Config )
Hi. I have a Radeon: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA]) Subsystem: Palit Microsystems Inc.: Unknown device 5159 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at d800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at d800 [size=256] Region 2: Memory at d700 (32-bit, non-prefetchable) [size=64K] Expansion ROM at d7fe [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- I'm using XFree86-4.3.0 compiled with the latest Gentoo ebuild. Everything works fine at home ( with my Radeon 64MB DDR VIVO ), but here at work DRI only works as root. As a normal user, glxinfo gives me: name of display: :0.0 libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect rendering display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow I have the following at the end of my /etc/X11/XF86Config: Section DRI Mode0666 EndSection The permission for /dev/dri is: [EMAIL PROTECTED] dan # ls -l /dev/dri total 0 crw-rw-rw-1 root root 226, 0 2003-07-23 08:14 card0 [EMAIL PROTECTED] dan # 'dmesg' shows this when X starts: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 203M agpgart: Detected Via Apollo Pro KT133 chipset agpgart: AGP aperture is 32M @ 0xe600 [drm] AGP 0.99 aperture @ 0xe600 32MB [drm] Initialized radeon 1.9.0 20020828 on minor 0 And just for completeness, here's my /var/log/XFree86.0.log: XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20 i686 [ELF] Build Date: 20 June 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not
Re: [Dri-devel] DRI only works as root ( mode 0666 in XF86Config )
On Wed, 2003-07-23 at 00:42, Daniel Kasak wrote: I'm using XFree86-4.3.0 compiled with the latest Gentoo ebuild. Everything works fine at home ( with my Radeon 64MB DDR VIVO ), but here at work DRI only works as root. As a normal user, glxinfo gives me: name of display: :0.0 libGL error: failed to open DRM: Operation not permitted [...] [EMAIL PROTECTED] dan # ls -l /dev/dri total 0 crw-rw-rw-1 root root 226, 0 2003-07-23 08:14 card0 (BTW, I hope you're aware that mode 660 and a dedicated group would be preferable from a security standpoint) Weird... were the DRM and radeon_dri.so built with the same or at least a similar compiler? If so, do LIBGL_DEBUG=verbose glxinfo or strace glxinfo provide more information? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI only works as root ( mode 0666 in XF86Config)
Michel Dänzer wrote: On Wed, 2003-07-23 at 00:42, Daniel Kasak wrote: I'm using XFree86-4.3.0 compiled with the latest Gentoo ebuild. Everything works fine at home ( with my Radeon 64MB DDR VIVO ), but here at work DRI only works as root. As a normal user, glxinfo gives me: name of display: :0.0 libGL error: failed to open DRM: Operation not permitted [...] [EMAIL PROTECTED] dan # ls -l /dev/dri total 0 crw-rw-rw-1 root root 226, 0 2003-07-23 08:14 card0 (BTW, I hope you're aware that mode 660 and a dedicated group would be preferable from a security standpoint) Weird... were the DRM and radeon_dri.so built with the same or at least a similar compiler? If so, do LIBGL_DEBUG=verbose glxinfo or strace glxinfo provide more information? Thanks for the quick reply. After looking at the output from `LIBGL_DEBUG=verbose glxinfo` and sniffing around the place I noticed that I ( as a normal user ) didn't have permission to cd into the /dev/dri directory. I did a 'chmod 755 /dev/dri' and now everything works. Yeah I know things could be more secure. But I'm the only user here who has a clue about Linux, and we're behind a firewall, and ... well ... I'm just happy that DRI is now working :) Thanks again for the help! Dan -- Daniel Kasak IT Developer * NUS Consulting Group* Level 18, 168 Walker Street North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: www.nusconsulting.com --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i810 texture upload patch
http://www.skynet.ie/~airlied/patches/dri/i810_tex_upload.diff I used the texenv demos from Mesa 5.0 to test this, I tested it with the old driver and this one, and they both look the same.. however neither of them show the intensity row like my Nvidia card on my main desktop .. on the i810 I just get four boxes of differing greys, like the lumiance one (slightly different greys), but on the NVidia it is more like the Alpha row... if no issues I'll commit this, and move onto texmem proper.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] No 3D support for Radeon IGP chips
http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 22:49 --- The patch doesn't really break any existing code. You can apply the patch and all supported cards should still work (if not, it's a bug). I've tested a 7500 breifly with the patch applied, everything worked properly. All it changes is a fb_offset added when sending a fb location related packet (like ColorOffset, DepthOffset, TxOffset). For all regular cards this fb_offset is set to zero and FB_LOCATION is not changed. I haven't tried any video capture thing though, but don't think there will be a big compatibity issue. All existing IGP boards only have TV-out, no video-in feature. -- Configure bugmail: http://bugs.xfree86.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: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
