Updated on sourceware: XFree86-xserv-4.2.0-10

[Jack Larsen]

Hi,

after upgrading to 4.2.0-10 xmodmap Xmodmap failed with 
"unknown command bad keysym in remove modifier list 
'Mode_switch', no corresponding keycodes".

If anybody experienced the same problem please
 comment out the line "remove control = Mode_switch"

-Hans

On Sun, 7 Jul 2002 20:10:15 -0400
"Harold Hunt" <huntharo@msu.edu> wrote:

> 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.
> 
> 


-- 
"Jack Larsen"