On Mon, 12 Nov 2018 10:20:35 +0000 Dave Stevenson dave.stevenson@raspberrypi.org wrote:
Hi Boris & Eric.
On Thu, 8 Nov 2018 at 15:12, Eric Anholt eric@anholt.net wrote:
Boris Brezillon boris.brezillon@bootlin.com writes:
On Thu, 08 Nov 2018 06:52:44 -0800 Eric Anholt eric@anholt.net wrote:
Boris Brezillon boris.brezillon@bootlin.com writes:
For the YUV conversion to work properly, ->x_scaling[0,1] should never be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE into VC4_SCALING_PPF when that happens.
Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Boris Brezillon boris.brezillon@bootlin.com
I couldn't find a spec justification for this -- did you have a testcase that fails?
Yep. Just set the downscaling ratio to 0.5 with an NV12 format and you'll hit the issue (I used modetest to do that):
# modetest -M vc4 -s 29:1920x1080-60 -P 96@95:1920x1080*0.5@NV12
I found that the firmware has a similar behavior to your patch ("if Y is !unity (x or scaling) and UV is unity, set UV to HPPF/VPPF scaling"). They also select the unity flag after the YUV scaling fixup.
Regardless, if this works, it's got my reviewed-by.
Hopefully we can do some IGT with writeback or chamelium testing all of the X/Y scaling options with a focus on hitting these 1:1 ratios. The state space is big and the docs are just ambiguous enough.
Great timing as I've hit exactly this when playing back a 1080P video on a 1080P screen. The colours were very muted in this situation, whilst playing any other resolution or any RGB format was fine. Took me a while to realise it wasn't the conversion matrices being set incorrectly :-/ Applying this patch sorts the problem. This was on the downstream 4.19 kernel, and the v2 of this set backported fairly easily. Can I request that for stable? Otherwise we can cherry-pick it for downstream.
Sure.