New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 826967 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

rk: scanning out an RGBA buffer as primary plane results in a black screen

Project Member Reported by dcasta...@chromium.org, Mar 28 2018

Issue description

On kevin, scanning out a primary plane that is an RGBA fb results in a black screen.

To reproduce:

modetest -M rockchip -s 48@38:2400x1600@AR24

while with: modetest -M rockchip -s 48@38:2400x1600@XR24 the modetest pattern is visible.
 
Separately from this bug, could you add a drm-test for this? We usually rely on those to qualify new display drivers, and if that's becoming a required functionality, it really should be in those tests.
Cc: jeffy.c...@rock-chips.com
Hi Jeffy!
Any chance you could take a look at this issue?
Project Member

Comment 4 by bugdroid1@chromium.org, Mar 30 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/drm-tests/+/0842005281c034af20eccc494656e89ba8d918e3

commit 0842005281c034af20eccc494656e89ba8d918e3
Author: Daniele Castagna <dcastagna@chromium.org>
Date: Fri Mar 30 02:51:41 2018

drm-tests: RGBA primary plane test

Adds a test that uses an RGBA fb for the primary plane.
On RK the screen is currnetly all black even if the alpha channel
is all 1.

TEST=atomictest -t rgba_primary
BUG=chromium:826967
Change-Id: I89a69d40f79b17913d77f83193a86ad24fa9225a
Reviewed-on: https://chromium-review.googlesource.com/985461
Commit-Ready: Daniele Castagna <dcastagna@chromium.org>
Tested-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>

[modify] https://crrev.com/0842005281c034af20eccc494656e89ba8d918e3/atomictest.c

Hi guys,

right, this seems to be a hardware limit, and that patch should be OK.

we have something like that in our BSP kernel:
commit 4108b1871081009225b5b0c7a80f43dcf5ebdd7d
Author: Mark Yao <mark.yao@rock-chips.com>
Date:   Tue Jun 21 14:31:09 2016 +0800

    drm/rockchip: disabled the plane alpha if it's bottom layer

    HardWare limited, the bottom layer not support per-pixel alpha,

@@ -787,7 +788,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
        rb_swap = has_rb_swapped(fb->pixel_format);
        VOP_WIN_SET(vop, win, rb_swap, rb_swap);

-       if (is_alpha_support(fb->pixel_format)) {
+       if (is_alpha_support(fb->pixel_format) &&
+           (s->dsp_layer_sel & 0x3) != win->win_id) { <--- the BSP kernel supported adjust planes' z-order. and the last 2 bits of this dsp_layer_sel is the win_id of bottom layer
                VOP_WIN_SET(vop, win, dst_alpha_ctl,
                            DST_FACTOR_M0(ALPHA_SRC_INVERSE));
                val = SRC_ALPHA_EN(1) | SRC_COLOR_M0(ALPHA_SRC_PRE_MUL) |

Sign in to add a comment