This removes all rendering and mapping code from xf86DiDGA, leaving
just mode setting and raw input device access. The mapping code didn't
have the offset within /dev/mem for the frame buffer and the pixmap
support assumed that the framebuffer was never reallocated.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The adjusted mode was freed, but any name allocated for that was leaked.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The smart scheduler is designed to minimize scheduler overhead by
increasing the interval between WaitForSomething calls when a single
client is running. However, the software rotation code depends on
its BlockHandler being invoked for screen updates; the long delays
caused by the smart scheduler optimizations means that screen updates
can be delayed a long time as well.
The change is simple -- prevent the smart scheduler from increasing
the scheduling interval while any screen is using software rotation.
Signed-off-by: Keith Packard <keithp@keithp.com>
The rotation block handler uses regular driver rendering functions to
repaint the screen, if those functions queue commands in the driver,
it's important that the driver block handler be invoked after the
rotated image is drawn.
Signed-off-by: Keith Packard <keithp@keithp.com>
xf86_reload_cursors restores the cursor to the correct position, but
that must adjust for cursor hot spot and frame before calling down to
the hardware function, otherwise the cursor jumps to the wrong
position until it is repositioned by the user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes screensaver fadeout effects.
Also make all RandR 1.2 compatibility code for XF86VidMode operate only on the
CRTC associated with the compatibility output, not all CRTCs at once.
xextproto had Xlib client headers moved into libXext.
Protocol header files are named fooproto.h, header files with constants
foo.h or fooconst.h where foo.h was already in use for client-side headers.
crtc->funcs->lock is NULL, so it's no use calling it here. Move it down so
it's actually defined before we use it.
Introduced with 6f59a81600.
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
This moves code out of each implementation of set_mode_major and back into
the X server. The real feature here is that the transform is now available
in the crtc for use by either xf86CrtcRotate or whatever the driver wants to
do. Without this change, the transform was lost for drivers providing the
set_mode_major interface.
Note that users of this API will want to stop smashing the transformPresent
field, and could also stop setting mode/x/y/rotation for new enough X servers,
but there's no reason to make that change as it will break things when
running against older X servers.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
If you have multiple cards, some that support randr 1.2 and some that don't
you can get a null dereference in here.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Make xf86 RANDR wrap the EnterVT call chain, so it can re-probe the
outputs when a laptop comes back from suspend/unsuspend (actually, any
time that we enter our VT again). The X server should then send RR*
events to clients, so they can cope with a monitor that was unplugged
while the laptop was suspended.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
It reports vertical size in cm in the detailed mode.
X.Org bug#21750 <http://bugs.freedesktop.org/show_bug.cgi?id=21750>
Reported-by: Peter Poklop <Peter.Poklop@gmx.at>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This way clients querying the gamma value via the VidMode extension at least
get the last value set via the same, rather than always something bogus.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
The reciprocal gamma value was missed in the first copy and this mistake was
propagated to the second one.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
A driver with this hook will take care of preparing the outputs & crtcs,
so calling the prepare functions will just cause unnecessary flicker.
Fixes bug #21077
This panel reports its vertical size in cm.
X.Org bug#21000 <http://bugs.freedesktop.org/show_bug.cgi?id=21000>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
There is a separate panning region check, but that doesn't work under
transformation, so just pre-clip the mouse coordinates when computing the
panning offsets. This leaves the case where panning constants are changing
unresolved.
Signed-off-by: Keith Packard <keithp@keithp.com>
When the crtc transformation changes, the entire crtc must be repainted.
This was being done by clearing the shadow and then painting the rectangle
containing the screen image; the clear being required as the screen image
may not fill the crtc. When changing the transform rapidly, this leads to
flashing. Eliminate the clear by painting the entire crtc instead of just
the screen rectangle.
Signed-off-by: Keith Packard <keithp@keithp.com>
All you get for standard timing descriptors is horizontal size in
multiples of 8 pixels (which means you can't say 1366) and height in
terms of aspect ratio (which means you can't say 768). You'd like to
just fuzzy-match this by walking the DMT list for sufficiently close
modes, but you can't because DMT is useless and only defines a 1360x768
mode, because it's _also_ specified in terms of character cells despite
providing pixel exact timings. Neither can you use CVT or GTF to
generate the timings, because they _also_ believe that modes have to be
a multiple of 8 pixels.
You'd also hope you could find a timing definition for this in CEA, but
you can't because CEA only defines transmission formats that actually
exist. So there's 480p, 720p, and 1080p, but no 768p. And why would
there be, after all, the encoded signal is never 768p so obviously no
one would ever make a display in that format.
So instead, make a CVT mode since that's likely to be handled well by
just about everything, smash the horizontal active down by 2, and shift
the sync pulse by 1. Underscanning the hard way.
Pass the suicide.
Otherwise drivers have to refuse interlace twice: once in the output
config, and once in ->valid_mode() to catch output and config modes.
If you can't do interlaced modes, asking nicely for it in the config
isn't going to suddenly make it work.
This patch gets the shadow scanout buffer repainted on panning area changes.
It does not, however, track the mouse correctly.
Signed-off-by: Keith Packard <keithp@keithp.com>
When the shadow scanout buffer can be re-used, the underlying framebuffer
area must be damaged so that the scanout will be repainted. This patch
delays the addition of that damaged area until after the transform in the
crtc has been updated, otherwise the old transform would have been used and
the wrong area repainted.
Signed-off-by: Keith Packard <keithp@keithp.com>
Drivers not using the new hw/xfree86/modes code would crash in DRI due to
that code trying to monitor CRTC changes.
Signed-off-by: Keith Packard <keithp@keithp.com>
We report the EDID values in RandR, and we let people configure whatever
they like for the screen in xorg.conf. Reporting the EDID values in the core
means applications get inconsistent font sizes in the default configuration.
Signed-off-by: Keith Packard <keithp@keithp.com>
