Re: [PATCH xserver] glamor: Limit outstanding drawing queue with glClientWaitSync

2016-06-07 Thread Keith Packard 
Eric Anholt  writes:

> vc4 just waits until you don't have too many (5, arbitrarily) execs
> outstanding before submitting another one.  I think this is a problem of
> the Intel driver, not glamor.  We ran into it with Intel on cairo-gl,
> too, and I should have just fixed it in the driver back then.

Sounds like a plan to me; should be easy to hack mesa to dtrt.

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver] glamor: Limit outstanding drawing queue with glClientWaitSync

2016-06-07 Thread Eric Anholt 
Keith Packard  writes:

> Michel Dänzer  writes:
>
>> Is this about x11perf by any chance? I was seeing long lag with that as
>> well, which turned out to be because we weren't correctly synchronizing
>> with the hardware for XGetImage.
>
> x11perf only does XGetImage once per run of the test; without some
> intra-test queue management, other applications are unusable while the
> test is running. This particular case isn't terribly interesting, but as
> we improve glamor to need fewer and fewer synchronizations between CPU
> and GPU, this should become relevant for interactions between regular
> applications.
>
>> In the amdgpu driver we now have a GPU scheduler managing the userspace
>> command submissions.
>
> That does seem like a fine place to manage this; right now, the intel
> driver appears to only do this in SwapBuffers.

vc4 just waits until you don't have too many (5, arbitrarily) execs
outstanding before submitting another one.  I think this is a problem of
the Intel driver, not glamor.  We ran into it with Intel on cairo-gl,
too, and I should have just fixed it in the driver back then.


signature.asc
Description: PGP signature
___
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 xserver] os: Do timers under input lock, not blocked signals

2016-06-07 Thread Keith Packard 
Peter Hutterer  writes:

>> Signed-off-by: Keith Packard 
>
> Reviewed-by: Peter Hutterer 

Merged.

   88e981e..8174daa  master -> master

-- 
-keith


signature.asc
Description: PGP signature
___
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 mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> I suppose. The code is almost certainly broken as-is though, I can't
> imagine trying to do both sigio and threaded input on the same fd would
> go well (or be in any way reasonable to support).

Looking usbSigioReadInput, xf86AddEnabledDevice and xf86SigioReadInput
shows that the existing code is just in-lining the old version of
xf86AddEnabledDevice.

I don't think we need to make this ABI dependent, we can just remove
usbSigioReadInput and unconditionally call xf86AddEnabledDevice. With
the old server code, it'd end up doing nothing different, and with the
new server code, it will end up getting threaded input as desired.

-- 
-keith


signature.asc
Description: PGP signature
___
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 mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> That said we're not masking sigio off from the input thread, which is
> probably also worth fixing.

I hope this does what you mean:

InputThreadDoWork(void *arg)
{
sigset_t set;

/* Don't handle any signals on this thread */
sigfillset();
pthread_sigmask(SIG_BLOCK, , NULL);

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver] os: Do timers under input lock, not blocked signals

2016-06-07 Thread Peter Hutterer 
On Sun, Jun 05, 2016 at 01:04:16PM -0700, Keith Packard wrote:
> Timer processing can happen on either the main thread or the input
> thread. As a result, it must be done under the input lock.
> 
> Signals are unrelated to timers now that SIGIO isn't used for input
> processing, so stop blocking signals while processing timers.
> 
> Signed-off-by: Keith Packard 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  os/WaitFor.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/os/WaitFor.c b/os/WaitFor.c
> index e839d61..b82f826 100644
> --- a/os/WaitFor.c
> +++ b/os/WaitFor.c
> @@ -398,7 +398,7 @@ CheckAllTimers(void)
>  OsTimerPtr timer;
>  CARD32 now;
>  
> -OsBlockSignals();
> +input_lock();
>   start:
>  now = GetTimeInMillis();
>  
> @@ -408,7 +408,7 @@ CheckAllTimers(void)
>  goto start;
>  }
>  }
> -OsReleaseSignals();
> +input_unlock();
>  }
>  
>  static void
> @@ -416,10 +416,10 @@ DoTimer(OsTimerPtr timer, CARD32 now, volatile 
> OsTimerPtr *prev)
>  {
>  CARD32 newTime;
>  
> -OsBlockSignals();
> +input_lock();
>  *prev = timer->next;
>  timer->next = NULL;
> -OsReleaseSignals();
> +input_unlock();
>  
>  newTime = (*timer->callback) (timer, now, timer->arg);
>  if (newTime)
> @@ -439,7 +439,7 @@ TimerSet(OsTimerPtr timer, int flags, CARD32 millis,
>  return NULL;
>  }
>  else {
> -OsBlockSignals();
> +input_lock();
>  for (prev =  *prev; prev = &(*prev)->next) {
>  if (*prev == timer) {
>  *prev = timer->next;
> @@ -448,7 +448,7 @@ TimerSet(OsTimerPtr timer, int flags, CARD32 millis,
>  break;
>  }
>  }
> -OsReleaseSignals();
> +input_unlock();
>  }
>  if (!millis)
>  return timer;
> @@ -468,13 +468,13 @@ TimerSet(OsTimerPtr timer, int flags, CARD32 millis,
>  if (!millis)
>  return timer;
>  }
> -OsBlockSignals();
> +input_lock();
>  for (prev = 
>   *prev && (int) ((*prev)->expires - millis) <= 0;
>   prev = &(*prev)->next);
>  timer->next = *prev;
>  *prev = timer;
> -OsReleaseSignals();
> +input_unlock();
>  return timer;
>  }
>  
> @@ -484,7 +484,7 @@ TimerForce(OsTimerPtr timer)
>  int rc = FALSE;
>  volatile OsTimerPtr *prev;
>  
> -OsBlockSignals();
> +input_lock();
>  for (prev =  *prev; prev = &(*prev)->next) {
>  if (*prev == timer) {
>  DoTimer(timer, GetTimeInMillis(), prev);
> @@ -492,7 +492,7 @@ TimerForce(OsTimerPtr timer)
>  break;
>  }
>  }
> -OsReleaseSignals();
> +input_unlock();
>  return rc;
>  }
>  
> @@ -503,14 +503,14 @@ TimerCancel(OsTimerPtr timer)
>  
>  if (!timer)
>  return;
> -OsBlockSignals();
> +input_lock();
>  for (prev =  *prev; prev = &(*prev)->next) {
>  if (*prev == timer) {
>  *prev = timer->next;
>  break;
>  }
>  }
> -OsReleaseSignals();
> +input_unlock();
>  }
>  
>  void
> @@ -528,10 +528,10 @@ TimerCheck(void)
>  CARD32 now = GetTimeInMillis();
>  
>  if (timers && (int) (timers->expires - now) <= 0) {
> -OsBlockSignals();
> +input_lock();
>  while (timers && (int) (timers->expires - now) <= 0)
>  DoTimer(timers, now, );
> -OsReleaseSignals();
> +input_unlock();
>  }
>  }
>  
> -- 
> 2.8.1
> 
> ___
> 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
> 
___
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 mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Adam Jackson 
On Tue, 2016-06-07 at 13:57 -0700, Keith Packard wrote:
> Adam Jackson  writes:
> 
> > That certainly would be a less icky solution though, will send an
> > update.
> 
> Might be better to leave it for someone able to test the result?

