Colormap Problems in Matrox G450 under FreeBSD 4.8
I have an application which requires it uses it own colormap. I'm using the 8+24 mode in the mga driver where the colormap has to be installed in the 8 Pseudo color plane. This application works well unchanged in HP-UX and Solaris 8. When i load the colormap , it affects all other applications on that screen. The xwininfo result indicates the color map has been successfully installed. 1)Is this a known bug in the mga driver? Possibly linked to the 8 + 24 mode ? 2) Is there an option in the Mga driver that is known to solve this problem ? i.e. ColorKey ? 3) Is there a known workaround? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Colormap Problems in Matrox G450 under FreeBSD 4.8
On Thu, 3 Apr 2003, Peter Gervais wrote: I have an application which requires it uses it own colormap. I'm using the 8+24 mode in the mga driver where the colormap has to be installed in the 8 Pseudo color plane. This application works well unchanged in HP-UX and Solaris 8. When i load the colormap , it affects all other applications on that screen. The xwininfo result indicates the color map has been successfully installed. This is true for most PC hardware in any 8-bit mode* Typically PC graphics hardware only has one palette storing the colormap; many HP and Sun systems have hardware with more than one palette, which solves the problem. In your particular case the 8bit visuals use the palette, but the 24 bit visuals ignore it, so any applications which use 24bit visuals should be unaffected by your unsociable application. Unfortunately the default visual in 8+24 is 8bit, and many applications just use the default, so most applications are affected. You may be able to get around this by starting X with something like: startx -- -cc 4 which will make the 24bit visual the default, although I believe that this stops many 8bit apps. from working; if they are too ignorant to support a 24buit visual they may be unable to find the 8bit pseudocolor visual when it is not the default :-( *The problem also affects any dynamic visual - GrayScale, PseudoColor and DirectColor, and any other visuals implemented the same way; eg TrueColor when gamma-correction is available. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Colormap Problems in Matrox G450 under FreeBSD 4.8
Thank you for answering my e-mail. I've noticed as well that this very same application will not update the screen unless the mouse is inside it's window area. This is a Air Traffic Control radar type of application which must be continuously updated no matter if the mouse is in the screen or not. The X lib calls are being made but yet the display will not update until the mouse is in the radar display. Again , same code as HP-UX and Solaris and works fine on those system. Is there a server option which will force update to occur if the mouse is not in the screen? At 07:28 PM 03/04/2003 +0100, you wrote: On Thu, 3 Apr 2003, Peter Gervais wrote: I have an application which requires it uses it own colormap. I'm using the 8+24 mode in the mga driver where the colormap has to be installed in the 8 Pseudo color plane. This application works well unchanged in HP-UX and Solaris 8. When i load the colormap , it affects all other applications on that screen. The xwininfo result indicates the color map has been successfully installed. This is true for most PC hardware in any 8-bit mode* Typically PC graphics hardware only has one palette storing the colormap; many HP and Sun systems have hardware with more than one palette, which solves the problem. In your particular case the 8bit visuals use the palette, but the 24 bit visuals ignore it, so any applications which use 24bit visuals should be unaffected by your unsociable application. Unfortunately the default visual in 8+24 is 8bit, and many applications just use the default, so most applications are affected. You may be able to get around this by starting X with something like: startx -- -cc 4 which will make the 24bit visual the default, although I believe that this stops many 8bit apps. from working; if they are too ignorant to support a 24buit visual they may be unable to find the 8bit pseudocolor visual when it is not the default :-( *The problem also affects any dynamic visual - GrayScale, PseudoColor and DirectColor, and any other visuals implemented the same way; eg TrueColor when gamma-correction is available. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Matthieu Herrb wrote (in a message from Thursday 3) CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 03/04/03 13:48:25 Log message: Document that mode switching functions are asynchronous and that XSetErrorHandler() and XSync() need to be used to get a synchronous like behaviour. (Bugzilla #22). This should read: Bugzilla #48. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
