* Renamed scsi_dsk to scsi_disk.
* Joined all scsi_disk sources together to a single scsi_disk.cpp file.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25737 a95241bf-73f2-0310-859d-f6bbb57e9c96
regression that audio playback of multiple files was not "seamless" anymore.
Even video playback should be seamless, the remaining small glitch could be
a problem with buffer timeout if the switch takes too long.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25735 a95241bf-73f2-0310-859d-f6bbb57e9c96
the producer media nodes would access the suppliers in their own thread
without having any locks held, while the window could replace the suppliers.
I think since I delayed the deletion of the suppliers in the controllers, this
problem was only theoretical... but this is just more clean.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25734 a95241bf-73f2-0310-859d-f6bbb57e9c96
a way that the transport group did not need to re-layout, then the seek
slider would not be at the correct position.
* Layout the transport controls with a fixed maximum width in order to prevent
spreading them too much.
* Fix "About" and "MediaPlayer" missing a space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25733 a95241bf-73f2-0310-859d-f6bbb57e9c96
displayed, does not seem to be the reason for the problem I am observing
with one clip I have, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25732 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Leave the codec a chance to advertise the best output color space,
try B_YCbCr422 as the most widely supported format in case the codec
does not advertise.
* Support two more overlay colorspace modes in the video consumer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25731 a95241bf-73f2-0310-859d-f6bbb57e9c96
two notifications (install + update), but only the install
notification.
* When create_app_meta_mime() installs a new MIME type (app signature or
supported type), it only sends the install notification, instead of
install + one or more updates.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25730 a95241bf-73f2-0310-859d-f6bbb57e9c96
as it seems devfs should not take over ownership. The device is deleted
in republish_driver for legacy drivers before the call to devfs_unpublish_device
that in turn deletes the vnode. This looks generally suspicious to me as
the device pointer the devfs vnode may still use gets invalid for a certain
amount of time (until the node is unpublished). So maybe the devfs should
take ownership of the device afterall and it shouldn't be deleted by the
device_manager/legacy driver functions. Axel please review.
* Do not try to delete the IOScheduler for now as creating one is disabled
currently too.
This fixes the crash on rescans of legacy drivers as seen when unplugging
USB devices.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25729 a95241bf-73f2-0310-859d-f6bbb57e9c96
"interface"
* Complete reimplementation of the playback engine using Media Nodes:
- Seeking video files does not appear to lockup the playback anymore, but
works on a frame accurate level even for keyframe based streams. There is
currently a problem with certain container formats, the audio track reports
a "Device Seek Error" in certain conditions. In that case audio goes silent,
and can be restarted by going back to the beginnings of the stream.
- Video overlays are now supported.
- It would be possible to connect the output of the MediaPlayer to other
applications or dormant media nodes.
* Known regressions:
- The volume slider has currently no effect anymore.
- Switching the audio track during playback has a known race condition and
can crash the player.
- The new engine is not as "light weight" as the old one. I tagged the
previous implementation in tags/components/mediaplayer-engine-v1. It does
not seem to have any noticable effect though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25725 a95241bf-73f2-0310-859d-f6bbb57e9c96
part of headers/private/shared, Icon-O-Matic used older versions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25720 a95241bf-73f2-0310-859d-f6bbb57e9c96
to give other windows the opportunity to mark the icon invalid before
recaching it.
* Since we currently update all app MIME types on first boot, over 400 messages
are generated, so that delay easily caused the message queue to get full.
* I've now reduced the wait to 10 ms, and also call BWindow::UpdateIfNeeded()
afterwards, which empties the message port, too. This fixes bug #2212.
* Note though, this should be handled completely different to make it really
work right.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25719 a95241bf-73f2-0310-859d-f6bbb57e9c96
Instead we only allow temporary caches to be merged. This remedies the
problem that after fork() + join() there remains a superfluous cache
layer for all RAM areas.
I haven't tested it, but this might improve the jam situation
memory-wise (huge heap is committed one less time), though it might
worsen it performance-wise (lots of heap pages are moved with every
merge).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25717 a95241bf-73f2-0310-859d-f6bbb57e9c96
new function merge_cache_with_only_consumer(), which is also used in
vm_cache_remove_area(), now.
* Added tracing for the merge case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25716 a95241bf-73f2-0310-859d-f6bbb57e9c96
help with bugs, sending patches and the ongoing Haiku-Ports effort.
As always, if you think someone should be listed, please drop me a line!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25711 a95241bf-73f2-0310-859d-f6bbb57e9c96
the message count doesn't really make much sense anyway (as opposed to
limiting the maximum size of waiting messages), we might still want to
enlarge this even more.
* This should further help with #2212.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25709 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This is not perfect, but it makes Tracker catch up and redraw when the next
event is due. This improves the situation in bug #2212.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25708 a95241bf-73f2-0310-859d-f6bbb57e9c96
concurent SendRequest() calls. Therefore it's probably a good idea to
protect that, now that the request data is not dynamically allocated anymore.
* Fix warning about not returning a result in the compatibility version of
init_mutex_etc() (which wouldn't make a difference as the Haiku version
does not return anything).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25707 a95241bf-73f2-0310-859d-f6bbb57e9c96
or busses/ide.
* This change makes the AHCI driver working again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25705 a95241bf-73f2-0310-859d-f6bbb57e9c96
remains. This replaces the previous mechanism of switching the thread to
a dedicated death stack. We might consider moving more cleanup work to
the undertaker, but that seems a little more involved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25704 a95241bf-73f2-0310-859d-f6bbb57e9c96
member in AHCIController, since, at least in theory, every PCI device could
come with its own module.
* Fixed exported module names to indicate compliance with the new device
manager.
* Apparently, GCC4 doesn't like mixing C++/C linkage even for variables anymore,
though it really shouldn't care about that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25699 a95241bf-73f2-0310-859d-f6bbb57e9c96
packages. Print an error message for unavailable packages.
* Detect the build of a GCC2/GCC4 hybrid image and install GCC2 packages
on a GCC4 build where no GCC4 package is available. I did not test
every GGC2 package on a GCC4 build, though I have not found any that
does not work. If a package gives problems, feel free to disable it
for the hybrid build or send me a note.
* Add new optional package for Beam. Though I could not test it since,
SATA AHCI does not work for me ATM. I know that Beam 1.1 for BONE is
unable to retrieve mails (times out). Maybe the R5 version has better
luck, will check later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25695 a95241bf-73f2-0310-859d-f6bbb57e9c96
than a semaphore, and can already be used in the early boot process.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25689 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Adjusted code using recursive locks respectively. The initialization
cannot fail anymore, and it is possible to use recursive locks in the
early boot process (even uninitialized, if in BSS), which simplifies
things a little.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25687 a95241bf-73f2-0310-859d-f6bbb57e9c96