GNOME Bugzilla – Bug 730475
xcb: Add RENDER support
Last modified: 2014-06-12 22:06:48 UTC
Add RENDER support
Created attachment 276907 [details] [review] Add RENDER support
I'm not sure we should be adding a bunch of X bindings to valac with Wayland and Mir coming. Maybe we should use the vala-extra-vapis repository for this instead? That said, I'm really not very familiar with the details of what exactly wayland/mir cover... if we're expected to keep using xcb this probably makes sense.
Correct, in the future Wayland/Mir world the XCB bindings are not required but... - If we're going to provide any XCB bindings (i.e. xcb.vapi) then we should provide the extensions too. No modern X system works without at least some extensions. - It seems unlikely that there will be any changes to the extensions since we are migrating to newer systems so the XCB API is very unlikely to have any changes. Note I found a bug in the XCB api but upstream (wisely) wont fix it because this would break API for the current XCB consumers. These points mean the .vapis shouldn't require any ongoing changes (unless they are incorrect). - While X seems likely to become a historical footnote we will like with X for some time. X based systems like Ubuntu 14.04 will be in active use until 2019 and I imagine the RedHat desktops for even longer. Also, even in the new display stacks we will need to provide legacy X interfaces for some time. In conclusion, I think we should either provide all of XCB or punt the whole lot to vala-extra-vapis.
Created attachment 277667 [details] [review] Add RENDER support Fix unref
(In reply to comment #3) > In conclusion, I think we should either provide all of XCB or punt the whole > lot to vala-extra-vapis. We can't remove the existing bindings, that would break backwards compatibility. I don't see why we can't just provide the core xcb binding and put the extensions in vala-extra-vapis. By my count, there are 32 of the things: xcb-composite xcb-damage xcb-dpms xcb-dri2 xcb-glx xcb-randr xcb-record xcb-render xcb-res xcb-screensaver xcb-shape xcb-shm xcb-sync xcb-xevie xcb-xf86dri xcb-xfixes xcb-xinerama xcb-xkb xcb-xselinux xcb-xtest xcb-xvmc xcb-xv xcb-cursor xcb-aux xcb-util xcb-atom xcb-event xcb-image xcb-keysyms xcb-renderutil xcb-ewmh xcb-icccm
I think it would be unexpected for users to look in a separate package for a large part of the XCB functionality. Your call - if you don't want XCB extensions in core Vala then close this bug WONTFIX.
At this point, probably it's even better to move xcb itself out of vala, don't know how to do it by the way. Having extensions in a separate repository means incompatibilities with xcb shipped with vala.
I agree that it's sub-optimal, but I don't think it's necessarily a bad way to go. I would prefer to keep the bindings together, but 32 new bindings for a library that is basically being deprecated is kind of insane. When bindings are added to valac we have to maintain them indefinitely, and keep any changes backwards-compatible. In my mind that is the main advantage of the vala-extra-vapis repository; it's meant to be used as a submodule or subtree, or for people to just copy the bindings they need. There are no backwards compatibility guarantees. There are some of examples of bindings moving out of vala in favor of distributing them with the library they bind: librsvg, gnome-keyring-1, and gedit. What we've always done is just add a Deprecated annotation which informs people of the change, but not actually remove the bindings from valac. I don't think we've ever removed bindings in favor of a third-party source, but it's certainly feasible. That said, I don't think it's necessary to remove the xcb bindings, at least for now. It's an option if we need to make backwards incompatible changes in the future. My vote would be to put the new xcb-* bindings in vala-extra-vapis or create a new repository for them, but keep xcb as-is, at least until we actually want to make backwards-incompatible changes, at which point it can move to wherever the xcb-* bindings are and we can deprecate the ones shipped with vala. (In reply to comment #7) > At this point, probably it's even better to move xcb itself out of vala, don't > know how to do it by the way. I'm not sure what you mean here... Are you saying that you think this is what we should do, or this is what we should do if we decide not to add new xcb-* bindings to vala? > Having extensions in a separate repository means incompatibilities with xcb > shipped with vala. Not necessarily. Or do you mean it allows for such incompatibilities, assuming it also includes xcb itself?
Move xcb.vapi in the vapi-extras. I don't know what's the best way to achieve this: deprecate it first and add it to vapi-extras? If extensions are in vapi-extras, and xcb.vapi in vala tree, there may be some incompatibility: e.g. extensions use a struct that is not present in xcb.vapi distributed by linux distros.
Okay, so the question is vala-extra-vapis or somewhere else? I'm happy to add them to vala-extra-vapis, but Robert, if you want to create a new repository specifically for xcb that would make sense too. Also, CC'ing Sergio Costas, since he may be interested in this as well.
vala-extra-vapis seems the most appropriate place to me. This will also require cairo-xcb to be moved.
You also included randr in this patch... should I just ignore that, or is it newer than the version from bug #730348?
Ah, sorry, it's the patch in bug #730348 which includes both. The question remains basically the same, though... which version should I use?
RANDR requires some types from RENDER - so the RANDR patch contains just those. Probably best to commit all of RENDER first and then commit the RANDR patch without those RENDER changes.
commit 461858469bbab3f2f66b7b164be2aaa7beb9afaa Author: Robert Ancell <robert.ancell@canonical.com> Date: Thu Jun 12 15:03:32 2014 -0700 Add xcb-render https://bugzilla.gnome.org/show_bug.cgi?id=730475