Re: Screen shooting and recording protocols (Re: Authorized clients)

On Fri, 10 Jan 2014 20:38:46 +0100 Maarten Baert wrote: > Is this multi-view functionality inherent to the way Wayland > works, or is it Weston-specific? Will other compositors easily be > able to implement this in the same way? Multi-view is a Weston feature AFAIK, but it does not depend on any

[PATCH] weston.ini.man: Fix some grammar

--- man/weston.ini.man | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/weston.ini.man b/man/weston.ini.man index 6be90bf..ce3f928 100644 --- a/man/weston.ini.man +++ b/man/weston.ini.man @@ -388,7 +388,7 @@ Contains settings for the weston terminal application (weston-term

Re: [PATCH weston 2/2] input: Unlink saved kbd focus listener when releasing seat

For both patches: Reviewed-by: Bryce Harrington On Fri, Jan 03, 2014 at 07:46:51PM +0100, Jonas Ådahl wrote: > Not doing this would leave a invalid list item in the view's destroy > signal listener list if destroying a seat that had previously lost > keyboard focus. > > Signed-off-by: Jonas Åda

Re: [PATCH 1/2] drm: prepend stamp space to output mode logging

LGTM on both patches. Reviewed-by: Bryce Harrington On Fri, Jan 10, 2014 at 10:15:17AM -0800, U. Artie Eoff wrote: > Use the STAMP_SPACE to make the output mode logging > a little nicer looking. > > Signed-off-by: U. Artie Eoff > --- > src/compositor-drm.c | 2 +- > 1 file changed, 1 insertio

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 10/01/14 19:47, Bill Spitzak wrote: > I think "recording a window" sounds a lot like another output (as in a > montior). Then all the existing multi-view stuff can be reused to > duplicate the window into this output, including controlling whether > child surfaces are shown. Is this multi-view f

Re: Authorized clients

Le 10/01/2014 19:39, Jasper St. Pierre a écrit : On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres > wrote: Le 10/01/2014 16:44, Maarten Baert a écrit : On 10/01/14 14:56, Martin Peres wrote: Please provide a detailed explanation for that a

Re: Authorized clients

Le 10/01/2014 19:37, Maarten Baert a écrit : On 10/01/14 18:13, Martin Peres wrote: And who would manage the sandboxes? Systemd won't be able to because it is user applications. I don't know how this will be done in the future, I can't predict that. I suppose there will be some kind of sandbox

Re: Screen shooting and recording protocols (Re: Authorized clients)

I'm pretty certain what is being requested is a rectangle of some output. The video recorder will record whatever pixels are inside that rectangle, even if the surface used to choose it is moved away from it or if other surfaces enter it. The compositor must be able to set a stride value on th

Re: Authorized clients

On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres wrote: > Le 10/01/2014 16:44, Maarten Baert a écrit : > > On 10/01/14 14:56, Martin Peres wrote: >> >>> Please provide a detailed explanation for that and tell me how likely it >>> is to ever end up upstream. >>> >> If by 'upstream' you mean the ker

Re: Authorized clients

On 10/01/14 18:13, Martin Peres wrote: > And who would manage the sandboxes? Systemd won't be able to because > it is user applications. I don't know how this will be done in the future, I can't predict that. I suppose there will be some kind of sandbox manager just like we have virtual machine man

[PATCH 2/2] udev-seat: break early when output is found and log the mapping

When an input device has a WL_OUTPUT udev property specified and that output is found, log it... also break from the loop immediately. Log a warning if the requested output is not found. Signed-off-by: U. Artie Eoff --- src/udev-seat.c | 38 +- 1 file changed

[PATCH 1/2] drm: prepend stamp space to output mode logging

Use the STAMP_SPACE to make the output mode logging a little nicer looking. Signed-off-by: U. Artie Eoff --- src/compositor-drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index 136d517..f7d7a8a 100644 --- a/src/compositor-drm

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 10/01/14 17:10, Pekka Paalanen wrote: > What you call capturing a window, is just capturing a sub-rect of the > screen for me. For me, capturing a window is a different thing, it > gets the original window contents. Okay, window capturing is probably not the right word to describe it. It's ess

Re: Screen shooting and recording protocols (Re: Authorized clients)

Am 2014-01-10 17:10, schrieb Pekka Paalanen: Well, if the user wants to capture it like that, maybe she rather takes a shot of the whole desktop? Maybe I'm just weird, but when I think about capturing a single window, I really think about the window contents, not how it is presented on screen. I

Re: Authorized clients

Le 10/01/2014 16:44, Maarten Baert a écrit : On 10/01/14 14:56, Martin Peres wrote: Please provide a detailed explanation for that and tell me how likely it is to ever end up upstream. If by 'upstream' you mean the kernel: I don't think anything new is needed, actually. Create a separate direct

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Fri, 10 Jan 2014 15:26:19 +0100 Maarten Baert wrote: > On 10/01/14 09:54, Pekka Paalanen wrote: > > I think it is realistic on good platforms, and also essential for > > performance. Needs to be tried out, of course. > X11 does capturing by simply copying the buffer to a SHM image. This > take

Re: [PATCH v4 3/3] compositor-drm: allow to be a wl_dmabuf server

On Fri, Jan 10, 2014 at 10:46 AM, Thomas Hellstrom wrote: > On 01/10/2014 04:23 PM, Rob Clark wrote: >> On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom >> wrote: >>> Conclusion: Avoid using dma-buf mmap() outside of drivers that know >>> exactly what they are >>> doing, and avoid it at all cost

Re: [PATCH v4 3/3] compositor-drm: allow to be a wl_dmabuf server

On 01/10/2014 04:23 PM, Rob Clark wrote: > On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom > wrote: >> Conclusion: Avoid using dma-buf mmap() outside of drivers that know >> exactly what they are >> doing, and avoid it at all cost. > > well, to be fair, if you are using a gpu on the client side

Re: Authorized clients

On 10/01/14 14:56, Martin Peres wrote: > Please provide a detailed explanation for that and tell me how likely > it is to ever end up upstream. If by 'upstream' you mean the kernel: I don't think anything new is needed, actually. Create a separate directory in /run/user/1000 for each application, u

Re: [PATCH v4 3/3] compositor-drm: allow to be a wl_dmabuf server

On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom wrote: > Conclusion: Avoid using dma-buf mmap() outside of drivers that know > exactly what they are > doing, and avoid it at all cost. well, to be fair, if you are using a gpu on the client side and pixman backend on the server side, you probably

Re: [PATCH v4 0/3] Add support of dmabuf in wayland/weston

On Fri, Jan 10, 2014 at 9:58 AM, Rob Clark wrote: > I suspect that this is somehow on the same level as wl_drm (which is > in mesa, not wayland). The difference here is that since you can > share buffers with various things (video codecs, cameras, etc), ie. > things beyond just the gpu, it makes

Re: [PATCH v4 0/3] Add support of dmabuf in wayland/weston

I suspect that this is somehow on the same level as wl_drm (which is in mesa, not wayland). The difference here is that since you can share buffers with various things (video codecs, cameras, etc), ie. things beyond just the gpu, it makes sense to put the protocol in some sort of common place rath

Re: Screen shooting and recording protocols (Re: Authorized clients)

On 10/01/14 09:54, Pekka Paalanen wrote: > I think it is realistic on good platforms, and also essential for > performance. Needs to be tried out, of course. X11 does capturing by simply copying the buffer to a SHM image. This takes about 2ms for a 1920x1080 frame. That's perfectly usable, consider

Re: Authorized clients

Le 10/01/2014 04:32, Jasper St. Pierre a écrit : On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres > wrote: On 09/01/2014 23:57, Maarten Baert wrote: On 09/01/14 21:54, Martin Peres wrote: The worse thing that can happen is an application runnin

Re: Authorized clients

Le 10/01/2014 03:27, Maarten Baert a écrit : On 10/01/14 01:05, Martin Peres wrote: Let me help: - The attacker has installed a Firefox plugin that sends him a copy of all forms that you fill out. - The attacker has messed with your PATH and has installed an infected Firefox binary in a folder

Re: Authorized clients

Le 10/01/2014 02:37, Sebastian Wick a écrit : Am 2014-01-10 01:05, schrieb Martin Peres: Hey, don't twist his question and my answer ;) The question was IF our protocol is wrong. Remember, we aren't addressing the security of desktop here. We are looking for a way to provide a service (screensho

[PATCH] Fix compilation with FreeRdp 1.1 and master v2

The API to use remoteFx encoding has changed between master and stable 1.1 branch. This patch should fix compilation for both. This new version adds checks for the freerdp/version.h file --- configure.ac | 5 + src/compositor-rdp.c | 12 2 files changed, 17 insertions(+)

Re: Screen shooting and recording protocols (Re: Authorized clients)

On Thu, 9 Jan 2014 22:38:47 +0100 Maarten Baert wrote: > But I agree that if the compositor is able to capture frames with zero > overhead, then the compositor should just capture every frame and let > the application decide. Is this realistic? I think it is realistic on good platforms, and also