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.
RandR 1.1 clients expect the size fields in this event to be the unrotated
dimensions of the screen. This behavior is "weird", but that's the way the old
code worked so we need to be bug-compatible with it.
The RandR protocol spec has several requests in support of user-defined
modes, but the implementation was stubbed out inside the X server. Fill out
the DIX portion and start on the xf86 DDX portion. It might be necessary to
add more code to the DDX to insert the user-defined modes into the output
mode list.
(cherry picked from commit 63cc2a51ef)
Conflicts:
randr/randrstr.h
Updated code to work in master with recent security API changes.
RandR 1.0 sizeID must be computed the same way every time, so when reporting
it in the ScreenChangeNotify event, just construct the usual 1.0 data block
and use that.
subpixel geometry information can be computed by looking at the connected
outputs and finding any with subpixel geometry and using one of those for
the global screen subpixel geometry. This might be improved by reporting
None if more than one screen has information and they conflict.
Events and internal data structures need to be updated whenever the physical
or pixel size of the screen changes. The code was ignoring the physical
size, so changing only that would not be registered anywhere.
(cherry picked from f42e3cea23 commit)
The RRScreenSizeSetRange function is used externally for 1.2 API drivers,
but can also be used in the 1.0 compatibility code. This also ensures that
the right changed bits are set so that clients are correctly notified when
the range changes.
RRGetInfo can return an error, use that to return BadAlloc to clients
instead of blindly going on with various requests.
(cherry picked from f05dd384d3 commit)
Mode lines reflect the monitor mode, not the projected size into the frame
buffer. Flip width/height around so that the dimensions are oriented
correctly.
(cherry picked from 612a8e6180 commit)
RandR 1.0 refresh rates were scrambled when working with a 1.2 driver that
returned sizes in a mixed order. SetScreenConfig was treating RRCrtcSet as
returning an RandR status instead of a Bool.
(cherry picked from 6dc711833d commit)
xf86 drivers need to create RandR object in the PreInit stage,
before the ScreenRec is allocated. Changing the RandR DIX code
to permit this required the addition of functions that later associate the
objects with the related screen.
An additional change is that modes are now global, and no longer associated
with a specific screen. This change actually makes mode management cleaner
as there is no more per-screen list of modes to deal with.
This changes the RandR 1.2 ABI/API for drivers.
Add function to keep pointer within valid crtc areas.
Finish event delivery and swapping code.
Separate configuration from layout changes to send correct events.
Output options and mode origins both affected driver ABI. memmove mistakes
were causing 'Freeing resource which isn't there' messages.
Prune unused non-user defined modes from available list now.
Provide a Xinerama implementation when DIX version isn't enabled. This
version exposes each crtc as a separate 'screen' and reports the size of
that patch. The extension also sends ConfigureNotify events to the root
window whenever crtcs change so that applications will re-fetch xinerama
information. This actually works for metacity.
RandR is getting too big to live in one file; split into one file per object
type (crtc, mode, screen), leaving the rest of the code in randr.c.
Code is slowly approaching the point where it will drop-in as a replacement
for the old 1.0 implementation.
