Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-08 Thread Alex Goins 
Thanks Hans for the insight into detecting HW cursor usage.

+Daniel Vetter, could you comment on this possible issue with
drmModeMoveCursor() and drmModePageFlip() interfering with each other on i915?

> I'm encountering some very strange issues when running these with PRIME
> Synchronization enabled, even after fixing our internal cursor handling. When
> moving the cursor around without damaging anything, it's smooth. When having 
> an
> application causing damage, and thus flipping, without the cursor moving, it's
> smooth. When moving the cursor AND causing damage, both the cursor and the
> flipping seem to be going at roughly 30 Hz, half speed.

> Skipping the call to either drmModeMoveCursor() in 
> drmmode_set_cursor_position()
> or the call to drmModePageFlip() in drmmode_SharedPixmapFlip() alleviates the
> issue for flipping or cursor moving, respectively, so I'm inclined to say that
> drmModeMoveCursor() or drmModePageFlip() are interfering with each other. 
> Could
> that be?

I suppose it could be worked around by disabling HW cursors, but i915 is our
most common output sink and I'd prefer if the default behavior remained
functional, especially for the first Xorg release that supports PRIME
Synchronization.

Thanks,
Alex

On Thu, 8 Sep 2016, Hans de Goede wrote:

> Hi,
> 
> On 08-09-16 01:32, Alex Goins wrote:
> > Hi Hans,
> >
> > Thanks for this, it will definitely be a big improvement.
> >
> > I've been testing these patches against the NVIDIA driver. Some concerns -
> >
> > What would be the best way to query from the master if the slave is using a 
> > HW
> > cursor? We typically composite the cursor onto the shared pixmap, and with 
> > this
> > it results in a double-cursor, so we need a way to tell if we shouldn't be 
> > doing
> > that.
> 
> If any of the slaves fail to set the hw cursor, we fall back to sw-cursor
> everywhere, so from the master you can simply do:
> 
>  xf86CursorScreenPtr ScreenPriv =
>  (xf86CursorScreenPtr) dixLookupPrivate(>devPrivates,
> xf86CursorScreenKey);
> 
> And then check ScreenPriv->SWCursor if that is false the all the
> slaves are using a HW cursor, if it is true none of the slaves are
> using a HW cursor.
> 
> > I'm encountering some very strange issues when running these with PRIME
> > Synchronization enabled, even after fixing our internal cursor handling. 
> > When
> > moving the cursor around without damaging anything, it's smooth. When 
> > having an
> > application causing damage, and thus flipping, without the cursor moving, 
> > it's
> > smooth. When moving the cursor AND causing damage, both the cursor and the
> > flipping seem to be going at roughly 30 Hz, half speed.
> 
> I'm not seeing this, note I'm using the hdmi out of an nvidia card driven
> by the nouveau kernel driver with modesetting driver as slaveoutput, so this
> could indeed be an i915 kernel driver issue as others have suggested.
> 
> Regards,
> 
> Hans
> 
> 
> 
> >
> > Skipping the call to either drmModeMoveCursor() in 
> > drmmode_set_cursor_position()
> > or the call to drmModePageFlip() in drmmode_SharedPixmapFlip() alleviates 
> > the
> > issue for flipping or cursor moving, respectively, so I'm inclined to say 
> > that
> > drmModeMoveCursor() or drmModePageFlip() are interfering with each other. 
> > Could
> > that be?
> >
> > Thanks,
> > Alex
> >
> > On Wed, 7 Sep 2016, Aaron Plattner wrote:
> >
> >> On 09/07/2016 08:51 AM, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 07-09-16 17:38, Aaron Plattner wrote:
>  On 09/07/2016 08:24 AM, Hans de Goede wrote:
> > Hi,
> >
> > On 07-09-16 17:02, Aaron Plattner wrote:
> >> Adding Alex.
> >>
> >> On 09/07/2016 05:26 AM, Hans de Goede wrote:
> >>> From: Dave Airlie 
> >>>
> >>> Currently with PRIME if we detect a secondary GPU,
> >>> we switch to using SW cursors, this isn't optimal,
> >>> esp for the intel/nvidia combinations, we have
> >>> no choice for the USB offload devices.
> >>>
> >>> This patch checks on each slave screen if hw
> >>> cursors are enabled, and also calls set cursor
> >>> and move cursor on all screens.
> >>>
> >>> Cc: Aaron Plattner 
> >>> Signed-off-by: Dave Airlie 
> >>> Signed-off-by: Hans de Goede 
> >>> Reviewed-by: Michel Dänzer 
> >>> ---
> >>> Changes in v6 (Hans de Goede):
> >>> -Move removal of xorg_list_is_empty(>pixmap_dirty_list)
> >>>  check from xf86CursorSetCursor() back to this patch (accidentally
> >>> moved to
> >>>  "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)
> >>>
> >>> Changes in v5 (Hans de Goede):
> >>> -Split out various helper functions into separate patches
> >>> -Fix cursor showing in the wrong spot on slave-outputs when rotation
> >>> is used
> >>>
> >>> Changes

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Michel Dänzer 
On 08/09/16 10:23 AM, Alex Goins wrote:
> On Thu, 8 Sep 2016, Michel Dänzer wrote:
> 
>> On 08/09/16 08:32 AM, Alex Goins wrote:
>>>
>>> I'm encountering some very strange issues when running these with PRIME
>>> Synchronization enabled, even after fixing our internal cursor handling. 
>>> When
>>> moving the cursor around without damaging anything, it's smooth. When 
>>> having an
>>> application causing damage, and thus flipping, without the cursor moving, 
>>> it's
>>> smooth. When moving the cursor AND causing damage, both the cursor and the
>>> flipping seem to be going at roughly 30 Hz, half speed.
>>>
>>> Skipping the call to either drmModeMoveCursor() in 
>>> drmmode_set_cursor_position()
>>> or the call to drmModePageFlip() in drmmode_SharedPixmapFlip() alleviates 
>>> the
>>> issue for flipping or cursor moving, respectively, so I'm inclined to say 
>>> that
>>> drmModeMoveCursor() or drmModePageFlip() are interfering with each other. 
>>> Could
>>> that be?
>>
>> It certainly could be, but that would probably be an issue in your
>> kernel driver.
> 
> Sorry, should have specified. This is running against the i915 DRM driver as 
> the
> slave. drmModeMoveCursor() and drmModePageFlip() are calling into i915 on 
> kernel
> 4.6.

Probably an i915 kernel driver issue then. I know there were issues like
that during the transition to the atomic KMS API.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Alex Goins 
On Thu, 8 Sep 2016, Michel Dänzer wrote:

> On 08/09/16 08:32 AM, Alex Goins wrote:
> > 
> > I'm encountering some very strange issues when running these with PRIME
> > Synchronization enabled, even after fixing our internal cursor handling. 
> > When
> > moving the cursor around without damaging anything, it's smooth. When 
> > having an
> > application causing damage, and thus flipping, without the cursor moving, 
> > it's
> > smooth. When moving the cursor AND causing damage, both the cursor and the
> > flipping seem to be going at roughly 30 Hz, half speed.
> > 
> > Skipping the call to either drmModeMoveCursor() in 
> > drmmode_set_cursor_position()
> > or the call to drmModePageFlip() in drmmode_SharedPixmapFlip() alleviates 
> > the
> > issue for flipping or cursor moving, respectively, so I'm inclined to say 
> > that
> > drmModeMoveCursor() or drmModePageFlip() are interfering with each other. 
> > Could
> > that be?
> 
> It certainly could be, but that would probably be an issue in your
> kernel driver.

Sorry, should have specified. This is running against the i915 DRM driver as the
slave. drmModeMoveCursor() and drmModePageFlip() are calling into i915 on kernel
4.6.

Thanks,
Alex___
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 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Michel Dänzer 
On 08/09/16 08:32 AM, Alex Goins wrote:
> 
> I'm encountering some very strange issues when running these with PRIME
> Synchronization enabled, even after fixing our internal cursor handling. When
> moving the cursor around without damaging anything, it's smooth. When having 
> an
> application causing damage, and thus flipping, without the cursor moving, it's
> smooth. When moving the cursor AND causing damage, both the cursor and the
> flipping seem to be going at roughly 30 Hz, half speed.
> 
> Skipping the call to either drmModeMoveCursor() in 
> drmmode_set_cursor_position()
> or the call to drmModePageFlip() in drmmode_SharedPixmapFlip() alleviates the
> issue for flipping or cursor moving, respectively, so I'm inclined to say that
> drmModeMoveCursor() or drmModePageFlip() are interfering with each other. 
> Could
> that be?

It certainly could be, but that would probably be an issue in your
kernel driver.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Alex Goins 
Hi Hans,

Thanks for this, it will definitely be a big improvement.

I've been testing these patches against the NVIDIA driver. Some concerns -

What would be the best way to query from the master if the slave is using a HW
cursor? We typically composite the cursor onto the shared pixmap, and with this
it results in a double-cursor, so we need a way to tell if we shouldn't be doing
that.

I'm encountering some very strange issues when running these with PRIME
Synchronization enabled, even after fixing our internal cursor handling. When
moving the cursor around without damaging anything, it's smooth. When having an
application causing damage, and thus flipping, without the cursor moving, it's
smooth. When moving the cursor AND causing damage, both the cursor and the
flipping seem to be going at roughly 30 Hz, half speed.

Skipping the call to either drmModeMoveCursor() in drmmode_set_cursor_position()
or the call to drmModePageFlip() in drmmode_SharedPixmapFlip() alleviates the
issue for flipping or cursor moving, respectively, so I'm inclined to say that
drmModeMoveCursor() or drmModePageFlip() are interfering with each other. Could
that be?

Thanks,
Alex

On Wed, 7 Sep 2016, Aaron Plattner wrote:

> On 09/07/2016 08:51 AM, Hans de Goede wrote:
> > Hi,
> > 
> > On 07-09-16 17:38, Aaron Plattner wrote:
> >> On 09/07/2016 08:24 AM, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 07-09-16 17:02, Aaron Plattner wrote:
>  Adding Alex.
> 
>  On 09/07/2016 05:26 AM, Hans de Goede wrote:
> > From: Dave Airlie 
> >
> > Currently with PRIME if we detect a secondary GPU,
> > we switch to using SW cursors, this isn't optimal,
> > esp for the intel/nvidia combinations, we have
> > no choice for the USB offload devices.
> >
> > This patch checks on each slave screen if hw
> > cursors are enabled, and also calls set cursor
> > and move cursor on all screens.
> >
> > Cc: Aaron Plattner 
> > Signed-off-by: Dave Airlie 
> > Signed-off-by: Hans de Goede 
> > Reviewed-by: Michel Dänzer 
> > ---
> > Changes in v6 (Hans de Goede):
> > -Move removal of xorg_list_is_empty(>pixmap_dirty_list)
> >  check from xf86CursorSetCursor() back to this patch (accidentally
> > moved to
> >  "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)
> >
> > Changes in v5 (Hans de Goede):
> > -Split out various helper functions into separate patches
> > -Fix cursor showing in the wrong spot on slave-outputs when rotation
> > is used
> >
> > Changes in v4 (Hans de Goede):
> > -Fix crash when xf86ScreenSetCursor() gets called on a hot-plugged GPU
> >
> > Changes in v3 (Hans de Goede):
> > -Re-indent xf86CursorScreenCheckHW
> > -Loop over slave-outputs instead of over pixmap_dirty_list, Aaron
> > Plattner has
> >  indicated that the nvidia driver does not use pixmap_dirty_list and
> > with
> >  the recent "randr/xf86: Add PRIME Synchronization / Double Buffer"
> > changes
> >  there may be 2 pixmaps pointing to the same GPU screen on the
> > pixmap_dirty_list twice
> > -Make xf86CurrentCursor work when called on GPU screen pointers
> >  (fixes the modesetting driver as outputslave crashing)
> > -Fix both hw and sw cursor showing at the same time when an usb
> > slave-gpu is
> >  present at cold plug time
> >
> > Changes in v2:
> > -hotplugging causes the driver to try and register
> >  the cursor private, however we can't register
> >  these at runtime yet, we need to add support for
> >  reallocation of cursor screen privates. However
> >  all hotplugged devices currently don't support
> >  HW cursors, so punt for now. This means GPUs
> >  already in the system will get hw cursors
> >  and USB ones won't which is all we care about
> >  presently.
> > -drop list empty checks (Eric)
> > -fixup comments (Michel)
> > ---
> >  dix/dispatch.c |  4 +++
> >  hw/xfree86/ramdac/xf86Cursor.c |  2 +-
> >  hw/xfree86/ramdac/xf86HWCurs.c | 78
> > +++---
> >  3 files changed, 78 insertions(+), 6 deletions(-)
> >
> > diff --git a/dix/dispatch.c b/dix/dispatch.c
> > index a3c2fbb..21c387e 100644
> > --- a/dix/dispatch.c
> > +++ b/dix/dispatch.c
> > @@ -3965,6 +3965,10 @@ AddGPUScreen(Bool (*pfnInit) (ScreenPtr
> > /*pScreen */ ,
> >
> >  update_desktop_dimensions();
> >
> > +if (!dixPrivatesCreated(PRIVATE_CURSOR))
> > +dixRegisterScreenPrivateKey(, pScreen,
> > +PRIVATE_CURSOR, 0);
> > +
> >  return i;
> >  }
> >
> > diff --git a/hw/xfree86/ramdac/xf86Cursor.c
> > b/hw/xfree86/ramdac/xf86Cursor.c
> > index

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Aaron Plattner 
On 09/07/2016 08:51 AM, Hans de Goede wrote:
> Hi,
> 
> On 07-09-16 17:38, Aaron Plattner wrote:
>> On 09/07/2016 08:24 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 07-09-16 17:02, Aaron Plattner wrote:
 Adding Alex.

 On 09/07/2016 05:26 AM, Hans de Goede wrote:
> From: Dave Airlie 
>
> Currently with PRIME if we detect a secondary GPU,
> we switch to using SW cursors, this isn't optimal,
> esp for the intel/nvidia combinations, we have
> no choice for the USB offload devices.
>
> This patch checks on each slave screen if hw
> cursors are enabled, and also calls set cursor
> and move cursor on all screens.
>
> Cc: Aaron Plattner 
> Signed-off-by: Dave Airlie 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Michel Dänzer 
> ---
> Changes in v6 (Hans de Goede):
> -Move removal of xorg_list_is_empty(>pixmap_dirty_list)
>  check from xf86CursorSetCursor() back to this patch (accidentally
> moved to
>  "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)
>
> Changes in v5 (Hans de Goede):
> -Split out various helper functions into separate patches
> -Fix cursor showing in the wrong spot on slave-outputs when rotation
> is used
>
> Changes in v4 (Hans de Goede):
> -Fix crash when xf86ScreenSetCursor() gets called on a hot-plugged GPU
>
> Changes in v3 (Hans de Goede):
> -Re-indent xf86CursorScreenCheckHW
> -Loop over slave-outputs instead of over pixmap_dirty_list, Aaron
> Plattner has
>  indicated that the nvidia driver does not use pixmap_dirty_list and
> with
>  the recent "randr/xf86: Add PRIME Synchronization / Double Buffer"
> changes
>  there may be 2 pixmaps pointing to the same GPU screen on the
> pixmap_dirty_list twice
> -Make xf86CurrentCursor work when called on GPU screen pointers
>  (fixes the modesetting driver as outputslave crashing)
> -Fix both hw and sw cursor showing at the same time when an usb
> slave-gpu is
>  present at cold plug time
>
> Changes in v2:
> -hotplugging causes the driver to try and register
>  the cursor private, however we can't register
>  these at runtime yet, we need to add support for
>  reallocation of cursor screen privates. However
>  all hotplugged devices currently don't support
>  HW cursors, so punt for now. This means GPUs
>  already in the system will get hw cursors
>  and USB ones won't which is all we care about
>  presently.
> -drop list empty checks (Eric)
> -fixup comments (Michel)
> ---
>  dix/dispatch.c |  4 +++
>  hw/xfree86/ramdac/xf86Cursor.c |  2 +-
>  hw/xfree86/ramdac/xf86HWCurs.c | 78
> +++---
>  3 files changed, 78 insertions(+), 6 deletions(-)
>
> diff --git a/dix/dispatch.c b/dix/dispatch.c
> index a3c2fbb..21c387e 100644
> --- a/dix/dispatch.c
> +++ b/dix/dispatch.c
> @@ -3965,6 +3965,10 @@ AddGPUScreen(Bool (*pfnInit) (ScreenPtr
> /*pScreen */ ,
>
>  update_desktop_dimensions();
>
> +if (!dixPrivatesCreated(PRIVATE_CURSOR))
> +dixRegisterScreenPrivateKey(, pScreen,
> +PRIVATE_CURSOR, 0);
> +
>  return i;
>  }
>
> diff --git a/hw/xfree86/ramdac/xf86Cursor.c
> b/hw/xfree86/ramdac/xf86Cursor.c
> index 623a65b..afcce53 100644
> --- a/hw/xfree86/ramdac/xf86Cursor.c
> +++ b/hw/xfree86/ramdac/xf86Cursor.c
> @@ -337,7 +337,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr
> pScreen, CursorPtr pCurs,
>  return;
>  }
>
> -if (infoPtr->pScrn->vtSema &&
> xorg_list_is_empty(>pixmap_dirty_list) &&
> +if (infoPtr->pScrn->vtSema &&
>  (ScreenPriv->ForceHWCursorCount ||
>   xf86CheckHWCursor(pScreen, cursor, infoPtr))) {
>
> diff --git a/hw/xfree86/ramdac/xf86HWCurs.c
> b/hw/xfree86/ramdac/xf86HWCurs.c
> index 0f6990a..25d9f5d 100644
> --- a/hw/xfree86/ramdac/xf86HWCurs.c
> +++ b/hw/xfree86/ramdac/xf86HWCurs.c
> @@ -17,6 +17,7 @@
>  #include "cursorstr.h"
>  #include "mi.h"
>  #include "mipointer.h"
> +#include "randrstr.h"
>  #include "xf86CursorPriv.h"
>
>  #include "servermd.h"
> @@ -129,8 +130,8 @@ xf86ShowCursor(xf86CursorInfoPtr infoPtr)
>  return TRUE;
>  }
>
> -Bool
> -xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
> xf86CursorInfoPtr infoPtr)
> +static Bool
> +xf86ScreenCheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
> xf86CursorInfoPtr infoPtr)
>  {
>  return
>  (cursor->bits->argb && infoPtr->UseHWCursorARGB &&
> @@ -142,7 +143,29 @@

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Hans de Goede 

Hi,

On 07-09-16 17:38, Aaron Plattner wrote:

On 09/07/2016 08:24 AM, Hans de Goede wrote:

Hi,

On 07-09-16 17:02, Aaron Plattner wrote:

Adding Alex.

On 09/07/2016 05:26 AM, Hans de Goede wrote:

From: Dave Airlie 

Currently with PRIME if we detect a secondary GPU,
we switch to using SW cursors, this isn't optimal,
esp for the intel/nvidia combinations, we have
no choice for the USB offload devices.

This patch checks on each slave screen if hw
cursors are enabled, and also calls set cursor
and move cursor on all screens.

Cc: Aaron Plattner 
Signed-off-by: Dave Airlie 
Signed-off-by: Hans de Goede 
Reviewed-by: Michel Dänzer 
---
Changes in v6 (Hans de Goede):
-Move removal of xorg_list_is_empty(>pixmap_dirty_list)
 check from xf86CursorSetCursor() back to this patch (accidentally
moved to
 "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)

Changes in v5 (Hans de Goede):
-Split out various helper functions into separate patches
-Fix cursor showing in the wrong spot on slave-outputs when rotation
is used

Changes in v4 (Hans de Goede):
-Fix crash when xf86ScreenSetCursor() gets called on a hot-plugged GPU

Changes in v3 (Hans de Goede):
-Re-indent xf86CursorScreenCheckHW
-Loop over slave-outputs instead of over pixmap_dirty_list, Aaron
Plattner has
 indicated that the nvidia driver does not use pixmap_dirty_list and
with
 the recent "randr/xf86: Add PRIME Synchronization / Double Buffer"
changes
 there may be 2 pixmaps pointing to the same GPU screen on the
pixmap_dirty_list twice
-Make xf86CurrentCursor work when called on GPU screen pointers
 (fixes the modesetting driver as outputslave crashing)
-Fix both hw and sw cursor showing at the same time when an usb
slave-gpu is
 present at cold plug time

Changes in v2:
-hotplugging causes the driver to try and register
 the cursor private, however we can't register
 these at runtime yet, we need to add support for
 reallocation of cursor screen privates. However
 all hotplugged devices currently don't support
 HW cursors, so punt for now. This means GPUs
 already in the system will get hw cursors
 and USB ones won't which is all we care about
 presently.
-drop list empty checks (Eric)
-fixup comments (Michel)
---
 dix/dispatch.c |  4 +++
 hw/xfree86/ramdac/xf86Cursor.c |  2 +-
 hw/xfree86/ramdac/xf86HWCurs.c | 78
+++---
 3 files changed, 78 insertions(+), 6 deletions(-)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index a3c2fbb..21c387e 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3965,6 +3965,10 @@ AddGPUScreen(Bool (*pfnInit) (ScreenPtr
/*pScreen */ ,

 update_desktop_dimensions();

+if (!dixPrivatesCreated(PRIVATE_CURSOR))
+dixRegisterScreenPrivateKey(, pScreen,
+PRIVATE_CURSOR, 0);
+
 return i;
 }

diff --git a/hw/xfree86/ramdac/xf86Cursor.c
b/hw/xfree86/ramdac/xf86Cursor.c
index 623a65b..afcce53 100644
--- a/hw/xfree86/ramdac/xf86Cursor.c
+++ b/hw/xfree86/ramdac/xf86Cursor.c
@@ -337,7 +337,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr
pScreen, CursorPtr pCurs,
 return;
 }

-if (infoPtr->pScrn->vtSema &&
xorg_list_is_empty(>pixmap_dirty_list) &&
+if (infoPtr->pScrn->vtSema &&
 (ScreenPriv->ForceHWCursorCount ||
  xf86CheckHWCursor(pScreen, cursor, infoPtr))) {

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c
b/hw/xfree86/ramdac/xf86HWCurs.c
index 0f6990a..25d9f5d 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -17,6 +17,7 @@
 #include "cursorstr.h"
 #include "mi.h"
 #include "mipointer.h"
+#include "randrstr.h"
 #include "xf86CursorPriv.h"

 #include "servermd.h"
@@ -129,8 +130,8 @@ xf86ShowCursor(xf86CursorInfoPtr infoPtr)
 return TRUE;
 }

-Bool
-xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr)
+static Bool
+xf86ScreenCheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr)
 {
 return
 (cursor->bits->argb && infoPtr->UseHWCursorARGB &&
@@ -142,7 +143,29 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr
cursor, xf86CursorInfoPtr infoPtr
 }

 Bool
-xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y)
+xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr)
+{
+ScreenPtr pSlave;
+
+if (!xf86ScreenCheckHWCursor(pScreen, cursor, infoPtr))
+return FALSE;
+
+/* ask each driver consuming a pixmap if it can support HW
cursor */
+xorg_list_for_each_entry(pSlave, >slave_list,
slave_head) {
+xf86CursorScreenPtr sPriv;
+
+if (!RRHasScanoutPixmap(pSlave))
+continue;


A hypothetical future version of the nvidia driver that supports being
loaded as a GPU screen probably wouldn't use the RR scanout pixmap
stuff, but I suppose we can deal with that later if it turns out to be
a

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Aaron Plattner 

On 09/07/2016 08:24 AM, Hans de Goede wrote:

Hi,

On 07-09-16 17:02, Aaron Plattner wrote:

Adding Alex.

On 09/07/2016 05:26 AM, Hans de Goede wrote:

From: Dave Airlie 

Currently with PRIME if we detect a secondary GPU,
we switch to using SW cursors, this isn't optimal,
esp for the intel/nvidia combinations, we have
no choice for the USB offload devices.

This patch checks on each slave screen if hw
cursors are enabled, and also calls set cursor
and move cursor on all screens.

Cc: Aaron Plattner 
Signed-off-by: Dave Airlie 
Signed-off-by: Hans de Goede 
Reviewed-by: Michel Dänzer 
---
Changes in v6 (Hans de Goede):
-Move removal of xorg_list_is_empty(>pixmap_dirty_list)
 check from xf86CursorSetCursor() back to this patch (accidentally
moved to
 "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)

Changes in v5 (Hans de Goede):
-Split out various helper functions into separate patches
-Fix cursor showing in the wrong spot on slave-outputs when rotation
is used

Changes in v4 (Hans de Goede):
-Fix crash when xf86ScreenSetCursor() gets called on a hot-plugged GPU

Changes in v3 (Hans de Goede):
-Re-indent xf86CursorScreenCheckHW
-Loop over slave-outputs instead of over pixmap_dirty_list, Aaron
Plattner has
 indicated that the nvidia driver does not use pixmap_dirty_list and
with
 the recent "randr/xf86: Add PRIME Synchronization / Double Buffer"
changes
 there may be 2 pixmaps pointing to the same GPU screen on the
pixmap_dirty_list twice
-Make xf86CurrentCursor work when called on GPU screen pointers
 (fixes the modesetting driver as outputslave crashing)
-Fix both hw and sw cursor showing at the same time when an usb
slave-gpu is
 present at cold plug time

Changes in v2:
-hotplugging causes the driver to try and register
 the cursor private, however we can't register
 these at runtime yet, we need to add support for
 reallocation of cursor screen privates. However
 all hotplugged devices currently don't support
 HW cursors, so punt for now. This means GPUs
 already in the system will get hw cursors
 and USB ones won't which is all we care about
 presently.
-drop list empty checks (Eric)
-fixup comments (Michel)
---
 dix/dispatch.c |  4 +++
 hw/xfree86/ramdac/xf86Cursor.c |  2 +-
 hw/xfree86/ramdac/xf86HWCurs.c | 78
+++---
 3 files changed, 78 insertions(+), 6 deletions(-)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index a3c2fbb..21c387e 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3965,6 +3965,10 @@ AddGPUScreen(Bool (*pfnInit) (ScreenPtr
/*pScreen */ ,

 update_desktop_dimensions();

+if (!dixPrivatesCreated(PRIVATE_CURSOR))
+dixRegisterScreenPrivateKey(, pScreen,
+PRIVATE_CURSOR, 0);
+
 return i;
 }

diff --git a/hw/xfree86/ramdac/xf86Cursor.c
b/hw/xfree86/ramdac/xf86Cursor.c
index 623a65b..afcce53 100644
--- a/hw/xfree86/ramdac/xf86Cursor.c
+++ b/hw/xfree86/ramdac/xf86Cursor.c
@@ -337,7 +337,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr
pScreen, CursorPtr pCurs,
 return;
 }

-if (infoPtr->pScrn->vtSema &&
xorg_list_is_empty(>pixmap_dirty_list) &&
+if (infoPtr->pScrn->vtSema &&
 (ScreenPriv->ForceHWCursorCount ||
  xf86CheckHWCursor(pScreen, cursor, infoPtr))) {

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c
b/hw/xfree86/ramdac/xf86HWCurs.c
index 0f6990a..25d9f5d 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -17,6 +17,7 @@
 #include "cursorstr.h"
 #include "mi.h"
 #include "mipointer.h"
+#include "randrstr.h"
 #include "xf86CursorPriv.h"

 #include "servermd.h"
@@ -129,8 +130,8 @@ xf86ShowCursor(xf86CursorInfoPtr infoPtr)
 return TRUE;
 }

-Bool
-xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr)
+static Bool
+xf86ScreenCheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr)
 {
 return
 (cursor->bits->argb && infoPtr->UseHWCursorARGB &&
@@ -142,7 +143,29 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr
cursor, xf86CursorInfoPtr infoPtr
 }

 Bool
-xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y)
+xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr)
+{
+ScreenPtr pSlave;
+
+if (!xf86ScreenCheckHWCursor(pScreen, cursor, infoPtr))
+return FALSE;
+
+/* ask each driver consuming a pixmap if it can support HW
cursor */
+xorg_list_for_each_entry(pSlave, >slave_list,
slave_head) {
+xf86CursorScreenPtr sPriv;
+
+if (!RRHasScanoutPixmap(pSlave))
+continue;


A hypothetical future version of the nvidia driver that supports being
loaded as a GPU screen probably wouldn't use the RR scanout pixmap
stuff, but I suppose we can deal with that later if it turns out to be
a problem.

Is this just to avoid showing the

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Hans de Goede 

Hi,

On 07-09-16 17:02, Aaron Plattner wrote:

Adding Alex.

On 09/07/2016 05:26 AM, Hans de Goede wrote:

From: Dave Airlie 

Currently with PRIME if we detect a secondary GPU,
we switch to using SW cursors, this isn't optimal,
esp for the intel/nvidia combinations, we have
no choice for the USB offload devices.

This patch checks on each slave screen if hw
cursors are enabled, and also calls set cursor
and move cursor on all screens.

Cc: Aaron Plattner 
Signed-off-by: Dave Airlie 
Signed-off-by: Hans de Goede 
Reviewed-by: Michel Dänzer 
---
Changes in v6 (Hans de Goede):
-Move removal of xorg_list_is_empty(>pixmap_dirty_list)
 check from xf86CursorSetCursor() back to this patch (accidentally moved to
 "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)

Changes in v5 (Hans de Goede):
-Split out various helper functions into separate patches
-Fix cursor showing in the wrong spot on slave-outputs when rotation is used

Changes in v4 (Hans de Goede):
-Fix crash when xf86ScreenSetCursor() gets called on a hot-plugged GPU

Changes in v3 (Hans de Goede):
-Re-indent xf86CursorScreenCheckHW
-Loop over slave-outputs instead of over pixmap_dirty_list, Aaron Plattner has
 indicated that the nvidia driver does not use pixmap_dirty_list and with
 the recent "randr/xf86: Add PRIME Synchronization / Double Buffer" changes
 there may be 2 pixmaps pointing to the same GPU screen on the 
pixmap_dirty_list twice
-Make xf86CurrentCursor work when called on GPU screen pointers
 (fixes the modesetting driver as outputslave crashing)
-Fix both hw and sw cursor showing at the same time when an usb slave-gpu is
 present at cold plug time

Changes in v2:
-hotplugging causes the driver to try and register
 the cursor private, however we can't register
 these at runtime yet, we need to add support for
 reallocation of cursor screen privates. However
 all hotplugged devices currently don't support
 HW cursors, so punt for now. This means GPUs
 already in the system will get hw cursors
 and USB ones won't which is all we care about
 presently.
-drop list empty checks (Eric)
-fixup comments (Michel)
---
 dix/dispatch.c |  4 +++
 hw/xfree86/ramdac/xf86Cursor.c |  2 +-
 hw/xfree86/ramdac/xf86HWCurs.c | 78 +++---
 3 files changed, 78 insertions(+), 6 deletions(-)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index a3c2fbb..21c387e 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3965,6 +3965,10 @@ AddGPUScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,

 update_desktop_dimensions();

+if (!dixPrivatesCreated(PRIVATE_CURSOR))
+dixRegisterScreenPrivateKey(, pScreen,
+PRIVATE_CURSOR, 0);
+
 return i;
 }

diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c
index 623a65b..afcce53 100644
--- a/hw/xfree86/ramdac/xf86Cursor.c
+++ b/hw/xfree86/ramdac/xf86Cursor.c
@@ -337,7 +337,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr pScreen, 
CursorPtr pCurs,
 return;
 }

-if (infoPtr->pScrn->vtSema && xorg_list_is_empty(>pixmap_dirty_list) 
&&
+if (infoPtr->pScrn->vtSema &&
 (ScreenPriv->ForceHWCursorCount ||
  xf86CheckHWCursor(pScreen, cursor, infoPtr))) {

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index 0f6990a..25d9f5d 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -17,6 +17,7 @@
 #include "cursorstr.h"
 #include "mi.h"
 #include "mipointer.h"
+#include "randrstr.h"
 #include "xf86CursorPriv.h"

 #include "servermd.h"
@@ -129,8 +130,8 @@ xf86ShowCursor(xf86CursorInfoPtr infoPtr)
 return TRUE;
 }

-Bool
-xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr 
infoPtr)
+static Bool
+xf86ScreenCheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr 
infoPtr)
 {
 return
 (cursor->bits->argb && infoPtr->UseHWCursorARGB &&
@@ -142,7 +143,29 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, 
xf86CursorInfoPtr infoPtr
 }

 Bool
-xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y)
+xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr 
infoPtr)
+{
+ScreenPtr pSlave;
+
+if (!xf86ScreenCheckHWCursor(pScreen, cursor, infoPtr))
+return FALSE;
+
+/* ask each driver consuming a pixmap if it can support HW cursor */
+xorg_list_for_each_entry(pSlave, >slave_list, slave_head) {
+xf86CursorScreenPtr sPriv;
+
+if (!RRHasScanoutPixmap(pSlave))
+continue;


A hypothetical future version of the nvidia driver that supports being loaded 
as a GPU screen probably wouldn't use the RR scanout pixmap stuff, but I 
suppose we can deal with that later if it turns out to be a problem.

Is this just to avoid showing the cursor on a GPU screen that is

Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime

2016-09-07 Thread Aaron Plattner 

Adding Alex.

On 09/07/2016 05:26 AM, Hans de Goede wrote:

From: Dave Airlie 

Currently with PRIME if we detect a secondary GPU,
we switch to using SW cursors, this isn't optimal,
esp for the intel/nvidia combinations, we have
no choice for the USB offload devices.

This patch checks on each slave screen if hw
cursors are enabled, and also calls set cursor
and move cursor on all screens.

Cc: Aaron Plattner 
Signed-off-by: Dave Airlie 
Signed-off-by: Hans de Goede 
Reviewed-by: Michel Dänzer 
---
Changes in v6 (Hans de Goede):
-Move removal of xorg_list_is_empty(>pixmap_dirty_list)
 check from xf86CursorSetCursor() back to this patch (accidentally moved to
 "xf86Cursor: Add xf86CheckHWCursor() helper function" in v5)

Changes in v5 (Hans de Goede):
-Split out various helper functions into separate patches
-Fix cursor showing in the wrong spot on slave-outputs when rotation is used

Changes in v4 (Hans de Goede):
-Fix crash when xf86ScreenSetCursor() gets called on a hot-plugged GPU

Changes in v3 (Hans de Goede):
-Re-indent xf86CursorScreenCheckHW
-Loop over slave-outputs instead of over pixmap_dirty_list, Aaron Plattner has
 indicated that the nvidia driver does not use pixmap_dirty_list and with
 the recent "randr/xf86: Add PRIME Synchronization / Double Buffer" changes
 there may be 2 pixmaps pointing to the same GPU screen on the 
pixmap_dirty_list twice
-Make xf86CurrentCursor work when called on GPU screen pointers
 (fixes the modesetting driver as outputslave crashing)
-Fix both hw and sw cursor showing at the same time when an usb slave-gpu is
 present at cold plug time

Changes in v2:
-hotplugging causes the driver to try and register
 the cursor private, however we can't register
 these at runtime yet, we need to add support for
 reallocation of cursor screen privates. However
 all hotplugged devices currently don't support
 HW cursors, so punt for now. This means GPUs
 already in the system will get hw cursors
 and USB ones won't which is all we care about
 presently.
-drop list empty checks (Eric)
-fixup comments (Michel)
---
 dix/dispatch.c |  4 +++
 hw/xfree86/ramdac/xf86Cursor.c |  2 +-
 hw/xfree86/ramdac/xf86HWCurs.c | 78 +++---
 3 files changed, 78 insertions(+), 6 deletions(-)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index a3c2fbb..21c387e 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3965,6 +3965,10 @@ AddGPUScreen(Bool (*pfnInit) (ScreenPtr /*pScreen */ ,

 update_desktop_dimensions();

+if (!dixPrivatesCreated(PRIVATE_CURSOR))
+dixRegisterScreenPrivateKey(, pScreen,
+PRIVATE_CURSOR, 0);
+
 return i;
 }

diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c
index 623a65b..afcce53 100644
--- a/hw/xfree86/ramdac/xf86Cursor.c
+++ b/hw/xfree86/ramdac/xf86Cursor.c
@@ -337,7 +337,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr pScreen, 
CursorPtr pCurs,
 return;
 }

-if (infoPtr->pScrn->vtSema && xorg_list_is_empty(>pixmap_dirty_list) 
&&
+if (infoPtr->pScrn->vtSema &&
 (ScreenPriv->ForceHWCursorCount ||
  xf86CheckHWCursor(pScreen, cursor, infoPtr))) {

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index 0f6990a..25d9f5d 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -17,6 +17,7 @@
 #include "cursorstr.h"
 #include "mi.h"
 #include "mipointer.h"
+#include "randrstr.h"
 #include "xf86CursorPriv.h"

 #include "servermd.h"
@@ -129,8 +130,8 @@ xf86ShowCursor(xf86CursorInfoPtr infoPtr)
 return TRUE;
 }

-Bool
-xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr 
infoPtr)
+static Bool
+xf86ScreenCheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr 
infoPtr)
 {
 return
 (cursor->bits->argb && infoPtr->UseHWCursorARGB &&
@@ -142,7 +143,29 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, 
xf86CursorInfoPtr infoPtr
 }

 Bool
-xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y)
+xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr 
infoPtr)
+{
+ScreenPtr pSlave;
+
+if (!xf86ScreenCheckHWCursor(pScreen, cursor, infoPtr))
+return FALSE;
+
+/* ask each driver consuming a pixmap if it can support HW cursor */
+xorg_list_for_each_entry(pSlave, >slave_list, slave_head) {
+xf86CursorScreenPtr sPriv;
+
+if (!RRHasScanoutPixmap(pSlave))
+continue;


A hypothetical future version of the nvidia driver that supports being 
loaded as a GPU screen probably wouldn't use the RR scanout pixmap 
stuff, but I suppose we can deal with that later if it turns out to be a 
problem.


Is this just to avoid showing the cursor on a GPU screen that is 
displaying the dummy framebuffer that it allocated at