Re: RELNOTES for 4.3.0
On Sat, 2003-02-22 at 13:11, Mike A. Harris wrote: No problem. It's possible the option you used worked around the problem. I found the true problem yesterday though (whew). ;o) Heh.. I spoke too soon yesterday. When I tried the new packages, I merely restarted XFree86. Today, the machine locked after a full reboot. It works with ForceInit, but not without, even with the newer packages. Sorry for the confusion. Whoa, deja vu. After you mentioning DPMS on DFP, I decided to have a look at the DPMS code in the radeon driver, and the R200 specs. I just implemented DPMS on Radeon yesterday for DFP/LCD, but also noted the existing DPMS code looks a bit more complex than it needs to be, so I'm going to take a stab at rewriting Radeon DPMS support after 4.3.0 is out, using the documented DISP_PWR_MAN_DPMS instead of the current mechanism. The patch above is similar to what I've written, but still incomplete. I've had several people test my latest Radeon driver out with DPMS on CRT alone, LCD alone, DFP alone, and combination of CRT+LCD and CRT+DFP, but not on dual DFP (they're more rare). I'll probably send my DPMS patch in for potential 4.3.0 inclusion, but if it doesn't get in, then it's on my ftpsite for those interested. Sweet. Looking forward to it. Jeff -- Jeff Brubaker [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Fri, Feb 21, 2003 at 04:06:57AM -0500, Mike A. Harris wrote: I've got a minimum of 5 bug reports stating that Savage MX/IX is broken in CVS XFree86 completely, and I've got at least 15 users begging me daily for fixes. I have been in contact with Tim Roberts about these issues, and his latest driver 1.1.27t fixes these issues. I didn't say the driver in CVS XFree86 was broken on this hardware for no reason. It may perhaps work for some users, but it is definitely broken for many. It is rare that I get more than 3 or so users report any particular XFree86 issue. Since users testing Tim's binary driver report that it fixes the problems for them, I have updated Red Hat XFree86 4.2.99.902 packages with Tim Robert's latest 1.1.27t driver, and patched in the 1.1.26t-1.1.26 CVS changes on top of it, however I have not gotten feedback from the users who have reported the driver being broken as to wether the new driver in our packaging works for them yet or not. If my latest build does work, then I was going to recommend that the savage driver be updated to 1.1.27t in CVS prior to 4.3.0, but if it does not work, then some change that went into XFree86 CVS on top of 1.1.26t broke support for these chips. Sorry - I didn't mean to imply that the driver was fine and you were wrong. I was merely suggesting that there was a workaround that fixed the problem for me(tm). The driver didn't work at all for me until I tried that option. Thanks for the notice on the packages. I'll install them this weekend and let you know the results. In other news, DPMS is still broken on my Radeon VE - Flat Panel (DVI). I don't have a DVI panel, or I'd have a look at that. Perhaps Hui or someone can take a stab at it though. Or, send me a DVI panel. ;o) There was a suggested patch sent to xpert, but I don't know what happened as a result: http://www.spinics.net/lists/xf-xpert/msg08069.html Jeff ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Fri, 2003-02-21 at 11:02, Jeff Brubaker wrote: Thanks for the notice on the packages. I'll install them this weekend and let you know the results. Mike, I've upgraded from XFree86-4.2.99.901-20030209.1 to XFree86-4.2.99.902-20030218.3 and I can now start X without the ForceInit option. Thanks for the update. :) Jeff -- Jeff Brubaker [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Xpert]XFree86 CVS and 1600x1024 (DVI) / Radeon
Wonderful. The reason I never saw the post was that my delivery was disabled for the list. I was wondering why my XFree86 mail folder was rather light lately. :-/ This must automatically happen when my mail server starts bouncing messages when the quota gets exceeded. Anyway, here's answers to the replies I found on the web archives: Keith Packard wrote: Hmm. The Radeon driver mode selection code was restructured during the RandR integration, it's quite possible that some mode lines aren't getting properly added. But, your log file seems to list 1600x1024 as a valid mode, so I'm a bit confused. What does 'xrandr' list as valid sizes? The log you enclosed showed the screen running at 16bpp; I assume setting the depth to 24 switches that to 32bpp? Yes, lately I've been running at 16bpp due to the lack of benefit in the higher bit plane modes. I've attached a 24 bit log file. During this session, I verified that pixmaps do have quite a bit of color banding, more so than other 24bit displays. It did push the fbbpp up to 32bpp. Note that this is DVI-DFP. It could be hardware limited, but I can't verify this (there's nothing but Linux on this machine). I've also attached output of some xrandr commands. This required rebuilding xrandr without any opt flags. The executable built with standard opt flags (none specified by myself, I only specified ProjectRoot) refused to interpret any arguments. This is likely due to using gcc 3.2 (RH8). Also note that it lists 1600x1024 as the active mode. The root window is indeed 1600x1024, but the image my SGI is getting is definately 1280x1024. Dr Andrew C Aitchison wrote: When I was looking for a dvi card for my SGI 1600SW, I thought I read that the Radeon didn't official support that resolution; maybe the driver now supports the resolution limit on the card :-( It seems to work quite well here. As distributed with RH8, XFree86 came up at 1600x1024 without needing a modeline. Previously, I used the following: Modeline sgi1600x1024 106.9 1600 1632 1656 1672 1024 1027 1030 1067 That log file says that the config file requested 16bpp :-) Yes, I've been running 16bpp due to the fact that it looks exactly the same as 24bpp. :-) 24bit log file attached. It also says that it is using the DAC in 6bit mode, which would not help. Hrm.. here's the 24bit log. It's listed as 8bit here, but there's still considerable color banding. Jeff This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 15 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-xfs i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Mon Oct 21 22:23:40 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Radeon VE (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6-CVS/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6-CVS/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6-CVS/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI:
[Xpert]XFree86 CVS and 1600x1024 (DVI) / Radeon
I tried to send this a few days ago but it looks like it may not have made it (never saw it come back across the list), so I'll try again. Apologies if it actually made it. With the flurry of commits over the last few weeks, I figured it would be worth installing XFree86 CVS and check out RandR, Xcursor and the new ATI acceleration. Unfortunately, X comes up with a root window size of 1600x1024 (reported by xdpyinfo) but is really only outputting 1280x1024 (reported by my SGI MultiLink adapter). All of this flows through a Radeon VE to my SGI 1600SW flat panel (DVI). Any ideas? Oh, and just to put every question in a single e-mail, thus making it difficult to find in mailing list archives, even in 24bpp, pixmaps appear to be 16bpp. My web page, for example, looks substantially different between my S3 based notebook in 24bpp and my Radeon VE based desktop in 24bpp. Is there a pixmap depth limitation in the radeon driver? I've attached the usual XFree86 logs for completeness. Jeff This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 15 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-xfs i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Thu Oct 17 23:48:57 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Radeon VE (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6-CVS/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6-CVS/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6-CVS/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1130 card 1043,8027 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1131 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1043,8027 rev 01 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 1043,8027 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 1043,8027 rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 1043,8027 rev 01 class 0c,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5159 card 1002,013a rev 00 class 03,00,00 hdr 00 (II) PCI: 02:0a:0: chip 11ad,0002 card 1385,f004 rev 20 class 02,00,00 hdr 00 (II) PCI: 02:0c:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1
[Xpert]XFree86 CVS and 1600x1024 (DVI) / Radeon
With the flurry of commits over the last few weeks, I figured it would be worth installing XFree86 CVS and check out RandR, Xcursor and the new ATI acceleration. Unfortunately, X comes up with a root window size of 1600x1024 (reported by xdpyinfo) but is really only outputting 1280x1024 (reported by my SGI MultiLink adapter). All of this flows through a Radeon VE to my SGI 1600SW flat panel. You can physically move windows off the visible screen, so the allocated root window is probably actually 1600x1024. I also manually defined the 1600x1024 modeline, which I grabbed from an old Mark V post in the archives, and XFree86 SEGV'd. Any ideas? I also noticed that xrandr died with BadParameter errors for anything other than changing the screen resolution. I'm guessing the ATI driver needs updating to handle the new extension. Oh, and just to put every question in a single e-mail, even in 24bpp, pixmaps appear to be 16bpp. My web page (in Mozilla), for example, looks substantially different between my S3 based notebook in 24bpp and my Radeon VE based desktop in 24bpp. Is there a pixmap depth limitation in the radeon driver? I've attached the usual XFree86 logs for completeness. Note that this is on RH8, gcc 3.2. Jeff This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 15 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-xfs i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Thu Oct 17 23:48:57 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Radeon VE (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6-CVS/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6-CVS/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6-CVS/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1130 card 1043,8027 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1131 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1043,8027 rev 01 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 1043,8027 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 1043,8027 rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 1043,8027 rev 01 class 0c,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5159 card 1002,013a rev 00 class 03,00,00 hdr 00 (II) PCI: 02:0a:0: chip 11ad,0002 card 1385,f004 rev 20 class 02,00,00 hdr 00 (II) PCI: 02:0c:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0
[Xpert]Disabling video card stored pixmaps
A few months ago I asked about slow XCopyArea() calls and the response was that they were due to having one pixmap in the video card's memory and one in system memory. Switching all pixmaps to shared memory pixmaps fixed the problem. Now, we need a remote capable solution. :) Would something as simple as specifying the amount of video ram to be only slightly higher than the fbbpp * resolution be valid or would this screw up hardware cursor and other things? Ideally, we'd like to fix this on the client (code), but a server side hack is not out of the question. Any ideas? Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Disabling video card stored pixmaps
On Mon, 2002-07-01 at 16:59, Mark Vojkovich wrote: Option XaaNoOffscreenPixmaps Thanks, Mark! Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Slow XCopyArea
On Wed, 2002-04-17 at 16:51, Mark Vojkovich wrote: Unfortunately, the second XCopyArea is incredibly slow and I'm getting just under 1 fps. (normal without it) This trick works fine on most Sun X servers, but seems to die with XFree86/Linux IA-32. Pixmaps may or may not go in video ram. Depending on the operations involved it may be faster being in one place or the other. Generally, if everything is video memory it's fastest, but that may not always be possible. When some buffers are in video ram and some aren't, moving data back and forth between them can be slower than if everything were in system ram. Usually, this situation doesn't occur so it's a good policy to stick everything that you can in video ram. Mark, this did the trick. Thanks! Jeff -- Jeff Brubaker - [EMAIL PROTECTED] - http://jeffro.net/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
