Re: [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
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.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf