[00:04] <RAOF> cnd: Can you keep the git branch called ubuntu+1 for now, and you don't need to use a standard suffix.  Treat the staging PPA as the main archive, just delayed :)
[00:05] <RAOF> cnd https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
[00:05] <cnd> RAOF, ok, I'll be uploading xorg-server_2:1.11.2.902-1ubuntu1
[00:05] <RAOF> bryceh: Could you add cnd to ~ubuntu-x-swat?
[00:05] <cnd> does that look right?
[00:05] <cnd> just double checking :)
[00:05] <RAOF> That looks right to me, yes.
[00:08] <bryceh> sure
[00:10] <bryceh> looks like someone beat me
[00:14] <RAOF> Cool ;)
[00:36] <cnd> RAOF, xorg-server has been accepted into ppa:ubuntu-x-swat/x-staging
[00:36] <cnd> reminder that I completely have not tested the code base :)
[00:37] <cnd> it's *your* fault if your input devices catch on fire :)
[00:37] <RAOF> cnd: Excellent!  I'll start throwing drivers at it.
[00:37] <RAOF> Hah.  The way my hardware luck's going, *they will*
[01:31] <cnd> hooray! It's built
[01:32] <RAOF> Let the wave of babies begin!
[01:34] <Sarvatt> cnd: who needed pinging about unity not working again with it because of libutouch-geiss?
[01:34] <RAOF> DBO or bregma
[01:35] <cnd> Sarvatt, it's either an issue with the utouch stack, or an issue with unity misusing it
[01:35] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/860707 comment #5 will be whats hit with whats in there
[01:35] <ubot4> Launchpad bug 860707 in unity (Ubuntu) (and 1 other project) "Unity crashes when started in an environment without utouch support (affects: 58) (dups: 2) (heat: 284)" [High,Confirmed]
[01:35] <Sarvatt> unity side was fixed
[01:35] <cnd> then bregma would be the one
[01:35] <Sarvatt> by http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1728#plugins/unityshell/src/GeisAdapter.cpp
[01:36] <cnd> Sarvatt, that unity code doesn't look right to me...
[01:36] <cnd> wait, nm
[01:36] <cnd> read the diff wrong
[01:37] <Sarvatt> i worked around it locally by ripping geis support out of unity so maybe its still a unity bug
[01:38] <Sarvatt> "ripping geis support out" == commenting out 2 lines..
[01:38] <cnd> Sarvatt, it looks like unity is still trying to use geis
[01:38] <cnd> even when it's not supported
[01:38] <cnd> otherwise it shouldn't be calling geis_configuration_get_value
[01:38] <cnd> so DBO or MacSlow (Mirco, who wrote that commit) should be pinged
[01:39]  * cnd is opening the code to peek
[01:40] <Sarvatt> http://sarvatt.com/downloads/patches/byegeis.patch was what was needed
[01:41] <cnd> Sarvatt, GeisAdapter::_root_instance is never initialized
[01:41] <cnd> it must be initialized to nullptr
[01:41] <cnd> Sarvatt, can you follow up on it?
[01:41] <cnd> I'm on vacation now through  monday
[01:42] <Sarvatt> should be easier with this ppa, ppa-purge is busted with multiarch so it took me a few hours to switch fixing it up when i was doing it in edgers
[01:43] <cnd> Sarvatt, I would suggest hitting MacSlow with a clue-by-four to get it resolved :)
[01:43] <cnd> you can leave bregma and DBO unharmed
[01:43] <Sarvatt> cnd: yeah sorry to bug ya on vacation man, was just picking your brain trying to find out who to bug :)
[01:44] <cnd> well, technically I am still working for 15 mins :)
[01:44] <cnd> I just can't follow up on it
[01:44]  * Sarvatt is on vacation now too, i know how it goes :)
[01:44] <cnd> ahh, ok
[01:44] <cnd> I can send an email right now then
[01:44] <cnd> yeah, I'll just do that
[01:51] <cnd> Sarvatt, I updated the bug with all the info, hopefully that's enough to see it through
[01:52] <Sarvatt> ya asked me before and i didn't follow through because reproducing it with edgers is really a pain in the ass, i'm really sorry about that man
[01:52] <Sarvatt> thanks :)
[01:55] <cnd> Sarvatt, np :)
[01:55] <cnd> if I had looked closely enough it would have been obvious
[01:55] <cnd> should have done it sooner
[01:56] <Sarvatt> edgers was broken for 2 months because i didn't comment out 2 lines of code, i know the feeling
[02:29] <Sarvatt> so let me get this straight, we're never going to be able to update xserver at a decent schedule anymore because fglrx taking 3 months to adapt to new abis and breaking unity with fglrx isn't an option because DX uses them?
[02:30] <Sarvatt> only the xserver releases where xserver releases 3 months before 2 months before final freeze
[02:45] <RAOF> Sarvatt: No, this is a one-time (or at least LTS-only) deal; it was quite clear in the sessions at UDS that “use an open-source driver” is an acceptable work around.
[02:45] <Sarvatt> the +1 will work at all times effort doesn't seem LTS only though
[02:45] <Sarvatt> oh ok
[02:46] <bjsnider> is the radeon driver a good alternative to fglrx at this point?
[02:49] <Sarvatt> very much so
[02:49] <Sarvatt> especially for the desktop where it works much better than fglrx
[02:50] <Sarvatt> xv is busted on fglrx in the december release, people using it get to wait a month for a fix
[02:51] <bjsnider> doesn't say much for amd
[02:51] <Sarvatt> agreed :)
[02:52] <bjsnider> it works "much better"?
[02:52] <bjsnider> that's mind-boggling
[02:52] <Sarvatt> MUCH
[02:53] <Sarvatt> so much better it isnt funny, they keep implementing things like the tearing fix which is broken and it takes them a month to fix what they break
[02:53] <bjsnider> does opengl work much better in radeon?
[02:54] <Sarvatt> they work on 3 monthly branches at a time, fixes go in the newest one, if its really important it might make release+1 version but usually not
[02:54] <Sarvatt> and for the past year its been working very bad imo
[02:56] <Sarvatt> there are no stable updates so you are guaranteed to have to wait a month for a fix if somethings broken
[02:56] <Sarvatt> (at least)
[02:56] <Sarvatt> more likely 2, worst case 3
[02:58] <Sarvatt> bjsnider: for games sure
[02:58] <Sarvatt> thats what i care about so i'd have to put up with it
[02:58] <Sarvatt> but if you just care about the desktop the open source ones are a much better option
[02:58] <bjsnider> for games fglrx is the better option?
[02:58] <Sarvatt> sane as nvidia, yeah much
[02:59] <Sarvatt> s/sane/same/
[02:59] <bjsnider> well, i guess that's what the firegl customers care about
[02:59] <bjsnider> opengl
[02:59] <Sarvatt> firegl customers care about professional 3D apps
[03:00] <bjsnider> and that's the only thing fglrx does well i guess
[03:00] <Sarvatt> and yea thats much faster, thats what fglrx was even released for, not much to do with a windows game in wine :P
[03:01] <bjsnider> what about mobile chips?
[03:01] <RAOF> If we can enable float textures & add libdxtn, radeon & intel should be reasonable for wine games, too.
[03:02] <Sarvatt> bjsnider: what about mobile chips? they're usually just a speed bump behind desktop ones
[03:02] <RAOF> Dunno about nouveau, but probably ok too.
[03:02] <Sarvatt> nouveau scares me
[03:03] <bjsnider> i meant that you qualified your remarks by saying that radeon is much better on desktops, as if mobile stuff was different
[03:03] <Sarvatt> its broken on lots of crap, especially in mesa
[03:03] <Sarvatt> bjsnider: nope mobile/desktop doesnt make a difference, its better for unity on everything
[03:04] <RAOF> It *is* much harder to recommend nouveau over nvidia than it is to recommend radeon over fglrx :)
[03:04] <Sarvatt> RAOF: we hit so many problems and have noone to escallate bugs to
[03:04] <Sarvatt> QA runs tests against nouveau, suspend/resume is completely busted
[03:04] <bryceh> actually we did meet the nouveau devs at the X conference, and can escalate to them
[03:05] <bryceh> it's just that it's fairly hard for them to solve bugs
[03:05] <bjsnider> there's a public bug tracking system for nouveau isn't there?
[03:05] <bryceh> yes
[03:05] <Sarvatt> nouveau devs = darktama though, escallating bugs to another distro for unreleased hardware?
[03:05] <Sarvatt> for mesa when he works on the kernel mostly?
[03:06] <bjsnider> why is it fairly hard for them to solve bugs?
[03:07] <bryceh> bjsnider, lack of access to register documentation
[03:07] <bryceh> bjsnider, and lack of man power for reverse engineering
[03:07] <bjsnider> there hasn't been any amd documentation in 3 years i think
[03:07] <bryceh> bjsnider, true but AMD employs several of the -ati developers who (AIUI) can get some insider info as a result
[03:07] <Sarvatt> nouveau to me is really done on a best effort basis, we really rely on the vendors a lot to fix bugs on unreleased stuff which i work on
[03:10] <bjsnider> that doesn't inspire a lot of confidence in nouveau
[03:10] <bjsnider> what happens when everybody and their dog wants to switch to wayland? you need nouveau for that
[03:13] <RAOF> Eh.  Suspend/resume is broken with nvidia, too :)
[03:13] <Sarvatt> RAOF: there's always a corner case, for the most part it shouldn't be though
[03:14] <Sarvatt> aka for crap thats certified its definitely not
[03:14] <RAOF> Well, my experience with nouveau has tended to include working suspend/resume.  Even on this t420s (before it stopped POSTing ☹)
[03:14] <Sarvatt> wait, nouveau?
[03:14] <Sarvatt> thats specifically the platform i'm saying suspend/resume is broken on nouveau on :)
[03:15] <RAOF> Sarvatt: It was working for me at one point, then it stopped working.  But it stopped working on nvidia at the same time :)
[03:16] <Sarvatt> hmm
[03:16] <Sarvatt> precise?
[03:16] <Sarvatt> just curious because thats gonna be a huge problem if it is
[03:17] <Sarvatt> so those systems shipped with 10.10, with acpi_osi="!Windows 2009" so it pretended to be XP so optimus wouldn't be used
[03:18] <RAOF> I installed that image, and that's what it came up with.  Then I suspended, and it didn't feel like waking.  Then I reset the BIOS options, and it didn't feel like POSTing :/
[03:20] <Sarvatt> installed what image?
[03:21] <Sarvatt> i have a freaking weird job, i need to identify workarounds need to make specific systems work so they can be preinstalled, the make them work in that release+1 out of the box
[03:44] <bjsnider> does suspend/resume work well using the blob?
[03:44] <bjsnider> i read complaints
[04:54] <RAOF> broder: Confirmed; hybrid-detect only prints "integrated" on the intel/ati hybrid system, even with the break removed (so, iterating over all the PCI devices)
[05:41] <broder> RAOF: excellent, thanks
[07:30] <broder> what happens if i start X with both nvidia-current and nvidia-173 installed?
[07:30] <broder> how does it figure out which kernel module to use?
[07:31] <tjaalton> dpkg-checkbuilddeps: error: --help is not a valid version'
[07:31] <tjaalton> fun
[07:33] <tjaalton> Build-Depends: debhelper (>= 8), dh-autoreconf, pkg-config, xserver-xorg-dev (>= --help)
[07:33] <tjaalton> :P
[07:36] <ricotz> cnd, hi, i think you should bump this depend x11proto-input-dev (>= 2.0.1-1ubuntu1) in 2:1.11.2.902-1ubuntu1
[07:38] <Sarvatt> ricotz: configure.ac require higher?
[07:38] <ricotz> RAOF, hi, ^
[07:39] <ricotz> Sarvatt, i guess it is mandatory for the backport xi2.2 stuff
[07:39] <ricotz> so i guess the configure bump is missing too
[07:40] <Sarvatt> is it mandtory? a commit got left out of the backport if so
[07:41] <ricotz> i think so
[07:42] <tjaalton> patch 05/42 of the multitouch bundle
=== jibel_ is now known as jibel
=== yofel_ is now known as yofel
[14:07] <ricotz> tjaalton, hi, do you have a link to your libwacom repo if you already pushed it?
[14:16] <tjaalton> ricotz: haven't pushed yet
[14:17] <ricotz> tjaalton, ok
[14:30] <tjaalton> hum, left already
[14:30] <tjaalton> git://anonscm.debian.org/users/tjaalton-guest/libwacom.git
[21:07] <RAOF> tjaalton: Yeah, I spotted that *almost* immediately ;)
[22:01] <RAOF> A suprising amount of our desktop really, really doesn't like multitouch going away.
[22:02] <RAOF> Unity?  Dies.  Unity2D?  The launcher will spin at 100% CPU and not display.  Evince?  Likewise.
[22:05] <FernandoMiguel> eheh
[22:06] <jcristau> so you can't remote an ubuntu desktop against a $something_else X server?
[22:10] <RAOF> I guess not.
[22:11] <RAOF> Those are all bugs, but they're obviously bugs that no-one's cared enough about; I think it's a pretty rare corner-case.
[22:14] <Sarvatt> RAOF: the evince one popped up in a precise libutouch-geis update, ricotz has a bug open about it
[22:14] <Sarvatt> think it affected EOG too
[22:20] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/utouch-geis/+bug/898175
[22:20] <ubot4> Launchpad bug 898175 in utouch-geis (Ubuntu) "uTouch hangs using XCB back end if X server does not support gesture protocol (affects: 3) (heat: 16)" [Undecided,Confirmed]
[22:20] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/utouch-geis/+bug/879348
[22:20] <ubot4> Launchpad bug 879348 in utouch-geis (Ubuntu) (and 1 other project) "evince segfaults (affects: 8) (dups: 2) (heat: 49)" [Undecided,Incomplete]
[22:59] <Sarvatt> RAOF: finally friggin found it http://www.spinics.net/lists/dri-devel/msg17272.html
[22:59] <Sarvatt> it was on dri-devel, i was looking through lkml and intel-gfx
[23:02] <RAOF> Because having just a single mailing list would have made that too hard ;)
[23:02] <Sarvatt> oh boy, file system corruption for that guy from it too
[23:03] <RAOF> Yeah.  Memory corruption is not my favourite thing.
[23:05] <RAOF> As you can see, I'm not up-to-date on my dri-devel reading :)