> It *has* to be this way. Userspace code cannot just go around
> blindly reconfiguring the hardware out from under the kernel drivers. You
> can argue forever about what should and should not go into the fbdev
> drivers (acceleration, mode timing calculations, etc) but the ability to
> lock framebuffer and MMIO region accesses and maintain hardware state
> **MUST** be present in the kernel drivers, and **ALL** userspace code
> **MUST** conform to the kernel's way of doing things.
So here's an idea. Would this work? Would it be simple enough? (Has
someone already done something similar?)
* Invent some sort of data structure able to describe what you need to do
to set the hardware to the current display mode, for any display mode on
any card. I suspect a sequence of I/O or memory accesses with limited
timing info might go a long way there. Of course, if hardware is so brain
damaged that it's impossible to figure out how to talk to (some parts of)
it at all without knowing all prior history, you have a problem, but
that's *really* crappy hardware. I think we can ignore that mess.
* Possibly add info what this does to some critical address parameters you
need to keep track of. Such as, "after this is done, register X is found
at address Y."
* Maybe we also need minimal info on how to return the hardware to a
"simple" default state?
* Have an ioctl that says "here is a data structure describing the
hardware state I need. Please activate." Oh, and one to get the previous
state.
* Have the kernel switch to whatever is the current state of the hardware
on the new console when the console is switched.
This would mean that user code does not need to rely on hardware registers
to find out what state the hardware was in when it started, and also that
getting to a sane mode would be a lot easier after a user program crash.
This would not, of course, mean calling the kernel for any pixel you want
to draw - *only* for mode changes.
Also, it would *not* mean needing a different driver for any video card on
the market.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/