vesa: disable the livepatching code by default

It can be enabled by putting "bios_patching true" in the VESA settings
file.

This patching does not work yet on modern hardware, but the detection
code to decide if we should try patching still says it found the
modetables. In this situation we can crash the BIOS or other weird
things can happen.

To avoid these problems, and because VESA is supposed to be the failsafe
option, disable this code by default, and let people who want to
experiment with it first enable it in the settings file.

Should fix #17633.

Change-Id: I4d89ff6dfeb7d02e39cd3da7b22ddd5411b10822
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5499
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

vesa: live mode patching, nvidia version.

Some improvements to allow setting 8, 15, 16 and 32bit modes, and detect
the correct mode number after patching the BIOS automatically, instead
of hardcoding it.

Also move the patching code to a separate file.

Fixes #10570.

Change-Id: I920f448b59ad7373cb8595d92ce3fa52324be67e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4629
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

vesa: implement live patching for ATI/AMD cards

This uses atombios headers to find where in the BIOS the video mode
tables is located. Then, we can replace entries in the table (in a RAM
copy of the BIOS, of course) and inject any video mode we need. To make
the table easy to find, the Atombios headers from the radeon_hd are
reused, but no atombios code execution takes place here.

Change-Id: If1981b1574822d4ce1e072dd6437a727192ce7cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4628
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

vesa: report BIOS manufacturer (visible in screen preferences)

Get the OEM string from the VESA info block (and also get the memory
size from there while we are at it). If the string is empty, use the
BIOS type (identified in other ways) to still report something.

Change-Id: I8cbd75d19f624a43db05e82d1e1b2a536cc418b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4625
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

vesa: live BIOS patching for Intel video devices

The VESA standard does not define any way for software to set a custom
video mode, which means normally we would be constrained to whichever
modes the video card manufacturer decided to provide. However, since we
run the BIOS in an emulated environment, it is possible (and even quite
easy) to patch it and inject any video mode we want, provided we know
the format to use and where to put the info in.

This approach was used in the NewOS VESA driver, as well as in
915resolution (a tool that predates the availability of native drivers
for Linux for Intel videocards). Later on it was also used in Chameleon
and Clover, bootloaders that are used for hackintoshes (running MacOS on
unsupported hardware).

This commit implements full support for Intel cards only, AMD and NVidia
will be added later (but there is preliminary code to detect them)

Change-Id: I2c528ba18b3863f486da694860a10761efcbfb3f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4624
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Remove dumb-framebuffer handling logic from the VESA driver.

This reverts commit a0db7ef2729955d83f002b51034f0dedd39b4a0a.
This reverts commit 40cdf7d607211c5f27854cd3048ac00e8baf20ab.
This reverts commit 2ff22d6734176a2cf93a05c6842f69ef59d27a26.
This reverts commit b9eacd390dbdf776561062b324dab4c6f5a0dc80.
This partially reverts commit 5ae7ac5fd9957b3ff9faf211fd66976170c21b2c.

This was all added in the run-up to the removal of the framebuffer driver,
or was added since then to enhance framebuffer-only support in that driver.

Change-Id: I32ab8199f22cf6846545ae19e943c98012b2a1d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4615
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

drivers/vesa: fix for RISC-V

* Make ISA bus optional in vesa driver

Change-Id: I1f38f92d81fbfe47224893e1d9dbf6a74306e2f0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3986
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA.

It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.

No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)

vesa: fold framebuffer driver into vesa driver.

* The app_server isn't designed to support two fallback drivers, so
on systems using UEFI to boot, the framebuffer driver will often
win when other drivers would likely work on those systems.

Updated drivers to use BIOS module instead of vm86.

* Calmed down CID 1976; the problematic situation should not be able to occur,
but I've changed it anyway to make the code clearer.


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

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


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

Fixed complete mixup of order of arguments passed to remap_frame_buffer().
Should fix #5186.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34846 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

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 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

* Setting the depth to 1 for VGA mode in frame_buffer_console_init() was not
a good idea; it didn't have any consequences in there, but actually broke
the app_server's support for the VGA mode.
* Cleanup.


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

* Added DPMS support to the VESA driver, in case the hardware/BIOS supports it.
* Minor cleanup.


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

* On some systems, switching the resolution in VESA mode during
runtime did not work and gave a "General System Error".
Jan Kloetzke provided a temporary work around, the area
which the BIOS can access is enlarged, although according to
specs, this should not be needed.
* After switching modes in the VESA driver, turn on write
combining for the frame buffer area. This gives a huge speed
boost for all graphics drawing. Only people for which mode
changes did not work were using the full speed since the
VESA mode switching support was added.
* Cleanup in the Jamfile, some header directories were included
multiple times.


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

* The boot loader now passes on its EDID info to the kernel, and that will
be put into a boot_item in frame_buffer_console_init().
* The VESA driver now supports gettings the EDID information as well; this
is necessary now, since the app_server no longer takes over the mode the
boot loader had chosen.
* Note, we might want to do this via vm86 instead in the future, and remove
the kernel part again.


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

Patch by Jan Klötzke with minor changes by myself:
* Use vm86 mode to call the VESA BIOS to do the actual mode switching by
providing an ioctl in the vesa driver.
* Fix vm86.h.


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

