LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
xmn has quit [Quit: xmn]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
<tmlind>
freemangordon: did you still have some question for me? :)
<freemangordon>
tmlind: I guess a couple of :), not now though
<tmlind>
freemangordon: ok
<tmlind>
bencoh: the thermal sensor is different between 34xx and 36xx afaik
<tmlind>
bencoh: in case there really is a thermal shutdown capability on 34xx, then mmc1_dat4 may be available depending if data line numbering starts from 0 or 1 as only four data lines are used for mmc1
_inky has joined #maemo-leste
<tmlind>
Wizzup, bencoh: maybe check how fremantle has muxed mmc1_dat4/gpio_126 with rwmem -s 16 0x48002150
<tmlind>
if it's mmc1_dat5/gpio_127 instead, then rwmem -s 16 0x48002152
<tmlind>
see also 35xx trm page 874 for reference
alex1216 has joined #maemo-leste
asrieldreemurr has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #maemo-leste
Danct12 has joined #maemo-leste
<tmlind>
also, see if n900 temp sensor ends up getting fixed and enabled, then see also commit 5c3db2d4d4ed ("ARM: dts: motorola-mapphone: Configure lower temperature passive cooling")
<tmlind>
waking up the system once a second is not nice for pm :)
alex1216 has quit [Client Quit]
<tmlind>
for the poll time testing with heavy cpu load you can monitor the temperature, for droid4 10 seconds seemed like plenty of time to react
alex1216 has joined #maemo-leste
<freemangordon>
tmlind: the point is that omap34 thermal driver doesn't seem to support tshut gpio at all
<freemangordon>
and I wonder what happens if gpios start behaving on OFF mode
<freemangordon>
is it possible the interrupt/oops we see to be tshut gpio irq
<freemangordon>
tmlind: also, why gpio_126?
<tmlind>
freemangordon: the tshut seems to be gpio_127, i think bencoh got the mmc dat line wrong earlier
<freemangordon>
according to n900 schematics, mmc1_data4-mmc1_data7 are not connected
<tmlind>
freemangordon: gpio bank4 is not powered off during off mode, it won't produce any interrupt during off mode, the only way to do that would be based on the padconf interrupt
<freemangordon>
which means gpio_127 is not connected
<tmlind>
yeah duping the gpio_127 padconf value from fremantle kernel would show
<tmlind>
if it's not muxed to gpio_127 mode, then tshut interrupt is not used at all
<freemangordon>
tmlind: I understand, but if we have gpios behaving we could have phantom gpio interrupt, no?
<freemangordon>
tmlind: hmm, well, there seem to be some "comparator" there
<tmlind>
freemangordon: if tshut is a an edge interrupt, there may not be any status to be seen after waking up from off mode
<tmlind>
except ifconfigured as a padconf interrupt
<tmlind>
possibly
<freemangordon>
ugh, this is sim_clk too in mode2
<tmlind>
so mux to gpio_127 mode, in the dts configure tshut interrupt as the padconf pin interrupt and not as gpio_127
<freemangordon>
tmlind: I doubt this is used as gpio_127, iiuc sim_clk is used
<tmlind>
see the interrupts-extended configuration for let's say n900 uart
<tmlind>
freemangordon: ok, yeah dumping out the related padconf register from fremantle kernel would show
<freemangordon>
ok, lemme connect to my prod device
<freemangordon>
good that I have devmem2 there :)
<tmlind>
hmm actually, the sim is on the modem, not on 34xx, so unlikely sim_clk is used
<freemangordon>
Value at address 0x48002152 (0x4001f152): 0x7
<freemangordon>
somebody shall do that on leste
<freemangordon>
Wizzup: ^^^
<tmlind>
safe mode, not used at all, so yeah experimenting remuxing to gpio_127 and configuring the padconf interrupt as tshut is doable
<freemangordon>
tmlind: any clue what to dump to verify that?
<freemangordon>
ugh, I lost the diagram
<tmlind>
freemangordon: enable padconf register 0x48002152 wake bit manually after muxing to gpio_127 mode and see if you can get 0x48002152 event bit to trigger
<tmlind>
then just start compiling code
<tmlind>
or whatever might trigger overheating, i guess you could tweak the thermal alert values if doable
<tmlind>
see WAKEUPENABLE and WAKEUPEVENT for the padconf, 35xx trm page 769
<bencoh>
tmlind: ah nice, I didn't check if those were in use indeed :)
<tmlind>
those get automatically handled if a pad is configured as a wakeirq in the dts, like we have for uart3 rx pin for example
<tmlind>
if the padconf as tshut interrupt works, then ti-bandgap.c needs to be updated to understand interrupts property from dts, right now it seems to only understand a gpio pin
alex1216 has quit [Ping timeout: 256 seconds]
Pali has joined #maemo-leste
<freemangordon>
tmlind: I was not able to find TSHUT trigger temperature configuration in TRM
<freemangordon>
for 3430 that is
<freemangordon>
also, I am not sure i understand Figure 25-1 in the TRM
<freemangordon>
in regards to gpio 127 that is
<tmlind>
hmm my 35xx trm does not seem to have any 25-1 for gpio_127
<freemangordon>
SWPU223M – July 2007 – Revised February 2011
<freemangordon>
this is 34xx, not 35xx
<tmlind>
oh ok, seems to be "Figure 24-1. General-Purpose Interface Overview" for 35xx trm
<tmlind>
i guess the idea is that the tshut could be also handled externally by pmic for example?
alex1216 has joined #maemo-leste
<freemangordon>
hmm, yeah, could be
<tmlind>
i guess my question still is: what stops battery charger automatically if battery overheats?
<freemangordon>
sec (phone call)
alex1216 has quit [Ping timeout: 240 seconds]
<tmlind>
Pali: so does the bq2415x autotimer stop charger automatically if not kicked?
<freemangordon>
tmlind: on fremantle it is userspace that does it, afaik
<freemangordon>
on leste I guess noone :)
alex1216 has joined #maemo-leste
<tmlind>
freemangordon: well let's hope the bq2415x hardware timer automatically disables the charger if the os is hung
<freemangordon>
I doubt that's the case
<freemangordon>
but yeah, lets wait for Pali
<tmlind>
yeah
<Pali>
tmlind: yes
<Pali>
HW automatically reset charger registers to default values, which disable charging
<tmlind>
Pali: ok good to hear & thanks for confirming
<Pali>
:-)
<tmlind>
so the soc thermal stuff is a completely separate story then
<tmlind>
i guess the worst thing that can happen with the soc thermal failing is the device overheats and hangs or reboots
<tmlind>
so assuming the soc bandgap continuous mode helps with the long polling issue, the poll value could easily be 10 secs instead of 1 sec
<tmlind>
and then if somebody feels like tinkering, configuring the tshut interrupt is doable, but the polling already check the values
<tmlind>
Wizzup: if you can test your known working pm setup with the TI_BANDGAP_FEATURE_CONT_MODE_ONLY patch and increase cpu_thermal dts polling-delay-passive and polling-delay to 10000 ms, and see if n900 still keeps hitting off during idle normally
<freemangordon>
tmlind: sorry, I don;t get it why we need contiguous mode
<tmlind>
Wizzup: or if you have a patch that makes v5.15 enter off mode during idle on n900 normally let me know
<freemangordon>
fremantle kernel uses single mode happily
<tmlind>
freemangordon: i recall getting a bandgap value takes tens or hundreds of ms on omap34xx, just wondering if the continuous mode happens to fix that issue, needs to be traced for some timestamps
<freemangordon>
iiuc it takes 36 sycles
<freemangordon>
*cycles
<freemangordon>
on 32767 Hz
<tmlind>
oh ok, maybe that's only on 36xx then
<freemangordon>
the question is if contiguous mode increases idle current
<tmlind>
well it's only enabled when sampling, not continuously
<tmlind>
the continuous mode may not be needed at all on omap3, just wondering as Wizzup said it blocks idle
<tmlind>
4040.103058: ti_bandgap_force_single_read: wait eocz up
<tmlind>
4040.103607: ti_bandgap_force_single_read: done eocz up
<tmlind>
4040.103607: ti_bandgap_force_single_read: wait eocz down
<tmlind>
4040.104828: ti_bandgap_force_single_read: done eocz down
Pali has quit [Ping timeout: 240 seconds]
<freemangordon>
tmlind: single mode works in fremantle kernel, so I think you are right and no need for contiguous mode
<tmlind>
yeah so it seems, maybe it was only an issue on 36xx or maybe 4430..
<tmlind>
anyways, increasing the dts polling-delay values should be done
<freemangordon>
what was the current one?
<tmlind>
Wizzup: or is the system not entering off during idle if CONFIG_OMAP3_THERMAL=y, or am i confused about that too?
<tmlind>
freemangordon: currently set to 250 / 1000 ms, probably setting both to 10000 should be ok
<freemangordon>
ugh, 250 ms seems a bit fast to me :)
<tmlind>
yeah i wonder if that's some oversampling
<tmlind>
anyways, we restore the context on every exit from a deeper idle state, i wonder if that is needed at all
<tmlind>
at least on 4430 the bandgap register does not seem to lose context
<tmlind>
on omap3 it's in control module that should have automatic restore enabled i think?
<freemangordon>
no idea :)
<freemangordon>
I would trust you on that one
<tmlind>
well let's see if i get sane values after disabling context restore and waiting for off idle
<tmlind>
will check that later on
alex1216 has quit [Ping timeout: 240 seconds]
alex1216 has joined #maemo-leste
<tmlind>
hard to say if context is lost as i'm having hard time getting n900 to enter off during idle..
alex1216 has quit [Read error: Connection reset by peer]
alex1216 has joined #maemo-leste
uvos has joined #maemo-leste
alex1216 has quit [Read error: Connection reset by peer]
alex1216 has joined #maemo-leste
<tmlind>
yup the context restore is needed, otherwise omap3 context lost counters never increase for off during idle
<tmlind>
Wizzup: so sounds like increasing the dts timeouts is the only thing needed for thermal sensor, no idea what might be causing the crashes you're seeing though
<tmlind>
unless reading the thermal register values somehow produce invalid values that cause some software bug with table index out of range or similar
<tmlind>
see earlier commit 30d24faba053 ("thermal: ti-soc-thermal: Fix bogus thermal shutdowns for omap4430")
<tmlind>
freemangordon: care to check that we really have the right temp table for 34xx compared to fremantle kernel? it seems like it might be the same currently as for 36xx
<tmlind>
oh never mind, the 34xx table is different from the 36xx table, split window comaprison of two copies of 34xx table accident :)
<freemangordon>
tmlind: sorry, cannot do now, RL job :)
alex1216 has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: regarding what you want me to dump (0x48002152) - do you want me to do that with thermal/bandgap enabled or not, and with or without tony's patch
<Wizzup>
tmlind: ok, can do that @ 10000ms with known-working
<Wizzup>
(still reading backlog)
<Wizzup>
tmlind: ok, I'll increase the timeout and re-enable OMAP3_THERMAL and test if it enters idle
<Wizzup>
but yeah, the oopses would still be a problem if I read the backlog correctly
<tmlind>
Wizzup: yeah so for me v5.15 only rarely hits off even with the compact timeout part reverted
<tmlind>
yup
<Wizzup>
tmlind: and if you revert OMAP3_THERMAL ?
<Wizzup>
or rather, disable it
<Wizzup>
(in config)
<tmlind>
well that patch did not cleanly revert against v5.15
<tmlind>
even with .config change, the timeout is still there, right?
<tmlind>
or are you seeing v5.15 hitting off easily when idle?
<Wizzup>
Yes, my current 5.15 hits OFF easily when in init=/bin/bash and OMAP3_THERMAL=n
<Wizzup>
of course serial has to be detached
<tmlind>
hmm, so with only .config option for compaction disabled?
<tmlind>
i'm seeing 36xx enter off all the time with same kernel.. of course it has much faster cpuidle times configured
<tmlind>
not sure why i'm not seeing off more.. but good to hear you have it working
<Wizzup>
tmlind: it would be better if we both see it working I'd say
<Wizzup>
so what are you seeing now and what would you expect?
<tmlind>
i'm kind of expecting off to happen more often like my 36xx based system is doing, could be n900 manages to sleep a really long time here too.. i should see that from cpuidle stats
<Wizzup>
ok, I could check my setup if it is helpful btw
<Wizzup>
not sure what you check in cpuidle
<tmlind>
not sure if this is a count or time.. but cat /sys/devices/system/cpu/cpu0/cpuidle/state[0123456]/usage
<tmlind>
ah do cat /sys/devices/system/cpu/cpu0/cpuidle/state[0123456]/time
<rafael2k>
hi everybody - just passing buy - happy the pinephone keybaord will start selling "first weeks of january"
<rafael2k>
; )
<rafael2k>
btw, since latest kernel update, about 6 months ago, pinephone is with broken telephony support in kernel...
<rafael2k>
*passing by
<rafael2k>
I finally bought a SIM card with data plan for my pinephone, and now I can confirm latest kernel update long time ago broke telephony, as I suspected.
<rafael2k>
I'll just copy the kernel and modules from mobian and be happy
pere has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<rafael2k>
ow yeah, 4G working
<rafael2k>
I made a tarball with the kernel and modules.. just uncompressing in the root directory will work. I'm uploading to the lazy ones which just want maemo working and don't have time (yet) to update the broken kernel shipped:
<uvos>
freemangordon: i mean the ranges work then, but the real issue that the coodinates are different between a widget inside of a hildon-pannable-area and one outside is not solved
<uvos>
this seams to just sweep the real issue under the rug for this one widget
<uvos>
appearanly the favorite solution to any problem for nokia engineers to any problem
<uvos>
*appearanly the favorite solution to any problem for nokia engineers
calx_ has joined #maemo-leste
R0b0t1`` has quit [Ping timeout: 268 seconds]
R0b0t1`` has joined #maemo-leste
calx_ is now known as calx
calx has quit [Quit: Leaving]
<rafael2k>
the MTS network is not configured for VoLTE, it uses CSFB and switched to GSM in a voice call. cool
<rafael2k>
sphone is not working yet, but I'm happy I got it up and now I can start debugging things
<uvos>
are you using ofono to start calls?
<uvos>
obv. the prerequisit for sphone working is ofono working
<uvos>
if ofono works but sphone dosent work plase "killall sphone; sphone -v -v -c dialer-open"
<uvos>
and show the log
<sicelo>
rafael2k: nice to see the icon on a real device :-)
<rafael2k>
ofono scripts, yes
<rafael2k>
in /usr/share/ofono
<rafael2k>
lemme try
<rafael2k>
tks uvos
calx_ has joined #maemo-leste
<uvos>
also some description on what dosent work would also be helpfull ofc
<rafael2k>
Unable to transmit dial number via ofono
<rafael2k>
sphone: comm-ofono: Error: GDBus.Error:org.ofono.Error.NotImplemented: Implementation not provided
<rafael2k>
nothing works
<rafael2k>
; )
<rafael2k>
receiving a call or originating a call
<uvos>
ofono is running, the modem is enabled and onlined?
<rafael2k>
btw, now my head is in "play mode", but I wanna help updating the kernel of pinephone
<rafael2k>
I wanna have my maemo full set before the keyboard arrives home
<rafael2k>
; )
<calx>
Does anybody know whether it's possible to use the vanilla Devuan installer if I've got a PINEPHONE with keyboard, mouse, & ethernet? I can do some development, but I'm a n00b at arm64, having dipped my toes in a long time ago but feeling frustrated failing to remember what I used to know.
<sicelo>
calx: to install Leste? or Devuan?
<calx>
To work towards Leste from a minimal Devuan install.
<uvos>
not sure why you would want to do that
<uvos>
and i dont think there is a devuan image for the pp
<calx>
Because I'm accustomed to working from a fairly minimal Devuan environment.
<uvos>
you would have to use the usual method to create a debian/devuan rootfs
<uvos>
and add some kernel of your choosing
<uvos>
just using some generic installer isent how it works in the arm world because we dont have generic kernels or bootloaders
<rafael2k>
uvos: SMS is working!
<uvos>
btw
<uvos>
you have to install rtcom eventlogger modules
<uvos>
but thats untrelated to the voice call problem
<uvos>
thats pretty wierd
<uvos>
i currently dont get why the interface would not exist on pp
<rafael2k>
btw, I'm using the repository package
<uvos>
dose the pp show more than one modem in ofono
<uvos>
ie list-modems?
<sicelo>
if your ultimate goal is Leste, then just start where Leste for PP is today, and improve. Leste is already as minimal as it gets. No bloat at all. of course if your ultimate goal is devuan .. different story
<freemangordon>
and this is not part of 'hildonizing' GtkRange
<freemangordon>
my bad that I didn;t do a separate commit
<uvos>
freemangordon: if i place a slider wdiget into a pannable area i get different coordinates origin points in gdb for motion events than if i place it into a gtk_scrolled_window
<calx>
Yeah, I imagine I can start with Leste, strip it, and build it back up to get comf with it. The wiki says to format the card as ext4, is that supposed to be raw ext4 or with a MBR or GUID?
<uvos>
freemangordon: disregarding what the reason is for this
<freemangordon>
uvos: could be, but that's not HPA's fault
<uvos>
i dont see how that would not trip up any custom widgets
<uvos>
that use the events
<rafael2k>
same error
<sicelo>
calx: again - what's your end goal? devuan or leste? if leste, how will stripping it help? of course, ultimately it's your choice what you do, but i'm curious nonetheless
<freemangordon>
also, what makes you think HPA miscalculates event coordinates?
<rafael2k>
./dial-number ....
<rafael2k>
dbus.exceptions.DBusException: org.ofono.Error.NotImplemented: Implementation not provided
<uvos>
freemangordon: well if i place the widget into any other container it works fine
<uvos>
and the coordinates are allways seseable and the same
<freemangordon>
and what widget does not work fine if you place it in HPA?
<uvos>
if i place it into a HPA the coordinates are very different (alligned to the hpa instad of the child widget)
<freemangordon>
so what?
<calx>
I'm gonna do leste from the start, the wiki just isn't as explicit as I prefer my directions to be. I had an N900 back in the day... man, those were the days!
<uvos>
well hpa behaves differently than any other container in this case, i only know of the slider that uses these events, but any application that implements a custom widget will trip over this if it uses these evetns
<freemangordon>
no, not really
<calx>
I also haven't used IRC in ages. Thanks for replying to me sicelo
<freemangordon>
slider was calling wrong function because of the way it is implementd
<uvos>
if it expects the hpa to work like any other gtk container
<uvos>
yes really
<freemangordon>
argh
<freemangordon>
look at the commit that breaks it
<rafael2k>
uvos: I'll investigate this ofono issue... strange, and nothing related to sphone
<uvos>
i see and understand that commit
<freemangordon>
it has nothing to do with hildon
<uvos>
but it dosent matter
<freemangordon>
sure it does
<uvos>
no
<freemangordon>
see how button-press-event is handles
<freemangordon>
*handled
<freemangordon>
this is original gtk code
<rafael2k>
good ol' AT commands work like a charm
<rafael2k>
:/
<freemangordon>
the same condition was missing in motion-event code
<freemangordon>
it seems GtkRange uses its own event_window and thus coordinates must be relative to it
<freemangordon>
not to event->window
<calx>
sicelo or whomever, am I supposed to create a disk label of type GPT or MBR, or just format straight to ext4 without a disk label?
<freemangordon>
anyway, if you think there is a bug in HPA, please feel free to open an issue, providing a test case.
<uvos>
freemangordon: right but with the hpa the event is relative to a different window so any widget that expects the event to get like in any other container
<uvos>
now that may be technicly broken
<uvos>
ok
<uvos>
but the fact that it works suggests its gona be used that way in other places too
<uvos>
anyhow its not important
<uvos>
its not like people are implementing gtk2 applications anymore...
<freemangordon>
that one too :)
<freemangordon>
gtk3 supports something like HAP natively, right?
<uvos>
yeah
<freemangordon>
*HPA
<uvos>
any scrolling widget is finger scrollable
<uvos>
hpa is obsolete
<freemangordon>
so we'll drop that anyway when it comes to it
<calx>
This wiki https://leste.maemo.org/PinePhone says "Format the SD card as ext4 using any of your preferred tools." How is a person supposed to pick which way to do it, lol!
<uvos>
yeah
<freemangordon>
uvos: and anyway that frustrating bug is now fixewd
<uvos>
right
<uvos>
thanks
<freemangordon>
np
<freemangordon>
uvos: just one note re HPA and GtkRange: GtkRange receives motion events straight from gdk, hildon has nothing to do with which windows those events come from
<sicelo>
calx: maybe that's outdated. i don't have pp, but there's an image here, http://maedevu.maemo.org/images/pinephone/20210822/ - clearly that one is a matter of using dd, etcher, or whatever similar tool one prefers
<sicelo>
perhaps you can do this, and update the wiki accordingly
<uvos>
freemangordon: yeah i know
<freemangordon>
HPA motion-event callback is not called in case of GtkRange
<uvos>
freemangordon: but the presence of the hpa changes behavior somehow
<freemangordon>
so I would say this is a bug in gtk
<uvos>
freemangordon: very possible yeah
<uvos>
rafael2k: org.ofono.VoiceCallManager.dial
<uvos>
rafael2k: not org.ofono.VoiceCall.dial
<uvos>
sry
<freemangordon>
are you sure GtkRange behaves correctly outside of HPA?
<rafael2k>
voicecalls for the EG25 support seems not there in the shipped version
<Wizzup>
so do we need patched ofono or newer ofono?
<sicelo>
mobian uses modemmanager instead of ofono. anyway, maybe compare what plasma mobile's ofono had ... (they have also switched to MM recently)
<Wizzup>
it's possible most systems do not shit with mainline ofono
<sicelo>
telephony was working fine for plamo with ofono
<uvos>
implementing a mm backend for sphone is really trivial btw
<uvos>
i just lack a device to test it
<uvos>
(ofc we have other stuff that uses ofono)
<rafael2k>
I'll try another distro with ofono to compare
<Wizzup>
maybe just look at the version?
<rafael2k>
easier
<rafael2k>
; )
<sicelo>
yeah, you don't need a whole distro :-p
<sicelo>
plus, they're dwindling
<rafael2k>
lemme see what is inside the mobian I borroed the kernel
<sicelo>
that one won't help you. they were using MM since day 1
<rafael2k>
right
<sicelo>
look at something that used Plasma Mobile, because that was ofono until very recently
<rafael2k>
ok
<uvos>
i dont think anyone uses ofono anymore execpt sfos and us
<sicelo>
just like x11 ... almost no one else uses it (on mobile) anymore. only sxmo did, but they're going wayland too
<rafael2k>
anyone, LTE connection works fine
<rafael2k>
*anyway
<Wizzup>
uvos: sfos is bigger than all others combined I think
<Wizzup>
(just noting)
<rafael2k>
need to fix X11 too.. I'm still with that nasty bug on rendering, but I just use it without accell for some time already... I forget about it
<uvos>
Wizzup: sure but they are soemthing different than the others
<uvos>
they are not really part of mainline linux efforts
<Wizzup>
rafael2k: there are some things to improve it a bit but there are still rendering problems
<uvos>
they are more like android really
<rafael2k>
<- downloading plasma mobile...
<uvos>
sicelo: sure bit with x11 we have a large amount of legacy code we would have to replace
<uvos>
sicelo: with ofono its very little
<uvos>
sicelo: just some icd2 stuff the status icon and sphone really
<uvos>
sicelo: as far as stuff thats currently implemented
<uvos>
sicelo: < 3k lines probubly
<Wizzup>
telepathy-ring
<uvos>
you know what i think about telepathy :P
<uvos>
but yeah
<uvos>
telepathy-ring
<Wizzup>
yes you want to roll your own :p
<rafael2k>
hummm, can not find ofono in plasma image
<rafael2k>
:/
<sicelo>
Wizzup: actually that's an interesting one - i wonder what plamo is doing with telepathy-* now that they've switched. never looked
<sicelo>
rafael2k: afaik there's not really a plasma image ... they're not a distro. you need to use an image of some distro that provided plamo, e.g. pmos (if they still have older images), or maybe manjaro did? anyway, i guess you need to look at code more than running a specific distro. hopefully the code differences should be quickly apparent
<rafael2k>
will compile a package from sid debian dir
<uvos>
you could also try and install the droid4 ofono
<uvos>
its newer i think
<sicelo>
rafael2k: ofono upstream?
<uvos>
and really nothing about it is mapphone specific
<sicelo>
upstream won't help you :-)
xmn has joined #maemo-leste
<rafael2k>
sicelo: sid package
<sicelo>
i doubt that'll help you either ;-)
<rafael2k>
with some tweaks for devuan / maemo
<uvos>
rafael2k: try installing the ofono pacakge from the droid4 leste repo first
<sicelo>
anyway, try it
<rafael2k>
uvos: can be, sure
<uvos>
its just a diffrerent ofono version
<rafael2k>
where can I grab it?
<uvos>
that also has moomdm driver
<uvos>
you can just browse the repo
<uvos>
and grab it
<sicelo>
someone else that uses ofono with pp is nemomobile. may also be helpful to see which ofono they use. i can't recall what features they have working thoug
<calx>
Wizzup, thanks for mentioning arm-sdk. I'll try to remember to look into it the next time I've got a few free cycles, or however the cool kids say it
<sicelo>
Anyway, gn!
<uvos>
sicelo: yes ril is the andorid hal for modems
<uvos>
radio interface layer or so
_inky has joined #maemo-leste
<calx>
sicelo, I've got it up! thanks for your help! Aptitude's up and working and wicd-curses shows connections but doesn't connect, but hey, one out of two ain't bad! Now I just gotta see what mess I can uninstall without breaking everything; probably not much.
<uvos>
we have our won network manager btw
<uvos>
icd2
<uvos>
*own
<uvos>
using wicd in parrallel with icd2 icd2 is not going to be very pretty
<calx>
I much prefer my network manager to not use X11
<uvos>
icd2 dosent use x11
<uvos>
the ui dose sure
<uvos>
but the ui is seperate
<uvos>
ofc
<calx>
Oh, nah? I'll have to read up on it. Thanks for mentioning! :-)
<calx>
gotta go, thanks everybody!
<rafael2k>
right, android shit
<rafael2k>
we need to use the qmi interface
<rafael2k>
there is also a kernel module... it might be there the problem too...
<Wizzup>
did you inspect ofono in debug mode
<_inky>
sxmo has no such issues with gfx as maemo.
<_inky>
may be the different kernel, may be other libraries.
<_inky>
but it has no problems with xorg.
<_inky>
i think just pmos baseline is more up to date.
<Wizzup>
_inky: I upgraded to a newer X and mesa than pmos has
<Wizzup>
and it makes no difference
<Wizzup>
so I don't think that's the case
<uvos>
hildon desktop might be buggy
<uvos>
dosent seam terribly likely since it works on all other drivers we have tried