norayr | leste port of mstardict done: https://github.com/norayr/mstardict/commit/ca99d9d803dbf39ca2aee8f0d305a0e33ddc97b2 | 00:08 |
---|---|---|
norayr | uvos, wow great. how can i make sure the screen is the only one? if i do xrandr -q i probably will see both screens. | 00:09 |
norayr | should i edit xorg.conf? | 00:09 |
norayr | ah, maybe there is no default xorg.conf, and it is autogenerated, and i should create the default? | 00:09 |
uvos | norayr: sure creating a xorg.conf with a static layout should work fine | 00:54 |
norayr | good, i'll try. it would be easier if i could ssh to device and start or stop xorg to test my xorg.conf changes. | 01:01 |
norayr | but i guess it'll only connect to the network if it starts hildon | 01:01 |
norayr | Wizzup: i think bot (lel?) didn't notice this https://github.com/maemo-leste-extras/bugtracker/issues/32 | 02:25 |
Oksanaa | MStarDict was great, back when I used it on Maemo 5 Fremantle :-) Thank you! | 08:24 |
* Oksanaa wonders if any news releases are planned for https://maemo-leste.github.io/ - the latest one was April 2022?.. | 08:25 | |
freemangordon | norayr: what? https://github.com/norayr/mstardict/commit/ca99d9d803dbf39ca2aee8f0d305a0e33ddc97b2#diff-889c5495b68d2a0c0d1f238818716a71939918499efbc0fc6d2994319624fc67R25 | 08:27 |
Oksanaa | I am very, very tired of the data fragmentation. Between (several devices, actually) Nokia N900, Fxtec Pro1, Nokia E71, and for-the-sake-of-taking-photographs Nokia 1.3 and Nokia N95... I have no idea how I will actually compile, in the distant future, a continuous history of SMS texts. Or a continuous photo album. Or notes. Or IRC history into a single IRC client. | 08:29 |
freemangordon | norayr: https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html | 08:34 |
Oksanaa | And I have no idea what device I want to use in the future. Fxtec Pro1? Perhaps, but I do not trust Sailfish OS to not brick it again - is there Maemo Leste image for it? Motorola Droid 4? Perhaps, but I do not have one, yet. Nokia N950? Perhaps, but it would need tricky soldering work to get SIM card slot working. Nokia N900? Perhaps, but it would need a repair of the charging port... | 08:34 |
freemangordon | norayr: or simply add AM_GNU_GETTEXT_VERSION to configure.ac, IIUC | 08:35 |
Oksanaa | At this rate, I would even be interested in a Maemo Leste image for Dragonbox Pyra: at least, this device (pre-ordered, not arrived yet) is not in need of repairs or data back-up. Granted, it's standard edition, not mobile edition, so it does not have cellular connectivity... Perhaps, I will (pre-)order another one, with cellular connectivity... | 08:39 |
norayr | freemangordon: i think AM_GNU_GETTEXT_VERSION is in configure.ac, i checked. | 09:34 |
norayr | but i'll check again | 09:34 |
norayr | and yes, i wanted to say, i have very limited knowledge with autotools etc, so it would be great if you comment on my solutions | 09:35 |
norayr | Oksanaa: i think last images were build in september. | 09:35 |
tmlind | freemangordon: not sure if increasing the timeouts helps. maybe the issue is that n_gsm is unable to connect if no response initially? | 09:41 |
tmlind | Wizzup, uvos: so i took a look at the tc358765 dsi bridge i2c transfers issues on mz617.. the chip seems super buggy for i2c | 09:43 |
tmlind | heh, so for register writes, writes go to address + 1 instead of address :) | 09:43 |
tmlind | and after a write, a short timeout is needed or else any following read or write will fail | 09:43 |
tmlind | of course it could be some i2c pull-up issue.. but lm75 on the same i2c bus works just fine. also tried configuring the bus at 400khz | 09:44 |
tmlind | the kernel tc358764 driver uses mipi_dsi reads and writes, and looks like the android driver for tc358765 only used i2c for dumping out the regs for debugging if i read the right code in the v3.0.8 tree.. | 09:45 |
tmlind | i guess i'll try to get the mipi_dsi reads and writes working too, then we can make sure i2c and mipi_dsi both read and write the same registers with the same values.. | 09:46 |
uvos__ | tmlind: thats wierd, might it also just be a special made to order motorola variant of the chip with one extra register that moves all the subisquent addresses +1? | 09:48 |
uvos__ | so if you hack the driver to just add 1 to the address on reads/writes dose it work? | 09:48 |
tmlind | uvos__: no.. i found this out by reading and writing to the early regs and looking the results with i2cdump | 09:48 |
uvos__ | ok | 09:49 |
tmlind | uvos__: any idea if the v3.0.8 kernel panel-mapphone-d2l.c is the one in use? | 09:49 |
uvos__ | i need to take apart my mz617 and charge it | 09:49 |
tmlind | heh | 09:50 |
uvos__ | tmlind: no but should be easy to check | 09:50 |
tmlind | looks like the tc358764 drivers in mainline kernel is finally fixed for the bridge api with some tested-by from the chromebook folks | 09:50 |
uvos__ | :) | 09:51 |
tmlind | i guess i'll try to get that to work, then 765 presumably just has dual lane support compared to 764.. | 09:51 |
uvos__ | would be very neat :) | 09:53 |
tmlind | so the i2ctransfer command i used for debugging was from: https://linuxhint.com/i2c-linux-utilities/ | 09:54 |
Wizzup | tmlind: heh @ register write offset. it would be super awesome if it can be mdae to work :) | 09:55 |
tmlind | something along the lines of this to read a reg: i2ctransfer -f -y 1 w2@0x50 0x05 0x80 r4 to read idreg, forgot which way around the 0x0580 address offset had to be specified | 09:55 |
tmlind | did not get that to work with android btw for dumping regs, android bus is 1 like above mainline 0 | 09:56 |
tmlind | but would be nice to have a register dump of the android regs naturally somehow | 09:57 |
tmlind | also with i2ctools, writes work along the examples on that page, but the address needs to be addr - 1, and sleep 0.1 is needed before any other transfers.. | 09:58 |
tmlind | looks like reading the idreg just returns the value at 0x80, which can be written directly.. | 09:59 |
tmlind | while writing to idreg won't work | 09:59 |
tmlind | i tried i2ctransfer from busybox on android btw, maybe it's buggy | 10:00 |
uvos__ | tmlind: might make sense to use androids own i2ctools | 10:39 |
uvos__ | use/try | 10:39 |
uvos__ | source is in the android tree ususally they are not installed on images unless you do a debug bild | 10:40 |
uvos__ | build | 10:40 |
freemangordon | tmlind: since the increase, I saw no failures in registrering audio interface | 10:41 |
freemangordon | also, it does not make sense not me _gsm to wait 8 seconds for command being send but audio driver to wait 1 second for response | 10:42 |
freemangordon | *does not make sense to me n_gsm | 10:43 |
tmlind | freemangordon: ok great if it helps :) | 10:46 |
freemangordon | do you plan to send tose patches for upstreaming soon? | 11:05 |
freemangordon | *those | 11:05 |
tmlind | me? which patches? serdev-gsm? | 11:06 |
* tmlind too many half done patches | 11:07 | |
tmlind | in case you're asking about serdev-gsm, those should be updated to use serdev read/write also for the client drivers | 11:09 |
tmlind | on a train again, bbl | 11:10 |
freemangordon | tmlind: yes, serdev-ngsm (and motmdm audio/gsm friends) | 12:08 |
Guest224 | Oksanaa: I saw your Maemo device thinking thru irclog...new Pinephone (not pro) convergence with keyboard (https://pine64.com/product/pinephone-beta-edition-with-convergence-package/ with https://pine64.com/product/pinephone-pinephone-pro-keyboard-case/) can be one option too. Easiest install just put Maemo image to SD card and restart. But anyway | 13:55 |
Guest224 | N900 and Droid 4 has some good points too. It is also question what physical phone size you want. | 13:55 |
Guest224 | -> I continue lurking thru irclog. | 14:05 |
rafael2k | Wizzup: I updated the PR with the kernel package version bump: https://github.com/maemo-leste/pine64-kernel/pull/8 | 16:20 |
Wizzup | ok, will handle today | 16:26 |
freemangordon | tmlind: also, you said we shall add some CIEV handler, but I am not sure I understand what you mean, given https://github.com/maemo-leste-upstream-forks/ofono/blob/maemo-ofono/drivers/motorolamodem/voicecall.c#L923 | 17:21 |
freemangordon | or do you mean we shall handle CIEV also in netreg? | 17:22 |
tmlind | freemangordon: oh maybe we have it already then, i guess that already covers netreg too for kicking the usb qmi modem | 17:25 |
tmlind | freemangordon: assuming they are on the same dlci | 17:26 |
tmlind | hmm maybe ciev_notify() should just kick the qmi usb modem, maybe nothing else is really needed | 17:27 |
freemangordon | mhm | 17:27 |
tmlind | could be some generic cive handler, not limited to voicecall.c | 17:28 |
freemangordon | in motmdm? | 17:28 |
tmlind | yeah | 17:29 |
freemangordon | motmdm.c | 17:29 |
tmlind | yup | 17:29 |
tmlind | then additionally voicecall.c can do what it needs to do with CIEV if anything | 17:29 |
freemangordon | shall I add such handler? | 17:32 |
freemangordon | hmm, why mot_qmi_trigger_events uses WMS no matter what has changed? | 17:35 |
freemangordon | like, how is MSIM or CREG event related to WMS? | 17:35 |
freemangordon | aren't those supposed to kick DMS, not WMS? | 17:36 |
freemangordon | or it is just a fake call to wake-up USB? | 17:36 |
tmlind | well anything that gets the usb qmimodem to check it's status should do, maybe there's a better way | 17:37 |
freemangordon | ok | 17:37 |
freemangordon | so, shall I add CIEV handler in motmdm.c? | 17:37 |
tmlind | all the modem notifications only seem to come to the n_gsm interface, usb won't notice anything and i was unable to reconfigure the usb modem when i tired | 17:38 |
freemangordon | ah, I see | 17:38 |
tmlind | yeah it's worth trying, it could simplify things | 17:38 |
tmlind | it's like the usb modem settings are read-only | 17:38 |
freemangordon | ok, will do | 17:38 |
tmlind | cool, look forward hearing what happens :) | 17:39 |
freemangordon | and what we expect to happen differently? | 17:39 |
freemangordon | like, what it the bug we try to fix? :) | 17:39 |
freemangordon | *is the | 17:39 |
tmlind | usb modem might start doing things on the notifications like it should | 17:39 |
freemangordon | what things, in particular? | 17:40 |
tmlind | like network status change, sim insert, data connected.. | 17:40 |
freemangordon | iiuc it already does | 17:40 |
tmlind | well maybe yeah | 17:40 |
freemangordon | but ok, one more cb should not hurt | 17:41 |
tmlind | but does ciev_notify() always call mot_qmi_trigger_events()? | 17:41 |
freemangordon | no | 17:41 |
tmlind | ok then it's worth trying and see what happens :) | 17:42 |
tmlind | also WAKEUP should do that if we don't have a handler for it | 17:43 |
freemangordon | I guess I shall enable n_gsm debug to see all the unsol messages that come | 17:43 |
tmlind | yeah or do sudo dmesg -w | 17:44 |
tmlind | after loading with modprobe n_gsm debug=0xff | 17:44 |
freemangordon | mhm | 17:44 |
tmlind | right that's what you meant too, i misread enabling ofono debug.. | 17:45 |
freemangordon | ok, going to do it | 17:46 |
Wizzup | 17:39 < freemangordon> like, what it the bug we try to fix? :) | 17:46 |
Wizzup | context activation often not workingf | 17:46 |
freemangordon | umm... is that still there after latest fixes? | 17:46 |
Wizzup | yes | 17:46 |
Wizzup | on my d4 I often still have to send a sms to get it to activate | 17:46 |
Wizzup | at least twice today | 17:46 |
Wizzup | maybe it's something else that's odd | 17:47 |
Wizzup | or rather: I have to send a sms for ofono to realise it's activated | 17:47 |
freemangordon | hmm... | 17:47 |
freemangordon | ok | 17:47 |
freemangordon | do you have n_gsm traces? | 17:47 |
tmlind | from android you mean? | 17:47 |
freemangordon | no, from leste | 17:48 |
tmlind | no don't have any | 17:48 |
freemangordon | when ctx activation fails | 17:48 |
Wizzup | no, but I can enable it again | 17:48 |
freemangordon | I think it will be helpful to see if there is anything coming from the modem at all | 17:48 |
Wizzup | there is, CIEV | 17:50 |
Wizzup | brb | 17:50 |
freemangordon | ok | 17:50 |
tmlind | ok. hmm so what is the context activation event? | 17:50 |
Wizzup | there are two that I saw | 17:51 |
freemangordon | ugh, my d4 just hanged :( | 17:51 |
Wizzup | one regarding radio tech and ciev | 17:51 |
tmlind | but is it for the same operator? | 17:51 |
tmlind | i mostly suffer from lost network connectivity not being notified and i have to manually reconnect to get pm working again.. | 17:52 |
tmlind | well there is some CIEV event for that | 17:52 |
tmlind | again | 17:52 |
tmlind | bbl | 17:55 |
Wizzup | are you asking if I see the problems only on specific operators? | 17:57 |
tmlind | just wondering what all is considered a context activation event | 18:09 |
Wizzup | by modem (in at), or by ofono, or conceptually? | 18:29 |
freemangordon | tmlind: I will intercept ~+WAKEUP as well | 18:36 |
freemangordon | Wizzup: tmlind: I suspect RSSI reported values are not in % | 18:50 |
Wizzup | Ah | 18:53 |
Wizzup | possible | 18:53 |
freemangordon | onm android it reports 15-18 and UI displays full strangth | 18:55 |
freemangordon | *strength | 18:55 |
Wizzup | right | 19:03 |
freemangordon | Network 'umts': '-78 dBm' | 19:44 |
freemangordon | this is for RSSI 16 | 19:44 |
freemangordon | https://pastebin.com/jwfNYBkB | 20:14 |
Wizzup | is this our ofono code, or android | 20:14 |
freemangordon | RSSI vs qmicli --nas-get-signal-strength -d /dev/cdc-wdm0 RSSI dBm | 20:15 |
Wizzup | ah | 20:15 |
freemangordon | f(x) = -1.1581501340482572e+002 * x^0 | 20:15 |
freemangordon | + 2.2017426273458440e+000 * x^1 | 20:15 |
freemangordon | 1st order polynomial approximation | 20:15 |
freemangordon | -115 + 2x to convert RSSI to dBm | 20:16 |
freemangordon | and then we'll have to convert to percent | 20:16 |
freemangordon | but that'd be easy | 20:16 |
Wizzup | right | 20:30 |
norayr | Wizzup, would it be convenient to create a repo for mstardict? | 21:51 |
Wizzup | norayr: pls open an issue and I will tomorrow | 23:14 |
freemangordon | hmm. seems this is our table https://m2msupport.net/m2msupport/signal-quality/ | 23:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!