[00:01] <robert_ancell> brb
[00:02] <RAOF> arsson: Did you restart lightdm?
[00:03] <RAOF> If not, you'll still be running unity-system-compositor+XMir, and you'll have hit the bug where usc stops rendering for no obvious reason.
[00:06] <arsson_> Sorry i use huawei stick and it constantly disconnect
[00:33] <bschaefer> RAOF, hey, what were the functions I should be looking at in radeon.ko? (if you know off the top of your head)
[00:33] <bschaefer> as im just getting to digging through them, and ill have the weekend to poke around as well :)
[00:33] <RAOF> bschaefer: You'd be looking at create_dumb and map_dump
[00:33] <RAOF> bschaefer: You'd be looking at create_dumb and map_dumb
[00:33] <bschaefer> RAOF, awesome, thanks!
[00:33]  * bschaefer didn
[00:33] <RAOF> They might not be called that, but they'll be something like that.
[00:33]  * bschaefer didn't have the logs being saved...
[00:34] <bschaefer> RAOF, and they are getting called through mmap, from mesa?
[00:34] <RAOF> You can also chase them through drm_drv.c; work out what radeon hooks up to those ioctls.
[00:34] <bschaefer> to see where its getting the offset from?
[00:34]  * RAOF forgets where it's getting the offset from.
[00:34]  * bschaefer should also dig through how each of these things are connected
[00:35] <bschaefer> well  more about digging through the ioctls to figure out where a possible incorrect argument could be generated
[00:35] <bschaefer> so the 2 functions i should dig through from the top would be drmIoctl, and mmap
[00:35] <RAOF> Ah, yeah.
[00:35] <bschaefer> cool, thanks! (i have logging set on now so I can revisit this conversation :)
[00:35] <RAOF> create_dumb and map_dumb are what you're fater.
[00:36] <bschaefer> cool, yup those are in mesa, but ill have to dig to where my card is setting things up as well...cause it has to be with the evergreen family, or possibly just the redwood ones
[00:36] <bschaefer> (where my card == where the driver)
[00:37] <bschaefer> RAOF, also, any luck reproducing the monitor issue on your ATI machine?
[00:37] <RAOF> bschaefer: The resolution change thing? Yeah, it's fixed.
[00:38] <bschaefer> RAOF, sweeet! what was the issue?
[00:38] <bschaefer> if its not tooo complicated haha
[00:39] <RAOF> bschaefer: More than just the root window uses the screen pixmap as its backing; so there was a valid new screen pixmap and root window that XMir was copying out of, but we hadn't fixed up other pixmaps, such as the one that Compiz renders into.
[00:41] <bschaefer> so one was trying to render to the wrong size? but cool!
[00:42]  * bschaefer goes to read the branch more or less
[00:46] <RAOF> They were totally disconnected.
[00:46] <RAOF> Compiz was rendering into one pixmap, XMir was copying out of another.
[00:47] <bschaefer> oo, so it was just copying garbage pixels/data, while compiz was rendering into a pixmap that wasn't being drawn
[00:48] <RAOF> Yeah.
[00:49] <bschaefer> well know I know what that looks like haha
[02:03] <RAOF> Hm. Do we have any guarantee about ordering of messages at all?
[02:03] <RAOF> Specifically - if I'm a client with more than one surface (like, say XMir), and focus switches from one of my surfaces to another, what are the states that I can see?
[02:04] <RAOF> Can I see ‘both of my surfaces are focused’? Can I see ‘neither of my surfaces are focused’?
[02:05] <RAOF> On the server side we guarantee that the two states are ‘surface A is focused, surface B is unfocused’ and ‘surface B is focused, surface A is unfocused’; are there any similar guarantees on the client side?
[02:34] <duflu> RAOF: That's why I rejected the focus notification design (which landed)
[02:35] <RAOF> duflu: Ah. That wasn't obvious to me from your comments.
[02:35] <duflu> RAOF: Yeah, but it's a natural side effect from the concerns I was raising
[02:35] <duflu> It landed, but I think still needs rewriting
[02:35] <RAOF> True. Just not a side effect I actually thought of.
=== chihchun_afk is now known as chihchun
[02:41] <duflu> RAOF: You can heuristically make a good guess of which surface has focus. But I suggest logging it as a bug. We need a definitive "one focus message" relative to the connection/session. Or a get_focused_surface
[02:42] <duflu> You could just ignore all the unfocus messages and take the focus messages in order...
[02:43] <RAOF> Unless you want to know when *none* of your surfaces are focused.
[02:54] <duflu> RAOF: if (focused_surface_id in (any of mine)) ?
[02:55] <RAOF> I'll get two events.
[02:55] <RAOF> One is "surface A lost focus"
[02:55] <RAOF> Another is "surface B gained focus"
[02:56] <duflu> RAOF: Just ignore the lost focus messages I guess. Take the gained focus messages in order and assume it's impossible to have nothing focused
[02:56] <RAOF> But it's explicitly possible to have nothing focused.
[02:56] <duflu> Yes, I just realized :(
[02:57] <RAOF> This is not something that should actually cause a problem for me, just interesting.
[02:57] <RAOF> Is there a standard C atomic ops library in main?
[03:00] <duflu> RAOF: sigatomic_t for an int. Otherwise pthread.h :)
[03:01] <RAOF> Or libatomic-ops
[03:15] <duflu> Yeah. Sorry, I'm in the habit of finding portable solutions... which work on all platforms. Not just Linux
[03:26] <duflu> RAOF: Any more thoughts on intel cache issues?
[04:14] <tvoss_> good morning
[04:19] <tvoss_> duflu, RAOF o/
[04:19] <RAOF> Morn.
[04:21] <duflu> tvoss_, Morning-ish
[04:21] <tvoss_> RAOF, duflu how is it going?
[04:22] <duflu> tvoss_: OK. Back to just figuring out bugs now  :)
[04:22] <tvoss_> duflu, :)
[04:26] <RAOF> Doing the XMir work to fix input-after-VT-switch.
[04:39]  * duflu goes to find lunch and /professional/ coffee :)
[04:54] <tvoss_> duflu, professional coffee ... a very nice term
[05:01] <duflu> RAOF: Still around?
[05:09] <RAOF> duflu: Yeah
[05:09] <RAOF> duflu: What's up?
[05:10] <duflu> RAOF: I just noticed... with the damaged/stripey cursor...
[05:10] <duflu> RAOF: The artefacts last _many_ frames. Much longer than 3. So that suggests it's indeed not related to buffer ordering.
[05:11] <RAOF> Which damaged/stripy cursor is this?
[05:11] <duflu> RAOF: intel "caching" artefacts ickle mentions
[05:11] <duflu> mentioned
[05:12] <RAOF> Oh, yeah.
[05:12] <duflu> I'm sanity checking to try and find related bugs in the Mir server still
[05:12] <RAOF> You probably won't see them with two full-screen egltriangles, either; you want to be doing *lots* of drawing.
[05:12] <RAOF> Like X window → compiz → root window → Mir. ☺
[05:13] <duflu> RAOF: How different to filling the screen? Stressing the GPU?
[05:13] <RAOF> Lots of memory access, I think.
[05:13] <duflu> RAOF: Oh, texturing?
[05:13] <RAOF> That'd be an easy way to generate lots of memory access, yes.
[05:14] <RAOF> It's *possible* that EGL Mir clients won't trigger this; there's apparently some effort taken in mesa to make this work.
[05:14] <RAOF> Although totally untested, because X does it.
[05:17] <duflu> I'm also trying to find a way to separate those artefacts from frame ordering issues
[05:18] <duflu> It would be nice to see only one bug at a time
[05:19] <RAOF> Yes.
[05:21] <duflu> Woo, easily separated
[05:26] <tvoss> woot :)
[05:26] <tvoss> sdl1.2 with Mir support & nexuiz -> win
[05:31] <RAOF> libatomic-oops
[05:35] <tvoss> RAOF, :)
[05:40] <Mirv> is there a way to get the same mirror mode that was before the multimonitor support? xrandr --output XMIR-2 --same-as XMIR-0 gives me something that is clipped on the lower resolution screen, but still has the same artifacts/slowness as with dual screen. before multimonitor support I had artifact free mirror mode where the lower resolution screen was displayed with grey borders on the higher resolution screen
[05:41] <duflu> Mirv: Not sure. I agree the mirroring was perfect before XMir became MM-aware :/
[05:43] <Mirv> duflu: heh, true
[05:43] <Mirv> the new mirroring is actually near unusable, while the dual screen is about usable still, with some slowness and artifacts. I think I'll use that for now.
[05:43] <Mirv> it's nice to have the fullhd back, to counter the minus sides
[05:46] <duflu> Mirv: If you want to vote... please do so on bug 1216472 and bug 1218735
[05:46] <duflu> :)
[05:46] <ubot5> bug 1216472 in mir (Ubuntu) "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,Confirmed] https://launchpad.net/bugs/1216472
[05:46] <ubot5> bug 1218735 in XMir "[intel] Bypass mode makes the cursor break up into horizontal line artefacts" [High,New] https://launchpad.net/bugs/1218735
[05:47] <Mirv> yeah :)
[05:48] <Mirv> yay for workarounds
[05:51] <duflu> Mirv: Also vote: bug 1217917
[05:51] <ubot5> bug 1217917 in XMir "XMir Multimonitor Not possible to select "Mirror Displays" in setting." [Undecided,Confirmed] https://launchpad.net/bugs/1217917
[05:56] <Mirv> mm. I'm an experimental person so I tried killall unity-system-compositor. no it did not gracefully restart, but now I've missing input methods in VT7 (lightdm) even after multiple reboots. any idea what could be wrong?
[05:56] <Mirv> it types in lightdm though everything that I type here
[05:56] <Mirv> but I can't type or move mouse if I move to VT7
[05:58] <duflu> Also no idea.
[05:58] <duflu> RAOF: Did you observe Mir giving XMir 2 or 3 unique buffers?
[07:00] <dholbach> good morning
[07:20] <tvoss_> duflu, RAOF you guys still around?
[07:21] <duflu> tvoss_: Yes. And finally got XMir running in my own development Mir server so I can examine it :)
[07:21] <tvoss_> duflu, \o/
[07:21] <duflu> XMir in mir_demo_server_shell is kind of funky
[07:24] <tvoss_> duflu, I can imagine :) I had nexuiz running mir_demo_server_shell an hour ago, quite funky, too
[07:24] <duflu> I can drag my X outputs on top of each other... it's not natural
[07:26] <tvoss_> duflu,  :)
[07:26] <tvoss_> mind taking a crappy video with your mobile?
[07:28] <duflu> tvoss_: That would appear to require 4 hangs right now :(
[07:28] <duflu> *4 hands
[07:29] <tvoss_> duflu, indeed :)
[07:29] <tvoss_> duflu, cancel that then
[07:34] <tvoss_> duflu, what is the status for the artifacts with bypass? can that be attributed to the cursor?
[07:34] <duflu> tvoss_, RAOF said that ickle said it was a quirk of the intel driver. Requires some workarounds
[07:34] <tvoss_> duflu, ack. Do we have a bug open?
[07:34]  * duflu shrugs
[07:35] <duflu> tvoss_: bug 1218735
[07:35] <ubot5> bug 1218735 in XMir "[intel] Bypass mode makes the cursor break up into horizontal line artefacts" [High,New] https://launchpad.net/bugs/1218735
[07:35] <tvoss_> duflu, thx
[07:39] <tvoss_> duflu, do we have a bug open for fullscreen games running at non-native resolution not benefitting from composite bypass?
[07:40] <duflu> tvoss_: No. I also haven't thought about it for a while. It's really all XMir I think
[07:40] <tvoss_> duflu, ack
[08:24] <dholbach> hey hey
[08:24] <dholbach> does anyone else have a bit of flickering with the cursor?
[08:26] <tvoss_> dholbach, yeah, known issue: bug 1218735
[08:26] <ubot5> bug 1218735 in XMir "[intel] Bypass mode makes the cursor break up into horizontal line artefacts" [High,New] https://launchpad.net/bugs/1218735
[08:26] <dholbach> thanks!
[08:26] <tvoss_> dholbach, please upvote it, will take some dancing with the Intel driver. RAOF has checked in intel-x
[08:26] <dholbach> upboat!
[08:34] <duflu> RAOF: OK, I'm logging all the XMir buffer actions. The compositor is acquiring/releasing in exactly the same order as the client. Even though I *see* incorrect ordering :(
[08:37] <alan_g> duflu: you're assuming a consistent sequential ordering. Einstein disproved that a century ago.
[08:39] <tvoss_> duflu, if that is the case, then XMir is jumbling up the frame order somewhere, isn't it?
[08:39] <duflu> tvoss_: That would be the conclusion. Assuming I'm right. Still trying to prove myself wrong
[08:39] <tvoss_> duflu, ack
[08:40] <tvoss_> duflu, mind summarizing how you report acquisition/release and how you assert that it is in the correct order?
[08:40] <duflu> tvoss: fprintf() says for each Switching bundle, the order of client/compositor acquire/releases is always 0,1,2,0,1,2
[08:41] <duflu> Maybe it's rarer than I think. I need to search for glitches programatically
[08:41] <tvoss_> duflu, yeah, just assert if the order is violated and run phoronix or glmark in xmir
[08:41] <tvoss_> duflu, putting load on x is usually a good way to trigger the issue
[08:42] <duflu> tvoss_: I can trigger it. I can see it.
[08:42] <duflu> tvoss_: I'm talking about the frame ordering bug, not the cursor bug
[08:42] <tvoss_> duflu, likewise, I thought you couldn't see it
[08:43] <duflu> tvoss_: I can't see it without XMir. Now I have XMir running in my dev server
[08:43] <tvoss_> duflu, yeah
[08:48] <duflu> I can see the compositor spinning through frames much faster than XMir provides them. But still the same order. The compositor just reuses the last one
[08:51] <tvoss_> duflu, shouldn't we only composite if there is a new frame?
[08:52] <duflu> tvoss_: Yes, but there's something funny with XMir multimonitor triggering redraws on all outputs even when only one screen is changing. I think that used to be a unityshell bug.
[08:53] <tvoss_> duflu, okay
[08:53] <duflu> Hmm
[08:53]  * duflu tries without Unity
[08:53] <tvoss_> duflu, I was just about to propose that
[08:53] <tvoss_> xfce without comp ftw :)
[08:53] <tvoss_> then with comp
[09:04] <tvoss_> \o/
[09:14] <duflu> tvoss_, ?
[09:15] <tvoss_> duflu, completed the first set of nexuiz/openarena benchmarks against native mir with bschaefer's sdl1.2 adjustments
[09:16] <duflu> Oh cool
[09:16] <duflu> Should be blazing fast
[09:16] <duflu> Hopefully
[09:16] <duflu> tvoss_: And yes, no ordering problems with Xfce in XMir
[09:17] <tvoss_> duflu, it is
[09:17] <tvoss_> duflu, verifying the numbers now
[09:17] <tvoss_> duflu, in the multi-monitor case, right?
[09:17] <tvoss_> duflu, did you enable composition in xfce?
[09:17] <duflu> tvoss_: Although I'm seeing very strange X damage artefacts. Yes, all multimonitor
[09:18] <duflu> tvoss_, composition?
[09:18] <duflu> I need to run in a minute
[09:19] <tvoss_> duflu, xfce has got a compositor, too
[09:19] <tvoss_> duflu, by default, it is switched off iirc
[09:22] <duflu> And out of time. I have real life to catch up on...
[09:48] <RAOF> Hey, what? Why does mir_surface_set_event_handler not take a void *ctx?
[09:48] <RAOF> What does the event handler get called with?
[09:48] <mlankhorst> tvoss_: could you send a new build for glmark? :P
[09:49] <tvoss_> mlankhorst, yeah, on it :)
[09:53] <RAOF> And with that, it's EOW
[09:53] <tvoss_> RAOF, enjoy your weekend :)
[09:56] <mlankhorst> sort of same for me, but I left early yesterday so I want to make up by engaging some phoronix mode :P
[09:56] <mlankhorst> write an email about glmark2 nouveau xmir vs mir, bahah
[10:00] <tvoss_> mlankhorst, compiling
=== jibel_ is now known as jibel
[10:49] <discopig> hi
[11:02] <tvoss_> discopig, hey
=== hikiko is now known as hikiko-lunch
=== hikiko-lunch is now known as hikiko
=== alan_g is now known as alan_g|lunch
[12:21] <hikiko> hi, I performed a dist-upgrade a while ago (i386) and since then the vt switch doesn't work in any mir branch (even when I use a fresh clone of trunk) does anyone have the same problem?
=== alan_g|lunch is now known as alan_g
[13:15] <alan_g> hikiko: are you running the server without root?
[13:16] <hikiko> no
[13:16] <hikiko> I reboot and fixed
[13:44] <tvoss_> mlankhorst, ping
[13:57] <smspillaz> RAOF: it takes a void * I'm pretty sure
[13:58] <smspillaz> RAOF: ah wait, it doesn't, but MirEventDelegate is defined as struct { event_handler_func func; void *ctx }
[14:04] <tvoss_> smspillaz, ping
[14:04] <tvoss_> smspillaz, you around for a bit?
[14:08] <smspillaz> tvoss_: a little bit
[14:19] <smspillaz> tvoss_: .. still here
[14:19] <tvoss_> smspillaz, yup, otp right now :) would like to talk about cursors and touches and motion events
[14:19] <smspillaz> ah okay. I can only talk over IRC at the moment - I've got a bad cold
[14:20] <tvoss_> smspillaz, sure, irc is fine with me
[14:20] <smspillaz> tvoss_: ... although I'll be going to bed soon. It might be better to send me an email or send an email to the list?
[14:20] <tvoss_> smspillaz, list is fine, too
=== alan_g is now known as alan_g|ea
=== alan_g|ea is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
=== smartboyhw_ is now known as smartboyhw
[15:14] <mlankhorst> tvoss_: pong
=== michael__ is now known as T0Z
=== alan_g is now known as alan_g|EOD
=== michael__ is now known as T0Z