* If the VESA driver remaps the frame buffer on init, it will now also make
sure that the kernel's frame buffer console points to the right data.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34835 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The VESA driver now tries to find the PCI card that it is controlling by
checking the physical frame buffer location.
* This allows us to map the whole frame buffer at once, which means there is no
need anymore to remap the memory on mode change.
* Also, this will ease the burden of the MTRRs, as the memory size will be
properly aligned.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34206 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added VESA capabilities field to the kernel args.
* 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

Some work in progress of the MTRR support. Shouldn't do any harm yet :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15525 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed debug/console.c, we no longer need it. frame_buffer_console_init() is now
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

Added the get_boot_item() call similar to what BeOS exports (have a look at
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

Added header for the frame buffer console module. It's here because it
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

* If the VESA driver remaps the frame buffer on init, it will now also make
sure that the kernel's frame buffer console points to the right data.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34835 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The VESA driver now tries to find the PCI card that it is controlling by
checking the physical frame buffer location.
* This allows us to map the whole frame buffer at once, which means there is no
need anymore to remap the memory on mode change.
* Also, this will ease the burden of the MTRRs, as the memory size will be
properly aligned.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34206 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added VESA capabilities field to the kernel args.
* 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

Some work in progress of the MTRR support. Shouldn't do any harm yet :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15525 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed debug/console.c, we no longer need it. frame_buffer_console_init() is now
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

Added the get_boot_item() call similar to what BeOS exports (have a look at
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

Added header for the frame buffer console module. It's here because it
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