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
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
Peter Hutterer writes:
>> Signed-off-by: Keith Packard
>
> Reviewed-by: Peter Hutterer
Merged.
88e981e..8174daa master -> master
--
-keith
signature.asc
Description: PGP signature
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
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();
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
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
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
___
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
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
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
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:
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
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
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
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
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
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
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 ++---
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
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
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
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)
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
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
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
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.
>
>
27 matches
Mail list logo