-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Add screen orientation support for Linux framebuffer #20154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
… frame buffer and DRM applications. This commit introduces support for screen orientation across various components by adding a new `Orientation` property of type `SurfaceOrientation` in `DrmOutputOptions` and `FbDevOutputOptions`. The `IScreenInfoProvider` interface is updated to inherit from `ISurfaceOrientation`, ensuring consistent orientation management. Key changes include: - Enhanced `FramebufferToplevelImpl` to handle orientation in size calculations. - Updated `LibInputBackend` for device input coordinate rotation based on screen orientation. - Implemented `ISurfaceOrientation` in `DrmOutput` and `FbdevOutput` classes. - Modified `DrawingContextImpl` to support canvas rotation based on orientation. - Improved `FramebufferRenderTarget` and `PixelFormatConversionShim` to respect framebuffer orientation during surface creation and pixel format conversions. - Streamlined rendering methods to ensure drawing operations align with the current surface orientation. - Removed redundant code related to framebuffer handling.
…bre/Avalonia into screenorientation
Theres really no point to do this in fbdev.
|
Removed the breaking changes so I could use the test builds. |
|
Please read the following Contributor License Agreement (CLA). If you agree with the CLA, please reply with the following: Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by AvaloniaUI OÜ and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant AvaloniaUI OÜ, and those who receive the Submission directly b. Patent License. You grant AvaloniaUI OÜ, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to AvaloniaUI OÜ. You agree to notify AvaloniaUI OÜ in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the Republic of Estonia, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and AvaloniaUI OÜ dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. 1 out of 2 committers have signed the CLA. |
|
@cla-avalonia agree |
|
You can test this PR using the following package version. |
42ceb43 to
1f0756c
Compare
|
You can test this PR using the following package version. |
70930fe to
6b7da48
Compare
|
You can test this PR using the following package version. |
6b7da48 to
65d05fe
Compare
65d05fe to
70ec077
Compare
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
Add screen orientation support for Linux DRM applications.
This is being continued on from #18658 to solve all the review comments from that PR, and change to a method that isn't Skia dependent and should work with any 2D backend.
Thanks @aguahombre for the initial implementation, I left your commits in here. I'm working on a project that needs this, so am willing to help push it across the finish line.
What does the pull request do?
Implement screen rotation for Linux kiosk applications for situations where the Linux drivers do not support all orientations of the display screen.
Supports 0, 90, 180 and 270 degree rotation of the display.
The touch screen input coordinates are also rotated to match the screen orientation.
Implemented in the output backend for DRM using an OpenGL shader and offscreen framebuffer. Only in the pipeline if there is a rotation requested, so no cost for no rotation.
Dynamic changing is not supported, must be set at DRM initialization time.
The names of the enum match the Android names and values to allow for a potential unification in the future.
The ControlCatalog program was updated to allow testing the functionality.
What is the current behavior?
See #18535 and #14241
Attempts to implement display rotation at the application level using RotateTransform on the MainView or EmbeddedRoutControl fail as any Combo and Popup menus appear unrotated and in the wrong position. Also, scrolling via touch input does not work for rotated views.
What is the updated/expected behavior with this PR?
Create a kiosk app with DrmOutputOptions Orientation set to one of the four SurfaceOrientation enum values to rotate the display output and touch input.
This has been tested on a Raspberry Pi 5 running a Raspberry Pi Touch Display 2.
How was the solution implemented (if it's not obvious)?
A 2nd framebuffer is created in DrmOutput when a rotation is requested to handle rotating the image into the DRM framebuffer.
Checklist
Breaking changes
No breaking changes, the scope is very limited and there should be no code differences with Rotation0 set.
Obsoletions / Deprecations
None
Fixed issues
Fixes #18535 and #14241
API Changes
One big question is adding SurfaceOrientation to Avalonia.Platform going to be too big of a change to Android apps? Since it also has its own instance of SurfaceOrientation? The way #18658 was implemented, that enum needed to cross project boundaries, but with how this is implemented its entirely contained in the Framebuffer project. So we could move it completely into the Framebuffer project and namespace if that makes things easier.