Bug 412731 - Please add API to get list of all window IDs on Wayland (so that I can iterate over them and make screenshots using org.kde.kwin.Screenshot)
Summary: Please add API to get list of all window IDs on Wayland (so that I can iterat...
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.14.5
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-08 13:00 UTC by Askar Safin
Modified: 2020-09-12 18:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Askar Safin 2019-10-08 13:00:47 UTC
My final task is this: I want to capture videos from all my opened videos. Every window should produce its own video. Even covered windows should produce video and ideally minimized ones, too.

Currently I do this using small C++ program written using Xlib.

Unfortunately the world is moving to Wayland, so I start to research how to do similar thing on Wayland. I discovered that Wayland (as opposed to X11) doesn't have standard way to get window images, so I should use some tricks, specific for particular Wayland server implementation. (Note here: yes, I know about xdg-desktop-portal, but as well as I know it doesn't give a way to take screenshot or a video from particular specified window, so xdg-desktop-portal is not for me.) So I started to research my Wayland server implementation, i. e. kwin_wayland.

I discovered that kwin_wayland offers a way to take screenshot of a particular window:

dbus-send --dest=org.kde.KWin /Screenshot org.kde.kwin.Screenshot.screenshotForWindow <winid>

Unfortunately, I was unable to understand what is this <winid>. On X11 this is (it seems) usual X11 window id. But on Wayland?! And how to get list of such ids?

So, I ask for adding some way to get list of all IDs suitable to pass to org.kde.kwin.Screenshot.screenshotForWindow . Preferably this should be another dbus interface.

This will allow me to write program I need. This program will repeatedly call screenshotForWindow for all windows on the system, thus creating videos.

Without such interface "screenshotForWindow" is completely useless and should be removed.

Also screenshotForWindow doesn't take fd as opposed to other functions in org.kde.kwin.Screenshot . This is bad, too, please, fix this.

SOFTWARE/OS VERSIONS
Linux Debian sid (created Oct 2019) amd64. KDE Plasma. Wayland

(available in About System)
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.11.3
Comment 1 David Edmundson 2019-10-08 13:07:43 UTC
>I want to capture videos from all my opened windows

Why? Surely you know which windows you want in advance.

There won't be a way for programs to get screenshots without some user interaction for security purposes. 

>This will allow me to write program I need. This program will repeatedly call screenshotForWindow for all windows on the system, thus creating videos.

That doesn't sound a very efficient way to record a video.

