All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Rajat Jain <rajatja@google.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Pearson <mpearson@lenovo.com>
Cc: Benjamin Berg <bberg@redhat.com>, David Airlie <airlied@linux.ie>,
	Christian Kellner <ckellner@redhat.com>,
	Javier Martinez Canillas <javierm@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Nitin Joshi1 <njoshi1@lenovo.com>
Subject: Re: RFC: Drm-connector properties managed by another driver / privacy screen support
Date: Fri, 17 Apr 2020 12:05:06 +0300	[thread overview]
Message-ID: <20200417120506.16db8df9@eldfell.localdomain> (raw)
In-Reply-To: <87pnc84frl.fsf@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 1222 bytes --]

On Thu, 16 Apr 2020 00:10:06 +0300
Jani Nikula <jani.nikula@linux.intel.com> wrote:

> On Wed, 15 Apr 2020, Rajat Jain <rajatja@google.com> 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 consensus is that all properties that get changed by both
> userspace and the kernel are mistakes, and the way to handle it is to
> have two properties.

Yes, I very much agree with Jani.

I don't like KMS properties that are writable by both the driver and
userspace. It's awkward to handle in userspace and fundamentally racy
aside from tricks like "what you wrote is not what you read back". I
have ranted against that when looking at HDCP properties, e.g.:
https://lists.freedesktop.org/archives/dri-devel/2019-July/226424.html

See also my other email in this thread about how userspace uses atomic
KMS UAPI: you must expect that userspace will always write the
property for any KMS update, even if it does not change its value, so
any change done by the kernel is randomly lost unless the property is
read-only or otherwise weird.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-04-17  9:05 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15  9:42 RFC: Drm-connector properties managed by another driver / privacy screen support Hans de Goede
2020-04-15  9:52 ` Daniel Vetter
2020-04-15 10:11   ` Hans de Goede
2020-04-15 10:22     ` Daniel Vetter
2020-04-15 11:39       ` Hans de Goede
2020-04-15 11:56         ` Hans de Goede
2020-04-15 12:01         ` Daniel Vetter
2020-04-15 13:02           ` Hans de Goede
2020-04-15 17:54             ` Daniel Vetter
2020-04-15 18:19               ` Hans de Goede
2020-04-15 18:29                 ` Daniel Vetter
2020-04-15 19:50                   ` Hans de Goede
2020-04-16  6:46                     ` Daniel Vetter
2020-04-15 15:28 ` Jani Nikula
2020-04-15 15:40   ` Hans de Goede
2020-04-15 17:14     ` [External] " Mark Pearson
2020-04-15 18:06       ` Hans de Goede
2020-04-15 19:20     ` Rajat Jain
2020-04-15 21:10       ` Jani Nikula
2020-04-15 21:21         ` Hans de Goede
2020-04-15 21:51           ` [External] " Mark Pearson
2020-04-17  9:05         ` Pekka Paalanen [this message]
2020-04-17  9:02     ` Pekka Paalanen
2020-04-17 11:55       ` Jani Nikula
2020-04-17 14:18         ` Daniel Vetter
2020-04-17 14:54           ` Benjamin Berg
2020-04-21 12:37         ` Hans de Goede
2020-04-21 12:40           ` Daniel Vetter
2020-04-21 14:46           ` Pekka Paalanen
2020-04-23 18:21             ` Rajat Jain
2020-04-24  7:40               ` Pekka Paalanen
2020-04-24  8:24                 ` Hans de Goede
2020-04-24  9:08                   ` Pekka Paalanen
2020-04-24 10:32                     ` Hans de Goede
2020-04-17 14:17       ` Daniel Vetter
2020-04-20  8:27         ` Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support) Pekka Paalanen
2020-04-20 10:04           ` Pekka Paalanen
2020-04-20 10:18             ` Simon Ser
2020-04-21 12:15             ` Daniel Vetter
2020-04-21 14:33               ` Pekka Paalanen
2020-04-21 14:39                 ` Simon Ser
2020-04-23 15:01                 ` Daniel Vetter
2020-04-24  8:32                   ` Pekka Paalanen
2020-04-28 14:51                     ` Daniel Vetter
2020-04-29 10:07                       ` Pekka Paalanen
2020-04-30 13:53                         ` Daniel Vetter
2020-05-04  9:49                           ` Pekka Paalanen
2020-05-04 11:00                             ` Daniel Vetter
2020-05-04 12:22                               ` Pekka Paalanen
2020-05-05  8:48                                 ` Daniel Vetter
2020-05-07  9:03                                   ` Pekka Paalanen
2020-04-20 10:15           ` Simon Ser
2020-04-20 12:22             ` Pekka Paalanen
2020-04-20 12:33               ` Simon Ser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200417120506.16db8df9@eldfell.localdomain \
    --to=ppaalanen@gmail.com \
    --cc=airlied@linux.ie \
    --cc=bberg@redhat.com \
    --cc=ckellner@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=javierm@redhat.com \
    --cc=mpearson@lenovo.com \
    --cc=njoshi1@lenovo.com \
    --cc=rajatja@google.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.