Support Wayland about peek HOT 24 CLOSED

Could this be achieved by using PipeWire and xdg-desktop-portal? This is the new default method when recording the screen under Wayland and at least has really nice integration with a permissions dialog showing up whenever an app is requesting portal access.

For example, with OBS and obs-xdg-portal:

Screen selection:

Window selection:

GNOME screen sharing indicator:

from peek.

Ok, found Kooha it's a perfect replacement for peek in Wayland

from peek.

Just a heads up here that this is, despite my hopes yesterday, not fixed, and probably never will be. While I have recording working, the way Wayland works does not allow Peek to set the recording area position correctly. The whole idea of the Peek UI is that you can set the recording area by moving and resizing the window itself.

On Wayland this does not work, as there is intentionally no such thing as global window coordinates, so Peek as no way to figure out its position on the screen. The Peek model of selecting the recording area just does not work there. The only way this could be fixed would be if the compositor would provide a service to specify the recording position relative to the application window, and not an absolute position as the Gnome Shell screenshot/screencast services currently do.

Please note that it is absolutely possible to implement a screen recording app using the Gnome Shell serviceunder Wayland, but you have to use the options provided there. E.g. you can record fullscreen or ask the service to let the user select an area. But this is a completely different app, and the main reason I developed Peek was about the user interface I wanted to have as it is.

