_CheckColorMenu() now selects the closest item available - if you switch back
the resolution to one that supports the original color space, it will be
restored. This fixes bug #2995.
* I also reverted r24674 as I remembered why I did that in the first place
(advertizing 24 bit modes as 32 bit), and it was a pretty stupid idea to
solve it like this, I must admit.
* Instead, the color space menu now only shows spaces that are actually
supported by the card at all. One could think about hiding 24 bit in case
both 24 bit, and 32 bit are available, but I didn't do that yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32179 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Changed BMenuField::MenuBarLayoutItem::BasePreferredSize() to return the
min size as well, instead of a fixed 100 pixels for the width...
* More minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32177 a95241bf-73f2-0310-859d-f6bbb57e9c96
always created for directories since quite some time now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32158 a95241bf-73f2-0310-859d-f6bbb57e9c96
only add a very limited amount of buffers part of the frame buffer, for
example, as that one is usually a very large area.
* This could prevent all sorts of media buffers to be cloned on certain
conditions (and could also cause a MediaPlayer fallback to bitmap mode for
no apparent reason).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32156 a95241bf-73f2-0310-859d-f6bbb57e9c96
already fixes bug #4189, although there is another bug that could cause a
similar effect (working on that next).
* Switched from media_server local TMap to HashMap, although this is probably
equally archaic.
* Also replaced TList with std::set for the team list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32155 a95241bf-73f2-0310-859d-f6bbb57e9c96
instead of allocating them separately, no functional change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32153 a95241bf-73f2-0310-859d-f6bbb57e9c96
time. But since this is also locked from within the driver/directory watcher
(with the node monitor lock held), and handle_driver_events() could cause
node monitoring updates, the locking order could be reverted, causing a
deadlock (I just ran into).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32152 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan, Axel, could one of you report this change in clockwerk/src/shared/AudioProducer.cpp too.
Clockwerk name his audio output "MediaPlayer Sound Output", which is both confusing and, well,
semantically wrong ;-).
BTW, for MediaPlayer being able to (re)name his output after the filename playing will be great, no?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32150 a95241bf-73f2-0310-859d-f6bbb57e9c96
be broken in the app_server now, but I haven't checked yet.
* Fixed typo in vesa.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32141 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cleaned up the source file, no functional change (intended).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32139 a95241bf-73f2-0310-859d-f6bbb57e9c96
Since we don't support Flattened Device Trees yet (and they don't solve all the issues), we need a place to hole board-specific config, which are different even though we use U-Boot on ARM. Things like cpu & mmu type...
U-Boot doesn't really help us there anyway, it only passes a few board infos (RAM banks & the bill), and optionally other stuff if we fake a linux kernel or netbsd loader, but still not enough. FDT support isn't available for ARM in U-Boot yet either. So for now, and likely for stuff we can't get from FDT, we'll put board-specific config there.
Unlike desktop machines were we want a single kernel per arch, we'd rather have the kernel built for a single board without having to handle detecting mmu type at boot and switching calls like I did on m68k.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32137 a95241bf-73f2-0310-859d-f6bbb57e9c96
accessible to the userland - this fixes#2405 (ie. MediaPlayer overlay now
works).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32135 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes problems with large files with sparse ranges (for example, Haiku
images).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32131 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fleshed out the Encoder API to support parameter setters/getters and returning
a BView for configuration. (Not yet sure if this is a good idea.)
BMediaTrack:
* Implemented all but one of the unimplemented methods in BMediaTrack. It should
be working as far as that class is concerned, unless I missed some of the
vision. ReplaceFrames() remains a stub, added a comment on why it probably
stays that way.
* Release the Encoder reference in the destructor.
FFmpeg plugin:
* Refactoring to delay opening the AVCodec until encoding the first chunk,
so that we can still adjust parameters.
* Support adjusting parameters via [Set|Get]EncodeParameters(). Currently,
only quality is supported, added TODOs about supporting the bit_rate setup
versus the automatically calculated bit_rate.
* Extended EncoderDescription by a bit_rate scale. The Encoder calculates the
raw bitrate needed by the current media format, and then divides that
number by the specific codec's bit_rate_scale, while taking into account the
desired quality. This seems to work very well already (tested with MPEG4),
although a lot more parameters could be specified for libavcodec, depending
on the desired quality.
* Enabled the ogg muxer in libavformat, although it is currently still disabled
in MuxerTable.cpp, because it rejects unknown codecs. Added TODO to this
effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32124 a95241bf-73f2-0310-859d-f6bbb57e9c96
