lucazadehi! 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/72636912:11
lucazadeis there any proper fix planned?12:17
tjaaltonsure, when it's available12:22
lucazadeis there a bug bug upstream to follow?12:24
tjaaltonprobably https://bugs.freedesktop.org/show_bug.cgi?id=3442712:25
ubot4`Freedesktop bug 34427 in Server/general "Graphical corruption when opening windows" [Normal,New]12:26
lucazadereally 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 gdm12:28
=== yofel_ is now known as yofel
lucazadeif I enable compiz is no more present12:29
lucazadeanyway i get the same garbled frame like this bug report12:30
lucazadethanks for updating bug tjaalton ... going to try to disable composite extension in xorg.conf12:40
tjaaltonwould be more helpful to try 1.10 again with that commit disabled12:41
tjaaltonand report back if it helps or not12:41
lucazadeyes with 1.1012:42
lucazadeshould i apply also the patch proposed or ubuntu xorg 1.10 is already patched?12:44
tjaaltonwhich proposed patch?12:45
tjaaltonoh, that's the one that backs out the commit12:46
ubot4`Freedesktop bug 34427 in Server/general "Graphical corruption when opening windows" [Normal,New]12:46
tjaaltonso yes12:46
lucazadenot an easy road12:46
tjaaltonyou haven't built debs before? then don't bother, it'll probably get reverted sooner or later12:47
lucazadeyes i've built some stuff.. but xorg is a bad beast12:47
tjaaltonand tbh I've seen it too, with savage12:47
tjaaltonit's just the server12:48
lucazadeah ok12:48
tjaaltondrop the patch in debian/patches, add it to d/p/series and build12:48
lucazadein xserver-xorg-core ?12:49
tjaaltonxorg-server is the source package12:49
lucazadeok .. i'll try to do something ;)12:50
tjaaltoni'll try it myself some day if nothing else12:52
=== njpatel is now known as njpatel_
mdeslaurbryceh: 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:30
Sarvattwe weren't doing that already? we really need to be13:33
mdeslaurtjaalton: yep we're doing it already, or yep we need to be doing it?13:35
tjaalton"need to be.."13:36
tjaaltonI'll push that to git for now13:42
Sarvatttjaalton: that patch just adds info, the actual quirking is done in a kernel patch13:45
SarvattI could swear we quirked them to noaccel shortly after lucid..13:46
Sarvattbut I cant find it13:47
tjaaltonoh, heh13:47
tjaaltonof course, duh13:48
=== njpatel_ is now known as njpatel
Sarvatthttps://bugs.freedesktop.org/attachment.cgi?id=44779 yay nouveau_vieux builds again15:52
Sarvatthttp://kernel.ubuntu.com/~sarvatt/2011Q1/ -- if anyone else wants kernels that actually work on sandybridge :P17:23
tjaaltonnot available yet :/ (the hw)17:28
Sarvattwaiting for lenovo?17:30
Sarvattwonder how much shipping would be to finland.. lol17:30
tjaaltonwell, a new desktop & server too17:34
tjaaltonwhy not replace them all at once17:34
Sarvattsandybridge desktop stuff isn't available in finland? how the heck?17:43
tjaaltonthe mb availability is still shown as "in a few weeks"17:46
tjaaltonthey were available before the flaw was announced17:47
tjaaltonshipments should've started on week 10, but..17:48
Sarvattoh dang17:49
Sarvattbryce got his replacement fixed motherboard already so hopefully wont be too much longer over there17:49
tjaaltonmy core2duo is still ok though, but would like to build the server asap :)17:49
Sarvattmesa builds in 8 minutes on a i7-2600 :)17:50
tjaaltonheh, even with current packaging..17:51
brycehSarvatt, yep, and I'm booted on the new board and sent the old one out via ups today17:56
Sarvattbryceh: think its too late for an intel-gpu-tools update?19:03
Sarvattdidn'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
tjaaltonthere's also libx11 1.4.2 waiting in git.. forgot to upload it19:05
brycehSarvatt, would be nice to get that up to date19:05
SarvattI added a get-orig-source target in the rules for edgers intel-gpu-tools packaging since they never release tarballs, makes it a lot easier19:06
Sarvattok I'll package it up, there's actually a bug requesting a recent bug fix commit in it too19:07
Sarvattfunny, the one in natty is exactly 1 year old today19:09
brycehI 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 lockups19:09
Sarvattthat may be a problem :)19:14
Sarvattso basically we want to just capture the error state from the kernel and drop all the intel_gpu_dump handling19:15
Sarvattmakes 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 some19:19
brycehyeah that's a good point19:21
brycehI haven't been attaching those to upstreamed bug reports, just because they're too dang big19:21
brycehplus I know ickle doesn't seem to care about the intel_gpu_dump output19:22
brycehmaybe I should rejigger the apport hook to use the kernel error codes19:22
Sarvattthe act of dumping it repeatedly that has been happening sometimes has triggered bugs on its own too19:22
tjaaltonbryceh: did you see my comments on #u-d re: xorg?19:22
brycehtjaalton, 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
tjaaltonso, is qxl useful on powerpc or armel, and use tabs instead of 8*space in vars*19:25
Sarvattarmel vars needs a major overhaul19:25
Sarvattbut I have no clue what exactly they'd want19:25
tjaaltonaiui it's a serverside package?19:25
brycehwell, I suppose people can always just ask for it if they need it.  Deleting.19:26
Sarvattppc64 would be the only one they'd ask for it on if they even care (between that and powerpc)19:27
brycehok changes pushed19:28
Sarvattthe arm guys bypass the metapackages because they dont want to pull in all that crap that'll never get used on arm though19:28
jcristaui suspect arm should just pull in fbdev19:28
tjaaltonand -dove, I hear19:29
brycehjcristau, yeah I prompted the arm guys to give me a list of the drivers they care about a while back, but they just seemed confused19:29
jcristaulool said nobody worked on dove in years19:29
tjaaltonwhich is just another framebuffer driver i guess19:29
tjaaltonjcristau: heh, ok, they still use it though19:29
Sarvattbryceh: me too, every time I hear complaining about it :P19:29
bryceharm == fun19:30
brycehok, speaking of fun, need to deal with a busted main water line.  be back in a bit19:30
tjaaltonbefore;  40 files changed, 19020 insertions(+), 16611 deletions(-)19:37
tjaaltoncurrent; 40 files changed, 10395 insertions(+), 7324 deletions(-)19:37
tjaaltonbeen splitting the diff between sis and winischofers sisfree..19:38
tjaaltonstill some way to go :P19:39
SarvattI spent a week doing that before saying screw it19:39
Sarvattwell trying to forward port the sis751 driver to the current days19:40
tjaaltonwell, I won't go all the way, just so that the diff is easier to read19:41
tjaaltonjust reorganizing the functions in sis_driver.c helped a lot19:42
tjaaltonthe premium and intel patches on top of sisfree are a lot easier to review19:43
tjaaltonand 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 preserved19:44
brycehok water ON20:07
cndbryceh, do you remember if you pulled my latest synaptics change?20:55
* cnd is checking lp20:56
loolSarvatt, 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 fbdev20:56
loolBut I don't think we have anything current in archive20:56
cndbryceh, http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git;a=commitdiff;h=bdec4bb6bb291cd893015ff1496b687e484d8e01;hp=37d215c7e1cb11aadf7f3b528296695b84c794b920:58
cndI was hoping it would get in before beta 1, but if it's too late it can wait20:58
cndI think there was something else I was meaning to get pushed too, let me try to find it20:58
cndbryceh, 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=6995430054b22d636694b16316e88d7dc0e5cf3321:00
brycehcnd, ok is that first one for the mini v touchpad issue?21:01
cndno, I haven't got to that yet21:02
cndit's just a general MT fix for synaptics semi-mt trackpads of all sorts21:02
cndneither of these fixes *must* go in for beta 121:03
brycehlool, ok too late for natty though (at least, for beta).21:03
cndbut it would be nice :)21:03
brycehok well synaptics is minor, I doubt pushing that in would be a problem21:04
cndbryceh, I hope to have a solution for the dell mini trackpads for beta 221:05
cndit's been sidetracked by other issues21:05
brycehthat git commit is rather lengthy, although most of that seems just patch goo21:05
cndyeah, it mostly is21:06
brycehok, builds fine.  have you tested this change on much hardware?21:06
cndit's been sitting in our utouch ppa for about a week or two21:06
cndand there's at least a handful of us using that21:06
cndI have such a device21:06
cndbryceh, I can get you a cleaner patch if you would like to review it21:07
Sarvatthrm 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.121:07
cndbryceh, http://paste.ubuntu.com/585039/21:07
brycehcnd, ahh much nicer21:08
brycehwas trying to eyeball what had changed about the case statements21:08
cndit gets tricky with the patches21:08
brycehok, well if you've been running it on some hardware I'll trust it's not got obvious regressions21:09
brycehkeep an eye on the bug tracker the next couple days but I'll go ahead and push it21:09
cndthe xserver one, maybe we want to push that soon after beta 121:09
cndso it can sit in the archive a while21:09
cndjust to be sure21:09
bryceh-synaptics pushed21:10
cndit has a higher potential for regression21:10
brycehcnd, yeah sounds like a good plan, I was thinking along the same lines21:10
cndthough it also has been in testing in our team for about two weeks21:10
brycehcnd, I *might* have another xserver patch going in today; if so I will slip this in with that21:11
loolbryceh: Yup; just mentioning it because we were on the topic of xorg drivers for ARM21:12
brycehlool, right21:12
loolbryceh: 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 pathes21:12
cndbryceh, ok21:13
brycehlool, 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 here21:14
brycehlool, http://paste.ubuntu.com/585049/ is what we're carrying for armel21:15
brycehlool, 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 direction21:15
brycehlool, 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-natty21:16
loolbryceh: This is correct; I would keep only fbdev; I don't even think vesa is relevant21:16
loolbryceh: Technically, dove has a PCI bus21:16
loolbryceh: So one could build these21:17
loolErr use these21:17
brycehlool, 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
loolbryceh: 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 them21:18
loolbryceh: 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 cirrus21:20
loolI'd be surprized if that's the case though21:20
brycehlool, ok sounds like a plan.  Is there a mailing list that would be appropriate to propose this on?21:20
brycehlool, or would it be better to just drop stuff post-beta and see if anyone raises issues?21:21
loolbryceh: debian-arm is very on topic for this, but then Debian might request to keep them as they theoritically oculd be used on some boards21:21
lool(back in 2min)21:21
jcristauwe could keep building the drivers, but not have xserver-xorg-video-all depend on them21:22
brycehjcristau, yeah that's sort of what I'm thinking21:22
brycehso folks could still manually install them if needed21:22
brycehand bubble up bug reports if/when it's worth re-adding them21:22
brycehlool, jcristau, ok thanks.  I'll post to debian-arm and follow up post-beta with some changes21:23
looljcristau: That's sensible in any case; I thought that was the case already21:24
jcristauit's freaking awesome.  xserver-xorg-video-all on armel depends on a lot of useless drivers, but not on omapfb or glamo21:24
loolI actually recall dropping drivers on armel in Ubuntu a while ago hmm21:24
loolah no, it was on lpia21:26
lool(or rather lpihaha)21:26
loolbryceh: One thing you need to be aware of is that the ARM drivers also often lack autodetection in the server21:27
loolbryceh: That is, if you don't have xorg.conf, the right drivers might not get selected21:27
loolthere was some work in Ubuntu specific patches a while ago, but I'm not sure how far it went21:27
brycehlool, due to lack-o-pci-bus ?21:27
jcristauyeah autodetection is only there for pci and sbus21:27
loolbryceh: That's right21:27
brycehlool, yeah I remember chatting with ncommander about that; thought he'd come up with something workable?21:28
loolthere's debian/patches/111_armel-drv-fallbacks.patch21:28
loolit seems to poke /sys and select between imx, dovefb, omapfb and fbdev21:29
* bryceh nods21:29
loolI suspect the fbdev fallback is missing, and I'm not sure the two OMAP drivers are tried, but that seems good enough21:29
brycehlooks like that is enabled in the xserver too... I take it it doesn't work universally on arm?21:29
loolbryceh: Sorry, I don't understand what you mean21:30
looldebian/patches/111_armel-drv-fallbacks.patch is in xorg-server21:30
brycehlool, sorry, I mean I take it that it doesn't provide automatic detection in all cases on arm?21:30
jcristaulool: fbdev is added as a fallback on all archs already21:31
jcristauwell all linux archs21:31
looljcristau: I fear it's patching out the fallback21:31
jcristauoh, crap, yeah.21:32
loolby default there's matches[i++] = xnfstrdup("fbdev");21:32
loolbut it's #else-d out21:32
looland only in the else statement21:32
jcristauright, sorry, i missed that on first read21:32
loolbryceh: The default is fbdev, which is sensible on ARM21:32
loolbryceh: So it's not that bad21:32
loolthe only issue I see here is that there might not be a fbdev fallback when you're expected to have the optimized driver21:33
jcristauhttp://paste.debian.net/111885/ then?21:36
loolbryceh: After some grep-ing, I confirm that there is proper OMAP DSS emulation, but I couldn't confirm for versatile which has PCI21:36
looljcristau: looks good21:37
loolbryceh: Ah found it, so no, it's not using PCI (cirrus or whatever), but a specific LCD controller21:39
loolbryceh: So I'm not aware of anybody using PCI drivers on ARM right now  :-021:41
brycehlool, ok21:42
RAOFSarvatt, tjaalton: For what it's worth, nva? accel isn't quirked off in f15.21:52
tjaaltonRAOF: they have two months until the release, so plenty of time to disable it again..21:53
RAOFThis is true.21:54
tjaaltonand people who might crack it during that time ;)21:54
RAOFAlso true :)21:54
brycehjcristau, btw thanks for the patch to patch 111.  it looks suitable to me.  lool any reservations to having that change to patch 111?22:06
brycehok, well I'll queue it for post-beta-122:11
Sarvattah hah, I can reproduce https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/739801 and it is specific to mesa 7.10.122:16
ubot4`Launchpad bug 739801 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-gt1] GPU lockup (IPEHR: 0x02000004) (affects: 1) (heat: 8)" [High,New]22:16
Sarvattthat apport hook is firing way more than it should, get crash dumps in /var/crash every 4 seconds or so while its playing22:23
loolbryceh: Nope, seems fine; thanks22:28
Sarvattnot even really hung, things are fine once you kill firefox/chromium22:28
loolbryceh: thanks a lot for caring for ARM  :-)22:28
* lool waves and goes afk22:28
popeybryceh: just fyi, i tested bug 630203 on natty, it's current expired but you asked for more info, so i added it22:51
ubot4`Launchpad bug 630203 in xkeyboard-config (Ubuntu) "Macintosh keyboard layout is wrong (affects: 2) (heat: 12)" [Undecided,Expired] https://launchpad.net/bugs/63020322:51
brycehpopey, ok thanks23:01
popeybryceh: also, dunno if it's related but bug 74212023: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/74212023:11
popeyalmost certainly not, but i got to it trying to fix the kb layout23:11
Sentynelhi 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 gold23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!