Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
W
weston
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 274
    • Issues 274
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 121
    • Merge Requests 121
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • wayland
  • weston
  • Issues
  • #20

Closed
Open
Opened Dec 06, 2016 by Bugzilla Migration User@bugzilla-migration

DRM: drm_fb reuse messy with opaque transitions

Submitted by Daniel Stone @daniels

Assigned to Daniel Stone @daniels

Link to original bug (#7634)

Description

Currently in compositor-drm, we have something like the below pseudocode:

struct drm_fb *drm_fb_get_from_bo(struct gbm_bo *bo, uint32_t format)  
{  
        struct drm_fb *fb = gbm_bo_get_user_data(bo);  
        if (fb)  
                return fb;  

        drmModeAddFB2(..., format, &fb->fb_id);  
}  

drm_output_prepare_{scanout,overlay}_view()  
{  
        uint32_t format;  
        struct drm_fb *fb;  

        format = gbm_bo_get_format(bo);  
        if (surface_is_opaque())  
                format = get_opaque_format(format);  
        fb = drm_fb_get_from_bo(bo);  
}  

This assumes that the lifetime of a gbm_bo is usefully tied to the lifetime of the surface_is_opaque() determination of a surface, where we check to see if the opaque area covers the whole area of the view.

This already breaks today in contrived multi-view situations, and could also break if the gbm_bo ends up living longer than a single repaint cycle in future.

I don't have a great idea of how to fix this right now, apart from maybe creating multiple FBs on demand.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: wayland/weston#20