Re: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

On Tue, 5 May 2020 10:48:52 +0200 Daniel Vetter wrote: > Refocusing on where I think we still have a bit a disconnnect. > > On Mon, May 04, 2020 at 03:22:28PM +0300, Pekka Paalanen wrote: > > On Mon, 4 May 2020 13:00:02 +0200 > > Daniel Vetter wrote: > > > O

Re: [PATCH 0/6] RFC Support hot device unplug in amdgpu

On Sat, 9 May 2020 14:51:44 -0400 Andrey Grodzovsky wrote: > This RFC is a more of a proof of concept then a fully working > solution as there are a few unresolved issues we are hopping to get > advise on from people on the mailing list. Until now extracting a > card either by physical extraction

Re: [RFC v2] drm/connector: Add support for privacy-screen properties (v2)

rol of > + * the DRM master process means that userspace must not cache the value > + * of the sw-state. Ccaching the sw-state value and including it in later Extra 'c' in "Caching". > + * atomic commits may lead to overriding a state change done through e.g. &g

Re: [RFC v2] drm/connector: Add support for privacy-screen properties (v2)

On Tue, 12 May 2020 10:02:12 +0200 Hans de Goede wrote: > Hi, > > On 5/12/20 9:49 AM, Pekka Paalanen wrote: > > On Mon, 11 May 2020 19:47:24 +0200 > > Hans de Goede wrote: > > > >> From: Rajat Jain > >> > >> Add support for generic

Re: [RFC v2 0/1] drm/connector: Add support for privacy-screen properties

On Tue, 12 May 2020 10:18:31 +0200 Hans de Goede wrote: > Hi, > > On 5/11/20 9:55 PM, Rajat Jain wrote: > > Hi Hans, > > > > On Mon, May 11, 2020 at 10:47 AM Hans de Goede > > wrote: > > > > Hi All, > > > > This RFC takes Rajat's earlier patch for adding p

Re: [RFC v2 0/1] drm/connector: Add support for privacy-screen properties

On Tue, 12 May 2020 18:09:15 +0200 Hans de Goede wrote: > Hi, > > On 5/12/20 4:20 PM, Pekka Paalanen wrote: > > On Tue, 12 May 2020 10:18:31 +0200 > > Hans de Goede wrote: > > > >> Hi, > >> > >> On 5/11/20 9:55 PM, Rajat Jain wrote: &g

Re: [RFC v2 0/1] drm/connector: Add support for privacy-screen properties

On Wed, 13 May 2020 11:28:38 -0700 Rajat Jain wrote: > On Wed, May 13, 2020 at 12:49 AM Pekka Paalanen wrote: ... > > On Tue, 12 May 2020 10:38:11 -0700 > > Rajat Jain wrote: > > > > > The chrome browser currently uses the API exposed by my (previous) >

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

(make/model/serial) and > > supported color-spaces. > > > > Signed-off-by: Simon Ser > > Suggested-by: Daniel Vetter > > Cc: Daniel Vetter Reviewed-by: Pekka Paalanen > > Cc: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_connector.c | 4 > >

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

On Fri, 9 Oct 2020 16:10:25 +0300 Ville Syrjälä wrote: > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > > Hi, > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > > > User-space should avoid parsing EDIDs for metadata already exposed via > > > other KMS interfaces and prop

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

On Fri, 9 Oct 2020 17:20:18 +0300 Ville Syrjälä wrote: > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote: > > On Fri, 9 Oct 2020 16:10:25 +0300 > > Ville Syrjälä wrote: > > > > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: &

Re: [PATCH 3/3] drm/vkms: fbdev emulation support

On Mon, 12 Oct 2020 16:23:35 +0200 Daniel Vetter wrote: > On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote: > > Hi, > > ... > > It's weird because it the kernel is misconfigured and no console is > > specified on the cmdline > > this console could become the main console... > >

Re: [PATCH 3/3] drm/vkms: fbdev emulation support

