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>
It's not allowed to enable the screen before having set a mode. At least
in the case of the intel_extreme driver, this creates some problem. Move
the call just a bit later in the init process, where the mode is already
set.
Change-Id: Iaa665f0edc15316890032f1a5928f33634dc8749
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4362
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: François Revol <revol@free.fr>
Reviewed-by: <BeagleJoe13@gmail.com>
The window is not easily accessible from the application itself, so this
change is practically not that useful, but it's still a good idea to continue
replacing old BAlert windows with BAboutWindow in order for the Haiku source
code to be exemplary as far as developing applications is concerned.
Change-Id: I05ea971ed0f8a996d5e168066b18eb7fe8bd5b3e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4331
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
team.cpp address_space change is needed in
arch_thread_init_kthread_stack to set initial thread page
translation map. It also allows to simplify some debugger code.
DEBUG_PAGE_ACCESS check is currently incorrectly implemented in
RISCV64VMTranslationMap and disabled to avoid panic.
gHtifRegs = 0 change is needed to avoid using HTIF when it is not
available. gHtifRegs != NULL check is used to detect that HTIF is
present. 0x40008000 is TinyEMU HTIF address. HTIF is emulator specific
device that provide serial IO and shutdown capability (and maybe
something else depending on virtual machine).
Change-Id: Ic4d567b28c49799ae0f55223dd983a752823bab4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4328
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Use generic c versions of memset and memcpy
Wwrite fast asm for that later, therefore no need for arch_string.S
* Disable FDT and DTB until ARM64 is ready
(WIP: do it later)
* use ELF64
* Use generic c versions of memset and memcpy
Wwrite fast asm for that later, therefore no need for arch_string.S
* Disable FDT and DTB until ARM64 is ready
(WIP: do it later)
* use ELF64
* virtio_mmio for riscv64,arm,arm64
* enable new FDT bus for riscv64,arm,arm64
Change-Id: I5141de4e0bfcb44c5368dfafdf68ebf06ca5fb93
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4063
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* This models the CpuInfo into a cross-architecture
platform_cpu_info
* Originally I was looking at merging this with "arch_cpu_info"
however that is "overall cpu" while CpuInfo is "indivial core
information" packed into an array.
* Since every dtb platform will report individual cores in fdt,
having a common cpu core info struct with at minimum the core
id makes sense.
* This could likely be refined further to some kind of core info
packed inside of arch_cpu_info, but this will fix arm,arm64,etc
for now until someone wants to dive into that.
Change-Id: Ia18a352403cd0da7130c1e637fc205d4311478ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4363
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
alc(4): add support for Mikrotik 10/25G NIC
The new Mikrotik 10/25G NIC is mostly compatible with AR8151 hardware,
with few exceptions:
* card supports only 32bit DMA operations
* card does not support write-one-to-clear semantics for interrupt status
register
* MDIO operations can take longer to complete
This patch adds support for Mikrotik 10/25G NIC to the alc driver
while maintaining support for all earlier HW.
The patch was tested with FreeBSD main branch as of commit
f4b38c360e63a6e66245efedbd6c070f9c0aee55
This was tested on Intel i7-4790K system with Mikrotik 10/25G NIC.
This was tested on Intel i7-4790K system with RB44Ge (AR8151 based 4-port NIC)
to verify backwards compatibility.
PR: 256000
Submitted by: Gatis Peisenieks <gatis@mikrotik.com>
MFC after: 1 week
Change-Id: I83cdeb24caccad15a9647a72159d979ecbd647f0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4361
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
could help with #16238
1/ iwn: adjust EEPROM read timeout for Intel 4965AGN M2
Reading EEPROM from Intel 4965AGN M2 takes 60 us which was causing panic
on system startup.
2/ from 561d34d705
The value for field "barker_mrc" of struct iwn2030_sensitivity_limits
was obtained from linux 3.2 wireless/iwlwifi driver code (iwl-2000.c:115
.barker_corr_th_min_mrc = 390).
Change-Id: I730bd6106e0d76da89fff041672ccbc4ef607976
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4359
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Change-Id: I6cb31760519c8ba4542d217d6e68439602eda558
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4356
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I4b8f69271ede117701725f9cce30de5bb8ba30bb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4332
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Built-in function call ffs() causing infinite recursion.
Change-Id: I506c0301c3a19178ebca4478cbe2ea06a7aeb932
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4318
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
