drm: add connector info/property for non-std displays

From: Dave Airlie <[email protected]>

This uses the EDID info from my HTC Vive to mark it as non-standard.

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

Quoted 9 lines · Dave Airlie

From: Dave Airlie <[email protected]>

This uses the EDID info from my HTC Vive to mark it as non-standard.

Signed-off-by Dave Airlie <[email protected]>

---
  drivers/gpu/drm/drm_edid.c | 3 +++
  1 file changed, 3 insertions(+)

I guess I was being naive for thinking that HMDs would come with a special EDID extension. Google indicates that someone might have worked on something called HMD-EXT to be standardized by VESA for EDID, but no documents seem to exist for that.

Thierry

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

Quoted 11 lines · Dave Airlie

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Quoted 7 lines

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

"non-standard" seems very ambiguous to me. If this is targetting HMDs in particular, perhaps we can borrow a term from that. Without being really familiar with that technology, a quick Google search suggests that these devices are commonly referred to as operating in "direct mode". Perhaps a boolean "direct-mode" property would be less ambiguous?

Quoted 20 lines · Thierry Reding

Quoted 11 lines · Dave Airlie

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Quoted 7 lines

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

Quoted 5 lines

"non-standard" seems very ambiguous to me. If this is targetting HMDs in particular, perhaps we can borrow a term from that. Without being really familiar with that technology, a quick Google search suggests that these devices are commonly referred to as operating in "direct mode". Perhaps a boolean "direct-mode" property would be less ambiguous?

I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic features to specific technologies if we can avoid it, there may be other requirements for connected displays we don't want to display on without some special app that aren't HMDs.

I agree non-standard is a bit ambiguous, but I'm not happy direct mode gives me any more useful info, anyone else got a name?

Quoted 32 lines · Dave Airlie

Quoted 20 lines · Thierry Reding

Quoted 11 lines · Dave Airlie

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Quoted 7 lines

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

Quoted 5 lines

"non-standard" seems very ambiguous to me. If this is targetting HMDs in particular, perhaps we can borrow a term from that. Without being really familiar with that technology, a quick Google search suggests that these devices are commonly referred to as operating in "direct mode". Perhaps a boolean "direct-mode" property would be less ambiguous?

I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic features to specific technologies if we can avoid it, there may be other requirements for connected displays we don't want to display on without some special app that aren't HMDs.

Quoted 2 lines

I agree non-standard is a bit ambiguous, but I'm not happy direct mode gives me any more useful info, anyone else got a name?

I'd have just gone with HMD. We're really bad at predicting the future, every time we try to make things a bit too generic it bites us. And think for leases it makes sense (since people are already talking about other uses than just HMD pass-through), but for this prop, not so much.

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 31 lines · Daniel Vetter

Quoted 30 lines · Dave Airlie

Quoted 19 lines · Thierry Reding

Quoted 11 lines · Dave Airlie

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Quoted 7 lines

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

Quoted 5 lines

"non-standard" seems very ambiguous to me. If this is targetting HMDs in particular, perhaps we can borrow a term from that. Without being really familiar with that technology, a quick Google search suggests that these devices are commonly referred to as operating in "direct mode". Perhaps a boolean "direct-mode" property would be less ambiguous?

I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic features to specific technologies if we can avoid it, there may be other requirements for connected displays we don't want to display on without some special app that aren't HMDs.

Quoted 6 lines

Quoted 2 lines

I agree non-standard is a bit ambiguous, but I'm not happy direct mode gives me any more useful info, anyone else got a name?

I'd have just gone with HMD. We're really bad at predicting the future, every time we try to make things a bit too generic it bites us. And think for leases it makes sense (since people are already talking about other uses than just HMD pass-through), but for this prop, not so much.

I'd vote for HMD too. non-standard is too ambiguous.

Alex

Quoted 9 lines

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 38 lines · Alex Deucher

Quoted 37 lines · Daniel Vetter

Quoted 25 lines · Dave Airlie

Quoted 19 lines · Thierry Reding

Quoted 11 lines · Dave Airlie

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Quoted 7 lines

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

Quoted 5 lines

"non-standard" seems very ambiguous to me. If this is targetting HMDs in particular, perhaps we can borrow a term from that. Without being really familiar with that technology, a quick Google search suggests that these devices are commonly referred to as operating in "direct mode". Perhaps a boolean "direct-mode" property would be less ambiguous?

Quoted 7 lines

I'm not sure direct-mode is any less ambiguous, I'm loathe to tie generic features to specific technologies if we can avoid it, there may be other requirements for connected displays we don't want to display on without some special app that aren't HMDs.

I agree non-standard is a bit ambiguous, but I'm not happy direct mode gives me any more useful info, anyone else got a name?

I'd have just gone with HMD. We're really bad at predicting the future, every time we try to make things a bit too generic it bites us. And think for leases it makes sense (since people are already talking about other uses than just HMD pass-through), but for this prop, not so much.

Quoted 1 line

I'd vote for HMD too. non-standard is too ambiguous.

