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
* 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
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
* Made sure the 80 character per line limit is honoured.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38370 a95241bf-73f2-0310-859d-f6bbb57e9c96
correctly.
* This should finally fix ticket #6454, but I keep it open until it's confirmed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38365 a95241bf-73f2-0310-859d-f6bbb57e9c96
didn't do that for broadcasts - this is still not a full solution as it won't
work for link layer broadcasts, but this should fix most DHCP problems.
* IPv4 multicast doesn't do that yet.
* Only send ICMP errors if it hasn't been a link layer broadcast.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38356 a95241bf-73f2-0310-859d-f6bbb57e9c96
DatagramSocket::AvailableData() locks; introduced a UdpEndpoint::Dump() method
to work around that.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38355 a95241bf-73f2-0310-859d-f6bbb57e9c96
This allows to use lower resolution screen modes with black border.
Added a set of TODOs :
* The smaller scren is not centered, but aligned top-left
* The base resolution used is the one reported from edid 1.1, because I'm still not sure how to parse EDID 1.2. This resolution is too small on my laptop, but it works.
Also added two ways of setting 8-to-6 dithering for 18-bit LVDS panel. No visible result for me, unfortunately.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38354 a95241bf-73f2-0310-859d-f6bbb57e9c96
The future cookie was leaked in three of four error scenarios.
Backported from grackle.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38345 a95241bf-73f2-0310-859d-f6bbb57e9c96
Based on Motorola MPC106 User Manual and NetBSD's
src/sys/arch/macppc/pci/grackle.c 1.11. The MPC106 apparently deviates by
requiring the E (enable) bit set to 1 for config read/write to work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38344 a95241bf-73f2-0310-859d-f6bbb57e9c96
First B_MEDIA_SEEK_TO_FRAME was handled to compute a time, then
it was ignored and frame was used as time stamp. Also the
conversion from frame to time had the num and den members of
the time base swapped in the computation, so it computed
bogus time stamps. Refactored the conversion methods, always
seek based on the time. Needs more testing (perhaps there are rounding
issues), but overriding a lot of native reader implementations with
AVFormatReader holds up very well now with a lot of files I tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38332 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Read the EDID info on both port A (analog VGA monitor) and C (LVDS panel)
* If an LVDS panel is detected, report the EDID resolutions instead of the BIOs settings
This fixes#6326, likely #5096, and possibly some others intel_extreme problems. Please test.
On the other hand, this make the screen preflet show the full list of more reported by the LVDS panel. As we don't support
scaling, some of these modes are unuseable and lead to a garbled screen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38329 a95241bf-73f2-0310-859d-f6bbb57e9c96
A grackle-compatible Motorola MPC106 PCI controller can be found in the
PowerMac G3 (ticket #6247). For now just let the user know.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38323 a95241bf-73f2-0310-859d-f6bbb57e9c96
