<freemangordon>
Wizzup: uvos: do you want me to do anything else re PA? shall I add PP scripts in leste-config? what about d4?
Oksanaa has joined #maemo-leste
<rafael2k>
dont forget about pp too!
<rafael2k>
: )
<freemangordon>
"shall I add PP scripts in leste-config?" :p
<freemangordon>
rafael2k: BTW, do you know if there is a way to get a list of all xcb keyboards/variants/etc. Keep in mind 'rules' file does not have all the info
<freemangordon>
so 'symbols' must be somehow parsed
<freemangordon>
so, shall I write my own parser?
<rafael2k>
hey!
<rafael2k>
I was still sleepy
* freemangordon
hands rafael2k some coffee
<rafael2k>
tks! drinking now!
<rafael2k>
looking at setxkbmap and xmodmap
macros__ has joined #maemo-leste
<freemangordon>
setxkbmap is of no help IIUC
<rafael2k>
I used to be good with x keyboard maps... always had trouble with things like ccedil and stuff like that
<freemangordon>
lemme try to explain what I am trying to achieve
<freemangordon>
in "text input" applet there is an option to select the HW keyboard layout
<rafael2k>
right
<rafael2k>
you need model, layout and variant only?
<freemangordon>
I want to fill that list by using the internal keyboard name of the particular device (nokiarx51, droid4, etc)
<freemangordon>
basically, what I need is to have a way to map nokiarx51->(list of possible layout variants)
<freemangordon>
this is present only in nokia_vndr/rx51
<freemangordon>
rx51 is just an example ofc, the same logic shall apply no matter the device
<freemangordon>
XkbRF_Load does good job, more or less, so I have 'rules' file as C data
<freemangordon>
but, I receive there data like ''nokiarx51' 'nokia_vndr/rx-51(common)+nokia_vndr/rx-51(%l%_v)'"
<freemangordon>
and here is where I am stuck
<rafael2k>
I'm looking at /usr/share/X11/xkb to see if I get some idea...
<freemangordon>
it is like spaghetti :)
<rafael2k>
good ol' X
<freemangordon>
do you know what 'nokia_vndr/rx-51(common)+nokia_vndr/rx-51(%l%_v)' is supposed to mean in terms of xcb?
<freemangordon>
like, WTF is %l%_v ?!?
<freemangordon>
and basically, who parses that? server?
<rafael2k>
it should be layout and variant... but no idea who parses that
<rafael2k>
:(
* freemangordon
grep xserver source code for 'xkb_symbols'
<rafael2k>
btw, I dunno why sometimes, after boot, something is correct with modem boot up
<rafael2k>
*is not correct
<rafael2k>
I had to power modem off and on to make it connect to network (using 4G in my case, but it does not matter)
<rafael2k>
this happened today
<rafael2k>
I was in the restaurant, connection to telephony network was not working
<Wizzup>
hmm
<rafael2k>
even tried ofono scripts, not ok
_inky has joined #maemo-leste
<rafael2k>
then just run "eg25 stop", "eg25 start"
<rafael2k>
then made model online with ofono scripts... and all good
<rafael2k>
connected using maemo UI without problem
<Wizzup>
hm, so maybe some racae
<Wizzup>
race*
<rafael2k>
uhum, as realized you was complaining
<Wizzup>
what ui do you use exactly?
<rafael2k>
I dunno, just the default one in maemo
<rafael2k>
are there more than one?
<rafael2k>
connections - and select the telephony provider, which has a different icon than wifi stuff
<Wizzup>
ok
<rafael2k>
but this thing was working fine, never had problem
<Wizzup>
I assume that always fails the first time?
<Wizzup>
hmm
<rafael2k>
lemme test a bit more
<rafael2k>
I'll reboot sometimes
<Wizzup>
well I mean it works for me too, but it by default doesn't wait for the connection to become active
<Wizzup>
so the first activation call always fails
<Wizzup>
next time it doesn't work try /etc/init.d/icd2 restart
<rafael2k>
ok
<rafael2k>
pp especially has big waiting times for modem to boot up
<Wizzup>
mhm
<Wizzup>
linux booting linux :)
<rafael2k>
two linux booting... eheheheh
<rafael2k>
maemo is booting too fast
<rafael2k>
:P
<Wizzup>
we could have the modem init script wait for the modem to boot before it continues
<Wizzup>
but it should not be a problem
<Wizzup>
ofono should just detect modem, and icd2 plugin should pick that up
<tmlind>
Wizzup: on boot, looks like qmi uim-get-pin-status needs to be waited for, then qmi get-msisdn, and even then no operator info is yet seen for a little while so that should be checked too before things are ready
<tmlind>
Wizzup: this with just with the related qmicli dms commands
<rafael2k>
but pp has kill switches for the modem... so better not to wait indefinitelly.
<buZz>
hmmm, you do make me realize how 'empty' that frontpage is
<buZz>
maybe we should get some more images on it
<Wizzup>
tmlind: hm, in ofono to have it detect the sim with pin on boot?
<Wizzup>
buZz: would love to get some people to work on the wiki :)
<buZz>
hmhm
<freemangordon>
rafael2k: seems the parser is in xkbcommon
<rafael2k>
freemangordon: yay!
<tmlind>
Wizzup: yeah looks like the sim is not seen for a while, maybe check with those qmicli commands after boot if that is your issue
<Wizzup>
ok, yeah, I can do that today, thanks for looking into that!
<Wizzup>
brb
<tmlind>
Wizzup: on a better keyboard now, here are the qmicli commands i use, first --dms-uim-get-pin-status, then after that works --dms-get-msisdn, then online the modem
<tmlind>
Wizzup: i've also noticed that even after that if the operator is not seen the modem will not properly work and needs to be re-onlined..
<tmlind>
Wizzup: oh actually i no longer use --dms-get-msisdn, only poll with --dms-uim-get-pin-status until sim is seen. need to figure out some check for when it's ok to online the modem after that
<tmlind>
Wizzup: but anyways, if --nas-get-home-network does not show the operator, the modem is stuck in some unusable state after boot
<tmlind>
and calls won't work probably until the modem is re-onlined or some other init part, don't know for sure
<tmlind>
uvos: so i've confirmed that having the lcd enabled weakens the indoors gnss signal for me, not the slide and not the backlight
<rafael2k>
tks tmlind!!
<tmlind>
rafael2k: does the pp have the same issue onlining the modem?
<rafael2k>
tmlind: I'm not sure, but put it offline and online makes it work after full boot
<rafael2k>
tmlind: so I suspect it could be the issue you mention
<tmlind>
rafael2k: ok maybe check with --nas-get-home-network if you see the operator when it does not work
<rafael2k>
ok tks, will check as soon as I put my daughter to sleep
<tmlind>
ok
<Wizzup>
tmlind: so these commands, do I run then before starting ofono, or?
<rafael2k>
Wizzup: I have a guess that this can be done just before giving the command to online the modem (to ofono already up), but lets wait tmlind...
<tmlind>
Wizzup: yeah so check with --dms-uim-get-pin-status before onlining, then check with --nas-get-home-network if you see the operator, sorry don't know the steps inbetween why --nas-get-home-network does not show operator after boot but then shows when tried again..
<tmlind>
Wizzup: so you could check with just qmicli while you have your gui starting up i think
<tmlind>
then add similar steps to sphone i guess assuming it helps
<_inky>
now works indeed!
<_inky>
it wasn't working for about half an hour i think.
<tmlind>
rafael2k: yeah or just check manually those commands before starting sphone
<tmlind>
so there's probably some qmi status when --nas-get-home-network telling modem is unusable, maybe that clears when the operator is seen later on, don't know. or maybe something needs to be reinitialized to make the modem usable at that point, i'm pretty sure just waiting is not enough at least on d4
<Wizzup>
tmlind: hm, but for ofono not seeing the sim changes, when should I run these commands?
<Wizzup>
assuming you were talking about fixing the ofono plugin to do certain calls upon sim changes
<Wizzup>
I guess the sim kick needs to be extended with qmi calls?
<tmlind>
Wizzup: hmm so what do you have doing the modem qmi calls? sphone or something else?
<Wizzup>
tmlind: so my understanding is that the sim problem is as follows
<Wizzup>
if I have a device where the sim card has a pin, the kernel clearly emits the sim status changes, but ofono doesn't pick them up
<Wizzup>
with is with ofono modem set to powered, but nothing else
<Wizzup>
s/with is/this is/
<Wizzup>
acting on ofono, for example it should go online will make it suddenly realise there -is- in fact a sim
<Wizzup>
but if you don't make the online call, it just thinks there is no sim
<Wizzup>
so the only thing interacting (writing) to ofono is the icd2 plugin that just sets the modem to 'powered'
<Wizzup>
sphone should just listen and act on smses/calls, not so much do anything else
<Wizzup>
icd2 can also set network context to active, but that's all there is
<Wizzup>
normally if modem shows there is a sim with a pin, on startup there will be a dialog to enter pin
<Wizzup>
so that works for me is to wait two minutes after boot, then restart ofono (once or twice, depends), and then it will just recognize that there is a sim
<Wizzup>
then I type startup-pin-query (iirc) and use the dialog to enter the pin
<Wizzup>
and then things kind of work as normal
<Wizzup>
but the sim notification clearly passes kernel messages with n_gsm debug
<tmlind>
yeah so could be that ofono has an issue noticing the state. but it might also be that the qmi client needs to check certain states are reached before trying to continue
<Wizzup>
right
<tmlind>
so trying to figure out why modem does not work right after boot, first sim is not seen
<tmlind>
then when sim is seen, home network is not yet seen
<tmlind>
once both are seen calls work
<Wizzup>
aha
<tmlind>
so it's like there's some inbetween states with no notifications or something
<tmlind>
so if icd2 is doing the qmi calls, there might be some status checks missing inbetween like "is the sim available" before trying to set the pin
<tmlind>
and "is the network seen" before trying to make calls
<Wizzup>
no maemo sw should do qmi calls specifically, all goes through ofono
<tmlind>
ok
<Wizzup>
(n900 for example doesn't do qmi, so we target ofono as abstraction)
<tmlind>
so maybe ofono is missing the status checks then
<Wizzup>
mhm
<tmlind>
this issue exists with just using qmicli to enable the modem too
<tmlind>
it's not enough to set pin, online and make calls :)
<Wizzup>
(plus me forward porting your work to 1.34)
<tmlind>
yeah well so when you start initially and your calls don't work, check the status with qmicli over ssh to see if you see the sim and the operator
<tmlind>
that should give some more clues
<Wizzup>
ok
<tmlind>
if it's the same problem i'm seeing
<Wizzup>
yeah I'll reboot my d4 momentarily and check over ssh
<tmlind>
Wizzup: ok so if you type the two qmicli commands during the first two minutes after start-up without restarting ofono we might get some more info
<Wizzup>
that is --dms-uim-get-pin-status ?
<Wizzup>
and later (after online) --nas-get-home-network ?
<tmlind>
yup
<Wizzup>
ok
<tmlind>
then qmicli might need that option to make reads and writes to work..
<Wizzup>
that is: printf "AT+CFUN=1\r" > /dev/gsmtty1
<rafael2k>
I prefer to stick with qmi interaction, as it is more complete and verbose
<rafael2k>
but in the end, for the baseband, it ends up in the "same place"...
<tmlind>
Wizzup: you need the packet id, try printf 'U1234%s\r' AT+CFUN=1 > /dev/gsmtty1
<Wizzup>
ok, that worked
<Wizzup>
once I do that the qmicli get home network worked
<Wizzup>
ofono again doesn't it see it though
<Wizzup>
so I think I am seeing different behaviour potentially, but then again I do have ofono running, and you might not, in your tests?
<tmlind>
well the issue i see is that there's a long delay between AT+CFUN=1 and --nas-get-home-network showing the operator, and modem won't work until something is reinitialized, only on the first modem start-up after booting
<rafael2k>
Wizzup: which device / modem are you carrying these tests?
<tmlind>
yeah i just use qmicli and at commands.. been meaning to update for years now..
<Wizzup>
rafael2k: droid 4
<Wizzup>
brb
<rafael2k>
ok
<rafael2k>
I wonder if we are doing the right thing calling /usr/bin/pinephone_setup-modem from udev and eg25 at init stage...
<rafael2k>
in my head, we could just do all the setup from udev hook
<rafael2k>
and make ofono wait the device target to be ready
xmn has joined #maemo-leste
<rafael2k>
(or not, I mean, ofono can read new devices dynamically)
<rafael2k>
as indeed, modem can be disabled by kill switches... so ofono should not even depend on modem bring up...
rafael2k has quit [Ping timeout: 250 seconds]
<humpelstilzchen[>
I'm currently trying to port easylist (https://talk.maemo.org/showthread.php?t=62280) to qt5. Problem is, that some dialogs QMessageBox do not appear. Known problem?
rafael2k has joined #maemo-leste
<rafael2k>
adding a 2s sleep in the end of start() made things stable again