Re: [PATCH vmmouse] conf: rename to 70-vmmouse.conf

[Peter Hutterer]

On Fri, Jun 10, 2016 at 04:32:19PM +0200, Stefan Dirsch wrote:
> Bump up the vmmouse driver to 70, so it get's preferred over libinput, which
> was dropped down to 60. This is only relevant for older kernels, which do not
> yet have the functionality provided by vmmouse driver. On recent kernels
> vmmouse driver is no longer loaded at all.
> 
> Signed-off-by: Stefan Dirsch 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  tools/{50-vmmouse.conf => 70-vmmouse.conf} | 0
>  tools/Makefile.am  | 2 +-
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename tools/{50-vmmouse.conf => 70-vmmouse.conf} (100%)
> 
> diff --git a/tools/50-vmmouse.conf b/tools/70-vmmouse.conf
> similarity index 100%
> rename from tools/50-vmmouse.conf
> rename to tools/70-vmmouse.conf
> diff --git a/tools/Makefile.am b/tools/Makefile.am
> index da0e782..0b4c526 100644
> --- a/tools/Makefile.am
> +++ b/tools/Makefile.am
> @@ -41,7 +41,7 @@ CLEANFILES = hal-probe-vmmouse
>  if HAS_XORG_CONF_DIR
>  
>  confdir=$(XORG_CONF_DIR)
> -dist_conf_DATA = 50-vmmouse.conf
> +dist_conf_DATA = 70-vmmouse.conf
>  
>  endif
>  
> -- 
> 2.6.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput] Init touch x/y axis labels as MT axis labels

[Peter Hutterer]

https://bugs.freedesktop.org/show_bug.cgi?id=96481

Signed-off-by: Peter Hutterer 
---
 src/xf86libinput.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 5295085..e18f8ff 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -798,10 +798,10 @@ xf86libinput_init_touch(InputInfoPtr pInfo)
res = 0;
 
xf86InitValuatorAxisStruct(dev, 0,
-  XIGetKnownProperty(AXIS_LABEL_PROP_ABS_X),
+  
XIGetKnownProperty(AXIS_LABEL_PROP_ABS_MT_POSITION_X),
   min, max, res * 1000, 0, res * 1000, 
Absolute);
xf86InitValuatorAxisStruct(dev, 1,
-  XIGetKnownProperty(AXIS_LABEL_PROP_ABS_Y),
+  
XIGetKnownProperty(AXIS_LABEL_PROP_ABS_MT_POSITION_Y),
   min, max, res * 1000, 0, res * 1000, 
Absolute);
InitTouchClassDeviceStruct(dev, TOUCH_MAX_SLOTS, XIDirectTouch, 2);
 
-- 
2.7.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

[Chris Wilson]

On Sun, Jun 12, 2016 at 06:23:25PM +0100, Emil Velikov wrote:
> On 12 June 2016 at 17:09, Chris Wilson  wrote:
> > On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On 11 June 2016 at 01:21, Alex Goins  wrote:
> >> > Reverse PRIME seems to be designed with discrete graphics as a sink in
> >> > mind, designed to do an extra copy from sysmem to vidmem to prevent a
> >> > discrete chip from needing to scan out from sysmem.
> >> >
> >> > The criteria it used to detect this case is if we are a GPU screen and
> >> > Glamor accelerated. It's possible for i915 to fulfill these conditions,
> >> > despite the fact that the additional copy doesn't make sense for i915.
> >> >
> >> > Normally, you could just set AccelMethod = none as an option for the 
> >> > device
> >> > and call it a day. However, when running with modesetting as both the 
> >> > sink
> >> > and the source, Glamor must be enabled.
> >> >
> >> > Ideally, you would be able to set AccelMethod individually for devices
> >> > using the same driver, but there seems to be a bug in X option parsing 
> >> > that
> >> > makes all devices on a driver inherit the options from the first detected
> >> > device. Thus, glamor needs to be enabled for all or for none until that 
> >> > bug
> >> > (if it's even a bug) is fixed.
> >> >
> >> > Nonetheless, it probably doesn't make sense to do the extra copy on i915
> >> > even if Glamor is enabled for the device, so this is more user friendly 
> >> > by
> >> > not requiring users to disable acceleration for i915.
> >> >
> >> IMHO the proposed patch does not sound like a reasonable long-term
> >> solution. Ideally the driver will expose a flag, based on which Xorg
> >> will enable/disable reverse prime. That said, as a short-term fix this
> >> is fine, barring the issues mentioned below.
> >
> > The decision as to whether or not the slave can use the passed pixmap as
> > its own scanout (or whether it requires a copy) is not part of the
> > master's policy.
> Hi Chris, it's this precisely what I've said/meant :-)
> 
> To put in other words:
> IMHO the master/slave device should expose all their capabilities.
> Based on these, Xorg should {en,dis}able reverse prime/etc.

Yes. But I would prefer it if the user made the choice, it may require
to jump through 20 different hoops, but if it is the only way to achieve
the user's configuration, that is what is need to be done.

This patch seems to be second guessing what the slave might be doing
instead, as you said, exposing a method by which the master/slave can
negotiate on what is being passed between them.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

[Emil Velikov]

