Re: xfwm4-wayland (xfway) is being ported to wlroots

[Alex]

Hi Adlo,

great to hear so, sounds promising !

I have currently trouble to build it (sent you a pm). When the build
runs fine for me, I'll give it a spin.

When you succeed in bringing the project into a good shape, and after
some testing, I suppose it would make sense to host it on
https://gitlab.xfce.org/  (if non of the core devs puts a veto)

Cheers, Alex

Am 15.07.22 um 06:54 schrieb adlo:

I am currently porting xfwm4-wayland (xfway) to wlroots. It is based on
Ariadne's Hopalong compositor.

I have also ported xfwm4's build system to Meson.

At the moment there are feature regressions compared to the libweston
version.

You can build it with meson.

https://github.com/adlocode/xfwm4/tree/wlroots

Regards

adlo
___
Xfce4-dev mailing list
xfce4-...@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-dev

Re: [PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure

[Alex Deucher]

On Thu, Dec 14, 2017 at 6:40 AM, Pekka Paalanen  wrote:
> From: Pekka Paalanen 
>
> Hi all,
>
> this is v5 (to match the numbering of my public branches) of the libweston 
> user
> facing API and infrastructure for supporting shared-CRTC clone mode.
>
> Previous submission with rationale:
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
>
> Design document:
> https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
>
> The goal:
> https://phabricator.freedesktop.org/T7727

FWIW, at least with the DC modesetting code in amdgpu, we can
synchronize multiple crtcs to the same timing when the monitors all
support the same mode timing or with monitors that have different
timings using variable length blanking periods on freesync capable
monitors.


Alex

>
> Changes in v5 compared to v3 are minor:
> - "libweston: properly orphan wl_output resources" is new.
> - Removal of wl_output global, when a head is detached from an enabled output.
> - Print "Detected a monitor change" only for enabled heads.
>
> You can find this series in the branch:
> https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5
>
> I went through the same testing procedure as with v3, the previous submission.
>
>
> However, the interesting bits are in the branch:
> https://gitlab.collabora.com/pq/weston/commits/clonemode-4
>
> As new things compared to clonemode-user-API-2, that one contains:
> - support for configuring clone mode in weston.ini
> - main.c implementation to configure a clode using the new API
> - desktop-shell enhancements to avoid redundant panel and background surfaces
>   in clone mode
> - hooking up custom data to weston_output via a new user-side destroy signal
> - naming outputs freely
> - DRM-backend support for shared-CRTC clone mode
> - video mode list merging in the DRM-backend
>
> The shared-CRTC clone mode has been tested to work on an i.MX6 device.
> Unfortunately it seems that PC hardware that would support it is becoming
> scarce AFAIU.
>
> Most of the patches in clonemode-4 depend on the atomic modesetting series and
> can therefore be submitted only after that one.
>
>
> Thanks,
> pq
>
> Pekka Paalanen (36):
>   libweston: introduce weston_head
>   libweston: move wl_output to weston_head
>   libweston: use head in wl_output global
>   libweston: make wl_output point to weston_head
>   libweston: refactor weston_mode_switch_finish
>   libweston: introduce weston_output::head_list
>   libweston: properly orphan wl_output resources
>   libweston: strdup head make, model, serial_number
>   cms-colord: find a good head
>   libweston: add name to weston_head
>   libweston: add weston_head::connected
>   libweston: add compositor list of heads
>   libweston: add heads_changed hook
>   libweston: new head-based output management API
>   libweston: add weston_head destroy signal
>   libweston: add weston_head_is_device_changed() API
>   weston: move weston_output_enable() into callers
>   weston: migrate headless to head-based output API
>   weston: migrate x11 to head-based output API
>   weston: migrate wayland to head-based output API
>   weston: migrate fbdev to head-based output API
>   weston: migrate RDP to head-based output API
>   weston: migrate DRM to head-based output API
>   libweston: change windowed_output_api output_create to create_head
>   libweston: remove output_pending_signal
>   libweston: stop auto-adding the implicit head
>   libweston: assert make/model in weston_output_enable()
>   libweston: assert current_mode in weston_output_enable()
>   libweston: cancel idle_repaint on output destroy
>   compositor-headless: migrate to head-based output API
>   compositor-rdp: migrate to head-based output API
>   compositor-fbdev: make re-enable less drastic
>   compositor-fbdev: migrate to head-based output API
>   compositor-x11: migrate to head-based output API
>   compositor-wayland: strict surface create/destroy
>   compositor-wayland: migrate to head-based output API
>
>  compositor/cms-colord.c |  38 +-
>  compositor/main.c   | 304 +---
>  compositor/weston-screenshooter.c   |   2 +-
>  desktop-shell/input-panel.c |   4 +-
>  desktop-shell/shell.c   |   4 +-
>  fullscreen-shell/fullscreen-shell.c |   4 +-
>  ivi-shell/input-panel-ivi.c |   4 +-
>  libweston-desktop/wl-shell.c|   2 +-
>  libweston-desktop/xdg-shell-v5.c|   2 +-
>  libweston-desktop/xdg-shell-v6.c|   2 +-
>  libweston/compositor-drm.c  |  15 +-
>  libweston/compositor-fbdev.c| 206 +---
>  libweston/compositor-headless.c |  75 ++-
>  l

Re: [PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure

[Alex Deucher]

On Fri, Dec 15, 2017 at 2:27 AM, Pekka Paalanen  wrote:
> On Thu, 14 Dec 2017 10:11:32 -0500
> Alex Deucher  wrote:
>
>> On Thu, Dec 14, 2017 at 6:40 AM, Pekka Paalanen  wrote:
>> > From: Pekka Paalanen 
>> >
>> > Hi all,
>> >
>> > this is v5 (to match the numbering of my public branches) of the libweston 
>> > user
>> > facing API and infrastructure for supporting shared-CRTC clone mode.
>> >
>> > Previous submission with rationale:
>> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
>> >
>> > Design document:
>> > https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
>> >
>> > The goal:
>> > https://phabricator.freedesktop.org/T7727
>>
>> FWIW, at least with the DC modesetting code in amdgpu, we can
>> synchronize multiple crtcs to the same timing when the monitors all
>> support the same mode timing or with monitors that have different
>> timings using variable length blanking periods on freesync capable
>> monitors.
>
> Hi Alex,
>
> that's cool. How does userspace take advantage of that, how do you
> configure KMS/atomic to make use of that? Is it supported through
> legacy KMS (non-atomic) as well?

the driver automatically syncs all heads that it can at modeset time I think.

>
> Does it involve things like the driver stealing an unused CRTC for each
> additional clone?

No, there is logic in the gpu to sync the timing of multiple crtcs.
You just need 1 crtc per display.

>
> The feature would fit perfectly under the "shared-CRTC clone mode" from
> libweston API point of view, even though it's not actually a single
> shared CRTC.
>
>
> Thanks,
> pq
>
>>
>>
>> Alex
>>
>> >
>> > Changes in v5 compared to v3 are minor:
>> > - "libweston: properly orphan wl_output resources" is new.
>> > - Removal of wl_output global, when a head is detached from an enabled 
>> > output.
>> > - Print "Detected a monitor change" only for enabled heads.
>> >
>> > You can find this series in the branch:
>> > https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5
>> >
>> > I went through the same testing procedure as with v3, the previous 
>> > submission.
>> >
>> >
>> > However, the interesting bits are in the branch:
>> > https://gitlab.collabora.com/pq/weston/commits/clonemode-4
>> >
>> > As new things compared to clonemode-user-API-2, that one contains:
>> > - support for configuring clone mode in weston.ini
>> > - main.c implementation to configure a clode using the new API
>> > - desktop-shell enhancements to avoid redundant panel and background 
>> > surfaces
>> >   in clone mode
>> > - hooking up custom data to weston_output via a new user-side destroy 
>> > signal
>> > - naming outputs freely
>> > - DRM-backend support for shared-CRTC clone mode
>> > - video mode list merging in the DRM-backend
>> >
>> > The shared-CRTC clone mode has been tested to work on an i.MX6 device.
>> > Unfortunately it seems that PC hardware that would support it is becoming
>> > scarce AFAIU.
>> >
>> > Most of the patches in clonemode-4 depend on the atomic modesetting series 
>> > and
>> > can therefore be submitted only after that one.
>> >
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure

[Alex Deucher]

On Mon, Dec 18, 2017 at 2:38 AM, Pekka Paalanen  wrote:
> On Fri, 15 Dec 2017 15:35:53 -0500
> Alex Deucher  wrote:
>
>> On Fri, Dec 15, 2017 at 2:27 AM, Pekka Paalanen  wrote:
>> > On Thu, 14 Dec 2017 10:11:32 -0500
>> > Alex Deucher  wrote:
>> >
>> >> On Thu, Dec 14, 2017 at 6:40 AM, Pekka Paalanen  
>> >> wrote:
>> >> > From: Pekka Paalanen 
>> >> >
>> >> > Hi all,
>> >> >
>> >> > this is v5 (to match the numbering of my public branches) of the 
>> >> > libweston user
>> >> > facing API and infrastructure for supporting shared-CRTC clone mode.
>> >> >
>> >> > Previous submission with rationale:
>> >> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
>> >> >
>> >> > Design document:
>> >> > https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
>> >> >
>> >> > The goal:
>> >> > https://phabricator.freedesktop.org/T7727
>> >>
>> >> FWIW, at least with the DC modesetting code in amdgpu, we can
>> >> synchronize multiple crtcs to the same timing when the monitors all
>> >> support the same mode timing or with monitors that have different
>> >> timings using variable length blanking periods on freesync capable
>> >> monitors.
>> >
>> > Hi Alex,
>> >
>> > that's cool. How does userspace take advantage of that, how do you
>> > configure KMS/atomic to make use of that? Is it supported through
>> > legacy KMS (non-atomic) as well?
>>
>> the driver automatically syncs all heads that it can at modeset time I think.
>
> Ok, but we need strong timing guarantees to be able to use it, just
> like we have when we have a single CRTC routed to several connectors.
> Is there such a guarantee that continues not only on initial modeset
> but through all following flips as well?

The timing is synchronized so in theory the flips should happen during
the same blanking period.  I think atomic may be able to guarantee
that, but while likely I don't think non-atomic can guarantee it.

>
>> >
>> > Does it involve things like the driver stealing an unused CRTC for each
>> > additional clone?
>>
>> No, there is logic in the gpu to sync the timing of multiple crtcs.
>> You just need 1 crtc per display.
>
> That is a bit awkward for Weston if userspace needs to assign a CRTC
> per connector and then quess whether all the CRTCs will be gen-locked
> for good so it needs only a single repaint loop, or not and it needs a
> repaint loop per CRTC.
>
> Is there a way to know for sure whether a set of CRTCs will be
> gen-locked? Preferably with ATOMIC_TEST_ONLY.

I don't think so.

Alex

>
>
> Thanks,
> pq
>
>>
>> >
>> > The feature would fit perfectly under the "shared-CRTC clone mode" from
>> > libweston API point of view, even though it's not actually a single
>> > shared CRTC.
>> >
>> >
>> > Thanks,
>> > pq
>> >
>> >>
>> >>
>> >> Alex
>> >>
>> >> >
>> >> > Changes in v5 compared to v3 are minor:
>> >> > - "libweston: properly orphan wl_output resources" is new.
>> >> > - Removal of wl_output global, when a head is detached from an enabled 
>> >> > output.
>> >> > - Print "Detected a monitor change" only for enabled heads.
>> >> >
>> >> > You can find this series in the branch:
>> >> > https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5
>> >> >
>> >> > I went through the same testing procedure as with v3, the previous 
>> >> > submission.
>> >> >
>> >> >
>> >> > However, the interesting bits are in the branch:
>> >> > https://gitlab.collabora.com/pq/weston/commits/clonemode-4
>> >> >
>> >> > As new things compared to clonemode-user-API-2, that one contains:
>> >> > - support for configuring clone mode in weston.ini
>> >> > - main.c implementation to configure a clode using the new API
>> >> > - desktop-shell enhancements to avoid redundant panel and background 
>> >> > surfaces
>> >> >   in clone mode
>> >> > - hooking up custom data to weston_output via a new user-side destroy 
>> >> > signal
>> >> > - naming outputs freely
>> >> > - DRM-backend support for shared-CRTC clone mode
>> >> > - video mode list merging in the DRM-backend
>> >> >
>> >> > The shared-CRTC clone mode has been tested to work on an i.MX6 device.
>> >> > Unfortunately it seems that PC hardware that would support it is 
>> >> > becoming
>> >> > scarce AFAIU.
>> >> >
>> >> > Most of the patches in clonemode-4 depend on the atomic modesetting 
>> >> > series and
>> >> > can therefore be submitted only after that one.
>> >> >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: About migrating framebuffers in multi-GPU compositors

[Alex Deucher]

y is attached to the iGPU, you'd need to copy that buffer to
system memory or carve out so it could be displayed by the iGPU
display hardware. If the compositor is compositing the rendering with
other buffers on the iGPU, then it may make more sense to keep it in
VRAM and just read it from the render engine in the iGPU and write the
resulting frame to the display buffer on the iGPU.  This also makes
sense if you have two dGPUs.  Ideally you'd read directly from the
remote device memory rather than taking a trip through system ram.  As
Pekka said, it gets complicated quickly.

What you really want to avoid is reading device memory or carve out
with the CPU.  Not only does it go over the PCI bus, but MMIO space is
usually mapped uncached on the CPU, so you'll be doing uncached reads
over a relatively slow bus.  If you need to get data out of device
memory, it is much better to have a device DMA it to somewhere else.
Either the device where the memory is attached (e.g., DMA from local
VRAM to system memory or local VRAM to remote VRAM on another device),
or the device who wants access to the memory (e.g., DMA from remote
VRAM to system memory or remote VRAM to local VRAM on the device).
Displaylink devices are a bad example of this.  Their display hardware
is fed from system memory, so you need to get the data from the render
device to system memory.  If you try to do the copy with the CPU, the
performance will be unusable.  This should largely work with dma-buf
since the dma-buf will be moved to system memory if the importer
doesn't support peer to peer DMA, but in a lot of cases, user mode
just mmaps the buffer in VRAM rather than importing it as dma-buf and
then copies it using the CPU.  That really only works if the source
buffer is in cached system memory.

Alex

Re: About migrating framebuffers in multi-GPU compositors

[Alex Deucher]

On Thu, Mar 24, 2022 at 3:40 PM Hoosier, Matt  wrote:
>
> On Thu, 2022-03-24 at 15:28 -0400, Alex Deucher wrote:
>
> CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments 
> unless you trust the sender and know the content is safe.
>
>
>
> On Thu, Mar 24, 2022 at 9:43 AM Hoosier, Matt <
>
> matt.hoos...@garmin.com
>
> > wrote:
>
>
> On Thu, 2022-03-24 at 11:56 +0200, Pekka Paalanen wrote:
>
>
> On Wed, 23 Mar 2022 14:19:08 +
>
>
> "Hoosier, Matt" <
>
>
> matt.hoos...@garmin.com
>
>
>
> wrote:
>
>
>
> Hi,
>
>
>
> I recently had a reason to wade through Mutter's code to support
>
>
> systems with more than one GPU. I was a bit surprised to see that
>
>
> it supports several different strategies for dealing with
>
>
> scanning out a buffer on a KMS output not associated with the GPU
>
>
> where the buffer was originally rendered.
>
>
>
> Hi,
>
>
>
> indeed. The reason for multiple paths is that different systems
>
>
> don't support all ways, or do support some of the ways but the
>
>
> performance might be abysmal. Knowing which path to take is a
>
>
> difficult problem, and other than benchmarking (which I didn't
>
>
> implement in Mutter) you can't really know if what you picked is
>
>
> going to be fine.
>
>
>
> In particular, the approach of using the secondary GPU's OpenGL
>
>
> implementation to blit into a dumb buffer was really unexpected.
>
>
> Typically, dumb buffers get described as a really slow, uncached
>
>
> mapping of GPU memory into the CPU.
>
>
>
> The support got added here (by Pekka):
>
>
>
> https://urldefense.com/v3/__https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/615__;!!EJc4YC3iFmQ!FFkanSe1AOe2ya_-thuTSNX7kr4pCENbg2UXiNPEhVEP_uxwjWvWCTHD-4dIcSsrfA$
>
>
>
>
>
> That MR is using the primary GPU to blit, not the secondary GPU.
>
>
>
> If a secondary GPU can have a hardware accelerated OpenGL context,
>
>
> I don't know why anyone would deliberately use dumb buffers on that
>
>
> device with OpenGL. GBM offers better ways.
>
>
>
>
> This MR cover letter has a better overview of all the methods:
>
>
> https://urldefense.com/v3/__https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/810__;!!EJc4YC3iFmQ!FFkanSe1AOe2ya_-thuTSNX7kr4pCENbg2UXiNPEhVEP_uxwjWvWCTHD-4d7YGnc1w$
>
>
>
>
> Ah, even nicer. Thanks!
>
>
> In the ranked-order list of strategies there, the zero-copy technique is less 
> preferred than the secondary GPU copy technique. Seems like you'd rarely ever 
> fall through to the zero-copy strategy even if the GPU drivers do both 
> support it. Anything subtle going on there that's good to be aware of? Like 
> maybe a given driver typically supports secondary-GPU-copy XOR zero-copy, so 
> you're fairly likely to reach the second strategy on systems that can handle 
> it.
>
>
>
>
> If I follow this right, the blit occurs directly between video
>
>
> memory owned by the primary GPU into dumb-buffer memory owned by
>
>
> the secondary GPU, without laboriously using the CPU to do PIO.
>
>
>
> Correct.
>
>
>
> Does this imply that the two GPUs' drivers have to be at least
>
>
> minimally aware of each other to negotiate some kind of DMA path
>
>
> directly between the two?
>
>
>
> I don't know the details. It depends on whether you can map
>
>
> secondary GPU memory to be written by the primary GPU. The specific
>
>
> use case here is iGPU as primary and virtual as secondary, which
>
>
> means that video memory for both is more or less "system RAM". No
>
>
> discrete VRAM involved.
>
>
>
> Oh interesting. I hadn't realized that on the hybrid GPU systems even the 
> dGPU uses system RAM. But on thinking about it, that's probably the only 
> efficient way for the hardware to be designed.
>
>
>
> It is accomplished through the kernel dmabuf framework where
>
>
> drivers export and import dmabuf.
>
>
>
> Right, makes sense.
>
>
> So I wonder how I should reason about a system that's configured with 2x of 
> the same discrete graphics card (AMD, if it matters). The compositor would 
> arbitrarly pick whichever of those happened to enumerate first as the 
> primary, and then it's down to the driver details as to which of the four 
> migration paths gets chosen? For the moment, let's assume that none of the 
> stock applications is bothering to use any sort of advanced dmabuf

Re: [RFC] drm/kms: control display brightness through drm_connector properties

[Alex Deucher]

On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
>
> Hi Simon,
>
> On 4/7/22 18:51, Simon Ser wrote:
> > Very nice plan! Big +1 for the overall approach.
>
> Thanks.
>
> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
> > wrote:
> >
> >> The drm_connector brightness properties
> >> ===
> >>
> >> bl_brightness: rw 0-int32_max property controlling the brightness setting
> >> of the connected display. The actual maximum of this will be less then
> >> int32_max and is given in bl_brightness_max.
> >
> > Do we need to split this up into two props for sw/hw state? The privacy 
> > screen
> > stuff needed this, but you're pretty familiar with that. :)
>
> Luckily that won't be necessary, since the privacy-screen is a security
> feature the firmware/embedded-controller may refuse our requests
> (may temporarily lock-out changes) and/or may make changes without
> us requesting them itself. Neither is really the case with the
> brightness setting of displays.
>
> >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> >> of the display's brightness setting. This will report 0 when brightness
> >> control is not available (yet).
> >
> > I don't think we actually need that one. Integer KMS props all have a
> > range which can be fetched via drmModeGetProperty. The max can be
> > exposed via this range. Example with the existing alpha prop:
> >
> > "alpha": range [0, UINT16_MAX] = 65535
>
> Right, I already knew that, which is why I explicitly added a range
> to the props already. The problem is that the range must be set
> before registering the connector and when the backlight driver
> only shows up (much) later during boot then we don't know the
> range when registering the connector. I guess we could "patch-up"
> the range later. But AFAIK that would be a bit of abuse of the
> property API as the range is intended to never change, not
> even after hotplug uevents. At least atm there is no infra
> in the kernel to change the range later.
>
> Which is why I added an explicit bl_brightness_max property
> of which the value gives the actual effective maximum of the
> brightness.
>
> I did consider using the range for this and updating it
> on the fly I think nothing is really preventing us from
> doing so, but it very much feels like abusing the generic
> properties API.
>
> >> bl_brightness_0_is_min_brightness: ro, boolean
> >> When this is set to true then it is safe to set brightness to 0
> >> without worrying that this completely turns the backlight off causing
> >> the screen to become unreadable. When this is false setting brightness
> >> to 0 may turn the backlight off, but this is not guaranteed.
> >> This will e.g. be true when directly driving a PWM and the video-BIOS
> >> has provided a minimum (non 0) duty-cycle below which the driver will
> >> never go.
> >
> > Hm. It's quite unfortunate that it's impossible to have strong guarantees
> > here.
> >
> > Is there any way we can avoid this prop?
>
> Not really, the problem is that we really don't know if 0 is off
> or min-brightness. In the given example where we actually never go
> down to a duty-cycle of 0% because the video BIOS tables tell us
> not to, we can be certain that setting the brightness prop to 0
> will not turn of the backlight, since we then set the duty-cycle
> to the VBT provided minimum. Note the intend here is to only set
> the boolean to true if the VBT provided minimum is _not_ 0, 0
> just means the vendor did not bother to provide a minimum.
>
> Currently e.g. GNOME never goes lower then something like 5%
> of brightness_max to avoid accidentally turning the screen off.
>
> Turning the screen off is quite bad to do on e.g. tablets where
> the GUI is the only way to undo the brightness change and now
> the user can no longer see the GUI.
>
> The idea behind this boolean is to give e.g. GNOME a way to
> know that it is safe to go down to 0% and for it to use
> the entire range.

Why not just make it policy that 0 is defined as minimum brightness,
not off, and have all drivers conform to that?

Alex

>
> > For instance if we can guarantee that the min level won't turn the screen
> > completely off we could make the range start from 1 instead of 0.
> > Or allow -1 to mean "minimum value, maybe completely off".
>
> Right, the problem is we really don't know and when the range is
> e.g. 0-65535 then something like 1 will almost always still ju

Re: [RFC] drm/kms: control display brightness through drm_connector properties

[Alex Deucher]

On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
>
> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
> > >
> > > Hi Simon,
> > >
> > > On 4/7/22 18:51, Simon Ser wrote:
> > > > Very nice plan! Big +1 for the overall approach.
> > >
> > > Thanks.
> > >
> > > > On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> > > >  wrote:
> > > >
> > > >> The drm_connector brightness properties
> > > >> ===
> > > >>
> > > >> bl_brightness: rw 0-int32_max property controlling the brightness 
> > > >> setting
> > > >> of the connected display. The actual maximum of this will be less then
> > > >> int32_max and is given in bl_brightness_max.
> > > >
> > > > Do we need to split this up into two props for sw/hw state? The privacy 
> > > > screen
> > > > stuff needed this, but you're pretty familiar with that. :)
> > >
> > > Luckily that won't be necessary, since the privacy-screen is a security
> > > feature the firmware/embedded-controller may refuse our requests
> > > (may temporarily lock-out changes) and/or may make changes without
> > > us requesting them itself. Neither is really the case with the
> > > brightness setting of displays.
> > >
> > > >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> > > >> of the display's brightness setting. This will report 0 when brightness
> > > >> control is not available (yet).
> > > >
> > > > I don't think we actually need that one. Integer KMS props all have a
> > > > range which can be fetched via drmModeGetProperty. The max can be
> > > > exposed via this range. Example with the existing alpha prop:
> > > >
> > > > "alpha": range [0, UINT16_MAX] = 65535
> > >
> > > Right, I already knew that, which is why I explicitly added a range
> > > to the props already. The problem is that the range must be set
> > > before registering the connector and when the backlight driver
> > > only shows up (much) later during boot then we don't know the
> > > range when registering the connector. I guess we could "patch-up"
> > > the range later. But AFAIK that would be a bit of abuse of the
> > > property API as the range is intended to never change, not
> > > even after hotplug uevents. At least atm there is no infra
> > > in the kernel to change the range later.
> > >
> > > Which is why I added an explicit bl_brightness_max property
> > > of which the value gives the actual effective maximum of the
> > > brightness.
>
> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> brightness control later on then we just perpetuate the nonsense we have
> right now, forever.
>
> Imo we should support two kinds of drivers:
>
> - drivers which are non-crap, and make sure their backlight driver is
>   loaded before they register the drm_device (or at least the
>   drm_connector). For those we want the drm_connector->backlight pointer
>   to bit static over the lifetime of the connector, and then we can also
>   set up the brightness range correctly.
>
> - funny drivers which implement the glorious fallback dance which
>   libbacklight implements currently in userspace. Imo for these drivers we
>   should have a libbacklight_heuristics_backlight, which normalizes or
>   whatever, and is also ways there. And then internally handles the
>   fallback mess to the "right" backlight driver.
>
> We might have some gaps on acpi systems to make sure the drm driver can
> wait for the backlight driver to show up, but that's about it.
>
> Hotplugging random pieces later on is really not how drivers work nowadays
> with deferred probe and component framework and all that.
>
> > > I did consider using the range for this and updating it
> > > on the fly I think nothing is really preventing us from
> > > doing so, but it very much feels like abusing the generic
> > > properties API.
> > >
> > > >> bl_brightness_0_is_min_brightness: ro, boolean
> > > >> When this is set to true then it is safe to set brightness to 0
> > > >> without worrying that this completely turns the backlight off causing
> > > >> the screen to become unreadable. When this is

Re: [RFC] drm/kms: control display brightness through drm_connector properties

[Alex Deucher]

On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:
>
> Hi,
>
> On 4/8/22 16:08, Alex Deucher wrote:
> > On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
> >>
> >> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> >>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
> >>>>
> >>>> Hi Simon,
> >>>>
> >>>> On 4/7/22 18:51, Simon Ser wrote:
> >>>>> Very nice plan! Big +1 for the overall approach.
> >>>>
> >>>> Thanks.
> >>>>
> >>>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> >>>>>  wrote:
> >>>>>
> >>>>>> The drm_connector brightness properties
> >>>>>> ===
> >>>>>>
> >>>>>> bl_brightness: rw 0-int32_max property controlling the brightness 
> >>>>>> setting
> >>>>>> of the connected display. The actual maximum of this will be less then
> >>>>>> int32_max and is given in bl_brightness_max.
> >>>>>
> >>>>> Do we need to split this up into two props for sw/hw state? The privacy 
> >>>>> screen
> >>>>> stuff needed this, but you're pretty familiar with that. :)
> >>>>
> >>>> Luckily that won't be necessary, since the privacy-screen is a security
> >>>> feature the firmware/embedded-controller may refuse our requests
> >>>> (may temporarily lock-out changes) and/or may make changes without
> >>>> us requesting them itself. Neither is really the case with the
> >>>> brightness setting of displays.
> >>>>
> >>>>>> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> >>>>>> of the display's brightness setting. This will report 0 when brightness
> >>>>>> control is not available (yet).
> >>>>>
> >>>>> I don't think we actually need that one. Integer KMS props all have a
> >>>>> range which can be fetched via drmModeGetProperty. The max can be
> >>>>> exposed via this range. Example with the existing alpha prop:
> >>>>>
> >>>>> "alpha": range [0, UINT16_MAX] = 65535
> >>>>
> >>>> Right, I already knew that, which is why I explicitly added a range
> >>>> to the props already. The problem is that the range must be set
> >>>> before registering the connector and when the backlight driver
> >>>> only shows up (much) later during boot then we don't know the
> >>>> range when registering the connector. I guess we could "patch-up"
> >>>> the range later. But AFAIK that would be a bit of abuse of the
> >>>> property API as the range is intended to never change, not
> >>>> even after hotplug uevents. At least atm there is no infra
> >>>> in the kernel to change the range later.
> >>>>
> >>>> Which is why I added an explicit bl_brightness_max property
> >>>> of which the value gives the actual effective maximum of the
> >>>> brightness.
> >>
> >> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> >> brightness control later on then we just perpetuate the nonsense we have
> >> right now, forever.
> >>
> >> Imo we should support two kinds of drivers:
> >>
> >> - drivers which are non-crap, and make sure their backlight driver is
> >>   loaded before they register the drm_device (or at least the
> >>   drm_connector). For those we want the drm_connector->backlight pointer
> >>   to bit static over the lifetime of the connector, and then we can also
> >>   set up the brightness range correctly.
> >>
> >> - funny drivers which implement the glorious fallback dance which
> >>   libbacklight implements currently in userspace. Imo for these drivers we
> >>   should have a libbacklight_heuristics_backlight, which normalizes or
> >>   whatever, and is also ways there. And then internally handles the
> >>   fallback mess to the "right" backlight driver.
> >>
> >> We might have some gaps on acpi systems to make sure the drm driver can
> >> wait for the backlight driver to show up, but that's about it.
> >>
> >> Hotplugging random pieces later o

Re: [RFC] drm/kms: control display brightness through drm_connector properties

[Alex Deucher]

On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  wrote:
>
> Hi,
>
> On 4/8/22 17:11, Alex Deucher wrote:
> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:
> >>
> >> Hi,
> >>
> >> On 4/8/22 16:08, Alex Deucher wrote:
> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
> >>>>
> >>>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> >>>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>> On 4/7/22 18:51, Simon Ser wrote:
> >>>>>>> Very nice plan! Big +1 for the overall approach.
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> >>>>>>>  wrote:
> >>>>>>>
> >>>>>>>> The drm_connector brightness properties
> >>>>>>>> ===
> >>>>>>>>
> >>>>>>>> bl_brightness: rw 0-int32_max property controlling the brightness 
> >>>>>>>> setting
> >>>>>>>> of the connected display. The actual maximum of this will be less 
> >>>>>>>> then
> >>>>>>>> int32_max and is given in bl_brightness_max.
> >>>>>>>
> >>>>>>> Do we need to split this up into two props for sw/hw state? The 
> >>>>>>> privacy screen
> >>>>>>> stuff needed this, but you're pretty familiar with that. :)
> >>>>>>
> >>>>>> Luckily that won't be necessary, since the privacy-screen is a security
> >>>>>> feature the firmware/embedded-controller may refuse our requests
> >>>>>> (may temporarily lock-out changes) and/or may make changes without
> >>>>>> us requesting them itself. Neither is really the case with the
> >>>>>> brightness setting of displays.
> >>>>>>
> >>>>>>>> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> >>>>>>>> of the display's brightness setting. This will report 0 when 
> >>>>>>>> brightness
> >>>>>>>> control is not available (yet).
> >>>>>>>
> >>>>>>> I don't think we actually need that one. Integer KMS props all have a
> >>>>>>> range which can be fetched via drmModeGetProperty. The max can be
> >>>>>>> exposed via this range. Example with the existing alpha prop:
> >>>>>>>
> >>>>>>> "alpha": range [0, UINT16_MAX] = 65535
> >>>>>>
> >>>>>> Right, I already knew that, which is why I explicitly added a range
> >>>>>> to the props already. The problem is that the range must be set
> >>>>>> before registering the connector and when the backlight driver
> >>>>>> only shows up (much) later during boot then we don't know the
> >>>>>> range when registering the connector. I guess we could "patch-up"
> >>>>>> the range later. But AFAIK that would be a bit of abuse of the
> >>>>>> property API as the range is intended to never change, not
> >>>>>> even after hotplug uevents. At least atm there is no infra
> >>>>>> in the kernel to change the range later.
> >>>>>>
> >>>>>> Which is why I added an explicit bl_brightness_max property
> >>>>>> of which the value gives the actual effective maximum of the
> >>>>>> brightness.
> >>>>
> >>>> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> >>>> brightness control later on then we just perpetuate the nonsense we have
> >>>> right now, forever.
> >>>>
> >>>> Imo we should support two kinds of drivers:
> >>>>
> >>>> - drivers which are non-crap, and make sure their backlight driver is
> >>>>   loaded before they register the drm_device (or at least the
> >>>>   drm_connector). For those we want the drm_connector->backlight pointer
> >>>

Re: I'm adding features to VKMS! What would you like to see?

[Alex Deucher]

On Fri, Jul 29, 2022 at 3:30 AM Jim Shargo  wrote:
>
> Hi Wayland folks!
>
> TL;DR: I'm working on extending VKMS and wanted feedback from other
> compositor/wayland devs.
>> // Background
>
> I work on the ChromeOS compositor, and recently I've been doing a
> bunch of stuff to improve our testing setup. At the moment, my main
> focus is improving our ability to write integration tests against
> DRM/KMS.
>
> It's pretty tricky to get right. Working with mocks of DRM loses all
> the useful helpers that live within the kernel, which would need to be
> rewritten (and kept up-to-date) in userspace. Stuff like writeback
> support would be even harder.
>
> Earlier this year, VKMS came up as a potential solution. I was happy
> to see that Weston is already using it. I've started thinking about
> what features from the wild we'd need, and started digging into the
> code.
>
> // Current Status
>
> I recently sent out my first patchset, which will let userspace build
> their own DRM drivers with ConfigFS. This implicitly adds support for
> multi-display setups which were impossible to test before. This also
> allows for multiple virtual DRM drivers to be created and used at the
> same time, which may increase test parallelism? Haven't tried it yet.
>
> v1 patchset: 
> https://patchwork.kernel.org/project/dri-devel/list/?series=662676
> cover letter: 
> https://lists.freedesktop.org/archives/dri-devel/2022-July/365647.html
>
> // Rough Plans
>
> The big features I want to target with this work are:
>   - Multi-display and movable planes. This is mostly covered by the
> ConfigFS changes.
>   - Hot plugging.
>   - Color, color management and HDR. Loads of new formats, support for
> color properties not currently implemented. Making sure writeback
> buffers are useful for this.
>   - Improve IGT testing for VKMS (for new features and existing skipped tests)
>
> // Questions
>
>   - What VKMS features could help your testing the most?
>   - How much do you care about writeback buffer support vs CRC checks
> in tests atm?
>   - What kinds of bugs do you get around DRM/KMS?
>   - Any thoughts in general?

Hey, nice work!

So, not really related to wayland, but it would be cool if we could
add a generic vkms helper library for drivers to use for virtual
display functionality.  E.g., for headless GPUs in data centers or for
virtualization.  We ended up pulling a version of dkms into amdgpu to
replace our old non-atomic virtual display support.  We tried at the
time to make a generic helper, but ended up running into a lot of
problems around memory access because on real GPUs the vkms is backed
by vram rather than system memory.  I know we could use vkms as a
standalone driver, but that runs into the same issue in that the vkms
is backed by system memory rather than vram.  The latter is desirable
because we want to be able to use vram directly so we can use the
framebuffer as a source for hardware video encoding for example.

Alex

>
> Thanks!
> -- Jim

Re: I'm adding features to VKMS! What would you like to see?

[Alex Deucher]

On Fri, Jul 29, 2022 at 1:28 PM Jonas Ådahl  wrote:
>
> On Fri, Jul 29, 2022 at 12:07:20PM -0400, Alex Deucher wrote:
> > On Fri, Jul 29, 2022 at 3:30 AM Jim Shargo  wrote:
> > >
> > > Hi Wayland folks!
> > >
> > > TL;DR: I'm working on extending VKMS and wanted feedback from other
> > > compositor/wayland devs.
> > >> // Background
> > >
> > > I work on the ChromeOS compositor, and recently I've been doing a
> > > bunch of stuff to improve our testing setup. At the moment, my main
> > > focus is improving our ability to write integration tests against
> > > DRM/KMS.
> > >
> > > It's pretty tricky to get right. Working with mocks of DRM loses all
> > > the useful helpers that live within the kernel, which would need to be
> > > rewritten (and kept up-to-date) in userspace. Stuff like writeback
> > > support would be even harder.
> > >
> > > Earlier this year, VKMS came up as a potential solution. I was happy
> > > to see that Weston is already using it. I've started thinking about
> > > what features from the wild we'd need, and started digging into the
> > > code.
> > >
> > > // Current Status
> > >
> > > I recently sent out my first patchset, which will let userspace build
> > > their own DRM drivers with ConfigFS. This implicitly adds support for
> > > multi-display setups which were impossible to test before. This also
> > > allows for multiple virtual DRM drivers to be created and used at the
> > > same time, which may increase test parallelism? Haven't tried it yet.
> > >
> > > v1 patchset: 
> > > https://patchwork.kernel.org/project/dri-devel/list/?series=662676
> > > cover letter: 
> > > https://lists.freedesktop.org/archives/dri-devel/2022-July/365647.html
> > >
> > > // Rough Plans
> > >
> > > The big features I want to target with this work are:
> > >   - Multi-display and movable planes. This is mostly covered by the
> > > ConfigFS changes.
> > >   - Hot plugging.
> > >   - Color, color management and HDR. Loads of new formats, support for
> > > color properties not currently implemented. Making sure writeback
> > > buffers are useful for this.
> > >   - Improve IGT testing for VKMS (for new features and existing skipped 
> > > tests)
> > >
> > > // Questions
> > >
> > >   - What VKMS features could help your testing the most?
> > >   - How much do you care about writeback buffer support vs CRC checks
> > > in tests atm?
> > >   - What kinds of bugs do you get around DRM/KMS?
> > >   - Any thoughts in general?
> >
> > Hey, nice work!
> >
> > So, not really related to wayland, but it would be cool if we could
> > add a generic vkms helper library for drivers to use for virtual
> > display functionality.  E.g., for headless GPUs in data centers or for
> > virtualization.
>
> With a risk of continuing being a bit off topic...
>
> What use cases is there a need to pass this functionality via virtual
> mode setting to implement virtual monitors in display servers, for
> headless and virtualization?
>
> I realize that there is a use case for virtual mode setting outputs for
> virtual machines meant to e.g. test run distributions while imitating real
> hardware as close as possible, but for actual intended remote access to
> headless machines or virtual machines, compositors can just render to
> offscreen framebuffers and communicate in whatever way, e.g. using DMA
> buffers via some IPC, with the software solution intended to provide the
> actual access.

Being able to run any distro (or compositor) unmodified on headless
GPUs on servers is the big one.  But you can do other things like
fetch EDIDs from displays on your local system and then inject them
into the virtual connectors on the server and start a virtual desktop
with the same "displays" as the local one which you can then use to
stream to your local system which is useful for thin clients.  We also
use it for pre-silicon emulation and early silicon bring-up internally
when we still want a standard "desktop" on the GPU.

Alex

X.Org Foundation Membership Renewal

[Alex Deucher]

On January 19th all xorg members were expired as part of the regular
process to remove inactive members.  If you would still like to be a
member of the X.Org Foundation, please renew your membership.  To
renew or to become a first time member, go to https://members.x.org/ .
For renewals, log in and click the renewal link.  For new members,
click the Join Now link.  The X.org Foundation is a non-profit
organization under the SPI umbrella which acts as a steward for the X
Window System and related projects.  Board elections are coming up so
renew or join today!

Thanks!

Alex Deucher
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 0/6] Add support for atomic async page-flips

[Alex Deucher]

On Tue, Aug 30, 2022 at 1:29 PM Simon Ser  wrote:
>
> This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> commits, aka. "immediate flip" (which might result in tearing).
> The feature was only available via the legacy uAPI, however for
> gaming use-cases it may be desirable to enable it via the atomic
> uAPI too.
>
> - v1: https://patchwork.freedesktop.org/series/107683/
> - User-space patch: https://github.com/Plagman/gamescope/pull/595
> - IGT patch: https://patchwork.freedesktop.org/series/107681/
>
> Main changes in v2: add docs, fail atomic commit if async flip isn't
> possible.
>
> Tested on an AMD Picasso iGPU.

Series is:
Reviewed-by: Alex Deucher 

>
> Simon Ser (6):
>   amd/display: only accept async flips for fast updates
>   drm: document DRM_MODE_PAGE_FLIP_ASYNC
>   drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
>   drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
>   drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
>   amd/display: indicate support for atomic async page-flips on DC
>
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++
>  .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 10 +++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c | 28 +--
>  drivers/gpu/drm/drm_ioctl.c   |  5 
>  drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>  drivers/gpu/drm/nouveau/nouveau_display.c |  1 +
>  drivers/gpu/drm/vc4/vc4_kms.c |  1 +
>  include/drm/drm_mode_config.h | 11 
>  include/uapi/drm/drm.h| 10 ++-
>  include/uapi/drm/drm_mode.h   | 11 
>  11 files changed, 83 insertions(+), 4 deletions(-)
>
> --
> 2.37.2
>
>

Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Alex Goins]

