From: Leo Li <sunpeng.li-5C7GfCeVMHo@public.gmane.org>
To: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH xf86-video-amdgpu 3/5] Keep CRTC properties consistent
Date: Tue, 10 Apr 2018 14:02:39 -0400 [thread overview]
Message-ID: <0b884ad3-c193-9eab-ca93-ff0ca0672f1e@amd.com> (raw)
In-Reply-To: <2fbbae9b-c874-7187-9b69-0a929dcaf5cf-otUistvHUpPR7s880joybQ@public.gmane.org>
On 2018-04-09 11:03 AM, Michel Dänzer wrote:
> On 2018-03-26 10:00 PM, sunpeng.li@amd.com wrote:
>> From: "Leo (Sunpeng) Li" <sunpeng.li@amd.com>
>>
>> In cases where CRTC properties are updated without going through
>> RRChangeOutputProperty, we don't update the properties in user land.
>>
>> Consider setting legacy gamma. It doesn't go through
>> RRChangeOutputProperty, but modifies the CRTC's color management
>> properties. Unless they are updated, the user properties will remain
>> stale.
>
> Can you describe a bit more how the legacy gamma and the new properties
> interact?
>
Sure thing, I'll include this in the message for v2:
In kernel, the legacy set gamma interface is essentially an adapter to
the non-legacy set properties interface. In the end, they both set the
same property to a DRM property blob, which contains the gamma lookup
table. The key difference between them is how this blob is created.
For legacy gamma, the kernel takes 3 arrays from user-land, and creates
the blob using them. Note that a blob is identified by it's blob_id.
For non-legacy gamma, the kernel takes a blob_id from user-land that
references the blob. This means user-land is responsible for creating
the blob.
From the perspective of RandR, this presents some problems. Since both
paths modify the same property, RandR must keep the reported property
value up-to-date with which ever path is used:
1. Legacy gamma via
xrandr --output <output_here> --gamma x:x:x
2. Non-legacy color properties via
xrandr --output <output_here> --set GAMMA_LUT <blob_id>
Keeping the value up-to-date isn't a problem for 2, since RandR updates
it for us as part of changing output properties.
But if 1 is used, the property blob is created within kernel, and RandR
is unaware of the new blob_id. To update it, we need to ask kernel about it.
--- continue with rest of message ---
>
>> Therefore, add a function to update user CRTC properties by querying DRM,
>> and call it whenever legacy gamma is changed.
>
> Note that drmmode_crtc_gamma_do_set is called from
> drmmode_set_mode_major, i.e. on every modeset or under some
> circumstances when a DRI3 client stops page flipping.
>
The property will have to be updated each time the legacy set gamma
ioctl is called, since a new blob (with a new blob_id) is created each time.
Not sure if this is a good idea, but perhaps we can have a flag that
explicitly enable one or the other, depending on user preference? A
user-only property with something like:
0: Use legacy gamma, calls to change non-legacy properties are ignored.
1: Use non-legacy, calls to legacy gamma will be ignored.
On 0, we can remove/disable all non-legacy properties from the property
list, and avoid having to update them. On 1, we'll enable the
properties, and won't have to update them either since legacy gamma is
"disabled". It has the added benefit of avoiding unexpected legacy gamma
sets when using non-legacy, and vice versa.
>
>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>> index 1966fd2..45457c4 100644
>> --- a/src/drmmode_display.c
>> +++ b/src/drmmode_display.c
>> @@ -61,8 +61,13 @@
>>
>> #define DEFAULT_NOMINAL_FRAME_RATE 60
>>
>> +/* Forward declarations */
>> +
>> static Bool drmmode_xf86crtc_resize(ScrnInfoPtr scrn, int width, int height);
>>
>> +static void drmmode_crtc_update_resources(xf86CrtcPtr crtc);
>
> Can you move the drmmode_crtc_update_resources such that the forward
> declaration isn't necessary?
>
Seems possible. It uses the rr_configure_and_change helper, so I'll pull
both of them up.
>
>> static Bool
>> AMDGPUZaphodStringMatches(ScrnInfoPtr pScrn, const char *s, char *output_name)
>> {
>> @@ -768,6 +773,7 @@ drmmode_crtc_gamma_do_set(xf86CrtcPtr crtc, uint16_t *red, uint16_t *green,
>>
>> drmModeCrtcSetGamma(pAMDGPUEnt->fd, drmmode_crtc->mode_crtc->crtc_id,
>> size, red, green, blue);
>> + drmmode_crtc_update_resources(crtc);
>> }
>>
>> Bool
>> @@ -1653,10 +1659,15 @@ static Bool drmmode_property_ignore(drmModePropertyPtr prop)
>> * Configure and change the given output property through randr. Currently
>> * ignores DRM_MODE_PROP_ENU property types. Used as part of create_resources.
>> *
>> +* @output: The output to configure and change the property on.
>> +* @pmode_prop: The driver-private property object.
>
> These two should have been added in patch 1.
Yep, will move.
Leo
>
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-04-10 18:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-26 20:00 [PATCH xf86-video-amdgpu 0/5] Implementing non-legacy color management sunpeng.li-5C7GfCeVMHo
[not found] ` <1522094418-9102-1-git-send-email-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2018-03-26 20:00 ` [PATCH xf86-video-amdgpu 1/5] Add functions for changing CRTC color management properties sunpeng.li-5C7GfCeVMHo
[not found] ` <1522094418-9102-2-git-send-email-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2018-04-09 15:03 ` Michel Dänzer
[not found] ` <0f5652b1-82af-23a2-969e-0e47844fef28-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-10 18:02 ` Leo Li
[not found] ` <25c493fd-dfa3-1549-6d7c-30790d48acae-5C7GfCeVMHo@public.gmane.org>
2018-04-11 8:39 ` Michel Dänzer
[not found] ` <90b36645-a08a-b36d-2e76-64ad9709b1a8-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-11 21:26 ` Leo Li
2018-03-26 20:00 ` [PATCH xf86-video-amdgpu 2/5] Hook up CRTC color management functions sunpeng.li-5C7GfCeVMHo
[not found] ` <1522094418-9102-3-git-send-email-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2018-04-09 15:03 ` Michel Dänzer
[not found] ` <01457540-fbc7-b608-4aee-5df18f7a7dde-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-10 18:02 ` Leo Li
[not found] ` <8994afe3-812f-432f-27ef-ab5db3513d15-5C7GfCeVMHo@public.gmane.org>
2018-04-11 8:48 ` Michel Dänzer
[not found] ` <ce29def3-b0f5-3c4a-cd3f-ca3c61770f81-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-11 21:26 ` Leo Li
2018-03-26 20:00 ` [PATCH xf86-video-amdgpu 3/5] Keep CRTC properties consistent sunpeng.li-5C7GfCeVMHo
[not found] ` <1522094418-9102-4-git-send-email-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2018-04-09 15:03 ` Michel Dänzer
[not found] ` <2fbbae9b-c874-7187-9b69-0a929dcaf5cf-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-10 18:02 ` Leo Li [this message]
[not found] ` <0b884ad3-c193-9eab-ca93-ff0ca0672f1e-5C7GfCeVMHo@public.gmane.org>
2018-04-11 8:39 ` Michel Dänzer
[not found] ` <4cd3224e-fd14-e66f-56bf-b983b8f74bc8-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-11 21:26 ` Leo Li
[not found] ` <78b780f2-d075-9496-e62a-8f6de989b992-5C7GfCeVMHo@public.gmane.org>
2018-04-12 10:30 ` Michel Dänzer
[not found] ` <cc580a31-0679-5492-afff-2ff683ca975d-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-12 16:48 ` Leo Li
[not found] ` <f915a0db-4756-91de-e9dd-336da66060e6-5C7GfCeVMHo@public.gmane.org>
2018-04-13 9:12 ` Michel Dänzer
2018-03-26 20:00 ` [PATCH xf86-video-amdgpu 4/5] Enable configure & change helper to handle enums sunpeng.li-5C7GfCeVMHo
[not found] ` <1522094418-9102-5-git-send-email-sunpeng.li-5C7GfCeVMHo@public.gmane.org>
2018-04-09 15:03 ` Michel Dänzer
2018-03-26 20:00 ` [PATCH xf86-video-amdgpu 5/5] Modify output_create_resources to use configure & change helper sunpeng.li-5C7GfCeVMHo
2018-04-09 14:10 ` [PATCH xf86-video-amdgpu 0/5] Implementing non-legacy color management Michel Dänzer
[not found] ` <53e9ea09-8b20-70fd-b7ef-c0219d46bdcc-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-10 18:02 ` Leo Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b884ad3-c193-9eab-ca93-ff0ca0672f1e@amd.com \
--to=sunpeng.li-5c7gfcevmho@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox