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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux