Merge remote-tracking branch 'whot/for-keith'

Xi: Allow clients to ask for 2.3 and then 2.2 without failing

This allows different sub-systems within the same application to
request different Xi versions without either getting old behaviour
everywhere or simply failing with a BadValue.

Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

xfree86: detach scanout pixmaps when detaching output GPUs

Commit 8f4640bdb9d3988148e09a08d2c7e3bab1d538d6 fixed a bit of a
chicken-and-egg problem by detaching GPU screens when their providers
are destroyed, which happens before CloseScreen is called.  However,
this created a new problem: the GPU screen tears down its RandR crtc
objects during CloseScreen and if one of them is active, it tries to
detach the scanout pixmap then.  This crashes because
RRCrtcDetachScanoutPixmap tries to get the master screen's screen
pixmap, but crtc->pScreen->current_master is already NULL at that
point.

It doesn't make sense for an unbound GPU screen to still be scanning
out its former master screen's pixmap, so detach them first when the
provider is destroyed.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

dix: set the valuator mask to ensure XI 1.x events have data

XI 1.x only allows for first + num valuators, so if a device sends data for
valuators 0 and 2+ only (i.e. valuator 1 is missing) we still need to get
the data for that from somewhere.
XI 1.x uses the hack of an unset valuator mask to get the right coordinates,
i.e. we set the value but don't set the mask for it so XI2 events have the
right mask.

For an absolute device in relative mode, this broke in b28a1af55cf, the
value was now always 0. This wasn't visible on the cursor, only in an XI 1.x
client. The GIMP e.g. sees jumps to x/0 every few events.

Drop the condition introduced in b28a1af55cf, data in valuators is always
absolute, regardless of the mode.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: check the xi2mask, not the grab type for touch listeners

grab->type is only non-zero for passive grabs. We're checking an active grab
here, so we need to check if the touch mask is set on the grab.

Test case: grab the device, then start two simultaneous touches. The
grabbing client won't see the second touchpoints because grab->type is 0
and the second touch is not an emulating pointer.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

hw/xwin: Fix numerous 64-bit format/type cast issues with debug printing of pointers

Numerous pieces of debug output cast a pointer to an int and then use a "%08x"
printf format.

Use "%p" format for 64-bit portability.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Fix possible crash in winMultiWindowGetClassHint

Fix a possible crash in winMultiWindowGetClassHint() when an application doesn't
null terminate the WM_CLASS property class name (which is an ICCCM conformance
bug in the application)

(Reported for running the contiki cooja simulator in multiwindow mode, although
it seems that many Java clients may have this problem, see [1])

Based on a patch by Marc Haesen.

v2: Avoid using strnlen() which is missing on MinGW
v3: Align with Xming patch

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6961123

Signed-off-by: Colin Harrison <colin.harrison@virgin.net>
Reviewed-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>

hw/xwin: Remove obsolete WIN_XEVENTS_SHUTDOWN

Remove obsolete WIN_XEVENTS_SHUTDOWN.  This event is never generated.

(I think the idea was to listen for WM_DELETE_WINDOW, but that's not a very
useful thing to do for a hidden window.)

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

configure.ac: Check for python at configure time when building XWin with AIGLX

Check for python at configure time when building XWin with AIGLX, it's used to
generate the wrapper code for native GL functions.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Avoid a null dereference if CreateDIBSection() fails in NetWMToWinIconAlpha()

Avoid a null dereference of DIB_pixels if CreateDIBSection() fails in
NetWMToWinIconAlpha()

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Handle WM_MOUSEHWHEEL

Handle WM_MOUSEHWHEEL tilt wheel messages, similarly to WM_MOUSEWHEEL scroll
wheel messages, to generate X button 6 and 7 presses and releases.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Map extra mouse buttons 1 and 2 to X buttons 8 and 9

Map extra mouse buttons 1 and 2 to X buttons 8 and 9, as conventional, leaving X
buttons 6 and 7 for tilt wheel.

Also add button labels for buttons 6, 7, 8 and 9 and change btn_labels in from a
dynamic allocation to a fixed one of the required size for all the labels we
use.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Remove unneeded WM_XBUTTON message defines

