From: "Etienne Lorrain" <etienne_lorrain@yahoo.fr>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: specific optimizations for unaccelerated framebuffers
Date: Mon, 15 Oct 2001 11:26:05 +0200 (CEST) [thread overview]
Message-ID: <20011015092605.55285.qmail@web11802.mail.yahoo.com> (raw)
In-Reply-To: <20011006003547.A42@toy.ucw.cz>
> > I am not speaking of DMA'ing at the refresh frequency (approx 70 times
> > per second the complete video memory), just the modified 64Kb blocks,
> > "once upon a while": if a single pixel is written twice, you will just
> > see the latter written value on the screen - but who cares.
> > Been able to DMA the complete video memory image around 5-10
> > times/second should be over the human eye sensitivity.
>
> Yep, that should work. Same trick as xterm uses.
> Pavel
Will be a bit more complex than xterm/curses. One of the problem
is that using the VESA1 interface is needed (DMA restrictions), so
you need to get back the array given by the Gujin bootloader, describing
which I/O port to use to switch the 32/64K window at 0xA0000. You do not
want to go back to real-mode at every VESA1 page change.
(This array is already available with the current Gujin, using it is
Gujin native mode for VESA1 cards)
> [Of course, user *will* see you are only updating at 5fps... But it will
> be way beter than current slowness.]
And the only usual "fast changing" thing is the mouse, so either use a
hardware extension of the video card or direct PCI write for it only.
My main question was which bandwidth the standard DMA is able to do
for memory to memory copy, if it is too slow, do not even start
to code anything... got no answer. The PC DMA can only copy memory by
16 bit units - and I am not sure it will behave correctly with
PCI stalls.
> Are you going to create a patch?
Lets say, I start just after I finish Gujin; i.e. if you want to see
something before Linux 3.1, find someone else... I can still help a bit.
Etienne.
___________________________________________________________
Un nouveau Nokia Game commence.
Allez sur http://fr.yahoo.com/nokiagame avant le 3 novembre
pour participer à cette aventure tous médias.
next prev parent reply other threads:[~2001-10-15 9:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3BBC4A4E.AC6106A6@ftel.co.uk>
2001-10-04 12:31 ` specific optimizations for unaccelerated framebuffers Etienne Lorrain
2001-10-04 14:01 ` Christopher Friesen
2001-10-04 14:28 ` Etienne Lorrain
2001-10-04 22:59 ` Alex Bligh - linux-kernel
2001-10-06 0:35 ` Pavel Machek
2001-10-15 9:26 ` Etienne Lorrain [this message]
2001-10-04 8:58 Etienne Lorrain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011015092605.55285.qmail@web11802.mail.yahoo.com \
--to=etienne_lorrain@yahoo.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).