lel | IMbackK opened a pull request: https://github.com/maemo-leste/leste-config/pull/25 (add quirks-mapphone to mapphone mce config) | 12:11 |
---|---|---|
Wizzup | what does this do? | 12:20 |
uvos | do the SCRN= thing with the display state | 12:23 |
uvos | and kick ttyUSB3/4 to avoid the pm bug | 12:23 |
Wizzup | aha | 12:23 |
uvos | essentaly manage the mapphone modem wierdness | 12:24 |
Wizzup | uvos: I see you build mce for -devel | 13:03 |
uvos | yes | 13:04 |
Wizzup | for the quircks, we have other scripts in place that kick the modem, don't we? | 13:04 |
Wizzup | would we not need to remove those? | 13:04 |
uvos | no | 13:04 |
uvos | was never merged | 13:04 |
Wizzup | so just my devices have that? | 13:04 |
Wizzup | based on the dbus-scripts | 13:04 |
uvos | https://github.com/maemo-leste/droid4-pm/pull/2 | 13:04 |
uvos | this was never merged | 13:04 |
Wizzup | hm this is for touchscreen | 13:05 |
Wizzup | I meant the scripts to kick the modem | 13:05 |
Wizzup | I thought we had those with dbus-scripts | 13:05 |
uvos | no its also modem | 13:05 |
uvos | printf 'U1234AT+SCRN=1\r' > /dev/gsmtty1 | 13:05 |
uvos | this is what mce now dose | 13:05 |
uvos | regarding head /dev/ttyUSBx that was never added or proposed anywhere afaik | 13:05 |
Wizzup | ok | 13:09 |
uvos | dbus-scripts in general should be demoted to extras now btw | 13:09 |
lel | IMbackK closed a pull request: https://github.com/maemo-leste/droid4-pm/pull/2 (Idle the ts while the display is off but the device is not locked) | 13:13 |
lel | MerlijnWajer renamed a repository: https://github.com/maemo-leste/libicd-tor | 19:44 |
Wizzup | uvos: tmlind: might be coincidence but I was waiting for quite some time for ofono to acknowledge the data connection was activated, and when I sent myself a sms it was activated as soon as the sms was received | 19:56 |
Wizzup | uvos: I upgraded to the latest mce, overwrite the config file, and my display no longer blanks on double power key tab | 20:20 |
Wizzup | s/tab/tap/ | 20:20 |
uvos | but it blanks otherwise? | 20:21 |
uvos | ie power menu option | 20:21 |
Wizzup | no | 20:22 |
Wizzup | I see the power menu | 20:22 |
uvos | ok | 20:22 |
Wizzup | but the display never turns off | 20:22 |
uvos | please stop mce via the init script | 20:22 |
uvos | and run "mce --verbose --verbose" | 20:22 |
uvos | in a sudo su - env | 20:22 |
uvos | with DSIPLAY set to :0 | 20:23 |
Wizzup | did you change anything recently? | 20:23 |
Wizzup | I thought it was just the quircks thing | 20:23 |
uvos | and give me the log of the startup as well as the power button press | 20:23 |
uvos | nothing that should have any impact on this | 20:23 |
uvos | i also added a new module to eventually replace ke-recv | 20:24 |
uvos | but its not loaded | 20:24 |
Wizzup | ke-recv has a lot of scripts, but nevermind that for now | 20:24 |
uvos | sure | 20:24 |
uvos | im just goint to fix the stuff in ke-recv that dosent work (memory interface kbd slide needing gconf etc) | 20:25 |
uvos | by implmenting that stuff in mce | 20:25 |
Wizzup | https://wizzup.org/log.txt | 20:25 |
Wizzup | ke-recv as in sd card mounting, etc | 20:25 |
uvos | no | 20:25 |
uvos | not that | 20:25 |
uvos | just the ke-recv deamon | 20:25 |
uvos | not all the other programs in the repo | 20:25 |
Wizzup | k | 20:25 |
uvos | (altho some of those need revisiting/ ellimination) | 20:25 |
Wizzup | ke-recv has some dbus interface that is used though, so that'll need care | 20:26 |
uvos | the memory interface yeah | 20:26 |
uvos | also usb | 20:26 |
uvos | sfos implmented those into mce, im just following here | 20:27 |
Wizzup | I will power off my droid until it can lock for now, I assume you can also test on your d4? | 20:27 |
uvos | it works on mine which is wierd | 20:27 |
uvos | anyhow let me read the log | 20:27 |
Wizzup | I don't see any errors there | 20:27 |
Wizzup | is it your maemo d4, or your mixed one :) | 20:27 |
uvos | mameo | 20:27 |
Wizzup | the only addition to 10-maemo.ini seems to be state-dbus | 20:28 |
uvos | mce: Failed to load module: battery-upower; skipping <- thats wierd | 20:28 |
Wizzup | I just accepted the package maintainer version | 20:28 |
uvos | (but would not cause this failure) | 20:28 |
uvos | ok the log dosent appear to show anything ammis | 20:31 |
uvos | ok the log dosent appear to show anything ammiss | 20:31 |
uvos | let me delete 90-user.ini and see if the default work | 20:31 |
Wizzup | so what I did was apt upgrade, and said 'Y' to overriding the config with the maintainer config | 20:31 |
Wizzup | my 99-user.ini is only lm3532 configured lights | 20:31 |
uvos | ok yeah there is something ammis with lock-tklock | 20:35 |
uvos | oh it missing | 20:41 |
uvos | wtf | 20:41 |
uvos | mce: Failed to load module: lock-tklock; skipping | 20:42 |
uvos | or rather it dosent link | 20:42 |
uvos | hmm | 20:42 |
uvos | we are missing a symbol: has_flicker_key | 20:45 |
uvos | Wizzup: have a n900 running? | 20:48 |
Wizzup | not next to me, but can in a few hours | 20:48 |
kona | i have one | 20:48 |
uvos | kona: great | 20:48 |
kona | it's up to date according to apt update && apt upgrade | 20:48 |
uvos | kona: ok 1 sec | 20:48 |
uvos | this path dosent exist right: /sys/devices/platform/gpio-switch/kb_lock/state | 20:49 |
uvos | kona: please check, but it should not | 20:49 |
uvos | kona: gpio-switch was renamed gpio_keys in mainline afaik | 20:49 |
kona | ls: cannot access '/sys/devices/platform/gpio-switch/kb_lock/state': No such file or directory | 20:50 |
uvos | thx | 20:50 |
kona | user@devuan-n900:~$ find /sys -name gpio-keys | 20:51 |
kona | /sys/bus/platform/drivers/gpio-keys | 20:51 |
uvos | Wizzup: ok its fixed | 20:54 |
uvos | let me rebuild | 20:54 |
Wizzup | uvos: what was the problem? | 21:07 |
uvos | i removed has_flicker_key in a different module becasue it gets set based on if /sys/devices/platform/gpio-switch/kb_lock/state exists (which is only the case on the n900 vendor kernel) | 21:09 |
uvos | but tklock has a nasty habbit of just externing global variables from random other modules | 21:09 |
Wizzup | aha | 21:09 |
uvos | so it wouldent link | 21:09 |
uvos | into mce when the module loaded | 21:09 |
uvos | we should have some automated testing that checks if all the modules load i think | 21:09 |
Wizzup | is it not possible to get a link error at build time? | 21:10 |
uvos | no because its extern to a symbol in a different module | 21:10 |
uvos | and since we build the modules seperatly they dont get linked at compile time | 21:10 |
uvos | which asks a interesting question apearantly systemui wants to know if has_flicker_key is true (it gets this via a dbus interface) | 21:17 |
uvos | not sure what the flicker key is | 21:17 |
uvos | but we have been sending systemui false regardless of if the key is present or not | 21:18 |
uvos | tklock dosent seam to change its behavior at all regardless of true or false here | 21:30 |
uvos | (tklock in systemui that is) | 21:30 |
uvos | Wizzup: anyhow im building a mce version that restors the previous behavor now | 21:32 |
Wizzup | do you mean without linking problems? | 21:34 |
uvos | yeah that and allways sends false (even on n900 where that is wrong) | 21:34 |
uvos | https://github.com/maemo-leste/osso-systemui-tklock/blob/12d41017242b9c3ddcf1ba6b1dfb1e5dcc37bcf6/osso-systemui-tklock.c#L209 | 21:39 |
uvos | ok dosent matter | 21:40 |
uvos | systemui-tklock dosent care about the flicker_key in the slightest | 21:40 |
uvos | and since the only thing lock-tklock dose with flicker_key is send it to systemui via SYSTEMUI_TKLOCK_OPEN_REQ | 21:40 |
uvos | its totaly vestigial | 21:41 |
uvos | thats half of lock-tklock in a nutshell :P | 21:41 |
Wizzup | upgrading now | 21:51 |
Wizzup | it's nice that the dsmeutil bug is fixed | 21:51 |
Wizzup | uvos: why does mce no longer get restarted post upgrade? | 21:52 |
Wizzup | that's weird | 21:52 |
Wizzup | (tklock works again) | 21:52 |
uvos | Wizzup: i just upgraded from repo | 21:52 |
uvos | and mce got restarted here | 21:52 |
uvos | you where running it in a shell as mce --verbose --verbose no? | 21:53 |
uvos | then ofc it wont get restarted | 21:53 |
uvos | since its not under conroll of openrc | 21:53 |
Wizzup | nah I rebooted the device | 21:54 |
Wizzup | I am sure it didn't restart because tklock didn't work until I restarted it via /etc/init.d/ | 21:54 |
uvos | did apt complain about something? | 21:55 |
Wizzup | no | 21:55 |
uvos | wierd | 21:55 |
Wizzup | yup | 21:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!