13:37 <cosm> any idea how screen rotation works on android? as far I can tell it doesn't use hardware support and there's no noticeable performance degradation

13:37 <cosm> on the other hand, fbdev with rotation on the same hardware is painfully slow

15:40 <ssvb> cosm: don't know, maybe it is using the 2D unit to do rotations?

15:42 <ssvb> cosm: checking the android sources (if they are available) might probably help, something around gralloc

15:55 <libv> hwcomposer is the key

15:56 <libv> if the display engine is used smartly by hwcomposer, then hwcomposer tells surfaceflinger that a given fb is shown as requested

15:56 <libv> otherwise, it is composited using gles

15:58 <ssvb> libv: the disp layers on sunxi hardware do not support rotation, right?

16:01 <ssvb> libv: I just wonder what would be the best way to have video overlays working in the rotated screen setup

16:05 <cosm> right, in this case it sounds like it's probably using gles

16:07 <cosm> ssvb: the ones on rk3* don't support rotation

16:09 <ssvb> cosm: then the GLES compositing as suggested by libv sounds like a reasonable explanation

16:09 <cosm> the reason I'm asking about this stuff is because I am bringing up GNU/Linux on a tablet

16:10 <cosm> so screen rotation would be really nice to have

16:10 <cosm> especially as the native orientation is portrait

16:11 <ssvb> cosm: do you have mali working with your kernel?

16:11 <ssvb> cosm: it would be interesting to check if https://github.com/ssvb/lima-memtester/ works out of the box

16:12 <cosm> I don't have mali working

16:12 <ssvb> no mali kernel module at all?

16:13 <cosm> it's supposed to be working, but after a few hours I've abandoned it since I wasn't using it at all

16:13 <cosm> *after a few hours of failing to get it working

16:14 <ssvb> do you have the mali.ko module? or is it completely disabled at the moment?

16:15 <cosm> as far as I remember the modules are building and loading successfully, the problem seemed to be in userspace

16:16 <libv> ssvb: as far as i remember, they don't indeed

16:16 <libv> does sunxi g2d do rotation?

16:16 <libv> ssvb: that's your area ;)

16:17 <ssvb> libv: yes, g2d supports rotation, but it is not available on sun5i, which is used for tablets too

16:18 <ssvb> cosm: can you just try the instructions from http://linux-sunxi.org/Hardware_Reliability_Tests to check if it suddenly happens to work?

16:19 <cosm> on rockchip I could use the 2D unit to rotate the whole framebuffer, but even if that works I'm afraid it would really kill the memory bandwidth on high resolution displays

16:19 <cosm> ssvb: will do

16:24 <ssvb> cosm: as for rotating the whole framebuffer, I'm afraid that we don't have many useful options

16:25 <ssvb> cosm: that's kind of like hardware accelerated shadow framebuffer, which should be a bit better than doing it in software

16:25 <ssvb> cosm: I know that the display controller at least in OMAP3 could do the rotated scanout

16:26 <ssvb> cosm: the display controller in Allwinner devices can't do this

16:26 <ssvb> cosm: you can probably check if the RK framebuffer driver sources have any hints

16:27 <cosm> ssvb: the user manual for rk3066 says nothing about resolution being supported

16:28 <cosm> and the only mentions in the drivers are in some dead code which uses one of the 2D accelerators

16:28 <cosm> to copy the rotated fb

16:28 <cosm> some mipi displays seem to support rotation and mirroring, but I'm not sure if it's a standard feature

16:29 <cosm> since the whole mipi thing is locked down

16:30 <cosm> I also have the datasheet for the RGB-to-MIPI bridge, which presumably has a buffer large enough for at least a complete frame

16:30 <cosm> but it doesn't say anything about rotation

16:32 <cosm> uhm, I've just noticed I've said resolution above

16:33 <cosm> it was supposed to be rotation

16:37 <ssvb> yes, I also noticed this typo, but understood what you mean :)

17:04 <cosm> I've seen there's a tablet with a 2048x1536 LCD using RK3188

17:04 <cosm> that's just crazy