[PATCH] drm: remove immutable flag from suggested X/Y connector properties

[PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Michael Thayer]

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

Re: [PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Daniel Vetter]

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@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
- some userspace to take advantage of it
- 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.

Also if we make this mutable would be good to switch the entire
scafffolding 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 ;-)
-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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Michael Thayer]

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@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Daniel Vetter]

On Wed, Dec 21, 2016 at 03:30:04PM +0100, Michael Thayer wrote:
> 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@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?

I don't see the point in merging core code for out-of-tree drivers. If
it's out-of-tree you can just add this locally (by adding the property).
Has ofc the risk of uapi breakage or not upstream opting for a slightly
different flavour, but that's the price for not being upstream.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Michael Thayer]

22.12.2016 08:07, Daniel Vetter пишет:
> On Wed, Dec 21, 2016 at 03:30:04PM +0100, Michael Thayer wrote:
>> 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@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?
>
> I don't see the point in merging core code for out-of-tree drivers. If
> it's out-of-tree you can just add this locally (by adding the property).
> Has ofc the risk of uapi breakage or not upstream opting for a slightly
> different flavour, but that's the price for not being upstream.

Evil question: I just can't see myself getting it upstream in the near 
future for lack of time.  How much success am I likely to have asking 
for volunteers?  (I do not see a reason why other people should have 
more time than I do, but you never know.)  Obviously I would continue 
committing to it and would probably switch to keeping our out-of-tree 
driver in sync with the in-kernel one.  For interest, the files are 
mainly in these places, and the other referenced include files are 
mainly compatibility layer things which would probably want eliminating:

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/common/VBoxVideo
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/GuestHost/HGSMI
https://www.virtualbox.org/browser/vbox/trunk/include/VBox/VBoxVideo.h
https://www.virtualbox.org/browser/vbox/trunk/include/VBox/VBoxVideoGuest.h
https://www.virtualbox.org/browser/vbox/trunk/include/VBox/HGSMI

Otherwise, yes, I could try implementing the interface out-of-tree, and 
see if the GNOME Shell people were still receptive to it (no point in 
doing it if they are not).  Hopefully if GNOME Shell used it other 
virtualisation drivers would pick it up too.

Regards
Michael

> -Daniel
>

-- 
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Gerd Hoffmann]

  Hi,

> > 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.

Not only kernel driver and qemu.  Right now neither qxl nor virtio-gpu
can communicate the actual layout back to the host.  So this also
requires changes to the guest/host protocol (i.e. the virtual hardware).

> > - some userspace to take advantage of it
> 
> As I wrote, mutter would be the first candidate.

Do you have any feedback from mutter developers on the two approaches
(touchscreen-style autoconfig or x+y offsets)?

cheers,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Michael Thayer]

03.01.2017 11:40, Gerd Hoffmann wrote:
>>> 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.
>
> Not only kernel driver and qemu.  Right now neither qxl nor virtio-gpu
> can communicate the actual layout back to the host.  So this also
> requires changes to the guest/host protocol (i.e. the virtual hardware).
>
>>> - some userspace to take advantage of it
>>
>> As I wrote, mutter would be the first candidate.
>
> Do you have any feedback from mutter developers on the two approaches
> (touchscreen-style autoconfig or x+y offsets)?

The first time I wrote to them no one responded to my e-mail[1].  I 
could try again, asking just that question, though my plan at this time 
was just to submit a patch.  (For Daniel, I am looking at our source 
code again to see if I can get it in a merge-able state with a 
reasonable time investment.  Then there would be the "some driver to 
implement".)

[1] 
https://mail.gnome.org/archives/gnome-shell-list/2016-December/msg00001.html

Regards
Michael

>
> cheers,
>   Gerd
>

-- 
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel