[v7,09/11] drm: uevent for connector status change

Submitted by Ramalingam C on May 7, 2019, 4:27 p.m.

Details

Message ID 20190507162745.25600-10-ramalingam.c@intel.com
State New
Headers show
Series "HDCP2.2 Phase II" ( rev: 9 ) in Intel GFX

Not browsing as part of any series.

Commit Message

Ramalingam C May 7, 2019, 4:27 p.m.
DRM API for generating uevent for a status changes of connector's
property.

This uevent will have following details related to the status change:

  HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>

Need ACK from this uevent from userspace consumer.

v2:
  Minor fixes at KDoc comments [Daniel]
v3:
  Check the property is really attached with connector [Daniel]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
 include/drm/drm_sysfs.h     |  5 ++++-
 2 files changed, 39 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..63fa951a20db 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -21,6 +21,7 @@ 
 #include <drm/drm_sysfs.h>
 #include <drm/drmP.h>
 #include "drm_internal.h"
+#include "drm_crtc_internal.h"
 
 #define to_drm_minor(d) dev_get_drvdata(d)
 #define to_drm_connector(d) dev_get_drvdata(d)
@@ -320,6 +321,9 @@  void drm_sysfs_lease_event(struct drm_device *dev)
  * Send a uevent for the DRM device specified by @dev.  Currently we only
  * set HOTPLUG=1 in the uevent environment, but this could be expanded to
  * deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
  */
 void drm_sysfs_hotplug_event(struct drm_device *dev)
 {
@@ -332,6 +336,37 @@  void drm_sysfs_hotplug_event(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_sysfs_hotplug_event);
 
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev.  Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+				      struct drm_property *property)
+{
+	struct drm_device *dev = connector->dev;
+	char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+	char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+	WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
+					   property->base.id));
+
+	snprintf(conn_id, ARRAY_SIZE(conn_id),
+		 "CONNECTOR=%u", connector->base.id);
+	snprintf(prop_id, ARRAY_SIZE(prop_id),
+		 "PROPERTY=%u", property->base.id);
+
+	DRM_DEBUG("generating connector status event\n");
+
+	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
 static void drm_sysfs_release(struct device *dev)
 {
 	kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@ 
 
 struct drm_device;
 struct device;
+struct drm_connector;
+struct drm_property;
 
 int drm_class_device_register(struct device *dev);
 void drm_class_device_unregister(struct device *dev);
 
 void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+				      struct drm_property *property);
 #endif

Comments

Hi,

On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> DRM API for generating uevent for a status changes of connector's
> property.
> 
> This uevent will have following details related to the status change:
> 
>   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> 
> Need ACK from this uevent from userspace consumer.

So we just had some discussions over on IRC and at about the hotplug
issue and came up with similar ideas:
https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html

The conclusions of these discussions so far would be to have a more or
less fine grain of uevent reporting depending on what happened. The
point is that we need to cover different cases:
- one or more properties changed;
- the connector status changed;
- something else about the connector changed (e.g. EDID/modes)

For the first case, we can send out:
HOTPLUG=1
CONNECTOR=<id>
PROPERTY=<id>

and no reprobe is required.

For the second one, something like:
HOTPLUG=1
CONNECTOR=<id>
STATUS=Connected/Disconnected

and a connector probe is needed for connected, but not for
disconnected;

For the third one, we can only indicate the connector:
HOTPLUG=1
CONNECTOR=<id>

and a reprobe of the connector is always needed

Then we still have the legacy case:
HOTPLUG=1

where userspace is expected to reprobe all the connectors.

I think this would deserve to be a separate series on its own. So I am
proposing to take this one off your plate and come up with another
seres implementing this proposal. What do you think?

Cheers,

Paul

> v2:
>   Minor fixes at KDoc comments [Daniel]
> v3:
>   Check the property is really attached with connector [Daniel]
> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
>  include/drm/drm_sysfs.h     |  5 ++++-
>  2 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 18b1ac442997..63fa951a20db 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -21,6 +21,7 @@
>  #include <drm/drm_sysfs.h>
>  #include <drm/drmP.h>
>  #include "drm_internal.h"
> +#include "drm_crtc_internal.h"
>  
>  #define to_drm_minor(d) dev_get_drvdata(d)
>  #define to_drm_connector(d) dev_get_drvdata(d)
> @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
>   * Send a uevent for the DRM device specified by @dev.  Currently we only
>   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
>   * deal with other types of events.
> + *
> + * Any new uapi should be using the drm_sysfs_connector_status_event()
> + * for uevents on connector status change.
>   */
>  void drm_sysfs_hotplug_event(struct drm_device *dev)
>  {
> @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
>  
> +/**
> + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> + * property status change
> + * @connector: connector on which property status changed
> + * @property: connector property whoes status changed.
> + *
> + * Send a uevent for the DRM device specified by @dev.  Currently we
> + * set HOTPLUG=1 and connector id along with the attached property id
> + * related to the status change.
> + */
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +				      struct drm_property *property)
> +{
> +	struct drm_device *dev = connector->dev;
> +	char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> +	char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> +
> +	WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> +					   property->base.id));
> +
> +	snprintf(conn_id, ARRAY_SIZE(conn_id),
> +		 "CONNECTOR=%u", connector->base.id);
> +	snprintf(prop_id, ARRAY_SIZE(prop_id),
> +		 "PROPERTY=%u", property->base.id);
> +
> +	DRM_DEBUG("generating connector status event\n");
> +
> +	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> +}
> +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> +
>  static void drm_sysfs_release(struct device *dev)
>  {
>  	kfree(dev);
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 4f311e836cdc..d454ef617b2c 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -4,10 +4,13 @@
>  
>  struct drm_device;
>  struct device;
> +struct drm_connector;
> +struct drm_property;
>  
>  int drm_class_device_register(struct device *dev);
>  void drm_class_device_unregister(struct device *dev);
>  
>  void drm_sysfs_hotplug_event(struct drm_device *dev);
> -
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +				      struct drm_property *property);
>  #endif
On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > DRM API for generating uevent for a status changes of connector's
> > property.
> >
> > This uevent will have following details related to the status change:
> >
> >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> >
> > Need ACK from this uevent from userspace consumer.
>
> So we just had some discussions over on IRC and at about the hotplug
> issue and came up with similar ideas:
> https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
>
> The conclusions of these discussions so far would be to have a more or
> less fine grain of uevent reporting depending on what happened. The
> point is that we need to cover different cases:
> - one or more properties changed;
> - the connector status changed;
> - something else about the connector changed (e.g. EDID/modes)
>
> For the first case, we can send out:
> HOTPLUG=1
> CONNECTOR=<id>
> PROPERTY=<id>
>
> and no reprobe is required.
>
> For the second one, something like:
> HOTPLUG=1
> CONNECTOR=<id>
> STATUS=Connected/Disconnected
>
> and a connector probe is needed for connected, but not for
> disconnected;
>
> For the third one, we can only indicate the connector:
> HOTPLUG=1
> CONNECTOR=<id>
>
> and a reprobe of the connector is always needed

There's no material difference between this one and the previous one.
Plus there's no beenfit in supplying the actual value of the property,
i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
Here's why:
- A side effect of forcing a probe on a connector is that you get to
read all the properties, so supplying them is kinda pointless.
- You can read STATUS without forcing a reprobe, if you want to avoid
the reprobe for disconnected. I'd kinda not recommend that though,
feels a bit like overoptimizing. And for reasonable connectors (i.e.
dp) reprobing a disconnected output is fast. HDMI is ... less
reasonable unfortunately, but oh well.
- There's no way to only reprobe status, you can only ever reprobe
everything with the current ioctl and implementations. Having an
option to reprobe only parts of it doesn't seem useful to me (we need
to read the EDID anyway, and that's the expensive part of reprobing in
almost all cases).

In a way PROPERTY=<status-prop-id> simply tells userspace that it
needs to reprobe this connector.

At that point we need to figure out whether this is a good uapi or
not, and that's where the epoch comes in. There's two reasons for an
epoch:
- We need it internally because I'm not goinig to wire a new return
value through hundreds of connector probe functions. It's much easier
to have an epoch counter which we set from e.g. drm_set_edid and
similar functions that update probe state.
- If userspace misses an event and there's no epoch, we're forcing
userspace to reprobe everything. Use case would be if a compositor is
switched away we probably don't want to piss of the current compositor
by blocking it's own probe kernel calls by doing our own (probe is
single-threaded in the kernel through the dev->mode_config.mutex). If
it can read the epoch property (which it can do without forcing a
reprobe) userspace would know which connectors it needs to check and
reprobe.

Hence why epoch, it's a bit more robust userspace api. Ofc you could
also require that userspace needs to keep parsing all uevents and make
a list of all connectors it needs to reprobe when it's back to being
the active compositor. But just comparing a current epoch with the one
you cached from the last full probe is much easier.

Another thing: None of this we can for connectors with unreliable hdp.
Or at least you'll piss of users if you cache always. The sad thing is
that HDMI is unreliable, at least on some machines/screen combos (you
never get a hpd irq if you plug in/unplug). So real compositors still
need to reprobe when the user asks for it. igt can probably get away
without reprobing.
-Daniel

> Then we still have the legacy case:
> HOTPLUG=1
>
> where userspace is expected to reprobe all the connectors.
>
> I think this would deserve to be a separate series on its own. So I am
> proposing to take this one off your plate and come up with another
> seres implementing this proposal. What do you think?
>
> Cheers,
>
> Paul
>
> > v2:
> >   Minor fixes at KDoc comments [Daniel]
> > v3:
> >   Check the property is really attached with connector [Daniel]
> >
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> >  include/drm/drm_sysfs.h     |  5 ++++-
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 18b1ac442997..63fa951a20db 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -21,6 +21,7 @@
> >  #include <drm/drm_sysfs.h>
> >  #include <drm/drmP.h>
> >  #include "drm_internal.h"
> > +#include "drm_crtc_internal.h"
> >
> >  #define to_drm_minor(d) dev_get_drvdata(d)
> >  #define to_drm_connector(d) dev_get_drvdata(d)
> > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> >   * deal with other types of events.
> > + *
> > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > + * for uevents on connector status change.
> >   */
> >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  {
> > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> >
> > +/**
> > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > + * property status change
> > + * @connector: connector on which property status changed
> > + * @property: connector property whoes status changed.
> > + *
> > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > + * set HOTPLUG=1 and connector id along with the attached property id
> > + * related to the status change.
> > + */
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > +                                   struct drm_property *property)
> > +{
> > +     struct drm_device *dev = connector->dev;
> > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > +
> > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > +                                        property->base.id));
> > +
> > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > +              "CONNECTOR=%u", connector->base.id);
> > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > +              "PROPERTY=%u", property->base.id);
> > +
> > +     DRM_DEBUG("generating connector status event\n");
> > +
> > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > +}
> > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > +
> >  static void drm_sysfs_release(struct device *dev)
> >  {
> >       kfree(dev);
> > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > index 4f311e836cdc..d454ef617b2c 100644
> > --- a/include/drm/drm_sysfs.h
> > +++ b/include/drm/drm_sysfs.h
> > @@ -4,10 +4,13 @@
> >
> >  struct drm_device;
> >  struct device;
> > +struct drm_connector;
> > +struct drm_property;
> >
> >  int drm_class_device_register(struct device *dev);
> >  void drm_class_device_unregister(struct device *dev);
> >
> >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > -
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > +                                   struct drm_property *property);
> >  #endif
> --
> Paul Kocialkowski, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
>
Hi,

On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > DRM API for generating uevent for a status changes of connector's
> > > property.
> > > 
> > > This uevent will have following details related to the status change:
> > > 
> > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > 
> > > Need ACK from this uevent from userspace consumer.
> > 
> > So we just had some discussions over on IRC and at about the hotplug
> > issue and came up with similar ideas:
> > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > 
> > The conclusions of these discussions so far would be to have a more or
> > less fine grain of uevent reporting depending on what happened. The
> > point is that we need to cover different cases:
> > - one or more properties changed;
> > - the connector status changed;
> > - something else about the connector changed (e.g. EDID/modes)
> > 
> > For the first case, we can send out:
> > HOTPLUG=1
> > CONNECTOR=<id>
> > PROPERTY=<id>
> > 
> > and no reprobe is required.
> > 
> > For the second one, something like:
> > HOTPLUG=1
> > CONNECTOR=<id>
> > STATUS=Connected/Disconnected
> > 
> > and a connector probe is needed for connected, but not for
> > disconnected;
> > 
> > For the third one, we can only indicate the connector:
> > HOTPLUG=1
> > CONNECTOR=<id>
> > 
> > and a reprobe of the connector is always needed
> 
> There's no material difference between this one and the previous one.
> Plus there's no beenfit in supplying the actual value of the property,
> i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.

That's the idea, but we need to handle status changes differently than
properties, since as far as I know, connected/unconnected status is not
exposed as a prop for the connector.

> Here's why:
> - A side effect of forcing a probe on a connector is that you get to
> read all the properties, so supplying them is kinda pointless.

Agreed, except for the status case where it's useful to know it's a
disconnect, because we don't need any probe step in that case.

> - You can read STATUS without forcing a reprobe, if you want to avoid
> the reprobe for disconnected. I'd kinda not recommend that though,
> feels a bit like overoptimizing. And for reasonable connectors (i.e.
> dp) reprobing a disconnected output is fast. HDMI is ... less
> reasonable unfortunately, but oh well.

How would that be retreived then? From the looks of it, that's a
MODE_GETCONNECTOR ioctl and I was under the impression this is what
does the full reprobe.

Not sure what issues could arise in case of disconnect without reprobe
-- at least I don't see why userspace should have to do anything in
particular except no longer using the connector, even in complex DP MST
cases.

> - There's no way to only reprobe status, you can only ever reprobe
> everything with the current ioctl and implementations. Having an
> option to reprobe only parts of it doesn't seem useful to me (we need
> to read the EDID anyway, and that's the expensive part of reprobing in
> almost all cases).

Agreed.

> In a way PROPERTY=<status-prop-id> simply tells userspace that it
> needs to reprobe this connector.

I thought we could access the props alone, which avoids doing a reprobe
when the kernel knows that only a prop or a set of props changed and do
not require a full reprobe. That's the first case I was mentionning.

> At that point we need to figure out whether this is a good uapi or
> not, and that's where the epoch comes in. There's two reasons for an
> epoch:
> - We need it internally because I'm not goinig to wire a new return
> value through hundreds of connector probe functions. It's much easier
> to have an epoch counter which we set from e.g. drm_set_edid and
> similar functions that update probe state.

I don't think I'm following what issue this is trying to solve
internally.

> - If userspace misses an event and there's no epoch, we're forcing
> userspace to reprobe everything. Use case would be if a compositor is
> switched away we probably don't want to piss of the current compositor
> by blocking it's own probe kernel calls by doing our own (probe is
> single-threaded in the kernel through the dev->mode_config.mutex). If
> it can read the epoch property (which it can do without forcing a
> reprobe) userspace would know which connectors it needs to check and
> reprobe.
>
> Hence why epoch, it's a bit more robust userspace api. Ofc you could
> also require that userspace needs to keep parsing all uevents and make
> a list of all connectors it needs to reprobe when it's back to being
> the active compositor. But just comparing a current epoch with the one
> you cached from the last full probe is much easier.

Fair enough, I think it's a fine idea for robustness yes, but I think
we could also provide extra info in the uevent when relevant and not
rely on that entirely.

> Another thing: None of this we can for connectors with unreliable hdp.
> Or at least you'll piss of users if you cache always. The sad thing is
> that HDMI is unreliable, at least on some machines/screen combos (you
> never get a hpd irq if you plug in/unplug). So real compositors still
> need to reprobe when the user asks for it. igt can probably get away
> without reprobing.

I wonder how that is handled currently and how a user action can solve
the issue without any notification from the kernel. Maybe a need a
better understanding of that case to have a clearer idea.

Cheers,

Paul

> -Daniel
> 
> > Then we still have the legacy case:
> > HOTPLUG=1
> > 
> > where userspace is expected to reprobe all the connectors.
> > 
> > I think this would deserve to be a separate series on its own. So I am
> > proposing to take this one off your plate and come up with another
> > seres implementing this proposal. What do you think?
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > v2:
> > >   Minor fixes at KDoc comments [Daniel]
> > > v3:
> > >   Check the property is really attached with connector [Daniel]
> > > 
> > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > ---
> > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > >  include/drm/drm_sysfs.h     |  5 ++++-
> > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > index 18b1ac442997..63fa951a20db 100644
> > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > @@ -21,6 +21,7 @@
> > >  #include <drm/drm_sysfs.h>
> > >  #include <drm/drmP.h>
> > >  #include "drm_internal.h"
> > > +#include "drm_crtc_internal.h"
> > > 
> > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > >   * deal with other types of events.
> > > + *
> > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > + * for uevents on connector status change.
> > >   */
> > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > >  {
> > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > >  }
> > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > 
> > > +/**
> > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > + * property status change
> > > + * @connector: connector on which property status changed
> > > + * @property: connector property whoes status changed.
> > > + *
> > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > + * related to the status change.
> > > + */
> > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > +                                   struct drm_property *property)
> > > +{
> > > +     struct drm_device *dev = connector->dev;
> > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > +
> > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > +                                        property->base.id));
> > > +
> > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > +              "CONNECTOR=%u", connector->base.id);
> > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > +              "PROPERTY=%u", property->base.id);
> > > +
> > > +     DRM_DEBUG("generating connector status event\n");
> > > +
> > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > +}
> > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > +
> > >  static void drm_sysfs_release(struct device *dev)
> > >  {
> > >       kfree(dev);
> > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > index 4f311e836cdc..d454ef617b2c 100644
> > > --- a/include/drm/drm_sysfs.h
> > > +++ b/include/drm/drm_sysfs.h
> > > @@ -4,10 +4,13 @@
> > > 
> > >  struct drm_device;
> > >  struct device;
> > > +struct drm_connector;
> > > +struct drm_property;
> > > 
> > >  int drm_class_device_register(struct device *dev);
> > >  void drm_class_device_unregister(struct device *dev);
> > > 
> > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > -
> > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > +                                   struct drm_property *property);
> > >  #endif
> > --
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
> 
>
On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > DRM API for generating uevent for a status changes of connector's
> > > > property.
> > > >
> > > > This uevent will have following details related to the status change:
> > > >
> > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > >
> > > > Need ACK from this uevent from userspace consumer.
> > >
> > > So we just had some discussions over on IRC and at about the hotplug
> > > issue and came up with similar ideas:
> > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > >
> > > The conclusions of these discussions so far would be to have a more or
> > > less fine grain of uevent reporting depending on what happened. The
> > > point is that we need to cover different cases:
> > > - one or more properties changed;
> > > - the connector status changed;
> > > - something else about the connector changed (e.g. EDID/modes)
> > >
> > > For the first case, we can send out:
> > > HOTPLUG=1
> > > CONNECTOR=<id>
> > > PROPERTY=<id>
> > >
> > > and no reprobe is required.
> > >
> > > For the second one, something like:
> > > HOTPLUG=1
> > > CONNECTOR=<id>
> > > STATUS=Connected/Disconnected
> > >
> > > and a connector probe is needed for connected, but not for
> > > disconnected;
> > >
> > > For the third one, we can only indicate the connector:
> > > HOTPLUG=1
> > > CONNECTOR=<id>
> > >
> > > and a reprobe of the connector is always needed
> >
> > There's no material difference between this one and the previous one.
> > Plus there's no beenfit in supplying the actual value of the property,
> > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
>
> That's the idea, but we need to handle status changes differently than
> properties, since as far as I know, connected/unconnected status is not
> exposed as a prop for the connector.

Oops, totally missed that. "Everything is a property" is kinda
new-ish, at least compared to kms. Kinda tempted to just make status
into a property. Or another excuse why we should expose the epoch
property :-)

> > Here's why:
> > - A side effect of forcing a probe on a connector is that you get to
> > read all the properties, so supplying them is kinda pointless.
>
> Agreed, except for the status case where it's useful to know it's a
> disconnect, because we don't need any probe step in that case.
>
> > - You can read STATUS without forcing a reprobe, if you want to avoid
> > the reprobe for disconnected. I'd kinda not recommend that though,
> > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > dp) reprobing a disconnected output is fast. HDMI is ... less
> > reasonable unfortunately, but oh well.
>
> How would that be retreived then? From the looks of it, that's a
> MODE_GETCONNECTOR ioctl and I was under the impression this is what
> does the full reprobe.

drmGetConnector vs drmGetConnectorCurrent.

> Not sure what issues could arise in case of disconnect without reprobe
> -- at least I don't see why userspace should have to do anything in
> particular except no longer using the connector, even in complex DP MST
> cases.

connector->status might be a lie without a full reprobe, and wrongly
indicate that the connector is disconnected while there's still
something plugged in. I'm not sure we've fixed those bugs by now
(usually it's around "hpd indicates disconnected" vs. "i2c indicates
connected, and we can't break this because every intel platform ever
shipped has a few devices where this is somehow broken, irrespective
of the sink).

> > - There's no way to only reprobe status, you can only ever reprobe
> > everything with the current ioctl and implementations. Having an
> > option to reprobe only parts of it doesn't seem useful to me (we need
> > to read the EDID anyway, and that's the expensive part of reprobing in
> > almost all cases).
>
> Agreed.
>
> > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > needs to reprobe this connector.
>
> I thought we could access the props alone, which avoids doing a reprobe
> when the kernel knows that only a prop or a set of props changed and do
> not require a full reprobe. That's the first case I was mentionning.
>
> > At that point we need to figure out whether this is a good uapi or
> > not, and that's where the epoch comes in. There's two reasons for an
> > epoch:
> > - We need it internally because I'm not goinig to wire a new return
> > value through hundreds of connector probe functions. It's much easier
> > to have an epoch counter which we set from e.g. drm_set_edid and
> > similar functions that update probe state.
>
> I don't think I'm following what issue this is trying to solve
> internally.

So I'm assuming that if we handle a hotplug, we only want to generate
one uevent for that, not one for every little thing that changed.
There's two ways to implement this logic:
- With some epoch counter and a helper function you can call everytime
something changed (e.g. status, or edid, or anything else we care
about e.g. from dp aux). This won't need much (if any) driver changes,
because we can just put these into the relevant helper/core functions
(like edid update, or dp aux reading or whatever).
- Wiring a new return value through the entire stack (and _all_ the
kms drivers) so that the probe helpers could aggregate this like they
currently do.

One of these is a lot less typing.

> > - If userspace misses an event and there's no epoch, we're forcing
> > userspace to reprobe everything. Use case would be if a compositor is
> > switched away we probably don't want to piss of the current compositor
> > by blocking it's own probe kernel calls by doing our own (probe is
> > single-threaded in the kernel through the dev->mode_config.mutex). If
> > it can read the epoch property (which it can do without forcing a
> > reprobe) userspace would know which connectors it needs to check and
> > reprobe.
> >
> > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > also require that userspace needs to keep parsing all uevents and make
> > a list of all connectors it needs to reprobe when it's back to being
> > the active compositor. But just comparing a current epoch with the one
> > you cached from the last full probe is much easier.
>
> Fair enough, I think it's a fine idea for robustness yes, but I think
> we could also provide extra info in the uevent when relevant and not
> rely on that entirely.

See above, with drmGetConnectorCurrent there's no need to provide more
than what's needed in the uevent, since userspace can get everything
else at the cost of one ioctl, without reprobing. With a bit of
engineering work we could even avoid taking the expensive
dev->mode_config.mutex lock for this fastpath.

> > Another thing: None of this we can for connectors with unreliable hdp.
> > Or at least you'll piss of users if you cache always. The sad thing is
> > that HDMI is unreliable, at least on some machines/screen combos (you
> > never get a hpd irq if you plug in/unplug). So real compositors still
> > need to reprobe when the user asks for it. igt can probably get away
> > without reprobing.
>
> I wonder how that is handled currently and how a user action can solve
> the issue without any notification from the kernel. Maybe a need a
> better understanding of that case to have a clearer idea.

User opens the screen configuration tool -> usually at that point the
tool/compositor force a full reprobe, which then often triggers the
automatic reconfiguring. E.g. on one laptop I have here when I plug in
random shit projectors at conferences nothing happens, until I run
xrandr, which triggers the full reprobe, which then makes the kernel
realize something change, sending and uevent, which starts the
automatic reconfigure machinery.

There's also the issue that there's machines with hpd storms (even on
DP, where you really need hpd to work to be compliant), and we have to
turn of the hpd irq to keep the machine useable.

Cheers, Daniel

>
> Cheers,
>
> Paul
>
> > -Daniel
> >
> > > Then we still have the legacy case:
> > > HOTPLUG=1
> > >
> > > where userspace is expected to reprobe all the connectors.
> > >
> > > I think this would deserve to be a separate series on its own. So I am
> > > proposing to take this one off your plate and come up with another
> > > seres implementing this proposal. What do you think?
> > >
> > > Cheers,
> > >
> > > Paul
> > >
> > > > v2:
> > > >   Minor fixes at KDoc comments [Daniel]
> > > > v3:
> > > >   Check the property is really attached with connector [Daniel]
> > > >
> > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > ---
> > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > index 18b1ac442997..63fa951a20db 100644
> > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > @@ -21,6 +21,7 @@
> > > >  #include <drm/drm_sysfs.h>
> > > >  #include <drm/drmP.h>
> > > >  #include "drm_internal.h"
> > > > +#include "drm_crtc_internal.h"
> > > >
> > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > >   * deal with other types of events.
> > > > + *
> > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > + * for uevents on connector status change.
> > > >   */
> > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > >  {
> > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > >  }
> > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > >
> > > > +/**
> > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > + * property status change
> > > > + * @connector: connector on which property status changed
> > > > + * @property: connector property whoes status changed.
> > > > + *
> > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > + * related to the status change.
> > > > + */
> > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > +                                   struct drm_property *property)
> > > > +{
> > > > +     struct drm_device *dev = connector->dev;
> > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > +
> > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > +                                        property->base.id));
> > > > +
> > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > +              "CONNECTOR=%u", connector->base.id);
> > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > +              "PROPERTY=%u", property->base.id);
> > > > +
> > > > +     DRM_DEBUG("generating connector status event\n");
> > > > +
> > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > +}
> > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > +
> > > >  static void drm_sysfs_release(struct device *dev)
> > > >  {
> > > >       kfree(dev);
> > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > --- a/include/drm/drm_sysfs.h
> > > > +++ b/include/drm/drm_sysfs.h
> > > > @@ -4,10 +4,13 @@
> > > >
> > > >  struct drm_device;
> > > >  struct device;
> > > > +struct drm_connector;
> > > > +struct drm_property;
> > > >
> > > >  int drm_class_device_register(struct device *dev);
> > > >  void drm_class_device_unregister(struct device *dev);
> > > >
> > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > -
> > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > +                                   struct drm_property *property);
> > > >  #endif
> > > --
> > > Paul Kocialkowski, Bootlin
> > > Embedded Linux and kernel engineering
> > > https://bootlin.com
> > >
> >
> >
> --
> Paul Kocialkowski, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
>
On Mon, 2019-05-13 at 11:34 +0200, Daniel Vetter wrote:
> On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski

> <paul.kocialkowski@bootlin.com> wrote:

> > Hi,

> > 

> > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:

> > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski

> > > <paul.kocialkowski@bootlin.com> wrote:

> > > > Hi,

> > > > 

> > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:

> > > > > DRM API for generating uevent for a status changes of connector's

> > > > > property.

> > > > > 

> > > > > This uevent will have following details related to the status change:

> > > > > 

> > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>

> > > > > 

> > > > > Need ACK from this uevent from userspace consumer.

> > > > 

> > > > So we just had some discussions over on IRC and at about the hotplug

> > > > issue and came up with similar ideas:

> > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html

> > > > 

> > > > The conclusions of these discussions so far would be to have a more or

> > > > less fine grain of uevent reporting depending on what happened. The

> > > > point is that we need to cover different cases:

> > > > - one or more properties changed;

> > > > - the connector status changed;

> > > > - something else about the connector changed (e.g. EDID/modes)

> > > > 

> > > > For the first case, we can send out:

> > > > HOTPLUG=1

> > > > CONNECTOR=<id>

> > > > PROPERTY=<id>

> > > > 

> > > > and no reprobe is required.

> > > > 

> > > > For the second one, something like:

> > > > HOTPLUG=1

> > > > CONNECTOR=<id>

> > > > STATUS=Connected/Disconnected

> > > > 

> > > > and a connector probe is needed for connected, but not for

> > > > disconnected;

> > > > 

> > > > For the third one, we can only indicate the connector:

> > > > HOTPLUG=1

> > > > CONNECTOR=<id>

> > > > 

> > > > and a reprobe of the connector is always needed

> > > 

> > > There's no material difference between this one and the previous one.

> > > Plus there's no beenfit in supplying the actual value of the property,

> > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.

> > 

> > That's the idea, but we need to handle status changes differently than

> > properties, since as far as I know, connected/unconnected status is not

> > exposed as a prop for the connector.

> 

> Oops, totally missed that. "Everything is a property" is kinda

> new-ish, at least compared to kms. Kinda tempted to just make status

> into a property. Or another excuse why we should expose the epoch

> property :-)

> 

> > > Here's why:

> > > - A side effect of forcing a probe on a connector is that you get to

> > > read all the properties, so supplying them is kinda pointless.

> > 

> > Agreed, except for the status case where it's useful to know it's a

> > disconnect, because we don't need any probe step in that case.

> > 

> > > - You can read STATUS without forcing a reprobe, if you want to avoid

> > > the reprobe for disconnected. I'd kinda not recommend that though,

> > > feels a bit like overoptimizing. And for reasonable connectors (i.e.

> > > dp) reprobing a disconnected output is fast. HDMI is ... less

> > > reasonable unfortunately, but oh well.

> > 

> > How would that be retreived then? From the looks of it, that's a

> > MODE_GETCONNECTOR ioctl and I was under the impression this is what

> > does the full reprobe.

> 

> drmGetConnector vs drmGetConnectorCurrent.

> 

> > Not sure what issues could arise in case of disconnect without reprobe

> > -- at least I don't see why userspace should have to do anything in

> > particular except no longer using the connector, even in complex DP MST

> > cases.

> 

> connector->status might be a lie without a full reprobe, and wrongly

> indicate that the connector is disconnected while there's still

> something plugged in. I'm not sure we've fixed those bugs by now

> (usually it's around "hpd indicates disconnected" vs. "i2c indicates

> connected, and we can't break this because every intel platform ever

> shipped has a few devices where this is somehow broken, irrespective

> of the sink).

> 

> > > - There's no way to only reprobe status, you can only ever reprobe

> > > everything with the current ioctl and implementations. Having an

> > > option to reprobe only parts of it doesn't seem useful to me (we need

> > > to read the EDID anyway, and that's the expensive part of reprobing in

> > > almost all cases).

> > 

> > Agreed.

> > 

> > > In a way PROPERTY=<status-prop-id> simply tells userspace that it

> > > needs to reprobe this connector.

> > 

> > I thought we could access the props alone, which avoids doing a reprobe

> > when the kernel knows that only a prop or a set of props changed and do

> > not require a full reprobe. That's the first case I was mentionning.

> > 

> > > At that point we need to figure out whether this is a good uapi or

> > > not, and that's where the epoch comes in. There's two reasons for an

> > > epoch:

> > > - We need it internally because I'm not goinig to wire a new return

> > > value through hundreds of connector probe functions. It's much easier

> > > to have an epoch counter which we set from e.g. drm_set_edid and

> > > similar functions that update probe state.

> > 

> > I don't think I'm following what issue this is trying to solve

> > internally.

> 

> So I'm assuming that if we handle a hotplug, we only want to generate

> one uevent for that, not one for every little thing that changed.

> There's two ways to implement this logic:

> - With some epoch counter and a helper function you can call everytime

> something changed (e.g. status, or edid, or anything else we care

> about e.g. from dp aux). This won't need much (if any) driver changes,

> because we can just put these into the relevant helper/core functions

> (like edid update, or dp aux reading or whatever).

> - Wiring a new return value through the entire stack (and _all_ the

> kms drivers) so that the probe helpers could aggregate this like they

> currently do.

> 

> One of these is a lot less typing.

> 

> > > - If userspace misses an event and there's no epoch, we're forcing

> > > userspace to reprobe everything. Use case would be if a compositor is

> > > switched away we probably don't want to piss of the current compositor

> > > by blocking it's own probe kernel calls by doing our own (probe is

> > > single-threaded in the kernel through the dev->mode_config.mutex). If

> > > it can read the epoch property (which it can do without forcing a

> > > reprobe) userspace would know which connectors it needs to check and

> > > reprobe.

> > > 

> > > Hence why epoch, it's a bit more robust userspace api. Ofc you could

> > > also require that userspace needs to keep parsing all uevents and make

> > > a list of all connectors it needs to reprobe when it's back to being

> > > the active compositor. But just comparing a current epoch with the one

> > > you cached from the last full probe is much easier.

> > 

> > Fair enough, I think it's a fine idea for robustness yes, but I think

