On 02/03/17 02:26 PM, Chen, Xiaogang wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>> On 23/02/17 06:46 AM, Chen, Xiaogang wrote:
From: Michel Dänzer [mailto:mic...@daenzer.net]
Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by
running
xrandr)
> -Original Message-
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Thursday, February 23, 2017 7:05 PM
> To: Chen, Xiaogang ; xorg-devel@lists.x.org
> Cc: jorge_monteag...@hotmail.com
> Subject: Re: [PATCH xserver] edid: Prune duplicates after adding modes from
> DDC
>
> On 2
On Wed, Mar 01, 2017 at 08:51:31AM +0100, Olivier Fourdan wrote:
> If a key event is sent programmatically, the virtual core keyboard does
> not have its dev->public.devicePrivate set and we can't get the Xwayland
> seat, in which case we end up crashing in keyboard_check_repeat().
>
> This is the
Adam Jackson writes:
> So, way back in 946f664b, I removed a cache from the miarc code, with the
> justification that arcs were rare and the performance improvement wasn't
> worth it. I'd have been more right if the miarc code wasn't, what's the
> word, garbage.
Hey, that's some of my finest cod
Adam Jackson writes:
> On Wed, 2017-03-01 at 00:07 -0800, Keith Packard wrote:
>> > Eric Anholt writes:
>>
>> > I tried to come up with a reason I would want a layer to be able to
>> > change the funcs per-gc at runtime, and failed. Yay for killing
>> > boilerplate.
>>
>> So, if we're changin
On Thu, 2017-02-16 at 14:58 -0500, Alex Deucher wrote:
> Seems reasonable to me. Series is:
> Acked-by: Alex Deucher
remote: I: patch #139300 updated using rev
35fbcb3f9987758bc26a87d5d7c033f4367cbd39.
remote: I: patch #139301 updated using rev
feed7e3f982a7ac14f6fe85ed2e1ec4a83700841.
remote
So, way back in 946f664b, I removed a cache from the miarc code, with the
justification that arcs were rare and the performance improvement wasn't
worth it. I'd have been more right if the miarc code wasn't, what's the
word, garbage.
Turns out that for dashed arcs we end up computing an 'miArcSpan
This avoids recomputing the span data for every dash. x11perf thinks
this is a pretty modest speedup:
832919.4 840471.1 ( 1.009) 100-pixel dashed ellipse
672353.1 680652.2 ( 1.012) 100-pixel double-dashed ellipse
13748.924287.9 ( 1.767) 100-pixel wide dashed
drawArc does some fairly expensive computation, but it's only sensitive
to arc width/height. Thread the span data up through the call chain so
it's at least possible for the caller to cache things.
Signed-off-by: Adam Jackson
---
mi/miarc.c | 64 ++
Outdent, normalize comment formatting, and use 'goto out' idiom for
error paths. No functional change.
Signed-off-by: Adam Jackson
---
mi/miarc.c | 368 ++---
1 file changed, 179 insertions(+), 189 deletions(-)
diff --git a/mi/miarc.c b/mi
On Wed, 2017-03-01 at 00:07 -0800, Keith Packard wrote:
> > Eric Anholt writes:
>
> > I tried to come up with a reason I would want a layer to be able to
> > change the funcs per-gc at runtime, and failed. Yay for killing
> > boilerplate.
>
> So, if we're changing wrappers, anyone want to consi
On Wed, 2017-03-01 at 20:28 +0100, Matthieu Herrb wrote:
> - typo in #ifdef check
> - also need to add AC_CHECK_FUNCS([arc4random_buf])
>
> Reported-by Eric Engestrom. Thanks
>
> Signed-off-by: Matthieu Herrb
remote: I: patch #141514 updated using rev
386fbbe410a1168b724136e54cf3bd37fb64ad4e.
- typo in #ifdef check
- also need to add AC_CHECK_FUNCS([arc4random_buf])
Reported-by Eric Engestrom. Thanks
Signed-off-by: Matthieu Herrb
---
configure.ac | 1 +
os/auth.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 6a7c4cc6f..a61
On Wed, 2017-03-01 at 14:05 -0500, Adam Jackson wrote:
> Mmm, that's weird though. After this change the code is is "if have
> tile pixmap, prepare access; call down to fbValidateGC; if have tile
> pixmap && false, finish access". I can't imagine leaving the tile
> prepared is the intent, but that
On Thu, 2017-03-02 at 01:04 +0900, Michel Dänzer wrote:
> On 02/03/17 12:33 AM, Adam Jackson wrote:
> >
> > -
> > -/* Sometimes tile pixmaps are swapped, you need access to:
> > - * - The current tile if it depth matches.
> > - * - Or the rotated tile if that one matches de
On Wednesday, 2017-03-01 17:45:12 +0100, Olivier Fourdan wrote:
> Not all compositors allow for customizing the Xwayland command line,
> gnome-shell/mutter for example have the command line and path to
> Xwayland binary hardcoded, which makes it harder for users to disable
> glamor acceleration in
On Tuesday, 2017-02-28 19:18:43 +0100, Matthieu Herrb wrote:
> Signed-off-by: Matthieu Herrb
> ---
> configure.ac| 2 ++
> include/dix-config.h.in | 6 ++
> os/auth.c | 7 +++
> 3 files changed, 15 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> ind
On 28 February 2017 at 22:52, Matthieu Herrb wrote:
>
> On Tue, Feb 28, 2017 at 10:41:29PM +, Emil Velikov wrote:
>> Hi Matthieu,
>>
>> On 28 February 2017 at 18:18, Matthieu Herrb wrote:
>> > Provide the function definition for systems that don't have it.
>> >
>> > Signed-off-by: Matthieu He
Hi all,
I am seeing quite a few Xwayland crashes related to glamor.
Various issues, could be with glamor itself or with the drivers (like the
issues I witness with nv30), whatever.
To investigate those issues (or even unblock affected users) it's often
useful to disable glamor -even temporarily-
Not all compositors allow for customizing the Xwayland command line,
gnome-shell/mutter for example have the command line and path to
Xwayland binary hardcoded, which makes it harder for users to disable
glamor acceleration in Xwayland (glamor being used by default).
Add an environment variable XW
On 02/03/17 12:33 AM, Adam Jackson wrote:
> The "tile depth != drawable depth" conditional can't be true, the
> protocol requires a match.
>
> Signed-off-by: Adam Jackson
> ---
> exa/exa.c | 22 --
> 1 file changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/exa/exa.c
On 02/23/2017 07:59 PM, Adam Jackson wrote:
> I pushed essentially this version of the patch (pos not gl_Position),
> having not read far enough down in the mailbox to see this version.
> (And, Dieter's right, picking on the little shit really is
> counterproductive for one-liners.)
>
> That said,
Bye Felisha.
v2:
- Require power-of-two bpp in ScreenInit
- Eliminate fbCreatePixmapBpp
Signed-off-by: Adam Jackson
---
fb/Makefile.am | 2 -
fb/fb.h| 165 -
fb/fb24_32.c | 548 -
fb/fb24_32.h | 44 -
fb/
Signed-off-by: Adam Jackson
---
glamor/glamor_core.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 7b2b396..610ae71 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -200,43 +200,6 @@ glamo
The "tile depth != drawable depth" conditional can't be true, the
protocol requires a match.
Signed-off-by: Adam Jackson
---
exa/exa.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 7266b71..af0185f 100644
--- a/exa/exa.c
+
There's really no reason to pretend to support this, apps hate it, all
we're doing is giving people a way to injure themselves. It doesn't work
anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
silently igno
Eric Anholt writes:
> I tried to come up with a reason I would want a layer to be able to
> change the funcs per-gc at runtime, and failed. Yay for killing
> boilerplate.
So, if we're changing wrappers, anyone want to consider a more
outlandish plan, like replacing the current ad-hoc plan of st
27 matches
Mail list logo
