- Note that -br is now default.
- Move -bs after -br for alphabetical ordering.
- Remove -config option that's been hidden in "ignore" section,
since ajax removed the -config code a couple years back.
- Add -nocursor option.
- Add xinput & xrandr to list of runtime server control programs
- Replace XDarwin with Xquartz in list of Xservers
Signed-off-by: Alan Coopersmith <email address hidden>
Reviewed-by: Adam Jackson <email address hidden>
Signed-off-by: Keith Packard <email address hidden>
(cherry picked from commit 7b09335a46f9428141811230c69eef7968531359)
7787526...
by
Simon Farnsworth <email address hidden>
Don't crash when asked if a client that has disconnected was local
ProcDRI2Dispatch uses LocalClient to determine if it's safe to respond
to a client that has made DRI2 requests which aren't sensible for
remote clients (anything but version). When the client has disappeared
mid-request stream (e.g. as a result of a kill -9, or a client-side
bug), LocalClient causes the X server to follow suit, as
((OsCommPtr)client->osPrivate)->trans_conn is NULL at this point.
The simple and obvious fix is to just return "not local" when
trans_conn is NULL, which fixes the crash I was seeing; however Keith
Packard pointed out that just checking trans_conn isn't enough;
quoting Keith:
"This looks almost right to me -- I reviewed the os code to see when
_XSERVTransClose is called (which is what frees the trans_conn data) and
found that every place which called that immediately set trans_conn to
NULL, except for the call in CloseDownFileDescriptor which is only
called from CloseDownConnection and which is immediately followed by
freeing the OsCommRec and setting client->osPrivate to NULL. So, I'd
suggest checking client->osPrivate in addition to the above check."
Signed-off-by: Simon Farnsworth <email address hidden>
Reviewed-by: Keith Packard <email address hidden>
Signed-off-by: Keith Packard <email address hidden>
(cherry picked from commit 660f6ab5494a728c3ca7ba00c305e9ff06c8ecb2)
Fix compiler issues with getifaddrs() call on OpenSolaris
OpenSolaris recently added support for the getifaddrs() API.
Building with that uncovered two compiler issues (one warning, one error)
in the code that was now being built for the first time in our builds:
"access.c", line 768: warning: argument #1 is incompatible with prototype:
prototype: pointer to struct sockaddr {unsigned short sa_family, array[14] of char sa_data} : "access.c", line 213
argument : pointer to struct sockaddr_storage {unsigned short ss_family, array[6] of char _ss_pad1, double _ss_align, array[240] of char _ss_pad2}
"access.c", line 838: assignment type mismatch:
struct sockaddr {unsigned short sa_family, array[14] of char sa_data} "=" struct sockaddr_storage {unsigned short ss_family, array[6] of char _ss_pad1, double _ss_align, array[240] of char _ss_pad2}
Signed-off-by: Alan Coopersmith <email address hidden>
Reviewed-by: Jamey Sharp <email address hidden>
(cherry picked from commit e42a29d269fadc11e065c63ee369e3165196f2d7)
xfree86: parser: Never use constant strings for driver names (fixes #17438)
When the parser sees the "keyboard" driver, it automatically (and
silently) replaces it with the constant string "kbd".
Everybody else uses malloc'd memory for the driver name, so input
device closure assumes it can use free.
Free val.str, so this crash doesn't turn into a memory leak. Whew.
Signed-off-by: Jesse Adkins <email address hidden>
Reviewed-by: Peter Hutterer <email address hidden>
Signed-off-by: Peter Hutterer <email address hidden>
(cherry picked from commit bce12f2956f23c0ee53f7f6485dba631293a0931)
fb: make isClipped always reject negative coordinates (bug 11503)
A window with either dimension > 32767 can be positioned such that
coordinates > 32767 are visible on the screen. Attempts to draw to
those pixels will generate coordinates wrapped around to negative
values.
The optimized clipping macro, 'isClipped', in fbbits.h, computes
clipping in window space rather than screen space using int16 values,
and so it too has coordinates wrapped around to negative values and
hence ends up accepting the wrapped drawing coordinates.
Two possible fixes for this problem
1) Detect wrapped region coordinates and clip those to 32767.
2) Detect negative incoming coordinates and reject those
This patch takes the second approach as it is much shorter, simply
detecting when either X or Y incoming coordinate is negative, which
can never be 'within' any drawable.
Signed-off-by: Keith Packard <email address hidden>
Reviewed-by: Adam Jackson <email address hidden>
(cherry picked from commit 3e56efcfb63677cd8574e1e435e61d96f79ea536)
A simple hack to accommodate various EDID who have detailed modes that
exceed the EDID's max pixel clock. The pixel clock is only defined in
units of 10MHz and often appears as the maximum pixel code of the
detailed modes, rounded to the nearest 10MHz. Adjusting the max_clock to
include an extra 5MHz prevents the parser from rejecting the detailed
modes.
The kernel uses the same fuzz and by including it in X we can use the
same modes in X as for the console.
In the future, we will want to try harder to keep the KMS modes but at
the same time we need to apply the restrictions as specified by the
user's configuration, and need to fill in modes for fullscreen games on
fixed-mode panels.
Reported-and-tested-by: Fabio Pedretti <email address hidden>
Signed-off-by: Chris Wilson <email address hidden>
Reviewed-by: Alex Deucher <email address hidden>
Signed-off-by: Keith Packard <email address hidden>
(cherry picked from commit 951605b4660290044fb238bcf1d6d9e498567e8c)
The callback data passed by reference to the hook was allocated on stack
within the scope of the case statement. The compiler is free to reuse
any of that stack space whilst making the function call so we may end up
passing garbage into the callback.
v2: Drop the unrelated hunk that snuck in when ammending the commit
message.
Signed-off-by: Chris Wilson <email address hidden>
Reviewed-by: Alan Coopersmith <email address hidden>
Signed-off-by: Keith Packard <email address hidden>
(cherry picked from commit 6dae7f3792611aace1df0cca63bf50c50d93de43)
Classic strlen/strcpy mistake of
foo = malloc(strlen(bar));
strcpy(foo, bar);
Testcase: valgrind Xephyr :1
==8591== Invalid write of size 1
==8591== at 0x4A0638F: strcpy (mc_replace_strmem.c:311)
==8591== by 0x605593: _XkbCopyGeom (xkbUtils.c:1994)
==8591== by 0x605973: XkbCopyKeymap (xkbUtils.c:2118)
==8591== by 0x6122B3: InitKeyboardDeviceStruct (xkbInit.c:560)
==8591== by 0x4472E2: CoreKeyboardProc (devices.c:577)
==8591== by 0x447162: ActivateDevice (devices.c:530)
==8591== by 0x4475D6: InitCoreDevices (devices.c:672)
==8591== by 0x4449EE: main (main.c:254)
==8591== Address 0x6f96505 is 0 bytes after a block of size 53 alloc'd
==8591== at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==8591== by 0x6054B7: _XkbCopyGeom (xkbUtils.c:1980)
==8591== by 0x605973: XkbCopyKeymap (xkbUtils.c:2118)
==8591== by 0x6122B3: InitKeyboardDeviceStruct (xkbInit.c:560)
==8591== by 0x4472E2: CoreKeyboardProc (devices.c:577)
==8591== by 0x447162: ActivateDevice (devices.c:530)
==8591== by 0x4475D6: InitCoreDevices (devices.c:672)
==8591== by 0x4449EE: main (main.c:254)
Reported-by: Dave Airlie <email address hidden>
Signed-off-by: Peter Hutterer <email address hidden>
Reviewed-by-and-apologised-for: Daniel Stone <email address hidden>
Signed-off-by: Keith Packard <email address hidden>
(cherry picked from commit 7f19a7a6e90a4fd7b7ec0256974f62e575218541)
Conflicts:
xkb/xkbUtils.c
(cherry picked from commit f85552aa452d5f575fee9f6031a33ca79bdc3cc8)