On Tue, 13 Oct 2020 09:53:44 +0200 Daniel Vetter wrote: > On Tue, Oct 13, 2020 at 8:14 AM Pekka Paalanen wrote: > > > > On Mon, 12 Oct 2020 16:23:35 +0200 > > Daniel Vetter wrote: > > > > > On Mon, Oct 12, 2020 at 02:40:58PM +0200

Re: [PATCH] drm: document that user-space should avoid parsing EDIDs

On Fri, 16 Oct 2020 16:50:16 +0300 Ville Syrjälä wrote: > On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote: > > On Fri, 9 Oct 2020 17:20:18 +0300 > > Ville Syrjälä wrote: > > > > > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:

Re: [PATCH] drm: add client cap to expose low power modes

On Wed, 21 Oct 2020 18:09:05 +0100 Daniel Stone wrote: > On Wed, 21 Oct 2020 at 17:34, Daniel Vetter wrote: > > On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote: > > > It makes sense to me: some modes are annotated with a 'low-power' > > > flag, tucked away behind a client cap whic

Re: [PATCH] drm: deprecate DRM_FORMAT_MOD_NONE

LINEAR, however the > name is confusing: NONE doesn't mean that the modifier is implicit, > instead it means that the layout is linear. Deprecate it. > > Signed-off-by: Simon Ser > Suggested-by: Bas Nieuwenhuizen > Cc: Daniel Vetter > Cc: Pekka Paalanen > --- > i

Re: [PATCH v2] drm: document that user-space should avoid parsing EDIDs

't do this (Brian) > > Signed-off-by: Simon Ser > Suggested-by: Daniel Vetter > Reviewed-by: Daniel Vetter > Acked-by: Thomas Zimmermann > Cc: Pekka Paalanen > Cc: Ville Syrjälä > Cc: Brian Starkey > --- > drivers/gpu/drm/drm_connector.c | 5 + >

Re: [PATCH libdrm] xf86drm.c: Use integer logarithm.

On Mon, 26 Oct 2020 16:11:20 +0300 Paul Gofman wrote: > log() is affected by FP control word and can provide inaccurate result. > > Fixes Killer Instinct under Wine not being able to find AMD vulkan > device. > > Signed-off-by: Paul Gofman > --- > With the rounding mode the application set

Re: [systemd-devel] DisplayPort display non-persistent device naming

On Thu, 29 Oct 2020 21:53:34 +0100 Marcin Kocur wrote: > Hello, > > this is the output of turning off and on my display (using power button): ... > The monitor was visible in xrandr as DP-2, after power off and on it's > visible as DP-3 (DP-2 is still there "disconnected"). > > It's troubles

Re: [PATCH libdrm 2/2] include: Avoid potentially infinite loop in log2_int().

On Wed, 28 Oct 2020 13:06:02 +0300 Paul Gofman wrote: > Signed-off-by: Paul Gofman > --- > util_math.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/util_math.h b/util_math.h > index e2fa95f5..f6bbe192 100644 > --- a/util_math.h > +++ b/util_math.h > @@ -38,6 +38,9 @@ static inli

Re: [PATCH v5 13/13] drm/print: Add tracefs support to the drm logging helpers

r > consumption. > > Using the new tracefs instance will allow distros to enable drm logging > in production without impacting performance or spamming the system > logs. > > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Pekka

Re: [PATCH v5 13/13] drm/print: Add tracefs support to the drm logging helpers

On Wed, 10 Jun 2020 09:29:37 -0400 Sean Paul wrote: > On Wed, Jun 10, 2020 at 3:57 AM Pekka Paalanen wrote: > > > > On Mon, 8 Jun 2020 17:05:03 -0400 > > Sean Paul wrote: > > > > > From: Sean Paul > > > > > > This patch adds a new mod

[PATCH v4] drm/doc: device hot-unplug for userspace

From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . A related Wayland pro

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

On Mon, 22 Jun 2020 11:35:01 +0200 Daniel Vetter wrote: > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote: > > Will be used to reroute CPU mapped BO's page faults once > > device is removed. > > > > Signed-off-by: Andrey Grodzovsky > > --- > > drivers/gpu/drm/drm_file.c | 8

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

