maemo.org - Talk - [Announce] CSSU Testing thread

Sure, that's fine -- but it brings up another point. Just what userbase is the CSSU intended to serve? Certainly, devs and power users can enjoy it now; but this "debugging dev only" option seems likely to trip up novice users. You really need to do a lot of massaging of config files to get this "feature" working right. So, is this really meant to be the next "Seamless Software Update"?

Forced-rotation comes as disabled.
It's just muppets that install all sorts and modify things they don't understand.
Your not going to fix this easily.

Yes, we all start as novices at some point.
From some of the stupid questions on here (many repeated over and over) you can tell the difference between a muppet and a genuine novice.

Quote:

Originally Posted by marmistrz (Post 1287620)

And if an user really wants it, he just edits .desktop

So instead of having one text file to add package names, you will have to enter every apps .desktop file to test portrait support.

Quote:

Originally Posted by Copernicus (Post 1287607)

Yeah, but if the user then wants to force the rotation of that app, they have to both turn the forcerotation on, and edit the .desktop file. Kind of a pain.

I guess that's my question -- is forced rotation still meant to be a debugging tool (so having lots of broken apps around when you turn it on is fine), or a feature (where you want all apps to work correctly)? It just doesn't seem designed efficiently for use as a feature...

Exactly. Agreed, Glad the question has been brought up.

Copernicus

2012-10-30 22:18

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by sixwheeledbeast (Post 1287757)

Forced-rotation comes as disabled.
It's just muppets that install all sorts and modify things they don't understand.

Are you saying here that forced-rotation actually is just a debugging tool, and therefore not meant for general use? ;)

The sense I'm getting from the discussion is that forced rotation is one of the most popular features of CSSU. Power users, novices, muppets, everybody -- the first thing they want to do with the CSSU is play with rotation.

Personally, I think it is unreasonable for us to assume that normal users of CSSU aren't going to want to turn on forced rotation. And as such, I'd prefer that it be already turned on, but only for those apps that benefit from it; rather than have it hidden away, and need significant configuration after being turned on to fix all the things it inevitably breaks...

don_falcone

2012-10-30 22:32

Re: [Announce] CSSU Testing thread

...something different now, maybe? Thanks! Who recompiled contacts-db? Opening call logs and messages is very quick now!

sixwheeledbeast

2012-10-30 22:52

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by Copernicus (Post 1287782)

Are you saying here that forced-rotation actually is just a debugging tool, and therefore not meant for general use? ;)

Yes. All be it used for the wrong purpose now.

Quote:

Originally Posted by Copernicus (Post 1287782)

The sense I'm getting from the discussion is that forced rotation is one of the most popular features of CSSU. Power users, novices, muppets, everybody -- the first thing they want to do with the CSSU is play with rotation.

And... it clearly states on the CSSU wiki (or on a sub-page) that forced-rotation will be unstable and is a development tool.
Any application not working in portrait is not bug.

Quote:

Originally Posted by Copernicus (Post 1287782)

I'd prefer that it be already turned on, but only for those apps that benefit from it; rather than have it hidden away, and need significant configuration after being turned on to fix all the things it inevitably breaks...

I partially agree.
I feel CSSU should act like stock Maemo PR1.3.
When forced-rotation is chosen to be enabled, it's forced-rotation is controlled, so only the apps benefit from it are forced.
This makes a better experience to user/muppet-land.

branja

2012-10-30 23:53

Re: [Announce] CSSU Testing thread

How can I check what version is my phone on?
It seems that I f... up something & I can't get it to update...it even says that I don't have cssu installed & I've installed it.

When I try to update anything via x term I get: ": GPG error: https://downloads.maemo.nokia.com ./ Release: The following signatures were invalid: KEYEXPIRED 1349249546 KEYEXPIRED 1349249546 KEYEXPIRED 1349249546
W: GPG error: https://downloads.maemo.nokia.com ./ Release: The following signatures were invalid: KEYEXPIRED 1349249546 KEYEXPIRED 1349249546 KEYEXPIRED 1349249546
W: GPG error: https://downloads.maemo.nokia.com ./ Release: The following signatures were invalid: KEYEXPIRED 1349249546 KEYEXPIRED 1349249546 KEYEXPIRED 1349249546
W: GPG error: http://marmistrz.net63.net fremantle Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9431AED09369EB78
W: You may want to run apt-get update to correct these problems
Nokia-N900:~#"

tnx in advance...

freemangordon

2012-10-31 06:37

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by Copernicus (Post 1287782)

Are you sure you are not mixing the things? As CSSU comes with two "portraits":

1. Portrait mode support for hildon-desktop, task navigator and applications, which is disabled by default in -stable branch and needs to be explicitly enabled by the user

2. forced rotation, which is causing you the problems with pierogi

The first one is an officially supported feature, the second is not.

sixwheeledbeast

2012-10-31 07:29

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by branja (Post 1287830)

USEFUL INFORMATION

Kernel Version

Code:

uname -r

in a terminal.

Kernel Frequencies

Code:

sudo kernel-config show

in a terminal.
Should be 250-600Mhz, and SR VDD1 & 2 on with KP50>

OS Version

Code:

Settings > About (Community SSU)

Latest PR1.3.1 = 21.2011.38-1
Latest CSSU Stable = 21.2011.38-1Smaemo4.1

The EXPIREDKEY has been covered in another thread and will not stop you updating.

freemangordon

2012-10-31 07:48

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by branja (Post 1287830)

Google might be your friend sometimes

http://talk.maemo.org/showthread.php?t=87208

branja

2012-10-31 09:23

Re: [Announce] CSSU Testing thread

kernel: v52
Frequencies: I use it OCed on a daily basis. 500-900; VDD1 is 0, VDD2 is 1; ignore nice load is 0; threshhold is 85; sampling rate is 150000; powersave bias is 0...
OS version: PR1.3.1 = 21.2011.38-1
CSSU...the thing is, I don't have that in options. That is why I asked what is wrong with my device in the first place.
Also, when I tried to manage views on hildon desktop, it appears that I only have 4 backgrounds...& when I've tried to change something in the CSSU features it says ''warning: community ssu is not installed'' and I installed it a long time ago (CSSU testing, to be precise).

Copernicus

2012-10-31 12:30

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by freemangordon (Post 1287923)

Are you sure you are not mixing the things? As CSSU comes with two "portraits"
...
The first one is an officially supported feature, the second is not.

Could be. But, from what I've seen the last couple of days, "forced rotation" has got to be one of the most loved and heavily used unsupported features I've ever seen. People have apparently been putting hours of work into carefully crafting extensive blacklists for the thing.

Ultimately, yeah, I'm here because it does impact Pierogi. And, it seems like folks here are highly motivated to keep it. As such, my request is that it be made an official feature of CSSU, and set up in such a way that it break less apps when used... :)

freemangordon

2012-10-31 13:57

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by Copernicus (Post 1288087)

Feel free to help:

https://gitorious.org/community-ssu/hildon-desktop

with either merge requests or with ideas on how to make things better.

#maemo-ssu on freenode IRC is the place where discussions happen, join us and share what and how you think has to be done.

It happened that we've been discussing "portrait/landscape" stuff (esp how Qt handles it) for the past couple of hours, you may want to read today's log of the same channel.

Copernicus

2012-10-31 15:30

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by freemangordon (Post 1288132)

Feel free to help:

Let me poke around a bit and see if I can catch up to the CSSU world. :) (The downsides to me helping are that (a) I haven't even yet installed CSSU on my N900s myself, and (b) I'm terrible with IRC. Every time I've used IRC, I end up screwing up something or other, embarrassing myself and annoying the heck out of all the other users. :) )

I'll start going through the archives again, and maybe begin work again on that Wiki page I never finished...

pali	2012-11-07 00:30

Re: [Announce] CSSU Testing thread

I created new battery status area plugin (based on old MAG version). It work with BME or with bq27x00_battery kernel driver. It is like original Nokia version, plus display percentage, remaining time and capacity.

Please test it and write if this can go to CSSU :-)

Source: https://gitorious.org/community-ssu/...applet-battery
DEB: now in CSSU

misiak

2012-11-07 00:51

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291294)

Works for me on my testing device, on CSSU-thumb, 2.6.28.10-cssu3 kernel, BME :) it required "killall hildon-status-menu" after installation. At first I thought it would display percentage on the icon and was disappointed, but after a second discovered that it displays this data after opening hildon-status-menu :) Great it's even localized! it says "Battery" and "hours" in my language, that's nice :)

One question: how is the remaining time calculated? my testing device is usually just running for a few days with very little usage (0.5-1h daily at max), it was running for something around 3 days now, your widget says: "Battery: 53%, 692/2387 mAh, 3 hours" - why only 3 hours? ;) Do you have a thread here or a bugtracker to report such issues?

edit: command

Code:

hal-device bme

returned

Code:

...

battery.remaining_time = 10800 (0x2a30) (int)

...

and I see in https://gitorious.org/~pali/communit...plet-battery.c (lines 205-231) that this is the value that you're treating as value in seconds. So either bme is wrong or interpretation of this value is wrong. By the way, nice reuse of strings from osso-clock, mediaplayer and osso-display ;) when you took days from osso-clock, didn't it also have hours? ;) and, side note (don't take it personally, as it's not aimed at you) - by looking at lines 129-163 i was suprised how lamer-ish the displayed graphics is :D

edit 2: "hal-device bme" returned exactly the same value of battery.remaining_time on my second n900 (10800). I need to say that both have similar percentage, thought (testing one has still 53% while the other one has 45%).

edit 3: the second device uses cssu stable, kernel 2.6.8.10-power51 (that's what uname -r says, but that's the "r1" version).

foobar

2012-11-07 00:52

Re: [Announce] CSSU Testing thread

Thanks! Seems to work fine, though I'm not sure the remaining time is very accurate. Says 3 hours for 58%. :)

Edit: Latest CSSU-thumb and BME here.

pali	2012-11-07 09:45

Re: [Announce] CSSU Testing thread

In hald-addon-bme documentation is written that "battery.remaining_time" key is in seconds. And in HAL documentation is written that remaining_time is also in seconds. I really do not know how BME calculate this time...

If you have kernel-power, you can stop BME and load bq27x00_battery kernel module for battery information. Status menu plugin automatically switch to bq module if is loaded/unloaded.

toxaris

2012-11-07 10:13

Re: [Announce] CSSU Testing thread

Like this?:

Code:

stop bme

modprobe bq27x00_battery

Just to be shure ;)

misiak

2012-11-07 10:16

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291395)

I know, with your kernel module it shows more possible value ;) either the documentation is wrong or my n900 (and foobar's one?) is somehow broken. I charged my main (cssu stable) device overnight, now it has 84% and battery.remaining_time is 14400 (0x3840) which would be 4h... oh, wait, this is funny, percentage dropped to 83 and battery.remaining_time is now 18000 (0x4650) which would be 5h. Strange, I think I'll write a script which will check these two values every 10 minutes and run it in the background after my next full charge untill almost full discharge.

edit: 82% and 14400 again.

edit 2: 81% and enormously low 3600 (0xe10)... and for 80, 7200 (0x1c20) - something is really messed up in here. and again, 10800 for 80... maybe it is the current value based on the device usage in the very moment? i'll play with it later:)

pali	2012-11-07 10:21

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by toxaris (Post 1291405)

Like this?:

Code:

stop bme

modprobe bq27x00_battery

Just to be shure ;)

Yes. Note that if you want to charge battery you need also kernel module bq2415x_charger. And due to HAL "battery charging" state is updated every 10-20s, so notification will not be immediately as you (un)plug charger.

