linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: linux-fbdev@vger.kernel.org, Simona Vetter <simona@ffwll.ch>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/6] fbcon: Make cursor_blink=0 work when configured before fb devices appear
Date: Mon, 23 Sep 2024 23:50:39 +0200	[thread overview]
Message-ID: <93c63567-d183-402e-82e0-f64b97b74ba8@gmx.de> (raw)
In-Reply-To: <ZvHd8VV6MO4kfLcL@intel.com>

On 9/23/24 23:30, Ville Syrjälä wrote:
> On Mon, Sep 23, 2024 at 11:04:55PM +0200, Helge Deller wrote:
>> On 9/23/24 17:57, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> Currently setting cursor_blink attribute to 0 before any fb
>>> devices are around does absolutely nothing. When fb devices appear
>>> and fbcon becomes active the cursor starts blinking. Fix the problem
>>> by recoding the desired state of the attribute even if no fb devices
>>> are present at the time.
>>>
>>> Also adjust the show() method such that it shows the current
>>> state of the attribute even when no fb devices are in use.
>>>
>>> Note that store_cursor_blink() is still a bit dodgy:
>>> - seems to be missing some of the other checks that we do
>>>     elsewhere when deciding whether the cursor should be
>>>     blinking or not
>>> - when set to 0 when the cursor is currently invisible due
>>>     to blinking, the cursor will remains invisible. We should
>>>     either explicitly make it visible here, or wait until the
>>>     full blink cycle has finished.
>>>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>>    drivers/video/fbdev/core/fbcon.c | 34 +++++++-------------------------
>>>    1 file changed, 7 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>>> index 2e093535884b..8936fa79b9e0 100644
>>> --- a/drivers/video/fbdev/core/fbcon.c
>>> +++ b/drivers/video/fbdev/core/fbcon.c
>>> @@ -3217,26 +3217,7 @@ static ssize_t show_rotate(struct device *device,
>>>    static ssize_t show_cursor_blink(struct device *device,
>>>    				 struct device_attribute *attr, char *buf)
>>>    {
>>> -	struct fb_info *info;
>>> -	struct fbcon_ops *ops;
>>> -	int idx, blink = -1;
>>> -
>>> -	console_lock();
>>> -	idx = con2fb_map[fg_console];
>>> -
>>> -	if (idx == -1 || fbcon_registered_fb[idx] == NULL)
>>> -		goto err;
>>> -
>>> -	info = fbcon_registered_fb[idx];
>>> -	ops = info->fbcon_par;
>>> -
>>> -	if (!ops)
>>> -		goto err;
>>> -
>>> -	blink = delayed_work_pending(&ops->cursor_work);
>>> -err:
>>> -	console_unlock();
>>> -	return sysfs_emit(buf, "%d\n", blink);
>>> +	return sysfs_emit(buf, "%d\n", !fbcon_cursor_noblink);
>>
>> I might be wrong and mix up things, but I think the previous code allowed
>> to show/set the blink value *per* registered framebuffer console,
>> while now you generally enable/disable blinking for all
>> framebuffer drivers at once?
>> Just thinking of a multiseat setup with different fb drivers
>> attached to different monitors with own mouse/keyboards...?!?
>
> There is just a single fbcon device in sysfs, so not really.
> It's true that it only ever operated on the fg_console, so
> on a first glane it may look like it might be some kind of
> per-fb thing. But the state was only recorded in the
> fbcon_cursor_noblink singleton, so when another vt becomes
> active it'll look at that an not start the blinker.

True.

> So I think the per-fb aspect was just an illusion.

No, I think in the past it worked, but I assume the per-fb
think got lost in all recent fbcon changes....
So, it's not a problem of your patch series.

> The whole interface is a bit of a mess. But I don't
> really see why anyone would want to use this on a
> per-fb device basis anyway. Either you want blinking
> stuff and extra power draw, or you don't.
>
> I think there are ways to turn of blinking via some escape
> sequences or something as well, so those could probably
> be used on a per-console basis. But I like to use this
> sysfs instead because it can't accidentally be re-enabled
> when random programs mess around with ttys.

I've added your patch series to the fbdev for-next git tree
to get some feedback from the autobuilders and testsuites.
I had to manually adjust patch #4 and #6 (after applying your v2
patches), so maybe you send a v3 of your whole series at some point.
Let's see what we get ...

Helge

  reply	other threads:[~2024-09-23 21:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-23 15:57 [PATCH 0/6] fbcon: Fix 'cursor_blink' sysfs attribute Ville Syrjala
2024-09-23 15:57 ` [PATCH 1/6] fbcon: Make cursor_blink=0 work when configured before fb devices appear Ville Syrjala
2024-09-23 21:04   ` Helge Deller
2024-09-23 21:30     ` Ville Syrjälä
2024-09-23 21:50       ` Helge Deller [this message]
2024-09-24  8:27         ` Helge Deller
2024-09-24  8:30           ` Ville Syrjälä
2024-09-26  6:08   ` Helge Deller
2024-09-26  9:57     ` Ville Syrjälä
2024-09-26 10:13       ` Helge Deller
2025-02-13 14:42         ` Ville Syrjälä
2025-02-13 22:47           ` Helge Deller
2025-02-14 17:41             ` Ville Syrjälä
2025-02-14 19:17               ` Helge Deller
2024-09-23 15:57 ` [PATCH 2/6] fbcon: Add sysfs attributes before registering the device Ville Syrjala
2024-09-24  7:34   ` Thomas Zimmermann
2024-09-23 15:57 ` [PATCH 3/6] fbcon: fbcon_cursor_noblink -> fbcon_cursor_blink Ville Syrjala
2024-09-23 19:46   ` Helge Deller
2024-09-23 20:26     ` Ville Syrjälä
2024-09-23 20:48   ` [PATCH v2 " Ville Syrjala
2024-09-24  7:35   ` [PATCH " Thomas Zimmermann
2024-09-23 15:57 ` [PATCH 4/6] fbcon: fbcon_is_inactive() -> fbcon_is_active() Ville Syrjala
2024-09-23 19:44   ` Helge Deller
2024-09-24  7:37   ` Thomas Zimmermann
2024-09-23 15:57 ` [PATCH 5/6] fbcon: Introduce get_{fg,bg}_color() Ville Syrjala
2024-09-23 19:44   ` Helge Deller
2024-09-24  7:42   ` Thomas Zimmermann
2024-09-23 15:57 ` [PATCH 6/6] fbcon: Use 'bool' where appopriate Ville Syrjala
2024-09-23 19:47   ` Helge Deller
2024-09-23 20:50   ` [PATCH v2 " Ville Syrjala
2024-09-24  7:51   ` [PATCH " 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=93c63567-d183-402e-82e0-f64b97b74ba8@gmx.de \
    --to=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=ville.syrjala@linux.intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).