#ubuntu-mir 2013-12-02
<xubincd> #ubuntukylin-devel
 * mterry waves at anpok
<w-flo> kdub, I think you worked on the android/HWC improvements.. good job, Mir is a pretty nice experience now on my old Desire Z :)
<kdub> thanks w-flo :D
<kdub> always good to hear new devices working
<w-flo> yeah, I only had to upgrade to the newest qcom binary driver.. There was some sort of deadlock in eglSwapBuffers using the older one
<w-flo> then it was a nice surprise to see how smooth it works, compared to a few weeks ago :)
<kdub> w-flo, yeah, we improved things so out-of-the-box hwc's should run more reliably within the last month or so
<mterry> kdub, just got out of a meeting.  So the hw_get_module failure is eventually from the_graphics_platform() from the DisplayServer() constructor
<kdub> mterry, yeah, i'm moderately sure the construction for NestedDisplay goes and calls some things it shouldnt
<mterry> kdub, hmm, I believe it
<kdub> mterry, hopefully we've pinpointed the problem, i can make a branch to unblock
<kdub> maybe tomorrow?
<mterry> kdub, awesome! thanks
<alan_g> alf_: can you re-review https://code.launchpad.net/~alan-griffiths/mir/yet-more-cleanup-of-ownership-of-client-buffers/+merge/197089
<alf_> robotfuel: Hi! I have a proposal for removing CI logic from our build files, exposing the ability to not run a test as an option https://code.launchpad.net/~afrantzis/mir/build-options-for-tests/+merge/197051
<alf_> robotfuel: we need to change the script that runs http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/192/console to pass the right options to cmake
<alf_> robotfuel: -DMIR_RUN_INTEGRATION_TESTS=OFF -DMIR_RUN_ACCEPTANCE_TESTS=OFF
#ubuntu-mir 2013-12-03
<kgunn> racarr: what was the little handy trick to get jenkins to pick up an mp ?..."request review" pick jenkins bot user...but what do you put in "type of review" ? "continuous integration"?
<racarr> kgunn: Yes
<racarr> continuous-integration
<alan_g> RAOF: Does this match the ugliness of the surrounding code? https://code.launchpad.net/~alan-griffiths/mir/hack-the-hack/+merge/197501
<alan_g> anpok: http://unity.ubuntu.com/mir/index.html
<kdub> mterry, so the nested was working with the simple client
<mterry> kdub, awesome, as I'd expect
<mterry> kdub, so do you want help setting up greeter mode?
<kdub> mterry, probably not enough time, have to jump into meetings
<kdub> could you point me at the code? maybe a visual inspection will give clues
<mterry> kdub, OK
<mterry> kdub, heh, it's not a small branch.  lp:~mterry/unity8/split
<mlankhorst> anyone wants to test mesa10 before I upload it to the archive? I've copied it to https://launchpad.net/~ubuntu-x-swat/+archive/ppa/+packages -- should be published shortly
<mterry> kdub, hmm, my other crash I was looking at (which might be same issue?) is crashing in libhybris.  Will try to get more info for ya, to confirm it's a Mir problem
<mlankhorst> ok it's up now
<mlankhorst> RAOF: can you please please accept pixman sru to saucy? :P
<mlankhorst> and probably raring, quantal, precise too but less priority there
<RAOF> mlankhorst: Sure, in a bit.
<mterry> kdub, heyo!
<mterry> kdub, so I think this other crash I'm seeing on the N7 is related to the nested-mode-does-too-much issue.  It's also crashing in the_graphics_platform(), possibly when trying to load the graphics library
<mterry> kdub, this N7 crash is easier to setup than the greeter crash
<mterry> kdub, and in fact, is actually blocking nested mode from landing, whereas the greeter one isn't
<mterry> kdub, so I'd love some of your time tomorrow for debugging
<ogra_> mterry, is anyone beyond me looking into maguro at the sprint ?
<ogra_> i'm at the point where i'm stuck in a loop of:
<ogra_> ioctl(14, 0xc01c6730, 0xbe99708c)       = 0
<ogra_> writev(15, [{"\6", 1}, {"IMGSRV\0", 7}, {":0: PVRSRVCreateDCSwapChain: Err"..., 50}], 3) = 58
<ogra_> writev(15, [{"\6", 1}, {"IMGSRV\0", 7}, {":0: framebuffer_device_open: Fai"..., 68}], 3) = 76
<ogra_> nanosleep({1, 0}, 0xbe997158)
<ogra_> which points to the driver ... which i have not much clue about
<mterry> ogra_, last time I checked in, it was using SF mode.  Did you force it to use mir mode?
<ogra_> mterry, maguro uses mir since saucy
<ogra_> we released it with mir
<mterry> ogra_, kdub thinks nested mode is doing too much hw configuration
<mterry> ogra_, no no
<ogra_> yes yes :)
<mterry> ogra_, I mean your stracing was showing it trying to use SF mode
<ogra_> oh, right
<mterry> ogra_, despite the fact that it should use Mir
<ogra_> well, i forced it to Mir by exporting the var before stracing
<ogra_> yeah
<mterry> ogra_, so if nested mode is doing bad hw config, that would explain why we see such weird results across hardware
<ogra_> there are other issues too for sure
<ogra_> ah, k
<mterry> ogra_, so I'm hoping for some sort of silver bullte
<mterry> ogra_, though having to force Mir is bad...
<ogra_> hehe, well, you are surely at the right place to catch one
<ogra_> yes, there are issues in lightdm or logind
 * mterry will get kdub drunk enough to agree to help
<ogra_> but these are separate from unity8 falling over
<ogra_> ++
<mterry> ogra_, I'll have to find a maguro to see why it's unique wrt to lightdm
<ogra_> i'll happily pay the beer, just send me the bill
<mterry> lightdm at least I can navigate, unlike this Mir stuff
<mterry> ogra_, so you forced MIR_SOCKET.   What did you do to force /run/user to behave?
<ogra_> well, i suspect lightdm doesnt do its job because Mir doesnt do right .... but we'll see
<ogra_> i added some mkdir, chown, chmod stuff the the wrapper to get the dir
<ogra_> that gets me a proper upstart session in which i can play with unity then
<ogra_> and stracing unity8 gets me the above framebuffer error in a loop until it gets frustrated any exist
<ogra_> *exits
<mterry> ogra_, I'm very confused by the runtimedir failure.  That really shouldn't be affected by Mir.  But it seems to work in non-nested mode...  /me hopes for large silver bullet
<ogra_> well, lets see, i'll hunt down more people tomorrow ... i'm sure we'll get somewhere before end of the week
<ogra_> as long as we can get Mir to start at all :)
<RAOF> alan_g: https://code.launchpad.net/~raof/mir/hack-hack-hack-remove-a-hack/+merge/197581
<alan_g> RAOF: looking...
 * alan_g thinks that looks much better! (but does it work? ...)
<RAOF> alan_g: Works for me :)
<alan_g> RAOF: and me. APPROVED!!!!
<ricmm> duflu: so
<ricmm> for platform-api clients, xbgr or bgr for occlusion support?
<ricmm> we can just select that one directly in src/ubuntu/mirclient/
<ricmm> no need for more smart opperation
<duflu> ricmm: Either should be fine
<duflu> ricmm: Don't stick to only one pixel format though. Expect the next device you try to not support it
<ricmm> duflu: everything else is in development-branch?
<duflu> ricmm: Even better. Everything else is released in archive Mir 0.1.2 already
<ricmm> ah perfect
#ubuntu-mir 2013-12-04
<RAOF> duflu: Yo! https://code.launchpad.net/~raof/mir/faster-debootstrapping/+merge/197660
<duflu> RAOF: Awesomtastic
<RAOF> duflu: https://code.launchpad.net/~raof/mir/faster-debootstrapping/+merge/197661
<alf_> duflu: are you OK with https://code.launchpad.net/~alan-griffiths/mir/cleanup-one-of-the-surface-classes/+merge/197250 after the conflict fixes?
<mlankhorst> anyone wants to test mesa10 before I upload it to trusty?
<mlankhorst> final call :P
<seb128> mlankhorst, you should probably do a call for testing to ubuntu-devel@
<duflu> alf_: mir_connection_promote(conn, privs)
<duflu> mir_connection_demote(conn, privs)
<alan_g> mir_connection_requires_privileges(connection, "...")
<mterry> kdub, reboot
<racarr> greyback: https://raw.github.com/f69m/ubuntu-phablet_platform-api/master/android/hybris/test_c_api.cpp
<racarr> g++ test_c_api.cpp `pkg-config --cflags --libs ubuntu-platform-api` -lGL -lEGL
<greyback> racarr: http://pastebin.ubuntu.com/6520884/
<bregma> hey all, I'm trying to run Unity8+mir natively on the desktop, but it seems the gallium drivers are trying to connect to the X server ... http://paste.ubuntu.com/6521723/
<bregma> anyone know of a way to force that not to happen?
<bregma> some magic environment variable, perhaps?
<bregma> dark incantations and a live sacrifice?
<bregma> ah, EGL_PLATFORM=drm ... causes a segfault instead, slightly better
<bregma> ah, OK, EGL_PLATFORM=mir at a guess, and much more success: throws an exception "what():  Could not create egl surface" yay!
<mlankhorst> bregma: no
<mlankhorst> bregma: you would need to write a gallium egl mir backend
<mlankhorst> or remove /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so temporarily while debugging :P
<mlankhorst> i guess we could stub out mir in egl_gallium so it falls back more gracefully
#ubuntu-mir 2013-12-05
<RAOF> robotfuel: Good $TIME_OF_DAY, CI friend! How would I go about getting an additional package installed (specifically: fakeroot) in the pre-build environment of our jenkins android autolander?
<duflu_> kgunn: swap interval 0 is https://bugs.launchpad.net/mir/+bug/1206400
<ubot5> Ubuntu bug 1206400 in Mir "Frame rates of GL clients are limited to 60Hz on Android, even with swapinterval=0" [Medium,Triaged]
<kdub> mterry, lp:~kdub/mir/fix-1258056
<kdub> if you need galaxy nexus nested to work
<ogra_> \o/
<mterry> kdub, ooh awesome!
 * mterry hugs kdub
