Doesn't work yet though:
- we don't implement heap yet,
- non-color machines have 2bpp, so we'll have to hack this in some way.
Change-Id: Idf8f69c2256837db3915949d93265decbb43a524
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3097
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Those were found in the official headers in the NeXTstep ISO, how come I
didn't even look there in the first place?
We do get enough info to use the framebuffer, but sadly the SCSI IO
seems invalid. Both the NetBSD and even NeXTstep bootblock have their
own embedded drivers, maybe they didn't trust their own rom?
Change-Id: I0a47c433da89b15091644cd5c69ffff24d0cdd1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3096
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Since the boot ROM API structure is declared with a custom alignment, we
simulate it with padding bytes around, and use aligntest.prg to verify
using ARAnyM + TOS/MiNT as we know how to link simple PRG files.
It now prints something to the screen then panics when initializing the
heap.
For now one must insert the loader manually into an existing floppy
image:
dd if=generated-m68k/objects/haiku/m68k/release/system/boot/next_m68k/haiku_loader.next_m68k bs=$((0x8000)) seek=1 of=next_floppy.img conv=notrunc
Change-Id: I06d74e9d85a352aab68dedce545bbe5fe9e990d5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2220
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
FreeBSD doesn't have m68k anyway, so use fenv from musl with as less
changes as possible.
Not sure the 'hidden' define should go there.
Change-Id: I343f72d61dcacf7dfc180d112529f5a6521d7e3b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2213
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This enables generation of exceptions that are due to uncorrected
hardware errors. The exception handlers were already in place and will
now actually trigger kernel panics.
Note that this is the simplest form of MCE "handling" and does not add
anything of the broader machine check architecture (MCA) that also allow
reporting of corrected errors. As MCEs are generally hard to decode due
to their hardware specifity, this merely makes such problems more
obvious.
Might help to discern hardware issues in cases that would otherwise just
triple fault and cause a reboot.
Change-Id: I9e3a2640458f7c562066478d0ca90e3a46c3a325
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
... with the replicant tray below the menu bar.
Deskbar now has four modes:
1. vertical mini-mode (old mini-mode)
2. horizontal mini-mode (new mini-mode, was vertical)
3. vertical expando-mode (default)
4. horizonal expando-mode
Horizontal mini-mode gets the corner, then it switches to vertical
mini-mode above or below that, then to vertical expando-mode after
that. Horizontal expando mode is in center-screen top and bottom.
Clock vertical centering simplification.
Change-Id: I216008c20feb28f793693046792bbcfdf1e703e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3146
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Without it, the device can't operate at all. Whether or not this is
enabled already is firmware dependent. It was off under QEMU when used
with "-soundhw ac97" and this makes the driver work there.
Fixes#10551 where the syslog shows that this can also happen on real
hardware that is otherwise fully configured.
The BGradient class is a bit strange as it can store any gradient on its
own, butonly the subclasses allow to set some of the fields.
In the asignment operator, the non-base data (which is in an union) was
not copied over.
More importantly, the missing copy constructor led to the default
implementation being used, and BList (used for the color stops) was
being copied using its default copy constructor, resulting in the two
BGradient (original and copy) poinitng to the same stops data. Heap
corruption resulted whenever one of them was deleted.
Having a working copy ocnstructor fixes this. The alternative is making
the copy constructor private or protected to make sure gradients are not
copied, since normally you'd copy only the subclasses, preserving the
C++ type. However there is nothing enforcing that, and manipulating a
BGradient copied from a subclass works just fine.
Change-Id: I28e733eb8a2970b76ae623eabb75ef8435f508af
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3144
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The level parameter in the CopyEngine::CollectCopyInfo() and
CopyEngine::Copy() methods was introduced in hrev30395 to allow the CopyEngine
to decide which directories should be copied. Since then, this
class has been rewritten and it is no longer necessary for that purpose.
This change refactors the CopyEngine and removes the
level parameter from the class interface. Furthermore, it was broken to begin
with; it was passed as reference to the internal recursive _Copy() and
_CollectCopyInfo() methods, meaning they acted like a global counter. The
global counter was increased at the beginning and decreased at the end of those
methods. Execution could terminate early though, leaving the level counter out
of sync with the recursion level.
There is one use of the level parameter, namely in the
WorkerThread::EntryFilter::ShouldClobberFolder() method, but the use of the
parameter was wrong (it would have been at level 3 at the point of the check,
not level 2) and the logic is functional without the level check.
Change-Id: Id92ef89b015e9b1185bde061273f61e492664bce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3139
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
This was removed in hrev33708 when enabling the "double click to raise"
feature. It results in all clicks after the first one just raising the
team again.
Fixes#8471
Change-Id: I2c7a7bd25401900ee22f6bb953d055e28670776e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3108
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Preserve passed in text rect in fTextRext (unless in layout)
and create an internal version fAlignedTextRect which is used
in place of fTextRect. fAlignedTextRext is aligned to fit the
text rect bounds and grows to fit. fAlignedTextRect always grows
vertically but only grows horizontally if wrap is off.
Left-aligned text view's grow right, right-aligned ones grow left,
and center center aligned ones grow out.
Set fTextRect to bounds in _DoLayout().
Reduce left and right padding inside text views from full label
spacing to half label spacing. Unify padding between BTextControl
and BTextView.
Fixing padding also fixes right and center-aligned BTextViews.
Undo extra scrolling for non-left text views from hrev24130 fixing
a scrolling left and right with mouse bug when it shouldn't.
Replace max_c and min_c with std::max and std::min respectively.
Remove scrolling from one instance of BTextView::SetText as it
produced undesired results while editing a scrolled text view.
Set text rect in BTextControl::DoLayout() and ScreenSaver
PreviewView::AddPreview().
Don't add padding if BTextView::SetInsets() is called. Set insets
to 0 in Tracker "Edit name" setting which prevents default padding
from being added. This is so that when you rename a file in Tracker
the TextView appears on top of the file name text with no padding.
80 char limit fixes.
Fixes#1651#12608#13796#15189#15688
Change-Id: I8c6106effc612f49aff374f29742471628b5df86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3054
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is no point in computing line breaks for a 10px wide text view and
it takes a long time because it needs a lot of linebreaks. The view
eventually gets laid out properly.
This may cause regressions, the TODO here is very old and I don't know
to which "other parts of the code" it refers. Possibly they were
rewritten, possibly not. In any case, there is no point in keeping this
nonsense initial text rect computation, it's better to fix the actual
problems.
Fixes#5582 (which was not locale-related, after all)
If be_app is not running yet, trying to lock it may easily end up in a
deadlock.
Fixes#2105
However, as a result of this, when this situation happens, the
translator roster will not be node monitoring added/removed translators.
This was already the case if BTranslatorRoster::Default was called
before BApplication constructor, now it's also the case if called inside
the BApplication constructor or from another thread before it finished
running.
Maybe BTranslatorRoster should try to register itself later on if it
detects this. But it's acceptable to have the app not monitor
translators, because adding and removing translators isn't a very common
occurence and restarting the app to get it to notice them is probably
ok.
Remove the InstallerInitScript (it does nothing) and the
InstallerFinishScript (it does too many things). Instead implement the
finishing directly in Installer. Separate writing the bootsector, so
that the "write bootsector" menu writes only the bootsector.
Fixes#16303
- libicule and libiculx do not exist anymore in newer ICU versions
(harfbuzz replaces them), but we didn't actually use them, so remove
them from the build feature and from the package dependencies
- Add namespace usage marcos since the newer ICU packages put ICU things
in a namespace, making it easier to have multiple versions of ICU used
side by side.
No functional change intended, but this makes it possible to build the
code with either ICU 57 (for gcc2) or 66 (for other architectures).
Reserved areas don't have the name field initialized, so explicitly
print "reserved" instead.
Change-Id: I26bcfcb8facb8b5df11a58074506e96a41943e31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2847
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes the output of the aspace KDL command more useful as it shows
reserved and free ranges in addition to areas.
Change-Id: Id6353820b7c040fce6bfc3297c1b34adb1c9bb99
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2846
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It allows an application to signal that it no longer needs the data in
the given address range and the underlying pages can be discarded and
reused elsewhere. This is finer grained than working with full areas
or mappings at a time and enables unmapping sections of partially used
mappings without giving up its address space.
Compared with punching holes into a mapping by "mapping over" with
PROT_NONE and MAP_NORESERVE, this has the obvious advantage of not
producing a lot of unused extra areas and saves the corresponding
resources. It is also a lot "lighter" of an operation than cutting
existing areas.
This introduces madvise() alongside the existing posix_madvise() to
allow for OS specific extensions. The constants for both functions are
aliased, the POSIX_MADV_* being a subset of the MADV_* ones without the
non-POSIX extensions. Internally posix_madvise() simply calls madvise().
MADV_FREE is commonly supported in other OSes with various subtle
semantic differences as to when pages are actually freed/cleared and how
or whether the pages are counted against the memory use of a process.
In the variant implemented here, pages are always immediately discarded
and memory counting is not altered. This behaviour should be considered
an implementation detail and may be altered later. The actual unmap and
discard could for example be delayed until pages are needed elsewhere to
reduce overhead in case of repeated discarding and remapping.
Note that MADV_FREE doesn't really align with the rest of the madvise()
API as it works like a command (i.e. discard these pages) and does not
add an attribute to the pages in the given range (i.e. mark these pages
for quick access from now on). As such, an MADV_FREE does not need to be
undone by setting a different advice later on, unlike how the other
flags work. This discrepancy may be the reason why it is not part of
POSIX.
Change-Id: Icc093379125a43e465dc4409d8f5ae0f64e107e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2844
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Pages in the given range are unmapped and freed without getting written
back anywhere. It can be used whenever a caller does not care about the
data in the given range anymore and wants to reduce page pressure.
Change-Id: I8bcce68fab278efef710d3714677e1d463504a56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The limit was set when creating limits.h back in hrev88. It seems to be
used only in glob(). The limit is quite low by today standards and
prevents building icu 67.
I guess the liit was put at 32K because that's what BeOS did, but I see
no reason to keep it that way.
Change-Id: I74f95d9b56891dd90c79b7ced35ca8d1ec81d6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3117
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* efi-app-x86_64 is a undocumented legacy compatibility
target from the early days of EFI.
* This opens the door to native arm,arm64 loaders without
the gnu-efi 'fake pe' stubs in the future.
* This change also clairifies what's happening within the
undocumented efi-app-x86_64
* Future as in binutils fixing these:
https://sourceware.org/bugzilla/show_bug.cgi?id=26206https://sourceware.org/bugzilla/show_bug.cgi?id=26218
Change-Id: I60b4a4f5ceb36059033debbe6bf5b01928d6b223
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3016
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
The label to be truncated was copied into a fixed width buffer without
taking the null byte into account which would make
BFont::GetTruncatedStrings() read out of bounds when the name got long
enough. The output strings were also not allocated with the required
extra space for the ellipsis which would possibly have caused the
output to overflow.
Since the goal is to truncate a single string, remove the entire
temporary extra allocations and simplify to use BFont::TruncateString()
directly, which avoids both problems by being BString based.
Change-Id: Ib57430faf6f706c705497191000ee9686441857e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3116
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
