From: Thomas Zimmermann <tzimmermann@suse.de>
To: Sven Schnelle <svens@stackframe.org>
Cc: linux-fbdev@vger.kernel.org,
dri-devel <dri-devel@lists.freedesktop.org>,
linux-parisc@vger.kernel.org, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH/RFT] fbdev driver for HP Visualize FX cards
Date: Mon, 8 Nov 2021 20:08:51 +0100 [thread overview]
Message-ID: <0b89a992-2a4a-4e39-93af-0690fec64912@suse.de> (raw)
In-Reply-To: <87ee7qvcc7.fsf@x1.stackframe.org>
[-- Attachment #1.1: Type: text/plain, Size: 3941 bytes --]
Hi
Am 08.11.21 um 17:31 schrieb Sven Schnelle:
> 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.
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
prev parent reply other threads:[~2021-11-08 19:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211031195347.13754-1-svens@stackframe.org>
[not found] ` <cd0f90d9-7dba-af33-f88b-289fc6f80b51@suse.de>
2021-11-01 8:54 ` [PATCH/RFT] fbdev driver for HP Visualize FX cards 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
2021-11-08 19:08 ` Thomas Zimmermann [this message]
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=0b89a992-2a4a-4e39-93af-0690fec64912@suse.de \
--to=tzimmermann@suse.de \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=svens@stackframe.org \
/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