We will pick up events that have no match later on, and if we return
an error here, it will prevent the job from being initialized, which
we definitely do not want.
Fixes#17291.
Translators and media-plugins are the main source of dependencies in haiku.hpkg,
and thus the main source of packages being pulled into chroots, especially
HaikuPorter chroots. (FFmpeg pulls in a rather large array of sub-
dependencies, itself.) So, here we break all the translators into their
own sub-package.
For now, haiku.hpkg is declared to depend on haiku_datatranslators,
so that users will not suddenly update and have no translators.
In the future, this will be dropped.
Note that this is only done for the primary arch at present.
Secondary architecture translators remain in the main secondary package
for now.
Change-Id: Id0b352f34f7110b79ec7787792bf3ae0edab4054
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4477
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Part of #9460
Change-Id: Ibcc30af0c2d351742cbedd6df15b2880b92edfee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4513
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Rename TRACE to INFO as it is always enabled.
* Rename TRACE_EXT to TRACE in line with other drivers.
* Move most previously-TRACE-now-INFO message to TRACE,
removing them from debug output.
This should get rid of the Highpoint-IDE syslog spam in every boot log.
We want to continue iterating until we have either reached the end
of the vectors or until we know that length is greater than MAX_FRAGMENT_SIZE,
so we need <= here, not <.
Fixes a problem that can arise with the
selection of language when adding or
editing user ratings.
Fixes#11316
Change-Id: I85625cdc156458d88f4d1ca01ae889d954364ffd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4511
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the external event is sticky and already triggered, then we want
to trigger any newly-added events immediately. This fixes "boot hangs
on rocket" regressions following 4f126f690c,
which seems to have exacerbated this already-existing race condition.
Fixes#17289.
Change-Id: Ie405826cc50255895c8831c34b8bdf902e584eb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4510
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Refactor ResolveExternalEvent to actually return the resolved event,
not just whether or not one was found, and then skip resolution
in TriggerExternalEvent and ResetStickyExternalEvent, which now
should only be passed ExternalEvents.
* ExternalEventSources now store destination Events, not Jobs,
following on that refactor.
* The second variant of ResolveExternalEvents is dropped,
and instead the Register/Unregister functions are implemented.
* Trigger and ResetSticky are now done in ExternalEventSource,
which now keeps track of whether it has been sticky-triggered
or not, though it does not use this information yet.
These changes should not affect behavior, they largely constitute
a reorganization (though some TODOs are resolved.)
Change-Id: I46a51cac0edb90e90b154ef9c94791cb7a1aad94
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4509
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is similar to with the registrar and debug_server,
both of which are started before app_server, already do.
In the case where we cannot connect to app_server for
_SuggestMountFlags, we default to read-only.
(This should however never happen, at present.)
axeld did all the hard work in 4bf862e368
but did not actually change the instantiation to use BServer. We now
do that, and pass "false" for "initGUI" to avoid connecting to app_server,
as syslog_daemon never does anything GUI related.
Only one #ifdef, the rest is all in basic if-tests. Relatively minimal changes,
and now the virtual keyboard device gets all the improvements made to the keyboard
layout view over the last 6 years.
The drivers do not support this properly at present, they would
run the other transfers interspersed with fragments from the fragemented one,
which is obviously the wrong thing to do.
No USB device drivers seem to do this at present (it would cause data
corruption if they had.)
Fixes#17275.
These come from the Haiku Newsletter, issue 56 article 2, which I
managed to retrieve the source from the Wayback Machine. (They
are based on applications from Be's Sample Code distributions.)
Jamfiles not yet included; the source is in unmodified form,
except the RSRCs have been decompiled to RDEFs.
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>
* Without this, kernel will crash on boot when a framebuffer
isn't provided by bootloader. (like on the riscv64 today)
Change-Id: I5ec64db30972c7c3b19e4cdb31f0fe72b5982c0f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4494
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I44211b3533f99338d7246e88593fc8838628904c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4485
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* For riscv64,arm,etc, the controller init is used to
parse the fdt to detect the PCI controller.
* Without the controller being init'ed, we don't yet know
the base registers of the PCI controller for io activity
on a lot of architectures / platforms
* x86 doesn't seem to use the io regs until well after
controller init
Change-Id: I2a04e30e4dc675657b5cd9183240dafd35473998
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4484
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Refactored version of X512's original work to split out
the ecam and fu740 PCI Controllers
Change-Id: I631885af03b0118fb0084ed7aa4a5aa0a355b0fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4435
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This fix is for ticket #9460 to potentially enable -Werror for JPEG2000Translator.
Original warning: 'char* strncpy(char*, const char*, size_t)' specified bound equals destination size [-Wstringop-truncation]
- Replaced several occurrences of same string with existing constant.
- Use strcmp instead of strncmp as one string is guaranteed to be null-terminated
- Replace strncpy use with strlcpy as seen in other code places.
Change-Id: I5e7ed0de10dc40447a64fe77a7909af577e128ac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4472
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The pre-allocate functionality was added to Haiku in hrev54704. It needs
support at the file system level though, and it is yet to be implemented by
BFS. Some applications (and glibc!) implement a fallback mechanism using
ftruncate(), including the LLVM tools, but they go to this fallback
mechanism when it is clear that the operation is not supported. In particular
they look for EOPNOTSUPP.
The current implementation returns B_UNSUPPORTED from the vfs layer when a
file system does not implement the feature. This error code this not map to
a POSIX error. This change converts it to EOPNOTSUPP.
Change-Id: Ief382b0f4d462dfedf84c731f68f69731de4498c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4492
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Now that we are not setting fFragmented in VectorLength(), we can
reset it in SetVector based purely on the length of the newly set vectors.
We also need to set it in SetData, as SetVector does not call this.
This fixes an oversight in bc7fd43358.
In a few instances, we need to not wait for objects to become unbusy
during ID puts because we expect they still will be, e.g. in the case
of Control pipes with submitted transfers that are still running. There,
we need to put the ID, cancel transfers, and only then wait for the
object to become unbusy.
Technically, this is a functional change, but at least in practice
it will have little real-world effect, for two reasons:
1. The DefaultPipe's Busy flag is basically never updated (the Device's
busy flag is generally used instead), so it will virtually never be
"busy".
2. Most devices have no Control endpoints besides that default one.
Change-Id: I32ff4094effeac9ec74546c9643ea2025418e1c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4491
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way, any endpoints or interfaces which are currently using the
default pipe for SetFeature/.../etc. will return immediately and
become unbusy.
Should fix the remaining KDLs in #16794 and #16969.
Change-Id: I6615fc03394a0c50eae1ca7da2fb43f243841613
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4490
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This mostly only matters for the Device DefaultPipe, which is still
accesible even after its USBID has been put, but it makes sense to
do this in general, too.
Change-Id: I6711f1ce8fe79dff54927e3b5e60dec15bb58b14
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4489
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Control pipes have internal structures to wait for queued requests.
When force-cancelling queued transfers, the callbacks will not be called,
and so such transfers would be left hanging until the timeout occurred
or the destructor destroys the semaphore and mutex.
This probably will not fix any hang-related tickets, though, as force
cancellation is pretty much only used during device/pipe teardown.
Change-Id: I41db7caf380cdd082bc3509e95262317489bf100
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4488
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I was not actually aware that our USB stack already supported
breaking (bulk) transfers up into smaller units as necessary;
these APIs are not very well documented.
This makes #15569 occur far less often, though it is still
more than possible to trigger.
It did not return the length of the vectors, but only the current
fragment's worth of vectors. It also modified the fFragmented flag,
which really should have been set in SetVectors in the first place.
As everything seemed to call IsFragmented after VectorLength,
this is not a behavioral change.
This allows us to stop storing the package flags, which saves 4
bytes per package node (a value that really adds up when there
are thousands upon thousands of PackageNodes), at the cost of an extra
sizeof(int32) allocation for the WeakPointer object per-package (of
which there are are much fewer, of course.)
This also is safer overall, as now consumers of GetPackage() or VFSInit()
will now hit a NULL dereference if they have failed to check if the
package still exists, instead of a use-after-free.
Change-Id: Iea97ffcd491c6e2da7093730a7fa951b84dcefdf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4478
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This is both more correct, as we need to not read past the 'size'
position of the passed pointer, and much faster, in the case where
the passed pointer is into some very large block of memory.
This provides an unbelievable speedup to a microbenchmark posted on IRC
that makes heavy use of this function in tandem with some rather
large allocations. (Some variants of it go from multiple minutes
to under a second!)
