Originally Posted by 412b

Learning cycle starts below 3248mV (EDV1 stored in EEPROM), OS shutdowns device at about 3200mV (a bit less in fact), so to start a learning cycle you just need to follow simple steps:
1. Fully charge the device.
2. Let it discharge without pluging-in power to the [3200mV, 3248mV]
3. Plugin-in power before it shutdowns and fully charge.
4. Repeat untill there will be a right learning cycle.
I spent a lot of time to make it do a learning cycle, but finally it did.
Moreover about specific of learning cycle here

Originally Posted by freemangordon

The work was suspended for a while (I was working on CSSU tasknav). Hopefully tasknav is bugfree now (at least on gitorious) so I will use my free time for some other tasks.

Till now the status (with DSP patch and 720p playback) is:

- DSP kernel patch breaks MP4 playback with stock userland libraries, H264 is working. In order to have all stuff working lots of usermode components need to be changed(dsp codecs, gst-dsp, ti-omx, omapfb, maybe mediaplayer)

- 720p playback needs 900 MHz CPU overclock, 530 MHZ DSP overclock, DSP shared memory increased from 4 MB to 5 MB, video memory increased from 4 MB to 8 MB. Only MP4, no H264. And DSP codec used is from Samsung i8910 Omnia HD, no legal way to get it. TBH the only file I have to test with is 720p video shot with some Android phone, so have no idea which profiles are supported and what the performance is.

- 720p videos played on TV - well, that could be the point I will give up. OMAP3 DSS is just not capable to downsample 1280x720 to either PAL or NTSC resolution. I was able to get picture on my TV by using PowerVR scaler, which outputs video to graphics plane, not to overlay. Result is that it overwrites buttons in media player .

What's next? Well it is summer time here , so maybe I will rest for a while. After that I have to make a choice - whether to continue playing with DSP first or to try to make portrait home for CSSU first. Anyway at some point of time DSP project will be resumed. The best thing that could happen is if Felipe Contreras gives a hand on it. When I return to DSP I will contact him and try to convince him to give some help.

In between if someone wants to continue work on it , just ask, I will give all of the source code needed.

Originally Posted by F2thaK

oh please, oh please... work on portrait homescreen!

Originally Posted by pali

At least you can publish your source code here.

Originally Posted by Estel

Also, question for Pali (or anyone, who knows for sure) - there is any way, to override EDV1 stored in EEPROM by any means (i.e. some vodoo-hacks done to bq_27x00 module), specifically for our device (N900)?

Originally Posted by [DarkGUNMAN]

I Agree, Portrait Hildon-Desktop please.

Originally Posted by F2thaK

oh please, oh please... work on portrait homescreen!

Originally Posted by freemangordon

I've already published it here (the kernel side). And you have my patch too, so it won't be lost. I was talking about user libraries, maybe a thread dedicated to DSP is better than kernel-power thread.

Originally Posted by pali

There was only one small bluetooth patch in v47. And commands which are in old post show if your problem is related to this patch.

No output means this problem has nothing with bluetooth l2cap patch.

====

How to find where is this problem:

I thought that this problem is with l2cap patch (but from Darkslayer post, it is not true). I do not have bluetooth headset, so I cannot reproduce this bug.

So the only way is using git bisect on my git repository and find which commit break bluetooth. But this must do someone who can test this problem, can use git and compile+flash kernel.

Originally Posted by vi_

OMG STFU. N900 is not a portrait device.

Deal with it.