-
Notifications
You must be signed in to change notification settings - Fork 80
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
Proof of concept OSD code. #10
base: master
Are you sure you want to change the base?
Conversation
Awesome! But may I ask, how slow is "too slow"? Just a user question, would be great to know some data about what formats and on what resolutions work good with OSD. If this is is the only OSD solution possible, it might be even needed to add info to the wiki for users to know what to expect. |
I added a branch of my idea for OSD support. It is far from optimal too, but at least it's pretty fast and I have many optimizations in mind. Seems like we doubled some work, sorry for not pushing this earlier. |
I think it's not exactly duplicated code. |
No, of course not duplicate, only vdp_output_surface_put_bits_indexed() Well, it doesn't strictly depend on G2D, this could be done in software too. It even needs to get some software fallback for SoCs without G2D. But most sunxi SoCs have G2D, so why not use it. The main difference is that my version puts a second disp layer over the video with real alpha blending. I'm still not quite sure if this is really better than using X (a little bit more optimized). It will be necessary to support "both", as a second alpha blended layer makes it impossible to use color key, so no window overlapping. I had many ideas how to do all this, but not much time to try. |
Hi guys. It's great to see some progress with the OSD feature support. We talked about this with @jemk some time ago on #linux-sunxi irc, and in my opinion the xorg ddx driver has the best control over what part of the window is visible at any time. So that it may handle fully visible or partially overlapped windows in the most optimal way. On a technical side, we can implement some basic DRI2 support for libvdpau-sunxi in https://github.com/ssvb/xf86-video-fbturbo and get it nicely integrated. The dri2 workflow is that the the clients may do two things:
This may look rather invasive. Except that we may treat "dri2 buffer" as not a real buffer with pixels, but as just some sort of a unique token. The cedar kernel driver can be extended with some new ioctl to support storing data by token and retrieving data by token. So the workflow may look like this:
Does this look reasonable? I was actually intending to implement some sort of prototype, but just did not have much free time lately. Still I hope to be able to do something useful during the upcoming Christmas holidays. |
Support for hue is there in principle, but would need tweaking, Due to the very limited range supported by the driver I didn't manage to do that. The hardware actually has full support for arbitrary CSC matrices, but since it is not exposed some hack like this is the best I could think of. Patch also fixes vdp_generate_csc_matrix to write the data to the correct location, previously it would actually write outside the matrix. Signed-off-by: Reimar Döffinger <[email protected]>
It works for displaying a usable OSD in MPlayer at full screen resolution and even if using hardware decode, but is far too slow for fullscreen use for example. Signed-off-by: Reimar Döffinger <[email protected]>
It works for displaying a usable OSD in MPlayer at full screen
resolution and even if using hardware decode, but is far
too slow for fullscreen use for example.
Signed-off-by: Reimar Döffinger [email protected]