[00:00] <bschaefer> RAOF, though whats strange is:
[00:00] <bschaefer> http://paste.ubuntu.com/6038461/
[00:00] <bschaefer> it has a XMIR-1 display added in?
[00:00] <bschaefer> but not connected...
[00:02] <bschaefer> annd yeah changing the res sends me back to lightdm
[00:05] <bschaefer> RAOF, if you're interested in the stacktrace in my Xorg.0.log:
[00:05] <bschaefer> http://paste.ubuntu.com/6038469/
[00:08] <RAOF> Ta.
[00:11] <RAOF> bschaefer: And, as usual, you can't get a proper trace out of that, can you?
[00:11] <RAOF> bschaefer: OH! Did you get an apport crash report out of that?
[00:13] <bschaefer> hmm
[00:13] <bschaefer> RAOF, im not sure, I usually don't use apport :)
[00:13]  * bschaefer checks
[00:13] <RAOF> Because you can post-process that locally to get a symbolic backtrace, using apport-retrace.
[00:14] <bschaefer> let me see if I can get a real backtrace...
[00:14] <bschaefer> as that one is pretty useless :)
[00:16] <bschaefer> RAOF, hmm I don't seem to have a *.crash file from today ... besides the hud service...
[00:17] <RAOF> Delete any existing Xorg crash file, and then crash it again :)
[00:17] <bschaefer> alright!
[00:30] <bschaefer> RAOF, cool got a *.crash file, now to run it through apport...
[00:31] <bschaefer> it doesn't crash very often though
[00:31] <RAOF> Oh, it doesn't dependably crash when you change resolution?
[00:31] <bschaefer> most the time it was changing the res, but lots of graphic problems
[00:31] <bschaefer> nope!
[00:31] <bschaefer> ill upload an image of what it looks like...but it looks baaad
[00:31] <bschaefer> finally got a crash though
[00:37] <bschaefer> RAOF, http://i.imgur.com/dKiZNKY.jpg
[00:37] <bschaefer> when it does work
[00:37] <RAOF> 404'd!
[00:37] <bschaefer> :(
[00:38]  * bschaefer tries a different site?
[00:38] <bschaefer> RAOF, or possibly this: http://imgur.com/dKiZNKY
[00:39] <RAOF> Whee!
[00:39] <bschaefer> strange, o well but yeah, I think I saw similar rendering issue with other testers?
[00:40] <bschaefer> but things are rendering fine when I don't force the res
[00:47] <bschaefer> :(
[00:47] <bschaefer> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[00:51] <RAOF> :(
[00:52] <RAOF> bschaefer: There'll be a shiny new -ati to test in qa-testing2 shortly.
[00:53] <bschaefer> sweet, I can give that run
[00:53]  * bschaefer attempts the apport-retrace again...for the hell of it
[01:03] <bschaefer> RAOF, i've also just realized I pulled the packages directly from qa-testing2, instead of adding that ppa...
[01:03] <bschaefer> which im guessing means it can't find the correct packages for the sandbox...
[01:03]  * bschaefer adds pps
[01:03] <bschaefer> ppa*
[01:12] <RAOF> bschaefer: That would be correct, yes.
[01:13] <RAOF> bschaefer: You're looking for xserver-xorg-video-radeon 7.2.0-0ubuntu3+xmirMM4
[01:14] <bschaefer> RAOF, the new one?
[01:14]  * bschaefer just added the ppa, and is redoing the apport-retrace
[01:14] <RAOF> Yeah. That's the one to test next.
[01:15] <bschaefer> cool, ill test it out after this (hopefully) new retrace attempt
[01:15] <bschaefer> hopefully successful*
[01:23] <bschaefer> RAOF, stracktrace: http://paste.ubuntu.com/6038660/
[01:24] <bschaefer>         pid = -1222160384
[01:24] <bschaefer> doesn't like good :)
[01:25] <RAOF> src_obj = {pitch = 1280, width = 3093165488, height = 3086817120, bpp = -1237450752, domain = 3093165488, bo = 0xb8560c28, tiling_flags = 3086729320, surface = 0xb63a06d6 <RADEONEXASetSharedPixmapBacking+70>}
[01:25] <bschaefer> yeah I just saw that as well
[01:25] <bschaefer> same with dest_obj
[01:25] <bschaefer> dst_obj*
[01:25] <RAOF> I believe that's fixed in MM4
[01:26] <bschaefer> sweet, let me give that a run
[01:29]  * bschaefer reboots
[01:37] <bschaefer> RAOF, just to double check, just asserting that that crash ins't happening?
[01:37] <bschaefer> after ~3 attempts no crash, but still have to reboot after the screen goes crazy :)
[01:37] <RAOF> Hm.
[01:37] <RAOF> Screen going crazy is not expected. :
[01:37] <RAOF> :/
[01:37] <bschaefer> RAOF, I could also be forcing the res in an odd way
[01:37]  * bschaefer paste bin commands
[01:38] <bschaefer> RAOF, http://paste.ubuntu.com/6038680/
[01:39] <RAOF> Ok.
[01:39] <RAOF> Huh.
[01:39] <bschaefer> used: cvt 1280 720 to get the modeline
[01:39] <RAOF> Why do you need --newmode?
[01:39] <RAOF> That won't work :)
[01:39] <bschaefer> RAOF, excellent, I just quickly looked up how to change the res using xrandr...
[01:40] <bschaefer> RAOF, I should just have to do:
[01:40] <RAOF> “xrandr -q” should list the valid modes, then you can just xrandr --output XMIR-0 --mode $EXISTING_MODE
[01:40] <bschaefer> xrandr --output XMIR-0 --mode 1024x768?
[01:41] <bschaefer> alright, ill give that a try then
[01:44] <bschaefer> RAOF, :( screen still went crazy....
[01:44] <RAOF> Hm.
[01:44]  * bschaefer checks logs for anything
[01:44] <bschaefer> nothingis crashing though
[01:44] <RAOF> Got dmesg / Xorg log?
[01:46] <bschaefer> RAOF, hmm let me past the xorg log/dmesg but Its hard to read them with such a small screen :)
[01:47] <RAOF> You should be able to just use pastebinit, right?
[01:47] <bschaefer> yeah I can: http://paste.ubuntu.com/6038693/
[01:48]  * bschaefer likes to be able to attempt to read them
[01:50] <bschaefer> dmesg: http://paste.ubuntu.com/6038696/
[01:50]  * bschaefer looks at the kern log
[01:54] <RAOF> Ah. You haven't tried to change the mode yet?
[01:54] <bschaefer> RAOF, ?
[01:55] <RAOF> bschaefer: The xorg log doesn't seem to contain an attempt to change the mode from the default.
[01:55] <bschaefer> RAOF, hmm I wonder if I grabed the wrong one?
[01:55] <RAOF> Mayhap.
[01:55] <bschaefer> i used Xorg.0.log.old...assuming it was the last one
[01:56]  * bschaefer attempts the mode change again looking at the current time...
[02:02] <bschaefer> RAOF, hmm my Xorg has the correct time, but I don
[02:02] <bschaefer> dont see it trying to set it...
[02:04] <RAOF> That is odd.
[02:04] <bschaefer> i have a bunch of extra bytes at the end of the file though...
[02:05] <duflu> RAOF: Those little horizontal lines with intel+XMir+bypass, they seem to be on damage rect boundaries... ?
[02:05] <RAOF> duflu: Not really, no?
[02:05] <bschaefer> RAOF, which when I try to open it in gedit says there an encoding error...I wonder if it was failing to get logged to...
[02:06] <bschaefer> lots of: \00
[02:06] <RAOF> bschaefer: Hm, maybe?
[02:06]  * bschaefer has no clue how that would happen
[02:06] <bschaefer> RAOF, should I try turning all the debugging messages back on?
[02:07] <bschaefer> and try to get some logs from the kern.log?
[02:07] <RAOF> Hm, maye?
[02:07] <bschaefer> wouldn't hurt at this point at lease...
[02:11] <bschaefer> RAOF, would setting the drm.debug thing even work for this?
[02:12]  * bschaefer also forgot the path to it...and does't have the log saved
[02:13]  * bschaefer found it..
[02:13] <bschaefer> well wouldnt hurt
[02:21] <bschaefer> RAOF, yay the Xorg log is showing it now...
[02:21] <RAOF> Woot!
[02:21] <bschaefer> http://paste.ubuntu.com/6038776/
[02:22] <bschaefer> but no errors in it...
[02:23] <bschaefer> at lease that I see :)
[02:26]  * bschaefer wonders if its having a problem cause one monitor is still the 640x480 res
[02:27] <bschaefer> as things are mirrored atm
[02:31] <RAOF> Hrm. Stupid qa-testing2 ppa building against the archive...
[02:32] <RAOF> Hm. Ok, that looks pretty standard.
[02:32]  * RAOF wonders if he can trigger this on his radeon.
[02:33] <bschaefer> I wonder if its cause im setting a mirror monitor to a res that is not supported by the other
[02:33] <bschaefer> the only one that overlaps is 640x480
[02:35] <bschaefer> RAOF, well im going to head off for the night and eat some dinner, hopefully its reproducible else where :)
[02:36] <RAOF> Yeah.
[02:36] <RAOF> Have nice dinner!
[02:36] <bschaefer> thanks! If I find any other info Ill poke you tomorrow
[02:36] <bschaefer> or if you want me to test anything else out
[02:40] <RAOF> Yay! Reproducible locally!
[02:49] <kgunn> RAOF: did anyone tell you?....nouvea w/ latest drivers from qa-testing2 will boot to usable unity single screen
[02:50] <RAOF> kgunn: But not more than one screen?
[02:50] <kgunn> RAOF: nope....but gagnon tried with standalone X and it wasn't happy
[02:50] <kgunn> i'm convinced nouveau is just a mess
[02:50] <kgunn> before we stirred the pot
[03:35] <duflu> robert_ancell: I only heard underwater mumbles half the time :/
[03:36] <robert_ancell> duflu, awesome
[03:36] <robert_ancell> :)
[03:43] <duflu> robert_ancell: So which should I expect to be landing first? bypass or timerless?
[03:43] <robert_ancell> duflu, probably bypass
[03:44] <duflu> OK, removing one of the timerless branches then
[03:44] <robert_ancell> duflu, does that make it easier to land timerless?
[03:44] <duflu> Yes
[04:28] <tvoss__> good morning
[04:31] <tvoss__> RAOF, ping
[04:31] <RAOF> tvoss__: Pong.
[04:35] <robert_ancell> bbiab
[04:36] <tvoss__> kgunn, ping
[04:38] <kgunn> tvoss__: pong
[05:17] <mlankhorst> morning
[05:23] <RAOF> mlankhorst: Speak of the devil!
[05:27]  * robert_ancell -> dinner etc, will be back later
[05:29] <duflu> Oh multi-monitor is so much less annoying when none of them are analog VGA
[05:32] <RAOF> Yeah, I'm trying to rid the world of VGA interfaces.
[05:33] <duflu> Especially when my oldest monitor misdetects the VGA signal most of the time
[05:34] <RAOF> You know, it'd be much easier to debug bypass if my radeon card didn't work perfectly with it.
[05:45] <duflu> RAOF: Good to hear, kinda. I'm working on a setup to try radeon+saucy here too
[05:47] <duflu> Oh, new saucy wallpapers?!
[05:48] <duflu> Ahem, wallpapers for saucy
[05:48] <RAOF> To the multi-monitor-bypass-testotron!
[05:48] <RAOF> Heh.
[05:52] <duflu> RAOF: Do you have a solid indication it is bypassing on radeon? Like performance?
[05:53] <duflu> ... lack or mouse lag?
[05:53] <RAOF> Ok. As long as you don't mind waiting a couple of frames for all your rendering to appear, multimonitor+bypass on Intel wors.
[05:53] <RAOF> *works.\
[05:53] <duflu> RAOF: Yeah that was true without bypass too, but I think the out-of-order-ness is worse with bypass
[05:53] <RAOF> Oh, no.
[05:53] <RAOF> This isn't out of orderness.
[05:54] <RAOF> And I'm *not* seeing the same out-of-order problems. At least at the moment.
[05:54] <RAOF> I'm talking about the rendering "teleporting in" in horizontal lines.
[05:55] <duflu> RAOF: Yeah saw that (less so) with intel bypass single monitor too
[05:55] <RAOF> Right.
[05:55] <duflu> Annoyingly, only on the XMir surface
[05:55] <mlankhorst> RAOF: did you fix ati? :P
[05:57] <RAOF> mlankhorst: By setting the window pixmap of all the children of the root window that share the root window's pixmap.
[05:57] <RAOF> I presume by "fix ati" you're talking about mode changing here?
[05:57] <mlankhorst> ytes
[05:57] <RAOF> Yeah.
[05:57] <RAOF> Did nouveau work with modechanges? I'd expect it to suffer the same problem.
[05:58] <duflu> brb
[05:59] <mlankhorst> RAOF: did you upload a version bump to mir so it's easier to test? :p
[06:00] <RAOF> No; I'll do so now.
[06:03]  * mlankhorst slowly wakes up
[06:22] <RAOF> mlankhorst: Got any idea what might cause this: http://ubuntuone.com/08RzJfgwUfZd1LigIS16Mh particularly fun brand of misrendering?
[06:25] <mlankhorst> RAOF: forgetting to flush maybe?
[06:26] <RAOF> That thought occurred
[06:27] <mlankhorst> try damaging the whole screen and see what happens..
[06:27] <mlankhorst> hm compiz already should, though
[06:29] <duflu> mlankhorst: I tried that. No change
[06:30] <mlankhorst> duflu: might be a driver bug or something :P
[06:30] <RAOF> I suspect it might be a cache-coherency problem that ickle warned me about.
[06:31] <duflu> Does intel need/use the "dirty/clips" feature of DRM? I thought it was only vmware that did
[06:31] <RAOF> fbc might interact with that?
[06:31] <mlankhorst> oh is it intel?
[06:32] <RAOF> Yad
[06:32] <duflu> Yes
[06:32] <RAOF> Yah
[06:32] <mlankhorst> yeah probably something like that
[06:32] <duflu> RAOF: What was the cache coherency warning?
[06:33] <duflu> brb
[06:34] <RAOF> mlankhorst: xserver MM16 awaits your attention
[06:34] <mlankhorst> what do you want me to test?
[06:35] <RAOF> nouveau MM
[06:35] <RAOF> If that didn't work before.
[06:36] <RAOF> duflu: I forget the details, but I half-remember that there was special cache invalidation magic needed when doing things to the framebuffer that mesa doesn't do?
[06:36] <duflu> RAOF: AFAICT, we're not doing anything Mesa doesn't do. I keep searching the Mesa sorce
[06:36] <duflu> But I'm probably wrong
[06:37] <RAOF> We'll, we're calling drmModeAddFB and drmModePageFlip, which mesa doesn't do :)
[06:37] <duflu> RAOF: Oh just SetCrtc?
[06:37] <RAOF> Mesa doesn't do that, either.
[06:37] <duflu> RAOF: ??
[06:38] <RAOF> Mesa doesn't do any of the modesettingy stuff; it leaves that for X to do.
[06:38] <RAOF> And X leaves that for the DDX to do.
[06:38] <RAOF> Except we don't let the DDX do what it was doing, and we do our own thing.
[06:38] <duflu> RAOF: So we need to copy some magic from DDX into Mir?
[06:39] <RAOF> Maybe
[06:39] <duflu> The old DDX
[06:39]  * duflu now has new source to examine
[06:39] <duflu> BTW, my experiment to get saucy on radeon has now failed
[06:39] <duflu> The machine fails to boot for new unknown reasons
[06:40] <mlankhorst> RAOF: hm could you MIR libjsoncpp? :P
[06:40] <mlankhorst> build-dep for llvm-toolchain
[06:40] <RAOF> mlankhorst: I can't promote it myself; is there a MIR already filed?
[06:41] <mlankhorst> it hm don't know if there is, but it was always a build-dep for llvm, but llvm-toolchain-3.3 had some package modifications to use an external copy
[06:45] <RAOF> How did llvm build before if it always build-depended on a package not in main?
[06:45] <mlankhorst> it had an internal copy :P
[06:45] <RAOF> Heh
[06:46] <mlankhorst> I suppose I could make a MIR for it, but I feel it's a bit of overkill
[06:47] <mlankhorst> bah it moved llvm-toolchain-3.3 back to universe
[06:51] <tvoss> duflu, one thing I noticed yesterday: we never "release" the BufferObject for the scanout bo
[06:52] <duflu> tvoss: I thought  there was a devious and non-obvious path where it was released. Will check again. It's certainly different to the default front_buffer as far as GBM is concerned
[06:54] <tvoss> duflu, as I understand it, the buffer object is never released until destruction
[06:55] <duflu> tvoss: Oh. Yes we do delete it correctly. And the "release" call would be erroneous (and crash from memory) on the bypass buf. Because that applies to gbm surface-specific bo's
[06:56] <tvoss> duflu, might be good to have a different type to wrap the buffer object, then. But that's for later
[06:56] <duflu> tvoss: You're only meant to gbm_surface_release_buffer on things which come from gbm_surface_lock_front_buffer
[06:56] <tvoss> duflu, one other thing: if a bypass buffer is provided, we never eglswap
[06:56] <duflu> tvoss: Correct! Bypass means no GL-anything!
[06:56] <tvoss> duflu, ack
[06:56] <tvoss> duflu, if only that was documented somewhere ;)
[06:57] <duflu> tvoss: Fair point. But it's interesting when you realise you can composite without any GL
[06:57] <RAOF> Well, we're not actually compositing anything.
[06:57] <duflu> True
[06:57] <duflu> Kinda
[07:03] <RAOF> If we used overlays then we *could* be compositing and bypass at the same time.
[07:04] <duflu> ... it opens up doors like Mir supporting non-GL platforms in a limited fashion
[07:05]  * tvoss points out that we have a weird cache invalidation thingy to fix first
[07:05] <duflu> RAOF: Already with the hardware cursor (works over bypass)
[07:18] <duflu> BTW, I think I observed a noticeable improvement with timerless on radeon with dual monitors. I think...
[07:30] <sil2100> Hi everyone
[07:31] <duflu> sil2100, morning
[07:32] <sil2100> Did all the branches needed for bypass and multimonitor get merged into trunks already?
[07:33] <sil2100> Of mir and unity-system-compositor?
[07:33] <duflu> sil2100: Not yet. Happening now
[07:33] <tvoss> sil2100, I will keep you posted as merges are happening
[07:33] <tvoss> sil2100, makes sense?
[07:33] <sil2100> duflu: can you poke me when that's done? And which components have changes that need releasing? Since I'd like to get it out today
[07:33] <sil2100> tvoss: thanks!
[07:51] <duflu> sil2100: Yep
[07:52] <hikiko> hi, question: what's the drm interface version? is it the library version or something else?
[07:53] <duflu> hikiko: I was wondering that myself. Seems unrelated to anything. And I was told that it doesn't get updated at all
[07:53] <hikiko> and it causes a bug in nested mir
[07:53] <mlankhorst> hikiko: no it's checking if dri2 is supported or not
[07:53] <mlankhorst> that's all
[07:55] <hikiko> so, if I want to fix the bug on nested mir (which is: I don't have permission to set the drmInterfaceVersion to the device I want to use - which is usable) I have to find another way to check if dri2 is supported?
[07:56] <mlankhorst> just assume it's supported tbh
[07:57] <mlankhorst> did you try killing that check entirely?
[07:57] <hikiko> yes and it works fine
[07:57] <hikiko> if there's no other part of mir that uses it
[07:57] <hikiko> then I ll just do an mp
[08:00] <hikiko> mlankhorst, duflu could you review it? https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
[08:00] <hikiko> (i just removed the check)
[08:01] <duflu> Will do
[08:01] <hikiko> thanks!
[08:02] <duflu> hikiko: Could that explain the strange DRM open failures some nvidia users get?
[08:03] <mlankhorst> duflu: that's.. more complicated
[08:04] <mlankhorst> but link a bug?
[08:04] <duflu> mlankhorst: bug 1206633
[08:04] <hikiko> that's the error I was getting too
[08:04] <hikiko> but I don't know if that change solves it (I have an intel)
[08:06] <mlankhorst> some calls require DRM_MASTER, but meh
[08:07] <duflu> Which we have, maybe not soon enough?
[08:08] <mlankhorst> probably not then
[08:08] <alan_g> \o/ bypass has landed
[08:08] <hikiko> :D
[08:08] <mlankhorst> and there can only be 1 master
[08:08] <mlankhorst> this is legacy from dri1 :/
[08:11] <mlankhorst> duflu: it's complicated, there used to be a race between xorg-server, lightdm and plymouth, where lightdm could not detect plymouth..
[08:12]  * duflu ducks
[08:12] <mlankhorst> I think if you start xorg-server before opening the drm fd in mir, you get the same kind of symptoms for a race..
[08:13] <duflu> alan_g: I'm fixing timerless now. I don't care what the variables are called. *count/no/num ... pick one and I'll change them all
[08:14] <duflu> hikiko: You got the same exception with errno==0 ?
[08:15] <alan_g> duflu: I'm not blocking on the names - and *_sequence_number is a mouthful
[08:15] <hikiko> no, with errno = 13 or so let me see
[08:15] <duflu> hikiko: Different bug. But it exists :)
[08:15] <hikiko> a yes the Success
[08:15] <hikiko> let me run it one more time
[08:15] <hikiko> :P
[08:15] <duflu> hikiko, Success or errno 13?
[08:18] <alan_g> duflu: *seq_no?
[08:18] <hikiko> I got the 13
[08:18] <hikiko> Permission denied
[08:18] <hikiko> but I think that at some point I got the success as well :S while debugging
[08:19] <hikiko> if I leave the check I get the 13
[08:19] <duflu> alan_g: That's the one option I disliked. It is actually a count or frame number without gaps (on at least one or more monitors). So I think count/no/num is better
[08:19] <mlankhorst> hikiko: can you do lsof /dev/dri/*
[08:19] <hikiko> it doesnt return anything
[08:20] <hikiko> plymouthd  189 root   12u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> Xorg      1988 root  mem    CHR  226,0          8971 /dev/dri/card0
[08:20] <hikiko> Xorg      1988 root   10u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> Xorg      1988 root   42u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> mir_demo_ 8375 root  mem    CHR  226,0          8971 /dev/dri/card0
[08:20] <hikiko> mir_demo_ 8375 root    9u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> mir_demo_ 8375 root   10u   CHR  226,0      0t0 8971 /dev/dri/card0
[08:20] <hikiko> ouch
[08:20] <hikiko> sorry
[08:20] <hikiko> ://
[08:20] <hikiko> it was huge
[08:21] <alan_g> duflu: sync_counter?
[08:21] <mlankhorst> hikiko: yeah you still had some stuff open, can only run 1 at the same time
[08:21] <duflu> alan_g: I think frame number is more self explanatory
[08:21] <hikiko> mlankhorst, it seems that I have plymouth running after all :)
[08:21] <mlankhorst> indeed!
[08:24] <alan_g> duflu: ok [current|local|global]_frame_number
[08:25] <duflu> tvoss: Do you want timerless done before we declare MM feature complete?
[08:25] <duflu> It's not really critical
[08:26] <tvoss> duflu, let's get it in if it does not break us
[08:26] <duflu> tvoss: Still working on fixing it tho
[08:26] <hikiko> mlankhorst, what do you mean I can only run one at time? only one can use the drm device at a specific time? (which means that I can't set the version to a device that is used although I can use the device?)
[08:26] <tvoss> duflu, don't block on it
[08:27] <hikiko> I dont know if what I wrote makes sense :p
[08:27] <mlankhorst> hikiko: there can only be 1 master
[08:27] <hikiko> and when you set the version you have to be the master?
[08:27] <mlankhorst> yes
[08:27] <mlankhorst> and if nobody has the device opened, you automatically become master
[08:27] <duflu> In that case, sil2100, bypass and MM are fully landed in lp:mir. There is no new version/tag yet. Usually robert_ancell does that
[08:27] <hikiko> then ok it's normal that only nested mir has the error
[08:28] <robert_ancell> yeah, I tag on mondays
[08:28] <hikiko> because in my case I am not and I don't want to become the master
[08:28] <robert_ancell> duflu, you haven't landed MM right?
[08:28] <duflu> robert_ancell: I said lp:mir where it landed weeks ago
[08:28] <robert_ancell> oh, right
[08:29] <mlankhorst> hikiko: yeah if you get the fd from someone else, presumably you're already authenticated. it's a silly concept :P
[08:29] <duflu> sil2100: But ask RAOF when the XMir parts are landing...
[08:30] <alan_g> hikiko: ( mlankhorst ) the fd should come from the hosting Mir session
[08:30] <duflu> alan_g: Actually I just noticed freezing the count doesn't always freeze rendering. It probably should. So fixing...
[08:31] <sil2100> duflu: ok, anything else needs landing? Anything in u-s-c?
[08:31] <duflu> robert_ancell, ^
[08:31] <hikiko> alan_g, the host uses the drm device and then I create a drm device to create the gbm device and allocate a gbm buffer (because gbm depends on drm) but it's the host that renders on the screen and is the master
[08:31] <robert_ancell> sil2100, lp:unity-system-compositor and lp:lightdm are all up to date
[08:31] <hikiko> so while my device can be used I dont have the permission (since I am not a master) to set the version
[08:32] <alan_g> hikiko: you can get a pre-authorised from mir_connection_drm_auth_magic()
[08:32] <hikiko> yes
[08:32] <hikiko> but I don't want to do this
[08:32] <hikiko> because I need to see on the screen
[08:33] <hikiko> (host mir does the rendering/vt etc)
[08:34] <hikiko> what does mir_connection_drm_auth_magic() do exactly?
[08:34] <mlankhorst> hikiko: authenticate
[08:34] <mlankhorst> which involves guessing a 32-bit integer iirc
[08:35] <hikiko> yes, in nested mir I only authenticate when I need to use the display
[08:36] <hikiko> and I guess that's correct, because if nested mir is the master then the host mir won't render anymore
[08:36] <hikiko> and I will see a freeze
[08:36] <hikiko> isnt it?
[08:36] <mlankhorst> authenticate != master
[08:37] <hikiko> then authentication doesn't solve the problem with the interface version
[08:37] <RAOF> mlankhorst: Did you get to test MM+nouveau?
[08:37] <hikiko> the initial problem was that I couldnt call the drmSetInterfaceVersion without being the master
[08:38] <alan_g> the host remains master, but gives the nested the fd it needs. The host sets the interface version nested
[08:38] <alan_g> nested doesn't need to
[08:38] <mlankhorst> RAOF: i was busy with llvm and tjaalton's stuff :P
[08:38] <RAOF> mlankhorst: Yeah, thought so.
[08:39] <hikiko> alan_g, the problem is that in drm helpers we call the setInterface when we open the drm device
[08:39] <hikiko> which is before authentication anyway
[08:39] <hikiko> and we use that code to check if the device we already opened
[08:39] <hikiko> is "usable"
[08:39] <hikiko> sorruy meeting brb
[08:40] <mlankhorst> hikiko: even authentication is not enough, requires master
[08:41] <mlankhorst> an authed client is something like glxgears, it can't touch the output mode or anything, but it can render and allocate buffers
[08:41] <hikiko> currently I do: open_drm_device
[08:41] <hikiko> amd then authentication
[08:41] <alan_g> mlankhorst: that's what I understand hikiko needs for nested. It is "just" an auth client
[08:42] <mlankhorst> indeed
[08:42] <mlankhorst> but drmSetVersion requires master :P
[08:42] <mlankhorst> so just kill it
[08:42] <alan_g> hikiko: don't do that - just get the fd from the master
[08:42] <hikiko> yes :)
[08:42] <hikiko> that's what I did
[08:43] <mlankhorst> ok so erm nouveau mm testing..
[08:43] <hikiko> alan_g, I cant get the fd from the master
[08:44] <hikiko> the master must use it's own gbm device
[08:44] <hikiko> because it might have other clients instead of mir on mir
[08:44] <RAOF> hikiko: Aren't you getting the drm fd from the PlatformPackage?
[08:45] <hikiko> PlatformIPCPackage?
[08:46] <RAOF> MirPlatformPackage, from mir_connection_get_platform
[08:46] <hikiko> no because I don't get the platform
[08:46] <hikiko> I create a native platform
[08:46] <hikiko> that has it's own buffers
[08:46] <hikiko> I don't use mir buffers
[08:47] <RAOF> And you can't get the platform first?
[08:47] <RAOF> Because mir_connection_get_platform will give you a fully armed and operation drm fd that you can create a gbm_device from.
[08:47] <RAOF> And then allocate buffers to your heart's content.
[08:47] <alan_g> RAOF: that's exactly what we want
[08:48] <hikiko> yes but the design we did was to have a native platform etc alan_g
[08:49] <alan_g> hikiko: What has that to do with this?
[08:51] <alan_g> The native platform needs an FD. mir_connection_get_platform (I had the wrong function before) gets that FD
[08:51] <mlankhorst> RAOF: single monitor works :P
[08:52] <tvoss> RAOF, what changes in Mir do you need landed for mm?
[08:52] <RAOF> tvoss: NOne
[08:52] <hikiko> yes just checking the MirPlatformPackage struct alan_g
[08:52] <mlankhorst> hm didn't crash on hotplug
[08:53] <RAOF> mlankhorst: And is displaying roughly correctly?
[08:53] <hikiko> RAOF, will this platform package give me the drm device of the host mir?
[08:53] <mlankhorst> RAOF: it would seem so
[08:53] <RAOF> mlankhorst: SHIP IT!
[08:53] <hikiko> because this is not what I want
[08:53] <RAOF> hikiko: No, it won't give you the same drm fd that the host mir has open.
[08:54] <mlankhorst> RAOF: overlapping screen works correctly too
[08:54] <RAOF> hikiko: It will give you a drm fd that you can use for your own rendering/buffer allocation/etc.
[08:54] <mlankhorst> as does a hole between the screens :P
[08:54] <RAOF> OOoh, thorough!
[08:54] <hikiko> RAOF, also will it be the master?
[08:54] <RAOF> hikiko: No, but it will be authenticated.
[08:54] <mlankhorst> RAOF: well those would be the main usecases anyway..
[08:55] <hikiko> cool then :)
[08:55] <RAOF> mlankhorst: And then it doesn't notice hotunplug? :)
[08:55] <mlankhorst> RAOF: no idea, I tried disabling both screens for fun, didn't work as intended :P
[08:56] <mlankhorst> main screen turn on
[08:56] <RAOF> :)
[08:56] <hikiko> +question how is this fd allocated? if we call the open_drm_device in gbm_display_helpers we have the same problem :)
[08:56] <hikiko> I think that just removing the check is the best
[08:57] <mlankhorst> RAOF: so it seems the case of 0 monitors doesn't work correctly :p
[08:57] <mlankhorst> when doing xrandr --output XMIR-* --off for all outputs
[08:58] <alan_g> hikiko: if gbm_display_helpers doesn't do what you need don't use it
[08:58] <RAOF> mlankhorst: I'm a bit surprised that doesn't work, but that's an edge case I'm happy to fix in post :
[08:58] <RAOF> :)
[08:58] <alan_g> hikiko: or give it the function you do need
[08:58] <duflu> I'm sure someone logged a bug for that yesterday
[08:59] <mlankhorst> looks like xorg didn't crash either :O
[09:00] <hikiko> alan_g, I ll just write a second open_drm_device that doesnt have the check of this branch: https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 then and use it
[09:00] <mlankhorst> oh right didn't test normal shutdown yet
[09:00] <mlankhorst> gasp, no crash
[09:00] <alan_g> hikiko: ack
[09:01] <mlankhorst> now the same, but with valgrind >:O
[09:01] <RAOF> mlankhorst: My code laughs at your petty memory-correctness tools!
[09:02] <mlankhorst> or does it? DUN DUN DUUN
[09:02] <RAOF> hikiko: It's still not clear to me why you need to open_drm_device at all?
[09:04] <mlankhorst> RAOF: haha i broke things, lets see if the panda has some debug output on serial console :P
[09:04] <hikiko> RAOF, I wont use mir buffers
[09:04] <hikiko> I will use native buffers
[09:04] <hikiko> gbm and android
[09:04] <mlankhorst> RAOF: bahaha
[09:04] <mlankhorst> [  292.862839] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR [XY_OUT_OF_BOUNDS] ch 3 [0x003fb4e000 unity-system-co[1120]] subc 2 class 0x9039 mthd 0x0300 data 0x00100000
[09:04] <hikiko> so in order to allocate a gbm buffer I need a gbm device which needs a drm device
[09:05] <mlankhorst> RAOF: seems to happen a few times during resizing
[09:05] <RAOF> hikiko: Yeah, but you *get* a drm device for free from the hosting Mir.
[09:05] <hikiko> RAOF, the problem is this check here:
[09:05] <hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
[09:05] <mlankhorst> RAOF: so har har har har har, I win :D
[09:06] <hikiko> which is inside open_drm_device
[09:06] <hikiko> so before you authenticate
[09:06] <hikiko> you have to drmSet..
[09:06] <RAOF> hikiko: Yeah, but you don't need to call open_drm_device at all.
[09:07]  * duflu doesn't understand what mlankhorst wins
[09:07] <hikiko> that's what I asked you, if I call the mir_connection..
[09:07] <hikiko> it wont call the open_drm_device at some point?
[09:07] <RAOF> All that open_drm_device does is get a drm fd; and you get the correct, pre-authenticated drm fd from mir_connection_get_platform
[09:07] <RAOF> hikiko: No, not on the nested server side.
[09:07] <hikiko> in any server's side
[09:07] <hikiko> the 2nd drm device allocated
[09:07] <RAOF> It *will* call get_authenticated_fd on the host's side.
[09:08] <hikiko> will have the problem
[09:08] <hikiko> yes
[09:08] <mlankhorst> duflu: RAOF may have won on memory validation, but he definitely LOST on gpu validation ;)
[09:08] <hikiko> then ok you ll get the bug in the host racarr|desert
[09:08] <RAOF> But you can get as many authenticated fds as you want.
[09:08] <hikiko> sorry
[09:08] <hikiko> RAOF,
[09:08] <hikiko> RAOF, I know the prob is that you cant run drmSetInterfaceVersion
[09:08] <hikiko> without being the drm_master
[09:09] <RAOF> Right. But the host Mir *is* drm master.
[09:09] <hikiko> since that is called before the drm authentication
[09:09] <hikiko> question:
[09:09] <RAOF> And the host Mir opens the fd for you, and then gives the fd over IPC.
[09:09] <hikiko> drm master is mir or a device?
[09:10] <RAOF> drm master is a state that a drm fd can be in. It basically means you get to modeset.
[09:10] <RAOF> (Among other things)
[09:10] <hikiko> when you call SetDrmMaster you pass an fd?
[09:10] <hikiko> let me check
[09:11] <RAOF> I'm not sure why you're caring about drm master?
[09:11] <RAOF> The nested compositor is not going to have access to a drm master fd, nor does it need one.
[09:11] <hikiko> RAOF,
[09:11] <hikiko> host mir starts
[09:12] <hikiko> it opens fd0
[09:12] <hikiko> it automatically becomes the master because it s the first device isnt it?
[09:12] <hikiko> and then you call setInterfaceVersion
[09:13] <hikiko> then opens fd1
[09:13] <hikiko> it's not the master
[09:13] <hikiko> you have to call setDrmMaster if you want it to be the master
[09:13] <hikiko> but before that
[09:13] <hikiko> in open_drm_device
[09:13] <hikiko> you call setInterfaceVersion
[09:13] <hikiko> for which you have no permission
[09:14] <hikiko> because you are not the master
[09:14] <hikiko> thats the problem
[09:14] <alan_g> hikiko: didn't we already solve that?
 alan_g, I ll just write a second open_drm_device that doesnt have the check of this branch: https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 then and use it
[09:14] <hikiko> alan_g, yes but RAOF asked which is the problem
[09:15] <tvoss> hikiko, I don't think we should call setInterfaceVersion in the nested compositor then
[09:15] <mlankhorst> which is what I said :P
[09:15] <hikiko> tvoss, that's what mlankhorst said and initially I did this MP because I thought that for the reason I wrote we dont wont it on mir as well
[09:16] <hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
[09:16] <tvoss> hikiko, we want it on the outer-most mir
[09:16] <hikiko> but ok I ll just remove it from the nested mur
[09:16] <RAOF> alan_g, hikiko: The second open_drm_device should be: { MirPlatformPackage *pkg; mir_connection_get_platform(conn, &pkg); return pkg->fds[0]; }
[09:16] <hikiko> ok then I ll just use another function in my branch
[09:16] <alan_g> hikiko: go for it!
[09:17] <hikiko> no RAOF because this way we ll get the device that the  host uses for rendering and we ll see nothing ... anyway :) I am going to do the change as alan_g says and then we improve it if there's something better :)
[09:18] <duflu> sil2100: Got what you need? AFAIK the LP-based projects are fully landed at least
[09:18] <RAOF> hikiko: That is how *all* (non-software) Mir clients work!
[09:18] <RAOF> hikiko: That *will* allow you to render and allocate buffers correctly.
[09:18] <alan_g> hikiko: we get an fd that allows us to allocate and use buffers - which is what we need
[09:18] <sil2100> duflu: I think all is in now, had a talk with RAOF and I think it should all go smoothly
[09:19] <hikiko> alan_g, RAOF then maybe better to give it a try
[09:27] <duflu> Hah. Don't google saucy wallpapers
[09:32] <RAOF> duflu: bypass is busted on intel; xmir is just exposing the bustedness by drawing enough to fill caches.
[09:32] <duflu> RAOF: I don't understand that statement entirely
[09:33] <RAOF> I'm talking with ickle in #intel-gfx; the horizontal bar corruption we see is stale cachelines.
[09:34] <RAOF> This is why you see it more on multihead than single-head; you're less likely to overfill the cache there.
[09:34] <duflu> RAOF: OK. What is "overfilling" and how is it avoided?
[09:35] <RAOF> Intel-specific stuff.
[09:35] <duflu> RAOF: Anything I can do for it in DRM userland?
[09:35] <RAOF> We need to disable caching for scanout buffers, and then periodically call kgem_busy
[09:36] <duflu> Sounds hackish
[09:36] <RAOF> Yeah.
[09:36] <duflu> That reminds me, I must improve the examples/ to help with that
[09:37] <tvoss> RAOF, is there an example where that is done?
[09:37] <RAOF> tvoss: grep xf86-video-intel for is_scanout; it's fairly widely distributed.
[09:38] <tvoss> RAOF, ack
[09:38] <tvoss> RAOF, where do we need to call kgem_busy? on the client or server-side?
[09:38] <RAOF> Really, server side.
[09:40] <RAOF> Since xmir is the only thing that reliably exposes this at the moment we could get away with doing it in xmir, but Unity8 will hit the same problems later.
[09:40] <tvoss> RAOF, indeed
[09:45] <tvoss> RAOF, is there a trigger that tells us when we should call kgem_busy?
[09:45] <RAOF> Don't know
[09:45] <tvoss> RAOF, ack
[09:45] <RAOF> Although probably when submitting a batch buffer
[09:45] <tvoss> duflu, do you file a bug?
[09:45] <tvoss> RAOF, reading through the numerous commits mentioning kgem_busy right now
[09:46] <duflu> tvoss: I don't think we have one yet. Because it never affected any PPA most people were testing, let alone trunk
[09:46] <tvoss> duflu, ack
[09:46] <tvoss> duflu, might make sense to note it down in a bug, though
[09:47] <RAOF> Actually, we might not have to fix it in the server; fixing it in XMir *and* ensuring that Mesa does the right thing (which it should do) should fix it for both.
[09:47] <RAOF> Which is significantly more tractable.
[09:47] <tvoss> RAOF, indeed, we keep it driver specific with that, don't we?
[09:47] <RAOF> Yes.
[09:47] <tvoss> RAOF, otherwise the server would make _interesting_ assumptions
[09:48]  * duflu votes for driver-specific hacks in driver-specific packages
[09:48] <RAOF> Eh, we'd just need to have a DDX layer for Mir ;)
[09:48] <duflu> :)
[09:48] <RAOF> We'd have a intel-gbm platform, and a nouveau-gbm platform, and…
[09:48] <duflu> Eek
[10:08] <duflu> tvoss, RAOF: Any objections to me logging off? I may yet cook dinner
[10:08] <RAOF> duflu: None from my end?
[10:11] <duflu> RAOF: On my desktop forcing two hardware surfaces to be placed on corresponding outputs (1920x1200) isn't enough to hit corruption/cache issues... !? But that's raring
[10:12] <RAOF> duflu: What card?
[10:12] <tvoss> duflu, feel free. Will call you in case of emergencies
[10:12] <tvoss> ;)
[10:12] <duflu> RAOF: HD2000 (i7-2600)
[10:14] <duflu> RAOF: Also lp:~vanvugt/mir/eglapp-place-output
[10:55] <RAOF> mlankhorst: Oh, where is your current xf86-video-nouveauL?
[10:57] <hikiko> alan_g, if you have a moment could you review this: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864 ?
[10:57] <alan_g> hikiko: sure
[10:58] <alan_g> hikiko: there are some MPs you can review too. ;)
[10:58] <hikiko> I am going to pull them alan_g :)
[11:07] <mlankhorst> RAOF: ..?
[11:07] <RAOF> mlankhorst: Yours is the last upload to qa-testing2; I want to prepare that for the archive.
[11:08] <mlankhorst> RAOF: oh didn't upload to github
[11:08] <mlankhorst> just apt-get source it
[11:08] <RAOF> Yeah, that's what I decided to do ;)
[11:08] <mlankhorst> RAOF: can you include xserver-xorg-video-nouveau 1.0.9 too?
[11:08] <RAOF> Sure.
[11:21] <hikiko> alan_g, how can I run the mir tests?
[11:21] <alan_g> hikiko: how long have you been on the project?!
[11:22] <alan_g> hikiko: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864/comments/414597
[11:45] <tvoss_> RAOF, mlankhorst sent you some packages for testing purposes
[11:45] <mlankhorst> yeah he should have them
[11:46] <tvoss_> mlankhorst, on nouveau with usc running, could you try to run sudo glmark2-es2-mir?
[11:46] <mlankhorst> sec, let me plug in a more.. stable card
[11:46] <tvoss_> mlankhorst, ack :)
[11:52]  * alan_g suddenly realises that we don't run the test suite for clang or android/armhf targets in CI
[12:05] <mlankhorst> mir should really have -dbg packages
[12:06] <mlankhorst> and usc too
[12:07] <RAOF> No, not really.
[12:07] <RAOF> Use the dbgsym packages.
[12:07] <RAOF> *Debian* should have -dbgsym packages
[12:07] <RAOF> Rather than manually constructing -dbg packages, like _animals_!
[12:08] <mlankhorst> RAOF: in the ppa?
[12:08] <RAOF> IIRC we've turned dbgsym packages on for the PPA.
[12:08] <RAOF> Dear Xserver: your intermittently failing test suite is adorable.
[12:09] <mlankhorst> RAOF: tell me where to find them, then :P
[12:09] <kgunn> RAOF: remember i told you there would be new ways for X to annoy you
[12:09] <RAOF> mlankhorst: I think you need to add the main/debug component to sources.
[12:09] <RAOF> mlankhorst: Enjoy your shiny new nouveau 1.0.9
[12:10] <mlankhorst> ah
[12:10] <mlankhorst> do all ppa's have that?
[12:10] <RAOF> Only those that have dbgsym packages enabled, sadly.
[12:10] <RAOF> Probably for space reasons?
[12:10] <RAOF> I don't know.
[12:10] <mlankhorst> probably
[12:11] <RAOF> But PPAs are space-limited *anyway*
[12:11] <RAOF> We should totally build dbgsym packages *everywhere*
[12:11] <mlankhorst> except we don't
[12:11] <RAOF> should implies don't :)
[12:11] <RAOF> Anyway, sleepy time!
[12:12] <mlankhorst> nn
[12:17] <tvoss_> RAOF, good night and get well soon
[12:22] <mlankhorst> interesting, I'm hitting a bug in vblanking somewhere
[12:22] <mlankhorst> probably
[12:23] <tvoss_> mlankhorst, with my testing packages
[12:26] <mlankhorst> I'm not sure what's causing it yet, but it seems some event is not being sent, ever ;P
[12:27] <tvoss_> mlankhorst, interesting
[12:33] <mlankhorst> hm might be a hang, bah
[12:36] <mlankhorst> ok other card
[12:37] <tvoss_> mlankhorst, ;)
[12:37] <mlankhorst> >:(
[12:38] <mlankhorst> there seems to be a memory corruption affecting all cards, but I don't know how
[13:09] <kgunn> hikiko: ping
[13:14] <hikiko> kgunn, hi
[13:21] <mlankhorst> wow..
[13:24] <tvoss_> mlankhorst, ?
[13:26] <mlankhorst> I may have found my nouveau issue, lets find out..
[13:29] <mlankhorst> hm no, still no closer :/
[13:54] <mlankhorst> tvoss_: do you have a normal glmark too? :P
[13:54] <tvoss_> mlankhorst, normal as in? :)
[13:54] <mlankhorst> x11
[13:54] <tvoss_> mlankhorst, it installs the usual x glmark2 as well
[13:54] <tvoss_> mlankhorst, should be part of the package
[13:56] <mlankhorst> tvoss_: not really, only contains glmark2-mir
[13:56] <mlankhorst> and glmark-es2-mir
[13:56] <tvoss_> mlankhorst, okay, recompiling packages
[13:56] <tvoss_> mlankhorst, thanks for testing :) found the issue btw
[13:57] <mlankhorst> hehe np :P
[13:58] <mlankhorst> btw does it matter if xorg runs in usc or not?
[13:58] <mlankhorst> as opposed to not running at all
[13:58] <sil2100> tvoss_, kgunn: hi guys, can you confirm if everything landed as needed (in -proposed at least)?
[13:58] <tvoss_> sil2100, ack
[13:59] <sil2100> tvoss_, kgunn: related to mir and the two features
[13:59] <mlankhorst> oh btw mesa 9.2 landed now
[13:59] <tvoss_> mlankhorst, wow, you love living on the edge, don't you? :)
[13:59] <tvoss_> mlankhorst, in archive or in proposed?
[13:59] <mlankhorst> tvoss_: proposed
[13:59] <mlankhorst> and now main it seems :P
[14:00] <tvoss_> mlankhorst, ack
[14:01] <mlankhorst> so right in time for feature freeze this time
[14:02] <kgunn> sil2100: yes
[14:02] <mlankhorst> tvoss_: hey last release we landed 9.1 right before final freeze
[14:10] <kgunn> hikiko: i just realized i'm on the hook for a uds session
[14:11] <hikiko> :)
[14:11] <hikiko> no problem kgunn
[14:12] <mlankhorst> unfortunately I cna't make any session this week, g2g :/
[14:15] <kgunn> hikiko: oh...wait...i was wrong...top of the hour....we're still on
[14:38] <jono> tvoss_, hey
[14:38] <jono> so the composite bypass lands today?
[14:44] <tvoss_> jono, yup
[14:55] <smartboyhw> tvoss_, is Mir now already in ubuntu-desktop meta packaage?
[14:55] <tvoss_> smartboyhw, not sure, need to check :)
[14:55] <tvoss_> jono, http://samohtv.wordpress.com/2013/08/29/mir-xmir-performance-in-13-10/
[14:55] <smartboyhw> :)
[14:55] <jono> tvoss_, does that include MM?
[14:55] <tvoss_> jono, the post? no: that's only addressing bypass
[14:56] <tvoss_> jono, I think we need some fixes for mm before we want to blog about it
[14:56] <jono> tvoss_, no I mean is MM in the archive?
[14:56] <jono> as part of FF?
[14:56] <tvoss_> jono, yeah
[14:56] <jono> ahhh awesome
[15:53] <olli> smartboyhw, no, it will need to be in main first before being pulled in as default
[16:29] <ricmm> tvoss_: ping
[16:29] <tvoss_> ricmm, pong
[16:30] <ricmm> tvoss_: where does Mir stand re: resizing/moving surfaces?
[16:30] <tvoss_> ricmm, we don't have it right now
[16:30] <ricmm> is there a plan for this? short-term I mean
[16:31] <tvoss_> ricmm, not really, would be great if we can live a week without it
[16:32] <ricmm> not sure how possible that is going to be with the OSK
[16:32] <ricmm> we will try today, but not sure
[23:33] <arsson> latest updates makes my cursor freeze in lightdm with nouveau?
[23:40] <RAOF> arsson: Updates from where?
[23:54] <arsson> RAOF: basic no ppa
[23:58] <RAOF> arsson: :(
[23:58] <RAOF> arsson: And you're presumably using unity-system-compositor+XMir? Does VT switching away and then back unfreeze the cursor?
[23:59] <robert_ancell> RAOF, lp:~robert-ancell/mir/drop-focus-on-vt-switch seems to work with test clients and drops focus when you VT switch away from them. It has a graphics lock-up as described in the MP, but you can work around it
[23:59] <robert_ancell> It should be good enough to start the XMir side of things
[23:59] <RAOF> robert_ancell: Sweet!
[23:59] <arsson> i went VT and removed u-s-c and now everything is workin