On Mon, 22 Jun 2020 16:24:38 +0200 Daniel Vetter wrote: > On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen wrote: > > > > On Mon, 22 Jun 2020 11:35:01 +0200 > > Daniel Vetter wrote: > > > > > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrot

Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state

On Thu, 25 Jun 2020 09:57:44 +0200 Daniel Vetter wrote: > On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote: > > > > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote: > > > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote: > > > > > > > > On Wed, Jun 24, 2020 at 5:24 PM Ale

Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state

On Thu, 25 Jun 2020 12:44:36 +0200 Daniel Vetter wrote: > On Thu, Jun 25, 2020 at 12:32 PM Pekka Paalanen wrote: > > > > On Thu, 25 Jun 2020 09:57:44 +0200 > > Daniel Vetter wrote: > > > > > On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote: > >

Re: [RFC] drm: expose connector status values in uapi

ode.h, and copy over the docs. Keep using the > drm_connector_status enum in drivers, because it allows for nice things > when using the enum as a type. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Pekka Paalanen > --- > > - Would something like this be d

Re: [RFC] drm: expose connector status values in uapi

On Fri, 26 Jun 2020 12:05:16 + Simon Ser wrote: > On Friday, June 26, 2020 11:15 AM, Pekka Paalanen wrote: > > > I have no opinion really if adding yet another set of the same > > definitions is good or not. We do need the UAPI doc, but that does not > > neces

Re: [git pull] drm for 5.8-rc1

On Wed, 1 Jul 2020 12:45:48 -0700 James Jones wrote: > OK, I think I see what's going on. In the Xorg modesetting driver, the > logic is basically: > > if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) { >drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm)); > } else { >

[PATCH v5] drm/doc: device hot-unplug for userspace

From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . A related Wayland pro

Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout

On Wed, 25 Mar 2020 11:24:15 +0100 Neil Armstrong wrote: > Hi, > > On 25/03/2020 10:04, Simon Ser wrote: > > On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong > > wrote: > > > >> Amlogic uses a proprietary lossless image compression protocol and format > >> for their hardware video codec

Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout

On Wed, 25 Mar 2020 17:18:15 +0100 Neil Armstrong wrote: > Hi, > > On 25/03/2020 14:49, Pekka Paalanen wrote: > > On Wed, 25 Mar 2020 11:24:15 +0100 > > Neil Armstrong wrote: > > > >> Hi, > >> > >> On 25/03/2020 10:04, Simon Ser wro

Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout

On Fri, 27 Mar 2020 15:14:46 +0100 Neil Armstrong wrote: > Hi, > > On 26/03/2020 10:36, Pekka Paalanen wrote: > > On Wed, 25 Mar 2020 17:18:15 +0100 > > Neil Armstrong wrote: > > > >> Hi, > >> > >> On 25/03/2020 14:49, Pekka Paal

Re: [PATCH v3 0/5] Introduce drm scaling filter property

On Mon, 30 Mar 2020 19:30:27 + Simon Ser wrote: > Hi, > > On Monday, March 30, 2020 8:38 PM, Pankaj Bharadiya > wrote: > > > Userspace patch series link: https://github.com/lrusak/xbmc/pull/24 > > This pull request is against a fork, not the official Kodi repository. > Are there any pl

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

On Tue, 31 Mar 2020 20:59:39 -0500 Daniel Dadap wrote: > On 3/30/20 10:11 AM, Jani Nikula wrote: > > On Fri, 27 Mar 2020, Daniel Dadap wrote: > >> A number of hybrid GPU notebook computer designs with dual (integrated > >> plus discrete) GPUs are equipped with multiplexers (muxes) that allow >

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

On Thu, 2 Apr 2020 13:39:25 +0200 Lukas Wunner wrote: > Note that vga_switcheroo is currently controlled via debugfs. > That is a historic artefact. The kernel has since gained a > mux subsystem in drivers/mux/ which could be used to represent > the display mux in a standardized way in regular s

Re: Aliases for DRI connectors?