We do have pipewire support.
Comment 2 Askar Safin 2019-10-08 13:30:09 UTC
(In reply to David Edmundson from comment #1)
> Why? Surely you know which windows you want in advance.
This is my task. In X11 this worked. In Wayland it doesn't work, so we have no feature parity.

My computer often crashes for various reasons. So I want to record videos from each of opened windows. So that after crash I can restore state of this windows.

Reasons for crashes are really diverse. Not only software crashes or power outages but also physical force. For example one day I was angry and I hit table where was my laptop, and then this laptop forcibly rebooted.

> There won't be a way for programs to get screenshots without some user
> interaction for security purposes.
Currently such way exists even on Wayland. This command:

dbus-send --dest=org.kde.KWin --print-reply /Screenshot org.kde.kwin.Screenshot.screenshotFullscreen

create screenshot without user interaction.

> We do have pipewire support.
Does you have way to capture pipewire stream from particular window? (I want to get list of all windows and capture them all, even covered ones.)

I have read https://flatpak.github.io/xdg-desktop-portal/portal-docs.html and it seems that I can capture video either from whole screen, either from some my own window. It seems capturing window of other app is not supported
Comment 3 David Edmundson 2019-10-08 15:22:32 UTC
>In Wayland it doesn't work, so we have no feature parity.

Correct. Making an exact clone is not an aim.

I am happy to help do what we need to address any valid use cases, if we can solve them properly. However, I still don't yet understand, how does this help with a crash?

>Currently such way exists even on Wayland

There are patches to remove that.


>Does you have way to capture pipewire stream from particular window?

Not currently, but it's something I do want to add.
Comment 4 Askar Safin 2019-10-08 17:41:36 UTC
(In reply to David Edmundson from comment #3)
> I am happy to help do what we need to address any valid use cases, if we can
> solve them properly.
Thanks a lot!

> However, I still don't yet understand, how does this
> help with a crash?

I often have something like 50 various windows opened. When my computer crashes, of course, I am completely disappointed and frustrated. Because all information about state of my computer and all information about my work is lost. In some sense set of opened windows *is* to-do list.

When I start to do something, I open relevant windows. Then this work may for some reason become postponed and some new urgent work may appear. Then I open new windows (without closing previous set of windows). This can happen a lot of times and then I may got 50+ windows, some of them are "new" (i. e. opened recently) and some "old" (i. e. I saw them very lot of time ago).

I rarely reboot my computer and I often use hibernate.

So, I want to record video from every window. If my computer crashes, I will watch all this videos (with a paper and pencil in my hands) and thus I will be able to open all this windows again restoring their state.

You may ask: why you need to watch video, why not just see the last screenshot?

Well, there is a lot of programs, such that their state cannot be restored by last screenshot. For example, browser window with tabs. I need to watch video in reverse order starting from last screenshot until all tabs will show up in video. Same for konsole windows. I need to watch entire video to see all commands and their output. Last screenshot will show me only few last commands.

So I will watch all this videos in reverse order from last screenshot until all information from this particular video is restored.

Okey, what I do currently? Currently I don't have such program. I use X11, and I simply record video from whole screen using "ffmpeg -f x11grab". When my computer crashes I watch this video (with a paper and pencil) from last frame until all windows will show up in video and all information from them is restored.

I usually restart video capturing once a day and unminimize all windows to make sure all they are captured. So in case of crash I need to watch no more than last day. Watching such video usually takes whole day.

What programs I use? Most of time I use 3 programs only: konsole, chromium and kate/kwrite. Usually I have lots of konsole windows opened, lots of chromium windows opened and a few kate/kwrite windows. Currently I have 8 konsoles and 11 chromiums (i. e. 19 windows). This is good situation, often windows count is more.

You may ask: why not just use build-in capabilities in this programs for restoring state? Chromium can restore tabs, kate can restore unsaved files and for konsole we have .bash_history. Well, this is true, but unfortunately all this features are not complete.

Let's begin from Chromium. Usually it restores form data correctly. But unfortunately sometimes this just fails. Also, Chromium doesn't restore form data for dynamically created form elements. If I remember correctly Chromium dev even said to me in bug tracker that Chromium will never restore form data in dynamically created elements. For example, go open https://paste.gg/ . Then click "Add file". Additional dynamically created <textarea> will open. Type some text to it, then crash your browser and restore tabs. That text will be lost.

Now let's speak about konsole. I use konsole windows as to-do list in some sense. Let me explain. For example, I created some file or directory using konsole. Say, I typed "mkdir /some-dir". Then I will not close this window while I need this dir. I. e. this window serves as reminder that this directory exists and that I should delete it when it becomes not needed. So I need to restore all konsole windows. To know what files and dirs I created to know that I should delete them. Of course, all this applies not only to files and dirs, but to other things, too. For example, I temporary moved some file from one place to another. Then this konsole window with "mv" command serves as reminder that this file should be moved back. Etc, etc. Okey, what about .bash_history? Well, first of all, in case of hard crash commands in opened windows are lost (because bash writes .bash_history at exit). But bash can be configured to write command to history immediately. So, let us assume we configured bash so. What next? Well, then .bash_history will contain all commands. From opened windows and from closed. But I need from opened only! Because they are in some sense to-do list. They mean actions which started but not finished. Temporary dirs which I created and not yet deleted etc. Also I need output of commands, not only commands themselves.

Okey, all this problems with programs can be fixed.

I can write Chromium extension which will save tabs better than standard mechanism. I can use something like asciinema or script ( https://manpages.debian.org/buster/bsdutils/script.1.en.html ) to save konsole state (side note: asciinema and script don't handle change of window size correctly, so they are not full solution, either). But I still need some mechanism which will simply record video from all windows. Why? For two reasons:

1. Robustness. Having general failback mechanism in addition to application-specific hacky solutions (chromium extensions and asciinema) is a good thing. Robustness is a good thing.
2. Most of time I use konsole, chromium and kate/kwrite, but sometimes I use something different. And I don't want to research ways to restore state in new application before using it. I want state saving to simply work.

Ask me questions if you still have them. I can explain you everything. I also can show you code I wrote so far. I wrote tool which captures videos for all X11 windows. This program is unfinished, so I currently don't use it. Also I wrote my own small analog of asciinema/script.

You may ask: why not simply fix all software and hardware problems which can cause crashes? Well, reasons are diverse. This can be power outage on my laptop. This can be something completely different. For example, one day I created isolated container on my laptop and gave away the access to this container to members of public IRC channel. I thought this container is completely isolated and anonymous IRC members will not cause any harm to my computer. But this was mistake. Someone simply started fork bomb and my computer got completely frozen. So I forcibly rebooted it and lost all state (this was time when I didn't use "ffmpeg -f x11grab" yet).

> Not currently, but it's something I do want to add.
Thanks a lot. If you address my use case, this would be great
Comment 5 David Edmundson 2020-01-27 12:02:48 UTC
>This program is unfinished, so I currently don't use it

I think this says a lot. 
This is purely hypothetical idea and I don't think would actually help you accomplish anything.

We will have per window recording at some point in the future. If you can use that for your ideas, great. 

But adding wayland support for a workflow no-one uses is not a bug currently.
Comment 6 Askar Safin 2020-09-12 18:18:26 UTC
>>This program is unfinished, so I currently don't use it
>I think this says a lot
Hi. Things changed. I rewrote my program from xlib to xcb and added some features. I used it successfully from 2020-05-09 to today (2020-09-12) and I will continue to use it. It records all opened windows simultaneously. I. e. not whole desktop, but each windows separately. I. e. the program does exactly what I want. I runs on top of KDE on X11. And it seems it is currently impossible to port it to kwin-wayland.

For all this time my computer never crashed. Except for today. Today the computer crashed and I was able successfully restore state of my computer using captured video. So I write this success report