Re: [PATCH libICE] Enable visibility annotations

[Emil Velikov]

On 13 May 2016 at 07:33, Yury Gribov  wrote:
> On 05/10/2016 03:00 PM, Yury Gribov wrote:
>>
>> On 05/06/2016 07:25 PM, Alan Coopersmith wrote:
>>>
>>> On 05/ 6/16 04:18 AM, Yury Gribov wrote:

 Unfortunately I don't see any good approach. We could move
 definitions of
 _X_EXPORT and friends to configure.ac but this would need to be done
 for all X11 packages (not just libICE) which just does not scale.
>>>
>>>
>>> And then you'd require any package that #includes an X11 header to use
>>> autoconf and add those to configure.ac and that really doesn't scale.
>>
>>
>> There is a way around this: you can strip internal defines from public
>> headers and replace it with e.g. extern. This is how visibility was
>> enabled for acl and libattr some time ago
>> (http://lists.nongnu.org/archive/html/acl-devel/2016-02/msg00020.html).
>>
>>> Xfuncproto.h exists because X exposes headers to things built with
>>> hundreds of different build systems.
>
>
> Cc-ed my home address (today's my last day in Samsung).
>
I'm sorry but I still don't see what/why you're suggesting. Can you
please elaborate ?

Related data point - both Sun/Oracle compiler and MSVC emit
warnings/errors, when the function definition is annotated with
_X_EXPORT, but the declaration isn't.


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

Re: [PATCH xserver] glamor: Disable logic ops when doing compositing

[Keith Packard]

Eric Anholt  writes:

> Oh, yeah.  Even better.

And a v3 which catches the other place where GL_BLEND is getting
set. Sent that under a separate cover along with a more complicated
patch for the red/alpha swizzling stuff.

-- 
-keith


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

Re: [PATCH] glamor: swizzle RED to 0 for alpha textures.

[Keith Packard]

Keith Packard  writes:

> And, loading a page from gfycat is broken by this change.
>
> firefox https://gfycat.com/HoarseCheapAmericankestrel
>
> So, we can either have feedly with black text or gfycat with 
> cat videos, but not both at the same time. I'm not sure I can live in a
> world without both of these.

I just posted a fix for this which leaves bits in the Red channel when
the destination is also in GL_RED format.

-- 
-keith


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

[PATCH xserver 1/3] glamor: Disable logic ops when doing compositing [v3]

[Keith Packard]

If the logic op gets left enabled, it overrides the blending
operation, causing incorrect contents on the display.

v2: Disable only on non-ES2, but disable even for PictOpSrc

v3: Found another place this is needed in
glamor_composite_set_shader_blend

Signed-off-by: Keith Packard 
---
 glamor/glamor_program.c | 4 
 glamor/glamor_render.c  | 6 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
index 0a94de6..322d198 100644
--- a/glamor/glamor_program.c
+++ b/glamor/glamor_program.c
@@ -445,6 +445,7 @@ static struct blendinfo composite_op_info[] = {
 static void
 glamor_set_blend(CARD8 op, glamor_program_alpha alpha, PicturePtr dst)
 {
+glamor_screen_private *glamor_priv = 
glamor_get_screen_private(dst->pDrawable->pScreen);
 GLenum src_blend, dst_blend;
 struct blendinfo *op_info;
 
@@ -459,6 +460,9 @@ glamor_set_blend(CARD8 op, glamor_program_alpha alpha, 
PicturePtr dst)
 break;
 }
 
+if (glamor_priv->gl_flavor != GLAMOR_GL_ES2)
+glDisable(GL_COLOR_LOGIC_OP);
+
 if (op == PictOpSrc)
 return;
 
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 65f7059..ea9abc7 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1075,10 +1075,14 @@ glamor_composite_set_shader_blend(glamor_screen_private 
*glamor_priv,
 glamor_set_composite_texture(glamor_priv, 1,
  shader->mask,
  shader->mask_pixmap, shader->mask_wh,
- shader->mask_repeat_mode);
+ shader->mask_repeat_mode,
+ dest_priv);
 }
 }
 
+if (glamor_priv->gl_flavor != GLAMOR_GL_ES2)
+glDisable(GL_COLOR_LOGIC_OP);
+
 if (op_info->source_blend == GL_ONE && op_info->dest_blend == GL_ZERO) {
 glDisable(GL_BLEND);
 }
-- 
2.8.0.rc3

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

[PATCH xserver 3/3] glamor: Preserve GL_RED bits in R channel when destination is GL_RED

[Keith Packard]

A1 and A8 pixmaps are usually stored in the Red channel to conform
with more recent GL versions. When using these pixmaps as mask values,
that works great. When using these pixmaps as source values, then the
value we want depends on what the destination looks like.

For RGBA or RGB destinations, then we want to use the Red channel
for A values and leave RGB all set to zero.

For A destinations, then we want to leave the R values in the Red
channel so that they end up in the Red channel of the output.

This patch adds a helper function, glamor_bind_texture, which performs
the glBindTexture call along with setting the swizzle parameter
correctly for the Red channel. The swizzle parameter for the Alpha
channel doesn't depend on the destination as it's safe to leave it
always swizzled from the Red channel.

This fixes incorrect rendering in firefox for this page:

https://gfycat.com/HoarseCheapAmericankestrel

while not breaking rendering for this page:

https://feedly.com

Signed-off-by: Keith Packard 
---
 glamor/glamor.c  | 36 
 glamor/glamor_composite_glyphs.c |  3 +--
 glamor/glamor_copy.c |  8 
 glamor/glamor_dash.c |  3 +--
 glamor/glamor_fbo.c  |  4 +---
 glamor/glamor_priv.h | 28 
 glamor/glamor_program.c  |  4 +++-
 glamor/glamor_render.c   | 18 ++
 glamor/glamor_spans.c|  3 +--
 glamor/glamor_transfer.c |  3 +--
 glamor/glamor_transform.c| 12 
 glamor/glamor_transform.h|  4 +++-
 12 files changed, 101 insertions(+), 25 deletions(-)

diff --git a/glamor/glamor.c b/glamor/glamor.c
index 477bc0e..62b5c3a 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -140,6 +140,42 @@ glamor_get_pixmap_texture(PixmapPtr pixmap)
 return pixmap_priv->fbo->tex;
 }
 
