Linux PARISC architecture development
 help / color / mirror / Atom feed
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 --]

      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