[PATCH/RFT] fbdev driver for HP Visualize FX cards

[Thomas Zimmermann]

Hi

Am 08.11.21 um 17:31 schrieb Sven Schnelle:
> Thomas Zimmermann <tzimmermann at suse.de> writes:
> 
>> Hi
>>
>> Am 06.11.21 um 22:02 schrieb Sven Schnelle:
>>> Thomas Zimmermann <tzimmermann at suse.de> writes:
>>>
>>>> Hi
>>>>
>>>> Am 01.11.21 um 09:54 schrieb Sven Schnelle:
>>>>> Hi Thomas,
>>>>> Thomas Zimmermann <tzimmermann at suse.de> writes:
>>>>> Thanks, i wasn't aware as i normally don't do any graphics related
>>>>> development. I take a look at dri and port the driver, which is
>>>>> hopefully not too hard.
>>>>
>>>> Sounds good.
>>>>
>>>> The one big difference when converting is that DRM really wants
>>>> drivers to support 32-bit XRGB colors. It's not a DRM limitation per
>>>> se, but a requirement of today's userspace programs. AFAICS your fbdev
>>>> driver uses a 256-color palette format. So the DRM driver would have
>>>> to convert
>>>> XRGB8888 to 8-bit RGB332 and install a corresponding palette. Don't
>>>> worry, it's easy. Take a look at the cirrus driver for a simple DRM
>>>> driver. [1]
>>> I have converted the driver,
>>
>> Cool!
>>
>>> but am using FORMAT_C8 because i haven't
>>> figured out yet how to switch the card to XRGB8888. That's still on the
>>> TODO list.
>>
>> Don't worry. As I outlined , you can still convert any image from
>> XRGB888 to RGB332 and display this instead.
>>
>>> One question about hw blitting: with the old fbdev framework one
>>> could
>>> replace the fb_imageblit function. For normal console text, this
>>> function gets called with a monochrome bitmap, and an fg/bg color value.
>>> This makes it easy to use HW accelerated blitting for text. In the
>>> gpu/drm drivers i think i found only one driver (nouveau) doing this and
>>> that was via the drm fbdev layer.
>>> Is that still the way to go, or is there a better way to do HW
>>> accelerated
>>> text blitting?
>>
>> Simply call drm_fbdev_generic_setup() after registering the
>> device. This should give you a console.
> 
> Yes, that's what i have, and it works. 

Nice :)

> The only thing that is odd (and i'm
> not sure whether that's a bug or not), is that fbset changes the
> resolution of the framebuffer, but doesn't reprogram the hardware to the
> new resolution. That means if i boot with 1920x1080 resolution, and do a
> fbset -a 640x480-60, only a small part of the screen is used now, but
> the physical resolution stays at 1920x1080. I first thought that's a bug
> in my driver, but my x86 Thinkpad X1 with nouveau behaves the same.

I'm surprised that anything happens at all. We don't even support 
changing the resolution via fbdev interfaces. I guess that it changes 
internal state such that the console only renders 640x480. But I can say 
for sure without investigating.

There's fbdev modesetting code in DRM's vmwgfx driver. I thought about 
porting it to the generic helpers, but it's not really important ATM.

> 
>> Don't bother about HW-accelerated blitting. From what I've heard, it
>> barely makes a difference nowadays. And our generic helpers have
>> plenty of features. Not using them to get a small benefit from HW
>> blitting isn't worth it.
> 
> Not sure. With my first driver (the fbdev/fbcon one without drm), that
> made a big difference when scrolling or the whole screen was updated. I
> never measured it, but i would think it was a 1:10 ratio.

That's interesting. Did you map the device's framebuffer memory with 
write combining enabled? Most HW does support WC mappings and it really 
makes a difference.

What I heard was about i915. I'd guess that even 1:10 is still a hard 
sell in DRM land. Especially since fbdev is on its way out.

Best regards
Thomas

> 
> Regards
> Sven
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20211108/68dd091f/attachment-0001.sig>