[Linux-fbdev-devel] re: James's new API post

[Sottek, M. J <mat...@in...>]

>So what I need is the latest drivers from people so they can be
>ported over. I also want to>know what people needed for the fbdev
>layer as well as the input layer. I see some email about DDC
>support for example. Please let me know what you need. Thank you. 

James,
  Sorry to get such a late jump on giving input, but we can only
assume to have plenty of time before 2.6.x. Here is some input.

#1 Monitor timings/ mode setting is quite poor in 2.4.x. I haven't
looked at what you have so far but here are some points that
should be considered.
  * Monitor timings are something that should be determined between
    the driver and the monitor. Users and higher level api's should
    not have anything to do with this. The driver I am working on
    now has a fixed set of timings that it supports. When set_var
    requests a new mode the closest match is found. It is key to
    let the driver have it's own mode table.  I also will eventually
    parse EDID to add modes to my tables is the monitor needs
    something special that I can support. To aid in code reuse you
    should just provide a function that parses EDID data into an
    edid data structure (Something like this was discussed a few
    day ago)

  * The user api needs to move away from timings all together.
    The user should be able to select a refresh rate from a provided
    list (negotiated between monitor and driver). It won't be long
    before timings are no longer used in hardware, and the only thing
    left to adjust will be refresh.

#2 Complete separation of data structures. The var and fix structures
   need rework badly. All things that are not explicitly needed by
   a higher level api should not be in there. Those things belong
   in the driver private data structures (It doesn't matter that
   nearly everyone will have an mmio pointer, it doesn't belong in
   a public data structure)

    * The software fallback functions should be set up in a more
      explicit way to keep these pointers out of other people's hands.
      For example, the console functions (putc, putcs etc) should
      be done something like this.
      fb->console_ops = create_generic_console_ops(base,pitch,depth);
        or use a hardware specific set as you would today.

    * I've seen mention of this in some posts but clearly the fb
      driver should not be tied in any way to the console. My driver
      has all the hardware functions totally independent of the
      interface. The fbcon is an interface provided on top of a
      graphics driver. They are currently way too connected, and
      in my opinion this is one reason that a lot of the X & DRI
      developers are not interested in combining efforts. The
      result of console + graphics driver looks nothing like a
      graphics driver and isn't appealing as a base driver to expand
      on.

#3 Don't try to wrap everything in a hardware independent API. Some
   hardware is going to support things that others don't. Take for
   instance "mirroring". The i810 can do this on the CRT + a TV or
   FP depending on what is connected. But the modes that can be
   supported are very limited and mucking up a mode API with this
   type of thing only makes a mess for everyone. Better to allow
   a hardware specific switch to alter the output device and just
   allow the driver to limit the available modes based on this
   hardware specific switch. In MS this is like the display
   properties dialog. The advanced options are dialogs written
   specific for the hardware. We could just have a set of guidelines
   for altering hardware specific configurations so that a command
   line utility or GUI could be made to control them.

#4 It would certainly be nice to combine the drm code into the fb
   code. NOTE: I wouldn't want to do this until the drivers are
   organized like graphics drivers instead of consoles. There is
   too much overlap now and it would just make for a really large
   mess. Most of the dri enabled X drivers already have a different
   code path for driver init than without dri so making the X servers
   use fb+dri wouldn't be a such an issue. The main goal here would
   be to eventually have a graphics driver setup that is easy to
   configure. 1 kernel driver + 1 X driver == success. not 1 vga
   driver + 1 fbcon driver + 1 drm driver + 1 X driver.

This is enough for discussion now,
-Matt