Originally Posted by pali

@412b: standard rules for /opt is that every 3rd application will install data to /opt/<app_name>/. This comes from UNIX.

/opt/<package> or /opt/<provider>

The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.

Originally Posted by pali

But there is no special reason.

Originally Posted by zerox

Firstly, thank you for all your work on the power kernel, and on the functionalities which it enables, most recently KP51 and the new USB Mode Switch.

However, after installing and testing KP51, I have once again found myself reverting to the stock kernel, as I have done previously after installing KP49 and KP50. The reason is that the power kernels seem to degrade the quality of SIP and Skype calling, and this is a deal-breaker for me.

I have searched the forums and found that other users have reported similar experiences. Some of these users believe that the problem arises from the changes in the way the power kernel controls cpu scaling and power management.

Would it be possible for you to produce, or advise how to produce, an experimental kernel which follows the stock kernel's approach to cpu scaling and power management (i.e. no support for overclocking/undervolting), while retaining as many as possible of the other changes which make the power kernel so useful?

Thanks for any help you can give, and again, please accept my sincere appreciation of the work that you do.

Originally Posted by zerox

Firstly, thank you for all your work on the power kernel, and on the functionalities which it enables, most recently KP51 and the new USB Mode Switch.

However, after installing and testing KP51, I have once again found myself reverting to the stock kernel, as I have done previously after installing KP49 and KP50. The reason is that the power kernels seem to degrade the quality of SIP and Skype calling, and this is a deal-breaker for me.

I have searched the forums and found that other users have reported similar experiences. Some of these users believe that the problem arises from the changes in the way the power kernel controls cpu scaling and power management.

Would it be possible for you to produce, or advise how to produce, an experimental kernel which follows the stock kernel's approach to cpu scaling and power management (i.e. no support for overclocking/undervolting), while retaining as many as possible of the other changes which make the power kernel so useful?

Thanks for any help you can give, and again, please accept my sincere appreciation of the work that you do.

Originally Posted by zerox

Firstly, thank you for all your work on the power kernel, and on the functionalities which it enables, most recently KP51 and the new USB Mode Switch.

However, after installing and testing KP51, I have once again found myself reverting to the stock kernel, as I have done previously after installing KP49 and KP50. The reason is that the power kernels seem to degrade the quality of SIP and Skype calling, and this is a deal-breaker for me.

I have searched the forums and found that other users have reported similar experiences. Some of these users believe that the problem arises from the changes in the way the power kernel controls cpu scaling and power management.

Would it be possible for you to produce, or advise how to produce, an experimental kernel which follows the stock kernel's approach to cpu scaling and power management (i.e. no support for overclocking/undervolting), while retaining as many as possible of the other changes which make the power kernel so useful?

Thanks for any help you can give, and again, please accept my sincere appreciation of the work that you do.

Originally Posted by reinob

Hi Pali or anyone who can answer this!

I'm now following your instructions to compile kernel-power
(cd kernel-power-2.6.28; dpkg-buildpackage -b -rfakeroot)

Since I'm not familiar with dpkg stuff, I thought I might just ask you:

If I want to change the .config (which only gets applied after/during dpkg-buildpackage), can I just run "make menuconfig" after having run dpkg-buildpackage and then run it again after having edited the .config?

(I'm home alone this weekend, so I'm going to try it anyway, but a quick confirmation would be nice).

My plan is to remove some stuff and add some other stuff. Will let you know if I get anywhere..

Edit: I managed to add a patch file to the right place so that the whole debian-circus worked OK.

Unfortunately I made a beginner mistake with my N900 (replaced getbootstate with a shell script just returning "USER". Forgot to chmod +x it. G*d*mnmot*erf*cki*gsh*t! My spare N900 is essentially unflashable. Linux doesn't consider it a valid device and the syslog spits a thousand errors (-110 and so) about the connected device. In-kernel charging works, sorta, but I cannot use the dedicated mode (with the wall charger, obviously), so it charges about 50mAh per hour, at most).

I guess it's time to take the second spare..

Originally Posted by [Knuckles]

Hello.
First post here, hope I don't step on any bear traps

I've been playing with using UDF instead of fat32/ntfs/ext234/whatever on my flash devices and external hard drives, since it's a filesystem that
a) has read-write support in linux and windows (7, I think XP doesn't like it) without extra software
b) is better than fat because it supports large files
c) is better than ntfs because it supports unix semantics (and for full ntfs on linux you need ntfs-3g and fuse)

Some more info:
http://serverfault.com/questions/550...d-drive-as-udf
http://superuser.com/questions/39942...sb-flash-drive

Anyway, UDF is listed as being supported by kernel-power, but at first it didn't work for me.
I then discovered that this fix is "needed":
https://git.kernel.org/?p=linux/kern...1d4d4b9781a555
Quoting from stackexchange:

Code:

Linux with an older kernel: needs the bs=512 option to mount, because it incorrectly used 2048 instead of the device sector size (fixed in commit 1197e4d).

Would it be possible for this patch to be included in KP?

Thanks for all your work!