Rathann has quit [Remote host closed the connection]
Livio has quit [Ping timeout: 240 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
naoki has joined #linux-rockchip
warpme has joined #linux-rockchip
<mort>
qschulz: yeah, sorry, the rq3588s
<mort>
rk3588s* damn
<mort>
I also saw those patches, tried to integrate them into an upstream kernel as part of a yocto build but couldn't seem to get it working, despite enabling a bunch of HDMI stuff in devicetree similar to how the repo which that patch series stems from had done for the rock-5
Livio has joined #linux-rockchip
Livio has quit [Ping timeout: 264 seconds]
<qschulz>
mort: i highly suggest to compile the kernel outside of any particular build system and test manually
<qschulz>
then you can provide info to the ML on how you tried to do stuff and that it doesn't work and they may be able to help you with it
<mort>
I don't trust myself to get the devicetree and defconfig and menuconfig stuff right when building manually
<mort>
I could try... but I have also already spent a whole bunch of time on this and I need to get on with the next thing
<mort>
My conclusion is more or less just that the upstream kernel or community forks simply aren't ready for the rk3588 still, even now years after release, and the vendor kernel + proprietary Mali drivers are still the way to go
<mort>
my hypothesis that you have to choose either 5+ year old hardware or expect to use vendor kernels remains true
<qschulz>
mort: more people upstreaming stuff, more chance to get out of your shitty vendor BSP
<mort>
which would've been alright enough if only I didn't have everyone across all embedded Linux related IRC channels constantly screaming at me to use mainline when I talk about anything kernel related at all
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mort>
qschulz: clearly not enough people up streaming stuff
<qschulz>
mort: welp, why should we support your shitty vendor BSP, we have no interest in it :)
<qschulz>
(to be clear, we have products on this same shitty vendor BSP ;) )
<qschulz>
mort: ideally, the vendor should do the upstreaming, instead of relying on hobbyists and companies building products on their SoCs
<diederik>
ah, that explains me finding Stretch and Bullseye in the documentation ...
<mort>
I'm not asking anyone to support Rockchip's BSP (though, I mean, this would be the IRC channel for discussion about it wouldn't it)
<mort>
I just wish people would stop constantly trying to coax me into wasting dozens of hours on dead-end attempts to use mainline
<qschulz>
mort: I guess, the difficult part being that the shitty vendor BSP from Rockchip is a base... then every SBC/SoM/whatever vendor are adding their shitty layer on top, so it's difficult to know how we could help, because we don't know what absolutely wonderful idea those people had to "fix" stuff
<mort>
qschulz: that's fine
<qschulz>
mort: if nobody uses/tests patches and/or mainline, you'll basically have no mainline or mainline in 10 years. It's a shared effort, cannot just expect stuff to magically work for free. But you're free to not want to spend your time on mainline that we cannot force you to
<mort>
"we sadly can't help with that in general because the BSP is shitty and SoM vendors do custom stuff and I don't happen to be familiar with that particular vendor" is a fine answer
<qschulz>
but for us, there isn't much benefit in trying to make your product work if it'll only ever live in that vendor fork
<mort>
"you should just use mainline" is not an acceptable answer
<mort>
"you should spend 50 hours trying to get mainline working" would be an acceptable answer, at least it doesn't try to make it sound like the easy solution
<qschulz>
people have a different set of skills, I cannot give you an estimate how much time it would take **you** to do it
<qschulz>
I'm not even capable of estimating the time it'd take me :)
<mort>
but you get the point
<qschulz>
I understand the frustration
<mort>
it's a significant amount of work because it's literally not supported mainline, so it involves trying to integrate various patch sets from across the web
<qschulz>
but it's "lashing out" on people who are not responsible for this situation and only want to have better/faster support mainline
<mort>
if I was struggling with the px30 and you said "you should really try to just get mainline working, it's supported" that would be reasonable
<mort>
I don't feel like I have lashed out at anyone in particular
<qschulz>
fair, I understood the complaint about "coaxing" you into trying mainline as lashing out
<qschulz>
but yeah, I'm also very disappointed in the global support for rk3588
<qschulz>
Rockchip hasn't done a great job here, even less than usual and we're already 2+ years since products exist :/
<mort>
I should have been clear, this wasn't at all directed towards you, at least not primarily
<qschulz>
Please really complain to them or your vendor, maybe one day they'll understand
<mort>
my guess is that FriendlyElec wouldn't respond at all, and if they did somehow respond honestly it would be some manner of "well what can we do about it, the rk3588 is attractive hardware which our users want, we do our best to provide system images which work with our products"
<qschulz>
mort: that's ok, thanks for the clarification. FOSS communities are sometimes getting a bit tired of being asked to do stuff or complaining that such and such do not work upstream already, or ask for help on stuff we've never seen (or want to see, the horrors....)
<qschulz>
or support vendor SW from vendors who do not participate (or very little) upstream
<mort>
I guess I understand that point of view too
<qschulz>
This is the case for a bunch of communities I'm part of, so sometimes it matches some patterns that makes the angry light bulb in the brain turn on, sometimes too quick :)
<qschulz>
mort: Those cheap SBCs come with a cost, you're doing the SW development for them :/
<qschulz>
Some companies are trying to do some work, but obviously that's specific to their HW design or usecases
<qschulz>
So, in short, it's always the final user that gets the shitty stuff :/
<mort>
"we should add $300 extra to BOM to get the exact same hardware specs but from someone who makes our software job easier" is always a tough ask :(
erg has joined #linux-rockchip
erg is now known as franoosh
<qschulz>
mort: spend +200k$ a year in engineering then :)
<mort>
not that there's really anything a vendor can do either, if a vendor had upstreamed great rk3588 support it would benefit those using vendors who don't do that too right
<qschulz>
mort: with such a narrow-minded view on things, we don't get anything upstream :)
<qschulz>
(not insulting you here, I've seen many people thinking that already)
<qschulz>
you're working for your customers, obviously some stuff is going to benefit your competitors
<qschulz>
Intel is still upstreaming stuff, even though it very likely benefits AMD, and vice-versa
<qschulz>
And there are industries in which you don't have a choice, you need an upstream base so you can follow CVEs for example
<mort>
I'm not saying vendors shouldn't upstream stuff, just that the logic isn't quite as straightforward as "buy more expensive SBC with rk3588, get better mainline kernel support"
naoki has quit [Quit: naoki]
<qschulz>
mort: I agree, but that's one of the solutions today. The other is to contract a company like Collabora to do the work for you right now
<mort>
it's more like, "buy more expensive SBC with rk3588 from a vendor who cares a lot about software, and contribute in a miniscule way to creating market pressure on vendors to participate in the upstreaming process"
<qschulz>
You get the cheap SBC/SoM on the long run, but you pay a huge upfront cost now
<qschulz>
The situation is: either you just take whatever your vendor gets you and you proxy your customer requests to their support and hope they fix stuff for you
<qschulz>
or you take what the vendor gets you and you spend some engineering efforts yourself to either patch their stuff and/or upstreaming stuff to free yourself from it
<qschulz>
pay a consulting company to do the work for you and your vendor
<qschulz>
or, wait for others to do all of this and hope they tackle your usecase and release your product in 10 years
<qschulz>
(the situation sucks in all cases)
<qschulz>
From a business PoV, this is terrible
<qschulz>
But many of us have a job thanks to that and we learn stuff. Ideally our job should be directly at the vendor's (e.g. like Intel I assume?) instead in small companies
<qschulz>
everyone suffers from vendor, to business, to customer, to end-user because nobody wants to spend the time or money :)
<qschulz>
</rant>
<qschulz>
(this is not directed at you, just my view on the industry in general)
<mort>
and I don't disagree
<mort>
if Rockchip had only upstreamed support, and my job consisted of grabbing mainline and making/adapting a devicetree to work on my particular SBC and enabling the necessary kernel config options, I would be so happy
<mort>
alternatively! If I worked for companies which had the kinds of resources necessary to let me spend most of my time trying to get an upstream kernel working and participate in the upstreaming and testing process, and just try to make this shit better for everyone, that would be amazing too
<mort>
but alas, I work for companies kind of expect me to spend my time making their products work, and I'm frequently the only person working on it so if I spend a week trying to help the rk3588 HDMI upstreaming effort that's me delaying some launch or release or whatever by a week
warpme has joined #linux-rockchip
dsimic has quit [Ping timeout: 240 seconds]
dsimic has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
System_Error has quit [Remote host closed the connection]
Livio has joined #linux-rockchip
System_Error has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
franoosh has quit [Remote host closed the connection]
psydroid2 has joined #linux-rockchip
warpme has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
ldevulder has quit [Ping timeout: 246 seconds]
Livio has quit [Ping timeout: 264 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Livio has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mort>
has anyone by any chance gotten hw accelerated Firefox to work with the Mali drivers? They seem to only provide EGL, not GLX
<mort>
at least glxinfo shows llvmpipe while eglinfo shows the mali drivers on my system
<linkmauve>
mort, try running Firefox on Wayland instead, it should use EGL then.
<mort>
linkmauve: I don't think this mali driver supports Wayland
<linkmauve>
Ah, then I can’t help you.
<mort>
anyway, I did try to force enable EGL and about:support says it is broken, and firefox outputs this to stderr: "[GFX1-]: glxtest: libEGL missing methods for GL test"
<linkmauve>
You can use Panfrost I think, it has been updated with panthor support which you can find in 6.10.
<mort>
yeah but mainline doesn't work with the rk3588
<mort>
HDMI specifically doesn't work, not sure if there are other issues as well
<mort>
which I got by dpkg-repacking a package from some FriendlyElec system image
<linkmauve>
Hmm, in btop’s list of partitions, only /boot is listed and not my rootfs, despite df, mount and other tools listing it correctly. This happens whether I boot off the microSD or off the NVMe, only the boot partition is listed there.
<linkmauve>
It reads /etc/mtab according to strace, but only ever uses the first partition there.
Livio has quit [Quit: leaving]
stikonas has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
naoki has joined #linux-rockchip
stikonas has quit [Ping timeout: 246 seconds]
Hypfer has quit [Quit: Ping timeout (120 seconds)]