XI events can now take the same processing paths as core events, and should do
the correct state changes etc.
There's some cases where XKB will use KeyPress as type for an event to be
delivered to the client. Stuck warnings in, not sure what the correct solution
is yet.
Using a global array for action filters is bad. If two keyboard hit a modifier
at the same time, releaseing the first one will deactivate the filter and
thus the second keyboard can never release the modifier again.
over to new system.
Need to update documentation and address some remaining vestiges of
old system such as CursorRec structure, fb "offman" structure, and
FontRec privates.
XkbCopyKeymap reallocates the destination keymap when it is not large enough
to hold the source data. When reallocating the map->types data, it needs to
zero out the new entries. The computation for where to start bzero'ing was
accounting for the size of the data type twice, once implicitly in the
pointer arithmetic, and once explicitly with '* sizeof (XkbKeyTypeRec)'.
This would often lead to random memory corruption when the destination
keymap had existing map->types data.
using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to
process DeviceKeyEvents after the first key press.
This should be the correct fix now.
The former <X11/extensions/XKBsrv.h> has been pulled into the server now as
include/xkbsrv.h, and the world updated to look for it in the new place,
since it made no sense to define server API in an extension header. Any
further work along this line will need to do similar things with XKBgeom.h
and friends.
otherwise a Xi grab may overwrite or release a core grab.
Replace grab and associates with coreGrab and deviceGrab structures,
adjust rest of dix/Xi/etc to compile.
xfree86: Don't check for core devices, we'll have the virtual ones anyway.
If we check, the first mouse device is duplicated and sends
double events.
When we reallocated modmap, we accidentally clobbered syms with the
result, leaving syms definitely too small, and modmap also potentially too
small (as well as not actually allocated anymore).
bugfix: uninitialized pPointer in miPointerGetPosition ifndef MPX
adding DeviceIntPtr parameter to ScreenRec's cursor functions.
cleanup of miPointer code to use same scheme in each function
dix: MPHasCursor() function determines checking whether to invoke
cursor rendering.
animcur: adding DeviceIntPtr parameter to cursor functions but animcur relies
on the core pointer right now.
xfixes: adding DeviceIntPtr parameter to cursor functions but xfixes relies on
the core pointer right now.
rac: adding DeviceIntPtr parameter to cursor functions but RAC relies on
the core pointer right now.
ramdac: adding DeviceIntPtr parameter to cursor functions but ramdac relies on
the core pointer right now.
added SpriteRecs for MPX devices
changed sprite dependency and added MPX functionality to parts
of events.c (ConfineToShape, PostNewCursor, XineramaCheckMotion,
CheckMotion, XineramaChangeToCursor, ChangeToCursor, CheckPhysLimits,
PointerConfinedToScreen)
added DeviceIntRec param to GetSpritePosition(). This required some
minor changes in ddx, xtest, xkb and xfixes.
mi: changed miPointer to pointer instead of static struct.
Take various extra precautions with copying levels across (thanks Chris
Lee for a gdb session), including allocating when we don't already have a
coherent map.
Only free type components if they're present.
Allocate geometry and compat components if we don't already have them in
the dest map.
Compute virtual modmap size bounded by nVModMapKeys-1, rather than
nVModMapKeys.
This is sort of a best guess. The other way seems a little more
logical, but also leads to segfaults pretty quickly if you hammer
GetMap hard enough. So let's try this one.
Forgot that all XKB requests took a device spec: the comparison of
'if working on the core keyboard, does this device send core events; or,
is this device the core keyboard?' was broken. Instead, what we want is
'if working on the core keyboard, does this device send core events; or,
is this device the one we're working on?'.
XKB.h specifies that XkbDfltXIId should be used where the client doesn't
care about the device identifier. We take this to mean core devices,
where practical.
Fix a bunch of range issues caused by incorrect assumptions (e.g. that the
design was at least halfway sensible), and copy types by hand, instead of
just blindly memcpy()ing the lot, since it itself cleverly contains a ton
of allocated pointers.
Get rid of almost all uses of these definitions. They're still defined for
delinquent out-of-tree drivers, and also for the Mesa build. As well as
for miinitext.c. But largely gone.
New files linked:
xorgconf.cpp Options
usb.3 usb_hid_usages
lynx_ppc.S
BUSmemcpy.S IODelay.S PortIO.S SlowBcopy.S
sun_inout.s
xaaTEGlyphBlt.S
xkbcomp/compiled/README
New files excluded:
All of lib/GL/apple
xlibi18n/*/*.mapfile
xxserver/xorg/configure.ac, xkb/Makefile.am:
Install README.compiled in the xkb output dir
it doesn't already exist. (ported from Solaris Xsun bug #5039004)
When BuildLikeSun is set, define MAKE_XKM_OUTPUT_DIR and set the xkb output
directory to /var/run/xkb.
Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings.
Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all
source files in the xserver/xorg tree, predicated on defines of
HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to
<X11/fonts/foo.h>.
<X11/...>
- For Xcomposite and Xdamage, don't link the build system out of the xc
tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source
change "foo.h" to <X11/foo.h> for core headers, e.g. X.h, Xpoll.h;
change "foo.h", "extensions/foo.h" and "X11/foo.h" to
<X11/extensions/foo.h> for extension headers, e.g. Xv.h;
change "foo.[ch]" to <X11/Xtrans/foo.[ch]> for Xtrans files.
//bugs.freedesktop.org/show_bug.cgi?id=2245) attachment #1647
(https://bugs.freedesktop.org/attachment.cgi?id=1647): export
Win32System and Win32TempDir remove #ifdef WIN32 block for building
xkbcomp commandline create win32 tempfile in system tempdir use
PATH_MAX*4 for commandline buffer unlink tmpfile again
(https://bugs.freedesktop.org/attachment.cgi?id=1645): cleanup some
#ifdef __UNIXOS2__ and WIN32 blocks. make OutputDirectory check the
size of the buffer quote all file and pathnames in the xkbcomp
commandline use PATH_MAX*4 for commandline buffer
Updating to EDID 1.3. (Bugzilla# 1490, Jay Cotton, Egbert Eich).
Removing unneeded code.
Fixed KGA handling for i810. KGA handling for chips derived from C&T chips
is slightly different. The changes make the code consistent with the
C&T (chips) and i740 drivers.
