uvos | freemangordon: not mutch i can do about that unless you have a way to repo | 00:11 |
---|---|---|
uvos | i know the tklock code is very racy | 00:11 |
uvos | it makes assumptions about the dbus bus that are not really valid | 00:11 |
freemangordon | uvos: you mean "mce tklock module" I assume | 00:11 |
uvos | well both | 00:11 |
uvos | both sides | 00:11 |
freemangordon | well, see the pastebin | 00:12 |
uvos | i see it | 00:12 |
uvos | but there is state syncorisation between mce and tklock | 00:12 |
uvos | and this state syncronisation makes assumptions about timeing gurantees dbus dose not make | 00:12 |
uvos | im not shure how it could end up in a loop but it is racy | 00:12 |
freemangordon | it is definitely mce that went nuts. I understand that we can;t do much without detailed mce logs | 00:13 |
uvos | it could also be soemthing else entirely ofc | 00:13 |
freemangordon | mhm | 00:13 |
uvos | Wizzup: freemangordon: with regards to charge mode | 00:13 |
uvos | mce is not involved at all | 00:13 |
uvos | and yes it dosent power off the display | 00:13 |
freemangordon | uvos: shall I enable verbose mce logs in init script? | 00:14 |
freemangordon | so, hopefully next time when this happens we will have more info | 00:14 |
uvos | freemangordon: sure if you have resonable grounds that you can trigger this again | 00:14 |
uvos | i have trouble getting sdl behave it registers drm master | 00:15 |
uvos | but you cant get the cookie out of std | 00:15 |
uvos | sdl | 00:15 |
uvos | so it cant turn of the display atm | 00:15 |
freemangordon | well, if I know how to trigger it, I will have provided those logs already :) | 00:15 |
freemangordon | this happens once in a month or so | 00:15 |
freemangordon | (with my usage ofc) | 00:15 |
freemangordon | oh, which reminds me that Wizzup promised to pull latest sdl. | 00:16 |
uvos | when it happens also try and check mces inputs | 00:16 |
freemangordon | umm, not sure I understand what you mean by "mce inputs" | 00:16 |
freemangordon | attach gdb or what? | 00:16 |
uvos | no check various, evdev and iio-sensor proxy | 00:17 |
freemangordon | ah | 00:17 |
uvos | either of those missbhavig could also cause it | 00:17 |
freemangordon | yeah | 00:17 |
freemangordon | but I guess verbose logs will give info about that too | 00:17 |
uvos | partially | 00:17 |
freemangordon | and give the uSD card I use is 64GiB, I think as a first step I shall enable them | 00:18 |
freemangordon | *given | 00:18 |
uvos | mce verbose log is farily quiet really | 00:18 |
freemangordon | but shall give us some clue about what happens | 00:19 |
uvos | please not that it is a keylogger | 00:19 |
uvos | *note | 00:19 |
uvos | when sharing logs | 00:19 |
freemangordon | this is a dev device only | 00:19 |
freemangordon | not to say I am the only one with access to it | 00:19 |
freemangordon | but yeah, thanks | 00:19 |
freemangordon | I think I won;t share the whole logs anyway | 00:20 |
freemangordon | TBH I don;t think this is related to inputs | 00:20 |
freemangordon | it seems like auto-lock triggers in 3-5 seconds and touching the screen does not reset the timer | 00:21 |
freemangordon | but it undims the screen | 00:21 |
freemangordon | anyway, no enough info | 00:22 |
freemangordon | uvos: BTW, I fixed stacked windows bug on 64 bits | 00:24 |
uvos | great | 00:29 |
uvos | its pretty buggy on 32bits too tho | 00:29 |
uvos | obv other bugs | 00:29 |
freemangordon | hmm, what bugs do you mean? | 00:30 |
uvos | well theres the qt applications that dont stack after the first window creation | 00:30 |
freemangordon | ah, but this is something in qt code I would say | 00:31 |
uvos | and theres a wierd bug where sometimes the back button will return to a totaly unrelated window from a differents applications stack | 00:31 |
freemangordon | not in MB | 00:31 |
freemangordon | uvos: this is on 64bits I think | 00:31 |
freemangordon | and this is what I fixed | 00:31 |
uvos | i can make the latter happen by messing around with sphone and modest on d4 | 00:31 |
uvos | for a while | 00:31 |
uvos | its some kind of race with window creation | 00:32 |
freemangordon | hmm | 00:32 |
uvos | i can also make it happen with the phone app and modest on fremantle | 00:32 |
uvos | so its a legacy bug | 00:32 |
freemangordon | ok, if you have a way to trigger, please share, I can have a look at it | 00:32 |
uvos | not realiably | 00:32 |
freemangordon | I see | 00:32 |
uvos | its somehow a race with when the windows are created | 00:32 |
uvos | ie try and create windows (via ssh or applicaion that take a while to load) while also creating another window | 00:33 |
freemangordon | maybe compile MB/h-d with debug traces enabled and try to rtrigger | 00:33 |
uvos | yeah | 00:33 |
freemangordon | MB provides really verbose logs of what happens | 00:34 |
freemangordon | is it normal that I see "inactivity: device inactivity timeout 30" twice in a row? | 00:34 |
uvos | yeah | 00:34 |
freemangordon | ok | 00:34 |
uvos | depends on where the input is attached | 00:35 |
uvos | also for ts on d4 is normal again | 00:35 |
uvos | because it reads the ts twice | 00:35 |
uvos | because d4 has 2 ts devices | 00:35 |
uvos | thats sortof a bug (ie mce should check with udev if the device is disabled) | 00:35 |
uvos | but its without consiquence | 00:36 |
freemangordon | anyway, mce verbose logs are now enabled, will let you know if there the bug reappears | 00:36 |
freemangordon | zzz | 00:40 |
sicelo | If anyone here has a Leste N900 handy, please tell me how the RGB led is named in sysfs. | 10:57 |
macros_ | is it anyone of these? | 11:07 |
macros_ | find /sys/ -name led 2>/dev/null | 11:07 |
macros_ | /sys/devices/platform/gpio_keys/input/input3/capabilities/led | 11:07 |
macros_ | /sys/devices/platform/n900-audio/sound/card0/input4/capabilities/led | 11:07 |
macros_ | /sys/devices/platform/68000000.ocp/48098000.spi/spi_master/spi0/spi0.0/input/input2/capabilities/led | 11:07 |
macros_ | /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:pwrbutton/input/input1/capabilities/led | 11:07 |
macros_ | /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:keypad/input/input0/capabilities/led | 11:07 |
humpelstilzchen[ | maybe search for brightness? | 11:09 |
macros_ | Here is everything containing LED or brightness https://pastebin.com/6xwg4ThA | 11:15 |
macros_ | It seems to be under /sys/firmware/devicetree/base/ocp@68000000/i2c@48072000/lp5523@32/ as I have entries /sys/firmware/devicetree/base/ocp@68000000/i2c@48072000/lp5523@32/led@{number from 0-8}/color | 11:19 |
macros_ | LEDs 4 to 6 under that path are for status, i suppose for the three colors. | 11:25 |
macros_ | https://pastebin.com/qMwiWEjU for details | 11:29 |
sicelo | This is leste? /sys/class/leds/ | 11:29 |
macros_ | Yes this is Leste, image from February I think | 11:30 |
macros_ | debug::sleep lp5523:b lp5523:g lp5523:kb1 lp5523:kb2 lp5523:kb3 lp5523:kb4 lp5523:kb5 lp5523:kb6 lp5523:r | 11:31 |
sicelo | tyvm | 11:32 |
freemangordon | Wizzup: sms seem to work in telepathy OOTB (empathy) | 17:08 |
freemangordon | I think we shall make conversations app a telepathy chat/sms client | 17:08 |
freemangordon | what the? empathy wants GLX? | 17:14 |
Wizzup | freemangordon: it already is | 17:17 |
freemangordon | really? that's great! | 17:17 |
freemangordon | so, basically we need accounts control UI and we can retire :D | 17:18 |
freemangordon | Wizzup: is that in repos already? | 17:20 |
freemangordon | as it seems empathy refuses to start on droid4 | 17:21 |
freemangordon | uvos: do I need to do anything special in order to have data connection on d4? | 17:24 |
freemangordon | data connection == gprs | 17:25 |
freemangordon | oh, actually I have, it is just that it is not visible in th eui | 17:26 |
freemangordon | something in icd ofono plugin I guess | 17:26 |
Wizzup | freemangordon: no, it's not in repos with tp | 17:34 |
Wizzup | freemangordon: I ran into issues with telepathy-qt (or my own code) | 17:34 |
Wizzup | freemangordon: we had a version that connected one tp account | 17:35 |
freemangordon | ok, no hurry, there is plenty of work on addressbook pending still | 17:35 |
Wizzup | but multiple accounts wasn't working | 17:35 |
freemangordon | Wizzup: OTOH - does ofono icd plugin work on d4? | 17:35 |
freemangordon | IOW - is it supposed to work | 17:35 |
Wizzup | there are a few known problems with it | 17:36 |
Wizzup | first one: it doesn't wait for ofono to make the data active, and it expects it to be active right away, so the ui reports failure | 17:36 |
Wizzup | unless the thing is already active | 17:36 |
Wizzup | this is not too hard to fix | 17:37 |
Wizzup | and then I don't think it detects when network is not visible, or when data connection is gone | 17:37 |
freemangordon | hmm, but after a restart I don;t see gprs connection in the dialog at all | 17:37 |
freemangordon | so, those are problems in the plugin? | 17:37 |
freemangordon | I can have a look at them | 17:38 |
Wizzup | could be a race with it not seeing the modem? not sure | 17:38 |
Wizzup | a restart of what, btw? | 17:38 |
freemangordon | device | 17:38 |
Wizzup | what if you restart icd2? | 17:38 |
freemangordon | also, do I have to enable/online the modem by hand? | 17:38 |
Wizzup | icd2 does powered up, and online upon scan | 17:39 |
Wizzup | of course if pin is necessary then not obnline | 17:39 |
freemangordon | hmm | 17:39 |
freemangordon | no pin is needed | 17:39 |
freemangordon | yep, after icd restart connection is available | 17:39 |
freemangordon | but it is missing the icon | 17:40 |
Wizzup | you mean in the dialog? | 17:40 |
freemangordon | mhm | 17:40 |
Wizzup | I have it | 17:40 |
Wizzup | maybe just some missing pkg | 17:40 |
freemangordon | yes | 17:40 |
freemangordon | but which one :) | 17:40 |
Wizzup | we have a meta pkg | 17:41 |
Wizzup | it's 00:40 here, need to get some sleep :) | 17:41 |
freemangordon | ok, please ping me when you have some time | 17:41 |
Wizzup | (work tomorrow as well :() | 17:41 |
Wizzup | freemangordon: ok | 17:41 |
uvos | freemangordon: data via icd/ofono has never worked for me | 18:01 |
uvos | freemangordon: i allways use qmicli | 18:02 |
freemangordon | I see | 18:02 |
freemangordon | well, data through ofono (scripts) seems to work | 18:02 |
freemangordon | but UI seems to have issues | 18:02 |
sicelo | It used to work fine on UI, but yes, something changed later on, although no idea what | 18:25 |
freemangordon | mhm | 18:25 |
freemangordon | anyway, gtg now | 18:25 |
freemangordon | ttyl | 18:25 |
humpelstilzchen[ | uvos: I see a different bug with black text on black input field, because it also affects non-maemo qt programs, e.g. qstardict | 19:19 |
uvos | humpelstilzchen[: it should affect non maemo applications | 19:29 |
uvos | also ofc if you find a specific case you have to check if the application isent doing something stupid, like hardcodeing a color. | 19:31 |
uvos | but yeah it affects non maemo applicaitons useing the maemo style | 19:31 |
humpelstilzchen[ | uvos: can't we just fix the gtk style? | 19:34 |
uvos | its not that simple | 19:54 |
uvos | the problem is that the maemo applications use base text on window color | 19:55 |
uvos | while expecting window to have high contrast with base | 19:55 |
uvos | so base text cant also have high contrast with base | 19:55 |
uvos | lots of these instances (eg. input fields) are in the qt plugin so yes you could fix this there | 19:56 |
uvos | but its also true in fremantle so they depended on this | 19:56 |
uvos | since you have to, you have to erroniously use base text on window color otherwise it wont work, if you create a custom widget | 19:57 |
uvos | so yeah im not saying do this would be wrong, but it would not totaly resolve the issue | 19:58 |
humpelstilzchen[ | also, do we really need that sapwood thing on pine? | 21:08 |
norayr | folks, do you think i can compile and make work modern gentoo prefix system on n810 with that old kernel. | 22:31 |
norayr | will modern libraries work with that old kernel? | 22:31 |
humpelstilzchen[ | uvos: never mind, there is no issue here. I had installed qt5ct which sets QT_QPA_PLATFORMTHEME which broke the theme. | 22:59 |
uvos | norayr: glibc has hard requirements on kernel version | 23:47 |
uvos | norayr: some other libs to too | 23:47 |
uvos | glibc is 3.2 i think | 23:47 |
uvos | ofc you could use a different libc | 23:49 |
uvos | but im gona guess that your goint to run into sutch issues somewhere else too | 23:50 |
uvos | so linux 3.2 is really minimal practical version for anything | 23:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!