*** M4rtinK has quit IRC | 00:12 | |
*** rZr is now known as rzr | 00:18 | |
*** KaIRC has quit IRC | 00:53 | |
*** rzr is now known as rZr | 00:54 | |
*** KaIRC has joined #nemomobile | 01:06 | |
*** npm_ is now known as npm | 01:17 | |
*** rcg has quit IRC | 02:18 | |
*** himamura has joined #nemomobile | 02:20 | |
*** rcg has joined #nemomobile | 02:33 | |
*** KaIRC has quit IRC | 02:52 | |
*** Estel_ has quit IRC | 03:31 | |
*** Estel_ has joined #nemomobile | 03:40 | |
*** Estel_ has quit IRC | 05:04 | |
*** Estel_ has joined #nemomobile | 05:04 | |
*** furikku has joined #nemomobile | 05:20 | |
*** npm has quit IRC | 06:01 | |
*** npm has joined #nemomobile | 06:05 | |
iekku | morning | 06:25 |
---|---|---|
*** noch has joined #nemomobile | 07:08 | |
dm8tbr | moaning | 07:40 |
*** nsuffys has joined #nemomobile | 08:06 | |
*** niqt has joined #nemomobile | 08:29 | |
niqt | morning | 08:30 |
*** NIN101 has joined #nemomobile | 09:12 | |
*** vakkov_ has quit IRC | 09:14 | |
*** M4rtinK has joined #nemomobile | 09:17 | |
*** Guest17580 is now known as Jade | 09:45 | |
*** Jade has joined #nemomobile | 09:46 | |
*** rZr has quit IRC | 10:07 | |
*** Siosm has joined #nemomobile | 10:12 | |
*** Siosm has quit IRC | 10:20 | |
*** vakkov_ has joined #nemomobile | 10:36 | |
*** noch has quit IRC | 10:39 | |
*** niqt has quit IRC | 10:44 | |
*** MohammadAG has quit IRC | 10:53 | |
*** nsuffys has quit IRC | 10:54 | |
*** Estel_ is now known as dhfg | 11:52 | |
*** dhfg is now known as Estel_ | 11:52 | |
*** KaIRC has joined #nemomobile | 12:03 | |
*** Termana has joined #nemomobile | 12:14 | |
*** jluisn has joined #nemomobile | 13:11 | |
*** DocScrutinizer has quit IRC | 13:18 | |
*** DocScrutinizer has joined #nemomobile | 13:18 | |
*** phaeron has quit IRC | 13:18 | |
*** phaeron has joined #nemomobile | 13:20 | |
*** jluisn has quit IRC | 13:37 | |
*** faenil has joined #nemomobile | 14:00 | |
faenil | can anyone sum up recent happenings about nemomobile for me? :) | 14:03 |
faenil | Stskeeps, yo man :) | 14:04 |
Stskeeps | its progressing nicely | 14:05 |
faenil | Stskeeps, like? :) | 14:08 |
faenil | is anyone still working on N950 hw adapt? | 14:08 |
faenil | has anyone fixed the battery level issue? what about the stuttering when scrolling (I remember it was due to sgx drivers)? | 14:09 |
Stskeeps | i've been investigating the tearing issue, may be due to 32bpp windows | 14:16 |
faenil | oh.. | 14:17 |
Stskeeps | according to a sgx guy we met | 14:19 |
Stskeeps | but i need to verify it better | 14:19 |
faenil | and haven't you tried with different bbps? | 14:19 |
Stskeeps | we also have new wifi applet and connman coming in | 14:19 |
Stskeeps | i did, but no direct difference | 14:20 |
faenil | yeah received an email about that | 14:20 |
vakkov_ | hah, they have tearing issue when scrolling in nitdroid too | 14:20 |
faenil | mm I see.. | 14:20 |
faenil | vakkov_, nice, that is a wonderful thing, more people looking for solutions | 14:20 |
Stskeeps | they use different drivers than us though | 14:20 |
faenil | but still, I guess the root of the problem is the same... | 14:21 |
faenil | wouldn't it be possible to talk to someone at Nokia who worked on the N9? | 14:21 |
Stskeeps | we did, actually | 14:21 |
faenil | this is a little info, don't think there's NDA or such | 14:22 |
faenil | oh :O | 14:22 |
faenil | and? | 14:22 |
vakkov_ | they are using 2.6.32 kernel and TI SGX DDK | 14:23 |
Stskeeps | hence the 32bpp [B[B[Bthough tehere isnt many people left from n9 anymore | 14:23 |
faenil | Stskeeps, not in Nokia, you mean :D | 14:23 |
faenil | Stskeeps, so they fixed that by changing the bpp? :O | 14:24 |
Stskeeps | listed it as a potential problem | 14:24 |
faenil | mm ok | 14:25 |
*** Siosm has joined #nemomobile | 14:26 | |
*** Siosm has quit IRC | 14:27 | |
faenil | we could try asking him http://fi.linkedin.com/in/tuomotanskanen | 14:28 |
faenil | if he knows someone we can ask | 14:28 |
faenil | " | 14:29 |
faenil | I've often been joking about moving down a layer per each product, so that probably makes my goal as moving to full kernel guy ;-)" | 14:29 |
faenil | I can send him a message via twitter, if you think that could be helpful Stskeeps | 14:33 |
faenil | unless he's the guy you talked to | 14:33 |
*** Siosm has joined #nemomobile | 14:36 | |
*** Siosm has quit IRC | 14:37 | |
faenil | Stskeeps, do you know this guy? http://ruedigergad.com/2012/06/03/nemomer-vs-battery-status-vs-n9n950/ | 14:52 |
Stskeeps | yes, rcg | 15:04 |
Stskeeps | and don't bother messaging tuomo, he's looking for a job atm.. | 15:05 |
faenil | Stskeeps, yeah I've read that... | 15:08 |
faenil | Stskeeps, anyway, have you ever seen this? http://meego.gitorious.org/qemu-maemo/qemu/blobs/0fb63c649876cb94580f32b4590e9ddea6acf4b0/hw/n00.c | 15:09 |
faenil | I mean, talking about battery | 15:09 |
faenil | it seems to read battery temperature and voltage from twl4030 | 15:10 |
faenil | which is the power manager | 15:10 |
faenil | Stskeeps, and there is a lot of code about bq27521 too | 15:15 |
Stskeeps | maybe, i can't touch it in open sadly though | 15:18 |
faenil | what do you mean? Stskeeps | 15:19 |
faenil | Stskeeps, also, couldn't we just open an N950 and see what's the battery manager? and gauge, and whatelse? | 15:21 |
faenil | since it seems we don't know what's the chip inside the n950 | 15:21 |
faenil | rcg, ping | 15:22 |
Stskeeps | we know the chip but no public chipset | 15:24 |
faenil | oh :( | 15:25 |
Stskeeps | er, datasheet | 15:26 |
faenil | yeah read that | 15:26 |
faenil | and there doesn't seems to exist any 521 model... | 15:27 |
faenil | Stskeeps, and aren't those info available publicly? I mean can Nokia people talk about that? | 15:30 |
faenil | there's no datasheet from TI | 15:30 |
faenil | but isn't it possible to ask Nokians some info? | 15:30 |
Stskeeps | no, and in practive meego devices is gone | 15:32 |
faenil | practive meego devices is gone? Stskeeps | 15:35 |
faenil | oh | 15:35 |
faenil | the dept you mean | 15:35 |
faenil | well but that doesn't matter, people don't just disappear | 15:36 |
faenil | don't you think people who worked on the N950/N9 still have info about those things? | 15:36 |
Stskeeps | sure, but they are prohibited to share and most no longer hav e the materials | 15:38 |
faenil | social engineering :D meego is dead, what's wrong with sharing info about phones who'll never come to life :D | 15:40 |
Stskeeps | gtg | 15:40 |
faenil | cya ;) | 15:40 |
rcg | faenil: pong | 15:42 |
faenil | rcg, hey :) | 15:42 |
faenil | I was trying to get some info about the battery issue to see if there was anything I could do to help | 15:42 |
faenil | I've read the blog post and read chat pages of you and Doc | 15:43 |
rcg | faenil: roger that :) | 15:43 |
rcg | any help is highly appreciated | 15:43 |
faenil | so, what's the current status? | 15:43 |
faenil | don't know if what I have read is updated | 15:43 |
rcg | essentially, as stated in the blog post | 15:43 |
rcg | from my side, the blog post is most up-to-date | 15:43 |
faenil | mm I see | 15:44 |
faenil | so the only thing to do is reversing the dump and linking bytes to commands? | 15:44 |
faenil | "commands" | 15:44 |
rcg | i assume you also had a look at the github(?) page where i uploaded the raw results etc? | 15:44 |
faenil | yes I did | 15:44 |
rcg | that's more or less what i tried so far, yes | 15:44 |
faenil | but you didn't succeed, why? | 15:45 |
rcg | well, as you see in the blog post i _think_ i identified some interesting fields in the i2c chip | 15:45 |
faenil | yeah, and not many are missing :) | 15:45 |
rcg | however, all my attempts to come up with a suitable kernel module were unsuccessful | 15:45 |
faenil | did you just run of ideas? or found any problem? got stuck in something? | 15:46 |
faenil | what do you mean? | 15:46 |
faenil | (I'm new to low lvl stuff ;) ) | 15:47 |
rcg | there is some bug report about this issue that also includes a patch that tries to come up with a kernel module that reads data from the i2c chip and exports these via sysfs | 15:47 |
rcg | faenil: don't worry.. i am fairly new to this as well :) | 15:48 |
rcg | just gimme a sec and i will look up these things | 15:48 |
faenil | and I've never written any kernel module :D | 15:48 |
faenil | just Qt programmer out of CS uni atm :D (studying for the specialization course) | 15:48 |
rcg | faenil: right, don't worry.. am also very much doing try and error and (more or less, most times less) educated guessing ;) | 15:51 |
faenil | :D | 15:51 |
faenil | so do we only have to associate bytes with meanings, or there are also problems in reading them? | 15:52 |
rcg | there are also problems reading them | 15:52 |
rcg | let me get the info... | 15:52 |
faenil | the association shouldn't be too painful, I mean it must be a permutation of the TI's datasheet for other models | 15:52 |
faenil | rcg, oh :( | 15:52 |
rcg | that's one issue.. the ti data sheets make no sense at all when compared to what you see in the chip and what you see in the data sheet :/ | 15:53 |
faenil | but we know those are the things written in there | 15:53 |
faenil | we just don't know the order... | 15:53 |
faenil | (ok, the data sheet doesn't use proper words, but...) :) | 15:53 |
rcg | well, with respect to the data sheet: those offsets mentioned data make absolutely no sense when compared to what you actually see when reading from the chip via i2c | 15:54 |
rcg | the only thing that actually makes sense is that writing 0x0001 to 0x0000 of the chip (as word) returns 0x0521 which kinda looks like the chip version | 15:55 |
faenil | yeah | 15:55 |
faenil | but what I mean is... | 15:55 |
faenil | I guess that the addresses are different | 15:55 |
faenil | but the info (atRate() , atDischargingRate() ) must be the same.. | 15:56 |
faenil | don't you agree? | 15:56 |
faenil | maybe atRate() isn't 0x02 , but 0x0e | 15:56 |
faenil | don't know | 15:56 |
faenil | that's what I mean :) | 15:56 |
rcg | yeah, that's what i tried to figure out by reading data over a longer period from the chip and is what i tried to summarize in the blog post | 15:56 |
faenil | ok, yeah, just wanted to see if we agreed on that ;) | 15:57 |
rcg | but unfortunately, there are also some issues when reading the data from the chip via the current version of the kernel module | 15:57 |
faenil | ok so that's the main problem | 15:57 |
rcg | https://bugs.nemomobile.org/show_bug.cgi?id=53 | 15:57 |
rcg | that's the bug report with a link to the patch | 15:57 |
rcg | that patch adds the kernel module | 15:57 |
faenil | yeah I've read that :) | 15:58 |
rcg | https://build.pub.meego.com/project/show?project=home%3Awonko%3Abranches%3ACE%3AAdaptation%3AN950-N9 | 15:58 |
rcg | https://build.pub.meego.com/package/show?package=kernel-adaptation-n950&project=home%3Awonko%3Abranches%3ACE%3AAdaptation%3AN950-N9 | 15:58 |
rcg | that's my branch of the kernel hw adaptation for n950 i am currently using for experimenting | 15:58 |
rcg | http://repo.pub.meego.com/home:/wonko:/branches:/CE:/Adaptation:/N950-N9/CE_Adaptation_N9xx-common_armv7hl/ | 15:59 |
rcg | there you can download the current status of my tries with the kernel | 15:59 |
*** niqt has joined #nemomobile | 15:59 | |
faenil | ok, but where's the problem? what are you using to read info? | 16:00 |
faenil | veskuh showed some values | 16:00 |
faenil | in the bug post | 16:00 |
rcg | actually, what i did was experimenting with the 0001-backport-from-kernel-2.6.39.patch patch | 16:00 |
rcg | well, one thing i figured is that using "upower -d" as mentioned in the bug report seems not to be pretty good for actually testing things | 16:01 |
rcg | instead seems much better to read those values directly from the sysfs for experimenting | 16:01 |
faenil | can't we just get the dump and display it on screen? dirty hack, but it works at least... | 16:02 |
rcg | then in dmesg, you can see the debug output | 16:02 |
rcg | what do you mean with "get the dump"? | 16:02 |
rcg | you can read the raw data from the chip via i2cdump | 16:02 |
faenil | yeah | 16:02 |
rcg | that's what my script did and that's the data i based my assumptions on | 16:02 |
faenil | yes | 16:02 |
faenil | exactly | 16:02 |
faenil | so can't we just bypass upower and display that info on the top left corner? | 16:03 |
rcg | now, the next step is to get a kernel module somehow running, that reads the data from the chip via i2c and exports it via sysfs | 16:03 |
faenil | once we're sure what the remaining battery is | 16:03 |
rcg | well, that would be another way to do this :) | 16:03 |
faenil | I mean, you gave it an interpretation and modified the driver, right? | 16:04 |
faenil | now, who's not showing? where are you getting stuck? what's not fetching the data? | 16:04 |
faenil | that's what I don't get :) | 16:04 |
rcg | that's what i did | 16:04 |
rcg | or tried | 16:04 |
rcg | maybe just try to install the kernel from my repository i linked above | 16:05 |
rcg | then you can better see what i am talking about | 16:05 |
rcg | the issue is that sometimes the sysfs entries report values and sometimes don't | 16:05 |
faenil | I don't have the n950 here .. | 16:05 |
rcg | when they don't report values, dmesg output shows error messages from the driver/kernel module code | 16:05 |
rcg | the issue that bugs me right now is that it's working sometimes and sometimes not.. i couldn't find any regularity in this | 16:06 |
faenil | mmm yeah | 16:06 |
faenil | I'm missing what the normal workflow should be XD | 16:06 |
rcg | that's what i wanted to deal with first.. afterwards we could then simply mess with offsets and byte/word conversions and all this stuff.. which _should_ be fairly easy | 16:06 |
faenil | can you make a real world example of the normal functioning of the whole thing? | 16:07 |
rcg | what do you mean with "real world example"? | 16:07 |
faenil | I mean, you power on the phone | 16:07 |
faenil | who tried to read the data? | 16:07 |
faenil | where do you see if it's successful? what are you trying to read it? why are you exporting it to sysfs? | 16:07 |
faenil | all that stuff :D | 16:07 |
faenil | who tries* | 16:08 |
faenil | how* are you trying to read it | 16:08 |
faenil | who calls q27x00_battery_read_energy(struct bq27x00_device_info *di) for example | 16:08 |
rcg | well, exporting via sysfs seems the way the kernel module is designed | 16:09 |
rcg | also upower seems to read from sysfs | 16:09 |
rcg | when reading from the sysfs nodes the module seems to try to communicate via the chip | 16:09 |
rcg | if this is successful the, e.g., "cat sysfs_thingie" returns a value | 16:09 |
rcg | if it is not successful you get an error iirc and dmesg shows more details about this | 16:10 |
faenil | is the kernel module the .c file you modified? | 16:10 |
rcg | yes | 16:10 |
faenil | ok | 16:10 |
rcg | at least one of the c files | 16:10 |
faenil | so, that .c file gets compiled into the .so right? | 16:11 |
rcg | .ko | 16:12 |
rcg | that is | 16:12 |
faenil | ko in our case, ok | 16:12 |
rcg | well, iirc, the patch modifies quite some files | 16:12 |
faenil | yeah | 16:12 |
rcg | one of these will become the kernel module | 16:12 |
faenil | kernel module = driver? | 16:13 |
rcg | my problems are: i am not very familiar with linux kernel module stuff, neither am i with how kernel modules interface i2c (which seems to be one issue), nor am i with sysfs, which seems the next issue :/ | 16:13 |
rcg | yeah | 16:13 |
rcg | kernel module == driver | 16:13 |
faenil | ok | 16:13 |
faenil | so we would just need someone with those competences to get it fixed in no time xD | 16:14 |
faenil | so something asks the module to read values right? (the power manager, or what else?) | 16:15 |
rcg | hopefully :) | 16:15 |
rcg | well, the interesting thing is, that reading from a sysfs node, e.g. via "cat sysfs_thingie", seems to actually trigger the kernel module or driver to try to read the values via i2c | 16:16 |
faenil | oh... | 16:16 |
faenil | -.- | 16:16 |
rcg | which, sometimes succeeds and sometimes failes, for no apparent reason | 16:16 |
faenil | shouldn't it try to read automatically? I mean isn't there something which autoupdates battery status? | 16:17 |
faenil | DocScrutinizer, maybe you can help, tell me you're there :D | 16:17 |
rcg | sry brb | 16:17 |
*** vakkov has joined #nemomobile | 16:17 | |
faenil | np | 16:17 |
vakkov | where can i download kickstarter.py from? | 16:18 |
DocScrutinizer | faenil: hmm? | 16:19 |
faenil | kernel modules... | 16:19 |
faenil | we were talking about the battery issue | 16:20 |
faenil | rcg says the module fails to export read values to sysfs | 16:20 |
faenil | and he says it seems the way to trigger the reading is "cat sysfs_bla_bla" | 16:20 |
faenil | when you cat the module read values from i2c but it randomly fails | 16:21 |
faenil | and you see the output of the error from dmesdg | 16:21 |
faenil | dmesg | 16:21 |
vakkov | i want to make an image similar to the ones nemo is distributed with | 16:21 |
DocScrutinizer | depends on particular kernel module we talk about | 16:21 |
faenil | DocScrutinizer, I mean, isn't there anything which autoupdates battery status? | 16:21 |
faenil | how does it usually work? | 16:21 |
DocScrutinizer | no, usually there SHALL NOT be any 'auto-update' | 16:22 |
faenil | how is the battery status updated? | 16:22 |
vakkov | what device are you talking about? IF N9/N950 look at e-yes's bme | 16:22 |
faenil | n950 | 16:22 |
DocScrutinizer | on reading sysfs node, the driver reads the I2C | 16:23 |
faenil | we're trying to get the battery status indicator to work | 16:23 |
DocScrutinizer | afaik | 16:23 |
faenil | ok, and how do you keep the battery indicator updated? | 16:23 |
DocScrutinizer | battery indicator needs to read battery status from sysfs whenever needed | 16:24 |
faenil | ok, so it has to read it once every X seconds, right? | 16:24 |
faenil | it autoupdates the indicator :D | 16:24 |
DocScrutinizer | based on timer, focus, screenlock, whatnot else | 16:24 |
faenil | yeah exactly | 16:24 |
faenil | ok, so the cat command is what starts it all, ok ;) | 16:25 |
faenil | thank you :) | 16:25 |
faenil | rcg noted that, but we're not sure if that's the wanted behavious | 16:25 |
DocScrutinizer | nota bene BME is using direct I2C access to battery gauge, which *will* occasionally cause collisions with any other kenel module meant to read same chip for sysfs node | 16:26 |
faenil | mmm | 16:27 |
faenil | what's BME first of all :D | 16:27 |
DocScrutinizer | also a kernel module like bq27x00.ko will cause I2C resource occupied so after loading this module BME will just fail | 16:27 |
DocScrutinizer | ~bme | 16:27 |
DocScrutinizer | hmm | 16:27 |
faenil | no bot here :D | 16:27 |
DocScrutinizer | maemo/nokia Battery Management Entity | 16:27 |
faenil | and is that what's used in Nemo? | 16:28 |
DocScrutinizer | nfc | 16:28 |
faenil | I mean, do we have to care about that? | 16:28 |
DocScrutinizer | ask Stskeeps | 16:28 |
faenil | ok | 16:28 |
faenil | the current problem anyway is that cat sysfs_bla_bla doesn't always work | 16:28 |
DocScrutinizer | yep, collisions most likely | 16:29 |
faenil | don't know what the error shown in dmesg is | 16:29 |
DocScrutinizer | best bet is to read twice and discard differing pairs | 16:29 |
faenil | but this is strange, all drivers which collide write to dmesg? | 16:29 |
DocScrutinizer | dirty but a stopgap bandaid | 16:30 |
faenil | and is it that likely to happen? | 16:30 |
faenil | 2 drivers reading the same file | 16:30 |
faenil | (battery chip) | 16:30 |
DocScrutinizer | BME uses direct I2C access, and when it collides on I2C with kernel module trying concurrent read, it simply results in wrong value read from bat gauge | 16:31 |
faenil | oh ok | 16:31 |
faenil | you mean concurrent i2c read as in, 2 modules reading 2chips with i2c, or 2 modules reading same chip? | 16:31 |
DocScrutinizer | when BME gets restarted however after kernel module got loaded/modprobed, it will fail to open I2C resource | 16:32 |
faenil | we still don't know if bme is used, so I guess that's another issue :) | 16:32 |
DocScrutinizer | BME reading chip 0x58:bus2 via I2C | 16:32 |
DocScrutinizer | bq27x00.ko accessing same I2C addr | 16:33 |
faenil | ok so same chip | 16:33 |
DocScrutinizer | via I2C driver iirc | 16:33 |
faenil | doesn't BME use a module? | 16:33 |
DocScrutinizer | I2C 'module' | 16:33 |
DocScrutinizer | see i2cget cmd | 16:33 |
DocScrutinizer | at maemo somebody is working on a wrapper ld_preload lib to divert direct I2C access to a sysfs read, for that particular chip | 16:35 |
DocScrutinizer | to "fix" bme | 16:35 |
faenil | I see | 16:36 |
DocScrutinizer | hth | 16:36 |
faenil | yeah it's better now, thanks :) | 16:36 |
faenil | so we have to see if the error in dmesg is because of collision | 16:37 |
DocScrutinizer | o/ highlight me if any further Q | 16:37 |
faenil | ok thanks :) | 16:37 |
faenil | we will get it working eventually, one day :D | 16:37 |
faenil | I think that's a critical issue for Nemomobile's usability, together with the visible tearing | 16:38 |
vakkov | https://gitorious.org/harmattan-goodies | 16:39 |
vakkov | might help | 16:39 |
faenil | vakkov, you think that could read battery info? | 16:39 |
vakkov | no idea, i know it's used in nitdroid.. i dont even have n9/n950 | 16:40 |
faenil | oh but that's only the client, we have to see if there's BME server running :) | 16:40 |
faenil | oh ok :) thanks ;) | 16:40 |
faenil | Stskeeps, ^ | 16:40 |
faenil | rcg, ^ | 16:41 |
vakkov | i need to make a raw image like the ones in nemo but not with nemo files.. if somebody can help.. | 16:41 |
faenil | I can't, sorry :( | 16:42 |
faenil | there was a tutorial | 16:42 |
faenil | https://wiki.merproject.org/wiki/Nemo/Creating_Releases vakkov | 16:43 |
faenil | that could help :) | 16:44 |
vakkov | http://wiki.meego.com/Image_Creation#Official_Meego_.ks_files | 16:46 |
vakkov | actually it's this but i dont want the repos and so on .. i just want to pack several folders in a ext3/4 partition as a file for qemu | 16:46 |
*** niqt has quit IRC | 16:47 | |
faenil | don't know then,sorry | 16:48 |
DocScrutinizer | faenil: if you like I may have a look at syslog/dmesg | 16:52 |
faenil | DocScrutinizer, but you should be using the modded kernel :) | 16:52 |
faenil | DocScrutinizer, I haven't tried it yet :) started talking about the battery issue one hour ago, with rcg :) | 16:53 |
DocScrutinizer | I'm not using any kernel regarding this offer, you need to provide a log | 16:53 |
faenil | oh you meant you could give a look a the log :) | 16:54 |
DocScrutinizer | ps|grp bme | 16:54 |
faenil | I don't have it sorry | 16:54 |
DocScrutinizer | grep* | 16:54 |
faenil | don't have the n950 here | 16:54 |
faenil | with me | 16:54 |
DocScrutinizer | well, ping me if anything I might help | 16:55 |
DocScrutinizer | no nemo system here though | 16:55 |
faenil | ok ;) | 16:55 |
faenil | thanks :) | 16:55 |
DocScrutinizer | yw | 16:55 |
vakkov | nemo is using ofono, right? | 16:58 |
DocScrutinizer | faenil: actually you *might* consider buffering of last real readout in bq27x00.ko and only doing one real readout for sysfs reads every minute | 17:03 |
faenil | yeah, that will come after :) | 17:05 |
DocScrutinizer | might be a valid approach for values that simply can't change that fast, particularly capacity | 17:05 |
DocScrutinizer | for current_now, voltage etc you want recent real readings | 17:06 |
DocScrutinizer | so there your buffering period is determined by max sample freq of chip, which is ~5s | 17:07 |
faenil | I see | 17:10 |
DocScrutinizer | anyway double-reading and comparing the read values seems a good concept here | 17:11 |
faenil | aha :) | 17:11 |
DocScrutinizer | possibly best done in kernel driver | 17:11 |
*** faenil has quit IRC | 17:30 | |
*** NIN101 has quit IRC | 17:55 | |
*** jussi01 is now known as jussi | 18:04 | |
*** NIN101 has joined #nemomobile | 19:03 | |
*** Luarvic has joined #nemomobile | 19:05 | |
*** Luarvic has quit IRC | 19:06 | |
*** _ol_ has joined #nemomobile | 19:10 | |
*** _ol_ is now known as [ol] | 19:10 | |
*** [ol] has joined #nemomobile | 19:12 | |
*** _ol has quit IRC | 19:16 | |
*** vakkov has quit IRC | 19:17 | |
*** bef0rd has joined #nemomobile | 19:25 | |
*** M4rtinK2 has joined #nemomobile | 19:43 | |
*** M4rtinK has quit IRC | 19:43 | |
*** furikku has quit IRC | 20:20 | |
*** NIN101 has quit IRC | 21:15 | |
*** npm_ has joined #nemomobile | 21:51 | |
*** npm has quit IRC | 21:53 | |
*** himamura has quit IRC | 22:09 | |
*** bef0rd has quit IRC | 22:42 | |
*** cxl000 has quit IRC | 22:48 | |
*** [ol] has quit IRC | 23:10 | |
*** [ol] has joined #nemomobile | 23:17 | |
*** parancibia has joined #nemomobile | 23:22 | |
*** parancibia has quit IRC | 23:32 | |
*** M4rtinK2 has quit IRC | 23:58 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!