|
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 |