With a less intrusive patch.
I'm thinking that the hs400 values for other gru devices are statistical
outliers, since most rk3399 platform seem to use hs200 for this.
It looks like *not* having `quiet` in the kernel cmdline somehow makes
the early init of the framebuffer fail.
I don't know the exact difference, but lowering loglevel rather than
using quiet doesn't work here.
In addition, this changes
The patches added here are required to build under some conditions, but
not all are ended up needed as CONFIG_DEBUG_FS is required to be active
otherwise the kernel doesn't even boot :/
The kernel size was reduced by:
* Removing tracing support
* Removing unneeded exfat and sdcardfs filesystems
* Removing all sound support
* Removing video input (camera) support
The latter options seem awfully shortsighted, until you remember that a goal is
to eventually deal with booting our own kernels through kexec.
The Moto Z Play device's boot partition size is putting us in a hard
spot.
Ah! It looks like this is not a constant, but a common failure mode
among android-based devices!
In dmesg:
```
Warning: unable to open an initial console.
```
Simply removing the `console=` fixes the console.
See f295dc1739 for a similar instance of
the issue.
This broke things subtly in the initrd.
The argument came from an OEM image. It might not affect Android images,
but it affects our setup.
It looks like it breaks console redirection and such things. This, in
turn, breaks systemd-udevd, aborting with the following:
```
close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:71, function safe_close(). Aborting
```
In turn, what tipped me off is this dmesg message:
```
Warning: unable to open an initial console.
```
Though there is no certainty it is related.
The kernel build is technically the same as google-taimen, with some
options switched around. An upcoming improvement will be to share the
"wahoo" platform's kernel build with an option to switch between the
two at build time, and further along the line, with modular kernels,
sharing the same exact builds, but with the device-specifics as modules.
Anchoring ourselves to an external project, at this point, is not
feasible. This does not allow us to explore making better use of the
capabilities of nix.
Though, a mechanism using third-party resources, like the postmarketOS
device information, is something that is desirable. The difference is
that it would need to *import* the information in the format used by
mobile-nixos, rather than mobile-nixos importing the information from a
"data dump".
This is dumb... These are all android/google/qualcomm/asus "features"
added to the kernel with no concern about actually being compatible
with the kernel. They all assume no USER_NS stuff.
Fun!
libinput, which I believe, claims there is a kernel bug with the
synaptics driver touchscreen in use.
This is the recommended fix according to PostmarketOS.
* https://wiki.postmarketos.org/wiki/Troubleshooting:touchscreen#sec_touchscreen:_kernel_bug
I have not seen any issues from using this fix.
The error:
```
synaptics: kernel bug: device has min == max on ABS_MT_WIDTH_MAJOR
```
According to the touchscreen documentation of the kernel, I don't think
that it is an issue to remove this information from touch events.
... the real reason is that I need to figure out why the sd card isn't
detected. Figured that trying a less "random" tree could help figure
things out, though it doesn't help.
At least, the build seems consistent with either versions.
The config changes are also to try to "fix" things, while in reality
they don't seem to do anything useful.
Those changes may change nothing with what I'm trying to accomplish...
Though they will make a full backport easier to handle as I now have
isolated upstream changes from device-specific changes.
The parameters were wrong for BGRA.
asus-flo had mismatched field positions.
Both devices had one offset two bits wrongly positioned.
Hope nobody sees this, ever...