* Changed get_boot_item() API: it now also can retrieve the size of the boot
item entry.
* The bios_ia32 video platform code now stores the available VESA modes in
the new vesa_modes kernel_args field.
* When configuring a VESA mode via settings file, it's no longer needed to
specify the exact mode - the closest available mode is now used. This should
help with bug #1962.
* frame_buffer_console_init() now also creates a boot_item for the VESA modes
in the kernel_args.
* The VESA accelerant now filters the mode list to only contain modes that
are actually supported.
* Moved non-shared vesa driver data into its own file vesa_private.h.


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

* The 4-bit VGA planar mode is now advertized as B_GRAY8 to the app_server.
* The app_server now detects that this mode is being used, and at least correctly copies
the 32bit data to the first plane, meaning we have a monochrome output for now
(it crashed before, as Stefano reported).


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

Minor cleanup.


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

improved debug output


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

Made some necessary enhancements to class Screen; the app_server also
has to care about refresh rates. Also changed Screen::GetMode() (formerly
Resolution()) to return all interesting values, so that hopefully no one
will call it anymore like RootLayer::SetScreens() did.
Greatly improved the horrible RootLayer::SetScreens().
The app_server is now able to deal with failing HWInterface::SetMode() calls;
in this case, it will fall back to the hardware's current mode. This now
also works correctly in combination with the vesa driver, so that you don't
have to compile the app_server with the same resolution you boot in anymore.
SetMode() now always returns if it succeeded or not.
Renamed RootLayer::fScreenXYResolution to fScreenWidth/Height respectively.
Removed the useless DisplayDriver::DisplayMode() method.
Added B_GET_DISPLAY_MODE to the required accelerant hooks.
Some minor cleanup.


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

Added very basic VESA driver. Will be improved in the future (right now
it doesn't really do anything, it just passes the initial frame buffer
on to the app_server).
While it seems to work on real hardware (if you set the video mode to
640x480x32, app_server restriction), under Bochs, the app_server crashes.


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

Updated drivers to use BIOS module instead of vm86.

* Calmed down CID 1976; the problematic situation should not be able to occur,
but I've changed it anyway to make the code clearer.


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

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


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

Fixed complete mixup of order of arguments passed to remap_frame_buffer().
Should fix #5186.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34846 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

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 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

* Setting the depth to 1 for VGA mode in frame_buffer_console_init() was not
a good idea; it didn't have any consequences in there, but actually broke
the app_server's support for the VGA mode.
* Cleanup.


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

* Added DPMS support to the VESA driver, in case the hardware/BIOS supports it.
* Minor cleanup.


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

* On some systems, switching the resolution in VESA mode during
runtime did not work and gave a "General System Error".
Jan Kloetzke provided a temporary work around, the area
which the BIOS can access is enlarged, although according to
specs, this should not be needed.
* After switching modes in the VESA driver, turn on write
combining for the frame buffer area. This gives a huge speed
boost for all graphics drawing. Only people for which mode
changes did not work were using the full speed since the
VESA mode switching support was added.
* Cleanup in the Jamfile, some header directories were included
multiple times.


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

* The boot loader now passes on its EDID info to the kernel, and that will
be put into a boot_item in frame_buffer_console_init().
* The VESA driver now supports gettings the EDID information as well; this
is necessary now, since the app_server no longer takes over the mode the
boot loader had chosen.
* Note, we might want to do this via vm86 instead in the future, and remove
the kernel part again.


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

Patch by Jan Klötzke with minor changes by myself:
* Use vm86 mode to call the VESA BIOS to do the actual mode switching by
providing an ioctl in the vesa driver.
* Fix vm86.h.


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

* Changed get_boot_item() API: it now also can retrieve the size of the boot
item entry.
* The bios_ia32 video platform code now stores the available VESA modes in
the new vesa_modes kernel_args field.
* When configuring a VESA mode via settings file, it's no longer needed to
specify the exact mode - the closest available mode is now used. This should
help with bug #1962.
* frame_buffer_console_init() now also creates a boot_item for the VESA modes
in the kernel_args.
* The VESA accelerant now filters the mode list to only contain modes that
are actually supported.
* Moved non-shared vesa driver data into its own file vesa_private.h.


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

* The 4-bit VGA planar mode is now advertized as B_GRAY8 to the app_server.
* The app_server now detects that this mode is being used, and at least correctly copies
the 32bit data to the first plane, meaning we have a monochrome output for now
(it crashed before, as Stefano reported).


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

Minor cleanup.


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

improved debug output


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

Made some necessary enhancements to class Screen; the app_server also
has to care about refresh rates. Also changed Screen::GetMode() (formerly
Resolution()) to return all interesting values, so that hopefully no one
will call it anymore like RootLayer::SetScreens() did.
Greatly improved the horrible RootLayer::SetScreens().
The app_server is now able to deal with failing HWInterface::SetMode() calls;
in this case, it will fall back to the hardware's current mode. This now
also works correctly in combination with the vesa driver, so that you don't
have to compile the app_server with the same resolution you boot in anymore.
SetMode() now always returns if it succeeded or not.
Renamed RootLayer::fScreenXYResolution to fScreenWidth/Height respectively.
Removed the useless DisplayDriver::DisplayMode() method.
Added B_GET_DISPLAY_MODE to the required accelerant hooks.
Some minor cleanup.


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

Added very basic VESA driver. Will be improved in the future (right now
it doesn't really do anything, it just passes the initial frame buffer
on to the app_server).
While it seems to work on real hardware (if you set the video mode to
640x480x32, app_server restriction), under Bochs, the app_server crashes.


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