* Get rid of fPacketSize and use fSamplesCount in GetBuffers instead.
* Clarify logic in _TransferCallback.
* Properly multiply in kSamplesBufferCount to fAreaSize
(this should be the only functional change in here.)
The larger buffers (now similarly sized to HDA at least in the
default cases of 44100 or 48000) seem to help with jittering
and discontinuities, which are significantly reduced now,
at least under emulation.
In hrev55048, checks were added to bail on initialization if invalid
audio formats were present either in inputs or outputs, which broke
any audio nodes that supported only one or the other. Now, instead,
we check channels first, and even then do not bail on invalid formats,
but simply do not declare support for inputs or outputs respectively.
This solves the initial cause of #17235. However, that ticket refers to
an unrelated problem this bug merely exposed, and so it should remain
open until that is resolved.
Stalls cause "HALTED" conditions on endpoints, so use B_DEV_STALLED.
Also clarify the comment referencing the specification, and add a
missing linebreak to the error message.
* Allocate the descriptors array separately from the data area.
* Clone the data area for kernel use separately from userland use.
Fixes the remaining SMAP problems with this driver.
An "Input" terminal in USB audio terms refers to any stream of audio
going "in" to the USB device, whether that be from the outside world
(e.g. a line in jack) or from the computer (e.g. via USB OUT endpoints.)
So we cannot rely on the terminal type to tell us whether it is an in
or an out for our purposes, we have to check the stream type, and then
use that to declare to multi_audio what kind of stream we have.
Fixes USB audio mixing up inputs and outputs, especially on devices
that only have one or the other and not both. (QEMU manifested
this problem.)
This may help fixing lgtm build failure "There is not enough space on the disk".
Change-Id: I5db5748b73e611ec6b66a8effdf5ad39969f9bde
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4415
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@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>
It seems this has been broken since I originally wrote it in 2019,
but it only gets called in two scenarios: on device unplug (where
it does not really matter), and on interface changes (where it does.)
Apparently very few people tried to use devices that depend on interface
changes, because those would have been totally broken by this.
There were actually two bugs here:
1. ConfigureEndpoint should not be called with the Deconfigure bit set.
(See inline comment.)
2. The first bit must be set in the context add flags.
Fixes#14971 at least, and possibly others as well.
...to usb_endpoint_superspeed_companion_descriptor, as it is
really SuperSpeed-specific (there are more companion descriptors
introduced in SuperSpeedPlus.)
No functional change, and this is a private struct at present.
* 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>
Including thread.h brings a massive array of things with it from
the kernel thread arch headers, team and thread definitions,
hash tables, linked lists, Referenceable, etc. that the vast majority
of AutoLock.h consumers neither want nor need.
So, put these in a separate header, and adjust all consumers of these
lockers to include the new file.
This change exposes the fact that a lot of files were inadvertently
making use of headers included indirectly through thread.h. Those
will be fixed in the next commit.
* Set driver module name of device_node.
* Set device module name and path for published devices.
This helps to understand what driver is used, and it's /dev path in the
Devices app.
Change-Id: Ibd902a322da7e4276052bd4429a7b869a56a592b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3390
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Previously these were just using the raw function name, which led
to markers like "Slab_begin". Now we prefix RANGE_MARKER_ so there
is absolutely no chance of confusion, and the symbols are clearly
visible in dumps.
Also add a note that the kernel must be built with -fno-toplevel-reorder
for these to work. (It seems when this was implemented, GCC had not yet
implemented top-level reordering.)
They are only used for debugging with the tracing system in a handful
of places, and -ftoplevel-reorder is enabled with optimizations for
a reason, so it makes more sense just to note this and not to enable
that option by default (i.e. in the off chance someone will want to
use these in non-debug builds, like I did.)
Will allow USB3, 64vCPU, NVME, etc. Versions below 13 are only for vmware products currently EOL.
Change-Id: I83303ab985f615852267e2539b350f72f05231e7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4410
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unfortunately it does not work, I get this when invoking
allocations_per_caller at the kdebug prompt:
92513 9162096 0x0000000000000000 <NULL> + 0x0 (commpage) (nearest)
12602 2108408 0xffffffff80132a50 _Z23add_alloc_tracing_entryP11ObjectCachejPv + 0x70 (kernel_x86_64)
The stack tracing system must be broken, or maybe it has never been
properly adjusted for x86_64.
If the timeout is already >= B_INFINITE_TIMEOUT, we do not need
to do any of the following math (which would usually overflow anyway)
and can leave the timeout alone.
Spotted by kernel undefined behavior sanitizer.
For the kernel team, we now assign it in team_init instead of having
a special case in Team::Team(), making things more similar to the
userland team creation.
Should not change any real functionality as Team::Create calls
almost nothing outside of this file.
This translator only supports still images for now, and supports both
decoding and encoding.
Encoding support has been tested only with aom, rav1e doesn’t build on
Haiku yet, see https://github.com/haikuports/haikuports/pull/5534 for
one of the missing dependencies.
Change-Id: I716f4b862ed316b89b227bfed38072d72074201f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3040
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 "update dependency versions" step automatically adds the requisite
versions to this file during the build based on whatever the build
system is actually using, so this is not necessary; and it seems
that some architectures besides GCC2 are still on a version of ICU
less than 66.
... so that you can see the extension.
Change-Id: I0c3cdcede912f6ccc7dfb8360bfd82599c8117c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4323
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We do not actually need a SetupFeatureObjcetsDir here, as this build feature
is used unconditionally if it is available (unlike OpenSSL which is not,
and which needs a feature objects directory.) It appears FeatureObjectsDir
expects to be called unconditionally, i.e. in an "else" as well as "if",
so this actually caused some build oddities.
Additionally, since it is built unconditionally if available, we have
to put it outside the "regular" checks in the PackageInfo so that it
will be included in the images. This fixes booting @minimum images,
which was apparently broken at some point when "zstd" was inadvertently
removed.
* Merge all except the x86_gcc2 one into a single "generic" one.
It is now exactly the same on all architectures, save a single
ifdef for x86_64, which needs a different compat version, as there
are still some packages built that far back and never rebuilt since!
* Group the requires according to category: first any arch packages,
then commands, then the GCC syslibs, then packages always depended
upon if they are available, and finally packages only depended upon
in "regular" builds.
* Put all packages inside HAIKU_BUILD_FEATURE_* ifdef tests,
and order them alphabetically within their category.
If I have done this all correctly, at least x86_64 should get an
identically generated haiku .PackageInfo as before this commit, save
the reordering changes. Others may differ based on package availability,
as they were missing the requisite #ifdef sections.
This is a BeOS app compatibility fix.
The comment in SetBits implementation said that B_RGB32 imports only
24 bits of the data, but that doesn't seem to be correct.
Fixes#12931
Change-Id: I826a7e358ea379b8bf1550c899e82b623e5c21b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4319
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
An effort was started some time ago to consolidate all internal
documentation in the git tree. However, this was just an accumulation of
files in various formats without any strucutre or way to browse it,
which results in no one even knowing that we have docs here.
This converts most of the files to restructuredtext and uses Sphinx to
generate an HTML browsable user manual (with a table of content and a
first attempt to put things in a global hierarchy).
There are almost no changes to the documentation content in this commit
(some obviously obsolete things were removed). The plan is to get the
toolchain up and running to make these docs easily available, and only
then see about improving the content. We can migrate some things off the
wiki and website, and rework the table of contents to have some more
hierarchy levels because currently it's a bit messy.
Change-Id: I924ac9dc6e753887ab56f18a09bdb0a1e1793bfd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4370
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@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>
