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
can edit the settings file. The default are 10000 lines BTW.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26045 a95241bf-73f2-0310-859d-f6bbb57e9c96
selection which we update whenever the first mouse button is released.
This also enables copy'n'paste between Terminals.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26044 a95241bf-73f2-0310-859d-f6bbb57e9c96
updating the scroll range (ie: in ContainerWindow.cpp). IMO, the programatic ScrollBy method shouldn't depend on the
ScrollBars ranges or state. The original fix in r21336 was apparently hiding other BScrollBar or BView bugs that have been
fixed in the mean time.
The content was offseted when going back to list mode after moving icons on the left/up in icon mode. This fixes Tracker bug
#2312.
- Revert and fix changes to ContainerWindow.cpp in r18481 (cvs 1.37). The condition was broken, but it wouldn't ScrollBy()
anyway due to the previous problem. Fixing BView made the content autoscroll even if the lefttop corner of the extent was
already visible.
- Probably unrelated, fix changes to ContainerWindow.cpp in r18993 (cvs 1.38). PoseView()->Bounds().left/top < 0 is expected,
if for example in icon mode you move an icon close or crossing the left side of the window and then scroll left to adjust.
This fix ResizeToFit that wouldn't scroll the view correctly in some cases.
So we had a Tracker Bug uncovering a BView fix that was hiding another Tracker bug, everything is fixed hopefully, phew :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26043 a95241bf-73f2-0310-859d-f6bbb57e9c96
- we'll just use decimal chip number (68030, ...) to identify cpu, fpu, and mmu for simplicity.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26041 a95241bf-73f2-0310-859d-f6bbb57e9c96
the left/right cursor keys.
* Normalized the Ctrl-<cursor> escape sequences. Makes word navigation
in vim work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26038 a95241bf-73f2-0310-859d-f6bbb57e9c96
worker thread. That sounds somehow reasonable, but has the problem that
signals to the process hit a thread that doesn't know how to handle
them. Fortunately the author already prepared the code to switch the
thread tasks. In the Terminal vim does now correctly react on window
resizes. Probably also fixes#2393.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26034 a95241bf-73f2-0310-859d-f6bbb57e9c96
wrapped to the next line and a subsequent LF would advance another line.
We behave like xterm now, i.e. visually the cursor stays on the same
line (on the last character), but the next character will be wrapped to
the next line.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26033 a95241bf-73f2-0310-859d-f6bbb57e9c96