> > we could also provide extra info in the uevent when relevant and not

> > rely on that entirely.

> 

> See above, with drmGetConnectorCurrent there's no need to provide more

> than what's needed in the uevent, since userspace can get everything

> else at the cost of one ioctl, without reprobing. With a bit of

> engineering work we could even avoid taking the expensive

> dev->mode_config.mutex lock for this fastpath.

> 

> > > Another thing: None of this we can for connectors with unreliable hdp.

> > > Or at least you'll piss of users if you cache always. The sad thing is

> > > that HDMI is unreliable, at least on some machines/screen combos (you

> > > never get a hpd irq if you plug in/unplug). So real compositors still

> > > need to reprobe when the user asks for it. igt can probably get away

> > > without reprobing.

> > 

> > I wonder how that is handled currently and how a user action can solve

> > the issue without any notification from the kernel. Maybe a need a

> > better understanding of that case to have a clearer idea.

> 

> User opens the screen configuration tool -> usually at that point the

> tool/compositor force a full reprobe, which then often triggers the

> automatic reconfiguring. E.g. on one laptop I have here when I plug in

> random shit projectors at conferences nothing happens, until I run

> xrandr, which triggers the full reprobe, which then makes the kernel

> realize something change, sending and uevent, which starts the

> automatic reconfigure machinery.

> 

> There's also the issue that there's machines with hpd storms (even on

> DP, where you really need hpd to work to be compliant), and we have to

> turn of the hpd irq to keep the machine useable.


Note that xrandr only works on X11. On Wayland, it won't.

Whether the user can actually do anything depends on the compositor. On
GNOME the D-Bus interface could probably force a re-probe when a
configuration tool is started or maybe with a "Rescan connectors"
button (not sure they'd like to have this in their UI). On KDE, Weston
and wlroots there is no way to do it.

As compositor writers, do we really need to provide a way for users to
force a reprobe? Can't the kernel do anything to handle these bad
screens?

> Cheers, Daniel

> 

> > Cheers,

> > 

> > Paul

> > 

> > > -Daniel

> > > 

> > > > Then we still have the legacy case:

> > > > HOTPLUG=1

> > > > 

> > > > where userspace is expected to reprobe all the connectors.

> > > > 

> > > > I think this would deserve to be a separate series on its own. So I am

> > > > proposing to take this one off your plate and come up with another

> > > > seres implementing this proposal. What do you think?

> > > > 

> > > > Cheers,

> > > > 

> > > > Paul

> > > > 

> > > > > v2:

> > > > >   Minor fixes at KDoc comments [Daniel]

> > > > > v3:

> > > > >   Check the property is really attached with connector [Daniel]

> > > > > 

> > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>

> > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> > > > > ---

> > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++

> > > > >  include/drm/drm_sysfs.h     |  5 ++++-

> > > > >  2 files changed, 39 insertions(+), 1 deletion(-)

> > > > > 

> > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c

> > > > > index 18b1ac442997..63fa951a20db 100644

> > > > > --- a/drivers/gpu/drm/drm_sysfs.c

> > > > > +++ b/drivers/gpu/drm/drm_sysfs.c

> > > > > @@ -21,6 +21,7 @@

> > > > >  #include <drm/drm_sysfs.h>

> > > > >  #include <drm/drmP.h>

> > > > >  #include "drm_internal.h"

> > > > > +#include "drm_crtc_internal.h"

> > > > > 

> > > > >  #define to_drm_minor(d) dev_get_drvdata(d)

> > > > >  #define to_drm_connector(d) dev_get_drvdata(d)

> > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)

> > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only

> > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to

> > > > >   * deal with other types of events.

> > > > > + *

> > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()

> > > > > + * for uevents on connector status change.

> > > > >   */

> > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)

> > > > >  {

> > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)

> > > > >  }

> > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);

> > > > > 

> > > > > +/**

> > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector

> > > > > + * property status change

> > > > > + * @connector: connector on which property status changed

> > > > > + * @property: connector property whoes status changed.

> > > > > + *

> > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we

> > > > > + * set HOTPLUG=1 and connector id along with the attached property id

> > > > > + * related to the status change.

> > > > > + */

> > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,

> > > > > +                                   struct drm_property *property)

> > > > > +{

> > > > > +     struct drm_device *dev = connector->dev;

> > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];

> > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };

> > > > > +

> > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,

> > > > > +                                        property->base.id));

> > > > > +

> > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),

> > > > > +              "CONNECTOR=%u", connector->base.id);

> > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),

> > > > > +              "PROPERTY=%u", property->base.id);

> > > > > +

> > > > > +     DRM_DEBUG("generating connector status event\n");

> > > > > +

> > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);

> > > > > +}

> > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);

> > > > > +

> > > > >  static void drm_sysfs_release(struct device *dev)

> > > > >  {

> > > > >       kfree(dev);

> > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h

> > > > > index 4f311e836cdc..d454ef617b2c 100644

> > > > > --- a/include/drm/drm_sysfs.h

> > > > > +++ b/include/drm/drm_sysfs.h

> > > > > @@ -4,10 +4,13 @@

> > > > > 

> > > > >  struct drm_device;

> > > > >  struct device;

> > > > > +struct drm_connector;

> > > > > +struct drm_property;

> > > > > 

> > > > >  int drm_class_device_register(struct device *dev);

> > > > >  void drm_class_device_unregister(struct device *dev);

> > > > > 

> > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);

> > > > > -

> > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,

> > > > > +                                   struct drm_property *property);

> > > > >  #endif

> > > > --

> > > > Paul Kocialkowski, Bootlin

> > > > Embedded Linux and kernel engineering

> > > > https://bootlin.com

> > > > 

> > --

> > Paul Kocialkowski, Bootlin

> > Embedded Linux and kernel engineering

> > https://bootlin.com

> > 

> 

>
On Mon, May 13, 2019 at 10:11:01AM +0000, Ser, Simon wrote:
> On Mon, 2019-05-13 at 11:34 +0200, Daniel Vetter wrote:
> > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > > 
> > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > > 
> > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > property.
> > > > > > 
> > > > > > This uevent will have following details related to the status change:
> > > > > > 
> > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > 
> > > > > > Need ACK from this uevent from userspace consumer.
> > > > > 
> > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > issue and came up with similar ideas:
> > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > 
> > > > > The conclusions of these discussions so far would be to have a more or
> > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > point is that we need to cover different cases:
> > > > > - one or more properties changed;
> > > > > - the connector status changed;
> > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > 
> > > > > For the first case, we can send out:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > PROPERTY=<id>
> > > > > 
> > > > > and no reprobe is required.
> > > > > 
> > > > > For the second one, something like:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > STATUS=Connected/Disconnected
> > > > > 
> > > > > and a connector probe is needed for connected, but not for
> > > > > disconnected;
> > > > > 
> > > > > For the third one, we can only indicate the connector:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > 
> > > > > and a reprobe of the connector is always needed
> > > > 
> > > > There's no material difference between this one and the previous one.
> > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > 
> > > That's the idea, but we need to handle status changes differently than
> > > properties, since as far as I know, connected/unconnected status is not
> > > exposed as a prop for the connector.
> > 
> > Oops, totally missed that. "Everything is a property" is kinda
> > new-ish, at least compared to kms. Kinda tempted to just make status
> > into a property. Or another excuse why we should expose the epoch
> > property :-)
> > 
> > > > Here's why:
> > > > - A side effect of forcing a probe on a connector is that you get to
> > > > read all the properties, so supplying them is kinda pointless.
> > > 
> > > Agreed, except for the status case where it's useful to know it's a
> > > disconnect, because we don't need any probe step in that case.
> > > 
> > > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > > reasonable unfortunately, but oh well.
> > > 
> > > How would that be retreived then? From the looks of it, that's a
> > > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > > does the full reprobe.
> > 
> > drmGetConnector vs drmGetConnectorCurrent.
> > 
> > > Not sure what issues could arise in case of disconnect without reprobe
> > > -- at least I don't see why userspace should have to do anything in
> > > particular except no longer using the connector, even in complex DP MST
> > > cases.
> > 
> > connector->status might be a lie without a full reprobe, and wrongly
> > indicate that the connector is disconnected while there's still
> > something plugged in. I'm not sure we've fixed those bugs by now
> > (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> > connected, and we can't break this because every intel platform ever
> > shipped has a few devices where this is somehow broken, irrespective
> > of the sink).
> > 
> > > > - There's no way to only reprobe status, you can only ever reprobe
> > > > everything with the current ioctl and implementations. Having an
> > > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > > almost all cases).
> > > 
> > > Agreed.
> > > 
> > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > > needs to reprobe this connector.
> > > 
> > > I thought we could access the props alone, which avoids doing a reprobe
> > > when the kernel knows that only a prop or a set of props changed and do
> > > not require a full reprobe. That's the first case I was mentionning.
> > > 
> > > > At that point we need to figure out whether this is a good uapi or
> > > > not, and that's where the epoch comes in. There's two reasons for an
> > > > epoch:
> > > > - We need it internally because I'm not goinig to wire a new return
> > > > value through hundreds of connector probe functions. It's much easier
> > > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > > similar functions that update probe state.
> > > 
> > > I don't think I'm following what issue this is trying to solve
> > > internally.
> > 
> > So I'm assuming that if we handle a hotplug, we only want to generate
> > one uevent for that, not one for every little thing that changed.
> > There's two ways to implement this logic:
> > - With some epoch counter and a helper function you can call everytime
> > something changed (e.g. status, or edid, or anything else we care
> > about e.g. from dp aux). This won't need much (if any) driver changes,
> > because we can just put these into the relevant helper/core functions
> > (like edid update, or dp aux reading or whatever).
> > - Wiring a new return value through the entire stack (and _all_ the
> > kms drivers) so that the probe helpers could aggregate this like they
> > currently do.
> > 
> > One of these is a lot less typing.
> > 
> > > > - If userspace misses an event and there's no epoch, we're forcing
> > > > userspace to reprobe everything. Use case would be if a compositor is
> > > > switched away we probably don't want to piss of the current compositor
> > > > by blocking it's own probe kernel calls by doing our own (probe is
> > > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > > it can read the epoch property (which it can do without forcing a
> > > > reprobe) userspace would know which connectors it needs to check and
> > > > reprobe.
> > > > 
> > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > > also require that userspace needs to keep parsing all uevents and make
> > > > a list of all connectors it needs to reprobe when it's back to being
> > > > the active compositor. But just comparing a current epoch with the one
> > > > you cached from the last full probe is much easier.
> > > 
> > > Fair enough, I think it's a fine idea for robustness yes, but I think
> > > we could also provide extra info in the uevent when relevant and not
> > > rely on that entirely.
> > 
> > See above, with drmGetConnectorCurrent there's no need to provide more
> > than what's needed in the uevent, since userspace can get everything
> > else at the cost of one ioctl, without reprobing. With a bit of
> > engineering work we could even avoid taking the expensive
> > dev->mode_config.mutex lock for this fastpath.
> > 
> > > > Another thing: None of this we can for connectors with unreliable hdp.
> > > > Or at least you'll piss of users if you cache always. The sad thing is
> > > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > > need to reprobe when the user asks for it. igt can probably get away
> > > > without reprobing.
> > > 
> > > I wonder how that is handled currently and how a user action can solve
> > > the issue without any notification from the kernel. Maybe a need a
> > > better understanding of that case to have a clearer idea.
> > 
> > User opens the screen configuration tool -> usually at that point the
> > tool/compositor force a full reprobe, which then often triggers the
> > automatic reconfiguring. E.g. on one laptop I have here when I plug in
> > random shit projectors at conferences nothing happens, until I run
> > xrandr, which triggers the full reprobe, which then makes the kernel
> > realize something change, sending and uevent, which starts the
> > automatic reconfigure machinery.
> > 
> > There's also the issue that there's machines with hpd storms (even on
> > DP, where you really need hpd to work to be compliant), and we have to
> > turn of the hpd irq to keep the machine useable.
> 
> Note that xrandr only works on X11. On Wayland, it won't.
> 
> Whether the user can actually do anything depends on the compositor. On
> GNOME the D-Bus interface could probably force a re-probe when a
> configuration tool is started or maybe with a "Rescan connectors"
> button (not sure they'd like to have this in their UI). On KDE, Weston
> and wlroots there is no way to do it.
> 
> As compositor writers, do we really need to provide a way for users to
> force a reprobe? Can't the kernel do anything to handle these bad
> screens?

Yeah, we defensively fall back to polling. Which isn't great from a power
usage pov.

btw as long as compositors use drmGetConnector and not just
drmGetConnectorCurrent you can trigger a full reprobe. If there's not way
to trigger that they'll all have to add a "force probe" button sooner or
later. But usually it's enough if you do a full reprobe when the user
starts your config tool.
-Daniel


> > Cheers, Daniel
> > 
> > > Cheers,
> > > 
> > > Paul
> > > 
> > > > -Daniel
> > > > 
> > > > > Then we still have the legacy case:
> > > > > HOTPLUG=1
> > > > > 
> > > > > where userspace is expected to reprobe all the connectors.
> > > > > 
> > > > > I think this would deserve to be a separate series on its own. So I am
> > > > > proposing to take this one off your plate and come up with another
> > > > > seres implementing this proposal. What do you think?
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Paul
> > > > > 
> > > > > > v2:
> > > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > > v3:
> > > > > >   Check the property is really attached with connector [Daniel]
> > > > > > 
> > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > > @@ -21,6 +21,7 @@
> > > > > >  #include <drm/drm_sysfs.h>
> > > > > >  #include <drm/drmP.h>
> > > > > >  #include "drm_internal.h"
> > > > > > +#include "drm_crtc_internal.h"
> > > > > > 
> > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > > >   * deal with other types of events.
> > > > > > + *
> > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > > + * for uevents on connector status change.
> > > > > >   */
> > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > >  {
> > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > >  }
> > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > > 
> > > > > > +/**
> > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > > + * property status change
> > > > > > + * @connector: connector on which property status changed
> > > > > > + * @property: connector property whoes status changed.
> > > > > > + *
> > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > > + * related to the status change.
> > > > > > + */
> > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > +                                   struct drm_property *property)
> > > > > > +{
> > > > > > +     struct drm_device *dev = connector->dev;
> > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > > +
> > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > > +                                        property->base.id));
> > > > > > +
> > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > > +              "PROPERTY=%u", property->base.id);
> > > > > > +
> > > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > > +
> > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > > +}
> > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > > +
> > > > > >  static void drm_sysfs_release(struct device *dev)
> > > > > >  {
> > > > > >       kfree(dev);
> > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > > --- a/include/drm/drm_sysfs.h
> > > > > > +++ b/include/drm/drm_sysfs.h
> > > > > > @@ -4,10 +4,13 @@
> > > > > > 
> > > > > >  struct drm_device;
> > > > > >  struct device;
> > > > > > +struct drm_connector;
> > > > > > +struct drm_property;
> > > > > > 
> > > > > >  int drm_class_device_register(struct device *dev);
> > > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > > 
> > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > > -
> > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > +                                   struct drm_property *property);
> > > > > >  #endif
> > > > > --
> > > > > Paul Kocialkowski, Bootlin
> > > > > Embedded Linux and kernel engineering
> > > > > https://bootlin.com
> > > > > 
> > > --
> > > Paul Kocialkowski, Bootlin
> > > Embedded Linux and kernel engineering
> > > https://bootlin.com
> > > 
> > 
> >
Hey,

Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit :
> On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > DRM API for generating uevent for a status changes of connector's
> > > > > property.
> > > > > 
> > > > > This uevent will have following details related to the status change:
> > > > > 
> > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > 
> > > > > Need ACK from this uevent from userspace consumer.
> > > > 
> > > > So we just had some discussions over on IRC and at about the hotplug
> > > > issue and came up with similar ideas:
> > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > 
> > > > The conclusions of these discussions so far would be to have a more or
> > > > less fine grain of uevent reporting depending on what happened. The
> > > > point is that we need to cover different cases:
> > > > - one or more properties changed;
> > > > - the connector status changed;
> > > > - something else about the connector changed (e.g. EDID/modes)
> > > > 
> > > > For the first case, we can send out:
> > > > HOTPLUG=1
> > > > CONNECTOR=<id>
> > > > PROPERTY=<id>
> > > > 
> > > > and no reprobe is required.
> > > > 
> > > > For the second one, something like:
> > > > HOTPLUG=1
> > > > CONNECTOR=<id>
> > > > STATUS=Connected/Disconnected
> > > > 
> > > > and a connector probe is needed for connected, but not for
> > > > disconnected;
> > > > 
> > > > For the third one, we can only indicate the connector:
> > > > HOTPLUG=1
> > > > CONNECTOR=<id>
> > > > 
> > > > and a reprobe of the connector is always needed
> > > 
> > > There's no material difference between this one and the previous one.
> > > Plus there's no beenfit in supplying the actual value of the property,
> > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > 
> > That's the idea, but we need to handle status changes differently than
> > properties, since as far as I know, connected/unconnected status is not
> > exposed as a prop for the connector.
> 
> Oops, totally missed that. "Everything is a property" is kinda
> new-ish, at least compared to kms. Kinda tempted to just make status
> into a property. Or another excuse why we should expose the epoch
> property :-)

Well I think it would make sense anyway, as long as we can make sure it
stays consistent with the one reported in the connector struct.

> > > Here's why:
> > > - A side effect of forcing a probe on a connector is that you get to
> > > read all the properties, so supplying them is kinda pointless.
> > 
> > Agreed, except for the status case where it's useful to know it's a
> > disconnect, because we don't need any probe step in that case.
> > 
> > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > reasonable unfortunately, but oh well.
> > 
> > How would that be retreived then? From the looks of it, that's a
> > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > does the full reprobe.
> 
> drmGetConnector vs drmGetConnectorCurrent.

Ah right, forgot about that one, thanks.

> > Not sure what issues could arise in case of disconnect without reprobe
> > -- at least I don't see why userspace should have to do anything in
> > particular except no longer using the connector, even in complex DP MST
> > cases.
> 
> connector->status might be a lie without a full reprobe, and wrongly
> indicate that the connector is disconnected while there's still
> something plugged in. I'm not sure we've fixed those bugs by now
> (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> connected, and we can't break this because every intel platform ever
> shipped has a few devices where this is somehow broken, irrespective
> of the sink).

Mhh either way, I think it's up to the driver to report that and make
it consistent. I think we have poll helpers to make up for cases where
hotplug is not available too. So I'm not sure why a full reprobe would
be needed: drivers just need to do the right thing.

> > > - There's no way to only reprobe status, you can only ever reprobe
> > > everything with the current ioctl and implementations. Having an
> > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > almost all cases).
> > 
> > Agreed.
> > 
> > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > needs to reprobe this connector.
> > 
> > I thought we could access the props alone, which avoids doing a reprobe
> > when the kernel knows that only a prop or a set of props changed and do
> > not require a full reprobe. That's the first case I was mentionning.
> > 
> > > At that point we need to figure out whether this is a good uapi or
> > > not, and that's where the epoch comes in. There's two reasons for an
> > > epoch:
> > > - We need it internally because I'm not goinig to wire a new return
> > > value through hundreds of connector probe functions. It's much easier
> > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > similar functions that update probe state.
> > 
> > I don't think I'm following what issue this is trying to solve
> > internally.
> 
> So I'm assuming that if we handle a hotplug, we only want to generate
> one uevent for that, not one for every little thing that changed.
> There's two ways to implement this logic:
> - With some epoch counter and a helper function you can call everytime
> something changed (e.g. status, or edid, or anything else we care
> about e.g. from dp aux). This won't need much (if any) driver changes,
> because we can just put these into the relevant helper/core functions
> (like edid update, or dp aux reading or whatever).
> - Wiring a new return value through the entire stack (and _all_ the
> kms drivers) so that the probe helpers could aggregate this like they
> currently do.
> 
> One of these is a lot less typing.

Oh I had missed this issue. Yeah of course if we start reporting
property changes, a hotplug will be lots of such changes.

So an epoch counter property would indeed also solve the reprobing
problem. But I think it would be nice to keep the ability to be
notified of what changed precisely via uevent. I'm not really buying
the "missing uevent" thing so much and I think we can reasonably expect
that it will be useful. Events could be aggregated (which the epoch
counter would probably also allow) and sent out altogether when the
connector status changes (along with the status information). I think
we're under-using uevent currently, and feel like this should be fixed
regardless of the full reprobe issue.

With that, I agree that a global epoch counter from the connector would
be a good quick way for userspace to tell if a connector changed or not
since the last time it checked.

> > > - If userspace misses an event and there's no epoch, we're forcing
> > > userspace to reprobe everything. Use case would be if a compositor is
> > > switched away we probably don't want to piss of the current compositor
> > > by blocking it's own probe kernel calls by doing our own (probe is
> > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > it can read the epoch property (which it can do without forcing a
> > > reprobe) userspace would know which connectors it needs to check and
> > > reprobe.
> > > 
> > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > also require that userspace needs to keep parsing all uevents and make
> > > a list of all connectors it needs to reprobe when it's back to being
> > > the active compositor. But just comparing a current epoch with the one
> > > you cached from the last full probe is much easier.
> > 
> > Fair enough, I think it's a fine idea for robustness yes, but I think
> > we could also provide extra info in the uevent when relevant and not
> > rely on that entirely.
> 
> See above, with drmGetConnectorCurrent there's no need to provide more
> than what's needed in the uevent, since userspace can get everything
> else at the cost of one ioctl, without reprobing. With a bit of
> engineering work we could even avoid taking the expensive
> dev->mode_config.mutex lock for this fastpath.
> 
> > > Another thing: None of this we can for connectors with unreliable hdp.
> > > Or at least you'll piss of users if you cache always. The sad thing is
> > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > need to reprobe when the user asks for it. igt can probably get away
> > > without reprobing.
> > 
> > I wonder how that is handled currently and how a user action can solve
> > the issue without any notification from the kernel. Maybe a need a
> > better understanding of that case to have a clearer idea.
> 
> User opens the screen configuration tool -> usually at that point the
> tool/compositor force a full reprobe, which then often triggers the
> automatic reconfiguring. E.g. on one laptop I have here when I plug in
> random shit projectors at conferences nothing happens, until I run
> xrandr, which triggers the full reprobe, which then makes the kernel
> realize something change, sending and uevent, which starts the
> automatic reconfigure machinery.

Oh right hehe, I definitely do that blind alt+f2 gnome-control-center
to get me out of an off-panel situation much too often.

> There's also the issue that there's machines with hpd storms (even on
> DP, where you really need hpd to work to be compliant), and we have to
> turn of the hpd irq to keep the machine useable.

I was under the impression that we switch to polling when a hpd storm
is detected in i915 (but that's a vague memory from my summer
internship at Intel 2 years ago).

Cheers,

Paul

> Cheers, Daniel
> 
> > Cheers,
> > 
> > Paul
> > 
> > > -Daniel
> > > 
> > > > Then we still have the legacy case:
> > > > HOTPLUG=1
> > > > 
> > > > where userspace is expected to reprobe all the connectors.
> > > > 
> > > > I think this would deserve to be a separate series on its own. So I am
> > > > proposing to take this one off your plate and come up with another
> > > > seres implementing this proposal. What do you think?
> > > > 
> > > > Cheers,
> > > > 
> > > > Paul
> > > > 
> > > > > v2:
> > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > v3:
> > > > >   Check the property is really attached with connector [Daniel]
> > > > > 
> > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > @@ -21,6 +21,7 @@
> > > > >  #include <drm/drm_sysfs.h>
> > > > >  #include <drm/drmP.h>
> > > > >  #include "drm_internal.h"
> > > > > +#include "drm_crtc_internal.h"
> > > > > 
> > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > >   * deal with other types of events.
> > > > > + *
> > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > + * for uevents on connector status change.
> > > > >   */
> > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > >  {
> > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > >  }
> > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > 
> > > > > +/**
> > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > + * property status change
> > > > > + * @connector: connector on which property status changed
> > > > > + * @property: connector property whoes status changed.
> > > > > + *
> > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > + * related to the status change.
> > > > > + */
> > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > +                                   struct drm_property *property)
> > > > > +{
> > > > > +     struct drm_device *dev = connector->dev;
> > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > +
> > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > +                                        property->base.id));
> > > > > +
> > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > +              "PROPERTY=%u", property->base.id);
> > > > > +
> > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > +
> > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > +
> > > > >  static void drm_sysfs_release(struct device *dev)
> > > > >  {
> > > > >       kfree(dev);
> > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > --- a/include/drm/drm_sysfs.h
> > > > > +++ b/include/drm/drm_sysfs.h
> > > > > @@ -4,10 +4,13 @@
> > > > > 
> > > > >  struct drm_device;
> > > > >  struct device;
> > > > > +struct drm_connector;
> > > > > +struct drm_property;
> > > > > 
> > > > >  int drm_class_device_register(struct device *dev);
> > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > 
> > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > -
> > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > +                                   struct drm_property *property);
> > > > >  #endif
> > > > --
> > > > Paul Kocialkowski, Bootlin
> > > > Embedded Linux and kernel engineering
> > > > https://bootlin.com
> > > > 
> > --
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
> 
>
Hi-just wanted to give some general thoughts here.

First off I'm 100% behind the epoch idea, that was one of the ideas I had been
thinking of proposing here in the first place but probably forgot at some
point down the road.

A couple of other things:
 * I think it would also probably be good to have events for when connectors
   are added or removed from the system (mainly for MST)
 * Have we considered having any sort of SYNC event, like what evdev uses for
   signaling the end of a frame of events for input devices?

On Fri, 2019-05-10 at 14:12 +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > DRM API for generating uevent for a status changes of connector's
> > property.
> > 
> > This uevent will have following details related to the status change:
> > 
> >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > 
> > Need ACK from this uevent from userspace consumer.
> 
> So we just had some discussions over on IRC and at about the hotplug
> issue and came up with similar ideas:
> https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> 
> The conclusions of these discussions so far would be to have a more or
> less fine grain of uevent reporting depending on what happened. The
> point is that we need to cover different cases:
> - one or more properties changed;
> - the connector status changed;
> - something else about the connector changed (e.g. EDID/modes)
> 
> For the first case, we can send out:
> HOTPLUG=1
> CONNECTOR=<id>
> PROPERTY=<id>
> 
> and no reprobe is required.
> 
> For the second one, something like:
> HOTPLUG=1
> CONNECTOR=<id>
> STATUS=Connected/Disconnected
> 
> and a connector probe is needed for connected, but not for
> disconnected;
> 
> For the third one, we can only indicate the connector:
> HOTPLUG=1
> CONNECTOR=<id>
> 
> and a reprobe of the connector is always needed
> 
> Then we still have the legacy case:
> HOTPLUG=1
> 
> where userspace is expected to reprobe all the connectors.
> 
> I think this would deserve to be a separate series on its own. So I am
> proposing to take this one off your plate and come up with another
> seres implementing this proposal. What do you think?
> 
> Cheers,
> 
> Paul
> 
> > v2:
> >   Minor fixes at KDoc comments [Daniel]
> > v3:
> >   Check the property is really attached with connector [Daniel]
> > 
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> >  include/drm/drm_sysfs.h     |  5 ++++-
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 18b1ac442997..63fa951a20db 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -21,6 +21,7 @@
> >  #include <drm/drm_sysfs.h>
> >  #include <drm/drmP.h>
> >  #include "drm_internal.h"
> > +#include "drm_crtc_internal.h"
> >  
> >  #define to_drm_minor(d) dev_get_drvdata(d)
> >  #define to_drm_connector(d) dev_get_drvdata(d)
> > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> >   * deal with other types of events.
> > + *
> > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > + * for uevents on connector status change.
> >   */
> >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  {
> > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> >  
> > +/**
> > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > + * property status change
> > + * @connector: connector on which property status changed
> > + * @property: connector property whoes status changed.
> > + *
> > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > + * set HOTPLUG=1 and connector id along with the attached property id
> > + * related to the status change.
> > + */
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > +				      struct drm_property *property)
> > +{
> > +	struct drm_device *dev = connector->dev;
> > +	char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > +	char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > +
> > +	WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > +					   property->base.id));
> > +
> > +	snprintf(conn_id, ARRAY_SIZE(conn_id),
> > +		 "CONNECTOR=%u", connector->base.id);
> > +	snprintf(prop_id, ARRAY_SIZE(prop_id),
> > +		 "PROPERTY=%u", property->base.id);
> > +
> > +	DRM_DEBUG("generating connector status event\n");
> > +
> > +	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > +}
> > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > +
> >  static void drm_sysfs_release(struct device *dev)
> >  {
> >  	kfree(dev);
> > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > index 4f311e836cdc..d454ef617b2c 100644
> > --- a/include/drm/drm_sysfs.h
> > +++ b/include/drm/drm_sysfs.h
> > @@ -4,10 +4,13 @@
> >  
> >  struct drm_device;
> >  struct device;
> > +struct drm_connector;
> > +struct drm_property;
> >  
> >  int drm_class_device_register(struct device *dev);
> >  void drm_class_device_unregister(struct device *dev);
> >  
> >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > -
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > +				      struct drm_property *property);
> >  #endif
On Mon, 2019-05-13 at 17:04 +0200, Daniel Vetter wrote:
> On Mon, May 13, 2019 at 10:11:01AM +0000, Ser, Simon wrote:

> > On Mon, 2019-05-13 at 11:34 +0200, Daniel Vetter wrote:

> > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski

> > > <paul.kocialkowski@bootlin.com> wrote:

> > > > Hi,

> > > > 

> > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:

> > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski

> > > > > <paul.kocialkowski@bootlin.com> wrote:

> > > > > > Hi,

> > > > > > 

> > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:

> > > > > > > DRM API for generating uevent for a status changes of connector's

> > > > > > > property.

> > > > > > > 

> > > > > > > This uevent will have following details related to the status change:

> > > > > > > 

> > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>

> > > > > > > 

> > > > > > > Need ACK from this uevent from userspace consumer.

> > > > > > 

> > > > > > So we just had some discussions over on IRC and at about the hotplug

> > > > > > issue and came up with similar ideas:

> > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html

> > > > > > 

> > > > > > The conclusions of these discussions so far would be to have a more or

> > > > > > less fine grain of uevent reporting depending on what happened. The

> > > > > > point is that we need to cover different cases:

> > > > > > - one or more properties changed;

> > > > > > - the connector status changed;

> > > > > > - something else about the connector changed (e.g. EDID/modes)

> > > > > > 

> > > > > > For the first case, we can send out:

> > > > > > HOTPLUG=1

> > > > > > CONNECTOR=<id>

> > > > > > PROPERTY=<id>

> > > > > > 

> > > > > > and no reprobe is required.

> > > > > > 

> > > > > > For the second one, something like:

> > > > > > HOTPLUG=1

> > > > > > CONNECTOR=<id>

> > > > > > STATUS=Connected/Disconnected

> > > > > > 

> > > > > > and a connector probe is needed for connected, but not for

> > > > > > disconnected;

> > > > > > 

> > > > > > For the third one, we can only indicate the connector:

> > > > > > HOTPLUG=1

> > > > > > CONNECTOR=<id>

> > > > > > 

> > > > > > and a reprobe of the connector is always needed

> > > > > 

> > > > > There's no material difference between this one and the previous one.

> > > > > Plus there's no beenfit in supplying the actual value of the property,

> > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.

> > > > 

> > > > That's the idea, but we need to handle status changes differently than

> > > > properties, since as far as I know, connected/unconnected status is not

> > > > exposed as a prop for the connector.

> > > 

> > > Oops, totally missed that. "Everything is a property" is kinda

> > > new-ish, at least compared to kms. Kinda tempted to just make status

> > > into a property. Or another excuse why we should expose the epoch

> > > property :-)

> > > 

> > > > > Here's why:

> > > > > - A side effect of forcing a probe on a connector is that you get to

> > > > > read all the properties, so supplying them is kinda pointless.

> > > > 

> > > > Agreed, except for the status case where it's useful to know it's a

> > > > disconnect, because we don't need any probe step in that case.

> > > > 

> > > > > - You can read STATUS without forcing a reprobe, if you want to avoid

> > > > > the reprobe for disconnected. I'd kinda not recommend that though,

> > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.

> > > > > dp) reprobing a disconnected output is fast. HDMI is ... less

> > > > > reasonable unfortunately, but oh well.

> > > > 

> > > > How would that be retreived then? From the looks of it, that's a

> > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what

> > > > does the full reprobe.

> > > 

> > > drmGetConnector vs drmGetConnectorCurrent.

> > > 

> > > > Not sure what issues could arise in case of disconnect without reprobe

> > > > -- at least I don't see why userspace should have to do anything in

> > > > particular except no longer using the connector, even in complex DP MST

> > > > cases.

> > > 

> > > connector->status might be a lie without a full reprobe, and wrongly

> > > indicate that the connector is disconnected while there's still

> > > something plugged in. I'm not sure we've fixed those bugs by now

> > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates

> > > connected, and we can't break this because every intel platform ever

> > > shipped has a few devices where this is somehow broken, irrespective

> > > of the sink).

> > > 

