Yes it is a complex subsystem, but wherever the code is it will be
complex, and could hang your machine. So keeping it out of the kernel on
stability grounds doesn't hold much water. (How many times has X frozen a
machine even though it lives totally in userspace?)
Also you may have misunderstood my "centralized" item: putting output
configuration into the kernel is not about pushing things to distros in a
unified way. It's about putting the code in one place that allows all
applications to benefit. In an X-mode setting world, any app that wants
full control of outputs has to be an X app. If the code is in the kernel,
any app or library can make use of it, and some already have. Projects
like Wayland and standalone EGL libraries are made possible with kernel
based memory management and mode setting. I mean, who wants to rewrite
mode setting for every chip and every type of application out there?
You're right about graphics being an oddball though: certain bits of it
belong in the kernel and certain bits in userspace. I think the line
should be drawn between memory management + mode setting and command
generation. The former needs to be in the kernel so that apps don't stomp
on global GPU state, while the latter is very complex and generally
involves mapping APIs like GL and Cairo to a specific set of GPU
instructions, so is well suited to userspace libraries.
More generally, there's a dogma out there that says "if it can be done
outside the kernel, it *should* be done outside the kernel". But such a
rule is far too inflexible. In many cases doing something in the kernel
provides such broad benefits that though a given subsystem could be
implemented differently, doing it in the kernel really is best (for
example network drivers or system checkpointing). I think kernel mode
setting and memory management clearly fall into that category as well,
since although the systems are complex they provide very widespread
benefits, and keep much of the hard stuff in one place where it can be
fixed once and used by many.