Re: Small issue in the ati/radeon dga driver
On Sat, 2005-01-15 at 12:12 +, James Wright wrote: Not sure if this is the right place to report this but anyway; xc/programs/XServer/hw/xfree86/drivers/ati/radeon_dga.c Line 114: currentMode-imageHeight= (info-FbMapSize / currentMode-bytesPerScanline); On my Radeon IGP chipset with 64MB of VideoRam, this value is calculated as 65536 (0x01). Although here the variable is a 32 bit integer, later in the dga library this value is truncated to a 16 bit integer, causing the driver to report the imageHeight as zero. I added a single line beneath Line 144 to clamp the value to the max a 16 bit iteger can hold; if (currentMode-imageHeight 0x) currentMode-imageHeight = 0x; This fixes the problem for my radeon, but I think the other ati drivers may suffer from the same problem, but I do not have the hardware to test. Note that the Radeon 2D engine only supports signed 14 bit coordinates. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DGA and tearing effects
On Sat, 2004-11-27 at 16:40 +, James Wright wrote: About a year ago I was using DGA for my games graphics library. I was told by various people that using DGA was not the way to go. At first I thought this was nonsense, as you can't get vsync using the more standard XPutImage method (and get tearing). However, all changed when I bought a laptop with TFT screen. Problem is, there is no vsync on the new LCD/TFT monitors! There is in my experience, at least if you use the panel's native mode. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: G4 AGP
On Thu, 2004-09-30 at 08:21 -0400, F. Heitkamp wrote: On Wed, 29 Sep 2004, Ian Romanick wrote: F. Heitkamp wrote: I can't get agp to work with my Apple G4. When I enable DRI X comes up but the resolution appears to be 640x480 and the mouse cursor is large, distorted and quivering. No user input is possible at this point. Is AGP support for the G4 still under development or is it supposed to work? I have a Radeon 9000. AFAIK, AGP is supported on all G4 based Macs. All of that should work fine even without AGP support. Does it work correctly with DRI disabled? Yes. It works fine. What kernel are you running? AGP on Macs only works out of the box with 2.6 kernels, for 2.4 you still need a DRM hack like http://penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff . -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
On Thu, 2004-09-16 at 19:49 +0200, Martin MOKREJ wrote: Dr Andrew C Aitchison wrote: On Thu, 16 Sep 2004, [ISO-8859-2] Martin MOKREJ wrote: Martin MOKREJ wrote: Actually, I didn't know earlier but the radeon should not continue but make X rather die as I have AGP 9200 card, and that's actually the reason why I have to use ati as driver. The naming is bad, but empirically I have figured out which drier works and aslo gives DRI. The credit goes to Philipp Klaus Krause from dri-users list: radeon is the driver for the Radeon 7000 series cards. ati is the one for Radeon 8500 to 9200. Last time I looked, ati was a wrapper driver which used one of the drivers mach64, r128 or radeon as appropriate, and radeon was appropriate for all Radeon cards. Has someone been playing around ? Or have you got different versions of the ati and radeon drivers ? No, but simply if user is stupid and types according to docs saying something like put on the Driver relevant driver for your card, like vesa, one usually knows ... I have Radeon 9200, OK, let's use radeon as it seems it does exist. So, when I used radeon directly, it caused by system to lockup, LCD display complaining it is out of sync. I propose to modify radeon driver in a way it would refuse to start on cards other than 7000 series. No, as Andrew says, the radeon driver basically supports any Radeon card to date. ati and radeon should behave exactly the same on any Radeon card, otherwise that's a bug in either of them. There is also the drver from ATI, I've forgotten what that is called. fglrx, FWIW. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: x(dm) freezes at first start
On Sat, 2004-09-11 at 14:21 +0200, Jonas Meurer wrote: at boot, when xdm is started, x freezes directly after the login screen is displayed. sometimes it's possible to type in the login name, but at the latest at typing the password, the complete screen freezes. i'm still able to kill x with magic sysrq key combination: alt+sysrq+k strg+alt+backspace and changing the console screen don't work any longer. as already said, this happens _only_ at the first start of xdm, in the boot process. if i stop and afterwards start xdm, it _never_ freezes. FWIW, I used to see something similar with gdm and kdm a while back, and it was a VT allocation race between the X server and the gettys. IIRC the X server would attach to VT 2 but display on VT 7, so it would never get the input. AFAIR the mouse cursor worked though, is that the case for you? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
On Fri, 2004-08-27 at 09:14 -0700, Tim Roberts wrote: [EMAIL PROTECTED] wrote: (**) RADEON(0): *Mode 1400x1050: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1400x1050 108.00 1400 34208 34320 1672 1050 1050 1053 1063 (**) RADEON(0): *Mode 1280x1024: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1280x1024 108.00 1280 34208 34320 1672 1024 1050 1053 1063 (**) RADEON(0): *Mode 640x480: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 640x480 108.00 640 34208 34320 1672 480 1050 1053 1063 (**) RADEON(0): *Mode 800x600: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 800x600 108.00 800 34208 34320 1672 600 1050 1053 1063 (**) RADEON(0): *Mode 1024x768: 108.0 MHz (scaled from 0.0 MHz), 64.6 kHz, 60.8 Hz (II) RADEON(0): Modeline 1024x768 108.00 1024 34208 34320 1672 768 1050 1053 1063 These aren't right. Every mode in the list (including the 7 default modes I deleted) is shown as having a pixel clock of 108 MHz, horiz of 64.6 kHz, and vert of 60.8 Hz. The sync and blank numbers in the modeline are bonkers, too. Is this a general issue in the 4.4.99 release, or only for this gentleman? This is business as usual with the radeon driver driving a digital connector and not a problem here. My question to the original poster would be whether he absolutely needs UseFBDev and if yes, what for? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Re: 64 bit XFree86 Starting Problem?
On Wed, 2004-03-31 at 06:33, Mahesh B wrote: I have successfully compiled 64bit XFree86 4.3.0 for ppc64 after applying the ppc64 patch in Linux box. Now I am not able to load the XServer using startx command. I got the following errors. (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting bitmap is the first module loaded, so there's probably a problem with the ELF loader. You can try building a static server with #define DoLoadableServer NO in xc/config/cf/host.def. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [support@ati.com: XFree / Linux Support # 2118096]
On Mon, 2004-03-15 at 21:03, Andreas Klemm wrote: how good does ATI support you in comparison to nVidia ? It's like day compared to night IMHO. A few days ago I had to call ATI hotline (where you have to pay $9.90 for phone support) because of some problems under XP... There I mentioned, that I had the feeling that nVidia seems to support XFree86 team more than ATI, since - drivers of up to date cards have been available in earlier releases than 4.4 and - there are no restrictions concerning 3D mode What you seem to have been missing is that those drivers are about the opposite of free (and ATI offers proprietary drivers as well). The 'free' nv driver only offers basic 2D support. ATI seems to be interested and wants to know exactly why I think, that nVidia seems to support XFree86 better. nVidia only 'supports Linux/X' in the very proprietary software sense. They basically don't seem to provide any interesting information about their hardware to anyone outside nVidia, not even corporations like SciTech. If it wasn't for Mark Vojkovich, I'm not sure there'd be any free support for nVidia hardware today. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XAA2 namespace?
On Wed, 2004-03-03 at 03:59, Mark Vojkovich wrote: Even with Sync() passing the particular surface which is necessitating the sync, I would expect all drivers to be syncing the whole chip without caring what the surface was. Most hardware allow you to do checkpointing in the command stream so you can tell how far along the execution is, but a Sync can happen at any time. Are you really going to be checkpointing EVERY 2D operation? That's where a driver callback to mark the end of a batch of rendering to (and from?) a surface might come in handy? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, 2004-03-02 at 21:06, Mark Vojkovich wrote: On Tue, 2 Mar 2004, David Dawes wrote: On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: Well, then I guess I could call the header file xaa2.h Not to be too picky, but won't this be the third version of XAA, not the second? Yes, it's actually the third. Harm's was the first. I think we even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? As everyone knows, counting starts at 0, so xaa2 in fact denotes the third XAA. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More X servers on one virtual area
On Tue, 2004-02-17 at 09:04, Jan Damborsky wrote: We have four single board computers with graphic accelerators. We have running Linux+X server on each of computer successfully. Each of computer is connected to one LCD panel. For now, we would like to use these four LCD screens like one big virtual area with one mouse cursor. Check out DMX (http://dmx.sourceforge.net/). -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon dri lockup
On Tue, 2004-02-17 at 02:14, Jonathan Isom wrote: Section Device Option Accel # [bool] Option AGPMode 2 Option EnableDepthMoves True# [bool] Have you tried without these two? Option AGPFastWrite False Option HWCursor True Identifier Card0 Driver radeon VendorName ATI BoardName Radeon RV100 QY [Radeon 7000/VE] BusID PCI:1:0:0 VideoRam65536 Is this correct? The VideoRam directive should only be used to override an incorrectly determined amount of video RAM, it's potentially harmful otherwise. EndSection -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon dri lockup
On Mon, 2004-02-16 at 05:45, Jonathan Isom wrote: I've got a Radeon 7000 that locks up hard on a linux 2.4.23. no logs are written requiring power cycle. It locks in Quake3 in less that 7 minutes most times. some xscreensaver work fine,but havn't tried them all If radeon_dri.so isn't at least from XFree86 4.3.0, please try a newer version. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon dri lockup
On Tue, 2004-02-17 at 00:06, Jonathan Isom wrote: On 2004-02-16 09:36:22 -0600 Michel Dnzer [EMAIL PROTECTED] wrote: On Mon, 2004-02-16 at 05:45, Jonathan Isom wrote: I've got a Radeon 7000 that locks up hard on a linux 2.4.23. BTW, what about older (or 2.6) kernels or the DRM from XFree86? no logs are written requiring power cycle. It locks in Quake3 in less that 7 minutes most times. some xscreensaver work fine,but havn't tried them all If radeon_dri.so isn't at least from XFree86 4.3.0, please try a newer version. 4.3.0 doesn't lockup. 4.4.0 rc2 locks up and only when running GL. 4.4.0 runs faster though. the instability i have found is gl related. Are you using any AGP or otherwise DRI related X server options? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
On Fri, 2004-02-06 at 10:30, Andrew C Aitchison wrote: On Fri, 6 Feb 2004, [iso-8859-1] Suresh Chandra Mannava wrote: does agpgard is specificaly for AGP? Yes. or can we use it for PCI? I've never used it, but I've seen references to pcigart, which provides (some of) the features of the agpgart kernel module for PCI devices. After a quite google, I'm not sure whether it is actually a kernel module, or part of the Mach64 DRI project: http://www.ussg.iu.edu/hypermail/linux/kernel/0102.1/0959.html suggests that it may come with the DRI, but http://mail-index.netbsd.org/tech-x11/2003/03/19/0006.html suggests that it may come with the OS kernel. (The first is quite old, but sugegsts that at the time pcigart may not have had support for the Mach64). As the first post says, PCI GART is a feature of ATI graphics chips; AFAIK it's only provided by Rage128 and later. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
On Mon, 2004-01-19 at 19:00, William M. Quarles wrote: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.7.0 but version 1.100.0 or newer is needed. (BTW, this isn't correct, the major should have been bumped) [dri] Disabling DRI. You need the DRM from GATOS as well. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mouse cursor look
On Fri, 2004-01-02 at 23:06, Jozef Riha wrote: thank you. however if you know the answer to my previous question i am still interested.. [...] try it with a sw cursor. try: option hwcursor false in your config. I'm afraid this won't help. Hardware or software cursor is an implementation detail, but the fact that the cursor doesn't appear in window dumps isn't. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon portrait mode
On Mon, 2004-01-05 at 01:04, Jonathan Thambidurai wrote: Is the Radeon hardware capable of accelerating (in 2D, I'm not concerned with 3D/DRI right now) a display in portrait mode? AFAICT the only way would be to render to a shadow framebuffer and use the 3D engine to rotate it. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Sat, 2003-11-29 at 21:03, Fred Heitkamp wrote: On Sat, 29 Nov 2003, Michel [ISO-8859-1] Dnzer wrote: On Fri, 2003-11-28 at 19:27, Fred Heitkamp wrote: name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 4.0.4 Current XFree86 CVS is based on Mesa 5.0.x, it seems to be picking up the wrong libGL? The libOSMesa libraries as of Nov 22 seems to be the following on my system. The OS stands for off-screen, it's unrelated. Start with the output of ldd `which glxinfo` | grep libGL.so (**) RADEON(0): Option AGPMode 4 Have you tried lower AGP modes? No but there doesn't seem to be a problem with the 2.4.x kernels running on mode 4. I will lower the mode and try disabling backing store and see what happens. [...] I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. But that was still at AGP 4x? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
On Fri, 2003-11-28 at 19:27, Fred Heitkamp wrote: name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 4.0.4 Current XFree86 CVS is based on Mesa 5.0.x, it seems to be picking up the wrong libGL? (**) RADEON(0): Option AGPMode 4 Have you tried lower AGP modes? (**) RADEON(0): Option BackingStore (**) RADEON(0): Backing store enabled BTW, do you really want to use backing store? I doubt it causes your problems, but it may hurt performance for local clients. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X11 CVS with linux 2.6.0-test9?
On Tue, 2003-11-25 at 09:09, Fred Heitkamp wrote: Just to aggravate myself I am trying to use XFree86 with linux kernel 2.6.0-test9. I have a Radeon 8500 and a ASUS A7M266-D with two 1600MP processors. I have compiled and installed the radeon kernel modules from the X cvs sources into the kernel modules directory. Why? The one that comes with the kernel is at least as current. When I load the radeon module into the kernel and start X glxinfo shows I have no DRI (first problem) even though dri is enabled. Does LIBGL_DEBUG=verbose glxinfo give a hint? Second problem: X/Gnome 2.4 only runs for a couple minutes before the display freezes hard. The only way to clear the display is to reboot (CTL-ALT-BKSPC does not work; kill -9 X does not clear the display). kill -9 rids the X server of any chance to restore the display; not that it likely has much chance in this case (sounds like a chip lockup). Are you using any AGP or otherwise DRI related options? My question is what is the status of XFree86 and linux 2.6.x kernels? Has been working fine here for a while. :) Does anyone have DRI and Radeon working with 2.6.x on any x86 hardware? I'm running on PPC though. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] convert radeon_video.c to use the CP
On Mon, 2003-11-24 at 00:31, Alex Deucher wrote:
The attached patch converts radeon_video.c to use the CP rather than
MMIO if direct rendering is enabled. I wanted to get some feedback
before committing to DRI cvs. I doubt this will affect overall
performance much, but it will reduce the overhead involved in stalling
the CP when switching between MMIO and the CP.
I still don't really see the point, but I do see problems:
@@ -255,6 +260,11 @@
CARD32 dwOvGCb, dwOvGCr;
CARD32 dwOvBCb, dwOvBCr;
+#ifdef ACCEL_CP
+if (info-directRenderingEnabled)
+ RING_LOCALS;
+#endif
+
if (ref = 2)
return;
ACCEL_CP is only defined in radeon_accel.c for radeon_accelfuncs.c; you
basically added commented out code, you'd have to use #ifdef XF86DRI
instead. I'm not sure using RING_LOCALS like this would even build
though, much less work as intended. I must say it's a bit worrying that
you don't seem to give even the most basic testing (does it get compiled
in at all?) to new code.
@@ -370,9 +400,20 @@
min = (r 16) | (g 8) | (b);
max = (0xff 24) | (r 16) | (g 8) | (b);
-RADEONWaitForFifo(pScrn, 2);
-OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_HIGH, max);
-OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_LOW, min);
+#ifdef ACCEL_CP
+if (info-directRenderingEnabled) {
+ BEGIN_RING(2);
+ OUT_RING_REG(RADEON_OV0_GRAPHICS_KEY_CLR_HIGH, max);
+ OUT_RING_REG(RADEON_OV0_GRAPHICS_KEY_CLR_LOW, min);
+ ADVANCE_RING();
+} else {
+#endif
+ RADEONWaitForFifo(pScrn, 2);
+ OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_HIGH, max);
+ OUTREG(RADEON_OV0_GRAPHICS_KEY_CLR_LOW, min);
+#ifdef ACCEL_CP
+}
+#endif
}
void
OUT_RING_REG() writes two words to the ring, so BEGIN_RING() needs twice
the number of register writes as an argument.
@@ -981,14 +1085,26 @@
left = (left 16) 7;
-RADEONWaitForFifo(pScrn, 2);
-OUTREG(RADEON_OV0_REG_LOAD_CNTL, 1);
-if (info-accelOn) info-accel-Sync(pScrn);
-while(!(INREG(RADEON_OV0_REG_LOAD_CNTL) (1 3)));
-
-RADEONWaitForFifo(pScrn, 14);
-OUTREG(RADEON_OV0_H_INC, h_inc | ((h_inc 1) 16));
-OUTREG(RADEON_OV0_STEP_BY, step_by | (step_by 8));
+#ifdef ACCEL_CP
+if (info-directRenderingEnabled) {
+ BEGIN_RING(3);
+ OUT_RING_REG(RADEON_OV0_REG_LOAD_CNTL, 1);
+ OUT_RING_REG(RADEON_OV0_H_INC, h_inc | ((h_inc 1) 16));
+ OUT_RING_REG(RADEON_OV0_STEP_BY, step_by | (step_by 8));
+ ADVANCE_RING();
+} else {
+#endif
+ RADEONWaitForFifo(pScrn, 2);
+ OUTREG(RADEON_OV0_REG_LOAD_CNTL, 1);
+ if (info-accelOn) info-accel-Sync(pScrn);
+ while(!(INREG(RADEON_OV0_REG_LOAD_CNTL) (1 3)));
+
+ RADEONWaitForFifo(pScrn, 14);
+ OUTREG(RADEON_OV0_H_INC, h_inc | ((h_inc 1) 16));
+ OUTREG(RADEON_OV0_STEP_BY, step_by | (step_by 8));
+#ifdef ACCEL_CP
+}
+#endif
x_off = 8;
y_off = 0;
I'm not sure you can just get rid of the register read like this, I
think it's there to make sure that double buffering works correctly.
Even ignoring these problems, it's kind of ugly in this form; some kind
of unification scheme like in radeon_accelfuncs.c would be better. So
it's back to the drawing board I'm afraid.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: radeon 2d engine and alpha blending
On Fri, 2003-11-21 at 04:39, Alex Deucher wrote: I realize that I could attempt to use it for render accel, but I was hoping to tie it into Keithp's compositing extension (http://www.freedesktop.org/Software/TranslucentWindows) to support alpha blended windows, not just hw accelerated AA text. What else would xcompmgr be using, if not RENDER? [...] I may need to use the 3d engine, 'May'? which then gets into a whole new can of worms with regard to state and locking. I doubt it'll be all that bad, and anyway, you can worry about that once you have something working... Transparent bitblits are supported by XAA's normal bitblit functions, how are these used? are there any apps that use them? render? Plain old ScreenToScreen copy. trans_color (the last argument to the SetupScreenToScreenCopy function) holds the (source) color which is handled to be transparent. It's as simple as that. (hint, hint: sis310_accel.c) And MD is right, it's not a plain transparent bitblit, it's colorkeyed in fact (but only using one color key, not a range). Isn't used very often, though. Thanks for the pointers. I'll take a look. It may not be worth the effort. Colour-keyed blits have been implemented in the radeon driver for ages... problem is, they're not what you'd like them to be. :) (XDirectFB uses them for SHAPE quite nicely though) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon 2d engine and alpha blending
On Thu, 2003-11-20 at 23:33, Alex Deucher wrote: According to marketing literature from ati, radeon hardware seems to support alpha and transparent BLTs. from the literature under 2D graphics: Support for Windows XP GDI extensions: Alpha BLT Transparent BLT Gradient Fill I don't suppose that kind of literature explicitly states that the 2D engine does all this though, does it? :) The databooks and DDKs also have several sections on doing transparent BLTs. is there any reason that this can't be used to accelerate alpha blending in the xserver? Yes, AIUI they really mean 'colour-keyed' when they say 'transparent'. I'd try to implement it myself, but I'm not familiar enough if XAA to understand how it should be done. By looking at another driver which does it? In the long run using the 3D engine is probably the way to go, but if it could be hacked up quickly using the 2D engine it might give a nice boost in the short term. Even Hui Yu once told me along the lines of 'the 3D engine needs to be used for alpha blending'. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glxgears lock up MDK9.2 with radeon 9200
On Wed, 2003-10-29 at 01:23, Emmanuel Allaud wrote: Hi all, I just installed a MDK 9.2, and as the agpgart module seems OK with my nForce2 chipset, I also loaded DRI. All logs are OK, the dri modules load correctly; but if I launch glxgears it locks up solid (hard reset only to get rid of it). I use the radeon driver of MDK9.2 for my radeon 9200 (from chaintech IIRC). Please try a recent r200 snapshot from http://dri.sourceforge.net/snapshots/ and post to the dri-devel list or file a bug at http://bugs.xfree86.org if the problem persists. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
On Sat, 2003-10-25 at 19:53, Harold L Hunt II wrote: Michel Dnzer wrote: On Wed, 2003-10-22 at 17:13, Egbert Eich wrote: Marc Aurele La France writes: [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I believe, so is Egbert. No, not currently. I usually go to the web interface and look at the open bugs, process new ones that can be handled quickly, or try to assign them to an expert on the specific area. There are a lot more areas than we have experts - in these cases I try to work on the ticket myself. This, and the low quality of some of the submissions, consumes a considerable amount of time. Indeed, you're doing most of the bugzilla work alone; it's a pity there aren't more people helping with that. Well, you know, XFree86's disregard for offers to help made by developers that have been with the project for over two years are certainly part of the problem. Err, this is about bug triage, which you can do just as well as everybody else. I agree that you should be able to commit Cygwin stuff yourself (but I can't do anything about it), I'm afraid your rants and threats won't do much good there though. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problem with ATI Radeon Mobility M6 LW
On Tue, 2003-10-14 at 10:33, Dimitris S. Economou wrote: Hi all, I have recently bought a Compaq evo N610C laptop and I'm encountering a problem with the graphics card adapter. The display is flickering producing a distortion in the displayed image. While the display is in this destorted shape it is impossible for someone to work with (not even shut down the laptop gracefully). The problem arises through a list of actions listed below: 1. While booting and after switches to a high resolution display taking advantage of the frame buffer. 2. While switching from X display to virtual consoles and vice-versa (ctrl-alt + Fn) 3. When the lid is opened while the laptop is in normal operation. 4. While resuming from standby. [...] I noticed from the change-log of XFree86 4.3.99.14 a related announcement which maybe the solution of the problem and I reiterate the snippet: ... 478. Radeon driver fixes (Hui [EMAIL PROTECTED]) [...] Does indeed solves the reported problem? Possibly. Trying the driver from current CVS certainly isn't a bad idea. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Compile failure CVS with DRI/DRM=NO
On Fre, 2003-10-10 at 20:56, Martijn Uffing wrote:
radeon_driver.c: In function `RADEONPreInitConfig':
radeon_driver.c:1972: warning: unused variable `s'
radeon_driver.c: In function `RADEONInitDispBandwidth':
radeon_driver.c:5727: structure has no member named
`directRenderingEnabled'
radeon_driver.c:5728: structure has no member named `agpMode'
make[6]: *** [radeon_driver.o] Error 1
Fixed in CVS with this patch.
--
Earthling Michel Dnzer \ 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: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.108
diff -p -u -r1.108 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 7 Oct 2003 22:47:12 - 1.108
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 11 Oct 2003 00:28:10 -
@@ -1969,7 +1969,9 @@ static Bool RADEONPreInitConfig(ScrnInfo
GDevPtrdev= pEnt-device;
MessageTypefrom;
unsigned char *RADEONMMIO = info-MMIO;
+#ifdef XF86DRI
const char *s;
+#endif
/* Chipset */
from = X_PROBED;
@@ -5724,9 +5726,11 @@ static void RADEONInitDispBandwidth(Scrn
/* DDR64 SCLK_EFF = SCLK for analysis */
sclk_eff = info-sclk;
} else {
+#ifdef XF86DRI
if (info-directRenderingEnabled)
sclk_eff = info-sclk - (info-agpMode * 50.0 / 3.0);
else
+#endif
sclk_eff = info-sclk;
}
Re: Deadlock with radeon DRI
On Thu, 2003-10-02 at 22:30, Keith Whitwell wrote:
Keith Whitwell wrote:
The problem seems to be that RADEONAdjustFrame() is designed to be
called from cursor handling routines that are executed outside the
Wakeup/Block handlers (perhaps this came in with SilkenMouse?) but is
being called during initialization after the point the lock is grabbed.
Actually, looking more closely at RADEONAdjustFrame(), I would guess that the
test of (info-CPStarted) is designed to avoid precisely this problem, right?
So I wonder why that's not working for you...
Me too, considering that it seems to be working for the vast majority of
people. Also, DRI{Lock,Unlock}() are designed to handle nested calls. It
seems the problem must be somewhere else, maybe it is a subtle
architecture difference after all?
--
Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: Re: Fwd: Vblank support in kernel and X server]
On Thu, 2003-09-11 at 16:55, Alan Cox wrote: On Mer, 2003-09-10 at 23:21, Michel Dnzer wrote: On Wed, 2003-09-10 at 19:00, Jim Gettys wrote: Here's Alan Cox's mail about it. In 2.4.20-ac1. Won't this conflict with the DRM vblank interrupt handling? (I've also seen framebuffer device patches for this...) Thats a matter for the X server driver modules. If DRM provides it then don't ask for it from the vblank code. In the case of framebuffer the same can be said. Nothing prevents one app from using the DRM interface, another the framebuffer device and yet another the generic vblank one, and at most one of them will work as expected in that case. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
On Wed, 2003-09-10 at 17:55, Alan Hourihane wrote: On Wed, Sep 10, 2003 at 05:41:23PM +0200, Michel Dnzer wrote: On Wed, 2003-09-10 at 17:09, Jim Gettys wrote: While the X server has had the XSync extension for a long time, the operating system hooks to allow X to synchronize with external events (e.g. vertical sync, sample clock of audio streams, etc) have been absent in open source systems. XSync was developed in the days of engineering workstations 10 years ago, and was debugged with such kernel support. FWIW, the DRM has provided synchronization to the vertical refresh for a while. Indeed. But it's presented through the OpenGL interface, whereas using XSync would allow non-OpenGL apps to use this extension and get that facility. No need for OpenGL, it's simply an ioctl for the DRM device. It wonly works when the DRI is enabled obviously. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
On Wed, 2003-09-10 at 18:11, Alan Hourihane wrote: On Wed, Sep 10, 2003 at 06:05:42PM +0200, Michel Dnzer wrote: On Wed, 2003-09-10 at 17:55, Alan Hourihane wrote: On Wed, Sep 10, 2003 at 05:41:23PM +0200, Michel Dnzer wrote: On Wed, 2003-09-10 at 17:09, Jim Gettys wrote: While the X server has had the XSync extension for a long time, the operating system hooks to allow X to synchronize with external events (e.g. vertical sync, sample clock of audio streams, etc) have been absent in open source systems. XSync was developed in the days of engineering workstations 10 years ago, and was debugged with such kernel support. FWIW, the DRM has provided synchronization to the vertical refresh for a while. Indeed. But it's presented through the OpenGL interface, whereas using XSync would allow non-OpenGL apps to use this extension and get that facility. No need for OpenGL, it's simply an ioctl for the DRM device. It wonly works when the DRI is enabled obviously. O.k. But then that's not very portable - in this instance we'd have to get the user space app to talk directly to the DRM. Ugh! Really? I'd think only the server would use the device, if the clients did, it would be the same problem regardless of the underlying mechanism, wouldn't it? (I'm talking about using it for XSync, in case that wasn't clear; an abstraction library for the various methods of vertical refresh synchronization might also be useful though) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: Re: Fwd: Vblank support in kernel and X server]
On Wed, 2003-09-10 at 19:00, Jim Gettys wrote: Here's Alan Cox's mail about it. In 2.4.20-ac1. Won't this conflict with the DRM vblank interrupt handling? (I've also seen framebuffer device patches for this...) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon lockups with 4.3.0
On Sat, 2003-08-30 at 00:46, Warren Turkal wrote: I am using XFree86 4.3.0 on a Debian Sid system with kernel 2.6.0-test4. Before I file a formal bug, I wanted to verify that it wasn't already fixed in the CVS HEAD. I have a Radeon M7. The XServer locks up the machine every now and then. When it locks up, the machine will still repsond to ACPI events (eg. acpid will still shutdown the machine when I press the power putton). I am not sure if the system is pingable at that point. The locking up is not changed if I add option NoAccel true to the driver configuration clause in my config file. In that case it can hardly be an X problem. Sounds rather like the kernel (anything interesting in its output? Does the same thing happen with 2.4 kernels?) or hardware. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 2003-08-28 at 03:30, Thomas Winischhofer wrote: I need to copy the texture to video RAM once, unless somebody tells me it already is there (I could use the 2D accelerator for this, too, then. In this case I just wonder why the mga driver doesn't do it this way.). Because the mga driver RENDER acceleration is just a proof of concept hack? :) Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. Err, I get without acceleration on a 1 Ghz TiBook: 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line (Charter 24) Did you drop some digits? :) (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) I guess it's not the op being something else than PictOpOver? Could it be related to XAA_RENDER_NO_SRC_ALPHA? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 2003-08-28 at 15:58, Thomas Winischhofer wrote: Michel Dnzer wrote: Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. Err, I get without acceleration on a 1 Ghz TiBook: 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line (Charter 24) Interesting. What do -shmput500 -rect500 -oddtilerect500 give you on that machine? 2 reps @ 0.3149 msec ( 3180.0/sec): 500x500 rectangle 1 reps @ 0.5198 msec ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) 800 reps @ 7.1992 msec ( 139.0/sec): ShmPutImage 500x500 square (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) I guess it's not the op being something else than PictOpOver? Could it be related to XAA_RENDER_NO_SRC_ALPHA? They are called under 4.2, but not under 4.3. Does the server make the difference, or the libraries? Have you traced the X server which would call them? Maybe freetype (which I use the Debian sid version of) needs to be recompiled for 4.3. I don't think freetype is directly related to this, do you mean Xft? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 2003-08-28 at 16:51, Thomas Winischhofer wrote: Michel Dnzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Well, 32 bit PowerPC CPUs aren't exactly famous for memory throughput. :( This is even accelerated via AGP by the chip's DMA engine, otherwise I only get around 50. Why the h*ck is render so fast on your machine? Beats me. One possibility is that doing it unaccelerated requires the CPU to read from video RAM, Indeed, it does AFAIK. which is terribly slow on my shared-memory architecture machine. dga (by pressing b) reports about 500MB/sec for writing, and only 37MB/sec for reading. Perhaps the 2D engine suffers from the same bottle-neck when doing the alpha blending... Sounds plausible. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Asiliant 69030 driver on PPC platform
On Thu, 2003-08-21 at 17:50, Gazelle Jean-Laurent wrote: Has anyone succeded in using Asiliant CT 69030, with XFree chips driver on a PowerPC platform ? I tried to compile XFree 4.1.0 sources on both Linux and LynxOS, and encountered the same issue on both system : - Accel mode off : color problem on 16bpp and 24 bpp : It seems to be a ByteOrdering problem 24 bpp : R and B are inverted 16 bpp : someting like R-G G-B B-R (enabling the XR0A 16bits ByteSwap solves the problem, but - Accel mode on : ByteSwapping problem on font in a xterm window (the letters are mirrored) http://xfree86.org/4.3.0/RELNOTES2.html#3 suggests that this might work in 4.3 . -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2 questions about radeon driver
On Tue, 2003-08-19 at 21:49, Alex Deucher wrote: I'm attempting to convert the Xv code to use the CP. how do you check to find out if the driver is using CP or MMIO accel? I considered using info-directRenderingEnabled, but as far as I can see the radeon can use the CP for accel even if the DRI is disabled. No, it can't. There's also info-CPStarted which indicates whether the CP is currently running. secondly, is there a way we could switch to software rendering if the total width or height of or all rendering windows is larger than 2048? Since we seem to be hw limited by that, it'd be nice if the driver would just switch to software after 2048 rather than just showing a blank window or in some cases locking up the video card. It might be too much of a pain in the butt though... (I assume you mean OpenGL software rendering) I don't think this is possible with the current scheme, we simply need to disable the DRI if the virtual resolution exceeds 2048 in either dimension. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [XFree86] Driver problem for RADEON 9100
On Sun, 2003-08-17 at 18:49, Alexander Stohr wrote: (WW) RADEON(0): Mode 640x480 is out of range. (WW) RADEON(0): Valid modes must be between 320x200-0x0 (II) RADEON(0): Total number of valid FP mode(s) found: 0 (EE) RADEON(0): No valid mode found for this DFP/LCD (EE) Screen(s) found, but none have a usable configuration. Let me say, there must be some driver problem. I think the major problem for setting up a cloned LCD/DFP mode is the lack of DDC detected modes for the 2nd port, so the driver is unable to clone any mode at all. i would like to pass that on to the experts. i dont know if using a snapshot version of the drivers or of X11 will help in any way. Assuming this is from 4.3, a snapshot driver will likely help. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Using the radeon CP engine for Xv
On Thu, 2003-08-14 at 17:45, Alex Deucher wrote: If the CP is enabled for acceleration on the radeon, could I also use it to issue Xv commands rather than using mmio? It looks like it should be possible. I'd be willing to give it a try. would any sort of special locking be required or can I just issue the commands to the ring like the accel code does? The latter. What kind of speed up would I expect if any? None I guess, as Xv involves relatively little register write overhead. Even if you mean transferring the image data as the r128 driver can, I'm not sure it's worth the effort as direct writes to the framebuffer seem to be at least as fast on well-configured current systems. That being said, using the CP for all (or as many as reasonable) register writes would have the benefit of not stalling the CP. Might yield slightly better performance when mixing stuff which does and doesn't currently use it. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: blanking of non-refreshing windows
On Wed, 2003-08-13 at 16:29, Andy Isaacson wrote: On Wed, Aug 13, 2003 at 11:39:08AM +0200, Michel Dnzer wrote: On Tue, 2003-08-12 at 16:49, Andy Isaacson wrote: A more useful solution would be to schedule an event a few dozen milliseconds (say, 20 or 100 ms) in the future, which upon arrival would check that the window has been refreshed and, if not, write it with the background color, on the assumption that if the app hasn't refreshed yet, it's not going to anytime soon. Ideally this event would only be handled when the X server is otherwise idle. All this effort for a band aid? A different basic approach like in XDarwin or XDirectFB makes more sense to me. I'm not familiar with how those two X servers operate, so could you help me out by explaining? How do they handle window obscures? How is it different from X11's BackingStore? I don't know a lot of details yet, but they indeed always keep the contents of windows around and composite the desktop with them (actually, they have another windowing system do this, but that's not the point). Note that BS is turned off by default precisely because it's frequently a pessimisation -- Actually, I thought it was because the current implementation we have sucks. too often the BS pixmap is too old, and the X server writes it to the framebuffer only to have it overwritten by the app as soon as it's scheduled. Well, do you want the windows to be refreshed ASAP or not? :) I don't think this is a big deal as the windows will be kept in video RAM whenever possible. I can only recommend trying out XDirectFB to anyone - it was a real 'eye opener' for me to move a screen-sized xeyes in front of a Mozilla window. Not to mention that it does real translucency. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: blanking of non-refreshing windows
On Tue, 2003-08-12 at 16:49, Andy Isaacson wrote: The problem: if an X11 app is very slow to refresh (it is swapped out, or SIGSTOPped, or is over a very slow link) its windows may remain garbage for a long time, which can be confusing when the garbage happens to be an image of windowmanager decorations (for example). The obvious solution, writing the background color into the framebuffer when a window is un-obscured, is a pessimisation of the normal case (where the app responds within a few milliseconds). A more useful solution would be to schedule an event a few dozen milliseconds (say, 20 or 100 ms) in the future, which upon arrival would check that the window has been refreshed and, if not, write it with the background color, on the assumption that if the app hasn't refreshed yet, it's not going to anytime soon. Ideally this event would only be handled when the X server is otherwise idle. All this effort for a band aid? A different basic approach like in XDarwin or XDirectFB makes more sense to me. Please CC me on any discussion, as I am not subscribed. Gladly, unfortunately the list makes this unnecessarily hard. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Sat, 2003-08-02 at 02:24, Simon Urbanek wrote: On Saturday, July 26, 2003, at 01:08 PM, Michel Dnzer wrote: On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote: When did you try exactly ? I've seen more fixes for TMDS getting in the CVS recently. I'm not sure what's up here, definitely not something the doc explains. I suspect it's the path of pixel data from the framebuffer to the TMDS transmitter that has an endian problem, I fail to see why SURFACE_CNTL thing would fail, or maybe it's a problem related to surface translation getting in our way ? I suspected that as well. If current CVS still doesn't work (works perfectly here with an external CRT on an M9 in a TiBook IV), please try this patch and post the RADEONInitCommonRegisters output. Thanks for the info. I was out of town so I couldn't test it until now. I built X from the current CVS just a few hours ago with the following results: 1) If I enable FBDev, then I get a nice picture on the TMDS screen, correct colors and nice 24 bit color depth. I also get a white screen on the ADC (VGA) screen. Well, as I said before, the behaviour of the second head is basically undefined in this case. It's not a supported configuration. 2) If I disable FBDev, then the results are exactly same as the version of X I used when first reporting this problem: signal is only on the DVI screen (ADC is blanked), the colors are broken in that weird manner (half-split color bits). Getting back to the console is impossible since both screens get blanked once you try that. I used your patch, but the info doesn't seem very helpful (btw the behavior was the same with/without the patch). I have attached logs from both runs. Indeed, it's not stray surfaces getting in the way either. I suspect it's rather a CRTC/DAC/whatnot setup problem. Hui Yu is the man to talk to. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote:
latest CVS build (by myself) as of yesterday (4.3.99...)
When did you try exactly ? I've seen more fixes for TMDS getting
in the CVS recently. I'm not sure what's up here, definitely not
something the doc explains. I suspect it's the path of pixel
data from the framebuffer to the TMDS transmitter that has an
endian problem, I fail to see why SURFACE_CNTL thing would fail,
or maybe it's a problem related to surface translation getting in
our way ?
I suspected that as well. If current CVS still doesn't work (works
perfectly here with an external CRT on an M9 in a TiBook IV), please try
this patch and post the RADEONInitCommonRegisters output.
Or maybe it's something like http://bugs.xfree86.org/show_bug.cgi?id=521
?
--
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: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.103
diff -p -u -r1.103 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 24 Jul 2003 13:50:23 - 1.103
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 26 Jul 2003 11:02:28 -
@@ -5341,8 +5341,10 @@ static void RADEONRestore(ScrnInfoPtr pS
}
/* Define common registers for requested video mode */
-static void RADEONInitCommonRegisters(RADEONSavePtr save, RADEONInfoPtr info)
+static void RADEONInitCommonRegisters(ScrnInfoPtr pScrn, RADEONSavePtr save)
{
+RADEONInfoPtr info = RADEONPTR(pScrn);
+
save-ovr_clr= 0;
save-ovr_wid_left_right = 0;
save-ovr_wid_top_bottom = 0;
@@ -5360,6 +5362,49 @@ static void RADEONInitCommonRegisters(RA
*/
if (save-bus_cntl (RADEON_BUS_READ_BURST))
save-bus_cntl |= RADEON_BUS_RD_DISCARD_EN;
+
+save-surface_cntl = 0;
+
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+switch (pScrn-bitsPerPixel) {
+case 16:
+ save-surface_cntl |= RADEON_NONSURF_AP0_SWP_16BPP | RADEON_NONSURF_AP1_SWP_16BPP;
+ break;
+
+case 32:
+ save-surface_cntl |= RADEON_NONSURF_AP0_SWP_32BPP | RADEON_NONSURF_AP1_SWP_32BPP;
+ break;
+}
+
+{
+ unsigned char *RADEONMMIO = info-MMIO;
+
+ ErrorF(%s: Surface 0: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE0_INFO), INREG(RADEON_SURFACE0_LOWER_BOUND),
+ INREG(RADEON_SURFACE0_UPPER_BOUND));
+ ErrorF(%s: Surface 1: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE1_INFO), INREG(RADEON_SURFACE1_LOWER_BOUND),
+ INREG(RADEON_SURFACE1_UPPER_BOUND));
+ ErrorF(%s: Surface 2: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE2_INFO), INREG(RADEON_SURFACE2_LOWER_BOUND),
+ INREG(RADEON_SURFACE2_UPPER_BOUND));
+ ErrorF(%s: Surface 3: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE3_INFO), INREG(RADEON_SURFACE3_LOWER_BOUND),
+ INREG(RADEON_SURFACE3_UPPER_BOUND));
+ ErrorF(%s: Surface 4: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE4_INFO), INREG(RADEON_SURFACE4_LOWER_BOUND),
+ INREG(RADEON_SURFACE4_UPPER_BOUND));
+ ErrorF(%s: Surface 5: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE5_INFO), INREG(RADEON_SURFACE5_LOWER_BOUND),
+ INREG(RADEON_SURFACE5_UPPER_BOUND));
+ ErrorF(%s: Surface 6: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE6_INFO), INREG(RADEON_SURFACE6_LOWER_BOUND),
+ INREG(RADEON_SURFACE6_UPPER_BOUND));
+ ErrorF(%s: Surface 7: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE7_INFO), INREG(RADEON_SURFACE7_LOWER_BOUND),
+ INREG(RADEON_SURFACE7_UPPER_BOUND));
+}
+#endif
}
/* Define CRTC registers for requested video mode */
@@ -5487,22 +5532,9 @@ static Bool RADEONInitCrtcRegisters(Scrn
(pScrn-bitsPerPixel * 8));
save-crtc_pitch |= save-crtc_pitch 16;
-save-surface_cntl = 0;
save-disp_merge_cntl = info-SavedReg.disp_merge_cntl;
save-disp_merge_cntl = ~RADEON_DISP_RGB_OFFSET_EN;
-#if X_BYTE_ORDER == X_BIG_ENDIAN
-switch (pScrn-bitsPerPixel) {
-case 16:
- save-surface_cntl |= RADEON_NONSURF_AP0_SWP_16BPP;
- break;
-
-case 32:
- save-surface_cntl |= RADEON_NONSURF_AP0_SWP_32BPP;
- break;
-}
-#endif
-
RADEONTRACE((Pitch = %d bytes (virtualX = %d, displayWidth = %d)\n,
save-crtc_pitch, pScrn-virtualX,
info-CurrentLayout.displayWidth));
@@ -6066,12 +6098,13 @@ static Bool RADEONInit(ScrnInfoPtr pScrn
info-Flags = mode-Flags;
+RADEONInitCommonRegisters(pScrn, save);
+
if (info-IsSecondary) {
if (!RADEONInitCrtc2Registers(pScrn, save, mode, info))
return FALSE;
RADEONInitPLL2Registers(save, info-pll, dot_clock);
} else {
- RADEONInitCommonRegisters
Re: Performance problems revisited
On Mon, 2003-07-21 at 13:29, Billy Biggs wrote: 1. A SuSE user with a Radeon 8500, P4 1.8, that gets 133fps with xvtest, but seemingly good performance from x11perf -shmput500 [2]. The radeon driver uses the CP for image writes, does Option XaaNoScanlineImageWriteRect have a similar impact on x11perf -shmput500 performance? - Motherboard AGP chipset. Does this matter if the driver uses the CPU to copy? Can just loading agpgart help? No. I wonder if the video capture card could have something to do with it? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Any clues - TuxRacer Incorrect Rendering
On Thu, 2003-07-17 at 23:25, Chris Edgington wrote:
Working on my last known bug in the SM731 support in the siliconmotion
driver. Using the current siliconmotion driver and my newly modified driver
on the SM722 hardware, running TuxRacer from RH9 works fine. TuxRacer (or
probably more appropriately glut) uses the VidMode extension to set the mode
to 640x480x16. The driver has no dri component, so the rendering of the game
is extremely slow, but it works.
When I run my new driver on the SM731, everything X works fine -
acceleration, overlay, etc. However, when I run TuxRacer, after the modeset
happens to 640x480x16, the TuxRacer display is hosed. It looks like some
kind of framebuffer width or pitch problem.
Indeed, does the desktop look correctly when switching modes with
ctrl-alt-{+,-} or xvidtune?
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Fri, 2003-07-18 at 14:30, Dan wrote: Sure Quake works, and xscreensaver and the xmms plugins. Cool. But a majority of the games I have don't work: Tribes 2 ( crashes on startup ), Unreal Tournament 2003 ( previously required S3 Texture Compression, now has far too many rendering bugs to be able to tell what's going on) , Neverwinter Nights ( runs at 1 frame every 5 seconds - and yes I have DRI working ). FWIW, most if not all of these problems have been fixed or are being worked on in DRI CVS. Watch the dri-devel and dri-patches lists. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Wed, 2003-06-04 at 14:11, Simon Urbanek wrote: On Wednesday, June 4, 2003, at 01:19 AM, Michel Dänzer wrote: On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? I tried the patch, but without any visible results :(. I was digging a bit more in the wrong colors issue and found out the following: When I'm running the CRT,CRT layout (as opposed to the previous CRT,TMDS) the colors behave differently. In fact is seems like a common endianess-problem: the layout of colors is 0xBBGGRR00 in Mac big-endian notation, but the color on the screen written by the driver are 0x00RRGGBB - that is the colors red and green are swapped and blue is never seen. This is true for both screens. So the summary (CVS XFree): * CRT,CRT mode: swapped 'byte-sex' causes wrong colors, otherwise both screens are OK * CRT,TMDS mode: CRT screen is off, TMDS has split colors - i.e. the low and high 4 bits of the components are interlaced I wanted to look at the code, but I can't seem to find any tech info on the Radeon chip - is it available to the chosen only after signing a NDA? Any help, especially with the CRT+TMDS mode is highly appreciated! Cheers, Simon PS: Additional info for Ben: In fact the kernel radeon driver works with the DFP *only* - in CRT,CRT layout the kernel hangs in the early-boot screen (and doesn't go further - no network etc.). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-07-15 at 16:17, Michel Dänzer wrote: [ citation without new stuff ] Sorry about that, fun time with Evolution. :\ -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: color swapping problem
On Thu, 2003-07-03 at 17:59, Laurent Mohin wrote: I'm working on a PowerPC (big endian) processor but my graphic controller (Silicon Motion SMI712) insists on treating its frame buffer as little endian. Working at 16bpp, byte swapping led me to incorrect colors on my display. Is there an option or a patch available in the Xserver to get rid of this issue? You could use a shadow framebuffer with a dedicated update function, but you'd lose any hardware acceleration. Doesn't the chip provide means to swap bytes on the framebuffer aperture though? Most non-ancient chips do. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Negative y values to fbcon_xx_putcs?
On Thu, 2003-07-03 at 10:51, Cheshire Cat Fish wrote: My putcs function is getting negative y values. None of the other driver sources I have looked at appear to do anything to handle negative y values. What would cause my putcs to be called with a negative Y? Wrong list, please follow up to linux-fbdev-devel only. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: aid for TODO tasks offered
On Mon, 2003-06-30 at 18:55, Egbert Eich wrote: (I don't know who currently maintains the i128 and r128) AFAIK Kevin E. Martin still maintains the r128 driver. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon 7000
On Wed, 2003-06-25 at 13:41, Lucio wrote: I have a sapphire m275 with radeon 7000, 32Mb, integrated. I can't make XFree86 work with it. With radeon or ati driver, system crashes when I launch X server, the screen gets black, keyboard leds light on and i have to physically shut down the pc. Any ideas? That seems to be a Radeon IGP 320; see http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=36 . -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Radeon hardware cursor
[ This is OT for dri-devel, please follow up elsewhere ]
On Fri, 2003-06-20 at 18:33, Jon Smirl wrote:
I'm looking at the ARGB code in the new driver. But
when the card powers on it seems to be in mono curosor
mode, how do you switch it to ARGB mode? I haven't
been able to locate where the new driver changes the
mode.
Indeed, it's a bit obfuscated in the driver. Bits 22:20 of
CRTC{,2}_GEN_CNTL control the cursor mode, the driver uses 2 for ARGB
with premultiplied alpha.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
On Fri, 2003-06-13 at 22:01, Andreakis, Dean (MED) wrote: I went ahead and commented out the dri section and the Load dri, Load GLcore and Load glx lines in the Module section of XF86Config-4 to try and prevent the DRI drivers from loading but I still see the same messages in the XF86 log file. Maybe I need to do something else to stop DRI from trying to load... Don't worry about the DRI, it shouldn't have any influence on your problem. It gets disabled with multihead anyway. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: I have several problems with the ATI Radeon drivers in XFree on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Isn't expected to work with this. Michel Daenzer's 4.2.1 DRI build 4.2.1? Haven't you tried my current packages for sid? Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) The first two worked even worse (no image at all), so in the following I'll refer to the later two which produce exactly the same results. Problem 1) I have a TMDS flat panel (DVI-D) on the DVI port of the card and an analog flat panel on the ADC port (via ADC2VGA cable). Both panels get correctly detected (see attached log file), but the analog one gets no signal after X is started. Option MonitorLayout CRT, TMDS doesn't help (nothing really changes, since both monitors get correctly detected even wihtout this). I tried all tricks I could think of, but the analog one (on the ADC port) gets no signal (even after X closes). Funny enough, using a DVI2VGA adapter and analog input of the *digital* panel causes both panels to work - i.e. changing the mode of the *panel that works* causes the other one to start working as well. This means that CRT, CRT combination works. It is really annoying since I have a digital panel and I don't want to run it in analog mode which sucks. Have you looked at the code for how the type of one head might have an influence on the other one? Probelm 2) No matter what combination (dual or single head) the colors are always wrong. This is independent of the depth used (every time differently wrong colors of course). I analyzed it for the 24-bit mode for the digital panel. Although 24-bit mode is enabled (and the server uses 4-bytes per pixel see log below), in fact only 3x4=12 bits are used. I wrote a small proggy that writes directly to the frame buffer and the sequence to set RGB colors (each 4 bit) is 0x00G0RB00 (beware, Macs are big-endian), that is 0x00f0 is fully saturated green, 0xf000 fully saturated red etc. Hmm, sounds like the palette is programmed incorrectly. Hui Yu or Kevin E. Martin might know more about these problems, but I'm not sure if they're reading either of these lists. You could file a bug to the XFree86 bugzilla. Problem 3) Shutting down X blanks both screens - i.e. the frame buffer is not correctly restored. This is somewhat painful since after closing X you can access the box via ssh only. Other relevant info: kernel is 2.4.20-ben10 (the devel versions crash), frame buffer works only with video=ofonly. Have you reported radeonfb not working to Benjamin Herrenschmidt or the linux-fbdev-devel list? It may also a bug in the radeon driver that it doesn't restore the console mode correctly though. PS: Posting once is enough... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] crash FreeBSD 4.8/XFree86 4.3.0/ATI Radeon MobilityM7: Symbol xf86SetDDCproperties unresolved
On Sam, 2003-04-12 at 18:51, Stephen Bartlett wrote: After a fresh install of FreeBSD 4.8-RELEASE I get this type of crash during startx: = (--) RADEON(0): VideoRAM: 32768 kByte (64-bit DDR SDRAM) (==) RADEON(0): Write-combining range (0xd010,0x8) was already clear (II) RADEON(0): CloneDisplay option not set -- defaulting to auto-detect (II) RADEON(0): Primary Display == Type 2 (II) RADEON(0): Panel ID string: (II) RADEON(0): Panel Size from BIOS: 65535x65535 Symbol xf86SetDDCproperties from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting This might be fixed in CVS. I get a very similar, although not exact same crash using a fresh install of FreeBSD 5.0-RELEASE (which installs XFree86 4.2.0). Different set of unresolved symbols, I believe. That's because the unresolved symbols are just a symptom and don't matter. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] radeon 9000 dual head work at all?
On Sam, 2003-04-12 at 21:15, Yang Yang wrote: then I tried to take down the dri module and run dual head, still doesn't work, [...] I enclosed my log file XFree86.0.log and the config file XF86Config, could you please have a look when you got time? Thanks a lot! You only added Screen 1 to one device section. You need to add Screen 0 to the other one. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] radeon 9000 dual head work at all?
On Sam, 2003-04-12 at 22:16, Yang Yang wrote: fglrx only works with XF86 4.2 /4.1, in fact , I got it working (with TV-out (kind of dual head)) before. but doesn't work with XF864.3, because XF864.3 uses a totally different way to load driver modules specified in the Device section: it goes to /usr/X11R6/lib/modules/drivers/* instead of /lib/modules/2.4.20/kernel/drivers/char/drm so when I put flgrx in the /lib/modules... XF86 4.3 says can't find the module, and if i put it in /usr/X11R6/.. it says the module format is wrong, seems 4.3 put the driver into two parts, one in /usr/X11R6 , and that calls the drm unit ( kernel module) in /lib/modules . /lib/modules/`uname -r`/kernel contains kernel modules, which the X server doesn't deal with directly, never has. If the fglrx driver doesn't work with 4.3 (I thought there's a new version that does?), that's probably because the XFree86 module ABI changed. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] radeon 7500 1600x1024 no longer working at xf86 4.3
On Don, 2003-04-03 at 21:18, Nate Pearlstein wrote: I tried out the new XFree86 4.3 to see if my long standing pet peeve about DPMS not working with my SGI Multilink adapter and 1600sw was fixed. It is! Cool! However, now it refuses to do 1600x1024 it only does 1280x1024. I usually use xinermama so I tried it w/o and using just the flat panel and the same thing. BTW the same XF86Config file works fine with 4.2 Attached are the XF86Config file and the XFS86 log I'm a bit confused: the log looks like it's using 1600x1024 on the first head, and it's getting very different EDID info from the second head. What am I missing? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.3.0 Radeon Mobility driver jittering screen
On Fre, 2003-04-04 at 18:46, Yann E. MORIN wrote: On Friday 04 April 2003 16:52, you wrote: I', using 4.2.0 on my Laptop (IMB Thinkpad A30), which seems to have a Mine is ACER Aspire 1430, with the (--) PCI:*(1:0:0) ATI Radeon Mobility M6 LY rev 0, Mem @ 0xe000/27, 0xc010/16, I/O @ 0x3000/8 With 4.2.0 this works fine (except a drawing bug when using line width 0 ...), so I tried to upgrade to 4.3.0. The Problem with 4.3.0 is that the display is sometimes (after X start) completely unusable, because the full display jitters. [--SNIP--] I have the exact same card with the exact same problem. Switching once or twice fixes the problem. Killing the server and restarting it (runlevel 5) helps also. BUT I use the framebuffer console and it happens from time to time that the display jitters in this same way when the kernel boots (kernel 2.4.20 vanilla). So I suspect there's a bug in either : - the kernel radeon framebuffer - the XFree radeon driver - both. I think it must be the last as Martin doesn't mention a framebuffer device at all and it doesn't seem to happen with 4.2 for him. That's very interesting; someone 'only' needs to look at a diff between the radeon driver in 4.2 and 4.3 and see what was changed that's also done in radeonfb. ;) I used to have the problem on a PowerBook with an M7, but not with an M6 or an M9. I guess it's a semi-random (timing related?) bug influenced by many factors. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [Bug 25] New: radeon_vtxfmt.c:1057:radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed.
On Fre, 2003-04-04 at 20:56, [EMAIL PROTECTED] wrote: [...] As a blender user who ran into this bug myself (and nearly overlooked this message) the patch would be greatly appreciated. Is this bug posted on bugs.xfree.org, or a DRI specific bugzilla? I ask because several keyword searches didn't turn anything up (I assume I'm chosing bad keywords to search on). The bug number is in the subject: http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] AIW Radeon 7500 - R200 QW XFree86 4.3Configuration Problem
On Mit, 2003-04-02 at 16:07, Doug Webb wrote: I have an All In Wonder Radeon 7500 AGP graphics card with a CRT attached to the DVI/VGA port via the included adapter. X gives me the error Screens found but no usable configuration found. In 4.2 the Option CrtScreen was used to solve this problem however this doesn't work in 4.3. I have tried all combinations of all the options I find relating to the adapter and monitor but nothing will force the driver to use the attached CRT. Does anyone know how to configure this card? If not where in the driver code should I look to force to it to use the CRT? I'm afraid that's not possible with 4.3.0. You could try http://www.penguinppc.org/~daenzer/XFree86/HuiYu/x430_radeon_all_in_one.diff and use Option MonitorLayout with that if necessary. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 with Intel I810 Chipset-Problems
On Don, 2003-04-03 at 15:59, Marcus C. Gottwald wrote: For me, disabling framebuffer usage helped to reduce the frequency of crashes, i.e. make sure there is NO such entry: Option UseFBDev true in your XF86Config. The i810/830 driver doesn't support that option. Did you switch from framebuffer device to VGA console instead? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Laptop display blanking with XFree Radeon driver onDell Inspiron 8200
On Mit, 2003-04-02 at 10:29, Simon Ejsing wrote: --BEGIN PGP SIGNED MESSAGE-- Hash: SHA1 My hardware is Dell Inspiron 8200 with 64MB Radeon Mobility 9000 gfx card. According to XFree86 logfile my chipset is: (II) Primary Device is: PCI 01:00:0 (--) Chipset ATI Radeon Mobility M9 Lf (AGP) found This would seem to be correct. However my problem arise when I blank the display (either by Fn+D or by closing the lid), after I restore the display by hitting enter or opening the lid again, the display stays blank and the backlight turns on... It seems that the Radeon driver doesn't restor the display correctly? Have you seen bugs 73 and 74? Also I have problems when suspending the laptop, this however seems to be a BIOS bug when using AGP... Anyone found a workaround? See http://cpbotha.net/dri_resume.html . -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Radeon 9000 Pro/7500 Multihead findings
On Don, 2003-04-03 at 02:13, Jason van Zyl wrote: This may possibly have already been reported but here goes. I have tried the following with both a Radeon 9000 Pro and a Radeon 7000. I have: Redhat 9.0 [ 4.3.0 ] Asus A7V333 Logitech USB / Wireless Mouse 2 Samsung SyncMaster 570V TFTs Xinerama enabled From many of the previous postings I have put together an XF86Config that will fire up X where both monitors appear to work correctly upon startup but when I drag the mouse from the primary display (which I believe is the DVI port in Radeons) the primary display seems to switch off. If I just use the keyboard I can open windows fine and I can even create windows and drag them across both displays but as soon the the mouse cursor moves from the primary to the secondary display I lose the primary display? If this has been reported, Indeed, it has: http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=90 -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: DDC via I2C (was: Help with configuration please!)
On Mon, 2003-03-31 at 22:34, Mark Vojkovich wrote: The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. The infamous http://www.penguinppc.org/~daenzer/DRI/radeon-ddc.diff (by Hui Yu) adds code to the radeon driver to probe all I2C busses for monitors. Hope this helps. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: BuildGlxExt
On Die, 2003-04-01 at 04:18, Frank Liu wrote: Can somebody explain to me what is BuildGlxExt? in the comment, it says: /* * If you don't want to build support for an external GLX server module or * library, uncomment this. * #define BuildGlxExt NO */ what does external mean? AFAICT BuildGlxExt is about the GLX extension and related components like libGL. Someone please correct me if I'm wrong. PS: About building all libraries shared: Are you aware of the implications? Are you going to support the API/ABI of every library? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] radeon 8500dv aiw
On Son, 2003-03-30 at 23:37, Peter Hoogsteen wrote: I have an Ati Radeon 8500 All In Wonder DV. In the past i used 'Option CrtScreen' in the monitor section in de XF86Config-4 file to make it work. But now i run Manadrake 9.1 with xfree86 4.3.0, and i have no result on startx. I have also a TV connected wich does show nothing either. Have you seen http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=16 ? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Problem installinglinux-drm-4.2.0-kernelsource.tar.gz
On Son, 2003-03-30 at 09:52, Prateek Mohan Dayal wrote: I was trying to make the above file BTW, AFAIK the DRM that comes with the 2.4.20 kernel should work with XFree86 4.2.0. but the process terminates with the error ... please help me the error is make: *** [gamma_drv.o] Error 1 That's not enough information, you'd have to provide the compiler errors. I assume you don't have a graphics chip with a Gamma though, so you could try just building the driver you need with make -f Makefile.linux driver.o -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] ATI Fire GL 9000 (Compaq Evo N800W)
On Fre, 2003-03-28 at 09:34, Georg-W. Koltermann wrote: I see that XFree86 4.3 has support for the FireGL 8800/8700 (R200), Radeon 9000 (R250), and Fire GL X1/Z1 (R300). Would one of these drivers bee good enough to support the Fire GL 9000 as present in the Compaq Evo N800w? AFAICT the FireGL 9000 seems to be a variant of the 9000 Mobility, so I'd expect it to work, in the worst case by overriding the chip ID to that of the latter. If XFree86 does not support it yet, are you aware of any other packages/additions to support this chipset? You could always try ATI's drivers if XFree86 doesn't meet your needs. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: XFree86 host.def file questions
On Fre, 2003-03-28 at 02:44, Kendall Bennett wrote: With that said, can someone recommend the best 'grep' command to use to determine if there are any errors in the World.log file? I use grep '\*\*\*' to catch the make errors. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] ATI Radeon 7500
On Fre, 2003-03-28 at 04:13, Robert Landrum wrote: I picked up an ebay special Radeon 7500 and have been trying for about two weeks to get it to work. I figure anything that takes two weeks to get working is broken beyond repair, and thus, expect no resolution. Firstly, I am running the debian installed version (from woody)... Version 4.1.0.1. [...] (--) PCI:*(1:0:0) ATI unknown chipset (0x5157) rev 0, Mem @ 0xe000/27, 0xed00/16, I/O @ 0x9000/8 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE (AGP) (II) Primary Device is: PCI 01:00:0 (EE) No devices detected. That XFree86 version is too old to recognize the card. The best idea is probably to look for a 4.2 or 4.3 backport for woody, e.g. as described in http://penguinppc.org/~daniels/README . -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xfree86 4.2 Radeon 9000 rv250 ig -no DRI
On Mit, 2003-03-26 at 17:43, GriSHka wrote: When I coment(#) dri in Section Module Loaddri all goes ok :-) but when not ,or in Section Device Option no_dri no my monitor is just shut down. What shall I do to make my Xfree86 work with DRI :-\ or how make my Accelerator work. Does this problem fix in Xfree86 4.3, have new X dri drivers for ATI Radeon 9000 This should work with 4.3. DRI on the 9000 wasn't supported in 4.2. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] clone and snoop under X-Windows
On Mon, 2003-03-24 at 17:14, Wunibald Karl wrote: I'm looking for an educational application to functionality, which I can embed into my application. I'd like to have a teacher snooping the students application windows or distributing it's own windows to the students application. I've looked at VNC, but this doesn't seem to give the granularity I'd like to have. I don't know if it will work better for you, but you could try x2x. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [XFree86(TM) Bug Report] No mouse suport for delllattitude with XFree86.4.3.0 none of the protocals work
On Sam, 2003-03-22 at 10:05, Joseph Rice wrote: Regarding: No mouse suport for dell lattitude with XFree86.4.3.0 none of the protocals work [...] (**) Option Protocol AceCad (**) Mouse1: Protocol: AceCad (**) Option CorePointer (**) Mouse1: Core Pointer (**) Option Device /dev/mouse (EE) xf86OpenSerial: Cannot open device /dev/mouse No such file or directory. No protocol can work with something that doesn't exist... Have you tried /dev/psaux with protocol auto, PS/2 or maybe ImPS/2 ? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Multi-Button mice
On Sam, 2003-03-22 at 11:00, Nigel Ridley wrote: I recently bought a 'Logitech Cordless Trackman Optical' which has 7 buttons plus a scroll wheel (which is clickable). I left my XF86Config-4 as-was (see below) and was suprised to see that some of the buttons work as expected. Section InputDevice Identifier Default Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol IMPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 Have you tried adding Option Buttons 7 here? (man 4x mouse) EndSection How do I know which number button corresponds to my 'drag lock button'? Numbers 1 2 are obviously left right, with number 3 being the 'middle' scroll wheel (there are two more buttons above and below the scroll wheel, 4 5?, which also scroll up and down). This then leaves the 'scroll lock' button (number 6?) and two more, which I think are for moving back and forwards thru web pages. xev will show you what number each button is. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 2D redraw speed
A description of the problem might help to get it addressed. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 2D redraw speed
On Sam, 2003-03-22 at 19:59, Tom Wesley wrote: On Saturday 22 March 2003 18:21, Michel Dänzer wrote: A description of the problem might help to get it addressed. :) I take it from your mail that for some reason the text of my mail didn't appear? Indeed, I only saw two attachments. The text wasn't in the message source either so I doubt it's an evolution bug. I have a Radeon 9000 graphics card and a 19 monitor. For some reason my screen refresh during normal operation (web browing email etc) seems very slow. Is there anything I can check to see why this is so? What operations are slow in particular? I've attached the XF86Config and output of xdpyinfo for review. The server log would be more interesting. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Dri-devel] Re: XFree86 bugzilla available
On Fre, 2003-03-21 at 21:07, José Fonseca wrote: No DRI developer expressed his interest or opposition, probably because there isn't opposition, or simply no interest. In either case I see no reasons why not proceed, so I'll open a bug to address this. I'll ask that [EMAIL PROTECTED] (the same addressed used on SF BT system) is set as the default owner for DRI bugs. I think it's a good idea but that dri-devel makes more sense than dri-patches. Also, what's the general mailing list one can subscribe to receive notifications everytime a bug is open? Currently [EMAIL PROTECTED] gets them all. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] ATI Radeon AIW 8500DV DRI video mode switch lockupXF86 4.3.0
On Mon, 2003-03-17 at 03:17, Donavan Pantke wrote: Alright guys, here's my situation: I have an ATI AIW 8500DV running XF86 4.3.0, using SuSE RPMS form the release. When I have DRI enabled on the card, I experience lockups when switching video modes. I can reproduce it with Alt-F? screen switches, but it takes a few tries to get that to happen. I can get it to happen right away by trying to run Diablo II using WineX. Symptoms are screen lockup with no keyboard response. When I disable DRI by commenting out the dri and glx modules, things are fine. As it also happens on VT switching, the fundamental problem is probably with stopping or starting the CP (Command Processor). I have no idea what could be wrong with that code though, it seems to work fine almost everywhere. Could be AGP chipset specific maybe. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
RE: [XFree86] Can't change hsync from 60Hz on secondary display -Radeon Mobility 9000 (M9)
On Die, 2003-03-18 at 18:02, Knutsen, Mark wrote: From: Michel Dänzer [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 11:43 AM On Mit, 2003-03-12 at 16:54, Knutsen, Mark wrote: I also tried setting the CloneVRefresh and DDCMode driver options, but that didn't change the results. What about the other CloneXXX options? (see http://xfree86.org/current/radeon.4.html if your X version doesn't have the radeon manpage yet) I tried adding: Option PanelOff Option CloneDisplay 2 Option CloneVRefresh 50.0 - 160.0 but, other than acknowledging the options, behavior and logfile output didn't change. What about the CloneMode and CloneHSync options? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] error message when starting
On Mon, 2003-03-17 at 21:09, jason wrote: I just upgraded to X 4.3.0 and in the process of debugging something else, I saw this error in my logs.. (EE) RADEON(0): Virtual height (0) is too small for the hardware (min 128) (EE) RADEON(0): No valid mode found for CRTC2 clone I searched google and it seems to be something wrong with the screens section? It seems that no matter what I specify in that section, X comes up with the same resolution. this is on an IBM T30 laptop. That log snippet is about the external output, are you trying to use that? It might be a good idea to post the complete log file or at least more snippets. Attached is the XConfig. Option CrtScreen is obsolete, and you shouldn't override the VideoRam, but those shouldn't cause problems. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Unreal Tournament/linux-2.4.20 Video lock up,then kernel freeze on stopping X4.3.0
On Die, 2003-03-18 at 00:24, Vivek wrote: On 16 Mar 2003, Michel Dänzer wrote: http://penguinppc.org/~daenzer/DRI/applied/r200-radeon-flushvertices.diff seems to help for a number of lockups, can you try it? I'm going to submit this for inclusion in the debs. No dice. Still locks up :( Bummer. Other things you could try: * set the environment variables RADEON_NO_CODEGEN, RADEON_NO_VTXFMT and RADEON_TCL_FORCE_DISABLE in this order to disable some driver features and see if that makes a difference * a snapshot from http://dri.sf.net -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] sample radeon7500 dual-head config?
On Mon, 2003-03-17 at 23:30, Trever Furnish wrote: I've stared at the radeon manual page from 4.2.99.902 for quite a while now and tried a few things, but I don't think I'm getting the config quite right to tell X that I want to use both ports of my dvi/vga radeon7500 in xinerama mode. Anyone have a working config file you could share? I'm not sure where to start. Cloning, which the radeon man page mentions, doesn't sound like what I want - I don't want identical output on two displays, but rather two displays treated as separate screens and combined using Xinerama. How are the screen and device sections supposed to be set up? Do I need two separate device sections? Two separate screen sections? If I need two device sections, how are they to differ? (I already tried just repeating the device section with different ID's, but it warns me that the busid is repeated and only uses one monitor.) You need to put Screen 0 in one device section and Screen 1 in the other. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] ATI Radeon AIW 8500DV DRI video mode switch lockupXF86 4.3.0
On Die, 2003-03-18 at 22:55, Donavan Pantke wrote: On Tuesday 18 March 2003 09:33, Michel Dänzer wrote: As it also happens on VT switching, the fundamental problem is probably with stopping or starting the CP (Command Processor). I have no idea what could be wrong with that code though, it seems to work fine almost everywhere. Could be AGP chipset specific maybe. Well, my hardware is running a AMD® 761 (569 BGA) northbridge chipset, and a VIA® VT82C686B (352BGA) southbridge chipset. It's a K Master motherbaord by MSI. I have heard of VIA northbrisge controller problems beofre, but not with the 761. I do seem to recall problems with some AMD chipsets, but I don't know anything specific. Any debugging clues? I can recompile from source if need be with debugging patches. I have nothing specific to suggest (does anyone else have good ideas?), tracking down where exactly the problem lies would be the first step. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Help ME!!!!
On Son, 2003-03-16 at 07:35, Omanno wrote: i have an powered by ATI Radeon 9100 does xfree86 have any support for it?? Yes, should work with 4.3.0. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: X 4.3 Freezes Computer when restarting
On Son, 2003-03-16 at 10:50, Ken Stanley wrote: On Sun, 2003-03-16 at 04:25, Tom Wesley wrote: On 16 Mar 2003, Ken Stanley wrote: When I try to restart X 4.3 my computer freezes completely after the screen goes blank. Something about X is not shutting down properly. I use Gnome 2.2, but it can't be that because this also occured when using twm as the window manager. What could cause X to behave this way? Are you using the framebuffer? That can sometimes freeze when leaving x. That's news to me. I don't believe so. The only frame buffer I know about is when I use the vga option from LILO -- and up until an hour ago I couldn't use LILO because my mainboard didn't recognize my hard drive. I flashed my BIOS to fix that, also in hopes to fix X somehow. Didn't fix X. But I did find out that it has no problem using a different video card/mainboard/cpu. Could it somehow be a conflict between the savage driver and GDM? No, but there tend to be problems on server reset because those code paths are only rarely tested in the drivers - see the recent threads about lockups on server reset with the radeon driver. Restarting the server instead of only resetting it usually works around these problems; for gdm, set AlwaysRestartServer=true in gdm.conf to achieve that. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Unreal Tournament/linux-2.4.20 Video lock up, then kernelfreeze on stopping X4.3.0
On Sam, 2003-03-15 at 21:54, Vivek Dasmohapatra wrote: Regarding: Unreal Tournament/linux-2.4.20 Video lock up, then kernel freeze on stopping X4.3.0 Email: [EMAIL PROTECTED] XFree86 Version: XFree86 Version 4.3.0 (Debian 4.3.0-0ds3v1a 20030314142755 [EMAIL PROTECTED]) [...] Video Card: pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x1002 device 0x5144 ATI Technologies Inc Radeon R100 QD [Radeon 7200] [...] Repeat By: This is probably tricky if you don't have Unreal Tournament: So far the thing has wedged in exactly the same place on the same level on UT 3 times, where it used to work under Xfree 4.1.0: When I get to a certain point on the morpheus level, the game jerks (which it does occasionally) and then just freezes: The keyboard and display seem completely locked, but I can still ssh into the machine from my laptop. At this point, my wm (fvwm), gdm and X are still running. However, X doesn't respond to TERM signals, and won't shut down normally. At this point, if I try to stop X with a KILL signal, the machine wedges hard: Nothing in the logs, corrupt file sytem, and a long boring fsck ahead. BTW, there is now a number of good journalling filesystems to choose from. http://penguinppc.org/~daenzer/DRI/applied/r200-radeon-flushvertices.diff seems to help for a number of lockups, can you try it? I'm going to submit this for inclusion in the debs. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
RE: [XFree86] Symbol xf86SetDDCproperties from module radeon_drv.o unresolved
On Son, 2003-03-16 at 20:44, Mathey, Nicolas wrote: Could it be an hardware problem ? Not necessarily, the video BIOS may simply not be laid out the way the driver expects. That's one reason why we don't want to rely only on the video BIOS in the long run, you could try http://www.penguinppc.org/~daenzer/DRI/radeon-ddc.diff . I applied this patch to the sources,all was ok during the patching. Are you sure? The patch was created against DRI CVS and may not apply cleanly to 4.3.0. But when I try to compile sources (and install them) I got an error on radeon_driver.o file: radeon_driver.c: In function `RADEONValidateCloneModes': radeon_driver.c:2975: warning: implicit declaration of function `RADEONDoDDC' radeon_driver.c:2975: warning: assignment makes pointer from integer without a cast radeon_driver.c: In function `RADEONRestoreCrtc2Registers': radeon_driver.c:4619: structure has no member named `IsDell' *** Error code 1 (continuing) So I can't get the new radeon_drv file patched... :( Do you know where my problems come from ? Looks like the patch wasn't applied correctly, maybe someone who's successfully using it with 4.3.0 can create a patch for you. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] ATI Radeon 7500 PCI : complete lock up when DRI is on
On Fre, 2003-03-14 at 04:38, Philippe Moutarlier wrote: I have 2 cards : ATI 8500 DV AGP and ATI 7500 PCI running RH 8.0 and Xfree from the HEAD as of today. Still trying to solve my dual head/dual card problem, I run into two problems : - if I try 2 cards simultaneously , the server dies with a signal 11 (see xfree_sig11.log) This may be the apparent current inability of the radeon driver to work with multiple cards, a backtrace would be interesting though. - if I try to run the PCI card only with DRI loaded (glx+dri), the box gets totally locked up and needs a hard reset. In this last case, could it be that the driver is still trying to use AGP mode to address the card ? Is there anyway to force PCI mode ? (I think I saw that option at some point, cannot remember where ...) I guess it's possible that it's confused by the AGP card and doing something silly without Option ForcePCIMode. The log after reboot is below (xfree_lock.log) It doesn't show the dri module being loaded though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] DRI disbled for on the Primary Head ??
On Sam, 2003-03-15 at 03:06, Philippe Moutarlier wrote: At last, I got my dual head working : but NOT with the ATI 7500 PCI. It worked right out of the box with an nVidia PCI, though. What's wrong with the radeon dirver and 2 ATI cards ?? It's called a bug. :\ Anyway, now I cannot get DRI on my Primary card with xinerama. Was not DRI supposed to work on the Primary Card in that config ? No, DRI isn't supported with Xinerama yet. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] ATI radeon kernel version mismatch
On Don, 2003-03-13 at 22:05, Philippe Moutarlier wrote: would you mind telling me where I cab find it ? http://www.xfree86.org/~alanh/ -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [blender 2.26cvs + XFree430] Total machinge lock
On Mit, 2003-03-12 at 05:33, Meino Christian Cramer wrote: From: Michel Dänzer [EMAIL PROTECTED] On Die, 2003-03-11 at 06:55, Meino Christian Cramer wrote: From: Michel Dänzer [EMAIL PROTECTED] oh yeah! The patch fixed it! Great...I am happy...! Great! ...before thinking ANY problem is solved: The crash due to opne a DispWin-window still remains working... I only meant: The script runs again! I still have to set export RADEON_NO_VTXFMT=1 to get renderings in a DispWin-window instead of DispView (directly on the screen)... I expected so, they're separate problems. The vtxfmt problem has been fixed in DRI CVS, it's a matter of someone extracting the fix and backporting it to 4.3. (please check the dri-devel archives and cooperate with Charl P. Botha [EMAIL PROTECTED] if you intend to) (I still dont understand what all these env-vars do. If a would have a problem I woulld set them all in a complete permutation pattern, which mean: I would be the monkey in front of the typewrite. And in opposite to the known example there would be no other monkey to produce a Shakespeare piece (= w orking setting)...so I would have to play all permutations alone You don't have to try all permutations as some variables encompass others (RADEON_NO_RAST encompasses RADEON_TCL_FORCE_DISABLE encompasses RADEON_NO_VTXFMT encompasses RADEON_NO_CODEGEN) and others only serve diagnostic purposes. just joking and playing with words, Michael! THIS IS NO CRITISM AT ALL! The only thing I would like is a more end-user understandable explanation of the settings. Fair enough, I'm not sure to what degree that's worth it though as they're mainly for debugging and working around bugs. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] DRM kerrnel modules - Archive Available ?
On Mit, 2003-03-12 at 04:54, Don Tanner wrote: I noticed on you page http://www.xfree86.org/~alanh/ that only one version / 1 file each for Linux and BSD are here. (the previous versions are allways removed) I would like to know if you have an archive available for the drm kernel modules tar balls. For Older versions of Xfree86 / kernels etc. We go to great lengths to preserve backwards compatibility, so the current DRM should work with XFree86 versions as of 4.1.0 at least (further back for some drivers). -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Out of Luck (tm) with ATI dual monitor ??
On Mit, 2003-03-12 at 17:31, Philippe Moutarlier wrote: Sorry to re-repost this but I never got any hints there. Could someone just tell me if this is just impossible ? What I would like to understand is what is going on : why 2 separately perfectly configured cards would not want to work together in multiple monitor layout. [...] (II) Loading sub module radeon (II) LoadModule: radeon (II) Reloading /usr/X11R6/lib/modules/drivers/radeon_drv.o (EE) Screen 1 deleted because of no matching config section. (II) UnloadModule: ati (II) UnloadModule: radeon A lot of effort has gone into support for multihead with a single card in the radeon driver. It seems that support for multiple cards may have been broken in the process. Might be easy to fix for someone with multiple cards though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] glx error after upgrade 4.2-4.3
On Die, 2003-03-11 at 19:06, Razvan Cosma wrote: On Tue, 11 Mar 2003, Michel Dänzer wrote: On Die, 2003-03-11 at 14:25, Razvan Cosma wrote: I had a perfectly working system (wolfenstein, mplayer etc) but hey, couldn't resist the temptation :) What I get now at startup is very puzzling, digging the google did not show at least one ocurrence of this error: GLX: Creating new client: 1! GLX: Creating new client: 2! ... GLX: Creating new client: 13! GLX: Too many clients! I also get a Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved! Where does the glx module come from? Doesn't look like it's the one that ships with XFree86 and is required by the DRI. The log would be interesting if you can't fix this yourself. aargh, but I have tried xfree without all the 3rd party stuff, and got no (illegal, wow) antialiased tt fonts and also no 3d. So let's see what I've caused to my system: 1085679 utah-glx-src-latest.tar.gz [...] (II) LoadModule: glx (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so (II) Module glx: vendor=Utah-GLX compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.1 (II) Loading extension GLX This is the Utah-GLX glx module, move it out of the way. The XFree86/DRI one is called libglx.a. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [blender 2.26cvs + XFree430] Total machinge lock
On Die, 2003-03-11 at 06:55, Meino Christian Cramer wrote: From: Michel Dänzer [EMAIL PROTECTED] oh yeah! The patch fixed it! Great...I am happy...! Great! David*, will you keep merging fixes from the DRI mesa-4-0-4-branch, or should I submit a patch? When I do understand, what is all behind the possible settings given in dri_driver_features.phtml I will try to use them... No need to play with them when things are working? :) * David Dawes -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
