Else it is read before initialization if XSERVER_LIBPCIACCESS is not defined
or location.type is not BUS_PCI.
Noticed when I got a segfault where it was 0x1 while doing some tests on arm.
Signed-off-by: Pascal Terjan
---
src/fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On 22 January 2016 at 12:36, Eric Anholt wrote:
> Here are my fixes for the regressions in the glamor-core-profile
> series. The first commit would go just before the GL_RED change, then
> I'd squash the other two into GL_RED. The series is now in
> glamor-core-profile of my fdo tree.
all 3 of
Eric Anholt writes:
> if (op == PictOpSrc) {
> +/* We can't do direct copies between different depths at 16bpp
> + * because r,g,b are allocated to different bits.
> + */
> +if (dst->pDrawable->bitsPerPixel == 16 &&
> +dst->pDrawable->depth != src-
Signed-off-by: Eric Anholt
---
glamor/glamor_render.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index c36b345..51718d1 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@
We only need it once at the top of the shader, so just put it
there.
Signed-off-by: Eric Anholt
---
glamor/glamor_render.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index e4beafc..7a50fe9 100644
--- a/gl
Signed-off-by: Eric Anholt
---
glamor/glamor_priv.h | 10 +-
glamor/glamor_render.c | 50 +++---
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 558ed63..f1eed5b 100644
--- a/gl
Here are my fixes for the regressions in the glamor-core-profile
series. The first commit would go just before the GL_RED change, then
I'd squash the other two into GL_RED. The series is now in
glamor-core-profile of my fdo tree.
Eric Anholt (3):
glamor: Drop duplicated GLAMOR_DEFAULT_PRECISIO
On Thu, Jan 21, 2016 at 11:54:19AM +0100, Olivier Fourdan wrote:
> XkbGetKeyboardByName relies on flags to read the data from the server.
>
> If the X server sends us the wrong flags or if a subreply is smaller
> than it should be, XkbGetKeyboardByName will not read all the available
> data and le
On 22 January 2016 at 07:06, Eric Anholt wrote:
> I originally inherited this from the EXA code, without determining
> whether it was really needed. Regular composite should end up doing
> the same thing, since it's all just shaders anyway. To the extent
> that it doesn't, we should fix composit
On 22 January 2016 at 07:06, Eric Anholt wrote:
> Please cherry-pick this to active stable branches.
>
> Reading and writing to 16-depth pixmaps using PICT_x1r5g5b5 ends up
> failing, unless you're doing a straight copy at the same bpp where the
> misinterpretation matches on both sides.
>
> Fixes
I originally inherited this from the EXA code, without determining
whether it was really needed. Regular composite should end up doing
the same thing, since it's all just shaders anyway. To the extent
that it doesn't, we should fix composite.
Signed-off-by: Eric Anholt
---
glamor/glamor_render
Please cherry-pick this to active stable branches.
Reading and writing to 16-depth pixmaps using PICT_x1r5g5b5 ends up
failing, unless you're doing a straight copy at the same bpp where the
misinterpretation matches on both sides.
Fixes rendercheck/blend/over and renderhceck/blend/src in piglit.
On Wed, 2016-01-20 at 15:50 -0500, Adam Jackson wrote:
> As of v4 of this extension, any GLES version number may be requested (to
> enable GLES3 and later). To comply with this, simply remove the API
> version checks and leave it to the DRI driver to validate. This happens
> to also enable using GL
XkbGetKeyboardByName relies on flags to read the data from the server.
If the X server sends us the wrong flags or if a subreply is smaller
than it should be, XkbGetKeyboardByName will not read all the available
data and leave data in the buffer, which will cause the next _XReply()
to fail with:
On Thu, Jan 21, 2016 at 10:48:05AM +0100, Olivier Fourdan wrote:
> XkbGetKeyboardByName relies on flags to read the data from the server.
>
> If the X server sends us the wrong flags or if a subreply is smaller
> than it should be, XkbGetKeyboardByName will not read all the available
> data and le
On 21 January 2016 at 09:48, Olivier Fourdan wrote:
> XkbGetKeyboardByName relies on flags to read the data from the server.
>
> If the X server sends us the wrong flags or if a subreply is smaller
> than it should be, XkbGetKeyboardByName will not read all the available
> data and leave data in t
XkbGetKeyboardByName relies on flags to read the data from the server.
If the X server sends us the wrong flags or if a subreply is smaller
than it should be, XkbGetKeyboardByName will not read all the available
data and leave data in the buffer, which will cause the next _XReply()
to fail with:
Hi,
On 21 January 2016 at 08:58, Olivier Fourdan wrote:
> XkbGetKeyboardByName relies on flags to read the data from the server.
>
> If the X server sends us the wrong flags or if a subreply is smaller
> than it should be, XkbGetKeyboardByName will not read all the available
> data and leave data
+ Peter of course!
On 21 January 2016 at 09:58, Olivier Fourdan wrote:
> XkbGetKeyboardByName relies on flags to read the data from the server.
>
> If the X server sends us the wrong flags or if a subreply is smaller
> than it should be, XkbGetKeyboardByName will not read all the available
> dat
XkbGetKeyboardByName relies on flags to read the data from the server.
If the X server sends us the wrong flags or if a subreply is smaller
than it should be, XkbGetKeyboardByName will not read all the available
data and leave data in the buffer, which will cause the next _XReply()
to fail with:
20 matches
Mail list logo