+void
+glamor_bind_texture(glamor_screen_private *glamor_priv, GLenum texture,
+glamor_pixmap_fbo *fbo, Bool destination_red)
+{
+glActiveTexture(texture);
+glBindTexture(GL_TEXTURE_2D, fbo->tex);
+
+/* If we're pulling data from a GL_RED texture, then whether we
+ * want to make it an A,0,0,0 result or a 0,0,0,R result depends
+ * on whether the destination is also a GL_RED texture.
+ *
+ * For GL_RED destinations, we need to leave the bits in the R
+ * channel. For all other destinations, we need to clear out the R
+ * channel so that it returns zero for R, G and B.
+ *
+ * Note that we're leaving the SWIZZLE_A value alone; for GL_RED
+ * destinations, that means we'll actually be returning R,0,0,R,
+ * but it doesn't matter as the bits in the alpha channel aren't
+ * going anywhere.
+ */
+
+/* Is the operand a GL_RED fbo?
+ */
+
+if (glamor_fbo_red_is_alpha(glamor_priv, fbo)) {
+
+/* If destination is also GL_RED, then preserve the bits in
+ * the R channel */
+
+if (destination_red)
+glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_R, GL_RED);
+else
+glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_R, GL_ZERO);
+}
+}
+
 PixmapPtr
 glamor_create_pixmap(ScreenPtr screen, int w, int h, int depth,
  unsigned int usage)
diff --git a/glamor/glamor_composite_glyphs.c b/glamor/glamor_composite_glyphs.c
index f51ff6d..50fd026 100644
--- a/glamor/glamor_composite_glyphs.c
+++ b/glamor/glamor_composite_glyphs.c
@@ -246,8 +246,7 @@ glamor_glyphs_flush(CARD8 op, PicturePtr src, PicturePtr 
dst,
 glamor_put_vbo_space(drawable->pScreen);
 
 glEnable(GL_SCISSOR_TEST);
-glActiveTexture(GL_TEXTURE1);
-glBindTexture(GL_TEXTURE_2D, atlas_fbo->tex);
+glamor_bind_texture(glamor_priv, GL_TEXTURE1, atlas_fbo, FALSE);
 
 for (;;) {
 if (!glamor_use_program_render(prog, op, src, dst))
diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c
index 5fed89f..3501a0d 100644
--- a/glamor/glamor_copy.c
+++ b/glamor/glamor_copy.c
@@ -38,8 +38,8 @@ use_copyarea(PixmapPtr dst, GCPtr gc, glamor_program *prog, 
void *arg)
 struct copy_args *args = arg;
 glamor_pixmap_fbo *src = args->src;
 
-glActiveTexture(GL_TEXTURE0);
-glBindTexture(GL_TEXTURE_2D, src->tex);
+glamor_bind_texture(glamor_get_screen_private(dst->drawable.pScreen),
+GL_TEXTURE0, src, TRUE);
 
 glUniform2f(prog->fill_offset_uniform, args->dx, args->dy);
 glUniform2f(prog->fill_size_inv_uniform, 1.0f/src->width, 
1.0f/src->height);
@@ -67,8 +67,8 @@ use_copyplane(PixmapPtr dst, GCPtr gc, glamor_program *prog, 
void *arg)
 struct copy_args *args = arg;
 glamor_pixmap_fbo *src = args->src;
 
-glActiveTexture(GL_TEXTURE0);
-glBindTexture(GL_TEXTURE_2D, src->tex);
+glamor_bind_texture(glamor_get_screen_private(dst->drawable.pScreen),
+GL_TEXTURE0, src, TRUE);
 
 

[PATCH xserver 2/3] glamor: glamor_make_current sooner in glamor_composite_with_shader

[Keith Packard]

glamor_make_current is supposed to be called before any GL APIs.

Signed-off-by: Keith Packard 
---
 glamor/glamor_render.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index ea9abc7..1e03ca0 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1143,12 +1143,12 @@ glamor_composite_with_shader(CARD8 op,
 }
 }
 
+glamor_make_current(glamor_priv);
+
 glamor_set_destination_pixmap_priv_nc(glamor_priv, dest_pixmap, 
dest_pixmap_priv);
 glamor_composite_set_shader_blend(glamor_priv, dest_pixmap_priv, , 
shader, _info);
 glamor_set_alu(screen, GXcopy);
 
-glamor_make_current(glamor_priv);
-
 glamor_priv->has_source_coords = key.source != SHADER_SOURCE_SOLID;
 glamor_priv->has_mask_coords = (key.mask != SHADER_MASK_NONE &&
 key.mask != SHADER_MASK_SOLID);
-- 
2.8.0.rc3

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