| Wizzup | if all goes well then tomorrow morning 5.15 sgx should be ready in -devel for droid | 00:37 |
|---|---|---|
| Wizzup | droid4 at least | 00:37 |
| Wizzup | uvos: this issue you were seeing on the d4 | 00:48 |
| Wizzup | -- OMAP 00004430 (version 00000b22) PPA release1.3.5 R2 | 00:48 |
| Wizzup | Reset reason = 000379a2 | 00:48 |
| Wizzup | Model ID is 0x00000003 | 00:48 |
| Wizzup | I just got it on the d3 as well | 00:48 |
| Wizzup | quickly starting a lot of osso-xterms | 00:48 |
| Wizzup | it has a reset reason at least | 00:48 |
| uvos | this looks to be mbm's response to a watchdog reboot | 00:48 |
| Wizzup | hm | 00:49 |
| Wizzup | ok | 00:49 |
| freemangordon | libhildonmime uri handling should work now https://github.com/maemo-leste/libhildonmime/commit/0197ee89187946354fd7849d48b80e69e5f3a338 | 11:50 |
| freemangordon | Wizzup: parazyd: do we already have fixed glib in stable? | 11:50 |
| Wizzup | freemangordon: let's see | 12:49 |
| Wizzup | freemangordon: https://github.com/maemo-leste-upstream-forks/glib/commits/maemo/beowulf | 12:50 |
| Wizzup | so I think -devel should apt dist-upgrade to 5.15 now for the d4 | 12:58 |
| Wizzup | I'll flash my bionic here with an image to try it later today | 12:59 |
| Wizzup | uvos: this could be interesting https://news.ycombinator.com/item?id=29555822 | 13:20 |
| uvos | yeah xorg got support for these via extension recently | 13:33 |
| MartijnBraam[m] | Wizzup: are you still unlocking the droids? | 13:33 |
| uvos | MartijnBraam[m]: he can unlock xt860 and sholes based devices (< droid 2 and friends) | 13:34 |
| Wizzup | MartijnBraam[m]: yes, I made that tweet, happy to provide any info you'd need | 13:34 |
| uvos | xt860 = droid 3 | 13:34 |
| Wizzup | well, we all can, I can easily provide remote access to a VM with the dongle attached if you're looking to RE | 13:34 |
| MartijnBraam[m] | I guess it would be nice to have a t least usb dumps of the unlocking | 13:34 |
| MartijnBraam[m] | dongle? | 13:35 |
| Wizzup | MartijnBraam[m]: don't worry I have a lot of droid3's here locked still | 13:35 |
| Wizzup | MartijnBraam[m]: yes, the sigmakey sw requires you to pay for it, get a physical smartcard, and buy extension packs for features | 13:35 |
| MartijnBraam[m] | heh, and they don't support droid4? :D | 13:35 |
| Wizzup | well, the droid4 comes as unlocked as it can, with the prime exception being the US | 13:35 |
| Wizzup | but iirc (per tmlind) they filter the operator in the modem firmware, which is a whole different story | 13:36 |
| Wizzup | 'as unlocked as it can' is perhaps an overstatement, I mostly meant that you don't need to network unlock it for global (sans US) usage | 13:36 |
| Wizzup | as far as I can tell sigmakey just needs a rooted device and then it uploads a bunch of payloads over adb | 13:37 |
| Wizzup | so if there is a tool to trace adb access/protocol we could dump that rather than dumping the usb protocol, but perhaps there's more going on | 13:37 |
| uvos | sure | 13:37 |
| Wizzup | I opened sigmakey in ida before and it's packed and not easy to RE (I spent a day or two trying to use it without paying) | 13:38 |
| uvos | you can do adb over network btw | 13:38 |
| Wizzup | uvos: that might be better than usbip I guess | 13:38 |
| uvos | if it only uses adb, yeah | 13:38 |
| Wizzup | right | 13:38 |
| MartijnBraam[m] | dumping it one layer higher is a lot nicer for RE yes | 13:38 |
| MartijnBraam[m] | as long as it doesn't do any magic | 13:39 |
| MartijnBraam[m] | over the usb part | 13:39 |
| Wizzup | as longh as that's everything, but it's something we could start with I guess | 13:39 |
| Wizzup | MartijnBraam[m]: so if you have any specific thoughts or ideas on how to make an open tool for it I am all ears, just let me know how I can help, I dreamed about doing it but don't have the time / resources | 13:39 |
| Wizzup | I could also do some usbredir hack with the sigmakey from my usb hub to some other remote computer to allow others to mess around with it | 13:40 |
| MartijnBraam[m] | I can take a look at figuring it out, I'm afraid it's just pulling a file, doing magic adjustments to it and writing it back, which would be very hard | 13:40 |
| uvos | dose sigmakey implement the adb protcoll itself | 13:41 |
| uvos | or dose it come with some version of the offical foss adb server | 13:41 |
| Wizzup | so the windows vm requires the motorola kernel drivers to be installed, but when I select a device I select it using adb in their gui, whatever that means | 13:41 |
| uvos | the moto drivers dont include adb iirc | 13:42 |
| Wizzup | MartijnBraam[m]: even if the binaries they upload are not foss, that's already a big step forward, I bet those binaries are not packed/obfuscated | 13:42 |
| Wizzup | but there is probably also some clever code in sigmakey itself to massage whatever data it gets back from the modem | 13:42 |
| Wizzup | it downloads some (iirc) security area from the modem and writes back changed values later | 13:43 |
| Wizzup | so we'd still have to trace that too | 13:43 |
| uvos | so if it uses the real adb | 13:44 |
| uvos | there is ADB_TRACE=1 | 13:44 |
| uvos | envvar | 13:44 |
| uvos | that prints everything it dose via the bridge | 13:44 |
| Wizzup | it also has a 'root my device' mode, so that could be used to test this path perhaps | 13:44 |
| Wizzup | since that's more easily repeatable | 13:44 |
| Wizzup | I can set up usbredirect(1) with the dongle or provide some form of vm access | 13:45 |
| Wizzup | but my head is too full with other stuff we have to do for leste to dedicated a lot more of my brain/time | 13:46 |
| MartijnBraam[m] | yeah I think usb dumps are fine for now for at least figuring out what's happening, if that's easy to do | 13:46 |
| Wizzup | uvos: oh here's a screenshot of the adb selection https://wizzup.org/sigmakey.png | 13:46 |
| Wizzup | MartijnBraam[m]: ok, I'll look at doing that in the next few days | 13:46 |
| MartijnBraam[m] | can at least write some wireshark dissectors if those don't exist yet for adb | 13:47 |
| MartijnBraam[m] | also getting a scanner today to reverse engineer today so I can't look at it immediately also | 13:47 |
| Wizzup | hm: https://www.wireshark.org/docs/man-pages/androiddump.html | 13:47 |
| Wizzup | MartijnBraam[m]: fun, what scanner? | 13:47 |
| MartijnBraam[m] | epson v600 | 13:48 |
| Wizzup | I have that one here on my shelve | 13:48 |
| MartijnBraam[m] | lol | 13:48 |
| MartijnBraam[m] | apparently it's very popular to scan film rolls | 13:48 |
| Wizzup | also the v800 or v850 | 13:48 |
| MartijnBraam[m] | oh nice | 13:49 |
| Wizzup | we were planning to use it as a replacement for the canon lide mark II since it's no longer being produced at archive.org) | 13:49 |
| Wizzup | I think there is a closed source 'epokwa' backend that it works with, but you probably know that | 13:50 |
| MartijnBraam[m] | apparently the windows software is not great and the linux software is either missing or very broken | 13:50 |
| Wizzup | the epokwa thing works for sure, but it's not ideal yeah | 13:50 |
| Wizzup | bbiab | 13:58 |
| freemangordon | Wizzup: thanks | 14:07 |
| freemangordon | hmm, there is something terribly wrong with ALS on d4 | 14:42 |
| uvos | freemangordon: hmm? | 14:42 |
| freemangordon | screens is being dimmed too much | 14:44 |
| freemangordon | despite brightness being on 5 | 14:44 |
| Wizzup | freemangordon: I don't see that, are you sure it is on 5? | 14:45 |
| uvos | works as inteded here too | 14:45 |
| uvos | i did change the brigtness levels a bit when i dehardcoded them | 14:46 |
| uvos | but lvl 5 is still 80 80 80 80 100 iirc | 14:46 |
| freemangordon | hmm, now I changed timeout to 1 minute and back to 30 seconds it seems to no longer behave | 14:46 |
| freemangordon | weird | 14:46 |
| freemangordon | "backlight time-out" that is | 14:46 |
| freemangordon | hmm, yes | 14:47 |
| freemangordon | it does the same | 14:47 |
| freemangordon | but it seems it is not ALS, but back-light time-out | 14:47 |
| uvos | no sure what you see | 14:47 |
| freemangordon | lemme take a video | 14:47 |
| Wizzup | note to self https://wiki.maemo.org/User:Jebba/Ofono#Using_oFono_in_Pass_thru_mode | 14:50 |
| Wizzup | took a while to find the page | 14:50 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/595 (Get modem passthrough working on n900 and document how to use it) | 14:50 |
| freemangordon | hmm, can't repro :( | 14:52 |
| Wizzup | freemangordon: maybe this is just the bug where the gtk slider doesn't work well | 14:52 |
| Wizzup | so you thought it was at 5 but it wasn't | 14:52 |
| uvos | this is correct | 14:52 |
| uvos | its a bug in hildon-pannable area | 14:52 |
| freemangordon | no, it was varying from very bright to almost invisible | 14:52 |
| uvos | freemangordon: so maybe what you saw is intedet behavior | 14:53 |
| uvos | i fixed something recently | 14:53 |
| uvos | let me discribe | 14:53 |
| freemangordon | like when event-eater is active | 14:53 |
| uvos | yeah i fixed that | 14:53 |
| freemangordon | but was hapenning every few seconds | 14:53 |
| freemangordon | ah, ok | 14:53 |
| uvos | so previously in dim mode | 14:54 |
| freemangordon | but I just upgraded :) | 14:54 |
| uvos | the display would be off | 14:54 |
| uvos | now it works as indended and is dim | 14:54 |
| uvos | this is because on n900 dim IS backlight off | 14:54 |
| uvos | but its transflective | 14:54 |
| uvos | now dim is whatever you set in mce.ini | 14:54 |
| freemangordon | ok, but the dim was triggered every few seconds | 14:54 |
| uvos | hmm | 14:54 |
| freemangordon | mhm | 14:54 |
| Wizzup | isn't the dim a separate thing from als and just timeout based? | 14:55 |
| freemangordon | yes, it is | 14:55 |
| uvos | yes | 14:55 |
| uvos | but it interacts with als | 14:55 |
| uvos | let me explain that | 14:55 |
| freemangordon | but it was like the timeout was set to 5 seconds or so | 14:55 |
| freemangordon | despite being 30 seconds in settings | 14:55 |
| uvos | so if https://github.com/maemo-leste/mce/blob/483c527164bc17898d400d9cd65d7b9408c3b30e/config/mce.ini#L336 | 14:55 |
| uvos | is set | 14:55 |
| freemangordon | yes, dim should interact with als | 14:55 |
| uvos | als will not lower the brightness _ever_ | 14:56 |
| uvos | instead the device will turn on the display | 14:56 |
| uvos | set the brightness to whatever als wants then | 14:56 |
| uvos | and then only change brightness if als wants somethinghigher | 14:56 |
| uvos | until the display either enters dim mode | 14:56 |
| uvos | or is turned off or the user changes profile | 14:56 |
| uvos | so if you have a high als value | 14:56 |
| uvos | and then go somewhere dark | 14:56 |
| uvos | and the device then enters dim mode, and then exits dim mode | 14:57 |
| uvos | brightness will permantetly be lower than before | 14:57 |
| freemangordon | that's ok | 14:57 |
| freemangordon | and not what I was seeing | 14:58 |
| uvos | ok | 14:58 |
| freemangordon | I was on my desk all the time | 14:58 |
| freemangordon | interactinbg with the device | 14:58 |
| uvos | btw | 14:58 |
| uvos | there is another bug in systemui | 14:58 |
| uvos | that breaks timeouts <30s | 14:58 |
| uvos | if tklock is used | 14:58 |
| freemangordon | yeah, I know that | 14:58 |
| uvos | ok | 14:58 |
| freemangordon | we have a fixed timeout of 10(?) or so seconds | 14:59 |
| uvos | 30 | 14:59 |
| uvos | afaik there is no reason for systemui to hold the lock | 14:59 |
| freemangordon | yeah | 14:59 |
| freemangordon | I may look at that someday, when we have all the other things fixed :) | 14:59 |
| freemangordon | it is really not that big issue I think | 14:59 |
| freemangordon | BTW, do we already have pannable-area fix in the repos? | 15:00 |
| uvos | no | 15:00 |
| uvos | i dont know how to fix pannable-area atm (wrt sliders) | 15:00 |
| uvos | the problem is it reports motion events to its child widgets | 15:00 |
| freemangordon | oh, I though it iwas about that 64bits fix | 15:00 |
| uvos | no that the scroling in hildon itself | 15:00 |
| freemangordon | ah | 15:01 |
| uvos | it dosent use panable area | 15:01 |
| freemangordon | but, what is the issue there? | 15:01 |
| uvos | in hildon or panable-area? | 15:01 |
| uvos | so widgets in a pannable-area get motion events reported in the wrong coordinate system | 15:01 |
| uvos | they should get it relative to themselves | 15:02 |
| uvos | but they get the events reported relavie to the root of the pannable area | 15:02 |
| uvos | this breaks sliders | 15:02 |
| freemangordon | is it the same in fremantle? | 15:02 |
| uvos | i dont think so | 15:02 |
| uvos | at least the brightness slider seams to behave | 15:02 |
| freemangordon | hmm, maybe some patch in gtk is missing | 15:02 |
| freemangordon | uvos: sliders are gtk or hildon components? | 15:03 |
| uvos | both | 15:03 |
| uvos | both normal gtk sliders are broken | 15:04 |
| * freemangordon checks | 15:04 | |
| uvos | as are the hildon ones | 15:04 |
| uvos | those are subclasses | 15:04 |
| uvos | and besides anything using the motion evens would be broken | 15:04 |
| uvos | theres probuly other widgets too | 15:04 |
| freemangordon | hmm | 15:05 |
| uvos | actually i think it might be broken on fremantle too | 15:05 |
| uvos | let me check something | 15:05 |
| uvos | the n900's hardware would hide it a bit | 15:05 |
| uvos | no its fine | 15:07 |
| freemangordon | for sure we are missing gtk-range maemo changes | 15:08 |
| freemangordon | and maybe more | 15:08 |
| freemangordon | uvos: as i am not sure what the issue is, could you describe what exactly is broken? iow - how to verify it is fixed? | 15:09 |
| uvos | freemangordon: so the widgets gets 2 events on d4 inevitably because of the high event rate | 15:09 |
| uvos | freemangordon: a touch event | 15:09 |
| uvos | freemangordon: and a motion event | 15:09 |
| uvos | the touch event is in the right place | 15:10 |
| uvos | but the motion event is relative to the root of the panable area | 15:10 |
| uvos | this means the slider gets one event where it thinks the user clicked/touched | 15:10 |
| uvos | and another that tells the widget that the user move his finger from the root of the panable area to the location he really touched | 15:11 |
| freemangordon | ah | 15:11 |
| uvos | this causes the slider to move to the right alot | 15:11 |
| uvos | depening on unkown factors either of these comes in first | 15:11 |
| freemangordon | I see | 15:11 |
| uvos | and the slider either ends up in the right place or maxed out | 15:11 |
| freemangordon | yeah | 15:11 |
| freemangordon | ok, now I see how to test | 15:12 |
| uvos | a good way to test this is to swipe the finger on the brightness slider | 15:12 |
| uvos | then move the finger close to the root of the panable area | 15:12 |
| uvos | and the window | 15:12 |
| freemangordon | it is reproducible in the VM too | 15:12 |
| uvos | the slider works corectly _there_ | 15:12 |
| freemangordon | with a mouse | 15:12 |
| uvos | yeah the motion events are the same with a mouse | 15:13 |
| freemangordon | if you want you may want to look in https://github.com/community-ssu/gtk/ | 15:13 |
| freemangordon | as I am not sure when I will have time for that | 15:13 |
| freemangordon | just grep for MAEMO_CHANGES | 15:14 |
| Wizzup | is it possible something simply changed in what X reports? | 15:14 |
| freemangordon | could be | 15:14 |
| Wizzup | the n900 it not multi touch | 15:14 |
| freemangordon | or nokia patched it | 15:14 |
| Wizzup | let me see if it happens on the n900 | 15:14 |
| freemangordon | but GTK should take care of it | 15:14 |
| uvos | no | 15:14 |
| uvos | its specifcly broken in pannable area | 15:14 |
| uvos | because it uses the motion events itself | 15:14 |
| uvos | and passes them unchainged to the child | 15:15 |
| freemangordon | ah | 15:15 |
| freemangordon | so, it is HildonPannableArea? | 15:15 |
| uvos | yes | 15:15 |
| freemangordon | ok | 15:15 |
| uvos | sliders are fine outside of the area | 15:15 |
| uvos | on n900 its less obvious | 15:16 |
| uvos | because the resoliution of the ts is less and the event rate is less | 15:16 |
| uvos | so you can make just a click event | 15:16 |
| uvos | without a tiny swipe | 15:16 |
| uvos | but it happens there too | 15:17 |
| uvos | (on leste) | 15:17 |
| freemangordon | yeah, does not happen on fremantle | 15:18 |
| freemangordon | ok, will take a look at it | 15:18 |
| tmlind | Wizzup, bencoh, uvos: so i got 3g data enabled and idling at between 60 to 62 mW too now :) | 16:40 |
| tmlind | looks like i had to change to gsm mode, do ifup wwan1, then switch to 3g mode | 16:40 |
| tmlind | somehow in 3g mode doing ifup wwan1 does not work for me, i need to switch to gsm first.. | 16:41 |
| tmlind | looks like using qmi-network in /etc/network/interfaces consumes way less power than starting qmi network manually and not using qmi-network | 16:41 |
| tmlind | i guess using qmi-network command rather than qmicli --wds-start-network polls less or something | 16:43 |
| bencoh | tmlind: If I understood properly, 3g->gsm->3g gives better result (battery-wise) than just enabling 3g? | 16:58 |
| bencoh | 60mW with umts data on is super cool imo | 16:59 |
| bencoh | (it means over 3days idling) | 17:00 |
| tmlind | yup yeah it seems that data enabled we may have a bit lower power consumption than without data.. needs to be checked again for sure | 17:09 |
| uvos | hmm | 17:16 |
| uvos | we dont get that on leste | 17:16 |
| uvos | even with the modem CFUN=0 its about 100mW | 17:16 |
| uvos | and powertop gives about 20 events/s | 17:17 |
| uvos | of which 11 are ipi | 17:17 |
| uvos | so im not sure what we are doing wrong | 17:18 |
| bencoh | uvos: did you try disabling cpu1? | 17:20 |
| uvos | yeah that helps a but | 17:20 |
| uvos | *bit | 17:20 |
| uvos | goes to around 90 or so | 17:21 |
| uvos | thats still quite far off from what tmlind reports | 17:21 |
| bencoh | yeah | 17:21 |
| bencoh | one of the sensors/touchscreen/whatever remains open maybe? | 17:21 |
| uvos | no | 17:21 |
| uvos | lsof dosent show any of those | 17:22 |
| bencoh | then some application keeps wakingup in the background? | 17:22 |
| uvos | not compatible with 21 events/s | 17:22 |
| bencoh | hm | 17:22 |
| uvos | (all of thats various kernel bits as far as i can see) | 17:22 |
| bencoh | right | 17:22 |
| bencoh | maybe CFUN=0 is worse than properly configured gsm? | 17:23 |
| uvos | android uses that in flight mode | 17:24 |
| uvos | and it manages 16-20 ish mW | 17:24 |
| uvos | but yeah | 17:24 |
| uvos | could be modem state | 17:24 |
| uvos | in some more complex way | 17:24 |
| bencoh | (20mW sounds like a dream) | 17:24 |
| tmlind | that's in offline mode though afaik | 17:27 |
| uvos | right | 17:27 |
| uvos | http://uvos.xyz/maserati/powertop.txt (for referance) | 17:27 |
| tmlind | oh looks like ifup wwan1 in 3g also works, but for some reason it takes a really long time.. i've seen that before now that i think of it | 17:28 |
| tmlind | ifup wwan1 just sits there at "Starting network with 'qmicli -d /dev/cdc-wdm1 --wds-start-network=..." | 17:28 |
| tmlind | then a few minutes later it continues while in gsm mode it happens right away | 17:28 |
| tmlind | Wizzup, uvos: you guys do rmmod phy-cpcap-usb on screen blank or when closing the slider? that's about 20 mW savings | 17:29 |
| tmlind | the uart mode in cpcap is a power hog | 17:30 |
| uvos | blacklist phy_cpcap_usb | 17:31 |
| uvos | yeah | 17:31 |
| uvos | tmlind: could you sudo omapconf audit os_idle full_log | 17:32 |
| uvos | just to prove its not some omap internal device | 17:32 |
| uvos | (unlikely but still) | 17:32 |
| uvos | also how are we mesureing power here | 17:34 |
| uvos | my numbers are as reported by cpcap loged every 5 minutes by crond | 17:34 |
| uvos | mesureing on the battery terminals with external equptent results in slightly lower numbers for me | 17:35 |
| uvos | maybe 10mW or so | 17:35 |
| tmlind | uvos: ok my numbers are from cpcap logged every 1 minutes | 17:37 |
| bencoh | 206,1 ms/s 10,7 Interrupt [19] IPI means it's working 20% of the sampling time (?) | 17:38 |
| bencoh | the first line (delayed_work_timer_fn) is odd considering it reports 0 events/s | 17:39 |
| uvos | no idea but those numbers seam screwy in several ways | 17:39 |
| bencoh | well, that's not the only odd one, but I'd love to understand what it means | 17:39 |
| uvos | yeah | 17:39 |
| tmlind | yup i've not had much luck catching any pollers based on the powertop data.. | 17:40 |
| uvos | i also have no idea how it comes up with the 52,7% CPU use number | 17:40 |
| bencoh | 52,7% CPU use doesn't sound too idle to me, so ... yeah | 17:40 |
| uvos | top reports mutch less | 17:40 |
| bencoh | maybe it's 52% CPU when outside of idle | 17:40 |
| uvos | i gues this is of the time not spent in ret or something | 17:40 |
| bencoh | (get out of my head :D) | 17:40 |
| uvos | better type fast :P | 17:40 |
| bencoh | still, if the first column is right, it's a lot | 17:41 |
| bencoh | (first column of the first line) | 17:41 |
| uvos | might also be the time spent outside of ret | 17:42 |
| uvos | really ret confusing it its the only way this makes sense | 17:42 |
| uvos | ie its 206,1 ms/s of seconds running | 17:43 |
| bencoh | delayed_work_timer_fn comes from kernel/workqueue.c, so you should enable /sys/kernel/debug/tracing/events/workqueue and check resulting traces | 17:43 |
| uvos | and its 0,00 Events/s because the powertop sample time started at the tail end of an event | 17:43 |
| bencoh | enabling it might affect the result, but at least we might be able to know which driver keeps scheduling work | 17:44 |
| uvos | i dont have that file | 17:45 |
| uvos | (also no idea how the tracing interface works atm) | 17:45 |
| uvos | ah | 17:45 |
| uvos | nvm | 17:45 |
| bencoh | mount -t debugfs debugfs /sys/kernel/debug/ | 17:46 |
| bencoh | echo 1 > /sys/kernel/debug/tracing/events/workqueue/enable | 17:46 |
| uvos | debugfs is mounted | 17:46 |
| bencoh | cat /sys/kernel/debug/tracing/trace | 17:46 |
| uvos | but yeah was other pebkac | 17:46 |
| bencoh | well, echo 0 to disable it before catting | 17:47 |
| bencoh | (and have it sleep in between, obviously) | 17:47 |
| uvos | its almost exclusively wl1271 | 17:50 |
| uvos | which makes sense and is sane | 17:50 |
| uvos | and dbs_work_handler | 17:51 |
| uvos | which is not mutch help :P | 17:51 |
| bencoh | tmlind: do you have wireless on? | 17:51 |
| tmlind | bencoh: not usually, that saves quite a bit with the ssid scanning i think | 17:52 |
| tmlind | access point scanning whatever the wlan interface is doing | 17:53 |
| bencoh | it might explain the difference then ... at least part of it | 17:53 |
| tmlind | yup | 17:53 |
| uvos | ill disable wifi and test again | 17:54 |
| uvos | 16 events/s | 18:01 |
| bencoh | does anyone know how powertop can report after a few seconds only, when I run it with -t 20 ? | 18:03 |
| bencoh | it feels terribly wrong somehow | 18:03 |
| uvos | dunno i think it reports immidatly on the first round, but it then takes n seconds to refesh | 18:05 |
| uvos | i just wait one refresh | 18:05 |
| uvos | the first round is allso extreamly noisy usually | 18:05 |
| bencoh | (note to self: running powertop --calibrate on my desktop is a terrible idea :D) | 18:05 |
| bencoh | (at least the keyboard still works, but I lost the mouse) | 18:06 |
| Wizzup | tmlind: is that with wwan1 | 19:04 |
| Wizzup | tmlind: I will check @ phy-cpcap-usb | 19:04 |
| uvos | Wizzup: tmlind has just 3 errors in omapconf os_idle | 19:47 |
| uvos | we have 5 | 19:47 |
| freemangordon | uvos: is it possible motion event to come before touch? | 19:49 |
| freemangordon | hmm, that doesn;t make sense | 19:52 |
| uvos | no | 19:52 |
| uvos | not really | 19:52 |
| uvos | ah maybe PanableArea is swallowing a touch event but leaks some of it? | 19:53 |
| freemangordon | it seems it initializes some internal variables on click, which are then used to calculate child coordinates | 19:54 |
| freemangordon | maybe another event comes that resets those, somehow | 19:54 |
| freemangordon | see https://github.com/maemo-leste/libhildon/blob/master/hildon/hildon-pannable-area.c#L112 | 19:54 |
| uvos | yeah i know | 19:54 |
| uvos | i looked at those | 19:54 |
| uvos | but could not figure it out in the time i had | 19:54 |
| freemangordon | ah | 19:54 |
| freemangordon | and this https://github.com/maemo-leste/libhildon/blob/master/hildon/hildon-pannable-area.c#L2611 | 19:55 |
| freemangordon | so somehow ix should be wrong there | 19:56 |
| freemangordon | wrong or zero | 19:56 |
| uvos | the difference is ABE | 19:58 |
| uvos | tmlinds ABE is gated | 19:58 |
| uvos | mine isent | 19:58 |
| uvos | let me kill pulse | 19:59 |
| tmlind | ok maybe that's it | 20:03 |
| uvos | maybe | 20:07 |
| uvos | but killing pulse dosent make it idle | 20:08 |
| uvos | ABE also dosent idle on Wizzup's device | 20:08 |
| uvos | hmm | 20:08 |
| Wizzup | hi, sorry, I was away | 20:44 |
| Wizzup | uvos: I'm planning to spend some time first on the n900 pm stuff and responding to the mailing list stuff (bandgap, panel), but can look at the droid4 stuff later this week or this weekend, let me know if you need anything from me | 20:53 |
| Wizzup | I am not sure what ABE does, but if it is related to audio, could it have something to do with hdmi audio not working perhaps? | 20:54 |
| freemangordon | uvos: hildon_pannable_area_motion_notify_cb doesn't get called at all | 21:07 |
| freemangordon | uvos: p, li { white-space: pre-wrap; } g_dbus_connection_call_sync | 21:20 |
| freemangordon | oops | 21:20 |
| freemangordon | this https://github.com/maemo-leste/osso-applet-display/blob/master/src/cpdisplay.c#L108 | 21:20 |
| freemangordon | you should not unref that | 21:20 |
| freemangordon | see https://www.freedesktop.org/software/gstreamer-sdk/data/docs/latest/gio/GDBusConnection.html#g-dbus-connection-call-sync | 21:20 |
| freemangordon | 'If the parameters GVariant is floating, it is consumed. This allows convenient 'inline' use of g_variant_new(), e.g.: " | 21:20 |
| freemangordon | we get "(controlpanel:21262): GLib-CRITICAL **: 22:18:20.201: g_variant_unref: assertion 'value->ref_count > 0' failed" currently | 21:21 |
| freemangordon | just FYI, going to fix that | 21:21 |
| Wizzup | neat the hubs I have at home already are supported by uhubctl | 21:42 |
| Wizzup | freemangordon: btw did you do some write up for xorg server or should I just try to figure it out | 22:15 |
| Wizzup | (wrt pp) | 22:15 |
| freemangordon | Wizzup: better figure it out, it is obvious iirc | 22:27 |
| Wizzup | k | 22:30 |
| freemangordon | hmm, dns resolution stopped working in leste VM | 22:54 |
| freemangordon | ping: abv.bg: Temporary failure in name resolution | 22:55 |
| sicelo | resolvconf weirdness - at least on my d4, i 'fixed' it with something like `rm -r /etc/resolvconf/run , rc-service stop resolvconf , rc-service start resolvconf` | 22:56 |
| freemangordon | rebooting VM, lets see | 22:56 |
| sicelo | i thought it was because my d4 install was partly broken | 22:56 |
| freemangordon | doesn't help :( | 23:00 |
| freemangordon | hmm: | 23:01 |
| freemangordon | Host abv.bg not found: 5(REFUSED) | 23:01 |
| freemangordon | maybe my host OS is behaving | 23:01 |
| Wizzup | freemangordon: not likely | 23:07 |
| Wizzup | (re: host 0s | 23:07 |
| Wizzup | (re: host os) | 23:07 |
| Wizzup | freemangordon: so we started to use resolvconf and it reads specific files for dns | 23:07 |
| Wizzup | or rather, dnsmasq reads specific resolvconf files | 23:07 |
| Wizzup | it's possible that the vm, which doesn't go through icd2, doesn't make any of these fiels | 23:08 |
| freemangordon | ah | 23:08 |
| freemangordon | bu, I have /etc/resolvconf/resolv.conf.d/original | 23:08 |
| freemangordon | *but | 23:08 |
| Wizzup | https://github.com/maemo-leste/libicd-network-ipv4/commit/d316dfdc511467d69f1f744238e4f47518674e32 | 23:08 |
| freemangordon | and it has correct data in | 23:08 |
| Wizzup | does that get read by dnsmasq though? | 23:09 |
| freemangordon | no idea | 23:09 |
| Wizzup | sec, I'll check | 23:09 |
| Wizzup | cat /run/dnsmasq/resolv.conf | 23:11 |
| Wizzup | I assume that's empty | 23:11 |
| freemangordon | yes, it is | 23:11 |
| Wizzup | so my vm has the same problem | 23:12 |
| Wizzup | I think maybe resolvconf hook never gets called for our /etc/network/interfaces eth0 setup in vm | 23:14 |
| Wizzup | this would make it work (one off): # cat /etc/resolvconf/resolv.conf.d/original | resolvconf -a eth0 | 23:14 |
| Wizzup | so either we need to modify /etc/network/interfaces to call resolvconf, or figure out how to do it automatically, or finally add libicd-network-wired or something | 23:15 |
| freemangordon | ok, that made it work, more or less | 23:16 |
| freemangordon | it seems I've lost default gateway too | 23:17 |
| freemangordon | but, let me reboot to be sure | 23:17 |
| freemangordon | after reboot it s ok | 23:18 |
| freemangordon | how hard would be to add libicd-network-wired? | 23:18 |
| Wizzup | phone src | 23:22 |
| Wizzup | sry* | 23:22 |
| Wizzup | if it's gconf with values we could do it, but still, I'd rather not rely on icd2 | 23:22 |
| Wizzup | like what if it crashes | 23:23 |
| Wizzup | then we cannot ssh in | 23:23 |
| freemangordon | maybe we shall ln /run/dnsmasq/resolv.conf to /etc/resolv.conf ? | 23:26 |
| freemangordon | though I have no idea how dnsmasq works | 23:26 |
| freemangordon | Wizzup: hmm, see /etc/default/dnsmasq | 23:29 |
| Wizzup | hm | 23:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
