Page MenuHomePhabricator

e wl rotation not working
Open, TODOPublic

Description

Going to put this in for tracking. e should really support all rotations regardless of drm device/output. evas can render rotated (gl surely can) and it works in almost all engines. it should work in ecore_evas drm and be used by e for rotation.

IMHO the ecore_evas + evas engine should, IF the drm device can more optimally rotate itself, then use that feature transparently if possible. the raw interface should be at ecore_evas ... or in future at the evas output level.

don't forget to ALSO rotate input. especially touch input (possibly/probably also handle specifically mapping specific touch devices to specific outputs WITH specific calibrations (rotations) as the touch device may or may not report in the same orientation as "native rendering without rotation".

this is necessary for pretty much every device like a phone, tablet, smart fridge, and watch as well as pc monitors and laptops/convertible displays etc.

don't forget that any "optimizations" like hw plane fiddling, direct buffer swapping of clients to bypass the compositor if they are fullscreen etc. should account for rotation etc.

but as it stands now... it's pretty broken/useless on many devices i am trying (touch laptops). i know many people who also rotate their desktop monitors... i do not but if i did i'd be in trouble too.

raster created this task.Sep 10 2017, 8:08 AM
zmike lowered the priority of this task from High to TODO.Sep 13 2017, 9:07 AM

I've pushed some commits for this to make rotation work (software mode) for the drm engine. This work is not complete yet as I still need to deal with rotating input, and I have a pending patch for Enlightenment which will enable all rotations in the dialog however I do not wish to push That patch until the input rotation is sorted out.

Actually... You may need the ability to rotate some inputs separately to the screen. Just saying... Probably good they rotate along with the screen normally but there will need to be the ability to explicitly rotate SOME inputs like touch (also to specifically assign specific touch inputs to specific screens). The touch panels may or may not have rotated input relative to the pixels of the screen. So when you do this, I'd add a flag to have touch rotation separate to screen (or other inputs too) and then define the rotation of these explicitly if flagged to not be the same. default would be to be the same i would assume.

So ... I have implemented software rotation for the drm engine (along with hardware rotation when possible). The input coordinates are all getting transformed properly (according to rotation) and that works good when we rotate via hardware.

There is an issue (and I am not sure where) when we rotate via software. Essentially, the pointer in Enlightenment is getting confined to an area maybe 100x100 in the top-left corner (when we rotate to 90 degrees via software). When I printf the pointer coordinates, they are all proper ... yet the Enlightenment pointer is still not moving :( There appears also to be some "garbage" being drawn in the pointer area when we move it.

Not really sure how to proceed here. I can push the changes to enable output rotation for all degrees to Enlightenment, however I fear that may cause an excessive amount of Phab tickets due to the pointer not moving and the garbage being drawn. I could (as an alternative) push those changes into a branch and let someone who knows more about E's pointer take a look.

Any thoughts ? from anyone ??

push the changes as before it wasnt even possible to rotate at all..

zmike added a comment.Oct 16 2017, 3:57 AM

If this involves substantial patches to Enlightenment, I would prefer to wait since the final release is scheduled for next week.

i looked at this before and the changes to e are minimal (and only affect wayland support, not x11). most of the work is in the engines/ecore_evas. at least without this work it won't rotate at all unless you have specific rotation support in the output crtc/dac unit which isn't as common as you'd think.

zmike added a comment.Oct 16 2017, 7:36 AM

I could (as an alternative) push those changes into a branch and let someone who knows more about E's pointer take a look.

Any thoughts ? from anyone ??

I missed this post last week, but I don't understand why this wasn't developed in a public branch to begin with?

i looked at this before and the changes to e are minimal (and only affect wayland support, not x11). most of the work is in the engines/ecore_evas. at least without this work it won't rotate at all unless you have specific rotation support in the output crtc/dac unit which isn't as common as you'd think.

It's difficult for me to formulate an opinion here as I don't see any phabricator diffs or public branches containing patches for rotation. I'll instead restate that the final release of E22 is currently scheduled for next week and large or untested patches should probably be withheld if they may impact core compositor functionality.

devilhorns added a comment.EditedOct 26 2017, 11:44 AM

I've pushed the Enlightenment changes to a branch here:

https://git.enlightenment.org/core/enlightenment.git/log/?h=devs/devilhorns/rotation

It's fairly non-invasive. I've tested this patch extensively .... and there is an issue that I would appreciate some help with. Basically the issue is that if you run E with the Software Engine, and do a rotation which is not "hardware supported" (like 90 degrees, or 270 degrees), then the Enlightenment mouse pointer gets stuck in the corner of the screen and no amount of elbow grease will make it move :( In Addition, there is garbage being drawn in/around/under the pointer image :(

Any help would be appreciated as I've exhausted myself digging into this...

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:57 AM
zmike edited projects, added efl: display system; removed Restricted Project.Jun 11 2018, 9:13 AM