Re: graphic drivers and simplefb

[Jared McNeill <jmcneill%invisible.ca@localhost>]

On Thu, 5 Apr 2018, Manuel Bouyer wrote:

> > For simplefb I have everything I need..
>
> OK, so in this case you'd want to have simplefb be the console,
> until a more complete graphic driver attaches and take over
> (much like we do with vga vs drm drivers in the x86 world).

Yeah maybe we should focus on that instead.

> > Boards exist where serial console is difficult or impossible to access. Lets
> > come up with a solution that satisfies all cases..
>
> Sure. In this case I guess stdout-path will not be set to the serial port
> though, so it should not use the serial port at all. I don't think we have
> anything to change for this.
>
> What I'm talking about is: stdout-path is set to the serial port, but
> we have console=fb in the bootargs. In this case I think we could use
> the serial port as console util the graphic driver (be it simplefb or
> something else) is attached, at which point it will attach as console and
> replay the dmesg buffer.
>
> For this we need either to have the serial port attach before the
> graphic drivers, or have a way to reset the console status of the serial
> port when needed.

The serial port will only attach as console if you have chosen it to be 
the console (stdout-path). I want to solve this problem the right way, not 
relying on device attach order, because device order hacks become 
unmanageable when you are dealing with multiple SoC families, shared 
drivers, and GENERIC kernels.

We need a solution that covers these use cases:

 - Console is UART (may or may not have display capabilities)
 - Console is FB (laptop, tablet, etc where UART is difficult to access)
 - Console device can be either UART or FB (like a dev board, where we
   support both with WSDISPLAY_MULTICONS)

Currently the armv7.img/arm64.img configs use 'console=fb' to get correct 
behavior in these 3 cases. This setup has been working well so far, but 
there is definite room for improvement. I just want to make sure that the 
existing functionality doesn't get broken.

Cheers,
Jared