<mterry> kdub, will test on the devices and get back to you
<mterry> kdub, unless you've already tested?
<kdub> i tested on my maguro, seems to work
<mterry> well, regardless, probably nice to have more data points
<mterry> kdub, awesome
<mterry> kdub, though I am interested to see if it also fixes my nexus4 or nexus7 problems
<kdub> well, one of those was the user being wrong
<mterry> kdub, not quite.  it was because the lightdm user wasn't in the video group and couldn't access /dev files that Mir wanted
<mterry> kdub, but really, Mir shouldn't need the user to be in video group when nested, right?
<mterry> kdub, and your fix will obviate the need
<mterry> right?
<kdub> it needs to be in the group with the access to the gpu/display devices
<kdub> well...
<mterry> kdub, even for nested?  :-/
<kdub> okay, i re-read and saw nested
<alan_g> kdub: shouldn't the nested version access h/w via the host
<mterry> kdub, ah cool
<kdub> nested doesn't have to be in the video group
<mterry> kdub, so yeah, it's a silver bullet for my problems  :)
<kdub> hopefully
<alan_g> ok
<mterry> ricmm, lp:~kdub/mir/fix-1258056
<mterry> kdub, OK!  I tested on maguro, and confirmed your fix there.  I tested on my mako and confirmed that it fixed the need to be in the video group there.  And I tested on grouper, but we still hit the GRALLOC/shm bug there.  Though once that is fixed, I'm sure your patch will help there too
<mterry> ricmm, ^ Yay!  So only bug left to squash for nested mode is GRALLOC/shm
 * mterry hopes
<mterry> ogra_, ^ FYI
<mterry> kdub, let me know when you file, I can comment on your merge with my test results
<ogra_> mrawesome, thanks !!
<kdub> mterry, okay
<alan_g> RAOF: alf_: anyone want to approve https://code.launchpad.net/~mir-team/mir/fix-hack-the-hack/+merge/197821
<ricmm> kdub: ping
<kdub> pong
<kdub> ricmm,
<ricmm> kdub: so I see your changes for n7 hwc layers
<ricmm> I see you made it smarter for general use
<ricmm> did you try this on n7 before landing?
<kdub> yes
<ricmm> im afraid something else might have regressed then
<ricmm> oh no, wait
<alf_> ricmm: kdub: ping? pong? The email thread was obviously not effective, we need more of it! ;)
<kdub> my n7 needs charge time to test
<ricmm> pingpongpingpong
<kdub> ping#ping.?
 * ogra_ has a ringing in his ears 
<ricmm> ogra_: my n7 is no longer writeable in /system/ when I touch .writeable_image
<ricmm> ogra_: do I need to jump through some other hoops to be able to remount rw ?
<ogra_> hmm
<ogra_> there was a bug recently, but stgraber fixed that iirc
<ogra_> is that an up to date install ?
<ricmm> maybe a few days old
<ricmm> but I cant flash it with latest without losing hours of work
<ricmm>  /days
<ricmm> ogra_: anything simpler? :D
<ogra_> i need to ask stgraber what his solution was ...
<ogra_> you should theoretically be able to just remount,rw
<ricmm> mount: cannot remount block device /dev/loop1 read-write, is write-protected
<ogra_> yeah ...
<ogra_> https://launchpad.net/ubuntu/trusty/+source/initramfs-tools-ubuntu-touch/0.63 ... that was the fix
<ricmm> I have .63
<ogra_> did you ever use apt to upgrade ?
<ricmm> no idea mterry gave me this one
<ricmm> why?
<ricmm> I have installed mir-demos tho, from apt
<ogra_> .63 wont help if the android side wants rebuilt and installed too
<ricmm> Ubuntu Trusty Tahr (development branch) - armhf (20131203.1)
<ogra_> hmm, thats not actually old
<ricmm> ogra_: latest android side for n7 has hwcomposer in there?
<ricmm> I'll just flash one I built y'day I think
<ogra_> hmm, no idea ...
<RAOF> fginther: Yo! Could we have an extra package installed in the pre-build environment for Mir-on-android CI? Specifically, setup-partial-armhf will soon require fakeroot.
<RAOF> ./autogen.sh --prefix=$HOME/.local --with-dri-drivers=i965,i915,r200,radeon,nouveau --with-gallium-drivers=i915,ilo,nouveau,r300,r600,radeonsi,svga,swrast --enable-glx-tls --enable-shared-glapi --enable-texture-float --with-egl-platforms=drm,x11,mir,wayland --enable-gles2 --enable-gles1  --enable-openvg --enable-gallium-egl LLVM_CONFIG=/usr/bin/llvm-config-3.4 --with-llvm-shared-libs CFLAGS="-O0 -g3" CXXFLAGS="-O0 -g3"
<fginther> RAOF, I'll add an action to look at this today and get back to you. The tentative answer is 'yes' but I need to double check
#ubuntu-mir 2013-12-06
<alan_g> duflu: are you questions addressed? https://code.launchpad.net/~alan-griffiths/mir/make-shell-SurfaceController-disappear/+merge/197583
<greyback> racarr: lp:~mzanetti/unity8/dont-assert-on-invalid-variant/ fixes your crash
<greyback> racarr: actually it landed in unity8 trunk
<ogra_> kdub, i dont get why powerd would matter for slow rendering of Mir (especially since that change landed in saucy, Mir on trusty is still slow as molasses on maguro ... )
<ogra_> (referring to bug 1182930 here)
<kdub> there was that one issue where the powerd hal wasn't being called
<ubot5> bug 1182930 in touch-preview-images "Galaxy Nexus rendering performance is too low" [Undecided,Fix released] https://launchpad.net/bugs/1182930
<ogra_> yes
<kdub> and that issues was resolved in powerd
<ogra_> that was a different bug
<ogra_> this one is about performance of the UI under Mir
<kdub> which was that bug? (the powerd one)
<ogra_> bug 1255045 was the one the powerd change was supposed to fix
<ubot5> bug 1255045 in Mir "screen does not turn on on maguro when pressing the power button" [Undecided,Incomplete] https://launchpad.net/bugs/1255045
<kdub> no, that's something different
<ogra_> well, in any case the performance didnt change due to powerd
<kdub> iirc, there was some sort of udev spamming or something going on that had interactions with the PowerHal
<ogra_> and we still get 50 uevents per second for each vsync
<ogra_> (this was only found in trusty ... powerd was not uploaded to trusty at all yet and teh fix you point to is from saucy times )
<ogra_> it might be a bug i dont know about, but i dont think it has anything to do with 1182930
<kdub> ok, i'll undo the changes then until we know more
<ogra_> i'm also not sure the PowerHAL stuff i pointed to has anything to do with it, i was just speculating that the 5 uevents per second could keep the system busy under the hood
<ogra_> s/5/50/
<kdub> well, it sounds like we don't quite know the cause here, so I put the bug back to 'new'
<ogra_> k
<ogra_> kdub, erm, you only newed powerd
<ogra_> ah, no, you didnt, sorry
<ogra_> my bugmail lies
<ogra_> ricmm, any news about grouper wrt u-s-c ?
<RAOF> fginther: How goes the fakeroot installation determination?
<fginther> RAOF, sorry, forgot about it. Looking right now
<fginther> RAOF, thanks for the reminder
<fginther> RAOF, do you have a branch I can test with?
<RAOF> fginther: https://code.launchpad.net/~raof/mir/faster-debootstrapping/+merge/197661
<fginther> RAOF, turned out to be a lot easier then I expected. It's ready now, I was able to do a successful test build on your branch.
<fginther> RAOF, http://s-jenkins.ubuntu-ci:8080/job/mir-android-trusty-i386-build/393/console
<RAOF> fginther: Bitchn'. Thanks!
<fginther> kgunn, are you guys ready to flip on the touch device integration tests that Chris Gagnon put together?
<alan_g> kgunn: @^ there was one test Chris saw failing intermittently that I couldn't reproduce. We could just disable it until we fixed if it is a problem
<kgunn> fginther: yes! we'd love to & yeah alan_g as you say let's just disable the one...we've been trying to get those in for a while
<fginther> kgunn, cool, I'll get this going
<alan_g> \o/
<kdub> yay!
 * alan_g waits to see if the test fails enough to be a PITA
<davmor2> kgunn: do you happen to know if the fix for this landed yet at all? https://bugs.launchpad.net/unity8/+bug/1253810
<ubot5> Ubuntu bug 1253810 in unity8 (Ubuntu) "Messages in Incoming not always display the correct date and content" [High,Confirmed]
<kgunn> davmor2: nope, there's a branch related as you might notice...we were waiting until monday so Saviq could chck with dednick if there's another way to fix (e.g. are we really fixing it the correct way)
<davmor2> kgunn: okay that's great thanks :)
#ubuntu-mir 2014-12-01
<RAOF> desrt: Hey, how would you like your client logging integration?
<RAOF> (As in: how would you like messages from libmirclient to be presented to you)
<alan_g> alf__: it isn't urgent, but as no-one "owns" USC could you please review this at a convenient point? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/migrate-to-mir-Server-API/+merge/240566
<alf__> alan_g: sure
<mlankhorst> what do I need for setting up lightdm correctly to run unity8 on a normal ubuntu install?
<alan_g> mlankhorst: http://unity.ubuntu.com/mir/using_mir_on_pc.html (I hope it is up to date - I've not used if for ages)
<mlankhorst> i don't think it is
<alan_g> What happens?
<alan_g> mzanetti: IIRC you've used unity8 desktop recently. ^^
<mlankhorst> I've installed unity8-desktop-session-mir, but it fails to spawn a native mir session
 * mzanetti reads
