send_bit() causes a type conversion from the value handed in to 0 or 1. This
clashed with the usage in send_byte(), that hands over a shifted byte. The
argument was converted to true when it had any value other than 0, whereas
before (where a bool simply was an int) it would have just handed over the value
directly. Therefore the logic in send_bit() that simply masked off the lowest
bit of the value would now not work anymore.
This fixes EDID failing on GCC4 and therefore fixes#2275, the last issue of
#4084 and may also affect #2780.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32593 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server without having a card that actually supports this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32457 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
1680x1050 with 16 bit on i865+ (still need to check the restrictions of
older chips).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31277 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Replaced all occurences with the standard macros M_PI, and M_PI_2.
* Some coding style cleanup on the touched files, no other changes besides
adding a missing check for a failed memory allocation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31250 a95241bf-73f2-0310-859d-f6bbb57e9c96
BTW, changing cursor shape when he's invisible will show it immediatly
right now. Sounds like wrong...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28978 a95241bf-73f2-0310-859d-f6bbb57e9c96
tigerdog; let's see how many complaints we get this time :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28913 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix for a problem of the ProSavage chip when VESA ran 32 bit before.
* Better error codes in SetDisplayMode().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28816 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The hardware cursor is now disabled at 640x480 with a Virge VX (before it
was just invisible).
* EDID info can now be read for all S3 chips.
* For the Savage IX, Savage MX, and SuperSavage chips the display is no
longer expanded to fill a laptop LCD display when the mode resolution is
less than the size of LCD display.
* Savage IX, Savage MX, and SuperSavage chips will now display mode
1400x1050 on a 1400x1050 laptop LCD display. Previously the display was
blank at that resolution.
* Previously about half the Savage chips would not draw properly at
1400x1050. That is, the image was badly skewed and unusable. All of
them now draw properly at 1400x1050.
* Some code was reorganized to remove unnecessary and redundant code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27863 a95241bf-73f2-0310-859d-f6bbb57e9c96
target when I checked it. Move the target display_mode declaration back above
the check but remove the dereferencing assignment. If proposing the display
mode succeeds it also initializes target. Thanks luroh for noticing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27492 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Disabled "timing.sync != 3" check that potentially ignores modes that we might
want to have. We could also add the mode by resolution in that case, and
ignore the timing info completely. There should be an open bug about this,
but I couldn't find it.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26762 a95241bf-73f2-0310-859d-f6bbb57e9c96
parameters. This caused ticket #1732 for me. At another place in the code,
the native resolution is added to the supported mode list and there it is
hardcoded to the first flatpanel info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26540 a95241bf-73f2-0310-859d-f6bbb57e9c96
Either of the two should work when the native resolution is 1368x768.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26539 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
* 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
Gerald Zajac. Thanks a lot!
* Also put it on the image by default.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25583 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled testing the checksum of the EDID info.
* Added a version check of the EDID info.
* Added more debug output.
* In the ModeList class, changes were made to how the refresh rate is
computed and used. Previously, some of the basic VESA modes were not
added to the mode list because the computed and specified refresh rates
did not exactly match. Now if the computed refresh rate is within 1.2%
of the specified rate, the mode is added. With this change, all basic
VESA modes selected by the EDID info are now added to the mode list.
* The "additional video modes" shown in the EDID dump are now added to
the mode list. Previously, this mode data was setup but not added to
the mode list. Code was also added here to set the vertical &
horizontal sync polarity according the EDID info. The sync polarities
are set according to a VESA document that I have.
* Fixed copy_str() warning, broken removal of trailing spaces, and null
termination.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24959 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
* Adds mode 1152x864 @60 Hz
* Adds mode 1400x1050 @75 Hz
* Adds a blank line between each of the different resolutions to make
the list more readable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24638 a95241bf-73f2-0310-859d-f6bbb57e9c96
these days, so having a not so crowded resolution menu is not really a good argument
for making the driver unusable for the majority of potential users.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24241 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
we now always only use the primary ring buffer.
* Removed secondary ring buffer allocation and member fields.
* Increased size of the primary ring buffer to 65536 bytes.
* The bytes per row register is computed differently for 9xx chips.
* On G33, the overlay does not need a physical address anymore, so we
don't pass B_APERTURE_NEED_PHYSICAL to the allocation anymore for that
device.
* intel_free_memory() accidently added the aperture base to the allocation
and would therefore never free any memory.
* INTEL_RING_BUFFER_SIZE_MASK was shifted one bit to the right, didn't
cause any harm with our buffer sizes, yet, though.
* With these changes, the driver runs stable on a G33 chipset (I have not
yet tested the hardware cursor, though, it might need some work, too).
The only known issue left is that overlay flickers a bit if its buffer
is partially backed up by reserved and allocated memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23798 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Now uses the AGP GART module for memory management. This greatly simplifies
the memory handling, and memory is now actually allocated on demand,
instead of a fixed size (stolen memory is not freed, though).
* The Intel GART module should now also work with older chipsets.
* No longer remove the GTT size from the stolen memory; this appears to have
been a mistake in the X driver. Not sure about the BIOS popup yet.
* The AGP module (in combination with the Intel GART module) is now mandatory
to use the Intel driver.
* Removed now superfluous settings (like memory size). Only enabling/disabling
the hardware cursor is still supported.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23781 a95241bf-73f2-0310-859d-f6bbb57e9c96