> > > > > - There's no way to only reprobe status, you can only ever reprobe

> > > > > everything with the current ioctl and implementations. Having an

> > > > > option to reprobe only parts of it doesn't seem useful to me (we need

> > > > > to read the EDID anyway, and that's the expensive part of reprobing in

> > > > > almost all cases).

> > > > 

> > > > Agreed.

> > > > 

> > > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it

> > > > > needs to reprobe this connector.

> > > > 

> > > > I thought we could access the props alone, which avoids doing a reprobe

> > > > when the kernel knows that only a prop or a set of props changed and do

> > > > not require a full reprobe. That's the first case I was mentionning.

> > > > 

> > > > > At that point we need to figure out whether this is a good uapi or

> > > > > not, and that's where the epoch comes in. There's two reasons for an

> > > > > epoch:

> > > > > - We need it internally because I'm not goinig to wire a new return

> > > > > value through hundreds of connector probe functions. It's much easier

> > > > > to have an epoch counter which we set from e.g. drm_set_edid and

> > > > > similar functions that update probe state.

> > > > 

> > > > I don't think I'm following what issue this is trying to solve

> > > > internally.

> > > 

> > > So I'm assuming that if we handle a hotplug, we only want to generate

> > > one uevent for that, not one for every little thing that changed.

> > > There's two ways to implement this logic:

> > > - With some epoch counter and a helper function you can call everytime

> > > something changed (e.g. status, or edid, or anything else we care

> > > about e.g. from dp aux). This won't need much (if any) driver changes,

> > > because we can just put these into the relevant helper/core functions

> > > (like edid update, or dp aux reading or whatever).

> > > - Wiring a new return value through the entire stack (and _all_ the

> > > kms drivers) so that the probe helpers could aggregate this like they

> > > currently do.

> > > 

> > > One of these is a lot less typing.

> > > 

> > > > > - If userspace misses an event and there's no epoch, we're forcing

> > > > > userspace to reprobe everything. Use case would be if a compositor is

> > > > > switched away we probably don't want to piss of the current compositor

> > > > > by blocking it's own probe kernel calls by doing our own (probe is

> > > > > single-threaded in the kernel through the dev->mode_config.mutex). If

> > > > > it can read the epoch property (which it can do without forcing a

> > > > > reprobe) userspace would know which connectors it needs to check and

> > > > > reprobe.

> > > > > 

> > > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could

> > > > > also require that userspace needs to keep parsing all uevents and make

> > > > > a list of all connectors it needs to reprobe when it's back to being

> > > > > the active compositor. But just comparing a current epoch with the one

> > > > > you cached from the last full probe is much easier.

> > > > 

> > > > Fair enough, I think it's a fine idea for robustness yes, but I think

> > > > we could also provide extra info in the uevent when relevant and not

> > > > rely on that entirely.

> > > 

> > > See above, with drmGetConnectorCurrent there's no need to provide more

> > > than what's needed in the uevent, since userspace can get everything

> > > else at the cost of one ioctl, without reprobing. With a bit of

> > > engineering work we could even avoid taking the expensive

> > > dev->mode_config.mutex lock for this fastpath.

> > > 

> > > > > Another thing: None of this we can for connectors with unreliable hdp.

> > > > > Or at least you'll piss of users if you cache always. The sad thing is

> > > > > that HDMI is unreliable, at least on some machines/screen combos (you

> > > > > never get a hpd irq if you plug in/unplug). So real compositors still

> > > > > need to reprobe when the user asks for it. igt can probably get away

> > > > > without reprobing.

> > > > 

> > > > I wonder how that is handled currently and how a user action can solve

> > > > the issue without any notification from the kernel. Maybe a need a

> > > > better understanding of that case to have a clearer idea.

> > > 

> > > User opens the screen configuration tool -> usually at that point the

> > > tool/compositor force a full reprobe, which then often triggers the

> > > automatic reconfiguring. E.g. on one laptop I have here when I plug in

> > > random shit projectors at conferences nothing happens, until I run

> > > xrandr, which triggers the full reprobe, which then makes the kernel

> > > realize something change, sending and uevent, which starts the

> > > automatic reconfigure machinery.

> > > 

> > > There's also the issue that there's machines with hpd storms (even on

> > > DP, where you really need hpd to work to be compliant), and we have to

> > > turn of the hpd irq to keep the machine useable.

> > 

> > Note that xrandr only works on X11. On Wayland, it won't.

> > 

> > Whether the user can actually do anything depends on the compositor. On

> > GNOME the D-Bus interface could probably force a re-probe when a

> > configuration tool is started or maybe with a "Rescan connectors"

> > button (not sure they'd like to have this in their UI). On KDE, Weston

> > and wlroots there is no way to do it.

> > 

> > As compositor writers, do we really need to provide a way for users to

> > force a reprobe? Can't the kernel do anything to handle these bad

> > screens?

> 

> Yeah, we defensively fall back to polling. Which isn't great from a power

> usage pov.

> 

> btw as long as compositors use drmGetConnector and not just

> drmGetConnectorCurrent you can trigger a full reprobe. If there's not way

> to trigger that they'll all have to add a "force probe" button sooner or

> later. But usually it's enough if you do a full reprobe when the user

> starts your config tool.


FWIW, some compositors (Weston, wlroots-based ones) don't have a
"graphical config tool", either because it's command-line (and event-
based, not poll-based) or because screen configuration is static (but
hotplug is supported). I guess we would need to expose some kind of
"rescan" command, which nobody will know about. Sigh.

> > > Cheers, Daniel

> > > 

> > > > Cheers,

> > > > 

> > > > Paul

> > > > 

> > > > > -Daniel

> > > > > 

> > > > > > Then we still have the legacy case:

> > > > > > HOTPLUG=1

> > > > > > 

> > > > > > where userspace is expected to reprobe all the connectors.

> > > > > > 

> > > > > > I think this would deserve to be a separate series on its own. So I am

> > > > > > proposing to take this one off your plate and come up with another

> > > > > > seres implementing this proposal. What do you think?

> > > > > > 

> > > > > > Cheers,

> > > > > > 

> > > > > > Paul

> > > > > > 

> > > > > > > v2:

> > > > > > >   Minor fixes at KDoc comments [Daniel]

> > > > > > > v3:

> > > > > > >   Check the property is really attached with connector [Daniel]

> > > > > > > 

> > > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>

> > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> > > > > > > ---

> > > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++

> > > > > > >  include/drm/drm_sysfs.h     |  5 ++++-

> > > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)

> > > > > > > 

> > > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c

> > > > > > > index 18b1ac442997..63fa951a20db 100644

> > > > > > > --- a/drivers/gpu/drm/drm_sysfs.c

> > > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c

> > > > > > > @@ -21,6 +21,7 @@

> > > > > > >  #include <drm/drm_sysfs.h>

> > > > > > >  #include <drm/drmP.h>

> > > > > > >  #include "drm_internal.h"

> > > > > > > +#include "drm_crtc_internal.h"

> > > > > > > 

> > > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)

> > > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)

> > > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)

> > > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only

> > > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to

> > > > > > >   * deal with other types of events.

> > > > > > > + *

> > > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()

> > > > > > > + * for uevents on connector status change.

> > > > > > >   */

> > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)

> > > > > > >  {

> > > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)

> > > > > > >  }

> > > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);

> > > > > > > 

> > > > > > > +/**

> > > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector

> > > > > > > + * property status change

> > > > > > > + * @connector: connector on which property status changed

> > > > > > > + * @property: connector property whoes status changed.

> > > > > > > + *

> > > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we

> > > > > > > + * set HOTPLUG=1 and connector id along with the attached property id

> > > > > > > + * related to the status change.

> > > > > > > + */

> > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,

> > > > > > > +                                   struct drm_property *property)

> > > > > > > +{

> > > > > > > +     struct drm_device *dev = connector->dev;

> > > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];

> > > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };

> > > > > > > +

> > > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,

> > > > > > > +                                        property->base.id));

> > > > > > > +

> > > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),

> > > > > > > +              "CONNECTOR=%u", connector->base.id);

> > > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),

> > > > > > > +              "PROPERTY=%u", property->base.id);

> > > > > > > +

> > > > > > > +     DRM_DEBUG("generating connector status event\n");

> > > > > > > +

> > > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);

> > > > > > > +}

> > > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);

> > > > > > > +

> > > > > > >  static void drm_sysfs_release(struct device *dev)

> > > > > > >  {

> > > > > > >       kfree(dev);

> > > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h

> > > > > > > index 4f311e836cdc..d454ef617b2c 100644

> > > > > > > --- a/include/drm/drm_sysfs.h

> > > > > > > +++ b/include/drm/drm_sysfs.h

> > > > > > > @@ -4,10 +4,13 @@

> > > > > > > 

> > > > > > >  struct drm_device;

> > > > > > >  struct device;

> > > > > > > +struct drm_connector;

> > > > > > > +struct drm_property;

> > > > > > > 

> > > > > > >  int drm_class_device_register(struct device *dev);

> > > > > > >  void drm_class_device_unregister(struct device *dev);

> > > > > > > 

> > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);

> > > > > > > -

> > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,

> > > > > > > +                                   struct drm_property *property);

> > > > > > >  #endif

> > > > > > --

> > > > > > Paul Kocialkowski, Bootlin

> > > > > > Embedded Linux and kernel engineering

> > > > > > https://bootlin.com

> > > > > > 

> > > > --

> > > > Paul Kocialkowski, Bootlin

> > > > Embedded Linux and kernel engineering

> > > > https://bootlin.com

> > > >

On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2019 11:34:58 +0200

> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> 

> > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski

> > <paul.kocialkowski@bootlin.com> wrote:

> > > Hi,

> > > 

> > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:  

> > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski

> > > > <paul.kocialkowski@bootlin.com> wrote:  

> > > > > Hi,

> > > > > 

> > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:  

> > > > > > DRM API for generating uevent for a status changes of connector's

> > > > > > property.

> > > > > > 

> > > > > > This uevent will have following details related to the status change:

> > > > > > 

> > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>

> > > > > > 

> > > > > > Need ACK from this uevent from userspace consumer.  

> > > > > 

> > > > > So we just had some discussions over on IRC and at about the hotplug

> > > > > issue and came up with similar ideas:

> > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html

> > > > > 

> > > > > The conclusions of these discussions so far would be to have a more or

> > > > > less fine grain of uevent reporting depending on what happened. The

> > > > > point is that we need to cover different cases:

> > > > > - one or more properties changed;

> > > > > - the connector status changed;

> > > > > - something else about the connector changed (e.g. EDID/modes)

> > > > > 

> > > > > For the first case, we can send out:

> > > > > HOTPLUG=1

> > > > > CONNECTOR=<id>

> > > > > PROPERTY=<id>

> > > > > 

> > > > > and no reprobe is required.

> > > > > 

> > > > > For the second one, something like:

> > > > > HOTPLUG=1

> > > > > CONNECTOR=<id>

> > > > > STATUS=Connected/Disconnected

> > > > > 

> > > > > and a connector probe is needed for connected, but not for

> > > > > disconnected;

> > > > > 

> > > > > For the third one, we can only indicate the connector:

> > > > > HOTPLUG=1

> > > > > CONNECTOR=<id>

> > > > > 

> > > > > and a reprobe of the connector is always needed  

> > > > 

> > > > There's no material difference between this one and the previous one.

> > > > Plus there's no beenfit in supplying the actual value of the property,

> > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.  

> > > 

> > > That's the idea, but we need to handle status changes differently than

> > > properties, since as far as I know, connected/unconnected status is not

> > > exposed as a prop for the connector.  

> > 

> > Oops, totally missed that. "Everything is a property" is kinda

> > new-ish, at least compared to kms. Kinda tempted to just make status

> > into a property. Or another excuse why we should expose the epoch

> > property :-)

> 

> Hi Daniel,

> 

> just to clarify the first case, specific to one very particular

> property:

> 

> With HDCP, there is a property that may change dynamically at runtime

> (the undesired/desired/enabled tristate). Userspace must be notified

> when it changes, I do not want userspace have to poll that property

> with a timer.

> 

> When that property alone changes, and userspace is prepared to handle

> that property changing alone, it must not trigger a reprobe of the

> connector. There is no reason to reprobe at that point AFAIU.

> 

> How do you ensure that userspace can avoid triggering a reprobe with the

> epoch approach or with any alternate uevent design?

> 

> We need an event to userspace that indicates that re-reading the

> properties is enough and reprobe of the connector is not necessary.

> This is complementary to indicating to userspace that only some

> connectors need to be reprobed instead of everything.


Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
reprobing. Would that work?
On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:
>
> On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:
> > On Mon, 13 May 2019 11:34:58 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > >
> > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > property.
> > > > > > >
> > > > > > > This uevent will have following details related to the status change:
> > > > > > >
> > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > >
> > > > > > > Need ACK from this uevent from userspace consumer.
> > > > > >
> > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > issue and came up with similar ideas:
> > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > >
> > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > point is that we need to cover different cases:
> > > > > > - one or more properties changed;
> > > > > > - the connector status changed;
> > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > >
> > > > > > For the first case, we can send out:
> > > > > > HOTPLUG=1
> > > > > > CONNECTOR=<id>
> > > > > > PROPERTY=<id>
> > > > > >
> > > > > > and no reprobe is required.
> > > > > >
> > > > > > For the second one, something like:
> > > > > > HOTPLUG=1
> > > > > > CONNECTOR=<id>
> > > > > > STATUS=Connected/Disconnected
> > > > > >
> > > > > > and a connector probe is needed for connected, but not for
> > > > > > disconnected;
> > > > > >
> > > > > > For the third one, we can only indicate the connector:
> > > > > > HOTPLUG=1
> > > > > > CONNECTOR=<id>
> > > > > >
> > > > > > and a reprobe of the connector is always needed
> > > > >
> > > > > There's no material difference between this one and the previous one.
> > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > >
> > > > That's the idea, but we need to handle status changes differently than
> > > > properties, since as far as I know, connected/unconnected status is not
> > > > exposed as a prop for the connector.
> > >
> > > Oops, totally missed that. "Everything is a property" is kinda
> > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > into a property. Or another excuse why we should expose the epoch
> > > property :-)
> >
> > Hi Daniel,
> >
> > just to clarify the first case, specific to one very particular
> > property:
> >
> > With HDCP, there is a property that may change dynamically at runtime
> > (the undesired/desired/enabled tristate). Userspace must be notified
> > when it changes, I do not want userspace have to poll that property
> > with a timer.
> >
> > When that property alone changes, and userspace is prepared to handle
> > that property changing alone, it must not trigger a reprobe of the
> > connector. There is no reason to reprobe at that point AFAIU.
> >
> > How do you ensure that userspace can avoid triggering a reprobe with the
> > epoch approach or with any alternate uevent design?
> >
> > We need an event to userspace that indicates that re-reading the
> > properties is enough and reprobe of the connector is not necessary.
> > This is complementary to indicating to userspace that only some
> > connectors need to be reprobed instead of everything.
>
> Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> reprobing. Would that work?

Yes that's the idea, depending upon which property you get you know
it's a sink change (needs full reprobe) or something else like hdcp
state machinery update.

Wrt avoiding the full reprobe for sink changes: I think we should
indeed decouple that from the per-connector event for sink changes.
That along is a good win already, since you know for which connector
you need to call drmGetConnector (which forces the reprobe). It would
be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
historically speaking every time we tried to rely on this we ended up
regretting things.
-Daniel
On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hey,
>
> Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit :
> > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > property.
> > > > > >
> > > > > > This uevent will have following details related to the status change:
> > > > > >
> > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > >
> > > > > > Need ACK from this uevent from userspace consumer.
> > > > >
> > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > issue and came up with similar ideas:
> > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > >
> > > > > The conclusions of these discussions so far would be to have a more or
> > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > point is that we need to cover different cases:
> > > > > - one or more properties changed;
> > > > > - the connector status changed;
> > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > >
> > > > > For the first case, we can send out:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > PROPERTY=<id>
> > > > >
> > > > > and no reprobe is required.
> > > > >
> > > > > For the second one, something like:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > STATUS=Connected/Disconnected
> > > > >
> > > > > and a connector probe is needed for connected, but not for
> > > > > disconnected;
> > > > >
> > > > > For the third one, we can only indicate the connector:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > >
> > > > > and a reprobe of the connector is always needed
> > > >
> > > > There's no material difference between this one and the previous one.
> > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > >
> > > That's the idea, but we need to handle status changes differently than
> > > properties, since as far as I know, connected/unconnected status is not
> > > exposed as a prop for the connector.
> >
> > Oops, totally missed that. "Everything is a property" is kinda
> > new-ish, at least compared to kms. Kinda tempted to just make status
> > into a property. Or another excuse why we should expose the epoch
> > property :-)
>
> Well I think it would make sense anyway, as long as we can make sure it
> stays consistent with the one reported in the connector struct.
>
> > > > Here's why:
> > > > - A side effect of forcing a probe on a connector is that you get to
> > > > read all the properties, so supplying them is kinda pointless.
> > >
> > > Agreed, except for the status case where it's useful to know it's a
> > > disconnect, because we don't need any probe step in that case.
> > >
> > > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > > reasonable unfortunately, but oh well.
> > >
> > > How would that be retreived then? From the looks of it, that's a
> > > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > > does the full reprobe.
> >
> > drmGetConnector vs drmGetConnectorCurrent.
>
> Ah right, forgot about that one, thanks.
>
> > > Not sure what issues could arise in case of disconnect without reprobe
> > > -- at least I don't see why userspace should have to do anything in
> > > particular except no longer using the connector, even in complex DP MST
> > > cases.
> >
> > connector->status might be a lie without a full reprobe, and wrongly
> > indicate that the connector is disconnected while there's still
> > something plugged in. I'm not sure we've fixed those bugs by now
> > (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> > connected, and we can't break this because every intel platform ever
> > shipped has a few devices where this is somehow broken, irrespective
> > of the sink).
>
> Mhh either way, I think it's up to the driver to report that and make
> it consistent. I think we have poll helpers to make up for cases where
> hotplug is not available too. So I'm not sure why a full reprobe would
> be needed: drivers just need to do the right thing.
>
> > > > - There's no way to only reprobe status, you can only ever reprobe
> > > > everything with the current ioctl and implementations. Having an
> > > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > > almost all cases).
> > >
> > > Agreed.
> > >
> > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > > needs to reprobe this connector.
> > >
> > > I thought we could access the props alone, which avoids doing a reprobe
> > > when the kernel knows that only a prop or a set of props changed and do
> > > not require a full reprobe. That's the first case I was mentionning.
> > >
> > > > At that point we need to figure out whether this is a good uapi or
> > > > not, and that's where the epoch comes in. There's two reasons for an
> > > > epoch:
> > > > - We need it internally because I'm not goinig to wire a new return
> > > > value through hundreds of connector probe functions. It's much easier
> > > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > > similar functions that update probe state.
> > >
> > > I don't think I'm following what issue this is trying to solve
> > > internally.
> >
> > So I'm assuming that if we handle a hotplug, we only want to generate
> > one uevent for that, not one for every little thing that changed.
> > There's two ways to implement this logic:
> > - With some epoch counter and a helper function you can call everytime
> > something changed (e.g. status, or edid, or anything else we care
> > about e.g. from dp aux). This won't need much (if any) driver changes,
> > because we can just put these into the relevant helper/core functions
> > (like edid update, or dp aux reading or whatever).
> > - Wiring a new return value through the entire stack (and _all_ the
> > kms drivers) so that the probe helpers could aggregate this like they
> > currently do.
> >
> > One of these is a lot less typing.
>
> Oh I had missed this issue. Yeah of course if we start reporting
> property changes, a hotplug will be lots of such changes.
>
> So an epoch counter property would indeed also solve the reprobing
> problem. But I think it would be nice to keep the ability to be
> notified of what changed precisely via uevent. I'm not really buying
> the "missing uevent" thing so much and I think we can reasonably expect
> that it will be useful. Events could be aggregated (which the epoch
> counter would probably also allow) and sent out altogether when the
> connector status changes (along with the status information). I think
> we're under-using uevent currently, and feel like this should be fixed
> regardless of the full reprobe issue.

I see two options:

1) kernel aggregates uevents a bit, and sends out one (per connector
that changed) indicating that sink related state changed. Userspace
listens to that, and does a drmGetConnector as a result to update
itself. Most of this code needs to exist anyway.

2) kernel sends out updates as we go, userspace reassembles everything
again (and not really an idea when all the updates are in, see Lyude's
question. Plus userspace still needs to have the drmGetConnector path,
at least for initial setup.

I don't see why 2) is any better than 1), and it has some clear downsides.

> With that, I agree that a global epoch counter from the connector would
> be a good quick way for userspace to tell if a connector changed or not
> since the last time it checked.
>
> > > > - If userspace misses an event and there's no epoch, we're forcing
> > > > userspace to reprobe everything. Use case would be if a compositor is
> > > > switched away we probably don't want to piss of the current compositor
> > > > by blocking it's own probe kernel calls by doing our own (probe is
> > > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > > it can read the epoch property (which it can do without forcing a
> > > > reprobe) userspace would know which connectors it needs to check and
> > > > reprobe.
> > > >
> > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > > also require that userspace needs to keep parsing all uevents and make
> > > > a list of all connectors it needs to reprobe when it's back to being
> > > > the active compositor. But just comparing a current epoch with the one
> > > > you cached from the last full probe is much easier.
> > >
> > > Fair enough, I think it's a fine idea for robustness yes, but I think
> > > we could also provide extra info in the uevent when relevant and not
> > > rely on that entirely.
> >
> > See above, with drmGetConnectorCurrent there's no need to provide more
> > than what's needed in the uevent, since userspace can get everything
> > else at the cost of one ioctl, without reprobing. With a bit of
> > engineering work we could even avoid taking the expensive
> > dev->mode_config.mutex lock for this fastpath.
> >
> > > > Another thing: None of this we can for connectors with unreliable hdp.
> > > > Or at least you'll piss of users if you cache always. The sad thing is
> > > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > > need to reprobe when the user asks for it. igt can probably get away
> > > > without reprobing.
> > >
> > > I wonder how that is handled currently and how a user action can solve
> > > the issue without any notification from the kernel. Maybe a need a
> > > better understanding of that case to have a clearer idea.
> >
> > User opens the screen configuration tool -> usually at that point the
> > tool/compositor force a full reprobe, which then often triggers the
> > automatic reconfiguring. E.g. on one laptop I have here when I plug in
> > random shit projectors at conferences nothing happens, until I run
> > xrandr, which triggers the full reprobe, which then makes the kernel
> > realize something change, sending and uevent, which starts the
> > automatic reconfigure machinery.
>
> Oh right hehe, I definitely do that blind alt+f2 gnome-control-center
> to get me out of an off-panel situation much too often.
>
> > There's also the issue that there's machines with hpd storms (even on
> > DP, where you really need hpd to work to be compliant), and we have to
> > turn of the hpd irq to keep the machine useable.
>
> I was under the impression that we switch to polling when a hpd storm
> is detected in i915 (but that's a vague memory from my summer
> internship at Intel 2 years ago).

We do poll, but the issue is still that polling doesn't do the same
thing as full reprobe. One just calls ->detect, the other ->detect +
->get_modes. This is a bit a silliness of the helpers and source of
lots of confusion. A possible fix might be to always call both.

Plus even when that mess is sorted there's still the issue of broken
hw, and we have no idea how much/where/which exactly. Except that
every time we relied on hpd status, we got regression reports and had
to revert.
-Daniel

> Cheers,
>
> Paul
>
> > Cheers, Daniel
> >
> > > Cheers,
> > >
> > > Paul
> > >
> > > > -Daniel
> > > >
> > > > > Then we still have the legacy case:
> > > > > HOTPLUG=1
> > > > >
> > > > > where userspace is expected to reprobe all the connectors.
> > > > >
> > > > > I think this would deserve to be a separate series on its own. So I am
> > > > > proposing to take this one off your plate and come up with another
> > > > > seres implementing this proposal. What do you think?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Paul
> > > > >
> > > > > > v2:
> > > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > > v3:
> > > > > >   Check the property is really attached with connector [Daniel]
> > > > > >
> > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > > @@ -21,6 +21,7 @@
> > > > > >  #include <drm/drm_sysfs.h>
> > > > > >  #include <drm/drmP.h>
> > > > > >  #include "drm_internal.h"
> > > > > > +#include "drm_crtc_internal.h"
> > > > > >
> > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > > >   * deal with other types of events.
> > > > > > + *
> > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > > + * for uevents on connector status change.
> > > > > >   */
> > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > >  {
> > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > >  }
> > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > >
> > > > > > +/**
> > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > > + * property status change
> > > > > > + * @connector: connector on which property status changed
> > > > > > + * @property: connector property whoes status changed.
> > > > > > + *
> > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > > + * related to the status change.
> > > > > > + */
> > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > +                                   struct drm_property *property)
> > > > > > +{
> > > > > > +     struct drm_device *dev = connector->dev;
> > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > > +
> > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > > +                                        property->base.id));
> > > > > > +
> > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > > +              "PROPERTY=%u", property->base.id);
> > > > > > +
> > > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > > +
> > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > > +}
> > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > > +
> > > > > >  static void drm_sysfs_release(struct device *dev)
> > > > > >  {
> > > > > >       kfree(dev);
> > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > > --- a/include/drm/drm_sysfs.h
> > > > > > +++ b/include/drm/drm_sysfs.h
> > > > > > @@ -4,10 +4,13 @@
> > > > > >
> > > > > >  struct drm_device;
> > > > > >  struct device;
> > > > > > +struct drm_connector;
> > > > > > +struct drm_property;
> > > > > >
> > > > > >  int drm_class_device_register(struct device *dev);
> > > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > >
> > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > > -
> > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > +                                   struct drm_property *property);
> > > > > >  #endif
> > > > > --
> > > > > Paul Kocialkowski, Bootlin
> > > > > Embedded Linux and kernel engineering
> > > > > https://bootlin.com
> > > > >
> > > --
> > > Paul Kocialkowski, Bootlin
> > > Embedded Linux and kernel engineering
> > > https://bootlin.com
> > >
> >
> >
>
On Mon, May 13, 2019 at 11:20 PM Lyude Paul <lyude@redhat.com> wrote:
>
> Hi-just wanted to give some general thoughts here.
>
> First off I'm 100% behind the epoch idea, that was one of the ideas I had been
> thinking of proposing here in the first place but probably forgot at some
> point down the road.
>
> A couple of other things:
>  * I think it would also probably be good to have events for when connectors
>    are added or removed from the system (mainly for MST)

Current uevent + userspace looks at the connector list from
drmGetResources? That should be enough to figure this out I think ...

>  * Have we considered having any sort of SYNC event, like what evdev uses for
>    signaling the end of a frame of events for input devices?

If we go with just 1 event, then that's the natural sync marker
stating "everything we updated for this connector is now updated". For
more global events the global uevent could serve that role (I guess
this is useful for hotpluggin/unpluggin entire mst chains - we might
want to coalesce these indeed).

I also don't think we need to make this an uapi guarantee, just best
effort kernel implementation - userspace needs to always be able to
deal with an event right after the one it's just processing.
-Daniel

>
> On Fri, 2019-05-10 at 14:12 +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > DRM API for generating uevent for a status changes of connector's
> > > property.
> > >
> > > This uevent will have following details related to the status change:
> > >
> > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > >
> > > Need ACK from this uevent from userspace consumer.
> >
> > So we just had some discussions over on IRC and at about the hotplug
> > issue and came up with similar ideas:
> > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> >
> > The conclusions of these discussions so far would be to have a more or
> > less fine grain of uevent reporting depending on what happened. The
> > point is that we need to cover different cases:
> > - one or more properties changed;
> > - the connector status changed;
> > - something else about the connector changed (e.g. EDID/modes)
> >
> > For the first case, we can send out:
> > HOTPLUG=1
> > CONNECTOR=<id>
> > PROPERTY=<id>
> >
> > and no reprobe is required.
> >
> > For the second one, something like:
> > HOTPLUG=1
> > CONNECTOR=<id>
> > STATUS=Connected/Disconnected
> >
> > and a connector probe is needed for connected, but not for
> > disconnected;
> >
> > For the third one, we can only indicate the connector:
> > HOTPLUG=1
> > CONNECTOR=<id>
> >
> > and a reprobe of the connector is always needed
> >
> > Then we still have the legacy case:
> > HOTPLUG=1
> >
> > where userspace is expected to reprobe all the connectors.
> >
> > I think this would deserve to be a separate series on its own. So I am
> > proposing to take this one off your plate and come up with another
> > seres implementing this proposal. What do you think?
> >
> > Cheers,
> >
> > Paul
> >
> > > v2:
> > >   Minor fixes at KDoc comments [Daniel]
> > > v3:
> > >   Check the property is really attached with connector [Daniel]
> > >
> > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > ---
> > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > >  include/drm/drm_sysfs.h     |  5 ++++-
> > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > index 18b1ac442997..63fa951a20db 100644
> > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > @@ -21,6 +21,7 @@
> > >  #include <drm/drm_sysfs.h>
> > >  #include <drm/drmP.h>
> > >  #include "drm_internal.h"
> > > +#include "drm_crtc_internal.h"
> > >
> > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > >   * deal with other types of events.
> > > + *
> > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > + * for uevents on connector status change.
> > >   */
> > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > >  {
> > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > >  }
> > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > >
> > > +/**
> > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > + * property status change
> > > + * @connector: connector on which property status changed
> > > + * @property: connector property whoes status changed.
> > > + *
> > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > + * related to the status change.
> > > + */
> > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > +                                 struct drm_property *property)
> > > +{
> > > +   struct drm_device *dev = connector->dev;
> > > +   char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > +   char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > +
> > > +   WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > +                                      property->base.id));
> > > +
> > > +   snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > +            "CONNECTOR=%u", connector->base.id);
> > > +   snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > +            "PROPERTY=%u", property->base.id);
> > > +
> > > +   DRM_DEBUG("generating connector status event\n");
> > > +
> > > +   kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > +}
> > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > +
> > >  static void drm_sysfs_release(struct device *dev)
> > >  {
> > >     kfree(dev);
> > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > index 4f311e836cdc..d454ef617b2c 100644
> > > --- a/include/drm/drm_sysfs.h
> > > +++ b/include/drm/drm_sysfs.h
> > > @@ -4,10 +4,13 @@
> > >
> > >  struct drm_device;
> > >  struct device;
> > > +struct drm_connector;
> > > +struct drm_property;
> > >
> > >  int drm_class_device_register(struct device *dev);
> > >  void drm_class_device_unregister(struct device *dev);
> > >
> > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > -
> > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > +                                 struct drm_property *property);
> > >  #endif
> --
> Cheers,
>         Lyude Paul
>

Hi,

