| 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:00 |
| bschaefer | annd yeah changing the res sends me back to lightdm | 00:02 |
| bschaefer | RAOF, if you're interested in the stacktrace in my Xorg.0.log: | 00:05 |
| bschaefer | http://paste.ubuntu.com/6038469/ | 00:05 |
| RAOF | Ta. | 00:08 |
| 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:11 |
| 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:13 |
| bschaefer | let me see if I can get a real backtrace... | 00:14 |
| bschaefer | as that one is pretty useless :) | 00:14 |
| bschaefer | RAOF, hmm I don't seem to have a *.crash file from today ... besides the hud service... | 00:16 |
| RAOF | Delete any existing Xorg crash file, and then crash it again :) | 00:17 |
| bschaefer | alright! | 00:17 |
| bschaefer | RAOF, cool got a *.crash file, now to run it through apport... | 00:30 |
| 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:31 |
| bschaefer | RAOF, http://i.imgur.com/dKiZNKY.jpg | 00:37 |
| bschaefer | when it does work | 00:37 |
| RAOF | 404'd! | 00:37 |
| bschaefer | :( | 00:37 |
| * bschaefer tries a different site? | 00:38 | |
| bschaefer | RAOF, or possibly this: http://imgur.com/dKiZNKY | 00:38 |
| RAOF | Whee! | 00:39 |
| bschaefer | strange, o well but yeah, I think I saw similar rendering issue with other testers? | 00:39 |
| bschaefer | but things are rendering fine when I don't force the res | 00:40 |
| bschaefer | :( | 00:47 |
| bschaefer | Backtrace stopped: previous frame inner to this frame (corrupt stack?) | 00:47 |
| RAOF | :( | 00:51 |
| RAOF | bschaefer: There'll be a shiny new -ati to test in qa-testing2 shortly. | 00:52 |
| bschaefer | sweet, I can give that run | 00:53 |
| * bschaefer attempts the apport-retrace again...for the hell of it | 00:53 | |
| 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:03 |
| RAOF | bschaefer: That would be correct, yes. | 01:12 |
| RAOF | bschaefer: You're looking for xserver-xorg-video-radeon 7.2.0-0ubuntu3+xmirMM4 | 01:13 |
| 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:14 |
| bschaefer | cool, ill test it out after this (hopefully) new retrace attempt | 01:15 |
| bschaefer | hopefully successful* | 01:15 |
| bschaefer | RAOF, stracktrace: http://paste.ubuntu.com/6038660/ | 01:23 |
| bschaefer | pid = -1222160384 | 01:24 |
| bschaefer | doesn't like good :) | 01:24 |
| 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:25 |
| bschaefer | sweet, let me give that a run | 01:26 |
| * bschaefer reboots | 01:29 | |
| 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:37 | |
| bschaefer | RAOF, http://paste.ubuntu.com/6038680/ | 01:38 |
| 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:39 |
| 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:40 |
| bschaefer | alright, ill give that a try then | 01:41 |
| 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:44 |
| bschaefer | RAOF, hmm let me past the xorg log/dmesg but Its hard to read them with such a small screen :) | 01:46 |
| RAOF | You should be able to just use pastebinit, right? | 01:47 |
| bschaefer | yeah I can: http://paste.ubuntu.com/6038693/ | 01:47 |
| * bschaefer likes to be able to attempt to read them | 01:48 | |
| bschaefer | dmesg: http://paste.ubuntu.com/6038696/ | 01:50 |
| * bschaefer looks at the kern log | 01:50 | |
| RAOF | Ah. You haven't tried to change the mode yet? | 01:54 |
| bschaefer | RAOF, ? | 01:54 |
| 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:55 |
| * bschaefer attempts the mode change again looking at the current time... | 01:56 | |
| bschaefer | RAOF, hmm my Xorg has the correct time, but I don | 02:02 |
| bschaefer | dont see it trying to set it... | 02:02 |
| RAOF | That is odd. | 02:04 |
| bschaefer | i have a bunch of extra bytes at the end of the file though... | 02:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| bschaefer | RAOF, would setting the drm.debug thing even work for this? | 02:11 |
| * bschaefer also forgot the path to it...and does't have the log saved | 02:12 | |
| * bschaefer found it.. | 02:13 | |
| bschaefer | well wouldnt hurt | 02:13 |
| bschaefer | RAOF, yay the Xorg log is showing it now... | 02:21 |
| RAOF | Woot! | 02:21 |
| bschaefer | http://paste.ubuntu.com/6038776/ | 02:21 |
| bschaefer | but no errors in it... | 02:22 |
| bschaefer | at lease that I see :) | 02:23 |
| * bschaefer wonders if its having a problem cause one monitor is still the 640x480 res | 02:26 | |
| bschaefer | as things are mirrored atm | 02:27 |
| RAOF | Hrm. Stupid qa-testing2 ppa building against the archive... | 02:31 |
| RAOF | Hm. Ok, that looks pretty standard. | 02:32 |
| * RAOF wonders if he can trigger this on his radeon. | 02:32 | |
| 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:33 |
| bschaefer | RAOF, well im going to head off for the night and eat some dinner, hopefully its reproducible else where :) | 02:35 |
| 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:36 |
| RAOF | Yay! Reproducible locally! | 02:40 |
| kgunn | RAOF: did anyone tell you?....nouvea w/ latest drivers from qa-testing2 will boot to usable unity single screen | 02:49 |
| 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 | 02:50 |
| === chihchun_afk is now known as chihchun | ||
| duflu | robert_ancell: I only heard underwater mumbles half the time :/ | 03:35 |
| robert_ancell | duflu, awesome | 03:36 |
| robert_ancell | :) | 03:36 |
| duflu | robert_ancell: So which should I expect to be landing first? bypass or timerless? | 03:43 |
| robert_ancell | duflu, probably bypass | 03:43 |
| 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 | 03:44 |
| tvoss__ | good morning | 04:28 |
| tvoss__ | RAOF, ping | 04:31 |
| RAOF | tvoss__: Pong. | 04:31 |
| robert_ancell | bbiab | 04:35 |
| tvoss__ | kgunn, ping | 04:36 |
| kgunn | tvoss__: pong | 04:38 |
| mlankhorst | morning | 05:17 |
| RAOF | mlankhorst: Speak of the devil! | 05:23 |
| * robert_ancell -> dinner etc, will be back later | 05:27 | |
| duflu | Oh multi-monitor is so much less annoying when none of them are analog VGA | 05:29 |
| RAOF | Yeah, I'm trying to rid the world of VGA interfaces. | 05:32 |
| duflu | Especially when my oldest monitor misdetects the VGA signal most of the time | 05:33 |
| RAOF | You know, it'd be much easier to debug bypass if my radeon card didn't work perfectly with it. | 05:34 |
| duflu | RAOF: Good to hear, kinda. I'm working on a setup to try radeon+saucy here too | 05:45 |
| duflu | Oh, new saucy wallpapers?! | 05:47 |
| duflu | Ahem, wallpapers for saucy | 05:48 |
| RAOF | To the multi-monitor-bypass-testotron! | 05:48 |
| RAOF | Heh. | 05:48 |
| duflu | RAOF: Do you have a solid indication it is bypassing on radeon? Like performance? | 05:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| duflu | brb | 05:58 |
| mlankhorst | RAOF: did you upload a version bump to mir so it's easier to test? :p | 05:59 |
| RAOF | No; I'll do so now. | 06:00 |
| * mlankhorst slowly wakes up | 06:03 | |
| RAOF | mlankhorst: Got any idea what might cause this: http://ubuntuone.com/08RzJfgwUfZd1LigIS16Mh particularly fun brand of misrendering? | 06:22 |
| mlankhorst | RAOF: forgetting to flush maybe? | 06:25 |
| RAOF | That thought occurred | 06:26 |
| mlankhorst | try damaging the whole screen and see what happens.. | 06:27 |
| mlankhorst | hm compiz already should, though | 06:27 |
| duflu | mlankhorst: I tried that. No change | 06:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| duflu | brb | 06:33 |
| RAOF | mlankhorst: xserver MM16 awaits your attention | 06:34 |
| mlankhorst | what do you want me to test? | 06:34 |
| RAOF | nouveau MM | 06:35 |
| RAOF | If that didn't work before. | 06:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:45 |
| mlankhorst | I suppose I could make a MIR for it, but I feel it's a bit of overkill | 06:46 |
| mlankhorst | bah it moved llvm-toolchain-3.3 back to universe | 06:47 |
| tvoss | duflu, one thing I noticed yesterday: we never "release" the BufferObject for the scanout bo | 06:51 |
| 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:52 |
| tvoss | duflu, as I understand it, the buffer object is never released until destruction | 06:54 |
| 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:55 |
| 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:56 |
| 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 | 06:57 |
| RAOF | If we used overlays then we *could* be compositing and bypass at the same time. | 07:03 |
| duflu | ... it opens up doors like Mir supporting non-GL platforms in a limited fashion | 07:04 |
| * 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:05 |
| duflu | BTW, I think I observed a noticeable improvement with timerless on radeon with dual monitors. I think... | 07:18 |
| sil2100 | Hi everyone | 07:30 |
| duflu | sil2100, morning | 07:31 |
| sil2100 | Did all the branches needed for bypass and multimonitor get merged into trunks already? | 07:32 |
| 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:33 |
| duflu | sil2100: Yep | 07:51 |
| hikiko | hi, question: what's the drm interface version? is it the library version or something else? | 07:52 |
| 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:53 |
| 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:55 |
| mlankhorst | just assume it's supported tbh | 07:56 |
| 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 | 07:57 |
| 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:00 |
| duflu | Will do | 08:01 |
| hikiko | thanks! | 08:01 |
| duflu | hikiko: Could that explain the strange DRM open failures some nvidia users get? | 08:02 |
| mlankhorst | duflu: that's.. more complicated | 08:03 |
| mlankhorst | but link a bug? | 08:04 |
| duflu | mlankhorst: bug 1206633 | 08:04 |
| ubot5 | bug 1206633 in Mir "mir doesn't start "Error opening DRM device" on nVidia" [Medium,Triaged] https://launchpad.net/bugs/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:04 |
| mlankhorst | some calls require DRM_MASTER, but meh | 08:06 |
| duflu | Which we have, maybe not soon enough? | 08:07 |
| 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:08 |
| mlankhorst | duflu: it's complicated, there used to be a race between xorg-server, lightdm and plymouth, where lightdm could not detect plymouth.. | 08:11 |
| * 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:12 |
| 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:13 |
| duflu | hikiko: You got the same exception with errno==0 ? | 08:14 |
| 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:15 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| alan_g | duflu: ok [current|local|global]_frame_number | 08:24 |
| duflu | tvoss: Do you want timerless done before we declare MM feature complete? | 08:25 |
| duflu | It's not really critical | 08:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| hikiko | (host mir does the rendering/vt etc) | 08:33 |
| 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:34 |
| hikiko | yes, in nested mir I only authenticate when I need to use the display | 08:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| mlankhorst | hikiko: even authentication is not enough, requires master | 08:40 |
| 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:41 |
| 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:42 |
| mlankhorst | ok so erm nouveau mm testing.. | 08:43 |
| hikiko | alan_g, I cant get the fd from the master | 08:43 |
| 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:44 |
| hikiko | PlatformIPCPackage? | 08:45 |
| 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:46 |
| 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:47 |
| hikiko | yes but the design we did was to have a native platform etc alan_g | 08:48 |
| alan_g | hikiko: What has that to do with this? | 08:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| mlankhorst | looks like xorg didn't crash either :O | 08:59 |
| 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:00 |
| mlankhorst | now the same, but with valgrind >:O | 09:01 |
| RAOF | mlankhorst: My code laughs at your petty memory-correctness tools! | 09:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| * 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| hikiko | because you are not the master | 09:14 |
| hikiko | thats the problem | 09:14 |
| alan_g | hikiko: didn't we already solve that? | 09:14 |
| alan_g | <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:14 |
| hikiko | alan_g, yes but RAOF asked which is the problem | 09:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| hikiko | alan_g, RAOF then maybe better to give it a try | 09:19 |
| duflu | Hah. Don't google saucy wallpapers | 09:27 |
| 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:32 |
| RAOF | I'm talking with ickle in #intel-gfx; the horizontal bar corruption we see is stale cachelines. | 09:33 |
| 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:34 |
| 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:35 |
| duflu | Sounds hackish | 09:36 |
| RAOF | Yeah. | 09:36 |
| duflu | That reminds me, I must improve the examples/ to help with that | 09:36 |
| 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:37 |
| 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:38 |
| 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:40 |
| 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:45 |
| 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:46 |
| 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:47 |
| * 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 | 09:48 |
| duflu | tvoss, RAOF: Any objections to me logging off? I may yet cook dinner | 10:08 |
| RAOF | duflu: None from my end? | 10:08 |
| 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:11 |
| 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:12 |
| duflu | RAOF: Also lp:~vanvugt/mir/eglapp-place-output | 10:14 |
| === chihchun is now known as chihchun_afk | ||
| RAOF | mlankhorst: Oh, where is your current xf86-video-nouveauL? | 10:55 |
| 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:57 |
| alan_g | hikiko: there are some MPs you can review too. ;) | 10:58 |
| hikiko | I am going to pull them alan_g :) | 10:58 |
| mlankhorst | RAOF: ..? | 11:07 |
| RAOF | mlankhorst: Yours is the last upload to qa-testing2; I want to prepare that for the archive. | 11:07 |
| 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:08 |
| hikiko | alan_g, how can I run the mir tests? | 11:21 |
| alan_g | hikiko: how long have you been on the project?! | 11:21 |
| alan_g | hikiko: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864/comments/414597 | 11:22 |
| === hikiko is now known as hikiko|lunch | ||
| tvoss_ | RAOF, mlankhorst sent you some packages for testing purposes | 11:45 |
| mlankhorst | yeah he should have them | 11:45 |
| 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:46 |
| * alan_g suddenly realises that we don't run the test suite for clang or android/armhf targets in CI | 11:52 | |
| === alan_g is now known as alan_g|lunch | ||
| mlankhorst | mir should really have -dbg packages | 12:05 |
| mlankhorst | and usc too | 12:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| mlankhorst | nn | 12:12 |
| tvoss_ | RAOF, good night and get well soon | 12:17 |
| mlankhorst | interesting, I'm hitting a bug in vblanking somewhere | 12:22 |
| mlankhorst | probably | 12:22 |
| tvoss_ | mlankhorst, with my testing packages | 12:23 |
| mlankhorst | I'm not sure what's causing it yet, but it seems some event is not being sent, ever ;P | 12:26 |
| tvoss_ | mlankhorst, interesting | 12:27 |
| === hikiko|lunch is now known as hikiko | ||
| mlankhorst | hm might be a hang, bah | 12:33 |
| mlankhorst | ok other card | 12:36 |
| tvoss_ | mlankhorst, ;) | 12:37 |
| mlankhorst | >:( | 12:37 |
| mlankhorst | there seems to be a memory corruption affecting all cards, but I don't know how | 12:38 |
| === alan_g|lunch is now known as alan_g | ||
| kgunn | hikiko: ping | 13:09 |
| hikiko | kgunn, hi | 13:14 |
| mlankhorst | wow.. | 13:21 |
| tvoss_ | mlankhorst, ? | 13:24 |
| mlankhorst | I may have found my nouveau issue, lets find out.. | 13:26 |
| mlankhorst | hm no, still no closer :/ | 13:29 |
| 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:54 |
| 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:56 |
| mlankhorst | hehe np :P | 13:57 |
| 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:58 |
| 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 | 13:59 |
| tvoss_ | mlankhorst, ack | 14:00 |
| mlankhorst | so right in time for feature freeze this time | 14:01 |
| kgunn | sil2100: yes | 14:02 |
| mlankhorst | tvoss_: hey last release we landed 9.1 right before final freeze | 14:02 |
| kgunn | hikiko: i just realized i'm on the hook for a uds session | 14:10 |
| hikiko | :) | 14:11 |
| hikiko | no problem kgunn | 14:11 |
| mlankhorst | unfortunately I cna't make any session this week, g2g :/ | 14:12 |
| kgunn | hikiko: oh...wait...i was wrong...top of the hour....we're still on | 14:15 |
| === alan_g is now known as alan_g|tea | ||
| jono | tvoss_, hey | 14:38 |
| jono | so the composite bypass lands today? | 14:38 |
| === alan_g|tea is now known as alan_g | ||
| tvoss_ | jono, yup | 14:44 |
| 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:55 |
| 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 | 14:56 |
| olli | smartboyhw, no, it will need to be in main first before being pulled in as default | 15:53 |
| ricmm | tvoss_: ping | 16:29 |
| tvoss_ | ricmm, pong | 16:29 |
| 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:30 |
| tvoss_ | ricmm, not really, would be great if we can live a week without it | 16:31 |
| ricmm | not sure how possible that is going to be with the OSK | 16:32 |
| ricmm | we will try today, but not sure | 16:32 |
| === alan_g is now known as alan_g|beer | ||
| === marrusl is now known as marrusl_afk | ||
| === marrusl_afk is now known as marrusl | ||
| arsson | latest updates makes my cursor freeze in lightdm with nouveau? | 23:33 |
| RAOF | arsson: Updates from where? | 23:40 |
| arsson | RAOF: basic no ppa | 23:54 |
| 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:58 |
| 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 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
