> X.org has gone modular at some point and that does help -- compared > to monolithic X servers as they used to be -- with computers which > are not the richest in resources, [...]
I don't quite see how; I'd rather have a non-modular server for my hardware than a modular server plus modules for my hardware. I really dislike the current trend to dynamically loading everything in sight; it is a security disaster waiting to happen and it is bloat. And the current trend to expect the X server to run as root, even on hardware without the peecee video disaster to excuse it, is just insane. (For example, on SPARCs I found the server trying to do its own sbus enumeration, something it has no business going anywhere near, presumably because someone thought it was a sane way to "port" code that did PCI enumeration.) On hardware where it works, I still use X11R6.4p3. But, well, if you find it helps you, whatever works. I hold my nose and use X.org servers on a few peecees that X11R6.4p3 doesn't support. (I do insist on fixing the cursor extension bug, though; it's annoying. Not that older X servers are perfect either; I found a crasher bug in wide line drawing the hard way....) >> But, yes, consider it a warning to look into it before just assuming >> that the support will (a) be there and (b) be non-bitrotted. [...] > Honestly I'd expect dumb frame buffer support to just work, as there > isn't much there to break or maintain. You'd think so, but in a day when "everything" has a (by our standards) high-end 3D rendering engine in front of it, it would not surprise me if dumb memory-mapped framebuffer access had bitrotted. Indeed, one of the things I fuzzily recall is that X.org requires the device-dependent layers to support some kind of acceleration framework (the alphabet soup that comes to mind is "XAA", but I could be misremembering). > A pixel array and a RAMDAC handled entirely by the kernel via generic > calls isn't rocket science after all. No, it isn't. But apparently modern X has advanced enough that it can no longer do some things X Consortium sample servers from three decades ago could. It's a bit like monitors: apparently flatscreen technology has improved to the point where monitors can no longer do what CRTs from multiple decades ago did routinely. > So if they broke some generic parts (DIX) by the lack of due > attention, then I'm really concerned. I don't think they did, but AIUI their DIX code expects the DDX code to support a bunch of cr...er, stuff, that has no relevance if you don't have a 3D rendering engine in your hardware, which may well mean that the dumb-framebuffer DDX implementations have been thrown away because they no longer work with the modern DIX code and nobody stepped up to continue twisting them into nastier and nastier pretzels to accommodate more and more DIX-layer peecee-world assumptions.... Fortunately, old X still works as well as it ever did. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B