21.12.2016 10:05, Daniel Vetter wrote:
> On Tue, Dec 20, 2016 at 11:38:52AM +0100, Michael Thayer wrote:
>> 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 at 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.
>
> Makes sense I think, but for merging we need:
> - some driver to implement
This is where it starts getting tricky. vboxvideo is out of tree. In
theory I could look at getting it merged, but that needs time I am
rather short of (I am the only person maintaining that driver and it is
just one of my responsibilities; and there are some bits there that are
probably too ugly to merge as is). I don't think I am really the person
to be doing this for qxl/virtio-gpu as that required adding the support
to qemu too. I think that they really should have it, but I would
rather not be the one adding it. So would our out-of-tree driver be
good enough?
> - some userspace to take advantage of it
As I wrote, mutter would be the first candidate.
> - and some proper kernel-doc, we're deprecating that horrible property
> table that no one human can maintain. Latest upstream has lots of
> examples of what I have in mind.
I can take a look at that.
> Also if we make this mutable would be good to switch the entire
> scaffolding over to the atomic way of doing things, i.e. put the property
> value as a decoded thing into drm_connector_state and wire up all the
> handling. Means you need an atomic driver as demonstration vehicle, but
> I'd say you want that anyway ;-)
Currently vboxvideo is keeping close to ast as I have time to follow it.
Switching to atomic as long as ast is not switched likely means more
new bugs introduced than I would like to have time to fix, plus
maintaining two versions of vboxvideo, one for pre-atomic kernels and
one for post. At the moment we support 3.11 to 4.10 with a manageable
minimum of conditional compilation. So does "would be good" mean what
it says, or is it meant slightly more strongly?
Thanks and regards,
Michael
> -Daniel
>
>>
>> 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: RiesstraÃe 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
