[Cin] "Competitors" or do we want to stay alive?

Tue Apr 8 08:14:11 UTC 2025

вт, 8 апр. 2025 г., 10:59 Pekka Paalanen <pekka.paalanen at haloniitty.fi>:

> On Mon, 7 Apr 2025 18:31:17 +0300
> Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
>
> > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paalanen at haloniitty.fi>:
> >
> > > On Mon, 7 Apr 2025 14:44:25 +0300
> > > Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
> > >
> > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <
> pekka.paalanen at haloniitty.fi>:
> > > >
> > > > > On Fri, 4 Apr 2025 22:14:10 +0300
> > > > > Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
> > > > >
> > > > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <
> gamberucci.andrea at 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 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 controls.
>
> The primary use case for DRM leasing is head-mounted displays for
> virtual reality. DRM leasing might be a good way to drive a separate
> mastering display.
>
>
> Thanks,
> pq
>
> > > > A bit like
> > > >
> > > >
> > >
> https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h
> > >
> > > That's an interesting one, I wasn't aware of this. I have to take some
> > > statements back.
> > >
> > > So this is communicating ICC profiles and associated window regions to
> > > an X11 compositing manager. If a profile covers the whole window, this
> > > should be relatively easy to hook up in a Wayland compositor's XWM
> > > (embedded X11 window manager).
> > >
> > > Being limited to ICC profiles is a hindrance for HDR, although the CICP
> > > extension for ICC does exist. Unfortunately CICP does not carry
> > > everything we have in the Wayland color-management protocol extension.
> > > Most notably, it misses the reference white level which would be
> > > necessary[1].
> > >
> >
> >
> > Somewhere there also was cinepaint fork (unrelated to cinelerra) that
> also
> > can be used for testing this functionality.
> >
> >
> > I suspect working with std body behind ICC will be ... challenging, if
> > anyone decided to add missing info into standart.
> >
> >
> > >
> > > Thanks,
> > > pq
> > >
> > > [1]:
> > >
> https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-can-be-used-for-HDR-calibration,1
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250408/0018a10e/attachment-0001.htm>