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

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

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

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

Re: [PATCH xserver] os: Do timers under input lock, not blocked signals

Peter Hutterer writes: >> Signed-off-by: Keith Packard > > Reviewed-by: Peter Hutterer Merged. 88e981e..8174daa master -> master -- -keith signature.asc Description: PGP signature

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

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

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

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();

Re: [PATCH xserver] os: Do timers under input lock, not blocked signals

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

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

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

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

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 ___

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

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

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

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

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

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

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

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:

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

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

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

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

Re: [PATCH xserver 2/5] dmx: Remove SIGIO input support here too

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

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

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

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

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

[PATCH xserver 2/5] dmx: Remove SIGIO input support here too

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

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

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

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

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

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

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

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

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

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

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)

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

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

Request for Proposal for XDC 2017

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

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

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

Re: [RFC] DRI3/PRESENT Add a way to select whether to use scanout or not depending on needs

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