Originally posted by dee.
View Post
Announcement
Collapse
No announcement yet.
RealVNC Remote Desktop Wants To Support Wayland
Collapse
X
-
-
Originally posted by Ancurio View PostProblem is you'd end up implementing the same relatively complicated software for each and every compositor, and they'd all suck infinitely more than say XSplit or OBS. That kind of defeats the point of having standardized interfaces like the input method one, no?
Comment
-
Originally posted by Ancurio View PostProblem is you'd end up implementing the same relatively complicated software for each and every compositor, and they'd all suck infinitely more than say XSplit or OBS. That kind of defeats the point of having standardized interfaces like the input method one, no?
Comment
-
Originally posted by erendorn View PostWell, that's what libraries are for. Making some given software capabilities available in multiple projects.
Originally posted by dee. View PostBut there could be a standardized interface for it, defined in the Wayland protocol. The compositor would just implement it - that's what they do anyway, they implement the Wayland protocol.
Edit: Actually nvm, that's not what I was saying. You're misunderstanding something; weston implements the wayland protocol/interfaces, because clients need to talk to it via them. If there is functionality for eg. a screen recorder that's built into the compositor, as is the case with wcap, there is no interface because there is no client to talk to, since the code paths lie directly in the compositor. You'll find that there is no "screen capture" interface in wayland. An interface is needed when an outside client (such as is the case with IM support, see text input protocol extension) provides the service and needs a standard way to talk to a compositor for resources / locked down functions.Last edited by Ancurio; 03 August 2013, 02:15 AM.
Comment
-
Originally posted by Ancurio View PostYou'll find that there is no "screen capture" interface in wayland.
The way I see it, having clients request the composited buffer directly from the compositor would be the simplest solution. The compositor being the only part of the stack that knows what it is.Last edited by dee.; 03 August 2013, 02:50 AM.
Comment
-
Originally posted by ua=42 View PostI wonder if it would be more efficient to have access to all the client framebuffers as opposed to the main one. Then you could set up events to be sent when each client is updated as opposed to every time the main buffer is updated. Also would mean just sending the image of the client that updated, not the entire screen.
Originally posted by Ancurio View PostRepainting in weston is already optimized in such a way that only damaged regions of the framebuffer are repainted. So you get that for free.
Originally posted by bulletxt View PostWhat about Mir? Are current changes/new_features in Wayland getting into Mir and viceversa? If not in less than two years we will have two completley different softwares.
Anything done in Mir can't (because of GPLv3) be directly integrated into Wayland. Also, if I understand correctly what the GPLv3 means, some algorithms might be patented and only usable if taking the code from the GPLv3 implementation, which means it can't even be reimplemented locally on Wayland, because it uses a different license. Features on Wayland going into Mir, well, they can copy whatever they want, the license allows them. I ignore if it's technically feasible, and it probably would take some work to port anyway. But if it's this way, then I hope Mir fans don't complain when someone points out Canonical is leeching from a project they did spread pretty harsh comments about.
Comment
-
Originally posted by Ancurio View PostOf course, but then it doesn't make sense anymore to provide this functionality in-compositor.
Comment
-
Originally posted by Ancurio View PostOh, okay. You want to write a library, and then 20 different kinds of glue code for each and every compositor out there, instead of simply implementing a common interface in one binary. Makes sense.
"One size will fit all" is not the best programming paradigm ever. Actually, it's specifically because X suffered from this problem that we are changing to wayland. Wayland enforces as little as possible.
Some libs are provided, though, and you can write extensions to the protocol. Extensions that any compositor may, or may not support. Or may support with some other lib.
Comment
Comment