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>
