From: "Iain Sandoe" <iain@sandoe.co.uk>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ani Joshi <ajoshi@shell.unixbox.com>,
William Blew <wblew@home.com>,
michel dnzer <michdaen@iiic.ethz.ch>,
kaoru fukui <k_fukui@highway.ne.jp>,
linuxppc-dev@lists.linuxppc.org
Subject: Re: XF4 (mach64) help please
Date: Thu, 19 Apr 2001 20:07:18 +0100 [thread overview]
Message-ID: <20010419190740.A697B2EFF6@apollo.valhalla.net> (raw)
On Thu, Apr 19, 2001, Geert Uytterhoeven wrote:
> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>> On Thu, Apr 19, 2001, Ani Joshi wrote:
>> > On Thu, 19 Apr 2001, William Blew wrote:
>> >> On Thu, 19 Apr 2001, Iain Sandoe wrote:
>> >> > 2/ how difficult would it be to plumb the scroll acceleration back into
>> the
>> >> > console driver? (would one need access to the NDA stuff?) -- the
scrolling
>> >> > of console is a real problem in blocking sound :-/
>> >>
>> >> For mach64 at least, I would start by porting the CopyScreen2Screen XXA
>> >> operation into the kernel and then using it during scrolling.
>> >
>> > This is already done by atyfb in the kernel,
>>
>> then why is the atyfb scroll (and fbdevhw) _so_ much slower than the X
>> 'native' driver ... the same reason as below?
>
> Because xterm uses jump scroll? Try scrolling line by line in X11.
hmmm. I was comparing "before" and "after" changing to Ani's new ati_drv.o
(before was using libfbdevhw.a) - in all other respects the configuration
was identical.
this is mach64 (3DU Pro) on G3/beige - the difference seemed to be striking
enough to comment (but I guess I could wind it back and do an X11Perf).
>> >however the problem lies in
>> > the entire fbcon layer where there is some improper locking/interrupts
>
> Read: the entire console layer. Fbcon cannot (read: couldn't) use interrupts
> because the upper console layer disables (disabled) interrupts.
>
>> > going on there. This was discussed here and on linux-fbdev a few months
>> > ago and I believe will be addressed in 2.5.
>>
>> and there is a (temporary) fix for it (I believe) involving a patch from
>> Andrew Morton - (which I haven't had time to try on PPC yet). Will that fix
>> the slow console scroll as well?
>
> It's supposed to. Haven't tried it yet, though.
I will ASAP - AFAICT the various blocking issues are the main problem with
(pmac) sound now.
ciao,
Iain.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2001-04-19 19:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-19 19:07 Iain Sandoe [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-04-19 18:21 XF4 (mach64) help please Iain Sandoe
2001-04-19 18:38 ` Geert Uytterhoeven
2001-04-19 12:36 Iain Sandoe
2001-04-19 15:46 ` William Blew
2001-04-19 17:57 ` Ani Joshi
2001-04-16 15:15 Iain Sandoe
2001-04-16 21:47 ` Michel Dänzer
2001-04-17 4:07 ` Ani Joshi
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=20010419190740.A697B2EFF6@apollo.valhalla.net \
--to=iain@sandoe.co.uk \
--cc=ajoshi@shell.unixbox.com \
--cc=geert@linux-m68k.org \
--cc=k_fukui@highway.ne.jp \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=michdaen@iiic.ethz.ch \
--cc=wblew@home.com \
/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).