ac_laptop | Anyway I just want to say that I already like the features that this Maemo Leste is bringing, such as the bash by default, the sudo su in place of the old gainroot , and the fact that the timezone is saved instead of having to set it every time the battery is removed. Keep up the good work ! | 00:04 |
---|---|---|
Wizzup | :) | 00:05 |
Wizzup | sicelo: merged both prs and building | 00:06 |
Wizzup | to -devel | 00:06 |
sicelo | Wizzup: thanks | 08:00 |
sicelo | freemangordon: <freemangordon> arno11: patch that allows us to use hrtimer for IRTX on n900 was just pushed to upstream 6.1 .... i can't see it. link perhaps? | 08:01 |
freemangordon | sicelo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.1/drivers-clocksource-timer-ti-dm-don-t-call-clk_get_r.patch?id=cc8743ec5bb4cd059b3df5f787c658a570a8a6e3 | 08:22 |
sicelo | thanks. i was looking under drivers/media/rc :p | 08:26 |
Wizzup | uvos: freemangordon: so I was babysitting my d4 with the screen on (permanently), voltage around 3.4-3.3, and it just suddenly shut off, whatever safeguard we have definitely did not kick in | 10:07 |
Wizzup | I'm trying to get the battery to be calibrated but it just shuts off rather than says 'now is the time to plug in' | 10:07 |
Wizzup | but this is with a frankenbattery | 10:10 |
uvos__ | Wizzup: the now is the time to plug in thing generally dosent work when the battery is not callibrated | 10:37 |
uvos__ | it works by checking if the battery is below 15% (or 10% dont remember exacly) | 10:37 |
uvos__ | but our charge estimateion sucks so it mostly dosent work | 10:37 |
uvos__ | the "emergency" shutdown is triggered by mce at a set voltage | 10:38 |
uvos__ | this most definatly works fine (for me) | 10:38 |
uvos__ | the voltage it shal shutdown is set in 70-droid4.ini | 10:38 |
uvos__ | er in mapphone.ini actually | 10:38 |
uvos__ | freemangordon: what happend to your charge estimation improvements btw? | 10:38 |
uvos__ | the kernel itself also triggers an emergency shutdown on voltage | 10:39 |
uvos__ | but this comes after mce so should not trigger, except whenever mce is not running (so boot mostly) | 10:39 |
uvos__ | this threshold is 3.1 iirc | 10:40 |
Wizzup | it didn't get to that though, it just shut off | 10:40 |
Wizzup | but again, it's a different batterey | 10:40 |
Wizzup | all I really care about is to calibrate it though :) | 10:40 |
uvos__ | well the battery shal not matter | 10:40 |
uvos__ | this means that the bms of the battery is triggering shutdown | 10:40 |
Wizzup | well it shut down before it hit 3.2V, but maybe it dropped a lot because of a spike | 10:40 |
uvos__ | this is really really bad | 10:40 |
uvos__ | they trigger at 2.9v or so and its only intended to be used a couple of times | 10:41 |
uvos__ | it causes damage | 10:41 |
uvos__ | please check with mce if the battery guard module is loaded and setup correctly | 10:42 |
uvos__ | please check if the system can read the voltage proparly | 10:43 |
Wizzup | well it was set up before, so I doubt this changed | 10:44 |
Wizzup | this is not a polarcell battery btw, it was some other nexus 4 compatible one | 10:45 |
uvos__ | well soemthing dosent sound healthy there | 10:45 |
freemangordon | uvos__: sitting on the queue | 11:14 |
freemangordon | :( | 11:14 |
uvos__ | freemangordon: ok i know the ocv esstmation wasent finished | 11:17 |
uvos__ | but do did have a better ocv->soc function right? | 11:17 |
uvos__ | maybe if you post it somewhere i can add it to upower | 11:17 |
freemangordon | no | 11:17 |
uvos__ | it would allready improve things on its own i gues | 11:17 |
freemangordon | it was not good enough | 11:18 |
uvos__ | freemangordon: ok | 11:18 |
uvos__ | ok | 11:18 |
uvos__ | not good enough mitght still be better than the current one :P | 11:18 |
freemangordon | well, it wass better, but not good enough for my taste :) | 11:18 |
uvos__ | but ok | 11:18 |
uvos__ | freemangordon: might be worth while | 11:18 |
uvos__ | still | 11:18 |
freemangordon | I would better first finish charging detection patches | 11:19 |
uvos__ | ok | 11:19 |
freemangordon | uvos__: estimation function was giving bogus values when I tried it on the allwinner tablet I have here | 11:20 |
uvos__ | the current function gives bogus values everywhere | 11:20 |
uvos__ | so i dont see the regression :P | 11:20 |
freemangordon | heh :) | 11:20 |
freemangordon | right, but why change something that does not work woth another that gives the same end result? | 11:21 |
uvos__ | well if its even marginally better on d4 it helps somewhere | 11:21 |
uvos__ | anyhow your call | 11:21 |
freemangordon | anyway, now I am close to finishing multimedia stuff, I might get back to charger detection | 11:21 |
freemangordon | ttyl | 11:22 |
uvos__ | ttyl | 11:22 |
arno11 | Wizzup: i added comments in transitions ini commit | 13:37 |
Wizzup | thanks! | 13:37 |
arno11 | ask me if you need more details | 13:37 |
arno11 | bbabl | 13:37 |
Wizzup | well at least my battery is calibrated now | 14:48 |
Wizzup | freemangordon: how do you feel about the transitions.ini changes for n900 by arno11? | 14:49 |
Wizzup | https://github.com/maemo-leste/leste-config/pull/38/files | 14:49 |
uvos__ | Wizzup: not freemangordon but if i may add what i think: it is why | 16:00 |
uvos__ | clearly the defaults worked fine on freemantle, they allready where tuned for the n900, so why do they need to change now | 16:00 |
uvos__ | why is it so much slower on leste, seams wierd | 16:01 |
uvos__ | on the other hand i disabled many animations on d4, not because they are slow, but because i find them annoying | 16:02 |
uvos__ | anyhow i would nak that pr on the basis that it affects everyone when the target is only to affect the n900 | 16:03 |
Wizzup | it only affects n900 | 16:03 |
Wizzup | > | 16:03 |
Wizzup | leste-config-n900/usr/share/hildon-desktop/transitions.ini.leste | 16:03 |
uvos__ | how would that even work | 16:03 |
Wizzup | so that would only get added on devices with the n900 leste config installed | 16:03 |
uvos__ | the file is in hildon-desktop | 16:03 |
uvos__ | allready | 16:03 |
Wizzup | yes, that might be a problem :) | 16:03 |
Wizzup | I think with dpkg divert it works | 16:04 |
Wizzup | so the hildon-desktop one would become .divert or whatever they do | 16:04 |
uvos__ | ok and what happens when hildon is reinstalled | 16:04 |
Wizzup | it will remain diverted | 16:04 |
uvos__ | ok | 16:04 |
Wizzup | this is not new territory, we do this with various things afaik | 16:04 |
Wizzup | it's still not -great-, but this wouldn't be the first time | 16:04 |
Wizzup | as for the other comments, I don't really have a strong opinion, but I think that if arno11 is finding ways to make hildon more usable on n900 it might be a good thing, I haven't looked at the differences personally | 16:05 |
uvos__ | you know what would make it more usable | 16:05 |
uvos__ | well not on n900 | 16:05 |
uvos__ | but tagging a relaease out would help | 16:05 |
Wizzup | hm? | 16:06 |
uvos__ | as currently there is a totaly pointless .5 sec delay on rotation | 16:06 |
Wizzup | ah | 16:06 |
uvos__ | https://github.com/maemo-leste/hildon-desktop/commit/2a1a4e1c45d79d374933f64e8ffdfa1541617a87 | 16:06 |
uvos__ | (was not released so far) | 16:06 |
uvos__ | anyhow | 16:07 |
Wizzup | I can definitely do that now if you like, to -devel | 16:07 |
uvos__ | no strong optinion on the n900 transisitons beside that its wierd that it should be needed | 16:07 |
uvos__ | Wizzup: that would be great | 16:07 |
Wizzup | building now | 16:09 |
uvos__ | thank you :) | 16:12 |
sicelo | Wizzup: did dbus-scripts work for you? iirc there's something you were going to use them for | 16:33 |
Wizzup | I think it did, but iirc you had to run two, one for system and one for user session, which was a bit silly | 16:33 |
sicelo | doesn't seem to be working at all for me now. i.e. it starts, but doesn't catch any events | 16:33 |
Wizzup | ok, I don't remember what I used it for | 16:33 |
sicelo | i understand the need for separate buses. in my case, I'm monitoring on the default system bus. weird | 16:34 |
sicelo | regarding the transitions.ini, i did test it, and it was quite fast as arno11 mentions | 16:35 |
sicelo | i missed some of the fancy stuff done by default, but i guess people will love the fast interaction | 16:36 |
uvos__ | we used to use dbus-scripts for rotation | 16:48 |
uvos__ | it def worked then, every one used it, it was default | 16:49 |
sicelo | ah right. I'll check to see how it was done at the time | 16:50 |
Wizzup | uvos__: ah yes that's rightg | 16:51 |
Wizzup | uvos__: if I wanted a few hours of your time this week (not all the hours, but parts of them) to look at the d3 issues, what would work for you? | 17:00 |
uvos__ | Wizzup: sure | 17:02 |
Wizzup | I mean, what day :) | 17:02 |
freemangordon | Wizzup: I don;t think we shall have special transitions for n900 | 17:04 |
freemangordon | if it is slow, we shall find why | 17:04 |
freemangordon | the same HW works ok with fremantle | 17:04 |
Wizzup | maybe it can be an optional pkg then | 17:05 |
uvos__ | that sounds like a good idea yeah | 17:05 |
uvos__ | ideally we would make it a transitions.ini.d for this however | 17:05 |
freemangordon | still, the question remains - why it is slow? 32bpp vs 16 bpp? | 17:06 |
uvos__ | thats probubly some of it yeah | 17:06 |
Wizzup | it's even slow on fremantle sometimes I think | 17:06 |
uvos__ | i think running n900 in 16bit would be ok, it cant runn the applications i am worried about that dont work in 32bit anyhow | 17:06 |
freemangordon | uvos__: BTW, .5 s delay on rotation is because it needs some time to redraw the applications | 17:07 |
freemangordon | otherwise you will see everything rotated and resized | 17:07 |
freemangordon | on n900 that is ;) | 17:07 |
uvos__ | freemangordon: no not that i added a delay because on ddk1.9 xorg crashed if you created ogl surfaces immitatly after roation | 17:08 |
uvos__ | this was a bug in that ddx | 17:08 |
uvos__ | its no longer with us | 17:08 |
uvos__ | so i reverted the delay | 17:08 |
uvos__ | but it was not released | 17:08 |
freemangordon | ah | 17:08 |
freemangordon | really? | 17:08 |
uvos__ | no, but Wizzup just released it | 17:08 |
freemangordon | also ctrl-backspace? | 17:08 |
uvos__ | yeah | 17:09 |
freemangordon | mhm | 17:09 |
uvos__ | but we still need to change the config file for that | 17:09 |
Wizzup | uvos__: sounds like any day of the week works then? :D | 17:11 |
uvos__ | Wizzup: thursday or wednesday gives you the best chances | 17:12 |
Wizzup | okay | 17:13 |
sicelo | talking about N900, what would you suggest as possible reasons that wlan is very slow? | 17:31 |
sicelo | i don't want to believe other omap3 users (e.g. pandrora, etc.) have same issue | 17:32 |
Wizzup | sicelo: power saving | 17:34 |
Wizzup | try to turn it off with iw | 17:34 |
sicelo | right, yes that too. how could i forget!? but let me check it really gets ok then | 17:37 |
arno11 | Wizzup: just to clarify a bit: i don't make this last PR like a definitive stuff, simply i can't continue calls integration with a none responsive UI OOTB. i'm totally agree it is better to find the root cause of slowness but ATM sphone is really to slow OOTB without transitions tweaks and sound is not great enough with stock daemon.conf. definitely it is just a temporary workaround | 18:07 |
arno11 | for example, calls latency depends of 2G or 3G tech, priorities (rt or not), depending of how quick cmt and sphone start/react, resampling method, sample rate, the use of sudo or not and other stuff... | 18:13 |
arno11 | so it is really difficult with random slowness | 18:15 |
arno11 | and n900 works so nicely with overclock and tweaks :) | 18:16 |
Wizzup | :) | 18:17 |
arno11 | bbl (driving) | 18:19 |
bencoh | personally I'd vote for light transitions by default in any case | 18:20 |
Wizzup | yeah that makes sense to me too, as long as it's obvious how to switch | 18:21 |
ac_laptop | hi again | 19:37 |
ac_laptop | what can I do when the X server crashes ? can I access a console somehow ? | 19:38 |
ac_laptop | I've made a typo in my keyboard config file and now Xorg crashes at startup | 19:39 |
ac_laptop | and I don't know how to go back to a TTY | 19:39 |
ac_laptop | and the network didn't set up automatically either, so no SSH | 19:40 |
freemangordon | ac_laptop: just mount sd card on your PC | 19:44 |
ac_laptop | freemangordon: this is what I ended up doing | 19:48 |
ac_laptop | hm now it doesn't like my .xinitrc , I guess I shouldn't have put the xbindkeys command in it | 19:51 |
ac_laptop | why doesn't it fall back to a TTY ? is it because TTYs are deactivated or is there an other reason ? | 19:58 |
arno11 | freemangordon: i think i don't have the skills to solve the problem but maybe i can find what is wrong with n900 default responsiveness. IYO where should i look first ? (i'll have time next weekend with not too much kid/baby stuff) | 20:16 |
arno11 | uvos: same question for you lol | 20:17 |
freemangordon | arno11: change xorg bpp to 16 and see if it behaves the same or os better | 20:26 |
freemangordon | *is better | 20:26 |
arno11 | ok thx :) | 20:27 |
ac_laptop | I'm still trying to determine where I should put the xbindkeys command to launch it when Xorg starts | 20:28 |
ac_laptop | .xsession doesnt seem to work | 20:29 |
ac_laptop | it should, unless there's a login manager | 20:29 |
freemangordon | ac_laptop: there is | 20:31 |
freemangordon | autologin | 20:32 |
freemangordon | uvos__: please, fix ^^^ license :D | 20:33 |
freemangordon | uvos__: https://github.com/maemo-leste-upstream-forks/autologin/blob/maemo/chimaera/debian/copyright#L6 | 20:34 |
freemangordon | ac_laptop: there is elogind session | 20:35 |
Wizzup | ok, dist upgraded my lime2 olimex tablets and my pinephone :) | 23:45 |
sicelo | :-) | 23:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!