.comment: 86ing XFree? - page 2
When Good Code Goes Goofy
Which is why I was particularly taken last week with the news that KDE's Simon Hausmann had managed to get Konqueror, the superb file manager and web browser from KDE2, ported to QT/Embedded such that it could work on one of those dinky handhelds. This is an interesting experiment, though an exercise that I don't see resulting in any real benefit to anyone. But there's one dandy aspect: it wasn't running atop XFree86.
The Linux kernel has gradually assumed some of the duties that were once the exclusive province of XFree86. The frame-buffer support in the 2.4.0-test series of kernels works reliably, allowing the kernel to switch into graphical mode at boot time. There is direct rendering support available in the kernel for some video cards, and the video modules for those cards are now part of the kernel source.
Might it be that one could cobble together a system such that the kernel takes care of all the hardware-based graphical duties, such that one could boot Linux with frame-buffer support enabled and switch directly into a window manager and desktop, bypassing XFree86 entirely?
Alas, no, or at least not in any useful way, according to people who have actually been elbow-deep in it.
some problems," says Petr Vandrovec, whose work is evident in
the kernel's frame-buffer code. "First one, biggest, is that X
are not only access to hardware, but also tons of other code, which
does tons of other operations (just look into list of x11perf
operations). Accelerated circles, squares, letters, images....X also
manages windows itself (in cooperation with windowmanager) and so on.
Get XF4.0.1 sources, strip out
xc/programs/hw/xfree86/drivers--and everything left is just
additional code, which you must use (or write from scratch) to
achieve full XF functionality.
"Second one is that currently framebuffer interface does not provide any accelerated API, it is just console replacement. There were some discussions whether to create universal kernel API for drawing rectangles and moving screen data around, but it is currently shot down."
One salivates over the possibility, if for no reason other than the fact that it could provide an elegant, simple, resource-friendly was of handling graphics. But not having been party to the whole discussion, I don't know the full breadth of the argument against this approach. One thing that comes to mind is that this might make it difficult for applications programmers to produce code portable to systems other than Linux.
"My current opinion is that if you want just some graphics, use framebuffer," Petr explains. "If you want fast graphics, use framebuffer together with DRI. I use fbtv (tv), fbi (image viewer) and vi on text console and I'm happy. There is also some framebuffer web browser somewhere, but I do not use it.
"Third one are existing application base. If you want to get xlib, and all xlib based apps to work, you have to implement X almost completely. For sure writing X again from scratch is really good idea, but it could take couple of years to get it to some usable state."
Well, yes, this could be a problem. The potential payoff, though, could be enormous. Want to see those games really scream?
"But for sure if you want to create some embedded system, using framebuffer is much more convient than using X. On the other side, with X you just put one window here, another there; with framebuffer you have to code how to draw line, circle or letter first, so it tooks much more time. Like the difference in programming in C and in assembler. I think that for example all apps which use DGA (== all 3D games?) should be easily portable to framebuffer+DRI."
Simon Hausmann, too, notes that while circumventing XFree86 is possible, it brings disadvantages except in embedded systems, where applications are more likely to be limited and therefore easier to manage.
"Well, it shouldn't be hard to compile and run kdelibs with Qt/Embedded, just using libICE from X11 for dcop communication," he said. "I haven't tried it, yet, but I'm not sure if it is worth it. I mean: You completely lose the capability to run any other X11 applications, and also stuff like OpenGL.
"The only gain I would really see is: Antialiasing and Alpha-Channel support. Given recent X11 developments I'm more than optimistic that we'll get it on many X11 desktops soon :-)
"What would be lost: The thing I would miss most is the network transparency!
"Although Qt implements a windowing system which allows multiple Qt processes sharing the same Qt/E display over a socket in /tmp it wouldn't work over networks, as Qt/E additionally uses shared memory. Hm, well, perhaps it _could_ be implemented, but then you end up in re-inventing X, while not having half as many applications for it :-}
"Well...hmm...but perhaps someone should just try it :-)"
Such thoughts make the heart sing, don't they? The sheer, delightfully audacious "let's see if we can do it" approach that is the motivating force behind so much in Linux development. But I digress.
As I thought about all this over the last few days, I turned, as I do often, to Michael Meding, who just seems to know stuff. And as usual he did this time, too, pointing me to the Berlin project. I poked around that organization's pages, coming close to drowning a couple of times--this stuff is way over my head in a lot of places--but the sense I got was that this is a project with some tremendous potential, that draws on ideas that have been around for more than a decade, though this particular incarnation has been around only (only?) since 1997. The idea is to produce a fast, light, easy-on-resources graphical engine. Right now they have code that works, but they do not have applications for it, and it is certainly not a drop-in replacement for XFree86, though there has been talk of a compatability layer being developed. Indeed, it brings along its own widget set and seems to want to replace XFree86, window manager, desktop, and so on. Not a bad idea, but also not exactly what I was looking for just now, though the mind does delight at the notion of some existing window manager and desktop system being ported over.
After all this, my speculations and questions had produced a happily irreducable conclusion: XFree86 is not the best of all possible ways of producing graphics on a Linux machine--but the best of all possible ways of doing that does not yet exist.
- 1Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 2Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 3Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 4Linux 4.6 Charred Weasel adds USB 3.1 Support
- 5Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader