avoid mix of 'variant' and 'variants'

we'll need the remote xkb in KeyboardProc in future so let's move it up.

Attributes GH PR #751: https://github.com/ArcticaProject/nx-libs/pull/751

(partially) fixes ArcticaProject/nx-libs#666

(partially) fixes ArcticaProject/nx-libs#666

(partially) fixes ArcticaProject/nx-libs#666

(partially) fixes ArcticaProject/nx-libs#666

(partially) fixes ArcticaProject/nx-libs#666

(partially) fixes ArcticaProject/nx-libs#666

(partially) fixes ArcticaProject/nx-libs#666

Attributes GH PR #753: https://github.com/ArcticaProject/nx-libs/pull/753

Backport of this commit:

  commit a2880699e8f1f576e1a48ebf25e8982463323f84
  Author: Keith Packard <keithp@keithp.com>
  Date:   Tue Mar 25 08:21:16 2014 -0700

    fb: fix fast-path blt detection

    The width parameter is used to disable the blit fast-path (memcpy) when
        source and destination rows overlap in memory. This check was added in [0].

    Unfortunately, the calculation to determine if source and destination
    lines overlapped was incorrect:
      (1) it converts width from pixels to bytes, but width is actually in
          bits, not pixels.
      (2) it adds this byte offset to dst/srcLine, which implicitly converts
          the offset from bytes to sizeof(FbBits).

    Fix both of these by converting addresses to byte pointers and width
    to bytes and doing comparisons on the resulting byte address.

    For example:
    A 32-bpp 1366 pixel-wide row will have
      width = 1366 * 32 = 43712 bits
      bpp = 32
      (bpp >> 3) = 4
      width * (bpp >> 3) = 174848 FbBits
      (FbBits *)width => 699392 bytes

    So, "careful" was true if the destination line was within 699392 bytes,
    instead of just within its 1366 * 4 = 5464 byte row.

    This bug causes us to take the slow path for large non-overlapping rows
    that are "close" in memory.  As a data point, XGetImage(1366x768) on my
    ARM chromebook was taking ~140 ms, but with this fixed, it now takes
    about 60 ms.
      XGetImage() -> exaGetImage() -> fbGetImage -> fbBlt()

    [0] commit e32cc0b4c85c78cd8743a6e1680dcc79054b57ce
    Author: Adam Jackson <ajax@redhat.com>
    Date:   Thu Apr 21 16:37:11 2011 -0400

        fb: Fix memcpy abuse

        The memcpy fast path implicitly assumes that the copy walks
        left-to-right.  That's not something memcpy guarantees, and newer glibc
        on some processors will indeed break that assumption.  Since we walk a
        line at a time, check the source and destination against the width of
        the blit to determine whether we can be sloppy enough to allow memcpy.
        (Having done this, we can remove the check for !reverse as well.)

    v3: Convert to byte units

    This first checks to make sure the blt is byte aligned, converts all
    of the data to byte units and then compares for byte address range
    overlap between source and dest.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

Fixes ArcticaProject/nx-libs#750

Backport of this commit:

commit e32cc0b4c85c78cd8743a6e1680dcc79054b57ce
Author: Adam Jackson <ajax@redhat.com>
Date:   Thu Apr 21 16:37:11 2011 -0400

    fb: Fix memcpy abuse

    The memcpy fast path implicitly assumes that the copy walks
    left-to-right.  That's not something memcpy guarantees, and newer glibc
    on some processors will indeed break that assumption.  Since we walk a
    line at a time, check the source and destination against the width of
    the blit to determine whether we can be sloppy enough to allow memcpy.
    (Having done this, we can remove the check for !reverse as well.)

    On an Intel Core i7-2630QM with an NVIDIA GeForce GTX 460M running in
    NoAccel, the broken code and various fixes for -copywinwin{10,100,500}
    gives (edited to fit in 80 columns):

    1: Disable the fastpath entirely
    2: Replace memcpy with memmove
    3: This fix
    4: The code before this fix

      1            2                 3                 4           Operation
      ------   ---------------   ---------------   ---------------   ------------
      258000   269000 (  1.04)   544000 (  2.11)   552000 (  2.14)   Copy 10x10
       21300    23000 (  1.08)    43700 (  2.05)    47100 (  2.21)   Copy 100x100
         960      962 (  1.00)     1990 (  2.09)     1990 (  2.07)   Copy 500x500

    So it's a modest performance hit, but correctness demands it, and it's
    probably worth keeping the 2x speedup from having the fast path in the
    first place.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>

