Messages in this thread | | | Date | Fri, 18 Oct 2002 10:27:59 -0700 (PDT) | From | James Simmons <> | Subject | 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.
- 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/
| |