#ubuntu-x 2007-04-23
<ubotu> New bug: #109139 in libx11 (main) "RDP-Session (using tsclient) crashes after some minutes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109139
<ubotu> New bug: #80959 in xorg (main) "Major screen corruption with X in Edgy on Dell Latitude D505" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80959
<ubotu> New bug: #79049 in xorg (main) "Monitor "Out of sync" with live cd" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79049
<ubotu> New bug: #77576 in xorg (main) "livecd -- X breaks w/ multi-monitors" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77576
<ubotu> New bug: #94671 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx]  fails to detect modelines in Feisty (low resolution)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94671
<ubotu> New bug: #109207 in Ubuntu "Mouse Disappears on New Login (dup-of: 63905)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109207
<ubotu> New bug: #109274 in xorg-server (main) "[apport]  Xorg crashed with signal 5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109274
<ubotu> New bug: #108853 in linux-restricted-modules-2.6.20 (restricted) "upgrade tool crashed during upgrade to 7.04" [Undecided,Confirmed]  https://launchpad.net/bugs/108853
<ubotu> New bug: #109281 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109281
<ubotu> New bug: #109282 in xserver-xorg-video-mga (main) "kdm restarting server causes loss of drm" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109282
<ubotu> New bug: #28907 in xkeyboard-config "Dapper 3: Shift cancels CapLock not OK" [Wishlist,Confirmed]  https://launchpad.net/bugs/28907
<ubotu> New bug: #109228 in linux-restricted-modules-2.6.20 (restricted) "nvidia activation failed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109228
<ubotu> New bug: #108803 in xorg (main) "Impossible d'installer  /var/cache/apt/archives/x11-common_1%3a7.2-0ubuntu11_i386.deb" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108803
<ubotu> New bug: #109199 in xorg (main) "Kubuntu Login "Slides Around the Screen" at 1280x1024 + 3 other errors with NVIDIA GeForce 6150" [Undecided,Needs info]  https://launchpad.net/bugs/109199
<ubotu> New bug: #109329 in linux-restricted-modules-2.6.20 (restricted) "nvidia upgrade failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109329
<ubotu> New bug: #108843 in xresprobe (main) "SIS 6326 (and/or Monitor): low-res configuration in Kubuntu 7.10" [Undecided,Confirmed]  https://launchpad.net/bugs/108843
<ubotu> New bug: #109414 in linux-restricted-modules-2.6.20 (restricted) "nvidia driver doesn't work with GF4 TI-4200 Go " [Undecided,Unconfirmed]  https://launchpad.net/bugs/109414
<ubotu> New bug: #109297 in xorg (main) "Dell Laptop Screen Flicker" [Undecided,Needs info]  https://launchpad.net/bugs/109297
<ubotu> New bug: #108786 in xorg (main) "Visual Glitch on the screen with a Dell inspiron 8600" [Undecided,Needs info]  https://launchpad.net/bugs/108786
<ubotu> New bug: #109210 in xorg (main) "Fiesty graphics problem" [Undecided,Needs info]  https://launchpad.net/bugs/109210
#ubuntu-x 2007-04-24
<ubotu> New bug: #109447 in xorg-server (main) "Xorg uses 100% cpu with xinerama enabled using nvidia driver " [Undecided,Unconfirmed]  https://launchpad.net/bugs/109447
<ubotu> New bug: #109453 in linux-restricted-modules-2.6.20 (restricted) "NVidia driver freezes xorg" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109453
<ubotu> New bug: #109456 in xorg (main) "Ubuntu installed with the wrong video card" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109456
<ubotu> New bug: #109459 in mesa (main) "I'dont know" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109459
#ubuntu-x 2007-04-29
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #111022 in xorg-server (main) "[apport]  Xorg crashed with signal 5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/111022
<ubotu> New bug: #111042 in linux-restricted-modules-2.6.20 (restricted) "ipw3945d not started at boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/111042
<ubotu> New bug: #42527 in xserver-xgl (universe) "Radeon 9000 and XGL reports "No screens found" at high resolutions" [Medium,Confirmed]  https://launchpad.net/bugs/42527
<ubotu> New bug: #51440 in xorg (main) "dapper 6.10 xkb configuration error" [Low,Needs info]  https://launchpad.net/bugs/51440
#ubuntu-x 2008-04-21
<ubotu> New bug: #30388 in linux-restricted-modules-2.6.15 "content in appwindows gets unreadable when moving a window" [Medium,Invalid] https://launchpad.net/bugs/30388
<jcristau> wtf 220036.
<bryce_> pesky feature requests
<ubotu> New bug: #219970 in compiz (main) "Compiz (still!) freeze on ATI X300SE (dup-of: 195051)" [Undecided,New] https://launchpad.net/bugs/219970
<ubotu> New bug: #220135 in xorg (main) "Hard lock booting/logging out/restarting" [Undecided,New] https://launchpad.net/bugs/220135
<ubotu> New bug: #220150 in linux-restricted-modules-2.6.24 (restricted) "Mouse cursor corruption on dual-head ATI Radeon Mobility X1300 (hardy+fglrx)" [Undecided,New] https://launchpad.net/bugs/220150
<ubotu> New bug: #220203 in xserver-xorg-video-intel (main) "Enabled compiz cauzes Xorg to freeze when CPU under load on HH" [Undecided,New] https://launchpad.net/bugs/220203
<Q-FUNK> guys, could it be that dexconf doesn't know about -amd or -geode?  launching without xorg.conf systematically reverts to -vesa.
<tjaalton> dexconf doesn't need to know
<tjaalton> it's the server
<Q-FUNK> server misses magic to pick -amd?
<tjaalton> yep
<Q-FUNK> can this be patched in for Hardy?
<Q-FUNK> cause right now, the driver fails to be found as -amd or -geode.
<tjaalton> should be possible
<tjaalton> patches welcome
<Q-FUNK> ajax added this to git (and I made a quick patch in bug #214119) but I'm not sure if the magic number is correct.
<ubotu> Launchpad bug 214119 in xserver-xorg-video-geode "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Triaged] https://launchpad.net/bugs/214119
<Q-FUNK> ï»¿(15:15:50) ogra: why would it work with X -cofigure then ?
<Q-FUNK> (15:16:03) ogra: test it yourself :)
<Q-FUNK> (15:16:16) Q-FUNK: beats me
<Q-FUNK> (15:16:52) Q-FUNK: Hardy's X doesn't have the amd vendor magic to associate the chip with the driver.
<tjaalton> X -configure apparently writes the Driver line to the config?
<Q-FUNK> yup
<Q-FUNK> but why would it succesfully match the driver when generating the config and not when launching without any xorg.conf?
<tjaalton> dunno, check the source
 * ogra waves
<tjaalton> ogra: howdy
<Q-FUNK> ogra: so LTSP just calls X -configure once and then copies the resulting config to the appropriate place, before launching ldm?
<ogra> right
<ogra> Xorg -configure -novtswitch :1
<ogra> is the actual call
<Q-FUNK> ok
<ogra> it creates xorg.conf.new which then gets handled by sed scripts for replacing of values with overrides from the user
<Q-FUNK> which currently succeeds at finding -amd 2.7.7.7 (or my patched version 2.7.7.8 with libDDC support)
<ogra> does it work if you try it manually as well ?
<Q-FUNK> however, it fails to find -geode completely, even with the symbolic link in place to link  amd_drv.so to geode_drv.so
<Q-FUNK> ogra: making Xorg -configure and then copying the xorg.xonf.new to /etc/X/xorg.conf ?  yes, it works, but only with -amd.
<ogra> just read it, no need to copy it :)
<ogra> is Driver "amd" in there ?
<ogra> if so, then dexconf or dpkg-reconfigure's magic suppresses something 
<ogra> ... something plain X finds
<tjaalton> dexconf doesn't write Driver at all
<ogra> it rewrites the config 
<ogra> or did that change ?
<tjaalton> yes, but a minimal one
<ogra> hmm
<jcristau> yes, dpkg-reconfigure xserver-xorg rewrites the config
<jcristau> if you don't want the config rewritten, don't do that
<ogra> then i dont see any logic in the fact that it works on ltsp but not on packages X
<ogra> *packaged
<tjaalton> pretty simple. the server xfAutoConfig.c doesn't know how to map the vendor id to "amd"
<ogra> but why does it know that with "Xorg -configure -novtswitch :1" ?
<ogra> if its known in he C code and no scipts fiddle wit it it  needs to generae the same Driver line in both cases
<ogra> the only logical explanation to me would be that the scripts fiddle with the file or the preseed avlues
<jcristau> because that's two different code paths
<jcristau> iirc
<ogra> jcristau, X is the same binary in both cases
<ogra> which is where both methods should get their core information about PCI ID -> driver assignment
<Q-FUNK> ogra: ï»¿"Xorg -configure -novtswitch :1" correctly finds -geode and writes that as Driver
<Q-FUNK> http://launchpadlibrarian.net/13589055/171_xf86AutoConfig_geode_addition.diff
<jcristau> ogra: 'Xorg -configure' and 'start X without xorg.conf' are two different code paths in the server
<Q-FUNK> so this is what would be missing, assuming that it's the right vendor id?
<ogra> jcristau, im not talking about 'start X without xorg.conf'
<tjaalton> ogra: but that's the case where it fails, which this patch should fix
<ogra> i'm talking about the two different xorg.xonf files we get from the different methids
<jcristau> ogra: well or 'without Driver in xorg.conf'
<ogra> tjaalton, oh, i didnt know you guys are experimenting without any confi here 
<tjaalton> ogra: it uses autoconfiguration for all the "missing" parts of xorg.conf..
<tjaalton> like Driver
<Q-FUNK> so Gutsy wrote the config including Driver name but Hardy only writes non-default values like keyboard map?
<tjaalton> right
<tjaalton> this has been the case since November :)
<tjaalton> or early December
<ogra> it would then default back to vesa, right ? 
<tjaalton> on x86 yes
<tjaalton> (actually there's a bug that it fails to fall back to fbdev on ppc)
<Q-FUNK> so adding the above magic patch should allow this to work without a config or Driver line?
<tjaalton> yes
<jcristau> there's nothing magic about it...
<Q-FUNK> how do I verify that I have the right ID number?
<jcristau> lspci
<Q-FUNK> and, ok, if we merge the above patch in Hardy, we'd probably need to call the driver geode instead of amd.
<jcristau> why?
<Q-FUNK> or would you rather leave it as amd, despite the driver rename?
<jcristau> i think it doesn't matter
<Q-FUNK> jcristau: which line in lspci's VGA section?
<tjaalton> Subsystem
<jcristau> the one that tells you the vendor id, which is 1022
<tjaalton> bryce: please push your xorg-server changes to git :)
<tjaalton> hmm, and asac did an upload too
<Q-FUNK> jcristau: subsystem doesn't list this here.  should I paste the result of lspci -v-v-v somewhere?
<tjaalton> -vn should be enough
<jcristau> no, it's not subsystem
<tjaalton> the first part of it
<tjaalton> ?
<jcristau> lspci -n -> 01:00.0 0300: 10de:018a (rev a2)
<jcristau> the 10de there says it's nvidia
<Q-FUNK> ok, just a second. lemme output this to a file
<tjaalton> oh right, not subsystem
<tjaalton> that was for something else :)
<jcristau> Q-FUNK: not needed. http://pci-ids.ucw.cz/iii/?i=1022
<Q-FUNK> 1022:2081 
<Q-FUNK> yup
<Q-FUNK> so we have the right number
<jcristau> (who doubt that?)
<Q-FUNK> so it's just a matter of merging http://launchpadlibrarian.net/13589055/171_xf86AutoConfig_geode_addition.diff except that we'd have it load "geode" instead of "amd" then?
<tjaalton> bbl ->
<Q-FUNK> that would make X work without Driver line and also in LTSP with Xorg -configure?
<jcristau> that wouldn't change anything for -configure
<Q-FUNK> jcristau: having the right number and X that actually does what it's intended to are two separate issues.
 * jcristau gives up
<tjaalton> :P
<ubotu> New bug: #213265 in xkeyboard-config (main) "Keyboard layout forgotten (hardy)" [Undecided,Confirmed] https://launchpad.net/bugs/213265
<ubotu> New bug: #219835 in ubuntu "Keyboard settings revert following restart (dup-of: 213265)" [Undecided,New] https://launchpad.net/bugs/219835
<jcristau> those sound like gnome bugs rather than xkeyboard-config
<ubotu> New bug: #220143 in xorg (main) "update manager crashed while updating from Gutsy to Heron" [High,Incomplete] https://launchpad.net/bugs/220143
<tjaalton> yep..
<Q-FUNK> komputes: reply sent :)
<ubotu> New bug: #36978 in linux-restricted-modules-2.6.15 "Dual Head Monitor sleep gives a black screen" [Medium,New] https://launchpad.net/bugs/36978
<pochu> I have a quick question... I'm going to buy a new graphic card, but I'm not sure whether to buy nVidia or ATI... given that ATI is going to open the closed source driver (because they haven't yet, right?) what would you suggest me to do?
<jcristau> no, they aren't going to open the closed source driver
<federico1> pochu: get an ati; AMD is releasing documentation for their chips
<bryce> lmao - http://www.youtube.com/watch?v=sPv8PPl7ANU
<pochu> oh, is it only the specs? I thought it was the driver itself, but re-reading this I see I misunderstood it: http://www.linux.com/feature/119049
<jcristau> pochu: they're working on the free radeon driver as well, and paying novell for their radeonhd work, but fglrx will remain closed
<bryce> pochu: AMD/ATI has been a lot more active in the X / Linux community than nVidia.
<ubotu> New bug: #218184 in ubiquity (main) "Kubuntu 8.04 beta not finish the installation in Brazil locale (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/218184
<pochu> I see, thank you all for your answers
<pochu> OTOH, I can't find a mid-range low-profile ATI card... :/
<bryce> Initialized empty Git repository in /home/bryce/src/xorg-server/xorg-server/.git/
<bryce> ssh: connect to host alioth.debian.org port 22: Connection timed out
<bryce> fatal: The remote end hung up unexpectedly
<jcristau> bryce: weird. seems to work for me
<bryce> tjaalton: anyway, I'd like to get my last xorg-server commit into git, but it seems to be inaccessible to me
<jcristau> bryce: ssh works?
<bryce> jcristau: yes
<jcristau> i just did 'git clone git.debian.org:/git/pkg-xorg/xserver/xorg-server'
<bryce> I was trying git clone ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git
<jcristau> should be the same
<jcristau> and ssh shouldn't timeout anyway. is it reproducible?
<bryce> yep
<jcristau> hmm
<bryce> aha, that time it seems to be going
<mario_limonciell> tjaalton, so slangasek shot down fglrx-8-04 for deferring to hardy-8.04.1 right?
<tjaalton> mario_limonciell: that's right
<tjaalton> bryce: ok, cool
<mario_limonciell> okay. 
<pochu> why, oh why did I buy a slim desktop?
<ubotu> New bug: #220345 in xserver-xorg-video-ati (main) "[hardy] kernel 2.6.24-16-generic + radeon driver = system freezes" [Undecided,New] https://launchpad.net/bugs/220345
<ubotu> New bug: #220344 in xorg (universe) "Transparency function in Xlib API for programmers" [Undecided,New] https://launchpad.net/bugs/220344
<jcristau> someone should reject that one... (220344)
<bryce> ok I'll take a look
<bryce> hmm, xcb sounds like the wrong level for such a functionality
<tjaalton> ok, running F9 live from a usb stick.. wanted to see kernel modesetting in action
<tjaalton> funny that it used 1360x768 by default, native is 1024x768
<ubotu> New bug: #220361 in xorg (main) "8.10RC install fails on Dell Latitude D600" [Undecided,New] https://launchpad.net/bugs/220361
<bryce> jcristau, seb128: there is a patch for xserver-xgl at https://bugs.launchpad.net/ubuntu/+source/xserver-xgl/+bug/215396/comments/11 that fixes xgl to report the correct version of xrandr it supports
<ubotu> Launchpad bug 215396 in gnome-control-center "gnome-display-properties crashed with SIGSEGV in _start() [when running xgl]" [Medium,Fix released] 
<ubotu> New bug: #220364 in xserver-xorg-video-nv (main) "Nvidia card 7150 not recognized in Hardy RC Live CD" [Undecided,New] https://launchpad.net/bugs/220364
<jcristau> bryce: better do something like http://cgit.freedesktop.org/xorg/xserver/diff/randr/rrdispatch.c?id=3b71b0f89f1db837da91650baa0ef4bb7ef2e98f imo
<jcristau> (with 1 as SERVER_RANDR_MINOR)
<jcristau> rather than redefine stuff from randrproto
<bryce> jcristau: *nod*
<jcristau> bryce: btw debian doesn't ship xgl :)
<bryce> ahh
<bryce> didn't know that; ok so nevermind on that one
<bryce> (I wish we didn't ship xgl either, but anyway)
<bryce> federico1: hey, so how did last week's xrandr gui hacking session go?  Got many good patches?
#ubuntu-x 2008-04-22
<ubotu> New bug: #220417 in linux-restricted-modules-2.6.24 (restricted) "package linux-restricted-modules-2.6.24-16-generic 2.6.24.12-16.34 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/220417
<federico1> bryce: not really so far :(
<federico1> bryce: I was rather distracted by setting up the hackfest infrastructure / fighting other fires
<federico1> bryce: but this week I do want to fix stuff :)
<federico1> bryce: how was xdevconf?
<bryce> federico1: pretty good, I got a nice set of patches from alex for -ati issues and got some good insights into general x stuff.
<bryce> I'd sort of hoped to spend some time talking with soeren about xrandr gui stuff
<federico1> bryce: nice, nice
<federico1> bryce: gimme some git love :)
<federico1> bryce: alex larsson?
<jcristau> federico1: deucher, presumably
<federico1> ah, of course
<federico1> we need uuids for people
<jcristau> heh
<ubotu> New bug: #220430 in linux-restricted-modules-2.6.24 (restricted) "Have to reinstall linux-restricted-modules-2.6.24 after boot for fglrx" [Undecided,New] https://launchpad.net/bugs/220430
<ubotu> New bug: #220469 in xserver-xorg-video-nv (main) "nv driver gives grainy/blurred output GF FX Go 5200" [Undecided,New] https://launchpad.net/bugs/220469
<ubotu> New bug: #220471 in xserver-xorg-video-intel (main) "Dialog pops up indicating switching to low resolution mode when no monitor is connected" [Undecided,New] https://launchpad.net/bugs/220471
<ubotu> New bug: #220510 in xorg-server (main) "X fails to use GEODE and reverts to VESA on a host without any xorg.conf" [Undecided,New] https://launchpad.net/bugs/220510
<ubotu> New bug: #215039 in xorg-server (main) "Xorg crashed with SIGSEGV in XkbWriteXKBGeometry()" [Medium,Incomplete] https://launchpad.net/bugs/215039
<ubotu> New bug: #211897 in xserver-xorg-video-intel (main) "Xorg crashed with SIGSEGV in xf86RandR12SetRotations()" [Medium,New] https://launchpad.net/bugs/211897
<ubotu> New bug: #220563 in xorg (main) "[Hardy] Xinerama no longer used but the replacement is not obvious!" [Undecided,New] https://launchpad.net/bugs/220563
<ubotu> New bug: #215699 in xkeyboard-config (main) "Error activating XKB configuration." [Undecided,New] https://launchpad.net/bugs/215699
<ubotu> New bug: #210140 in xkeyboard-config (main) "Error in activating xkb configuration" [Undecided,New] https://launchpad.net/bugs/210140
<ubotu> New bug: #116513 in xkeyboard-config (main) "'MacBook/MacBook Pro (Intl)' Keyboard Model error" [Undecided,New] https://launchpad.net/bugs/116513
<ubotu> New bug: #164191 in xkeyboard-config (main) ""Default" keyboard settings are seemingly incompatible with GNOME" [Undecided,New] https://launchpad.net/bugs/164191
<seb128> james_w: btw, did you have a gnome-control-center update waiting for sponsoring? I think you showed me diffs for the font issue and the clone checkbox one but I'm not sure if you had a debdiff ready for upload or not
<james_w> seb128: hm, let me look
<james_w> seb128: http://paste.ubuntu.com/7766/ is the gnome-control-center one
<james_w> http://paste.ubuntu.com/7767/ is the gnome-desktop one
<seb128> ok, thanks
<seb128> I'll change the target to hardy-proposed and sponsor those there
<james_w> thanks
<mvo> seb128: is hardy-proposed open yet? or do you still upload to main hardy?
<mvo> (oh, I think you answered that already)
<seb128> mvo: I've no idea, I'll try to upload to proposed and see what happens
<mvo> let me know, I have a fix for that too
<seb128> ok
<ubotu> New bug: #220620 in linux-restricted-modules-2.6.24 (restricted) "Wireframes drawn as dashed lines in Blender" [Undecided,New] https://launchpad.net/bugs/220620
<ubotu> New bug: #135296 in xserver-xorg-video-intel (main) "Weird stripe on display" [Undecided,New] https://launchpad.net/bugs/135296
<ubotu> New bug: #220746 in xkeyboard-config (main) "The Euro key mapping only works with one keyboard layout" [Undecided,New] https://launchpad.net/bugs/220746
<bryce>  
<bryce>           
<ubotu> New bug: #220408 in mesa (main) "[savage] hyperspace closed unexpectedly" [Undecided,Confirmed] https://launchpad.net/bugs/220408
<tjaalton> bryce: I wonder how jockey would suit for the "hey you've got a wacom, wanna enable it" kind of situations
<bryce> yeah
<bryce> tjaalton: sounds like there's some discussions about envyng and jockey, and pulling drivers from ppa vs multiverse, etc.
<tjaalton> bryce: there is? I know envyng does that, but afaik jockey doesn't know about envyng
<bryce> right, pitti says it's a long range goal to have a driver update database that jockey can pull from
<bryce> I've encouraged him to work with alberto... maybe at uds we can work out some collaboration plans f2f
<tjaalton> well, for wacom (or any other input driver) it would be a mid-term solution until input-hotplug worked like it should
<bryce> true
<munckfish> Hi guys, any chance that PS3 crash fix could go in to an xserver rebuild this week? Or should we wait till after hardy release now?
<bryce> post-release probably
<munckfish> bryce: ok that's cool
<bryce> at this point only release blocker bugs are getting patches accepted
<munckfish> I think the PS3 team need to target 8.04.1 anyway
<bryce> (which I'm finding a tad inconvenient, but guess that's ok)
<bryce> munckfish: do you have the fix as a patch attached to a bug? 
<munckfish> I think I'll take a break till next week
<munckfish> well, heh, it's your patch
<bryce> oh right...  *swimming in patches*
<munckfish> sure I know :)
<bryce> could you remind me of the bug id?
<munckfish> I sure can one sec ...
<munckfish> LP 217647
<ubotu> Launchpad bug 217647 in ubuntu-ps3-port "Crash at startup on PS3 (hardy)" [Critical,In progress] https://launchpad.net/bugs/217647
<bryce> I can go ahead and commit it to our xserver git tree.  the patch was pretty trivial
<munckfish> aha ok
<munckfish> Your git tree is very interesting
<munckfish> I'm nowhere with git at the moment
<munckfish> bryce: ok. I need to go offline now, if you commit that it'd be great then I'll be back to pester again once hardy is out. Cheers!
<bryce> sure, cya
<ubotu> New bug: #220782 in xorg (main) "gdm fails to start on hardy haron with intel 965 card" [Undecided,New] https://launchpad.net/bugs/220782
<tormod> tjaalton: do you have your savage laptop handy for trying out /usr/lib/xscreensaver/hyperspace ?
<ubotu> New bug: #220738 in compiz (main) "compiz creates white screen with cursor when resuming from suspend or hibernate (dup-of: 160264)" [Undecided,New] https://launchpad.net/bugs/220738
<ubotu> New bug: #220781 in linux-restricted-modules-2.6.24 (restricted) "linux-restricted-modules-server metapackage not present in repository" [Undecided,New] https://launchpad.net/bugs/220781
<bryce> committed and pushed
<bryce> tormod: I've been exchanging emails with the ATI engineer working on those top 5 fglrx bugs
<bryce> tormod: so far results are unimpressive - mostly they report being unable to reproduce the bugs
<tormod> bryce: they do run hardy?
<bryce> yeah
<tormod> bryce: and they use amd64? do you think it can be related to certain types of hardware?
<bryce> I think it might be hardware specific, not sure
<bryce> they didn't tell me details of what system(s) they're testing on 
<tjaalton> tormod: actually I do, but it's not updated for awhile
<tormod> tjaalton: there's some mesa explosion in bug #220408
<ubotu> Launchpad bug 220408 in mesa "[savage] hyperspace closed unexpectedly" [Undecided,Confirmed] https://launchpad.net/bugs/220408
<tjaalton> tormod: it should crash?
<tjaalton> because it doesn't crash here
<tormod> tjaalton: yes it crashes/hangs for both the reporter and myself.
<tjaalton> maybe it's hanging (99% cpu) but doesn't seem to eat memory
<ubotu> New bug: #182598 in xserver-xorg-video-intel (main) "intel 965 3d graphic application don't work" [Undecided,New] https://launchpad.net/bugs/182598
<tjaalton> the animation works for a couple of seconds
<tormod> tjaalton: sometimes it works for me after going maximized window
<tjaalton> oh, neat
<tjaalton> I need to try again tomorrow after the packages have been updated
<tjaalton> night ->
<bryce> night timo
<ubotu> New bug: #220809 in libx11 (main) "XkbGetKeyboard returns null" [Undecided,New] https://launchpad.net/bugs/220809
<ubotu> New bug: #220065 in xrandr (main) "[Heron] X server does not properly configure laptop monitor on Everex VA2001T" [Undecided,New] https://launchpad.net/bugs/220065
#ubuntu-x 2008-04-23
<ubotu> New bug: #220821 in xorg-server (main) "Mouse wheel with xephyr and ubuntu 8.04" [Undecided,New] https://launchpad.net/bugs/220821
<ubotu> New bug: #220846 in xorg (main) "Gutsy to Hardy upgrade crash  Logs and Config available" [Undecided,New] https://launchpad.net/bugs/220846
<ubotu> New bug: #220869 in xserver-xorg-input-fpit (universe) "X crashes after installing fpit driver in Hardy" [Undecided,New] https://launchpad.net/bugs/220869
<ubotu> New bug: #220876 in xorg (main) "[Hardy] Xorg crashed with SIGSEGV in miPointerUpdateSprite" [Undecided,New] https://launchpad.net/bugs/220876
<ubotu> New bug: #220887 in xserver-xorg-driver-ati "Radeon M6 / fail to detected the screen on PowerBook3,3" [Undecided,New] https://launchpad.net/bugs/220887
<tjaalton> bryce_: I'll ask pitti about jockey & wacom, and if it could be possible to get something even for 8.04.1
<bryce> tjaalton, ok
<bryce> tjaalton: btw I finally packaged up those -ati patches for testers
<bryce> tjaalton: looking through the bug tracker, there's a ton of bugs that look like it might fix; I'm requesting people test.
<tjaalton> bryce: nice, the number of ati bugs has (almost) gone through the roof :)
<bryce> yeah :-/
<bryce> I feel kind of bad because I focused most of my hardy triaging time to intel, knowing that drivers like -ati needed attention too.  But only so many hours in the day...
<tjaalton> yeah.. and I was being selfish about the damn nvidia blob (which I use nowadays, like all the boxes at work..)
<bryce> but I am going to focus exclusively on -ati now for a little while and see if I can bring its bug count down too.  maybe whatever tricks I learned doing -intel will help
<bryce> tormod seems to have been giving -ati some attention though
<ubotu> New bug: #220103 in linux-restricted-modules-2.6.24 (restricted) "Madwifi randomly disconnects and reconnects; causes networkmanager to flood logs" [Undecided,New] https://launchpad.net/bugs/220103
<tjaalton> I'm also thinking that we shouldn't be _too_ paranoid about pushing fixes in -updates.. things tend to sit in -proposed for way too long. I hope the stable release manager would handle some of the bureaucracy there, or cut it down
<ubotu> New bug: #186095 in xserver-xorg-video-intel (main) "hardware destroyed!" [Undecided,Incomplete] https://launchpad.net/bugs/186095
<ubotu> New bug: #189867 in xserver-xorg-driver-nv "enabling fastwrites and SBA" [Undecided,Confirmed] https://launchpad.net/bugs/189867
<ubotu> New bug: #214683 in ubuntu "[Hardy]  Mathematica fonts look bad (dup-of: 197163)" [Undecided,Incomplete] https://launchpad.net/bugs/214683
<ubotu> New bug: #190356 in xserver-xorg-input-mouse (main) "Aquila L1 tablet malfunctioning" [Undecided,Incomplete] https://launchpad.net/bugs/190356
<bryce> tjaalton: that's something I've been worried about myself
<bryce> tjaalton: I'll follow your lead in how best to get fixes rolled out to folks, I could definitely use some advice.  In the past when I've tried doing SRU's they seem to end up stuck in limbo
<bryce> tjaalton: for today's -ati package I would like to get extensive testing before we push patches in it.  
<tjaalton> bryce: yeah..
<tjaalton> I could test it on the r200 I still have
<seb128> bryce: don't try to push 15 patches in one SRU, too complex to give that good testing and figure what can create issue for who
<bryce> seb128: I wasn't planning to
<seb128> ok, just mentionning it in case
<bryce> seb128: the combined package is there mainly for ease of testing.  If we find it fixes specific bugs, I want to ferret out which patch did the actual fix.
<seb128> ok
<bryce> presently we have a bunch of patches but don't know what bug id's they might solve.
<seb128> there is no reason for SRU to be stucked if there is a testcase and some user can confirm the update fixes the issue
<bryce> seb128: well there's more minutia to take care of than that... must set subscribers, bug states, etc. just so, else it gets ignored
 * bryce wishes for a nice simple "SRU this bad boy" button
 * bryce . o O (greasemonkey script?  hmm)
<seb128> bryce: right, the wiki instruction were not nice, I discussed that with pitti and he simplified the page now
<seb128> that's basically
<seb128> - have a test case
<seb128> - attach the debdiff, explain how you fixed the bug
<seb128> - subscribe ubuntu-sru
<seb128> which is not too complicated
<bryce> yeah, now that's straightforward
<bryce> maybe pitti has too much german in him?  ;-)
<seb128> bryce: https://wiki.ubuntu.com/StableReleaseUpdates, read the procedure please and let me know if you think that's clear enough
<bryce> seb128: yeah I read that after it was updated; it's a lot clearer (still more steps than your nice process, but clearer).
<seb128> well, those are basically the same steps but using a verbose description ;-)
<ubotu> New bug: #220951 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new causes unusable tty's" [Undecided,New] https://launchpad.net/bugs/220951
<ubotu> New bug: #193791 in xserver-xorg-driver-nv "Default video playback settings are bad" [Low,Incomplete] https://launchpad.net/bugs/193791
<ubotu> New bug: #204579 in xorg (main) "Ubuntu 8.04 BETA won't start X.org in Qemu" [Undecided,New] https://launchpad.net/bugs/204579
<jcristau> bryce: i adapted your fix for bug 217647 to master and just pushed it, fwiw
<ubotu> Launchpad bug 217647 in ubuntu-ps3-port "Crash at startup on PS3 (hardy)" [Critical,In progress] https://launchpad.net/bugs/217647
<ubotu> New bug: #217560 in ubuntu "Blue tinge in DVD playback (dup-of: 184440)" [Undecided,New] https://launchpad.net/bugs/217560
<ubotu> New bug: #221014 in linux-restricted-modules-2.6.24 (restricted) "Desktop displayed for approx. 30 seconds on restore from hybernate (before password prompt)." [Undecided,New] https://launchpad.net/bugs/221014
<ubotu> New bug: #219950 in linux-restricted-modules-2.6.24 (restricted) "Font size on login screen is too big with nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/219950
<ubotu> New bug: #221022 in xserver-xorg-input-evdev (main) "Wireless mouse has no horizontal movement after upgrade to hardy" [Undecided,New] https://launchpad.net/bugs/221022
<ubotu> New bug: #221065 in libx11 (main) "cached compose data is not available" [Undecided,New] https://launchpad.net/bugs/221065
<seb128> bryce, james_w: the xrandr capplet asking if the settings should be applied or not is buggy, not sure what it the issue but it often doesn't revert when it should
<seb128> it's not consistant though, I can get it not working on then working after restarting the capplet in the same session
<bryce_> jcristau: thanks
<ubotu> New bug: #221092 in linux-restricted-modules-2.6.24 (restricted) "switch from multi-head to single-head => Xorg takes 100% cpu" [Undecided,New] https://launchpad.net/bugs/221092
<ubotu> New bug: #221108 in linux-restricted-modules-2.6.24 (restricted) "After installing nvidia-glx-new system slows down after login" [Undecided,New] https://launchpad.net/bugs/221108
<ubotu> New bug: #221136 in xkeyboard-config (main) "Change back ~ to just AltrGr+4 and not AltrGr+4+AltrGr+4 in Spanish keyboard" [Undecided,New] https://launchpad.net/bugs/221136
<ubotu> New bug: #221143 in libxmu (main) "package libxmuu1 2:1.0.4-1 failed to install/upgrade: files list file for package `libxmuu1' is missing final newline" [Undecided,New] https://launchpad.net/bugs/221143
<ubotu> New bug: #221158 in xserver-xorg-video-intel (main) "[Hardy] Intel VGA controller falling back onto VESA" [Undecided,New] https://launchpad.net/bugs/221158
<ubotu> New bug: #221161 in xorg (main) "Xorg crashes with signal 11 in dualhead configuration" [Undecided,New] https://launchpad.net/bugs/221161
<ubotu> New bug: #221162 in ubuntu "FGLRX with compiz fusion and KVM XP crashes X11 (dup-of: 172715)" [Undecided,New] https://launchpad.net/bugs/221162
<ubotu> New bug: #221179 in xserver-xorg-video-intel (main) "[Hardy] Intel VGA controller/driver not automatically detected" [Undecided,New] https://launchpad.net/bugs/221179
<ubotu> New bug: #220786 in linux-restricted-modules-2.6.24 (restricted) "video blinkink when its not full screen or the leave full screen menu appears" [Undecided,New] https://launchpad.net/bugs/220786
<ubotu> New bug: #221188 in xserver-xorg-video-intel (main) "[Hardy] Intel VGA controller not detected, Getting black screen instead of GDM" [Undecided,New] https://launchpad.net/bugs/221188
<ubotu> New bug: #215756 in xorg-server (main) "nvidia card cannot detect monitor and ubuntu switches to 640x480" [Undecided,Incomplete] https://launchpad.net/bugs/215756
<ubotu> New bug: #221121 in xkeyboard-config (main) "Dialog gnome-keyboard-properties > Layout > Layout settings is not localized in German" [Low,New] https://launchpad.net/bugs/221121
#ubuntu-x 2008-04-24
<ubotu> New bug: #221239 in linux-restricted-modules-2.6.24 (restricted) "hardy: nvidia-glx-new fails after upgrade" [Undecided,New] https://launchpad.net/bugs/221239
<ubotu> New bug: #220852 in xorg-server (main) "Blank screen on laptop" [Undecided,New] https://launchpad.net/bugs/220852
<ubotu> New bug: #220868 in firefox-3.0 (main) "Website crashes Gnome (dup-of: 212648)" [Undecided,Incomplete] https://launchpad.net/bugs/220868
<ubotu> New bug: #221297 in xserver-xorg-video-intel (main) "Wrong resolution for DVI connected Monitor on startup" [Undecided,New] https://launchpad.net/bugs/221297
<ubotu> New bug: #221116 in xorg (main) "gnome-display-properties: dual display does not work by default" [Undecided,New] https://launchpad.net/bugs/221116
<ubotu> New bug: #221316 in xserver-xorg-video-intel (main) "[hardy] blank screen on 855GM when playing video using intel driver" [Undecided,New] https://launchpad.net/bugs/221316
<Q-FUNK> isn't the release today? :)
<Q-FUNK>  -> topic ;)
<ubotu> New bug: #221334 in xorg-server (main) "Useful dual-head configuration requires manual editing of xorg.conf" [Undecided,New] https://launchpad.net/bugs/221334
<ubotu> New bug: #221344 in linux-restricted-modules-2.6.24 (restricted) "Hardy: Can't install and use nvidia-glx-new - only Nvidias binary installer works" [Undecided,New] https://launchpad.net/bugs/221344
<tjaalton> hrmh, xkb-and-loathing patch doesn't build with 1.0.2 & dapper
<tjaalton> xserver-1.0.2
<ubotu> New bug: #221436 in xserver-xorg-video-i810 "Screen dimmed when user could not control brightness" [Undecided,New] https://launchpad.net/bugs/221436
<bryce> heya tjaalton, happy release day :-)
<tjaalton> bryce: hi, same to you :)
 * tjaalton grabs a beer
