Validate the candidate child device a bit more by checking the device ID
and the base and subclass of the device. We don't even know if the child
is still on the PCI bus and some firmware may mark disabled devices by
simply invalidating one of these values. Possibly fixes#8111.
Added TODO concerning that we might not want to fail at all since we
ensure that we matched all devices after routing preparation at which
state we would notice any missing child devices anyway.
While the log of hrev35726 says that unusable page ranges are supposed
to be marked with PAGE_STATE_UNUSED and allocated ones with
PAGE_STATE_WIRED, both actually marked with PAGE_STATE_UNUSED.
When limiting the available memory by reducing the page count it may not
be enough to just limit sNumPages. Depending on the physical memory map
non existing pages between ranges (sNonExistingPages) would still be
added up and later subtracted from the sNumPages, resulting in a wrong
max page count. Also due to the fixed removal of non existing page
ranges the actually available memory would usually not be the amount
set via LIMIT_AVAILABLE_MEMORY.
Instead we now calculate the available memory when going through the
physical memory ranges and limit/exit as soon as we've reached the
desired amount of available memory (also ignoring further non-existing
pages).
When a breakpoint is asked to archive itself to a message, ensure that
the message is empty before writing. Fixes breakpoints past the first one
being broken on restore due to each breakpoint archive containing
the combined settings of all previous breakpoints.
* Having defines in a header that are used only a single time is not helpful.
* B_TRANSLATE in a macro is only expanded when the macro is used, so it escaped collectcatkeys eyes.
* Ensure that we don't underflow the used_pages count and that used
+ cached pages don't overflow max_pages. As there is no locking the
values may change while we read them so that such situations could
arise.
* Make the TODO about the missing locking into a Note explaining the
above, as it is not really worth adding locking here. The stats are
only informational.
Due to a missing entry in Keymap's Jamfile, the localized strings of
ModifierKeysWindow.cpp are not yet included in the corresponding catalog
on HTA.
The attached patch adds ModifierKeysWindow.cpp to DoCatalogs and changes 'Ok' to 'OK'.
Fixes#8127
* break apart encoder type lookup to share with legacy
connector probe
* add function to check for external encoders
* reduce chip requirement to Avivo+ from R600 for register population
- When the user chooses the location of a source file via the file panel,
we now preserve the file panel so it can remember its previous location
when invoked again.
Resolves the other part of #8095.
- When adding files/directories into the file manager, we now also take care
to add them to their respective parent entry lists as well. This allows the
intelligent location functions to actually traverse directories to update
all sibling/parent locations properly as needed.
- Slight changes to ensure that the implicit/explicit status of the location
can be passed around throughout the process. Needed for the above to work.
Resolves the intelligent location portion of #8095.
CFE is used in the upcoming Amiga X-1000 dualcore PPC board.
* Largely inspired by the OF and U-Boot code.
* Still largely stubbed out.
* The loader builds but I don't have a machine to test it. Anyone interested?
* The altered used pages calculation of hrev43168 wasn't correct, as
the inactive page queue may (validly) contain mapped pages as well.
Those would then get counted twice (as they are included in
gMappedPagesCount already).
Instead we calculate the used pages from the total page count, minus
everything we account for otherwise. Doing it this way is possible
without introducing any additional counters, as all the counts to
subtract are already present (as opposed to some of the ones that
would be needed for adding the counts up). Fixes#8109.
* Added TODO regarding the problem of not locking any of the counters
which runs the risk of them getting modified while we haven't yet read
all of them.
Also includes some style fixes and checks on fTopTab which seems to be NULL sometimes.
Does NOT behave well with tabbing yet and still has some drawing bugs.
* Fixed issue introduced in hrev38139: restoring from the line
drawing table was hard-coded to UTF8 Ground table. That is wrong:
the table for currently configured encoding must be set back.
Please look on using of _GuessGroundTable() for details;
* Fixed issue introduced in hrev34894: the semantic of convert_xx_utf8
functions requires the destination length to be set equal to the
target buffer size. Pre-hrev34894 usage of "homebrew" conversion
functions was a bit different - destination length was set to 0.
This made any converstions of input data useless and produce no
visual results;
* Private list of supported encodings (Encoding.cpp) was replaced by
using BPrivate::BCharacterSetRoster functionality. That allows to
use centralized info about encodings in unified with other
applications (Mail & StyledEdit for example) way. Most of currently
enumerated in UTF8.h encodings now available in Terminal.
Note that UCS-2 and UTF-16 are temporary (???) excluded from the
list of encodings supported by Terminal.
* The B_UTF16_CONVERSION was added in system-wide UTF8.h declarations.
This character set is available for enumerating by BCharacterSetRoster
but not listed in public API. Looks like it was just missed;
* Special note about "Text Encoding" entry in Preference File:
So known "shortname" of encoding was used in the preferences file.
For details look on the encodings list in previous version of
Encoding.cpp. As result of migrating to BCharacterSet-provided
resources this list was deleted and is not available anymore.
Instead of it the IANA name of the character encoding targeted
to be used for this purposes. Frankly speaking this part looks
like not working at the moment. The value of text encoding is
hardcoded to "UTF-8" now and is not affected by any operations
in Terminal menu. Note that "shortname" for default encoding
was "UTF8" but the saved value is "UTF-8" - and they are looking
not dependent at all. So this change should not introduce any
kind of backward incompatibility.
