[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BK PATCHS] fbdev updates.

    > That's fine for me, but I'd expect other people to find problems with it.
    > Would it not be better to allow drivers to decide which type of blanking
    > they want to use depending on the current parameters set via the set_par
    > callback? Only the drivers themselves know what their fb_blank method is
    > capable of performing.

    Yes the drivers should always have priority. The other stuff is there
    only if the drivers have no power management of any kind. I leave it up to
    the driver write to implement a fb_blank function that handles different

    > I think with the above you'll inadvertently encourage drivers to mundge
    > the fb_blank function pointer in their set_par method.

    Why would you have to mess around with the function pointer. Couldn't you
    just set a flag or fill in a hardware dependent struct that defines what
    states are possible for hardware power management. Then when fb_blank is
    called it uses the information to decide which action to take. I think
    this approach is much more powerful than using a single can_soft_blank
    flag. I like to get ride of can_soft_blank and allow the driver to decide
    on this stuff itself.

    > There is also the argument about wanting soft blanking, but hardware power
    > saving.

    Hm. True unfortunely the fbdev layer lacks handling details like that. The
    console system is even worse. This is why a single flag like
    can_soft_blank can actually be a limitation.

    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 13:30    [W:0.020 / U:1.260 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site