* As suggested by Korli, the signal is now encoded in the "reason" field of
wait_for_child().
* waitpid() now sets the status passed in so that the signal can be read out
(but it still doesn't do it's full job).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17338 a95241bf-73f2-0310-859d-f6bbb57e9c96
scan job in the calling thread).
* KDiskDeviceManager::InitialDeviceScan() now runs synchronously, so that
get_boot_partitions() doesn't need to do this ugly wait hack.
* KDiskDeviceManager::CreateFileDevice() can now run synchronously as well, which
fixes a deadlock in fs_mount() - note, mounting file devices still doesn't work,
though as Haiku's BFS doesn't allow this right now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17334 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
when called with interrupts turned off, get_memory_map() will now call the new
vm_translation_map_ops::query_interrupt() call.
Under PPC, this is trivial (at least right now), but on x86 we need to make sure
we have access to the page table entry, ie. we need to create an area that points
to its own page table entry, so that we can map in the page table entry containing
the address we're looking for. It's not really nice, feel free to come up with
a cleaner solution :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17280 a95241bf-73f2-0310-859d-f6bbb57e9c96
always call all handlers in this case, but we still try to return the correct
return code (ie. B_HANDLED_INTERRUPT and B_INVOKE_SCHEDULER).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17278 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
class, and only wraps around that one.
* Translating is no longer serialized, you can translate more than one object
at a time now.
* A BTranslator that is released (ie. deleted) will no longer let its BTranslatorRoster
crash.
* Removed BTranslatorRoster::Version() - this kind of call definitely makes no
sense at all. It's still exported from the sources, though, for backwards
compatibility.
* Simplified and improved code.
* Images are now unloaded only once.
* Added new method IsTranslator() that will be used by the DataTranslations preferences
application.
* Began implementing new methods StartWatching()/StopWatching() that will notify
you if new translators are installed or old ones removed (this will also be used
by DataTranslations once it's ready).
* The private BTranslatorRoster class will now add itself to the existing BApplication,
in order to provide automatic updating of the translators if needed (not yet implemented
though).
* Not heavily tested yet, there might be some regressions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17247 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
* The Decorator are temporarily using ui_color() - this needs to be changed
to use the DesktopSettings (when the decorator stuff gets refactored); right
now, the colors are fixed.
* Added B_WINDOW_TEXT_COLOR, B_WINDOW_INACTIVE_TAB_COLOR, and
B_WINDOW_INACTIVE_TEXT_COLOR to the UI colors, B_WINDOW_TAB_COLOR is no
longer deprecated. Note, however, that not every decorator may use these
colors.
* Removed unused and wrong (ie. hard-coded paths) stuff from ServerConfig.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17236 a95241bf-73f2-0310-859d-f6bbb57e9c96
read-only area shared between the Desktop and all applications.
* Right now, this area only contains the desktop colors, ie. B_PANEL_BACKGROUND_COLOR
etc.; ui_color() no longer needs to ask the server for these colors.
* The ui_colors are now maintained by DesktopSettings, though ColorSet is still there.
* The default colors are now hardcoded once and for everyone in InterfaceDefs.h, ie.
the app_server uses them as well.
* Desktop::Init() can now also return an error (but that is not yet accounted for).
* Cleaned up InterfaceDefs.h.
* Fixed wrong include in moreUTF8.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17232 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 fixes to make screen_blanker wait_for_thread() instead of
killing the screen saver thread, BScreenSaver::Stop() is now called
as well as its destructor
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17206 a95241bf-73f2-0310-859d-f6bbb57e9c96
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17201 a95241bf-73f2-0310-859d-f6bbb57e9c96
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
systems a chance to know if they have locked already.
This fixes a locking problem in BFS where one thread tried to acquire two read
locks (where someone else trying to acquire a write lock would have caused a
dead lock).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17108 a95241bf-73f2-0310-859d-f6bbb57e9c96
to cut down on BRegion related allocations, cannot really tell
if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
the debugger if you
- try to nest read locks
- try to write lock when your are a reader already
- don't match up nested locks when your a writer
-> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
and fixed the locking for use with the MultiLocker, the "a reader can
not become a writer" is especially tricky, feel free to review the
changes
* activated the MultiLocker, I tested this quite a bit, if there are
problems simply turn on DEBUG and you should drop into the debugger
right where the problem is... hope all is good
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
is public now, even if it may not yet be public and fixed API.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16995 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
it and rebuilding it on the server side (that causes a huge speed
up for regions containing many rects)
* There is a method in ServerLink that could have been used, but I
actually needed to add the direct BRegion support to LinkReceiver
* added LinkReceiver as a friend to BRegion class
* ServerApp and ServerWindow keep the CursorManager locked after they
have retrieved a cursor until they have called Acquire() on the
cursor. (Axel: what good is using atomic* stuff in Acquire() and
Release() if we have to protect this by a lock anyways?)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16957 a95241bf-73f2-0310-859d-f6bbb57e9c96
function, and added a vfs_disconnect_vnode() for other kernel components.
* devfs_unpublish_device() can now optionally make use of this call.
* Fixed the type check of devfs' unpublish_node().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16907 a95241bf-73f2-0310-859d-f6bbb57e9c96
though it looks so simple, I see no reason why it shouldn't work 8-)).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16906 a95241bf-73f2-0310-859d-f6bbb57e9c96
information to identify the boot volume - if we want to be able to map all BIOS
drive IDs to the disks in the system, we need to do this always, though.
* Forgot to commit the updated disk_identifier.h in the last commit...
* Removed the unused dumpBlock() function from devices.cpp.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16892 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Adapt other sources where needed (the boot loader's RootFileSystem still
used the old implementation).
* Implemented RootFileSystem::Rewind().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16889 a95241bf-73f2-0310-859d-f6bbb57e9c96
loader): it now supports holes between segments, and accepts any segment order.
* Renamed elf.c to elf.cpp and fixed warnings.
* Renamed elf_image_info::dynamic_ptr and eheader to dynamic_section and elf_header.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16878 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
BRect to clipping_rect with simple C casts. I think this
is more adequate, since clipping_rects are used for
pixel indices. This change fixes some graphics problems too,
it appears that cursor coords are fractional on Haiku, even
with a normal mouse. In Playground, this resulted in the
hit points being rendered wrongly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16840 a95241bf-73f2-0310-859d-f6bbb57e9c96
now on the amount of memory installed in the system. Ie. if you have only
128 MB the kernel heap will be only half in size.
* Minor cleanup in vm_page.c, renamed some variables to match our style guide.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16838 a95241bf-73f2-0310-859d-f6bbb57e9c96
Axel Dörfler