On Tue, 2019-05-14 at 16:36 +0300, Pekka Paalanen wrote:
> On Tue, 14 May 2019 13:02:09 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:
> > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:  
> > > > On Mon, 13 May 2019 11:34:58 +0200
> > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > >  
> > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:  
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:  
> > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:  
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:  
> > > > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > > > property.
> > > > > > > > > 
> > > > > > > > > This uevent will have following details related to the status change:
> > > > > > > > > 
> > > > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > > > > 
> > > > > > > > > Need ACK from this uevent from userspace consumer.  
> > > > > > > > 
> > > > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > > > issue and came up with similar ideas:
> > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > > > > 
> > > > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > > > point is that we need to cover different cases:
> > > > > > > > - one or more properties changed;
> > > > > > > > - the connector status changed;
> > > > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > > > > 
> > > > > > > > For the first case, we can send out:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > PROPERTY=<id>
> > > > > > > > 
> > > > > > > > and no reprobe is required.
> > > > > > > > 
> > > > > > > > For the second one, something like:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > STATUS=Connected/Disconnected
> > > > > > > > 
> > > > > > > > and a connector probe is needed for connected, but not for
> > > > > > > > disconnected;
> > > > > > > > 
> > > > > > > > For the third one, we can only indicate the connector:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > 
> > > > > > > > and a reprobe of the connector is always needed  
> > > > > > > 
> > > > > > > There's no material difference between this one and the previous one.
> > > > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.  
> > > > > > 
> > > > > > That's the idea, but we need to handle status changes differently than
> > > > > > properties, since as far as I know, connected/unconnected status is not
> > > > > > exposed as a prop for the connector.  
> > > > > 
> > > > > Oops, totally missed that. "Everything is a property" is kinda
> > > > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > > > into a property. Or another excuse why we should expose the epoch
> > > > > property :-)  
> > > > 
> > > > Hi Daniel,
> > > > 
> > > > just to clarify the first case, specific to one very particular
> > > > property:
> > > > 
> > > > With HDCP, there is a property that may change dynamically at runtime
> > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > when it changes, I do not want userspace have to poll that property
> > > > with a timer.
> > > > 
> > > > When that property alone changes, and userspace is prepared to handle
> > > > that property changing alone, it must not trigger a reprobe of the
> > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > 
> > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > epoch approach or with any alternate uevent design?
> > > > 
> > > > We need an event to userspace that indicates that re-reading the
> > > > properties is enough and reprobe of the connector is not necessary.
> > > > This is complementary to indicating to userspace that only some
> > > > connectors need to be reprobed instead of everything.  
> > > 
> > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > reprobing. Would that work?  
> 
> Hi,
> 
> yes, that would work, if it was acceptable to DRM upstream. The replies
> to Paul seemed to be going south so fast that I thought we wouldn't get
> any new uevent fields in favour of "epoch counters".
> 
> > Yes that's the idea, depending upon which property you get you know
> > it's a sink change (needs full reprobe) or something else like hdcp
> > state machinery update.
> 
> Right.
> 
> > Wrt avoiding the full reprobe for sink changes: I think we should
> > indeed decouple that from the per-connector event for sink changes.
> > That along is a good win already, since you know for which connector
> > you need to call drmGetConnector (which forces the reprobe). It would
> > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > historically speaking every time we tried to rely on this we ended up
> > regretting things.
> 
> What changed? This sounds very much what Paul suggested. Looking at it
> from userspace side:
> 
> HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> 
> - If yy is "Content Protection", no need to drmModeGetConnector(), just
>   re-get the connector properties.
> 
> - Kernel probably shouldn't bother sending this for properties where
>   re-probe could be necessary, and send the below instead.
> 
> HOTPLUG=1 CONNECTOR=xx
> 
> - Needs to drmModeGetConnector() on the one connector, no need to probe
>   others. Implies that one needs to re-get the connector properties as
>   well.
> 
> HOTPLUG=1
> 
> - Need to do drmModeGetResouces() to discover new/disappeared
>   connectors, and need to drmModeGetConnector to re-probe every
>   connector. (As always.)
> 
> That should be also backwards-compatible: any userspace that doesn't
> understand CONNECTOR will see HOTPLUG=1 and re-probe everything. Any
> userspace that doesn't understand PROPERTY or the property it refers to
> will fall back to probing either the connector or everything.
> 
> I would be happy to get that behaviour into Weston, particularly as the
> HDCP feature is brewing for Weston too.
> 
> --------
> 
> When discussing this in IRC, I had the concern about how uevents are
> delivered in userspace. Is there a possibility that they might be
> overwritten, contain stale attributes, or get squashed together?
> 
> Particularly if a display server is current on the VT and active and
> monitoring udev, but stuck doing something and cannot service uevents
> very fast, and the kernel sends more than one event before the process
> gets back to dispatching. The terminology in libudev API confused me as
> an event is a device. Squashing together would make sense if the
> uevent were just updating a device attribute list. Previously when we
> had just a single kind of uevent, that would not have made a
> difference, but if we gain different kinds of uevents like here, it
> starts to matter.
> 
> However, Paul came to the conclusion that we will be ok as long as the
> events come via netlink.

Yes, basically netlink is fine and uevent file polling is not. If the
application is too slow to service new udev devices (events), I'm
pretty sure they get queued if they come from netlink. It's only when
not using netlink with udev (not sure when that really happens, and the
info doesn't seem to be exposed to the application) that the latest
contents are read from the uevent file.

The way I see it, we should put the assumption that userspace will get
all our events or just figure it out on its own with the epoch counter.
It's a notification mechanism, and I think we should count on the fact
that userspace can reliably get notified that way (not to say it has to
be the only way, the epoch counter can provide a polling-ish
alternative).

Cheers and thanks for the recap,

Paul
Hi,

On Tue, 2019-05-14 at 13:09 +0200, Daniel Vetter wrote:
> On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hey,
> > 
> > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit :
> > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > property.
> > > > > > > 
> > > > > > > This uevent will have following details related to the status change:
> > > > > > > 
> > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > > 
> > > > > > > Need ACK from this uevent from userspace consumer.
> > > > > > 
> > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > issue and came up with similar ideas:
> > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > > 
> > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > point is that we need to cover different cases:
> > > > > > - one or more properties changed;
> > > > > > - the connector status changed;
> > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > > 
> > > > > > For the first case, we can send out:
> > > > > > HOTPLUG=1
> > > > > > CONNECTOR=<id>
> > > > > > PROPERTY=<id>
> > > > > > 
> > > > > > and no reprobe is required.
> > > > > > 
> > > > > > For the second one, something like:
> > > > > > HOTPLUG=1
> > > > > > CONNECTOR=<id>
> > > > > > STATUS=Connected/Disconnected
> > > > > > 
> > > > > > and a connector probe is needed for connected, but not for
> > > > > > disconnected;
> > > > > > 
> > > > > > For the third one, we can only indicate the connector:
> > > > > > HOTPLUG=1
> > > > > > CONNECTOR=<id>
> > > > > > 
> > > > > > and a reprobe of the connector is always needed
> > > > > 
> > > > > There's no material difference between this one and the previous one.
> > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > > 
> > > > That's the idea, but we need to handle status changes differently than
> > > > properties, since as far as I know, connected/unconnected status is not
> > > > exposed as a prop for the connector.
> > > 
> > > Oops, totally missed that. "Everything is a property" is kinda
> > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > into a property. Or another excuse why we should expose the epoch
> > > property :-)
> > 
> > Well I think it would make sense anyway, as long as we can make sure it
> > stays consistent with the one reported in the connector struct.
> > 
> > > > > Here's why:
> > > > > - A side effect of forcing a probe on a connector is that you get to
> > > > > read all the properties, so supplying them is kinda pointless.
> > > > 
> > > > Agreed, except for the status case where it's useful to know it's a
> > > > disconnect, because we don't need any probe step in that case.
> > > > 
> > > > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > > > reasonable unfortunately, but oh well.
> > > > 
> > > > How would that be retreived then? From the looks of it, that's a
> > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > > > does the full reprobe.
> > > 
> > > drmGetConnector vs drmGetConnectorCurrent.
> > 
> > Ah right, forgot about that one, thanks.
> > 
> > > > Not sure what issues could arise in case of disconnect without reprobe
> > > > -- at least I don't see why userspace should have to do anything in
> > > > particular except no longer using the connector, even in complex DP MST
> > > > cases.
> > > 
> > > connector->status might be a lie without a full reprobe, and wrongly
> > > indicate that the connector is disconnected while there's still
> > > something plugged in. I'm not sure we've fixed those bugs by now
> > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> > > connected, and we can't break this because every intel platform ever
> > > shipped has a few devices where this is somehow broken, irrespective
> > > of the sink).
> > 
> > Mhh either way, I think it's up to the driver to report that and make
> > it consistent. I think we have poll helpers to make up for cases where
> > hotplug is not available too. So I'm not sure why a full reprobe would
> > be needed: drivers just need to do the right thing.
> > 
> > > > > - There's no way to only reprobe status, you can only ever reprobe
> > > > > everything with the current ioctl and implementations. Having an
> > > > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > > > almost all cases).
> > > > 
> > > > Agreed.
> > > > 
> > > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > > > needs to reprobe this connector.
> > > > 
> > > > I thought we could access the props alone, which avoids doing a reprobe
> > > > when the kernel knows that only a prop or a set of props changed and do
> > > > not require a full reprobe. That's the first case I was mentionning.
> > > > 
> > > > > At that point we need to figure out whether this is a good uapi or
> > > > > not, and that's where the epoch comes in. There's two reasons for an
> > > > > epoch:
> > > > > - We need it internally because I'm not goinig to wire a new return
> > > > > value through hundreds of connector probe functions. It's much easier
> > > > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > > > similar functions that update probe state.
> > > > 
> > > > I don't think I'm following what issue this is trying to solve
> > > > internally.
> > > 
> > > So I'm assuming that if we handle a hotplug, we only want to generate
> > > one uevent for that, not one for every little thing that changed.
> > > There's two ways to implement this logic:
> > > - With some epoch counter and a helper function you can call everytime
> > > something changed (e.g. status, or edid, or anything else we care
> > > about e.g. from dp aux). This won't need much (if any) driver changes,
> > > because we can just put these into the relevant helper/core functions
> > > (like edid update, or dp aux reading or whatever).
> > > - Wiring a new return value through the entire stack (and _all_ the
> > > kms drivers) so that the probe helpers could aggregate this like they
> > > currently do.
> > > 
> > > One of these is a lot less typing.
> > 
> > Oh I had missed this issue. Yeah of course if we start reporting
> > property changes, a hotplug will be lots of such changes.
> > 
> > So an epoch counter property would indeed also solve the reprobing
> > problem. But I think it would be nice to keep the ability to be
> > notified of what changed precisely via uevent. I'm not really buying
> > the "missing uevent" thing so much and I think we can reasonably expect
> > that it will be useful. Events could be aggregated (which the epoch
> > counter would probably also allow) and sent out altogether when the
> > connector status changes (along with the status information). I think
> > we're under-using uevent currently, and feel like this should be fixed
> > regardless of the full reprobe issue.
> 
> I see two options:
> 
> 1) kernel aggregates uevents a bit, and sends out one (per connector
> that changed) indicating that sink related state changed. Userspace
> listens to that, and does a drmGetConnector as a result to update
> itself. Most of this code needs to exist anyway.
>
> 2) kernel sends out updates as we go, userspace reassembles everything
> again (and not really an idea when all the updates are in, see Lyude's
> question. Plus userspace still needs to have the drmGetConnector path,
> at least for initial setup.
> 
> I don't see why 2) is any better than 1), and it has some clear downsides.

My main point is that when the kernel knows some individual property
changed, it should update its internal state and report what prop
changed *in cases that don't require a full reprobe* and report only
which connector changed when a connector reprobe is needed anyway.

Maybe we could even have quirks for drivers to indicate that common
actions that shouldn't require a reprobe actually do for this driver in
particular, because of whatever instability we want to be confident
about handling. I believe this should be abstracted away in DRM and not
reflected on the userspace API.

So it's not just about providing per-property updates, the updates
reported this way have to be "standalone" and never imply that anything
else about the connector's state could have change. Driver's guarantee.

> > With that, I agree that a global epoch counter from the connector would
> > be a good quick way for userspace to tell if a connector changed or not
> > since the last time it checked.
> > 
> > > > > - If userspace misses an event and there's no epoch, we're forcing
> > > > > userspace to reprobe everything. Use case would be if a compositor is
> > > > > switched away we probably don't want to piss of the current compositor
> > > > > by blocking it's own probe kernel calls by doing our own (probe is
> > > > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > > > it can read the epoch property (which it can do without forcing a
> > > > > reprobe) userspace would know which connectors it needs to check and
> > > > > reprobe.
> > > > > 
> > > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > > > also require that userspace needs to keep parsing all uevents and make
> > > > > a list of all connectors it needs to reprobe when it's back to being
> > > > > the active compositor. But just comparing a current epoch with the one
> > > > > you cached from the last full probe is much easier.
> > > > 
> > > > Fair enough, I think it's a fine idea for robustness yes, but I think
> > > > we could also provide extra info in the uevent when relevant and not
> > > > rely on that entirely.
> > > 
> > > See above, with drmGetConnectorCurrent there's no need to provide more
> > > than what's needed in the uevent, since userspace can get everything
> > > else at the cost of one ioctl, without reprobing. With a bit of
> > > engineering work we could even avoid taking the expensive
> > > dev->mode_config.mutex lock for this fastpath.
> > > 
> > > > > Another thing: None of this we can for connectors with unreliable hdp.
> > > > > Or at least you'll piss of users if you cache always. The sad thing is
> > > > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > > > need to reprobe when the user asks for it. igt can probably get away
> > > > > without reprobing.
> > > > 
> > > > I wonder how that is handled currently and how a user action can solve
> > > > the issue without any notification from the kernel. Maybe a need a
> > > > better understanding of that case to have a clearer idea.
> > > 
> > > User opens the screen configuration tool -> usually at that point the
> > > tool/compositor force a full reprobe, which then often triggers the
> > > automatic reconfiguring. E.g. on one laptop I have here when I plug in
> > > random shit projectors at conferences nothing happens, until I run
> > > xrandr, which triggers the full reprobe, which then makes the kernel
> > > realize something change, sending and uevent, which starts the
> > > automatic reconfigure machinery.
> > 
> > Oh right hehe, I definitely do that blind alt+f2 gnome-control-center
> > to get me out of an off-panel situation much too often.
> > 
> > > There's also the issue that there's machines with hpd storms (even on
> > > DP, where you really need hpd to work to be compliant), and we have to
> > > turn of the hpd irq to keep the machine useable.
> > 
> > I was under the impression that we switch to polling when a hpd storm
> > is detected in i915 (but that's a vague memory from my summer
> > internship at Intel 2 years ago).
> 
> We do poll, but the issue is still that polling doesn't do the same
> thing as full reprobe. One just calls ->detect, the other ->detect +
> ->get_modes. This is a bit a silliness of the helpers and source of
> lots of confusion. A possible fix might be to always call both.

I think that would make a lot of sense. I don't really get why we have
to wait for userspace to do a reprobe to get the new modes when the
kernel can be absolutely sure that the modes changed and need to be
refreshed.

> Plus even when that mess is sorted there's still the issue of broken
> hw, and we have no idea how much/where/which exactly. Except that
> every time we relied on hpd status, we got regression reports and had
> to revert.

I think we could configure the notification behavior per-driver and
some events that wouldn't require a full probe on some drivers could do
so on other drivers. Userspace should find out whether to reprobe or
not dynamically based on what's in the uevent anyway, so it's not even
an inconsistency in the interface that 2 events be reported differently
in 2 drivers. I think that'd be better than the current situation we're
in anyway. If some drivers want be paranoid and always ask for
a reprobe of the connectors because of unreliable hw, their choice.

Cheers,

Paul

> -Daniel
> 
> > Cheers,
> > 
> > Paul
> > 
> > > Cheers, Daniel
> > > 
> > > > Cheers,
> > > > 
> > > > Paul
> > > > 
> > > > > -Daniel
> > > > > 
> > > > > > Then we still have the legacy case:
> > > > > > HOTPLUG=1
> > > > > > 
> > > > > > where userspace is expected to reprobe all the connectors.
> > > > > > 
> > > > > > I think this would deserve to be a separate series on its own. So I am
> > > > > > proposing to take this one off your plate and come up with another
> > > > > > seres implementing this proposal. What do you think?
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > Paul
> > > > > > 
> > > > > > > v2:
> > > > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > > > v3:
> > > > > > >   Check the property is really attached with connector [Daniel]
> > > > > > > 
> > > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > @@ -21,6 +21,7 @@
> > > > > > >  #include <drm/drm_sysfs.h>
> > > > > > >  #include <drm/drmP.h>
> > > > > > >  #include "drm_internal.h"
> > > > > > > +#include "drm_crtc_internal.h"
> > > > > > > 
> > > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > > > >   * deal with other types of events.
> > > > > > > + *
> > > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > > > + * for uevents on connector status change.
> > > > > > >   */
> > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > >  {
> > > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > >  }
> > > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > > > 
> > > > > > > +/**
> > > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > > > + * property status change
> > > > > > > + * @connector: connector on which property status changed
> > > > > > > + * @property: connector property whoes status changed.
> > > > > > > + *
> > > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > > > + * related to the status change.
> > > > > > > + */
> > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > +                                   struct drm_property *property)
> > > > > > > +{
> > > > > > > +     struct drm_device *dev = connector->dev;
> > > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > > > +
> > > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > > > +                                        property->base.id));
> > > > > > > +
> > > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > > > +              "PROPERTY=%u", property->base.id);
> > > > > > > +
> > > > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > > > +
> > > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > > > +}
> > > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > > > +
> > > > > > >  static void drm_sysfs_release(struct device *dev)
> > > > > > >  {
> > > > > > >       kfree(dev);
> > > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > > > --- a/include/drm/drm_sysfs.h
> > > > > > > +++ b/include/drm/drm_sysfs.h
> > > > > > > @@ -4,10 +4,13 @@
> > > > > > > 
> > > > > > >  struct drm_device;
> > > > > > >  struct device;
> > > > > > > +struct drm_connector;
> > > > > > > +struct drm_property;
> > > > > > > 
> > > > > > >  int drm_class_device_register(struct device *dev);
> > > > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > > > 
> > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > > > -
> > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > +                                   struct drm_property *property);
> > > > > > >  #endif
> > > > > > --
> > > > > > Paul Kocialkowski, Bootlin
> > > > > > Embedded Linux and kernel engineering
> > > > > > https://bootlin.com
> > > > > > 
> > > > --
> > > > Paul Kocialkowski, Bootlin
> > > > Embedded Linux and kernel engineering
> > > > https://bootlin.com
> > > > 
> 
>
On Tue, May 14, 2019 at 4:13 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Tue, 2019-05-14 at 13:09 +0200, Daniel Vetter wrote:
> > On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hey,
> > >
> > > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit :
> > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > > property.
> > > > > > > >
> > > > > > > > This uevent will have following details related to the status change:
> > > > > > > >
> > > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > > >
> > > > > > > > Need ACK from this uevent from userspace consumer.
> > > > > > >
> > > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > > issue and came up with similar ideas:
> > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > > >
> > > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > > point is that we need to cover different cases:
> > > > > > > - one or more properties changed;
> > > > > > > - the connector status changed;
> > > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > > >
> > > > > > > For the first case, we can send out:
> > > > > > > HOTPLUG=1
> > > > > > > CONNECTOR=<id>
> > > > > > > PROPERTY=<id>
> > > > > > >
> > > > > > > and no reprobe is required.
> > > > > > >
> > > > > > > For the second one, something like:
> > > > > > > HOTPLUG=1
> > > > > > > CONNECTOR=<id>
> > > > > > > STATUS=Connected/Disconnected
> > > > > > >
> > > > > > > and a connector probe is needed for connected, but not for
> > > > > > > disconnected;
> > > > > > >
> > > > > > > For the third one, we can only indicate the connector:
> > > > > > > HOTPLUG=1
> > > > > > > CONNECTOR=<id>
> > > > > > >
> > > > > > > and a reprobe of the connector is always needed
> > > > > >
> > > > > > There's no material difference between this one and the previous one.
> > > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > > >
> > > > > That's the idea, but we need to handle status changes differently than
> > > > > properties, since as far as I know, connected/unconnected status is not
> > > > > exposed as a prop for the connector.
> > > >
> > > > Oops, totally missed that. "Everything is a property" is kinda
> > > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > > into a property. Or another excuse why we should expose the epoch
> > > > property :-)
> > >
> > > Well I think it would make sense anyway, as long as we can make sure it
> > > stays consistent with the one reported in the connector struct.
> > >
> > > > > > Here's why:
> > > > > > - A side effect of forcing a probe on a connector is that you get to
> > > > > > read all the properties, so supplying them is kinda pointless.
> > > > >
> > > > > Agreed, except for the status case where it's useful to know it's a
> > > > > disconnect, because we don't need any probe step in that case.
> > > > >
> > > > > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > > > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > > > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > > > > reasonable unfortunately, but oh well.
> > > > >
> > > > > How would that be retreived then? From the looks of it, that's a
> > > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > > > > does the full reprobe.
> > > >
> > > > drmGetConnector vs drmGetConnectorCurrent.
> > >
> > > Ah right, forgot about that one, thanks.
> > >
> > > > > Not sure what issues could arise in case of disconnect without reprobe
> > > > > -- at least I don't see why userspace should have to do anything in
> > > > > particular except no longer using the connector, even in complex DP MST
> > > > > cases.
> > > >
> > > > connector->status might be a lie without a full reprobe, and wrongly
> > > > indicate that the connector is disconnected while there's still
> > > > something plugged in. I'm not sure we've fixed those bugs by now
> > > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> > > > connected, and we can't break this because every intel platform ever
> > > > shipped has a few devices where this is somehow broken, irrespective
> > > > of the sink).
> > >
> > > Mhh either way, I think it's up to the driver to report that and make
> > > it consistent. I think we have poll helpers to make up for cases where
> > > hotplug is not available too. So I'm not sure why a full reprobe would
> > > be needed: drivers just need to do the right thing.
> > >
> > > > > > - There's no way to only reprobe status, you can only ever reprobe
> > > > > > everything with the current ioctl and implementations. Having an
> > > > > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > > > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > > > > almost all cases).
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > > > > needs to reprobe this connector.
> > > > >
> > > > > I thought we could access the props alone, which avoids doing a reprobe
> > > > > when the kernel knows that only a prop or a set of props changed and do
> > > > > not require a full reprobe. That's the first case I was mentionning.
> > > > >
> > > > > > At that point we need to figure out whether this is a good uapi or
> > > > > > not, and that's where the epoch comes in. There's two reasons for an
> > > > > > epoch:
> > > > > > - We need it internally because I'm not goinig to wire a new return
> > > > > > value through hundreds of connector probe functions. It's much easier
> > > > > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > > > > similar functions that update probe state.
> > > > >
> > > > > I don't think I'm following what issue this is trying to solve
> > > > > internally.
> > > >
> > > > So I'm assuming that if we handle a hotplug, we only want to generate
> > > > one uevent for that, not one for every little thing that changed.
> > > > There's two ways to implement this logic:
> > > > - With some epoch counter and a helper function you can call everytime
> > > > something changed (e.g. status, or edid, or anything else we care
> > > > about e.g. from dp aux). This won't need much (if any) driver changes,
> > > > because we can just put these into the relevant helper/core functions
> > > > (like edid update, or dp aux reading or whatever).
> > > > - Wiring a new return value through the entire stack (and _all_ the
> > > > kms drivers) so that the probe helpers could aggregate this like they
> > > > currently do.
> > > >
> > > > One of these is a lot less typing.
> > >
> > > Oh I had missed this issue. Yeah of course if we start reporting
> > > property changes, a hotplug will be lots of such changes.
> > >
> > > So an epoch counter property would indeed also solve the reprobing
> > > problem. But I think it would be nice to keep the ability to be
> > > notified of what changed precisely via uevent. I'm not really buying
> > > the "missing uevent" thing so much and I think we can reasonably expect
> > > that it will be useful. Events could be aggregated (which the epoch
> > > counter would probably also allow) and sent out altogether when the
> > > connector status changes (along with the status information). I think
> > > we're under-using uevent currently, and feel like this should be fixed
> > > regardless of the full reprobe issue.
> >
> > I see two options:
> >
> > 1) kernel aggregates uevents a bit, and sends out one (per connector
> > that changed) indicating that sink related state changed. Userspace
> > listens to that, and does a drmGetConnector as a result to update
> > itself. Most of this code needs to exist anyway.
> >
> > 2) kernel sends out updates as we go, userspace reassembles everything
> > again (and not really an idea when all the updates are in, see Lyude's
> > question. Plus userspace still needs to have the drmGetConnector path,
> > at least for initial setup.
> >
> > I don't see why 2) is any better than 1), and it has some clear downsides.
>
> My main point is that when the kernel knows some individual property
> changed, it should update its internal state and report what prop
> changed *in cases that don't require a full reprobe* and report only
> which connector changed when a connector reprobe is needed anyway.
>
> Maybe we could even have quirks for drivers to indicate that common
> actions that shouldn't require a reprobe actually do for this driver in
> particular, because of whatever instability we want to be confident
> about handling. I believe this should be abstracted away in DRM and not
> reflected on the userspace API.
>
> So it's not just about providing per-property updates, the updates
> reported this way have to be "standalone" and never imply that anything
> else about the connector's state could have change. Driver's guarantee.

I'm not sure what that guarantee buys us. You can never assume that if
you get this event that only that property changed, since other stuff
might have changed meanwhile.
And especially for a sink change we know that a lot of properties
(including stuff like connector->status here that's not yet a
property) will have changed. And event with e.g. PROPERTY=epoch would
simply indicate that all the sink related things have been updated,
and you can get them with drmGetConnectorCurrent.

We also need some way to indicate that an entire batch of updates have
completed if we send out events for every part of this. Sending out
bigger events neatly sidesteps that issue.

> > > With that, I agree that a global epoch counter from the connector would
> > > be a good quick way for userspace to tell if a connector changed or not
> > > since the last time it checked.
> > >
> > > > > > - If userspace misses an event and there's no epoch, we're forcing
> > > > > > userspace to reprobe everything. Use case would be if a compositor is
> > > > > > switched away we probably don't want to piss of the current compositor
> > > > > > by blocking it's own probe kernel calls by doing our own (probe is
> > > > > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > > > > it can read the epoch property (which it can do without forcing a
> > > > > > reprobe) userspace would know which connectors it needs to check and
> > > > > > reprobe.
> > > > > >
> > > > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > > > > also require that userspace needs to keep parsing all uevents and make
> > > > > > a list of all connectors it needs to reprobe when it's back to being
> > > > > > the active compositor. But just comparing a current epoch with the one
> > > > > > you cached from the last full probe is much easier.
> > > > >
> > > > > Fair enough, I think it's a fine idea for robustness yes, but I think
> > > > > we could also provide extra info in the uevent when relevant and not
> > > > > rely on that entirely.
> > > >
> > > > See above, with drmGetConnectorCurrent there's no need to provide more
> > > > than what's needed in the uevent, since userspace can get everything
> > > > else at the cost of one ioctl, without reprobing. With a bit of
> > > > engineering work we could even avoid taking the expensive
> > > > dev->mode_config.mutex lock for this fastpath.
> > > >
> > > > > > Another thing: None of this we can for connectors with unreliable hdp.
> > > > > > Or at least you'll piss of users if you cache always. The sad thing is
> > > > > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > > > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > > > > need to reprobe when the user asks for it. igt can probably get away
> > > > > > without reprobing.
> > > > >
> > > > > I wonder how that is handled currently and how a user action can solve
> > > > > the issue without any notification from the kernel. Maybe a need a
> > > > > better understanding of that case to have a clearer idea.
> > > >
> > > > User opens the screen configuration tool -> usually at that point the
> > > > tool/compositor force a full reprobe, which then often triggers the
> > > > automatic reconfiguring. E.g. on one laptop I have here when I plug in
> > > > random shit projectors at conferences nothing happens, until I run
> > > > xrandr, which triggers the full reprobe, which then makes the kernel
> > > > realize something change, sending and uevent, which starts the
> > > > automatic reconfigure machinery.
> > >
> > > Oh right hehe, I definitely do that blind alt+f2 gnome-control-center
> > > to get me out of an off-panel situation much too often.
> > >
> > > > There's also the issue that there's machines with hpd storms (even on
> > > > DP, where you really need hpd to work to be compliant), and we have to
> > > > turn of the hpd irq to keep the machine useable.
> > >
> > > I was under the impression that we switch to polling when a hpd storm
> > > is detected in i915 (but that's a vague memory from my summer
> > > internship at Intel 2 years ago).
> >
> > We do poll, but the issue is still that polling doesn't do the same
> > thing as full reprobe. One just calls ->detect, the other ->detect +
> > ->get_modes. This is a bit a silliness of the helpers and source of
> > lots of confusion. A possible fix might be to always call both.
>
> I think that would make a lot of sense. I don't really get why we have
> to wait for userspace to do a reprobe to get the new modes when the
> kernel can be absolutely sure that the modes changed and need to be
> refreshed.

Don't let the names trick you, it's an entirely arbitrary split,
historically grown :-)

> > Plus even when that mess is sorted there's still the issue of broken
> > hw, and we have no idea how much/where/which exactly. Except that
> > every time we relied on hpd status, we got regression reports and had
> > to revert.
>
> I think we could configure the notification behavior per-driver and
> some events that wouldn't require a full probe on some drivers could do
> so on other drivers. Userspace should find out whether to reprobe or
> not dynamically based on what's in the uevent anyway, so it's not even
> an inconsistency in the interface that 2 events be reported differently
> in 2 drivers. I think that'd be better than the current situation we're
> in anyway. If some drivers want be paranoid and always ask for
> a reprobe of the connectors because of unreliable hw, their choice.

The problem isn't typing the code, it's making sure we don't break the
world with this. Even if you limit this to i915 alone. That's why I'm
suggesting we untangle things as much as possible, makes it easier to
do the (pretty much inevitable) revert.
-Daniel

> Cheers,
>
> Paul
>
> > -Daniel
> >
> > > Cheers,
> > >
> > > Paul
> > >
> > > > Cheers, Daniel
> > > >
> > > > > Cheers,
> > > > >
> > > > > Paul
> > > > >
> > > > > > -Daniel
> > > > > >
> > > > > > > Then we still have the legacy case:
> > > > > > > HOTPLUG=1
> > > > > > >
> > > > > > > where userspace is expected to reprobe all the connectors.
> > > > > > >
> > > > > > > I think this would deserve to be a separate series on its own. So I am
> > > > > > > proposing to take this one off your plate and come up with another
> > > > > > > seres implementing this proposal. What do you think?
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Paul
> > > > > > >
> > > > > > > > v2:
> > > > > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > > > > v3:
> > > > > > > >   Check the property is really attached with connector [Daniel]
> > > > > > > >
> > > > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > >  #include <drm/drm_sysfs.h>
> > > > > > > >  #include <drm/drmP.h>
> > > > > > > >  #include "drm_internal.h"
> > > > > > > > +#include "drm_crtc_internal.h"
> > > > > > > >
> > > > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > > > > >   * deal with other types of events.
> > > > > > > > + *
> > > > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > > > > + * for uevents on connector status change.
> > > > > > > >   */
> > > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > > >  {
> > > > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > > >  }
> > > > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > > > >
> > > > > > > > +/**
> > > > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > > > > + * property status change
> > > > > > > > + * @connector: connector on which property status changed
> > > > > > > > + * @property: connector property whoes status changed.
> > > > > > > > + *
> > > > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > > > > + * related to the status change.
> > > > > > > > + */
> > > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > > +                                   struct drm_property *property)
> > > > > > > > +{
> > > > > > > > +     struct drm_device *dev = connector->dev;
> > > > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > > > > +
> > > > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > > > > +                                        property->base.id));
> > > > > > > > +
> > > > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > > > > +              "PROPERTY=%u", property->base.id);
> > > > > > > > +
> > > > > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > > > > +
> > > > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > > > > +}
> > > > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > > > > +
> > > > > > > >  static void drm_sysfs_release(struct device *dev)
> > > > > > > >  {
> > > > > > > >       kfree(dev);
> > > > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > > > > --- a/include/drm/drm_sysfs.h
> > > > > > > > +++ b/include/drm/drm_sysfs.h
> > > > > > > > @@ -4,10 +4,13 @@
> > > > > > > >
> > > > > > > >  struct drm_device;
> > > > > > > >  struct device;
> > > > > > > > +struct drm_connector;
> > > > > > > > +struct drm_property;
> > > > > > > >
> > > > > > > >  int drm_class_device_register(struct device *dev);
> > > > > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > > > >
> > > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > > > > -
> > > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > > +                                   struct drm_property *property);
> > > > > > > >  #endif
> > > > > > > --
> > > > > > > Paul Kocialkowski, Bootlin
> > > > > > > Embedded Linux and kernel engineering
> > > > > > > https://bootlin.com
> > > > > > >
> > > > > --
> > > > > Paul Kocialkowski, Bootlin
> > > > > Embedded Linux and kernel engineering
> > > > > https://bootlin.com
> > > > >
> >
> >
> --
> Paul Kocialkowski, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
>
On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Tue, 14 May 2019 13:02:09 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:
> > >
> > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:
> > > > On Mon, 13 May 2019 11:34:58 +0200
> > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > >
> > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > > > property.
> > > > > > > > >
> > > > > > > > > This uevent will have following details related to the status change:
> > > > > > > > >
> > > > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > > > >
> > > > > > > > > Need ACK from this uevent from userspace consumer.
> > > > > > > >
> > > > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > > > issue and came up with similar ideas:
> > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > > > >
> > > > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > > > point is that we need to cover different cases:
> > > > > > > > - one or more properties changed;
> > > > > > > > - the connector status changed;
> > > > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > > > >
> > > > > > > > For the first case, we can send out:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > PROPERTY=<id>
> > > > > > > >
> > > > > > > > and no reprobe is required.
> > > > > > > >
> > > > > > > > For the second one, something like:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > STATUS=Connected/Disconnected
> > > > > > > >
> > > > > > > > and a connector probe is needed for connected, but not for
> > > > > > > > disconnected;
> > > > > > > >
> > > > > > > > For the third one, we can only indicate the connector:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > >
> > > > > > > > and a reprobe of the connector is always needed
> > > > > > >
> > > > > > > There's no material difference between this one and the previous one.
> > > > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > > > >
> > > > > > That's the idea, but we need to handle status changes differently than
> > > > > > properties, since as far as I know, connected/unconnected status is not
> > > > > > exposed as a prop for the connector.
> > > > >
> > > > > Oops, totally missed that. "Everything is a property" is kinda
> > > > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > > > into a property. Or another excuse why we should expose the epoch
> > > > > property :-)
> > > >
> > > > Hi Daniel,
> > > >
> > > > just to clarify the first case, specific to one very particular
> > > > property:
> > > >
> > > > With HDCP, there is a property that may change dynamically at runtime
> > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > when it changes, I do not want userspace have to poll that property
> > > > with a timer.
> > > >
> > > > When that property alone changes, and userspace is prepared to handle
> > > > that property changing alone, it must not trigger a reprobe of the
> > > > connector. There is no reason to reprobe at that point AFAIU.
> > > >
> > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > epoch approach or with any alternate uevent design?
> > > >
> > > > We need an event to userspace that indicates that re-reading the
> > > > properties is enough and reprobe of the connector is not necessary.
> > > > This is complementary to indicating to userspace that only some
> > > > connectors need to be reprobed instead of everything.
> > >
> > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > reprobing. Would that work?
>
> Hi,
>
> yes, that would work, if it was acceptable to DRM upstream. The replies
> to Paul seemed to be going south so fast that I thought we wouldn't get
> any new uevent fields in favour of "epoch counters".
>
> > Yes that's the idea, depending upon which property you get you know
> > it's a sink change (needs full reprobe) or something else like hdcp
> > state machinery update.
>
> Right.
>
> > Wrt avoiding the full reprobe for sink changes: I think we should
> > indeed decouple that from the per-connector event for sink changes.
> > That along is a good win already, since you know for which connector
> > you need to call drmGetConnector (which forces the reprobe). It would
> > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > historically speaking every time we tried to rely on this we ended up
> > regretting things.
>
> What changed? This sounds very much what Paul suggested. Looking at it
> from userspace side:

