These functions are entry points of the DDX (or stubs thereof), not supposed
to be called by any drivers, so no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These aren't used by any drivers/modules, and it doesn't seem make much
sense doing so, thus no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are only used inside xkb internally, so no need to keep them
in a public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These are only used inside xkb, not by any drivers, so no need to
keep them in public header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This (public) file isn't used by anybody outside Xserver tree
and doesn't contain anything useful anymore, so lets drop it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1729>
This function is only used inside the same .c file where it's defined,
no outside users, also not in drivers. Thus no need to keep it exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1468>
This is to make sure the hardware gets the device states regardless
whether the internal state has changed or not, to overcome situations
that device LEDs are out of sync e.g. switching between VTs.
Signed-off-by: Yao Wei (魏銘廷) <yao.wei@canonical.com>
Let's move this to where all the other protocol handlers are.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
XKB stores some stuff in the ClientRec that, style-wise, should probably
be in a client private. vMinor tracks the client's idea of the XKB
minor version, but is never read, we can just nuke it. vMajor is only
used for a bug-compat workaround for X11R6.0-vintage clients. We're
only using though (1<<4) for xkbClientFlags in the protocol, so we can
pack that field down to a u8 and store the bug-compat flag there.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
The xserver generates the key repeat by itself.
But when used with another server processing inputs first (e.g. a
Wayland compositor), the other server may be busy dealing with some
other things and not queue up key release events in time.
Add a vfunc in XkbSrvInfo to possibly add a check before re-emitting a
keypress event in the AccessX timer handler, so that the key repeat has
a chance to be denied if the server processing the input is not ready.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When NumLock is on and a new keymap is applied, the next modifier state
change will turn off that LED (but leave the state enabled). The cause
for this is a bit convoluted:
* the SLI explicitState is copied from the current state in
ProcXkbGetKbdByName. Thus, if NumLock is on, that state is 0x2.
* on the next modifier key press (e.g. Shift), XkbApplyState() calls into
XkbUpdateIndicators() -> XkbUpdateLedAutoState() to update SLIs (if any)
for the currently changed modifier. But it does so with a mask only for
the changed modifier (i.e. for Shift).
* XkbUpdateLedAutoState() calculates the state based on this mask and
ends up with 0 because we don't have a Shift LED and we masked out the
others.
* XkbUpdateLedAutoState() compares that state with the previous state
(which is still 0x2) and then proceeds to turn the LED off
This doesn't happen in the normal case because either the mask
encompasses all modifiers or the state matches of the masked-out
modifiers matches the old state.
Avoid this issue by forcing an SLI update after changing the keymap.
This updates the sli->effectiveState and thus restores everything to
happy working order.
https://bugzilla.redhat.com/show_bug.cgi?id=1047151
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Even though -Wcomment doesn't mind it (in gcc or clang), the appearance
of */* confuses the syntax highlighter of some editors (eg. vim), and
causes warnings in MSVC.
Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Removed in d35a02a767, tigervnc 1.2.80 and
xf86-video-nested need it for now.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This will also make it useful for cases when we have a new keymap to
apply to a device but don't have a source device.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Whenever the master changes, push the locked modifier state to the attached
slave devices, then update the indicators. This way, when NumLock or CapsLock
are hit on any device, the LED will light up on all devices. Likewise, a new
keyboard attached to a master device will light up with the correct
indicators.
The indicators are handled per-keyboard, depending on the layout, i.e. if one
keyboard has grp_led:num set, the NumLock LED won't light up on that keyboard.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Just forcing everything to const char* is not helpful, compiler warnings are
supposed to warn about broken code. Forcing everything to const when it
clearly isn't less than ideal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
==2547== 1 bytes in 1 blocks are still reachable in loss record 1 of 111
==2547== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2547== by 0x64D1551: strdup (strdup.c:43)
==2547== by 0x4802FB: Xstrdup (utils.c:1113)
==2547== by 0x585B6C: XkbSetRulesUsed (xkbInit.c:219)
==2547== by 0x58700F: InitKeyboardDeviceStruct (xkbInit.c:595)
==2547== by 0x419FA3: vfbKeybdProc (InitInput.c:74)
==2547== by 0x425A3D: ActivateDevice (devices.c:540)
==2547== by 0x425F65: InitAndStartDevices (devices.c:713)
==2547== by 0x5ACA57: main (main.c:259)
and a few more of the above.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
eventType is set for the type that triggered a XkbControlsNotify event.
Technically, SlowKeys is triggered by a timer which doesn't have a matching
core event type. So we used to use 0 here.
Practically, the timer is triggered by a key press + hold and cancelled when
the key is released before the timeout expires. So we might as well set
KeyPress (keycode) in the ControlsNotify to give clients a chance to differ
between timer-triggered SlowKeys and client-triggered ones.
This is a chance in behaviour, though I suspect with little impact.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
No-one uses this - not xkbcomp, not GNOME, not KDE. The preferred way
to deal with component listing (which gives you RMLVO rather than
KcCGST) is to use the XML files on the client side.
Indeed, a couple of hours after making this commit, it emerged that all
*.dir files built with xkbcomp 1.1.1 (released two years ago) and later
have been catastrophically broken and nearly empty. So I think that's
reasonable proof that no-one uses them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Why sending the number of the (implementation-dependent) error statement to
the client is a good idea is a bit beyond me, but at least document it so we
can all share the despair.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
../../include/xkbsrv.h:308:51: warning: redundant redeclaration of
‘DeviceKeyPress’ [-Wredundant-decls]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Cleans up around 120 warnings from this set
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
The two functions have identical semantics, including safely returning
NULL when NULL is passed in (which POSIX strdup does not guarantee).
Some callers could probably be adjusted to call libc strdup directly,
when we know the input is non-NULL.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
If a button release event is posted for the MD pointer, post a release event
through the matching XTEST device. This way, a client who posts a button
press through the XTEST extension cannot inadvertedly lock the button.
This behaviour is required for historical reasons, until server 1.7 the core
pointer would release a button press on physical events, regardless of the
XTEST state. Clients seem to rely on this behaviour, causing seemingly stuck
grabs.
The merged behaviour is kept for multiple keyboard PointerKey events, if two
physical keyboards hold the button down as a result of PointerKey actions,
the button is not released until the last keyboard releases the button.
X.Org Bug 28808 <http://bugs.freedesktop.org/show_bug.cgi?id=28808>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Problem:
lockedPtrButtons keeps the state of the buttons locked by a PointerKeys button
press. Unconditionally clearing the bits may cause stuck buttons in this
sequence of events:
1. type Shift + NumLock to enable PointerKeys
2. type 0/Ins on keypad to emulate Button 1 press
→ button1 press event to client
3. press and release button 1 on physical mouse
→ button1 release event to client
Button 1 on the MD is now stuck and cannot be released.
Cause:
XKB PointerKeys button events are posted through the XTEST pointer device.
Once a press is generated, the XTEST device's button is down. The DIX merges
the button state of all attached SDs, hence the MD will have a button down
while the XTEST device has a button down.
PointerKey button events are only generated on the master device to avoid
duplicate events (see XkbFakeDeviceButton()). If the MD has the
lockedPtrButtons bit cleared by a release event on a physical device, no
such event is generated when a keyboard device triggers the PointerKey
ButtonRelease trigger. Since the event - if generated - is posted through
the XTEST pointer device, lack of a generated ButtonRelease event on the
XTEST pointer device means the button is never released, resulting in the
stuck button observed above.
Solution:
This patch merges the MD's lockedPtrButtons with the one of all attached
slave devices on release events. Thus, as long as one attached keyboard has
a lockedPtrButtons bit set, this bit is kept in the MD. Once a PointerKey
button is released on all keyboards, the matching release event is emulated
from the MD through the XTEST pointer device, thus also releasing the button
in the DIX.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure all of the private keys used by the test code are
initialized before being used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Robert Hooker <sarvatt@ubuntu.com>
This patch only changes the API, not the implementation of the
devPrivates infrastructure. This will permit a new devPrivates
implementation to be layed into the server without requiring
simultaneous changes in every devPrivates user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com>
The name XkbDDXFakeDeviceButton and XkbDDXFakeDeviceMotion is somewhat
misleading, there's no DDX involved in the game at all anymore.
This removes XkbFakeDeviceMotion and XkbFakeDeviceButton from the API where
it arguably shouldn't have been in the first place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Section 4.6.1 of the XKB spec says that "the initial event always moves the
cursor the distance specified in the action [...]", so skip the
POINTER_ACCELERATE flag for GPE, it would cause double-acceleration.
Potential regression - GPE expects the coordinates to be either relative or
both. XKB in theory allows for x to be relative and y to be absolute (or
vice versa). Let's pretend that scenario has no users.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
XKB really XKBdoes not XKBneed its own XKBdefines for XKBeverything.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Signed-off-by: Keith Packard <keithp@keithp.com>
Since it's typedef'd to XkbConvertCase anyway and the headers are now split
from the client headers, simply get rid of it altogether.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Bonus point - it's easier to understand what's actually being done with the
memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Signed-off-by: Keith Packard <keithp@keithp.com>
Please no extension-specific macros for memory allocation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For core and XI1 events, store the key_repeat flag in the sequence number
until TryClientEvents. The sequenceNumber is unset until TryClientEvents.
[Also thrown in, some random indentation changes. Thanks]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Before dropping down into the DIX, convert back into XI events. This is a
temporary solution only, until the DIX is capable of handling InternalEvents
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Changes MakeAtom to take a const char * and NameForAtom to return them,
since many callers pass pointers to constant strings stored in read-only
ELF sections. Updates in-tree callers as necessary to clear const
mismatch warnings introduced by this change.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of always keeping two copies of the keymap, only generate the
core keymap from the XKB keymap when we really need to, and use the XKB
keymap as the canonical keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Keyboard map notifications are always generated from within XKB code,
which also takes care of copying the keysyms, etc. If you need to
mangle the keymap yourself, generate a new core keymap/modmap, and pass
it to XkbApplyMappingChange.
SendMappingNotify is renamed to SendPointerMappingNotify (and ditto its
Device variants), which still only _sends_ the notifications, as opposed
to also doing the copying a la XkbApplyMappingChange.
Also have the modmap change code traverse the device hierachy, rather
than just going off the core keyboard.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XkbInitKeyboardDeviceStruct is now the only valid keyboard
initialisation: all the details are hidden behind here. This now makes
it impossible to supply a core keymap at startup.
If dev->key is valid, dev->key->xkbInfo->desc is also valid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No more #ifdef XKB, because you can't disable the build, and no more
noXkbExtension either.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For some reason, XKB allows clients to set a global (!) flag that simply
turns lock keys into state no-ops. Ignore this flag.
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).
These symbols were removed from the X Server, or never declared.
One symbol that may need special attention is XkbBuildCoreState(),
that doesn't have a prototype anywhere, but is called from
xkb/xkbEvents.c:XkbFilterEvents(), and also used by the macros
XkbStateFieldFromRec() and XkbGrabStateFromRec() defined in
include/xkbstr.h.
fb/wfbrename.h also may need some cleanup, as it makes several
"renames" of non existing symbols.
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.
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>
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 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.
Enrico Weigelt, metux IT consult
Yao Wei
Peter Hutterer
Adam Jackson
Mihail Konev
Olivier Fourdan
Peter Harris
Kristian Høgsberg
Rui Matos
Keith Packard
Daniel Stone
Alan Coopersmith
Rami Ylimäki
Adam Tkac
Alan Coopersmith
Paulo Cesar Pereira de Andrade
Peter Hutterer
Peter Hutterer
Thomas Jaeger