[00:50] <kees> tomreyn: final version appears to be: https://lkml.org/lkml/2013/3/11/677
[02:18] <tomreyn> thanks
[05:11] <tjaalton> tomreyn: huh?
 uploading -intel 2.21.4
 yeah, it has that fix :)
[05:12] <tomreyn> ... is what i was referriing to
[05:12] <tjaalton> no
[05:13] <tjaalton> that was not the kernel..
[05:14] <tomreyn> okay thanks
[06:47] <RAOF> tjaalton, Sarvatt: Sounds like glamor works for 1.14 & 1.13.x; we should keep radeonsi enabled in -edgers.
[07:14] <tjaalton> RAOF: oh cool
[07:14] <tjaalton> we still have it on raring too
[07:14] <tjaalton> but glamor needs an update?
[07:15] <tjaalton> hum, is it even in the archive?
[07:15] <tjaalton> what a mess :P
[07:41] <RAOF> tjaalton: Nope, not in the archive; that needs to be done ):
[07:41] <RAOF> :)
[07:41] <mlankhorst> ooh fun
[07:41] <mlankhorst> could it be made part of the xorg group?
[07:42] <tjaalton> i recently got an unreleased 8xxx series card, but it's not even si-based.. duh
[07:42] <tjaalton> el cheapo series
[07:43] <mlankhorst> :>
[07:43] <tjaalton> was disappointed for not being able to test this stuff.. even to just notice it's "utter failure" or whatever phoronix calls it this week
[07:44] <mlankhorst> hahah
[07:56] <tjaalton> mlankhorst: yeah it probably makes sense under pkg-xorg
[07:59] <mlankhorst> yeah if it does get MIR'd, I'll ask to get pixman and all the blob packages in the xorg package list too :)
[08:00] <tjaalton> oh that list, right
[08:05] <mlankhorst> but ok when you checked the race condition I'll upload xorg-server 1.13.3 :)
[08:06] <mlankhorst> brb
[08:07] <tjaalton> well, at least the git version doesn't break anything here
[08:07] <tjaalton> although if you need the race case tested then yes, within the next hour
[09:08] <mlankhorst> Lies!
[09:10] <tjaalton> hah
[09:10] <tjaalton> soon
[09:10] <tjaalton> disabled swap and eth0 bridge so it's actually able to hit it
[09:11] <mlankhorst> it should show something in the xorg log if you do hit it
[09:11] <tjaalton> first I'll try with the current one
[09:57] <tjaalton> mlankhorst: ok, I have the current package obviously doing something there, now trying the new one
[09:58] <tjaalton> ooh, reproduce the race with it
[09:58] <tjaalton> +d
[09:59] <mlankhorst> does it survive?
[09:59] <tjaalton> no
[09:59] <mlankhorst> ah boo, logs?
[09:59] <tjaalton> low-graphics mode
[10:00] <tjaalton> http://pastebin.com/ebwTGe1C
[10:01] <tjaalton> here's the previous one http://pastebin.com/yRpBX0jA
[10:02] <mlankhorst> it's happy about it though
[10:02] <mlankhorst> afaict
[10:03] <mlankhorst> so where does it go wrong? :S
[10:04] <tjaalton> beats me
[10:04] <mlankhorst> can you paste correct log too?
[10:05] <tjaalton> with this kernel?
[10:05] <tjaalton> um, xserver
[10:05] <mlankhorst> sure 
[10:05]  * mlankhorst has the feeling it fails somewhere else in a similar fashion
[10:05] <tjaalton> this matches my old tests, so there's nothing new
[10:07] <mlankhorst> [     5.162] (II) intel(G0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen <tjaalton@ubuntu.com>)
[10:07] <mlankhorst> is it a hybrid?
[10:07] <tjaalton> no
[10:07] <tjaalton> ivb sdp
[10:08] <tjaalton> the package is from the archive
[10:08] <tjaalton> here's a working one http://pastebin.com/kYRdDYv4
[10:09] <mlankhorst> it's saying G0 though
[10:09] <mlankhorst> which is weird
[10:10] <mlankhorst> iirc that was graphics offload
[10:11]  * mlankhorst rechecks
[10:11] <tjaalton> just (0) with the working one
[10:13] <mlankhorst> yeah but what is it trying to bind to..
[10:13] <mlankhorst> [     4.779] (==) Matched intel as autoconfigured driver 0
[10:13] <mlankhorst> [     4.779] (==) Matched intel as autoconfigured driver 1
[10:13] <mlankhorst> o.O
[10:14] <mlankhorst> oh well, both have that
[10:15] <tjaalton> when it fails plymouth doesn't have a chance of showing the splash, it's showing vt1 instead
[10:16] <tjaalton> but still would like to try with it disabled, can't remember what to put on cmdline
[10:16] <tjaalton> removing splash isn't enough
[10:18] <tjaalton> plymouth.enable=0, maybe
[10:20] <mlankhorst> tjaalton: what if you remove the drmSetMaster call from plymouth? :p
[10:20] <mlankhorst> it will probably fail
[10:20] <mlankhorst> just checking if the race is gone then
[10:22] <tjaalton> I'll try without plymouth a few times, first was successful
[10:22] <mlankhorst> or something like in activate if (!ply_terminal_is_active (backend->terminal)) return;
[10:22] <mlankhorst> probably src/plugins/renders/drm/plugin.c or something
[10:22] <mlankhorst> that should hopefully be enough to prevent it from stealing master
[10:24] <tjaalton> ha, failuer
[10:24] <tjaalton> -re
[10:24] <mlankhorst> when
[10:24] <tjaalton> [     4.765] drmSetMaster failed with -1(Operation not permitted)
[10:24] <tjaalton> without plymouth
[10:25] <mlankhorst> o.O
[10:26] <tjaalton> http://pastebin.com/HzXGPRMS
[10:28] <mlankhorst> oh duh
[10:28] <mlankhorst> drmsetmaster doesn't return err code
[10:30] <mlankhorst> tjaalton: pushed new version
[10:31] <mlankhorst> my guess is it will fail with -EINVAL, lets see >:X
[10:32] <mlankhorst> I'm hoping for -EINVAL, in fact
[10:33] <mlankhorst> if so, I'll ask you to test a kernel patch
[10:36] <tjaalton> building
[10:40] <tjaalton> bah, plymouthd _was_ still running, I'll disable it harder
[10:41] <mlankhorst> that's fine, I just want that error again :P
[10:41] <tjaalton> alright
[10:43] <tjaalton> [     4.901] drmSetMaster failed with 22(Invalid argument)
[10:43] <mlankhorst> yay
[10:43] <mlankhorst> let me grab the raring kernel
[10:44] <tjaalton> guess I need it too?-)
[10:44] <tjaalton> oh I have it..
[10:44] <mlankhorst> is a .patch good enough?
[10:44] <tjaalton> yep
[10:50] <mlankhorst> tjaalton: http://paste.ubuntu.com/5607392/
[10:52] <mlankhorst> blergh should probably have fixed it, missing fops_put(old_fops); ah well
[10:52] <mlankhorst> wont be able to load drm module :p
[10:53] <tjaalton> the last hunk failed to apply
[10:53] <mlankhorst> I'll try 3.8 ish
[10:54] <mlankhorst> applies cleanly against 3.8.0 here
[10:57] <mlankhorst> http://paste.ubuntu.com/5607407/
[10:57] <tjaalton> not -12.21
[10:57] <mlankhorst> is that 3.8 kernel?
[10:57] <tjaalton> yep
[10:58] <tjaalton> maybe .2 or such
[10:58] <mlankhorst> I'll try v3.8.x branch then
[10:59] <mlankhorst> still applies cleanly o.O
[10:59] <mlankhorst> just apply with hand, it's a small patch
[11:00] <mlankhorst> idea is that f_op gets replaced only once, and not reset on failure
[11:00] <mlankhorst> and then it drops drm_global_mutex before calling f_op->open
[11:00] <mlankhorst> drm_open re-takes global_mutex to prevent races
[11:01] <tjaalton> hah
[11:01] <tjaalton>     UBUNTU: SAUCE: drm -- stop early access to drm devices
[11:01] <tjaalton> that's a nearly three year old patch..
[11:02] <tjaalton> why it didn't apply
[11:02] <tjaalton> mind reviewing that one?
[11:03] <mlankhorst> zap it
[11:03] <mlankhorst> this solution *should* work better
[11:03] <tjaalton> and apply yours?
[11:03] <mlankhorst> yeah
[11:03] <tjaalton> k
[11:04] <tjaalton> wonder if that patch is what's causing the race in the first place..
[11:04] <mlankhorst> nah it's a fail attempt to work around it
[11:04] <mlankhorst> then again maybe
[11:05] <mlankhorst> though I would expect open to fail in that case with -EAGAIN
[11:05] <tjaalton> don't recall having this bug before maybe a year ago
[11:06] <mlankhorst> I think it would still fail with that workaround because it's not complete
[11:06] <mlankhorst> just taking global mutex seems to be a reasonable fix :p
[11:07] <mlankhorst> it could otherwise return the second open call before firstopen is called in drm
[11:09] <tjaalton> building
[11:10] <mlankhorst> hm or worse, possibly before load finishes
[11:11] <mlankhorst> only it wouldn't happen on first open, but if 2 devices open in parallel, like xorg and plymouth
[11:12] <mlankhorst> first one would nicely block on global_mutex, second one would race ahead without any locking at all
[11:31] <tjaalton> hmm no kms on vt
[11:31] <mlankhorst> o.O
[11:31] <mlankhorst> drm failed to load?
[11:31] <tjaalton> no it was fine
[11:32] <tjaalton> second boot, kms fine, vt change and the mouse cursor follows :)
[11:33] <tjaalton> and can't find the greeter again
[11:34] <tjaalton> restart lightdm and it's fine
[11:37] <tjaalton> ha, failure
[11:38] <mlankhorst> was afraid of that, meh :/
[11:38] <tjaalton> mlankhorst: same as before
[11:38] <mlankhorst> still -EINVAL?
[11:38] <tjaalton> yep
[11:38] <mlankhorst> on setmaster right?
[11:38] <tjaalton> [     4.856] (II) config/udev: Adding drm device (/dev/dri/card0)
[11:38] <tjaalton> [     4.856] drmSetMaster failed with 22(Invalid argument)
[11:38] <tjaalton> [     4.861] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64
[11:39] <mlankhorst> was afraid of that
[11:40] <mlankhorst> tjaalton: could you add a printk to drm_setmaster_ioctl to find out which exactly it triggers on?
[11:40] <tjaalton> where?
[11:40] <mlankhorst> drm_stub.c
[11:49] <mlankhorst> I'm hoping it's complaining about file_priv->minor->master, in which case I should revive the first part of bryce's attempt
[11:49] <tjaalton> building
[11:50] <mlankhorst> or better yet, plymouth should not call drmsetmaster and just bug out early if it didn't get master, it lost to xorg-server :P
[11:51] <tjaalton> or just wait for the system compositor..
[11:57] <mlankhorst> http://paste.ubuntu.com/5607513/
[11:58] <mlankhorst> could you try that?
[11:59] <tjaalton> so not the printk stuff?
[11:59] <mlankhorst> could keep it, but this is for plymouth to not take master if not on active vt
[11:59] <mlankhorst> at least, I guess it works like that
[12:20] <tjaalton> mlankhorst: didn't try the plymouth patch yet, but the failing check was "if (file_priv->minor->master)"
[12:21] <mlankhorst> good, plymouth one is probably the fix
[12:21] <mlankhorst> I hope
[12:21] <tjaalton> funny that it follows the same pattern. first boot I get the cursor-on-vt issue, second one is fine, third one fails
[12:22] <tjaalton> fails with failsafe (hah)
[12:23] <mlankhorst> resetting or full power off?
[12:23] <tjaalton> reset
[12:30] <tjaalton> mlankhorst: nope, still failed
[12:31] <mlankhorst> I guess I'll revive the spin patch on setmaster then
[12:41] <mlankhorst> pushed
[12:42] <mlankhorst> tjaalton: can you retest xorg-server with the patch refreshed patch?
[12:43] <tjaalton> building
[12:50] <tjaalton> hm, it's probably not normal that on nearly every boot I have dmesg full of ext4_orphan_cleanup
[12:50] <tjaalton> ..messages
[12:55] <tjaalton> [     4.888] (II) config/udev: Adding drm device (/dev/dri/card0)
[12:55] <tjaalton> [     4.888] (II) spinning!
[12:55] <tjaalton> [     5.111] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64
[12:55] <tjaalton> works
[12:55] <mlankhorst> \o/
[12:56] <mlankhorst> now reset the rest to previous state, and see if it still works?
[12:57] <mlankhorst> eg default plymouth and kernel
[12:57] <tjaalton> yep
[13:00] <mlankhorst>  * radeon_driver_firstopen_kms - drm callback for last close
[13:00] <mlankhorst> void radeon_driver_lastclose_kms(struct drm_device *dev)
[13:00] <mlankhorst> :D
[13:14] <tjaalton> works
[13:17] <tjaalton> now I have the mouse cursor on top of a vt (blinking cursor on top-left), heard the bongos
[13:18] <tjaalton> it didn't spin, but the intel driver spent half a second on "something"
[13:18] <tjaalton> [     4.950] (++) using VT number 7
[13:18] <tjaalton> [     5.451] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen <tjaalton@ubuntu.com>)
[13:18] <mlankhorst> could it be plymouth? :P
[13:19] <tjaalton> could, I enabled it again
[13:19] <tjaalton> booted fine a couple of times
[13:19] <mlankhorst> presumably plymouth shouldn't attempt to attach if xorg-server ended up starting
[13:20] <mlankhorst> could you try with the plymouth patch?
[13:22] <tjaalton> now I just got a blank screen
[13:22] <mlankhorst> fun :/
[13:22] <tjaalton> root      1638  1339  0 15:21 ?        00:00:00 plymouth --ping
[13:23] <tjaalton> plymouth doesn't exit
[13:23] <mlankhorst> can you attach to plymouthd, see if it's stuck on something?
[13:23] <tjaalton> [+0.01s] DEBUG: Waiting for ready signal from X server :0
[13:23] <tjaalton> [+0.01s] DEBUG: Stopping Plymouth, no displays replace it
[13:24] <tjaalton> from lightdm.log
[13:25] <tjaalton> ply_terminal_deactivate_vt
[13:25] <tjaalton> http://pastebin.com/C9wvXrF9
[13:25] <tjaalton> I need to run ->
[13:30] <mlankhorst> boo it needs debug symbols
[13:32] <mlankhorst> oh that's from lightdm
[13:40] <mlankhorst> blargh I need some way to reproduce this if I want to fix it :/
[13:54] <mlankhorst> boooo this one's too slow
[18:22] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=62198 gen3 possibly messed up in x-x-v-intel 2.21.4 if anyone comes across corruption bugs on them
[18:24] <tjaalton> i'll check it out
[18:24] <tjaalton> or maybe not
[18:24] <tjaalton> forget 965gm is gen4
[18:25] <mlankhorst> my eee is gen 3 :P
[18:25] <mlankhorst> I'll test tomorrow
[18:29] <Sarvatt> Duke`_: probably what you're hitting
[18:34] <Duke`_> hum the last two updates seems ok for me
[18:36] <Duke`_> I remember having a glxgears with transparent background, instead of black
[18:39] <Duke`_> ok, I just installed 2.21.4, going to reboot
[18:41] <Sarvatt> Duke`: ah sorry, another bug then
[18:42] <Sarvatt> i updated edgers right after you complained in case it was a transient bug, so much changes every day and i hadn't for a week
[18:42] <Duke`> eh ;)
[18:43] <Duke`> the 20130301 version was terrible, X totally broken
[18:44] <Duke`> black screen and it was hard to switch to a VT
[20:41] <burp> dear ubuntu-x people
[20:42] <burp> nvidia-current 304.84 in the precise ubuntu-x-swat PPA depends on xserver-xorg-core
[20:42] <burp> but the new https://wiki.ubuntu.com/Kernel/LTSEnablementStack depends on xserver-xorg-core-lts-quantal
[20:43] <burp> so they can't be readily installed together
[20:43] <burp> (and maybe shouldn't :)
[20:44] <burp> I haven't been able to find any more information on this
[20:44] <burp> except these gentlemen on askubuntu who ran into the problem: http://askubuntu.com/a/257889
[20:44] <burp> will ubuntu-x-swat stick with the current situation, or are there plans for compatibility with the LTSEnablementStack?
[20:46] <jcristau> what does the lts stack buy you if you're using nvidia's driver anyhow?
[20:47] <burp> I'm not sure yet. :)
[20:48] <burp> but currently if you install bumblebee on a 12.04.2 system, X doesn't startup anymore
[20:48] <burp> that would be reason #1 to clear things up
[20:48] <burp> also, bumblebee systems have Intel graphics as wel
[20:48] <burp> l
[20:49] <burp> (the LTSEnablementStack seems to be default on new 12.04.2 installs. I just got burned by this problem.)
[20:49] <Sarvatt> sudo apt-get install xserver-xorg-lts-precise :)
[20:50] <bryce> yeah bumblebee should probably update their depends
[20:50] <Sarvatt> that'll downgrade you back to the older stack
[20:50] <burp> it's not bumblebee
[20:50] <burp> bumblebee only depends on nvidia-current
[20:50] <burp> but nvidia-current depends on xserver-xorg-core
[20:50] <burp> is there no solution possible where the enablement stack is also supported?
[20:51] <tjaalton> don't use the ppa?
[20:51] <burp> one needs the PPA if one has a NVIDIA 7xx no?
[20:51] <burp> (this laptop has NVIDIA GeForce 710m)
[20:51] <bryce> burp, ah.  mlankhorst was working on getting that resolved.  Check with him.
[20:52] <tjaalton> well there are other versions available on precise
[20:52] <tjaalton> if bumblebee depends on nvidia-current then fix that
[20:52] <Sarvatt> the nvidia driver is whats messed up in the ppa
[20:53] <tjaalton> sure
[20:53] <tjaalton> but why use the ppa?
[20:53] <Sarvatt> bjsnider: ya didnt pick up tseliot's recent packaging changes it looks like
[20:53] <Sarvatt> because newer blob drivers actually are worth upgrading to? :P
[20:53] <tjaalton> and there's nvidia-310, no?
[20:54] <Sarvatt> 304.84 is still newer
[20:54] <tjaalton> probably doesn't matter for this hw?
[20:55] <burp> so should I not want to install the latest nicely packaged nvidia binary drivers on this Ivy Bridge i7 with NVIDIA GeForce 710m in Optimus configuration?
[20:55] <Sarvatt> it fixes a kde logout problem, xrandr rotation, and speeds up font rendering, perfectly valid reasons to want to update it..
[20:55] <burp> It felt like a logical thing to do at the time.
[20:56] <tjaalton> ok then, so wait for it to get fixed :)
[20:56] <burp> :)
[20:56] <Sarvatt> thanks for the heads up it was broken
[20:56] <burp> I should probably double-check if it has been reported and if not report it, no?
[20:56] <Sarvatt> burp: nah its not a distro bug, reporting it here was right :)
[20:57] <burp> ok great thanks!
[21:11] <Sarvatt> bjsnider: patch incoming for fixing the precise blob depends
[21:12] <Sarvatt> bjsnider: http://paste.ubuntu.com/5608946/
[21:18] <Sarvatt> burp: just uploaded it, should be up in a few hours
[21:19] <burp> wow, that's awesome, thank you very very much!
[21:24] <bjsnider> Sarvatt, is it just in precise?
[21:25] <mlankhorst> bjsnider: it's only needed for precise, unless you want to backport the enablement stack to quantal ;)(
[21:26] <Sarvatt> bjsnider: yeah, its a pain in the rear i know :(
[21:26] <mlankhorst> but you could probably harmlessly sync those changes back to later
[21:26] <Sarvatt> could just make them all except precise then make the precise at the end slapping that patch on though
[21:27] <Sarvatt> mlankhorst: except he's still doing lucid blobs even :)
[21:27] <mlankhorst> o.o
[21:27] <Sarvatt> would need to extend the number of abis it provides
[21:27] <mlankhorst> not for much longer?
[21:27] <bjsnider> burp, you have which chip?
[21:27] <bjsnider> i can't find a record of that one
[21:28] <Sarvatt> bjsnider: rebadged 620m
[21:28] <burp> http://www.notebookcheck.net/NVIDIA-GeForce-710M.84746.0.html
[21:28] <bjsnider> he shouldn't be using the ppa then
[21:28] <bjsnider> too new
[21:29] <bjsnider> only geforce 6k/7k hardware
[21:29] <burp> I shouldn't?
[21:29] <Sarvatt> burp: does it work? :P
[21:29] <burp> hehehe
[21:29] <burp> it seems to!
[21:30] <burp> I'm only just installing the thing
[21:31] <burp> but optirun glxspheres is doing the right thing much faster than the intel is doing it
[21:31] <Sarvatt> -310 probably doesn't even work on it since the one in precise is so old
[21:31] <bryce> good sign
[21:31] <bryce> Sarvatt, :-/
[21:32] <burp> cancel that
[21:32] <burp> actually the intel with vblank_mode=0 is much faster than than optirun
[21:32] <mlankhorst> hah
[21:33] <Sarvatt> try optirun glxinfo and see if it says nvidia
[21:33] <burp> it does :)
[21:33] <burp> OpenGL Renderer: GeForce 710M/PCIe/SSE2
[21:33] <burp> vs OpenGL Renderer: Mesa DRI Intel(R) Ivybridge Mobile
[21:33] <burp> nvidia gives 120+ frames per second
[21:34] <burp> intel almost 200
[21:34] <burp> :)
[21:34] <burp> I sure hope that nvidia is sleeping most of the time
[21:34] <mlankhorst> it has to copy twice
[21:34] <burp> shees I should probably get me a real irc client
[21:34] <mlankhorst> nobody said optimus worked well
[21:34]  * mlankhorst tests on lapptop
[21:35] <Sarvatt> on a real app it'd probably be much better :)
[21:35] <burp> I'm just happy that there's something with which I can keep it sleeping
[21:36] <burp> lemme try primus just for reference
[21:36] <burp> a much more respectable 160+ frames per second
[21:38] <burp> I'm actually really happy with this cheapskate performance laptop so far
[21:38] <burp> if anyone's interested
[21:38] <burp> Acer V3 571G with Full HD IPS display (very pretty), Intel i7 quad core (real quad), 8G RAM and big slow hard disk for 800 eurobucks
[21:38] <burp> seems to run ubuntu 12.04.2 fine!
[21:39] <burp> (no I'm not selling)
[21:39]  * mlankhorst wonders where you get glxspheres from
[21:39] <Sarvatt> mesa demos, we just dont package it
[21:39] <mlankhorst> ah
[21:39] <burp> jeez
[21:39] <burp> on this system it seems to come from virtualgl
[21:39]  * mlankhorst builds
[21:40]  * burp wonders what IRC client is en vogue these days
[21:40] <burp> irssi still? or something else?
[21:40] <Sarvatt> oh nope, its packaged with virtualgl
[21:40] <mlankhorst> icechat?
[21:41] <burp> err, seems to be windows?
[21:41] <mlankhorst> dno
[21:41] <burp> it does say "the chat cool people use"
[21:42] <burp> I see what they did there
[21:46] <mlankhorst> hm guess you're right
[21:46] <mlankhorst> ugh c# too
[21:49] <mlankhorst> 275.781442 frames/sec - 289.647733 Mpixels/sec
[21:49] <burp> what graphics?
[21:49] <mlankhorst> radeon and i915
[21:51] <Sarvatt> 76.287995 frames/sec - 80.123756 Mpixels/sec whee ultrabook hd4000 :)
[21:52] <mlankhorst> was with DRI_PRIME=1 so it rendered on the radeon
[21:52]  * mlankhorst tries i915
[21:52] <mlankhorst> erm native radeon*
[21:54] <Sarvatt> oh 32 bit version is much faster
[21:55] <mlankhorst> how do I kill off vblank?
[21:55] <Sarvatt> vblank_mode=0
[21:55] <mlankhorst> that doesn't seem right :p
[21:56] <mlankhorst> oh.. right, no syncing between i915 and radeon probably
[21:56] <Sarvatt> isn't that what you're working on........?
[21:56]  * Sarvatt coughs
[21:57] <mlankhorst> it's tear free!
[21:57] <mlankhorst> but that doesn't mean userspace performs its own sync correctly
[21:57] <Sarvatt> woohoo, starcraft 2: heart of the swarm time :)
[21:58] <Sarvatt> lets see if this bugger works in wine
[22:00] <mlankhorst> Sarvatt: anyway syncing should work tear free, but if both ddx drivers don't tell that they wrote or read something, you could have 2 reads off the same frame
[22:01] <mlankhorst> so it shows as higher fps ;P
[22:01]  * mlankhorst will be sure to break wine this friday
[22:25] <RAOF> mlankhorst: Hey, do you know off hand what would happen if I close() a prime dma-buf fd after importing it? Do I lose access to that buffer?