lopsided98 has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-aarch64
ris has quit [Ping timeout: 276 seconds]
h0m1 has quit [Ping timeout: 276 seconds]
h0m1 has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 268 seconds]
Thra11 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
Acou_Bass has quit [Ping timeout: 268 seconds]
Acou_Bass has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
<tilpner> samueldr: Do you have any ideas on how to prevent that in general? Encoding "works with this (host, target)" in meta is probably unrealistic
<tilpner> samueldr: But without that, it's easy to dismiss broken cross compilation for being broken before too, or only working with combinations not tested
<tilpner> Ideally, we would have per-attrpath lists of expected-to-work combinations, and ofborg would verify they all still work
<tilpner> But I know that's unrealistic
ris has joined #nixos-aarch64
<Thra11> samueldr: FYI, I've started collecting some RockPRO64/Pinebook Pro-related userspace stuff in a nixpkgs overlay: https://github.com/Thra11/nixpkgs-overlays-rk3399
ryantrinkle has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
vika_nezrimaya has quit [Ping timeout: 276 seconds]
chiefgoat has joined #nixos-aarch64
<samueldr> tilpner: I don't know :(
<samueldr> but it's not a bad thought to write it up in meta properties in some ways
<samueldr> maybe we need to ping Ericson*314 and/or matthewbauer on the subject, if they have idea
<samueldr> and, while I was a bit annoyed, I wasn't annoyed _at you_ :) the PR body was written up in a transactional tone, which might sound negative, but in reality it should have been read without tone, sorry
chiefgoat has quit [Quit: ZNC 1.7.5-rc1 - https://znc.in]
chiefgoat has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
jslight90 has joined #nixos-aarch64
adisbladis has quit [Quit: WeeChat 2.4]
<jslight90> Hello. I need some assistance or information. I'm trying to run Kodi Media Center on NixOS on a Raspberry Pi 3B. Has anyone been able to get hardware video decoding to work with aarch64 on a Raspberry Pi?
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FRidh has quit [Quit: Konversation terminated!]
chiefgoat has quit [Ping timeout: 240 seconds]
Thra11 has quit [Quit: WeeChat 2.5]
zupo has joined #nixos-aarch64
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ToxicFrog> Huh. I know the drivers exist, because hardware h264 decoding works in rasplex. But I've never tried getting it working in nixos.
<ToxicFrog> (note that you won't get h265 decoding regardless, the pi doesn't have hardware for it)
<clever> i think the rpi is also limited to 8bit stuff, 10bit things will fail
<clever> i was also reading a thread on the decoder stuff, and its limited to about 50mbit/sec of total h264 data
<clever> which becomes a limit if your trying to decode several things in parallel
<clever> or use it as a plex hw transcoder
<jslight90> I'm just trying to do things like h264 video playback; the video and audio have terrible stutter on NixOS vs using LibreELEC. I can confirm that LibreELEC is using hardware and NixOS is using software to process the video. This causes the processor to max out and not keep up.
<jslight90> The major difference with LibreELEC is that it runs 32-bit ARMv7 instead of 64-bit AArch64 (which has better cache support on NixOS).
<clever> jslight90: the gpu libraries wont work on 64bit, because the api involves passing userland pointers to the gpu and back
<clever> jslight90: and 64bit pointers dont fit in the provided fields
<jslight90> Does video decoding in hardware work on ARMv7 with NixOS?
<clever> jslight90: cant remember if i tested it there or not
<clever> jslight90: there is an mmap() flag, to force the allocation to be within the 1st 4gig
<clever> so you can truncate a pointer to 32bit safely
<clever> that would need to be used for all buffers passed to the gpu, to allow gpu accel in a 64bit process
<clever> but for extra fun, that mmap() flag is x86 only
<clever> so you cant use it on aarch64!
<jslight90> clever: Okay. I'll try building it on ARMv7 after my PC finishes building my astronomy software for AArch64. :P