Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
<stan>
buzz, seems to boot without any of those things on the back cover connected
<stan>
there's a removable rubber tab next to the speaker also, i wonder what that was intended for
Daanct12 has quit [Quit: Quitting]
cockroach has quit [Quit: leaving]
Daanct12 has joined #maemo-leste
Pali has quit [Ping timeout: 246 seconds]
Daanct12 has quit [Client Quit]
Daanct12 has joined #maemo-leste
<Daanct12>
Good morning aikon fellas
<stan>
hi Daanct12 hows your maemo-leste experiences
<Daanct12>
Pretty ok, except for the fact that i couldn't find apps i need
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 258 seconds]
joerg has quit [Killed (sodium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 252 seconds]
<parazyd>
Wizzup: Could you link to the code where this advanced_show ism
<parazyd>
is?
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
reallll is now known as belcher
_uvos_ has joined #maemo-leste
<_uvos_>
stan: the contacts in the rear frame are antennas. from memor,y the ones at the bottom are for cellular
<_uvos_>
the rubber around the speaker is for dampening ofc
_uvos_ has quit [Ping timeout: 272 seconds]
inky has quit [Ping timeout: 272 seconds]
inky has joined #maemo-leste
pagurus has joined #maemo-leste
rafael2k has quit [Ping timeout: 258 seconds]
<Wizzup>
parazyd: the plugin part or the plugin loader part?
<parazyd>
22:30 <Wizzup> parazyd: freemangordon: looks like connui plugins can have plugin->advanced_show = to have settings show up in advanced settings, so we could do that for provider
<freemangordon>
Do you think we can do anything else re u-boot but migrate to DT?
<Pali>
freemangordon: Hi!
<freemangordon>
keep in mind that ACM functionality won;t be affected by that, IIUC
<Pali>
I'm wondering how long would take them again to review patches...
<freemangordon>
and by removing dead code we can keep -mthumb disabled
<Pali>
there are still more n900 patches in queue
<freemangordon>
well, I guess we can put pressure now we are forced to do DT
<freemangordon>
also, I still think Tom is a reasonable guy
<Pali>
do we have enough space for DTB blob? and do we have space for libfdt code?
<freemangordon>
yes, we do
<freemangordon>
once we remove host and hub code
<freemangordon>
worst case we'll enable -mthumb
<freemangordon>
NOLO manages to live with it, so I am (almost) sure u-boot will do too
<Pali>
I do not have power for this project anymore...
<freemangordon>
:)
<Pali>
they just want from us things which are not required for other subsystems, like that requirement for DT
<freemangordon>
well, we can jsut fork
<Pali>
and I really do not have power to discuss on this topic anymore
<freemangordon>
ok
<Pali>
I did everything what was possible, but everytime they either ignore pending patches or come up with new idea how to increase work on this project, just because they can
<Pali>
I really do not understand this discussion as year ago we were told that U_BOOT_DRVINFOS() approach is OK
<Pali>
and now when we sent last patches for DM, somebody said that DTS is required
<Pali>
so it means that whole work which was done can be trashed and migration can start from zero again
<Pali>
not mentioning that these patches were waiting in queue for review for a very long time and nobody complained
uvos has joined #maemo-leste
<freemangordon>
ok then, I'll make one last effort(not now though) to convince Tom their approach is destructive and if that disagree, well, not much that can be done
<uvos>
Pali: dont let it get yourself down :)
<freemangordon>
uvos: feel free to join the discussion on the ML
<uvos>
Pali: besides, its a bootloader keeping it at some old working version as a fork is not sutch a huge loss
<uvos>
freemangordon: i think youd rather i not :P i think the "demands" are resonable.
<Pali>
you can guess what happen if we invest lot of time to DTS migration...
<Pali>
... somebody else come up with another idea what is requirement for us and say that it must be done
<Pali>
and we will start again this discussion which ends up with the fact that what we did was useless...
<freemangordon>
yeah, looks like
<uvos>
i mean thair goal is pretty obivous, they want n900 to be as little maintaints burden as possible, that means proting to whatever is the latest mechanisum in uboot so it istent in the way of droping old mechanisums
<uvos>
would this be a good thing? yes! is it reasonable to make you do it? maybe no.
rafael2k has joined #maemo-leste
<Wizzup>
freemangordon: should we have one tab per provider in advance settings, or one tab with providers? I think the former
<uvos>
if its causing stress i would just fork. the it seams unlikely that uboot would add any functionality we would need within the resonable usefull life of the n900 no?
<sicelo>
freemangordon, sounds like you would be willing/able to do some of the DT migration for N900 u-boot? :)
<sicelo>
assuming you have the time/energy for it, i guess it's worthwhile to investigate
<Wizzup>
we really have a lot of other thing we'd rather focus on though.
<Wizzup>
that we need fmg for, too
<Wizzup>
uvos: btw, using mdbus2 you can see if ofono is willing to activate context at all, I find that sometimes the call to set the context to active just times out and it never works
<Wizzup>
and I don't know why ofono does that, but then the state forever cannot be changed
<Wizzup>
it will always say "operation in progress"
<uvos>
Wizzup: ok
<uvos>
Wizzup: ill take a look at ofono, but
<Wizzup>
one thing we could consider for debugging some of this is to use the ofono path where it does everything over usb
<Wizzup>
it's a big power draw but we can rule out ofono specific bugs this way
<Wizzup>
not for production usage, of course
<uvos>
my current todo list looks like this 1. add a mixer controll to kernel that activates the PGA for voice 2. rebase cmake mce 3. implment minimal mce stuff needed for sphone 4. fix sphone ofono 5. look a ofno
<sicelo>
of course
<Wizzup>
let's add mine as well then: 1. create connui-provider and learn about connui plugins 2. libicd-dummy-provider to act more like normal provider 3. wlan scan troubles 4. pulseaudio setup/integration (would give volume applet, alarms actually working, ...)
<Wizzup>
there's a lot of misc stuff too but that's my plan code wise
<uvos>
sounds good
<Wizzup>
If connui plugins work like how I understand they work, then it's kinda neat
<uvos>
thats good. so far connui has been a bit of a minefield from a users perspective
<uvos>
not sure if its still a thing with connui changes
<Wizzup>
would be good to check I guess
xmn has joined #maemo-leste
<tmlind>
uvos: your voice call todo list order sounds good to me :)
stan has quit [Quit: Lost terminal]
<Wizzup>
freemangordon: ah, looks like connui will only allow one "plugin" per network type, so the idea of connui-provider as iapsettings plugins does not work
<Wizzup>
we'll have to add it to connui-internet or add some other plugin loading capabilities, potentially regardless of network type
<Wizzup>
so currently there can only be one active "advanced" plugin per network type
cockroach has joined #maemo-leste
<Wizzup>
I will turn this into connui-dummy to at least make a simple plugin to show how it can work, and then look at adding providers to connui-internet directly, I think
<Wizzup>
freemangordon: nvm, I'll debug more later
inky_ has joined #maemo-leste
<Wizzup>
uvos: ok yeah I can confirm that scans are started but the results aren't read by icd2 plugin somehow
<Wizzup>
will investigate that a bit later, spend quite a few hours on this connui-dummy now
<Wizzup>
uvos: oh... I think I see it
<Wizzup>
will confirm a bit later
uvos has quit [Ping timeout: 265 seconds]
<Wizzup>
uvos: so one problem was in my code which checked the return code of the wpa_ctrl_request, but it also looks like wpa supplicant does not populate bss info or something
inky_ has quit [Read error: Connection reset by peer]
<Wizzup>
uvos: lol, this gets better, I'll let you know after coffee
<Wizzup>
so wpa_ctrl_request often returns -1 when it succeeds
<Wizzup>
and my code was checking for it to be == 0, and it should be != 0 because of how the function returns its result, but then I got no scans at all since it always reported failure, even though it did scan
<Wizzup>
just ignoring the result all together seems to make it work just like old times (well)
<Wizzup>
I'll have to dive in a bit more I suppose, see why it's failing like this
<Wizzup>
parazyd: I think with new ke-recv the reboot problem might be gone? seems weird though, I can't reproduce anymore
<Wizzup>
stan: yw hope it helps
mrkrisprolls has joined #maemo-leste
<bencoh>
sicelo: the fremantle phoneapp isn't that good anyway, in my opinion
<Wizzup>
we'll keep the rtcom-eventlogger backend and stuff, and also have tp integration eventually of course
inky_ has quit [Ping timeout: 268 seconds]
inky has joined #maemo-leste
<Wizzup>
parazyd: connui-dummy is there, it's not of much use, but it was missing and it was good for me to learn how to do this
<bencoh>
Wizzup: was the wifi-switcher applet left behind on purpose?
<bencoh>
oh btw, I get 116mW on droid4 after boot and wlan0 interface down, which is nice
<stan>
btw i have one otg hub that works, but the very compact one here does not for me - as soon as i plugin a device i get disconnects/reconnects on the usb hub https://www.ebay.de/itm/294134869562?hash=item447bcdee3a:g:8csAAOSwbhNgNhR4
<sixwheeledbeast>
not clearly proven, so left in devel maybe?
<sixwheeledbeast>
oh no its extras package
inky has quit [Ping timeout: 272 seconds]
<bencoh>
looks like I have something working ... apart from the fact that it doesn't update the status applet (it should say "off" when wifi is disabled)
<bencoh>
heh, the applet itself checks whether module is loaded or not ...
<Wizzup>
bencoh: it's possible that the current icd2 module doesn't handle the interface going off (i.e. the applet might still show connected)
<Wizzup>
I think I need to handle that wpa_supplicant dbus signal still
<bencoh>
Wizzup: it reads /proc/modules
inky has joined #maemo-leste
<Wizzup>
I meant wrt updating the status applet
<bencoh>
yeah, me too
<Wizzup>
ok
<bencoh>
but I don't unload the driver, so it's makes sense
<Wizzup>
ok
<Wizzup>
reading specific driver name is not ideal
<Wizzup>
we could probably find out which driver owns which interface
<bencoh>
I don't intend to unload the driver anyway, unless you think it'd be better
<bencoh>
oh, I'm currently testing on droid4, btw
<Wizzup>
check
<bencoh>
we might want to release a slightly different version for n900
<Wizzup>
why?
<bencoh>
on n900 it used to unload driver, I dunno if this is still required on mainline
<Wizzup>
does anyone know any sensible dummy icons?
<Wizzup>
preferrably already avail on leste
* bencoh
gives a dummy look
<Wizzup>
hehe
<Wizzup>
maybe I can use a 'no connection' icon
<Wizzup>
general_presence_offline will do
rafael2k has quit [Ping timeout: 240 seconds]
<sicelo>
Wizzup: wifi connection working better now - seems bug fixed. gsm internet still won't connect
<Wizzup>
sicelo: yeah, didn't work on it
<Wizzup>
(gsm)
<Wizzup>
freemangordon: would it be a problem to link libconnui in a icd2 provider?
<Wizzup>
I want to use it's gconf IAP config read stuff
<Wizzup>
freemangordon: in particular iap_settings_get_gconf_value
<sicelo>
i don't know if it was mentioned, regarding the gsm issue, that it's not possible to set APN now, as clicking Next after the connection name dialog goes nowhere
<bencoh>
alright, the good news is that the switcher works properly on droid4. but it looks like it hardly has any noticeable effect on battery use
<Wizzup>
bencoh: there are bursts every now and then
<Wizzup>
there should be a small effect
<sicelo>
i don't recall that it had that much noticeable effect on N900 too :)
<bencoh>
Wizzup: even with wifi off? well, glad I ported it then :)
<bencoh>
(I mean, disconnected*)
<Wizzup>
bencoh: yes
<Wizzup>
no
<Wizzup>
not with wifi off
<Wizzup>
sorry
<Wizzup>
with the interface disabled I think it's the same
<Wizzup>
cool that it works
<bencoh>
oh and, serial power management is great :)
<Wizzup>
yup, just something to be aware off when pasting
<Wizzup>
(since you lose the first char)
<bencoh>
:)
<Wizzup>
sicelo: thanks for testing wlan fixes btws
<Wizzup>
s/btws/btw/
<bencoh>
should I assume ifconfig is availabel on leste? (I guess no, but ...)
<sicelo>
it is available
<Wizzup>
for the applet?
<sicelo>
Wizzup: cool
<bencoh>
Wizzup: yeah
<bencoh>
that tool has been obsolete for a decade :]