**** BEGIN LOGGING AT Tue Sep 15 02:59:58 2015 Sep 15 05:28:18 ka6sox: Wiki seems back to normal now. Any idea what happened? Sep 15 05:30:11 no, but I got a mediawiki expert who will work on it tomorrow...and get things sorted Sep 15 05:30:33 Well it seems OK now again Sep 15 05:30:39 So not sure what happened Sep 15 05:38:23 Tofe: FeedSpider 2 works again, Aressel did an update it seems according to his Twitter post Sep 15 06:37:42 Herrie: ok, great! Sep 15 06:46:50 Tofe: I noticed that with your IPK when I have PIN window visible, plug in USB, it goes back to padlock Sep 15 06:46:57 Is that what you meant yesterday? Sep 15 06:56:19 Herrie: yes, it's a bit too much Sep 15 07:28:54 Tofe: Well it fixed the original bug :P But needs some tweaking indeed. Some graph on how this all works would be helpful I guess Sep 15 07:32:07 Yeah, but it's a bit complex to draw, of course Sep 15 07:32:52 No priority I guess Sep 15 07:33:14 I think I should spend a month or so sometime on just improving documentation on things Sep 15 07:33:17 And there is still this line that I don't fully understand: https://github.com/webOS-ports/luna-sysmgr/blob/webOS-ports/master/Src/base/DisplayManager.cpp#L3418 Sep 15 07:34:47 Ah that's for EAS Sep 15 07:34:52 Why should it check the passcode only when the trigger is this type of event ? I tried modifying it to "displayEvent != DisplayEventUnlock", but it gives the misbehaving of the provided ipk Sep 15 07:34:55 Exchange Active Sync Sep 15 07:34:58 EAS ? Sep 15 07:35:00 ah Sep 15 07:35:29 This basically has a forced password on the device. I.e. the EAS policy can enforce that you're required to put a pin or password Sep 15 07:35:38 We have that here at our company Sep 15 07:36:00 So when you add an Exchange account you'll be forced to set a PIN as well ;) Sep 15 07:36:02 Ok, yes, I have that also here Sep 15 07:36:21 (There's a nice patch though to bypass it :P) Sep 15 07:37:06 Ok, so basically if a state asks to change to "Unlock", then it obeys, apart if there's EAS Sep 15 07:37:37 I guess so. I think this is more when you try to disable pin/password altogether Sep 15 07:42:35 I hesitate to modify the state graph a lot, it could take a lot of time to re-converge on something stable Sep 15 07:43:10 I think for now we can disregard EAS because it was removed from open sourced bits afaik Sep 15 07:43:21 It's not in the email app for sure Sep 15 07:43:46 Ok, but even so, disregarding EAS means we never will lock the screen when on charge :) Sep 15 07:44:23 Not sure to what extend back end stuff is still there, but I guess it's pretty much gone due to licensing fees to MS Sep 15 07:45:48 Also another issue is that this test I pointed to triggers a buggy situation: we get a callstack like StateOff::handleEvent -> StateOn::enter -> updateLockState -> lock -> StateOn::handleEvent -> StateOnLock::enter Sep 15 07:46:10 so we enter the OnLock state when we haven't finished yet entering the StateOn state... Sep 15 07:48:28 To make it short, putting that lock logic in this place is a mistake Sep 15 07:49:26 What we should do is always go to the Lock state, and from there, if there is no lock, go on to the On or Puck models Sep 15 07:49:47 modes* Sep 15 07:51:46 Maybe that could be done fairly easily by modifying just slightly how updateLockState behaves and how the caller handles what is may return Sep 15 07:53:02 morphis: Sep 15 07:53:16 morphis: ^ any thoughts? Sep 15 07:55:03 Herrie|Veer: sounds fine Sep 15 07:56:30 morphis: Was there any specific reason why we pulled the legacy calendar app? Seems FrantID (UberCalendar dev) is willing to have a fresh stab at getting a working Enyo 2 calendar, but just wondering Sep 15 08:03:42 Herrie|Veer: I think it wasn't working well Sep 15 08:04:37 Ah ok could be the window management because it used quite some funny stuff Sep 15 08:04:47 I'll put it sometime to see what it does for me Sep 15 08:05:03 I guess it improved with all work Tofe put into some things recently Sep 15 08:05:15 Anyway an Enyo 2 rewrite would be nice performance wise Sep 15 08:05:54 right Sep 15 08:07:28 FrantId would have a stab at the Enyo 2 version first. He can probably reuse quite a bit from the Enyo 1 app backend wise. I saw 72ka reused a lot of his functions in the Enyo 2 rewrite of his Mojo Google Maps app ;) Sep 15 08:13:58 Ah seems there's an EAS Web API that's open source now :) We could eventually implement that I guess :) Sep 15 08:17:49 Added it to the tracker for sometime in the future. Sep 15 09:55:03 morphis: ping Sep 15 11:54:26 Herrie|Veer: pong Sep 15 12:02:51 Had a discussion with nizovn a little while ago on IEEE802 that's quite commonly used for wifi nowadays Sep 15 12:03:14 We have UPC here that uses it for it's hotspots and I'm sure others use it too. Sep 15 12:05:50 Seems that connman needs a separate config file for each on of these networks Sep 15 12:06:55 Which is not really very user friendly. I know there are different kinds of 2 step auth involved etc but a more user friendly approach would be good. Sep 15 12:07:43 Anything you're aware of that exists for this? Sep 15 12:08:41 Herrie|Veer: you mean things like WPA-EAP ? Sep 15 12:13:04 Tofe: I need to look at home what it uses exactly again, I know it's IEEE802.1x with username and password. When I add the config file I only get prompted for the password (should be username and password). That needs addressing in the wifi plugin and/or Sep 15 12:13:04 the Settings app. Sep 15 12:14:32 Herrie|Veer: IEEE802 is pretty much not only wifi :) Sep 15 12:15:01 morphis: Yeah I know ;) Sep 15 12:15:18 But most commonly we'd see it in wifi on a phone ;) Sep 15 12:15:25 but you mean enterprise networks with authentication, right? Sep 15 12:15:33 morphis: Yes Sep 15 12:15:45 Herrie|Veer: not only as Wifi, Bluetooth, Ethernet, ... Sep 15 12:15:47 Either cert + user name + password etc Sep 15 12:16:01 Herrie|Veer: basically that is pretty easy to setup Sep 15 12:16:21 morphis: Yes but on a phone/tablet 90% of time you'll use it over wifi ;) Sep 15 12:16:30 see https://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt Sep 15 12:16:36 Herrie|Veer: right Sep 15 12:16:48 just place a *.config file in /var/lib/connman Sep 15 12:16:48 I use such thing for my entreprise wifi Sep 15 12:16:49 morphis: Yes but you need to set it up for EACH network ;) Sep 15 12:17:20 Herrie|Veer: right, but what would you do otherwise? Sep 15 12:17:24 each network is different .. Sep 15 12:17:39 Which is a bit of a pain when you're at Starbucks, hotel or somewhere where they use it ;) Sep 15 12:17:54 you have to setup each one individually Sep 15 12:18:02 It's up to the UI to create these files, isn't it? Sep 15 12:18:03 it starts with the fact that each one as a different BSSID Sep 15 12:18:04 Just not sure how legacy dealt with this, I didn't need to worry about config files :P Just user + password Sep 15 12:18:16 Herrie|Veer: that is how the UI abstracts that Sep 15 12:18:27 At least it seemed to me that way ;) Sep 15 12:19:21 there are different types of enterprise networks Sep 15 12:19:42 so you have to select the right type first, then add anything needed for that type (cert, username, password, ...) Sep 15 12:20:15 you could just put some code for this into webos-connman-adapter Sep 15 12:26:45 So webos-connman-adapter would write the config file? Sep 15 12:27:53 Herrie|Veer: yes Sep 15 12:28:03 legacy had some parameters for com.palm.wifi/connect Sep 15 12:35:03 OK will look into that a bit :) Sep 15 13:00:16 JaMa: New build has new PulseAudio right? Sep 15 13:00:24 Will test it when at home tonight :) Sep 15 13:02:54 Herrie|Veer: yes Sep 15 13:06:26 And I'll update my build too Sep 15 13:06:52 JaMa: do you think there's a big gap to switch to Qt 5.5 ? Sep 15 13:10:39 Tofe: unstable builds are already configured to use 5.5 Sep 15 13:10:55 Tofe: no idea how it works in runtime yet Sep 15 13:11:00 * Tofe is tempted to give it a try Sep 15 13:12:30 JaMa: You built unstable image too? Happy to test drive those :) Sep 15 13:15:43 not yet, still building oe world Sep 15 13:30:50 JaMa: Qt 5.5 is currently the only change in unstable? Sep 15 13:35:04 Tofe: Seems like it, it points to jama/fido in meta-webos-ports which has QT 5.5 added compared to our fido branch Sep 15 13:35:43 ok, then I'll test that at home Sep 15 13:42:23 Tofe: yes Sep 15 15:27:50 JaMa: Seems we might have an issue with qtscenegraph-adaptation ? Sep 15 15:29:15 hybristexture.cpp:170:43: error: 'PREMUL' was not declared in this scope. Sep 15 15:36:17 Herrie|Veer: unstable build? Sep 15 15:36:47 Yup in Grouper log Sep 15 15:36:59 Still building but saw this Sep 15 15:37:26 yes, it's possible, I was building Qt 5.5 only for qemux86 Sep 15 15:38:13 Seems it uses qtscenegraph from mer which hasn't been updated since January. Could be that needs some work. Sep 15 15:40:07 yes Sep 15 16:22:19 JaMa: Seems that there's a static inline uint PREMUL (uint x) declaration in eglgralloctexture.cpp but not in hybristexture.cpp Sep 15 16:25:42 It might suffice to c&p that but I'm in no way C++ expert. Sep 15 16:26:01 Tofe: ^ Might be worth for you to look at at your local build? Sep 15 16:28:53 I'll have a look Sep 15 16:44:10 Herrie, JaMa: I think it's an indirect include that is no more there with Qt 5.5 (qdrawhelper_p.h). In another cpp, eglgralloctexture.cpp, we see that they duplicated its definition. I think the same should be done here. https://github.com/mer-hybris/qtscenegraph-adaptation/blob/master/customcontext/texture/eglgralloctexture.cpp#L63 Sep 15 16:45:05 Ah no, it was a direct include. Well, anyway. Sep 15 16:53:46 Tofe: That's what I meant ;) I think that big should be copied to hybristexture.cpp Sep 15 16:53:52 s/big/bit Sep 15 16:55:09 Herrie: oh, I missed your sentence! Yes, I think you're right. Sep 15 16:58:25 Herrie: do you know what "ALS" means, in the context of the display manager ? Sep 15 16:59:29 seems to be related with brightness Sep 15 17:00:00 Tofe: Ambient light sensor Sep 15 17:00:19 ah ! thanks ! Sep 15 17:00:29 Basically it senses the light around and can adjust screen brightness based on that I think Sep 15 17:00:38 nizovn might be able to tell you more Sep 15 17:00:59 That's fine, I just didn't know the acronym Sep 15 17:13:57 Herrie, morphis: regarding the state machine, what is your opinion: should the lock screen be visible between dockmode and On, or between Off and dockmode ? Sep 15 17:14:40 Legacy code seems to consider that DockMode is a sort of locking Sep 15 17:14:47 s/sort/kind/ Sep 15 17:15:39 between both I would say Sep 15 17:16:45 mmmh why not Sep 15 17:16:58 Let's try Sep 15 17:20:42 Tofe: Not sure about between DockMode and On, but for sure between Off and DockMode Sep 15 17:20:45 But let's try Sep 15 18:06:56 Herrie: https://dl.dropboxusercontent.com/u/4679068/luna-next/luna-sysmgr_3.0.0-3%2Bgit1%2Be99f658af8-r0.9_armv7a-vfp-neon.ipk <-- worth testing I think Sep 15 18:20:20 Tofe: Thnx will try in a bit Sep 15 18:20:30 Anything specific I should look for? Sep 15 18:20:59 I think the remaining issues are around the dockmode Sep 15 18:25:03 Having the pincode between Off and dockmode doesn't work that well Sep 15 18:26:39 I mean, the dockmode is meant to be the "screensaver" of the device when on puck Sep 15 18:27:15 OK will test it a bit Sep 15 18:27:39 With regards to the QT 5.5 issue, should work fork, fix use that for now and PR to upstream? Sep 15 18:27:50 I think sledges can merge for this repo ;) Sep 15 18:27:55 So could be quick anyway Sep 15 18:28:38 yes, that should work Sep 15 18:30:34 You want me to try this or you'll give it a go? I cannot really runtime test stuff here ;) Sep 15 18:30:39 Have no C++ setup Sep 15 18:32:52 I don't have any Qt5.5 build setup yet; but I could test that it doesn't break the current build, at least Sep 15 18:33:59 Yeah ;) Sep 15 18:34:18 It should be really straight forward but I'm reluctant to PR untested code ;) Sep 15 18:34:51 hehe Sep 15 18:35:16 I guess adding the qt_div_255 doesn't hurt as well Sep 15 18:54:43 Arf, there's bug in our LockScreen.qml :) Sep 15 18:55:44 ?? Sep 15 18:56:08 https://dl.dropboxusercontent.com/u/4679068/luna-next/luna-sysmgr_3.0.0-3%2Bgit1%2Be99f658af8-r0.12_armv7a-vfp-neon.ipk <-- this is without the additionnal lock for going to DockMode Sep 15 18:57:41 Tofe: Ah :) Sep 15 19:00:22 https://github.com/webOS-ports/luna-next-cardshell/pull/239 <-- this fixed the aforesaid bug Sep 15 19:04:54 https://github.com/Tofee/luna-sysmgr/commit/01d45a3f00b90e9932192c0379dd3ddfd2b72bf5 <-- this is the current state of the rework Sep 15 19:09:27 http://paste.ubuntu.com/12419722/ <-- this builds fine for us (Qt 5.4.2) Sep 15 19:10:33 So basically -#include is gone in 5.5? Sep 15 19:10:44 Hence we need the addition of the other 2 bits? Sep 15 19:13:15 Let me PR it to upstream Sep 15 19:14:42 Herrie|Laptop: it's not gone, but the content has changed, so it's better not to rely on it. And it was private anyway, so we are to blame for using it :) Sep 15 19:16:02 https://github.com/mer-hybris/qtscenegraph-adaptation/compare/master...Herrie82:master Sep 15 19:16:33 Yep ! Sep 15 19:21:25 OK PR in Sep 15 19:21:35 pinging sledges to see if can be merged Sep 15 19:23:21 He may be afk at this hour :) Sep 15 19:24:41 Dunno Sep 15 19:39:36 Seems sledges would prefer to have a single header with these instead because they're now duplicated Sep 15 19:48:54 Why not. Sep 15 19:52:03 Just I have no clue how to do that :P Sep 15 20:21:11 Tofe: LunaSysMgr looks good Sep 15 20:21:42 Just the going back to padlock when you already have pinpad visible and plugin USB is a bit annoying ;) Sep 15 20:23:42 Tofe: Ah needed reboot Sep 15 20:23:46 Seems better now Sep 15 20:27:38 Tofe: I'd say ready for PR :) **** ENDING LOGGING AT Wed Sep 16 02:59:59 2015