public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Belousov Maksim <mail@singulared.space>
To: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>,
	Thomas Zimmermann <tzimmermann@suse.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	Belousov Maksim <mail@singulared.space>
Subject: [PATCH] drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh
Date: Mon, 23 Feb 2026 21:12:47 +0400	[thread overview]
Message-ID: <20260223171247.503277-1-mail@singulared.space> (raw)

The ili9486 driver uses DRM_SIMPLE_MODE() which sets the pixel
clock to 1 kHz. Since htotal==hdisplay and vtotal==vdisplay,
the calculated vrefresh is:

    1000 / (480 * 320) = 0.006 Hz

This breaks Wayland compositors in two ways. Compositors that
use the mode's refresh rate to schedule their repaint loop
(such as Weston) compute a repaint delay of over a second,
triggering abnormal delay warnings and degrading rendering.
Compositors that are page-flip driven (such as wlroots-based
compositors) are unaffected at the compositor level, but still
report the near-zero rate to clients via wl_output.mode. This
causes toolkits such as GTK4 to not schedule redraws, so
applications render their initial frame but never visually
update in response to input.

Replace DRM_SIMPLE_MODE() with DRM_MODE_INIT(30, ...) which
properly calculates the pixel clock for a 30 Hz target refresh
rate. 30 Hz is a conservative default achievable on most SPI
setups. The actual frame rate remains bounded by SPI bus
throughput; the mode's vrefresh only affects how compositors
and clients schedule rendering.

Note: other tiny DRM drivers (hx8357d, ili9163, ili9225,
ili9341, mi0283qt, repaper, sharp-memory) have the same issue
and would benefit from the same change.

Tested on Raspberry Pi 4 with ILI9486-based MHS-3.5" SPI LCD
(480x320). With Weston, the compositor logs "computed repaint
delay is abnormal" warnings. With sway (wlroots), GTK4 clients
fail to visually update. Both issues are resolved by this
patch.

Signed-off-by: Belousov Maksim <mail@singulared.space>
---
 drivers/gpu/drm/tiny/ili9486.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 1e411a0f4..83eda43bd 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -165,7 +165,7 @@ static const struct drm_simple_display_pipe_funcs waveshare_pipe_funcs = {
 };
 
 static const struct drm_display_mode waveshare_mode = {
-	DRM_SIMPLE_MODE(480, 320, 73, 49),
+	DRM_MODE_INIT(30, 480, 320, 73, 49),
 };
 
 DEFINE_DRM_GEM_DMA_FOPS(ili9486_fops);
-- 
2.51.0


             reply	other threads:[~2026-02-23 17:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 17:12 Belousov Maksim [this message]
2026-02-24  0:01 ` Claude review: drm/tiny: ili9486: use DRM_MODE_INIT for proper vrefresh Claude Code Review Bot
2026-02-24  0:01 ` Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260223171247.503277-1-mail@singulared.space \
    --to=mail@singulared.space \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kamlesh.gurudasani@gmail.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox