Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Cursor bounds are calculated using `vc_font.height` instead of `vc_cell_height`, breaking hardware cursors when the text cell height is overridden. --
commit 25f4b9b96dc26e69ace4c42e72c99970c3c5fcf1 Author: Thomas Zimmermann <[email protected]> vgacon: Use vt_font_cursor_{start,end}() This commit replaces vgacon's custom cursor size calculations with the shared helpers vc_font_cursor_start() and vc_font_cursor_end(). It subtracts one from the end value to account for VGA hardware expectations. > diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c > index 536e7fe4d1426..b16ddb1b09a70 100644 > --- a/drivers/video/console/vgacon.c > +++ b/drivers/video/console/vgacon.c [ ... ] > @@ -524,33 +525,8 @@ static void vgacon_cursor(struct vc_data *c, bool enable) > return; > } > > - switch (CUR_SIZE(c->vc_cursor_type)) { [ ... ] > - default: > - vgacon_set_cursor_size(1, c_height); > - break; > - } > + vgacon_set_cursor_size(vc_font_cursor_start(&c->vc_font, c_type), > + vc_font_cursor_end(&c->vc_font, c_type) - 1); [Severity: High] Does this code break the hardware cursor when the character cell height is dynamically overridden? If a user space utility like SVGATextMode calls the VT_RESIZEX ioctl with a smaller v_clin, c->vc_cell_height is updated while c->vc_font.height remains unchanged. By computing the cursor bounds using the static font height via the shared helpers instead of the active character cell height, it seems the programmed start scanline could exceed the maximum scanline of the character cell (VGA_CRTC_MAX_SCAN). Since the hardware scanline counter resets before reaching the programmed cursor start line, would this cause the hardware cursor to become completely invisible? > } > > static void vgacon_doresize(struct vc_data *c, -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
