When updating the XKB keymap, make sure the keyboard feedback is also
copied, to preserve autorepeat settings etc.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Single-group keys may get replicated amongst all groups. Check explicitly for
this case and squash it down to one group.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
A single-group key on a multi-group keyboard has to be replicated across all
three groups (see Section 12.4 of the XKB protocol spec). Ensure that there's
enough symbols available to actually do that.
e.g. a key ABCD on a 3 group keyboard needs to be replicated as ABABCDCDABCD,
hence requiring space for 12 symbols, even if maxSymsPerKey is less than that.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
A grep on xorg/* revealed there's no consumer of this define.
Quote Alan Coopersmith:
"The consumer was in past versions of the headers now located
in proto/x11proto - for instance, in X11R6.0's xc/include/Xproto.h,
all the event definitions were only available if NEED_EVENTS were
defined, and all the reply definitions required NEED_REPLIES.
Looks like Xproto.h dropped them by X11R6.3, which didn't have
the #ifdef's anymore, so these are truly ancient now."
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Alloc an EventList once and then re-use instead of allocing a new event each
time we need a master event.
There's a trick included: because all the event processing handlers only take
an xEvent, init a size 1 EventList and squash the events into this one.
Events that have count > 1 must be squished into an xEvent array anyway before
passing into the event handlers, so we don't lose anything here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
We'd like to do soft repeat in the server for all keys. Remove obscure check, that'd
prevent the server from autorepeating when delay is set to exactly 660ms and rate is
set to exactly 25 (interval=40).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
If no rules file is given, simply re-use the previous one. If no RF is given
the first time this function is called, use the built-in default.
This includes fixing the built-in default to something that actually exists.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
The device's button down state array was changed to use DOWN_LENGTH and thus
bitflags for each button in cfcb3da7.
Update the DBSN events to copy this bit-wise state.
Update xkb and Xi to check for the bit flag instead of the array value.
Reported by ajax.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
The warnings corrected were only the ones that should correct
real problems. The most common one is 64 bit integers as
"printf %l" arguments.
Note that there is a patch related to this at:
http://bugs.freedesktop.org/show_bug.cgi?id=18204
This is the biggest "visibility" patch. Instead of doing a "export"
symbol on demand, export everything in the sdk, so that if some module
fails due to an unresolved symbol, it is because it is using a symbol
not in the sdk.
Most exported symbols shouldn't really be made visible, neither
advertised in the sdk, as they are only used by a single shared object.
Symbols in the sdk (or referenced in sdk macros), but not defined
anywhere include:
XkbBuildCoreState()
XkbInitialMap
XkbXIUnsupported
XkbCheckActionVMods()
XkbSendCompatNotify()
XkbDDXFakePointerButton()
XkbDDXApplyConfig()
_XkbStrCaseCmp()
_XkbErrMessages[]
_XkbErrCode
_XkbErrLocation
_XkbErrData
XkbAccessXDetailText()
XkbNKNDetailMaskText()
XkbLookupGroupAndLevel()
XkbInitAtoms()
XkbGetOrderedDrawables()
XkbFreeOrderedDrawables()
XkbConvertXkbComponents()
XkbWriteXKBSemantics()
XkbWriteXKBLayout()
XkbWriteXKBKeymap()
XkbWriteXKBFile()
XkbWriteCFile()
XkbWriteXKMFile()
XkbWriteToServer()
XkbMergeFile()
XkmFindTOCEntry()
XkmReadFileSection()
XkmReadFileSectionName()
InitExtInput()
xf86CheckButton()
xf86SwitchCoreDevice()
RamDacSetGamma()
RamDacRestoreDACValues()
xf86Bpp
xf86ConfigPix24
xf86MouseCflags[]
xf86SupportedMouseTypes[]
xf86NumMouseTypes
xf86ChangeBusIndex()
xf86EntityEnter()
xf86EntityLeave()
xf86WrapperInit()
xf86RingBell()
xf86findOptionBoolean()
xf86debugListOptions()
LoadSubModuleLocal()
LoaderSymbolLocal()
getInt10Rec()
xf86CurrentScreen
xf86ReallocatePciResources()
xf86NewSerialNumber()
xf86RandRSetInitialMode()
fbCompositeSolidMask_nx1xn
fbCompositeSolidMask_nx8888x0565C
fbCompositeSolidMask_nx8888x8888C
fbCompositeSolidMask_nx8x0565
fbCompositeSolidMask_nx8x0888
fbCompositeSolidMask_nx8x8888
fbCompositeSrc_0565x0565
fbCompositeSrc_8888x0565
fbCompositeSrc_8888x0888
fbCompositeSrc_8888x8888
fbCompositeSrcAdd_1000x1000
fbCompositeSrcAdd_8000x8000
fbCompositeSrcAdd_8888x8888
fbGeneration
fbIn
fbOver
fbOver24
fbOverlayGeneration
fbRasterizeEdges
fbRestoreAreas
fbSaveAreas
composeFunctions
VBEBuildVbeModeList()
VBECalcVbeModeIndex()
TIramdac3030CalculateMNPForClock()
shadowBufPtr
shadowFindBuf()
miRRGetScreenInfo()
RRSetScreenConfig()
RRModePruneUnused()
PixmanImageFromPicture()
extern int miPointerGetMotionEvents()
miClipPicture()
miRasterizeTriangle()
fbPush1toN()
fbInitializeBackingStore()
ddxBeforeReset()
SetupSprite()
InitSprite()
DGADeliverEvent()
SPECIAL CASES
o defined as _X_INTERNAL
xf86NewInputDevice()
o defined as static
fbGCPrivateKey
fbOverlayScreenPrivateKey
fbScreenPrivateKey
fbWinPrivateKey
o defined in libXfont.so, but declared in xorg/dixfont.h
GetGlyphs()
QueryGlyphExtents()
QueryTextExtents()
ParseGlyphCachingMode()
InitGlyphCaching()
SetGlyphCachingMode()
Previously each server starting ran xkbcomp with the output set to
<keymapname>.xkm, read it, then deleted it - which led to races if
two servers were starting at the same time with the same keymap.
Sun bug #6773816 Xorg uses the same xkm output file for compiled keymap file
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6773816>
If the event is an XI event, we need to work on the correct device, not on
the VCK.
Adds XIGetDevice(event) function to extract the device from an event.
When MouseKeys are activated, keyboard devices may generate fake mouse button
events through XKB. Let's get then running through the appropriate paths, i.e.
as XI events on the correct device.
To make matters more fun, ProcessOtherEvents drops events if the DIX device
state cannot be updated accordingly, i.e. all button events from keyboard
devices.
Hence we need to get the paired MD for the device in XkbDDXFakeDeviceButton,
and post the event through the paired MD (usually the VCP).
Removes now-unused ddxFakeBtn.c.
Note: this patch only half-arsedly fixed button events, motion events are a
more complicated matter.
A couple of coding style cleanups, a warning fix via removing a
now-unused label, and also put an else so we don't spuriously trip a
condition that should admittedly never occur anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
newTypes is a local variable which always has an address. newTypesIn,
on the other hand, might be sus.
See also 5544c51447.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Was doing only dry-runs, which kinda explains why changing the compat map
didn't really have any effect.
Fallout from e8c2a3d7c9.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
If we update key types from core, and groups 2 - n have a canonical type but
the same symbols as the explicit type of group 1, assume that it was a core
sym duplication according to Section 12.4 of the XKB Protocol Spec.
Ignore the canonical types and pretend there's only one group for the key -
with the explicit key type.
The protocol spec does not cover this case, so we have to guess here.
According to Section 12.4 of the XKB Protocol Spec, if a key only has a single
group but the keyboard has multiple groups defined, the core description of
the key is a duplication of the single group across all symbols. i.e.
G1L1 G1L2 G1L1 G1L2 G1L3 G1L4 G1L3 G1L4
The previous code generated G1L1 G1L2 G1L3 G1L4 G1L3 G1L4, leading to
"invented" groups when the process is reversed.
Note that this creates wrong key types on reconstruction from core to xkb,
i.e. any single-group key with a key type that is not one of the canonical
four (Sec 12.2.3), will get the assigned type on group 1, and a canonical type
for the other gruops.
X.Org Bug 14373 <http://bugs.freedesktop.org/show_bug.cgi?id=14373>
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.
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
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.
- 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.
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.
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.
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 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.
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.
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?
(cherry picked from commit 7a97ca667405a42d008265c3a870210cc1da97dd)
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>
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.
