<linkmauve>
mort, why would you not use that kernel fork? It’s most likely what will end up in mainline at some point, or some variation of it.
<mort>
linkmauve: 1) I like to stick with distro kernels as far as humanly possible, and 2) if I'm going to compile a custom kernel (e.g if I need to change a build option) I at least want to stick with mainline
<CounterPillow>
then you'll have to wait
<mort>
well that's not really an option
<mort>
it seems like ARM's official solution is to use the proprietary mali drivers, right?
<mort>
tbh I wish Linux had a sane driver architecture where companies could just provide drivers without all this mess
hipboi has quit [Ping timeout: 264 seconds]
<CounterPillow>
You've mentioned before that you want to use awful vendor binaries that make cross-kernel refactoring impossible and I've told you why I disagree with this before, and we don't need to re-tread this discussion.
<mort>
I have absolutely no idea what you are talking about, I have had this discussion before but never in my life have I ever suggested anything which would make cross-kernel refactoring impossible
<mort>
and your claim is that fixing the current absolutely horrible situation is literally impossible, that we will just have to live with Linux being shit with drivers which don't work on hardware that's more recent than like 6 years old
<CounterPillow>
Okay, it appears you are completely clueless what binary vendor drivers with an ossified ABI would actually mean for refactoring, so no need to discuss this with you at all since you're unqualified to have this discussion :)
<mort>
I promise you, I understand the technical details here
<mort>
it's not complex, we're talking about providing a somewhat stable ABI, libraries have been doing that since time immemorial
<CounterPillow>
Yep, confirmed as not understanding the problem domain
<mort>
nope
<CounterPillow>
Last time we had this discussion you didn't even know what an ABI was and kept calling it "API"
<mort>
lol don't let your ignorance show like that, I was talking about the API last time, not the ABI
<mort>
I was *explicitly* not talking about binary compatibility but source compatibility
<mort>
this time you mentioned ABI so I kept to that topic
<CounterPillow>
Okay, clearly you're the expert on this topic so I warmly await your perfect forward-compatible kernel driver ABI spec on the mailing list
<mort>
anyway if you want some form of ABI stability without ossification problems, what you do is you create a well-defined ABI, you promise not to break it in minor and patch releases, you try to keep breaking changes in major releases to a minimum but if you do need a big kernel-wide refactor you're not locked out from breaking it entirely
<mort>
nothing I have ever said has ever implied that I want an eternally forward-compatible kernel/driver ABI *or* API
<CounterPillow>
You seem awfully confident that companies will maintain their drivers across such ABI versions, when they can't even be bothered to maintain their out-of-tree dkms modules for newer kernels :)
<mort>
I'm not
<CounterPillow>
Then what's the point
<CounterPillow>
You gain nothing, you just lose access to the code
<mort>
I'm confident that they'll do a somewhat better job if the driver has to be updated, say, on average every 10 years, rather than every month
<mort>
if access to the code is the concern, then don't define a stable ABI at all, just define a stable API
<CounterPillow>
You don't even know how long kernel release cycles are if you think out-of-tree modules need to be updated "every month"
<mort>
hell, intentionally break the ABI on every release if you want
<CounterPillow>
Why don't you do that, since you're the one wanting it?
<mort>
there is no rhyme or reason to when they need to be updated because there is no promise of any form of either API or ABI stability, every single commit could break drivers for all mainline is concerned
<mort>
why don't I do what
<CounterPillow>
Contribute your genius idea to Linux in the form of an RFC patchset
<CounterPillow>
Hint: if you can't implement it, you're not qualified to opine that this would be a good idea.
<mort>
bullshit
<mort>
if you had half a clue, you'd actually argue based on the technical merits, with valid arguments
<CounterPillow>
I do. It makes refactoring across drivers impossible.
hipboi has joined #linux-rockchip
<mort>
but all you're doing is, in essence, straw-manning my arguments ("you want an eternally forward compatible ABI"), misunderstanding me (like the ABI vs API thing), or doing the typical BS FOSS "if you don't personally invest a decade of your life into doing it it's a bad idea" thing
<mort>
explain how it makes refactoring across drivers impossible, please.
hipboi has quit [Read error: Connection reset by peer]
<CounterPillow>
We could not change or extend the API except for when all-knowing mort decides we can, and we can't refactor across said API boundaries to make code paths simpler.
<mort>
hey nice, another straw-man
<mort>
please tell me when I said I thought it should be my decision when breakages happen?
<mort>
and please tell me how an API stability guarantee would make refactors across the API boundary impossible
<CounterPillow>
seems like you don't know what API stability means
<mort>
elaborate
<mort>
you'd just have to release a major version when you refactor across API boundaries in a way which requires an API break
hipboi has joined #linux-rockchip
<CounterPillow>
So you're now saying I can't refactor until some later point in time?
<mort>
that's how almost every library works, there's nothing special about being the kernel which would make the same principles not apply
<CounterPillow>
There is, the kernel internals have a hell of a lot of surface area
<mort>
well you'd probably need to convince someone that the refactor is worth an API break, and then time things so that the refactor ships with the release of a new major version
<CounterPillow>
e.g. the clock api would touch a hell of a lot of drivers
<mort>
how is the surface area of the clock API relevant, is it necessary for it to change in backward incompatible ways a lot?
hipboi has quit [Read error: Connection reset by peer]
<CounterPillow>
It is part of a lot of drivers, and occasionally gets readjusted to better fit actual hardware, and yes that would be hard to engineer in a way where interfaces are kept compatible.
hipboi has joined #linux-rockchip
<CounterPillow>
I have received subsystem refactor patchsets in my email inbox that touched my driver, I know what they look like
<CounterPillow>
If you want an OS that lets vendors do whatever with drivers and shackles itself to some ABI/API for drivers, feel free to use Windows. I've heard the XP to Vista transition went very well, and users were delighted.
<mort>
well, yeah
<mort>
compared to having every single minor Windows update break people's drivers? People love the current Windows model
<CounterPillow>
if you use hyperboles like "every single minor update" and "6 year old hardware" it's very evident you have no argument
<CounterPillow>
If you find yourself using a lot of out-of-tree kernel drivers, make better purchasing decisions. Serious companies do upstream driver work, e.g. Intel Wi-Fi chipsets compared to Realtek DKMS vomit.
<mort>
good one, Mr. steel man
<mort>
tell me which SBC vendor is the right purchasing decision
<mort>
anything with ARM GPUs is out obviously
<CounterPillow>
not anymore since panthor will be Arm's driver going forward, with official support :)
<mort>
well it's not now
<mort>
so what's the right purchasing decision now
<CounterPillow>
STM, RK3399, Qualcomm
<mort>
I didn't know it would have official support from ARM btw, that's cool
<CounterPillow>
Intel and AMD make embedded boards as well, and they usually have upstream driver support from day 1
<mort>
RK3399 is from february 2016, so almost exactly 7 years old
<mort>
you're saying my "6 year old hardware" thing was exaggerated lol
<mort>
so you're saying old rockchip good, new rockchip bad
<CounterPillow>
RK3568 then, but you're gonna cherrypick that one out as well
<mort>
I looked up RK3399 because that was the only specific chip you suggested, it wasn't my intention to cherry-pick sorry
<CounterPillow>
Yes, rockchip has notably reduced their upstreaming activity but they're occasionally contributing again though this may be employees working in their own time
<mort>
I have generally found Qualcomm to be reasonably pleasant to work with using upstream kernels, but that might just be because I've used pretty old Qualcomm SoCs
<mort>
does Qualcomm and STM really work so closely with upstream that new SoCs have officially supported drivers merged into mainline within, say, a year?
<mort>
anyway it doesn't really matter, I'm usually in a situation where either hardware has already been chosen or other factors are so much more important than "mort has a nicer time getting the GPU to work"
<mort>
It's nice that mainline can boot on that snapdragon, I wonder what the GPU status is though
stikonas has quit [Ping timeout: 240 seconds]
<mort>
anyway, good talk, I'm going to bed.
<mort>
CounterPillow: if this topic ever does come up again, we will have a much more pleasant conversation if we skip past the initial stuff about "you want an eternally perfectly stable API or ABI" or "you don't even know the difference between an API or ABI" or anything like that
<CounterPillow>
I have no interest in ever discussing this with you ever again, but you'll probably bait me again by making stupid remarks about "sane" driver models
<mort>
that's perfectly fair, and something like "we have already had this conversation and we will not resurrect it" is fair, I probably should have respected your first message which was more or less like that
<mort>
but then comments like "Okay, it appears you are completely clueless what binary vendor drivers with an ossified ABI would actually mean for refactoring" kinda bait me into at least defending my position, because I am certainly not of the opinion that there should be an ossified ABI (as I hope I have expressed clearly in this convo)
camus has joined #linux-rockchip
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 260 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Remote host closed the connection]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 264 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 276 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 256 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 264 seconds]
hipboi has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
eballetbo has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mripard has joined #linux-rockchip
warpme has joined #linux-rockchip
stikonas has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 260 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alpernebbi has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
alpernebbi has quit [Changing host]
alpernebbi has quit [Ping timeout: 252 seconds]
alpernebbi has joined #linux-rockchip
alpernebbi has quit [Changing host]
alpernebbi has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 276 seconds]
alpernebbi has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
alpernebbi has quit [Changing host]
stikonas has quit [Ping timeout: 264 seconds]
warpme has joined #linux-rockchip
kbingham_ is now known as kbingham
raster has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 260 seconds]
alpernebbi has joined #linux-rockchip
alpernebbi has quit [Changing host]
alpernebbi has joined #linux-rockchip
ldevulder has joined #linux-rockchip
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #linux-rockchip
psydroid has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 252 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #linux-rockchip
f476_ has joined #linux-rockchip
f476 has quit [Ping timeout: 264 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
matthias_bgg has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #linux-rockchip
mripard has quit [Quit: mripard]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
stikonas has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 260 seconds]
ldevulder has quit [Ping timeout: 246 seconds]
matthias_bgg has joined #linux-rockchip
ldevulder has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linkmauve>
Ah, someone already submitted thermal-zones for the rk3588, it just hasn’t been merged yet.
<linkmauve>
The TRM says JPEG encoding is supported up to 8192×8192, but when I try to encode a 8192×5532 YU12 image I end up with 32 KiB of data which encodes only part of the first line, and no error from hantro. :(
<linkmauve>
A 4096×2766 encodes properly, I’ll try to figure out the current limit.