- Lazy initializing the fDecodedData variable fits best in
_ResetRawDecodedAudio() as fRawDecodedAudio is all about managing properties
of fDecodedData. So fDecodedData having some memory allocated is seen as a
property here.
- Updated documentation accordingly
- No functional change intended.
- For best performance the color conversion function expects a memory location
aligned to 32 bytes. Without that alignment the color conversion function
falls back to a slower conversion path. This fix was measured via
DO_PROFILING and tested with various 1080p video files.
- The first decoded video frame was always zero bytes large, due to passing the
wrong linesize to the color conversion function. The field containing the
right linesize (fHeader.u.raw_video.bytes_per_row) simply wasn't initialized
yet. Fix it by updating fHeader first before applying deinterlacing and color
converting to the decoded video frame.
Tested with mpeg2_decoder_test where the first picture now isn't empty
(black) anymore.
- Padding is required by FFMPEG for correct operation of all audio decoders.
FFMPEG performs some speed optimizations under the hood that may lead to
reading over the end of the chunk buffer wouldn't there have been padding
applied.
- Resolve TODOs by unifying fVideoChunkBuffer and fChunkBuffer back into
fChunkBuffer because audio path is responsible for freeing fChunkBuffer now.
Resolved TODOs apply to the replacing fVideoChunkBuffer variable by
fChunkBuffer, rename some methods by removing the "Video" part, collapse two
methods into one (_LoadNextChunkIfNeededAndAssignStartTime()).
No functional change intended.
- Enhance "logging stream to file" functionality to write to distinct logging
files for audio and video. Before this commit one could only log video
streams. But with unifying the _LoadNextChunkIfNeededAndAssignStartTime()
audio streams gained the logging functionality for free. But now audio and
video streams would be written in the same log file when watching a media
file containing both audio and video. This is prevented by the distinct
logging mentioned above.
- Update documentation accordingly.
- Main reasons for this refactoring of negotiation steps are to increase
readability and to be on par with the video path.
- Rearrange some negotiation steps in video path to be on par with audio path.
- Add documentation for the new method and update existing documentation
accordingly.
- No functional change intended.
- Fix max line length, switch statement style and some pointer comparisons in
if statements. No functional change intended.
Note: There may be more coding style violations lurking.
- Main purpose is to debug a/v synchronization issues by playing the dumped
mpeg ts data in alternative video players (like ffplay or MediaPlayer) and
see how those behave.
- The commit diffs shows some coding style violations (max. line length) that
show up throughout the whole DVBMediaNode class. Those will be fixed in the
next commit to keep a clean separation between the different code changes.
- Kudos to Marcus Overhagen for laying out the general idea of automatic
detection by sharing some of his dvb code examples with me.
- Automatically detect the audio frame rate, channel count and sample format.
- Share audio sample format conversion code between AVFormatReader and
AVCodecDecoder.
- Tested with several video and audio files via MediaPlayer.
- Tested also with test case mp3_decoder_test -after- removing the hard coded
audio decoding parameters. Although the test shows that auto detection is
working (via stepping through the auto detection code path) the complete test
is still failing, due to missing implementation of incomplete audio frame
decoding.
- Add and update the documentation accordingly.
- Main purpose is to prepare auto detection of audio frame properties for
media formats that encode those properties in the frames themself (e.g. MP3)
instead of in the container format (e.g. WMA).
The main difference between akin named methods _DecodeNextAudioFrame() and
_DecodeNextAudioFrameChunk() is that the former method deals with providing
the exact number of audio frames expected by the caller of
BMediaDecoder::Decode() and the latter deals with decoding any number of
audio frames at all.
- New documentation added and existing documentationupdated accordingly.
- No functional change intended.
- Some small refactoring when resetting fRawDecodedAudio. Instead of letting
FFMPEG reset fRawDecodedAudio we do it manually to preserve the allocated
memory in fRawDecodedAudio->opaque (otherwise FFMPEG's
avcodec_get_frame_defaults() would NULLify the opaque pointer without
releasing the allocated memory.
- Keep track of the total size of fDecodedData in fRawDecodedAudio->linesize[0]
instead of relying on calculating it every time it is needed. This makes the
code more comprehensible.
- Main reason for this refactoring is to increase readability and thus make
audio decode path more comprehensible.
- Added documentation for the new method accordingly.
- Small change in calculating the decoded data size to clear when error occurs
during decoding. This way it is more readable and more consistent with
calculations of decoded data size on other locations.
- No functional change intended.
- Main reason for this refactoring is to increase readability and thus make the
audio decode path more comprehensible.
- Added documentation for the new method accordingly.
- No functional change intended.
- Main reasons are to increase readability of audio path and to demonstrate
that chunk loading in audio and video path is the same code that can be
focused in one method (instead of two at the moment). Added a TODO for
collapsing both methods into one and the conditions that must hold true to
do so (just in case I'll be hitted by a bus and someone else has to proceed).
Collapsing is scheduled for a later commit.
- Added documentation for the new method accordingly.
- Make use of full line length in comments of
_LoadNextVideoChunkIfNeededAndAssignStartTime().
- No functional change intended.
- Main reason for this refactoring is to increase readability and thus make the
audio decode path more comprehensible.
- Added documentation for the new method accordingly.
- Small refactoring for detecting when to update fRawDecodedAudio's properties.
This is a preparation step for factoring out the flushing of the
fDecodedDataBuffer in a later commit.
- No functional change intended.
- FFMPEG handles the relationship of start time between encoded and decoded
audio data now by using the fTempPacket->dts and the
fDecodedDataBuffer->pkt_dts fields. We still have to manually keep track of
start times for consecutive audio frames though to support returning a number
of audio frames that may assembled of partial AVFrames.
- The start time of the very first audio frame data packet returned by Decode()
is now correctly calculated based on GetNextChunk() start times instead of
being always zero.
- Introduce fRawDecodedAudio that serves as a container to store properties of
the audio frames stored in fDecodedData. This prepares the population of the
fHeader structure with audio frame properties needed to allow clients of
BMediaDecoder::Decode() detect audio format changes in a later commit.
- Remove fStartTime as it is superflous now.
- The reason for compiler complaining about "INT64_C is not defined here" is
gone since the addition of the compiler flag "-D__STDC_CONSTANT_MACROS"
to the Jamfile some time ago. This flag allows C++ to use C99 math features.
- No functional change intended.
- Also change what is printed for video frames. Currently both
debug_fframe_[audio|video] are used in AVCodecDecoder only and thus are
streamlined for their usage there. For example we print the AVFrame.pkt_dts
field instead of the AVFrame.pkt field because the later one is never touched
by AVCodecDecoders usage of the FFMPEG library.
Note: AVFrame.pkt being never touched means that it always contains the value
AV_NOPTS_VALUE making it less useful for debug purposes.
- There are two main reasons for this refactoring:
1. Prepare using FFMPEGs functionality of audio frame start time assignment
(instead of rolling it ourself) like already done for the video path
(see _LoadNextVideoChunkIfNeededAndAssignStartTime() for reference).
2. Get rid of fChunkBufferOffset (this is a minor reason though).
- Untangle some of the conditional checks to increase readability.
- No functional change intended.
- First method is solely responsible to fill the audio output buffer with
already decoded audio frames.
Second method is solely responsible for decoding the encoded audio data and
put it in the decoded audio output buffer for further processing with the
first method.
This prepares auto detection of audio frame properties for audio formats
where the properties are contained within the encoded audio frame (e.g. MP3),
instead within the audio container format (e.g. WMA). Implementing auto
detection is scheduled for a later commit though.
- Added documentation accordingly.
- No functional change intended.
- Use name that correctly reflects the return value of avcodec_decode_video2().
- Make DO_PROFILING code path of AVCodecDecoder compile again.
- No functional change intended.
- This makes the video output looks more visual appealing. Without bilinear
filtering you would see aliasing artifacts all over the place. Now it looks
more harmonic.
- This get rids of the complain "'UINT64_C' was not declared in this scope" and
allows us to remove the (now superflous) declaration of UINT64_C.
- No functional change intended.
- This should fix the bug where video files that played well before the recent
changes to the FFMPEG Plugin didn't play anymore. Now we apply the essential
video container properties (that were passed by with Setup()) to the
AVCodecContext. Some video formats simply store those properties in the
container only (e.g. AVI, WMV) and not in the video frames itself
(e.g. MPEG2).
Tested with several files from samples.ffmpeg.org and from the FATE suite of
FFMPEG.
- Ensure that start times are increased monotonically for video formats that
contain B-frames, too, as expected by the BMediaDecoders.
Previously start times were returned that seemed to go back in time for
videos containing B-frames.
Tested with resolutionchange.mpg (\see http://samples.ffmpeg.org/MPEG2)
Note: Even though start times aren't going back in time anymore there are
times where two consecutive start times are equal. This would need more
research once this exposes a bug in a real application. Further more this
might seem like a new bug, but before this commit the equal start times would
have simply some different start time[s] in between. So at most this is the
same bug just wearing new clothes :)
- Documentation updated accordingly.
- I misinterpreted the semantics of reordered_opaque. I thought it would
establish the correct relationship between the start_time returned by
GetNextChunk() and the next video frame successfully decoded. But for this
to work reordered_opaque expects to be filled with presentation time stamps.
A series of presentation time stamps may be jumping back in time due to the
presence of B-frames. The decoded frame presentation time stamps series would
then be ordered in a monotonically increased way.
But actually GetNextChunk() always returns monotonically increasing start
times. Mapping this behaviour to FFMPEG's expectations means labeling those
start times as decoding time stamps (dts). Though for those start times to be
related to the correct decoded video frames you have to assign the start time
with the AVPacket containing the data to be decoded.
- This commit finally makes DVB video playback working for me with the TV app.
Though no audio yet.
- The documentation was updated accordingly.
- This field is needed by the dvb.media_addon to detect a format change so
fill it with the correct value.
- Updated documentation accordingly to reflect reordered function calls and new
assumptions based on the function call ordering.
- Due to comparing the wrong fields with one another the dvb.media_addon called
ChangeFormat() on every new video frame.
- Also remove a duplicate print statement.
- This init check prevented the MediaStreamDecoder from setting up an input
format. The values the init check is based on are initialized by the first
call to BMediaDecoder::SetTo() as described in the BeBook ("If you use the
empty form of the constructor, you'll have to call SetTo() to establish the
format to be decoded before calling Decode()"). But MediaStreamDecoder
doesn't provide a public way to call BMediaDecoder::SetTo() first.
There are at least two possible solutions to remedy this situation:
1. Remove the init check
2. Add a public way to call SetTo()
The first solution was chosen for the following reason: Least amount of
code change needed as it is an implementation detail so no client code has
to be touched.
The second solution might make sence when you want to stick to the BeBook
where a clear distinction between SetTo() and SetInputFormat() is made, but
as the current MediaStreamDecoder implementation doesn't stick to the BeBook
anyway there is less need to add another method at this time.
- This is the workaround as described in the bug report #11018.
- I would have preferred to place this workaround in DVBMediaAddon::InitCheck()
as this method can return a status code but unfortunately it is never called.
- Remove use of now superflous media_header_ex structure.
- Respect 80 char line limit and indentation rules. Coding style only applied
to functions raw_[audio|video]_thread, rest of the class may need some more
cleanup.
- No functional change intended.
- Fixes a bug using realloc with a memory area that is declared const which
lead to a crash in MediaPlayer playing big_buck_bunny_720p_stereo.ogg.
- The refactoring introduces a strict separation between const memory areas
(chunk data read from GetNextChunk()) and mutable memory areas
(fVideoChunkBuffer) by using a copy operation instead of a casted
assignment operation.
- Updated documentation accordingly.
- Besides fixing the bug, there is no functional change intended.
- Main reason for refactoring was to increase readability of
_DecodeNextVideoFrame() by simplifying it. Refactoring was tested
successfully for no functional change with mpeg2_decoder_test.
- Reindented the method definition in the header file so that the new method
_LoadNextVideoChunkIfNeededAndUpdateStartTime() fits into 80 chars per line.
Reindentdation is applied to methods only as the member variables have no
space left for reindentation.
- Update documentation accordingly.
- Fix wording of audio part to audio path.
- No functional change intended.
- Padding is required by FFMPEG for correct operation of all video decoders.
FFMPEG performs some speed optimizations under the hood that may lead to
reading over the end of the chunk buffer wouldn't there have been padding
applied.
- Note: Padding is required for audio decoders, too. I will tackle this in some
later commits. For the time being we have a degradation in code reuse, due to
different memory ownership of chunk buffers in audio and video decoder path.
Audio path must not care about freeing chunk buffers whereas video path must.
- Fix coding style and some typos.
- Update documentation accordingly.
- Video frames still contained in the video decoder are now flushed when there
are no encoded data chunks left (signaled by B_LAST_BUFFER_ERROR).
- New code was successfully tested with mpeg2_decoder_test. The last test image
is now decoded, too, resulting in a bump of the expected number of decoded
images.
- Refactor code to support flushing -and- keep the readability at a sane level.
- Remove some uncommented code for the sake of readability.
- Documentation updated accordingly.
- Kudos to Marcus Overhagen for laying out the general idea of automatic
detection by sharing some of his dvb code examples with me.
- Simplify pixel format search code by removing the loop and let FFMPEG
decide what pixel format to use based on the actual video data.
- Automatically detect the video frame rate based on the actual video data.
- Remove fOutputVideoFormat to avoid synchronizing values in two distinct
places. The member variable fHeader is the main place for important decoder
parameters now.
- Introduce fOutputColorSpace containing the color space that was previously
tracked in the fOutputVideoFormat member variable.
- Update the documentation accordingly.
- The frame rate calculation is purely based on AVCodecContext fields. This way
the frame rate can be calculated by the FFMPEG decoder based on the actual
video data. This is useful for automatically detection of the correct
decoding parameters (not implemented yet but scheduled for a later commit).
- Not used anywhere yet (scheduled for a later commit).
- Also some minor documentation updates.
- Also make use of the extracted code in the AVCodecDecoder class.
- Enhance some documentation and fix some coding style violations.
- No functional change intended.
- This allows a BMediaDecoder (e.g. FFMPEG Plugin) to communicate back format
changes to its clients.
For a more thorough explanation and discussion see haiku-development mailing
list: http://www.freelists.org/post/haiku-development/Request-for-protest-Media-Kit-Extend-media-header-struct
- Backwards compatibility is taken into account and preserved by reducing the
relevant _reserved[] fields.
- Code changes that will actually make use of these extensions are due for the
following commits. As these structure extensions affect several Haiku
components (e.g. media_server, MediaPlayer, etc.) and third party apps (e.g.
StampTV, etc.) I refrain from committing them in one batch with this commit.
This should make it easier to track down bugs originating in this code
change.
(cherry picked from commit 806b6888d2dcf84b4934f8f137a48d3381864d1c)
- We let FFMPEG keep track of the correct relationship between presentation
start time of the encoded video frame and the resulting decoded video frame.
This simplyfies our code, meaning less lines of code to maintain :)
- Update documentation and pointing out some corner cases when calculating the
correct presentation start time of a decoded video frame under certain
circumstances.
- Fix doxygen: Use doxygen style instead of javadoc style.
- No functional change intended.
Signed-off-by: Colin Günther <[email protected]>
- Main purpose is to make reading the function DecodeNextFrame() easier on the
eyes, by moving out auxiliary code.
Note: The media_header update code for the start_time is still left in
DecodeNextFrame(). This will be addressed in a later commit specially
targetted on handling start_time calculations for incomplete video frames.
- Also updated / added some documentation.
- No functional change intended.
Signed-off-by: Colin Günther <[email protected]>
- This commit makes the mpeg2_decoder_test successfully decode the test video
into 84 consecutive PNG images, yeah :)
- If this commit broke playing video files for you please file a bug report.
I've tested only with one video file (big_buck_bunny_720p_stereo.ogg) that
everything still works.
- The implementation has some shortcomings though, that will be addressed with
some later commits:
1. Start time of media header is wrongly calculated. At the moment we are
using the start time of the first encoded data chunk we read via
GetNextChunk(). This works only for chunk that contain one and exactly
one frame, but not for chunks that contain the end or middle of a frame.
2. Fields of the media header aren't updated when there is a format change
in the middle of the video stream (for example the pixel aspect ratio
might change in the middle of a DVB video stream (e.g. switch from 4:3
to 16:9)).
- Also fix a potential bug, where the CODEC_FLAG_TRUNCATED flag was always
set, due to missing brackets.
Signed-off-by: Colin Günther <[email protected]>
- It is just one flag that needs to be set, so that streaming video data can be
handled by the FFMPEG library.
- For reference: This flag is based on FFMPEG's 0.10.2 video decode example
(doc/example/decoding_encoding.c).
- The _DecodeNextVideoFrame() method needs to be adjusted (still to come), to
take streamed data into account. So the flag on its own doesn't help, but it
is a reasonable step in that direction.
Signed-off-by: Colin Günther <[email protected]>
- Factor out the deinterlacing and color converting part to make the code more
readable. This makes it easier to understand which code belongs to the actual
decoding process and which code to the post processing.
- There seems to be no performance impact involved (I just looked at the spikes
of the process manager) in factoring out this part, but one can always inline
the method if a closer performance assesment (e.g. by enabling the profiling
the existing profiling code) suggests so.
- Document the _DecodeVideo() method a little bit. Maybe someone can document
the info parameter, as I'm a little bit clueless here.
- No functional change intended.
Signed-off-by: Colin Günther <[email protected]>
(cherry picked from commit c5fa095fa73d47e75a46cfc138a56028fcc01819)
- We factor out the code that does the decoding, deinterlacing and color space
converting into its own function. This prepares auto detection of video frame
properties in a later commit. Auto detection means (for example), that you
don't need to know the size of the decoded video frame -before- intitializing
the video codec as it is the case with the current implementation.
- Use the already existent private member variable fHeader to fill out and
return video frame properties.
- Rename some variables to be more self describing.
- No functional change intended.
Signed-off-by: Colin Günther <[email protected]>
(cherry picked from commit 6beab04f48e98022041895750f38c5a35a5f4f9e)
- As it is rather hard to find useful documentation, on how to use FFMPEG's API
we cut of some research time by just documenting it at the place where it is
most visible to other FFMPEG plugin developers :)
Signed-off-by: Colin Günther <[email protected]>
(cherry picked from commit b0ed15d2196ca45de8ab2d5913d760602aacc5f3)
- This small refactoring is in preparation for implementing decoding of partial
video frame data, where one needs to preserve encoded data between multiple
calls to AVCodecDecoder::_DecodeVideo().
- Note: The names fChunkBuffer and fChunkBufferSize are open for discussion.
I'd rather prefer fEncodedDataChunkBuffer and fEncodedDataChunkBufferSize.
But I'd like to take small refactoring steps, and changing the naming would
also touch the AVCodecDecoder::_DecodeAudio() function. I'd rather focus
on improving the video part for now, leaving the audio part alone.
- No functional change intended.
Signed-off-by: Colin Günther <[email protected]>
(cherry picked from commit f2da1e752458b926aebe50642bf6af19e9903f17)
The workaround triggers the loading of all media plugins prior to using
methods of class BMediaFormats. Using the function get_next_encoder()
is used because of two facts
1. It is publicly available and thus can be used by 3rd party apps,
too.
2. It is already available by including BMediaFormats.h, so there is
no need to include another header for this workaround.
Signed-off-by: Colin Günther <[email protected]>
(cherry picked from commit a89b0a4e69f18b2b3b2c2f5615450a5ddac838af)
The workaround triggers the loading of all media plugins prior to using
methods of class BMediaFormats. Using the function get_next_encoder()
is used because of two facts
1. It is publicly available and thus can be used by 3rd party apps,
too.
2. It is already available by including BMediaFormats.h, so there is
no need to include another header for this workaround.
Signed-off-by: Colin Günther <[email protected]>
(cherry picked from commit 80354716fe8b25c81ec45bd96ae36e171228b8a0)
- Compiling dvb.media_addon with DEBUG on fails with error message:
generated/objects/haiku/x86/debug_1/add-ons/media/media-add-ons/dvb/
MediaFormat.o: In function `av_log2_c': /boot/home/Development/haiku-a4/
generated/build_packages/ffmpeg-0.10.2-r1a4-x86-gcc2-2012-08-30/common/
include/libavutil/common.h:80: undefined reference to `ff_log2_tab'
collect2: ld returned 1 exit status"
- Research done to narrow down the solution space:
- ff_log2_tab is a array that is nowhere needed in the dvb.media_addon
- ff_log2_tab is defined as an extern array in the ffmpeg header file
libavutil/common.h
- ff_log2_tab is used in the inline function av_log2_c (libavutil/common.h)
which doesn't get optimized away when compiling with debug information
- MediaFormat.cpp needs only some Codec-IDs from the ffmpeg header file
avcodec.h
- The following fixes were tried:
- Trying to eliminate unused debug symbols with compilation
flag -feliminate-unused-debug-types (see gcc documentation
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Debugging-Options.html#Debugging-Options)
by adding the following lines to UserBuildConfig
AppendToConfigVar C++FLAGS : HAIKU_TOP src : -feliminate-unused-debug-types : global ;
AppendToConfigVar CCFLAGS : HAIKU_TOP src : -feliminate-unused-debug-types : global ;
-> Failed, because flag -feliminate-unused-debug-types is not supported by GCC 2.95.3
- Trying to eliminate unused debug symbols in the linker stage
-> This worked, by removing the LINKFLAG "-Xlinker --no-undefined" when
linking all objects into the dvb.media_addon we are getting our addon
with debug symbols.
- Final solution:
- Instead of adding/removing flags, we just add the missing implementation
for the ff_log2_tab array in MediaFormat.cpp. This -feels- the seems to
be the cleanest solution as it is more obvious what's goin' on compared
to hiding the solution in the Jamfile.
Signed-off-by: Colin Günther <[email protected]>
- This test currently fails and thus showing that there is something wrong in
the Media Kit.
- This test was first developed and tested on Haiku R1 Alpha 4.1 where
every thing was hacked together to make this test succeed, thus showing that
the current Media Kit state of affair has some issues and not this test :)
- The test comes with documentation (@see mp3_decoder_test.cpp).
Signed-off-by: Colin Günther <[email protected]>
- This test currently fails and thus showing that there is something wrong in
the Media Kit.
- This test was first developed and tested on Haiku R1 Alpha 4.1 where
every thing was hacked together to make this test succeed, thus showing that
the current Media Kit state of affair has some issues and not this test :)
- The test comes with documentation (@see mpeg2_decoder.test.cpp).
Signed-off-by: Colin Günther <[email protected]>
support for some of the newer 9k chipsets. For example my Eee PC 1005 HA can
now be used with WiFi.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35747 a95241bf-73f2-0310-859d-f6bbb57e9c96
been part of r35691, where I applied a patch by mmadia taken from ticket #5457
(which was previously closed by bonefish), with some modifications by me.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35692 a95241bf-73f2-0310-859d-f6bbb57e9c96
driver may not build due to dependencies to the kernel_c++_structs.h header.
Normally this header is build by jam when building the libfreebsd_network.a
library, with the first network driver so to speak.
Adding a rule to the atheroswifi Jamfile to build kernel_c++_structs.h
would be the wrong fix, because the atheroswifi doesn't need condition
variables.
The correct fix is to remove the #include <condvar.h> statement from proc.h.
And while I'm at it, I remove all the other include statements, too, as none
of them are needed by this header (all drivers are still compiling).
* Thank you mmadia for the heads up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35349 a95241bf-73f2-0310-859d-f6bbb57e9c96
should now be able to be installed gracefully. This fixes ticket #5248.
* Enhancement of the -a parameter, so that it accepts multiple packages at once.
Multiple packages have to be included in double quotes, due to the way getopts
handles options. This fixes ticket #5315.
* Thanks mmadia for this patch!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35327 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removing the respective settings files, as they are no longer needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35171 a95241bf-73f2-0310-859d-f6bbb57e9c96
Name mapping is now defined in the glue code.
* Adding two macros for handling firmware name mapping completely in the glue
code:
- HAIKU_FIRMWARE_NAME_MAP(firmwarePartsCount) is used when mapping is
required. Have a look to iprowifi2100's glue code for an example.
- NO_HAIKU_FIRMWARE_NAME_MAP() is used when the firmware names don't need to
be mapped. For example: broadcom43xx
* Discard usage of vm_map_file() and use the previously read() method again.
After Axel and Ingo agree that both methods are fine in this particular use
case, using read() looks easier on the eye. It needs only 3 parameters, where
vm_map_file() takes 10.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35170 a95241bf-73f2-0310-859d-f6bbb57e9c96
firmware for unshipable broadcom43xx and marvell88w8335. Furthermore it installs
the firmware for ipw2100 and iprowifi2200, which requires the user to consent
to its license terms. Thank you mmadia!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35164 a95241bf-73f2-0310-859d-f6bbb57e9c96
nightlies, though. As this will require an update of AboutSystem, which is
scheduled for a later commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35160 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be copied to /home/config/settings/kernel/drivers with omitting the file
endings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35158 a95241bf-73f2-0310-859d-f6bbb57e9c96
the Intel provided firmware archive in /system/data/firmware/ipw2100/ with out
the need of any renaming.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35157 a95241bf-73f2-0310-859d-f6bbb57e9c96
the respective firmware files renaming is now done within the firmware loader.
The mapping of original firmware names to FreeBSD internal firmware names is
now done within driver specific settings files. Those are committed in a next
step.
This approach allows a clean separation of FreeBSD compat layer requirements
and native driver requirements.
For example: we have two Intel PRO/Wireless 2100 drivers. Do we prefer the
naming scheme of the native driver or do we force the native driver to use
the one of the FreeBSD driver? With this commit we prefer native over FreeBSD.
* Changed the firmware loader to make use of Haiku's file mapping facility.
* Implementing firmware unloading.
* Some minor cleanups in two compat layer header files, which are using Haiku
defined identifiers, where apropriate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35156 a95241bf-73f2-0310-859d-f6bbb57e9c96
temporary solution as long as there is no package manager available. When
executing the script, it mentions this, too. This fixes#4680. Thank you.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35041 a95241bf-73f2-0310-859d-f6bbb57e9c96
duplicating firmware names in firmware_get() of the freebsd compat layer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34844 a95241bf-73f2-0310-859d-f6bbb57e9c96
so that it can make use of the firmware installed by the OptionalPackage
Wifi-ipw2100+fw.
* Updating OptionalPackages to use the latest Wifi-ipw2100+fw package.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34833 a95241bf-73f2-0310-859d-f6bbb57e9c96
Now the reference count get accessed only once, leading to true atomarity.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34823 a95241bf-73f2-0310-859d-f6bbb57e9c96
on wlan stack shutdown, now.
* Added patch by mmlr to support IBSS (aka Ad-hoc) mode. To activate IBSS mode
one would need recompile the wlan stack, though, once the constant in
start_wlan() is switched from IEEE80211_M_STA to IEEE80211_M_IBSS. There is
no runtime configuration, yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34821 a95241bf-73f2-0310-859d-f6bbb57e9c96
ensure interrupts are disabled only once per interrupt event.
* Coding style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34819 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Using conditional compiliation instead of just deleting original code
to easen future driver updates.
* Coding style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34816 a95241bf-73f2-0310-859d-f6bbb57e9c96
per interrupt. Moreover the interrupt is disabled only once now too.
* Using atomic_{set|get} operations for synchronizing the interrupt status
as proposed by Axel.
* Coding style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34812 a95241bf-73f2-0310-859d-f6bbb57e9c96
and ath_intr function. Those are faster than the HAIKU_INTR* macros.
* Some variable renaming to stick with common naming conventions of the other
wlan drivers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34811 a95241bf-73f2-0310-859d-f6bbb57e9c96
I don't know about such hardware, it is better to be cautious here.
* Code style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34809 a95241bf-73f2-0310-859d-f6bbb57e9c96
Colin Günther