This sounds solid, some refinements below:

> HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
>
> - If yy is "Content Protection", no need to drmModeGetConnector(), just
>   re-get the connector properties.
>
> - Kernel probably shouldn't bother sending this for properties where
>   re-probe could be necessary, and send the below instead.


I think we should assert that the kernel can get the new property
values using drmModeGetConnectorCurrent for this case, i.e. the kernel
does not expect a full reprobe. I.e. upgrade your idea from "should"
to "must"

Furthermore different property can indicate different kind of updates,
e.g. hdcp vs general sink change vs. whatever else might come in the
future.

> HOTPLUG=1 CONNECTOR=xx
>
> - Needs to drmModeGetConnector() on the one connector, no need to probe
>   others. Implies that one needs to re-get the connector properties as
>   well.

Sounds good.

> HOTPLUG=1
>
> - Need to do drmModeGetResouces() to discover new/disappeared
>   connectors, and need to drmModeGetConnector to re-probe every
>   connector. (As always.)

Maybe we should clarify that this is also what you get when an entire
connector appears/disappears (for dp mst hotplug).

Maybe we could make an additional rule that if a connector has the
EPOCH property, then it does _not_ need to be reprobe for the global
events. For that case userspace should only check whether there's
new/removed connectors, and then probe the new ones (and disable the
removed ones as needed). We can also use some other flag to indicate
this if we don't add the epoch proprty.

> That should be also backwards-compatible: any userspace that doesn't
> understand CONNECTOR will see HOTPLUG=1 and re-probe everything. Any
> userspace that doesn't understand PROPERTY or the property it refers to
> will fall back to probing either the connector or everything.

Agreed, that should work.

> I would be happy to get that behaviour into Weston, particularly as the
> HDCP feature is brewing for Weston too.
>
> --------
>
> When discussing this in IRC, I had the concern about how uevents are
> delivered in userspace. Is there a possibility that they might be
> overwritten, contain stale attributes, or get squashed together?
>
> Particularly if a display server is current on the VT and active and
> monitoring udev, but stuck doing something and cannot service uevents
> very fast, and the kernel sends more than one event before the process
> gets back to dispatching. The terminology in libudev API confused me as
> an event is a device. Squashing together would make sense if the
> uevent were just updating a device attribute list. Previously when we
> had just a single kind of uevent, that would not have made a
> difference, but if we gain different kinds of uevents like here, it
> starts to matter.
>
> However, Paul came to the conclusion that we will be ok as long as the
> events come via netlink.

Yeah netlink shouldn't drop events on the floor I think. It might
still happen, but then I think you should get an indication of that
error, and you just treat it as a general hotplug event like on older
kernels.
-Daniel

Hi,

On Tue, 2019-05-14 at 16:28 +0200, Daniel Vetter wrote:
> On Tue, May 14, 2019 at 4:13 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Tue, 2019-05-14 at 13:09 +0200, Daniel Vetter wrote:
> > > On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hey,
> > > > 
> > > > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit :
> > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > > > property.
> > > > > > > > > 
> > > > > > > > > This uevent will have following details related to the status change:
> > > > > > > > > 
> > > > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > > > > 
> > > > > > > > > Need ACK from this uevent from userspace consumer.
> > > > > > > > 
> > > > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > > > issue and came up with similar ideas:
> > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > > > > 
> > > > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > > > point is that we need to cover different cases:
> > > > > > > > - one or more properties changed;
> > > > > > > > - the connector status changed;
> > > > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > > > > 
> > > > > > > > For the first case, we can send out:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > PROPERTY=<id>
> > > > > > > > 
> > > > > > > > and no reprobe is required.
> > > > > > > > 
> > > > > > > > For the second one, something like:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > STATUS=Connected/Disconnected
> > > > > > > > 
> > > > > > > > and a connector probe is needed for connected, but not for
> > > > > > > > disconnected;
> > > > > > > > 
> > > > > > > > For the third one, we can only indicate the connector:
> > > > > > > > HOTPLUG=1
> > > > > > > > CONNECTOR=<id>
> > > > > > > > 
> > > > > > > > and a reprobe of the connector is always needed
> > > > > > > 
> > > > > > > There's no material difference between this one and the previous one.
> > > > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > > > > 
> > > > > > That's the idea, but we need to handle status changes differently than
> > > > > > properties, since as far as I know, connected/unconnected status is not
> > > > > > exposed as a prop for the connector.
> > > > > 
> > > > > Oops, totally missed that. "Everything is a property" is kinda
> > > > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > > > into a property. Or another excuse why we should expose the epoch
> > > > > property :-)
> > > > 
> > > > Well I think it would make sense anyway, as long as we can make sure it
> > > > stays consistent with the one reported in the connector struct.
> > > > 
> > > > > > > Here's why:
> > > > > > > - A side effect of forcing a probe on a connector is that you get to
> > > > > > > read all the properties, so supplying them is kinda pointless.
> > > > > > 
> > > > > > Agreed, except for the status case where it's useful to know it's a
> > > > > > disconnect, because we don't need any probe step in that case.
> > > > > > 
> > > > > > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > > > > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > > > > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > > > > > reasonable unfortunately, but oh well.
> > > > > > 
> > > > > > How would that be retreived then? From the looks of it, that's a
> > > > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > > > > > does the full reprobe.
> > > > > 
> > > > > drmGetConnector vs drmGetConnectorCurrent.
> > > > 
> > > > Ah right, forgot about that one, thanks.
> > > > 
> > > > > > Not sure what issues could arise in case of disconnect without reprobe
> > > > > > -- at least I don't see why userspace should have to do anything in
> > > > > > particular except no longer using the connector, even in complex DP MST
> > > > > > cases.
> > > > > 
> > > > > connector->status might be a lie without a full reprobe, and wrongly
> > > > > indicate that the connector is disconnected while there's still
> > > > > something plugged in. I'm not sure we've fixed those bugs by now
> > > > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> > > > > connected, and we can't break this because every intel platform ever
> > > > > shipped has a few devices where this is somehow broken, irrespective
> > > > > of the sink).
> > > > 
> > > > Mhh either way, I think it's up to the driver to report that and make
> > > > it consistent. I think we have poll helpers to make up for cases where
> > > > hotplug is not available too. So I'm not sure why a full reprobe would
> > > > be needed: drivers just need to do the right thing.
> > > > 
> > > > > > > - There's no way to only reprobe status, you can only ever reprobe
> > > > > > > everything with the current ioctl and implementations. Having an
> > > > > > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > > > > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > > > > > almost all cases).
> > > > > > 
> > > > > > Agreed.
> > > > > > 
> > > > > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > > > > > needs to reprobe this connector.
> > > > > > 
> > > > > > I thought we could access the props alone, which avoids doing a reprobe
> > > > > > when the kernel knows that only a prop or a set of props changed and do
> > > > > > not require a full reprobe. That's the first case I was mentionning.
> > > > > > 
> > > > > > > At that point we need to figure out whether this is a good uapi or
> > > > > > > not, and that's where the epoch comes in. There's two reasons for an
> > > > > > > epoch:
> > > > > > > - We need it internally because I'm not goinig to wire a new return
> > > > > > > value through hundreds of connector probe functions. It's much easier
> > > > > > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > > > > > similar functions that update probe state.
> > > > > > 
> > > > > > I don't think I'm following what issue this is trying to solve
> > > > > > internally.
> > > > > 
> > > > > So I'm assuming that if we handle a hotplug, we only want to generate
> > > > > one uevent for that, not one for every little thing that changed.
> > > > > There's two ways to implement this logic:
> > > > > - With some epoch counter and a helper function you can call everytime
> > > > > something changed (e.g. status, or edid, or anything else we care
> > > > > about e.g. from dp aux). This won't need much (if any) driver changes,
> > > > > because we can just put these into the relevant helper/core functions
> > > > > (like edid update, or dp aux reading or whatever).
> > > > > - Wiring a new return value through the entire stack (and _all_ the
> > > > > kms drivers) so that the probe helpers could aggregate this like they
> > > > > currently do.
> > > > > 
> > > > > One of these is a lot less typing.
> > > > 
> > > > Oh I had missed this issue. Yeah of course if we start reporting
> > > > property changes, a hotplug will be lots of such changes.
> > > > 
> > > > So an epoch counter property would indeed also solve the reprobing
> > > > problem. But I think it would be nice to keep the ability to be
> > > > notified of what changed precisely via uevent. I'm not really buying
> > > > the "missing uevent" thing so much and I think we can reasonably expect
> > > > that it will be useful. Events could be aggregated (which the epoch
> > > > counter would probably also allow) and sent out altogether when the
> > > > connector status changes (along with the status information). I think
> > > > we're under-using uevent currently, and feel like this should be fixed
> > > > regardless of the full reprobe issue.
> > > 
> > > I see two options:
> > > 
> > > 1) kernel aggregates uevents a bit, and sends out one (per connector
> > > that changed) indicating that sink related state changed. Userspace
> > > listens to that, and does a drmGetConnector as a result to update
> > > itself. Most of this code needs to exist anyway.
> > > 
> > > 2) kernel sends out updates as we go, userspace reassembles everything
> > > again (and not really an idea when all the updates are in, see Lyude's
> > > question. Plus userspace still needs to have the drmGetConnector path,
> > > at least for initial setup.
> > > 
> > > I don't see why 2) is any better than 1), and it has some clear downsides.
> > 
> > My main point is that when the kernel knows some individual property
> > changed, it should update its internal state and report what prop
> > changed *in cases that don't require a full reprobe* and report only
> > which connector changed when a connector reprobe is needed anyway.
> > 
> > Maybe we could even have quirks for drivers to indicate that common
> > actions that shouldn't require a reprobe actually do for this driver in
> > particular, because of whatever instability we want to be confident
> > about handling. I believe this should be abstracted away in DRM and not
> > reflected on the userspace API.
> > 
> > So it's not just about providing per-property updates, the updates
> > reported this way have to be "standalone" and never imply that anything
> > else about the connector's state could have change. Driver's guarantee.
> 
> I'm not sure what that guarantee buys us. You can never assume that if
> you get this event that only that property changed, since other stuff
> might have changed meanwhile.

Then you get a second event notification and act accordingly. And the
kernel will group individual property change events into logical events
that only get reported once, too, so it will be rare in practice. I
don't see what issue we have at hand.

> And especially for a sink change we know that a lot of properties
> (including stuff like connector->status here that's not yet a
> property) will have changed. And event with e.g. PROPERTY=epoch would
> simply indicate that all the sink related things have been updated,
> and you can get them with drmGetConnectorCurrent.

That's what I had in mind with reporting CONNECTOR= without any
PROPERTY. Reporting that epoch change feels weird to me, epoch is more
of a meta-information about the connector that userspace should
probably query on its own.

> We also need some way to indicate that an entire batch of updates have
> completed if we send out events for every part of this. Sending out
> bigger events neatly sidesteps that issue.

As we discussed, grouping property changes into logical changes seems
agreeable to everyone.

> > > > With that, I agree that a global epoch counter from the connector would
> > > > be a good quick way for userspace to tell if a connector changed or not
> > > > since the last time it checked.
> > > > 
> > > > > > > - If userspace misses an event and there's no epoch, we're forcing
> > > > > > > userspace to reprobe everything. Use case would be if a compositor is
> > > > > > > switched away we probably don't want to piss of the current compositor
> > > > > > > by blocking it's own probe kernel calls by doing our own (probe is
> > > > > > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > > > > > it can read the epoch property (which it can do without forcing a
> > > > > > > reprobe) userspace would know which connectors it needs to check and
> > > > > > > reprobe.
> > > > > > > 
> > > > > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > > > > > also require that userspace needs to keep parsing all uevents and make
> > > > > > > a list of all connectors it needs to reprobe when it's back to being
> > > > > > > the active compositor. But just comparing a current epoch with the one
> > > > > > > you cached from the last full probe is much easier.
> > > > > > 
> > > > > > Fair enough, I think it's a fine idea for robustness yes, but I think
> > > > > > we could also provide extra info in the uevent when relevant and not
> > > > > > rely on that entirely.
> > > > > 
> > > > > See above, with drmGetConnectorCurrent there's no need to provide more
> > > > > than what's needed in the uevent, since userspace can get everything
> > > > > else at the cost of one ioctl, without reprobing. With a bit of
> > > > > engineering work we could even avoid taking the expensive
> > > > > dev->mode_config.mutex lock for this fastpath.
> > > > > 
> > > > > > > Another thing: None of this we can for connectors with unreliable hdp.
> > > > > > > Or at least you'll piss of users if you cache always. The sad thing is
> > > > > > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > > > > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > > > > > need to reprobe when the user asks for it. igt can probably get away
> > > > > > > without reprobing.
> > > > > > 
> > > > > > I wonder how that is handled currently and how a user action can solve
> > > > > > the issue without any notification from the kernel. Maybe a need a
> > > > > > better understanding of that case to have a clearer idea.
> > > > > 
> > > > > User opens the screen configuration tool -> usually at that point the
> > > > > tool/compositor force a full reprobe, which then often triggers the
> > > > > automatic reconfiguring. E.g. on one laptop I have here when I plug in
> > > > > random shit projectors at conferences nothing happens, until I run
> > > > > xrandr, which triggers the full reprobe, which then makes the kernel
> > > > > realize something change, sending and uevent, which starts the
> > > > > automatic reconfigure machinery.
> > > > 
> > > > Oh right hehe, I definitely do that blind alt+f2 gnome-control-center
> > > > to get me out of an off-panel situation much too often.
> > > > 
> > > > > There's also the issue that there's machines with hpd storms (even on
> > > > > DP, where you really need hpd to work to be compliant), and we have to
> > > > > turn of the hpd irq to keep the machine useable.
> > > > 
> > > > I was under the impression that we switch to polling when a hpd storm
> > > > is detected in i915 (but that's a vague memory from my summer
> > > > internship at Intel 2 years ago).
> > > 
> > > We do poll, but the issue is still that polling doesn't do the same
> > > thing as full reprobe. One just calls ->detect, the other ->detect +
> > > ->get_modes. This is a bit a silliness of the helpers and source of
> > > lots of confusion. A possible fix might be to always call both.
> > 
> > I think that would make a lot of sense. I don't really get why we have
> > to wait for userspace to do a reprobe to get the new modes when the
> > kernel can be absolutely sure that the modes changed and need to be
> > refreshed.
> 
> Don't let the names trick you, it's an entirely arbitrary split,
> historically grown :-)

Seems like it would be sane to fix that up at this point.

> > > Plus even when that mess is sorted there's still the issue of broken
> > > hw, and we have no idea how much/where/which exactly. Except that
> > > every time we relied on hpd status, we got regression reports and had
> > > to revert.
> > 
> > I think we could configure the notification behavior per-driver and
> > some events that wouldn't require a full probe on some drivers could do
> > so on other drivers. Userspace should find out whether to reprobe or
> > not dynamically based on what's in the uevent anyway, so it's not even
> > an inconsistency in the interface that 2 events be reported differently
> > in 2 drivers. I think that'd be better than the current situation we're
> > in anyway. If some drivers want be paranoid and always ask for
> > a reprobe of the connectors because of unreliable hw, their choice.
> 
> The problem isn't typing the code, it's making sure we don't break the
> world with this. Even if you limit this to i915 alone. That's why I'm
> suggesting we untangle things as much as possible, makes it easier to
> do the (pretty much inevitable) revert.

I really strongly believe that cases of broken hardware should not be a
show-stopper for improving the situation for every other non-broken
case ou there. Sure, there's the policy of no regressions, but it has
limits too. Wanting to support broken hardware is a noble goal, but I
think we should frankly ask ourselves at what cost we want it, and how
much we want to let that degrade the situation for other non-broken
hardware.

And in practice, I still don't see why there have to be regressions. If
a driver aims to support broken setups, it should deal with that itself
and not expect the core to. With what I'm proposing, that could mean
reporting that a full reprobe is needed on basically any event like we
do today. But please, let other drivers do better than that if they
can.

Cheers,

Paul

> -Daniel
> 
> > Cheers,
> > 
> > Paul
> > 
> > > -Daniel
> > > 
> > > > Cheers,
> > > > 
> > > > Paul
> > > > 
> > > > > Cheers, Daniel
> > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > Paul
> > > > > > 
> > > > > > > -Daniel
> > > > > > > 
> > > > > > > > Then we still have the legacy case:
> > > > > > > > HOTPLUG=1
> > > > > > > > 
> > > > > > > > where userspace is expected to reprobe all the connectors.
> > > > > > > > 
> > > > > > > > I think this would deserve to be a separate series on its own. So I am
> > > > > > > > proposing to take this one off your plate and come up with another
> > > > > > > > seres implementing this proposal. What do you think?
> > > > > > > > 
> > > > > > > > Cheers,
> > > > > > > > 
> > > > > > > > Paul
> > > > > > > > 
> > > > > > > > > v2:
> > > > > > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > > > > > v3:
> > > > > > > > >   Check the property is really attached with connector [Daniel]
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > > > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > > >  #include <drm/drm_sysfs.h>
> > > > > > > > >  #include <drm/drmP.h>
> > > > > > > > >  #include "drm_internal.h"
> > > > > > > > > +#include "drm_crtc_internal.h"
> > > > > > > > > 
> > > > > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > > > > > >   * deal with other types of events.
> > > > > > > > > + *
> > > > > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > > > > > + * for uevents on connector status change.
> > > > > > > > >   */
> > > > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > > > >  {
> > > > > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > > > >  }
> > > > > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > > > > > 
> > > > > > > > > +/**
> > > > > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > > > > > + * property status change
> > > > > > > > > + * @connector: connector on which property status changed
> > > > > > > > > + * @property: connector property whoes status changed.
> > > > > > > > > + *
> > > > > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > > > > > + * related to the status change.
> > > > > > > > > + */
> > > > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > > > +                                   struct drm_property *property)
> > > > > > > > > +{
> > > > > > > > > +     struct drm_device *dev = connector->dev;
> > > > > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > > > > > +
> > > > > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > > > > > +                                        property->base.id));
> > > > > > > > > +
> > > > > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > > > > > +              "PROPERTY=%u", property->base.id);
> > > > > > > > > +
> > > > > > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > > > > > +
> > > > > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > > > > > +}
> > > > > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > > > > > +
> > > > > > > > >  static void drm_sysfs_release(struct device *dev)
> > > > > > > > >  {
> > > > > > > > >       kfree(dev);
> > > > > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > > > > > --- a/include/drm/drm_sysfs.h
> > > > > > > > > +++ b/include/drm/drm_sysfs.h
> > > > > > > > > @@ -4,10 +4,13 @@
> > > > > > > > > 
> > > > > > > > >  struct drm_device;
> > > > > > > > >  struct device;
> > > > > > > > > +struct drm_connector;
> > > > > > > > > +struct drm_property;
> > > > > > > > > 
> > > > > > > > >  int drm_class_device_register(struct device *dev);
> > > > > > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > > > > > 
> > > > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > > > > > -
> > > > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > > > +                                   struct drm_property *property);
> > > > > > > > >  #endif
> > > > > > > > --
> > > > > > > > Paul Kocialkowski, Bootlin
> > > > > > > > Embedded Linux and kernel engineering
> > > > > > > > https://bootlin.com
> > > > > > > > 
> > > > > > --
> > > > > > Paul Kocialkowski, Bootlin
> > > > > > Embedded Linux and kernel engineering
> > > > > > https://bootlin.com
> > > > > > 
> > --
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
> 
>
On Wed, May 15, 2019 at 09:43:24AM +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Tue, 2019-05-14 at 16:28 +0200, Daniel Vetter wrote:
> > On Tue, May 14, 2019 at 4:13 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > > 
> > > On Tue, 2019-05-14 at 13:09 +0200, Daniel Vetter wrote:
> > > > On Mon, May 13, 2019 at 7:14 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hey,
> > > > > 
> > > > > Le lundi 13 mai 2019 à 11:34 +0200, Daniel Vetter a écrit :
> > > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:
> > > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > > > > > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > > > > > property.
> > > > > > > > > > 
> > > > > > > > > > This uevent will have following details related to the status change:
> > > > > > > > > > 
> > > > > > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > > > > > 
> > > > > > > > > > Need ACK from this uevent from userspace consumer.
> > > > > > > > > 
> > > > > > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > > > > > issue and came up with similar ideas:
> > > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > > > > > 
> > > > > > > > > The conclusions of these discussions so far would be to have a more or
> > > > > > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > > > > > point is that we need to cover different cases:
> > > > > > > > > - one or more properties changed;
> > > > > > > > > - the connector status changed;
> > > > > > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > > > > > 
> > > > > > > > > For the first case, we can send out:
> > > > > > > > > HOTPLUG=1
> > > > > > > > > CONNECTOR=<id>
> > > > > > > > > PROPERTY=<id>
> > > > > > > > > 
> > > > > > > > > and no reprobe is required.
> > > > > > > > > 
> > > > > > > > > For the second one, something like:
> > > > > > > > > HOTPLUG=1
> > > > > > > > > CONNECTOR=<id>
> > > > > > > > > STATUS=Connected/Disconnected
> > > > > > > > > 
> > > > > > > > > and a connector probe is needed for connected, but not for
> > > > > > > > > disconnected;
> > > > > > > > > 
> > > > > > > > > For the third one, we can only indicate the connector:
> > > > > > > > > HOTPLUG=1
> > > > > > > > > CONNECTOR=<id>
> > > > > > > > > 
> > > > > > > > > and a reprobe of the connector is always needed
> > > > > > > > 
> > > > > > > > There's no material difference between this one and the previous one.
> > > > > > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > > > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.
> > > > > > > 
> > > > > > > That's the idea, but we need to handle status changes differently than
> > > > > > > properties, since as far as I know, connected/unconnected status is not
> > > > > > > exposed as a prop for the connector.
> > > > > > 
> > > > > > Oops, totally missed that. "Everything is a property" is kinda
> > > > > > new-ish, at least compared to kms. Kinda tempted to just make status
> > > > > > into a property. Or another excuse why we should expose the epoch
> > > > > > property :-)
> > > > > 
> > > > > Well I think it would make sense anyway, as long as we can make sure it
> > > > > stays consistent with the one reported in the connector struct.
> > > > > 
> > > > > > > > Here's why:
> > > > > > > > - A side effect of forcing a probe on a connector is that you get to
> > > > > > > > read all the properties, so supplying them is kinda pointless.
> > > > > > > 
> > > > > > > Agreed, except for the status case where it's useful to know it's a
> > > > > > > disconnect, because we don't need any probe step in that case.
> > > > > > > 
> > > > > > > > - You can read STATUS without forcing a reprobe, if you want to avoid
> > > > > > > > the reprobe for disconnected. I'd kinda not recommend that though,
> > > > > > > > feels a bit like overoptimizing. And for reasonable connectors (i.e.
> > > > > > > > dp) reprobing a disconnected output is fast. HDMI is ... less
> > > > > > > > reasonable unfortunately, but oh well.
> > > > > > > 
> > > > > > > How would that be retreived then? From the looks of it, that's a
> > > > > > > MODE_GETCONNECTOR ioctl and I was under the impression this is what
> > > > > > > does the full reprobe.
> > > > > > 
> > > > > > drmGetConnector vs drmGetConnectorCurrent.
> > > > > 
> > > > > Ah right, forgot about that one, thanks.
> > > > > 
> > > > > > > Not sure what issues could arise in case of disconnect without reprobe
> > > > > > > -- at least I don't see why userspace should have to do anything in
> > > > > > > particular except no longer using the connector, even in complex DP MST
> > > > > > > cases.
> > > > > > 
> > > > > > connector->status might be a lie without a full reprobe, and wrongly
> > > > > > indicate that the connector is disconnected while there's still
> > > > > > something plugged in. I'm not sure we've fixed those bugs by now
> > > > > > (usually it's around "hpd indicates disconnected" vs. "i2c indicates
> > > > > > connected, and we can't break this because every intel platform ever
> > > > > > shipped has a few devices where this is somehow broken, irrespective
> > > > > > of the sink).
> > > > > 
> > > > > Mhh either way, I think it's up to the driver to report that and make
> > > > > it consistent. I think we have poll helpers to make up for cases where
> > > > > hotplug is not available too. So I'm not sure why a full reprobe would
> > > > > be needed: drivers just need to do the right thing.
> > > > > 
> > > > > > > > - There's no way to only reprobe status, you can only ever reprobe
> > > > > > > > everything with the current ioctl and implementations. Having an
> > > > > > > > option to reprobe only parts of it doesn't seem useful to me (we need
> > > > > > > > to read the EDID anyway, and that's the expensive part of reprobing in
> > > > > > > > almost all cases).
> > > > > > > 
> > > > > > > Agreed.
> > > > > > > 
> > > > > > > > In a way PROPERTY=<status-prop-id> simply tells userspace that it
> > > > > > > > needs to reprobe this connector.
> > > > > > > 
> > > > > > > I thought we could access the props alone, which avoids doing a reprobe
> > > > > > > when the kernel knows that only a prop or a set of props changed and do
> > > > > > > not require a full reprobe. That's the first case I was mentionning.
> > > > > > > 
> > > > > > > > At that point we need to figure out whether this is a good uapi or
> > > > > > > > not, and that's where the epoch comes in. There's two reasons for an
> > > > > > > > epoch:
> > > > > > > > - We need it internally because I'm not goinig to wire a new return
> > > > > > > > value through hundreds of connector probe functions. It's much easier
> > > > > > > > to have an epoch counter which we set from e.g. drm_set_edid and
> > > > > > > > similar functions that update probe state.
> > > > > > > 
> > > > > > > I don't think I'm following what issue this is trying to solve
> > > > > > > internally.
> > > > > > 
> > > > > > So I'm assuming that if we handle a hotplug, we only want to generate
> > > > > > one uevent for that, not one for every little thing that changed.
> > > > > > There's two ways to implement this logic:
> > > > > > - With some epoch counter and a helper function you can call everytime
> > > > > > something changed (e.g. status, or edid, or anything else we care
> > > > > > about e.g. from dp aux). This won't need much (if any) driver changes,
> > > > > > because we can just put these into the relevant helper/core functions
> > > > > > (like edid update, or dp aux reading or whatever).
> > > > > > - Wiring a new return value through the entire stack (and _all_ the
> > > > > > kms drivers) so that the probe helpers could aggregate this like they
> > > > > > currently do.
> > > > > > 
> > > > > > One of these is a lot less typing.
> > > > > 
> > > > > Oh I had missed this issue. Yeah of course if we start reporting
> > > > > property changes, a hotplug will be lots of such changes.
> > > > > 
> > > > > So an epoch counter property would indeed also solve the reprobing
> > > > > problem. But I think it would be nice to keep the ability to be
> > > > > notified of what changed precisely via uevent. I'm not really buying
> > > > > the "missing uevent" thing so much and I think we can reasonably expect
> > > > > that it will be useful. Events could be aggregated (which the epoch
> > > > > counter would probably also allow) and sent out altogether when the
> > > > > connector status changes (along with the status information). I think
> > > > > we're under-using uevent currently, and feel like this should be fixed
> > > > > regardless of the full reprobe issue.
> > > > 
> > > > I see two options:
> > > > 
> > > > 1) kernel aggregates uevents a bit, and sends out one (per connector
> > > > that changed) indicating that sink related state changed. Userspace
> > > > listens to that, and does a drmGetConnector as a result to update
> > > > itself. Most of this code needs to exist anyway.
> > > > 
> > > > 2) kernel sends out updates as we go, userspace reassembles everything
> > > > again (and not really an idea when all the updates are in, see Lyude's
> > > > question. Plus userspace still needs to have the drmGetConnector path,
> > > > at least for initial setup.
> > > > 
> > > > I don't see why 2) is any better than 1), and it has some clear downsides.
> > > 
> > > My main point is that when the kernel knows some individual property
> > > changed, it should update its internal state and report what prop
> > > changed *in cases that don't require a full reprobe* and report only
> > > which connector changed when a connector reprobe is needed anyway.
> > > 
> > > Maybe we could even have quirks for drivers to indicate that common
> > > actions that shouldn't require a reprobe actually do for this driver in
> > > particular, because of whatever instability we want to be confident
> > > about handling. I believe this should be abstracted away in DRM and not
> > > reflected on the userspace API.
> > > 
> > > So it's not just about providing per-property updates, the updates
> > > reported this way have to be "standalone" and never imply that anything
> > > else about the connector's state could have change. Driver's guarantee.
> > 
> > I'm not sure what that guarantee buys us. You can never assume that if
> > you get this event that only that property changed, since other stuff
> > might have changed meanwhile.
> 
> Then you get a second event notification and act accordingly. And the
> kernel will group individual property change events into logical events
> that only get reported once, too, so it will be rare in practice. I
> don't see what issue we have at hand.
> 
> > And especially for a sink change we know that a lot of properties
> > (including stuff like connector->status here that's not yet a
> > property) will have changed. And event with e.g. PROPERTY=epoch would
> > simply indicate that all the sink related things have been updated,
> > and you can get them with drmGetConnectorCurrent.
> 
> That's what I had in mind with reporting CONNECTOR= without any
> PROPERTY. Reporting that epoch change feels weird to me, epoch is more
> of a meta-information about the connector that userspace should
> probably query on its own.
> 
> > We also need some way to indicate that an entire batch of updates have
> > completed if we send out events for every part of this. Sending out
> > bigger events neatly sidesteps that issue.
> 
> As we discussed, grouping property changes into logical changes seems
> agreeable to everyone.

Yeah no one's disagreeing on that I guess, it's just that there's ways to
get there that involve more or less typing :-)

> > > > > With that, I agree that a global epoch counter from the connector would
> > > > > be a good quick way for userspace to tell if a connector changed or not
> > > > > since the last time it checked.
> > > > > 
> > > > > > > > - If userspace misses an event and there's no epoch, we're forcing
> > > > > > > > userspace to reprobe everything. Use case would be if a compositor is
> > > > > > > > switched away we probably don't want to piss of the current compositor
> > > > > > > > by blocking it's own probe kernel calls by doing our own (probe is
> > > > > > > > single-threaded in the kernel through the dev->mode_config.mutex). If
> > > > > > > > it can read the epoch property (which it can do without forcing a
> > > > > > > > reprobe) userspace would know which connectors it needs to check and
> > > > > > > > reprobe.
> > > > > > > > 
> > > > > > > > Hence why epoch, it's a bit more robust userspace api. Ofc you could
> > > > > > > > also require that userspace needs to keep parsing all uevents and make
> > > > > > > > a list of all connectors it needs to reprobe when it's back to being
> > > > > > > > the active compositor. But just comparing a current epoch with the one
> > > > > > > > you cached from the last full probe is much easier.
> > > > > > > 
> > > > > > > Fair enough, I think it's a fine idea for robustness yes, but I think
> > > > > > > we could also provide extra info in the uevent when relevant and not
> > > > > > > rely on that entirely.
> > > > > > 
> > > > > > See above, with drmGetConnectorCurrent there's no need to provide more
> > > > > > than what's needed in the uevent, since userspace can get everything
> > > > > > else at the cost of one ioctl, without reprobing. With a bit of
> > > > > > engineering work we could even avoid taking the expensive
> > > > > > dev->mode_config.mutex lock for this fastpath.
> > > > > > 
> > > > > > > > Another thing: None of this we can for connectors with unreliable hdp.
> > > > > > > > Or at least you'll piss of users if you cache always. The sad thing is
> > > > > > > > that HDMI is unreliable, at least on some machines/screen combos (you
> > > > > > > > never get a hpd irq if you plug in/unplug). So real compositors still
> > > > > > > > need to reprobe when the user asks for it. igt can probably get away
> > > > > > > > without reprobing.
> > > > > > > 
> > > > > > > I wonder how that is handled currently and how a user action can solve
> > > > > > > the issue without any notification from the kernel. Maybe a need a
> > > > > > > better understanding of that case to have a clearer idea.
> > > > > > 
> > > > > > User opens the screen configuration tool -> usually at that point the
> > > > > > tool/compositor force a full reprobe, which then often triggers the
> > > > > > automatic reconfiguring. E.g. on one laptop I have here when I plug in
> > > > > > random shit projectors at conferences nothing happens, until I run
> > > > > > xrandr, which triggers the full reprobe, which then makes the kernel
> > > > > > realize something change, sending and uevent, which starts the
> > > > > > automatic reconfigure machinery.
> > > > > 
> > > > > Oh right hehe, I definitely do that blind alt+f2 gnome-control-center
> > > > > to get me out of an off-panel situation much too often.
> > > > > 
> > > > > > There's also the issue that there's machines with hpd storms (even on
> > > > > > DP, where you really need hpd to work to be compliant), and we have to
> > > > > > turn of the hpd irq to keep the machine useable.
> > > > > 
> > > > > I was under the impression that we switch to polling when a hpd storm
> > > > > is detected in i915 (but that's a vague memory from my summer
> > > > > internship at Intel 2 years ago).
> > > > 
> > > > We do poll, but the issue is still that polling doesn't do the same
> > > > thing as full reprobe. One just calls ->detect, the other ->detect +
> > > > ->get_modes. This is a bit a silliness of the helpers and source of
> > > > lots of confusion. A possible fix might be to always call both.
> > > 
> > > I think that would make a lot of sense. I don't really get why we have
> > > to wait for userspace to do a reprobe to get the new modes when the
> > > kernel can be absolutely sure that the modes changed and need to be
> > > refreshed.
> > 
> > Don't let the names trick you, it's an entirely arbitrary split,
> > historically grown :-)
> 
> Seems like it would be sane to fix that up at this point.