Thank you Harry and all other contributors for your work on this. Responses
inline -

On Mon, 23 Oct 2023, Pekka Paalanen wrote:

> On Fri, 20 Oct 2023 11:23:28 -0400
> Harry Wentland  wrote:
> 
> > On 2023-10-20 10:57, Pekka Paalanen wrote:
> > > On Fri, 20 Oct 2023 16:22:56 +0200
> > > Sebastian Wick  wrote:
> > >   
> > >> Thanks for continuing to work on this!
> > >>
> > >> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote:  
> > >>> v2:
> > >>>  - Update colorop visualizations to match reality (Sebastian, Alex Hung)
> > >>>  - Updated wording (Pekka)
> > >>>  - Change BYPASS wording to make it non-mandatory (Sebastian)
> > >>>  - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
> > >>>section (Pekka)
> > >>>  - Use PQ EOTF instead of its inverse in Pipeline Programming example 
> > >>> (Melissa)
> > >>>  - Add "Driver Implementer's Guide" section (Pekka)
> > >>>  - Add "Driver Forward/Backward Compatibility" section (Sebastian, 
> > >>> Pekka)
> > >
> > > ...
> > >
> > >>> +An example of a drm_colorop object might look like one of these::
> > >>> +
> > >>> +/* 1D enumerated curve */
> > >>> +Color operation 42
> > >>> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 
> > >>> matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve
> > >>> +├─ "BYPASS": bool {true, false}
> > >>> +├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ EOTF, 
> > >>> PQ inverse EOTF, …}
> > >>> +└─ "NEXT": immutable color operation ID = 43

I know these are just examples, but I would also like to suggest the possibility
of an "identity" CURVE_1D_TYPE. BYPASS = true might get different results
compared to setting an identity in some cases depending on the hardware. See
below for more on this, RE: implicit format conversions.

Although NVIDIA hardware doesn't use a ROM for enumerated curves, it came up in
offline discussions that it would nonetheless be helpful to expose enumerated
curves in order to hide the vendor-specific complexities of programming
segmented LUTs from clients. In that case, we would simply refer to the
enumerated curve when calculating/choosing segmented LUT entries.

Another thing that came up in offline discussions is that we could use multiple
color operations to program a single operation in hardware. As I understand it,
AMD has a ROM-defined LUT, followed by a custom 4K entry LUT, followed by an
"HDR Multiplier". On NVIDIA we don't have these as separate hardware stages, but
we could combine them into a singular LUT in software, such that you can combine
e.g. segmented PQ EOTF with night light. One caveat is that you will lose
precision from the custom LUT where it overlaps with the linear section of the
enumerated curve, but that is unavoidable and shouldn't be an issue in most
use-cases.

Actually, the current examples in the proposal don't include a multiplier color
op, which might be useful. For AMD as above, but also for NVIDIA as the
following issue arises:

As discussed further below, the NVIDIA "degamma" LUT performs an implicit fixed
point to FP16 conversion. In that conversion, what fixed point 0x maps
to in floating point varies depending on the source content. If it's SDR
content, we want the max value in FP16 to be 1.0 (80 nits), subject to a
potential boost multiplier if we want SDR content to be brighter. If it's HDR PQ
content, we want the max value in FP16 to be 125.0 (10,000 nits). My assumption
is that this is also what AMD's "HDR Multiplier" stage is used for, is that
correct?

>From the given enumerated curves, it's not clear how they would map to the
above. Should sRGB EOTF have a max FP16 value of 1.0, and the PQ EOTF a max FP16
value of 125.0? That may work, but it tends towards the "descriptive" notion of
assuming the source content, which may not be accurate in all cases. This is
also an issue for the custom 1D LUT, as the blob will need to be converted to
FP16 in order to populate our "degamma" LUT. What should the resulting max FP16
value be, given that we no longer have any hint as to the source content?

I think a multiplier color op solves all of these issues. Named curves and
custom 1D LUTs would by default assume a max FP16 value of 1.0, which would then
be adjusted by the multiplier. For 80 nit SDR content, set it to 1, for 400
nit SDR content, set it to 5, for HDR PQ content, set it to 125, etc. 

> 

Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Alex Goins]

On Thu, 26 Oct 2023, Sebastian Wick wrote:

> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote:
> > On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
> > Alex Goins  wrote:
> >
> > > Thank you Harry and all other contributors for your work on this. 
> > > Responses
> > > inline -
> > >
> > > On Mon, 23 Oct 2023, Pekka Paalanen wrote:
> > >
> > > > On Fri, 20 Oct 2023 11:23:28 -0400
> > > > Harry Wentland  wrote:
> > > >
> > > > > On 2023-10-20 10:57, Pekka Paalanen wrote:
> > > > > > On Fri, 20 Oct 2023 16:22:56 +0200
> > > > > > Sebastian Wick  wrote:
> > > > > >
> > > > > >> Thanks for continuing to work on this!
> > > > > >>
> > > > > >> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote:
> > > > > >>> v2:
> > > > > >>>  - Update colorop visualizations to match reality (Sebastian, 
> > > > > >>> Alex Hung)
> > > > > >>>  - Updated wording (Pekka)
> > > > > >>>  - Change BYPASS wording to make it non-mandatory (Sebastian)
> > > > > >>>  - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane 
> > > > > >>> Property
> > > > > >>>section (Pekka)
> > > > > >>>  - Use PQ EOTF instead of its inverse in Pipeline Programming 
> > > > > >>> example (Melissa)
> > > > > >>>  - Add "Driver Implementer's Guide" section (Pekka)
> > > > > >>>  - Add "Driver Forward/Backward Compatibility" section 
> > > > > >>> (Sebastian, Pekka)
> > > > > >
> > > > > > ...
> > > > > >
> > > > > >>> +An example of a drm_colorop object might look like one of these::
> > > > > >>> +
> > > > > >>> +/* 1D enumerated curve */
> > > > > >>> +Color operation 42
> > > > > >>> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 
> > > > > >>> matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve
> > > > > >>> +├─ "BYPASS": bool {true, false}
> > > > > >>> +├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ 
> > > > > >>> EOTF, PQ inverse EOTF, …}
> > > > > >>> +└─ "NEXT": immutable color operation ID = 43
> > >
> > > I know these are just examples, but I would also like to suggest the 
> > > possibility
> > > of an "identity" CURVE_1D_TYPE. BYPASS = true might get different results
> > > compared to setting an identity in some cases depending on the hardware. 
> > > See
> > > below for more on this, RE: implicit format conversions.
> > >
> > > Although NVIDIA hardware doesn't use a ROM for enumerated curves, it came 
> > > up in
> > > offline discussions that it would nonetheless be helpful to expose 
> > > enumerated
> > > curves in order to hide the vendor-specific complexities of programming
> > > segmented LUTs from clients. In that case, we would simply refer to the
> > > enumerated curve when calculating/choosing segmented LUT entries.
> >
> > That's a good idea.
> >
> > > Another thing that came up in offline discussions is that we could use 
> > > multiple
> > > color operations to program a single operation in hardware. As I 
> > > understand it,
> > > AMD has a ROM-defined LUT, followed by a custom 4K entry LUT, followed by 
> > > an
> > > "HDR Multiplier". On NVIDIA we don't have these as separate hardware 
> > > stages, but
> > > we could combine them into a singular LUT in software, such that you can 
> > > combine
> > > e.g. segmented PQ EOTF with night light. One caveat is that you will lose
> > > precision from the custom LUT where it overlaps with the linear section 
> > > of the
> > > enumerated curve, but that is unavoidable and shouldn't be an issue in 
> > > most
> > > use-cases.
> >
> > Indeed.
> >
> > > Actually, the current examples in the proposal don't include a multiplier 
> > > color
> > > op, which might be useful. For AMD as above, but also for NVIDIA as the

Re: [PATCH v5 00/44] Color Pipeline API w/ VKMS

[Alex Goins]

Hi Harry,

Thanks for this. I just want to remind about a few things that would be required
for NVIDIA hardware, as discussed at the Display Next Hackfest -- fully
understand that they aren't currently included in this series because they
aren't required on AMD hardware. Allowing color ops to be non-bypassable is a
big improvement in this direction.

In each of these cases, it should be possible to represent NVIDIA's color
pipeline using the existing color ops, but it would rely on rejecting invalid
configurations in atomic check, with no way to communicate the limitations to
clients.

- Tag IN_FORMATS for a color pipeline (as you have mentioned).
+ Required to communicate that the first NVIDIA pre-blending LUT is
  incompatible with FP16 inputs.

- Introduce a single-channel 1DLUT color op, or add the ability to flag
  individual channels of an ordinary 1DLUT as read-only.
+ Required to handle NVIDIA's 1D tone-mapping LUT designed to operate only
  on the intensity component of ICtCp.
  
- Allow marking color ops as read-only and non-bypassable (halfway there)
  and/or allow marking a color op as requiring a modeset to update.
+ Required to handle specific LUTs that can't have their entries changed
  while in use without visible glitches/tearing, yet must be enabled to
  support tone-mapping and pre-blend scaling.
+ In lieu of the first option, it may be suitable to just use the existing
  1D curve colorop with only a single curve supported, marked as
  non-bypassable. Allowing modesets as in the second option would allow for
  the possibility of selecting different curves, however.

Thanks,
Alex Goins
NVIDIA

On Mon, 9 Sep 2024, Harry Wentland wrote:

> External email: Use caution opening links or attachments
> 
> 
> On 2024-08-29 10:55, Xaver Hugl wrote:
> > Hi,
> >
> > I have a WIP implementation of this for KWin at
> > https://invent.kde.org/plasma/kwin/-/commits/work/zamundaaa/drm-colorop.
> > It maps KWin's color pipeline to the drm one to get (primary plane
> > only, for now) direct scanout of HDR content on SDR displays while
> > doing tone mapping (or SDR on HDR, but that's been possible before).
> > It currently uses the two 1D custom luts and the 3D lut for this; once
> > I add support for named 1D curves, it should also make use of that and
> > the matrix. I haven't tested the Intel version yet, but if it can
> > match the pipeline, it should work the same there.
> >
> > In testing your amd-color-pipeline-v5 branch I get two crashes in the
> > kernel though: https://invent.kde.org/-/snippets/3217
> > The null pointer dereference only happens sometimes, seemingly
> > randomly, but if I make KWin generate new blobs each frame, I can 100%
> > reliably reproduce the list_add corruption problem by just opening
> > glxgears in fullscreen while the color profile of the display is set
> > to "built in" (which makes it use the 3D LUT for gamut mapping).
> > Here's a branch that generates the color pipeline each frame and
> > triggers this: 
> > https://invent.kde.org/plasma/kwin/-/commits/work/zamundaaa/drm-colorop-list-add-corruption
> >
> 
> Thanks for the test branch. Got a repro and will investigate.
> 
> Harry
> 
> >
> >
> > Am Mo., 19. Aug. 2024 um 22:57 Uhr schrieb Harry Wentland
> > :
> >>
> >> This is an RFC set for a color pipeline API, along with implementations
> >> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
> >> found at [1]. The IGT tests run a pixel-by-pixel comparison with an
> >> allowable delta variation as the goal for these transformations is
> >> perceptual correctness, not complete pixel accuracy.
> >>
> >> v5 of this patchset fleshed out documentation for colorops and the
> >> various defines that are being introduced.
> >>
> >> VKMS supports two named transfer function colorops and two matrix
> >> colorops.
> >>
> >> Amdgpu advertises the following pipeline for GPUs with DCN 3 or newer:
> >>
> >> 1. 1D Curve EOTF
> >> 2. 3x4 CTM
> >> 3. Multiplier
> >> 4. 1D Curve Inverse EOTF
> >> 5. 1D LUT
> >> 6. 3D LUT
> >> 7. 1D Curve EOTF
> >> 8. 1D LUT
> >>
> >> The supported curves for the 1D Curve type are:
> >> - sRGB EOTF and its inverse
> >> - PQ EOTF, scaled to [0.0, 125.0] and its inverse
> >> - BT.2020/BT.709 OETF and its inverse
> >>
> >> Note that the 1st and 5th colorops take the EOTF or Inverse
> >> OETF while the 3rd colorop takes the Inverse EOTF or OETF.
> >>
> >> The 3D LU

Re: Beginnings of multiple monitor

[Alex Deucher]

On Wed, Feb 9, 2011 at 7:01 PM, Marty Jack  wrote:
> I have a little patch that allocates the CRTCs to avoid the multiple monitor 
> black screen.  If you don't want it right now that's fine too.
>
> I don't know what Kristian's ultimate vision of this is.  Do we allow windows 
> to move like they do now on a virtual desktop where you can slide one to a 
> RightOf monitor by dragging it and it appears part on one and part on the 
> other?
>
> A lot of the data structure and processing change for multiple monitors would 
> depend on whether it is possible to have one pair of big FBs added to both 
> CRTCs at the same time, with different (x,y,w,h) if it is tiled and the same 
> (x,y) if it is cloned or how he would want to handle this case [moving the 
> rbo, fb_id, image up to drm_compositor].  With some philosophical guidance I 
> could get the underpinnings in place.
>

The sensible way to handle this is one surface per crtc otherwise we
run into the same problems we hit with X where a multi-head desktop is
too wide for the render/texture limits of the hardware.

Alex

> diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c
> index 6df6b34..d8827b7 100644
> --- a/compositor/compositor-drm.c
> +++ b/compositor/compositor-drm.c
> @@ -37,6 +37,7 @@ struct drm_compositor {
>        struct udev *udev;
>        struct wl_event_source *drm_source;
>
> +       uint32_t crtc_allocator;
>        struct tty *tty;
>  };
>
> @@ -198,7 +199,7 @@ create_output_for_connector(struct drm_compositor *ec,
>        }
>
>        for (i = 0; i < resources->count_crtcs; i++) {
> -               if (encoder->possible_crtcs & (1 << i))
> +               if ((encoder->possible_crtcs & (1 << i)) && ( ! 
> (ec->crtc_allocator & (1 << i
>                        break;
>        }
>        if (i == resources->count_crtcs) {
> @@ -210,6 +211,7 @@ create_output_for_connector(struct drm_compositor *ec,
>        wlsc_output_init(&output->base, &ec->base, 0, 0,
>                         mode->hdisplay, mode->vdisplay);
>
> +       ec->crtc_allocator |= (1 << i);
>        output->crtc_id = resources->crtcs[i];
>        output->connector_id = connector->connector_id;
>        output->mode = *mode;
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
 wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  wrote:
>> On Mon, 21 Mar 2011 19:19:43 +
>> timofonic timofonic  wrote:
>>> So if KMS is so cool and provides many advantages over fbdev and
>>> such... Why isn't more widely used intead of still relying on fbdev?
>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>> it seems) instead using KMS directly?
>>
>> Used by what?  All three major GPU device classes have KMS support
>> (Intel, ATI, and nVidia).  If you want it for a particular device, you
>> can always port it over.
>
> The three major GPU device classes on PC...

Sadly it gets worse.  A lot of the SoC vendors are adding an fbdev
emulation layer on top of v4l rather than using fbdev directly or
using KMS and v4l has grown it's own edid, hdmi, and cec handling.

Alex

>
>> As for fbdev emulation, what's still using it?  There's nothing
>> stopping projects from converting over; X and Wayland can already
>> handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
>
>>> I know the graphic driver situation is quite bad on Linux, especially
>>> on the embedded world. Fbdev seems is still quite used there by binary
>>> blob drivers.
>>
>> Probably for a couple of reasons:
>>  1) inertia: fbdev has been around a lot longer, and provides most of
>>  what embedded devices need anyway
>>  2) feature set: why bother doing a full KMS driver if you're not
>>  going to use any of the additional features it would provide (output
>>  management, memory management, execution management)
>
> ... if no additional features of KMS are needed?
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
>                                 -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary  wrote:
> On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
>> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes 
> wrote:
>> > On Mon, 21 Mar 2011 19:19:43 +
>> >
>> > timofonic timofonic  wrote:
>> >> So if KMS is so cool and provides many advantages over fbdev and
>> >> such... Why isn't more widely used intead of still relying on fbdev?
>> >> Why still using fbdev emulation (that is partial and somewhat broken,
>> >> it seems) instead using KMS directly?
>> >
>> > Used by what?  All three major GPU device classes have KMS support
>> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
>> > can always port it over.
>> >
>> > As for fbdev emulation, what's still using it?  There's nothing
>> > stopping projects from converting over; X and Wayland can already
>> > handle KMS APIs just fine.
>> >
>> >> I know the graphic driver situation is quite bad on Linux, especially
>> >> on the embedded world. Fbdev seems is still quite used there by binary
>> >> blob drivers.
>> >
>> > Probably for a couple of reasons:
>> >  1) inertia: fbdev has been around a lot longer, and provides most of
>> >  what embedded devices need anyway
>> >  2) feature set: why bother doing a full KMS driver if you're not
>> >  going to use any of the additional features it would provide (output
>> >  management, memory management, execution management)
>>
>> Related: We are still missing basic userspace tools (kmsset, e.g.),
>> some kind of direct KMS console (kmscon would work, if it existed),
>> and an xf86-video-modesetting which compiles and works (this is
>> actually possible now, with some patches that landed in 2.6.38 for
>> generic KMS access.)
>
> This looks interesting. If existing *fb drivers could be easily converted to
> KMS (including 2D acceleration) and then used in X with a common driver, it
> would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
> with 2D acceleration.

You'd need to update the existing DDX to work with KMS.  Generally you
need some sort of userspace driver to allocate the buffers, deal with
acceleration alignment, build the acceleration command buffers, and
interface with X.

Alex

>
>> This is important to me, as the various old drivers I've been hacking
>> on won't be accepted upstream without some sort of userspace which can
>> work with them. One of the big goals of KMS was a generic
>> userspace-facing API, like FB, but without the suck.
>
>
> --
> Ondrej Zary
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Google Summer of Code 2016

[Alex Deucher]

Hi,

It's time to start thinking about the Google Summer of Code for 2016!
The Xorg GSoC project is open to all projects related to graphics,
windowing systems, and related technologies (Mesa, Wayland, X, input,
kernel, OpenGL, OpenCL, etc.).

For mentors and developers, please start thinking of ideas and update
your Summer of Code ideas pages.  The main Xorg page is available
here:
http://www.xorg-foundation.org/wiki/SummerOfCodeIdeas/
If you have trouble updating it directly, let me know and I can post
your updated content.

For students, please start your community bonding.  Get on the mailing
lists and start reading code and asking questions.  Think about what
you might want to work on who would be a good mentor.  Don't be afraid
to ask questions!  You can use current and past GSoC ideas as a
starting point for your own.

If anyone has any questions, please don't hesitate to ask.

Thanks!

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Inter-client surface embedding

[Alex Elsayed]

Mark Thomas wrote:

> 
> As part of my current attempts to get MATE fully working on Wayland, I was
> planning to take a look at porting mate-panel this weekend.  However, I
> pretty quickly hit the first snag, which is that Gtk on Wayland doesn't
> support the GtkSocket/GtkPlug interface, which mate-panel relies heavily
> upon.



The question I find myself asking is "Do you really need a full-on surface 
to which you render arbitrarily?"

As I understand it, this is intended for the system-tray type use case, 
correct? Which generally has much simpler requirements in the common case, 
and the exceptional cases really do make more sense as shell plugins. Isn't 
that exactly what the proposed StatusNotifier[1] spec (which is used by KDE, 
I think Gnome as well, likely others) was intended to solve?

In particular, it was explicitly intended to get well clear of XEmbed 
precisely because of how horrid it was to deal with.

Because of the way it was designed, it should work with little-to-no 
modification, regardless of X11, Wayland, or anything else, so long as DBus 
is around.

[1] http://www.notmart.org/misc/statusnotifieritem/index.html

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 1/6] Add colorcorrection protocol

[Alex Elsayed]

Pekka Paalanen wrote:

> On Mon, 31 Mar 2014 09:25:34 +0100
> Richard Hughes  wrote:
> 
>> On 31 March 2014 08:46, Pekka Paalanen
>>  wrote:
>> > how much data can an ICC profile be?
>> 
>> Printer profiles can be several megabytes in size, but display
>> profiles (what will be seen here) are usually in the 20-30kb size
>> range.
> 
> I do wonder if we will have a problem with the maximum message
> size in Wayland. I'm not sure how the maximum is determined, and since
> profiles could in theory be very big, I'd propose using an out-of-band
> method for transferring that data.
> 
>> > Also, what if a client has several surfaces all with the same ICC
>> > profile, would it not be useful to have some notion of re-using an
>> > already sent and parsed color profile? Otherwise I would imagine lots
>> > of overhead if every surface has a private copy of the profile
>> > sent over the wire, parsed, and stored in the compositor's renderer.
>> 
>> I don't think typically they'll be many different profiles in use, on
>> a typical system most things will just be (assumed) sRGB to 'n'
>> display profiles, where n is the number of outputs.
> 
> I take that as "yes, explicit re-use would be very useful" to avoid
> parsing, comparing and coalescing at every turn.

Well, with FD passing couldn't fstat be used with comparing st_dev and 
st_inode? That'd give comparison without parsing (although depending on how 
you use the FD you might want the SEAL_* stuff as well.)

