Hi Am 08.11.21 um 17:31 schrieb Sven Schnelle:
Thomas Zimmermann <tzimmermann@xxxxxxx> writes:Hi Am 06.11.21 um 22:02 schrieb Sven Schnelle:Thomas Zimmermann <tzimmermann@xxxxxxx> writes:Hi Am 01.11.21 um 09:54 schrieb Sven Schnelle:Hi Thomas, Thomas Zimmermann <tzimmermann@xxxxxxx> 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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
