Re: [Xpert]A big confusion over here - XFree 4.2 - and rage 128
On Wed, 2002-02-20 at 00:17, Gustavo Homem wrote: I am having serious trouble with XFree. I have a rage 128 video card. I was using XFree 4.1 from mdk 8.1 and the Xv extension was malfunctioning for DVDs (was ok for other movies). It would eat too much CPU so a lot of frames were dropped (tested with xine, vlc and mplayer), for example xine would take around 45 % and the X server about 45% using Xv output. I upgraded to XFree 4.2 rpms from mandrake in hope to have this problem solved since it was working perfectly on XFree 4.03 from mdk 8.0. I can only guess why 4.0.3 worked better than 4.1.0; I guess it's because the r128 driver in 4.0.3 didn't properly support 420 video (or was it 422? I forget :) yet. X complained then about drm modules beiing old, so I downloaded the latest one from dri.sf.net , compiled and instaled the module at /lib/modules/ The result was as follows with dri enabled: 1 - Now bttv no longer freezes the system if used with dri enabled (hooray) 2 - The KDM login screen is completely messed (widgets are garbaged, not drawn properly) I have fixed this in DRI CVS and submitted the fix to XFree86. Both 1) and 2) are due to the fact that the r128 driver does 2D acceleration differently with DRI enabled now. I'm sure you've also noticed the better 2D performance. :) 3 - This is the weird part: Xv is messed, the colors don't match the real ones, they are completely changed and there is an horizontal strip with a diferent color variation with xine and a lot of garbage with mplayer, X freezes a short time after switching to and from fullscreen (except for the mouse). Strangely during the time before X freezes there are no framedrops but they come back with dri disabled. What is exactly the relation of Xvideo and dri ? They are conceptually independent, however as of 4.2.0, the r128 driver tries to take advantage of the DRM to accelerate Xv image transfer. Unfortunately, this doesn't work well with some chips, and there are also problems coordinating this with the new 2D acceleration yet. Until these issues are sorted out, use of the DRM for Xv should be an option which defaults to off. I'll submit a patch to that effect soon. Attached is a hack which disables it completely in source for now. I hope this is useful for people who are bitten by this. -- 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]i810, XFree86: vertical bars on screen
Greetings. I am currently running XFree86 4.1.0 on Linux 2.4.17 (Debian unstable). My system is based around the Intel 815 chipset (Pentium 3, 933 MHz). Afterstep window manager, with a 16 bit color depth. Every so often, I get vertical bars appearing on my screen when I move a window around. These bars are 12 pixels wide, and tend to be separated by 116 pixels (hmm. Interesting figures...) Depending on where the window being moved is, the location at which the bars appear may move across 64 pixels. (Sorry, I can't tell you the offset from the side of the screen. Oops.) The bars do *not* appear automagically -- they appear only when I move a window around on screen (or move to a different part of the virtual screen provided by AfterStep) -- and not even all the time then. It *seems* to be related to having a large number of gtk-based windows open, but I can't swear to that; I can't reliably reproduce the problem. :-( Does anybody have any suggestions? Or am I going to end up spending a couple of hundred (Australian) dollars on a new (better :) video card? Oh, and a final note: I'm aware that XFree 4.2.0 is out. I'd prefer not to have to download and install the binaries myself -- I'd prefer to stick with the Debian package system. If, however, it can be stated with certainty that this problem is resolved in 4.2, I'll look into it. (There doesn't *seem* to be anything in the changelog, though.) Thanks, Stuart. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ct65555 and XVideo
Andrei Lahun writes: Hello . Firstly thank you for fixing bug with ct driver , now driver working without modification of source code. But i found that time to time when i whatch video with mplayer/xine and Xvideo, during startup of player CT driver froze Xserver. I looked at diff between 4.1.0 and 4.2.0 and found at least a way to get rid of these problems: + Bool doubleBuffer; + Bool manualDoubleBuffer; + int currentBuffer; } CHIPSPortPrivRec, *CHIPSPortPrivPtr; And doubleBuffer set to TRUE. When i set it to FALSE no more problems with Xvideo and i donot see any performance decrease. Could you please find out where it is hanging in double buffer mode? You need to log in remotely and start X in gdb. You need a special version of gdb which you can find at: www.dawa.demon.co.uk/xfree-gdb Also Xvideo works only in 24 bits , in 16 just mess. Please could someone fix this in CVS or at least answer at this mail. If you know how. We don't. I have spent several days on this without finding a way to fix it. (I am not subscribed to mailing list) regards Andrei Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]request: xlib resources
on Tue, Feb 19, 2002 at 01:55:47PM +0100, Marc Bruenink wrote: Hi Further i've a problem using XGetFontPath() (segmentation fault) and i didn't find the fault. Perhaps somebody knows where to find a sample source concerning font loading, listing aso. ? okay this is my source code till now: char **ret; int *icount; ret = XGetFontPath(dpy, icount); -- Segfaults here... XSync(dpy, False); what about; char **ret; int icount; ret = XGetFontPath(dpy, icount); XSync(dpy, False); -- mallum ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]request: xlib resources
I use the man pages, the orielly xlib book and prayer. -- mallum on Tue, Feb 19, 2002 at 01:57:41AM +0100, Marc Bruenink wrote: Hi I'm searching for all kinds of resources concerning xlib. I've found http://tronche.com/gui/x/xlib/introduction/ and i think this is a good tutorial but unfortunately it's incomplete. Further i've a problem using XGetFontPath() (segmentation fault) and i didn't find the fault. Perhaps somebody knows where to find a sample source concerning font loading, listing aso. ? Xlib Mailinglists and IRC channels would be great regards marc(..) -- =PGP= http://www.bruenink.de/marc/pgp/ keyserver -Spenden-- Hast Du noch 30pin SIMM RAM?? Oder einen Socket 3 Prozessor?? Oder ein Terminal?? Willst Du ne gute Tat tun?? Gib's mir!! -Werbung- Ich widerspreche der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung (§ 28 Abs.3 BDSG) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: libxml needs iconv.h ?
On 19 Feb, Keith Packard wrote: Around 14 o'clock on Feb 19, [EMAIL PROTECTED] wrote: I know that XML is the computer religion du jure, but as David and others have mentioned, the bulk of the problems are from situations where users are required to adjust the configuration files to deal with problems in the X server. The trouble is that many of us instinctively recoil from any wildly popular new mechanism assuming that it's being misapplied again and again. Most of the time, this is true. I've been considering this issue for several years and have had many separate people suggest that perhaps XML is a good fit for this job; please bear with me as we try to rid ourselves of our common predjudices against anything we see in the popular press. My concern with XML is whether we will encourage mis-use and unrealistic expectations. I have seen completely unrealistic expectations from XML believers lead to very bad decisions. I do not want to encourage that. As a format, XML is fine. I would prefer S-expressions, but a restricted XML schema is merely S-expressions with pointy delimiters instead of curved delimiters. S-expressions are considered utterly obscure and immensely difficult while XML is intuitively obvious to the naive observer. This is not due to the difference between pointy and curved delimiters. It is the impact of herd mentality in computers. I understand S-expressions, both their strengths and weaknesses, and I think that S-expressions are a good choice for configuration files. Giving them pointy delimiters does not change that. If the schema is designed and specified so that none of the XML extensions beyond the S-expression analogues are permitted, then we can also consider using a tiny customized XML parser when we want to reduce the footprint of X. S-expression parsing can be done in a very compact form, and the equivalent restricted XML parser would be similarly compact and fast. I am using the term schema deliberately. I think that the schema is the proper route, not the DTD. The differences are small but important. Schema give you a little more rope with which to hang yourself, but the DTD already gave you more than enough to get in real trouble. Schema permit you to document the contents and constraints much more clearly than DTDs and that is important. If we stick to S-expression equivalents, the schema can be converted into a DTD automatically so that older tools that only support DTDs can be kept happy. R Horn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A big confusion over here - XFree 4.2 - and rage 128
Michel Dänzer wrote: On Wed, 2002-02-20 at 00:17, Gustavo Homem wrote: I am having serious trouble with XFree. I have a rage 128 video card. I was using XFree 4.1 from mdk 8.1 and the Xv extension was malfunctioning for DVDs (was ok for other movies). It would eat too much CPU so a lot of frames were dropped (tested with xine, vlc and mplayer), for example xine would take around 45 % and the X server about 45% using Xv output. I upgraded to XFree 4.2 rpms from mandrake in hope to have this problem solved since it was working perfectly on XFree 4.03 from mdk 8.0. I can only guess why 4.0.3 worked better than 4.1.0; I guess it's because the r128 driver in 4.0.3 didn't properly support 420 video (or was it 422? I forget :) yet. X complained then about drm modules beiing old, so I downloaded the latest one from dri.sf.net , compiled and instaled the module at /lib/modules/ The result was as follows with dri enabled: 1 - Now bttv no longer freezes the system if used with dri enabled (hooray) 2 - The KDM login screen is completely messed (widgets are garbaged, not drawn properly) I have fixed this in DRI CVS and submitted the fix to XFree86. Both 1) and 2) are due to the fact that the r128 driver does 2D acceleration differently with DRI enabled now. I'm sure you've also noticed the better 2D performance. :) 3 - This is the weird part: Xv is messed, the colors don't match the real ones, they are completely changed and there is an horizontal strip with a diferent color variation with xine and a lot of garbage with mplayer, X freezes a short time after switching to and from fullscreen (except for the mouse). Strangely during the time before X freezes there are no framedrops but they come back with dri disabled. What is exactly the relation of Xvideo and dri ? They are conceptually independent, however as of 4.2.0, the r128 driver tries to take advantage of the DRM to accelerate Xv image transfer. Unfortunately, this doesn't work well with some chips, and there are also problems coordinating this with the new 2D acceleration yet. Until these issues are sorted out, use of the DRM for Xv should be an option which defaults to off. I'll submit a patch to that effect soon. Attached is a hack which disables it completely in source for now. I hope this is useful for people who are bitten by this. -- 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 Michel, I don't see an attachment. Did you only send it to Gustavo? I would like to try the patch/hack to disable DRM for Xv. Updating to the latest CVS fixed some of my problems. I just tried xine, and got a system lockup. Mplayer worked, but colors were wrong. It looks like a lot of R128 users will have to avoid using a vanilla XFree86-4.2. That's unfortunate because xawtv with DRI in XF4.1 locks up the system. Joe Krahn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A big confusion over here - XFree 4.2 - and rage 128
On Wed, 2002-02-20 at 14:30, Joe Krahn wrote:
Until these issues are sorted out, use of the DRM for Xv should be an
option which defaults to off. I'll submit a patch to that effect soon.
Attached is a hack which disables it completely in source for now. I
hope this is useful for people who are bitten by this.
Michel, I don't see an attachment. Did you only send it to Gustavo?
No, I just forgot to actually attach it, thanks for pointing this out.
I would like to try the patch/hack to disable DRM for Xv.
Voilà.
It looks like a lot of R128 users will have to avoid using
a vanilla XFree86-4.2. That's unfortunate because xawtv with
DRI in XF4.1 locks up the system.
It's indeed very unfortunate that these problems have only been
discovered after the 4.2.0 release. I hope that there will be 4.2 bugfix
releases and/or that the distributors will integrate fixes into their
4.2 packages.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: r128_video.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c,v
retrieving revision 1.11
diff -u -r1.11 r128_video.c
--- r128_video.c27 Jan 2002 20:05:31 - 1.11
+++ r128_video.c20 Feb 2002 10:22:51 -
@@ -500,7 +500,7 @@
int w
){
-#ifdef XF86DRI
+#if 0 /*def XF86DRI*/
#define BUFSIZE (R128_BUFFER_SIZE - R128_HOSTDATA_BLIT_OFFSET)
#define MAXPASSES (MAXHEIGHT/(BUFSIZE/(MAXWIDTH*2))+1)
[Xpert]Smallest X initialisation
Hi all I was wondering if my initialisations was ok. Here is the smallest Xlib init I can have (open a window and create an ximage). Has anyone smaller ? display = XOpenDisplay (NULL); root_window = DefaultRootWindow (display); window = XCreateWindow (display, root_window, 10, 10, 320, 200, 0, 16, 1, visual, 0, 0); XMapRaised (display, window); XFlush (display); ximage = XCreateImage (display, CopyFromParent, depth, ZPixmap, 0, NULL, 320, 200, 32, 320 * 2); -- Jean-Yves Lamoureux Software Developper --- As you see I'm working : LinesFile 640 /prive/alambik/video/video.c ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xdm dying at Feb 13th EST 9:58
I had the most unpleasant surprise last week at Feb 13th EST 9:58: my X clients (running XFree86 4) got disconnected form their HP Login servers. The error message in X log was: XDM: too many keepalive retransmissions This problem ALWAYS happens at this time. I did some research and I found out people having the same problem in May 2000 and September 2001. Does anyone knows about this problem? Is there a fix? Dows anyone knows when this will happen again? Thanks Rodrigo Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]unsuscribe xpert
___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]i810, XFree86: vertical bars on screen
Stuart, This is a watermark issue. The watermark is the set of delays etc. that control the flow of data into and out of a FIFO that feeds the dac. Your FIFO is probably running out of data when memory bandwidth isn't available to fill the screen and blit at the same time. Your video mode is probably to blame. Either run at a lower refresh rate, or a smaller resolution. Additionally there were some systems that had a incorrect bios setting in the MEMMODE register. This was fixed in XFree sometime recently but I don't recall when. If your system suffers from that issue upgrading to 4.2.0 may provide better results. Additionally if you are using a non standard Modeline in XF86Config... don't do that. -Matt -Original Message- From: Stuart Lamble [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 8:27 PM To: [EMAIL PROTECTED] Subject: [Xpert]i810, XFree86: vertical bars on screen Greetings. I am currently running XFree86 4.1.0 on Linux 2.4.17 (Debian unstable). My system is based around the Intel 815 chipset (Pentium 3, 933 MHz). Afterstep window manager, with a 16 bit color depth. Every so often, I get vertical bars appearing on my screen when I move a window around. These bars are 12 pixels wide, and tend to be separated by 116 pixels (hmm. Interesting figures...) Depending on where the window being moved is, the location at which the bars appear may move across 64 pixels. (Sorry, I can't tell you the offset from the side of the screen. Oops.) The bars do *not* appear automagically -- they appear only when I move a window around on screen (or move to a different part of the virtual screen provided by AfterStep) -- and not even all the time then. It *seems* to be related to having a large number of gtk-based windows open, but I can't swear to that; I can't reliably reproduce the problem. :-( Does anybody have any suggestions? Or am I going to end up spending a couple of hundred (Australian) dollars on a new (better :) video card? Oh, and a final note: I'm aware that XFree 4.2.0 is out. I'd prefer not to have to download and install the binaries myself -- I'd prefer to stick with the Debian package system. If, however, it can be stated with certainty that this problem is resolved in 4.2, I'll look into it. (There doesn't *seem* to be anything in the changelog, though.) Thanks, Stuart. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: libxml needs iconv.h ?
Around 8 o'clock on Feb 20, [EMAIL PROTECTED] wrote: As a format, XML is fine. I would prefer S-expressions, but a restricted XML schema is merely S-expressions with pointy delimiters instead of curved delimiters. If you squint, and format your XML properly, you can easily pretend that it is S-expressions... In developing the fontconfig DTD, I discovered that the XML proponents involved directed me to a more s-expression like syntax. ... I think that S-expressions are a good choice for configuration files. Giving them pointy delimiters does not change that. XML has one advantage over S-exprs -- the existing parsers can capture and retain formatting information so that the writer can precisely reproduce what the reader was given. If the schema is designed and specified so that none of the XML extensions beyond the S-expression analogues are permitted, then we can also consider using a tiny customized XML parser when we want to reduce the footprint of X. Yes, the existing XML parsers are relatively large -- 100K for expat, 600K for libxml2. I'm not willing to write a custom parser, but certainly would accept contributions along such lines. However, if XML-based configuration becomes popular in other areas, it may be that the 100K library will be shared among many applications mitigating it's memory impact somewhat. I am using the term schema deliberately. I think that the schema is the proper route, not the DTD. The differences are small but important. Schema give you a little more rope with which to hang yourself, but the DTD already gave you more than enough to get in real trouble. Schema permit you to document the contents and constraints much more clearly than DTDs and that is important. I haven't explored the world of schema yet; if using those would help make the configuration file somewhat more self-documenting, and provide tools that can verify the contents more accurately, then we should probably use them. I also don't know the state of existing tools wrt schema-based XML. I took the cautious approach when designing the fontconfig mechanism. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A big confusion over here - XFree 4.2 - and rage 128
Hi Michel : Thanks for your answer. I can only guess why 4.0.3 worked better than 4.1.0; I guess it's because the r128 driver in 4.0.3 didn't properly support 420 video (or was it 422? I forget :) yet. I don't know exactly what are those 420 and 422 ? Image formats ? How does that justify the fact that mpeg2 overlay performance degraded ? What I complain about (with XFree 4.1 and XFree 4.2 DRI disabled) is a very high cpu load when using XV output, which causes frame dropping. With Xshm output I get no frame drops and Xv was supposed to provide better performance, so I have to conclude that Xv output is broke in either 4.1 and 4.2 , in the latter case it is broke in 2 different ways (but only for mpeg). X complained then about drm modules beiing old, so I downloaded the latest one from dri.sf.net , compiled and instaled the module at /lib/modules/ The result was as follows with dri enabled: 1 - Now bttv no longer freezes the system if used with dri enabled (hooray) 2 - The KDM login screen is completely messed (widgets are garbaged, not drawn properly) I have fixed this in DRI CVS and submitted the fix to XFree86. Both 1) and 2) are due to the fact that the r128 driver does 2D acceleration differently with DRI enabled now. I'm sure you've also noticed the better 2D performance. :) I read that the 2d acceleration mode had to be changed because it was incompatible with the use of bttv, but why have two diferent implmentations ? What I noticed was that with DRI enabled Xv ouput was smooth again before crashing (colors were wrong though), but that was the usual situation with 4.03 regardless of DRI beeing enabled or disabled. 3 - This is the weird part: Xv is messed, the colors don't match the real ones, they are completely changed and there is an horizontal strip with a diferent color variation with xine and a lot of garbage with mplayer, X freezes a short time after switching to and from fullscreen (except for the mouse). Strangely during the time before X freezes there are no framedrops but they come back with dri disabled. What is exactly the relation of Xvideo and dri ? They are conceptually independent, however as of 4.2.0, the r128 driver tries to take advantage of the DRM to accelerate Xv image transfer. Unfortunately, this doesn't work well with some chips, and there are also problems coordinating this with the new 2D acceleration yet. hmm, I had a very quick look at dri.sf.net info, and I think I read drm was 3d only and that 2d data would allways go to the X server (they have a picture :) ). Did this change ? Is drm going to be used for 2d in the future ? Until these issues are sorted out, use of the DRM for Xv should be an option which defaults to off. I'll submit a patch to that effect soon. Attached is a hack which disables it completely in source for now. I hope this is useful for people who are bitten by this. Well, I am looking forward to see how this problem is solved. Too bad that I am too busy get really into it, since the subject is very interesting. Thanks again Gustavo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Why suid for linear framebuffer?
On Wed, 20 Feb 2002 [EMAIL PROTECTED] wrote: I am using the nv driver for a Riva TNT 2 on a FreeBSD 4.5-RELEASE system and receive the following fatal error when starting X with a non-superuser: (WW) checkDevMem: failed to open /dev/mem (Permission denied) linear framebuffer access unavailable Fatal server error: xf86OpenConsole: Server must be suid root Any help or comments are very appreciated. The X-server needs root permissions to open /dev/mem. It's always been that way. Either XFree86 needs to be suid root or the wrapper does. BTW, that error message is deceiving. You need to open /dev/mem to map any of the card's registers, not just the framebuffer. And even if it were a planar framebuffer you'd still need to open /dev/mem. Somebody should fix that error message. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Matrox G200 MMS almost-quad display
Hello Xperts, I am encountering a weird problem with a Matrox G200 MMS quad-display card. Maybe someone can shed some light upon it or at least suggest a direction of what I could try next? I tested 2 different cards (same model) already, so it's not defect hardware like I suspected: I installed the MGA drivers for G200 MMS from Matrox as detailed on their site. The driver version is 1.43, and XFree is 4.1.0, kernel version 2.4.4GB (SuSE). I compiled XFree and the driver from sources. I can get three displays working, but not four. More specifically, I cannot get any combination of displays working which would include display #2, the one at the PCI bus address 2:4:0. Every time when I try starting X with this display enabled (including a single-screen configuration on this display), the machine just hangs. Mostly I can use CTRL-ALT-DEL to reboot it (as the display goes black), and sometimes it's locked hard. What's very frustrating is that I can mix and match all other displays as I like and everything is fine, just this #2 is broken. The last lines that appear in the log (here pasted from an attempt to get display #2 alone working, hence MGA(0)) are always: ... (II) MGA(0): Not using default mode 1856x1392 (insufficient memory for mode) (II) MGA(0): Not using default mode 1920x1440 (insufficient memory for mode) (II) MGA(0): Not using default mode 1920x1440 (insufficient memory for mode) (II) MGA(0): Not using default mode 1400x1050 (insufficient memory for mode) (II) MGA(0): Not using default mode 1400x1050 (insufficient memory for mode) (==) MGA(0): Write-combining range (0xf500,0x20) In successful configurations (using displays #1, #3, #4), the server apparently goes past this line: ... (II) MGA(0): Not using default mode 1856x1392 (hsync out of range) (II) MGA(0): Not using default mode 1856x1392 (bad mode clock/interlace/doublescan) (II) MGA(0): Not using default mode 1920x1440 (hsync out of range) (II) MGA(0): Not using default mode 1920x1440 (bad mode clock/interlace/doublescan) (II) MGA(0): Not using default mode 1400x1050 (hsync out of range) (==) MGA(0): Write-combining range (0xf300,0x80) (==) MGA(0): Write-combining range (0xf380,0x20) (--) MGA(0): Virtual size is 1024x768 (pitch 1024) (**) MGA(0): Mode 1024x768: 93.0 MHz, 66.4 kHz, 82.8 Hz (==) MGA(0): DPI set to (75, 75) ... Maybe someone can point out what the write-combining range message means and what could be going wrong here? Note that I have no other PCI devices in the same box, nor do I have an AGP card. lspci produces good-looking output showing all four virtual devices, with all the same configuration details besides of the memory at lines (0xf500 is the memory-at for device #2, 0xf300 for device #3). I have looked at BIOS settings, but I can't see anything relevant there (not being a hardware expert, granted). Your opinion and suggestions about further steps to resolve this problem are highly appreciated. Also, maybe someone has a G200 MMS quad setup working and can share their XFree/driver/system versions to encourage me :-) Thanks in advance - Jan Ploski ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Here's how to unsubscribe from this list!
Why is it that people keep sending unsubscribe requests to the whole list. As if everybody here should do something about them wanting to unsubscribe. In case you lost the welcome message that was sent when you subscribed, here's a portion of it... Welcome to the [EMAIL PROTECTED] mailing list! To post to this list, send your email to: [EMAIL PROTECTED] General information about the mailing list is at: http://XFree86.Org/mailman/listinfo/xpert If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://XFree86.Org/mailman/options/xpert/insert_your_email_address_here You can also make such adjustments via email by sending a message to: [EMAIL PROTECTED] with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: XXX (I'm not going to tell you my password) If you forget your password, don't worry, you will receive a monthly reminder telling you what all your XFree86.Org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. * NOTE! Does this monthly email actually get sent ? * You may also have your password mailed to you automatically off of the Web page noted above. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]An question about StopVideo on ATI AiW
Coz I use a non-member mailbox last time, so I send it again by member mailbox Kevin Huang === Hello everyone : I encounter a strange problem and can't figure out why. I have a ATI AiW r128 video card his new Xv supported driver. When I use DVD player to play mpeg2 file move other window to clip the video window, the driver doesn't call StopVideo. But in it's VideoInit function, it sets flag VIDEO_OVERLAID_IMAGES as below : VAR[i].type |= XvWindowMask | XvVideoMask | XvStillMask | XvImageMask; VAR[i].name = R128; VAR[i].flags=VIDEO_OVERLAID_IMAGES|VIDEO_CLIP_TO_VIEWPORT; According to XFree86 X server New Design(DRAFT): The XFree86 X Video Extension(Xv) Device Dependent Layer chapter, it mentions that if we set VIDEO_OVERLAID_IMAGES, StopVideo will be called whenever the destination gets clipped or moved so that the image can be left up until then. My confusion is that how ATI does that it can prevent the driver to call StopVideo when we clip the video window. Does anybody know this give me a help, Thanks a lot !! Sincerely, Kevin Huang - ¨C¤Ñ³£ Yahoo!©_¼¯ www.yahoo.com.tw ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]An question about StopVideo on ATI AiW
On Thu, 21 Feb 2002, [big5] ¶À¸s³Í wrote: Coz I use a non-member mailbox last time, so I send it again by member mailbox Kevin Huang === Hello everyone : I encounter a strange problem and can't figure out why. I have a ATI AiW r128 video card his new Xv supported driver. When I use DVD player to play mpeg2 file move other window to clip the video window, the driver doesn't call StopVideo. But in it's VideoInit function, it sets flag VIDEO_OVERLAID_IMAGES as below : VAR[i].type |= XvWindowMask | XvVideoMask | XvStillMask | XvImageMask; VAR[i].name = R128; VAR[i].flags=VIDEO_OVERLAID_IMAGES|VIDEO_CLIP_TO_VIEWPORT; According to XFree86 X server New Design(DRAFT): The XFree86 X Video Extension(Xv) Device Dependent Layer chapter, it mentions that if we set VIDEO_OVERLAID_IMAGES, StopVideo will be called whenever the destination gets clipped or moved so that the image can be left up until then. The docs are old. Stop won't actually get called with a simple clip change. Stop will only get called on a move or when the cliplist changes such that an exposure is generated. Even then, the StopVideo function can be ignored by the driver in that case because the cleanup flag isn't set. What most of the drivers do in that case is make note that Stop was called and will stop it in a few seconds if there are no PutImage calls following. MArk ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]out of scan range
Running suse 7.2, kernel 2.4.16, kde 2.1.2, matrox g200 video card and sony cpd-200es monitor. I upgraded to Xserver 4.1 and I used sax2 for configuration. The monitor horizontal and vertical freq ranges were detected correctly by sax2. System will boot properly to kde desktop.The problem is when I enter cntrl+alt+backspace, this does not kill the Xserver and monitor will turn black for few seconds and switches back to kde desktop. when I enter cntrl+alt+F1, monitor turns black with a message out of scan range and I do not see the text console and I have to enter cntrl+alt+del to reboot. when I click shutdown from the desktop, the monitor turns black with same message out of scan range, text console does not get restored, but the system will shutdown properly. This problem did not happen with the Xserver version 4.0.3 that was included in suse 7.2 distribution. Does anyone know how to fix this problem? Thanks in advance for any suggestions. P.S If solution needs some compiling work, please provide detail instructions ( I am new to Linux). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon VE dualhead
You can try to use HorizSync 80 and VertRefresh 75 (be careful, check your monitor manual first) instead of HorizSync 64 and VertRefresh 60. Or you can simply try to remove HorizSync 64 and VertRefresh 60 lines from both of your Monitor sections, radeon driver will use the sync ranges from the EDID (this may not work for you if your monitors have multi separate sync settings). Your monitors seem to only support 1280x1024@75Hz. If you force it to 1280x1024@60Hz as you did, it may have the problem as you experienced. BTW, your monitors use analog input, you don't need Option CrtScreen lines. hy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 19, 2002 11:42 AM Subject: Re: [Xpert]Radeon VE dualhead Here is the attachments I meant to include... -- Today's funny quote of the day: I have flabby thighs, but fortunately my stomach covers them. www.GCFL.net (The Good, Clean Funnies List): Good, clean funnies five times a week, FOR FREE no ads in the mailings! The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon VE dualhead
Actually, the monitors ideally want 1280x1024@60Hz and that's why I have the HorizSync and VertRefresh set the way I do (the monitor spec said that the monitors use those frequencies). However, I will try putting the valid ranges back for HS VS and see what that does. I know that it's something simple I'm missing... Later I tried the setup without the CrtScreen options, and there was no change, so I agree with you that they are not necessary. Do you have a XF86Config-4 file that works (with dualhead Radeon)? Thanx, John On Wed, Feb 20, 2002 at 11:33:35PM -0800, hy0 wrote: You can try to use HorizSync 80 and VertRefresh 75 (be careful, check your monitor manual first) instead of HorizSync 64 and VertRefresh 60. Or you can simply try to remove HorizSync 64 and VertRefresh 60 lines from both of your Monitor sections, radeon driver will use the sync ranges from the EDID (this may not work for you if your monitors have multi separate sync settings). Your monitors seem to only support 1280x1024@75Hz. If you force it to 1280x1024@60Hz as you did, it may have the problem as you experienced. BTW, your monitors use analog input, you don't need Option CrtScreen lines. hy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 19, 2002 11:42 AM Subject: Re: [Xpert]Radeon VE dualhead Here is the attachments I meant to include... -- Today's funny quote of the day: I have flabby thighs, but fortunately my stomach covers them. www.GCFL.net (The Good, Clean Funnies List): Good, clean funnies five times a week, FOR FREE no ads in the mailings! The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Today's funny quote of the day: The advantage of exercising every day is that you die healthier. www.GCFL.net (The Good, Clean Funnies List): Good, clean funnies five times a week, FOR FREE no ads in the mailings! The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]S3 TRIO 3D system hang from PCI violation
Hello everyone, Recently, we discovered a PCI violation occuring using ATI Rage XL chipsets, which Marc Aurele La France was kind enough to provide a fix for us. We have also discovered that the same PCI violation is occuring with S3 TRIO 3D (as well as the PERMEDIA) chipset. I was hoping to find a kind S3 soul that could help us create a similar fix as to what Marc provided us with ATI. Marc's patch is attached for reference. Please CC me on any responses, as I am not subscribed to this list. Sincerely, Bradley Wayne Thomas PS: I am terribly sorry about the mail.. I am aware that an eternal bout of tourture and punishment is in store for me because of it :). (See attached file: IBM.diff.gz) Caldera Linux NOS Support Phone (919) 543-2693 Fax (919) 543-7606 [EMAIL PROTECTED] IBM.diff.gz Description: Binary data
[Xpert]xgamma not working with second head of MGA G400 AGP
I have a 3 (well, trying to make it 4 if I can get the second voodoo to soft boot) head system, and for some odd reason, xgamma won't change the gamma of the second MGA head, while it will change the gamma of the first head no problem. dual:~$ xgamma -s 0 - Red 1.237, Green 1.239, Blue 1.374 dual:~$ xgamma -s 1 - Red 1.300, Green 1.300, Blue 1.300 dual:~$ xgamma -s 2 - Red 3.000, Green 3.000, Blue 3.000 dual:~$ xgamma -s 2 -rg 5 -bg 5 -gg 5 - Red 3.000, Green 3.000, Blue 3.000 - Red 5.000, Green 5.000, Blue 5.000 At this point, I should be staring at a totally washed out 3rd head, but nothing happens. Ideas? Don Armstrong -- Always try to do things in chronological order. It's less confusing that way. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]An question about StopVideo on ATI AiW
Hi Mark : Thanks for your answer in advance!! :) I'm working on Xv driver for my company's graphic chip, but I encounter an problem can't fint out the reason. Everytime I use other window to clip the video window or move it, StopVideo will be called makes the video flicker. This doesn't happen in ATI AiW r128. When I check the XFree86.0.log of ATI AiW, only PutImage is called. Does any special flags need to set in the driver ? BTW, if I run xawtv 3.71 under ATI AiW, PutVideo will be called. When I use other window to clip the xawtv video window, StopVideo is called the video flicker!! It's very strange that StopVideo is called in xawtv but not called in mpeg2 player. According to the docs, I can't find out the reason between PutImage PutVideo. Would you pls give me any hint ? Thanks a lot !! Sincerely, Kevin Huang --- Mark Vojkovich [EMAIL PROTECTED] wrote¡G On Thu, 21 Feb 2002, Kevin Huang wrote: Coz I use a non-member mailbox last time, so I send it again by member mailbox Kevin Huang === Hello everyone : I encounter a strange problem and can't figure out why. I have a ATI AiW r128 video card his new Xv supported driver. When I use DVD player to play mpeg2 file move other window to clip the video window, the driver doesn't call StopVideo. But in it's VideoInit function, it sets flag VIDEO_OVERLAID_IMAGES as below : VAR[i].type |= XvWindowMask | XvVideoMask | XvStillMask | XvImageMask; VAR[i].name = R128; VAR[i].flags=VIDEO_OVERLAID_IMAGES|VIDEO_CLIP_TO_VIEWPORT; According to XFree86 X server New Design(DRAFT): The XFree86 X Video Extension(Xv) Device Dependent Layer chapter, it mentions that if we set VIDEO_OVERLAID_IMAGES, StopVideo will be called whenever the destination gets clipped or moved so that the image can be left up until then. The docs are old. Stop won't actually get called with a simple clip change. Stop will only get called on a move or when the cliplist changes such that an exposure is generated. Even then, the StopVideo function can be ignored by the driver in that case because the cleanup flag isn't set. What most of the drivers do in that case is make note that Stop was called and will stop it in a few seconds if there are no PutImage calls following. MArk - ¨C¤Ñ³£ Yahoo!©_¼¯ www.yahoo.com.tw ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Here's how to unsubscribe from this list!
On Wed, 20 Feb 2002, Dave Williss wrote: If you forget your password, don't worry, you will receive a monthly reminder telling you what all your XFree86.Org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. * NOTE! Does this monthly email actually get sent ? * Yes, it does. -Yuri ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
