Date: Mon, 3 May 1999 10:44:01 -0400 (EDT) From: Kelly Yancey <kbyanc@alcnet.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: new loader question / module question Message-ID: <Pine.BSF.4.05.9905031002070.53103-100000@kronos.alcnet.com> In-Reply-To: <xzpogk36qcm.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 May 1999, Dag-Erling Smorgrav wrote: > Kelly Yancey <kbyanc@alcnet.com> writes: > > Also, it got me thinking? Is there a way to "through away" the > > informaiton after I'm done with it. For example, in the splash module, > > once you load the image into memory, it's stuck there forever (ie. the > > "feature" that you can re-use it as a screen saver because it is still > > in memory). I was under the impression that we don't page kernel memory > > and thus the image is wired into RAM all the time (it will never be > > paged). Please tell me I'm wrong...because if not, doesn't this seem like > > a Bad Thing? > > Unfortunately, you're correct. What's more, the memory occupied by a > module is not reclaimed when the module is unloaded. Is there a way to free the memory allocated by the loader for the image? I don't see how since we didn't actually allocate the memory ourselves...I suppose it should still be possible free() the memory once we have located it by the tag, but I'm not sure how to do this? I'm thinking about providing a way to pass additional options to the splash module to enable/disable certain features (hence the idea in the original posting of using the loader to load a config file and then locating the tag and reading the configuration). One such option (for those people who would prefer the extra memory be reclaimed rather than being able to re-use it as a non-X screen saver) would be to free the memory allocated to the image after the system is booted (that is...if it is possible). > > > Thanks for all of your help! By the way? Is anyone working on improving > > the splash module. > > To a certain degree, yes. > > > With all the examining I've been doing of it recently, > > I would like to add the ability for it to scale the image to fit the > > screen size (rather than die of rimages which are too large). > > I might look into it some day, but the result of scaling the image is > likely to be very ugly due to aliasing. > > > I was also > > thinking about adding XPM support so I don't have to use Windows BMP > > files :) > > You don't have to use BMP files; you can use PCX files instead (PCX is > the file format Paintbrush used before it got bought by Microsoft) by > loading splash_pcx instead of splash_bmp. You won't get a fadeout > effect, though; I left that part out of the PCX decoder because it > didn't work properly and I didn't feel like trying to understand or > debug the code. Is this in -stable? or -current? My 3.1-19990309-STABLE machine only had a decoder for BMP files. > > BTW, those "Windows BMP files" are properly called DIBs (Device > Independent Bitmaps) and come in two slightly different variants: a > Windows version and an OS/2 version. I don't recall the differences in > format between the two. I think I've got it in a Dr. Dobbs somewhere...as I recall the headers are just slightly different. > > A PNG decoder is also planned, but it's a lot more work than a PCX > decoder and I haven't found the time to finish it yet. > Ouch...and I was starting to feel bad for investing any more kernel memory for something as trivial as a splash screen ;) > > anyway, those are just a couple of the ideas I thought I could > > implement to improve it, but I don't want to mess with it if someone else > > is already working on it. > > Patches are always welcome. Well, the first set of related patches (which I hope to have done by the end of the week) are to add some extra video modes to the syscons driver (320x400, 320x480, 360x200, 360x240, 360x400, and 360x480 modex). I'll post those to -hackers when I'm done. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > Kelly Yancey ~kbyanc@alcnet.com~ "Silly penguin, Linux is for kids" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905031002070.53103-100000>