This is the mail archive of the cygwin-xfree-announce@cygwin.com mailing list for the Cygwin/XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Updated on sourceware: XFree86-xserv-4.2.0-10


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]