[PATCH xf86-video-nested 09/10] Introduce a new XCB client backend, and make it the default one.

Laércio de Sousa laerciosousa at sme-mogidascruzes.sp.gov.br
Mon Nov 9 09:22:31 PST 2015


I will send a v3 patch with some last-minute fixes found right after v2.
Hopefully all your advices are contempled now.

Please tell me if you have any other concerns.

Att.

2015-11-06 15:18 GMT-02:00 Uli Schlachter <psychon at znc.in>:

> Hi,
>
> Am 06.11.2015 um 14:10 schrieb Laércio de Sousa:
> [...]
> >>> +static void
> >>> +_NestedClientSetWMClass(NestedClientPrivatePtr pPriv,
> >>> +                        const char* wm_class)
> >>> +{
> >>> +    size_t class_len = strlen(wm_class) + 1;
> >>> +    char *class_hint = malloc(class_len);
> >>> +
> >>> +    if (class_hint)
> >>> +    {
> >>> +        strcpy(class_hint, wm_class);
> >>> +        xcb_change_property(pPriv->conn,
> >>> +                            XCB_PROP_MODE_REPLACE,
> >>> +                            pPriv->window,
> >>> +                            XCB_ATOM_WM_CLASS,
> >>> +                            XCB_ATOM_STRING,
> >>> +                            8,
> >>> +                            class_len,
> >>> +                            class_hint);
> >>> +        free(class_hint);
> >>> +    }
> >>
> >> Why is this strcpy needed?
> >>
> > I've copied over this piece of code from Xephyr. In that context,
> > class_hint stores a concatenation bewteen two strings, so that strcpy is
> > needed, but here the WM_CLASS string is much more simple, so that strcpy
> is
> > not needed. I'll remove it. Thanks!
>
> Uhm, right. This wants to set WM_CLASS and WM_CLASS should contain "two"
> strings
> (the class and the instance), separated by a null byte.
>
> Sorry for not noticing this earlier, but isn't this code wrong then?
>
> https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
>
> [...]
> >>> +        if (!ev)
> >>> +        {
> >>> +            if (_NestedClientConnectionHasError(pPriv->scrnIndex,
> >>> +                                                pPriv->conn))
> >>> +            {
> >>> +                /* XXX: Is there a better way to do this? */
> >>> +                xf86DrvMsg(pPriv->scrnIndex,
> >>> +                           X_ERROR,
> >>> +                           "Connection with host X server lost.\n");
> >>> +                free(ev);
> >>> +                NestedClientCloseScreen(pPriv);
> >>> +                exit(1);
> >>> +            }
> >>> +
> >>> +            break;
> >>> +        }
> >>> +
> >>> +        switch (ev->response_type & ~0x80)
> >>> +        {
> >>> +        case XCB_EXPOSE:
> >>> +            _NestedClientProcessExpose(pPriv, ev);
> >>> +            break;
> >>> +        case XCB_CLIENT_MESSAGE:
> >>> +            _NestedClientProcessClientMessage(pPriv, ev);
> >>> +            break;
> >>> +        case XCB_MOTION_NOTIFY:
> >>> +            _NestedClientProcessMotionNotify(pPriv, ev);
> >>> +            break;
> >>> +        case XCB_KEY_PRESS:
> >>> +            _NestedClientProcessKeyPress(pPriv, ev);
> >>> +            break;
> >>> +        case XCB_KEY_RELEASE:
> >>> +            _NestedClientProcessKeyRelease(pPriv, ev);
> >>> +            break;
> >>> +        case XCB_BUTTON_PRESS:
> >>> +            _NestedClientProcessButtonPress(pPriv, ev);
> >>> +            break;
> >>> +        case XCB_BUTTON_RELEASE:
> >>> +            _NestedClientProcessButtonRelease(pPriv, ev);
> >>> +            break;
> >>> +        }
> >>> +
> >>> +        free(ev);
> >>> +        xcb_flush(pPriv->conn);
> >>
> >> Why is this flushing inside of the event loop? Wouldn't a flush after
> the
> >> loop
> >> be enough?
> >>
> > Well... Comparing it with other XCB snippets I've found in the web, it
> > seems this xcb_flush() call is not needed at all. Calling it right atfer
> > window creation or redrawing (XCB_EXPOSE event only) should be enough,
> > right?
> [...]
>
> Well, it depends. Something should flush in the end in case there are any
> requests still in XCB's output buffer (and nothing implicitly flushes them
> by
> waiting for a reply). So I think that having a call to xcb_flush() before
> returning to this function should be added. If it does something, it just
> prevented a bug and if it doesn't do anything, it's not expensive. ;-)
>
> Everything else seems fine, thanks.
>
> Uli
> --
> "For saving the Earth.. and eating cheesecake!"
>



-- 
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20151109/c06677e4/attachment-0001.html>


More information about the xorg-devel mailing list