<mzanetti> mlankhorst: hmm... that should work. I didn't do anything special.
<mzanetti> mlankhorst: try to first log in into a unity7 session, then logout again and relogin to the unity8 session
<mzanetti> that seems to improve chances of a successful start
<mzanetti> it is still a bit flaky
<mzanetti> mlankhorst: I've heard of people with nvidia cards having issues. I'm using an Intel one
<desrt> RAOF: 'just use the journal'?
<desrt> RAOF: otherwise i guess a callback is fine
<mlankhorst> btw does the unity8 session run fullscreen on mir?
<greyback> mlankhorst: yes it does
<mlankhorst> so if I create a Xmir window there, it will be hidden by the u8 session?
<greyback> yes, if that mir client is connecting to unity-system-compositor. But if you connect it to unity8 (MIR_SOCKET=$SDG_RUNTIME_DIR/mir_socket) it should appear in unity8
<greyback> you'll need to append "--desktop_file_hint=/usr/share/applications/some-desktop-file.desktop" to the process, else it won't be accepted
<greyback> as unity8 is strict, and requires either upstart to launch the app, or else that command line arg appended to the command
<mlankhorst> ah
<mlankhorst> would that explain the broken pipe? :P
<mlankhorst> where can I find that in the source :p
<greyback> that policy is defined in lp:qtmir:/src/modules/Unity/Application/application_manager.cpp:ApplicationManager::authorizeSession
<mlankhorst> ok
<mlankhorst> thanks
<seb128> hey
<seb128> is it possible to start a demo mir server somewhere while keeping the an xorg/unity7 session running?
<seb128> I tried to "sudo mir_demo_server_shell --vt 1" and switch to vt1 but I couldn't come back (or there is a bug with my i965 which bugged the machine)
<greyback> seb128: that used to work, lemme try
<seb128> greyback, thanks
<greyback> seb128: yep worked here
<greyback> seb128: ctrl+alt+backspace quits the mir server
<greyback> as it tends to ignore Crtl+C in the console that started it
<seb128> greyback, thanks
<seb128> greyback, can you ctrl-alt-f1 ctrl-alt-f7 to switch between mir and unity7?
<greyback> seb128: yes
<seb128> greyback, k, thanks for that and for the email ;-)
<greyback> seb128: thought it might be handy
<seb128> it is indeed :-)
<greyback> seb128: while I've got you, somehow unity7 isn't showing up as an option in my lightdm Greeter. Only unity8 is there. ubuntu-desktop is installed. Any ideas?
<seb128> greyback, install ubuntu-session
<desrt> seb128: getting the server working is another issue...
<desrt> seb128: you need to change ownership of the socket and symlink it to the correct location in your user's xdg_runtime_dir (or set env variables to work around)
<greyback> seb128: it is installed
<seb128> greyback, weird then, is "unity" installed?
<greyback> yep, it is
<seb128> hum
<greyback> I'm a tad confused
<greyback> but it's not end of world, it's my unity8 desktop machine anyway
<seb128> do you have anything useful in /var/log/lightdm/ ?
<seb128> x-0-greeter.log
<seb128> desrt, do you know if there is a wikipage or something about the socket thing?
<mlankhorst> that the greeter doesn't use mir makes things hard for me. :P
<desrt> seb128: no.  i don't.
<desrt> seb128: unfortunately this is sort of something that everyone has to discover for themseelves....
<desrt> seb128: also: you need to run the server as root
<seb128> desrt, the email I crossed had those instructions
 * desrt has burned half an hour or so figuring these things out, twice (after having forgot the first round)
<seb128> sudo mir_demo_server_shell --vt 1
<seb128> sudo env XDG_RUNTIME_DIR=/run/user/1000 MIR_SOCKET=/tmp/mir_socket
<desrt> oh.  nice.
<seb128> the second command is missing the <command>
<desrt> that's a strange combination of environment variables :)
<seb128> but you are saying that's not going to be enough?
<desrt> you need to change ownership of the socket if you wnat to connect as a normal user
<seb128> k
<seb128> I'm fine running the command under sudo
<seb128> but thanks for the hint
 * desrt has had a couple of outstanding requests to improve the situation here...
<desrt> seb128: 'don't gtk as root' ;)
<seb128> desrt, on a test laptop EDONTCARE ;-)
 * greyback has todo item to write up this stuff, sorry hasn't got it done
<seb128> that would be useful
<seb128> http://unity.ubuntu.com/mir/ doesn't have a lot of useful user informations
<mlankhorst> it seems to be hard to run your own unity8 currently..
<mlankhorst> at least when not going through lightdm
 * desrt is reminded that he has been meaning to file some bugs, and does so: https://bugs.launchpad.net/mir/+bug/1398038 and https://bugs.launchpad.net/mir/+bug/1398039
<ubot5> Launchpad bug 1398038 in Mir "need nested mir (in X) server" [Undecided,New]
<ubot5> Launchpad bug 1398039 in Mir "test servers should have commandline options for socket owner, location" [Undecided,New]
<racarr> Morning
<greyback> seb128: extremely messy, but here's the biggest of my notes on unity8/mir http://pad.ubuntu.com/using-mir
<seb128> greyback, thanks
 * alan_g finds mir doesn't build today
