[v3 4/6] drm/vs: Add KMS crtc&plane

Icenowy Zheng uwu at icenowy.me
Tue Dec 26 19:57:17 PST 2023


在 2023-12-07星期四的 19:31 +0800,Keith Zhao写道:
> 
> 
> On 2023/12/7 16:41, Icenowy Zheng wrote:
> > 在 2023-12-04星期一的 20:33 +0800,Keith Zhao写道:
> > *snip*
> > 
> > > +static void update_cursor_plane(struct vs_dc *dc, struct
> > > vs_plane
> > > *plane,
> > > +                               struct drm_plane *drm_plane,
> > > +                               struct drm_atomic_state
> > > *drm_state)
> > > +{
> > > +       struct drm_plane_state *state =
> > > drm_atomic_get_new_plane_state(drm_state,
> > > +                                                                
> > >     
> > >   drm_plane);
> > > +       struct vs_plane_state *plane_state =
> > > to_vs_plane_state(state);
> > > +       struct drm_framebuffer *drm_fb = state->fb;
> > > +       struct dc_hw_cursor cursor;
> > > +
> > > +       cursor.address = plane_state->dma_addr[0];
> > > +       cursor.x = state->crtc_x;
> > > +       cursor.y = state->crtc_y;
> > 
> > From my experiments on poking with registers on T-Head TH1520 (also
> > uses DC8200 display controller and a similar driver), the DC8200
> > hardware have a different definition of cursor position X and Y
> > with
> > the CRTC plane state.
> > 
> > For CRTC plane state, hot_x and hot_y are only provided as
> > reference,
> > and the cursor should be displayed with its (0,0) drawn to (crtc_x,
> > crtc_y) ([XY]_crtc are values specified in CRTC state, the right
> > part
> > of the assignments here), when the cursor is moved to (0,0) but the
> > hot
> > point is not (0,0), it could be negative.
> > 
> > However, for DC8200 registers definition, cursor XY position could
> > not
> > be negative -- the cursor will disappear then; because in its
> > definition, the cursor XY position should be where the cursor is
> > pointing to, instead of its (0,0). DC8200 will draw (0,0) of the
> > cursor
> > to (x - hot_x, y - hot_y). So to met the expectation of the KMS
> > plane
> > settings, the DC8200 position should be set to (crtc_x + hot_x,
> > crtc_y
> > + hot_y) instead. Thus these two lines of code should be:
> > 
> > ```
> >         cursor.x = state->crtc_x + drm_fb->hot_x;
> >         cursor.y = state->crtc_y + drm_fb->hot_y;
> > ```

Well I realized that this change is not correct too: when moving the
mouse cursor with the screen rotated, the mouse cursor will disappear
at some screen border.

My current idea is:

As the CRTC hot point is just a reference, we can just ignore it, and
use the HW hot point to implement negative cursor position.

The patch is like the follow:

-    cursor.x = state->crtc_x;
-    cursor.y = state->crtc_y;
-    cursor.hot_x = drm_fb->hot_x;
-    cursor.hot_y = drm_fb->hot_y;
+    if (state->crtc_x > 0) {
+        cursor.x = state->crtc_x;
+        cursor.hot_x = 0;
+    } else {
+        cursor.hot_x = -state->crtc_x;
+        cursor.x = 0;
+    }
+    if (state->crtc_y > 0) {
+        cursor.y = state->crtc_y;
+        cursor.hot_y = 0;
+    } else {
+        cursor.hot_y = -state->crtc_y;
+        cursor.y = 0;
+    }

drm_fb could just be removed in this function then because it's no
longer needed (it's used to get the cursor's hot point, which we
ignored now).

> > 
> > 
> > > +       cursor.hot_x = drm_fb->hot_x;
> > > +       cursor.hot_y = drm_fb->hot_y;
> > > +       cursor.display_id = to_vs_display_id(dc, state->crtc);
> > > +       update_cursor_size(state, &cursor);
> > > +       cursor.enable = true;
> > > +
> > > +       dc_hw_update_cursor(&dc->hw, cursor.display_id, &cursor);
> > > +}
> > *snip
> hello Icenowy:
> you are deep understanding on dc8200.
> by the way of practice
> I tested this change on the debian desktop, is there a way to compare
> the cursor behavior change?
> Thanks
> 
> 
> 




More information about the linux-riscv mailing list