<bryce> hmm, launchpad is pokey today
<bryce> tjaalton: so how things going?
<ubotu> New bug: #221491 in linux-restricted-modules-2.6.24 (restricted) "package xorg-driver-fglrx 8.471-0ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/221491
<ubotu> New bug: #221504 in xserver-xorg-video-intel (main) "Gaming instability in Hardy" [Undecided,New] https://launchpad.net/bugs/221504
<tjaalton> bryce: I've uploaded xorg-server for dapper-proposed (way overdue) to fix hangs when opening menus in OO.org, but it failed to build
<tjaalton> the patch needs some backporting, probably due to older gcc I think
<tjaalton> http://launchpadlibrarian.net/13852766/buildlog_ubuntu-dapper-i386.xorg-server_1%3A1.0.2-0ubuntu10.11_FAILEDTOBUILD.txt.gz
<bryce> ../../os/utils.c:1747: error: syntax error before 'old_alarm'
<tjaalton> ah right, it's the xkb-and-loathing patch, same as in hardy
<bryce> that sounds like it's a dependency problem...  maybe a newer version of whatever provides old_alarm() needs to be specified in build-depends
<tjaalton> 51..
<tjaalton> http://users.tkk.fi/~tjaalton/dpkg/xkb-and-loathing.dpatch
<bryce> aha
<ubotu> New bug: #221521 in xorg (main) "Hardy Heron: X fails to run - no screens found" [Undecided,New] https://launchpad.net/bugs/221521
<tjaalton> yet-another buggy averatec machine
<tjaalton> sometimes I envy Apple
<tjaalton> bedtime.. night ->
#ubuntu-x 2008-04-25
<ubotu> New bug: #200230 in compiz (main) "OpenGL windows flicker on mouse input and leave garbage when moved (intel video cards) (dup-of: 96991)" [Undecided,Confirmed] https://launchpad.net/bugs/200230
<ubotu> New bug: #221514 in xserver-xorg-video-intel (main) "dual monitors does not work it ignores settings" [Undecided,New] https://launchpad.net/bugs/221514
<ubotu> New bug: #221622 in x11-utils (main) "update dependency problems" [Undecided,New] https://launchpad.net/bugs/221622
<ubotu> New bug: #221624 in x11-xfs-utils (main) "package x11-xfs-utils None [modified: /var/lib/dpkg/info/x11-xfs-utils.list] failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/221624
<ubotu> New bug: #221250 in xserver-xorg-video-intel (main) "Ubuntu don't detect Intel graphic card" [Undecided,New] https://launchpad.net/bugs/221250
<ubotu> New bug: #221629 in xorg-server (main) "[hardy] x crashes semi-randomly on intel" [Undecided,New] https://launchpad.net/bugs/221629
<ubotu> New bug: #204854 in vte (main) "gnome-terminal / vte doesn't follow gnome font rendering settings (dup-of: 190848)" [Undecided,Confirmed] https://launchpad.net/bugs/204854
<ubotu> New bug: #190848 in xft "font in terminal does not resemble font in preview" [Undecided,New] https://launchpad.net/bugs/190848
<ubotu> New bug: #221703 in xorg (main) "Dell Inspiron 8100 comes up in low graphics (800x600)" [Undecided,New] https://launchpad.net/bugs/221703
 * Ng tried out VGA out for the first time yesterday. Wish I'd tried it earlier in the hardy cycle, because it gets a bit confused ;(
<tjaalton> Ng: so you read the X300 review?
<Ng> bryce: what kind of results did you get testing with the projector we forced you to smuggle? ;)
<Ng> tjaalton: hmm?
<Ng> bryce: I suspect the problems I had were because my LCD is widescreen and those projectors are 4:3
<tjaalton> http://redmonk.com/sogrady/2008/04/22/the-x300-review-part-2-running-ubuntu-hardy/
<Ng> heh, not seen that
<tjaalton> the reviewer didn't test that
<Ng> awsome
<Ng> that review totally saves me from writing up my notes
<Ng> since it links to my thinkwiki notes and alsa bug ;)
<tjaalton> hehe :)
<Ng> does the screen resolution tool allow for extended desktops btw?
<Ng> unticking the clone option didn't seem to make a great deal of difference
<tjaalton> I guess it should
<jcristau> only with a big enough fb?
<Ng> with what? ;)
<Ng> let's pretend I'm a user with a mouse and not someone who's been writing xorg.conf files for a decade :)
<Ng> because I'm really really bored of writing xorg.conf files ;)
<Ng> which reminds me, I need to see if there's a bug filed about xorg not using the system keymap
<tjaalton> yep, extending the desktop doesn't work here either (10x7)
<tjaalton> but maybe compiz has something to do with it
<Ng> hmm
<jcristau> Ng: the framebuffer is allocated at xserver start, and can't be resized yet; so you need to set the size in xorg.conf if you want to be able to extend the desktop
<tjaalton> ah right
<tjaalton> so it's 10x7 by default
<tjaalton> here..
<Ng> jcristau: erk
<Ng> in which case I'd say the clone output tickbox shouldn't be there
<jcristau> (ideally the framebuffer could be resized, and would be per-crtc, so you wouldn't have that issue)
<Ng> yeah, that would be awesome
<tjaalton> WIP
<tjaalton> :)
<tjaalton> isn't that's what shatter is about?
<tjaalton> er, the shatter-branch I mena
<tjaalton> -an
<Ng> also while I'm nitpicking, I thought the resolutions preferences tool wasn't seeing my VGA output, but actually it was underneath the box representing the LCD
<tjaalton> Ng: same here.. shame on me that I didn't try it out before now :)
<ubotu> New bug: #221793 in xorg (main) "Xorg does not follow system keymap" [Undecided,New] https://launchpad.net/bugs/221793
<Ng> tjaalton: yeah, I tried it for the first time yesterday when I was trying to put release bandwidth graphs on a projector in the office ;)
<tjaalton> Ng: that bug needs input-hotplug
<Ng> k
<Ng> hey wait, why?
<tjaalton> for keyboards I mean, and that's still shaky
<Ng> there's a system keymap set
<Ng> inherit that if there's no xorg.conf
<tjaalton> distro specific
<tjaalton> happens to be /etc/default/console-setup on ubuntu
<tjaalton> ..the file that xserver-xorg postinst reads
<Ng> yeah it generated an xorg.conf fine, but there seems to be a growing trend to ditch xorg.conf entirely
<tjaalton> well, too bad for them :)
<Ng> it's totally the future
<Ng> I'd ditch mine if I could set emulatescrollwheel somewhere else
<Ng> xorg could just check for some XKB environment variables and we could source console-setup in gdm's init script
<tjaalton> I don't mind having a 1kb file lying around if everything works :)
<Ng> but I don't see what the problem with it being distro specific is, we patch tons of stuff
<Ng> (xorg included, if the package version is anything to go by)
<tjaalton> it's just hard to do right
<tjaalton> and it's preferred to have something that has "upstream approved" stamp on it
<Ng> of course :)
<ubotu> New bug: #221808 in xorg (main) "[hardy] NVIDIA driver doesn't work after upgrade from 7.10: invalid EDID checksum" [Undecided,New] https://launchpad.net/bugs/221808
<ubotu> New bug: #221494 in linux-restricted-modules-2.6.24 (restricted) "package update-manager 1:0.87.24 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1), E:Sub-process /usr/bin/dpkg returned an error code (1)" [High,Confirmed] https://launchpad.net/bugs/221494
<mvo> tjaalton: what do you think of the above ---^
<tjaalton> mvo: there's another bugreport with fglrx version 8.471-0ubuntu1
<tjaalton> no idea where that's from
<tjaalton> bug 221491
<ubotu> Launchpad bug 221491 in linux-restricted-modules-2.6.24 "package xorg-driver-fglrx 8.471-0ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/221491
<tjaalton> marked as dupe now
<mvo> ok, it might be envy releated (the #221394 one)
<tjaalton> yeah
<ubotu> New bug: #221675 in ubuntu "video playback color wrong (dup-of: 184440)" [Undecided,New] https://launchpad.net/bugs/221675
<james_w> Ng: is 220872 your issue with extended desktops?
<Ng> james_w: quite possibly
<Ng> I'm wondering if the scree nresolution thing can detect that the vfb isn't big enough to extend the desktop and either just refuse to offer it, or explain why
<ubotu> New bug: #221898 in xserver-xorg-video-intel (main) "Virtual desktop larger than real display after X startup" [Undecided,New] https://launchpad.net/bugs/221898
<tjaalton> party on! :)  ->
<ubotu> New bug: #221917 in xorg (main) "parece que el archivo xorg no esta trabajando, aunque en el sinaptic todo ya esta instalado pero sigue el error. " [Undecided,New] https://launchpad.net/bugs/221917
<ubotu> New bug: #221920 in xserver-xorg-video-intel (main) "Compositing results in garbage on the screen for Intel 82815, shouldn't be turn on by default" [Undecided,New] https://launchpad.net/bugs/221920
<ubotu> New bug: #221586 in firefox-3.0 (universe) "Firefox 3 Beta 5 -- Brownout (dup-of: 215728)" [Undecided,Incomplete] https://launchpad.net/bugs/221586
<ubotu> New bug: #221760 in firefox-3.0 (main) "Firefox working on hard disk for 5 Minutes after start. (dup-of: 215728)" [Undecided,New] https://launchpad.net/bugs/221760
<ubotu> New bug: #215974 in firefox (universe) "Firefox image zoom is broken on PPC (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/215974
<ubotu> New bug: #222010 in linux-restricted-modules-2.6.24 (restricted) "cant uninstall" [Undecided,New] https://launchpad.net/bugs/222010
<ubotu> New bug: #222047 in xserver-xorg-input-keyboard (main) "CapsLock LED still lights after change to CTRL key" [Undecided,New] https://launchpad.net/bugs/222047
<ubotu> New bug: #222132 in xorg (main) "Screen corruption" [Undecided,New] https://launchpad.net/bugs/222132
<ubotu> New bug: #222061 in xkeyboard-config (main) "japanese keyboard layout is incorrect" [Undecided,New] https://launchpad.net/bugs/222061
<ubotu> New bug: #222027 in xorg (main) "[nvidia-glx-new] only stripes with NVS140M" [Undecided,Incomplete] https://launchpad.net/bugs/222027
<ubotu> New bug: #222060 in nautilus (main) "Mouse's Back/Forward buttons don't work in nautilus (dup-of: 42678)" [Undecided,New] https://launchpad.net/bugs/222060
<ubotu> New bug: #222164 in xf86-input-evtouch (universe) "evtouch works incorrectly when the screen is left or right rotated" [Undecided,New] https://launchpad.net/bugs/222164
<ubotu> New bug: #211892 in xorg-server (main) "control modifier gets lost in hardy" [Undecided,New] https://launchpad.net/bugs/211892
<ubotu> New bug: #220533 in suspend2-userui (universe) "resum on suspend to ram doesn't work on lenovo R61 (dup-of: 160264)" [Undecided,New] https://launchpad.net/bugs/220533
<ubotu> New bug: #150843 in wacom-tools (main) "Wacom stylus went dead after Gusty" [Undecided,Confirmed] https://launchpad.net/bugs/150843
<ubotu> New bug: #222034 in linux-restricted-modules-2.6.24 (main) "There is a kernel issue with 2.6.24-16-generic. Wireless seems to be broken on a PC with a Linksys WMP54G 2.0 PCI adapter (RaLink RT2500 802.11g )." [Undecided,Confirmed] https://launchpad.net/bugs/222034
#ubuntu-x 2008-04-26
<bryce> erf, up to 1600 bugs
<ubotu> New bug: #222229 in linux-restricted-modules-2.6.24 (restricted) "Firefox causes Kernel bug and crash" [Undecided,New] https://launchpad.net/bugs/222229
<ubotu> New bug: #222205 in xserver-xorg-video-ati (main) "Can't see video output with default ATI drivers in hardy" [Undecided,New] https://launchpad.net/bugs/222205
<ubotu> New bug: #222178 in linux-restricted-modules-2.6.24 (restricted) "Hdmi audio and nvidia" [Undecided,New] https://launchpad.net/bugs/222178
<ubotu> New bug: #222179 in xserver-xorg-video-intel (main) "Computer hard-locks if video overlay is used with compiz" [Undecided,New] https://launchpad.net/bugs/222179
<ubotu> New bug: #215870 in rdesktop (main) "layout switching works ina funny way (dup-of: 196277)" [Undecided,New] https://launchpad.net/bugs/215870
<ubotu> New bug: #152007 in compiz (main) "compiz fusion blur effects cannot be turned on (dup-of: 201264)" [Low,Confirmed] https://launchpad.net/bugs/152007
<ubotu> New bug: #211071 in compiz (main) "Window shadows don't show up; blur doesn't work (dup-of: 186382)" [Undecided,Confirmed] https://launchpad.net/bugs/211071
<ubotu> New bug: #219808 in linux-restricted-modules-2.6.24 (main) "[Hardy] [Compiz] Using "Group and Tab Windows" with more than one group causes hangs/freezes" [Undecided,New] https://launchpad.net/bugs/219808
<ubotu> New bug: #221095 in ubuntu "secondary keyboard layout in gnome is wrong alt gr (dup-of: 196277)" [Undecided,New] https://launchpad.net/bugs/221095
<ubotu> New bug: #222444 in linux-restricted-modules-2.6.24 (restricted) "Login screen has wrong resolution" [Undecided,New] https://launchpad.net/bugs/222444
<ubotu> New bug: #222449 in linux-restricted-modules-2.6.24 (restricted) "Radeon HD3870 / fglrx multiple problems" [Undecided,New] https://launchpad.net/bugs/222449
<ubotu> New bug: #222691 in xserver-xorg-video-ati (main) "Xpress 200, 3d programs unstable" [Undecided,New] https://launchpad.net/bugs/222691
<ubotu> New bug: #222701 in xorg (main) "package xserver-xorg 1:7.3+10ubuntu10 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/222701
<ubotu> New bug: #222407 in ubuntu "Nvidia driver does not work properly in hardy (dup-of: 219639)" [Undecided,New] https://launchpad.net/bugs/222407
<ubotu> New bug: #222213 in linux-restricted-modules-2.6.24 (restricted) "gnome-system-monitor crashes when wifi (fwlanusb) statistics are queried" [Undecided,New] https://launchpad.net/bugs/222213
<ubotu> New bug: #222188 in linux-restricted-modules-2.6.24 (main) "Xorg crashes using firefox" [Undecided,Confirmed] https://launchpad.net/bugs/222188
<ubotu> New bug: #214881 in epiphany-browser (main) "When going to ubuntuguide.org with epiphany the desktop crashes (dup-of: 212648)" [Undecided,Incomplete] https://launchpad.net/bugs/214881
<ubotu> New bug: #85202 in xserver-xorg-input-mouse (main) "cant scroll ore use the side buttons (ms intelli mouse) in kernel 2.6.20-8" [Undecided,Confirmed] https://launchpad.net/bugs/85202
<ubotu> New bug: #222787 in xserver-xorg-video-ati (main) "xserver-xorg-video-ati doesnt work with radeon 8500 in Hardy (either)" [Undecided,New] https://launchpad.net/bugs/222787
<ubotu> New bug: #222724 in nvidia-settings (universe) "login screen resets nvidia color settings" [Undecided,New] https://launchpad.net/bugs/222724
#ubuntu-x 2008-04-27
<ubotu> New bug: #222861 in linux-restricted-modules-2.6.24 (restricted) "GDM won't load, or maybe X? With fglrx on radeon 9700 mobile. Ubuntu 8.04" [Undecided,New] https://launchpad.net/bugs/222861
<ubotu> New bug: #222865 in linux-restricted-modules-2.6.24 (restricted) "Atheros 5413 Troubles" [Undecided,New] https://launchpad.net/bugs/222865
<ubotu> New bug: #222873 in xorg (main) "OQO Model 02 Default Xorg Configuration Issue" [Medium,Confirmed] https://launchpad.net/bugs/222873
<ubotu> New bug: #222879 in linux-restricted-modules-2.6.24 (restricted) "Compiz breaks Resume from Suspend on Thinkpad using FN-F4" [Undecided,New] https://launchpad.net/bugs/222879
<ubotu> New bug: #222924 in xorg (main) "X crashes suddenly" [Undecided,New] https://launchpad.net/bugs/222924
<ubotu> New bug: #188660 in xorg (main) "live CD loops between login and desktop on ATI Xpress cards" [Undecided,Confirmed] https://launchpad.net/bugs/188660
<ubotu> New bug: #57153 in xorg-server (main) "xorg-server 1:1.0.2-0ubuntu10.3 breaks X: "no screens found"" [Critical,Fix released] https://launchpad.net/bugs/57153
<ubotu> New bug: #222939 in linux-restricted-modules-2.6.24 (restricted) "Driver nVidia GeForce 8400M GS (rev a1) Fails in Hardy" [Undecided,Incomplete] https://launchpad.net/bugs/222939
<ubotu> New bug: #223013 in xorg (main) "[hardy kde4] erratic trackpad behaviour after upgrade from gutsy" [Undecided,New] https://launchpad.net/bugs/223013
<ubotu> New bug: #222854 in linux-restricted-modules-2.6.24 (restricted) "nVidia driver from repo renders ubuntu unusable" [Undecided,New] https://launchpad.net/bugs/222854
<ubotu> New bug: #222270 in linux-restricted-modules-2.6.24 (restricted) "[Hardy 8.04] nvidia-glx-new adept error amd64" [Undecided,New] https://launchpad.net/bugs/222270
<ubotu> New bug: #222163 in linux-restricted-modules-2.6.24 (restricted) "Xorg crashes when using two monitors set up by aticonfig (BigDesktop mode)" [Undecided,Incomplete] https://launchpad.net/bugs/222163
<ubotu> New bug: #222739 in xterm (main) "xterm segfaults after a while." [Undecided,New] https://launchpad.net/bugs/222739
<ubotu> New bug: #219604 in linux-restricted-modules-2.6.24 (restricted) "[Hardy] april 14 daily-live  nvidia-glx-new failure" [Undecided,Incomplete] https://launchpad.net/bugs/219604
<ubotu> New bug: #219799 in ubuntu "X restarts when I visit ubuntuguide.org (dup-of: 222188)" [Undecided,New] https://launchpad.net/bugs/219799
<ubotu> New bug: #223050 in xserver-xorg-input-elographics (universe) "Calibration whith new elographics driver" [Undecided,New] https://launchpad.net/bugs/223050
<alex-weej> if anyone with knowledge of mouse/trackpad scrolling could have a look at https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/223170 it'd be mucho appreciated
<ubotu> Launchpad bug 223170 in gtk+2.0 "Trackpad scrolling is jerky and difficult to be precise with" [Undecided,New] 
<alex-weej> :x
<ubotu> New bug: #223170 in xserver-xorg-input-synaptics (main) "Trackpad scrolling is jerky and difficult to be precise with" [Undecided,New] https://launchpad.net/bugs/223170
<bryce> tjaalton: any ideas on 196277?  I wonder if dexconf had some workarounds for this issue, that were dropped during the dexconf cleanup
<ubotu> New bug: #223212 in linux-restricted-modules-2.6.24 (restricted) "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212
<tormod> Hi, where is compiz started and/or blacklisted?
<ubotu> New bug: #222516 in xorg (main) "gnome-display-properties shows wrong refresh rate" [Low,Incomplete] https://launchpad.net/bugs/222516
<ubotu> New bug: #223242 in xorg (main) "X server crashes when browsing a certain website" [Undecided,New] https://launchpad.net/bugs/223242
<ubotu> New bug: #223266 in linux-restricted-modules-2.6.24 (restricted) "package xorg-driver-fglrx 8.471-0ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/223266
<jcristau> bryce: how is that bug dexconf-related?
<tjaalton> bryce: right, dexconf isn't related, this seems more like a gnome/xserver problem to me
<alex_mayorga> hi, is this the right place to troubleshot an X problem?
<alex_mayorga> bug 146706
<ubotu> Launchpad bug 146706 in xserver-xorg-video-nv "[Hardy] Live cd graphics fail with nvidia geforce4 440 go " [High,Triaged] https://launchpad.net/bugs/146706
<alex_mayorga> bryce: ping
<ubotu> New bug: #223278 in xorg (main) "Keeping mighty mouse buttons pressed results in repeated ButtonPress events [regression]" [Undecided,New] https://launchpad.net/bugs/223278
<ubotu> New bug: #223284 in libxrandr (main) "xrandr (and displayconfig-gtk) deeply confused about analog monitor connected to dvi port via adapter" [Undecided,New] https://launchpad.net/bugs/223284
<ubotu> New bug: #223272 in xorg (main) "X does not start with 4GB of RAM" [Undecided,New] https://launchpad.net/bugs/223272
<ubotu> New bug: #223302 in linux-restricted-modules-2.6.24 (restricted) "fglrx kernel source control and makefile bugs" [Undecided,New] https://launchpad.net/bugs/223302
<bryce> tjaalton, jcristau: just wondering since comment #3 said the issue went away after tweaking the xorg.conf
<jcristau> i must admit i don't understand most of the comments on that bug
<alex_mayorga> anyone interested on smashing bug 146706
<ubotu> Launchpad bug 146706 in xserver-xorg-video-nv "[Hardy] Live cd graphics fail with nvidia geforce4 440 go " [High,Triaged] https://launchpad.net/bugs/146706
<bryce> https://bugs.freedesktop.org/show_bug.cgi?id=4927#c4 seems to be the best lead so far on the issue, however I don't know what is implied as far as fixing it goes
<ubotu> Freedesktop bug 4927 in Input/Keyboard "XKM files do not keep the information regarding the explicit vmodmap mask" [Major,Reopened] 
<jcristau> bryce: so the fix is "don't use grp:alts_toggle for now"?
<jcristau> alex_mayorga: meh. Xorg.0.log.old  (53.1 KiB, application/x-trash). is there a way to change it to text/plain?
<jcristau> alex_mayorga: your log shows the vesa driver being used, not nv
<alex_mayorga> jcristau, I'm all ears, please help me help you close that bugger
<alex_mayorga> it currently fails and says "screen init failed"
<alex_mayorga> I'm a real newbie on this, so please bear with me
<jcristau> first this is someone else's bug, so unless you're really really sure it's the same problem as originally reported you should assume it isn't
<alex_mayorga> is the same card
<jcristau> no it isn't. yours is 10DE0174, the first one is 10DE0179.
<alex_mayorga> oh! sorry
<jcristau> then you can look for something similar reported against your driver at bugs.freedesktop.org
<jcristau> if it's not reported there, there's a good chance it won't get fixed
<jcristau> so reporting it upstream is a good first step :)
<alex_mayorga> any tips/guide to get a usable desktop in the mean time?
<jcristau> vesa doesn't work?
<alex_mayorga> i no longer get a prompt to select vesa when dpkg-reconigur
<jcristau> $EDITOR /etc/X11/xorg.conf, add Driver "vesa" in the Device section
<alex_mayorga> done
<alex_mayorga> then?
<jcristau> then startx?
<alex_mayorga> fatal server error:no screems found
<alex_mayorga> EE screens found bun none have a usable configuration
<alex_mayorga> jcristau, I've got this laptop with a severed display, I have it hooked to this monitos http://www.amazon.com/Samsung-LNT2653H-26-inch-LCD-HDTV
#ubuntu-x 2009-04-20
<bhuey> pwnguin: just one of the monitors ? not both
<bhuey> if that's the case, I might move to that driver
<bhuey> I like the proprietary driver though because of GLX
<pwnguin> bhuey: im fairly certain ive rotated my tablet and the vga output remained the same
<pwnguin> you might be able to do that with nvidia
<bhuey> do you have instructions or is it pretty much something that you play with when you install the drivers and run the screen configuration utilities ?
<bhuey> I was able to do that to the entire scene, but not the individual monitor
<bhuey> and a Google search yielded nothing informative regarding this
<pwnguin> what you need to do is read the very long and boring nvidia manual in /usr/share/doc/nvidia-glx with an eye towards xrand
<pwnguin> r
<bhuey> hmmm, ok
<bhuey> there's no info on rotating just the screen but the entire view itself
<pwnguin> bhuey: well you could always try out raof's stuff and see if you like it
<bhuey> pwnguin: does he hang out here ?
<pwnguin> raof? yes
<RAOF> Man, it takes a long time to build an ubuntu kernel.
<pwnguin> technically, nouveau is experimental
<pwnguin> so if it fails for you, don't get super angry or expect anything
<RAOF> Also, if you've got a geforce 8 or 9 card, use a compositing manager, or a bunch of stuff won't work.
<superm1> RAOF, are you building with debuild -b, or did you follow the simplified steps?
<superm1> the normal debian packaging will build a ton of variants you probably wont care about
<RAOF> VARIOUS_ENVIRONENT_VARIABLES fakeroot debian/rules binary-mmiotrace
<RAOF> IE: I'm just building the flavour I'm interested in.
<superm1> okay good
<RAOF> There just happens to be one metric buttload of modules to build.
<RAOF> I'll probably farm it out to a PPA once I'm reasonably sure it works; having an MMIO trace capable kernel would be useful for a number of people.
<superm1> i'm not familiar with MMIO trace, what is that?
<pwnguin> its a reverse engineering tool
<pwnguin> for charting memory mapped I/O
<RAOF> "Kindly log every memory-mapped IO operation performed by this kernel module, so I can see what it does"
<superm1> Ah, i see
<pwnguin> i think you can guess which module this might be applied to
<RAOF> fglrx :P
<superm1> perhaps it starts with n and rhymes with cydia
<bhuey> pwnguin: i'll wait for him to come on sometime and ask him how to go about doing this
<RAOF> bhuey: You mean raof? :)
<superm1> is there a performance hit in operating such a kernel (by the overhead of logging all that data)?
<bhuey> btw, I love that you folks have done all of this work for Ubuntu
<bhuey> RAOF: same character ?
<bhuey> ok, I can see lower case like I use to :)
<RAOF> superm1: There's a huge performance hit when you're actually tracing; X startup takes in the order of minutes.
<bhuey> RAOF: yeah, I'd appreciate some pointers as to how to rotate just one of my screen so that I can use it in portrait mode of sorts.
<superm1> RAOF, but the tracing can be enabled and disabled on demand?
<RAOF> superm1: And apparently even when it's not active there's a couple of MB overhead per CPU.
<bhuey> I can rotate the entire virtual view but not just one monitor. I'd like to know how to rotate just one monitor
<RAOF> Yeah.  Tracing can be enabled & disabled at will.
<bhuey> if it is possible
<RAOF> bhuey: With nouveau?
<bhuey> RAOF: any driver
<bhuey> I'm using nvidia right now
<superm1> but with that overhead on a per cpu basis, definitely not a good idea to have available on a production kernel
<bhuey> until nouveau gets full glx support, it's not a viable option for me
<RAOF> superm1: Right.  Otherwise I'd just be asking the kernel team to enable it.
<superm1> RAOF, well if it aides upstream development significantly, you can possibly ask the kernel team to set up a PPA that spits out kernels with it enabled like the mainline builds do for upstream kernel releases
<RAOF> Possibly.  Or I can just do what I'm doing, and shove a -mmiotrace flavour in my nouveau PPA.
<RAOF> If that turns out to be too hard, I'll ask the kernel team.
<superm1> right
<bhuey> RAOF: do any of the drivers to that ?
<RAOF> bhuey: Oh, sorry.
<RAOF> bhuey: Yes.  Any driver that supports XRandR 1.2 will do that.
<bhuey> yeah, but for just one screen
<RAOF> The nvidia driver *doesn't*, and I'm not sure if you can.
<bhuey> I've got a dual screen setu
<bhuey> setup
<RAOF> The nvidia driver doesn't support XRandR 1.2.
<bhuey> I can rotate it, but only the entire image
<RAOF> If you can't do it in nvidia-settings, you can't do it.
<bhuey> ok, that supports multiple screens then right ?
<bhuey> ok
<bhuey> but noveau does this ? what about glx support ?
<RAOF> Nouveau does this.  There's no 3d support, however.
<bhuey> nouveau
<bhuey> hmmm
<bhuey> I'll have to suffer with the nvidia driver then
<RAOF> (That's not entirely accurate: there's 3d support ranging from "can play OpenArena flawlessly" to "glxgears causes kernel panic".  The drivers switch from one state to another on a semi-regular basis)
<bhuey> glx support is critical
<bhuey> how's progress with that ? do you know ?
<RAOF> Slow.
<pwnguin> a quick note, bhuey's video card: 6600gt =)
<bhuey> yeah, it's hard stuff
<bhuey> pwnguin: thanks :)
<bhuey> I really appreciate this help btw
<RAOF> pwnguin: Yeah, I remembered.  I think the *current* state of glx on his card is "glxgears will show artefacts the first time you run it, will kill X the second".
<bhuey> great
<pwnguin> bhuey: it seems like you have a choice mainly, between "smooth 3d graphics" and "rotates individual screens"
<bhuey> the nvidia driver wins
<pwnguin> then i guess we
<pwnguin> then i guess we're done here
<bhuey> ok
<bhuey> until the next release :)
<bhuey> thanks
 * RAOF wouldn't expect supported 3d with nouveau in Karmic, either.
<RAOF> Although I would hope it to be the default driver for nvidia cards.
<RAOF> Well, I hope the PPAs don't mind building the kernel.  I wonder how many hours it'll take.
<superm1> RAOF, i know when rtg and those guys push to ppas, they have a way to make sure the ppa won't build all the flavours too, so unless you fully hacked up debian/control to only have your tracable flavour, you might want to check about that
<RAOF> Whoops.  I think that'll build all the flavours.
<RAOF> Oh, well.  I now know how to make it _not_ build all the flavours.  Next upload won't build everytihng :/
 * RAOF plays "upload another 90Mb of kernel source to the ppa, this time it'll definitely build only -mmiotrace"
<superm1> well at least you got it fixed now rather than 10 hours from now :)
<Mirv> RAOF: if Fedora is getting nouveau as default in 11, I'd guess Karmic could as well have nouveau as default... it even supports more cards than nv
<Mirv> it'd be great, though, I like the message that it's delivering to NVIDIA
<tjaalton> I'm pretty sure it will be chosen as default..
<pwnguin> Mirv: i doubt it'll really make an impact on usage numbers
<pwnguin> glx is basically vital
<bryce_> o/
<bryce_> I registered a UDS session to discuss defaulting to -nouveau
<ttx> bryce: do you still need more testing/reproduction data points on bug 359392 ?
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] https://launchpad.net/bugs/359392
<bryce_> ttx: couldn't hurt to have your intel_gpu_dump output for reference
<bryce_> ttx: assuming your symptoms, hw, etc. are a match with that bug.  If not, you should collect that info, but report as a separate bug report
<ttx> bryce_: ok, will make my best reproducing it. I'm like seb128, I wasn't ever bitten by it.
 * bryce_ --> bed
