wayland-protocols
wf-recorder
wayland-protocols | wf-recorder | |
---|---|---|
5 | 13 | |
141 | 768 | |
- | - | |
4.8 | 6.7 | |
over 1 year ago | about 2 months ago | |
Meson | C++ | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wayland-protocols
-
c-api for wayland input-method-unstable-v1
I was wondering which .so contains the symbols for https://github.com/wayland-project/wayland-protocols/blob/main/unstable/input-method/input-method-unstable-v1.xml.
-
Flameshot, powerful screenshot tool, fully support Wayland (able to run on sway)
I was researching the issue and noticed wlr-screencapture. I was hoping to see it at https://github.com/wayland-project/wayland-protocols too, but no luck. Thanks for the lead on xfg-desktop-portal.
It is fascinating watching the near decade-long journey as Wayland tackles screenshots.
-
Guide: Full Wayland Setup for Linux
> Nothing is thrown away -> xserver is there for exactly this reason. Adding the extension for a system with bad abstraction is not too wise, but if you wanted to understand it, you would have done so already based on the video.
I did watch the video, and while I was convinced that the X.org reference implementation was crusty, I was not convinced that there was anything inherently wrong with X11-the-protocol. Like, if there existed an X extension whose responsibility was just to get clients set up with their own video buffers that it could composite for them, then it sounds like it would address 90% of Wayland's value proposition. Is there a particular video snippet you want me to pay special attention to that clarifies this?
> Why would it be lost? There is a core protocol that absolutely specifies it.
I read through the stable interface definitions in the wayland-protocols repo [1], and did not see anything related to controlling which programs get to see which events. Is this still in development (or unstable)? If so, is there an ETA at which point I can expect every correct Wayland compositor to faithfully implement it?
> And when you had only one player in the whole game.. which is pretty contradictory to your last sentence.
That's because the X server implements the mechanisms, not policies, for multiplexing the screen and input devices. In the service of this, it provides tools to enumerate, identify, query, modify, and extend properties of windows, as well as route messages between them. There was never a compelling need for multiple competing incompatible X servers because X is the narrow waist (i.e. an unopinionated digital commons) shared by software that competed on policy.
> I didn’t address these things because basically everything has a solution under wayland nowadays. Please have a look at the wayland-protocol repo and see for yourself the state of it. Also, wayland is a display manager, just because the X server was a monolith, it had no place to eg. manage clipboard. Actually, Wayland is the one that fulfills the UNIX philosophy of do one thing (although I don’t find the UNIX philosophy a good thing in every case)
I read through the unstable interface definitions, and see that Wayland is indeed trying to implement not only the same kinds IPC facilities and input device multiplexing that X provided, but also is trying to impose stronger opinions on what types of windows exist and how they behave (e.g. Wayland has a notion of pop-ups, text inputs, and so on). So if Wayland's goal is to avoid being as "monolithic" as X, it appears to be failing.
Also, putting core functionality that everyone must implement the same way into extensions just so they can call Wayland "just a protocol" or "just a display manager" is disingenuous. They might as well just say that they're part of the core protocol.
> No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way.
Does the wlroots project define what extensions are standard and required for a piece of software to call itself a Wayland compositor? No? Then "just use wlroots" isn't addressing the problem of making sure these compositors are compliant to a set of common, useful standards. Like, maybe wlroots should be the standard-definer, just as X was? What happens with window managers built with a compositor that is not wlroots?
[1] I was looking here: https://github.com/wayland-project/wayland-protocols
-
Plasma Wayland (session) Has Come a Long Way, But....
Virtual keyboard: https://bugs.kde.org/show_bug.cgi?id=427972 it is still a hot-topic on the protocol definition side with the current definition https://github.com/wayland-project/wayland-protocols/blob/master/unstable/text-input/text-input-unstable-v3.xml still not satisfactory, this was one of the subject of this weekend Plasma Wayland online Sprint. The Virtual keyboard is especially important for different input methods, aka chinese, japanese, koreans characters. You may want to setup http://maliit.github.io/ on your system.
-
[SimpleWM] Sometimes you just have to make things from scratch
The protocol XML files have remarkable, concise documentation of each request, event and interface. Core protocol. Other protocols.
wf-recorder
-
How to screen capture using ffmpeg on wayland?
Try wf-recorder.
-
Peek Alternative
The closest thing is probably wf-recorder.
- How can I record my screen with the correct display as input?
-
XWayland 22.1 Planned For Release Next Month
The spec is designed to be minimal and it's expected for compositors to work together and add additional features, for example here is the tool for screen recording on wlroots compositors (sway and what most wayland WM's use) https://github.com/ammen99/wf-recorder, even though most people claim wayland doesn't support screen-recording/screenshotting. We just don't have a universal tool for that that works on all compositors, pipewire however seems to be coming to fill that niche.
-
Free Screen Recorder for a very low-end laptop.
If you are on Wayland, wf-recorder Is a good choice .
-
This is my "Sway is fantastic" post
As for screen recording, I’ve used wf-recorder (IIRC, not at PC atm) several times the past couple of weeks, works equally well.
-
Poor quality when using h264_vaapi and hevc_vaapi to encode screen recording on linux (wayland) with wf-recorder
The issue I'm encountering is described here in more detail (including images).
-
Flameshot, powerful screenshot tool, fully support Wayland (able to run on sway)
Wfrecorder [0] is what I use, doesn't have a fancy gui but it just works
0: https://github.com/ammen99/wf-recorder
-
Think Twice Before Abandoning Xorg – Wayland Breaks Everything
A workaround for sharing the whole screen is to use wf-recorder [1], which supports capturing the whole screen, and feeding its output to a virtual V4L2 device using v4l2loopback [2]. Software that is able to capture from a V4L2-compatible webcam (i.e. most) can them capture from the virtual device without knowing anything about Wayland. It's not exactly the most CPU-efficient way of doing things, but if you can afford the cycles it works very well!
[1] https://github.com/ammen99/wf-recorder
[2] https://github.com/umlaeute/v4l2loopback
-
ffscreencast – a screencast CLI-tool with video overlay and multimonitor support
You want to use wf-recorder. This is in my sway config:
> set $screenrecord wf-recorder -g "$(slurp)" -f ~/screenshots/mov-$(date +"%Y-%m-%d--%H-%M-%S.mp4")
> bindsym Shift+Control+F6 exec $screenrecord
> bindsym Ctrl+Shift+BackSpace exec killall -s SIGINT wf-recorder
Hitting shift-control-f6 will spawn slurp which lets you click and drag to set the area you want to record. This will then launch wf-recorder and record the selected area, saving to ~/screenshots/mov-${date}. You can use ctrl-shift-backspace to kill the recorder and end recording.
https://github.com/ammen99/wf-recorder
https://github.com/emersion/slurp
What are some alternatives?
peek - Simple animated GIF screen recorder with an easy to use interface
sway - i3-compatible Wayland compositor
flameshot - Powerful yet simple to use screenshot software :desktop_computer: :camera_flash:
wtype - xdotool type for wayland
Jitsi Meet - Jitsi Meet - Secure, Simple and Scalable Video Conferences that you use as a standalone app or embed in your web application.
wayfire - A modular and extensible wayland compositor
swaylock - Screen locker for Wayland
grim - Grab images from a Wayland compositor
wlroots - A modular Wayland compositor library
Waybar - Highly customizable Wayland bar for Sway and Wlroots based compositors. :v: :tada:
clipman - A simple clipboard manager for Wayland