<kdub> alan_g|tea, what's not building
<seb128> https://errors.ubuntu.com/problem/318a0132ff5aca50838dfffb9bdbe88d1edebf01 is showing on e.u.c for vivid
<seb128> hitting abrt in mir_connection_create_surface()
<alan_g> kdub: it turns out to be vivid migration detritus
<seb128> (just pointing it, dunno if you guys watch e.u.c)
<alan_g> seb128: not sure where that report originates, but a test called "createing_surface_on_garbage_connection_is_fatal_Test" forking a process that aborts doesn't seem like anything to worry about
<racarr> New rev for mir-event-2.0 :)
<seb128> alan_g, right, it's still generating some noise on the error tracker so would be good to fix/disable
<alan_g> seb128: I've not looked closely, but we have a number of tests whose purpose is to ensure an abort occurs when required. Are you suggesting that we shouldn't test those scenarios?
<seb128> alan_g, hum, no, I just wonder if we could do something to avoid getting e.u.c reports for them
<seb128> that's kind of low importance though, so feel free to ignore me ;-)
<alan_g> If you can suggest a way to do that in Mir I can follow it up. Otherwise...
<seb128> good point
<seb128> I'm going to investigate if that's possible, thanks ;-)
<kdub> camako, was thinking about how you mentioned that you were looking through the platform code in trying to not tear down the display system on compositor start/stop
<kdub> I can point to what android is doing there if that helps
<kdub> but it seems to mostly be something the server is doing
<kdub> and perhaps some improvement has to be done to the mesa platform too
<camako> kdub, thanks. I looked at Android side, and am now looking at the Mesa side which is more involved.
<kdub> camako, yeah, the android side its easy to keep the display around... iirc, the mesa side has some complication with VT's
<racarr> camako: Thanks for your comments on event-2.0 will get back toyou right after lunch
<RAOF> desrt: Oh, I was wrong about how much done eventloop fds is; it's much closer to finished than I thought :)
#ubuntu-mir 2014-12-02
<mlankhorst> RAOF: yay, can I kill xmir-thread-proxy then? :P
<alf__> duflu: @unfreeze-1, can I see the effect of this branch on the desktop too with full screen glmark2, or only on the phone?
<duflu> alf__: Both (or in fact now only desktop since the workaround landed). bypass and overlays both have the same extra buffer requirement
<alf__> duflu: thanks
<duflu> mlankhorst: I'm a bit rusty on the subject.. do you know how long vblank actually lasts?
<duflu> I think it's only a couple millisec at most?
<mlankhorst> yeah
<mlankhorst> why?
<mlankhorst> might be less with reduced blanking
<duflu> mlankhorst: Just thinking about optimizations. And thinking I can rule out trying to do all rendering during vblank
<duflu> mlankhorst: What's "reduced blanked" used for?
<duflu> "reduced blanking"
<mlankhorst> less bandwidth requirement since there's no point in sending a blank signal for long on an old crt..
<mlankhorst> nobody has a crt any more, it's all digital ;)
<duflu> mlankhorst: Oh custom modes, as in Xorg?
<mlankhorst> https://en.wikipedia.org/wiki/Coordinated_Video_Timings#Reduced_blanking
<mlankhorst> no it's a standard
<duflu> mlankhorst: Thanks. I estimate vblank is typically around 1ms then
<duflu> Sometimes
<duflu> That's useful
<duflu> So we must always page flip or be efficient to reprogram CRTCs quickly
<mlankhorst> Or use atomic modesetting :P
<mlankhorst> will be there in time for final mir release ;-)
<duflu> greyback_: WM status: Making another attempt at building default policy into libmirserver this week.
<duflu> And about to make an attempt at dinner
<greyback_> duflu: ack. I've nothing of consequence to contribute
<duflu> greyback_: Sounds positive. :/ OK then, night.
<greyback_> enjoy
<mlankhorst> why doesn't mir use render nodes when available?
<greyback_> alan_g: sorry I got the MRs mixed up, but yeah I was testing https://code.launchpad.net/~alan-griffiths/qtmir/new-migrate-to-mir-Server-API/+merge/243177 on my laptop and unity8 failed to start with it installed
<alan_g> greyback_: ack. I was just looking. BTW please tell me that "// FIXME(gerry) this will go very bad for >1 display buffer" has nothing to do with the problem.
<greyback_> alan_g: that refers to qtmir not supporting multi monitor. Not the problem here unfortunately
<greyback_> or fortunately..
<alan_g> I thought so. But I thought I'd ask as you're here.
<mlankhorst> hm weird
<mlankhorst> is anyone else running into the nesting limit of mir?
<alan_g> I've not tried it recently, but I have had 7 levels of nesting going on an N4 before getting bored
<mlankhorst> I'm testing on amd64, fails on the 4th level :P
<mlankhorst> http://paste.debian.net/134556/
<mlankhorst> last one fails with:
<mlankhorst> get chip id failed: -1 [13]
<mlankhorst> param: 4, val: 0
<mlankhorst> [intel_init_bufmgr:1068] Error initializing buffer manager.
<mlankhorst> in interests of simplicity I was debugging with Xmir, none of my breakpoints on the host or first level nesting fire on drmAuthMagic :/
<mlankhorst> 3rd level being xmir, fourth being glxgears. those work at least..
<mlankhorst> hm I guess I could do hardmode and force xmir to open a new fd for itself, reduces debugging by 1 :)
<mlankhorst> yeah, fails slightly faster.. mir_connection_drm_auth_magic is not handled correctly in nested case I guess..
<alan_g> greyback: is there a Qt-style approach you'd favour to https://code.launchpad.net/~alan-griffiths/qtmir/new-migrate-to-mir-Server-API/+merge/243177 -c290
<alan_g> (I'm still trying to confirm that the race fixed there is the condition you encountered.)
<greyback> alan_g: what you've got there is fine. Like we tend to prefer QMutex to std::mutex and things like that, but it's not essential
<attente_> the event time in mir is measured in nanoseconds?
<attente_> ok, seems to be the case
<Trevinho> attente_: yep, it's mir_event /= 1000000 to get what gdk likes ;)
<Trevinho> RAOF: hey, do you have any idea why doing https://github.com/GNOME/gtk/commit/37ad6e11477060c74c2818210583b6fa37b1b027?diff=split (so submitting all the modified quads in a single VBO), breaks things in gdkgl?
<attente_> Trevinho: thanks, just saw your change
<Trevinho> attente_: maybe adding a #define for that might have been nicer
<attente_> Trevinho: yeah, that sounds good
<kdub> camako, yeah, the android side its easy to keep the display around... iirc, the mesa side has some complication with VT's
<kdub> camako, sorry, hit up+enter from yesterday
<camako> :-)
<greyback> bschaefer: ping
<greyback> oO what have I done
<greyback> bschaefer: ping?
<bschaefer> greyback, pong
<greyback> bschaefer: hey, I want to test your SDL work (to finally review https://code.launchpad.net/~brandontschaefer/qtmir/correct-xrgb-support/+merge/238937)
<bschaefer> greyback, sweet
<greyback> bschaefer: do I need to build anything?
<greyback> and can you gie me name of a game or 2 I can test
<greyback> I would like to see what's needed to have Qt support mir_pixel_format_xrgb_8888 on big endian platforms
<bschaefer> greyback, that actually doesn't fix the issue :(
<greyback> ah
<bschaefer> i tested the fix me self, thought would be nice to get another set of eyes
<greyback> bschaefer: but it's something I can help with
<bschaefer> greyback, right soo
<bschaefer> greyback, a game hmm
<bschaefer> greyback, for the phone you'll need a game that actually *fits* the size of the phone
<bschaefer> which the only one that actually exists in main is scumvm
<bschaefer> greyback, but its easier just to hack the size of the tests the come with the sdl branch
<greyback> bschaefer: ok, I'll take the sdl branch. I need a custom branch?
<bschaefer> greyback, yeah
<bschaefer> Trevinho, what changes did you make to that branch?
<bschaefer> or should i just give him my other one :)
<Trevinho> bschaefer: ehm, what?
<bschaefer> Trevinho, your sdl1.2 branch :)
<bschaefer> greyback, mine: lp:~brandontschaefer/+junk/sdl1.2-mir
<bschaefer> Trevinho, fixed some memory issues i had in mine IIRC
<Trevinho> bschaefer: nice, did you include also the fixes for resolution stuff?
<bschaefer> Trevinho, nope, i was wondering if we should just give greyback your branch
<bschaefer> as its *more* up-to-date
<Trevinho> bschaefer: not sure, as you prefer
<bschaefer> greyback, just use mine for now, until i can see what was changed :)
<Trevinho> greyback: mine is at https://code.launchpad.net/~3v1n0/+junk/sdl1.2-mir
<greyback> ok
<bschaefer> greyback, soo what you'll need to do on the phone
<Trevinho> greyback: if you get crashes with it (as I had), just use mine :)
<bschaefer> ./configure --disable-video-opengl
<Trevinho> it's basically the same, but with few fixe
<bschaefer> by adding that to debian/rules
<bschaefer> greyback, let me double check if i did that already
<greyback> bschaefer: why disabling opengl? no gles support?
<bschaefer> no i haven't :(
<bschaefer> greyback, this is true, are you running on the desktop?
<greyback> ok
<bschaefer> or the phone?
<greyback> I'll be doing both
<bschaefer> for the phone you'll need to disable opengl, as SDL1.2 does NOT support gles
<bschaefer> and if you include opengl
<bschaefer> it thinks its supported on the phone
<bschaefer> since the headers exists
<bschaefer> (annoying but idk the correct fix for that one)
<Trevinho> bschaefer: btw the main thing you should incluide in your branch is http://bazaar.launchpad.net/~3v1n0/+junk/sdl1.2-mir/revision/13
<Trevinho> as in the desktop it will lead to crashes
<bschaefer> Trevinho, ooo yeah
<bschaefer> Trevinho, i realized this later when doing glfw but i've not changed that in sdl1.2 :)
<bschaefer> thanks!
<bschaefer> greyback, but pretty much, let me know when something isn't working :)
<bschaefer> and i can help you haha
<greyback> bschaefer: will do
<Trevinho> bschaefer: np... I've tested with wormux and mplayer and both works well with it...  Although the sdl1.2 fullscreen way seems quite oldish (it basically tries to change the resolution instead that increasing the window size)
<bschaefer> good luck!
<greyback> I've enough to play with for now
<bschaefer> cool
<greyback> bschaefer: and sdl2?
<bschaefer> greyback, sdl2... i've not seen any color issues
<greyback> bschaefer: ok, and it just works?
<bschaefer> greyback, but its not using software renderering
<bschaefer> it uses opengles on the phone, which might be *why* its working
<bschaefer> greyback, i can test that out
<bschaefer> greyback, but pretty much yes, SDL2 is a more completed port, and its also upstream :)
<greyback> bschaefer: ok. What would you run to test it?
<greyback> I just want to know these things so I test qtmir with them
<bschaefer> hmm theres no great SDL2 examples, i've a few of my own
<bschaefer> but theres tests in sdl2 it self
<greyback> ok, those will do nicely
<bschaefer> greyback, or this haha: https://github.com/BrandonSchaefer/SDLMazeGenerator
<bschaefer> it just generates mazes
<bschaefer> in SDL2
<greyback> perfect
<bschaefer> it looks pretty, but it depends on a backend thingy:
<greyback> so I see
<bschaefer> https://github.com/BrandonSchaefer/SDLBackend
<greyback> no biggie
<bschaefer> greyback, pretty simple thing, i was just using that for most of my examples i've floating around
<bschaefer> mainly to test SDL2
<greyback> bschaefer: great, thanks. If I've problems I'll be in touch :)
<bschaefer> greyback, sweet, good luck! (also that MazeGenerator has the WIDTH/HEIGHT hard coded in. at ui/Main.cpp)
<greyback> ack
<alan_g> greyback: where does the unity8 log go?
<greyback> alan_g: ~/.cache/upstart/unity8.log
<greyback> alan_g: note lp:~alan-griffiths/qtmir/new-migrate-to-mir-Server-API running nicely now, just need to check one thing
<alan_g> greyback: interesting (I won't mention it crashes strangely for me...)
<greyback> alan_g: does it? Maybe I should test more...
<alan_g> greyback: but I'm having trouble running u8 even without my changes - so it may be unrelated.
<alan_g> But please do test some more
<greyback> will do
 * alan_g isn't sure how to test u8 and is prepared to believe greyback's results over his own for now.
<alan_g> greyback: false alarm: It is the "refactored" branch that is crashing for me. The new-migrate-to-mir-Server-API branch seems stable.
 * alan_g forgot a "push"
<alan_g> greyback: BTW is there a way to exit a u8 desktop session? (other than killing it from a VT)
 * alan_g starts to dislike qmake
<RAOF> Trevinho: Breaks gdkgl in general, or only under Mir?
<Trevinho> RAOF: under mir
<Trevinho> RAOF: basically I get corrupted textures (well 2d textures), while the gl area is still working fine
<Trevinho> by 2d textures I mean the cairo surface that should be drawn through gl, while the opengl view (for example, the classic gl gears) that are embedded works fine
<RAOF> There didn't seem to be anything there that would interact directly with anything Mir-specific...
<Trevinho> RAOF: exactly... It only just changes the things so that it submit them at once or per each quad
<Trevinho> RAOF: but for some reason that change breaks gdkgl in mir... at least in my setup (it would be even more weird if that could be driver specific)
#ubuntu-mir 2014-12-03
<mlankhorst> huh
<mlankhorst> why would unity8 give me a surface that has slightly more width than the screen?
<mlankhorst> New size: 1366x742
<mlankhorst> while the screen is 1360x768
<mlankhorst> oh no, it's 1366 after all, wonder why it says 1360 then..
<greyback> mlankhorst: a unity8 bug most likely. I'm aware of a bug where the surface height you end up with is 4 pixels too tall (for non-fullscreen surface)
<mlankhorst> oh no, it might be some thing I need to workaround in xmir, bug in the resolution stuff
<duflu_> mlankhorst: Interestingly Xorg also reports physical dimensions (xrandr) completely wrong. Mir does not
 * duflu_ wanders off
<mlankhorst> shrug :P
<mlankhorst> I'm fighting with Xmir atm, getting some nice interactions where u8 resizes my newly created Xmir window and I currently don't handle that. I need to detect the case where Xmir runs in a window and handle xrandr differently there..
<mlankhorst> can I detect the window is created with a different somehow? the resize event seems to be delayed..
<greyback> mlankhorst: unity8's window sizing is a bit flawed right now. When clients requests surface, it is given fullscreen surface. Then when first frame is swapped, does unity8 resize surface to what is wants
<greyback> so you always get a resize event shortly after surface creation
<mlankhorst> ok, that would explain things..
<greyback> known issue, I have code to fix it, I need to resurrect it and land it
<mlankhorst> that would really help me. :P
<greyback> mlankhorst: ok, let me do that today.
<alan_g> greyback: are you now happy with my qtmir changes? (I tracked down my problems to PEBCAK)
<greyback> alan_g: I am, just need to check one thing and then I can TA the new-migrate. Will then move onto the refactor, but from my initial look there was nothing controversial
<alan_g> greyback: great
<mlankhorst> greyback: but that could open another bug, until I call mir_surface_set_event_handler I can't process messages from the surface
<mlankhorst> so if you fix it will it be race-free?
<greyback> alan_g: can you answer that? ^^
<greyback> mlankhorst: my understanding is when client calls mir_connection_create_surface with certain geometry defined in MirSurfaceParamters, the MirSurface returned should be checked again by the client to see the geometry it is given - as they may not be the same.
<mlankhorst> yeah, unfortunately I don't see a call to do so..
<greyback> mlankhorst: mir_surface_get_parameters should do it
<alan_g> mlankhorst: what race are you concerned with?
<alan_g> the size of the surface you have is available locally (as greyback says) and needs to be checked
<mlankhorst> what call gives me the size then?
<mlankhorst> oh right, the MirGraphicsRegion
<mlankhorst> but that only works for cpu rendering, not gl
<mlankhorst> oh nm, found it
<greyback> alan_g: all approved, many thanks
<alan_g> greyback: thank you.
<rsalveti> kgunn: kdub: hey, have one question about mir and the input system and events, who knows more about that?
<rsalveti> basically I want to understand what is the flow for the evdev events we get on our devices
<kgunn> rsalveti: racarr and anpok
<rsalveti> I know the shell is the one handling all the input, probably via mir
<kdub> probably racarr in this timezone
<rsalveti> cool, thanks
<rsalveti> hm, no racarr around
<kgunn> rsalveti: he's just gone for lunch...
<rsalveti> cool, will ping him later then, thanks!
#ubuntu-mir 2014-12-04
<duflu_> Hmm, is CI really asleep now? I guess it will take some hours to be sure
<rsalveti> racarr: still around?
<rsalveti> racarr: do you know who is the one responsible for sending the input events to qt and then shell?
<rsalveti> racarr: just trying to understand the big picture
<rsalveti> my problem is that I'm getting KEY_PLAYPAUSE from the input device (kernel level), but I'm not getting Qt::Key_MediaTogglePlayPause in Qt, but getting another event id instead
<rsalveti> same for KEY_MEDIA
<rsalveti> I'm checking that in the qml available for the shell
<rsalveti> I know mir is handling the input events, but don't yet know how that works with the rest of the stack
<rsalveti> if it's something like evdev -> mir -> qt -> shell or different than that
<RAOF> rsalveti: That's right; evdev -> mir -> Qt -> shell.
<rsalveti> RAOF: do you know if mir is doing any parsing or filtering of the evdev events before sending that to Qt?
<rsalveti> also, do we need any sort of platform specific backend in Qt to handle the input device messages from Mir?
<rsalveti> this is specifically to touch, not sure if that would be any different from the desktop use case
<duflu> rsalveti: AFAIK we have a lack of key translation, which is a missing feature :)
<RAOF> rsalveti: So, we do some input parsing before feeding to Qt; the bit that you'd be interested in is in qtmir - src/platforms/mirserver/qteventfeeder.{h,cpp}
<rsalveti> awesome
<RAOF> As you see, that implements a mir::input::InputDispatcher, which hooks into the Mir event feeding.
<rsalveti> right, and hooks into Qt
<rsalveti> perfect, thanks!
<racarr> rsalveti: RAOF: By the time unity8 receives it its already gone through USC
<racarr> so the events are fully processed, keys are XKB mapped, etc...
<racarr> also my buffer stream bug is hilariously comical
<racarr> was
<racarr> *swats*
<RAOF> Don't leave us hanging!
<RAOF> racarr: Oh, yeah. That bit too :)
<racarr> RAOF: Haha...its hard to explain. Ok so imagine you are trying to implement
<racarr> ms::BasicSurface::set_cursor_buffer_stream(...
 * RAOF imagines
<racarr> so I had the idea, ok well, it will just install an adapter object
<racarr> which will register itself as an observer with the buffer stream
<racarr> and each time a buffer appears, create a cursor image from it and
<racarr> just call Surface::set_cursor_image
<RAOF> This seems sensible.
<racarr> yeah not totally insane, not the easiest to make efficient but quick
<racarr> so, this adapter object is a member of the surface
<racarr> ...so in set_cursor_image
<RAOF> ...you take a lock...
<racarr> no haha even sillier
<racarr> I reset the adapter object!
<racarr> because
<racarr> set_cursor_image was a request to switch to
<racarr> an image
<racarr> an uninstall
<racarr> the buffer stream observer
<RAOF> Oooh, yeah!
<racarr> (which you would need to happen if you really did change to a static image)
<racarr> and then the icing on the cake is I eronneously concluded it was client buffer swaps not properly completing
<racarr> by debugging the deprecated SessionMediator::advance_buffer function
<racarr> lol
<RAOF> Hah. Gold!
<racarr> classic comedy lol
<racarr> ok thats good though
<racarr> then tomorrow morning I can focus on cleaning it up and in the afternoon
<racarr> on client clean up
<racarr> omg I never ate dinner
<RAOF> Ooops!
<racarr> hmm
<racarr> the Qt::Key_MediaTogglePlayPause problem must just be
<racarr> the static table in qteventfeeder
<racarr> however for clients...
<racarr> there is the other table in qtubuntu
<racarr> but how does (Qtmir::)MirSurfaceItem::consume
<racarr> work
<racarr> e.g. do we translate xkb key code -> qt key code -> back to xkb
<racarr> or is it broken and clients can't receive things like media keys
<racarr> for most things it will work because xkb key sym corresponds
<racarr> with qt keycode
<racarr> corresponds with unicode code point
<racarr> but media keys, etc are the exception and thats what the table is for
<racarr> *looks*
<racarr> ah not cool, qt tracks the "native virtual key"
<racarr> no* cool
<racarr> and thats used to reconstruct
<racarr> the mir event
<racarr> rsalveti: It should work if you add it to the top of the table at qteventfeeder.cpp
<racarr> WHAT TO EAT
<duflu> racarr: While you are cursor tinkering... it's occurred to me that a cursor isn't just per-surface but also varies between tools. E.g. mouse vs stylus vs finger touchpoints. They could (should) have different appearance
<duflu> When playing with a stylus I thought it would be nice if the cursor on screen showed which tool actually produced the last event to move the cursor
<racarr> mm maybe
<racarr> I think shells should be able to implement that
<duflu> racarr: Yeah definitely shells/clients pick the images. But you have to tell them from the server what the tool is
<duflu> But before all that, we would need to teach Android input how to move the cursor with tools other than the mouse
<duflu> Because it doesn't want to
<racarr> yeah, after we transition out old MirKeyEvent and MirMotionEvent
<racarr> im looking forward to starting to unwind this by differentiating
<racarr> MirTouchInputEvent and MirPointerInputEvent
<duflu> racarr: Which is a hovering stylus? :)
<racarr> and all the various combinations of synthesis required to support, synaptics, pointer emulation, wacom<->pointer, etc.
<racarr> duflu: Well, in this case if the stylus was configured for pointer emulation
<racarr> you would first receive the "raw" MirTouchInputEvent
<racarr> and it would have a non null
<racarr> "synthesized_to" member
<racarr> which is the ID, of an event which you can expect immediately
<racarr> synthesized from the event
<racarr> and the client can choose to interpret it
<racarr> as a touch
<duflu> Hmm, I've got another semi-broken laptop with stylus. I think it turns on now... so will try that
<racarr> or interpret the cursor motion in the synthetic pointer event
<racarr> I mean it definitely
<racarr> doesnt work at the moment haha
<duflu> racarr: I like how it works now (stylus is like a finger). Just want a cursor shown during hover
<RAOF> Hm.
<RAOF> I don't think you want per-tool cursors.
<RAOF> But mainly because only the mouse - virtual or otherwise - has a cursor.
<RAOF> Touchpoints obviously don't get cursors; the stylus likewise.
<RAOF> (Unless it's manipulating the virtual mouse cursor, but in that case see virtual mouse cursor)
<duflu> RAOF: I can see a cursor for the stylus in X. But would prefer it looked different to the mouse
<RAOF> How would that work?
<RAOF> The cursor would change depending on what input device you touched?
<duflu> RAOF: Change the cursor to match whatever tool caused it to move last
<RAOF> That's possible, I guess, but why would you ever want to do that?
<RAOF> It always does the same thing.
<duflu> RAOF: It's a subtle bit a feedback that makes the user more comfortable that the system understands what they're doing
<duflu> An arrow for the stylus looks kludgy
<RAOF> Maybe, I guess?
<duflu> And may be visibly annoying too (too big)
<duflu> Man, I'm digging myself in. This branch went from just implementing fullscreen to doing half the WM spec
<duflu> Still in under 1000 lines :)
<RAOF> If you're using the stylus for anything stylus-y then you won't have the arrow, anyway?
<RAOF> It might be useful; I suspect that it'll actually appear weird.
<duflu> RAOF: If you're using the stylus primarily then you don't want to switch to mouse to click a button. So you have to see where you're aiming
<RAOF> Right, but why would you want the cursor to be smaller when you're using the stylus?
<duflu> RAOF:  I guess I'm imagining that a paint app forgets to change its cursor
<RAOF> :)
<mlankhorst> does eglSwapBuffers block?
<mlankhorst> or what call should I use to check when a new mir surface is available for rendering
<mlankhorst> oh seems to block then..
#ubuntu-mir 2014-12-05
<racarr_> ah hmm...it's difficult to write to a buffer you get on the server side via compositor_acquire because you get
<racarr_> the temporary compositor buffer and can't
<racarr_> cast to the platform implementation type...
<racarr_> (its difficult because im using the BufferWriter strategy...now BufferAccessor...) this seems to be an argument for buffer::read :)
<RAOF> I don't think that you can, in general, read from a Buffer.
<RAOF> Heh. You live and learn.
<RAOF> Also, whoops. 10â¶ ns in 1 ms.
<racarr_> NO EXPONENTS IN IRC
<racarr_> *smacks with ruler*
<racarr_> wheee
<racarr_> animted cursor :)
<RAOF> Whoot!
<racarr_> *sends application to guiness book of world records*
<racarr_> Most banjos restringed during full mir compile: 1.5
<racarr_> I await my challenger
<RAOF> I wonder how much people would care if we added a glib dependency in Mir users.
<RAOF> It'd be kinda nice to be returning GSource-s rather than needing to re-roll the same thing over again.
<racarr_> RAOF: I'd +1 that
<racarr_> but in my mind GLib is effectively libc ;)
<RAOF> Well, we already have a runtime dependency on glib...
<RAOF> Hm.
<RAOF> I think I will do that.
<duflu> RAOF: What's glib being used for now?
<RAOF> duflu: GLibMainLoop
<duflu> RAOF: That's old news(?)
<RAOF> Oh, as in - what do *I* want to use it for?
<RAOF> GSource
<duflu> I'd forgotten how quickly things land without CI :)
<duflu> The good old days of living dangerously
<RAOF> Man.
<RAOF> *Again* I confuse nsec with msec.
<racarr_> y u no std::chrono
<racarr_> (C API presumably :()
<RAOF> Oh, well. That's EOW for me.
<RAOF> mircva::InputReceiver is *very nearly* a functioning GSource.
<racarr_> nifty
<RAOF> GSource is pretty cool.
<RAOF> For the eventloop integration thing I think I'll just export GSources directly via libmirclient-glib.
<RAOF> But anyway, EOW.
<racarr_> bye :) happy weekend
<mlankhorst> RAOF: can i use it in xmir too?
<tsdgeos> anpok_: racarr_: ping?
<tsdgeos> or anyone else, is there a way to get the log of the raw x,y of the touch presses mir gets?
<tsdgeos> i tried exporting MIR_SERVER_INPUT_REPORT=log
<tsdgeos> but the only thing i get is
<tsdgeos> [1417781333.496738] (II) input: Received event finished seq_id=102 src_fd=89
<tsdgeos> which isn't much interesting
<alan_g> tsdgeos: is mir_demo_standalone_input_filter of any use (despite its name it is a demo *server* that dumps input events)
<tsdgeos> alan_g: probably not, i have a situation with autopilot+unity8 in which i think some touch events are being delivered wrong somewhere
<tsdgeos> but i need unity8 to run so i can run autopilot so probably mir_demo_standalone_input_filter is not seful
 * alan_g doesn't know (but thinks you asked the right people)