<bryce_> night
<pwnguin> bryce: i doubt I'll be in attendence, but i fully support the idea
<jbarnes> bryce, mdz: just to confirm, are you still getting interrupts when the freeze happens?  and does the "current sequence" increment in i915_gem_interrupt?
<bryce> jbarnes: lemme check, I got another freeze yesterday
<jbarnes> bryce: thanks
<bryce> oh... you mean while the system is frozen?  I'll have to re-freeze it first.  Will get back to you
<jbarnes> yeah while frozen
<bryce> get some good ideas on fixes over the weekend?
<jbarnes> unfortunately no :(
<jbarnes> given the gpu dumps you guys gave me I was hoping it was a render accel problem
<jbarnes> but at least some reporters tried that and still saw hangs
<jbarnes> of course that doesn't mean render accel isn't broken, just that it can't be the whole fix
<bryce> jbarnes: hm bummer, I was hoping the new tools would make these bugs completely transparent.  But I guess it's like having a backtrace - it helps capture the state but not what caused it to get into that state
<jbarnes> yeah for certain kinds of hangs they can really help
<jbarnes> for others they just give us a few more clues and things to eliminate
<jbarnes> the last hang info you posted actually seemed ok... I asked anholt to confirm
<jbarnes> (ok as in we're not failing to track sequence numbers it looks like)
<bryce> jbarnes: that was my "classic" hang that occurs after several hours use, as opposed to the freeze that occurs from mdz's script
<bryce> heya apw
<jbarnes> bryce: also, if the kernel you're running also has my i915 error interrupt patch you could check dmesg when the hang happens
 * cwillu 's been away for a little while
<cwillu> should stock jaunty still have lingering hangs?
<bryce> cwillu: yeah
<Caesar> tjaalton: you around?
#ubuntu-x 2009-04-21
<bryce> jbarnes: "current sequence" does not seem to be incrementnig
<jbarnes> bryce: ok just wanted to make extra sure the gpu was hung
<jbarnes> albert23's last dump shows that we started executing junk
<bryce> I've waited a couple hours since the freeze, and no files in /sys/kernel/debug/dri/0 have changed
<pwnguin> bryce_: what's the purpose exactly, of adding lspci entries to the bug descrption?
<bryce_> pwnguin: needed for upstreaming the bug
<tjaalton> Caesar: yes?
<Caesar> tjaalton: libxcb
<Caesar> We're seeing problems with it in Hardy
<Caesar> On amd64
<Caesar> Both the 64-bit version and what's in ia32-libs
<Caesar> Apparently the problems went away when I rebuilt the ia32-libs version without optimisation
<Caesar> Make of that what you will
<Caesar> I haven't tried making a non-optimised 64-bit version yet to see if that solves the other problems
<Caesar> I was wondering if you had any thoughts on the whole situation? There's been one or two libxcb-related bugs bouncing around I think
<tjaalton> Caesar: which ones?
<tjaalton> and what problems?
<Caesar> tjaalton: various crashes
<Caesar> I'm not VPNed into work at the moment, so I can't check our bug tracking system
<tjaalton> ok, are they on lp too?
<tjaalton> I'd be interested to know if they happen on jaunty too
<tjaalton> since we're going to be fully 64bit in a few months ;)
<tjaalton> I know that there used to be some java issues
<tjaalton> but java was fixed since
<tjaalton> and so was libxcb, so that it can't fail the same way anymore
<Caesar> java was one of the problematic things
<Caesar> Let me see which lp bugs we're subscribed to
<Caesar> So there's #220628
<Caesar> and #232364 is less pressing
<Caesar> I'd have to doublecheck what we've got internally tomorrow
<tjaalton> sure
<tjaalton> so there's a patch for the former.. have you tried backporting it?
<Caesar> Not yet
<Caesar> I've still been trying to wrap my head around all of the issues
<tjaalton> think I've seen this bug myself, good to know there's a fix :)
<Caesar> Actually, let me search my email, that should turn up something useful
<tjaalton> I'll be moving the next week or so, which means I'm unable to work on it before early May perhaps, but I'll keep an eye on it because it seems important
<Caesar> Yeah, it seems to be fairly important
<Caesar> I think we did a backport of that patch for a single user to see how it worked out for them
<Caesar> Firefox still seemed to crash, just less
<tjaalton> I'll assign myself to the bug
<Caesar> I had someone look at some other crashes, and he said:
<Caesar> I can't see how $EBX is meant to be maintained.  The generated code looks optimised (non static functions have been inlined).  This feels like an optimization bug.
<Caesar> (that was for the ia32-libs version)
<Caesar> So I went and rebuilt it without optimisation
<Caesar> and that seemed to fix the problem
<Caesar> So something's very wrong if just changing the optimisation level fixes the problem
<tjaalton> that was some other bug?
<Caesar> Yeah
<Caesar> It's very internal, so it's hard to file a meaningful lp bug
<tjaalton> heh, ok
<tjaalton> could that be a compiler bug?
<Caesar> I guess it could be
<tjaalton> talk to doko about it
<tjaalton> he might have ideas
<Caesar> ok
<Le-Chuck_ITA> Hi there, I have Xorg crashing on "first reboot" after installing jaunty. It worked for months, but the latest version of X works only on first boot, that's very strange. Perhaps related to kernel. It's bug #364488
<ubottu> Launchpad bug 364488 in ubuntu "After some day of installation, Xorg won't start anymore (black screen and locked keyboard)" [Undecided,New] https://launchpad.net/bugs/364488
<mnemo> tjaalton: i switched the package to xorg on this bug (not wacom) --> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/364488
<ubottu> Launchpad bug 364488 in xorg "After some day of installation, Xorg won't start anymore (black screen and locked keyboard)" [Undecided,New]
<mnemo> tjaalton: or why did you set wacom-tools on it?
<tjaalton> mnemo: because it's likely a dupe of another bug (can't find it now)
<mnemo> aaah ok
<mnemo> does wacom-tools request xorg.log etc just like xorg does when you run the apport-collect thing?
<tjaalton> not necessarily a wacom bug, could be in the xserver
<tjaalton> yes
<mnemo> ok would you like me to change it back to wacom-tools then?
<tjaalton> yes
<mnemo> will do
<tjaalton> thanks
<mnemo> tjaalton: btw, I have wacom HW
<tjaalton> mnemo: ok, you could check bug 358643 and see if you can reproduce the issues
<ubottu> Launchpad bug 358643 in wacom-tools "Xorg crashed with SIGSEGV in DeleteInputDeviceRequest()" [Medium,Confirmed] https://launchpad.net/bugs/358643
<mnemo> sure
<tjaalton> there are also proposed fixes, and I've yet to grok the reply from gomyhr
<mnemo> its my gf's wacom actually so I never tried it in ubuntu before.... anyway now when I connected it, things just worked out of the box...
<mnemo> like I got this in dmesg --> http://pastebin.com/m1124224
<mnemo> and I can move around the mouse cursor at least
<mnemo> no special xorg.conf
<tjaalton> right, it works if you _don't_ have anything in the conffile
<tjaalton> but I'm worried about the people upgrading :)
<tjaalton> it'll be mentioned on the release notes though
<tjaalton> but an SRU would be nice
<mnemo> right..
<tjaalton> anyway, lunch ->
<mnemo> yea
<mnemo> cya
<tjaalton> tseliot: have you had time to prepare the new stable nvidia for testing?
<tseliot> tjaalton: I prepared and I'm using 180.51 but I think it's still a prerelease
<tseliot> http://www.nvnews.net/vbulletin/showthread.php?t=122606
<tseliot> Current official release: 180.44 (x86 / x86_64)
<tseliot> Current prerelease: 180.51
<tseliot> Current beta release: 185.19
<tjaalton> ah
<tjaalton> ok
<tseliot> no regressions so far
<tseliot> we might do an SRU when the stable version is released
<tjaalton> right
<tjaalton> I should probably test the gf9600gt's a bit more
<tjaalton> we'll be getting a 100 of those :/
<tseliot> unfortunately I don't own one
<apw> jbarnes, hi ... trying to get a handle on the tiling performance issues associated with MCHBAR, and wondering what happened with the patch 'allocate MCHBAR space & enable if necessary', i think i remember there being a replacement proposed  but cannot find it
<Ng> hmm, x hung
<Ng> i shouldnt have hacked out the blacklist ;)
<Ng> is there anything i can quickly do to get debugging before i have to reboot?
<Ng> i have a quick gdb bt
<tjaalton> Ng: do you have all the bits (2.6.30 + patched i915.ko, the reg-dumper=
<Ng> no, stock jaunty
<tjaalton> ok
<Ng> gah. i have to reboot npw
<Ng> so obviously I'm behind on all the debugging/testing things I should be doing
<soren> An acquaintance of mine just ran update-manager to do the intrepid->jaunty upgrade and it told him that there wasn't an fglrx driver for his card. It's an x1400. Is that accurate?
<soren> If it is, he'll be moved to the free driver, right? I'm told they don't support 3D acceleration.
<soren> If that's indeed the case, the upgrade will mean he'll lose 3D capabilities. However, I don't see any mention of anything like this in the release notes?
<mvo> soren: what is the pci id of this card (the x1400) ?
<soren> mvo: I'll check.
<mvo> soren: I doN't think he will loose 3d acceleration, but it may be less well supported, iirc the x1400 is a r500 based card and the 3d support for the free driver is pretty solid there
<mvo> (compiz should run just fine, not sure about more advanced stuff like real games)
<soren> mvo: 1002:7145
<mvo> soren: from the modaliases it looks like this is indeed just r600+ support now
<soren> fglrx, you mean?
<soren> So he'll be automatically switched to the free driver? That's the one called "radeon", is it?
<mvo> soren: yes - and http://www.x.org/wiki/RadeonFeature looks pretty good for the r500
<soren> mvo: Fantastic. Thank you.
<mvo> soren: let me know how the upgrade goes and if everything works as expected please
<soren> mvo: Still... I understand why he was startled by that message. Losing 3D would be a showstopper for lots of people, I think.
<soren> mvo: Will do.
<Ng> are we could to put in such a message for i965?
<mvo> soren: right. I understand. I'm not familiar enough with the free ati driver to judge how well the individual chips are supported, so I decided to go with the "conservative" message
<mvo> Ng: only in a sru at this point
<tjaalton> soren: the r5xx series has free 3D support
<tjaalton> since intrepid
<soren> tjaalton: Cool.
<soren> I'm just passing the message on... He was rather concerned by the message, and the release notes don't mention anything about this.
<Ng> mvo: fair enough
<jcristau> and r6/7xx will probably get it for the next release
<soren> Perhaps it's worth mentioning the transition in the release notes.
<soren> mvo: He's doing the upgrade later today and promised he'd get back to me with the results. I'll keep you posted :)
<mvo> jcristau, tjaalton: is it "good enough" to not show a warning at all for all r5xx chips?
<tjaalton> mvo: where's the full text?
<mvo> http://paste.ubuntu.com/155350/
<tjaalton> I guess it could only worry people
<tjaalton> although the text is technically correct :)
<Shappie__> Hello, is there a way to disable the RandR extension of Xorg?
<Shappie__> It conflicts with my fglrx driver from ATi (9.4)
<Mirv> mvo: for basic desktop (3D) usage it should be enough, and largely at least there is zero reduction in desktop effects. games do suffer until radeon-rewrite comes for karmic.
<Mirv> I've played stuff like Neverwinter Nights on my (former) Radeon X800 without problems, but things like Doom 3 do not work (yet)
<mvo> Mirv: thanks! that is valauble information, so the warning is probably a good idea
<Mirv> mvo: warning, or just a release note about decreased game performance on R500
<jcristau> Shappie__: that doesn't make sense
<Mirv> of course, there might indeed be a bunch of gamers using something like X1650-X1950, for them it's an important piece of information
<Shappie__> jcristau: What you mean? When i type in terminal the command with sudo aticonfig to make dualscreen setup its says error due to RandR 1.2 enabled
<Shappie__> You need the exact error? I have it somewhere...
<Mirv> but if using the warning message, just remove the "desktop effects, and "
<jcristau> Shappie__: shrug.  i don't know what aticonfig is, so i probably couldn't help with it anyway.
<jbarnes> apw: it's under "pnp: add PNP resource range checking function" on intel-gfx
<jbarnes> apw: I split it in two because the pnp part needed to be generic
<apw> jbarnes, ahh thanks will look at it
<apw> jbarnes, i see that bjorn came back with an alternative generic check, did that get tested yet?
<jbarnes> apw: no, do you have a test platform you could try it with?
<jbarnes> you'd need to add an EXPORT_SYMBOL for it and a prototype
<apw> i have users who are upset its not working
<jbarnes> should be easy to do though
<apw> so i suspect they would be willing to test anything, as their performance sucks without your fix
<jbarnes> would be great to get some test results so we could push it upstream soon
<bryce> morning
<jbarnes> morning
<jbarnes> bryce: did you see my last update to imad?
<jbarnes> my mailer is giving me trouble, just want to make sure it went out
<jbarnes> was in reply to mdz's comment
<bryce> jbarnes: no emails from you for today in my inbox
<jbarnes> just sent again...
<bryce> jbarnes: anything else I could do to help you guys?
<jbarnes> not atm I think
<jbarnes> looking at albert's dumps now
<bryce> tjaalton: I've updated https://wiki.ubuntu.com/X/Drivers to indicate the latest info for our main drivers, can you please review it when you get a chance, and add any other information that's worth including?
<tormod> bryce: ^ beta version of xserver?
<tjaalton> bryce: the -intel entry has a wrong version
<bryce> good catches... updated
<tjaalton> bryce: I'm a bit lost about wacom actually, there are some bugs suggesting that xsetwacom/wacomcpl doesn't work, but actually they do if the correct device name is used
<tjaalton> but I've yet to confirm that
<bryce> ok
<bryce> tjaalton: don't forget to update the release notes if this is a known issue, esp. if there's a workaround people can use
<jbarnes> bryce: I thought the sony panel problem was fixed?
<bryce> jbarnes: might be, this known issue list is old (2.6.1-ish)
<jbarnes> at least the linked bug is fixed :)
 * jbarnes checks the commit id
<tjaalton> bryce: I will take the crappy oem tablet with me tomorrow, so I can play with the patches
<tjaalton> and update relnotes accordingly
<jbarnes> bryce: yeah 2.6.3 has the sony panel fix so you can remove that bit
<bryce> okies
<bryce> tjaalton: awesome thanks
<jbarnes> bryce: also, tv out properties and the sdvo tv stuff should be pretty easy to backport, you could ping yingying about getting that done maybe
<tormod> bryce: re wiki: the link to fd.o 19274 is wrong
<bryce> jbarnes: is that strictly -intel stuff or does it require kernel changes?
<jbarnes> for non-kms they're just 2d driver updates
<bryce> tormod: ok thanks, what should it be linked to?
 * bryce hmms @ sru-ability of tv stuff
<jbarnes> don't know how much user demand you have for it
<jbarnes> anyway just a thought since upstream has those bits
<bryce> yeah
<bryce> we've got one TV out properties related bug, but it's medium priority
<bryce> looks like we don't have a lot of user demand for it; guess we'll just snag it for karmic when we merge
<tormod> bryce: I googled for "frontbuffer rendering broken" and found 19174 :)
<tormod> I will fix it in the wiki
<bryce> yikes
<bryce> thanks
<tormod> bryce: you had a lock on the page, any pending changes in your browser?
<bryce> none
<tormod> saved
<RichardWolfVI> hey I'm on Jaunty and playing video crashes X on most cases
<tormod> on intel, of anyone wondered
<tormod> s/of/if
<tormod> do you have specified a Virtual size?
<RichardWolfVI> tormod: I don't know about that.
<tormod> your xorg.conf is the default one?
<tormod> well actually the Display Preferences GUI will rewrite it if you play with dual screen
<RichardWolfVI> Well, I'm using a single one
<RichardWolfVI> http://paste.ubuntu.com/155570/ my xorg.conf
<tormod> hmm how come you have that "greedy" in there if you never touched it?
<RichardWolfVI> I didnÂ¿t said I never touched it
<RichardWolfVI> *didn't
<RichardWolfVI> I just added that line in hopes the graphics performance increased
<RichardWolfVI> at least compiz isn't hanging now
<JanC> is there a reason why Ubuntu patches Xorg to allow only 20 input-devices instead of the default 128?
<bdmurray> bryce: is there somewhere compiz isn't running anymore on my intel card bugs should go?
<jbarnes> bdmurray: it's currently disabled
<jbarnes> due to 359392
<bdmurray> jbarnes: right, I realize that I was wondering if there was some master bug they should be made a duplicate of
<jbarnes> ubottu: that's bug 359392 btw
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] https://launchpad.net/bugs/359392
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jbarnes> bdmurray: maybe that one
<bryce> ah, let's not dupe to that one; it's long enough as is, and we still need it for working on
 * bryce looks for better one to dupe to
<bryce> yikes, >300 bugs on intel
<bryce> bdmurray: 363821 looks suitable to dupe against
<bryce> I'll update that one
<jbarnes> bryce: yeah don't remind me
<jbarnes> bryce: we've got >300 open at fdo also
<jbarnes> and I seriously doubt all the ubuntu ones have fdo analogs :/
<bryce> likely not
<JanC> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/364895 --> feature request for karmic  ã
<ubottu> Launchpad bug 364895 in xorg-server "MAXDEVICES too low for some purposes" [Undecided,New]
#ubuntu-x 2009-04-22
<paran> The patch for bug 345397 in evdev 1:2.1.1-1ubuntu4 causes a bad regression for me, key repeat is disabled for certain arrow keys.
<ubottu> Launchpad bug 345397 in xserver-xorg-input-evdev "[patch] Fix ability to modify keyboard repeat rate" [High,Fix released] https://launchpad.net/bugs/345397
<paran> A commend warned that this regression had been observed with this patch on Intrepid. I made a comment there, should I also report the regression as a new bug?
<bryce> paran, yep
<paran> bryce: ok, will do that tomorrow then.
<JanC> bryce: does Ubuntu support multiseat systems?  ã
<crdlb> several people in +1 have said that their xorg.conf files are blank today
<crdlb> is this intentional?
<JanC> crdlb: Xorg files are supposed to be (almost) blank since intrepid
<crdlb> sure, the skeleton is great
<crdlb> but I got the impression it was _completely_ blank
<JanC> well, that shouldn't really matter AFAIK
<crdlb> it matters a lot :)
<JanC> how?
<crdlb> because it makes trivial additions non-trivial
<JanC> most people shouldn't make "trivial additions"
<crdlb> eg changing the AccelMethod or enabling AccelDFS
<crdlb> there's no reason not to include the skeleton
<JanC> and it's easy enough to recreate a skeleton xorg.conf if you really need it
<crdlb> it's a pointless extra step
<crdlb> the skeleton doesn't break any of the autoconfig
<JanC> not really, as for most people it's a pointless step to parse xorg.conf  ;)
<crdlb> huh?
<JanC> why parse a skeleton xorg.conf?
<crdlb> who is the implied subject in that sentence? X?
<JanC> X
<JanC> most people don't even know xorg.conf exists
<crdlb> and they can stay ignorant even if it does exist
<JanC> and AFAIK configuration tools will create it if needed
<crdlb> there are no configuration tools to add Option "AccelDFS" (and there shouldn't be)
<crdlb> but that doesn't mean you should be wasting my time by not including the skeleton
<JanC> if there is no reason for configuration tools to set that option, there is no need for that option
<JanC> except for debugging maybe
<JanC> and it's not me that decides  ;)
<crdlb> the option makes EXA usable on my GPU, but it cannot be enabled by default due to buggy hardware that I don't have
<JanC> right, so the blacklisting should be refined
<crdlb> ...
<crdlb> you have yet to suggest a reason not to include the skeleton
<JanC> ... or to include it
<JanC> I don't really care, except maybe parsing it takes time but is useless for most people
<crdlb> parsing it is negligable
<JanC> well, I still have it, so duno  :P
<JanC> worst case you have to recreate it once
<crdlb> yes, which multiplies by every single user I have to tell it to
<JanC> dpkg-reconfigure will take care of that I suppose
<crdlb> it does, indeed
<JanC> crdlb: the users you should tell that to should be a tiny minority, otherwise this should be configured automaticly (and if not, it's a bug)
<crdlb> this is the real world :)
<JanC> well, help work on getting it fixed in the next version then (although I haven't heard anybody who really needed that option to get a working system, maybe that depends on what you want to do)
<crdlb> I just fundamentally don't see the logic in not including an xorg.conf
<crdlb> I foolishly assumed it was a bug ...
<JanC> and by help I mean: report bugs & help testing & help nagging when it's still possible to change things ;)
<JanC> the ultimate goal is to get rid of xorg.conf, so everything that still needs it is a bug  ;)
<crdlb> no, the ultimate goal is to not need the xorg.conf for anything
<crdlb> which is perfectly served by installing a static xorg.conf with the distro
<JanC> if you don't need it, then it's useless to install it
<crdlb> it does not follow that you should delete it, though
<JanC> maybe an empty file with only a comment about running dpkg-reconfigure would be useful for now
<JanC> for those people who don't read upgrade notes etc.  ;)
<crdlb> the skeleton is 11 lines :)
<JanC> well, I don't think anything is gonna change before tomorrow  ;)
<crdlb> of course :)
<crdlb> stop the release!!!
<JanC> there are much more serious issues than this  :-(
<crdlb> intel
<JanC> right, as well as AMD/ATI AFAIK   :p
<JanC> well, maybe less than intel
<crdlb> the radeon driver is quite nice this cycle :)
<JanC> duno, I have only intel (3x)
 * crdlb has no intel
<JanC> anyway, I'm gonna sleep, 6:15 am here  ;)
<crdlb> skip it ;>
<mnemo> "Intel Linux Driver Kills The Netbook Experience"
<mnemo> http://www.phoronix.com/scan.php?page=news_item&px=NzIyMA
<mnemo> sadly I have to agree :(
<apw> jbarnes, about?
<jbarnes> apw: yeah
<apw> jbarnes, just had some feedback on the new mchbar patches, which i refactored onto our kernel, positive
<apw> so i'll be cleaning those up and getting back with you 'Tested-by ...' like
<jbarnes> great I was just typing that but you beat me :)
<jbarnes> I guess you can just reply to bjorn with the cleaned up version that worked for you and hopefully he'll just send it upstream
<apw> also just been talking about the other 965 hangs ... and there are rumours of swapping being involced
<apw> i was wondering if the bit 17 swizzle fixups could be involved?
<jbarnes> supposedly 965 doesn't generally have bit 17 issues
<jbarnes> but it's a possibility
<jbarnes> (the swapping I mean)
<jbarnes> should be easy enough to test... just need a memory hog to run at the same time
<apw> can we tell if we have swizzling there from the dumps we get?
<jbarnes> I don't think we provide that info right now...
 * jbarnes looks
<jbarnes> yeah I think we'd have to add some printks to the mchbar checking code, but 965 doesn't have bit 17 swizzling
<jbarnes> doesn't mean the new swap code isn't causing problems though...
<bryce> morning
<jbarnes> morning
<bryce> jbarnes: I realized I didn't run with the dri option in the last couple dumps I gave you... will try again today if it still seems relevant
<jbarnes> ok thanks
<bryce> tjaalton: I've been mulling over setting up an xorg-updates ppa or some such, with newer drivers for jaunty.  
<bryce> tjaalton: maybe as a ppa in xorg-edgers; it seems to fit well with what tormod does
<bryce> tjaalton: sound interesting to you?
<mnemo> bryce: would you then be willing to push those packages to main if they prove to be reeeally solid ?
<bryce> mnemo: well...  they couldn't go to jaunty since that's released
<bryce> mnemo: but yes, they'd be pushed to karmic main as well
<mnemo> ok, there is no way xorg/intel driver gets updated through SRU/propsed and so no?
<bryce> right, only cherrypicked bug fixes
<mnemo> right
<mnemo> im gonna be on karmic anyway
<mnemo> i want UXA to be rock solid for 9.10
<bryce> in certain, very very rare circumstances, an entire driver can go in as SRU, but only like if the driver was entirely busted and non-functional for everyone
<mnemo> yea I guess intel in jaunty is bad but not nearly bad enough
<bryce> but my idea with xorg-updates is to provide a way for jaunty users to get around this by getting new drivers to play with
<bryce> another idea along with that, is that we could "test run" driver updates there for karmic, before putting them into main
<bryce> so if there are like major issues, we can identify them there and then hold off on doing the update
<bryce> but that's just a side idea; dunno if it's worth the extra effort
<mnemo> I think part of the problem is that intel ddx and mesa is not well tested with .28 kernel... upstream is testing more carefully with .29 right now and .30 soon
 * bryce nods
<mnemo> a karmic PPA would be very nice though
<jbarnes> 2.6.28 should actually be ok... but dri1 & exa don't get much love these days
<mnemo> bryce: we're moving to UXA right away in karmic right?
<bryce> yeah I'm unsure if we did an xorg-unstable, if it should be driver/mesa updates only, or also include new xserver, kernel, etc.
<bryce> to keep it simple maybe just stick with major driver updates (e.g. -intel 2.7, etc.)
<tjaalton> bryce: yeah, sounds fine
<bryce> jbarnes: system still freezes with that buffer reuse option turned off
<jbarnes> bryce: arg
<bryce> jbarnes: want the gpu data?
<jbarnes> if you have the INTEL_DEBUG=batch output, yes
<bryce> is there a way to set that by default?  having to remember to restart gdm with that set each time is a PITA
<bryce> i.e. no this does not have that set
<jbarnes> you'd have to put it in one of the X session files i guess
<bryce> sometimes I wonder if you guys make up these options just to keep testers busy ;-)
<bryce> is there a way to check post-boot whether the option is in effect?
<jbarnes> bryce: yeah if we delay fixing the bug long enough the chip stops shipping :)
<jbarnes> dunno about a post-boot check no
<jbarnes> aside from seeing if you're getting tons of log output
<bryce> that would do.  log output in what file?
<jbarnes> the gdm log iirc
<jbarnes> like albert23 had
<bryce> ok
<bryce> is that gdm log file useful to you to include in the data dumps?  If so I'll add it to the guide.
<jbarnes> if it has the batch output, otherwise it's not interesting
<bryce> is the batch output included in intel_gpu_dump or /sys/kernel/debug/dri/0/i915* or dmesg as well, already?
<jbarnes> no the INTEL_DEBUG=batch option makes dri clients dump a bunch of stuff while they execute
<jbarnes> which just ends up on stderr I think for that client
<jbarnes> so if you start gdm that way its log will have all the batch output
<jbarnes> for anything X does anyway
<bryce> whoa, no kidding, that's a lot of data
<bryce> (fwiw, I just stuck it in /etc/init.d/gdm directly)
<jbarnes> cool
<jbarnes> yeah albert23's last attachment was several megs
<bryce> I see that an easy way to tell that it's in effect is that it slows the system down noticeably
<bryce> jbarnes: when setting dri options with driconf, do those take effect instantly or only on reboot?
<jbarnes> they'll take effect on newly started dri clients
<jbarnes> any running clients won't pick up the change though afaik
<bryce> ok, now have a freeze with the dri option, your patch, and INTEL_DEBUG=batch.
<jbarnes> cool
<bryce> intel_context.c:527: Batchbuffer flush with 404b used
<bryce> hrm, the compressed tarball with the gdm.log is 100mb
<bryce> 74 mb to be specific
<jbarnes> can you put it somewhere?
<jbarnes> btw I hope you can meet w/anholt, would probably go much faster
<bryce> waiting on it to upload to launchpad... might be a while
<bryce> meanwhile, snag it from:  http://www2.bryceharrington.org:8080/files/i915_debugfs_bwh6.tgz
<bryce> jbarnes: ^
<jbarnes> thanks
<jbarnes> bryce: wow almost a gig uncompressed :)
<bryce> good compression ratio... lotsa 0x00000 ;-)
<bryce> yeah it had to run for a bit before locking up
<bryce> it locked up while the switch-desktop OSD was showing, fwiw
<bryce> jbarnes: there is a Canonical meet up downtown Portland this friday that I'll be at, that anholt could come to if it would help for him to sit in front of the affected hw
<bryce> jbarnes: at least 3 people with affected systems will be there
<jbarnes_> bryce: ok cool
<bryce> forwarding the invite
<bryce> heh, compiz is starting to get piles of "compiz suddenly stopped working!!1!" bug reports
<mnemo> bryce: is there any way I could subscribe to all incoming intel ddx and mesa bugs? i'm thinking it would be useful to help out with triage etc
<bryce> mnemo: yes, you can get this by joining the ubuntu-x-swat team
<bryce> mnemo: that will actually subscribe for all of the X bug reports, so you may have to use a filter to only include the source package(s) you actually care about
<mnemo> bryce: cool, I requested to join now
<bryce> awesome, I've approved you
<mnemo> thanks
<mnemo> bryce: you use the "X-Launchpad-Bug: sourcepackage=blah" mailheader to sort the mail right?
<bryce> mnemo: exactly
<bryce> X-Launchpad-Message-Rationale also can be useful in narrowing down what gets put in your mailbox, but sourcepackage= should take care of th ebulk of it
<mnemo> right.. I use thunderbird so im thinking maybe I can sort into folders based on package and then color the mails based on bug status or something like that
 * bryce nods
<bryce> I use mutt, and colorize based on status changes
<bryce> mnemo: http://pastebin.ubuntu.com/156128/
<bryce> heya tormod
<bryce> tormod: I was thinking of an idea sort of inspired from xorg-edgers, to set up a ppa for jaunty updates, but only for stable releases, so people who want newer drivers but not risky git updates have a place to snag them
<bryce> tormod: pretty bare bones so far, but it will be living at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<tormod> hi bryce! that's exactly what we have in ~intel-gfx-testing
<tormod> I have just been waiting for 2.7.1...
<bryce> tormod: oh, didn't realize that was still being maintained
<tormod> (looking) I see you go beyond intel
<bryce> yeah
<bryce> should we merge these two things?
<tormod> well maintained... I am waiting for a "stable" version :)
<bryce> have you found 2.7.0 not stable enough?
<tormod> no, just the intel x.y.0 experience
 * bryce nods
<bryce> well, a secondary reason I have for setting this up is to pre-test packages we're considering for karmic, to help us find major issues before uploading
<tormod> the only reason for having a separate intel repo is that intel needs newer libdrm, the other drivers usually don't
<bryce> er, before uploading to karmic
<jcristau> tormod: also intel breaks more than others :)
<tormod> otherwise we can just use your xup and forget about intel-gfx-testing
<tormod> jcristau: true, it should be kept isolated, and be touched with gloves :)
<bryce> tormod: I think it'd be fine to carry newer libdrm's in xup... in fact you can see I already pulled in debian's libdrm 2.4.9 :-)
<bryce> it's the kernel dependencies that I worry most about...
<tormod> yes those are a pita - I guess the "mainline kernels" repo will be popular
 * tormod runs 2.6.30rc3 btw
