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

Tue Apr 8 07:58:53 UTC 2025

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.

> > 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 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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250408/235feef1/attachment.sig>