Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On Fri, 20 Oct 2023 11:23:28 -0400 Harry Wentland wrote: > On 2023-10-20 10:57, Pekka Paalanen wrote: > > On Fri, 20 Oct 2023 16:22:56 +0200 > > Sebastian Wick wrote: > > > >> Thanks for continuing to work on this! > >> > >> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote: > >>> v2: > >>> - Update colorop visualizations to match reality (Sebastian, Alex Hung) > >>> - Updated wording (Pekka) > >>> - Change BYPASS wording to make it non-mandatory (Sebastian) > >>> - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property > >>>section (Pekka) > >>> - Use PQ EOTF instead of its inverse in Pipeline Programming example > >>> (Melissa) > >>> - Add "Driver Implementer's Guide" section (Pekka) > >>> - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) > >>> > > > > ... > > > >>> +Driver Forward/Backward Compatibility > >>> += > >>> + > >>> +As this is uAPI drivers can't regress color pipelines that have been > >>> +introduced for a given HW generation. New HW generations are free to > >>> +abandon color pipelines advertised for previous generations. > >>> +Nevertheless, it can be beneficial to carry support for existing color > >>> +pipelines forward as those will likely already have support in DRM > >>> +clients. > >>> + > >>> +Introducing new colorops to a pipeline is fine, as long as they can be > >>> +disabled or are purely informational. DRM clients implementing support > >>> +for the pipeline can always skip unknown properties as long as they can > >>> +be confident that doing so will not cause unexpected results. > >>> + > >>> +If a new colorop doesn't fall into one of the above categories > >>> +(bypassable or informational) the modified pipeline would be unusable > >>> +for user space. In this case a new pipeline should be defined. > >> > >> How can user space detect an informational element? Should we just add a > >> BYPASS property to informational elements, make it read only and set to > >> true maybe? Or something more descriptive? > > > > Read-only BYPASS set to true would be fine by me, I guess. > > > > Don't you mean set to false? An informational element will always do > something, so it can't be bypassed. Yeah, this is why we need a definition. I understand "informational" to not change pixel values in any way. Previously I had some weird idea that scaling doesn't alter color, but of course it may. > > I think we also need a definition of "informational". > > > > Counter-example 1: a colorop that represents a non-configurable > > Not sure what's "counter" for these examples? > > > YUV<->RGB conversion. Maybe it determines its operation from FB pixel > > format. It cannot be set to bypass, it cannot be configured, and it > > will alter color values. > > > > Counter-example 2: image size scaling colorop. It might not be > > configurable, it is controlled by the plane CRTC_* and SRC_* > > properties. You still need to understand what it does, so you can > > arrange the scaling to work correctly. (Do not want to scale an image > > with PQ-encoded values as Josh demonstrated in XDC.) > > > > IMO the position of the scaling operation is the thing that's important > here as the color pipeline won't define scaling properties. > > > Counter-example 3: image sampling colorop. Averages FB originated color > > values to produce a color sample. Again do not want to do this with > > PQ-encoded values. > > > > Wouldn't this only happen during a scaling op? There is certainly some overlap between examples 2 and 3. IIRC SRC_X/Y coordinates can be fractional, which makes nearest vs. bilinear sampling have a difference even if there is no scaling. There is also the question of chroma siting with sub-sampled YUV. I don't know how that actually works, or how it theoretically should work. Thanks, pq pgpoV0LM7zwTn.pgp Description: OpenPGP digital signature
Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set
On Tuesday, October 17th, 2023 at 14:10, Ville Syrjälä wrote: > On Mon, Oct 16, 2023 at 10:00:51PM +, Simon Ser wrote: > > > On Monday, October 16th, 2023 at 17:10, Ville Syrjälä > > ville.syrj...@linux.intel.com wrote: > > > > > On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote: > > > > > > > On Mon, 16 Oct 2023 15:42:16 +0200 > > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > > > Hi Pekka, > > > > > > > > > > On 10/16/23 14:18, Pekka Paalanen wrote: > > > > > > > > > > > On Mon, 16 Oct 2023 12:52:32 +0200 > > > > > > André Almeida andrealm...@igalia.com wrote: > > > > > > > > > > > > > Hi Michel, > > > > > > > > > > > > > > On 8/17/23 12:37, Michel Dänzer wrote: > > > > > > > > > > > > > > > On 8/15/23 20:57, André Almeida wrote: > > > > > > > > > > > > > > > > > From: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > > > > > > > > > > Specify how the atomic state is maintained between userspace > > > > > > > > > and > > > > > > > > > kernel, plus the special case for async flips. > > > > > > > > > > > > > > > > > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com > > > > > > > > > Signed-off-by: André Almeida andrealm...@igalia.com > > > > > > > > > [...] > > > > > > > > > > > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is > > > > > > > > > allowed to > > > > > > > > > +effectively change only the FB_ID property on any planes. > > > > > > > > > No-operation changes > > > > > > > > > +are ignored as always. [...] > > > > > > > > > During the hackfest in Brno, it was mentioned that a commit > > > > > > > > > which re-sets the same FB_ID could actually have an effect > > > > > > > > > with VRR: It could trigger scanout of the next frame before > > > > > > > > > vertical blank has reached its maximum duration. Some kind of > > > > > > > > > mechanism is required for this in order to allow user space > > > > > > > > > to perform low frame rate compensation. > > > > > > > > > > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR > > > > > > > monitor > > > > > > > and it worked as expected, so this shouldn't be a concern. > > > > > > > Right, so it must have some effect. It cannot be simply ignored > > > > > > > like in > > > > > > > the proposed doc wording. Do we special-case re-setting the same > > > > > > > FB_ID > > > > > > > as "not a no-op" or "not ignored" or some other way? > > > > > > > There's an effect in the refresh rate, the image won't change but > > > > > > > it > > > > > > > will report that a flip had happened asynchronously so the > > > > > > > reported > > > > > > > framerate will be increased. Maybe an additional wording could be > > > > > > > like: > > > > > > > > > > Flipping to the same FB_ID will result in a immediate flip as if it > > > > > was > > > > > changing to a different one, with no effect on the image but effecting > > > > > the reported frame rate. > > > > > > > > Re-setting FB_ID to its current value is a special case regardless of > > > > PAGE_FLIP_ASYNC, is it not? > > > > > > No. The rule has so far been that all side effects are observed > > > even if you flip to the same fb. And that is one of my annoyances > > > with this proposal. The rules will now be different for async flips > > > vs. everything else. > > > > Well with the patches the async page-flip case is exactly the same as > > the non-async page-flip case. In both cases, if a FB_ID is included in > > an atomic commit then the side effects are triggered even if the property > > value didn't change. The rules are the same for everything. > > I see it only checking if FB_ID changes or not. If it doesn't > change then the implication is that the side effects will in > fact be skipped as not all planes may even support async flips. Hm right. So the problem is that setting any prop = same value as previous one will result in a new page-flip for asynchronous page-flips, but will not result in any side-effect for asynchronous page-flips. Does it actually matter though? For async page-flips, I don't think this would result in any actual difference in behavior?
Re: Weston 13 and Weston 12.0.3 release schedule
Hi all, Just a heads-up, we're going to postpone our Beta release for the next week (it should've been today), as to able to fix some issues we've discovered recently, and also give fdo.org time to "recover". Note that all the other dates are also shifted with one week. Thanks! On Mon, Oct 09, 2023 at 07:36:06PM +0300, Marius Vlad wrote: > Hi all, > > Here is the release schedule for Weston 13.0, the next major version: > > - Alpha: October 16, in one week > - Beta: October 23 > - RC1: October 30 > - First possible release: November, 6 > > Package maintainers are encouraged to pick up the pre-releases to make > sure packaging can be tested (and fixed) before the stable release. > > Additionally I'd like to do a Weston 12 bug-fix/point release at the > same time matching our first possible release date. As usual, we have a > dedicated label, 'Backport to Weston 12' if there's something you'd like > to get in for Weston 12, or you can reach out directly. > > Thanks! signature.asc Description: PGP signature
[PATCH] drm/doc: describe PATH format for DP MST
This is already uAPI, xserver parses it. It's useful to document since user-space might want to lookup the parent connector. Additionally, people (me included) have misunderstood the PATH property for being stable across reboots, but since a KMS object ID is baked in there that's not the case. So PATH shouldn't be used as-is in config files and such. Signed-off-by: Simon Ser Cc: Pekka Paalanen Cc: Dmitry Baryshkov Cc: Daniel Vetter --- drivers/gpu/drm/drm_connector.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index c3725086f413..392bec1355a3 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1198,6 +1198,11 @@ static const u32 dp_colorspaces = * drm_connector_set_path_property(), in the case of DP MST with the * path property the MST manager created. Userspace cannot change this * property. + * + * In the case of DP MST, the property has the format + * ``mst:-`` where is the KMS object ID of the + * parent connector and is a hyphen-separated list of DP MST + * port numbers. Note, KMS object IDs are not stable across reboots. * TILE: * Connector tile group property to indicate how a set of DRM connector * compose together into one logical screen. This is used by both high-res -- 2.42.0
Re: [PATCH] drm/doc: describe PATH format for DP MST
On Mon, 23 Oct 2023 at 23:37, Simon Ser wrote: > > This is already uAPI, xserver parses it. It's useful to document > since user-space might want to lookup the parent connector. > > Additionally, people (me included) have misunderstood the PATH > property for being stable across reboots, but since a KMS object > ID is baked in there that's not the case. So PATH shouldn't be > used as-is in config files and such. > > Signed-off-by: Simon Ser > Cc: Pekka Paalanen > Cc: Dmitry Baryshkov > Cc: Daniel Vetter Reviewed-by: Dmitry Baryshkov > --- > drivers/gpu/drm/drm_connector.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index c3725086f413..392bec1355a3 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1198,6 +1198,11 @@ static const u32 dp_colorspaces = > * drm_connector_set_path_property(), in the case of DP MST with the > * path property the MST manager created. Userspace cannot change this > * property. > + * > + * In the case of DP MST, the property has the format > + * ``mst:-`` where is the KMS object ID of > the > + * parent connector and is a hyphen-separated list of DP MST > + * port numbers. Note, KMS object IDs are not stable across reboots. Nit: maybe `... is not guaranteed to be stable...' > * TILE: > * Connector tile group property to indicate how a set of DRM connector > * compose together into one logical screen. This is used by both > high-res > -- > 2.42.0 > > -- With best wishes Dmitry
