fill_page_table_entry() by a ptesync(). Mapping the kernel heap
took about 2 minutes here before.
* Added missing shift of the asid_base in ppc_translation_map_change_asid().
* Commented out the BAT stuff in arch_vm_translation_map_init_post_area().
Besides that I think it won't work that way, it made the page table
unaccessible; though I'm not sure why.
* Added a bit of documentation to the beginning of the file. Should give
enough information to understand what happens here without further
detailed knowledge about the architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15769 a95241bf-73f2-0310-859d-f6bbb57e9c96
BeMail uses 2, Terminal (under Dano) 4, and Tracker as well as pe 3 - so 3 seems
to be a good compromise.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15763 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added another optimized bitmap drawing routine
for B_OP_ALPHA and BGR[A]32 bitmaps. When actual
blending takes place, it is more than 1.7 times
faster than R5, and about the same speed when
the bitmap is fully opaque.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15761 a95241bf-73f2-0310-859d-f6bbb57e9c96
arch_mmu_allocate() to set the "cache inhibited" flag. One negative
effect was that for such memory the lwarx instruction (used by the
atomic_*() functions) does "... cause the system data storage error
handle to be invoked...", as the architecture specification puts it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15759 a95241bf-73f2-0310-859d-f6bbb57e9c96
with quite good results I might add. Drawing B_RGB32
bitmaps is more than 1.2 times faster than on R5, while
B_CMAP8 bitmaps are slightly slower. The optimization
is only for B_OP_COPY and unscaled bitmaps
(B_RGB32 and B_CMAP8). Drawing only parts of the bitmap
is supported. Adding optimization for scaled bitmaps
should be beneficial, since the generic version is 2 two
4 times slower. I think it gets even worse for partial
bitmaps.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15758 a95241bf-73f2-0310-859d-f6bbb57e9c96
{HAIKU,HOST,TARGET}_KERNEL_PIC_{CC,LINK}FLAGS which define the
compiler/linker flags specifying the kind of position independence
the kernel shall have. For x86 we had and still have -fno-pic, but the
PPC kernel has -fPIE (position independent executable) now, as we
need to relocate it.
* The boot loader relocates the kernel now. Mostly copied the relocation
code from the kernel ELF loader. Almost completely rewrote the PPC
specific relocation code, though. It's more correct and more complete now
(some things are still missing though).
* Added boot platform awareness to the kernel. Moved the generic
Open Firmware code (openfirmware.c/h) from the boot loader to the kernel.
* The kernel PPC serial debug output is sent to the console for the time
being.
* The PPC boot loader counts the CPUs now and allocates the kernel stacks
(made OF device iteration a bit more flexible on the way -- the search
can be restricted to subtree). Furthermore we really enter the kernel...
(Yay! :-) ... and crash in the first dprintf() (in the atomic_set()
called by acquire_spinlock()). kprintf() works, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15756 a95241bf-73f2-0310-859d-f6bbb57e9c96
probably increase the values we got from BScrollBar::GetSteps(), though, as
it's a bit slow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15755 a95241bf-73f2-0310-859d-f6bbb57e9c96
with the "EventMask" test app the last time:
* The focus view didn't get any mouse messages anymore if there was a permanent
B_POINTER_EVENTS view.
* B_KEYBOARD_EVENTS now works again.
* B_MOUSE_WHEEL_CHANGED messages no do arrive their targets without prior
keyboard input.
* Added TODO item that other focus messages don't go through to the app without
keyboard input (fix only works for B_MOUSE_WHEEL_CHANGED).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15754 a95241bf-73f2-0310-859d-f6bbb57e9c96
wider, so that they completely fill up the space they have (making them nicely
aligned to the surrounding border).
* the placement controls now accept up to 5 bytes (for things like "-1000").
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15751 a95241bf-73f2-0310-859d-f6bbb57e9c96
as cached_block::data - which led to a crash as block_cache::FreeBlock() tried to
free both later.
Since neither cached_block::parent_data nor cached_block::original are supposed
to be != NULL in block_cache::FreeBlock(), they are no longer freed, but the system
panics if one of them is not NULL.
This should fix bug #77.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15749 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The left and right box should now always look aligned horizontally
(at least under Haiku).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15748 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Less flickering when drawing the label: the area of the label is now
clipped, so there is no need to fill the background again.
* Consumed the last reserved member for the bounding box of the label.
* More or less rewrote the header.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15747 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Better error reporting when writing the attributes.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15744 a95241bf-73f2-0310-859d-f6bbb57e9c96
preferences app writes its info with this type (instead of B_MESSAGE_TYPE as
Be's does).
It's now possible to set the background image for Tracker under Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15742 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Now always returns B_BAD_DATA in case of attributes with the wrong size.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15741 a95241bf-73f2-0310-859d-f6bbb57e9c96
attribute is longer than B_MIME_TYPE_LENGTH.
* NodeInfo::GetType() now null terminates the attribute; you cannot expect
that strings in attributes are null terminated (it already wrote the null
byte to B_MIME_TYPE_LENGTH - 1 for safety, but why not do it right?).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15740 a95241bf-73f2-0310-859d-f6bbb57e9c96
when receiving a HELLO request. Thus it doesn't need to be restarted
when the image had been rebuilt. That was a bit annoying...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15735 a95241bf-73f2-0310-859d-f6bbb57e9c96
panel window (and thus the text is no longer cut off under Haiku).
Instead of only writing "JPEG Image" for JPEG images, and nothing for
all other image types, the MIME types short description is now displayed
(or the MIME type itself if no such description exists).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15733 a95241bf-73f2-0310-859d-f6bbb57e9c96
reported from our build tools under Linux. As it seems Linux does not
translate dirent::d_ino for mount points (BeOS and Haiku do), which
caused us not to find a mount point entry in its parent directory.
Thanks to Vampyre for the hint.
Fixes bugs #73 and #76.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15726 a95241bf-73f2-0310-859d-f6bbb57e9c96
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15723 a95241bf-73f2-0310-859d-f6bbb57e9c96
or even the resizing mode isn't done yet, though. See TODOs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15720 a95241bf-73f2-0310-859d-f6bbb57e9c96
as only the BitmapManager class is allowed to call them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15718 a95241bf-73f2-0310-859d-f6bbb57e9c96
* if file panels shouldn't be quit, we no longer call QuitRequested() for
them and stop quitting windows (which left normal windows open, because
file panels always return "false" in QuitRequested())
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15715 a95241bf-73f2-0310-859d-f6bbb57e9c96
and ResizeBy()
* WindowLayer::SetSizeLimits() needs to be called with the
AllWindows lock held
* I was observing weird behaviour with "unclickable" windows
that I might have fixed by explicitly excluding invisible
windows from Desktop::WindowAt(), there might be something
wrong with the "current" window list though, Axel would know
* finally found the problem with "delayed background clearing"
* enabled delayed background clearing and removed unnecessary
code. It should be more efficient, since it clears larger
areas at once, and it solves the problem of views unable to
draw into regions that are pending for another update - among
other things, updates in resizing windows are more fluent,
especially for B_FULL_UPDATE_ON_RESIZE views. "Cut off" scroll
bars should no longer appear when the view being scrolled takes
too long to redraw.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15714 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved ImageFilePanel code to its own file, so that it can be reused easily.
* Moved BGWindow stuff into Backgrounds.cpp.
* Cleanup to match our style guide better.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15712 a95241bf-73f2-0310-859d-f6bbb57e9c96
I wouldn't be surprised, if more wrappers are still missing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15709 a95241bf-73f2-0310-859d-f6bbb57e9c96
specifying whether only the exact supplied address is acceptable. If
false, the address is considered a hint only. It will be picked, if
available, otherwise a greater address is tried to be acquired, and
as last resort any address. This feature is only implemented for PPC.
It is needed since the preferred kernel text base address 0x80000000
might not be available (and actually isn't on my Mac mini).
* Fixed a bug in the PPC memory management code:
is_{virtual,physical}_allocated() were checking whether the given
range was completely contained by an existing range instead of
checking for intersection. As a consequence we could (and did) allocate
a range intersecting with already allocated ranges. The kernel segment
thus overwrote OF memory for instance.
* The ELF loader makes sure that it got both text and data segment of
the image to be loaded.
The PPC boot loader successfully loads kernel and modules now. Next
comes the hard part, I'm afraid.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15708 a95241bf-73f2-0310-859d-f6bbb57e9c96
platform_allocation_region(). Since the callback stuff doesn't seem to
work, the Open Firmware didn't ask us to allocate memory in turn, and
thus we didn't know about the range that had been mapped and reused it
later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15699 a95241bf-73f2-0310-859d-f6bbb57e9c96
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
B_ALPHA_OVERLAY alha function (blending on top of
a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
FillRect() in Painter
* used the "packed" version of scanlines for shapes with
an outline thicker than 4 pixels (and filled shapes anyways),
this improves drawing speed when there are a few anti-aliased
pixels at the beginning of a scanline, then a solid fill and
some anti-aliased pixels at the end of the scanline. Such as
large letters.
To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15698 a95241bf-73f2-0310-859d-f6bbb57e9c96
and thus, it could be used again which led to a crash.
Changed the free ranges list from a singly linked list to a doubly linked
list so that not all free ranges have to be searched for the one to be
freed anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15696 a95241bf-73f2-0310-859d-f6bbb57e9c96
the modified bit set were written back (that's the case when they weren't put into
the modified pages queue yet), they were enqueued into the active queue twice, messing
up the page lists with various effects - this little thing took me busy for the last
few days :-/
* Improved the "page" debugger command: it now prints out much more info, and also lets
you lookup pages via physical address.
* The dump commands are now using kprintf() instead of dprintf().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15692 a95241bf-73f2-0310-859d-f6bbb57e9c96
IP, and UDP, as well as a home brewn UDP based protocol, "remote disk",
which provides random access to a single remote file/device. The Open
Firmware flavored boot loader automatically initializes the net stack,
searches for a remote disk, and tries to boot from it, if the boot
device is a network device (e.g. when loading the boot loader via
TFTP).
This is quite nice for developing with a two-machine setup, since one
doesn't even need to install Haiku on the test machine anymore, but can
serve it directly from the development machine. When the networking
support in the kernel is working, this method could even be used to
fully boot, not just for loading kernel and initial modules.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15689 a95241bf-73f2-0310-859d-f6bbb57e9c96
argument value of 0 should only free the old allocation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15688 a95241bf-73f2-0310-859d-f6bbb57e9c96
* bfs_inode must be packed, otherwise the structure is larger due to
different alignment requirements.
* The off_t array returned by bfs_inode::Values() is in on-disk
endianess. This was ignored in some places. Hope I squashed all
occurences.
Those fixes should probably be back-ported to the kernel add-on, too.
Will do that when I get to that point in the kernel, unless someone
beats me to it.
The PPC boot loader does at least find the kernel on a BFS volume now.
Haven't dared to let it be loaded yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15686 a95241bf-73f2-0310-859d-f6bbb57e9c96
arch_cpu_user_TLB_invalidate(). Empty at the moment; will have a look at
that later. The PPC kernel builds again, now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15685 a95241bf-73f2-0310-859d-f6bbb57e9c96
of_call_method() which is actually an implementation of the
"call-method" client function.
* of_interpret() announced one less return value than actually needed.
Seemed to work anyway, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15683 a95241bf-73f2-0310-859d-f6bbb57e9c96
also added a few comments explaining what's going on. Japanese not updated?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15667 a95241bf-73f2-0310-859d-f6bbb57e9c96
