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

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

[Thomas Zimmermann]

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

(cc'ing dri-devel)

Hi

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.
> 
> What is working right now:
> 
> - modesetting (tested all VESA modes between 640x480 - 1600x1200).
> - hardware cursor
> - 2D acceleration like imageblit and fillrect.
> 
> What is not (fully) working:
> 
> - X11 with fbdev. xinit + mwm looks almost ok, except some corruption
> where the text cursor was drawn when it is moved.
> - more advanced X11 programs. xfce4-session doesn't really show much.
> 
> I would be most interested if people could test this driver with their FX
> cards and report. I know that Visualize FXe doesn't work because it uses
> completely different register addresses. For FX10 i would hope that they
> share the same register set as they are based on the same architecture.
> Note that you have to disable the sticon driver, otherwhise that one would
> hog the PCI card and visualizefx would never be probed.
> 
> Not sure about FX2/4/6. Might be different, might be not.
> 
> I obtained all the knowledge about the registers by watching what STI and the HP-UX
> X Server writes into the card. So the register names might be called different
> compared to what HP has written in their data books.

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.

Best regards
Thomas

[1] 
https://gitlab.freedesktop.org/tzimmermann/linux/-/commits/fbconv-plus-drivers

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