<bryce> I talked to apw about getting a .dsc for 2.6.30-rc2, although not sure if he's had time to set it up
<bryce> for xup I'm thinking of restricting it to only updates that can run on the given series' kernel and xserver
<tormod> yeah that's a good rule
<bryce> but updates to mesa, lib's, etc. are okay
<jcristau> i'd be pissed if the driver stopped working with "old" kernels. but maybe that's already happened..
<tormod> for the time being this == xorg-edgers
<bryce> if we find we need something more than that, then maybe that calls for a specialized ppa, something in xorg-edgers perhaps
<mnemo> jcristau: since eric is ripping out EXA/DRI1 I guess it will soonish run only on GEM kernels (which I think is .28 and later) .. not sure when they will merge the cleanup branch to master though
<jcristau> yeah
<jcristau> but i need partial upgrades from lenny to work. that means .26...
<tormod> can it not run without acceleration? sounds like it dead slow anyway
<bryce> jbarnes: another dri_debug dump with INTEL_DEBUG - https://bugs.edge.launchpad.net/ubuntu/+bug/365299
<ubottu> Launchpad bug 365299 in xserver-xorg-video-intel "[i965] X freeze while running repro script" [Undecided,New]
<jbarnes> bryce: ok thanks
<jbarnes> god interactive perf sucks when a build is going on
#ubuntu-x 2009-04-23
<bryce> jbarnes: is the gpu dumping stuff particular to 9xx?  is it at all worth trying for 8xx freeze bugs?
<jbarnes> so far it just decodes 9xx stuff mainly
<seb128> bryce_: did you try to trigger the intel crash with a virtual config?
<seb128> there has been 2 new comments from users who don't have the issue and have virtual settings today
<hyperair> is there a reason i965 has been blacklisted in jaunty?
<hyperair> i commented out the line in the compiz loading script and it seems to run fine
<mnemo> hyperair: if you do "aptitude changlog compiz" maybe there is a comment about the reason on that change?
<hyperair> mnemo: i'll poke it later when i'm back in jaunty.
<hyperair> the installer hung on me.
<hyperair> bah
<mnemo> ;(
<hyperair> well then
<hyperair> off i go
<hyperair> with another attempt with the usb startup thing
<jbarnes> apw: get a chance to put together those mchbar patches yet?
<bryce> http://people.ubuntu.com/~bryce/drivers.svg
<jcastro> bryce: that is ouchy
<bryce> jcastro: yeah
<paran> but that is a nice graph.. I didn't know gnuplot could output SVG :)
<jbarnes_> bryce: those trends are pretty scary... all of the used drivers have positive slopes
<bryce> jbarnes: yep
<bryce> well, except for -nv and -openchrome
<jbarnes> yeah that's why I qualified it with "used" :)
<bryce> heh
<jbarnes> we're clearly in the worst shape though... and only partly because there are so many intel chips out there
<bryce> -ati at least has fewer bugs now than it did at the start of  the period
<jbarnes> yeah that's nice
<jbarnes> I wonder how many ati bug reports are supressed when people just move to the proprietary driver though
<bryce> actually for jaunty, we've seen the reverse situation
<jbarnes> if they find a bug in fglrx I wonder if they report it directly to ati or just live with it too
<jbarnes> oh really?
<bryce> -fglrx was not available for the longest time, so people were using -ati, and then when we finally did get it, they dropped support for all pre-R6xx chips
<jbarnes> oh right
<bryce> so this cycle a LOT of people have been forced to shift to -ati.
<bryce> also the functionality gap between -ati and -fglrx is a lot narrower than between -nv and -nvidia
<jbarnes> yeah
<bryce> I've given up on -nv pretty much.  I think in karmic we're going to switch to -nouveau like fedora has
<jbarnes> yeah might be in ok shape by then... the fedora guys have been putting a ton of work into it
<bryce> with -intel, I'm a bit concerned in that with the EXA -> UXA transition, is upstream going to care any longer about bugs when using EXA?  If not, what do we do with all these existing bug reports?  wontfix them?
<bryce> I guess, once we have new -intel bits in place, we'll ask people to retest against that, and close the bugs if they can't reproduced there
<jbarnes> yeah that's one option
<jbarnes> we'll continue to do 2.7.x releases though
<jbarnes> which means asking users to try uxa might become more viable over time with juanty, since the driver has it and it should get more usable over the 2.7.x period
<bryce> that's good to hear
<bryce> I'd like in karmic to retain the option of switching back to exa for users who have trouble with uxa
#ubuntu-x 2009-04-24
* mnemo changed the topic of #ubuntu-x to: Ubuntu 9.04 released! | https://wiki.ubuntu.com/X
<nawi> I have an old bug that is supposedly fixed and I haven't got any responses https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/308410
<ubottu> Launchpad bug 308410 in update-manager "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed]
<tseliot> nawi: that should be fixed. What driver are you using?
<tseliot> which version?
<nawi> tseliot, i'm using the "nv", driver but that problem persists no matter what driver I attempt to install
<tseliot> nawi: what does this command say? apt-cache policy xserver-xorg-core
<nawi> actually, it seems I can install the nvidia-glx-173
<nawi> but the problem persists for 180, which is my goal
<tseliot> please attach the output of that command ^^
<nawi> xserver-xorg-core:  Installed: 2:1.6.0-0ubuntu14  Candidate: 2:1.6.0-0ubuntu14
<nawi>  Version table: *** 2:1.6.0-0ubuntu14 0        500 http://archive.ubuntu.com jaunty/main Packages       100 /var/lib/dpkg/status
<tseliot> nawi: ok, now I need the output of this command (use pastebin.com to paste the output): sudo aptitude show nvidia-glx-180
<nawi> the problem started when I did update and rebooted, there was kernel mismatch between 180 and 185 drivers, then I reinstalled 180 which removed xserver
<nawi> now I have xserver but not nvidia-glx
<tseliot> 185 doesn't exist
<tseliot> yet
<nawi> http://stuntmoto.org/php/zf/
<nawi> that has 185 too mysteriously
<nawi> I found a couple of intrepid sources from apt repositories, l removed then and updated and the problem is gone
<nawi> now I'll just need to try installing the driver
<nawi> and nvidia-glx-180 is now Version: 180.44-0ubuntu1
<tseliot> nawi: ok, so the problem was caused by a package installed from an external repository
<nawi> yes, it seems so
<tseliot> remove that repository from your sources.list
<nawi> already did that and i'm installing the driver now
<tseliot> if it doesn't work
<nawi> i'll reboot now
<tseliot> just type: sudo rm /var/cache/apt/archives/nvidia*
<nawi> it works now, thanks for the help
<jbarnes> apw: ping
<tormod> bryce, did you delete all -intel packages from x-updates?
<tseliot> tormod: if I get drm from git and then type: make -C linux-core DRM_MODULES="i915"  only drm.ko is built but no i915 any ideas as to what I'm doing wrong?
<tormod> tseliot: if you just run "make", is i915 built then?
<tseliot> tormod: just "make" gives make: *** No targets specified and no makefile found
<tormod> well you are in the linux-core directory?
<tseliot> I'm running make -C linux-core now
<tseliot> let's see what happens
<tormod> your syntax above used to work, at least for other modules
<tseliot> tormod: yes, it works for i810, radeon, etc. but not for i915 or i830
<tseliot> no, there's no i915.ko
<tormod> ah I remember, they ditched it - you're supposed to get it from the kernel now, and not from linux-core
<tseliot> the files related to i915 are in shared-core
<tormod> the i915 stuff in libdrm/linux-core is rotting
<tormod> which means nobody wants to bother with backporting stuff to linux-core which then has to built with any kernel
<jbarnes> oh yeah geez don't use the drm repo
<tseliot> tormod: basically I'm trying to get the drm bits for the kernel and to make them build with DKMS so that I can use the latest intel driver with libdrm + the drm kernel bits while keeping kernel 2.6.28
<tormod> jbarnes: for intel you mean? linux-core is still valid for other drivers right?
<jbarnes> kinda
<tseliot> jbarnes: where shall I get it for intel?
<jbarnes> airlied has been putting stuff he considers stable into his drm-rawhide repos and such
<jbarnes> tseliot: for intel just copy the drivers/gpu/drm dir from a more recent kernel
<tseliot> jbarnes: ok and then something like make -C linux-core DRM_MODULES="i810 i830 i915" should work, right?
<jbarnes> possibly
<tseliot> ok
<jbarnes> assuming it picks up the right headers too
<tseliot> jbarnes: and where can I find them?
<jbarnes> include/drm
<tseliot> ah, ok
<tormod> tseliot: I was just uploading a libdrm and -intel for Jaunty in ~intel-gfx-testing PPA, it might be what you're after
<tseliot> tormod: yes, but wouldn't I still need the kernel modules though?
 * tseliot would like to use UXA and benefit from the fixes in the kernel
<tseliot> (and not having UXA hang X)
<tormod> yes, if you need kernel fixes it will not help
<tseliot> dkms should be the answer
<tormod> or use the "mainline kernel" repo
<tseliot> that too but I would like to keep a kernel which is supported and have the new kernel stuff as a module which is automatically rebuilt when the kernel is updated
<tormod> yes that sounds nice if it will work
<tormod> if the above works, why don't they copy the gpu/drm stuff back into linux-core? would be nice, because then drm-snapshot could be used
<tormod> (and drm-snapshot could be ported to dkms of course)
<tseliot> right
<tseliot> ok, I got it to work from the kernel
 * tseliot needs to move it from the kernel to a separate package
<tormod> hi bryce, I dropped a libdrm and -intel 2.7.0 in ~intel-gfx-testing
<tormod> I did the dirty libdrm-dev Replaces libc-headers. If it's ok you might want to copy it to x-updates.
#ubuntu-x 2009-04-25
<bryce> heya andresmujica
<maco> so i've got an interesting situation. X (with -intel for i965) was working great on an install that was upgraded from intrepid to jaunty alpha 2 and onward. i did a clean install, and now it crashes after only running for a few minutes...but not on a live cd
<maco> first time i've ever heard of a clean install making things worse
<bryce> maco: did you report a bug?
<maco> not yet, i just switched to live cd a half hour ago to see if itd keep happening
<maco> tried installing l-b-m too figuring maybe i had that on the upgraded system
<maco> im trying to figure if there's any other stuff to check that could put it in the "configuration issue" category
<bryce> well you know the drill... collect a backtrace, report a bug, etc.
<maco> ok
<maco> hrm...wait if its locking not going away completely, can i still get a backtrace? it's doing the freeze-but-mouse-moves thing
<james_w> is that compiz freezing?
<james_w> do you have an ssh server running on that machine?
<maco> i dont have compiz on here
<james_w> ah, sorry
<maco> but i did have kwin running with compositing...
<james_w> is that kwin freezing? :-)
<maco> well i cant click anything when it does that, nor switch to a VT
<maco> and xcompmgr was working fine on the upgraded install for the last week
<maco> the only thing i can think of is that i had greedy set on the upgraded install and hadnt added that yet on the clean install. but i dont think it's set onthe live cd which is running fine, so...
#ubuntu-x 2009-04-26
<jcastro> bryce_: your list is set, sorry for the confusion
<bryce_> jcastro: thanks!
<bryce_> tjaalton: do you operation ubuntu?
<bryce_> er, s/operation/operate/
<tjaalton> bryce_: operate?
<bryce_> tjaalton: do you know how we can get it subbed to ubuntu-x-bugs@ ?
<tjaalton> bryce_: ah.. well, no :)
<bryce_> who runs it?  any ideas?
<tjaalton> there's such a mailinglist?
<bryce_> I'm setting it up
<tjaalton> I mean 'ubuntu' :)
<bryce_> I don't want to switch over to it until people (and the bot) have had a chance to sub
<bryce_> https://edge.launchpad.net/~ubuntu-x-swat/+mailing-list-subscribers
<bryce_> (see the post I just sent to ubuntu-@ about it)
<tjaalton> riiight, I get it now
<mnemo> bryce, tjaalton: how can I build and install mesa from git without loosing the ability to go back to supported distro packages?
<tjaalton> mnemo: why would you lose it?
<mnemo> im not sure exactly but I think during jaunty cycle that I ended up with a mix of everything
<mnemo> i used --prefix=/usr back then
<tjaalton> ah
<mnemo> should I use --prefix=/usr/local and then delete everything in /usr/local to go back?
<mnemo> or what is the foolproof way to revert?
<tjaalton> so clone mesa from git.debian.org, and pull the upstream branch on top of the packaging branch (ubuntu, debian-unstable..)
<tjaalton> better yet, create a branch for it first
<mnemo> ok and then build a deb from debian git repo?
<tjaalton> (git checkout ubuntu; git checkout -b my-test; git merge mesa_7_4_1)
<tjaalton> yes
<mnemo> with a bit of googling I can figure that out
<tjaalton> modify the changelog first
<mnemo> and in the final step, how do I revert from the debian-git DEB back to the distro DEB?
<mnemo> for example, can I use "sudo apt-get install mesa/jaunty" ?
<tjaalton> apt-get install foo=VER
<tjaalton> I'm not sure if there is a simple way to revert all the packages in one go
<tjaalton> afk, tv ->
<mnemo> when I revert from xorg-edgers I usually do something like:
<mnemo> sudo apt-get install $(apt-show-versions -b | awk '/\/unknown/ { printf gensub(/([a-z0-9-])\/unknown/, "\\1/jaunty ", 1) }')
<mnemo> yea
<mnemo> cya
<mnemo> thanks for the help
<cshadowrun> is there any new information about xrandr supporting multiple nvidia cards with 3d?
<cshadowrun> i last looked about 5 months ago
<cshadowrun> also, anyone know a decent replacement for gnome-panel since it's completely disfunctional for multiple X screens in jaunty?
#ubuntu-x 2010-04-26
<Sarvatt> bryceh: amazing how many people are trying to literally run apport-collect BUGNUMBER in response to your automated replies :D
<RAOF> Sarvatt: Good $TIME_OF_DAY
<RAOF> Is there anyone around to sponsor an xserver-xorg-video-intel upload?  We need to drop the DRI-disablement patch before release.
<rafiyr> I need a touch of help debugging driver assignment for an input device.
<RAOF> I'm not particularly experienced in that area, but need experience in that sort of debugging.  want to learn together? :)
<rafiyr> Sure
<rafiyr> Let the fun begin
<RAOF> So, what's the problem?
<rafiyr> I'm just trying to verify the n-trig stuff gets setup correctly.  Its a pen+multitouch sensor in the screen
<rafiyr> Atm, the wacom driver is best for the pen and evdev for touch.
<rafiyr> And lucid beta 1 was assigning them correctly (I think).  But the current images are assigning both to evdev.
<rafiyr> There seem to be pattern matches for all sorts of stuff in /lib/udev/rules.d and /usr/lib/X11/xorg.conf.d
<RAOF> I think that we switched to the xorg.conf.d work between beta 1 and now.  This would probably be the cause of the switch.
<rafiyr> And I tweaked both (when booting off a live image on a usb stick)
<RAOF> Right.  My understanding of the way these interact is that udev can tag devices with particular information, and the rules in xorg.conf.d use that information to match appropriately.
<rafiyr> So if I change the files in that dir, should an X (gdm) restart reassign the drivers?
<rafiyr> Or am I going to have to poke at the image before booting on it?
<RAOF> That is my understanding.
<rafiyr> hm
<RAOF> You shouldn't have to reboot.
<rafiyr> 2 minutes until my usb stick is ready for another test (decided to clean it before trying again)
<RAOF> Unless you're fiddling with udev rules; I believe that would require that you re-run the udev scanning stuff, which might not be possible on a running system.
<rafiyr> I tried fiddling with udev, hal/fdi, and the xorg.conf.d and restarted all the udev services and gdm
<rafiyr> but let me try just fiddling with xorg.conf.d when it comes back up
<RAOF> https://fedoraproject.org/wiki/Input_device_configuration is some documentation, if you haven't found it yet.
<RAOF> Stupid killswitch.  Keeps getting accidentally triggered.
<rafiyr> interesting
<rafiyr> Have to admit, that I'm still just used to configuring everything myself
<RAOF> I know why.  It's relatively easy to do, once you've learnt how.
<rafiyr> And this automated stuff just makes life so much harder
<RAOF> Until it works, at which point you no longer notice it :)
<rafiyr> Like screen resolutions and dpms.  One of my video drivers started deciding it knows best, and since I didn't use a compliant identifier for my monitor, it ignored my modelines.
<rafiyr> Yeah, hoping so.  This n-trig stuff certainly is a pain without auto-config.  The best way to use it seems to be to target 2-3 event nodes, which of course may move around on every boot
<RAOF> Without knowing the details of the hardware, it would seem to me that you should be able to match on Vendor and/or Device to do that configuration?
<RAOF> Or possibly just MatchIsTouchscreen "on" ?
<rafiyr> Have to match the product id (thanks for that link the explanation of the pattern keys helped) since I want to use different drivers for the pen and touch
<rafiyr> (added the sensor types to the name in the kernel a couple months ago)
<RAOF> Aha!
<rafiyr> So, if you have a pen, how would you assign the buttons
<rafiyr> the tip is of course left click or btn0 (or 1 depending on who you ask)
<rafiyr> there is a barrel switch, which seems to default to btn 2 (middle)
<rafiyr> and a button a little further up the side which switches to eraser
<rafiyr> but in eraser mode that too emits a left click for normal desktop use
<RAOF> What does the tip button emit when in eraser mode?
<rafiyr> left
<rafiyr> seems to me to be a bit wasteful
<RAOF> It's always left, as is the erasor buttor?  That'sâ¦ odd.
<rafiyr> I personally map them to tip left, tip+barrel -> right, and tip+eraser -> middle
<RAOF> Incidentally, I know that bryceh is doing some multitouch work with an n-trig device - you might want to check in with him when it's not 10pm on a Sunday :)
<rafiyr> yeah, been working with him for a while now
<RAOF> I've never really played with a pen, so I'm not sure what the ergonomic constraints are on button placement :)
<rafiyr> Yeah, I figure I should figure out who is familiar with the conventions so I can maintain some consistency
<RAOF> So the n-trig stuff isn't working out of the box on the RC?  It sounds like we should be able to fix that.
<rafiyr> well, that link was what I needed, so thank you for that.  I figure the rest is just tuning and shouldn't be a problem once I figure out what the proper behavior is.
<rafiyr> Well, 1 line in 10-wacom.conf
<rafiyr> MatchProduct "N-Trig Pen"
<rafiyr> instead of "HID 1B96:0001"
<rafiyr> but I'm experimenting with the button maps now, to see if I can make those sensible
<rafiyr> Gimp only seems to draw on button1.  So I'd better leave that one alone.  But I see no reason not to prefer right over middle for the button on the side of the pen
<rafiyr> Seems to me that when you only have 2 buttons, right trumps middle
<RAOF> Ack.
<rafiyr> I suppose I should open a bug report and email a few people
<RAOF> A bug report would be good; xserver-xorg-input-watcom seems like a good target.
<rafiyr> ok
<ricotz> RAOF, hello
<RAOF> ricotz: Howdie.
<ricotz> RAOF, are you using edgers ppa with nouveau?
<RAOF> I have been in the past.
 * RAOF is currently using the nvidia netbook to test out GPU video decoding capabilities.
<ricotz> for me with xserver 1.8 , X freezes on logout
<ricotz> RAOF, ok
<RAOF> I haven't tested xserver 1.8; there's still a bit of fallout from the way upstream fixed the GEM object leak, though.  It's possible you're seeing that.
<RAOF> Or just some other random X bug! :)
<ricotz> i am seeing no other problem, 3d is working fine, and so on, only when i try to shutdown X it freezes, but i am not sure if nouveau or xserver is the problem here
<ricotz> the gem_object leak is no problem for me, enough ram here
<RAOF> ricotz: Either you're restarting X frequently, or you'd be noticing the GEM leak; even with 4 GiB you'll notice when 3GiB have been stolen by gem :)
<ricotz> i know, having 8gb ;-), it will take some time to fill them
<rafiyr> RAOF: thanks for your help.  I'd better get some sleep.  btw, a user had already opened a bug.
<RAOF> I wish i915 was slightly less *totally silent* during startup.  It might be nice if it mentioned what displays it thought were connected, for example.
<KiBi> /C/C
<KiBi> hmpf. :)
<mvo> tseliot: I updated bug #568041 (if you haven't see already), it would be interessting to ask him to re-test with network
<ubottu> Launchpad bug 568041 in jockey "[Lucid] Upgrade from Karmic broke nVidia installation on cdrom only upgrade (without network)" [Undecided,Won't fix] https://launchpad.net/bugs/568041
<mvo> tseliot: but I think it will work just fine then (it does for me)
<bjsnider> RAOF, what hardware does the netbook have?
<tseliot> mvo: ah, so that was the problem
<tseliot> mvo: thanks for dealing with that report
<mvo> np
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/565981/comments/77 -- that is a very good point, the slowdown that lead to those reverts was indeed the memory leak problem
<ubottu> Ubuntu bug 565981 in xorg-server "[KMS] gem objects not deallocated" [Critical,Fix released]
<LLStarks> OpenGL vendor string: VMware, Inc.
<LLStarks> OpenGL renderer string: Gallium 0.4 on i915 (chipset: 945GM)
<LLStarks> OpenGL version string: 1.3 Mesa 7.9-devel
<LLStarks> i find that to be very sexy.
<Ng> eep, just updated the X40 since all the DRI disablement got dropped, and it won't start X
<Ng> with -intel 2:2.9.1-3ubuntu4 or 5 (the only two debs on there). I just get a black screen
<Ng> aha, it's the kernel
<Ng> -19 works, -21 doesn't
<Ng> -20 works too
<Ng> bryceh: please can I be more important than the people who wanted 8086:3582 blacklisted from KMS? ;)
<Ng> hrm, and now an oops from -20 in intel_release_load_detect_pipe
<bryceh> Ng, my eyes don't matter - you need kernel team luv
<bryceh> Ng, any changes to that now would require rolling a kernel change
<bryceh> apw, ^^  we're getting a lot of anti-votes for blacklisting kms on 8xx
<bryceh> Ng, it would be interesting if you booted the kernel with the blacklist (-21 or newer) and see if it works if you force kms on (i915.modeset=1) if it starts working
<ilmari> bryceh: any tips on debugging #568138?
<ilmari> deadlock in i915_gem_*_ioctl
<bryceh> ilmari, nope
<bryceh> nothing beyond the usual anyway.  see the ubuntu-x wiki.
#ubuntu-x 2010-04-27
<mdeslaur> fyi: http://blino.org/blog/mandriva/poulsbo-xserver1.7.html
<ripps> why does it take forever for the gtk file dialog to do anything when I select a folder with a lot of images. It freezes for like a full minute before it allows me to bush a button.
<RAOF> The simple, facetious answer would be âbecause GTK is doing something slowâ.
<RAOF> ripps: However, we can do better than that.  Let's narrow it down: what X driver?
<ripps> RAOF: r300 ati KMS
<RAOF> Good, so we're in the âshould have decent accelerationâ zone.
<RAOF> It also suggests that maybe it's not an X problem, but let's see if we can pinpoint it.
<RAOF> Is there any obvious system load when that's happening?  Disc access?
<RAOF> Is GTK trying to do something stupid, like create thumbnails for everything?
<ripps> It is an external ntfs harddrive, so I suppose that might have something to do with it, but this problem seems to come a go. Just a few weeks ago, it was loading at a decent pace, but the last couple days, it's been taking almost a full minute. The only program that seems to be having load is the program that called the dialog (in this case, usually google-chrome)
<ripps> It spikes pretty high too, I've caught chrome at about 86% during one of these loads
<RAOF> If you copy that directory to a more native filesystem, does it load quickly?
<ripps> RAOF: I don't have enough space on a native filesystem right now (hence the reason I use a external harddrive) I could do some cleaning and see if I can.
<RAOF> Keep that up your sleeve; it might be useful.
<RAOF> So, does this happen all the time?  If you now try to open the same directory again, is it as slow again?
<ripps> I don't want to convert the harddrive to a linux native filesystem because I tend to transfer files between it and a windows pc usually.
<ripps> RAOF: loading the directory in Nautilus doesn't have this kind of slowdown, only with gtk file dialogs
<ripps> I have a lot of images and cbz comic archives mixed together in the folder
<ripps> Hmmm... at-spi-registry jumped up to 15-19% while it was loading the directory... think that might have something to do with it? 
<ripps> RAOF: ^
<RAOF> That seems odd.
<RAOF> That's the accessability frameworkâ¦
<ripps> Hmm.. now that I think about it. I started playing around with secondary dwell clicks a few weeks ago. I turned it off because it wasn't working very well, but I might have never turned accessibility service off. 
<RAOF> Give that a whirl, perhaps?
<ripps> well, I killed at-spi-registryd, but I still see slow dialog, this time Xorg was the one jumping up to 15-18% instead of at-spi
<ilmari> anything revealing in xrestop?
<RAOF> oprofile might be a winner; it would be interesting to see what's actually taking time.
<RAOF> Also, to eliminate the driver it might be nice to try again with the vesa driver.  If that showed the same behaviour it would strongly suggest a bug somewhere higher in the stack.
<ripps> How do I force X to load vesa?
<RAOF> Add an xorg.conf with Driver "vesa" in there.  https://wiki.ubuntu.com/X/KernelModeSetting has an example.
<ripps> How do I use oprofile?
<RAOF> http://oprofile.sourceforge.net/docs/ has a cheat-sheet
<RAOF> I haven't used oprofile myself, though, so I'm not sure how easy that is in practice.
<RAOF> opreport --demangle=smart --symbols `which lyx` from the examples page is probably the output we're looking for.
<bjsnider> RAOF, what hardware does the netbook you're testing have?
<RAOF> bjsnider: An intel something-or-other and a GeForce 9300M
<bjsnider> cool, so it's dual gpus?
<RAOF> Yes, but hidden behind a crazy bios switch.
<RAOF> One of them is always hidden.
<bjsnider> well, i set up a ppa with vaapi with mplayer and vlc. depending on which intel generation, hardware accel for hd video may work for both gpus
<bjsnider> https://launchpad.net/~nvidia-vdpau/+archive/cutting-edge-multimedia
<bjsnider> i'd say for it to work well the intel gpu has to be at least a gma 4500
<Sarvatt> it needs seperate libva kernel and libdrm updates as well to even be worth bothering with on intel
<Sarvatt> none of its upstream yet last i checked a few days ago
<RAOF> Yeah; those patches exposing the fancy h264 hardware decode ringbuffer to libdrm don't seem to have landed yet.
<bjsnider> strange that the intel libva driver builds. i'd have thought there'd be undefined symbol errors and so forth
<RAOF> Ok.  Time for some lunch.
<Ng> bryceh: aha, I'll try that tonight, thanks :)
<mvo> hi, what is the best way to debug something like bug #570634
<ubottu> Launchpad bug 570634 in xorg-server "immediate logout of the gnome session after hardy -> lucid upgrade (inside kvm)" [Undecided,New] https://launchpad.net/bugs/570634
<mvo> apport seems to not pick it up, should it?
<jcristau> you say "nothing unusual in the X log" and then attach an X log which shows a segv :)
<mvo> jcristau: that was a bit of a mistake â¦
<jcristau> compiz with cirrus, though?
<mvo> yes
<mvo> well, kvm
<jcristau> that's asking for trouble :)
<mvo> heh :)
<mvo> I noticed!
<jcristau> then again, (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
<jcristau> means compiz can't work
<mvo> yeah, it should detect it and fallback, and sometimes it does
<mvo> but not always it seems
<jcristau> maybe it tries, but X crashes first :)
<mvo> yeah
<mvo> is there a way to retrace the crash? will it pick up debug symbols automatically?
<jcristau> starting X with -core should get a core dump in /etc/X11
<jcristau> seems like X crashes on the first composite call, before compiz gets a chance to check glx stuff
<mvo> thanks, I try that (I just need to figure out where gdm calls X and how to add args)
<tseliot> mvo: maybe try gdm_server_start_on_active_vt (added by patch 28) or gdm_server_start ?
<seb128> mvo, start without compiz and see if running glxinfo crashes it too
<jcristau> seb128: it's not crashing in GL stuff
<jcristau> it's crashing in composite
<seb128> oh ok
<tseliot> mvo: you can add arguments as shown in that patch: server->priv->command = g_strdup (X_SERVER " -nr -verbose")
<jcristau> tseliot: should be possible to do that from the gdm config, though, hopefully
<jcristau> it is with gdm 2.20 anyway..
<seb128> I've looked a bit for this and it doesn't seem to be in the config with the new gdm no
<jcristau> sigh
<tseliot> :-/
<jcristau> no end of brokenness in this new gdm it seems
<jcristau> other option would be to start X without compiz, ssh in, attach gdb, and then start compiz
<mvo> tseliot: right, that is a bit heavy weight
 * tseliot nods
<mvo> glxinfo works fine
<mvo> but I'm sure its some sort of race as I sometimes can login
<mvo> and sometimes can't
<Cobalt> Is there any benefit to adding the Xorg Edgers repository (for Intel chipsets) in Lucid?
<JanC> Cobalt: do you have problems with the default drivers?
<Cobalt> I haven't upgraded yet, I was just wondering what people's experience of it has been. Will be doing so towards release time.
<JanC> Cobalt: I think xorg edgers might be useful on lucid for people with an intel i8xx IGP
<JanC> but I haven't followed all the latest stuff about that
<__mikem> Sarvatt: may I ask when I can expect xorg-edgers to be available?
<Sarvatt> __mikem: available? if you mean vmware support in there I already told you that i probably wont get to it for a  month or two
<__mikem> Sarvatt: oh okay. Sorry, I forgot that you gave me a time frame
<Sarvatt> i told you how to do it yourself too :)
<Sarvatt> mvo: hmm so kvm's cirrus device no longer has a 1234 pci id? we have a patch default cirrus to vesa but you have an actual cirrus pci id there
<mvo> Sarvatt: oh, that is interessting
<Sarvatt> defaulting qemu's cirrus pci id to vesa I mean because it had problems with the cirrus driver
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/184_virtual_devices_autodetect.patch;h=a236e2210ba8c71324f178e6e344c6954befc26e;hb=refs/heads/ubuntu-lucid
<Sarvatt> but looking at that i dont see how it ever worked since 1234 pci id would never have been matched and it would have been defaulted to vesa anyway, need to look into that some more
<Sarvatt> darnit, don't have any systems handy with hardware virtualization support to mess with it at the moment and it looks to be significantly different in the non KVM case, asking for a full backtrace with archive versions of xserver are still screwed up since xserver dbg and dbgsym packages are still screwed up
<Sarvatt> apport definitely isn't working with xserver segfaults though, its not just this one machine i'm on
<bryceh> fairly sure it's turned off by default at this point
<bryceh> Sarvatt, or had you explicitly enabled it?
<Sarvatt> yeah I enabled it and its not blacklisted
<bryceh> mm, then could be a bug somewhere
<bryceh> are other apport crash hooks working?
<Sarvatt> it hasn't worked since the fixes to have it not crash the server in other situations here, and i haven't seen an apport xserver bug since then either
<Sarvatt> yeah other ones are working fine
<bryceh> hrm, sounds like a bug in the x apport script maybe then
<Cobalt> JanC: Fair enough, I'll see what the deal is after I install.
<bryceh> Sarvatt, sounds a lot like a bug in my commit 1643fb38 but I don't see an obvious error
<bryceh> Sarvatt, would be interesting if commenting out lines 76-83 would make it functional again
<Sarvatt> will do, need to switch back to a broken xserver that i can crash easily too :)
<Sarvatt> it hasn't been working for me since january though, but its possible I'm remembering wrong or didn't dig into it any deeper in that time frame
<bryceh> well, I know it at least worked up until the last change (mar 8th) since that change was prompted by apport reports ending up in the wrong place
<bryceh> I admit I don't recall seeing many reports subsequent to that, but that's also about when we stopped the -intel freeze capture tool, which quelled a lot of the reports
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/510997 -- thats the last apport bug i see reported regarding a segfault using free drivers
<ubottu> Ubuntu bug 510997 in xorg-server "Xorg crashed with SIGSEGV in _IO_default_xsputn()" [Undecided,Confirmed]
<Sarvatt> assert reports seem to still be working
<Sarvatt> but there are lots of bugs with server segfaults in the logs after
<bryceh> hrm
<bryceh> there were several changes on jan 25th
<bryceh> and then a bunch in feb
<Sarvatt> that bug was filed against karmic too throwing another wrench in it, bah
<bryceh> bug #515135 is newer - from 1-31
<ubottu> Launchpad bug 515135 in xserver-xorg-video-intel "Xorg crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/515135
<Sarvatt> bryceh: ok thats interesting because xserver-xorg-core 2:1.7.3.902-1ubuntu9
<Sarvatt> xorg-server (2:1.7.3.902-1ubuntu9) lucid; urgency=low
<Sarvatt>   * Fully disable 100_rethrow_signals.patch as it seems to still cause
<Sarvatt>     crashes.  Goodbye apport.
<bryceh> seems the apport hook still works for proprietary drivers though - lp #566435 from 4/18
<ubottu> Launchpad bug 566435 in nvidia-graphics-drivers "Xorg crashed with SIGSEGV in strtol()" [Medium,New] https://launchpad.net/bugs/566435
<bryceh> this is a sad state of affairs to be troubleshooting why we're not *more* bug reports than we already are ;-)
<Sarvatt> well its wasting a heck of a lot of time digging through peoples logs and vague descriptions to find the info and we're losing automatic duping :) 
<bryceh> bugs that have vbox installed seem to be getting through ok - lp #559288
<Sarvatt> downgrading to xserver 2:1.7.6-2ubuntu5 now to play with the apport script and see if i can get it going
<ubottu> Launchpad bug 559288 in virtualbox-ose "Xorg crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/559288
<bryceh> mm, the vbox test bails out before the nvidia bits anyway so that doesn't tell much
<bryceh> ooh I have an idea
<Sarvatt> shoot me any ideas you have because i have an easily testable setup going now :)
<bryceh> wait maybe not
<bryceh> well there is a stanza towards the end that prompts the user before attaching their gdm files
<bryceh> since it's an interactive bit, I thought maybe it fails when handling crashes
<bryceh> however that wouldn't explain why it's working for proprietary drivers
<bryceh> but might try commenting that out and see if it makes any difference
<bryceh> the one thing I see that might be squirrelly with open vs. proprietary is the stuff for attaching /var/lib/dkms/ bits around line 92
<bryceh> Sarvatt, do you have a /var/lib/dkms directory?  If so, that bit of code could be executing but maybe the glob is breaking
<bryceh> kind of crazy how many X crashes are really "broken vbox" bugs
<Sarvatt> commented all of that stuff out, lets see
<Sarvatt> no /var/lib/dkms here
<bryceh> lp #560633 is a recent one with no proprietary drivers or vbox
<ubottu> Launchpad bug 560633 in xserver-xorg-input-evdev "Xorg crashed with SIGSEGV in read()" [Undecided,Confirmed] https://launchpad.net/bugs/560633
<Sarvatt> oh bah 2:1.7.6-2ubuntu5 had the fix for clutter crashing in it, it was 2:1.7.6-2ubuntu1 i needed
<Sarvatt> nothing in /var/crash/, apport is running and i even tried using the karmic source_xorg.py
 * Sarvatt just goes the easy route and puts a patched gdm to launch x with -core in a PPA for now
