[Wayland-bugs] [Bug 50049] New: Weston handles XRGB badly, as shown by simple-shm

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50049

             Bug #: 50049
           Summary: Weston handles XRGB badly, as shown by simple-shm
    Classification: Unclassified
           Product: Wayland
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: weston
        AssignedTo: wayland-bugs at lists.freedesktop.org
        ReportedBy: darxus at chaosreigns.com


"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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.