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>
* 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>
The name retrieved from GetName() on BTextEncoding is owned by that
instance which goes out of scope when identify_text() returns. A const
char pointer to it can therefore not be used as an output variable. Use
a BString instead which ensures an appropriate reference is acquired.
Change-Id: Ib87fc9879d29e927bb41d1a9165ca7599b74a3bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3115
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The panic is continuable, but moving on with the free will overrun the
array and corrupt memory.
Change-Id: I9a5849a40158042150a25740ca57d711aee872bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3114
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the vector is assigned to a CPU it means that the assignment
structure is still referenced from the CPU side and must not be reset.
This can happen when an interrupt vector is freed that still has a
handler installed, i.e. when the order of removing the handler and
freeing the vector is reversed.
Change-Id: Ib2dc5fa8f95a28b36e8f150dc8f16236ca4b2275
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3113
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Freeing an interrupt vector that still has handlers is not allowed.
Change-Id: If2f256e5288c7a61b7e23bdb202f259f5b67b7ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3112
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The old buffer info was not initialized so would possibly contain bogus
initial content.
Since the introduction of the TimeComputer, the old buffer info was not
used to update the timesource data and the only remaining use was for
keeping track of the previous cycle number.
Replace the old buffer info by just the old cycle number and initialize
that.
Change-Id: I8be5a17f086a9f81f9b8fd0629e10460518f3d8c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3111
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I82465c3002cbf58fad79b9621074cafd8fbd16e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3106
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Abstacts the list of supported languages into
the LanguageModel class preventing use of
List. Also; fix a few cases where newer
logging techniques may have caused incorrect
logic flow.
Relates To #15534
Change-Id: I144fe4788abdaf0d93e53eeabc97b3f7aa2ec710
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3085
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Instead of adding "dummy views", leave the original views intact
and just add a resizing hack to take care of any movements that
apps have inflicted.
Fixes#16411, a crash in WonderBrush, and compatibility issues
in some other applications.
We need a different constant or mechanism to get the document
window border size, it appears, or a static method to get
a scroll bar's preferred size.
Should fix#16422.
Two indices into the fEntries ring buffer are used in TimeComputer,
fLastEntry which points to the most recent sample and fFirstEntry which
points to the oldest one. The drift calculation then uses the oldest
values pointed at by fFirstEntry to produce smoother values.
Both indices are initialized to 0, then fLastEntry is incremented prior
to writing the first sample, resulting in the first sample to be written
to fEntries[1]. When drift is calculated on subsequent samples, they
were using the uninitialized data from fEntries[0] due to fFirstEntry
still pointing there, until enough samples had been added for
fFirstEntry to be moved forward. The resulting incorrect drift values
would depend on the entry content and ratio between real and performance
time and generally end up being much too small.
The drift values are published on the time source and used to correct
the conversion between performance and real time in
BTimeSource::RealTimeFor(). Given the incorrectly small drift values,
this conversion produced real time values far in the future, causing
increased delays in processes that wait for such computed real times.
One likely victim was the startup of the AudioMixer, as it generally
starts soon after the driver and its MultiAudioNode. If it started right
in the time window where the drift was broken, it would end up delaying
its initial buffer processing by a factor generally depending on the
difference between real and performance time start points, so usually
the difference of the start of the boot process to the start of the
audio driver.
The symptom was then noticable by initial silence after boot, as the
mixer was not producing any buffers until the wrongly calculated real
time had been reached. After that, lots of queued up events were
processed at once, resulting in a CPU spike and glitchy audio for a
couple of seconds after which audio finally normalized. As the problem
was in the MultiAudioNode all mutli audio drivers were affected, HDA
being the most prominent.
As the erroneous delay depended on the initial entry content and the
boot time, it was highly variable. Whether or not the mixer was affected
at all also depended on it starting reasonably early after the driver,
which made the symptom of the bug appear and disappear depending on
slight timing changes, making unrelated code changes look like they were
affecting the bug.
The fFirstEntry index is now updated to fLastEntry after the initial
entry is added, so that the drift calculation always uses valid data.
Fixes#16222, may also affect #15472 and possibly other "no audio"
tickets in case they are really "delayed" audio tickets.
Change-Id: I61f4a67e8b8bf14d2f311cb41b24a1c385aebc19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3092
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The socket is a blocking one, which means Read() will block unless data
is available, thus WaitForReadable() is useless in this context.
Testing also shows a 2x performance increase from removing this call due
to poll() performance being botched when KDEBUG_LEVEL >= 2.
Change-Id: I3170f865e961112b420c1548726bb6fd38e94cb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3078
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This make sure that the temporary buffer will always be deleted should
any premature return happens.
Change-Id: I448ec7c3f3eeca1ef2b6473b49323f34bcb7bf86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3077
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Instead we can trigger a Read() immediately, as our socket is blocking
and won't return until some data has been made available. This avoids a
potentially costly syscall in the loop body.
Change-Id: I899f55ede41af7cb7e9311aa04006b33c40d3ee4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit brings the following changes:
- DownloadProgress() should now be reported for every DataReceived()
calls, similar to other BUrlRequest classes.
- Properly verify whether a listener has been set before invoking them.
Change-Id: I4ded82e318ba580b8869c3d1751da4e36882c39f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3075
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This simplify the clean up code path and make sure that the temporary
buffer will always be freed on exit.
Change-Id: I70c1a25bfa66c4f4a96dd3d0af3765a67e305fb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3074
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Trigger DownloadProgress after DataReceived, similar to how other BUrlRequest
classes behave.
Change-Id: I4858c3736b1b1ebec55af9903dbfd4b976a77df3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3073
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Make BFileRequest reports download progress after every DataReceived()
calls.
DownloadProgress() format has also been changed to use 0 as
`bytesTotal` when the total size is unknown. This is similar to
BHttpRequest functions currently.
Change-Id: I2920ea00c4f841bb666425be6f8da418e913c727
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3072
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit implements a check for the flag raised by Stop() to cancel
a given request as soon as possible. Cancelled requests will return
B_INTERRUPTED regardless of whether the request has completed,
on par with how BHttpRequest is behaving at the moment.
Change-Id: Ia8a95b910cff158c710c5b2ed58b4675e705642e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3071
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
hrev54429 added some changes to logging in HaikuDepot which broke the
build of the tests.
The build for haikudepottest.so adds some cpp files from the
HaikuDepot source. Now that Logger::NameForLevel and
Logger::IsLevelEnabled are referenced in some of the code being tested
we need to include Logger.cpp as well.
This just adds Logger.cpp to the haikudepottest.so build.
Change-Id: I80a8bb2053c3c78d821ce3cf9902c3a42b0def37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3056
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This ensures that the allocated physical memory uses 32 bit addresses.
Also avoid writing to the 64 bit address registers when the controller
is not 64 bit.
Change-Id: I58008d68bcd9579903534f824db2660f73e39160
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3065
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The spec says that changing the DMA memory addresses of a stream should
really only be done after a reset and before the first run. Stopping the
stream is not enough, as the controller is allowed to cache the
addresses even when the stream is paused.
Note that this is applied to both, the initial configuration of buffers
and to the case of dynamically changing stream parameters. In the initial
case this should always be a no-op as the controller was previously
globally reset.
In the dynamic reconfiguration case this fixes random memory corruption
due to the controller still accessing and modifying physical memory that
is released by the driver. With some controllers, such corruption was
easily triggered by changing the input and output sampling rates for the
HDA device in the media preferences.
The return value of the reset call is intentionally not checked to allow
for it to partially or fully fail. At least for HDA under QEMU, the
stream reset fails to start, while the initial stream stop still works
and prevents the memory corruption.
Change-Id: I7c6e6547ee08889a2990de26d5eed5e73b2ca13c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3063
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Don't unconditionally enable PCI interrupt generation as this only
applies when MSIs are not in use. Delay the evaluation and setting of
the interrupt disable bit until after it is clear whether or not MSIs
are to be used.
Initially force interrupt generation off as early as possible. Depending
on the initial state of the controller, some spurious interrupts might
come up and we really don't want them to occur before everything is set
up in the right way.
Change-Id: Ifb12f5eef1cbf8ecfa3f352564139125d8ad2169
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3062
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is already properly done in uninit_driver.
Putting the module in device instead of driver uninit meant that on a
device reopen the gPCIx86Module would always be gone and therefore MSIs
could not be used anymore even if they previously were.
Change-Id: Ib3bddefbe6bcb02fa1c97f3c843cecaf31c80e3e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Just disabling it will leak the vector reservation and makes it
impossible to configure an MSI on the device again.
Also removes the check for the gPCIx86Module as having an MSI configured
really implies its presence.
Change-Id: I9f0e3e63c988af515d23ad93d86918cde9add97a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3060
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This was previously only done if reset failed.
Change-Id: I30ebe1d302087816bccfe67e3d236c9446425aea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3059
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In the start case this adds debug output in case a start fails.
For stops this makes sure the stream DMA engine has actually stopped
operating, which is a precondition for some other operations.
Change-Id: I0e2731513febd0e0cd4e1f0ef89cf3d7312a47e1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3058
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It is a recurring pattern to set some bits, then wait for them to be
read as set or the reverse. For resets this is done once in both
directions, so factoring this out removes quite a bit of similar code.
No functional change intended.
Change-Id: I2ae4b6cce490c33e1a027328f01fbffea67c5180
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3057
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Remove workaround for BTextView bug from 2006 that no long applies
in FileTypes ApplicationTypeWindow by allowing the text views to
align themselves on FrameResized().
Don't override height on version text views, default height is good.
Change-Id: I41e5a9244c5c79eee3bba133064d016673e008e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3053
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Two usage scenarios:
* Wrong directory selected when invoking as Tracker add-on.
I often find myself having TextSearch invoked on selected child,
when I wanted it to open in parent context.
* Result was not found in target directory, so maybe the search
should be broader.
Change-Id: I2621f3cec7459572ddae438de4ba42ce74432e28
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3044
Reviewed-by: humdinger <humdingerb@gmail.com>
* An upstream bug exists which results in the tianocore
bios crashing when attempting to read from qemu's
(unconfigured, but present) flash device.
Change-Id: Ie9f02a290abc29cce3a5e279382750c0b14164dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3049
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Anecdotal: whenever I hit Cmd+A with text field focused I want to
quickly select search phrase, not the results. In fact I never found
myself in a situation where the latter is the desired outcome.
Change-Id: Ib5edcee8e7366485181cb2030ecfa989619cd600
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3043
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The documentation file (which PulkoMandy only merged today) was created
over a year ago from a short conversation I had with him, and by now
a lot of its information is already outdated or has been merged into
comments in the driver already (specifically, the notes at the end about
error messages no longer apply as there are different ones, and the
bugs causing those errors have since been fixed.)
A few of the statements in it were not noted in the driver, though,
so I have added those as comments.
- Use the correct escape sequence for reverse video
- The vertical form feed does not cleanr the screen on normal serial
terminals, so additionally use the clear screen sequence
It's useful to see our openboot boot menu.
I'm not sure what B_NEGATIVE_FACE is meant to do. The be book says
"Characters are drawn in the low color, while the background is drawn in
the high color.", but DrawString does not draw the background, so some
color swapping will still be needed in this case anyway.
Use a larger default window size so the keymap is readable.
However, size it down on low resolution displays.
Fixes#14892
Change-Id: Id35c46fa14bef570f78d8f065d95f6e6d8f0c6d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1312
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Fixes#9618 (which suggested using a tree view, but I think that's not
useful, just proper sorting of the items seems fine to me)
Change-Id: Ie1298eec048f9cb42528b8420a91e807e8f00eab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3030
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* BSolver is implemented by solver add-ons
* We may want to (unlikely) leverage another
package solver in the future.
* We may want to (likely) implement a dummy
solver when libsolv is unavailable on new
architectures without bootstrap.
* This also makes solving missing libsolv a little
more graceful vs the "include "libsolv.h" not
found.
Change-Id: Iedd9d0f022fb743c4c7606bd33a4b6dbef0576f7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/819
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Same problem as in BListView::ScrollToSelection.
Change-Id: I1cd26190566b1808f47475c1499298b66549f024
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2312
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Now it allows to connect MediaPlayer video producer to differnt node in Cortex.
Change-Id: I7ee598ea64d10e8fa876259e7a4480a650a0e189
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3034
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Changes the logging in HD to use a macro for the
various log levels to declutter the code and to
make it easier to more systematically log.
Change-Id: I025970707a0a11e7e3aaa4b52fc91288af0183f5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3018
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The spec says this is undefined behavior, but it will fix one more
problem with #8297
Change-Id: Ibc15f306c92b05019de1050a9eb239ba57b1a91e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3029
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Use , as the shortcut key for settings in all built-in apps. Some used
S, but that's already the shortcut for saving. , is the recommended
shortcut in the HIG already, but built-in apps were not updated to
match.
Fixes#11733.
This adds the upper 32 bits for address and size.
Change-Id: I2f776c7b8b72ecefca9f3b93d9c42912666a41e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3026
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Factor out the conversion to BAR index and hand the pci_info to both
memory and IO port allocation functions. Then apply the same checks
in the IO port case as are done for memory.
This aligns with what is done on FreeBSD.
Change-Id: Ib4bd28fd861959a467ba676de22efb1f97e5a27c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3025
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fix address type mask to use the right bits via PCI_address_type. The
previous 0xc value applies to the upper of the two address type and
the prefetchable bit instead of the two adddress type bits. This would
cause prefetchable 64 bit BARs to be misidentified as not being 64 bit.
Remove address masking as this is already done on the field in pci_info.
Use uint64 instead of phys_addr_t explicitly as on pure 32 bit platforms
this would otherwise result in a shift greater than type size.
Note that the sizes should theoretically be adjusted as well, but in all
of these cases a size needing the upper 32 bits doesn't make much sense.
Change-Id: Idd0d6e9a6cc18656b43cafcac720b132fc1f2ad3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3024
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Make mandatory argument of _GetRomBarInfo a reference too and use NULL
instead of 0 for pointer argument default value.
Some line length cleanup.
Change-Id: I1bdb59eeae4496b75fd4a1b8c5b305283da266f9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3023
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This moves the entire 64 bit handling into _GetBarInfo() and applies it
to the PCI address and size too. Previously only the RAM address was
handled for the 64 bit case.
Also fixes the 64 bit check to be done after the type determination.
Previously it would theoretically be possible for an IO BAR with the
lowest address bit set for that type (bit 3) to be mistaken to be 64 bit
and then skipping/mishandling the next BAR. Due to alignment this would
have needed to be a 4 byte IO BAR though.
This also corrects the limit for 64 bit BARs of type 1 devices. As there
are only two slots, only slot 0 can be 64 bit.
Also removes a copy&paste error that would lead to the high address of
64 bit BARs of type 1 devices to get taken from the h0 instead of h1
struct, corrupting its value.
Make the mandatory arguments to _GetBarInfo() references to make the
distinction more obvious and replace 0 with NULL in the default values.
Change-Id: Iae59f2875c93f15411a4d9791e71e69ba7a42287
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3022
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
FreeBSD apparently enables these options by default.
This should enable support for 802.11n (i.e. HT mode) on Atheros
chips that support it, of which there are quite a few.
Map entries can be read, most structures are in place. Next is to
actually work with the directory block.
Change-Id: I700ee2e003bdef97838b1f06a95e53a5e4293658
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2981
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We can now read short form directories.
Change-Id: I23eb6ef52e8bb07643213e603ed0185f536c649f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2952
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
...when it is paired with a horizontal scrollbar. This has the
added benefit of restoring the previous horizontal scrollbar size,
it having been lost in the prior refactor due to the "container views"
removing 2 pixels for the borders (previously, there was a different
sizing system for the count view that provided it.)
Fixes#16368 item 1.
The one-pixel offset greatly improved the text alignment under HiDPI,
but degraded it on non-HiDPI. I guess one pixel really does make
that much of a difference; so this will have to be revisted.
BFont is by default bitmap-spaced, so we do not need to make
a new font just to add bitmap spacing. The rest of the code
assumes in places that we have the same general characteristics
as be_plain_font anyway, so having these bits of code does
not make a lot of sense.
Also correct the list element height computation to now just use
be_plain_font directly, which will work even when this is the first
PoseView created (i.e. before the font height has been read.)
Now that the scrollbar is part of the pose area, we no longer
have to include its height in the spacing of the pose view
from the buttons and the bottom of the window.
Mentioned by X512 in #16368.
This was the behavior before the commit yesterday that unified the
two methods of computing the preferred size. It seems some applications
expect this to be callable without a window lock, so this works when
the other method does not.
Fixes#16372.
Change-Id: Ifbd82ef7bfc2c39b2aeb5c25be177421cd22d246
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2920
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
As BScrollView has already been adjusted to use this, most applications
will now have properly scaled scrollbars on HiDPI systems.
All unadjusted controls and applications will still be able to use
the hard-coded constants as before, but these should eventually
be deprecated altogether and then removed.
This replaces the use of the hard-coded scroll bar size constants
and instead asks the scrollbars for their preferred sizes directly.
Right now, this is a giant no-op since BScrollBar just returns
the same hard-coded size when asked. The next commit will, however,
change that.
It was always enabled, and disabling it would break ABI.
If we want to make it disable-able, it needs to be a setting,
but I don't really see a reason for that.
This change will rename the confusing "url" within
HaikuDepot to be "identifier" in line with
corresponding changes in pkg kit and HDS. Also at
the same time support is introduced for HDS
repos' meta-data to artificially match against
multiple repos; as requested for the future R1B3
release process. Some tidy-ups and extensions have
been made to the JSON schema-to-model and the
schema-to-parser scripts.
Change-Id: I402e7d610986039f58d72028bda7de977e9115e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2986
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Remove use of custom list class where it is not
really required.
Relates To #15534
Change-Id: I4bdc258a64055b6e36c7be93672c52d0499e512b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2991
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This greatly improves the appearance of menus under font-scaled systems.
The computations are written such that the margins should be unchanged
under a 12pt font size.
The behavior of not making the icons smaller than their default
pixel size is (for now) kept, but when making them larger,
fractional scaling is now used.
This makes alerts look much better on my system, which has a font
size of 18 (i.e. 150% normal, so 32px -> 48px.)
* Migrate some platform agnostic architecture code into
boot/arch from efi/arch. This helps to avoid conflicts
between kernel and boot sources as well.
* Conflicts between arch_cpu in efi and kernel code means
bootcode really should *never* directly use kernel arch
headers. (other platforms don't, which is why they don't
have this same issue)
* We carefully thread any needed kernel headers (namely
assembly helper macros) into the bootloader headers without
mixing in the whole conflicting kernel/arch headers.
* ARM now properly get its cpu init code called, and we
progress further into the EFI bootloader.
Change-Id: If67ec9758b5ce68563ebd9eb45d5196401911c67
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2975
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Make sure brightness is reset to properly disable the Revert button.
Fixes#16354
Change-Id: I4551e809db316db05f3fd9db361b8703d149a88b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2989
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The BSD implementation was under the Advertising Clause,
so we might as well take the opportunity to replace the
implementation entirely with musl's.
Header also rewritten to be a Haiku one; the constants
are left unchanged of course.
* Remove functions not even FreeBSD defines.
* Remove dependency on unnecessary headers.
* Update copyright headers to match FreeBSD's; includes
removal of the advertising clause.
* Move some private structs to netresolv port_before.
Unfortunately, it seems musl implements very little of this file,
so we may wind up sticking with netresolv for its implementation.
This patch gets read_dir, lookup and few others to work. Entries cannot
be listed yet except the root.
Change-Id: Ic4b7b61a794a1b75849e45777a383b3315b15aa8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2915
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This reverts commit fb44a1cd72.
Reason for revert: may cause UAFs
Change-Id: I315ce4fc5cd1706ca07e7062fc0461b7fff7c831
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2980
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I90a9440898994459f8d6de922a3f363fbeddaaf4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2974
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This change resets the delay when the user moves to next/previous image or
page within an image (e.g. TIFF) or deletes an image while a slide show is
running.
Fixes#16321
Change-Id: If0b8f4caef9c6aa4c0ad5bbb01d65bf43c1f831f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2967
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The .rel.* sections were forgotten in the PE binary, so we just put them in a single .rel
Change-Id: I7bc564e18ec8dd64410b43106272ee74696c2883
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2973
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
DriveSetup terminology was changed a while ago. Disks get 'initialized'
with a partition map. Partitions are 'formatted'.
Change-Id: I600145cdd1ed622378d364aa66a6146aae4a9a87
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2968
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Otherwise, important HAIKU_BOOT_* flags don't make it into
the build commands.
* Ensure any external sources used by EFI get recompiled
vs reused due to potential differences in wchar length
(EFI dictates short-wchar, but no wchar's in our code)
Change-Id: I7a4a0347d39239c73fa510378e048f51be1cd360
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2965
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
