11:58 <rtp> alyssa: hi. fwiw, yesterday I've done a very quick test on my t628 of mesa master. With kmscube, got the background with no cube. mesa master + revert of 5a7688fdecd76c7d9cd87f6f6c93eb32870a2146, I'm getting the cube

13:14 <alyssa> rtp: Interesting, that commit was supposed to make T600 *easier* to support :(

13:14 <alyssa> Thank you for the update

13:19 <alyssa> rtp: Do you think you could do some, ahem, bit twiddling?

13:20 <alyssa> With that commit applied, go through the various bits that changes (gl_enable, unknnown_10, tiler_gl_enables) and try using old values / a mix of the old and new values?

13:37 <rtp> alyssa: ok. will try to find some time tonight to do that.

13:46 <alyssa> rtp: Good luck! :)

13:46 <alyssa> (BTW, when I say a mix, I mean at a bit level, these are bit fields)

13:51 <rtp> well, I think I'm going to tried reverting the patch hunk by hunk instead of reverting the whole patch or something like that.

13:52 <alyssa> That might do it, but it's too coarse and the patch has a lot of internal dependencies

13:52 <alyssa> We generally do want to keep the 64-bit stuff, it's just a matter of which flags need to be set for 64-bit + T6XX

13:57 <rtp> yeah I understand that being able to drive 32 bit with 64 bit code should make things easier

13:57 <alyssa> rtp: It's not that, so much as maintaining a single code path is easier

13:57 <alyssa> And... if your board is 32-bit and my reference board is 64-bit, invariably your board is going to be broken half of the time

13:58 <alyssa> With 64-bit universal, that shouldn't happen since there's no divergence :)

14:02 <rtp> alyssa: oh, that's what I meant. Sorry if I was not clear enough

14:07 <alyssa> No worries :)