Unless, of course, it has the B_BITMAP_CLEAR_TO_WHITE flag as well.
From my testing, not clearing the BBitmap matches BeOS's behaviour
more closely (if not exactly) compared to clearing the BBitmap.
My test program created the BBitmap and BView, drew a diagonal red line
across it, and saved the result to a file.
The results:
* BeOS - transparent background; red line with no anti-aliasing
* Haiku, current behaviour - white background; red line
* Haiku, new behaviour - transparent background; red line with
black pixels as artifacts of the anti-aliasing process.
The anti-aliasing artifacts, as PulkoMandy pointed out, are simply a
result of not using the B_OP_ALPHA and an appropriate blending mode,
and would happen on BeOS as well if the line had some transparency,
such as through anti-aliasing.
Change-Id: I09ac054eb0ce79e697b78ea48d1db4a15041e600
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7899
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
TCP times are measured in milliseconds, and so on LAN (or on two
VMs on the same host) we can wind up with round trip times of
less than 1 ms, which thus come out to 0. Tolerate this appropriately
rather than taking 0 to be a magic value meaning "unknown".
Change-Id: Ica827ee4ea353208291cf4348e9da8af6214b507
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7926
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The basic idea: target a window size large enough to fit one
second's worth of data in it, using the round-trip time to
condition when we make the computations.
If we don't have SACK (to reduce retransmissions on packet loss)
or the user has specified a specific receive buffer size, then don't
scale at all.
Send window scaling isn't implemented yet, as that more-or-less
requires more careful management of congestion windows and SACK
processing which we do not currently implement.
Part of #15886.
Change-Id: Ia2480e6981324d2663e47cb17e8fc47ccc5f9aa0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6364
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is more important when window scaling is enabled as otherwise
we will send large amounts of window-update ACKs needlessly.
Ideally we would just use fReceiveWindow here, but due to a
TODO it stays constant (or increases only) at present, so we
have to compute the window size remainder inline. Another
similar computation elsewhere failed to take the case when
the window is 0 into account, so fix that too while at it.
Change-Id: Ibcca258472940d7de2d1adc9f986ddb7245438be
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7924
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
The network stack (TCP in particular) does not handle path MTU
discovery properly (or at all), so we should avoid trying to
send (or advertise support for) frames that large.
Now that we use net_buffers for receiving and sending directly,
this value really is only the "MTU"; it is entirely possible
to receive frames larger than this successfully. So this should
only fix things and not break anything at present.
The CRC is handled within the driver and does not need to be accounted
for here (despite the fact that some of the constants used in MTU
assignment do include it in their computations.)
We need to not expose arbitrary previously-used memory contents
to userspace applications, but this also fixes a bug in that
POSIX specified partial pages in mmaped files should be zero-filled,
and without this, RAMFS did not adhere to that.
Should fix https://github.com/haikuports/haikuports/issues/10463
(which was earlier reported as #18903.)
Tidy up of the languages model handling.
Change-Id: Ie9f93dab0a91b4598da87e58cb065fc5272a7b74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7925
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If the send maximum segment size is very large (as it is on loopback)
and we have receive scaling enabled, we can wind up in situations where
the advertised window will basically always be smaller than the maximum
segment size. In order to avoid stalling until timeouts occur in
this case, check the advertised window against the default segment
size times 3 (which is around the size of ethernet MTU.)
The TIME_WAIT timer, when it fires, either sets FLAG_DELETE_ON_CLOSE
(if FLAG_CLOSED is not set), or releases the socket reference directly
(if it is set.) As we set FLAG_CLOSED in Free(), we only want to start
the TIME_WAIT timer if FLAG_DELETE_ON_CLOSE is not set yet.
Probably harmless since the timer was cancelled on deletion anyway,
but it doesn't hurt to be clearer here.
...in-order packets following out-of-order ones.
This more or less undoes 04468d614b2a9568d7f05c09c7d8bc48670989d9.
A closer reading of the specs indicates we should send duplicate ACKs
for every out-of-order packet even when SACK is enabled (and of course
send up-to-date SACK information with each duplicate ACK in that case.)
can be found on USB 3.1 xhci controllers in the PORTSC register
Change-Id: I11df7e22ca1ab71b42325f8c3db1e4745287feeb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7923
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The onoff value should be set to 1 for "on" and 0 for "off",
based on the FreeBSD code.
Change-Id: I8da7c905bc4af815f51563b6d9696692b29771db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7919
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
virtio can pass us packets with some of the checksums incomplete.
For now we just pass these to the stack without completing their
checksums; the stack will check only the CHECKSUM_VALID flags.
Tested with QEMU on Linux (IPv4, UDP, TCP, ICMP), seems to work.
Change-Id: Ifc13d931278849b6c4eec550444344e7f1bf53d1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7918
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The revision number is used to know if the font list has changed, and
that's where it happens.
Fixes the revision going back when a font directory is removed.
Change-Id: Ib9bb0f463177aff11665c0083604f4a7e35395eb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7921
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It may not be ID 0 if it has been changed from the default.
Change-Id: I9aef328ee243d85c2cd37b47666440e0e54e66c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7920
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
If SACK is enabled, then we do not need to send a duplicate ACK
for every out-of-sequence packet, just the first one; following
ones will get delayed-acknowledge'd with SACK information.
Under those conditions, this reduces duplicate ACKs significantly.
* Extend the volume size limit in bsd_device_init() from 32 GB to 256
GB.
* Permit read-only access above this threshold.
* I would like to do more testing before allowing write access above
256 GB.
* See #11119.
Change-Id: Ica7872d5f4c06415c1501f7a8ffb955785f91a29
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7911
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We can't allow applications to reference/unreference cursors,
this is a safety/security violation, and it being done improperly
lead to the reference counts becoming incorrect on the app_server
side.
Change AS_REFERENCE_CURSOR to AS_CLONE_CURSOR and adjust the Cursor
code appropriately. (In the future, copying BCursor without Clone'ing
the data in the case of custom cursors could be accomplished with
client-side reference counting.)
Then rework CursorManager to remove cursors at once on team deletion,
and otherwise clean up cursor reference management to let the
reference counting handle things.
We need to acquire our own references to these Cursors.
Fixes assert failures after the addition of more Referenceable asserts,
and may help with #13464 and #18275.
This matches Linux. New files created in these folders will still
have rwxr-xr-x by default, of course, but the directories themselves
should be usable by all users.
If it is, that could indicate a use-after-free (0xdeadbeef has the
sign bit set), or at least that something else strange is happening.
May help with catching/diagnosing KDLs in the network stack.
This (mostly) reverts commit 3ea7c99119a6ae7305a1579d7294e9b1b46810e5.
We no longer need this code after introducing the calls to send
net_buffers to drivers directly.
Change-Id: I31a2fdbbbe8203c53dbcc1e3b1fab2492c8651bd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7914
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It would be nice to reuse the data_nodes as ext_bufs directly
and save another copy. However, we can't do that at the moment,
because while data_nodes and MCLBYTES are the same size (2048),
the data_nodes contain a header structure at the beginning of
that data.
(Perhaps we should consider reworking net_buffer to store data
differently to make that possible. It would also have the advantage
that data_nodes would start on a page boundary or a half-page boundary,
which would make doing direct DMA with them much easier in this
and other drivers as well.)
Change-Id: I8cd3b82a90f328c7a5d2437e3e95413bd74537ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7913
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This paves the way for a variety of more interesting interactions
between drivers and the stack which are currently not possible
(e.g. checksum offload, #18744). The main advantage for the moment
is that we will save a memcpy of the buffer on each send/receive.
Adapt the virtio_net driver so that at least one driver is using
the new interface. Network still seems to work OK with it.
Change-Id: Ic5832e4865e3e1bed7462583ca1ffd16418d7cab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7912
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Does not actually break ABI since net_buffer had 3 bytes of padding
remaining unused.
Add the first two constants for this field: L3/L4_CHECKSUM_VALID.
These will indicate when the checksum of the packet is known to be
valid (good/correct).
Change-Id: I155b3ea51d1093e229677cb788a007560ddbd428
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7916
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
