This fixes (a harmless) out of bounds array access, and CID 1359.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38423 a95241bf-73f2-0310-859d-f6bbb57e9c96
make much sense to wake up any waiters either in this case.
* Fixed doubled semaphore deletion.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38418 a95241bf-73f2-0310-859d-f6bbb57e9c96
around BLocaleRoster::GetAvailableTimeZonesForCountry()
* minor cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38412 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note this leads to KDL if there is a write error, so it may not be the best way for a floppy...
This allows the driver to uninitialize properly when all devices are unplugged, which in turns permits updating the driver without rebooting to unload it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38410 a95241bf-73f2-0310-859d-f6bbb57e9c96
discovered by Coverity for some reason): commands without arguments would
overwrite memory (in this case the sConsole::arg_count only, though).
* Travis's copyright was missing in blue_screen.cpp.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38409 a95241bf-73f2-0310-859d-f6bbb57e9c96
The floppy icon is based on zumi's one. changes done :
* I made the floppy a bit thinner, it looked more like a zip100 cartridge
* I added an USB logo (or something that more or less looks like one) on the floppy label
* The logo only shows at big icon sizes since I couldn't get it looking good at small ones.
Feel free to improve.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38407 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Write operation will always return an error, one needs to send request sense until the write is actually done.
This gets floppy writing working.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38406 a95241bf-73f2-0310-859d-f6bbb57e9c96
This gets read capaity working, the device shows up in drivesetup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38404 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed the mp3_reader and mp3_decoder from the image and from
the source tree even. The mpeg123lib based decoder was crashy,
since the lib didn't cope with bad input data too well, whatever
the reason, but bad input can also be a specially crafted file.
I didn't see the value in keeping two decoders around that use
a third party library as backend. While reading in the mp3_decoder
code, I even saw that it used global variables in the mpeg123 lib
to figure out framerate and channel count, after decoding a bit of
input. Obviously this has concurrency issues.
* Removed the mp4_reader from the image. It is native code, and should
perhaps be preferred over imported code, but I don't have the
resources to look into it, and David doesn't seem to have the time
either. There are basically three types of problems with the
native mp4 reader: 1) It is way too CPU intensive. I have many HD
files that don't play at all, since there is not enough time left
for actual decoding. 2) Seeking leaves a lot of visual artifacts
(with the very same decoder plug-in), since there seems something
wrong either with finding true keyframes, or with flushing buffers
correctly. And 3) very often audio stops working at all after
seeking. Sometimes a keyframe is returned for audio which is very
far away from the wanted frame, which currently triggers bad
behavior in the audio producer node in MediaPlayer and can even
crash the media_addon_server. With the ffmpeg based mp4 reader,
none of these problems exist: Seeking is perfect, no artifacts,
CPU load is low enough for pretty much all HD clips I tested with,
and audio always works and is always in perfect sync with the video
after seeking.
If there are regressions after this commit at all (I tested a lot of
files), then I anticipate only that the ffmpeg plugin does not advertise
support for files it could actually handle (i.e. easily fixable). In
those cases hopefully a test stream can be made available. If the
native mp4 reader is improved to the point that it works as well as
the ffmpeg mp4 demuxer, we can easily switch it back, but for now, users
will prefer reliable playback.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38403 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Ask the drive for its status after each command we send, or else it locks up
THis get us as far as trying to read the drive capacity, but this still fails for some reason.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38402 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Output more information in AVFormatReader::StreamCookie::Open(),
AVInputFormat flags for example.
* Added CODEC_ID_AAC handling when codecTag is 0. Adds support
for AAC in Matroska containers when the ffmpeg plugin is enabled
to handle those.
* Added some rounding to frame<->time conversions.
* AVFormatReader::StreamCookie::Seek() forgot to pass the seek
flags to av_seek_frame().
* The most important fix is this, though: There are formats which
build the keyframe index on the fly, while parsing the stream!!
These means we can only seek to real keyframes for parts of the
stream that has already been decoded. Handle this situation by
assuming we can seek to the requested frame/time. This change
fixes the use of the AVFormatReader as MP3 reader.
* Anothe important fix is to ignore the nb_frames member of the
stream for the total frame count. This makes MP4 movies
also work perfectly now when the AVFormatReader is used for them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38401 a95241bf-73f2-0310-859d-f6bbb57e9c96
gives the deprecated warning... We need to cache an AVPacket for this.
* Check the allocation of fOutputBuffer.
* When seeking, we need to flush the already decoded stuff
in fOutputBuffer, and throw away the last chunk buffer as well.
* Handle an incomplete input format at least to the point of not
crashing with a divide error (mp3_reader would give us such an
incomplete format for example).
* _DecodeAudio():
- Fixed some edge cases in the audio decoding loop: avcodec_decode_audio3()
can return a 0 length, which means no error, but no decoded frames
either. ffplay throws away the chunk in this case, do the same.
- Convert some invalid situations that were printf()s into debugger()s.
- Add much more comments to explain how everything works.
* Fixed the occasional coding style issue.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38400 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Move the interrupt stuff inside the device structure
* Some cleanup, added some more tracing fordebug purposes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38399 a95241bf-73f2-0310-859d-f6bbb57e9c96
to endpoints. This should help with the final issues of bug #6454.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38397 a95241bf-73f2-0310-859d-f6bbb57e9c96
layer.
* Converted the hash used to the BOpenHashTable instead of khash.
* Fixed remaining GCC4 warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38391 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When writing encoded audio, we were leaking one
temporary buffer per chunk.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38388 a95241bf-73f2-0310-859d-f6bbb57e9c96
drawing whitespace at the start of a line but the behaviour is not perfect yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38387 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Check for errors using != instead of < - the functions are not supposed to
return anything above B_OK.
* Use the stack-wide ENABLE_DEBUGGER_COMMANDS instead of our own local solution.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38386 a95241bf-73f2-0310-859d-f6bbb57e9c96
trying to build the compiler when it's not going to work
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38384 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed another instance of BToolTip deletion, when we should be releasing
a reference instead (the first one was fixed by Rene - thanks BTW!)
* brought BCountry back into the game, such that the localized name of the
country is now being used, where possible (avoiding the " Time" suffixes
in English)
* country-items containing only one timezone are now being filtered (the
timezone moves up one level, replacing the country item, but adopting
the country's name)
* added the date to the timezone-item's tooltip, in order to make it obvious
which timezone is "before" and which is "behind" the date-borderline
I'm pretty happy with how it works now - what's yet missing is conversion of
the preflet to the layout kit and localization of the GUI.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38382 a95241bf-73f2-0310-859d-f6bbb57e9c96
since we'd like to be able to get the timezones of the global (i.e. empty)
country, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38380 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is loosely based on usb_disk, but uses a different protocol for sending the commands.
Refactoring is unfinished, so don't look at the style too muh, it will e fixed and cleaned up later.
Basic communication with the drive works (sending commands). Command themselves still mostly untested.
Command Blocks sent to the drive are most likely wrong and may erase your floppies or do any other weird things!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38379 a95241bf-73f2-0310-859d-f6bbb57e9c96
the missing notifications.
* Renamed ieee80211_haiku.c to .cpp, and made it compile (this part requires
the updated GCC2, as it uses the ISO-C varargs macros).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38378 a95241bf-73f2-0310-859d-f6bbb57e9c96
to take into account the correct extra spacing around
the TitleView, as well the internal margin width that
the TitleView adds to the current column width sum for
its virtual width used to set the horizontal scrollbar
proportion. Introduced TitleView::MarginWidth() for that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38374 a95241bf-73f2-0310-859d-f6bbb57e9c96
removed rows in OutlineView::RemoveRow(BRow* row). It also
contained a bug (tracked down by Duggan in ticket #3897, thanks!)
which caused it to skip the sub-tree height computation when
FindParent() returns false, which it does for root items.
Now the computation is simple: The subTreeHeight is the height
of the row itself, if a) the row doesn't have a parent or b)
the parent is visible and expanded. Then if the row being removed
is expanded, we calculate the sub-tree height recursively.
Removed a lot of duplicated or even trippled checks along the
way and solved two easily solvable TODOs with regards to what is
invalidated. Previously the entire list view was invalidated
for each row being removed, even if they were scrolled out the
view bounds.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38372 a95241bf-73f2-0310-859d-f6bbb57e9c96
