HaikuBuildCompatibility.h; this fixes building agp_gart and the intel
extreme driver for BeOS.
* Added sockaddr_storage to HaikuBuildCompatibility.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23823 a95241bf-73f2-0310-859d-f6bbb57e9c96
for reading my commit and noticing! :-)
Using the test application I could have found that bug; that codepath is
currently not used in Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23801 a95241bf-73f2-0310-859d-f6bbb57e9c96
the GTT is not part of the stolen memory. However, the BIOS popup seems
to be - removing that page solves the flickering overlay when its buffer
contained it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23799 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
memory (so no memory was ever bound in that case).
* Disabled debug output in the Intel GART module.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23797 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed "physical" parameter of GART's bind_aperture() - I don't think this
be of use to anyone.
* Fixed binding/unbinding pages in the Intel GART driver; I accidently shifted
the page offset twice.
* Actually forgot handling of allocated memory in Aperture::BindMemory().
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23796 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The kernel now opens up to 8 debugger modules (and puts them into an array;
maybe we'll want to switch to a doubly linked list when there is the need).
* Implemented an example debugger module that prints a stack trace of the
current thread when the kernel debugger is entered (not included in the
image).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23794 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
also used in BindMemory() and UnbindMemory() - before the latter two were
just not working correctly for memory in the reserved region.
* The Aperture destructor now also frees (and unbinds) all still existing
allocations.
* Aperture::fFirstMemory was not initialized.
* Added some more debug output.
* BindMemory()'s vertical to physical address translation didn't work correctly.
* alignment must be at least B_PAGE_SIZE in _Insert().
* bind_aperture() needs to pass the B_APERTURE_NON_RESERVED flag to
CreateMemory().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23774 a95241bf-73f2-0310-859d-f6bbb57e9c96
(I guess frenchies are guilty here, as mmu_man's ThemeAddOn have the same disease...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23757 a95241bf-73f2-0310-859d-f6bbb57e9c96
* It now also serves as a generic GART manager and accepts bus modules as well
as custom modules of graphics drivers if they want to (could be used for the
Radeon PCI GART stuff, for example).
* Implemented GART support module for Intel i965 and G33 chipsets (the other
Intel chips will come later).
* Renamed agp bus manager to agp_gart to reflect its new functionality (even
though the AGP functionality is already outdated (due to PCIe), the GART
stuff remains current).
* Adapted existing users of the AGP bus manager to the API changes.
* Not very well tested yet...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23754 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added some defines needed when playing with the bridge controller.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23753 a95241bf-73f2-0310-859d-f6bbb57e9c96
OS-owned bit. Otherwise we overwrite exactly the bit we later have to wait for.
Could theoretically help on legacy support issues, but I doubt it since most
hardware probably does not even use EHCI legacy support as it's normally not
needed to support full/low-speed input devices.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23747 a95241bf-73f2-0310-859d-f6bbb57e9c96
useful soon so that you can actually do something after entering KDL.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23742 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented _RemoveTransferFromEndpoint
* Reworked _AppendChainDescriptorsToEndpoint as now every endpoint has (must have) a dummy descriptor
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23741 a95241bf-73f2-0310-859d-f6bbb57e9c96
pointer (as needed by the G33 chipset).
* Minor debug output improvements.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23739 a95241bf-73f2-0310-859d-f6bbb57e9c96
controller ownership in EHCI to aid debugging USB legacy support issues.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23735 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed _SubmitControlRequest in order to use _AppendChainDescriptorsToEndpoint
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23734 a95241bf-73f2-0310-859d-f6bbb57e9c96
Notify the finisher thread after canceling transfers. It was possible that freeing the allocated
transfer resources would be delayed unnecessarily until some other transfer completed and woke up
the finisher thread. Found by Salvatore Benedetto, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23714 a95241bf-73f2-0310-859d-f6bbb57e9c96
transfer resources would be delayed unnecessarily until some other transfer completed and woke up
the finisher thread. Found by Salvatore Benedetto, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23713 a95241bf-73f2-0310-859d-f6bbb57e9c96
* set_gtt_entry() used the wrong index to fill the GTT - this could have never
worked correctly when you specified more memory than the amount of stolen
memory.
* Implementing maintaining resources for emulating overlay using the 3D engine
on i965. I don't yet commit the actual overlay code, as that is a) ugly, and
b) does not work yet.
* Moved AreaKeeper into its own header.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23709 a95241bf-73f2-0310-859d-f6bbb57e9c96
* renamed trasfer_data memeber top to first_descriptor
* added data_descriptor member to transfer_data (useful for control transfer)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23702 a95241bf-73f2-0310-859d-f6bbb57e9c96
so in the first place)
* Renamed local variable descriptor to current in the finisher thread
* Using next_done_descriptor instead of next_logical_descriptor, as the latest
is used to keep track of all descriptors that belongs to the transfer
* Added _UnlinkTransfer private method
* Implemented _FreeDescriptorChain
* Moved endpoint pointer from the ohci_general_td structur to the transfer_data_s
structure, ad the ohci_general_td has already a transfer_data_s pointer which can
be used to the endpoint pointer reducing ridundancy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23701 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the structure of the add-on was originally designed to handle all kinds of
different input devices, but has been limited to handle Wacom tablets for
now, since our mouse add-on handles the rest already.
* various Wacom Tablets are supported including Cintiq Partner, Graphire,
Graphire2/3/4, Intuos, Intous2/3, PenStation, PenPartner and Volito
TODO: Currently, the add-on does not work for some reason, though the kernel
driver publishes a devfs entry and the input_server picks it up, the Wacom
device thread is running. Need to investigate...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23667 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the driver should be generic for all Wacom tablets, but there is a
special control transfer to put the devices in to "absolute mode", it
may not work with future tablets. The driver allows to use read devices,
for which there is a special protocol. If the read request has a certain
size, then the driver will transmit info on the device, like the vendor
and product id as well as the max the packet size, for reads larger than
that, it will issue an interrupt transfer and put the raw data received
from the device behind the info header
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23666 a95241bf-73f2-0310-859d-f6bbb57e9c96
also move the thread ID from AbstractTraceEntry to TraceEntry).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23657 a95241bf-73f2-0310-859d-f6bbb57e9c96
parent node could temporarily get invalid (ie. CheckNode() would
fail).
* Since shrinking the stream was done in edge cases only, anyway, we
will no longer do that which works around the problem. This fixes
bug #1716.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23656 a95241bf-73f2-0310-859d-f6bbb57e9c96
dump a B+tree header resp. node.
* Use dprintf() when a transaction is too large instead of a panic; even
though the file system has to revert the transaction, it's not lethal,
and it does not corrupt your disk.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23653 a95241bf-73f2-0310-859d-f6bbb57e9c96
new size fell on a block boundary.
* Removed newline from Inode::Remove() tracing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23652 a95241bf-73f2-0310-859d-f6bbb57e9c96
caused old entries (that were part of the same transaction) to be
overwritten.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23642 a95241bf-73f2-0310-859d-f6bbb57e9c96
code:
- The vec array to contain the block list and the index block was one entry
to small.
- But that didn't really matter, as RunArrays/run_array was broken and never
put anything into the log; we only ever wrote index headers. BFS would
totally screw up the disk when trying to replay the log (even though the
replay code itself was and is working fine).
- If a log entry ended at the end of the log area, BFS could overwrite the
first block after the log with the next entry.
* run_array now adopt the sorting stuff from the sorted_array. Blocks in the
log are now always sorted.
* Added TODO item to sorted_array as it's not endian safe (will only work
correctly when BFS is used in the native endian).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23638 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored everything to C++ with the different devices as subclasses
* Added proper ACM detection with parsing of the ACM descriptors
* Added device transfer error handling and fixed some concurency issues
* Big cleanup to conform to our style guide
This should make at least ACM stable to use. Commiting this over my K850i with
ACM compliant USB modem and UMTS data connection. Note that support for all
other device classes (Prolific, FTDI and KLSI) is untested but should work the
same as before. Note also that since we currently lack a TTY module this will
only build/work for R5 or Dano with the proper TTY headers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23634 a95241bf-73f2-0310-859d-f6bbb57e9c96
blocks into the new transaction, but it would set that transaction on all
blocks of the old transaction, too. Also, it did not correctly update the
num_blocks/sub_num_blocks fields of the old transaction. Even worse, it did
return B_OK instead of the ID of the new transaction...
* get_writable_cached_block() did not correctly maintain the number of blocks
in the sub transaction.
* write_cached_block() did not free the original_data of a block when it wrote
it back as part of a previous transaction.
* Changed "cookie" for cache_next_block_in_transaction() to "long", so it will
be 64 bits when needed.
* Improved the API for detaching sub transactions: you can now get the blocks
of only the main (parent) transaction as well, added new
cache_block_in_main_transaction() function.
* BFS now flushes the log when there is no space left for the current
transaction.
* _WriteTransactionToLog() allocated a "vecs" array, but never freed it.
* _WriteTransactionToLog() now also supports detaching the current sub
transaction if the whole thing is getting too large (it will now also panic
if that doesn't work out).
* Removed a useless optimization: making the blocks available in the cache
isn't really needed, as all blocks in a transaction are locked into the
cache, anyway.
* Implemented Transaction::WriteBlocks().
* Minor cleanup, removed some dead code, fixed warnings in the fs_shell's
block_cache when compiled with debug output on.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23610 a95241bf-73f2-0310-859d-f6bbb57e9c96
