[00:00] RAOF, though whats strange is: [00:00] http://paste.ubuntu.com/6038461/ [00:00] it has a XMIR-1 display added in? [00:00] but not connected... [00:02] annd yeah changing the res sends me back to lightdm [00:05] RAOF, if you're interested in the stacktrace in my Xorg.0.log: [00:05] http://paste.ubuntu.com/6038469/ [00:08] Ta. [00:11] bschaefer: And, as usual, you can't get a proper trace out of that, can you? [00:11] bschaefer: OH! Did you get an apport crash report out of that? [00:13] hmm [00:13] RAOF, im not sure, I usually don't use apport :) [00:13] * bschaefer checks [00:13] Because you can post-process that locally to get a symbolic backtrace, using apport-retrace. [00:14] let me see if I can get a real backtrace... [00:14] as that one is pretty useless :) [00:16] RAOF, hmm I don't seem to have a *.crash file from today ... besides the hud service... [00:17] Delete any existing Xorg crash file, and then crash it again :) [00:17] alright! [00:30] RAOF, cool got a *.crash file, now to run it through apport... [00:31] it doesn't crash very often though [00:31] Oh, it doesn't dependably crash when you change resolution? [00:31] most the time it was changing the res, but lots of graphic problems [00:31] nope! [00:31] ill upload an image of what it looks like...but it looks baaad [00:31] finally got a crash though [00:37] RAOF, http://i.imgur.com/dKiZNKY.jpg [00:37] when it does work [00:37] 404'd! [00:37] :( [00:38] * bschaefer tries a different site? [00:38] RAOF, or possibly this: http://imgur.com/dKiZNKY [00:39] Whee! [00:39] strange, o well but yeah, I think I saw similar rendering issue with other testers? [00:40] but things are rendering fine when I don't force the res [00:47] :( [00:47] Backtrace stopped: previous frame inner to this frame (corrupt stack?) [00:51] :( [00:52] bschaefer: There'll be a shiny new -ati to test in qa-testing2 shortly. [00:53] sweet, I can give that run [00:53] * bschaefer attempts the apport-retrace again...for the hell of it [01:03] RAOF, i've also just realized I pulled the packages directly from qa-testing2, instead of adding that ppa... [01:03] which im guessing means it can't find the correct packages for the sandbox... [01:03] * bschaefer adds pps [01:03] ppa* [01:12] bschaefer: That would be correct, yes. [01:13] bschaefer: You're looking for xserver-xorg-video-radeon 7.2.0-0ubuntu3+xmirMM4 [01:14] RAOF, the new one? [01:14] * bschaefer just added the ppa, and is redoing the apport-retrace [01:14] Yeah. That's the one to test next. [01:15] cool, ill test it out after this (hopefully) new retrace attempt [01:15] hopefully successful* [01:23] RAOF, stracktrace: http://paste.ubuntu.com/6038660/ [01:24] pid = -1222160384 [01:24] doesn't like good :) [01:25] src_obj = {pitch = 1280, width = 3093165488, height = 3086817120, bpp = -1237450752, domain = 3093165488, bo = 0xb8560c28, tiling_flags = 3086729320, surface = 0xb63a06d6 } [01:25] yeah I just saw that as well [01:25] same with dest_obj [01:25] dst_obj* [01:25] I believe that's fixed in MM4 [01:26] sweet, let me give that a run [01:29] * bschaefer reboots [01:37] RAOF, just to double check, just asserting that that crash ins't happening? [01:37] after ~3 attempts no crash, but still have to reboot after the screen goes crazy :) [01:37] Hm. [01:37] Screen going crazy is not expected. : [01:37] :/ [01:37] RAOF, I could also be forcing the res in an odd way [01:37] * bschaefer paste bin commands [01:38] RAOF, http://paste.ubuntu.com/6038680/ [01:39] Ok. [01:39] Huh. [01:39] used: cvt 1280 720 to get the modeline [01:39] Why do you need --newmode? [01:39] That won't work :) [01:39] RAOF, excellent, I just quickly looked up how to change the res using xrandr... [01:40] RAOF, I should just have to do: [01:40] “xrandr -q” should list the valid modes, then you can just xrandr --output XMIR-0 --mode $EXISTING_MODE [01:40] xrandr --output XMIR-0 --mode 1024x768? [01:41] alright, ill give that a try then [01:44] RAOF, :( screen still went crazy.... [01:44] Hm. [01:44] * bschaefer checks logs for anything [01:44] nothingis crashing though [01:44] Got dmesg / Xorg log? [01:46] RAOF, hmm let me past the xorg log/dmesg but Its hard to read them with such a small screen :) [01:47] You should be able to just use pastebinit, right? [01:47] yeah I can: http://paste.ubuntu.com/6038693/ [01:48] * bschaefer likes to be able to attempt to read them [01:50] dmesg: http://paste.ubuntu.com/6038696/ [01:50] * bschaefer looks at the kern log [01:54] Ah. You haven't tried to change the mode yet? [01:54] RAOF, ? [01:55] bschaefer: The xorg log doesn't seem to contain an attempt to change the mode from the default. [01:55] RAOF, hmm I wonder if I grabed the wrong one? [01:55] Mayhap. [01:55] 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] RAOF, hmm my Xorg has the correct time, but I don [02:02] dont see it trying to set it... [02:04] That is odd. [02:04] i have a bunch of extra bytes at the end of the file though... [02:05] RAOF: Those little horizontal lines with intel+XMir+bypass, they seem to be on damage rect boundaries... ? [02:05] duflu: Not really, no? [02:05] 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] lots of: \00 [02:06] bschaefer: Hm, maybe? [02:06] * bschaefer has no clue how that would happen [02:06] RAOF, should I try turning all the debugging messages back on? [02:07] and try to get some logs from the kern.log? [02:07] Hm, maye? [02:07] wouldn't hurt at this point at lease... [02:11] 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] well wouldnt hurt [02:21] RAOF, yay the Xorg log is showing it now... [02:21] Woot! [02:21] http://paste.ubuntu.com/6038776/ [02:22] but no errors in it... [02:23] at lease that I see :) [02:26] * bschaefer wonders if its having a problem cause one monitor is still the 640x480 res [02:27] as things are mirrored atm [02:31] Hrm. Stupid qa-testing2 ppa building against the archive... [02:32] Hm. Ok, that looks pretty standard. [02:32] * RAOF wonders if he can trigger this on his radeon. [02:33] I wonder if its cause im setting a mirror monitor to a res that is not supported by the other [02:33] the only one that overlaps is 640x480 [02:35] RAOF, well im going to head off for the night and eat some dinner, hopefully its reproducible else where :) [02:36] Yeah. [02:36] Have nice dinner! [02:36] thanks! If I find any other info Ill poke you tomorrow [02:36] or if you want me to test anything else out [02:40] Yay! Reproducible locally! [02:49] RAOF: did anyone tell you?....nouvea w/ latest drivers from qa-testing2 will boot to usable unity single screen [02:50] kgunn: But not more than one screen? [02:50] RAOF: nope....but gagnon tried with standalone X and it wasn't happy [02:50] i'm convinced nouveau is just a mess [02:50] before we stirred the pot === chihchun_afk is now known as chihchun [03:35] robert_ancell: I only heard underwater mumbles half the time :/ [03:36] duflu, awesome [03:36] :) [03:43] robert_ancell: So which should I expect to be landing first? bypass or timerless? [03:43] duflu, probably bypass [03:44] OK, removing one of the timerless branches then [03:44] duflu, does that make it easier to land timerless? [03:44] Yes [04:28] good morning [04:31] RAOF, ping [04:31] tvoss__: Pong. [04:35] bbiab [04:36] kgunn, ping [04:38] tvoss__: pong [05:17] morning [05:23] mlankhorst: Speak of the devil! [05:27] * robert_ancell -> dinner etc, will be back later [05:29] Oh multi-monitor is so much less annoying when none of them are analog VGA [05:32] Yeah, I'm trying to rid the world of VGA interfaces. [05:33] Especially when my oldest monitor misdetects the VGA signal most of the time [05:34] You know, it'd be much easier to debug bypass if my radeon card didn't work perfectly with it. [05:45] RAOF: Good to hear, kinda. I'm working on a setup to try radeon+saucy here too [05:47] Oh, new saucy wallpapers?! [05:48] Ahem, wallpapers for saucy [05:48] To the multi-monitor-bypass-testotron! [05:48] Heh. [05:52] RAOF: Do you have a solid indication it is bypassing on radeon? Like performance? [05:53] ... lack or mouse lag? [05:53] 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] *works.\ [05:53] RAOF: Yeah that was true without bypass too, but I think the out-of-order-ness is worse with bypass [05:53] Oh, no. [05:53] This isn't out of orderness. [05:54] And I'm *not* seeing the same out-of-order problems. At least at the moment. [05:54] I'm talking about the rendering "teleporting in" in horizontal lines. [05:55] RAOF: Yeah saw that (less so) with intel bypass single monitor too [05:55] Right. [05:55] Annoyingly, only on the XMir surface [05:55] RAOF: did you fix ati? :P [05:57] mlankhorst: By setting the window pixmap of all the children of the root window that share the root window's pixmap. [05:57] I presume by "fix ati" you're talking about mode changing here? [05:57] ytes [05:57] Yeah. [05:57] Did nouveau work with modechanges? I'd expect it to suffer the same problem. [05:58] brb [05:59] RAOF: did you upload a version bump to mir so it's easier to test? :p [06:00] No; I'll do so now. [06:03] * mlankhorst slowly wakes up [06:22] mlankhorst: Got any idea what might cause this: http://ubuntuone.com/08RzJfgwUfZd1LigIS16Mh particularly fun brand of misrendering? [06:25] RAOF: forgetting to flush maybe? [06:26] That thought occurred [06:27] try damaging the whole screen and see what happens.. [06:27] hm compiz already should, though [06:29] mlankhorst: I tried that. No change [06:30] duflu: might be a driver bug or something :P [06:30] I suspect it might be a cache-coherency problem that ickle warned me about. [06:31] Does intel need/use the "dirty/clips" feature of DRM? I thought it was only vmware that did [06:31] fbc might interact with that? [06:31] oh is it intel? [06:32] Yad [06:32] Yes [06:32] Yah [06:32] yeah probably something like that [06:32] RAOF: What was the cache coherency warning? [06:33] brb [06:34] mlankhorst: xserver MM16 awaits your attention [06:34] what do you want me to test? [06:35] nouveau MM [06:35] If that didn't work before. [06:36] 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] RAOF: AFAICT, we're not doing anything Mesa doesn't do. I keep searching the Mesa sorce [06:36] But I'm probably wrong [06:37] We'll, we're calling drmModeAddFB and drmModePageFlip, which mesa doesn't do :) [06:37] RAOF: Oh just SetCrtc? [06:37] Mesa doesn't do that, either. [06:37] RAOF: ?? [06:38] Mesa doesn't do any of the modesettingy stuff; it leaves that for X to do. [06:38] And X leaves that for the DDX to do. [06:38] Except we don't let the DDX do what it was doing, and we do our own thing. [06:38] RAOF: So we need to copy some magic from DDX into Mir? [06:39] Maybe [06:39] The old DDX [06:39] * duflu now has new source to examine [06:39] BTW, my experiment to get saucy on radeon has now failed [06:39] The machine fails to boot for new unknown reasons [06:40] RAOF: hm could you MIR libjsoncpp? :P [06:40] build-dep for llvm-toolchain [06:40] mlankhorst: I can't promote it myself; is there a MIR already filed? [06:41] 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] How did llvm build before if it always build-depended on a package not in main? [06:45] it had an internal copy :P [06:45] Heh [06:46] I suppose I could make a MIR for it, but I feel it's a bit of overkill [06:47] bah it moved llvm-toolchain-3.3 back to universe [06:51] duflu, one thing I noticed yesterday: we never "release" the BufferObject for the scanout bo [06:52] 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] duflu, as I understand it, the buffer object is never released until destruction [06:55] 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] duflu, might be good to have a different type to wrap the buffer object, then. But that's for later [06:56] tvoss: You're only meant to gbm_surface_release_buffer on things which come from gbm_surface_lock_front_buffer [06:56] duflu, one other thing: if a bypass buffer is provided, we never eglswap [06:56] tvoss: Correct! Bypass means no GL-anything! [06:56] duflu, ack [06:56] duflu, if only that was documented somewhere ;) [06:57] tvoss: Fair point. But it's interesting when you realise you can composite without any GL [06:57] Well, we're not actually compositing anything. [06:57] True [06:57] Kinda [07:03] If we used overlays then we *could* be compositing and bypass at the same time. [07:04] ... 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] RAOF: Already with the hardware cursor (works over bypass) [07:18] BTW, I think I observed a noticeable improvement with timerless on radeon with dual monitors. I think... [07:30] Hi everyone [07:31] sil2100, morning [07:32] Did all the branches needed for bypass and multimonitor get merged into trunks already? [07:33] Of mir and unity-system-compositor? [07:33] sil2100: Not yet. Happening now [07:33] sil2100, I will keep you posted as merges are happening [07:33] sil2100, makes sense? [07:33] 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] tvoss: thanks! [07:51] sil2100: Yep [07:52] hi, question: what's the drm interface version? is it the library version or something else? [07:53] hikiko: I was wondering that myself. Seems unrelated to anything. And I was told that it doesn't get updated at all [07:53] and it causes a bug in nested mir [07:53] hikiko: no it's checking if dri2 is supported or not [07:53] that's all [07:55] 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] just assume it's supported tbh [07:57] did you try killing that check entirely? [07:57] yes and it works fine [07:57] if there's no other part of mir that uses it [07:57] then I ll just do an mp [08:00] mlankhorst, duflu could you review it? https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 [08:00] (i just removed the check) [08:01] Will do [08:01] thanks! [08:02] hikiko: Could that explain the strange DRM open failures some nvidia users get? [08:03] duflu: that's.. more complicated [08:04] but link a bug? [08:04] mlankhorst: bug 1206633 [08:04] bug 1206633 in Mir "mir doesn't start "Error opening DRM device" on nVidia" [Medium,Triaged] https://launchpad.net/bugs/1206633 [08:04] that's the error I was getting too [08:04] but I don't know if that change solves it (I have an intel) [08:06] some calls require DRM_MASTER, but meh [08:07] Which we have, maybe not soon enough? [08:08] probably not then [08:08] \o/ bypass has landed [08:08] :D [08:08] and there can only be 1 master [08:08] this is legacy from dri1 :/ [08:11] 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] 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] 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] hikiko: You got the same exception with errno==0 ? [08:15] duflu: I'm not blocking on the names - and *_sequence_number is a mouthful [08:15] no, with errno = 13 or so let me see [08:15] hikiko: Different bug. But it exists :) [08:15] a yes the Success [08:15] let me run it one more time [08:15] :P [08:15] hikiko, Success or errno 13? [08:18] duflu: *seq_no? [08:18] I got the 13 [08:18] Permission denied [08:18] but I think that at some point I got the success as well :S while debugging [08:19] if I leave the check I get the 13 [08:19] 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] hikiko: can you do lsof /dev/dri/* [08:19] it doesnt return anything [08:20] plymouthd 189 root 12u CHR 226,0 0t0 8971 /dev/dri/card0 [08:20] Xorg 1988 root mem CHR 226,0 8971 /dev/dri/card0 [08:20] Xorg 1988 root 10u CHR 226,0 0t0 8971 /dev/dri/card0 [08:20] Xorg 1988 root 42u CHR 226,0 0t0 8971 /dev/dri/card0 [08:20] mir_demo_ 8375 root mem CHR 226,0 8971 /dev/dri/card0 [08:20] mir_demo_ 8375 root 9u CHR 226,0 0t0 8971 /dev/dri/card0 [08:20] mir_demo_ 8375 root 10u CHR 226,0 0t0 8971 /dev/dri/card0 [08:20] ouch [08:20] sorry [08:20] :// [08:20] it was huge [08:21] duflu: sync_counter? [08:21] hikiko: yeah you still had some stuff open, can only run 1 at the same time [08:21] alan_g: I think frame number is more self explanatory [08:21] mlankhorst, it seems that I have plymouth running after all :) [08:21] indeed! [08:24] duflu: ok [current|local|global]_frame_number [08:25] tvoss: Do you want timerless done before we declare MM feature complete? [08:25] It's not really critical [08:26] duflu, let's get it in if it does not break us [08:26] tvoss: Still working on fixing it tho [08:26] 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] duflu, don't block on it [08:27] I dont know if what I wrote makes sense :p [08:27] hikiko: there can only be 1 master [08:27] and when you set the version you have to be the master? [08:27] yes [08:27] and if nobody has the device opened, you automatically become master [08:27] 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] then ok it's normal that only nested mir has the error [08:28] yeah, I tag on mondays [08:28] because in my case I am not and I don't want to become the master [08:28] duflu, you haven't landed MM right? [08:28] robert_ancell: I said lp:mir where it landed weeks ago [08:28] oh, right [08:29] hikiko: yeah if you get the fd from someone else, presumably you're already authenticated. it's a silly concept :P [08:29] sil2100: But ask RAOF when the XMir parts are landing... [08:30] hikiko: ( mlankhorst ) the fd should come from the hosting Mir session [08:30] alan_g: Actually I just noticed freezing the count doesn't always freeze rendering. It probably should. So fixing... [08:31] duflu: ok, anything else needs landing? Anything in u-s-c? [08:31] robert_ancell, ^ [08:31] 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] sil2100, lp:unity-system-compositor and lp:lightdm are all up to date [08:31] so while my device can be used I dont have the permission (since I am not a master) to set the version [08:32] hikiko: you can get a pre-authorised from mir_connection_drm_auth_magic() [08:32] yes [08:32] but I don't want to do this [08:32] because I need to see on the screen [08:33] (host mir does the rendering/vt etc) [08:34] what does mir_connection_drm_auth_magic() do exactly? [08:34] hikiko: authenticate [08:34] which involves guessing a 32-bit integer iirc [08:35] yes, in nested mir I only authenticate when I need to use the display [08:36] and I guess that's correct, because if nested mir is the master then the host mir won't render anymore [08:36] and I will see a freeze [08:36] isnt it? [08:36] authenticate != master [08:37] then authentication doesn't solve the problem with the interface version [08:37] mlankhorst: Did you get to test MM+nouveau? [08:37] the initial problem was that I couldnt call the drmSetInterfaceVersion without being the master [08:38] the host remains master, but gives the nested the fd it needs. The host sets the interface version nested [08:38] nested doesn't need to [08:38] RAOF: i was busy with llvm and tjaalton's stuff :P [08:38] mlankhorst: Yeah, thought so. [08:39] alan_g, the problem is that in drm helpers we call the setInterface when we open the drm device [08:39] which is before authentication anyway [08:39] and we use that code to check if the device we already opened [08:39] is "usable" [08:39] sorruy meeting brb [08:40] hikiko: even authentication is not enough, requires master [08:41] 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] currently I do: open_drm_device [08:41] amd then authentication [08:41] mlankhorst: that's what I understand hikiko needs for nested. It is "just" an auth client [08:42] indeed [08:42] but drmSetVersion requires master :P [08:42] so just kill it [08:42] hikiko: don't do that - just get the fd from the master [08:42] yes :) [08:42] that's what I did [08:43] ok so erm nouveau mm testing.. [08:43] alan_g, I cant get the fd from the master [08:44] the master must use it's own gbm device [08:44] because it might have other clients instead of mir on mir [08:44] hikiko: Aren't you getting the drm fd from the PlatformPackage? [08:45] PlatformIPCPackage? [08:46] MirPlatformPackage, from mir_connection_get_platform [08:46] no because I don't get the platform [08:46] I create a native platform [08:46] that has it's own buffers [08:46] I don't use mir buffers [08:47] And you can't get the platform first? [08:47] 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] And then allocate buffers to your heart's content. [08:47] RAOF: that's exactly what we want [08:48] yes but the design we did was to have a native platform etc alan_g [08:49] hikiko: What has that to do with this? [08:51] The native platform needs an FD. mir_connection_get_platform (I had the wrong function before) gets that FD [08:51] RAOF: single monitor works :P [08:52] RAOF, what changes in Mir do you need landed for mm? [08:52] tvoss: NOne [08:52] yes just checking the MirPlatformPackage struct alan_g [08:52] hm didn't crash on hotplug [08:53] mlankhorst: And is displaying roughly correctly? [08:53] RAOF, will this platform package give me the drm device of the host mir? [08:53] RAOF: it would seem so [08:53] mlankhorst: SHIP IT! [08:53] because this is not what I want [08:53] hikiko: No, it won't give you the same drm fd that the host mir has open. [08:54]