| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
And make sure os.h is included in files that use it.
|
|
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
|
|
|
|
Really not necessary, we can just walk the list and spare us the special
treatment of the VCK.
|
|
|
|
Core events don't happen until later in the DIX, so pump device events down
instead. This makes modifiers work again when SlowKeys is enabled.
|
|
|
|
|
|
|
|
|
|
Again, hasn't worked since at least 7.0.
|
|
Remove a whole bunch of code that was never built, be it entire files or
just dead ifdefs.
|
|
|
|
|
|
|
|
device->button->down used to be a 32-byte bitmask with one bit for each
button. This has changed into a 256-byte array, with one byte assigned for
each button. Some of the callers were still using this array as a bitmask
however, this is fixed with this patch.
Thanks to Keith Packard for pointing this out. See also:
http://lists.freedesktop.org/archives/xorg/2008-June/036202.html
|
|
|
|
|
|
Could lead to some invalid pointers in the second server generation.
|
|
We only have one set of default rules options in xkb. When the second keyboard
is brought up with Xkb options specified, these new options overwrite the old.
In future server generations, the rules used for the VCK are a mixture of the
default ones and ones previously specified for other keyboards. Simply
resetting the xkb default rules to NULL avoids this issue.
Reproducable by setting XkbLayout "de" and XkbVariant "nodeadkeys". In the
second server generation, the VCK has "us(nodeadkeys)". This again produces a
SIGABRT when the first key is hit.
I could not figure out why the SIGABRT happens. This patch is avoiding the
issue rather than fixing it.
|
|
|
|
|
|
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
|
|
|
|
When something went wrong building a keymap, try to explain to the user
what it actually was, instead of the dreaded 'Failed to load XKB keymap'
catch-all.
|
|
Conflicts:
Xext/EVI.c
Xext/appgroup.c
Xext/cup.c
Xext/mitmisc.c
Xext/sampleEVI.c
dix/window.c
|
|
X.Org Bug 15614 <http://bugs.freedesktop.org/show_bug.cgi?id=15614>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
|
|
|
|
- map can be NULL in some cases, so don't try to dereference it.
- don't default to inputInfo.keyboard
This is firefighting, I presume something in the class copy may have gone
wrong to get a NULL map in the first instance?
|
|
|
|
XkbFinishDeviceInit is called once when the device is initialised, but also
when a class copy causes the key class of a device to change. In this case, overwriting the CtrlProc of the KeybdFeedbackClass with XkbDDXKeybdCtrlProc sets up a nice recursive loop of XkbDDXKeybdCtrlProc calling itself until the cows come home.
|
|
Conflicts:
Xext/xevie.c
dix/dispatch.c
|
|
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)
|
|
This merge reverts Magnus' device coorindate scaling changes. MPX core event
generation is very different, so we can't scale in GetPointerEvents.
Conflicts:
Xi/opendev.c
dix/devices.c
dix/dixfonts.c
dix/getevents.c
dix/resource.c
dix/window.c
hw/xfree86/common/xf86Xinput.c
mi/mipointer.c
xkb/ddxBeep.c
xkb/ddxCtrls.c
xkb/ddxKeyClick.c
xkb/ddxList.c
xkb/ddxLoad.c
xkb/xkb.c
xkb/xkbAccessX.c
xkb/xkbEvents.c
xkb/xkbInit.c
xkb/xkbPrKeyEv.c
xkb/xkbUtils.c
|
|
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.
|
