This Time Self-Hosted
dark mode light mode Search

If you want to bitch, get your b****y facts straight at least

So already two fellow devs bitched at me because I enabled the xcb plugin in xine-lib-1.1.9 by default. Enabling those by default was not a fluke, and was totally intentional. And I probably know way better than they do what the USE flag does for that package.

First, the reason why xcb is enabled by default is that the next version of Kaffeine, as well as KDE4, will require XCB support. This because it’s the only way to be able to embed a xine-lib frontend inside another application (Kaffeine inside Konqueror for instance), without having to deal with two Xlib connections. Expecting more than a couple of users wanting to check out KDE4 in the near future, I think that enabling xcb by default is a good idea; I’d rather enable xcb support in Kaffeine by default too, as without xcb, opening a video in Konqueror often leads to the browser to crash, together with all the tabs.

Second, enabling xcb in xine-lib will not break non-xcb-using frontends. Christoph wrote separate plugins, for XShm over XCB and Xv over XCB; they use a different setup than X11 plugins, so the frontends will know what they can load and what they cannot. So an XCB-based plugin (and I mean xcb, not libX11 wrapping XCB) will use the XCB plugins, and a “classic” frontend will use the libX11-based plugins. Just like fbxine (the framebuffer xine frontend) will never try to use an X11 plugin, or aaxine will never try to use the OpenGL plugin.

Third, libxine does not get any linking to libxcb directly; and as the xine plugins does not install any .la file, the libxcb dependency will not be carried around.

Fourth, even if Kaffeine had xcb enabled by default, it does not install any library that other packages link to (well beside kaffeine-mozilla-plugin, but I don’t think if that’s actually developed at all), so libxcb can’t be carried around there either.
The only way libxcb can be carried around is by enabling it in libX11.

Fifth, libxcb and libX11 has no common symbol: you can load those on the same address space without causing any collision. libxcb was designed that way.

Sixth, you can have in your system both libxcb and libX11, they don’t collide, software using libX11 won’t magically be ported to libxcb, otherwise we’d be all happy.

Seventh, you can use at the same time libX11 and libxcb applications. This is the nice thing about X11: it’s a network-oriented protocol, so as long as you use the same protocol, you can mix and match client implementations of it. You can easily run an x86 Linux application using libxcb with a SPARC Solaris X11 server as DISPLAY.

Eighth, you don’t need libX11 built as a libxcb wrapper (USE=xcb for libX11) to have xine-lib built with USE=xcb. The plugins are separated, which is the whole idea of it. You could as well have a frontend that only uses libxcb, without libX11 at all.. I was actually going to work on a similar port of xine-ui.

Ninth, you don’t even need libX11 built as a libxcb wrapper to run Kaffeine (which uses libX11 through Qt) with xcb output. libxcb was designed this way; you have two connections between the client (Kaffeine) and the X11 server, one for libX11, one for libxcb. Of course if you have libX11 built as a wrapper for libxcb, you’d get just one connection, and the code from libX11 would be disappearing. But this does not mean that a pure libX11 would break Kaffeine; it would just use more resources. On the bright side, it wouldn’t crash your Konqueror with 20 tabs open if you end up in a site that has embedded video.

And for what concerns “installing libxcb without reason”, the reason I gave you already, it’s not like I’m forcing it on anybody, the xcb USE flag can still be disabled if you don’t want to use it. It’s no more and no less as any other default USE flags. Or should I say that having the cairo USE flag enabled by default in the profile is making me install cairo without reason, as I don’t want to use it?

(And no, I don’t want cairo disabled by default; I actually have the cairo USE flag enabled in my system, and I wanted to look at cairo more deeply one day, I just wanted to take an example from some GNOME-needed technology, just because it seems to me like at least one of the two complainers might not be interested in xcb because it’s simply used by KDE applications at the moment.)

(Actually, gxine in Mercurial should also supports XCB, because, mind what, it works also better…)

P.S.: if you just say “it’s broken and I don’t want to try again”, then I’m just going to ignore you. From now on. Forever.

Comments 8
  1. Very nice article. Is there some documentation about xcb available online? I only remember that it made problems in the beginning times when support appeared. Don’t know wheter I’d gain anything by enabling it now…

  2. So if I understand this correctly, the use flag on xlib enables a sort of proxy to translate “normal” x11 to xcb? And this is in fact causing issues with java for example?

  3. The protocol is always the same, xcb simply has a nicer interface to the X11 protocol than Xlib (libX11).libX11 built with xcb USE flag implements the Xlib interface on top of xcb calls. XCB interface is asynchronous and has better locking capabilities, so it’s a gain in cleanness and performance.Unfortunately Java has a very very very old version of libXinerama built-in, which does not perform locking correctly. While libX11 (Xlib) always ignored that problem, XCB asserts out. The problem is that a mutex that is not held is being released, usually.So the problem lies in Java’s code, libXCB only shows it as a real problem.But again, xcb on xine-lib will _never_ break Java nor anything else.

  4. So if you use Java it’s a bad idea to enable it on libX11 unless it’s fixed in Java. Let me guess… it’s unlikely that Java will be fixed soon?

  5. No, it’s still a good idea to use xcb.Just use the environment variable LIBXCB_ALLOW_SLOPPY_LOCK=1 for your java apps.

  6. And it’s fixed already in Java: OpenJDK has it fixed for a while now as they don’t use an internal copy of libXinerama anymore, but link the system’s one (i’ve been sending them patches on similar ideas for a while when OpenJDK first started, that one was taken more to the extreme that I asked 😛 – I simply suggested a switch to use internal or system – I’m happy with the result).

Leave a Reply to Ewan MarshallCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.