joerg has quit [Killed (calcium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
<AaronBurr>
any progress joerg ?
belcher_ is now known as belcher
Pali has joined #maemo-leste
uvos has joined #maemo-leste
Pali has quit [Ping timeout: 258 seconds]
ikmaak has quit [Read error: Connection reset by peer]
ikmaak has joined #maemo-leste
Blikje has joined #maemo-leste
<Wizzup>
freemangordon: regarding some telepathy ui for messaging (conversations clone), what do you think makes sense for prototyping and/or production, what language and widget set to write it in?
<Wizzup>
The way I see it, we can do a few things:
<Wizzup>
1. modify/build-upon empathy heavily (which is gtk3)
<Wizzup>
2. make our own quick prototype in C/Python, where we don't care much about the widgetset but rather getting something that works for us for now
<Wizzup>
3. Go with gtk2/C, try to stay as close as possible to conversations
<Wizzup>
I think (3) would potentially be the hardest
<Wizzup>
We (parazyd and I) have set ourselves a soft deadline of ~10 sept or something to have something that can at least do basic telepathy stuff with gabble (xmpp/gtalk), and nothing else yet
<Wizzup>
Of course there's the whole rtcom-eventlogger integration that needs to follow
<Wizzup>
but the idea is to at least think about how a UI can look that supports many protocols, how we can have that in one application, etc
<Wizzup>
adding the 'tel' protocol via telepathy-ring/telepathy-ofono would be a next step, with rtcom-eventlogger support
<Wizzup>
I'm a little bit inclined to do it in qt and python is possible (maybe C/C++ is easier if no bindings exist) because it makes for much easier prototyping
<Wizzup>
of course, any backend stuff like eventlogger we'd do in C anyway
<Wizzup>
(opinions from others also welcome, of course)
* uvos
reads
<uvos>
i think this is a problem that needs a global decision really, effectively, eventually we have to move from gtk2 to something newer and any new applications we implment that are supposed to be in core should move in the same direction.
<Wizzup>
I'm just not at all well versed in gtk2 and dislike building UIs from code
<Wizzup>
if we can make it happen with glade for now, I'd be OK with that
<Wizzup>
when it comes to forward thinking, I'm all for using modern backends, but am OK with living with gtk2 until we have a working thing in gtk2 and then port it over to gtk3 with the same functionality
<parazyd>
Glade is not ideal
<uvos>
Wizzup: then you should write your new application in gtk3
<Wizzup>
but for me personally, making gtk UIs is klunky, I'm really bad at it
<Wizzup>
(the same is true for gtk3)
<Wizzup>
I don't think gtk2 and gtk3 are all that differente in that regard
<uvos>
no
<uvos>
gtk3 is worse imo
<Wizzup>
yeah, well, either way :p
<Wizzup>
I could do it much more easily in qt5 for example
<uvos>
so moving to gtk3 is a bit easier but note that some of the stuff we have in gtk2 needs to be rewirtten anyhow (like hildon-desktop, realistcly this will never be a wayland compositor)
<uvos>
Wizzup: i dont think we want to have stuff in gtk3 and qt provideing core stuff
<uvos>
in the long run
<Wizzup>
I guess my question wasn't so muhc gtk2 vs gtk3 but more gtk vs qt
<uvos>
so we need to choose
<parazyd>
wdym in the long run?
<parazyd>
Are you against combining gtk and qt?
<uvos>
yes in core that makes no sense
<uvos>
and is delapidating for n900 too
<uvos>
(since both allways need to be in ram)
<uvos>
parazyd: in the long run we need to move the gtk2 stuff somewhere else
<uvos>
and we should have everything on one toolkit
<Wizzup>
yeah, for ram purposes it's nicer if they are the same, but I don't have big problems with some things being qt as well
<Wizzup>
maybe we need to define 'core' as well
<parazyd>
I'd argue that hildon is separate from, say, conversations
<uvos>
right what is core is up for argumentation
<Wizzup>
right, we do have lots of things in qt5 (calendar is one, open media player will be another)
<uvos>
i think coversations qualifys
<Wizzup>
yeah it might very well qualify
<uvos>
Wizzup: i know
<uvos>
Wizzup: i dont like this
<uvos>
Wizzup: unless the choice is to move everthing to qt eventually
<Wizzup>
uvos: well it was a case of, the community did a port of a closed thing, and it was qt5, so we build it and voila
<Wizzup>
the original things were gtk2 mostly but closed, so yeah
<uvos>
yes i know our pedecessors made manny unfortionate descissions
<Wizzup>
if I have to pick between nothing or qt5, it's an easy choice :p
<uvos>
we need to have a route out of the mess
<uvos>
it need not be done soon in any way but a clear route must be stated
<Wizzup>
ok, but I'd like to focus a bit om my more immediate question as well
<Wizzup>
gtk2 can be done in python as well for example (although I don't like that as much)
<uvos>
well the immediate question follows from what long term goal we choose
<uvos>
unless you go gtk2
<uvos>
i dont think thats sane at all though
<uvos>
since that just forces someone to port it later
<Wizzup>
I think for some things it is not necessarily bad to make a prototype in widget set A and language B, and then port it all to widget set C and language D when the prototype part is done
<uvos>
unrelated: a side benefit of you doing it in qt is it forces you to finally fix the damn issues the qt port has :P
<Wizzup>
do we have a list of the bugs?
<uvos>
just various ones
<Wizzup>
the one that bugs me the most is him integration, but I know there is one thing with the back-forth window stacking
<Wizzup>
there is qscroller crashes but that is a qt problem we need to backport
<Wizzup>
backfix, or w/e
<uvos>
but the theaming is pretty broken and needs to be reworked, it needs to have standard widget sizes that we then scale, there is the problem with the grab transfer not working right, there is the problem with window stacking there is him
<uvos>
maybe others
<uvos>
i dont think there is a list
<uvos>
just various bug reports
<uvos>
it would also be really cool if the qmenu integration could be reworked
<uvos>
so maemo apps just use one level of actions in qmenu
<uvos>
and for desktop apps the qmenu gets flattend
<uvos>
but really we could implment a hieracy
<uvos>
that opens more dialogs to navigate the menu
<uvos>
Wizzup: but since its out of date and everything there thats still relevant is in other issues.
<uvos>
Wizzup: but ill leave that up to your discretion
<uvos>
s/but/
<Wizzup>
will check in a bit
fremantle has joined #maemo-leste
<fremantle>
test
<Wizzup>
fremantle: bok
fremantle has left #maemo-leste [#maemo-leste]
fremantle has joined #maemo-leste
fremantle has left #maemo-leste [#maemo-leste]
fremantle has joined #maemo-leste
fremantle has left #maemo-leste [#maemo-leste]
<freemangordon>
Wizzup: honestly, I'd go with qt5 too, the only concern I have is resource usage
<freemangordon>
also, using qt does not contradict with keeping it cole to fremantle ui
<freemangordon>
we can use QtWebEngine/QtWebEnginWidgets to render, in the same way fremantle does
<freemangordon>
we can simply reuse js/css IIUC
<freemangordon>
which does all of the heavy work
<freemangordon>
but OTOH conversations UI should be simple, so gtk should be no problem
<freemangordon>
IIUC
<freemangordon>
or I am missing something
<freemangordon>
cole? hmm, what did I want to say? I guess co-'mpatib'-le
<uvos>
freemangordon: so are you suggesting to port the gtk2 to qt5+ too?
<uvos>
eventually ofc not now
<uvos>
*gtk2 stuff
<freemangordon>
in particular for conversations
<freemangordon>
not in general
<tmlind>
uvos: so on the buggy cpcap regs, what are the android values vs mainline values?
<tmlind>
probably a typo somewhere as i had to combine 2 android value tables into one..
<tmlind>
also, maybe the uncleared cpcap registers explain why power consumption is greater with mainline kernel after poweroff
<uvos>
tmlind: vhvio is regulator fixed @ 2775000uV in the mainline kernel and the mainline kernel sets CPCAP_REG_VHVIOC/0x0644 to 0x17
<uvos>
the moto kernel also has it @ 2775000uV according its source but the register ends up @ 0x12 in every operating mode i could think of to test
<uvos>
setting it to 0x12 on the mainline kernel dosent seam to break anything
<tmlind>
weird
<tmlind>
do the other regulator values match then?
<uvos>
yeah
<uvos>
i think 0x12 is simply off for this regulator
<uvos>
so the android kernel allways has this off
<tmlind>
oh
<uvos>
no idea what its connected to
<uvos>
i tried using every periferal i could think of
<tmlind>
so maybe we can just remove regulator-always-on for vhvio
<uvos>
but maby the off thing is wrong
<tmlind>
it might be used by w3glte
<uvos>
its possible
<uvos>
i cant test that
<uvos>
but i suspect android would turn on the lte modem
<uvos>
at least for a while after boot
<tmlind>
yeah
<tmlind>
if android has it at 0x12, then we should fix the off val in the mainline regulator table and remove regulator-always-on
<uvos>
yeah
<uvos>
but since we dont know what its connected to....
<tmlind>
oh the off value is correct in mainline at 0x12
<uvos>
btw the cleared registers are all registers past 0x7c9c i have no idea what these are
<uvos>
on mainline these read various non zero values
<uvos>
we dont set them anywhere
<uvos>
in android they all read 0
<tmlind>
the thing to do would be to take a spare droid4 and float off all the components, then have it xrayed like somebody suggested few years ago :)
<uvos>
yeah
<tmlind>
anybody have contacts in soldering shops in asia to do both for us?
<tmlind>
well anywhere in the world, naturally does not need to be asia, seems like that's where they mostly are
<tmlind>
uvos: no idea about the regs past 0x7c9c.. also, android keeps a mask for every register to avoid clearing some bits that we do not do
<tmlind>
uvos: looks like we have ak8975 using vhvio in the dts
<tmlind>
uvos: sorry lis3dh on droid4, ak8975 on bionic
<tmlind>
anyways, sounds like the regulator-always-on can be dropped
<uvos>
tmlind: yeah i know
<uvos>
tmlind: but its wrong
<uvos>
you can use the accel in android no problem with the reg at 0x12
<tmlind>
maybe not if not used as vio for anything else
<uvos>
and i just did the reverse
<uvos>
and the accel works fine in mainline with the reg off to
<tmlind>
heh
<tmlind>
does it work still with vhvio set to 0?
<uvos>
no that kills it
<uvos>
also als
<tmlind>
but system boots?
<uvos>
im modifying the values at runtime atm i can rebuild dts later
<tmlind>
sounds like the 0x12 value is some hack to keep some device partially enabled..
<uvos>
i gues maybe
<tmlind>
or 0x12 value might be set for faster enable time
<uvos>
but every periferal that i tried in android works with it like this
<uvos>
same with mainline right now
<tmlind>
would be interesting to see what the voltage difference is between 0x12 and 0x17
<uvos>
no doubt maybe i can grab it from bionic
<tmlind>
i guess the 0x17 value could explain higher poweroff voltage with mainline kernel
<uvos>
yes
<uvos>
current i assume
<tmlind>
we have about 1mW enabled on poweroff i think
<tmlind>
compared to android
<uvos>
i gues i could messure it
<tmlind>
maybe android disables something in the microcontroller on poweroff?
<uvos>
android dose disable all the macros before shutdown
<uvos>
but we dont enable them in the first place so eh
<tmlind>
but we have them enabled from kexec
<uvos>
hmm maybe ill try look into that when i back @home
<tmlind>
ok. food time here, bbl
<uvos>
on bionic the shutdown current is even worse
<uvos>
btw
<uvos>
but its clear what it is there
<uvos>
if you go into a very dark room you can see the android button leds glowing dimmly
<tmlind>
heh ok
<Wizzup>
freemangordon: check @ qt5
<Wizzup>
I'll respond in more detail in a bit, I don't think it would be that simple
<bencoh>
uvos: so basically droid4 just burns energy on dimmly-lighted leds and unneeded accelerometer?
Pali has joined #maemo-leste
<uvos>
bionic burns energy on a dimmly light light
<uvos>
the d4 dose not
<uvos>
it burns (mutch less) energy on something unkown
<tmlind>
after poweroff, compared to android, might be happening also during runtime
<uvos>
right
<tmlind>
i'm seeing occasional extra 1mW peaks after shutdown with mainline kernel that do not happen after shutdown from android
<uvos>
the light on bionic might give some credance to the idea that its cpcap-uc thats doing it
<uvos>
on bionic it its cpcap-uc that controlles the light in question
<tmlind>
on droid4, android is consuming little over 1mW after shutdown (probably the rtc?), mainline kernel 1 - 3 mW after shutdown
<uvos>
1mW is very high for an rtc
<uvos>
but sure
<uvos>
might be misc other leakage currents
<sicelo>
Wizzup: in terms of a Qt conversations clone, you may want to look at the yappari UI - i think i've mentioned this before
<sicelo>
i think ceene may be even able to help - i recall at some point he wanted to make it work with any other platform, e.g. Telegram
<uvos>
tmlind: CPCAP_REG_VHVIOC dosent appear to change this result any
<uvos>
tmlind: my d4 draws 0.11mA @ 4V if i shut down from kexecboot with the moto kernel
<uvos>
tmlind: and 0.20mA @ 4V if i shutdown with mainline
<uvos>
the d4 is really unhappy about the burdon voltage of my meter
<uvos>
so its pretty hard to messure (i had to have a jumper over the meter & only remove that when it turned off)
<tmlind>
yeah ok, the difference in values sound similar to what i'm seeing
<uvos>
honestly im not terribly worried about a difference of 400uW
<tmlind>
it sucks to shut down the device and then the battery is empty in a week :( btw, i'm using a ina226 i2c board with a 0.1 ohm shunt to measure the power
<uvos>
tmlind: yeah something like that is better than just a generic meter
<uvos>
they useualy have huge burden voltages
<tmlind>
yeah the ina226 i2c boards can be bought for about 5 units
<uvos>
i think i might even have one
<uvos>
ok i also tried setting 0x644 to 0
<uvos>
and shutdown
<uvos>
no change
<tmlind>
i soldered mine to a beaglebone pocket, can read the shunt with the kernel driver with just a script :)
<tmlind>
no kernel changes needed
<uvos>
but that wont work with my gpib setup :P
<uvos>
all my test and mesuremnt stuff is from the 80s mostly
<tmlind>
ok :)
<tmlind>
hmm i should see if my tube scope still works..
<uvos>
with those things its usually yes
<tmlind>
yeah unless caps have bloated
<uvos>
eh my main scope is a hp1741a from 1977, i replaced all the electrolitic caps, only a single one was slightly out of spec
<uvos>
its mostly the stuff after 1990 that has caps that die
<tmlind>
yeah
<sixwheeledbeast>
cap plague 1999>?
<uvos>
even before that the increased density did reliability in
<uvos>
but yeah it gets really bad with the plague years
<uvos>
its also surviorship bias and epensive test equpitment usualy has very high quality componants too. if an instrument has made it from the 60s or 70s to modern day that means the caps in that unit are pretty damn well seald or it would have broken and been tossed long ago.
<sixwheeledbeast>
I was replacing loads early 2k in allsorts of stuff. visual inspection look fine, popped underneath not at the vent.
<tmlind>
on bloated components, i got another confirmation that lineageos bloats droid4 battery if left connected for several weeks i guess
<tmlind>
sounds like also stock android as they use the same battd
<uvos>
i mean the batterys are legit 4.35v chemistry is a legit type that was popular at the time. it had worse cycle lifetime than regular lipos for a bit more energy desity. it fell out of favor because the 4.2V chemesties made up the difference in increased Ah
<uvos>
im not supprised that these very old batteries now bloat at a hight rate if charged to the maximum for weeks (something you should never do to a lipo anyhow)
<uvos>
maybe you can feed battd a bionic bw8x nvram
<uvos>
as this tells it to charge to 4.2v only
<tmlind>
heh yeah
<tmlind>
maybe this is the reason why so many devices on ebay are sold without back cover if it breaks :)
<uvos>
the cover broke instead of just being leveraged off?
<uvos>
thats pretty intense bloating then
<uvos>
good thing im not living within a fires reach of this guy ^^^^ who is holding 10 year old lipos at 4.35V for long periods
<tmlind>
heh i don't know if the covers can break with bloating
<Wizzup>
sicelo: good point regarding yappari
* tmlind
goes zzz
<Wizzup>
we don't have a ticket for sms/conversations specifically yet I think
<uvos>
Wizzup just wants the general ui implementation i suspect
<uvos>
not the whatsapp backend
<Wizzup>
freemangordon: for whatsapp yes, but it looks like conversations, is qt, and is foss :)
<Wizzup>
so looking around could be quite useful I imagine
<sicelo>
freemangordon: work was dropped on it because whatsapp was banning numbers wholesale. so the very last package is actually an empty package (because people didn't want to stop using it) :-p
<freemangordon>
mhm
<uvos>
Wizzup: maybe you can look sms for that too, either useing ofono directly or have sphone spit out a dbus call in place of a call to its own ui.
<Wizzup>
uvos: we really aim to use telepathy, so it'd be telepathy-ring, but yes
<Wizzup>
I met with parazyd irl today and we talked a bit about how the conversations ui could work/look (mostly like fremantle)
<Wizzup>
I'll try to sketch up something later, probably not for another week or 2 or so though
<uvos>
ok sure
<Wizzup>
in general we'd hope we can fit everything in telepathy (at least for most of the features), and then do specific things via user accounts UI, as in fremantle (i.e. changing protocol avatar or something, like how it does with skype)
<Wizzup>
and then the conversations UI would have various views for different protocols, and perhaps also a merged one just showing all latest messages
<freemangordon>
I really think we should be able to just reuse css/js