From mint-bounce@lists.fishpool.fi Mon Jun 13 17:15:31 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] Problem with mint 1.16 installation From: Odd Skancke To: MiNT List In-Reply-To: <42AD9489.509@seznam.cz> 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> <20050610213419.1280.qmail@mailcz.in.systinet.com> <1118442697.6432.55.camel@linuxbox> <42AD9489.509@seznam.cz> Content-Type: text/plain Date: Mon, 13 Jun 2005 17:10:41 +0200 Message-Id: <1118675442.6432.77.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org 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.1 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: man, 13,.06.2005 kl. 10.13 -0400, skrev Standa Opichal: > Hi! :) > > Odd Skancke wrote: > > Hello, > > > > fre, 10,.06.2005 kl. 14.34 -0700, skrev Standa Opichal: > > > > Agreed it is a hack. Agreed this is not a good idea. Agreed this is not > > a thing the AES should do by design. I have been saying that all along, > > right? > > ok. Let's make the approach description clear then... What? > > > will work on any systems/architectures. The ideal situation would be for > > such functionality to be available when the driver runs. > > > > > >>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?). > > > > > > This is a problem most Hades owners (and all versions of the Nova VDI, > > mach64, et6000 and Rage) suffers from, not just me. I did patch the et6k > > driver to get rid of this problem, and it worked fine. However, patching > > the video-driver like that will make it work only on 060 and compatible. > > And what is wrong with having it only 060 compatible? In my eyes this is > definitely not an excuse to hack AES in such a way.... > > >>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? > > > > I do not understand what you are saying here? Please explain? > > What would you do if a particular VDI driver you use (IIRC Matrix TT > card) doesn't implement vq_scrninfo() method? > 1) hack every application that is using that to not to > 2) create AUTO TSR application that would hook on this and imlement > the function? > > I think that the only way to go is 2). What kind of a comparison is this? Install NVDI. > > > If you think I added this for my own amusement, > > No, I would never even think about that. I just do not like hacks in new > apps because of some other SW imperfections. TSR seems to be the right > solution for me in this case. And so far I cannot think of any better. Well, then we disagree again. And I dont want to go any further with this discussion because we do not understand eachother at all. Using a TSR is really a hack!! There is a reason Ssystem() provides cache control. I am starting to disagree with myself saying using Ssystem() is a hack. XaAES uses cpush() in strategic places too ... a hack? You talking about TSR tells me we have very different definitions of _clean software_! Odd Skancke