This is copied from linux/input.h, presumably that's the ones at least the
Linux kernel can give us for any device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This mirrors that in KeyClassRec: the state of the buttons as posted to
GetPointerEvents, rather than the state of the buttons as processed by
ProcessOtherEvent and friends.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Everything goes through XKB's Process{Keyboard,Pointer}Event on its way
through to ProcessOtherEvent now, so get rid of the old, useless functions.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-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>
Replace both core and Xi functions with one function that validates the
proposed map, and sends out both kinds of notification.
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>
XIShouldNotify just lets you know if you should send an event for a
keymap change (or similar) concerning a given device to a given client;
at the moment, this is only for devices which are sending events to that
client.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn two unsigned chars into one unsigned int for both vmods and the
vmod mask. As a bonus, remove broken unused accessor macro for setting
the vmods.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn four unsigned chars into one unsigned long.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn vmods from two unsigned chars into one int.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For some reason, we insist on having daft internal representations that
make no sense, that always have to be converted to be used. We should
really sort this one out.
Also, comment the hojillion members of XkbStateRec.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We don't use them, as they're not up to the task. We'll get a better
solution someday, promise.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we find something weird in the rules, don't stash it as an extra
freeform component, just state that the rules file is likely broken and
move on with our lives.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have modmap (in the exact same format!) in XKB, so just use
that all the time, instead of duplicating the information.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since modifierKeyMap is generated from modifierMap, just remove it, and
only generate it when we need to send the modifier map to the client.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have state fully stored within XKB, so instead of duplicating it,
just generate the values to send to clients when required.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
XkbRMLVOSet is just a set of strings for rules, model, layout, variant
and options; use that in preference to XkbRF_VarDefsRec, which is a
hideously complicated monster that somehow managed to not include the
actual rules.
While we're at it, clean up xkbrules.h so it doesn't require xkbstr.h.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of hardcoding base/pc105/us, allow users to change the defaults at
./configure time. Change the default model to be evdev on Linux.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This fixes the following bug. Assuming your window manager grabs
Alt+Button1 to move windows, map Button3 to 0 via XSetPointerMapping,
then press the physical button 3 (this shouldn't have any effect), press
Alt and then button 1. The press event is delivered to the application
instead of firing the grab.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note: properties don't need to be cleaned up, the DIX does it for us anyway.
Data that is stored in properties is cleaned up by the property system.
Handlers, etc. don't need to be unregistered while cleaning up, as they get
deleted when the device is removed anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Simon Thum <simon.thum@gmx.de>
If the MD's lastSlave was a devices with custom axes ranges, then a
WarpPointer would position the cursor at the wrong location. A WarpPointer
request provides screen coordinates and these coordinates were scaled to the
device range before warping.
This patch consists of two parts:
1) in the WarpPointer handling, get the lastSlave and post the event through
this device.
2) assume that WarpPointer coordinates are always in screen coordinates and
scale them to device coordinates in GPE before continuing. Note that this
breaks device-coordinate based XWarpDevicePointer calls (for which the spec
isn't nailed down yet anyway) until a better solution is found.
X.Org Bug 19297 <http://bugs.freedesktop.org/show_bug.cgi?id=19297>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This property is used to denote type float for input properties. Such
properties can be accessed easily through the XIPropToFloat() function.
Code originally written by Simon Thum.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Converts an XIPropertyValuePtr to an integer, provided that type and format is
right.
Code originally written by Simon Thum.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
This commit moves the focus handling from events.c into enterleave.c and
implements a model similar to the core enter/leave model.
For a full description of the model, see:
http://lists.freedesktop.org/archives/xorg/2008-December/041740.html
This commit also gets rid of the focusinout array in the WindowRec, ditching
it in favour of a local array that keeps the current focus window for each
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of keeping a flag on each window for the devices that are in this
window, keep a local array that holds the current pointer window for each
device. Benefit: searching for the first descendant of a pointer is a simple
run through the array.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The builtin-fonts configure option was removed, as it at best should
have been a runtime option. Instead, now it always register all "font
path element" backends, and adds built-ins fonts at the end of the
default font path.
This should be a more reasonable solution, to "correct" the most
common Xorg FAQ (could not open default font 'fixed'), and also don't
break by default applications that use only the standard/historical
X Font rendering.
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>
All .a libraries were converted to .la, and instead of linking the
Xorg binary with a mix of .a and .la, and adding some libraries more
then once in the command line, etc, now it generates a single libxorg.la
from all the required convenience libraries, and links with a dummy
xorg.c (that should usually be the file with the main function...).
This removes the requirement of some things like libosandcommon and
libinit, that existed to circumvent problems when linking multiple
.a and .la in the final Xorg binary.
The "symbol table" is now generated dynamically, by a shell script,
with an embedded gawk parser that parses cpp output. The new file
sdksyms.sh is generated by hand by analyzing all Makefile.am's and
making it create a sdksyms.c file, that includes all sdk headers that
will add symbols for the Xorg binary. Module headers aren't read, and
a in 2 files it was required to add a "<hash>ifndef XorgLoader" around
declarations shared between the Xorg binary and libextmod. A few
other changes were added to other sdk headers, like preventing
multiple inclusion, or including other headers to satisfy dependencies.
This should be a lot more portable, and better (hopefully properly)
using libtool to generate convenience libraries.
Those tables were once used to decide what symbols are visible to
modules, but they were outdated. The only real usage was that, since
it was taking the address of symbols, linkage should fail if the
symbols were not available.
Now the proper way to make symbols available to modules should
be to use the _X_EXPORT macro, or not compile with hidden symbols,
so that all symbols would be available.
All symbols in the tables were revised to ensure they are exported,
and only symbols that were not exported are ClientSleepUntil() and
DuplicateModule(), that were not in the sdk for quite some time
already, and should not have any users outside of the X Server
(and/or builtin modules).
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).
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