On Wed, 1 Apr 2020 14:38:37 -0500 Matt Hoosier wrote: > I'm searching for some sort of scheme that will let my DRI master query the > set of available connectors and select the one carrying a prearranged > designation. The problem I'm trying to solve is to allow deploying one > standardized users

Re: Aliases for DRI connectors?

On Fri, 3 Apr 2020 10:28:52 +0200 Guillermo Rodriguez wrote: > Hi Pekka, > > El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen > () escribió: > > > > On Wed, 1 Apr 2020 14:38:37 -0500 > > Matt Hoosier wrote: > > > > > I'm searching for som

Re: KMS enums and bitfields UAPI

On Fri, 03 Apr 2020 10:15:21 + Simon Ser wrote: > Hi all, > > I've been working on a library called libliftoff [1]. This library allows > users > to set KMS properties on a hardware planes abstraction called layers. > Basically, library users create as many layers as they want with the KMS

Re: Curtaining API / Force blanking displays

On Fri, 3 Apr 2020 12:56:33 -0700 Erik Jensen wrote: > First off, apologies if the functionality described already exists and I > just failed to find it, or if this isn't the correct venue for this > discussion. If so, pointers to the correct location would be appreciated. > > I'm currently look

Re: [PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

On Wed, 1 Apr 2020 18:13:32 +0300 Andy Shevchenko wrote: > On Wed, Apr 01, 2020 at 04:13:51PM +0200, Hans Verkuil wrote: > > On 4/1/20 4:05 PM, Sakari Ailus wrote: > > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM > > > pixel formats denoted by 4ccs. The 4cc encoding

Re: Curtaining API / Force blanking displays

On Mon, 6 Apr 2020 12:01:30 -0700 Erik Jensen wrote: > Thanks for the reply! (And thanks Simon for the pointer to ffmpeg.) > > > Screen scraping like that will have big problems trying to a) > > synchronize to the display updates correctly (was the screen > > updated, did you get old or new fram

UAPI doc (Re: KMS enums and bitfields UAPI)

On Wed, 15 Apr 2020 10:40:36 + Simon Ser wrote: > On Tuesday, April 14, 2020 3:33 PM, Daniel Vetter wrote: > > > > What I'm suggesting isn't to make all enum values UAPI. I'm suggesting > > > to add standard enum values as #defines in the UAPI headers to make > > > these values UAPI. Non-st

Re: RFC: Drm-connector properties managed by another driver / privacy screen support

On Wed, 15 Apr 2020 17:40:46 +0200 Hans de Goede wrote: > Hi, > > On 4/15/20 5:28 PM, Jani Nikula wrote: > > On Wed, 15 Apr 2020, Hans de Goede wrote: > >> ii. Currently the "privacy-screen" property added by Rajat's > >> patch-set is an enum with 2 possible values: > >> "Enabled" > >> "Disab

Re: RFC: Drm-connector properties managed by another driver / privacy screen support

On Thu, 16 Apr 2020 00:10:06 +0300 Jani Nikula wrote: > On Wed, 15 Apr 2020, Rajat Jain wrote: > > * I think having 2 properties might be a confusing UAPI. Also, we have > > existing properties like link-status that can be changed by both the > > user and the hardware. > > I think the consen

Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

On Fri, 17 Apr 2020 16:17:18 +0200 Daniel Vetter wrote: > On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen wrote: > > > > Hi, > > > > let's think about how userspace uses atomic KMS UAPI. The simplest way > > to use atomic correctly is that userspace w

Re: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

On Mon, 20 Apr 2020 11:27:04 +0300 Pekka Paalanen wrote: > On Fri, 17 Apr 2020 16:17:18 +0200 > Daniel Vetter wrote: > > > On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen > > wrote: > > > > > > Hi, > > > > > > let's think about

Re: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)

On Mon, 20 Apr 2020 10:15:39 + Simon Ser wrote: > On Monday, April 20, 2020 10:27 AM, Pekka Paalanen > wrote: > > > The only "random" KMS state is the properties the userspace KMS > > program does not know that are set on start-up. I have been assuming &g

