<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?
<sicelo>
thanks. i was looking under drivers/media/rc :p
Daanct12 has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.1.1]
Daanct12 has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
ahmed_sam has joined #maemo-leste
<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
<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'
<Wizzup>
but this is with a frankenbattery
pere has joined #maemo-leste
ahmed_sam has quit [Read error: Connection reset by peer]
akossh has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
Wizzup: the now is the time to plug in thing generally dosent work when the battery is not callibrated
<uvos__>
it works by checking if the battery is below 15% (or 10% dont remember exacly)
<uvos__>
but our charge estimateion sucks so it mostly dosent work
<uvos__>
the "emergency" shutdown is triggered by mce at a set voltage
<uvos__>
this most definatly works fine (for me)
<uvos__>
the voltage it shal shutdown is set in 70-droid4.ini
<uvos__>
er in mapphone.ini actually
<uvos__>
freemangordon: what happend to your charge estimation improvements btw?
<uvos__>
the kernel itself also triggers an emergency shutdown on voltage
<uvos__>
but this comes after mce so should not trigger, except whenever mce is not running (so boot mostly)
<uvos__>
this threshold is 3.1 iirc
<Wizzup>
it didn't get to that though, it just shut off
<Wizzup>
but again, it's a different batterey
<Wizzup>
all I really care about is to calibrate it though :)
<uvos__>
well the battery shal not matter
<uvos__>
this means that the bms of the battery is triggering shutdown
<Wizzup>
well it shut down before it hit 3.2V, but maybe it dropped a lot because of a spike
<uvos__>
this is really really bad
<uvos__>
they trigger at 2.9v or so and its only intended to be used a couple of times
<uvos__>
it causes damage
<uvos__>
please check with mce if the battery guard module is loaded and setup correctly
<uvos__>
please check if the system can read the voltage proparly
<Wizzup>
well it was set up before, so I doubt this changed
<Wizzup>
this is not a polarcell battery btw, it was some other nexus 4 compatible one
<uvos__>
well soemthing dosent sound healthy there
elastic_dog has quit [Ping timeout: 258 seconds]
dos has quit [Ping timeout: 255 seconds]
dos has joined #maemo-leste
elastic_dog has joined #maemo-leste
<freemangordon>
uvos__: sitting on the queue
<freemangordon>
:(
Pali has joined #maemo-leste
<uvos__>
freemangordon: ok i know the ocv esstmation wasent finished
<uvos__>
but do did have a better ocv->soc function right?
<uvos__>
maybe if you post it somewhere i can add it to upower
<freemangordon>
no
<uvos__>
it would allready improve things on its own i gues
<uvos__>
freemangordon: ok
<freemangordon>
it was not good enough
<uvos__>
ok
<uvos__>
not good enough mitght still be better than the current one :P
<freemangordon>
well, it wass better, but not good enough for my taste :)
<uvos__>
but ok
<uvos__>
freemangordon: might be worth while
<uvos__>
still
<freemangordon>
I would better first finish charging detection patches
<uvos__>
ok
<freemangordon>
uvos__: estimation function was giving bogus values when I tried it on the allwinner tablet I have here
<uvos__>
the current function gives bogus values everywhere
<uvos__>
so i dont see the regression :P
<freemangordon>
heh :)
<freemangordon>
right, but why change something that does not work woth another that gives the same end result?
<uvos__>
well if its even marginally better on d4 it helps somewhere
<uvos__>
anyhow your call
<freemangordon>
anyway, now I am close to finishing multimedia stuff, I might get back to charger detection
<freemangordon>
ttyl
<uvos__>
ttyl
DFP has joined #maemo-leste
sunshavi has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: i added comments in transitions ini commit
<Wizzup>
thanks!
<arno11>
ask me if you need more details
<arno11>
bbabl
arno11 has left #maemo-leste [#maemo-leste]
xmn has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.1.1]
sch has joined #maemo-leste
enyc has quit [Ping timeout: 255 seconds]
enyc has joined #maemo-leste
<Wizzup>
well at least my battery is calibrated now
<Wizzup>
freemangordon: how do you feel about the transitions.ini changes for n900 by arno11?
<Wizzup>
so that would only get added on devices with the n900 leste config installed
<uvos__>
the file is in hildon-desktop
<uvos__>
allready
<Wizzup>
yes, that might be a problem :)
<Wizzup>
I think with dpkg divert it works
<Wizzup>
so the hildon-desktop one would become .divert or whatever they do
xmn has joined #maemo-leste
<uvos__>
ok and what happens when hildon is reinstalled
<Wizzup>
it will remain diverted
<uvos__>
ok
<Wizzup>
this is not new territory, we do this with various things afaik
<Wizzup>
it's still not -great-, but this wouldn't be the first time
Shock_ has quit [Ping timeout: 240 seconds]
<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
<uvos__>
you know what would make it more usable
<uvos__>
well not on n900
<uvos__>
but tagging a relaease out would help
<Wizzup>
hm?
<uvos__>
as currently there is a totaly pointless .5 sec delay on rotation
<Wizzup>
I can definitely do that now if you like, to -devel
<uvos__>
no strong optinion on the n900 transisitons beside that its wierd that it should be needed
<uvos__>
Wizzup: that would be great
<Wizzup>
building now
<uvos__>
thank you :)
k1r1t0 has quit [Ping timeout: 260 seconds]
k1r1t0_N900 has quit [Ping timeout: 255 seconds]
k1r1t0_N900 has joined #maemo-leste
k1r1t0_N900 has quit [Read error: Connection reset by peer]
<sicelo>
Wizzup: did dbus-scripts work for you? iirc there's something you were going to use them for
<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
<sicelo>
doesn't seem to be working at all for me now. i.e. it starts, but doesn't catch any events
<Wizzup>
ok, I don't remember what I used it for
<sicelo>
i understand the need for separate buses. in my case, I'm monitoring on the default system bus. weird
<sicelo>
regarding the transitions.ini, i did test it, and it was quite fast as arno11 mentions
<sicelo>
i missed some of the fancy stuff done by default, but i guess people will love the fast interaction
<uvos__>
we used to use dbus-scripts for rotation
<uvos__>
it def worked then, every one used it, it was default
<sicelo>
ah right. I'll check to see how it was done at the time
<Wizzup>
uvos__: ah yes that's rightg
<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?
<uvos__>
Wizzup: sure
<Wizzup>
I mean, what day :)
<freemangordon>
Wizzup: I don;t think we shall have special transitions for n900
<freemangordon>
if it is slow, we shall find why
<freemangordon>
the same HW works ok with fremantle
<Wizzup>
maybe it can be an optional pkg then
<uvos__>
that sounds like a good idea yeah
<uvos__>
ideally we would make it a transitions.ini.d for this however
<freemangordon>
still, the question remains - why it is slow? 32bpp vs 16 bpp?
<uvos__>
thats probubly some of it yeah
<Wizzup>
it's even slow on fremantle sometimes I think
<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
<freemangordon>
uvos__: BTW, .5 s delay on rotation is because it needs some time to redraw the applications
<freemangordon>
otherwise you will see everything rotated and resized
<freemangordon>
on n900 that is ;)
<uvos__>
freemangordon: no not that i added a delay because on ddk1.9 xorg crashed if you created ogl surfaces immitatly after roation
<uvos__>
this was a bug in that ddx
<uvos__>
its no longer with us
<uvos__>
so i reverted the delay
<uvos__>
but it was not released
<freemangordon>
ah
<freemangordon>
really?
<uvos__>
no, but Wizzup just released it
<freemangordon>
also ctrl-backspace?
<uvos__>
yeah
<freemangordon>
mhm
<uvos__>
but we still need to change the config file for that
<Wizzup>
uvos__: sounds like any day of the week works then? :D
<uvos__>
Wizzup: thursday or wednesday gives you the best chances
<Wizzup>
okay
fab_ has joined #maemo-leste
<sicelo>
talking about N900, what would you suggest as possible reasons that wlan is very slow?
<sicelo>
i don't want to believe other omap3 users (e.g. pandrora, etc.) have same issue
vectis has quit [Server closed connection]
vectis has joined #maemo-leste
<Wizzup>
sicelo: power saving
<Wizzup>
try to turn it off with iw
<sicelo>
right, yes that too. how could i forget!? but let me check it really gets ok then
Shock_ has quit [Ping timeout: 240 seconds]
Shock_ has joined #maemo-leste
uvos__ has quit [Ping timeout: 260 seconds]
arno11 has joined #maemo-leste
<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
pere has quit [Ping timeout: 255 seconds]
<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...
uvos__ has joined #maemo-leste
<arno11>
so it is really difficult with random slowness
<arno11>
and n900 works so nicely with overclock and tweaks :)
<Wizzup>
:)
sch has quit [Ping timeout: 246 seconds]
<arno11>
bbl (driving)
arno11 has left #maemo-leste [#maemo-leste]
<bencoh>
personally I'd vote for light transitions by default in any case
<Wizzup>
yeah that makes sense to me too, as long as it's obvious how to switch
sch has joined #maemo-leste
sch has quit [Ping timeout: 260 seconds]
sch has joined #maemo-leste
ac_laptop has joined #maemo-leste
<ac_laptop>
hi again
<ac_laptop>
what can I do when the X server crashes ? can I access a console somehow ?
arno11 has joined #maemo-leste
pere has joined #maemo-leste
<ac_laptop>
I've made a typo in my keyboard config file and now Xorg crashes at startup
<ac_laptop>
and I don't know how to go back to a TTY
<ac_laptop>
and the network didn't set up automatically either, so no SSH
<freemangordon>
ac_laptop: just mount sd card on your PC
uvos__ has quit [Remote host closed the connection]
uvos__ has joined #maemo-leste
<ac_laptop>
freemangordon: this is what I ended up doing
<ac_laptop>
hm now it doesn't like my .xinitrc , I guess I shouldn't have put the xbindkeys command in it
<ac_laptop>
why doesn't it fall back to a TTY ? is it because TTYs are deactivated or is there an other reason ?
sch has quit [Ping timeout: 264 seconds]
<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)
<arno11>
uvos: same question for you lol
<freemangordon>
arno11: change xorg bpp to 16 and see if it behaves the same or os better
<freemangordon>
*is better
<arno11>
ok thx :)
<ac_laptop>
I'm still trying to determine where I should put the xbindkeys command to launch it when Xorg starts
elastic_dog has quit [Ping timeout: 240 seconds]
<ac_laptop>
.xsession doesnt seem to work
<ac_laptop>
it should, unless there's a login manager