Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
wayland
wayland
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 96
    • Issues 96
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 25
    • Merge Requests 25
  • 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
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • waylandwayland
  • Issues
  • #93

Closed
Open
Opened Apr 29, 2019 by Scott Anderson@ascentReporter

Contradiction in wl_surface description

From the description of wl_surface:

Destroying the role object does not remove the role from the wl_surface, but it may stop the wl_surface from "playing the role". For instance, if a wl_subsurface object is destroyed, the wl_surface it was created for will be unmapped and forget its position and z-order. It is allowed to create a wl_subsurface for the same wl_surface again, but it is not allowed to use the wl_surface as a cursor (cursor is a different role than sub-surface, and role switching is not allowed).

However, comparing that to the description of wl_subsurface.destroy:

The sub-surface interface is removed from the wl_surface object that was turned into a sub-surface with a wl_subcompositor.get_subsurface request. The wl_surface's association to the parent is deleted, and the wl_surface loses its role as a sub-surface. The wl_surface is unmapped immediately.

So wl_surface says the role is kept (specifically giving wl_subsurface as an example), while wl_subsurface says it is not. wl_surface is also describing behaviour of forgetting the parent's position and z-order, which is not described anywhere in the wl_subsurface description.

I would personally side with the behaviour wl_surface describes, as I cannot think of a reason why wl_subsurface would need to override the normal wl_surface role behaviour, and leads to a more consistent implementation for compositors.
It also matches that behaviour that weston and wlroots have actually implemented:

[3332352.321]  -> wl_compositor@4.create_surface(new id wl_surface@3)
[3332352.333]  -> wl_compositor@4.create_surface(new id wl_surface@7)
[3332352.344]  -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@8, wl_surface@7, wl_surface@3)
[3332352.371]  -> wl_subsurface@8.destroy()
[3332352.377]  -> xdg_wm_base@6.get_xdg_surface(new id xdg_surface@9, wl_surface@7)
[3332352.396]  -> xdg_surface@9.get_toplevel(new id xdg_toplevel@10)
[3332352.509] wl_display@1.delete_id(8)
[3332352.531] wl_display@1.error(xdg_surface@9, 0, "Cannot assign role xdg_toplevel to wl_surface@7, already has role wl_subsurface

I have not tested any other compositors.

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/wayland#93