From: Michael Schmitz <schmitzmic@gmail.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
linux-m68k@vger.kernel.org, geert@linux-m68k.org
Cc: Miro Kropacek <miro.kropacek@gmail.com>, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2 2/5] fbdev: Give atafb proper parent
Date: Tue, 18 Aug 2026 07:11:20 +1200 [thread overview]
Message-ID: <badcf850-5e4d-40cb-11df-ff15f23e4983@gmail.com> (raw)
In-Reply-To: <3347106a-f0f9-415a-94e4-94bc9b8182ef@suse.de>
Hi Thomas,
Am 17.08.2026 um 19:57 schrieb Thomas Zimmermann:
>>>> The atafb fb device registers no parent, causing a missing symlink
>>>> (/sys/class/graphics/fb0/device). Xorg fbdevhw driver looks for that
>>>> symlink when scanning for devices, so add a parent node for atafb.
>>>
>>> Do you really have these devices to test with?
>>
>> Not the particular hardware that patches 3 and 4 add support for, but
>> the 'normal' Videl that is found in every Falcon, yes.
N.B.: actual hardware won't be essential to test - an emulator such as
ARAnyM will do fine.
>>
>>> If so, could you also replace the hard coded fb_info with a call to
>>> framebuffer_alloc()?
>>
>> Can't see how that would work - fb_info isn't passed to all functions
>> that need to use it, especially in the hardware detection phase (hence
>> the use of a static fb_info struct)?
On second thought, depending on how early in driver init fb_info is
needed, I may get away with turning it into a struct *fb_info and using
that where it can't easily be passed.
>
> You'd have to modify the driver to pass the allocated instance, of
> course. It's not a trivial oneliner, but if this driver is still
> relevant, it might be worth improving it.
Your point is taken - I'll take a look at what would be required to pass
fb_info to all users. It's been nineteen years since rewrote atafb so
getting my head around the call sequences may take awhile.
Cheers,
Michael
>
> Best regards
> Thomas
>
>>
>> Cheers,
>>
>> Michael
>>
>>>>
>>>> Signed-off-by: Miro Kropacek <miro.kropacek@gmail.com>
>>>> Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>
>>>> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
>>>> Cc: <linux-fbdev@vger.kernel.org>
>>>> Link: https://lists.debian.org/debian-68k/2026/08/msg00000.html
>>>> ---
>>>> drivers/video/fbdev/atafb.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
>>>> index b8ed1c537293..3d540803dc2b 100644
>>>> --- a/drivers/video/fbdev/atafb.c
>>>> +++ b/drivers/video/fbdev/atafb.c
>>>> @@ -3101,6 +3101,11 @@ static int __init atafb_probe(struct
>>>> platform_device *pdev)
>>>> #endif /* ATAFB_EXT */
>>>> // strcpy(fb_info.mode->name, "Atari Builtin ");
>>>> + /* Parent the fb device properly: without this fb0 registers as a
>>>> + * virtual sysfs device with no /sys/class/graphics/fb0/device
>>>> link,
>>>> + * which makes Xorg's fbdevhw reject it ("No devices detected").
>>>> + */
>>>> + fb_info.device = &pdev->dev;
>>>
>>> Because this is supposed to happen in framebuffer_alloc() and keeping it
>>> there would be preferable.
>>>
>>> Best regards
>>> Thomas
>>>
>>>> fb_info.fbops = &atafb_ops;
>>>> // try to set default (detected; requested) var
>>>> do_fb_set_var(&atafb_predefined[default_par - 1], 1);
>>>
>>
>
next prev parent reply other threads:[~2026-08-17 19:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 7:37 [PATCH v2 0/5] m68k SuperVidel patches Michael Schmitz
2026-08-16 7:37 ` [PATCH v2 1/5] m68k: Fix atari mouse movement Michael Schmitz
2026-08-17 8:00 ` Geert Uytterhoeven
2026-08-16 7:37 ` [PATCH v2 2/5] fbdev: Give atafb proper parent Michael Schmitz
2026-08-16 14:38 ` Helge Deller
2026-08-16 18:37 ` Michael Schmitz
2026-08-17 6:34 ` Thomas Zimmermann
2026-08-17 7:49 ` Michael Schmitz
2026-08-17 7:57 ` Thomas Zimmermann
2026-08-17 19:11 ` Michael Schmitz [this message]
2026-08-19 1:35 ` Michael Schmitz
2026-08-16 7:37 ` [PATCH v2 3/5] fbdev: Add support for further video bit depths on atafb:external Michael Schmitz
2026-08-16 7:37 ` [PATCH v2 4/5] fbdev: Add support for SuperVidel's SuperBlitter Michael Schmitz
2026-08-16 7:37 ` [PATCH v2 5/5] m68k: Add support for Svethlana Michael Schmitz
2026-08-17 7:14 ` Geert Uytterhoeven
2026-08-17 8:50 ` Geert Uytterhoeven
2026-08-17 8:52 ` Geert Uytterhoeven
2026-08-17 18:57 ` Michael Schmitz
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=badcf850-5e4d-40cb-11df-ff15f23e4983@gmail.com \
--to=schmitzmic@gmail.com \
--cc=geert@linux-m68k.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=miro.kropacek@gmail.com \
--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.