Thread (10 messages) 10 messages, 2 authors, 2021-11-08

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

From: Sven Schnelle <hidden>
Date: 2021-11-08 16:31:17
Also in: dri-devel

Thomas Zimmermann [off-list ref] writes:
Hi

Am 06.11.21 um 22:02 schrieb Sven Schnelle:
quoted
Thomas Zimmermann [off-list ref] writes:
quoted
Hi

Am 01.11.21 um 09:54 schrieb Sven Schnelle:
quoted
Hi Thomas,
Thomas Zimmermann [off-list ref] 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!
quoted
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.
quoted
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. 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.
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.

Regards
Sven
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help