08:29 <qschulz> mort: AFAIK, you still need to create an audio card to be able to output I2S

08:29 <qschulz> so you may need to have to declare a dummy codec

08:29 <qschulz> in a way Linux needs to know the format of the data to send over I2S

08:30 <qschulz> so a dummy codec which specifies what the DSP actually is capable of handling I guess

10:42 <naoki> mmm

10:44 <naoki> I didn't care when I sent ROCK Pi E v3.0 patch for u-boot... I thought dts can be shared, but it doesn't work well for OpenWrt :(

14:57 <mort> qschulz: how do I create a dummy codec then?

14:59 <mort> don't tell me I have to create a custom kernel module just to play sound

15:07 <qschulz> seems like it

15:07 <qschulz> mort: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-utils.c#n189

15:10 <mort> useless

15:11 <mort> that was re: the "seems like it" not re: the link -- is that dummy_dai usable from devicetree? If so maybe I can avoid

15:11 <qschulz> no it's not

15:11 <qschulz> and it's on purpose IIUC

15:11 <qschulz> though you probably could write your own card driver that makes use of ti

15:12 <qschulz> it seems to be used on some mtk and imx cards?

15:12 <mort> I fucking hate this garbage kernel

15:12 <mort> man

15:12 <mort> just let me play audio! Don't make me write a kernel driver just to play audio, that's literally the meme

15:13 <mort> maybe I should check out freebsd, I bet they don't make you write your own kernel driver *on purpose* to output audio on hardware which they have *already written drivers for*

15:15 <mort> this isn't directed at #linux-rockchip so I guess it's off topic but every single little thing I want to do is met with so much INTENTIONAL resistance, this kernel really doesn't want me to use it without writing custom out-of-tree kernel drivers (but then if I write custom out-of-tree kernel drivers, kernel upgrades become hell, and then if I ever

15:15 <mort> complain about that to someone then I was the moron who didn't just use unmodified upstream Linux)

15:15 <mort> I hate it

15:15 <CounterPillow> then fuck off already

15:16 <mort> oh I would love to

15:16 <mort> but this user hostile piece of shit operating system happens to be the only realistic option for most stuff I want to do

15:18 <mort> nothing makes my blood boil more than when developers of what's meant to be a general purpose piece of software INTENTIONALLY block certain basic things like fucking playing audio

15:18 <qschulz> nobody's forcing you to use out-of-tree kernel drivers, you could contribute them to upstream so you don't have to carry them for too long for example

15:19 <mort> No I can't

15:19 <qschulz> i don't have the background for this specific use case but it could simply be that nobody's actually done the work and this one driver isn't for it

15:19 <mort> My driver would literally be a dummy driver, and it sounds like upstream intentionally doesn't want to expose a dummy codec driver to devicetree

15:20 <qschulz> **I** (with no knowledge of anything in this subsystem) would think that it could be possible to create a new driver which takes things like data format, clocks, etc... from DT/ACPI for hardware that is truly not configurable

15:20 <mort> I should gtfo before I get myself banned. Thanks for your help and I wish the operating system we all rely on was less preoccupied with making my life hell

15:48 <mriesch> mort: would this do the trick? https://elixir.bootlin.com/linux/v6.10.4/source/sound/soc/codecs/spdif_transmitter.c

15:48 <qschulz> mriesch: they're gone :) maybe they'll monitor the logs though /me shrugs

15:49 <qschulz> mriesch: but that does seem interesting

15:50 <mriesch> qschulz: i can still answer them on stackoverflow :-)

15:50 <qschulz> why it has SPDIF in the name is beyond me though

16:49 <CounterPillow> mort has been engaging in bad faith arguments and done nothing but complaining for months. They're not interested in solutions, or in doing any of the work themselves.

17:10 <mriesch> qschulz: well maybe spdif outputs are more common than i2s ones

17:11 <mriesch> so the solution exists for spdif and not (yet) for i2s

17:11 <mriesch> but i guess solving this issue for i2s would go along these lines

17:26 <robmur01> yes, where "those lines" are literally "provide the OS with a driver for your hardware so the OS has some idea of how to actually use your hardware"

17:27 <robmur01> S/PDIF transmitters (although they're often actually TOSLINK) are real pieces of hardware, albeit very simple ones

17:27 <mort> I can't

17:28 <robmur01> AIUI a raw I2S interface *has* to know what it's talking to on the other end, because stuff like clock directions aren't negotiated in the protocol

17:29 <mriesch> robmur01: so, in summary, not at all along those lines :-)

17:31 <mriesch> mort: so what is actually at the other end of i2s lines?

17:31 <qschulz> mriesch: they're gone again :)

17:32 <mriesch> grmpf. do i really need to turn in joins and parts in my client?

17:33 <qschulz> mriesch: if you have autocomplete it usually doesn't work with people that are gone :)

17:33 <mriesch> ah that explains why it didn't work 🙈

17:35 <robmur01> mriesch: no, if it's some fixed I2S sink with no configurability then it should be absolutely similar to spdif-dit, i.e. simply wanting a similarly trivial driver to describe the format/rate/mclk direction/etc. it expects

17:35 <mriesch> ah ok

17:37 <robmur01> FWIW my experience in this is a couple of days of banging my head against I2S and simple-audio-card on the NanoPC-T4, when there *was* already an upstream driver for the codec on the other end, and still failing :)

19:54 <naoki> hmmmm

20:32 <naoki> about U-Boot, I really want to change defconfig name from rock5a-rk3588s_defconfig and rock5b-rk3588_defconfig to rock-5a- and rock-5b-

20:33 <naoki> mmind00: why you used rock-5-itx- instead of rock5-itx- ?

20:34 <mmind00> naoki: suggested by dsimic ... due to Radxa naming that one board differently

20:37 <naoki> if my memory is correct, I suggested rock5a(5b?) should be rock-5a, but it was declined :(

20:37 <naoki> declined by someone

20:46 <mort> so I guess I try to write a fucking kernel driver

20:46 <mort> where the hell do I start

20:47 <mort> I hate this

20:49 <mort> I don't know what the difference is between a cpu dai and a a codec dai, I don't know what a dit is, I don't know what a "card" is, and I sure as hell don't want to do any of this

20:50 <mort> but digging down and learning about all of this is apparently how you get this kernel to output audio

21:01 <mort> I don't understand why linux,spdif-dit is allowed to exist

21:11 <diederik> mort: getting into a different state of mind seems like a prerequisite for doing anything productive

21:11 <mort> too bad

21:21 <mort> devicetree was a mistake, the fantasy that it should be an OS-agnostic description of the hardware seems to be the cause of most problems I encounter

21:27 <mort> I'll stop talking about this here because it's mostly off topic