hi takashi, thanks for the info, but the ftp requires username and password, which i dont know ..... anonymous access is not possible to the url you posted ...... yup, including a "multimedia kernel package" sounds like a good solution, so people can choose if they want to run a server or a multimedia machine (or a normal workstation, of course ;) um, the instructions for using a default source tree is ok, thats what i tried already .... it works, but not 100% clean as with a suse kernel. maybe i made an error somewhere .... dont know. it always broke my system somehow, was unstable. and even with a default kernel where i have no patches applied. no problem with suse kernels, so that couldnt be some compiler/bad memory issue or the like. i dont use initrd's anyway, because i dont want to create a new initrd all the time just get boot-time-needed modules in it when they change/move. and because im not booting off a floppy or similar, why should i have a compressed image anyway ?? i just tried the ll and kgi patches that failed here on a suse system on a second machine where i installed debian (got this cd from a magazine) what should i say, all went smooth, no quirks ....... so my mm-development will take place on that machine now, until i get at least the ll patches running on suse (if i only could access the url you posted ....) the kgi site _looks_ like there is no development currently, but thats only a impression. in the cvs there are more recent version than on the site. only reason for me to use kgi is for my realtime video add-ons to jmax im currently writing. graphic output of bitmaps is somewhat slow in a standard x system, and takes way too much cpu power ..... so i thought kgi may give some speedup there. i will see the next days if this is true on the other machine. anyway, thanks, chris Am Montag, 26. November 2001 14:40 schrieben Sie:
Hi,
At Sat, 24 Nov 2001 10:57:02 +0100,
Christian Klippel wrote:
hi all, esp. @ suse !
in the past time i ran into several "problems" with suse's style of "messing up" the kernel sources in respect to the standard ones. there are some enhancements/patches i really would like to use, and that i also would recommend suse to somehow integrate it into their's ...
first of all, there are the low-latency patches, this is esp. usefull when working with realtime audio manipulation/generation ..
I admit it's not quite straightforward to apply the patch to SuSE kernel. We've discussed about integration of LL patches but still not happen just because of its maintenance problem. I've provided patchset at ftp://ftp.suse.com/pub/people/tiwai/suse-patches for some kernels. Please give a try. Hopefully such a patchset will be included in the next release (even if not compiled in)..
always had problems to get this into a suse kernel, while at the same time it is often hairy to get a "normal" kernel running on a suse system .... (at least i had never real luck with this, it boots, ok, but half of the system wont work if not heavily changed to non-suse defaults, as found on other systems)
This is not true. Compiling a vanilla kernel and installation are quite normal like other distros. Only difference is creation of initrd. SuSE provides mk_initrd script while RedHat's one is name mkinitrd. The modules to be inserted are listed in /etc/rc.config. So, let me write down the procedure briefly:
1. extract linux tarball (1.5. apply patches) 2. edit kernel configuration 3. make dep && make bzImage && make modules 4. become root and make modules_install 5. install arch/XXX/boot/bzImage to /boot/vmlinuz (or what else as you like) 6. run mk_initrd. no option is required when you installed a kernel image as /boot/vmlinuz. Otherwise, use -k and -i option to specify its name. make sure what modules will be loaded (see /etc/rc.config) 7. run lilo. if you use non-standard kernel image and initrd files, edit /etc/lilo.conf before this. 8. reboot - amen.
next thing is the kgi extension (http://kgi.sf.net) to get somewhat faster graphics handling in linux. i have seen/worked with this a little on another machine, where install/patch/etc. of the kernel and that package went fine, but no go under suse (im using 7.2 at the moment) this is something i really miss, since output to default x windows is somewhat slow without such enhancements. not to think about about realtime video manipulation (which im currently programming) ....
Hmm, no clue about this. How about to ask this on kgi's ML? My rough guess is incompatible kernel or permission under /dev. Anyway it's diffult to determine without precise info..
so, would be nice to hear if someone ever got one of the mentioned extensions running on suse, and esp. to hear what suse has to say about that. just packing tons of picture viewers and audio players doesnt make any distribution usable for real multimedia usage, and what suse offers in its distributions is (forgive me) an almost toy-ish try to give the impression of multimedia under linux .... but not only the apps itself are important, also enhanced support for handling multimedia in general is a _very important_ thing, so i really wonder about the usability of the two packages mentioned above together with suse ..... remember, i had no problems (two times !) to get these working on non-suse linux distros, but always failed on suse ..... but to get high performance these are needed/very usefull ..... i want to use suse in the future too, but if this lack of multimedia support is continuing in suse in the future, i have no other choice than to switch and drop suse ........ at least suse should provide packages of the above that work on suse systems ....
As said above, LL patch already exists. Sorry that it's still not integrated into our kernel, but please understand that such a patch is difficult to apply since we need to check what each code exactly does and which side effects it would cause, too. Such an essential patch affects the performance of kernel very severely, and this is not preferable for server machines (this is the major target, I must say, at this moment of linux - multimedia is still a follower). Prehaps creating a new kernel package for multimedia would be an alternative solution.
Regarding KGI, I have no idea at all, whether someone works on it. As long as looking at KGI's webpage, it seems that KGI itself is being not so actively developed, though..
ciao,
Takashi
-- visit me at http://mamalala.de