<Sarvatt> my crashes all end at 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e937b] but the ones that are working go farther past that? #2  0x00007f6ec8cf934e in backtrace () from /lib/libc.so.6 #1  0x00007f6ec7f3966e in _Unwind_Backtrace () from /lib/libgcc_s.so.1
<Sarvatt> it sure would be nice if mesa could remove ~/.drirc on upgrade or downgrade
<Sarvatt> i always forget to reset all of the settings when i change mesa versions, right now it leaves texture tiling enabled on intel when i downgrade back to the lucid version where its horribly buggy
<Sarvatt> think i'll put a note about that on xorg-edgers, only a problem if someone installed driconf anyway
<Sarvatt> bryceh: noticed something odd in the bug you linked there - http://launchpadlibrarian.net/43774793/GdmLog2.txt
<Sarvatt> it didn't print the backtrace info in the log and it successfully dumped a core
<bryceh> do you think people commonly use driconf?  If so we could add it to the apport hook :-)
<bryceh> yeah I haven't looked at enough of the new gdm logs to know if that's normal or not
<Sarvatt> nah i'm sure it's by far the minority but if you've ever installed it and changed the settings all of the settings stick around permenantly until you remove ~/.drirc
<Sarvatt> if i install mesa 7.9 and then driconf and change a setting, it'll store all of the settings from 7.9 and those will get loaded for everything mesa in all other versions even if the default values are different
<Sarvatt> going from 7.9 to 7.7 is bad that way because intel will use texture tiling that's really screwed up in 7.7 and disabled by default there
<Sarvatt> bryceh: all of the reports where apport is working and catching segfaults are the same - http://launchpadlibrarian.net/43553278/GdmLog2.txt
<Sarvatt> and here's what it looks like not working http://pastebin.com/DJtj6nhL
<Sarvatt> (that's /var/log/gdm/:0.log.1 after a crash)
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/168_glibc_trace_to_stderr.patch;h=ed218bb3673836c143afac8c8842255b818bd90c;hb=refs/heads/ubuntu insufficient for all cases?
<bryceh> well, the presence of a .driconf could be a clue on bugs; I'll put on my todo list to add it to apport later on
<bryceh> could be
<bryceh> Sarvatt, there has always been some cases where xserver crashes don't get caught by apport, and we never did figure out why
<bryceh> however it seems like we're getting far fewer than usual
<bryceh> mm, we disabled 100_rethrow_signals.patch on Jan 18th
<bryceh> so that explains why it "seemed" that crashes stopped being captured at that point
<bryceh> it was re-enabled on Feb 3rd
<bryceh>   * 100_rethrow_signals.patch: Fix SigAbortServer to cleanly exit(1) on a
<bryceh>     non-signal crash, as the original upstream code does. Not exiting leads to
<bryceh>     continuing back into the code which threw the error, which eventually
<bryceh>     leads to writing into the already closed log file and other operations
<bryceh>     which cause segfaults.
<bryceh>   * Re-enable 100_rethrow_signals.patch.  Hello apport.
<bryceh>  -- Martin Pitt <martin.pitt@ubuntu.com>  Wed, 03 Feb 2010 17:29:53 -0800
<Sarvatt> the log stops at the backtrace on every bug i can find so far where it's working, looks like the backtrace info is supposed to go to STDERR for apport to catch it and it's being printed to the log in the cases where its not working
<bryceh> weird
<bryceh> well, I can imagine that is what is causing the problem
<bryceh> but why would it be that this seems to be working for the proprietary drivers?
<Sarvatt> trying to find an apport bug with a 32 bit core dump i can play with to look into it more
<bryceh> we should bring pitti into this at some point too
<Sarvatt> seems to be one specific abort path that works and the others dont or something, the ones that are working are using proprietary drivers or having input related crashes
<Sarvatt> darn only core dump i can find is x86_64 and i use 32 bit on everything but one machine that i dont have access to at the moment
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/563759 -- floating point exception getting reported as a SIGSEGV?
<ubottu> Error: Could not parse data returned by Ubuntu: list index out of range (https://launchpad.net/bugs/563759)
<Sarvatt> yeah looking through the bugs it really was limited to proprietary drivers/input crashes even in karmic :(
<jcristau> obviously that's because the free video drivers aren't buggy
<Sarvatt> seems like it would be cleaner and work in more situations if apport just parsed the reason it died whenever it dies with a SIGABRT, but i have no idea how you'd get a core dump that way without starting with -core
<lapion> has anyone with that uses i915 kms with an i855 or older chipset tried the new 2.6.33.3 drm drivers?
<lapion> what was the ppa for experimental 2.6 drm kernels again ?
<Sarvatt> lapion: just curious, have you ever tried using KMS and forcing the X driver to fbdev to see if it had problems?
<lapion> You mean like booting with the regular kernel into single user mode and then staring up failsafex ?
<lapion> I mean booting to single usermode with kms, and then starting kms ? I get a black screen..
<lapion> 2nd kms=failsafemode
<lapion> failsafe mode/non kms mode gives me no dual screen..
<lapion> that is failsafe mode without kms
<lapion> Sarvatt, booting with kms and fbdev gives me black screen
<Sarvatt> ah yeah fbdev wouldn't give you dual screen anyway
<Sarvatt> lapion: how about intel 2.8.0? have you tried that out?
<Sarvatt> i backported all of the stuff to make it work with xserver 1.7 in the x-retro PPA
<Sarvatt> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-retro
<bryceh> ah thanks for fixing that up Sarvatt
<lapion> I just read someting in the http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33.3
<Sarvatt> needed 8 or 9 commits backported, EXA was dropped before 2.8.0 though so I dropped that part of the changelog that you put in
<lapion> You see I was getting hangcheck errors without the zserver freezing..
<Sarvatt> what did you read interesting there?
<lapion>     Commit:     bc9025bdc4e2b591734cca17697093845007b63d
<lapion> hmm I think I misinterpreted this one.. they are talking about locks not deadlocks
<lapion> hmm as of latest update my pentium 4 clock cannot be set anymore
<ilmari> speaking of locks/deadlocks... sysrq-d (show all locks that are held) isn't doing anything (just outputs the sysrq help message), even though CONFIG_LOCKDEP_SUPPORT=y
 * ilmari would like to be able to investigate https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/568138 further the next time it happens
<ubottu> Ubuntu bug 568138 in xserver-xorg-video-intel "[arrandale] deadlock in i915_gem_madvise_ioctl" [Undecided,Confirmed]
<lapion> btw when selecting resume in the Recovery Menu, doesn't start the Xserver under lucid
<ilmari> the gdm upstart job it's still checking /proc/cmdline and refusing to start if the machine was initally booted in single user mode
<ilmari> s/it's/is/
<lapion> well yeah sudo start gdm resolved in pretty quickly
<lapion> btw btw ilmari alt-ssyrq-d does that freeze up the system ?
<ilmari> lapion: I haven't tried actually hitting the keys, but echo d > /proc/sysrq-trigger just gives the help message
<lapion> about the freezes, if the xserver freezes once, the xserver freezes up faster in successive reboots
<ilmari> both the i915 kernel thread and X are stuck in __mutex_lock_slowpath+0xe7/0x170 
<lapion> are you talking about show blockes tasks (W) ?
<lapion> I believe it's activated with W
<ilmari> no, that works
<lapion> ilmari, 
<ilmari> which is just what the softlockup watchdog already has showed
<ilmari> 'd'     - Shows all locks that are held.
<ilmari> (from /usr/share/doc/linux-doc/sysrq.txt.gz)
<lapion> outdated info
<Sarvatt> ilmari: pretty sure its because CONFIG_LOCK_STAT isn't set
<ilmari> ah
#ubuntu-x 2010-04-28
<Sarvatt> definitely something to ask in #ubuntu-kernel though, i'm not sure. looks like the only requirement to show it is CONFIG_LOCKDEP but we dont have that set and i dont see what selects it, doesn't seem to be CONFIG_LOCKDEP_SUPPORT though
<Sarvatt> hmm FTRACE might disable it
<Sarvatt> ilmari: are you having that problem still with xserver 2:1.7.6-2ubuntu7?
<ilmari> yes
 * ilmari builds a kernel with LOCKDEP, LOCK_STAT and PROVE_LOCKING enabled
<ilmari> yeah, now sysrq-d works
<ilmari> Sarvatt: thanks
<bryceh> Sarvatt, http://www.happyassassin.net/2010/04/27/when-qa-works-x-org-and-memory-leaks-and-crashes-oh-my/
<Sarvatt> ignoring the fact it's still broken in F-12/RHEL-6 where they originated from then I guess?
<bryceh> hah
<RAOF> And as far as I'm aware, the issues with compositing managers *still* haven't been resolved.
<RAOF> Unless that changed since yesterday evening. 
<Sarvatt> it's working fine here now, i added another patch to xorg-edgers a few days ago thats fixing it
<bryceh> Sarvatt, you're messin' with his righteousness
<RAOF> Sarvatt: Was that the incorrect-but-works-ok patch on xorg-devel?
<Sarvatt> bryceh: not trying to sign up to that person's blog to say that, but it sounds like they don't consider it an issue because they don't ship clutter 1.2 with it so the only people reproducing the bug are people compiling things themselves. the crash bug is still there in the server though..
<Sarvatt> RAOF: yeah
<bryceh> I did find one interesting bit on that post... redhat uses something called 'bodhi' to help with their QA
<bryceh> Sarvatt, you're probably right.  that's funny in a way
<RAOF> That's their equivalent of *-proposed, IIUC, but it's got a dedicated UI, package karma, and such.
<bryceh> bodhi - http://fedoraproject.org/wiki/Bodhi_Guide
<bryceh> RAOF, interesting; is that turned on for the whole development process?
<bryceh> or is that only used for testing post-release ala our SRU mechanism?
<RAOF> bryceh: It's not clear to me.  I don't *think* rawhide goes through bodhi, so it'd be equivalent to our SRU mechanism.
<bryceh> kind of reminds me of our http://qa.ubuntu.com/reports/xorg_prop_drivers/
<bryceh> kind of a mashup of that and PQM
<RAOF> Since when has *that* existed?
<RAOF> That's the result of our call for dedicated restricted driver testing?
<bryceh> yep
<bryceh> sorry, assumed it was general knowledge.  alberto and I have been fielding questions from the testers all release
<RAOF> Either there's an X development list I'm not subscribed to or you've been fielding questions in private :0
<RAOF> Or maybe while I'm sleeping, I guess :)
<bryceh> heh, yeah ara set up a separate mailing list for this
<bryceh> which is just as well, a lot of the questions were really pedestrian
<bryceh> xorg-prop-drivers-testers@lists.launchpad.net
<bryceh> https://launchpad.net/~xorg-prop-drivers-testers
<bryceh> RAOF, you might want to browse through the archives.  This turned out to be a pretty successful little effort
<bryceh> I'd suggest repeating it for MM, and maybe even expand it to additional drivers if you'd like
<Sarvatt> that fallback testing result list is as expected since the test case had no chance of working in the first place..
<bryceh> yeah
<bryceh> the test plan needs some tuning up
<bryceh> I wrote it back before the alternatives system went in and some things I thought would work ended up not being implemented
<RAOF> bryceh: Thanks for that pointer.
<bryceh> heh, bug #568475
<ubottu> Launchpad bug 568475 in xserver-xorg-video-ati "screen corruption : multiple cases : fast scrolling firefox error console - fast mouse movement - sometimes just so" [Undecided,Incomplete] https://launchpad.net/bugs/568475
<bryceh> he couldn't take a photo of the screen to show the corruption, so he *drew* it
<bryceh> first time I've seen that :-)
<rafiyr> bryceh: if you have a moment, take a look at https://launchpad.net/bugs/556761, the ntrig pen support needs a couple lines updated in 10-wacom.conf
<ubottu> Ubuntu bug 556761 in xf86-input-wacom "ntrig stylus: can only left-click" [Undecided,New]
<Sarvatt> note to self: reboot and make sure you can mount the luks encrypted partition before you move things onto it in the future... :(
<RAOF> I've not had *that* particular problem with luks :)
<Sarvatt> only thing I can think of was I typoed the passphrase both times while creating it
<RAOF> Oh, you can't open it *at all*?
<Sarvatt> nope, tried every possible typo I can think of too
<RAOF> :(
<lapion> ilmari you there ?
<lapion> my system can be running for days with tvtime activity the whole time, occasionally using firefox as well, but then if I want to use the update-manager the system crashes.(hangcheck-crash) while updating or getting package information.
<lapion> of course I also get the crash on occasions when I am not using the update manager manually, I have never thought of checking if it started up autamatically
<Sarvatt> looks like the --with-dri-searchpath change to accommodate gallium isn't ideal, aiglx must be hardcoded to load from /usr/lib/dri and doesn't honor that. for now i'm just keeping things that only have gallium drivers in libgl1-mesa-dri (/usr/lib/dri) as well
 * bryceh waves
<Sarvatt> morning bryceh 
<bryceh> Sarvatt, heya I notice RAOF committed a 2:1.7.6-2ubuntu7.1 to git last Saturday with the glx patches and the updated upstream fix
<bryceh> Sarvatt, however I don't see signs that a matching SRU was filed, or that it was uploaded to lucid-proposed yet
<bryceh> Sarvatt, I'm going to prep an SRU xorg-server today so am wondering if I can just drop that 7.1 or if I'd be stepping on RAOF's toes impolitely if I did that
<Sarvatt> i don't know what the deal is with that, fixing savage at the expense of breaking all swrast users again doesn't seem like a good idea to me though :)
<bryceh> Sarvatt, how does savage come into this?
<Sarvatt> savage had a regression with clutter apps not starting with 2ubuntu7
<bryceh> ah
 * bryceh boggles at people running clutter on savage
<Sarvatt> but swrast is broken with clutter when the server has glx 1.3+ and I can't find anything but clutter people saying its mesa and mesa people saying its clutter's fault
<bryceh> heh
<bryceh> which means probably either one could be patched but neither wish to do it
<Sarvatt> yup :) if it's only savage RAOF was doing it for I'd like to try to fix up savage instead of breaking swrast again which affects a huge amount more people comparatively
<bryceh> no my guess is that this was a shot at fixing the memleak without sacrificing glx
<bryceh> fortunately he did it on a branch (ubuntu-linux) so looks like I can just do my changes on the main ubuntu branch
<Sarvatt> yeah need to ask RAOF what his thoughts are on it, savage is the only regression I have heard of so far
<Sarvatt> and that's been broken in many ways with clutter since the beginning :)
<bryceh> yeah and there's been a couple corruption bug reports I've seen which resolved when we moved to 1.2
<Sarvatt> bryceh: IMO those other SRU's (exa one in there?) should go in first since they're important crash fixes and the glx one is more of a wishlist thing that will probably need more lengthy testing and hold it up
<Sarvatt> the exa one is affecting everyone using radeon and the noscript extension that's really popular
 * bryceh nods
<bryceh> pitti also has one change I'll include
<bryceh> Sarvatt, on another topic...  have you looked into packaging -intel 2.11?
<Sarvatt> yeah I have been meaning to ask if you think it is something we should put in x-updates, but then I started questioning libdrm updates too and am unsure how much to put in that PPA :)
 * bryceh nods
<bryceh> do you know if anything besides libdrm needs updated?
<bryceh> if it's just libdrm I'd be game to include that
<bryceh> but if it starts needing mesa or other bits to be updated, maybe we should skip it and leave it to xorg-edgers
 * bryceh breakfasts... bbiab
<Sarvatt> nah, libdrm doesn't need to be updated for just intel 2.11
<Sarvatt> i'll package it up and upload it to x-updates, mainly I was thinking a PPA that had just libdrm/ddx/mesa stable branch in it would be useful for bug reporters to test against to check for things that need backporting, xorg-edgers is a bit drastic of a change :)
<Sarvatt> mesa stable seems safe to me, I mean look at the changes post 7.7.1 :) http://cgit.freedesktop.org/mesa/mesa/log/?h=mesa_7_7_branch
<bryceh> yeah a lucid-oriented ppa wouldn't be a bad idea
<bryceh> Sarvatt, ignoring the apple stuff, yeah looks like a few things maybe worth backports there
<Sarvatt> 2.11 uploaded
<bryceh> Sarvatt, key is to be able to tie those fixes to bug reports in LP, else justifying a SRU will be hard
<Sarvatt> meego has a copy-fb patch that applies to 2.11 at least :P
<Sarvatt> the blobs are pretty important to have in x-updates for sure since installing from the vendors websites doesn't work anymore, i put 195.35.24 in there the other day which is needed to support the whole new generation of cards that just came out
<bryceh> I've spoken with nvidia about that, and sounds like they're open to helping us out there
<bryceh> dunno about fglrx
<bryceh> thanks for uploading 2.11
 * bryceh crosses off the todo list
<Sarvatt> what are the policies regarding nvidia blob updates in a stable release given that it is unrealistic to keep one version for 3 years with how they do things? makes me wish there was a restricted-updates :)
<bjsnider> why couldn't there be a restricted-updates?
<Sarvatt> hardy could update from nvidia.com or use envyng or whatever but i can see it being a problem in lucid since by the end of desktop support 6 new generations of cards wont be supported at all
<bryceh> Sarvatt, so far the policy has been o/~ no, no no o/~
<bryceh> good question though
<bryceh> restricted-updates seems a sane idea as well
<bjsnider> nvidia sometimes introduces regressions in the blob, like the current problem with hdmi audio, but generally updates are necessary to support new hardware. and that should override other considerations
<Sarvatt> having it in the partner repo would be nice
<bryceh> maybe the right way is to have each driver update in x-updates as they're available
<Sarvatt> i *really* need to move ppa-purge over to python and look into integrating it with things so it purges ppa's on upgrade instead of just disabling them, this seems to be a really big problem with PPAs
<bryceh> and if there is an update which is found to be all good, no regression, suggest it for restricted-updates (assuming one was made to exist)
<Sarvatt> yeah I was just thinking it would be nice if there were "blessed" ppa's that could be enabled graphically with software sources to make that easier without requiring archive shuffling, but it seems like something that would be right for the partner repo since its proprietary and required with how they do updates. i'm not aware of all of the limitations on partner though
<bryceh> me either
<bryceh> well, in any case this is totally what I'd had in mind for x-updates
<imbrandon> i think i'm bitten by the intel kms bug but i'm not really good at truble shooting X problems , anyone arround to bounce some ideas off from to see if i need to file a new bug or if its an existing one ( i'm fairly confident its the latter but not 100% )
<Sarvatt> yeah for sure, same here, it's just the policies for what we put in x-updates that I am sketchy about. We should probably avoid libdrm if at all possible in there since it complicates things (new drivers will require the updated libdrm as well if built against it) but we're at the mercy of upstream there
<Sarvatt> like the blob will require the updated libdrm too if its built against it even if it doesn't use it..
<bryceh> Sarvatt, true
<bryceh> Sarvatt, yeah my original thinking had been drivers-only
<bryceh> although esp. with intel, it seems deps change a lot
<imbrandon> basicly here is what happens ( lucid upto date laptop as of an hour ago , no special ppa or anything ) , normal boot i get a blank screen after plymouth but before X ( i see plymouth ) , but if i add i915.modeset=1 i can get into X and everything seems normal until i goto play video ( with any player ) X crashes 
<imbrandon> sooo am i bit by the same bug, isnt there a ppa to fix it , i'm REALLY bad at X trubleshooting
<bjsnider> Sarvatt, i don't think the blob is build against libdrm
<Sarvatt> imbrandon: sounds like you have a 8xx generation intel? :)
<imbrandon> Sarvatt: yes, 845 i think, i can look if it matters
<imbrandon> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
<Sarvatt> theres no magical PPA that can fix 8xx at the moment unfortunately, it's horribly broken in general everywhere
<imbrandon> Sarvatt: ahh ok, so no better work arround than the i915.modeset thing ? is there as bug i can subscribe to to watch ?
<Sarvatt> yeah there are quite a few bugs, one sec I'll dig some up
<imbrandon> anything i can do to help test ? being a ubuntu dev i'm pretty familiar with the process, just not X ;)
<imbrandon> lol
<Sarvatt> this will be a problem on any modern distro though, its not ubuntu specific
<imbrandon> Sarvatt: yea i figured
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/541511
<ubottu> Launchpad bug 541511 in ubuntu-release-notes "MASTER: [i855] GPU lockup (apport-crash)" [Undecided,Fix released]
<imbrandon> seems like an intel driver thing, but i wasent 100% sure thus comming in here
<imbrandon> fix released ?
<imbrandon> ohh fixed in the release notes
<imbrandon> :)
<imbrandon> Sarvatt: great, gives me a place to start, thanks 
<Sarvatt> imbrandon: the first thing I would try is i915.modeset=1 + manually changing the driver to fbdev in your xorg.conf. you won't have multiple monitors or acceleration but it should work at native resolution. if that has problems I would try without KMS (which is the default) and use the vesa driver
<Sarvatt> both options are ugly but if you don't want to use an older release and cant upgrade the GPU there isn't much choice at the moment :(
<imbrandon> right now just the modeset seems to be working with justa a few artafacts in X
<imbrandon> i'm typing on this laptop ( screen + irrsi )  now so its not 100% lost
<imbrandon> might try the fbdev driver, dont care about accel or multimonitors
<imbrandon> Sarvatt: how can i turn KMS off though without recompiling the kern ?
<jcristau> boot with i915.modeset=0
<imbrandon> k
<Sarvatt> kms is defaulted to off on 8xx in lucid, just dont add i915.modeset=1
<imbrandon> ahh well without i915.modeset=1 i get a hard lock after plymouth
<Sarvatt> have you tried disabling splash?
<imbrandon> yes
<Sarvatt> how about blacklisting vga16fb?
<imbrandon> that i havent tried
<Sarvatt> echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-framebuffer.conf && sudo update-initramfs -u and try booting without splash. worth a shot :)
<imbrandon> ok so let me get this clear ( in my head ) what i should try ( gonna reboot in a sec to try it ) is blacklist that module, leave the modeset in the grub kernel line and switch to the fbdev driver ?
<imbrandon> Sarvatt: kk i'll try that first
<Sarvatt> in UMS there are a lot of options you can play with to see if you can get it usable, man intel in a terminal will list them, i'd start by disabling tiling 
<imbrandon> ok i'm detaching screen, bbiab , thanks for the pointers guys
<Sarvatt> dont use fbdev unless you're using KMS
<imbrandon> got it
<jcristau> kms+fbdev should work fine afaik
<Sarvatt> yeah vga16fb is only used with plymouth without KMS so it sounded like he was going to use that on top of dropping i915.modeset=1 (which would make him use UMS) and fbdev wouldn't work
<imbrandon> yea no i'm blacklisting it , leaving the modeset to 1
<imbrandon> and switching to fbdev
<imbrandon> first two done, making an xorg.conf now
<Sarvatt> blacklisting wouldn't matter there, was suggesting that to try to get intel working with UMS since you said that wasn't working
<Sarvatt> UMS+intel would be the ideal combination if you could get it working, the vesa or fbdev options are worst case scenarios
<imbrandon> ahh ok
<imbrandon> soo since i have it blacklisted i should "try" UMS and intel ?
<Sarvatt> yeah
<imbrandon> k lemme do that, its done now, brb
<bryceh> imbrandon, your questions make me wonder a bit...  a number of people have come here with similar questions, and I imagine there are going to be more once the release is out
<imbrandon> bryceh: probably :)
<imbrandon> ok so i'm back
<bryceh> I'd sort of like to figure out a way to address questions for folks higher up, prior to them coming here
<bryceh> imbrandon, can I ask you a few questions in relation to this
<imbrandon> ums+blacklist+intel dident work
<bryceh> imbrandon, what places did you look for a solution before coming here?
<imbrandon> so now i'm gonna try kms+fbdev
<imbrandon> bryceh: LP, but the intel driver stuff is a maze
<bryceh> imbrandon, how did you identify #ubuntu-x as a channel to ask on?  Did someone refer you, or a website, or just a guess?
<imbrandon> bryceh: i'd be happy to help maintain a wiki since i have the hardware to test it too
<bryceh> imbrandon, ok in LP what specifically were you looking for?  (The bug report is there, but evidently not in a form which you found easily digestible)
<imbrandon> bryceh: i'm a ubutnu-core-dev i just "knew" lol , but i'm just not a good X person
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=[i855] is a good list of similar bugs, the ones numbered 500000 and up are lucid ones mostly
<bryceh> ok, so #ubuntu-x based on past experience
<imbrandon> ( about the channel that is )
<imbrandon> yea
<bryceh> imbrandon, by chance did you look at the release notes or the Ubuntu-X wiki pages before coming here?
<bryceh> if not, is that because you didn't know about them, or because you knew but didn't think they'd have the answers?
<imbrandon> bryceh: yea, berifly, thats why i knew it was a wider problem that there might be a work arround for, just wasent clear on what the workarround was
<imbrandon> release notes, not the wiki
<Sarvatt> it helps a lot having someone willing to test things in real time not having access to the hardware myself :)
<imbrandon> wiki pages for teams i rarely check as from experice ( maybe not in X's case ) havent had awnsers about bugs, only the team
<bryceh> imbrandon, ok good to know - did you spot the wiki link from the entry about it in the release notes?
<imbrandon> yea
<imbrandon> Sarvatt: heheh yea , an i love this laptop, its my "main" dev machine, i hate to replace it ;)
<Sarvatt> imbrandon: if you want to test UMS more later it might be worth trying the version of xserver-xorg-video-intel thats in this PPA -https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-retro
<bryceh> Did you follow the link?  Why or why not?  If you followed it, did you find it useful or not?  (too technical? too general?)
<imbrandon> Sarvatt: sure i'm down for testing whatever, i have a few working desktops and servers should i totaly fubar something 
<imbrandon> ;)
<imbrandon> bryceh: i followed it but it was too general it seemed so i quickly ( without a through look ) dismissed it
<imbrandon> maybe wrongly but i did
<imbrandon> ;)
<bryceh> ok
<Sarvatt> imbrandon: since you're on 855 there are some promising kernel changes that are much too invasive to backport right now that might fix things up too, i can dig you up a link and I think Geir has made kernel debs out of it
<bryceh> I'll have to firm it up
<imbrandon> Sarvatt: k
<imbrandon> bryceh: k
<imbrandon> bryceh: if there is anything else i can do wiki wise lemme know, i'm more than willing to help, just a bit behind the X curv, untill today its always "just worked" for me since warty on all my hardware ;)
<Sarvatt> karmic worked?
<imbrandon> well there was that one thing in early dapper but that bit everyone ;) shhhh
<Sarvatt> using the kernel in karmic is an option :)
<imbrandon> Sarvatt: yea, karmic worked like a charm on this laptop for months
<imbrandon> Sarvatt: hum, never thought about that
<bryceh> imbrandon, cool, yeah we could definitely use help improving the wiki pages at wiki.ubuntu.com/X, especially the Troubleshooting section
<bryceh> imbrandon, a lot of what we need help with is just basic copyediting.  I tend to be overly verbose in my wordings so a second set of eyes to boil stuff down to simplify it would likely improve it
<imbrandon> so just to be clear in my head here, is this a kernel problem or an intel/X problem or a mix
<imbrandon> lol
<bryceh> less is more, 'nat
<imbrandon> bryceh: cool, i can do that
<Sarvatt> mostly the kernel
<imbrandon> ok so if i un-backlist that module ( just to be clean ) and install the latest karmic kernel ( via apt pinning ) i "should" be ok ?
<imbrandon> and obviously boot form it via grub
<Sarvatt> possibly :)
<imbrandon> that is assuming karmic worked for me , that might be an option for the general public too since karmic will be supported kernel wise for a nother year, hum
<imbrandon> apt pinning is a bit above most ppl but i bet it could be made easy via a wiki
<Sarvatt> don't need to pin anything, just have to select it from the list in grub :)
<imbrandon> Sarvatt: hum true, i forget kernel is one that can be installed side by side
<imbrandon> ok let me try that next, if that dont work i'll go down the fbdev route
<imbrandon> Sarvatt: how can i tell what -video driver i have loaded ?
<Sarvatt> /var/log/Xorg.0.log should make it obvious
<imbrandon> ok bbiab, gotta get the kids from school
<bjsnider> Sarvatt, what's the deal with poulsbo on lucid?
<bryceh> Sarvatt, while I finish up this xorg-server upload... any other changes you know of which we know we need?
<bryceh> bjsnider, no deal at the moment
<bryceh> bjsnider, use vesa, unless you feel like working on porting over the mandriva psb kernel patches
<bjsnider> mandriva is using an old x server
<bryceh> sorry I meant s/mandriva/meego/
<imbrandon> back
<imbrandon> well both the old kernel and kms+fbdev both are good worksarounds
<imbrandon> bryceh Sarvatt ^^
<imbrandon> bryceh: i'll touchup over the wiki some this evening after everyone is asleep in the house and I can concentrate a bit more
<bryceh> imbrandon, great, thanks :-)
<bryceh> gahh, writing up srus is so time consuming....
<bryceh> Sarvatt, RAOF, xserver uploaded, sru's filed.  3 fixes included.
<bryceh> and git pushed
<BUGabundo> iihhhh
<BUGabundo> I see we are going to have huge updates post release
 * BUGabundo refreshs SRU page
<bryceh> BUGabundo, are you complaining?
<BUGabundo> I'm not
<BUGabundo> I'm use to it
<bryceh> yeah it's pretty standard operating procedure, esp. for an LTS
<bryceh> if anything I think it's going to be light compared with hardy, at least for X stuff.  But we'll see.
<BUGabundo> ehe
<BUGabundo> well, the 6th ill upgrade to 10.10
<bryceh> good man :-)
<BUGabundo> some one must keep tabs on your guys works 
<bryceh> imbrandon, Sarvatt, I've refactored https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes to hopefully be less generic
#ubuntu-x 2010-04-29
<bryceh> imbrandon, Sarvatt, please review that page and if you can spot ways to improve it please edit
<RAOF> bryceh, Sarvatt: Yeah, that ubuntu-lucid branch is an attempt to pull back glx 1.4 without the clutter crash or memory leak, particularly if we found that somethings had come to depend on 1.4.  I didn't want it only sitting on my local system. :)
<bryceh> morning RAOF
<RAOF> Good morning
<imbrandon> bryceh: cool will do here very shortly
<bryceh> RAOF, fwiw what I've done in such situations in the past is chunk it into a ppa
<bryceh> that way it's available/backedup and easy to test
<bryceh> (which I'm sure has already been done in this case)
<RAOF> Yup :)
<Sarvatt> bryceh: will look it over in a bit, been working 
<Sarvatt> bryceh: btw mandriva does have xserver 1.7/2.6.32 support for poulsbo now, thats what someone linked a day or two ago
<Sarvatt> and holy crap the package infrastructure for poulsbo is nuts, 7-8 packages?
<RAOF> How do they manage that?
<Sarvatt> http://blino.org/blog/mandriva/poulsbo-xserver1.7.html
<RAOF> Kernel module, DDX, maybe libdrm extensionâ¦
<Sarvatt> then xserver libglx and libdri in seperate packages too..
<RAOF> And then mesa driver, presumably.
<RAOF> That's still 6 :)
<Sarvatt> yup and firmware
<RAOF> Ah, of course!
<bryceh> sheesh
<Sarvatt> psb-firmware xserver-xorg-video-psb libdrm-psb psb-kernel-source xpsb-glx libgl1-mesa-dri-psb and a change to libdrm for psb symbols
<Sarvatt> just needs packaging changes to work with alternatives and to drop a load of patches on most parts, the tarballs are still the same old ones from hardy
<bryceh> I say Mandriva can win -psb
<Sarvatt> hah I said "just"
<Sarvatt> if anyone has a psb netbook they can bring to UDS I can probably be convinced to make it all work there :)
<bryceh> Sarvatt, you could put a call out on ubuntu-devel@
<bryceh> Sarvatt, or ask tseliot, he probably knows how to get one for testing
 * bryceh hrms at 5bug #68779
<RAOF> Has the flock of canaries patch made it into upstream yet?  Those users seem quite happy with the 2.6.34-rc5 kernel daily packgaes.  Let's checkâ¦
<bryceh> RAOF, what are your thoughts on bug #568779 ?
<ubottu> Launchpad bug 568779 in xserver-xorg-video-intel "[i855] 10.04 rc boots into black/blank screen" [Undecided,Confirmed] https://launchpad.net/bugs/568779
<RAOF> It's a bit scattered, isn't it?  We knew that there were going to be *some* pepole with 855 cards who'd have problems.  This will end up being a duplicate of bug #541511, won't it?
<ubottu> Launchpad bug 541511 in ubuntu-release-notes "MASTER: [i855] GPU lockup (apport-crash)" [Undecided,Fix released] https://launchpad.net/bugs/541511
<bryceh> RAOF, yeah probably
<RAOF> Some get fixed by re-enabling kms, some get fixed with vesa, someâ¦ :(
<jg>  a random walk through an N dimensional space.
<RAOF> Not guaranteed to end up at the starting position.
<jg> yup.
<jg> RAOF, or even terminate, as I saw in beta 2.
<jg> Thankfully, I get a new toy tomorrow, and won't care much anymore about the RS600 POS.
<jg> new laptop is somewhere in the air between Louisville, KY and Boston at this instant, according to UPS.
<bryceh> if only manufacturers would stop making new hardware, it would make our lives so much easier
<jg> bryceh: heh.  I may have a different set of problems, but I can get keithp to fix them if I do ;-).
<jg> first time I've gotten to select my own laptop in 3-4 years.
<jg> bryceh: note my RS600 problem is hardware that I got over 18 months ago: it's hardly in the new category.
<RAOF> bryceh: Or even just make new hardware without crazy architectural differences would be nice.  It can't be *that* hard to preserve the modesetting interface across generations, surely :)
<bryceh> if only manufacturers would stop making hardware, it would make our lives so much easier
<bryceh> we have 0 bug reports about the abacus after all
<jg> bryceh: but then you'd be stuck with old braindamage forever, which is equally bad and frustrating.  You'd have to support broken POS for aeons, rather than merely half a decade or so.
<jg> bryceh: for example, trying to make mode setting work on old ISA cards would be a unique form of water torture.
<bryceh> ok
<bryceh> if only manufacturers would stop making old hardware, it would make our lives so much easier
<jg> now that we've gotten rid of all new hardware and all old hardware, we'll all set to use semi-obsolete systems ;-)
<bryceh> jg, you know, it's kind of an achilles heel of FOSS, that each year brings an increase to the amount of hardware out there that needs supported, and any upstream change to X risks breaking at least *some* random selection of HW
<jg> bryceh: yeah, and if not enough people care, it stays broken.  I don't think I'll probably cry hard if the RS600 stays broken indefintely, though having the tablet working would be sort of nice...
<jg> would help to have a more obvious business model on the desktop side to enable funding of random hardware maintenance, though.  There are times FOSS's business models are insufficient, at least at current scale.
<jg> now 10x the desktop/laptop market share would go along way toward fixing that problem.
<bryceh> yeah, the business model seems to work well enough for when someone is actively selling the bit of hardware, since money flows  consumer -> hw manufacturer -> OS vendor
<jg> as we have on the server side, for quite a while.
<jg> Still hard on the desktop side, though not as dismal as it used to be.
<bryceh> but when its hw no longer being sold, there isn't $$ flowing around, since the OS can be had without purchasing it, so support is entirely OSV good will
<jg> bryceh: yeah, server production deployments force that on the server side.
<bryceh> right, where service contracts are purchased, there is a money flow
<jg> RH is based on that...
<bryceh> on the desktop it seems users aren't accustomed to buying technical support contracts or whatever
<bryceh> I'd say 9 out of 10 bug reports that we see on X would really probably be better classified as tech support requests (well, 'help requests' at least)
<jg> bryceh: the microsoft ecology is that there is no real support available other than the local IT guys, child or  neighbor; you just throw out the machine and buy a new one if you ever upgrade it.
<jg> ever try to deal with Microsoft to get help with any of their software?
<bryceh> heh true enough
<jg> I went through *five* releases of Microsoft Word, unable to reliably convert a document to plain ascii, and couldn't get them to fix it, even when I had contacts in the office group who tried to do so for me.
<jg> oh, for the ability to even generate a stack trace to be able to give them......
<bryceh> given that, it amazes me how outraged bug reporters get when someone doesn't reply to their bug report right away
<jg> bryceh: you are dealing with the lunatic fringe of people, in several dimensions.
<jg> unless you are a very big microsoft customer, with a really serious bug, it's almost impossible to get them to pay attention, even if you have "support".
<jg> most of the support that isn't "community" is forced back on the hardware vendors who supply the crack to the addicts.
<jg> I'm amused, 8 years later, that HP is buying a company that does Linux based handhelds.  The lack of vision is stunning.
<jg> 8 years ago, the only Linux handhelds were HP iPAQ's, period, done by HP/former Compaq people.
<jg> maybe it's 10 years now.
<bryceh> heh
<jg> now, if they'd given us 10 % of the 1.2 billion they are playing for Palm, they might be somewhere in phones or handhelds.
<rafiyr> Someone actually bid on palm?
<jg> If I'm bitter, just ignore me.
<jg> yes. HP.
<rafiyr> Guess I should look at the news once in a while.
<jg> http://www.nytimes.com/2010/04/29/technology/29palm.html?ref=global-home
<jg> instead, they cleverly laid off everyone who had caused the first linux handheld devices to run Linux....
<bryceh> jg, very penny-wise of them
<jg> heh.  pound foolish, and took pounds out of keithp's and my hide, among others.
<jg> (like jamey hicks, and andrew christian and so on).
<jg> well, good night; hopefully I wont have too many adventures with my nice new laptop tomorrow....
<bryceh> night
<vish> Sarvatt: hi.. I'm using the mainline kernel .33 and it doesnt seem to require the quirk new_pll=0  [RV515]
<vish> 2.6.33-02063303-generic
<vish> hmm , is KMS on by default in mainline kernel.. how do i check?
<RAOF> Does /sys/bus/pci/devices/$YOUR_CARDS_PCI_ADDR/controlD exist?  If so - you're using kms.
<RAOF> I'd expect kms to be on by default in the 2.6.33 mainline kernel; I haven't checked though.
<RAOF> You can also check /var/log/Xorg.0.log; drivers tend to say whether they're using KMS
<vish> yeah , the /var/log/Xorg.0.log  shows   (II) [KMS] Kernel modesetting enabled.
<RAOF> Oooh!  I just saw one of those thinkpad x200s+compiz powersave=1 sync flashes!  My hardware *isn't* totally unaffected :)
<ara> do you guys think this bug should be an xorg one instead? 
<ara> bug 569214
<ubottu> Launchpad bug 569214 in ubiquity "Ubuntu 10.04-rc desktop installer unreverable error" [Undecided,Incomplete] https://launchpad.net/bugs/569214
<bryceh> ara, impossible to say without more info.  if they're using i855 graphics it could be just a dupe of the 8xx kms bug
<ara> bryceh, ok, thanks
<Sarvatt> vish: really? do you have any idea when the flickering started with the ubuntu kernels?
<Sarvatt> vish: do you have the 2.6.32-19 kernel to try by any chance?
<vish> Sarvatt: i have tried with 32-19 as well , if i use new_pll=0 on boot there is no problem , but the problem arises after ~6hrs 
<vish> , seems it runs out of magic
<Sarvatt> interesting, how about 2.6.32-16? that one should be a clean backport of 2.6.33's drm
<vish> Sarvatt: but with .33 i'm not using new_pll=0 and after~19hrs I dont have *any* problems
<vish> yeah , thats -16 was the next thing i wanted to test.. havent tested it yet..
<vish> was actually expecting problems with .33 , surprising  , /several/ problems seem solved.. 
<Sarvatt> is it 2.6.33 with a karmic config or a lucid config?
<vish> lucid one
<Sarvatt> ah its karmic, they didnt make any 2.6.33's with lucid's config
<bryceh> sweet, there's a cache coherency patch
<Sarvatt> vish: 2.6.32-16 would be really interesting if you could test it, if that fails then the problem is outside of drm 
<vish> Sarvatt: isnt this the lucid one?  > http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.3-lucid/
<vish> thats the one i'm using
<Sarvatt> oh thats totally different, we dont have .3 yet in lucid
<Sarvatt> that means your problem will be fixed by the next SRU :)
<Sarvatt> awesome
<vish> yay! :)
<Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.3-lucid/CHANGES
<Sarvatt> something in there fixed it
<vish> Sarvatt: just curious ,which kernel did you mean initially?  [i thought those were the only mainline ones]
<bryceh> Sarvatt, have you packaged kernel patches before?
<Sarvatt> you said 2.6.33 and i didnt look at the kernel version you posted to notice it was 2.6.33.3
<Sarvatt> bryceh: not in a PPA :(
<bryceh> hmm
<vish> ah , cool
<bryceh> some day I need to learn that
<Sarvatt> i dont know how to bump the abi right for a PPA
<Sarvatt> yeah same here
<Sarvatt> been saying that for months now but i never get around to it :)
<Sarvatt> vish: just curious, how is your monitor connected?
<Sarvatt> oh wait its a laptop isnt it
<vish> yeah , Acer laptop
<Sarvatt> just ruling out commits that it could be
<bryceh> Sarvatt, oh... this patch is just the "This is the most horrible hack I've ever written" patch we already knew about
<bryceh> (I think, lemme doublecheck)
<Sarvatt> bryceh: 2.6.33.3 fixes PAL tv problems with KMS, wrong gamma values with radeon when using a DVI-VGA adapter, washed out images over tv out on radeon - bug 548709 
<ubottu> Launchpad bug 548709 in linux "[R423] gamma bug, display too bright when using DVI-VGA adapter [patch]" [Medium,Triaged] https://launchpad.net/bugs/548709
<bryceh> great
<Sarvatt> i've seen bugs for all of those but have to dig them up
<Sarvatt> noting on that bug that its fixed in 2.6.33.3
<Sarvatt> vish: I have no idea what fixed it in your case..
<Sarvatt> hopefully it's not some agp or pci problem that wont be in the next kernel :(
<vish> Sarvatt: do you want me to test 32-16 too?
<Sarvatt> nah that was just because I thought you were saying the 2.6.33 kernel fixed it
<Sarvatt> (not 2.6.33.3)
<vish>  this 33.3 is totally awesome! :D  i earlier had minor memory problems , songs used stutter when wallpaper changed , and all sorts of things.. but now *poof*!  
<vish> xorg cpu would just spike fo 2secs when wallpaper changed
<vish> for*
<Sarvatt> i hope http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=ae2e767a2b2be23d6131cf463f3de730014dc070 isn't the cause of that cus that patch isn't upstream, they reverted it because of problems..
<Sarvatt> vish: do you have the bug number for your flickering problems handy by any chance?
<Sarvatt> it's against linux so i'm having problems finding it in the noise with my slow net connection
<vish> Sarvatt: i didnt file one separately since you mentioned it was a known bug..
<Sarvatt> yeah i thought you might be subscribed to it or something, no worries
<vish> Sarvatt: i think this is the one closet to mine > Bug #541501
<ubottu> Launchpad bug 541501 in xserver-xorg-driver-ati "[RV515] [LENOVO T60] external screen display shows "shivering", horizontal refresh offset" [Unknown,Fix released] https://launchpad.net/bugs/541501
<Sarvatt> https://bugs.launchpad.net/bugs/570394 -- i need to turn my reply there into a stock reply since most every nvidia bug is just because of that problem :)
<ubottu> Launchpad bug 570394 in nvidia-graphics-drivers "nvidia "glXCreateContext failed"" [Undecided,Incomplete]
<bryceh> Sarvatt, heh
<bryceh> Sarvatt, if that's true, it makes me wonder if we could programmatically identify and dupe those bugs
<bjsnider> man, that fails to make sense. there's no way you can install nvidia-current that it doesn't update the alternatives to use its own glx
<bryceh> Sarvatt, I've sent apw an email asking for a kernel ppa with that patch
 * hyperair quickly gets his fix of xorg-edgers after upgrading to luci
