Bug 50049

Summary: Weston handles XRGB badly, as shown by simple-shm
Product: Wayland Reporter: Darxus <darxus>
Component: westonAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: darxus
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Darxus 2012-05-17 06:29:33 UTC
"If the compositor does not properly ignore the X-channel, and uses it as alpha, you will see a cross over the image."
- http://ppaalanen.blogspot.com/2012/04/improved-appearance-for-simplest.html
simple-shm does show this cross / X.

<pq> soreau, the "X" in simple-shm is indeed a bug. _Weston's_
     bug. If an app gives you an XRGB buffer, you are supposed 
     to ignore the X channel.
<soreau> pq: How difficult would it be to fix the bug in weston,
         and where does it lie exactly?
<pq> soreau, well, GL ES 2 has no such format as XRGB texture,
     and we cannot upload an RGB texture, since we have the X
     channel in the data. So it goes up as ARGB. Or was it ABGR,
     but anyway.
<pq> and our shaders don't know better and go and use the alpha 
<soreau> pq: So where's the bug then, egl? the weston surface
         shaders?
<soreau> gles2*
<soreau> the format type handling?
<pq> shaders, I'd say
<pq> GL ES 2 just doesn't support any texture upload that
     requires conversion (without extensions)
<pq> I'd fix that by adding a uniform flag to fragment shaders
     saying whether to sample A-channel or assume it's 1.0.
<pq> though krh said we've been before, but I couldn't find the
     code in git when I looked
<pq> *we have been there before
<soreau> and that's controlled by what? how do you know if the  
         surface wants to be xrgb or not?
<pq> wl_shm tells you
<soreau> well then it should be relatively trivial to fix
<pq> when you create a wl_buffer using the wl_shm object, you
     pass in a format
<pq> so we need to get the flag on buffer attach
<pq> and program it into the uniform when we paint the surface
<pq> yeah, it just wasn't a very useful fix for me, when I did 
     simple-shm rewrite
<soreau> pq: this would require wayland protocol adjustment?
<pq> but for you with xwayland it probably is very useful
<pq> no 
<pq> all the protocol is there, weston is just sloppy :-)
<soreau> bah 
<soreau> it's only as sloppy as you let it be
<pq> I'm still wondering why krh said we had that at some point 
     (and I do recall something like that!), but why I couldn't
     find it in git history
<soreau> pq: Had what?
<pq> a separate path for XRGB buffer or rendering
<soreau> I don't see why there wouldn't be
<soreau> it seems to be supported throughout for the most part
<pq> sorry, what?
<soreau> or, it's just lacking implementation like so many things
<pq> yeah
<soreau> fortunately, weston is pretty easy to work on
Comment 1 Darxus 2012-05-17 07:02:51 UTC
<krh> pq: we did have a sample feature to just set alpha to one   
      for xrgb textures
<krh> but we changed the drm buffers to set up the right  
      combination of content and format so we didn't need that
<pq> krh, yeah but I couldn't find it back then. Maybe I didn't   
     look for the right changes.
<krh> and then we discover that GLES2 doesn't let you specify  
      GL_RGB+GL_ARGB for teximage2d
<krh> eventhough that wouldn't require conversion
<krh> I suppose the thinking is that you should just do the   
      right thing in the shade
<krh> shader
<pq> krh, yes in the shader. I understood that was implemented
     once upon a time? And I have a vague recollection of seeing   
     or even touching it, but couldn't find it anymore. Maybe  
     it's just my memories of Compiz dev haunting me.
<krh> pq: no, we had that

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.