I suppose. The code is almost certainly broken as-is though, I can't
imagine trying to do both sigio and threaded input on the same fd would
go well (or be in any way reasonable to support).

That said we're not masking sigio off from the input thread, which is
probably also worth fixing.

- ajax
___
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 mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> That certainly would be a less icky solution though, will send an update.

Might be better to leave it for someone able to test the result?

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver 3/5] dri1: Hide the SIGIO details from drivers

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> Yes. The motion is to get the definitions ahead of their use without a
> forward decl, since dri.h no longer exposes them.

Seems fine to me then.

Acked-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
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 mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Adam Jackson 
On Tue, 2016-06-07 at 13:09 -0700, Keith Packard wrote:
> Adam Jackson  writes:
> 
> > Signed-off-by: Adam Jackson 
> > ---
> >  src/bsd_mouse.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/bsd_mouse.c b/src/bsd_mouse.c
> > index a2c8ec7..dc628d4 100644
> > --- a/src/bsd_mouse.c
> > +++ b/src/bsd_mouse.c
> > @@ -546,8 +546,10 @@ usbMouseProc(DeviceIntPtr pPointer, int what)
> >  pInfo->fd = -1;
> >  } else {
> >  xf86FlushInput(pInfo->fd);
> > +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 23
> >  if (!xf86InstallSIGIOHandler (pInfo->fd, usbSigioReadInput,
> >    pInfo))
> > +#endif
> >  AddEnabledDevice(pInfo->fd);
> 
> I looked at this code and walked away -- why isn't this just using
> xf86AddEnabledDevice?

No idea, which is a bit distressing. That code seems to have come in
between 6.7 and 7.0, and I can't find a git copy of that cvs history
anywhere (and the cvs services are long since shut down). Thankfully I
think I've found the old cvsroot on kemper, I'll get that imported.

That certainly would be a less icky solution though, will send an update.

- ajax
___
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 xserver 3/5] dri1: Hide the SIGIO details from drivers

2016-06-07 Thread Adam Jackson 
On Tue, 2016-06-07 at 13:17 -0700, Keith Packard wrote:
> Adam Jackson  writes:
> 
> > Not being used, and not likely to be useful.
> 
> This patch looks like you've just moved code around in the file; are
> there differences in the new code which require this motion? It's pretty
> hard to review as-is.

Yes. The motion is to get the definitions ahead of their use without a
forward decl, since dri.h no longer exposes them.

- ajax
___
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 xserver 5/5] dix: Update some comments to reflect the new non-SIGIO input model

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> Signed-off-by: Adam Jackson 

Reviewed-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver 4/5] xfree86: Undocument UseSIGIO in xorg.conf

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> The doc text is wrong at this point, input processing isn't going to
> vary based on this, so we shouldn't say it does. The only thing this
> _does_ get used for is DRI1 SwapBuffers (on everything but savage), and
> if you disable it you're not going to get DRI1 at all, so we really
> shouldn't even mention it.
>
> Still, leave the option wired up to the parser so we don't break any
> DRI1-driver-using setup relying on it being disabled, and so we don't
> complain about unused options elsewhere.
>
> Signed-off-by: Adam Jackson 

Acked-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver 3/5] dri1: Hide the SIGIO details from drivers

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> Not being used, and not likely to be useful.

This patch looks like you've just moved code around in the file; are
there differences in the new code which require this motion? It's pretty
hard to review as-is.

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver 2/5] dmx: Remove SIGIO input support here too

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> This code was broken anyway. Note that DEVICE_OFF would make dmx think
> _no_ devices were using SIGIO anymore, which means 'xinput disable' on
> your mouse would probably do weird things to your keyboard too. Rather
> than try to repair that and keep SIGIO working on this one niche DDX,
> just rip it out and use the thread model like everyone else.
>
> Signed-off-by: Adam Jackson 

