bus_type has been added to MediaRoster.h and the serial driver.
It is not used enough to be in any shared header.
media_roster only uses it for buffer size estimation.
Change-Id: If4f372d44e871230da4744d99ec7cde0c79c8344
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5209
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Create and use *_mouse_acceleration_by_name functions to replace older *_mouse_acceleration functions. Now consistent with related functions (such as *_mouse_speed_by_name).
* Passing mouse_name to HandleGetSetMouseAcceleration in the BMessage fixes mouse acceleration changes not applying properly.
Change-Id: I668cdbbbb81e3cb9069a3fc2ce77e6ef75ba8476
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5189
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This assumes a Gen9 or Gen11 configuration, and aux channel 0. As a result, the same EDID will
be found for every DDI port. The mapping should be found in the VBT.
Tested on KabyLake and JasperLake
Change-Id: I27f5ac8ec8e6ba519fbe9aaf745e78a7361175b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5175
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Newer devices use a different layout for the backlight PWM registers
- Get the min brightness level from the BDB
Change-Id: I99745a022dd38733a4c2386f91c4c57016dd2acd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5162
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The old implementation used the real lock_memory(). This is problematic
and does not work for a large number of reasons:
1) Various parts of the kernel assume memory is locked only very
temporarily, and will often wait on locked memory to become unlocked.
The transient nature of locks is further demonstrated by the fact that
lock_memory acquires references to structures, like the address space,
which are only released by unlock_memory
2) The VM has a hard assumption that all lock_memory calls will be
exactly balanced, and maintains internal "WiredRange" structures
on areas, etc. corresponding to the original lock_memory calls.
Maintaining separate data structures as this code did is a recipe
for even more problems when the structures are manipulated separately,
leading to confusing or incorrect behavior on unlocks.
3) Areas with locked memory cannot be deleted, nor can the pages which are
locked be removed from the areas/caches. This of course is most notable
when destroying teams which locked memory, but the problem also occurs
when just using delete_area, resize_area, mmap/munmap, etc.
Because of (2) and especially (3), adding support for mlock()-like semantics
to the existing memory locking system is just not a good option. A further
reason is that our lock_memory is much stricter than mlock(), which only
demands the pages in question must remain resident in RAM and cannot be
swapped out (or, it seems, otherwise written back to disk.)
Thus, this commit completely removes the old implementation (which
was seriously broken and did not actually automatically unlock memory
on team exit or area destruction at all, etc.) and instead adds a new
feature to VMAnonymousCache to block certain pages from being written out.
The syscall then just invokes this to do its work.
Fixes#17674. Related to #13651.
Change-Id: Id2745c51796bcf9a74ba5325fe686a95623cd521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5147
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Resize(): adds more space to the end of the bitmap.
* Shift(): moves all bits in the map up or down.
* Use size_t instead of int for indexes.
Also add unit tests for the new functions (they seem to be passing.)
Reference material for shift implementation:
2c56d43c1e/bitops.h (L977)
Change-Id: Ia85768aaeed7bd3ffef3a9f575f05331e048fe50
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5146
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Internal display on my laptop isn't detected yet so modesetting doesn't
work, but at least I get vblank interrupts and backlight control.
Fixes#17569
Change-Id: I86dd56bc3fc2c288688242e34d9220028036ab74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5156
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
see Devicetree Specification,
section 2.3.5 #address-cells and #size-cells
The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed.
The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
Change-Id: Iafed49358540f8ac7aa673c3dc0191c9b580250b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This reverts commit 8497a2cc28.
The VFS layer is not at all ready for this. Many places in the
code implicitly assume ino_t values will never change. This
functionality is only necessary for live shrinking of partitions,
which is a feature niche enough we do not need to worry about
implementing it in the first round of resizing (if ever.)
Part of the point of published variables is to make them "shareable",
and not require external synchronization. Requiring the callers
to ensure unpublishing does not occur is thus unreasonable, as e.g.
a variable could be unpublished immediately after being notified.
That is the case for some usages of these variables in the FreeBSD
compatibility layer, which under heavy usage, can and did trigger
use-after-unpublishes and then KDLs, at least in local testing.
Instead, only unlock the hash after we have locked the variable.
This is already done in some other functions, so it's safe to do
it here, too. This way, the variable won't be unpublished
while Notify() is running.
Get the OEM string from the VESA info block (and also get the memory
size from there while we are at it). If the string is empty, use the
BIOS type (identified in other ways) to still report something.
Change-Id: I8cbd75d19f624a43db05e82d1e1b2a536cc418b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4625
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The VESA standard does not define any way for software to set a custom
video mode, which means normally we would be constrained to whichever
modes the video card manufacturer decided to provide. However, since we
run the BIOS in an emulated environment, it is possible (and even quite
easy) to patch it and inject any video mode we want, provided we know
the format to use and where to put the info in.
This approach was used in the NewOS VESA driver, as well as in
915resolution (a tool that predates the availability of native drivers
for Linux for Intel videocards). Later on it was also used in Chameleon
and Clover, bootloaders that are used for hackintoshes (running MacOS on
unsupported hardware).
This commit implements full support for Intel cards only, AMD and NVidia
will be added later (but there is preliminary code to detect them)
Change-Id: I2c528ba18b3863f486da694860a10761efcbfb3f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4624
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* move common SMP initialization code to x86/arch_smp.cpp
* factor out arch-specific SMP initialization to
arch_smp_32.cpp resp arch_smp_64.cpp
* implement smp_trampoline for x86 32-bit EFI loader
* rename SMP trampoline for x86_64 to long_smp_trampoline
* add new argument virtKernelArgs to arch_smp_boot_other_cpus
as the kernel args are not identity mapped on 32-bit architectures
Change-Id: I30d0bb1fa9bfb08f6784a2af34eb83d6b64afa57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4869
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* Resolves an issue compiling icu70
* FreeBSD is 262,144
* Linux is 2,097,152
* Haiku was 131,072
This roughly doubles the maximum args length, and makes us
function inline with FreeBSD today. If we're the shortest
straw, we're going to find a lot of things broken (such
as ICU 70.1) Matching FreeBSD means any limitations we see
will also be seen on FreeBSD, making fewer "Haiku issues".
Change-Id: I677c0523a2f27c9e9901fda4180445bcb6da31b2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4991
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>
Instead of the malloc_referenced system. Makes for some cleaner code,
and the malloc_referenced system was only used here, so it can now be
dropped altogether.
* Adjust a comment that now goes with 3 functions and not just 1.
* Remove spinlock switch function, this is useless as it cannot
change interrupt states here, but we require interrupts to
be enabled to wait on a ConditionVariable.
* Remove WaitStatus function from ConditionVariableEntry; unused
and would require locks anyway.
* Implement Publish using Init.
vendor_id shall come after the bitfields
Move hpet_address to separate struct definition so we can apply
the correct packed flags.
see also: https://wiki.osdev.org/HPET
Change-Id: Iced005846fedd4b895910e9b61137d5349db5b41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4859
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* We decided to not create our own custom define checks
and go with the standard ones for riscv64.
* clang doesn't define __RISCV64__ either, so this moves
the clang build of riscv64 a bit further
Change-Id: I2a6c3751168a898c1617b32f46055a9ba1609e2b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4861
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* The "size" parameter is the size of "out" not "in", and the
return size_t parameter is supposed to always have the total amount
of wchar_ts needed, not how many are actually used.
* In the case where "outSize == 0", we set "requiredSize" and then
return.
Fixes crashes seen in glib2 Unicode collation routines, which
are used in GTK file dialogs.
Thanks to PulkoMandy for glancing at this.
The old versions used pixel-count dimensions, not pixel-span dimensions
as the entire rest of the API does, which was probably a mistake
in the first place. The new APIs using BSize always use pixel-span
dimensions.
The old versions will shortly be deprecated.
Discovered while working on Xlibe.
Change-Id: I604a5ac6e0588420ff0b667d9193d60ac27b92c6
Change-Id: Iff9e4198aca706097889faf51e9559fe551126ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4782
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* We pack the first 8 bits into a union for the raw
edid since alignment matters.
* Handing the raw_edid is a bit ugly, so in the edid struct
we drop the input_type from the union since packing doesn't
matter as much.
Change-Id: I32dbfe9484f9eb83cf491a44d30a32ca36d65b7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4775
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
For now this is used on RISCV64 to indicate that interrupts will always
be on CPU 0. However, in the future, some architectures may want
or require interrupts to be "steered" in various ways, and this
also paves the way for that.
Change-Id: Iec79870cf5c4898d102d0e624de19602271ae772
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4721
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>
Before 2019, the entire ConditionVariable system was "giant"-locked:
that is, there was a single global lock that all ConditionVariable
and ConditionVariableEntry operations had to pass through. This of
course was not very performant on multicore systems and when
ConditionVariables see significant use, so I reworked it then to have
more granular locking.
Those patches took a number of attempts to get right, as having two
objects in separate threads that can each access the other not turn
into a deadlock or use-after-free is not easy to say the least,
and the ultimate solution I came up with erased most of the performance
gains I initially saw on the first (partially broken) patchsets.
So I have wanted to revisit this and see if there was a better way
even since then. Recently there have been a few reports of
ConditionVariable-related panics (apparently double unlocks),
notably #16894, and so that was reason enough to actually revisit
this code and see if a better solution could be found.
Well, I think I have come up with one: after this commit, Entries
no longer have their own lock, and instead accesses to Entry members
are almost always atomic; and there is now a case where we spin inside
Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable.
This leads to somewhat simpler code (no more lock/unlock dance in Notify),
though it is significantly more difficult to understand the nuances of it,
so I have left a sizable number of comments explaining the intricacies
of the new logic.
Note: I initially tried 1000 for "tries", but on a few instances I did see
the panic hit, strangely. I don't think the code that is waited on can
be reasonably reduced any further, so I have just increased the limit to
10000 (which is still well below what spinlocks use.) Hopefully this suffices.
Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores:
before:
real 0m23.627s
user 0m25.152s
sys 0m7.319s
after:
real 0m23.962s
user 0m25.229s
sys 0m7.330s
Though I occasionally I saw sys times as low as 7.171s, so this seems
to be at least not a regression if not a definitive improvement.
Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
GCC still assumes that the dirent has no data past the end for some
scenarios here and still mis-optimizes things. Therefore, drop the
usages of unions altogether, and instead use a casted character array.
Additionally, use B_FILE_NAME_LENGTH for the array, not B_PATH_NAME_LENGTH,
and make sure to add 1 for the NULL terminator.
The lock entry is the first thing in the struct, so this is a no-op
change, but it is safer to do in case of changes, of course.
Spinlocks have been structures for quite a long time, so this was
probably just missed in the conversion.
we don't sample if the last sample is too recent and use the cached result.
Change-Id: I17ed29bda7fe7276f1a4148b3e1985c9d32ae032
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4101
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This file should ideally contain only those things needed
across all system headers, even POSIX ones, and all other
declarations (B_* ones especially) should go in SupportDefs.h.
However, as nothing but riscv64 uses this right now, I've just
moved it to there.
GCC 11 treats [1] as a fixed-length array and not a flexible-length
array, and so some things that used direct strcmp("..", ent->d_name),
for instance, would be optimized out as being always unequal,
which was the cause of #17389. Using a real FLA informs GCC that
there is going to be more than one byte of data, and thus this
fixes that bug.
BeOS used [1] and not [0], possibly because it had to deal with
compilers (MetroWerks? Early GCC2?) that did not support FLAs.
GCC 2.95 does, using [0], and GCC 4 does, using [], so we can go
with that here.
(I did try using [0] for both, which seems to be OK with GCC 11,
but GCC 8 throws errors when d_name is dereferenced directly
as being-out-of-bounds. So, we have to use the #if here and give
newer GCC the [] syntax and not [0] to avoid that problem.)
The real question probably is whether or not we should backport
some variant of these changes to R1/beta3, as software at HaikuPorts
very well may run in to the same issue. (The alternative workaround
is to compile with -O1 and not -O2 for any affected software.) But
maybe this is an argument for keeping with the beta4 schedule of
this coming January...
At present, it does, but that is an oddity we have preserved from BeOS
that the next commit is going to remove. (This commit thus wastes 1 byte
without the following one.)
Most changes are pretty straightforward: only a +1 is needed,
and a few removed from sizing calculations. Some filesystems like UDF
originally passed back the length with the \0 included, so they have
been adjusted further. UFS2 had some other sizing problems which are also
corrected in this commit.
Our dirent structure is "slim": it has a flexible-length array at the
end which must be allocated to whatever size the consumer wants. However,
we use [1] there and not [0] or [], which meant GCC thought it was not
a flexible-length array, and so it optimized various string accesses
that it assumed must be always false. Among these was BDirectory's
check for "." and "..", and so that resulted in infinite loops.
When changing our dirent structure to a proper FLA instead of [1],
GCC then throws errors on LongDirEntry as it has data "after" the
FLA; which is what we want, but there is no way to tell GCC that.
So now we use a union instead, which is the proper way to statically
allocate a FLA.
This is part of #17389, but the real fix requires changing our dirent
structure, which is coming in a separate commit.
As suggested by PulkoMandy. This was done before my commits yesterday,
but those just reverted patches that had only been in since May,
so it's not clear how much this is actually needed. Nonetheless
it seems like the more correct thing to do.
While FreeBSD and glibc feature-guard it, they also feature-guard
a lot of other things that we don't, and musl does not guard it,
so it seems more than safe enough to leave it unguarded.
Fixes compilation errors with GCC 11. (The other possible solution
was including features.h in more places, but this seems simpler.)
* A few things need alignment, instead of forcing them all
to align themselves, support alignment of the kernel_args
* Default of 1 is "no alignment"
Change-Id: Iff05dcec8adaa963c8444d701464ea11616062f6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4698
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Catch errors and report them in bus parsing code
* Align the FDT kernel_arg to 8-bytes
* we still choose BSD-2-clause :-)
Change-Id: If2a88b7f131025ff1c1a2d903ed52f039e5bbcb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4694
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
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>
This way it becomes much easier to write multiple console implementations
in one bootloader.
Tested for bios_ia32 and efi.
Change-Id: I67134f5c3de109b15d46898864ba7f51c6592afc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4642
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Delete dropped out networks.
* Add in newly discovered networks.
* Add static (aka class) compare method to WirelessNetworkMenuItem
that is used to sort items by signal strength descending.
Add == operator to wireless_network struct to determine if
existing items have a known network attached.
Remove the non-network items from the menu, save them, sort
network menu items, then add non-network items back into the
menu.
Update NetworkStatus preflet to use same compare method as Network
preflet. signal_strength_compare function had a bool return value
instead of int which worked to sort items the first time, but does
not work on successive compares.
By not deleting and recreating the menu items each Pulse(),
the Network preflet no longer crashes on update. The menu flashes
on update still but doesn't crash.
Fixes#12024
Change-Id: Ie5b22cea4e66350b9c5df8e3b8de266ede50ad6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4243
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
... methods which call the respective methods in BList.
These convinience methods allow you to sort a menu of menu items
via a compare function, swap two menu items, or move a menu item
to a new index. Update items layout if menu is open.
Previously there was no easy way to rearrange menu items in a menu.
Change-Id: Ice3d6e5404e895196d8bd32d696dce7c55bd72d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4296
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This cuts out almost 40,000 lines of these headers. (I did something similar
in the atheroswifi AR93xx/94xx driver when importing it from FreeBSD,
which had a lot more than 40,000 lines.)
The code in this module was derived from the one in driver/tty. However,
the driver uses a shared lock between the master and slave side of a
TTY, and this was changed to use two separate locks. The approach with
two locks does not work. It seems the change was unfinished and the
second TTY was never locked. But attempting to lock it will result in
lock inversion problems, unless we do complicated things (try to find
which of the two TTY is the master side, and lock that first, for
example). It is simpler to restore the shared lock as used in the
driver.
To set up the shared lock, I modified the tty_create function to take a
pointer to the master TTY when creating the slave. Maybe it makes more
sense to create both sides in the same call, create_tty_pair?
However, this does not work as easily as I wanted, because there is some
recursion going on: at least in one case, the tty_control function is
calling the driver's tty_service function, which in turns attempts to
call back into tty_control for the "other side" TTY. To handle this
case, replace the mutex with a recursive_lock.
Fixes#17091, where the root problem was access to
other_tty->select_pool without locking. This was also made unconvenient
to debug because select_pool objects are self-deleting, when the last
item in the pool is removed. As a result, the code accessing it without
log would suddenly find out that the data it was accessing had been
freed and erased.
This also makes the TTY code in driver/tty and generic/tty a bit more
similar than it was before, and brings us one step closer to merging the
two together. There are still two main differences and I don't know
enough about TTY to decide if they are important, and which version
should be kept:
- The driver has extra code for "background" read and write. I don't
know what this is used for.
- The driver has a single "settings" instance shared by a master and
slave TTY, while the module has two separate instances, but seems to
copy one to the other. I'm not sure which approach is correct.
Change-Id: Ie2daddd027859ce32ba395af76b4f109f8b984b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4604
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These will be needed to implement custom modes in the VESA driver.
Change-Id: I9b52de691baa14e1f1a3ccce500ced9bb040b113
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4622
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Now that it is not used anywhere in the source tree following
previous commits.
Change-Id: Id2fc417a0658d09148e99587c613a928f1fbe4c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4611
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This reverts commit 3e8376c6dd.
Reason for revert: Bootloader currently fails to load kernel
It should be added back once the kernel can start.
Change-Id: Iebefbf8681aff4dff09cef7b7eb832b61f7789c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4579
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Someone on the internet found out gcc only understand posix_memalign.
The alloc_align attribute may be applied to a function that returns
a pointer and takes at least one argument of an integer or enumerated
type. It indicates that the returned pointer is aligned on a boundary
given by the function argument at position.
Change-Id: I4b0af6ef3020da1fb460652117286193d5d72f1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4514
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: Ifadd47204be1ec688017a567d43dca38c80bd1df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4431
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Set first stack frame return address to
<commpage>commpage_thread_exit, so it will be called
when thread entry point returns.
Change-Id: Ide5cde8d4501eb7241e03ff4052174e984e78870
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4493
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
These were used in function_remapper.cpp but can be used elsewhere too,
so move them to a private header. Also use them for the stack protector
hidden function definition (probably not so useful since gcc2 doesn't
support using the stack protector anyway?).
The gcc2 way to make a symbol hidden is to manually generate the .hidden
directive in the assembler output. This is not perfect: it is hard to
use for C++ functions and methods (manual mangling of the name is
needed), and inline assembler can only be inserted inside functions. But
the alternative is patching gcc2 to add support for the function
attribute, and I don't want to dig into that today.
This is an old version of libc++ that was imported in an early attempt
of building Haiku with clang. It is currently not used for anything. In
fact there never was a Jamfile to build it.
* PCI ID's from Linux
* There are a bunch of NAVI quirks around 3d rendering pipelines
but not many around modesetting (which is the only thing we care
about)
Change-Id: If63e31fe1d37d9d95f2a71c222a4cda7a2914a5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4467
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Only one code change: for some reason, GCC chokes on the cr3 functions
as macros (throwing errors about invalid registers.) The BSDs have them
as inline functions instead, so they are converted to that here.
Tested and working. There seems to be about a 10% decrease in CPU time
on some compilation benchmarks that I briefly tried.
Change-Id: I31666297394d7619f83fca6ff5f933ddd6f07420
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4515
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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>
It was removed in hrev55422 as we never had declared it in any headers.
But it seems some software came to depend on it anyway. Reinstate it,
and add a declaration for it, behind _GNU_SOURCE.
This is a source compatibility break from BeOS, but should not
be an ABI one (I checked, the symbols are identical.)
Also use "= {}" in the definitions of the fields. We use this
in plenty of places in the kernel, so it should be OK for GCC2.
Change-Id: Ibe05b2236d46024d7b4563ae16e1cc7140fed965
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4434
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