<anpok_> tsdgeos: hm did you export that for usc?
<anpok_> because unity8 is nested
<tsdgeos> anpok_: ok, let me see if i restart usc then
<anpok_> and the input gets fed directly from the nested surface to the qt input dispatcher and I think it wont be logging its contents..
<tsdgeos> anpok_: where do usc logs end up?
<anpok_> it ought to end up in /var/log/lightdm/unity-system-compositor.log
<tsdgeos> anpok_: do i just kill and start it? or is it driven by upstart too?
<anpok_> hm restart lightdm should do it
<tsdgeos> oki
<anpok_> oh InputReport might not be helpful enough
<tsdgeos> oh :/
<alan_g> anpok_: @"not helpful" the interface or the default implementation? (I'm looking for motivating examples for allowing customizing the reports and we should try to get the interfaces right)
<anpok_> alan_g: hm i think the interface here.. it does not get the position
<anpok_> i believe we log it somewhere else
<anpok_> through the legacy input report
<tsdgeos> anpok_: do you know the lower place i could put a printf of the x,y positions?
<tsdgeos> to see if it's mir or wathever is below?
<tsdgeos> is that android already?
<anpok_> we have that.. hmm but where
<anpok_> tsdgeos: MIR_CLIENT_INPUT_RECEIVER_REPORT=log for unity8
<tsdgeos> ok, let's see
<anpok_> this would be what unity8 receives from usc
<anpok_> and you can basically do the same for a client of unity8 to see how that event got dispatched to it..
<tsdgeos> food first!
<alan_g> alf__: I've been looking at migrating render_surfaces (mostly out of curiosity to see what stops it being a valid example). There's just one nasty: "surface_pf = the_buffer_allocator()->supported_pixel_formats()[0];" as we don't expose the buffer allocator. Can you think of a better way to get a valid pixel format?
<alf__> alan_g: No. Perhaps this indicates a gap in the new API, since without a pixel format the shell can't create its own surfaces.
<alan_g> Indeed. But I'm not sure GraphicBufferAllocator is the interface that should be exposed to support this?
<alf__> alan_g: just the_supported_pixel_formats() ?
<alan_g> Well, that's all we need for render_surfaces and I can't currently see an interface it belongs on.
<alan_g> I'm just not sure mir::Server::supported_pixel_formats() is right
 * alan_g wonders if we should "republish" mir/raii.h
<attente_> hello, does mir support pointer/keyboard grabbing?
<anpok> hm a shell could do that on its own already, but no there is no such thing yet in the client api
<attente_> anpok: is there any plan to add it to the client api?
<anpok> attente_: no idea when... or how urgent that is.. best is to make a bug report to rise attention
<attente_> anpok: ok, thanks
#ubuntu-mir 2014-12-07
<RAOF> attente_: I assume you mean for something like SDL? We're not going to have generic âgrabbingâ, but you'll be able to create âviewportâ surfaces that get the same sort of semantics.
#ubuntu-mir 2015-11-30
<vitimiti> I'm trying to build and run the Unity 8 shell following this tutorial over here: https://unity.ubuntu.com/getinvolved/development/unity8/ but I get an initctl error saying the unity8 process is unknown: http://paste.ubuntu.com/13573548/ Somebody knows how to fix this problem?
<alan_g> vitimiti: try asking on #ubuntu-unity
<vitimiti> I will
<alan_g> anpok: does this make any sense to you? lp:1521225
<anpok> by vivid and wily you mean lp:mir on top of vivid and wily? or specific version of mir?
<Stskeeps> g 20
<alan_g> anpok: lp:mir
<alan_g> It must be a recent change, I would have noticed last week.
<anpok> alan_g: will look into that.. just finishing another problem i found when testing on nexus10 but not limited to it
#ubuntu-mir 2015-12-01
<slvn_> Hi,
<slvn_> Just want to let you know that I have publish a few games, native game based on sdl2
<slvn_> so there are directly using mirclient, through sdl2, and they can be a way to test mir
<slvn_> (indeed, it seemed one app have made mir crashed,  when disconnecting)
<slvn_> so if you want to try, here's the link : https://uappexplorer.com/app/com.ubuntu.developer.1bsyl.cartes
<gatobaubau> slvn_, hehe i have almost all of them installed :))
<gatobaubau> slvn_, negative space is really nice
<slvn_> thanks, great you enjoyed !
<gatobaubau> slvn_, was it hard to port your games to ubuntu phone? i you also have android versions
<slvn_> usually people gives up quickly with negative space :)
<gatobaubau> they run out of ink )))
<slvn_> not really hard to port .. actually there were developed first under ubuntu and android
<slvn_> there was a few issue with mir ... for orientation .. and couples of bugs..
<slvn_> and, since I use sdl2, I can re-use all the code for all platforms
<slvn_> gatobaubau, I was told then when quitting my app, sometime mir crashed ... maybe you could double check ... because I have no ubuntu-deice :D
<gatobaubau> slvn_, i never had any problems with your apps, i'll check to logs later :P just in case
<anpok> slvn_: hm mir as in the unity8 nested server? or unity-system-compostior? or really a shutdown crash of the application?
<slvn_> I just copy paste, since it's short ...
<slvn_>  qtmir.mir: SessionListener::stopping - this= SessionListener(0xb194a134) session= 0x5f935c
<slvn_>  terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<slvn_>    what():  Failure sending input event : Unknown channel provided
<slvn_> ()
<slvn_> to be confirmed ...
<anpok> ah
<anpok> this is actually possible..  and if not handled by the input dispatcher the server would be affected
<anpok> *plausible
<anpok> hm since qtmir has its own we need to fix that there too
<slvn_> .. don't really understand this :) ... but, maybe one should double check if this really happens with an official version ... my app were a use-case to reproduce this ..
<anpok> well i guess you need to hit the right point in time to trigger the problem.. looking at the code.. it is caused by the fact that the input communication is done in a separate thread and keeps track of active surfaces..
<anpok> and in the case described the component knows that the surface is already gone, before it gets the request to dispatch the event..
<anpok> hmm so I either change the way the input channels of surfaces are tracked and kept alive a little longer or we fix the caller to handle the case..
<anpok> https://bugs.launchpad.net/mir/+bug/1521529
<ubot5> Ubuntu bug 1521529 in Mir "handle failures during input dispatch when client disconnet" [Undecided,New]
<anpok> one of things that could be reworked.. the abstraction around InputChannel is still kind of odd becaue we use the android input framework for that..
<alan_g> sometimes I see line of code that makes me wonder...
<alan_g> if (write(p.write_fd(), "a", 1)) {}
<mcphail> write returns non-zero on error and success, doesn't it?
 * mcphail doesn't have "man" installed on this machine
