[PATCH 1/6] fbcon: Make cursor_blink=0 work when configured before fb devices appear

Helge Deller deller at gmx.de
Fri Feb 14 19:17:48 UTC 2025


On 2/14/25 18:41, Ville Syrjälä wrote:
> On Thu, Feb 13, 2025 at 11:47:42PM +0100, Helge Deller wrote:
>> On 2/13/25 15:42, Ville Syrjälä wrote:
>>> On Thu, Sep 26, 2024 at 12:13:04PM +0200, Helge Deller wrote:
>>>> On 9/26/24 11:57, Ville Syrjälä wrote:
>>>>> On Thu, Sep 26, 2024 at 08:08:07AM +0200, Helge Deller wrote:
>>>>>> Hi Ville,
>>>>>>
>>>>>> On 9/23/24 17:57, Ville Syrjala wrote:
>>>>>>> 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.
>>>>>>
>>>>>> are you planning to send follow-up patches to address those shortcomings?
>>>>>
>>>>> Nope. I don't really care about those as I never plan to
>>>>> turn the cursor blinking back on after turning it off via
>>>>> udev.
>>>>
>>>> Sad, but OK. I will look into this when I find time.
>>>> I'd hoped to push those patches upstream during this merge window,
>>>> but then I think I have to delay them at least until kernel 6.13.
>>>
>>> What happened to these? Not seeing them anywhere...
>>
>> The issues above are not fixed yet, so they are still parked in my for-next-next tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/log/?h=for-next-next
>
> Those issues are already present in the current code, so
> I'm sure what's the point of holding this up due to them.

Let's try to fix it while we touch it.

Helge


More information about the dri-devel mailing list