[02:13] <darkxst> RAOF, ping
[02:24] <RAOF> darkxst: Yo!
[02:24] <darkxst> RAOF, can you take a quick look at my pointer barrier patch
[02:24] <darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
[02:24] <ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
[02:24] <darkxst> are you happy with that fix?
[02:25] <RAOF> I'm not actually at work this week, but re: your patch - my concern is whether it'll break BarrierNotify behaviour on the edges.
[02:28] <darkxst> well the original patch is a bit hacky, but I don't believe my patch breaks anything further
[02:30] <RAOF> Have you tested it? :) IIRC the gtest tests cover that behaviour
[02:31] <darkxst> RAOF, I have tested under unity and the sticky edges still work as expected
[02:31] <RAOF> Also testing hidden unity launcher reveal behaviour would be good
[02:32] <RAOF> Cool. I'll give it a better read post-baby
[02:32] <darkxst> the Barrier events use the clamped values anyway?
[02:32] <darkxst> I think the unclampled values are only needed for the velocity calculation
[02:33] <darkxst> hidden unity launcher = auto-hide dash right?
[02:41] <darkxst> RAOF, there is not test case for barrier_find_nearest() function
[03:05] <bjsnider> darkxst, you just never gave up on this. i need to learn to have that kind of perseverance
[03:11] <darkxst> lol, just want to see it fixed, this bug has been annoying me since precise
[03:12] <bjsnider> the way you bang down doors to get what you want is a skill i wasn't born with
[05:23] <tjaalton> bryceh: https://bugs.freedesktop.org/show_bug.cgi?id=49347
[05:23] <ubottu> Freedesktop bug 49347 in Server/Input/Core "Jumping tablet cursor with transformation matrix" [Normal,Reopened]
[05:23] <tjaalton> so there was a bug open about the issue, and now there's a patch
[05:27] <tjaalton> (that after rotating nexus7 with xrotate, the cursor would be jumping around)
[05:34] <Sarvatt> input not working after one touch on the network manager indicator is pretty crappy :)
[05:34] <tjaalton> dandrader is working on that
[05:35] <tjaalton> he reproduced it on a dell laptop
[05:35] <tjaalton> (touchscreen)
[05:35] <tjaalton> opening the indicator menus quickly repro'd it
[06:29] <mlankhorst> morning
[07:00] <mlankhorst> bryceh: nice readup on triaging
[08:18] <mlankhorst> should we sru 9.0.1 to quantal?
[08:20] <mlankhorst> actually guess it's time I move to raring :)
[08:43] <mvo> mlankhorst: speaking of SRU, I just uploaded the apt SRU, once its availalbe it would be great if you could sru-verify the version in quantal-proposed
[08:45] <mlankhorst> sure np
[08:46] <mlankhorst> actually quantal-proposed would be harder to test, but I can test the precise one
[08:46] <mlankhorst> would the reduced testcase work?
[08:47] <mlankhorst> i could probably just test the quantal one by installing it in precise and testing though, if that's ok
[08:48] <mvo> mlankhorst: yeah, I think that would work, thanks
[09:06] <mlankhorst> ah great raring chroot/netboot works
[09:45] <mlankhorst> Sarvatt: ugh bzr is awful, can you check if I accidentally overwrote your changes with a merge?
=== christoffer is now known as Guest58555
[10:10] <mlankhorst> RAOF: argh I remember why I needed to override xserver-common, sadly can't get rid of that, but I'll try dpkg-divert
[10:23] <mlankhorst> ugh things get ugly fast, there..
[10:25] <mlankhorst> guess I'll just try to install protocol.txt only and depend on normal xserver-common too for the Xserver manpage
[10:53] <mlankhorst> mvo: hm seems i had a bug so it didn't do conflicts properly, might explain why I set that bug off in the first place :-)
[11:37] <mlankhorst> RAOF: ok if mesa and intel build I'll do a ppa7 attempt with renamed libdrm, nothing should be hardcoded on the name any more. I should be able to change the soname to libdrm-ltsq.so.2 for example
=== seb128_ is now known as seb128
[14:40] <mlankhorst> hmm
[14:40] <mlankhorst> RAOF: can I submit the libdrm hack anonymously? it's really really really fugly..
[14:45] <ogra_> *giggle*
[14:46] <jcristau> mlankhorst: git commit --amend --author=raof
[14:50] <mlankhorst> jcristau: it's for the renamed stack, basically take libdrm from quantal, do some evil voodoo, end up with something that's libdrm but not quite
[15:55] <mlankhorst> calling eod, enough messing around with libdrm
[16:56] <bryceh> tjaalton, thanks, I'll test that out
=== yofel_ is now known as yofel
[19:14] <Yuioup> Hey all
[19:14] <Yuioup> I have a question: I'm beta testing Steam for Linux and am using an AMD card. According to this wiki page: "https://wiki.ubuntu.com/Valve", the experimental driver has not been released yet. Does anybody know when those drivers might be released?
[19:16] <Yuioup> Nobody here?
[19:19] <bryceh> no eta yet.  whenever tseliot gets to the task
[19:25] <Yuioup> Ah. Is there a way for me to download the driver somehow? Or is this something I cannot download seperately?
[20:57] <bjsnider> why is he using an amd card, is what i want to know
[21:08] <JanC> bjsnider: why not?
[21:09] <bjsnider> because he isn't using windows
[21:10] <JanC> I've had more luck using AMD cards then using Nvidia cards on linux
[21:10] <JanC> but then again, I don't play games
[21:10] <JanC> or at least not very often/many
[21:11] <bjsnider> that's the first time i've seen someone say that
[21:11] <JanC> in any case, things should just work if you use common hardware
[21:13] <JanC> of course, I understand the people behind Steam worked more closely with Nvidia than with AMD until now...