also renamed their accelerants and settings files accordingly.
* Added Mandelbrot and GLDirectMode as demo applications.
* Moved CortexAddOnHost to /bin.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21010 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use AGP Bus manager module
* Fixed wrong framebuffer address computation; this should fix bug #1079.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20336 a95241bf-73f2-0310-859d-f6bbb57e9c96
Monitor Routing rework
* mostly to fix my issues with dual monitors VGA + DVI which didn't work! ;)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20275 a95241bf-73f2-0310-859d-f6bbb57e9c96
* New "ATOM" BIOS Support for radeons X-series
* This also removes scanning for the BIOS signature for other cards
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20272 a95241bf-73f2-0310-859d-f6bbb57e9c96
Made the following changes from the version I got from Eric:
* made BppForSpace() in DriverInterface.h inline to remove some warnings
* renamed driver source files to lower case.
* removed Be Inc. copyright from kernel driver as I couldn't see anything coming
from Be Inc. there - correct me if I was wrong, Eric.
* Minor other changes like added missing header guards.
* The README provided in the main directory is only included in the accelerant
directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19793 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
- Corrected wrong ID association (0x4e50 is M11-based, not M10-based).
- Implemented fixed dividers support for laptop panel refresh rate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19209 a95241bf-73f2-0310-859d-f6bbb57e9c96
under Haiku, though. If someone has access to this card, feel free to fix this :-)
I renamed the driver to s3savage (from BeSavage), and added the license text
separately (dunno if that's really needed, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18978 a95241bf-73f2-0310-859d-f6bbb57e9c96
to take that into account.
* Introduced INTEL_TYPE_FAMILY_MASK and INTEL_TYPE_GROUP_MASK to better
differentiate the device type.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18293 a95241bf-73f2-0310-859d-f6bbb57e9c96
export those functions. The log_coll stuff now uses system_time() instead
if enabled - that should be good enough.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17567 a95241bf-73f2-0310-859d-f6bbb57e9c96
output as well.
* Obviously got the register for INTEL_DISPLAY_B_DIGITAL_PORT wrong - it's
not 0x61000 but 0x61140, maybe that can explain the fun we had at BeGeistert :)
* Renamed the analog display registers to better fit the digital ones, ie.
replaced DISPLAY with DISPLAY_A - although this might be not really correct
as it seems that the pipes can be selected arbitrarily.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17566 a95241bf-73f2-0310-859d-f6bbb57e9c96
Need to clean this up, though. It even sort of worked on tic's IBM X40
on BeGeistert - if you weren't irritated by the fact some parts of the
screen were just black, that is :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17565 a95241bf-73f2-0310-859d-f6bbb57e9c96
that at least 8 bit modes seems to work (but overlay only partially)
* Added "hardware_cursor" option to the settings file - when set to "false", you should
have a cursor in the second output now as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17498 a95241bf-73f2-0310-859d-f6bbb57e9c96
without having a VESA mode set first (thanks to Stephan for noticing
this).
* intel_set_display_mode() now calls intel_propose_display_mode() to make
sure the mode passed in is valid. Note, B_PROPOSE_DISPLAY_MODE is still
not working correctly (which will cause problems for BWindowScreen and
friends).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17460 a95241bf-73f2-0310-859d-f6bbb57e9c96
introduced a lock that is used in B_SET_DISPLAY_MODE etc.
* Correctly implemented B_ACQUIRE_ENGINE and B_RELEASE_ENGINE now (ie. they lock
the engine now).
* The lock of the ring buffers is now deleted when the (primary) accelerant is closed.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17453 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Turns out cursor handling is simpler as originally thought, so I could remove its
physical mapping - it's still put into the shared area, though, although that isn't
needed for this chip (but could eventually simplify the handling of other generations
of this chip).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17450 a95241bf-73f2-0310-859d-f6bbb57e9c96
(in the kernel driver) fail - or crash the system.
* Waiting for VBLANK now works as expected - you actually have to *set* the bit
to clear it, isn't that obvious? :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17443 a95241bf-73f2-0310-859d-f6bbb57e9c96
is no good (or reliable) way to retrieve the physical address of "stolen"
(by the BIOS) graphics memory.
* Implemented allocation of additional graphics memory in case the BIOS was
a bit too cheap. We now guarantee 8 MB of memory available to the graphics
chip - would be nicer to only allocate that on demand, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17433 a95241bf-73f2-0310-859d-f6bbb57e9c96
I am also not sure if it's working correctly.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17425 a95241bf-73f2-0310-859d-f6bbb57e9c96
use it (which isn't really that bad).
* B_SCREEN_TO_SCREEN_BLIT is now working as intended, so we can finally move
windows and scroll at decent speed :-)
* Implemented a simple version of B_WAIT_ENGINE_IDLE for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17422 a95241bf-73f2-0310-859d-f6bbb57e9c96
the usual order of other registers, so I mixed it up: vertical downscaling
is now working as expected as well.
* The downscaling factor was a tiny bit too low (one pixel from the view).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17414 a95241bf-73f2-0310-859d-f6bbb57e9c96
used, though.
* Renamed the PhyisicalPageMapper class to AreaKeeper and made it a bit more
generic (ie. it can now also create usual areas)
* The shared_info is now created using the AreaKeeper, too, and this actually
fixes some potential memory leaks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17412 a95241bf-73f2-0310-859d-f6bbb57e9c96
overlay - this will improve the overlay performance when the engine is
under load (the acceleration engine will use the primary lower priority
ring buffer).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17411 a95241bf-73f2-0310-859d-f6bbb57e9c96
mode), but you have to set the scaling UV registers in order to have correct
overlay.
* In other words, overlay is working now! There are still issues with it, which
can probably be attributed to missing bounds checks (the screen goes black
when you leave full-screen mode in VLC - but not if overlay just stops).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17365 a95241bf-73f2-0310-859d-f6bbb57e9c96
the Intel chip obviously cannot do overlays in B_RGB16 - even though it pretends
to be able to do that.
* B_YCbCr422 seems to work, though, I haven't tested any other spaces for now, and
I somewhat doubt they will work. It's all green, though, and the scaling doesn't
seem to be correct - that we be solvable, though :)
* There aren't any bounds checks (so don't move the window out of the screen), and
also the overlay_view offsets are ignored.
* Scaling and moving is now detected, and there is always as little work done as
possible to reduce the workload on buffer switches (the most common case).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17315 a95241bf-73f2-0310-859d-f6bbb57e9c96
lsb to msb).
* The result is that there is now *something* to see when overlay is turned on. In
fact the whole screen goes dark besides a few pixels on the top - now isn't that
something? :-)
* The overlay is also turned off again correctly - which also revealed a bug in our
app_server: B_CONFIGURE_OVERLAY is not always called with window=NULL/view=NULL
to turn off overlay (might be an incorrect handling of BView::ClearOverlay()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17300 a95241bf-73f2-0310-859d-f6bbb57e9c96
small) up for this specific task - this will later be used for the acceleration
engine as well.
Some more work on overlay initialization, doesn't do anything yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17254 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The overlay register update buffer is now created and exported, ready
to be used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17244 a95241bf-73f2-0310-859d-f6bbb57e9c96
of graphics memory is now possible.
* Changed driver name to start with "intel_extreme" to have a nicer device
name.
* Renamed frame_buffer* stuff to graphics_memory* as the frame buffer just
happens to be located somewhere in the graphics memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17224 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The functions now check the acquire_sem() result.
* mem_freetag() will return an status code now, too.
* Moved the mem_block and mem_info definitions into the source file; no
reason to have them public.
* You can now give the memory manager a name which it will use for its
heap area and lock.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17221 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Some preparations to support more than one chipset, added i855G (device ID 0x3582)
to test with - the accelerant_device_info is now filled with that additional data
as well.
* Some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16982 a95241bf-73f2-0310-859d-f6bbb57e9c96
Only mode switches do work, doesn't yet make sure the mode is valid, though.
At this point, this driver only works on Haiku, the R5 app_server is crashing for some
reason I need to investigate some day (maybe tomorrow :)).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16872 a95241bf-73f2-0310-859d-f6bbb57e9c96
and not to delete it.
* The header didn't include everything it needed.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16702 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
