From: Michael Thayer <michael.thayer@oracle.com>
To: dri-devel@lists.freedesktop.org
Cc: Michael Thayer <michael.thayer@oracle.com>,
kraxel@redhat.com, daniel.vetter@intel.com
Subject: [PATCH] drm: remove immutable flag from suggested X/Y connector properties
Date: Tue, 20 Dec 2016 11:38:52 +0100 [thread overview]
Message-ID: <20161220103852.30963-1-michael.thayer@oracle.com> (raw)
The suggested X and Y connector properties are intended as a way for drivers
for virtual machine GPUs to provide information about the layout of the
host system windows (or whatever) corresponding to given guest connectors.
The intention is for the guest system to lay out screens in the virtual
desktop in a way which reflects the host layout. Sometimes though the guest
system chooses not to follow those hints, usually due to user requests. In
this case it is useful to be able to pass information back about the actual
layout chosen.
The immediate use case for this is host-to-guest pointer input mapping.
Qemu, VirtualBox and VMWare currently handle this by providing an emulated
graphics tablet device to the guest. libinput defaults, as did X.Org before
it used libinput, to mapping the position information reported by the device
to the smallest rectangle enclosing the screen layout. Knowing that layout
lets the hypervisor send the right position information through the input
device.
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
---
Follow-up to thread "Passing multi-screen layout to KMS driver". In that
thread, Gerd suggested an alternative way of solving the use case, namely
emulating one input device per virtual screen, touchscreen-style. My reasons
for prefering this approach is that it is relatively uninvasive, and closer
to the way things are done now without (in my opinion) being ugly; and that
automatic touchscreen input to screen mapping is still not a solved problem.
I think that both are valid though.
Both approaches require changes to the hypervisor and virtual hardware, and
to user-space consumers which would use the interface. I have checked the
mutter source and believe that the change required to support the interface
as implemented here would be minimal and intend to submit a patch if this
change is accepted. I think that the virtual hardware changes are likely to
be less invasive with this approach than with the other. This change will
though also require small drm driver changes once the virtual hardware has
been adjusted; currently to the qxl driver and to the out-of-tree vboxvideo
driver. It would certainly be nice to have in virtio-gpu.
Regards
Michael
Documentation/gpu/kms-properties.csv | 4 ++--
drivers/gpu/drm/drm_connector.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
index 981873a..825238e 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -20,8 +20,8 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De
,,“overscan”,RANGE,"Min=0, Max=100",Connector,TBD
,,“saturation”,RANGE,"Min=0, Max=100",Connector,TBD
,,“hue”,RANGE,"Min=0, Max=100",Connector,TBD
-,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector
-,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector
+,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,"property to suggest an X offset for a connector to help match positions of host windows and guest screens; can be set by the driver for the host or user-space for the guest"
+,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,"property to suggest an Y offset for a connector to help match positions of host windows and guest screens; can be set by the driver for the host or user--space for the guest"
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB
i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255."
,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5a45262..ebb3cee 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -876,10 +876,10 @@ int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
return 0;
dev->mode_config.suggested_x_property =
- drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "suggested X", 0, 0xffffffff);
+ drm_property_create_range(dev, 0, "suggested X", 0, 0xffffffff);
dev->mode_config.suggested_y_property =
- drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "suggested Y", 0, 0xffffffff);
+ drm_property_create_range(dev, 0, "suggested Y", 0, 0xffffffff);
if (dev->mode_config.suggested_x_property == NULL ||
dev->mode_config.suggested_y_property == NULL)
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2016-12-20 10:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-20 10:38 Michael Thayer [this message]
2016-12-21 9:05 ` [PATCH] drm: remove immutable flag from suggested X/Y connector properties Daniel Vetter
2016-12-21 14:30 ` Michael Thayer
2016-12-22 7:07 ` Daniel Vetter
2016-12-22 7:46 ` Michael Thayer
2017-01-03 10:40 ` Gerd Hoffmann
2017-01-04 17:49 ` Michael Thayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161220103852.30963-1-michael.thayer@oracle.com \
--to=michael.thayer@oracle.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox