Hi Am 18.11.22 um 09:57 schrieb Helge Deller:
Hello Maximilian, On 11/15/22 23:05, Zopolis0 wrote:I'm not too familiar with DRM, unfortunately, so I can't give you a great answer.My current aim is just to get this and the other gc-linux patches into upstream before they begin to rot.But, I'd be happy to look into porting this to DRM after it's merged though.Your aim to upstream the patches is ok, but generally DRM is the way forwardfor Linux graphics.I've briefly looked at the driver and it seems that it initially sets up the graphics mode, and that changes to the screen are then rendered into a memorybuffer from where a damage detection is then run which updates the screen. As far as I understand DRM, this is how it's done in DRM for various graphics drivers (Thomas, please correct me if I'm wrong!).
You're right. We do this for most simple hardware that has limited options for color formats and/or display memory.
Additionally the driver includes two IOCTLs for FBIOWAITRETRACE (wait for retrace) and FBIOFLIPHACK (wait until a specific video page is visible or not visible).I assume libsdl is using those? Are they still required nowadays? I don't know if such ioctls are doable in DRM or if DRM has other possibilities - this would be interesting as it would help to decide if porting to DRM is possible & useful.
There's the DRM_IOCTL_WAIT_VBLANK ioctl, which appears to do the same as FBIOWAITRETRACE. IDK the meaning of FBIOFLIPHACK, but if it's just for vsync-ing display updates then DRM does this automatically as part of the pageflip.
Usually we also expect the patches to be sent with proper commit messages in plain text to the mailing lists. Since you had problems with this, I'vestored your patch in the fbdev-wii branch of my git repo, so that it's easierfor me to take a look at the patch. For people who are interested as well, it's archieved here now: https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=fbdev-wii&id=802bb0aa1af149ec8299ea7dfebf3fc10dc9c3dfThat said, I wish you much success with pushing the other gc-patches upstream. But for now I won't merge this patch unless the possibility to convert to DRMhas been fully clarified.
The best we can do might be drivers/staging. But staging would only make it easier to track DRM during the port.
With DRM, you'd initially have to put some effort into the port. And DRM is different enough from fbdev that it really is work. But once ported, DRM offers a well-maintained set of helpers and features. And most of all, you'd get support for modern userspace. Fbdev support in userspace is dying and only the text console is reliably available.^1
Best regards Thomas ^1: There are ideas of moving away from fbdev-based consoles.
HelgeOn Wed, 16 Nov 2022 at 04:05, Helge Deller <deller@xxxxxx <mailto:deller@xxxxxx>> wrote:On 11/15/22 11:05, Zopolis0 wrote: > Just upstreaming the gc/wii framebuffer driver from gc-linux, and > incorporates Farter's patch to solve the color issue. See> https://fartersoft.com/blog/2011/06/22/hacking-up-an-rgb-framebuffer-driver-for-wii-linux/ <https://fartersoft.com/blog/2011/06/22/hacking-up-an-rgb-framebuffer-driver-for-wii-linux/> > and https://fartersoft.com/blog/2011/07/31/hacking-up-an-rgb-framebuffer-driver-for-wii-linux-take-two/ <https://fartersoft.com/blog/2011/07/31/hacking-up-an-rgb-framebuffer-driver-for-wii-linux-take-two/>.Just for the record: Is there a reason why it wasn't (or can't be) ported to DRM ?Looking at the patch (and the hardware behind it) I do see various reasons,but I'd like to hear it from you... Helge
-- 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:
OpenPGP_signature
Description: OpenPGP digital signature