Acked-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver 1/5] dix: Use OsSignal() not signal()

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> As the man page for the latter states:
>
> The effects of signal() in a multithreaded process are unspecified.
>
> We already have an interface to call sigaction() instead, use it.

Lgtm.

Reviewed-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
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 mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Keith Packard 
Adam Jackson  writes:

> Signed-off-by: Adam Jackson 
> ---
>  src/bsd_mouse.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/bsd_mouse.c b/src/bsd_mouse.c
> index a2c8ec7..dc628d4 100644
> --- a/src/bsd_mouse.c
> +++ b/src/bsd_mouse.c
> @@ -546,8 +546,10 @@ usbMouseProc(DeviceIntPtr pPointer, int what)
>  pInfo->fd = -1;
>  } else {
>  xf86FlushInput(pInfo->fd);
> +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 23
>  if (!xf86InstallSIGIOHandler (pInfo->fd, usbSigioReadInput,
>pInfo))
> +#endif
>  AddEnabledDevice(pInfo->fd);

I looked at this code and walked away -- why isn't this just using
xf86AddEnabledDevice?

-- 
-keith


signature.asc
Description: PGP signature
___
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 xserver 2/5] dmx: Remove SIGIO input support here too

2016-06-07 Thread Adam Jackson 
This code was broken anyway. Note that DEVICE_OFF would make dmx think
_no_ devices were using SIGIO anymore, which means 'xinput disable' on
your mouse would probably do weird things to your keyboard too. Rather
than try to repair that and keep SIGIO working on this one niche DDX,
just rip it out and use the thread model like everyone else.

Signed-off-by: Adam Jackson 
---
 hw/dmx/dmxinput.h   |  18 
 hw/dmx/input/Makefile.am|   2 -
 hw/dmx/input/dmxevents.c|   1 -
 hw/dmx/input/dmxinputinit.c |   9 +-
 hw/dmx/input/dmxsigio.c | 234 
 hw/dmx/input/dmxsigio.h |  43 
 6 files changed, 2 insertions(+), 305 deletions(-)
 delete mode 100644 hw/dmx/input/dmxsigio.c
 delete mode 100644 hw/dmx/input/dmxsigio.h

diff --git a/hw/dmx/dmxinput.h b/hw/dmx/dmxinput.h
index 83c9c8b..210fd7a 100644
--- a/hw/dmx/dmxinput.h
+++ b/hw/dmx/dmxinput.h
@@ -47,9 +47,6 @@
 #ifndef DMXINPUT_H
 #define DMXINPUT_H
 
-/** Maximum number of file descriptors for SIGIO handling */
-#define DMX_MAX_SIGIO_FDS 4
-
 struct _DMXInputInfo;
 
 /** Reason why window layout was updated. */