Attributes GH PR #752: https://github.com/ArcticaProject/nx-libs/pull/752

Fixes this valgrind finding

==16977== Warning: invalid file descriptor -1 in syscall close()
==16977== Conditional jump or move depends on uninitialised value(s)
==16977==    at 0x544B6B: XkbSendNewKeyboardNotify (xkbEvents.c:62)
==16977==    by 0x540481: ProcXkbGetKbdByName (xkb.c:5330)
==16977==    by 0x4341C5: Dispatch (NXdispatch.c:482)
==16977==    by 0x40EB02: main (main.c:353)
==16977==  Uninitialised value was created by a heap allocation
==16977==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16977==    by 0x431BD7: NextAvailableClient (dispatch.c:3719)
==16977==    by 0x47B297: AllocNewConnection (connection.c:821)
==16977==    by 0x47B297: EstablishNewConnections (connection.c:910)
==16977==    by 0x463DFE: ProcessWorkQueue (dixutils.c:541)
==16977==    by 0x47635E: WaitForSomething (WaitFor.c:213)
==16977==    by 0x434089: Dispatch (NXdispatch.c:360)
==16977==    by 0x40EB02: main (main.c:353)

Backport of

  commit dc9ce695a69ca0787f58f8d160212a7a41acb703
  Author: Rami Ylimäki <rami.ylimaki@vincit.fi>
  Date:   Wed Mar 9 15:45:40 2011 +0200

    xkb: Initialize pad bytes sent in replies of geometry requests.

    Valgrind complains about uninitialized data being written to clients.
Reviewed-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Backport of

  commit 81b3b0cce088866dc3cda099d7c8d6655849fd43
  Author: Tomas Janousek <tomi@nomi.cz>
  Date:   Wed May 20 15:03:01 2009 +0200

    Bug #6428, #16458, #21464: Fix crash due to uninitialized VModMap fields.

    In ProcXkbGetKbdByName, mrep.firstVModMapKey, .nVModMapKeys and
    .totalVModMapKeys were not initialized, contained random values and caused
    accesses to unallocated and later modified memory, causing
    XkbSizeVirtualModMap and XkbWriteVirtualModMap to see different number of
    nonzero values, resulting in writes past the end of an array in XkbSendMap.

    This patch initializes those values sensibly and reverts commits 5c0a2088 and
    6dd4fc46, which have been plain non-sense.
Signed-off-by: Tomas Janousek <tomi@nomi.cz>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

ensure that we have all the required def files

Regression fix for a93f64e4. The test executables bails out on test failure, whereas ifdef does not. Adding "|| true" where needed.

Attributes GH PR #736: https://github.com/ArcticaProject/nx-libs/pull/736

Suppress printing the rm and the cc call for every file.
Only print the compiler call in case of error.

create a new def file nxconfig.def and be fine. The settings in that
file will be respected by all subsequent imake calls anywhere in the tree.

nx-libs.spec: newer versions of SLE* and OpenSuSE use xkbcomp-devel, while RedHat-based distros want xorg-x11-xkb-utils-devel for xkbcomp.pc.

(Very) old SLE versions don't have that file at all and we can do
without - we'll just use the previous, default values.

This also means that we don't need to preinstall a package containing
xkbcomp.pc on Debian and derivates for the cleaning target.