toxaris

2012-11-07 11:39

Re: [Announce] CSSU Testing thread

Hmm, dont know if this is right but this is how it looks like on my phone.
I run this:

Code:

stop bme

modprobe bq27x00_battery

modprobe bq2415x_charger

(im running CSSU-T, KP51r1, Thumb4).
http://toxaris.com/battery.png

pali	2012-11-07 12:09

Re: [Announce] CSSU Testing thread

@toxaris, it should be fixed now. Updated version of DEB package is on same URL.

guilledoc

2012-11-07 14:40

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by toxaris (Post 1291429)

Hmm, dont know if this is right but this is how it looks like on my phone.
I run this:

Code:

stop bme

modprobe bq27x00_battery

modprobe bq2415x_charger

(im running CSSU-T, KP51r1, Thumb4).
http://toxaris.com/battery.png

Same problem here recently installed
CSSU-thumb here
EDIT: sorry reboot and it´s working great Thanks a lot (I´ve wroted before even seeing your reply!! :)

pali	2012-11-07 14:43

Re: [Announce] CSSU Testing thread

After installing/updating reboot phone. If after reboot still show -1, please upload ouput of "lshal" command.

reinob

2012-11-07 15:06

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291294)

Thanks pali. Could you also add i2cget to the pack? (for those who don't have bme nor use bq27x00_battery :)

How do you decide which one to use? user preference or priorities? (bme -> bq [ -> i2c ]).

pali	2012-11-07 15:10

Re: [Announce] CSSU Testing thread

@reinob, not possible, becuase i2cget must be run under root.

misiak

2012-11-07 16:49

Re: [Announce] CSSU Testing thread

@pali and others who may be interested

I played a little with bme and searched a bit on the Internet. I found: http://www.gossamer-threads.com/list...velopers/64917 which states:

Quote:

Also, hald-addon-bme exposes the following signals under
com.nokia.bme.signal /com/nokia/bme/signal (unless otherwise specified,
these signals have no arguments)
charger_connected
charger_disconnected
charger_charging_failed
charger_charging_off
charger_charging_on
battery_full
battery_empty
battery_low
battery_state_changed (arguments for this are 2 uints, dbus type 'u',
unknown exactly what they are for)
battery_timeleft (arguments for this are 2 uints, dbus type 'u', first one
is for idle time, second is for active time)

The purpose of these signals should be self-explanatory for the most part.

Plus it exposes 2 dbus methods on com.nokia.bme.request. Both take no
parameters. The status_info_req method causes a method to be run that will
send the appropriate signals from the list above. The timeleft_info_req
method also causes the signals to be sent but it also sends a message to
BME to retrieve the relavent data for the timeout fields.

So what I did was open two terminals at the same time, in one I typed:

Code:

dbus-monitor --system

In the other (as found at https://garage.maemo.org/pipermail/p...ly/000060.html ):

Code:

dbus-send --system /com/nokia/bme/request com.nokia.bme.request.timeleft_info_req

In the first terminal, lots of info appeared after few moments, one of which was interesting for us:

Code:

signal sender=:1.8 -> dest=(null destination) serial=6836 path=/org/freedesktop/Hal/devices/bme; interface=org.freedesktop.Hal.Device; member=PropertyModified

   int32 1

   array [

      struct {

         string "battery.remaining_time"

         boolean false

         boolean false

      }

   ]

signal sender=:1.27 -> dest=(null destination) serial=48 path=/com/nokia/bme/signal; interface=com.nokia.bme.signal; member=battery_timeleft

   uint32 4260

   uint32 180

I'm not sure what these 4260 and 180 mean, but I guess this is the "real" value for idle and "busy" remaining time for battery in whatever unit.

On "hal-device bme" the value is always equal to one of (18000,10800,14400,7200,3600) for me and it changes with regard to some pattern which I completely don't understand... Maybe it's good to use this method for bme? (As soon as we aknowledge in what unit are these idle and active values reported)

Others: could you repeat my test and check values on your n900s?

reinob

2012-11-07 17:26

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291497)

@reinob, not possible, becuase i2cget must be run under root.

Mine is setuid'd, so that I can use it from a DCE widget without su/sudo-magic.

Given the number of programs that add themselves to the sudoers list (without password), I guess setting the setuid bit for i2cget doesn't make it any less secure..

Anyway, it's your program :) [ and I'm happy with my DCE widget ]

pali	2012-11-07 17:48

Re: [Announce] CSSU Testing thread

@misiak: this is already implemented in new hald-addon-bme

misiak

2012-11-07 18:56

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291538)

@misiak: this is already implemented in new hald-addon-bme

I'm sorry, but I think I don't understand ;) What is already implemented in new hald-addon-bme? I just wrote a way to fetch two values (idle + active) via dbus, which I found on the Internet. hald-device reports only one value, which is totally different than both these two (and for me seems a bit random as for battery remaining time value, but it should be treated only as my oppinion). If the method I pointed out in my previous post is already implemented in hald-addon-bme, why not use it instead of using the value you're using? (no offence intended, I just think I don't understand what you mean)

pali	2012-11-07 19:10

Re: [Announce] CSSU Testing thread

Problem is that bq27200 chip report only one value (there is no active or ide using). New hald-addon-bme sending that dbus signal too, but both values are same.

See function hald_addon_bme_timeleft_info in https://gitorious.org/rx51-bme-repla...ld-addon-bme.c

misiak

2012-11-07 21:10

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291558)

Ok, I understand. But in the file you linked I still see

Code:

...

    else if (battery_info->power_supply_status == STATUS_DISCHARGING)



    {



      CHECK_INT(power_supply_time_to_empty_avg,



            libhal_device_set_property_int (hal_ctx, udi, "battery.remaining_time", battery_info->power_supply_time_to_empty_avg, NULL));



    }

...

As well as...

Code:

...

#define BQ27200_UEVENT_FILE_PATH "/sys/class/power_supply/bq27200-0/uevent"

...

fp = fopen(BQ27200_UEVENT_FILE_PATH,"r")

...

   while(fgets(line,sizeof(line),fp))



  {



    char*tmp;



    tmp = strchr(line,'=');

...

      else if(!strcmp(line,"POWER_SUPPLY_TIME_TO_EMPTY_AVG"))



        battery_info->power_supply_time_to_empty_avg = atoi(tmp);

...

But I don't have "/sys/class/power_supply/bq27200-0/uevent" on my main n900 (i have bme, not any open replacement and neither your kernel module). So I understand this code and I think I know now what you mean.

1. your kernel module reports values in its own way and it's irrelevant here
2. hald-addon-bme from rx51-bme-replacement reports value ONLY via battery.remaining_time
3. hald-addon-bme from stock firmware (the closed one) reports value via battery.remaining_time AND reports two values via a signal I desribed earlier.

So, the rx51-bme-replacement doesn't implement the signal emission, do I get it right? (if this is true, the code of your widget could become even more complex and have 3 possible reading options, not 2 ;) )

AND, if I understand you correctly, the chip reports only one value and it's the one reported in battery.remaining_time and the values reported in a signal:

Code:

signal sender=:1.27 -> dest=(null destination) serial=48 path=/com/nokia/bme/signal; interface=com.nokia.bme.signal; member=battery_timeleft

   uint32 4260

   uint32 180

are calculated by some equation we don't know. Do I get you right?

If I understood you, is it possible that the value reported by chip (which we put in battery.remaining_time) is e.g. some kind of current (not as "electric current" but as "right here right now") power usage (some encoded value, e.g. 3600 means 500mA, 7200 means 600mA, 10800 means 700mAh, etc. - but the mA numbers are totally made up), I just noticed that these values depend on device usage - the more cpu and ram is active atm, the higher that number is (that's why I came to this conclusion, but feel free to educate me and proove me wrong, or just write I'm wrong and where I can read more about it to become less of a ***** and more of a genius ;) ).

