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

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 th

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

t 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 v

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

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

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

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: >> > &g

Re: About migrating framebuffers in multi-GPU compositors

MA 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

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

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

e 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 d

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

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

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

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

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

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

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

ic 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?

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 wor

X.Org Foundation Membership Renewal

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

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

d 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: in

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

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

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

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.

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

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 lin

Re: Beginnings of multiple monitor

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

Re: Future desktop on dumb frame buffers?

tel, 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

Re: Future desktop on dumb frame buffers?

b 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. General

Google Summer of Code 2016

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

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 ma

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

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 usual

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

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, 2

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

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/

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

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

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

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 Dat

X.Org Google Summer of Code

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.

Re: [PATCH] xRandr strikes back

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

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

X.Org Google Summer of Code

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

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

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 co

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

d to report the size in output > coordinates. > > It also seems right from a user perspective. The list of resolutions > would be "2880x1800, 1920x1200, 1400x900", which is to a first degree > what users will experience with these modes. Furthermore, this will > allow us t

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

t'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 __

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

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(+) d

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

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(+) d

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

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 b

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

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 b

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

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: Alexan

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

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 --- shar

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

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

[PATCH] compositor-drm: fix EGL format type

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

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

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 man

Re: Thoughts about decoration information in the xdg_shell

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,

Re: Thoughts about decoration information in the xdg_shell

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

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

t 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!

plish 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 ___ way

Re: Graphics memory management in ARM/Embedded Linux

ting 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 ther

Re: RFC: multitouch support v2

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/mous

Re: RFC: multitouch support v2

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. Ima

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

于 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->b

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

r 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

于 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 +

Re: [PATCH v2] shell: Fix Bug 48906

于 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

Re: [PULL weston] simple fixes

于 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",

Re: Weston on Android - First light

于 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,

Re: Migration guide?

于 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

Re: Wayland on Embedded

ng 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://li

Re: GTK Ubuntu Precise packaging success

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 c

Re: GTK Ubuntu Precise packaging success

? 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

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

? 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 p

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

lay 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:4

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

Re: [RFC] VTs for multiple seats

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

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

于 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 su

Bug: wayland performance halfed when running es2gears_wayland at fedora17

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, Ubun

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

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

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

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

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

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

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

: 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

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

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

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

ch 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 Wen

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

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

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

-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

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

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/di

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

-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

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

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

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

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

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

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

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

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

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

eason 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

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

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

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

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

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

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

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

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

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

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-state

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

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

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

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

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

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

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

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

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

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

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

-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

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

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

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

hout 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_c

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

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 cre

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

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

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

s 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&#x

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

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 +++

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

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 f

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

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 Hu

  1   2   3   >