@@ -69,15 +66,6 @@ typedef void (*UpdateWindowInfoProc) (struct _DMXInputInfo *,
 /** An opaque structure that is only exposed in the dmx/input layer. */
 typedef struct _DMXLocalInputInfo *DMXLocalInputInfoPtr;
 
-/** State of the SIGIO engine */
-typedef enum {
-DMX_NOSIGIO = 0,/**< Device does not use SIGIO at all. */
-DMX_USESIGIO,   /**< Device can use SIGIO, but is not
- * (e.g., because the VT is switch
- * away). */
-DMX_ACTIVESIGIO /**< Device is currently using SIGIO. */
-} dmxSigioState;
-
 /** DMXInputInfo is typedef'd in \a dmx.h so that all routines can have
  * access to the global pointers.  However, the elements are only
  * available to input-related routines. */
@@ -102,12 +90,6 @@ struct _DMXInputInfo {
 ProcessInputEventsProc processInputEvents;
 UpdateWindowInfoProc updateWindowInfo;
 
-/* Local input information */
-dmxSigioState sigioState;  /**< Current stat */
-int sigioFdCount;  /**< Number of fds in use */
-int sigioFd[DMX_MAX_SIGIO_FDS];/**< List of fds */
-Bool sigioAdded[DMX_MAX_SIGIO_FDS];/**< Active fds */
-
 /** True if a VT switch is pending, but has not yet happened. */
 int vt_switch_pending;
 
diff --git a/hw/dmx/input/Makefile.am b/hw/dmx/input/Makefile.am
index 185aaf8..b56ee8e 100644
--- a/hw/dmx/input/Makefile.am
+++ b/hw/dmx/input/Makefile.am
@@ -34,8 +34,6 @@ DMXSRCS = dmxinputinit.c \
   dmxinputinit.h \
   dmxarg.c \
   dmxarg.h \
-  dmxsigio.c \
-  dmxsigio.h \
   dmxevents.c \
   dmxevents.h \
  dmxxinput.c \
diff --git a/hw/dmx/input/dmxevents.c b/hw/dmx/input/dmxevents.c
index 3789602..235ba21 100644
--- a/hw/dmx/input/dmxevents.c
+++ b/hw/dmx/input/dmxevents.c
@@ -47,7 +47,6 @@
 #include "dmxcommon.h"
 #include "dmxcursor.h"
 #include "dmxmotion.h"
-#include "dmxsigio.h"
 #include "dmxmap.h"
 
 #include 
diff --git a/hw/dmx/input/dmxinputinit.c b/hw/dmx/input/dmxinputinit.c
index cdefd9a..a9522ff 100644
--- a/hw/dmx/input/dmxinputinit.c
+++ b/hw/dmx/input/dmxinputinit.c
@@ -63,7 +63,6 @@
 #include "usb-other.h"
 #include "usb-common.h"
 
-#include "dmxsigio.h"
 #include "dmxarg.h"
 
 #include "inputstr.h"
@@ -434,7 +433,6 @@ static int
 dmxDeviceOnOff(DeviceIntPtr pDevice, int what)
 {
 GETDMXINPUTFROMPDEVICE;
-int fd;
 DMXLocalInitInfo info;
 int i;
 Atom btn_labels[MAX_BUTTONS] = { 0 };   /* FIXME */
@@ -523,8 +521,8 @@ dmxDeviceOnOff(DeviceIntPtr pDevice, int what)
 break;
 case DEVICE_ON:
 if (!pDev->on) {
-if (dmxLocal->on && (fd = dmxLocal->on(pDev)) >= 0)
-dmxSigioRegister(dmxInput, fd);
+if (dmxLocal->on)
+   dmxLocal->on(pDev);
 pDev->on = TRUE;
 }
 break;
@@ -534,7 +532,6 @@ dmxDeviceOnOff(DeviceIntPtr pDevice, int what)
  * detached screen (DEVICE_OFF), and then again at server
  * generation time (DEVICE_CLOSE). */
 if (pDev->on) {
-dmxSigioUnregister(dmxInput);
 if (dmxLocal->off)
 dmxLocal->off(pDev);
 pDev->on = FALSE;
@@ -654,7 +651,6 @@ dmxSwitchReturn(void *p)
 
 if (!dmxInput->vt_switched)
 dmxLog(dmxFatal, "dmxSwitchReturn called, but not switched\n");
-dmxSigioEnableInput();
 for (i = 0; i < dmxInput->numDevs; i++)
 if (dmxInput->devs[i]->vt_post_switch)
 dmxInput->devs[i]->vt_post_switch(dmxInput->devs[i]->private);
@@ -676,7 +672,6 @@ dmxWakeupHandler(void *blockData, int result, void 
*pReadMask)
 dmxInput->vt_switch_pending = 0;
 for (i = 0; i <

[PATCH xserver 1/5] dix: Use OsSignal() not signal()

2016-06-07 Thread Adam Jackson 
As the man page for the latter states:

The effects of signal() in a multithreaded process are unspecified.

We already have an interface to call sigaction() instead, use it.

Signed-off-by: Adam Jackson 
---
 Xext/shm.c  |  5 ++---
 Xext/xf86bigfont.c  |  6 ++
 hw/dmx/input/lnx-keyboard.c |  5 ++---
 hw/kdrive/ephyr/ephyr.h |  1 -
 hw/kdrive/linux/linux.c |  1 -
 hw/kdrive/src/kdrive.c  |  2 --
 hw/kdrive/src/kinput.c  |  1 -
 hw/xfree86/common/xf86Init.c| 18 +-
 hw/xfree86/os-support/bsd/bsd_init.c|  2 +-
 hw/xfree86/os-support/linux/lnx_init.c  |  2 +-
 hw/xfree86/os-support/shared/VTsw_usl.c |  2 +-
 hw/xfree86/parser/write.c   |  5 ++---
 include/globals.h   |  2 --
 os/utils.c  |  4 ++--
 14 files changed, 22 insertions(+), 34 deletions(-)

diff --git a/Xext/shm.c b/Xext/shm.c
index b359a90..0a44b76 100644
--- a/Xext/shm.c
+++ b/Xext/shm.c
@@ -153,7 +153,6 @@ static ShmFuncs fbFuncs = { fbShmCreatePixmap, NULL };
 }
 
 #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || 
defined(__CYGWIN__) || defined(__DragonFly__)
-#include 
 
 static Bool badSysCall = FALSE;
 
@@ -170,7 +169,7 @@ CheckForShmSyscall(void)
 int shmid = -1;
 
 /* If no SHM support in the kernel, the bad syscall will generate SIGSYS */
-oldHandler = signal(SIGSYS, SigSysHandler);
+oldHandler = OsSignal(SIGSYS, SigSysHandler);
 
 badSysCall = FALSE;
 shmid = shmget(IPC_PRIVATE, 4096, IPC_CREAT);
@@ -183,7 +182,7 @@ CheckForShmSyscall(void)
 /* Allocation failed */
 badSysCall = TRUE;
 }
-signal(SIGSYS, oldHandler);
+OsSignal(SIGSYS, oldHandler);
 return !badSysCall;
 }
 
diff --git a/Xext/xf86bigfont.c b/Xext/xf86bigfont.c
index 95b5371..97596ea 100644
--- a/Xext/xf86bigfont.c
+++ b/Xext/xf86bigfont.c
@@ -96,8 +96,6 @@ static Bool badSysCall = FALSE;
 
 #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || 
defined(__CYGWIN__) || defined(__DragonFly__)
 
-#include 
-
 static void
 SigSysHandler(int signo)
 {
@@ -111,7 +109,7 @@ CheckForShmSyscall(void)
 int shmid = -1;
 
 /* If no SHM support in the kernel, the bad syscall will generate SIGSYS */
-oldHandler = signal(SIGSYS, SigSysHandler);
+oldHandler = OsSignal(SIGSYS, SigSysHandler);
 
 badSysCall = FALSE;
 shmid = shmget(IPC_PRIVATE, 4096, IPC_CREAT);
@@ -123,7 +121,7 @@ CheckForShmSyscall(void)
 /* Allocation failed */
 badSysCall = TRUE;
 }
-signal(SIGSYS, oldHandler);
+OsSignal(SIGSYS, oldHandler);
 return !badSysCall;
 }
 
diff --git a/hw/dmx/input/lnx-keyboard.c b/hw/dmx/input/lnx-keyboard.c
index 0aa62f4..2a5ce79 100644
--- a/hw/dmx/input/lnx-keyboard.c
+++ b/hw/dmx/input/lnx-keyboard.c
@@ -158,7 +158,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -505,7 +504,7 @@ kbdLinuxVTSignalHandler(int sig)
 {
 myPrivate *priv = PRIV;
 
-signal(sig, kbdLinuxVTSignalHandler);
+OsSignal(sig, kbdLinuxVTSignalHandler);
 if (priv) {
 ioctl(priv->fd, VT_RELDISP, VT_ACKACQ);
 priv->switched = !priv->switched;
@@ -537,7 +536,7 @@ kbdLinuxActivate(int fd, int vtno, int setSig)
 VT.acqsig = SIGUSR1;
 if (ioctl(fd, VT_SETMODE, ))
 FATAL0("kbdLinuxActivate: VT_SETMODE VT_PROCESS failed\n");
-signal(SIGUSR1, kbdLinuxVTSignalHandler);
+OsSignal(SIGUSR1, kbdLinuxVTSignalHandler);
 }
 return Success;
 }
diff --git a/hw/kdrive/ephyr/ephyr.h b/hw/kdrive/ephyr/ephyr.h
index f5015f6..7723bf1 100644
--- a/hw/kdrive/ephyr/ephyr.h
+++ b/hw/kdrive/ephyr/ephyr.h
@@ -27,7 +27,6 @@
 #define _EPHYR_H_
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/hw/kdrive/linux/linux.c b/hw/kdrive/linux/linux.c
index a52bdef..76daaf2 100644
--- a/hw/kdrive/linux/linux.c
+++ b/hw/kdrive/linux/linux.c
@@ -25,7 +25,6 @@
 #endif
 #include "kdrive.h"
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/hw/kdrive/src/kdrive.c b/hw/kdrive/src/kdrive.c
index 52bea5a..f02d826 100644
--- a/hw/kdrive/src/kdrive.c
+++ b/hw/kdrive/src/kdrive.c
@@ -43,8 +43,6 @@
 #include 
 #endif
 
-#include 
-
 #if defined(CONFIG_UDEV) || defined(CONFIG_HAL)
 #include 
 #endif
diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c
index 4119b08..c2fc7bb 100644
--- a/hw/kdrive/src/kinput.c
+++ b/hw/kdrive/src/kinput.c
@@ -32,7 +32,6 @@
 #if HAVE_X11_XF86KEYSYM_H
 #include 
 #endif
-#include 
 #include 
 #ifdef __sun
 #include/* needed for FNONBLOCK & FASYNC */
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 323ac11..93c0d74 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -308,16 +308,16 @@ InstallSignalHandlers(void)

[PATCH xserver 5/5] dix: Update some comments to reflect the new non-SIGIO input model

2016-06-07 Thread Adam Jackson 
Signed-off-by: Adam Jackson 
---
 hw/dmx/doc/dmx.xml  | 11 +++
 hw/dmx/input/dmxevents.c|  4 ++--
 hw/dmx/input/lnx-keyboard.c |  2 +-
 hw/dmx/input/lnx-ms.c   |  2 +-
 hw/dmx/input/lnx-ps2.c  |  2 +-
 hw/dmx/input/usb-common.c   |  2 +-
 hw/dmx/input/usb-keyboard.c |  2 +-
 hw/xfree86/common/xf86Privstr.h |  3 +--
 hw/xfree86/common/xf86str.h |  2 +-
 mi/mieq.c   |  3 +--
 mi/mipointer.c  |  5 +++--
 mi/mipointrst.h |  2 +-
 12 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/hw/dmx/doc/dmx.xml b/hw/dmx/doc/dmx.xml
index 40b9e42..f10cf79 100644
--- a/hw/dmx/doc/dmx.xml
+++ b/hw/dmx/doc/dmx.xml
@@ -944,14 +944,9 @@ are missing.
 devReadInput()
 
 Each device will have some function that gets called to read its
-physical input.  These may be called in a number of different ways.  In
-the case of synchronous I/O, they will be called from a DDX
-wakeup-handler that gets called after the server detects that new input is
-available.  In the case of asynchronous I/O, they will be called from a
-(SIGIO) signal handler triggered when new input is available.  This
-function should do at least two things: make sure that input events get
-enqueued, and make sure that the cursor gets moved for motion events
-(except if these are handled later by the driver's own event queue
+physical input. This function should do at least two things: make sure that
+input events get enqueued, and make sure that the cursor gets moved for motion
+events (except if these are handled later by the driver's own event queue
 processing function, which cannot be done when using the MI event queue
 handling).
 
diff --git a/hw/dmx/input/dmxevents.c b/hw/dmx/input/dmxevents.c
index 235ba21..fb0c00f 100644
--- a/hw/dmx/input/dmxevents.c
+++ b/hw/dmx/input/dmxevents.c
@@ -585,7 +585,7 @@ dmxInvalidateGlobalPosition(void)
  * \a DMX_ABSOLUTE_CONFINED (in the latter case, the pointer will not be
  * allowed to move outside the global boundaires).
  *
- * If \a block is set to \a DMX_BLOCK, then the SIGIO handler will be
+ * If \a block is set to \a DMX_BLOCK, then the input thread will be
  * blocked around calls to \a enqueueMotion(). */
 void
 dmxMotion(DevicePtr pDev, int *v, int firstAxes, int axesCount,
@@ -689,7 +689,7 @@ dmxFixup(DevicePtr pDev, int detail, KeySym keySym)
  * KeyRelease event, then the \a keySym is also specified.
  *
  * FIXME: make the code do what the comment says, or remove this comment.
- * If \a block is set to \a DMX_BLOCK, then the SIGIO handler will be
+ * If \a block is set to \a DMX_BLOCK, then the input thread will be
  * blocked around calls to dmxeqEnqueue(). */
 
 void
diff --git a/hw/dmx/input/lnx-keyboard.c b/hw/dmx/input/lnx-keyboard.c
index 2a5ce79..a273f6b 100644
--- a/hw/dmx/input/lnx-keyboard.c
+++ b/hw/dmx/input/lnx-keyboard.c
@@ -820,7 +820,7 @@ kbdLinuxConvert(DevicePtr pDev,
  * event, enqueue it with the \a motion function.  Otherwise, check for
  * special keys with the \a checkspecial function and enqueue the event
  * with the \a enqueue function.  The \a block type is passed to the
- * functions so that they may block SIGIO handling as appropriate to the
+ * functions so that they may block the input thread as appropriate to the
  * caller of this function. */
 void
 kbdLinuxRead(DevicePtr pDev,
diff --git a/hw/dmx/input/lnx-ms.c b/hw/dmx/input/lnx-ms.c
index 621f0fe..cb3b25f 100644
--- a/hw/dmx/input/lnx-ms.c
+++ b/hw/dmx/input/lnx-ms.c
@@ -191,7 +191,7 @@ msLinuxButton(DevicePtr pDev, ENQUEUEPROC enqueue, int 
buttons, BLOCK block)
  * event, enqueue it with the \a motion function.  Otherwise, check for
  * special keys with the \a checkspecial function and enqueue the event
  * with the \a enqueue function.  The \a block type is passed to the
- * functions so that they may block SIGIO handling as appropriate to the
+ * functions so that they may block the input thread as appropriate to the
  * caller of this function. */
 void
 msLinuxRead(DevicePtr pDev,
diff --git a/hw/dmx/input/lnx-ps2.c b/hw/dmx/input/lnx-ps2.c
index dd70cb8..9041974 100644
--- a/hw/dmx/input/lnx-ps2.c
+++ b/hw/dmx/input/lnx-ps2.c
@@ -187,7 +187,7 @@ ps2LinuxButton(DevicePtr pDev, ENQUEUEPROC enqueue, int 
buttons, BLOCK block)
  * event, enqueue it with the \a motion function.  Otherwise, check for
  * special keys with the \a checkspecial function and enqueue the event
  * with the \a enqueue function.  The \a block type is passed to the
- * functions so that they may block SIGIO handling as appropriate to the
+ * functions so that they may block the input thread as appropriate to the
  * caller of this function. */
 void
 ps2LinuxRead(DevicePtr pDev, MOTIONPROC motion,
diff --git a/hw/dmx/input/usb-common.c b/hw/dmx/input/usb-common.c
index 67aa07e..8c62aba 100644
--- a/hw/dmx/input/usb-common.c
+++ b/hw/dmx/input/usb-common.c
@@ -77,7 +77,7 @@
 /** Read an event from the \a

[PATCH xserver 3/5] dri1: Hide the SIGIO details from drivers

2016-06-07 Thread Adam Jackson 
Not being used, and not likely to be useful.

Signed-off-by: Adam Jackson 
---
 hw/xfree86/dri/dri.c | 133 ---
 hw/xfree86/dri/dri.h |   3 --
 2 files changed, 62 insertions(+), 74 deletions(-)

diff --git a/hw/xfree86/dri/dri.c b/hw/xfree86/dri/dri.c
index 0046e52..dbad12f 100644
--- a/hw/xfree86/dri/dri.c
+++ b/hw/xfree86/dri/dri.c
@@ -310,6 +310,68 @@ dri_crtc_notify(ScreenPtr pScreen)
 xf86_wrap_crtc_notify(pScreen, dri_crtc_notify);
 }
 
+static void
+drmSIGIOHandler(int interrupt, void *closure)
+{
+unsigned long key;
+void *value;
+ssize_t count;
+drm_ctx_t ctx;
+typedef void (*_drmCallback) (int, void *, void *);
+char buf[256];
+drm_context_t old;
+drm_context_t new;
+void *oldctx;
+void *newctx;
+char *pt;
+drmHashEntry *entry;
+void *hash_table;
+
+hash_table = drmGetHashTable();
+
+if (!hash_table)
+return;
+if (drmHashFirst(hash_table, , )) {
+entry = value;
+do {
+if ((count = read(entry->fd, buf, sizeof(buf) - 1)) > 0) {
+buf[count] = '\0';
+
+for (pt = buf; *pt != ' '; ++pt);   /* Find first space */
+++pt;
+old = strtol(pt, , 0);
+new = strtol(pt, NULL, 0);
+oldctx = drmGetContextTag(entry->fd, old);
+newctx = drmGetContextTag(entry->fd, new);
+((_drmCallback) entry->f) (entry->fd, oldctx, newctx);
+ctx.handle = new;
+ioctl(entry->fd, DRM_IOCTL_NEW_CTX, );
+}
+} while (drmHashNext(hash_table, , ));
+}
+}
+
+static int
+drmInstallSIGIOHandler(int fd, void (*f) (int, void *, void *))
+{
+drmHashEntry *entry;
+
+entry = drmGetEntry(fd);
+entry->f = f;
+
+return xf86InstallSIGIOHandler(fd, drmSIGIOHandler, 0);
+}
+
+static int
+drmRemoveSIGIOHandler(int fd)
+{
+drmHashEntry *entry = drmGetEntry(fd);
+
+entry->f = NULL;
+
+return xf86RemoveSIGIOHandler(fd);
+}
+
 Bool
 DRIScreenInit(ScreenPtr pScreen, DRIInfoPtr pDRIInfo, int *pDRMFD)
 {
@@ -2378,74 +2440,3 @@ DRICreatePCIBusID(const struct pci_device *dev)
 
 return busID;
 }
-
-static void
-drmSIGIOHandler(int interrupt, void *closure)
-{
-unsigned long key;
-void *value;
-ssize_t count;
-drm_ctx_t ctx;
-typedef void (*_drmCallback) (int, void *, void *);
-char buf[256];
-drm_context_t old;
-drm_context_t new;
-void *oldctx;
-void *newctx;
-char *pt;
-drmHashEntry *entry;
-void *hash_table;
-
-hash_table = drmGetHashTable();
-
-if (!hash_table)
-return;
-if (drmHashFirst(hash_table, , )) {
-entry = value;
-do {
-#if 0
-fprintf(stderr, "Trying %d\n", entry->fd);
-#endif
-if ((count = read(entry->fd, buf, sizeof(buf) - 1)) > 0) {
-buf[count] = '\0';
-#if 0
-fprintf(stderr, "Got %s\n", buf);
-#endif
-
-for (pt = buf; *pt != ' '; ++pt);   /* Find first space */
-++pt;
-old = strtol(pt, , 0);
-new = strtol(pt, NULL, 0);
-oldctx = drmGetContextTag(entry->fd, old);
-newctx = drmGetContextTag(entry->fd, new);
-#if 0
-fprintf(stderr, "%d %d %p %p\n", old, new, oldctx, newctx);
-#endif
-((_drmCallback) entry->f) (entry->fd, oldctx, newctx);
-ctx.handle = new;
-ioctl(entry->fd, DRM_IOCTL_NEW_CTX, );
-}
-} while (drmHashNext(hash_table, , ));
-}
-}
-
-int
-drmInstallSIGIOHandler(int fd, void (*f) (int, void *, void *))
-{
-drmHashEntry *entry;
-
-entry = drmGetEntry(fd);
-entry->f = f;
-
-return xf86InstallSIGIOHandler(fd, drmSIGIOHandler, 0);
-}
-
-int
-drmRemoveSIGIOHandler(int fd)
-{
-drmHashEntry *entry = drmGetEntry(fd);
-
-entry->f = NULL;
-
-return xf86RemoveSIGIOHandler(fd);
-}
diff --git a/hw/xfree86/dri/dri.h b/hw/xfree86/dri/dri.h
index 1ce0970..7e0337f 100644
--- a/hw/xfree86/dri/dri.h
+++ b/hw/xfree86/dri/dri.h
@@ -332,9 +332,6 @@ extern _X_EXPORT void DRIMoveBuffersHelper(ScreenPtr 
pScreen,
 
 extern _X_EXPORT char *DRICreatePCIBusID(const struct pci_device *PciInfo);
 
-extern _X_EXPORT int drmInstallSIGIOHandler(int fd,
-void (*f) (int, void *, void *));
-extern _X_EXPORT int drmRemoveSIGIOHandler(int fd);
 extern _X_EXPORT int DRIMasterFD(ScrnInfoPtr pScrn);
 
 extern _X_EXPORT void *DRIMasterSareaPointer(ScrnInfoPtr pScrn);
-- 
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

[PATCH xserver 4/5] xfree86: Undocument UseSIGIO in xorg.conf

2016-06-07 Thread Adam Jackson 
The doc text is wrong at this point, input processing isn't going to
vary based on this, so we shouldn't say it does. The only thing this
_does_ get used for is DRI1 SwapBuffers (on everything but savage), and
if you disable it you're not going to get DRI1 at all, so we really
shouldn't even mention it.

Still, leave the option wired up to the parser so we don't break any
DRI1-driver-using setup relying on it being disabled, and so we don't
complain about unused options elsewhere.

Signed-off-by: Adam Jackson 
---
 hw/xfree86/man/xorg.conf.man | 9 -
 1 file changed, 9 deletions(-)

diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man
index 8693cab..94b199e 100644
--- a/hw/xfree86/man/xorg.conf.man
+++ b/hw/xfree86/man/xorg.conf.man
@@ -511,15 +511,6 @@ core file.
 In general you never want to use this option unless you are debugging an Xorg
 server problem and know how to deal with the consequences.
 .TP 7
-.BI "Option \*qUseSIGIO\*q  \*q" boolean \*q
-This controls whether the Xorg server requests that events from
-input devices be reported via a SIGIO signal handler (also known as SIGPOLL
-on some platforms), or only reported via the standard select(3) loop.
-The default behaviour is platform specific.   In general you do not want to
-use this option unless you are debugging the Xorg server, or
-working around a specific bug until it is fixed, and understand the
-consequences.
-.TP 7
 .BI "Option \*qDontVTSwitch\*q  \*q" boolean \*q
 This disallows the use of the
 .BI Ctrl+Alt+F n
-- 
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

[PATCH mouse] bsd: Don't try to use SIGIO for input ABI >= 23

2016-06-07 Thread Adam Jackson 
Signed-off-by: Adam Jackson 
---
 src/bsd_mouse.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/bsd_mouse.c b/src/bsd_mouse.c
index a2c8ec7..dc628d4 100644
--- a/src/bsd_mouse.c
+++ b/src/bsd_mouse.c
@@ -546,8 +546,10 @@ usbMouseProc(DeviceIntPtr pPointer, int what)
 pInfo->fd = -1;
 } else {
 xf86FlushInput(pInfo->fd);
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 23
 if (!xf86InstallSIGIOHandler (pInfo->fd, usbSigioReadInput,
   pInfo))
+#endif
 AddEnabledDevice(pInfo->fd);
 }
 }
-- 
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 xserver] glamor: Limit outstanding drawing queue with glClientWaitSync

2016-06-07 Thread Keith Packard 
Michel Dänzer  writes:

> Is this about x11perf by any chance? I was seeing long lag with that as
> well, which turned out to be because we weren't correctly synchronizing
> with the hardware for XGetImage.

x11perf only does XGetImage once per run of the test; without some
intra-test queue management, other applications are unusable while the
test is running. This particular case isn't terribly interesting, but as
we improve glamor to need fewer and fewer synchronizations between CPU
and GPU, this should become relevant for interactions between regular
applications.

> In the amdgpu driver we now have a GPU scheduler managing the userspace
> command submissions.

That does seem like a fine place to manage this; right now, the intel
driver appears to only do this in SwapBuffers.

-- 
-keith


signature.asc
Description: PGP signature
___
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

Request for Proposal for XDC 2017

2016-06-07 Thread Daniel Vetter 
Hi all,

The X.org board is soliciting proposals to host XDC in 2017. By the usual
rotation a location in north america is preferred, but the board will also
consider other locations, especially if there's an interesting co-location
with another conference.

If you consider hosting XDC, we have assembled a wiki page with what's
generally expected and needed:

https://www.x.org/wiki/Events/RFP/

If possible the board would like to decide on the next location at XDC
2016 in Helsinki, please submit your proposal with at least the key
information about location, possible dates and estimated costs to
bo...@foundation.x.org latest by 31th August. An early quick heads-up to
the board if you consider hosting would also be good, in case we need to
adjust the schedule a bit. Also earlier is better since in generally there
will be a bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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 xserver] glamor: Limit outstanding drawing queue with glClientWaitSync