>> > Is that a reasonable requirement for all compositors that support
>> > per-output ICC profiles?
>> 
>> I think it's a very little amount of work, IMO doing it centrally
>> makes a lot of sense as some bits are tricky to do correctly.
> 
> "Tricky" should be solve by shared libraries rather than a daemon,
> IMHO. I'm more concerned about the amount of work the compositor will
> be doing, not the work for implementing it. I think such color space
> conversion should be accounted for the client, i.e. done in the client.
> It would be wasteful, if a compositor needs to compute the source
> conversion every time it just repaints the screen, even if the content
> for a color-managed surface has not changed. I'm assuming a compositor
> would be texturing directly out of a client's buffer.
> 
> I would also like to have room for compositors that blend in a
> non-ideal color space. Having a separate blending color space is
> essentially an additional copy, AFAIU, which is a pretty high cost for
> something, whose result any single client cannot assume at all, anyway.
> I still think that if a client needs the result of blending non-opaque
> pixels to be guaranteed, it should do it itself and not rely on the
> server.
> 
>> Overall, I'm very happy to see someone pick up this work. Thanks.
> 
> Indeed.
> 
> 
> Thanks,
> pq


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

[Alex Deucher]

On Tue, Jun 24, 2014 at 11:29 PM, Alvaro Fernando García
 wrote:
> Signed-off-by: Alvaro Fernando García 

I think it would be better to just squash this entire patch set into one patch.

Alex

> ---
>  src/compositor-drm.c | 35 ---
>  1 file changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 7d514e4..4d23b7c 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -55,6 +55,14 @@
>  #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
>  #endif
>
> +#ifndef DRM_CAP_CURSOR_WIDTH
> +#define DRM_CAP_CURSOR_WIDTH 0x8
> +#endif
> +
> +#ifndef DRM_CAP_CURSOR_HEIGHT
> +#define DRM_CAP_CURSOR_HEIGHT 0x9
> +#endif
> +
>  static int option_current_mode = 0;
>
>  enum output_config {
> @@ -108,6 +116,9 @@ struct drm_compositor {
>
> clockid_t clock;
> struct udev_input input;
> +
> +   uint32_t cursor_width;
> +   uint32_t cursor_height;
>  };
>
>  struct drm_mode {
> @@ -987,7 +998,7 @@ drm_output_set_cursor(struct drm_output *output)
> (struct drm_compositor *) output->base.compositor;
> EGLint handle, stride;
> struct gbm_bo *bo;
> -   uint32_t buf[64 * 64];
> +   uint32_t buf[c->cursor_width * c->cursor_height];
> unsigned char *s;
> int i, x, y;
>
> @@ -1010,7 +1021,7 @@ drm_output_set_cursor(struct drm_output *output)
> s = wl_shm_buffer_get_data(buffer->shm_buffer);
> wl_shm_buffer_begin_access(buffer->shm_buffer);
> for (i = 0; i < ev->surface->height; i++)
> -   memcpy(buf + i * 64, s + i * stride,
> +   memcpy(buf + i * c->cursor_width, s + i * stride,
>ev->surface->width * 4);
> wl_shm_buffer_end_access(buffer->shm_buffer);
>
> @@ -1018,8 +1029,8 @@ drm_output_set_cursor(struct drm_output *output)
> weston_log("failed update cursor: %m\n");
>
> handle = gbm_bo_get_handle(bo).s32;
> -   if (drmModeSetCursor(c->drm.fd,
> -output->crtc_id, handle, 64, 64)) {
> +   if (drmModeSetCursor(c->drm.fd, output->crtc_id, handle,
> +   c->cursor_width, c->cursor_height)) {
> weston_log("failed to set cursor: %m\n");
> c->cursors_are_broken = 1;
> }
> @@ -1296,6 +1307,14 @@ init_drm(struct drm_compositor *ec, struct udev_device 
> *device)
> else
> ec->clock = CLOCK_REALTIME;
>
> +   ret = drmGetCap(fd, DRM_CAP_CURSOR_WIDTH, &cap);
> +   if (ret == 0)
> +   ec->cursor_width = cap;
> +
> +   ret = drmGetCap(fd, DRM_CAP_CURSOR_HEIGHT, &cap);
> +   if (ret == 0)
> +   ec->cursor_height = cap;
> +
> return 0;
>  }
>
> @@ -1554,15 +1573,17 @@ drm_output_init_egl(struct drm_output *output, struct 
> drm_compositor *ec)
> return -1;
> }
>
> -   flags = GBM_BO_USE_CURSOR_64X64 | GBM_BO_USE_WRITE;
> +   flags = GBM_BO_USE_WRITE;
> +   if (ec->cursor_width == 64 && ec->cursor_height == 64)
> +   flags = GBM_BO_USE_CURSOR_64X64 | flags;
>
> for (i = 0; i < 2; i++) {
> if (output->cursor_bo[i])
> continue;
>
> output->cursor_bo[i] =
> -   gbm_bo_create(ec->gbm, 64, 64, GBM_FORMAT_ARGB,
> - flags);
> +   gbm_bo_create(ec->gbm, ec->cursor_width, 
> ec->cursor_height,
> +   GBM_FORMAT_ARGB, flags);
> }
>
> if (output->cursor_bo[0] == NULL || output->cursor_bo[1] == NULL) {
> --
> 2.0.0
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH V2] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

[Alex Deucher]

On Wed, Jun 25, 2014 at 10:09 AM, Alvaro Fernando García
 wrote:
> Init cursor size to 64x64 if drmGetCap() fails.
>
> Use Mesa GBM_BO_USE_CURSOR define (which removes 64x64 restriction)
>
> Signed-off-by: Alvaro Fernando García 

Reviewed-by: Alex Deucher 

> ---
>  src/compositor-drm.c | 43 ---
>  1 file changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 7d514e4..61ddea1 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -55,6 +55,14 @@
>  #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
>  #endif
>
> +#ifndef DRM_CAP_CURSOR_WIDTH
> +#define DRM_CAP_CURSOR_WIDTH 0x8
> +#endif
> +
> +#ifndef DRM_CAP_CURSOR_HEIGHT
> +#define DRM_CAP_CURSOR_HEIGHT 0x9
> +#endif
> +
>  static int option_current_mode = 0;
>
>  enum output_config {
> @@ -108,6 +116,9 @@ struct drm_compositor {
>
> clockid_t clock;
> struct udev_input input;
> +
> +   uint32_t cursor_width;
> +   uint32_t cursor_height;
>  };
>
>  struct drm_mode {
> @@ -987,7 +998,7 @@ drm_output_set_cursor(struct drm_output *output)
> (struct drm_compositor *) output->base.compositor;
> EGLint handle, stride;
> struct gbm_bo *bo;
> -   uint32_t buf[64 * 64];
> +   uint32_t buf[c->cursor_width * c->cursor_height];
> unsigned char *s;
> int i, x, y;
>
> @@ -1010,7 +1021,7 @@ drm_output_set_cursor(struct drm_output *output)
> s = wl_shm_buffer_get_data(buffer->shm_buffer);
> wl_shm_buffer_begin_access(buffer->shm_buffer);
> for (i = 0; i < ev->surface->height; i++)
> -   memcpy(buf + i * 64, s + i * stride,
> +   memcpy(buf + i * c->cursor_width, s + i * stride,
>ev->surface->width * 4);
> wl_shm_buffer_end_access(buffer->shm_buffer);
>
> @@ -1018,8 +1029,8 @@ drm_output_set_cursor(struct drm_output *output)
> weston_log("failed update cursor: %m\n");
>
> handle = gbm_bo_get_handle(bo).s32;
> -   if (drmModeSetCursor(c->drm.fd,
> -output->crtc_id, handle, 64, 64)) {
> +   if (drmModeSetCursor(c->drm.fd, output->crtc_id, handle,
> +   c->cursor_width, c->cursor_height)) {
> weston_log("failed to set cursor: %m\n");
> c->cursors_are_broken = 1;
> }
> @@ -1296,6 +1307,18 @@ init_drm(struct drm_compositor *ec, struct udev_device 
> *device)
> else
> ec->clock = CLOCK_REALTIME;
>
> +   ret = drmGetCap(fd, DRM_CAP_CURSOR_WIDTH, &cap);
> +   if (ret == 0)
> +   ec->cursor_width = cap;
> +   else
> +   ec->cursor_width = 64;
> +
> +   ret = drmGetCap(fd, DRM_CAP_CURSOR_HEIGHT, &cap);
> +   if (ret == 0)
> +   ec->cursor_height = cap;
> +   else
> +   ec->cursor_height = 64;
> +
> return 0;
>  }
>
> @@ -1554,15 +1577,21 @@ drm_output_init_egl(struct drm_output *output, struct 
> drm_compositor *ec)
> return -1;
> }
>
> -   flags = GBM_BO_USE_CURSOR_64X64 | GBM_BO_USE_WRITE;
> +#ifdef GBM_BO_USE_CURSOR
> +   flags = GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE;
> +#else
> +   flags = GBM_BO_USE_WRITE;
> +   if (ec->cursor_width == 64 && ec->cursor_height == 64)
> +   flags = GBM_BO_USE_CURSOR_64X64 | flags;
> +#endif
>
> for (i = 0; i < 2; i++) {
> if (output->cursor_bo[i])
> continue;
>
> output->cursor_bo[i] =
> -   gbm_bo_create(ec->gbm, 64, 64, GBM_FORMAT_ARGB,
> - flags);
> +   gbm_bo_create(ec->gbm, ec->cursor_width, 
> ec->cursor_height,
> +   GBM_FORMAT_ARGB, flags);
> }
>
> if (output->cursor_bo[0] == NULL || output->cursor_bo[1] == NULL) {
> --
> 2.0.0
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

ecore-wayland: (version2) Fix monitoring ECORE_FD_WRITE defaultly on wayland display fd lead to 100% cpu usage

[Alex Wu]

Hi all,
To fix the regression reported at
http://trac.enlightenment.org/e/ticket/1993, I cooked the version 2 of
this patch. Please checkout it out.
From e4ff96104075c972b24752e6799ac88acceccd48 Mon Sep 17 00:00:00 2001
From: Alex Wu 
Date: Mon, 17 Dec 2012 11:05:11 +0800
Subject: [PATCH] ecore-wayland: (version 2)Fix monitoring ECORE_FD_WRITE
 defaultly on waylanddisplay fd lead to 100%
 cpu usage

In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.

Change from v1:
Add idle enterer destroy code into _ecore_wl_shutdown() to avoid
using freed wl_display.
---
 trunk/efl/src/lib/ecore_wayland/Ecore_Wayland.h |1 +
 trunk/efl/src/lib/ecore_wayland/ecore_wl.c  |   40 +--
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/trunk/efl/src/lib/ecore_wayland/Ecore_Wayland.h 
b/trunk/efl/src/lib/ecore_wayland/Ecore_Wayland.h
index 5281c6f..eadfc14 100644
--- a/trunk/efl/src/lib/ecore_wayland/Ecore_Wayland.h
+++ b/trunk/efl/src/lib/ecore_wayland/Ecore_Wayland.h
@@ -87,6 +87,7 @@ struct _Ecore_Wl_Display
unsigned int mask;
unsigned int serial;
Ecore_Fd_Handler *fd_hdl;
+   Ecore_Idle_Enterer *idle_enterer;
 
struct wl_list inputs;
struct wl_list outputs;
diff --git a/trunk/efl/src/lib/ecore_wayland/ecore_wl.c 
b/trunk/efl/src/lib/ecore_wayland/ecore_wl.c
index 7f06a1d..3e5bc8f 100644
--- a/trunk/efl/src/lib/ecore_wayland/ecore_wl.c
+++ b/trunk/efl/src/lib/ecore_wayland/ecore_wl.c
@@ -7,6 +7,7 @@
 
 /* local function prototypes */
 static Eina_Bool _ecore_wl_shutdown(Eina_Bool close);
+static Eina_Bool _ecore_wl_cb_idle_enterer(void *data);
 static Eina_Bool _ecore_wl_cb_handle_data(void *data, Ecore_Fd_Handler *hdl);
 static void _ecore_wl_cb_handle_global(void *data, struct wl_registry 
*registry, unsigned int id, const char *interface, unsigned int version 
EINA_UNUSED);
 static Eina_Bool _ecore_wl_xkb_init(Ecore_Wl_Display *ewd);
@@ -138,10 +139,13 @@ ecore_wl_init(const char *name)
 
_ecore_wl_disp->fd_hdl =
  ecore_main_fd_handler_add(_ecore_wl_disp->fd,
-   ECORE_FD_READ | ECORE_FD_WRITE,
+   ECORE_FD_READ,
_ecore_wl_cb_handle_data, _ecore_wl_disp,
NULL, NULL);
 
+   _ecore_wl_disp->idle_enterer =
+ ecore_idle_enterer_add(_ecore_wl_cb_idle_enterer, _ecore_wl_disp);
+
wl_list_init(&_ecore_wl_disp->inputs);
wl_list_init(&_ecore_wl_disp->outputs);
 
@@ -356,6 +360,8 @@ _ecore_wl_shutdown(Eina_Bool close)
 
if (_ecore_wl_disp->fd_hdl)
  ecore_main_fd_handler_del(_ecore_wl_disp->fd_hdl);
+   if (_ecore_wl_disp->idle_enterer)
+  ecore_idle_enterer_del(_ecore_wl_disp->idle_enterer);
 
if (close)
  {
@@ -397,9 +403,31 @@ _ecore_wl_shutdown(Eina_Bool close)
 }
 
 static Eina_Bool
+_ecore_wl_cb_idle_enterer(void *data)
+{
+   Ecore_Wl_Display *ewd;
+   int ret;
+
+   if (!(ewd = data)) return ECORE_CALLBACK_RENEW;
+
+   ret = wl_display_flush(ewd->wl.display);
+   if (ret < 0 && errno == EAGAIN)
+ {
+ecore_main_fd_handler_active_set(ewd->fd_hdl, ECORE_FD_READ | 
ECORE_FD_WRITE);
+ }
+   else if (ret < 0)
+ {
+  /* FIXME: need do error processing? */
+ }
+
+   return ECORE_CALLBACK_RENEW;
+}
+
+static Eina_Bool
 _ecore_wl_cb_handle_data(void *data, Ecore_Fd_Handler *hdl)
 {
Ecore_Wl_Display *ewd;
+   int ret;
 
/* LOGFN(__FILE__, __LINE__, __FUNCTION__); */
 
@@ -412,7 +440,15 @@ _ecore_wl_cb_handle_data(void *data, Ecore_Fd_Handler *hdl)
if (ecore_main_fd_handler_active_get(hdl, ECORE_FD_READ))
  wl_display_dispatch(ewd->wl.display);
else if (ecore_main_fd_handler_active_get(hdl, ECORE_FD_WRITE))
- wl_display_flush(ewd->wl.display);
+ {
+ret = wl_display_flush(ewd->wl.display);
+if (ret == 0)
+  ecore_main_fd_handler_active_set(hdl, ECORE_FD_READ);
+else if (ret == -1 && errno != EAGAIN)
+  {
+/* FIXME: need do error processing? */
+  }
+ }
 
return ECORE_CALLBACK_RENEW;
 }
-- 
1.7.9.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] ecore-wayland: Improve opaque setting logic.

[Alex Wu]

Hi,
I cooked the patch to improve the opaque setting logic in ecore_wayland.
It can significantly help the weston to do more efficient compositing.
Modifications including:
1. Update win->region.opaque in ecore_wl_window_update_size, so that
the opaque info is synced with the geometry.

2. Add win->surface checking in ecore_wl_window_buffer_attach
before send any wl_surface related request, it will avoid segfault
in case that calling ecore_wl_window_buffer_attach() before
ecore_wl_window_show().
From 40ed108f3fc16c87d93c49aee4961a53e01a78a2 Mon Sep 17 00:00:00 2001
From: Alex Wu 
Date: Sat, 5 Jan 2013 10:50:19 +0800
Subject: [PATCH] ecore-wayland: Improve opaque setting logic.

1. Update win->region.opaque in ecore_wl_window_update_size, so that
the opaque info is synced with the geometry.

2. Add win->surface checking in ecore_wl_window_buffer_attach
before send any wl_surface related request, it will avoid segfault
in case that calling ecore_wl_window_buffer_attach() before
ecore_wl_window_show().
---
 trunk/efl/src/lib/ecore_wayland/ecore_wl_window.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/trunk/efl/src/lib/ecore_wayland/ecore_wl_window.c 
b/trunk/efl/src/lib/ecore_wayland/ecore_wl_window.c
index 13ea38f..f20b3c6 100644
--- a/trunk/efl/src/lib/ecore_wayland/ecore_wl_window.c
+++ b/trunk/efl/src/lib/ecore_wayland/ecore_wl_window.c
@@ -241,6 +241,9 @@ ecore_wl_window_buffer_attach(Ecore_Wl_Window *win, struct 
wl_buffer *buffer, in
 return;
  }
 
+   if (!win->surface)
+  return;
+
if (win->region.input)
  {
 wl_surface_set_input_region(win->surface, win->region.input);
@@ -421,6 +424,15 @@ ecore_wl_window_update_size(Ecore_Wl_Window *win, int w, 
int h)
if (!win) return;
win->allocation.w = w;
win->allocation.h = h;
+
+   if (!win->transparent || !win->alpha)
+ {
+if (win->region.opaque) wl_region_destroy(win->region.opaque);
+win->region.opaque = 
+  wl_compositor_create_region(_ecore_wl_disp->wl.compositor);
+wl_region_add(win->region.opaque, win->allocation.x, 
win->allocation.y, 
+  win->allocation.w, win->allocation.h);
+ }
 }
 
 EAPI void 
-- 
1.7.9.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

X.Org Google Summer of Code

[Alex Deucher]

It's that time of year again.  The X.Org foundation is looking for
volunteers to organize the Google Summer of Code application for the
X.Org foundation. Historically the X.Org GSoC application has
encompassed not just X, but the entire open source graphics ecosystem
(mesa, X, kernel, wayland, etc.).  Responsibilities would include
coordinating the application with Google, updating the ideas pages,
and helping to secure mentors.  Having been involved with it for
several years, I can say it is a very rewarding project for all
involved.  If you are interested, please email the board at
bo...@foundation.x.org.

Thanks!

X.Org Foundation Board
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xRandr strikes back

[Alex Deucher]

l object management take care of which
>> reply was for which request.
>>
>> Mode switching can take time, and it might even be best to be
>> performed with all outputs at once, instead of one output at a time
>> sequentially. So, maybe you should also think whether the protocol
>> itself should also have a concept of atomic mode setting for many
>> outputs in one go, so that a server does not have to guess how many
>> outputs you might want to change at a time.
>
>
> Indeed, multiple outputs introduces complexities. I think we should be able
> to follow most of the default xrandr assumptions here. These are a few
> random thoughts I have with that idea in mind:
>
> 1) A second output should be added to the right (or left) of the primary by
> default. (Is there a concept of a primary output in weston? Maybe the one at
> 0,0?)
> 2) There is no concept of --same-as with weston currently. (i.e. clone mode)
> 3) Outputs are generally ordered in a vertical fashion by default.
> 4) For multiple outputs, all of the outputs' positions should be
> recalculated even if only one of the output changes mode. (Perhaps it could
> be intelligent enough to detect when the positions do not need to be reset)

Some other things to consider, lest you end up in the same boat as X:
1. outputs on multiple GPUs
2. one surface per output?
3. probably better to mirror the kernels display abstraction layers
(crtc, encoder, connector) than X's (crtc, output) as it better
matches the hardware.

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] RDP compositor take 5

[Alex Elsayed]

Hardening wrote:

> On 30/03/2013 21:34, Jason Ekstrand wrote:
>> Hardening,

>> 
>> I'm curious what your use-case is for passing an FD to an RDP server.
>> Do you intend it to have an authentication daemon that then starts RDP
>> weston?
>> 
> In this case there's no listener. This could be used to have a process
> that forks a virtual desktop (weston in this case) and wants to get the
> display remotely using RDP.
> 
> I'm also preparing some patch for FreeRDP to have that kind of invocation:
> xfreerdp "/fork:weston --backend=rdp-compositor --width=800 --height=600"
> 
> or with some code to take input/output from stdin/stdout:
> xfreerdp /stdin | weston --backend=rdp-compositor --width=800
> --height=600 --rdp-pipe

Another possible case is to have weston/rdp be socket-activated by systemd, 
much like sshd can be (sshd@.service).

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

X.Org Google Summer of Code

[Alex Deucher]

Just a reminder to all students and mentors planning to work on an
X.Org GSoC project this year, the deadline for applications is
tomorrow (May 3rd, 19:00 UTC).  If you are a student planning to
apply, please submit your application by the deadline.  If you are
planning to mentor a project and have not signed up as a mentor yet,
please log into melange and connect with the xorg organization as a
mentor from your dashboard.  If you have any additional questions, let
me know.

Thanks everyone!

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[Alex Deucher]

On Wed, May 8, 2013 at 5:19 PM, Todd Showalter  wrote:
> On Wed, May 8, 2013 at 3:51 PM, Jason Ekstrand  wrote:
>
>> Also, I agree that you're going to have mixed setups.  Like you said, people
>> replace their laptops fairly frequently.  However, I have a monitor sitting
>> on my desk that I bought in 2004 and it's still working perfectly with no
>> dead pixels.  Even if I go out next year and buy an super hi-res laptop,
>> I'll still plug it into that monitor as an external.  I think we can expect
>> mixed setups for quite some time.
>
> True; I guess my point there is that I'm betting that in the next
> year or so the CCFL on your LCD monitor will go, and you're going to
> be junking it.  It seems like the backlight on CCFL LCD monitors has a
> MTTF of around a decade, and aftermarket replacement of CCFLs is
> neither easy nor financially sensible from what I've seen.
>
>> Also, you have to remember what drives buying monitor A over monitor B.  A
>> lot of the reason to bump from 1280x1024 to 1600x1200 or 1920x1080 is screen
>> space.  You can put a lot more windows (and therefore get more work done) on
>> a 1920x1080 screen than on the old 1280x1024 screen.  With the bump to 4k,
>> you don't get a bump in space, just resolution.  Therefore, I don't know how
>> jumpy people are going to be to replace the 1920x1080 screen with one that's
>> more expensive but doesn't grant them extra room to work.  I don't think the
>> switch to 4k will be as rapid as you are suggesting.
>
> What I think is going to happen is the TV makers will be pushing
> 4K for the "home theatre" market, and will hope to convince people
> with TVs to upgrade to 4K.  There's been a lot of noise over 4K this
> year, mostly because 3DTV has been dead in the water, TVs are becoming
> super cheap commodity items (the price of a big TV has come down by a
> literal order of magnitude in the past decade; I remember seeing 50"
> plasma TVs for $20K CDN, now I can have one for less than $2K CDN, and
> that doesn't even take a decade of inflation into account), and the
> manufacturers are desperate to find a way to convince people that
> their current TV is horribly obsolete and needs replacing.  It sounds
> like the push is going to be for 4K TVs paired with 4K-capable bluray.
>

Perhaps, but what's to say the 4k uptake will be any better than 3DTV?
 3DTV plus 3D bluray didn't take off, why would 4k Plus 4k bluray?
The real problem is lack of content accessibility.  There's no unified
interface to get to all the content users want to access.  Until that
changes, I don't see any big uptake in any new TV technology.

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Alex Deucher]

first degree
> what users will experience with these modes. Furthermore, this will
> allow us to expose "fake" modes for lower resolutions that maybe some
> LCD panels don't support (or do with a bad looking scaling), which some
> games may want.

Just a note that a lot of drivers already expose "fake" scaled modes
using the scalers in the display hardware for fixed mode panels so
you'll have to differentiate whether you want the display hardware or
wayland to do the scaling.

Alex

>
>> What about x,y in the wl_output.geometry event (which I think are just a
>> global coordinate space leak that should not be there)?
>
> Yeah, this is in global coords, and seems like a leak.
>
>> The video modes are important because of the
>> wl_shell_surface.set_fullscreen with method DRIVER. A fullscreen
>> surface with method DRIVER implies, that the client wants the
>> compositor to change the video mode to match this surface. Of course
>> this usually only happens when the fullscreen surface is topmost and
>> active.
>>
>> A client can use the list of supported video modes from the wl_output
>> to choose the size of its fullscreen surface. E.g. if video mode
>> 800x600 is supported, the client may choose to make the fullscreened
>> surface of size 800x600, and assume that the server ideally switches
>> the video mode 800x600 to present the surface.
>>
>> How do buffer_scale and output scale interact with this mechanism?
>
> I think the modes reported should say whether the mode is native or
> scaled, so the app can chose whether to use it or not. However, I think
> its nice that we can support 800x600 in a scaled version even if the lcd
> panel can't drive this natively (or do so poorly). This means you can
> run games designed for 800x600 even on that hardware.
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web] raspberrypi: more accurate on dependencies

[Alex Bradbury]

On 3 June 2013 12:58,   wrote:
> From: Pekka Paalanen 
> It's not strictly necessary to use rpi-update, but I don't know how old
> firmware and libs are in the Raspbian packages, so recommend it still.

They currently contain firmware as of 2013-05-24.

I don't know if it's worth noting in this doc page (is it intended to
*only* contain instructions for those building from source?) but
prebuilt binaries are available at http://raspberrypi.collabora.com/,
and are in fact already included on the most recent Raspbian image.

Regards,

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] config: verify that the config file has been parsed

[Alex DAMIAN]

From: Alexandru DAMIAN 

weston_config_parse may return NULL, leading
to an ungraceful exit via SIGSEGV.

Adding a nice check that gracefully exits the compositor
when the config.ini parsing failed.

Signed-off-by: Alexandru DAMIAN 
---
 src/compositor.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compositor.c b/src/compositor.c
index f619f82..9ba6e88 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3489,6 +3489,10 @@ int main(int argc, char *argv[])
}
 
config = weston_config_parse("weston.ini");
+   if (config == NULL) {
+   weston_log("Could not parse config file weston.ini");
+   exit(EXIT_FAILURE);
+   }
weston_log("Using config file '%s'\n",
   weston_config_get_full_path(config));
section = weston_config_get_section(config, "core", NULL, NULL);
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 1/2] config: verify that the config file has been parsed

[Alex DAMIAN]

From: Alexandru DAMIAN 

weston_config_parse may return NULL, leading
to an ungraceful exit via SIGSEGV.

Adding a nice check that gracefully exits the compositor
when the config.ini parsing failed.

Signed-off-by: Alexandru DAMIAN 
---
 src/compositor.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compositor.c b/src/compositor.c
index f619f82..bc4837f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3489,6 +3489,10 @@ int main(int argc, char *argv[])
}
 
config = weston_config_parse("weston.ini");
+   if (config == NULL) {
+   weston_log("Could not parse config file weston.ini\n");
+   exit(EXIT_FAILURE);
+   }
weston_log("Using config file '%s'\n",
   weston_config_get_full_path(config));
section = weston_config_get_section(config, "core", NULL, NULL);
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 2/2] compositor: check if seteuid worked

[Alex DAMIAN]

From: Alexandru DAMIAN 

Checking the return value from seteuid in
order to not launch clients with the wrong effective uid.

Signed-off-by: Alexandru DAMIAN 
---
 src/compositor.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index bc4837f..2a16f52 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -247,8 +247,11 @@ child_client_exec(int sockfd, const char *path)
sigfillset(&allsigs);
sigprocmask(SIG_UNBLOCK, &allsigs, NULL);
 
-   /* Launch clients as the user. */
-   seteuid(getuid());
+   /* Launch clients as the user. Do not lauch clients with wrong euid.*/
+   if (seteuid(getuid()) -1) {
+   weston_log("compositor: failed seteuid\n");
+   return;
+   }
 
/* SOCK_CLOEXEC closes both ends, so we dup the fd to get a
 * non-CLOEXEC fd to pass through exec. */
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[[PATCH v3 2/2]] compositor: check if seteuid worked

[Alex DAMIAN]

From: Alexandru DAMIAN 

Checking the return value from seteuid in
order to not launch clients with the wrong effective uid.

Signed-off-by: Alexandru DAMIAN 
---
 src/compositor.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index bc4837f..1a85693 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -247,8 +247,11 @@ child_client_exec(int sockfd, const char *path)
sigfillset(&allsigs);
sigprocmask(SIG_UNBLOCK, &allsigs, NULL);
 
-   /* Launch clients as the user. */
-   seteuid(getuid());
+   /* Launch clients as the user. Do not lauch clients with wrong euid.*/
+   if (seteuid(getuid()) == -1) {
+   weston_log("compositor: failed seteuid\n");
+   return;
+   }
 
/* SOCK_CLOEXEC closes both ends, so we dup the fd to get a
 * non-CLOEXEC fd to pass through exec. */
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v3 1/2] config: verify that the config file is not null

[Alex DAMIAN]

From: Alexandru DAMIAN 

weston_config_parse may return NULL,
leading to an ungraceful exit via SIGSEGV if we
try to reference the structure.

Adding a check in weston_config_full_path so that
we return the empty file /dev/null as filename
if we started without a config file.

Signed-off-by: Alexandru DAMIAN 
---
 shared/config-parser.c | 2 +-
 src/compositor.c   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index e1bf212..ef5c5b9 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -385,7 +385,7 @@ weston_config_parse(const char *name)
 const char *
 weston_config_get_full_path(struct weston_config *config)
 {
-   return config->path;
+   return config == NULL ? "/dev/null" : config->path;
 }
 
 int
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/1] config: add command line option for config file

[Alex DAMIAN]

From: Alexandru DAMIAN 

Added an option to specify the weston.ini config file
to be used. Defaults to ${PWD}/weston.ini

Adding a check in weston_config_full_path so that
we don't crash if we started without a config file.

Fixing a typo in help message.

Signed-off-by: Alexandru DAMIAN 
---
 shared/config-parser.c |  2 +-
 src/compositor.c   | 15 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index e1bf212..8defbbb 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -385,7 +385,7 @@ weston_config_parse(const char *name)
 const char *
 weston_config_get_full_path(struct weston_config *config)
 {
-   return config->path;
+   return config == NULL ? NULL : config->path;
 }
 
 int
diff --git a/src/compositor.c b/src/compositor.c
index f619f82..c073410 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3338,7 +3338,8 @@ usage(int error_code)
"  -S, --socket=NAME\tName of socket to listen on\n"
"  -i, --idle-time=SECS\tIdle time in seconds\n"
"  --modules\t\tLoad the comma-separated list of modules\n"
-   "  --log==FILE\t\tLog to the given file\n"
+   "  --log=FILE\t\tLog to the given file\n"
+   "  --config=FILE\t\tUse specified config file. Defaults to 
./weston.ini\n"
"  -h, --help\t\tThis help message\n\n");
 
fprintf(stderr,
@@ -3429,6 +3430,7 @@ int main(int argc, char *argv[])
int32_t help = 0;
char *socket_name = "wayland-0";
int32_t version = 0;
+   char *config_file = "weston.ini";
struct weston_config *config;
struct weston_config_section *section;
 
@@ -3441,6 +3443,7 @@ int main(int argc, char *argv[])
{ WESTON_OPTION_STRING, "log", 0, &log },
{ WESTON_OPTION_BOOLEAN, "help", 'h', &help },
{ WESTON_OPTION_BOOLEAN, "version", 0, &version },
+   { WESTON_OPTION_STRING, "config", 'c', &config_file },
};
 
parse_options(core_options, ARRAY_LENGTH(core_options), &argc, argv);
@@ -3488,9 +3491,13 @@ int main(int argc, char *argv[])
backend = WESTON_NATIVE_BACKEND;
}
 
-   config = weston_config_parse("weston.ini");
-   weston_log("Using config file '%s'\n",
-  weston_config_get_full_path(config));
+   config = weston_config_parse(config_file);
+
+   if (config != NULL) {
+   weston_log("Using config file '%s'\n", 
weston_config_get_full_path(config));
+   } else {
+   weston_log("Starting with no config file.");
+   }
section = weston_config_get_section(config, "core", NULL, NULL);
weston_config_section_get_string(section, "modules", &modules, "");
 
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/1] option-parser: mark option value arguments as parsed

[Alex DAMIAN]

From: Alexandru DAMIAN 

Weston options in long name format may have the
values separated from option name by the '=' character,
or specified as a separate argument, e.g.
"--config value".

If the option value is a separate argument, we need
to mark that argument as parsed and not try to
reiterate over it.

Signed-off-by: Alexandru DAMIAN 
---
 shared/option-parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/shared/option-parser.c b/shared/option-parser.c
index c00349a..c8a84db 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -67,6 +67,7 @@ parse_options(const struct weston_option *options,
strncmp(options[k].name, &argv[i][2], len) == 0 &&
(argv[i][len + 2] == '=' || argv[i][len + 2] == 
'\0')) {
handle_option(&options[k], &argv[i][len + 3]);
+   if (argv[i][len+2] == '\0') i++;
break;
} else if (options[k].short_name &&
   argv[i][0] == '-' &&
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] compositor-drm: fix EGL format type

[Alex DAMIAN]

From: Alexandru DAMIAN 

EGLInt is not always uint32_t so we need
to make sure we use the right int size for the format.

Signed-off-by: Alexandru DAMIAN 
---
 src/compositor-drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 2770c85..9228f85 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -85,7 +85,7 @@ struct drm_compositor {
uint32_t crtc_allocator;
uint32_t connector_allocator;
struct wl_listener session_listener;
-   uint32_t format;
+   EGLint format;
 
/* we need these parameters in order to not fail drmModeAddFB2()
 * due to out of bounds dimensions, and then mistakenly set
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/1] weston-launch: alter tty command line parameter semantics

[Alex DAMIAN]

From: Alexandru DAMIAN 

Current behaviour of the tty parameter is to take effect
only if there is a new user starting up.

Since it is useful to start weston-launch with a command line
specified tty, I'm changing the semantics of the tty parameter:

* the argument to the --tty parameter is now mandatory
* if specified, weston-launch will try to run on the specified tty
* otherwise, it will continue to try to find the first free console

This patch allows starting weston-launch over a ssh connection,
for example, with the current user.

Signed-off-by: Alexandru DAMIAN 
---
 src/weston-launch.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/src/weston-launch.c b/src/weston-launch.c
index 1b560af..94be876 100644
--- a/src/weston-launch.c
+++ b/src/weston-launch.c
@@ -466,14 +466,10 @@ setup_tty(struct weston_launch *wl, const char *tty)
struct vt_mode mode = { 0 };
char *t;
 
-   if (!wl->new_user) {
+   if (tty) {
+   wl->tty = open(tty, O_RDWR | O_NOCTTY);
+   } else if (!wl->new_user) {
wl->tty = STDIN_FILENO;
-   } else if (tty) {
-   t = ttyname(STDIN_FILENO);
-   if (t && strcmp(t, tty) == 0)
-   wl->tty = STDIN_FILENO;
-   else
-   wl->tty = open(tty, O_RDWR | O_NOCTTY);
} else {
int tty0 = open("/dev/tty0", O_WRONLY | O_CLOEXEC);
char filename[16];
@@ -497,7 +493,7 @@ setup_tty(struct weston_launch *wl, const char *tty)
error(1, errno, "stat %s failed", tty);
 
if (major(buf.st_rdev) != TTY_MAJOR)
-   error(1, 0, "invalid tty device: %s", tty);
+   error(1, 0, "invalid tty device: %s ", 
ttyname(wl->tty));
 
wl->ttynr = minor(buf.st_rdev);
}
@@ -631,7 +627,7 @@ main(int argc, char *argv[])
 
memset(&wl, 0, sizeof wl);
 
-   while ((c = getopt_long(argc, argv, "u:t::vh", opts, &i)) != -1) {
+   while ((c = getopt_long(argc, argv, "u:t:vh", opts, &i)) != -1) {
switch (c) {
case 'u':
wl.new_user = optarg;
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Thoughts about decoration information in the xdg_shell

[Alex Elsayed]

Jasper St. Pierre wrote:

> On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
>  wrote:
> 

> 
> I think the trap that I personally don't want to run into is the case
> where we have a compositor that doesn't support SSD coupled to a client
> that doesn't support CSD. Nobody can draw the decorations, and at this
> point we've engineered the user into a corner.
>
> For me, the debate about window decorations and Wayland is that we need
> *something* to be mandated to be supported. GNOME wants that to be CSD,
> and KDE wants that to be SSD.

From Martin's message: "It would require clients to support CSD"

What he's advocating is that, yes, everything must include _support_ for
CSD. But enabling it at _runtime_ should not be mandatory.
 
> From the GNOME side, we're heavily using CSD features in our apps [0]
> (such that we'd probably even ignore the Wayland hint to ignore CSD,
> actually), and SSD code in mutter is a large pile of code I would not like
> to maintain, as it's quite complicated, so it's natural for us to want to
> encourage CSD.

And his proposal explicitly allows that. All it is is a communication
channel; the compositor politely requesting "I'd prefer [not] to draw the
decorations for you" and the application saying "I am [not] drawing my own
decorations."

Without this, the two sides have no clean way to communicate that
information, and to do so requires ad-hoc, hackish attempts to support it at
a layer that support does not belong in. With it, at least the left hand and
right hand can tell what the other is doing.

> I also think that CSD has technical advantages for complex server effects:
> if we simply paint surfaces around the window, if we put the window into
> e.g. Coverflow Alt-Tab, we won't see seams around the window. (And
> personally, I'm of the opinion that any design changes you'd need to make
> to apps to make them usable on a touch device vs. regular device stem far
> beyond the window decorations they use in the end.)

As far as design changes between the devices, those are smaller than you
might think (especially with Qt Quick 2 and the work going on with that; see
[1] and [2])

> I'm fine with a hint telling apps to not draw decorations, but I'd like to
> mandate that CSD is supported by everything.

As I noted, Martin's mail said the same thing.

> [0] 
> http://build.gnome.org/ostree/buildmaster/results/tasks/applicationstest/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png
Link is a 404.

[1] http://aseigo.blogspot.com/2012/10/one-code-base-multiple-form-factors.html
[2] http://www.notmart.org/index.php/Software/Components_towards_a_new_plasma

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Thoughts about decoration information in the xdg_shell

[Alex Elsayed]

Thiago Macieira wrote:

> On segunda-feira, 18 de novembro de 2013 06:37:47, Martin Gräßlin wrote:
>> That sounds look a good solution to me!
> 
> Make it simpler: all clients MUST be able to draw decorations. That's what
> Wayland up until now requires anyway.

It's a given that they must be *able* to decorate themselves, however...

> A client MAY ask the compositor to draw decorations. If and only if the
> compositor replies that it will, the client is then not required to draw
> them. The only compositor likely to even understand this extension is
> kwin: it will reply "sure, I'll decorate" for any apps that request it. If
> necessary, the request can include a suggestion level on how strongly the
> client wants the compositor to do the decoration.

...there are cases where the decorations should not be shown at all. The 
netbook shell, for instance, handles decorations via a Plasma panel IIRC, 
and thus doesn't draw traditional decorations for fullscreen windows *at 
all*.

A client-initiated system like you describe CANNOT handle such a case.

> If the compositor does not reply to the extension, the application MUST
> decorate itself (according to whatever rules are prevalent, including no
> decorations for a tablet or mobile environment, etc.).
>
> If the application does not request it, the compositor MUST NOT decorate
> the windows -- it must assume the client is doing it properly. I'm
> guessing that most toolkits will not request it and will not provide a way
> for applications to do it either.

As stated above, this ignores the valid case of not wanting any decorations 
to be actually drawn *on* the windows, and the functionality instead being 
provided by another means.

I personally have both the top menubar *and* the decorations of fullscreen 
windows hidden, and the functionality appears in an autohiding plasma panel 
to conserve screen space. (dbusmenu/appmenu & kwin-button-applet)


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

[Alex Deucher]

On Tue, Jul 29, 2014 at 3:03 PM, Pekka Paalanen  wrote:
> On Tue, 29 Jul 2014 13:19:10 +0200
> Daniel Vetter  wrote:
>
>> On Tue, Jul 29, 2014 at 12:55:24AM -0700, Jason Ekstrand wrote:
>> > I pushed this one.  Let's get a follow-up that lets weston actually use the
>> > bigger cursors.  It would also be good to hack together a little client
>> > that attaches a big cursor so we can verify that it's working.  I don't
>> > think we need to put it in the repo, I'd just like proof that we're
>> > actually taking advantage of our new-found big cursors.
>>
>> Just an aside: With recent kernels intel hw supporst 64x64, 128x128 and
>> 256x256. On all generations (down to gen2).
>
> Ok, so which one of those will we get through drmGetCap()?
>
> I think it would not be nice, if we receive the values 256x256,
> because then Weston will pad *all* cursor images to 256x256,
> even if 64x64 would suffice. So possibly quite a waste there, first
> memcpy and then full-sized gbm_bo_write for every cursor change.
>
> If drmGetCap returns 64, 128, or 256, how would we infer all the
> valid sizes? All powers-of-two larger than 64x64, included? Is
> e.g. 64x256 valid?

I added the drmGetCap cursor support for radeon as our hw only
supports fixed size hw cursors and there is other hardware out there
with similar limitations.  I'm not sure what the best way to handle
this would be for hw that supports multiple cursor sizes.  I think
perhaps the recent KMS overlay/plane changes cover this by exposing
cursors as planes.

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

GSoC Ideas!

[Alex Deucher]

Hi everyone!

It's that time of year again.  Time to start coming up with GSoC
ideas.  Martin and I are organizing this year's Xorg entry.  We need
to fill in our ideas page with some good possible projects for
students.  The project ideas should be something that a student could
accomplish over the summer so keep the scope focused.  Please use the
templates on
http://www.x.org/wiki/SummerOfCodeIdeas/ and update the wiki or post
the ideas on the mailing list.  Martin and I will update the page as
the ideas come in.

Thanks!

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Graphics memory management in ARM/Embedded Linux

[Alex Deucher]

2011/4/20 Tom Cooksey :
>
>
> 2011/4/20 microcai 
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> 于 2011年04月20日 20:39, Tom Cooksey 写道:
>> > Hi All,
>> >
>> > Please excuse the spam... just trying to spread the word: Linaro is
>> > currently developing a graphics memory manager for Linux which allows
>> > buffers to be shared between different devices and different processes.
>> > On
>> > ARM SoCs, many different hw devices need to access the same buffer
>> > (which
>> > E.g. GEM doesn't support). As a simple example, a GPU needs to write to
>> > a
>> > buffer which a display controller reads from. At least in ARM-Linux
>> > land,
>> > this is a fairly hot-topic and a dedicated mailing list has been created
>> > to
>> > discuss different requirements, figure out if TTM/GEM can be adapted,
>> > etc.
>> >
>> >
>> > The mailing list is here:
>> >
>> > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>> >
>> >
>> > There's also a wiki page gathering requirements here:
>> >
>> >
>> > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement
>> >
>> >
>> > Hopefully there's people on the Wayland list which this will be
>> > interesting
>> > to. Would be cool if a Wayland compositor used the mechanism Linaro
>> > comes up
>> > with to share window buffers between different processes!
>> >
>> >
>> >
>> > Cheers,
>> >
>> > Tom
>> >
>> >
>> >
>>
>> Not again, due!
>> Does DRI has some mentally wrong that cann't be fixed other than
>> re-create?
>
> Yes, possibly. The existing memory managers in Linux (GEM & TTM) don't:
>
> a) Allow buffers to be shared between different device drivers

This being looked at by a number of people.

> b) Don't allow physically contiguous memory allocations (something simple
> hardware without MMUs need)

ttm supports discrete vram which is contiguous.

>
> So while I agree re-inventing something just for the sake of it is bad,
> that's not what's happening. In fact, I think there's a good chance TTM will
> be ripped out, stuck into its own driver (with its own device node /dev/ttm)
> and extended to meet everyone's requirements. At least there has been some
> feasibility work done by Dave Airlie to partially address issue (a):
> http://airlied.livejournal.com/71734.html.

There are a number of people interested in allowing buffers to be
shared between devices and writing a memory manager is a LOT of work.
Would it not make more sense to fix the short comings in ttm to do
what you need rather than writing a new one?

Alex

>
>
> Cheers,
>
> Tom
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: RFC: multitouch support v2

[Alex Elsayed]

Kristian Høgsberg  writes:
> Right... in the MPX sense, right?  So you could have a keyboard and
> mouse combo controlling one pointer/kb focus and the touch screen
> being its own master device.  Then maybe you could have one person
> using the touch screen UI, and another person using the kb/mouse
> combo.  That's kind of far fetched, of course, but I think the main
> point is that there's no inherent association between a kb/mouse combo
> and a touch screen.  On the other hand, what about a setup with two
> mouse/kb combos (master devices) and a touch screen... you'd expect
> tapping a window on the touch screen to set kb focus, but if you have
> multiple master kbs, which kb focus do you set?  Maybe we're just
> doomed for trying to make both pointer and direct touch interaction
> work in the same UI.

One use case you seem to be forgetting is that there are mouse-type
devices like recent Synaptics touchpads that *also* do multitouch.
Multitouch != touchscreen. One way to solve this might be to make 
touchscreens a pointer device *with no associated keyboard device*,
or at least none attached to actual hardware. In XInput, you can create
a new master pair with a real pointer, but only an XTest keyboard. A 
dummy, if you will.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: RFC: multitouch support v2

[Alex Elsayed]

Chase Douglas  writes:
> I don't think anyone is forgetting about indirect devices, at least I'm
> not :). However, their use scenarios are a bit easier to deal with
> because there's no pointer emulation.
> 
> We will also want the ability to have a touchscreen "attached" to a real
> keyboard. Imagine you have a tablet with a bluetooth keyboard. Where you
> touch should change the focus for the keyboard input.

(sorry for deleting history, posting from the Gmane web interface)

Perhaps the best solution is simply to punt grouping input devices to
udev (so that users can write custom rules if need be), and say that
all input sources share focus with fellow members of their group.
This might be compilicated by the desire to move input devices
between groups, though, and before long we end up with something
rather like XInput 2.

I personally think that it would be a *really* good idea to bring Peter
Hutterer into this, seeing as he has literally done this for years, and
certainly has a good idea of where the pitfalls are.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/3] compositor-drm: Add switch_mode support.

[Alex Wu]

于 2012/4/18 9:01, Juan Zhao 写道:

On 04/17/2012 05:20 PM, zhiwen...@linux.intel.com wrote:

+ if (!drm_mode) {
+ printf("%s, invalid resolution:%dx%d\n", __func__, mode->width, 
mode->height);

+ return -1;
+ } else if (&drm_mode->base == output->base.current) {
+ return 0;
+ } else if (drm_mode->base.width == output->base.current->width&&
+ drm_mode->base.height == output->base.current->height) {
+ /* only change refresh value */
+ ret = drmModeSetCrtc(ec->drm.fd,
+ output->crtc_id,
+ output->current_fb_id, 0, 0,
+ &output->connector_id, 1,&drm_mode->mode_info);
+
+ if (ret) {
+ fprintf(stderr, "failed to set mode (%dx%d) %u Hz\n",
+ drm_mode->base.width,
+ drm_mode->base.height,
+ drm_mode->base.refresh);
+ ret = -1;
I would suggest align the error message by fprintf(stderr, "xxx"), or 
some general error message report method.
Because we don't have that general error message report method now, I 
suggest to use "fprintf(stderr, "")".

Yes, I will fix it in next version

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PULL wayland] fd leak checks and a socket fallback

[Alex Bradbury]

On 23 April 2012 13:44, Pekka Paalanen  wrote:
> Btw. I can't find a definition for __NR_accept4 in Bionic. __NR_accept
> is there. Are those constants between arches, would I be able to
> #define it myself?

ARM was missed off when accept4 was added. This was rectified for 2.6.36:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21d93e2e29722d7832f61cc56d73fb953ee6578e

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 1/2] animation: add fading-in animation

[Alex Wu]

于 2012/4/25 19:09, juan.j.z...@linux.intel.com 写道:

From: Juan Zhao

To ful-fill user experience, add the fading-in animation
when mapping a window.
v2: update that westom_surface_damage to repaint
 remove that transform part in fade struct

Signed-off-by: Juan Zhao
---


  src/util.c |   85 
  1 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/src/util.c b/src/util.c
index c7511cf..9943820 100644
--- a/src/util.c
+++ b/src/util.c
@@ -96,6 +96,15 @@ struct weston_zoom {
void *data;
  };

+struct weston_fade {
+   struct weston_surface *surface;
+   struct weston_animation animation;
+   struct weston_spring spring;
+   struct wl_listener listener;
+   void (*done)(struct weston_fade *fade, void *data);
+   void *data;
+};
+
  static void
  weston_zoom_destroy(struct weston_zoom *zoom)
  {
@@ -325,3 +334,79 @@ weston_environment_get_fd(const char *env)

return fd;
  }
+/*fade in and fade out animation*/
+static void
+weston_fade_destroy(struct weston_fade *fade)
+{
+   wl_list_remove(&fade->animation.link);
+   wl_list_remove(&fade->listener.link);
+   fade->surface->geometry.dirty = 1;
should we set the surface->alpha to 255 explicitly here? It seems that 
weston_spring_done() may not guarantee that spring.current > 1.0 when done.

+   if (fade->done)
+   fade->done(fade, fade->data);
+   free(fade);
+}
+




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] shell: Fix Bug 48906

[Alex Wu]

于 2012/4/27 9:55, yan.w...@linux.intel.com 写道:

From: Alex Wu

Remove rotation when entering fullscreen and restore rotation when
exiting fullscreen.
---
  src/shell.c |   14 ++
  1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/src/shell.c b/src/shell.c
