[PATCH xserver 4/7] glx: Use vnd layer for dispatch (v2)
Kyle Brenneman
kyle.brenneman at gmail.com
Wed Jan 10 20:57:10 UTC 2018
On 01/10/2018 11:05 AM, Adam Jackson wrote:
> The big change here is MakeCurrent and context tag tracking. We now
> delegate context tags entirely to the vnd layer, and simply store a
> pointer to the context state as the tag data. If a context is deleted
> while it's current, we allocate a fake ID for the context and move the
> context state there, so the tag data still points to a real context. As
> a result we can stop trying so hard to detach the client from contexts
> at disconnect time and just let resource destruction handle it.
>
> Since vnd handles all the MakeCurrent protocol now, our request handlers
> for it can just be return BadImplementation.
>
> We also remove a bunch of LEGAL_NEW_RESOURCE, because now by the time
> we're called vnd has already allocated its tracking resource on that
> XID. Note that we only do this for core GLX requests, for vendor private
> requests we still need to call LEGAL_NEW_RESOURCE and in addition need
> to call up to addXIDMap and friends.
>
> v2: Update to match v2 of the vnd import, and remove more redundant work
> like request length checks.
>
> Signed-off-by: Adam Jackson <ajax at redhat.com>
> ---
> configure.ac | 2 +-
> glx/createcontext.c | 2 -
> glx/glxcmds.c | 275 ++++++++++++----------------------
> glx/glxcmdsswap.c | 98 +-----------
> glx/glxext.c | 329 ++++++++++++++++++++++++++++-------------
> glx/glxext.h | 4 +
> glx/glxscreens.h | 1 +
> glx/glxserver.h | 5 -
> glx/xfont.c | 2 -
> hw/kdrive/ephyr/ephyr.c | 2 +-
> hw/kdrive/ephyr/meson.build | 1 +
> hw/kdrive/src/kdrive.c | 3 +
> hw/vfb/InitOutput.c | 2 +
> hw/vfb/meson.build | 3 +-
> hw/xfree86/Makefile.am | 5 +
> hw/xfree86/common/xf86Init.c | 2 +-
> hw/xfree86/dixmods/glxmodule.c | 1 +
> hw/xfree86/meson.build | 1 +
> hw/xquartz/darwin.c | 4 +-
> hw/xwayland/Makefile.am | 1 +
> hw/xwayland/meson.build | 1 +
> hw/xwayland/xwayland.c | 2 +
> include/glx_extinit.h | 5 +-
> 23 files changed, 359 insertions(+), 392 deletions(-)
>
>
xorgGlxThunkRequest should be calling addXIDMap and removeXIDMap, not
the internal handlers. The default branch there may need some additional
attention if it would handle any requests that create or destroy resources.
And, in answer to the question next to xorgGlxThunkRequest, those could
indeed be generated. The generate_dispatch_stubs.py script in the
libglvnd repo only generates the core GLX requests, but it should be
able to handle of those GLXVendorPrivate requests as well.
-Kyle
More information about the xorg-devel
mailing list