From: Simon Ser <contact@emersion.fr>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Benjamin Berg <bberg@redhat.com>, David Airlie <airlied@linux.ie>,
Thomas Zimmermann <tzimmermann@suse.de>,
Christian Kellner <ckellner@redhat.com>,
Javier Martinez Canillas <javierm@redhat.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Hans de Goede <hdegoede@redhat.com>,
Mark Pearson <mpearson@lenovo.com>,
Rajat Jain <rajatja@google.com>,
Nitin Joshi1 <njoshi1@lenovo.com>
Subject: Re: Operating KMS UAPI (Re: RFC: Drm-connector properties managed by another driver / privacy screen support)
Date: Mon, 20 Apr 2020 10:15:39 +0000 [thread overview]
Message-ID: <eT7Xq1DV3kIBOemufORRm39_VF3D9VD08jWCOHvl2IcqmNXqpgtgDGtPcpT_CnQjhIzqth_VdU_A8U1dCFj02JzayLcYCdUlz_5Y-i2tNXk=@emersion.fr> (raw)
In-Reply-To: <20200420112704.68d02472@eldfell.localdomain>
On Monday, April 20, 2020 10:27 AM, Pekka Paalanen <ppaalanen@gmail.com> 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
> that as long as you had fbdev active before the KMS program started,
> the unknown properties have "harmless" default values. And maybe even at
> driver device init if fbdev does not exist?
Note, this is not the case when using e.g. a display manager. In the
past there have been cases of a display manager setting a hw cursor
and launching a compositor not supporting hw cursors. This results in
a stuck hw cursor.
> Btw. I searched for all occurrences of link_status in
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html and it seems it
> only has two possible values, good and bad, and no mention whether it
> is writable. Looks like it's writable. There does not seem to be a) an
> explanation how exactly it needs to the handled (writing it does
> something? what can you write?) or b) any way discern between kernel
> and userspace set values like HDCP "Content Protection" has.
User-space needs to reset the value to GOOD when recovering from a BAD
value.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-20 10:15 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
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 [this message]
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='eT7Xq1DV3kIBOemufORRm39_VF3D9VD08jWCOHvl2IcqmNXqpgtgDGtPcpT_CnQjhIzqth_VdU_A8U1dCFj02JzayLcYCdUlz_5Y-i2tNXk=@emersion.fr' \
--to=contact@emersion.fr \
--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=ppaalanen@gmail.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.