Peek: Support Wayland

[agravelot]

I can't record my screen when I'm using Wayland.
This screen is black, see the link.
http://image.noelshack.com/fichiers/2016/41/1476636882-peek-2016-10-16-18-44.gif

Linux arch-asterix 4.7.7-1-ck #1 SMP PREEMPT Fri Oct 7 16:05:42 EDT 2016 x86_64 GNU/Linux
gnome-shell 3.22.1+2+g5a08886-1

Thank you for this awesome tool!

[phw]

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.

[pharaone]

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

[agravelot]

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'

[phw]

@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.

[phw]

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.

[phw]

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.

[phw]

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.

[Ads20000]

@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.

[phw]

@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.

[fbruetting]

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

[phw]

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

[phw]

As a side note green-recorder is struggling with exactly the same positioning issue: https://github.com/green-project/green-recorder/issues/16

[fbruetting]

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

[phw]

@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?

[phw]

i added a separate issue for this on https://github.com/phw/peek/issues/98