By adding a new output callback, ->get_crtc, xf86SetDesiredModes is able to
avoid turning off outputs & CRTCs if the current output<->CRTC mappings are the
same as the desired configuration. This helps avoid flickering displays at
startup time, which speeds things up a little and looks better.
In order to report accurate values to users of the RandR property interface,
it's sometimes necessary to ask the driver to update the value (for example
when backlight brightness changes without the server's knowledge, due to hotkey
events or direct sysfs banging).
This patch wires up the core server code with a new xf86CrtcFuncs callback,
get_property, to allow for this.
The new code is available under the RANDR_13_INTERFACE define, which in turn
depends on the RANDR_12_INTERFACE code.
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.
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
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)
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.
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 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)
This patch tracks the protocol changes which introduce more complex
semantics for RandR output properties including pending and valid value
information.
(cherry picked from commit af55c65bea)
To allow RandR objects to be created before the screen object exists,
the resource types must be registered with the resource database.
A driver wishing to create RandR objects must call RRInit before doing so.
Also, fix a segfault when setting Output data before it is associated with a
screen.
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.
Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings.
Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all
source files in the xserver/xorg tree, predicated on defines of
HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to
<X11/fonts/foo.h>.
change "foo.h" to <X11/foo.h> for core headers, e.g. X.h, Xpoll.h;
change "foo.h", "extensions/foo.h" and "X11/foo.h" to
<X11/extensions/foo.h> for extension headers, e.g. Xv.h;
change "foo.[ch]" to <X11/Xtrans/foo.[ch]> for Xtrans files.
