You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Composite's overlay window is a normal xproto Window that needs special destruction. Also, the server allocates the XID and returns it in a reply. The current structure expects requests without a reply.
+ ("composite", &[+ /* This request has a reply (and the server allocates the XID!)+ * Also, this wraps an existing resource (Window), but needs a special free.+ ResourceInfo {+ resource_name: "xproto:Window",+ create_requests: &[+ CreateInfo {+ request_name: "GetOverlayWindow",+ created_argument: "window",+ },+ ],+ free_request: "ReleaseOverlayWindow",+ },+ */+ ]),
dri2's CreateDrawable also uses xproto::Drawable (hm, I guess this one should even be easily implementable.. I just have no clue about dri2 nor if anyone would still use it)
+ ("dri2", &[+ /*+ * DRAWABLE more or less comes from xproto?!?+ ResourceInfo {+ resource_name: "DRAWABLE",+ create_requests: &[+ CreateInfo {+ request_name: "CreateDrawable",+ created_argument: "drawable",+ },+ ],+ free_request: "DestroyDrawable",+ },+ */+ ]),
GLX has lots of candidates, but I couldn't find a spec and I doubt anyone uses this extension with/from Rust. My guesses: CreateGLXPixmap, CreatePixmap, CreateNewContext, CreatePbuffer, CreateWindow
SHM has a CreateSegment request that creates a Seq. However, this request has a reply with an FD containing the segment. "has a reply" does not match the current structure of these wrapper objects at all.
xf86dri just uses CARD32 instead of a proper resource typedef (same for xprint)
This is follow-up to #78 / #629. That PR only implements the "easy" part. However, there is also:
CreateDrawable
also usesxproto::Drawable
(hm, I guess this one should even be easily implementable.. I just have no clue about dri2 nor if anyone would still use it)CreateSegment
request that creates aSeq
. However, this request has a reply with an FD containing the segment. "has a reply" does not match the current structure of these wrapper objects at all.CARD32
instead of a proper resource typedef (same for xprint)The text was updated successfully, but these errors were encountered: