|
There is a suggested patch for the request_scroll()
fix in the
attached scroll.txt.I don't know how to post this
appropriately, but for now I just attached a pasted copy
of this patch in the scroll.txt.
Here is the issue:
I found out that under DOS scroll_screen() wraps to the pmode call
=
setdisplaystart when linear frame buffer is
used.Only problem it sets
EBX to 0x80 which waits for the retrace.I =
think it would be reasonable to
be able to
chose EBX=3D0x00 mode where the function does not wait for a
retrace to =
happen.Request scroll will not do
because that will wrap back
to scroll_screen() if tripple-buffer is not =
available.But it would be
possible to
do it anyway by just implementing a retrace_simulator with the
=
set_display_start EBX=3D0x00 !There could
be other reasons to just want
to scroll without always waiting for a =
retrace ! I changed the lib to
include
scroll_screen_now() wich will do just that.It will work with any
=
gfx_driver that can scroll.I think the vbeaf
driver request_scroll()
will do allright.It only wrote the vesa modex =
and vbeaf for now.Is this
something that
that may be implemented in future releases or you may explain
why is EBX =
0x80 set is stone.
On the topic of scroll...
Maybe request_scroll() sould be called
schedule_scroll().
(VESA calls it that way too.)
Then the new
request_scroll() would be see below...
(This involves adding another member
in the gfx_driver struct for ="">schedule_scroll() which
will be just like
the original r2equest_scroll() of course.)
See attachment for the details
!
|