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.
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.
...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.
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 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.)
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.
Taken from FreeBSD; some minor cleanup elsewhere.
udp.h rewritten entirely as it contained no copyrightable
material and bears little resemblance to BSD's.
* 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.
* Remove all functions and a number of constants that neither
glibc nor musl define or support (and even FreeBSD does not
declare a good number of these anymore.)
* Redeclare the primary flags in terms of (1 << X) instead
of raw 0x... for readability (the constants at the end
do NOT match up to their definitions in glibc, musl, and BSDs!)
* Remove usage of unneeded headers, and __BEGIN/END_DECLS.
* Replace non-Haiku license headers with the ones from FreeBSD,
which notably contain a removal of the advertising clause.
ABIs remain unchanged, but a small set of applications that
use these esoteric APIs may not compile anymore (are there
any remaining?)
This beings the replacement of the libbind/netresolv-based implementation
with musl's equivalent. The code is less well commented in some places,
but it is well-designed and well-maintained, and the licensing situation
is much cleaner than the multi-BSD-licensed libbind-derivative code,
as well as being actively maintained (supposedly NetBSD has taken over
libbind/netresolv, but have not posted any portable code since 2013.)
The eventual goal is to replace the entirety of NetResolv with code
from musl, which will be an involved process as ABI compatibility
will be a problem. These functions at least are extremely
straightforward to replace.
Change-Id: Icfefaa90cbf56b012e4e42360be5b0f0c16d73bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2943
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Axel Dörfler <[email protected]>
These are not in the standard and are not declared by glibc at all.
The symbols remain for any applications that are still using them,
for now.\
Change-Id: Ie6b4a6b5ec3231c304e05ce9cb38c67d9ee51ad7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2942
Reviewed-by: waddlesplash <[email protected]>
This avoids creaing a semaphore where it is not needed, especially
as most of these locks are never used from another thread (in the
reports in #16246, there are thousands of semaphores from this
with only a small handful having a "last acquirer" != 0.)
On an idle system with 1GB RAM and the 100ms timeout, it takes multiple
minutes for all the pages in the system to get cleared after boot, but once
they do, the page scrubber will then remain idle for seconds to even
minutes at a time, so this is clearly worth it.
The "free pages condition" was unused before this commit, so I have
repurposed it (and unpublished it.)
Change-Id: I7034677a1e51c97c2baf11b772db3a31c0e1adfa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1699
Reviewed-by: waddlesplash <[email protected]>
The code here cannot handle the case where alignment > block_size,
so anything calling Init() with these parameters is invalid.
Fixes#15902 (nvme_disk was long since adjusted, so this is a defense
against code being written in the future.)
This reverts commit 82f985c036.
Reason for revert: Broke the build with this message:
/packages/groff-1.22.3-1-x86_64.hpkg: Scheme missing.
Change-Id: I9dea4986238cedfdc33c84739e69a331add09cdf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2896
Reviewed-by: waddlesplash <[email protected]>
This pulls in the final translations for applications for R1/beta2,
and also the new HaikuWebKit.
Change-Id: I2bfb8933dcf35239f6962f8bee2dea507dec6fd5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2869
Reviewed-by: waddlesplash <[email protected]>
The check as to whether or not the buf should be freed was wrong,
leading to incorrect frees.
Fixes double-free KDLs under the idualwifi driver that occur
on boot extremely frequently.
Change-Id: Ia411a6f5c31dd30764705cd87840797f862b4020
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2862
Reviewed-by: waddlesplash <[email protected]>
The goal here is to avoid potentially expensive fork()ing.
The time for a fork() is (for a process with no real heap usage
and thus few areas) 300-400us on my system. load_image() takes
3000us (3ms) or so, but this of course includes exec() time.
Overall, for compiling HaikuDepot (with a tweaked jam to use
posix_spawn on Haiku, not just on Linux) there is a slight
decrease in time:
before:
real 1m21.727s
user 1m2.131s
sys 0m43.029s
after:
real 1m19.472s
user 1m1.752s
sys 0m41.740s
Which is probably within the realm of "noise", so more benchmarks
are needed. Likely if we tweak our jam usage to not need as many
shells when running commands, this would be a much more noticeable
change.
Change-Id: I217f2476b1ed9aa18322b3c2bc8986571d89549a
On platforms (such as Haiku) where dash is available or can be installed
but is not the default /bin/sh, this can provide a significant improvement
to compile times vs. /bin/bash or other more complex shells.
At least under Haiku, this is around a ~10% "real" time gain for builds.
This also allows one to specify a JAMSHELL by passing that environ
to ./configure.
This class can potentially be accessed by multiple "tabs" (windows)
at once, so it must be read/write locked to account for that.
Fixes#16027.
Change-Id: I9cc741874caed4997497b03c8893bc2acb0e6fe7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2779
Reviewed-by: waddlesplash <[email protected]>
libnvme can break up transfers that are too large, but to do so,
it allocates one nvme_request struct (of which it has a large,
but finite, pool) per segment. Since we are already iterating
over "vecs", we might as well cut off transfers after they
would otherwise go over the limit.
Individual IOVs that are too large are left alone, though;
libnvme can still handle this. But at least we no longer try
to do all I/O in one go.
Tested in a similar manner to the previous commit.
The "offset" parameter was not actually an IOV offset, but actually
a byte offset across all IOVs... whoops. Somehow, this went unnoticed
as most controllers have large enough maximum transfer sizes
that we would in practice not hit the limit (even with bs=1M
dd tests!)
KapiX's controller, as seen in #16049, however, has a maximum
transfer size of 64 pages; much smaller than these other controllers,
so it did trigger this behavior and exposed the bug.
Tested by adding an artificial limit of 2 blocks as the max
transfer size (which makes things pretty slow, as you might
expect.)
I added this function to make the queued requests logic more robust,
but I failed to notice that since it is called from nvme_qpair_submit_request,
it would just result in a deadlock of any qpair that had requests
queued.
May help with some of the "qpair lockup" tickets.
Change-Id: I5ff63b509ae8812356d0d33f019027d3159b6685
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2735
Reviewed-by: waddlesplash <[email protected]>
We do not need to go through all the overhead of mutex_lock_with_timeout()
if there is in fact no timeout.
Change-Id: I7891ae9138a7d45be934ac53412b82546d52b901
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2730
Reviewed-by: waddlesplash <[email protected]>
As far as I can tell, there is no reason to ignore unlocks, ever;
if no threads are waiting, then mutex_unlock() will act appropriately.
So all we need to do is increment the lock's count here,
as we are relinquishing our request for locking.
On the other hand, if we did not find our structure in the lock,
that means we own the lock; so to return with an error from here
without changing the count would result in a deadlock, as the lock
would then be ours, despite our error code implying otherwise.
Additionally, take care of part of the case where we have woken up
by mutex_destroy(), by setting thread to NULL and checking for it
in that case. There is still a race here, however.
May fix#16044, as it appears there is a case where ACPICA
calls this with a timeout of 0 (we should make this be
a mutex_trylock, anyway.)
Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716
Reviewed-by: waddlesplash <[email protected]>
Otherwise, the entire list will be scanned for row widths, which
is extremely slow with thousands of items, and may not be what
the user wants anyway, if they have set specific column sizes
which are larger/smaller than that.
Helps with #16012 and #15889 considerably.
The size limits are already the minimum/maximum for all views,
not just the current one, so we do not need to recompute them
when the layout is invalidated due to an item switch.
Fixes#14675, and other performance issues on switching tabs
in layouted BTabViews, among other things.
Change-Id: I55bfe4ddb8c8a79c634634cfc27113205a790c42
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2677
Reviewed-by: Andrew Lindesay <[email protected]>
It does have a performance impact (as it serializes all VMCache
creations), and it is not that useful, so move it to KDEBUG_LEVEL_2
so that the beta releases (on KDEBUG_LEVEL_1) are not affected
by it.
(The nightlies are on KDEBUG_LEVEL_2, so this will not affect
them.)
Change-Id: Iab35d58f9d210651e3fd9027b75ea27a7a6928e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2612
Reviewed-by: waddlesplash <[email protected]>
Also remove the MINGW support, as it was far too incomplete.
This *should* work under case-sensitive NTFS, but instead,
it seems #14963 occurs. So perhaps there is a GCC bug
related to case-sensitive vs. case-insensitivity after all.
This is a "best of both worlds" approach: if nvme_disk
determines the I/O can be done with no bouncing at all,
it will do so; otherwise, the I/O is done by the _bounce
method that uses DMAResource.
Thanks to mmlr for helping investigate some of the DMAResource
crashes and other oddities.
Fixes#15818 and #15123.
This fixes the virtual/physical mixup problems that plagued
the driver until now.
This is rather inefficent, though, as it does its own page-based
bouncing instead of using DMAResource. That will come in the
next commit.
This is needed by CreateSubRequest, which creates a sub-request
using some subset of the passed IO vectors. In the case that the
last vector will not be fully used, we need to clamp its size
in the sub-request to the remaining length.
do_iterative_fd_io, used by vfs_read_pages (which is in turn
used by the file cache) used this to split up requests
into their constituent block-run requests. So, previously,
the invalid IO requests created by this could, under one possible
interpretation, overwrite valid file data and cause disk corruption.
It is slightly unfortunate that generic_size_t has no unsigned
equivalent, so we are left with 0 as the magic number here,
instead of -1. However, the passed "length" remains unchanged,
so any callers that pass the wrong value for lastVecSize
will be trapped by the assert added in the previous commit
Fixes#15912 (the assert added in the previous commit),
and potentially disk corruption caused by this.
waddlesplash