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>
Remove code in xf86Wakeup for dealing with other input and switch to
using the new NotifyFd interface.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This new libXfont API eliminates exposing internal X server symbols to
the font library, replacing those with a struct full of the entire API
needed to use that library.
v2: Use libXfont2 instead of libXfont_2
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The intent here was that fallback drivers would be at the end of the
list in order, but if a fallback driver happened to be at the end of the
list already that's not what would happen. Rather than open-code
something smarter, just use qsort.
Note that qsort puts things in ascending order, so somewhat backwardsly
fallbacks are greater than native drivers, and vesa is greater than
modesetting.
v2: Use strcmp to compare non-fallback drivers so we get a predictable
result if your libc's qsort isn't stable (Keith Packard)
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
/dev/vc/0 is a devfs thing which is long dead, so stop trying to open
/dev/vc/0, besides being a (small) code cleanup this will also fix the
"parse_vt_settings: Cannot open /dev/tty0 (%s)\n" error message to
display the actual error, rather then the -ENOENT from also trying
/dev/vc/0.
BugLink: https://patchwork.freedesktop.org/patch/8768/
Reported-by: Chad Versace <chad.versace@linux.intel.com>
Suggested-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Chad Versace <chad.versace@intel.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>
Changes PRIME to use double buffering and synchronization if all required
driver functions are available.
rrcrtc.c:
Changes rrSetupPixmapSharing() to use double buffering and
synchronization in the case that all required driver functions are
available. Otherwise, falls back to unsynchronized single buffer.
Changes RRCrtcDetachScanoutPixmap() to properly clean up in the case of
double buffering.
Moves StopPixmapTracking() from rrDestroySharedPixmap() to
RRCrtcDetachScanoutPixmap().
Changes RRReplaceScanoutPixmap() to fail if we are using double buffering,
as it would need a second ppix parameter to function with double buffering,
and AFAICT no driver I've implemented double buffered source support in uses
RRReplaceScanoutPixmap().
randrstr.h:
Adds scanout_pixmap_back to struct _rrCrtc to facilitate PRIME
double buffering.
xf86Crtc.h:
Adds current_scanout_back to _xf86Crtc to facilitate detection
of changes to it in xf86RandR12CrtcSet().
xf86RandR12.c:
Changes xf86RandR12CrtcSet() to detect changes in
scanout_pixmap_back.
Adds scanout_pixmap_back to struct _rrCrtc to facilitate PRIME double
buffering.
v1: Initial commit
v2: Rename PresentTrackedFlippingPixmap to PresentSharedPixmap
v3: Refactor to accomodate moving (rr)StartFlippingPixmapTracking and
(rr)(Enable/Disable)SharedPixmapFlipping to rrScrPrivRec from ScreenRec
Add fallback if flipping funcs fail
v4: Detach scanout pixmap when destroying scanout_pixmap_back, to avoid
dangling pointers in some drivers
v5: Disable RRReplaceScanoutPixmap for double-buffered PRIME, it would need an
ABI change with support for 2 pixmaps if it were to be supported, but AFAICT
no driver that actually supports double-buffered PRIME uses it.
Refactor to use rrEnableSharedPixmapFlipping() as a substitute for
rrCrtcSetScanoutPixmap() in the flipping case.
Remove extraneous pSlaveScrPriv from DetachScanoutPixmap()
Remove extraneous protopix and pScrPriv from rrSetupPixmapSharing()
v6: Rebase onto ToT
v7: Unchanged
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Goins <agoins@nvidia.com>
Consolidate to a single if/else statement and eliminate the redundant
local variable in_range and assignments to x/y.
Reviewed-by: Adam Jackson <ajax@redhat.com>
The driver can now specify exactly which aspects of the transform it
wants to handle via XF86DriverTransform* flags.
Since the driver can now choose whether it wants to receive transformed
or untransformed cursor coordinates, xf86CrtcTransformCursorPos no
longer needs to be available to drivers, so make it static.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Even if the driver is handling the transform, we still need to transform
the cursor position for clipping, otherwise we may hide the HW cursor
when the cursor is actually inside the area covered by the CRTC.
v2: Use crtc_x/y local variables for clarity
Reviewed-by: Adam Jackson <ajax@redhat.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>
A single provider can be both a offload and source slave at the same time,
the use of seperate lists breaks in this case e.g. :
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
xrandr --setprovideroutputsource 1 0x7b
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
xrandr --setprovideroffloadsink 1 0x7b
xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Not good. The problem is that the provider with id 0x46 now is on both
the output_slave_list and the offload_slave_list of the master screen.
This commit fixes this by unifying all 3 lists into a single slaves list.
Note that this does change the struct _Screen definition, so this is an ABI
break. I do not expect any of the drivers to actually use the removed / changed
fields so a recompile should suffice.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
As documented in xorg.conf(5), a value of ConstantDeceleration between 0
and 1 will speed up the pointer. However, values less than 1 actually
had no effect. Fix this.
Note that this bug only affected "ConstantDeceleration" as configured
through xorg.conf, not "Device Accel Constant Deceleration" as configured
through xinput. The property handler AccelSetDecelProperty() also did
not need to be changed, as it did not limit the values of the property.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=92766
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to notice that it's set, but still pass it through to dix.
Return 0 to indicate this.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
A new --with-fallback-input-driver=foo option allows selecting a
fallback driver for the server if the driver configured for the device
is not found. Note that this only applies when the device has a driver
assigned and that module fails to load, devices without a driver are
ignored as usual.
This avoids the situation where a configuration assigns e.g. the
synaptics driver but that driver is not available on the system,
resulting in a dead device. A fallback driver can at least provides some
functionality.
This becomes more important as we move towards making other driver true
leaf nodes that can be installed/uninstalled as requested. Specifically,
wacom and synaptics, a config that assigns either driver should be
viable even when the driver itself is not (yet) installed on the system.
It is up to the distributions to make sure that the fallback driver is
always installed. The fallback driver can be disabled with
--without-fallback-input-driver and is disabled by default on non-Linux
systems because we don't have generic drivers on those platforms.
Default driver on Linux is libinput, evdev is the only other serious
candidate here.
Sample log output:
[ 3274.421] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event4)
[ 3274.421] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad weird driver"
[ 3274.421] (II) LoadModule: "banana"
[ 3274.422] (WW) Warning, couldn't open module banana
[ 3274.422] (II) UnloadModule: "banana"
[ 3274.422] (II) Unloading banana
[ 3274.422] (EE) Failed to load module "banana" (module does not exist, 0)
[ 3274.422] (EE) No input driver matching `banana'
[ 3274.422] (II) Falling back to input driver `libinput'
.. server proceeds to assign libinput, init the device, world peace and rainbows
everywhere, truly what a sight. Shame about the banana though.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Not visible in the patch, but the same stanza is repeated below inside
the #ifdef GLXEXT. There's no reason to bother with checking it if we
built without GLXEXT so remove the unconditional one.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The doc text is wrong at this point, input processing isn't going to
vary based on this, so we shouldn't say it does. The only thing this
_does_ get used for is DRI1 SwapBuffers (on everything but savage), and
if you disable it you're not going to get DRI1 at all, so we really
shouldn't even mention it.
Still, leave the option wired up to the parser so we don't break any
DRI1-driver-using setup relying on it being disabled, and so we don't
complain about unused options elsewhere.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
As the man page for the latter states:
The effects of signal() in a multithreaded process are unspecified.
We already have an interface to call sigaction() instead, use it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.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>
Fixes a crash on startup in the radeon driver's drmmode_show_cursor()
due to xf86_config->cursor == NULL, because no CRTC was enabled yet, so
xf86_crtc_load_cursor_image was never called.
(Also use scrn->pScreen instead of xf86ScrnToScreen(scrn))
v2: Set xf86_config->cursor at the beginning of xf86_load_cursor_image
instead of at the end.
Reviewed-by: Keith Packard <keithp@keithp.com>
Threaded input doesn't use SIGIO anymore, but existing drivers using
xf86BlockSIGIO and xf86ReleaseSIGIO probably want to lock the input
mutex during those operations. Provide inline functions to do this
which are marked as 'deprecated' so that drivers will get warnings
until they are changed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Oops. This didn't get removed when xfree86 was converted over to use
the input thread.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
threaded input can affect drivers that use OsBlockSIGIO when dealing
with cursors.
Signed-off-by: Keith Packard <keithp@keithp.com>
Requested-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Switch the XFree86 DDX over to threaded input
v2: Rewrite comment in xf86Helper about silken mouse
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current SIGIO signal handler method, used at generation of input events,
has a bunch of oddities. This patch introduces an alternative way using a
thread, which is used to select() all input device file descriptors.
A mutex was used to control the access to input structures by the main and input
threads. Two pipes to emit alert events (such hotplug ones) and guarantee the
proper communication between them was also used.
Co-authored-by: Fernando Carrijo <fcarrijo@freedesktop.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
v2: Fix non-Xorg link. Enable where supported by default.
This also splits out the actual enabling of input threads to
DDX-specific patches which follow
v3: Make the input lock recursive
v4: Use regular RECURSIVE_MUTEXes instead of rolling our own
Respect the --disable-input-thread configuration option by
providing stubs that expose the same API/ABI.
Respond to style comments from Peter Hutterer.
v5: use __func__ in inputthread debug and error mesages.
Respond to style comments from Peter Hutterer.
v6: use AX_PTHREAD instead of inlining pthread tests.
Suggested by Emil Velikov <emil.l.velikov@gmail.com>
v7: Use pthread_sigmask instead of sigprocmask when using threads
Suggested by Adam Jackson <ajax@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When this code was called from SIGIO, saving and restoring errno could
possibly have made sense in some strange environment. Now that this
will not be called from a signal handler, there is no reason to do that.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes all of the SIGIO handling support used for input
throughout the X server, preparing the way for using threads for input
handling instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO.
v2: Don't change locking order (Peter Hutterer)
v3: Comment weird && FALSE in xf86Helper.c
Leave errno save/restore in xf86ReadInput
Squash with stub adding patch (Peter Hutterer)
v4: Leave UseSIGIO config parameter so that
existing config files don't break (Peter Hutterer)
v5: Split a couple of independent patch bits out
of kinput.c (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Not all display managers make it easy (or possible) to modify the
command line flags passed to the server, so add a way to get to it from
xorg.conf.
v2: Fix the FlagOptions list to not have IGLX after the terminator (Alan
Coopersmith)
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This makes the cursor pointer held by xf86Cursors.c get reset to NULL
whenever the cursor isn't displayed, and means that the reference
count held in xf86Cursor.c is sufficient to cover the reference in
xf86Cursors.c.
As HideCursor may be called in the cursor loading path after
UseHWCursor or UseHWCursorARGB when HARDWARE_CURSOR_UPDATE_UNHIDDEN
isn't set in the Flags field, the setting of the cursor pointer had to
be moved to the LoadCursor paths.
LoadCursorARGBCheck gets the cursor pointer, but LoadCursorImageCheck
does not. For LoadCursorImageCheck, I added a new function,
xf86CurrentCursor, which returns the current cursor. With this new
function, we can eliminate the cursor pointer from the
xf86CrtcConfigRec, once drivers are converted over to use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
The destination variable is never freed, thus we even plug some memory
leaks.
v2: Rebase against updated xf86CheckPrivs() helper.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Current message was quite off "file specified must be a relative path"
and alike. Just factor it out and use "path/file" as needed.
v2: Rework error message, drop "Using default", print actual arg value.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
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>
Slave GPUs don't have a root window to set this on, so don't.
This fixes some crashes I saw just playing around.
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>
The tablet pads have been separate kernel devices for a while now and
libwacom has labelled them with the udev ID_INPUT_TABLET_PAD for over a year
now. Add a new MatchIsTabletPad directive to apply configuration options
specifically to the Pad part of a tablet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.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>
-Wlogical-op now tells us:
devices.c:1685:23: warning: logical ‘and’ of equal expressions
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
R_SP is also defined in <sys/ucontext.h> on m68k. Also remove duplicate
definitions.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Andreas Schwab <schwab@suse.de>
Rather than 'hacking' around symbol names and providing macros such as
'Local' just fold things and make the code more readable.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
... so that we can use it without the forward declaration. Plus we're
doing to reuse it in the next commit ;-)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Add the const notation to all the static storage as well as the
functions that use it - xf86getToken(), xf86getSubTokenWithTab(),
StringToToken() and xf86getStringToken().
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
All consumers have been ported to the root window callback, so this can
all be nuked.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Practically speaking, the EDID major version is never not 1.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We can call this more than once via xf86OutputSetEDID since hotplug is
actually a thing in RANDR 1.2, but xf86RegisterRootWindowProperty merely
adds the data to a list to be applied to the root at CreateWindow time,
so calls past the first (for a given screen) would have no effect until
server regen.
Once we've initialised pScrn->pScreen is filled in, so we can just set
the property directly.
v2: Removed pointless version check, deobfuscate math (Walter Harms)
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
For the dri2 backend, we depend on xfree86 already, so we can walk the
options for the screen looking for a vendor string from xorg.conf. For
the swrast backend we don't have that luxury, so just say mesa. This
extension isn't really meaningful on Windows or OSX yet (since libglvnd
isn't really functional there yet), so on those platforms we don't say
anything and return BadValue for the token from QueryServerString.
v2: Use xnf* allocators when parsing options (Eric and Emil)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
When the HW cursor is hidden (e.g. because xf86CursorResetCursor
triggers a switch from HW cursor to SW cursor), the driver isn't
notified of this for disabled CRTCs. If the HW cursor was shown when the
CRTC was disabled, it may still be displayed when the CRTC is enabled
again.
Prevent this by explicitly hiding the HW cursor again after setting a
mode if it's currently supposed to be hidden.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94560
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
There are no longer any loadable font modules (not that they ever did
much in the first place), so stop pretending they're a defined ABI
surface.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Was removed from the tree in:
commit f175cf45ae
Author: Olivier Fourdan <ofourdan@redhat.com>
Date: Wed Feb 10 09:34:34 2016 +0100
vidmode: move to a separate library of its own
but not removed from the Makefile, which broke 'make dist'.
Signed-off-by: Adam Jackson <ajax@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>
Add xf86CursorResetCursor, which allows switching between HW and SW
cursor depending on the current state.
Call it from xf86DisableUnusedFunctions, which is called after any CRTC
configuration change such as setting a mode or disabling a CRTC. This
makes sure that SW cursor is used e.g. while a transform is in use on
any CRTC or while there are active PRIME output slaves, and enables HW
cursor again once none of those conditions are true anymore.
Reviewed-by: Keith Packard <keithp@keithp.com>
We currently don't handle transforms for the HW cursor image, so return
FALSE to signal a software cursor must be used if a transform is in use
on any CRTC.
v2: Check crtc->transformPresent instead of crtc->transform_in_use. The
latter is TRUE for rotation as well, which we handle correctly.
Reviewed-by: Keith Packard <keithp@keithp.com>
This patch introduces a new flag ATTR_KEY for hotplugged input devices,
so we can better distinguish between real keyboards (i.e. devices with
udev property ID_INPUT_KEYBOARD="1") and other key input devices like
lid switches, power buttons, etc.
All supported hotplug backends (udev, hal, and wscons) will set both
flags ATTR_KEY and ATTR_KEYBOARD for real keyboards, but udev backend
will set ATTR_KEY, but not ATTR_KEYBOARD, for non-keyboard key input
devices (hal and wscons will set both flags in any case). With this
distinction, kdrive input hotplugging mechanism will be allowed to only
grab real keyboards, as other key input devices are currently not
supported.
In order to don't break current behaviour, this patch will replace all
ATTR_KEYBOARD occurrences with ATTR_KEY in hw/xfree86/common/xf86Xinput.c.
[ajax: Just add ATTR_KEY, don't re-number the other attributes]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Laércio de Sousa <laerciosousa@sme-mogidascruzes.sp.gov.br>
The API signature of the DIX xf86VidModeGetGammaRampSize() is now
identical to the xf86cmap's xf86GetGammaRampSize() and all it does is
actually call xf86GetGammaRampSize() so we can save one vfunc.
Remove uneeded xf86VidModeGetGammaRampSize() function.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The DIX already checks for VidModePrivateKey to get the vfunc, so
checking for this again in the DDX is redundant.
Remove the redundant function xf86VidModeAvailable() from the DDX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
XVidMode extension might be useful to non hardware servers as well (e.g.
Xwayand) so that applications that rely on it (e.g. lot of older games)
can at least have read access to XVidMode.
But the implementation is very XFree86 centric, so the idea is to add
a bunch of vfunc that other non-XFree86 servers can hook up into to
provide a similar functionality.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87806
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
To avoid confusion as to what belongs on the DDX and what not.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
To be able to reuse the VidMode extension in a non-hardware server, the
display mode definitions need to be accessible from DIX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The mode access functions (namely VidModeCreateMode(),
VidModeCopyMode(), VidModeGetModeValue() and VidModeSetModeValue()) are
used only in xf86VidMode code and do not need to be available anywhere
else.
Remove these functions from the public VidMode API and move them as
static where they are used.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
