<samueldr>
I guess this, with a CM4, may start to look like a better option
<samueldr>
I'd like to see a raspberry pi 4 class hardware not constrained by bad I/O or bad power supply issues
<samueldr>
how it benchmarks against other higher end SBCs
cole-h has quit [Ping timeout: 252 seconds]
<Ke>
so current status of pbp display: can see the output in sway and it accepts commands, but display says "no signal"
<Ke>
this is with nadia patches
<Ke>
and nadia's u-boot built on archlinux (assuming nadia is not distributing gubmen't spyware built on evil(like harkonnen) linux distibution)
<Ke>
linux-5.11.13
<Ke>
fwiw I have never used sway external monitors so there is a slight possibility that I am doing it wrong, but internet says all displays enabled by default and ui seems to unfocus(change colour) the other display while switching to a desktop on my external monitor
nyanotech has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<LinuxHackerman>
Emil Karlson: sway will just autodetect it, enable it, and put it to the right of the internal display, as long as it isn't configured otherwise
<Ke>
with my other dongle it seems to be working
<Ke>
I now have: video/keyboard on u-boot, external display, usb and ethernet on dongle on linux
<Ke>
so feature completeness is not super far away
<Ke>
this keyboard feels super awkwards
<Ke>
haven't been at the office for ages
<Ke>
this is also funny that foot seems to select font sizes based on screen dimensions, not resolution
<Ke>
switching from 1080p to 1080p screen gave me more lines
<LinuxHackerman>
nice how that stuff works nowadays
<LinuxHackerman>
I think what it actually uses to decide is the DPI, i.e. the amount of pixels and the size of the screen
<LinuxHackerman>
(pet peeve of mine: the way that the term "resolution" refers to both pixel density _and_ size in pixels…)
<Ke>
language is as we use it
<Ke>
but definitely pixel density would be more in line with how it gets used elsewhere
<Ke>
or I guess inverse of pixel density ie. size of a pixel
jumper149 has joined #nixos-aarch64
<LinuxHackerman>
of course it is, and I'm far from a prescriptivist. But I'll still complain when the way language is used makes communication more difficult :p
zupo has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
<Ke>
well it's not like most people are not just fine with exceptions being the norm
<Ke>
it 's kind of funny though this is the case
<Ke>
but I guess it might be related to the way language has to evolve to get new meanings
<Ke>
like there had to be a way to move from concrete things to abstract, which is quite a leap
<ShalokShalom>
Who here runs NixOS on Android in chroot?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
cole-h has joined #nixos-aarch64
mindavi has joined #nixos-aarch64
<mindavi>
samueldr: Hey, I'm trying to cross-build the tools in the mobile-nixos repository, but not sure how to do that. Any pointers? I've tried nix-build overlay/package-name/default.nix and nix-build -A package-name, but (as I was expecting) that doesn't work
<samueldr>
Mindavi: what in particular?
<mindavi>
In this case, dtbtool
<mindavi>
I was looking at the hydra logs and saw some failures for different tools that seemed easy to resolve
<mindavi>
So I wanted to take a stab at it
<samueldr>
nix-build --argstr device [device-with-right-arch] -A pkgs.dtbtool
<samueldr>
so e.g.
<samueldr>
nix-build --argstr device asus-z00t -A pkgs.dtbtool # for aarch64-linux
<samueldr>
the default.nix exposes the whole package set
<mindavi>
This doesn't seem right: error: getting status of '/home/rick/hobby/mobile-nixos/pkgs.dtbtool': No such file or directory
<samueldr>
missing the -A ?
<samueldr>
(I don't use the `nix` command, so I'm not sure how it would be with `nix build`)
<mindavi>
nix-build --argstr $MOBILE_NIXOS_DEVICE -A pkgs.dtbtool
<samueldr>
--argstr needs 2 arguments
<mindavi>
Oops
<samueldr>
first is the argument name (device) and second is what you need :)
<samueldr>
so it was eating the `-A`
<samueldr>
I still don't know what I should do for a more "proper" UX for just building a package
<samueldr>
it is really cumbersome with that method
<mindavi>
Thanks :)
<mindavi>
Hmm yeah it's not very friendly, but it works
<mindavi>
At least
<mindavi>
I guess I gotta find the correct device now
<samueldr>
examples: asus-z00t for aarch64, asus-flo for armv7l, uefi-x86_64 for x86_64
<samueldr>
none of the devices should be altering generic packages
<samueldr>
so it's more about forcing evaluation for the right pkgsCross
<mindavi>
Oh, and dtbTool should be with a capital
<mindavi>
Now I get something :)
<mindavi>
One of these days the fix for gtk-doc should go from staging to master as well, which should fix some of the builds of mobile-nixos hydra
<samueldr>
yeah, I'm not *too* concerned right now with those
<samueldr>
Mindavi: you saw I added "canaries" to the project, right?
<samueldr>
if you have anything you know can get problematic with cross-compilation and Mobile NixOS, and is a good indicator of regressions in a well-constrained setup, please suggest canaries :)
<mindavi>
I remember looking at those, but forgot about it again. I'll let you know if I find anything :) I see that those are also broken due to the gtk-doc errors, so hopefully they get fixed too on hydra
<samueldr>
yeah, I specifically chose things that show specific issues, pain points mainly
<mindavi>
For now I haven't really seen anything misbehaving, except for text looking really wonky on sway
<mindavi>
I did get sway running on my pinephone with a cross build, so I'm happy about that :)
<samueldr>
nice to hear
jumper149 has quit [Quit: WeeChat 3.1]
angerman has quit [Ping timeout: 250 seconds]
ShalokShalom has quit [Read error: Connection reset by peer]
c00w has quit [Read error: Connection reset by peer]
ShalokShalom has joined #nixos-aarch64
s1341_ has quit [Ping timeout: 260 seconds]
illustris has joined #nixos-aarch64
c00w has joined #nixos-aarch64
zhaofeng_alt has joined #nixos-aarch64
angerman has joined #nixos-aarch64
s1341_ has joined #nixos-aarch64
NekomimiScience has joined #nixos-aarch64
alpernebbi has quit [Quit: alpernebbi]
pinkieval has quit [Ping timeout: 276 seconds]
pinkieval has joined #nixos-aarch64
quinn has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<hexa->
hrm, how far out is the quartz64?
<samueldr>
no idea
<samueldr>
but the way development's been going, we'll have to wait for more mainlining to happen I guess
<samueldr>
but already it's happening
<samueldr>
the last pine64 community update has more details about the plan for producing hardware, and the currrent challenges
<samueldr>
if that was more what you were asking about
<hexa->
kinbda
<hexa->
kinda*
<hexa->
I recently saw some patches on netdev regarding rk3566/rk3568
<hexa->
so mainling is happening
<samueldr>
yeah, that's coming from pine user-developers :)
<samueldr>
but before considering a quartz64, I'd wait for more user-developers to further make the kernel support better
<hexa->
actually the patches on netdev are from a guy @rock-chips.com
<hexa->
and one from collabora
<hexa->
collabora usually does consulting and contract work on these kinds of things
<hexa->
so not sure they are strictly user-developers
<hexa->
tbh, I'm looking forward to the model b, no display :)
<hexa->
I mostly need headless compute with proper network access
<hexa->
and proper usb pd power
<hexa->
4 cores, 8 GB ram
<samueldr>
oh, yes, too
<samueldr>
but I find it irritating to see SBCs with only one display output because the SoC can't do better
<samueldr>
if they want to be NUC-like, they need to come with the features one would want!
<hexa->
oh yeah, that would be a great form factor and market to enter
<samueldr>
"we", as in the whole computer world, needs an "i5 nuc, but with ARM"
<samueldr>
so not a low power thingy
<samueldr>
something you would use, multiple displays, browse the modern web, and other less intensive tasks like compiling the kernel, doing 3D stuff, gaming
<samueldr>
I guess the on-die GPUs are not really there with hw support yet, not sure about actual power
<hexa->
not sure how recent midgard and bifrost are
<hexa->
> Mali-G52 2EE Bifrost GPU@800MHz
<{^_^}>
error: syntax error, unexpected '@', expecting ')', at (string):494:25
<hexa->
on the quartz64
<zhaofeng1>
RK3399 has Midgard
<hexa->
ah ok
<samueldr>
yeah, and putting more mali in the hands of the right people will help making it better in the end
<hexa->
so last gen and current gen :)
<samueldr>
but I was thinking compared to how recent x86_64 SoC gpus
<samueldr>
like the AMD ones
<samueldr>
if we could have a radeon gpu on an ARM SoC for a NUC-like
<samueldr>
that would be lovely
<hexa->
yikes
<samueldr>
yikes?
<hexa->
game changer
<samueldr>
samsung is maybe going back to amd with a radeon in their next exynos
<zhaofeng1>
By the way, does anyone know any more recent "Linux handheld with a physical keyboard" alternative to PocketCHIP? For some reason I really want to get my hands on one
<samueldr>
alternative, because you cannot get a pocketchip?