Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&pScreen->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 ho
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&pScreen->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(&cursorScreenDevPriv, 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/
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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
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
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
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(&pScreen->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(&cursorScreenDevPriv, 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 > > +++
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&cursorScreenDevPriv, 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(&pScreen->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, xf86CursorInfo
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&cursorScreenDevPriv, 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(&pScreen->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, &pScreen->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 s
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&cursorScreenDevPriv, 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(&pScreen->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, &pScreen->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
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&cursorScreenDevPriv, 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(&pScreen->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, &pScreen->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 ScreenInit? Can
Re: [PATCH v6 xserver 7/7] xf86Cursor: Add hw cursor support for prime
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(&pScreen->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(&cursorScreenDevPriv, 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(&pScreen->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, &pScreen->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 ScreenInit? Can we
just rely on xf86CollectEnabledOutputs r
