mieq: Fix a crash regression in mieqProcessDeviceEvent

(lldb) bt
* thread #6: tid = 0x92d4eb, 0x00000001001dee94 X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000, event=0x0000000100298bb0,
screen=0x0000000000000000) + 36 at mieq.c:519, stop reason = EXC_BAD_ACCESS (code=1, address=0x44)
  * frame #0: 0x00000001001dee94 X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000, event=0x0000000100298bb0, screen=0x0000000000000000) + 36 at
mieq.c:519
    frame #1: 0x00000001001df3eb X11.bin`mieqProcessInputEvents + 555 at mieq.c:631
    frame #2: 0x0000000100017674 X11.bin`ProcessInputEvents + 20 at darwinEvents.c:422
    frame #3: 0x0000000100175eaa X11.bin`Dispatch + 154 at dispatch.c:357
    frame #4: 0x0000000100181b4a X11.bin`dix_main(argc=4, argv=0x00007fff5fbff750, envp=0x00007fff5fbff650) + 1594 at main.c:296
    frame #5: 0x000000010001ba80 X11.bin`server_thread(arg=0x0000000101208220) + 64 at quartzStartup.c:66
    frame #6: 0x00007fff89bb9899 libsystem_pthread.dylib`_pthread_body + 138
    frame #7: 0x00007fff89bb972a libsystem_pthread.dylib`_pthread_start + 137
    frame #8: 0x00007fff89bbdfc9 libsystem_pthread.dylib`thread_start + 13

Regression from: 9fb08310b51b46736f3ca8dbc04efdf502420403

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
xfree86: Remove stale /usr/share/X11/xorg.conf.d hard-code from the xorg.conf man page

I forgot that the old behavior of searching in /usr/share/X11/xorg.conf.d was
documented in the man page.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Fixes: acc0b5edd1dc ("xfree86: Only support one sysconfigdir")
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove an ancient IBM configuration

Whatever unix this was meant to be is either no longer in circulation,
or is AIX, which we don't claim to support anyway.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove some XFree86 3.x leftovers

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: (Don't) change BITMAP_SCANLINE_UNIT on Linux s390{, x}

Every other architecture sets this to 32, and I can't think of any
benefit s390 would derive from changing it.  It is, at any rate,
something the client already copes with, and the only internal code
impact seems to be some complicated math in miGetPlane, which you never
hit if you're using fb.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove some dead macros

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove some cfb leftovers

These macros meant something in cfb, but not in fb.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Default GLYPHPADBYTES to 4

This effectively no longer varied across architectures anyway.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove wacky sparc special casing (v2)

This appears to be defining sparc if ever __sparc or __sparc__ were
defined, which is almost reasonable, but these days we want to be using
the __arch__ style.  Why any of this would ever be triggered on m68k is
truly a mystery for the ages.

v2: Fix commit message, as noted by nix

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove a weird case of little-endian s390

I really don't think this was ever correct, but I'm also not sure what
non-Linux Unix this was meant to enable.  The only one I know of was
OS/390 / z/OS / OpenEdition, but I think that was big-endian too.

At any rate this is all about to go away, so this is just removing an
edge case.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dix: Remove arch awareness from servermd.h (v2)

At this point we have no architectures where image byte order is
different from bitmap bit order, or where either of those two are not
also the native word endianness.  Hooray, one more place where we don't
have to worry about enabling new CPU architectures.

v2: Rebase to master to handle the addition of ppc64le, arc, and xtensa,
and use autoconf's endianness detection instead of gcc predefines.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
xfree86: Remove i2c multimedia modules

These came in with the GATOS merge I think.  The only driver using them
was radeon, and then only in UMS mode.  The radeon driver dropped UMS
support from the main branch about two years ago, the UMS branch hasn't
been touched in about fifteen months, and does not build against 1.16 in
any case, so this is all dead code.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Merge remote-tracking branch 'jeremyhu/master'
xwayland: Only disable/enable devices on capabilities change

Anytime a capability is first reported, the device is created, but after
that, it is only disabled/enabled.

This is a closer behavior to what Xorg does on VT switch, at the expense
of maybe leaving a dangling "physical" device if a capability goes for good.
Otherwise, any DeviceIntPtr (re)created after server initialization will be
left floating, and bad things happen when the wayland enter event handler
tries to update cursor position based on a floating device.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>