<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">вт, 8 апр. 2025 г., 10:59 Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi">pekka.paalanen@haloniitty.fi</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 7 Apr 2025 18:31:17 +0300<br>
Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>> wrote:<br>
<br>
> пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi" target="_blank" rel="noreferrer">pekka.paalanen@haloniitty.fi</a>>:<br>
> <br>
> > On Mon, 7 Apr 2025 14:44:25 +0300<br>
> > Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>> wrote:<br>
> >  <br>
> > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen <<a href="mailto:pekka.paalanen@haloniitty.fi" target="_blank" rel="noreferrer">pekka.paalanen@haloniitty.fi</a>>:<br>
> > >  <br>
> > > > On Fri, 4 Apr 2025 22:14:10 +0300<br>
> > > > Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank" rel="noreferrer">randrianasulu@gmail.com</a>> wrote:<br>
> > > >  <br>
> > > > > пт, 4 апр. 2025 г., 21:35 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" target="_blank" rel="noreferrer">gamberucci.andrea@gmail.com</a>>:<br>
> > > > >  <br>
> ><br>
> > ...<br>
> >  <br>
> > > > > > A theoretical question: can CinGG be adapted to work in Wayland or  <br>
> > is  <br>
> > > > > > it impossible? Has XWayland limitation?  <br>
> > > ><br>
> > > > X11 and Wayland designs for color management are fundamentally<br>
> > > > incompatible.<br>
> > > ><br>
> > > > With X11, applications never tell the display server what kind of<br>
> > > > pixels they are producing or which, if any, color profile they used for<br>
> > > > the display. With Wayland, applications must describe their pixels to<br>
> > > > the display server. Since X11 applications tell nothing to the X  <br>
> > server,  <br>
> > > > Xwayland has no color information to forward to the Wayland compositor.<br>
> > > ><br>
> > > > There can be case-specific manual solutions, though, that rely on<br>
> > > > correctly configuring both the X11 apps and the Wayland compositor. X11<br>
> > > > apps need to be configured to render for a specific display profile,<br>
> > > > and the Wayland compositor needs to assume the X11 windows are rendered<br>
> > > > for the same specific display profile. How that is actually done is up<br>
> > > > for each X11 app and each Wayland compositor.<br>
> > > >  <br>
> > ><br>
> > > Is there possibility for X extension for Xwayland allowing relatively<br>
> > > simple way to tell Xwayland what to do with each window/region?  <br>
> ><br>
> > Hi,<br>
> ><br>
> > sure, but would it not be more useful to invest that effort in a proper<br>
> > Wayland integration?<br>
> >  <br>
> <br>
> Cinelerra-gg like other cinelerra forks uses custom gui library:<br>
> <br>
> <a href="https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD" rel="noreferrer noreferrer" target="_blank">https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=tree;f=cinelerra-5.1/guicast;h=0c7946e891c758f1b4df89c8459cbac926bf4b3b;hb=HEAD</a><br>
> <br>
> I have no idea how much effort will be needed to add Wayland to it.<br>
> <br>
> We lost our main/only developer nearly 5 years ago, so all I can do is<br>
> fixing minor bugs and trying to catch up with ffmpeg API changes.<br>
> <br>
> So, we are on look out for c++ developer who is not afraid of "legacy" and<br>
> will not try to 'refactor' it on first sight (efforts to refactor cinelerra<br>
> proved to be LONG at best and unworkable at worst).<br>
> <br>
> I do not have HDR capable GPU/Monitor, and things most likely will remain<br>
> so in foreseeable future (I am officially invalid, so my income sources are<br>
> limited, and VERY limited by USA standarts. )<br>
> <br>
> Even if cinelerra(-gg) might never rise up to prominent position in<br>
> Linux/*bsd world again - I still consider us useful as example of working<br>
> NLE with internal 32fp pipeline, hw decoding, some OpenGL integration.<br>
> <br>
> So, if only more developers were not afraid to experiment with 'legacy<br>
> '..... After all, retrocomputing is a thing now!<br>
> <br>
<br>
Sorry to hear, I wish you and the project all the best.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thanks ....</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> > X11 is fundamentally limited to max 32-bit pixels so its stuck at 30<br>
> > bpc max with only 2 bits of alpha. That's probably the only thing that<br>
> > cannot be worked around.<br>
> >  <br>
> <br>
> <br>
> I am not sure we need alpha over video region on final output .... right<br>
> now x11/x11 opengl outputs definitely live without. If linux DRM can<br>
> transmit 12bit hdmi/DP - may be this functionality can be implemented as<br>
> separate output module? I looked into how psychtoolbox implement HDR<br>
> rendering .. very funny, a bit like using Vulkan to put output in HDR mode<br>
> and doing framebuffer blit manually in shaders ....<br>
<br>
Linux DRM KMS is not inherently limiting bit depth, it all depends on<br>
the hardware and the driver. E.g. a driver can support a framebuffer<br>
with half-float RGB (16 bpc) or 16 bpc integer or 32-bit float,<br>
whatever anyone desires. Adding new formats to a list is easy, it's all<br>
about what the hardware and HDMI, DisplayPort etc. can do.<br>
<br>
I'm not aware of how psychtoolbox works, but I guess it needs complete<br>
control over an output for scientific experiments. One way to do that<br>
is to use DRM leasing.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">yes, this is how I come to discover that  this probably strictly scientific project grow some HDR player ;)</div><div dir="auto"><br></div><div dir="auto"><a href="http://psychtoolbox.org/docs/PsychHDR">http://psychtoolbox.org/docs/PsychHDR</a></div><div dir="auto"><br></div><div dir="auto">also link at the bottom of page to source file.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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 ....</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It appears that Xwayland has support for DRM leasing, so X11 apps can<br>
lease a KMS CRTC and a KMS connector from a willing Wayland compositor.<br>
The advantage is that the app gets complete, direct access to the<br>
display device and monitor, unobstructed by the window system. The<br>
disadvantage is that the same monitor disappears from the rest of the<br>
desktop environment, and you have to use the KMS UAPI to drive it - IOW<br>
without a window system to lean on. I'm not sure what EGL nor Vulkan<br>
offers to make that easier.<br>
<br>
The monitor disappearing from the rest of the desktop environment is<br>
absolute, including input delivery. The user cannot move the mouse<br>
pointer to the leased monitor. This means you need either some<br>
input means outside of the desktop environment, or you need a regular<br>
window on another monitor for controls.<br>
<br>
The primary use case for DRM leasing is head-mounted displays for<br>
virtual reality. DRM leasing might be a good way to drive a separate<br>
mastering display.<br>
<br>
<br>
Thanks,<br>
pq<br>
<br>
> > > A bit like<br>
> > ><br>
> > >  <br>
> > <a href="https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h" rel="noreferrer noreferrer" target="_blank">https://github.com/oyranos-cms/oyranos/blob/master/libxcm/include/X11/Xcm/Xcm.h</a><br>
> ><br>
> > That's an interesting one, I wasn't aware of this. I have to take some<br>
> > statements back.<br>
> ><br>
> > So this is communicating ICC profiles and associated window regions to<br>
> > an X11 compositing manager. If a profile covers the whole window, this<br>
> > should be relatively easy to hook up in a Wayland compositor's XWM<br>
> > (embedded X11 window manager).<br>
> ><br>
> > Being limited to ICC profiles is a hindrance for HDR, although the CICP<br>
> > extension for ICC does exist. Unfortunately CICP does not carry<br>
> > everything we have in the Wayland color-management protocol extension.<br>
> > Most notably, it misses the reference white level which would be<br>
> > necessary[1].<br>
> >  <br>
> <br>
> <br>
> Somewhere there also was cinepaint fork (unrelated to cinelerra) that also<br>
> can be used for testing this functionality.<br>
> <br>
> <br>
> I suspect working with std body behind ICC will be ... challenging, if<br>
> anyone decided to add missing info into standart.<br>
> <br>
> <br>
> ><br>
> > Thanks,<br>
> > pq<br>
> ><br>
> > [1]:<br>
> > <a href="https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-can-be-used-for-HDR-calibration,1" rel="noreferrer noreferrer" target="_blank">https://www.freelists.org/post/argyllcms/Standard-spec-for-ICC-file-that-can-be-used-for-HDR-calibration,1</a><br>
> >  <br>
<br>
</blockquote></div></div></div>