[PATCH libX11 v3] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Olivier Fourdan 
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:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
Aborted

Check if there is some extra data left at the end of
XkbGetKeyboardByName() and discard that data if any is found.

Many thanks to Peter Hutterer  for finding the
root cause of the issue and Adam Jackson  for helping
with the analysis!

Signed-off-by: Olivier Fourdan 
---
v2: bail out if extra data is found, do not return success.
v3: fix indentation, remove warning message

 src/xkb/XKBGetByName.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/xkb/XKBGetByName.c b/src/xkb/XKBGetByName.c
index 973052c..efd985b 100644
--- a/src/xkb/XKBGetByName.c
+++ b/src/xkb/XKBGetByName.c
@@ -44,7 +44,7 @@ XkbGetKeyboardByName(Display *dpy,
 {
 register xkbGetKbdByNameReq *req;
 xkbGetKbdByNameReply rep;
-int len, extraLen;
+int len, extraLen = 0;
 char *str;
 XkbDescPtr xkb;
 int mapLen, codesLen, typesLen, compatLen;
@@ -204,12 +204,16 @@ XkbGetKeyboardByName(Display *dpy,
 if (status != Success)
 goto BAILOUT;
 }
+if (extraLen > 0)
+   goto BAILOUT;
 UnlockDisplay(dpy);
 SyncHandle();
 return xkb;
  BAILOUT:
 if (xkb != NULL)
 XkbFreeKeyboard(xkb, XkbAllComponentsMask, xTrue);
+if (extraLen > 0)
+_XEatData(dpy, extraLen);
 UnlockDisplay(dpy);
 SyncHandle();
 return NULL;
-- 
2.5.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libX11] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Olivier Fourdan 
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:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
Aborted

Check if there is some extra data left at the end of
XkbGetKeyboardByName() and discard that data if any is found.

Many thanks to Peter Hutterer  for finding the
root cause of the issue and Adam Jackson  for helping
with the analysis!

Signed-off-by: Olivier Fourdan 
---
 src/xkb/XKBGetByName.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/xkb/XKBGetByName.c b/src/xkb/XKBGetByName.c
index 973052c..01927fc 100644
--- a/src/xkb/XKBGetByName.c
+++ b/src/xkb/XKBGetByName.c
@@ -28,12 +28,23 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
 #ifdef HAVE_CONFIG_H
 #include 
 #endif
+#include 
+
 #include "Xlibint.h"
 #include 
 #include "XKBlibint.h"
 
 /******/
 
+static void
+_discardExtraLen(Display *dpy, int extraLen)
+{
+fprintf(stderr,
+   "XkbGetKeyboardByName: server returned wrong data, discarding %i 
bytes\n",
+   extraLen);
+_XEatData(dpy, extraLen);
+}
+
 XkbDescPtr
 XkbGetKeyboardByName(Display *dpy,
  unsigned deviceSpec,
@@ -44,7 +55,7 @@ XkbGetKeyboardByName(Display *dpy,
 {
 register xkbGetKbdByNameReq *req;
 xkbGetKbdByNameReply rep;
-int len, extraLen;
+int len, extraLen = 0;
 char *str;
 XkbDescPtr xkb;
 int mapLen, codesLen, typesLen, compatLen;
@@ -204,12 +215,16 @@ XkbGetKeyboardByName(Display *dpy,
 if (status != Success)
 goto BAILOUT;
 }
+if (extraLen > 0)
+   _discardExtraLen(dpy, extraLen);
 UnlockDisplay(dpy);
 SyncHandle();
 return xkb;
  BAILOUT:
 if (xkb != NULL)
 XkbFreeKeyboard(xkb, XkbAllComponentsMask, xTrue);
+if (extraLen > 0)
+   _discardExtraLen(dpy, extraLen);
 UnlockDisplay(dpy);
 SyncHandle();
 return NULL;
-- 
2.5.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Olivier Fourdan 
+ 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
> data and leave data in the buffer, which will cause the next _XReply()
> to fail with:
>
> [xcb] Extra reply data still left in queue
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
> Aborted
>
> Check if there is some extra data left at the end of
> XkbGetKeyboardByName() and discard that data if any is found.
>
> Many thanks to Peter Hutterer  for finding the
> root cause of the issue and Adam Jackson  for helping
> with the analysis!
>
> Signed-off-by: Olivier Fourdan 
> ---
>  src/xkb/XKBGetByName.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/src/xkb/XKBGetByName.c b/src/xkb/XKBGetByName.c
> index 973052c..01927fc 100644
> --- a/src/xkb/XKBGetByName.c
> +++ b/src/xkb/XKBGetByName.c
> @@ -28,12 +28,23 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  #ifdef HAVE_CONFIG_H
>  #include 
>  #endif
> +#include 
> +
>  #include "Xlibint.h"
>  #include 
>  #include "XKBlibint.h"
>
>
>  /******/
>
> +static void
> +_discardExtraLen(Display *dpy, int extraLen)
> +{
> +fprintf(stderr,
> +   "XkbGetKeyboardByName: server returned wrong data, discarding %i
> bytes\n",
> +   extraLen);
> +_XEatData(dpy, extraLen);
> +}
> +
>  XkbDescPtr
>  XkbGetKeyboardByName(Display *dpy,
>   unsigned deviceSpec,
> @@ -44,7 +55,7 @@ XkbGetKeyboardByName(Display *dpy,
>  {
>  register xkbGetKbdByNameReq *req;
>  xkbGetKbdByNameReply rep;
> -int len, extraLen;
> +int len, extraLen = 0;
>  char *str;
>  XkbDescPtr xkb;
>  int mapLen, codesLen, typesLen, compatLen;
> @@ -204,12 +215,16 @@ XkbGetKeyboardByName(Display *dpy,
>  if (status != Success)
>  goto BAILOUT;
>  }
> +if (extraLen > 0)
> +   _discardExtraLen(dpy, extraLen);
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return xkb;
>   BAILOUT:
>  if (xkb != NULL)
>  XkbFreeKeyboard(xkb, XkbAllComponentsMask, xTrue);
> +if (extraLen > 0)
> +   _discardExtraLen(dpy, extraLen);
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return NULL;
> --
> 2.5.0
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libX11 v2] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Olivier Fourdan 
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:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
Aborted

Check if there is some extra data left at the end of
XkbGetKeyboardByName() and discard that data if any is found.

Many thanks to Peter Hutterer  for finding the
root cause of the issue and Adam Jackson  for helping
with the analysis!

Signed-off-by: Olivier Fourdan 
---
v2: bail out if extra data is found, do not return success.

 src/xkb/XKBGetByName.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/xkb/XKBGetByName.c b/src/xkb/XKBGetByName.c
index 973052c..af2536a 100644
--- a/src/xkb/XKBGetByName.c
+++ b/src/xkb/XKBGetByName.c
@@ -28,12 +28,23 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
 #ifdef HAVE_CONFIG_H
 #include 
 #endif
+#include 
+
 #include "Xlibint.h"
 #include 
 #include "XKBlibint.h"
 
 /******/
 
+static void
+_discardExtraLen(Display *dpy, int extraLen)
+{
+fprintf(stderr,
+   "XkbGetKeyboardByName: server returned wrong data, discarding %i 
bytes\n",
+   extraLen);
+_XEatData(dpy, extraLen);
+}
+
 XkbDescPtr
 XkbGetKeyboardByName(Display *dpy,
  unsigned deviceSpec,
@@ -44,7 +55,7 @@ XkbGetKeyboardByName(Display *dpy,
 {
 register xkbGetKbdByNameReq *req;
 xkbGetKbdByNameReply rep;
-int len, extraLen;
+int len, extraLen = 0;
 char *str;
 XkbDescPtr xkb;
 int mapLen, codesLen, typesLen, compatLen;
@@ -204,12 +215,16 @@ XkbGetKeyboardByName(Display *dpy,
 if (status != Success)
 goto BAILOUT;
 }
+if (extraLen > 0)
+   goto BAILOUT;
 UnlockDisplay(dpy);
 SyncHandle();
 return xkb;
  BAILOUT:
 if (xkb != NULL)
 XkbFreeKeyboard(xkb, XkbAllComponentsMask, xTrue);
+if (extraLen > 0)
+   _discardExtraLen(dpy, extraLen);
 UnlockDisplay(dpy);
 SyncHandle();
 return NULL;
-- 
2.5.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 v2] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Peter Hutterer 
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 leave data in the buffer, which will cause the next _XReply()
> to fail with:
> 
> [xcb] Extra reply data still left in queue
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
> Aborted
> 
> Check if there is some extra data left at the end of
> XkbGetKeyboardByName() and discard that data if any is found.
> 
> Many thanks to Peter Hutterer  for finding the
> root cause of the issue and Adam Jackson  for helping
> with the analysis!
> 
> Signed-off-by: Olivier Fourdan 
> ---
> v2: bail out if extra data is found, do not return success.

fwiw, I checked the other usages of _XEatData and none of them have a
warning message, so I think we can do the same behaviour here - as long as
we return NULL an error is signalled and we should be fine.

also: note the all-space, not tab, indentation. tabs were expensive in the
80s.

Cheers,
   Peter

> 
>  src/xkb/XKBGetByName.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/src/xkb/XKBGetByName.c b/src/xkb/XKBGetByName.c
> index 973052c..af2536a 100644
> --- a/src/xkb/XKBGetByName.c
> +++ b/src/xkb/XKBGetByName.c
> @@ -28,12 +28,23 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  #ifdef HAVE_CONFIG_H
>  #include 
>  #endif
> +#include 
> +
>  #include "Xlibint.h"
>  #include 
>  #include "XKBlibint.h"
>  
>  /******/
>  
> +static void
> +_discardExtraLen(Display *dpy, int extraLen)
> +{
> +fprintf(stderr,
> + "XkbGetKeyboardByName: server returned wrong data, discarding %i 
> bytes\n",
> + extraLen);
> +_XEatData(dpy, extraLen);
> +}
> +
>  XkbDescPtr
>  XkbGetKeyboardByName(Display *dpy,
>   unsigned deviceSpec,
> @@ -44,7 +55,7 @@ XkbGetKeyboardByName(Display *dpy,
>  {
>  register xkbGetKbdByNameReq *req;
>  xkbGetKbdByNameReply rep;
> -int len, extraLen;
> +int len, extraLen = 0;
>  char *str;
>  XkbDescPtr xkb;
>  int mapLen, codesLen, typesLen, compatLen;
> @@ -204,12 +215,16 @@ XkbGetKeyboardByName(Display *dpy,
>  if (status != Success)
>  goto BAILOUT;
>  }
> +if (extraLen > 0)
> + goto BAILOUT;
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return xkb;
>   BAILOUT:
>  if (xkb != NULL)
>  XkbFreeKeyboard(xkb, XkbAllComponentsMask, xTrue);
> +if (extraLen > 0)
> + _discardExtraLen(dpy, extraLen);
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return NULL;
> -- 
> 2.5.0
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Daniel Stone 
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 in the buffer, which will cause the next _XReply()
> to fail with:
>
> [xcb] Extra reply data still left in queue
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
> Aborted
>
> Check if there is some extra data left at the end of
> XkbGetKeyboardByName() and discard that data if any is found.

Thanks, that looks really good! (And I almost wonder if we shouldn't
cache data from the last reply - request/sequence number, etc - to
make that error a bit more friendly.)

> @@ -204,12 +215,16 @@ XkbGetKeyboardByName(Display *dpy,
>  if (status != Success)
>  goto BAILOUT;
>  }
> +if (extraLen > 0)
> +   _discardExtraLen(dpy, extraLen);
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return xkb;

This case seems like it shouldn't return success, but instead jump to
BAILOUT; if there's extra unconsumed data, either the server is
broken, or we've missed something.

With that fixed:
Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 v2] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Daniel Stone 
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 the buffer, which will cause the next _XReply()
> to fail with:
>
> [xcb] Extra reply data still left in queue
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
> Aborted
>
> Check if there is some extra data left at the end of
> XkbGetKeyboardByName() and discard that data if any is found.
>
> Many thanks to Peter Hutterer  for finding the
> root cause of the issue and Adam Jackson  for helping
> with the analysis!
>
> Signed-off-by: Olivier Fourdan 

Reviewed-by: Daniel Stone 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glx: Fix GLX_EXT_create_context_es2_profile support

2016-01-21 Thread Adam Jackson 
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 GLES1 in direct contexts, so if that's the dire
> situation you find yourself in, your client driver at least stands a
> chance of working.
> 
> v4 also specifies that both extension strings should be advertised for
> compatibility with clients written against v1 of the extension spec, so
> add the es_profile bit to the extension list and enable it whenever we
> would enable es2_profile.

 ajax: btw, +1 on your version of the glx ES2 patch. i'm not
   on the list, so i can't reply to it. but i'm fairly sure 
   it'll work at least as well as my version of the patch.

Treating that as an R-b.

remote: I: patch #71182 updated using rev 
bc415fb1e0031ad23bda6e9c3f4664532876a0e5.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   49aa5e3..bc415fb  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 v3] XKB: fix XkbGetKeyboardByName with Xming server

2016-01-21 Thread Peter Hutterer 
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 leave data in the buffer, which will cause the next _XReply()
> to fail with:
> 
> [xcb] Extra reply data still left in queue
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
> Aborted
> 
> Check if there is some extra data left at the end of
> XkbGetKeyboardByName() and discard that data if any is found.
> 
> Many thanks to Peter Hutterer  for finding the
> root cause of the issue and Adam Jackson  for helping
> with the analysis!
> 
> Signed-off-by: Olivier Fourdan 

   43ba0a6..7eb724d  master -> master

thanks!

Cheers,
   Peter


> ---
> v2: bail out if extra data is found, do not return success.
> v3: fix indentation, remove warning message
> 
>  src/xkb/XKBGetByName.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/xkb/XKBGetByName.c b/src/xkb/XKBGetByName.c
> index 973052c..efd985b 100644
> --- a/src/xkb/XKBGetByName.c
> +++ b/src/xkb/XKBGetByName.c
> @@ -44,7 +44,7 @@ XkbGetKeyboardByName(Display *dpy,
>  {
>  register xkbGetKbdByNameReq *req;
>  xkbGetKbdByNameReply rep;
> -int len, extraLen;
> +int len, extraLen = 0;
>  char *str;
>  XkbDescPtr xkb;
>  int mapLen, codesLen, typesLen, compatLen;
> @@ -204,12 +204,16 @@ XkbGetKeyboardByName(Display *dpy,
>  if (status != Success)
>  goto BAILOUT;
>  }
> +if (extraLen > 0)
> + goto BAILOUT;
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return xkb;
>   BAILOUT:
>  if (xkb != NULL)
>  XkbFreeKeyboard(xkb, XkbAllComponentsMask, xTrue);
> +if (extraLen > 0)
> +_XEatData(dpy, extraLen);
>  UnlockDisplay(dpy);
>  SyncHandle();
>  return NULL;
> -- 
> 2.5.0
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

2016-01-21 Thread Eric Anholt 
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.

Signed-off-by: Eric Anholt 
---
 glamor/glamor_render.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index d8574ec..92b6b0c 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -512,6 +512,14 @@ static int
 compatible_formats(CARD8 op, PicturePtr dst, PicturePtr src)
 {
 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->pDrawable->depth) {
+return 0;
+}
+
 if (src->format == dst->format)
 return 1;
 
-- 
2.6.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 2/2] glamor: Drop the composite_with_copy path entirely.

2016-01-21 Thread Eric Anholt 
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.c | 92 --
 1 file changed, 92 deletions(-)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 92b6b0c..1b226aa 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -508,41 +508,6 @@ glamor_set_composite_solid(float *color, GLint 
uniform_location)
 glUniform4fv(uniform_location, 1, color);
 }
 
-static int
-compatible_formats(CARD8 op, PicturePtr dst, PicturePtr src)
-{
-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->pDrawable->depth) {
-return 0;
-}
-
-if (src->format == dst->format)
-return 1;
-
-if (src->format == PICT_a8r8g8b8 && dst->format == PICT_x8r8g8b8)
-return 1;
-
-if (src->format == PICT_a8b8g8r8 && dst->format == PICT_x8b8g8r8)
-return 1;
-}
-else if (op == PictOpOver) {
-if (src->alphaMap || dst->alphaMap)
-return 0;
-
-if (src->format != dst->format)
-return 0;
-
-if (src->format == PICT_x8r8g8b8 || src->format == PICT_x8b8g8r8)
-return 1;
-}
-
-return 0;
-}
-
 static char
 glamor_get_picture_location(PicturePtr picture)
 {
@@ -564,54 +529,6 @@ glamor_get_picture_location(PicturePtr picture)
 return glamor_get_drawable_location(picture->pDrawable);
 }
 
-static Bool
-glamor_composite_with_copy(CARD8 op,
-   PicturePtr source,
-   PicturePtr dest,
-   INT16 x_source,
-   INT16 y_source,
-   INT16 x_dest, INT16 y_dest, RegionPtr region)
-{
-int ret = FALSE;
-
-if (!source->pDrawable)
-return FALSE;
-
-if (!compatible_formats(op, dest, source))
-return FALSE;
-
-if (source->repeat || source->transform) {
-return FALSE;
-}
-
-x_dest += dest->pDrawable->x;
-y_dest += dest->pDrawable->y;
-x_source += source->pDrawable->x;
-y_source += source->pDrawable->y;
-if (PICT_FORMAT_A(source->format) == 0) {
-/* Fallback if we sample outside the source so that we
- * swizzle the correct clear color for out-of-bounds texels.
- */
-if (region->extents.x1 + x_source - x_dest < 0)
-goto cleanup_region;
-if (region->extents.x2 + x_source - x_dest > source->pDrawable->width)
-goto cleanup_region;
-
-if (region->extents.y1 + y_source - y_dest < 0)
-goto cleanup_region;
-if (region->extents.y2 + y_source - y_dest > source->pDrawable->height)
-goto cleanup_region;
-}
-glamor_copy(source->pDrawable,
-dest->pDrawable, NULL,
-RegionRects(region), RegionNumRects(region),
-x_source - x_dest, y_source - y_dest,
-FALSE, FALSE, 0, NULL);
-ret = TRUE;
- cleanup_region:
-return ret;
-}
-
 static void *
 glamor_setup_composite_vbo(ScreenPtr screen, int n_verts)
 {
@@ -1451,15 +1368,6 @@ glamor_composite_clipped_region(CARD8 op,
 }
 }
 
-if (!mask && temp_src) {
-if (glamor_composite_with_copy(op, temp_src, dest,
-   x_temp_src, y_temp_src,
-   x_dest, y_dest, region)) {
-ok = TRUE;
-goto out;
-}
-}
-
 if (temp_src_pixmap == dest_pixmap) {
 glamor_fallback("source and dest pixmaps are the same\n");
 goto out;
-- 
2.6.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

2016-01-21 Thread Dave Airlie 
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 rendercheck/blend/over and renderhceck/blend/src in piglit.
>
> Signed-off-by: Eric Anholt 

makes sense,
Reviewed-by: Dave Airlie 

> ---
>  glamor/glamor_render.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index d8574ec..92b6b0c 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -512,6 +512,14 @@ static int
>  compatible_formats(CARD8 op, PicturePtr dst, PicturePtr src)
>  {
>  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->pDrawable->depth) {
> +return 0;
> +}
> +
>  if (src->format == dst->format)
>  return 1;
>
> --
> 2.6.4
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/2] glamor: Drop the composite_with_copy path entirely.

2016-01-21 Thread Dave Airlie 
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 composite.

For EXA I could see us caring, for glamor not so much. Though I
suppose in theory we could
have a blitfb based copy that is faster, but we don't.

Reviewed-by: Dave Airlie 
>
> Signed-off-by: Eric Anholt 
> ---
>  glamor/glamor_render.c | 92 
> --
>  1 file changed, 92 deletions(-)
>
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index 92b6b0c..1b226aa 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -508,41 +508,6 @@ glamor_set_composite_solid(float *color, GLint 
> uniform_location)
>  glUniform4fv(uniform_location, 1, color);
>  }
>
> -static int
> -compatible_formats(CARD8 op, PicturePtr dst, PicturePtr src)
> -{
> -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->pDrawable->depth) {
> -return 0;
> -}
> -
> -if (src->format == dst->format)
> -return 1;
> -
> -if (src->format == PICT_a8r8g8b8 && dst->format == PICT_x8r8g8b8)
> -return 1;
> -
> -if (src->format == PICT_a8b8g8r8 && dst->format == PICT_x8b8g8r8)
> -return 1;
> -}
> -else if (op == PictOpOver) {
> -if (src->alphaMap || dst->alphaMap)
> -return 0;
> -
> -if (src->format != dst->format)
> -return 0;
> -
> -if (src->format == PICT_x8r8g8b8 || src->format == PICT_x8b8g8r8)
> -return 1;
> -}
> -
> -return 0;
> -}
> -
>  static char
>  glamor_get_picture_location(PicturePtr picture)
>  {
> @@ -564,54 +529,6 @@ glamor_get_picture_location(PicturePtr picture)
>  return glamor_get_drawable_location(picture->pDrawable);
>  }
>
> -static Bool
> -glamor_composite_with_copy(CARD8 op,
> -   PicturePtr source,
> -   PicturePtr dest,
> -   INT16 x_source,
> -   INT16 y_source,
> -   INT16 x_dest, INT16 y_dest, RegionPtr region)
> -{
> -int ret = FALSE;
> -
> -if (!source->pDrawable)
> -return FALSE;
> -
> -if (!compatible_formats(op, dest, source))
> -return FALSE;
> -
> -if (source->repeat || source->transform) {
> -return FALSE;
> -}
> -
> -x_dest += dest->pDrawable->x;
> -y_dest += dest->pDrawable->y;
> -x_source += source->pDrawable->x;
> -y_source += source->pDrawable->y;
> -if (PICT_FORMAT_A(source->format) == 0) {
> -/* Fallback if we sample outside the source so that we
> - * swizzle the correct clear color for out-of-bounds texels.
> - */
> -if (region->extents.x1 + x_source - x_dest < 0)
> -goto cleanup_region;
> -if (region->extents.x2 + x_source - x_dest > 
> source->pDrawable->width)
> -goto cleanup_region;
> -
> -if (region->extents.y1 + y_source - y_dest < 0)
> -goto cleanup_region;
> -if (region->extents.y2 + y_source - y_dest > 
> source->pDrawable->height)
> -goto cleanup_region;
> -}
> -glamor_copy(source->pDrawable,
> -dest->pDrawable, NULL,
> -RegionRects(region), RegionNumRects(region),
> -x_source - x_dest, y_source - y_dest,
> -FALSE, FALSE, 0, NULL);
> -ret = TRUE;
> - cleanup_region:
> -return ret;
> -}
> -
>  static void *
>  glamor_setup_composite_vbo(ScreenPtr screen, int n_verts)
>  {
> @@ -1451,15 +1368,6 @@ glamor_composite_clipped_region(CARD8 op,
>  }
>  }
>
> -if (!mask && temp_src) {
> -if (glamor_composite_with_copy(op, temp_src, dest,
> -   x_temp_src, y_temp_src,
> -   x_dest, y_dest, region)) {
> -ok = TRUE;
> -goto out;
> -}
> -}
> -
>  if (temp_src_pixmap == dest_pixmap) {
>  glamor_fallback("source and dest pixmaps are the same\n");
>  goto out;
> --
> 2.6.4
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 1/3] glamor: Drop duplicated GLAMOR_DEFAULT_PRECISIONs in render accel.

2016-01-21 Thread Eric Anholt 
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/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -72,7 +72,6 @@ glamor_create_composite_fs(struct shader_key *key)
 "uniform int   source_repeat_mode;\n"
 "uniform int   mask_repeat_mode;\n";
 const char *relocate_texture =
-GLAMOR_DEFAULT_PRECISION
 "vec2 rel_tex_coord(vec2 texture, vec4 wh, int repeat) \n"
 "{\n"
 "   vec2 rel_tex; \n"
@@ -119,14 +118,12 @@ glamor_create_composite_fs(struct shader_key *key)
 "}\n";
 
 const char *source_solid_fetch =
-GLAMOR_DEFAULT_PRECISION
 "uniform vec4 source;\n"
 "vec4 get_source()\n"
 "{\n"
 "  return source;\n"
 "}\n";
 const char *source_alpha_pixmap_fetch =
-GLAMOR_DEFAULT_PRECISION
 "varying vec2 source_texture;\n"
 "uniform sampler2D source_sampler;\n"
 "uniform vec4 source_wh;"
@@ -139,7 +136,6 @@ glamor_create_composite_fs(struct shader_key *key)
 " source_wh, source_repeat_mode, 0);\n"
 "}\n";
 const char *source_pixmap_fetch =
-GLAMOR_DEFAULT_PRECISION
 "varying vec2 source_texture;\n"
 "uniform sampler2D source_sampler;\n"
 "uniform vec4 source_wh;\n"
@@ -152,14 +148,12 @@ glamor_create_composite_fs(struct shader_key *key)
 " source_wh, source_repeat_mode, 1);\n"
 "}\n";
 const char *mask_solid_fetch =
-GLAMOR_DEFAULT_PRECISION
 "uniform vec4 mask;\n"
 "vec4 get_mask()\n"
 "{\n"
 "  return mask;\n"
 "}\n";
 const char *mask_alpha_pixmap_fetch =
-GLAMOR_DEFAULT_PRECISION
 "varying vec2 mask_texture;\n"
 "uniform sampler2D mask_sampler;\n"
 "uniform vec4 mask_wh;\n"
@@ -172,7 +166,6 @@ glamor_create_composite_fs(struct shader_key *key)
 " mask_wh, mask_repeat_mode, 0);\n"
 "}\n";
 const char *mask_pixmap_fetch =
-GLAMOR_DEFAULT_PRECISION
 "varying vec2 mask_texture;\n"
 "uniform sampler2D mask_sampler;\n"
 "uniform vec4 mask_wh;\n"
@@ -185,31 +178,26 @@ glamor_create_composite_fs(struct shader_key *key)
 " mask_wh, mask_repeat_mode, 1);\n"
 "}\n";
 const char *in_source_only =
-GLAMOR_DEFAULT_PRECISION
 "void main()\n"
 "{\n"
 "  gl_FragColor = get_source();\n"
 "}\n";
 const char *in_normal =
-GLAMOR_DEFAULT_PRECISION
 "void main()\n"
 "{\n"
 "  gl_FragColor = get_source() * get_mask().a;\n"
 "}\n";
 const char *in_ca_source =
-GLAMOR_DEFAULT_PRECISION
 "void main()\n"
 "{\n"
 "  gl_FragColor = get_source() * get_mask();\n"
 "}\n";
 const char *in_ca_alpha =
-GLAMOR_DEFAULT_PRECISION
 "void main()\n"
 "{\n"
 "  gl_FragColor = get_source().a * get_mask();\n"
 "}\n";
 const char *in_ca_dual_blend =
-GLAMOR_DEFAULT_PRECISION
 "out vec4 color0;\n"
 "out vec4 color1;\n"
 "void main()\n"
@@ -280,7 +268,10 @@ glamor_create_composite_fs(struct shader_key *key)
 FatalError("Bad composite IN type");
 }
 
-XNFasprintf(, "%s%s%s%s%s%s%s", header, repeat_define, 
relocate_texture,
+XNFasprintf(,
+"%s"
+GLAMOR_DEFAULT_PRECISION
+"%s%s%s%s%s%s", header, repeat_define, relocate_texture,
 rel_sampler, source_fetch, mask_fetch, in);
 
 prog = glamor_compile_glsl_prog(GL_FRAGMENT_SHADER, source);
-- 
2.6.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 2/3] squash: glamor: Fix rendering to a8 textures in core profile.

2016-01-21 Thread Eric Anholt 
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/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -116,10 +116,17 @@ enum shader_in {
 SHADER_IN_COUNT,
 };
 
+enum shader_dest_swizzle {
+SHADER_DEST_SWIZZLE_DEFAULT,
+SHADER_DEST_SWIZZLE_ALPHA_TO_RED,
+SHADER_DEST_SWIZZLE_COUNT,
+};
+
 struct shader_key {
 enum shader_source source;
 enum shader_mask mask;
 enum shader_in in;
+enum shader_dest_swizzle dest_swizzle;
 };
 
 struct blendinfo {
@@ -285,7 +292,8 @@ typedef struct glamor_screen_private {
 int render_nr_quads;
 glamor_composite_shader composite_shader[SHADER_SOURCE_COUNT]
 [SHADER_MASK_COUNT]
-[SHADER_IN_COUNT];
+[SHADER_IN_COUNT]
+[SHADER_DEST_SWIZZLE_COUNT];
 
 /* shaders to restore a texture to another texture. */
 GLint finish_access_prog[2];
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 7a50fe9..c36b345 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -177,25 +177,38 @@ glamor_create_composite_fs(struct shader_key *key)
 "  return rel_sampler(mask_sampler, mask_texture,\n"
 " mask_wh, mask_repeat_mode, 1);\n"
 "}\n";
+
+const char *dest_swizzle_default =
+"vec4 dest_swizzle(vec4 color)\n"
+"{"
+"  return color;"
+"}";
+const char *dest_swizzle_alpha_to_red =
+"vec4 dest_swizzle(vec4 color)\n"
+"{"
+"  float undef;\n"
+"  return vec4(color.a, undef, undef, undef);"
+"}";
+
 const char *in_source_only =
 "void main()\n"
 "{\n"
-"  gl_FragColor = get_source();\n"
+"  gl_FragColor = dest_swizzle(get_source());\n"
 "}\n";
 const char *in_normal =
 "void main()\n"
 "{\n"
-"  gl_FragColor = get_source() * get_mask().a;\n"
+"  gl_FragColor = dest_swizzle(get_source() * get_mask().a);\n"
 "}\n";
 const char *in_ca_source =
 "void main()\n"
 "{\n"
-"  gl_FragColor = get_source() * get_mask();\n"
+"  gl_FragColor = dest_swizzle(get_source() * get_mask());\n"
 "}\n";
 const char *in_ca_alpha =
 "void main()\n"
 "{\n"
-"  gl_FragColor = get_source().a * get_mask();\n"
+"  gl_FragColor = dest_swizzle(get_source().a * get_mask());\n"
 "}\n";
 const char *in_ca_dual_blend =
 "out vec4 color0;\n"
@@ -214,6 +227,7 @@ glamor_create_composite_fs(struct shader_key *key)
 const char *in;
 const char *header;
 const char *header_norm = "";
+const char *dest_swizzle;
 GLuint prog;
 
 switch (key->source) {
@@ -246,6 +260,21 @@ glamor_create_composite_fs(struct shader_key *key)
 FatalError("Bad composite shader mask");
 }
 
+/* If we're storing to an a8 texture but our texture format is
+ * GL_RED because of a core context, then we need to make sure to
+ * put the alpha into the red channel.
+ */
+switch (key->dest_swizzle) {
+case SHADER_DEST_SWIZZLE_DEFAULT:
+dest_swizzle = dest_swizzle_default;
+break;
+case SHADER_DEST_SWIZZLE_ALPHA_TO_RED:
+dest_swizzle = dest_swizzle_alpha_to_red;
+break;
+default:
+FatalError("Bad composite shader dest swizzle");
+}
+
 header = header_norm;
 switch (key->in) {
 case SHADER_IN_SOURCE_ONLY:
@@ -271,8 +300,8 @@ glamor_create_composite_fs(struct shader_key *key)
 XNFasprintf(,
 "%s"
 GLAMOR_DEFAULT_PRECISION
-"%s%s%s%s%s%s", header, repeat_define, relocate_texture,
-rel_sampler, source_fetch, mask_fetch, in);
+"%s%s%s%s%s%s%s", header, repeat_define, relocate_texture,
+rel_sampler, source_fetch, mask_fetch, dest_swizzle, in);
 
 prog = glamor_compile_glsl_prog(GL_FRAGMENT_SHADER, source);
 free(source);
@@ -386,7 +415,7 @@ glamor_lookup_composite_shader(ScreenPtr screen, struct
 glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
 glamor_composite_shader *shader;
 
-shader = _priv->composite_shader[key->source][key->mask][key->in];
+shader = 
_priv->composite_shader[key->source][key->mask][key->in][key->dest_swizzle];
 if (shader->prog == 0)
 glamor_create_composite_shader(screen, key, shader);
 
@@ -841,6 +870,13 @@ glamor_composite_choose_shader(CARD8 op,
 key.in = SHADER_IN_SOURCE_ONLY;
 }
 
+if (dest_pixmap->drawable.bitsPerPixel <= 8 &&
+glamor_priv->one_channel_format == GL_RED) {
+key.dest_swizzle =

[PATCH xserver 0/3] Fixups for GL_RED patch.

2016-01-21 Thread Eric Anholt 
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_PRECISIONs in render accel.
  squash: glamor: Fix rendering to a8 textures in core profile.
  squash: glamor: Fix Render blending for alpha-to-red.

 glamor/glamor_priv.h   |  10 -
 glamor/glamor_render.c | 101 ++---
 2 files changed, 87 insertions(+), 24 deletions(-)

-- 
2.6.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 3/3] squash: glamor: Fix Render blending for alpha-to-red.

2016-01-21 Thread Eric Anholt 
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
@@ -215,8 +215,8 @@ glamor_create_composite_fs(struct shader_key *key)
 "out vec4 color1;\n"
 "void main()\n"
 "{\n"
-"  color0 = get_source() * get_mask();\n"
-"  color1 = get_source().a * get_mask();\n"
+"  color0 = dest_swizzle(get_source() * get_mask());\n"
+"  color1 = dest_swizzle(get_source().a * get_mask());\n"
 "}\n";
 const char *header_ca_dual_blend =
 "#version 130\n";
@@ -422,11 +422,29 @@ glamor_lookup_composite_shader(ScreenPtr screen, struct
 return shader;
 }
 
+static GLenum
+glamor_translate_blend_alpha_to_red(GLenum blend)
+{
+switch (blend) {
+case GL_SRC_ALPHA:
+return GL_SRC_COLOR;
+case GL_DST_ALPHA:
+return GL_DST_COLOR;
+case GL_ONE_MINUS_SRC_ALPHA:
+return GL_ONE_MINUS_SRC_COLOR;
+case GL_ONE_MINUS_DST_ALPHA:
+return GL_ONE_MINUS_DST_COLOR;
+default:
+return blend;
+}
+}
+
 static Bool
 glamor_set_composite_op(ScreenPtr screen,
 CARD8 op, struct blendinfo *op_info_result,
 PicturePtr dest, PicturePtr mask,
-enum ca_state ca_state)
+enum ca_state ca_state,
+struct shader_key *key)
 {
 GLenum source_blend, dest_blend;
 struct blendinfo *op_info;
@@ -473,6 +491,14 @@ glamor_set_composite_op(ScreenPtr screen,
 }
 }
 
+/* If we're outputting our alpha to the red channel, then any
+ * reads of alpha for blending need to come from the red channel.
+ */
+if (key->dest_swizzle == SHADER_DEST_SWIZZLE_ALPHA_TO_RED) {
+source_blend = glamor_translate_blend_alpha_to_red(source_blend);
+dest_blend = glamor_translate_blend_alpha_to_red(dest_blend);
+}
+
 op_info_result->source_blend = source_blend;
 op_info_result->dest_blend = dest_blend;
 op_info_result->source_alpha = op_info->source_alpha;
@@ -1006,8 +1032,10 @@ glamor_composite_choose_shader(CARD8 op,
 goto fail;
 }
 
-if (!glamor_set_composite_op(screen, op, op_info, dest, mask, ca_state))
+if (!glamor_set_composite_op(screen, op, op_info, dest, mask, ca_state,
+ )) {
 goto fail;
+}
 
 *shader = glamor_lookup_composite_shader(screen, );
 if ((*shader)->prog == 0) {
-- 
2.6.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

2016-01-21 Thread Keith Packard 
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->pDrawable->depth) {
> +return 0;
> +}
> +

How can this pass the following check then? The render format is
supposed to completely define the component layout within a pixel?

>  if (src->format == dst->format)
>  return 1;

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel