Framebuffer devices that are registered by DRM drivers for fbdev emulation
have a "drmfb" suffix in their name. But makes them to be quite confusing
if a driver already has "drm" in its name:
$ cat /proc/fb
0 rockchipdrmdrmfb
$ cat /proc/fb
0 simpledrmdrmfb
Instead, let's just add a "-fb" suffix to denote that are DRM drivers FB:
$ cat /proc/fb
0 rockchipdrm-fb
$ cat /proc/fb
0 simpledrm-fb
Suggested-by: Peter Robinson <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f6baa204612..bbaff92c509 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1737,7 +1737,7 @@ void drm_fb_helper_fill_info(struct fb_info *info,
sizes->fb_width, sizes->fb_height);
info->par = fb_helper;
- snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
+ snprintf(info->fix.id, sizeof(info->fix.id), "%s-fb",
fb_helper->dev->driver->name);
}
--
2.31.1
On Fri, May 21, 2021 at 03:19:10PM +0200, Javier Martinez Canillas wrote:
> Framebuffer devices that are registered by DRM drivers for fbdev emulation
> have a "drmfb" suffix in their name. But makes them to be quite confusing
> if a driver already has "drm" in its name:
>
> $ cat /proc/fb
> 0 rockchipdrmdrmfb
>
> $ cat /proc/fb
> 0 simpledrmdrmfb
>
> Instead, let's just add a "-fb" suffix to denote that are DRM drivers FB:
>
> $ cat /proc/fb
> 0 rockchipdrm-fb
>
> $ cat /proc/fb
> 0 simpledrm-fb
>
> Suggested-by: Peter Robinson <[email protected]>
> Signed-off-by: Javier Martinez Canillas <[email protected]>
So what with all the drivers which do _not_ have drm in their name? Also
I'm never sure how much these are uapi or not ...
-Daniel
> ---
>
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6baa204612..bbaff92c509 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1737,7 +1737,7 @@ void drm_fb_helper_fill_info(struct fb_info *info,
> sizes->fb_width, sizes->fb_height);
>
> info->par = fb_helper;
> - snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
> + snprintf(info->fix.id, sizeof(info->fix.id), "%s-fb",
> fb_helper->dev->driver->name);
>
> }
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi
Am 21.05.21 um 17:33 schrieb Daniel Vetter:
> On Fri, May 21, 2021 at 03:19:10PM +0200, Javier Martinez Canillas wrote:
>> Framebuffer devices that are registered by DRM drivers for fbdev emulation
>> have a "drmfb" suffix in their name. But makes them to be quite confusing
>> if a driver already has "drm" in its name:
>>
>> $ cat /proc/fb
>> 0 rockchipdrmdrmfb
>>
>> $ cat /proc/fb
>> 0 simpledrmdrmfb
>>
>> Instead, let's just add a "-fb" suffix to denote that are DRM drivers FB:
>>
>> $ cat /proc/fb
>> 0 rockchipdrm-fb
>>
>> $ cat /proc/fb
>> 0 simpledrm-fb
>>
>> Suggested-by: Peter Robinson <[email protected]>
>> Signed-off-by: Javier Martinez Canillas <[email protected]>
>
> So what with all the drivers which do _not_ have drm in their name? Also
> I'm never sure how much these are uapi or not ...
Why do we need a suffix anyway?
> -Daniel
>
>> ---
>>
>> drivers/gpu/drm/drm_fb_helper.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index f6baa204612..bbaff92c509 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -1737,7 +1737,7 @@ void drm_fb_helper_fill_info(struct fb_info *info,
>> sizes->fb_width, sizes->fb_height);
>>
>> info->par = fb_helper;
>> - snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
>> + snprintf(info->fix.id, sizeof(info->fix.id), "%s-fb",
>> fb_helper->dev->driver->name);
>>
>> }
>> --
>> 2.31.1
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Hi
Am 21.05.21 um 19:18 schrieb Javier Martinez Canillas:
> On 5/21/21 6:53 PM, Thomas Zimmermann wrote:
>
> [snip]
>
>>>
>>> So what with all the drivers which do _not_ have drm in their name? Also
>>> I'm never sure how much these are uapi or not ...
>>
>
> That someone could threat as an uapi is a fair point indeed.
>
>> Why do we need a suffix anyway?
>>
>
> Yes, I thought the same and was torn about posting a patch to just remove
> the suffix. I don't think users care that much if is a fb device from a
> fbdev driver or a DRM driver using the fbdev emulation.
Yup. I don't see how anything in userspace would depend on the exact
name; especially since fbdev emulation only provides basic features.
(I'd welcome a counter examples that proves me wrong.)
IMHO we can risk it to remove the suffix entirely. But that needs an ack
from Daniel or Dave.
Best regards
Thomas
>
>>> -Daniel
>>>
>
> Best regards,
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
On 5/21/21 6:53 PM, Thomas Zimmermann wrote:
[snip]
>>
>> So what with all the drivers which do _not_ have drm in their name? Also
>> I'm never sure how much these are uapi or not ...
>
That someone could threat as an uapi is a fair point indeed.
> Why do we need a suffix anyway?
>
Yes, I thought the same and was torn about posting a patch to just remove
the suffix. I don't think users care that much if is a fb device from a
fbdev driver or a DRM driver using the fbdev emulation.
>> -Daniel
>>
Best regards,
--
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering
Hi
Am 25.05.21 um 15:08 schrieb Daniel Vetter:
> On Fri, May 21, 2021 at 08:53:56PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 21.05.21 um 19:18 schrieb Javier Martinez Canillas:
>>> On 5/21/21 6:53 PM, Thomas Zimmermann wrote:
>>>
>>> [snip]
>>>
>>>>>
>>>>> So what with all the drivers which do _not_ have drm in their name?
Also
>>>>> I'm never sure how much these are uapi or not ...
>>>>
>>>
>>> That someone could threat as an uapi is a fair point indeed.
>>>> Why do we need a suffix anyway?
>>>>
>>>
>>> Yes, I thought the same and was torn about posting a patch to just remove
>>> the suffix. I don't think users care that much if is a fb device from
a
>>> fbdev driver or a DRM driver using the fbdev emulation.
>>
>> Yup. I don't see how anything in userspace would depend on the exact name;
>> especially since fbdev emulation only provides basic features. (I'd welcome
>> a counter examples that proves me wrong.)
>>
>> IMHO we can risk it to remove the suffix entirely. But that needs an ack
>> from Daniel or Dave.
>
> If you guys with your distro hats on all think it doesn't matter, then
> yeah I'm all for dropping the somewhat silly -drm or drmfb suffixes. I
> think that was just way back so it's easier to know you've loaded the
> right driver, back when there was both drm and native fbdev drivers
> around. But now I think for new hw there's only drm, so should be all
> fine.
Suse doesn't use fbdev, except for some outliers; most notably hypervfb
and generic efifb/vesafb. Both are now being replaced with drm code.
From what I've seen, it's the same for other distros. And X11 checks
for the existence of device files anyway IIRC.
Best regards
Thomas
> -Daniel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Hello,
On 5/25/21 3:34 PM, Thomas Zimmermann wrote:
[snip]
>>
>> If you guys with your distro hats on all think it doesn't matter, then
>> yeah I'm all for dropping the somewhat silly -drm or drmfb suffixes. I
>> think that was just way back so it's easier to know you've loaded the
>> right driver, back when there was both drm and native fbdev drivers
>> around. But now I think for new hw there's only drm, so should be all
>> fine.
>
> Suse doesn't use fbdev, except for some outliers; most notably hypervfb
> and generic efifb/vesafb. Both are now being replaced with drm code.
> From what I've seen, it's the same for other distros. And X11 checks
> for the existence of device files anyway IIRC.
Yes, I believe is the same for us.
I'll post a patch to just remove the suffix then. Thanks you both
for the feedback.
>
> Best regards
> Thomas
>
>> -Daniel
>>
>
Best regards,
--
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering
On Fri, May 21, 2021 at 08:53:56PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 21.05.21 um 19:18 schrieb Javier Martinez Canillas:
> > On 5/21/21 6:53 PM, Thomas Zimmermann wrote:
> >
> > [snip]
> >
> > > >
> > > > So what with all the drivers which do _not_ have drm in their name? Also
> > > > I'm never sure how much these are uapi or not ...
> > >
> >
> > That someone could threat as an uapi is a fair point indeed.
> > > Why do we need a suffix anyway?
> > >
> >
> > Yes, I thought the same and was torn about posting a patch to just remove
> > the suffix. I don't think users care that much if is a fb device from a
> > fbdev driver or a DRM driver using the fbdev emulation.
>
> Yup. I don't see how anything in userspace would depend on the exact name;
> especially since fbdev emulation only provides basic features. (I'd welcome
> a counter examples that proves me wrong.)
>
> IMHO we can risk it to remove the suffix entirely. But that needs an ack
> from Daniel or Dave.
If you guys with your distro hats on all think it doesn't matter, then
yeah I'm all for dropping the somewhat silly -drm or drmfb suffixes. I
think that was just way back so it's easier to know you've loaded the
right driver, back when there was both drm and native fbdev drivers
around. But now I think for new hw there's only drm, so should be all
fine.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch