The previous logic would link from the end of the ring to the start,
and the TRB there would always itself be a link TRB. Now, we avoid this
by linking back to the start from within the TD segments, and putting
the "Event Data" TRB there.
May help with some problems.
Change-Id: I92c4e135ee28c8c89646594a99fb40ee0d6c4484
Following the last commit, we can just let if_input
process the whole chain at once.
The logic here may not have been correct, and possibly
caused memory leaks under high-traffic conditions.
May help with #18585 and others.
There was a comment indicating where this happened, but then
there was a use of one of them after this point. Fix that,
and add { } around their use to prevent this from happening again.
The list of supporting applications is generated case-insensitive
by making all items lowercase, see
src/kits/storage/mime/SupportingApps.cpp:302
Force the MIME type to lowercase before calling GetSupportingApps()
or a MIME containing uppercase isn't found.
Fixes#18752
Change-Id: I38252cd1be8f059d7df4bf8775855b6343a489c0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7340
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
by default, AdapterIO is initialized with a BMallocIO object, which will
be extended indefinitely. Flushing regularly is necessary to avoid
excessive memory usage. Tested in StreamRadio.
Change-Id: I9f3142c0a2300ad44dc54ccf6932d41c9526320b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7302
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Rework the way in which the application deals
with screenshots so that there is a repository
of screenshots that is referenced from
identifiers on the package model and not that
the screenshot bitmaps are stored with the
model and not cleaned up.
Change-Id: I632def96852a518b3f6b1c8b81909de117bbbc54
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7296
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
sample for qemu: -device virtio-vga,edid=on,xres=1024,yres=768 -display sdl
display mode can be set in the Screen preferences.
Change-Id: If1d6aeecb208ce7c62c42eea1a95c71237c4375a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7038
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Instead, rely on commitment being done later, when the
protections are changed. set_area_protection() already
did just that, but set_memory_protection did not, so
it is implemented here.
Fixes#18733.
Change-Id: Ia58aee93faf1296fce69d723b12d0fa0a8440706
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7339
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* /dev/graphics/virtio_gpu/0 is a valid entry
* app_server doesn't set the initial mode if it's identical; use
0x0 as initial resolution.
Change-Id: Ica0323e6c5d78b39f05499edc93fa9c949b97dc8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7037
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Also use the standard kernel-wide constants for IO or memory space
rather than defining new ones, as well as the PCI constants for
address types.
Change-Id: Iad03f7666ad5121a5c9a398339aa1a191339a1d1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7336
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the max address for a PCI bus is not fixed, try to compute it from
the minimum and length (if available).
Change-Id: I23d87da32779d22324f944b5b359390f523ec7a7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7111
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Upcoming changes will make this method return values in _vnode even
when they return error codes under some conditions. To avoid easily-
caused memory leaks, this commit refactors the output variable to
be VnodePutter&, and all consuming methods to thus make use of Putters.
Should not be a functional change.
Change-Id: Id7b9066f8cd50c159d52c921b16e475e4e1de806
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7301
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
some laptops decide to not charge a fast full battery to not consume a cycle.
In this discharging state, the current rate is zero, thus no time left can be computed.
We add a state "Not charging" to clearly differentiate and avoid user confusion.
PowerStatus was triggering low battery notifications, this is also fixed.
Change-Id: I4745c78eb0863ab01fe34cb065707d068cff0f0e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7300
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Remaining non-uses are mostly in specialized functions that e.g. operate
on many file descriptors at once (like vfs_exec_io_context.)
Reduces "goto"s. Should not have any functional change.
In our C library we try to provide a "clean" POSIX/ISO-C set of include
files that strictly conforming applications can use. However, we also
want to provide some extensions that are commonly available in BSD or
GNU systems.
These are normally provided in a separate directory
(headers/compatibility/bsd) and additionally guarded by compiler defines
that can either be explicitly set, or enabled by default if the language
standard (selected from the compiler command line) is one with GNU
extensions (this is the default for GCC). This is controlled by a header
file called features.h.
However, for some headers it is not so simple to split the GNU
extensions apart from the other parts of the file, because it's not just
extra functions, but additional flags and defines.
So, we need the "features.h" mechanism to be available even in the base
set of headers, but not enable anything if the BSD headers are not in
the search path. The simplest way to achieve this is to have an empty
features.h in the base set of headers, that can then be overriden by the
one in headers/compatibility/bsd if needed.
Fixes#18732
Change-Id: Ia54d1206c2fba378ae276ed4232aee8443180afb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7287
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Draw warning and stop icons on top of the menu fields instead.
Remove conflict views, create a new file to hold StatusMenuField
and StatusMenuItem. Set the icon with them instead.
Change-Id: If6c00199f24ac4f4fc789f12cc6cdcd7a912418f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7209
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This fixes crashes that happen when scrolling list views in Icon-O-Matic
triggered by the BListView auto-scroll feature reintroduced in hrev57439.
Take out the auto-scrolling code from Icon-O-Matic, call BListView's
MouseMoved() instead since BListView's can scroll now. The BListView auto-
scroll feature has been updated to work with draggable multi-select.
ScrollTo(index) method has been moved from Icon-O-matic to BListView and
is used to scroll to an index instead of a selection since the selection
doesn't change while you are dragging.
Override BListItem's DrawItem() method to prevent it from drawing. I've
hijacked DrawItem()'s complete param to mean even or odd instead.
Everybody draws the same background PathListView.cpp and StyleListView.cpp
now push the frame over and draw text using SimpleListView parent class
DrawItem() instead of repeating the drawing code.
InitiateDrag got moved from the abstract DragSortableListView class to the
SimpleListView implementation class.
The following color constants have been added:
rgb_color kDropIndicatorColor = make_color(255, 65, 54, 255);
rgb_color kDragFrameColor = make_color(17, 17, 17, 255);
First one is the red drop target indicator line. It has been changed to
clrs.cc red which is the same as B_FAILURE_COLOR, but I didn't want to use
that InterfaceDef constant as it doesn't indicate failure in this case,
it's just a slightly different red.
Second one is the drag selection outline, it has been changed from pure
black to clrs.cc black which is a shade lighter than pure black.
Fixes#18707
Change-Id: Ib0b375d7d5641d458a6ce004a6dfeac551636698
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7215
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
- coded_picture_number, display_picture_number and key_frame are deprecated
- dump all of the frame flags
- add missing entries in the picture type list
Change-Id: I64f0f20833f9cf3f31f77b26b464b36f68a67998
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7251
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
ffmpeg already provides us with a framerate if it is known at the stream
level. If it is not known at this level, the framerate may not be fixed
througout the video, and so the best thing to do is to leave the media
kit field_rate unset, and let applications handle frames according to
their presentation timestamps as they come (this is what we had been
doing anyway, the code to output the framerate to the media kit had been
commented out for a long time and the computed value was not used)
Since ffmpeg removed the ticks_per_frame field [1], the code would not
compile anymore with later ffmpeg versions.
[1] https: //patchwork.ffmpeg.org/project/ffmpeg/patch/20230507133255.20881-12-anton@khirnov.net/
Change-Id: Icc0988c507965883a1570e46f904ebf235fb71bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7247
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
IMMEDIATE_ACKNOWLEDGE invokes SendQueued ... but with
a send window size forced to 0, so it just generates an
ACK (or a duplicate ACK as the case may be), and doesn't
actually trigger sending of data.
So, adjust the check, introduce a new action flag, and
invoke it properly.
Fixes traffic stalls caused by waiting for the
persist timeout to occur.
This amends hrev51540 (yes, from 2017.)
Change-Id: I6344463938cfaa0134bb8cf3e224789cded0987c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7285
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
First, we don't need to generate ACKs for every other
segment received, only every second full-size segment
or within 500ms, as the comment notes. So check the
receive window size before deciding to send an ACK
immediately.
Second, let the timeout routine handle sending the ACK
even in the immediate invocation case. This way, we
don't spend time in receive routines waiting for the
send path locks, and also multiple packets received in
quick succession will have one ACK generated instead of
many.
Also, following the previous commit, the timeout routine
will avoid generating duplicate ACKs now. In the case
where a duplicate ACK really needs to be generated,
DelayedAcknowledge won't be used anyway.
Inspired by ambroff's remarks and patch in
comment:14 of #18203.
Greatly reduces the number of ACKs generated,
and increases throughput due to less duplicate ACKs
causing congestion logic to kick in.
Change-Id: I37991464b1a802aceb3e2b453df8dc4cb2e14ce5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7284
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As the comment already notes, it's possible that we wind up
in the timeout routine despite the timer being cancelled, if
the cancellation was done after execution was in progress.
In either case, do not invoke Send if there is nothing to do,
as invoking Send...(force = true) will generate a duplicate ACK.
Duplicate ACKs will be noticed by the remote end as a sign of
congestion, so we don't want that to happen.
Change-Id: Iac30c140c322ccf0b0477e434459e7674bc24e1a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7283
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
A variety of things marked "not implemented" actually are,
at least partially, but the comment was not adjusted.
Change-Id: I760cca8ef3f601d27c0143f7dc75f5049d02f899
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7282
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Otherwise it's just confusing.
Change-Id: Ic88550c05a957b06917cfc08d1163ffe5b2e0652
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7281
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
