From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13142 invoked by alias); 8 Jul 2002 00:32:35 -0000 Mailing-List: contact cygwin-xfree-announce-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: cygwin-xfree-announce-owner@sources.redhat.com Received: (qmail 6666 invoked from network); 8 Jul 2002 00:10:16 -0000 Reply-To: From: "Harold Hunt" To: "cygx" , "cygxannounce" Subject: Updated on sourceware: XFree86-xserv-4.2.0-10 Date: Sun, 07 Jul 2002 17:32:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2002-07/txt/msg00001.txt.bz2 List-Id: The XFree86-xserv-4.2.0-10 package has been updated in the Cygwin distribution. This is a synchronization with all the fixes that have been applied from Server Test Series - Test 61 through Server Test Series - Test 63. These fixes are summarized below: 1) Add support for the `-clipupdates num_boxes' parameter when using `-engine 2' or `-engine 4', in addition to the previously supported `-engine 1'. Once again, I can't tell if this feature has any benefit whatsoever. I need some volunteers to perform rigorous testing with different values for the threshold at which point updated boxes are collected into a clipping region. One may find the ``x11perf'' program beneficial here, as well as ``glxgears'', which gives a frames per second reading. Of course, it would be most beneficial to have performance comparisons for a few different machine types (processors, memory amounts, video cards, PCI or AGP, etc.). Update clipping is off by default. (Harold Hunt) 2) Change the DirectDraw module handle and function pointers from screen privates to global variables. Loading the DirectDraw module and function pointers needs to be done only at server initialization, not at screen initialization. Similarly, we don't need to unload and reload DirectDraw for each screen when the server regenerates; rather, we need only unload DirectDraw when the server is shutting down. This cleanup makes it much for difficult to misunderstand what is going on with the DirectDraw module handle and function pointers. (Harold Hunt) 3) Detect the supported engines only once at startup, rather than once per screen initialization. Rework the supported engine detection logic to assume that the DirectDraw module handle and function pointers have already been loaded if they are present and working. (Harold Hunt) 4) Add a global module handle for ``comctl32.dll'' and ``_TrackMouseEvent''. Try to get a pointer to the _TrackMouseEvent function and print an informational message if we cannot find the function, suggesting to the user that they install Internet Explorer 3.0 or greater if they have not already done so. We also set the _TrackMouseEvent function pointer to point to the no operation function if we can't find a valid function so that any calls to the function pointer will do nothing (instead of trying to dereference a NULL and crashing). Mouse pointer hiding/showing may be messed up when we don't have _TrackMouseEvent, but the user can remedy that by following the advice in the information message. Remove our compile-time link to comctl32.dll. (Harold Hunt) 5) Add an `-emulatepseudo' parameter that causes a depth 8 PseudoColor visual to be created in TrueColor modes, with the same limitations described in the Test62 change log. PseudoColor emulation is off by default. (Harold Hunt) 6) Correctly calculate the number of bits used to store color information by counting the total number of bits that are set in our color masks. This should fix problems introduced in Test61 for users with 24bpp or 15bpp displays. (Alan Hourihane, Harold Hunt) 7) Add a #if conditional to winInitVisuals* that calls miSetVisualTypesAndMasks or fbSetVisualTypesAndMasks depending on if XFree86Server is defined. Currently this isn't useful because Mesa (similar to Open GL) doesn't work when XFree86Server is undefined. I'll leave this here for now for future reference. (Harold Hunt) 8) Fix the KDE 3.0 alpha-channel icon bug that appeared only when running Windows at 32 bits per pixel. Many more details below. (Alan Hourihane) 9) pScreenInfo->dwDepth used to refer to the depth that the user specified with the -depth parameter or the depth returned by GetDeviceCaps (BITSPIXEL) and pScreenInfo->dwBPP used to refer to the bits of color per pixel. For example, running Windows at 32 bit color would mean dwDepth == 32 and dwBPP == 24. It turns out that this was exactly backwards from what it should be. The dwDepth variable new refers to the color ``depth'' of a pixel, that is, the number of bits that make up the color specification for a pixel. For example, a 32 bit pixel uses 24 bits to represent color plus an 8 bit pad for alignment purposes and a 16 bit pixel can use 15 or 16 bits to represent color. The dwBPP variable now refers to the bits used to store each pixel, that is, the number of bits that each pixel occupies in the framebuffer memory. For example, a 32 bit pixel occupies 32 bits in the framebuffer memory while a 24 bit pixel occupies 24 bits in the framebuffer memory (the former pixels are 32 bit aligned, while the latter pixels are called ``packed'' because the pixels are not aligned and any given pixel may actually be stored in two separate 32 bit units). The meaning of dwDepth and dwBPP was corrected throughout the source code, touching files such as wincmap.c, winscrinit.c, InitOutput.c, winshadddnl.c, winshaddd.c, winshadgdi.c, winnativegdi.c, winpfbdd.c, and win.h. Also, we modify the depth 24 pixmap format at runtime to use 24 bits per pixel, instead of 32, when Windows is running in 24 bit color; this matches the Windows pixel format when running in 24 bit color. The end result of all of this is that we now no longer report that we have a depth 32 visual, as depth 32 visuals do not exist. What we were previously calling a depth 32 visual is actually a depth 24 visual with a different bits per pixel. Advertising a proper visual when running Windows at 32 bit color corrects the problem of KDE 3.0 not displaying icons or text with alpha channels. Alan did the magical part of discovering the underlying problem, I did the grunt work of cleaning the code and making sure that all of the corner cases were still handled. (Alan Hourihane, Harold Hunt) 10) In winBltExposedRegionsShadowDD* () we try to restore the primary DirectDraw surface up to WIN_REGAIN_SURFACE_RETRIES (currently 1) times when a bit block transfer of the exposed regions fails. This corrects the case where switching a notebook from its internal display to an external display (or vice versa) would cause the Cygwin/XFree86 window to blank and fail to redraw itself until the Cygwin/XFree86 window was minimized and then restored. (Harold Hunt) -- Harold Hunt To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'XFree86-xserv' from the 'XFree86' category. You may need to click the "Full" button if it doesn't show up. Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://archive.progeny.com/cygwin/ is a reliable high bandwidth connection. In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is usually up-to-date. In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date. If one of the above doesn't have the latest version of this package you can either wait for the site to be updated or find another mirror. Please send questions or comments to the Cygwin/XFree86 mailing list at: cygwin-xfree@sources.redhat.com . If you want to subscribe go to: http://cygwin.com/lists.html I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin/XFree86 in general. If you want to make a point or ask a question the Cygwin/XFree86 mailing list is the appropriate place.