From: Sven Schnelle <svens@stackframe.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: linux-parisc@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel <dri-devel@lists.freedesktop.org>,
Helge Deller <deller@gmx.de>
Subject: Re: [PATCH/RFT] fbdev driver for HP Visualize FX cards
Date: Mon, 08 Nov 2021 17:31:04 +0100 [thread overview]
Message-ID: <87ee7qvcc7.fsf@x1.stackframe.org> (raw)
In-Reply-To: <312d6427-67ff-67c5-b662-23127bb76d12@suse.de> (Thomas Zimmermann's message of "Mon, 8 Nov 2021 09:37:01 +0100")
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Hi
>
> Am 06.11.21 um 22:02 schrieb Sven Schnelle:
>> Thomas Zimmermann <tzimmermann@suse.de> writes:
>>
>>> Hi
>>>
>>> Am 01.11.21 um 09:54 schrieb Sven Schnelle:
>>>> Hi Thomas,
>>>> Thomas Zimmermann <tzimmermann@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. 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
next prev parent reply other threads:[~2021-11-08 16:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-31 19:53 [PATCH/RFT] fbdev driver for HP Visualize FX cards Sven Schnelle
2021-10-31 19:53 ` [PATCH] video: fbdev: add HP Visualize FX driver Sven Schnelle
2021-11-01 7:07 ` [PATCH/RFT] fbdev driver for HP Visualize FX cards Thomas Zimmermann
2021-11-01 8:54 ` Sven Schnelle
2021-11-01 9:33 ` Thomas Zimmermann
2021-11-01 10:11 ` Sven Schnelle
2021-11-06 21:02 ` Sven Schnelle
2021-11-08 8:37 ` Thomas Zimmermann
2021-11-08 16:31 ` Sven Schnelle [this message]
2021-11-08 19:08 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee7qvcc7.fsf@x1.stackframe.org \
--to=svens@stackframe.org \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).