lkml.org 
[lkml]   [1999]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean