<samueldr>
variant of the gpu driver in the kernel
<samueldr>
if I can fix what qualcomm broke
<colemickens>
this is the android kernel, does android not use the framebuffer support at all, or do they have special usersapce sauce for it, etc?
<samueldr>
which, starting from my work of just porting forward the cheryl2 driver on top of bluecross... I think I'm not starting well
<colemickens>
hm
<samueldr>
Android uses DRM since somewhere around 8
<samueldr>
previous vintage of Qualcomm SoC still shipped with working fbdev drivers
<samueldr>
the vintage of SDM845 though doesn't
<samueldr>
at least not on cheryl2
<colemickens>
samueldr: is your desire for getting it working mainly uniformity?
<samueldr>
yeah
<samueldr>
if I can shed most or all OEM customizations, it will help to work in tandem with other users
<samueldr>
I already was successful in reducing the diff to only the OEM changes
<samueldr>
dropping all the weird backports and cherry-picks
<samueldr>
by identifying them all
<samueldr>
razer released only a tarball
<samueldr>
no git history
<samueldr>
so I had to scavenge around for likely patches that accounted for the diffs compared to the CAF release it was built from
<samueldr>
then once I had most of them
<samueldr>
I could delete all the changes!
<colemickens>
samueldr: seems like a lot of work, if DRM is available? (sorry I feel like these are really naive questions)
<samueldr>
not everything works with DRM
<samueldr>
though it's not only about DRM
<samueldr>
it's also about getting updated kernels
<samueldr>
and have CAF + the minimum patch set authored by the OEM
<samueldr>
so from that minimum patch set, I was able to update to the latest CAF release, already a big win
<samueldr>
now I tried to get greedy and update to google's branch
<samueldr>
and it's failing quite spectacularly :)
<colemickens>
only dumping a tarball is :(
<samueldr>
yes
<samueldr>
but still better than nothing at all
<samueldr>
also, reducing that patch set was really helpful in understanding what was actually done
<samueldr>
because all razer phone 2 kernel source trees just commit that big messy blob
<samueldr>
while I instead have one commit per driver, approx
<samueldr>
so yeah, having an fbdev working is better than none, even if DRM is better than fbdev
<samueldr>
fbdev is simple, and it already works with so many things
<samueldr>
but I agree that DRM should be used when available (I think)
<samueldr>
one benefit with fbdev is that we can produce a simple rootfs that works everywhere
<samueldr>
while DRM... I don't know when it started being supported on many targets
<samueldr>
I don't know if the API is stable, even!
<samueldr>
hopefully it is
<samueldr>
it must be, since it's in the kernel
<colemickens>
Thanks for explaining, this is what I suspected but wanted to understand
<colemickens>
Do you have any guidance on if I should "go with" the ALS or LineageOS kernel sources? I am too lazy to diff them if there's a preference or obvious choice?
<samueldr>
I don't know for sure
<samueldr>
LineageOS is more likely to be customized to harmonize with their needs
<samueldr>
ALS is going to be closer to stock
<colemickens>
Also, if you have the list of kernel options for nix-daemon? I have CONFIG_USER_NS from the looks of it, and I'm not seeing how to get more verobsity of nix-daemon
<samueldr>
I don't, sorry :/
justanotheruser has quit [Ping timeout: 240 seconds]
<samueldr>
just like that 722GB free
<samueldr>
I did not collect garbage, only deleted all /nix/store/*-source
<samueldr>
oops
<samueldr>
wrong channel
justanotheruser has joined #nixos-aarch64
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 246 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
AmandaC has joined #nixos-aarch64
ib07 has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
<colemickens>
the fdisk -l output makes my head spin
<samueldr>
hahaha
<colemickens>
so uh, why do I not just have a wlan0 or somesuch?
<colemickens>
I didn't really expect it to be so easy, but...
<samueldr>
the "wrong" simple answer is that the drivers are less and less being implemented in the kernel
<samueldr>
and more and more a thin layer with a closed source userspace daemon
<samueldr>
so you don't have a driver for wifi in your kernel
<samueldr>
you have a driver to talk with the wifi hardware
<samueldr>
and that requires a closed-source userspace component
<samueldr>
though on mainline the driver is implemented in the kernel
<samueldr>
go figure
<samueldr>
it's as if they were trying to hide their work
<colemickens>
um what
<colemickens>
I mean, if it works, ship it. I guess.
<samueldr>
it's baffling, really
<samueldr>
they could just use whatever systems the kernel provides
<samueldr>
and it'd work just fine
<colemickens>
so is there any hope of it being in mainline now?
<samueldr>
maybe I can use that to cheat a framebuffer
<samueldr>
I think that also explains how people get framebuffer easily when making "funny things" like porting tianocore or doing some low level "hacking"
<samueldr>
they just use whatever the bootloader left them
<sphalerite>
ha ok, the wifi working yesterday was a fluke I guess, the old problems are back.
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
cole-h has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
colemickens has quit [Quit: killed]
fgaz has quit [Quit: killed]
Dandellion has quit [Quit: killed]
yangm has quit [Quit: killed]
JJJollyjim has quit [Quit: killed]
codyopel has quit [Quit: killed]
Ox4A6F has quit [Quit: killed]
cornu has quit [Quit: killed]
Ke has quit [Quit: killed]
flo[m] has quit [Quit: killed]
Ericson2314 has quit [Quit: killed]
puzzlewolf has quit [Quit: killed]
bbigras has quit [Quit: killed]
Danct12[m] has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
hsngrmpf[m] has quit [Quit: killed]
smrtak[m] has quit [Quit: killed]
alexarice[m] has quit [Quit: killed]
bqy has quit [Quit: killed]
ArtemVorotnikov[ has quit [Quit: killed]
Jake[m] has quit [Quit: killed]
leonardp has quit [Quit: killed]
kyren has quit [Quit: killed]
pinage404[m] has quit [Quit: killed]
Smith[m]1 has quit [Quit: killed]
bennofs[m] has quit [Quit: killed]
tnias[m] has quit [Quit: killed]
tilcreator has quit [Quit: killed]
betrion[m] has quit [Quit: killed]
danielrf[m] has quit [Quit: killed]
blitzclone[m] has quit [Quit: killed]
hpfr has quit [Quit: killed]
lopsided98 has joined #nixos-aarch64
Smith[m] has joined #nixos-aarch64
<sphalerite>
meh, it still won't boot into the recovery when the fastboot-booted image fails… and lineage doesn't have ramoops info either
<samueldr>
:/
<samueldr>
the next think I'd do under your situation is to go with the lineageos kernel config outright
<samueldr>
you could try going from its defconfig
<samueldr>
though extracting it from the kernel is the best bet
<samueldr>
the required options here are likely relevant here too
<samueldr>
CONSOLE
<samueldr>
ON MY RAZER PHONE TWO
<samueldr>
dang is the text tiny
<samueldr>
it's as many pixels as my main display (1440p)
<samueldr>
but like, so much smaller
<samueldr>
this is actually GREATEST news for everyone here
<samueldr>
because this probably describes how to get early graphical console on all devices
<samueldr>
and from the docs about it in the kernel, this doesn't even invalidate gpu usage!
<samueldr>
I'm going to try it out on z00t tomorrow, if it works out that pretty much guarantees it's going to work across the whole range of devices
<samueldr>
the docs in the kernel tree for 3.10 do seem to indicate it was a thing back then!
<sphalerite>
hahaha
<sphalerite>
\o/
<samueldr>
I'll try to document it the best I can, though it looks like it'll be relatively trivial to implement
<samueldr>
waiting on yet another 5 minutes build
<samueldr>
aaand... it works!
<samueldr>
at least up to the mobile nixos menu
<samueldr>
it's actually quite amazing
Danct12[m] has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
betrion[m] has joined #nixos-aarch64
JJJollyjim has joined #nixos-aarch64
smrtak[m] has joined #nixos-aarch64
yangm has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
tnias[m] has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
pinage404[m] has joined #nixos-aarch64
puzzlewolf has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
blitzclone[m] has joined #nixos-aarch64
codyopel has joined #nixos-aarch64
Ke has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
cornu has joined #nixos-aarch64
bqy has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
hsngrmpf[m] has joined #nixos-aarch64
tilcreator has joined #nixos-aarch64
colemickens has joined #nixos-aarch64
ArtemVorotnikov[ has joined #nixos-aarch64
Jake[m] has joined #nixos-aarch64
flo[m] has joined #nixos-aarch64
alexarice[m] has joined #nixos-aarch64
kyren has joined #nixos-aarch64
hpfr has quit [*.net *.split]
noonien has quit [*.net *.split]
h0m1 has quit [*.net *.split]
noonien has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
rtjure has joined #nixos-aarch64
<ashkitten>
samueldr: nice!!
<ashkitten>
early graphical console will be amazing
<samueldr>
it is
<samueldr>
though that particular device has a weird quirk
<samueldr>
framebuffer stuff breaks on normal boot, but not in recovery mode!
<ashkitten>
weird!
<samueldr>
msm_drm.dsi_display0=mdss_dsi_nt36830_wqhd_dualdsi_extclk_cmd_10bit vs msm_drm.dsi_display0=mdss_dsi_nt36830_wqhd_dualdsi_video_extclk_30hz
<samueldr>
normal vs. recovery, kernel command line option
<samueldr>
I would bet it's related
<samueldr>
weird how it's being set to 30hz in recovery, 10 bit in normal boot
<samueldr>
I didn't even know the panel was... bittlier
<samueldr>
was it HDR?
<samueldr>
oh, it is!
<ashkitten>
10bit generally corresponds to hdr
<samueldr>
TIL, that phone had HDR
<samueldr>
has*
<samueldr>
I'm thinking in the past since it's not one I'm using right now :)
<ashkitten>
:p
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I think it's 120hz in simplefb, which is hella weird
<samueldr>
things feel almost *too* smooth
<samueldr>
where's the good ol' jank?
zupo has joined #nixos-aarch64
<ashkitten>
ky0ko1 said that about my 144Hz monitor too
zupo has quit [Client Quit]
<ky0ko>
yeah framebuffer at high speed is weird lol
alpernebbi has joined #nixos-aarch64
<samueldr>
this is a gamer phone... I wonder how software rendering on simplefb would handle supertuxkart
<ashkitten>
i didn't know that had framebuffer output
<samueldr>
simplefb runs x11
<ashkitten>
ohh
<ashkitten>
i thought it was an actual framebuffer console
<ashkitten>
from the name
<samueldr>
simplefb is basically "render direct to memory" and hopefully via DMA the GPU does the right thing
<ashkitten>
clearly it's doing something right
<ky0ko>
fbcon would be the framebuffer console
<samueldr>
and yeah, the console uses it, and x11, and pretty much anything graphical generally end up being able to
<samueldr>
yeah
<sphalerite>
is there a difference between simplefb and fbdev?
<samueldr>
I'm not sure
<samueldr>
I don't find (quickly) docs about fbdev
<ky0ko>
yes, but i dont recall off the top of my head what the difference is
<samueldr>
but simplefb is literally a span in memory that's been tagged "kernel: don't touch, except to throw pixels at it"
maxsc has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
<maxsc>
Hi all, I managed to encrypt and install nixos on a sdcard from a usb stick for my raspberry pi 3b (no plus), but now I need a usb stick inserted to boot from the sdcard, does anybody know what's happening? I set program_usb_boot_mode=1 in config.txt, but that's not revertible, right?
<clever>
maxsc: program_usb_boot_mode cant be reversed, but the SD card has priority when both are present
<maxsc>
Right, so that works, but do I need to leave a usb stick in the rpi forever then?
knerten2 has quit [Ping timeout: 260 seconds]
<clever>
if you want to boot from usb, yes
<clever>
if you want to boot from SD, then you can remove the usb
<maxsc>
When I remove the usb stick the rpi doesn't boot at all
<maxsc>
There isn't even any screen output, so I can't see what's happening
<maxsc>
I'm on the BCM2835 model of the rpi 3b btw, so maybe this is a known problem with this model..
<samueldr>
the sd card doesn't have a "FIRMWARE" partition, most likely
<clever>
BCM2835 is the SoC for pi1, not pi3
<samueldr>
clever: ^ if that helps you guide maxsc
<clever>
samueldr: yeah, that sounds like the most likely cause
cole-h has quit [Ping timeout: 260 seconds]
<maxsc>
samueldr: thanks, you are right, I named it "boot", so renaming the partition to "FIRMWARE" solves my issue?
<clever>
the name doesnt matter much
<samueldr>
it's the content
<clever>
just that you have the pi firmware on a fat32 partition
<maxsc>
yes, does it need to be on fat16?
<samueldr>
and u-boot, for the default expected system
<clever>
maxsc: nixos tends to mount sda2 to /firmware instead of /boot/
<clever>
but i would expect that to at least show a rainbow screen on startup
<sphalerite>
samueldr: oh right, then fbdev is the user-space interface /dev/fb* (which can be provided by any fb driver) while simplefb is the driver for a memory-region fb
zupo has joined #nixos-aarch64
<maxsc>
Yes, it's not burned from an img, rather I formatted it myself so that I could encrypt the rootfs
<clever>
maxsc: `blkid /dev/sda2` ?
<thefloweringash>
my cross compiled llvm has a host platform llvm-config, which promptly fails due to wrong cpu type when trying to build lld. anyone run into this?
rajivr has quit [Quit: Connection closed for inactivity]
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
rtjure_ has joined #nixos-aarch64
alp has quit [Ping timeout: 260 seconds]
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 256 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has joined #nixos-aarch64
<kyren>
hey, I have a raspberry pi 4 running nixos-20.09, everything works perfectly fine, except I also have a hifiberry-dacplusadc that only works IF I manually apply the device tree overlay
<kyren>
what is the proper method in nixos-20.09, if there is one, to apply an overlay to the raspberry pi foundation kernel fork, i.e. the _rpi4 kernel
<clever>
kyren: the pi firmware should automatically apply a dt overlay from the hat eeprom on the board
<clever>
kyren: but the way nixos uses uboot, that gets undone
<kyren>
I can get my sound card to work either by applying the device tree manually via /sys/kernel/config/device-tree/overlays/ OR if I make /boot/overlays and place the dtbo there and add the overlay via config.txt
<kyren>
hey clever, I'm back with more device tree questions of course, I know you explained this all to me the last time I asked and I remember SOME of it lol
<clever>
ah, /boot/overlays is the proper way to do it via the firmware
<kyren>
not using uboot, definitely isn't loaded via the eeprom, for whatever reason it's not right for this kernel
<clever>
its possible that upstream linux renaming fields broke the overlay in the eeprom
<kyren>
but it definitely works if I do it manually, just wondering if there's some way of doing this other than the two I just described, or if not I suppose I can make it work by writing stuff to make the overlays directory and place the file there I guess
<clever>
and the dtbo your using has been similarly renamed
<kyren>
yeah that's what hifiberry says, it works automatically with their hifiberry-dacplus board but not the dacplusadc board
<samueldr>
clever: the image still doesn't use u-boot by default for the raspberry pi 4
<kyren>
so my question is basically what's the proper way to load the overlay with the _rpi4 kernel
<kyren>
if there even is one
<clever>
kyren: id say dtoverlay= in config.txt is the proper way when using the firmware
<samueldr>
there is a declarative way though
<kyren>
"when using the firmware" meaning what exactly, not using uboot?
<clever>
kyren: correct
<samueldr>
when using the raspberry pi proprietary boot chain
<samueldr>
I'm not 100% positive how it works though
<kyren>
yeah a declarative way would be great
<clever>
i think the above one applies the overlays at build time
<kyren>
so I already tried that, I can go through what it does with you, it doesn't seem to work on 20.09 due to.... something, I think there's a PR about it that didn't make it into 20.09, but it also doesn't work on unstable
<kyren>
I'd be happy with whatever declarative solution, I'm not tied into doing it one way or the other, I'd even try the vanilla kernel if that works at all with the rpi4 yet
<kyren>
so if you add something like "${config.boot.kernelPackages.kernel}/dtbs/overlays/hifiberry-dacplusadc.dtbo" to hardware.deviceTree with 20.09 it errors with FDT_ERR_NOTFOUND, with unstable it does work though, lemme try again to boot unstable and see if that actually applies the overlay or not, I don't remember the specifics other than the fact that the sound card didn't actually work
<samueldr>
there doesn't seem to be a facility to copy additional files
<kyren>
I could override the builder, run the previous builder, then copy the files hehe
<samueldr>
that sure is an option
<kyren>
lol
<kyren>
actually there's maybe not a great way to do that either
<kyren>
or, at least I don't know of a way to do that
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 256 seconds]
evalexpr has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 260 seconds]
julm has joined #nixos-aarch64
<kyren>
just for future reference, I ended up just making a systemd service to load the device tree overlay at runtime, that seems to be the simplest declarative way to load overlays