Remove unneeded WM_XBUTTON message defines, they have been provided by w32api
for a long time now.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Change winTranslateKey() to return it's result as it's return value

Change winTranslateKey() to return it's result as it's return value, and change
it's uses as well.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Consider left and right modifier keys independently on gaining focus

Handle left and right ctrl and shift keys independently

Assume that all modifiers are cleared when all keys are released on focus lost,
as internalKeyState doesn't record which modifier key was pressed.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Remove an extra '\n' from some log messages

Remove an extra '\n' from internal client IOError log messages

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: _NET_WM_STATE is ATOM[] not ATOM

_NET_WM_STATE is ATOM[] not ATOM, a list of window state hints, so check all of
the atoms, not just the first one

See EWMH specifcation, section "Application Window Properties"

v2: Actually use [] on the returned atom data

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Improve WM_ENDSESSION handling using separate messaging window thread

Currently, WM_ENDSESSION just calls GiveUp() to set the DE_TERMINATE flag. But
for the X server to exit cleanly, we also need the X server dispatch loop to be
unblocked so it can notice that DE_TERMINATE has been set and exit, removing
it's lock file and any unix domain socket.

It appears that the system will terminate the process when the last UI thread in
that process returns from processing WM_ENDSESSION for the last top-level
window.

Since WM_ENDSESSION appears to sent by the system via SendMessage()
(synchronously) and the wndproc is called to process it in the message thread
for that window (the X server thread), we can't easily terminate the X server
dispatch loop from inside the WM_ENDSESSION message processing.

So, create a messaging window, a hidden, top-level window, with a separate
thread to catch this message, and process it by calling GiveUp() and then
blocking on a mutex until the X server dispatch loop exits.

Also, notice when this is a shutdown cancel WM_ENDSESSION message and take no
action.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Allow DDX to provide a main()

XQuartz already conditionally renames main() as dix_main() so it can provide
it's own main().  This isn't the ideal way of doing this, as it prevents libdix
built this way from being useful with any other DDX.

So instead, always name that function dix_main(), and also provide a stub main()
which just calls dix_main(), which can be overriden in the DDX.

Add a main() to XWin (XQuartz already has one, of course).

It's no longer neccessary to link XWin and XQuartz with libmain.

v2: Remove unneeded stub main hw/xwin/InitOutput.c

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Merge remote-tracking branch 'alanc/master'

dix: scale y back instead of x up when pre-scaling coordinates

The peculiar way we handle coordinates results in relative coordinates on
absolute devices being added to the last value, then that value is mapped to
the screen (taking the device dimensions into account). From that mapped
value we get the final coordinates, both screen and device coordinates.

To avoid uneven scaling on relative coordinates, they are pre-scaled by
screen ratio:resolution:device ratio factor before being mapped. This
ensures that a circle drawn on the device is a circle on the screen.

Previously, we used the ratio to scale x up. Synaptics already does its own
scaling based on the resolution and that is done by scaling y down by the
ratio. So we can remove the code from the driver and get approximately the
same behaviour here.

Minor ABI bump, so we can remove this from synaptics.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Emmanuel Benisty <benisty.e@gmail.com>

Fix typo in header guard.

Signed-off-by: Thomas Klausner <wiz@NetBSD.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Xephyr: Use _XEatDataWords (from Xlib 1.6) instead of _XEatData

Simplifies code and reduces risk of overflow from converting length
field in X replies from words to bytes.

One call to _XEatData is left in ephyrHostGLXGetStringFromServer where
it's already been checked for overflow, and other values have been
subtracted from it to reduce the size of data remaining to be eaten.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

glxproxy: Use _XEatDataWords (from Xlib 1.6) instead of _XEatData

Reduces risk of overflow from converting length field in X replies
from words to bytes.   (Also seems to be what several calls were
already incorrectly passing to _XEatData.)

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

glxproxy: Use _XReadPad instead of _XEatData to clean up the slop

