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
buffer). These are the sequences our /etc/termcap uses (local less and
vim use the alternative screen buffer now). The ones already implemented
are used e.g. by the termcap of my Linux installation. A bit weird all
those different termcap files, some even with the same version
number.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26031 a95241bf-73f2-0310-859d-f6bbb57e9c96
less.
* Added /etc/vim/vimrc. Besides fixing key mappings it also disables
compatibility mode and adjusts some settings to make using vi a more
pleasant experience.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26028 a95241bf-73f2-0310-859d-f6bbb57e9c96
2KB. That's the currently recommended size of the buffer passed to
tgetent(). Our xterm entry is bigger, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26023 a95241bf-73f2-0310-859d-f6bbb57e9c96
