* Add boot option to rotate screen display through 90 degrees.
Some machines have a detachable display that can be used in either
portrait or landscape orientations, and require software to rotate
the displayed image accordingly. There is no way to detect the
current orientation through the BIOS, so provide a boot option to
control this. Hopefully we only need to support one (+90 degree)
angle.
Note that the rotate option only works in graphical mode. When booted
by a legacy BIOS using text mode, we have to rely on the BIOS to do
what's necessary.
* Extend boot command line options for display screen control.
Replace "rotate" option with "screen.rhs-up" and "screen.lhs-up" to
allow rotation in either direction. Add a "screen.mode=<w>x<h>"
option to set a preferred width <w> and height <h> for the UEFI
frame buffer. Also allow "screen.mode=bios" to use the default
UEFI frame buffer resolution.
* Add more debug output for EFI frame buffer mode.
* Replicate command line parsing of screen options in efisetup.c.
Trying to do it only once in screen.c didn't work, because static
variables initialied to zero are placed in the bss section, and we
don't zero the bss section until after efisetup() is executed.
The resulting code is in fact smaller, because the compiler can
optimise better when everything is local.
* Add a boot command line option for efisetup debug.
* Improve EFI debug test screen pattern.
* Document the new screen and efidebug boot command line options.
* Fix typo in README.
A headless EFI system may have no GOP devices. In this case, disable
output to the physical display, but continue to write to the shadow
buffer. This allows operation via a serial console.
* Add preliminary support for TTY Serial/UART (#15)
* Use shadow_buffer instead of VGA buffer to get a framebuffer-agnostic TTY supprot
* Added menu browsing & inputs from Serial TTY (#15)
* Add fix for degree symbol on TTY. Correct serial.c & serial.h file created with CRLF (#15)
* Move tty_error_redraw() to insure correct redraw when a error occurs
* Many reindent / cleanup
* Various optimization from @martinwhitaker comments
This is needed for subsequent changes. If we do ever get presented with
a frame buffer larger than 8192x8192 pixels, we'll need to think again
about how to manage it.