<hyperair> d
<bryceh> Sarvatt, although maybe find a bug that was not filed against kubuntu to dupe against
<Sarvatt> hyperair: finally did it eh? :)
<hyperair> Sarvatt: my exams just ended today =)
<Sarvatt> bjsnider: yeah it's got me wondering too, i'm guessing theres some way of updating that fails to do it currently
<bjsnider> Sarvatt, either the postinst script is failing to run, or another script is running later that's resetting the glx alternative
<Sarvatt> like installing after having installed the drivers from nvidia.com manually at some point with files left behind or something else that people forget to mention in bug reports :)
<hyperair> Sarvatt: so.. now that hal is gone, how do i configure my synaptics things?
<bjsnider> Sarvatt, well, they could be lying about that, yes.
<Sarvatt> hyperair: easiest way is to just edit /usr/lib/X11/xorg.conf.d/whatever-synaptics.conf and add Option "foo" "whatever"
<hyperair> Sarvatt: not /etc?
<Sarvatt> yeah I know its bad advice to tell people to edit that but its the easiest :)
<jcristau> hyperair: /etc/X11/xorg.conf
<Sarvatt> hyperair: correct way would be to just add the options to xorg.conf
<hyperair> Sarvatt: aah okay, thanks.
<jcristau> hyperair: add a InputClass section with MatchIsTouchpad "on"
<hyperair> jcristau: thanks
<jcristau> and whatever options
<hyperair> aha. i see why my touchpad was acting weird now.
<Sarvatt> man synaptics has all the options and man xorg.conf tells you the structure
<hyperair> for some reason, xserver-xorg-input-synaptics got removed during upgrade
<hyperair> this was the most borked upgrade of ubuntu i've ever had
<Sarvatt> oh wait you're on edgers so it's /usr/share/X11 anyway :D
<Sarvatt> hyperair: hope you used ppa-purge xorg-edgers before upgrading..
<hyperair> Sarvatt: i didn't. *groan*
<Sarvatt> i put a big fat warning on the page about that
<hyperair> Sarvatt: the difference is... i don't heed warnings =D
<hyperair> no, what i really meant is i know enough to recover from borked upgrades
<Sarvatt> ppa removal seriously needs  happen in the update process instead of just disabling PPA's
<hyperair> the hit-or-miss part is making sure the system still boots after upgrade
<hyperair> after that i'm fine \o/
<Sarvatt> i dont know where to start hooking it in
<hyperair> hooking?
<hyperair> ah
<hyperair> yes, that's true.
<hyperair> you should talk to mvo about this.
<Sarvatt> hyperair: good thing you reactivated xorg-edgers right after upgrading because things would have been horribly broken :)
<Sarvatt> mesa is totally different in lucid
<Sarvatt> and the karmic version is higher
<hyperair> Sarvatt: er no actually..
<hyperair> Sarvatt: i didn't. X worked by chance.
<hyperair> Sarvatt: right now i'm still downloading PPA packages
<hyperair> 162 of them @_@
<Sarvatt> with no GL i'm sure :)
<Sarvatt> hyperair: were you using the blob or is that your intel machine?
<Sarvatt> curious if the nvidia-current in xorg-edgers works, haven't tried it yet
<hyperair> Sarvatt: this is my intel machine.
<hyperair> Sarvatt: my nvidia machine is several hundred miles away
<Sarvatt> bryceh: scanning xorg.0.log on all nvidia-graphics-drivers bugs for (II) Loading /usr/lib/xorg/modules/extensions/libglx.so as candidates for the stock reply would w ork :)
<Sarvatt> ahh back to work i go
<Sarvatt> what are the useful logs from a release upgrade again?
<Sarvatt> asking the person  in that nvidia bug if he can attach them and hopefully see where it went wrong. /var/log/apt/term.log and /var/log/dpkg.log? wasn't there another log or two just for the dist release process?
<jcristau> mvo would probably know
<Sarvatt> hmm wonder if its possible /usr/lib/xorg/extra-modules doesn't exist at the point where its setting up the alternatives
<Sarvatt> libgl1-mesa-glx is what makes it
<Sarvatt> oh weird nevermind, mesa is making /usr/lib/xorg/x11-extra-modules
 * Sarvatt is confused
<Sarvatt> what the heck is  /usr/lib/xorg/x11-extra-modules, xorg-server only checks  /usr/lib/xorg/extra-modules additionally
<bryceh> dunno
<bryceh> Sarvatt, I used my new script to grep out all the nvidia-graphics-drivers bugs with that libglx.so path in them
<bryceh> :-)
<bryceh> looks like it flagged a couple dozen bugs, I'm going through them now
<bryceh> some it appears were filed against nvidia-graphics-drivers but the user booted into an open source driver to file the report, so not all are actually dupes of the alternatives bug
<bryceh> also, I'm thinking I should set up a MASTER bug report for this, as none of these flagged bug reports are really that well made
<bryceh> well, maybe they're dupes of bug #522328
<ubottu> Launchpad bug 522328 in nvidia-graphics-drivers "[Test xpr-008] Lucid upgrade broke when upgrading from manually installed nvidia proprietary drivers" [High,Triaged] https://launchpad.net/bugs/522328
<Sarvatt> good idea! having them all in one place will make finding out the problem easier since i cant seem to reproduce it, wish tseliot was around to pick his brain because the alternatives are a maze. really want to see someones dpkg logs from when they upgraded  to see what order things went in. anyone have a karmic machine they are about to upgrade to lucid that could reproduce? :)
<bryceh> yeah I've been a bit disappointed he hasn't been that active here this release
<bryceh> yeah I'm going to use #522328 as the master for this, I don't want to own this bug ;-)
<Sarvatt> bryceh: Failed to initialize the GLX module; please check in your would be a better string to search for
<Sarvatt> would only be in these specific bugs
<bryceh> oh
<bryceh> rats...
<bryceh> alright rerunning...
<Sarvatt> wait what the heck, just realized this guys log has timestamping - (EE) Apr 26 20:59:18 NVIDIA(0): Failed to initialize the GLX module; please check in your X
<Sarvatt> ahh ok the nvidia messages all have timestamping even if the rest of the log doesnt
<bryceh> ahh
<bryceh> weird
<bryceh> wish the script didn't take so long to run...
<Sarvatt> /usr/lib/mesa/ld.so.conf - priority 500
<Sarvatt>  slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules
 * bryceh drums fingers
<Sarvatt> i dont understand the x11-extra-modules, xserver is only set up to look in extra-modules additionally
<Sarvatt> oh i guess the alternative links that to extra-modules?
<Sarvatt> fglrx uses  slave xorg_extra_modules: /usr/lib/fglrx/xorg
<hyperair> Sarvatt: ...i get GPU hangs. whee.
<Sarvatt> whee!
<Sarvatt> sudo ppa-purge xorg-edgers and see if it happens on lucid, hope not!
<Sarvatt> ok i dont think its related to xorg_extra_modules because nvidia_drv.so is in there too and thats loading
<Sarvatt> which means the alternatives for nvidia are getting set up properly in the first place, hmm
<bjsnider> then something is coming along after and changing them
<Sarvatt> nvidia_drv.so wouldn't load if extra-modules was pointing at the mesa version for some reason
<Sarvatt> libglx should be in extra-modules right next to nvidia_drv if i'm not mistaken
<bjsnider> it would have to be a xserver-xorg package that's installed after the nvidia-current package
<bryceh> Sarvatt, hmm, not getting any results from the new search string
<Sarvatt> dunno about that because xserver tries to load from extra-modules before the normal one, I think it might just be hitting people reusing an old xorg.conf with something odd in it
<Sarvatt> oh yeah
<Sarvatt> i think i know what it is
<bjsnider> why would the sorg.conf file have anything to do with alternatives?
<Sarvatt> crap clients home, gotta run to the next job but i'll be back soon, i know what the problem is
<Sarvatt> its the depth section not being in xorg.conf
<Sarvatt> i had the same problems when i was trying to autoload nvidia without an xorg.conf
<Sarvatt> if you dont have depth 24 it wont load nvidia's libglx and uses the servers
<bjsnider> DefaultDepth	24?
<Sarvatt> yeah
<bjsnider> so they used nvidia-xconfig to create the xorg.conf?
<Sarvatt> need to go through the other bugs and compare xorg.conf, might be another option screwing that up like the argbvisuals
<bryceh> "Failed to initialize the GLX module" not turning anything up so far... I'll let it keep running though
<bjsnider> i'm going to try nvidia-xconfig right now and see if it puts that in there
<bjsnider> nvidia-xconfig puts defaultdepth 24 in there too
<hyperair> okay, it can't be a gpu hang. i can switch VTs once.
<hyperair> Sarvatt: BAH. xserver-xorg keeps hanging >_>
<hyperair> blargh. why can't i switch VTs once X hangs in lucid?
<bryceh> because it's probably hung in the kernel
<hyperair> hmmm
<hyperair> but why didn't this kernel have issues with xorg-edgers of karmic?
<Sarvatt> looks like my last message didn't go through, but in https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/570394 they have 	Modulepath	"/usr/lib/xorg/modules" making it so /usr/lib/xorg/extra-modules doesn't get used
<ubottu> Launchpad bug 570394 in nvidia-graphics-drivers "nvidia "glXCreateContext failed"" [Undecided,Incomplete]
<bjsnider> Sarvatt, they have a modulepath line in the xorg.conf file?
<Sarvatt> yup
<bjsnider> where in the world...
<bjsnider> where are they getting these crazy xorg.conf files
<Sarvatt> me? lol
<bjsnider> maybe nvidia=xconfig was doing this years ago?
<Sarvatt> old nvidia-xconfig and dpkg-reconfigure xserver-xorg
<bryceh> Sarvatt, 537648 and 570394 were the only bugs that matched that search string
<Sarvatt> thats new, File descriptor 3 (pipe:[141203]) leaked on lvs invocation. Parent PID 29395: /bin/sh when updating grub
<Sarvatt> bryceh: ahh ok, both are absolutely the same issue with an invalid xorg.conf
<Sarvatt> whats the right place to have the Section "Files" section in xorg.conf removed on upgrade?
<Sarvatt> # nvidia-xconfig: X configuration file generated by nvidia-xconfig
<Sarvatt> # nvidia-xconfig:  version 1.0  (buildmeister@builder75)  Fri Mar 12 01:42:27 PST 2010
<Sarvatt> heh nvidia-xconfig might still be making that invalid xorg.conf..
<Sarvatt> http://launchpadlibrarian.net/42386210/XorgConf.txt
<Sarvatt> nope, it kept it around from an old xorg.conf when you run it, just ran it and it didn't
<Sarvatt> ok *something* relatively current is making that xorg.conf with the modulepath set in it at least, this guy had a fresh install of lucid at alpha 3
<Sarvatt> nah he put it there himself cut and pasted from somewhere else and ran nvidia-xconfig after looking at the options
<bryceh> Sarvatt, probably just close as invalid or convert to a question
<Sarvatt> yep closed them all
<bryceh> cool
<bryceh> bug 494625 can be made into a standard "your xorg.conf settings aren't right" master bug
<Sarvatt> ugh tons of bugs from nvidia people saying visual effects goes back to none after activating nvidia-current!!!!111
<ubottu> Launchpad bug 494625 in nvidia-graphics-drivers "-nvidia requires settings in xorg.conf else it won't work" [Wishlist,Triaged] https://launchpad.net/bugs/494625
<Sarvatt> (it requires a reboot and isn't supposed to work right away goobers!) :)
<bryceh> sounds like another master bug
<Sarvatt> do we have a proprietary drivers wiki?
<bryceh> not really, we've got some bits and pieces in the troubleshooting pages
<bryceh> would be nice to have though
<Sarvatt> i'll start writing up common issues
<Sarvatt> http://sarvatt.com/downloads/propdrivers.txt
<Sarvatt> got that so far
<bryceh> looks good
<bryceh> maybe better than a wiki page would be just to have master bug reports for each issue
<bryceh> that'd make bug duping a bit simpler, and then we can track the status of the issues
<Sarvatt> works for me, trying to find more common issues to add
<bryceh> 570498 - installation fails when your disk is out of space (duh!)
<Sarvatt> hehe
<Sarvatt> hope you dont mind i'm marking it invalid... :D
<bryceh> no prob
<bryceh> or move to questions
<bryceh> wow, making good progress squishing nvidia bugs, down to 137 :-)
<Sarvatt> the answer is you need space on your partition to install a package, I would hope thats obvious enough not to have to make a question out of it :)
<bryceh> heh
<Sarvatt> added a few xorg.conf options to that propdrivers.txt that fix a few other bugs i've come across
<Sarvatt> i need to use that  Option "UseEvents" "false" option personally, otherwise i get lots of stalls on my 8400M GS
 * bryceh closes out a mess of kubuntu -nvidia bugs with no stack traces provided
<Sarvatt> a lot of them are probably karmic too, nvidia-graphics-drivers seems to be the dumping ground kubuntu guys use even though the right package is nvidia-graphics-drivers-180 on karmic :)
<bryceh> yep
<bryceh> 564129 was the only one with a decent stacktrace, so I left it
<bryceh> 128
<Sarvatt> wish these kde bug logs weren't useless
<Sarvatt> people have problems running apport-collect usually on these ones dumped over from kde ones saying no new information to add
<Sarvatt> nothing we can do with just a dependency list and the backtrace thats usually all in qt functions
<bryceh> mm, search page on launchpad shows there's now an Expired state
<Sarvatt> nice!!
<Sarvatt> nVidia driver scrambles Usplash (on lucid)
<Sarvatt> kaay
<Sarvatt> thats either plymouth or vga16fb's fault anyhow, not nvidia-graphics-drivers
<bryceh> yep
<Sarvatt> if you set something wontfix, it requires someone in bugcontrol or core-dev to change the status right?
<Sarvatt> I'm eyeing https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/565980 which is likely to get changed even though they dont like the response :)
<ubottu> Launchpad bug 565980 in nvidia-graphics-drivers "low resolution in plymouth screen with nvidia-current" [Undecided,Won't fix]
#ubuntu-x 2010-04-30
<RAOF> Sarvatt: Yup; that got changed recently.  People now shouldn't be able to switch from wont fix if they can't switch to won't fix.
<Sarvatt> sweet, just wish you could keep things marked fix released at the same status because there are *tons* of people reopening and reclosing the gem memory leak bug
<Sarvatt> not saying anything, just changing the status to fix released - fix commited and fix commited - fix released in one go, probably spamming for karma :)
<bryceh> Sarvatt, yeah I filed a usability bug against launchpad about that one
<bryceh> good god, I've never seen a bug with so many dupes - #507062
<Sarvatt> sooo
<Sarvatt> linux-headers-generic | linux-headers
<Sarvatt> nvidia-current requires that
<RAOF> I *think* there may possibly be a fix for thatâ¦ why haven't I pointed that bug at my aubergine ppa?
<Sarvatt> if someone has -generic headers installed but is using the -generic-pae kernel without -generic-pae headers installed they are screwed :)
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/569237
<ubottu> Launchpad bug 569237 in nvidia-graphics-drivers "package nvidia-current 195.36.15-0ubuntu2 failed to build on pae kernel: Could not determine kernel version" [Undecided,New]
<RAOF> Sarvatt: Right.  I'm pretty sure there is no way of ensuring that the user has the appropriate headers installed through dpkg.
<bryceh> RAOF, you mean #507062 ?  
<Sarvatt> indeed, another one for the prop drivers notes
<RAOF> bryceh: Yeah.  #507062.  I'm not sure if it's a fix, but the upstream âmake the bits of Xlib that are meant to be threadsafe *actually* threadsafeâ branch fixes a bunch of similar errors.
<bryceh> ah
<bryceh> yeah this sounds familiar, we've had threading issues in xcb before
<RAOF> So, not at this point a fix that's remotely SRUable :)
<bryceh> RAOF, shall I assign this one to you?
<RAOF> bryceh: Yeah, go for it.
<bryceh> we had one just like this in hardy, I'm having flashbacks
<bryceh> there were workarounds that could be applied to foss apps, but we never did get the proprietary apps sorted
<bryceh> and that bug stuck around like a thorn forever.  maybe it's still open
<RAOF> Possibly as a dupe of this one? :)
 * bryceh goes ahuntin
<bryceh> 419501 maybe?
<RAOF> âSelected text itemâ + âFind launchpad bug by nubmerâ in Do is Love.
<Sarvatt> bug 507062
<bryceh> bug #419501
<ubottu> Launchpad bug 507062 in libx11 "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed." [High,Incomplete] https://launchpad.net/bugs/507062
<ubottu> Launchpad bug 419501 in gasp-core "apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed." [Critical,Fix released] https://launchpad.net/bugs/419501
 * Sarvatt just wanted a link
<Sarvatt> ah yeah bryceh thats because the error is basically, X crashed underneath me and I couldn't connect
<bryceh> mm
<RAOF> bryceh: Yeah.  I've posted the PPA on that, and it doesn't seem to totally fix everything :).  It *does* fix the âico -threads 10â testcase.
<bryceh> ah yes I see
<bryceh> actually 419501 isn't the one I was thinking of
<bryceh> however I see shuttleworth asked me a question there that I didn't answer.  whoops.
<Sarvatt> whoops!
<RAOF> :)
<Sarvatt> xorg-edgers also has all of the libs and xcb updates that were added to possibly fix it, that was the main reason i rebuilt everything in there
<RAOF> Sarvatt: You built from the branch, or has that been merged now?
<Sarvatt> ah no i didnt build the multithreaded xcb stuff, just the mass of libs that got updated to only call XAllocID with the display lock held
<Sarvatt> there were 8 or 9 libs that were potentially where the problem was coming from
<bryceh> heeeeere we go.  bug #232364
<ubottu> Launchpad bug 232364 in xfce4-utils "dbus-launch hangs at session start waiting on socket output in libxcb" [Critical,Fix released] https://launchpad.net/bugs/232364
<Sarvatt> libXi libXext libXtrap libXrender libXfixes libXdamage libXcomposite -- guess I overcounted
<bryceh> we figured out that with open source stuff that the order that you start things up could mask the bug (comment #48) so we did that where we could (i.e. no solution for proprietary apps) and left it at that
<Sarvatt> they all had non-threadsafe functions though
<Sarvatt> http://lists.freedesktop.org/archives/xorg-commit/2010-April/date.html -- search the page for libXcomposite: Changes to 'master'   Jamey Sharp
<Sarvatt> thats where the updates were
<Sarvatt> sheesh, friend can't boot the livecd on 3 of his machines with older nvidia cards, gogo nouveau!
<Sarvatt> 7900GS 7800GT 7800GTX all dont work :(
<RAOF> Sarvatt: That makes me a sad panda.
<RAOF> Is modesetting so hard that it needs to break across cards in the same generation?!
<bjsnider> those cards aren't particularly old
<bjsnider> i wonder what ben skeggs would say about that
<bjsnider> use fedora, probably
<RAOF> I wonder if you can boot fedora on a MacBook Pro 5,x :)
<bryceh> RAOF, only if you contribute to upstream, you insensitive clod!!
<Sarvatt> I asked him to boot fedora 13 to see if it worked, I'm going to go out on a limb and say it will since we have a crapload more nouveau backports than they do :)
<Sarvatt> err we have less I meant
 * Sarvatt is eyeing the phantom tv out problems on 7xxx series that they are working around..
<bjsnider> people can criticize ubuntu for that and also poulsbo
<RAOF> Sarvatt: They don't so much have nouveau backports as they've pulled in nouveau/linux-2.6 :)
<RAOF> That's a valid point though: we currently don't distinguish between
<RAOF> "connected but with broken EDID" and "disconnected".  I think it sounds
<RAOF> reasonable to treat the former as connector_status_unknown instead.
<RAOF> That way, if nothing else is connected, X will still light you up at the
<RAOF> fallback size.  OOOH YES PLEASE.
<RAOF> *That's* something to track and ensure it gets into Maverick :)
<Sarvatt> bjsnider: at least thats a valid criticism, poulsbo isn't exactly something ubuntu specific..
<Sarvatt> hmm, wonder if i should munge the drm symbols and module name for psb-kernel-source so it doesn't interfere
<Sarvatt> noone here using psb eh..?
 * Sarvatt wants to make sure the kernel module is right before doing all of the rest of the packages
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/psb
<Sarvatt> oh hmm packaging needs a lot more work, no point shipping psb-modules and building them
<Dr_Jakob> Hmm is anybody running any gallium based DRI drivers on Ubuntu 9.10.
<Dr_Jakob> ?
<Sarvatt> there's probably people on phoronix doing it, xorg-edgers doesn't have it at least
<Dr_Jakob> Hmm ok
<Dr_Jakob> I'm just trying to diagnose a very weird bug I'm seeing.
<Dr_Jakob> Thanks anyway
<Sarvatt> sorry, I dont have any systems on karmic to test :(
<Sarvatt> woo 6 day queue for PPA builds
<jcristau> Sarvatt: by then people will have started flooding the archive with m stuff, so ppa will fall even more behind? :)
<Sarvatt> I know I will be adding to that too :)
<Sarvatt> already switched to maverick here
<hyperair> Sarvatt: maverick!
<hyperair> Sarvatt: say, how did you get around your initrd+make-kpkg issues?
 * hyperair is compiling a new kernel right now and is interested to know
<Sarvatt> sudo update-initramfs -c pointing at the installed kernel and update-grub
<BUGabundo> ALREADY?
<Sarvatt> think i have to add the initrd line to grub manually too, can't remember since i haven't done it in a few months
<BUGabundo> there's no tool chain yet
<BUGabundo> is there?!?
<Sarvatt> its all copied over from lucid right now
<BUGabundo> ahhh
 * BUGabundo seds source.list
<BUGabundo> here I go
<hyperair> Sarvatt: lolwut
<hyperair> BUGabundo: er there's no maverick in the repository....
<hyperair> Sarvatt: oy april fools was last month.
<BUGabundo>  http://archive.ubuntu.com/ubuntu/dists/maverick/
<hyperair> whut
<BUGabundo> eheeh
<BUGabundo> yes there is
<hyperair> you have to be kidding m
<hyperair> e
<BUGabundo> I changed to lucid on day two
<hyperair> bah!
<BUGabundo> 36h after karmic was released
<BUGabundo> so I'm on time to move to maverick
<hyperair> pfft
<hyperair> my mirror hasn't updated.
<BUGabundo> very few will
<Sarvatt> only archive.ubuntu.com yeah
<BUGabundo> I must use main until alpha1
<hyperair> heh?
<hyperair> why wouldn't thye?
<Sarvatt> hyperair: when you do it that way you have to manually remove the /boot/initrd-whatever for that kernel when you remove the package too
<hyperair> don't they all rsync from archive.ubuntu.com?
<BUGabundo> nope
<hyperair> Sarvatt: oh hell. that sounds really bothersome >_>
<BUGabundo> very few sync devel archive
<Sarvatt> probably needs manual intervention to add the new release to each mirror, no idea though
<BUGabundo> Sarvatt: should I keep a lucid repo for security updates
<Sarvatt> it's only been up a few hours
<BUGabundo> or will everything be pushed to maverick repo ?
<Sarvatt> i just changed the main ones to maverick and left all the -updates -security and stuff on lucid, wont be anything for a few days probably on maverick :)
<BUGabundo> okay
<BUGabundo> its what I usually do
<BUGabundo> I run both repos for several weeks
<BUGabundo> then I must take them out
<BUGabundo> on 7.x something I had clash of packages deps cause of that
<BUGabundo> but I've learned to deal with most of them, by now
<Sarvatt> looking forward to gcc 4.5 though with -march=atom support for kernel building
<BUGabundo> heh
<BUGabundo> my mirror has it http://mirrors.fe.up.pt/pub/ubuntu/dists/maverick/
<Sarvatt> hyperair: honestly it's probably easier to just learn the ubuntu kernel build system for those mainline kernels, thats what i plan on doing next time i need a kernel built. theres a kernel-team git repo with the scripts to build them and doesn't look that complicated
<hyperair> Sarvatt: er actually what i'm worried about is disk space.
<hyperair> Sarvatt: the mainline kernels compile with debug symbols, then strip them
<hyperair> that alone can blow my /home to hell
<Sarvatt> you compile kernels on your encrypted /home??
<Sarvatt> that sounds painful!
<Sarvatt> yeah thats true though, i wasn't thinking about that and it'll be a problem here too
<BUGabundo> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<Sarvatt> only have 10GB on my VPS where I do it and make-kpkg already uses 4.5 or so
<BUGabundo> boooo
<hyperair> Sarvatt: er everything's encrypted and stuffed in lvm
<hyperair> Sarvatt: you don't mean to say you compile everything on tmpfs
<Sarvatt> probably adding 3x to the compilation length there :D
<hyperair> meh
<hyperair> i've got bfs
<hyperair> so kernel compilations do nothing but heat up the comp
<hyperair> compiz, X, and everything else runs as smoothly as ever \o/
<Sarvatt> BUGabundo: oh yeah the maverick kernels have been coming out for awhile now too but just in a PPA -  https://edge.launchpad.net/~leannogasawara/+archive/ppa/+packages
<BUGabundo> fine by me :)
<Sarvatt> nvidia aint going to work for awhile though no doubt
<BUGabundo> let me know when you guys have nvidia blobs or nouveau to test
<Sarvatt> hyperair: http://kernel.ubuntu.com/git?p=ubuntu/kteam-tools.git;a=summary theres those scripts that make the mainline daily kernels
<BUGabundo> I really hope we get better IO with the new kernel
<BUGabundo> the changes done in the last part of the cycle to lucid
<BUGabundo> killed all my IO boost
<BUGabundo> copying stuff is very slow
<BUGabundo> I dropped from over 55MBs ovver e-sata
<BUGabundo> with now impact to my system
<BUGabundo> to 26-30MB/s with my disk IO rendering the system useless
<hyperair> BUGabundo_Bones: use ionice
<bjsnider> BUGabundo_Bones, since when does esata work?
<hyperair> BUGabundo_Bones: and btrfs, or something that doesn't suck as hard with fsync.
<BUGabundo_Bones> hyperair: I already do
<hyperair> =\
<BUGabundo_Bones> bjsnider: for ever? never had *any* prob with it
<BUGabundo_Bones> other then being asked GKSUDO for it
<hyperair> huh? gksudo?
<BUGabundo_Bones> yeah to mount it
<hyperair> er don't you always need root perms to mount anything that's not an external device?
<hyperair> just stick it in fstab
<BUGabundo_Bones> no
<BUGabundo_Bones> usb sticks automount
<BUGabundo_Bones> no prob there
<BUGabundo_Bones> my e-sata disk, all stay umounted
<BUGabundo_Bones> and clicking on the icon, to mount, asks password
<hyperair> so stick it in fstab
<bjsnider> why should a regular user need root permission to mount a filesystem?
<BUGabundo_Bones> but why would I need it for some, and not for others
<BUGabundo_Bones> no idea
<BUGabundo_Bones> I filed it a while ago
<BUGabundo_Bones> no one ever touched it
<BUGabundo_Bones> I stop caring 
<bjsnider> well, at least it's not as bad as fedora, where you have to type in a password every time you move the mouse
<Sarvatt> i just chmod/chgrp the mount point to my account
<BUGabundo_Bones> ahahhahaahahaha
<bjsnider> giving the regular user ownership over /media would solve some of the mount permission annoyance i guess
<BUGabundo_Bones> I can try
 * BUGabundo_Bones goes hacking FS