index 9c844b5..6654167 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -118,6 +118,7 @@ struct shell_surface {
enum shell_surface_type type;
int32_t saved_x, saved_y;
bool saved_position_valid;
+   bool saved_rotation_valid;
int unresponsive;

struct {
@@ -663,6 +664,11 @@ shell_unset_fullscreen(struct shell_surface *shsurf)
shsurf->force_configure = 1;
weston_surface_set_position(shsurf->surface,
shsurf->saved_x, shsurf->saved_y);
+   if (shsurf->saved_rotation_valid) {
+   wl_list_insert(&shsurf->surface->geometry.transformation_list,
+   &shsurf->rotation.transform.link);
+   shsurf->saved_rotation_valid = false;
+   }
  }

  static int
@@ -950,6 +956,13 @@ shell_surface_set_fullscreen(struct wl_client
*client,
if (weston_surface_is_mapped(es))
shsurf->force_configure = 1;

+   if (!wl_list_empty(&shsurf->rotation.transform.link)) {
+   wl_list_remove(&shsurf->rotation.transform.link);
+   wl_list_init(&shsurf->rotation.transform.link);
+   shsurf->surface->geometry.dirty = 1;
+   shsurf->saved_rotation_valid = true;
+   }
+
wl_shell_surface_send_configure(&shsurf->resource, 0,
shsurf->output->current->width,
shsurf->output->current->height);
@@ -1176,6 +1189,7 @@ create_shell_surface(void *shell, struct
weston_surface *surface,
shsurf->unresponsive_animation.fading_in = 0;
shsurf->unresponsive_animation.current.frame = unresponsive_fade_frame;
shsurf->saved_position_valid = false;
+   shsurf->saved_rotation_valid = false;
shsurf->surface = surface;
shsurf->fullscreen.type = WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT;
shsurf->fullscreen.framerate = 0;
--
1.7.5.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


So far, saved_rotation_valid seems to be used in fullscreen mode only.
Need it record rotation state in the other non-fullscreen modes?


Yes, we can put the fixes in another patch after this one applied.



Thanks,
Yan Wang
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PULL weston] simple fixes

[Alex Wu]

于 2012/4/27 14:56, yan.w...@linux.intel.com 写道:

On Fri, Apr 27, 2012 at 8:09 AM,  wrote:

On Thu, 26 Apr 2012 19:42:52 -0700 (PDT)
yan.w...@linux.intel.com wrote:


http://cgit.collabora.com/git/user/pq/wayland-demos.git/log/?h=simple-fixes

...

About "simple-shm: render meaningful diagnostics", Because
paint_pixels
process pixels one by one, the following may be better:
time/32 ->  time>>5
time/64 ->  time>>6
time/16 ->  time>>4

You're saying the compiler does not automatically do that? Dang.
I thought it would if given the chance by using nice constant divisors.

Right, I didn't pay too much attention to performance, it is a debug
app after all. Can be optimised if someone has trouble with it.


Thanks,
pq


Yes. Current popular compilers may do this optimization. But ">>" may be
better. Just suggestion.

IINM the compiler will produce identical output using bitshift and
division when it's trivial to optimize away the division as in the
above case. IMHO using bitshift in these situations just adds
confusion if the purpose of the expression actually was an arithmetic
division.

Jonas


Could you please explain what are IINM and IMHO? Very thanks.


google gives that:

IINM :  If I'm Not Mistaken
IMHO :  In my humble opinion




Yan Wang

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston on Android - First light

[Alex Wu]

于 2012/4/27 20:56, Pekka Paalanen 写道:

Hi all,

I am happy to announce the first step towards a Wayland stack on
Android: simple-shm runs with Weston on a Galaxy Nexus!

The whole story, a picture, and a video:
http://ppaalanen.blogspot.com/2012/04/first-light-from-weston-on-android.html


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



That is so cool.
Is it possible to make a wayland backend for Android window system?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Migration guide?

[Alex Wu]

于 2012/5/7 4:30, Gregory Merchan 写道:

Hi,

I looking for a migration guide from X11 to Wayland. Most of my Google
search results are real estate listings for properties with windows in
Wayland, MA.

I have just a few things I hope someone will help me with:

1. The X property mechanism was generic, so we could have ICCCM, MWM,
EWMH, etc. properties without changing the X server. Will Wayland also
have such a generic mechanism?

2. Was the work requested in this message ever done?
http://lists.freedesktop.org/archives/wayland-devel/2010-November/000270.html
. (I could work on this maybe later this month, if it's not done.)

3. X11 famously abided by the rule of determining "mechanism, not
policy". Is there a similar rule for Wayland?

4. I'm concerned about the implications of this message:
http://lists.freedesktop.org/archives/wayland-devel/2012-January/001845.html
. It looks like policy was being written into Wayland, but maybe that
discussion was about Weston?


My understanding is that Wayland combines the display server, the window 
manager and the compositor in one process and thus, must provide an 
functionality provided by these processes. The behavior of display 
server is generic and suitable for "mechanism, not policy", but for the 
compositor and window manager, writting some policies into them is 
accepted and unavoidable. Correct me if

I made some misunderstanding.



Thanks,
Greg
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland on Embedded

[Alex Bradbury]

On 8 May 2012 11:24, Pekka Paalanen  wrote:
> If you can get a GL ES 2 context by EGL on X on your platform, then I
> guess it could work. If your system does not use Mesa for 3D drivers,
> then you won't get GL support for Wayland clients.

Pekka is being modest and not pointing to his very useful summary of
the requirements of Wayland on the platform's EGL/GLES stack
http://ppaalanen.blogspot.co.uk/2012/03/what-does-egl-do-in-wayland-stack.html

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: GTK Ubuntu Precise packaging success

[Alex Wu]

Hi darxus,
I installed your PPA on my ubuntu 12.04 desktop and followed your 
directions on https://launchpad.net/~darxus/+archive/wayland-gtk to run 
the gtk apps you listed both on native weston and weston as X11 client. 
I would like to share some information of my trying.


1.  gtk apps will crash due to invoke gdk_x11_* functions in 
libcanberra-gtk3-module which is a sound event wrapper lib for gtk3. so 
I removed this package.


2. Should setuid for weston like this:
 sudo chown root /usr/bin/weston
 sudo chmod +s /usr/bin/weston

3. Each time launched weston, should make the sockect accessible for 
clients:

sudo chmod ugo+rw /tmp/wayland*
I noticed that 2 and 3 has been mentioned in this thread, but 
adding them into your directions may make thing easier.


4. For gnome-terminal, gedit and rhythmbox,  should launch a session bus 
and export the DBUS_SESSION_BUS_ADDRESS. When run app under unity, 
DBUS_SESSION_BUS_ADDRESS is already their.  when  run app in fullscreen 
weston (launched in VT), should export DBUS_SESSION_BUS_ADDRESS manually.


5. brasero can not run, and no useful log printed.


? 2012/4/18 23:07, dar...@chaosreigns.com ??:

On 04/18, dar...@chaosreigns.com wrote:

When I tried using the Ubuntu GTK+ 3.4.1 source and only
applying the patches to default to X11 output before Wayland
(https://bugzilla.gnome.org/show_bug.cgi?id=674102) and remove the
cairo-gl dependency (https://bugzilla.gnome.org/show_bug.cgi?id=672361),
all applications segfault when I attempt to run them through Wayland.
That PPA is here: https://launchpad.net/~darxus/+archive/wayland-gtk

It turns out this one works fine, after you put
"export LIBOVERLAY_SCROLLBAR=0" in your ~/.bashrc .
Thanks to seb128.

These packages should be quite clean, since they're just the Ubuntu
packages plus two patch sets (default to X before Wayland, remove cairo-gl
dependency) and adding the two build flags to enable the Wayland backend
(without disabling the X backend), both pulled from GTK git master.
They're also not showing the graphical glitching I was getting with the
packages based on GTK git master.

Bonus, GTK themes are working now, so GTK applications are looking much
nicer in Wayland.


Keep in mind it's entirely possible this will break stuff.  But using it
works something like this:


Install Ubuntu Precise.

echo "export LIBOVERLAY_SCROLLBAR=0">>  ~/.bashrc
sudo apt-get install ppa-purge
sudo apt-get update&&  sudo apt-get upgrade
sudo apt-add-repository ppa:darxus/wayland-gtk
sudo apt-get update&&  sudo apt-get upgrade # should only upgrade gtk packages

Reboot.

In one gnome-terminal, run:

export XDG_RUNTIME_DIR=/tmp # Put in ~/.bashrc?
weston

In another gnome-terminal, run:

export XDG_RUNTIME_DIR=/tmp
export GDK_BACKEND=wayland
gnome-calculator&
gnome-terminal&
file-roller&
charmap&
gnome-sudoku&
gwibber&
transmission-gtk&
brasero&
gnome-sound-recorder&
baobab&
gedit&
rhythmbox&
gnome-system-monitor&


To revert all changes:

sudo ppa-purge ppa:darxus/wayland-gtk # Nice 'n tidy.


Please do let me know what GTK applications you find do and don't work, so
I can update http://www.chaosreigns.com/wayland/works/

And, of course, let me know how the packages work.


I have it on good authority that this stuff will never make it into Ubuntu
Precise, not even as an SRU (Stable Release Update).  But I can't imagine
why it wouldn't make the October Ubuntu release.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: GTK Ubuntu Precise packaging success

[Alex Wu]

? 2012/5/8 22:42, dar...@chaosreigns.com ??:

On 05/08, Alex Wu wrote:

Hi darxus,
I installed your PPA on my ubuntu 12.04 desktop and followed your
directions on [1]https://launchpad.net/~darxus/+archive/wayland-gtk to run
the gtk apps you listed both on native weston and weston as X11 client. I
would like to share some information of my trying.

Thanks.


1.  gtk apps will crash due to invoke gdk_x11_* functions in
libcanberra-gtk3-module which is a sound event wrapper lib for gtk3. so I
removed this package.

Please open a bug for this by running "ubuntu-bug libcanberra-gtk3-module",
similar to these, tagged "wayland":


I tryed to fire a bug by "ubuntu-bug libcanberra-gtk3-module ", but got 
"Network problem". So I open a 
bug(https://bugs.launchpad.net/ubuntu/+source/apport/+bug/996904) for 
apport first. I also reported the libcanberra bug 
(https://bugs.launchpad.net/ubuntu/+source/libcanberra/+bug/996917) 
directly through the webpage.




https://launchpad.net/bugs/984914
https://launchpad.net/bugs/994091

I haven't seen this, which application or applications produced it?


This bug is only produced on weston as X11 client mode, all applications 
on your list crash. I guess that in the unity env, there is a daemon 
which use libcanberra to provide sound theme for apps. While in the 
weston desktop, no sound deamon launched and hence no crash. Anyway, 
libcanberra-gtk3-module has direct dependency on gdk_x11_**, that should 
be removed.





2. Should setuid for weston like this:
 sudo chown root /usr/bin/weston
 sudo chmod +s /usr/bin/weston

For running outside of X, yes, I should add that.


3. Each time launched weston, should make the sockect accessible for
clients:
sudo chmod ugo+rw /tmp/wayland*
I noticed that 2 and 3 has been mentioned in this thread, but adding
them into your directions may make thing easier.

When running with weston SUID root, yeah, that's a good idea too.


4. For gnome-terminal, gedit and rhythmbox,  should launch a session bus
and export the DBUS_SESSION_BUS_ADDRESS. When run app under unity,
DBUS_SESSION_BUS_ADDRESS is already their.  when  run app in fullscreen
weston (launched in VT), should export DBUS_SESSION_BUS_ADDRESS manually.

From: http://www.chaosreigns.com/wayland/works/
'To get gnome-terminal to work outside of windows, you probably want to
launch weston as "dbus-launch ~/install/bin/weston", and run gnome-terminal
as "gnome-terminal --disable-factory".'

I suspect running weston through dbus-launch has a similar effect, but I


Yes, If the terminal running the app can inherit the 
DBUS_SESSION_BUS_ADDRESS env from weston, for example, clicking the 
terminal icon on the weston panel will launch a weson-terminal which 
inherits the DBUS_SESSION_BUS_ADDRESS env from weston. But if the 
wesont-terminal is launched from a remote terminal, for example, I used 
to launch app from a putty terminal, that breaks it.



bet running weston SUID root breaks it.


Do you mean  doing "sudo chown root /usr/bin/weston" and "sudo chmod +s 
/usr/bin/weston" will break it? According to my testing, the answer is 
"No".

My steps are:
Open VT
sudo chown root /usr/bin/weston
sudo chmod +s /usr/bin/weston
export XDG_RUNTIME_DIR=/tmp
export LIBOVERLAY_SCROLLBAR=0
dbus-launch /usr/bin/weston
clicked terminal icon on the weston panel to launch weston-terminal

#In the weston-terminal
export GDK_BACKEND=wayland
sudo chmod ugo+rw /tmp/wayland*
gnome-terminal & # that works fine
...




5. brasero can not run, and no useful log printed.

What exactly did you see?  Did it run, without crashing, but not display
any output?  I've seen that sometimes, other times it works.  Occasionally
it doesn't display until... I'm not sure what happens.


I opened the wayland debug and found that brasero already launched 
normally ,but not display any output. The input event are normal.


I found another issue that in the native weston mode,  rhythmbox will 
crash in libmmkeys.so which invokes libX11.so. But in the weston as X11 
client mode, it works fine. It seems that  rhythmbox will request dbus 
service  from gnome-settings-daemon, if the service not privided,  
rhythmbox will invoke X11 api and crash. Where should I report this bug? 
rhythmbox community or ubuntu?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston running on Ubuntu 11.10 : Query on libEGL debug output

[Alex Wu]

? 2012/5/22 1:40, souvik.da...@wipro.com ??:



Script done on Monday 21 May 2012 07:05:43 PM IST

> From the above log, it seems that libEGL debug logs are occuring twice.

One set with
libEGL debug: Native platform type: drm (autodetected)
..
and other set with
libEGL debug: Native platform type: wayland (autodetected)
..

Can some one please explain why are these sets getting repeated? I have built 
MESA with backend support for wayland and egl.
May be I am missing some fundamental concept here.


In your case, both client side and server side will use egl. For client 
side, it will use  wayland egl which wraps the buffer sharing mechanism 
between client and server. For server side, use drm egl to create the 
EGLImage from wl_buffer. The EGLImage then will be used by the 
compositor as a texture or passed to the modesetting code to use as an 
overlay plane. For details of EGL in wayland, you can ref


 * http://ppaalanen.blogspot.com/2012/03/what-does-egl-do-in-wayland-stack.html

 * Section "Hardware Enabling for Wayland" in
   http://wayland.freedesktop.org/architecture.html




Thanks and Regards,
Souvik






Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: gtk3-demo-application not running in gtk with Wayland back end

[Alex Wu]

Hi,
What deos the setWaylandEnv.sh do? Please attached the detailed info about
1. version or commit info of wayland, weston and gtk3.
2. building opts for gtk3.
3. steps to reproduce.

The more detailed info the more we may helps.

于 2012/5/29 12:19, suranjana.bhattacha...@wipro.com 写道:
> Thanks a lot for the help!
> I have tried to run gnome-calculator on terminal (CTRL+ALT+F1) but it failed 
> with following error. Please look into the following error description . 
>
>
>
> couldn't open /home/wipro/.config/weston-desktop-shell.ini
>
> (process:29849): GLib-GIO-ERROR **: No GSettings schemas are installed on the 
> system
> ./setWaylandEnv.sh: line 40: 29849 Trace/breakpoint trap   
> /usr/bin/gnome-calculator
> wipro@wipro-WSG52M05W7-0047:~$ disconnect from client 0x9b76830
> read error: No such file or directory
> libEGL debug: Display 0x8083c38 is destroyed with resources
> libEGL debug: Display 0x9a9bcd8 is destroyed with resources
>
>
> Regards,
> Suranjana
>
>
>
>
> 
> From: Alex Wu [zhiwen...@linux.intel.com]
> Sent: Tuesday, May 29, 2012 7:48 AM
> To: Suranjana Bhattacharya (WT01 - Manufacturing & Hi Tech)
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: gtk3-demo-application not running in gtk with Wayland back end
>
> Due to some gtk application has dependency which may stop it running on 
> wayland, I suggest to run a simple gtk3 application like gnome-calculator to 
> verify that your gtk3 and weston works well. You can ref 
> https://launchpad.net/~darxus/+archive/wayland-gtk<https://launchpad.net/%7Edarxus/+archive/wayland-gtk>
>  to setup necesary env.
>
> 于 2012/5/28 16:59, 
> suranjana.bhattacha...@wipro.com<mailto:suranjana.bhattacha...@wipro.com> 写道:
>
> Hello,
>
>
>
> I am new in Wayland development. I have built Wayland in a system having 
> Ubuntu 11.10. I have also built gtk+3.0 with Wayland backend.
>
> I can successfully run Weston on terminal (CTRL+ALT+F1). But when I try to 
> run gtk3-demo-application, it is not running and giving following errors.
>
>
>
> 
>
> 
>
>
>
> (gtk3-demo-application:24881): GLib-GIO-ERROR **: Settings schema 
> 'org.gtk.Demo' is not installed
>
>
>
> disconnect from client 0x9251fa0
>
> ./setWaylandEnv.sh: line 38: 24881 Trace/breakpoint trap   
> $WLD/bin/gtk3-demo-application
>
> wipro@wipro-WSG52M05W7-0047:~$ disconnect from client 0x9227830 read error: 
> No such file or directory libEGL debug: Display 0x890ac38 is destroyed with 
> resources libEGL debug: Display 0x914ccd8 is destroyed with resources
>
>
>
>
>
> Thanks & Regards,
>
> Suranjana Bhattacharya
>
>
>
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should 
> check this email and any attachments for the presence of viruses. The company 
> accepts no liability for any damage caused by any virus transmitted by this 
> email.
>
> www.wipro.com<http://www.wipro.com>
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
> Please do not print this email unless it is absolutely necessary. 
>
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. 
>
> WARNING: Computer viruses can be transmitted via email. The recipient should 
> check this email and any attachments for the presence of viruses. The company 
> accepts no liability for any damage caused by any virus transmitted by this 
> email. 
>
> www.wipro.com
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: gtk3-demo-application not running in gtk with Wayland back end

[Alex Wu]

Due to some gtk application has dependency which may stop it running on 
wayland, I suggest to run a simple gtk3 application like 
gnome-calculator to verify that your gtk3 and weston works well. You can 
ref https://launchpad.net/~darxus/+archive/wayland-gtk 
 to setup necesary 
env.


? 2012/5/28 16:59, suranjana.bhattacha...@wipro.com ??:


Hello,

I am new in Wayland development. I have built Wayland in a system 
having Ubuntu 11.10. I have also built gtk+3.0 with Wayland backend.


I can successfully run Weston on terminal (CTRL+ALT+F1). But when I 
try to run gtk3-demo-application, it is not running and giving 
following errors.






(gtk3-demo-application:24881): GLib-GIO-ERROR **: Settings schema 
'org.gtk.Demo' is not installed


disconnect from client 0x9251fa0

./setWaylandEnv.sh: line 38: 24881 Trace/breakpoint trap   
$WLD/bin/gtk3-demo-application


wipro@wipro-WSG52M05W7-0047:~$ disconnect from client 0x9227830 read 
error: No such file or directory libEGL debug: Display 0x890ac38 is 
destroyed with resources libEGL debug: Display 0x914ccd8 is destroyed 
with resources


Thanks & Regards,

Suranjana Bhattacharya

*Please do not print this email unless it is absolutely necessary. *

The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately and destroy all copies of this message and any attachments.


WARNING: Computer viruses can be transmitted via email. The recipient 
should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any 
virus transmitted by this email.


www.wipro.com



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] VTs for multiple seats

[Alex Deucher]

On Wed, Jul 4, 2012 at 2:13 PM, David Herrmann
 wrote:
> Hi guys
>
> (CC'ing systemd-ML as they proved to be very helpful and interested in this 
> ;))
>
> I am currently working on kmscon and am planning on writing some
> user-space VT logic similar to CONFIG_VT in the kernel. The idea is to
> have multiple virtual terminals for each seat. systemd-logind
> currently associates the kernel VTs tty1-ttyX to seat0 only and all
> other seats are not multi-session capable. Moreover, there is no easy
> and simple way to make the kernel VTs multi-seat capable. Therefore,
> we need another approach.
>
> I was talking to Lennart about this and there is definitely a need to
> fix this. However, I have multiple ideas for that and I was wondering
> whether you want to comment on this, too, as I saw that one of your
> initial proposals for wayland was to have a system wide compositor
> which handles all video input and as such would always be active on a
> seat (see proposal 3. below).

There's also Dave's render node work which has been picked up by Ilija:
http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html
The basic idea is that you can allocate display resources to separate
drm device nodes and then run separate userspace stacks on top of each
one or submit rendering/compute commands to a render-only node.

Alex
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] ecore_wayland: Add Copy and Paste support

[Alex Wu]

于 2012/7/26 18:41, Daniel Stone 写道:

Hi,

On 26 July 2012 11:18,  wrote:

Add a global Ecore_Wl_Dnd object to handle copy and paste. I think
it is more appropriate to name this struct Ecore_Wl_Selection, which
is responsible for both dnd and cnp. This patch just cover the copy
and paste and not support "clear clipboard", due to wayland has no
way to do that.

Actually it does - the data source you pass to set_selection can be
NULL, which will remove the selection offer and effectively clear the
clipboard.
I don't think so. The weston has a clipboard object which will cache the 
contents of selection and create a data source internally. If 
set_selection set a NULL data source, the clipboard will call 
wl_seat_set_selection() to take over the data source ownership and 
notify the client with selection and offer. See 
clipboard.c::clipboard_set_selection().


But, I should say "weston has no way to do that" instead of wayland.


Similarly, you have to be prepared to receive a NULL data source from
the selection event.

I think you mean NULL data offer.



Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Bug: wayland performance halfed when running es2gears_wayland at fedora17

[Alex Wu]

Hi all,
We are doing some performance profiling on wayland using es2gears and
found a issue that mesa-deoms/src/egl/opengles2/es2gears_wayland
(running drm backend) on platform-a (sandybridge, fedora 17 with kernel
version 3.5) has 30fps but es2gears_x11 60fps, but on platform-b
(sandybridge, Ubuntu 12.04 with kernel version 3.2) the fps is 60fps
both for es2gears_wayland and es2gears_x11.

Two platform has the same version status:

drm: 6fa2b29d226306870eebe93afb2106ca7d79569b
Mesa: 4e087de51ad0e7ba4a7199d3664e1d096f8dc510
demos: 7ba23583b237d4c07823006ef35dca434ebd5759
Wayland: 915cdeee29291332384c4cf9ee67758e19500131
weston: cd8cdccdd375058ae467974af5831a507ed016f5


I debugged on platform-a and found that drmModePageFlip in
weston/src/compositor-drm.c has calling rate of 30/s. If not set the
EGL_DEPTH_SIZE attribute on EGLContext in
mesa-deoms/src/egl/eglut/eglut.c, the fps of es2gears_wayland gets 60 fps.

we also installed ubuntu 12.04(with 3.2 kernel) on platform-a, and build
all the packages needed, the es2gears_wayland got 60fps.

So, my question is why wayland performance halfed when running
es2gears_wayland at fedora17 (kernel 3.5)?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v6 42/44] drm/colorop: Add 3D LUT supports to color pipeline

[Alex Hung]

On 10/13/24 09:58, Simon Ser wrote:

On Thursday, October 3rd, 2024 at 22:01, Harry Wentland 
 wrote:


From: Alex Hung 

It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.

1. new drm_colorop_type: DRM_COLOROP_3D_LUT.
2. 3D LUT modes define hardware capabilities to userspace applications.
3. mode index points to current 3D LUT mode in lut_3d_modes.


Do we really need all of this complexity here?

User-space needs to copy over its 3D LUT to the KMS blob. Kernel needs to
copy from the KMS blob when programming hardware. Why do we need a list of
different modes with negotiation?

I've heard that some of this complexity has been introduced to add in the
future BO-backed LUTs. That would be a nice addition, but it's not here
right now, so how can we design for that case when we haven't actually tried
implementing it and made sure it actually works in practice?

It would be easy to introduce "modes" (or something different) when the
BO-based 3D LUT uAPI is introduced. There are many ways to handle backwards
compatibility: new properties can have their defaults set to the previously
fixed format/swizzle/etc, a new colorop can be introduced if there are
too many conflicts, and worst case new functionality can be gated behind a
DRM cap (although I don't think we'd need to resort to this here).

I'd recommend just having one fixed supported format, like we have for
1D LUTs. We can have a read-only props for the size and the color depth,
as well as a read-write prop for the data blob.



That's a good point. I will simplify DRM_COLOROP_3D_LUT implementation 
and remove 3D LUT mode. It can be used for future BO-based 3D LUT if 
necessary


In summary:

The attributes to be kept now: lut_size, interpolation and color_depth. 
The rests can be fixed and documented for userspace.



diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5ef87cb5b242..290c2e32f692 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -913,6 +913,90 @@ enum drm_colorop_type {
 * property.
 */
DRM_COLOROP_MULTIPLIER,
+   /**
+* @DRM_COLOROP_3D_LUT:
+*
+* A 3D LUT of &drm_color_lut entries,
+* packed into a blob via the DATA property. The driver's expected
+* LUT size is advertised via the SIZE property.
+*/
+   DRM_COLOROP_3D_LUT,


User-space docs are missing many details I believe.


+};
+
+/**
+ * enum drm_colorop_lut3d_interpolation_type - type of 3DLUT interpolation
+ *
+ */
+enum drm_colorop_lut3d_interpolation_type {
+   /**
+* @DRM_COLOROP_LUT3D_INTERPOLATION_TETRAHEDRAL:
+*
+* Tetrahedral 3DLUT interpolation
+*/
+   DRM_COLOROP_LUT3D_INTERPOLATION_TETRAHEDRAL,
+};
+
+/**
+ * enum drm_colorop_lut3d_traversal_order - traversal order of the 3D LUT
+ *
+ * This enum describes the order of traversal of 3DLUT elements.
+ */
+enum drm_colorop_lut3d_traversal_order {
+   /**
+* @DRM_COLOROP_LUT3D_TRAVERSAL_RGB:
+*
+* the LUT elements are traversed like so:
+*   for R in range 0..n
+* for G in range 0..n
+*   for B in range 0..n
+* color = lut3d[R][G][B]
+*/
+   DRM_COLOROP_LUT3D_TRAVERSAL_RGB,
+   /**
+* @DRM_COLOROP_LUT3D_TRAVERSAL_BGR:
+*
+* the LUT elements are traversed like so:
+*   for R in range 0..n
+* for G in range 0..n
+*   for B in range 0..n
+* color = lut3d[B][G][R]
+*/
+   DRM_COLOROP_LUT3D_TRAVERSAL_BGR,
+};
+
+/**
+ * struct drm_mode_3dlut_mode - 3D LUT mode
+ *
+ * The mode describes the supported and selected format of a 3DLUT.
+ */
+struct drm_mode_3dlut_mode {
+   /**
+* @lut_size: 3D LUT size - can be 9, 17 or 33
+*/
+   __u16 lut_size;


Are "9, 17 or 33" just example values? Or does the kernel actually guarantee
that the advertised size can never be something else? It doesn't seem like
there is a check, and enforcing it would hinder extensibility (adding new
values would be a breaking uAPI change).


+   /**
+* @lut_stride: dimensions of 3D LUT. Must be larger than lut_size
+*/
+   __u16 lut_stride[3];


It sounds a bit weird to have the driver dictate the stride which must be used.
Usually user-space picks and sends the stride to the driver.


+   /**
+* @interpolation: interpolation algorithm for 3D LUT. See 
drm_colorop_lut3d_interpolation_type
+*/
+   __u16 interpolation;
+   /**
+* @color_depth: color depth - can be 8, 10 or 12
+*/
+   __u16 color_depth;


Ditto: reading these docs, user-space might not handle any other value.

It would be nice to better explain what this means exactly. Are the output
color values trunca

[V7 24/45] drm/amd/display: Add bypass COLOR PIPELINE

[Alex Hung]

From: Harry Wentland 

Add the default Bypass pipeline and ensure it passes the
kms_colorop test plane-XR30-XR30-bypass.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 495e3cd70426..22ff9a31b592 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1756,6 +1756,20 @@ dm_atomic_plane_get_property(struct drm_plane *plane,
 }
 #endif
 
+#define MAX_COLOR_PIPELINES 5
+
+static int
+dm_plane_init_colorops(struct drm_plane *plane)
+{
+   struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
+   int len = 0;
+
+   /* Create COLOR_PIPELINE property and attach */
+   drm_plane_create_color_pipeline_property(plane, pipelines, len);
+
+   return 0;
+}
+
 static const struct drm_plane_funcs dm_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -1859,7 +1873,12 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager 
*dm,
 
 #ifdef AMD_PRIVATE_COLOR
dm_atomic_plane_attach_color_mgmt_properties(dm, plane);
+#else
+   res = dm_plane_init_colorops(plane);
+   if (res)
+   return res;
 #endif
+
/* Create (reset) the plane state */
if (plane->funcs->reset)
plane->funcs->reset(plane);
-- 
2.43.0

[V7 25/45] drm/amd/display: Skip color pipeline initialization for cursor plane

[Alex Hung]

cursor plane does not need to have color pipeline.

Signed-off-by: Alex Hung 
---
v7:
 - Add a commit messages

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 22ff9a31b592..1bfb9f340c24 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1764,6 +1764,9 @@ dm_plane_init_colorops(struct drm_plane *plane)
struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
int len = 0;
 
+   if (plane->type == DRM_PLANE_TYPE_CURSOR)
+   return 0;
+
/* Create COLOR_PIPELINE property and attach */
drm_plane_create_color_pipeline_property(plane, pipelines, len);
 
-- 
2.43.0

[V7 21/45] drm/colorop: pass plane_color_pipeline client cap to atomic check

[Alex Hung]

From: Harry Wentland 

Drivers will need to know whether an atomic check/commit
originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
so they can ignore deprecated properties, like COLOR_ENCODING
and COLOR_RANGE.

Pass the plane_color_pipeline bit to drm_atomic_state.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---

v5:
 - Fix kernel docs

 drivers/gpu/drm/drm_atomic_uapi.c |  1 +
 include/drm/drm_atomic.h  | 18 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7bc4978e5441..a3e1fcad47ad 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1572,6 +1572,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
state->acquire_ctx = &ctx;
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
+   state->plane_color_pipeline = file_priv->plane_color_pipeline;
 
 retry:
copied_objs = 0;
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index feef16fd89e2..f3afc1ef3f81 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -414,6 +414,24 @@ struct drm_atomic_state {
 */
bool duplicated : 1;
 
+   /**
+* @plane_color_pipeline:
+*
+* Indicates whether this atomic state originated with a client that
+* set the DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE.
+*
+* Drivers and helper functions should use this to ignore legacy
+* properties that are incompatible with the drm_plane COLOR_PIPELINE
+* behavior, such as:
+*
+*  - COLOR_RANGE
+*  - COLOR_ENCODING
+*
+* or any other driver-specific properties that might affect pixel
+* values.
+*/
+   bool plane_color_pipeline : 1;
+
/**
 * @colorops:
 *
-- 
2.43.0

[V7 22/45] drm/colorop: define a new macro for_each_new_colorop_in_state

[Alex Hung]

Create a new macro for_each_new_colorop_in_state to access new
drm_colorop_state updated from uapi.

Signed-off-by: Alex Hung 
---
 include/drm/drm_atomic.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index f3afc1ef3f81..c926f1924edc 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -1035,6 +1035,26 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
  (new_colorop_state) = 
(__state)->colorops[__i].new_state, 1))
 
 
+/**
+ * for_each_new_colorop_in_state - iterate over all colorops in an atomic 
update
+ * @__state: &struct drm_atomic_state pointer
+ * @colorop: &struct drm_colorop iteration cursor
+ * @new_colorop_state: &struct drm_colorop_state iteration cursor for the new 
state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all colorops in an atomic update, tracking new state. 
This is
+ * useful is useful in places where the state delta needs to be considered, for
+ * example in atomic check functions.
+ */
+#define for_each_new_colorop_in_state(__state, colorop, new_colorop_state, 
__i) \
+   for ((__i) = 0; \
+(__i) < (__state)->dev->mode_config.num_colorop;   \
+(__i)++)   \
+   for_each_if ((__state)->colorops[__i].ptr &&\
+((colorop) = (__state)->colorops[__i].ptr, \
+ (void)(colorop) /* Only to avoid 
unused-but-set-variable warning */, \
+ (new_colorop_state) = 
(__state)->colorops[__i].new_state, 1))
+
 /**
  * for_each_oldnew_plane_in_state - iterate over all planes in an atomic update
  * @__state: &struct drm_atomic_state pointer
-- 
2.43.0

[V7 33/45] drm/colorop: Add 1D Curve Custom LUT type

[Alex Hung]

We've previously introduced DRM_COLOROP_1D_CURVE for
pre-defined 1D curves. But we also have HW that supports
custom curves and userspace needs the ability to pass
custom curves, aka LUTs.

This patch introduces a new colorop type, called
DRM_COLOROP_1D_LUT that provides a SIZE property which
is used by a driver to advertise the supported SIZE
of the LUT, as well as a DATA property which userspace
uses to set the LUT.

DATA and size function in the same way as current drm_crtc
GAMMA and DEGAMMA LUTs.

Signed-off-by: Alex Hung 
Co-developed-by: Harry Wentland 
Signed-off-by: Harry Wentland 
---
v7:
 - Change "size" to "lut_size" (this affects multiple following commits)
 - Move "lut_size" from drm_colorop_state to drm_colorop
 - Modify other files accordingly (i.e. from drm_colorop_state->size
   to drm_colorop->lut_size)

v5:
 - Add kernel doc
 - Define SIZE in similar manner to GAMMA_SIZE on drm_crtc (Melissa)

 drivers/gpu/drm/drm_atomic.c  |  4 +++
 drivers/gpu/drm/drm_atomic_uapi.c |  5 
 drivers/gpu/drm/drm_colorop.c | 47 +--
 include/drm/drm_colorop.h | 16 +++
 include/uapi/drm/drm_mode.h   |  9 ++
 5 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c58663327e6b..b7a05132ee01 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -793,6 +793,10 @@ static void drm_atomic_colorop_print_state(struct 
drm_printer *p,
drm_printf(p, "\tcurve_1d_type=%s\n",
   
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
break;
+   case DRM_COLOROP_1D_LUT:
+   drm_printf(p, "\tsize=%d\n", colorop->lut_size);
+   drm_printf(p, "\tdata blob id=%d\n", state->data ? 
state->data->base.id : 0);
+   break;
case DRM_COLOROP_CTM_3X4:
drm_printf(p, "\tdata blob id=%d\n", state->data ? 
state->data->base.id : 0);
break;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index a3e1fcad47ad..4744c12e429d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -701,6 +701,9 @@ static int drm_atomic_color_set_data_property(struct 
drm_colorop *colorop,
bool replaced = false;
 
switch (colorop->type) {
+   case DRM_COLOROP_1D_LUT:
+   size = colorop->lut_size * sizeof(struct drm_color_lut);
+   break;
case DRM_COLOROP_CTM_3X4:
size = sizeof(struct drm_color_ctm_3x4);
break;
@@ -750,6 +753,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
+   } else if (property == colorop->lut_size_property) {
+   *val = colorop->lut_size;
} else if (property == colorop->data_property) {
*val = (state->data) ? state->data->base.id : 0;
} else {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 665b23900cc0..e6dea2713490 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -64,6 +64,7 @@
 
 static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
+   { DRM_COLOROP_1D_LUT, "1D Curve Custom LUT" },
{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"}
 };
 
@@ -219,11 +220,52 @@ static int drm_colorop_create_data_prop(struct drm_device 
*dev, struct drm_color
 
colorop->data_property = prop;
drm_object_attach_property(&colorop->base,
-   colorop->data_property,
-   0);
+  colorop->data_property,
+  0);
+
+   return 0;
+}
+
+/**
+ * drm_colorop_curve_1d_lut_init - Initialize a DRM_COLOROP_1D_LUT
+ *
+ * @dev: DRM device
+ * @colorop: The drm_colorop object to initialize
+ * @plane: The associated drm_plane
+ * @lut_size: LUT size supported by driver
+ * @return zero on success, -E value on failure
+ */
+int drm_colorop_curve_1d_lut_init(struct drm_device *dev, struct drm_colorop 
*colorop,
+ struct drm_plane *plane, uint32_t lut_size)
+{
+   struct drm_property *prop;
+   int ret;
+
+   ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_1D_LUT);
+   if (ret)
+   return ret;
+
+   /* initialize 1D LUT only attribute */
+   /* LUT size */
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "SIZE",
+0, U

[V7 34/45] drm/amd/display: add shaper and blend colorops for 1D Curve Custom LUT

[Alex Hung]

This patch adds colorops for custom 1D LUTs in the SHAPER and
BLND HW blocks.

With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut

The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 1D curve colorop
3. 1D LUT
4. 1D curve colorop
5. 1D LUT

The 1D curve colorops support sRGB, BT2020, and PQ scaled to 125.0.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Initialize uint32_t blend_size = 0 by default (kernel test robot)
 - Modify state->size to colorop->lut_size

 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 166 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c |  32 
 2 files changed, 120 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 1765402bc122..0bea52eede39 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1211,38 +1211,6 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state 
*plane_state,
return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
 }
 
-static int
-__set_colorop_in_shaper_1d_curve(struct dc_plane_state *dc_plane_state,
-  struct drm_colorop_state *colorop_state)
-{
-   struct dc_transfer_func *tf = &dc_plane_state->in_shaper_func;
-   struct drm_colorop *colorop = colorop_state->colorop;
-   struct drm_device *drm = colorop->dev;
-
-   if (colorop->type != DRM_COLOROP_1D_CURVE)
-   return -EINVAL;
-
-   if (!(BIT(colorop_state->curve_1d_type) & 
amdgpu_dm_supported_shaper_tfs))
-   return -EINVAL;
-
-   if (colorop_state->bypass) {
-   tf->type = TF_TYPE_BYPASS;
-   tf->tf = TRANSFER_FUNCTION_LINEAR;
-   return 0;
-   }
-
-   drm_dbg(drm, "Shaper colorop with ID: %d\n", colorop->base.id);
-
-   if (colorop->type == DRM_COLOROP_1D_CURVE) {
-   tf->type = TF_TYPE_DISTRIBUTED_POINTS;
-   tf->tf = 
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
-   tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
-   return __set_output_tf(tf, 0, 0, false);
-   }
-
-   return -EINVAL;
-}
-
 static int
 __set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
  struct dc_plane_state *dc_plane_state,
@@ -1251,64 +1219,61 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state 
*plane_state,
struct drm_colorop *old_colorop;
struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
struct drm_atomic_state *state = plane_state->state;
+   enum dc_transfer_func_predefined default_tf = TRANSFER_FUNCTION_LINEAR;
+   struct dc_transfer_func *tf = &dc_plane_state->in_shaper_func;
+   const struct drm_color_lut *shaper_lut;
+   struct drm_device *dev = colorop->dev;
+   uint32_t shaper_size;
int i = 0;
 
+   /* 1D Curve - SHAPER TF */
old_colorop = colorop;
-
-   /* 2nd op: 1d curve - shaper */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
(BIT(new_colorop_state->curve_1d_type) & 
amdgpu_dm_supported_shaper_tfs)) {
colorop_state = new_colorop_state;
break;
}
-
-   if (new_colorop_state->colorop == old_colorop) {
-   colorop_state = new_colorop_state;
-   break;
-   }
}
 
-   if (!colorop_state)
-   return -EINVAL;
-
-   return __set_colorop_in_shaper_1d_curve(dc_plane_state, colorop_state);
-}
-
-
-static int
-__set_colorop_1d_curve_blend_tf_lut(struct dc_plane_state *dc_plane_state,
- struct drm_colorop_state *colorop_state)
-{
-
-   struct dc_transfer_func *tf = &dc_plane_state->blend_tf;
-   struct drm_colorop *colorop = colorop_state->colorop;
-   struct drm_device *drm = colorop->dev;
-   const struct drm_color_lut *blend_lut;
-   uint32_t blend_size = 0;
-
-   if (colorop->type != DRM_COLOROP_1D_CURVE)
-   return -EINVAL;
+   if (colorop_state && !colorop_state->bypass && colorop->type == 
DRM_COLOROP_1D_CURVE) {
+   drm_dbg(dev, "Shaper TF colorop with ID: %d\n", 
colorop->base.id);
+   tf->type = TF_TYPE_DISTRIBUTED_POINTS;
+   tf->tf = default_tf = 
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+   tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_

[V7 32/45] drm/amd/display: Add support for BT.709 and BT.2020 TFs

[Alex Hung]

From: Harry Wentland 

This adds support for the BT.709/BT.2020 transfer functions
on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.

With this change the following IGT subtests pass:
kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf
kms_colorop --run plane-XR30-XR30-bt2020_oetf

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c   | 11 ---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 10 +++---
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 63044e0296cb..1765402bc122 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -676,6 +676,9 @@ amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type 
tf)
case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
return TRANSFER_FUNCTION_SRGB;
+   case DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:
+   case DRM_COLOROP_1D_CURVE_BT2020_OETF:
+   return TRANSFER_FUNCTION_BT709;
case DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
case DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF:
return TRANSFER_FUNCTION_PQ;
@@ -1284,8 +1287,10 @@ __set_colorop_1d_curve_blend_tf_lut(struct 
dc_plane_state *dc_plane_state,
const struct drm_color_lut *blend_lut;
uint32_t blend_size = 0;
 
-   if (colorop->type != DRM_COLOROP_1D_CURVE &&
-   colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+   if (colorop->type != DRM_COLOROP_1D_CURVE)
+   return -EINVAL;
+
+   if (!(BIT(colorop_state->curve_1d_type) & amdgpu_dm_supported_blnd_tfs))
return -EINVAL;
 
if (colorop_state->bypass) {
@@ -1321,7 +1326,7 @@ __set_dm_plane_colorop_blend(struct drm_plane_state 
*plane_state,
/* 3nd op: 1d curve - blend */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
-   new_colorop_state->curve_1d_type == 
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+   (BIT(new_colorop_state->curve_1d_type) & 
amdgpu_dm_supported_blnd_tfs)) {
colorop_state = new_colorop_state;
break;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index a9d94018a207..ff5828a1e8cd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -33,14 +33,18 @@
 
 const u64 amdgpu_dm_supported_degam_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
-   BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF);
+   BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF);
 
 const u64 amdgpu_dm_supported_shaper_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
-   BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF);
+   BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
 
 const u64 amdgpu_dm_supported_blnd_tfs =
-   BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
+   BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF);
 
 #define MAX_COLOR_PIPELINE_OPS 10
 
-- 
2.43.0

[V7 40/45] drm/colorop: allow non-bypass colorops

[Alex Hung]

From: Harry Wentland 

Not all HW will be able to do bypass on all color
operations. Introduce an 'allow_bypass' boolean for
all colorop init functions and only create the BYPASS
property when it's true.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 22 +---
 drivers/gpu/drm/drm_atomic.c  |  3 +-
 drivers/gpu/drm/drm_colorop.c | 53 ---
 drivers/gpu/drm/vkms/vkms_colorop.c   |  8 +--
 include/drm/drm_colorop.h | 10 ++--
 5 files changed, 61 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 92c9f3fb0254..ec94ff887886 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -66,7 +66,9 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, 
amdgpu_dm_supported_degam_tfs);
+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane,
+   amdgpu_dm_supported_degam_tfs,
+   true);
if (ret)
goto cleanup;
 
