On Fri, 30 Jan 2015 21:31:24 +0200 Ruslan Kuprieiev <[email protected]> wrote:
> Hi! > > I would like to add checkpoint/restore support of a graphical app(no > gl) that uses wayland. > I'll appreciate any thoughts and ideas on how to accomplish that as > well as what simplest > app should I start with. > > After discussing it on #wayland, it looks like I should start with > creating patches for weston > to implement needed getters and setters to obtain client's state on > dump and set it on restore. > > I was wondering if you could help me by providing some info about > amount of data, that > describes the client's state. > > I'll also appreciate any hints on where to start digging into weston. Structs weston_surface, weston_view, weston_subsurface, shell_surface... everything contained by those is a candidate, plus everything that ever references those or those reference. Shared mmapped files, file descriptors... I have very hard time seeing what could work for you while not rewriting the world. Maybe you could start by looking at software pixel buffers. A client creates a file on tmpfs, mmaps and writes pixels into it, sends the file descriptor to the compositor, and the compositor mmaps that file. So for save/restore, you need to somehow reinstate this mapping in both the client and the compositor. This is the fundamental, basic mechanism how clients send content to the compositor, and the compositor decides how long it needs it. Can you do that? Clients send the file descriptor only once per wl_shm_pool. After that they assume they can re-use the wl_buffers indefinitely. We have no mechanism to revoke any. Can you save and restore unix socket connections? Note, that (re)connecting means starting from a clean slate in Wayland protocol state wise. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
