User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.5) Gecko/20060912 Firefox/1.5.0.5 Build Identifier: You may have noticed the link to my forum post in this week's GWN. I've figured out a simple kernel hack that lets you add your own bootup logos (which go where Tux normally sits) and which you can select for at compile-time (via menuconfig). The method is described here: http://gentoo-wiki.com/HOWTO_Linux_Logo_Hack#Do_it_Right I think it'd be great if you fine people could include this in the gentoo-sources patchset. I've been canvassing user opinions, and it seems that the majority (nearly 90%) of Gentooers support the idea. I don't reckon it'd need a lot of maintenance, (how often do Linus et al change the bootup logo code?), but of course I'd be willing to handle any tweaking/fixing that was within my capabilities. I for one don't think that Larry gets anywhere near enough exposure, so I reckon this is just what he needs. What's your opinion? Reproducible: Always Steps to Reproduce: 1. Boot the system 2. Larry isn't there! 3. Mourn the lack of gender-confused cows in our default kernel
Can you please attach the proposed patch to this bug?
Created attachment 97582 [details] Diff files and proposed log Here you go - this is the first patch I've ever submitted to anything, so I hope I've done it right :) There are a couple of other candidate logos being discussed in the forums, which can be added without any trouble at a later date. This is the original one that I made though, so it'll do for now.
Created attachment 97583 [details] Diff files & proposed logo Argh, guess I didn't get it right. If at first you don't succeed...
Thanks, but plain text only attachments, please. Make it as easy as possible for developers to review the submission, since we have plenty of other bugs to be looking at :)
Created attachment 97589 [details, diff] Patch for Kconfig file
Created attachment 97590 [details, diff] Patch for Makefile
Created attachment 97591 [details, diff] Patch for logo.c Alright, there ya go. Third time lucky, I hope :)
Gah, my apologies - all of these files are in $KERNEL_TREE/drivers/video/logo/ Sorry I've made such a pig's ear of this bug report - like I say, it's the first time I've done anything like this...
Created attachment 97950 [details] larry-gentoo-logo224.patch This complete patch contains Larry logo and more official Gentoo logo (I'll atach it too for reference).
Created attachment 97951 [details] logo_gentoo_clut224.png Gentoo logo.
It is a nice touch but I'm not so keen on including this in our kernel. Instead, we should perhaps add a configurable path input into menuconfig, which would point to an image file on the filesystem, and then we #include that file from the kernel source if the option is enabled. That way we could provide a selection of images in another ebuild and the actual kernel patch would be a candiate to go upstream. Any volunteers?
I'm not keen on including this while genpatches doesn't really include any Gentoo specific things. Also, the idea of including images in a patchset is slightly odd. I'd consider a patch to pull in images from the filesystem at compile time, as described in comment #11. If anyone is interested in implementing this, I could elaborate further if that wasn't clear.
It's on my list of things to attempt, but I'm slightly put off by the fact that I'd have to learn C properly first. Also I'm at Uni now, so I've got less free time than I had over the Summer when I worked it all out. If no-one else does it then I will try it eventually, but I'm sure it'd happen a lot faster (and better) if someone with some kernel experience (I'm not implying anybody in particular) took up the mantle. Sorry I can't be more positive here...
You wouldn't have to write much C at all, just add a text input entry on the menu (for the path to the image) and an #include in the source which uses that path. You would have to modify the existing code to play nicely with this new include, but that's about it.
Oh, OK. I might give that a go quite soon then :)
(In reply to comment #15) > Oh, OK. I might give that a go quite soon then :) > I just wonder how "soon" you meant... :-) I've been using Larry The Cow logo on every single machine I've been installing since... pfew... quite a lot of time now. I'm begging you, man: pleaaaaaase, would you mind including the submited patches, e.g. in Gentoo patchset? A whole lot of thanks in advance. (a Happy Larry Fan)
Agh, I'm sorry but I'm just not up to the job. I had a go at doing it back in October, but I couldn't get my head around it. As I recall, I kept getting compile errors and I didn't know how to fix them... Like I said in my previous comment, if anybody who knows more about these things wants to pitch in (maybe even just talk me through it on IRC?) then that'd be fantastic - but I don't think it's going to get done otherwise, I'm afraid :(
Created attachment 126713 [details, diff] Patch for Larry The Cow boot logo (224 colors) (In reply to comment #17) > Agh, I'm sorry but I'm just not up to the job. > > I had a go at doing it back in October, but I couldn't get my head around it. > As I recall, I kept getting compile errors and I didn't know how to fix them... Ok, sorry. Here's the patch that I've been using on x86 and x86_64 architecture since kernels 2.6.17 (IIRC). I don't remember where I got it - I didn't write it in fact. I usually apply it from /usr/src/linux right after I emerge gentoo-sources but I'm sure it can be successfully applied to any kernel source tree. The patch adds an entry in kernel configuration Device drivers > Graphics support > Logo configuration. Select it, build your kernel, reboot and enjoy a 224-colors Larry ;).
Yup, that looks very much like an amalgamation of the three patches I posted before (I didn't know how to put them all into a single file). What's needed, though, is a way of loading the PPM in from the filesystem at compile-time, by specifying a path to it in menuconfig. I don't know how to do that. I have my own "new kernel" script, which takes me through menuconfig, makes and installs the kernel and its modules and copies the image to /boot - I guess if you have something similar, (is Genkernel scriptable? I've never used it), you could simply add the patch command to that...
(In reply to comment #19) > Yup, that looks very much like an amalgamation of the three patches I posted > before (I didn't know how to put them all into a single file). > > What's needed, though, is a way of loading the PPM in from the filesystem at > compile-time, by specifying a path to it in menuconfig. I don't know how to do > that. But that's what the patch does: if you include it into Gentoo's patchset, it will be applied when the sources are extracted. It creates the required files and changes menuconfig accordingly so that all you have to do is to run make menuconfig, select your favorite logo and compile. BTW is this the right place to request for adding a patch to gentoo patchset? > I have my own "new kernel" script, which takes me through menuconfig, makes and > installs the kernel and its modules and copies the image to /boot - I guess if > you have something similar, (is Genkernel scriptable? I've never used it), you > could simply add the patch command to that... I don't know, I only used genkernel three times in 2004 :-) .
Have you read comments #11 and #12, by Daniel Drake? My patch doesn't allow you to specify a path in menuconfig. The path is hardcoded into the patch, and it points to a pre-made image file which is also in the patch. What's required is a patch which will produce a text-input field when you're configuring the kernel using menuconfig, so that you can type the path to /any/ suitable image file in your filesystem.
If I understand Daniel's opinion I'd like to add a little bit of user experience. I agree including pictures into the main kernel is a little odd. But - first - it already happened at least once since someone had got to include Tux's picture at some time in the main kernel tree. Second, we're talking about Gentoo's "mascotte" be it Larry or the Big G - or whatever. It's not as sensitive as putting new SATA drivers into the main tree, is it? :-) Finally letting the user input a file location in menuconfig would move the responsibility for creating the PPM file onto the user's side. Of course it's no big deal. You'd say if they can patch a kernel they for sure can convert an image into the correct format. But the reverse is also true: if they know how to convert an image to the appropriate format, let's keep the patch way for - if it's not complicated - both ways are no simpler for anybody. At least there are howto's to add custom logo's at will. And of course they might need a little understanding of C but if you follow the guide it can be done rather easily. Letting the user fill in a file path would also - preferably IMHO - mean providing link to tools, e.g. convert or whatever. Unless menuconfig can be enhanced to convert file formats into the appropriate C source file. I know Daniel would like a more generic way but again we're talking about Gentoo's specifics here. So IMHO it's worth the inclusion.
Sorry, we won't add the image to genpatches, becuase it doesn't meet our current patch criteria: no feature patches other than hardware support additions that are already upstream. This isn't because having images in the kernel tree is a bad idea, I'm fully aware that we already have penguins and I don't oppose that in any way. My point is that we won't include it *on Gentoo's end*. The argument is the same for all other feature patches, e.g. reiser4 filesystem. Will we add reiser4 to genpatches? No, it's outside of our patch criteria. If reiser4 went into mainline Linux, would we rip it out in genpatches? No. Upstream is where it belongs, which is why it was rejected from genpatches in the first place. In this case, adding a cow to the upstream kernel probably wouldn't go down well upstream developers. However, creating a simple patch to allow the user to specify a path to an image would definitely be considered. If someone writes such a patch *and* it gets accepted upstream, we'll include it genpatches.
(In reply to comment #23) > If someone writes such a patch *and* it gets accepted upstream, we'll include > it genpatches. So where is the place to have such a patch be submitted upstream?
... and how about an ebuild with this specific patch? It won't require upstream approval, will be independent of this bugzilla and, lastly, could be quickly implemented distributed. Or even a USE flag to gentoo-sources, which controls the application of such a patch? It wouldn't need inclusion in the main gentoo patchset, just a separate patch. Also quickly implemented and distributed. (But I wonder; would it require upstream aknowledgment?)
Sorry to bother but here's another idea (just trying to find a way to quickly make everybody happy, me included). Why not an ebuild with the patch, like I previously said, which would be refered to by a USE flag in the main gentoo-sources ebuild? # USE="-larry" emerge -pvq gentoo-sources [ebuild R ] sys-kernel/gentoo-sources-2.6.22-r2 USE="-build -symlink -larry" # USE="larry" emerge -pvq gentoo-sources [ebuild N ] sys-kernel/gentoo-larry-0.0.1 [ebuild R ] sys-kernel/gentoo-sources-2.6.22-r2 USE="-build -symlink larry" Does it fit anyone?
or even: # USE="user-patches debian gentoo larry" emerge -pvq gentoo-sources [ebuild N ] sys-kernel/gentoo-larry-1.0 [ebuild N ] virtual/kernel-user-patches-2.0.1 USE="debian gentoo -freebsd larry whateverisavailableatthattime" [ebuild R ] sys-kernel/gentoo-sources-4.10.85-r32 USE="-build -symlink user-patches"
So why am I suggesting ebuilds and so on? The idea of having an input area in menuconfig suggests it's up to *every* single Gentoo user to a) find the image b) struggle, search and find what to do with the picture c) convert the image d) type the file name into menuconfig e) see if that works. I'd like an easier approach, like USE flags - since it's what Gentoo is all about - where only *one* person has to create a patch, a couple of others have to make the ebuild and *millions* of Gentoo users just have to select their favorite USE flag. And even an ebuild which has nothing with gentoo-sources, with just the patch, would be acceptable, IMHO, provided it has DEPEND="gentoo-sources" in it. And it's even not necessary to change and add a use flag to the gentoo-sources ebuild (just thinking further) if the larry-the-cow.ebuild or the multiple-kernel-logos.ebuild just have the DEPEND="gentoo-sources" clause in it. So everybody should be happy with it, shouldn't they? No kernel upstream approval, no question, no tears, no wait :) .
I had a bit of a think earlier on and came to the conclusion that the best way for end-users to access the patch as it stands would be to create a Portage overlay, mirroring gentoo-sources but also containing the logo patch. If I went down that route, the whole thing would be totally independent of Gentoo and so wouldn't waste the time of any devs. I guess I could try writing some kind of cronjob to watch RSS feeds for new gentoo-sources releases, and then create appropriate ebuilds on my overlay server as required (which would, of course, be accessible from the net). That seems entirely feasible to me, actually - I might have a go at it. Better check the security on my server first though, this'll be its first production application :)
(In reply to comment #24) > So where is the place to have such a patch be submitted upstream? Submit it here and I'll take care of upstreaming it. (In reply to comment #25) > ... and how about an ebuild with this specific patch? It won't require upstream > approval, will be independent of this bugzilla and, lastly, could be quickly > implemented distributed. An ebuild that just installs the specific patch (but doesn't apply it) and some documentation? That would work. Feel free to file a bug with an ebuild for this, maybe someone will offer to maintain it. > Or even a USE flag to gentoo-sources, which controls the application of such a > patch? It wouldn't need inclusion in the main gentoo patchset, just a separate > patch. Also quickly implemented and distributed. (But I wonder; would it > require upstream aknowledgment?) We require upstream acknowledgement for all new patches. And USE based patch application is out of the question, see the genpatches FAQ. A developer-to-be expressed interest in writing the required kernel patch here (to allow the user to enter an image path in menuconfig) so maybe something will come of it. This is still the nicest approach that is realistic, and could be made very easy for the user through a genkernel command line option (it would emerge the package that contains the logo in the correct format, and would compile the kernel with the configuration set to point at the image). I still encourage others to look into writing this simple patch. There are other examples of the kernel menuconfig controlling #includes from userspace, e.g. the ACPI DSDT override.
(In reply to comment #29) Sounds like a good idea. But is it absolutely necessary? I mean an ebuild with the patch could be applied to not only gentoo-sources but any kernel sources - maybe with small adjustments. I know ebuilds can modify files outside their temporary working directory (e.g. /etc/portage/package.*, in which "net-www/apache2" was recently changed into "www-server/apache2"). So it should be possible to package a patch in an ebuild, that acts directly upon /usr/src/linux - apart from checking if the patch was already applied and such kinds of things but that's only ebuild cooking if you allow me the expression ;-).
Created attachment 127850 [details, diff] Add "include custom bootup logo"-functionality. There are 4 different types of images the kernel knows how to handle: black/white (*.pbm), vga16 (*.ppm), clut224 (*.ppm) and gray256 (*.pgm). This patch adds options to include external images all 4 types. Please comment, so I can fix/enhance the patch.
Apologies, I must have missed that patch when it came in and only just noticed it now. I've put it on my list of stuff to review. Feel free to poke me if I don't get round to it soon.
I have just tried custom_bootup patch with only a trivial change to be applied to kernel 2.6.23 (tuxonice-sources-2.6.23-r5) and tested it with the two logos from larry-gentoo-logo224.patch attached here. Issue: if I want to change the custom logo, I have to manually delete linux/drivers/video/logo/logo_custom_clut224.ppm After that, it works fine.
Created attachment 139180 [details, diff] linux-2.6.23-custom-bootup.patch Patch for kernel 2.6.23. It solves above mentioned issue. Changes from linux-2.6.22-custom-bootup.patch: (linux/drivers/video/logo/Makefile) 1) Added missing 'FORCE' prerequisite when '$(call if_changed,copy)' command is used. 2) Removed 'clean-files += logo_custom_*' line and changed clean-files := *.o *_mono.c *_vga16.c *_clut224.c *_gray256.c to clean-files := *.o *_mono.c *_vga16.c *_clut224.c *_gray256.c logo_custom_* at the end of Makefile or it won't delete custom images when 'make clean' is run.
*** Bug 263728 has been marked as a duplicate of this bug. ***