@@ -83,7 +85,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_mult_init(dev, ops[i], plane);
+   ret = drm_colorop_mult_init(dev, ops[i], plane, true);
if (ret)
goto cleanup;
 
@@ -99,7 +101,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane);
+   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane, true);
if (ret)
goto cleanup;
 
@@ -115,7 +117,9 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, 
amdgpu_dm_supported_shaper_tfs);
+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane,
+   amdgpu_dm_supported_shaper_tfs,
+   true);
if (ret)
goto cleanup;
 
@@ -132,7 +136,8 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
}
 
ret = drm_colorop_curve_1d_lut_init(dev, ops[i], plane, 
MAX_COLOR_LUT_ENTRIES,
-   
DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR);
+   
DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR,
+   true);
if (ret)
goto cleanup;
 
@@ -148,7 +153,9 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, 
amdgpu_dm_supported_blnd_tfs);
+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane,
+   amdgpu_dm_supported_blnd_tfs,
+   true);
if (ret)
goto cleanup;
 
@@ -165,7 +172,8 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
}
 
ret = drm_colorop_curve_1d_lut_init(dev, ops[i], plane, 
MAX_COLOR_LUT_ENTRIES,
-   
DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR);
+   
DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR,
+   true);
if (ret)
goto cleanup;
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9a17fe11bcb3..88219b095d99 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -786,7 +786,8 @@ static void drm_atomic_colorop_print_state(struct 
drm_printer *p,
 
drm_printf(p, "colorop[%u]:\n", colorop->base.id);
drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
-   drm_printf(p, "\tbypass=%u\n", state->bypass);
+   if (colorop->bypass_property)
+   drm_printf(p, "\tbypass=%u\n", state->bypass);
 
switch (colorop->type) {
case DRM_COLOROP_1D_CURVE:
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index e8d8806e94cf..dfff8e37ff05 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -85,7 +85,8 @@ static const struct drm_prop_enum_list 
drm_colorop_lut1d_interpolation_list[] =
 /* Init Helpers */
 
 static int drm_colorop_init(struct drm_device *dev, struct drm_colorop 
*colorop,
- 

[V7 27/45] drm/amd/display: Add support for sRGB Inverse EOTF in SHAPER block

[Alex Hung]

Expose a 2nd curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to
perform the sRGB Inverse EOTF on the shaper block
when the colorop is not in bypass.

With this change the follow IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf

The color pipeline now consists of the following colorops:
1. 1D curve colorop w/ sRGB EOTF support
2. 1D curve colorop w/ sRGB Inverse EOTF support

Signed-off-by: Alex Hung 
Co-developed-by: Harry Wentland 
Signed-off-by: Harry Wentland 
---
v6:
 - don't pass uninitialized variable into __set_output_tf

 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 74 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 19 +
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.h |  1 +
 3 files changed, 94 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 566035af00cd..65f681b0c31c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1202,6 +1202,68 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state 
*plane_state,
return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
 }
 
+static int
+__set_colorop_in_shaper_1d_curve(struct dc_plane_state *dc_plane_state,
+  struct drm_colorop_state *colorop_state)
+{
+   struct dc_transfer_func *tf = &dc_plane_state->in_shaper_func;
+   struct drm_colorop *colorop = colorop_state->colorop;
+   struct drm_device *drm = colorop->dev;
+
+   if (colorop->type != DRM_COLOROP_1D_CURVE &&
+   colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF)
+   return -EINVAL;
+
+   if (colorop_state->bypass) {
+   tf->type = TF_TYPE_BYPASS;
+   tf->tf = TRANSFER_FUNCTION_LINEAR;
+   return 0;
+   }
+
+   drm_dbg(drm, "Shaper colorop with ID: %d\n", colorop->base.id);
+
+   if (colorop->type == DRM_COLOROP_1D_CURVE) {
+   tf->type = TF_TYPE_DISTRIBUTED_POINTS;
+   tf->tf = 
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+   tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
+   return __set_output_tf(tf, 0, 0, false);
+   }
+
+   return -EINVAL;
+}
+
+static int
+__set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+   struct drm_colorop *old_colorop;
+   struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+   struct drm_atomic_state *state = plane_state->state;
+   int i = 0;
+
+   old_colorop = colorop;
+
+   /* 2nd op: 1d curve - shaper */
+   for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+   if (new_colorop_state->colorop == old_colorop &&
+   new_colorop_state->curve_1d_type == 
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+
+   if (new_colorop_state->colorop == old_colorop) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+   }
+
+   if (!colorop_state)
+   return -EINVAL;
+
+   return __set_colorop_in_shaper_1d_curve(dc_plane_state, colorop_state);
+}
+
 static int
 amdgpu_dm_plane_set_color_properties(struct drm_plane_state *plane_state,
 struct dc_plane_state *dc_plane_state)
@@ -1257,6 +1319,7 @@ amdgpu_dm_plane_set_colorop_properties(struct 
drm_plane_state *plane_state,
   struct dc_plane_state *dc_plane_state)
 {
struct drm_colorop *colorop = plane_state->color_pipeline;
+   struct drm_device *dev = plane_state->plane->dev;
int ret;
 
/* 1D Curve - DEGAM TF */
@@ -1267,6 +1330,17 @@ amdgpu_dm_plane_set_colorop_properties(struct 
drm_plane_state *plane_state,
if (ret)
return ret;
 
+   /* 1D Curve - SHAPER TF */
+   colorop = colorop->next;
+   if (!colorop) {
+   drm_dbg(dev, "no Shaper TF colorop found\n");
+   return -EINVAL;
+   }
+
+   ret = __set_dm_plane_colorop_shaper(plane_state, dc_plane_state, 
colorop);
+   if (ret)
+   return ret;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 3be0cb19ebc7..718544b11863 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd

[V7 28/45] drm/amd/display: Add support for sRGB EOTF in BLND block

[Alex Hung]

Expose a 3rd 1D curve colorop, with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block
to perform the sRGB transform when the colorop is not in
bypass

With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb_eotf

The color pipeline now consists of the following colorops:
1. 1D curve colorop w/ sRGB EOTF support
2. 1D curve colorop w/ sRGB Inverse EOTF support
3. 1D curve colorop w/ sRGB EOTF support

Signed-off-by: Alex Hung 
Co-developed-by: Harry Wentland 
Signed-off-by: Harry Wentland 
---
v7:
 - Initialized uint32_t blend_size = 0 by default (kernel test robot)

 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 77 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 19 +
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.h |  1 +
 3 files changed, 97 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 65f681b0c31c..ddc8318f6201 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1264,6 +1264,72 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state 
*plane_state,
return __set_colorop_in_shaper_1d_curve(dc_plane_state, colorop_state);
 }
 
+
+static int
+__set_colorop_1d_curve_blend_tf_lut(struct dc_plane_state *dc_plane_state,
+ struct drm_colorop_state *colorop_state)
+{
+
+   struct dc_transfer_func *tf = &dc_plane_state->blend_tf;
+   struct drm_colorop *colorop = colorop_state->colorop;
+   struct drm_device *drm = colorop->dev;
+   const struct drm_color_lut *blend_lut;
+   uint32_t blend_size = 0;
+
+   if (colorop->type != DRM_COLOROP_1D_CURVE &&
+   colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+   return -EINVAL;
+
+   if (colorop_state->bypass) {
+   tf->type = TF_TYPE_BYPASS;
+   tf->tf = TRANSFER_FUNCTION_LINEAR;
+   return 0;
+   }
+
+   drm_dbg(drm, "Blend colorop with ID: %d\n", colorop->base.id);
+
+   if (colorop->type == DRM_COLOROP_1D_CURVE) {
+   tf->type = TF_TYPE_DISTRIBUTED_POINTS;
+   tf->tf = 
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+   tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
+   return __set_input_tf(NULL, tf, blend_lut, blend_size);
+   }
+
+   return -EINVAL;
+}
+
+static int
+__set_dm_plane_colorop_blend(struct drm_plane_state *plane_state,
+struct dc_plane_state *dc_plane_state,
+struct drm_colorop *colorop)
+{
+   struct drm_colorop *old_colorop;
+   struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+   struct drm_atomic_state *state = plane_state->state;
+   int i = 0;
+
+   old_colorop = colorop;
+
+   /* 3nd op: 1d curve - blend */
+   for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+   if (new_colorop_state->colorop == old_colorop &&
+   new_colorop_state->curve_1d_type == 
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+
+   if (new_colorop_state->colorop == old_colorop) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+   }
+
+   if (!colorop_state)
+   return -EINVAL;
+
+   return __set_colorop_1d_curve_blend_tf_lut(dc_plane_state, 
colorop_state);
+}
+
 static int
 amdgpu_dm_plane_set_color_properties(struct drm_plane_state *plane_state,
 struct dc_plane_state *dc_plane_state)
@@ -1341,6 +1407,17 @@ amdgpu_dm_plane_set_colorop_properties(struct 
drm_plane_state *plane_state,
if (ret)
return ret;
 
+   /* 1D Curve - BLND TF */
+   colorop = colorop->next;
+   if (!colorop) {
+   drm_dbg(dev, "no Blend TF colorop found\n");
+   return -EINVAL;
+   }
+
+   ret = __set_dm_plane_colorop_blend(plane_state, dc_plane_state, 
colorop);
+   if (ret)
+   return ret;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 718544b11863..c5154e1430f5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -37,6 +37,9 @@ const u64 amdgpu_dm_supported_degam_tfs =
 const u64 amdgpu_dm_supported_shaper_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF);
 
+const u64 amdgpu_dm_supported_blnd_tfs =
+   BIT(DRM_COLOROP_1D_CURVE_SRG

[V7 03/45] drm/vkms: Add kunit tests for VKMS LUT handling

[Alex Hung]

From: Harry Wentland 

Debugging LUT math is much easier when we can unit test
it. Add kunit functionality to VKMS and add tests for
 - get_lut_index
 - lerp_u16

Reviewed-by: Louis Chauvet 
Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
Cc: Arthur Grillo 
---
v7:
 - Fix checkpatch warnings and errors (Louis Chauvet)
  - Change SPDX-License-Identifier: GPL-2.0+ from /* */ to //
  - Fix checkpatch errors and warnings (new line at EOF, redundant spaces, and 
long lines)
  - Add static to const struct vkms_color_lut test_linear_lut
 - Add "MODULE_DESCRIPTION" (Jeff Johnson)

v6:
 - Eliminate need to include test as .c file (Louis Chauvet)

v5:
 - Bring back static for lerp_u16 and get_lut_index (Arthur)

v4:
 - Test the critical points of the lerp function (Pekka)

v3:
 - Use include way of testing static functions (Arthur)
 
 drivers/gpu/drm/vkms/Kconfig |  15 ++
 drivers/gpu/drm/vkms/Makefile|   1 +
 drivers/gpu/drm/vkms/tests/.kunitconfig  |   4 +
 drivers/gpu/drm/vkms/tests/Makefile  |   3 +
 drivers/gpu/drm/vkms/tests/vkms_color_test.c | 172 +++
 drivers/gpu/drm/vkms/vkms_composer.c |   8 +-
 drivers/gpu/drm/vkms/vkms_composer.h |  13 ++
 7 files changed, 214 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
 create mode 100644 drivers/gpu/drm/vkms/tests/Makefile
 create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_test.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_composer.h

diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
index b9ecdebecb0b..59c4a32adb9d 100644
--- a/drivers/gpu/drm/vkms/Kconfig
+++ b/drivers/gpu/drm/vkms/Kconfig
@@ -13,3 +13,18 @@ config DRM_VKMS
  a VKMS.
 
  If M is selected the module will be called vkms.
+
+config DRM_VKMS_KUNIT_TESTS
+   tristate "KUnit tests for VKMS." if !KUNIT_ALL_TESTS
+   depends on DRM_VKMS=y && KUNIT
+   default KUNIT_ALL_TESTS
+   help
+ This builds unit tests for VKMS. This option is not useful for
+ distributions or general kernels, but only for kernel
+ developers working on VKMS.
+
+ For more information on KUnit and unit tests in general,
+ please refer to the KUnit documentation in
+ Documentation/dev-tools/kunit/.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 1b28a6a32948..8d3e46dde635 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -9,3 +9,4 @@ vkms-y := \
vkms_writeback.o
 
 obj-$(CONFIG_DRM_VKMS) += vkms.o
+obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += tests/
diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig 
b/drivers/gpu/drm/vkms/tests/.kunitconfig
new file mode 100644
index ..70e378228cbd
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_VKMS=y
+CONFIG_DRM_VKMS_KUNIT_TESTS=y
diff --git a/drivers/gpu/drm/vkms/tests/Makefile 
b/drivers/gpu/drm/vkms/tests/Makefile
new file mode 100644
index ..7876ca7a3c42
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += vkms_color_test.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_test.c 
b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
new file mode 100644
index ..b53beaac2703
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+
+#include 
+#include 
+#include "../vkms_drv.h"
+#include "../vkms_composer.h"
+
+#define TEST_LUT_SIZE 16
+
+MODULE_IMPORT_NS(EXPORTED_FOR_KUNIT_TESTING);
+
+static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
+   { 0x0, 0x0, 0x0, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+   { 0x, 0x, 0x, 0 },
+};
+
+static const struct vkms_color_lut test_linear_lut = {
+   .base = test_linear_array,
+   .lut_length = TEST_LUT_SIZE,
+   .channel_value2index_ratio = 0xf000fll
+};
+
+
+static void vkms_color_test_get_lut_index(struct kunit *test)
+{
+   s64 lut_index;
+   int i;
+
+   lut_index = get_lut_index(&test_linear_lut, test_linear_array[0].red);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int(lut_index), 0);
+
+   f

[V7 30/45] drm/amd/display: Enable support for PQ 125 EOTF and Inverse

[Alex Hung]

From: Harry Wentland 

This patchset enables support for the PQ_125 EOTF and its inverse
on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.

With this patchset the following IGT subtests are passing:
kms_colorop --run plane-XR30-XR30-pq_125_eotf
kms_colorop --run plane-XR30-XR30-pq_125_inv_eotf
kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf
kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf-pq_125_eotf

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 20 +--
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c |  6 --
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index ddc8318f6201..63044e0296cb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -25,6 +25,7 @@
 #include "amdgpu.h"
 #include "amdgpu_mode.h"
 #include "amdgpu_dm.h"
+#include "amdgpu_dm_colorop.h"
 #include "dc.h"
 #include "modules/color/color_gamma.h"
 #include "basics/conversion.h"
@@ -675,6 +676,9 @@ amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type 
tf)
case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
return TRANSFER_FUNCTION_SRGB;
+   case DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
+   case DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF:
+   return TRANSFER_FUNCTION_PQ;
default:
return TRANSFER_FUNCTION_LINEAR;
}
@@ -1157,8 +1161,10 @@ __set_colorop_in_tf_1d_curve(struct dc_plane_state 
*dc_plane_state,
struct drm_colorop *colorop = colorop_state->colorop;
struct drm_device *drm = colorop->dev;
 
-   if (colorop->type != DRM_COLOROP_1D_CURVE &&
-   colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+   if (colorop->type != DRM_COLOROP_1D_CURVE)
+   return -EINVAL;
+
+   if (!(BIT(colorop_state->curve_1d_type) & 
amdgpu_dm_supported_degam_tfs))
return -EINVAL;
 
if (colorop_state->bypass) {
@@ -1190,7 +1196,7 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state 
*plane_state,
/* 1st op: 1d curve - degamma */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
-   new_colorop_state->curve_1d_type == 
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+   (BIT(new_colorop_state->curve_1d_type) & 
amdgpu_dm_supported_degam_tfs)) {
colorop_state = new_colorop_state;
break;
}
@@ -1210,8 +1216,10 @@ __set_colorop_in_shaper_1d_curve(struct dc_plane_state 
*dc_plane_state,
struct drm_colorop *colorop = colorop_state->colorop;
struct drm_device *drm = colorop->dev;
 
-   if (colorop->type != DRM_COLOROP_1D_CURVE &&
-   colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF)
+   if (colorop->type != DRM_COLOROP_1D_CURVE)
+   return -EINVAL;
+
+   if (!(BIT(colorop_state->curve_1d_type) & 
amdgpu_dm_supported_shaper_tfs))
return -EINVAL;
 
if (colorop_state->bypass) {
@@ -1247,7 +1255,7 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state 
*plane_state,
/* 2nd op: 1d curve - shaper */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
-   new_colorop_state->curve_1d_type == 
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) {
+   (BIT(new_colorop_state->curve_1d_type) & 
amdgpu_dm_supported_shaper_tfs)) {
colorop_state = new_colorop_state;
break;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index c5154e1430f5..a9d94018a207 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -32,10 +32,12 @@
 #include "amdgpu_dm_colorop.h"
 
 const u64 amdgpu_dm_supported_degam_tfs =
-   BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
+   BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF);
 
 const u64 amdgpu_dm_supported_shaper_tfs =
-   BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF);
+   BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF);
 
 const u64 amdgpu_dm_supported_blnd_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
-- 
2.43.0

[V7 31/45] drm/colorop: add BT2020/BT709 OETF and Inverse OETF

[Alex Hung]

From: Harry Wentland 

The BT.709 and BT.2020 OETFs are the same, the only difference
being that the BT.2020 variant is defined with more precision
for 10 and 12-bit per color encodings.

Both are used as encoding functions for video content, and are
therefore defined as OETF (opto-electronic transfer function)
instead of as EOTF (electro-optical transfer function).

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/drm_colorop.c |  2 ++
 include/drm/drm_colorop.h | 19 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index f3391602a577..665b23900cc0 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -70,6 +70,8 @@ static const struct drm_prop_enum_list 
drm_colorop_type_enum_list[] = {
 static const char * const colorop_curve_1d_type_names[] = {
[DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF",
[DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF",
+   [DRM_COLOROP_1D_CURVE_BT2020_INV_OETF] = "BT.2020 Inverse OETF",
+   [DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
[DRM_COLOROP_1D_CURVE_PQ_125_EOTF] = "PQ 125 EOTF",
[DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF",
 };
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 4084a7438032..83a6bd64d48a 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -55,6 +55,25 @@ enum drm_colorop_curve_1d_type {
 */
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF,
 
+   /**
+* @DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:
+*
+* The inverse of &DRM_COLOROP_1D_CURVE_BT2020_OETF
+*/
+   DRM_COLOROP_1D_CURVE_BT2020_INV_OETF,
+
+   /**
+* @DRM_COLOROP_1D_CURVE_BT2020_OETF:
+*
+* The BT.2020/BT.709 transfer function. The BT.709 and BT.2020
+* transfer functions are the same, the only difference is that
+* BT.2020 is defined with more precision for 10 and 12-bit
+* encodings.
+*
+*
+*/
+   DRM_COLOROP_1D_CURVE_BT2020_OETF,
+
/**
 * @DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
 *
-- 
2.43.0

[V7 29/45] drm/colorop: Add PQ 125 EOTF and its inverse

[Alex Hung]

From: Harry Wentland 

The PQ function defines a mapping of code values to nits (cd/m^2).
The max code value maps to 10,000 nits.

Windows DWM's canonical composition color space (CCCS)  defaults
to composing SDR contents to 80 nits and uses a float value of
1.0 to represent this. For this reason AMD HW hard-codes a PQ
function that is scaled by 125, yielding 80 nit PQ values for
1.0 and 10,000 nits at 125.0.

This patch introduces this scaled PQ EOTF and its inverse as
1D curve types.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/drm_colorop.c |  2 ++
 include/drm/drm_colorop.h | 21 -
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 7d4b29c0a0cc..f3391602a577 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -70,6 +70,8 @@ static const struct drm_prop_enum_list 
drm_colorop_type_enum_list[] = {
 static const char * const colorop_curve_1d_type_names[] = {
[DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF",
[DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF",
+   [DRM_COLOROP_1D_CURVE_PQ_125_EOTF] = "PQ 125 EOTF",
+   [DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF",
 };
 
 
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index e9f5c1adc2fe..4084a7438032 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -36,7 +36,6 @@
  * enum drm_colorop_curve_1d_type - type of 1D curve
  *
  * Describes a 1D curve to be applied by the DRM_COLOROP_1D_CURVE colorop.
- *
  */
 enum drm_colorop_curve_1d_type {
/**
@@ -56,6 +55,26 @@ enum drm_colorop_curve_1d_type {
 */
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF,
 
+   /**
+* @DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
+*
+* The PQ transfer function, scaled by 125.0f, so that 10,000
+* nits correspond to 125.0f.
+*
+* Transfer characteristics of the PQ function as defined by
+* SMPTE ST 2084 (2014) for 10-, 12-, 14-, and 16-bit systems
+* and Rec. ITU-R BT.2100-2 perceptual quantization (PQ) system.
+* Equivalent to H.273 TransferCharacteristics code point 16.
+*/
+   DRM_COLOROP_1D_CURVE_PQ_125_EOTF,
+
+   /**
+* @DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF:
+*
+* The inverse of DRM_COLOROP_1D_CURVE_PQ_125_EOTF.
+*/
+   DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF,
+
/**
 * @DRM_COLOROP_1D_CURVE_COUNT:
 *
-- 
2.43.0

[V7 38/45] drm/amd/display: Swap matrix and multiplier

[Alex Hung]

Swap the order of matrix and multiplier as designed in hardware.

Signed-off-by: Alex Hung 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c  | 12 ++--
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c|  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index edf05290d441..54ec12c1352f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1477,25 +1477,25 @@ amdgpu_dm_plane_set_colorop_properties(struct 
drm_plane_state *plane_state,
if (ret)
return ret;
 
-   /* 3x4 matrix */
+   /* Multiplier */
colorop = colorop->next;
if (!colorop) {
-   drm_dbg(dev, "no 3x4 matrix colorop found\n");
+   drm_dbg(dev, "no multiplier colorop found\n");
return -EINVAL;
}
 
-   ret = __set_dm_plane_colorop_3x4_matrix(plane_state, dc_plane_state, 
colorop);
+   ret = __set_dm_plane_colorop_multiplier(plane_state, dc_plane_state, 
colorop);
if (ret)
return ret;
 
-   /* Multiplier */
+   /* 3x4 matrix */
colorop = colorop->next;
if (!colorop) {
-   drm_dbg(dev, "no multiplier colorop found\n");
+   drm_dbg(dev, "no 3x4 matrix colorop found\n");
return -EINVAL;
}
 
-   ret = __set_dm_plane_colorop_multiplier(plane_state, dc_plane_state, 
colorop);
+   ret = __set_dm_plane_colorop_3x4_matrix(plane_state, dc_plane_state, 
colorop);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 33156531d751..d0777691862b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -75,7 +75,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
 
i++;
 
-   /* 3x4 matrix */
+   /* Multiplier */
ops[i] = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!ops[i]) {
DRM_ERROR("KMS: Failed to allocate colorop\n");
@@ -83,7 +83,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane);
+   ret = drm_colorop_mult_init(dev, ops[i], plane);
if (ret)
goto cleanup;
 
@@ -91,7 +91,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
 
i++;
 
-   /* Multiplier */
+   /* 3x4 matrix */
ops[i] = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!ops[i]) {
DRM_ERROR("KMS: Failed to allocate colorop\n");
@@ -99,7 +99,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_mult_init(dev, ops[i], plane);
+   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane);
if (ret)
goto cleanup;
 
-- 
2.43.0

[V7 39/45] drm/colorop: Define LUT_1D interpolation

[Alex Hung]

From: Harry Wentland 

We want to make sure userspace is aware of the 1D LUT
interpolation. While linear interpolation is common it
might not be supported on all HW. Give driver implementers
a way to specify their interpolation.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Fix a checkpatch long-line warning
 - Modify state->size to colorop->lut_size

 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c |  6 ++--
 drivers/gpu/drm/drm_atomic.c  |  2 ++
 drivers/gpu/drm/drm_colorop.c | 36 ++-
 include/drm/drm_colorop.h | 19 +-
 include/uapi/drm/drm_mode.h   | 13 +++
 5 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index d0777691862b..92c9f3fb0254 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -131,7 +131,8 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_curve_1d_lut_init(dev, ops[i], plane, 
MAX_COLOR_LUT_ENTRIES);
+   ret = drm_colorop_curve_1d_lut_init(dev, ops[i], plane, 
MAX_COLOR_LUT_ENTRIES,
+   
DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR);
if (ret)
goto cleanup;
 
@@ -163,7 +164,8 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
 
-   ret = drm_colorop_curve_1d_lut_init(dev, ops[i], plane, 
MAX_COLOR_LUT_ENTRIES);
+   ret = drm_colorop_curve_1d_lut_init(dev, ops[i], plane, 
MAX_COLOR_LUT_ENTRIES,
+   
DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR);
if (ret)
goto cleanup;
 
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1fa6818794d6..9a17fe11bcb3 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -795,6 +795,8 @@ static void drm_atomic_colorop_print_state(struct 
drm_printer *p,
break;
case DRM_COLOROP_1D_LUT:
drm_printf(p, "\tsize=%d\n", colorop->lut_size);
+   drm_printf(p, "\tinterpolation=%s\n",
+  
drm_get_colorop_lut1d_interpolation_name(colorop->lut1d_interpolation));
drm_printf(p, "\tdata blob id=%d\n", state->data ? 
state->data->base.id : 0);
break;
case DRM_COLOROP_CTM_3X4:
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 9fbfb2b89b1b..e8d8806e94cf 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -78,6 +78,9 @@ static const char * const colorop_curve_1d_type_names[] = {
[DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF",
 };
 
+static const struct drm_prop_enum_list drm_colorop_lut1d_interpolation_list[] 
= {
+   { DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR, "Linear" },
+};
 
 /* Init Helpers */
 
@@ -234,10 +237,12 @@ static int drm_colorop_create_data_prop(struct drm_device 
*dev, struct drm_color
  * @colorop: The drm_colorop object to initialize
  * @plane: The associated drm_plane
  * @lut_size: LUT size supported by driver
+ * @lut1d_interpolation: 1D LUT interpolation type
  * @return zero on success, -E value on failure
  */
 int drm_colorop_curve_1d_lut_init(struct drm_device *dev, struct drm_colorop 
*colorop,
- struct drm_plane *plane, uint32_t lut_size)
+ struct drm_plane *plane, uint32_t lut_size,
+ enum drm_colorop_lut1d_interpolation_type 
lut1d_interpolation)
 {
struct drm_property *prop;
int ret;
@@ -257,6 +262,17 @@ int drm_colorop_curve_1d_lut_init(struct drm_device *dev, 
struct drm_colorop *co
drm_object_attach_property(&colorop->base, colorop->lut_size_property, 
lut_size);
colorop->lut_size = lut_size;
 
+   /* Interpolation */
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"LUT1D_INTERPOLATION",
+   drm_colorop_lut1d_interpolation_list,
+   
ARRAY_SIZE(drm_colorop_lut1d_interpolation_list));
+   if (!prop)
+   return -ENOMEM;
+
+   colorop->lut1d_interpolation_property = prop;
+   drm_object_attach_property(&colorop->base, prop, lut1d_interpolation);
+   colorop->lut1d_interpolation = lut1d_interpolation;
+
/* data */
ret = drm_colorop_create_data_prop(dev, colorop);
if (ret)
@@ -411,6 +427,9 @@ static const char * const colorop_type_name[] = {
[DRM_COLOR

[V7 37/45] drm/amd/display: add multiplier colorop

[Alex Hung]

This adds support for a multiplier. This multiplier is
programmed via the HDR Multiplier in DCN.

With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-multiply_125
kms_colorop --run plane-XR30-XR30-multiply_inv_125

The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 3x4 CTM
3. Multiplier
4. 1D curve colorop
5. 1D LUT
6. 1D curve colorop
7. 1D LUT

Signed-off-by: Alex Hung 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 40 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 16 
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 5d6effe6f90e..edf05290d441 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1250,6 +1250,35 @@ __set_dm_plane_colorop_3x4_matrix(struct drm_plane_state 
*plane_state,
return 0;
 }
 
+static int
+__set_dm_plane_colorop_multiplier(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+   struct drm_colorop *old_colorop;
+   struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+   struct drm_atomic_state *state = plane_state->state;
+   const struct drm_device *dev = colorop->dev;
+   int i = 0;
+
+   /* Multiplier */
+   old_colorop = colorop;
+   for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+   if (new_colorop_state->colorop == old_colorop &&
+   new_colorop_state->colorop->type == DRM_COLOROP_MULTIPLIER) 
{
+   colorop_state = new_colorop_state;
+   break;
+   }
+   }
+
+   if (colorop_state && !colorop_state->bypass && colorop->type == 
DRM_COLOROP_MULTIPLIER) {
+   drm_dbg(dev, "Multiplier colorop with ID: %d\n", 
colorop->base.id);
+   dc_plane_state->hdr_mult = 
amdgpu_dm_fixpt_from_s3132(colorop_state->multiplier);
+   }
+
+   return 0;
+}
+
 static int
 __set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
  struct dc_plane_state *dc_plane_state,
@@ -1459,6 +1488,17 @@ amdgpu_dm_plane_set_colorop_properties(struct 
drm_plane_state *plane_state,
if (ret)
return ret;
 
+   /* Multiplier */
+   colorop = colorop->next;
+   if (!colorop) {
+   drm_dbg(dev, "no multiplier colorop found\n");
+   return -EINVAL;
+   }
+
+   ret = __set_dm_plane_colorop_multiplier(plane_state, dc_plane_state, 
colorop);
+   if (ret)
+   return ret;
+
/* 1D Curve & LUT - SHAPER TF & LUT */
colorop = colorop->next;
if (!colorop) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 9a9386bf85ec..33156531d751 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -91,6 +91,22 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
 
i++;
 
+   /* Multiplier */
+   ops[i] = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+   if (!ops[i]) {
+   DRM_ERROR("KMS: Failed to allocate colorop\n");
+   ret = -ENOMEM;
+   goto cleanup;
+   }
+
+   ret = drm_colorop_mult_init(dev, ops[i], plane);
+   if (ret)
+   goto cleanup;
+
+   drm_colorop_set_next_property(ops[i-1], ops[i]);
+
+   i++;
+
/* 1D curve - SHAPER TF */
ops[i] = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!ops[i]) {
-- 
2.43.0

[V7 36/45] drm/colorop: Add mutliplier type

[Alex Hung]

This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.

It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.

Signed-off-by: Alex Hung 
---
v7:
 - Modify size_property to lut_size_property

 drivers/gpu/drm/drm_atomic.c  |  3 +++
 drivers/gpu/drm/drm_atomic_uapi.c |  4 
 drivers/gpu/drm/drm_colorop.c | 37 +--
 include/drm/drm_colorop.h | 16 +
 include/uapi/drm/drm_mode.h   |  9 
 5 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b7a05132ee01..1fa6818794d6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -800,6 +800,9 @@ static void drm_atomic_colorop_print_state(struct 
drm_printer *p,
case DRM_COLOROP_CTM_3X4:
drm_printf(p, "\tdata blob id=%d\n", state->data ? 
state->data->base.id : 0);
break;
+   case DRM_COLOROP_MULTIPLIER:
+   drm_printf(p, "\tmultiplier=%llu\n", state->multiplier);
+   break;
default:
break;
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4744c12e429d..3c815a2a8d9d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -728,6 +728,8 @@ static int drm_atomic_colorop_set_property(struct 
drm_colorop *colorop,
state->bypass = val;
} else if (property == colorop->curve_1d_type_property) {
state->curve_1d_type = val;
+   } else if (property == colorop->multiplier_property) {
+   state->multiplier = val;
} else if (property == colorop->data_property) {
return drm_atomic_color_set_data_property(colorop,
state, property, val);
@@ -753,6 +755,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
+   } else if (property == colorop->multiplier_property) {
+   *val = state->multiplier;
} else if (property == colorop->lut_size_property) {
*val = colorop->lut_size;
} else if (property == colorop->data_property) {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index e6dea2713490..9fbfb2b89b1b 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -65,7 +65,8 @@
 static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
{ DRM_COLOROP_1D_LUT, "1D Curve Custom LUT" },
-   { DRM_COLOROP_CTM_3X4, "3x4 Matrix"}
+   { DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
+   { DRM_COLOROP_MULTIPLIER, "Multiplier"},
 };
 
 static const char * const colorop_curve_1d_type_names[] = {
@@ -286,6 +287,37 @@ int drm_colorop_ctm_3x4_init(struct drm_device *dev, 
struct drm_colorop *colorop
 }
 EXPORT_SYMBOL(drm_colorop_ctm_3x4_init);
 
+/**
+ * drm_colorop_mult_init - Initialize a DRM_COLOROP_MULTIPLIER
+ *
+ * @dev: DRM device
+ * @colorop: The drm_colorop object to initialize
+ * @plane: The associated drm_plane
+ * @return zero on success, -E value on failure
+ */
+int drm_colorop_mult_init(struct drm_device *dev, struct drm_colorop *colorop,
+ struct drm_plane *plane)
+{
+   struct drm_property *prop;
+   int ret;
+
+   ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_MULTIPLIER);
+   if (ret)
+   return ret;
+
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC, 
"MULTIPLIER", 0, U64_MAX);
+   if (!prop)
+   return -ENOMEM;
+
+   colorop->multiplier_property = prop;
+   drm_object_attach_property(&colorop->base, 
colorop->multiplier_property, 0);
+
+   drm_colorop_reset(colorop);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_colorop_mult_init);
+
 static void __drm_atomic_helper_colorop_duplicate_state(struct drm_colorop 
*colorop,
struct 
drm_colorop_state *state)
 {
@@ -376,7 +408,8 @@ void drm_colorop_reset(struct drm_colorop *colorop)
 static const char * const colorop_type_name[] = {
[DRM_COLOROP_1D_CURVE] = "1D Curve",
[DRM_COLOROP_1D_LUT] = "1D Curve Custom LUT",
-   [DRM_COLOROP_CTM_3X4] = "3x4 Matrix"
+   [DRM_COLOROP_CTM_3X4] = "3x4 Matrix",
+   [DRM_COLOROP_MULTIPLIER] = "Multiplier",
 };
 
 const char *drm_get_colorop_type_name(enum drm_colorop_type type)
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_

[V7 26/45] drm/amd/display: Add support for sRGB EOTF in DEGAM block

[Alex Hung]

Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.

With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf

The color pipeline now consists of a single colorop:
1. 1D curve colorop w/ sRGB EOTF

Signed-off-by: Alex Hung 
Co-developed-by: Harry Wentland 
Signed-off-by: Harry Wentland 
---
v7:
 - Fix checkpatch warnings
  - Change switch "{ }" position
  - Delete double ";"
  - Delete "{ }" for single-line if-statement
  - Add a new line at EOF
  - Change SPDX-License-Identifier: GPL-2.0+ from // to /* */

v6:
 - cleanup if colorop alloc or init fails

 .../gpu/drm/amd/display/amdgpu_dm/Makefile|  3 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 86 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 70 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.h | 34 
 .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 10 +++
 5 files changed, 202 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
 create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.h

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile 
b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
index ab2a97e354da..46158d67ab12 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
@@ -38,7 +38,8 @@ AMDGPUDM = \
amdgpu_dm_pp_smu.o \
amdgpu_dm_psr.o \
amdgpu_dm_replay.o \
-   amdgpu_dm_wb.o
+   amdgpu_dm_wb.o \
+   amdgpu_dm_colorop.o
 
 ifdef CONFIG_DRM_AMD_DC_FP
 AMDGPUDM += dc_fpu.o
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index ebabfe3a512f..566035af00cd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -668,6 +668,18 @@ amdgpu_tf_to_dc_tf(enum amdgpu_transfer_function tf)
}
 }
 
+static enum dc_transfer_func_predefined
+amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type tf)
+{
+   switch (tf) {
+   case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
+   case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
+   return TRANSFER_FUNCTION_SRGB;
+   default:
+   return TRANSFER_FUNCTION_LINEAR;
+   }
+}
+
 static void __to_dc_lut3d_color(struct dc_rgb *rgb,
const struct drm_color_lut lut,
int bit_precision)
@@ -1137,6 +1149,59 @@ __set_dm_plane_degamma(struct drm_plane_state 
*plane_state,
return 0;
 }
 
+static int
+__set_colorop_in_tf_1d_curve(struct dc_plane_state *dc_plane_state,
+  struct drm_colorop_state *colorop_state)
+{
+   struct dc_transfer_func *tf = &dc_plane_state->in_transfer_func;
+   struct drm_colorop *colorop = colorop_state->colorop;
+   struct drm_device *drm = colorop->dev;
+
+   if (colorop->type != DRM_COLOROP_1D_CURVE &&
+   colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+   return -EINVAL;
+
+   if (colorop_state->bypass) {
+   tf->type = TF_TYPE_BYPASS;
+   tf->tf = TRANSFER_FUNCTION_LINEAR;
+   return 0;
+   }
+
+   drm_dbg(drm, "Degamma colorop with ID: %d\n", colorop->base.id);
+
+   tf->type = TF_TYPE_PREDEFINED;
+   tf->tf = amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+
+   return 0;
+}
+
+static int
+__set_dm_plane_colorop_degamma(struct drm_plane_state *plane_state,
+  struct dc_plane_state *dc_plane_state,
+  struct drm_colorop *colorop)
+{
+   struct drm_colorop *old_colorop;
+   struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+   struct drm_atomic_state *state = plane_state->state;
+   int i = 0;
+
+   old_colorop = colorop;
+
+   /* 1st op: 1d curve - degamma */
+   for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+   if (new_colorop_state->colorop == old_colorop &&
+   new_colorop_state->curve_1d_type == 
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+   }
+
+   if (!colorop_state)
+   return -EINVAL;
+
+   return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
+}
+
 static int
 amdgpu_dm_plane_set_color_properties(struct drm_plane_state *plane_state,
 struct dc_plane_state *dc_plane_state)
@@ -1187,6 +1252,24 @@ amdgpu_dm_plane_set_color_properties(struct 
drm_plane_state *plane_state,
return 0;
 }
 
+static int
+

[V7 43/45] drm/amd/display: Add AMD color pipeline doc

[Alex Hung]

From: Harry Wentland 

Add kernel doc for AMD color pipeline.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 122 +++---
 1 file changed, 102 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 5e8c5c0657c4..56fb0870a2fc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -33,6 +33,32 @@
 /**
  * DOC: overview
  *
+ * We have three types of color management in the AMD display driver.
+ * 1. the legacy &drm_crtc DEGAMMA, CTM, and GAMMA properties
+ * 2. AMD driver private color management on &drm_plane and &drm_crtc
+ * 3. AMD plane color pipeline
+ *
+ * The CRTC properties are the original color management. When they were
+ * implemented per-plane color management was not a thing yet. Because
+ * of that we could get away with plumbing the DEGAMMA and CTM
+ * properties to pre-blending HW functions. This is incompatible with
+ * per-plane color management, such as via the AMD private properties or
+ * the new drm_plane color pipeline. The only compatible CRTC property
+ * with per-plane color management is the GAMMA property as it is
+ * applied post-blending.
+ *
+ * The AMD driver private color management properties are only exposed
+ * when the kernel is built explicitly with -DAMD_PRIVATE_COLOR. They
+ * are temporary building blocks on the path to full-fledged &drm_plane
+ * and &drm_crtc color pipelines and lay the driver's groundwork for the
+ * color pipelines.
+ *
+ * The AMD plane color pipeline describes AMD's &drm_colorops via the
+ * &drm_plane's COLOR_PIPELINE property.
+ *
+ * drm_crtc Properties
+ * ---
+ *
  * The DC interface to HW gives us the following color management blocks
  * per pipe (surface):
  *
@@ -43,33 +69,89 @@
  * - Surface regamma LUT (normalized)
  * - Output CSC (normalized)
  *
- * But these aren't a direct mapping to DRM color properties. The current DRM
- * interface exposes CRTC degamma, CRTC CTM and CRTC regamma while our hardware
- * is essentially giving:
+ * But these aren't a direct mapping to DRM color properties. The
+ * current DRM interface exposes CRTC degamma, CRTC CTM and CRTC regamma
+ * while our hardware is essentially giving:
  *
  * Plane CTM -> Plane degamma -> Plane CTM -> Plane regamma -> Plane CTM
  *
- * The input gamma LUT block isn't really applicable here since it operates
- * on the actual input data itself rather than the HW fp representation. The
- * input and output CSC blocks are technically available to use as part of
- * the DC interface but are typically used internally by DC for conversions
- * between color spaces. These could be blended together with user
- * adjustments in the future but for now these should remain untouched.
+ * The input gamma LUT block isn't really applicable here since it
+ * operates on the actual input data itself rather than the HW fp
+ * representation. The input and output CSC blocks are technically
+ * available to use as part of the DC interface but are typically used
+ * internally by DC for conversions between color spaces. These could be
+ * blended together with user adjustments in the future but for now
+ * these should remain untouched.
+ *
+ * The pipe blending also happens after these blocks so we don't
+ * actually support any CRTC props with correct blending with multiple
+ * planes - but we can still support CRTC color management properties in
+ * DM in most single plane cases correctly with clever management of the
+ * DC interface in DM.
+ *
+ * As per DRM documentation, blocks should be in hardware bypass when
+ * their respective property is set to NULL. A linear DGM/RGM LUT should
+ * also considered as putting the respective block into bypass mode.
+ *
+ * This means that the following configuration is assumed to be the
+ * default:
+ *
+ * Plane DGM Bypass -> Plane CTM Bypass -> Plane RGM Bypass -> ... CRTC
+ * DGM Bypass -> CRTC CTM Bypass -> CRTC RGM Bypass
+ *
+ * AMD Private Color Management on drm_plane
+ * -
+ *
+ * The AMD private color management properties on a &drm_plane are:
+ *
+ * - AMD_PLANE_DEGAMMA_LUT
+ * - AMD_PLANE_DEGAMMA_LUT_SIZE
+ * - AMD_PLANE_DEGAMMA_TF
+ * - AMD_PLANE_HDR_MULT
+ * - AMD_PLANE_CTM
+ * - AMD_PLANE_SHAPER_LUT
+ * - AMD_PLANE_SHAPER_LUT_SIZE
+ * - AMD_PLANE_SHAPER_TF
+ * - AMD_PLANE_LUT3D
+ * - AMD_PLANE_LUT3D_SIZE
+ * - AMD_PLANE_BLEND_LUT
+ * - AMD_PLANE_BLEND_LUT_SIZE
+ * - AMD_PLANE_BLEND_TF
+ *
+ * The AMD private color management property on a &drm_crtc is:
+ *
+ * - AMD_CRTC_REGAMMA_TF
+ *
+ * Use of these properties is discouraged.
+ *
+ * AMD plane color pipeline
+ * 
+ *
+ * The AMD &drm_

[V7 44/45] drm/colorop: Add kernel doc for data blob

[Alex Hung]

Add layout of data blob for colorop types: DRM_COLOROP_1D_LUT,
DRM_COLOROP_CTM_3X4 and DRM_COLOROP_3D_LUT

Signed-off-by: Alex Hung 
---
 include/drm/drm_colorop.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 7b58dcf0615a..11b474a9b10a 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -146,6 +146,24 @@ struct drm_colorop_state {
 *
 * Data blob for any TYPE that requires such a blob. The
 * interpretation of the blob is TYPE-specific.
+*
+* For 1D LUTs (DRM_COLOROP_1D_LUT), the blob is an array of
+* struct drm_color_lut with size of "lut_size".
+*
+* For 3x4 matrix (DRM_COLOROP_CTM_3X4), the blob is a float[12]:
+* out   matrix  in
+* |R|   |0  1  2  3 |   | R |
+* |G| = |4  5  6  7 | x | G |
+* |B|   |8  9  10 12|   | B |
+*
+* For 3D LUTs (DRM_COLOROP_3D_LUT), the blob is a 3D array of
+* struct drm_color_lut with dimension length of "lut_size".
+* The LUT elements are traversed like so:
+*   for R in range 0..n
+* for G in range 0..n
+*   for B in range 0..n
+* color = lut3d[R][G][B]
+*
 */
struct drm_property_blob *data;
 
-- 
2.43.0

[V7 42/45] drm/amd/display: add 3D LUT colorop

[Alex Hung]

This adds support for a 3D LUT.

The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. Multiplier
3. 3x4 CTM
4. 1D curve colorop
5. 1D LUT
6. 3D LUT
7. 1D curve colorop
8. 1D LUT

Signed-off-by: Alex Hung 
---
v7:
 - Simplify 3D LUT according to drm_colorop changes (Simon Ser)

 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 100 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c |  19 
 2 files changed, 116 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 54ec12c1352f..5e8c5c0657c4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1282,7 +1282,8 @@ __set_dm_plane_colorop_multiplier(struct drm_plane_state 
*plane_state,
 static int
 __set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
  struct dc_plane_state *dc_plane_state,
- struct drm_colorop *colorop)
+ struct drm_colorop *colorop,
+ bool *enabled)
 {
struct drm_colorop *old_colorop;
struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
@@ -1310,6 +1311,7 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state 
*plane_state,
tf->tf = default_tf = 
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
__set_output_tf(tf, 0, 0, false);
+   *enabled = true;
}
 
/* 1D LUT - SHAPER LUT */
@@ -1337,8 +1339,88 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state 
*plane_state,
shaper_size = shaper_lut != NULL ? shaper_size : 0;
 
/* Custom LUT size must be the same as supported size */
-   if (shaper_size == colorop->lut_size)
+   if (shaper_size == colorop->lut_size) {
__set_output_tf(tf, shaper_lut, shaper_size, false);
+   *enabled = true;
+   }
+   }
+
+   return 0;
+}
+
+/* __set_colorop_3dlut - set DRM 3D LUT to DC stream
+ * @drm_lut3d: user 3D LUT
+ * @drm_lut3d_size: size of 3D LUT
+ * @lut3d: DC 3D LUT
+ *
+ * Map user 3D LUT data to DC 3D LUT and all necessary bits to program it
+ * on DCN accordingly.
+ */
+static void __set_colorop_3dlut(const struct drm_color_lut *drm_lut3d,
+   uint32_t drm_lut3d_size,
+   struct dc_3dlut *lut)
+{
+   if (!drm_lut3d_size)
+   return;
+
+   lut->state.bits.initialized = 0;
+
+   /* Only supports 17x17x17 3D LUT (12-bit) now */
+   lut->lut_3d.use_12bits = true;
+   lut->lut_3d.use_tetrahedral_9 = false;
+
+   lut->state.bits.initialized = 1;
+   __drm_3dlut_to_dc_3dlut(drm_lut3d, drm_lut3d_size, &lut->lut_3d,
+   lut->lut_3d.use_tetrahedral_9, 12);
+
+}
+
+static int
+__set_dm_plane_colorop_3dlut(struct drm_plane_state *plane_state,
+struct dc_plane_state *dc_plane_state,
+struct drm_colorop *colorop,
+bool shaper_enabled)
+{
+   struct drm_colorop *old_colorop;
+   struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+   struct dc_transfer_func *tf = &dc_plane_state->in_shaper_func;
+   struct drm_atomic_state *state = plane_state->state;
+   const struct amdgpu_device *adev = drm_to_adev(colorop->dev);
+   const struct drm_device *dev = colorop->dev;
+   const struct drm_color_lut *lut3d;
+   uint32_t lut3d_size;
+   int i = 0;
+
+   /* 3D LUT */
+   old_colorop = colorop;
+   for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+   if (new_colorop_state->colorop == old_colorop &&
+   new_colorop_state->colorop->type == DRM_COLOROP_3D_LUT) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+   }
+
+   if (colorop_state && !colorop_state->bypass && colorop->type == 
DRM_COLOROP_3D_LUT) {
+   if (!adev->dm.dc->caps.color.dpp.hw_3d_lut) {
+   drm_dbg(dev, "3D LUT is not supported by hardware\n");
+   return 0;
+   }
+
+   drm_dbg(dev, "3D LUT colorop with ID: %d\n", colorop->base.id);
+   lut3d = __extract_blob_lut(colorop_state->data, &lut3d_size);
+   lut3d_size = lut3d != NULL ? lut3d_size : 0;
+   __set_colorop_3dlut(lut3d, lut3d_size, 
&dc_plane_state->lut3d_func);
+
+   /* 3D LUT requires shaper. If shaper colorop is 

[V7 41/45] drm/colorop: Add 3D LUT supports to color pipeline

[Alex Hung]

It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.

new drm_colorop_type: DRM_COLOROP_3D_LUT.

Signed-off-by: Alex Hung 
---
v7:
 - Simplify 3D LUT by removing lut_3d_modes and related functions (Simon Ser)

 drivers/gpu/drm/drm_atomic.c  |  6 +++
 drivers/gpu/drm/drm_atomic_uapi.c |  6 +++
 drivers/gpu/drm/drm_colorop.c | 72 +++
 include/drm/drm_colorop.h | 21 +
 include/uapi/drm/drm_mode.h   | 21 +
 5 files changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 88219b095d99..d94ea4e11888 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -806,6 +806,12 @@ static void drm_atomic_colorop_print_state(struct 
drm_printer *p,
case DRM_COLOROP_MULTIPLIER:
drm_printf(p, "\tmultiplier=%llu\n", state->multiplier);
break;
+   case DRM_COLOROP_3D_LUT:
+   drm_printf(p, "\tsize=%d\n", colorop->lut_size);
+   drm_printf(p, "\tinterpolation=%s\n",
+  
drm_get_colorop_lut3d_interpolation_name(colorop->lut3d_interpolation));
+   drm_printf(p, "\tdata blob id=%d\n", state->data ? 
state->data->base.id : 0);
+   break;
default:
break;
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 3c815a2a8d9d..f742a6235c12 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -707,6 +707,10 @@ static int drm_atomic_color_set_data_property(struct 
drm_colorop *colorop,
case DRM_COLOROP_CTM_3X4:
size = sizeof(struct drm_color_ctm_3x4);
break;
+   case DRM_COLOROP_3D_LUT:
+   size = colorop->lut_size * colorop->lut_size * 
colorop->lut_size *
+  sizeof(struct drm_color_lut);
+   break;
default:
/* should never get here */
return -EINVAL;
@@ -759,6 +763,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->multiplier;
} else if (property == colorop->lut_size_property) {
*val = colorop->lut_size;
+   } else if (property == colorop->lut3d_interpolation_property) {
+   *val = colorop->lut3d_interpolation;
} else if (property == colorop->data_property) {
*val = (state->data) ? state->data->base.id : 0;
} else {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index dfff8e37ff05..e3dd49c0080d 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -67,6 +67,7 @@ static const struct drm_prop_enum_list 
drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_LUT, "1D Curve Custom LUT" },
{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
{ DRM_COLOROP_MULTIPLIER, "Multiplier"},
+   { DRM_COLOROP_3D_LUT, "3D LUT"},
 };
 
 static const char * const colorop_curve_1d_type_names[] = {
@@ -82,6 +83,11 @@ static const struct drm_prop_enum_list 
drm_colorop_lut1d_interpolation_list[] =
{ DRM_COLOROP_LUT1D_INTERPOLATION_LINEAR, "Linear" },
 };
 
+
+static const struct drm_prop_enum_list drm_colorop_lut3d_interpolation_list[] 
= {
+   { DRM_COLOROP_LUT3D_INTERPOLATION_TETRAHEDRAL, "Tetrahedral" },
+};
+
 /* Init Helpers */
 
 static int drm_colorop_init(struct drm_device *dev, struct drm_colorop 
*colorop,
@@ -349,6 +355,51 @@ int drm_colorop_mult_init(struct drm_device *dev, struct 
drm_colorop *colorop,
 }
 EXPORT_SYMBOL(drm_colorop_mult_init);
 
+int drm_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop *colorop,
+  struct drm_plane *plane,
+  uint32_t lut_size,
+  enum drm_colorop_lut3d_interpolation_type 
interpolation,
+  bool allow_bypass)
+{
+   struct drm_property *prop;
+   int ret;
+
+   ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_3D_LUT, 
allow_bypass);
+   if (ret)
+   return ret;
+
+   /* LUT size */
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "SIZE",
+0, UINT_MAX);
+   if (!prop)
+   return -ENOMEM;
+
+   colorop->lut_size_property = prop;
+   drm_object_attach_property(&colorop->base, colorop->lut_size_property, 
lut_size);
+   colorop->lut_size = lut_size;
+
+   /* interpolation */
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
"LUT3D_INTERPOLATION",
+   drm_colorop_lut3d_interpolation_list,
+  

[V7 45/45] drm/colorop: Add destroy functions for color pipeline

[Alex Hung]

The functions are to clean up color pipeline when a device driver
fails to create its color pipeline.

Signed-off-by: Alex Hung 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c |  3 +-
 drivers/gpu/drm/drm_colorop.c | 41 +++
 drivers/gpu/drm/vkms/vkms_colorop.c   |  3 +-
 include/drm/drm_colorop.h |  2 +
 4 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index e03e6044f937..80173f00dfd0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -200,8 +200,7 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
return 0;
 
 cleanup:
-   for (; i >= 0; i--)
-   kfree(ops[i]);
+   drm_colorop_pipeline_destroy(plane);
 
return ret;
 }
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index e3dd49c0080d..5245d6a4da39 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -154,6 +154,47 @@ static int drm_colorop_init(struct drm_device *dev, struct 
drm_colorop *colorop,
return ret;
 }
 
+/**
+ * drm_colorop_cleanup - Cleanup a drm_colorop object in color_pipeline
+ *
+ * @colorop: The drm_colorop object to be cleaned
+ */
+void drm_colorop_cleanup(struct drm_colorop *colorop)
+{
+   struct drm_device *dev = colorop->dev;
+   struct drm_mode_config *config = &dev->mode_config;
+
+   list_del(&colorop->head);
+   config->num_colorop--;
+
+   if (colorop->state && colorop->state->data) {
+   drm_property_blob_put(colorop->state->data);
+   colorop->state->data = NULL;
+   }
+
+   kfree(colorop->state);
+   kfree(colorop);
+}
+
+/**
+ * drm_colorop_pipeline_destroy - Helper for color pipeline destruction
+ *
+ * @plane: - The drm_plane structure containing the color_pipeline
+ *
+ * Provides a default color pipeline destroy handler for a planes.
+ */
+void drm_colorop_pipeline_destroy(struct drm_plane *plane)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_mode_config *config = &dev->mode_config;
+   struct drm_colorop *colorop, *next;
+
+   list_for_each_entry_safe(colorop, next, &config->colorop_list, head) {
+   drm_colorop_cleanup(colorop);
+   }
+}
+EXPORT_SYMBOL(drm_colorop_pipeline_destroy);
+
 /**
  * drm_colorop_curve_1d_init - Initialize a DRM_COLOROP_1D_CURVE
  *
diff --git a/drivers/gpu/drm/vkms/vkms_colorop.c 
b/drivers/gpu/drm/vkms/vkms_colorop.c
index c418926d5bc0..5cf47a6ef79e 100644
--- a/drivers/gpu/drm/vkms/vkms_colorop.c
+++ b/drivers/gpu/drm/vkms/vkms_colorop.c
@@ -89,8 +89,7 @@ static int vkms_initialize_color_pipeline(struct drm_plane 
*plane, struct drm_pr
return 0;
 
 cleanup:
-   for (; i >= 0; i--)
-   kfree(ops[i]);
+   drm_colorop_pipeline_destroy(plane);
 
return ret;
 }
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 11b474a9b10a..953eea079708 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -367,6 +367,8 @@ static inline struct drm_colorop *drm_colorop_find(struct 
drm_device *dev,
return mo ? obj_to_colorop(mo) : NULL;
 }
 
+void drm_colorop_pipeline_destroy(struct drm_plane *plane);
+
 int drm_colorop_curve_1d_init(struct drm_device *dev, struct drm_colorop 
*colorop,
  struct drm_plane *plane, u64 supported_tfs,
  bool allow_bypass);
-- 
2.43.0

[V7 35/45] drm/amd/display: add 3x4 matrix colorop

[Alex Hung]

This adds support for a 3x4 color transformation matrix.

With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_enc
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_dec

The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 3x4 CTM
3. 1D curve colorop
4. 1D LUT
5. 1D curve colorop
6. 1D LUT

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Change %lu to %zu for sizeof() when In drm_warn

v6:
 - fix warnings in dbg prints

 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 50 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 16 ++
 2 files changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 0bea52eede39..5d6effe6f90e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1211,6 +1211,45 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state 
*plane_state,
return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
 }
 
+static int
+__set_dm_plane_colorop_3x4_matrix(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+   struct drm_colorop *old_colorop;
+   struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+   struct drm_atomic_state *state = plane_state->state;
+   const struct drm_device *dev = colorop->dev;
+   const struct drm_property_blob *blob;
+   struct drm_color_ctm_3x4 *ctm = NULL;
+   int i = 0;
+
+   /* 3x4 matrix */
+   old_colorop = colorop;
+   for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+   if (new_colorop_state->colorop == old_colorop &&
+   new_colorop_state->colorop->type == DRM_COLOROP_CTM_3X4) {
+   colorop_state = new_colorop_state;
+   break;
+   }
+   }
+
+   if (colorop_state && !colorop_state->bypass && colorop->type == 
DRM_COLOROP_CTM_3X4) {
+   drm_dbg(dev, "3x4 matrix colorop with ID: %d\n", 
colorop->base.id);
+   blob = colorop_state->data;
+   if (blob->length == sizeof(struct drm_color_ctm_3x4)) {
+   ctm = blob ? (struct drm_color_ctm_3x4 *) blob->data : 
NULL;
+   __drm_ctm_3x4_to_dc_matrix(ctm, 
dc_plane_state->gamut_remap_matrix.matrix);
+   dc_plane_state->gamut_remap_matrix.enable_remap = true;
+   
dc_plane_state->input_csc_color_matrix.enable_adjustment = false;
+   } else
+   drm_warn(dev, "blob->length (%lu) isn't equal to 
drm_color_ctm_3x4 (%zu)\n",
+blob->length, sizeof(struct 
drm_color_ctm_3x4));
+   }
+
+   return 0;
+}
+
 static int
 __set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
  struct dc_plane_state *dc_plane_state,
@@ -1409,6 +1448,17 @@ amdgpu_dm_plane_set_colorop_properties(struct 
drm_plane_state *plane_state,
if (ret)
return ret;
 
+   /* 3x4 matrix */
+   colorop = colorop->next;
+   if (!colorop) {
+   drm_dbg(dev, "no 3x4 matrix colorop found\n");
+   return -EINVAL;
+   }
+
+   ret = __set_dm_plane_colorop_3x4_matrix(plane_state, dc_plane_state, 
colorop);
+   if (ret)
+   return ret;
+
/* 1D Curve & LUT - SHAPER TF & LUT */
colorop = colorop->next;
if (!colorop) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 8a5e15083f11..9a9386bf85ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -75,6 +75,22 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane 
*plane, struct drm_pr
 
i++;
 
+   /* 3x4 matrix */
+   ops[i] = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+   if (!ops[i]) {
+   DRM_ERROR("KMS: Failed to allocate colorop\n");
+   ret = -ENOMEM;
+   goto cleanup;
+   }
+
+   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane);
+   if (ret)
+   goto cleanup;
+
+   drm_colorop_set_next_property(ops[i-1], ops[i]);
+
+   i++;
+
/* 1D curve - SHAPER TF */
ops[i] = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!ops[i]) {
-- 
2.43.0

Re: [PATCH v6 41/44] drm/colorop: allow non-bypass colorops

[Alex Hung]

On 10/4/24 05:43, Louis Chauvet wrote:

On 03/10/24 - 16:01, Harry Wentland wrote:

Not all HW will be able to do bypass on all color
operations. Introduce an 'allow_bypass' boolean for
all colorop init functions and only create the BYPASS
property when it's true.

Signed-off-by: Harry Wentland 
---
  .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 22 +---
  drivers/gpu/drm/drm_atomic.c  |  3 +-
  drivers/gpu/drm/drm_colorop.c | 51 ---
  drivers/gpu/drm/vkms/vkms_colorop.c   |  8 +--
  include/drm/drm_colorop.h | 10 ++--
  5 files changed, 60 insertions(+), 34 deletions(-)



[...]


--- a/drivers/gpu/drm/vkms/vkms_colorop.c
+++ b/drivers/gpu/drm/vkms/vkms_colorop.c
@@ -31,7 +31,7 @@ static int vkms_initialize_color_pipeline(struct drm_plane 
*plane, struct drm_pr
goto cleanup;
}
  
-	ret = drm_colorop_curve_1d_init(dev, ops[i], plane, supported_tfs);

+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, supported_tfs, 
true);
if (ret)
goto cleanup;
  
@@ -48,7 +48,7 @@ static int vkms_initialize_color_pipeline(struct drm_plane *plane, struct drm_pr

goto cleanup;
}
  
-	ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane);

+   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane, true);
if (ret)
goto cleanup;
  
@@ -64,7 +64,7 @@ static int vkms_initialize_color_pipeline(struct drm_plane *plane, struct drm_pr

goto cleanup;
}
  
-	ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane);

+   ret = drm_colorop_ctm_3x4_init(dev, ops[i], plane, true);
if (ret)
goto cleanup;
  
@@ -80,7 +80,7 @@ static int vkms_initialize_color_pipeline(struct drm_plane *plane, struct drm_pr

goto cleanup;
}
  
-	ret = drm_colorop_curve_1d_init(dev, ops[i], plane, supported_tfs);

+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, supported_tfs, 
true);
if (ret)
goto cleanup;


