From mint-bounce@lists.fishpool.fi Mon Jun 13 16:17:42 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <42AD9489.509@seznam.cz> Date: Mon, 13 Jun 2005 10:13:29 -0400 From: Standa Opichal User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Problem with mint 1.16 installation 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 In-Reply-To: <1118442697.6432.55.camel@linuxbox> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 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: 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... > Now, what choice do I have? Altho the AES is not the place to do this, > XaAES is a kernel module, and have access to the right API's so it can > make sure CPU caches are turned off before calling v_opnwk() then > restored immediately after. This is the best solution given the > situation. And since Ssystem() is a well documented system call, this > 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). > 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. Best Regards STanda