Message ID | 20171025063023.12584-1-airlied@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hi, On 25 October 2017 at 07:30, Dave Airlie <airlied@gmail.com> wrote: > This adds the infrastructure needed to quirk displays > using edid and to mark them as non-desktop to denote > that userspace shouldn't display a standard desktop on them. > > A non-desktop 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. I still think putting these behind a client cap is a good idea: https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html Cheers, Daniel
On 25 October 2017 at 21:15, Daniel Stone <daniel@fooishbar.org> wrote: > Hi, > > On 25 October 2017 at 07:30, Dave Airlie <airlied@gmail.com> wrote: >> This adds the infrastructure needed to quirk displays >> using edid and to mark them as non-desktop to denote >> that userspace shouldn't display a standard desktop on them. >> >> A non-desktop 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. > > I still think putting these behind a client cap is a good idea: > https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html We want the X server to see these. How else can someone discover there's a HMD plugged in? So a client cap doesn't make any sense. Dave.
On 26 October 2017 at 05:24, Dave Airlie <airlied@gmail.com> wrote: > On 25 October 2017 at 21:15, Daniel Stone <daniel@fooishbar.org> wrote: >> Hi, >> >> On 25 October 2017 at 07:30, Dave Airlie <airlied@gmail.com> wrote: >>> This adds the infrastructure needed to quirk displays >>> using edid and to mark them as non-desktop to denote >>> that userspace shouldn't display a standard desktop on them. >>> >>> A non-desktop 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. >> >> I still think putting these behind a client cap is a good idea: >> https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html > > We want the X server to see these. How else can someone discover > there's a HMD plugged in? > > So a client cap doesn't make any sense. Userspace also doesn't help with getting the console off these and not having them upset your other fbcon monitor, if someone invents a userspace database and gets it into X.org/mutter/<list of wayland compositors> then I'm happy to use it. Dave.
Daniel Stone <daniel@fooishbar.org> writes: > I still think putting these behind a client cap is a good idea: > https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html Assuming that everyone eventually catches up, this should be a short-term issue. So, all we have to do is figure out how to make the transition, which seems a lot less weighty than something that will affect the environment for a long time. We need to consider the cross-version compatibility issues for both the window system and the kernel. That means an old window system with new kernel or new window system with old kernel should work as well as it does today. Today, an HMD display is presented as a normal output and applications can discover it through the window system and present an image on it by placing their image at the right location on the screen. To keep that working, we can't hide HMD outputs from an older window system.
On Wed, Oct 25, 2017 at 01:23:58PM -0700, Keith Packard wrote: > Daniel Stone <daniel@fooishbar.org> writes: > > > I still think putting these behind a client cap is a good idea: > > https://lists.freedesktop.org/archives/dri-devel/2017-October/155616.html > > Assuming that everyone eventually catches up, this should be a > short-term issue. So, all we have to do is figure out how to make the > transition, which seems a lot less weighty than something that will > affect the environment for a long time. > > We need to consider the cross-version compatibility issues for both the > window system and the kernel. That means an old window system with new > kernel or new window system with old kernel should work as well as it > does today. > > Today, an HMD display is presented as a normal output and applications > can discover it through the window system and present an image on it by > placing their image at the right location on the screen. To keep that > working, we can't hide HMD outputs from an older window system. Yeah we add flags when old userspace would get more broken by this. If old/existing userspace is handling stuff incorrectly already, there's no need to flag that it now works better, and hiding by default seems to have issues too. In case of doubt I'll opt for less uapi, anytime that's possible :-) So my vote on no opt-in flag needed here. -Daniel
On Wed, 2017-10-25 at 16:30 +1000, Dave Airlie wrote: > From: Dave Airlie <airlied@redhat.com> > > This adds the infrastructure needed to quirk displays > using edid and to mark them as non-desktop to denote > that userspace shouldn't display a standard desktop on them. > > A non-desktop 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 <airlied@redhat.com> > --- > 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(-) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 704fc89..f9d3538 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -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_desktop_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-desktop"); How to deal with devices that may switch to non-desktop mode dynamically during runtime, such as PSVR (I don't know if there are or will be others)? The PSVR connection box initially (in "cinematic mode") passes through its HDMI input to its external HDMI output unchanged and renders the input image as a floating plane on the HMD. The pass-through HDMI output may be connected to the system's only monitor, therefor PSVR doesn't belong in the drm_edid non-desktop quirk list during boot. Via USB commands the connection box can be switched to "VR mode", where it passes through its HDMI input to the HMD and renders a re-undistorted version of one of the eye views to its HDMI output. Should the non-desktop property be made mutable for such devices, or should this just be left to userspace completely, keeping them non-desktop=false? regards Philipp
This is the same as the series for non-standard displays but uses the phrase 'non-desktop' instead. No functional changes.
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 704fc89..f9d3538 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -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_desktop_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-desktop"); + if (!prop) + return -ENOMEM; + dev->mode_config.non_desktop_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_desktop_property, + connector->display_info.non_desktop); + ret = drm_property_replace_global_blob(dev, &connector->edid_blob_ptr, size, diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 00ddabf..1e24d5d9 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -82,6 +82,8 @@ #define EDID_QUIRK_FORCE_6BPC (1 << 10) /* Force 10bpc */ #define EDID_QUIRK_FORCE_10BPC (1 << 11) +/* Non desktop display (i.e. HMD) */ +#define EDID_QUIRK_NON_DESKTOP (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_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP); + 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: diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index b4285c40..7fcfc57 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -284,6 +284,11 @@ struct drm_display_info { * @hdmi: advance features of a HDMI sink. */ struct drm_hdmi_info hdmi; + + /** + * @non_desktop: Non desktop display (HMD). + */ + bool non_desktop; }; int drm_display_info_set_bus_formats(struct drm_display_info *info, diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index 0b4ac2e..b21e827 100644 --- a/include/drm/drm_mode_config.h +++ b/include/drm/drm_mode_config.h @@ -728,6 +728,13 @@ struct drm_mode_config { */ struct drm_property *suggested_y_property; + /** + * @non_desktop_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_desktop_property; + /* dumb ioctl parameters */ uint32_t preferred_depth, prefer_shadow;