Active Topics
-
Maemo repository (9)
to Community by nokiafemboy - 2 hrs, 24 mins ago -
Error after installing Leste on sdcard (18)
to Maemo 7 / Leste by Maemish - 17 hrs, 48 mins ago -
Maemo 20th Anniversary (4)
to Brainstorm by teroyk - 2 days, 12 hrs ago -
Nokia Booklet 3G (RX-75) Drivers (64)
to Alternatives by teroyk - 2 days, 13 hrs ago -
Porting apps to Leste (46)
to Maemo 7 / Leste by teroyk - 4 days, 16 hrs ago - more...
 |
|
2011-09-15
, 04:20
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#292
|
IDont, according to last irc meeting @ mamemo-kernel-power, Pali will be releasing kp49 quickly (mostly, to fix bug known as "save as"), so he won't be able to introduce *every* path created by colin.stephane and freemangordon up to date (for example, further tweaking of FM transmitter API's).
That mean bfs kernel will be "little" ahead - which I think is all right due to spirit of project
Just posting this, to avoid confusion, when You'll find out that some updates you've included didn't made it to kp49. "they" will, just later.
It's also possible (but I think unlikely) that patches to be found on kp49 will be tweaked a little further before releasing (compared to ones from link I've provided), so it may be good to keep an eye on code and update things that seems sane.
I know it sounds little messy, I hope freemangordon and colin.stephane will finally request maintainership and we're gonna get more predictable update stream
That mean bfs kernel will be "little" ahead - which I think is all right due to spirit of project
Just posting this, to avoid confusion, when You'll find out that some updates you've included didn't made it to kp49. "they" will, just later.It's also possible (but I think unlikely) that patches to be found on kp49 will be tweaked a little further before releasing (compared to ones from link I've provided), so it may be good to keep an eye on code and update things that seems sane.
I know it sounds little messy, I hope freemangordon and colin.stephane will finally request maintainership and we're gonna get more predictable update stream
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2011-09-15
, 12:12
|
|
Posts: 111 |
Thanked: 27 times |
Joined on Apr 2010
|
#293
|
this is the most amazing mod ive ever done. without fail. i would suggest it has made my device about 35 percent faster. overclocked to 1100, the same as i had with power48. and limiting the scaling to 4 frequencies. the speed is phenominal. fantastic work everyone! im chuffed!
*edit. only thing is tactile feedback seems to have been enabled and i dunno how to turn it off. seems to vibrate slightly when pressing screen. any ideas?
*edit. only thing is tactile feedback seems to have been enabled and i dunno how to turn it off. seems to vibrate slightly when pressing screen. any ideas?
|
|
2011-09-15
, 12:21
|
|
Posts: 41 |
Thanked: 13 times |
Joined on Feb 2010
@ Australia
|
#294
|
just uninstall it.
apt-get remove tactile
apt-get remove tactile
|
|
2011-09-15
, 12:26
|
|
Posts: 111 |
Thanked: 27 times |
Joined on Apr 2010
|
#295
|
i get 'tactile is not installed so not removed'.
also when opening xterm get....
BusyBox v1.19.2 (Debian 1.19.2power1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
-sh: /home/user/.bashrc: line 5: can't create /dev/cgroup/cpu/user/2600/tasks: nonexistent directory
-sh: /home/user/.bashrc: line 5: can't create /dev/cgroup/cpu/user/2600/notify_on_release: nonexistent directory
*edit.... now im really confused about the tactile vibration. i dont have it installed, its set to 0 in the cssu transitions.ini. it seems to only vibrate sometimes and vary in vibration. what on earth?!
*edit 2.... fixed it! was just the touch vibration option under display. durrr. somehow reenabled on install
Last edited by imacmillan; 2011-09-15 at 16:01.
also when opening xterm get....
BusyBox v1.19.2 (Debian 1.19.2power1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
-sh: /home/user/.bashrc: line 5: can't create /dev/cgroup/cpu/user/2600/tasks: nonexistent directory
-sh: /home/user/.bashrc: line 5: can't create /dev/cgroup/cpu/user/2600/notify_on_release: nonexistent directory
*edit.... now im really confused about the tactile vibration. i dont have it installed, its set to 0 in the cssu transitions.ini. it seems to only vibrate sometimes and vary in vibration. what on earth?!
*edit 2.... fixed it! was just the touch vibration option under display. durrr. somehow reenabled on install
Last edited by imacmillan; 2011-09-15 at 16:01.
|
|
2011-09-16
, 19:31
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#296
|
Originally Posted by hawaii
I haven't got any experience with building the bleeding-edge wl1251 driver, but here are the fcam-drivers: https://garage.maemo.org/frs/downloa....7-2_armel.deb.
FWIW,
fcam-drivers and bleeding-edge-wl1251 will need to be rebuilt against the headers for the most recent bfs6 builds. I'm looking at you, Tigerite :P
I've modified the source to include kernel-bfs' fcam drivers next to the ones for kernel-power and kernel-omap, instead of having one of the last two replaced. This new fcam package should be pushable to Maemo's repositories too.
By the way, about the wlan1251 driver, pali noted it's on his TODO list to look into integrating it into kernel-power, which would IMO be a really nice and clean solution.
Originally Posted by Estel
We've been there before; It's just that we hadn't made any releases back then
That mean bfs kernel will be "little" ahead - which I think is all right due to spirit of project
.
Originally Posted by Estel
I'll keep an eye on the source, thanks for mentioning.
It's also possible (but I think unlikely) that patches to be found on kp49 will be tweaked a little further before releasing (compared to ones from link I've provided), so it may be good to keep an eye on code and update things that seems sane.
Originally Posted by imacmillan
Whoa, I'm glad you're content with kernel-bfs
this is the most amazing mod ive ever done. without fail. i would suggest it has made my device about 35 percent faster. overclocked to 1100, the same as i had with power48. and limiting the scaling to 4 frequencies. the speed is phenominal. fantastic work everyone! im chuffed!
Last edited by iDont; 2011-09-16 at 19:34.
| The Following User Says Thank You to iDont For This Useful Post: | ||
|
|
2011-09-16
, 20:36
|
|
Posts: 145 |
Thanked: 91 times |
Joined on Jun 2010
|
#297
|
Originally Posted by iDont
yeah you were right... the call distortion came back now to an extent where I had them even a few times a day. strange thing though that I haven't experienced it even once in some days after the cssu update.
In my experience, some short distortion means that the problem is still there, and that you'll eventually get a more severe distorted call later. Please do report back though
I've been talking with Tigerite about releasing kernel-bfs to Maemo's repositories with only the BFS patches enabled up to v0.330. This because of the following reasons:
a) I don't see the distortion being fixed anytime soon
b) kernel-bfs has some advantages over kernel-power. For example the -ck patches. (Subjective point)
c) BFS 330 is still BFS. Whilst it isn't the latest version, it still offers BFS' (design) advantages over CFS.
I've been running this configuration as my stable configuration for several weeks now, without any issues. Expect this release soon.
anyway I'm just giving the new kernel with bfs 330 a try and it's working pretty smooth, thanks!
|
|
2011-09-26
, 15:45
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#298
|
Hey iDont, I have idea, that may make BFS kernel even more bleeding-edge
As You may remember, there was a path in power-kernel tree, that allowed bq27x00_battery module and BME to live together (happily). Path was turned off, due to it being violating standards (theoretically, bq_27x00_battery and BME should not access same i2c). Ho ever, there was *never* true report of it causing any problems (every one I've heard of, resulted in finding other source of problems), so decision was rather "ideological" than practical. AFAIK, no one know why it worked perfectly (when theoretically, it should not), and we won't know, cause BME is closed source - there is possibility, that something there is also "out of standards"l, allowing combo to work
If You could enable it in BFS kernel, many, many people would be happy penguins (including me ). I'm sure it would bring quite wider audience for project, but, more importantly, it would be in spirit of project - incorporating features that are working great and bringing joy, but denied mainline
/Estel
// Edit
If someone wonder, why even bother - let me name first thing from top of my head. Using it with advanced power monitor (and after calibrating fuel gauge chip), we can make our battery status applet to show *real* amount of battery left, with mistake lower than +-0,1% (absolutely true mAh readings + battery percentage readings).
As You may remember, there was a path in power-kernel tree, that allowed bq27x00_battery module and BME to live together (happily). Path was turned off, due to it being violating standards (theoretically, bq_27x00_battery and BME should not access same i2c). Ho ever, there was *never* true report of it causing any problems (every one I've heard of, resulted in finding other source of problems), so decision was rather "ideological" than practical. AFAIK, no one know why it worked perfectly (when theoretically, it should not), and we won't know, cause BME is closed source - there is possibility, that something there is also "out of standards"l, allowing combo to work
If You could enable it in BFS kernel, many, many people would be happy penguins (including me
). I'm sure it would bring quite wider audience for project, but, more importantly, it would be in spirit of project - incorporating features that are working great and bringing joy, but denied mainline /Estel
// Edit
If someone wonder, why even bother - let me name first thing from top of my head. Using it with advanced power monitor (and after calibrating fuel gauge chip), we can make our battery status applet to show *real* amount of battery left, with mistake lower than +-0,1% (absolutely true mAh readings + battery percentage readings).
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2011-09-27
, 19:28
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#299
|
Originally Posted by Estel
Well, being bleeding-edge is not a goal in itself; it just happens to come with many goodies
Hey iDont, I have idea, that may make BFS kernel even more bleeding-edge
Originally Posted by Estel
Yes, I've noticed the whole i2c-dev patch discussion on IRC. Personally, I think the patch should be left disabled. I know there aren't any confirmed reports on it causing trouble, but this doesn't alleviate the fact that you're removing a very important safety mechanism.
As You may remember, there was a path in power-kernel tree, that allowed bq27x00_battery module and BME to live together (happily). Path was turned off, due to it being violating standards (theoretically, bq_27x00_battery and BME should not access same i2c). Ho ever, there was *never* true report of it causing any problems (every one I've heard of, resulted in finding other source of problems), so decision was rather "ideological" than practical. AFAIK, no one know why it worked perfectly (when theoretically, it should not), and we won't know, cause BME is closed source - there is possibility, that something there is also "out of standards"l, allowing combo to work
If You could enable it in BFS kernel, many, many people would be happy penguins (including me
However, to give everyone some freedom of choice, I've created a patch that allows you to toggle the safety mechanism in question on or off at runtime. The patch consists of Matan's original patch + some sysfs code wrapped around it (from the kernel documentation, with love). I've used a slightly provocative name for the sysfs entry, but that seems only fair considering what you're actually doing
.If you understand the risks of the (original) patch, then here goes the tutorial:
Code:
Nokia-N900:~# cd /sys/kernel/n900/ Nokia-N900:/sys/kernel/n900# echo 1 > i2c-dev_break_ioctl
Code:
Nokia-N900:/sys/kernel/n900# modprobe bq27x00_battery Nokia-N900:/sys/kernel/n900# stop bme bme (stop) running, process 774 bme (stop) pre-stop, process 2184 main process 774 bme (stop) stopping, process 774 bme (stop) killed, process 774 bme (stop) post-stop, process 2187 bme (stop) waiting Nokia-N900:/sys/kernel/n900# start bme bme (start) waiting bme (start) starting bme (start) pre-start, process 2201 bme (start) spawned, process 2207 bme (start) post-start, (main) process 2207 bme (start) running, process 2207
Code:
Nokia-N900:/sys/kernel/n900# dmesg | grep HACK [ 351.532806] i2c-dev: HACK: omitting lock (EBUSY) [ 351.532836] i2c-dev: HACK: omitting lock (EBUSY)
Precompiled debs plus the patch itself can be found on kernel-bfs' garage page. Please test it and report back. I haven't got any previous experience with kobjects/sysfs, so some elements of the patch could probably be implemented in a cleaner manner. This doesn't affect its workings however. Feedback is appreciated / patches are welcome
.p.s. I'll send the patch to pali later as well.
edit 2: patch is sent. Pali replied that he's already working on a different solution which works by redirecting ioctls. That solution allows us to have both bq27x00_battery and bme working together without removing the safety mechanism in i2c-dev. There's no ETA on that yet though.
Last edited by iDont; 2011-09-29 at 17:02.
|
|
2011-09-28
, 00:22
|
|
Posts: 1,042 |
Thanked: 430 times |
Joined on May 2010
|
#300
|
hello iDont just wanna ask is the call distortion problem still exist on the current builds?
fcam-drivers and bleeding-edge-wl1251 will need to be rebuilt against the headers for the most recent bfs6 builds. I'm looking at you, Tigerite :P