You allow the bypass here, but you forgot to add a check in apply_colorop
to bypass the colorop when this is set. It seems to be the case in the AMD
driver too. Or maybe you wanted to pass false in "allow_bypass"?



The bypass is used in each color transform. For example, it is used in 
pre_blend_color_transform() of vkms_composer.c, before calling 
apply_colorop().


Similarly, it is checked before calling each color transformation in 
amdgpu_dm_color.c, such as __set_colorop_in_tf_1d_curve(), 
__set_dm_plane_colorop_3x4_matrix() and etc.





  
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h

index d3a00296973d..b8c1c4da3444 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -333,14 +333,16 @@ static inline struct drm_colorop *drm_colorop_find(struct 
drm_device *dev,
  }
  
  int drm_colorop_curve_1d_init(struct drm_device *dev, struct drm_colorop *colorop,

- struct drm_plane *plane, u64 supported_tfs);
+ struct drm_plane *plane, u64 supported_tfs,
+ bool allow_bypass);
  int drm_colorop_curve_1d_lut_init(struct drm_device *dev, struct drm_colorop 
*colorop,
  struct drm_plane *plane, uint32_t lut_size,
- enum drm_colorop_lut1d_interpolation_type 
lut1d_interpolation);
+ enum drm_colorop_lut1d_interpolation_type 
lut1d_interpolation,
+ bool allow_bypass);
  int drm_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop 
