The fact that this has been in place so long makes me really wonder if
anybody cares about this running in Tiger or Leopard.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
It seems like make dist should be doing te right thing without this commit,
but it's not in some cases. Don't ask me to explain why.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
The generated event does not have axes other than X and Y and has a
newer timestamp. In particular, the newer timestamp may be newer than
the real touch end event, which may be stuck in the syncEvents queue. If
a client uses the timestamps for grabbing bad things may happen.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
A request, like input device grabs, may check a request timestamp
against currentTime. It is possible for currentTime to lag a previously
sent event timestamp. If the client makes a request based on such an
event timestamp, the request may fail the validity check against
currentTime unless we always update the time before processing the
request.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch is physically active, the pointer core state should reflect
that the first button is pressed. Currently, this only occurs when there
are active listeners of the touch sequence. By moving the device state
updating to the beginning of touch processing we ensure it is updated
according to the processed physical state no matter what.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code checks the core event mask as though it were an XI
mask. This change fixes the checks so the proper client and event masks
are used.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently, the touch is only logically ended if the touch has physically
ended. If the touch hasn't physically ended, the touch record is never
ended. If there aren't any more listeners, we don't need to keep the dix
touch record around any more.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
As a special case, if a still physically active pointer emulated touch
has no listeners and the device is explicitly grabbed for pointer
events, create a new dix touch record for the grab only.
This allows for clients to "hand off" grabs. For example, when dragging
a window under compiz the window decorator sees the button press and
then ungrabs the implicit grab. It then tells compiz to grab the device,
and compiz then moves the window with the pointer motion. This is racy,
but is allowed by the input protocol for pointer events when there are
no other clients with a grab on the device.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The function will be used for building a sprite for pointer emulation
after an explicit device grab. This commit refactors the code so that
TouchBuildSprite will function with any event type and moves the checks
to the caller.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Pointer passive grabs may be changed by the grabbing client. This allows
for a selecting client to change an implicit grab to an active grab,
which is the mechanism used for pop-up windows like application menus.
We need to do the same thing with touches. If the grabbing client is the
owner of a touch sequence, change the listener record to reflect the new
grab. If the grabbing client is not the owner, nothing changes for the
touch.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fake touch end events are generated by touch acceptance and rejection.
These should not cause implicit pointer grabs to be deactivated.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fake end events are generated by touch acceptance or rejection. These
should not end the touch point.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We still need to generate the touch ownership event to process the
ending of the touch event in the case where the owner has the end
already.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
See UpdateCurrentTime() for reference. I don't know what bug this might
trigger, but it wouldn't hurt to fix this.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Explicit pointer grabs are placed at the head of the touch listener
array for pointer emulated touches. If the grab is deactivated, we must
remove it from all touches for the device.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a bit of unimplemented code for touchscreen pointer emulation. A
pointer grabbing client currently never accepts the touch sequence. The
sequence must be accepted once any touch-derived event is irrevocably
delivered to a client.
The first pointer event, derived from a touch begin event, may be caught
in a sync grab and then replayed. This is essentially a revocable
delivery of an event. Thus, we must wait till a non-begin event is
delivered.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This will be used for accepting and rejecting touches in the future.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code returns a reference to memory that may not actually be
an XI2 mask. Instead, only return a value when an XI2 client has
selected for events.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code checks the core event mask as though it were an XI2
mask. This change fixes the checks so the proper client and event masks
are used.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
The ResourceSizeRec now contains the number of references to the
resource. For example a Pixmap knows this value and it can be useful
for determining the "weight" of the resource. Typically this value
is 1.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
The generic hashtable implementation adds a key-value container, that
keeps the key and value inside the hashtable structure and manages
their memory by itself. This data structure is best suited for
fixed-length keys and values.
One creates a new hash table with ht_create and disposes it with
ht_destroy. ht_create accepts the key and value sizes (in bytes) in
addition to the hashing and comparison functions to use. When adding
keys with ht_add, they will be copied into the hash and a pointer to
the value will be returned: data may be put into this structure (or if
the hash table is to be used as a set, one can just not put anything
in).
The hash table comes also with one generic hashing function plus a
comparison function to facilitate ease of use. It also has a custom
hashing and comparison functions for hashing resource IDs with
HashXID.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Calls to Hash(client, id) were replaced with calls directly to
HashResourceID(id, clientTable[client].hashsize) and the Hash-function
was removed.
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
The public hashing function HashResourceID uses the same hashing
hashing algorithm as resource.c uses internally, but it provides an
interface that will is usable by external modules. It provides a
parameter for the number of bits for the hash, instead of finding the
size from its internal hash table.
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
The mechanism allows iterating even through subresources that don't
have specific XID's. When such 'resources' are iterated, the XID for
them will be zero. A resource type can assign an iteration function
for its subresources with SetResourceTypeFindSubResFunc; by default
resources are assumed not to contain subresources.
The purpose of this extension is to enable accurate accounting of
the resources a resource consumes or uses.
This patch provides the subresource iteration functions for Windows
and GCs.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
This patch implements a part of the XResource extension v1.2 (as specified in
http://patchwork.freedesktop.org/patch/2720/ ). The request implemented is
X_XResQueryClientIds.
This patch depends on the feature introduced by
1e933665be "dix: Add facilities for
client ID tracking." .
This latest version also adds Doxygen-formatted comments and takes a better
notice of coding conventions (as in http://www.x.org/wiki/CodingStyle ).
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
QueryPointer is part of the core protocol. As such, it knows nothing
about touch devices. Touches are converted to button 1 press, pointer
motion, and button 1 release for core clients, so we should ensure the
pointer state mask has button 1 set when XQueryPointer is used.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Issue:
* Two sequential touches (i.e. down, up, down, up)
* Both are grabbed by a touch grab
* Both have a second listener in the form of a pointer grab or selection
* The second and first touches are rejected in that order
The first touch must be pointer emulated before the second touch, so the
second touch must be paused until the first touch is rejected or
accepted and all events are delivered to pointer clients.
This change ensures all pointer emulated events are emitted
sequentially. It necessarily imposes a delay on further touch events
when pointer grabs and selections are used, but there is no way around
it.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just like when we deliver to a touch listener, we must convert a touch
end event to an update event for further clients. This also ensures that
the touch record is not deleted at the end of ProcessTouchEvent().
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After the pointer grab is deactivated, the touch listener record is
updated at the end of DeliverTouchEmulatedEvent. However, the touch
record is ended when the grab is deactivated, so the update to the
listener record is in an array of memory that has been freed.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device was enabled before the VT switch, re-enabled it. Otherwise leave
it as is, there was probably a reason why it was disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Events from button-only devices still need coordinates, and they get them
from scale_to_desktop(). Therefore, a dev without valuators is not a bug.
However, a dev with valuators, but less than two of them still is a bug.
This was noticed when unplugging a "Creative Technology SB Arena Headset",
which has some BTNs and some KEYs, but no REL or ABS valuators.
It emits [BTN_3] = 0 on unplug, which would trigger the BUG_WARN.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the result of re-running the 'x-indent.sh' script over
xf86vmode.c to clean up the disaster caused by broken syntax in the
file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Inside the unfinished XF86VIDMODE_EVENTS #ifdef block the
function definition for xf86VidModeNotifyEvent had an extra ');'
before the prototype argument declarations. This was harmless for the
compiler as the code never gets used, but completely messed up the
file re-indentation. This patch removes the spurious characters in
preparation for re-indenting the file.
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 55f552adb6.
This appears to cause a crash at init time instead of close.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Acked-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
As a PE platform, all symbols in both EXEs and DLLs must be resolved
at link time. As Xorg modules depend on symbols in the Xorg
executable, we must build Xorg before its modules, creating an implib
from the former which is used to link the latter. This implib must
then be installed in order to build the drivers.
Currently only two drivers are supported on Cygwin: xf86-video-dummy
(to replace Xvfb/Xfake) and xf86-video-nested (to replace Xnest/Xephyr).
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Cygwin doesn't have ELF rpath capabilities, so these libraries need
to be loaded before the drivers (namely dummy and nested) which
depend on their symbols.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This is necessary when building Xorg and XWin simultaneously, otherwise
undefined symbol errors result in sdksyms.c.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>