On 12 June 2016 at 17:09, Chris Wilson  wrote:
> On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote:
>> Hi all,
>>
>> On 11 June 2016 at 01:21, Alex Goins  wrote:
>> > Reverse PRIME seems to be designed with discrete graphics as a sink in
>> > mind, designed to do an extra copy from sysmem to vidmem to prevent a
>> > discrete chip from needing to scan out from sysmem.
>> >
>> > The criteria it used to detect this case is if we are a GPU screen and
>> > Glamor accelerated. It's possible for i915 to fulfill these conditions,
>> > despite the fact that the additional copy doesn't make sense for i915.
>> >
>> > Normally, you could just set AccelMethod = none as an option for the device
>> > and call it a day. However, when running with modesetting as both the sink
>> > and the source, Glamor must be enabled.
>> >
>> > Ideally, you would be able to set AccelMethod individually for devices
>> > using the same driver, but there seems to be a bug in X option parsing that
>> > makes all devices on a driver inherit the options from the first detected
>> > device. Thus, glamor needs to be enabled for all or for none until that bug
>> > (if it's even a bug) is fixed.
>> >
>> > Nonetheless, it probably doesn't make sense to do the extra copy on i915
>> > even if Glamor is enabled for the device, so this is more user friendly by
>> > not requiring users to disable acceleration for i915.
>> >
>> IMHO the proposed patch does not sound like a reasonable long-term
>> solution. Ideally the driver will expose a flag, based on which Xorg
>> will enable/disable reverse prime. That said, as a short-term fix this
>> is fine, barring the issues mentioned below.
>
> The decision as to whether or not the slave can use the passed pixmap as
> its own scanout (or whether it requires a copy) is not part of the
> master's policy.
Hi Chris, it's this precisely what I've said/meant :-)

To put in other words:
IMHO the master/slave device should expose all their capabilities.
Based on these, Xorg should {en,dis}able reverse prime/etc.

Or perhaps you meant something entirely different ? If so can you
please elaborate.

Thanks
Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

[Chris Wilson]

On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote:
> Hi all,
> 
> On 11 June 2016 at 01:21, Alex Goins  wrote:
> > Reverse PRIME seems to be designed with discrete graphics as a sink in
> > mind, designed to do an extra copy from sysmem to vidmem to prevent a
> > discrete chip from needing to scan out from sysmem.
> >
> > The criteria it used to detect this case is if we are a GPU screen and
> > Glamor accelerated. It's possible for i915 to fulfill these conditions,
> > despite the fact that the additional copy doesn't make sense for i915.
> >
> > Normally, you could just set AccelMethod = none as an option for the device
> > and call it a day. However, when running with modesetting as both the sink
> > and the source, Glamor must be enabled.
> >
> > Ideally, you would be able to set AccelMethod individually for devices
> > using the same driver, but there seems to be a bug in X option parsing that
> > makes all devices on a driver inherit the options from the first detected
> > device. Thus, glamor needs to be enabled for all or for none until that bug
> > (if it's even a bug) is fixed.
> >
> > Nonetheless, it probably doesn't make sense to do the extra copy on i915
> > even if Glamor is enabled for the device, so this is more user friendly by
> > not requiring users to disable acceleration for i915.
> >
> IMHO the proposed patch does not sound like a reasonable long-term
> solution. Ideally the driver will expose a flag, based on which Xorg
> will enable/disable reverse prime. That said, as a short-term fix this
> is fine, barring the issues mentioned below.

The decision as to whether or not the slave can use the passed pixmap as
its own scanout (or whether it requires a copy) is not part of the
master's policy.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

[Emil Velikov]

Hi all,

On 11 June 2016 at 01:21, Alex Goins  wrote:
> Reverse PRIME seems to be designed with discrete graphics as a sink in
> mind, designed to do an extra copy from sysmem to vidmem to prevent a
> discrete chip from needing to scan out from sysmem.
>
> The criteria it used to detect this case is if we are a GPU screen and
> Glamor accelerated. It's possible for i915 to fulfill these conditions,
> despite the fact that the additional copy doesn't make sense for i915.
>
> Normally, you could just set AccelMethod = none as an option for the device
> and call it a day. However, when running with modesetting as both the sink
> and the source, Glamor must be enabled.
>
> Ideally, you would be able to set AccelMethod individually for devices
> using the same driver, but there seems to be a bug in X option parsing that
> makes all devices on a driver inherit the options from the first detected
> device. Thus, glamor needs to be enabled for all or for none until that bug
> (if it's even a bug) is fixed.
>
> Nonetheless, it probably doesn't make sense to do the extra copy on i915
> even if Glamor is enabled for the device, so this is more user friendly by
> not requiring users to disable acceleration for i915.
>
IMHO the proposed patch does not sound like a reasonable long-term
solution. Ideally the driver will expose a flag, based on which Xorg
will enable/disable reverse prime. That said, as a short-term fix this
is fine, barring the issues mentioned below.

> v1: N/A
> v2: N/A
> v3: N/A
> v4: Initial commit
> v5: Unchanged
> v6: Rebase onto ToT
>
> Signed-off-by: Alex Goins 
> ---
>  hw/xfree86/drivers/modesetting/driver.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/driver.c 
> b/hw/xfree86/drivers/modesetting/driver.c
> index f7abd1e..403cb96 100644
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -1378,9 +1378,13 @@ ScreenInit(ScreenPtr pScreen, int argc, char **argv)
>  xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> "Failed to initialize the Present extension.\n");
>  }
> -/* enable reverse prime if we are a GPU screen, and accelerated */
> -if (pScreen->isGPU)
> -ms->drmmode.reverse_prime_offload_mode = TRUE;
> +/* enable reverse prime if we are a GPU screen, and accelerated, and 
> not
> + * i915. i915 is happy scanning out from sysmem. */
> +if (pScreen->isGPU) {
> +drmVersionPtr version = drmGetVersion(ms->drmmode.fd);
> +if (strncmp("i915", version->name, version->name_len))
'version' can be null.

> +ms->drmmode.reverse_prime_offload_mode = TRUE;
> +}
We're leaking 'version'.

Same two apply for the UDL patch.

Regards,
Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel