The main CI workflow was renamed from "Build, lint, and test" to "CI" by
660e3ccb1c ("Build, lint, and test" => "SerenityOS") and ae6025987d
("SerenityOS" => "CI").
The new badge is based on the markdown created by the CI workflow page
"Create status badge" menu item.
From the shellcheck man page:
> This option defaults to false only due to ShellCheck's origin as a
> remote service for checking untrusted scripts.
> It can safely be enabled for normal development.
This allows us to remove the `shellcheck source=/dev/null` workaround
in most places.
This host controller is very similar to the one in the BCM2712, so
we can reuse this driver.
The Raspberry Pi firmware doesn't initialize the host controller,
so you need to boot with EDK II.
`take_first()` on a Vector is O(n), meaning this function used to have
O(n^2) behavior in the width of an image.
We can just use a span instead, which can be be advanced in O(1) time.
Makes
pdf --debugging-stats ~/Downloads/ignition.pdf
go from 10.2s to 6.7s, 34% faster.
Makes the first 50 pages of
pdf --debugging-stats pdf-stuff/Mellor_ACTITC_10.pdf
go from 65.9s to 13.2s, 80% faster.
Fixes#26082.
This is basically identical to the commit that added support for this
in text segments in #26078 (160b06eccb).
This is used on most, maybe all, pages of Mellor_ACTITC_10.pdf,
and on at least some pages of most files of the PDFs at
https://library.sciencemadness.org/library/books/.
arch_enter_kernel is more complex on AArch64 than on x86_64 or riscv64.
We have to initialize more registers, disable the MMU, and switch to EL1
if we entered in EL2.
We need to disable the MMU, as switching the MMU configuration is not
a single atomic register write.
While the MMU is disabled, no memory that was previously cached should
be accessed.
The rest of the code is very similar to the other architectures.
Most bits in that register have undefined reset values.
Also add some comments where these values are coming from.
LSMAOE is bit 29, so put it after nTLSMD (bit 28).
The EFI prekernel will enter the kernel at the entry point specified in
the ELF header.
The current pre_init code doesn't use the specified entry point, as it's
linked to a raw binary.
The EFI Prekernel needs the kernel to be relocatable, so build it
without --no-pie and stop linking the kernel to KERNEL_MAPPING_BASE.
Preprocess the linker script, so we can use PF_{X,W,R} macros instead of
using magic numbers, similar to the linker scripts of other
architectures.
pre_init now needs to relocate itself so it still works when linking
without `--no-pie`.
KSyms.cpp also needs to be changed, as it currently expects the kernel
to be linked to KERNEL_MAPPING_BASE.
We can now decode 144 of ignition.pdf's 233 pages.
The remaining pages all need support for custom huffman tables
stored in table segments. That's for later.
We can now decode 16 of ignition.pdf's 233 pages, up from 9 :^)
Most of the previous 9 successfully-decoded pages were empty pages.
We can now newly decode pages 1, 6, 17, 214, 220, 221, 229 -- all
contain actual text!
(Page 1 of annex-h.jbig2 needs support for grayscale MMR too, so we
still can't decode that yet.)
Implements: 7.4.3.1.7 Symbol ID Huffman table decoding
This requires making the existing huffman table support codes
that are 32 bit long.
The spec says "This is very similar to the "zlib" coded format
documented in RFC 1951, though not identical". We should explore
if we can share more code here in the future. In particular,
`assign_huffman_codes()` looks like it might be the canonical
algorithm for assigning canonical codes.
Not used for anything yet.
This requires adding support for the "lower range table line"
concept, for ranges that start at -infinity up to a given number.
I'm doing this for now by setting the top bit in `prefix_length`.
This is enough to get past 7.4.3.1.2 for both page 1 of annex-h.jbig2
and of page 1 of ignition.pdf.
Do this by just looking through all EndOfStripe segments of the
current page and determining the height that way.
Also add a few consistency checks for PageInformation / EndOfStripe /
EndOfPage / EndOfFile segments. (But there's more to be done;
we could implement 7.3.2.)
With this, we can decode the remaining 15 files (*-stripe.jb2) in
t89-halftone.zip, and we can decode 042_9.jb2 from the power jbig2
test file set.
I haven't seen this in PDFs in the wild.
As detailed in the second commit of #23639, 290c9541de, I created
that file by first running
Meta/jbig2_to_pdf.py -o foo.pdf \
Tests/LibGfx/test-inputs/jbig2/bitmap.jbig2
But when I created that file, jbig2_to_pdf.py did not yet strip
EndOfPage. It only learned to do that recently, in #26051.
So I ran that command again, then I copied over the new output for the
main jbig2 image, and manually updated the offsets in the xref
table for the two objects following that. I also manually updated
the offset to the xref table in the startxref part.
No real behavior change, but makes jbig2-globals.pdf more
PDF-spec-compliant.
I had extracted white_47x23.jbig2 and black_47x23.jbig2 from a PDF
(and then tweaked them). PDFs store jbig2 data in the embedded
organization. In PDFs, the EndOfPage segment is stripped.
But in standalone files in the sequential organization, the EndOfPage
segment is required per spec (see 7.4.9 End of page segment syntax:
"Each page must have exactly one end of page segment associated with
it.").
I appended the bytes
00 00 00 01 31 00 01 00 00 00 00
to each file. That's an EndOfPage segment with segment number 1,
associated with page 1. This should make the files valid.
(EndOfFile is only required for files in the random organization;
it's optional in the sequential organization from what I understand.)
This catches errors that occur within async tests so that we fail faster
rather than timing out due to `done()` not being called.
We use `Promise.resolve()` because `f` isn't guaranteed to be an async
function.
(cherry picked from commit 0de910784e498594f99017880b914b4cc2d4ad42)
Most JBIG2 files that use huffman-encoded symbol regions also use
huffman-encoded text regions, which we don't yet support.
But page 2 of annex-h.jbig2 uses a huffman-encoded global symbol
dictionary and arithmetic coding for everything else, so this
is enough to let us decode page 2 of annex-h.jbig2 :^)
I think we probably can't use CanonicalCodes here (this reads
in big endian order, it interleaves codes and values, and possibly
the codes aren't canonical). Maybe that's wrong, I'm not 100% sure.
But for now, let's get it working, and make it good later :^)
Sönke Holz