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" <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] . 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"
