вт, 8 апр. 2025 г., 10:59 Pekka Paalanen <pekka.paala...@haloniitty.fi>:
> On Mon, 7 Apr 2025 18:31:17 +0300 > Andrew Randrianasulu <randrianas...@gmail.com> wrote: > > > пн, 7 апр. 2025 г., 17:18 Pekka Paalanen <pekka.paala...@haloniitty.fi>: > > > > > On Mon, 7 Apr 2025 14:44:25 +0300 > > > Andrew Randrianasulu <randrianas...@gmail.com> wrote: > > > > > > > пн, 7 апр. 2025 г., 14:19 Pekka Paalanen < > pekka.paala...@haloniitty.fi>: > > > > > > > > > On Fri, 4 Apr 2025 22:14:10 +0300 > > > > > Andrew Randrianasulu <randrianas...@gmail.com> 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 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 > > > > >
