[Linux-fbdev-devel] Re: [BK PATCHS] fbdev updates.

[James S. <jsi...@in...>]

> 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
cases.

> 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.