Re: [PATCH] Add framebuffer device driver for gamecube/wii, incorporating Farter's work.

[Thomas Zimmermann <tzimmermann@suse.de>]

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

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 
> forward
> for 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 
> memory
> buffer 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've
> stored your patch in the fbdev-wii branch of my git repo, so that it's 
> easier
> for 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=802bb0aa1af149ec8299ea7dfebf3fc10dc9c3df
> 
> That 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 DRM
> has 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.

> 
> Helge
> 
>> On Wed, 16 Nov 2022 at 04:05, Helge Deller <deller@gmx.de 
>> <mailto:deller@gmx.de>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]