Set orientation from DRM on fallback
ClosedPublic

Authored by romangg on Nov 24 2019, 4:09 PM.

Details

Summary

In case of a failed atomic commit the previous mode should be fallen back to.
For orientation provide again a setter that DRM backend can use to set the
transform back to the last working one.

Test Plan

Compiles, fallback works, cursor still messed up somewhat (scaling issue?).

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.
romangg created this revision.Nov 24 2019, 4:09 PM
Restricted Application added a project: KWin. · View Herald TranscriptNov 24 2019, 4:09 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Nov 24 2019, 4:09 PM
zzag added a subscriber: zzag.Nov 26 2019, 7:57 AM

Thank you for looking into this! The way conversion between Qt::ScreenOrientations and DeviceInterface::Transform is done seems to be wrong.

Mixing both Qt::PortraitOrientation and Qt::InvertedPortraitOrientation doesn't make sense. Wouldn't it be better to introduce a screen transformation enum and use it instead of Qt::ScreenOrientations?

In D25507#567590, @zzag wrote:

Thank you for looking into this! The way conversion between Qt::ScreenOrientations and DeviceInterface::Transform is done seems to be wrong.

Mixing both Qt::PortraitOrientation and Qt::InvertedPortraitOrientation doesn't make sense. Wouldn't it be better to introduce a screen transformation enum and use it instead of Qt::ScreenOrientations?

Yes, it would be better I believe. But I wanted to first try to fix the current approach before thinking about replacing it.

zzag added a comment.Nov 26 2019, 11:24 AM

I don't see any particular reason that holds us from doing that, but meh fair enogh. Could you please create a Phabricator task so we don't forget to refactor this code?

romangg edited the test plan for this revision. (Show Details)Nov 26 2019, 9:32 PM
This revision was not accepted when it landed; it landed in state Needs Review.Nov 26 2019, 9:33 PM
This revision was automatically updated to reflect the committed changes.
In D25507#567683, @zzag wrote:

I don't see any particular reason that holds us from doing that, but meh fair enogh. Could you please create a Phabricator task so we don't forget to refactor this code?

See D25558

zzag added a comment.Nov 26 2019, 11:18 PM
In D25507#567683, @zzag wrote:

I don't see any particular reason that holds us from doing that, but meh fair enogh. Could you please create a Phabricator task so we don't forget to refactor this code?

See D25558

Thanks.