Modifications made on hrev55413 removed UsageID from array Items,
but also (bug here) broke UsagePage, needed by KeyboardHandler
in order to recognize items as Keyboard ones.
Fixes#17263.
Change-Id: I4b73c69240f31d3c8c2aacf6bab0d270f2053387
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4458
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Follow-up for Alan Shearer's change. Useful when the buffer contains the
character "%".
Change-Id: Ia6771a2d71306ca97e7c03f0e986ad3cfe100684
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4459
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
the file position corresponds to the end of the buffer.
Change-Id: Ib67dcfe1f43d959777c2f6dbf84181f25a022a7c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4447
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* I've added support to multiple min-max ranges to array reports too.
* All possible usages are stored in an array (Vector<uint32>). Perhaps, this can be squashed into an array of ranges.
* Usage array is stored in HIDReport class, so there is only one copy of it.
* HIDReportItem no longer has UsageMinimum()/UsageMaximum() as this no longer works. Instead, a Usage() member has been introduces.
* HIDReportItems of type variable, have a Usage ID assigned to them. HIDReportItems of type array have a zero usage ID as it has no sense.
* Having a variable typed HIDReportItem to store a range of usages ID doesn't seem a good idea to me because Data() method would have to return the values of all usages... or perhaps ask for a specific usage value with something like Data(0x03). This will require changes in hid stack and overcomplicate things.
* A bitmap keyboard is a worst-case scenario: Near a hundred of usages (uint32) are stored and the same quantity of HIDReportItems are created (this is already happening on Haiku). It doesn't seem a resource drama to me.
* Keyboard Handler has room for improvement, but I would like to left that for another patch series.
Change-Id: I556fa0aebfda831ef5334be5ae3a37f099ffa35d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4403
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This helps with creating a sysroot, otherwise extracted package
links refer to /system, which is outside of the sysroot.
* Should have no functional impact on Haiku, as these are already
symlinks
Change-Id: I29f719dc2c0839dd090e7f33eea0b8f98e0d6355
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4218
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Some applications may request per-page protections for an especially
large area (e.g. multiple GB), which leads to allocating a rather
large page protections area (e.g. 512KB), which we cannot allocate
without locking the kernel space to get new slabs.
We only need to avoid locking the kernel space if the area in question
is in the kernel space, as in that case, kernel space will already be
read-locked by the current thread.
Fixes#16898.
Change-Id: If52413a594da66edfc2821811d959085a2c3c78e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4436
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This codepath is only hit for especially large malloc'd areas that
do not fit into an object cache, which is a rather rare case to
have in tandem with DONT_LOCK_KERNEL_SPACE, but we need to be
prepared for it in this code anyways.
Probably this codepath would previously have caused a hang due to
attempted double lock of the kernel addres space. Unfortunately
it appears our rw_locks do not actually detect that at present,
so likely I should investigate that next...
Change-Id: I3c9059d3e3939271beeeff221ebc921bc07ddf00
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4438
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This removes the use of the destructor in the move assignment operator, as it
may rely on undefined behaviour from the compiler. Additionally, some duplicate
logic to dereference and free a shared string has been unified under
_ReleasePrivateData().
Change-Id: Ie9f51d598c734f83cd0fba49b651315c6e9c8aac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4440
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Video generated by DemoVideoProducer is now displayed correctly
Change-Id: Idaed170a355ae7ed0b50c143a5c6c33da1393551
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4401
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Most of the ClonedNode methods just forward calls as appropriate to
fNode or fClonedNode, but missed that fNode is itself always an ObjectNode.
Now we store that, and forward on the two relevant ObjectNode calls.
This fixes kernel stack trace function demangling where the symbols
contained clones (e.g. "[clone .localalias]", etc.). Before this commit,
such symbols would just appear as "()" and no more.
The "[clone...]" block will in such cases appear after the function name
and not after all the function parameters, as the two are returned
separately and there is no way to indicate how they should be printed
in the kernel's API usage of these functions.
ClonedNode was only introduced a few months ago in hrev55147,
so this has not been broken for too long.
This file just uses fprintf(stderr, ). Probably it should be
converted to use macros...
This allows for easy debugging of silence by restarting the media addon
server in a terminal. Eventually we should fix#17245.
Only on non-GCC2 for now, as GCC2 does not have -fvisibility.
An opt-out is left as a possibility, and is unfortunately necessary
for libshared and libicon, as these two are used even in WebKit instead
of linking to the .a. However, libcolumnlistview, libagg, and a whole
bunch of others are now no longer exported, so this is already a major
improvement on what symbols we were leaking.
This may provide performance differences for consumers of these APIs,
as GCC and the linker are now free to merge and directly use functions
that previously could have been semantically interposed. AGG usage in
app_server, especially, may benefit.
We can also now remove the addition from libnetservices, so do that.
That is, it will now pull in NEEDLIBS and LINKLIBS set by LinkAgainst
from static libraries also built by Jam. This allows specifying what
libraries other static libraries need only once (in most cases;
occasionally things are not evaluated in a sane order and then
this does not quite work.)
Use this for libnetservices.a, which needs libshared.a, so that
dependencies on it do not have to be declared within most in-tree
consumers of libnetservices (e.g. Package Kit, http_streamer, etc.)
This implements the "rule of 5" for this type. While the copy operation for
BString was already using shallow copies of the underlying data, this change
further optimizes moving the data from one object to another.
While it is not the intention to implement move semantics to all types in the
legacy Haiku/Be kits, data types like BString are good candidates, because move
operations are often useful when working with data within an application.
In this implementation, the internal data of the string object will be set to
NULL, thus leaving an empty string.
Change-Id: I16bf9424f9b17f622b0b57659b80628e18760288
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4428
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Otherwise, the symbols will be re-exported into whatever shared
libraries the static library is linked into, and potentially conflict
with other applications that also linked against some other version
of the same library and symbols.
Fixes#17134, or at least the crash portion. I couldn't get any
audio or video to play here, they seemed to just cause WebKit to
stutter and hang a lot when trying to load pages with them. Maybe
that's expected behavior, though?
We are no longer running these addons on BeOS.
Change-Id: I4baa562bfdfaab56a92689c29d068ec59b2ee9d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4433
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If the incoming node is still pretty generic, we have to specialize
the input format to the output format in order to not be left with
wildcards.
Additionally, ensure that the frame sizes match up. MultiAudioNode
silently rejects buffers that are not sized precisely as it wants
them, so we need to attempt to have equivalent frame counts
on either end.
* We are no longer on BeOS and can now use format_is_compatible
and format->SpecializeTo.
* Remove set-but-unused media_format in node_output.
This allows AudioAdapter to connect to MultiAudioNodes.
However, no sound is produced. I have yet to determine why.
In the meantime, this seems to at least not break audio.
Change-Id: I983a496556c52a4ccde0c2cd165c659d597b84c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4432
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Apparently BeOS' SpecializeTo() was broken, and so when this code
was introduced in 2003, it came with its own copies of the
specialization routines.
We don't run on BeOS anymore, and our specialization routines
appear to be identical to these, so, we can drop them.
Should not result in any functional change.
This path normalization was functionally a recursive lstat(), which
should theoretically be identical to rooting the path in the CWD
and then normalizing the rest of the components after that.
Well, a recursive lstat() is much slower than simple manipulation.
How much slower? Well, on my system, the existing lstat() version
took up a combined total of 63,284,607 us for building haiku.hpkg
(only the package itself, no other components rebuilt), while
this new version uses just 47,901 us -- and this just for a @minimum!
I performed a full @nightly build with both versions in use at once,
with an abort() in place if paths ever did not match, and it
did not fire once. (I even sabotaged the new function just to
ensure that it would actually find differing paths.)
This code was merged in 338b8dc301 (2005),
and has remained largely unchanged since then. I don't know what the
rationale was at the time for using this method instead of this much
simpler version. Perhaps the 3-argument normalize_dir_path was written
first and used more, while this 2-argument version was added later
as a simple shim? But the original commit has no uses of the 3-argument
version aside from the 2-argument one...
Either way, this is an absolutely unbelievable speedup to Haiku builds.
These functions are hit in every I/O operation of all libroot_build
users, and their usages really do add up, as the example above shows.
Fixes#16288.
Change-Id: Ia11f64b0d4106ee62f22741a32ccc0c75c184442
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4427
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
It seems GCC has the same behavior as Clang now, so we can ignore
errors generated while preprocessing. (Previously we did anyway,
before the recent commit adding -e to JAMSHELL flags, so this
just continues previous behavior.)
* Drop ArchUART8260 layer to reduce complexity. It's whole
existance in life was to adjust the mmio alignment.
* Fold architecture mmio alignment into DebugUart
* We could potentially pass a Init(int mmioAlignment)
arg in the future if the macros get too messy.
* Move Barrier code back a layer into DebugUART
* Fixes the arm uart and EFI build
Change-Id: I0f127d902993e9f6e6a03cac8c7c37c0363134bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4422
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We have a number of "actions" blocks in our Jam rules with more than
one command, and so without -e, the actions will only fail if the last
command does. This is clearly not what was intended in virtually all
cases, so we should pass -e to the shell to ensure any command failing
causes the whole actions to fail.
I am kind of surprised that nobody noticed this before now, even
in the original Jamrules going back to the Perforce days. I only
noticed it because I experimented with making "rm" fail to find
places where it was invoked instead of $(RM)...
Change-Id: Id83a1aeb9736be1d08ba10bb52ab81f2cab11625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4426
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Some logs are emitted even when nothing at all is happening, constantly
spamming the syslog. Log them only the first time they happen.
Change-Id: I81511a7ce245c2141fa3dcd141b2f3732d9b51ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4424
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
In some cases, we don't need the full tracking of every byte received at
the PS2 level, but higher level traces from specific devices will be
enough.
Change-Id: I31984e6b7784b5d033b457f43f3793f772213f4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4423
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
