[lkml]   [2004]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ioctl number 0xF3
    Arjan van de Ven wrote:
    > On Sat, May 22, 2004 at 02:39:47PM +0200, Thomas Winischhofer wrote:
    >>I intend using them for controlling SiS hardware specific settings like
    >>switching output devices, checking modes against output devices,
    >>repositioning TV output, scaling TV output, changing gamma correction,
    >>tuning video parameters, and the like.
    > That doesn't in principle sound SiS specific. Sure the implementation will
    > be but the interface?

    Don't get me wrong.. did you ever write a driver for graphics hardware?
    Different graphics cards have widely different features and
    restrictions, for example what output devices are supported and which
    output devices can be "mapped" to what CRT controller, what modes are
    supported on what output device if it's mapped to what CRT controller,
    whether the CRTCs really are independant or of they need "cooperation"
    in specific modes (because one of the CRTCs is crippled like in my case)
    etc etc etc.

    Not that this would be much of an excuse, but not even the Windows folks
    have a unique interface for vendor specific things, like setting up dual
    head, video mirroring, etc. IMHO a generic interface will 1) force
    restrictions to supported features, 2) be bloated with stuff that will
    require a ton of checks and thereby lead to a requirement of smart
    userland applications that from the beginning will need to know about
    the specific hardware and its features - again.

    What we are talking here are no essential things. What I want is simply
    a few ioctls for mostly (but, granted, not exclusively) very hardware
    specific things (at least as regards the possible arguments to the
    various ioctls).

    >>And rest assured, they will be 32/64 bit safe. Not sure what you mean by
    >>"ioctl interface" here but have a look at the Matrox framebuffer driver
    >>which uses some 'n' ioctls for similar stuff (which in that way do not
    >>apply to the SiS hardware which is why I can't reuse them).
    > Ok this is exactly the point I was trying to make. Would it be possible to
    > have the "new" ioctl interface be such that they CAN be used by both matrox
    > and Sis ?

    The framebuffer drivers are - I am trying to say this nicely - a chaos
    as regards custom implementations for ioctls and extensions to the
    standard fb ioctls. I do not intend to wait until all the
    maintainers/authors agree on a unique interface which they haven't been
    able to in years.

    These ioctls I intend to implement (and partly already have implemented)
    are nothing userland will need to know much about. They are going to be
    used by stuff like DirectFB (which needs a driver for specific hardware
    anyway), my config tool and the X driver (in order to restore the
    hardware state properly, including changes done during the X server
    session while switching back to another VT).

    Is 64 out of, what's that, 65536 too much to ask? Well, I could live
    with 32 as well...


    Thomas Winischhofer
    thomas AT winischhofer DOT net
    twini AT xfree86 DOT org
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.023 / U:41.688 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site