12:59 <stormyknight3000> I was thinking about the problem with screen resoltuions other than 1080p requiring odd workarounds for different rockchip CPUs...

13:00 <stormyknight3000> it might be a bit hacky, but what about storing the correct values for the pixel clock (if I recall the name correctly) in text files alongside the rockchipdrm module?

13:01 <stormyknight3000> the only requirement would be the ability to detect which rk cpu and mali gpu is being used

13:01 <stormyknight3000> the correct values could be loaded at runtime during the initialization of the module

13:39 <robmur01> there's no technical issue with having SoC-specific data in the driver itself if that's the best way to solve a problem; the much bigger challenge is in *getting* that data - i.e. whether a given arbitrary rate can be generated stably on a given SoC - in the first place

15:26 <LinuxHackerman> Is that not something to handle in device trees?

15:40 <stormyknight3000> that's what I thought... but from what I heard yesterday, it was something different?

15:40 <stormyknight3000> I don't know, I haven't ever done nay kernel hacking in my lifetime so maybe this would be a good place for me to start just so I can help diagnose the problem

15:42 <robmur01> it's already "handled" in DT in as much as DT provides a SoC-specific compatible for the device so that the driver can know to implement SoC-specific behaviour

15:46 <LinuxHackerman> oooh silly me, I misread the message — I thought "getting" the data as in getting it into the driver, not collecting it in the first place

17:35 <stormyknight3000> robmur01 and LinuxHackerman, do you know of anyone who would be willing to mentor an amateur developer for kernel development? I would love to get into kernel development, but I don't know where to start. I am already pretty well-versed in the C language, but I could use some practical experience with memory management and low-level systems programming

17:36 <stormyknight3000> being able to figure out how to read a hardware spec to implement a driver or reverse engineer hardware to create the spec which would be the basis for the driver would be fantastic :D

17:37 <LinuxHackerman> Not me, sorry, I'm not really in that world, the closest I've come is building a bunch of kernels and writing a doc fix which I still haven't got around to working out how to submit upstream a year later :/

17:37 <stormyknight3000> that's alright, I will just have to keep looking around

17:38 <stormyknight3000> I can't find any classes anywhere that talk about kernel development and system programming

17:38 <stormyknight3000> so I might as well ask around to see if I can find someone who would help me gain some practical experience in the field

17:38 <LinuxHackerman> though I think if I wanted to do that on my own, I'd have a look at one of the rockchip TRMs and read the corresponding kernel source to see how it maps. But I don't have any real practical experience, so take that with a grain or three of salt.

17:40 <stormyknight3000> I might give that a try as well

17:40 <stormyknight3000> reading an implementation of a spec could be very useful indeed

17:47 <robmur01> sorry, I can't be much help either - I applied to the company for a general low-level software job, ended up being put to work on Linux, and here I still am years later

17:48 <robmur01> previously I was doing high-level data processing stuff plus a bit of control/data acquisition in science, and hacking on PIC micros as a hobby