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: 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>

Return "Unsupported" from VESA accelerant mode setting

Currently, when trying to change settings in Screen preferences on
a system which uses VESA driver on UEFI system, the displayed error
message is "Invalid argument". This commit simply changes returned
error code to B_UNSUPPORTED, so that in the UI we show
"Operation not supported" error.

Change-Id: I2a654d6f652c7b24ecd23969e04e477456235aa0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3858
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

vesa: fix missing display_mode for UEFI.

* Broke use of non-standard modes in hrev51207. Code changed
when merging framebuffer driver back into vesa driver...

Change-Id: I688ae627de23f37ffc8614d8f189593f8833ae3e

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.

VESA: compare modes by index, instead of contents

We only compared the height, width, and depth of modes to decide if the
mode was already set. However, at boot, we may have these settings right
and other things not properly configured, preventing VESA to set a
working mode unless forced from the boot menu.

Fixes #12918

vesa: don't switch to the current mode.

* If a mode change is requested, check if it is equivalent to the
current one, and don't do anything in this case.

Dump actual mode count in vesa_accelerant_mode_count() debug output.

* vesa != intel. *cough*
* no functional change


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

* Minor cleanup.


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

Add initial vesa modes even if EDID information is present. EDID does not
include all supported video modes. Fixes #4166.

Note that this change will probably show several weird resolution is some
configurations. They are all valid resolutions but are not commom so we need
a way to filter those out.



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

* Add the width, and height to fill_display_mode(). This should help with #7751
this time.


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

Fix crash in VESA accelerant.

- Keep track of the correct number of initial modes available.



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

* Fixed coding style violation introduced with the last commit.


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

* Only add the VESA modes if there is no EDID available.


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

* The VESA accelerant now always makes sure that all supported resolutions are
added to the mode list (in 60 Hz, but that doesn't really matter).
* It does this by iterating over the modes found, and computes the
display_timings from them using the GTF code.
* This should help with one of the problems of ticket #7751.


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

* If the VESA accelerant has EDID information, it will now also pass it to
create_display_modes().


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

* 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

* Now completely initializes the current_mode if it's in the mode list.
* The mode list is now created by the common mode list creation code.
* Minor cleanup.


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

* Moved VGA planar mode blitting into the VESA kernel driver.
* In grayscale mode, the AccelerantHWInterface now sets the palette correctly.
* HWInterface now has a fVGADevice set by AccelerantHWInterface which will be used
to talk to the VESA driver.
* Completed planar blitting for all 4 planes; we now have a perfect 16 color
grayscale mode when you choose "Standard VGA mode" in the boot loader with
an unsupported graphics card (such as in Qemu).


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

Calmed down the VESA accelerant a bit.


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

Fixes that make Haiku build with gcc 4. Mainly out of the following
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.



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

vesa: don't switch to the current mode.

* If a mode change is requested, check if it is equivalent to the
current one, and don't do anything in this case.

Dump actual mode count in vesa_accelerant_mode_count() debug output.

* vesa != intel. *cough*
* no functional change


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

* Minor cleanup.


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

Add initial vesa modes even if EDID information is present. EDID does not
include all supported video modes. Fixes #4166.

Note that this change will probably show several weird resolution is some
configurations. They are all valid resolutions but are not commom so we need
a way to filter those out.



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

* Add the width, and height to fill_display_mode(). This should help with #7751
this time.


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

Fix crash in VESA accelerant.

- Keep track of the correct number of initial modes available.



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

* Fixed coding style violation introduced with the last commit.


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

* Only add the VESA modes if there is no EDID available.


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

* The VESA accelerant now always makes sure that all supported resolutions are
added to the mode list (in 60 Hz, but that doesn't really matter).
* It does this by iterating over the modes found, and computes the
display_timings from them using the GTF code.
* This should help with one of the problems of ticket #7751.


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

* If the VESA accelerant has EDID information, it will now also pass it to
create_display_modes().


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

* 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

* Now completely initializes the current_mode if it's in the mode list.
* The mode list is now created by the common mode list creation code.
* Minor cleanup.


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

* Moved VGA planar mode blitting into the VESA kernel driver.
* In grayscale mode, the AccelerantHWInterface now sets the palette correctly.
* HWInterface now has a fVGADevice set by AccelerantHWInterface which will be used
to talk to the VESA driver.
* Completed planar blitting for all 4 planes; we now have a perfect 16 color
grayscale mode when you choose "Standard VGA mode" in the boot loader with
an unsupported graphics card (such as in Qemu).


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

Calmed down the VESA accelerant a bit.


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

Fixes that make Haiku build with gcc 4. Mainly out of the following
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.



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