a bit.
* This also fixes a bug Salvatore pointed me to: Vnode would also call
put_vnode() on destruction if get_vnode() failed earlier.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26097 a95241bf-73f2-0310-859d-f6bbb57e9c96
- kernel_m68K almost links now, jsut bails out on the linker script...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26096 a95241bf-73f2-0310-859d-f6bbb57e9c96
hanging systems on boot, but probably just hides a problem somewhere else, as
the transfers should timeout on their own if the device doesn't respond.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26082 a95241bf-73f2-0310-859d-f6bbb57e9c96
unit attention telling us that the device or media status changed, which is
expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26081 a95241bf-73f2-0310-859d-f6bbb57e9c96
the select/deselect/readv/writev hooks. Not that it would matter as the static
memory there is cleared to 0 anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26080 a95241bf-73f2-0310-859d-f6bbb57e9c96
hook from the legacy driver.
* Add note explaining why it is set to an arbitrary invalid value (~0) and why
it still works by redirecting in the virtual Select() of LegacyDevice.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26079 a95241bf-73f2-0310-859d-f6bbb57e9c96
source bitmaps. The destination is preserved now when encountering such
transparent pixels in the source bitmaps.
* B_OP_ERASE is supposed to replace with the low color whereever a source
bitmap has a non-transparent pixel.
* The B_OP_MIN and B_OP_MAX drawing modes are supposed to select either the
source or destination pixel based on their brightness, not combine the two
pixels' color components into a new pixel. The brightness_for() function is
taken from ColorConversion.cpp in the interface kit. Probably a simpler
algorithm would do as well.
* Handle B_TRANSPARENT_MAGIC_* in all cases when drawing bitmaps with non-alpha
source bitmaps, as all modes except B_OP_COPY are sensitive to transparency.
This should make all drawing modes behave as documented in the BeBook. Except
for B_OP_SELECT, which seems broken under R5, the results compare nicely now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26075 a95241bf-73f2-0310-859d-f6bbb57e9c96
to draw a bitmap and a B_MIXED_COLORS pattern. This shows that most of the
Haiku drawing modes are off of what the BeBook documents them to be and also
shows that B_OP_SELECT is actually broken under R5.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26074 a95241bf-73f2-0310-859d-f6bbb57e9c96
level 2).
* merge_cache_with_only_consumer() marked the source cache unbusy when
it was done, which caused a race condition with the page fault code.
I accidentally introduced this problem in r25716. Fixes#2326.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26068 a95241bf-73f2-0310-859d-f6bbb57e9c96
bitmaps in B_OP_INVERT mode does not affect pixels where the source bitmap
was transparent, as noted in the BeBook. Not really sure I'm doing that right
though and probably needs looking into for B_OP_ERASE and B_OP_SELECT too.
Fixes bug #2421 though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26067 a95241bf-73f2-0310-859d-f6bbb57e9c96
a volume to the audio data. It ramps between a previous and the current volume
if necessary to smooth out the changes. The volume slider functionality is
thereby restored.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26066 a95241bf-73f2-0310-859d-f6bbb57e9c96
include the OSS media add-on (node), since Haiku comes with it's own
version. Therefor you can now add the OpenSound optional package and
it will just work out of the box, unless you have native drivers that
fight over the hardware with OSS. It is no longer necessary to delete
the opensound.media_addon from the home/config/add-ons/media folder.
If you don't build from scratch, make sure you delete
generated/download/OpenSound.zip or the change won't take effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26064 a95241bf-73f2-0310-859d-f6bbb57e9c96
perfect in Haiku for me (HD Audio), while it adds a very noticable latency.
On C-Media, the difference between "policy 4" and "policy 5" is 2048 versus
32768 bytes, which is 16 times the latency. I added a note on why the same
policy on Haiku might give me troubles (C-Media versus HD Audio means
16 bits/sample versus 32 bits/sample) and if OSS does not double the buffer
size then I can see where the trouble is comming from. I should probably
figure out a more fine grained way of influencing the driver buffer size.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26062 a95241bf-73f2-0310-859d-f6bbb57e9c96
C-Media based sound card). In Haiku, I could test with HD Audio, and playback
has clicks. It doesn't seem to have to do with the "drift", which is now
correctly published, I am not sure what exactly is causing it, I would like to
test on different hardware yet.
* I have modified the buffering policy (4 will give about 2048 bytes internal
OSS buffer), which decreases the latency of the node to an acceptable value.
* I completely replaced the timesource publishing algo to be more reliable.
* Removed now unnecessary methods from OpenSoundDeviceEngine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26059 a95241bf-73f2-0310-859d-f6bbb57e9c96
the scrollbar.
* Added notes about BeOS behavior to SetTarget(const char*).
* Reuse SetTarget(NULL) in the destructor.
* Initialize fTarget and fTargetName in the archive constructor.
* Added TODO about possibly restoring the target in the archive constructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26057 a95241bf-73f2-0310-859d-f6bbb57e9c96
