[03:58] <scientes> can someone add the modesetting drive to xorg-edgers?
[05:14] <mlankhorst> hey
[05:24] <RAOF> Ho!
[05:28] <scientes> why does one touchscreen i have (multitouch) do scrolling (rubber-banding scrolling) in nautilus, and the other (single-click touchscreen) does selecting in nautilus, on the exact same machine at the same time?
[05:29] <RAOF> You'll need to describe the situation better.
[05:30] <RAOF> Fundamentally - because the multitouch one can detect two fingers, so can (and will) do two finger scrolling, whereas that's impossible on the single touch.
[05:31] <scientes> i'm only using one finger
[05:31] <scientes> but i see a fundamentally differn' behavior
[05:31] <scientes> i cannot do a drag-select on the multitouch monitor
[05:31] <RAOF> Sounds like someone's got a broken driver!
[05:31] <scientes> basically i want the elastic-scrolling
[05:32] <scientes> xorg detects it as a touchscreen
[05:32] <scientes> and the driver is usbtouchscreen.c
[05:32] <scientes> (the single touch one)
[05:32] <scientes> let me see on the multitouch
[05:33] <scientes> hmm i forget how to query udev, its /dev/input/event4
[05:34] <scientes> I have a multi-seat setup here
[05:35] <RAOF> Xorg.0.log will tell you what X driver it's using (presumably evdev); udevadm info --name=/dev/input/event4 --query=all will give you the udev info.
[05:35] <scientes> http://paste.debian.net/175569/
[05:36] <scientes> yeah the multitouch one has usbhid as driver (isn't that just the general driver, not end driver???)
[05:37] <scientes> hmm the one that is working fine is full of BUS stanzas....... http://paste.debian.net/175570/
[05:38] <RAOF> That's the one that's working fine?
[06:30] <mlankhorst> hey :P
[06:40] <mlankhorst> morning alll
[06:42] <RAOF> Good morning again :)
[07:06] <mlankhorst> RAOF: when do things show up in https://launchpad.net/ubuntu/precise/+queue?queue_state=1 ? Missing synaptics there
[07:09] <RAOF> Ah, we've managed to get that queue down nicely ;)
[07:09] <RAOF> mlankhorst: < 30 minutes after a successful upload.
[07:11] <mlankhorst> my investigative skills tells me that the upload must have failed then
[07:11] <mlankhorst> cnd?
[07:15] <RAOF> mlankhorst: What version were you expecting? xserver-xorg-input-synaptics | 1.6.0-0ubuntu1~precise1 | precise-updates | source, amd64, armel, armhf, i386, powerpc is presumably not it?
[07:15] <mlankhorst> woops, needs version bump
[07:16] <mlankhorst> that explains, I forgot to push ubuntu-precise :)
[07:18] <mlankhorst> RAOF: can you upload ubuntu-precise branch of xserver-xorg-input-synaptics? Should be 1.6.2-1ubuntu1~precise1
[07:18] <RAOF> Sure.
[07:22] <mlankhorst> btw valgrinding is fun, found another issue with suspend
[07:23] <mlankhorst> radeon this time
[07:30] <RAOF> mlankhorst: What 12.04 bugs does that upload fix? It's not clear from the changelog, and it'd make it much easier to review if we had that :)
[07:36] <mlankhorst> it should be clear if you added -v 1.6.0-0ubuntu1~precise1
[07:40] <mlankhorst> 1.6.2 is all the patches of 1.6.1-1ubuntu1 rolled into a version bump upstream
[07:41] <mlankhorst> LP: #941953
[07:41] <mlankhorst> bug 941953 ?
[07:41]  * mlankhorst pokes ubottu 
[07:42] <RAOF> 941953 972727 are the two bugs it fixes?
[07:42] <RAOF> Ah, well apart from 972727.
[07:43] <RAOF> It's still not clear from the top changelog entry why we're doing this; I'm not going to be doing the SRU review, so you want to make it as easy as possible to see what's happening :)
[07:50] <mlankhorst> yeah the real changelog entry is 1.6.1-1ubuntu1 
[07:51] <RAOF> mlankhorst: Can I suggest adding something to the most recent changelog entry like “New upstream version fixes memory corruption, causing crashes (LP: #941953)”; that'll make it obvious why we're doing this.e
[07:53] <mlankhorst> RAOF: hm true, could you upload the diff to debian/changelog in precise? I'll give it another shot
[07:55] <RAOF> I'm not sure what you're asking for there, sorry :/
[07:55] <RAOF> Where do you want the diff uploaded?
[07:55] <mlankhorst> erm did you upload the package yet or not?
[07:55] <RAOF> (Also, what diff?) ☺
[07:55] <RAOF> No, I've not yet uploaded the package.
[07:55] <mlankhorst> ah k then nm :)
[07:55] <RAOF> I stopped during my regular pre-upload checks to ask you questions ;)
[07:58] <mlankhorst> RAOF: Shall I just change that version from ~precise1 to ~0quantal to emphasize that is the changelog for quantal and add another 1.6.2-1ubuntu1~precise1 version on top that contains the reasoning for having it in precise? eg referencing bugs in 1.6.1-1ubuntu1
[07:59] <RAOF> mlankhorst: Nah, I don't think that's necessary.
[07:59] <RAOF> Incidentally when *are* we uploading 1.6.2 to quantal?
[08:00] <mlankhorst> oh that should already have been done..
[08:02] <RAOF> Need a sponsor for that? ☺
[08:02] <mlankhorst> yeah just upload the ubuntu branch :)
[08:15] <mlankhorst> RAOF: can you check if it looks better now?
[08:17] <RAOF> Looks much better, thanks.
[08:25] <RAOF> Urgh, reindenting.
[08:25] <mlankhorst> yep :S
[08:25] <RAOF> How much effort would it be to cherry-pick those patches instead?
[08:26] <mlankhorst> too much, and you would create a new work, now it's just the same version as we have in quantal
[08:26] <RAOF> Eeeerguh
[08:27] <RAOF> Uploaded; please make that case on the bug, though.
[08:28] <RAOF> Now, to the PIZZA!
[08:38] <jcristau> incidentally when's quantal getting 1.12? :)
[08:38] <mlankhorst> after alpha2 right?
[08:43] <mlankhorst> although we might want to upload those xorg-server input patches that are in proposed now before that.
[09:30] <jcristau> do you guys have info on when fglrx will finally work with 1.12 btw?
[09:33] <mlankhorst> sigh, forgot how much fglrx lags
[09:48] <jcristau> i think it's supposed to work now except it's broken on 64bit
[10:44] <mlankhorst> RAOF: http://pastebin.com/PucL1weS any ideas?
[10:47] <mlankhorst> hm nm think i understand it
[10:53] <mlankhorst> randr1.2 thought it was being smart.. naughty
[11:00] <mlankhorst> and with inspiration from https://lwn.net/Articles/446631/ I found a few alikes :)
[11:38] <mlankhorst> might explain why someone else complained about suspend crashing
[11:57] <mlankhorst> bumping video abi in a stable release is not done, right? ;)
[11:58] <jcristau> correct :)
[11:59] <mlankhorst> i know, would have been easier to convert something to a static string rather to find out where it's all going wrong
[12:04] <mlankhorst> http://pastebin.com/Hn3vxDVw
[12:05] <mlankhorst> that looks ok? Fix valgrind error on suspend
[12:09] <jcristau> doesn't look crazy to me in any case
[12:09] <mlankhorst> I'll check with the X devs to be sure, maybe there's a lifetime semantic to preferred mode
[18:57] <mlankhorst> bryceh: can we upload the new video drivers early?
[19:09] <Sarvatt> so what to do about x-x-v-ati? quantal needs an update to work with cairo 1.12 and we have that darn 6.14.99. is.really.6.14.4-5ubuntu1?
[19:10] <Sarvatt> scientes: its up there now
[19:10] <mlankhorst> Sarvatt: basically what I said ;)
[19:10] <jcristau> Sarvatt: 7 is coming soon anyway :)
[19:10] <jcristau> the no-ums branch
[19:11] <Sarvatt> woohoo
[19:11] <mlankhorst> and nouveau bumped to 1.0.1 :x
[19:11] <Sarvatt> poor powerpc
[19:12] <mlankhorst> what would prevent kms working for powerpc?
[19:15] <Sarvatt> agp not working for starters
[19:16] <jcristau> it sometimes works
[19:16] <jcristau> i know michel has been running on kms for years on his ppc
[19:16] <Sarvatt> i gave up on my ibook around 2.6.31
[19:16] <mlankhorst> sounds more like not enough people care then, anyhow
[19:16] <Sarvatt> yeah needed to explicitly disable agp, and then there were all kinds of mesa problems
[19:36] <mlankhorst> Sarvatt: it sounds like nobody really cared enough then to really fix it
[19:36] <jcristau> when they hear the word agp people run away for some reason
[19:37] <mlankhorst> well now they have no choice :x
[19:37] <Sarvatt> especially uninorth
[19:42] <mlankhorst> well looks like google has to pay oracle 0$ http://www.groklaw.net/article.php?story=20120620140533395
[19:42] <mlankhorst> wonder how you do that..
[19:45] <bryceh> mlankhorst, yep can upload drivers whenever, assuming the required bits are in place.
[19:46] <mlankhorst> bryceh: let me check the big 3 just in case
[19:47] <mlankhorst> intel was uploaded already
[19:51] <mlankhorst> bryceh: ok ati can be uploaded
[19:56] <bryceh> alright
[19:56] <mlankhorst> nouveau might be picked up already due to not having precise changes
[19:57] <mlankhorst> if so can you sync with 1.0.1 ?
[19:58] <bryceh> mlankhorst, did you use the tarball from debian or re-roll a new git snapshot?
[19:58] <bryceh> and if the latter, got a link to the new orig tarball handy?  or shall I roll one locally
[19:58] <Sarvatt> Prf_Jakob: any reason why enable_fbdev shouldn't default to on in the kernel?
[19:58] <mlankhorst> bryceh: for ati I don't know, I can't upload directly :)
[19:59] <mlankhorst> but just use sid
[19:59] <Prf_Jakob> Sarvatt: theoratically we can handled the kernel driver and the old driver at the same time.
[19:59] <mlankhorst> the debian tarball will work since it's just a small change compared to debian
[20:00] <mlankhorst> the only reason we have a custom version was a single patch iirc
[20:01] <Prf_Jakob> Sarvatt: I have been pushing for it to be turned on by default other devs have been pushing against.
[20:01] <Prf_Jakob> Sarvatt: going to add a config for it
[20:03] <bryceh> mlankhorst, are you certain?  looks like debian carries version 6.14.4, whereas we're carrying a git snapshot; is it clear that 6.14.4 is a superset of the git snapshot?
[20:04] <bryceh> if it is, then we probably ought to adjust the version (ugh) to reflect that
[20:06] <jcristau> pretty sure a snapshot from december is older than 6.14.4, yes.
[20:06] <jcristau> seeing how 6.14.4 was from march 29
[20:07] <mlankhorst> bryceh: hm not 100%, but debian does versioning different..
[20:08] <bryceh> jcristau, well I'm more thinking if there was a stable 6.14.x branch separate from master.  But that doesn't appear to be the case
[20:08] <jcristau> right they cut releases from master
[20:09] <bryceh> also the proposed merge is versioned 1:6.14.99~git20120608.9425c50e-0ubuntu1, suggesting it has an updated git pull
[20:10] <bryceh> 6.14.4 was from 03-29, but 0608 suggests a pull from current git tip
[20:10] <jcristau> yeah that looks wrong
[20:10] <jcristau> should be 6.14.4~really6.14.4 :)
[20:10] <jcristau> err
[20:10] <jcristau> 6.14.99~really6.14.4 i mean
[20:10]  * bryceh nods
[20:11] <bryceh> yeah the git history looks like it's 6.14.4 plus some cherrypicks from debian
[20:11] <mlankhorst> ah k i might have screwed up then
[20:11] <jcristau> it's annoying how they bump the version post release only to decrease it again before the next one
[20:11] <bryceh> mlankhorst, version numbers in situations like this are always tricky
[20:11] <bryceh> jcristau, yeah
[20:12] <bryceh> so...  1:6.14.99~really6.14.4-5ubuntu1 ?  does that look right? or should it be -0ubuntu1?
[20:13] <jcristau> yeah -0ubuntu1 i think
[20:15] <bryceh> hmm, one downside is this may make it tougher to go back to the old style git naming if we start doing git snapshots of master again
[20:15] <bryceh> well, s/tougher/messier/
[20:18] <jcristau> as i said i expect 7.0 before long for the ums kill
[20:18] <jcristau> so hopefully it won't be a long term thing
[20:18] <mlankhorst> bryceh: after that we can go back to debian anyhow, modesetting=1 patch will become useless :>
[20:18] <bryceh> ah, ok no prob then
[20:18] <mlankhorst> so we would be synched at 7.0 again
[20:19] <bryceh> hmm, pbuilder is unhappy
[20:20] <jcristau> mlankhorst: right
[20:21] <mlankhorst> it's just for now so that people get no graphical glitches
[20:33] <mlankhorst> bryceh: do you know someone affected by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/966744 ?
[20:38] <mlankhorst> suspecting 2:1.11.4-0ubuntu10.4~0notreally1 will help, which is basically valgrind fix
[20:53] <bryceh> mlankhorst, no I don't
[20:53] <bryceh> mlankhorst, you might stick that in a precise ppa and request people on that bug give it a test
[20:56] <mlankhorst> bryceh: well one of the bug reports hint at a xorg crash
[20:59] <bryceh> -ati uploaded
[21:00] <mlankhorst> bryceh: ah k do you know what nouveau version is used?
[21:03] <bryceh> DIST=quantal chet version xserver-xorg-video-nouveau
[21:03] <bryceh> xserver-xorg-video-nouveau  quantal  1:1.0.1-1
[21:03] <mlankhorst> ok perfect
[21:05] <mlankhorst> bryceh: that should fix all glitches then at least :)
[21:09] <bryceh> mlankhorst, got anything else needing sponsored while I'm at it?
[21:10] <mlankhorst> I'm going to be playing more with valgrind tbh, it's not that much of a performance hog.
[21:10] <mlankhorst> but nope got a few things sru'd atm :)
[21:10] <mlankhorst> bryceh: will we upload x1.12 too?
[21:13] <bryceh> maybe; we should see what RAOF thinks
[21:14] <bryceh> he's been handling the xserver transitions the last few cycles, I've assumed this would be on his todo list here too
[21:14] <mlankhorst> I had a x1.12 ppa in x-staging but drivers are outdated now :)
[21:22] <tjaalton> my 2 vacation-cents, but maybe the driver uploads should've gone to the ppa until the whole stack got moved to quantal :)
[21:26] <tjaalton> binary-copied, whatev
[21:26] <bryceh> tjaalton, mah
[21:26] <bryceh> er, meh
[21:27] <tjaalton> i mean, since it's just a lever to pull
[21:28] <tjaalton> is there anything else holding back 1.12?
[21:28] <bryceh> tjaalton, -nouveau probably got auto-sync'd.  -ati's gone a long time since last merge, and we pull patches for it frequently enough
[21:28] <bryceh> tjaalton, we wanted to wait about a month to focus on sru's, and it's been about a month.  figure it could go in any time
[21:28] <mlankhorst> tjaalton: No, we need to upload drivers now so using quantal is actually _USEFUL_
[21:28] <mlankhorst> instead of glitching like crazy
[21:28] <bryceh> but dunno if raof has some master plan for it
[21:29] <mlankhorst> bryceh: we can't binary copy now at least, would have to set up the ppa again
[21:29] <tjaalton> uploads are cheap, i know that
[21:30] <mlankhorst> i mean version conflicts with the x-staging ppa :)
[21:30] <tjaalton> conflicts?
[21:30] <tjaalton> the ppa has older versions, sure
[21:31] <mlankhorst> yeah that's why i said it would have to be redone
[21:31] <tjaalton> ust jpload the next one there and then copy
[21:31] <mlankhorst> yeah
[21:31] <mlankhorst> but I'd need the ok from raof for it
[21:32] <tjaalton> he should be awake any minute now :)
[21:34] <tjaalton> i'm not even running quantal so no idea what it looks like atm
[21:34] <tjaalton> but precise .1 is looking better
[21:35] <tjaalton> pre-proposed anyway
[21:35] <mlankhorst> lets upload nouveau to .1 "what could possibly go wrong" ;)
[21:35] <tjaalton> heh
[21:39] <mlankhorst> see if they are doing their job by uploading 1.0.0 with the massive memory leak
[21:40] <bryceh> ahem "they" includes "us" ;-)
[21:41] <mlankhorst> :D
[21:41] <mlankhorst> aww responsibility sucks
[21:41] <bryceh> quite true
[21:45] <mlankhorst> but no im quite paranoid, uploading to stable freaks me out. :P
[21:48] <mlankhorst> bryceh: oh btw you can run xorg quite nicely in valgrind with nouveau/r600, it still ends up faster than pandaboard. :)
[21:54] <Sarvatt> mlankhorst: ever seen http://wiki.debian.org/XStrikeForce/git-usage ?
[21:54] <mlankhorst> Sarvatt: yeah had to use it for rebasing a few times :)
[21:55] <mlankhorst> getting xorg-server forwarded to 1.12 iirc
[21:55] <Sarvatt> good to use that workflow if you mess with the debian branches, dri2proto :P
[21:55] <mlankhorst> woops
[21:55] <mlankhorst> what did I mess up?
[21:55] <Sarvatt> upstream-unstable first then merge that in
[21:55] <mlankhorst> ah k
[21:58] <mlankhorst> darn that needs automation badly
[22:01] <Sarvatt> ChangeLog has to be manually updated too
[22:02] <mlankhorst> how about I hide in shame, revert that commit tomorrow and redo it properly. :P
[22:02] <mlankhorst> night
[22:20] <bryceh> cya
[22:44] <RAOF> I'm happy to move 1.12 to quantal.
[22:44] <RAOF> We're not waiting for mesa to settle down?
[22:45] <mlankhorst> I think we won't have to do mesa yet necessarily, right?
[22:46] <RAOF> No, we don't.
[22:46] <mlankhorst> I could probably set up a ppa again tomorrow, but bed time now :)
[22:47] <RAOF> We might as well upload to quantal-proposed.
[22:47] <RAOF> Then once everything's built, we can easily copy to quantal.
[22:47] <mlankhorst> ah sure go for it :)
[22:48] <mlankhorst> it's just the video drivers needing a bump iirc
[22:50] <Sarvatt> 817905
[22:50] <Sarvatt> argh darn yubikey nano goes off every time the laptop is moved
[22:51] <Sarvatt> RAOF: how's gods and kings?
[22:51] <RAOF> Not yet played :)
[22:52] <RAOF> Last night was board gaming; Space Alert and 7 Wonders.
[22:52] <RAOF> Which I didn't win at, but Sam won both games of 7 Wonders.
[22:52] <RAOF> Which, if you haven't played it, is an excellent fast 7-player game.
[22:58] <bryceh> I just checked for bugs since the mesa 8.0.3 upload... nada
[23:00] <Sarvatt> bryceh: ati and nouveau have both been broken with bad corruption since cairo was uploaded over a month ago and i just heard about it today.. i think a lot of people are sticking to precise :)
[23:01]  * Sarvatt included
[23:01] <RAOF> Strangely I haven't noticed that corruption.
[23:02] <Sarvatt> i mean we knew it was broken from cairo 1.12 going into debian before precise released
[23:02] <RAOF> And I *have* been nouveauing on and off.
[23:04] <bryceh> Sarvatt, could well be
[23:04] <bryceh> I too have been staying on precise, mainly to  stay focused on srus