If you get an "error waiting for interrupt" during boot, try to disabled IDE DMA.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32769 a95241bf-73f2-0310-859d-f6bbb57e9c96
of calloc, since the memory is memcpy()'d in the next line. Added a TODO
comment. +alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32767 a95241bf-73f2-0310-859d-f6bbb57e9c96
media present they will always fail with the no media or media changed errors.
+alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32732 a95241bf-73f2-0310-859d-f6bbb57e9c96
don't try to use it for media status polling. In those cases we'll assume a
fixed device with no exchangable medias and therefore always return B_OK.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32731 a95241bf-73f2-0310-859d-f6bbb57e9c96
does calculate the remaining bytes, not the transferred ones, so obviously that
number has to be subtracted from the expected buffer size! Albeit severe, this
wasn't hit that often, because this calculation will only be used when the
transferred size doesn't match the handed in buffer size exactly. So things like
HID or mass storage, that mostly know the exact transfer size weren't affected.
But it could very well explain #4101 where the size isn't previously know.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32680 a95241bf-73f2-0310-859d-f6bbb57e9c96
of load, when using large enough block sizes or when simply having a slow device
this is by far not enough. It is now at 15 seconds, which should reduce timeout
problems to those cases where the device actually get's stuck (because of us
doing something wrong).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32615 a95241bf-73f2-0310-859d-f6bbb57e9c96
* activated ac3 audio file format support
* uses format metadata to keep the codec context extra data (now needed for flac)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32597 a95241bf-73f2-0310-859d-f6bbb57e9c96
send_bit() causes a type conversion from the value handed in to 0 or 1. This
clashed with the usage in send_byte(), that hands over a shifted byte. The
argument was converted to true when it had any value other than 0, whereas
before (where a bool simply was an int) it would have just handed over the value
directly. Therefore the logic in send_bit() that simply masked off the lowest
bit of the value would now not work anymore.
This fixes EDID failing on GCC4 and therefore fixes#2275, the last issue of
#4084 and may also affect #2780.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32593 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added support for logical partition headers in partitioning info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32591 a95241bf-73f2-0310-859d-f6bbb57e9c96
Please report such warnings, they can help to investigate timing issues with some hda codecs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32589 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also add some paranoid checks: ACPI BIOSes implementation can be... wild.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32584 a95241bf-73f2-0310-859d-f6bbb57e9c96
because all reports schedule transfers on the same endpoint and therefore need
to possibly reschedule. Previously if we got a report that we didn't listen on
all further reports would stop, because noone would schedule a new transfer.
This fixes extra keys not working on my natural keyboard.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32580 a95241bf-73f2-0310-859d-f6bbb57e9c96
image and DevelopmentMin optional package. This is the original libjpeg (6b),
which I will updated to version 7 within the next few days. I need to
understand better the modifications made to it before updating.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32553 a95241bf-73f2-0310-859d-f6bbb57e9c96
processed. The controller may initialize it to any value when starting to
process the descriptor. If a controller did that it was possible that we thought
a transfer was already done even if it actually just started. Transfers would
then return that weren't processed, returning uninitialized buffers.
Instead of relying on the condition codes we now check that the head and tail
pointers are the same. This guarantees that all transfer descriptors of the
endpoint at hand are completed.
Reverted r32534 again as this one fixes the problem for real. The same things
that were mentioned there could happen here essentially, so in the worst case
the device or controller could stall because of freeing in-use structures.
Fixes#4067.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32551 a95241bf-73f2-0310-859d-f6bbb57e9c96
reused and overwritten by the first descriptor of the new transfer and the first
descriptor will become the new tail. We anticipate this situation in
_AddPendingTransfer() and set the first_descriptor of the transfer data to the
tail already. Since the tail was pretty much cleared to zero, this introduced
a race condition. After adding the pending transfer it can already be found
in the finisher thread. If this happened before actually switching the tail
and first descriptor it would find a descriptor with a condition of 0, meaning
"No Error" and would process the transfer incorrectly. Depending on the count
of descriptors and the timing of the switch taking place this could have
resulted in aborted transfers with actual length 0 or with the correct actual
length but invalid data. In the very worst case it could have freed things still
in use by the controller, resulting in all sorts of device errors. Sadly it
doesn't fix#4067.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32534 a95241bf-73f2-0310-859d-f6bbb57e9c96
transfer descriptors into individual packets. The descriptors are more a
logical thing. As such we do not generate one descriptor per packet but one
for each block of two pages at max. Therefore we only set the initial toggle bit
to the one we stored on the first descriptor and let OHCI use the carry bit for
subsequet descriptors. That error would only be visible on transfers above two
pages in size though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32532 a95241bf-73f2-0310-859d-f6bbb57e9c96
retired descriptor, it actually contains the value that is to be used next.
Confirmed that by cross-referencing FreeBSD.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32531 a95241bf-73f2-0310-859d-f6bbb57e9c96
toggle carry stays valid, we better make sure we set it correctly. Additionally
even if the toggle carry wasn't clobbered, there are conditions the toggle is
reset without the controller being able to notice (as in clearing a halt state).
Since I don't have any OHCI hardware this is untested, but should fix bug #4067
if correct.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32510 a95241bf-73f2-0310-859d-f6bbb57e9c96
Use kits/print/PrintTransportAddOn.cpp in transport add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32499 a95241bf-73f2-0310-859d-f6bbb57e9c96
For now copied PrintTransportAddOn.cpp from kits/print into each tranport add-on folder and use that instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32489 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server without having a card that actually supports this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32457 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fix ZETA build as yes, I still test stuff in ZETA :p
Thanks Rene for noticing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32377 a95241bf-73f2-0310-859d-f6bbb57e9c96
device is not compatible, after all.
* No longer accept color changes if the mode is not an 8 bit one. I think that
BWindowScreen does that after changing the mode, so that is messes up the
colors, at least that's the theory, will test on real iron now.
* Use VGA as a fallback if setting the palette via VBE failed. This brings back
the colors for ParticlesII in Qemu (but not in VirtualBox, which seems to be
completely broken in this regard).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32359 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Added him to Contributors
- Missing a icon thoug, any thoughts about how it should look?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32334 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stubbed out config_manager and pci bus_manager arch code.
Now really use the boot floppy tgz for the netbsd uimage as it all builds, but with other kernel arch code not yet commited.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32324 a95241bf-73f2-0310-859d-f6bbb57e9c96
case was an unterminated string, though).
* fix_dirent() did not copy the trailing null-byte.
* Not yet entirely sure why, but this caused #4214.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32254 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Rewrote PartitionMapWriter
* Updated style to match current style guide for the intel partitioning system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32235 a95241bf-73f2-0310-859d-f6bbb57e9c96
GPL mode. Later in the code, the function would only be used in GPL compile mode,
but this fixes the linking in non-GPL mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32193 a95241bf-73f2-0310-859d-f6bbb57e9c96
system has been configured to include GPL add-ons. This cannot be switched on
the fly without rebuilding all of the FFmpeg plugin, since the change in the
Jamfile defines will not automatically trigger a rebuild. So if you change your
configuration with regards to --include-gpl-addons, you have to touch config.h
(this commit touches it anyway).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32191 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enabled WAV muxer.
* Updated configure line in config.h to be closer to what it could have been
to produce the current config.h, but a lot of encoders and muxers are enabled
manually at the moment, so this line wouldn't produce the config.h as is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32188 a95241bf-73f2-0310-859d-f6bbb57e9c96
confused about what I already compiled here). The sample format was already
specified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32186 a95241bf-73f2-0310-859d-f6bbb57e9c96
but specify it to 16bits/sample if it's still a wildcard. Make sure to
allocate the scrub buffer with the correct sample size (was hardcoded to 2
bytes per sample).
* In the AVFormatReader, specify the sample format for B_MEDIA_ENCODED_AUDIO.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32185 a95241bf-73f2-0310-859d-f6bbb57e9c96
a good idea; it didn't have any consequences in there, but actually broke
the app_server's support for the VGA mode.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32181 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
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
again. Should fix playback of any file where the ffmpeg plugin was responsible
for sound. (The symptoms were a crash into the debugger because of an unspecified
audio format...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32107 a95241bf-73f2-0310-859d-f6bbb57e9c96
didn't own.
* We are supposed to open the AVCodecContext in the writer, even though we never
use it. According to libav-users mailing list, this is necessary, since that
will allocate and initialize some structures that are later needed in
av_write_header(). How this is supposed to work for encoders that libavcodec
does not support, or which we don't know how to map, I do not yet know. For
now it doesn't matter and resolves the problem that audio tracks report the
wrong stream duration.
* Some more improvements with regards to what information we need to fill out
and which we don't.
* Use more sensible defaults for the stream bitrate, so that we get better
quality video by default. This and other parameters can be calculated when
we implement setting the quality.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32103 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't leak the driver settings handle.
* No need to get the "active" parameter in ValidateCreateChild() -- either
way is fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32098 a95241bf-73f2-0310-859d-f6bbb57e9c96
generation for the packets and how I set the time_base in the AVStream and
AVStream->codec structures. This results in the audio streams of the written
files to report a much too long duration.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32064 a95241bf-73f2-0310-859d-f6bbb57e9c96
info is not part of the media_format otherwise.
* Finished enough in the AVFormatWriter and AVCodecEncoder that we can now
actually create AVIs and MPGs and encode MPEG1, MPEG2 and MPEG4 video.
But no audio as of yet. Also, there is no bit-rate/quality setup, so it seems
libavformat is using the least possible bit-rate/quality.
* Enable some more muxers and encoders in the FFmpeg libs.
* Uses pixel format conversion from libswsscale, need to read the documentation
again, but I think it makes the plugin GPL.
* Fixed includes in libswscale/swscale.h, this is now an unmodified FFmpeg 0.5
header again (AFAICT).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32043 a95241bf-73f2-0310-859d-f6bbb57e9c96
media_file_format as input, so that the Writer knows what kind of file is
needed.
* Also, since information about the stream format is going to be needed at the
Writer level as well, the AllocateCookie() method gets the stream
media_format.
* Fleshed out some aspects of AVFormatWriter, many TODOs are left.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32025 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented some of AVCodecEncoder. Maybe video encoding already works, but
we don't know until the AVFormatWriter is more than just stubs... but I doubt
it. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32016 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved Encoder API towards what we need for the get_next_encoder() variants
and the BMediaTrack API.
* Implemented the rest of MediaWriter. Still undecided what to make of
AddTrackInfo(). BMediaEncoder has that as well, which hints that this is
something the Encoder needs to support. But it could also be that this is
only possible to support in Writer.
* Wired a lot of previously unimplemented methods in BMediaFile and BMediaTrack
needed for write support. If I have not overlooked anything, only the
parameter stuff is still unimplemented now.
This is all untested, since the FFMpeg Encoder and Writer are still only stubs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32013 a95241bf-73f2-0310-859d-f6bbb57e9c96
The AddOnManager in the media_server registers one encoder entry per
successful EncoderPlugin::RegisterNextEncoder(). This gives us a first idea
what media_format_family and input/output media_type is supported. The
mechanism may have to be extended, or the Encoder needs an API to specialize
a format further. In that case, the get_next_encoder() version that takes
optional _acceptedInput/OutputFormat needs to instantiate the plugin and
needs to ask the Encoder. But AFAIK, no app uses it like that anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32005 a95241bf-73f2-0310-859d-f6bbb57e9c96
but is better than before in any case. The deinterlacing is nothing fancy,
basically, it just drops the first field... the implementation to use this
is also not as efficient as it could be, it currently allocates a temporary
frame always...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31996 a95241bf-73f2-0310-859d-f6bbb57e9c96
current libavformat API. FFmpeg is a little inconsistent in this regard. For
interlaced video, it will report a frame rate which is the field rate, but
still decode both fields into a single frame. For the time being, we reduce
the frame rate from 50.0 to 25.0 and handle interlaced video transparently
for the clients. This needs to be fixed later on...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31995 a95241bf-73f2-0310-859d-f6bbb57e9c96
need to work differently, such that supported media_formats come into play,
I will know soon when I implement some of the stuff from MediaFormats.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31994 a95241bf-73f2-0310-859d-f6bbb57e9c96
"AVI (Audio Video Interleave)" in the available output formats popup... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31956 a95241bf-73f2-0310-859d-f6bbb57e9c96
the one just closed anymore. The fSeparateSubTransactions mechanism should
make sure that this won't happen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31954 a95241bf-73f2-0310-859d-f6bbb57e9c96
Transaction::UnlockInodes() method was never called, leading to bug #4155.
* In order to make sure that inodes are still going to be reverted, we actually
need to move them into the parent transaction which we now do. This should
fix#4155.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31952 a95241bf-73f2-0310-859d-f6bbb57e9c96
definitely not a good idea to move _UnlockInodes() after the Journal::Unlock()
call (which was done to achieve a revertable inode).
* Instead, Journal::Unlock() is now responsible for calling the now public
Transaction::UnlockInodes(), and always does this at the right time while
holding the journal log.
* While I don't understand how #4155 can happen, this bug should be the one that
caused it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31944 a95241bf-73f2-0310-859d-f6bbb57e9c96
* resolved a couple of redundant function declaration in our public headers
* adjusted zipomatic accordingly - everything else built fine
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31938 a95241bf-73f2-0310-859d-f6bbb57e9c96
different name than the directory entry pointing to it). The BeOS BFS is known
to create such problems from time to time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31937 a95241bf-73f2-0310-859d-f6bbb57e9c96
let it crash!
* Made some headers self-contained.
* Always lock, regardless of "reenter" (we're using a recursive lock, so this
doesn't matter at all).
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31913 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reverted r31809 as it introduced a race condition; if the I/O request had been
notified, it could already been deleted at that point.
* Instead, we need to notify the request in each file system/driver that uses
it. Added new notify_io_request() function that does that exactly.
* Added a TODO comment to the userlandfs where the request notification needs
a bit more thought.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31903 a95241bf-73f2-0310-859d-f6bbb57e9c96
* first_argument() never returns NULL, so we don't have to check for it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31899 a95241bf-73f2-0310-859d-f6bbb57e9c96
were supposed to be deleted/changed with the previous commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31888 a95241bf-73f2-0310-859d-f6bbb57e9c96
* checked what offsets my hardware my hardware really had: it affected only playback, and was 192 for 16 bits and 256 for 20/24 bits. With these values, playback and record are crystal clear.
As I can't find any references for such offset values anywhere, sorry it's not supposed to work out of the box on all hardware. Maybe we could adjust the offset at runtime.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31875 a95241bf-73f2-0310-859d-f6bbb57e9c96
and its own version of a BTabView. This worked correctly on beos, but since it
hardcoded some things, didn't look correct on haiku (due to the new look).
I just removed the layouting code, and adapted the rest to fit well.
This fixed the weird white line which was
showing up. Note that the jpeg2000 translator needs to be fixed in the same way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31871 a95241bf-73f2-0310-859d-f6bbb57e9c96
Damn my hardware only supports 20bits input, though this explains why it doesn't work with 24bits input..
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31867 a95241bf-73f2-0310-859d-f6bbb57e9c96
a sub transaction, or else we would try to continue using it.
* It doesn't make any sense to increase fUnwrittenTransactions when
_WriteTransactionToLog() failed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31857 a95241bf-73f2-0310-859d-f6bbb57e9c96
leading BFS to report success on actually failed transactions. Those
transactions were even kept open, leading to a panic when starting the next
transaction.
* Transaction::Done() now returns a status - currently, this is only handled
correctly where this is likely to happen without a disk fault, ie. if the
transaction was too large to be written back safely.
* Improved "bfs_journal" command output.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31850 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Make the key arrays take the full range of possible index values (32-bits).
* Forward all unmapped keys with their HID usage as keycode.
* Remove some superflous debug output.
With this many of the extra keys on keyboards should be forwarded as unmapped
keys. An application could now watch for them (B_UNMAPPED_KEY{UP|DOWN} messages)
and interpret them based on their keycode which matches the HID usage.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31838 a95241bf-73f2-0310-859d-f6bbb57e9c96
throughout the code.
* Got rid of the transactions - they weren't really used, and thus only created
unnecessary overhead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31836 a95241bf-73f2-0310-859d-f6bbb57e9c96
Tracker's OpenHashTable.h which it should eventually replace. We've renamed the
class to BOpenHashTable and changed the interface slightly so that HashTableLink
became superfluous.
Adapted all the code that used it. Since the OpenHashTables no longer clash,
this should fix the GCC4 build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31791 a95241bf-73f2-0310-859d-f6bbb57e9c96
introduced earlier.
* Reworked the previous device classes to make them ProtocolHandlers handling
their respective input_server <-> driver protocol.
* Implement setting report item data and building/sending reports based on that.
* Remove the old HID parsing code.
This enables us to use all HID devices as we now parse and use the HID
descriptors/reports. Non-boot-porotocol devices should therefore work.
The next step will be to implement a generic input/output framework in userland
that can communicate with a generic protocol handler in usb_hid. This will then
enable applications to make use of all the non-mapped HID stuff directly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31790 a95241bf-73f2-0310-859d-f6bbb57e9c96
actually relies on that.
* Instead, _RemoveInvalidNode() now manipulates the parent tree manually.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31774 a95241bf-73f2-0310-859d-f6bbb57e9c96
could cause a KDL.
* Added a "force" argument to Inode::Remove() which should make it remove inodes
more reliably for checkfs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31773 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The "index" was not correctly updated when the next indirect block was about
to be used, which lead the code to write the runs to a wrong block, causing
slight corruption, as well as the known invalid block_run(0,0,0) problem.
* blocksRequested is now always a multiple of "minimum" as well.
* When the file size grew beyond the max_double_indirect_range, the minimum was
not adjusted, leading to too many extra allocations that had to be reverted
afterwards again.
* If an allocation was not a multiple of NUM_ARRAY_BLOCKS, but also smaller than
this limit (could happen due to the bug above), an endless loop could be
entered. This was actually a regression introduced in r974.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31767 a95241bf-73f2-0310-859d-f6bbb57e9c96
access the block bitmap out of bounds (which usually resulted in a crash).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31749 a95241bf-73f2-0310-859d-f6bbb57e9c96
efi_gpt_validate_create_child() hooks.
* Implemented setting the name to the partition for real.
* Implemented to_ucs2().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31712 a95241bf-73f2-0310-859d-f6bbb57e9c96
that we lost a few keystrokes, and would make keys (like SysReq) stick.
Thanks to Rene for the note!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31688 a95241bf-73f2-0310-859d-f6bbb57e9c96
turn Print-Screen into SysReq. Now, getting into the debugger works via USB
keyboards as well.
* I switched the break/pause key detection to Alt, too, although I could not
find any such mechanism on PS/2 keyboards. Someone knows better how to deal
with this one? (the key actually produces two scancodes, 0x1d + 0x45 on PS/2
keyboards)
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31670 a95241bf-73f2-0310-859d-f6bbb57e9c96
probably meant to be. The call as it was made no sense at all, as it hardcoded
the endpoint number and tried to supply data to a non-data request. It also
wasn't using a synchronous call, possibly triggering the callback function with
an incompletely set-up device structure, depending on how quickly the request
would return. This caused bug #4107.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31666 a95241bf-73f2-0310-859d-f6bbb57e9c96
patch from about a year ago (I couldn't use any code of his yet, though,
but there are a few things left). The emergency keys are triggered by
pressing Alt-SysReq + key.
* By default, only Alt-SysReq+'d' is used as a means to deliberately enter
the kernel debugger. F12 belongs to userland again, now :-)
* Debugger add-ons now have another optional method to implement their own
emergency keys - 'd' for the debugger cannot be overridden, though.
* The mechanism can be turned off via a new kernel setting, so it's not that
easy anymore to "crash" Haiku if you don't want to.
* Right now, the PS/2 driver, and the pre-input_server in-kernel debugger
keyboard mini-driver support this, USB not yet.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31660 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added missing name parameter to the partitioning system module child creation
and child creation validation hooks. Pass the name to them.
* Added BPartitionParameterEditor interface, which is/will be used for editing
disk system specific parameters.
* Implemented partition parameter editors for BFS initialization and Intel
partition map child creation.
* Fixed the incorrect supported child partition type iteration in the Intel
partition map add-on. It does now return actual types.
* Handle the "active" flag parameter in the Intel partitioning system module.
* DriveSetup:
- Replaced the "Create" submenu by a simple menu item. The type can now by
chosen in the dialog.
- Make use of initialization and child creation parameter editors. Some
non-generic code has been moved to the respective editor implementations
(BFS, intel partitioning system).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31658 a95241bf-73f2-0310-859d-f6bbb57e9c96
AVStream does not provide it. For my test Flash Videos, I can at least get
a duration now, although seeking is pretty broken.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31616 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Seeking does not work, since the duration extraction from libavformat does
not work for this container (maybe there are ways/workarounds but I didn't
look into it).
* Automatic white space cleanup.
TODO: Add MIME type with sniffer rule.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31605 a95241bf-73f2-0310-859d-f6bbb57e9c96
audio format is now taken into account by the decoder when negociating the media output format.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31597 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed the broken character conversion functions of the Haiku "port".
Instead map the 4 unused wchar/locale support functions to panic().
Eventually we might want to provide minimalistic wchar support in the kernel
instead, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31596 a95241bf-73f2-0310-859d-f6bbb57e9c96
non-ambiguous names (as pointed out by Ingo).
- This file has a lot of code that is Haiku only and is not in the original
ntfs-3g code. maybe we should try to clean this up and merge the changes
upstream.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31592 a95241bf-73f2-0310-859d-f6bbb57e9c96
size of wchar was 16 bits, which was not true anymore after recent changes.
- Considering the changes were inside libntfs, which is 3rd party code, I am
not sure this is the correct way to apply this fix (if you have a better
idea, let me know.
- This fixes bug #4075.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31589 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added new protocol method process_ancillary_data_no_container() that does not
need a container to fill the cmsghdr data.
* Added support for the IP_RECVDSTADDR option using this call.
* Implemented support for IP_MULTICAST_IF.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31585 a95241bf-73f2-0310-859d-f6bbb57e9c96
the HAIKU_FFMPEG_DEFINES and friends to the toplevel ffmpeg Jamfile.
* Define the X86 CPU acceleration features in global Jamfile variables,
so that we can build specific source files depending on those defines
later (used for libavcodec_x86.a).
* In config.h, a whole bunch of parsers were defined off, which was the
actual reason why plain old .MPG files and also my .MTS streams with
H.264 video gave only scrambled video.
* Removed some files from the build by comparing which files are build
by a pristine FFmpeg libavcodec Makefile.
Attention: The following changes may break the GCC2 build:
* Remove Haiku specific changes from
- libavcodec/x86/cavsdsp_mmx.c
- libavcodec/x86/dsputil_mmx.c
- libavcodec/x86/h264dsp_mmx.c
I will test this next after switching my GCC. If you are impatiant, the
following changes were previously done to the pristine FFmpeg 0.5 files:
libavcodec/x86/cavsdsp_mmx.c:
* commented out line 426 to 429
libavcodec/x86/h264dsp_mmx.c
* h264_loop_filter_strength_mmx2() was commented out.
libavcodec/x86/dsputil_mmx.c
* gmc_mmx() was commented out.
* commented out line 2665 (assigning c->gmc)
* commented out line 2786 (assigning c->h264_loop_filter_strength)
However, I would now make similar changes by checking the GCC version. Also,
the libavcodec/x86/dsputil_mmx.c:2786 was still assigning the dummy
h264_loop_filter_strength_mmx2() version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31506 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved Seek(). If wence is not SEEK_SET, make sure to check the current
source position and adjust it to what the stream points to. Also, return
just -1 on error since this is used for libavformat code. And don't set
the stream position to the error return value.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31504 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debugging facility to dump the first 100 packets of a video stream
to a debug file on the Desktop.
* When needing to flush packets, avcodec_flush_buffers() is unfortunately
not reliable. For audio codecs, the work around was to close and reopen
the codec in Seek(). Do this also for video codecs. Makes H.264 more
reliable here.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31503 a95241bf-73f2-0310-859d-f6bbb57e9c96
TODO:
- Move watching stuff from driver to device cookie so it can be used by multiple instances.
- Find out why we only get notified about AC / battery changes.
- Fetch _BMD info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31483 a95241bf-73f2-0310-859d-f6bbb57e9c96
- The timeout in Wait was ignored because B_RELATIVE_TIMEOUT was missing.
- Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31482 a95241bf-73f2-0310-859d-f6bbb57e9c96
Doing it on demand in AcpiOsExecute leads to kernel panic on my machine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31481 a95241bf-73f2-0310-859d-f6bbb57e9c96
KPartition::CreateChild(). CreateChild() calls AddChild(), which publishes
the new partition, though at that point offset and size were not set, so that
the published devices would not be usable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31463 a95241bf-73f2-0310-859d-f6bbb57e9c96
* We can actually tell libavformat to discard packets for streams that
we are not interested in. Found this in the ffplay code. This should hopefully
avoid the efficiency impact of using one AVFormatContext per stream.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored NegotiateOutputFormat() and Decode() into two separate private
methods each, one for video and one for audio.
* Keep reading chunks when video decoding, until we have got a picture. This
gets us scrambled video instead of a black picture for h264 in mpegts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31457 a95241bf-73f2-0310-859d-f6bbb57e9c96
context has AVPrograms. I gather this feature is for container streams
that contain multiple "groups of streams" like how it would work for
satilite mpeg-ts streams with multiple TV channels in one stream. For this
to be properly supported, we should extend the BMediaFile/Track API. For
now, the AVFormatReader uses the first program, if one is there. This
was also needed to get make mpegts demuxer work, but it is not yet enabled
for other reasons.
* Read more probe data. 1024 bytes were not enough to detect "mpegts" properly
for example.
* For now, I disabled the locking in the AVFormatReader hooks themselves,
this should not be necessary, though I hope libavformat is reentrant as
long as you have your own AVFormatContext for each thread. So far everything
hints that it is the case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31454 a95241bf-73f2-0310-859d-f6bbb57e9c96
we need to parse the "Unrecognized Type ..." strings we produce for partition
type IDs we can't match to a name. This fixes the "Failed to prepare
modifications" error the userland tools would produce when a partition with
such a type was encountered.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31453 a95241bf-73f2-0310-859d-f6bbb57e9c96
just architecture specific flags, call them just HAIKU_FFMPEG_DEFINES.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31432 a95241bf-73f2-0310-859d-f6bbb57e9c96
how everything currently worked. (Packet peaking was only done once in Init().)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31423 a95241bf-73f2-0310-859d-f6bbb57e9c96
container formats we support. I hope I have turned on only those that don't
have an implementation already (did we support ASF already?). I mostly tested
with AVI and that works reasonably well, but I only tested raw audio so far.
However, the backend for Marcus' avi_reader is much nicer than FFmpeg, so I
think it should stay and have disabled the support for AVI in AVFormatReader.
A big disappointment is that MPG containers only give scrambled video. It may
be a problem of the AVCodecDecoder, but I am not so sure. After all, it works
fine for other container formats. If I am not mistaken, VLC also does not use
the mpeg demuxer from FFmpeg. :-\ On top of that, libavformat detects the
time_base and stream duration wrongly for one of my test MPGs.
As for the implementation: Although seeking in libavformat happens for an
individual stream, in reality, the packets for all other streams need to be
flushed (that's also what happens in the libavformat tutorials I've seen).
Since our MediaKit API allows to seek tracks indivually, this is of course
a no-go, since then all other tracks would be out of sync. My solution is to
simply open the demuxer once for each stream and then completely ignore the
packets of the respective other streams. This also works around the problem
that libavformat is unable to provide packets by stream, requiring the
API user to queue the packets that he needs not now, but later for other
streams. It also means we have to no memory copies, since we can directly
use the packet buffer until the next call to GetNextChunk().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31421 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved stuff from testing in Sniff() into class members.
* Added function to gfx_utils() that converts an FFmpeg pix_fmt to color_space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31402 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The URLProtocol idea seems not to work out, so I removed that code, but
the other idea of setting up a ByteIOContext actually works, once I seek
back to the beginning of the stream after reading the initial probe buffer,
we may also offset the buffer pointer in the ByteIOContext to where we
have already read, but I am not sure of possible side effects of that.
We can now probe for the correct demuxer and detect streams.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31379 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Turn off tracing in the AVCodecDecoder which I accidentally turned on in
a previous commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31366 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed inclusion of internal.h from libavcodec.h, it's not there in the
plain FFmpeg 0.5 version of the file.
The last item fixes the GCC2 build, at least AFAICT.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31364 a95241bf-73f2-0310-859d-f6bbb57e9c96
unified the Reader and Decoder plugins and renamed the add-on to "ffmpeg".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31358 a95241bf-73f2-0310-859d-f6bbb57e9c96
"ffmpeg" and export multiple plugin types from the same plugin (Decoder and
Reader).
* Work in progress on an libavformat based Reader plugin, does nothing yet.
* Moved config.h from libavcodec subfolder up one level, so that it's used
by libavformat as well. Adjusted libavutil/common.h accordingly.
* Turned off GPL code in config.h
* Turned off BeOS muxers in config.h
* Turned on HAVE_THREADS and HAVE_PTHREADS, although that is nowhere used
in the ffmpeg code (it appears).
* Indentation cleanup in avcodecplugin.h
I have built this with GCC4, but last night I built libavformat.a with GCC2
so I am hoping this doesn't break the GCC2 built.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31355 a95241bf-73f2-0310-859d-f6bbb57e9c96