Wouldn't then be better then to add some enum property with "HMD" as one of values.
On the other side this property is currently used just to prevent fb creation, what about naming property after its purpose? non-fb, non-console, ...whatever.

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

drivers/gpu/drm/drm_connector.c +13 -0

index 704fc8934616..50a176483619 100644
@@ -234,6 +234,10 @@ int drm_connector_init(struct drm_device *dev,
 				   config->link_status_property,
 				   0);
 
+	drm_object_attach_property(&connector->base,
+				   config->non_std_display_property,
+				   0);
+
 	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
 		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
 	}

@@ -811,6 +815,11 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.link_status_property = prop;
 
+	prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, "non_standard");
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.non_std_display_property = prop;
+
 	return 0;
 }
 

@@ -1194,6 +1203,10 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 	if (edid)
 		size = EDID_LENGTH * (1 + edid->extensions);
 
+	drm_object_property_set_value(&connector->base,
+				      dev->mode_config.non_std_display_property,
+				      connector->display_info.non_std);
+
 	ret = drm_property_replace_global_blob(dev,
 					       &connector->edid_blob_ptr,
 	                                       size,

drivers/gpu/drm/drm_edid.c +6 -2

index 00ddabfbf980..4225052def37 100644
@@ -82,6 +82,8 @@
 #define EDID_QUIRK_FORCE_6BPC			(1 << 10)
 /* Force 10bpc */
 #define EDID_QUIRK_FORCE_10BPC			(1 << 11)
+/* Non standard display device (i.e. HMD) */
+#define EDID_QUIRK_NON_STD_DEVICE               (1 << 12)
 
 struct detailed_mode_closure {
 	struct drm_connector *connector;

@@ -4393,7 +4395,7 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
 }
 
 static void drm_add_display_info(struct drm_connector *connector,
-				 struct edid *edid)
+				 struct edid *edid, u32 quirks)
 {
 	struct drm_display_info *info = &connector->display_info;
 

@@ -4407,6 +4409,8 @@ static void drm_add_display_info(struct drm_connector *connector,
 	info->max_tmds_clock = 0;
 	info->dvi_dual = false;
 
+	info->non_std = !!(quirks & EDID_QUIRK_NON_STD_DEVICE);
+
 	if (edid->revision < 3)
 		return;
 

@@ -4627,7 +4631,7 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
 	 * To avoid multiple parsing of same block, lets parse that map
 	 * from sink info, before parsing CEA modes.
 	 */
-	drm_add_display_info(connector, edid);
+	drm_add_display_info(connector, edid, quirks);
 
 	/*
 	 * EDID spec says modes should be preferred in this order:

include/drm/drm_connector.h +5 -0

index b4285c40e1e4..5c3a1667458b 100644
@@ -284,6 +284,11 @@ struct drm_display_info {
 	 * @hdmi: advance features of a HDMI sink.
 	 */
 	struct drm_hdmi_info hdmi;
+
+	/**
+	 * @non_std: Non standard display device (HMD).
+	 */
+	bool non_std;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,

include/drm/drm_mode_config.h +7 -0

index 0b4ac2ebc610..a5a44aeccff4 100644
@@ -728,6 +728,13 @@ struct drm_mode_config {
 	 */
 	struct drm_property *suggested_y_property;
 
+	/**
+	 * @non_std_display_property: Optional connector property with a hint
+	 * that device isn't a standard display, and the console/desktop,
+	 * should not be displayed on it.
+	 */
+	struct drm_property *non_std_display_property;
+
 	/* dumb ioctl parameters */
 	uint32_t preferred_depth, prefer_shadow;
 

Signature · 6 lines

2.14.2

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

From: Dave Airlie <[email protected]>

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Signed-off-by Dave Airlie <[email protected]>

---
 drivers/gpu/drm/drm_connector.c | 13 +++++++++++++
 drivers/gpu/drm/drm_edid.c      |  8 ++++++--
 include/drm/drm_connector.h     |  5 +++++
 include/drm/drm_mode_config.h   |  7 +++++++
 4 files changed, 31 insertions(+), 2 deletions(-)

drivers/gpu/drm/drm_connector.c +4 -0

index 704fc8934616..50a176483619 100644
@@ -234,6 +234,10 @@ int drm_connector_init(struct drm_device *dev,
 				   config->link_status_property,
 				   0);
 
+	drm_object_attach_property(&connector->base,
+				   config->non_std_display_property,
+				   0);
+
 	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
 		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
 	}

drivers/gpu/drm/drm_connector.c +8 -0

+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.non_std_display_property = prop;
+
 	return 0;
 }
 

@@ -1194,6 +1203,10 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 	if (edid)
 		size = EDID_LENGTH * (1 + edid->extensions);
 
+	drm_object_property_set_value(&connector->base,
+				      dev->mode_config.non_std_display_property,
+				      connector->display_info.non_std);
+
 	ret = drm_property_replace_global_blob(dev,
 					       &connector->edid_blob_ptr,
 	                                       size,

drivers/gpu/drm/drm_edid.c +3 -1

index 00ddabfbf980..4225052def37 100644
@@ -82,6 +82,8 @@
 #define EDID_QUIRK_FORCE_6BPC			(1 << 10)
 /* Force 10bpc */
 #define EDID_QUIRK_FORCE_10BPC			(1 << 11)
+/* Non standard display device (i.e. HMD) */
+#define EDID_QUIRK_NON_STD_DEVICE               (1 << 12)
 
 struct detailed_mode_closure {
 	struct drm_connector *connector;

@@ -4393,7 +4395,7 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
 }
 
 static void drm_add_display_info(struct drm_connector *connector,
-				 struct edid *edid)
+				 struct edid *edid, u32 quirks)
 {
 	struct drm_display_info *info = &connector->display_info;
 

drivers/gpu/drm/drm_edid.c +2 -1

+
 	if (edid->revision < 3)
 		return;
 

@@ -4627,7 +4631,7 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
 	 * To avoid multiple parsing of same block, lets parse that map
 	 * from sink info, before parsing CEA modes.
 	 */
-	drm_add_display_info(connector, edid);
+	drm_add_display_info(connector, edid, quirks);
 
 	/*
 	 * EDID spec says modes should be preferred in this order:

include/drm/drm_connector.h +5 -0

index b4285c40e1e4..5c3a1667458b 100644
@@ -284,6 +284,11 @@ struct drm_display_info {
 	 * @hdmi: advance features of a HDMI sink.
 	 */
 	struct drm_hdmi_info hdmi;
+
+	/**
+	 * @non_std: Non standard display device (HMD).
+	 */
+	bool non_std;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,

include/drm/drm_mode_config.h +7 -0

index 0b4ac2ebc610..a5a44aeccff4 100644
@@ -728,6 +728,13 @@ struct drm_mode_config {
 	 */
 	struct drm_property *suggested_y_property;
 
+	/**
+	 * @non_std_display_property: Optional connector property with a hint
+	 * that device isn't a standard display, and the console/desktop,
+	 * should not be displayed on it.
+	 */
+	struct drm_property *non_std_display_property;
+
 	/* dumb ioctl parameters */
 	uint32_t preferred_depth, prefer_shadow;

This adds the infrastructure needed to quirk displays using edid and to mark them a non-standard.

A non-standard display is one which doesn't work like a normal rectangular monitor or requires some transformation of the output by the rendering process to make sense.

This is meant to cover head mounted devices like HTC Vive.

Why not add a client cap which hides 'non-standard' displays completely from non-aware clients? That way you can keep the connected status as is, and clients either never see the HMD or will be able to check the property.

Either way, I'm still not convinced doing this in the kernel makes any sense.

We need the shared EDID library anyway in order to deal with the quirk tables replicated between the kernel/Xorg currently, so that's going to happen pretty soon regardless of whether or not the kernel gets its own database.

Quoted 4 lines · Daniel Stone

Why not add a client cap which hides 'non-standard' displays completely from non-aware clients? That way you can keep the connected status as is, and clients either never see the HMD or will be able to check the property.

Most clients are display servers, and it looks like we're settling on using the display server as the way to enumerate all of the displays (as direct enumeration through DRM non-master FDs involve rather drastic permissions changes in the kernel).

This means that display servers are going to have to change to both see these displays while keeping them from being part of the desktop. So, while I guess it might be useful to hide HMD from existing display servers with a bit like this, I don't think there's any particular long-term benefit?

Quoted 2 lines

Either way, I'm still not convinced doing this in the kernel makes any sense.

fbdev. We want to keep the HMD dark until there's something 'real' to show on it.

If you accept that fbdev needs to know this, then there's no way to avoid maintaining a database in the kernel. Maybe what we need is some way to load additional database entries into the kernel at boot time from a file in the initrd? And if you want a user-space database too, then maybe the kernel data should be generated from that and dumped into the initrd? One version of the truth is hard enough to deal with; I'd hate to have two.

Quoted 4 lines

We need the shared EDID library anyway in order to deal with the quirk tables replicated between the kernel/Xorg currently, so that's going to happen pretty soon regardless of whether or not the kernel gets its own database.

Yeah, we'll presumably need this support in the Vulkan KHR_display extension too, so sharing EDID support up in user space between all of these entities seems like a great idea.

Hi,

Quoted 11 lines · Keith Packard

Quoted 4 lines · Daniel Stone

Why not add a client cap which hides 'non-standard' displays completely from non-aware clients? That way you can keep the connected status as is, and clients either never see the HMD or will be able to check the property.

Most clients are display servers, and it looks like we're settling on using the display server as the way to enumerate all of the displays (as direct enumeration through DRM non-master FDs involve rather drastic permissions changes in the kernel).

Quoted 5 lines

This means that display servers are going to have to change to both see these displays while keeping them from being part of the desktop. So, while I guess it might be useful to hide HMD from existing display servers with a bit like this, I don't think there's any particular long-term benefit?

I totally agree with you. On the other hand, this gives symmetry to making sure we don't put fbcon into someone's retinas: if we're doing that, why not also hide it from legacy userspace which isn't going to be aware of HMD characteristics?