**** BEGIN LOGGING AT Sat Mar 14 02:59:59 2015
Mar 14 03:29:18 <DougReeder> I think everything we really need should be on openwebosproject.org
Mar 14 08:48:24 <morphis> EricBlade: I have one
Mar 14 08:51:38 <morphis> EricBlade: but side seems to be still available
Mar 14 08:53:02 <morphis> Herrie|2: yeah 815 can be closed
Mar 14 09:01:57 <nizovn> morphis: according to output, sensors are still working, so it might be something else.
Mar 14 09:03:38 <morphis> nizovn: hm
Mar 14 09:11:26 <Herrie|2> EricBlade: I'm also having HTTrack making a copy since openwebosproject.org is so slow
Mar 14 09:11:44 <Herrie|2> Also copied pretty much everything from the app catalog I could get my hands on ;)
Mar 14 09:42:25 <nizovn> morphis: if you have time, can you test again but with sensortestapp? it shows all sensor readings, so it's interesting how it react on blanking screen.
Mar 14 17:03:21 <morphis> nizovn: let me do that
Mar 14 17:04:34 <morphis> nizovn: looks good so far: https://bpaste.net/show/1715d954e614
Mar 14 17:04:40 <Tofe> ok, I've finished my mako rebuild with my patch on the qpa. Let's see what happens...
Mar 14 17:05:21 <morphis> Tofe: for screen orientation?
Mar 14 17:05:24 <morphis> for which qpa?
Mar 14 17:05:33 <Tofe> morphis: yes
Mar 14 17:05:38 <Tofe> the hwcomposer qpa
Mar 14 17:06:05 <Tofe> just an humble patch
Mar 14 17:06:25 <morphis> ok
Mar 14 17:06:50 <Tofe> https://github.com/Tofee/qt5-qpa-hwcomposer-plugin/commit/cce9f3c9241cd9c624405b0d874186d5713261c5
Mar 14 17:07:07 <morphis> ah ok
Mar 14 17:09:06 <Tofe> not very conclusive so far :(
Mar 14 17:12:54 <morphis> :)
Mar 14 17:13:28 <Tofe> there doesn't seem to be any polling of the screen orientation
Mar 14 17:13:55 <morphis> nizovn: https://bpaste.net/show/31ad99b1b289 that is the LunaSysMgr output when I have ALS enabled and power on/off the display
Mar 14 17:14:51 <morphis> Tofe: possible that the sensor isn't working yet
Mar 14 17:19:48 <morphis> nizovn: a bit more verbose: https://bpaste.net/show/4331d44e58e1
Mar 14 17:20:48 <Tofe> morphis: yeah, doesn't seem to work that much; we have a qml test app, do we ?
Mar 14 17:22:53 <Tofe> mmh even test_sensors can't poll the accelerator, that's not great news
Mar 14 17:25:34 <morphis> hm
Mar 14 17:25:42 <morphis> you blanked the display before trying
Mar 14 17:25:43 <morphis> ?
Mar 14 17:25:55 <Tofe> what do you mean?
Mar 14 17:26:13 <morphis> on N4 there seem to be problems with sensors after you blanked the display
Mar 14 17:26:27 <morphis> and test_sensors might not work as long as sensorfw is running
Mar 14 17:26:47 <Tofe> ok, I'll just kill luna-next
Mar 14 17:27:24 <Tofe> nope. Then I'll try using Qt.Sensors in QML :)
Mar 14 17:27:48 <morphis> hm
Mar 14 17:27:49 <morphis> E/qcom_sensors_hal( 2147): hal_load_oem_lib: ERROR: Could not open OEM HAL library
Mar 14 17:27:50 <morphis> E/qcom_sensors_hal( 2147): hal_init: No native sensors linux driver found in /system/lib/hw/sensors.oem.so
Mar 14 17:27:50 <morphis> E/qcom_sensors_hal( 2147): hal_process_time_resp: Resetting rollover count from 0 to 0
Mar 14 17:28:55 <Tofe> where do you get such output?
Mar 14 17:30:21 <Tofe> from test_sensors: "   Hardware HAL API version: 0x0" <-- doesn't look good to me
Mar 14 17:31:05 <morphis>  /system/bin/logcat
Mar 14 17:31:08 <morphis> also see https://github.com/mer-hybris/unblank-restart-sensors
Mar 14 17:32:46 <Tofe> ah yes, same here
Mar 14 17:34:24 <Tofe> HAL API version issue?
Mar 14 17:35:24 <morphis> hm
Mar 14 17:35:33 <morphis> with test_sensors I don't get any event for any sensor
Mar 14 17:36:20 <morphis> where sensortestapp seems to be able to do that
Mar 14 17:36:42 <Tofe> ah correct
Mar 14 17:38:48 <nizovn> morphis: thanks!
Mar 14 17:40:18 <morphis> nizovn: problem seems to be more like this:
Mar 14 17:40:26 <morphis> when you start sensortestapp while the display is on
Mar 14 17:40:38 <morphis> everything will also work when you blank/unblank the display
Mar 14 17:40:52 <morphis> but when you stop sensortestapp it will not work again afterwards
Mar 14 17:41:23 <Tofe> morphis: I got also that issue without having luna-next running, so no blank/unblank involved (screen was always off)
Mar 14 17:41:56 <Tofe> I would just keep "when you stop sensortestapp it will not work again afterwards"
Mar 14 17:41:58 <morphis> so that is what the Mer guys meant it seems
Mar 14 17:43:11 <morphis> Tofe: try: create testapp.conf with https://bpaste.net/show/78e6ac53ba2e
Mar 14 17:43:20 <morphis> then run sensortestapp -c=testapp.conf
Mar 14 17:43:31 <morphis> that seems to work so far without having luna-next running
Mar 14 17:43:57 <Tofe> morphis: and it will survive a restart of sensortestapp?
Mar 14 17:44:15 <morphis> no
Mar 14 17:44:26 <Tofe> because for me, with default conf, I got all the sensors, including orientation
Mar 14 17:44:28 <morphis> need to restart sensorfwd
Mar 14 17:44:32 <morphis> right
Mar 14 17:44:46 <morphis> output was just too fast for me and I wanted just the orientation one
Mar 14 17:44:51 <Tofe> :) ok
Mar 14 17:45:02 <nizovn> morphis: btw i failed to properly stop sensortestapp, it require sensorfwd restart after each stop
Mar 14 17:45:07 <Tofe> I just wanted to see some lines with orientation, and I'm satisfied
Mar 14 17:45:54 <morphis> nizovn: yeah
Mar 14 17:45:59 <morphis> that is what we see too
Mar 14 17:46:17 <morphis> nizovn: you know why?
Mar 14 17:47:33 <Tofe> however, I'm not yet conviced that the Qt sensor plugin works
Mar 14 17:48:09 <nizovn> morphis: i don't remember :) found right way some time ago, seems i killed it with some signal
Mar 14 17:48:40 <morphis> nizovn: but afterwards running it again was possible?
Mar 14 17:48:47 <nizovn> yes
Mar 14 17:52:31 <morphis> nizovn: what I tried was: start sensorfwd and then sensortestapp
Mar 14 17:52:44 <morphis> then closed the terminal with sensortestapp and opened another one
Mar 14 17:52:50 <morphis> wasn't able to get any events again
Mar 14 17:53:49 <morphis> when I have two running in parallel I can stop one of both with CTRL+C
Mar 14 17:53:59 <morphis> and restart another one without problems
Mar 14 17:54:08 <morphis> but one needs to stay
Mar 14 17:54:33 <nizovn> morphis: with -g=0 it seems to stop correctly
Mar 14 17:55:24 <morphis> looks like sensortestapp waits for some dbus response
Mar 14 17:55:30 <morphis> (gdb) bt
Mar 14 17:55:30 <morphis> #0  0x40cab32c in poll () at ../sysdeps/unix/syscall-template.S:81
Mar 14 17:55:30 <morphis> #1  0x402b8984 in ?? () from /usr/lib/libdbus-1.so.3
Mar 14 17:55:30 <morphis> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Mar 14 17:55:36 <morphis> which it never gets
Mar 14 18:00:50 <morphis> bash-4.3# sensortestapp -g=0
Mar 14 18:00:50 <morphis> Config file " "/usr/share/sensorfw-tests/testapp.conf" " successfully loaded
Mar 14 18:00:50 <morphis> Failed to load plugin
Mar 14 18:00:50 <morphis> Failed to initialize SensorHandler. Aborting.
Mar 14 18:00:55 <morphis> that is what I get with -g=0
Mar 14 18:01:54 <nizovn> morphis: yes, now got the same
Mar 14 18:04:58 <morphis> nizovn: any idea?
Mar 14 18:05:25 <nizovn> need to think, but now seems i can replicate it on TP
Mar 14 18:05:53 <morphis> seems to hang here: https://github.com/mer-packages/sensorfw/blob/master/tests/testapp/sensorhandler_qtapi.cpp#L142
Mar 14 18:10:35 <morphis> interesting
Mar 14 18:10:41 <morphis> its whole dbus service seems to hang
Mar 14 18:10:44 <morphis> also a bash-4.3# mdbus2 -s com.nokia.SensorService
Mar 14 18:10:52 <morphis> doesn't respond
Mar 14 18:11:58 <morphis> ah https://bpaste.net/show/13db601d74c4
Mar 14 18:13:36 <morphis> the reader thread doesn't seem to finish
Mar 14 18:15:25 <morphis> and the other thread seems to also wait
Mar 14 18:15:53 <morphis> but on a different condition
Mar 14 18:24:06 <Herrie> Tofe: I created another small bug for the notifications, especially the battery ones
Mar 14 18:25:13 <Herrie> Let me know if it's clear, if not I can clarify. Basically battery notifications should overwrite each other. So the 15% should overwrite the 20% one, the 10% one should overwrite the 15% one. Also the "Device Shutdown" banner doesn't disappear in any way ;) Which it should when it starts charging ;)
Mar 14 18:25:45 <morphis> Herrie: that seems to be more something we need to handle from the systemui app
Mar 14 18:26:55 <Herrie> morphis: Not sure where it needs to happen
Mar 14 18:27:04 <Herrie> I couldn't pin it down while I was looking through various bits
Mar 14 18:27:24 <morphis> nizovn, Tofe: maybe https://bpaste.net/show/8d70724288c1 helps
Mar 14 18:27:43 <Herrie> There is some code for it in systemui but doesn't seem to work
Mar 14 18:28:24 <morphis> hm, maybe there is a default timeout for banner messages
Mar 14 18:28:30 <morphis> how is it on your Veer?
Mar 14 18:28:47 <morphis> does the banner message disappear shortly after it appeared or does it stay?
Mar 14 18:29:07 <morphis> Herrie: btw. https://github.com/webOS-ports/luna-systemui/blob/webOS-ports/master/data/PowerdService.js is the code for this
Mar 14 18:29:08 <Herrie> https://github.com/webOS-ports/luna-systemui/blob/webOS-ports/master/data/PowerdService.js#L121
Mar 14 18:29:23 <Herrie> That should close it once it's charging but it doesn't
Mar 14 18:29:32 <morphis> hm
Mar 14 18:29:33 <Herrie> Only a Luna-Next Restart or full reboot makes it disappear
Mar 14 18:29:48 <morphis> checking the received ls2 response would be a good start
Mar 14 18:30:07 <morphis> console.log(JSON.stringify(inResponse));
Mar 14 18:38:22 <Herrie> In LNC or in the systemUI?
Mar 14 18:40:13 <morphis> in systemui
Mar 14 18:40:49 <Herrie> OK
Mar 14 18:40:54 <morphis> nizovn: https://bpaste.net/show/8d70724288c1 helps a bit
Mar 14 18:41:04 <morphis> at least it makes things communcating again
Mar 14 18:42:38 <Herrie> morphis: OK will have a look then
Mar 14 18:52:57 <nizovn> morphis: yes, for me works too
Mar 14 18:55:29 <morphis> nizovn: but do you get new events afterwards?
Mar 14 18:56:01 <morphis> nizovn: https://bpaste.net/show/f04d9eed042f is what I get then
Mar 14 19:03:05 <nizovn> yes, see this sometimes after turn off screen
Mar 14 19:07:32 <morphis> hm
Mar 14 19:43:45 <nizovn> morphis: btw if set okToStop it false, it works good
Mar 14 19:44:01 <nizovn> s/it/to
Mar 14 19:47:52 <morphis> really?
Mar 14 21:03:49 <Herrie> morphis: Seems systemui doesn't see the charging state
Mar 14 21:04:04 <Herrie> At least not when USB is connected
Mar 14 21:04:16 <Herrie> While it is charging and cardshell shows charging symbol? CONSOLEAPI LOG: Herrie 2a inResponse{"percent":98,"percent_ui":100,"temperature_C":296,"current_mA":-1,"voltage_mV":4380291,"capacity_mAh":-1}
Mar 14 21:05:44 <morphis> Herrie: that looks like the wrong response from the service
Mar 14 21:06:58 <nizovn> Herrie: i didn't know batteries are so smart that provide temperature in kelvins (seems _C is mistake) :)
Mar 14 21:07:56 <Herrie> I think it's 29,6c ;)
Mar 14 21:08:24 <Herrie> morphis: That's what {kind:enyo.PalmService, name:"batteryStatus", service:"palm://com.palm.bus/signal/", method:"addmatch", subscribe:true, onResponse:"handlePowerNotifications"}, returns
Mar 14 21:10:28 <Herrie> {kind:"PalmService", name:"chargerStatusQuery", service:"palm://com.palm.power/com/palm/power/", method:"chargerStatusQuery"}, does return the charging status
Mar 14 21:11:08 <Herrie> Not sure how this works exactly: https://github.com/webOS-ports/luna-systemui/blob/webOS-ports/master/data/PowerdService.js#L52
Mar 14 22:11:52 <Herrie> OK might have found the problem & solution more or less
Mar 14 22:12:02 <Herrie> Now just need to let the N4 drain a bit to see what it will do ;)
**** ENDING LOGGING AT Sun Mar 15 02:59:59 2015