From: Petr V. <VAN...@vc...> - 2001-07-18 12:15:28
|
On 18 Jul 01 at 14:02, Romain Dolbeau wrote: > In the above functions, are the various position > parameters (sx, xx, sy, yy) in > > 1) display coordinate > 2) buffer coordinate > > Before I commit my change to fix pm3fb, I'd > like an authoritative answer on the subject. > It just _feels_ wrong to me to use absolute > coordinate. It is buffer coordinate. You have framebuffer xres_virtual * yres_virtual pixels, and all coordinates for putc/clear/bmove are relative to left upper corner of this buffer. Then you have window xres * yres which specifies what is visible on screen. And while coordinates for painting characters are in character cell, offset from buffer's top left corner and window top left corner (xoffset, yoffset) is specified in pixels, not in character cells. So you should take yoffset/xoffset into account only for setting viewport position (and yres/xres for setting viewport size), while accelerated painting ops should not use these 4 values at all. Best regards, Petr Vandrovec van...@vc... |
From: Petr V. <VAN...@vc...> - 2001-07-18 13:09:28
|
On 18 Jul 01 at 14:28, Romain Dolbeau wrote: > Petr Vandrovec wrote: > > > So you should take yoffset/xoffset into account > > only for setting viewport position (and yres/xres > > for setting viewport size), while accelerated > > painting ops should not use these 4 values at all. > > OK, thanks. I assume this is _not_ true for > the clear_margins ? fbcon_cfb32 takes yoffset > into account, but not xoffset ?!? bug ? It is bug. clear_margin is stupid procedure anyway as it corrupts screen buffer contents, so if you are using non-zero xoffset, you should make sure that there is no right margin... Best regards, Petr Vandrovec van...@vc... |
From: Romain D. <do...@ir...> - 2001-07-18 13:25:40
|
Petr Vandrovec wrote: > It is bug. clear_margin is stupid procedure anyway as > it corrupts screen buffer contents, so if you are using > non-zero xoffset, you should make sure that there is no > right margin... Why should it corrupts memory ? Properly written, you only erase the rows/columns that are displayed and not used, i.e. right margin: from (yoffset) to (yoffset + yres) and from (conp->vc_cols * fontwidth(p) + xoffset) to (xoffset + xres) bottom margin: from (xoffset) to (xoffset + xres) and from (conp->vc_rows * fontheight(p) + yoffset) to (yoffset + yres) and the fbcon-* do it properly except they forgot the xoffset. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
From: Petr V. <VAN...@vc...> - 2001-07-18 13:51:06
|
On 18 Jul 01 at 15:25, Romain Dolbeau wrote: > Petr Vandrovec wrote: > > It is bug. clear_margin is stupid procedure anyway as > > it corrupts screen buffer contents, so if you are using > > non-zero xoffset, you should make sure that there is no > > right margin... > > Why should it corrupts memory ? Properly written, > you only erase the rows/columns that are displayed > and not used, i.e. > > right margin: from (yoffset) > to (yoffset + yres) > and from (conp->vc_cols * fontwidth(p) + xoffset) > to (xoffset + xres) I probably do not understand where you are painting black square... What if you increment xoffset, paint something, and now decrement xoffset, and increment it back? Now you have vertical black stripe in the middle of your picture... > bottom margin: from (xoffset) > to (xoffset + xres) > and from (conp->vc_rows * fontheight(p) + yoffset) > to (yoffset + yres) And this is of course wrong. What if you have yoffset = 400, and now you hit shift-pgup, so yoffset is now 200? So bottom of screen is cleared. Now you cancel viewing scrollback, so yoffset is now back to 400 - and voila, you have black line in the middle of the screen. fbcon/fbdev has to work hardly around this - it must decide when to call clear_margin (if it is scrolling caused by console subsystem) and when not (when you are walking through scrollback). And even in this case it is buggy. If you'll shift-pgup through whole framebuffer (of course you has to disable buggy scrollback with video=scrollback:0, as otherwise software scrollback kicks in and no ypan is done), you'll find that top line in the framebuffer has cleared its upper part, because of same area is visible in 'normal' situation as few lines below last line on the screen. So you have to create one spare character line between end and top of picture, just to keep this line black. Another problem is that margin is painted by color #0 and not by black, so if you'll set bgcolor to red, fill screen with blue, you'll get blue square with red margin on right/bottom and finally black around that. It is especially visible with midnight commander, which sometime has background color set to cyan when clear_margin is invoked. And as fbcon does not allow xoffset != 0, I do not think that there is any need for fixing right side of clear_margin. Best regards, Petr Vandrovec van...@vc... |
From: Romain D. <do...@ir...> - 2001-07-18 14:22:18
|
Petr Vandrovec wrote: > And this is of course wrong. What if you have yoffset = 400, and > now you hit shift-pgup, so yoffset is now 200? So bottom of screen [snip] OK, you were talking about the whole fbcon subsystem while I was talking about the function itself. It's easy to write a function that comply with the specification, but from your description it's obviously difficult to properly use clear_margin :-) Thanks for the answers, -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
From: Romain D. <do...@ir...> - 2001-07-18 12:28:34
|
Petr Vandrovec wrote: > So you should take yoffset/xoffset into account > only for setting viewport position (and yres/xres > for setting viewport size), while accelerated > painting ops should not use these 4 values at all. OK, thanks. I assume this is _not_ true for the clear_margins ? fbcon_cfb32 takes yoffset into account, but not xoffset ?!? bug ? TIA -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |