| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
This makes the code more consistent with other versions of
out-of-queue event processing
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This removes all of the SIGIO handling support used for input
throughout the X server, preparing the way for using threads for input
handling instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO.
v2: Don't change locking order (Peter Hutterer)
v3: Comment weird && FALSE in xf86Helper.c
Leave errno save/restore in xf86ReadInput
Squash with stub adding patch (Peter Hutterer)
v4: Leave UseSIGIO config parameter so that
existing config files don't break (Peter Hutterer)
v5: Split a couple of independent patch bits out
of kinput.c (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.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>
|
|
-Wlogical-op now tells us:
devices.c:1685:23: warning: logical ‘and’ of equal expressions
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Wrong use of the mask here caused a beep whenever a key was rejected but
also when it was released after being accepted. Fix the mask to check
for the correct enabled controls.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
|
|
Globally replace #ifdef and #if defined usage of 'sun' with '__sun'
such that strict ISO compiler modes such as -ansi or -std=c99 can be used.
Signed-off-by: Richard PALO <richard@NetBSD.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
Add a new event source type for keypress events synthesised from focus
notifications (e.g. KeymapNotify from the parent server, when running
nested). This is used to keep the keys-down array in sync with the host
server's, without sending actual keypress events to clients.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Add a flag to DeviceEvents, giving the source of the event. Currently
this only supports a 'normal' flag, but will be used later to add a
'focus-in' flag, noting events synthesised from key/button arrays on
focus-in notifications.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Move the giant state machine which maps from a key action to actually
running the filters into a separate function, to be used when adding
KeyFocusIn.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
With this change, when a key mapped to an action to emulate mouse button
presses and releases is held down, other keys pressed during that time are
still processed normally. This is a prerequisite for proper support of
ISOLock.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
The autorepeat for these actions was not correctly implemented, as the key
repeat would be mistakenly interpreted as key releases. Rather than fixing
this, this change simply disables autorepeat for Set/Lock actions, for two
reasons:
- Autorepeating Set/Lock keys make complicate the interactions of actions.
- Autorepeating Set/Lock keys have no apparent benefit, but hurt in the real
world for layouts such as de(neo): Neo has a Level5 shift on the LSGT key,
and a Level5 lock on Level5 of the same key. This is unusable if LSGT
autorepeats. However, disabling autorepeat for key LSGT completely is not
ideal for users that have a "usual" layout besides Neo, where LSGT carries
symbols.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
|
|
Ensure that the given strings length in an XkbSetGeometry request remain
within the limits of the size of the request.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The XkbSetGeometry request embeds data which needs to be swapped when the
server and the client have different endianess.
_XkbSetGeometry() invokes functions that swap these data directly in the
input buffer.
However, ProcXkbSetGeometry() may call _XkbSetGeometry() more than once
(if there is more than one keyboard), thus causing on swapped clients the
same data to be swapped twice in memory, further causing a server crash
because the strings lengths on the second time are way off bounds.
To allow _XkbSetGeometry() to run reliably more than once with swapped
clients, do not swap the data in the buffer, use variables instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
sed -i "s/[ ]\+$//g" **/*.(c|h)
happy reviewing...
git diff -w is an empty diff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
When _XkbCheckAtoms returns NULL for an error, it always sets the
error return code, but GCC can't figure that out, so just initialize
the local variable, 'bad', in _XkbSetNamesCheck to eliminate the warning.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
XkbInterestPtrs are created by clients that already exist, meaning,
clients that have already had ProcVector installed as something other
than InitialProcVector.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Check the return values from fread to make sure the elements are
actually getting read from the file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
|
|
This was the wrong fix to the problem, and it triggered a change in XKB
behavior: previously a button event would unlock a latched modifier, now it
doesn't anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=73155
Note that the new behavior is is strictly spec compliant but we've had the
other behavior for a long time so we shouldn't break it.
The bug this patch originally fixed was a null-pointer dereference when
releasing button events on server shutdown. This was addressed by the commit
below, so the need for this patch has gone away anyway.
commit 3e4be4033aed78b2bb3a18d51f0963989efd1af3
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jan 25 11:47:32 2013 +1000
dix: when shutting down slave devices, shut down xtest devices last
This reverts commit 2decff6393a44b56d80d53570718f95354fde454.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Removed in d35a02a767017f13db4bd4742eef49293d5a30ea, 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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Helper function to return a default map if the keymap compilation failed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
This provides a callback to write to xkbcomp's buffer once everything is
prepared.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.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>
|
|
Reviewed-by: Kristian Høgsberg <krh@bitplanet.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>
|
|
No functional changes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
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>
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
Add const to lots of strings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
If the -ardelay or -arinterval options have no argument, there's no
point trying to read it.
See
http://www.forallsecure.com/bug-reports/feb3db57fc206d8df22ca53a6907f74973876272/
Reported-by: Alexandre Rebert <alexandre@cmu.edu>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If drivers supply incorrect values don't just quietly return False, spew to
the log so we can detect what's going on. All these cases are driver bugs
and should be fixed immediately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
|
|
InitPointerClassDeviceStruct/InitKeyboardDeviceStruct allocate a
proximity/focus class, respectively. If a driver calls
InitFocusClassDeviceStruct or InitProximityClassDeviceStruct beforehand,
the previously allocated class is overwritten, leaking the memory.
Neither takes a parameter other than the device, so we can simply skip
initialising it if we already have one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
|
|
==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>
|
|
The main problem this patch addresses is that if a latch is put on
multi-level key with a Latch/Lock/Set, it is possible that after all
keys are released, still base modifiers are set, which typically will
make the keyboard unusable. To see how it happens (without the patch),
assume that key AltGr sets Mod5 when pressed by itself, and latches Mod3
when pressed together with Shift. Now press Shift, then AltGr and
release both keys in reverse order. Mod3 is now latched, and the
LatchMods filter remains active as the second filter. Now press AltGr;
Mod5 base modifier gets set, and the SetMods filter will become active
as the first filter. Release AltGr: First, the SetMods filter will set
clearMods to Mod5, then the LatchMods filter will overwrite clearMods
with Mod3. Result: the Mod5 base modifier will remain set. This
example becomes practically relevant for the revised German standard
layout (DIN 2137-1:2012-06).
Other changes implement the latch behaviour more accurately according to
the specification. For example, releasing a modifier latching key can
at the same time clear a locked modifier, promote another modifier that
is latched to locked, and latch a third modifier. Overall, what the
code does should be straightforward to compare what the XKB protocol
specification demands, see the table in section 6.3.
Finally, releasing a key no longer cancels a latch that has not become
pending yet. In my opinion, the specification is not clear; it speaks
of "operating" a key, which the patch effectivly interprets as "press"
rather than "press or release". From my experience, using the latter
interpretation makes latches on higher levels practically unusable. In
the example given above, one would have to release AltGr always before
Shift to get the Mod3-Latch. The practical relevance of latches on
higher levels is once more given by the revised German standard layout.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Xlib doesn't use this value (it computes it from the reply length
instead) which is why nobody has noticed yet. But the spec
http://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html
says that it should be set.
Signed-off-by: Peter Harris <pharris@opentext.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
xkb.c: In function '_XkbSetNamesCheck':
xkb.c:3987:18: warning: variable 'names' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
|
|
The redirect and the message action filter functions implicitly assumed that
when they receive an event for the same keycode they were activated for, that
this is the a release of the key that activated the filter. This is not true
if the key autorepeats. Due to the incorrect assumption, the effective key
repeat rate was effectively halved.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The base group is not brought into range and, therefore, using it as an array
index crashed the X server. Also, at this place, we should ignore locked
groups, but not latched groups. Therefore, use sum of base and latched groups,
brought into range.
Reproducible with:
key <FK07> {
type= "ONE_LEVEL",
symbols[Group1]= [ NoSymbol ],
actions[Group1]= [ LatchGroup(group=-1, clearLocks) ]
};
And hitting F7 will exceed the group level and access arbitrary memory.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
I checked this patch with diff -w to check that it only affected
whitespace.
|
|
The formatter confused address operators preceded by casts with
bitwise-and expressions, placing spaces on either side of both.
That syntax isn't used by ordinary address operators, however,
so fix them for consistency.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Regression introduced by commit 2decff6393a44b56d80d53570718f95354fde454
xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP
XTest buttons must be released when a physical button is released. This was
fixed in 14327858391ebe929b806efb53ad79e789361883, but
2decff6393a44b56d80d53570718f95354fde454 changed a condition that this code
didn't get triggered anymore.
"dev" for pointer events is now always the VCP which doesn't have a xkbi
struct. So move this condition out and always trigger the XTest released for
button events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Frank Roscher <Frank-Roscher@gmx.net>
|
|
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>
|
