=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
[07:28] <guest42315> how do you handle gamepad events in qml?
[07:59] <tsdgeos> mzanetti: app scope is left align? i didn't have that
[07:59]  * tsdgeos tries again
[07:59] <mzanetti> tsdgeos, didn't notice it on the first review either, but I installed that branch on my dogfooding device and last night I saw the apps scope being off
[08:01] <tsdgeos> right, they are
[08:01] <tsdgeos> wonder what they are returning in the align field
[08:01]  * tsdgeos prints
[08:02] <guest42315> so guys.. i need gamepad support in qml.. to code a nice game
[08:03] <tsdgeos> they are not adding anything
[08:03] <guest42315> else i'm not coding a nice game
[08:03] <mzanetti> guest42315, what makes you think that gamepads are not supported in qml?
[08:03] <mzanetti> or rather, how does it relate?
[08:04] <guest42315> oh, i coudn't find documentation oh how to use gamepad in qml
[08:04] <guest42315> :/
[08:04] <mzanetti> guest42315, well, if the gamepad is connected, it should just be like any other input device (mouse/keyboard)
[08:04] <guest42315> at first i thought that i just use the key events but that doesn't work
[08:04] <guest42315> yeah...
[08:04] <guest42315> but it doesn't work
[08:05] <mzanetti> does it work in other applications?
[08:05] <mzanetti> i.e. non-qml ones?
[08:05] <guest42315> the gamepad works in supertux for example
=== davidcalle_ is now known as davidcalle
[08:05] <mzanetti> guest42315, interesting, are you trying that on the phone or on a desktop?
[08:05] <guest42315> desktop
[08:05] <guest42315> the keyboard event work
[08:06] <mzanetti> hmm... then that's odd... I might have been wrong then
[08:06] <guest42315> can you test with a gamepad?
[08:06] <guest42315> :D
[08:06] <mzanetti> I do have a gamepad hidden deep down in the closet somewhere, yes :D
[08:06] <guest42315> :))))
[08:08] <tsdgeos> mzanetti: right, so the appscope has a bug that was hidden by our bug :D
[08:08] <mzanetti> muahaha :D
[08:09] <tsdgeos> i'll see if i can rework it somehow
[08:13] <mzanetti> guest42315, ok... turns out it is not that easy indeed. Should be possible, and google reveals a bunch of tutorials on how to use gamepads/joysticks with Qt but it requires some C++ code.
[08:13] <mzanetti> sounds like an interesting project
[08:16] <Saviq> tsdgeos, re: upstart restart - sure, I understand it doesn't, I just wonder how that's possible
[08:16] <tsdgeos> upstart doing weird things :D
[08:16] <Saviq> tsdgeos, like where would the UNITY_MIR_SOCKET come from if it's not set in upstart
[08:16] <tsdgeos> the docu says that those stanzas are not even run by restart...
[08:16] <tsdgeos> ŝo there's that
[08:17] <Saviq> right, it's pre-start and post-stop
[08:17] <Saviq> so yeah, I'll do some investigation
[08:18] <tsdgeos> i'd call it "upstart broke"
[08:18] <tsdgeos> and we workaround it
[08:18] <tsdgeos> but sure investigate :)
[08:18] <Saviq> I just want to retrace what's happening and how does your change help
[08:19] <Saviq> we should just move to systemd already ;P
[08:19] <tsdgeos> Saviq: i did add some echo "variable" &> /tmp/file
[08:19] <tsdgeos> and you'll see that the variables get lost unless this is added
[08:21] <Saviq> tsdgeos, yeah that's what I plan to do, query initctl for the value, for the global value, look at the local env etc.
[08:22] <guest42315> mzanetti, thanks :D yep would be nice to have gamepad support
[08:24] <Saviq> tsdgeos, only thing that comes to mind is that pre-start and post-stop *are* actually run on restart, and what's more they end up being run in the same environment, so even if post-stop unsets the vars in upstart, the local env still holds them, and the logic gets broken
[08:24] <tsdgeos> Saviq: oh sure, they are run, that's out of question
[08:25] <Saviq> tsdgeos, that could be fixed by using initctl get instead of reading the local env
[08:26] <tsdgeos> maybe :D
[08:26] <tsdgeos> i don't enough upstart to be honest
[08:29] <Saviq> that's the only explanation I have for this, really
=== larsu_ is now known as larsu
[08:44] <tsdgeos> mzanetti: updated the card carousel
[08:44] <mzanetti> tsdgeos, ack
[08:54] <tsdgeos> ltinkl: https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts/+merge/269608
[09:09] <mzanetti> ltinkl, good morning, mind reapproving https://code.launchpad.net/~mzanetti/unity8/animate-spread-invokation/+merge/269722
[09:10] <mzanetti> ltinkl, I had to resubmit with a prereq to avoid conflicts in the silo
[09:10] <mzanetti> no other changes
[09:33] <tsdgeos> hmmmm
[09:34] <tsdgeos> mzanetti: ltinkl: should i be able to get a unity8 desktop session from the current packages in vivid+overlay?
[09:34] <tsdgeos> i get the greeter, to which i put the password
[09:34] <tsdgeos> and i am sent back to the greeter
[09:35] <tsdgeos> Not sure if
[09:35] <tsdgeos> Failed to connect to "/run/user/1004/ubuntu-keyboard-info" after 10 failed attempts
[09:35] <tsdgeos> may be the cause?
[09:35] <greyback_> that's indicating the osk isn't coming up, which isn't fatal
=== nudtrobert1 is now known as nudtrobert
[09:35] <tsdgeos> right, thought so
[09:35] <tsdgeos> wonder if the unity8 process itself is crashing
[09:35] <tsdgeos> let me see
[09:36] <tsdgeos> yep
[09:36]  * tsdgeos debugs
[09:37] <tsdgeos> greyback_: btw i tried yesterday again my game using qgraphcisview on the phone and still segfaults, guess still the support for multiwindow not really there?
[09:37] <tsdgeos> fake multiwindow, since the game really uses only one window
[09:37] <tsdgeos> but i see more than one "Ubuntu Window" printed
[09:37] <greyback_> tsdgeos: it's not there
[09:37] <tsdgeos> i guess something is creating more that aren't really shown
[09:38] <greyback_> but it shouldn't crash, instead only 1 window should be visible
[09:38] <greyback_> any idea where the crash happens?
[09:38] <tsdgeos> sure i can give you a bt, give me a few mins
[09:39] <tsdgeos> so this is where unity8 crashes on my desktop
[09:39] <tsdgeos> http://paste.ubuntu.com/12244262/
[09:39] <tsdgeos> what?
[09:39] <greyback_> eek
[09:40] <greyback_> have you a mix of mir 0.13 & 0.14 packages on your system?
[09:40]  * greyback_ hopes gcc5 ABI shift isn't the cause
[09:40] <tsdgeos> lots of threads but this should not be a problem http://paste.ubuntu.com/12244264/
[09:41] <tsdgeos> greyback_: spot on!
[09:41] <greyback_> that really is a lot of threads
[09:42] <tsdgeos> greyback_: so i guess i can't do anything about it?
[09:42] <tsdgeos> other than move to wily? :D
[09:42] <greyback_> tsdgeos: no it should work
[09:42] <tsdgeos> ah ok
[09:42] <greyback_> could you manually remove the mir 0.13 packages and try again?
[09:43] <tsdgeos> greyback_: this is what i have http://paste.ubuntu.com/12244280/
[09:43] <tsdgeos> greyback_: if i remove the 0.13 packages it wants to remove the unity8 package
[09:44] <tsdgeos> http://paste.ubuntu.com/12244284/
[09:44] <greyback_> hmm
[09:47] <greyback_> my only guess is that something other than qtmir depends on mir, which unity8 happens to use. And that something needs a rebuild
[09:47] <greyback_> I've an errand to run right now, back in 1 hour, will try to repro then
[09:49] <tsdgeos> tx
[10:03] <Saviq> tsdgeos, just drop the Name= on your phone and restart unity8-dash ;)
[10:04] <tsdgeos> Saviq: why?
[10:04] <Saviq> tsdgeos, to check what happens when you remove the Name=Scopes
[10:04] <tsdgeos> i did that on the phone
[10:04] <tsdgeos> looks exactly like what design wants
[10:04] <tsdgeos> just the spinner
[10:05] <Saviq> no reason why it should look different anywhere else, then :)
[10:05] <tsdgeos> well that's not the desktop spread
[10:05] <tsdgeos> it's a different code path
[10:05] <tsdgeos> may look different
[10:05] <Saviq> right, window name
[10:06]  * Saviq didn't really see the desktop spread for quite some time ;)
[10:09] <tsdgeos> greyback_: the crash i get on my game is http://paste.ubuntu.com/12244384/
[10:45] <tsdgeos> is this something we should do? or u-s-c ? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1488959
[10:45] <ubot5> Ubuntu bug 1488959 in unity8 (Ubuntu) "Tapping screen when dimmed should just restore the brightness and not activate a component" [Undecided,Confirmed]
[11:16] <Saviq> tsdgeos, ok, managed to grok what happens with the upstart job
[11:16] <tsdgeos> cool
[11:16] <Saviq> tsdgeos, apart from the fact, as you say, the scripts should not run
[11:16] <tsdgeos> what's wrong?
[11:16] <Saviq> tsdgeos, the problem is we're only unsetting/resetting the global vars
[11:17] <Saviq> tsdgeos, but the scripts run in the *job* env
[11:17] <Saviq> which isn't cleared in case of a restart
[11:17] <tsdgeos> right
[11:17] <tsdgeos> that's actually documented afaik
[11:17] <Saviq> so after post-stop, in pre-start we still have the values in our local and job envs
[11:17] <Saviq> sure, that even makes sense
[11:17] <tsdgeos> but it's also documented thye don't run
[11:17] <tsdgeos> so :D
[11:22] <Saviq> tsdgeos, on top of your branch http://paste.ubuntu.com/12244688/
[11:22] <Saviq> tsdgeos, we should have an autopilot test verifying those
[11:23]  * tsdgeos starts running
[11:29] <mzanetti> dandrader, hey, can you drop the whitespace here please: https://code.launchpad.net/~dandrader/unity8/removeForceActiveFocus/+merge/269609
[11:30] <Saviq> tsdgeos, shouldn't be that bad, we already have something around upstart there ;)
[11:31] <dandrader> mzanetti, ok
[11:31] <dandrader> Saviq, back already? welcome back!
[11:31] <Saviq> dandrader, sounds like you weren't expecting me so soon ;D
[11:31] <tsdgeos> Saviq: so want me to do a restart 3 times and check it works? as part as that MR or separate?
[11:31] <Saviq> dandrader, thanks, happy to be around
[11:31] <Mirv> tsdgeos: have you had time to test the bug fix + unity 8 with the silo 026? I've about completed with full AP suite runs (a pain nowadays).
[11:32] <tsdgeos> Mirv: yes i did, sorry i forgot to update the bug
[11:32] <Saviq> tsdgeos, you mean in an autopilot test? no, maybe just add a FIXME in there
[11:32] <Saviq> to add a test
[11:32] <tsdgeos> Saviq: ok
[11:32] <Mirv> tsdgeos: ok
[11:32] <tsdgeos> food!
[11:34] <mzanetti> anpok, hey, could this be Mir? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1488899
[11:34] <ubot5> Ubuntu bug 1488899 in unity8 (Ubuntu) "USB keyboard not recognized Meizu 4" [Undecided,New]
[11:34] <mzanetti> or rather lower layers?
[11:38] <Saviq> tsdgeos, when you back, ideas on how to get some stats on the portrait-er vs. landscape-er images? I added some console.log()s, but the maths don't add up, looks like the change is triggered more than once sometimes
[11:38] <dandrader> mzanetti, done
[11:38] <mzanetti> ta
[11:52] <anpok> mzanetti: hardware usb issue (otg should work on mx4, shouldnt it?), could be udevd (we upgraded that a one or two months ago),
[11:53] <anpok> but above that.. if it is detect as a keyboard on the udev level there is no reason it shouldnt work with mir
[11:53] <anpok> *detected
[11:53] <mzanetti> anpok, yeah, I agree, just wanted to have another confirmation before assigning the bug way down to lower layers
[11:53] <mzanetti> thanks
[11:53] <anpok> it would be interesting to get dmesg/syslog output
[11:54] <anpok> then we would know for sure
[11:54] <anpok> btw i did add a mir bug which will probabl converge into a udev or kvm problem
[11:54] <anpok> because on wily there is an issue with udev detecting the right mouse deice
[11:54] <anpok> *device
[11:54] <anpok> +within kvm
[12:01] <mzanetti> greyback_, hey, qtubuntu conflicting too (dpr silo)
=== alan_g is now known as alan_g|lunch
=== MacSlow is now known as MacSlow|lunch
[12:24] <greyback> tsdgeos: re your game backtrace, think qtubuntu doing something wrong. Have logged https://bugs.launchpad.net/qtubuntu/+bug/1490956 - if you can add anything, please do
[12:24] <ubot5> Ubuntu bug 1490956 in qtubuntu "QOpenGL widget-based app crashing" [Undecided,New]
[12:32] <tsdgeos> Saviq: you added a console.log where? in the calculation? or in the onchanged?
[12:32] <tsdgeos> the calculation is triggered as the other two variables are calculated
[12:32] <tsdgeos> but afaics the onchanged should only be triggered when it really changes
[12:32] <tsdgeos> greyback: added some stuff and subscribed myself to the bug
[12:32] <greyback> tsdgeos: appreciated
[12:33] <Saviq> tsdgeos, in onCompleted and onChanged on a separate bool prop, but you're right, it might be triggered twice
[12:36] <greyback> ltinkl: hey, do you still want the OOBE silo?
[12:42] <tsdgeos> Saviq: added FIXME as requested
[12:44] <Saviq> tsdgeos, tx
=== davidcalle_ is now known as davidcalle
=== alan_g|lunch is now known as alan_g
[13:10] <ltinkl> greyback, ye please
[13:10] <greyback> ok
=== MacSlow|lunch is now known as MacSlow
[14:51] <tsdgeos> ltinkl: so you're on wily?
=== dandrader is now known as dandrader|afk
[15:19] <ltinkl> tsdgeos, on vivid
[15:19] <tsdgeos> ltinkl: you're runnig your own complited unity8 or installed one?
=== dandrader|afk is now known as dandrader
[15:26] <ltinkl> tsdgeos, compiled
[15:26] <ltinkl> tsdgeos, in a separate session/user
[15:27] <tsdgeos> k
[15:28] <syeh> Hi, can someone here tell me what this line in unityshell.cpp is meant to catch:  renderer.find("LLVM") != std::string::npos
[15:28] <syeh> I think it should try to match "llvmpipe" not "LLVM"
[16:00] <mzanetti> mterry, hey, the QR code in arale's wizard. Did we do that ourselves or was that in cooperation with penk etc?
[16:01] <mterry> mzanetti, I believe we did not do that ourselves
[16:01] <mzanetti> kgunn, do you know? ^
[16:01] <mterry> mzanetti, PES or whatever they were called used a new front-screen for it, via wizard plugins
[16:01] <kgunn> mzanetti: yeah pes thing i think
[16:01] <kgunn> part of custom tarball
[16:01] <mzanetti> ack. will talk to them
[16:02] <mzanetti> thanks
[16:35] <syeh> Trevinho:  in unityshell.cpp, can renderer.find("LLVM") be replaced by renderer.find("llvmpipe")?
[16:57] <Trevinho> syeh: I think is fine... Or keeping both if it's not a problem
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|lunch
[17:30] <syeh> Trevinho:  LLVM is causing a problem for our Gallium driver because we'd like to report LLVM if there's a chance we can fall back to Gallium LLVM draw path for certain operations
[17:34] <syeh> What is the patch review process for Unity?  I am not sure if "format-patch" and "send-email" works under bzr
[18:04] <greyback> syeh: push your branch to bzr, then create a merge proposal. See http://packaging.ubuntu.com/html/fixing-a-bug.html#committing-the-fix
[18:05] <greyback> syeh: so push to lp:~syeh/unity/a_name_for_my_fix
[18:05] <greyback> then can use "bzr lp-open" to open the web-page for your branch, which contains a "Propose or Merging" link
[18:08] <syeh> greyback:  thanks.  I just committed the change in my local repo.  Let me see how to push
[18:09] <greyback> syeh: something like "bzr push lp:~syeh/unity/a_name_for_my_fix" should do the job. Have assumed "syeh" is your launchpad username, replace if needed
[18:11] <syeh> so actually, I've done a "bzr add ..." then "bzr commit" before I got your message.  How do I revert that so I can do debcommit?
=== dandrader|lunch is now known as dandrader
[19:32] <dandrader> mzanetti, ping
[19:39] <mzanetti> dandrader, hey
[19:39] <dandrader> mzanetti, do we have a branch that replaces the rectangular shadow of the app window with only the visible parts along its borders?
[19:40] <mzanetti> dandrader, don't think so. Cimi said he'd be doing that but I haven't seen anything. why do you need that?
[19:41] <dandrader> mzanetti, is not that I *need* it. Just noticed the issue while working on something else
[19:41] <dandrader> so I was wondering
[19:41] <mzanetti> dandrader, ah. on arale?
[19:41] <dandrader> mzanetti, no, N7
[19:41] <mzanetti> hmm... n7 shouldn't be that bad
[19:42] <mzanetti> anyways, no we don't have one yet
[19:43] <dandrader> mzanetti, didn't say I noticed the performance drawback. but did notice the big black semi-translucent rect and thought "hmm... seems wasteful"
[19:44] <mzanetti> right...