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.
Details
- Reviewers
romangg davidedmundson - Group Reviewers
KWin Plasma - Commits
- R108:77b5c3caa953: [platforms/drm] Add support for rotation property on the Plane
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.
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.
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? |
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.