* It was making things confusing and honestly the dynamic
calculation code does a pretty good job.
* Just make sure we scale the scale the CPU bars with a
multipler that makes sense for a minimum width.
* This should give us a good baseline. Tested 1 to 32 cpus
Change-Id: If41c73e68b2de2b39196013af13e6c0ffdbe6489
* We saw a "big" cpu bar on 1 core.
* This was because adding 8 to the static "15" width
resulted in the static CPU sizing code getting disabled
* Converting this to 4 just completely disabled the static
scaling code and made dynamic always enabled
Change-Id: Ida8c718c0d0a2fcf72aedbf525daad040d5b3678
I don't know if the behavior makes sense, but anything is better than a
kernel crash. The ticket is an example calling the syscall directly,
so there is no user-oriented guarantee on how we behave here.
Fixes#16741.
Change-Id: I803596004d005c8c0e058c5422c4b0f7c78cfad8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3623
Reviewed-by: Rene Gollent <rene@gollent.com>
Change-Id: Ie10acfd10e8feab71660f99938cbb5bbab565772
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3618
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
DriveSetup does not make it clear when there is empty space or when a
partition is not formatted. Reword things a bit to make this easier to
understand.
This was a common source of confusion in various video reviews of Haiku,
with people trying to install Haiku to a partition that had not been
formatted.
Part of #16304
* 4 cores or less, use static table. More make view larger.
* 16 cores or less, 2px CPU bars
* More than 16 cores, 1px CPU bars
* Tested through 128 cores in qemu
Change-Id: I5fb460e7ee5848d0395b109acc602e86f4d5bbd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3616
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Regression introduced in hrev54742 which used DeskTextColor() on a
non-desktop view. The view color isn't set anywhere in that case and
does not match the background color, which led to drawing white text on
a white background.
Moreover, a second bug was stacked on that: the selection is drawn in
"reverse video" (using the document color for the text and document text
color for the background) only for active windows. For inactive ones, it
is drawn normally, and then a middle-grey rectangle is alpha blended on
top. Add a comment to clarify that and reintroduce the ckeck that had
been removed.
Also replace the hardcoded black for the selection background, so it
will be more easily visible for people using dark mode.
Fixes#16627.
They were accidentally removed in hrev54634 in an attempt to clean up
the code.
Reintroduce the old logic with some cleanup and improvements:
- There was a mixup of "tab side" vs "border". The constant values for
the two are the same, so it still worked as designed, but it made the
code harder to follow since it deals with both borders and tab sides.
- Define an isVertical boolean to decide if the tab view is vertical,
avoiding repeated tests for specific tabview sides.
Fixes#16640.
We do not want flat buttons here. This was introduced to get the Be
control look to draw inverted color labels on the buttons, but there
must be another way to do this.
Fixes#16660.
+ avoid spaces at the end of a translatable string, as those can
easily be missed by the translators.
Change-Id: Ic41e613b44e4248529d1f68f6bab13a048e66f3e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3612
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There are three parts to this change:
- In FetchFileJob, if the request fails with a timeout or IO error
(probably because of unstable connection) attempt to resume the
download with a range request. No limit on number of retries
currently, maybe we should add one.
- In PackageManager, before downloading a file, look around in other
transaction directories in case it's already there. Partial and
complete downloads are differentiated by an attribute which the
fetch file job maintains. For complete downloads, no fetch job is
scheduled, for partial downloads, the fetch job will request the
remainder of the file.
- In BHttpRequest, the implementation of SetRangeStart() and
SetRangeEnd() have been added, along with some refactoring to
handle listener notifications consistently. This also fixed a
bug where the final notification for download progress was not
emitted for compressed data.
Fixes#12414.
Change-Id: I3e285741ed0e5651594a7c2e1c7170644a9d297d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3404
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Untested. If audio is not decoding well, try increasing the constant.
Change-Id: I151764e6bb3e69088904d33bfeb683bf0569bd23
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3605
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
On sparc, the minimal page size we can use is 8K. Since B_PAGE_SIZE and
PAGESIZE defines were hardcoded to 4K, this resulted in a lot of
confusion in all code trying to manipulate pages.
- Remove cpu.h from headers/private/kernel/arch/*. It dates back from
NewOS and was not used anymore since our kernel uses B_PAGE_SIZE
(PAGE_SIZE was the only thing defined in this header).
- Add posix/arch/*/limits.h with the arch specific page size and include
it from the main limits.h.
- Adjust bios_ia32/debug.cpp which was the only place using the
PAGE_SIZE constant from the deleted headers.
- Change OS.h to define B_PAGE_SIZE to be the same as POSIX PAGESIZE.
- Define PAGESIZE in the build header if the host OS doesn't.
Change-Id: I8c3732cf952ea3c2f088aa16d216678fbf198b96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3558
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Fixes the ARM image to actually include Haiku within
a partition on the SD card.
* Drops the mtools requirement
* Drops the C/H/S requirements
Change-Id: Ie2776a09399ac181daab7a503e96e27ab7093af4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3608
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- The quirk was not properly applied due to misuse of the device API
- The interrupts could run out of sync, leading to not properly waiting
for commands to terminate before reading their result. Add panic to
check for that (at the start of the next command) and fix the code.
Change-Id: If83b7bbb3c3446d374115ed22c09b91020028578
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3609
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I built only the bootloader for sparc when testing, so some code was
disabled because it's guarded by _BOOT_MODE.
Confirmed that the generated assembler is not larger than before (the
disassembly file is the same size, but for some reason functions were in
a different order, making it difficult to compare more closely)
It needs to be done once per device and only after we have decided that
the device is supported and should be handled by the driver.
Change-Id: Ia00c1fbb151ab181abbfcfaed538cf58985aea07
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3601
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The BFS on-disk data is not aligned. Reading it to memory and trying to
access fields directly does not work on sparc. memcpy the data to an
aligned variable before handling it with its native size.
gcc knows how to access unaligned data, but we need to tell it when to do
so. This is done with the "packed" attribute, but it works only on
structs. So we have to wrap the values in a struct.
Thanks to C++ features, we can make the struct
relatively transparent by having an assigment operator (for writes) and
a cast operator (for read access), so there is no need to access the
value inside the struct with ".value" everywhere. The rest of the code
is then largely unchanged (except for use in printf statements and other
vararg functions, where the implicit casting can't work).
gcc takes care of performing the access in the correct way on platforms
that need it (old ARM, sparc) and can still optimize things on other
architectures where specific code is not needed for unaligned access.
Fixes#9255
Change-Id: I3bf62590dee059ad32b1845bdc4eace165b73203
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2363
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The NetworkStatus applet by default only shows the first address
on the interface, assuming IPv4 semantics and ignoring others.
This assumption doesn't hold true for IPv6-enabled systems, which
not only have both IPv4+IPv6 addresses, but typically multiple
IPv6 addresses (link-local and global at a minimum).
In addition, it's not unheard of to have multiple IPv4 addresses
on a single interface, even though it's difficult to configure in
Haiku at time of writing.
This change loops through all available addresses and prints them
in the status.
No attention to ordering is made; future enhancements could
include sorting IPv6 global/link-local, displaying the type, etc.
Change-Id: Ib437e32fc878b5baafa8c2437659e10fb6fcffbf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3550
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Package files to be committed may already exist in the packages folder,
there is no good reason to fail the transaction. These may be packages
which are not activated, or there may be other reasons. While I have
not investigated how this situation may form, I don't see a good reason
to spend the time. Simply compare the contents of the existing file
with the file from the transaction, only fail if they are different.
Change-Id: I2a574df38385c8dead8bac2beace94436d43760a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3597
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is a quirk needed to switch the controller to standard SD mode
(copied from FreeBSD).
The response type configuration for R7 response was incorrect, this
response type does not have a data phase. This made the Ricoh SDHCI
implementation generate an unexpected "transfer complete" interrupt,
while apparently the implementation in QEMU didn't.
The interrupt generation is a bit different from what I got in QEMU
when developping the driver, for some commands, we get only a
"transfer complete" and no "command complete" interrupt as I'd expect
when the command completes.
This is handled in the following way:
- The interrupt always releases the semaphore to notify that something
has happened (once per event)
- When the main thread waits for an event, it always uses the same
pattern:
while (!condition)
acquire_sem(...)
This pattern makes it not wait at all if the condition is already
satisfied. If the interrupt triggers later or already happened when the
code gets to execute this while loop, the semaphore can be left with
some tokens in it. These will be emptied the next time the thread waits
on something.
To make sure ths works properly and everything is synchronizing as
expected, some extra checks are added before execution of a command to
make sure the hardware is in the expected state.
There is also lots of extra tracing, I prefer to leave this enabled
initially and wait for some other users to test this new driver on their
hardware. When we are confident enough that it is compatible with
several implementations, we can reduce the tracing or turn it off.
Change-Id: Ib9617dbea62f87124dbaad0027b53a13d949641f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3600
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The main differences:
- The initialization sequence requires an additional command (this was
already done)
- The layout of the CSD register and the way to compute the device
geometry from it changes
- The read and write commands parameter is a sector number instead of a
byte position
Change-Id: Ie729e333c9748f36b37acd70c970adfd425cf0b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3512
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
- The restrictions are now set by the sdhci bus and retrieved from there
by the DMAResources.
- Configure SDMA with the maximal available boundary check of 512K and
publish the corresponding DMA restrictions.
- dma_resource cannot be initialized implicitly as a member of
mmc_disk_driver_info because mmc_disk_driver_info is allocated with
malloc/free, not new/delete. So we now explicitly allocate and delete
it.
This allows reads and writes of more than a single block at a time.
Change-Id: Ibb97c91543312c7970c28a7a8c68a12708263e32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3505
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The SDHCI spec also offers an "advanced DMA" mode where we can use
scatter-gather lists. It would allow to remove several of the DMA
restrictions, but hardware support for it is optional, so we need this
version anyway.
The geometry is retrieved on demand in the first read or write or in a
call to the get geometry or get device size ioctl. It is not possible to
retrieve it from the device initialization because that is called as
part of the mmc_bus scanning, which needs a specific sequence of
commands and keeps the bus locked to prevent drivers to insert their own
commands in the middle of that sequence.
TODO:
- Move the DMA restrictions definition to sdhci_pci and forward it up to
mmc_disk (which is the one creating the IOScheduler)
- Decide if we want to keep non-DMA support (probably should, but it
makes things more complex, because it uses virtual addresses)
Change-Id: Ib1dd14eacf62052d747bfb3ef7820bc5a34d3030
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3471
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* The "default" of 3MiB wasn't enough for modern larger media
formats, resulting in inability to play 4k video no matter
how much horse power you threw at Haiku. (4k is ~8MiB)
* This dynamically calculates the ChunkCache based on the
video framesize * 2.
* 4k video now plays smoothly on my Ryzen 1800x.
Change-Id: I65bf6bd6fa60ac3196ea70eeeb5e655d43c10bcd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3598
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
