"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
<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
Should be fixed with http://cgit.freedesktop.org/wayland/weston/commit/?id=d6ad122d9ac8856aa6d35cc690550c857caa5212
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.