From: Russell K. <rm...@ar...> - 2002-10-18 18:33:03
|
On Fri, Oct 18, 2002 at 10:27:59AM -0700, James Simmons wrote: > 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. The drivers don't have priority though. You call set_par, and then wander off into the internals of fbgen.c to set can_soft_blank youself, without giving the drivers any look-in to set that correctly. > > 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. Well, it needs to be fixed. We've lost functionality that was present in 2.4, and therefore I call it a bug. -- Russell King (rm...@ar...) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html |
From: James S. <jsi...@in...> - 2002-10-18 21:31:36
|
> > 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. > > The drivers don't have priority though. You call set_par, and then > wander off into the internals of fbgen.c to set can_soft_blank youself, > without giving the drivers any look-in to set that correctly. Your right. That is a bug from the old fbgen code. Since few driver used the old fbgen code it never appeared. I suggest we remove can_soft_blank and just test to see if the function pointer exist for fb_blank. If it doesn't then we can resort to other tricks in suggested in the ther email. |
From: Russell K. <rm...@ar...> - 2002-10-18 21:37:17
|
On Fri, Oct 18, 2002 at 02:24:48PM -0700, James Simmons wrote: > Your right. That is a bug from the old fbgen code. Since few driver used > the old fbgen code it never appeared. I suggest we remove can_soft_blank > and just test to see if the function pointer exist for fb_blank. If it > doesn't then we can resort to other tricks in suggested in the ther email. Ok. What about the case where you're running in true colour / static pseudo colour, and can't blank the palette, but do have a fb_blank method to handle the direct colour / pseudo colour case? -- Russell King (rm...@ar...) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html |
From: Geert U. <ge...@li...> - 2002-10-22 17:15:22
|
On Fri, 18 Oct 2002, Russell King wrote: > On Fri, Oct 18, 2002 at 02:24:48PM -0700, James Simmons wrote: > > Your right. That is a bug from the old fbgen code. Since few driver used > > the old fbgen code it never appeared. I suggest we remove can_soft_blank > > and just test to see if the function pointer exist for fb_blank. If it > > doesn't then we can resort to other tricks in suggested in the ther email. > > Ok. What about the case where you're running in true colour / static > pseudo colour, and can't blank the palette, but do have a fb_blank > method to handle the direct colour / pseudo colour case? That's what the return value of the fb_blank() function is for: to indicate whether it handled the blanking or not. If not, the upper layer has to take care of it. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: James S. <jsi...@in...> - 2002-10-18 17:23:41
|
> So the generic part of the code should behave like this: > > if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) { > /* use hardware blanking */ > } else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR || > info->fix.visual == FB_VISUAL_DIRECTCOLOR) { > /* use software blanking */ > } else { > /* no blanking possible, except for filling the screen with black, which > is not appropriate (unless we save/restore the contents?) */ > } > > Is that OK for you? I was thinking more like if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) { /* use hardware blanking */ } else if (info->var.accel_flags) { /* Use hardware fillrect to blank the screen */ info->fbops->fb_fillrect(info, whole_screen); } else { /* Nothing avaiable. Use set the colormap to black */ } What do you think? |
From: James S. <jsi...@in...> - 2002-10-18 17:12:41
|
> I'm not sure this "set var" business has been thought out as much as it > should be. <snip> I see it coming. With the next set of changes it will be possible to have fbdev with the VT system. So I have been putting into place the ability to power down the framebuffer via the ioctl. So I want the flow to be with fbcon from high level console to fbcon layer to fbdev driver. Without fbcon to go from userland to the fbdev driver directly. Also we have mode changing. Soon I will add hooks to the VT layer to allow use to change a single VC via stty. VT_RESIZE can replace the current method of changing the size of all VCS instead of the fbdev layer doing it. So you will see the necessary changes to handle all this. |
From: James S. <jsi...@in...> - 2002-12-06 21:26:09
|
Hi!!! After much work and many fixes the final api for the framebuffer layer is complete and alot of new functionality has been added. Several drivers have been ported. Still several more to go. Could you grab the latest changes from bk://fbdev.bkbits.net/fbdev-2.5 Please sync it up to your latest tree. Thank you. |