Sure, the problem is fixing up everyone.

> > > > Plus even when that mess is sorted there's still the issue of broken
> > > > hw, and we have no idea how much/where/which exactly. Except that
> > > > every time we relied on hpd status, we got regression reports and had
> > > > to revert.
> > > 
> > > I think we could configure the notification behavior per-driver and
> > > some events that wouldn't require a full probe on some drivers could do
> > > so on other drivers. Userspace should find out whether to reprobe or
> > > not dynamically based on what's in the uevent anyway, so it's not even
> > > an inconsistency in the interface that 2 events be reported differently
> > > in 2 drivers. I think that'd be better than the current situation we're
> > > in anyway. If some drivers want be paranoid and always ask for
> > > a reprobe of the connectors because of unreliable hw, their choice.
> > 
> > The problem isn't typing the code, it's making sure we don't break the
> > world with this. Even if you limit this to i915 alone. That's why I'm
> > suggesting we untangle things as much as possible, makes it easier to
> > do the (pretty much inevitable) revert.
> 
> I really strongly believe that cases of broken hardware should not be a
> show-stopper for improving the situation for every other non-broken
> case ou there. Sure, there's the policy of no regressions, but it has
> limits too. Wanting to support broken hardware is a noble goal, but I
> think we should frankly ask ourselves at what cost we want it, and how
> much we want to let that degrade the situation for other non-broken
> hardware.

The policy of "no regression" has pretty much no limits. Either you fix up
everything, or it's not going to happen. Or there's some reasonable
forward-compatible option.
-Daniel

> And in practice, I still don't see why there have to be regressions. If
> a driver aims to support broken setups, it should deal with that itself
> and not expect the core to. With what I'm proposing, that could mean
> reporting that a full reprobe is needed on basically any event like we
> do today. But please, let other drivers do better than that if they
> can.
> 
> Cheers,
> 
> Paul
> 
> > -Daniel
> > 
> > > Cheers,
> > > 
> > > Paul
> > > 
> > > > -Daniel
> > > > 
> > > > > Cheers,
> > > > > 
> > > > > Paul
> > > > > 
> > > > > > Cheers, Daniel
> > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > Paul
> > > > > > > 
> > > > > > > > -Daniel
> > > > > > > > 
> > > > > > > > > Then we still have the legacy case:
> > > > > > > > > HOTPLUG=1
> > > > > > > > > 
> > > > > > > > > where userspace is expected to reprobe all the connectors.
> > > > > > > > > 
> > > > > > > > > I think this would deserve to be a separate series on its own. So I am
> > > > > > > > > proposing to take this one off your plate and come up with another
> > > > > > > > > seres implementing this proposal. What do you think?
> > > > > > > > > 
> > > > > > > > > Cheers,
> > > > > > > > > 
> > > > > > > > > Paul
> > > > > > > > > 
> > > > > > > > > > v2:
> > > > > > > > > >   Minor fixes at KDoc comments [Daniel]
> > > > > > > > > > v3:
> > > > > > > > > >   Check the property is really attached with connector [Daniel]
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > > > > > ---
> > > > > > > > > >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> > > > > > > > > >  include/drm/drm_sysfs.h     |  5 ++++-
> > > > > > > > > >  2 files changed, 39 insertions(+), 1 deletion(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > > > index 18b1ac442997..63fa951a20db 100644
> > > > > > > > > > --- a/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > > > +++ b/drivers/gpu/drm/drm_sysfs.c
> > > > > > > > > > @@ -21,6 +21,7 @@
> > > > > > > > > >  #include <drm/drm_sysfs.h>
> > > > > > > > > >  #include <drm/drmP.h>
> > > > > > > > > >  #include "drm_internal.h"
> > > > > > > > > > +#include "drm_crtc_internal.h"
> > > > > > > > > > 
> > > > > > > > > >  #define to_drm_minor(d) dev_get_drvdata(d)
> > > > > > > > > >  #define to_drm_connector(d) dev_get_drvdata(d)
> > > > > > > > > > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> > > > > > > > > >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> > > > > > > > > >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> > > > > > > > > >   * deal with other types of events.
> > > > > > > > > > + *
> > > > > > > > > > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > > > > > > > > > + * for uevents on connector status change.
> > > > > > > > > >   */
> > > > > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > > > > >  {
> > > > > > > > > > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> > > > > > > > > >  }
> > > > > > > > > >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> > > > > > > > > > 
> > > > > > > > > > +/**
> > > > > > > > > > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > > > > > > > > > + * property status change
> > > > > > > > > > + * @connector: connector on which property status changed
> > > > > > > > > > + * @property: connector property whoes status changed.
> > > > > > > > > > + *
> > > > > > > > > > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > > > > > > > > > + * set HOTPLUG=1 and connector id along with the attached property id
> > > > > > > > > > + * related to the status change.
> > > > > > > > > > + */
> > > > > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > > > > +                                   struct drm_property *property)
> > > > > > > > > > +{
> > > > > > > > > > +     struct drm_device *dev = connector->dev;
> > > > > > > > > > +     char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > > > > > > > > > +     char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > > > > > > > > > +
> > > > > > > > > > +     WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > > > > > > > > > +                                        property->base.id));
> > > > > > > > > > +
> > > > > > > > > > +     snprintf(conn_id, ARRAY_SIZE(conn_id),
> > > > > > > > > > +              "CONNECTOR=%u", connector->base.id);
> > > > > > > > > > +     snprintf(prop_id, ARRAY_SIZE(prop_id),
> > > > > > > > > > +              "PROPERTY=%u", property->base.id);
> > > > > > > > > > +
> > > > > > > > > > +     DRM_DEBUG("generating connector status event\n");
> > > > > > > > > > +
> > > > > > > > > > +     kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > > > > > > > > > +}
> > > > > > > > > > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > > > > > > > > > +
> > > > > > > > > >  static void drm_sysfs_release(struct device *dev)
> > > > > > > > > >  {
> > > > > > > > > >       kfree(dev);
> > > > > > > > > > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > > > > > > > > > index 4f311e836cdc..d454ef617b2c 100644
> > > > > > > > > > --- a/include/drm/drm_sysfs.h
> > > > > > > > > > +++ b/include/drm/drm_sysfs.h
> > > > > > > > > > @@ -4,10 +4,13 @@
> > > > > > > > > > 
> > > > > > > > > >  struct drm_device;
> > > > > > > > > >  struct device;
> > > > > > > > > > +struct drm_connector;
> > > > > > > > > > +struct drm_property;
> > > > > > > > > > 
> > > > > > > > > >  int drm_class_device_register(struct device *dev);
> > > > > > > > > >  void drm_class_device_unregister(struct device *dev);
> > > > > > > > > > 
> > > > > > > > > >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > > > > > > > > > -
> > > > > > > > > > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > > > > > > > > > +                                   struct drm_property *property);
> > > > > > > > > >  #endif
> > > > > > > > > --
> > > > > > > > > Paul Kocialkowski, Bootlin
> > > > > > > > > Embedded Linux and kernel engineering
> > > > > > > > > https://bootlin.com
> > > > > > > > > 
> > > > > > > --
> > > > > > > Paul Kocialkowski, Bootlin
> > > > > > > Embedded Linux and kernel engineering
> > > > > > > https://bootlin.com
> > > > > > > 
> > > --
> > > Paul Kocialkowski, Bootlin
> > > Embedded Linux and kernel engineering
> > > https://bootlin.com
> > > 
> > 
> > 
> -- 
> Paul Kocialkowski, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com
>
Hi,

On Wed, 2019-05-15 at 10:37 +0300, Pekka Paalanen wrote:
> On Tue, 14 May 2019 16:34:01 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > On Tue, 14 May 2019 13:02:09 +0200
> > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >  
> > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:  
> > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:  
> 
> ...
> 
> > > > > > Hi Daniel,
> > > > > > 
> > > > > > just to clarify the first case, specific to one very particular
> > > > > > property:
> > > > > > 
> > > > > > With HDCP, there is a property that may change dynamically at runtime
> > > > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > > > when it changes, I do not want userspace have to poll that property
> > > > > > with a timer.
> > > > > > 
> > > > > > When that property alone changes, and userspace is prepared to handle
> > > > > > that property changing alone, it must not trigger a reprobe of the
> > > > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > > > 
> > > > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > > > epoch approach or with any alternate uevent design?
> > > > > > 
> > > > > > We need an event to userspace that indicates that re-reading the
> > > > > > properties is enough and reprobe of the connector is not necessary.
> > > > > > This is complementary to indicating to userspace that only some
> > > > > > connectors need to be reprobed instead of everything.  
> > > > > 
> > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > > > reprobing. Would that work?  
> > > 
> > > Hi,
> > > 
> > > yes, that would work, if it was acceptable to DRM upstream. The replies
> > > to Paul seemed to be going south so fast that I thought we wouldn't get
> > > any new uevent fields in favour of "epoch counters".
> > >  
> > > > Yes that's the idea, depending upon which property you get you know
> > > > it's a sink change (needs full reprobe) or something else like hdcp
> > > > state machinery update.  
> > > 
> > > Right.
> > >  
> > > > Wrt avoiding the full reprobe for sink changes: I think we should
> > > > indeed decouple that from the per-connector event for sink changes.
> > > > That along is a good win already, since you know for which connector
> > > > you need to call drmGetConnector (which forces the reprobe). It would
> > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > > > historically speaking every time we tried to rely on this we ended up
> > > > regretting things.  
> > > 
> > > What changed? This sounds very much what Paul suggested. Looking at it
> > > from userspace side:  
> > 
> > This sounds solid, some refinements below:
> > 
> > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > 
> > > - If yy is "Content Protection", no need to drmModeGetConnector(), just
> > >   re-get the connector properties.
> > > 
> > > - Kernel probably shouldn't bother sending this for properties where
> > >   re-probe could be necessary, and send the below instead.  
> > 
> > I think we should assert that the kernel can get the new property
> > values using drmModeGetConnectorCurrent for this case, i.e. the kernel
> > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > to "must"
> 
> Hi Daniel,
> 
> ok, that's good.
> 
> > Furthermore different property can indicate different kind of updates,
> > e.g. hdcp vs general sink change vs. whatever else might come in the
> > future.
> 
> What do you mean by different kinds of updates?
> 
> Btw. I started thinking, maybe we should completely leave out the "If
> yy is "Content Protection"" and require the kernel to guarantee, that
> if PROPERTY is set, then drmModeGetConnector() (probing) must not be
> necessary based on this event alone.

I agree, this is precisely what I had in mind.

> Writing it down again:
> 
> HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> 
> - yy denotes which connector xx property changed.
> 
> - Userspace does not need to do drmModeGetConnector(), it only needs to
>   drmModeObjectGetProperties() on the connector to receive the new
>   updated property values.
> 
> - Kernel must not send this event for changes that may require probing
>   for correct results, exceptional conditions (buggy hardware, etc.)
>   included. Instead, the kernel must send one of the below events.

Agreed, and leave this up to the driver in the end, not the core.

> Is there actually anything interesting that
> drmModeGetConnectorCurrent() could guaranteed correctly return that is
> not a property already? I'd probably leave this consideration out
> completely, and just say do one of the needs-probing events if anything
> there changed.

In the end, I think this should help move to a situation where
userspace would not have to do a reprobe at any point and the kernel
side just does it.

I see no justification for asking userspace to probe anyway, we can
manage all that in-kernel with each driver keeping its connector props
up to date and properly notifying userspace.

On the other hand, it's definitely good to keep the ability for
userspace to voluntarily reprobe at times, but those two ideas can work
fine together.

> > > HOTPLUG=1 CONNECTOR=xx
> > > 
> > > - Needs to drmModeGetConnector() on the one connector, no need to probe
> > >   others. Implies that one needs to re-get the connector properties as
> > >   well.  
> > 
> > Sounds good.
> > 
> > > HOTPLUG=1
> > > 
> > > - Need to do drmModeGetResouces() to discover new/disappeared
> > >   connectors, and need to drmModeGetConnector to re-probe every
> > >   connector. (As always.)  
> > 
> > Maybe we should clarify that this is also what you get when an entire
> > connector appears/disappears (for dp mst hotplug).
> 
> Yes, that's what I wrote. :-)
> 
> Weston implements the discovery of appearing/disappearing connectors
> (as opposed to connecting/disconnecting connectors). Not sure anyone
> has ever tested it though...
> 
> > Maybe we could make an additional rule that if a connector has the
> > EPOCH property, then it does _not_ need to be reprobe for the global
> > events. For that case userspace should only check whether there's
> > new/removed connectors, and then probe the new ones (and disable the
> > removed ones as needed). We can also use some other flag to indicate
> > this if we don't add the epoch proprty.
> 
> Sounds fine to me, though I'm not too clear what the epoch property
> is designed to achieve. Is it about avoiding re-probing when re-gaining
> DRM master after having let it go, e.g. VT-switching back from another
> VT? That would be nice.
> 
> > > That should be also backwards-compatible: any userspace that doesn't
> > > understand CONNECTOR will see HOTPLUG=1 and re-probe everything. Any
> > > userspace that doesn't understand PROPERTY or the property it refers to
> > > will fall back to probing either the connector or everything.  
> > 
> > Agreed, that should work.
> 
> Cool. The epoch exception you worded seems to fit backward-compatible
> as well.
> 
> > > I would be happy to get that behaviour into Weston, particularly as the
> > > HDCP feature is brewing for Weston too.
> > > 
> > > --------
> > > 
> > > When discussing this in IRC, I had the concern about how uevents are
> > > delivered in userspace. Is there a possibility that they might be
> > > overwritten, contain stale attributes, or get squashed together?
> > > 
> > > Particularly if a display server is current on the VT and active and
> > > monitoring udev, but stuck doing something and cannot service uevents
> > > very fast, and the kernel sends more than one event before the process
> > > gets back to dispatching. The terminology in libudev API confused me as
> > > an event is a device. Squashing together would make sense if the
> > > uevent were just updating a device attribute list. Previously when we
> > > had just a single kind of uevent, that would not have made a
> > > difference, but if we gain different kinds of uevents like here, it
> > > starts to matter.
> > > 
> > > However, Paul came to the conclusion that we will be ok as long as the
> > > events come via netlink.  
> > 
> > Yeah netlink shouldn't drop events on the floor I think. It might
> > still happen, but then I think you should get an indication of that
> > error, and you just treat it as a general hotplug event like on older
> > kernels.
> 
> Alright, although reading Paul it sounds like there is another
> (fallback?) method as well that wouldn't work. Should userspace worry
> about that?

It's unclear to me when that non-netlink thing is actually used by
systemd. IMO we can just leave this out. I think overall uevent/udev is
reliable enough for us to just expect it to work.

Cheers,

Paul

> Hmm, get an indication of an error... I don't know how that would be
> presented in libudev API and I can't point to any code in Weston that
> would deal with it. Does anyone have a clue about that?
> 
> Userspace cannot really start taking advantage of any new fine-grained
> hotplug events until it can rely on the event delivery. Granted, this
> seems purely a userspace issue, but I bet it could be formulated as a
> kernel regression: things stop working after upgrading the kernel while
> having always used new userspace which was ready for detailed hotplug
> events but didn't ensure the delivery in userspace.
> 
> Thanks,
> pq
On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:
> On Tue, 14 May 2019 16:34:01 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > > On Tue, 14 May 2019 13:02:09 +0200
> > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >  
> > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:  
> > > > >
> > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:  
> 
> ...
> 
> > > > > > Hi Daniel,
> > > > > >
> > > > > > just to clarify the first case, specific to one very particular
> > > > > > property:
> > > > > >
> > > > > > With HDCP, there is a property that may change dynamically at runtime
> > > > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > > > when it changes, I do not want userspace have to poll that property
> > > > > > with a timer.
> > > > > >
> > > > > > When that property alone changes, and userspace is prepared to handle
> > > > > > that property changing alone, it must not trigger a reprobe of the
> > > > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > > >
> > > > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > > > epoch approach or with any alternate uevent design?
> > > > > >
> > > > > > We need an event to userspace that indicates that re-reading the
> > > > > > properties is enough and reprobe of the connector is not necessary.
> > > > > > This is complementary to indicating to userspace that only some
> > > > > > connectors need to be reprobed instead of everything.  
> > > > >
> > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > > > reprobing. Would that work?  
> > >
> > > Hi,
> > >
> > > yes, that would work, if it was acceptable to DRM upstream. The replies
> > > to Paul seemed to be going south so fast that I thought we wouldn't get
> > > any new uevent fields in favour of "epoch counters".
> > >  
> > > > Yes that's the idea, depending upon which property you get you know
> > > > it's a sink change (needs full reprobe) or something else like hdcp
> > > > state machinery update.  
> > >
> > > Right.
> > >  
> > > > Wrt avoiding the full reprobe for sink changes: I think we should
> > > > indeed decouple that from the per-connector event for sink changes.
> > > > That along is a good win already, since you know for which connector
> > > > you need to call drmGetConnector (which forces the reprobe). It would
> > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > > > historically speaking every time we tried to rely on this we ended up
> > > > regretting things.  
> > >
> > > What changed? This sounds very much what Paul suggested. Looking at it
> > > from userspace side:  
> > 
> > This sounds solid, some refinements below:
> > 
> > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > >
> > > - If yy is "Content Protection", no need to drmModeGetConnector(), just
> > >   re-get the connector properties.
> > >
> > > - Kernel probably shouldn't bother sending this for properties where
> > >   re-probe could be necessary, and send the below instead.  
> > 
> > 
> > I think we should assert that the kernel can get the new property
> > values using drmModeGetConnectorCurrent for this case, i.e. the kernel
> > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > to "must"
> 
> Hi Daniel,
> 
> ok, that's good.
> 
> > Furthermore different property can indicate different kind of updates,
> > e.g. hdcp vs general sink change vs. whatever else might come in the
> > future.
> 
> What do you mean by different kinds of updates?

Atm we're discussing two:

- "Content Protection"
- "sink changed, but you don't need to reprobe" this would be quite a bit
  a catch all from the output detection. Paul thinks differently, but I'm
  not sold on splitting this up more, at least not right now. This would
  include connector status (and related things returned by drmGetConnector
  which currently aren't a property), EDID, the mst path id, that kind of
  stuff.

Ime once we have 2, there's more bound to come :-)

> Btw. I started thinking, maybe we should completely leave out the "If
> yy is "Content Protection"" and require the kernel to guarantee, that
> if PROPERTY is set, then drmModeGetConnector() (probing) must not be
> necessary based on this event alone.
> 
> Writing it down again:
> 
> HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> 
> - yy denotes which connector xx property changed.

Maybe yy denotes which group of properties changed, and part of the uapi
is picking the canonical one. E.g. content protection might also gain more
properties in the future (there's patches, but the userspace won't be open
sourced). And for that case I don't think we should then send an even for
every single individual property, but just for the lead property.

Maybe we should change it to UPDATE_TYPE=<some-unique-string>, but it felt
better to use the property id we already have for this.

> - Userspace does not need to do drmModeGetConnector(), it only needs to
>   drmModeObjectGetProperties() on the connector to receive the new
>   updated property values.

drmModeGetConnector(Current) also supplies all the properties already.
This is special with connectors, since the predate the "properties on
everything" design. I'd just mention this function here, and ignore
drmModeObjectGetProperties.

> - Kernel must not send this event for changes that may require probing
>   for correct results, exceptional conditions (buggy hardware, etc.)
>   included. Instead, the kernel must send one of the below events.
> 
> Is there actually anything interesting that
> drmModeGetConnectorCurrent() could guaranteed correctly return that is
> not a property already? I'd probably leave this consideration out
> completely, and just say do one of the needs-probing events if anything
> there changed.

That's why I'm suggesting the PROPERTY=<epoch_prop_id> would indicate all
sink related stuff, including the not-properperty-fied stuff is updated,
and will be reported correctly by GetConnectorCurrent.

> > > HOTPLUG=1 CONNECTOR=xx
> > >
> > > - Needs to drmModeGetConnector() on the one connector, no need to probe
> > >   others. Implies that one needs to re-get the connector properties as
> > >   well.  
> > 
> > Sounds good.
> > 
> > > HOTPLUG=1
> > >
> > > - Need to do drmModeGetResouces() to discover new/disappeared
> > >   connectors, and need to drmModeGetConnector to re-probe every
> > >   connector. (As always.)  
> > 
> > Maybe we should clarify that this is also what you get when an entire
> > connector appears/disappears (for dp mst hotplug).
> 
> Yes, that's what I wrote. :-)
> 
> Weston implements the discovery of appearing/disappearing connectors
> (as opposed to connecting/disconnecting connectors). Not sure anyone
> has ever tested it though...

From what -modesetting and X drivers do: Expect surprises in real world
usage :-/

> > Maybe we could make an additional rule that if a connector has the
> > EPOCH property, then it does _not_ need to be reprobe for the global
> > events. For that case userspace should only check whether there's
> > new/removed connectors, and then probe the new ones (and disable the
> > removed ones as needed). We can also use some other flag to indicate
> > this if we don't add the epoch proprty.
> 
> Sounds fine to me, though I'm not too clear what the epoch property
> is designed to achieve. Is it about avoiding re-probing when re-gaining
> DRM master after having let it go, e.g. VT-switching back from another
> VT? That would be nice.

Yup, pretty much. Plus I think we need the epoch internally in the kernel
anyway, to figure out what has changed without having to rewrite endless
amounts of output detection code in all drivers to pass up a new status
change return code. Because atm we totally fail to track sink-related
changes from short pulse hpd (i.e. stays connected, but e.g. edid
changed).

> > > That should be also backwards-compatible: any userspace that doesn't
> > > understand CONNECTOR will see HOTPLUG=1 and re-probe everything. Any
> > > userspace that doesn't understand PROPERTY or the property it refers to
> > > will fall back to probing either the connector or everything.  
> > 
> > Agreed, that should work.
> 
> Cool. The epoch exception you worded seems to fit backward-compatible
> as well.
> 
> > 
> > > I would be happy to get that behaviour into Weston, particularly as the
> > > HDCP feature is brewing for Weston too.
> > >
> > > --------
> > >
> > > When discussing this in IRC, I had the concern about how uevents are
> > > delivered in userspace. Is there a possibility that they might be
> > > overwritten, contain stale attributes, or get squashed together?
> > >
> > > Particularly if a display server is current on the VT and active and
> > > monitoring udev, but stuck doing something and cannot service uevents
> > > very fast, and the kernel sends more than one event before the process
> > > gets back to dispatching. The terminology in libudev API confused me as
> > > an event is a device. Squashing together would make sense if the
> > > uevent were just updating a device attribute list. Previously when we
> > > had just a single kind of uevent, that would not have made a
> > > difference, but if we gain different kinds of uevents like here, it
> > > starts to matter.
> > >
> > > However, Paul came to the conclusion that we will be ok as long as the
> > > events come via netlink.  
> > 
> > Yeah netlink shouldn't drop events on the floor I think. It might
> > still happen, but then I think you should get an indication of that
> > error, and you just treat it as a general hotplug event like on older
> > kernels.
> 
> Alright, although reading Paul it sounds like there is another
> (fallback?) method as well that wouldn't work. Should userspace worry
> about that?
> 
> Hmm, get an indication of an error... I don't know how that would be
> presented in libudev API and I can't point to any code in Weston that
> would deal with it. Does anyone have a clue about that?
> 
> Userspace cannot really start taking advantage of any new fine-grained
> hotplug events until it can rely on the event delivery. Granted, this
> seems purely a userspace issue, but I bet it could be formulated as a
> kernel regression: things stop working after upgrading the kernel while
> having always used new userspace which was ready for detailed hotplug
> events but didn't ensure the delivery in userspace.

You have this already (if it's really an issue with netlink reliability,
tbh no idea), you can already miss a global uevent. It's easier to catch
up if you do miss it, since you're forcing a reprobe on everything. That's
why I think the EPOCH thing would be good, userspace could be defensive
and always call GetConnectorCurrent on all connectors if it gets any
hotplug uevent, and if it gets an EPOCH change, force a reprobe. But I'm
not sure that's really required (aside from VT switching).

If we do think this is required I wonder whether we even need the more
specific event at all :-)
-Daniel

On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> On Wed, 15 May 2019 10:24:49 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:
> > > On Tue, 14 May 2019 16:34:01 +0200
> > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >   
> > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:  
> > > > >
> > > > > On Tue, 14 May 2019 13:02:09 +0200
> > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >    
> > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:    
> > > > > > >
> > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:    
> > > 
> > > ...
> > >   
> > > > > > > > Hi Daniel,
> > > > > > > >
> > > > > > > > just to clarify the first case, specific to one very particular
> > > > > > > > property:
> > > > > > > >
> > > > > > > > With HDCP, there is a property that may change dynamically at runtime
> > > > > > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > > > > > when it changes, I do not want userspace have to poll that property
> > > > > > > > with a timer.
> > > > > > > >
> > > > > > > > When that property alone changes, and userspace is prepared to handle
> > > > > > > > that property changing alone, it must not trigger a reprobe of the
> > > > > > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > > > > >
> > > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > > > > > epoch approach or with any alternate uevent design?
> > > > > > > >
> > > > > > > > We need an event to userspace that indicates that re-reading the
> > > > > > > > properties is enough and reprobe of the connector is not necessary.
> > > > > > > > This is complementary to indicating to userspace that only some
> > > > > > > > connectors need to be reprobed instead of everything.    
> > > > > > >
> > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > > > > > reprobing. Would that work?    
> > > > >
> > > > > Hi,
> > > > >
> > > > > yes, that would work, if it was acceptable to DRM upstream. The replies
> > > > > to Paul seemed to be going south so fast that I thought we wouldn't get
> > > > > any new uevent fields in favour of "epoch counters".
> > > > >    
> > > > > > Yes that's the idea, depending upon which property you get you know
> > > > > > it's a sink change (needs full reprobe) or something else like hdcp
> > > > > > state machinery update.    
> > > > >
> > > > > Right.
> > > > >    
> > > > > > Wrt avoiding the full reprobe for sink changes: I think we should
> > > > > > indeed decouple that from the per-connector event for sink changes.
> > > > > > That along is a good win already, since you know for which connector
> > > > > > you need to call drmGetConnector (which forces the reprobe). It would
> > > > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > > > > > historically speaking every time we tried to rely on this we ended up
> > > > > > regretting things.    
> > > > >
> > > > > What changed? This sounds very much what Paul suggested. Looking at it
> > > > > from userspace side:    
> > > > 
> > > > This sounds solid, some refinements below:
> > > >   
> > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > >
> > > > > - If yy is "Content Protection", no need to drmModeGetConnector(), just
> > > > >   re-get the connector properties.
> > > > >
> > > > > - Kernel probably shouldn't bother sending this for properties where
> > > > >   re-probe could be necessary, and send the below instead.    
> > > > 
> > > > 
> > > > I think we should assert that the kernel can get the new property
> > > > values using drmModeGetConnectorCurrent for this case, i.e. the kernel
> > > > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > > > to "must"  
> > > 
> > > Hi Daniel,
> > > 
> > > ok, that's good.
> > >   
> > > > Furthermore different property can indicate different kind of updates,
> > > > e.g. hdcp vs general sink change vs. whatever else might come in the
> > > > future.  
> > > 
> > > What do you mean by different kinds of updates?  
> > 
> > Atm we're discussing two:
> > 
> > - "Content Protection"
> > - "sink changed, but you don't need to reprobe" this would be quite a bit
> >   a catch all from the output detection. Paul thinks differently, but I'm
> >   not sold on splitting this up more, at least not right now. This would
> >   include connector status (and related things returned by drmGetConnector
> >   which currently aren't a property), EDID, the mst path id, that kind of
> >   stuff.
> > 
> > Ime once we have 2, there's more bound to come :-)
> 
> Hi Daniel,
> 
> I don't understand what the "sink changed" thing could be, but sure,
> there can be more.

So if you have a repeater (hdmi or dp) and you change the thing you plug
into that, then on the computer you don't get a full hotplug, because the
repeater was always connected. Instead you get a short pulse hotplug,
indicating that something with the sink has changed. This could be a
slightly adjusted EDID (e.g. different eld in the audio section), or
something else. That's what I mean with "sink changed". Similar thing can
happen if you unplug and then plug in something else real quick (usually
over suspend/resume), where connector->status stays the same, but the
actual thing plugged in is different. I think for hdmi this is just the
EDID, but we do parse a bunch of things out of the EDID that have further
effects (color space, max clock). With DP there's also dp aux stuff, e.g.
if you switch from a 2 lane to a 4 lane cable then with same screen more
modes can work.

Clearer?

I guess for the documentation for this new uapi we need to make an
exhaustive list of all the things that might have changed for a "sink
changed" event, whatever we actually agree on what that should look like.
Or the PROPERTY=0 fallback you mention below as a fallback idea.

> > > Btw. I started thinking, maybe we should completely leave out the "If
> > > yy is "Content Protection"" and require the kernel to guarantee, that
> > > if PROPERTY is set, then drmModeGetConnector() (probing) must not be
> > > necessary based on this event alone.
> > > 
> > > Writing it down again:
> > > 
> > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > 
> > > - yy denotes which connector xx property changed.  
> > 
> > Maybe yy denotes which group of properties changed, and part of the uapi
> > is picking the canonical one. E.g. content protection might also gain more
> > properties in the future (there's patches, but the userspace won't be open
> > sourced). And for that case I don't think we should then send an even for
> > every single individual property, but just for the lead property.
> > 
> > Maybe we should change it to UPDATE_TYPE=<some-unique-string>, but it felt
> > better to use the property id we already have for this.
> 
> Indeed, it is not really necessary to identify the exact property.
> 
> We could even just use PROPERTY=0 to indicate "something may have
> changed, you should re-get the properties, but no need to probe I
> promise".
> 
> Or like you said, whatever. I don't really care as long as the
> semantics are the same.
> 
> > > - Userspace does not need to do drmModeGetConnector(), it only needs to
> > >   drmModeObjectGetProperties() on the connector to receive the new
> > >   updated property values.  
> > 
> > drmModeGetConnector(Current) also supplies all the properties already.
> > This is special with connectors, since the predate the "properties on
> > everything" design. I'd just mention this function here, and ignore
> > drmModeObjectGetProperties.
> 
> To avoid confusion, it would be best to mention all three functions
> then. It is very easy to forget about legacy uAPI like properties
> through GetConnector.
> 
> > > - Kernel must not send this event for changes that may require probing
> > >   for correct results, exceptional conditions (buggy hardware, etc.)
> > >   included. Instead, the kernel must send one of the below events.
> > > 
> > > Is there actually anything interesting that
> > > drmModeGetConnectorCurrent() could guaranteed correctly return that is
> > > not a property already? I'd probably leave this consideration out
> > > completely, and just say do one of the needs-probing events if anything
> > > there changed.  
> > 
> > That's why I'm suggesting the PROPERTY=<epoch_prop_id> would indicate all
> > sink related stuff, including the not-properperty-fied stuff is updated,
> > and will be reported correctly by GetConnectorCurrent.
> 
> Just because GetConnectorCurrent returns the same properties as
> drmModeObjectGetProperties? Ok then. Personally I'm quite firmly in the
> land where drmModeObjectGetProperties exists, so don't really care
> about the legacy stuff.

So from a quick skimming GetConnectorCurrent == GetProperties, except you
don't get the non-propertified stuff like mode list, ->status, and a few
other things we parse out from various sources. So for connectors you need
to use GetConnector/Current anyway I think, if you rely on GetProperties
only, you're missing stuff.

Agreed that we need to spell this all out.

> > > > > HOTPLUG=1 CONNECTOR=xx
> > > > >
> > > > > - Needs to drmModeGetConnector() on the one connector, no need to probe
> > > > >   others. Implies that one needs to re-get the connector properties as
> > > > >   well.    
> > > > 
> > > > Sounds good.
> > > >   
> > > > > HOTPLUG=1
> > > > >
> > > > > - Need to do drmM odeGetResouces() to discover new/disappeared
> > > > >   connectors, and need to drmModeGetConnector to re-probe every
> > > > >   connector. (As always.)    
> > > > 
> > > > Maybe we should clarify that this is also what you get when an entire
> > > > connector appears/disappears (for dp mst hotplug).  
> > > 
> > > Yes, that's what I wrote. :-)
> > > 
> > > Weston implements the discovery of appearing/disappearing connectors
> > > (as opposed to connecting/disconnecting connectors). Not sure anyone
> > > has ever tested it though...  
> > 
> > From what -modesetting and X drivers do: Expect surprises in real world
> > usage :-/
> 
> I don't know what they do, but sure, always. :-)
> 
> As long as no-one uses untested Weston code to scream "kernel
> regression"...
> 
> > > > Maybe we could make an additional rule that if a connector has the
> > > > EPOCH property, then it does _not_ need to be reprobe for the global
> > > > events. For that case userspace should only check whether there's
> > > > new/removed connectors, and then probe the new ones (and disable the
> > > > removed ones as needed). We can also use some other flag to indicate
> > > > this if we don't add the epoch proprty.  
> > > 
> > > Sounds fine to me, though I'm not too clear what the epoch property
> > > is designed to achieve. Is it about avoiding re-probing when re-gaining
> > > DRM master after having let it go, e.g. VT-switching back from another
> > > VT? That would be nice.  
> > 
> > Yup, pretty much. Plus I think we need the epoch internally in the kernel
> > anyway, to figure out what has changed without having to rewrite endless
> > amounts of output detection code in all drivers to pass up a new status
> > change return code. Because atm we totally fail to track sink-related
> > changes from short pulse hpd (i.e. stays connected, but e.g. edid
> > changed).
> 
> I do not care at all what you might need internally. ;-)
> 
> I am solely interested in the uAPI, and will not look at kernel code. I
> just don't have the time for that.
> 
> > > > > That should be also backwards-compatible: any userspace that doesn't
> > > > > understand CONNECTOR will see HOTPLUG=1 and re-probe everything. Any
> > > > > userspace that doesn't understand PROPERTY or the property it refers to
> > > > > will fall back to probing either the connector or everything.    
> > > > 
> > > > Agreed, that should work.  
> > > 
> > > Cool. The epoch exception you worded seems to fit backward-compatible
> > > as well.
> > >   
> > > >   
> > > > > I would be happy to get that behaviour into Weston, particularly as the
> > > > > HDCP feature is brewing for Weston too.
> > > > >
> > > > > --------
> > > > >
> > > > > When discussing this in IRC, I had the concern about how uevents are
> > > > > delivered in userspace. Is there a possibility that they might be
> > > > > overwritten, contain stale attributes, or get squashed together?
> > > > >
> > > > > Particularly if a display server is current on the VT and active and
> > > > > monitoring udev, but stuck doing something and cannot service uevents
> > > > > very fast, and the kernel sends more than one event before the process
> > > > > gets back to dispatching. The terminology in libudev API confused me as
> > > > > an event is a device. Squashing together would make sense if the
> > > > > uevent were just updating a device attribute list. Previously when we
> > > > > had just a single kind of uevent, that would not have made a
> > > > > difference, but if we gain different kinds of uevents like here, it
> > > > > starts to matter.
> > > > >
> > > > > However, Paul came to the conclusion that we will be ok as long as the
> > > > > events come via netlink.    
> > > > 
> > > > Yeah netlink shouldn't drop events on the floor I think. It might
> > > > still happen, but then I think you should get an indication of that
> > > > error, and you just treat it as a general hotplug event like on older
> > > > kernels.  
> > > 
> > > Alright, although reading Paul it sounds like there is another
> > > (fallback?) method as well that wouldn't work. Should userspace worry
> > > about that?
> > > 
> > > Hmm, get an indication of an error... I don't know how that would be
> > > presented in libudev API and I can't point to any code in Weston that
> > > would deal with it. Does anyone have a clue about that?
> > > 
> > > Userspace cannot really start taking advantage of any new fine-grained
> > > hotplug events until it can rely on the event delivery. Granted, this
> > > seems purely a userspace issue, but I bet it could be formulated as a
> > > kernel regression: things stop working after upgrading the kernel while
> > > having always used new userspace which was ready for detailed hotplug
> > > events but didn't ensure the delivery in userspace.  
> > 
> > You have this already (if it's really an issue with netlink reliability,
> > tbh no idea), you can already miss a global uevent. It's easier to catch
> > up if you do miss it, since you're forcing a reprobe on everything. That's
> > why I think the EPOCH thing would be good, userspace could be defensive
> > and always call GetConnectorCurrent on all connectors if it gets any
> > hotplug uevent, and if it gets an EPOCH change, force a reprobe. But I'm
> > not sure that's really required (aside from VT switching).
> 
> No, my concern is not an issue with netlink reliability. It is a
> potential issue when userspace chooses to not use netlink, and uses
> something else instead. I'm not sure what that else is but Paul says
> there is code in libudev and that is completely outside the control of
> KMS apps like display servers.