2016-06-07 Thread Michel Dänzer 
On 07.06.2016 01:02, Keith Packard wrote:
> Michel Dänzer  writes:
> 
>> I wrote an eerily similar patch a while ago, but the problem turned out
>> to be in the GL or kernel driver. Are you sure that's not the case for
>> you?
> 
> I'm seeing a long lag when running benchmarks that don't ever need
> to synchronize with the hardware.

Is this about x11perf by any chance? I was seeing long lag with that as
well, which turned out to be because we weren't correctly synchronizing
with the hardware for XGetImage.


> Given that the X server doesn't use SwapBuffers, I'm not sure where
> else we would expect rate limiting to occur?

In the amdgpu driver we now have a GPU scheduler managing the userspace
command submissions.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
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: [RFC] DRI3/PRESENT Add a way to select whether to use scanout or not depending on needs

2016-06-07 Thread Michel Dänzer 
On 07.06.2016 07:27, davya...@free.fr wrote:
> 
> Currently when a buffer is presented with the Present extension, in
> case it meets all the criterias to be used for a flip, the Xserver
> asks the DDX to check the pixmap can be used for a flip (check_flip),
> and if yes, X schedules a flip.
> 
> I guess *theoritically* (perhaps there may need a few patches for
> that) DDXs are supposed to refuse to flip for example if the format
> isn't compatible with the display format (non scanout vs scanout
> format).
> 
> If the driver uses scanout-able buffers, and the Xserver returns
> PresentCompleteModeCopy, then the driver can deduce it should be ok
> to reallocate its pixmaps and use ones without scanout formats, if
> better for efficiency or vram usage. However in case the driver uses
> non-scanout-able buffers, there is no way (except trying scanout-able
> buffers sometimes) to guess the Xserver could do flips if only the
> buffers were of another format.
> 
> 
> A similar but different issue also happen for DCC compression for
> radeon cards: In case of DCC, the memory for the buffer is allocated,
> but a compressed state of the buffer is contained in a separate
> buffer that some metadata describes (that the driver and ddx can
> read).
> 
> Currently the driver will always resolve such buffers before sending
> them to the Xserver, however ideally when not used for flips, it
> would be more efficient (performance and energy wise) to keep a
> compressed state. The ddx (via glamor) is able to understand these
> buffers without issues.
> 
> Similarly there'd need some information to tell whether such
> compression can be used or not (which currently is equivalent to the
> case described above for scanout: if we could flips, do not use DCC
> to be able to do flips, else use DCC). However the case is different,
> because one could argue that the DDX could resolve the buffer to
> allow the flip. But performance-wise, decompression is heavy, and it
> would be better for the driver to know about flips, and in that case
> it wouldn't compress that buffer in the first place (thus no need for
> decompression).
> 
> 
> 
> Has anyone suggestions to allow these two use cases ?
> 
> My suggestion is to add to the Present extension a new COMPLETE event
> that would say 'we do copy, but all conditions to flip were met,
> except the fact that the ddx said it couldn't flip with that
> buffer'.
> 
> How would people go with this proposition ?

One problem with this is that the DDX driver could refuse to flip for
other reasons, in which case the client side Present code could end up
flip-flopping between scanout/DCC enabled/disabled.

Instead, I'd propose adding an event which means something along the
lines of "you can try using buffers suitable for flipping now".


> My hypothesis is also that for some reason during rendering, we could
> switch from 'flips can be used' to 'flips cannot be used' and
> vice-versa, for example if playing a game fullscreen, then
> alt-tabbing (while game still rendering to the same size in the
> background) and then switching back.

Ignoring Wayland for a moment, unless I'm missing something, at least
one of two things always happens when a window becomes suitable for
flipping:

1. The window geometry changes
2. The window is unredirected

The new event could be sent on these two circumstances.


> Also when Wayland uses drm planes more, it may use this to hint apps
> going through XWayland use scanout-able buffers or not, so it's not
> just about fullscreen surfaces.

Xwayland could similarly send the new event at appropriate times.


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