[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.053 / U:1.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site