<samueldr>
ah, by making a USB port on your GPIO lines
<DigitalKiwi>
also do you need a SoC or would a microcontroller work? there are even more options if you do that
<DigitalKiwi>
(i think)
<samueldr>
pretty sure you're right
<DigitalKiwi>
hiduino
<samueldr>
the rpi 4's usb type-c plug is OTG enabled, and should thus be possible to be used as a Linux Gadget
<samueldr>
some android phones can be used as gadgets, in fact, I would bet most, if not all, due to how adb works
<samueldr>
though only those on which you can run your own software might be usable as custom gadgets
<DigitalKiwi>
i've only looked around for stuff for the purposes of a midi controller but i think they could work for a keyboard too? there's another one i can't think of right now that has good hid support
<samueldr>
most of the time, if it works as a usb gadget, it can be any usb gadget
<clever>
samueldr: adb and picture sync all rely on the phone being a usb slave
* DigitalKiwi
always thinks it's named tiny not teensy and has to ddg until finds
<clever>
samueldr: usb otg is the more rare part (my 1st tablet didnt support it) and thats where the tablet can also be a usb host, and accept a usb stick or even a mouse!
<samueldr>
clever: yeah, why "most, if not all", edging my bets against bad implementations
<samueldr>
using a mouse on my phone annoys some people :)
<clever>
samueldr: the rpi 1-3 all support usb otg at the cpu level, but the modem B's all have a usb hub in the way, so you cant do it at all
<clever>
samueldr: and the model A's dont have the otg detect pin routed, so software cant detect if it should be in host or device mode
<samueldr>
(I know all that)
<clever>
samueldr: from what i saw of the pics of the rpi4, the usb-c isnt the otg port
<clever>
there is a seperate micro-usb beside the usb-c
<clever>
my guess, is that they just took the existing crappy usb controller they always had, and properly gave it a usb-otg port
<clever>
at that point, you already have all the pieces to do it right!!!
<clever>
su 'sh -c cat > /dev/hidg0'
<clever>
then just write the hex to stdin as needed
<clever>
oh, neat, this app even supports OTP codes
<DigitalKiwi>
i can't tell if you like this app or don't like this app
<clever>
*weeps*, nothing calls OutputUsbKeyboard (the non-root one)
<clever>
DigitalKiwi: i would fork it and fix the problems, if my phone was rooted enough to be able to use it :P
<t184256>
OTP over Bluetooth HID? Now I definitely gotta buy a dedicated work phone.
<DigitalKiwi>
makes sense
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 252 seconds]
ryantrinkle has joined #nixos-aarch64
kvaster has joined #nixos-aarch64
<Guest77>
I've used "nixpkgs.crossSystem" to build an sd-card. I copied the closure for the sd-card to the booted machine. However, when I run 'nixos-rebuild' it seems to ignore the store and re-download everything. Any hints for making it "work offline"?
<gchristensen>
Guest77: the problem is things built cross are not "the same" as things built locally
<gchristensen>
because they werebuilt using different instructions
<Guest77>
Damn, I guessed that. The host target tuple right?
<gchristensen>
yeah
<Guest77>
So the derivation is different :(
<gchristensen>
yeah
<gchristensen>
a fairly annoying thing in general
<Guest77>
It's not something that can really be solved because the compiler outputs will likely be different?
<samueldr>
exactly
<gchristensen>
I wonder if early cut-off (CAS/intensional store) could possibly help for this
<Guest77>
Oh Bananas! Oh well, it got me somewhere faster than compiling on a poor little machine. So I'm still glad it exists.
<gchristensen>
probably not, I assume the compilers built would retain something annoying like what it was compiled on/for
<samueldr>
yeah, I would assume so unless verified and verifiable
<samueldr>
e.g. if there was a hydra process to take for an eval X the pkgscross and native build outputs and compare them to be the same bytewise
<samueldr>
(should reproducible builds technically include cross builds too?)
<gchristensen>
I don't see why not :)
<Guest77>
Could you cheat the derivations and say use a pointer to an item, that says this cross compiled thing is "the same" as what the real thing is?
<samueldr>
as of right now, I don't think so, since that would still be a different input
<samueldr>
unless you went somehow outside nix and manipulated the outputs?
<Guest77>
I would expect a mechanisim in nix, that says "it's ok to use this instead of that". An alias of sorts for the binaries.
<samueldr>
that would be breaking one of the strong guarantees :/
<gchristensen>
yes
<samueldr>
(but sure would be useful)
<gchristensen>
or it would have to be extremely manual/extremely specific
<Guest77>
Yes. I know. That's why it's a cheat.
<gchristensen>
yeah
<Guest77>
It would almost be like an overlay that overrides all the outputs? Does that make sense? I'm a nix noob.
<gchristensen>
right someting like that
<gchristensen>
A batch more of our c2.large.arm Ampere servers have come online in our AMS1 data center. These systems are not reserved and are in our public cloud. <- on packet
jackdk has quit [Quit: Connection closed for inactivity]
<sphalerite>
Guest77: you might be able to set nixpkgs.crossSystem to the system that the device actually is and nixpkgs.system to "x86-64-linux" in the system config, and add your x86_64 machine as a remote builder, then always build your system using that
<sphalerite>
ymmv though, I haven't tried this myself.
<gchristensen>
interesting
<DigitalKiwi>
gchristensen: what's that mean?
<DigitalKiwi>
(about packet)
<gchristensen>
it means you can get 32 cores at 3.3GHz with 128G of RAM, 480G of SSD, and 2x10Gbps NICs for $1.00/h (or less on spot) in the AMS1 datacenter of Packet
<gchristensen>
of armv8
<DigitalKiwi>
nice
<gchristensen>
before they were 100% spoken fore
<gchristensen>
you could'nt just *get* one because they were all in use
<gchristensen>
for the ~first time, you can just get one
<samueldr>
IIRC the ampere ones are those that support armv7, so VMs can be made