<samueldr>
maybe someone can help me out here, does the earliest google pixel phones with userspace fastboot (fastbootd) have a separate recovery partition in addition to the boot partition?
<samueldr>
from reading the fastbootd docs it looks like it should, something like boot_a / boot_b / recovery_a / recovery_b
<samueldr>
but they don't spell it out
<samueldr>
on my fastbootd device (motorola-rav, motorola g fast) there are those four partitions
<samueldr>
and if I understand things right, the boot partitions don't include the recovery anymore
<samueldr>
I guess the earliest device would be a pixel 3
evils has joined #nixos-aarch64
s1341_ has quit [Quit: Connection closed for inactivity]
<danielrf[m]>
samueldr: There is boot_(a,b} but no recovery_(a,b) on my pixel 3 xl
<danielrf[m]>
I thought "boot as recovery" meant the recovery partition was no longer necessary
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-aarch64
<samueldr>
danielrf[m]: exactly, "boot as recovery" indeed means that
<samueldr>
but it looks like fastboot in userspace, or fastbootd, does not mean "boot as recovery"
<samueldr>
>> Because userspace fastboot and recovery are similar, you can merge them into one partition/binary
<samueldr>
>> The bootloader flashes the bootloader, radio, and boot/recovery partitions, after which the device boots into fastboot (userspace) and flashes all other partitions
<samueldr>
it does not exactly spell out whether a recovery partition would be expected or not
<danielrf[m]>
fastbootd and recovery are both executables in the boot partition on my device
<samueldr>
that's what I was assuming before exploring the motorola-rav !
<danielrf[m]>
I'm a little surprised you have a device with a recovery partition plus fastbootd
<danielrf[m]>
maybe the recovery partition is unused/legacy?
<samueldr>
it's a fresh new device from last year
<samueldr>
and (untested yet) I expect recovery to hold the recovery as it's where the TWRP build is meant to be flashed
<samueldr>
this is all so confusing :)
<samueldr>
I guess every OEM has their own view on the implementation in the end
<danielrf[m]>
perhaps they are entirely orthogonal concepts: "boot as recovery" / fastbff
<samueldr>
fastbff?
<danielrf[m]>
fastbootd
<samueldr>
right, I wondered if it was another name for it
<samueldr>
I guess they are, fastboot in userspace really should have been called "we want a 'super' partition and implementing this in the bootloader is too hard"
<samueldr>
"we we'll have fastboot running in Linux where Linux knows about the super partition scheme"
<samueldr>
but it's a mouthful for a name
<danielrf[m]>
nope, fastbff is just me getting stuck with the wrong keyboard mappings....
<zhaofeng>
artturin: For pinephone, how were you able to get Squeekboard to show up? It seems to be running and the log shows that it has loaded some layout files, but I just can't see it on screen.
<samueldr>
danielrf[m]: but yes, boot as recovery is orthogonal AFAICT, and was most likely a practical thing to do to reduce the amount of useless partitions?
<danielrf[m]>
yeah, part of my surprise was just that I thought Android introduced "boot as recovery" before fastbootd, so I assumed if you had the first then you'd have the latter
<samueldr>
same
<danielrf[m]>
I'd agree
<samueldr>
I'm glad though that I ended up having that device as a fastbootd test device
<samueldr>
since it shows how wrong the assumptions I had were
<danielrf[m]>
good to know!
<samueldr>
I guess even in Mobile NixOS, I'll have to change from `boot_as_recovery` to `distinct_recovery_partition` or something
<samueldr>
though maybe it doesn't matter and either is synonmy
<samueldr>
synonym*
<samueldr>
though, one nice thing I was able to really verify, Mobile NixOS should be able to just takeover the `super` partition and ignore the fancy partitioning shenanigans
<samueldr>
I'll have to check how annoying it is to flash back to a fancy partition scheme though
<samueldr>
but boot_a/b will hold a stage-1 (maybe stage-0), and A/B is not needed for stage-2 in NixOS because we have generations
<danielrf[m]>
my pixel 3 doesn't have a super partition, and android splits the super image across the vendor/system/product partiions:
<danielrf[m]>
Another reason to try to avoid depending on /vendor mount being available?
<samueldr>
danielrf[m]: exactly
<danielrf[m]>
and including all firmware in the mobile nixos build
<samueldr>
something you just made me realize (before saying it)
<samueldr>
ooh, this will allow me to validate an assumption
<samueldr>
>> Dynamic partitioning is implemented using the dm-linear device-mapper module in the Linux kernel. The super partition contains metadata listing the names and block ranges of each dynamic partition within super. During first-stage init, this metadata is parsed and validated, and virtual block devices are created to represent each dynamic partition.
<samueldr>
it's said that it happens during `init`
<samueldr>
it'll be trivial to see once I have it booting mobile nixos
<samueldr>
(for the record, I haven't started working on the port...)
<samueldr>
still gathering data
<samueldr>
interesting that the data is found *inside* the partition
<samueldr>
wild to see the contrived methods they're using for android, when you compare with how simple chromeos does it
<samueldr>
some of the info is somewhat outdated (applies only to the earliest devices), but is not wrong
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has quit [Quit: dev_mohe]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
rng4 has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
<zhaofeng>
atturin: Thanks! It ended up being just the org.gnome.desktop.a11y.applications.screen-keyboard-enabled being set to false as well as the docked mode being enabled
<zhaofeng>
Once I fixed both, the keyboard just worked
zupo has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
<samueldr>
Ke: we cannot change the partitioning of an android phone
<samueldr>
we *could* but it's extremely risky as one wrong move and the phone won't boot anymore
<samueldr>
the firmware and bootloaders are on the main storage, so one wrong move and it won't work anymore
<samueldr>
and for other devices? we already do not have such a convoluted system...
<samueldr>
... though I did make the "persist" and "misc" partitions be a thing for non-android devices too... but that's because they're going to be useful
rajivr has quit [Quit: Connection closed for inactivity]
nicoo has quit [Ping timeout: 268 seconds]
<Ke>
for android sure
<samueldr>
oh, sorry, I read "the same" partitioning
<samueldr>
and we do use sane partitioning
<samueldr>
when we're in control
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nicoo has joined #nixos-aarch64
jumper141 has joined #nixos-aarch64
jumper141 has quit [Client Quit]
jumper149 has quit [*.net *.split]
zupo has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
evils has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<andoriyu>
does steam run on rpi4?
<samueldr>
does steam run on aarch64?
<samueldr>
(trick question, the answer is really complex)
<gchristensen>
if you get steam to run on an rpi4 I'd expect steam to be coming out of its ears
<samueldr>
though, "host system needs to be 32bit little-endian" not sure how that'll fare with an aarch64 kernel
<samueldr>
there's also the steam remote play software
<samueldr>
which is a thing for native armv7l, not sure if anything looked at it for NixOS
<samueldr>
so, really complex!
<andoriyu>
Well, i actually just need steam link, which I know works on rpi4.
<andoriyu>
But I also know there is no nixpkg fpr that.
<clever>
samueldr: the steam client is only built for x86-32bit as far as i know, and nothing else
<clever>
it can then launch 32bit or 64bit games
<samueldr>
clever: box86
<clever>
x86 only
<samueldr>
I linked to it because it's been used to launch steam *and* its games
<clever>
i would not expect opengl to function at usable speeds when going that
<andoriyu>
Well, I don't need to run any games, just stream them.
<clever>
andoriyu: there is the steam link client, which can stream games, and run on arm
<clever>
root@pi400:~# dpkg -l | grep steamlink
<clever>
ii steamlink 1.0.7 armhf The Steam Link app brings desktop gaming to your Raspberry Pi. Just pair a controller to your device, connect to a computer running Steam on the same local network, and start playing your existing Steam games.