ChanServ changed the topic of #arm-graphics to: Everything about graphics drivers on ARM (X11, Wayland, GLES, fbdev, KMS, Mesa, ...) - Logs at
dl9pf has joined #arm-graphics
cosm has joined #arm-graphics
<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
<cosm> on the other hand, fbdev with rotation on the same hardware is painfully slow
<ssvb> cosm: don't know, maybe it is using the 2D unit to do rotations?
<ssvb> cosm: checking the android sources (if they are available) might probably help, something around gralloc
<libv> hwcomposer is the key
<libv> if the display engine is used smartly by hwcomposer, then hwcomposer tells surfaceflinger that a given fb is shown as requested
<libv> otherwise, it is composited using gles
<ssvb> libv: the disp layers on sunxi hardware do not support rotation, right?
<ssvb> libv: I just wonder what would be the best way to have video overlays working in the rotated screen setup
<cosm> right, in this case it sounds like it's probably using gles
<cosm> ssvb: the ones on rk3* don't support rotation
<ssvb> cosm: then the GLES compositing as suggested by libv sounds like a reasonable explanation
<cosm> the reason I'm asking about this stuff is because I am bringing up GNU/Linux on a tablet
<cosm> so screen rotation would be really nice to have
<cosm> especially as the native orientation is portrait
<ssvb> cosm: do you have mali working with your kernel?
<ssvb> cosm: it would be interesting to check if works out of the box
<cosm> I don't have mali working
<ssvb> no mali kernel module at all?
<cosm> it's supposed to be working, but after a few hours I've abandoned it since I wasn't using it at all
<cosm> *after a few hours of failing to get it working
<ssvb> do you have the mali.ko module? or is it completely disabled at the moment?
<cosm> as far as I remember the modules are building and loading successfully, the problem seemed to be in userspace
<libv> ssvb: as far as i remember, they don't indeed
<libv> does sunxi g2d do rotation?
<libv> ssvb: that's your area ;)
<ssvb> libv: yes, g2d supports rotation, but it is not available on sun5i, which is used for tablets too
<ssvb> cosm: can you just try the instructions from to check if it suddenly happens to work?
<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
<cosm> ssvb: will do
<ssvb> cosm: as for rotating the whole framebuffer, I'm afraid that we don't have many useful options
<ssvb> cosm: that's kind of like hardware accelerated shadow framebuffer, which should be a bit better than doing it in software
<ssvb> cosm: I know that the display controller at least in OMAP3 could do the rotated scanout
<ssvb> cosm: the display controller in Allwinner devices can't do this
<ssvb> cosm: you can probably check if the RK framebuffer driver sources have any hints
<cosm> ssvb: the user manual for rk3066 says nothing about resolution being supported
<cosm> and the only mentions in the drivers are in some dead code which uses one of the 2D accelerators
<cosm> to copy the rotated fb
<cosm> some mipi displays seem to support rotation and mirroring, but I'm not sure if it's a standard feature
<cosm> since the whole mipi thing is locked down
<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
<cosm> but it doesn't say anything about rotation
<cosm> uhm, I've just noticed I've said resolution above
<cosm> it was supposed to be rotation
<ssvb> yes, I also noticed this typo, but understood what you mean :)
<cosm> I've seen there's a tablet with a 2048x1536 LCD using RK3188
<cosm> that's just crazy
libv has quit [Ping timeout: 260 seconds]
libv has joined #arm-graphics