<alan_g> Yes, but is this really the clearest way to ignore the return code.
<mcphail> Those curly brackets were actually empty? Probably meant to check for success but couldn't understand why write() was still returning true on failure and deleted the block.
<slvn_>   /join #ubuntu-touch
<k1l> is there a daily iso for testing unity8+MIR?
<k1l> the desktop-next daily-live is gone, but that is what most wiki pages link to
<alan_g> k1l: I don't think so (we don't create/publish ISOs etc around here, just churn the code). There is a package: unity8-desktop-session-mir - does that help?
<k1l> i just wanted to give it a test run to see what the state is, while not touching my actual system.
<k1l> (just tested a fedora rawhide iso which should have wayland as default now but that didnt boot to the login/desktop so i was curious what the MIR/unity is doing on my thinkpad hardware)
<alan_g> I guess you could boot a vanilla ISO, and install unity8-desktop-session-mir before switching sessions.
<k1l> will try that, thanks
#ubuntu-mir 2015-12-02
<robin-hero_> Hey all, I bought a SlimPort-HDMI adapter last week, but I can't charge my phone and connect it to an external display at the same time: I've already filled a bug: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1519235
<ubot5`> Ubuntu bug 1519235 in mir (Ubuntu) "Nexus 4 - HDMI-Slimport adapter can't charge the phone and display the screen at the same time." [Undecided,Confirmed]
<robin-hero_> If I remember correctly, it works with Android, but not with Ubuntu
<anpok_> hm it works for me
<anpok_> robin-hero_: the one I use looks more like this one http://www.amazon.com/Yakamoz-Slimport-Adapter-Cable-Lovely/dp/B00H8QIUZG/ref=sr_1_81?ie=UTF8&qid=1449046804&sr=8-81&keywords=slimport
<white_duck> wohoo mir 0.19
<robin-hero_> anpok_, Hmm, I need to relfash Android to test again, If it wouldn't work well with that it it a hardware problem with the adapter.
<alan_g> AlbertA: thanks for picking up the ubsanitizer work, I've been meaning to get around to that but getting distracted..since April :(
<AlbertA> alan_g: no problem, I didn't even know it existed until you mentioned it yesterday :)
<AlbertA> alan_g: no other major reports other that those two bugs I have MPs for... the rest are issues with gmock or a gcc ubsan bug  complaining about non-capture lambdas
<alan_g> If you'd been at the ACCU conference last year you couldn't have missed it. ;)
<alan_g> Well, the last conference (which was this year)
<alan_g> @"issues with gmock" - surprising, I know google are big users of ubsan
<AlbertA> alan_g: apparently fixed in their trunk: https://groups.google.com/forum/#!msg/googlemock/cHSPZfcIwSc/sYAzFl2DCQAJ
<AlbertA> I get various reports of "/usr/include/gmock/gmock-spec-builders.h:1530:60: runtime error: member call on null pointer of type 'const struct ResultHolder'"
<alan_g> AlbertA: I guess we're too late to get an update in vivid. :(
<alan_g> *into
<alan_g> AlbertA: just checking, your bug 1522105 isn't a different manifestation of bug 1514884 is it? (Fix landed recently.)
<ubot5`> bug 1522105 in Mir "NestedServer.display_configuration_reset_when_application_exits segfaults" [Medium,New] https://launchpad.net/bugs/1522105
<ubot5`> bug 1514884 in Mir "There's something racy in NestedServer.display_orientation_changes_are_forwarded_to_host" [Medium,Fix committed] https://launchpad.net/bugs/1514884
<AlbertA> alan_g: probably a different cause now... I tried the tip of lp:mir
<alan_g> OK, just sounded possible as it could have been an affected case.
<AlbertA> alan_g: looks like surface stack is sending a null surface pointer to the observers
<AlbertA> based on the GDB backtrace
<alan_g> I see. If you don't get to it I'll have a look in the morning.
<AlbertA> oh yeah.. SurfaceStack::add_observer drops/reacquires the lock as it loops over the existing surfaces...so that needs fixing
<alan_g> Oh, that looks painful.
<AlbertA> alan_g: yep... the good ol' callback problem...
 * alan_g decided to end the day before getting too interested in solving that one.
<alan_g|EOD> (it doesn't work)
<alan_g|EOD> AlbertA: could it be as simple as copying "surfaces" under lock and looping over the copy?
 * alan_g|EOD => really EOD
<AlbertA> alan_g|EOD: it could but then the observer calls could be out of order: like receiving surface_removed before surface_exists
<AlbertA> which would be odd
<kdub> arm64 vs amd64 makes me go crosseyed
<Saviq> kgunn, tracked down to line 95 in http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/surfaceobserver.cpp#L95
<Saviq> meaning we're getting a nullptr as cursor, and not expecting it
<Saviq> folks, should SurfaceObserver::cursor_image_set_to deal with null pointers? is it expected that we're getting it? see bug #1522117
<ubot5> bug 1522117 in qtmir (Ubuntu) "Unity 8 desktop session "stops" when exiting an X app" [Critical,Triaged] https://launchpad.net/bugs/1522117
<kgunn> anpok: ^
<shiznix> is Wily Mesa supposed to build with Wily Mir, or is this a WIP?
<anpok> Saviq: not expected.. i thought AlbertA working on something similar, but looking through the logs he was after something different
<Saviq> oh so we actually uncovered a mir bug?
<AlbertA> Saviq: maybe it's this? https://code.launchpad.net/~albaguirre/mir/fix-1521795/+merge/279218
<Saviq> AlbertA, definitely sounds related
<shiznix> encountered pkgconfig problem where mesa-11.0.2-1ubuntu4 can't find 'mir-client-platform-mesa-dev' as this was renamed to 'mir-client-platform-mesa' in mir-0.17.0+15.10.20151008.2-0ubuntu1
<shiznix> but once this small typo is smoothed over, mesa fails to build -> http://webcache.googleusercontent.com/search?q=cache:jmRbpw2aKBQJ:pastebin.com/G7pLiWRT+&cd=2&hl=en&ct=clnk&gl=au&client=ubuntu
<shiznix> not my pastebin, but exactly the same build error
<shiznix> and somewhat reassuring that i'm not the only one :D
<shiznix> apologies for the noise if they're not intended to build together yet
<RAOF> shiznix: They are expected to build together; which versions are you building, though?
<RAOF> Ah, mesa 11.0.2 vs mir 0.17?
<shiznix> RAOF: yes :)
#ubuntu-mir 2015-12-03
<alan_g> balloons: ping! <-- alf
<balloons> alan_g :-). So I'm looking at your document for tasks. My only concern is having the dependencies on previous tasks
<balloons> ideally these will be standalone. So I'm trying to think about how we could incoporate the same thing without having a hard dependency
<balloons> as it stands, we'd be limiting who could work on tasks 2 and 3
<alan_g> Well, there needs to be some base code to work with. And even if we took the mir examples as the base there's only one version of that.
<balloons> right. So we could also hold the tasks until each one is completed. So we could not publish task 2 until at least one person has done task 1
<balloons> that might be the simplest thing to do
<balloons> are there other needs within the team? Like simple features or bugs? Documentation needs?
<alan_g> "simple features" isn't so easy for a system library. There needs to be work elsewhere to expose the features.
<alan_g> There are bugs, but the simple ones just get fixed
<balloons> alan_g, yes I know. Something this low level isn't a trivial thing
<balloons> But I figured I would ask. Do you have good documentation in all places?
<balloons> How about having them review the getting started guide; perhaps write a contributing guide?
<balloons> And I do think your idea of using MIR to create some examples is probably the best for coding work
<alf> ogra_: Hi! If we want to ship a config file just on the phone (e.g. a special config file for lightdm) what would be the right package to put it in?
<ogra_> there is a specifc settings package ... /me forgot the name ... to much snappy in my head recently :P
<ogra_> ubuntu-touch-settings ...
<alf> ogra_: great, thanks!
#ubuntu-mir 2015-12-04
<alan_g> alf: what's the reasoning behind DisplayConfigurationTest.hw_display_change_doesnt_apply_base_config_if_per_session_config_is_active? If we (e.g.) unplug a monitor we need to reconfigure, not carry on with a possibly invalid config.
<alf> alan_g: We want to avoid possibly redundant configuration changes to reduce flickering. The idea is that a session that has set a session config will update it once it gets notified about a change.
<alf> alan_g: There were plans to add a timeout, so if the client doesn't update the config "soon" (e.g. it has hung) the server will apply the base config
 * alan_g wonders if we should kill the client
<alan_g> alf: so I should update the recently added DISABLED_given_client_set_display_configuration_when_monitor_unplugs_configuration_is_reset to have the client do the reconfigure?
<mmmcandy> guy, any idea when 0.18 will land in xenial?
<mmmcandy> s
 * mmmcandy can't words
<alf> alan_g: Yes, that's the current expected/supported behavior (until/if we add a timeout)
<alf> mmmcandy: No ETA yet, we are in the process or releasing though. I would say some time next week unless we find a blocking issue.
<mmmcandy> alf thanks :o)
<alf> mmmcandy: 'kdub' is doing the 0.18 release, so if you need more fine grained progress info you could ping him
<DimitrisGR> exit
<kdub> mmmcandy, the release silo is here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 maybe another week or so
<kdub> in the testing phases
<DimitrisGR> hello all, I have just built Mir, I try to run the demo_server and I get the error: "Error:libmir_demo_server_loadable.so: cannot open shared object file: No such file or directory"
<DimitrisGR> I tried "whereis libmir_demo_server_loadable.so" and the file exists in "/usr/local/lib/libmir_demo_server_loadable.so"
<alan_g> DimitrisGR: can you pastebin the full output?
<DimitrisGR> alan_g: the only output is this line "Error:libmir_demo_server_loadable.so: cannot open shared object file: No such file or directory"
<DimitrisGR> alan_g: i don't know if you want to run something else
<alan_g> Exactly which executable are you running?
<DimitrisGR> i follow this http://unity.ubuntu.com/mir/demo_server.html and i run "sudo mir_demo_server"
<alan_g> What does "sudo which mir_demo_server" say?
<DimitrisGR> Error:libmir_demo_server_loadable.so: cannot open shared object file: No such file or directory
<alan_g> What does "sudo which mir_demo_server" say?
<DimitrisGR> what do you mean? that's the output i get when i run it
<DimitrisGR> oh sry
<DimitrisGR> i did not see the "which"' :P
<DimitrisGR> it says "/usr/local/bin/mir_demo_server"
<alan_g> does mir_demo_server --help work? (no sudo)
<DimitrisGR> no, the same error again
<DimitrisGR> I also runned ctest and all the test pass
<alan_g> You've used make to install - and clearly that's broken something.
<alan_g> I use either the built version (e.g. sudo bin/mir_demo_server ...) or the package install and that usually works.
<DimitrisGR> so what do you suggest i should do?
<DimitrisGR> is it a bug?
<alan_g> Well, clearly there's a bug in the "sudo make install" support
<alan_g> But do you actually need that?
<DimitrisGR> i don't know :P i am trying to find an open source project to contribute (newbie here), and mir seemed interesting. so I just followed the steps for "Building the source for a PC"
<alan_g> In that case, don't bother with installing it to play with. Just use the copy in the build tree. (add "bin/" to the commands)
<alan_g> And please report the bug - in the documentation, in the install or both
<DimitrisGR> there is no need to install it? how will i test it, get to know the code better etc if i cannot run it
<alan_g> (Assuming you're in the build directory) try "bin/mir_demo_server --help"
<alan_g> DimitrisGR: I've got to go to lunch now - if no-one else is about I'll be back in around an hour
<mmmcandy> thanks kdub
<kenvandine> anpok, you were doing the work needed to use the mouse and touchpad settings right?
<kenvandine> anpok, how's that coming?  i just heard that's on the list for ota-9
<alan_g> balloons: evidence that there is a useful documentation review task - https://bugs.launchpad.net/mir/+bug/1522836
<ubot5> Ubuntu bug 1522836 in Mir "After "make install" mir_demo_server cannot find shared object file" [Medium,Confirmed]
<anpok> kenvandine: with 0.18 we will have that working in usc/mir
<anpok> then we might need something u8 or qtmir .. need to check with greyback for that
#ubuntu-mir 2016-12-05
<RAOF> You know what would be ace? If our mutexs had some form of documentation of the invariants they're protecting.
<RAOF> Hm. I might have managed megabytes of valgrind output here!
<duflu> Finely valground
<RAOF> Hah. That output gets much more readable if you spread it out over the width of two monitors!
<RAOF> Oh!
<RAOF> Yes, that's right.
<RAOF> MirWaitHandle being terrible.
<duflu> I'm pretty sure MirWaitHandle works perfectly. If it's not perfect then add a regression test for what fails. But we may also not need it...
<RAOF> Right, it works, but it's architecturally horrible.
<RAOF> (Mostly works; it still doesn't distinguish responses)
<duflu> Indeed, it was invented by someone who only envisioned single responses. Then fixed by someone (me) who realised it failed for multiple responses. Then later probably can simply be not mentioned in the client API in future
<duflu> Although I much prefer using a wait object of some form than callbacks. Anything is nicer than callbacks
<duflu> And you could convert a wait object into a callback if it was well designed
<RAOF> I was in favour of foo_begin/foo_complete at the beginning.
<RAOF> That would be nice wait-objects :)
<RAOF> Oh, dear.
<RAOF> Mocks.
<RAOF> Oh, good.
<RAOF> Pulling in more recent trunk and resolving the conflicts *also* resolves some of the test errors. Yay!
<RAOF> Woot!
<RAOF> Now down to 5 sets of failures.
<alan_g> dandrader: would this address some of your concerns about moving child windows? https://code.launchpad.net/~alan-griffiths/miral/fix-1646735/+merge/312447
<dandrader> alan_g, will comment on the mp
<alan_g> greyback: your position on this? https://code.launchpad.net/~alan-griffiths/miral/fix-1646735/+merge/312447/comments/811089
<greyback> alan_g: needed to give it a think. Yep I think your suggestion is worth a go (commented as much)
#ubuntu-mir 2016-12-06
<RAOF> The best thing about mocking is that you encode all the implementation assumptions into hard-to-reason-about implicit state!
<RAOF> Yes!
<RAOF> Now with (hopefully) *all* the tests satisfying the assumptions of the code!
<RAOF> Hm. I wonder how deep a stacktrace I can create before it all falls in a heap?
<RAOF> Current winner is 63 frames deep.
<duflu> anpok: Feels like the default mouse acceleration has changed to flat. Did you do that or did upstream libinput? Not complaining... it's actually what I wanted :)
<duflu> At least I think it has changed...?
<duflu> Or did Xorg just start using the same profile and I got used to it?
<duflu> Maybe the libinput curve just became less bad than it used to be?
<duflu> Oh crap. It's probably just a side-effect of the kernel bug which prevents high resolution mouse input now (usbhid.mousepoll=1). So as a result the feel is a bit different
#ubuntu-mir 2016-12-07
<RAOF> Why hello, odd bug.
<RAOF> Why isn't disconnect() being responded to?
<RAOF> Oh, goodie. It's somehow a race?
<RAOF> AAAaaaah.
<RAOF> It's a race between mir_render_surface_release and mir_connection_release.
<RAOF> Hm.
<RAOF> Why do we ignore logical_width and logical_height for bufferstreams in mir_surface_spec_add_render_surface?
 * duflu shrugs
<RAOF> Ah.
<RAOF> The reason why the tests don't *currently* deadlock in that race is because they race allocate_buffer instead.
<duflu> RAOF: I think I'm overallocated for features this cycle. Do you want to take one of my major items off my hands?
<RAOF> duflu: Whatta ya got?
<duflu> (fbdev + osmesa || SimpleDRM kernel work)
<duflu> The first one is just a Mir driver
<RAOF> The second one is driving an already roughly-agreed-to patch through lkml.
<duflu> Indeed, but it's been driving for a few years
<duflu> Not sure how long to wait
<duflu> Perhaps if we do nothing the feature will exist :)
<RAOF> Patch set v5 got submitted by a drm guy in September.
<duflu> To me fbdev would be fun to learn driver development. And it would work on any kernel... assuming osmesa works
<duflu> But that's just me
<RAOF> Why would fbdev involve learning driver development?
<duflu> RAOF: Mir driver development
<RAOF> Ah, right.
<duflu> I know the basics... I was building something similar back in the early 90s before I got distracted
<duflu> RAOF: I just figured you know all the parts. If we were to build a fallback driver to solve all the fallback problems before 17.04 you would be able to do it
<duflu> And working in any VM out of the box would be awesome
<duflu> It's assigned to me, but before then I need to finish client-side vsync and probably now do GL-based display cloning
<duflu> So there's a reasonable risk I won't have all three features done before 17.04
<RAOF> Seems reasonable.
<RAOF> I'll see where SimpleDRM is at.
<RAOF> Because if it's done, that's the cheapest option :)
<RAOF> And, indeed, looks like simpledrm has landed.
<duflu> Not in Linus' tree. Which one comes before that for DRM work?
<RAOF> In whatever tree all the patches to drm-devel are applied to.
<RAOF> I'm actually not sure what tree that is.
<duflu> You always need to know who the second in command is, per component
<duflu> The kernel docs say who
<RAOF> Yeah, it's drm-misc. I thought so.
<RAOF> Can't see it in there, though.
<RAOF> Which is odd, because I see unrelated patches that patch simpledrm.
<RAOF> Hey, cool! rr will now record mir_acceptance_tests!
<duflu> And I thought Unix already took all the two letter names
<duflu> RAOF: Is it intentional or incidental that streams use SurfaceIDs and SurfaceObservers?
<RAOF> Incidental, mostly.
<duflu> Oh I see. We started with just surface and it morphed incrementally into streams
<RAOF> For the former, it might have made sense to have just a single âobject IDâ namespace.
<RAOF> For the latter, SurfaceObserver basically makes sense with Streams, too. :)
<duflu> Indeed
<applemuncy_1> Greetings : )  Is this the right place to ask about mir_android_diagnostic testing and failures?
<greyback> applemuncy_1: yep
#ubuntu-mir 2016-12-08
<alan_g> anpok: IITC you found gtk-mir was ignoring parent when creating modal dialogs? Can you confirm/link here? https://bugs.launchpad.net/ubuntu/+bug/1445543/comments/6
<ubot5> Ubuntu bug 1445543 in Ubuntu "Multi-window GTK apps in Mir are randomly unresponsive, seem to freeze" [High,Incomplete]
<anpok> alan_g: I can remember finding two specific not implemented window changes..
<anpok> one might be changing the parent.. the other one was setting the dialolg to be modal after it was created
#ubuntu-mir 2016-12-09
<robert_ancell> Anyone seen this failure?
<robert_ancell> [  7%] Building CXX object src/platforms/mesa/server/x11/CMakeFiles/mirplatformservermesax11sharedresources.dir/X11_resources.cpp.o
<robert_ancell> In file included from /home/bob/bzr/lightdm-snap/stage/include/X11/Xlib.h:47:0,
<robert_ancell>                  from /home/bob/bzr/lightdm-snap/parts/mir/src/src/platforms/mesa/server/x11/X11_resources.h:22,
<robert_ancell>                  from /home/bob/bzr/lightdm-snap/parts/mir/src/src/platforms/mesa/server/x11/X11_resources.cpp:22:
<robert_ancell> /home/bob/bzr/lightdm-snap/stage/include/X11/Xfuncproto.h:174:24: error: ISO C++ does not permit named variadic macros [-Werror=variadic-macros]
<robert_ancell>  #define _X_NONNULL(args...)  __attribute__((nonnull(args)))
<robert_ancell> This is on zesty
<kgunn> hey guys so i was chatting with dslul in #snappy, he was trying out the mir-kiosk stuff
<kgunn> oops...and having network issues too i guess
<kgunn> will wait
<kgunn> so it fails on the mir-kiosk (server) bringup part
<kgunn> line 87
<kgunn> http://pastebin.com/RTm8FQWb
<kgunn> Dec  9 11:19:58 localhost snap[1909]: Mir fatal error: Failed to get frontbuffer
<kgunn> but it looks like it's finding the kms/drm drivers fine...
<kgunn> any ideas?
<kgunn> alan_g: camako ^
<dslul> kgunn, what does this mean: pci id for fd 7: 1013:00b8, driver (null)
<dslul> it is just before the error, and after selecting the driver
<kgunn> no idea :)
<kgunn> but maybe one of these guys will
<kgunn> oh... anpok_ is on... ^^
<dslul> I've just installed the overlay, let's see what happens
<alan_g> kgunn: well, the "Failed to get frontbuffer" error comes from the kms driver: it's failing to get a buffer for compositing to. But that doesn't tell us why
<daniele_> kgunn, I did what you said, added the ppa, then sudo apt update and dist-upgrade, rebooted but lightdm doesn't have the unity8 entry
<kgunn> daniele_: right...you have to do one more step, sudo apt-get install unity8-desktop-session-mir
<kgunn> then you should prolly reboot
<daniele_> unity8-desktop-session-mir : Depends on: unity8-desktop-session (>= 1.0.13) but is not going to be installed
<daniele_> I think something went wrong
<anpok_> what driver is that?
<anpok_> ah qemu
<anpok_> switch model from VGA to QXL
<daniele_> in virt-manager?
<anpok_> yes
<daniele_> I can't find this option
<anpok_> hm there should be a video section .. in which you can switch the model
<kgunn> daniele_: click the little information icon....
<kgunn> i think it brings up a panel with all those options...then you can click on video/gfx
<daniele_> ok found it
<daniele_> it was set to cirrus
<daniele_> it works now!
<daniele_> thank you
<kgunn> daniele_: great! if you have more questions let us know....
<kgunn> would love to hear if you have a specific application you're chasing
<camako> kgunn, I am not sure if you've gotten to the bottom of dslul's problem, but the "pci id for fd 7: 1013:00b8, driver (null)" is coming from the Mesa driver.
<camako> It's not finding the correct dri backend
<camako> It's not related to Mir, but rather the setup... I think it has to do with mixing a new Mesa with an old(er) distro... Like Mesa 13.0.x vs Xenial...
<daniele_> camako, I have mesa 12, we already solved the problem, it was a misconfiguration in virt-manager
<daniele_> kgunn, nothing serious for now, but I worked in IoT and wanted to hack some code in case I needed it in the future
<kgunn> glad we solved that too...i'll know if someone else asks
<daniele_> maybe you can write it in the tutorial https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<daniele_> btw, it would be great to have support for raspberry pi 2/3, since they are pretty common and cheap
#ubuntu-mir 2016-12-10
<dslul> hello, kgunn I tried to install unity8-session on ubuntu core 16 (virt-manager 64 bit), I followed the instructions on the document you posted yesterday, but this error always repeats:
<dslul> upstart: unity8-dash main process (6626) killed by ABRT signal
<dslul> upstart: unity8-dash main process ended, respawning
<dslul> these two lines infinitely repeat (with different PID each time)
