On 2018-05-08 2:24 PM, Daniel Stone wrote: > Unless I'm missing something, taskbars need a separate protocol to > communicate the task list, tell the compositor to raise/activate the > surfaces for that task, etc. I guess lock screens would be handled by > the 'overlay' mode, though that makes me incredibly itchy for the > security implications of having a lock state the compositor is unaware > of.
Depends on the taskbar. We expect to be working with KDE in the future to draw up protocols for this as well, though. Also, we have a separate protocol coming down the line later for helping lock screens out: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-input-inhibitor-unstable-v1.xml Feel free to take an early look, but let's keep the discussion focused on layer-shell instead of picking this protocol apart too. > This discussion mentions (amongst quite a lot of other things, some > fairly unpleasant) that access to layer-shell _must_ be locked down to > trusted clients only, which everyone takes as a given. That really > seems like it's worth mentioning in the introduction, though it > contradicts the 'broad number of other applications' line. We have some nebulous plans for opening up "locked down" protocols to third parties in a secure way in the future. Again, taking the discussion in this direction could get out of scope for layer-shell pretty quick. Maybe we need to shelve this and discuss how to provide secure access to privledged protocols to third-parties first, but we're confident that the ideas we're thinking about will work (they're mostly building on top of what Weston already does to seucre its desktop shell). I agree that the discussion on earlier versions of the protocol brought up some unpleasant consequences of the early design decisions. However, we redesigned those parts until we got what we believe is a pretty solid protocol. > From a purely Weston point of view, I'm not at all sure how we'd go > about authenticating arbitrary (from the compositor's point of view, > i.e. not launched in a trusted way?) third-party clients, so don't > know how we'd go about implementing this in that compositor. Ideas > welcome, of course. Just to give a quick overview of what we have in mind, we start by opening the socket ourselves and noting that the wl_client has some set of permissions, then we fork from the compositor and use WAYLAND_SOCKET instead of WAYLAND_DISPLAY for the client connection. Weston does something like this at compositor/main.c:weston_client_launch. On top of this we want to build some simple protocols subprocesses can use to grant a subset of their permissions to their own children. This would probably be as simple as a list of interface names they're allowed to bind to. The compositor could combine this knowledge with global filtering to clean up the loose ends. These ideas are still somewhat nebulous but I'm confident enough that it'll work that I think we can proceed with the discussion on protocols like layer-shell. Compositors which are interested in implementing these protocols and securing them today can do something simple like weston_client_launch as a temporary solution and make it more accessible to third parties later. > This was an interesting read. From a high level though, there's a fair > bit of overlap with the IVI shell, which also exposes the same concept > of stacked layers (and surface attachment to layers), out to clients. > Historically ivi-shell has also included its own wl_shell/xdg_shell > alternative for apps, but Michael Tayfel's recent patchset (which I > think is a good thing) deprecates that by letting the IVI shell expose > xdg-shell to clients. > > Maybe there could be a good future in merging this with a rationalised > IVI shell? I think it might be possible to replace IVI shell with layer shell (or replace a subset of IVI shell with layer shell), but I'm not sure that the other way around is a great plan. I also find it highly questionable to repurpose xdg-shell in places like IVI (e.g. in a non-desktop setting); I think it's far better to define new shells. For some context, in wlroots we're already accustomed to the idea of several distinct shells. We used to have a Grand Unified Shell Abstraction when we were based on wlc, but learned our lesson and moved to a new approach. Today, we have a "view" abstraction, but it's rather thin and not all shell surfaces are views. For example, Xwayland unmanaged surfaces are supported, but do not participate in the view abstraction. Layer surfaces also do not participate in the view abstraction. And even for those who do use the view abstraction, it's a very thin abstraction, and consumers of views are exposed to shell-specific concerns. This is more work, but allows us to have _much_ better support for each shell. In short, we think that embracing the differences between shells is a better design than attempting to fit a square peg in a variety of holes. -- Drew DeVault _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
