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>
Most importantly include zstd, which is a new requirement for the
bootstrap build.
Change-Id: I981401e7d70fb7e1befaf7fc37f2fddc6d7e327d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4635
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is an internal ICU library, used by their command line tools only.
libbe (or anything in Haiku sources) does not need to link to it.
Change-Id: Id322572c6833c225d5501a7e9520dd3dc82934f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4634
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>
The other Atheros drivers are "atheros813x" and "atheroswifi",
so renaming this one (which is the oldest of the set) to match
the other two makes sense.
This is the driver for Intel's new line of desktop-class ethernet
controllers, from FreeBSD. Not yet included in the builds as it
is untested.
Part of #17212.
Now that there is also a "tap" driver in here, and the WiFi drivers
are also in a subdirectory, moving the physical ethernet device drivers
to a subdirectory also makes sense.
(Briefly) discussed on the mailing lists.
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>
There is no need to construct and destruct nested objects. The new and
delete calls on the struct will take care of it. However, some fields
have C functions for construction/destruction and these should be
called.
Change-Id: I09d5930f499ef3fa4ff580d482c682172b00b6a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4603
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Suggested by axeld on the mailing list a while back.
strlcpy/strlcat NULL-terminate within the passed buffer size,
so we have no need to subtract 1 here.
The changes for iflib reorganized some things that these drivers used,
so here we upgrade them as well.
One new chipset is supported in rtl81xx, the rest should all just be
API changes.
In 47404f12f2, a MemoryDeleter was added
to manage this memory instead of doing it manually; most of the free()s
were removed in that commit, but these were somehow missed.
It will be needed in the VESA driver to locate things in the VESA BIOS.
Change-Id: Iab42886beb99414fec4d1ad99a08299be679b4d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4623
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>
This will be used for live patching of the VESA BIOS.
Change-Id: I66c2dfd950262b5ba4d1e7b424eac46f0695297a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4621
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should resolve the problems where the framebuffer driver was
getting picked instead of the "real" graphics driver, when available,
which led to the framebuffer driver getting merged back into the VESA
driver.
Change-Id: I4ad00d2ac3b5dda34aa63f8691d4cbb85e4f6bb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4616
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit a0db7ef272.
This reverts commit 40cdf7d607.
This reverts commit 2ff22d6734.
This reverts commit b9eacd390d.
This partially reverts commit 5ae7ac5fd9.
This was all added in the run-up to the removal of the framebuffer driver,
or was added since then to enhance framebuffer-only support in that driver.
Change-Id: I32ab8199f22cf6846545ae19e943c98012b2a1d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4615
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 72fc5e6a71.
They were removed because app_server often picked them instead of
a better graphics driver, and fallbacks merged into VESA instead.
That seems to have created more problems than it solved, in the long run,
and so the intent now is to change app_server to understand the
framebuffer driver as a fallback one instead.
Change-Id: I6edd97fb29ed2b9c13c6c540569695c8426ecfd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4614
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