If any possibility to make the Peek model work on a Wayland compositor comes up in future I am more than happy to revisit this again, but for now this is not going anywhere. And I am maybe most disappointed by this since this is one of the last apps that keeps me from migrating to Wayland :(

Also there are indications the very same issue might come up on Mir, but I have not investigated this any further.

from peek.

@Nevax07 Thanks, but it doesn't really help here, sorry.

The issue here itself is well known, and there are actually two points to it:

1. ffmpeg itself does not yet support taking screenshots in Wayland, so it is obvious this doesn't work. We can wait until ffmpeg supports it, but I have no idea whether they have any plans to do so. Also I want to move away from using ffmpeg for screen capturing.
2. There is (for now) not the "Wayland Screen Capture Protocol". There have been talks about this, but for now the individual compositors have their own implementation. Gnome Shell provides a DBUS service for screen capturing, Weston also has some solution (which I haven't looked into, yet).

So my current plan actually is to support the Gnome service as a first step, as Gnome IMHO currently provides the best Wayland experience and people are already using it.

from peek.

I have committed support for recording via the DBus service provided by Gnome Shell, which also works on Wayland. This new backend is used automatically when Gnome Shell is detected, but you can still use the ffmpeg backend if needed by starting peek with the new backend switch:

peek --backend=ffmpeg

This is as far as I can currently go with Wayland support, and is of course limited to the Gnome implementation for now. Please open issues for other Wayland compositors if needed. For Mir see #39.

from peek.

Yes, as of now Wayland is not supported. I definitely want to support Wayland, but screen recording on Wayland currently is a bit more difficult, as there is no official Wayland screen recording API for now. There are however APIs provided by the Compositors. E.g. Weston provides one, and Gnome also has one, but I haven't looked at it yet.

from peek.

Ok, probably final word on this: There is a workaround 😄!

When using Gnome Shell Wayland session you can use Peek to record the screen by using the latest git revision and forcing Peek into launching as an X11 app:

GDK_BACKEND=x11 peek

By this peek will not use the native Wayland backend but will run under XWayland instead, which provides native window coordinates. I will make this the default in the desktop file, as Peek is otherwise unusable on Gnome Shell with Wayland.

from peek.

I tried peek --backend=ffmpeg and GDK_BACKEND=x11 peek
Both didn't work on Sway

from peek.

I tried peek --backend=ffmpeg and GDK_BACKEND=x11 peek Both didn't work on Sway

I've also tried and it didn't work on Gnome.
Another issue is that the Peek window is blocking access to the underlying window, which makes it useless. :(

from peek.

i added a separate issue for this on #98

from peek.

With Mir there is way for recording the screen, can you support mir?

from peek.

Here it is my log, maybe it will be helpful.

nov. 02 07:28:03 arch-obelix dbus-daemon[815]: Activating service name='com.uploadedlobster.peek'
nov. 02 07:28:03 arch-obelix dbus-daemon[815]: Successfully activated service 'com.uploadedlobster.peek'
nov. 02 07:28:03 arch-obelix dleyna-renderer-service[3027]: dLeyna: Exit
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: ffmpeg version 3.2 Copyright (c) 2000-2016 the FFmpeg developers
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   built with gcc 6.2.1 (GCC) 20160830
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libavutil      55. 34.100 / 55. 34.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libavcodec     57. 64.100 / 57. 64.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libavformat    57. 56.100 / 57. 56.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libavdevice    57.  1.100 / 57.  1.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libavfilter     6. 65.100 /  6. 65.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libavresample   3.  1.  0 /  3.  1.  0
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libswscale      4.  2.100 /  4.  2.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libswresample   2.  3.100 /  2.  3.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   libpostproc    54.  1.100 / 54.  1.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: [x11grab @ 0x55e0b1c15b00] Stream #0: not enough frames to estimate rate; consider increasing probesize
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: Input #0, x11grab, from ':0+29,64':
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   Duration: N/A, start: 1478068113.477336, bitrate: N/A
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:     Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1088x575, 15 fps, 1000k tbr, 1000k tbn, 1000k tbc
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: [huffyuv @ 0x55e0b1c48080] using huffyuv 2.2.0 or newer interlacing flag
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: [huffyuv @ 0x55e0b1c4e4c0] using huffyuv 2.2.0 or newer interlacing flag
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: [huffyuv @ 0x55e0b1c52120] using huffyuv 2.2.0 or newer interlacing flag
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: [huffyuv @ 0x55e0b1c562c0] using huffyuv 2.2.0 or newer interlacing flag
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: [huffyuv @ 0x55e0b1c20200] using huffyuv 2.2.0 or newer interlacing flag
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: Output #0, avi, to '/tmp/peekZ22AQY.avi':
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   Metadata:
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:     ISFT            : Lavf57.56.100
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:     Stream #0:0: Video: huffyuv (HFYU / 0x55594648), rgb24, 1088x574, q=2-31, 200 kb/s, 15 fps, 15 tbn, 15 tbc
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:     Metadata:
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:       encoder         : Lavc57.64.100 huffyuv
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: Stream mapping:
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]:   Stream #0:0 -> #0:0 (rawvideo (native) -> huffyuv (native))
nov. 02 07:28:33 arch-obelix com.uploadedlobster.peek[815]: Press [q] to stop, [?] for help
nov. 02 07:28:40 arch-obelix com.uploadedlobster.peek[815]: [1.3K blob data]
nov. 02 07:28:40 arch-obelix com.uploadedlobster.peek[815]: video:49400kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.016574%
nov. 02 07:28:45 arch-obelix dbus[407]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'

from peek.

@phw you should probably inform the Wayland devs, maybe by filing a bug here?

I'm sure they'd want you to be using Wayland rather than XWayland if possible, but definitely worth filing a bug so that it's on there somewhere even if they close it.

from peek.

@Ads20000 The general screenshot issue has already been discussed, and at least for now there is no interest in supporting a screenshot/screencast protocol inside the core Wayland specification, but rather the individual compositors can implement something (and they do).

Also the second issue of not allowing absolute coordinates for applications is a well made decision for Wayland with quite a few advantages and will not change, see e.g. the discussion at https://lists.freedesktop.org/archives/wayland-devel/2015-September/024410.html

If we bring this up somewhere it should probably be addressed to the developers of the individual compositors, not sure how successful this will be. If somebody wants to start a discussion about this somewhere that's ok, but it won't be me as I won't have the time and energy such a discussion requires.

Seriously XWayland will stick around for a while, since too much software is still X based.

from peek.

Green Recorder is able to record on Wayland. Could stealing some code help in this case? [Maybe you can steal / get inspired by some other features, too. ^^]

http://www.omgubuntu.co.uk/2017/03/green-recorder-wayland-screen-recorder?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+d0od+%28OMG%21+Ubuntu%21%29

from peek.

No, won't help. Greenrecorder just uses the Gnome Shell DBus service for screen recording, which Peek also already supports. Without that recording on Wayland would not work at all. Note how Greenrecorder's features are restricted in Wayland. That is because they can only support the use cases as provided by the DBus service.

The main issue Peek has is the positioning of the recording area, a problem Greenrecorder doesn't have. See the Peek FAQs at https://github.com/phw/peek/blob/master/README.md#why-no-native-wayland-support

from peek.

As a side note green-recorder is struggling with exactly the same positioning issue: mhsabbagh/green-recorder#16

from peek.

Well, doesn't work under Wayland at my station at all. I just see the resolution "562x0" – no matter how big the size of the window is, and:

$ GDK_BACKEND=x11 peek
Using screen recorder backend gnome-shell
Error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Invalid params
Error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Invalid params

from peek.

@fbruetting Interesting, I think it errors due to the height being set to 0. Now the height shouldn't make a problem at all, that part even works natively on Wayland. Could be a GTK bug.

What versions of GTK and Gnome are this?

from peek.

Hi and thank you for working on this project. The thread is very interesting. I was wondering if any workaround existed for KDE Plasma, since there seem to be one for Gnome Shell. I use Peek so much I'm staying on X11 right now :D

from peek.

@paulodiovani It works after starting the recording, but for some reason my cursor is appearing in the wrong location.

from peek.

Obs works in Wayland but not Peek, are there other options to record animated gif from a partial screen?

from peek.

Obs works in Wayland but not Peek, are there other options to record animated gif from a partial screen?

I believe Peek will work fine with Gnome on Wayland, but not for other WMs.

Currently, I'm using slurp + wf-recorder on Sway WM, but it shall work for any wl-roots WM.
I couldn't make it work to record GIFs directly, so I use a ffmpeg script to do that myself.

from peek.

@paulodiovani No, I'm on Gnome Wayland and Peek record just the mouse cursor with a black screen behind

I didn't try with ffmpeg

from peek.