A question about XCompositeRedirectSubwindows

Wed Jun 20 00:35:44 UTC 2018

On Tue, Jun 19, 2018 at 2:23 PM Egil Möller <egil at innovationgarage.no>
wrote:

> Oups, sorry for my reply-to-you-only, that was a mistake.
>
> So my problem with letting events "fall through" to the window is that I
> plan to do zoom (hence the OpenGL), both in and out, and would like to have
> events working even in a zoomed state... The window manager idea I'd like
> to build is one that extends the multiple virtual workspaces metaphor into
> an infinite desktop that you can zoom and pan as you like, and paste a
> window onto at any size at any zoom level... It might be a bit hard as a
> first project this deep into X stuff, but it's something I've wanted to
> build for a long while. So, what are the reasons synthesizing events will
> fail (and how will they fail)?
>

First off, there's a super high latency cost here. Second, actually filling
in the correct event is unobvious and tricky, especially when dealing with
XInput2. It would require building the equivalent of an X server inside
your CM to send. It would probably not be too much work for anything that
doesn't use too many server-side subwindows and just treats the window as a
single surface, so it miiiight be good enough for most cases, but I'd be
sketchy. And most apps that don't use server-side windows will be the ones
using XI2. Third, input grabs will override your COW, so anything that uses
a pointer grab will see bizarre behavior. Fourth, synthesized events are
specially marked, and some clients might throw out events with the
synthesized flag set.

To be honest, this problem was one of the original problems that Wayland
tried to solve. In the Wayland architecture, the display server and
compositing manager are combined into a single process, and the compositor
has full control over sending events to surfaces. It might be easier to
hack up a Wayland compositor to get it to do what you want.

> Hehe, that is the impression I got from plowing through the specs and code
> too.. It would kind of be useful to get to talk to one of those people
> about how things are "supposed to work".
>

A lot of those people are on this list. Or, if not here, on the
wayland-devel list. I'm not one of them, but I feel I've worked on enough
X-related things to understand how the system is put together.

> Thanks! I think I might need it :P
>
>
> On 19. juni 2018 16:52, Jasper St. Pierre wrote:
>
> Hi,
>
> (Re-adding xorg-devel. Please make sure to keep the list CC'd in the
> future)
>
> It is possible for a window to set "no background color", in which case
> the existing window contents are used for the pixmap. xclock likely sets no
> background color. You can check an individual window's properties with
> xwininfo.
>
> Redrawing the screen every frame isn't a bad idea for a simple compositor
> to get started. For a more fancy, complete redraw loop, you can track when
> windows get drawn to with with the Damage extension, and schedule a repaint
> when that happens. Bonus points if you use the damage rectangles to be more
> accurate with your redraw. Also, helpful hint that windows get their
> backing pixmaps thrown away when resized -- you need to pay attention to
> ConfigureNotify and regrab the backing pixmap with
> XCompositeNameWindowPixmap, and that whole jazz.
>
> I don't recommend synthesizing input events -- a lot of things are likely
> to break or just not work well. Set an empty input shape on the COW, and
> make sure to draw windows where they want to be. Pay attention to
> MotionNotify events from windows that are moving.
>
> I'm unaware of any beginner-level documentation or tutorials. The number
> of people that have written a compositing manager from scratch can be
> counted on one hand, and a lot of them had a hand in designing the
> architecture to begin with.
> https://magcius.github.io/xplain/article/composite.html has some ideas of
> the broader concepts, but none of the details.
>
> Good luck.
>
> On Tue, Jun 19, 2018 at 2:01 AM Egil Möller <egil at innovationgarage.no>
> wrote:
>
>> Hi!
>>
>> Thanks for answering a noob question :) Ha! That's so not documented (in
>> an obvious way)! I was assuming that I could get the initial window
>> content, as already drawn (obviously clipped to whatever is visible on
>> screen) directly... So why does xclock "work" then? I just haven't gotten
>> around to event handling yet, wanted to learn the drawing/copying methods
>> themselves first...
>>
>> Two follow up questions:
>>
>>   * How should I redraw the screen? As often as I can, or waiting for
>> some event for all redirected windows (which event)?
>>   * Can I capture input events (key, mouse) for the overlay window and
>> then somehow synthesize them for whatever window / subwindow my window
>> manager thinks it has drawn in that position? Some docs I read sounded like
>> this is impossible, and you should turn of input for the overlay, and
>> position the real window underneath in a "strategic position"...
>>
>> Also, is there any good documentation and/or tutorials around this
>> anywhere?
>>
>> /Egil
>>
>> On 19. juni 2018 08:42, Jasper St. Pierre wrote:
>>
>> Hi,
>>
>> What you're seeing here is a fun little side effect of composite. As you
>> might be aware, unredirected X windows don't have any backing storage
>> beyond the front buffer -- the full window contents are not really there.
>> That means that when the X server first goes to redirect these windows, it
>> decides that it should let the window paint again, and sends the window an
>> Expose event to let it know it should repaint. A side effect of this is
>> that the X server redraws the background for the window. This is the
>> semantics for what an Expose event means -- an area that is "Exposed" is
>> the background color until the client paints over it.
>>
>> The client will eventually paint its window contents, but since your CM
>> does not appear to have a frame loop, and it only paints once, you do not
>> see the updated frame contents.
>>
>> On Sun, Jun 17, 2018 at 1:28 PM Egil Möller <egil at innovationgarage.no>
>> wrote:
>>
>>> Hi!
>>>
>>> I'm trying to write a new compositing window manager, and finding the
>>> documentation for the API:s I need quite spread out.
>>>
>>> The particular problem I'm having right now is that copying some windows
>>> (xclock) using
>>> XCompositeRedirectSubwindows and e.g. XRenderComposite works fine, while
>>> other windows (xterm, xlock) leaves me we a square with only their
>>> background color. This seems to be true for both XRenderComposite and
>>> glXBindTexImageEXT. Any ideas what's different between them, and what I
>>> need to do differently?
>>>
>>> My code is here: https://github.com/redhog/InfiniteGlass
>>> (main code is in wm.c; running "make" ahould give you an Xephyr nested X
>>> session that shows the problem).
>>>
>>> Thanks in advance,
>>>
>>> Egil Möller
>>>
>>>
>>>
>>> _______________________________________________
>>> xorg-devel at lists.x.org: X.Org development
>>> Archives: http://lists.x.org/archives/xorg-devel
>>> Info: https://lists.x.org/mailman/listinfo/xorg-devel
>>
>>
>>
>> --
>>   Jasper
>>
>>
>>
>
> --
>   Jasper
>
>
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180619/0891d8de/attachment.html>