20:58 <Lyude> hm

20:59 <Lyude> alyssa: something else we should clean up: there are a couple of headers in panfrost that have what look like copy pasted copyrights from other unrelated companies?

20:59 <Lyude> pan_screen.h says it's written by vmware thanks to keith whitwell ;P

21:24 <alyssa> Lyude: pan_screen.* -is- literally copypasted from other drivers (softpipe and vc4 mostly) :P

21:25 <alyssa> Thank you, VMWare, for your continued support of free GPU drivers on ARM! :P

21:37 <Lyude> alyssa: hehe; would still probably be good to change the copyright, all of that is just boilerplate so it's not really important to maintain previous copyrights

21:38 <Lyude> or at least the headers

21:38 <alyssa> mm, alright, I try to stay on the safe side

21:38 <alyssa> but you're probably right here

21:38 <Lyude> the actual code on the other hand we can say "Based on whatever"

21:39 <Lyude> that would also work for all of the headers; so long as it has Panfrost somewhere on it since we are making our own changes to this

22:14 <alyssa> do

22:14 <alyssa> oops

22:49 <Lyude> oh hey, looks like i might have misread something

22:49 <Lyude> i'm trying some stuff to get the current kapi working and it looks like they didn't change as much as I thought

22:50 <Lyude> which also makes it a lot less likely we're going to reuse this...

22:51 <alyssa> oh?

22:51 <Lyude> yeah, it looks like the handshake is still the same

22:52 <Lyude> (noticing a lot more now that I've actually got everything cross compiling and setup :)

22:53 <alyssa> wee!

22:54 <Lyude> it looks like the big change is just that they got rid of the silly ioctl header

22:55 <alyssa> OK

22:55 <Lyude> actually, with the number of changes here I'm going to say it might just be a better idea to start using their headers like hanezter said

22:55 <Lyude> *hanetzer

23:06 <Lyude> alyssa: also: a note about something we'll need to figure out: i'm probably just stripping support for the legacy kernel uapi

23:06 <Lyude> are you going to be able to work with that?

23:06 <Lyude> e.g. do your machines have access to newer kernel versions

23:07 <alyssa> I don't know

23:07 <alyssa> THere's allegedly mainline support for rk3399 but it's unclear if it's ready for daily use and this is my school machine

23:08 <alyssa> I'm keeping legacy support in userspace at least.

23:08 <alyssa> Do whatever you need in kernel space; I'll catch up when I can :)

23:08 <Lyude> alyssa: well that's the thing; i'm talking userspace here

23:09 <Lyude> the reason I want to do that is because then we can have a lot more systems (including mine and hanetzer's) work with this out of the box

23:09 <Lyude> (also-i can handle all the code parts in mesa for that)

23:09 <Lyude> (was kind of my plan anyway)

23:10 <Lyude> i also don't mind just helping you get the newer kernel module working on your machine if that's the issue

23:28 <Lyude> alyssa: that means we need to keep maintaining both until we get a kernel module, and that also means people are going to need to be able to test against both versions to make sure changes don't break things, unless you're going to test everything

23:28 <Lyude> alyssa: also-i'm not planning on doing this on master yet jfyi

23:29 <Lyude> not until things actually work well on my end

23:29 <alyssa> OK? Maintaining both is trivial?

23:30 <alyssa> 99.9% of code doesn't affect the kernel stuff, so if any non-kernel-related changes will work on both (or neither)

23:30 <alyssa> And I do test code?

23:30 <Lyude> well yeah-that's why I offered to help you get the kernel module working on your machine

23:31 <alyssa> That's not the issue

23:31 <alyssa> It's that this is a known good (i.e. stable) kernel, and any deviation from that is, well, risky for stability

23:32 <alyssa> So until it's bullet proof, I'm staying on the known-good

23:32 <alyssa> The good news is that.. what I use doesn't affect your kernel work, since having support for one API is not mutually exclusive with the other :)

23:33 <Lyude> actually it does-basic context setup from panfrost_nondrm.c doesn't even work on the latest arm kernel driver

23:33 <alyssa> ...and?

23:34 <alyssa> Having two code paths is not the end of the world; there's very little code at stake

23:35 <Lyude> what kernel are you running atm\

23:36 <alyssa> PMed

23:37 <Lyude> alyssa: I understand where you're comign from i'm just hesistant because you'll have to keep testing all of my changes to make sure that I'm not breaking things on your kernel

23:38 <alyssa> I have to test all changes to userspace anyway, regardless

23:38 <alyssa> :P

23:38 <Lyude> which i guess is one thing but i think we could at least give getting something else running on your machine a shot, especially since most of the people using this aren't using the old kernel drivers

23:38 <Lyude> yeah; that is true

23:39 <alyssa> What do you peg me for, someone who just pulls random code and pushes it to master without testing? :P

23:39 <Lyude> alyssa: remember it's been a while since i've actually worked on the same codebase as you :p

23:40 <alyssa> this is true

23:40 <Lyude> and the way you handle things is definitely different (in a good way!) then you did before

23:41 <Lyude> anyway-i'm just hesistant because 1-i can help with kernel issues anyway and 2-I'd like to actually know that getting something else running on your machine isn't just as simple as compiling a new mali_kbase

23:41 <Lyude> if it's a chromeos kernel it might not be terribly painful to just update the mali kbase in there

23:41 <Lyude> and i don't mind handling that

23:41 <alyssa> I'm just.. touching about my kernel, okay :P

23:41 <Lyude> ...i kind of do this every single rhel release so, i can't emphasis that last part more strongly

23:42 <Lyude> i also don't want to have to have three different kernel apis, assuming we do have our own kernel module eventually

23:42 <alyssa> wait, 3?

23:43 <alyssa> I thought it would be "legacy grossness" and "transient whatever-the-in-dev-kernel-module-uses"

23:43 <alyssa> No?

23:43 <Lyude> there would be the old uapi, the current mali kbase uapi that devices building the driver from source (like my vim2) will need, then the panfrost kernel

23:43 <Lyude> (old uapi being the one your laptop uses)

23:43 <alyssa> I thought #2 would morph into #3 as #3 is devved?

23:44 <Lyude> tbh maybe, but I'm not far enough to really know yet

23:45 <Lyude> also: do mainline kernels not work for your laptop?

23:48 <Lyude> heyheyey

23:48 <Lyude> basic context works now

23:48 <Lyude> alyssa: also we have some time to figure out what we want to do here: I expect this to take a bit of time

23:50 <Lyude> alyssa: also: we still have any kind of way to dump out the ioctls that it's sending between us and the kernel

23:51 <Lyude> wai

23:51 <Lyude> hold on there is no way context creation is all we needed to update

23:53 <Lyude> had a moment of hope there but realized it wasn't anything-glmark2 runs, but no image seems to come on screen before it hits oom in a second or two