| Message ID | 20190507162745.25600-10-ramalingam.c@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | HDCP2.2 Phase II | expand |
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 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. Thanks, pq
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 >
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. Thanks, pq
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
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. 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. 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. > > 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? 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
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 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. > > 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. > > > > 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 :-/ 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. 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? Thanks, pq
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 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? 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? 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. > > > > 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. 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? 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. > 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? > > 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. Thanks, pq
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 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". > 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. 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. > 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? ... > 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. Thanks, pq
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, 21 May 2019 09:52:50 +0200 Daniel Vetter <daniel@ffwll.ch> 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: > > > > > 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: ... > > > > > > 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. 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. > 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... > > 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. Thanks, pq
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 Mon, 3 Jun 2019 15:19:13 +0000 "Ser, Simon" <simon.ser@intel.com> wrote: > On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote: > > 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? FWIW, I would absolutely *love* to be able to exercise Weston's DRM-backend in Gitlab CI with anything, even just vkms, at least in Weston's test suite to test Weston against KMS in general. Once that is up, kernel people could replicate from that to their own CI for testing drivers against known userspace. I think it would be an awesome long term plan, whether uAPI specs appear or not. Long term, because I have no idea who could work on it when. In theory, all I would be waiting for is for vkms to be just featureful enough and to figure out a way how to get that running inside Gitlab CI. Thanks, pq
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
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. > + */ > +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
On Thu, 4 Jul 2019 16:12:10 +0530 Ramalingam C <ramalingam.c@intel.com> wrote: > 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() Hi, yes, it is the kernel internal doc. An UAPI doc would spell out the attributes "CONNECTOR" and "PROPERTY" and describe their values explaining what they are, instead of decsribing a kernel-internal function arguments. However, as discussed, we cannot have UAPI docs at this time, so I guess this is the best we can have. Thanks, pq > > > +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 > >
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