* like sigqueue() but for threads. was added recently to FreeBSD, long before to glibc.
* also include features.h in gnu/pthread.h
Change-Id: I73bca666e2c67d7ff05f341bf85d71df9ccccbe5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7659
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
FontStyle will be keeping the references, so the family will exist as
long as there's a style pointing to it.
Change-Id: I639f7914be924a84d5db5882c638a4dac665aa23
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7634
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
On font removal styles may still be referenced by views, pictures or
whatever else. In that case, what we were doing had the following
effects:
- The style is still available through the family. So it is still
returned when listing fonts.
- The style is not available by ID. So a few app server messages will
fail, including those for string width or character escapements.
Moreover, if the removal was due to an update, adding the style again
fails because we already have one by that name. If all the old
references are finally dropped, we end up without the old nor the
updated style.
We now do the opposite: until all references are dropped, a style can
still be fetched by ID (that is, by an object that loaded it before
being removed), but it is not listed anymore (so it won't be given to an
app loading a font by name or by changing the style of a font of the
same family).
Fixes: #18868
Change-Id: Ia64744afeb9297fd446e437d08636733b6dc0aec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7633
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In which case failure to find it in the styles hash table does not tell
us anything about the existence of its family.
Change-Id: I77c8960a96e7283547650daae67ea71fd022567e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7631
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
(And surrounding portions of the "btCoreData" module.)
* Rewrote the main "l2cap.h" header representing protocol constants
and structures. Now conforms to general Haiku naming conventions
rather than BSD ones. Some more constants added/removed based
on the most recent Bluetooth specification.
* Rewrote all code derived from the BSDs to match Haiku conventions
and structures in the driver.
* Dropped the "channel" and "frame" structures from "btCoreData".
Channels are now managed by L2capEndpoints, and "frames" are
now just plain net_buffers without surrounding structures.
This also makes state management much simpler.
* Made it so that actual net_buffers are passed through to the
l2cap_receive function rather than another data structure.
A fake interface address is used to communicate connection
information. (This probably ought to be changed, though.)
* Get rid of l2cap_lower and l2cap_upper abstractions.
Everything related to channel/endpoint management is now
done in L2capEndpoint, while buffer reception is handled
directly in l2cap_receive and elsewhere, same as other drivers.
* Wire up more hooks and fix module flags (needed to be able to
get the module loaded and opening sockets at all.)
* Implement an actual locking strategy in L2capEndpoint
and HciConnection. There's still problems with lifetime
management, but at least thread-safety is mostly handled.
* Create an L2capEndpointManager and use it to manage
the endpoints, rather than having a single (unsafe)
linked-list.
And plenty of other refactorings and cleanups besides.
There's still more to be done for Bluetooth overall, though:
* The "btCoreData" and "hci" modules also badly need a major
overhaul, and should be merged into a single "bluetooth"
bus_manager. They also shouldn't be passing around pointers
to other modules like this.
* There's a number of TODOs/FIXMEs in the L2CAP module, most
notably around timeouts (especially command timeouts) and
parameter validation/specification.
Tested by myself and kallisti5. Outgoing connections,
at least, manage to fully initialize and configure
successfully.
(And surrounding portions of the "btCoreData" module.)
* Rewrote the main "l2cap.h" header representing protocol constants
and structures. Now conforms to general Haiku naming conventions
rather than BSD ones. Some more constants added/removed based
on the most recent Bluetooth specification.
* Rewrote all code derived from the BSDs to match Haiku conventions
and structures in the driver.
* Dropped the "channel" and "frame" structures from "btCoreData".
Channels are now managed by L2capEndpoints, and "frames" are
now just plain net_buffers without surrounding structures.
This also makes state management much simpler.
* Made it so that actual net_buffers are passed through to the
l2cap_receive function rather than another data structure.
A fake interface address is used to communicate connection
information. (This probably ought to be changed, though.)
* Get rid of l2cap_lower and l2cap_upper abstractions.
Everything related to channel/endpoint management is now
done in L2capEndpoint, while buffer reception is handled
directly in l2cap_receive and elsewhere, same as other drivers.
* Wire up more hooks and fix module flags (needed to be able to
get the module loaded and opening sockets at all.)
* Implement an actual locking strategy in L2capEndpoint
and HciConnection. There's still problems with lifetime
management, but at least thread-safety is mostly handled.
* Create an L2capEndpointManager and use it to manage
the endpoints, rather than having a single (unsafe)
linked-list.
And plenty of other refactorings and cleanups besides.
There's still more to be done for Bluetooth overall, though:
* The "btCoreData" and "hci" modules also badly need a major
overhaul, and should be merged into a single "bluetooth"
bus_manager. They also shouldn't be passing around pointers
to other modules like this.
* There's a number of TODOs/FIXMEs in the L2CAP module, most
notably around timeouts (especially command timeouts) and
parameter validation/specification.
Tested by myself with kallisti5's help. Incoming connections
(on the PSM for SDP) get all the way to the latter half
of the Configuration step before hanging.
8cc8ec9ef9 fixed a problem due to BSpinner
using its own variable to store the value instead of resorting to
BControl's one. That was accessed with a inline method, so programs
compiled before the change get the spinner's value from a place that in
newer revisions contain garbage. Copy the value to that position after
changes, so that it is available for both old and new apps.
Fixes: #18898
Change-Id: I01679bfcb5b208e04ea85d7ec38cc655305d532a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7657
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Mostly deleting leftovers from where this was copied from IPv4,
and implementing some missing functionality.
Notable bugfix: is_empty_address was broken due to an incorrect
comparison.
* If a user selects 2 files whose names differ only in case,
right-drags them to a FAT volume Tracker window as a set, chooses
the move option from the drop-down, and chooses to continue if an
alert box appears, the second file in line to be copied will be lost
(this is consistently reproducible on my system).
* Eliminate the option to continue in this situation, so that the move
will always be aborted instead of progressing to deletion of the
second file from the origin directory.
Change-Id: I52197945fe28072eeddcd68e91ce5e7b8534b184
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7623
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Introduced in hrev57710, they are the remnants of a previous version of
the change, not needed with the final one.
Change-Id: I03dbb86fd8963897dfed7bd77772e4ac97a8e739
- Out of bounds index for values that would use a bigger unit than
available.
- Jumping from bytes to MiB, without using KiB despite being better.
- Wrong catalog key for base units.
- BSizeColumn showing incorrect values for sizes less than 1 MiB.
- Extraction of catalog messages for BSizeColumn.
Fixes: #18892
Change-Id: Ib36a30a29b425654ab569537b11c8c56093ddc2e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7626
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Introduced in 90510b4af9 with no use. As
those values are the page indices of the list in the settings window,
adding the later pages fail.
Fixes: #18890
Change-Id: I9b28f8b279163ea1b54e5659c95c2fd80bb88ed2
* Honestly, Vagrant seems pretty dead at this point.
* We didn't see many users of this.
* Hashicorp has been doing weird license things too
with BSL.
Change-Id: I2932a28fc6316266925e434c02bdd117c874d838
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7622
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Update: OnDisk format and manage endianness for the ShortAttribute Class.A separate private function to Swap endianness is implemented inside the Class
Change-Id: I348d6c0ac128fe56d63a16e4f10ff90708c6a7a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7582
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Errors are now enabled for all audio drivers.
Change-Id: Ia4e986f0ed8965376c3bbefc3d9f04bcd68ad561
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7621
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
The compiler complains about implicit declaration of free and calloc
despite stdlib.h being included. I think it's because of -ffreestanding
being used on the command line?
Change-Id: I57c3899e5034d1c2ee9cb6c1ed4c92aa818b53ea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7619
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
The driver Jamfile had a "-w" added to the compiler command line to
disable all warnings.
Use the generic util.c/h instead of having a separate copy.
Change-Id: I74e325850d573e75d652658748426c9ae353c6e7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7617
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
These have never been included in the Haiku build as far as I can see.
All the soundcards they support are already handled in the auich dirver.
All the IDE driver that ichaudio claims to support, I'm not sure why they
are in an audio driver.
One of them was written for BeOS and never updated for Haiku
multi_audio, and the other was apparently some experiment that didn't
get anywhere in the end. To avoid confusion, let's keep only one driver.
Change-Id: I5bf48e7dd2c5340e84a1ab4eb3e3b079103b7988
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7604
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- use shared (updated) util.c for memory allocation
- disable functions that are currently not used (ac97 suopport)
Untested, I don't have the hardware.
Change-Id: I9c406e46af94dfc213cfa258c5f375da3c0c719d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7603
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
Move util.c from auich (the most up to date version) to the parent
directory of ac97. Use it also for auvia. This means changing several
physical addresses to use phys_addr_t instead of pointers, and declaring
buffers allocated by alloc_mem to be user-accessible or not.
Untested, I don't have the hardware.
Change-Id: I2ababc713384cbf34174fbcecfb3595547a1fd97
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7602
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander von Gluck <alex@terarocket.io>
Part of #9460
* If there is an operation between signed and unsigned int, the unsigned is changed to signed one,
except for some operations (if before the operation the signed one is checked to be less than
zero or not, then the signed one get cast to be unsigned (errors due to sign error when casting
are impossible))
* When doing operations on pointers, integers get cast to uintptr_t type
Untested: I don't have the hardware.
Change-Id: I6a959c004862e055ee99f6f2ad5ca3397b32cdd2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7484
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Needed for the echo indigo soundcard driver build.
IRQ is used as a field name in pmcia/cs.h. The IRQ() macro should only
be used with parameters. So we can avoid the use of IRQ in cs.h being
accidentally replaced by the macro.
Change-Id: Ib10f3c5148cfb7c87a0b258a95a590778b6e5cb4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7608
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
In the new "automatic" mode, the number of displayed colors
is just 3, as opposed to the full 38. Much more manageable!
The HSL routines added in this commit were derived from
https://gist.github.com/ciembor/1494530 which is itself derived
from the Wikipedia page describing HSL/HSV.
Part of #15543 and #11636.
Change-Id: I230a358d18c379fb0673162e0b3cbdb8d1b8d84e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7479
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There seem to be a gcc2 bug resulting in bitfields of uint32 type being cast to int.
The bitfield is mostly not needed here, since the fields are 8, 16 or 32
bits, so just use the appropriate types.
Change-Id: Ie4297db8bcda8ca0937c7f55915b318a1f4f6e55
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7599
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
