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
Wrote a jamfile and did some build fix (but doesn't build yet).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37109 a95241bf-73f2-0310-859d-f6bbb57e9c96
Kernel doesn't use it, and it could be regenerated in the kernel if it did need it.
This also unlocks the apic range the bios can use. Previously the apic ids would have
to fit within 0..MAX_CPUS or it'd reject the cpu. Some boxes (mine in particular)
seem to sparsely populate the apic id so that the range is pretty large.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37108 a95241bf-73f2-0310-859d-f6bbb57e9c96
phys_addr_t. IOW, if PAE is enabled, that memory should be put to use now.
Apparently we report an incorrect amount of total memory (also counting
memory gaps), which also suggests that we need another method to manage the
vm_page structures (currently a huge array with indexes proportional to
physical page addresses, i.e. wasting memory for the gaps).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37107 a95241bf-73f2-0310-859d-f6bbb57e9c96
need a spinlock per CPU; a single variable suffices.
* Extended call_all_cpus[_sync]() to work before smp_wake_up_non_boot_cpus()
(even before smp_init()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37105 a95241bf-73f2-0310-859d-f6bbb57e9c96
work-arounds, I applied the work-around where the problem actually occurs,
until someone takes the time to look into it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37095 a95241bf-73f2-0310-859d-f6bbb57e9c96
maps. Now we can at least fully boot in qemu with one CPU. A few things
still need to be implemented, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37090 a95241bf-73f2-0310-859d-f6bbb57e9c96
page with a 32 bit physical address (needed for the PDPTs). A small set of
free pages is cached, so the rather expensive vm_page_allocate_page_run() can
be avoided most of the time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37088 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_FILTER_BITMAP_BILINEAR to DrawBitmap(). There is virtually no delay at all.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37080 a95241bf-73f2-0310-859d-f6bbb57e9c96
