Messages in this thread | | | Date | 09 Jan 1999 13:36:00 +0200 | From | (Kai Henningsen) | Subject | Re: short display with 2.1.132-ac3, matroxfb and XF86_SVGA 3.3.3 |
| |
taylorj@ecs.csus.edu (Jon M. Taylor) wrote on 05.01.99 in <Pine.HPP.3.91.990105135743.1040A-100000@gaia.ecs.csus.edu>:
> 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/
| |