Xlib already provides a function to eat padding bytes after the
data read, so use it instead of calculating it ourselves.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Xephyr: integer overflow in XF86DRIGetClientDriverName()

clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>

Xephyr: integer overflow in XF86DRIOpenConnection()

busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>

Xephyr: integer overflow in ephyrHostGLXGetStringFromServer()

reply.length & reply.size are CARD32s and need to be bounds checked before
multiplying or adding to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Xdmx: integer overflow in GetGLXFBConfigs()

numFBConfigs & numAttribs are CARD32s and need to be bounds checked before
multiplying by structure sizes to come up with the total size to allocate,
to avoid integer overflow leading to underallocation and writing data from
the network past the end of the allocated buffer.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Xdmx: integer overflow in GetGLXVisualConfigs()

numVisuals & numProps are both CARD32 and need to be bounds checked before
multiplying by structure sizes to come up with the total size to allocate,
to avoid integer overflow leading to underallocation and writing data from
the network past the end of the allocated buffer.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

dix: allow a ConstantDeceleration between 0 and 1 (#66134)

A constant deceleration of x simply means (delta * 1/x). We limited that to
values >= 1.0f for obvious reasons, but can also allow values from 0-1.
That means that ConstantDeceleration is actually a ConstantAcceleration, but
hey, if someone needs it...

X.Org Bug 66134 <http://bugs.freedesktop.org/show_bug.cgi?id=66134>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

dix: UpdateTouchesForGrab must only free the listener grab if it is non-NULL

If a client calls XIGrabDevice in response to a ButtonPress event (regular
event selection), the device will have a grab, but listener->grab is NULL.

Check for that, to avoid logspam.

[ 26293.863] (EE) BUG: triggered 'if (!pGrab)'
[ 26293.863] (EE) BUG: grabs.c:256 in FreeGrab()
[ 26293.863] (EE)
[ 26293.863] (EE) Backtrace:
[ 26293.864] (EE) 0: /usr/bin/Xorg (FreeGrab+0x54) [0x45d3fc]
[ 26293.864] (EE) 1: /usr/bin/Xorg (UpdateTouchesForGrab+0x135) [0x447d4e]
[ 26293.864] (EE) 2: /usr/bin/Xorg (ActivatePointerGrab+0x1ba) [0x447f3d]
[ 26293.864] (EE) 3: /usr/bin/Xorg (GrabDevice+0x3e6) [0x4503bc]
[ 26293.864] (EE) 4: /usr/bin/Xorg (ProcXIGrabDevice+0x1f9) [0x5981b1]
[ 26293.865] (EE) 5: /usr/bin/Xorg (ProcIDispatch+0x78) [0x58aa17]
[ 26293.865] (EE) 6: /usr/bin/Xorg (Dispatch+0x30d) [0x43347e]
[ 26293.865] (EE) 7: /usr/bin/Xorg (main+0x61d) [0x498175]
[ 26293.865] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3df5621b75]
[ 26293.865] (EE) 9: /usr/bin/Xorg (_start+0x29) [0x423a19]
[ 26293.866] (EE) 10: ? (?+0x29) [0x29]
[ 26293.866] (EE)

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

config: provide example configuration for multi-seat setups

Seats other than seat0 need custom configuration. Provide that with a
default configuration file so we can share it across distros.

This file intentionally does not end in .conf so it won't get picked up by
the server after a normal installation. gdm, or whatever starts up the
servers will have to explicitly specifiy this config file.

This file replaces the one currently written by systemd's multi-seat-x
binary:
http://cgit.freedesktop.org/systemd/systemd/tree/src/login/multi-seat-x.c

CC: Lennart Poettering <lennart@poettering.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>

Fix mouse header include on DragonFly and FreeBSD

*  __FreeBSD_kernel_version doesn't exist anymore

* The removed check was for FreeBSD versions from before September 2000
  which are no longer supported anyway

* Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66045

Signed-off-by: François Tigeot <ftigeot@wolfpond.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

os: Remove any old logfile before trying to write to it

If we are not backing up logfiles, remove the old logfile before trying to write
a new logfile, as otherwise the operation may fail if the previous logfile was
created by a different user.

