From: sashiko-bot@kernel.org
To: "Thomas Zimmermann" <tzimmermann@suse.de>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH 2/2] vt: Distinguish between blanking and VESA blank mode in con_blank
Date: Mon, 12 Oct 2026 09:47:53 +0000 [thread overview]
Message-ID: <sashiko-outbox-167905@kernel.org> (raw)
In-Reply-To: <20261012094114.38549-3-tzimmermann@suse.de>
> The con_blank callback in struct consw encodes blanking and display
> blank mode in a single parameter named blank. Its semantics equal
> the FB_BLANK constants from the fbdev subsystems. Yet it is of type
> enum vesa_blank_mode, which describes VESA DPMS levels of the attached
> monitor. Although related, this is something else.
>
> For this reason, calls to con_blank fill the blank parameter with
> values that appear non-sensical at first. For example, to blank the
> console, but keep the monitor on, vt passes VESA_VSYNC_SUSPEND (eq '1').
> This is because consoles interpret '1' as pixels-off-but-monitor-on.
> The constant VESA_VSYNC_SUSPEND actually means monitor-vsync-off. And
> the argument used for monitor-vsync-off is VESA_VSYNC_SUSPEND+1.
>
> To fix this by splitting blank into two parameters, blank and blank_mode.
> The new blank is a boolean to control the display blanking. If cleared,
> the console creates display output, if set the console does not. The
> new parameter blank_mode specifies the VESA blank mode for the monitor
> and equals VESA DPMS levels. If blank is set, blank_mode gives a hint
> to the console, on how to set up the signal to the monitor.
>
> The actual interpretation is up to the console. Newportcon and sticon
> only handle blank or not-blank. Fbcon and vgacon implement blank plus
> the VESA DPMS handling. The implementation of both consoles is again
> somewhat confusing because types and values do not match. Clean up
> both with the new blank/blank_mode logic.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012094114.38549-1-tzimmermann@suse.de?part=2
next prev parent reply other threads:[~2026-10-12 9:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 9:27 [PATCH 0/2] vt: Simplify console-blanking interface Thomas Zimmermann
2026-10-12 9:27 ` [PATCH 1/2] vt: Use boolean as parameter to do_blank_screen() and do_unblank_screen() Thomas Zimmermann
2026-10-12 9:45 ` sashiko-bot
2026-10-12 11:30 ` Greg KH
2026-10-12 12:28 ` Thomas Zimmermann
2026-10-12 12:41 ` Thomas Zimmermann
2026-10-12 16:13 ` Greg KH
2026-10-12 9:27 ` [PATCH 2/2] vt: Distinguish between blanking and VESA blank mode in con_blank Thomas Zimmermann
2026-10-12 9:47 ` sashiko-bot [this message]
2026-10-12 11:29 ` Greg KH
2026-10-12 12:08 ` Thomas Zimmermann
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=sashiko-outbox-167905@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.