Yes, they would, obviously... as would any multimedia related projects.kirk wrote: The Xine FAQ page recommends 1000hz.
Code: Select all
CONFIG_USB_SUSPEND=y
Ah. I see. Of course. So then, you hand-copied all your necessary kernel modules over?Leachim wrote:I think the only problem with a non-hdd-install is, that you also have to rebuild the initrd with the appropriate new kernel modules.
The -ck patch set is said to do wonders for mplayer. Especially on an SMP system. If I glean correctly, mplayer is the only popular single-threaded multimedia player out there, and it kicks ass under -ck.Leachim wrote:I did this for the "cutting-edge-2.17-kernel" (2.6.21.5) and use it everyday under Puppy 2.15CE. As a coincidence I plan to apply Con Kolivas' patches tomorrow - maybe to a 2.6.22-kernel - let's see!
When I get results, I will post them here!
From my experience, I think you will have difficulty applying any two of these patches in combination.Sit Heel Speak wrote:I've set up hard disk installs of 2.17 on three separate partitions of the same disk...will keep one normal, make the second CFS+RT, and the third SD+RT...
MPlayer's performance is already good on my old P2-350 with old 16MB AGP graphics card. It plays DVD's faultlessly.Sit Heel Speak wrote:The -ck patch set is said to do wonders for mplayer. Especially on an SMP system.
No, I'm much to lazy, doing such things by hand ... ^^Sit Heel Speak wrote:Ah. I see. Of course. So then, you hand-copied all your necessary kernel modules over?Leachim wrote:I think the only problem with a non-hdd-install is, that you also have to rebuild the initrd with the appropriate new kernel modules.
Code: Select all
#!/bin/bash
KERNEL_VERSION=2.6.21.5
set -e
function update_gz_module()
{
while read ABSNAME
do
FILENAME=$(basename $ABSNAME)
FILENAME=${FILENAME%.gz}
SRCNAME=$(find lib/modules/$KERNEL_VERSION -name "$FILENAME")
echo updating $ABSNAME from $SRCNAME
ABSNAME=${ABSNAME%.gz}
cp $SRCNAME $ABSNAME
rm $ABSNAME.gz
gzip -9 $ABSNAME
done
}
function update_module()
{
while read ABSNAME
do
FILENAME=$(basename $ABSNAME)
SRCNAME=$(find lib/modules/$KERNEL_VERSION -name "$FILENAME")
echo updating $ABSNAME from $SRCNAME
cp $SRCNAME $ABSNAME
done
}
find mnt/lib/modules/$KERNEL_VERSION -name "*.ko.gz" | update_gz_module
find mnt/lib/modules/$KERNEL_VERSION -name "*.ko" | update_moduleHardinfo, it's this cool app Barry and some others found (i read that it's going in Puppy from now on).Sit Heel Speak wrote:1. What is the system info program we are seeing?
can't address this.Sit Heel Speak wrote:2. Has anyone else besides me, had trouble unpacking .zip archives when using a realtime-patched kernel (no problem though with ordinary 2.17, and no problem with ck-patched)?
don't worry, me too. i'm just sort of grasping some of this as i go and "standing on the shoulders of giants".Sit Heel Speak wrote:3. At present, I'm way beyond the upper limit of my "Peter Principle competence" here...
one would really have to review the patch to see the files that are effected. i still can't run patch unless i read directions. the first time i patched something i read the file names and line numbers out of the patch and copied and pasted the C (it was a REALLY short one).Sit Heel Speak wrote:however...my newbie question is... I wonder if the loadable kernel modules are adjusted by the choice of kernel patches + timer tick + scheduler et cetera at kernel-compile time.
i don't know for certain, but it seems highly unlikely that a kernel patch would change anything but code for the kernel (that could include any headers for the kernel).Sit Heel Speak wrote:I wonder if any other (e.g. header, library) files get likewise adjusted during the kernel compilation.
i've run across very few apps that require kernel references (only those that require loadable modules of some type). there are some, but the main things that would need updated in Puppy are a couple modem/usb-modem, wireless and "misc" modules. there are other modules for the kernel that aren't "in" the main kernel source. the afformentioned items are such. they break. for instance in my testing here, my modem is no longer recognized because the module on my machine that was compiled by someone with Puppy 2.17 source and config against that kernel image will not load with the one i recompiled.Sit Heel Speak wrote:And consequently, I wonder to what extent all applications link into the kernel modules and/or specially-adjusted headers et al at their own compile time...and/or refer during their make to the kernel .config...and therefore require recompilation if the kernel is hacked.
init is a shell script that runs against busy box which runs ontop of gcc. it's two layers out from the kernel and seems to work fine from my tests.Sit Heel Speak wrote:Furthermore I wonder to what extent timings must be adjusted in the init scripts, when using such a kernel.
i don't think it is.Sit Heel Speak wrote:If app code is indeed so influenced...
....although it does seem to effect performance "just a bit".John Doe wrote:i don't think it is.Sit Heel Speak wrote:If app code is indeed so influenced...
