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>
None of these were used; they were all imported with the original
root Haiku commit, and they are totally unrelated to PulkoMandy's
new SPARC work. Plus, they were also under a BSD Advertising Clause
license.
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.
