Hello Fedi, @weirdtreething @9lore and I are looking for project name suggestions.

We've been discussing it on-and-off for the past year, but I think it's finally time to split #chrultrabook into two projects.

Just to be clear: There's no drama, not even close. It's just that project grew exponentially, and 95% of support requests come from Windows users, which we couldn't care less about.

Main reasons behind this decision are:
1. Inability to get funding.
Chrultrabook being Windows-centric meant people assumed that paid Windows drivers funded the project.
That is absolutely not the case, as the only person working on Windows support is CoolStar and money goes directly to her.

2. Increasing complexity.
Machines are getting more expensive, and a lot of stuff is changing under the hood. For instance:
- IPU cameras are now standard on higher-end models
- Tablet mode and other various sensors were handled by EC (with exception of Dell machines that used ISH). It seems like noving forward, ISH (Integrated Sensor Hub) will become standard.
- Intel also introduced THC (Touch Host Controller) and various other "co-processors" as they're cosplaying as ARM.
- Disappearing support from Google and CPU vendors (Intel, AMD). Previously, Google's engineers were unofficially helping us behind the scenes. As nearly entire ChromeOS team was fired, we no longer have connections at Google to help us with stuff like publishing firmwares in upstream. I raised this issue this year, and been told that no firmware from ChromeOS will be published in linux-firmware moving forward (at least when it comes to Intel-specific platforms).
Google cancelled AMD Chromebooks (resulting in layoffs at AMD and re-structuring), while Intel is just generally struggling. Many people who helped us with stuff like audio on Intel's side were fired as well.
- Lack of documentation of any kind. Schematics are under NDAs, ARM vendors like Qualcomm or MediaTek refused to share any kind of documentation (even if we offered to sign an NDA), which means that we need to reverse-engineer ARM64 platforms (hence why progress is slow on that end).

3. Documentation.
Because of Windows users, we had to over-simplify documentation to the point where it's not really useful... to anyone. Not to advanced users, and certainly not to developers who'd be interested in helping.
Splitting the project means new documentation, where we hope to document every machine (or at least platform) with as much detail as possible (see postmarketOS wiki pages or my github profile as examples of that).
We're also hoping to create wiki-like website to host pictures of mainboards listing chips and various measurements, which should help people trying to fix their systems and reduce amount of e-waste.
Small taste of how it could look like: https://cros.sakamoto.pl/w/Main_Page

4. Mental health.
Community became unmoderable. Choosing Discord as communication platform was a mistake, people straight up refuse to use forums or github issues.
On top of that, 95% support requests come from Windows users who ignore any rules whatsoever and ask repeated quesitons that are answered in FAQ on CoolStar's website.
Because of that, we lost motivation to work on project (despite loving tinkering with those machines) and burned ourselves out.
We want to leave that baggage behind and focus on what we want to do, without dealing with support requests from Windows users.

5. Re-focusing.
We want to work on ARM64 firmware. Current state of coreboot on ARM is frankly abominable as a whole, full of hacks and regressions.
We want to improve it, despite platform-specific quirks.
Ideally you should be able to just flash the firmware, plug USB with Linux on it, boot installer via EFI and have standard booting method.

So, that's why we decided to move forward with this decision. We really want to get back on track, but it won't be under "chrultrabook" umbrella anymore.
chromebook hackers wiki

@elly @9lore @weirdtreething what's chrultrabook? and yeah, more predictable uefi on arm would be nice indeed, especially if we get more support for acpi, because I believe device tree files are a big part of the problem
@esoteric_programmer @9lore @weirdtreething ACPI is a mess, trying to add support for it would be a nightmare that I would dread implementing Linux even if someone would pay me for it.

DeviceTree has it's faults, but syntax-wise I will take it over ACPI any day of the week (and that comes from someone who has most experience with x86)
@elly @9lore @weirdtreething the problem with device trees isn't sintax, it's that the kernel or whatever has to have support for that board/device, and exactly that device, otherwise it wouldn't work doesn't matter how similar the boards are. Is that right? if so, then arm will be forever more closed than x86
@esoteric_programmer @elly @9lore There is no reason why we can't put the devicetree into the firmware. Then any generic kernel with the correct drivers enabled will work.
@weirdtreething @9lore @elly but you have to do that for each board out there, meaning that if you don't know of it specifically, there's no support at all, right?
@esoteric_programmer @9lore @elly Yes, but we are targetting platforms which have no new devices at this point, so we do know all of them.
@esoteric_programmer @9lore @elly This problem is also not unique to devicetee
@weirdtreething @9lore @esoteric_programmer In case of laptops (or embedded devices), ACPI is very board-specific. It doesn't matter whether you use ACPI or DT.

It's a bit obfuscated if you're using coreboot for instance, as ACPI is generated based on options you configure (like rootports or usb ports), but it's fundamentally the same.

With ACPI you get SoC-specific tables. On top of that you add SuperIO/EC tables. On top of that, you add board-specific tables (USB, PCIe etc).

With DT you get SoC-specific DT. You import that into your board's dts, you refer to root nodes (like USB controller, I2C, SPI) and add devices that are on those buses as well as their options.

DeviceTree is simpler, much easier to understand, and more transparent. The only problem is that despite Linux's policy of keeping DT bindings backwards-compatible, things do break. If people would decide on using compatibles and keep compatibility while making changes to drivers, there would be zero reasons why DT couldn't be passed from the firmware (like ACPI tables are).