[07:23] <mlankhorst> morning
[07:51] <RAOF> Aloha!
[07:53] <mlankhorst> so it seems intel works on x 1.12 but broke on earlier, sigh :S
[07:55] <tjaalton> broke?
[07:55] <tjaalton> what broke it
[07:56] <mlankhorst> crashes on some damage when I try to start it
[07:57] <mlankhorst> so I'm trying to bisect xserver now for it
[07:58] <tjaalton> but this is quantal?
[07:59] <tjaalton> i'm just confused :)
[07:59] <mlankhorst> im trying to make this one start on precise at least, the x1.12 ppa works on precise
[08:28] <mlankhorst> so -> bisection time
[09:38] <mlankhorst>  ah perfect, the part where it bumped video abi still triggers crash
[10:38] <mlankhorst> hm, I think bisecting kernel is more pleasant than X..
[11:56] <mlankhorst> oddly enough now the 1.12 version is crashing too, i swear it worked before, but maybe that was without valgrind
[12:08] <mlankhorst> RAOF: is the osvendorfatalerror needed in the rethrow signals xorg-server patch
[12:29] <mlankhorst> cnd: ping?
[14:02] <mlankhorst> interesting.. another valgrind issue
[14:03] <mlankhorst> victim being radeon on suspend/resume it seems
[14:04] <cnd> mlankhorst, pong
[14:05] <mlankhorst> cnd: in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/968845 you mention a xorg-xserver patch that has to be reverted due to another bug
[14:05] <mlankhorst> https://bugs.launchpad.net/ubuntu/precise/+source/xorg-server/+bug/1009629
[14:07] <cnd> yes?
[14:08] <mlankhorst> is that x server patch really required for the other bug to be fixed?
[14:08] <cnd> a fix is required, but there's a new set of patches that fixes it properly
[14:09] <cnd> see http://cgit.freedesktop.org/xorg/xserver/log/
[14:09] <cnd> everything from "include: add BUG_RETURN_* macros" to "dix: disable all devices before shutdown" I think
[14:10] <mlankhorst> ah k
[14:10] <mlankhorst> does it need any fixes in synaptics as well?
[14:10] <jcristau> that set wasn't considered suitable for the stable branch though
[14:14] <mlankhorst> jcristau: hm I am tempted to send in a patch for server that reverts to the old behavior at least, quickly reviewing up to drop client argument reveals no functional change so that part could be skipped..
[14:14] <cnd> jcristau, why not?
[14:15] <cnd> is it an abi breaker?
[14:15] <jcristau> because it's a rabbit hole, aiui
[14:17] <cnd> mlankhorst, we still need synaptics 1.6.2
[14:17] <cnd> and we will still need this bug fixed in the server
[14:18] <cnd> whether it's by backporting all those patches or just creating a smaller patch to do the same thing on our server
[14:19] <mlankhorst> ok I'm not a xorg dev but looks like we'd need to pick 'dix: return early from DisableDevice if the device is already disabled' onwards only, but freeing sprite when device is disabled looks risky for stable.
[14:20] <cnd> yeah, the previous patches just may include functionality that is used in these patches
[14:20] <cnd> we could remove any instances of BUG_RETURN_VAL
[14:20] <mlankhorst> I'll use my memory corruption for justification of synaptics 1.6.2 then :)
[14:21] <mlankhorst> those seem functionally identical so yeah could be dropped
[14:22] <cnd> mlankhorst, I can't tell if the bad patch is supposed to be reverted though
[14:22] <cnd> or just left as is, with these new fixes on top
[14:22] <mlankhorst> I'll just check if that git tree has it
[14:22] <cnd> I'm trying to figure out
[14:22] <cnd> yeah
[14:23] <mlankhorst> judging from http://cgit.freedesktop.org/xorg/xserver/commit/?id=4c68f5d395c66f28b56e488cb3cd12f36820357b it was supposed to be kept in
[14:26] <cnd> yeah
[14:26] <mlankhorst> I'll test 
[14:27] <mlankhorst> if Xephyr is broken still on top of those I'll sru the revert patch for now
[14:53] <mlankhorst> only 1 patch has to be adjusted fortunately
[15:10] <mlankhorst> cnd: one question though, http://cgit.freedesktop.org/xorg/xserver/commit/?id=e433d1046c222f9d969c2c28a4651ff9097614f4
[15:11] <mlankhorst> dev->enabled is set last, wouldn't it be possible for DisableDevice to be called twice on same device as result?
[15:12] <mlankhorst> probably not possible due to semantics, but I thought I'd ask :)
[15:12] <jcristau> the server is single threaded
[15:12] <jcristau> and i don't think you get to call disabledevice from a signal handler
[15:12] <mlankhorst> jcristau: I mean more because of the additional disabledevice call there
[15:12] <jcristau> ah
[15:13] <jcristau> stupid me
[15:14] <jcristau> i don't think the if would fire for both paired devices
[15:14] <mlankhorst> neither, just wanted to have confirmation from someone who understands the code better :)
[15:15]  * jcristau shuts up :)
[15:26] <cnd> mlankhorst, yes, this shouldn't be an issue if I understand things right :)
[15:26] <cnd> tbh, I don't know all the ins and outs of paired devices and how they are implemented
[15:26] <cnd> whot is probably the only one who does
[15:26] <mlankhorst> im guessing one of them has to be sprite owner
[15:26] <cnd> yeah
[15:31] <mlankhorst> in either case refreshed those patches on x1.11, seems to fix the Xephyr issue.
[15:39] <mlankhorst> cnd: can you upload to proposed?
[15:54] <mlankhorst> or anyone? :)
[15:57] <cnd> mlankhorst, I can
[15:57] <cnd> do you have a package ready?
[15:57] <mlankhorst> yeah it's in xorg-server ubuntu-precise branch
[15:58] <mlankhorst> brb food
[16:00] <cnd> mlankhorst, ok, I'll review and upload
[16:00] <cnd> thanks!
[16:27] <cnd> mlankhorst, uploaded to precise-proposed
[16:27] <mlankhorst> thanks :)
[16:28] <mlankhorst> I added ubuntu-sru to the bug report, do I need to do anything else?
[16:31] <seb128> mlankhorst, https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[16:31] <seb128> mlankhorst, basically your bug need "impact", "regression potential" and "test case" in its description
[16:31] <seb128> mlankhorst, and to be nominated for precise ... what bug number is that?
[16:32] <mlankhorst> seb128: those are in the bug :) https://bugs.launchpad.net/ubuntu/precise/+source/xorg-server/+bug/1009629
[16:32] <seb128> mlankhorst, ok, you are all set then
[16:32] <mlankhorst> perfect, thanks :)
[16:32] <seb128> mlankhorst, I've put the precise line to fix commited
[16:32] <seb128> since that got uploaded
[16:32] <mlankhorst> ah k
[16:33] <seb128> mlankhorst, you should probably get the fix in quantal as well, or at least in the package vcs for quantal
[16:33] <mlankhorst> it is
[16:33] <seb128> mlankhorst, the SRU team likes to make sure issue will be addressed in the devel version as well
[16:33] <seb128> mlankhorst, ok, then probably put the bug from confirmed to fix commited
[20:09] <mlankhorst> cnd: can you upload xserver-xorg-input-synaptics ubuntu-precise branch too after I verify it? And maybe upload ubuntu branch to quantal so that version in quantal won't be lower than precise.
[20:15] <cnd> mlankhorst, sure, just let me know when you're done verifying
[20:15] <cnd> thanks!
[20:15] <mlankhorst> I verified it with the quantal package so you can upload that one at least (since it's just a version bump)
[20:18] <mlankhorst> ok precise one too :)
[20:25] <mlankhorst> Tomorrow I'm going to take a look at why valgrind is throwing errors at radeon suspend, noticed that when testing synaptics. Hopefully after that my radeon laptop shows up no errors with valgrind any more. :)
[21:32] <ernstp> looks like the radeon module in no longer included in linux-image from 3.4 builds and on
[21:32] <ernstp> both precise and mainline
[21:33] <ernstp> it boots with vesafb and then I can't access the computer when xorg starts actually, still ssh though
[21:33] <ernstp> I mean qunatal and mainline
[21:41] <jwi> ernstp: install the *-image-extra-* package
[21:50] <dupondje> Hi some small question. How about Optimus support in Quantal? Something got in yet or ?
[21:51] <mlankhorst> >implying support is available upstream
[21:51] <mlankhorst> ;)
[21:52] <dupondje> having bumblebee would be a great step imo ...
[21:52] <jcristau> hahaha
[21:52] <jcristau> you must be kidding
[21:52] <mlankhorst> bumblebee is a great step, it's in the wrong direction though..
[21:52] <dupondje> why ?
[21:52] <dupondje> bumblebee is not THE solution indeed
[21:53] <mlankhorst> it's unmaintainable and upstream work is already being done with dmabuf
[21:53] <dupondje> I just want a solution so I can disable my second vga card
[21:53] <dupondje> cause in a laptop, its a power drain
[21:54] <jcristau> why did you buy it then?
[21:54] <dupondje> because else it works fine :)
[21:55] <dupondje> its better having a partial solution then nothing no ?
[21:55] <jcristau> no
[21:55] <mlankhorst> not if the solution is WRONG :(
[21:55] <jwi> as long as you don't have to maintain it...
[21:56] <dupondje> whats the plan for Quantal then ?
[21:56] <mlankhorst> upstream the prime bits
[21:57] <dupondje> which will take care of suspending the second vga card ?
[22:16] <mlankhorst> dupondje: Hopefully, but that hasn't been completed yet :)
[22:17] <dupondje> where can I follow its status ? :)
[22:17] <mlankhorst> follow x server commits, especially xrandr related ones currently
[22:19] <dupondje> ok thanks!