Some symbols were available because they were reexported by haikuwebkit
1.8.2, but they won't be exported anymore in the next releases. So we
need to link to libnetservices.a directly, and link to it before the .so
files to make sure the symbols from the static library are used.
If there are undefined symbols, we can't load the kernel (the bootloader
complains about missing relocations). It makes sense to not allow that
at compile time.
Change-Id: I430bebada16544ffa8be293cd6c075338970d8ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4668
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This replaces the previous round-robin system. It should reduce
lock contention on multi-core systems, with potential other
benefits depending on drive behavior.
FreeBSD's NVMe driver does basically the same thing.
In most cases we don't need to use the complete display_mode struct and
we just need the timings. This will avoid future confusion between the
virtual width/height and the actual display timings, if we implement
scrolling someday.
Change-Id: I6c4430b84130b956a47ea0a01afb0843f5a34fd2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4665
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Apparently my comment about the width and height being swapped in this
register was not visible enough, so I make it a bit more obvious by
adding some uppercase.
Change-Id: I27621032d071ed09f82aa109f37482178351db04
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4664
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add a column to the table to show the publish
date. Also add text on the featured packages
view to show the publish date. Supports
sorting.
Fixes#13006
Change-Id: I19d9bc5bf7f44b5673c2ade5d00de8fdadbe1b06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4649
Reviewed-by: humdinger <humdingerb@gmail.com>
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The upcoming change to use zstd by default will make the -z no-argument
variant obsolete, so instead we need to support passing "zstd" or "zlib"
to actually indicate the compression method we want to use.
BZstdCompressionAlgorithm already has these #ifdefs and will
return error codes appropriately if built without libzstd,
so we do not need to check again inside the Package Kit.
This should not break the no-zstd build (well, it is broken
somewhat right now anyway, but this will not break it further),
and it simplifies logic somewhat.
This way, we get the user's environment variables, and so should
input_server, which is started by app_server.
This should, after 6 years, fix#12534. We may need to revisit this
when/if we add multiuser support, but that is a problem for another day.
Change-Id: I04698306bc68a585acd232e9f9d29c50bc170a1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Refactors so that we look for a codec subsystem ID, then the
Audio Function Group subsystem ID if not found.
* Moves the order around a bit so that the quirks are set early
enough.
* Also adds a quirk for MacBookAir 6,2, allows speakers to work.
Change-Id: I4c64f96936a82a5d7187d86d8558f28516fd4ecb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4654
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We still do not know if the accelerant buffers are graphics memory or not,
but in my testing (on the VESA driver), the only time I could get _CopyRect
to be called was where the buffer was in fact not graphics memory.
So that should provide a performance improvement there.
On the other end of things, this should resolve unaligned video memory
access problems on RISCV, and potentially other platforms, as gfxcpy32
did not attempt to align pointers; it should also improve performance
as memcpy will usually be faster than our custom gfxcpy here.
Most of this code has not been touched since 2006 or so.
Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It just causes confusion and is wrong in the case where double buffering
status changed during the object lifetime.
Change-Id: Ia1a9ae3f5a1b1b7d521b79c7d1c7be92cef60a06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4633
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
libtermcap was deprecated in favor of terminfo in 2013; the library was
removed then, and this file was only left because not all optional
packages had yet been rebuilt against ncurses. Well, that has now
long been completed, and indeed all applications continue to function
even after removing /etc/termcap.
In case any legacy applications that I have missed still do need it,
it should be provided by HaikuPorts and not Haiku itself.
These are better here than in my bash history...
Change-Id: Iab8940f4efed950e26a8bad29cb8954464270e8f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4645
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On Sparc Openboot, we get allocated a stack of only 8 kilobytes, and
each called function costs at least 176 bytes for the stack frame.
This means we need to be more careful than usual about stack usage. Move
some large-ish allocations off the stack by either making them static,
or allocated dynamically.
Add a compiler flag to error on functions which use too much stack. The
threshold is at 1023 bytes, because that's what allowed me to find the
two functions that were causing a stack overflow (open_from and
_ParseActivatedPackagesFile)
Change-Id: Ia0d13a9247e1a3fff4ce654bdffd6edb16e7cbc7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2371
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These are helper functions for long double math. On sparc there is no
hardware implementation of long double instructions, and the ABI defines
these methods which must be part of the C library. GCC calls the methods
directly in its generated code.
They were already added to libroot, but they also need to be in the
stub, which is used during bootstrapping to link mpfr (during the
target gcc build).
I put these in a separate file because I assume the generation of the
stubs file from the real libroot.so will usually not be run on sparc,
and will not include these symbols otherwise. This may become a problem
if libroot for different architectures starts to diverge further.
Change-Id: I6070394c685fee35b3dc12a507f5a6271571b993
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4636
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
