Re: Full-motion zero-copy screen capture in Weston
Hi Matt, fös., 31. maí 2024 kl. 15:34 skrifaði Hoosier, Matt : > > Thanks, understood. I would expect that I need to take some care in > allocating a buffer that my DRM driver accepts for writeback, in this usage. > > > > Do I interpret right that the wlroots screencopy extension wants the client > to create a fresh zwlr_screencopy_frame_v1 for each successive frame? I > wonder then: > > > > * Whether this might lead to the possibility of dropped frames, if the client > doesn’t manage to send back the requests to start capture for frame N+1 soon > enough after the delivery of the copied buffer for frame N; and If you send a frame request as soon as you receive an update, frames will not be dropped. > * Will the explicit request for each frame via zwlr_screencopy_frame_v1:: > copy(), result in artificial redraws to satisfy the request? Ideally I would > just like to receive a passive copy of each frame that naturally got drawn by > the compositor. Perhaps with one artificial redraw at the very beginning of > the screencopy stream just to have a defined starting point. For wlr-screencopy-v1, you can use the the "copy_with_damage" request to avoid "artificial redraws". See: https://wayland.app/protocols/wlr-screencopy-unstable-v1#zwlr_screencopy_frame_v1:request:copy_with_damage For ext-screencopy-v1, when you create a session, a redraw may be required for the first frame. After that, only damaged frames are copied for that session. See: https://wayland.app/protocols/wayland-protocols/124 Regards, Andri
Re: Full-motion zero-copy screen capture in Weston
Hi Matt, fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt : > > Hi, > > Yeah. I agree that although I can prototype something quick and dirty here as > a change to weston_output_capture_v1, it's probably not a good fit there. > > Drew or Simon, does either of > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml > or > https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml > strike you as a good fit for the use-case of getting a streamed copy of an > output? They seem very similar – not sure what differentiates them from each > other. > I'd say ext-screencopy-v1 is pretty close to being complete. It is designed for both single shot capture and screen casting. It has 2 acks and it has been implemented in wlroots, cosmic and wayvnc. I would not recommend wlr-export-dmabuf for anything as it suffers from synchronisation issues. There are no guarantees for life-times of the dmabufs. wlr-screencopy works well enough, but ext-screencopy-v1 is better. See: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124 > My goal is to implement this screen capture with a guarantee that the copy > comes from a KMS writeback connector. I know this sounds like an odd thing to > insist on. Let's say that in my industry, the system is rarely only running > Linux directly on the bare metal. Using the writeback hardware on the display > controller allows to get a copy of content from all the virtual machines in > the system. Although the protocol is called "screencopy", it does not need to be implemented via copying. I don't think anything precludes drm write-back or rendering directly to the client-submitted buffers. Regards, Andri
[ANNOUNCE] wayvnc v0.5.0
Hi all, I've just released wayvnc v0.5.0. The most significant addition for this release is H.264 encoding via the Open H.264 RFB protocol extension. Clients that have implemented Open H.264 at this time are TigerVNC and wlvncc, of which only the latter uses hardware accelerated decoding. H.264 encoding is hardware accelerated and requires the `--gpu` command line flag to be enabled. It isn't particularly useful without hardware acceleration, so it's better to stick with "Tight" encoding if you don't have GPU rendering. More details can be found on the release page: https://github.com/any1/wayvnc/releases/tag/v0.5.0 and the accompanied neatvnc release here: https://github.com/any1/neatvnc/releases/tag/v0.5.0 Best regards, Andri
Re: xkbcommon: Converting keysym to keycode
Hi adlo mið., 1. des. 2021 kl. 14:31 skrifaði adlo : > > Hi > > Does xkbcommon have a function to convert a keysym to a keycode? It does not, last time I checked, but "xkb_keymap_key_get_mods_for_level" does help a lot. Wayvnc does this sort of reverse key mapping. Maybe this helps? See: https://github.com/any1/wayvnc/blob/master/src/keyboard.c Regards, Andri
[ANNOUNCE] wayvnc 0.3.1
New features since v0.2.0: * Copy & paste, thanks to Scott Moreau. * wayvnc now has a man page. * wayvnc now exits if authentication is enabled but fails. Git commit history since v0.2.0: Alexander Graul (1): Add openSUSE Tumbleweed installation instruction Andri Yngvason (15): buffer: Fix buffer attribute comparison README: Use "yay" in archlinux installation instructions Exit if enabling auth fails Clean up config on exit Clean up aml on nvnc init failure data-control: Make offer handling asynchronous data-control: Don't free data-control-manager twice data-control: Clean up whole receive context in aml_free_fn data-control: Destroy data device on exit Don't init data_control if it's not supported by compositor Write a man page Generate and install a man page man-page: Fix wording FAQ: Remove outdated Q Release v3.0.0 Fix man page path Jan Beich (1): shm: guard fallback on FreeBSD < 13 as well Jony (1): add Void Linux install command to README.md Scott Moreau (1): Add basic clipboard support https://github.com/any1/wayvnc/archive/v0.3.1.tar.gz md5 40fa40caf3052256626a4e345a50ccb4 wayvnc-v0.3.1.tar.gz sha1 ee0103dab69b5d39690ded4f5058b400c81c9b04 wayvnc-v0.3.1.tar.gz sha256 7b68af5bfa5e19352aaa5140e6c2418f90bfe6a949775bd236b06796c56e27f5 wayvnc-v0.3.1.tar.gz sha512 0ddfd949b76a4dc140b825f488eb887cf4608a685b9d2b8a514a2ad5b436baf2ea1cdcd159ec98e22bf3724daab71822d5beded3695dd05b4b062ad76ad3f25b wayvnc-v0.3.1.tar.gz ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
