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

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

[Sven Schnelle]

Hi Thomas,

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Am 31.10.21 um 20:53 schrieb Sven Schnelle:
>> Hi List(s),
>> i wrote a fbdev driver for the HP Visualize FX cards used some of
>> the
>> PA-RISC workstations. It utilizes some of the 2D acceleration features
>> present in the card.
>> [..]
>
> Thanks for all the work you put into this. We welcome drivers even for
> older hardware, but not for fbdev. DRM is all the rage now and has
> been for a while. I'd like to ask you to convert the driver to DRM and
> resubmit to <dri-devel@lists.freedesktop.org>.
>
> I while ago, I made conversion helpers for this. You can look at [1]
> for a trivial DRM drivers that wraps existing fbdev drivers for use
> with DRM. Once you have that, it turns into a refactoring job.

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.

Sven

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

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1884 bytes --]

Hi

Am 01.11.21 um 09:54 schrieb Sven Schnelle:
> Hi Thomas,
> 
> Thomas Zimmermann <tzimmermann@suse.de> writes:
> 
>> Am 31.10.21 um 20:53 schrieb Sven Schnelle:
>>> Hi List(s),
>>> i wrote a fbdev driver for the HP Visualize FX cards used some of
>>> the
>>> PA-RISC workstations. It utilizes some of the 2D acceleration features
>>> present in the card.
>>> [..]
>>
>> Thanks for all the work you put into this. We welcome drivers even for
>> older hardware, but not for fbdev. DRM is all the rage now and has
>> been for a while. I'd like to ask you to convert the driver to DRM and
>> resubmit to <dri-devel@lists.freedesktop.org>.
>>
>> I while ago, I made conversion helpers for this. You can look at [1]
>> for a trivial DRM drivers that wraps existing fbdev drivers for use
>> with DRM. Once you have that, it turns into a refactoring job.
> 
> 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]

If you need help, there's <dri-devel@lists.freedesktop.org>.

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tiny/cirrus.c

> 
> 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 --]

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

[Sven Schnelle]

Hi Thomas,

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Am 01.11.21 um 09:54 schrieb Sven Schnelle:
>> 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.

Right now the driver only supports 8 bit pseudocolor, because i wanted
to start with something easy to get the kernel fbcon running. I have no
idea (yet) how to switch the card into other color formats. And neither
how to do pseudo color with drm. But i'll figure it out i guess.

> Don't worry, it's easy. Take a look at the cirrus driver for a simple DRM
> driver. [1]

Great, i also picked that driver as a template. :-)

Thanks for your help and pointers, much appreciated!

Sven

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

[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, 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.

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?

Thanks
Sven

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

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

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.

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.

Best regards
Thomas

> 
> Thanks
> 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 --]

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

[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. 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

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

[Thomas Zimmermann]

[-- 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 --]