* This gives us plenty of space for source packages.
* A Mini-DVD is 1.4 GiB, and USB sticks of 2 GiB are at
the sweet spot of low-price vs size.
* Unused space will be compressed in release zip.
* We blew by 700 MiB long ago. Sorry CD-R folks.
Change-Id: I3bbe4508777027f6fe7c0ee2992637541feeb88f
Fixes#13622.
The "media_node_framework" is such a huge mess. We really should sit down
and design a MediaKit2 someday that doesn't require ~15,000 lines of media
node support code just to have a "fully functioning media player."
It seems to be as if not faster than the built-in method now as far
as I can tell, and this means one less arch-specific difference.
I haven't ripped all of it out yet, though.
It has been deprecated since FFmpeg ~3.0, and is internally implemented
using these functions now, so this should largely be a no-op change.
AVCodecEncoder still uses it.
All of the functions it calls are deprecated and no longer needed,
as FFmpeg loads all codecs automatically now, and uses pthreads internally
for locking as needed.
From mmlr's analysis in #13370 comment:22: "We actually do ignore a missing
routing in case the interrupt line is 0. In this case it isn't 0 but 0xff,
which is invalid and generally treated the same as 0 in the rest of the code.
Ignoring the missing routing on 0xff seems like the way to go here."
Indeed, I managed to locate a footnote in the PCI 3.0 specification which
confirms that this is the case on x86, and a commit in the Linux kernel
which essentially does the same thing this change does:
https://github.com/torvalds/linux/commit/e237a5518425155faa508a087f2826
Interestingly, that commit is only from 2016, while PCI 3.0 is from 2004.
This probably fixes#13370 ("Haiku doesn't MBR boot on Ryzen"), and potentially
other interrupt-routing-related boot failures.
Change-Id: I88129f6507c62d24cb50cf5c78597ca7bd7872d7
Reviewed-on: https://review.haiku-os.org/590
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* There was an off-by-one error in initialization code;
BRect(0, 0, 15, 15) does not create 16x16 bitmap - it is 15x15.
As a result vector icons were rendered at 15x15 and then scaled to
16x16.
Change-Id: If1b57148e5a887a4bf71e01606d3d0d6fd0ed149
Reviewed-on: https://review.haiku-os.org/585
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We do not know anything about the symbols we are being asked to demangle;
it is entirely possible they are malformed, or that we parse them incorrectly,
which previously led to buffer overflows. E.g. the "2","8" in "SetTo__Q28_GLOBAL_"
is presently incorrectly parsed as a length, leading to an access 21 bytes past
the end of the string.
This caused a page fault under the guarded heap, a fact I had the misfortune
to discover when trying to attach Debugger to a guarded-heap'd application
which somehow ran the demangler under the guarded heap also, and that symbol
above was in runtime_loader, so it crashed while loading its symbols.
So now we do what the GCC3+ demangler does here, and keep track of the input
buffer through the use of a state class, which will prevent us from incrementing
past the buffer's end.
I've tested this patch using the new haikuc++filt utility against libtracker
(indeed, it took multiple rounds of testing to get the diff to be 0 bytes)
and it seems to work exactly as before, though now without out-of-bounds
accesses.
As this demangler is also used in the kernel, it's possible that some
triple-faults on x86_gcc2[h] are caused by this bug (although that would
be rare; one of the incorrectly-parsed symbols would have to be in the
stack trace, and then it would have to read past the end of the buffer
containing the symbol.)
Change-Id: I343991cebd7d2887812c8c6b3dc2e0df2fcd79fa
Reviewed-on: https://review.haiku-os.org/579
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Built as "haikuc++filt" so you can keep it in PATH without replacing GCC's.
The implementation is a very close copy of "demumble", which is
under the Apache 2 license, so this is also. Most of the modifications
to "demumble" were to strip out Windows symbol support, and then
add GCC2 symbol support (this required reworking of the main loop,
as we detect GCC2 symbols in a different way than Itanium symbols.)
I've also added a command-line flag to ignore GCC2 symbols when stream-
processing, which is sometimes useful when demangling GCC3+ symbols.
Running this under guarded heap with some random SOs shows that there are
some symbols which apparently cause memory corruption in the GCC2 demangler.
I haven't yet looked into that, though.
They may still be running at the point we detach from the window, and
as we stop watching everything else at that point (and the threads
themselves depend on the window looper as the global "lock"), we
need to tear them down then.
We especially cannot do this in the destructor, as there are some
virtual methods that the threads need during their teardown which
obviously will not work in ~BPoseView.
Fixes#13371, and potentially other Tracker crashes that occured
as a result of closing the window while the add-poses tasks were
still operational.
Change-Id: Ib7ec0d1d413096be899a05887399f5b087eb8f99
Reviewed-on: https://review.haiku-os.org/574
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes the tests added in the previous commit, and also #8552.
Change-Id: Idf9459474bc66054f94cf66065ed6fcf9c60cece
Reviewed-on: https://review.haiku-os.org/572
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BeOS R5 treats NULL passed as the "replace with" argument as if it were
an empty string. Our BString currently does nothing.
Change-Id: I54b661e4ea8335ce531e6b6e3de2095a41112cd7
Reviewed-on: https://review.haiku-os.org/571
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When HEAD is tagged, the output will be identical to what it was
before (the latest hrev tag and nothing else.) When HEAD is not tagged,
and the most recent tag is further back, we now use a format like this:
hrevXXXXX+N(+dirty)
... where N is the number of commits since hrevXXXXX, and +dirty is added
if the working tree is dirty. This is significantly shorter than the
previous model (as it does not have the Git revision.)
Fixes#14445.
Change-Id: Ide7f66cf0ac1c1f05402afc52b6be3b68b66d6dc
Reviewed-on: https://review.haiku-os.org/566
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The action vm_page_fault takes should depend on whether the iframe to be
handled is a user iframe or not. The check for the user flag in the
error code does however only check if the fault happend in user or
kernel space. Use IFRAME_IS_USER() instead which checks the privilege
level of the iframe. Under 32 bit x86 this also handles vm86
compatibility mode properly.
This is the same logic as used on FreeBSD (TRAPF_USERMODE).
Fixes#13930.
Change-Id: I9c348b6ab4c60daaaaa2c0fe33bcc3336aa29f7b
Reviewed-on: https://review.haiku-os.org/560
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Patch by Pete Goodeve, ticket #9134.
(Removed play_sample_rate and record_sample_rate as suggested in
patch review, adjusted hda.settings accordingly.)
Tune buffer size and buffer count with an optional settings file
/boot/home/config/settings/kernel/drivers/hda.settings. Same as
it's done for the auich driver.
Pete:
> I [...] request 4 buffers of 1024 frames, I get a nice 13-14ms latency.
Change-Id: I3c1c64375d22b525afb970d5e8379b22b8514438
Reviewed-on: https://review.haiku-os.org/521
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Thanks Axel and Jerome for the reviews!
Change-Id: I4f116c540cf59ba74b79d9d2f95ed40edc9c4174
Reviewed-on: https://review.haiku-os.org/557
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes#12034, and a variety of other strange "no wireless networks
appear" bugs that have plagued Haiku for years.
Change-Id: I734cb8084e8a626b8e03511519609bf80c1559eb
Reviewed-on: https://review.haiku-os.org/552
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This depends on the previous commit to return the correct error code
from ioctl().
If there are no VAPs running (which is the case after a forced disconnect
from an access point), scans will fail. In that case, we call
IEEE80211_IOC_HAIKU_COMPAT_WLAN_UP, which will restart a VAP, and then
initiate the scan.
Change-Id: I732aefe67e386dbb0ed3d232ed9deda678132601
Reviewed-on: https://review.haiku-os.org/551
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, if a device driver returned an error of any kind, -1 was
propagated the rest of the way up through the stack instead of the
actual error code.
Change-Id: I6839763c6b2eb86d6112d3732e6cb80d022f1fe8
Reviewed-on: https://review.haiku-os.org/550
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* _VirtualWidth() ignores invisible columns
This makes the horizontal scrollbar match the width of the visible columns.
Also trigger an initial update of the scrollbars.
* Fixes#14480
Change-Id: I7d4b27a8fdca58c150ac47f9b948b127fb275fdf
Reviewed-on: https://review.haiku-os.org/543
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
This fixes the (intermittently) crashing test added in the previous commit,
and should also fix#12024 and #14348.
Note that this is a slight behavioral departure from BeOS, though since
BeOS crashed when this was done previously, it shouldn't cause any
other problems.
Change-Id: I90b6132ff7741b8d6cb601375a9b11fc3ffacb40
Reviewed-on: https://review.haiku-os.org/541
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Adds/removes items as rapidly as possible from the menu from the
main thread while the menu is open. That part works. Then it deletes
all of the BMenuItems and then closes the menu, which crashes,
as the BMenuItems do not notify the BMenu they are being deleted.
I tested this on BeOS and it seems that this model crashes there also
(looking through the code comments, it seems there are a number of
testcases found throughout the years like this.) Removing the items
before deleting them indeed fixes the crashes on both BeOS
and Haiku.
Change-Id: I8624f966bdc17030ddca05b97aa57b518ab420c5
Reviewed-on: https://review.haiku-os.org/540
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
...if the row is present in the list, but continue to return false if the
row is not currently visible on the screen.
Part of #11675. Cherry-picked from https://review.haiku-os.org/442.
BFS does this as part of journal management, but not as part of block
cache synchronization (which makes sense, as flushing it then would
defeat the purpose of the drive's write cache.) No other file system
seems to touch it at all, so we should do it as part of an explicit sync.
This may help with some of the filesystem corruption issues, as it seems
that on slow disks, the drive might not have enough time to flush the cache
before it is powered off (or on some SATA/AHCI based disks, it is not flushed
before close at all), so triggering it here and, as the ioctl is supposed to be
synchronous, waiting for it also, seems to make sense.
Change-Id: I7d9992c21ca4b59c839711dcc96c973b4b8df052
Reviewed-on: https://review.haiku-os.org/530
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* The difference is visible when control background doesn't match
panel background.
Change-Id: Ie3a034acaa52929becd6601520e0e05f32ecc8d8
Reviewed-on: https://review.haiku-os.org/537
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When URLs combine a base URL with a relative part, the relative part's
path component was being pre-processed. This removed any ".." from the
path and in some cases in the unit test cases, the ".." should have been
retained and then only later applied to the base URL. This changes
fixes this so that the relative part is not pre-processed and is applied
with it's path in a raw state.
Completes Fixes for #14377
Change-Id: I9cebb8599889494e11f40a3b54c87ebca3ed1a21
Reviewed-on: https://review.haiku-os.org/529
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Here's what happens:
* BPackageManager created a BRefreshRepositoryRequest with a BContext
of an empty DecisionProvider and itself.
* Since there is no internet access, the FetchFileJobs that the refresh
class queued fail. Specifically, the first one does, but then as the
subsequent ones depend on it, they are all aborted.
* As some jobs were aborted, the StateListener is notified.
* The state listener of course has the BPackageManager class as one of
the listeners, and so calls it, because even though the handler methods
of BRefreshRepositoryRequest, they are powerless to stop event propagation.
* The BPackageManager's highest subclass' implementation gets called, which is
of course pkgman's.
* pkgman decides to DIE() upon receiving word that a job was aborted.
There are thus four potential solutions to this issue:
* Rewrite the package kit's event & job handling systems to not be so
screwed up in terms of propagation. Seriously, there is way too much
stuff that we send to the "user" in here, and as you can see, it can
get *extremely* convoluted even for supposedly "simple" tasks. This
is probably the best "long-term" solution; but obviously is far too
involved for the present.
* Only partially rework event handling; specifically in the SupportKit to
allow JobStateListeners to stop further propagation. This is probably
the best "medium-term" solution.
* Do not pass the package manager as the JobStateListener to the
RefreshRepositoryRequest. This would have the downside that the
regular notifications about download state, etc. would not be returned
at all, which we don't want. We could make a shim ... but that would be
a lot of code for little benefit. The prior solution makes more sense.
* Completely ignore "JobAborted" notices in pkgman. In fact, this is the
solution that virtually all other consumers of this API take (although
some of them seem to have TODOs about it), including package_daemon,
HaikuDepot, etc., and so it's the one I've taken here. If a "job aborted"
error is actually fatal, then it's the Package Kit's problem.
Fixes#13075.
"Elementary streams" were introduced with MPEG-2, but did not find much use
outside of internal data interchange until now, which finds some HEVC
files being actually distributed in this format.
The first four bytes (00 00 00 01) are common to all (packetized?) elementary
streams, while the three following (40 01 0c) identify a HEVC stream. Actually
I could not find good data on these; all the HEVC files I saw (and some hex-
dumps on online mailing lists of more) contain these three bytes in common
while following ones appear to be the internal header. (I didn't dig deeply
enough into FFmpeg's source code to find out the "real deal.")
Fixes#12565.
