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