From: Juergen B. <jue...@kr...> - 2007-01-31 08:14:34
|
Hi all, is this list alive? Currently I'm trying to develop a accelerated framebuffer driver. My own imageblit and fillrect functions are working now. But my copyarea function will never be called. I thought it will be called to scroll the screen. But it seems not. Does anybody know what event triggers this function? If I'm on the wrong list, please give me a hint, what's the correct group for this kind of question. Thanks in advance Juergen |
From: Juergen B. <jue...@kr...> - 2007-01-31 10:10:56
|
Hi Petr, On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote: > > is this list alive? > > More or less. Less... Seems so... :-) > > Currently I'm trying to develop a accelerated framebuffer driver. My own > > imageblit and fillrect functions are working now. But my copyarea > > function will never be called. I thought it will be called to scroll the > > screen. But it seems not. Does anybody know what event triggers this > > function? If I'm on the wrong list, please give me a hint, what's the > > correct group for this kind of question. > > fbcon believes (quite correctly) that repainting screen is faster than > doing copyarea because on unaccelerated driver reads from framebuffer > are 4-10 times slower than writes... > > Take a look at updatescrollmode() in fbcon.c - you must persuade this > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW. FBINFO_READS_FAST > should be sufficient - or you can report fast bitblt + fast panning, or > fast bitblt + slow imageblit. If you report no panning + fast bitblt + > fast imageblit, redraw is used :-( Uhhh, sounds complicated. All right, I will take a look into fbcon.c. Thank you. Juergen |
From: James S. <jsi...@in...> - 2007-02-06 21:09:10
|
> On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote: > > > is this list alive? > > > > More or less. Less... > > Seems so... :-) The main list is linux-fbdev-devel. > > > Currently I'm trying to develop a accelerated framebuffer driver. My own > > > imageblit and fillrect functions are working now. But my copyarea > > > function will never be called. I thought it will be called to scroll the > > > screen. But it seems not. Does anybody know what event triggers this > > > function? If I'm on the wrong list, please give me a hint, what's the > > > correct group for this kind of question. > > > > fbcon believes (quite correctly) that repainting screen is faster than > > doing copyarea because on unaccelerated driver reads from framebuffer > > are 4-10 times slower than writes... > > > > Take a look at updatescrollmode() in fbcon.c - you must persuade this > > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW. FBINFO_READS_FAST > > should be sufficient - or you can report fast bitblt + fast panning, or > > fast bitblt + slow imageblit. If you report no panning + fast bitblt + > > fast imageblit, redraw is used :-( > > Uhhh, sounds complicated. All right, I will take a look into fbcon.c. Thank > you. For fb_info.flags add in FBINFO_HWACCEL_IMAGEBLIT. For example info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_IMAGEBLIT | FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_YPAN; See fb.h for more info. |
From: Juergen B. <jue...@kr...> - 2007-02-10 14:33:14
|
Hi Petr, On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote: > Take a look at updatescrollmode() in fbcon.c - you must persuade this > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW. FBINFO_READS_FAST > should be sufficient - or you can report fast bitblt + fast panning, or > fast bitblt + slow imageblit. If you report no panning + fast bitblt + > fast imageblit, redraw is used :-( I tried around to get fbcon to use SCROLL_MOVE. These are my current settings: info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_IMAGEBLIT | FBINFO_READS_FAST; With this settings updatescrollmode() decides to use SCROLL_MOVE. Two things are coming up with this scroll mode (all in fbcon_scroll() ): 1) why is the variable "logo_shown" always set to 0 for console 0? When in console 0 it always ends up in "goto redraw_up;" But I have no logo on my console? For other consoles than 0 "logo_shown" is -1 (=FBCON_LOGO_CANSHOW) 2) with the settings above active on another console then 0, the whole system freezes immediately in ops->bmove() or ops->clear()???? 2a) when I comment out the "logo_shown" check in fbcon_scroll() it also freezes the whole system in console 0. Any ideas? Juergen |
From: Antonino A. D. <ad...@gm...> - 2007-02-21 23:40:47
|
On Sat, 2007-02-10 at 15:32 +0100, Juergen Beisert wrote: > Hi Petr, > > On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote: > > Take a look at updatescrollmode() in fbcon.c - you must persuade this > > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW. FBINFO_READS_FAST > > should be sufficient - or you can report fast bitblt + fast panning, or > > fast bitblt + slow imageblit. If you report no panning + fast bitblt + > > fast imageblit, redraw is used :-( > > I tried around to get fbcon to use SCROLL_MOVE. These are my current settings: > > info->flags = FBINFO_DEFAULT | > FBINFO_HWACCEL_COPYAREA | > FBINFO_HWACCEL_FILLRECT | > FBINFO_HWACCEL_IMAGEBLIT | > FBINFO_READS_FAST; > With this settings updatescrollmode() decides to use SCROLL_MOVE. > > Two things are coming up with this scroll mode (all in fbcon_scroll() ): > > 1) why is the variable "logo_shown" always set to 0 for console 0? When in > console 0 it always ends up in "goto redraw_up;" But I have no logo on my > console? For other consoles than 0 "logo_shown" is -1 > (=FBCON_LOGO_CANSHOW) > 2) with the settings above active on another console then 0, the whole system > freezes immediately in ops->bmove() or ops->clear()???? > 2a) when I comment out the "logo_shown" check in fbcon_scroll() it also > freezes the whole system in console 0. > > Any ideas? > The global 'logo_shown' is only used at the very start, to display the boot logo if it is equal to LOGO_DRAW. It basically forces the scroll mode to redraw and gives space in the upper part of your screen. After that 'logo_shown' is assigned the index of the foreground console (usually 0) and your scroll settings are now used. Basically, don't touch the 'logo_shown' variable. If you don't want the tux logo, then disable it in your kernel config. As to why your driver freezes, I don't know. Check if it also crashes with cfbcopyarea first. Tony |
From: Juergen B. <jue...@kr...> - 2007-02-22 10:20:08
|
On Thursday 22 February 2007 00:43, Antonino A. Daplas wrote: > On Sat, 2007-02-10 at 15:32 +0100, Juergen Beisert wrote: > > Hi Petr, > > > > On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote: > > > Take a look at updatescrollmode() in fbcon.c - you must persuade this > > > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW. FBINFO_READS_FAST > > > should be sufficient - or you can report fast bitblt + fast panning, or > > > fast bitblt + slow imageblit. If you report no panning + fast bitblt + > > > fast imageblit, redraw is used :-( > > > > I tried around to get fbcon to use SCROLL_MOVE. These are my current > > settings: > > > > info->flags = FBINFO_DEFAULT | > > FBINFO_HWACCEL_COPYAREA | > > FBINFO_HWACCEL_FILLRECT | > > FBINFO_HWACCEL_IMAGEBLIT | > > FBINFO_READS_FAST; > > With this settings updatescrollmode() decides to use SCROLL_MOVE. > > > > Two things are coming up with this scroll mode (all in fbcon_scroll() ): > > > > 1) why is the variable "logo_shown" always set to 0 for console 0? When > > in console 0 it always ends up in "goto redraw_up;" But I have no logo on > > my console? For other consoles than 0 "logo_shown" is -1 > > (=FBCON_LOGO_CANSHOW) > > 2) with the settings above active on another console then 0, the whole > > system freezes immediately in ops->bmove() or ops->clear()???? > > 2a) when I comment out the "logo_shown" check in fbcon_scroll() it also > > freezes the whole system in console 0. > > > > Any ideas? > > The global 'logo_shown' is only used at the very start, to display the > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll > mode to redraw and gives space in the upper part of your screen. After > that 'logo_shown' is assigned the index of the foreground console > (usually 0) and your scroll settings are now used. No, 0 is a valid index and always used in console 0. So my scroll settings in console 0 are never used. > Basically, don't touch the 'logo_shown' variable. If you don't want the > tux logo, then disable it in your kernel config. Its already disabled. I didn't use the logo in my tests. > As to why your driver freezes, I don't know. Check if it also crashes > with cfbcopyarea first. I tried it with cfbcopyarea, because my hardware routine isn't finished yet. But all I tried, cfbcopyarea will never be called. It always ends up in ops->bmove() and crashes... Juergen |
From: Antonino A. D. <ad...@gm...> - 2007-02-22 10:42:21
|
On Thu, 2007-02-22 at 11:19 +0100, Juergen Beisert wrote: > On Thursday 22 February 2007 00:43, Antonino A. Daplas wrote: > > On Sat, 2007-02-10 at 15:32 +0100, Juergen Beisert wrote: > > > Hi Petr, > > > > > > On Wednesday 31 January 2007 10:12, Petr Vandrovec wrote: > > > > Take a look at updatescrollmode() in fbcon.c - you must persuade this > > > > function to use SCROLL_*_MOVE, not SCROLL_*_REDRAW. FBINFO_READS_FAST > > > > should be sufficient - or you can report fast bitblt + fast panning, or > > > > fast bitblt + slow imageblit. If you report no panning + fast bitblt + > > > > fast imageblit, redraw is used :-( > > > > > > I tried around to get fbcon to use SCROLL_MOVE. These are my current > > > settings: > > > > > > info->flags = FBINFO_DEFAULT | > > > FBINFO_HWACCEL_COPYAREA | > > > FBINFO_HWACCEL_FILLRECT | > > > FBINFO_HWACCEL_IMAGEBLIT | > > > FBINFO_READS_FAST; > > > With this settings updatescrollmode() decides to use SCROLL_MOVE. > > > > > > Two things are coming up with this scroll mode (all in fbcon_scroll() ): > > > > > > 1) why is the variable "logo_shown" always set to 0 for console 0? When > > > in console 0 it always ends up in "goto redraw_up;" But I have no logo on > > > my console? For other consoles than 0 "logo_shown" is -1 > > > (=FBCON_LOGO_CANSHOW) > > > 2) with the settings above active on another console then 0, the whole > > > system freezes immediately in ops->bmove() or ops->clear()???? > > > 2a) when I comment out the "logo_shown" check in fbcon_scroll() it also > > > freezes the whole system in console 0. > > > > > > Any ideas? > > > > The global 'logo_shown' is only used at the very start, to display the > > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll > > mode to redraw and gives space in the upper part of your screen. After > > that 'logo_shown' is assigned the index of the foreground console > > (usually 0) and your scroll settings are now used. > > No, 0 is a valid index and always used in console 0. So my scroll settings in > console 0 are never used. No, scroll_redraw is used if logo_shown = LOGO_DRAW. After a switch, it changes to logo_shown = fg_console = 0, and this time your scroll settings will be used. > > > Basically, don't touch the 'logo_shown' variable. If you don't want the > > tux logo, then disable it in your kernel config. > > Its already disabled. I didn't use the logo in my tests. > Okay. > > As to why your driver freezes, I don't know. Check if it also crashes > > with cfbcopyarea first. > > I tried it with cfbcopyarea, because my hardware routine isn't finished yet. > But all I tried, cfbcopyarea will never be called. It always ends up in > ops->bmove() and crashes... > ops->bmove is basically a wrapper to copyarea, so it does get used. I don't know why it would freeze though. Perhaps you can pinpoint where exactly in bmove it crashes. Tony |
From: Juergen B. <jue...@kr...> - 2007-02-22 11:43:56
|
On Thursday 22 February 2007 11:45, Antonino A. Daplas wrote: > > > The global 'logo_shown' is only used at the very start, to display the > > > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll > > > mode to redraw and gives space in the upper part of your screen. After > > > that 'logo_shown' is assigned the index of the foreground console > > > (usually 0) and your scroll settings are now used. > > > > No, 0 is a valid index and always used in console 0. So my scroll > > settings in console 0 are never used. > > No, scroll_redraw is used if logo_shown = LOGO_DRAW. After a switch, it > changes to logo_shown = fg_console = 0, and this time your scroll > settings will be used. So logo_shown will be set always to 0 for console 0, even if the logo is disabled? What do you mean with "switch"? Switch to another console? Or something else? Maybe I missunderstand. In fbcon_scroll() I found: [...] if (logo_shown >= 0) goto redraw_up; [...] But FBCON_LOGO_* are defined to values below 0. And with logo_shown=0 always the mode SCROLL_REDRAW is used. I'm confused. > > > As to why your driver freezes, I don't know. Check if it also crashes > > > with cfbcopyarea first. > > > > I tried it with cfbcopyarea, because my hardware routine isn't finished > > yet. But all I tried, cfbcopyarea will never be called. It always ends up > > in ops->bmove() and crashes... > > ops->bmove is basically a wrapper to copyarea, so it does get used. I > don't know why it would freeze though. Perhaps you can pinpoint where > exactly in bmove it crashes. I will try it. Juergen |
From: Antonino A. D. <ad...@gm...> - 2007-02-22 12:12:17
|
On Thu, 2007-02-22 at 12:43 +0100, Juergen Beisert wrote: > On Thursday 22 February 2007 11:45, Antonino A. Daplas wrote: > > > > The global 'logo_shown' is only used at the very start, to display the > > > > boot logo if it is equal to LOGO_DRAW. It basically forces the scroll > > > > mode to redraw and gives space in the upper part of your screen. After > > > > that 'logo_shown' is assigned the index of the foreground console > > > > (usually 0) and your scroll settings are now used. > > > > > > No, 0 is a valid index and always used in console 0. So my scroll > > > settings in console 0 are never used. > > > > No, scroll_redraw is used if logo_shown = LOGO_DRAW. After a switch, it > > changes to logo_shown = fg_console = 0, and this time your scroll > > settings will be used. > > So logo_shown will be set always to 0 for console 0, even if the logo is > disabled? What do you mean with "switch"? Switch to another console? Or > something else? > > Maybe I missunderstand. In fbcon_scroll() I found: > [...] > if (logo_shown >= 0) > goto redraw_up; Yep, kinda weird how it goes. First, logo_shown = SHOW_LOGO. This adds space at the top and the logo is drawn. Then logo_shown = fg_console, which forces scroll mode to redraw. Finally it becomes logo_shown = DONTSHOW in fbcon_switch(), and the space above disappears and the drivers scroll settings kick in. Tony |