Re: [Cin] "Competitors" or do we want to stay alive?
On Mon, 7 Apr 2025 18:31:17 +0300 Andrew Randrianasulu wrote: > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen : > > > On Mon, 7 Apr 2025 14:44:25 +0300 > > Andrew Randrianasulu wrote: > > > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen : > > > > > > > On Fri, 4 Apr 2025 22:14:10 +0300 > > > > Andrew Randrianasulu wrote: > > > > > > > > > пт, 4 апр. 2025 г., 21:35 Andrea paz : > > > > > > > > > ... > > > > > > > > A theoretical question: can CinGG be adapted to work in Wayland or > > is > > > > > > it impossible? Has XWayland limitation? > > > > > > > > X11 and Wayland designs for color management are fundamentally > > > > incompatible. > > > > > > > > With X11, applications never tell the display server what kind of > > > > pixels they are producing or which, if any, color profile they used for > > > > the display. With Wayland, applications must describe their pixels to > > > > the display server. Since X11 applications tell nothing to the X > > server, > > > > Xwayland has no color information to forward to the Wayland compositor. > > > > > > > > There can be case-specific manual solutions, though, that rely on > > > > correctly configuring both the X11 apps and the Wayland compositor. X11 > > > > apps need to be configured to render for a specific display profile, > > > > and the Wayland compositor needs to assume the X11 windows are rendered > > > > for the same specific display profile. How that is actually done is up > > > > for each X11 app and each Wayland compositor. > > > > > > > > > > Is there possibility for X extension for Xwayland allowing relatively > > > simple way to tell Xwayland what to do with each window/region? > > > > Hi, > > > > sure, but would it not be more useful to invest that effort in a proper > > Wayland integration? > > > > Cinelerra-gg like other cinelerra forks uses custom gui library: > > https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD > > I have no idea how much effort will be needed to add Wayland to it. > > We lost our main/only developer nearly 5 years ago, so all I can do is > fixing minor bugs and trying to catch up with ffmpeg API changes. > > So, we are on look out for c++ developer who is not afraid of "legacy" and > will not try to 'refactor' it on first sight (efforts to refactor cinelerra > proved to be LONG at best and unworkable at worst). > > I do not have HDR capable GPU/Monitor, and things most likely will remain > so in foreseeable future (I am officially invalid, so my income sources are > limited, and VERY limited by USA standarts. ) > > Even if cinelerra(-gg) might never rise up to prominent position in > Linux/*bsd world again - I still consider us useful as example of working > NLE with internal 32fp pipeline, hw decoding, some OpenGL integration. > > So, if only more developers were not afraid to experiment with 'legacy > '. After all, retrocomputing is a thing now! > Sorry to hear, I wish you and the project all the best. > > X11 is fundamentally limited to max 32-bit pixels so its stuck at 30 > > bpc max with only 2 bits of alpha. That's probably the only thing that > > cannot be worked around. > > > > > I am not sure we need alpha over video region on final output right > now x11/x11 opengl outputs definitely live without. If linux DRM can > transmit 12bit hdmi/DP - may be this functionality can be implemented as > separate output module? I looked into how psychtoolbox implement HDR > rendering .. very funny, a bit like using Vulkan to put output in HDR mode > and doing framebuffer blit manually in shaders Linux DRM KMS is not inherently limiting bit depth, it all depends on the hardware and the driver. E.g. a driver can support a framebuffer with half-float RGB (16 bpc) or 16 bpc integer or 32-bit float, whatever anyone desires. Adding new formats to a list is easy, it's all about what the hardware and HDMI, DisplayPort etc. can do. I'm not aware of how psychtoolbox works, but I guess it needs complete control over an output for scientific experiments. One way to do that is to use DRM leasing. It appears that Xwayland has support for DRM leasing, so X11 apps can lease a KMS CRTC and a KMS connector from a willing Wayland compositor. The advantage is that the app gets complete, direct access to the display device and monitor, unobstructed by the window system. The disadvantage is that the same monitor disappears from the rest of the desktop environment, and you have to use the KMS UAPI to drive it - IOW without a window system to lean on. I'm not sure what EGL nor Vulkan offers to make that easier. The monitor disappearing from the rest of the desktop environment is absolute, including input delivery. The user cannot move the mouse pointer to the leased monitor. This means you need either some input means outside of the desktop environment, or you need a regular window on another monitor for contr
Re: [Cin] "Competitors" or do we want to stay alive?
вт, 8 апр. 2025 г., 10:59 Pekka Paalanen : > On Mon, 7 Apr 2025 18:31:17 +0300 > Andrew Randrianasulu wrote: > > > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen : > > > > > On Mon, 7 Apr 2025 14:44:25 +0300 > > > Andrew Randrianasulu wrote: > > > > > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen < > pekka.paala...@haloniitty.fi>: > > > > > > > > > On Fri, 4 Apr 2025 22:14:10 +0300 > > > > > Andrew Randrianasulu wrote: > > > > > > > > > > > пт, 4 апр. 2025 г., 21:35 Andrea paz < > gamberucci.and...@gmail.com>: > > > > > > > > > > > > ... > > > > > > > > > > A theoretical question: can CinGG be adapted to work in > Wayland or > > > is > > > > > > > it impossible? Has XWayland limitation? > > > > > > > > > > X11 and Wayland designs for color management are fundamentally > > > > > incompatible. > > > > > > > > > > With X11, applications never tell the display server what kind of > > > > > pixels they are producing or which, if any, color profile they > used for > > > > > the display. With Wayland, applications must describe their pixels > to > > > > > the display server. Since X11 applications tell nothing to the X > > > server, > > > > > Xwayland has no color information to forward to the Wayland > compositor. > > > > > > > > > > There can be case-specific manual solutions, though, that rely on > > > > > correctly configuring both the X11 apps and the Wayland > compositor. X11 > > > > > apps need to be configured to render for a specific display > profile, > > > > > and the Wayland compositor needs to assume the X11 windows are > rendered > > > > > for the same specific display profile. How that is actually done > is up > > > > > for each X11 app and each Wayland compositor. > > > > > > > > > > > > > Is there possibility for X extension for Xwayland allowing relatively > > > > simple way to tell Xwayland what to do with each window/region? > > > > > > Hi, > > > > > > sure, but would it not be more useful to invest that effort in a proper > > > Wayland integration? > > > > > > > Cinelerra-gg like other cinelerra forks uses custom gui library: > > > > > https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD > > > > I have no idea how much effort will be needed to add Wayland to it. > > > > We lost our main/only developer nearly 5 years ago, so all I can do is > > fixing minor bugs and trying to catch up with ffmpeg API changes. > > > > So, we are on look out for c++ developer who is not afraid of "legacy" > and > > will not try to 'refactor' it on first sight (efforts to refactor > cinelerra > > proved to be LONG at best and unworkable at worst). > > > > I do not have HDR capable GPU/Monitor, and things most likely will remain > > so in foreseeable future (I am officially invalid, so my income sources > are > > limited, and VERY limited by USA standarts. ) > > > > Even if cinelerra(-gg) might never rise up to prominent position in > > Linux/*bsd world again - I still consider us useful as example of working > > NLE with internal 32fp pipeline, hw decoding, some OpenGL integration. > > > > So, if only more developers were not afraid to experiment with 'legacy > > '. After all, retrocomputing is a thing now! > > > > Sorry to hear, I wish you and the project all the best. > Thanks > > > > X11 is fundamentally limited to max 32-bit pixels so its stuck at 30 > > > bpc max with only 2 bits of alpha. That's probably the only thing that > > > cannot be worked around. > > > > > > > > > I am not sure we need alpha over video region on final output right > > now x11/x11 opengl outputs definitely live without. If linux DRM can > > transmit 12bit hdmi/DP - may be this functionality can be implemented as > > separate output module? I looked into how psychtoolbox implement HDR > > rendering .. very funny, a bit like using Vulkan to put output in HDR > mode > > and doing framebuffer blit manually in shaders > > Linux DRM KMS is not inherently limiting bit depth, it all depends on > the hardware and the driver. E.g. a driver can support a framebuffer > with half-float RGB (16 bpc) or 16 bpc integer or 32-bit float, > whatever anyone desires. Adding new formats to a list is easy, it's all > about what the hardware and HDMI, DisplayPort etc. can do. > > I'm not aware of how psychtoolbox works, but I guess it needs complete > control over an output for scientific experiments. One way to do that > is to use DRM leasing. > yes, this is how I come to discover that this probably strictly scientific project grow some HDR player ;) http://psychtoolbox.org/docs/PsychHDR also link at the bottom of page to source file. I am not sure radv supported all required extensions last time I looked at it. Andrea does have AMD card but "only" wide-gamut monitor. May be some kind of measurement overlay exist in .. mangohud or something? To see pixel and metadata values even w/o HDR monitor > It appears that Xwayland has support f
Re: [PATCH V8 06/43] drm/colorop: Add 1D Curve subtype
Hi there,
On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> wrote:
> > 'plane' seems really incongruous here. The colorop can be created for
> > any number of planes, but we're setting it to always be bound to a
> > single plane at init, and that can only be changed later.
>
> I don't think the current design allows a single colorop to be re-used
> between planes? I think as-is, drivers create one set of colorops per
> plane and never share them between different planes?
OK, Harry's reply cleared that up perfectly - the flexibility that's
there at the moment is about being able to reuse colorops for CRTCs in
post-blend ops (great!), not shared between planes.
> > 1. Is it guaranteed that, if any plane on a device supports the
> > COLOR_PIPELINE property, all planes will support COLOR_PIPELINE?
> > (Given the amdgpu cursor-plane discussion, it looks like no, which is
> > unfortunate but oh well.)
>
> I don't think so. (They could all expose a COLOR_PIPELINE with the only
> choice as the zero bypass pipeline, but that sounds silly.)
Works for me: so any planes could not have colour pipelines, and the
result would be undefined (well, less defined) colour.
> > 2. Is it guaranteed that, if a COLOR_PIPELINE property exists on a
> > plane, that BYPASS will be one of the supported values? (The current
> > implementation does this, which seems sensible, but if the plan is to
> > not make this a uAPI invariant, e.g. to support planes with mandatory
> > CM steps, this should probably be explicitly documented.)
>
> Yes. This is a hard requirement, mentioned in the design doc IIRC.
Nice. I guess that's kind of implicit given pre-colorop behaviour
expectations. We'd probably need a client cap analogous to universal
planes to expose planes with mandatory colorop steps. This should
probably be enforced with igt.
> > 3. Can a given color pipeline potentially be used on different planes,
> > i.e. a colorop used to represent a separate hardware processing block
> > which may be used on any plane but only one plane at a time? (This
> > should be documented either way, and if they are unique per plane, igt
> > should enforce this.)
>
> Right now, I don't think so. Could be a future extension I suppose, but
> I think we need to properly sit down and think about all of the possible
> consequences. Maybe using the same pipeline ID isn't the best uAPI here.
I'm with you on this. I think if we were trying to express a single
color-transformation block which was shared between multiple planes
(MTK is probably the closest to this conceptually from what I've
seen), having an immutable COLOR_PIPELINE_SHARED = { ids... } property
would be the best way to achieve this.
> > 3. Can a given color pipeline be active on multiple planes at a time?
> > (If so, the implementation definitely needs rethinking: the colorop
> > would need to have a list of planes.)
>
> I don't think so.
Great. But probably needs igt.
> > 4. Can a given color pipeline be active on multiple planes on multiple
> > CRTCs at a time?
>
> Ditto.
Ditto.
> > 5. For a given colorop property, is it an invariant that the colorop
> > will only appear in one color pipeline at a time? (I believe so, but
> > this probably needs documenting and/or igt.)
>
> I don't really understand why that would matter to user-space.
Plane A: COLOR_PIPELINE@123 = { 1D_CURVE@456 }
Plane B: COLOR_PIPELINE@789 = { 1D_CURVE@456 }
If userspace wasn't defensive about this, it would program the curve
for 456 twice, and unless they were the same you'd get undesirable
results.
The existing implementation is fine here, I think it just needs better
igt to codify the expectations we all have.
> > Either way, I suspect that clorop->plane is the wrong thing to do, and
> > that it maybe wants to be a list of planes in the drm_colorop_state?
>
> I don't think so, for a given plane, there can only be a single pipeline
> active at a time.
Yeah, again that was just not having grasped that the colorop not
being derived from the plane was actually about allowing for it to be
attached to a single CRTC instead, rather than potentially multiple
planes. I have no concerns around this.
As it stands, I've gone through the implementation pretty thoroughly,
as well as our use of it in Weston. I'm happy with how it looks for
pre-blend, and I'm even happier that the implementation is written to
apply easily to apply to post-blend CRTC pipelines.
With the suggested uAPI doc fixes and igt additions, this series is:
Reviewed-by: Daniel Stone
Thanks everyone for the immense amount of work that's gone into this. :)
Cheers,
Daniel
[ANNOUNCE] wayland-protocols 1.43
wayland-protocols 1.43 is now available. This release adds a new protocol - toplevel tags - which enables clients to tag toplevels in a script friendly way. This release also adds toplevel edge constraints to xdg-shell, which enables compositors to let clients know in what ways window edges are constrained, e.g. whether they can resize or not. For a complete log, including bug fixes, see the short log below. Jonas Ådahl (2): xdg-shell: Add edge constraints build: Bump version to 1.43 Simon Ser (1): color-management-v1: fix typo in feature.windows_scrgb Xaver Hugl (2): meson: sort protocols alphabetically staging: add toplevel tag protocol git tag: 1.43 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.43/downloads/wayland-protocols-1.43.tar.xz SHA256: ba3c3425dd27c57b5291e93dba97be12479601e00bcab24d26471948cb643653 wayland-protocols-1.43.tar.xz SHA512: e568ef57d169235426044c1dcffe1e55daaa0ac6071e72e20e50f509d7d506a01fb49a394954308d5e8d329482e74d0d0a326f11e1c8b4c628453db2adea7274 wayland-protocols-1.43.tar.xz PGP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/releases/1.43/downloads/wayland-protocols-1.43.tar.xz.sig signature.asc Description: PGP signature
Re: [PATCH V8 06/43] drm/colorop: Add 1D Curve subtype
On 2025-04-08 12:40, Daniel Stone wrote:
> Hi there,
>
> On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
>> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
>> wrote:
>>> 'plane' seems really incongruous here. The colorop can be created for
>>> any number of planes, but we're setting it to always be bound to a
>>> single plane at init, and that can only be changed later.
>>
>> I don't think the current design allows a single colorop to be re-used
>> between planes? I think as-is, drivers create one set of colorops per
>> plane and never share them between different planes?
>
> OK, Harry's reply cleared that up perfectly - the flexibility that's
> there at the moment is about being able to reuse colorops for CRTCs in
> post-blend ops (great!), not shared between planes.
>
Just to make sure we're talking about the same thing:
The design intent is to allow drm_colorops on a crtc (once we implement
that), not to be able to share the same drm_colorop between a plane and
crtc.
>>> 1. Is it guaranteed that, if any plane on a device supports the
>>> COLOR_PIPELINE property, all planes will support COLOR_PIPELINE?
>>> (Given the amdgpu cursor-plane discussion, it looks like no, which is
>>> unfortunate but oh well.)
>>
>> I don't think so. (They could all expose a COLOR_PIPELINE with the only
>> choice as the zero bypass pipeline, but that sounds silly.)
>
> Works for me: so any planes could not have colour pipelines, and the
> result would be undefined (well, less defined) colour.
Yes, basically it would be what we have now (without color pipelines).
>
>>> 2. Is it guaranteed that, if a COLOR_PIPELINE property exists on a
>>> plane, that BYPASS will be one of the supported values? (The current
>>> implementation does this, which seems sensible, but if the plan is to
>>> not make this a uAPI invariant, e.g. to support planes with mandatory
>>> CM steps, this should probably be explicitly documented.)
>>
>> Yes. This is a hard requirement, mentioned in the design doc IIRC.
>
> Nice. I guess that's kind of implicit given pre-colorop behaviour
> expectations. We'd probably need a client cap analogous to universal
> planes to expose planes with mandatory colorop steps. This should
> probably be enforced with igt.
>
Yes.
The API allows for the option of non-bypassable individual
colorops, but the pipeline as a whole must support bypass
currently.
>>> 3. Can a given color pipeline potentially be used on different planes,
>>> i.e. a colorop used to represent a separate hardware processing block
>>> which may be used on any plane but only one plane at a time? (This
>>> should be documented either way, and if they are unique per plane, igt
>>> should enforce this.)
>>
>> Right now, I don't think so. Could be a future extension I suppose, but
>> I think we need to properly sit down and think about all of the possible
>> consequences. Maybe using the same pipeline ID isn't the best uAPI here.
>
> I'm with you on this. I think if we were trying to express a single
> color-transformation block which was shared between multiple planes
> (MTK is probably the closest to this conceptually from what I've
> seen), having an immutable COLOR_PIPELINE_SHARED = { ids... } property
> would be the best way to achieve this.
>
>>> 3. Can a given color pipeline be active on multiple planes at a time?
>>> (If so, the implementation definitely needs rethinking: the colorop
>>> would need to have a list of planes.)
>>
>> I don't think so.
>
> Great. But probably needs igt.
>
Right, otherwise a driver dev might implement colorops in a way that
breaks this. Though, if DRM helpers are used it should be fairly safe,
I would think.
>>> 4. Can a given color pipeline be active on multiple planes on multiple
>>> CRTCs at a time?
>>
>> Ditto.
>
> Ditto.
>
>>> 5. For a given colorop property, is it an invariant that the colorop
>>> will only appear in one color pipeline at a time? (I believe so, but
>>> this probably needs documenting and/or igt.)
>>
>> I don't really understand why that would matter to user-space.
>
> Plane A: COLOR_PIPELINE@123 = { 1D_CURVE@456 }
> Plane B: COLOR_PIPELINE@789 = { 1D_CURVE@456 }
>
Yeah, a simple IGT test that parses all color pipelines and checks
that colorops don't occur in multiple pipelines is needed.
> If userspace wasn't defensive about this, it would program the curve
> for 456 twice, and unless they were the same you'd get undesirable
> results.
>
> The existing implementation is fine here, I think it just needs better
> igt to codify the expectations we all have.
>
>>> Either way, I suspect that clorop->plane is the wrong thing to do, and
>>> that it maybe wants to be a list of planes in the drm_colorop_state?
>>
>> I don't think so, for a given plane, there can only be a single pipeline
>> active at a time.
>
> Yeah, again that was just not having grasped that the colorop not
> being derived from the plane was actually about allowing for it to be
> attached to a single CRTC in