edit: by the way, thanks for answering.

edit2: in order not to spam i answered for the next Pali's message at http://talk.maemo.org/showthread.php...28#post1291628 .

toxaris

2012-11-07 21:26

Re: [Announce] CSSU Testing thread

Hello again.
Still some stange stuff here after the update to the new deb.
I have done a few reboots too.
http://toxaris.com/battery2.png

Link to lshal dump.
http://toxaris.com/lshal.txt

pali	2012-11-07 21:47

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by toxaris (Post 1291598)

Hello again.
Still some stange stuff here after the update to the new deb.
I have done a few reboots too.
http://toxaris.com/battery2.png

Link to lshal dump.
http://toxaris.com/lshal.txt

Ok, from your output and log I see that you stopped bme and loaded bq27x00 and bq2415x drivers.

Battery design capacity (which is 0) is read from rx51_battery kernel driver, which is not loaded. But this driver is part of kernel-power v52 (prerelease), so it is not present in v51.

If status menu plugin cannot read design capacity it will try to read last full capacity.

But in HAL log is missing "battery.reporting.last_full" in /org/freedesktop/Hal/devices/computer_power_supply_battery_bq27200_0 (for bq27200 chip). This can be problem if learning cycle of bq27200 was not complete. Can you write output of this?

$ cat /sys/class/power_supply/bq27200-0/uevent
$ cat /sys/class/power_supply/bq27200-0/charge_full

pali	2012-11-07 21:54

Re: [Announce] CSSU Testing thread

@misiak,

hald-addon-bme from rx51-bme-replacement reports both "battery.remaining_time" HAL key and "battery_timeleft" dbus signal. In previous post I wrote that funcion for generating singal is "hald_addon_bme_timeleft_info". But that function (you can see) sending both values same as "battery.remaining_time".

How BME calculating that 2 times nobody know. What I know is that BME not using time value from bq chip.

For bq27200 chip see datasheet on https://focus.ti.com/docs/prod/folde...t/bq27200.html There is maybe also info how chip calculate that value.

StocChr

2012-11-08 13:34

Re: [Announce] CSSU Testing thread

is it normal, that the battery only charging to 94% and the led for low battery starts at 0% to blink?
and the remaining time disappears at lower percentages?

pali	2012-11-08 13:46

Re: [Announce] CSSU Testing thread

Percentage is calculated as current/design_capacity. So if your battery is older then it is not possible to charge it to design capacity.

Battery low signal is sent by hald-addon-bme (BME version or new replacement).

If remaining time is reported as 0, then it disappear.

For values look to lshal.

marmistrz

2012-11-08 16:45

Re: [Announce] CSSU Testing thread

Quote:

Originally Posted by pali (Post 1291294)

Wow, well done! :)
If it works flawlessly, I'd like to see it in CSSU

This should get on with Advanced Power (maybe conflict?)
I didn't test it, but it'd have great advantage over Adv. Power if it showed in which measure the time left is counted :)

tadzik

2012-11-08 21:11

Re: [Announce] CSSU Testing thread

Just installed the new battery indicator on fresh cssu-thumb. Works like a charm after a reboot, thanks.

toxaris

2012-11-10 12:46

Re: [Announce] CSSU Testing thread

1 Attachment(s)

Quote:

Originally Posted by pali (Post 1291607)

Hello.

Well maybe its about time to upgrade to KP52 then.
Today Im running CSSU Testing, and CSSU Thumb.
Is it safe to just install the KP52 debs or do I have to wait until CSSU Thumb is based upon KP52?

Anyway the output from uevent i attached.
And I get this error when I

Code:

cat /sys/class/power_supply/bq27200-0/charge_full

cat: read error: no data available

All times are GMT. The time now is 06:49.

Page 24 of 47

Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8