Page 2 of 2 FirstFirst 12
Results 11 to 12 of 12

Thread: "Atomic Display Framework" Shown For Linux

  1. #11
    Join Date
    Jan 2009
    Posts
    1,448

    Default

    Quote Originally Posted by robclark View Post
    Hi Ericg, what android (and weston) are missing is the ability to atomically update the primary scanout layer on the same vsync as the overlay layers. It isn't really related to what keithp is doing w/ dri3/present. There are a couple other (mostly minor) things, but it all can and will be added to KMS (and there are already proposals about how to do the atomic pageflip/modeset parts of it). So, can KMS *today* handle android's (and weston's) needs.. no. But what is missing can be added.
    Hi Rob,
    If I understand you, currently, HWComposer isn't meeting android's needs, but the proposed ADF can currently do this. The problem with it, as you've said, is that you are adding a separate "non-standard" driver target, and that the only problem it solves (atomic updates) can be added to kms/drm.
    So, the current situation is that everyone wants to move to atomic partial page updates, but that no one is currently shipping a solution, but there are the above paths forward?

    Thanks/Liam

  2. #12
    Join Date
    Sep 2011
    Posts
    288

    Default

    Quote Originally Posted by liam View Post
    Hi Rob,
    If I understand you, currently, HWComposer isn't meeting android's needs, but the proposed ADF can currently do this. The problem with it, as you've said, is that you are adding a separate "non-standard" driver target, and that the only problem it solves (atomic updates) can be added to kms/drm.
    So, the current situation is that everyone wants to move to atomic partial page updates, but that no one is currently shipping a solution, but there are the above paths forward?

    Thanks/Liam
    well, you can say that KMS isn't currently meeting HWComposer's needs for composition bypass. Not really anything to do w/ partial page updates (whatever that is). But if you are using hw overlays for some surfaces, you need to be able to keep that in sync w/ the gpu rendered layers so all the updates happen in sync. (And, as I've mentioned before, this is nothing specific to android, weston or any other wayland compositor using hw bypass (overlays) needs the same thing.) KMS doesn't currently give a solution for this, although there are proposals about how to do it it. (Ie. atomic/nuclear modeset/pageflip.) Part of the reason that KMS atomic support hasn't moved forward in the last ~6mo or so is that since I left TI (and no longer had access to sgx driver code), I haven't had a driver with which to implement atomic prototype. Now that I have msm drm/kms driver, I'm closer to being able to work on atomic again.. I still need to implement kms plane (overlay) support in msm, and a few other bits and pieces, but hopefully I should be returning to atomic support in kms in the near(ish) future.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •