> >First try setting a larger virtual y size than the visible size.
> I run the vesafb at 800x600 (on an old Thinkpad), so when I use
> ggiSetSimpleMode(vis,GGI_AUTO,GGI_AUTO,GGI_AUTO,GGI_AUTO,GT_AUTO); I get a
> mode string (from ggiGetMode() followed by ggiSPrintMode()) which reads:
> 800x600.V800x600.F1.D1x1[C16/16]
Yes. vesafb can do _one_and_only_one mode: The one it booted in.
> But when I tried to set a "longer" (virtual y > physical y) mode by
> calling, e.g., ggiSetGraphMode(vis, 800, 600, 800, 2*600, GT_AUTO);
> GGI seems to ignore my request,
No - vesafb tells GGI that it cannot do any mode but the one it has.
> since mode_string still contains exactly the same measurements:
> 800x600.V800x600.F1.D1x1[C16/16]
> Am I doing this wrong?
No. Vesafb just can't.
> Or is it a hardware limitation
Not really. The hardware might do it, but vesafb can't due to the way it
works. It sets up one mode at startup while still in real mode and
that's it.
> (my video card is getting old, and it only has 1MB VRAM, if I recall
> correctly;
In that case it's a HW-limitation:
800x600= 480 000 byte , 800x600x16bit= 960 000 byte ... no room for double
height.
Please read vesafb.txt somewhere under /usr/src/kernel/Documentation/* .
There is an option that allows higher virtual heights.
> I am also using univbe.exe under MS-DOS so that my card seems VESA 2.0
> compliant to the linux vesafb, although it is only VESA 1.2 compliant)?
That doesn't matter.
> I am using the fbdev target. And the call
> ggiCheckGraphMode(vis,800,600,800,1200,GT_AUTO,&mode);
> returns -1, showing that the call of ggiSetGraphMode() with this
> parameters would really fail...
Yes. This fbdev driver can't, which is why Marcus advised to try that first
and then resort to CopyBox if it doesn't work.
> >You should copy the whole screen at a time though, why would you want to
> >copy a few rows at a time?
> I wished to make reading text easy while scrolling, and I've always felt
> that having the ability to scroll line after line is easier for the user
> who is reading; though this requires updating the screen in a more
> "painful" way, I guess...
I think you misunderstood each other here. Marcus is talking about using
a single "ggiCopyBox" for the whole screen - how far you scroll then is you
choice. I think he had the impression that you wanted to move it
row by row or something ...
> But I guess that, if I manage to get a "longer" virtual visual, I might
> just as well obtain this effect of "gradual" scrolling by making the
> origin descend along the y-axis in a gradual way, right?
Yes.
> This way I might avoid using ggiCopyBox() and achieve the same effect; do
> you consider this to be a "good" solution to achieve the desired
> "graduality" when scrolling?
Yes.
> [Was this what you meant? Or were you only referring to using
> ggiSetOrigin() when updating the whole screen?]
No. SetOrigin is good, if available.
> But if I really don't manage to get a longer virtual visual, what can I do
> about it?
Either draw as needed from a virtual plane you just "imagine", like text
editors do, or allocate a large enough Background buffer in a memvisual
(read targets.txt in the doc dir for that) and use ggiCrossBlit.
> Must I "draw" things on bitmaps using "normal" dynamically allocated
> memory
I'd use a memvisual for that. Allows you to still use LibGGI for rendering.
> and then use ggiCopyBox() to copy them onto the visual
No - CopyBox works intra-visual only. Not across visuals. ggiCrossBlit
or eventually ggiPutBox (for main memory) would be right.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
