> I have to disagree. First, it is not only the mode setting that goes
> into the kernel. And mode setting is really the last thing that needs to
> be there. You certainly do not have multiple applications trying to set
> different modes _at the same time_.
No, but that's not the issue. You can search around and look for the
motivations behind putting mode setting into the kernel, but they come
- panic/oops (yes this is important, don't know why you disagree)
- X independence (this is pretty big, especially on special purpose
- user experience (eliminating any unnecessary mode changes is a pretty
- fbdev APIs aren't suitable for most current devices
- centralizes control over hardware (no more fighting drivers)
- improves suspend/resume speed & robustness
Simply saying that "The kernel and X also never access the hardware at the
same time" doesn't make it true; in fact that very issue has been a big
source of bugs in the graphics architecture for a long time now.
And your comment about polling for display changes doesn't account for
power savings. Polling is a terrible thing when you're running on battery
and want to keep your CPU asleep as much as possible. And hotplug
interrupts are required for certain new output types to work correctly at
all (like displayport).
As for uvesafb/v86d I can't imagine why you'd want to depend on that
configuration. The VESA interfaces make you totally dependent on the
VBIOS implementation, which isn't actually used much by real drivers, and
so is often broken or missing modes for your hardware, and limits what you
can do quite a bit. Native drivers are simply much more suited to real
work than anything VESA/VBIOS based.
So overall I think you're ignoring a number of real issues with the
current design; in-kernel memory management and kernel based mode setting
should have happened long ago.