Re: [Video] ILM support for waylandsink query
Hi Eugen, Yes, I have implemented using protocol and it is working. However I also want to try it with direct usage of ILM apis but no luck yet. I have done the same with glimagesink, eglvivsink video sink plugin and it is working. Thanks & Regards, Vikash On Tue, Mar 28, 2017 at 1:09 AM, Eugen Friedrich wrote: > Hi Vikash, > > i could not really find this out from the call stack but the problem > could be that the ilmClient api is not thread safe, and in upstream > direct after 1.11 release we decided to deprecated this, > so just remove the ilmClient calls and use wayland protocol directly > and you can continue to use the ilmCommon api this one is thread save. > > Hope this helps, > Eugen > > 2017-03-27 10:35 GMT+02:00 Vikas Patil : > > Hi All, > > > > Modifying the view port as follows solves the issue 1. However still not > > getting what could be the cause of segmentation fault with direct usage > of > > ILM apis. > > > > //wl_viewport_set_destination (window->video_viewport, res.w, res.h); > > wl_viewport_set_destination (window->video_viewport, 800, 480); > > > > Thanks & Regards, > > Vikash > > > > On Fri, Mar 24, 2017 at 3:28 PM, Vikas Patil > wrote: > >> > >> Dear All, > >> > >> I am trying to add support for wayland-ivi-extension 1.11.0 to > waylandsink > >> [1] (video sink plug-in from gstreamer1.0-plugins-bad package) for > Jacinto6 > >> SoC using following two methods. > >> > >> 1. Using ivi-application protocol similar to simple-egl.c (test from > >> weston) > >> - This works. > >> - Here is video size is 1280x720 and screen resolution is 800x480 then > >> only top left of video is visible. How should I fix this? > >> > >> > >> 2. Using ilmClient and ilmControl APIs directly. > >> - This do not work and gives segmentation fault with below call stack. I > >> have checked the calls and setup seems correct to me. > >> - I thought it might be wayland sink uses drm protocol to allocate > buffers > >> which will be attached to created surfaces and tried to disable > thatpath > >> and instead use SHM. > >> With this also the same behavior. > >> > >> Any inputs? Attached here the patch for wayland sink which implements > ilm > >> support. > >> > >> Any inputs after looking at the call stack? > >> > >> #0 0xb6812928 in wl_proxy_marshal_constructor (proxy=0x150410, > >> opcode=opcode@entry=1, interface=0xb6827714 ) > >> at ../wayland-1.11.0/src/wayland-client.c:729 > >> #1 0xb6851e98 in wl_display_get_registry (wl_display=) > at > >> /usr/include/wayland-client-protocol.h:957 > >> #2 init_client () at > >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi- > layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:207 > >> #3 get_client_instance () at > >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi- > layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:235 > >> #4 0xb6852128 in wayland_surfaceCreate (nativehandle=3051387744, > >> width=, height=, pixelFormat= out>, > >> pSurfaceId=0xb688fe04 ) > >> at > >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi- > layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:273 > >> #5 0xb687cb10 in create_ilm_surface (window=0xb5e05150, > display=0x150410) > >> at ../../../git/ext/wayland/wlwindow.c:252 > >> #6 gst_wl_window_new_internal (display=0x150410) at > >> ../../../git/ext/wayland/wlwindow.c:383 > >> #7 0xb687d3b4 in gst_wl_window_new_toplevel (display=, > >> info=info@entry=0x14fff0) at ../../../git/ext/wayland/wlwindow.c:395 > >> #8 0xb68787c0 in gst_wayland_sink_render (bsink=0x14fde8, > >> buffer=0xb5504b68) at ../../../git/ext/wayland/gstwaylandsink.c:658 > >> #9 0xb691b134 in gst_base_sink_do_preroll () from > >> /usr/lib/libgstbase-1.0.so.0 > >> Cannot access memory at address 0x0 > >> #10 0x0014fde8 in ?? () > >> Cannot access memory at address 0x0 > >> Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > >> > >> > >> [1] > >> https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/ > tree/ext/wayland?id=1.6.3 > >> > >> Thanks you all in advance. > >> > >> Thanks & Regards, > >> Vikash > > > > > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2 10/11] [RFC] Account for very large repaint window misses
Hi Daniel & Pekka, finally managed to go through the whole patch series, updated my own application to current Wayland/Weston and test it a bit. I like it! It would have gotten my Reviewed-by's if i had actually managed to review it in some more reasonable time before the merge ;). The only thing i would suggest is to make the time window for the output update coalescing somewhat more tight and mostly to prevent repaint deadlines from shifting. In weston_output_maybe_repaint() you have this... msec_to_repaint = timespec_sub_to_msec(&output->next_repaint, now); if (msec_to_repaint > 1) return ret; ...for skipping an output for coalescing. Given timespec_sub_to_msec floor()'s to full msecs, that means you'd accept a next_repaint almost 2 msecs (~1.99 msecs) into the future, so for the candidate output that would be like moving the repaint window deadline ~ 2 msecs closer to the start of a refresh cycle, cutting off more clients earlier from getting their surface updates out for the next vblank. After return from weston_output_repaint() you call ... weston_compositor_read_presentation_clock(...&now) ... again to update "now", so if weston_output_repaint() for the current output involves some serious compositing work, you shift the "now" point for the following outputs in the compositors output list further into the future, so depending on where an output is in the compositor->output_list you could get such delays to add up and essentially move the repaint window deadline for later outputs by more than 2 msecs closer. I think that's not so good for predictability if the position of an output in the output_list and the potentially varying composition workload on preceding outputs can shift the repaint deadlines for later outputs by a large amount and defer an actual coalesced update for all outputs which are caught in this further. So i'd probably drop that weston_compositor_read_presentation_clock(...&now) to prevent this kind of drift? And make the msec_to_repaint deadline more like >= 1 instead of > 1 to limit the time window to at most 1 msec? Ideally we'd probably have timers with better than 1 msec granularity to deal with high refresh rate displays. The underlying timerfd api for wl_event_source_timer_update() seems to support nsecs resolution. Gamer or Stereo panels with 144 Hz or 165 Hz refresh are now becoming more common. One of my users already uses a commercially available 240 Hz BenQ Zowie panel for reliable fullscreen high-speed animations under X11 with the FOSS graphics stack, so refresh durations of only ~4 msecs are now a thing and shifting repaint deadlines by 2 msecs or more would have significant impact at only 4 msecs refresh. I assume a very important intended use case for this output coalescing is to make sure that outputs which are tightly genlocked/synchronized in their video refresh cycles will really update/page-flip somewhat reliably together and do so efficiently, e.g., if this is implemented on top of some solid atomic flip kms-driver support? Stuff like stereoscopic 3D output to two separate genlocked outputs for the two eyes (3D cinema, medical/science applications, advanced VR/AR HMD's). Or even multi-display walls or VR CAVE environments with > 2 outputs? For such apps one would assume the outputs are tightly synchronized, so even a < 1 msec window for coalescing should be fine. If you think about single-display VR apps like 1 output driving a regular desktop GUI display, the other driving something like a cosumer VR HMD like the HTC Vive or Oculus Rift, we'd also would want to make sure the repaint behavior of the output driving the HMD is very predictable and stable, even in presence of some activity on the regular non-synchronized desktop screen, so apps can minimize motion-to-photon latency. Output coalescing which would too liberally coalesce outputs which are unrelated in their refresh cycles could hurt such applications quite a bit. Or create funny beat patterns when the outputs refresh cycles drift against each other (60 Hz vs. 75/90/144 Hz) and the compositor alternates between coalescing updates together and treating them separately in a way that could cause hard to understand or avoid frame drops? I've read that the latest Vulkan spec now includes a VK_GOOGLE_display_timing extension, intended for VR apps, which is pretty close to what was proposed for Waylands presentation_queue extension or VDPAU's frame scheduling for video playback. Comments more to the point of patch 10/11 below... On 03/13/2017 01:48 PM, Pekka Paalanen wrote: On Fri, 10 Mar 2017 14:52:58 + Daniel Stone wrote: Hi Pekka, On 10 March 2017 at 13:41, Pekka Paalanen wrote: On Wed, 1 Mar 2017 11:34:09 + Daniel Stone wrote: * the deadline given by repaint_msec? In that case we delay until * the deadline of the next frame, to give clients a more predictab
Re: [Video] ILM support for waylandsink query
Hi Vikash, i could not really find this out from the call stack but the problem could be that the ilmClient api is not thread safe, and in upstream direct after 1.11 release we decided to deprecated this, so just remove the ilmClient calls and use wayland protocol directly and you can continue to use the ilmCommon api this one is thread save. Hope this helps, Eugen 2017-03-27 10:35 GMT+02:00 Vikas Patil : > Hi All, > > Modifying the view port as follows solves the issue 1. However still not > getting what could be the cause of segmentation fault with direct usage of > ILM apis. > > //wl_viewport_set_destination (window->video_viewport, res.w, res.h); > wl_viewport_set_destination (window->video_viewport, 800, 480); > > Thanks & Regards, > Vikash > > On Fri, Mar 24, 2017 at 3:28 PM, Vikas Patil wrote: >> >> Dear All, >> >> I am trying to add support for wayland-ivi-extension 1.11.0 to waylandsink >> [1] (video sink plug-in from gstreamer1.0-plugins-bad package) for Jacinto6 >> SoC using following two methods. >> >> 1. Using ivi-application protocol similar to simple-egl.c (test from >> weston) >> - This works. >> - Here is video size is 1280x720 and screen resolution is 800x480 then >> only top left of video is visible. How should I fix this? >> >> >> 2. Using ilmClient and ilmControl APIs directly. >> - This do not work and gives segmentation fault with below call stack. I >> have checked the calls and setup seems correct to me. >> - I thought it might be wayland sink uses drm protocol to allocate buffers >> which will be attached to created surfaces and tried to disable thatpath >> and instead use SHM. >> With this also the same behavior. >> >> Any inputs? Attached here the patch for wayland sink which implements ilm >> support. >> >> Any inputs after looking at the call stack? >> >> #0 0xb6812928 in wl_proxy_marshal_constructor (proxy=0x150410, >> opcode=opcode@entry=1, interface=0xb6827714 ) >> at ../wayland-1.11.0/src/wayland-client.c:729 >> #1 0xb6851e98 in wl_display_get_registry (wl_display=) at >> /usr/include/wayland-client-protocol.h:957 >> #2 init_client () at >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:207 >> #3 get_client_instance () at >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:235 >> #4 0xb6852128 in wayland_surfaceCreate (nativehandle=3051387744, >> width=, height=, pixelFormat=, >> pSurfaceId=0xb688fe04 ) >> at >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:273 >> #5 0xb687cb10 in create_ilm_surface (window=0xb5e05150, display=0x150410) >> at ../../../git/ext/wayland/wlwindow.c:252 >> #6 gst_wl_window_new_internal (display=0x150410) at >> ../../../git/ext/wayland/wlwindow.c:383 >> #7 0xb687d3b4 in gst_wl_window_new_toplevel (display=, >> info=info@entry=0x14fff0) at ../../../git/ext/wayland/wlwindow.c:395 >> #8 0xb68787c0 in gst_wayland_sink_render (bsink=0x14fde8, >> buffer=0xb5504b68) at ../../../git/ext/wayland/gstwaylandsink.c:658 >> #9 0xb691b134 in gst_base_sink_do_preroll () from >> /usr/lib/libgstbase-1.0.so.0 >> Cannot access memory at address 0x0 >> #10 0x0014fde8 in ?? () >> Cannot access memory at address 0x0 >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> >> >> [1] >> https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/wayland?id=1.6.3 >> >> Thanks you all in advance. >> >> Thanks & Regards, >> Vikash > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Video] ILM support for waylandsink query
Le lundi 27 mars 2017 à 14:05 +0530, Vikas Patil a écrit : > 1. Using ivi-application protocol similar to simple-egl.c (test from > weston) > - This works. > - Here is video size is 1280x720 and screen resolution is 800x480 > then only top left of video is visible. How should I fix this? Embed waylandsink into your application using the GstVideoOverlay interface to constrain the video. This has nothing to do with the shell being used here. Feel free to improve gst-launch support here. regards, Nicolas signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Video] ILM support for waylandsink query
Hi All, Modifying the view port as follows solves the issue 1. However still not getting what could be the cause of segmentation fault with direct usage of ILM apis. //wl_viewport_set_destination (window->video_viewport, res.w, res.h); wl_viewport_set_destination (window->video_viewport, 800, 480); Thanks & Regards, Vikash On Fri, Mar 24, 2017 at 3:28 PM, Vikas Patil wrote: > Dear All, > > I am trying to add support for wayland-ivi-extension 1.11.0 to waylandsink > [1] (video sink plug-in from gstreamer1.0-plugins-bad package) for Jacinto6 > SoC using following two methods. > > 1. Using ivi-application protocol similar to simple-egl.c (test from > weston) > - This works. > - Here is video size is 1280x720 and screen resolution is 800x480 then > only top left of video is visible. How should I fix this? > > > 2. Using ilmClient and ilmControl APIs directly. > - This do not work and gives segmentation fault with below call stack. I > have checked the calls and setup seems correct to me. > - I thought it might be wayland sink uses drm protocol to allocate buffers > which will be attached to created surfaces and tried to disable thatpath > and instead use SHM. > With this also the same behavior. > > Any inputs? Attached here the patch for wayland sink which implements ilm > support. > > Any inputs after looking at the call stack? > > #0 0xb6812928 in wl_proxy_marshal_constructor (proxy=0x150410, > opcode=opcode@entry=1, interface=0xb6827714 ) > at ../wayland-1.11.0/src/wayland-client.c:729 > #1 0xb6851e98 in wl_display_get_registry (wl_display=) at > /usr/include/wayland-client-protocol.h:957 > #2 init_client () at /usr/src/debug/wayland-ivi- > extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/ > src/ilm_client_wayland_platform.c:207 > #3 get_client_instance () at /usr/src/debug/wayland-ivi- > extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/ > src/ilm_client_wayland_platform.c:235 > #4 0xb6852128 in wayland_surfaceCreate (nativehandle=3051387744, > width=, height=, pixelFormat=, > pSurfaceId=0xb688fe04 ) > at /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi- > layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:273 > #5 0xb687cb10 in create_ilm_surface (window=0xb5e05150, display=0x150410) > at ../../../git/ext/wayland/wlwindow.c:252 > #6 gst_wl_window_new_internal (display=0x150410) at > ../../../git/ext/wayland/wlwindow.c:383 > #7 0xb687d3b4 in gst_wl_window_new_toplevel (display=, > info=info@entry=0x14fff0) at ../../../git/ext/wayland/wlwindow.c:395 > #8 0xb68787c0 in gst_wayland_sink_render (bsink=0x14fde8, > buffer=0xb5504b68) at ../../../git/ext/wayland/gstwaylandsink.c:658 > #9 0xb691b134 in gst_base_sink_do_preroll () from > /usr/lib/libgstbase-1.0.so.0 > Cannot access memory at address 0x0 > #10 0x0014fde8 in ?? () > Cannot access memory at address 0x0 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > > [1] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/ > tree/ext/wayland?id=1.6.3 > > Thanks you all in advance. > > Thanks & Regards, > Vikash > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] Interface for injection of input events
On Wed, 2017-03-22 at 11:00 +0800, Jonas Ådahl wrote: > On Wed, Mar 22, 2017 at 12:23:46PM +1000, Peter Hutterer wrote: > > > > == Authentication/Identification == > > The goal is to filter clients based on some white/blacklist, so > > that e.g. > > xdotool can access this interface but others cannot. > > > > This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this > > reliably. > > It's trivial to do per user, but per-process is difficult. DBus > > filters > > are largely limited to per-users. It's possible to get the process > > ID of a > > sender but going beyond that is unreliable (kernel doesn't > > guarantee comm > > being accurate). > > > > Requiring applications to bind to a bus name merely restricts them > > to being > > a singleton, there is no guarantee the application that binds > > org.freedesktop.org.WoodoTool.auth.xdotool is actually xdotool. > > > > The option that comes closest so far is some pre-shared key between > > compositor and application. That would need to be worked into the > > API, but > > it also relies on all participants to keep the key encrypted in > > memory and > > the various configuration files. > > > > So it's not clear whether we can do anything beyond a basic on/off > > toggle on > > whether to allow events from fake input devices. Debatable if such > > a crude > > mechanism is useful. > > > > > > Either way, this is a problem that *must* be solved but not > > necessarily one > > that affects the API itself (beyond what is required to make it > > technically feasable, e.g. passing cookies around) > > This could be left up to flatpak et.al, couldn't it? Coming up with a > authentication mechanism that likely can be worked around without > proper > sandboxing doesn't sound relaible. CC:ing Alex regarding this. Flatpak does indeed handle this, but it would really only work if all the apps on your system are sandboxed. I.e, we can identify a flatpak due to how we set it up when starting it, which the app cannot change from inside the sandbox. However, any app not launched that way can pretend to be someone else. Essentially there are two tiers of app trust. Anything not flatpak (and snappy, etc) is considered trusted on the user bus, and can do "anything". So, in the golden future where all normal apps are sandboxed this could work, but for current distros there is no secure way to authenticate apps. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly guitar-strumming paramedic gone bad. She's a cosmopolitan paranoid safe cracker with only herself to blame. They fight crime! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
