[12:11] <lucazade> hi! I've seen that reverting to xorg 1.9 in natty solves bug 726369 
[12:11] <ubot4`> Launchpad bug 726369 in xorg-server (Ubuntu) (and 2 other projects) "graphical glitches in menu and metacity (natty) (affects: 5) (heat: 28)" [Undecided,Confirmed] https://launchpad.net/bugs/726369
[12:17] <lucazade> is there any proper fix planned?
[12:22] <tjaalton> sure, when it's available
[12:24] <lucazade> is there a bug bug upstream to follow?
[12:24] <tjaalton> dunno
[12:24] <lucazade> thanks
[12:25] <tjaalton> probably https://bugs.freedesktop.org/show_bug.cgi?id=34427
[12:26] <ubot4`> Freedesktop bug 34427 in Server/general "Graphical corruption when opening windows" [Normal,New]
[12:28] <lucazade> really close to my issue.. but it is seems that bug occurs only when composite is enable. Here is the opposite, infact i see this also in gdm
[12:29] <lucazade> if I enable compiz is no more present
[12:30] <lucazade> anyway i get the same garbled frame like this bug report
[12:40] <lucazade> thanks for updating bug tjaalton ... going to try to disable composite extension in xorg.conf
[12:41] <tjaalton> would be more helpful to try 1.10 again with that commit disabled
[12:41] <tjaalton> and report back if it helps or not
[12:42] <lucazade> yes with 1.10
[12:44] <lucazade> should i apply also the patch proposed or ubuntu xorg 1.10 is already patched?
[12:45] <tjaalton> which proposed patch?
[12:46] <lucazade> https://bugs.freedesktop.org/show_bug.cgi?id=34427#c13
[12:46] <tjaalton> oh, that's the one that backs out the commit
[12:46] <ubot4`> Freedesktop bug 34427 in Server/general "Graphical corruption when opening windows" [Normal,New]
[12:46] <tjaalton> so yes
[12:46] <lucazade> ugh!
[12:46] <lucazade> not an easy road
[12:47] <tjaalton> you haven't built debs before? then don't bother, it'll probably get reverted sooner or later
[12:47] <lucazade> yes i've built some stuff.. but xorg is a bad beast
[12:47] <tjaalton> and tbh I've seen it too, with savage
[12:48] <tjaalton> it's just the server
[12:48] <lucazade> ah ok
[12:48] <tjaalton> drop the patch in debian/patches, add it to d/p/series and build
[12:49] <lucazade> in xserver-xorg-core ?
[12:49] <tjaalton> xorg-server is the source package
[12:50] <lucazade> ok .. i'll try to do something ;)
[12:52] <tjaalton> i'll try it myself some day if nothing else
[13:30] <mdeslaur> bryceh: for #553789, could we at least quirk off accel (like this: http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-drv-nouveau.git;a=blob;f=nouveau-nva3-noaccel-info.patch;h=ddd6586069dc3558af30a20d17589e19bf42bfb8;hb=HEAD)
[13:33] <Sarvatt> we weren't doing that already? we really need to be
[13:33] <tjaalton> yep
[13:35] <mdeslaur> tjaalton: yep we're doing it already, or yep we need to be doing it?
[13:36] <tjaalton> "need to be.."
[13:42] <tjaalton> I'll push that to git for now
[13:45] <Sarvatt> tjaalton: that patch just adds info, the actual quirking is done in a kernel patch
[13:46] <Sarvatt> I could swear we quirked them to noaccel shortly after lucid..
[13:47] <Sarvatt> but I cant find it
[13:47] <tjaalton> oh, heh
[13:48] <tjaalton> of course, duh
[14:19] <tjaalton> http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=drm-nouveau-nva3-noaccel.patch;h=7dd9678f459282b5128dfa3d6cb4ed40b8cea0a7;hb=refs/heads/f14/master
[15:52] <Sarvatt> https://bugs.freedesktop.org/attachment.cgi?id=44779 yay nouveau_vieux builds again
[17:23] <Sarvatt> http://kernel.ubuntu.com/~sarvatt/2011Q1/ -- if anyone else wants kernels that actually work on sandybridge :P
[17:28] <tjaalton> not available yet :/ (the hw)
[17:30] <Sarvatt> waiting for lenovo?
[17:30] <Sarvatt> wonder how much shipping would be to finland.. lol
[17:34] <tjaalton> hehe
[17:34] <tjaalton> well, a new desktop & server too
[17:34] <tjaalton> why not replace them all at once
[17:43] <Sarvatt> sandybridge desktop stuff isn't available in finland? how the heck?
[17:46] <tjaalton> the mb availability is still shown as "in a few weeks"
[17:47] <tjaalton> they were available before the flaw was announced
[17:48] <tjaalton> shipments should've started on week 10, but..
[17:49] <Sarvatt> oh dang
[17:49] <Sarvatt> bryce got his replacement fixed motherboard already so hopefully wont be too much longer over there
[17:49] <tjaalton> my core2duo is still ok though, but would like to build the server asap :)
[17:50] <Sarvatt> mesa builds in 8 minutes on a i7-2600 :)
[17:51] <tjaalton> heh, even with current packaging..
[17:56] <bryceh> Sarvatt, yep, and I'm booted on the new board and sent the old one out via ups today
[19:03] <Sarvatt> bryceh: think its too late for an intel-gpu-tools update?
[19:05] <Sarvatt> didn't realize the one in ubuntu was so old, no wonder I have to run all  the error states from the kernel through intel_error_decode :)
[19:05] <tjaalton> there's also libx11 1.4.2 waiting in git.. forgot to upload it
[19:05] <tjaalton> earlier
[19:05] <bryceh> Sarvatt, would be nice to get that up to date
[19:06] <Sarvatt> I added a get-orig-source target in the rules for edgers intel-gpu-tools packaging since they never release tarballs, makes it a lot easier
[19:07] <Sarvatt> ok I'll package it up, there's actually a bug requesting a recent bug fix commit in it too
[19:08] <bryceh> ok
[19:09] <Sarvatt> funny, the one in natty is exactly 1 year old today
[19:09] <bryceh> I think it's probably very low risk of regression so might be includable in beta.  In any case would be nice to have it post-beta for dealing with gpu lockups
[19:14] <Sarvatt> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=56167d8bfd7dcd6959e3f0465b09833f2906baec
[19:14] <Sarvatt> that may be a problem :)
[19:15] <Sarvatt> so basically we want to just capture the error state from the kernel and drop all the intel_gpu_dump handling
[19:19] <Sarvatt> makes sense, I haven't looked at a dump since the middle of maverick since all the info is in the intel_error_decode output and then some
[19:21] <bryceh> yeah that's a good point
[19:21] <bryceh> I haven't been attaching those to upstreamed bug reports, just because they're too dang big
[19:22] <bryceh> plus I know ickle doesn't seem to care about the intel_gpu_dump output
[19:22] <bryceh> maybe I should rejigger the apport hook to use the kernel error codes
[19:22] <Sarvatt> the act of dumping it repeatedly that has been happening sometimes has triggered bugs on its own too
[19:22] <tjaalton> bryceh: did you see my comments on #u-d re: xorg?
[19:25] <bryceh> tjaalton, yeah, you think we should omit it for armel and powerpc?  I wasn't sure whether it's valid there but guessed maybe?
[19:25] <tjaalton> so, is qxl useful on powerpc or armel, and use tabs instead of 8*space in vars*
[19:25] <Sarvatt> armel vars needs a major overhaul
[19:25] <Sarvatt> but I have no clue what exactly they'd want
[19:25] <tjaalton> aiui it's a serverside package?
[19:26] <bryceh> well, I suppose people can always just ask for it if they need it.  Deleting.
[19:27] <Sarvatt> ppc64 would be the only one they'd ask for it on if they even care (between that and powerpc)
[19:28] <bryceh> ok changes pushed
[19:28] <Sarvatt> the arm guys bypass the metapackages because they dont want to pull in all that crap that'll never get used on arm though
[19:28] <tjaalton> yeah
[19:28] <jcristau> i suspect arm should just pull in fbdev
[19:29] <tjaalton> and -dove, I hear
[19:29] <bryceh> jcristau, yeah I prompted the arm guys to give me a list of the drivers they care about a while back, but they just seemed confused
[19:29] <jcristau> lool said nobody worked on dove in years
[19:29] <tjaalton> which is just another framebuffer driver i guess
[19:29] <tjaalton> jcristau: heh, ok, they still use it though
[19:29] <jcristau> ok
[19:29] <Sarvatt> bryceh: me too, every time I hear complaining about it :P
[19:30] <bryceh> arm == fun
[19:30] <bryceh> ok, speaking of fun, need to deal with a busted main water line.  be back in a bit
[19:37] <tjaalton> before;  40 files changed, 19020 insertions(+), 16611 deletions(-)
[19:37] <tjaalton> current; 40 files changed, 10395 insertions(+), 7324 deletions(-)
[19:38] <tjaalton> been splitting the diff between sis and winischofers sisfree..
[19:39] <tjaalton> still some way to go :P
[19:39] <Sarvatt> I spent a week doing that before saying screw it
[19:39] <tjaalton> hehe
[19:40] <Sarvatt> well trying to forward port the sis751 driver to the current days
[19:41] <tjaalton> well, I won't go all the way, just so that the diff is easier to read
[19:42] <tjaalton> just reorganizing the functions in sis_driver.c helped a lot
[19:43] <tjaalton> the premium and intel patches on top of sisfree are a lot easier to review
[19:44] <tjaalton> and airlied said it would probably be ok to just start from there and clean up the driver, but this way at least some of the history is preserved
[20:07] <bryceh> ok water ON
[20:07] <tjaalton> *flushhhh*
[20:55] <cnd> bryceh, do you remember if you pulled my latest synaptics change?
[20:56]  * cnd is checking lp
[20:56] <lool> Sarvatt, bryceh: Ah since you ask, there seems to be renewed interest for an imx51 fb driver which apparently does improve performance; it's another fork of fbdev
[20:56] <lool> But I don't think we have anything current in archive
[20:58] <cnd> bryceh, http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git;a=commitdiff;h=bdec4bb6bb291cd893015ff1496b687e484d8e01;hp=37d215c7e1cb11aadf7f3b528296695b84c794b9
[20:58] <cnd> I was hoping it would get in before beta 1, but if it's too late it can wait
[20:58] <cnd> I think there was something else I was meaning to get pushed too, let me try to find it
[21:00] <cnd> bryceh, ahh yes, server: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blobdiff;f=debian/changelog;h=21d73c51bdce83b440ce91d0ad48827c6cac27dc;hp=95f3efc7f801f291875a721122e6d9054f7391da;hb=debf2e97639978400e3643d0dbeecbf1a8194c3c;hpb=6995430054b22d636694b16316e88d7dc0e5cf33
[21:01] <bryceh> cnd, ok is that first one for the mini v touchpad issue?
[21:02] <cnd> no, I haven't got to that yet
[21:02] <cnd> it's just a general MT fix for synaptics semi-mt trackpads of all sorts
[21:03] <cnd> neither of these fixes *must* go in for beta 1
[21:03] <bryceh> lool, ok too late for natty though (at least, for beta).
[21:03] <cnd> but it would be nice :)
[21:04] <bryceh> ok well synaptics is minor, I doubt pushing that in would be a problem
[21:05] <cnd> bryceh, I hope to have a solution for the dell mini trackpads for beta 2
[21:05] <cnd> it's been sidetracked by other issues
[21:05] <bryceh> that git commit is rather lengthy, although most of that seems just patch goo
[21:06] <cnd> yeah, it mostly is
[21:06] <bryceh> ok, builds fine.  have you tested this change on much hardware?
[21:06] <cnd> it's been sitting in our utouch ppa for about a week or two
[21:06] <cnd> and there's at least a handful of us using that
[21:06] <cnd> I have such a device
[21:07] <cnd> bryceh, I can get you a cleaner patch if you would like to review it
[21:07] <Sarvatt> hrm vblank_mode=0 glxgears triggers a steady stream of [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 69936, at 69936], missed IRQ? on sandybridge 100% of the time with mesa 7.10.1
[21:07] <cnd> bryceh, http://paste.ubuntu.com/585039/
[21:08] <bryceh> cnd, ahh much nicer
[21:08] <bryceh> was trying to eyeball what had changed about the case statements
[21:08] <cnd> yeah
[21:08] <cnd> it gets tricky with the patches
[21:09] <bryceh> ok, well if you've been running it on some hardware I'll trust it's not got obvious regressions
[21:09] <bryceh> keep an eye on the bug tracker the next couple days but I'll go ahead and push it
[21:09] <cnd> ok
[21:09] <cnd> the xserver one, maybe we want to push that soon after beta 1
[21:09] <cnd> so it can sit in the archive a while
[21:09] <cnd> just to be sure
[21:10] <bryceh> -synaptics pushed
[21:10] <cnd> it has a higher potential for regression
[21:10] <bryceh> cnd, yeah sounds like a good plan, I was thinking along the same lines
[21:10] <cnd> though it also has been in testing in our team for about two weeks
[21:11] <bryceh> cnd, I *might* have another xserver patch going in today; if so I will slip this in with that
[21:12] <lool> bryceh: Yup; just mentioning it because we were on the topic of xorg drivers for ARM
[21:12] <bryceh> lool, right
[21:12] <lool> bryceh: I didn't even run it, but I'm on #EFIKAMX, and there was a lot of rejoicing when they managed to improve some 2D pathes
[21:13] <cnd> bryceh, ok
[21:13] <cnd> thanks!
[21:14] <bryceh> lool, I talked about this with Tobin (who had brought the topic up of why so much X stuff rebuilds when arm images are being cooked), and slangasek, and I showed them the list of drivers we build for armel, but I gather it's outside their area of expertise.  You probably would have the strongest clueage here
[21:15] <bryceh> lool, http://paste.ubuntu.com/585049/ is what we're carrying for armel
[21:15] <bryceh> lool, I think most of those drivers are way obsolete in general, and particularly are irrelevant for arm, but don't want to remove stuff without someone conversant in arm video bits giving some direction
[21:16] <bryceh> lool, possibly beta-eve is not the right time to make changes though :-)  But would be good to know what we could try dropping for post beta or even post-natty
[21:16] <lool> bryceh: This is correct; I would keep only fbdev; I don't even think vesa is relevant
[21:16] <lool> bryceh: Technically, dove has a PCI bus
[21:17] <lool> bryceh: So one could build these
[21:17] <lool> Err use these
[21:18] <bryceh> lool, I know some of these drivers are used for virtualization (-cirrus) or for specialty devices (-sisusb is used for some usb video cases).  Are those potentially of any value on arm?
[21:18] <lool> bryceh: Given that these drivers are very rarely used, that ARM boards rarely have a PCI bus, and that even when they do you usually have embedded graphics which you want to use, I think it's reasonnable to propose dropping them
[21:20] <lool> bryceh: For virtualization, qemu emulates real hardware: either OMAP fb which has special packages in the archive AFAIK, or a regular fb (as in the case of versatile/vexpress); we currently lack a PCI bus for our emulated boards, except the frankenstein versatile which we should drop; I could check whether it can use cirrus
[21:20] <lool> I'd be surprized if that's the case though
[21:20] <bryceh> lool, ok sounds like a plan.  Is there a mailing list that would be appropriate to propose this on?
[21:21] <bryceh> lool, or would it be better to just drop stuff post-beta and see if anyone raises issues?
[21:21] <lool> bryceh: debian-arm is very on topic for this, but then Debian might request to keep them as they theoritically oculd be used on some boards
[21:21] <lool> (back in 2min)
[21:22] <jcristau> we could keep building the drivers, but not have xserver-xorg-video-all depend on them
[21:22] <bryceh> jcristau, yeah that's sort of what I'm thinking
[21:22] <bryceh> so folks could still manually install them if needed
[21:22] <jcristau> right
[21:22] <bryceh> and bubble up bug reports if/when it's worth re-adding them
[21:23] <bryceh> lool, jcristau, ok thanks.  I'll post to debian-arm and follow up post-beta with some changes
[21:24] <lool> back
[21:24] <lool> jcristau: That's sensible in any case; I thought that was the case already
[21:24] <jcristau> it's freaking awesome.  xserver-xorg-video-all on armel depends on a lot of useless drivers, but not on omapfb or glamo
[21:24] <lool> I actually recall dropping drivers on armel in Ubuntu a while ago hmm
[21:26] <lool> ah no, it was on lpia
[21:26] <lool> (or rather lpihaha)
[21:26] <bryceh> heh
[21:27] <lool> bryceh: One thing you need to be aware of is that the ARM drivers also often lack autodetection in the server
[21:27] <bryceh> mm
[21:27] <lool> bryceh: That is, if you don't have xorg.conf, the right drivers might not get selected
[21:27] <lool> there was some work in Ubuntu specific patches a while ago, but I'm not sure how far it went
[21:27] <bryceh> lool, due to lack-o-pci-bus ?
[21:27] <jcristau> yeah autodetection is only there for pci and sbus
[21:27] <lool> bryceh: That's right
[21:28] <bryceh> lool, yeah I remember chatting with ncommander about that; thought he'd come up with something workable?
[21:28] <lool> there's debian/patches/111_armel-drv-fallbacks.patch
[21:29] <lool> it seems to poke /sys and select between imx, dovefb, omapfb and fbdev
[21:29]  * bryceh nods
[21:29] <lool> I suspect the fbdev fallback is missing, and I'm not sure the two OMAP drivers are tried, but that seems good enough
[21:29] <bryceh> looks like that is enabled in the xserver too... I take it it doesn't work universally on arm?
[21:30] <lool> bryceh: Sorry, I don't understand what you mean
[21:30] <lool> debian/patches/111_armel-drv-fallbacks.patch is in xorg-server
[21:30] <bryceh> lool, sorry, I mean I take it that it doesn't provide automatic detection in all cases on arm?
[21:31] <jcristau> lool: fbdev is added as a fallback on all archs already
[21:31] <jcristau> well all linux archs
[21:31] <lool> jcristau: I fear it's patching out the fallback
[21:32] <lool> http://paste.debian.net/111883/
[21:32] <jcristau> oh, crap, yeah.
[21:32] <lool> by default there's matches[i++] = xnfstrdup("fbdev");
[21:32] <lool> but it's #else-d out
[21:32] <lool> and only in the else statement
[21:32] <jcristau> right, sorry, i missed that on first read
[21:32] <lool> bryceh: The default is fbdev, which is sensible on ARM
[21:32] <lool> bryceh: So it's not that bad
[21:33] <lool> the only issue I see here is that there might not be a fbdev fallback when you're expected to have the optimized driver
[21:36] <jcristau> http://paste.debian.net/111885/ then?
[21:36] <lool> bryceh: After some grep-ing, I confirm that there is proper OMAP DSS emulation, but I couldn't confirm for versatile which has PCI
[21:37] <lool> jcristau: looks good
[21:39] <lool> bryceh: Ah found it, so no, it's not using PCI (cirrus or whatever), but a specific LCD controller
[21:41] <lool> bryceh: So I'm not aware of anybody using PCI drivers on ARM right now  :-0
[21:42] <bryceh> lool, ok
[21:52] <RAOF> Sarvatt, tjaalton: For what it's worth, nva? accel isn't quirked off in f15.
[21:53] <tjaalton> RAOF: they have two months until the release, so plenty of time to disable it again..
[21:54] <RAOF> This is true.
[21:54] <tjaalton> and people who might crack it during that time ;)
[21:54] <RAOF> Also true :)
[21:54] <tjaalton> :)
[22:06] <bryceh> jcristau, btw thanks for the patch to patch 111.  it looks suitable to me.  lool any reservations to having that change to patch 111?
[22:11] <bryceh> ok, well I'll queue it for post-beta-1
[22:16] <Sarvatt> ah hah, I can reproduce https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/739801 and it is specific to mesa 7.10.1
[22:16] <ubot4`> Launchpad bug 739801 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-gt1] GPU lockup (IPEHR: 0x02000004) (affects: 1) (heat: 8)" [High,New]
[22:23] <Sarvatt> that apport hook is firing way more than it should, get crash dumps in /var/crash every 4 seconds or so while its playing
[22:23] <bryceh> sweet
[22:28] <lool> bryceh: Nope, seems fine; thanks
[22:28] <Sarvatt> not even really hung, things are fine once you kill firefox/chromium
[22:28] <lool> bryceh: thanks a lot for caring for ARM  :-)
[22:28]  * lool waves and goes afk
[22:51] <popey> bryceh: just fyi, i tested bug 630203 on natty, it's current expired but you asked for more info, so i added it
[22:51] <ubot4`> Launchpad bug 630203 in xkeyboard-config (Ubuntu) "Macintosh keyboard layout is wrong (affects: 2) (heat: 12)" [Undecided,Expired] https://launchpad.net/bugs/630203
[23:01] <bryceh> popey, ok thanks
[23:11] <popey> bryceh: also, dunno if it's related but bug 742120
[23:11] <ubot4`> Launchpad bug 742120 in gnome-control-center (Ubuntu) "Square blocks where text should be (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/742120
[23:11] <popey> almost certainly not, but i got to it trying to fix the kb layout
[23:58] <Sentynel> hi guys, anybody know if there are issues building the (official) nvidia driver modules with the gold linker? I'm getting some odd issues with X not starting newer kernel versions and I was wondering if it might have started when I switched to gold