We pass in the client that wants to create the device anyway, lets use the
parameter instead of hardcoding the serverClient.
Wow. I hope this is merge detritus, otherwise it'd be a sign that I didn't
have enough coffee that day.
When a new device is added, calculate the event size needed if a DCCE event is
sent and set the EQ's event size to this minimum. This avoids reallocs when a
event is sent (which may happen during a SIGIO).
This variable was used originally to determine which client is allowed to
change the pointer-keyboard pairing. For now, we just let anyone change it and
see how that works out.
Rather than freeing/allocing classes each time the device capabilities need to
swap, store them in the devPrivates system.
When a class is unused, it is pushed into the devPrivates, and later recovered
when needed again. This saves us a lot of memory allocations/frees, admittedly
on the cost of some memory.
The DDX (xfree86 anyway) maintains its own device list in addition to the one
in the DIX. CloseDevice will only remove it from the DIX, not the DDX. If the
server then restarts (last client disconnects), the DDX devices are still
there, will be re-initialised, then the hal devices come in and are added too.
This repeats until we run out of device ids.
This also requires us to strdup() the default pointer/keyboard in
checkCoreInputDevices.
X.Org Bug 14418 <http://bugs.freedesktop.org/show_bug.cgi?id=14418>
The device classes aren't deleted anymore on a class change, so there's no
need to store the MD's original classes. We should however restore the MD to
sane defaults when disconnecting the last device, consider this as TODO item.
Instead of a simple counter, use bits to keep track of which device is where
etc. When device enters a window (or sets focus), the bit matching the device
is set, when it leaves again, it is unset. If there are 0 bits set, then
Leave/Enter/Focus events may be sent to the client.
Same theory as before, but this should get around the insanity with
Grab/Ungrab special cases. Those cases are basically untested though.
InitializeSprite won't create a new one if it already exists, with the result
of overwriting the master's sprite. This master sprite is then assigned to the
floating slave, and freed when the slave is reattached later.
Setting the sprite to NULL forces InitializeSprite to alloc a new one, and
this one can be freed without further repercussions.
XkbFinishDeviceInit does the following:
xkbi->kbdProc= pXDev->kbdfeed->CtrlProc;
pXDev->kbdfeed->CtrlProc= XkbDDXKeybdCtrlProc;
If we directly copy the device classes for the VCK, pXDev->kbdfeed->CtrlProc
at the time of copying is still XbkDDXKeybdCtrlProc. So at some point
XkbDDXKeybdCtrlProc is called, and calls itself, and calls itself, and...
Setting the device's classes to NULL seems to fix things. The memory isn't
lost, it gets stored into the devPrivates and freed at device closing time.
Before we enable the device through the driver, we size it up and make sure
that the events in the event list contain enough bytes for a possible
ClassesChangedEvent lateron.
If two devices are attached to the same master device, pressing button 1 on
each of them leads to two button presses from the same device. Some apps
really don't like that.
So we just put a counter in place and only send the first press and the last
release.
We free the ValuatorClassRec quite regularly. If a SIGIO is handled while
we're swapping device classes, we can bring the server down when we try to
access lastx/lasty of the master device.
XkbInitKeyboardDefviceStruct may call FatalError if it fails. FatalError then
cleans up all the devices, resulting in a segfault if the pointer is
uninitialised.
Old code was fundamentally broken, fixes now are:
- free the MDs current device classes
- copy the device classes instead of flipping the pointers
- check for the old MD, not the new one.
Anything in dev->key, dev->valuator etc. of a MD must always be a copy of the
original class. The intial classes of an MD (the ones set up before an SD is
attached) as well, as we may have to restore them if no SD is attached
anymore.
Each time a different slave device sends through a master, an
DeviceClassesChangedEvent is enqueued. When this event is processed, all
classes of the matching master device are changed, and the event is sent to
the clients.
Next time the master is queried, it thus shows the evclasses of the last slave
device. The original classes are stored in the devPrivates.
TODO: if all slave devices are removed, the master's original classes need to
be restored.
For pointers: don't try to set master->valuator fields if there is no master.
For keyboards: check if device is valid before trying to access the fields in
miPointerGetScreen (btw. this disables DGA events for floating keyboards).
Also stop the hideous number of ErrorFs if we request the paired device for a
floating dev.
XkbRemoveResourceClient wants to access xkbInfo if it exists, so make
sure we NULL it after freeing it. It doesn't make much sense to move
the RemoveResourceClient call first, as there's not much point in
notifying clients while we're shutting the server down anyway.
Floating devices get sprites, but still aren't spriteOwners. This prevents
them from getting rendered, and also stops segfaulting.
(not really solving the problems with keyboards though)
Set isMaster for VCP/VCK.
Init sprites for master pointer devices.
Pair master kbds with master pointers (1:1 pairing!).
Attach other devices to VCP/VCK.
For now, we don't allow attaching slaves to other slaves, and we don't allow
pairing slaves with other slaves.
Pairing is for master keyboard->master pointer only.
Attaching is for slave device->master device only.
We re-pair them with the VCP, not a real device! If we would do otherwise,
somebody may change our keyboard focus and thus get us typing where we don't
want to type.
If the pairing client is not set, then the pairing is initiated internally
(e.g. when a new keyboard device is configured). In this case we _must_ pair
regardless of who is the pairing client.
Unfortunately, more information is needed to properly label the device.
This will come from the configuration file, the hotplug messages, etc.
It will either have to be passed into this function,
or this hook moved down into the callers.
Removes "LookupKeyboardDevice" and "LookupPointerDevice" in favor of
inputInfo.keyboard and inputInfo.pointer, respectively; all use cases
are non-XI compliant anyway.
We need it unconditionally in a few places, and the rest checked for NULL and
then set it to VCK anyway. So, fixing up all callers to appreciate the defined
return value.
EnableDevices is (amongst others )called after a VT switch. We must not create
a new sprite or re-pair the device, otherwise we lose the input device setup
that we had before the VT switch.
This requires the devices to be in exactly the same order as before
the VT switch. Removing a device while on a different VT is probably a bad
idea.
The device state needs to be changed while processing the XI event. Core
events are always processed after XI, so by then the device is already set up
properly. However, we now rely on DeviceButtonMotionMask to be equal to
ButtonMotionMask. It already is, but stick a big fat warning in so nobody
attempts to change it.
This commit disables XKB for the VCK, thus essentially for all devices.
Temporarily anyway.
Add keyc->postdown, which represents the key state as of the last mieqEnqueue
call, and use it when we need to know the posted state, instead of the
processed state (keyc->down). Add small functions to getevents.c to query and
modify key state in postdown and use them all through, eliminating previously
broken uses.
over to new system.
Need to update documentation and address some remaining vestiges of
old system such as CursorRec structure, fb "offman" structure, and
FontRec privates.
Add support for HAL-based hotplugging, in which we just get the list of
input devices and properties from HAL. Requires an FDI which is not yet
in mainline HAL.
Is set when passive grab is implicit as result of a ButtonPress event. If this
is the case, we need to store the XI mask as well as the core mask to ensure
delivery of XI events during the grab's lifetime.
Remove all core grabs on other devices when client issues a GrabPointer or
GrabKeyboard request. Let's assume that the client really only wants one
device to interact, so this seems like a reasonable solution.
Add XGE handling in DeliverGrabbedEvent.
We can now grab something selecting XGE events, but the current code is a
bit messy and doesn't work too well yet.
If we don't do this, a device that is paired before a sprite has been
initialized for the paired device will not actually get the right sprite and
segfault the server on focus events. Happens for the VCK.
Both VCP and VCK are not in the inputInfo.devices list anymore, so we need to
check them separately. If we don't do this, we end up re-using ids 0 and 1,
causing all sorts of grief for clients.
Requires moving the spriteTrace into the DeviceIntRec and adjusting a few
functions to take in device argument, most notably XYToWindow().
Cursor rendering on the second screen is busted.
arbitrary X status codes instead of just TRUE/FALSE.
The dix layer in most cases still does not propagate the return value of
XACE hooks back to the client, however. There is more error propagation
work to do.
Improve memory usage by allocating the sprite's memory only to devices that
actually have a sprite and provide means to remove a device's cursor from the
screen (more hotplugging, yay!).
This commit breaks ScreenRec's ABI.
The former <X11/extensions/XKBsrv.h> has been pulled into the server now as
include/xkbsrv.h, and the world updated to look for it in the new place,
since it made no sense to define server API in an extension header. Any
further work along this line will need to do similar things with XKBgeom.h
and friends.
EnableDevice.
zero out spriteTrace, otherwise GetCurrentRootWindow() may return
invalid data.
Evdev adds previously hotplugged devices on its own when rescanning,
and ActivateDevice does not get called for those devices. Sprites need
to be initialized or paired before the device gets started, so the
safest place to do so is EnableDevice (which actually does get called
by the evdev driver).
dix: IsPointerDevice and IsKeyboardDevice, use same ways to identify type
of device as XI does for the XListInputDevices reply.
Autopair each non-pointer device with VCP when activating, pair with
real device after activation.
Don't return non-keyboard devices when calling GetPairedKeyboard or
PickKeyboard, otherwise we segfault for 'evdev brain'.
state field in the event, rather than using the virtual devices.
ProcessPointerEvent: name argument "device" instead of "other".
Add GetPairedKeyboard().
otherwise a Xi grab may overwrite or release a core grab.
Replace grab and associates with coreGrab and deviceGrab structures,
adjust rest of dix/Xi/etc to compile.
xfree86: Don't check for core devices, we'll have the virtual ones anyway.
If we check, the first mouse device is duplicated and sends
double events.
dix: set coreGrab flag for grabs caused by GrabPointer and button presses.
remove virtual core devices from device list, only real devices are in
the list now.
Auto-pair each keyboard with a real pointer if one is available,
provides multiple keyboards automatically after startup if devices
are configured.
fix GuessFreePointerDevice() to do what it's supposed to do.
mi: fix: call miPointerMove from miPointerWarpCursor.
fix: remove unused id field from miCursorInfoRec
don't update sprite for virtual core pointer.
ambiguious request. PickPointer and PickKeyboard are used for getting
the appropriate pointer when situation is unclear.
Fix some issues with InitializeSprite.
dix, xfree86: Remove last traces of InitSprite.
Free sprite struct if a spriteOwner is paired.
xfree86: Use PairDevices instead of passing booleans around when creating a
sprite.
Xext: Switch back to using LookupPointer/KeyboardDevice instead of
inputInfo.xyz.
Adding PointerKeyboardPairingChanged event
Correct error values for XWarpDevicePointer
dix: Adding device argument to SendMappingNotify
Adding spriteOwner flag to devices
Add a generic 'ring the bell' function (console bell on Linux and BSD,
/dev/audio on Solaris), and add DDX functions for this. Make this the
core keyboard's bell.
Port Xvfb and Xnest to this.
Port XFree86 to this, with OS-specific hooks for Linux, BSD, and Solaris
taken from foo_io.c in the old layer.
