On Wed, Jun 08, 2022 at 07:44:03PM +0300, Roman Stratiienko wrote: > ср, 8 июн. 2022 г. в 11:17, Maxime Ripard <maxime@xxxxxxxxxx>: > > > > On Mon, Jun 06, 2022 at 01:16:06PM +0300, Roman Stratiienko wrote: > > > вс, 5 июн. 2022 г. в 23:23, Jernej Škrabec <jernej.skrabec@xxxxxxxxx>: > > > > > > > > Dne nedelja, 05. junij 2022 ob 11:40:18 CEST je Roman Stratiienko napisal(a): > > > > > Otherwise alpha value is discarded, resulting incorrect pixel > > > > > apperance on the display. > > > > > > > > > > This also fixes missing transparency for the most bottom layer. > > > > > > > > Can you explain that a bit more? > > > > > > Well... I would recommend reading Bartosz Ciechanowski's blog > > > https://ciechanow.ski/alpha-compositing/ or the Porter-Duff's 1984 > > > whitepaper itself. > > > > > > HINT: That magic numbers from sun8i_mixer.h ( 0x03010301 ) corresponds > > > to SOURCE OVER mode. > > > > > > As you can see from the blending equation it outputs both pixel value > > > and alpha value (non-premultiplied data mode). > > > > > > Also single-layer non-premultiplied buffers may have for example > > > (R255,G255,B255,A2) pixel value, which should be sent as {R2, G2, B2} > > > through the physical display interface. > > > > > > When OUTCTL.PREMULTI disabled pixel, the RGB values passes as is, and > > > even 100% transparent data {R255, G255, B255, A0} will appear as 100% > > > opaque white. > > > > Without going into the full explanation about what alpha is, your commit > > log must describe what the bug is exactly, and most importantly how do > > you trigger it. > > I do not understand what you want me to add. Context. Again, what the bug is exactly and how it fails, so things like what setup triggers it, what exactly is wrong with it (is the layer not displayed at all, corrupted, something else?), etc. > I checked alpha appearance manually by preparing framebuffers with > data and presenting it on the display in various combinations. > > I attached the videos and tests as a proof. If you don't believe me > you can always check. It's not about believing you. Let's say that in a couple of years it turns out that this patch introduced a regression, or something just isn't clear about it. We go have a look at the commit message, and it just points to a video that isn't hosted anywhere anymore, because you closed your hosting account, removed it, whatever. Then what? That's why we ask to have the whole context in your message, because otherwise you introduce a dependency on something Linux as a whole has no control over. And if it's not there anymore, your current commit message is useless. > If you find something missing in the commit message or don't like to > see external links feel free to amend it. From my point of view the > patch is complete. I'm sorry you feel that way, but I don't really get your attitude there. What did you expect from reviews in general if you're just going to ignore anything we might say? Maxime
