Hi

Am 18.11.22 um 09:57 schrieb Helge Deller:

Hello Maximilian,

On 11/15/22 23:05, Zopolis0 wrote:

quoted

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

quoted

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