<BUGabundo_Bones> $ sudo chown bugabundo.bugabundo /media -R
<bjsnider> chown username:groupname /media
<Sarvatt> oops i didn't mean chmod there
<Sarvatt> vish: looks like your problem isnt the same as any of these bugs
<bjsnider> would changing /media's ownership persist after a reboot?
<Sarvatt> vish: 2.6.33.3 didn't fix anyone else on any of the bugs and no one else in them is having the problem on lvds it seems as far as I can tell (they 5 bugs I'm looking at are all external monitor related)
<BUGabundo_Bones> bjsnider: ill know tomorrow
<hyperair> Sarvatt: yay i got it working, with update-initramfs and all. just ln -s everything from /usr/share/kernel-package/etc/kernel/*.d
 * hyperair is off to reboot into new kenrel
<Sarvatt> hyperair: woohoo!
<Sarvatt> it's funny i've been using kernel-package 12.x for over a year and still haven't set it up right :) stopped caring about building my own around the same time
<Sarvatt> if i used my turion machine more i'd be doing it because PHC rocks
<Sarvatt> undervolting atom as low as it'll go makes almost no difference
<Sarvatt> i'll be glad pcie aspm will finally be enabled in MM though, that and force quirking my ata controller into SATA mode were the main reasons I built my own kernels but I figured out how to just edit the efi variables in the bios to change it to SATA mode directly
<Sarvatt> psb is close - http://pastebin.com/yjDNXS0u
<Dr_Jakob> Sarvatt: I die a little bit inside every time somebody says psb.
#ubuntu-x 2010-05-01
<Sarvatt> Dr_Jakob: you and me both.. pretty soon moorestown is going to replace that dread :)
<vish> Sarvatt: should i file a separate bug then? or will the .33.3 drm patches land irrespective of a bug?
<hyperair> wooo maverick has hit the mirrors!
<bryceh> nice
 * hyperair contemplates upgrading
<bryceh> hyperair, you're not running lucid already?
<hyperair> bryceh: running lucid. contemplating upgrading to maverick =p
<bryceh> oh ahhh
<bryceh> well, the next few weeks should be pretty boring
<bryceh> most breakage will come post-UDS
<hyperair> heheh
<hyperair> breakage huh
<om26er> hello everybody! what would be the grub parameter for booting nvidia without KMS
#ubuntu-x 2010-05-02
<Sarvatt> sheesh, people really consider the x.y.0 branches the stable branches for mesa, I'm getting even more worried about xserver in the future :) by the time a branch is considered the stable branch there are 3 branches (like master, 7.8 and mesa_7.7_branch with 7.7.1+)
<raggiskula> uhm, hi
<raggiskula> I just installed 10.04 and my secondary display is disorted
<raggiskula> a bit out of focus, but it looks like this
<raggiskula> http://imgur.com/edtfr
<raggiskula> I'm using the default drivers
<raggiskula> not fglrx
<raggiskula> the display was ok while using fglrx but no 3d where my card is unsuported
<Bernardo> hi all
<Bernardo> I am trying to port Mandriva's patches for the poulsbo driver and xorg 1.7.x, but I am stuck
<Bernardo> It seems to work, the psb module is called, drm initialized and loaded without problems, but DRIScreenInit fails to create /dev/dri/*, and then fails
<Bernardo> I've loaded the psb and the drm modules with debug enabled, and there is no error in dmesg
<Bernardo> anyone can help me?
<bjsnider> how would someone install new software on an ubuntu system that doesn't have internet access?
<BUGabundo> bjsnider: debs?
<BUGabundo> gdeb
<bjsnider> nah
<bjsnider> there's a whole chain of dependencies
#ubuntu-x 2011-04-25
<Inumedia> Anyone know of any settings in X that changes how fast a touchpad will move the mouse?  Not the overall speed but horizontal vs vertical speed.
<bryceh> LLStarks, probably kernel issue; downgrade your kernel until it works, then do git bisect to find what changeset did it
#ubuntu-x 2011-04-26
<alkisg> I'm trying to pass 'us,gr' as the keyboard layouts in Xephyr, but the comma is seen as a parameter separator so it doesn't work:
<alkisg> $ Xephyr :1 -keybd ephyr,,xkbmodel=evdev,xkbrules=evdev,xkblayout=us,gr,xkboptions=grp:alt_shift_togge -ac -reset -screen 1024x600 -query 127.0.0.1
<alkisg> [it gives me this warning]: Kbd option key (gr) of value ((null)) not assigned!
<alkisg> Does anyone know the correct syntax?
<tjaalton> use doublequotes?
<alkisg> I tried them around "us,gr", but I got the same warning (and still not working):
<alkisg> Xephyr :1 -keybd ephyr,,xkbmodel=evdev,xkbrules=evdev,xkblayout="us,gr",xkboptions=grp:alt_shift_togge -ac -reset -screen 1024x600 -query 127.0.0.1
<RAOF> You might need to escape the quotes; it's possible your shell is eating them.
<alkisg> I also tried \", nothing, and I tried to quote the whole command line in '', again no joy
<alkisg> Xephyr :1 -keybd 'ephyr,,xkbmodel=evdev,xkbrules=evdev,xkblayout="us,gr",xkboptions=grp:alt_shift_togge' -ac -reset -screen 1024x600 -query 127.0.0.1
<alkisg> Kbd option key (gr") of value ((null)) not assigned!
<alkisg> Is some other separator acceptable, like e.g. xkblayout=us|gr ?
<alkisg> Ah, got it: $ Xephyr :1 -keybd ephyr,,xkbmodel=evdev,xkbrules=evdev,xkblayout=us+gr:2,xkboptions=grp:alt_shift_toggle -ac -reset -screen 1024x600 -query 127.0.0.1
<tjaalton> how did you figure it out? no manpage even mentions '-keybd'
<alkisg> Yup I know :(
<alkisg> I googled and googled and found some broken examples
<tjaalton> ok
<alkisg> Then 2 hours later I got it working with trial and error :-/
<ScottK> alkisg: It might be useful to file a bug with suggestions for improving the man page while this experience is fresh in your mind.
<alkisg> ScottK: hmm ok, but against which package? the Xephyr man page only lists 3 options, maybe those that are specific to Xephyr itself. Maybe the rest of the options are Xorg options, to be documented in `man X`? But I can't even find "query" in `man X`...
<alkisg> Is "X -query" documented someplace else?
<ScottK> Dunno.  
<tjaalton> Source: xorg-server
<ScottK> There we go.
<alkisg> Ah, "query" is documented in `man xserver`
<alkisg> `Xephyr --help` does show the available TinyX options. So they're just missing from the Xephyr manpage...
<Sarvatt> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110413-natty.html errr nvidia-graphics-drivers-180 is in the archive?
<Sarvatt> been in there since karmic apparently, dont think thats intentional
<bryceh> Sarvatt, yeah was wondering about that myself.  Shouldn't we drop it (or at least close out the bugs)?
<tjaalton> should be removed
<tjaalton> maybe bugbot would then stop reassigning bugs there :)
<Sarvatt> bryceh: did you mean to have a desktopcouch dependency in xdiagnose?
<bryceh> Sarvatt, no
<bryceh> Sarvatt, I used quickly to generate the project, I'll bet that pulled it in for preferences or some such (which I don't use)
<bryceh> heh, I ended up deleting so much stuff quickly generated it would have been easier to generate the project from scratch ;-)
<bryceh> tjaalton, does bugbot assign bugs there?  if so I should fix that.  Thought it was directing them to the general nvidia package
<Sarvatt> wasn't sure if there was some feature you were planning that used it or something
<tjaalton> bryceh: bug 718742 as an example
<ubot4> Launchpad bug 718742 in xserver-xorg-input-evdev (Ubuntu) "Cyborg R.A.T.7 Right Click Issue (affects: 1) (heat: 8)" [Undecided,Won't fix] https://launchpad.net/bugs/718742
<bryceh> tjaalton, thanks I'll investigate
<tjaalton> or bug 765850
<ubot4> Launchpad bug 765850 in nvidia-graphics-drivers-180 (Ubuntu) "unable to rotate display left or right (affects: 1) (heat: 3257)" [Undecided,New] https://launchpad.net/bugs/765850
<bryceh> heh, I've got some weird bug where sometimes right clicking to bring up the context menu in chromium causes the area that was occupied by the context menu to remain (doesn't re-render) showing a static clipping from the browser window 
<bryceh> vt switching causes those regions to turn gray
<bryceh> a sufficient amount of switching desktops seems to eventually make the issue go away
<bryceh> this on an rv770 with -ati on 2.6.38.8.22
<tjaalton> hmm bug 771344 is the one jane has?
<ubot4> Launchpad bug 771344 in xorg (Ubuntu) "external monitor does not work (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/771344
<bryceh> yeah I think all those arrandale bugs are the same
<bryceh> tjaalton, seems to be fixed with newer kernel, but having hard time finding someone willing to bisect
<seb128> you might be able to convince pitti to try ;-)
<bryceh> ok bugbot's nvidia-180 issue is fixed
<bryceh> ok desktopcouch excised from xdiagnose.
<tjaalton> bryceh: good to hear that there's progress
<cnd> bryceh, tjaalton: either of you interested in trying to resolve bug 762768?
<ubot4> Launchpad bug 762768 in xserver-xorg-input-synaptics (Ubuntu) "cannot select text with left click with touchpad (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/762768
<cnd> I think the resolution would be to try to get the input device properties to find out if it's a clickpad
<cnd> input device properties are a new functionality of the kernel evdev interface in natty
<cnd> if it's a clickpad, then set the area bottom edge
<cnd> I'd take it and fix it myself, but I'm swamped right now
<cnd> there should already be some code in my synaptics patches to determine if the trackpad is semi-mt, so you can use that as reference
<bryceh> cnd, can you describe what needs done on the bug report itself?  Then whichever of us wants to pick it up can take it from there
<cnd> bryceh, yeah
#ubuntu-x 2011-04-27
<Sarvatt> wow - http://zrusin.blogspot.com/2011/04/apitrace.html
<Sarvatt> http://sarvatt.com/downloads/glxgears.trace   that look screwed up on anyone elses system when you replay it? been meaning to report this bug on gen6 intel since april 12th's mesa checkout and if that works that'll help a crapload describing it
<RAOF> Sarvatt: Yeah.  I was looking at that and thinking âthat's a high priority for Oneiric packagingâ :)
<RAOF> Also, I've just taken delivery of a Dell Ultrasharp 24" monitory.
<RAOF> Dear lord, 24" monitors are big.  I'm glad I didn't go for the 27" :(
<RAOF> :)
<Sarvatt> know any simple packages using cmake by any chance? :P
<Sarvatt> planning on packaging it up tomorrow
<RAOF> Compiz does.
<RAOF> That's not exactly simple, but hey!  Neither's cmake!
<Sarvatt> oh thats a lot easier than i thought it'd be
<RAOF> Dear kernel build: FASTER!
<Sarvatt> RAOF: want me to build you one? takes 10 minutes or so
<RAOF> Yes please.
<Sarvatt> what ya need?
<RAOF> i386, bitte.
 * RAOF builds a source package.
<Sarvatt> wonder if this can trace unity, apitrace is falling over on a few more complex things i've run so far - warning: unsupported call glSecondaryColorPointerEXT
<Sarvatt> have a patch to apply to the natty or oneiric kernels or are ya doing something more complex?
<RAOF> I want to test my patch; it should work, but who knows :)
<RAOF> Untested code is broken!
<Sarvatt> its easier if i just build it from ubuntu git with your patch applied if thats ok
<RAOF> I haven't actually got a patch as such yet, although I could generate it from git if that's easier for you.
<Sarvatt> natty or oneiric?
<RAOF> natty.
<Sarvatt> yeah just shoot me the git diff
<RAOF> Is there an oneiric kernel?
<Sarvatt> yep, not published anywhere yet though
<RAOF> http://cooperteam.net/patchme.patch
<RAOF> Applies to both natty and oneiric, actually, assuming oneiric is 2.6.39-based.
<Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=summary
<Sarvatt> natty i386 generic or generic-pae?
<RAOF> generic
<Sarvatt> also do you need headers?
<RAOF> Nope.
<Sarvatt> okie building now
<RAOF> It only touches drm, and will be tested on a desktop.
<RAOF> Ta muchly.
<RAOF> I'll build me a kickarse desktop system soon; I think I want to wait for the z68 chipset first.
<Sarvatt> good call :)
<Sarvatt> almost done, building the deb now
<RAOF> What system's that building on?
 * RAOF would *love* a 10 minute kernel build time.
<Sarvatt> http://sarvatt.com/downloads/cpuinfo.txt
<Sarvatt> http://kernel.ubuntu.com/~sarvatt/raof/
<RAOF> Is that a dual-socket quad-core xeon setup?
<Sarvatt> real	12m52.920s
<Sarvatt> user	115m50.160s
<Sarvatt> sys	15m38.780s
<Sarvatt> 4 sockets x 8 core cpu with HT :)
<RAOF> Woot.  Looks like that works as expected.
<RAOF> (IE: not hanging in poll() âº)
 * RAOF gives it a couple more minutes of dpms cycling.
<Sarvatt> awesome, you mean i'll be able to close the lid in a unity session again without having to restart unity from a VT 10% of the time? :P
 * Sarvatt installs
<RAOF> Yes.
<RAOF> This is exactly that bug :)
<Sarvatt> awesome, it does look to be fixed
<RAOF> Excellent.
<Sarvatt> now if only I didn't have to reenable semaphores on sandybridge to get rid of [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 392605, at 392605], missed IRQ? under compiz unity would be perfect :)
<Sarvatt> oh besides the multi monitor bustage
<Sarvatt> bryceh: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-o-xorg-ubuntu-x-team-huddle did you see when it was scheduled? :)
<Sarvatt> monday at noon
<jcristau> haha
<Sarvatt> should just rename it the "create new articles for phoronix to post session"
<soreau> hah
<Sarvatt> let's play a gag and talk about switching to i915g and wayland entirely for 11.10
<JanC> lol
<JanC> Sarvatt: I've seen people claim that earlier already anyway  ;-)
<JanC> at least the wayland part...
<Sarvatt> [     5.403]
<Sarvatt> X.Org X Server 1.10.1
<Sarvatt> why did I not switch to SSD earlier..
<bryceh> Sarvatt, yeah the automatic scheduler at work probably
<bjsnider> sarvyou know of any special problem with jockey/nvidia if the user is using the pae kernel?
<bjsnider> Sarvatt,  you know of any special problem with jockey/nvidia if the user is using the pae kernel?
<Sarvatt> yeah if they only have linux-headers-generic installed they wont get automatic generic-pae header updates
<Sarvatt> you need linux-headers-foo-generic-pae instead of linux-headers-foo-generic
<bjsnider> but it's not done automatically
<Sarvatt> only if they installed with >4gb ram, and while plugged into the net so it automatically installed the generic-pae kernel, if they did it after the fact they need to install linux-headers-generic-pae too
<Sarvatt> really annoying :(
<Sarvatt> would be nice if we just switched generic to PAE next cycle IMO :)
<bjsnider> pae would still work as a standard i386 kernel on systems with <4gb right? i mean it's not going to constantly lock up or anything
<Sarvatt> yeah its just a small performance penalty and intel had some problems with it back when we were first going to do that (I think it was in .30?). I think phoronix even did some benchmarks showing the differences recently
<Sarvatt> http://www.phoronix.com/scan.php?page=article&item=ubuntu_natty_pae64&num=1
<bjsnider> .30 is quite a while ago
<Sarvatt> err he tested machines with 4gb ram or more in those benchmarks, nevermind ignore that article I linked :)
<jcristau> bjsnider: it's not going to work on cpus that don't support pae
<jcristau> Sarvatt: fwiw i think the plan for debian is to have a 486 flavour, 686-pae and amd64.  no 686/smp without pae anymore.
<bjsnider> jcristau, wouldn't work meaning it would just panic and not even boot?
<jcristau> probably.
<Sarvatt> pretty sure since we are i686 only !PAE isn't an option and that was why it was being considered, will be sure to bring it up at UDS
<Sarvatt> there's probably a geode that'll throw a wrench in that
<jcristau> there are !pae 686 cpus, apparently.  pentium m, via c3 nehemiah, geode lx, from the debian-kernel thread.
<Sarvatt> pentium m? oh wow
<jcristau> http://lists.debian.org/debian-kernel/2011/02/msg00246.html
<stgraber> uptime
<stgraber> oops :)
<tjaalton> yeah my "new" glorious sis671 laptop has a pentium-m..
<jcristau> lucky you.
<tjaalton> thinkpad t23 too
<Sarvatt> tjaalton: which pentium m though? most pentium m's supported it..
<Sarvatt> then again, SIS, probably one of the first ones :)
<tjaalton> Sarvatt: hmm, could be a newer one
<tjaalton> it's only 4y old
<tjaalton> the thinkpad is ~9yo
<tjaalton> but doesn't the nx-emulation cover those?
<tjaalton> guess i'll need to install the pae-kernel on the t23 to see
<bjsnider> tjaalton, every sis based xp system i've worked on is unable to smoothly draw a window being dragged across a screen
<tjaalton> bjsnider: well I didn't buy it because of trail blazing performance :)
<bjsnider> that's good because it's not much of an improvement over the sight of a blank screen
<tjaalton> got it a month ago for testing the new code, though i've yet to actually test it
<Sarvatt> tjaalton: i've got a sis 741GX/sempron socket 754 combo you can have if you want some more trash :)
<Sarvatt> oh its a sis 760gx
<tjaalton> eww
<Sarvatt> darn wifi kill switch on this e6420 is waaay too easy to hit
<tjaalton> [    0.000000] Notice: NX (Execute Disable) protection missing in CPU!
<tjaalton> [    0.000000] NX (Execute Disable) protection: approximated by x86 segment limits
<tjaalton> so yeah, pae-kernel works just fine on pentium-m
<tjaalton> on the t23
#ubuntu-x 2011-04-28
<EagleScreen> hello
<EagleScreen> hello
<EagleScreen> will be available soon intel driver 2.15.0 in X Updates PPA?
<jcastro> bryceh: ping me next week if you want me to slide that X session out of monday
<bryceh> jcastro, yeah we'd like it to be thurs or friday
<jcastro> the scheduler will run again tomorrow
<jcastro> but remind me next week after the schedule's settled down
<bryceh> jcastro, sounds like you need a todo list program ;-)
<jcastro> bryceh: this is my "if they care they will ping again but I won't make too much of an effort right now but I want to sound useful."
<bryceh> *snortle*
<bjsnider> ricotz, the default gnome 3 font doesn't seem to be available here. is it on your system?
<bjsnider> cantarell
<ricotz> bjsnider, no it isnt available, i just customized them
<EagleScreen> bryceh: can I expect an upload of intel driver 2.15.0 soon in X-Updates PPA??
<EagleScreen> anyone else?
<bryceh> EagleScreen, perhaps, if someone has some freetime to do it, although with the release people are pretty busy
<bryceh> EagleScreen, would you be interested in joining the xorg-edgers team to help do updates?
<EagleScreen> i am a beginer packager
<EagleScreen> but if you think I can help.. i'd join
<bryceh> EagleScreen, that's probably fine - there are scripts you run to generate the packages, so it doesn't require a heavy amount of packaging know-how (except when you need to troubleshoot problems, which others can help with anyway)
<bryceh> let me dig up some additional info for you to look at 
<bryceh> EagleScreen, on https://launchpad.net/~xorg-edgers scroll down to "Contributors to xorg-edgers be welcome" and read that section
<bryceh> it shows where you can get the script, and how to run it to get a new upstream snapshot of a video driver
<bryceh> EagleScreen, give that a try and see if you can make a 2.15.0 snapshot driver for yourself
<EagleScreen> ok
<EagleScreen> but i was thinking in make stable 2.15.0 not a git snapshot
<EagleScreen> i was playing with debian unstable (KDE) and i have seen that desktop effects works pretty well with my intel card, then i thougth it was by the 2.15.0 driver newer than 2.14 in Kubuntu natty, but now i see that debian esting with 2.14.0 also have good desktop effects
<EagleScreen> in natty ther are very slow and KDE disable them
<EagleScreen> so it must be another thing more than the 2.15.0
<bryceh> EagleScreen, ok well one of us will eventually get 2.15.0 into x-updates once some of the more pressing issues are taken care of
<bryceh> actually with the release out now it's probably a good time to refresh x-updates.
<EagleScreen> yes, but 2.15.0 may not fix the desktop effects issue since they work in Debian under 2.14.0
<EagleScreen> the difference must be in another X package, may be some library
<Sarvatt> it's not in there yet because of libdrm, the nvidia package will depend on the newer libdrm (even though it doesn't use it) and a lot of people just install the nvidia deb from that PPA which will screw up things
<Sarvatt> kde effects being slow would be mesa
<bryceh> heya Sarvatt
<Sarvatt> more than likely I bet you're seeing that blur is disabled automatically in debian, but its getting enabled in ubuntu which is leading to the disable effects fallback
<Sarvatt> heyo bryceh!
<EagleScreen> both natty and Debian have 7.10.2
<Sarvatt> yeah but debian does not revert the commit that breaks direct rendering in KDE in their mesa
<Sarvatt> (which means no blur automatically on intel)
<EagleScreen> then, direct rendering is broken now in Debian testing? how do I check it?
<Sarvatt> i'm not familiar with KDE to answer that, I think there's a lot that tells you if direct rendering is enabled? let me dig up the bug reports
<Sarvatt> log rather
<Sarvatt> EagleScreen: ~/.xsession-errors
<Sarvatt> on debian it will say
<bjsnider> ricotz, the problem ryan paul complained about in his review of gnome 3, where there's too much white space everywhere is due to the cantarell font. i just installed and tested it. the ubuntu font looks better from the standpoint of whitespace.
<Sarvatt> Direct rendering:                       no
<Sarvatt> Requires strict binding:                yes
<Sarvatt> GLSL shaders:                           no
<Sarvatt> and on natty it will say
<Sarvatt> Direct rendering:                       yes
<Sarvatt> Requires strict binding:                yes
<Sarvatt> GLSL shaders:                           yes
<bjsnider> looks like cantarell adds a lot of padding on the top of the letters
<EagleScreen> i dont see that lines in the file
<Sarvatt> EagleScreen: run kwin manually maybe? should be in the terminal output when you run it
<Sarvatt> alternatively, just disable blur and lanczos in kwin to stop the fallbacks
<EagleScreen> i still dont see it, neither on terminal
<EagleScreen> i dont know what blur is
<EagleScreen> and how to disable it
<Sarvatt> I dont know how to disable it in KDE either, was under the impression there was an option in the GUI to do it though. anyone else here know?
<Sarvatt> quite a lot of interesting linaro sessions this time around
#ubuntu-x 2011-04-29
<RAOF> It's always interesting to catch up with the linaro guys.
<jcastro> bryceh: you're sorted with your Xorg team session on Thursday, right after lunch so you guys will be nice and happy.
<Sarvatt> jcastro: thanks a ton for that
<RAOF> We should probably have a wayland-specific session, now that I think of it.
<jcastro> RAOF: remember that there is an -o- in the titles, so I encourage you to do something that makes desktop-wayland-o-matic-something-clever 
<RAOF> Heh.
<RAOF> The nomenclature is desktop-o, though right?
<soreau> <diegoviola> RAOF: strange, ubuntu people are talking about shipping wayland as the default in 11.10
<soreau> ;)
<bjsnider> yeah, that's going to happen
<bjsnider> 5000 developers and 100000 testers are working 24/7 on it for the next 6 months
<bjsnider> i wonder how the issue of the blob's lack of gem/kms would be solved in 6 months
<bryceh> jcastro, thanks
<RAOF> Eh.  It wouldn't actually be *too* hard to transition to X-on-wayland, and there are some benefits to that.
<bryceh> RAOF, let's wait for some guidance from mark before we get too far down the pike
<RAOF> Oh, I'm not suggesting that we'll be *doing* it, but it's hardly 2500 developer-years and 50,000 tester-years worth of work :)
 * bryceh works on getting CivV installed under wine...
 * RAOF found that it Just Worked.
<RAOF> Also, care of nvidia's linux drivers being significantly better than their windows drivers, was much more stable.
<bryceh> heh
<bryceh> well, I'm trying to get it running on -ati
<RAOF> fglrx might run it.  And possibly r600g with mesa from git and float textures enabled and libtxc-dxtn and a 2.6.39 kernel might, too :)
<bryceh> funny bug, when I move the Steam dialog window 100 pixels horizontally, it moves 200 pixels
<soreau> RAOF: nvidia linux drivers more stable than their windows counterparts? How do you figure that?
<soreau> I was wondering, if radeon gallium is default for natty, what does libgl1-mesa-dri-experimental provide?
<tjaalton> nouveau_dri.so
<RAOF> soreau: For my hardware - 7600go - I have a choice of nvidia-current on linux or 170.63 on Windows.
<tjaalton> hum, so the moonlight package doesn't actually do anything
<tjaalton> doesn't show up in about:plugins
<RAOF> Which plugin package?
<tjaalton> moonlight-plugin-mozilla
<RAOF> Ah.  In archive.
<tjaalton> needed to install the 4.0-preview to get anything
<tjaalton> though silverlight4 content doesn't work with it either
<tjaalton> so, moo
<cnd> bryceh, found a nasty bug with masked valuators and input coordinate transformation
<cnd> I've got a patch that I'm testing out right now
<cnd> it should undergo plenty of testing before being SRU'd though
<cnd> how do you think we should go about this?
<Sarvatt> cnd: can you send it to me so I can add it to edgers at least?
<cnd> Sarvatt, sure
<bjsnider> ricotz, i guess the network-manager-gnome package isn't really integrating with gnome-shell like it was supposed to
<ricotz> bjsnider, if you arent using the nm-0.9 packages then this is normal
<bjsnider> ricotz, where do i get those packages?
<ricotz> bjsnider, you can use ppa:ricotz/staging, but without a gnome-control-center with nm0.9 support you will loose some functionality
<ricotz> the import package is gir1.2-networkmanager-1.0
<bjsnider> what functionality?
<ricotz> bjsnider, access to the configuration
<bjsnider> i don't do anything crazy with it, just dhcp/wired
<ricotz> but using nm-connection-editor directly should work fine
<ricotz> in this case you should be fine
<bjsnider> the only networking options i see in gnome control center now are for adding proxies
<bjsnider> ricotz, how long before the nm-0.9 package is added to the gnome 3 ppa?
<ricotz> bjsnider, yes, to have more option g-c-c needs to be compiled with nm09 support which is disabled in the ppa
<ricotz> not sure might, you probably want to use oneiric which should include it soon
<bjsnider> ricotz, the plan is to have gnome 3 side by side with unity in oneiric?
<ricotz> yes
<bjsnider> i don't understand how the indicators get worked around, since gnome 3 doesn't use them
<BUGabundo> howdy
<BUGabundo> I got a bit of mess with my X package
<BUGabundo> for a while on Natty, and since I just upgraded to 11.10 
<BUGabundo> I would like to get it clear, before more stuff messes it up
<BUGabundo> http://paste.ubuntu.com/600936/
<BUGabundo> thanks in advance
<Sarvatt> cnd: thanks a ton, got the patch
<Sarvatt> ppa.launchpad.net is down though
<Sarvatt> just tried to upload it, Connection failed, aborting. Check your network [Errno 111] Connection refused
<BUGabundo> Sarvatt: can you take a look ?
<BUGabundo> http://paste.ubuntu.com/600936/
<Sarvatt> BUGabundo: dpkg -l?
<BUGabundo> of what?
<BUGabundo> everything? :P
<BUGabundo> $ dpkg -l | pastebinit 
<BUGabundo> http://paste.ubuntu.com/600993/
<BUGabundo> Sarvatt: ^^^^
<Sarvatt> yeah somethings out of wack and it could be a lot of things :)
<BUGabundo> it has been for a while
<BUGabundo> after I pushed a X ppa
<BUGabundo> and removed it after
<BUGabundo> FYI I'm on 11.10 :D
<Sarvatt> BUGabundo: yeah thats all kinds of messed up, lets see..
<Sarvatt> BUGabundo: ok start with
<Sarvatt> add deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu natty main to /etc/apt/sources.list.d/xorg-edgers.list
<Sarvatt> then sudo apt-get update
<Sarvatt> then sudo ppa-purge xorg-edgers
<Sarvatt> you have some stuff from the xserver 1.10 RC ABI's lingering around, i'm surprised stuff works :)
<BUGabundo> :)
<Sarvatt> that should fix it though, let me know if it doesn't
<BUGabundo> okay
<BUGabundo> PPA is slow
<BUGabundo> so gonna take a bit
<BUGabundo> Sarvatt: how sane does this look? http://paste.ubuntu.com/600998/
<Sarvatt> perfect
<Sarvatt> sudo apt-get install xserver-xorg-video-all after too to get it back to normal
<Sarvatt> libglapi-mesa is specific to xorg-edgers at the moment and not in mesa 7.10 so normal its going to be removed
<BUGabundo> Sarvatt: as a reminder , im on 11.10 in case it matters :P
<Sarvatt> yepyep theres nothing X specific there yet
<Sarvatt> just a copy of 11.04
<BUGabundo> okay
<Sarvatt> i had ya add the natty sources so those packages would get added to the list to be removed, don't have oneiric stuff in xorg-edgers yet because PPAs are screwed
<Sarvatt> sure wish I could figure out why unity is spazzing out on me the past few days, I can't interact with the panel or use alt shortcuts or change channels in xchat randomly every few hours
<Sarvatt> close terminator, it works again for a few seconds until it happens again
<BUGabundo> PPA purged successfully using aptitude fallback
<Sarvatt> BUGabundo: let me know if it works, got to run soon for dinner :)
<BUGabundo> The following NEW packages will be installed:
<BUGabundo>   xserver-xorg-video-all xserver-xorg-video-ati{a} xserver-xorg-video-mach64{a} xserver-xorg-video-openchrome{a} xserver-xorg-video-qxl{a} xserver-xorg-video-r128{a} xserver-xorg-video-radeon{a} xserver-xorg-video-s3virge{a} xserver-xorg-video-savage{a} xserver-xorg-video-vmware{a} 
<BUGabundo> feel free to go
<BUGabundo> ill ping you tomorrow nite on the result
<Sarvatt> oh alrighty, I'm on MSN too
<Sarvatt> oh wait, didn't set up MSN on this new PC, doing it now
<BUGabundo> ahah
<BUGabundo> MSN
<BUGabundo> don't use that
<BUGabundo> all I have its your Xbox XMPP
<BUGabundo> :P
<Sarvatt> wish I could change that!
<BUGabundo> mauauaa
<BUGabundo> why ?
<Sarvatt> i picked that nick on my 360 account that can't get online anymore, they dont let you change the nick anywhere else apparently
<Sarvatt> i'm on it via pidgin and it has that name stored server side somewhere :)
<BUGabundo> ah
<BUGabundo> wait
<Sarvatt> shows up as Alias: Sarvatt  here, not sure why it show the xbox 360 account name for other people
<BUGabundo> Account
<BUGabundo> pick that one
<BUGabundo> User Info
#ubuntu-x 2011-04-30
<m1chael> sry for that
<m1chael> and I'm new to radeon graphic cards if I want a Gallium3D driver which repo should I add ubuntu-x or XorgEdgers? and what package to install? xserver-xorg-video-ati?
<ashams> May ask for help: I can't find the upstream git tree for xserver-xorg-input-synaptics
<soren> ashams: git://anongit.freedesktop.org/git/xorg/driver/xf86-input-synaptics ?
<ashams> soren: yeah, thank you
<soren> ashams: np
<soren> ashams: I found it in its /usr/share/doc/<blah>/copyright file, by the way.
<ashams> soren: thank you
<ashams> soren: may I ask for another favor?
<ashams> soren:  I can't find the xorg config file
<ashams> thus I can't make run-time config
<ashams> soren: sorry, I need to go :)
<EagleScreen> hello
<EagleScreen> I want to disable the "intel" Xorg driver in order to use the "fbdev" in natty, but there isn't xorg.conf.d/50-device.conf
<EagleScreen> fbdev is more reliable than intel in my case
<bryceh> EagleScreen, you need to blacklist i915 in the kernel modules to do that
<EagleScreen> thanks you
<EagleScreen> using fbdev, the mouse pointer dissapiars if is not moving
<EagleScreen> dissapears
<Sarvatt> RAOF_: are ya around by any chance? I'm having a heck of a time finding the vblank hang bug to dupe a few to it since it's lost in the mess that are linux bugs, have the number handy?
<Sarvatt> ahhh got it, nevermind  https://bugs.launchpad.net/ubuntu/natty/+source/unity/+bug/740126
<ubot4`> Launchpad bug 740126 in unity (Ubuntu Natty) (and 6 other projects) "Something blocks compiz randomly several times per day (affects: 9) (dups: 1) (heat: 68)" [High,Triaged]
<Sarvatt> bryceh: funny, now that I'm digging into intel bugs I see quite a few that are most likely dupes of this one, including the one that looked like a libdrm regression
<Sarvatt> why is it every cycle there's a huge number of bugs on intel that happen during dpms events? third release in a row, definitely something to ask cert to test the whole cycle if its not already
#ubuntu-x 2011-05-01
<abbeyj> I'm looking for a package containing vmwgfx_drv.so and vmwgfx_dri.so.
<abbeyj> I thought these were in libgl1-mesa-dri-experimental but they're not there any longer.
<abbeyj> Have they moved somewhere?
<bryceh> Sarvatt, is that the dpms on external monitor bug that seems to be affecting arrandale-generation chips?
<bjsnider> abbeyj, Package/file vmwgfx_drv.so does not exist in natty
<bjsnider> doesn't exist in maverick either
<bjsnider> abbeyj, libgl1-mesa-dri-experimental never contained those files. the actual list is here: http://packages.ubuntu.com/maverick/i386/libgl1-mesa-dri-experimental/filelist
<abbeyj> bjsnider: what's http://ubuntu-tweak.com/source/xorg-edgers-ppa/ talking about then? (search for "libgl1-mesa-dri-experimental")
<bjsnider> sounds like that file might be related to vmware
<abbeyj> it is.  i'm running in vmware player
<bjsnider> that page was last updated on jan 12 2010
<bjsnider> abbeyj, you should talk to sarvatt about this
<Sarvatt> bryceh: affects all generations
<Sarvatt> abbeyj: I removed it a long time ago, some vmware guy asked us to stop enabling the kernel module and it doesn't work without that enabled so it needs a new kernel too. it really complicated the mesa packaging with the xserver circular build dependencies
<Sarvatt> i have no clue why ubuntu-tweak posted a cut and paste from the PPA info page and never updated it
<ScottK> ubuntu-tweak is not great about keeping stuff up to date.  See what I added to my clamav PPA: http://ubuntu-tweak.com/source/clam-antivirus/
<Sarvatt> good call :) 
<Sarvatt> darn, You don't have permission to change source. (signed up to edit the info)
<ScottK> I changed it in the PPA itself.  Next time they mirrored it, problem solved.
<bryceh> Sarvatt, is there a patch identified?
<abbeyj> Sarvatt: vmware tools ships with the kernel module and will automatically build it
<abbeyj> but only if the dri and X modules are already present
<abbeyj> looks like i'm building from source
<Prf_Jakob> abbeyj: wait the installer builds the kernel driver?
<Prf_Jakob> tools installer*
<abbeyj> i believe that it is supposed to.  it isn't doing it for me since i don't have the other modules.
<Prf_Jakob> ah no, its not supposed to build the module.
<thopiekar> hi
<thopiekar> I try to build xserver-xorg 1.9 with ABI 8.. when installing all deps of xserver-xorg it says that it hasn't passed the test because it is build against ABI10. So, which dep of xorg needs to be downgraded?
<thopiekar> * using natty here. and took xorg-server from your x-swat ppa (maverick)
#ubuntu-x 2012-04-23
<RAOF> *arse*
<RAOF> Stupid X, crashing when I ask gdb to evaluate something nonsensical!
<jcristau> heh
<FernandoMiguel> olÃ¡
<bryceh> Quantal Quetzal??
<broder> RAOF: how nonsensical? do you know about set unwindonsignal?
<RAOF> broder: Nonsensical as in passing arguments in the wrong order, leading to a null pointer deref.
#ubuntu-x 2012-04-24
<RAOF> Hey, is anyone here able to reproduce bug #962704?
<ubottu> Launchpad bug 962704 in xserver-xorg-input-synaptics (Ubuntu) "cursor jumps to screen border when touching trackpad border" [Undecided,Confirmed] https://launchpad.net/bugs/962704
<RAOF> I think I've got the fix.
<bryceh> RAOF, nope.  I had a 'jump to screen border' problem on the netbook but the conditions differed.  Plus it's no longer happening with cnd's latest stuff.
<RAOF> Yeah, there was an earlier jump to screen border that cnd definitely fixed.
<RAOF> That was *desperately* annoying, so I know it's fixed because people aren't screaming at us :)
 * bryceh nods
<cnd> RAOF, bryceh: I think whot just posted a fix for that issue
<cnd> upstream
<cnd> I've been waiting on updating to upstream until he actually releases it for real
<cnd> http://lists.x.org/archives/xorg-devel/2012-April/030585.html
<RAOF> cnd: Yup.
<RAOF> cnd: I'm pretty sure the scroll issues I was tracing down are fixed by that, too.
<RAOF> So I've prepared an SRU and am just testing it now.
<cnd> ok, cool
<RAOF> (Specifically, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/982771 )
<ubottu> Launchpad bug 982771 in xserver-xorg-input-synaptics (Ubuntu) "Scrolling stops working in GTK3 scrolled windows after some time" [High,Confirmed]
<cnd> I'm off to bed
<cnd> have a good evening :)
<bryceh> cnd, cya
<bryceh> cnd, bedtime already?
<RAOF> Sleep well, and wake :)
<RAOF> Hey, does anyone know if bcm5974 is unique to apple hardware?
<RAOF> Sarvatt: If you'd like to check that your macbook can suspend, resume, *and* still have a working trackpad with the synaptics in -proposed, that'd be grand. :)
<Sarvatt> RAOF: no dice, its stuck thinking 1 finger click is 2 fingers after resume
<FernandoMiguel> g'nite
<Darxus> It could be very useful in discussions with some people to have a decent answer to this question:  Once Wayland is used by default on Ubuntu (whever that happens), what is the shortest possible amount of time until X stops being supported?
<bryceh> hi Darxus 
<bryceh> Darxus, that's rather speculative :-)
<bryceh> Darxus, I think at this stage there cannot be a decent answer to that... far too many variables to consider
<Darxus> Of course.  But there are people freaking out that they won't be able to use X natively anymore once Wayland works.  And it would be nice to be able to tell them somewhat authoritively that their concerns are unfounded.  
<Darxus> For more reasons than "backward compatability is going to be awesome, really".
<bryceh> ah
<bryceh> Darxus, well, let's lay out some assumptions
<bryceh> first, "Wayland used by default on Ubuntu" - let's define this to mean:
<bryceh> * Either fglrx supports wayland, or the FOSS radeon driver is better all around than fglrx, and fglrx is obsolete
<bryceh> * Ditto -nvidia and -nouveau
<bryceh> * wayland's performance is as good or better than X11
<bryceh> * we can handle both the login session and the logged in user session
<bryceh> * a wayland-enabled widgetset (gtk, qt, or whathaveyou) is fully supported by all major applications we need (openoffice, firefox/chromium, unity, et al.)
<bryceh>  
<bryceh> now, assuming all the above were true and wayland's 100% ready, and the Ubuntu project has consensus to switch to Wayland, there's two ways it could go
<bryceh> 1.  We make the switch in an LTS.
<bryceh> 2.  We wait until the release after the LTS.
<Darxus> I can't imagine why you'd pick #1.
<bryceh> case #1 would mean we would be able to stop officially supporting X11 in about 2 years.
<jcristau> what does "supporting X11" mean?
<jcristau> running X11 apps?
<bryceh> case #2 would mean we'd continue to support X11 for the duration of the LTS, which is 5 years.
<bryceh> jcristau, right, "support" also needs to be defined
<jcristau> i'm not seeing that happening in like 10 years
<jcristau> or 20
<bryceh> jcristau, he asked for the absolute minimum timeframe
<mlankhorst> bryceh: but id probably support X for 10 more years than an early release of wayland..
<bryceh> I think that the assumptions I laid out are not likely to be met for a long while
<mlankhorst> true :)
<bryceh> so yeah, I mean, "We could not stop supporting X11 for less than 2 years in the crazy nutty scenario, or 5 years in the slightly more realistic scenario"
<bryceh> where by support I mean packaging updates regularly, ensuring all applications run on it, fixing bugs, providing security fixes, yada yada
<mlankhorst> I doubt you could even do it in 1 release cycle..
<mlankhorst> even if wayland was ready
<bryceh> probably not
<Darxus> So what, Ubuntu will continue supporting (natively) using X for a minimum of 20 more years?  :)
<mlankhorst> X is already 30 years or older, so what's the problem?
<bryceh> Darxus, such leading questions...
<bryceh> Darxus, ;-)
<Darxus> Damn.
<Darxus> It's funny how much hate has poured on wayland just because Mark Shuttleworth said ubuntu will use it.  I believe that hate would ease off if somebody authitatively said ubuntu will continue supporting X for at least 20 years.
<Darxus> Okay, not *just* because he said ubuntu will use it, but because people manage to vastly misunderstand it.
<mlankhorst> And that's exactly what you realistically can't say..
<Darxus> Fair enough.
<bryceh> Darxus, yeah I also am troubled by how people blew wayland into a big bubble
<jcristau> marks likes making bubbles
<bryceh> tbh, that's half the reason I put some time into getting it packaged for ubuntu... so people could have something tangible to review
<Darxus> bryceh: I do appreciate that.
<Darxus> If only I could get xwayland working and create a video demonstrating it works great....
<bryceh> Darxus, so what I'd tell people is this:
<bryceh> yes, as soon as someone demonstrates wayland works, suddenly worldwide all X11-based apps will mysteriously stop working.
<Darxus> Haha.
 * Darxus forwards that to phoronix.
<bryceh> heh
<Darxus> I'm coming across (what seems like) a lot of "yeah well people said pulse audio wouldn't suck either".
<bryceh> Darxus, more seriously, if someone rubbed a genie and waved a magic wand and rainbows shot from unicorn butts, I can't see support going away for at least 5 years from 14.04.  When you start taking into account all the variables and uncertainties, it's looking more like 10 years or more
<Darxus> Thanks.
<bryceh> and anyway I really doubt we'd make a wholesale switch in one go, we'd probably use wayland in some capacity for a while, with X11 running under it, and gradually factor out needing X11 over some years
<bryceh> then at the tail end years from  now we'd probably not have X11 seeded but have it in the archive for legacy users
<Darxus> Right.
<Darxus> Thanks.
<bryceh> so, it wouldn't install by default but would still be there for apps that need it
<bryceh> Darxus, again though, all of the above is totally just out of my ass speculation, don't quote it as anything official
<Darxus> Right.  
<bryceh> except the unicorn butt bits, that's ok
<bryceh> Darxus, more nearer term, robert ancell is looking into doing an experiment of using wayland for the login screen, for certain specific cases (e.g. foss drivers only).  there's a UDS discussion and blueprint for that.
<Darxus> Yeah, I've noticed.  That would be fun to see happen.
<Darxus> RAOF was asking about it in #wayland not long ago.
<bryceh> Darxus, but please don't take that as a commitment that we're moving to wayland; at this stage it's just an experiment.  Despite mark's post, we don't have any official plans in place to move to wayland.
<bryceh> or I should say, aside from his post...
<Darxus> Yeah, I know.  
<Darxus> Hah.
<bryceh> but I do think we are going to move in a wayland-ish direction; if not wayland itself then something wayland-like.  My bet would be an X.org that incorporates a more wayland-like architecture, but who knows.
<Darxus> Like using KMS/DRM for output and dropping DDXes?
<bryceh> Darxus, yeah; there's been some interesting experiments along those lines going on over on the ARM side for example
<Darxus> Nice.  
#ubuntu-x 2012-04-25
<RAOF> Sarvatt: Doh!  If that doesn't fully fix your touchpad you might want to ping whot; he's under the impression that'll fix his redhat bug :)
<sforshee> cnd, I'm doing some debug prints in x-x-i-s for the bcm5974 s3 problem. My assumption is that all events from the touchpad will go through the loop in EventReadHwState. Is that correct?
<cnd> yeah
<sforshee> okay, so here's what I see then...
<sforshee> UninitializeTouch is called on the way down, InitializeTouch is called coming back up
<sforshee> no events come in before I touch the touchpad
<sforshee> yet it's still messed up
<cnd> maybe the state is still somewhat screwed up even after uninit and init?
<sforshee> that would be my guess
<sforshee> so resetting num_touches isn't enough I guess
<cnd> sforshee, what are you seeing when you hit the bug?
<sforshee> basically most things kind of acts like I have one additional finger down, except for moving the pointer which works fine
<sforshee> so a click generates a right click
<sforshee> a 2-finger drag moves windoes
<sforshee> *windows
<sforshee> etc.
<sforshee> actually the click behavior with one finger is inconsistent, sometimes I get right click, sometimes left click
<sforshee> two-finger drag very consistently moves windows though
<cnd> that's odd
<cnd> I'm wondering if there is an issue with mtdev
<sforshee> hmm, now something is wedged
<cnd> here's my theory
<cnd> mtdev takes untracked touches
<cnd> and tries to follow touches and assign them to tracked slots
<cnd> let's imagine that mtdev thinks there's a touch in the middle of the trackpad
<cnd> if you then physically touch in the middle of the trackpad, it will think it's the same touch
<cnd> but if you touch somewhere else, it will think it's a different touch
<cnd> that would explain why sometimes it acts like there's one touch, and sometimes two
<sforshee> I was trying to see if the right vs. left click correlated with where I clicked, but I didn't get a good feel for it before it wedged
<cnd> sforshee, I wonder if you can reproduce by keeping one finger touching while you log out to restart the X server?
<sforshee> cnd, just during the logout? or hold it down when logging in too?
<cnd> just during the X server restart
<cnd> once you hit the greeter you can release
<cnd> then type your pw to log in
<cnd> then test
<sforshee> something doesn't like that very much :(
<sforshee> the one time it worked it didn't reproduce the bug. but I got several hangs
<cnd> hmm
<cnd> what kinds of hangs?
<sforshee> I can ssh in, so the system is still up, but the desktop is completely frozen
<cnd> sforshee, keyboard input doesn't work?
<cnd> because a stuck pointer would look like a hung system
<sforshee> nope
<sforshee> in fact this last time it hung before displaying the greeter
<cnd> hmm
<sforshee> can't switch to vt1 either
<cnd> what about from your ssh session
<cnd> sudo chvt 1
<cnd> sudo stop lightdm
<cnd> either of those work?
<cnd> sudo killall -9 X
<cnd> :)
<sforshee> chvt 1 doesn't work, it seems to be stick in ioctl(3, VT_WAITACTIVE
<sforshee> service lightdm stop works
<RAOF> I love that the X server can disallow VT switching.  It makes everything so much more robust :/
#ubuntu-x 2012-04-26
<Sarvatt> RAOF: what should i be looking from in xinput --test-xi2
<RAOF> Whether you get multitouch events.  I'm not *entirely* sure what they look like, though :)
<RAOF> My magic touchpad is in my missing luggage.
<Sarvatt> when its busted, i get 8 valuators going off while 2 finger scrolling, when its not i get 1
<Sarvatt> well 8 flags
<Sarvatt> it will be hard as hell to capture spurious 4 finger taps while 2 finger scrolling in xinput --test-xi2, it happens like once every 5-10 minutes
<Sarvatt> and thats so much info printed in the meantime
<RAOF> I'd just dump the logs into a pastebin and throw it at whot :)
<Sarvatt> ok next time i want to inflict that crap upon myself (tomorrow morning) i'll do it, right now no mt gestures work cus i rmmod/modprobed bcm5974 so 2 finger scroll is usable :)
<RAOF> :)
 * Sarvatt cant wait to get a limited piece of crap elantech touchpad so these things go away when ux31 comes with 1080p screens with ivybridge :)
<tjaalton> bryceh: hey, looks like totals-precise-workqueue.svg is having some issues?
<bryceh> tjaalton, yep
<tjaalton> bryceh: was known already? :)
<bryceh> yeah, hardware failure
<tjaalton> ah :)
<bryceh> I moved all the scripts over to new hw.  everything works except the graphs for some reason
<tjaalton> ok
<tjaalton> no rush, I like to think everything is smooth and working
<tjaalton> (and not look at the bugmail folders..)
<tjaalton> :)
<bryceh> heh
<bryceh> yeah, probably something simple; looks like the data is all generating properly, it's just gnuplot being cranky
<bryceh> tjaalton, I have things set up that whenever a script fails, it emails me.  So I have an INBOX full of errors this morning.  Hard to miss :-)
<tjaalton> bryceh: heh :)
<bryceh> semi-fixed
<tjaalton> looks good, or is the timescale a bit limited?
<bryceh> missing historical data; the scripts are not parsing the older json files.  I think the json parser on the new machine is stricter on syntax
<bryceh> stand by
<tjaalton> yeah that's why totals.svg looks the way it does
<bryceh> (need to figure out a good way to delete one comma from 408 files)
<tjaalton> sed?-)
<bryceh> hah, launchpad is reporting quantal is now the current development codename
<bryceh> and is not listing precise as a supported release
<tjaalton> oh good, that was fast
<bryceh> right, so with that, back online:  http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-precise-workqueue.svg
<tjaalton> totals.svg looks funny :)
<bryceh> oneiric is also not listed as supported.  odd
<bryceh> tjaalton, hmm yeah what's up with totals.svg...
<bryceh> ok, here the problem is too *much* historical data
<tjaalton> bryceh: not using all the data? looks like it leaves gaps
<tjaalton> ah
<tjaalton> maybe filter it so that the timescale is still the same but "resolution" is smaller
<bryceh> nah, just have to be more selective in the data files to use
<bryceh> tjaalton, ok that one should be fixed.  going to get breakfast and will poke around for other breakages after that.  
<bryceh> tjaalton, btw I also fixed it so workqueue graphs continue to get generated and updated on past releases, although a few look wrong
<tjaalton> bryceh: thanks :)
<bryceh> e.g. so we can keep using the precise workqueue graph for tracking LTS work
<tjaalton> yeah that's good
<bryceh> tjaalton, http://humber/Arsenal/ubuntu-x-swat/Reports/package_status.html is the new versions-current; decided package_status was a clearer name.
<bryceh> that script had also been on the failed system, but was more severely broken since it requires a chroot, so had to build a new one on the new system yesterday.
<bryceh> tjaalton, I updated it for quantal while I was at it, but looks like there's no data yet since dev hasn't opened
<jcristau> http://humber?
<bryceh> ok http://bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package_status.html
<jcristau> :)
<bryceh> (for those not on my home network)
<jcristau> hmm.  no mesa there?
<tjaalton> bryceh: ah, noted
<tjaalton> jcristau: seems to be there now
<tjaalton> why does wine want to deinstall debhelper et al
<tjaalton> likely not wine but one of it's deps
<mlankhorst> maybe it pulls in some i386 that uninstall 64-bits versions?
<tjaalton> could be
<sforshee> cnd, I was just doing some more debugging with the bcm5974. I'm getting the weird behavior, but the number of touches x-x-i-s sees is correct.
<sforshee> cnd, whether or not I get left- or right-click behavior definitely seems to correspond to where my finger is on the touchpad, but the num_touches still always shows the correct value
<sforshee> cnd, I just added this information to the bug as well
#ubuntu-x 2012-04-27
<RAOF> Do we have any X-related blueprints other than https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-system-compositor that we'd like to do for Quantal?
<bryceh> RAOF, I emailed you a while back with some ideas
<RAOF> Oh, right, yes.
<RAOF> There it is.
<RAOF> :/
<bryceh> RAOF, also HWE has one for hybrid graphics, and robert is poking at a wayland one.
<RAOF> Yeah, that's the system-compositor I posted.
<RAOF> At least, I presume it is :)
<bryceh> ok, I didn't look
<bryceh> I was showing my daughter the computer tonight, and she got to banging on the keyboards, and I'm afraid she managed to break the keyboard!  at least, the left control key no longer works
<bryceh> and you know, left control is pretty vital.  I'm an emacs user for heaven's sake!
<bryceh> ahem, anyway
<RAOF> Surely you mean left caps!
<bryceh> there's been two arsenal blueprints posted so far (one by bjf and kate, another by cnd).  So I anticipate I'm going to be focusing more on tools this cycle
<RAOF> I'll whip up a general-xorg blueprint, as I don't see one currently, and I think they've been reasonably useful sessions in the past.
<bryceh> RAOF, this is a nice cherry blue mechanical individual key backlit keyboard.  the control key's led is also not lighting up.  So bad sign I think.
<RAOF> :(
<bryceh> yeah a good catch-all if nothing else
 * RAOF could actually do with a new keyboard.
<RAOF> I anticipate that my cycle will be spent on the system-compositor.
<bryceh> I guess we need to be careful since we're going to want  to backport the stack, but otherwise I'm figuring we'll just keep it pretty generic upstream
<RAOF> Yes; also the system-compositor is, care of nvidia & fgrlx, going to be opt-in in some form.
<bryceh> I'm so totally sold on backlit keyboards now.  dark room + overly bright monitors = where the f is the keyboard??
<RAOF> I generally aim for not-dark-room, myself
<bryceh> I suggested if alberto is at uds, we should brain-pick
<bryceh> but guessing he's going to not be there again, so probably no matter
<bryceh> I do wonder if we could straighten up the packaging for the binary drivers better, but it hasn't been a top concern
<bryceh> he seems to have it quite well covered.  The concern is more just bus factor.
<RAOF> Yeah.
<RAOF> Hm.  Now that I think of it, do we need to do any thinking about video {de,en}coding acceleration?
<bryceh> well, the intel guys are interested in our feedback on libva
<bryceh> I don't know of any other expressed needs besides that
<RAOF> I guess it's something that we can pretty uncontrovertially just add a few depends and turn on.
<RAOF> ARM, obviously, really really really wants it, but they do their own thing.
<bryceh> looks like it's  being hooked in for most video players already; not sure there's much we'd need to do on the X side
<RAOF> Right; we've even got gstreamer-vaapi in Precise.
<bryceh> outside ubuntu seems like most of the resistance has  been related to patents, which isn't such a driver here
<RAOF> That and DRM.
<bryceh> yep
<RAOF> So there is something that's not yet there in the driver level - video decoding acceleration for !intel.
<bryceh> RAOF, so one thing I've been pondering is I'm aware there some new USB video and other alternate device thingamajigs.  
<bryceh> there's some legitimate packaging / x configure work needed to make those types of things work out of the box
<RAOF> It's probably too optimistic to expect that airlied'll finish the hotplug-enabled X server by 12.10, and they'll just work :/
<RAOF> What can we actually do out of the box?
<bryceh> not something I'm really interested in personally, but figure it's relevant for our users
<bryceh> right, yeah, I dunno
<RAOF> Having asked that question, it seems that this is probably worth a session :)
<bryceh> hand wavily we can just leave it to airlied to get it all working.  but yeah might be a while before it's perfect
<bryceh> no one has actually pinged me about any of this.  But I expect it's gonna be an expectation before too long.
<RAOF> People do occasionally go âhow do I get this to workâ and I don't have a good answer.
<bryceh> a large chunk of the problem is "detect available video devices on the usb bus"
<bryceh> for which I do  have  a pre-draft patch
<RAOF> Oooh, that'd be nice.
<RAOF> Although, of course, raises problem number 2: X really doesn't like driving two "cards".
<bryceh> xinerama!
<RAOF> :)
<bryceh> yeah, tip of the iceberg type problem
<RAOF> It's worth a discussion, though.
<bryceh> I don't know if you were cc'd but we got a support request bug last week for "How can I get 3 monitors working, using 1 Intel plus 2 nvidia?"
<bryceh> RAOF, aside from the wayland stuff what do you anticipate working on this cycle?
<RAOF> I think the wayland stuff might be a full cycle worth.
<RAOF> Apart from that, helping with whatever hwe needs done with hybrid graphics, and possibly getting that XRandR protocol we talked in Orlando about done.
<bryceh> RAOF, yes I do plan to get more done on that libxrandr-utils development work.  I'm fairly far along, it's mostly just the test writing that takes the time.
<bryceh> RAOF, one thing...  I'd like to not deal with bugs so much in 12.10.  I do plan to keep some focus on 12.04 bugs 
<RAOF> I'm happy to do the X-protocol-related bits of that, now that I feel fully steeped in that particular madness.
<RAOF> Ok.  Bug wrangling is much less fun than other stuff; if you'd like a spell, I can do that.
<bryceh> RAOF, great, well any help on libxrandr-utils would be welcomed.  I admit I've been a bit demotivated/distracted due to the lack of feedback there.
<bryceh> RAOF, yeah it is less fun, but still important
<RAOF> Absolutely!
<bryceh> on the plus side, it seems to be getting easier.
<bryceh> (on the less-plus side, the world seems to have no shortage of ignorant fools)
<bryceh> ok, reboot time. brb
<RAOF> I'm not sure that we can change that :)
<bryceh> nice; ctrl key works again (just no backlight, which is odd)
<bryceh> speaking of keyboards, I'd also like to focus a lot on keyboard bugs
<bryceh> I've been investigating one for mterry lately, and I think it taps into some more general issues with keyboard translation problems that I'd like to understand better
<RAOF> If you'd like to get deep into the keyboard stack, please be my guest.
<RAOF> Thar be dragons!
<tjaalton> yeah I was promised a lenovo displaylink monitor, wonder where it is :)
<tjaalton> but it'll need many bits to work ootb, not sure xserver 1.13 will be enough
<tjaalton> or kernel 3.5
#ubuntu-x 2012-04-28
<albert23> nice, [Intel-gfx] [PATCH v2] drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. fixes freeze on SNB running googleearth
 * albert23 left a note on 966631
#ubuntu-x 2012-04-29
<tjaalton> hmm, there's no point in nvidia-{96,173}-updates packages.. the major version is never going to change, and if there's an update to support newer xservers, the main package can be changed since they're broken now..
#ubuntu-x 2013-04-22
<llstarks|spare> i'll try to do an nvidia randr 1.4 write up over the next day or so
<llstarks|spare> works beautifully despite x limitations that cause tearing
<tjaalton> llstarks|spare: so xserver needs a rebuild
<erappleman> i'm not sure. libudev0 was needed to even pull in -core. input-all and video-all also got removed with most drivers
<erappleman> sorry again about nick confusion
<tjaalton> heh
<tjaalton> why do you need the new version again?
<erappleman> aaronp said that 1.13.y was needed for nvidia to use randr 1.4 properly. turns out it was actually 1.14.0
<erappleman> it took us more than a week to figure that out
<tjaalton> you tested with 1.13?
<erappleman> yes
<tjaalton> hm
<erappleman> the main problem was nvidia telling us to use .xinitrc instead of .xsessionrc
<tjaalton> xserver version doesn't change that :)
<erappleman> true, but nvidia's instructions were bs: https://devtalk.nvidia.com/default/topic/539322/linux/blank-screen-with-319-12-on-optimus-laptop/
<tjaalton> so what issues you had with 1.13?
<erappleman> the x session wouldn't display anything on the backlit screen, same result for everyone who tried to get optimus offloading working
<erappleman> 1.14 works, can't point to any particular commit
<tjaalton> ok
<tjaalton> how's powersaving working, or is nvidia enabled all the time?
<erappleman> nvidia is enabled the whole time. you display with modesetting or intel. there's no vsync due to x limitations.
<erappleman> powermizer does work
<mlankhorst> morning
<tjaalton> erappleman: I have no problem trying to upgrade to the staging ppa
<erappleman> unless i'm screwing up fresh installs, there's an abi disagreement
<mlankhorst> tjaalton: libudev0 is no longer available
<mlankhorst> and compiz no longer installs
<tjaalton> why does it not complain here then
<mlankhorst> because you have the old stuff still installed, I suppose
<tjaalton> libudev0 yes
<tjaalton> huh, intel-gpu-tools depends on it
<tjaalton> best to rebuild it then
<mlankhorst> I'm tossing a complete lts-raring rebuild in my ppa, for precise
<mlankhorst> yeah xserver needs a rebuild too
<tjaalton> and an upgrade to 1.14.1
<tjaalton> oh I had a snapshot of i-g-t that depended on libudev0
<tjaalton> no need to rebuild it
<tjaalton> updated inputproto too
<mlankhorst> can you pull the patches from 1.13.3 too?
<tjaalton> ah
<tjaalton> yeah
<tjaalton> mlankhorst: could you check xorg-server ubuntu+1 branch that it looks sane
<tjaalton> patches should match what is needed, and they apply
<mlankhorst> looks good
<tjaalton> thanks, I'll upload it
<tjaalton> to the ppa
<mlankhorst> I'd prefer it if the drm patch was rebased, but meh :P
<tjaalton> why would we need it still?
<mlankhorst> hm I guess we don't if the fix is backported to precise too
<tjaalton> it will
<tjaalton> fighting to get it in raring first..
<tjaalton> oh it was evdev that still needed a rebuild against libudev1
<mlankhorst> tjaalton: heh we should be able to land lts-raring as soon as we want to, at least..
<mlankhorst> Sarvatt: I need your magic abilities, how do I fix plymouthd: ply-terminal.c:630: ply_terminal_set_mode: Assertion `terminal != ((void *)0)' failed. ?
#ubuntu-x 2013-04-23
<bjsnider> i don't understand the alias created by the fglrx package. it says "alias fglrx fglrx"
<bjsnider> that whole section of the rules file is weird
<bjsnider> it's using variables, but they're being filled manually, not from out-of-control stuff
<bjsnider> i guess it would make sense if there was an alternate package with a different name than fglrx, like fglrx-updates or whatever
<bjsnider> but those could be different packaging scripts with different code
<bjsnider> PKG_driver      := fglrx
<bjsnider> PKG_module      := $(shell echo "$(PKG_driver)" | sed s/\-/_/g)
<bjsnider> don't know why that sed is in there
<bjsnider> it yields fglrx
<bjsnider> alias fglrx $(PKG_module)
<bjsnider> that is alias fglrx fglrx
<mlankhorst> morning
<tjaalton> mlankhorst: new test branch from whot
<mlankhorst> \o/
<mlankhorst> oh and he fixed up the conflict correctly now, good :)
<tjaalton> it's rebased with master I think
<tjaalton> the branch
<mlankhorst>     dix: always copy grabs, don't reference them
<mlankhorst> that one should fix the issue I was facing
<mlankhorst>     FIXME dix: remove TouchListenerGone hook
<mlankhorst> don't know about that one, seems to be a hack
<mlankhorst> ok let me build this on the n7
<tjaalton> building it straight or backported to 1.13+
<tjaalton> ?
<mlankhorst> straight + reverts
<tjaalton> right
<mlankhorst> I applied the reverts first then merged it in again
<mlankhorst> ok, nexus seems to be working now
<mlankhorst> lets see if i can build it..
<tjaalton> huh, unpacking ubuntu-docs seems to kill i/o on my machines
<mlankhorst> woops, forgot to enable debug, it doesn't crash but it seems that it still fails on touch after a while
<tjaalton> bah
<tjaalton> thanks for testing
<tjaalton> i've now uploaded plymouth to -proposed
<mlankhorst> or well, right away
<tjaalton> lightdm follows
<mlankhorst> I'll try with --enable-debug
<mlankhorst> \o/
<mlankhorst> fwiw, if we have the libdrm sru verified we could upload lts-raring to precise
<tjaalton> yeah
<mlankhorst> it builds on i386 and amd64, I disabled build for armel/armhf since that was unsupported anyway
<tjaalton> nice, apt-get autoremove cleans up old kernels
<tjaalton> also, it just occurred to me that I hadn't tested the new plymouth job on my desktop at all, before now :)
<tjaalton> 3/3 successful boots though
<tjaalton> 4
<tjaalton> after the tenth I'll call it a success and upload lightdm too
<mlankhorst> yay
<tjaalton> 10
<mlankhorst> I guess I'll go verify libdrm works across all we care about..
<tjaalton> mlankhorst: add your findings to the touch bug :)
<mlankhorst> I told whot in private, he knows
<mlankhorst> 11:43 <whot> really? that's a new instance of that bug then because it passes all the tests
<mlankhorst> 11:43 <whot> well, all except one, which is probably what you're seeing
<mlankhorst> 11:44 <whot> actually, that even makes sense - you triggered the bug when ungrabbing during a touch point and that's the test case I just added and it fails atm
<mlankhorst> it was the same testcase that crashed before :-)
<tjaalton> ah, good
#ubuntu-x 2013-04-24
<FernandoMiguel> lot's of video corruption when using multi display on my Intel HD3000 :(
<FernandoMiguel> best way to report this ?
<tjaalton> what release?
<FernandoMiguel> as usual for me, +1
<FernandoMiguel> aka 13.04
<tjaalton> ubuntu-bug xserver-xorg-video-intel
<FernandoMiguel> collecting
<FernandoMiguel> uploading
<FernandoMiguel> tjaalton: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1172450
<ubottu> Launchpad bug 1172450 in xserver-xorg-video-intel (Ubuntu) "video corruption on multi display" [Undecided,New]
<FernandoMiguel> leaving for a few minutes to grab dinner. feel free to ask any further info
<shadeslayer> hi, I'm trying to get X up on the Nexus 10 and it seems to start but there's nothing on the screen : http://paste.kde.org/731666/
<shadeslayer> any ideas?
<shadeslayer> lightdm log : http://paste.kde.org/731672/
<FernandoMiguel> back
#ubuntu-x 2013-04-25
<mlankhorst> g'day
<MCR> ricotz, hi :)
<MCR> New fglrx is out...
<zzippy> anybody tested the new packages 1.14.1 from X-staging PPA on Raring daily? They do not work, had to downgrade to 1.14.0
<zzippy> ..and install libudev0 ;)
<tjaalton> hmm, wonder why
<mlankhorst> hmz *looks*
<mlankhorst> tjaalton: worksforme, at least
<Sarvatt> works for me also
<mlankhorst> tested on intel and radeon, i could try nouveau too I suppose
<mlankhorst> nouveau works too
<wolfgang8741> anyone have a 3 monitor display to help reproduce and/or familiar with mesa to help diagnose https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1170418
<ubottu> Launchpad bug 1170418 in compiz (Ubuntu) "Unity Launcher and window borders missing upon login when using 3 monitors" [Undecided,Confirmed]
<mlankhorst> wolfgang8741: downgrade to 9.0.3 first to see if it works or not
<mlankhorst> also..
<mlankhorst> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<mlankhorst> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<mlankhorst> and killed with 7, which is SIGBUS. You probably want to install libgl1-mesa-dri-dbg and libgl1-mesa-glx-dbg to get a backtrace from compiz
<wolfgang8741> mlankorst: thanks, this is my first downgrade which mesa package(s) do I force downgrade on?
<Sarvatt> everything in dpkg -l "*mesa*" | grep 9.1.1
<Sarvatt> also you will have to install libllvm3.1 again if it got autoremoved
<Sarvatt> the debs are available at https://launchpad.net/ubuntu/+source/mesa/9.0.3-0ubuntu1/+build/4369527 and https://launchpad.net/ubuntu/+source/mesa/9.0.3-0ubuntu1/+build/4369525
<wolfgang8741> thanks again, I'll post the results to the bug later today, I have to finish up some work now.
<mlankhorst> Sarvatt: any bets on too much memory to be pinned to vram? :p
<mlankhorst> oh looks like you can mmap invalid regions too
#ubuntu-x 2013-04-26
<Heis> quick question; will the x-swat ppa become available for raring?
<Heis> yes, stupid question. i take it all back ;)
#ubuntu-x 2013-04-27
<penguin42> I'm triaging bug 1173649   - are there any similar reports; wrong bitdepth on intel graphics, seems an odd failure
<ubottu> bug 1173649 in xorg (Ubuntu) "incorrect color depth - intel graphics card" [Undecided,New] https://launchpad.net/bugs/1173649
#ubuntu-x 2014-04-22
<ricotz> mlankhorst, hi, copying wine1.7 builds from saucy to trusty isnt easily working anymore while libtiff4 is gone
<mlankhorst> oh :/
<mlankhorst> hm
 * mlankhorst copies libtiff4
<mlankhorst> would that cause anything unexpected to happen?
<ricotz> it might work, but i would prefer proper builds for every pocket rather than binary copies ;)
<mlankhorst> meh but I'm lazy
<ricotz> with a nice versioning
<ricotz> i see ;)
<mlankhorst> fine I'll look
<ricotz> thanks
<mlankhorst> ok updated my scripts
#ubuntu-x 2014-04-24
<zer0def> let's try here: would there be a way to revert xorg to 1.13 in trusty for the purpose of running fglrx-legacy? tried looking for ppas, but so far, no results; before i simply go and start pulling down packages from previous releases, i would prefer to be sure i won't stumble on something laughably easy and break my xserver ;)
<jcristau> if you want to use an earlier release, run an earlier release?
<zer0def> that's the thing, i don't want to run an earlier release of the distro, just an earlier xorg
<zer0def> and that's only because amd aren't keen on keeping up with xorg devel
<tseliot> even if you manage to run an old X without breaking the rest of the system, are you sure the module will build against Trusty's kernel?
<zer0def> yes, amd's installer provides packages for trusty
<zer0def> and it DID build
<zer0def> except for the annoying fact stated above
<tseliot> that doesn't mean it will work
<zer0def> well, i have no other way of finding out, except attempting to run it on what it's capable of running.
<tseliot> you'll have to get around the reverse dependencies: http://paste.ubuntu.com/7321327/ 
<tseliot> it's not something I would recommend
<tseliot> doesn't the open driver work for you?
<zer0def> it does, just not quite the way i want it to ;)
<zer0def> yeah, most of those depends i'd probably fill just fine
#ubuntu-x 2014-04-27
<Azelphur> I'm suffering from this bug, https://github.com/ValveSoftware/steam-for-linux/issues/2285 does anyone have any suggestions? one of the replies says to use RandR, but I didn't think RandR was a replacement for Xinerama?
<pkern> Don't use xinerama?
<pkern> It is.
<Azelphur> pkern: I didn't think I could not use xinerama if I had 4 displays, 2 graphics cards.
<Azelphur> short of separate X screens anyway, which is it's own kettle of buggyness
#ubuntu-x 2015-04-21
<furkan> tjaalton: the new radeon TearFree feature fixes my problem
<tjaalton> furkan: guess it just hides the problem then
<boax> hello
<boax> there is a critical bug in ubuntu 15.04!
<boax> i am talking in #ubuntu-devel and in  #xorg-devel
<boax> in two days there should be the release of 15.04 and its fully unusable on some machines!
<boax> how to reproduce: dd the most recent daily build into an usb pendrive, boot from it, open libreoffice -> there is an Xorg server crash
<boax> http://pastebin.com/9K0W1NwU
<boax> this report here looks same: https://bbs.archlinux.org/viewtopic.php?id=195666
<RAOF> boax: Is there an Ubuntu bug filed?
<boax> RAOF: i was able to face that all down
<boax> http://pastebin.com/9K0W1NwU
<boax> is related to an gnome 3.14 bug
<RAOF> boax: You should have got a prompt to submit an error report to Launchpad?
<boax> RAOF: check the last message here: https://bbs.archlinux.org/viewtopic.php?id=194819
<boax> the bug is somewhat strange. it come on few machines but on those machines it always come
<boax> and makes those machines somewhat unusable
<RAOF> Sure.
<RAOF> Have you filed a bug on launchpad?
<RAOF> Have you got a âsubmit errorâ popup?
<boax> i cant beleive that i am the only one with that bug
<boax> or are there only that few people who test upcomming versions like 15.04?
<RAOF> Because if you submit the bug that way, it'll come attached with all sorts of useful debugging information.
<boax> the solution for the bug seem to be: backport some things from recent gnome versions that fix that error or bump the version of gnome to the recent one that dont cause this error
<RAOF> Neither of those is the solution to an X server crash.
<RAOF> At best, that's a workaround.
<RAOF> If you submit the bug report to Launchpad we'll get a full backtrace, with symbols, and it'll be much more likely that we can fix it.
<boax> RAOF: you are a dev that could help when reported the way you explain here?
<RAOF> Yes.
<boax> okay. to help you providing the information you need i have to start the system that crashes, let it crash and then when it ask me if it should send the crash report  have to answer yes?
<boax> how can that be done on an machine that does not have an internet connection?
<RAOF> Hah. That's a little more difficult, but not too much.
<boax> i have an usb pendrive that can travel the data from the one to the other machine
<RAOF> When the machine crashes it should generate a /var/crash/_usr_bin_X_something_or_other.crash file.
<boax> okay. i get that for you :)
<RAOF> On a machine with an internet connection you can then run âubuntu-bug that_crash_fileâ, and it'll do the reporting bits.
<boax> RAOF: okay. i have the file after making it 777 to be able to copy it to the usb pendrive as a normal user. its about 5mb. the machine i have internet on is not ubuntu. should i upload the file to you?
<RAOF> Ok; if you can put it somewhere I can download it.
<boax> uploading... have you already an idea on what part the bug could be? Xorg server?
<RAOF> If the X server's crashing it's an X bug.
<RAOF> (Almost certainly)
<boax> you got the file? Check your query ;)
<RAOF> Yup.
<RAOF> You've hit https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1443456
<ubottu> Launchpad bug 1443456 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in fbBltOne()" [Medium,New]
<boax> i told tarpman that he was right with guessting that this could be the error :)
<boax> can i help somehow to debug that error?
<boax> i think its more then "Medium". Its critical or blocking
<boax> RAOF: can i do something else to help you debugging this error?
<RAOF> No, it seems pretty obvious what the immediate problem is; glamor shouldn't be passing in a NULL destination to fbCopy.
<RAOF> This doesn't look like something that should block the release, but should be fixed in an early update.
#ubuntu-x 2015-04-22
<boax> why not fixed now when its that clear?
<boax> the freeze time is exactly for this cases, not?
<RAOF> Because although the immediate cause is obvious, the reason why glamor is passing NULL isn't (yet).
<RAOF> And because, as per the errors.ubuntu.com, this seems to be reasonably infrequently hit.
<boax> errors.ubuntu.com would be the place where this 5 mb file have been gone normaly?
<RAOF> Pretty much, yeah.
<boax> how does is care that people dont report the same bug around 100 times?
<RAOF> By being in the process before people do the work to report the bug.
<RAOF> It's one of the parts that handles duplicate detection, for example.
<boax> Dont fully understand. When i turn off the live system, start it again, report the bug, turn it off again, start it again, report gaian, ... how does the system detect that i am the same user all the times?
<RAOF> It doesn't. It does, however, detect that your thing has crashed again.
<boax> any why my and not the computer from someone else?
<RAOF> Which is what we're more interested in - a crash which affects 100 users once a month is not more interesting than a crash which affects 3 users every day.
<boax> RAOF: when the update is been released and the system is been installed with enabled "install updates during installation". would that fix be also included?
<RAOF> Yes
<boax> i have not understand what things are loaded there. It does not seem to be something like an apt-get upgrade
<RAOF> That's basically what it does, yes.
<boax> ?? but when i start the fresh installed system and run an apt-get update and after that an apt-get upgrade i get tons of updates
<boax> how can that be when i have already installed all the updates thanks to an apt-get upgrade before?
<RAOF> Is this on a stable release, or on a pre-release image? Because there's tons of upgrades all the time for pre-release images.
<boax> RAOF: stable release 14.10
<boax> when you would like to see what i mean take an stable 14.10 and install it with connected internet. after that run apt-get update and then apt-get upgrade. you would get tons of updates
<boax> have to go now. thanks a log RAOF 
<boax> thanks a lot i mean
#ubuntu-x 2015-04-23
<bandit-led> any way to get dkms to build modules for kernel 4 ?
<bandit-led> sudo dpkg-reconfigure nvidia-349 works but i have to install kernel and boot into non gui and run it
<bandit-led> sudo dkms install -m nvidia -v 349-349.16 -k 4.0.0-rc1-02232015 does not work like it used to
<bandit-led> running 349.16 on ubuntu 15.04
<bandit-led> /var/lib/dkms/nvidia/349-349.16/build/make.log http://pastebin.ubuntu.com/10868933/
#ubuntu-x 2015-04-24
<bgd> Hi everyone! I have a synaptics with 3-finger-swipe capability (as shown by xinput list-props) and I wonder how I can activate that in Unity, so that e.g. I can change the workspace with it?
<tjaalton> no idea, try #ubuntu-unity
#ubuntu-x 2015-04-25
<bandit-led> so back to the dkms issue lots of us are having since uvm was changed from a separate package into nvidia-3xx
<bandit-led> copying /usr/src/nvidia-349-349.16/uvm to /usr/src/nvidia-349-uvm-349.16 and using the dkms files from https://launchpad.net/~mamarley/+archive/ubuntu/nvidia/+files/nvidia-349_349.16-100ubuntu100%7Eppa0%7Evivid_amd64.deb
<bandit-led> dkms builds both the nvidia and the nvidia-uvm modules correctly
<bandit-led> sudo dkms install -m nvidia -v 349-349.16 -k 4.0.0-rc1-02232015
<bandit-led> sudo dkms install -m nvidia-349-uvm -v 349.16 -k 4.0.0-rc1-02232015
<bandit-led> and the dkms from https://launchpad.net/~mamarley/+arc...ivid_amd64.deb copied into /usr/src/nvidia-349-uvm-349.16
<bandit-led> as i posted on the forums i gave myself a headache trying to figure out the dkms file from xorg-edgers and patching it..
<bandit-led> so if some one could build upon what mamarley has fixed in his release we could get a fix added to xorg-edgers that would take care of a bunch of bugs on the tracker. 
#ubuntu-x 2016-04-25
<Guest55073> I have a Nvidia GTX 580 card and looking to add support for Vulkan on my Ubuntu 14.04. I found this https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan. Would it work for me? I think not (since the GTX 580 is not supported by Nvidia) but I wanted to check.
<mariogrip> is there known bug that nvidia proprietary drivers not working in 16.04? I tested 15.10 and they work perfectly 
<tjaalton> no
<mariogrip> that's weird, I even tried to reinstall 16.04, they don't even work on fresh install
#ubuntu-x 2016-04-26
<palodequeso_> So... how does one enable DRI3 in ubuntu 16.04 with the vulkan drivers on an intel graphics chip?
<alkisg> Hi, ubuntu-mate has a file named /usr/share/X11/xorg.conf.d/90-zap.conf that does:
<alkisg>     Option "XKbOptions" "terminate:ctrl_alt_bksp"
<alkisg> But this deletes the settings defined in /etc/default/keyboard, instead of appending to them
<alkisg> Is there any syntax that allows appending xkboptions rather than overriding them?
<alkisg> I've filed that in: https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1574789
<ubottu> Launchpad bug 1574789 in ubuntu-mate-settings (Ubuntu) "xorg.conf.d/90-zap.conf destroys xorg keyboard settings" [Undecided,New]
#ubuntu-x 2017-04-26
<tjaalton> ricotz: you can just ping here if you want libdrm etc synced
<tjaalton> no need to file bugs
#ubuntu-x 2018-04-25
<mamarley> ricotz: On a whim I decided to try NVIDIA 396 with xorg 1.20-RC5 and it almost works.  It doesn't even complain about ABI mismatch, but for some reason the GLX module fails to load.
<ricotz> mamarley, hmm, a new xserver release without ABI breaks doesn't sound right
<tjaalton> are you sure it doesn't already support the abi?
<mamarley> ricotz: 1.20 does go from ABI 23 to 24 (and trying to run it with NVIDIA 390 does make an ABI warning).
<mamarley> But with both drivers, the GLX module fails to load (it says something about too many errors, despite no errors having been printed in the X log).
<ricotz> tjaalton, hmm, I thought the last bump was for 1.19, but yeah, abi 24 is for 1.20 which doesn't mean they broke/finalized it last minute ;)
<mamarley> I'm curious as to why the GLX module fails to load if the ABI is supported though.
<ricotz> (the bump to abi 24 was done over a year ago)
<ricotz> (so don't take this number check for evidence)
#ubuntu-x 2018-04-26
<ricotz> mamarley, hi, regarding your testing with xserver 1.20, did you try 396.18.05 yet?
<mamarley> ricotz: Didn't even know that was out.  Thanks for letting me know, I will give it a shot.
<ricotz> ok, maybe they fixed something
<ricotz> tjaalton, hi, did you get to vulkan 1.1.73 yet?
<mamarley> I've had *lots* of people emailing me about how 396 causes problems with KDE Plasma, but I haven had any trouble. *shrug*
<mamarley> ricotz: Nope, still the black screen and GLX loading failure.  The error I get is "[     4.571] (EE) Not enabling extension GLX: maximum number of events or errors exceeded."
<ricotz> ok :(
<mamarley> 1.20 has been problematic for my hardware.  Obviously NVIDIA won't work yet and one of my Intel systems won't work in multimonitor mode with it (I get constant page flip resource allocation failures and flickering screens).
<mamarley> I have a bug open about that but it hasn't seen much attention.
<ricotz> I se
<ricotz> e
<ricotz> I don't dare to test it yet ;)
<mamarley> It isn't too bad to test.  In the worst case, I just roll back to 1.19.6 and it works again.
<mamarley> It isn't like testing kernels where one bug in the wrong place can corrupt your disk. :P
<mamarley> I guess NVIDIA's GLX module has some incompatibility with 1.20.  I just hope they go ahead and fix it in 396 instead of waiting for the next major release.
<mamarley> ricotz: Oh, and someone in another channel randomly posted a solution to the problem of having so many more packages to install when testing the new-style NVIDIA packaging: "sudo apt install --only-upgrade ../path/to/package_arch.changes".  That will automatically upgrade all installed packages using the built packages.
<tjaalton> ricotz: nope
<ricotz> mamarley, nice
<ricotz> tjaalton, ok, hoping you will soon :)
#ubuntu-x 2019-04-23
<mamarley> ricotz: I have 430.09 in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
