Embarassingly, it looks like I introduced this dead function in
commit 13c7d53df8 a year ago.
Nothing ever used it, not even then.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This uses the wrapper in case we need to emulate poll with select
as we do on Windows.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This error code can mean we're submitting more rects at once than the
driver can handle. If that happens, resubmit one at a time.
v2: Make the rect submit loop more error-proof (Walter Harms)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michael Thayer <michael.thayer@oracle.com>
With no users of the interface needing the readmask anymore, we can
remove it from the argument passed to these functions.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is a cleanup, proposed by Adam Jackson, but wasn't merged with
the original NotifyFD changes.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Commit 80e64dae: "modesetting: Implement PRIME syncing as a sink" originally was
supposed to have this line, but it was dropped as part of the merge process.
Foregoing the NULL assignment causes a ton of problems with dereferencing
uninitialized memory.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
In newer laptops with switchable graphics, the GPU may have 0 outputs,
in this case the modesetting driver should still load if the GPU is
SourceOffload capable, so that it can be used as an offload source provider.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
When a card has import capability it can be an offload _sink_, not
a source and vice versa for export capability.
This commit fixes the modesetting driver to properly set these
capabilities, this went unnoticed sofar because most gpus have both
import and export capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Server GPUs often have a VNC feature attached to allow remote console.
The controller implementing this feature is usually not very powerful,
and we can easily swamp it with work. This is made somewhat worse by
damage over-reporting the size of the dirty region, and a whole lot
worse by applications (or shells) that update the screen with identical
pixel content as was already there.
Fix this by double-buffering the shadow fb, using memcmp to identify
dirty tiles on each update pass. Since both shadows are in host memory
the memcmp is cheap, and worth it given the win in network bandwidth.
The tile size is somewhat arbitrarily chosen to be one cacheline wide at
32bpp on Intel Core.
By default we enable this behaviour for (a subset of) known server GPUs;
the heuristic could use work.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
24bpp front buffers tend to be the least well tested path for client
rendering. On the qemu cirrus emulation, and on some Matrox G200 server
chips, the hardware can't do 32bpp at all. It's better to just allocate
a 32bpp shadow and downconvert in the upload hook than expose a funky
pixmap format to clients.
[ajax: Ported from RHEL and separate modesetting driver, lifted kbpp
into the drmmode struct, cleaned up commit message, fixed 16bpp]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlied <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
[hdegoede@redhat.com: rebase, also use kbpp for rotate shadow fb]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
With the previous patch, the modesetting driver can now return whether
the driver supports hw cursor. However, it alone doesn't suffice,
unfortunately. drmmode_load_cursor_argb_check() is called in the
following chain:
xf86CursorSetCursor()
-> xf86SetCursor()
-> xf86DriverLoadCursorARGB()
-> xf86_load_cursor_argb()
-> xf86_crtc_load_cursor_argb()
-> drmmode_load_cursor_argb_check()
*but* at first with drmmode_crtc->cursor_up = FALSE. Then the
function doesn't actually set the cursor but returns TRUE
unconditionally. The actual call of drmmode_set_cursor() is done at
first via the show_cursor callback, and there is no check of sw cursor
fallback any longer at this place. Since it's called only once per
cursor setup, so the xserver still thinks as if the hw cursor is
supported.
This patch is an ad hoc fix to correct the behavior somehow: it does
call drmmode_set_cursor() at the very first time even if cursor_up is
FALSE, then quickly hides again. In that way, whether the hw cursor
is supported is evaluated in the right place at the right time.
Of course, it might be more elegant if we have a more proper mechanism
to fall back to sw cursor at any call path. But it'd need more
rework, so I leave this workaround as is for now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The modesetting driver still has an everlasting bug of invisible
cursor on cirrus and other KMS drivers where no hardware cursor is
supported. This patch is a part of an attempt to address it.
This patch particularly converts the current load_cursor_argb callback
of modesetting driver to load_cursor_argb_check so that it can return
whether the driver handles the hw cursor or falls back to the sw
cursor.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
[hdegoede@redhat.com: Add extra comment suggested by Kenneth]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The error value isn't always -EINVAL, e.g. the kernel drm core returns
-ENXIO when the corresponding ops doesn't exist. Without this fix,
DRM_IOCTL_MODE_CURSOR2 would be dealt as success even if it
shouldn't.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Implements (Start/Stop)FlippingPixmapTracking, PresentSharedPixmap, and
RequestSharedPixmapNotifyDamage, the source functions for PRIME
synchronization and double buffering. Allows modesetting driver to be used
as a source with PRIME synchronization.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
v5: Move disabling of reverse PRIME on sink to sink commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reverse PRIME seems to be designed with discrete graphics as a sink in
mind, designed to do an extra copy from sysmem to vidmem to prevent a
discrete chip from needing to scan out from sysmem.
The criteria it used to detect this case is if we are a GPU screen and
Glamor accelerated. It's possible for i915 to fulfill these conditions,
despite the fact that the additional copy doesn't make sense for i915.
Normally, you could just set AccelMethod = none as an option for the device
and call it a day. However, when running with modesetting as both the sink
and the source, Glamor must be enabled.
Ideally, you would be able to set AccelMethod individually for devices
using the same driver, but there seems to be a bug in X option parsing that
makes all devices on a driver inherit the options from the first detected
device. Thus, glamor needs to be enabled for all or for none until that bug
(if it's even a bug) is fixed.
Nonetheless, it probably doesn't make sense to do the extra copy on i915
even if Glamor is enabled for the device, so this is more user friendly by
not requiring users to disable acceleration for i915.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
v5: Unchanged
v6: Rebase onto ToT
v7: NULL check and free drmVersionPtr
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
UDL (USB 2.0 DisplayLink DRM driver) and other drivers for USB transport devices
have strange semantics when it comes to vblank events, due to their inability to
get the actual vblank info.
When doing a page flip, UDL instantly raises a vblank event without waiting for
vblank. It also has no support for DRM_IOCTL_WAIT_VBLANK, and has some strange
behavior with how it handles damage when page flipping.
It's possible to get something semi-working by hacking around these issues,
but even then there isn't much value-add vs single buffered PRIME, and it
reduces maintainability and adds additional risks to the modesetting driver
when running with more well-behaved DRM drivers.
Work needs to be done on UDL in order to properly support synchronized
PRIME. For now, just blacklist it, causing RandR to fall back to
unsynchronized PRIME.
This patch originally blacklisted UDL by name, but it was pointed out that there
are other USB transport device drivers with similar limitations, so it was
expanded to blacklist all USB transport devices.
v1: N/A
v2: N/A
v3: Initial commit
v4: Move check to driver.c for consistency/visibility
v5: Refactor to accomodate earlier changes
v6: Rebase onto ToT
v7: Expand to blacklist all USB transport devices, not just UDL
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
DPMS would prevent page flip / vblank events from being raised, freezing
the screen until PRIME flipping was reinitialized. To handle DPMS cleanly,
suspend PRIME page flipping when DPMS mode is not on, and resume it when
DPMS mode is on.
v1: Initial commit
v2: Moved flipping_active check from previous commit to here
v3: Unchanged
v4: Unchanged
v5: Move flipping_active check to sink support commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Implements (Enable/Disable)SharedPixmapFlipping and
SharedPixmapNotifyDamage, the sink functions for PRIME synchronization and
double buffering. Allows modesetting driver to be used as a sink with PRIME
synchronization.
Changes dispatch_slave_dirty to flush damage from both scanout pixmaps.
Changes drmmode_set_scanout_pixmap*() functions to
drmmode_set_target_scanout_pixmap*() that take an additional parameter
PixmapPtr *target. Then, treat *target as it did prime_pixmap. This allows
me to use it to explicitly set both prime_pixmap and prime_pixmap_back
individually. drmmode_set_scanout_pixmap() without the extra parameter
remains to cover the single-buffered case, but only works if we aren't
already double buffered.
driver.c:
Add plumbing for rr(Enable/Disable)SharedPixmapFlipping and
SharedPixmapNotifyDamage.
Change dispatch_dirty_crtc to dispatch_dirty_pixmap, which functions the
same but flushes damage associated with a ppriv instead of the crtc, and
chanage dispatch_slave_dirty to use it on both scanout pixmaps if
applicable.
drmmode_display.h:
Add flip_seq field to msPixmapPrivRec to keep track of the event handler
associated with a given pixmap, if any.
Add wait_for_damage field to msPixmapPrivRec to keep track if we have
requested a damage notification from the source.
Add enable_flipping field to drmmode_crtc_private_rec to keep track if
flipping is enabled or disabled.
Add prime_pixmap_back to drmmode_crtc_private_rec to keep track of back
buffer internally.
Add declarations for drmmode_SetupPageFlipFence(),
drmmode_EnableSharedPixmapFlipping(),
drmmode_DisableSharedPixmapFlipping, drmmode_SharedPixmapFlip(), and
drmmode_SharedPixmapPresentOnVBlank().
Move slave damage from crtc to ppriv.
drmmode_display.c:
Change drmmode_set_scanout_pixmap*() functions to
drmmode_set_target_scanout_pixmap*() that take an additional parameter
PixmapPtr *target for explicitly setting different scanout pixmaps.
Add definitions for functions drmmode_SharedPixmapFlip(),
drmmode_SharedPixmapPresentOnVBlank(),
drmmode_SharedPixmapPresent(),
drmmode_SharedPixmapVBlankEventHandler(),
drmmode_SharedPixmapVBlankEventAbort(),
drmmode_EnableSharedPixmapFlipping(), and
drmmode_DisableSharedPixmapFlipping,
drmmode_InitSharedPixmapFlipping(), and
drmmode_FiniSharedPixmapFlipping, along with struct
vblank_event_args.
The control flow is as follows:
pScrPriv->rrEnableSharedPixmapFlipping() makes its way to
drmmode_EnableSharedPixmapFlipping(), which sets enable_flipping to
TRUE and sets both scanout pixmaps prime_pixmap and
prime_pixmap_back.
When setting a mode, if prime_pixmap is defined, modesetting
driver will call drmmode_InitSharedPixmapFlipping(), which if
flipping is enabled will call drmmode_SharedPixmapPresent() on
scanout_pixmap_back.
drmmode_SharedPixmapPresent() requests that for the source to
present on the given buffer using master->PresentSharedPixmap(). If
it succeeds, it will then attempt to flip to that buffer using
drmmode_SharedPixmapFlip(). Flipping shouldn't fail, but if it
does, it will raise a warning and try drmmode_SharedPixmapPresent()
again on the next vblank using
drmmode_SharedPixmapPresentOnVBlank().
master->PresentSharedPixmap() could fail, in most cases because
there is no outstanding damage on the mscreenpix tracked by the
shared pixmap. In this case, drmmode_SharedPixmapPresent() will
attempt to use master->RequestSharedPixmapNotifyDamage() to request
for the source driver to call slave->SharedPixmapNotifyDamage() in
response to damage on mscreenpix. This will ultimately call
into drmmode_SharedPixmapPresentOnVBlank() to retry
drmmode_SharedPixmapPresent() on the next vblank after
accumulating damage.
drmmode_SharedPixmapFlip() sets up page flip event handler by
packing struct vblank_event_args with the necessary parameters, and
registering drmmode_SharedPixmapVBlankEventHandler() and
drmmode_SharedPixmapVBlankEventAbort() with the modesetting DRM
event handler queue. Then, it uses the drmModePageFlip() to flip on
the next vblank and raise an event.
drmmode_SharedPixmapPresentOnVBlank() operates similarly to
drmmode_SharedPixmapFlip(), but uses drmWaitVBlank() instead of
drmModePageFlip() to raise the event without flipping.
On the next vblank, DRM will raise an event that will ultimately be
handled by drmmode_SharedPixmapVBlankEventHandler(). If we flipped,
it will update prime_pixmap and prime_pixmap_back to reflect that
frontTarget is now being displayed, and use
drmmode_SharedPixmapPresent(backTarget) to start the process again
on the now-hidden shared pixmap. If we didn't flip, it will just
use drmmode_SharedPixmapPresent(frontTarget) to start the process
again on the still-hidden shared pixmap.
Note that presentation generally happens asynchronously, so with
these changes alone tearing is reduced, but we can't always
guarantee that the present will finish before the flip. These
changes are meant to be paired with changes to the sink DRM driver
that makes flips wait on fences attached to dmabuf backed buffers.
The source driver is responsible for attaching the fences and
signaling them when presentation is finished.
Note that because presentation is requested in response to a
vblank, PRIME sources will now conform to the sink's refresh rate.
At teardown, pScrPriv->rrDisableSharedPixmapFlipping() will be
called, making its way to drmmode_FiniSharedPixmapFlipping().
There, the event handlers for prime_pixmap and prime_pixmap_back
are aborted, freeing the left over parameter structure. Then,
prime_pixmap and prime_pixmap back are unset as scanout pixmaps.
Register and tear down slave damage per-scanout pixmap instead of
per-crtc.
v1: Initial commit
v2: Renamed PresentTrackedFlippingPixmap to PresentSharedPixmap
Renamed flipSeq to flip_seq
Warn if flip failed
Use SharedPixmapNotifyDamage to retry on next vblank after damage
v3: Refactor to accomodate moving (rr)StartFlippingPixmapTracking and
(rr)(Enable/Disable)SharedPixmapFlipping to rrScrPrivRec from ScreenRec
Do damage tracking on both scanout pixmaps
v4: Tweaks to commit message
v5: Revise for internal storage of prime pixmap ptrs
Move disabling for reverse PRIME from source commit to here
Use drmmode_set_target_scanout_pixmap*() to set scanout pixmaps
internally to EnableSharedPixmapFlipping().
Don't support flipping if ms->drmmode.pageflip == FALSE.
Move flipping_active check to this commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
ms->drmmode.pageflip was only loaded from options if ms->drmmode.glamor was
defined, otherwise it would always assume FALSE.
PRIME Synchronization requires ms->drmmode.pageflip even if we aren't using
glamor, so load it unconditionally.
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
drmmode_set_scanout_pixmap_(cpu/gpu) would only do teardown if ppix ==
NULL. This meant that if there were consecutive calls to
SetScanoutPixmap(ppix != NULL) without calls to SetScanoutPixmap(ppix ==
NULL) in between, earlier calls would be leaked. RRReplaceScanoutPixmap()
does this today.
Instead, when setting a scanout pixmap, always do teardown of the existing
scanout pixmap before setting up the new one. Then, if there is no new one
to set up, stop there.
This maintains the previous behavior in all cases except those with
multiple consecutive calls to SetScanoutPixmap(ppix != NULL).
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
modesetting relied on randr_crtc->scanout_pixmap being consistent with
calls to SetScanoutPixmap, which is very fragile and makes a lot of
assumptions about the caller's behavior.
For example, RRReplaceScanoutPixmap(), when dropping off with !size_fits,
will set randr_crtc->scanout_pixmap = NULL and then call SetScanoutPixmap.
Without this patch, drmmode_set_scanout_pixmap_(cpu/gpu) will think that
there is no scanout pixmap to tear down, because it's already been set to
NULL.
By keeping track of the scanout pixmap in its internal state, modesetting
can avoid these types of bugs and reduce constraints on calling
conventions.
v1: N/A
v2: N/A
v3: N/A
v4: N/A
v5: Initial commit
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
[fix copied from 40191d82370e in xf86-video-ati]
Without this, we end up setting rotated CRTCs back to their previous
framebuffer right after we perform a rotation. Reproducer:
- Have two monitors connected at the same resolution
- Rotate one monitor from normal straight to inverted
- Watch as the monitor you didn't rotate either freezes or shows intense
flickering
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If we're doing reverse-prime; or doing rotation the main fb is not used,
and there is no reason to add it in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
drmmode_set_mode_major() is the only user of drmmode->fb_id and will
create it if necessary.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This ensures the fb gets re-added when a shared pixmap is re-used for
a second drmmode_set_scanout_pixmap_cpu call.
Note currently the xserver never re-uses a shared pixmap in this way,
so this is mostly a sanity fix.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
drmmode_set_scanout_pixmap_gpu(pix) adds drmmod->fb_id through a call
to drmmode_xf86crtc_resize(), but on a subsequent
drmmode_set_scanout_pixmap_gpu(NULL) it would not remove the fb.
This keeps the crtc marked as busy, which causes the dgpu to not
being able to runtime suspend, after an output attached to the dgpu
has been used once. Which causes burning through an additional 10W
of power and the laptop to run quite hot.
This commit adds the missing remove fb call, allowing the dgpu to runtime
suspend after an external monitor has been plugged into the laptop.
Note this also makes drmmode_set_scanout_pixmap_gpu(NULL) match the
behavior of drmmode_set_scanout_pixmap_cpu(NULL) which was already
removing the fb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This is an ABI break, in that we now pass NULL to a function that hasn't
accepted it before.
Alex Goins had a different patch for this but it wasn't symmetrical, it
freed something in a very different place than it allocated it, this
attempts to retain symmetry in the releasing of the backing bo.
v2: use a new toplevel API, though it still passes NULL to something
that wasn't expecting it.
v3: pass -1 instead of 0.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Goins <agoins at nvidia.com>
No longer needed now that xf86CursorResetCursor is getting called for
each CRTC configuration change.
v2: Keep xf86_reload_cursors as a deprecated empty inline function
until all drivers stop calling it. (Adam Jackson)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Use this instead of the (now deprecated) cursor pointer in the
xf86CrtcConfigRec.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fix build without --enable-glamor.
Caught by the arm tinderbox.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This moves the capabilites setting to after glamor is initialised, and
enables the offload caps in cases where they work. This enables DRI2
PRIME support with modesetting.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise ms_ent_priv will return NULL and things will fall apart.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For some reason a couple of the dirty functions in driver.c used 8
spaces per tab instead of 4 like the rest of the file. Fix this to make
it more consistent and give me more room to work in ms_dirty_update in
subsequent commits.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Both radeon and amdgpu don't set the mode until the first blockhandler,
this means everything should be rendered on the screen correctly by
then.
This ports this code, it also removes the tail call of EnterVT from
ScreenInit, it really isn't necessary and causes us to set a dirty mode
with -modesetting always anyways.
v2: reorder set desired modes vs block handler as done for amdgpu.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This adds support using glamor for background None.
loosely based off the amdgpu code. relies on the glamor_finish code.
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Setting crtc->transformPresent to FALSE was preventing the transform
from actually taking effect and putting RandR into a confused state.
Now that the RandR 1.2 cursor code handles transforms correctly, we can
allow them to properly take effect.
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes build errors of:
present.c: In function 'ms_do_pageflip':
present.c:410:17: error: 'drmmode_bo' has no member named 'gbm'
new_front_bo.gbm = glamor_gbm_bo_from_pixmap(screen, new_front);
^
present.c:412:22: error: 'drmmode_bo' has no member named 'gbm'
if (!new_front_bo.gbm) {
^
present.c: In function 'ms_present_check_flip':
present.c:536:36: error: 'drmmode_bo' has no member named 'gbm'
if (drmmode_crtc->rotate_bo.gbm)
^
Introduced by commit 13c7d53d
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This moves the code from the platform case into
a common function, and calls that from the
other two.
v2: Emil convinced me we don't need to lookup pEnt
here, so let's not bother.
Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This isn't used anywhere, so no point storing it until we need it.
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Replace the block/wakeup handlers with a NotifyFd callback.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
DestroyPixmap handles that just fine. This also lets us drop our use
of the manual image destruction function (Note that the radeon driver
still uses it in a similar fashion, though).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The ifdef checks for XF86_CRTC_VERSION >= 3/5 are remnants from the
out-of-tree driver. Within the tree, we can rely on:
xf86Crtc.h:#define XF86_CRTC_VERSION 6
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We calloc() output_ids. Let's free() it, too.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This fixes a bug where running the card out of PPLL's when hotplugging
another monitor would result in all of the displays going blank and
failing to work properly until X was restarted or the user switched to
another VT.
[Michel Dänzer: Pass errno instead of -ret to strerror()]
[Daniel Martin: Add \n to log message]
Picked from xf86-video-ati
7186a87 Handle failures in setting a CRTC to a DRM mode properly
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
A user on a nouveau-driven card ran into a problem where DVI-D-1 and
DVI-I-1 were aliasing. The simplest fix is to provide the full connector
names. While we're at it, rename the output names to match what is in
the kernel, and start counting the connectors from 1 rather than 0. The
only deviation is HDMI vs HDMI-A, which kept its original name.
This will break backwards compatibility with existing xorg.conf's that
reference output names, but the alternative is to create a separate
counting system, further disconnecting from the kernel names.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Descriptions for Options PageFlip and SWCursor.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds zaphod and ZaphodHeads support
to the the in-server modesetting driver.
this is based on a request from Mario,
and on the current radeon driver, along
with some patches from Mario to bring things
up to the state of the art in Zaphod.
v2: fixup vblank fd registring.
v3: squash Mario's fixes.
modesetting: Allow/Fix use of multiple ZaphodHead outputs per x-screen.
modesetting: Take shift in crtc positions for ZaphodHeads configs into account.
modesetting: Add ZaphodHeads description to man page.
small cleanups (airlied).
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
