Hello build bot (Jenkins), Paul Menzel,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/45235
to look at the new patch set (#2).
Change subject: libpayload: cbgfx: Fix 'equals' counter for Lanczos resampling ......................................................................
libpayload: cbgfx: Fix 'equals' counter for Lanczos resampling
The current initialization of the 'equals' counter is incorrect, so that when 'equals >= SSZ * SSZ', the pixels in the sample array might not be all the same, leading to an wrong pixel value being set in the framebuffer.
The 'equals' counter stores the number of latest pixels that were exactly equal. Within the for loop of 'ox', the sample array is updated in a column-based order, and the 'equals' counter is updated accordingly. However, the 'equals' counter is initialized in a row-based order, which causes it to be set too large than it should be. Consider the example where sample[sx][sy] are initially:
[X X X A A A] // sy = 0 [X X X B B B] [X X X B B B] [X X X B B B] [X X X B B B] [X X X B B B] // sy = SSZ
Then, the correct implementation will initialize 'equals' to be 15, with last_equal being B. Suppose all of the remaining pixels are B. Then, at the end of the 'while (fpfloor(ixfp) > ix)' loop when ix = 4, or equivalently after 4 more columns of sample are updated, 'equals' will be 15 + 6 * 4 = 39, which is greater than SSZ * SSZ = 36, but we can see there are still 2 A's in the sample:
[B B B B A A] [B B B B B B] [B B B B B B] [B B B B B B] [B B B B B B] [B B B B B B]
Therefore, we must also initialize the 'equals' counter in a column-based order.
BUG=b:167739127 TEST=emerge-puff libpayload TEST=Character 'k' is rendered correctly on puff BRANCH=zork
Change-Id: Ibc91ad1af85adcf093eff40797cd54f32f57111d Signed-off-by: Yu-Ping Wu yupingso@chromium.org --- M payloads/libpayload/drivers/video/graphics.c 1 file changed, 23 insertions(+), 21 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/35/45235/2