This change is useful when:
- The DDX doesn't use the logfile backup mechanism (i.e. not Xorg)
- The DDX is run by a non-root user, and then by a different non-root user
- The logfile directory doesn't have the restricted-deletion flag set

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Acked-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: when ungrabbing an active grab, accept pointer grabs (#66720)

Ungrabbing a device during an active touch grab rejects the grab. Ungrabbing
a device during an active pointer grab accepts the grab.

Rejection is not really an option for a pointer-emulated grab, if a client
has a button mask on the window it would get a ButtonPress emulated after
UngrabDevice. That is against the core grab behaviour.

X.Org Bug 66720 <http://bugs.freedesktop.org/show_bug.cgi?id=66720>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>

xkb: don't call atoi(NULL) when parsing argv

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>

Revert "DRI2: re-allocate DRI2 drawable if pixmap serial changes"

This reverts commit 3209b094a3b1466b579e8020e12a4f3fa78a5f3f.  After a
long debug session by Paul Berry, it appears that this was the commit
that has been producing sporadic failures in piglit front buffer
rendering tests for the last several years.

GetBuffers may return fresh buffers with invalid contents at a couple
reasonable times:

- When first asked for a non-fake-front buffer.
- When the drawable size is changed, an Invalidate has been sent, and
  obviously the app needs to redraw the whole buffer.
- After a glXSwapBuffers(), GL allows the backbuffer to be undefined,
  and an Invalidate was sent to tell the GL that it should grab these
  appropriate new buffers to avoid stalling.

But with the patch being reverted, GetBuffers would also return fresh
invalid buffers when the drawable serial number changed, which is
approximately "whenever, for any reason".  The app is not expecting
invalid buffer contents "whenever", nor is it valid.  Because the GL
usually only GetBuffers after an Invalidate is sent, and the new
buffer allocation only happened during a GetBuffers, most apps saw no
problems.  But apps that do (fake-)frontbuffer rendering do frequently
ask the server for the front buffer (since we drop the fake front
allocation when we're not doing front buffer rendering), and if the
drawable serial got bumped midway through a draw, the server would
pointlessly ditch the front *and* backbuffer full of important
drawing, resulting in bad rendering.

The patch was originally to fix bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=28365
Specifically:

    To reproduce, start with a large-ish display (i.e. 1680x1050 on my
    laptop), use the patched glxgears from bug 28252 to add the
    -override option.  Then run glxgears -override -geometry 640x480
    to create a 640x480 window in the top left corner, which will work
    fine.  Next, run xrandr -s 640x480 and watch the fireworks.

I've tested with an override-redirect glxgears, both with vblank sync
enabled and disabled, both with gnome-shell and no window manager at
all, before and after this patch.  The only problem observed was that
before and after the revert, sometimes when alt-tabbing to kill my
gears after completing the test gnome-shell would get confused about
override-redirectness of the glxgears window (according to a log
message) and apparently not bother doing any further compositing.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>

Merge remote-tracking branch 'jturney/master'

hw/xwin: Update manifest to target all architectures, not just x86

Update manifest to target all architectures, not just x86

Also: Write explicit dependencies for Xwin.rc.  XWin.exe.manifest and X.ico are
included the resource compiler output, so add a dependency on them to cause it
to be recompiled if they change.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Win32 Windows properties are of pointer type HANDLE, not an integer type

Win32 Windows properties are of pointer type HANDLE, not an integer type, but we
use the Windows property WINDOW_WID_PROP to store the X window XID.

Add appropriate casts to show it doesn't matter that an XID is smaller than a
pointer on 64-bit build.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: winMultiWindowGetTransientFor() returns an XID not a WindowPtr

winMultiWindowGetTransientFor() accesses the WM_TRANSIENT_FOR property, which is
an X window XID (which we compare with WINDOW_WID_PROP) and not a WindowPtr.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Change winIconIsOverride() to take a HICON parameter

Change winIconIsOverride() to take a HICON parameter, so some unneccessary
casts, which weren't portable to 64-bit Cygwin, can be removed.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Fix uses of CreateDialogParam() for 64-bit builds

Fix uses of CreateDialogParam() to be more strictly correct, for 64-bit builds

dwInitParam parameter is LPARAM, not int
Return type of DLGPROC is INT_PTR, not WINBOOL

Also: Reporting the value of g_hDlgDepthChange is completely uninteresting, we
are just interested in GetLastError() if it is NULL

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: deprecated interface cygwin_conv_to_win32_path() doesn't exist in 64-bit cygwin

The deprecated interface cygwin_conv_to_win32_path() doesn't exist in 64-bit
cygwin, but both the ID_ABOUT_CHANGELOG control and the referenced file who's
path we are converting haven't existed for a while, so just remove this unused,
cygwin-specific code.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

hw/xwin: Fix a 64-bit portability issue with casting HINSTANCE result of ShellExecute() to an integer

Fix a 64-bit portability issue with casting HINSTANCE result of ShellExecute()
to an integer: Since HINSTANCE is a pointer type, use INT_PTR rather than int.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

config: add a quirks file for devices needing special configuration

This is the fedora quirks file configuring the special handling some devices
need. Rather than keeping this distro-specific add it to the tree so we can
share these quirks.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>

dix: add missing dixFreeRegistry define

Fixes a build failure on debian's udeb builds.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: remove logspam in RefCursor()

This shouldn't have been in the patch

Reported-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

Merge remote-tracking branch 'whot/unreviewed'

Merge remote-tracking branch 'whot/touch-grab-race-condition-56578-v3'

Merge remote-tracking branch 'whot/for-keith'

dix: devices must have valuators before touch is initialized

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: fix device scaling to use a [min,max[ range.

defmin/defmax are screen coords and thus use a min-inclusive, max-exclusive
range. device axes ranges are inclusive, so bump the max up by one to get the
scaling right.

This fixes off-by-one coordinate errors if the coordinate matrix is used to
bind the device to a fraction of the screen. It introduces an off-by-one
scaling error in the device coordinate range, but since most devices have a
higher resolution than the screen (e.g. a Wacom I4 has 5080 dpi) the effect
of this should be limited.

This error manifests when we have numScreens > 1, as the scaling from
desktop size back to screen size drops one device unit.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: pre-scale x by the screen:device:resolution ratio

commit 61a99aff9d33728a0b67920254d2d4d79f80cf39
    dix: pre-scale relative events from abs devices to desktop ratio (#31636)

added pre-scaling of relative coordinates coming from absolute devices to
undo uneven scaling based on the screen dimensions.

Devices have their own device width/height ratio as well (in a specific
resolution) and this must be applied for relative devices as well to avoid
scaling of the relative events into the device's ratio.

e.g. a Wacom Intuos4 6x9 is in 16:10 format with equal horiz/vert
resolution (dpi). A movement by 1000/1000 coordinates is a perfect diagonal
on the tablet and must be reflected as such on the screen.

However, we map the relative device-coordinate events to absolute screen
coordinates based on the axis ranges. This results in an effective scaling
of 1000/(1000 * 1.6) and thus an uneven x/y axis movement - the y
axis is always faster.

So we need to pre-scale not only by the desktop dimenstions but also by the
device width/height ratio _and_ the resolution ratio.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Abstract cursor refcounting

Too many callers relied on the refcnt being handled correctly. Use a simple
wrapper to handle that case.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: call UpdateDeviceState() for emulated TouchEndEvents

ProcessTouchEvents() calls UDS for all touch events, but if the event type
was switched to TouchUpdate(pending end) UDS is a noop.

Daniel Drake found this can cause stuck buttons if a touch grab is
activated, rejected and the touch event is passed to a regular listener.
This sequence causes the TouchEnd to be changed to TouchUpdate(pending end).

The actual TouchEnd event is later generated by the server once it is passed
to the next listener. UDS is never called for this event, thus the button
remains logically down.

A previous patch suggested for UDS to handle TouchUpdate events [1], however
this would release the button when the first TouchEvent is processed, not
when the last grab has been released (as is the case for sync pointer
grabs). A client may thus have the grab on the device, receive a ButtonPress
but see the button logically up in an XQueryPointer request.

This patch adds a call to UDS to TouchEmitTouchEnd(). The device state must
be updated once a TouchEnd event was sent to the last grabbing listener and
the number of grabs on the touchpoint is 0.

[1] http://patchwork.freedesktop.org/patch/13464/

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: devices must have valuators before touch is initialized

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: fix warning - remove unused 'rc'

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: fix cursor refcounting

The cursor is referenced during CopyGrab(), thus doesn't need to be handled
manually anymore. It does need to be refcounted for temp grabs though.

The oldGrab handling in ProcGrabPointer is a leftover from the cursor in the
grab being refcounted, but the grab itself being a static struct in the
DeviceIntRec. Now that all grabs are copied, this lead to a double-free of
the cursor (Reproduced in Thunderbird, dragging an email twice (or more
often) causes a crash).

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

ephyr: add -resizeable to the man page

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>

ephyr: fix typo in man page

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Shadow: Switch the Amiga/Atari bitplane code to the canonical X.Org license

Also add my name to the list of authors in COPYING

Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Keith Packard <keithp@keithp.com>

dix: free the old grab when activating a new grab

A client may call XIGrabDevice twice, overwriting the existing grab. Thus,
make sure we free the old copy after we copied it. Free it last, to make
sure our refcounts don't run to 0 and inadvertantly free something on the
way.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: check for HAS_ACCEPTED only for grab listeners

If we have one listener left but it's not a grab, it cannot be in
LISTENER_HAS_ACCEPTED state.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Move TouchListenerGone call to CloseDownClient

TouchListenerGone cleans up if a client disappears. Having this in
FreeGrab() triggers cyclic removal of grabs, emitting wrong events. In
particular, it would clean up a passive grab record while that grab is
active.

Move it to CloseDownClient() instead, cleaning up before we go.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: remove all listeners when freeing a touch

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: always copy grabs, don't reference them

Introduced in xorg-server-1.13.99.901-2-g9ad0fdb. Storing the grab pointer
in the listener turns out to be a bad idea. If the grab is not an active
grab or an implicit grab, the pointer stored is the one to the grab attached
on the window. This grab may be removed if the client calls UngrabButton or
similar while the touch is still active, leaving a dangling pointer.

To avoid this, copy the grab wherever we need to reference it later. This
is also what we do for pointer/keyboard grabs, where we copy the grab as
soon as it becomes active.

Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: AllocGrab can copy if an argument is passed in

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: freeing a null grab is a bug, complain if doing so

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: use a temporary variable for listeners[0]

no functional changes

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: drop DeviceIntRec's activeGrab struct

Obsolete since 4bc2761ad5ec2d0668aec639780ffb136605fbc8. This struct
existed so copying a passive grab could be simply done by
  activeGrab = *grab

and thus have a copy of the GrabPtr we'd get from various sources but still
be able to check device->grab for NULL.

Since 4bc2761 activeGrab is a pointer itself and points to the same memory
as grabinfo->grab, leaving us with the potential of dangling pointers if
either calls FreeGrab() and doesn't reset the other one.

There is no reader of activeGrab anyway, so simply removing it is
sufficient.

Note: field is merely renamed to keep the ABI. Should be removed in the
future.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: use a tmp variable for the to-be-removed touch listener

No functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: invert a loop condition

Change the single if condition in the loop body to a
    if (!foo) continue;
and re-indent the rest.

No functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: XAllowEvents() on a touch event means accepting it

A sync grab is the owner once it gets events. If it doesn't replay the
event it will get all events from this touch, equivalent to accepting it.

If the touch has ended before XAllowEvents() is called, we also now need to
send the TouchEnd event and clean-up since we won't see anything more from
this touch.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: move EmitTouchEnd to touch.c

No functional changes, this just enables it to be re-used easier.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: Don't emit a TouchEnd event to a frozen device

EmitTouchEnd calls DeliverTouchEvents directly instead of through
public.processInputProc. If a device is frozen, the TouchEnd is
processed while the device is waiting for a XAllowEvents and thus ends the
touch point (and the grab) before the client decided what to do with it. In
the case of ReplayPointer, this loses the event.

This is a hack, but making EmitTouchEnd use processInputProc breaks
approximately everything, especially the touch point is cleaned up during
ProcessTouchEvents. Working around that is a bigger hack than this.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: use public.processInputProc to replay the touch history

If a device is frozen in results to a grab, we need to enqueue the events.

This makes things complicated, and hard to follow since touch events are now
replayed in the history, pushed into EnqueueEvent, then replayed later
during PlayReleasedEvents in response to an XAllowEvents.

While the device is frozen, no touch events are processed, so if there is a
touch client with ownership mask _below_ the grab this will delay the
delivery and potentially screw gesture recognition. However, this is the
behaviour we have already anyway if the top-most client is a sync pgrab or
there is a sync grab active on the device when the TouchBegin was generated.

(also note, such a client would only reliably work in case of ReplayPointer
anyway)

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: when punting to a new owner, always create TouchEnd events

If a touch is pending_finish and we just punted it to the next owner, that
client must receive a TouchEnd event.

If we just punted to the last owner and that owner not a touch grab, we need
to end the touch since this is the last event to be sent, and the client
cannot accept/reject this.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: save state for early acceptance

Delivering an event changes the state to LISTENER_IS_OWNER and we thus lose
the information of early acceptance.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: if a passive async grab is activated from an emulated touch, accept

Async grabs cannot replay events, they cannot reject, so we can do an early
accept here.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: fix lookup in ActivateEarlyAccept

ActivateEarlyAccept() can only be called from a grabbing client, so we can
ignore the rest. And it's easy enough to get the client from that since
9ad0fdb135a1c336771aee1f6eab75a6ad874aff.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: update the core listener state if we delivered the touch event

If a TouchBegin is sent to a core client, that client is now the owner.

By the time the TouchEnd is being processed, the client cannot replay
anymore, so we can assume that this is the final touch end and we can clean
up the touch record.

Note: DeliverTouchEmulatedEvent is called for all listeners and immediately
bails out if the client is not the owner and thus shouldn't yet get the
event. Thus, check the return code.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: if we delivered a TouchEnd to a passive grab, end it

ef64b5ee97099618cf2e2cbbd3e471095695ae24 (which introduced the
TOUCH_CLIENT_ID check) has a wrong assumption that generated touch events
(TOUCH_CLIENT_ID) should not terminate passive grabs.
This is untrue, a TouchEnd may be generated in response to a TouchReject
higher up. If we _deliver_ an event to a client, terminate the passive grab.

This requires us to count the actually delivered events too (first hunk).

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: don't prepend an activated passive grab to the listeners

If the device is currently grabbed as the result of a passive grab
activating, do not prepend that grab to the listeners (unlike active grabs).
Otherwise, a client with a passive pointer grab will prevent touch grabs
from activating higher up in the window stack.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Xi: not having an ownership mask does not mean automatic acceptance

If we only have a single touch-grabbing client, setting the client as owner
would clean up the touch once the TouchEnd was processed. If the client then
calls XIAllowTouches() it will receive a BadValue for the touch ID (since
the internal record is already cleaned up).

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

input: print warnings if drivers don't initialize properly

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>

dix: don't overwrite proximity/focus classes

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>

dix: reset the OsBuffers after killing all clients

==21860== 24 bytes in 1 blocks are still reachable in loss record 85 of 397
==21860==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21860==    by 0x61ED93: AllocateOutputBuffer (io.c:1037)
==21860==    by 0x61E15A: WriteToClient (io.c:764)
==21860==    by 0x457B30: ProcQueryExtension (extension.c:275)
==21860==    by 0x43596B: Dispatch (dispatch.c:432)
==21860==    by 0x425DAB: main (main.c:295)

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>

os: Reset input buffer's 'ignoreBytes' field

If a client sends a request larger than maxBigRequestSize, the server is
supposed to ignore it.

Before commit cf88363d, the server would simply disconnect the client.  After
that commit, it attempts to gracefully ignore the request by remembering how
long the client specified the request to be, and ignoring that many bytes.
However, if a client sends a BigReq header with a large size and disconnects
before actually sending the rest of the specified request, the server will
reuse the ConnectionInput buffer without resetting the ignoreBytes field.  This
makes the server ignore new X clients' requests.

This fixes that behavior by resetting the ignoreBytes field when putting the
ConnectionInput buffer back on the FreeInputs list.

Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

dix: delete all callbacks before reset

DeleteCallbackManager() introduced for better symmetry in the caller, they
do the same thing.

==20085== 24 bytes in 1 blocks are still reachable in loss record 11 of 103
==20085==    at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==20085==    by 0x43A097: CreateCallbackList (dixutils.c:837)
==20085==    by 0x43A1D3: AddCallback (dixutils.c:869)
==20085==    by 0x4B1736: GEExtensionInit (geext.c:209)
==20085==    by 0x41C8A8: InitExtensions (miinitext.c:389)
==20085==    by 0x5AC918: main (main.c:208)

==2042== 8 bytes in 1 blocks are still reachable in loss record 2 of 97
==2042==    at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2042==    by 0x4C2A657: realloc (vg_replace_malloc.c:525)
==2042==    by 0x4802F5: XNFrealloc (utils.c:1095)
==2042==    by 0x43A17A: CreateCallbackList (dixutils.c:855)
==2042==    by 0x43A1EF: AddCallback (dixutils.c:870)
==2042==    by 0x4B1752: GEExtensionInit (geext.c:209)
==2042==    by 0x41C8A8: InitExtensions (miinitext.c:389)
==2042==    by 0x5AC9E4: main (main.c:208)
==2042==

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

Xi: free barrier code at reset time

==29423== 16 bytes in 1 blocks are definitely lost in loss record 73 of 328
==29423==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==29423==    by 0x5987C0: XIBarrierInit (xibarriers.c:908)
==29423==    by 0x58F370: XInputExtensionInit (extinit.c:1300)
==29423==    by 0x4F33C3: InitExtensions (miinitext.c:337)
==29423==    by 0x4997DB: main (main.c:208)

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

os: Use ErrorFSigSafe from FatalError and it's friends

Backtrace logging etc. is already sigsafe, but the actual FatalError message
in response is not yet, leading to amusing logs like this:

    (EE) Segmentation fault at address 0x0
    (EE) BUG: triggered 'if (inSignalContext)'
    (EE) BUG: log.c:499 in LogVMessageVerb()
    (EE) Warning: attempting to log data in a signal unsafe manner while in
    signal context.
    Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or
    ErrorFSigSafe().
    The offending log format message is:

    Fatal server error:

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

os: complain about unsupported pnprintf directives

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

os: support %c in pnprintf

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

os: support %% in pnprintf

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

os: support pnprintf length modifiers for integers

Mainly for %ld, smaller than int is propagated anyway, and %lld isn't really
used.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

dix: reset the registry before quitting

Heaps of these:
==2042== 15,360 bytes in 120 blocks are still reachable in loss record 94 of
97
==2042==    at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2042==    by 0x4C2A657: realloc (vg_replace_malloc.c:525)
==2042==    by 0x45FB91: double_size (registry.c:65)
==2042==    by 0x45FC97: RegisterRequestName (registry.c:85)
==2042==    by 0x460095: RegisterExtensionNames (registry.c:179)
==2042==    by 0x460729: dixResetRegistry (registry.c:334)
==2042==    by 0x5AC992: main (main.c:201)

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

xkb: free XkbRulesUsed and XkbRulesDflt on extension cleanup

==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>

If neither HAL nor udev backends are enabled, warn the user

If both are missing,  input device hotplugging will not work out of the box.
While we still have a DBus-API or the user may want to set AAD off all the
time, the most likely source of this is misconfiguration (i.e. lack of the
udev/hal devel packages).

Message printed last to make it more obvious to the user.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>