> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:43 EST