over to new system.
Need to update documentation and address some remaining vestiges of
old system such as CursorRec structure, fb "offman" structure, and
FontRec privates.
xf86RandR12ScreenSetSize must protect calls to EnableDisableFBAccess with
suitable vtSema checks to avoid invoking driver code while the X server is
inactive.
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.
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.
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 the PreferredMode option is selected in the config file, remove the
M_T_PREFERRED bit from all other preferred modes to force the config file
mode to be selected.
Code that disabled mode detection on disabled outputs would confuse
applications by listing said outputs as connected but without any modes.
This makes the disabled state in the config file affect only the initial
configuration and not subsequent modifications by RandR.
The DDX code was ignoring pending properties for computing when mode setting
was required. This meant that configurations differing only in property
values would not cause the mode to be set.
I made a mistake in some new code using MakeAtom, passing the size of the
string instead of the length of the string. Figuring there might be other
such mistakes, I reviewed the server code and found four bugs of the same
form.
at server startup, and not against the virtual X/Y parameters
as they can change.
This fixes an issue when canGrow is TRUE and modes get dropped
when using the virtual X/Y parameters.
DRI uses a non-screen block/wakeup handler which will be executed after the
screen block handler finishes. To ensure that the rotation block handler is
executed under the DRI lock, dynamically wrap the screen block handler for
rotation.
Leaving devices enabled during server startup can cause problems during the
initial mode setting in the server, especially when they are used for
different purposes by the X server than by the BIOS. Disabling all of them
before any mode setting is attempted provides a stable base upon which the
remaining mode setting operations can be built.
SourceValidate is used exclusively by the software cursor code to pull the
cursor off of the screen before using the screen as a source operand. This
eliminates the software cursor from the frame buffer while painting the
rotated image though. Disabling this function by temporarily setting the
screen function pointer to NULL causes the cursor image to be captured.
(cherry picked from commit 05e1c45ade)
Setting a mode on an unrotated CRTC was causing all of the rotation updates
to be disabled; the loop looking for active rotation wasn't actually looking
at each crtc, it was looking at the modified crtc many times.
(cherry picked from commit 8b217dee3a)
I've managed to solve my own bug (#10545) by applying the following
patch to the xserver.
Please apply.
<Conspiracy mode on>
This monitor is "Vista Certified". I wonder if this is a pure coincidence...
<Conspiracy mode off>
With kind regards
Erik Andrén
(cherry picked from commit a63704f14a)
Option "Enable" "True" will force the server to enable an output at startup
time, even if the output is not connected. This also causes the default
modes to be added for this output, allowing even sync ranges to be used to
pick out standard modes.
(cherry picked from commit a3d73ba2cb)
By default, use the screen monitor section for output 0, however, a driver
can change which output gets the screen monitor by calling
xf86OutputUseScreenMonitor.
(cherry picked from commit f4a8e54caf)
This Acer monitor reports support for 75hz refresh via EDID, and yet when
that rate is delivered, the monitor does not sync and reports out of range.
Use the existing 60hz quirk for this monitor.
(cherry picked from commit 1328a288e9)
xf86SetSingleMode tries to resize all crtcs to match the selected mode. When
a CRTC has no matching mode, it now disables the CRTC (instead of crashing).
Also, poke the RandR extension when xf86SetSingleMode is done so that
appropriate events can be delivered, and so that future RandR queries return
correct information.
(cherry picked from commit dc6c4f6989)
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.
desiredX and desiredY were not recorded during xf86InitialConfiguration.
desiredX, desiredY and desiredRotation were not recorded during
xf86SetSingleMode.
(cherry picked from commit 36e5227215)
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)
The rotation state is stored in the xf86_config structure which is not
re-initialized at server reset time. Clean it up at CloseScreen time.
(cherry picked from commit f8db7665dc)
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.
Rotation block handler was re-registering the rotation damage structure,
creating an infinite loop in the damage code. Track registration of the
damage structure to avoid this.
(cherry picked from commit b14f003b0e)
