| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
X.Org Bug 15614 <http://bugs.freedesktop.org/show_bug.cgi?id=15614>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
|
|
If input processing is frozen, only wrap realInputProc: don't smash
processInputProc as well. When input processing is thawed, pIP will be
rewrapped correctly.
This supersedes the previous workaround in 50e80c9.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
An astute observer will note that the entirety of XkbCopyKeymap is indented
with spaces, and no tabs whatsoever, and not commit changes which break the
otherwise consistent indentation.
A non-astute observer will note the breakage when the commit mail comes
through with clearly broken indentation.
A polite, non-astute, observer will then fix it.
C'est la vie.
|
|
|
|
(cherry picked from commit 2a47accff8dccded4dfe031f9366c028ba927824)
|
|
Due to an unwitting sense inversion when eliminating XkbFileInfo, we were
setting the complete wrong keymap on startup (non-XKB map if we had an XKB
map available, or the XKB map if we didn't have any available). Invert the
sense properly, and add two small bits that also went missing in that commit.
|
|
|
|
|
|
During XkbInitKeyboardDevice, we compiled a keymap and promptly threw it away;
brief inspection revealed the embarassingly simple problem. Sorry.
|
|
Sorry about the megacommit, but this touches on a lot of stuff.
Get rid of XkbFileInfo, which was pretty seriously redundant, and move the
only useful thing it had (defined) into XkbDescRec. defined will be removed
pretty soon anyway. Is the compat map pointer non-NULL? Then you have a
compat map, congratulations! Anyhow, I digress.
All functions that took an XkbFileInfoPtr now take an XkbDescPtr, _except_
XkmReadFile, which returns an XkbDescPtr *, because people want to deal in
XkbDescPtrs, not XkbDescRecs.
|
|
We don't do XKBsrv.h anymore.
|
|
We were forgetting to set the sizes for sections and rows and a couple of
other misc bits in XkbCopyKeymap's geometry. Sort that out, and add a
couple of clarifying comments along the way.
|
|
Don't load prebuilt keymaps anymore.
|
|
Since we're no longer sharing with Xlib, don't pass Displays and XPointers
everywhere.
|
|
We have SEEK_SET and size_t, seriously. Also use DebugF instead of
ifdef DEBUG, and ditch a couple of random bits that were never used.
|
|
There's no point in having the function definitions be conditional, so
whatever.
|
|
We need to start breaking the XKB API to enforce sanity, so drag whichever
headers we need to do so into the server tree, as the client API is set in
stone, being part of Xlib.
|
|
Get rid of the XKB errors code to save a bunch of space.
|
|
Opening a device is not really "reading" it.
Requests that globally configure a device should require "manage" access.
|
|
It actually does help if a pointer is NULL rather than pointing to nirvana
when you're trying to free it lateron. Who would have thought?
|
|
|
|
In some weird cases we call this function when there is no SrvLedInfo on the
device. And it turns out null-pointer dereferences are bad.
X.Org Bug 13961 <http://bugs.freedesktop.org/show_bug.cgi?id=13961>
|
|
Previously, we'd just keep num_sections at 0, which would break the
geometry and lead us to leak sections. Don't do that.
|
|
Conflicts:
Xext/EVI.c
Xext/bigreq.c
Xext/cup.c
Xext/dpms.c
Xext/fontcache.c
Xext/mitmisc.c
Xext/xcmisc.c
Xext/xf86bigfont.c
Xext/xtest.c
configure.ac
dbe/dbe.c
hw/darwin/darwin.h
hw/darwin/darwinEvents.c
hw/darwin/iokit/xfIOKit.h
hw/darwin/iokit/xfIOKitCursor.c
hw/darwin/quartz/fullscreen/fullscreen.c
hw/darwin/quartz/fullscreen/quartzCursor.c
hw/darwin/quartz/quartz.c
hw/darwin/quartz/quartzCommon.h
hw/darwin/quartz/quartzCursor.c
hw/darwin/quartz/xpr/dri.c
hw/darwin/quartz/xpr/dristruct.h
hw/darwin/quartz/xpr/xprCursor.c
hw/darwin/quartz/xpr/xprFrame.c
hw/xfree86/modes/xf86RandR12.c
include/cursor.h
miext/rootless/rootlessCommon.h
miext/rootless/rootlessScreen.c
miext/rootless/rootlessWindow.c
render/picturestr.h
Trying to pick up the pieces from the darwin churn here...
|
|
Don't run VT switches, terminations, or anything, on the core keyboard: only
run actions which affect the keyboard state. If we get an action such as VT
switch, just swallow the event.
|
|
Make sure we send the correct event for the type of device when we're
sending key repeat events, which stops repeats being sent to incorrect
windows.
|
|
This reverts commit a5cf3f21f712e46dbf9bca289e67be75f2b531d3.
Moving all the names into dix/registry.c
|
|
Conflicts:
hw/xnest/Pixmap.c
include/dix.h
|
|
|
|
Conflicts:
dix/dispatch.c
dix/property.c
hw/xfree86/common/xf86VidMode.c
include/xkbsrv.h
render/glyph.c
xkb/xkbActions.c
|
|
alloca has no way to return failure, and instead can possibly arbitrarily
overflow the stack. Let's avoid that one.
|
|
Cope with Xi and pointer events in the (now increasingly misnamed)
XkbProcessKeyboardEvent. If it's the wrong type, call through the wrapping
chain to get out; else, process it.
|
|
Don't get XkbUpdateIndicators to update the indicators on all our devices: we
already deal with that ourselves.
Add exevents.h include to get more (proto)types.
|
|
Instead of hardcoding CoreProcessPointerEvent, actually try to unwrap properly
and then call the unwrapped processInputProc. Seems to be a better idea,
especially since it makes stuff actually work...
(cherry picked from commit 8f9bf927e1beecf9b9ec8877131ec12c765e4d84)
|
|
This is hopefully better than hardcodey calling CoreProcessPointerEvent.
(cherry picked from commit 32d0440c7f6e604807cb14dd32349df6f22c903b)
|
|
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.
(cherry picked from commit 6334d4e7be18de5f237c12a6dc20f75aa23477d0 with some
additional compile fixes and non-MPX adaptations)
|
|
using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to
process DeviceKeyEvents after the first key press.
This should be the correct fix now.
(cherry picked from commit 4d5df14f2c4a3108a8c8adfcf4766c0d1a9daad2)
|
|
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.
(cherry picked from commit bfe6b4d2d9952a80f8dbc63eec974ef894e5c226)
|
|
|
|
Removes "LookupKeyboardDevice" and "LookupPointerDevice" in favor of
inputInfo.keyboard and inputInfo.pointer, respectively; all use cases
are non-XI compliant anyway.
|
|
Introduces new dix API to lookup a device, dixLookupDevice(), which
replaces LookupDeviceIntRec and LookupDevice.
|
|
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.
|
|
|
|
This has never worked in any modular server release, and as far as I know
was never tested in 6.7 through 6.9.
|
|
Apparently it needed to be nSyms*15/10, not *12/10; make it match the
other allocation code.
|
|
Make sure size_types will _always_ be 0 if we don't have any types.
|
|
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.
|
|
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).
|
|
Make sure we're not copying sym_interpret across from an empty source.
|
