* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96
called by debug_init_post_vm().
Since the availability of a blue screen specific getchar() is static anyway, there
is no need for the sBlueScreenGetChar variable (only the message "only serial input
available" gets lost, but since that is platform specific anyway...).
Hello blue screen! We now have an on-screen KDL, to be enabled by the kernel
setting "bluescreen", just like on BeOS.
The blue screen does not yet support any cursor actions or backspace, though (need
to grab some stuff from our console driver).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12896 a95241bf-73f2-0310-859d-f6bbb57e9c96
the APM driver to see it at work).
The frame buffer console now creates such a boot item to give a potential
VESA driver access to the boot frame buffer configuration.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12221 a95241bf-73f2-0310-859d-f6bbb57e9c96
will also get syscall that the app_server has to call in order to update
the frame buffer configuration.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11352 a95241bf-73f2-0310-859d-f6bbb57e9c96
