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)
The fbdev API doesn't allow setting the pitch explicitly, so we have to set
the virtual width to the pitch we're using for drawing. This fixes corruption
after changing the virtual width with RandR.
The fbdev API allows the driver to 'accept' modes it doesn't really support by
modifying it to the nearest supported mode. Without this check, e.g. vesafb
would appear to accept all modes, even though it actually can't set any modes
other than the bootup mode at all.
This has been what has been used the most successfully post-damagetrack.
The current thinking is that:
1) We should be able to accelerate basically everything. So we don't need to
try to migrate trees of pixmaps permanently out of framebuffer to speed
CPU drawing up.
2) Migration is cheaper in the thrashing case, so we don't want to go to a lot
of effort to try (and fail badly) to find a working set.
Mostly due to exaDrawableDirty() now calculating the backing pixmap coordinates
internally, for cases where they aren't trivially known. There's a new
exaPixmapDirty() function for the other cases.
- Added -extension & +extension to Xserver man page
- Changed Xorg synopsis from X11R6 to X11R7
- Clarified Xorg ancestry description
- Moved Solaris to free/Open Source OS list
- Removed references to MetroLink module loader & getconfig
- Converted (1) to (__appmansuffix__) in a few more places
- Replaced http://www.freedesktop.org/cvs/ with http://gitweb.freedesktop.org/
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)