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.
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.
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).
Set the new randr crtc of the output before the output change notification is
delivered to the clients.
Remove RROutputSetCrtc as it is not really necessary. All we have to do is set
the output's crtc on RRCrtcNotify
When checking how to validate the selected mode and position against the
current screen size, the test against 90/270 rotation did not mask out
reflection, so that when reflection was specified, the 90/270 test would
never succeed. This caused incorrect bounds checking and would return
an error to the user instead of rotating the screen.
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.
Yes, two changes in one commit. Sorry 'bout that.
The first change ensures that when pending property values have been
changed, a mode set to the current mode will actually do something, rather
than being identified as a no-op. In addition, the driver no longer needs to
manage the migration of pending to current values, that is handled both
within the xf86 mode setting code (to deal with non-RandR changes) as well
as within the RandR extension itself.
The second change eliminates the two-call Create/AttachScreen stuff that was
done in a failed attempt to create RandR resources before the screen
structures were allocated. Merging these back into the Create function is
cleaner.
(cherry picked from commit 57e87e0d00)
Conflicts:
randr/randrstr.h
randr/rrcrtc.c
I think master and server-1.3-branch are more in sync now.
Pending Properties take effect when the driver says they do, so provide an
API to tell DIX when a property effect is made. Also, allow driver
to reject property values in RRChangeOutputProperty.
(cherry picked from commit 8eb288fbd6)
RRModes are referenced by the resource db, RROutput and RRCrtc structures.
Ensure that the mode reference count is decremented each time a reference is
lost from one of these sources. The missing destroys were in
RRCrtcDestroyResource and RROutputDestroyResource, which only happen at
server reset time, so modes would be unavailable in subsequent server
generations.
The xf86 mode setting code was mis-using this field to try and store a
pointer to a DisplayModeRec, however, each output has its own copy of every
DisplayModeRec leaving the one in in the RRModeRec devPrivate field pointing
at a random DisplayModeRec.
Instead of attempting to rectify this, eliminating the devPrivate entirely
turned out to be very easy; the DDX code now accepts an arbitrary RRModeRec
structure and set that to the hardware, converting it on the fly to a
DisplayModeRec as needed.
(cherry picked from commit 3506b9376c)
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.
It was using REQUEST_SIZE_MATCH (client request length must equal request size)
rather than REQUEST_AT_LEAST_SIZE (client request length must be at least
big enough for request size), and this request has data following the request
structure.
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)
The config time in the RandR protocol reflects when the hardware state has
changed. It was getting changed anytime the driver changed the usage
of the hardware as well.
(cherry picked from 98d18a6578 commit)
When an output no longer reports the current mode, it must still be included
in the list advertised by the X server. Walk the crtcs to ensure it is
included.
(cherry picked from 78689d0d66 commit)
RRCrtcDestroyResource and RROutputDestroyResource had matching
bugs that would overwrite memory past the end of the storage
of the crtc or output arrays. Oops.
(cherry picked from 4202b23ed8 commit)
Now that resources can be created during server initialization, make sure
the crtc, output and mode resource types are created before attempting to
create associated resources.
(cherry picked from commit ec83d67416)
