(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-drive...
Sven.
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
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
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
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
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 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
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
dri-devel@lists.freedesktop.org
-
Sven Schnelle -
Thomas Zimmermann