I doubt anyone builds with this turned off or has done for a long
time.
It helps my eyes bleed slightly less when reading the code, I've left
the define in place as some drivers use it.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If no compat_output is defined, we inadvertently (attempt to) return
whatever data is at index -1. Instead, return NULL since that's what
callers are expecting.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
This creates an automatic monitor for a tiled monitor at startup.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This puts the tiles of the monitor in the right place at
X server startup.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Change the X server default to do right-of placement
at startup. This gives an option to allow drivers to
override this placement, which has been used for server
drivers where both heads are not in the same physical
place.
Been in Fedora for a few years, but for tiled monitors
we really want something along these lines.
This is an ABI break.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add support for drivers to set the tiling
property. This is used by clients to
work out the monitor tiles for DisplayID
monitors.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Don't try to destroy rotation_damage in the xf86RotateCloseScreen; it
will have been destroyed when the screen pixmap was destroyed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When no shadow frame buffer is needed, the rotate block handler
doesn't need to be called any more. Remove it from the chain.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
xf86Rotate, it was delaying unwrapping the BlockHandler until after
calling xf86RotateRedisplay. If there was a software cursor on the
screen, the redisplay operation would cause cursor to be removed from
the frame buffer and the misprite block handler to be inserted into
the block handler chain with the misprite screen private saved block
handler now set to xf86RotateBlockHandler.
When xf86RotateRedisplay returned, xf86RotateBlockHandler would then
set screen->BlockHandler to its saved value, call down and then reset
screen->BlockHandler to xf86RotateBlockHandler. miSpriteBlockHandler
would never be called after that, which meant that the software cursor
will now disappear from the screen whenever rendering overlapped and
would only reappear when the cursor was moved.
To correct this, all that is needed is to move the restoration of
screen->BlockHandler to the top of xf86RotateBlockHandler, before the
call to xf86RotateRedisplay.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Create load_cursor_image_check, load_cursor_argb_check,
LoadCursorImageCheck and LoadCursorARGBCheck that can return failure
and use them in preference to the old unchecked variants.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michael Thayer <michael.thayer@oracle.com>
load_cursor_argb() may need to be able to fail and have the server fall back
to a software cursor in at least the following circumstances.
1) The hardware can only support some ARGB cursors and this does not just
depend on cursor size.
2) Virtual hardware may not wish to pass through a cursor to the host at a
particular time but may wish to accept the same cursor at another time.
This patch adds a return value to the API and makes the server do the
software fall-back on failure.
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The detailed timings are for a 15.6" display when max image size
correctly reports 13.3".
Signed-off-by: Arun Raghavan <arun@accosted.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This gets the easy warnings, mostly constant string problems.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Instead of only relying on the Range section, we can do better on
HDMI to find out what is the max dot clock the monitor supports. The
HDMI CEA vendor block adds a TMDS max freq we can use.
This makes X not prune 4k resolutions on HDMI.
v2: Replace X_INFO by X_PROBED in the message that prints the max
TMDS frequency (Chris Wilson)
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
With outputless GPUs showing up we crash here if there are not outputs
try and recover with a bit of grace.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
EDID sometimes lies about screen sizes. Since the screen size is used
by clients to determine the DPI a wrong ration will lead to terrible
looking fonts.
Add a sanity check for the h/v ratio cutting off at 2.4. This would
still accept the cinemascope aspect ratio as valid.
Also add message suggesting to add a quirk table entry.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
You can only register one drawable on a given damage, so there's no
reason to require the caller to specify the drawable, the damage is
enough. The implementation would do something fairly horrible if you
_did_ pass mismatched drawable and damage, so let's avoid the problem
entirely.
v2: Simplify xf86RotateDestroy even more [anholt]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
newer automake gets quite noisy about this.
hw/xfree86/ddc/Makefile.am:7: warning:
'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
and many more of these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Commit 8f4640bdb9 fixed a bit of a
chicken-and-egg problem by detaching GPU screens when their providers
are destroyed, which happens before CloseScreen is called. However,
this created a new problem: the GPU screen tears down its RandR crtc
objects during CloseScreen and if one of them is active, it tries to
detach the scanout pixmap then. This crashes because
RRCrtcDetachScanoutPixmap tries to get the master screen's screen
pixmap, but crtc->pScreen->current_master is already NULL at that
point.
It doesn't make sense for an unbound GPU screen to still be scanning
out its former master screen's pixmap, so detach them first when the
provider is destroyed.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Too many callers relied on the refcnt being handled correctly. Use a simple
wrapper to handle that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no point in turning on outputs connected to GPU screens during initial
configuration. Not only does this cause them to just display black, it also
confuses clients when these screens are attached to a master screen and RandR
reports that the outputs are already on.
Also, don't print the warning about no outputs being found on GPU screens,
since that's expected.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@gmail.com>
scrn->display is a property of the main screen really, and we don't
want to have the GPU screens use it for anything when picking modes
or a front buffer size.
This fixes a bug where when you plugged a display link device, it
would try and allocate a screen the same size as the current running
one (3360x1050 in this case), which was too big for the device. Avoid
doing this and just pick sizes based on whats plugged into this device.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When we disconnect an output/offload slave set the changed bits,
so a later TellChanged can do something.
Then when we remove a GPU slave device, sent change notification
to the protocol screen.
This allows hot unplugged USB devices to disappear in clients.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
commit 6703a7c7cf
Author: Keith Packard <keithp@keithp.com>
Date: Tue Jan 8 20:24:32 2013 -0800
hw/xfree86: Require only one working CRTC to start the server.
changed the logic to try to set the mode on all connected outputs rather
than abort upon the first failure. The return error code was then
tweaked such that it reported success if it set a mode on any crtc.
However, this confuses the headless case where we never enable any crtcs
and also, importantly, never fail to set a crtc.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59190
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Also-written-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This removes a large number of redundant declaration warnings.
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Section "Monitor"
Identifier "a21inch"
Option "PreferredMode" "1600x1200"
Option "ZoomModes" "1600x1200 1280x1024 1280x1024 640x480"
EndSection
The option's effect is to search for and mark once each named mode in
the output modes list. So the specification order is free and the zoom
modes sequence follows the order of the output modes list. All marked
modes are available via the Ctrl+Alt+Keypad-{Plus,Minus} key
combination.
See also http://bugs.freedesktop.org/show_bug.cgi?id=17954.
This option has its use for combined monitor and television setups.
It allows for easy switching between 60 Hz and 50 Hz modes even when a
monitor refuses to display the input signal.
(Includes a few minor changes suggested by Aaron for v2)
Signed-off-by: Servaas Vandenberghe <vdb@picaros.org>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
So in the cold plug server shutdown case, we reap the resources
before we call CloseScreen handlers, so the config->randr_provider
is a dangling pointer when the xf86CrtcCloseScreen handler is called,
however in the hot screen unplug case, we can't rely on automatically
reaped resources, so we need to clean up the provider in the xf86CrtcCloseScreen
case.
This patch provides a cleanup callback from the randr provider removal
into the DDX so it can cleanup properly, this then gets called by the automatic
code for cold plug, or if hot unplug it gets called explicitly.
Fixes a number of random server crashes on shutdown
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58174
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=891140
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The previous fix for the previous fix, didn't fully work,
If we don't set compat_output we end up doing derferences
of arrays with -1, leading to valgrind warnings.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of requiring every mode set to complete successfully, start up
as long as at least one CRTC is working. This avoids failures when one
or more CRTCs can't start due to mode setting conflicts.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Following commit 37d956e3ac
Author: Keith Packard <keithp@keithp.com>
Date: Mon Sep 10 11:14:20 2012 +1000
xf86: fix compat output selection for no output GPUs
headless servers can no longer startup as we no longer select a compat
output for the fake framebuffer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is set by pre_init not screen init, so if we free it here
and then recycle the server, we lose all the providers.
I think we need to wrap FreeScreen here to do this properly,
will investigate for 1.14 most likely, safer to just leak this
on server exit for now.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The core RandR screen cleanup now involves cleaning up any GPU screen
associations, and those call down into DDX to clean up the driver. If
the pointers from the xf86 structures back to the core randr
structures are set to NULL at that point, bad things happen.
This patch "knows" that the core RandR close screen is underneath the
xf86 randr close screen function, and so makes sure it gets called
first.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The indenter seems to have gotten confused by initializing arrays of
structs with the struct defined inline - for predefined structs it did
a better job, so match that.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The RandR CRTC structures are freed when their resource IDs are
destroyed during server shut down, which is before the screen is
closed. Calling back into RandR with stale pointers just segfaults the
server.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Knut Petersen <knut_petersen@t-online.de>
Panning is at odds with CRTC cursor confinement. This disables CRTC cursor
confinement as long as panning is enabled.
Fixes regression introduced in 56c90e29f0.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Let's say - purely for the sake of argument, mind you - that you had a
server GPU with anemic memory bandwidth, and you walked up to it and
plugged in a monitor that was 1920x1080 because that's what happened to
be on the crash cart. Say the memory bandwidth is such that anything
larger than 1280x1024 gets filtered away. Now you're in trouble,
because the established timings section includes a 720x400 mode because
that's what DOS 80x25 is, and that happens to just about match the
physical aspect ratio.
Instead let's reuse the logic from the existing aspect-match path: pick
the larger mode of either the physical aspect ratio or 4:3.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Based on the original patch by Chris Wilson, which was a better fix than mine.
We stash a copy of the desiredMode on the crtc so that we can restore it
after a vt switch. This copy is a simple memcpy and so also stashes a
references to the pointers contained within the desiredMode. Those
pointers are freed the next time the outputs are probed and mode list
rebuilt, resulting in us chasing those dangling pointers on the next
mode switch.
==22787== Invalid read of size 1
==22787== at 0x40293C2: __GI_strlen (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22787== by 0x668F875: strdup (strdup.c:42)
==22787== by 0x5DBA00: XNFstrdup (utils.c:1124)
==22787== by 0x4D72ED: xf86DuplicateMode (xf86Modes.c:209)
==22787== by 0x4CA848: xf86CrtcSetModeTransform (xf86Crtc.c:276)
==22787== by 0x4D05B4: xf86SetDesiredModes (xf86Crtc.c:2677)
==22787== by 0xA7479D0: sna_create_screen_resources
(sna_driver.c:220)
==22787== by 0x4CB914: xf86CrtcCreateScreenResources (xf86Crtc.c:725)
==22787== by 0x425498: main (main.c:216)
==22787== Address 0x72c60e0 is 0 bytes inside a block of size 9 free'd
==22787== at 0x4027AAE: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22787== by 0x4A547E: xf86DeleteMode (xf86Mode.c:1984)
==22787== by 0x4CD84F: xf86ProbeOutputModes (xf86Crtc.c:1578)
==22787== by 0x4DC405: xf86RandR12GetInfo12 (xf86RandR12.c:1537)
==22787== by 0x518119: RRGetInfo (rrinfo.c:202)
==22787== by 0x51D997: rrGetScreenResources (rrscreen.c:335)
==22787== by 0x51E0D0: ProcRRGetScreenResources (rrscreen.c:475)
==22787== by 0x513852: ProcRRDispatch (randr.c:493)
==22787== by 0x4346DB: Dispatch (dispatch.c:439)
==22787== by 0x4256E4: main (main.c:287)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36108
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
