RFC: Add abstraction layer between XVideo and device drivers #35
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I have been working on adding hardware acceleration for XVideo to another hardware platform (Rockchip RK3188). The glue code in sunxi_video seem to be largely reusable for other similar devices, so I've ended up changing it to act as an interface between a device driver and XVideo. This is somewhat similar to SunxiG2D, which is used as an abstraction layer by multiple hardware drivers. Note: This commit is for gathering feedback, please don't merge it in your main branches since it breaks stuff. Once we agree on a design, I'm willing to port the Sunxi driver to use this interface. Note, however, that I don't have any hardware set up for testing it, so it would be nice if someone else offered to test it or maybe port it themselves. In terms of functionally there are two things I've changed: * I've replaced the clipping stuff with a new function, which clips the drw area to the visible screen so that no content is attempted to be rendered off-screen, and at the same time it sets up margins and offsets for the src area so that only the correct content is rendered in the visible portion of the drw area. As far as I can tell, the results from xf86XVClipVideoHelper were not actually used(?) * I've split set_yuv420_input_buffer to a function which only sets up buffer related parameters and a second function called set_input_par which sets up x, y, w, h, stride parameters for the input buffer. This was required because these parameters need to be updated in xReputImage, but in that function we don't know have access to the other parameters that have to be passed to set_yuv420_input_buffer. * The driver struct has a flags field which can be used to control various features. The only flags I'm introducing is for enabling or disabling double (well, technically multiple) buffering. I need this feature for RK3188 since from my tests I can't change the frame pointer fast enough for video. I could also work around it using a custom copy_buffer(), but I think that would be quite dirty. :) I would appreciate a relatively quick discussion so that I can avoid publishing code depending on this draft. Thank you
|
All the old discussion about this patch actually happened on IRC. My primary concern at that time was the backwards/forward compatibility of the display ioctls from various Rockchip vendor kernels and the supported features (whether we need the multibuffering or not, etc.). Now that Rockchip has started to actively contribute their KMS driver to the mainline kernel, how does it affect us? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have been working on adding hardware acceleration for XVideo
to another hardware platform (Rockchip RK3188). The glue code
in sunxi_video seem to be largely reusable for other similar
devices, so I've ended up changing it to act as an interface
between a device driver and XVideo. This is somewhat similar
to SunxiG2D, which is used as an abstraction layer by multiple
hardware drivers.
Note: This commit is for gathering feedback, please don't
merge it in your main branches since it breaks stuff.
Once we agree on a design, I'm willing to port the Sunxi driver
to use this interface. Note, however, that I don't have any
hardware set up for testing it, so it would be nice if someone
else offered to test it or maybe port it themselves.
In terms of functionally there are two things I've changed:
the drw area to the visible screen so that no content is attempted
to be rendered off-screen, and at the same time it sets up margins
and offsets for the src area so that only the correct content is
rendered in the visible portion of the drw area. As far as I can
tell, the results from xf86XVClipVideoHelper were not actually used(?)
various features. The only flag I'm introducing is for enabling
or disabling double (well, technically multiple) buffering. I need
this feature for RK3188 since from my tests I can't change the
frame pointer fast enough for video. I could also work around it using
a custom copy_buffer(), but I think that would be quite dirty. :)
I would appreciate a relatively quick discussion so that I can avoid
publishing code depending on this draft. Thank you