Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: graphic drivers and simplefb



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


Home | Main Index | Thread Index | Old Index