afaik this other path only exists because it's the older one, for uapi
backwards compatibility with older userspace. Shouldn't be used for
anything.

> Can you explain how one could miss a global hotplug event when
> userspace is using netlink to watch for events? I thought the netlink
> path through libudev was reliable. And how does userspace realize it
> missed an event?

I thought netlink is supposed to be reliable, but then if you send
bazillion of events and userspace is stuck, eventually you will run out of
memory. I have no idea how netlink signals that, and how that's forwarded
or not in libudev. Also not sure whether we should actually care about
this.
-Daniel

On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> On Thu, 16 May 2019 14:24:55 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > On Wed, 15 May 2019 10:24:49 +0200
> > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > >   
> > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:  
> > > > > On Tue, 14 May 2019 16:34:01 +0200
> > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >     
> > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:    
> > > > > > >
> > > > > > > On Tue, 14 May 2019 13:02:09 +0200
> > > > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > > >      
> > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:      
> > > > > > > > >
> > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:      
> > > > > 
> > > > > ...
> > > > >     
> > > > > > > > > > Hi Daniel,
> > > > > > > > > >
> > > > > > > > > > just to clarify the first case, specific to one very particular
> > > > > > > > > > property:
> > > > > > > > > >
> > > > > > > > > > With HDCP, there is a property that may change dynamically at runtime
> > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > > > > > > > when it changes, I do not want userspace have to poll that property
> > > > > > > > > > with a timer.
> > > > > > > > > >
> > > > > > > > > > When that property alone changes, and userspace is prepared to handle
> > > > > > > > > > that property changing alone, it must not trigger a reprobe of the
> > > > > > > > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > > > > > > >
> > > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > > > > > > > epoch approach or with any alternate uevent design?
> > > > > > > > > >
> > > > > > > > > > We need an event to userspace that indicates that re-reading the
> > > > > > > > > > properties is enough and reprobe of the connector is not necessary.
> > > > > > > > > > This is complementary to indicating to userspace that only some
> > > > > > > > > > connectors need to be reprobed instead of everything.      
> > > > > > > > >
> > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > > > > > > > reprobing. Would that work?      
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > yes, that would work, if it was acceptable to DRM upstream. The replies
> > > > > > > to Paul seemed to be going south so fast that I thought we wouldn't get
> > > > > > > any new uevent fields in favour of "epoch counters".
> > > > > > >      
> > > > > > > > Yes that's the idea, depending upon which property you get you know
> > > > > > > > it's a sink change (needs full reprobe) or something else like hdcp
> > > > > > > > state machinery update.      
> > > > > > >
> > > > > > > Right.
> > > > > > >      
> > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we should
> > > > > > > > indeed decouple that from the per-connector event for sink changes.
> > > > > > > > That along is a good win already, since you know for which connector
> > > > > > > > you need to call drmGetConnector (which forces the reprobe). It would
> > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > > > > > > > historically speaking every time we tried to rely on this we ended up
> > > > > > > > regretting things.      
> > > > > > >
> > > > > > > What changed? This sounds very much what Paul suggested. Looking at it
> > > > > > > from userspace side:      
> > > > > > 
> > > > > > This sounds solid, some refinements below:
> > > > > >     
> > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > > >
> > > > > > > - If yy is "Content Protection", no need to drmModeGetConnector(), just
> > > > > > >   re-get the connector properties.
> > > > > > >
> > > > > > > - Kernel probably shouldn't bother sending this for properties where
> > > > > > >   re-probe could be necessary, and send the below instead.      
> > > > > > 
> > > > > > 
> > > > > > I think we should assert that the kernel can get the new property
> > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the kernel
> > > > > > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > > > > > to "must"    
> > > > > 
> > > > > Hi Daniel,
> > > > > 
> > > > > ok, that's good.
> > > > >     
> > > > > > Furthermore different property can indicate different kind of updates,
> > > > > > e.g. hdcp vs general sink change vs. whatever else might come in the
> > > > > > future.    
> > > > > 
> > > > > What do you mean by different kinds of updates?    
> > > > 
> > > > Atm we're discussing two:
> > > > 
> > > > - "Content Protection"
> > > > - "sink changed, but you don't need to reprobe" this would be quite a bit
> > > >   a catch all from the output detection. Paul thinks differently, but I'm
> > > >   not sold on splitting this up more, at least not right now. This would
> > > >   include connector status (and related things returned by drmGetConnector
> > > >   which currently aren't a property), EDID, the mst path id, that kind of
> > > >   stuff.
> > > > 
> > > > Ime once we have 2, there's more bound to come :-)  
> > > 
> > > Hi Daniel,
> > > 
> > > I don't understand what the "sink changed" thing could be, but sure,
> > > there can be more.  
> > 
> > So if you have a repeater (hdmi or dp) and you change the thing you plug
> > into that, then on the computer you don't get a full hotplug, because the
> > repeater was always connected. Instead you get a short pulse hotplug,
> > indicating that something with the sink has changed. This could be a
> > slightly adjusted EDID (e.g. different eld in the audio section), or
> > something else. That's what I mean with "sink changed". Similar thing can
> > happen if you unplug and then plug in something else real quick (usually
> > over suspend/resume), where connector->status stays the same, but the
> > actual thing plugged in is different. I think for hdmi this is just the
> > EDID, but we do parse a bunch of things out of the EDID that have further
> > effects (color space, max clock). With DP there's also dp aux stuff, e.g.
> > if you switch from a 2 lane to a 4 lane cable then with same screen more
> > modes can work.
> > 
> > Clearer?
> > 
> > I guess for the documentation for this new uapi we need to make an
> > exhaustive list of all the things that might have changed for a "sink
> > changed" event, whatever we actually agree on what that should look like.
> > Or the PROPERTY=0 fallback you mention below as a fallback idea.
> 
> Hi Daniel,
> 
> to me all that sounds like userspace would better do a probe and start
> from scratch with that one connector. Therefore it would fall into the
> 'HOTPLUG=1 CONNECTOR=xx' case, no PROPERTY.
> 
> I suppose I'm missing something?

Doing a full probe is hella expensive. Atm you always have to do this, but
we're talking about the brave new future where the kernel sucks less, and
the kernel would have done the expensive probing for you already.

> But also I don't mind, I have always expected there might be more
> properties whose change does not require a probe.
> 
> So, the kernel does sometimes do the probe on its own as well, right?
> Is that completely invisible to userspace, or could it stall some
> userspace operations that are not a probe of the same connector?

Major stall because the locking design isn't pretty. If the kernel is
probing right now even your GetConnectorCurrent or GetProperties (on a
connector) will stall for whatever long it takes to read the EDID. Or
whatever else the kernel is doing in the probe paths right now. We could
probably improve this, and make sure that at least GetConnectorCurrent and
GetProperties stop sucking. But needs some serious locking-fu to make that
work.

Aside: Just realized this is another important reason why we need to batch
up property updates. If we don't, then userspace will simply get held up
until the kernel is done anyway.

> I really think the design of the uAPI must start with how userspace is
> expected to react to the events. For that there are three cases:
> re-deiscover and probe everyting, re-probe one connector, re-read
> properties of one connector without probe. Userspace can then discover
> what exactly changed, just like it already does.

Yup, I think on this we all agree.

> > > > > Btw. I started thinking, maybe we should completely leave out the "If
> > > > > yy is "Content Protection"" and require the kernel to guarantee, that
> > > > > if PROPERTY is set, then drmModeGetConnector() (probing) must not be
> > > > > necessary based on this event alone.
> > > > > 
> > > > > Writing it down again:
> > > > > 
> > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > 
> > > > > - yy denotes which connector xx property changed.    
> > > > 
> > > > Maybe yy denotes which group of properties changed, and part of the uapi
> > > > is picking the canonical one. E.g. content protection might also gain more
> > > > properties in the future (there's patches, but the userspace won't be open
> > > > sourced). And for that case I don't think we should then send an even for
> > > > every single individual property, but just for the lead property.
> > > > 
> > > > Maybe we should change it to UPDATE_TYPE=<some-unique-string>, but it felt
> > > > better to use the property id we already have for this.  
> > > 
> > > Indeed, it is not really necessary to identify the exact property.
> > > 
> > > We could even just use PROPERTY=0 to indicate "something may have
> > > changed, you should re-get the properties, but no need to probe I
> > > promise".
> > > 
> > > Or like you said, whatever. I don't really care as long as the
> > > semantics are the same.
> > >   
> > > > > - Userspace does not need to do drmModeGetConnector(), it only needs to
> > > > >   drmModeObjectGetProperties() on the connector to receive the new
> > > > >   updated property values.    
> > > > 
> > > > drmModeGetConnector(Current) also supplies all the properties already.
> > > > This is special with connectors, since the predate the "properties on
> > > > everything" design. I'd just mention this function here, and ignore
> > > > drmModeObjectGetProperties.  
> > > 
> > > To avoid confusion, it would be best to mention all three functions
> > > then. It is very easy to forget about legacy uAPI like properties
> > > through GetConnector.
> > >   
> > > > > - Kernel must not send this event for changes that may require probing
> > > > >   for correct results, exceptional conditions (buggy hardware, etc.)
> > > > >   included. Instead, the kernel must send one of the below events.
> > > > > 
> > > > > Is there actually anything interesting that
> > > > > drmModeGetConnectorCurrent() could guaranteed correctly return that is
> > > > > not a property already? I'd probably leave this consideration out
> > > > > completely, and just say do one of the needs-probing events if anything
> > > > > there changed.    
> > > > 
> > > > That's why I'm suggesting the PROPERTY=<epoch_prop_id> would indicate all
> > > > sink related stuff, including the not-properperty-fied stuff is updated,
> > > > and will be reported correctly by GetConnectorCurrent.  
> > > 
> > > Just because GetConnectorCurrent returns the same properties as
> > > drmModeObjectGetProperties? Ok then. Personally I'm quite firmly in the
> > > land where drmModeObjectGetProperties exists, so don't really care
> > > about the legacy stuff.  
> > 
> > So from a quick skimming GetConnectorCurrent == GetProperties, except you
> > don't get the non-propertified stuff like mode list, ->status, and a few
> > other things we parse out from various sources. So for connectors you need
> > to use GetConnector/Current anyway I think, if you rely on GetProperties
> > only, you're missing stuff.
> 
> That was part of my question: the stuff I would be missing, does it
> matter?
> 
> Most of the stuff I would be missing are things that require a probe to
> be up-to-date, which means I will not be missing them, because I will
> be calling drmModeGetConnector instead (and not GetConnectorCurrent),
> because the kernel driver sent an uevent to tell me to do exactly that.

Yes currently that's true, because the kernel sucks. But it would be nice
if we could do the expensive probing all upfront, for most connectors, and
(at least eventually) block userspace's uevent handler a bit less.

> Is there anything in the set of connector parameters which a) do not
> require a probe to be up-to-date, and b) are not actual properties too?

Not yet. I'd like to make the kernel suck less though (and at least for
dp/hdmi we should be able to do that with few changes).

> If there are, we have two options: complicate userspace to use a third
> function to get some bits (drmModeGetConnectorCurrent), or make the
> kernel driver just send the uevent that makes userspace probe anyway.

See above, I want to get the expensive probe stuff out of the ueven as
much as possible. Reading an EDID usually means you miss a frame (~20ms
for your average hdmi edid, can be a lot more). Except if you bother with
thread your compositor, and then why does the kernel suck that much :-/

> > Agreed that we need to spell this all out.
> > 
> > > > > > > HOTPLUG=1 CONNECTOR=xx
> > > > > > >
> > > > > > > - Needs to drmModeGetConnector() on the one connector, no need to probe
> > > > > > >   others. Implies that one needs to re-get the connector properties as
> > > > > > >   well.      
> > > > > > 
> > > > > > Sounds good.
> > > > > >     
> > > > > > > HOTPLUG=1
> > > > > > >
> > > > > > > - Need to do drmM odeGetResouces() to discover new/disappeared
> > > > > > >   connectors, and need to drmModeGetConnector to re-probe every
> > > > > > >   connector. (As always.)      
> 
> ...
> 
> > > > > > > --------
> > > > > > >
> > > > > > > When discussing this in IRC, I had the concern about how uevents are
> > > > > > > delivered in userspace. Is there a possibility that they might be
> > > > > > > overwritten, contain stale attributes, or get squashed together?
> > > > > > >
> > > > > > > Particularly if a display server is current on the VT and active and
> > > > > > > monitoring udev, but stuck doing something and cannot service uevents
> > > > > > > very fast, and the kernel sends more than one event before the process
> > > > > > > gets back to dispatching. The terminology in libudev API confused me as
> > > > > > > an event is a device. Squashing together would make sense if the
> > > > > > > uevent were just updating a device attribute list. Previously when we
> > > > > > > had just a single kind of uevent, that would not have made a
> > > > > > > difference, but if we gain different kinds of uevents like here, it
> > > > > > > starts to matter.
> > > > > > >
> > > > > > > However, Paul came to the conclusion that we will be ok as long as the
> > > > > > > events come via netlink.      
> > > > > > 
> > > > > > Yeah netlink shouldn't drop events on the floor I think. It might
> > > > > > still happen, but then I think you should get an indication of that
> > > > > > error, and you just treat it as a general hotplug event like on older
> > > > > > kernels.    
> > > > > 
> > > > > Alright, although reading Paul it sounds like there is another
> > > > > (fallback?) method as well that wouldn't work. Should userspace worry
> > > > > about that?
> > > > > 
> > > > > Hmm, get an indication of an error... I don't know how that would be
> > > > > presented in libudev API and I can't point to any code in Weston that
> > > > > would deal with it. Does anyone have a clue about that?
> > > > > 
> > > > > Userspace cannot really start taking advantage of any new fine-grained
> > > > > hotplug events until it can rely on the event delivery. Granted, this
> > > > > seems purely a userspace issue, but I bet it could be formulated as a
> > > > > kernel regression: things stop working after upgrading the kernel while
> > > > > having always used new userspace which was ready for detailed hotplug
> > > > > events but didn't ensure the delivery in userspace.    
> > > > 
> > > > You have this already (if it's really an issue with netlink reliability,
> > > > tbh no idea), you can already miss a global uevent. It's easier to catch
> > > > up if you do miss it, since you're forcing a reprobe on everything. That's
> > > > why I think the EPOCH thing would be good, userspace could be defensive
> > > > and always call GetConnectorCurrent on all connectors if it gets any
> > > > hotplug uevent, and if it gets an EPOCH change, force a reprobe. But I'm
> > > > not sure that's really required (aside from VT switching).  
> > > 
> > > No, my concern is not an issue with netlink reliability. It is a
> > > potential issue when userspace chooses to not use netlink, and uses
> > > something else instead. I'm not sure what that else is but Paul says
> > > there is code in libudev and that is completely outside the control of
> > > KMS apps like display servers.  
> > 
> > afaik this other path only exists because it's the older one, for uapi
> > backwards compatibility with older userspace. Shouldn't be used for
> > anything.
> 
> "Shouldn't be used" and someone screaming "kernel regression"... are you
> sure that path won't matter?
> 
> Like some home-brewn distribution that happens to configure their
> libudev and kernel to use the old method, uses already new userspace,
> and then upgrades the kernel that starts sending fine-grained hotplug
> events, resulting the display server randomly handling hotplug wrong.
> 
> Reading Airlie's recent rant about kernel regression handling make this
> a scary scenario where you would have no other choice than to rip all
> the fine-grained uevents out again.
> 
> Is there any difference in the kernel code between the old method and
> the netlink method? Would it be possible to send fine-grained hotplug
> events only through netlink, and fall back to the old 'HOTPLUG=1' for
> the old method?

There's a lot of grey in kernel regressions, and for fringe setups used by
few people I wouldn't worry about this. If they expect their shit to keep
working when using new stuff and crappy old interfaces, they get to keep
all the pieces.

Dave's recent rant was a bit special, since userspace is clearly smoking
some strong stuff (-modesetting's atomic is seriously not using atomic
correctly), but it was also affecting too many people, and changing the
boot setup meant you'd get a black screen on boot-up already. Instead of
just on the first modeset with more than 1 screen.

There's also a fairly easy fix for that -modesetting issue: We don't
expose atomic if the compositor has a process name of "Xserver". Brutal,
but gets the job done. Once X is fixed, we can give a new "I'm not totally
broken anymore" interface to get back at atomic.

tldr; I'm not worried at all, at least not more than with anything uapi.
Very rarely we'll have regrets.

> > > Can you explain how one could miss a global hotplug event when
> > > userspace is using netlink to watch for events? I thought the netlink
> > > path through libudev was reliable. And how does userspace realize it
> > > missed an event?  
> > 
> > I thought netlink is supposed to be reliable, but then if you send
> > bazillion of events and userspace is stuck, eventually you will run out of
> > memory. I have no idea how netlink signals that, and how that's forwarded
> > or not in libudev. Also not sure whether we should actually care about
> > this.
> 
> Ok. Let's try to keep the number of events low then, e.g. in the case of
> 
> 	HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> 
> revert to sending just a single uevent with PROPERTY set to 0 instead
> if there are more than one such no-probe property changes for the same
> connector.

Yeah PROPERTY=0 would be another option. I think indicates clearly "don't
reprobe" but also "update not for any specific prop, but for all of
them".

Cheers, Daniel
Le lundi 20 mai 2019 à 18:11 +0200, Daniel Vetter a écrit :
> On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > On Thu, 16 May 2019 14:24:55 +0200
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> > 
> > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > > On Wed, 15 May 2019 10:24:49 +0200
> > > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >   
> > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:  
> > > > > > On Tue, 14 May 2019 16:34:01 +0200
> > > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > >     
> > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:    
> > > > > > > > On Tue, 14 May 2019 13:02:09 +0200
> > > > > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > > > >      
> > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:      
> > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:      
> > > > > > 
> > > > > > ...
> > > > > >     
> > > > > > > > > > > Hi Daniel,
> > > > > > > > > > > 
> > > > > > > > > > > just to clarify the first case, specific to one very particular
> > > > > > > > > > > property:
> > > > > > > > > > > 
> > > > > > > > > > > With HDCP, there is a property that may change dynamically at runtime
> > > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > > > > > > > > when it changes, I do not want userspace have to poll that property
> > > > > > > > > > > with a timer.
> > > > > > > > > > > 
> > > > > > > > > > > When that property alone changes, and userspace is prepared to handle
> > > > > > > > > > > that property changing alone, it must not trigger a reprobe of the
> > > > > > > > > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > > > > > > > > 
> > > > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > > > > > > > > epoch approach or with any alternate uevent design?
> > > > > > > > > > > 
> > > > > > > > > > > We need an event to userspace that indicates that re-reading the
> > > > > > > > > > > properties is enough and reprobe of the connector is not necessary.
> > > > > > > > > > > This is complementary to indicating to userspace that only some
> > > > > > > > > > > connectors need to be reprobed instead of everything.      
> > > > > > > > > > 
> > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > > > > > > > > reprobing. Would that work?      
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The replies
> > > > > > > > to Paul seemed to be going south so fast that I thought we wouldn't get
> > > > > > > > any new uevent fields in favour of "epoch counters".
> > > > > > > >      
> > > > > > > > > Yes that's the idea, depending upon which property you get you know
> > > > > > > > > it's a sink change (needs full reprobe) or something else like hdcp
> > > > > > > > > state machinery update.      
> > > > > > > > 
> > > > > > > > Right.
> > > > > > > >      
> > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we should
> > > > > > > > > indeed decouple that from the per-connector event for sink changes.
> > > > > > > > > That along is a good win already, since you know for which connector
> > > > > > > > > you need to call drmGetConnector (which forces the reprobe). It would
> > > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > > > > > > > > historically speaking every time we tried to rely on this we ended up
> > > > > > > > > regretting things.      
> > > > > > > > 
> > > > > > > > What changed? This sounds very much what Paul suggested. Looking at it
> > > > > > > > from userspace side:      
> > > > > > > 
> > > > > > > This sounds solid, some refinements below:
> > > > > > >     
> > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > > > > 
> > > > > > > > - If yy is "Content Protection", no need to drmModeGetConnector(), just
> > > > > > > >   re-get the connector properties.
> > > > > > > > 
> > > > > > > > - Kernel probably shouldn't bother sending this for properties where
> > > > > > > >   re-probe could be necessary, and send the below instead.      
> > > > > > > 
> > > > > > > I think we should assert that the kernel can get the new property
> > > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the kernel
> > > > > > > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > > > > > > to "must"    
> > > > > > 
> > > > > > Hi Daniel,
> > > > > > 
> > > > > > ok, that's good.
> > > > > >     
> > > > > > > Furthermore different property can indicate different kind of updates,
> > > > > > > e.g. hdcp vs general sink change vs. whatever else might come in the
> > > > > > > future.    
> > > > > > 
> > > > > > What do you mean by different kinds of updates?    
> > > > > 
> > > > > Atm we're discussing two:
> > > > > 
> > > > > - "Content Protection"
> > > > > - "sink changed, but you don't need to reprobe" this would be quite a bit
> > > > >   a catch all from the output detection. Paul thinks differently, but I'm
> > > > >   not sold on splitting this up more, at least not right now. This would
> > > > >   include connector status (and related things returned by drmGetConnector
> > > > >   which currently aren't a property), EDID, the mst path id, that kind of
> > > > >   stuff.
> > > > > 
> > > > > Ime once we have 2, there's more bound to come :-)  
> > > > 
> > > > Hi Daniel,
> > > > 
> > > > I don't understand what the "sink changed" thing could be, but sure,
> > > > there can be more.  
> > > 
> > > So if you have a repeater (hdmi or dp) and you change the thing you plug
> > > into that, then on the computer you don't get a full hotplug, because the
> > > repeater was always connected. Instead you get a short pulse hotplug,
> > > indicating that something with the sink has changed. This could be a
> > > slightly adjusted EDID (e.g. different eld in the audio section), or
> > > something else. That's what I mean with "sink changed". Similar thing can
> > > happen if you unplug and then plug in something else real quick (usually
> > > over suspend/resume), where connector->status stays the same, but the
> > > actual thing plugged in is different. I think for hdmi this is just the
> > > EDID, but we do parse a bunch of things out of the EDID that have further
> > > effects (color space, max clock). With DP there's also dp aux stuff, e.g.
> > > if you switch from a 2 lane to a 4 lane cable then with same screen more
> > > modes can work.
> > > 
> > > Clearer?
> > > 
> > > I guess for the documentation for this new uapi we need to make an
> > > exhaustive list of all the things that might have changed for a "sink
> > > changed" event, whatever we actually agree on what that should look like.
> > > Or the PROPERTY=0 fallback you mention below as a fallback idea.
> > 
> > Hi Daniel,
> > 
> > to me all that sounds like userspace would better do a probe and start
> > from scratch with that one connector. Therefore it would fall into the
> > 'HOTPLUG=1 CONNECTOR=xx' case, no PROPERTY.
> > 
> > I suppose I'm missing something?
> 
> Doing a full probe is hella expensive. Atm you always have to do this, but
> we're talking about the brave new future where the kernel sucks less, and
> the kernel would have done the expensive probing for you already.
>
> > But also I don't mind, I have always expected there might be more
> > properties whose change does not require a probe.
> > 
> > So, the kernel does sometimes do the probe on its own as well, right?
> > Is that completely invisible to userspace, or could it stall some
> > userspace operations that are not a probe of the same connector?
> 
> Major stall because the locking design isn't pretty. If the kernel is
> probing right now even your GetConnectorCurrent or GetProperties (on a
> connector) will stall for whatever long it takes to read the EDID. Or
> whatever else the kernel is doing in the probe paths right now. We could
> probably improve this, and make sure that at least GetConnectorCurrent and
> GetProperties stop sucking. But needs some serious locking-fu to make that
> work.
> 
> Aside: Just realized this is another important reason why we need to batch
> up property updates. If we don't, then userspace will simply get held up
> until the kernel is done anyway.

I'm all in favor of having the kernel do the probing on its own (and
reworking things to make sure this doesn't stall uapi calls) while
only sending a uevent when we have a new connector state populated and ready.

> > I really think the design of the uAPI must start with how userspace is
> > expected to react to the events. For that there are three cases:
> > re-deiscover and probe everyting, re-probe one connector, re-read
> > properties of one connector without probe. Userspace can then discover
> > what exactly changed, just like it already does.
> 
> Yup, I think on this we all agree.
> 
> > > > > > Btw. I started thinking, maybe we should completely leave out the "If
> > > > > > yy is "Content Protection"" and require the kernel to guarantee, that
> > > > > > if PROPERTY is set, then drmModeGetConnector() (probing) must not be
> > > > > > necessary based on this event alone.
> > > > > > 
> > > > > > Writing it down again:
> > > > > > 
> > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > > 
> > > > > > - yy denotes which connector xx property changed.    
> > > > > 
> > > > > Maybe yy denotes which group of properties changed, and part of the uapi
> > > > > is picking the canonical one. E.g. content protection might also gain more
> > > > > properties in the future (there's patches, but the userspace won't be open
> > > > > sourced). And for that case I don't think we should then send an even for
> > > > > every single individual property, but just for the lead property.
> > > > > 
> > > > > Maybe we should change it to UPDATE_TYPE=<some-unique-string>, but it felt
> > > > > better to use the property id we already have for this.  
> > > > 
> > > > Indeed, it is not really necessary to identify the exact property.
> > > > 
> > > > We could even just use PROPERTY=0 to indicate "something may have
> > > > changed, you should re-get the properties, but no need to probe I
> > > > promise".
> > > > 
> > > > Or like you said, whatever. I don't really care as long as the
> > > > semantics are the same.
> > > >   
> > > > > > - Userspace does not need to do drmModeGetConnector(), it only needs to
> > > > > >   drmModeObjectGetProperties() on the connector to receive the new
> > > > > >   updated property values.    
> > > > > 
> > > > > drmModeGetConnector(Current) also supplies all the properties already.
> > > > > This is special with connectors, since the predate the "properties on
> > > > > everything" design. I'd just mention this function here, and ignore
> > > > > drmModeObjectGetProperties.  
> > > > 
> > > > To avoid confusion, it would be best to mention all three functions
> > > > then. It is very easy to forget about legacy uAPI like properties
> > > > through GetConnector.
> > > >   
> > > > > > - Kernel must not send this event for changes that may require probing
> > > > > >   for correct results, exceptional conditions (buggy hardware, etc.)
> > > > > >   included. Instead, the kernel must send one of the below events.
> > > > > > 
> > > > > > Is there actually anything interesting that
> > > > > > drmModeGetConnectorCurrent() could guaranteed correctly return that is
> > > > > > not a property already? I'd probably leave this consideration out
> > > > > > completely, and just say do one of the needs-probing events if anything
> > > > > > there changed.    
> > > > > 
> > > > > That's why I'm suggesting the PROPERTY=<epoch_prop_id> would indicate all
> > > > > sink related stuff, including the not-properperty-fied stuff is updated,
> > > > > and will be reported correctly by GetConnectorCurrent.  
> > > > 
> > > > Just because GetConnectorCurrent returns the same properties as
> > > > drmModeObjectGetProperties? Ok then. Personally I'm quite firmly in the
> > > > land where drmModeObjectGetProperties exists, so don't really care
> > > > about the legacy stuff.  
> > > 
> > > So from a quick skimming GetConnectorCurrent == GetProperties, except you
> > > don't get the non-propertified stuff like mode list, ->status, and a few
> > > other things we parse out from various sources. So for connectors you need
> > > to use GetConnector/Current anyway I think, if you rely on GetProperties
> > > only, you're missing stuff.
> > 
> > That was part of my question: the stuff I would be missing, does it
> > matter?
> > 
> > Most of the stuff I would be missing are things that require a probe to
> > be up-to-date, which means I will not be missing them, because I will
> > be calling drmModeGetConnector instead (and not GetConnectorCurrent),
> > because the kernel driver sent an uevent to tell me to do exactly that.
> 
> Yes currently that's true, because the kernel sucks. But it would be nice
> if we could do the expensive probing all upfront, for most connectors, and
> (at least eventually) block userspace's uevent handler a bit less.

Agreed.

> > Is there anything in the set of connector parameters which a) do not
> > require a probe to be up-to-date, and b) are not actual properties too?
> 
> Not yet. I'd like to make the kernel suck less though (and at least for
> dp/hdmi we should be able to do that with few changes).
> 
> > If there are, we have two options: complicate userspace to use a third
> > function to get some bits (drmModeGetConnectorCurrent), or make the
> > kernel driver just send the uevent that makes userspace probe anyway.
> 
> See above, I want to get the expensive probe stuff out of the ueven as
> much as possible. Reading an EDID usually means you miss a frame (~20ms
> for your average hdmi edid, can be a lot more). Except if you bother with
> thread your compositor, and then why does the kernel suck that much :-/
> 
> > > Agreed that we need to spell this all out.
> > > 
> > > > > > > > HOTPLUG=1 CONNECTOR=xx
> > > > > > > > 
> > > > > > > > - Needs to drmModeGetConnector() on the one connector, no need to probe
> > > > > > > >   others. Implies that one needs to re-get the connector properties as
> > > > > > > >   well.      
> > > > > > > 
> > > > > > > Sounds good.
> > > > > > >     
> > > > > > > > HOTPLUG=1
> > > > > > > > 
> > > > > > > > - Need to do drmM odeGetResouces() to discover new/disappeared
> > > > > > > >   connectors, and need to drmModeGetConnector to re-probe every
> > > > > > > >   connector. (As always.)      
> > 
> > ...
> > 
> > > > > > > > --------
> > > > > > > > 
> > > > > > > > When discussing this in IRC, I had the concern about how uevents are
> > > > > > > > delivered in userspace. Is there a possibility that they might be
> > > > > > > > overwritten, contain stale attributes, or get squashed together?
> > > > > > > > 
> > > > > > > > Particularly if a display server is current on the VT and active and
> > > > > > > > monitoring udev, but stuck doing something and cannot service uevents
> > > > > > > > very fast, and the kernel sends more than one event before the process
> > > > > > > > gets back to dispatching. The terminology in libudev API confused me as
> > > > > > > > an event is a device. Squashing together would make sense if the
> > > > > > > > uevent were just updating a device attribute list. Previously when we
> > > > > > > > had just a single kind of uevent, that would not have made a
> > > > > > > > difference, but if we gain different kinds of uevents like here, it
> > > > > > > > starts to matter.
> > > > > > > > 
> > > > > > > > However, Paul came to the conclusion that we will be ok as long as the
> > > > > > > > events come via netlink.      
> > > > > > > 
> > > > > > > Yeah netlink shouldn't drop events on the floor I think. It might
> > > > > > > still happen, but then I think you should get an indication of that
> > > > > > > error, and you just treat it as a general hotplug event like on older
> > > > > > > kernels.    
> > > > > > 
> > > > > > Alright, although reading Paul it sounds like there is another
> > > > > > (fallback?) method as well that wouldn't work. Should userspace worry
> > > > > > about that?
> > > > > > 
> > > > > > Hmm, get an indication of an error... I don't know how that would be
> > > > > > presented in libudev API and I can't point to any code in Weston that
> > > > > > would deal with it. Does anyone have a clue about that?
> > > > > > 
> > > > > > Userspace cannot really start taking advantage of any new fine-grained
> > > > > > hotplug events until it can rely on the event delivery. Granted, this
> > > > > > seems purely a userspace issue, but I bet it could be formulated as a
> > > > > > kernel regression: things stop working after upgrading the kernel while
> > > > > > having always used new userspace which was ready for detailed hotplug
> > > > > > events but didn't ensure the delivery in userspace.    
> > > > > 
> > > > > You have this already (if it's really an issue with netlink reliability,
> > > > > tbh no idea), you can already miss a global uevent. It's easier to catch
> > > > > up if you do miss it, since you're forcing a reprobe on everything. That's
> > > > > why I think the EPOCH thing would be good, userspace could be defensive
> > > > > and always call GetConnectorCurrent on all connectors if it gets any
> > > > > hotplug uevent, and if it gets an EPOCH change, force a reprobe. But I'm
> > > > > not sure that's really required (aside from VT switching).  
> > > > 
> > > > No, my concern is not an issue with netlink reliability. It is a
> > > > potential issue when userspace chooses to not use netlink, and uses
> > > > something else instead. I'm not sure what that else is but Paul says
> > > > there is code in libudev and that is completely outside the control of
> > > > KMS apps like display servers.  
> > > 
> > > afaik this other path only exists because it's the older one, for uapi
> > > backwards compatibility with older userspace. Shouldn't be used for
> > > anything.
> > 
> > "Shouldn't be used" and someone screaming "kernel regression"... are you
> > sure that path won't matter?
> > 
> > Like some home-brewn distribution that happens to configure their
> > libudev and kernel to use the old method, uses already new userspace,
> > and then upgrades the kernel that starts sending fine-grained hotplug
> > events, resulting the display server randomly handling hotplug wrong.
> > 
> > Reading Airlie's recent rant about kernel regression handling make this
> > a scary scenario where you would have no other choice than to rip all
> > the fine-grained uevents out again.
> > 
> > Is there any difference in the kernel code between the old method and
> > the netlink method? Would it be possible to send fine-grained hotplug
> > events only through netlink, and fall back to the old 'HOTPLUG=1' for
> > the old method?
> 
> There's a lot of grey in kernel regressions, and for fringe setups used by
> few people I wouldn't worry about this. If they expect their shit to keep
> working when using new stuff and crappy old interfaces, they get to keep
> all the pieces.
> 
> Dave's recent rant was a bit special, since userspace is clearly smoking
> some strong stuff (-modesetting's atomic is seriously not using atomic
> correctly), but it was also affecting too many people, and changing the
> boot setup meant you'd get a black screen on boot-up already. Instead of
> just on the first modeset with more than 1 screen.
> 
> There's also a fairly easy fix for that -modesetting issue: We don't
> expose atomic if the compositor has a process name of "Xserver". Brutal,
> but gets the job done. Once X is fixed, we can give a new "I'm not totally
> broken anymore" interface to get back at atomic.
> 
> tldr; I'm not worried at all, at least not more than with anything uapi.
> Very rarely we'll have regrets.

