05:49 <tomeu> alyssa: yep, that was it, yesterday I pushed what I needed to do to get that working

05:49 <tomeu> I'm looking a bit at weston this morning

06:12 <alyssa> tomeu: awesome!

07:44 <tomeu> good news: weston displays with the drm backend and gl renderer, bad news: everything is upside down and the colors are all messed up

07:45 <tomeu> alyssa: everything seems to be rotated 180 degrees, any ideas?

07:59 <HdkR> tomeu: Upside down to whom? Since OpenGL coordinate system is flipped

07:59 <tomeu> ran out of time for this week

08:00 <HdkR> origin is bottom left in GL, while almost everywhere else it is top left right

08:00 <tomeu> HdkR: the rendering is all rotated 180 degrees when compared to using the pixman renderer

08:00 <HdkR> Wait, actually rotated 180 degrees, not just flipped?

08:00 <HdkR> :P

08:00 <tomeu> yeah, not really flipped

08:01 <HdkR> Don't hardware display engines typically have support for rotating planes?

08:02 <tomeu> sometimes, though some restrictions use to apply

08:02 <tomeu> but in this case, I think it's something wrong with the rendering

08:02 <HdkR> Interesting

08:03 <tomeu> as the pixman renderer displays just fine on rockchip without anything special

08:03 <tomeu> there's lots of artifacts, hopefully someone with knowledge of the rendering side of things can look at it before I have time again to work on the winsys

08:16 <tomeu> actualy, I think it isn't rotated, but flipped on both axis

08:17 <tomeu> guess that if we're rendering to scanout, we should be flipping stuff as the display hw expects

08:26 <tomeu> finally understood what's going on, I shouldn't have removed the fb flipping code

08:26 <tomeu> only make it use the right stride

08:53 <tomeu> ok, all is pushed

09:23 <tomeu> if someone could try it out with kmscube and/or weston and try to figure out what the artifacts are due to, that would be great :)

12:18 <davidlt> http://lkml.iu.edu/hypermail/linux/kernel/1812.0/04025.html

12:18 <davidlt> [PATCH v1 0/9] Overview of Arm komeda display driver

16:10 <alyssa> tomeu: Uhhhhh, if you said flipped-Y (reflected along the X axis, I guess), then I'd say "Of course it is - you just commented out the code that flips the framebuffer back to normal!"

16:11 <alyssa> It's possible that wasn't the right place for it; you might need to adjust something at the winsys side but then do the stri-- Ah, read the rest of the backlog

16:12 <alyssa> tomeu: Is anything special needed to try it? (Should I be able to just compile and run from a VT on my chromebook running a chromeos 4.4 kernel?)

16:13 <Lyude> alyssa: you probably will need an up to date mali_kbase module

16:15 <alyssa> alright

16:15 <alyssa> I wasn't sure what the status on kbase-updating was

18:14 <Lyude> alyssa: yeah it's still happening

18:15 <Lyude> alyssa: I'd give a shot at trying to compile https://gitlab.freedesktop.org/lyudess/mali_kbase/commits/meson-gxm-khadas-vim2/TX041-SW-99002-r27p0-01rel0 - it's got some meson specific changes (that I need to get rid of and actually fix the problems that they work around) but those shouldn't make any difference with the default platform in the config, devicetree

18:16 <Lyude> might even compile just fine against your chromeos kernel

23:17 <alyssa> Alright :)

23:21 <Lyude> if it doesn't let me know, i'll be happy to help