Weston headless backend - xvfb-run emulation
Hi, I'm working on Firefox/Wayland port on Fedora and there's a need to run Wayland Firefox in headless Wayland session - it's used in build process to perform PGO build, it's used for test runs and so. It's generally what xvfb-run provides - a headless X11 server which launches a single command and quit when the command finishes. Is that possible with Weston and any of its backend? I haven't found any reference how to launch firefox inside weston-headles backend automatically so far. Thanks, ma. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston headless backend - xvfb-run emulation
On 12/22/18 10:36 AM, Pekka Paalanen wrote: On Fri, 21 Dec 2018 13:00:12 +0100 Martin Stransky wrote: Hi, I'm working on Firefox/Wayland port on Fedora and there's a need to run Wayland Firefox in headless Wayland session - it's used in build process to perform PGO build, it's used for test runs and so. It's generally what xvfb-run provides - a headless X11 server which launches a single command and quit when the command finishes. Is that possible with Weston and any of its backend? I haven't found any reference how to launch firefox inside weston-headles backend automatically so far. Hi, Weston doesn't have any kind of autolaunch feature, but there are interested people at least for the desktop use case. Weston's own test suite uses a custom plugin to launch test clients, but it's not installed. That might be a better approach for a test suite than a generic desktop app autolaunch, since you can make the compositor quit and forward the test app exit code. That plugin is at tests/weston-test.c, and it implements also a test protocol, but the most relevant part for you is idle_launch_client(). test_client_sigchld() handles quitting Weston. We could think of some kind of arrangement to allow using Weston/headless to run automated tests in other projects out-of-the-box. Maybe the idle_launch_client() functionality could be integrated in the headless backend directly... but then we need more changes in Weston's test suite to allow running the tests with different backends. Maybe that would be a slightly longer term plan. Are you only looking for headless launching of apps, or would you be interested in more features like screenshooting or fake input events to drive and check tests? Hello, Mozilla uses xvfb as a frame buffer X server and launches x11vnc inside it. The Firefox itself is controlled by Marionette [1] so there's no need for fake input events (AFAIK). Also the screen capture is not necessary for now. A good start would be to launch Firefox inside wayland headless session and I can work from this point further to investigate what's needed. If the plugin provides such functionality that will be fine for now. Thanks, ma. [1] https://firefox-source-docs.mozilla.org/testing/marionette/marionette/index.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: DMABuf/Wayland buffer sharing
finished implementing the zero copy case yet. In all cases, the GPU is rendering the image, and the DisplayLink device (DL) is display-only and needs CPU access to the buffer as it is a virtual DRM driver. - zero copy by either allocating on the GPU and importing to DL, or allocating on DL and importing to GPU; - GPU copy from a temporary GPU buffer into a DL buffer imported to GPU; - CPU copy (glReadPixels) from a temporary GPU buffer into a mmapped DL buffer. The trouble is that each "import" may fail for whatever reason, and I must have a fallback. My case is the opposite of your case: I have GPU writing and CPU reading, you have CPU writing and GPU reading. Also I wonder if it's feasible to use any modifiers as I need plain/linear buffer to draw into by skia. I suspect when I create the buffer with modifiers and then I map it to CPU memory for SW drawing, intermediate buffer is created and then the pixels are de-composed back to GPU memory. No, I don't believe there is any kind of intermediate buffer behind the scenes in GBM or dmabuf ioctls/mmap. OpenGL drivers may use intermediate buffers. Some EGLImage operations are allowed to create more buffers behind the scenes but I think implementations try to avoid it. Copies are bad for performance, and implicit copies are unexpected performance bottle-necks. So yes, I believe you very much need to ensure the buffer gets allocated as linear from the start. Some hardware may have hardware tiling units, that may be able to represent a linear CPU view into a tiled buffer, but I know very little of that. I think they might need driver-specific ioctls to use or something, and are a scarce resource. Thanks, ma. Thanks, pq -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
dmabuf modifiers for HW overlays
On 8/2/19 12:04 PM, Martin Stransky wrote: Also I wonder if it's feasible to use any modifiers as I need plain/linear buffer to draw into by skia. I suspect when I create the buffer with modifiers and then I map it to CPU memory for SW drawing, intermediate buffer is created and then the pixels are de-composed back to GPU memory. No, I don't believe there is any kind of intermediate buffer behind the scenes in GBM or dmabuf ioctls/mmap. OpenGL drivers may use intermediate buffers. Some EGLImage operations are allowed to create more buffers behind the scenes but I think implementations try to avoid it. Copies are bad for performance, and implicit copies are unexpected performance bottle-necks. So yes, I believe you very much need to ensure the buffer gets allocated as linear from the start. Some hardware may have hardware tiling units, that may be able to represent a linear CPU view into a tiled buffer, but I know very little of that. I think they might need driver-specific ioctls to use or something, and are a scarce resource. The HW overlays is another use-case I'm working on. I want to draw 2D data to dmabuf buffer by CPU and send it directly to GPU to render from (bind as wl_buffer and attach it to wl_subsurface). I guess it also depends on compositor how to handles that and how does that handle mutter?. Does mutter such dmabuf buffer pass directly to GPU? Also is it feasible to use *any* modifiers here and which flags should I pass to gbm_bo_create()? I want to use plain DRM_FORMAT_ARGB for the dmabuf buffer as it's easy to draw into but I wonder if that buffer can be used by GPU directly for compositing and how effective is that. Thanks, ma. -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: dmabuf modifiers for HW overlays
On 8/2/19 1:48 PM, Scott Anderson wrote: On 2/08/19 10:19 pm, Martin Stransky wrote: On 8/2/19 12:04 PM, Martin Stransky wrote: Also I wonder if it's feasible to use any modifiers as I need plain/linear buffer to draw into by skia. I suspect when I create the buffer with modifiers and then I map it to CPU memory for SW drawing, intermediate buffer is created and then the pixels are de-composed back to GPU memory. No, I don't believe there is any kind of intermediate buffer behind the scenes in GBM or dmabuf ioctls/mmap. OpenGL drivers may use intermediate buffers. Some EGLImage operations are allowed to create more buffers behind the scenes but I think implementations try to avoid it. Copies are bad for performance, and implicit copies are unexpected performance bottle-necks. So yes, I believe you very much need to ensure the buffer gets allocated as linear from the start. Some hardware may have hardware tiling units, that may be able to represent a linear CPU view into a tiled buffer, but I know very little of that. I think they might need driver-specific ioctls to use or something, and are a scarce resource. The HW overlays is another use-case I'm working on. I want to draw 2D data to dmabuf buffer by CPU and send it directly to GPU to render from (bind as wl_buffer and attach it to wl_subsurface). I guess it also depends on compositor how to handles that and how does that handle mutter?. Does mutter such dmabuf buffer pass directly to GPU? > Also is it feasible to use *any* modifiers here and which flags should I pass to gbm_bo_create()? I want to use plain DRM_FORMAT_ARGB for the dmabuf buffer as it's easy to draw into but I wonder if that buffer can be used by GPU directly for compositing and how effective is tha > Thanks, ma As the client, you don't need to try do the compositor's/driver's job for it. If you want CPU accessable buffers, just use wl_shm. Trying to push CPU data into a dmabuf directly can potentially hurt more than it helps. You should benchmark if that actually leads to increased performance, especially across different hardware/drivers. Yes, I suppose that will be optional. Regarding overlays, a pending change to wp_linux_dmabuf [1] would give the client more information about how to allocate its GPU buffers so that's it's more likely to work with hardware overlays or be more efficient in general, but it's a complicated thing to get correct, and it'll never be perfect. Great, thanks! I'm also puzzled as to why you would need to use GBM directly. Some clients have a justified use for it, but most don't, and is mainly useful for display servers instead. Are the EGL/OpenGL APIs not sufficient? Recently video playback at Firefox drains your laptop battery reliably under Linux and improvement would be great. Also fullscreen video playback can benefit from it. ma. > Scott [1]: https://lists.freedesktop.org/archives/wayland-devel/2018-November/039660.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Is textureSize(samplerExternalOES, int) missing in desktop mesa 19.1.7 implementation?
Hi guys, while implementing WebRender Wayland backend in Firefox [1] I hit a strange bug. Although GL_OES_EGL_image_external_essl3 extension is supported on my system (Fedora 30 / Intel Skylake GT2 / OpenGL ES 3.2 Mesa 19.1.7) I'm getting this error from a sample fragment shader: Error: compiling fragment: 0:7(2): error: no matching function for call to `textureSize(samplerExternalOES, int)'; candidates are: ... ... I checked that GL_OES_EGL_image_external_essl3 is explicitly enabled in my shader, I even installed my own mesa debug build and stepped by gdb into shader compilation routines but it looks like that textureSize() implementation for samplerExternalOES is just missing, although its' explicitly mentioned by GL_OES_EGL_image_external_essl3 spec. Can anyone confirm that or am I just doing something wrong? Thanks, ma. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1583731 -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wl_subsurace position - double buffered state?
Hi Guys, while solving a FF bug [1] I'm unable to figure out why a subsurface has wrong offset. There's the related part of wayland-debug log: [1622539.791] -> wl_compositor@53.create_surface(new id wl_surface@61) [1622539.821] -> wl_subcompositor@57.get_subsurface(new id wl_subsurface@62, wl_surface@61, wl_surface@42) gdk_window_get_position 26 23 [1622539.857] -> wl_subsurface@62.set_position(26, 23) [1622539.868] -> wl_subsurface@62.set_desync() [1622539.874] -> wl_compositor@53.create_region(new id wl_region@63) [1622539.882] -> wl_surface@61.set_input_region(wl_region@63) [1622539.889] -> wl_region@63.destroy() [1622539.904] -> wl_surface@61.set_buffer_scale(2) [1622539.912] -> wl_surface@61.commit() but I still see the sub surface on old initial position (0,0). It's moved to correct position imediately when I try to resize the window. (full log is attached). Sometimes it happens that the surface is on correct position right after start - but I don't see any difference in the log. It's on Fedora 30 / mutter-3.32.2-4.fc30.x86_64. Any idea what can be wrong? Thanks, Martin [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1592350 -- Martin Stransky Software Engineer / Red Hat, Inc [1621949.941] -> wl_display@1.get_registry(new id wl_registry@2) [1621950.003] -> wl_disp...@1.sync(new id wl_callback@3) [1621950.163] wl_display@1.delete_id(3) [1621950.182] wl_registry@2.global(1, "wl_drm", 2) [1621950.206] wl_registry@2.global(2, "wl_compositor", 4) [1621950.226] -> wl_regis...@2.bind(2, "wl_compositor", 3, new id [unknown]@4) [1621950.261] wl_registry@2.global(3, "wl_shm", 1) [1621950.279] -> wl_regis...@2.bind(3, "wl_shm", 1, new id [unknown]@5) [1621950.403] -> wl_shm@5.create_pool(new id wl_shm_pool@6, fd 12, 2304) [1621950.638] -> wl_shm_pool@6.resize(6912) [1621950.793] -> wl_shm_pool@6.resize(16128) [1621951.043] -> wl_shm_pool@6.resize(34560) [1621951.524] -> wl_shm_pool@6.resize(71424) [1621954.076] -> wl_shm_pool@6.resize(145152) [1621954.198] -> wl_shm_pool@6.resize(292608) [1621955.727] -> wl_shm_pool@6.resize(587520) [1621959.196] -> wl_shm_pool@6.resize(1177344) [1621975.710] wl_registry@2.global(4, "wl_output", 2) [1621975.733] -> wl_regis...@2.bind(4, "wl_output", 2, new id [unknown]@7) [1621975.796] -> wl_disp...@1.sync(new id wl_callback@8) [1621975.806] wl_registry@2.global(6, "zxdg_output_manager_v1", 1) [1621975.817] -> wl_regis...@2.bind(6, "zxdg_output_manager_v1", 1, new id [unknown]@9) [1621975.831] -> zxdg_output_manager_v1@9.get_xdg_output(new id zxdg_output_v1@10, wl_output@7) [1621975.840] -> wl_disp...@1.sync(new id wl_callback@11) [1621975.847] wl_registry@2.global(7, "wl_data_device_manager", 3) [1621975.859] -> wl_regis...@2.bind(7, "wl_data_device_manager", 3, new id [unknown]@12) [1621975.872] wl_registry@2.global(8, "gtk_primary_selection_device_manager", 1) [1621975.882] -> wl_regis...@2.bind(8, "gtk_primary_selection_device_manager", 1, new id [unknown]@13) [1621975.896] wl_registry@2.global(9, "wl_subcompositor", 1) [1621975.906] -> wl_regis...@2.bind(9, "wl_subcompositor", 1, new id [unknown]@14) [1621975.920] wl_registry@2.global(10, "xdg_wm_base", 2) [1621975.930] wl_registry@2.global(11, "zxdg_shell_v6", 1) [1621975.939] wl_registry@2.global(12, "wl_shell", 1) [1621975.949] wl_registry@2.global(13, "gtk_shell1", 3) [1621975.959] -> wl_regis...@2.bind(13, "gtk_shell1", 3, new id [unknown]@15) [1621975.972] wl_registry@2.global(14, "wp_viewporter", 1) [1621975.982] wl_registry@2.global(15, "zwp_pointer_gestures_v1", 1) [1621975.991] -> wl_regis...@2.bind(15, "zwp_pointer_gestures_v1", 1, new id [unknown]@16) [1621976.005] wl_registry@2.global(16, "zwp_tablet_manager_v2", 1) [1621976.014] -> wl_regis...@2.bind(16, "zwp_tablet_manager_v2", 1, new id [unknown]@17) [1621976.028] wl_registry@2.global(17, "wl_seat", 5) [1621976.038] -> wl_regis...@2.bind(17, "wl_seat", 5, new id [unknown]@18) [1621978.926] -> wl_compositor@4.create_surface(new id wl_surface@19) [1621978.947] -> gtk_primary_selection_device_manager@13.get_device(new id gtk_primary_selection_device@20, wl_seat@18) [1621978.957] -> wl_data_device_manager@12.get_data_device(new id wl_data_device@21, wl_seat@18) [1621979.063] -> wl_compositor@4.create_surface(new id wl_surface@22) [1621979.072] -> zwp_tablet_manager_v2@17.get_tablet_seat(new id zwp_tablet_seat_v2@23, wl_seat@18) [1621979.082] -> wl_disp...@1.sync(new id wl_callback@24) [1621979.090] wl_registry@2.global(18, "zwp_relative_pointer_manager_v1", 1) [1
Re: wl_subsurace position - double buffered state?
On 10/30/19 8:58 AM, Jonas Ådahl wrote: [...] Quoting the specification of the set_position request: The scheduled coordinates will take effect whenever the state of the parent surface is applied. When this happens depends on whether the parent surface is in synchronized mode or not. See wl_subsurface.set_sync and wl_subsurface.set_desync for details. In short, you need to commit the parent surface for the new position to take effect. The reason for this is that the position of the surface is more of a state of the parent surface rather than the subsurface itself, and it is likely that if you move the subsurface, something on the parent surface needs to be updated at the same time in order to avoid intermediate incorrectly rendered frames. Thanks a lot, it works as expected now. Martin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Do I need wl_frame_callback at all?
Hi guys, what happens and is it a correct behavior when application does not use wl_frame_callback at all and just do the drawing (wl_surface_commit) whatever it has a data do draw? I know it may be sub-optimal to draw more frequently but I'd need to cache the visual data elsewhere otherwise so it easier for me to just put it at compositor instead to store it offscreen and then copy it to wl_buffer when wl_frame_callback comes. Thanks, ma. -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Do I need wl_frame_callback at all?
On 11/20/19 12:12 PM, Scott Anderson wrote: On 21/11/19 12:03 am, Martin Stransky wrote: Hi guys, what happens and is it a correct behavior when application does not use wl_frame_callback at all and just do the drawing (wl_surface_commit) whatever it has a data do draw? I know it may be sub-optimal to draw more frequently but I'd need to cache the visual data elsewhere otherwise so it easier for me to just put it at compositor instead to store it offscreen and then copy it to wl_buffer when wl_frame_callback comes. Thanks, ma. Hi It's perfectly legal in the protocol to commit whenever you want to. The frame event is just a suggestion. Nothing is stopping anyone from rendering and committing at 1000 frames per second, other than people asking you to stop being so wasteful. Wayland uses the "mailbox" model (this is Vulkan terminology), so the compositor will just use whatever the current commit is at the time it does its composition. So do you mean in this scenario: -- composition commit A commit B commit C -- composition only 'commit C' is painted and A/B are lost? Martin Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wl_surface/wl_subsurface composition
Hi guys, while solving a Firefox Wayland bug [1] I wonder if there's any composition between a surface and a subsurface on compositor side (namely mutter) when the subsurface area is subset of the surface and the surface is set as opaque. Both surface and subsurface are using ARGB pixel format. Thanks, Martin [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1591489#c9 -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Drag & Drop - multiple wl_data_device/wl_seat interfaces
On 4/29/21 4:20 AM, Sichem Zhou wrote: Hi Martin, There was an attempt MR [1] try to fix the firefox copy/paste issue last year. You sure the clipboard is working correctly under weston? I just checked you still can't paste anything to firefox. I'm not sure about Weston but works in KWin, Mutter, Sway. Firefox register its own wl_data_device and listens there. It uses the same seat (seat0) as Gtk. Martin [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/426 Le mar. 20 avr. 2021 20 h 52, Martin Stransky a écrit : Hello folks, I'm solving an issue with multiple wl_data_device/wl_seat interfaces. Firefox uses two wl_data_devices, one owned by Gtk and one owned by Firefox. When cliboard operations are used (copy/paste) it works as expected. But with Drag & Drop sometimes only one device gets the D&D events so D&D does not work reliably. Wayland log is attached. I wonder if that can be related to active wl_keyboard/wl_seat or is that a compositor bug? (I'm using mutter-3.38.4-1.fc33). Thanks, Martin -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Martin Stransky Software Engineer / Red Hat, Inc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Difficulties with Wayland D&D protocol - D&D source persistence
Hi folks, I'd like to point out how Wayland D&D protocol limits real life applications. Main limitation is a requirement that D&D source window has to be kept opened and D&D is cancelled otherwise. That's especially painful with popups. See this Mozilla bug and video attached there [1]. What's the problem? - When a popup window is source of D&D (a bookmark entry on the example here), we can't close it. - It's difficult to do D&D to another popup as the source one has to me kept opened. That means we need to show popups which are not intended to be shown together: - if the popups are adjacent, xdg-positoner can be used. - if the popups are not adjacent (an example on the clip), wl_subsurface popup has to be used with its consequences (buggy compositor/gtk3 implementation). So may be the D&D source persistence condition relaxed? Thanks, Martin [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1797046 -- Martin Stransky Software Engineer / Red Hat, Inc
Re: Difficulties with Wayland D&D protocol - D&D source persistence
On 10/24/22 12:29, Carlos Garnacho wrote: - It's difficult to do D&D to another popup as the source one has to me kept opened. That means we need to show popups which are not intended to be shown together: - if the popups are adjacent, xdg-positoner can be used. - if the popups are not adjacent (an example on the clip), wl_subsurface popup has to be used with its consequences (buggy compositor/gtk3 implementation). So may be the D&D source persistence condition relaxed? To allow a fix for this case, I think it would be more backwards compatible and coherent to relax wl_data_device.start_drag conditions, so that it's only required that the serial/grab is on a surface of the same client, and a different source surface may be used. Firefox could then pass the toplevel surface as the drag source. This way lifetime correctness is guaranteed, and "snap back" animations on failed DnD have a surface to return to. Yes, relaxing wl_data_device.start_drag conditions would be enough here. Thanks. -- Martin Stransky Software Engineer / Red Hat, Inc
Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients
On 11/29/23 10:10, Olivier Fourdan wrote: [...] So my question is, if there is any interest for such a project [4], should this be moved to the wayland namespace in gitlab (we could even change the name of the project), should that be added to the existing "wayland-utility" project that we have already, or if there's no interest it's fine to stay in my own gitlab namespace for now? Definitely needed for Firefox/Wayland testing. Thanks for providing that! [1] Red Hat Enterprise Linux 10 plans for Wayland and Xorg server <https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server?channel=/en/blog/channel/red-hat-enterprise-linux> [2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197 [3] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1595 [4] https://gitlab.freedesktop.org/ofourdan/xwayland-run -- Martin Stransky Software Engineer / Red Hat, Inc
Re: Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients
On 11/29/23 10:35, Olivier Fourdan wrote: Hi Simon, On Wed, 29 Nov 2023 at 10:16, Simon Ser wrote: I'd prefer this to be kept in your personal namespace: I'd prefer not to make this an official Wayland project. Well, that was quick! :) If I may, would it be possible to elaborate on the rationale behind your opinion, is that because there is no interest at all, because of the quality of the code, because of Python, or because it's partly about Xwayland and X11? I understand it may not be suitable as a project of its own within the Wayland space, but couldn't we consider adding these to the (existing) wayland-utils instead? +1 There should be a standardized and widely used tool to test Wayland based applications every Wayland based project may use. There's no point to fragment it through personal repos. -- Martin Stransky Software Engineer / Red Hat, Inc
