to be an acceptable graphic to use in the creation of third party logos and
other graphics. This will hopefully balance the need to protect the trademark
and the desire to create derivative graphics that have a strong visual
connection to the Haiku Project. The exact usage terms for these graphics are
not yet spelled out. At a minimum, the apect ratio of the leaves should be
maintained.
* Removed Big*leaf*, as the colors and shading were poorly done.
* Added HAIKU Background Leaf[ - outline], which has multiple layers.
* Added HAIKU Leaf
1: http://www.freelists.org/post/haiku/Haiku-User-Group-Logo-What-is-wanted
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37161 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Some cleanup in member sorting
* Some renaming of members for improved clarity
* Removed _HasSelection() and use fHasSelection directly
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37159 a95241bf-73f2-0310-859d-f6bbb57e9c96
ticket #1357. Added the package to the alpha-* release profile by default.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37153 a95241bf-73f2-0310-859d-f6bbb57e9c96
function generator. This build tool is needed by the
WebPositive build for example.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37151 a95241bf-73f2-0310-859d-f6bbb57e9c96
otherwise some other calculation screws up later, and the menu frame ends up
to be offsetted by its height. Fixes ticket #6159.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37149 a95241bf-73f2-0310-859d-f6bbb57e9c96
is a slight difference in BMessage storage, or there is no actual
change at all...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37147 a95241bf-73f2-0310-859d-f6bbb57e9c96
help the stack to detect and handle hotplug device removal.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37144 a95241bf-73f2-0310-859d-f6bbb57e9c96
space (missing elses). The state would never get higher than "note". There
still seems to be an issue (probably vm_kernel_address_space_left() not
returning the correct value), since even at 2021 MB (as reported by "aspaces")
the state is still only "note", while the heap grower is not able to allocate
heap areas anymore.
* "low_resource" command: The address space flag was not printed for hooks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37140 a95241bf-73f2-0310-859d-f6bbb57e9c96
used e.g. by the slab allocator. The interesting part is the address space
usage anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37139 a95241bf-73f2-0310-859d-f6bbb57e9c96
kernel private.
* Moved dumping code from dump_cache() to new VMCache::Dump().
* Override VMCache::Dump() in VMVnodeCache to also print the vnode.
* Removed no longer needed VMCache::GetLock().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37138 a95241bf-73f2-0310-859d-f6bbb57e9c96
Applied patch for #5209 by oruizdorantes for usb_asix, do the same for usb_davicom.
Will eventually rework it in order to remove duplicated IDs list.
The usb_serial driver also needs the same optimization,
but gathering the IDs list will take more time than refactor the code and since
usb_serial is not yet included in haiku image neither ready (no tty module), there is less user experience immediate gain...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37135 a95241bf-73f2-0310-859d-f6bbb57e9c96
anymore as that truncates physical addresses when PAE is enabled.
Now, if a 4 GB physical address limit is forced in DMAResource, the system
continues to work fine when the physical memory > 4 GB is used. Otherwise it
hangs or crashes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37134 a95241bf-73f2-0310-859d-f6bbb57e9c96
restrictions for virtual/physical addresses.
* vm_page_allocate_page_run():
- Fixed conversion of base/limit to array indexes. sPhysicalPageOffset was not
taken into account.
- Takes a physical_address_restrictions instead of base/limit and also
supports alignment and boundary restrictions, now.
* map_backing_store(), VM[User,Kernel]AddressSpace::InsertArea()/
ReserveAddressRange() take a virtual_address_restrictions parameter, now. They
also support an alignment independent from the range size.
* create_area_etc(), vm_create_anonymous_area(): Take
{virtual,physical}_address_restrictions parameters, now.
* Removed no longer needed B_PHYSICAL_BASE_ADDRESS.
* DMAResources:
- Fixed potential overflows of uint32 when initializing from device node
attributes.
- Fixed bounce buffer creation TODOs: By using create_area_etc() with the
new restrictions parameters we can directly support physical high address,
boundary, and alignment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37131 a95241bf-73f2-0310-859d-f6bbb57e9c96
which caused the upper 32 bit of the address to be ignored, thus mapping to
the wrong page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37130 a95241bf-73f2-0310-859d-f6bbb57e9c96
uint64, since that's the width of the page table entry. Was harmless, though,
since the flags are in the lower 32 bits anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37129 a95241bf-73f2-0310-859d-f6bbb57e9c96
in r37117 as well, which was really the main point of introducing it.
Improves #6124 (reported memory lower than installed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37127 a95241bf-73f2-0310-859d-f6bbb57e9c96
patch by Ziusudra.
* Use new(std::nothrow) instead of new.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37126 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't define status in CopyToClipboard() before it's actually used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37124 a95241bf-73f2-0310-859d-f6bbb57e9c96
* try to launch screen_blanker by path when a launch by signature fails.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37120 a95241bf-73f2-0310-859d-f6bbb57e9c96
comments in the code, different programs do it differently. However, I
believe we should follow the BeBook documentation. This is the method which
WonderBrush uses as well, and that one had been tested with other apps like
Refraction. Potentially, copy&paste could work across GoBe Productive now
also, but I didn't test.
* Handle the case where the selection bitmap that gets restored from the
clipboard has a bounds rectangle with an offset. Use this offset as an
alternative to the "be:location" hack.
* Fix the drag bitmap to be semi-transparent on Haiku. B_OP_SELECT does not
affect the alpha channel on Haiku like it apparently did on BeOS, though
I am not inclined to change that behavior.
* Fixed some coding style violations, but tried to mix as little cleanup as
possible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37118 a95241bf-73f2-0310-859d-f6bbb57e9c96
* try at support realtek alc888. alsa uses this init sequence.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37113 a95241bf-73f2-0310-859d-f6bbb57e9c96