Cheers to that!

> > > > Can you explain how one could miss a global hotplug event when
> > > > userspace is using netlink to watch for events? I thought the netlink
> > > > path through libudev was reliable. And how does userspace realize it
> > > > missed an event?  
> > > 
> > > I thought netlink is supposed to be reliable, but then if you send
> > > bazillion of events and userspace is stuck, eventually you will run out of
> > > memory. I have no idea how netlink signals that, and how that's forwarded
> > > or not in libudev. Also not sure whether we should actually care about
> > > this.
> > 
> > Ok. Let's try to keep the number of events low then, e.g. in the case of
> > 
> > 	HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > 
> > revert to sending just a single uevent with PROPERTY set to 0 instead
> > if there are more than one such no-probe property changes for the same
> > connector.
> 
> Yeah PROPERTY=0 would be another option. I think indicates clearly "don't
> reprobe" but also "update not for any specific prop, but for all of
> them".

That would make sense, although I think we should also be able to cover
cases where one or a number of properties changed and we know exactly
which ones. If we're going to have an exposed connector state and an
internal one that's being populated with connector changes, that could
be made easier.

Cheers,

Paul

On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Mon, 20 May 2019 18:11:07 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > > On Thu, 16 May 2019 14:24:55 +0200
> > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > > > On Wed, 15 May 2019 10:24:49 +0200
> > > > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:
> > > > > > > On Tue, 14 May 2019 16:34:01 +0200
> > > > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > > >
> > > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, 14 May 2019 13:02:09 +0200
> > > > > > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon <simon.ser@intel.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > > > > > > Hi Daniel,
> > > > > > > > > > > >
> > > > > > > > > > > > just to clarify the first case, specific to one very particular
> > > > > > > > > > > > property:
> > > > > > > > > > > >
> > > > > > > > > > > > With HDCP, there is a property that may change dynamically at runtime
> > > > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must be notified
> > > > > > > > > > > > when it changes, I do not want userspace have to poll that property
> > > > > > > > > > > > with a timer.
> > > > > > > > > > > >
> > > > > > > > > > > > When that property alone changes, and userspace is prepared to handle
> > > > > > > > > > > > that property changing alone, it must not trigger a reprobe of the
> > > > > > > > > > > > connector. There is no reason to reprobe at that point AFAIU.
> > > > > > > > > > > >
> > > > > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe with the
> > > > > > > > > > > > epoch approach or with any alternate uevent design?
> > > > > > > > > > > >
> > > > > > > > > > > > We need an event to userspace that indicates that re-reading the
> > > > > > > > > > > > properties is enough and reprobe of the connector is not necessary.
> > > > > > > > > > > > This is complementary to indicating to userspace that only some
> > > > > > > > > > > > connectors need to be reprobed instead of everything.
> > > > > > > > > > >
> > > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
> > > > > > > > > > > reprobing. Would that work?
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The replies
> > > > > > > > > to Paul seemed to be going south so fast that I thought we wouldn't get
> > > > > > > > > any new uevent fields in favour of "epoch counters".
> > > > > > > > >
> > > > > > > > > > Yes that's the idea, depending upon which property you get you know
> > > > > > > > > > it's a sink change (needs full reprobe) or something else like hdcp
> > > > > > > > > > state machinery update.
> > > > > > > > >
> > > > > > > > > Right.
> > > > > > > > >
> > > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we should
> > > > > > > > > > indeed decouple that from the per-connector event for sink changes.
> > > > > > > > > > That along is a good win already, since you know for which connector
> > > > > > > > > > you need to call drmGetConnector (which forces the reprobe). It would
> > > > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but
> > > > > > > > > > historically speaking every time we tried to rely on this we ended up
> > > > > > > > > > regretting things.
> > > > > > > > >
> > > > > > > > > What changed? This sounds very much what Paul suggested. Looking at it
> > > > > > > > > from userspace side:
> > > > > > > >
> > > > > > > > This sounds solid, some refinements below:
> > > > > > > >
> > > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > > > > >
> > > > > > > > > - If yy is "Content Protection", no need to drmModeGetConnector(), just
> > > > > > > > >   re-get the connector properties.
> > > > > > > > >
> > > > > > > > > - Kernel probably shouldn't bother sending this for properties where
> > > > > > > > >   re-probe could be necessary, and send the below instead.
> > > > > > > >
> > > > > > > >
> > > > > > > > I think we should assert that the kernel can get the new property
> > > > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the kernel
> > > > > > > > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > > > > > > > to "must"
> > > > > > >
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > ok, that's good.
> > > > > > >
> > > > > > > > Furthermore different property can indicate different kind of updates,
> > > > > > > > e.g. hdcp vs general sink change vs. whatever else might come in the
> > > > > > > > future.
> > > > > > >
> > > > > > > What do you mean by different kinds of updates?
> > > > > >
> > > > > > Atm we're discussing two:
> > > > > >
> > > > > > - "Content Protection"
> > > > > > - "sink changed, but you don't need to reprobe" this would be quite a bit
> > > > > >   a catch all from the output detection. Paul thinks differently, but I'm
> > > > > >   not sold on splitting this up more, at least not right now. This would
> > > > > >   include connector status (and related things returned by drmGetConnector
> > > > > >   which currently aren't a property), EDID, the mst path id, that kind of
> > > > > >   stuff.
> > > > > >
> > > > > > Ime once we have 2, there's more bound to come :-)
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > I don't understand what the "sink changed" thing could be, but sure,
> > > > > there can be more.
> > > >
> > > > So if you have a repeater (hdmi or dp) and you change the thing you plug
> > > > into that, then on the computer you don't get a full hotplug, because the
> > > > repeater was always connected. Instead you get a short pulse hotplug,
> > > > indicating that something with the sink has changed. This could be a
> > > > slightly adjusted EDID (e.g. different eld in the audio section), or
> > > > something else. That's what I mean with "sink changed". Similar thing can
> > > > happen if you unplug and then plug in something else real quick (usually
> > > > over suspend/resume), where connector->status stays the same, but the
> > > > actual thing plugged in is different. I think for hdmi this is just the
> > > > EDID, but we do parse a bunch of things out of the EDID that have further
> > > > effects (color space, max clock). With DP there's also dp aux stuff, e.g.
> > > > if you switch from a 2 lane to a 4 lane cable then with same screen more
> > > > modes can work.
> > > >
> > > > Clearer?
> > > >
> > > > I guess for the documentation for this new uapi we need to make an
> > > > exhaustive list of all the things that might have changed for a "sink
> > > > changed" event, whatever we actually agree on what that should look like.
> > > > Or the PROPERTY=0 fallback you mention below as a fallback idea.
> > >
> > > Hi Daniel,
> > >
> > > to me all that sounds like userspace would better do a probe and start
> > > from scratch with that one connector. Therefore it would fall into the
> > > 'HOTPLUG=1 CONNECTOR=xx' case, no PROPERTY.
> > >
> > > I suppose I'm missing something?
> >
> > Doing a full probe is hella expensive. Atm you always have to do this, but
> > we're talking about the brave new future where the kernel sucks less, and
> > the kernel would have done the expensive probing for you already.
> >
> > > But also I don't mind, I have always expected there might be more
> > > properties whose change does not require a probe.
> > >
> > > So, the kernel does sometimes do the probe on its own as well, right?
> > > Is that completely invisible to userspace, or could it stall some
> > > userspace operations that are not a probe of the same connector?
> >
> > Major stall because the locking design isn't pretty. If the kernel is
> > probing right now even your GetConnectorCurrent or GetProperties (on a
> > connector) will stall for whatever long it takes to read the EDID. Or
> > whatever else the kernel is doing in the probe paths right now. We could
> > probably improve this, and make sure that at least GetConnectorCurrent and
> > GetProperties stop sucking. But needs some serious locking-fu to make that
> > work.
>
> Hi Daniel,
>
> ok. I was assuming the kernel locking was unfixable, due to e.g.
> hardware interfaces that are, well, hardware.
>
> It seems the locking would be the first thing needing to be fixed
> before anyone goes adding more automatic probing into the kernel,
> because otherwise you risk introducing random timing hickups for
> userspace, leading to someone screaming "kernel regression".

There's is fairly fine-grained locking all over kms, except for the
probe path. That has one lock over all connnectors. Only thing we need
to uncouple that from GetConnectorCurrent is to arrange for some
read-only cache of the last probe state (which might not be the
current stuff).

> > Aside: Just realized this is another important reason why we need to batch
> > up property updates. If we don't, then userspace will simply get held up
> > until the kernel is done anyway.
> >
> > > I really think the design of the uAPI must start with how userspace is
> > > expected to react to the events. For that there are three cases:
> > > re-deiscover and probe everyting, re-probe one connector, re-read
> > > properties of one connector without probe. Userspace can then discover
> > > what exactly changed, just like it already does.
> >
> > Yup, I think on this we all agree.
> >
>
> ...
>
> > > > > > > > > --------
> > > > > > > > >
> > > > > > > > > When discussing this in IRC, I had the concern about how uevents are
> > > > > > > > > delivered in userspace. Is there a possibility that they might be
> > > > > > > > > overwritten, contain stale attributes, or get squashed together?
> > > > > > > > >
> > > > > > > > > Particularly if a display server is current on the VT and active and
> > > > > > > > > monitoring udev, but stuck doing something and cannot service uevents
> > > > > > > > > very fast, and the kernel sends more than one event before the process
> > > > > > > > > gets back to dispatching. The terminology in libudev API confused me as
> > > > > > > > > an event is a device. Squashing together would make sense if the
> > > > > > > > > uevent were just updating a device attribute list. Previously when we
> > > > > > > > > had just a single kind of uevent, that would not have made a
> > > > > > > > > difference, but if we gain different kinds of uevents like here, it
> > > > > > > > > starts to matter.
> > > > > > > > >
> > > > > > > > > However, Paul came to the conclusion that we will be ok as long as the
> > > > > > > > > events come via netlink.
> > > > > > > >
> > > > > > > > Yeah netlink shouldn't drop events on the floor I think. It might
> > > > > > > > still happen, but then I think you should get an indication of that
> > > > > > > > error, and you just treat it as a general hotplug event like on older
> > > > > > > > kernels.
> > > > > > >
> > > > > > > Alright, although reading Paul it sounds like there is another
> > > > > > > (fallback?) method as well that wouldn't work. Should userspace worry
> > > > > > > about that?
> > > > > > >
> > > > > > > Hmm, get an indication of an error... I don't know how that would be
> > > > > > > presented in libudev API and I can't point to any code in Weston that
> > > > > > > would deal with it. Does anyone have a clue about that?
> > > > > > >
> > > > > > > Userspace cannot really start taking advantage of any new fine-grained
> > > > > > > hotplug events until it can rely on the event delivery. Granted, this
> > > > > > > seems purely a userspace issue, but I bet it could be formulated as a
> > > > > > > kernel regression: things stop working after upgrading the kernel while
> > > > > > > having always used new userspace which was ready for detailed hotplug
> > > > > > > events but didn't ensure the delivery in userspace.
> > > > > >
> > > > > > You have this already (if it's really an issue with netlink reliability,
> > > > > > tbh no idea), you can already miss a global uevent. It's easier to catch
> > > > > > up if you do miss it, since you're forcing a reprobe on everything. That's
> > > > > > why I think the EPOCH thing would be good, userspace could be defensive
> > > > > > and always call GetConnectorCurrent on all connectors if it gets any
> > > > > > hotplug uevent, and if it gets an EPOCH change, force a reprobe. But I'm
> > > > > > not sure that's really required (aside from VT switching).
> > > > >
> > > > > No, my concern is not an issue with netlink reliability. It is a
> > > > > potential issue when userspace chooses to not use netlink, and uses
> > > > > something else instead. I'm not sure what that else is but Paul says
> > > > > there is code in libudev and that is completely outside the control of
> > > > > KMS apps like display servers.
> > > >
> > > > afaik this other path only exists because it's the older one, for uapi
> > > > backwards compatibility with older userspace. Shouldn't be used for
> > > > anything.
> > >
> > > "Shouldn't be used" and someone screaming "kernel regression"... are you
> > > sure that path won't matter?
> > >
> > > Like some home-brewn distribution that happens to configure their
> > > libudev and kernel to use the old method, uses already new userspace,
> > > and then upgrades the kernel that starts sending fine-grained hotplug
> > > events, resulting the display server randomly handling hotplug wrong.
> > >
> > > Reading Airlie's recent rant about kernel regression handling make this
> > > a scary scenario where you would have no other choice than to rip all
> > > the fine-grained uevents out again.
> > >
> > > Is there any difference in the kernel code between the old method and
> > > the netlink method? Would it be possible to send fine-grained hotplug
> > > events only through netlink, and fall back to the old 'HOTPLUG=1' for
> > > the old method?
> >
> > There's a lot of grey in kernel regressions, and for fringe setups used by
> > few people I wouldn't worry about this. If they expect their shit to keep
> > working when using new stuff and crappy old interfaces, they get to keep
> > all the pieces.
>
> It didn't sound gray at all, reading Dave Airlie's email about it. If
> someone updates the kernel, and something works worse after that, then
> it is by definition a kernel regression. Period. And the earliest
> regression wins, i.e. if a revert breaks other things, the revert will
> be done regardless.
>
> > Dave's recent rant was a bit special, since userspace is clearly smoking
> > some strong stuff (-modesetting's atomic is seriously not using atomic
> > correctly), but it was also affecting too many people, and changing the
> > boot setup meant you'd get a black screen on boot-up already. Instead of
> > just on the first modeset with more than 1 screen.
>
> Then I think I missed the context of Dave's email. Reading it again, I
> still do not see that context.
>
> Btw. how do you determine "not using atomic correctly"? Has some uAPI
> specification for atomic appeared? I wasn't aware there was any uAPI
> specs, so there is no "incorrect use" if it happened to work once.

-modesetting atomic blows up with more than one screen (even if you
just move that screen between crtc). The breakage was that with the
fastboot changes we've put the one screen onto crtc 1, but by default
modesetting wants it on crtc 0, and it couldn't do that switch
anymore.

All current atomic in -modesetting can do is pageflip and dpms off/on
on the first screen on the first crtc. Anything more fancy goes boom,
like where you change the connector/crtc links.

It's _really_ broken :-)

> I don't personally really like these rules, but if these are the rules,
> then so be it. In my opinion it would be a huge step forward to get and
> require uAPI specifications, that people could verify both kernel and
> userspace against. Verifying against kernel code with no spec is what
> leads to the -modesetting issue by the sounds of it.
>
> Documenting kernel internal interfaces is not it. People reading
> DRM internal interface docs would need to know how DRM works internally
> before they could map that information into uAPI, which makes it less
> useful if not even useless for userspace developers.

vgem is the idea here for validation, but if people ship atomic code
that was never tested except for "boots on my laptop", then nothing is
going to help.

And yes we have a huge gap with uapi documentation. btw for properties
those section are meant to be useful for userspace people too:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties

and all subsequent chapters. I guess it's a bit burried, but this part
is meant to be the uapi spec for properties. Is that also failing your
expectations?

> > There's also a fairly easy fix for that -modesetting issue: We don't
> > expose atomic if the compositor has a process name of "Xserver". Brutal,
> > but gets the job done. Once X is fixed, we can give a new "I'm not totally
> > broken anymore" interface to get back at atomic.
>
> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
> check against the process issuing ioctl by ioctl, or the process that
> opened the device? Which would be logind? What about DRM leasing? ...

In the Get/SetCaps ioctl we can do the check, which is called from X,
not logind. We just need some way to tell -modesetting apart from
everything else, and luckily there's not any other atomic X drivers.

> > tldr; I'm not worried at all, at least not more than with anything uapi.
> > Very rarely we'll have regrets.
>
> If you say so, ok. I'm a pessimist. I will certainly be happy if people
> can make progress with fine-grained uevents.

Maybe I've been suffering this for too long :-)
-Daniel

On Tue, May 21, 2019 at 12:01:29PM +0300, Pekka Paalanen wrote:
> Hi Daniel,
> 
> what says the assumption of the only monitor being driven by CRTC 0
> was a bad one? :-p
> 
> It's probably not obvious that userspace needs to explicitly try to
> avoid invalid configuration combinations by inspecting the current full
> configuration and not just the one CRTC/connector it wants to use.

Well the entire point of atomic is that you do set the entire config. The
-modesetting atomic conversation tried to just use the atomic ioctl by 1:1
replacing legacy ioctl calls, and they screwed things up.

If it would have applied the entire configuration in one go, it would
work.

> > All current atomic in -modesetting can do is pageflip and dpms off/on
> > on the first screen on the first crtc. Anything more fancy goes boom,
> > like where you change the connector/crtc links.
> > 
> > It's _really_ broken :-)
> 
> But it worked exactly that much, until a kernel change broke it, right?
> Yes, I totally see the sillyness, but if it worked and we have these
> no-regression rules...

Which is why the offending patch has been reverted. Any the way forward is
to just disable atomic from the kernel for X.org, because the legacy path
actually works. We also have patches to disable atomic in -modesetting,
but they're stuck.

> > > I don't personally really like these rules, but if these are the rules,
> > > then so be it. In my opinion it would be a huge step forward to get and
> > > require uAPI specifications, that people could verify both kernel and
> > > userspace against. Verifying against kernel code with no spec is what
> > > leads to the -modesetting issue by the sounds of it.
> > >
> > > Documenting kernel internal interfaces is not it. People reading
> > > DRM internal interface docs would need to know how DRM works internally
> > > before they could map that information into uAPI, which makes it less
> > > useful if not even useless for userspace developers.  
> > 
> > vgem is the idea here for validation, but if people ship atomic code
> > that was never tested except for "boots on my laptop", then nothing is
> > going to help.
> 
> A testing pattern library with vkms would be awesome indeed.
> 
> > And yes we have a huge gap with uapi documentation. btw for properties
> > those section are meant to be useful for userspace people too:
> > 
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
> > 
> > and all subsequent chapters. I guess it's a bit burried, but this part
> > is meant to be the uapi spec for properties. Is that also failing your
> > expectations?
> 
> Yes: it is hard to find (it is in Driver Developer's Guide, buried
> several chapters in), it is interleaved with lots of DRM internal
> details, makes references to DRM internal functions, and probably
> relies on DRM internals behaviour through the references by not
> repeating what they do.
> 
> It is useful once you find it, but I don't think it's enough for making
> good use in userspace for someone who hasn't been a DRM kernel
> developer.

Summarizing our long irc chat on this: I agree, everyone else agrees, but
it's a question of making it happen and having someone with sufficient
tech writer experience to make it useful.

What we have now is essentially what happens if I type uapi specs (I
pushed for these property docs). As you can see, it ain't pretty :-/

I think at least the process v4l has, where missing docs for uapi causes
the doc build to fail, is sound. I have no idea how to adapt that to what
we do, both from a "this will take a few years to fill the gaps and I
don't know how to write good specs" and more implementation pov -
properties can be created anywhere, no changes to include/uapi required.
So hard to spot automatically.

Cheers, Daniel
On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>> On Mon, 20 May 2019 18:11:07 +0200
>> Daniel Vetter <daniel@ffwll.ch> wrote:
>>
>>> There's also a fairly easy fix for that -modesetting issue: We don't
>>> expose atomic if the compositor has a process name of "Xserver". Brutal,
>>> but gets the job done. Once X is fixed, we can give a new "I'm not totally
>>> broken anymore" interface to get back at atomic.
>>
>> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
>> check against the process issuing ioctl by ioctl, or the process that
>> opened the device? Which would be logind? What about DRM leasing? ...
> 
> In the Get/SetCaps ioctl we can do the check, which is called from X,
> not logind. We just need some way to tell -modesetting apart from
> everything else, and luckily there's not any other atomic X drivers.

Not yet...

As for a "I'm not totally broken anymore" interface, we did something
like that (though kind of in the other direction) with
RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
be added, because the former claimed acceleration was "working" in cases
where it really wasn't... That kind of thing could become ugly in the
long run if other Xorg driver start using atomic, and they'll inevitably
be broken in different ways.
On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >> On Mon, 20 May 2019 18:11:07 +0200
> >> Daniel Vetter <daniel@ffwll.ch> wrote:
> >>
> >>> There's also a fairly easy fix for that -modesetting issue: We don't
> >>> expose atomic if the compositor has a process name of "Xserver". Brutal,
> >>> but gets the job done. Once X is fixed, we can give a new "I'm not totally
> >>> broken anymore" interface to get back at atomic.
> >>
> >> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
> >> check against the process issuing ioctl by ioctl, or the process that
> >> opened the device? Which would be logind? What about DRM leasing? ...
> > 
> > In the Get/SetCaps ioctl we can do the check, which is called from X,
> > not logind. We just need some way to tell -modesetting apart from
> > everything else, and luckily there's not any other atomic X drivers.
> 
> Not yet...
> 
> As for a "I'm not totally broken anymore" interface, we did something
> like that (though kind of in the other direction) with
> RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
> be added, because the former claimed acceleration was "working" in cases
> where it really wasn't... That kind of thing could become ugly in the
> long run if other Xorg driver start using atomic, and they'll inevitably
> be broken in different ways.

It's definitely a very suboptimal situation. Not sure there's a good way
out. The trouble here is that i915 ended up configuring crtc/connectors
differently than -modesetting (to allow fastboot, which I think is still
i915 exclusive). This then highlighted that modesetting can't do atomic
modesets if you try to reassign connectors.

One idea I have is that vgms would help compositors to play out a bunch of
standard scenarios, even automated. But that's not there yet, and every
compositor project needs to care beyond "boots on my laptop, ship it". No
idea that's even possible.
-Daniel
On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote:
> On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:

> > On 2019-05-21 9:52 a.m., Daniel Vetter wrote:

> > > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:

> > > > On Mon, 20 May 2019 18:11:07 +0200

> > > > Daniel Vetter <daniel@ffwll.ch> wrote:

> > > > 

> > > > > There's also a fairly easy fix for that -modesetting issue: We don't

> > > > > expose atomic if the compositor has a process name of "Xserver". Brutal,

> > > > > but gets the job done. Once X is fixed, we can give a new "I'm not totally

> > > > > broken anymore" interface to get back at atomic.

> > > > 

> > > > You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you

> > > > check against the process issuing ioctl by ioctl, or the process that

> > > > opened the device? Which would be logind? What about DRM leasing? ...

> > > 

> > > In the Get/SetCaps ioctl we can do the check, which is called from X,

> > > not logind. We just need some way to tell -modesetting apart from

> > > everything else, and luckily there's not any other atomic X drivers.

> > 

> > Not yet...

> > 

> > As for a "I'm not totally broken anymore" interface, we did something

> > like that (though kind of in the other direction) with

> > RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to

> > be added, because the former claimed acceleration was "working" in cases

> > where it really wasn't... That kind of thing could become ugly in the

> > long run if other Xorg driver start using atomic, and they'll inevitably

> > be broken in different ways.

> 

> It's definitely a very suboptimal situation. Not sure there's a good way

> out. The trouble here is that i915 ended up configuring crtc/connectors

> differently than -modesetting (to allow fastboot, which I think is still

> i915 exclusive). This then highlighted that modesetting can't do atomic

> modesets if you try to reassign connectors.

> 

> One idea I have is that vgms would help compositors to play out a bunch of


Just so people aren't confused: I think Daniel meant "vkms" here :P

> standard scenarios, even automated. But that's not there yet, and every

> compositor project needs to care beyond "boots on my laptop, ship it". No

> idea that's even possible.


Having documentation for userspace is also important IMHO.

Regarding automated compositor testing, it's probably not possible to
have a single place where all compositors are tested: vkms should
probably be included as part of their CI. Thoughts?

Anyway, we could start a discussion to see if compositor people are
interested. Or have you already talked to some compositor maintainers?

On 2019-07-04 at 14:12:27 +0300, Pekka Paalanen wrote:
> On Tue,  7 May 2019 21:57:43 +0530
> Ramalingam C <ramalingam.c@intel.com> wrote:
> 
> > DRM API for generating uevent for a status changes of connector's
> > property.
> > 
> > This uevent will have following details related to the status change:
> > 
> >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > 
> > Need ACK from this uevent from userspace consumer.
> > 
> > v2:
> >   Minor fixes at KDoc comments [Daniel]
> > v3:
> >   Check the property is really attached with connector [Daniel]
> > 
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> >  drivers/gpu/drm/drm_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> >  include/drm/drm_sysfs.h     |  5 ++++-
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 18b1ac442997..63fa951a20db 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -21,6 +21,7 @@
> >  #include <drm/drm_sysfs.h>
> >  #include <drm/drmP.h>
> >  #include "drm_internal.h"
> > +#include "drm_crtc_internal.h"
> >  
> >  #define to_drm_minor(d) dev_get_drvdata(d)
> >  #define to_drm_connector(d) dev_get_drvdata(d)
> > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> >   * deal with other types of events.
> > + *
> > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > + * for uevents on connector status change.
> >   */
> >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  {
> > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> >  
> > +/**
> > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > + * property status change
> > + * @connector: connector on which property status changed
> > + * @property: connector property whoes status changed.
> > + *
> > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > + * set HOTPLUG=1 and connector id along with the attached property id
> > + * related to the status change.
> > + */
This is the kernel doc added for drm_sysfs_connector_status_event()
similar to drm_sysfs_hotplug_event()

-Ram
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > +				      struct drm_property *property)
> > +{
> > +	struct drm_device *dev = connector->dev;
> > +	char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > +	char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > +
> > +	WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
> > +					   property->base.id));
> > +
> > +	snprintf(conn_id, ARRAY_SIZE(conn_id),
> > +		 "CONNECTOR=%u", connector->base.id);
> > +	snprintf(prop_id, ARRAY_SIZE(prop_id),
> > +		 "PROPERTY=%u", property->base.id);
> > +
> > +	DRM_DEBUG("generating connector status event\n");
> > +
> > +	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> > +}
> > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > +
> >  static void drm_sysfs_release(struct device *dev)
> >  {
> >  	kfree(dev);
> > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > index 4f311e836cdc..d454ef617b2c 100644
> > --- a/include/drm/drm_sysfs.h
> > +++ b/include/drm/drm_sysfs.h
> > @@ -4,10 +4,13 @@
> >  
> >  struct drm_device;
> >  struct device;
> > +struct drm_connector;
> > +struct drm_property;
> >  
> >  int drm_class_device_register(struct device *dev);
> >  void drm_class_device_unregister(struct device *dev);
> >  
> >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > -
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > +				      struct drm_property *property);
> >  #endif
> 
> Hi,
> 
> this patch is completely missing the UAPI documentation.
> 
> Weston in
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
> does have good looking code to parse this event.
> 
> 
> Thanks,
> pq