00:19
Pali has quit [Ping timeout: 246 seconds]
01:06
Danct12 has joined #maemo-leste
01:48
xmn has joined #maemo-leste
02:53
elastic_dog has quit [Ping timeout: 264 seconds]
02:59
elastic_dog has joined #maemo-leste
03:36
Danct12 has quit [Quit: Leaving]
04:06
RedW has quit [Quit: No Ping reply in 180 seconds.]
04:06
RedW has joined #maemo-leste
04:24
joerg has quit [Ping timeout: 252 seconds]
04:25
joerg has joined #maemo-leste
04:45
macros_2ndPC has quit [Ping timeout: 260 seconds]
04:47
macros_2ndPC has joined #maemo-leste
05:02
RedW has quit [Quit: No Ping reply in 180 seconds.]
05:03
RedW has joined #maemo-leste
05:20
mardy has joined #maemo-leste
05:46
<
tmlind >
hmm no idea what could have caused increased power consumption, don't think i've seen that with my kernel tests
06:12
<
freemangordon >
I will revert to the kernel before the patches to see if I get the same here
06:13
<
freemangordon >
with latest I have POWER_SUPPLY_POWER_AVG=125612
06:13
<
freemangordon >
for POWER_SUPPLY_CURRENT_AVG=32458
06:19
<
freemangordon >
tmlind: I see serial kernel threads in top with the patches
06:25
Twig has joined #maemo-leste
06:26
<
tmlind >
freemangordon: hmm i wonder which patch could cause that
06:26
<
freemangordon >
tmlind: wait, I am still not convinced we have an issue
06:27
<
freemangordon >
for how long I shall not touch the device in order to assume it has proper average power calculated?
06:29
<
tmlind >
i'd check once a minute if comparing
06:30
<
freemangordon >
so far I'd say it is better with the patches
06:32
<
freemangordon >
hmm. lets put accounts offline and set modest to check every 30 minutes
06:36
<
freemangordon >
without patches the lowest I got is:
06:36
<
freemangordon >
POWER_SUPPLY_CURRENT_AVG=31177
06:36
<
freemangordon >
POWER_SUPPLY_POWER_AVG=116290
06:37
<
freemangordon >
but most of the time idle avg current stays between 40-50mA
06:45
<
freemangordon >
tmlind: I see 2 more serial interrupts in /proc/interrupts with the patches, I guess that's normal
06:46
<
freemangordon >
what I don;t think is normal is having irq/112-48020000.serial:wakeup and irq/124-4806a000.serial:wakeup visible in top all the time
06:49
<
buZz >
is this with the kernel now in -devel?
06:49
<
freemangordon >
yes
06:50
<
buZz >
i'm not seeing those in top, at least not in a fully booted hildon?
06:50
<
freemangordon >
maybe serial gpios are not configured properly so they generate fake interrupts?
06:53
<
freemangordon >
OTOH I don;t see number of interrups to increase
07:00
<
freemangordon >
without patches I have average of the average power consumption over a period of 5 minutes (removing spikes) of 142.8mW
07:01
<
freemangordon >
with patches, under same conditions, it is 139.2
07:01
<
freemangordon >
so I'd say there is no difference
07:03
rafael2k has joined #maemo-leste
07:04
rafael2k_ has joined #maemo-leste
07:07
<
tmlind >
yes those are the threaded interrupt handlers for the padconf wakeup events
07:07
rafael2k has quit [Ping timeout: 244 seconds]
07:09
<
freemangordon >
yes, but I don;t see them without patches
07:09
<
freemangordon >
also, I have nothing connected to the serial, why are those active?
07:12
<
tmlind >
those are always active when a device is runtime suspended
07:19
norayr has left #maemo-leste [Disconnected: closed]
07:20
norayr has joined #maemo-leste
07:21
uvos has joined #maemo-leste
07:27
<
freemangordon >
enabling online accounts (no iphb) increases power usage with ~40 mW
07:33
pere has quit [Ping timeout: 264 seconds]
07:34
alex1216 has joined #maemo-leste
07:35
<
uvos >
40mW is really terrible on d4
07:35
<
uvos >
i get more like 25 ususally
07:36
<
uvos >
"<freemangordon> but most of the time idle avg current stays between 40-50mA"
07:36
ceene has joined #maemo-leste
07:37
<
uvos >
but mW mesurements are more usefull
07:37
<
uvos >
as mA changes quite a bit with battery voltage
07:37
<
uvos >
(as you would expect)
07:38
<
freemangordon >
yes, that's why I measured power
07:45
dev has joined #maemo-leste
07:47
pere has joined #maemo-leste
08:03
dev has left #maemo-leste [Disconnected: Replaced by new connection]
08:03
dev has joined #maemo-leste
08:27
ceene has quit [Read error: Connection reset by peer]
08:27
_CN_ has joined #maemo-leste
08:33
xmn has quit [Ping timeout: 268 seconds]
08:34
akossh has joined #maemo-leste
08:35
xmn has joined #maemo-leste
08:41
Livio has joined #maemo-leste
08:41
Livio has quit [Changing host]
08:41
Livio has joined #maemo-leste
08:56
Livio has quit [Ping timeout: 265 seconds]
09:06
dev has left #maemo-leste [Disconnected: closed]
09:09
dev has joined #maemo-leste
09:19
dev has left #maemo-leste [Disconnected: closed]
09:20
dev has joined #maemo-leste
09:36
uvos__ has joined #maemo-leste
09:36
<
uvos__ >
idk what was going on yesterday
09:36
<
uvos__ >
but its ideling at 90mW here rn
09:37
<
uvos__ >
so i gues the yesterdays excessive power usage was unrelated to the kernel patches. probubly
09:37
<
freemangordon >
maybe modem related
09:38
<
uvos__ >
it dose sometimes idle at 120mW with out explanation (allways has, only the xt875 dosent have that problem)
09:38
<
uvos__ >
but 150mW from yesterday was farily excessive+
09:38
<
uvos__ >
freemangordon: maybe, no idea
09:39
<
freemangordon >
now testing if iphb makes any difference
09:42
rafael2k_ is now known as rafael2k
09:43
<
freemangordon >
ught, gabble is compiled without iphb support :(
09:59
akossh has quit [Quit: Leaving.]
10:01
Livio has joined #maemo-leste
10:01
Livio has quit [Changing host]
10:01
Livio has joined #maemo-leste
10:36
Pali has joined #maemo-leste
10:41
Livio has quit [Ping timeout: 268 seconds]
10:43
dos has quit [Quit: Kabum!]
10:43
dos has joined #maemo-leste
10:47
<
Wizzup >
hey that's interesting news @ pvrsgx mail
10:48
<
Wizzup >
I wonder if they are fully aware of the X ddx that we use/have
10:49
dev has left #maemo-leste [Disconnected: Replaced by new connection]
10:49
<
buZz >
i'm not sure why a application has a device, i thought they were all pretty portable?
10:49
dev has joined #maemo-leste
10:49
<
uvos__ >
Wizzup: what email are you talking about?
10:51
dev has left #maemo-leste [#maemo-leste]
10:53
<
uvos__ >
buZz: some applications might need some specific hw feature, think compass usage excluding n900 or something
10:54
<
uvos__ >
but yeah its probubly not nessecary to fill that in usually
10:54
<
buZz >
right, but most do not i guess? should i just remove the device tag?
10:54
dev has joined #maemo-leste
10:54
<
Wizzup >
uvos__: ah I thought it went to the list but didn't, I can fwd it to you
10:55
<
Wizzup >
buZz: looks good, maybe mention mor explicitly where the dictionaries are hosted
10:55
<
buZz >
Wizzup: okidoki
10:55
<
buZz >
but there's many many many sources of dicts
10:55
<
buZz >
even inside devuan
10:56
<
buZz >
stardict-english-czech/stable,stable 20171101-1 all
10:56
<
buZz >
stardict-german-czech/stable,stable 20171101-1 all
10:57
<
Wizzup >
hmmm, ok, it isn't clear to me that those can be used from the page
10:57
<
Wizzup >
I guess it's under the "Also" ?
10:57
<
uvos__ >
Wizzup: great
10:58
<
buZz >
if traffic gets nuts for those dicts i could move them to a leste server or whatever
10:58
<
buZz >
all dictionaries on that mirror that are linked in the .htmls are free to use/pd/gpl
10:58
<
buZz >
but there's some unlinked inside that are copyrighted i think?
11:00
<
buZz >
removing the device tag works well btw, i dont think this needs any
11:00
<
Wizzup >
buZz: I made some changes
11:00
<
Wizzup >
Can you elaborate some on espeak as well?
11:01
<
Wizzup >
also, maybe we ought to have a 'mstardict-alldict' pkg or something
11:01
<
Wizzup >
unless it's very very large
11:01
<
buZz >
well, there's no authority issueing stardict format dictionaries
11:02
<
buZz >
that stardict-dic mirror is 5.8GB
11:02
<
Wizzup >
buZz: is it distconv or dictconv btw
11:02
<
Wizzup >
wiki says distconv
11:09
<
freemangordon >
Wizzup: please reply to that mail
11:10
<
freemangordon >
if we can convince andrew to help with pvr EXA on our x driver (HW accell compositing) that would be great
11:10
<
buZz >
Wizzup: i also think this program is more suitable for a 'few' dictionaries and not the whole mass of human knowledge :P
11:11
<
freemangordon >
as we already have everything else FOSS
11:11
<
freemangordon >
and mesa driver we have
11:11
<
buZz >
Wizzup: i elaborated on it and added a preferences screenshot too
11:20
<
Wizzup >
freemangordon: my understanding is that he'd make builds mostly
11:20
<
Wizzup >
freemangordon: ok, I can try, but I believe you know a -lot- more about this than I do
11:21
<
freemangordon >
I will join to the party later on if questions arise
11:21
<
Wizzup >
I'm afraid I might not be able to add enough context, but ok, I can try...
11:21
<
freemangordon >
ok, if you think it will be better, I will reply
11:22
<
Wizzup >
I think so, my only thought is that it'd be great if we know what builds we could use from him, and that over-asking might not be productive atm (but who knows, I don't know what the other 'good news' is)
11:22
<
freemangordon >
will do
11:23
uvos__ has quit [Quit: Konversation terminated!]
11:24
<
Wizzup >
buZz: these espeak voices, where would they be placed, also in MyDocs/mstardict ?
11:25
<
buZz >
Wizzup: updated :)
11:25
dev has left #maemo-leste [Disconnected: Replaced by new connection]
11:25
<
Wizzup >
buZz: btw, the 'website' is set to a git repo, and the leste repo to another, I think they're one and the same so we can probably just link to our leste repo
11:25
<
Wizzup >
if there's no website that is
11:25
dev has joined #maemo-leste
11:25
<
buZz >
there's no website, alright
11:25
<
buZz >
the repo linked is the upstream where norayr was doing their dev work
11:26
<
Wizzup >
maybe the wayback link can be the website
11:26
<
Wizzup >
buZz: sure but it'll be out of date assuming norayr submits to the leste repo going forward
11:26
<
buZz >
thats for stardict, maybe the maemo.org thread?
11:27
<
Wizzup >
maybe, also not ideal imho, maybe just don't have one if there's no clear point
11:28
<
buZz >
alright, removed :)
11:28
<
buZz >
i explained some about the espeak now anyway
11:29
<
buZz >
the red is so ugly on its default colors :P maybe thats ugly enough to get me to edit it
11:30
dev has left #maemo-leste [#maemo-leste]
11:31
dev has joined #maemo-leste
11:33
<
buZz >
i think its hardcoded in libwrapper.cpp ? :/
11:33
alex1216 has quit [Ping timeout: 265 seconds]
11:36
uvos__ has joined #maemo-leste
11:37
<
norayr >
hey i am here, let me soo what you are talking about.
11:38
<
buZz >
and wizzup some
11:39
Livio has joined #maemo-leste
11:39
Livio has quit [Changing host]
11:39
Livio has joined #maemo-leste
11:39
<
norayr >
wow thank you!
11:41
<
norayr >
feel free to make any changes to the repo in maemo-extras.
11:41
<
norayr >
did i leave somewhere a link to norayr/mstardict? it's not important anymore, you can delete it.
11:42
<
norayr >
and i am not planning much work on it. i was just able to port/package it, bring to life with some changes, not even sure that good changes.
11:42
<
norayr >
and i use it, since i use stardict dictionaries, and i have my own dictionaries converted from pdfs or other sources, and it is convenient.
11:43
<
norayr >
so i would be happy if anyone does something to it.
11:43
<
norayr >
let's say i have no idea what to do with that on click function
11:43
<
buZz >
well, i'm annoyed by the red, not sure where it's originating from
11:43
<
norayr >
which tries to execute nokia browser.
11:43
<
buZz >
yeah its a html rendering i think
11:44
<
norayr >
yeah feel free to push to the repo!
11:44
<
buZz >
i think it should somehow know to link to itself , but it doesnt
11:44
<
buZz >
hehe , well, if i can find it ;)
11:44
<
norayr >
you said once!
11:44
<
norayr >
on this screenshot
11:45
<
norayr >
i see the word is red
11:45
<
norayr >
but it shoud non link to anything.
11:45
<
norayr >
i don't see links.
11:45
<
buZz >
this was just a example of 'a item' from 'a dictionary'
11:45
<
buZz >
but, the item title is always red
11:45
<
buZz >
regardless of colors of theme, etc
11:45
<
norayr >
yeah... i think it's possible to change it.
11:46
<
norayr >
at least to not be red, but have the same color as the rest of the text.
11:47
<
norayr >
i need a flickr app. will try to bring one to life. if it doesn't work, i'll try to write one by using flickurl.
11:48
<
norayr >
i remember one app for maemo was in qt and was very slow on n900.
11:48
<
norayr >
extremely slow.
11:48
<
norayr >
i had the impression that qt is slower on n900.
11:48
<
norayr >
did anyone have such an impression?
11:50
<
uvos >
its pretty much guarnteed qt4+ / gtk3+ are slower than gtk2
11:50
<
uvos >
just beacuse how they render themselves
11:50
<
norayr >
doesn't gtk render itself via x?
11:50
<
Wizzup >
qt5 scrolls smoother than gtk2 for sure
11:50
<
uvos >
(potential for improved hw accel asside)
12:02
alex1216 has joined #maemo-leste
12:04
xmn has quit [Ping timeout: 265 seconds]
12:11
_CN_ has quit [Ping timeout: 250 seconds]
12:21
<
bencoh >
norayr: I'd say that qt was slower than gtk on n900 as well yeah
12:21
Joanna has joined #maemo-leste
12:21
Joanna has left #maemo-leste [#maemo-leste]
12:26
Joanna has joined #maemo-leste
12:53
<
freemangordon >
something werid happened to my device, now it idles @ 400 mW
13:12
<
Wizzup >
freemangordon: some drivers loaded?
13:14
<
freemangordon >
nothing changed IIUC
13:14
<
Wizzup >
maybe run omapconf?
13:15
<
freemangordon >
it shows the same
13:15
<
freemangordon >
I installed powertop, unfortunately it does not help much
13:15
<
freemangordon >
ogh
13:15
<
freemangordon >
what the?
13:15
<
Wizzup >
I had a problem with a droid that after I had it on psu for too long, it started drawing 16mA when turned off
13:16
<
Wizzup >
was a hw problem I bet
13:16
<
freemangordon >
ok, I switched status from offline to online and back and it fixed the issue
13:16
<
freemangordon >
this does not make sense :)
13:17
<
freemangordon >
hmmm
13:17
<
freemangordon >
ok, it idles @ 120 mW now
13:18
<
freemangordon >
now I can test iphb
13:19
<
Wizzup >
yeah there is a problem where the modem doesn't idle in some states I think
13:20
<
freemangordon >
I am connected through wifi
13:20
_CN_ has joined #maemo-leste
13:20
<
freemangordon >
ah, I meat account status
13:20
<
freemangordon >
*meant
13:20
<
freemangordon >
not flight mode
13:23
<
freemangordon >
ok, without iphb and with 2 jabber accounts it idles @ ~155mW
13:26
<
freemangordon >
Wizzup: BTW, can we remove obsolete linux headers from the repo?
13:27
<
Wizzup >
sure, if you want, just let me know which exact ones you want removed
13:28
<
freemangordon >
so, with iphb I am seeing values as low as 125 mW
13:28
<
Wizzup >
this is over wifi I suspect?
13:28
<
freemangordon >
with same accounts online
13:28
<
freemangordon >
yes
13:29
<
freemangordon >
ok, lets stop iphb and try again
13:36
<
freemangordon >
hmm, seems iphb breaks it
13:38
<
freemangordon >
oh, it crashes :)
13:44
<
sicelo >
mmm, PVR email ... may i get a link? i thought i was in the correct ML, but I didn't get the mail
14:00
<
freemangordon >
sicelo: it is not in a ML
14:32
<
uvos >
even 120 is very high @ freemangordon
14:35
<
uvos >
wakeups generally dont hurt the droid 4 nearly as mutch as the n900 btw
14:36
<
uvos >
since it can enter and exit idle way way faster than n900
14:36
<
uvos >
even the mm compatction that creates a couple of hz of wakeups totaly prevents the n900 from ideling at all
14:37
<
uvos >
while on d4 the effect on power consumption wasent even mesurable
14:37
<
uvos >
so yeah just things to think about when optimizing
14:43
<
freemangordon >
well,, this is what I get here
14:43
<
freemangordon >
hints how to chase that are appreciated :)
14:44
<
Wizzup >
uvos: it was measurable on the d4 fwiw
14:44
<
Wizzup >
but not a lot
14:44
<
freemangordon >
uvos: keep in mind I measure that in ssh session
14:44
<
freemangordon >
I think each ssh session adds about 40 mW or something
14:45
<
uvos >
idle ssh session is very low cost
14:45
<
uvos >
so if omapconf dosent change
14:45
<
Wizzup >
on gprs it actively causes the batery life to die 2-3 normal speed
14:45
<
uvos >
on gprs it causes the modem to stay awake
14:46
<
Wizzup >
having gprs active without ssh hardly impacts battery life
14:46
<
uvos >
anyhow if ompaconf dosent change, nothing is keeping the device awake permantently
14:46
<
uvos >
so that suggests something is using too mutch cpu time
14:47
<
freemangordon >
maybe tcp activity
14:47
<
freemangordon >
I'll run tcpdup to see what happens
14:47
<
uvos >
also if its tcp activity on the modem
14:47
<
freemangordon >
*tcpdump
14:47
<
uvos >
like ssh it will not enter idle state
14:47
<
uvos >
the modem takes qutie some time to calm down
14:47
<
uvos >
after you last used it
14:47
<
freemangordon >
lemme offile the modem
14:48
<
uvos >
for some reason offlineling the modem dosent really do anything pm wise
14:48
<
freemangordon >
well, what to do then?
14:48
rafael2k has quit [Ping timeout: 252 seconds]
14:48
<
uvos >
dont connect gprs?
14:48
<
freemangordon >
it is not connected
14:49
<
uvos >
then your not waking the modem
14:49
<
freemangordon >
I am using wifi all the time while measuring
14:49
<
freemangordon >
my wifi rooter is pretty ol, that might create issues too
14:49
<
freemangordon >
also, I think I have lowered RTS, lemme check
14:50
<
freemangordon >
well, rts threshold is 500, not that bad
14:50
<
freemangordon >
shoudl not affect power savings
14:51
<
uvos >
how manny wakeups do you have?
14:51
<
freemangordon >
sec
14:51
<
uvos >
should be 15 ish hz at very the most
14:52
<
freemangordon >
now 10
14:52
akossh has joined #maemo-leste
14:52
akossh has left #maemo-leste [#maemo-leste]
14:52
<
uvos >
sounds resonable
14:52
<
uvos >
first mesurement is allways high
14:53
<
freemangordon >
I am doing 'while [ 1 ]; do sleep 30; cat uevent | grep AVG; done'
14:53
<
freemangordon >
no issue with that,right?
14:53
<
freemangordon >
POWER_SUPPLY_POWER_AVG=222636
14:53
<
freemangordon >
the fuck?
14:54
<
freemangordon >
ok, lemme run tcpdump
14:54
<
freemangordon >
uvos: what is the time window avg is calculated on?
14:54
<
freemangordon >
do you know?
14:55
<
uvos >
should be fine at reading uevent
14:55
<
uvos >
no but short
14:55
<
uvos >
its filtered for spikes
14:55
<
uvos >
not for long periods
14:55
<
uvos >
ie its seconds not minutes or anything
14:56
<
freemangordon >
does not look good
14:56
<
freemangordon >
let me see if using iphb will change that
14:56
<
uvos >
its about 50mW high yeah
14:57
<
freemangordon >
I guess because of the jabber accounts
14:58
<
uvos >
i wonder if reading uevent makes it higher
14:58
<
freemangordon >
for sure it does
14:58
<
uvos >
because the kernel goes and fetches more values than just reading power_avg
14:58
<
freemangordon >
hmm
14:58
<
freemangordon >
hmm....
14:58
<
freemangordon >
right
14:58
<
freemangordon >
lemme try with just the average
14:59
<
uvos >
so by the time it fetches power_avg
14:59
<
uvos >
its been awake more
14:59
<
freemangordon >
yeah
15:00
<
freemangordon >
also grep keeps it awake for longer
15:00
<
uvos >
sure but thats after the read
15:00
<
uvos >
and the window isent 30 s long
15:00
<
freemangordon >
I think it is longer than 30s
15:01
<
freemangordon >
at least a minute
15:01
<
uvos >
i dont think so
15:01
<
uvos >
but wating 1 minute like i do
15:01
<
uvos >
would make the results more comperable in this case
15:02
<
freemangordon >
ok, lemme change the delay
15:03
<
uvos >
so doing what you do gives me 158990 btw
15:03
<
uvos >
while the cron job was saying 92 before
15:03
<
uvos >
so i dont think anythings wrong
15:04
<
freemangordon >
hmm
15:04
<
uvos >
or wrogner than here :P
15:04
<
freemangordon >
108292
15:04
<
uvos >
android dose 30mW
15:04
<
freemangordon >
for 1 minute with iphbd
15:04
<
freemangordon >
but we don;t have off mode?
15:05
<
freemangordon >
btw, why?
15:05
<
uvos >
was never implmented in the mainline kernel
15:05
<
Wizzup >
would be nice to have ofc :p
15:05
<
freemangordon >
maybe we shall pester tmlind :)
15:06
Joanna has quit [Quit: Connection closed for inactivity]
15:08
Livio has quit [Ping timeout: 268 seconds]
15:10
Livio has joined #maemo-leste
15:10
Livio has joined #maemo-leste
15:10
Livio has quit [Changing host]
15:10
<
freemangordon >
I'll leave it running for 10 minutes and then will do the same without iphbd
15:12
<
uvos >
speaking of off mode
15:12
<
uvos >
the other 2 things the android kernel dose that we dont pm wise
15:12
<
uvos >
is clock sgx down and change the emif operating point
15:13
<
uvos >
this is probubly the reason we use more power while not idle
15:13
<
freemangordon >
I don't think clocking sgx down will help a lot
15:13
<
freemangordon >
no idea what emif is
15:14
<
uvos >
idk how mutch these things account for and wont speculate
15:14
<
freemangordon >
I think our buggest issue is dss being on
15:15
<
freemangordon >
because sgx is idle most of the times
15:15
<
freemangordon >
basically sgx clocks are stopped as soon as there is nothing for it to render
15:15
<
freemangordon >
IIUC
15:16
<
uvos >
this broke after swiching form ddk1.9, but you said it works again
15:16
<
freemangordon >
yes, you can check in /kernel/debug
15:16
<
freemangordon >
it is OFF even when display is ON
15:29
_CN_ has quit [Remote host closed the connection]
15:31
<
freemangordon >
iphb on: 10 samples average: 158.5mW, lowest reading 105.6, 8 samples average (highest and lowest samples removed): 155.2
15:31
<
freemangordon >
iphb off: 10 samples average: 182.8mW, lowest reading 132.6, 8 samples average (highest and lowest samples removed): 182.2
15:31
<
freemangordon >
ok, some results:
15:31
<
freemangordon >
uvos: ^^^
15:32
<
uvos >
im not sure why iphb would hurt
15:33
<
freemangordon >
well, you was against it IIRC
15:33
<
uvos >
im skepitcal it would help (much)
15:33
<
uvos >
but thats different from it hurting
15:33
<
freemangordon >
~25mW on average for 2 jabber accounts is lots IMO
15:34
<
uvos >
how often dose it try and refesh?
15:34
<
freemangordon >
every 30 seconds iiuc
15:34
<
freemangordon >
but with iphb this gets synced, so you have only one wake for both accounts
15:35
<
freemangordon >
the more users the more the saving will be
15:35
<
freemangordon >
like, modest supports iphb as well
15:35
<
uvos >
but also why dose telepathy not sync refreshes with itself
15:35
<
uvos >
why dose it need the kernel to do that
15:36
<
uvos >
also maybe there is some other way to accive the same thing, besides introducing a custom kernel module
15:36
<
freemangordon >
no, wait
15:36
<
freemangordon >
kernel module is used in a different way
15:37
<
freemangordon >
it just signals userland that there is something to be send over the wire
15:37
<
freemangordon >
so radios will be on anyways
15:37
<
freemangordon >
so, if there are clients whose wake time is nearby, just wake them up now
15:37
<
uvos >
i also wonder how android handels this
15:37
<
freemangordon >
no idea
15:37
<
uvos >
alot of android patches ended up in mainline
15:37
<
uvos >
(android boots on mainline now basicly)
15:38
<
freemangordon >
well, wakelocks :)
15:38
<
freemangordon >
I would bet on that
15:39
<
freemangordon >
so maybe it is more or less the same, besides I don;t know how it communicates when kernel tcp stack has something to send
15:40
<
freemangordon >
how feasible is to have pre-build kernel module in the repos?
15:40
<
freemangordon >
instead of doing dkms build
15:40
<
uvos >
would be quite the headache i imagine
15:41
<
freemangordon >
ok, lets stick to dkms for now
15:41
noidea_ has quit [Ping timeout: 265 seconds]
15:41
<
uvos >
we could also just add it to the kernel
15:41
<
uvos >
its not like its relevant on x86
15:42
<
uvos >
and everywhere else we build the kernel anyhow
15:42
<
freemangordon >
I prefer dkms way
15:43
<
freemangordon >
otherwise it will not be possible to test on the VM
15:46
alex1216 has quit [Quit: WeeChat 2.3]
15:54
<
freemangordon >
uvos: Wizzup: why linux-headers-generic is not provided by omap kernel headers?
15:54
<
freemangordon >
omap kernel headers package that is
16:01
xmn has joined #maemo-leste
16:03
noidea_ has joined #maemo-leste
16:08
noidea_ has quit [Client Quit]
16:08
noidea_ has joined #maemo-leste
16:13
<
freemangordon >
do you mind if I add it?
16:18
<
Wizzup >
not sure why it is like that
16:18
<
Wizzup >
I mean if it provides the headers
16:19
<
freemangordon >
it provides linux-headers, but IIUC virtual package should be linux-headers-generic
16:19
<
freemangordon >
at least this is what is provided by amd64 devuan kernel
16:20
<
freemangordon >
ok, going to change that
16:29
norayr has left #maemo-leste [Disconnected: closed]
16:30
<
freemangordon >
hmm ok, actually this is the correct virtual package name
16:30
<
freemangordon >
Wizzup: please remove linux-headers-n900 and linux-headers-droid4 packages
16:31
<
freemangordon >
oh, you can;t
16:32
<
freemangordon >
I shall disable -stable repo
16:32
<
freemangordon >
Wizzup: is -omap kernel in -stable?
16:33
<
freemangordon >
yes, it is
16:33
<
freemangordon >
so, I think we shall remove all the old n900/droid4 kernels
16:34
norayr has joined #maemo-leste
16:37
<
freemangordon >
I assume no, if you onject, please LMK and I'll revert
16:38
<
freemangordon >
*object
16:40
asdflkj_sh has joined #maemo-leste
16:44
<
Pali >
I'm fine with it!
16:44
<
freemangordon >
ok, thanks
16:51
<
Wizzup >
freemangordon: I can remove any pkg if needed
16:54
<
freemangordon >
Wizzup: please remove all old kernels (and headers) then
16:54
<
freemangordon >
they are not used anyways
16:54
<
freemangordon >
and just create trouble
17:03
<
Wizzup >
freemangordon: ok, can you be explicit?
17:04
<
Wizzup >
linux-headers-n900 and linux-headers-droid4 ?
17:05
<
Wizzup >
if we do that, and remove it from stable too, we also need a replacement for it for -stable usres
17:08
<
freemangordon >
we already have
17:09
<
freemangordon >
see ^
17:17
<
freemangordon >
thanks
17:22
Livio has quit [Ping timeout: 260 seconds]
18:00
Livio has joined #maemo-leste
18:00
Livio has quit [Changing host]
18:00
Livio has joined #maemo-leste
18:16
Livio has quit [Ping timeout: 248 seconds]
19:17
<
freemangordon >
Wizzup: wich package to add dependency to?
19:17
<
freemangordon >
hildon-connectivity-meta?
19:21
Daaanct12 is now known as Danct12
19:36
<
Wizzup >
freemangordon: for what package?
19:37
<
freemangordon >
iphbd
19:37
<
freemangordon >
the daemon itself
19:41
<
Wizzup >
I think hildon-connectivity-meta is fine for now
19:43
<
Wizzup >
will it depend on the dkms pkg too?
19:46
<
freemangordon >
iphbd depends on it
19:46
<
freemangordon >
so meta needs only iphbd dependency
19:50
Twig has quit [Ping timeout: 252 seconds]
19:50
Joanna has joined #maemo-leste
19:53
<
Wizzup >
let's make it -devel only for now?
19:53
<
freemangordon >
sure
19:53
<
freemangordon >
will you add that dependency?
19:54
<
Wizzup >
I can in a few minutes
20:09
Twig has joined #maemo-leste
20:16
Livio has joined #maemo-leste
20:16
Livio has quit [Changing host]
20:16
Livio has joined #maemo-leste
20:46
mardy has quit [Quit: WeeChat 3.5]
20:49
Twig has quit [Ping timeout: 265 seconds]
20:50
akossh has joined #maemo-leste
21:39
sunshavi has joined #maemo-leste
21:42
Keeblo has joined #maemo-leste
21:42
Keeblo has quit [Remote host closed the connection]
21:45
LjL has quit [Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.]
21:55
Livio has quit [Ping timeout: 265 seconds]
21:57
akossh has quit [Remote host closed the connection]
22:00
Joanna has quit [Quit: Connection closed for inactivity]
22:08
Joanna has joined #maemo-leste
22:11
vagag has joined #maemo-leste
22:14
uvos has quit [Ping timeout: 250 seconds]
22:15
Joanna has left #maemo-leste [#maemo-leste]
22:22
akossh has joined #maemo-leste
22:25
noidea_ has quit [Ping timeout: 265 seconds]
22:39
LjL has joined #maemo-leste
22:44
Pali has quit [Ping timeout: 250 seconds]
23:09
norayr has left #maemo-leste [Error from remote client]
23:16
akossh has quit [Quit: Leaving.]
23:16
norayr has joined #maemo-leste
23:18
vagag has left #maemo-leste [#maemo-leste]
23:23
norayr has left #maemo-leste [Error from remote client]
23:25
norayr has joined #maemo-leste
23:51
lightbringer has quit [Ping timeout: 260 seconds]
23:52
lightbringer has joined #maemo-leste
23:52
lightbringer has joined #maemo-leste