From mint-bounce@lists.fishpool.fi Fri Jun 10 23:37:50 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <20050610213419.1280.qmail@mailcz.in.systinet.com> References: <42A85C4F.7050500@atari-hcm.de> <1118332250.6432.5.camel@linuxbox> <1118418583.7315.1.camel@joy.home> <20050610181058.16372.qmail@mailcz.in.systinet.com> <1118433097.6432.23.camel@linuxbox> In-Reply-To: <1118433097.6432.23.camel@linuxbox> From: Standa Opichal To: mint@fishpool.com Subject: Re: [MiNT] Problem with mint 1.16 installation Date: Fri, 10 Jun 2005 14:34:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.4 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j5ALbo9M017536 Odd, OK, I was a little fuzzy it seems... To be clear: I do not get the idea of hacking AES to do workarounds when the videodriver is to be fixed. What is the point in making AES to shut caches off? It this a thing that the AES should do by design? I truly believe it is not. So the real solution you ET whatever problem is to fix/wrap the HW driver to do what is necessary. If there is no API for the particular thing (a VDI card video driver in this case) that the closest documented API level is to be fixed IMHO (the VDI, right?). That is just like the older NOVA HW driver on my friends TT doesn't have the VDI scrninfo() implemented. Would I patch HighWire to not to use this function or would I rather go and implement the VDI function for the single TT I have problem with? Just my point of view... STanda Odd Skancke writes: > Hello, > > fre, 10,.06.2005 kl. 20.10 +0200, skrev Standa Opichal: >> Hi! >> >> Exactly, if there is a crappy VDI that is not compatible with a particular >> CPU then the VDI is to be patched and not the AES, right? So the hack should >> not go into AES implementation IMHO. > > The VDI has just as little to do with this as the AES has. The > videohardware driver is the issue here. But since there is no defined > API for drivers to use, we're out of luck. The next best thing then is > to use a defined API where available to attempt to minimize the problem. > Any problem with this? > >> >> STanda >> >> >> Petr Stehlik writes: >> >> > Odd Skancke píše v Čt 09. 06. 2005 v 17:50 +0200: >> >> with black screen. I had this problem with the ET6K I had in my Hades. >> >> However, the latest XaAES (as found in the CVS) turns the caches off >> >> before calling v_opnwk()/v_clswk(), and this should cure it. >> > >> > I am surprised that an AES must play with CPU caches. Shouldn't XBIOS >> > (or VDI, at worst) do that instead? >> > >> > Petr >> > > Odd skancke