On Fri, 1 Mar 2019 12:47:05 -0700 Chris Murphy <[email protected]> wrote:
> On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen <[email protected]> wrote: > > > > On Thu, 28 Feb 2019 18:28:33 -0700 > > Chris Murphy <[email protected]> wrote: > > > > > I'm curious how legacy applications including games used to manipulate > > > actual hardware LUT in a video card, if the application asked the > > > client to do it, in which case it still could do that? > > > > Hi Chris, > > > > right now, in no case. > > I made a typo. > s/client/kernel > > Or has LUT manipulation only ever been done via X11? Hi Chris, X11 apps have (hopefully) done hardware LUT manipulation only through X11. There was no other way AFAIK, unless the app started essentially hacking the system via root privileges. The current DRM KMS kernel design has always had a "lock" (the DRM master concept) so that if one process (e.g. the X server) is in control of the display, then no other process can touch the display hardware at the same time. Before DRM KMS, the video mode programming was in the Xorg video drivers, so if an app wanted to bypass the X server, it would have had to poke the hardware "directly" bypassing any drivers, which is even more horrible that it might sound. Non-X11 apps, such as fbdev, svgalib, DirectFB, etc., would be something different that I'm not too familiar with. Fbdev was a standard'ish kernel ABI, while the rest more or less poked the hardware directly bypassing any kernel drivers, if not using fbdev under the hood. These I would just ignore, they were running without a window system to begin with. > > > a. I've already done color management, I *really do* need deviceRGB > > > b. display this, its color space is _________. > > > > Case b) is already in both of the protocol proposals. > > > > Case a) is in Niels' proposal, but I raised some issues with that. It is > > a very problematic case to implement in general, too, because the > > compositor is in some cases very likely to have to undo the color > > transformations the application already did to go back to a common > > blending space or to the spaces for other outputs. > > Case a) is a subset of the calibration/characterization application's > requirement. > > Even if it turns out the application tags its content with displayRGB, > thereby in effect getting a null transform, (or a null transform with > whatever quantization happens through 32bpc float intermediate color > image encoding), that's functionally a do not color manage deviceRGB > path. What is "displayRGB"? Does it essentially mean "write these pixel values to any monitor as is"? What if the channel value's data type does not match? I suppose if a compositor receives content with "displayRGB" profile, assuming my guess above is correct, it would have to apply the inverse of the blending space to output space transform first, so that the total result would be a null transform for pixels that were not blended with anything else. > > > Both types of applications exist. It might very well be reasonable to > > > say, yeah we're not going to support use case a.) Such smarter > > > applications are going to have to do their color management however > > > they want internally, and transform to a normalized color space like > > > P3 or Rec.2020 or opRGB and follow use case b.) where they tag all > > > content with that normalized color space. > > > > Right. We'll see. And measurement/calibration/characterisation > > applications are a third category completely different to the two > > above, by window management requirements if nothing else. > > It is fair to keep track of, and distinguish a display path with: > > 1. no calibration and no/null transform; > 2. calibration applied, but no/null transform; > 3. calibration and transform applied. > > The calibration application does need a means of ensuring explicitly > getting each of those. 1, is needed to figure out the uncorrected > state and hopefully give the user some guidance on knob settings via > OSD, and then to take meausurements to compute a corrective curve > typically going in the video card LUT or equivalent wherever else that > would go; 2, is needed to build an ICC profile for the display; and 3, > is needed for verifying the path. > > An application doing color management internally only really needs > path 2. Nevertheless, that app's need is a subset of what's already > needed by an application that does display calibration and profiling. Yes, this is very much why I would prefer measurement/calibration/characterization applications to use another protocol extension that is explicitly designed for these needs instead of or in addition to a generic "color management" extension that is designed for all apps for general content delivery purposes. I presume the measurement or calibration use case always involves "owning" the whole monitor, and the very specific monitor at that. That is, making the monitor temporarily exclusive to the app, so that nothing else can interfere (e.g. instant messaging notification popping up just under the measurement sensor). That would also give an opportunity, if wanted(!), to bypass compositor color conversions and do or not do anything else special. IOW, measurement/calibration/characterization is off the scope of the currently on-going discussions. As a precedent, Weston has a separate protocol extension for calibrating touchscreen touch points. There was a calibration app that was using just the normal input interfaces all apps can use, but the shortcomings of that made it very painful to use correctly and there were no guarantees it produced the correct result. It also could not load the new calibration into the compositor at all, and was not able to compute it in the coordinate system libinput needs it. With a new protocol extension designed specifically for calibration all these problems went away: https://lists.freedesktop.org/archives/wayland-devel/2018-March/037610.html Thanks, pq
pgpUpQW7xHElR.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