Re: [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix

On Mon, 21 Sep 2020 14:08:48 +0300 Tomi Valkeinen wrote: > Hi, > > On 04/09/2019 23:20, Ilia Mirkin wrote: > > >> Implement CTM color management property for OMAP CRTC using DSS > >> overlay manager's Color Phase Rotation matrix. The CPR matrix does not > >> exactly match the CTM pr

Re: [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix

On Tue, 22 Sep 2020 10:44:38 +0300 Tomi Valkeinen wrote: > On 21/09/2020 14:49, Pekka Paalanen wrote: > > > would it not be simplest if KMS UAPI specification defined the abstract > > color pipeline with all the blocks that may be exposed with > > driver-agnostic UAPI, a

Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit

On Tue, 22 Sep 2020 20:18:34 +0200 Daniel Vetter wrote: > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > pull in arbitrary other resources, including CRTCs (e.g. when > reconfiguring global resources). > > But in nonblocking mode userspace has then no idea this happened

Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit

On Wed, 23 Sep 2020 11:26:39 +0200 Daniel Vetter wrote: > I'm really not awake yet ... > > On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen wrote: > > > > On Tue, 22 Sep 2020 20:18:34 +0200 > > Daniel Vetter wrote: > > > > > When doing an atomic

Re: [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY

On Wed, 23 Sep 2020 22:01:25 +0200 Daniel Vetter wrote: > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad wrote: > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resourc

Re: [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY

On Thu, 24 Sep 2020 10:04:12 +0200 Daniel Vetter wrote: > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen wrote: > > > > On Wed, 23 Sep 2020 22:01:25 +0200 > > Daniel Vetter wrote: > > > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad > > > wro

Re: [PATCH 1/5] drm: add legacy support for using degamma for gamma

ed instead of drm_atomic_helper_legacy_gamma_set() when > the DEGAMMA_LUT is the underlying property that needs to be set. > This sounds and looks right to me fwiw, so Reviewed-by: Pekka Paalanen Thanks, pq > --- > drivers/gpu/drm/drm_atomic_helper.c | 81 ++--

Re: [PATCH 2/5] drm/omap: use degamma property for gamma table

and the legacy ioctl will continue working as before. > Makes sense to me: Reviewed-by: Pekka Paalanen Thanks, pq > --- > drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc

Re: [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY

On Wed, 23 Sep 2020 17:18:52 +0200 Daniel Vetter wrote: > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > pull in arbitrary other resources, including CRTCs (e.g. when > reconfiguring global resources). > > But in nonblocking mode userspace has then no idea this happened

Re: [PATCH 2/2] drm/atomic: debug output for EBUSY

On Wed, 23 Sep 2020 12:57:37 +0200 Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. > These debug messages will be especially useful with the flight recorder, but also without. :-) ... >

Re: [PATCH 2/2] drm/atomic: debug output for EBUSY

On Fri, 25 Sep 2020 10:46:51 +0200 Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. > > v2: Move misplaced hunk to the right patch (Pekka) Hi, both patches Acked-b

Re: [PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()

On Mon, 28 Sep 2020 12:24:28 +0200 Gerd Hoffmann wrote: > Hi, > > > > I don't quite remember where exactly this was implemented. It was not a > > > shared buffer, though. IIRC the buffer allocation code in one of the > > > libs rounded the size towards multiples of 64. I remember thinking that

Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On Sat, 22 Aug 2020 11:59:26 +0200 Michel Dänzer wrote: > On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > > On 2020-08-21 12:57 p.m., Michel Dänzer wrote: > >> From: Michel Dänzer > >> > >> Don't check drm_crtc_state::active for this either, per its > >> documentation in include/drm/drm

Re: [PATCH] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On Tue, 25 Aug 2020 12:58:19 -0400 "Kazlauskas, Nicholas" wrote: > On 2020-08-22 5:59 a.m., Michel Dänzer wrote: > > On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote: > >> On 2020-08-21 12:57 p.m., Michel Dänzer wrote: > >>> From: Michel Dänzer > >>> > >>> Don't check drm_crtc_state::acti

Printing bitfields in the kernel (Re: [PATCH] drm: Parse Colorimetry data block from EDID)

On Wed, 26 Aug 2020 22:23:28 +0800 Algea Cao wrote: > CEA 861.3 spec adds colorimetry data block for HDMI. > Parsing the block to get the colorimetry data from > panel. > > Signed-off-by: Algea Cao > --- > > drivers/gpu/drm/drm_edid.c | 45 + > include/drm

Re: [PATCH] drm/doc: Document that modifiers are always required for fb

On Wed, 2 Sep 2020 12:24:40 +0200 Daniel Vetter wrote: > Even for legacy userspace, since otherwise GETFB2 is broken and if you > switch between modifier-less and modifier-aware compositors, smooth > transitions break. > > Also it's just best practice to make sure modifiers are invariant for >

Re: [PATCH] drm/doc: Document that modifiers are always required for fb

On Wed, 2 Sep 2020 13:15:49 +0200 Daniel Vetter wrote: > On Wed, Sep 2, 2020 at 1:02 PM Pekka Paalanen wrote: > > > > On Wed, 2 Sep 2020 12:24:40 +0200 > > Daniel Vetter wrote: > > > > > Even for legacy userspace, since otherwise GETFB2 is broken and

Re: [PATCH] drm/doc: Document that modifiers are always required for fb

On Mon, 7 Sep 2020 10:41:37 +0200 Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 08:37:31AM +, Simon Ser wrote: > > On Monday, September 7, 2020 10:31 AM, Daniel Vetter > > wrote: > > > > > On Wed, Sep 02, 2020 at 02:59:49PM +, Simon Ser wrote: > > > > > > > On Wednesday, September

Re: per-plane LUTs and CSCs?

On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu wrote: > Hi all, > > I was wondering whether you could give me an advise on how to proceed further > with the following issue as I'm preparing to upstream the next set of patches > for the iMX8MQ display controller(DCSS). The display controller h

Re: per-plane LUTs and CSCs?

On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote: > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote: > > On Wed, 9 Sep 2020 13:57:28 +0300 > > Laurentiu Palcu wrote: > > > > > Hi all, > > > > > > I was wondering wheth

Re: per-plane LUTs and CSCs?

On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote: > Hi Pekka, > > On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote: > > On Thu, 10 Sep 2020 09:52:26 +0200 > > Daniel Vetter wrote: > > > > > On Thu, Sep 10, 2020 at 10:25:43AM +0300

Re: per-plane LUTs and CSCs?

ly Prosyak wrote: > >>> On 2020-09-10 6:56 a.m., Laurent Pinchart wrote: > >>>> On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote: > >>>>> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote: > >>>>>> On Thu, Se

Re: [PATCH] drm: drivers may provide multiple primary planes per CRTC

On Fri, 7 Aug 2020 11:07:06 +0200 Daniel Vetter wrote: > On Thu, Aug 06, 2020 at 10:33:31AM +, Simon Ser wrote: > > Some drivers may expose primary planes compatible with multiple CRTCs. > > Make this clear in the docs: the current wording may be misunderstood as > > "exactly one primary plan

Re: How to prevent input devices from unblanking the X screen when DPMS is on?

On Fri, 7 Aug 2020 16:07:35 +0200 Merlijn Wajer wrote: > Hi, > > Is it possible to have X handle input events, but not actually unblank > the screen upon input events when dpms is enabled? Hi, by "blanking", do you mean that the CRTC turns off (as opposed to the display turning off) so that it

Re: How to prevent input devices from unblanking the X screen when DPMS is on?

On Mon, 10 Aug 2020 10:43:42 +0200 Merlijn Wajer wrote: > Hi Pekka, > > Thanks for the reply - > > On 10/08/2020 09:43, Pekka Paalanen wrote: > > On Fri, 7 Aug 2020 16:07:35 +0200 > > Merlijn Wajer wrote: > > > >> Hi, > >> > >> Is

Re: [PATCH 4/6] drm/rockchip: dw_hdmi: Add vendor hdmi properties

On Wed, 12 Aug 2020 16:30:17 +0300 Laurent Pinchart wrote: > Hi Algea, > > On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote: > > 在 2020/8/12 17:33, Laurent Pinchart 写道: > > > On Wed, Aug 12, 2020 at 04:35:43PM +0800, Algea Cao wrote: > > >> Introduce struct dw_hdmi_property_ops in plat_da

Re: [PATCH 4/6] drm/rockchip: dw_hdmi: Add vendor hdmi properties

On Thu, 13 Aug 2020 13:45:22 +0300 Laurent Pinchart wrote: > On Thu, Aug 13, 2020 at 10:42:28AM +0300, Pekka Paalanen wrote: > > On Wed, 12 Aug 2020 16:30:17 +0300 Laurent Pinchart wrote: > > > On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote: > > > > 在 2020/

Re: [PATCH] drm/vkms: add alpha-premultiplied color blending

On Wed, 19 Aug 2020 17:53:36 -0300 Melissa Wen wrote: > The current VKMS blend function ignores alpha channel and just overwrites > vaddr_src with vaddr_dst. This XRGB approach triggers a warning when > running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT > tests, cairo_format_ar

[PATCH] drm/doc: device hot-unplug for userspace

From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . Signed-off-by:

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Tue, 19 May 2020 10:37:12 -0400 Andrey Grodzovsky wrote: > Thanks for the summary, does put things in order and makes it easier to > comprehend all the TODOs, some questions bellow > > On 5/19/20 6:06 AM, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > >

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Wed, 20 May 2020 16:19:00 +0200 Daniel Vetter wrote: > On Wed, May 20, 2020 at 3:20 PM Simon Ser wrote: > > > > On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter wrote: > > > > > Maybe we should add an explicit note that there's no guarantee about the > > > new chardev minor this new devic

[PATCH v2] drm/doc: device hot-unplug for userspace

From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . Signed-off-by:

Re: [PATCH v2] drm: add docs for standard CRTC properties

On Thu, 21 May 2020 11:09:31 + Simon Ser wrote: > This patch adds docs for the ACTIVE and MODE_ID CRTC properties. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Michel Dänzer > Cc: Daniel Stone > --- >

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 09:51:30 -0400 Andrey Grodzovsky wrote: > On 5/25/20 8:46 AM, Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > Set up the expectations on how hot-unplugging a DRM device should look like > > to > > userspace. > > > >

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 16:28:04 +0200 Daniel Vetter wrote: > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote: > > > > On 5/20/20 8:46 AM, Daniel Vetter wrote: > > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote: > > > >

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 16:30:17 +0200 Daniel Vetter wrote: > On Mon, May 25, 2020 at 09:51:30AM -0400, Andrey Grodzovsky wrote: > > On 5/25/20 8:46 AM, Pekka Paalanen wrote: > > > > > From: Pekka Paalanen > > > > > > Set up the expectations on h

Re: Dynamically change enumeration list of DRM enumeration property

On Tue, 26 May 2020 10:01:23 +0530 Yogish Kulkarni wrote: > Hi, > > Is it possible to dynamically change enumeration list of DRM enumeration > property ? Motivation behind this question is to understand whether it is > possible to create connector enum property (e.g a property which will list >

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Tue, 26 May 2020 10:30:20 -0400 Andrey Grodzovsky wrote: > On 5/19/20 6:06 AM, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > Set up the expectations on how hot-unplugging a DRM device should look like > > to > > userspace. > > > > W

Re: [PATCH] drm/doc: device hot-unplug for userspace

n Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky > > >> wrote: > > >>> > > >>> On 5/27/20 2:44 AM, Pekka Paalanen wrote: > > >>>> On Tue, 26 May 2020 10:30:20 -0400 > > >>>> Andrey Grodzovsky wrote: > > >>>&g

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 17:09:55 +0200 Daniel Vetter wrote: > On Mon, May 25, 2020 at 05:55:19PM +0300, Pekka Paalanen wrote: > > On Mon, 25 May 2020 16:28:04 +0200 > > Daniel Vetter wrote: > > > > > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote:

Re: Dynamically change enumeration list of DRM enumeration property

On Thu, 28 May 2020 17:38:59 +0530 Yogish Kulkarni wrote: > I am trying to find a way through Weston which will allow setting specific > encoding at display output. Hi, why do *you* want to control that? Why not let the driver always choose the highest possible encoding given the video mode an

Re: [PATCH] xf86drm: add drmOpenByFB

On Thu, 28 May 2020 17:46:08 +0800 Chih-Wei Huang wrote: > The main problem we're trying to solve is to > find the DRM device of the primary framebuffer (fb0). Hi, I would say that is a completely wrong starting point. Please, let fbdev die in peace/pieces. Do not make any new code that relies

Re: Dynamically change enumeration list of DRM enumeration property

ATS property is somewhat similar, although more complicated because it is the combination of format and modifier. > (Since I am using my Gmail Id, I feel I should mention that I work at > Nvidia) Nice to know the source of interest. :-) Thanks, pq > > Thanks, > -Yogish > &g

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Thu, 28 May 2020 16:45:45 +0200 Daniel Vetter wrote: > On Thu, May 28, 2020 at 03:27:57PM +0300, Pekka Paalanen wrote: ... > > Hmm. Maybe Wayland compositors should ignore all EGL import failures > > that happen after the wl_buffer has been created (which implies that >

[PATCH v3] drm/doc: device hot-unplug for userspace

From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . A related Wayland pro

Re: [PATCH] drm: document how user-space should use link-status

rm/igt-gpu-tools/-/commit/fbe61f529737191d0920521946a575bd55f00fbe > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Manasi Navare > Cc: Pekka Paalanen > --- > drivers/gpu/drm/drm_connector.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c

Re: Dynamically change enumeration list of DRM enumeration property

On Wed, 3 Jun 2020 10:50:28 +0530 Yogish Kulkarni wrote: > Inline.. > > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote: > > > On Mon, 1 Jun 2020 09:22:27 +0530 > > Yogish Kulkarni wrote: > > > > > Hi, > > > > > > For lett

Re: [PATCH v2] drm: document how user-space should use link-status

521946a575bd55f00fbe > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Manasi Navare > Cc: Pekka Paalanen > --- > drivers/gpu/drm/drm_connector.c | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c b/dri

Re: [PATCH] fbdev: geocode: Add the missed pci_disable_device() for gx1fb_map_video_memory()

On Wed, 3 Jun 2020 17:25:47 +0800 Chuhong Yuan wrote: > Although gx1fb_probe() has handled the failure of gx1fb_map_video_memory() > partly, it does not call pci_disable_device() as gx1fb_map_video_memory() > calls pci_enable_device(). > Add the missed function call to fix the bug. > > Fixes: 5

Re: Dynamically change enumeration list of DRM enumeration property

On Wed, 03 Jun 2020 20:20:44 + (UTC) Jonas Karlman wrote: > Hi, > > On 2020-06-03 11:12, Pekka Paalanen wrote: > > On Wed, 3 Jun 2020 10:50:28 +0530 > > Yogish Kulkarni wrote: > > ... > >> The primary reason for why content producer masters video/

Re: [PATCH v3] drm: document how user-space should use link-status

> > > > I'm not 100% sure the paragraph about not resetting link-status or not > > using ALLOW_MODESET is accurate. Just like the previous version, this > > is just an attempt at documenting the current kernel behaviour. > > > > drivers/gpu/drm/drm_connector.c | 20 > > 1 file

Re: [PATCH v3] drm/doc: device hot-unplug for userspace

On Mon, 1 Jun 2020 17:32:03 +0300 Pekka Paalanen wrote: > Set up the expectations on how hot-unplugging a DRM device should look like to > userspace. > > Written by Daniel Vetter's request and largely based on his comments in IRC > and > from https://lists.freedesktop

<    3   4   5   6   7   8   9   10   11   >