01:17 <hanetzer> alyssa_: you can do it internally with mtd-utils iirc

01:17 <alyssa_> hanetzer: I'm listening :p

01:18 <hanetzer> forget the exact program and invocation, but I did it that way. dd if=/dev/mtd0 of=bios.img ; do the gbb stuff, then lemme see if I can remember

01:20 <hanetzer> think it was something like flash_eraseall -j /dev/mtd0 && flashcp bios.img /dev/mtd0

01:22 <alyssa_> ....Yeah I don't want a brick... ;P

01:23 <hanetzer> heh, which is why you copy bios.img away first :)

01:24 <alyssa_> hanetzer: Oh, right, so I can reflash it with my nonexistent flash equipment

01:24 <hanetzer> ch341a_spi device, $5usd shipped from amazon :P

01:25 <alyssa_> Look, I maintain if a general purpose free software solution is inaccessible to my nontechnical grandmother or to my nontechnical close friends, it's of limited utility anyway..

01:26 <alyssa_> For many purposes, I'm non-technical... there's a specific sliver of the stack I focus on, and the rest I expect to just work (to paraphrase Torvalds)

01:27 <alyssa_> Disassembling a laptop to use external flashing equipment is WAY out of my comfort zone, _and there is zero reason it should be to the contrary_

01:27 <hanetzer> fair enough. I mess with everything tho :P

01:27 <alyssa_> If that's a prerequisite to using a laptop with free software, free software _has already failed_ on that device. Luckily it's not that bad, but..

01:27 <hanetzer> honestly, 'disassembling' is really unfair kevin. 8 screws, phillips.

01:27 <hanetzer> unfair to*

01:28 <hanetzer> like, its not some massive hp laptop with like 28 screws just to get at the mobo :P

01:28 <alyssa_> 8 > 0

01:28 <alyssa_> So as far as user friendliness goes, the laptop's still screwed

01:30 <hanetzer> fair enough, but its hella easier on the kevin than speedy, thats for sure. granted, I keep damned near all my hardware in various states of disassembly :P

01:30 <alyssa_> Technical expertise in any particular area _cannot_ be the price to freedom, or invariably we're in the chains.

01:33 <hanetzer> \o/

02:28 <chewitt> @alyssa_ speaking of the technically inexperienced (me and my users) .. any chance you can look at the Kodi default screensavers?

02:28 <chewitt> currently if the default savers start (black and dim) the GUI is dead and needs a restart to fix

07:45 <narmstrong> So on RK3399, afbc is limited to 2560x1600 ? So you can’t render full 4k using afbc ?

07:45 <narmstrong> (I need to check this kind of limitation on S912...)

08:17 <urjaman> hanetzer: i think speedy is also 8 screws and you can lift the keyboard-containing-plate up? (just counted :P) ... tho 2 of them are under those pads so... relative.

08:17 <urjaman> oh well and clips tho... i already half-forgot things...

14:52 <alyssa_> narmstrong: 2560 limit horizontally. The public spec for rk3399 says 1600 is a verical limit, but krh says that shouldn't actually matter. But no, no 4K

14:52 <alyssa_> ....unless you rotate your monitor! ;)

19:00 <narmstrong> alyssa_: it's kind of a solution

19:05 <alyssa_> narmstrong: :P

19:05 <alyssa_> What's your interest in RK anyway? :P

19:07 <chewitt> RK, Allwinner and Amlogic have a lot of common IP in several key areas

19:08 <chewitt> and similarly dismal availability of documentation

19:10 <alyssa_> Touche

19:15 <alyssa_> cwabbott: hanetzer: HdkR: Lyude: tomeu: robher: So, I'm going to preface this by saying my emotions are a little wacky right now, but I just want to let y'all know how grateful I am to have you as co-contributors on Panfrost. There are a lot of grumbly FOSS projects out there, but you care bears make playing with Panfrost super fun and.... well, a year and a half ago people would've laughed at the idea of proper upstream support for mo

