Re: [Xpert]adding radeon driver documentation
On Wed, 24 Jul 2002, hy0 wrote:
Actually, the value of this option is processed in this switch
statement:
switch (info-agpMode) {
case 4: mode |= RADEON_AGP_4X_MODE;
case 2: mode |= RADEON_AGP_2X_MODE;
case 1: default: mode |= RADEON_AGP_1X_MODE;
}
As you can see, anything except 2 and 4 will set 1x. Even 4 and 2 may
fall back to lower transfer rates depending on the capabilities of the
chip and the AGP bridge. agpgart handles that.
There is no break in above switch statement. 3 LSBs will fall through.
If agpMode=7, 7 will be passed to the agpgart driver. This is not a bug,
agpgart driver
(see agpgart_be.c) will use the highest bit according to AGP bridge's
capability.
That's why I said if you use AGPMode = 3, you'll end up with 2x.
There is no beak, but there is no fall through for 7 or 3:
agpMode mode
7 1
6 1
5 1
4 7
3 1
2 3
1 1
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]void driver?
On Thu, 25 Jul 2002 [EMAIL PROTECTED] wrote: Section InputDevice Identifier DummyKeyboard Driver void EndSection where can i get the void driver for the dummykeyboard? Or is it already installed? I searched in /usr/X11R6/lib/modules/drivers but there is no void_drv.o file. It is an input driver, so lives in /usr/X11R6/lib/modules/input/void_drv.o -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Nec MultiSync LCD 1810X - rotation
Hello -- I have a Nec MultiSync LCD 1810X which is a monitor capable of turning 90degrees so you get a A4 size screen... very handy for checking an actual layout... I know that there is software for widows called Pivot Pro, but I have not found any for Linux.. or any clues as to how it would work. I do know that the IPaQ can do the changing of orientation of the screen. Does anyone have this working? or have an idea on where to start? Thanks Aukjan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]void driver?!!
Section InputDevice Identifier Keyboard0 Driver keyboard EndSection Section InputDevice Identifier DummyKeyboard Driver void EndSection when i'm trying to start with the void driver the kde setup hangs up. by the time, when the initializing peripherals setup is doing, it stands still and i have to reboot the system. what's going wrong? i'm using xfree86-4.1.0, is this the reason? -Thorsten ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Press Button in a remote application.
Hello, I need to make a function that presses a button of an application from its name. For example an application has the buttons ok and cancel. I need, from my function, it sends the press event to one of the buttons from its name, SendButton (display, name_button). I don't know how X-window manage buttons, I suppose like a window, but I don't know how I can press a button from its name. I use XSendEvent but I don't know how to locate the correct button. Somebody can give me any idea? Thank you very much. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Nec MultiSync LCD 1810X -- rotate
Sorry posted this as a reply... here we try again.. Hello -- I have a Nec MultiSync LCD 1810X which is a monitor capable of turning 90degrees so you get a A4 size screen... very handy for checking an actual layout... I know that there is software for widows called Pivot Pro, but I have not found any for Linux.. or any clues as to how it would work. I do know that the IPaQ can do the changing of orientation of the screen. Does anyone have this working? or have an idea on where to start? Thanks Aukjan -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
On Thu, 2002-07-25 at 08:50, Dr Andrew C Aitchison wrote:
On Wed, 24 Jul 2002, hy0 wrote:
Actually, the value of this option is processed in this switch
statement:
switch (info-agpMode) {
case 4: mode |= RADEON_AGP_4X_MODE;
case 2: mode |= RADEON_AGP_2X_MODE;
case 1: default: mode |= RADEON_AGP_1X_MODE;
}
As you can see, anything except 2 and 4 will set 1x. Even 4 and 2 may
fall back to lower transfer rates depending on the capabilities of the
chip and the AGP bridge. agpgart handles that.
There is no break in above switch statement. 3 LSBs will fall through.
If agpMode=7, 7 will be passed to the agpgart driver. This is not a bug,
agpgart driver
(see agpgart_be.c) will use the highest bit according to AGP bridge's
capability.
That's why I said if you use AGPMode = 3, you'll end up with 2x.
There is no beak, but there is no fall through for 7 or 3:
agpMode mode
7 1
6 1
5 1
4 7
3 1
2 3
1 1
Exactly, and then agpgart picks the highest set bit from mode which is
supported by the chip and the bridge.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
On Wed, 2002-07-24 at 19:47, hy0 wrote: On Tue, 2002-07-23 at 22:54, hy0 wrote: If you set ForcePCIMode on any other architecture, DRI support will be disabled. (FIXME: I'm probably misunderstanding this option. How would one force an AGP Radeon card to work on the PCI bus? Or a PCI Radeon card (are there any?) to work on the AGP bus? Are there dual-bus integrated Radeon cards floating around, which can sit on either the PCI or AGP bus?) For AGP board, you can force it to use PCI GART instead of default AGP GART. This option can be used in following cases: (1) You have a PCI card. PCI GART will be used automatically in that case. That's what I thought when I tried this a few months ago, but it turned out not the case. When I tried a PCI 7500 on a x86 machine with dri-tnl branch code, I was expecting RADEONDRIAgpInit to return FALSE and the driver to fall back to PCI mode. But amazingly, it went through RADEONDRIAgpInit successfully (on a PCI board!) and treated the board as an AGP board with DRI enabled. The driver went through all mode initialization stuffs correctly, and of course, finally locked up when trying to do some accelerated 2D drawings. When I used ForcePCIMode option, I got DRI working correctly on that PCI board. It only failed after I played some 3D games for a while, the cause of failure might not be PCI gart related after all (I didn't look into it). In addition, I also got the pcigart worked with an AGP 7500 board on that x86 system. To automatically identify a Radeon PCI card, the PCI subsystem ID (not device id) has the info. But this is not implemented in the current driver. If we can't figure out a more general and reliable way to identify a PCI card (there should be), this method (subsystem ID) can be used. Yes, I should have said 'should' instead of 'will'. :) That's how it's supposed to work and how it works in the r128 driver. (2) You have an AGP card, but the agpgart kernel driver doesn't support the AGP bridge chipset on your motherboard. Ditto. (This has pros and cons which have to be considered carefully) (3) The AGP GART doesn't work correctly. I'm not sure the current status of pcigart support. It didn't work reliably a few month ago. Still doesn't seem to work on x86 but works fine on alpha and powerpc at least. Weird. As said above, I actually got it worked on a x86 system with both PCI and AGP 7500 card, just not sure how reliably it works on all other systems. I was suggesting we should consider enabling it on the dri-devel list, as we could get rid of some ugly code if we did. Unfortunately, Charl P. Botha encountered a lockup on server startup when he tried it on his notebook with an M7. I still think we should consider carefully if we want to document these options. IMO, this is a very useful option, especially when a lot of systems appear to have stability problems with AGP gart. Like the VT switching lockup problem on some systems, this option is worth to try (you may need to enable PCIGART_ENABLE compile option first in both 2D and kernel drivers). Well, we seem to have fixed the VT switching problems. And most other AGP problems I've seen seem to be related to high transfer rates or special features like Fast Writes. Comparing to using AGP gart, using PCI gart might slow things down by 20-30% in 3D applications, it's still a good option if your agp gart doesn't work reliably. You're probably right, my concerns are mainly about the CP related options. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Xpert digest, Vol 1 #2013 - 11 msgs
On Tue, 16 Jul 2002, David Dawes wrote: Date: Tue, 16 Jul 2002 10:06:53 -0400 From: David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: Xpert digest, Vol 1 #2013 - 11 msgs On Mon, Jul 15, 2002 at 02:43:04PM +0200, Xavier Bestel wrote: Le lun 15/07/2002 à 14:20, Mike A. Harris a écrit : what you are asking for is the RandR (Resize and Rotate) extention. This extension is implemented already, and support for it is available in the kdrive X server included with XFree86. The core server simply has not had RandR functionality added yet. It isn't funded development, so it will be done whenever someone cares to do it and has the time. I'm interested in working on it, but it hasn't been priority one for me yet. IIRC Mark said the API between the core server and the drivers doesn't allow for RandR to be implemented. Most of the Resize part could probably be implemented within the current driver API, but as Mark said, a fully featured implementation is probably better targetted for XFree86 5.0. Resize is what I'm interested in, and have discussed with Keith a few months back. The only thing preventing me from working on it is a busy schedule... The rotate and depth stuff doesn't interest me at least not currently. It will be nice to have when it happens though. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]void driver?
On July 25, 2002 01:08 am, [EMAIL PROTECTED] wrote about [Xpert]void driver?: Section InputDevice Identifier DummyKeyboard Driver void EndSection Does the void driver still try to allocate a VT? Can it be used on the XServer where the second XServer is configured for a secondary video card, without messing with the first video card/console? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: Xpert digest, Vol 1 #2013 - 11 msgs
Around 17 o'clock on Jul 25, Rob Taylor wrote: What needs to be implemented for Resize to work? I have a few spare cycles i could donate... (I'm read most of the server code base at one point or other and submitted patches before (tho i'm still waiting to hear from a developer on those...)) As a first hack, all that's really needed is to hook the RandR reconfiguration function up to the existing size switching code in the XFree86 DDX. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
Attached is a modified rootv.c file - this should do the trick. I tested it on my ATI AIW radeon and it works OK. The window sizes and everything are all hard coded, but you can change this stuff to suit your needs and see how it works. The encoding is also hard coded to the number that the ATI driver uses for NTSC composite - you can figure out which number this is for your brooktree board by using xvinfo. Yup, checked that and chanded it accordingly. I tested it with all Xv ports which i assumed to correspond to the video devices i have (which seems to be a wrong assumption because of the results i got). Anyway - if i start the program it displays some image but it is half offscreen and half set to the side, as a completly misconfigured overlay and looks pretty close to the overlay (guessed upon the coloring as xv images have a slightly darker gamma than overly here). The video is display for some seconds and then it locks up for some seconds and the process repeats. After launching the app the X server is no longer responsive and often can not be restarted cleanly at all. In short - it does not work. (BTW - i think you mixed up the order of some of the parameters of the XvPutVideo() call in that modified rootv.c). Any more ideas? Eventually i can test it with a system with an Nvidia card to see if it works anything different... Not sure I completely understand you here, but any program can use the XvPutVideo() call. There are various reasons why the author of xawtv chose Just to go for sure - i guess the XvPutVideo call is not just an X-server integrated version of the overlay+clipping functionality like xawtv does? I mean - it really uses graphics hardware for colorspace+stretching? XvShmPutImage instead - in my experience, this call is usually used to display frames one at a time in quick succession (such as in an MPEG-2 decoder). Exactly, and in the case of xawtv (and my kvdr) i use it to display consecutive grabbed frames which works but with the mentioned limitations. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Recommendations for card with DVI support (1600x1200)
After reading the mailing list archive for the last half year or so, I am now even more confused than before. I am looking for a graphics card that allows me to drive my Dell flat panel display at 1600x1200 using the DVI interface. Apparently, my initial choice of a Matrox G550 was a poor decision as this card cannot drive DVI at more than 1280x1024 (I now need to find out what my vendor's return policy is...) Ideally, I am looking for a solution that is supported by open source X11 drivers, but I am willing to settle for closed source ones if that is my only option at this time. While Debian Linux only ships XF86 4.1.0, I wouldn't have any problems with compiling a CVS snapshot and/or applying external patches. I don't require 3D acceleration, but would prefer rock-solid 2D operation. As the screen was expensive enough, a card in the $100 (or less) range would be preferable. If the card can simultaneously drive a second analog monitor, that would be a bonus, but I guess I can always plug in an old PCI graphics card. If I receive multiple different suggestions, I promise to write a summary on my experiences once I get everything to work. I would guess that with the price for large LCD panels dropping, this might turn into an FAQ. Markus P.S.: I earlier tried sending this e-mail using a slightly different return address; it is now pending approval by the list administrator. So, if you eventually see a duplicate post, then I would like to apologize for it. -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Recommendations for card with DVI support (1600x1200)
On Thu, 25 Jul 2002, Markus Gutschke wrote: After reading the mailing list archive for the last half year or so, I am now even more confused than before. I am looking for a graphics card that allows me to drive my Dell flat panel display at 1600x1200 using the DVI interface. Apparently, my initial choice of a Matrox G550 was a poor decision as this card cannot drive DVI at more than 1280x1024 (I now need to find out what my vendor's return policy is...) Ideally, I am looking for a solution that is supported by open source X11 drivers, but I am willing to settle for closed source ones if that is my only option at this time. While Debian Linux only ships XF86 4.1.0, I wouldn't have any problems with compiling a CVS snapshot and/or applying external patches. I don't require 3D acceleration, but would prefer rock-solid 2D operation. As the screen was expensive enough, a card in the $100 (or less) range would be preferable. If the card can simultaneously drive a second analog monitor, that would be a bonus, but I guess I can always plug in an old PCI graphics card. If I receive multiple different suggestions, I promise to write a summary on my experiences once I get everything to work. I would guess that with the price for large LCD panels dropping, this might turn into an FAQ. If you're willing to run with CVS, the nv driver can drive that panel depending on which TMDS controller it has on board. The nv driver doesn't support dual head though so you won't be able to hook up two monitors to it. Of course, it works with the binary closed source drivers. The GeForce2 MX cards should be in your price range and possibly the GeForce4 MX on the high end of it. You have to make sure to pay attention to what DVI resolutions the particular card supports as it depends on the TMDS controller and different vendors use different ones. The builtin TMDS controller on GeForce4 MX isn't capable of driving that panel, so only the higher-end boards with external TMDS controllers will be able to do the job. If you have a particular vendor's card that you are interested in, let me know and I can try to round one up and verify that the nv driver works fine with that panel (the Dell 2000FP ?). Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]colormap and bit-depth problems
Hi, I'm running an app that requires 8-plane depth, and am having some trouble. When I display it on a Solaris box running 24-plane depth, it automatically selects an 8-plane visual to run in, and everything is great. When I try to display it under XFree86 running 24-plane depth, it can't find an 8-plane visual, and crashes. I'd really like to avoid having to run 8-plane depth. I'm far from knowledgable when it comes to X visuals, but I dug up the following. Here's the pertinent (I think) output from xdpyinfo on the Solaris box: name of display:unix:0.0 version number:11.0 vendor string:Sun Microsystems, Inc. vendor release number:3610 maximum request size: 262140 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, MSBFirst, 32 image byte order:MSBFirst number of supported pixmap formats:3 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 132 focus: window 0x54d, revert to Parent number of extensions:27 AccessX ... ... default screen number:0 number of screens:1 screen #0: dimensions:1920x1200 pixels (541x338 millimeters) resolution:90x90 dots per inch depths (3):1, 8, 24 root window id:0x37 depth of root window:8 planes number of colormaps:minimum 1, maximum 5 default colormap:0x34 default number of colormap cells:256 preallocated pixels:black 1, white 0 options:backing-store YES, save-unders YES largest cursor:64x64 current input event mask:0x58003d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask number of visuals:16 default visual id: 0x20 visual: visual id:0x20 class:PseudoColor depth:8 planes available colormap entries:256 red, green, blue masks:0x0, 0x0, 0x0 significant bits in color specification:8 bits visual: visual id:0x21 ... The significant difference (once again, I think) that I see between this and the same output on the box running XFree86 is: number of colormaps:minimum 1, maximum 1 on the XFree86 box, instead of: number of colormaps:minimum 1, maximum 5 on the Solaris box. #1 Is this the problem, and if so how do I set the maximum to higher than 1? #2 If this is not the problem, what is, and how can I fix it? Thanks in advance, Russ -- === = Russ E Radke = (970)206-5855 = = Analog Design Engineer= (970)206-5260 FAX = = LSI Logic = [EMAIL PROTECTED] = === ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
I tested it with all Xv ports which i assumed to correspond to the video devices i have (which seems to be a wrong assumption because of the results i got). You'll note that the software picks the first port that it finds which matches both the XvInputMask and XvVideoMask (ie - it supports putVideo - can be verified using XvInfo). So, if you have multiple cards that support this, you'll always get the first one unless you modify it. Anyway - if i start the program it displays some image but it is half offscreen and half set to the side, as a completly misconfigured overlay and looks pretty close to the overlay (guessed upon the coloring as xv images have a slightly darker gamma than overly here). The video is display for some seconds and then it locks up for some seconds and the process repeats. After launching the app the X server is no longer responsive and often can not be restarted cleanly at all. In short - it does not work. (BTW - i think you mixed up the order of some of the parameters of the XvPutVideo() call in that modified rootv.c). I didn't actually write this It looks OK to me - from the man page: XvPutVideo(dpy, port, d, gc, vx, vy, vw, vh, dx, dy, dw, dh) Display *dpy; XvPortID port; Drawable d; GC gc; int vx, vy, dx, dy; unsigned int vw, vh; unsigned int dw, dh; You could try making the last 8 numbers 0,0,640,480,0,0,640,480 ... It was set for 240 because of some deinterlacing junk for the ATI card I was working with at the time - this could cause you issues. Any more ideas? Eventually i can test it with a system with an Nvidia card to see if it works anything different... Not sure I completely understand you here, but any program can use the XvPutVideo() call. There are various reasons why the author of xawtv chose Just to go for sure - i guess the XvPutVideo call is not just an X-server integrated version of the overlay+clipping functionality like xawtv does? I mean - it really uses graphics hardware for colorspace+stretching? As far as I understand, yes - this actually uses the graphics hardware to do colorspace conversions and overlays... (the hardware gurus can correct me here if I'm wrong). Try changing those numbers and see how it works What is the exact hardware you're using again (framegrabber card and VGA card) Perhaps if you post the output of xvinfo I could have a look to see if I can help solve your problem Mark ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Recommendations for card with DVI support (1600x1200)
On Thu, 25 Jul 2002, Markus Gutschke wrote: I am looking for a graphics card that allows me to drive my Dell flat panel display at 1600x1200 using the DVI interface. Apparently, my initial choice of a Matrox G550 was a poor decision as this card cannot drive DVI at more than 1280x1024 (I now need to find out what my vendor's return policy is...) I don't know whether it will do 1600x1200, but I am driving a 1600x1024 panel from the DVI interface on my G550. I use CVS XFree86 (I'm not sure whether 4.2 would work) with the XFree86 supplied mga driver, but I have to (or did last time I checked) use the Matrox supplied mga_hal_drv.o. I have heard that other people can only get the DVI interface to driver their panels if the *don't* use mga_hal_drv.o -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]colormap and bit-depth problems
On Thu, 25 Jul 2002, Russ Radke wrote: I'm running an app that requires 8-plane depth, and am having some trouble. When I display it on a Solaris box running 24-plane depth, it automatically selects an 8-plane visual to run in, and everything is great. When I try to display it under XFree86 running 24-plane depth, it can't find an 8-plane visual, and crashes. I'd really like to avoid having to run 8-plane depth. The significant difference (once again, I think) that I see between this and the same output on the box running XFree86 is: number of colormaps:minimum 1, maximum 1 on the XFree86 box, instead of: number of colormaps:minimum 1, maximum 5 on the Solaris box. No, the number of colormaps isn't the problem (and I don't know any PC hardware with more than one* colormap). If your hardware runs with the mga, glint or ct driver, they you are in luck. These drivers support the option Overlay with give you 24 and 8 bit visuals (mga and glint) or 8 and 15 bit (ct). *Some* other hardware (some S3 cards with the right RAMdacs) could support overlays, but most other PC cards don't have the hardware to allow two different visual depths at the same time. (* Actually I would say that anything running XFree86 with overlays is providing one and a half colormaps - one programmable and one fixed.) -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
There is no beak, but there is no fall through for 7 or 3: agpMode mode 7 1 6 1 5 1 4 7 3 1 2 3 1 1 Exactly, and then agpgart picks the highest set bit from mode which is supported by the chip and the bridge. My bad. I was looking at the code I modified a while ago for debugging agp fast write. It let all valid bits to pass through (including bits for FW and SB) to agpgart driver. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Recommendations for card with DVI support (1600x1200)
There was a problem with certain panels working at high pixel clock (typically at 1600x1200) on a Radeon board. It has been fixed in the current CVS code. If you just want to give it a quick try, I can send you the binary driver off the list. Hui I'm currently staring at RH7.3 on a ViewSonic VP201mb (1600x1200) attached to the DVI port on an ATI Radeon 7500. Xscreensaver seems to occasionally tickle an Xserver bug (every few weeks), but I haven't had a chance to investigate, so I don't know whether it is a core or driver issue. I haven't seen it on my Matrox G450 yet, but I just upgraded that machine. Might be fixed upstream already ... I need to check the changelog. Regards, Bill Rugolsky ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
