Clients expect any Xinerama-enabled screen to report at least one
monitor, but with RandR, there may not be any enabled crtcs. In this case,
tell the client that Xinerama is not active.
(cherry picked from commit 1afdf8b0a9)
The timestamp transferred in the X protocol is a 32-bit number of
milliseconds.
The timestamp stored in the server is a structure that contains two fields:
months (!) and milliseconds.
When the server passes the config timestamp to the client, it discards the
months part and sends only the milliseconds part.
When the server receives the config timestamp from the client, it tries to
guess the "months" part by looking at the current time and then maybe adding
or
subtracting one. The guess is wrong after the server has been running long
enough (several hours).
I have added two ErrorF calls around the 'if' statement that returns
RRSetConfigInvalidConfigTimestamp in randr/randr.c and my Xorg.0.log has
this:
randr request got good config time: 0:-2103495671
for the first few successful xrandr calls, and
randr request failed with RRSetConfigInvalidConfigTime: client passed
1:-2103495671, server has 0:-2103495671
when it fails. The server has been running for 8 and a half hours.
The obvious fix would be to ignore the months field and only compare the
milliseconds.
(cherry picked from commit 0dc2bb6101)
MAXBUFSIZE appears to be a leftover of some previous time. Instead, just
use maxBigRequestSize when bigreqs are available (limiting buffers to ~16MB).
When bigreqs are not available, needed won't be larger than the maximum
size of a non-bigreqs request (256kB).
(cherry picked from commit ca82d4bddf)
an int overflow, making dx*dx+dy*dy negative. Now pow(negative,
non-integer) yields NaN, so you loose. Use fp math to avoid that.
(cherry picked from commit 12d27cf33c)
The author of the int10 code looked at the VBIOS POSTing code
in DOSEMU to get some initial idea on how to POST a VBIOS.
To give credit to the DOSEMU Team for this inspiration a comment
was added to the code which could suggest that code from the
GPLed DOSEMU was directly incorporated into this code.
This patch should clearify the situation.
(cherry picked from commit 1d11e4bc4c)
Licensing issues of these files include:
- They claim to be licensed under the GPL, yet we haven't allowed that in the
xserver repository in the past.
- They refer the user to the top of the tree for GPL license text, yet it isn't
there.
- They claim to be derived from the (MIT-licensed) ati kdrive code, yet don't
follow the licensing terms of those files.
(cherry picked from commit 87295b66a9)
The multi-crtc cursor code in hw/xfree86/modes holds a reference to the
current cursor. This reference must be correctly ref counted so the cursor
is not freed out from underneath this code.
(cherry picked from commit 7dc8531548)
The fb pointer would be left uninitialized when exaPixmapIsOffscreen
returned false. When it returned true and the pixmap was damaged,
fb would be initialized from the pixmap's devPrivate.ptr before the
exaDoMigration and exaPrepareAccess calls, at which point
devPrivate.ptr would still be pointing at offscreen memory.
(cherry picked from commit 3c448b0eb6)
A bunch of CFLAGS had gone missing, so the build failed with errors like:
../../../../../hw/xfree86/os-support/linux/lnx_ev56.c:7:19: error: input.h: No such file or directory
../../../../../hw/xfree86/os-support/linux/lnx_ev56.c:8:24: error: scrnintstr.h: No such file or directory
(cherry picked from commit a1fe36b772)
miTrapezoids creates an alpha pixmap and initializes the contents
using PolyFillRect, which causes the pixmap to be moved in for
acceleration. The subsequent call to RasterizeTrapezoid won't be
accelerated by EXA, which causing the pixmap to be moved back out
again.
By wrapping Trapezoids and using ExaCheckPolyFillRect instead of
PolyFillRect to initialize the pixmap, we avoid this roundtrip.
(cherry picked from commit daee59b170)
LessThan/GreaterThan comparisons were used in the wakeup handler,
and LessOrEqual/GreaterOrEqual in the block handler.
Change it to use LessOrEqual/GreaterOrEqual in both functions,
since this is what XSyncNegativeComparison and
XSyncPositiveComparison imply.
This reverts commit 2243b30e54. The existing
DRI interface doesn't let us get from a __DRIdrawable to the corresponding
X drawable, and thus, we can't implement AIGLX damage tracking with the
current interface.
As a result, we can remove the quirks that existed to flip the bits back around
for us. This is not confirmed in all cases due to lack of bugs containing EDID
blocks associated with the quirks, but is likely true.
RRFirstOutput returns the first active output, which won't be set until
after RRScanOldConfig is finished running. Instead, just use the first
output (which is the only output present with an old driver, after all).
I exported the evdev driver to Xephyr server. I'm running it using something
like:
$ ./hw/kdrive/ephyr/Xephyr :1 -mouse evdev,,device=/dev/input/event4 -keybd \
evdev,,device=/dev/input/event1,xkbmodel=abnt2,xkblayout=br
It also closes /#5668.
Don't use our DBusError for property getting, because we simply don't care:
this fixes D-Bus error spew to stderr. Thanks Michel Dänzer for debugging
and testing.
and the Xephyr virtual mouse keeps alive. With this patch the semantic changes
turning '-pointer' && 'Xephyr virtual mouse' always false.
Now we can open a device pointer and pass its options in Xephyr's command line
without having other pointer unused.
Don't call fbFinishWrap until the pixman_image_t that stores the pointer is
actually freed. This prevents corruption or crashes caused by accessing a
wrapped pointer after the wrapping is torn down.