only scsi_disk checks the actual value, other drivers take the logical block size.
This change reports the physical block size from the disk rather than the block
size used by IDE/SATA/SCSI commands. On typical modern SATA disks, the SATA
commands will use 512 byte blocks, but the disk will actually read and write
4K blocks internally. This is only of importance for partition alignment for DriveSetup,
and is independant of file systems or partitioning systems. This could also influence
the recommended block size for some file systems.
Change-Id: Id0f2e22659e89fcef64c1f8d04f81cd68995e01f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5667
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This was a holdover from BeOS, which did this as inline assembly.
We do not on any platform other than 32-bit x86, and even there
we may have preferred to do things a little differently on non-BeOS
ABIs.
Most things ported from other systems, or even native apps, are going to
use _Thread_local variables anyway, which will bypass this system
altogether.
This takes an int32 (e.g. B_MINI_ICON or another constant) and
then returns a BSize scaled appropriately, the same as ComposeSpacing()
does already for the *_SPACING constants.
This will be used to replace icon size computations throughout the tree.
... and B_WORKSPACES_CHANGED too.
hrev50148 propagated B_SCREEN_CHANGED messages to
children allowing them to respond to screen changes
fixing #8035 back in 2016.
This does the same thing for workspace messages only
I spelled propagate correctly this time.
Add private _PropagateMessageToChildViews() convinience
method to BWindow to do this work.
Call PostMessage() instead of calling MessageReceived()
directly which can work better in certain circumstances.
Change-Id: I5978c3fe674bbe75d9eafb7afb654a49ee3e0c11
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5516
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This considerably overhauls touchpad event generation, simplifying and
cleaning it up considerably:
* Return the touchpad specifications through the MS_IS_TOUCHPAD ioctl.
* There is now a dedicated MS_READ_TOUCHPAD ioctl, as touchpads
can either return touchpad_movement structures or mouse_movement
ones depending on what mode they are operating in.
* Event repeating on timeouts is now handled in MovementMaker and
the input_server control thread, so MS_READ_TOUCHPAD takes
a timeout value. This means we can drop all the EventProducers.
* Use the real floating-point math functions in MovementMaker now
that we are running in userland.
* Drop unused structures, constants, headers, and other things
related to touchpad support.
Change-Id: I28cdb28e4100393a9338a8ebb865573cec13fc1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5455
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This was introduced into the main API in 2010 (d72ede75fb),
but was actually only fully used for the past month (c2a9a890f3)
when SIOCGIFMEDIA was supported for all *BSD drivers and not just WiFi.
Most userland consumers of this structure did not use it correctly,
as was the case in #17770, and only worked because in the fallback case
the network stack just treated it as if it were an ifreq.
Nothing actually used the ifm_count/ifm_ulist (though tentative APIs
were exposed for it) as noted by previous commits; and the fact that
Haiku's IFM_* declarations are so spartan makes most of the returned
values unintelligible to userland without using FreeBSD compat headers.
If, in the future, we decide to implement ifmedia listing and selection
properly, that should likely be done with separate ioctls instead of
having multi-function ones like this.
This is technically an ABI break, but in practice it should not matter:
ifmediareq::ifm_current aligns with ifreq::ifr_media, so the things
that used this structure like our in-tree code did will continue to work.
Until this past May, the only other field that was usually set was
ifm_active, but in the absence of setting ifm_status all non-Haiku
consumers should ignore it completely.
The only consumer of this ioctl that I know of out of the tree,
wpa_supplicant, still works after these changes.
This file contains a set of constants and flags which are already passed
between applications, net_server, and wpa_supplicant to indicate network
security, connection modes, and a variety of other things.
As the OpenBSD net80211 stack does not need wpa_supplicant for WPA2/PSK,
it only makes sense that we would pass the same information we pass
to wpa_supplicant into the stack instead. Rather than expose yet another
set of constants and flags to userland besides the FreeBSD and these
Haiku native ones, just make it so this file can be included in the kernel,
and the constants thus used directly.
* Fully remove unused and deprecated functions.
* Comment as to which functions are deprecated.
* Rename _by_name functions to be without the suffix, as this is C++
and there's no reason not to use overloads here.
Change-Id: I4e2152f17806605eb965795417013cea800e661e
* This will be needed for the following commit that implements
`pthread_tryjoin_np` and `pthread_timedjoin_np`.
Change-Id: Idccb1aa588d6d10825294d14925d9bd046b65f19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5098
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- All servers are now Werror
- All bus_managers are now Werror
- All input_server add-ons are now Werror
- Some more things in bin/ are Werror
Only tested on x86_64, I'll let the buildbot test on x86_gcc2 and RISC-V
Change-Id: I5ec86512eac729c862828a45d8431f85c4ec422b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5226
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
bus_type has been added to MediaRoster.h and the serial driver.
It is not used enough to be in any shared header.
media_roster only uses it for buffer size estimation.
Change-Id: If4f372d44e871230da4744d99ec7cde0c79c8344
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5209
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Create and use *_mouse_acceleration_by_name functions to replace older *_mouse_acceleration functions. Now consistent with related functions (such as *_mouse_speed_by_name).
* Passing mouse_name to HandleGetSetMouseAcceleration in the BMessage fixes mouse acceleration changes not applying properly.
Change-Id: I668cdbbbb81e3cb9069a3fc2ce77e6ef75ba8476
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5189
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This reverts commit 8497a2cc28.
The VFS layer is not at all ready for this. Many places in the
code implicitly assume ino_t values will never change. This
functionality is only necessary for live shrinking of partitions,
which is a feature niche enough we do not need to worry about
implementing it in the first round of resizing (if ever.)
The old versions used pixel-count dimensions, not pixel-span dimensions
as the entire rest of the API does, which was probably a mistake
in the first place. The new APIs using BSize always use pixel-span
dimensions.
The old versions will shortly be deprecated.
Discovered while working on Xlibe.
Change-Id: I604a5ac6e0588420ff0b667d9193d60ac27b92c6
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This file should ideally contain only those things needed
across all system headers, even POSIX ones, and all other
declarations (B_* ones especially) should go in SupportDefs.h.
However, as nothing but riscv64 uses this right now, I've just
moved it to there.
* Delete dropped out networks.
* Add in newly discovered networks.
* Add static (aka class) compare method to WirelessNetworkMenuItem
that is used to sort items by signal strength descending.
Add == operator to wireless_network struct to determine if
existing items have a known network attached.
Remove the non-network items from the menu, save them, sort
network menu items, then add non-network items back into the
menu.
Update NetworkStatus preflet to use same compare method as Network
preflet. signal_strength_compare function had a bool return value
instead of int which worked to sort items the first time, but does
not work on successive compares.
By not deleting and recreating the menu items each Pulse(),
the Network preflet no longer crashes on update. The menu flashes
on update still but doesn't crash.
Fixes#12024
Change-Id: Ie5b22cea4e66350b9c5df8e3b8de266ede50ad6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4243
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
... methods which call the respective methods in BList.
These convinience methods allow you to sort a menu of menu items
via a compare function, swap two menu items, or move a menu item
to a new index. Update items layout if menu is open.
Previously there was no easy way to rearrange menu items in a menu.
Change-Id: Ice3d6e5404e895196d8bd32d696dce7c55bd72d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4296
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The code in this module was derived from the one in driver/tty. However,
the driver uses a shared lock between the master and slave side of a
TTY, and this was changed to use two separate locks. The approach with
two locks does not work. It seems the change was unfinished and the
second TTY was never locked. But attempting to lock it will result in
lock inversion problems, unless we do complicated things (try to find
which of the two TTY is the master side, and lock that first, for
example). It is simpler to restore the shared lock as used in the
driver.
To set up the shared lock, I modified the tty_create function to take a
pointer to the master TTY when creating the slave. Maybe it makes more
sense to create both sides in the same call, create_tty_pair?
However, this does not work as easily as I wanted, because there is some
recursion going on: at least in one case, the tty_control function is
calling the driver's tty_service function, which in turns attempts to
call back into tty_control for the "other side" TTY. To handle this
case, replace the mutex with a recursive_lock.
Fixes#17091, where the root problem was access to
other_tty->select_pool without locking. This was also made unconvenient
to debug because select_pool objects are self-deleting, when the last
item in the pool is removed. As a result, the code accessing it without
log would suddenly find out that the data it was accessing had been
freed and erased.
This also makes the TTY code in driver/tty and generic/tty a bit more
similar than it was before, and brings us one step closer to merging the
two together. There are still two main differences and I don't know
enough about TTY to decide if they are important, and which version
should be kept:
- The driver has extra code for "background" read and write. I don't
know what this is used for.
- The driver has a single "settings" instance shared by a master and
slave TTY, while the module has two separate instances, but seems to
copy one to the other. I'm not sure which approach is correct.
Change-Id: Ie2daddd027859ce32ba395af76b4f109f8b984b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4604
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Now that it is not used anywhere in the source tree following
previous commits.
Change-Id: Id2fc417a0658d09148e99587c613a928f1fbe4c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4611
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Someone on the internet found out gcc only understand posix_memalign.
The alloc_align attribute may be applied to a function that returns
a pointer and takes at least one argument of an integer or enumerated
type. It indicates that the returned pointer is aligned on a boundary
given by the function argument at position.
Change-Id: I4b0af6ef3020da1fb460652117286193d5d72f1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4514
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
These were used in function_remapper.cpp but can be used elsewhere too,
so move them to a private header. Also use them for the stack protector
hidden function definition (probably not so useful since gcc2 doesn't
support using the stack protector anyway?).
The gcc2 way to make a symbol hidden is to manually generate the .hidden
directive in the assembler output. This is not perfect: it is hard to
use for C++ functions and methods (manual mangling of the name is
needed), and inline assembler can only be inserted inside functions. But
the alternative is patching gcc2 to add support for the function
attribute, and I don't want to dig into that today.
these colorspaces are packed as RGB or RGBA, not BGR or BGRA.
RGB48_BIG and RGBA64 only differ in the endianess of the channel the 2-byte value.
this is a big difference with RGB24_BIG and RGBA32_BIG, in which case _BIG
means the order is RGB (BGR) and not BGR (BGRA).
BGR48, BGRA64 could indeed be added, if needed.
I chose 0x11 and 0x12 arbitrarily, but given the order of channels 0x1011
and 0x1012 might make more sense. This would mean using another bit for "real"
bigendian colorspaces.
Only the color conversion to 32-bits is implemented.
Tested with the RAWTranslator modified to output 16bpp with success.
Found some references in enum AVPixelFormat in libavutil/pixfmt.h.
Change-Id: I4b023dec85d01f1e63e1b053139e5bb5d263a0e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4468
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This is a source compatibility break from BeOS, but should not
be an ABI one (I checked, the symbols are identical.)
Also use "= {}" in the definitions of the fields. We use this
in plenty of places in the kernel, so it should be OK for GCC2.
Change-Id: Ibe05b2236d46024d7b4563ae16e1cc7140fed965
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4434
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This removes the use of the destructor in the move assignment operator, as it
may rely on undefined behaviour from the compiler. Additionally, some duplicate
logic to dereference and free a shared string has been unified under
_ReleasePrivateData().
Change-Id: Ie9f51d598c734f83cd0fba49b651315c6e9c8aac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This implements the "rule of 5" for this type. While the copy operation for
BString was already using shallow copies of the underlying data, this change
further optimizes moving the data from one object to another.
While it is not the intention to implement move semantics to all types in the
legacy Haiku/Be kits, data types like BString are good candidates, because move
operations are often useful when working with data within an application.
In this implementation, the internal data of the string object will be set to
NULL, thus leaving an empty string.
Change-Id: I16bf9424f9b17f622b0b57659b80628e18760288
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4428
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
The USB Kit uses it, so this allows the USB Kit to stop including
USB3.h.
Change-Id: Ifde025ec41bef92013fda0440d60b7216cfdbe4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4413
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* We really should get out of the habbit of making up
our own architecture defines.
* __riscv with an additional __riscv_xlen is the
standard that developed... let's just roll with it.
Change-Id: Ieb777d48340ae25a6d66f66133afa0ec5c6da9b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4402
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Define thumbnail attributes in Attributes.h:
Media:Thumbnail to store the thumbnail,
Media:Thumbnail:CreationTime to see if thumbs need to be regenerated.
Store 128x128 thumbnail in attribute, for icon sizes smaller than
128x128 down-scale the 128x128 thumbnail. Use B_FILTER_BITMAP_BILINEAR
to down-scale the image using the bilinear scaling algorithm which
creates nicer looking thumbnails than the default scaling algorithm.
Store thumbnails as WebP images which compress smaller than PNGs and
fit in the inode better at 128x128.
Check the file's modification time in GetFileIconFromAttr() and compare
it to the thumbnail creation time. If the file has not been modified
since the last time we generated thumbnails return the thumbnail from
the attribute, otherwise fetch a new thumbnail with GetThumbnailIcon().
Add "Generate image thumbnails" Tracker setting. Default is turned off
for now. To generate image thumbnails you must first turn this setting
on in Tracker Windows preferences.
Spawn a get_thumbnail() thread to generate thumbnails and retrieve them
later on from the window thread to fill out into the icon. This should
improve responsiveness of generating thumbnails from a folder with a
lot of images. The generator thread will write the thumbnail data to an
attribute if on writable BFS volume.
If not on writable BFS volume, the generator thread will send the data
back to the original thread through a port by calling write_port().
When the thread is finished creating the thumbnail it sends a message
back to the Tracker application thread to update the pose which
instructs the window thread to look for an thumbnail. It either finds a
thumbnail in an attribute, or picks up the thumbnail data that has been
sent through write_port() using read_port().
This works on both read-write and read-only BFS volumes but it still
depends on the presence of a BEOS:TYPE parameter to have been written
to the volume before it became read-only. Thumbnail generation does not
work on other read-only volumes for example an ISO-9660 CD, but it does
work on read-only BFS volumes for example the BeOS R5 CD.
Move BPrivate::CheckNodeIconHintPrivate() from BNodeInfo to Tracker
Model CheckNodeIconHint(). Create Model::CheckAppIconHint() and look
for a vector icon or mini and large icon in that method. Check that
the base type is directory, volume, trash, desktop, or if executable
call CheckAppIconHint().
Add 1 to temp_name to fix the following warning:
src/kits/tracker/FSUtils.cpp:2437:12: note: 'snprintf' output 3 or more
bytes (assuming 267) into a destination of size 266
Rename temp_name to tempName following our style guidelines. Use
strlcpy() and strlcat() instead of strcpy() to safely copy the string.
This fixes thumbnail generation on 64-bit Haiku.
Change-Id: I7f927a5a1f8cf65e4b1aa1e0eb55bbfae87fd969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3163
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The APIs for this were introduced in ICU 63, so we'll need an update.
ICU 63 does not build with gcc2, so this method is disabled there.
Change-Id: Iabe49509ed6d4e578560d497d3ca336a97db4625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1874
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Fixes:
* Use uint64 instead of off_t when handling offset and size
of the trimmed range in the fs_trim_data structure
* BlockAllocator::Trim: Correct the size of a buffer
* ram_disk, mmc: Do not trim past device capacity
Improvements:
* BlockAllocator::Trim: Because the received offset and size
are ignored by BFS (the functionality is not implemented yet),
return B_UNSUPPORTED if the range does not cover the whole
partition
* ram_disk, mmc: More accurate calculation of the number
of trimmed bytes
* devfs: Add a uint64 version of translate_partition_access()
Change-Id: I24f4c08674f123ad33a5fef6e28996a4ada6ff0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4155
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
