* Works a bit better with dark themes
* Has some interesting alternative design elements
* MIT licensed
Change-Id: I6cfd1d4d05016fb014d515d94cff3b8c8d0298b2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4508
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* 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>
Add lots of comments explaining things in the code. Also fix parsing
of Beta updates which have hrev version numbers with an extra bit at
the end, like hrev12345_67. Include architecture in the GRUB menu
title, so you can tell 32 bit and 64 bit installs apart. Switch
back to #!/usr/bin/sh, like all the other probes do.
Change-Id: Id47afe5029369c739d5177b1dd917c7d1d631ad6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4498
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I9c660b1569b5439f2cd9088fde4e96512e7817d8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4496
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Original version of 83haiku as seen in Debian Linux, for detecting
pre-package based Haiku OS and automatically setting up a GRUB
boot menu item for bootable Haiku partitions.
Change-Id: I0d1fe4c9b395e7912b2398ab6bac5c25d92aa64a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4495
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alexander G. M. Smith <agmsmith@ncf.ca>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
tested with success at least on VGA, see #16069. Thanks TmTFx and rudolfc!
Change-Id: I4183416b09216b111984658eb8b23c8f62a0e36d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2762
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
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>
On x86_64, the KERNEL_ARCH should really be "x86_64", but it was "x86"
as the architecture sources/headers directory is shared between 32 and 64 bit.
Should not be a functional change on any platform outside x86_64.
Size of gBootGDT[] is 'USER_DATA_SEGMENT + 1' defined at line 26,
and it equals USER_CODE_SEGMENT, so gBootGDT[USER_CODE_SEGMENT]
is out of bounds at line 44.
Change-Id: I1374f4d1185b6a47f910ac128d49a07cdd80d925
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4536
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Some are still in-tree and need to be removed, but this takes care
of all recent Intel, Realtek, and also the old Ralink chips.
This cuts down the size of haiku.hpkg by close to 10MB.
This reverts commit 6683314327.
Apparently, on closer inspection, this is not actually correct:
TARGET_KERNEL_ARCH is "x86" even on gcc2, and not an index into
the TARGET_CC_* etc. variable sets. That is pretty confusing and should
probably be fixed.
The static asserts are broken on GCC2 and so did not catch this. It appears
nobody has ever tried to use this structure on 32-bit plaforms in the upstream
libraries or SPDK/DPDK?
Fixes#15212.
They are not in any way architecture-specific. Simplifies the various driver Jamfiles.
This also paves the way for some upcoming changes that make the kernel always be built
with the non-legacy GCC...
We will pick up events that have no match later on, and if we return
an error here, it will prevent the job from being initialized, which
we definitely do not want.
Fixes#17291.
Translators and media-plugins are the main source of dependencies in haiku.hpkg,
and thus the main source of packages being pulled into chroots, especially
HaikuPorter chroots. (FFmpeg pulls in a rather large array of sub-
dependencies, itself.) So, here we break all the translators into their
own sub-package.
For now, haiku.hpkg is declared to depend on haiku_datatranslators,
so that users will not suddenly update and have no translators.
In the future, this will be dropped.
Note that this is only done for the primary arch at present.
Secondary architecture translators remain in the main secondary package
for now.
Change-Id: Id0b352f34f7110b79ec7787792bf3ae0edab4054
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4477
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Part of #9460
Change-Id: Ibcc30af0c2d351742cbedd6df15b2880b92edfee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4513
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Rename TRACE to INFO as it is always enabled.
* Rename TRACE_EXT to TRACE in line with other drivers.
* Move most previously-TRACE-now-INFO message to TRACE,
removing them from debug output.
This should get rid of the Highpoint-IDE syslog spam in every boot log.
We want to continue iterating until we have either reached the end
of the vectors or until we know that length is greater than MAX_FRAGMENT_SIZE,
so we need <= here, not <.
Fixes a problem that can arise with the
selection of language when adding or
editing user ratings.
Fixes#11316
Change-Id: I85625cdc156458d88f4d1ca01ae889d954364ffd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4511
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the external event is sticky and already triggered, then we want
to trigger any newly-added events immediately. This fixes "boot hangs
on rocket" regressions following 4f126f690c,
which seems to have exacerbated this already-existing race condition.
Fixes#17289.
Change-Id: Ie405826cc50255895c8831c34b8bdf902e584eb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4510
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Refactor ResolveExternalEvent to actually return the resolved event,
not just whether or not one was found, and then skip resolution
in TriggerExternalEvent and ResetStickyExternalEvent, which now
should only be passed ExternalEvents.
* ExternalEventSources now store destination Events, not Jobs,
following on that refactor.
* The second variant of ResolveExternalEvents is dropped,
and instead the Register/Unregister functions are implemented.
* Trigger and ResetSticky are now done in ExternalEventSource,
which now keeps track of whether it has been sticky-triggered
or not, though it does not use this information yet.
These changes should not affect behavior, they largely constitute
a reorganization (though some TODOs are resolved.)
Change-Id: I46a51cac0edb90e90b154ef9c94791cb7a1aad94
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4509
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is similar to with the registrar and debug_server,
both of which are started before app_server, already do.
In the case where we cannot connect to app_server for
_SuggestMountFlags, we default to read-only.
(This should however never happen, at present.)
axeld did all the hard work in 4bf862e368
but did not actually change the instantiation to use BServer. We now
do that, and pass "false" for "initGUI" to avoid connecting to app_server,
as syslog_daemon never does anything GUI related.
Only one #ifdef, the rest is all in basic if-tests. Relatively minimal changes,
and now the virtual keyboard device gets all the improvements made to the keyboard
layout view over the last 6 years.
The drivers do not support this properly at present, they would
run the other transfers interspersed with fragments from the fragemented one,
which is obviously the wrong thing to do.
No USB device drivers seem to do this at present (it would cause data
corruption if they had.)
Fixes#17275.
