Instead of from drmmode_set_mode_major. There's no need to re-set the
gamma LUT on every modeset, the kernel should preserve it.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
In that case (with DC as of 4.17 kernels), the display hardware applies
gamma to the HW cursor.
v2:
* Also use all 0s when alpha == 0 in the gamma passthrough case.
Bugzilla: https://bugs.freedesktop.org/106578
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We compose the two LUTs when pushing non-legacy gamma changes, and the
same needs to be done when setting legacy gamma.
To do so, we just call push_cm_prop() on the gamma LUT. It will compose
the LUTs for us, and fall back to using legacy LUT (upscaled to non-
legacy size) if non-legacy is unavailable.
It's also possible that the Kernel has no support support for non-
legacy color. In which case, we fall back to legacy gamma.
v2: Remove per-CRTC check for color management support.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Frequently, a user may have non-legacy gamma enabled for monitor
correction, while using legacy gamma for things like
redshift/nightlight.
To do so, we compose the two LUTs. Legacy gamma will be applied first,
then non-legacy. i.e. non-legacy_LUT(legacy_LUT(in_color)).
Note that the staged gamma LUT within the driver-private CRTC will
always contain the non-legacy LUT. This is to ensure that we have a
cached copy for future compositions.
v2: Don't compose LUTs if legacy gamma is disabled (which is the case
for deep 30bpp color). The legacy LUT won't be computed here,
causing composition to spit out something invalid.
v3: Use LUT sizes that are now cached in drmmode.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
[ Michel Dänzer: Replace "crtc->funcs->gamma_set == NULL" with
!crtc->funcs->gamma_set ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Setting a color property involves:
1. Staging the property onto the driver-private CRTC object
2. Pushing the staged property into kernel DRM, for HW programming
Add a function to do the staging, and execute the above steps in
output_property_set.
v2:
- Remove per-CRTC check for color management support in stage_cm_prop.
- Use switch statement instead of if statements.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Notify RandR of any updated color properties on the output's CRTC when
its get_property() hook is called.
v2: Remove per-CRTC check for color management support.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
List color management properties on outputs if there is kernel support.
Otherwise, don't list them at all.
v2:
- Use switch statement in configure_and_change
- Also configure LUT sizes for outputs that don't have an attached CRTC.
We can do this since LUT sizes are now cached on the drmmode object.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
[ Michel Dänzer: Drop const from data pointer declaration in
rr_configure_and_change_cm_property, to avoid warning when building
against xserver 1.13 ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
And destroy them on the CRTC destroy hook.
When initializing color management properties on the private
drmmode_crtc, we want to:
1. Default its color transform matrix (CTM) to identity
2. Program hardware with default color management values (SRGB for
de/regamma, identity for CTM)
It's possible that cm initialization fails due to memory error or DRM
error. In which case, the RandR state may not reflect the actual
hardware state.
v2:
- Use switch statement in push_cm_prop
- Get rid of per-CRTC cm support checks. Keep it simple and only check
the first CRTC, since kernel will always report all or nothing for AMD
hardware.
- Remove per-CRTC LUT size caching, drmmode now holds that. Update
commit message to reflect this.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
[ Michel Dänzer: Replace "drmmode_crtc->ctm == NULL" with
!drmmode_crtc->ctm ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
DRM creates property types with unique IDs during kernel driver init.
Cache the color property IDs on DDX init for use later, when we need
to modify these properties. Also cache the (de)gamma LUT sizes, since
they are the same for all CRTCs on AMD hardware.
Since these values are the same regardless of the CRTC, they can be
cached within the private drmmode_rec object. We can also use any color-
management-enabled CRTC to initially fetch them.
Also introduce an enumeration of possible color management properties,
to provide a easy and unified way of referring to them.
v2:
- Reorder cm property enum so that LUT sizes are at the end. This allows
us to use DEGAMMA_LUT_SIZE as an anchor for iterating over mutable cm
properties.
- Cache (de)gamma LUT sizes within drmmode, since it's the same for all
CRTCs on AMD hardware. Update commit message to reflect this.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
When enabling a secondary GPU output, Xorg can try resizing the screen
beyond the limit advertised by the driver, leading to drmModeAddFB
failing and primary GPU outputs turning off. Check for this and bail
instead.
Leo pointed out that drmmode_do_crtc_dpms wasn't getting called when
turning off an output with
xrandr --output <output> --off
This meant that the vblank sequence number and timestamp wouldn't be
saved before turning off the CRTC in this case.
Reported-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Reviewed-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Compilation failed with XSERVER_PLATFORM_BUS undefined:
../../src/amdgpu_probe.c: In function ‘amdgpu_kernel_open_fd’:
../../src/amdgpu_probe.c:133:21: error: dereferencing pointer to incomplete type ‘struct xf86_platform_device’
dev = platform_dev->pdev;
^~
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
[ Michel Dänzer:
* Fixed remaining preprocessor guards to work with xserver 1.13
* Touched up commit log ]
This prevents a nested call to drmHandleEvent, which would hang.
Fixes hangs when disabling TearFree on a CRTC while a DRI3 client is
page flipping.
Reviewed-by: Samuel Li <Samuel.Li@amd.com>
When disabling TearFree, drmmode_crtc->scanout_id could remain as 1,
but drmmode_set_mode_major would destroy drmmode_crtc->scanout[1], so
scanout_do_update() would keep bailing, and the scanout buffer would
stop being updated.
Fixes freeze after disabling TearFree on a CRTC with active RandR
rotation or other transform.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Set crtc->driverIsPerformingTransform for any case we can handle before
calling xf86CrtcRotate. We already clear it afterwards when the latter
clears crtc->transform_in_use.
This should allow our separate scanout buffer mechanism to be used in
more cases.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
It means we are not using our own scanout buffers.
Fixes crash when TearFree is supposed to be enabled, but
drmmode_handle_transform doesn't set crtc->driverIsPerformingTransform.
Bugzilla: https://bugs.freedesktop.org/105736
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We don't need to wait for a non-TearFree scanout update before scanning
out from the screen pixmap or before flipping, as the scanout update
won't be visible anyway. Instead, just abort it.
There is a case that when set screen from reverse to normal, the old
scanout damage is freed in modesetting before scanout update handler,
so it causes segment fault issue.
Signed-off-by: Jim Qu <Jim.Qu@amd.com>
[ Michel Dänzer: Only call drmmode_crtc_wait_pending_event before
drmmode_crtc_scanout_free is actually called, slightly tweak commit
message ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
amdgpu_scanout_extents_intersect could leave the scanout damage region
in an invalid state, triggering debugging checks in pixman:
*** BUG ***
In pixman_region_append_non_o: The expression r->x1 < r->x2 was false
Set a breakpoint on '_pixman_log_error' to debug
We were clobbering entries in mi's global miSpritePointerFuncs struct,
which cannot work correctly with multiple primary screens. Instead,
assign a pointer to our own wrapper struct to PointPriv->spriteFuncs.
Fixes crashes with multiple primary screens.
Fixes: 69e20839bf ("Keep track of how many SW cursors are visible on
each screen")
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Since xf86CursorCloseScreen runs after AMDGPUCloseScreen_KMS,
PointPriv->spriteFuncs doesn't point to the same struct in the latter as
in AMDGPUCursorInit_KMS. So we were restoring info->Set/MoveCursor to
the wrong struct. Then in the next server generation,
info->Set/MoveCursor would end up pointing to
drmmode_sprite_set/move_cursor, resulting in an infinite loop if one of
them was called.
To avoid this, only change the Set/MoveCursor hooks if their values
match our expectations, otherwise leave them as is. This is kind of a
hack, but the alternative would be invasive and thus risky changes to
the way we're wrapping CloseScreen, and it's not even clear that can
work without changing xserver code.
Fixes: 69e20839bf ("Keep track of how many SW cursors are visible on
each screen")
(Ported from radeon commit 504b8721b17a672caf1ed3eab087027c02458cab)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
We were updating the link-status property when a uevent came in, but
we also want to update the non-desktop property, and potentially
others as well. We also want to check at detect time in case we don't
get a hotplug event.
This patch updates every property provided by the kernel, sending
changes to DIX so it can track things as well.
Signed-off-by: Keith Packard <keithp@keithp.com>
(Ported from xserver commit a12485ed846b852ca14d17d1e58c8b0f2399e577,
slightly modifying logic to reduce indentation depth)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
If drmModeGetConnector() fails in drmmode_output_detect(), we have to
reset the output_id to -1 too.
Yet another spot leading to a potential NULL dereference when handling
the mode_output member as output_id was != -1. Though, this case should
be very hard to hit.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
(Ported from xserver commit 6804875662363764683a86c1614e4cf3cc70a20a)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Replace the various loops to lookup drmModeProperty(Blob)s by
introducing helper functions.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
(Ported from xserver commit f44935cdb7321af242ce9f242975f096807b97f7)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
xorg-server.h defines _XSERVER64 which is used in X.h to choose the
correct definition of XID
this prevents a failure in the present.h configure test that disables
DRI3 on X.Org 1.20
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
If we fail to find or set the mode for a CRTC, keep trying for the
remaining CRTCs, and only return FALSE if we failed for all CRTCs that
should be on.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
This reverts commit a23d1ff700.
pAMDGPUEnt cannot be NULL anymore here now that we no longer call
AMDGPUFreeRec directly from AMDGPUPreInit_KMS.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
DRI clients can use depth 32 pixmaps while the screen is depth 24, in
which case page flipping would fail.
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
(Ported from radeon commit 733f606dd6ca8350e6e7f0858bfff5454ddc98ed)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
[ Michel Dänzer:
* Require Xorg >= 1.19.99.1 for depth 30, otherwise it can't work with glamor
* Update manpage, per radeon commit
574bfab4bf1fcd95163a8f33cea2889189429d30 ]
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
gamma set is disabled in kernel driver when deep color.
Enable it will confuse the user.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
[ Michel Dänzer: Align drmmode_pre_init change with radeon commit
1f1d4b1fa7d4b22dd8553f7e71251bf17ca7a7b1 ]
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This allows to en-/disable some functions depending on individual screen
settings.
Prep work for more efficient depth 30 support.
Suggested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
(Ported from radeon commit 21f6753462464acfd3c452393328c977a375ce26)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