19:15 <alyssa_> dern Mali's, and yet here we are thanks to each one of your work. Thank you for the continued amazing contributions and for being awesome friends/people. I know "thank you" doesn't get said nearly enough in the free software community, let alone in the world at large, but y'all deserve it. You :clap: are :clap: amazing~

19:16 <alyssa_> daniels: ....and thank you for talking me down out of *more than one* "Rawr I'm quitting open sourcez forever!!!" melt down ;)

19:21 <narmstrong> alyssa_: your RK AFBC implement will help me, thx :-) even if the HW is different, the DRM glue will serve me as a valuable example !

19:22 <alyssa_> narmstrong: Shh you're ruining the moment ;P

19:30 <daniels> alyssa_: np, thankyou for creating the project in the first place & subsequently failing to quit forever :)

19:31 <Lyude> alyssa_: and thank you for all of the work you've put into this :)

19:32 <alyssa_> <3

19:41 <HdkR> alyssa_: Same emotional response back to you. You're doing good work :)

21:06 <hanetzer> alyssa_: no prob, for what little I've done towards it, I'm mostly grateful you got the ball rolling :P

21:07 <hanetzer> I mean, all I've written is some hwinit stubs which were mostly rearranged bits from the arm driver in proper kernel style, plus the tracing bit :P

21:08 <hanetzer> and even if you do quit forever, thanks for putting the code in view of the public so it can't vanish with you :D

21:38 <urjaman> lol, super supportive and stuff :D

21:40 <urjaman> anyways thank you all for being here (even tho i havent really gotten the energy to get into coding this), this is a good place to be

21:41 <urjaman> meanwhile, i'm figuring out dithering on an RK3066 ... ("maybe just try upstreaming this one little patch, cant be that hard he thought"...)

21:51 <alyssa_> urjaman: Dithering on RK3288 wasn't enough of an excercise as it was? :P

21:55 <urjaman> i mean apparently the driver needs to support all the chips :P (and someone just added RK3066 so that wasnt in the 4.20 i was using as my base (yeah i was lazy))

21:58 <alyssa_> urjaman: Mmblep

21:58 <urjaman> anyhows, doesnt seem like too hard, rk3066 just doesnt have the allegro/frc selector bit so i figure it's better to make the code not warn about unsupported bits ...

23:27 <Lyude> HdkR: you don't have any bf work pending for upstream mesa atm correct?

23:30 <alyssa_> Lyude: I think all the bi stuff is downstream right now

23:30 <HdkR> Lyude: Correct, it's just sitting in my branch atm

23:30 <alyssa_> I left the `bifrost/` folder out when merging upstream since there was just too much code to deal with and I didn't want to also add the burden of code I couldn't even test

23:31 <Lyude> HdkR: btw, mind linking me to your branch?

23:31 <alyssa_> Now that we're settled in, I'd be happy to take well-written patches to add back that stuff

23:31 <HdkR> https://gitlab.freedesktop.org/sonicadvance1/mesa/tree/bifrost_compiler

23:32 <Lyude> HdkR: cool

23:34 <HdkR> Been a month since I've touched it sadly

23:37 <Lyude> HdkR: any idea if this was originally based off upstream mesa after we merged panfrost, or was it downstream panfrost?

23:38 <HdkR> Downstream

23:38 <HdkR> Could probably rebase it with little trouble

23:38 <Lyude> alright, guess first place to start would be rebasing yeah

23:38 <alyssa_> Please do.

23:38 <alyssa_> Lyude: My advice? Don't rebase, just copy the bifrost/ dir to a fresh upstream mesa

23:39 <HdkR> I was thinking more just cherry-picking

23:39 <HdkR> :P

23:39 <Lyude> alyssa_: yeah don't worry, merging very difficult to merge things in git is kind of half of my dayjob :p

23:39 <alyssa_> Lyude: I mean, noted for future reference, but

23:40 <alyssa_> When you send upstream bifrost stuff in the first place, I'm going to want it all squashed to one or two commits.

23:40 <Lyude> alyssa_: of course

23:40 <alyssa_> So you can probably save yourself a spike in blood pressure by just squashing it now :P