*colorop,
-struct drm_plane *plane);
+struct drm_plane *plane, bool allow_bypass);
  int drm_colorop_mult_init(struct drm_device *dev, struct drm_colorop *colorop,
- struct drm_plane *plane);
+ struct drm_plane *plane, bool allow_bypass);
  
  struct drm_colorop_state *

  drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
--
2.46.2

[V7 14/45] drm/vkms: Add enumerated 1D curve colorop

[Alex Hung]

From: Harry Wentland 

This patch introduces a VKMS color pipeline that includes two
drm_colorops for named transfer functions. For now the only ones
supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
We will expand this in the future but I don't want to do so
without accompanying IGT tests.

We introduce a new vkms_luts.c file that hard-codes sRGB EOTF,
sRGB Inverse EOTF, and a linear EOTF LUT. These have been
generated with 256 entries each as IGT is currently testing
only 8 bpc surfaces. We will likely need higher precision
but I'm reluctant to make that change without clear indication
that we need it. We'll revisit and, if necessary, regenerate
the LUTs when we have IGT tests for higher precision buffers.

Signed-off-by: Harry Wentland 
Signed-off-by: Alex Hung 
---
v7:
 - Fix checkpatch warnings (Louis Chauvet)
  - Change kzalloc(sizeof(struct drm_colorop) ...) to kzalloc(sizeof(*ops[i]) 
...)
  - Remove if (ops[i]) before kfree(ops[i])
  - Fix styles by adding and removing spaces (new lines, tabs and so on)

v6:
 - drop 'len' var (Louis Chauvet)
 - cleanup if colorop alloc or init fails (Louis Chauvet)
 - switch loop in pre_blend_transform (Louis Chauvet)
 - drop extraneous if (colorop) inside while (colorop) (Louis Chauvet)

v5:
 - Squash with "Pull apply_colorop out of pre_blend_color_transform"
   (Sebastian)
 - Fix warnings
 - Fix include
 - Drop TODOs

v4:
 - Drop _tf_ from color_pipeline init function
 - Pass supported TFs into colorop init
 - Create bypass pipeline in DRM helper (Pekka)

v2:
 - Add commit description
 - Fix sRGB EOTF LUT definition
 - Add linear and sRGB inverse EOTF LUTs

 drivers/gpu/drm/vkms/Makefile|   4 +-
 drivers/gpu/drm/vkms/vkms_colorop.c  |  82 +++
 drivers/gpu/drm/vkms/vkms_composer.c |  50 ++
 drivers/gpu/drm/vkms/vkms_drv.h  |   3 +
 drivers/gpu/drm/vkms/vkms_luts.c | 801 +++
 drivers/gpu/drm/vkms/vkms_luts.h |  12 +
 drivers/gpu/drm/vkms/vkms_plane.c|   2 +
 7 files changed, 953 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h

diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 8d3e46dde635..0bf3c116f1ae 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -6,7 +6,9 @@ vkms-y := \
vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
-   vkms_writeback.o
+   vkms_writeback.o \
+   vkms_colorop.o \
+   vkms_luts.o
 
 obj-$(CONFIG_DRM_VKMS) += vkms.o
 obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += tests/
diff --git a/drivers/gpu/drm/vkms/vkms_colorop.c 
b/drivers/gpu/drm/vkms/vkms_colorop.c
new file mode 100644
index ..af319cd3de23
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_colorop.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vkms_drv.h"
+
+static const u64 supported_tfs =
+   BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+   BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF);
+
+#define MAX_COLOR_PIPELINE_OPS 2
+
+static int vkms_initialize_color_pipeline(struct drm_plane *plane, struct 
drm_prop_enum_list *list)
+{
+   struct drm_colorop *ops[MAX_COLOR_PIPELINE_OPS];
+   struct drm_device *dev = plane->dev;
+   int ret;
+   int i = 0;
+
+   memset(ops, 0, sizeof(ops));
+
+   /* 1st op: 1d curve */
+   ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
+   if (!ops[i]) {
+   DRM_ERROR("KMS: Failed to allocate colorop\n");
+   ret = -ENOMEM;
+   goto cleanup;
+   }
+
+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, supported_tfs);
+   if (ret)
+   goto cleanup;
+
+   list->type = ops[i]->base.id;
+   list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", 
ops[i]->base.id);
+
+   i++;
+
+   /* 2nd op: 1d curve */
+   ops[i] = kzalloc(sizeof(*ops[i]), GFP_KERNEL);
+   if (!ops[i]) {
+   DRM_ERROR("KMS: Failed to allocate colorop\n");
+   ret = -ENOMEM;
+   goto cleanup;
+   }
+
+   ret = drm_colorop_curve_1d_init(dev, ops[i], plane, supported_tfs);
+   if (ret)
+   goto cleanup;
+
+   drm_colorop_set_next_property(ops[i - 1], ops[i]);
+
+   return 0;
+
+cleanup:
+   for (; i >= 0; i--)
+   kfree(ops[i]);
+
+   return ret;
+}
+
+int vkms_initialize_colorops(struct drm_plane *plane)
+{
+   struct drm_prop_enum_list pipeline;
+   int ret;
+
+   /* Add color pipeline */
+   ret = vkms_initialize_color_pipeline(plane, &pipeline);
+   if (ret)
+   return ret;
+
+   /* Create COLOR_PIPELINE property and attach */
+   ret = drm_plane_create_color_pipeline_property(plane

[V7 12/45] drm/plane: Add COLOR PIPELINE property

[Alex Hung]

From: Harry Wentland 

We're adding a new enum COLOR PIPELINE property. This
property will have entries for each COLOR PIPELINE by
referencing the DRM object ID of the first drm_colorop
of the pipeline. 0 disables the entire COLOR PIPELINE.

Userspace can use this to discover the available color
pipelines, as well as set the desired one. The color
pipelines are programmed via properties on the actual
drm_colorop objects.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Fix a checkpatch warning - a new line after variable declaration

v4:
 - Add pipeline property creation helper (Pekka)
 - Fix function comment for
   drm_atomic_set_colorop_for_plane (Pekka)
 - Always create Bypass pipeline (Pekka)
 - Add missing function declaration (Chaitanya Kumar Borah)

 drivers/gpu/drm/drm_atomic.c  | 46 
 drivers/gpu/drm/drm_atomic_state_helper.c |  5 +++
 drivers/gpu/drm/drm_atomic_uapi.c | 43 +++
 drivers/gpu/drm/drm_plane.c   | 52 +++
 include/drm/drm_atomic.h  |  3 ++
 include/drm/drm_atomic_uapi.h |  2 +
 include/drm/drm_plane.h   | 11 +
 7 files changed, 162 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 736fa6a11c08..35136987d5e8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1461,6 +1461,52 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
*state,
 }
 EXPORT_SYMBOL(drm_atomic_add_affected_planes);
 
+/**
+ * drm_atomic_add_affected_colorops - add colorops for plane
+ * @state: atomic state
+ * @plane: DRM plane
+ *
+ * This function walks the current configuration and adds all colorops
+ * currently used by @plane to the atomic configuration @state. This is useful
+ * when an atomic commit also needs to check all currently enabled colorop on
+ * @plane, e.g. when changing the mode. It's also useful when re-enabling a 
plane
+ * to avoid special code to force-enable all colorops.
+ *
+ * Since acquiring a colorop state will always also acquire the w/w mutex of 
the
+ * current plane for that colorop (if there is any) adding all the colorop 
states for
+ * a plane will not reduce parallelism of atomic updates.
+ *
+ * Returns:
+ * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
+ * then the w/w mutex code has detected a deadlock and the entire atomic
+ * sequence must be restarted. All other errors are fatal.
+ */
+int
+drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
+struct drm_plane *plane)
+{
+   struct drm_colorop *colorop;
+   struct drm_colorop_state *colorop_state;
+
+   WARN_ON(!drm_atomic_get_new_plane_state(state, plane));
+
+   drm_dbg_atomic(plane->dev,
+  "Adding all current colorops for [plane:%d:%s] to %p\n",
+  plane->base.id, plane->name, state);
+
+   drm_for_each_colorop(colorop, plane->dev) {
+   if (colorop->plane != plane)
+   continue;
+
+   colorop_state = drm_atomic_get_colorop_state(state, colorop);
+   if (IS_ERR(colorop_state))
+   return PTR_ERR(colorop_state);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_atomic_add_affected_colorops);
+
 /**
  * drm_atomic_check_only - check whether a given config would work
  * @state: atomic configuration to check
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 519228eb1095..d1dd082b1286 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -267,6 +267,11 @@ void __drm_atomic_helper_plane_state_reset(struct 
drm_plane_state *plane_state,
plane_state->color_range = val;
}
 
+   if (plane->color_pipeline_property) {
+   /* default is always NULL, i.e., bypass */
+   plane_state->color_pipeline = NULL;
+   }
+
if (plane->zpos_property) {
if (!drm_object_property_get_default_value(&plane->base,
   plane->zpos_property,
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 8a038e04be58..f2503f56fc82 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -256,6 +256,36 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state 
*plane_state,
 }
 EXPORT_SYMBOL(drm_atomic_set_fb_for_plane);
 
+
+/**
+ * drm_atomic_set_colorop_for_plane - set colorop for plane
+ * @plane_state: atomic state object for the plane
+ * @colorop: colorop to use for the plane
+ *
+ * Helper function to select the color pipeline on a plane by setting
+ * it to the first drm_colorop element of the pipeline.
+ */
+void
+drm_atomic_

[V7 15/45] drm/vkms: Add kunit tests for linear and sRGB LUTs

[Alex Hung]

From: Harry Wentland 

Two tests are added to VKMS LUT handling:
- linear
- inv_srgb

Reviewed-by: Louis Chauvet 
Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Fix checkpatch warnings (Louis Chauvet)
  - Adde a commit messages
  - Fix code styles by adding and removing spaces (new lines, tabs and so on)

 drivers/gpu/drm/vkms/tests/vkms_color_test.c | 39 +++-
 drivers/gpu/drm/vkms/vkms_composer.c | 17 ++---
 drivers/gpu/drm/vkms/vkms_composer.h | 13 +++
 3 files changed, 55 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_test.c 
b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
index b53beaac2703..d765c5eb5d88 100644
--- a/drivers/gpu/drm/vkms/tests/vkms_color_test.c
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
@@ -6,6 +6,7 @@
 #include 
 #include "../vkms_drv.h"
 #include "../vkms_composer.h"
+#include "../vkms_luts.h"
 
 #define TEST_LUT_SIZE 16
 
@@ -36,7 +37,6 @@ static const struct vkms_color_lut test_linear_lut = {
.channel_value2index_ratio = 0xf000fll
 };
 
-
 static void vkms_color_test_get_lut_index(struct kunit *test)
 {
s64 lut_index;
@@ -49,6 +49,19 @@ static void vkms_color_test_get_lut_index(struct kunit *test)
lut_index = get_lut_index(&test_linear_lut, 
test_linear_array[i].red);
KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(lut_index), i);
}
+
+   KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(&srgb_eotf, 0x0)), 
0x0);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_eotf, 
0x0)), 0x0);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_eotf, 
0x101)), 0x1);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_eotf, 
0x202)), 0x2);
+
+   KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(&srgb_inv_eotf, 0x0)), 
0x0);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_inv_eotf, 
0x0)), 0x0);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_inv_eotf, 
0x101)), 0x1);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_inv_eotf, 
0x202)), 0x2);
+
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_eotf, 
0xfefe)), 0xfe);
+   KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(&srgb_eotf, 
0x)), 0xff);
 }
 
 static void vkms_color_test_lerp(struct kunit *test)
@@ -155,9 +168,33 @@ static void vkms_color_test_lerp(struct kunit *test)
KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x1, 0x8000), 0x1);
 }
 
+static void vkms_color_test_linear(struct kunit *test)
+{
+   for (int i = 0; i < LUT_SIZE; i++) {
+   int linear = apply_lut_to_channel_value(&linear_eotf, i * 
0x101, LUT_RED);
+
+   KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(linear, 0x101), i);
+   }
+}
+
+static void vkms_color_srgb_inv_srgb(struct kunit *test)
+{
+   u16 srgb, final;
+
+   for (int i = 0; i < LUT_SIZE; i++) {
+   srgb = apply_lut_to_channel_value(&srgb_eotf, i * 0x101, 
LUT_RED);
+   final = apply_lut_to_channel_value(&srgb_inv_eotf, srgb, 
LUT_RED);
+
+   KUNIT_EXPECT_GE(test, final / 0x101, i - 1);
+   KUNIT_EXPECT_LE(test, final / 0x101, i + 1);
+   }
+}
+
 static struct kunit_case vkms_color_test_cases[] = {
KUNIT_CASE(vkms_color_test_get_lut_index),
KUNIT_CASE(vkms_color_test_lerp),
+   KUNIT_CASE(vkms_color_test_linear),
+   KUNIT_CASE(vkms_color_srgb_inv_srgb),
{}
 };
 
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 983654540ee5..ee3cfe153d8f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -113,19 +113,8 @@ VISIBLE_IF_KUNIT s64 get_lut_index(const struct 
vkms_color_lut *lut, u16 channel
 }
 EXPORT_SYMBOL_IF_KUNIT(get_lut_index);
 
-/*
- * This enum is related to the positions of the variables inside
- * `struct drm_color_lut`, so the order of both needs to be the same.
- */
-enum lut_channel {
-   LUT_RED = 0,
-   LUT_GREEN,
-   LUT_BLUE,
-   LUT_RESERVED
-};
-
-static u16 apply_lut_to_channel_value(const struct vkms_color_lut *lut, u16 
channel_value,
- enum lut_channel channel)
+VISIBLE_IF_KUNIT u16 apply_lut_to_channel_value(const struct vkms_color_lut 
*lut, u16 channel_value,
+   enum lut_channel channel)
 {
s64 lut_index = get_lut_index(lut, channel_value);
u16 *floor_lut_value, *ceil_lut_value;
@@ -150,6 +139,8 @@ static u16 apply_lut_to_channel_value(const struct 
vkms_color_lut *lut, u16 chan
return lerp_u16(floor_channel_value, ceil_channel_value,
lut_index & DRM_FIXED_DECIMAL_MASK);
 }
+EXPORT_SYMBOL_IF_KUNIT(apply_lut_to_channel_value);
+
 
 static void apply_lut(const

[V7 13/45] drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

[Alex Hung]

From: Harry Wentland 

With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
 - COLOR_ENCODING
 - COLOR_RANGE

Drivers are expected to ignore these properties when
programming the HW.

Setting of the COLOR_PIPELINE plane property or drm_colorop
properties is only allowed for userspace that sets this
client cap.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---

v5:
 - Fix kernel docs

v4:
 - Don't block setting of COLOR_RANGE and COLOR_ENCODING
   when client cap is set

 drivers/gpu/drm/drm_atomic_uapi.c | 13 -
 drivers/gpu/drm/drm_ioctl.c   |  7 +++
 include/drm/drm_file.h|  7 +++
 include/uapi/drm/drm.h| 16 
 4 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index f2503f56fc82..f0c22abcc28f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -570,6 +570,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (property == plane->color_range_property) {
state->color_range = val;
} else if (property == plane->color_pipeline_property) {
+   if (!file_priv->plane_color_pipeline) {
+   drm_dbg_atomic(dev,
+  "Setting COLOR_PIPELINE plane property 
not permitted unless DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set\n");
+   return -EINVAL;
+   }
+
/* find DRM colorop object */
struct drm_colorop *colorop = NULL;
 
@@ -1180,6 +1186,12 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
case DRM_MODE_OBJECT_COLOROP: {
+   if (!file_priv->plane_color_pipeline) {
+   drm_dbg_atomic(prop->dev,
+  "[OBJECT:%d] is a colorop but 
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE not set\n",
+  obj->id);
+   ret = -EINVAL;
+   }
struct drm_colorop *colorop = obj_to_colorop(obj);
struct drm_colorop_state *colorop_state;
 
@@ -1192,7 +1204,6 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
ret = drm_atomic_colorop_set_property(colorop,
colorop_state, file_priv,
prop, prop_value);
-
break;
}
default:
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 51f39912866f..6b5021b68e35 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -373,6 +373,13 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
return -EINVAL;
file_priv->supports_virtualized_cursor_plane = req->value;
break;
+   case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
+   if (!file_priv->atomic)
+   return -EINVAL;
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->plane_color_pipeline = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 8c0030c77308..6d9a1578c7dc 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -206,6 +206,13 @@ struct drm_file {
 */
bool writeback_connectors;
 
+   /**
+* @plane_color_pipeline:
+*
+* True if client understands plane color pipelines
+*/
+   bool plane_color_pipeline;
+
/**
 * @was_master:
 *
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 16122819edfe..a2fc85ecdea1 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -875,6 +875,22 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT6
 
+/**
+ * DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
+ *
+ * If set to 1 the DRM core will allow setting the COLOR_PIPELINE
+ * property on a &drm_plane, as well as drm_colorop properties.
+ *
+ * Drivers will ignore these drm_plane properties:
+ *  - COLOR_ENCODING
+ *  - COLOR_RANGE
+ *
+ * The client must enable &DRM_CLIENT_CAP_ATOMIC first.
+ *
+ * This capability is currently in development.
+ */
+#define DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE7
+
 /* DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.43.0

[V7 11/45] drm/colorop: Add atomic state print for drm_colorop

[Alex Hung]

From: Harry Wentland 

Print atomic state for drm_colorop in debugfs

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Add a commit messages
 - Squash "drm/colorop: Add NEXT to colorop state print" (Simon Ser)

 drivers/gpu/drm/drm_atomic.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 44c5b5dd8b33..736fa6a11c08 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -777,6 +777,20 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
return 0;
 }
 
+
+
+static void drm_atomic_colorop_print_state(struct drm_printer *p,
+   const struct drm_colorop_state *state)
+{
+   struct drm_colorop *colorop = state->colorop;
+
+   drm_printf(p, "colorop[%u]:\n", colorop->base.id);
+   drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
+   drm_printf(p, "\tbypass=%u\n", state->bypass);
+   drm_printf(p, "\tcurve_1d_type=%s\n", 
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+   drm_printf(p, "\tnext=%d\n", colorop->next ? colorop->next->base.id : 
0);
+}
+
 static void drm_atomic_plane_print_state(struct drm_printer *p,
const struct drm_plane_state *state)
 {
@@ -798,7 +812,8 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
drm_printf(p, "\tcolor-range=%s\n",
   drm_get_color_range_name(state->color_range));
drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
-
+   drm_printf(p, "\tcolor-pipeline=%d\n",
+  state->color_pipeline ? state->color_pipeline->base.id : 0);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
 }
@@ -1842,6 +1857,7 @@ static void __drm_state_dump(struct drm_device *dev, 
struct drm_printer *p,
 bool take_locks)
 {
struct drm_mode_config *config = &dev->mode_config;
+   struct drm_colorop *colorop;
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -1851,6 +1867,14 @@ static void __drm_state_dump(struct drm_device *dev, 
struct drm_printer *p,
if (!drm_drv_uses_atomic_modeset(dev))
return;
 
+   list_for_each_entry(colorop, &config->colorop_list, head) {
+   if (take_locks)
+   drm_modeset_lock(&colorop->plane->mutex, NULL);
+   drm_atomic_colorop_print_state(p, colorop->state);
+   if (take_locks)
+   drm_modeset_unlock(&colorop->plane->mutex);
+   }
+
list_for_each_entry(plane, &config->plane_list, head) {
if (take_locks)
drm_modeset_lock(&plane->mutex, NULL);
-- 
2.43.0

[V7 16/45] drm/colorop: Add 3x4 CTM type

[Alex Hung]

From: Harry Wentland 

This type is used to support a 3x4 matrix in colorops. A 3x4
matrix uses the last column as a "bias" column. Some HW exposes
support for 3x4. The calculation looks like:

 out   matrixin
 |R|   |0  1  2  3 |   | R |
 |G| = |4  5  6  7 | x | G |
 |B|   |8  9  10 11|   | B |
   |1.0|

This is also the first colorop where we need a blob property to
program the property. For that we'll introduce a new DATA
property that can be used by all colorop TYPEs requiring a
blob. The way a DATA blob is read depends on the TYPE of
the colorop.

We only create the DATA property for property types that
need it.

Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---

v6:
 - take ref for DATA blob in duplicate_state func (Xaver Hugl)

v5:
 - Add function signature for init (Sebastian)
 - Fix kernel-doc

v4:
 - Create helper function for creating 3x4 CTM colorop
 - Fix CTM indexes in comment (Pekka)

 drivers/gpu/drm/drm_atomic.c  | 14 ++-
 drivers/gpu/drm/drm_atomic_uapi.c | 29 +
 drivers/gpu/drm/drm_colorop.c | 42 +++
 include/drm/drm_colorop.h | 21 
 include/uapi/drm/amdgpu_drm.h |  9 ---
 include/uapi/drm/drm_mode.h   | 24 +-
 6 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 35136987d5e8..c58663327e6b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -787,7 +787,19 @@ static void drm_atomic_colorop_print_state(struct 
drm_printer *p,
drm_printf(p, "colorop[%u]:\n", colorop->base.id);
drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
drm_printf(p, "\tbypass=%u\n", state->bypass);
-   drm_printf(p, "\tcurve_1d_type=%s\n", 
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+
+   switch (colorop->type) {
+   case DRM_COLOROP_1D_CURVE:
+   drm_printf(p, "\tcurve_1d_type=%s\n",
+  
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+   break;
+   case DRM_COLOROP_CTM_3X4:
+   drm_printf(p, "\tdata blob id=%d\n", state->data ? 
state->data->base.id : 0);
+   break;
+   default:
+   break;
+   }
+
drm_printf(p, "\tnext=%d\n", colorop->next ? colorop->next->base.id : 
0);
 }
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index f0c22abcc28f..7bc4978e5441 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -692,6 +692,30 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
return 0;
 }
 
+static int drm_atomic_color_set_data_property(struct drm_colorop *colorop,
+   struct drm_colorop_state *state,
+   struct drm_property *property, uint64_t val)
+{
+   ssize_t elem_size = -1;
+   ssize_t size = -1;
+   bool replaced = false;
+
+   switch (colorop->type) {
+   case DRM_COLOROP_CTM_3X4:
+   size = sizeof(struct drm_color_ctm_3x4);
+   break;
+   default:
+   /* should never get here */
+   return -EINVAL;
+   }
+
+   return drm_property_replace_blob_from_id(colorop->dev,
+   &state->data,
+   val,
+   size,
+   elem_size,
+   &replaced);
+}
 
 static int drm_atomic_colorop_set_property(struct drm_colorop *colorop,
struct drm_colorop_state *state, struct drm_file *file_priv,
@@ -701,6 +725,9 @@ static int drm_atomic_colorop_set_property(struct 
drm_colorop *colorop,
state->bypass = val;
} else if (property == colorop->curve_1d_type_property) {
state->curve_1d_type = val;
+   } else if (property == colorop->data_property) {
+   return drm_atomic_color_set_data_property(colorop,
+   state, property, val);
} else {
drm_dbg_atomic(colorop->dev,
   "[COLOROP:%d:%d] unknown property 
[PROP:%d:%s]]\n",
@@ -723,6 +750,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
+   } else if (property == colorop->data_property) {
+   *val = (state->data) ? state->data->base.id : 0;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/d

[V7 20/45] drm/vkms: Add tests for CTM handling

[Alex Hung]

From: Harry Wentland 

A whole slew of tests for CTM handling that greatly helped in
debugging the CTM code. The extent of tests might seem a bit
silly but they're fast and might someday help save someone
else's day when debugging this.

Reviewed-by: Louis Chauvet 
Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
---
v7:
 - Fix a checkpatch a long-line warning (Louis Chauvet)

v6:
 - update reference values since we're now rounding

v5:
 - Make apply_3x4_matrix static

v4:
 - Comment on origin of bt709_enc matrix (Pekka)
 - Use full opaque alpha (Pekka)
 - Add additional check for Y < 0x (Pekka)
 - Remove unused code (Pekka)

 drivers/gpu/drm/vkms/tests/vkms_color_test.c | 250 +++
 drivers/gpu/drm/vkms/vkms_composer.c |   4 +-
 drivers/gpu/drm/vkms/vkms_composer.h |   1 +
 3 files changed, 254 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_test.c 
b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
index d765c5eb5d88..e9bc4380fb88 100644
--- a/drivers/gpu/drm/vkms/tests/vkms_color_test.c
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
@@ -190,11 +190,261 @@ static void vkms_color_srgb_inv_srgb(struct kunit *test)
}
 }
 
+#define FIXPT_HALF(DRM_FIXED_ONE >> 1)
+#define FIXPT_QUARTER (DRM_FIXED_ONE >> 2)
+
+static const struct drm_color_ctm_3x4 test_matrix_3x4_50_desat = { {
+   FIXPT_HALF, FIXPT_QUARTER, FIXPT_QUARTER, 0,
+   FIXPT_QUARTER, FIXPT_HALF, FIXPT_QUARTER, 0,
+   FIXPT_QUARTER, FIXPT_QUARTER, FIXPT_HALF, 0
+} };
+
+static void vkms_color_ctm_3x4_50_desat(struct kunit *test)
+{
+   struct pixel_argb_s32 ref, out;
+
+   /* full white */
+   ref.a = 0x;
+   ref.r = 0x;
+   ref.g = 0x;
+   ref.b = 0x;
+
+   memcpy(&out, &ref, sizeof(out));
+   apply_3x4_matrix(&out, &test_matrix_3x4_50_desat);
+
+   KUNIT_EXPECT_MEMEQ(test, &ref, &out, sizeof(out));
+
+   /* full black */
+   ref.a = 0x;
+   ref.r = 0x0;
+   ref.g = 0x0;
+   ref.b = 0x0;
+
+   memcpy(&out, &ref, sizeof(out));
+   apply_3x4_matrix(&out, &test_matrix_3x4_50_desat);
+
+   KUNIT_EXPECT_MEMEQ(test, &ref, &out, sizeof(out));
+
+   /* 50% grey */
+   ref.a = 0x;
+   ref.r = 0x8000;
+   ref.g = 0x8000;
+   ref.b = 0x8000;
+
+   memcpy(&out, &ref, sizeof(out));
+   apply_3x4_matrix(&out, &test_matrix_3x4_50_desat);
+
+   KUNIT_EXPECT_MEMEQ(test, &ref, &out, sizeof(out));
+
+   /* full red to 50% desat */
+   ref.a = 0x;
+   ref.r = 0x8000;
+   ref.g = 0x4000;
+   ref.b = 0x4000;
+
+   out.a = 0x;
+   out.r = 0x;
+   out.g = 0x0;
+   out.b = 0x0;
+
+   apply_3x4_matrix(&out, &test_matrix_3x4_50_desat);
+
+   KUNIT_EXPECT_MEMEQ(test, &ref, &out, sizeof(out));
+}
+
+/*
+ * BT.709 encoding matrix
+ *
+ * Values printed from within IGT when converting
+ * igt_matrix_3x4_bt709_enc to the fixed-point format expected
+ * by DRM/KMS.
+ */
+static const struct drm_color_ctm_3x4 test_matrix_3x4_bt709_enc = { {
+   0x366cf400ull, 0xb7175900ull, 0x000127bb300ull, 0,
+   0x80001993b3a0ull, 0x80005609fe80ull, 0x6f9db200ull, 0,
+   0x9d70a400ull, 0x80008f011100ull, 0x8e6f9330ull, 0
+} };
+
+static void vkms_color_ctm_3x4_bt709(struct kunit *test)
+{
+   struct pixel_argb_s32 out;
+
+   /* full white to bt709 */
+   out.a = 0x;
+   out.r = 0x;
+   out.g = 0x;
+   out.b = 0x;
+
+   apply_3x4_matrix(&out, &test_matrix_3x4_bt709_enc);
+
+   /* Y 255 */
+   KUNIT_EXPECT_GT(test, out.r, 0xfe00);
+   KUNIT_EXPECT_LT(test, out.r, 0x1);
+
+   /* U 0 */
+   KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+   /* V 0 */
+   KUNIT_EXPECT_LT(test, out.b, 0x0100);
+
+   /* full black to bt709 */
+   out.a = 0x;
+   out.r = 0x0;
+   out.g = 0x0;
+   out.b = 0x0;
+
+   apply_3x4_matrix(&out, &test_matrix_3x4_bt709_enc);
+
+   /* Y 0 */
+   KUNIT_EXPECT_LT(test, out.r, 0x100);
+
+   /* U 0 */
+   KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+   /* V 0 */
+   KUNIT_EXPECT_LT(test, out.b, 0x0100);
+
+   /* gray to bt709 */
+   out.a = 0x;
+   out.r = 0x7fff;
+   out.g = 0x7fff;
+   out.b = 0x7fff;
+
+   apply_3x4_matrix(&out, &test_matrix_3x4_bt709_enc);
+
+   /* Y 127 */
+   KUNIT_EXPECT_GT(test, out.r, 0x7e00);
+   KUNIT_EXPECT_LT(test, out.r, 0x8000);
+
+   /* U 0 */
+   KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+   /* V 0 */
+   KUNIT_EXPECT_LT(test, out.b, 0x0100);
+
+   /* == red 255 - bt709 enc == */
+   out.a = 0x;
+   out.r = 0x;
+   out.g = 0x0;
+   out.b = 0x0;
+
+   apply_3x4_ma