| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A pointer device should be able to send events while the client has a core
grab on a keyboard device, and likewise.
|
|
|
|
|
|
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.
|
|
In some cases a button press may activate a passive core grab. If the client
owning the passive grab already has a core grab on another device, don't
actually activate it. Otherwise the client gets two simultaneous passive
core grabs, and may never ungrab the device again (only if the other grab uses
GrabModeSync).
Reproducable: fire up gnome-session, open up gnome-terminal. Click with the
ClientPointer onto the window decoration, then click with another pointer onto
an application icon in the panel. Drag the icon out, release the button and
voila - you just lost your second mouse.
|
|
This is just papering over a problem. The whole focus system needs to be
revised.
|
|
This is a half-assed attempt at getting rid of some enter-leave problems. When
a grab is activated, the events didn't get sent before, leading to interesting
results. This commit papers over it but doesn't actually fix it properly. The
whole enter/leave (focusin/out) structure needs to be ripped out and changed
for multiple devices.
|
|
|
|
Let the drivers only generate XI events and put those into the event queue.
When processing events, generate core events as needed. This fixes a number of
problems with XKB and the DIX in general.
The previous approach was to put core events and XI events as separate events
into the event queue. When being processed, the server had no knowledge of
them coming from the same device state change. Anything that would then change
the state of the device accordingly was in danger of changing it twice,
leading to some funny (i.e. not funny at all) results.
Emulating core events while processing XI events fixes this, there is only one
path that actually changes the device state now. Although we have to be
careful when replaying events from synced devices, otherwise we may lose
events.
Note: XI has precedence over core for passive grabs, but core events are
delivered to the client first.
This removes the wrapping added in 340911d7243a7f1095d79b5b2dcfa81b145c2474
|
|
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.
|
|
|
|
Raw events can be generated for pointer events, so 2 + MVE isn't enough.
|
|
|
|
|
|
Also stick another warning in, more changes needed for XGE if panoramix is
active.
|
|
|
|
|
|
|
|
The device passed through to UnrealizeCursor isn't used anyway, so setting it
to NULL is enough.
|
|
GenericEvents can't be parsed to keyButtonPointer, and there's no guarantee
that it has a time field anyway. PlayReleasedEvent needs to store the millis
when we know it (core events, XI event) and just re-use them for GenericEvents.
Yes, this is a hack. But it looks like the time has zero significance anyway.
|
|
DDE is not always called, grabbed or focused devices go through
Deliver{Grabbed|Focus}Event first.
Thanks to Eamon Walsh for spotting it.
|
|
GenericEvents can be > sizeof(xEvents), so we need to make sure we're
allocating and copying enough memory for the event.
|
|
|
|
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.
|
|
FixKeyState needs to be able to handle XI events, otherwise we get "impossible
keyboard events" on server zaps and other special key combos.
|
|
If a device is paired with the VCP, deleting the VCP before the device will
segfault the server when the sprite should get updated.
|
|
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.
|
|
This reverts commit 6b055e5d9751e3679ff98065e43225ec8a960053.
MPX relies on the XI event being delivered before the core event. Device grabs
break, amongst other things. I guess stuck modifiers need to be fixed some
other way.
Conflicts:
dix/getevents.c
|
|
We shouldn't be able to restrict events like Expose, etc. with device based
ACLs. So we just ignore all non-input events when checking for permissions.
|
|
Thanks to Ben Close for spotting it.
|
|
This should fix the random segfaults with ProcUngrabKeyboard.
Thanks to David Nolden for spotting it.
|
|
Conflicts:
Xi/exevents.c
dix/devices.c
dix/getevents.c
include/dix.h
mi/mieq.c
|
|
|
|
A passive core grab doesn't specify the device, and is thus created with the
ClientPointer as device. When this grab is activated later, don't actually
activate the grab on the grab device, but rather change the device to the one
that caused the grab to activate. Same procedure for keyboards.
Makes core apps _A LOT_ more useable and reduces the need to set the
ClientPointer.
Only applies to core grabs!
|
|
Taking the VCK is only correct if no physical device is connected, and even
then it's not really a good idea.
|
|
Checking for VCP/VCK is simply not a safe way to check if a grab is a core grab.
|
|
automake 1.10 really wants foo.c for foo.O, so give it some dummy files to
deal with if it really needs them.
|
|
Disclaimer: It's 6:51am. I'm trying to be as understandable as possible.
What was happening previously was this:
* Press Alt
* Extended event generated and processed: state is now Alt down once
* Core event generated
- keyboard switched: inherited state is Alt down once
- event processed: Alt down twice
* Release Alt
* Extended event generated and processed: state is now null
* Core event generated and processed: Alt down once
If we switch the order:
* Press Alt
* Core event generated:
- keyboard switched: inherited state is null
- event processed: Alt down once
* Extended event generated and processed: state is now Alt down once
* Release Alt
* Core event generated and processed: state is now null
* Extended event generated and processed: state is now null
When we carry over the previous state, it needs to be the _previous_ state
(state and modifiersPerKey), assuming that we're going to catch now-core
events for any of these. For example, if Ctrl is held down as we pivot, we
need to carry Ctrl over with a count of one, for which an extended + core
release will then clear. Carrying over the union of the previous state _and
the state resulting from the immediate action_ was what broke things.
|
|
Convert all my license statements to the standard, accepted form:
cf. <20070717142307.GD13478@fooishbar.org>
http://lists.freedesktop.org/archives/xorg/2007-July/026451.html
keithp's license on configure.ac changed with his verbal permission.
|
|
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.
|
|
For some reason, my keyboard has 25 mouse buttons, but zero valuators. This
causes GPE to blow up spectacularly, trying to get (and set) co-ordinates from
devices without valuators. For now, just prevent this from ever happening,
and whack a dirty great FIXME in.
|
|
Move the null root cursor handling out of main() and into CreateRootCursor.
|
|
Make sure the font path is always 'built-ins' when we use built-in fonts,
rather than having it as a fixed path for a while, then clobbering it
halfway through startup.
|
|
Break up D-Bus into two components: a D-Bus core that can be used by any
part of the server (for the moment, just the D-Bus hotplug API, and the
forthcoming HAL hotplug API), and the old D-Bus hotplug API.
|
|
|
|
|
|
Call CheckMotion from ProcessOtherEvents() to make sure absolute XI events
update the sprite before an event is sent.
|
|
|
|
We need to do this to update the sprites x/y coordinate before we assemble a
button event. Absolute devices may send a buttonEvent with valuators attached.
If we don't update the sprite before assembling the event, the valuators are
lost and the button press is delivered to the previous position of the device.
Doesn't have any effect on relative devices.
|
