[platforms/drm] Add support for rotation property on the Plane
ClosedPublic

Authored by graesslin on Oct 31 2017, 5:10 PM.

Details

Summary

A preparation step to support rotation of outputs. The idea is to rotate
using DRM directly and not add it to the compositors. With this change
and a small hack to try it, I was able to rotate the screen.

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
graesslin created this revision.Oct 31 2017, 5:10 PM
Restricted Application added a project: KWin. · View Herald TranscriptOct 31 2017, 5:10 PM
Restricted Application added subscribers: kwin, plasma-devel. · View Herald Transcript
romangg added inline comments.Oct 31 2017, 5:54 PM
plugins/platforms/drm/drm_object_plane.cpp
125

Check not necessary.

plugins/platforms/drm/drm_object_plane.h
108

I wouldn't add an additional variable, since its value is saved in the Rotation property. You can retrieve it by calling

DrmObject::value((int)PropertyIndex::Rotation)
graesslin updated this revision to Diff 21666.Oct 31 2017, 6:40 PM

Incorporate suggested changes

Restricted Application edited projects, added Plasma; removed KWin. · View Herald TranscriptOct 31 2017, 6:40 PM
graesslin updated this revision to Diff 21667.Oct 31 2017, 6:52 PM

Call it "Transformation" instead of "Rotation" and make it proper flags.

After further reading I noticed one needs to combine the flipped and rotated flags
for some transformations on Wayland Outputs. And on Wayland Outputs it's called transform.

Restricted Application edited projects, added KWin; removed Plasma. · View Herald TranscriptOct 31 2017, 6:52 PM

Do you think we'll need a compositor fallback?

*If* we do have a compositor fallback, then I don't see the point of a DRM specific codepath, it's not going to have any slower having a transform in painting, and will just result in one code path not getting tested.

To mostly answer my own question:

In hwcomposer, it seems we have a transform attribute on the layer.

For nested wayland we can set a transform on our wl_surface.

For FBDev or nested in X, I don't think we can. But probably don't care?

plugins/platforms/drm/drm_object_plane.h
63

why don't we use DRM_MODE_ROTATE_0 for the values?

Do you think we'll need a compositor fallback?

*If* we do have a compositor fallback, then I don't see the point of a DRM specific codepath, it's not going to have any slower having a transform in painting, and will just result in one code path not getting tested.

To mostly answer my own question:

In hwcomposer, it seems we have a transform attribute on the layer.

For nested wayland we can set a transform on our wl_surface.

For FBDev or nested in X, I don't think we can. But probably don't care?

Yep. And that's why I don't want to add a compositor fallback. Doing the fallback looked quite complex when I looked at it due to multi screen.

ngraham added a subscriber: ngraham.Nov 1 2017, 6:49 PM
davidedmundson accepted this revision.Nov 2 2017, 5:41 PM
This revision is now accepted and ready to land.Nov 2 2017, 5:41 PM
This revision was automatically updated to reflect the committed changes.