#ubuntu-x 2007-04-09
<ubotu> New bug: #104569 in xserver-xorg-video-via (main) "glxgears crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104569
<ubotu> New bug: #13530 in linux-restricted-modules-2.6.15 (restricted) "nvidia-glx crashes/lockups" [Medium,Needs info]  https://launchpad.net/bugs/13530
<ubotu> New bug: #103416 in libx11 (main) "after upgrade opera segfault" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103416
<ubotu> New bug: #104694 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104694
<ubotu> New bug: #50451 in xorg (main) "Mouse movement wreak havoc" [Undecided,Needs info]  https://launchpad.net/bugs/50451
<ubotu> New bug: #104742 in xrandr (main) "doesnt allow rotation to be set" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104742
<ubotu> New bug: #104750 in libxrender (main) "dapper: thunderbird crashes after upgrade at 2007-03-11 when ms-ttf-tahoma installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104750
<ubotu> New bug: #104757 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104757
<ubotu> New bug: #104761 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104761
<ubotu> New bug: #95231 in xkeyboard-config (main) "[gnome-keyboard-properties]  l10n is broken" [Low,Unconfirmed]  https://launchpad.net/bugs/95231
<pochu> hey tepsipakki :-) how does the x-x-v-intel testing goes?
<pochu> will have it in universe for feisty? :-)
<tepsipakki> it was uploaded but rejected because of a missing copyright files
<tepsipakki> it will be added later this week
<pochu> cool :)
<crimsun> nice
<tepsipakki> funny that it got in debian :)
<tepsipakki> since the package is basically the same
<Treenaks> tepsipakki: with the broken copyright files? :)
<tepsipakki> yes
<Treenaks> tepsipakki: wow.. because they're really anal about that (not even ipw2200 is working in etch for me.. *growl*)
#ubuntu-x 2007-04-10
<ubotu> New bug: #104978 in xrandr (main) "[apport]  xrandr crashed with SIGSEGV in XRRGetScreenInfo()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104978
<ubotu> New bug: #104937 in xserver-xorg-video-unichrome (universe) "Unsupported chipset - VT3230 " [Undecided,Unconfirmed]  https://launchpad.net/bugs/104937
<ubotu> New bug: #96036 in xorg-server (main) "Blutooth DiNovo does not work after boot" [Undecided,Confirmed]  https://launchpad.net/bugs/96036
<ubotu> New bug: #104889 in linux-restricted-modules-2.6.20 (restricted) "s2ram followed by s2disk fails" [Medium,Confirmed]  https://launchpad.net/bugs/104889
<ubotu> New bug: #104997 in xserver-xorg-input-synaptics (main) "synaptics touchpad on acer aspire not working after update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104997
<ubotu> New bug: #97332 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx upgraded ahead of nvidia-glx-legacy (dup-of: 96430)" [Undecided,Needs info]  https://launchpad.net/bugs/97332
<ubotu> New bug: #28425 in xorg (main) "xbase-clients: xkbcomp or xmodmap or libxkbfile or libxklavier problem don't start XKB" [High,Rejected]  https://launchpad.net/bugs/28425
<ubotu> New bug: #104225 in restricted-manager (main) "Restricted drivers manager loses nvidia (dup-of: 93209)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104225
* Starting logfile irclogs/ubuntu-x.log
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #96486 in update-manager "u-m should automatically install nvidia-glx-legacy if hardware requires it" [Medium,Confirmed]  https://launchpad.net/bugs/96486
<ubotu> New bug: #105191 in linux-restricted-modules-2.6.20 (restricted) "restarting xserver (or switching back to ctrl+alt+F7 from ctrl+alt+F1-6) hangs/crashes/freezes system with fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105191
<ubotu> New bug: #105206 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105206
<ubotu> New bug: #41272 in linux-restricted-modules-2.6.15 (restricted) "[FGLRX]  kernel drivers kills USB subsystem" [High,Confirmed]  https://launchpad.net/bugs/41272
<ubotu> New bug: #104993 in xorg (main) "X does not start when booting from 7.04 beta CD" [Undecided,Needs info]  https://launchpad.net/bugs/104993
<ubotu> New bug: #105287 in xorg (main) "dpkg-reconfigure xserver-xorg -phigh or -pmedium should add Load "glx"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105287
<ubotu> New bug: #105282 in linux-restricted-modules-2.6.20 (restricted) "Resolution is down to 1024x768 from 1280x1024 after enabling restricted ati driver.." [Undecided,Needs info]  https://launchpad.net/bugs/105282
<ubotu> New bug: #105312 in xorg (main) "OpenGL apps crash X.org with 3dfx cards when libglide3 is missing" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105312
<ubotu> New bug: #105285 in nvidia-kernel-common (restricted) "nvidia-glx installed itself over Nvidia propriatary" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105285
#ubuntu-x 2007-04-11
<ubotu> New bug: #39941 in xserver-xorg-input-synaptics (main) "Mouse on laptop flaky" [Medium,Unconfirmed]  https://launchpad.net/bugs/39941
<ubotu> New bug: #105379 in xorg (main) "X crashes after logging out in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105379
<ubotu> New bug: #105385 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-new X.org driver modprobes nivida, not nvidia_new" [High,Unconfirmed]  https://launchpad.net/bugs/105385
<ubotu> New bug: #105408 in linux-restricted-modules-2.6.20 (restricted) "ubuntu xorg-driver-fglrx 7.1.0-8.34.8+2.6.20.5-14.18 upgrade broke X-server with ATI Radeon 9600 pro deluxe" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105408
<ubotu> New bug: #105115 in linux-restricted-modules-2.6.20 (restricted) "dist-upgrade installArchives() failed" [High,Confirmed]  https://launchpad.net/bugs/105115
<ubotu> New bug: #105443 in linux-restricted-modules-2.6.20 (restricted) "DRI disabled with fglrx in feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105443
<ubotu> New bug: #102626 in xorg (main) "feisty fawn doesn't start graphical /xwindows at all" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102626
<ubotu> New bug: #105477 in linux-restricted-modules-2.6.20 (restricted) "Nvidia glx 9631 doesn't initialize Dell 20" 2005FPW" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105477
<ubotu> New bug: #105403 in linux-restricted-modules-2.6.20 (restricted) "[Feisty]  Compiz doesn't allow to unlock the screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105403
<ubotu> New bug: #90275 in linux-restricted-modules-2.6.20 (restricted) "can't start X after installing nvidia-glx" [Medium,Unconfirmed]  https://launchpad.net/bugs/90275
<ubotu> New bug: #82312 in linux-restricted-modules-2.6.20 (restricted) "[feisty]  X is blank after upgrade" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82312
<ubotu> New bug: #105580 in xorg (main) "X does not come up on amd64 livecd with nvididia 6600 (misdetected as s3viige?!?)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105580
<ubotu> New bug: #105574 in xorg (main) "Firefox often fails to start on kubuntu feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105574
<ubotu> New bug: #105583 in xserver-xorg-video-via (main) "via drm bug in kernel 2.6.20" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105583
<ubotu> New bug: #105593 in linux-restricted-modules-2.6.20 (restricted) "claims that nvidia is in use on live system" [High,Unconfirmed]  https://launchpad.net/bugs/105593
<ubotu> New bug: #105592 in restricted-manager (main) "claims that nvidia is in use on live system (dup-of: 105593)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105592
<ubotu> New bug: #89290 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-legacy driver crashes xorg on startup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89290
<ubotu> New bug: #73102 in linux-restricted-modules-2.6.20 (restricted) "ATI Radeon AVIVO Video -> 'Blue' tv" [Low,Confirmed]  https://launchpad.net/bugs/73102
<ubotu> New bug: #105581 in xorg (main) "Problems with Ubuntu 7.04 -restricted driver manager" [Undecided,Needs info]  https://launchpad.net/bugs/105581
<ubotu> New bug: #105629 in xorg (main) "DPMS not working with tdfx driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105629
<ubotu> New bug: #105534 in xorg (main) "ATIX700" [Undecided,Needs info]  https://launchpad.net/bugs/105534
<ubotu> New bug: #105637 in linux-restricted-modules-2.6.20 (restricted) "Network-Manager not working with madwifi" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105637
<ubotu> New bug: #95541 in linux-restricted-modules-2.6.20 (restricted) "Toshiba Laptop - GDM Fails After Logout" [Medium,Needs info]  https://launchpad.net/bugs/95541
<ubotu> New bug: #105647 in xorg (main) "[feisty]  changing user locks mouse" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105647
<ubotu> New bug: #105656 in xserver-xorg-video-i810 (main) "wrong white and black levels in xv with i810" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105656
<ubotu> New bug: #105658 in xorg (main) "X crashes when switching to console while KDE is starting up" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105658
<ubotu> New bug: #105660 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105660
<ubotu> New bug: #105692 in xorg-server (main) "[PATCH]  Some memory leaks fixed from upstream" [Undecided,Fix committed]  https://launchpad.net/bugs/105692
#ubuntu-x 2007-04-12
<ubotu> New bug: #105755 in mesa (main) "glx crashes on launch" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105755
<ubotu> New bug: #105756 in linux-restricted-modules-2.6.20 (restricted) "/sbin/lrm-manager allows nvidia_new .ko module to get loaded when DISABLED_MODULES="nv" in /etc/default/linux-restricted-modules-common" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105756
<ubotu> New bug: #96092 in xorg (main) "installed ubuntu can't get 1024x768 stuck with 800x600" [Undecided,Needs info]  https://launchpad.net/bugs/96092
<ubotu> New bug: #105760 in xorg (main) "Wron resolution on NVIDIA + DELL 2405FPW" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105760
<ubotu> New bug: #105790 in xorg-server (main) "xserver-xorg configuration with standard installer defaults to the vesa driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105790
<ubotu> New bug: #105788 in linux-restricted-modules-2.6.20 (restricted) "ATI Radeon X1600 PCI-Express is not working with FGLRX driver. Only brown empty screen appears." [Undecided,Unconfirmed]  https://launchpad.net/bugs/105788
<ubotu> New bug: #105673 in linux-restricted-modules-2.6.20 (restricted) "Switching to a vt and back often makes x session unusable if compiz is running" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105673
<ubotu> New bug: #105836 in linux-restricted-modules-2.6.20 (restricted) "[feisty]  "black screen" is not black" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105836
<ubotu> New bug: #104356 in totem (main) "play/pause keyboard button not working in totem (dup-of: 37225)" [Wishlist,Needs info]  https://launchpad.net/bugs/104356
<ubotu> New bug: #32715 in linux-restricted-modules-2.6.15 (restricted) "kernel module mismatch" [Medium,Unconfirmed]  https://launchpad.net/bugs/32715
<ubotu> New bug: #96900 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-legacy doesn't start GLX" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96900
<ubotu> New bug: #57118 in linux-restricted-modules-2.6.17 (restricted) "kernel and X module version missmatch" [Undecided,Unconfirmed]  https://launchpad.net/bugs/57118
<ubotu> New bug: #105862 in xorg (main) "Mirai DTL-642E500 42' LCD in 1920x1080" [Undecided,Needs info]  https://launchpad.net/bugs/105862
<tepsipakki> kylem: where is the ubuntu kernel git hosted?
<kylem> we have an internal tree, but it's also pushed to git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-feisty.git
<kylem> (or ubuntu-2.6.git for the 'in development' tree for ubuntu+1)
<tepsipakki> ah, thought so
<tepsipakki> it was requested a while ago that we maintained the xorg changes in git, so debian could pull them easily
<kylem> it would be optimal probably to use git.debian.org and an ubuntu branch, i think
<tepsipakki> but the problem is where to put it, since bzr is the blessed vcs :)
<kylem> we don't have any git hosting infrastructure atm.
<kylem> tepsipakki, do you have an alioth.debian.org account?
<tepsipakki> yes, that's what I thought too
<tepsipakki> yes
<kylem> alternately, you can use repo.or.cz which offers public hosting, or i can set you up with access to other places if you need it
<tepsipakki> ok, thanks.. good to know
<kylem> np.
<tepsipakki> maybe I'll ask the debian guys first :)
<tepsipakki> ..and it's ok to host them in git.d.o :)
<kylem> cool
<tepsipakki> at least jcristau didn't object, and thought that dnusinow won't either
<ubotu> New bug: #105927 in xorg (main) "X is strange when shifting from X to console and back. " [Undecided,Unconfirmed]  https://launchpad.net/bugs/105927
<ubotu> New bug: #105928 in linux-restricted-modules-2.6.20 (restricted) "binary nvidia 1.0.9631 crashes X on startup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105928
<Mithrandir> tepsipakki: prod; about the video-ati upload.  Is it needed for the release?
<tepsipakki> no
<tepsipakki> it just reverted the change in previous upload (which didn't build)
<tepsipakki> maybe it could've been dealt otherwise
<Mithrandir> hm, so we have an out-of-date at the moment due to it?
<tepsipakki> what do you mean by that?
<Mithrandir> xserver-xorg-video-ati currently fails to build due to that patch?  So it's just a revert of what's between 1:6.6.3-2ubuntu4 and 1:6.6.3-2ubuntu5?
<tepsipakki> yes
<Mithrandir> ok, accepted
<tepsipakki> ah :)
<tepsipakki> what about -intel?
<Mithrandir> that's universe, isn't it?
<tepsipakki> it would replace -i810-modesetting not -i810, and yes it's universe
<Mithrandir> I'm tempted to say we accept it even with the licence problem.
<tepsipakki> the license "problem" is the same with rest of the xorg :)
<tepsipakki> well, it's a problem and upstream knows about it, but not a top priority
<tepsipakki> also, I have a fix ready for bug 89853
<ubotu> Malone bug 89853 in xorg-server "[regression]  7.2 broke vesa: "No matching modes found"" [Medium,Confirmed]  https://launchpad.net/bugs/89853
<tepsipakki> although it hasn't been tested to work yet
<tepsipakki> but the concept is used for various other similar situations
<Mithrandir> ugh, we probably want that in too, yes.
<ubotu> New bug: #105957 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx should add [Option "UseEDID" "False"]  to [Section "Device"]  in xorg.conf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105957
<tepsipakki> hm, I'll modify the patch a bit
<tepsipakki> the proposed version won't work
<tepsipakki> Mithrandir: what do you think of bug 103902? Pretty obvious to me
<ubotu> Malone bug 103902 in xserver-xorg-input-evdev "X crashes when using evdev: undefined symbol xf86OSRingBell" [Undecided,Confirmed]  https://launchpad.net/bugs/103902
<tepsipakki> and dead simple
<Mithrandir> I think I need sleep. :-)
<Mithrandir> sorry, see you tomorrow.
<tepsipakki> hehe, do that!
<tepsipakki> I'll just upload these :)
<ubotu> New bug: #105966 in iceauth (main) "gdm in loop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105966
<ubotu> New bug: #105967 in linux-restricted-modules-2.6.20 (restricted) "nvidia autoinstall 1900x1200 not working" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105967
<ubotu> New bug: #105968 in linux-restricted-modules-2.6.20 (restricted) "nvidia autoinstall 1900x1200 not working" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105968
<ubotu> New bug: #104105 in xorg (main) "[feisty]  gnome-display-properties reports incorrect refresh rate ?" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104105
<ubotu> New bug: #99468 in xorg (main) "feisty, display fails when quitting" [Undecided,Confirmed]  https://launchpad.net/bugs/99468
#ubuntu-x 2007-04-13
<ubotu> New bug: #5741 in xkeyboard-config (main) "Another problem with mac keyboard" [Medium,Needs info]  https://launchpad.net/bugs/5741
<ubotu> New bug: #13379 in xserver-xorg-driver-nv (main) "[nv]  screen needs reinit after lid open/shut" [Medium,Rejected]  https://launchpad.net/bugs/13379
<ubotu> New bug: #9181 in xorg (main) "xbase-clients: [setxkbmap]  Segmentation fault" [Medium,Rejected]  https://launchpad.net/bugs/9181
<ubotu> New bug: #106148 in linux-restricted-modules-2.6.20 (restricted) "[fglrx]  Scrambled mouse pointer and parts of screen in big desktop mode" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106148
<ubotu> New bug: #104989 in linux-restricted-modules-2.6.20 (restricted) "Totem: YUV video, U/V components are swapped" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104989
<ubotu> New bug: #106181 in xorg (main) ""turn off" from kde menu crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106181
<ubotu> New bug: #106015 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Medium,Unconfirmed]  https://launchpad.net/bugs/106015
<ubotu> New bug: #106202 in xserver-xorg-video-i810 (main) "Fiesty Herd5 Live CD incorrectly boots at 640*480" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106202
<ubotu> New bug: #106191 in xorg (main) "suspend to ram not working since last kernel update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106191
<ubotu> New bug: #106199 in xorg (main) "[feisty]  50% of cpu when a page is waiting to load" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106199
<tepsipakki> oh goody
<tepsipakki> seems that discover-data changed the ATI vendor string in August
<tepsipakki> so all the trickery we had in xserver-xorg.postinst didn't work
<Mithrandir> heh
<tepsipakki> the new version should fix at least some post-dapper regressions..
<tepsipakki> Mithrandir: ok to upload?
<tepsipakki> http://users.tkk.fi/~tjaalton/dpkg/xorg.debdiff
<tepsipakki> I'll upload it, since I need to run elsewhere now.. leave it in the queue if it's not suitable
<Mithrandir> thanks.
<Mithrandir> sorry, I get dragged in half a zillion directions here so I keep being distracted.
<tepsipakki> heh :)
<tepsipakki> ->
<ubotu> New bug: #105138 in linux-restricted-modules-2.6.20 (restricted) "nvidia-settings wont work with nvidia legacy driver" [Undecided,Confirmed]  https://launchpad.net/bugs/105138
<ubotu> New bug: #106317 in xorg (main) "Xserver not working after installing dapper ati drivers" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106317
<ubotu> New bug: #106345 in xserver-xorg-video-i810-modesetting "i810 modesetting doesn't work with resolution 1366x768" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106345
#ubuntu-x 2007-04-14
<ubotu> New bug: #106395 in xresprobe (main) "Flat panel resolution 1680x1050 not detected for laptop with ATI X1400" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106395
<ubotu> New bug: #12838 in xorg (main) "[radeon]  dpms and backlight don't play happily" [Medium,Fix released]  https://launchpad.net/bugs/12838
<ubotu> New bug: #106414 in xserver-xorg-video-ati (main) "[Feisty]  DPMS no longer switches off backlight on radeon" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106414
<ubotu> New bug: #106415 in linux-restricted-modules-2.6.20 (restricted) "Conflicting package conflict; nvidia-glx-new" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106415
<ubotu> New bug: #106434 in linux-restricted-modules-2.6.20 (restricted) "2.6.20-15-generic breaks X when using NVIDIA-glx drivers" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106434
<ubotu> New bug: #16887 in xorg (main) "[i810]  won't do lower modes on default laptop sync ranges" [Medium,Confirmed]  https://launchpad.net/bugs/16887
<ubotu> New bug: #40700 in xorg (main) "16:9 aspect ratios have corrupt display Dapper Beta" [Medium,Needs info]  https://launchpad.net/bugs/40700
<ubotu> New bug: #82189 in xserver-xorg-video-i810-modesetting (universe) "Using xserver-xorg-video-i810-modesetting results in a blank screen" [Undecided,Confirmed]  https://launchpad.net/bugs/82189
<ubotu> New bug: #34208 in xorg (main) "offer to set higher screen resolutions if autodetection fails (dup-of: 27508)" [Wishlist,Confirmed]  https://launchpad.net/bugs/34208
<ubotu> New bug: #49827 in xorg (main) "Available resolutions incompletely set to 1024x768, 800x600, 640x480" [High,Confirmed]  https://launchpad.net/bugs/49827
<ubotu> New bug: #42354 in xorg (main) "Screen configuration misses horizontal/virtical refresh rates (dup-of: 3731)" [Medium,Confirmed]  https://launchpad.net/bugs/42354
<ubotu> New bug: #40475 in xorg (main) "Installer does not probe correctly for possible resolutions. (dup-of: 49827)" [Medium,Needs info]  https://launchpad.net/bugs/40475
<ubotu> New bug: #46666 in xorg (main) "Dapper RC wrong screen resolution (dup-of: 3731)" [Medium,Needs info]  https://launchpad.net/bugs/46666
<ubotu> New bug: #42652 in xorg (main) "Monitor misdetected (ThinkPad X41 Tablet) (dup-of: 3731)" [Medium,Needs info]  https://launchpad.net/bugs/42652
<ubotu> New bug: #106600 in linux-restricted-modules-2.6.20 (restricted) "system freeze after activating fglrx (ATI Radeon Mobility X700)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106600
<ubotu> New bug: #106611 in xorg (main) "USB mouse does not function when hot plugged" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106611
<ubotu> New bug: #106638 in xserver-xorg-video-i810 (main) "xrandr crashes XServer, if used from different VT" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106638
#ubuntu-x 2007-04-15
<ubotu> New bug: #106647 in xcursor-themes (main) "Mouse pointer missing when using whiteglass" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106647
<ubotu> New bug: #106648 in xcursor-themes (main) "Mouse cursor changes when over flash animation" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106648
<ubotu> New bug: #106652 in xserver-xorg-video-ati (main) "glx problems with xserver-xorg-video-ati" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106652
<tepsipakki> hm, xorg upload was rejected
<tepsipakki> anyway, zzz ->
<crimsun> was there a rationale posted in the changelog?
<ubotu> New bug: #106679 in libx11 (main) "ENVI/IDL segmentation fault" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106679
<Mithrandir> tepsipakki: yes, sorry, just too late even for those kinds of fixes.
<tepsipakki> Mithrandir: ok, np
<tepsipakki> Mithrandir: what if I dropped the new part of it, so that it only fixes the ATI vendor strings?
<ubotu> New bug: #51874 in linux-restricted-modules-2.6.15 (restricted) "Nvidia legacy drivers doesn't work on newer kernel" [Undecided,Needs info]  https://launchpad.net/bugs/51874
<ubotu> New bug: #105901 in xorg (main) "nvidia 7800gt live cd/ install issue" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105901
<ubotu> New bug: #106217 in linux-restricted-modules-2.6.20 (restricted) "hidden file controlling NVIDIA driver does not get removed when switching from nvidia-glx-new back to nvidia-glx causing X not to start due to mismatch of versions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106217
<ubotu> New bug: #42478 in linux-restricted-modules-2.6.15 (restricted) "ppracer aborts after intro screen on NVidia Riva TNT2" [Medium,Confirmed]  https://launchpad.net/bugs/42478
<ubotu> New bug: #40273 in linux-restricted-modules-2.6.15 (restricted) "Xorg fails to run using nvidia driver" [Medium,Needs info]  https://launchpad.net/bugs/40273
<ubotu> New bug: #106705 in xkeyboard-config (main) "Keyboard layout is incorrect for some keys" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106705
<ubotu> New bug: #92581 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-legacy doesn't disable composite extension automatically on installation" [Undecided,Confirmed]  https://launchpad.net/bugs/92581
<ubotu> New bug: #53569 in xorg-server (main) "Closing a window will often freeze X" [Undecided,Needs info]  https://launchpad.net/bugs/53569
<ubotu> New bug: #106718 in xorg (main) "incorrect path to .Xmodmap" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106718
<ubotu> New bug: #105309 in xorg (main) "Bad xorg config for 1440x900 monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105309
<ubotu> New bug: #103383 in xorg (main) "Multiple screens in Ubutu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103383
<ubotu> New bug: #21637 in gtk+2.0 "xkb greek polytonic: cannot write psili and dasia after upgrade to breezy" [Medium,Confirmed]  https://launchpad.net/bugs/21637
<ubotu> New bug: #56376 in linux-source-2.6.17 (main) "[Dapper 6.06]  Laptop - PCI cannot allocate resource for region 7 8 and 9 (dup-of: 54294)" [Undecided,Needs info]  https://launchpad.net/bugs/56376
#ubuntu-x 2008-04-07
<ubotu> New bug: #207457 in ubuntu "[Hardy] Spanish keyboad layout won't work (dup-of: 196277)" [Undecided,New] https://launchpad.net/bugs/207457
<ubotu> New bug: #213171 in xorg (main) "Unable to install with GUI on Fujitsu Lifebook C7651" [Undecided,New] https://launchpad.net/bugs/213171
<ubotu> New bug: #77226 in wacom-tools (main) "Wacom Mouse Scroll Wheel is Upside-Down" [Undecided,Confirmed] https://launchpad.net/bugs/77226
<ubotu> New bug: #213191 in xserver-xorg-video-intel (main) "855GME system freezes when switching to external monitor" [Undecided,New] https://launchpad.net/bugs/213191
<ubotu> New bug: #212996 in linux-restricted-modules-2.6.24 (restricted) "[hardy] fglrx breaks hibernate" [Undecided,Incomplete] https://launchpad.net/bugs/212996
<ubotu> New bug: #213212 in xserver-xorg-video-amd (main) "freeze with lots of usb events" [Undecided,New] https://launchpad.net/bugs/213212
<ubotu> New bug: #213262 in mesa (main) "965GM wine Messa crash when using DRI" [Undecided,New] https://launchpad.net/bugs/213262
<Ng> tjaalton: have you seen firefox make the mouse cursor disappear when it's thinking, in the last few days?
<Ng> (and/or thunderbird)
<Ng> both are doing it for me atm in metacity and compiz
<Ng> it's extremely annoying and doesn't happen to a fresh user :/
<tjaalton> Ng: no, haven't seen such
<Ng> dammit
<Ng> I can't reproduce it anywhere :(
<Ng> and I can't imagine what on earth could be causing it
<Ng> oh!
<Ng> I bet I know what this is
<Ng> I've not seen the busy pointer in a while, I bet it's just that is showing up blank for some reaosn
<Ng> yeah, starting gedit or similar makes it briefly disappear when it should be showing the pointer with a spinner next to it
<Ng> I'm sure there used to be a command to manually set the current pointer
<Ng> I thought it was xsetpointer, but that seems to do something else entirely ;)
<Ng> meh, it was getting too annoying to work, so I restarted X and it's back to normal
<ubotu> New bug: #213346 in xkeyboard-config (main) "Missing character on belgian keyboard" [Undecided,New] https://launchpad.net/bugs/213346
<ubotu> New bug: #206510 in linux-restricted-modules-2.6.24 (restricted) "Possible Nvidia 8600GT Problem" [Undecided,New] https://launchpad.net/bugs/206510
<james_w> morning bryce. Can you ping me when you're up and have a few minutes to chat please?
<seb128> james_w: is that about the xrandr changes?
<james_w> seb128: yes
<seb128> ok, could you have the discussion in a place where I'm too? ;-)
<james_w> sure, is here ok?
<seb128> btw I did update the gnome-desktop and gnome-settings-daemon xrandr patches this afternoon while waiting on new GNOME tarballs
<seb128> using the current fedora rpms versions
<james_w> great, are they uploaded, or somewhere else?
<seb128> yes, uploaded to hardy
<james_w> thanks, I'll make sure to grab those.
<seb128> I had to use a Breaks on gnome-control-center because they broke the ABI by changing a struct
<ubotu> New bug: #213203 in ubiquity (main) "[Hardy Beta] Problems with Live CD Installation (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/213203
<seb128> james_w: so what is to do now is to update the gnome-control-center change and track the bugs I mentionned in the mail
<seb128> they added some beta warning text in the capplet when I tried fc9 beta, dunno if they removed that, if not we want to
<seb128> james_w: first thing I would wait for the new version, I uploaded a gnome-control-center rebuild, so in an hour or so you should have libgnome-desktop-2 gnome-control-center and gnome-settings-daemon updates available, please make sure they still work for you after uprading (ie, try to restart your session and to use the capplet)
<james_w> ok
<seb128> james_w: http://cvs.fedoraproject.org/viewcvs/devel/control-center/ has the change, it's add-randr12-capplet.patch there
<seb128> james_w: gnome-control-center in hardy has 101_cc-add-randr12-capplet.patch which is basically this patch, the makefile changes have been moved to 102_cc-randr12-makefile.patch
<seb128> and the other 1nn_cc-* are changes we did to that code
<seb128> the game there is to update 101_cc-add-randr12-capplet.patch using the new redhat version
<seb128> and to update then the other patches which need to be updated or drop the one which are not useful after the update
<seb128> james_w: if you want to give a try to that you are really welcome ;-)
<seb128> and let me know if the summary is not clear ;-)
<ubotu> New bug: #55554 in linux-restricted-modules-2.6.15 "HAL Status 3 on AR5212 chipset (broken wifi)" [Undecided,Invalid] https://launchpad.net/bugs/55554
<bryce> morning
<bryce> heya james_w
<james_w> hi bryce, how are you?
<bryce> pretty good, you?
<james_w> good thanks.
<seb128> hey bryce
<james_w> I don't know if you saw but Colin asked me to help out on the gnome/xrandr front, so I am just trying to get up to speed on that.
<james_w> at the moment I can just about spell xrandr, so I've got to spend some time getting up to speed.
<bryce> yes, that's great, we can really use the help.  The work's pretty straightforward but time consuming and we're down to the crunch
<james_w> seb128 gave me some pointers to where the applicable code is, but I need a pointer of which direction to go in.
<bryce> hehe, well most of the work is going to be fixing C patches and packaging
<bryce> I'll send a reply to the email to start with
<james_w> cool, I should be able to manage that, I guess the first thing is to reproduce the issues. Is there one that I should start on?
<seb128> bryce: dunno if you read but I updated the gnome-desktop and gnome-settings-daemon patched to current redhat version today
<seb128> james_w: first thing would be to do the gnome-control-center patch update I would say to make sure we are uptodate before fixing issues when have already been fixed in the update
<james_w> ok, thanks.
<seb128> james_w: otherwise the most frequent complain is g-s-d crashing under xgl, so sudo apt-get install xserver-xgl and restart your session should be enough to trigger it
<james_w> ok, sounds easy enough.
<bryce> wow, I think this is the first time I've seen seb128 recommend someone install xgl ;-)
<seb128> and that's not going to repeat again soon ;-)
<bryce> seb128: when where the patches in Fedora's RPM's taken?
<seb128> bryce: some hours ago, I took them from their viewcvs
<bryce> ok
<bryce> er, I meant, when were the patches snapshotted from ssp's git tree?
<seb128> "Sat Apr 5 16:40:52 2008 UTC (2 days ago) by ssp " for the gnome-desktop one
<seb128> and around the time for the g-s-d one
<bryce> ah good.  I took snapshots Friday, but Saturday would be newer.
<seb128> I used viewcvs rather than git to have something tested
<seb128> if they pushed to the distro that's likely working
<bryce> james, also these patches bring in some new capabilities (clone mode, display hotkeys, drag-and-drop dual-head configuration, and maybe more)
<bryce> james_w: even though they're features, we also have bug reports in about those as well
<ubotu> New bug: #213465 in xkeyboard-config (main) "bug with the numeric keyboard  " [Undecided,New] https://launchpad.net/bugs/213465
<ubotu> New bug: #198833 in xorg (main) "OOo writer locks up the whole system" [Undecided,New] https://launchpad.net/bugs/198833
<ubotu> New bug: #213490 in linux-restricted-modules-2.6.24 (restricted) "package linux-restricted-modules-2.6.24-15-generic 2.6.24.12-15.33 failed to install/upgrade: subprocesso post-installation script retornou erro do status de saÃ­da 16" [Undecided,New] https://launchpad.net/bugs/213490
<ubotu> New bug: #212737 in xorg (main) "Wacom tablet works from LiveCD but not installed hardy" [Undecided,Incomplete] https://launchpad.net/bugs/212737
<james_w> heh, just for clarification we are testing the "System->Preferences->Screen Resolution" tool, aren't we?
<bryce> right
<bryce> I've got more background and photos posted at my blog - http://bryceharrington.org/drupal/
<james_w> yeah, I've seen your posts about working on it. It looks pretty cool.
<james_w> something is pretty slow, but I might expect that as it's quite an old card with a non-free driver.
<bryce> oh yeah, you will likely have trouble testing this with the proprietary drivers
<bryce> if you need to test it, and can actually run the free driver, that's what I'd suggest
<james_w> I've got a free one in my laptop, and I can use nv on my desktop, so that's not a problem.
<bryce> great
<bryce> fwiw, rotation on -ati locks up the system.  rotation on -nv isn't even available.  it works about 90-95% on -intel
<bryce> resolution switching works without catastrophic issues on all hardware I've tested
<bryce> there are sometimes some glitches though - but can usually be fixed by switching to another rez and back
<james_w> yeah, switching resolutions went fine, I wasn't offered any other rotations.
<james_w> I'm not able to test any interesting configurations either, I only have a single monitor.
<bryce> that's fine - focus just on getting the patches updated; as long as you can test on one config (like -nv) that'll be enough to validate that things got integrated properly
<bryce> I've gotten several other community members volunteering to do more testing in coming weeks, so we should have ample coverage
<james_w> ok, should I still work from CVS?
<james_w> I haven't found the git repo to see if there is anything newer there.
<bryce> ah, sorry, the git repo is at http://www.gnome.org/~ssp/randr/.git
<bryce> yes there are some new changes
<bryce> http://paste.ubuntu-nl.org/62442/
<james_w> thanks, I'm grabbing the repo for myself.
<bryce> I also have set up a bzr repo where I've put my snapshots of his code
<bryce> https://code.launchpad.net/~bryceharrington/gnome-control-center/ssp-xrandr
<bryce> the only things of special note there are I have 3 scripts which convert his git code into patches that will apply to our ubuntu packages
<james_w> so it appears as though the fedora patch and the git repo are actually diverged, I assumed he was just cherry-picking changes.
<bryce> hrm
<james_w> I can't find the last CVS change in the git repo.
<bryce> ok - as seb suspected, there may be fixes in the fedora cvs that haven't gotten put back in ssp's repo, which we probably will want
<james_w> the penultimate commit in CVS does appear to be in git, so I don't know if it's just a race condition.
<ubotu> New bug: #212902 in xserver-xorg-video-ati (main) "My video flickers in all apllications relating to video" [Undecided,New] https://launchpad.net/bugs/212902
<ubotu> New bug: #213532 in xorg (main) "No video when using window transparency." [Undecided,New] https://launchpad.net/bugs/213532
<james_w> bryce: do you want me to supply you with debdiffs of the source packages, or changes to bzr?
<bryce> debdiffs would be best
<james_w> cool
<james_w> #define I_KNOW_THIS_IS_UNSTABLE_AND_ONLY_IN_FEDORA
<bryce> yup, the patch I sent you should strip all of those out
<james_w> hmm, you sent me a patch?
<bryce> yeah, hmm did you not get my reply?
<james_w> to Colin's email?
<bryce> oh duh, you weren't on the cc
<bryce> yeah
<james_w> ah, ok.
<bryce> re-sent
<james_w> thanks
<ubotu> New bug: #213566 in xkeyboard-config (main) "dapper->hardy missing files on upgrade" [High,New] https://launchpad.net/bugs/213566
<mvo> does anyone of you have a idea about bug  #213566
<ubotu> Launchpad bug 213566 in xkeyboard-config "dapper->hardy missing files on upgrade" [High,New] https://launchpad.net/bugs/213566
<mvo> reproducable on dapper->hardy upgrade with the release-upgrader
<bryce> hmm
<mvo> pretty scary
<bryce> odd, but it looks like the upgrade code just needs to be modified to set up those symlinks
<mvo> "the upgrade code" -> update-manager? or some postinst magic in the package?
<bryce> not sure...  I'm not seeing symlink manufacturing stuff in the x11proto-kb rules, and there's no postinst there
<mvo> hmmm, bad. dpkg -c xkb-data.deb has it, but dpkg -L xkb-data (and the filesystem) do not have the symlinks
<mvo> I will investigate more tomorrow, might be a dpkg problem or some other oddness
<bryce> ok, let me know if you need help
<bryce> xkb-data looks obsolescent... maybe it's only used for transitioning
<bryce> er wait nevermind, that's xkeyboard-config
<mvo> I suspect it might be some strangness with the replaces
<mvo> tomorrow, its sleeping time
<james_w> I'm finishing for the day as well, I'll try and have the patches ready for you tomorrow.
<bryce> cool, cya
<bryce> james_w: how far along did you get?
<bryce> james_w: and is there anything you're stuck on that I could work on in the meantime?
<james_w> bryce: I didn't really get anywhere, I was just looking around the code trying to work out which bits were in which patch.
<james_w> feel free to work on it and drop me anything you get done in a mail.
<bryce> ah ok
<bryce> sure
<bryce> doing some keyboard stuff at the moment, but may look at the patches if nothing higher priority comes up
<james_w> ok
<seb128> what patches do you guys speak about?
<seb128> have you tried that the updates I did today did break the world? ;-)
<james_w> seb128: I tested today's updates, they worked in my limited testing.
<seb128> james_w: ok, thanks
<seb128> as long as it doesn't make GNOME crash after login that's alright
<james_w> we were discussing the CVS, git and Ubuntu versions of the patches, it's not immediately clear which code is in which set.
<seb128> what I would say is take the redhat updates patch and replace the hardy one using it
<james_w> yeah, that makes sense, I was also looking if there was anything worth taking in git.
 * james_w wishes for one version control system for all three, this is exactly what that would be great for.
<seb128> yeah
<ubotu> New bug: #212319 in xscreensaver (main) "[fglrx amd64] atunnel crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/212319
<ubotu> New bug: #212320 in xscreensaver (main) "[fglrx amd64] queens crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/212320
#ubuntu-x 2008-04-08
<ubotu> New bug: #213669 in xorg (main) "[Hardy] Caps Lock causes keys to repeat" [Undecided,New] https://launchpad.net/bugs/213669
<ubotu> New bug: #213617 in linux-ubuntu-modules-2.6.24 (main) "package linux-ubuntu-modules-2.6.24-14-generic None failed to install/upgrade: subprocess post-removal script returned error exit status 1 (dup-of: 149836)" [Undecided,Invalid] https://launchpad.net/bugs/213617
<ubotu> New bug: #213700 in xorg-server (main) "X.org + compiz crashes on nautilus file drag" [Undecided,New] https://launchpad.net/bugs/213700
<ubotu> New bug: #213734 in xserver-xorg-video-ati (main) "firefox-3.0 scrolls jerkily with ATI driver, EXA and compiz" [Undecided,New] https://launchpad.net/bugs/213734
<ubotu> New bug: #200429 in mesa-utils "XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" " [Undecided,Invalid] https://launchpad.net/bugs/200429
<bryce> I've written up this section on troubleshooting missing keyboard mappings in X:  https://wiki.ubuntu.com/X/Troubleshooting#head-1125c10247cf42e51d6329403e00d89af20fad32
<bryce> however I'm still a bit sketchy on the whole thing, and the docs may be incorrect.  I'd greatly appreciate review/critique feedback to make it more correct.
<Ng> bryce: do you happen to know how acpi_fakekey sends events? I've been trying to get the ThinkVantage key on my thinkpad going. acpid calls the script which runs fakekey, but things like xev see no event
<bryce> Ng, sadly, everything I know at this point about key mapping is listed in that above link
<Ng> ok, I'll have a read anyway :)
<bryce> I guess you'd look at what acpi_fakekey does to fake keys.
<Ng> it seems to open the first /dev/input event device it can find and write to that
<bryce> unfortunately the post from mjg59 that mentioned acpi-based keys just said "send me info about this and we'll get it fixed" without details of *how* they get fixed
<Ng> I thought that was where the problem was because event0 is my trackpoint, but hardcoding it to the keyboard device didn't seem to make any difference
<Ng> I could try and badger matt :)
<bryce> have you spoken with matthew about it?
<bryce> heh yeah
<bryce> see if you can get a good detailed description of the troubleshooting approach, so we can feed it into that link for when we run into this in the future
<Ng> not yet unfortunately, I've had bigger fish to fry
<Ng> getting suspend and audio working won out over a little button ;)
<bryce> hehe
<Ng> I don't even need it, I used to use it to lock the screen, but my new laptop has a Fn key combination for that. it's just the principle of the thing at this point ;)
<pwnguin> bryce: about that keymapping thing
<pwnguin> is a tty console nessecary?
<pwnguin> i guess not
<pwnguin> ive done hotkey in the past, but sorta petered out about what to do from there =/
<bryce> pwnguin: dunno; several pages I read were adamant about that
<pwnguin> i wonder if maybe its because a tty means you wont get keyboard events from a local keyboard 
<pwnguin> oh my
<pwnguin> someone fixed one of my tablet buttons
<bryce> tjaalton: any reasons why not to commit the patch on bug 184651?
<ubotu> New bug: #205821 in moblin-applets (universe) "[Hardy+PPA]:Network manager icon is blank on statusbar and it shows "Network manager is not running" when click the blank icon though internet connection is good (dup-of: 199486)" [Undecided,New] https://launchpad.net/bugs/205821
<tjaalton> bryce: no, and I actually have it on my tree
<bryce> ok cool
<tjaalton> should start pushing stuff later today
<bryce> (I was just reviewing http://people.ubuntu.com/~bryce/Xorg/status_current.html and noticed it)
<bryce> heh, clicking back through <prev> on that shows that things are definitely getting better
<tjaalton> wow, history :)
 * bryce resists graphing
<pwnguin> so total xorg bugs is total active bugs
<tjaalton> there's probably something missing since the packagebugs page shows 1512 bugs (or is it lp search lying again)
<tjaalton> pwnguin: yes, pick any ;)
<pwnguin> heh
<tjaalton> it has gone down from 1800+ since early December
<bryce> yeah, it may be that lp is lying
<pwnguin> and has gone nowhere since bryce started keeping that history ;)
<james_w> hey bryce 
<bryce> heya
<james_w> did you get any time to look at the patches?
<tjaalton> well I've been catching up with real work so no time to do bug triage :)
<bryce> james_w: nope, keyboard stuff consumed all my time
<james_w> no problem, just didn't want to repeat any work.
 * bryce nods
<james_w> I've got an SRU I should get done today, but then I should be able to spend all my time on them.
 * bryce nods
<ubotu> New bug: #46904 in xkeyboard-config (main) "several keyboard layouts are listed several times" [Medium,Fix released] https://launchpad.net/bugs/46904
<ubotu> New bug: #213856 in xserver-xorg-video-intel (main) "Windows and desktops flicker and flash black with Compiz enabled with the Intel video driver (945GM)" [Undecided,New] https://launchpad.net/bugs/213856
<ubotu> New bug: #204736 in mesa-utils "glxinfo crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/204736
<ubotu> New bug: #134466 in ubuntu "ipw3945d causing computer to stutter (dup-of: 48395)" [Undecided,New] https://launchpad.net/bugs/134466
<ubotu> New bug: #213891 in xorg (main) "Xorg crashes when I visit a page in Mozilla Firefox" [Undecided,New] https://launchpad.net/bugs/213891
<james_w> seb128: hi, the current libgnome-desktop in the archive has "#error This is not for general consumption yet." in the xrandr stuff, was this intentional?
<james_w> I can't compile against it currently.
<seb128> james_w: what do you mean?
<seb128> compile what?
<james_w> the xrandr patches in -desktop currently have
<james_w> +#ifndef I_KNOW_THIS_IS_UNSTABLE_AND_ONLY_IN_FEDORA
<james_w> +#error This is not for general consumption yet.
<james_w> +#endif
<seb128> right
<seb128> the API is not public and not meant to be used
<james_w> so I now try and g-c-c against them without defining that, as bryce's instructions say, and it obviously fails.
<seb128> ok
<james_w> so do we want to keep that in all of them, or strip it out of all of them?
<seb128> so I did use the patch from redhat because I didn't know bryce did cleaning there
<seb128> I mean I used to stack patch
<seb128> since he put other ubuntu changes to different patches I though he did that for all the ubuntu changes
<james_w> ah, ok.
<seb128> so fix it the way you think it's better
<seb128> but don't make it public
<seb128> either use this define
<seb128> or rename it to use FEDORA_AND_UBUNTU or something
<james_w> I'll just keep it as it is I guess, and keep the define in g-c-c
<seb128> alright
<seb128> did bryce just dropped it before?
<james_w> yeah, there's a patch in his bzr repo to remove these defines.
<seb128> ok
<seb128> I think that's wrong to make the api public
<james_w> the updated patch seems to work, but is says "Cloned output" for my single screen, I'll look in to that.
<james_w> hmm, "<property name="label" translatable="yes">Mirror Screens (the clone wars)</property>"
<james_w> I guess we want to change that?
<seb128> remove the "(the clone wars)" I guess yes ;-)
<seb128> james_w: could you also include the change on bug #213134 while you are working on the update?
<ubotu> Launchpad bug 213134 in gnome-control-center "Untranslated strings in Monitor Resolution Settings window" [Undecided,Confirmed] https://launchpad.net/bugs/213134
<seb128> james_w: also better to get the updated patch as soon as possible and look at small issues later so the strings can be imported in launchpad and translated
<seb128> we can still do an another upload to fix issues
<seb128> the g-c-c part is only a capplet so it'll not make system unusable
<james_w> sure, it looks ok to me in a quick test apart from the naming issue, and that looks like it is -desktop anyway.
<seb128> naming?
<james_w> calling my screen a "Cloned output"
<seb128> ah
<ted1> bryce: So I was playing with OSX...  (how to start a conversation with people already scared)
<ted1> When you close the lid on your computer with an external monitor plugged in, it switches off the laptop panel and goes exclusively to the external display.
<ted1> Would it be possible to do something like that with the XRandR stuff?
<jcristau> it is, if you get acpi or key events when you close the lid
<ted1> Well, we can emit a DBUS signal, which would probably be more reliable.
<ted1> Let GPM handle all the other stuff.
<bryce> morning
 * ted1 is going to let bryce get coffee before harassing him more :)
<bryce> james_w: have you gotten to gnome-desktop yet?  if not, I'll work on that today
<james_w> bryce: no, I haven't
<james_w> http://jameswestby.net/scratch/g-c-c.diff is the g-c-c one
<james_w> if you have a moment can you tell me whether I am looking in the right place for the "Cloned Screen" problem?
<james_w> http://paste.ubuntu.com/6627/
<james_w> line 22 looks like it should be "if", not "else if" to me.
<james_w> as clone_width is initialised to -1 at the start of the function.
<bryce> hmm
<bryce> are you running into a bug because of this?
<james_w> the capplet shows "Cloned Output" for my single screen, which seems wrong.
<bryce> ok, fwiw, that "clone wars" line has been there since the earliest days of the dialog - it was part of the mockup iirc
<bryce> however until recently the underlying handling code wasn't implemented
<bryce> so in the previous version I just stripped out the checkbox
<bryce> however I understand the clone stuff is implemented, so maybe the checkbox works now
<james_w> ah, ok. I still don't see the checkbox
<james_w> I assumed that was because I only have a single screen, but maybe I need to update a patch
<bryce> in any case I think the "(the clone wars)" bit needs to be removed ;-)
<james_w> I don't see it being stripped out in any of the patches.
<james_w> I made it "Clone Screens", what do you think?
<bryce> probably ok
<bryce> our usability guy suggested something different, I'll see if I can find it
<james_w> mirror made it sound like you would get a mirror image on one to me
<bryce> >> *   Is there an alternative wording for "Mirror another screen" that
<bryce> >>     doesn't imply reflection?
<bryce> >
<bryce> > 'Clone' is the official term.  I used 'mirror' since that has been used
<bryce> > in one of the displayconfig-gtk mockups.
<bryce> Perhaps "Copy of".
<bryce> I think I like "Clone" better than "Copy" but either's probably better than mirror
<james_w> yep
<bryce> oh here's a more recent suggestion from him, I hadn't implemented yet...
<bryce> Button labels should always use Initial Capitals. :-) Nice work otherwise.
<bryce> Cheers
<bryce> ted1: you could probably make the xrandr calls from the power manager to make that happen
<ted1> bryce: But, it's not crazy?
<bryce> a little crazy
<bryce> but not too much
<ted1> Hmph.
<ted1> So how do I know which display is the laptop LCD and which one is external?
<bryce> it'll result in weird stuff like gnome panels getting jumbled up, random crashes, weird interactions with sleep modes/Xv/Compiz, and so on, but those are par for the course
<jcristau> ted1: you probably don't know, but you can guess
<ted1> I work on the desktop team, we assume that X is perfect :)
<jcristau> haha
<bryce> it seems the standard way is to look for something named "*LVDS*"
<bryce> or, /LVDS/i
<ted1> I guess, it would seem unlikely that someone would use LVDS externally.
<ted1> But are there panels that internally don't use LVDS?
<bryce> not afaik
<jcristau> ted1: the naming comes from the X driver
<ted1> Oh, so it's not really describing the hardware, more the driver port.
<ted1> Okay, I'm going to think about this more, but I think it's something I'd like to figure out for Ibex.
<ted1> Thanks for the info.
<bryce> ted1: I'd suggest making it opt-in for Intrepid, since xrandr is still fairly unstable on some hardware.  once there's been sufficient testing it could be switched on by default by intrepid+1.
<bryce> ted1: or if you really want to flip it on by default, do it only for intel gfx hardware; that one is furthest along and has the fewest remaining issues
<jcristau> there are issues with radeon randr?
<jcristau> i haven't really followed that, as my laptop is intel :)
<bryce> jcristau: I consistently get lockups when rotating.  Also some minor issues switching resolutions
<jcristau> too bad
<tjaalton> <jawdrop> "VIA Joins The Open Driver Bandwagon"
<tjaalton> about time
<mvo> bryce: when we talked about bug #213566 you mentioned that there are no maintainer scripts involved, but it seems the xkb-data.preinst is doing some stuff at least to those links
<ubotu> Launchpad bug 213566 in xkeyboard-config "dapper->hardy missing files on upgrade" [High,Confirmed] https://launchpad.net/bugs/213566
<bryce> tjaalton: heh, link?
<bryce> BenC and I have been talking with them privately and encouraging them to open everything; good to see they have done so officially
<tjaalton> bryce: it was mentioned on phoronix (where else)
<ubotu> New bug: #214092 in linux-restricted-modules-2.6.24 (restricted) "Suspend to RAM fails in second resume cycle for Hardy, fglrx, ATI Mobility Radeon 9700" [Undecided,New] https://launchpad.net/bugs/214092
 * mvo is currently pretty lost with that bug
<ubotu> New bug: #214105 in xserver-xorg-video-ati (main) "Freeze with ati driver during boot on 8.04" [Undecided,New] https://launchpad.net/bugs/214105
<bryce> tjaalton: hrm, I've been pushing them to get in contact with the openchrome community.  Too bad there's no mention of that there.
<bryce> but I guess it's still early
<tjaalton> or they want to start from scratch :)
<tjaalton> YAVD
<ubotu> New bug: #214119 in xserver-xorg-video-amd (main) "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [Undecided,New] https://launchpad.net/bugs/214119
<Q-FUNK> guys, any objection remaining to sync'ing geode from debian?
<ubotu> New bug: #214165 in xorg (main) "[Hardy] After upgrade today can't detect screen size" [Undecided,New] https://launchpad.net/bugs/214165
<ubotu> New bug: #214168 in xorg (main) "video acceleration broken with .810 driver in Hardy Beta" [Undecided,New] https://launchpad.net/bugs/214168
<ubotu> New bug: #214201 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new upgrade bug (gutsy -> hardy)" [Undecided,New] https://launchpad.net/bugs/214201
<ubotu> New bug: #214205 in linux-restricted-modules-2.6.24 (restricted) "upgrade of xserver-xorg-core conficts (gutsy to hardy)" [Undecided,New] https://launchpad.net/bugs/214205
<ubotu> New bug: #214241 in xorg-server (main) "package xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.3 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/214241
<ubotu> New bug: #214239 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx-new 100.14.19+2.6.22.4-14.10 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/214239
<ubotu> New bug: #214252 in xserver-xorg-input-synaptics "[Hardy] Synaptics touchpad vertical scroll (middle button) not working as expected" [Undecided,New] https://launchpad.net/bugs/214252
<tjaalton> bryce: tomorrow I'll upload the pending stuff I have been sitting on.. should have time during the day
<bryce> ok
<tjaalton> needed to push vdr first.. anyway, night ->
<ubotu> New bug: #214270 in xserver-xorg-video-intel (main) "AWN Avant Window Navigator icons corrupted with xserver-xorg-video-intel 2:2.2.1-1ubuntu11" [Undecided,New] https://launchpad.net/bugs/214270
#ubuntu-x 2008-04-09
<bryce> james_w: btw I've finished the gnome-desktop update, I just need to test it and then will upload it, perhaps tonight
<bryce> tests ok; gnome-desktop uploaded
<bryce> hmm, looks like seb128 already did gnome-settings-daemon
<james_w> bryce: great, I'll test them in a little while.
<ubotu> New bug: #214439 in xserver-xorg-video-tdfx (main) "Quake engine games freeze if video settings changed" [Undecided,New] https://launchpad.net/bugs/214439
<bryce> tdfx wtf?
<bryce> 3dfx Banshee... interesting
<ubotu> New bug: #214442 in xserver-xorg-video-ati (main) "Time out error with r128 and some games" [Undecided,New] https://launchpad.net/bugs/214442
<james_w> bryce: what would you like me to work on today?
<james_w> I can test the uploads, and also seb uploaded g-c-c, so I think the patches need updating there again.
<bryce> james_w: how far along are you with the gnome-control-center patches?  Getting that uploaded is probably the next priority
<james_w> they were pretty good I think, I'll update them and do some more testing, and then talk to seb about them.
<bryce> presently, I'm working on a new patch to g-d to add a mess of null pointer checks.  Seems like many of our bugs have been due to null pointers from g-d
<bryce> so yeah, getting all the patches in g-c-c building properly, and getting that package would be the main goal today.
<james_w> ok, sure
<bryce> Looking over our bugs and that people are reporting problems still even after seb's last set of uploads (which I thought would fix those bugs), the new g-c-c changes unfortunately aren't going to solve that
<bryce> so priority #2 after that is sorting out why 199960 and 210226 are still happening
<bryce> the patch I'm doing may help with 210226 but it may just expose the null pointer at a higher level (which would be a good thing, but just one step)
<bryce> in 199960, the reporters are getting pretty ornery and fussy, but I'm hopeful the g-s-d upload sorted it out - but not much word since the 3rd
<james_w> 199960 is nice and easy to reproduce, which helps.
<james_w> any idea how to reproduce 210226?
<bryce> are you able to reproduce 199960?  I've not been able to
<bryce> I haven't reproduced 210226, but the backtraces are pretty clear
<bryce> there were a bunch of unrelated issues lumped into 199960; I think the only remaining active was when running with Xgl, however I *think* the Apr 6th g-d/g-s-d uploads might have addressed that
<james_w> I did "aptitude install xserver-xgl" and gnome-settings-daemon didn't start on the next login, so I assumed it was the bug, maybe it wasn't
<bryce> if not, then maybe we need an explicit check for Xgl in g-s-d (and probably g-c-c) like the code I posted in comment 57
<james_w> I tested on Monday
<james_w> I'll test again today.
<james_w> bryce: have you sent any of the other patches that we are carrying upstream?
<bryce> my plan has been to send them once we verified they built against the latest code
<bryce> on my list so far are these three for gnome-desktop:
<bryce> 102_gd-xrandr-null-pointer-check.patch
<bryce> 103_gd-xrandr-xerror-check.patch
<bryce> 104_gd-randr-revert-support.patch
<bryce> I'm not sure if I should send in the g-s-d patch; I'm not sure checking for xrandr versions is really that necessary.  ubuntu and fedora are both running xrandr 1.2 servers, so...  might be useful in general, but I don't know
<bryce> I want to go through the g-c-c patches once your work's uploaded, and send in a few of those.  I think half or so will be relevant for them
<james_w> yeah, that's what it looks like to me.
<james_w> the revert dialog requires 104_gd-randr-revert-support.patch?
<bryce> yes
<james_w> ok, thanks.
<bryce> I'd asked ssp previously about that but never got a response, and am guessing he won't be so interested, but who knows.
<james_w> I'm going back to bed for a short nap, but I'll start with g-c-c after that.
<bryce> ok cool
<bryce> james_w: I'll be cc'ing the gnomecc list (it's pretty low traffic if you want to subscribe during this project)
<seb128> hello
<bryce> hi
<seb128> bryce: hey
<seb128> bryce: they changed all that in gnome-desktop since my patch update on monday or did you list changes which we already had in your changelog?
<bryce> I listed changes we already had
<seb128> ah ok, that was confusing
<seb128> I think you didn't see my update and redid the work or something
<seb128> s/think/though
<bryce> actually that's the case :-/
<seb128> :-(
<seb128> but we dicussed it on IRC some days ago?
<bryce> but I noticed right after uploading and see that we had almost exactly the same patch
<bryce> I thought you had said you didn't have time to work on it, so I had it on my todo list
<seb128> hum
<seb128> then I sent this mail to colin and you
<seb128> james_w joined the chan
<seb128> and we discussed the changes
<seb128> you even asked me when I did take the snapshot
<seb128> I copied the redhat viewcvs from saturday and you said that was newer than your snapshot
<seb128> no?
<bryce> I assumed you took the snapshot and handed it over to james_w
<bryce> so I asked james_w before I started if he'd had a chance to work on it, and he said no, so I said I had some time and would help by doing that bit
<seb128> ok, I though I had been clear when I asked you guys to test the new hardy versions
<bryce> I thought you meant the gnome changes in general
<seb128> hum, k
<seb128> so to be clear I updated this one
<seb128> and the gnome-settings-daemon one too
<seb128> there was just the gnome-control-center one to update, that's what I explain on the chan to james_w
<seb128> I though you read that too, sorry about the confusion
<bryce> no prob, actually the patches for gnome-desktop applied cleanly without issue, so the time was mostly just reviewing all the changes, which I planned to do regardless
<seb128> alright
<seb128> btw they broke the ABI, dunno if you noticed
<seb128> I had to add a breaks in the package on monday due to that
<bryce> yeah I ran into that; confused me a bit
<bryce> can you tell me more about it?
<seb128> ok, so the only change in your update is the unstable define renamed apparently
<seb128> so no breakage in this one
<seb128> good ;-)
<bryce> right; in fact my change just adds another define test we can opt to start using if we wish
<bryce> since "ONLY_IN_FEDORA" clearly is not 100% true ;-)
<seb128> right ;-)
<bryce> but in general it probably doesn't matter to anyone, unless they're browsing code
<seb128> btw why did you change the configure.in?
<bryce> I didn't change that, but I wonder if it's a difference between the fedora rpm patch, and what I took from ssp?
<seb128> -#GNOME_COMMON_INIT
<seb128> +GNOME_COMMON_INIT
<seb128> etc
<seb128> they likely have extra debug macros used in git
<seb128> that they don't use for the packaging
<seb128> you reenabled those
<bryce> yeah, I noticed that too but don't know what it does.  I can revert that part if you'd like
<seb128> if that builds that's alright
<bryce> it builds and I tested it and seems to work properly
<seb128> alright, good
<seb128> let's wait for james_w gnome-control-center patch update now
<seb128> I'm wondering if somebody tried the current version using xgl
<seb128> users tend to complain loud when things are broken
<bryce> yeah I'm wondering that too
<seb128> but they don't bother adding a comment when things are fixed usually
<bryce> james_w said he can recreate the xgl issue fairly easy and will test it
<bryce> you know I get that with most X bugs too ;-)
<seb128> :-)
<ubotu> New bug: #214470 in xorg (main) "gdm screen uses virtual screen size instead of actual" [Undecided,New] https://launchpad.net/bugs/214470
<tjaalton> bryce: isn't bug 205979 a dupe of 184651?
<ubotu> Launchpad bug 205979 in xorg-server "xserver crash on exit in CloseDownDevices and SrvXkbFreeGeomRows" [Unknown,Confirmed] https://launchpad.net/bugs/205979
<bryce> tjaalton: hmm let me look
<bryce> darn, I nearly figured that one out myself.  guess I'm duplicating a lot of work lately!  ;-)
<tjaalton> heh :)
<tjaalton> I've now got six patches for xorg-server, mostly from upstream and one that defaults to intel instead of i810
<bryce> hmm, their patch doesn't match the direction I was going, but I bet it just solves it from a different (likely better) direction
<bryce> hmm, and looking at the backtraces and steps to reproduce, they're *slightly* different
<bryce> I'm not 100% sure that the patch for 184651 will also solve 205979, but I think it's possible and it wouldn't surprise me at all
<tjaalton> maybe ask again after this has been uploaded and then mark as dupe if it's fixed (and close the upstream report)
<ubotu> New bug: #214484 in xorg (main) "Standard NV driver doesn't work with G70 cards at 2560x1600" [Undecided,New] https://launchpad.net/bugs/214484
<tjaalton> hmmh, I had some mesa patches to add, but now I can't find any.. "assigned to" ftw
<tjaalton> lunch ->
<tjaalton> bryce: if you have anything you want me to look at, just ask
<bryce> I don't have any patches for the xserver at the moment; I've been uploading other things directly as I run across them
<bryce> bugwise, the top priorities right now are the 4 x-related bugs at https://bugs.launchpad.net/ubuntu/+bugs?field.milestone%3Alist=829
<seb128> did you guys made some video driver changes which could have broken the dpi values detected on some cards?
<bryce> I uploaded some patches for -intel the past few days, including one that updates a bunch of quirks, a few of which could correct some dpi issues
<bryce> other than -intel, I've not updated any other drivers
<seb128> ok
<seb128> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/213745
<ubotu> Launchpad bug 213745 in evince "PDF pages appear extremely small in evince" [Medium,Incomplete] 
<seb128> upstream thinks it could be a dpi detection issue, I've asked for xdpyinfo logs and what card those users are using
 * bryce nods
<bryce> for font dpi issues we also need to see their EDID, so it would be good to have their Xorg.0.log's
<seb128> ok
<seb128> asked that on the b ug
<seb128> bug
<bryce> one thing to look for in EDID is the monitor's physical dimensions, which is the thing that messes up dpi calculations
<bryce> anyway, off to bed for me.  night
<seb128> 'night bryce
<seb128> bryce: ok, those guys seem to all have intel cards
<seb128> bryce: so I would say you broke the intel driver :-)
<ubotu> New bug: #213745 in xserver-xorg-video-intel (main) "PDF pages appear extremely small in evince" [High,Confirmed] https://launchpad.net/bugs/213745
<ubotu> New bug: #214499 in linux-restricted-modules-2.6.24 (restricted) "Recompiled Ubuntu kernel - nvidia driver does not load (comm: modprobe Not tainted)" [Undecided,New] https://launchpad.net/bugs/214499
<ubotu> New bug: #214501 in xkeyboard-config (main) "no dead keys in hardy" [Undecided,New] https://launchpad.net/bugs/214501
<Q-FUNK> on bug #214119 I heard that before and this was already before the libpciaccess merge.
<ubotu> Launchpad bug 214119 in xserver-xorg-video-amd "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Triaged] https://launchpad.net/bugs/214119
<Q-FUNK> as far as I can tell, this is yet another case of a buggy BIOS that will require workarounds in x86emu.  The same driver works fine if compiled against an older X and using an xorg.conf
<ubotu> New bug: #209759 in firefox (universe) "firefox does not display scaled jpegs (dup-of: 182038)" [Undecided,Confirmed] https://launchpad.net/bugs/209759
<ubotu> New bug: #214513 in xserver-xorg-driver-i810 "mouse i810" [Undecided,New] https://launchpad.net/bugs/214513
<ubotu> New bug: #214517 in xserver-xorg-video-intel (main) "supend/resume broken with latest intel driver & kernel 2.6.24-15 " [Undecided,New] https://launchpad.net/bugs/214517
<ubotu> New bug: #214527 in evince (main) "Evince rendering very small text (dup-of: 213745)" [Low,Invalid] https://launchpad.net/bugs/214527
<ubotu> New bug: #208483 in ubiquity (main) "installer crashes in keyboard layout selection (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/208483
<james_w> seb128: hi. I've updated the g-c-c patch: http://jameswestby.net/scratch/g-c-c.diff
<seb128> james_w: excellent!
<james_w> it's now not showing any name for my monitor, I'll look in to why.
<james_w> I also didn't change the #define to be the new one bryce added support for, so it still says FEDORA.
<ubotu> New bug: #212373 in firefox-3.0 (main) "PNG error (dup-of: 182038)" [Undecided,Incomplete] https://launchpad.net/bugs/212373
<seb128> james_w: ok, the applet runs, that broken the "cancel the changes" action though, and I've no monitor description written either
<seb128> s/broken/broke
<james_w> the cancel button in the timer window?
<seb128> james_w: should I upload or do you want to give a try at fixing at least the cancellation thing before?
<seb128> yes
<seb128> or using esc
<james_w> it worked here.
<james_w> do you get any output on the terminal?
<seb128> james_w: that's working now, go figure
<seb128> xrand1.2 is still quite broken though
<seb128> I thought it would work alright on intel, but it doesn't :-(
<seb128> when switching to a lower resolution and back the screen has the small resolution area displayed correctly and the borders corrupted
<seb128> mvo: ^ compiz issue?
<seb128> compiz seems to thing the corrupted border is the limit of the workspace too
<seb128> I can move the xorg cursor there and use things under it correctly
<seb128> but when doing a dialog dnd for example it stops and switch workspaces
<mvo> seb128: I have a look once I finished debugging this bug #213566 issue
<ubotu> Launchpad bug 213566 in xkeyboard-config "dapper->hardy missing files on upgrade" [High,In progress] https://launchpad.net/bugs/213566
<seb128> ok
<mvo> its a nasty one
<seb128> james_w: ok, that seems already to me, thanks a lot for the work on it, I'll upload
<seb128> james_w: btw do you have an opinion on whether we should use "Refresh Rate" or "Refresh rate"?
<james_w> if you want to hang on a minute I think I might have fixed the name thing.
<seb128> the upstream capplet is using "Refresh rate"
<seb128> james_w: sure
<james_w> I though upstream was using "Rate", and we patched it to use "rate", which I just reverted
<james_w> bryce said that the usability guy (is that mpt?) said that we should use capital letters for labels, and all of the rest do.
<seb128> james_w: if you do patch edition could ou remove the extra g_print? I don't think we make any use of those informations anyway and we should have only errors printing in .xsession-errors
<james_w> sure, you want me to remove them all?
<seb128> just the non error ones
<seb128> we should still display failures
<james_w> should I move them to something that would show up in .xsession-errors for debugging?
<seb128> they do show up there already
<seb128> that's why I want to clean those ;-)
<seb128> at the moment it prints thing like
<seb128> CRTC 49 Timestamp: 3792732
<seb128> Output 4e Timestamp: 3792732
<seb128> applying configuration. Clone: yes
<seb128> etc
<seb128> those should not be printed I think
<seb128> that's just a detail though
<james_w> yeah, I agree.
<seb128> I want to clean .xsession-errors for hardy but too much to do
<seb128> I'll do a mini goal and try to get that for 8.04.1
<seb128> do a mini goal = write a wiki page or something or tag bugs and try to get contributors helping to clean those
<james_w> I've got it showing "Cloned Output" again, so it's wrong, but less wrong.
<seb128> did you had this label already using the hardy version?
<james_w> there's something wrong with the clone checkbox, so I'll have a quick look to see if I can debug that.
<seb128> ok
<james_w> yes, it was wrong in the previous versions as well.
<seb128> ok, so at least that's not a regression
<seb128> brb, need to restart xorg to get an usuable workspace again
<james_w> I think it's a problem with gnome-desktop patch though, so it shouldn't stop us uploading this.
<seb128> re
<james_w> Is there something better to use than g_print for real error messages?
<james_w> aside from a popup of course?
<seb128> g_warning and g_error
<seb128> g_error call abort though so it's only to use on real errors
<seb128> and g_warning is for error worth reporting but which should stop the program
<james_w> thanks
<seb128> and also g_messages for normal messages
<seb128> what is nice is that you can change the log handler so make those go in a debug log rather than on std*
<seb128> oh, that is not a cool bug
<seb128> using xrand1.2 breaks the dpi informations on intel
<seb128> which means once you have used the new capplet you will have broken dpis and the evince issue we got several bugs about
<tjaalton> ouch
<seb128> that breaks the web browse fonts too
<tjaalton> and that was due to the latest change?
<seb128> I've no idea, I didn't notice the issue before
<tjaalton> no, seems to be an upstream issue
<seb128> I'm going to downgrade the intel driver now
<tjaalton> ok, the changes seem to have added only some quirks
<seb128> and people started reporting that some days ago
<seb128> right
<seb128> https://launchpad.net/bugs/178558 suggests the issue is not new
<ubotu> Launchpad bug 178558 in xulrunner-1.9 "Firefox 3.0 makes everything annoyingly huge" [High,Fix released] 
<seb128> see https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/178558/comments/50
<tjaalton> yeah
<seb128> I think evince was not sensible to wrong dpi before or something
<seb128> so we didn't get lot of bugs about the issue
<seb128> or we got firefox font issues bugs which are not easy to track
<jcristau> maybe with X log, output of xrandr and xdpyinfo it would be possible to do something. random screenshots, not so much
<seb128> jcristau: I can give you any information you need
<seb128> jcristau: starting xorg xpydinfo shows a correct 120 dpi number
<seb128> using xrand1.2 to set the same screen resolution I'm already using the xdpyinfo number goes to 1x1
<seb128> that's a dell D630 laptop using a intel 965 video card
<seb128> using the current intel driver
<tjaalton> heh, mine dropped from 106x105 to 87x85
<jcristau> do you X log, preferrably with the ModeDebug option turned on?
<jcristau> meh
<jcristau> s/do you/& have an/
<seb128> jcristau: easy enough to get, where do I turn this option?
<jcristau> in the Device section
<seb128> jcristau: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/213745 has several Xorg.0.log
<ubotu> Launchpad bug 213745 in xserver-xorg-video-intel "PDF pages appear extremely small in evince" [High,Confirmed] 
<seb128> jcristau: but I don't think they are using the debug mode
<seb128> I'll try in a bit, I've things open that I don't want to close right now ;-)
<jcristau> (might be a good idea to set ModeDebug by default)
<jcristau> ok
<seb128> let me know if those logs are useful already
<jcristau> eww
<jcristau>   dimensions:    1280x800 pixels (40959x50175 millimeters)
<jcristau>   resolution:    1x0 dots per inch
<seb128> yeah, that's what you get after using xrandr1.2
<seb128>   dimensions:    1440x900 pixels (37887x31871 millimeters)
<seb128>   resolution:    1x1 dots per inch
<seb128> that's the value on my laptop
<jcristau> (II) intel(0): Printing DDC gathered Modelines:
<jcristau> (II) intel(0): Modeline "1280x800"x0.0   65.31  1280 1296 1328 1344  800 801 804 810 -hsync -vsync (48.6 kHz)
<seb128> it was 120x120 before using xrandr
<jcristau> that 0.0 is broken
<seb128> (II) intel(0): Printing DDC gathered Modelines:
<seb128> (II) intel(0): Modeline "1440x900"x0.0  108.50  1440 1520 1600 1952  900 903 909 926 -hsync -vsync (55.6 kHz)
<seb128> (II) intel(0): Modeline "1440x900"x0.0  108.50  1440 1520 1600 1952  900 903 909 926 -hsync -vsync (55.6 kHz)
<seb128> I've those
<jcristau> seb128: what exact command? xrandr --output 'foo' --mode 1440x900?
<seb128> jcristau: I'm using this new xrandr1.2 capplet from redhat that bryce backported
<seb128> is the xrandr command line using 1.2 too?
<jcristau> hrm, actually it's "1024x768"x0.0 here too
<tjaalton> same here
<jcristau> yes
<jcristau> so that's not it
<jcristau> modedebug would probably help
<seb128> ok, sec, editing xorg.conf and restarting
<tjaalton> was it a boolean?
<jcristau> do you have an url to the capplet source?
<jcristau> tjaalton: yes
<seb128> jcristau: the patches are on http://people.ubuntu.com/~bryce/Testing/XrandrGui/
<seb128> jcristau: http://www.gnome.org/~ssp/randr/ is the upstream thing, I think that's using git
<seb128> http://www.gnome.org/~ssp/randr/.git 
<ubotu> New bug: #214561 in evince (main) "Evince shows pdfs file with a very small size (dup-of: 213745)" [Low,Invalid] https://launchpad.net/bugs/214561
<ubotu> New bug: #214581 in nvidia-settings (universe) "[hardy] nvidia-settings window is displayed way too small" [Undecided,New] https://launchpad.net/bugs/214581
<seb128> jcristau: http://people.ubuntu.com/~seb128/Xorg.0.log
<jcristau> so at startup X sets your screen size to 304 x 190
<jcristau> (mm)
<jcristau> as reported by your monitor
<jcristau> and then something goes crazy
<seb128> as said if I don't use this capplet the xdpyinfo settings are correct
<seb128> so it goes wrong when using the xrandr calls
<seb128> the code which applies the settings seems to be in the gnome-desktop changes
<seb128> randrwrap.c
<seb128> it calls XRRSetScreenSize()
<mvo> tjaalton: if you maintain xkeyboard-config in git for ubuntu you may want to sync with my latest uplaod
<seb128> mvo: so what was the bug?
<tjaalton> mvo: I noticed your latest comment.. maybe this bug went "unnoticed" when people upgraded to edgy..
<mvo> seb128: multiple ones, but the killer was wrong order of unpack and replacing files in /etc with symlinks that confused dpkg
<tjaalton> mvo: and it's not maintained in git, unfortunately
<mvo> ok
<tjaalton> it's not maintained by XSF in Debian :)
<mvo> tjaalton: it pretty servere, if it went unoticed than our QA back then was pretty bad
<mvo> tjaalton: it kills the keyboard for anyone using the gnome-keyboard preferences
<tjaalton> ugh
<mvo> it depends on the unpack ordering for it to trigger, maybe we were just luck on dapper->edgy
<mvo> the issue that xkeyboard-config is in universe (and should be in main) is still open though
<tjaalton> could be yes
 * mvo goes to the seeds
<mvo> that was a bugger of a bug, happy to have nailed it down (works in my upgrade test environement, lts see if it works in the wild as well :)
<jcristau>     width_mm = (width * 96.0) * 25.4;
<jcristau>     height_mm = (height * 96.0) * 25.4;
<jcristau>     
<jcristau>     rw_screen_set_size (assign->screen, width, height, width_mm, height_mm);
<jcristau> so it's supposed to set dpi to 96
<jcristau> except, maybe not
<tjaalton> gotta run, bbl ->
<jcristau> hmm, shouldn't that be (width / 96.0) * 25.4?
<seb128> hum, yeah
<seb128> trying
<jcristau> seems likely to fuck things up, setting dpi to 1/96 instead of 96 :)
<seb128> brbr
<seb128> trying that change
<seb128> jcristau: ok, nice catch, much better now ;-)
<seb128> note for next time, don't blame xorg too quickly ;-)
<jcristau> cool
<jcristau> blaming red hat is a much better strategy! ;)
<seb128> yeah ;-)
<ubotu> New bug: #214592 in xserver-xorg-video-intel (main) "[Hardy] OpenGL renders Wrong " [Undecided,New] https://launchpad.net/bugs/214592
<james_w> seb128: the clone checkbox isn't showing up as 'glade_xml_get_widget (xml, "clone_checkbox");' is returning NULL
<james_w> there is '<widget class="GtkCheckButton" id="clone_checkbox">' in the glade file.
<james_w> do you know enough about glade to offer any suggestions?
<seb128> james_w: hum, looking
<mvo> james_w: was glade_xml_new run with a different root widget?
<mvo> james_w: so that clone_checkbox is not a child of whatever root was set to? (that might be a possible explaination for this behavior)
<james_w> glade_xml_new (GLADE_FILE, NULL, NULL);
<seb128> james_w: where is this clone widget?
<seb128> james_w: is that the Mirror Screen one?
<james_w> I'm seeing it at line 100 of "capplets/display/display-capplet.glade"
<james_w> seb128: yes
<seb128> it's displayed correctly for me
<james_w> hmm, odd.
<james_w> Do you have multiple screens?
<seb128> no
<seb128> I'm using a laptop right now
<seb128> and it's not pluged to any monitor or dock
<james_w> and this is with the latest changes I made?
<seb128> using the debdiff you sent me some hours ago
<james_w> odd.
<seb128> james_w: http://people.ubuntu.com/~seb128/xrandr.png
<james_w> I'll fix up what I have currently and pass that to you.
<seb128> ok, thanks
<james_w> I don't have the checkbox, or the "Detect displays" button.
<seb128> did you install the glade?
<seb128> or do you run from your source?
<james_w> yeah, I'm just wondering whether it's not getting installed.
<seb128> try to strace -e open gnome-display-properties 2>&1 | grep glade
<seb128> then glade this one
<seb128> and see if it's correct
<james_w> yeah, it's not in the .deb and the one on my system is old.
<james_w> thanks!
<seb128> you are welcome
<seb128> weird though
<seb128> the debdiff you sent me works correctly and the glade is installed there
<james_w> ah, it's in capplets-data
<seb128> yes
<seb128> I usually sudo dpkg -i *.deb ;-)
<james_w> yeah, I'm using two machines, and I was too lazy to copy them all across.
<james_w> It all seems to work nicely though.
<seb128> cool
<james_w> seb128: http://jameswestby.net/scratch/g-c-c.diff updated if you want to grab it again and do your thing
<seb128> james_w: my thing being debuild? ;-)
<james_w> oh, I thought you used sticky tape to make the .debs
<seb128> my debian applicant manager made me rewrite my a rules without using debhelper or cdbs
<seb128> I really appreciate the packaging tools since ;-)
<seb128> james_w: good work, thanks
<seb128> james_w: new revision uploaded to hardy
<seb128> james_w: I get the issue you described I think though, I've only one screen and the clone options is checked by default so the monitor label is wrong
<james_w> yeah, I think that's a problem in the -desktop patch, I asked bryce about it as I am not sure what the correct logic should be.
<seb128> that's a minor point
<seb128> and it's likely that redhat will fix it
<seb128> next issue should be to look if it still bug under xgl
<james_w> yep, I'm going to try that now.
<james_w> xgl kills g-s-d, with a backtrace very similar to https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/210226
<ubotu> Launchpad bug 210226 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,Confirmed] 
<ubotu> New bug: #178274 in xulrunner-1.9 (main) "[hardy] firefox breaks on some pages with an X error (dup-of: 205599)" [Medium,Incomplete] https://launchpad.net/bugs/178274
<ubotu> New bug: #184076 in midbrowser "gecko received an X Window System error (dup-of: 205599)" [Undecided,New] https://launchpad.net/bugs/184076
<ubotu> New bug: #194782 in firefox-3.0 (main) "[hardy] firefox breaks on some pages with an X error (dup-of: 205599)" [Undecided,New] https://launchpad.net/bugs/194782
<ubotu> New bug: #214652 in xorg (main) "Xorg freezes on logout in hardy" [Undecided,New] https://launchpad.net/bugs/214652
<james_w> seb128: how would you feel about http://jameswestby.net/scratch/g-s-d.diff
<james_w> is there a preferred way to add the linker options?
<james_w> I wasn't sure whether autoconf would be appreciated.
<james_w> It's taking bryce's code for detecting Xgl and just disabling the xrandr plugin if it is detected.
<bryce> morning
<james_w> hi bryce, sleep well?
<seb128> james_w: that seems the wrong approch to me, do you know why it breaks exactly?
<james_w> nope, afraid not.
<bryce> james_w: well enough
<james_w> bryce: testing the new stuff on Xgl I didn't get a backtrace like those in the report, I got one like bug 210226
<ubotu> Launchpad bug 210226 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,Confirmed] https://launchpad.net/bugs/210226
<seb128> james_w: I keep that as an option but I would prefer to find the call which is failing under xgl and fix that because it might cause similar cause under other situations
<james_w> seb128: yes, that would be better, but I don't know where to look for that. I can look tomorrow if someone has a few pointers.
<seb128> james_w: we have bugs about similar crash when using nvidia and xinerama for example
<seb128> james_w: not really, that's just plain C crash debugging, not really hint to help there out of using gdb and valgrind
<seb128> james_w: let me have a look tomorrow and ping you back, ok?
<james_w> seb128: sure, I'll take a quick look now as well.
<seb128> ok, thanks
<seb128> I'm away for diner, see you later
<james_w> bye
<james_w> XRRGetScreenSizeRange fails on Xgl
<james_w> bryce: this is where I get stuck, I can't follow the X calls in libxrandr, is there a way I can debug this further?
<james_w> or do we just need to add code for this situation to avoid a segfault?
<bryce> james_w: what i've been doing is adding in some null pointer checks...
<bryce> http://people.ubuntu.com/~bryce/Testing/XrandrGui/gd-randr-null-check.patch
<bryce> warning - I've not compiled that patch yet, it may have typos
<james_w> bryce: yeah, you've got the one causing this crash in there, want me to test it?
<james_w> bryce: I've got to go now, sorry, I'll try and catch you later today to see if there is anything else to do. Feel free to drop me an email with anything instead.
<james_w> Otherwise I'll test any uploads and work on other things.
 * bryce finally catches up on backlog
<bryce> good work on getting the g-c-c patch uploaded, I'll pull it and test too
<james_w> I'm pretty embarrased that I was trying to debug why the checkbox was missing when I just hadn't updated capplets-data :-)
<bryce> heh
<bryce> yeah I'll get this patch uploaded and you can test tomorrow or as you have time
<bryce> my suspicion with that bug is that <root cause> is resulting in the xrandr gui code getting an invalid data structure, with some members being NULL
<bryce> we can pepper the code with the null pointer checks, but it doesn't address the root cause that's causing the problem in the first place
<bryce> I suspect using Xgl is one root cause.  It's possible seb is right and that there are other similar causes
<james_w> screen->info is null in my case
<james_w> as XRRGetScreenSizeRange fails, and so it just sets it too NULL, and then this is never checked for.
<james_w> null in rw_screen_list_outputs that is.
<bryce> mmm
<bryce> so the next question is why XRRGetScreenSizeRange fails
<bryce> james_w: can you run sudo ddcprobe and see if you get edidfail?
<james_w> sure
<james_w> nope
<james_w> want the output?
<bryce> sure
<james_w> (this is still nvidia by the way)
<bryce> maybe -nvidia just doesn't work with that call?
<bryce> perhaps we should simply include code to bail out once that call fails
<james_w> http://paste.ubuntu.com/6673/
<bryce> hmmmm
<bryce> something looks odd...  can you pastebin your /var/log/Xorg.0.log?
<bryce> ah, nope nevermind
<bryce> (thought it was reporting cm when it should say mm, but it's actually doing the right thing)
<james_w> http://paste.ubuntu.com/6674/
<bryce> the ddcprobe output looks ok.  Also, am I remembering correctly that you tested with -nv and it worked ok?  that would rule out an edid issue
<james_w> um, no I haven't tested with nv yet.
<james_w> let me do that.
<james_w> still -xgl?
<bryce> odd, no edid listed in your Xorg.0.log.  
<bryce> sure
<bryce> actually wait
<bryce> I don't think it's an edid issue, don't worry about testing the -nv driver
<bryce> I'm fairly certain the issue is that -nvidia+-xgl is not supporting the necessary xrandr 1.2 calls, and we just need to check if that call failed
<bryce> assuming that's right, running -nv without -xgl should work.  I'm not sure what -nv + -xgl would do, actually.  I suspect it'd probably fail
<james_w> I can log in with nv and g-s-d runs fine, I've no idea whether I'm actually on Xgl though.
<bryce> xpdyinfo | grep -i xgl   I think
<james_w> that doesn't report anything even when xgl is working.
<bryce> sorry.   xvinfo | grep -q Xgl
<bryce> xvinfo | grep Xgl   actually
<james_w> yep nv works, but it's not Xgl
<bryce> ok, that's what I expected
<bryce> -nv + Xgl probably is a really uncommon config
<bryce> (if it's even possible to config it that way)
<joumetal> bug 214168 has good screenshot. What could cause it?
<ubotu> Launchpad bug 214168 in xserver-xorg-video-intel "video acceleration broken with .810 driver in Hardy Beta" [Undecided,New] https://launchpad.net/bugs/214168
<bryce> heya joumetal
<joumetal> hello bryce
<bryce> joumetal: I don't know exactly what's causing it but I can give some general comments
<joumetal> go ahead
<bryce> first, issues that appear with 3D only, are sometimes/often due to issues in mesa.  Not sure that's necessarily true in this case, but a possibility
<bryce> also, I see the card in question is i815, which is a pretty old model of intel card
<bryce> and in fact, many i8xx cards didn't work properly in -intel when we started Hardy, but we've forwarded bug reports upstream and the Xorg team has been fixing them
<bryce> especially i855 got a lot of fixes.  But each of the i8xx models has its own little quirks and bios-specific issues
<bryce> I suspect i855 is more commonly found than i815, so it doesn't surprise me that there may be more bugs for i815 to do
<bryce> anyway...
<bryce> so what's needed here is to collect the /var/log/Xorg.0.log (this should always be included when people report X bugs), but otherwise I think it is ready for forwarding upstream
<bryce> joumetal: do you want to collect that file and/or forward upstream, or shall I take it from here?
<joumetal> I am happy if you take it.
<bryce> ok will do
<bryce> also, when you spot a bug that is driver specific and have added a task for that, you can also close the xorg task; not necessary to have them double filed
<joumetal> ok maked xorg task invalid.
<james_w> hey seb128.
<james_w> bryce has a patch that should fix the -xgl issue I am seeing.
<seb128> re james_w
<seb128> ah, cool
<seb128> where is it?
<james_w> http://people.ubuntu.com/~bryce/Testing/XrandrGui/gd-randr-null-check.patch
<james_w> I haven't tested it, but it adds a NULL check where the segfault was, so it should at least prevent that.
<bryce> james_w: did you test it?  I'm finding one of the asserts is causing a crash on my dev box (which is good... but needs fixed first)
<james_w> bryce: no, sorry, I didn't
<bryce> also the null check may not *fix* the problem (it might), but at worst will shift the problem higher up in the stack where it can be better handled
<seb128> the patch looks alright, adding extra checks is a good thing
<bryce> I noticed ssp had added similar checks in a few places, so followed his style and just made sure they were ubiquitous, but I may have been too liberal since now it's asserting
<seb128> let's get it uploaded soon and see what the user feedback is
<seb128> bryce: btw dunno if you noticed we fixed the evince issue
<seb128> bryce: thanks to jcristau who noticed that the dpi calculation was wrong
<bryce> oh awesome, what was the cause?
<bryce> yeah I saw the discussion
<bryce> oh, *96 vs /96
<seb128> the gnome-desktop call was using width_mm = (width * 96.0) * 25.4
<seb128> and same for height
<seb128> where is should be / 96.0
<bryce> good catch
<seb128> indeed
<bryce> I also wonder about using 96 there
<seb128> that's what GNOME used to code as a value
<seb128> I was thing about changing that to use the gconf dpig key rather
<seb128> s/thing/thinking
<seb128> that would allow users to change the value
<bryce> I hope in intrepid we can finally get all the dpi fussiness sorted out
<seb128> which is not possible now
<seb128> would be nice if xorg would get that right ;-)
<bryce> yeah...  well looks like a lot of the remaining issues are quirkable
<seb128> quirk are nice
<bryce> however I'm concerned about situations where edid is not available, since all the dpi calcs seem to depend on the monitor providing at least some info
<seb128> it make possible to fix things broken which it would not be possible to workaround easily in the code
 * bryce nods
<seb128> well, maybe xorg should just fallback to 96 dpis when there is no edid information?
<bryce> I believe it does.  That may be why we don't see more bug reports than we already do
<seb128> ah, ok
<bryce> I wonder if there are apps that are using mechanisms other than Xorg for getting that value though
<seb128> let's try to drop the coded value again next cycle
<bryce> agreed
<seb128> not in the standard desktop I think
<bryce> I need to diagram out all the paths, like I did for the resolution stuff
<seb128> GNOME seems to not care about the xorg value
<bryce> seems there are multiple techniques people have used for calculating dpi; maybe unifying them could eliminate many bugs and make quirking more universally effective
<seb128> bryce: btw xrandr is still quite broken, I though that resolution changes would work on intel
<bryce> too many cases of "dpi is right in apps ABC, but bad in DEF"
<seb128> could be a compiz bug, when when switching between resolution the usuable screen portion stays to the small resolution and the other border are corrupted
<bryce> could be
<bryce> two of my -intel systems work great with the resolution switching.  one system only works when switching resolution to *higher* rez's, and locks up if reducing
<bryce> however that system I've hacked so much X stuff on I think it needs a complete reinstall (Xrandr used to work fine on it before I started work on xrandr gui stuff)
<seb128> is there any driver where xrandr is really working correctly?
<bryce> there is no driver I've found that works 100% with xrandr with any arbitrary chipsets
<bryce> but since these issues cause incorrect behavior rather than out and out crashes, I'm not certain how exactly to debug them
<bryce> once the major xrandr gui bugs are closed, I want to build a table of xrandr test results for various drivers/chipsets, and approach the upstream devs.
<bryce> seb128: a useful thing would be to try to reproduce the issue using just the cmdline xrandr tool; if this can be done, we can report the issue directly upstream.  Otherwise we need to first identify if it is due to a bug in xrandr gui (like that dpi issue was)
<seb128> right
<bryce> fwiw, this is the crash I'm working on...
<bryce> Program received signal SIGSEGV, Segmentation fault.
<bryce> [Switching to Thread 0xb6d2d720 (LWP 6683)]
<bryce> 0x0804d911 in on_screen_changed (scr=0x8193880, data=0x8070e80) at xrandr-capplet.c:122
<bryce> 122	in xrandr-capplet.c
<seb128> that's the common one I think
<seb128> one of those I listed in the mail I sent some days ago
<seb128> would be nice to get it fixed indeed ;-)
<bryce> ah, so then if it's unrelated to my patch (which is as I suspect), should I upload this, so we can test it against the Xgl bug?  Then I'll continue troubleshooting this one
<bryce> this one is starting to feel like an uninitialized pointer error
<seb128> uninitialized pointer is easy to figure if you have the issue
<seb128> build using -O0 rather than -O2
<bryce> ok
<seb128> when using -O0 usually the variable are initialized
<ubotu> New bug: #214787 in xserver-xorg-video-intel (main) "Intermittent monitor flicker after screen blanking in Hardy" [Undecided,New] https://launchpad.net/bugs/214787
<bryce> ok, whatever that bug is, it is unrelated to my changes; the dialog seems to work fine on other hardware, so I'll proceed with uploading.
<seb128> cool
<bryce> hrm, got rejected
<bryce> oh whoops, collided with your fix.
<ubotu> New bug: #214813 in xorg (main) "Bad detection of card - Dell Optiplex 740 AMD64" [Undecided,New] https://launchpad.net/bugs/214813
<bryce> try again && lunch (bbiab)
<bryce> ok went through that time
<ubotu> New bug: #214836 in linux-restricted-modules-2.6.24 (restricted) "lrm incorrectly installs nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/214836
#ubuntu-x 2008-04-10
<ubotu> New bug: #214909 in xserver-xorg-video-radeonhd (universe) "radeonhd driver does not support changing brightness on T60p" [Undecided,New] https://launchpad.net/bugs/214909
<ubotu> New bug: #209886 in xserver-xorg-video-ati (main) "Live CD not working with Mobility Radeon HD 2400 [1002:94c9]" [Undecided,New] https://launchpad.net/bugs/209886
<ubotu> New bug: #214911 in xserver-xorg-video-radeonhd (universe) "radeonhd does not support 3D" [Undecided,New] https://launchpad.net/bugs/214911
<ubotu> New bug: #214895 in xserver-xorg-video-intel (main) "Screensaver Settings Mini-preview" [Undecided,New] https://launchpad.net/bugs/214895
<james_w> hi all
<seb128> hey james_w
<bryce> hi guys
<james_w> forgot that this channel wasn't on my auto-join list.
<james_w> Is there an upload waiting for testing?
<bryce> I uploaded the null ptr fixes, so those need tested
<ubotu> New bug: #213845 in xorg (main) "Computer brought to complete halt when changing keyboard layouts using fglrx" [Undecided,Incomplete] https://launchpad.net/bugs/213845
<james_w> ** (gnome-settings-daemon:7047): CRITICAL **: rw_screen_list_outputs: assertion `screen->info != NULL' failed
<james_w> is that what you were seeing as well bryce?
<bryce> no, the issue I was seeing turned out to be an unrelated bug (still haven't figured it out, but did manage to isolate it as independent of whether my patch is present)
<james_w> ah, ok
<james_w> so this is what was causing the segfault before, it's just asserting now with your checks added.
<bryce> right
<bryce> fwiw, we might be able to loosen them from being asserts to being returns of null or 0 or -1 or something that can be checked
<bryce> heya tjaalton
<tjaalton> hi bryce 
<tjaalton> I've got one fix for xorg waiting, the one that soren has been waiting for. it's setting "CorePointer" for the mouse section again. Without that the section is not used at all, and the vmmouse tricks are useless
 * bryce nods
<bryce> I still don't have any myself (been uploading a bunch of other bits tho). 
<james_w> http://paste.ubuntu.com/6693/
<james_w> that seems to fix settings-daemon on Xgl issue I was seeing.
<bryce> oh cool
<james_w> (I had to change the prints as it was complaining that %d couldn't be used for type Window)
<bryce> ok
<bryce> want me to sponsor?
<james_w> though I have got a mixed up keymap now, I don't know what's causing that.
<james_w> should seb128 ACK first?
<bryce> there's been some other reports of mixed up keyboards lately (or maybe I've just been paying more attention to keyboard bugs).  In any case I suspect that's an unrelated issue
<bryce> I think seb128 will be ok with it - it's just adding another null pointer check and removing a few g_print's
<seb128> james_w: if it works fine for you I've no objection to get that uploaded
<james_w> great, thanks.
<seb128> james_w: while you are at it could you remove the extra printing there too as you did yesterday for gnome-control-center?
<james_w> sure
<james_w> I've got my keymap back after removing Xgl. Don't know what that means though.
<bryce> seb128: do you think upstream will care whether the g_print()'s are commented using C++ //'s, vs C /* */ ?
<seb128> well, that's a workaround
<seb128> the proper way to do that would be to either a --debug option or have a #define DEBUG or something which enable those
<bryce> uploaded
<bryce> many could probably just be deleted entirely
<seb128> right
<james_w> http://paste.ubuntu.com/6694/
<james_w> that's a patch to remove the debugging g_prints
<bryce> seb can take that one - I'm heading to bed (after 3am again, my gf's gonna kill me... again)
<tjaalton> :)
<seb128> 'night bryce
<tjaalton> I see that a lot :)
<seb128> james_w: seems mostly fine, but errors should not be commented I think
<seb128> we want to know when something goes wrong
<seb128> it should just not display anything on the command line when working correctly
<james_w> night bryce 
<james_w> ok
<james_w> http://paste.ubuntu.com/6695/ any better?
<mvo> night bryce
<seb128> james_w: yes, looks good now
<ubotu> New bug: #210978 in mesa (main) "compiz.real crashed with SIGSEGV in _nv000069gl()" [Undecided,New] https://launchpad.net/bugs/210978
<ubotu> New bug: #208156 in update-manager (main) "Could not install 'libc6' (dup-of: 205079)" [Undecided,New] https://launchpad.net/bugs/208156
<ubotu> New bug: #204818 in update-manager (main) "update manager crashed upgrading 'libc6' package. (dup-of: 205079)" [Medium,Confirmed] https://launchpad.net/bugs/204818
<ubotu> New bug: #209435 in update-manager (main) "crash in upgrade (dup-of: 205079)" [Undecided,New] https://launchpad.net/bugs/209435
<ubotu> New bug: #215282 in xserver-xorg-video-intel (main) "intel video driver not working on Dell inspirion 1525" [Undecided,New] https://launchpad.net/bugs/215282
<bryce> heya Q-FUNK
<bryce> james_w: I've just forwarded our patches upstream, to the gnomecc list
<Q-FUNK> hey
<Q-FUNK> I have updated packages with the Replaces added (silly oversight, ARGH!)
<bryce> awesome
<Q-FUNK> waiting to be uploaed to debian
<Q-FUNK> you also probably noticed that I managed to wake up the Koolu guys? :)
<bryce> yes, very good!
<bryce> I had put in a good word for your efforts earlier, so am glad they are getting involved
<Q-FUNK> I was in touch with them a few months ago. maddog praised me for being so active as a cheerleader and with bug triaging on this driver.
<bryce> well earned :-)
<bryce> btw, don't know if you noticed but final archive freeze just went into effect a couple hours ago
<bryce> http://people.ubuntu.com/~bryce/Xorg/status_current.html
<Q-FUNK> oh?
<Q-FUNK> so no time to sync 2.8.0-6 then?
<bryce> changes need approval by archive admin.  I'm not sure a sync would be authorized unless it fixed some critical bug(s)
<bryce> and even in that case, slangasek may prefer just to have the bug fix(es) individually backported, however couldn't hurt to ask.
<Q-FUNK> there are mainly 2 reasons to upgrade to geode:  major code cleanup,  getting rid of -amd for good and no need to drag transitinal for the next 2 years
<Q-FUNK> well, if anyone can sponsor into debian http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.8.0-6.dsc
<bryce> well, if nothing else maybe we can aim for getting it in for 8.04.1
<Q-FUNK> we really need this to be released now. there won't be any support for -amd anymore and LTSP needs it
<Q-FUNK> ogra really wanted edubuntu to release with this
<Q-FUNK> he was waiting impatiently for -geode to finally be released
<bryce> well, I'm concerned "code cleanup" won't be seen as a compelling reason
<Q-FUNK> sorry, not my fault I cannot directly upload into debian and magically launch a sync at ubuntu.
<Q-FUNK> I've been trying to do this transition with sporadic net access over the last couple of weeks
<Q-FUNK> and this sync request was filed well before the final freeze
<bryce> Q-FUNK: I've prompted slangasek's attention to it, and he says he'll be starting to look at these items today and tomorrow
<Q-FUNK> prmising :)
<Q-FUNK> would be even easier if we can get this sponsored into debian now, so that it's ready to sync by tomorrow
<bryce> I'm going to be gone through Sunday, but if it's still not 100% done by Monday let me know and I'll put it at the top of my todo list.
<Q-FUNK> ok
<bryce> I can't sponsor to debian, but if nothing else I can try brute force breaking it into individual patches and submit piece by piece to the review team
<Q-FUNK> that would be nearly impossible
<bryce> obviously getting it sync'd would be much preferred...
<Q-FUNK> indeed
<ubotu> New bug: #207168 in ubiquity (main) "installer restarts X on Kubuntu Hardy after selecting keyboard (dup-of: 184651)" [Undecided,Confirmed] https://launchpad.net/bugs/207168
<bryce> sooo many bugs
<bryce> I know that Hardy is a LOT better than Gutsy in terms of stability and such, but it still seems like there's an overwhelming number of crash bugs left
<bryce> at least, I think we have the xrandr gui finally stablized enough that people aren't going to completely freak out, but some of the xrandr bugs need attention
<bryce> james_w: there is starting to be some scattered review commentary on gnomecc; since I'm going to be gone now through the weekend, if you could, please respond to those where there's something we can say/do.  They pointed out our font patch was reversed, so that could probably use attention.
<Q-FUNK> speaking of that cute xrandr gui tool, why didn't it go to Accessories or as an applet?
<bryce> Q-FUNK: it (quite directly) replaces the Screen Resolution tool, which has always lived in System/Prefs
<Q-FUNK> I always wondered why that one was there too
<james_w> bryce: sure, I can take a look. Was the font patch something I dropped?
<bryce> not sure - patch 108_cc-randr12-capplet-font-layout.patch 
<james_w> cool, I'll work it out.
<bryce> Q-FUNK: personally I thought it should be in System/Admin.
<Q-FUNK> well, it's designed to be able to reconfigure on the fly, no?
<bryce> I have seen some randr changers implemented as toolbar applets and IMHO it's just wasteful of screen real estate.  
<Q-FUNK> her,e the main need I have for it is when i plug my laptop into a projector
<bryce> ultimately I think the idea is that you'd configure that *ONCE*, and then it would automatically detect when the projector is plugged/unplugged, and automatically change to the appropriate config without any button pushing
<bryce> I haven't tested that, but it's clearly where fedora is going with the code.  It might already work.
<bryce> of course, the skeptical part of me notes how whenever the computer tries to do things automatically for me, it often ends up causing me *more* work and confusion, but I'll be optimistic this time.
<bryce> maybe we need a paperclip.  "Hi!  I see you have connected a   PROJECTOR.  Would you like to a) TURN IT OFF, b) SET TO 320x240, or c) REBOOT?"
<jcristau> except load detection on vga is loss
<Q-FUNK> here, I already have an issue with xrandr assuming that the minute I plug an external display, it should become the main one.  the end result is that what i see on the laptop screen is clipped, becuase it has WXGA, while the projectors tend to be 4:3.
<jcristau> so what you can do is have a button for the user to tell you he plugged a monitor and needs you to do the detection
<jcristau> but you can't poll
<Q-FUNK> it doens't seem to be able to treat them as two separte displays, each with its own size and content
<jcristau> Q-FUNK: uh?
<bryce> do you mean the toolbars are off?
<jcristau> Q-FUNK: xrandr has --left-of and --above options
<Q-FUNK> jcristau: it indeed does but that doesn't produce the expected result
<Q-FUNK> bryce: that too
<jcristau> Q-FUNK: not sure what the expected result is, then
<jcristau> because it works just fine for me. plug a monitor or projector; xrandr --output VGA --auto --above LVDS; ...; profit
<Q-FUNK> it currently doens't give me output that is above or left of anything.  it instead tries to mirror the content on two displays of different geometries.
<jcristau> xrandr --auto does that.  --above doesn't, if you allocated a large enough fb
<Q-FUNK> that virtual fb already is a problem.  it seems to treat the displays as zooms on two areas of a larger map, with parts not showing on either zoom
<Q-FUNK> I tried with bryce's tool and manually with xrandr cli options
<bryce> Q-FUNK: can you please post the fix/debdiff for the Replaces to 211385?  Maybe also link to the new debian sync request
<jcristau> sounds like a window manager problem
<Q-FUNK> compiz+metacity in gnome
<Q-FUNK> bryce: sure. just a sec. rebooting..
<Q-FUNK> ok, which bug was this, again?
<bryce> bug #211385
<ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
<ubotu> New bug: #215414 in xorg (main) "installation error for package  x11-common" [Undecided,New] https://launchpad.net/bugs/215414
#ubuntu-x 2008-04-11
<ubotu> New bug: #212709 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV in _XSend()" [Undecided,New] https://launchpad.net/bugs/212709
<ubotu> New bug: #215449 in xorg (main) "Keyboard becomes unresponsive in X" [Undecided,New] https://launchpad.net/bugs/215449
<tjaalton> damn atieventsd.. it should probably be disabled
<ubotu> New bug: #207108 in linux-restricted-modules-2.6.24 (restricted) "ATI driver enabled 8.04 don't start" [Undecided,New] https://launchpad.net/bugs/207108
<tjaalton> mvo: I've noticed a possible problem with x11-common and dapper->hardy upgrades.. x11-common Replaces xrgb (<= 1.0.0-0ubuntu2) but the package in dapper has an epoch, so the rule doesn't work?
<tjaalton> this is also bug 212672
<ubotu> Launchpad bug 212672 in xorg "couldn't upgrade to hardy from dapper" [Undecided,New] https://launchpad.net/bugs/212672
<mvo> tjaalton: good catch, the epoch is needed
<tjaalton> mvo: ok, I'll add it
<ubotu> New bug: #215456 in update-manager (main) "Upgrade  failed (dup-of: 205079)" [Undecided,New] https://launchpad.net/bugs/215456
<mvo> bug 215456 makes me slightly nervous, it seems to be nvidia releated
<ubotu> Launchpad bug 215456 in update-manager "Upgrade  failed (dup-of: 205079)" [Undecided,New] https://launchpad.net/bugs/215456
<ubotu> Launchpad bug 205079 in linux-restricted-modules-2.6.24 "kubuntu Hardy Heron could not install libc6" [High,Fix released] https://launchpad.net/bugs/205079
<mvo> do you know if we had tls in gutsy too?
<tjaalton> nvidia-glx installed the non-tls version in /usr/lib until a few weeks ago
<mvo> hm, ok
<mvo> I wonder how these people got the bug then
<seb128> bug #196464
<ubotu> Launchpad bug 196464 in gdm "After gdm upgrade no X cliens can be run" [Low,Confirmed] https://launchpad.net/bugs/196464
<seb128> interesting comment
<seb128> what is atieventsd and why does it .Xauthority?
<tjaalton> sigh
<seb128> does it change
<tjaalton> it's some crappy daemon for multihead
<tjaalton> I'm all for disabling it by default
<tjaalton> it only generates grief from what I can tell
<seb128> ok, I'll wait to see if other people have the same issue
<seb128> and reassign
<tjaalton> ok
<ubotu> New bug: #215585 in linux-restricted-modules-2.6.24 (restricted) "[Hardy] Complete system freeze when scrolling using fglrx" [Undecided,New] https://launchpad.net/bugs/215585
<ubotu> New bug: #196464 in linux-restricted-modules-2.6.24 (restricted) "After gdm upgrade no X cliens can be run" [Low,Confirmed] https://launchpad.net/bugs/196464
<ubotu> New bug: #206703 in kdebase (main) "[hardy] kde fail to start if keyboard native langage maps are activated (dup-of: 205979)" [Undecided,Fix released] https://launchpad.net/bugs/206703
<seb128> james_w: https://bugs.launchpad.net/bugs/215396
<ubotu> Launchpad bug 215396 in gnome-control-center "gnome-display-properties crashed with SIGSEGV in _start() [when running xgl]" [Medium,New] 
<james_w> seb128: I'm just testing a "fix" for that.
<james_w> it's the same issue we solved for g-s-d and Xgl I think
<seb128> james_w: ok, good ;-)
<james_w> however the capplet is missing a NULL check so it crashes.
<seb128> scr=0x0
<seb128> indeed
<Q-FUNK> hm.  dak@debian seems to be in limbo.  got the upload ack mail more than 3 hours ago, but still no install mail.
<jcristau> Q-FUNK: you built with the new dpkg
<jcristau> Q-FUNK: and dak didn't like that until a few minutes ago
<Q-FUNK> oh?
<jcristau> see the thread on -devel
<Q-FUNK> ok
<Q-FUNK> jcristau: title of the thread?
<jcristau> something with dak in it
<Q-FUNK> Are Sha* checksums accepted by dak ?
<jcristau> yes
<Q-FUNK> ok
<Q-FUNK> except that I never received the rejection mail.  I received the confirmation for the upload, then nothing.
<jcristau> the upload was probably put on hold
<jcristau> and reinjected after the dak fix
<Q-FUNK> hopefully :)
<Q-FUNK> thanks for the pointer, anyhow
<ubotu> New bug: #215584 in xserver-xorg-video-ati "compiz freeze with ATI Radeon X600" [Undecided,New] https://launchpad.net/bugs/215584
<ubotu> New bug: #215702 in linux-restricted-modules-2.6.24 (restricted) "Hardy:  fglrx + compiz (dexktop effects) not working right" [Undecided,New] https://launchpad.net/bugs/215702
<Q-FUNK> hm.  still nothing from the damn buildd.
<ubotu> New bug: #215728 in xorg (main) "High CPU Consumption" [Undecided,New] https://launchpad.net/bugs/215728
<komputes> Q-FUNK: any progress of the geode driver?
<Q-FUNK> komputes: yes, waiting for debian to get its package builders back into shape
<komputes> Q-FUNK: great, if you need me to test it I have the hardware, so just ping me when that time comes
<jcristau> geode isn't autobuilt, so 'package builders' have nothing to do with that...
<Q-FUNK> hm?
<Q-FUNK> the buildd have a deprecated dpkg-dev and silently reject packages that use a recent one.
<Q-FUNK> and whoever was supposed to re-queue packages evidently missed one
<jcristau> no
<Q-FUNK> how else do you explain this then?
<jcristau> i don't know why you're talking about buildds
<Q-FUNK> then don't say no.
<ubotu> New bug: #24582 in xkeyboard-config ""Back" and "Forward" buttons should work out of the box in Firefox" [Wishlist,In progress] https://launchpad.net/bugs/24582
<james_w> seb128: http://paste.ubuntu.com/6770/#
<james_w> do you think the message is ok?
<seb128> james_w: there is already a message displayed when the capplet can't be used no?
<james_w> yes, there is
<james_w> I'm not sure exactly what the problem here is though. It has already checked that xrandr 1.2 is available
<james_w> but it still doesn't work, it's probably a driver bug I think
<seb128> I think that's a xgl issue
<james_w> or Xgl in this case
<seb128> the driver is likely xrandr capable
<seb128> but xgl might not be
<seb128> or something
<seb128> james_w: about the message, why do you need a new one if we already have one? I'm concerned about translations
<james_w> ah yes
<james_w> it's just the way the code is layed out
<james_w> also I wasn't sure about re-using it if it's not the same problem.
<seb128> what is the other problem?
<seb128> and I think your message is too technical
<seb128> users don't know what xrandr is
<seb128> we should just display a "your graphical setup doesn't support dynamic configuration change" or similar
<james_w>  "The X Server does not support the XRandR extension.  Runtime resolution changes to the display size are not available."
<james_w> "The version of the XRandR extension is incompatible with this program. Runtime changes to the display size are not available."
<james_w> that's the two existing messages.
<seb128> bah
<seb128> I would use the first one
<james_w> ok, I'll change it
<seb128> do you agree about the not breaking translations?
<james_w> yeah, that's important.
<seb128> I don't want to dictate decisions ;-)
<seb128> ok, cool
<ubotu> New bug: #215778 in linux-restricted-modules-2.6.24 (restricted) "2.6.24-16.30 kernel update - nvidia: module license 'NVIDIA' taints kernel" [Undecided,Confirmed] https://launchpad.net/bugs/215778
<ubotu> New bug: #215399 in firefox-3.0 (main) "firefox beta 3 does not always display images (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/215399
<ubotu> New bug: #215976 in ubuntu "nvidia driver not found with 2.6.24-16 kernel(64 bit) (dup-of: 215778)" [Undecided,New] https://launchpad.net/bugs/215976
#ubuntu-x 2008-04-12
<ubotu> New bug: #216005 in xserver-xorg-video-ati (main) "[hardy] Regression: compiz fails because of failed "Maximum texture size" check" [Undecided,New] https://launchpad.net/bugs/216005
<Q-FUNK> great.  this time, the upload made it, but installer complained about incorrect sha1 and sha256 checksums, so rejected the install.
<ubotu> New bug: #216066 in linux-restricted-modules-2.6.24 (restricted) "brightness adjustment does not work on GeForce 8600M GS" [Undecided,New] https://launchpad.net/bugs/216066
<ubotu> New bug: #216068 in ubuntu "nvidia  2.6.24-16-generic don't work (dup-of: 215778)" [Undecided,New] https://launchpad.net/bugs/216068
<ubotu> New bug: #215799 in linux-restricted-modules-2.6.22 "ATI new driver (fglrx) doesn't work for mobility radeon 9600." [Undecided,New] https://launchpad.net/bugs/215799
<ubotu> New bug: #215800 in ubuntu "ATI new driver (fglrx) doesn't work for mobility radeon 9600. (dup-of: 215799)" [Undecided,New] https://launchpad.net/bugs/215800
<ubotu> New bug: #216110 in linux-restricted-modules-2.6.24 (restricted) "Xorg crashes unpredictably with compiz running." [Undecided,New] https://launchpad.net/bugs/216110
<ubotu> New bug: #211796 in xserver-xorg-driver-via (universe) "can't run wine! system freezes" [Undecided,New] https://launchpad.net/bugs/211796
<ubotu> New bug: #110125 in linux-restricted-modules-2.6.24 (restricted) "[nvidia] GL xscreensavers crashed" [Undecided,Confirmed] https://launchpad.net/bugs/110125
<ubotu> New bug: #206039 in xscreensaver (main) "[nvidia] gears crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/206039
<ubotu> New bug: #207293 in xscreensaver (main) "[nvidia] flyingtoasters crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/207293
<ubotu> New bug: #208525 in xscreensaver (main) "[nvidia] flipflop crashed with SIGSEGV in _IO_link_in() (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/208525
<ubotu> New bug: #202835 in xscreensaver (main) "[nvidia] flurry crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/202835
<ubotu> New bug: #205578 in xscreensaver (main) "[nvidia] glslideshow crashed with SIGSEGV (dup-of: 110125)" [Undecided,Incomplete] https://launchpad.net/bugs/205578
<ubotu> New bug: #206853 in xscreensaver (main) "[nvidia] gltext crashed with SIGSEGV in _nv000079gl() (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/206853
<ubotu> New bug: #208519 in xscreensaver (main) "[nvidia] glknots crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/208519
<ubotu> New bug: #123300 in xscreensaver (main) "[nvidia] xrayswarm crashed with SIGSEGV in XDrawLine() (dup-of: 110125)" [Medium,New] https://launchpad.net/bugs/123300
<ubotu> New bug: #145591 in xscreensaver (main) "[nvidia] gflux crashed with SIGSEGV in _IO_link_in() (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/145591
<ubotu> New bug: #147295 in xscreensaver (main) "[nvidia] glmatrix crashed with SIGSEGV in _IO_link_in() (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/147295
<ubotu> New bug: #176976 in xscreensaver (main) "[nvidia] moebius crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/176976
<ubotu> New bug: #191197 in xscreensaver (main) "[nvidia] sierpinski3d crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/191197
<tormod> bryce, as you can see I have been going through nvidia crashes. On nvidia it is either (GL & i386) or (non-GL & amd64). On fglrx it is mostly (GL & amd64).
<tormod> somebody should probably mark 110125 "Critical"
<ubotu> New bug: #216241 in linux-restricted-modules-2.6.24 (restricted) "version 8.3 has broken dkms system." [Undecided,New] https://launchpad.net/bugs/216241
<ubotu> New bug: #216246 in linux-restricted-modules-2.6.24 (restricted) "Ati fglrx 8.3" [Undecided,New] https://launchpad.net/bugs/216246
<Q-FUNK> somehow, I suspect that some patch in xserver-xorg-core managed to break DDC again on amd/geode
<Q-FUNK> same source code, same -geode package.  works on an older snapshot of hardy, fails on the currently frozen codebase.
<ubotu> New bug: #216347 in wacom-tools (main) "wacomcpl missing from package" [Undecided,New] https://launchpad.net/bugs/216347
<Q-FUNK> jcristau: the patches you merged for x86emu in Debian/unstable seem to work fine with -geode.  thanks!
<jcristau> Q-FUNK: ok, thanks for testing
<Q-FUNK> jcristau: at least, no hardware freeze and DDC seems to work fine there.
<Q-FUNK> jcristau: however, it borke a few days ago on Ubuntu.
<Q-FUNK> broke, even
<Q-FUNK> on Ubuntu, the driver reverts to its default 800x600 rez, which suggests X core problems.
<jcristau> well if you know when it broke, it should be pretty easy to find what exactly broke it
<Q-FUNK> sometimes during this week
<Q-FUNK> at least, DDC autoconfiguration was working fine a few days ago, using the -amd 2.7.7.7-1 that is currently in hardy
<jcristau> well then, find the culprit and fix it?
<Q-FUNK> I don't have fast enough hardware to rebuild xserver-xorg-core so many times
<Q-FUNK> but there was only one recent upload of core and it was this week on the 9th.
<Q-FUNK> so it's pretty certain thta it's one of those patches
<jcristau> and none of them seem related
<Q-FUNK> indeed
<dennda> Bug #216454 @ bryce. The first in a series
<ubotu> Launchpad bug 216454 in xserver-xorg-video-intel "Cloning and "Extending" a screen keeps the system in a state with which you cannot work" [Undecided,New] https://launchpad.net/bugs/216454
<ubotu> New bug: #216454 in xserver-xorg-video-intel (main) "Cloning and "Extending" a screen keeps the system in a state with which you cannot work" [Undecided,New] https://launchpad.net/bugs/216454
<ubotu> New bug: #216490 in xserver-xorg-video-intel (main) "Need a Pipe-A quirk for 1028:00c8" [Undecided,New] https://launchpad.net/bugs/216490
<ubotu> New bug: #216522 in xrandr "RandR detects wrong properties of screen" [Undecided,New] https://launchpad.net/bugs/216522
#ubuntu-x 2008-04-13
<ubotu> New bug: #216562 in xorg (main) "package xserver-xorg 1:7.3+10ubuntu8 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/216562
<ubotu> New bug: #216629 in linux-restricted-modules-2.6.24 (restricted) "fglrx incompatible with x1600pro agp" [Undecided,New] https://launchpad.net/bugs/216629
<ubotu> New bug: #216636 in linux-restricted-modules-2.6.24 (restricted) "[hardy] Nvidia 9600 GT Not Supported" [Undecided,New] https://launchpad.net/bugs/216636
<ubotu> New bug: #216658 in linux-restricted-modules-2.6.24 (restricted) "Madwifi not working after 2.6.24-16 update (x86_64)" [Undecided,New] https://launchpad.net/bugs/216658
<ubotu> New bug: #216680 in linux-restricted-modules-2.6.24 (restricted) "Nvidia drivers doesn't load on startup" [Undecided,New] https://launchpad.net/bugs/216680
<ubotu> New bug: #216696 in xserver-xorg-video-ati (main) "failing to detect available resolutions, cannot use proper ones (regressed)" [Undecided,New] https://launchpad.net/bugs/216696
<ubotu> New bug: #205836 in update-manager (main) "Stack Smashing Still Happening with libc6_2.7-9ubuntu2_i386 (dup-of: 205079)" [Undecided,Triaged] https://launchpad.net/bugs/205836
<ubotu> New bug: #215446 in update-manager (main) "dependency problems - leaving unconfigured (dup-of: 205079)" [Undecided,Incomplete] https://launchpad.net/bugs/215446
<ubotu> New bug: #203568 in xorg-server (main) "usb mouse doesn't work on hardy" [Undecided,Confirmed] https://launchpad.net/bugs/203568
<ubotu> New bug: #216766 in xserver-xorg-video-openchrome (main) "distorted screen with openchrome-drivers" [Undecided,New] https://launchpad.net/bugs/216766
<ubotu> New bug: #216838 in xorg (main) "Screen instable (like raining) in Acer Travelmate 6592 (Hardy Beta)" [Undecided,New] https://launchpad.net/bugs/216838
<ubotu> New bug: #216949 in xserver-xorg-video-intel (main) "Intel graphics (945gm) drivers doesn't work in Hardy, no direct rendering (HP 530)" [Undecided,New] https://launchpad.net/bugs/216949
<ubotu> New bug: #216961 in xorg (main) "Visiontec x1300 Creates Unusable system" [Undecided,New] https://launchpad.net/bugs/216961
#ubuntu-x 2009-04-06
<cwillu> poke poke
<cwillu> oh ya, and some day I'll put a radeon card back into a computer and check if I can still reproduce bug #174427, I promise :p
<ubottu> Launchpad bug 174427 in xserver-xorg-video-ati "[RV280 9250] [AGP] Tremulous causes X server crash (signal 11) at depth 16" [Medium,Invalid] https://launchpad.net/bugs/174427
<bryce> cwillu:  For a more general purpose message, maybe: '''Bugs can have similar symptoms but different root causes.  Check that you have the same chipset _before_ commenting (lspci |grep VGA).  Upstream has a one-person-one-issue policy, so if you're not 100% certain you have the same issue, your issue won't get examined if you don't report it as a new bug.'''
<bryce> (sorry for late reply, I was off work today and it was nice out so mostly worked on the yard and on some shop projects.)
<Ng> what sets DPMS settings these days?
<Ng> I just applied some updates and xset is now showing that my LCD will DPMS-Off after 60 seconds of inactivity. Pretty sure it wasn't like that before, and I expect it'll go away if I bounce X, I'm just curious what touches that stuff these days
<tjaalton> gnome-power-manager
<Ng> ah, that crashed during the upgrade :)
<tjaalton> heh
<Ng> probably hal restarting
<bryce> gods how I hate -intel
<tjaalton> bryce: 277 open bugs :P
<bryce> tjaalton: indeed
<tjaalton> all time high on all the team packages
<tjaalton> I think
<tjaalton> lrm doesn't count
<bryce> think you're right
<bryce> -intel sucks
<bryce> enough for one day...  night.
<tjaalton> night :)
<albert23> patch 116_865g_disable_dri.patch seems a bit unfortunate, given freedesktop bug 21060
<ubottu> Freedesktop bug 21060 in Driver/intel "Crash in drm_intel_gem_bo_start_gtt_access with XV if DRI disabled" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=21060
<albert23> and we have crash reports for both 845 and 865
<albert23> (upstream changed the title from XV with large virtual display into XV if DRI disabled)
<bryce> hi albert23: 
<albert23> hi bryce
<bryce> funny you should mention this; I just happen to have started looking into all the Xv crash issues
<albert23> I went looking for totem crashes :-)
<bryce> I agree disabling dri on 865 is unfortunate, but it seems the system doesn't even boot up without that
<bryce> so, in my view, playing videos successfully is a secondary issue to that
<albert23> well, we can fix the X crash
<albert23> and playing video may still be possible without XV
<bryce> exactly.  also, we're getting a spate of reports of Xv crashes beyond just 865
<albert23> That worked with the large virtual display
<bryce> I suspect the crashes are unrelated to whatever is requiring dri disabled on 865
<bryce> albert23: give me any ideas, insights, or data you've uncovered.  I'm still just trying to digest it all
<bryce> what we really need are full backtraces, and so far none of the bug reports have one.  still looking though.
<bryce> 347527 has a partial backtrace but it's not enough
<albert23> I don't have any 8xx
<albert23> I wonder if bug 304871 could be fixed by disabling gem
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/304871/+text)
<albert23> the "Couldn't bind memory for BO front buffer" problem
<bryce> I wondered about that
<bryce> given how late we are, and how intricate that chunk of code is, it makes me a bit uncomfortable to think about
<albert23> So adding the module option from 349992 would be interesting
<albert23> 347527 has " Failed to pin xv buffer" which I found only in one place in -intel
<albert23> so that crash we can fix as well
<bryce> albert23: how confident are you in your patch for fdo #21060?
<albert23> I got that idea because I had seen the combination of the unreference and the pointer=NULL on many other places in the code
<bryce> it sounds appropriate to me.  wish we had some feedback from upstream on it
<albert23> It's assigned to anholt now
<bryce> albert23: what does Gordon's last comment on that bug mean?
<albert23> I think that explains why he changed the title of the bug
<bryce> ohh
<bryce> ok, so if I understand correctly, having DRI disabled triggers a code path that causes this bug, and if your virtual frame buffer is set large, that causes DRI to be disabled.  
<bryce> intriguing
<albert23> That's how I understand it as well
<albert23> And slangaseks log showed DRI was indeed disabled for him
<bryce> ok, suddenly pieces fall into place :-)
 * bryce studies further
<bryce> albert23: notice the patch on http://lists.freedesktop.org/archives/intel-gfx/2009-February/001426.html touches the code but still has the unref problem
<albert23> that added a condition to the code. And guess what you see in the first half of the condition?
<albert23> drm_intel_bo_unreference(pPriv->buf); followed by pPriv->buf = NULL;
<bryce> indeed
<bryce> but why did they still omit it in the second stanza?  hmm
<bryce> it sounds like on bug 347527 that it's the inverse of 354688 - crashes *unless* DRI is disabled
<ubottu> Launchpad bug 347527 in xserver-xorg-video-intel "[830m] mplayer appears to crash X unless DRI is disabled" [Undecided,Incomplete] https://launchpad.net/bugs/347527
<albert23> yeah, that's what the title says. But I don't see evidence DRI was enabled in the log
<albert23> seems to use software rendering? 4.130567] (II) GLX: Initialized DRISWRAST GL provider for screen 0
<bryce> [    2.236645] (**) intel(0): Option "NoDRI"
<albert23> bryce: so he has a log with DRI disabled, and containing the crash. That doesn't match the title?
<bryce> albert23: yep
 * bryce fixifies title
<bryce> ahhh I understand now.  Boy I'm slow today
<bryce> he has been having unrelated problems (X freezes) that drove him to disable DRI, and now is getting video playback crashes
<bryce> so that fits with our hypothesis
<albert23> Ahh, you are still faster then me
<bryce> 351869 is another dupe
<bryce> kewlness, so all the bugs I've looked at so far have either had DRI off for some reason, or was a 945 with virtual buffer > 2048
 * bryce scans for more dupes
<albert23> 352760
<bryce> heya jbarnes
<jbarnes> bryce: hi
<jbarnes> I couldn't reproduce fdo #20739 with current bits or 2.6.1 + 2.6.29
<jbarnes> trying with jaunty now (my upgrade just finished)
<bryce> jbarnes: I think we got a stranglehold on the Xv crash bug.  albert23 has a patch that looks like it may solve it - http://bugzilla.freedesktop.org/show_bug.cgi?id=21060
<ubottu> Freedesktop bug 21060 in Driver/intel "Crash in drm_intel_gem_bo_start_gtt_access with XV if DRI disabled" [Normal,New]
<jbarnes> bryce: which versions of xf86-video-intel, mesa & kernel is jaunty shipping with?
<bryce> seems to be a code path triggered when DRI is off for whatever reason
<jbarnes> bryce: yeah the fix for 21060 looks good
<bryce> { 2.6.3, 7.4, 2.6.28+backports }
<jbarnes> any gem fixes backported?
<jbarnes> or are you waiting for me to tell you which ones? :)
<bryce> possibly not enough ;-)
<bryce> yes please :-)
<bryce> some gem stuff is backported for the kernel
<bryce> I'm not directly involved in that so don't know the exact details
<jbarnes> there were so many changes...
<jbarnes> what's Martin Pitt's irc nick?
<bryce> we're pretty late in the cycle for kernel changes now, so I think the kernel team would be interested only in absolutely critical fixes
<bryce> pitti
<jbarnes> right, hopefully a hang fix would qualify
<bryce> yep, especially if it affects pitti
<bryce> jbarnes: hey btw are any of the register docs public for any of the 8xx chipsets?
<jbarnes> I guess he's not around... is he on the kernel team?
<jbarnes> bryce: not yet... hopefully after the g4x stuff gets released we'll be able to do 915/945 and 8xx
<bryce> probably in bed (based in germany).  He's the desktop technical lead, so not kernel but pulls lots of weight
<jbarnes> ok cool
<jbarnes> I've got a couple of bugs from him, I'll try chatting with him tomorrow
<jbarnes> aha crashed it w/the jaunty kernel :)
<jbarnes> hm maybe I mean :/
<jbarnes> ah seems better with 2.6.3
<bryce> jbarnes: regarding the performance issue on intel, I did up a page to help folks troubleshooting such problems - https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
<bryce> I'd love to say, "The reason EXA performance regressed from 2.5 to 2.6 is ..." but I'm clueless
 * jbarnes looks
<jbarnes> bryce: EXA uses GEM too... in fact they share render accel code in *_render.c
<bryce> ok
<jbarnes> the UxaTesting page looks interesting... some of the "worse" reports seem unrelated/tangential (like video tearing or 3d perf regression)
<jbarnes> dri2 has lower performance in some cases, mainly due to the tiling regression (which is fixed in 2.6.29) and some additional blit overhead in some cases
<bryce> a lot of the reports on that page are on 2.6.1 btw.  I neglected to direct people to indicate their driver version
<bryce> looking at the wiki changelog, it seems we're getting fewer "worse" reports now, but still quite a few "mixed"
<jbarnes> 2.6.3 was *much* better, uxa-wise
 * bryce nods
<jbarnes> there's also the memory leak in fdo 20704 which is pretty much fixed now
<bryce> we do still have a ton of bugs open for issues when UXA is enabled.  I've encouraged people to forward them upstream as well, so hopefully you've been seeing an influx of testers
<jbarnes> but again that's a dri2 issue rather than uxa
<jbarnes> yeah we've been working solely on bug fixing for the past few weeks
<bryce> kewl
<jbarnes> so one of the big perf issues people found when going from dri1 -> dri2 is that tiled rendering got disabled
<jbarnes> you might add that to the uxa section... it's fixed in 2.6.29 and in the 2.7 driver but it was a pretty huge regression on some 945 platforms
<albert23> jbarnes: that also happens with EXA?
<bryce> ok
<jbarnes> albert23: what the perf regression?  it should only affect dri2
<albert23> performance with 945 and exa is still very poor (dual channel memory)
<jbarnes> dri2 can't be enabled with exa
<jbarnes> ah that could be a bigger gem regression
<albert23> and I get it fixed by disabling gem
<jbarnes> anholt has been working on a fix for the daul channel memory problem, the so-called "a17 swizzle" bug
<kees> albert23: how do you disable GEM?
<albert23> kees: I patched the intel driver
<kees> haha
<bryce> albert23: got the patch?  I could at least link to it from the performance page for folks to try
<albert23> bryce: that's the one we discussed last week
<jbarnes> albert23: look for "drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU." on the dri-devel mailing list
<bryce> albert23: right, my brain is swiss cheese 
<albert23> kees: http://paste.ubuntu.com/142337/
<albert23> you need to switch of gem and add a second patch (accepted upstream)
<jbarnes> bryce: so those two issues (the tiled rendering/fence reg one and the a17 one) are probably worth adding to that page for your bleeding edge users
<jbarnes> description for the tiled rendering one can be found in my message to intel-gfx, subject "[RFC] support tiled rendering on pre-965 chips"
<albert23> jbarnes: thanks, found it
<bryce> jbarnes: ok thanks
<jbarnes> albert23: please reply with testing results if you get a chance
<jbarnes> albert23: to eric and dri-devel I mean
<albert23> jbarnes: the patch is for kernel 2.6.29 I suppose?
<jbarnes> yeah probably against eric's drm-intel-next branch
<bryce> jbarnes, what is "a17"?  I saw a bug report on that but don't know what it means.  Is it just some register address?
<albert23> OK, I will give it a try later this week
<bryce> hmm maybe I've asked this question before
<jbarnes> bryce: it refers to a memory addressing mode
<jbarnes> bryce: our gpu & memory controller are on the same chip
<jbarnes> and there are all sorts of weird addressing modes they use in combination with the cpu to increase performance
<jbarnes> a17 is one of the bits ("address bit 17") that gets set or cleared in certain dual channel configs
<jbarnes> normally it's invisible, but if a page of graphics memory gets swapped out and then back in at a different address, the a17 setting for the new page might be different
<jbarnes> and until Eric's patch we didn't track that, so we just had to disable tiling (and thus any a17 funkiness) altogether
 * bryce updates https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
<bryce> thanks jesse, hopefully I didn't butcher the explanation too badly
 * jbarnes checks
#ubuntu-x 2009-04-07
<jbarnes> on the tiled rendering section it should probably refer to pre-965 platforms not just 945
<jbarnes> the other section looks good
<cwillu> i.e., into the 800's?
<cwillu> or just 910+?
<jbarnes> yeah would have affected 8xx as well
<bryce> got it
<albert23> bryce: the part on /dev/dri/card0 permissions doesn't seem correct. We use hal+acl to set the permissions, not udev.
<albert23> note the + in crw-rw----+
<bryce> albert23: ok, was just copying hearsay off one of the performance bugs
<bryce> albert23: I've s/udev/hal+acl/ but could you update that section of the page if it's still not correct?
<albert23> bryce: I can take a look tomorrow. It's getting late here
<bryce> ok
<bryce> tjaalton: heh, I just got ready to upload the fix for 337926 and see you've beaten me
<bryce> ...or maybe not.  Looks like you've gone to bed.  I'll go ahead and put it in.  Hopefully I am not stepping on toes too hard here...
<bryce> http://fedora.nicubunu.ro/webcomics/ctrl-alt-backspace.svg
<cwillu> bryce, disabled it by default just in time.  I figure we got another 18 months before alt-sysrq-k becomes well known enough to be the butt of bad webcomic jokes :p
<bryce> cwillu: hehe
<bryce> cwillu: hey, I want to help sort out why you're not able to set Triaged; you're still having that problem?
<cwillu> sec
<cwillu> no, triaged still doesn't show up on the list
<cwillu> new/incomplete/invalid/confirmed/inprogress/committed/released
<cwillu> (looking at bug #174427, which is on xserver-xorg-video-ati)
<ubottu> Launchpad bug 174427 in xserver-xorg-video-ati "[RV280 9250] [AGP] Tremulous causes X server crash (signal 11) at depth 16" [Medium,Invalid] https://launchpad.net/bugs/174427
<cwillu> (and invalid, because I've been ignoring it for years now :p)
<jbarnes> bryce: so looks like lp 348428 is fixed but the fdo bug hasn't been updated?
<ubottu> Launchpad bug 348428 in xserver-xorg-video-intel "Switching to another user and then to anything else causes freeze in drm_intel_bo_unreference ()" [High,Fix released] https://launchpad.net/bugs/348428
<bryce> hmm, you're definitely on the team
<cwillu> there was some launchpad trouble around when you confirmed me though, do things ever get out of sync like that?
<bryce> jbarnes: well, we "fixed" it by dropping patches we think caused the regression
<bryce> those are upstream patches so the issue still needs solved there afaik
<jbarnes> ah ok
<bryce> actually I just dropped one of the two patches, the other seemed less suspicious
<bryce> weirdly, the issue that the patch was supposed to fix did not reappear on dropping it
<jbarnes> funky
<bryce> -intel is like magic to me
<jbarnes> it's a twisty maze
<cwillu> filled with cavernous bugs, all alike
<jbarnes> something like that
<bryce> jbarnes: btw dunno if you saw but I've switched off DRI for i865 and i810 due to freeze problems.
<jbarnes> yeah I saw that...
<bryce> some day it would be nice to fix that
<jbarnes> yeah 8xx has rotted a bit, we hope to fix a bunch of 8xx bugs after 2.7.0 comes out but nothing solid yet
<bryce> that would be sweet; roughly a quarter to a third of our -intel bugs are for 8xx chips
<jbarnes> yeah there are a ton of centrino platforms out there
<jcristau> bryce: intel wants people to buy new laptops, so they break the old ones ;)
<bryce> jcristau: sometimes I wonder ;-)
<bryce> I really lost it on one guy that complained about support for SVideo on his i845, that he'd never buy intel graphics, yada yada
<bryce> I've heard the same complaint from nvidia and fglrx users about hardware support dropping
<bryce> at least with -intel, users *can* contribute the effort to help maintain the old stuff
<bryce> they just *don't*
<bryce> (afaik)
 * cwillu pokes bryce with a "hey, I'm a user" stick
<cwillu> definitely can't mark bugs as triaged though
<bryce> a rare gem you are!
 * cwillu beams
<bryce> yeah I'm trying to figure this out...  I wonder if you have to be an Administer for the project
<jcristau> every once in a while a non-intel and non-redhat patch makes it upstream :)
<cwillu> can't set importance either, which isn't terribly surprising
<bryce> however I don't seem to be able to bless people into Adminship (I can demote people though...)
<cwillu> I tried logging out and back in yesterday, on the off chance that it was something in my session
<bryce> cwillu: possibly it requires being on the ubuntu-qa team... 
<bryce> (if my reading of 118708 is correct)
<cwillu> Should I poke ubuntu-qa then?
<cwillu> probably not really a huge deal for now
<bryce> one sec
<cwillu> I mean, I can always add a triaged tag and poke you with a list
<bryce> here try this - https://launchpad.net/~bugsquad/+join
<cwillu> <waiting for launchpad>
<jcristau> cwillu: that goes without saying :)
<cwillu> oh, no, it needs to be said :p
<bryce> we sync launchpad's refresh rate to the performance of your video driver
<cwillu> oh, let me switch from my laptop (i945) to my desktop (nvidia :p)
<jcristau> i thought it was to make sure you could finish your coffee break while it's loading a page
<cwillu> I usually keep a coffee maker 2 feet to the left of my left-most monitor
<cwillu> maybe moving it to the next room would improve launchpad's perceived performance :)
<cwillu> bryce, no, still can't touch importance or set triaged
<bryce> hrm
<bryce> ok, I'll check with brian murray and figure out how to get you set up
<cwillu> k, thanks
<cwillu> really, as long as launchpadlibs works I can still be productive
<bryce> cwillu: aha brian pointed me to the guidelines - https://wiki.ubuntu.com/UbuntuBugControl
<cwillu> okay, 
<cwillu> I'll hit the enter key instead of shift
 * cwillu mutters
<cwillu> I'll get that started tomorrow.  Heading off to the coffee shop with laptop in tow right away :)
 * cwillu will poke again in 30 minutes or so
<bryce> ok cool; movie time
<tjaalton> bryce_: no problem, I noticed that my dev laptop was not here, so had to postpone it :)
<bryce_> hidy ho
<bryce_> hidie?
<bryce_> tjaalton: how are your children doing?
<tjaalton> bryce_: sitting on the couch, watching telly ;)
<tjaalton> ie. doing well, still coughing though
<tjaalton> and we finally found a place we could call "home", so it's bargaining time..
<tjaalton> hmm, I'm sure I heard my phone beep somewhere..
<cwillu_clone> bryce, bug #328484 strikes me as something that could be upstreamed.  Reporter is responsive, bug is reproducible, etc
<ubottu> Launchpad bug 328484 in xserver-xorg-video-intel "[igc4] displayport monitors not detected in Intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/328484
<jcristau> keithp is already working on DP
<cwillu_clone> He's tried the jaunty beta and a more recent jaunty daily, and confirmed that it still exists
<cwillu_clone> ah, k, know the bug # offhand?
<jcristau> 19995
<jcristau> (not offhand, had to find it first :) )
<cwillu_clone> :)
<cwillu_clone> that's on freedesktop?
<jcristau> yeah
<tjaalton> bryce_: could you ack bug 355340, it'd enable proper wacom hotplug and there are people confirming that, even with a serial tablet
<ubottu> Launchpad bug 355340 in wacom-tools "[FFe] Please allow a new version of wacom-tools" [Wishlist,Confirmed] https://launchpad.net/bugs/355340
<tjaalton> or nack, whichever you prefer :)
<bryce_> sure
<bryce_> done
<bryce_> cwillu_clone: good find.  Yes, link the upstream bug to ours, and encourage the user to collaborate with upstream on the issue
<cwillu_clone> already done
<cwillu_clone> I've been talking to him in #ubuntu+1 as well, although he hasn't poked me yet today :)
<cwillu_clone> bryce, is launchpadlib known for being broken randomly?
<jcristau> i guess i'm going to have to coordinate somewhat with ron when i finally get the new x to unstable...
<cwillu_clone> Launchpad.get_token_and_login('just testing', STAGING_SERVICE_ROOT, cache) is giving me a type error (float is required) in an egg which I _think_ was just pulled in when I installed it
<jcristau> tjaalton: is there anything in wacom/hal that's not upstream yet, for the hotplug stuff?
<cwillu_clone> and I was gonna get all pythonic on launchpad's api too :(
<cwillu_clone> ah, there we go.  Never trust easy_install, even if you didn't call it yourself in the first place
<tjaalton> jcristau: no, it's all in 0.8.3.*
<jcristau> tjaalton: ah, nice. thanks.
<tjaalton> 0.8.3 also supports the new Intuos4 devices.. had to check what they look like and it made me drool :P'''
<tjaalton> bryce_: thanks
<bryce_> cwillu_clone: yes launchpadlib has a lot of bugs in it
<bryce_> cwillu_clone: I've been accumulating workarounds in a utility library for stuff
<cwillu_clone> was a 2.6 bug in httplib2 that's fixed in our repository, but not on pipy
 * cwillu_clone 's coffee is wearing off, time to sleep
<bryce_> night
<cwillu> well, time to leave denny's at least :p
<cwillu> wow, it took that long to time out?
<Unggnu> hi all
<Unggnu> I wanted to add a passage at the top of the Backtracing wiki for apport. Is that Ok?
<Unggnu> Afaik Apport can only track Xorg crashes in INtrepid oder later
<Unggnu> But it is much more easier since no second computer is needed, no extra packages and so on
<Unggnu> and all the needed information is posted
<bryce_> heya Unggnu
<Unggnu> hi bryce_
<bryce_> Unggnu: yep apport usage is a good idea
<Unggnu> I wanted a short passage at the top.
<bryce_> in fact mdz had suggested doing it a while back, so he'll be happy to see your work
<Unggnu> bryce_: btw. bug #345796 has a patch from upstream which works for me and a Gentoo guy :)
<ubottu> Launchpad bug 345796 in xserver-xorg-video-intel "[i855 i915] Xorg crashed with SIGSEGV in drm_intel_bo_unpin()" [Medium,Confirmed] https://launchpad.net/bugs/345796
<Unggnu> ok
 * bryce_ looks
<bryce_> Unggnu: ok thanks, I put it on my todo list.  I'll try to get it in tomorrow
<Unggnu> thx
<Unggnu> hm, jumping to an anchor with spaces doesn't seem to work in the Wiki
<bryce_> nope
<Unggnu> https://wiki.ubuntu.com/X/Backtracing - I hope it is alright
<Unggnu> Btw. the anchor space problem should be fixed. Makes much more work.
<Unggnu> if you can't to a specific part of a wiki page
<Unggnu> +point
<Unggnu> Apport works fine with X in Jaunty and according to pitti with Intrepid also
<bryce_> yeah
<bryce_> probably can do it with &32; or whatever the space html symbol is
<bryce_> looks good
<Unggnu> no, %20 doesn't work
<Unggnu> I guess that's the reason why Wikipedia converts them to _
<bryce> yay, wacom-tools updated.  congrats timo
<tjaalton> bryce_: yeah :)
<bryce> ok, enough bug damage for one day.  bedtime.  night.
<tjaalton> night!
<bryce> morning
<jbarnes> hi
<sbeattie> hrm, is there a reason /etc/X11/xinit/xinitrc is not executable?
<bryce> sbeattie: maybe it is sourced rather than executed?
<bryce> heya albert23
<albert23> hi bryce
<bryce> sweet, finally a debugging method for GPU hangs on -intel:  http://bugs.freedesktop.org/show_bug.cgi?id=17638#c28
<ubottu> Freedesktop bug 17638 in Driver/intel "[945GM] intermittent crashes (Ring of Death) if ExaNoComposite unset" [Critical,New]
<sbeattie> bryce: the reason I ask is that the vnc4server's default .vnc/xstartup script does "exec /etc/X11/xinit/xinitrc" by default which fails; so I'm curious whether that should be fixed in in X or vnc4server.
<bryce> hmm, that's such a common file that I would guess if it is not executable, it's for a very good reason (security perhaps?)
<bryce> if its non-executable state were a problem, I'd have expected to see more widespread bug reports on it
<bryce> maybe jcristau has better wisdom on this
<bryce> btw I've written up https://wiki.ubuntu.com/X/Troubleshooting/Freeze for helping in triage freeze / gpu lockup bugs
<sbeattie> bryce: one thing to note is that in all the hangs I've seen, the mouse still would move, but otherwise X was frozen. You may wish to incorporate that into the Narrowing Class section.
<bryce> I mention that in the symptoms section, but I could mention that there too
<bryce> done
<cwillu> sbeattie, should be sourced, xinitrc can set environment vars to configure things, which doesn't work if you exec it afaik
<cwillu> at least, so says redhat, gentoo and debian :p
<sbeattie> cwillu: on a fork/exec, the parent won't get the env variables, true; but a direct exec() replaces the calling processes memory with the exec()ed one.
<sbeattie> cwillu: amusingly, bug 257724 claims its executable on fedora.
<ubottu> Launchpad bug 257724 in vnc4 "vnc4server startup script error" [Undecided,New] https://launchpad.net/bugs/257724
<sbeattie> anyway, sourcing in vnc4server should be fine.
<jbarnes> bryce: so on lp #344740 it sounds like you've definitely narrowed things down to the Xv patch?
<ubottu> Launchpad bug 344740 in xserver-xorg-video-intel "[i855] xserver-xorg-video-intel-2.6.3 : Only green window when playing movies with XV extension" [Undecided,Fix released] https://launchpad.net/bugs/344740
<jbarnes> (upstream fdo #20956)
<albert23> bryce:  I have updated the /dev/dri/card0 permissions part on IntelPerformance
<tseliot> federico1: did you review my patch? http://bugzilla.gnome.org/show_bug.cgi?id=568160
<ubottu> Gnome bug 568160 in libgnome-desktop "Gnome Settings daemon causes high CPU usage with an expensive call" [Major,Unconfirmed]
<bryce> jbarnes: yeah once that was reverted, people experiencing the crash said the problems suddenly went away
<bryce> the only thing I'm scratching my head over is why the green window issue when playing Xv did not come back
<bryce> albert23: excellent :-)
<jbarnes> what was the patch you reverted exactly?
<mnemo> there was a fix for green video included in the mesa7.4 upload
<mnemo> a mesa fix
<mnemo> for people seeing green video in elisa
<bryce> mnemo: aha
<bryce>   * Disable 114_fix_xv_with_non_gem.patch: At the time we accepted it, it
<bryce>     sounded a little risky, so I took it on the condition that it didn't
<bryce>     cause regressions, which apparently we have proof that it does.
<bryce>     (LP: #348428) (Reopen 344740)
<mnemo> bryce: this is the bug I was thinking about --> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/349127
<ubottu> Ubuntu bug 349127 in mesa "Elisa displays video with greenish/purplish colors" [High,Fix released]
<mnemo> i was able to repro that bug on my intel G45 before the mesa7.4 upload
<bryce> jbarnes: Eric's comment "...hopefully not anger tiny-aperture systems too much" made me uncertain about the patch to begin with.
<jbarnes> yeah
<bryce> mnemo: kewl, so that's one less loose end, that probably explains it.
<bryce> jbarnes: btw I wrote up a page on troubleshooting freezes - https://wiki.ubuntu.com/X/Troubleshooting/Freeze - if you know any tricks worth listing there, I'd love to add more
<bryce> jbarnes: cworth told me about the new batchbuffer dump technique, which sounds pretty cool for the future
<jbarnes> yeah that can be helpful
<jbarnes> bryce: the biggest thing with freezes (and most bugs but especially freezes) is figuring out a way to reliably reproduce it
<jbarnes> might be good to add that to the page... create a series of steps that causes the freeze reliably
<jbarnes> if you can do that we'll probably be able to fix it
<jbarnes> if not, it'll take awhile (like the 945 hang)
<jbarnes> bryce: so reverting the one line change to i830_video.c allows fast user switching to work?
<bryce> ok will add
<bryce> jbarnes: correct
<seb128> is xvfb-run known to be broken?
<seb128>  $ xvfb-run ls
<seb128>  [: 182: Illegal number: 
<seb128>  xvfb-run: error: display :99 already in use
<seb128> hum
<seb128> it seems to works fine using bash
<seb128> ok, bryce broke it with his upload a week ago
<seb128> +    if [ "$XVFBPID" -eq "$(</tmp/.X${SERVERNUM}-lock)" ]; then
<seb128> the $() is "" using dash
 * seb128 opens bug
<seb128> bug #357338
<ubottu> Launchpad bug 357338 in xorg-server "xvfb-run broken in jaunty using dash" [High,New] https://launchpad.net/bugs/357338
<seb128> the change also breaks multiple runs, ie pygtk call it for python 2.5 and 2.6, it detects a running instance and breaks
<jbarnes> bryce: just updated fdo #20956 (the fast user switching thing) in case you want to notify anyone
<bryce> sweet
<bryce> jbarnes: btw a kernel fix is going in tonight for some of the freezes on -intel that have been reported recently.  dunno if those reports made it up to the upstream tracker
<jbarnes> the pat related stuff?
<bryce> the BCHBAR patch
<jbarnes> ah ok
<bryce> it's being discussed on #ubuntu-kernel presently if you'd like to listen in
<jbarnes> I need to respin that one for licensing reasons... I unintentionally relicensed that code as GPL :p
<jbarnes> bryce: I guess they must be done talking about it now :)
#ubuntu-x 2009-04-08
<Unggnu> hi all
<Unggnu> bryce_:  This bug https://bugs.launchpad.net/bugs/348428 is already fixed through disabling a previous patch but upstream has now released a libdrm patch for it so ?
<ubottu> Ubuntu bug 348428 in xserver-xorg-video-intel "Switching to another user and then to anything else causes freeze in drm_intel_bo_unreference ()" [High,Fix released]
<bryce> Unggnu: good catch, that's the one jesse was working on today based on our work?
<bryce> btw, regarding the wiki links that have spaces in them, usually when I run into such situations I take it as a clue that the section I'm linking to might need to be broken out into its own separate page.
<Unggnu> Yes in apply to our report afaik
<bryce> unless there's problems with what we've changed, given we have only 1 day before final freeze, I'd leave it as is
<Unggnu> ok :)
<Unggnu> But the xv vt patch does make it?
<bryce> which one?
<Unggnu> According to the wiki: Makes sense but some passages are small but practical like the description how to use the Apport crash message
<Unggnu> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/345796
<ubottu> Ubuntu bug 345796 in xserver-xorg-video-intel "[i855 i915] Xorg crashed with SIGSEGV in drm_intel_bo_unpin()" [Unknown,Fix released]
<Unggnu> oh
<Unggnu> :)
<Unggnu> Why fixed released?
<Unggnu> Hm, maybe ubottu reads the upstream report
<Unggnu> The patch is http://launchpadlibrarian.net/24880952/119_fix_vt_switch.patch
<bryce> yes, I'll look at 345796 tomorrow, I think that should make it
<Unggnu> thx
<bryce> basically anything assigned to me, or targeted to jaunty, or milestoned to 9.04 still could make it in, either pre-release, or during final freeze, or even as an SRU
<bryce> _could_ :-)
<Unggnu> With it INtel seems quite stable atm
<bryce> ahh, now that's awesome to hear finally!
<Unggnu> Yeah, with Exa of course :)
<bryce> I'm glad the last couple weeks have seen a lot of -intel fixes
<Unggnu> I hope that UXA stays for a while
<Unggnu> so it gets stable :)
<bryce> "stays for a while"?  You mean stays off by default?
<Unggnu> no, that they don't invent ZXA shortly after :)
<bryce> hehehe
<Unggnu> They are really fast with their bug fixing but they also push things to fast forward. E.g. I still need the Overlay-X option to get a decent video experience.
<bryce> I totally agree
<bryce> we need to be more aggressive at pushing bugs upstream to them, to slow them down :-)
<Unggnu> yeah but probably won't help :-D
<bryce> ah, it might
<Unggnu> They should use launchpad for bug reporting. It is so easy then to push it upstream :)
<Unggnu> Like hplip
<bryce> yeah I know
<Unggnu> two clicks actually
<bryce> for Inkscape, we use launchpad both for the project, and for the project in Ubuntu, and it makes bug management so easy
<bryce> now if only Inkscape used bzr so it was easier to cherrypick patches ;-)
<Unggnu> :)
<Unggnu> Maybe there will be a wrapper script someday
<tseliot> federico1: ping
<federico1> tseliot: hey
<tseliot> federico1: news on you know what? ;)
<federico1> tseliot: I was reviewing your patch for #568160, then got caught up with something else
<tseliot> ok
<federico1> I'm on it now
<tseliot> federico1: great, let me know if there's something which is not clear or which should be improved
<federico1> sure
 * jbarnes looks for manoj
<federico1> tseliot: made some stylistic changes to your patch; I'm building it now to test it...
<federico1> (you got caught by the pesky four-space tabs in that file...)
<bryce> jbarnes: callsign 'manjo'.  I pinged him on our internal IRC to come here.
<bryce> jbarnes: here he comes
<jbarnes> cool thanks
<jbarnes> manjo: just wondering about the sun java crash
<manjo> bryce_, 
<manjo> jbarnes, yes
<jbarnes> lp 337608, fdo 20739
<ubottu> Launchpad bug 337608 in xserver-xorg-video-intel "[i945] X crashes in fbBlt() when using Sun Java Plugin 6 + firefox3.0 on Asus EEEPC 1000" [Unknown,Confirmed] https://launchpad.net/bugs/337608
<manjo> jbarnes, will test now and confirm 
<jbarnes> great thanks
<manjo> be in a bit .. I am chowing down my lunch as fast as I can 
<manjo> jbarnes, thanks for pointing me to it 
<jbarnes> manjo: np, just trying to close all my ubuntu bugs upstream ;)
 * bryce hugs jbarnes
<jbarnes> heh
<manjo> no love for me for finding it ? 
<manjo> jbarnes, upgrading now will test as soon as its done and post results on both bugs
 * jbarnes shoots the messenger
<jbarnes> manjo: great
 * manjo thinks that is not a bug he will die for ... try again
 * bryce hugs manjo
<jbarnes> hehe
<jbarnes> hugs >> bullets to the head
<federico1> tseliot: committed to svn now - thanks for working on this :)
<tseliot> federico1: yes, I know, I used to code a lot in Python (hence the four-space tabs set in my IDE)
<tseliot> federico1: thanks :-)
<manjo> bryce, jbarnes sorry bad news
<manjo> bryce, jbarnes it still crashes
<jbarnes> oh no
<jbarnes> manjo: what bits exactly?
<jbarnes> 2.6.28-11-generic & the 2.6.3 driver package?
<manjo> ii  xserver-xorg-video-intel                   2:2.6.3-0ubuntu8    
<manjo> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
<manjo> latest jaunty kernel
<jbarnes> hm
<jbarnes> just going to the test page w/firefox & scrolling right?
<manjo> yes
<jbarnes> ok I'll try again
<manjo> I wil leave the bug as is you want me to comment ? 
<manjo> jbarnes, I can see this is a nasty one 
<jbarnes> could you add your version info to it so I don't lose it?
<manjo> done 
<jbarnes> thanks
<jbarnes> manjo: yeah I think there's something funky going on with exa in this case
<jbarnes> I have a patch that *might* fix things but I want to reproduce it so I can be sure
<manjo> ok. do you know of any other website with embedded java applet I can test with ? 
<manjo> may be this applet does bad things ? 
 * manjo thinking out loud
<manjo> ah but the correct behaviour is for the browser to crash not the xserver right ? 
<jbarnes> yeah definitely :)
<jbarnes> even if java is abusive we should at worst kill the app
<jbarnes> wow that was fast...
<jbarnes> just crashed it, I wonder if the earlier version of xf86-video-intel I tested with was ok but this one is broken?
<jbarnes> hm
<bryce> stealth patch ;-)
#ubuntu-x 2009-04-09
 * Ng tries to keep up with the slowmotion compiz bug
<Ng> bryce: should I open a new bug about the problems I see?
<bryce> I guess
<bryce> there seems to be several different issues causing performance regressions
<Ng> yeah, it sucks when various vague issues get conflated :/
<bryce> performance issues are the worst, they're not measurable and not differentiable since they're summation effects
<bryce> freeze issues are nearly as bad since you can't tell one from the next, but at least it's pretty definite when you have the issue
<tjaalton> Ng: so the problem you are seeing is with many windows open?
<Ng> tjaalton: I have three maximised windows on separate workspaces (terminator, then thunderbird, then firefox) and flipping workspaces stutters. possibly an easier symptom to work with is the background changer - instead of being a smooth fade it's 2 or 3 frames
<tjaalton> right, I get that too
<tjaalton> but it's snappy when there aren't much to draw
<tjaalton> *isn't
<Ng> yeah, and often the first workspace flip or two will be ok, but the performance degrades if I keep flipping
<tjaalton> probably the reason why they invented UXA
<Ng> it feels like it's being overly affected by the system working harder, and CPU usage is higher than with UXA, which stays smooth no matter how aggressively I flip workspaces
<Ng> perhaps, but EXA in Intrepid didn't do this
<tjaalton> intrepid didn't have gem
 * Ng nods
<Ng> what was there before gem? is there an easy way to disable gem?
<Ng> I'm a bit lost in intel acronym soup ;)
<tjaalton> dunno if it can be disabled easily
<bryce> there is a kernel patch to add a flag you can use to disable it
<tjaalton> there was no proper memory management before, I guess :)
<bryce> there's also a patch that forcefully disables it in the driver, without requiring kernel changes
<tjaalton> ok
<bryce> I can dig either up if anyone's interested.
<bryce> they're on -intel bugs
<bryce> I'm too chicken to try ripping out GEM at this late stage, at least, not without more testing
<tjaalton> Ng might want to try, I'm a bit busy with packing etc :P
<Ng> I'll have a go at the -intel level one. I'm not up for even thinking about kernel changes at this point ;)
<bryce> standby
<bryce> Ng, bug 349992 has an A17 swizzling patch for -intel
<ubottu> Launchpad bug 349992 in xserver-xorg-video-intel "[945 tiling] Low performance due to no A17 workaround" [High,Confirmed] https://launchpad.net/bugs/349992
<bryce> the kernel patch is also attached to that bug
<bryce> there is another patch, hang on
<bryce> http://paste.ubuntu.com/142337/
<bryce> all this stuff, plus the MCHBAR patch, is documented at https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
<Ng> ta
<Ng> hmm that second patch looks familiar, I think I read it after reading that IntelPerformance page and dismissed it because it was talking about 945
<Ng> but I didn't think to check if 965 matches IS_945* or if there's an IS_965 I could use
<bryce> about to pass out... bedtime... night
<Ng> cya :)
<alex-weej_> anybody heard of any bugs involving the screen flickering black a few times then staying black
<alex-weej_> my music pauses momentarily, then sometimes resumes after a few seconds or others just stays dead
<alex-weej_> and keyboard does not respond
<alex-weej_> compiz + nvidia 180
<alex-weej_> only recently started happening in jaunty :(
<alex-weej_> and with nvidia 177 compiz refuses to start so i can't rule it out
<HammerHead66> ï»¿alex-weej_: I had the same problem but it was 8.04 64 bit Gnome it was because I hadn't installed the drivers right
<alex-weej_> i've reinstalled using Jockey like 3 times
<alex-weej_> 64-bit also, though
<BUGabundo> hi
<BUGabundo> can any X guru help out on #ubuntu+1 ?
<BUGabundo> cwillu isn't in today
<SnoFox> Hey, how to I start X in failsafe mode?
<SnoFox> I bet I broke my driver.
<BUGabundo> SnoFox: not here, please
<BUGabundo> this is not a support channel
<HammerHead66> when grub screen comes up hit the Esc key on your keyboard
<SnoFox> O.o
<DBO> bryce, sorry about pinging in the wrong channel, do you mind talking about intel and xorg for a couple minutes?
<bryce> topic?
<BUGabundo> hey guys, guud evening
<bryce> heya BUGabundo
<DBO> why is it eating my CPU alive when I scroll?
<DBO> I have an intel GMA 4500... its a decent card at least in intrepid
<BUGabundo> I got that a few times too
<BUGabundo> eats 100% of one core
<DBO> causes my sound to start skipping
<bryce> DBO, check lp, think there's a bug open on that
<DBO> can you help me find it?
<bryce> freezes are higher prio for me atm but if you have a patch I can look
<DBO> I do not, I just want to understand why intel is regressing like its its job
<bryce> see the IntelPerformance page I put in the X wiki to explain that
 * DBO goes to look
<DBO> bryce, one last question, is this going to be fixed or are intel users out to drift for a release?
<DBO> bryce, http://wiki.x.org/wiki/FindPage?action=fullsearch&titlesearch=1&value=Intel am I missing something, I dont see an IntelPerformance page?
<DBO> oh, its on the dri wiki =)
<bryce> the Ubuntu-X wiki
<bryce> http://wiki.ubuntu.com/X/Troubleshooting/
<DBO> oh, okay
<bryce> as to your last question, is that just sarcasm or are you literally asking?
<DBO> I am literally asking. Is it going to be fixed for jaunty
<DBO> I am not trying to be insulting
<BUGabundo> make me +1
<bryce> heh, that question is sort of on par with "are we there yet??"  ;-)
<BUGabundo> I always knew intel drivers a *good* place
<BUGabundo> this cycle it looks like a big washout
<bryce> IF a fix is found, it will be fixed
<BUGabundo> so it's a bad bug, not drop of support?
<bryce> IF no fix is found, it won't
<DBO> I guess part of the frustration here is, why did we upgrade the X stack with all these regressions then?
<bryce> DBO, read the IntelPerformance page
<DBO> I am reading
<DBO> oh I see, you addressed it
<bryce> it is true the -intel drivers we've gotten have had rather poor QA.  We're fixing up what we can in the distro, but there's only so much we can do at this level
<BUGabundo> of course
 * jbarnes hides
<jcristau> heh
<bryce> jbarnes has been helping tons.  :-)
<pwnguin> "I just want to understand why intel is regressing like its its job"
<DBO> it's its
<bryce> hehe
<DBO> sorry =)
<jbarnes> I'm adding regressions as fast as I can
<pwnguin> a more sinister explaination would be that intel sells hardware ;)
<jcristau> jbarnes: damn cworth is trying to spoil all your good work
<jbarnes> heh
<jbarnes> GEM is a big source of regressions
<jbarnes> since it hasn't seen much development on 8xx systems
<jbarnes> we're hoping to fix a lot of those issues after the 2.7.0 release (i.e. for 2.7.1)
<bryce> I think the movement of code into the kernel has also either caused regressions or at least made them a bit harder to get fixes for
<jbarnes> (though one of the biggest issues was fixed recently in the kernel)
<bryce> s/get fixes for/get fixes into Ubuntu for/
<DBO> is there any clear picture about whats causing the scrolling performance issues on the 4500 series?
<jbarnes> GEM was insidious because now we have a few code paths to deal with in the 2D driver
<jbarnes> pre-GEM, GEM, GEM+GTT, GEM+KMS
<jbarnes> and then of course XAA, EXA and UXA on all of those
<jbarnes> so we've been making our job a lot harder recently to add the features people want
<bryce> DBO, EXA would be my guess, but hard to say
<DBO> it exhibits the behavior on EXA and UXA
<bryce> try XAA
<DBO> I will do that
<jbarnes> also if the memory map dump in the X log doesn't show "X tiled" for your front buffer, perf will be really bad
<DBO> I didn't know XAA was viable for the 4500 series
<bryce> heh, I'd doubt it could be called "viable"
<bryce> but on other hw I've seen scrolling issues go away when EXA->XAA
<bryce> XAA is pretty buggy on -intel (which is why we moved to EXA in the first place)
<bryce> but some like it
<bryce> jbarnes: btw, it seems we still have a scattering of freeze issues.  I don't know if they're different bugs, or instances of the same one.  At least some seem to have cropped up recently (perhaps due to patches added or reverted), but others have been going on a while
<DBO> i wonder if the community could come up with a ppa with the intrepid xorg stack...
<bryce> jbarnes: I'm going to try to get bug reports on freezes organized and tabulated, to see if I can categorize them better
<jbarnes> bryce: I think cworth is hot on the trail of the biggest one, affecting 945
<bryce> jbarnes: meanwhile if you have tips...
<jcristau> DBO: xaa with compositing is fail, so it's not really viable given nobody's willing to fix it
<DBO> jcristau, fair enough
<DBO> when is 2.7.0 due?
<jbarnes> DBO: can I see your X log from when it's slow?
<jbarnes> DBO: supposedly tomorrow, but I'm not sure if we'll make it (still have a couple of blockers open)
<DBO> jbarnes, yeah, I have to boot back over to jaunty to do it first (can't well develop GNOME Do without working X)
<DBO> brb
<bryce> heya RAOF!
<DBO> http://paste2.org/p/181093
<bryce> jbarnes: side question...  I've noticed with newer intel chips, lspci just says "Integrated Graphics Controller" - is there a better way to get the card's name?  (GMA X4500HD, etc.)
<RAOF> Howbie
<DBO> I forgot who it was that wanted my xorg log, but thats it
<DBO> hey RAOF 
<DBO> shhh, I am pretending to be a clueless user like always
<jbarnes> bryce: not sure... lspci gets the name info from the pci ids database
<jbarnes> dunno if a newer one is available with friendlier names
<jbarnes> DBO: hm looks reasonable... you're even getting uxa + dri2
<jbarnes> firefox scrolling is slow?
<DBO> very
<DBO> like if I flick my finger on the trackpad it will scroll for 3 or 4 seconds
<bryce> DBO, do you see this only in firefox, or any other apps?
<DBO> things that have pure text in the scroll box seem to be okay
<DBO> it looks to be related to "complex" content or pixmaps
<bryce> how about inkscape ?
<DBO> a treeview scrolls mostly okay
<DBO> will install
<jbarnes> DBO: can you post dmesg too?
<DBO> one second
<DBO> you want since boot?
<jbarnes> yeah something capturing the boot process
<jbarnes> we've seen badness in the kernel's PAT/mtrr tracking recently
<jbarnes> that definitely slows things down if it's wrong
<DBO> oh the width of the window being scroll has a very definite impact on the performance
<DBO> perhaps its more a function of the overall area
<DBO> jbarnes, http://paste2.org/p/181100
<DBO> sorry for the delay again
<jbarnes> that one doesn't have the early boot stuff
 * jbarnes checks whether that's important
<DBO> erm, I will double check
<DBO> but I think thats all of it
<jbarnes> you could try booting with the 'nopat' option
<DBO> you are right
<jbarnes> also /proc/mtrr
<DBO> jbarnes, /proc/mtrr http://paste2.org/p/181108
<jbarnes> that's with X running?
<DBO> yes
<DBO> jbarnes, http://paste2.org/p/181109 thats a better kernel log
<DBO> jbarnes, still wanting nopat?
<jbarnes> it *might* help
<DBO> i think debian disables PAT by default
<jbarnes> hm
<jbarnes> if that's the case I don't think you're getting write combining anywhere
<jbarnes> since your /proc/mtrr was missing a WC entry for the framebuffer
<jbarnes> and PAT isn't enabled so the kernel may not have done it for you
<DBO> can you restate that in english? :D
<jbarnes> X really wants write combined mappings of the framebuffer or everything gets really slow
<jbarnes> not everything is rendered by the GPU; if X doesn't have write combining for what it does in software (includes a lot of the composite stuff that ff uses) it'll be super slow, every write will be uncached to memory
<DBO> so how do I get WC?
<jbarnes> pre-PAT you need to set up the MTRR regs to cover your graphics aperture
<jbarnes> however if you have PAT, you can do it on a page by page basis
<jbarnes> (when PAT isn't broken that is)
<jbarnes> gimme a few minutes
 * DBO waits patiently =)
<jbarnes> checking libpciaccess & X for the mtrr setting bits
<bryce> http://cateee.net/lkddb/web-lkddb/DRM_I915.html - huh, seems 2e02, 2e12, and 2e22 have the same generic name.
 * bryce needs a decoder ring.  2e22 I think may be G45?
<bryce> G43 and G41 the others maybe?
<jbarnes> heh I'd have to look at the header files
<bryce> ah good call
<jcristau> yeah 2e22 seems to be g45
<bryce> common.h:#define PCI_CHIP_IGD_E_G	0x2E02
<bryce> common.h:#define PCI_CHIP_G45_G		0x2E22
<bryce> common.h:#define PCI_CHIP_Q45_G		0x2E12
<bryce> common.h:#define PCI_CHIP_G41_G		0x2E32
<DBO> jbarnes, any luck?
<jbarnes> DBO: well it looks like the kernel lies about having being able to write combine resources in sysfs w/o PAT
<jbarnes> at least it doesn't go out of its way to make it happen
<jbarnes> I've got a patch to libpciaccess which might help
<DBO> okay
<jbarnes> but only on systems with non-crappy mtrr layouts
<DBO> is mine crappy?
<jbarnes> no looks like it might work on yours
<DBO> sweet
<jbarnes> some systems ship these days assuming XP, which uses PAT
 * DBO starts downloading the libpciaccess source
<jbarnes> so they use all the MTRRs in weird ways
<jbarnes> so PAT really is the right solution for many machines
<jbarnes> but if it's disabled... :)
<DBO> im not sure if it is, I just said that I read debian does that...
<jbarnes> it looks like it's disabled
<DBO> ah
<DBO> is there a boot option to enable it?
<bryce> bug 357908
<ubottu> Launchpad bug 357908 in xserver-xorg-video-intel "[i965] X hang with EXA while scrolling in firefox" [High,Triaged] https://launchpad.net/bugs/357908
<DBO> thank you bryce, your launchpad fu is superior to mine
<jcristau> DBO: heh. i didn't know that.
<jcristau> $ grep X86_PAT /boot/config-2.6.29-1-amd64 
<jcristau> # CONFIG_X86_PAT is not set
<jcristau> indeed seems disabled on debian.
<jbarnes> DBO: not if it's not built in to your kernel
<bryce> DBO: nah just came across that randomly working on other stuff
<DBO> jbarnes / jcristau I am willing to try a patch or a kernel rebuild or both or whatever you think will help
<DBO> I'll sell me soul on ebay and donate the proceeds to the FSF if need be
<jbarnes> DBO: ooh looks like my simple patch might help
<jbarnes> ready to try it?
<DBO> ready
<DBO> got the source downloaded, the coolers are cool, the hot dogs are hot, its hammer time
<jbarnes> mail addr for the patch?
<DBO> jassmith@gmail.com
<DBO> erm, or just paste2.org
<jbarnes> DBO: sent
<DBO> got it, applying
<jbarnes> http://paste2.org:80/p/181137 for the curious
<DBO> building package now
<DBO> had to install some depends
<DBO> do I need to reboot?
<DBO> or just restart X?
<jbarnes> for platforms with crappy mtrr layouts (kernel complains about "no more mtrrs") there's an enable_mtrr_cleanup boot option
<j> DBO: just X
<jbarnes> ugg
<DBO> thank you
<DBO> I will be right back
 * jbarnes types in the wrong text widget
<DBO> need to unload driver modules?
<jbarnes> shouldn't need to
<DBO> meh, I'll do it just in case
<DBO> jbarnes, reg05: base=0x0d0000000 ( 3328MB), size=  256MB, count=1: write-combining
<jbarnes> so far so good
<DBO> i dont see any really improvement though
<DBO> i'll see if I can do a bit of informal testing
<jbarnes> sigh
<jbarnes> bryce: which git commit is DBO running?
<jbarnes> of xf86-video-intel I mean
<DBO> no, its still killing my CPU on scroll
<jbarnes> hm
<DBO> 2:2.6.99.1+git20090402.fad714c4-0ubuntu0tormod2 0
<DBO> so git as of april 2
<jbarnes> still on UXA?
<DBO> yeah
<DBO> in fact thats pretty much the only thing of interest in my xorg.conf
<DBO> thats the only Option
<jbarnes> libdrm 2.4.7 has fixes, as does git after apr 2
<DBO> 2.4.6~git20090403.51d6346f-0ubuntu0tormod2 <--- libdrm
<jbarnes> 6cd914ef315036ce8e91c7b6492994353e8ed2d8 in particular might help
<DBO> I could patch that in if I knew how to get the diff
<jbarnes> ah ok that libdrm should be fine
<bryce> jbarnes: assuming he has stock ubuntu installed, that would be the 2.6.3 release (+patches)
<DBO> i dont, I have xorg edgers ppa installed, that was the first thing I installed
<bryce> oh, nevermind, xorg edgers
<bryce> heh
<DBO> plus I figure its not too useful to you guys if I dont at least try to get pretty close to upstream release
<jbarnes> http://paste2.org:80/p/181147
<DBO> I know I hate when I get bug reports from GNOME Do 0.6 series now
<jbarnes> that might make a big difference
<bryce> DBO: yeah, right thing to do when working with jbarnes
<DBO> making a package with that diff now jbarnes 
<jbarnes> bryce: unless you're a few days behind, that's ancient history to me :)
<DBO> jbarnes, that diff is already in my current version
<jbarnes> ok someone walk me through building a new xf86-video-intel deb
<DBO> I guess the original package maintainer cherry picked it
<jbarnes> DBO: arg
<DBO> where can I get current source for this tree
<DBO> I can build a deb
<jbarnes> git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
<DBO> mmm git
<DBO> git co?
<jbarnes> git clone
<DBO> thank you
 * jbarnes makes room on his desk for the gm45
<DBO> jbarnes, I appreciate you debugging this with me
<jbarnes> DBO: it's a report that keeps coming up
<jbarnes> I'd like to nail it
<DBO> well I'll stay with you until I have to go give this talk tonight
<DBO> and then I'll be back for more
<jbarnes> cool
<DBO> building
<DBO> please excuse if the name of the package is wrong
<DBO> i forgot to rename the date
<DBO> i'll fix that the second time I build it
<DBO> ok let me try that again
<DBO> ah damnit
<DBO> the structure changed somewhere
<jbarnes> np
<jbarnes> I'm updating the gm45 to jaunty now
<DBO> usr/share/xserver-xorg/pci/
<DBO> any idea what goes in there?
<jbarnes> hm no
<jcristau> don't bother with that.
<DBO> k
<DBO> if it no matter, I'll just drop it from the package
<jcristau> (we install there a list of pci ids to help the server choose the right driver when none is configured; that's hopefully going away soon)
<jcristau> DBO: yeah you can do that
<DBO> trying again
<DBO> you must excuse me, my packaging fu is somewhat weak
<DBO> RAOF only taught be enough to slaughter them terribly =P
<bryce> for future reference, here are my notes for building debs of drivers (both for releases and git snapshots):  https://wiki.ubuntu.com/X/DriverBuilding
<DBO> ooh, nice =)
<DBO> wewt
<DBO> it built
<DBO> jbarnes, ok, I have a package, its terrible but it should do the trick
<jcristau> really all you really need is './autogen.sh; make; sudo cp --remove-destination src/.libs/intel_drv.so /usr/lib/xorg/modules/drivers/; sudo killall X' :)
<jcristau> with one less really
<DBO> restarting X
<DBO> brb
<DBO> hehe, somehow i killed composite
<jbarnes> what happened?
<DBO> oh, whitelisted driver check fail
<DBO> i can override that
 * jbarnes wishes he had a faster jaunty mirror to pull from
<DBO> guess not...
<DBO> its using the vesa driver now in xorg...
<DBO> wonder why...
<jbarnes> oh yuck
 * DBO tries to remember how to force intel in xorg.conf
<DBO> Driver "intel"
<DBO> right?
<jbarnes> yeah
<DBO> brb
<DBO> there we go
<DBO> now its working :)
#ubuntu-x 2009-04-10
<DBO> still terrible scrolling :)
<DBO> jbarnes, need anything else from me?
<DBO> can you reproduce it on your system?
<jbarnes> still updating
<jbarnes> what site do you use to test the scrolling?
<DBO> slashdot
<DBO> but its obvious on just about any site
<jbarnes> ok
<DBO> slashdot comment threads after the floating element is forced to reposition is really nasty
<jbarnes> hm ok
<DBO> to be fair about that one though, thats been nasty forever
<DBO> the regression is that even the slashdot homepage doesn't scroll nicely anymore
<jbarnes> it's not super fast on 965 but not horribly slow either (exa though)
<DBO> exa/uxa makes no difference in this case
<DBO> though oddly Docky (uses lots of cairo) is very very smooth, as smooth is intrepid
<DBO> and it has a window as large as a browser
<jbarnes> it's interesting how very specific types of rendering can uncover bugs like that
<DBO> though i have a flash video playing everything slows down a lot more than it used to
<jbarnes> ah I think I see it
<jbarnes> it's slower through a list of collapsed comments
<jbarnes> with the floater on the side
<jbarnes> worse with a composting manager running
<DBO> yeah, but again to be fair thats been there since day 1 i have had this computer, its also present on windows so that bit is probably gecko's fault
<DBO> or maybe not
<jbarnes> still not crazy slow though
<DBO> who knows
<DBO> on a g45 with jaunty?
<jbarnes> no testing 965 while my gm45 updates
<DBO> when you say not crazy slow
<DBO> how many lines of text at a time would you say it skips?
<jbarnes> takes about 2s to do one page up
<jbarnes> page up key that is
<DBO> thats not crazy slow in your world? =P
<DBO> i would try playing music and then scrolling up and down with the mouse wheel
<jbarnes> well not 3-4 that would be twice as slow :)
<DBO> see if you can get the music to skip
<jbarnes> but no it's bad just not as bad as I thought
<DBO> mine takes about 3s
<DBO> just timed it =/
<jbarnes> yeah it sucks up a bunch of cpu
<jbarnes> hm now does sysprof work on this machine?
<DBO> mine or yours?
<jbarnes> either :)
<DBO> installing
<jbarnes> looks like it ought to take a little less than a second/scroll
<DBO> ok its working
<jbarnes> 945 has this problem too
<jbarnes> oh cool you can collect a profile then
<jbarnes> with debug symbols
<DBO> just scroll up and down?
<DBO> debug symbols on what?
<jbarnes> on X, xf86-video-intel, kernel & libdrm
<DBO> ah yeah probably not right now, I'd have to install a LOT of stuff...
<jbarnes> I'm trying now on my 945 which is even slower to scroll
<DBO> alright, presentation time
<DBO> I'll come back and bother you later jbarnes, thanks for the help
<jbarnes> sure
<jbarnes> thank you
<bryce> man, some day I'm going to write a cron job to check X bugs for the word "randomly" and mark them invalid.
<jcristau> lol
 * bryce waves to cwillu
<cwillu> poke poke
<jbarnes> if DBO comes back... I updated fdo bug 18572 with the profile I captured
<ubottu> Launchpad bug 18572 in gnome-applets "modem_applet: waitpid()'s return value causes wedging." [Medium,Triaged] https://launchpad.net/bugs/18572
<cwillu> I must be getting popular or something:  bryce waves, bugabundu blew me a kiss, and ubottu just told me that I'm also a bot (written in php)
<bryce> :-)
 * cwillu resolves to invent random tags and apply them to random bugs more often :p
<cwillu> 945 under uxa, black screen on resume from hibernate:  ssh'ing in, killing compiz.real and rerunning compiz restores the session (oddly, nothing less than that)
<bryce> mm
 * cwillu deletes out the gibberish he typed in his editor while the screen was blanked :p
<bryce> I've been ignoring UXA bugs so far.  At some point those are going to need deeper attention
<bryce> I've been working on exa freezes all day today
<cwillu> my 945 is due for some punishment if you want me to try anything
<bryce> presently, I'm just trying to build a table of all the different freezes that have been reported
<bryce> https://wiki.ubuntu.com/X/Bugs/IntelDriver
<bryce> just to get some sort of framework in place to discern any patterns
<cwillu> bugs I have listed as hangs that aren't on your list:  340652, 347527, 316423, 259385, 304871 (fixed I believe), 343690 (also fixed), 340964, 328918, 322613, 320821, 337243, 312776 (intrepid)
 * cwillu starts opening lots of launchpad tabs to check for dups :p
<cwillu> mind if I sort that table on the bug number?
<bryce> lemme save
<bryce> sure, I'm about to head off to dinner in a few minutes anyway, so feel free to add to the table
<bryce> saved.
<cwillu> k
<bryce> i've also been doing s/hang/freeze/ and s/lockup/freeze/ to make them consistent
<bryce> and removing that damn "randomly" word whenever I spot it ;-)
<cwillu> heh
<cwillu> I'd suggest "indeterminately", but I'm guessing you wouldn't appreciate it
<bryce> the best are, "Freezes when compiz enabled... and with compiz disabled"
<cwillu> you have 327844 listed twice, is that desired?
<cwillu> || 327844 || G45  || 2009-02-10 || Frequent  || Turn compiz on      || Disable compiz || ||
<cwillu> || 327844 || G45  || 2009-02-10 || Rare      || Video playback      || || ||
 * cwillu pings bryce 
<bryce> yep
<bryce> I did that because in the bug they mention two different scenarios where freezes occur
<bryce> (ideally we'd handle those as separate bug reports)
<bryce> heh, that bug is exactly the one I was thinking about with my "best" comment ;-)
<cwillu> heh
<bryce> btw, save frequently
<cwillu> yep
<cwillu> if only we had some collaborative system for managing bugs p
<bryce> I made the mistake of not doing so, and firefox crashed when I was half-way through, and had to start all over again :-(
<bryce> agreed
<cwillu> session restore includes form fields though
<bryce> didn't work for me
<cwillu> :/
<bryce> I really want to have some launchpad-like list report that allows filtering by tag
<cwillu> oh, check browser.sessionstore.privacy_level
<bryce> it's set to '1' for me
<cwillu> which means that it doesn't hold data for https sites
<cwillu> http://kb.mozillazine.org/Browser.sessionstore.privacy_level
 * bryce sets to 0
<bryce> thanks!
<bryce> mm, I think on my laptop I'll leave that to 1 ;-)
<cwillu> http://kb.mozillazine.org/Browser.sessionstore.postdata might also need a tweaking if you change it from 1
<bryce> it's set to 0
<bryce> I'm thinking that may be what I want.  guess I can play with it
<cwillu> and also, openoffice is a crashy flacky unreliable piece of crap
 * cwillu feels an urge to murder something at least once a day due to openoffice calc
<bryce> heh
<cwillu> the waitlpring table is currently crashing calc
<cwillu> like, seriosuly
<bryce> you trying to edit that IntelDriver page in calc?
<cwillu> no, just messing with the tables to cross-check against my list
<cwillu> normally copy/paste of an html table works fine
<cwillu> I do my heaving lifting in gedit :p
<bryce> wow, I don't even trust gedit
<bryce> I don't really trust any editor without autosave
<bryce> btw 327844 now says was solved with 2.6.3-0ubuntu9
<cwillu> I have a ctrl-s reflex burned into my left hand ever since I was 12 years old and watched 3 days of work on a game I was writing go up in a puff of crashing-the-ide
 * cwillu reminisces of gfa-basic
<cwillu> that's the 'disable dri on everything' patch?
<cwillu> did you want intrepid bugs in that table?
<cwillu> (re: gedit, I also wrote my own autosave/restore session plugin for it, among other things)
<bryce> nice
<bryce> uh, intrepid bugs are okay if they are believed to still affect jaunty
<bryce> if they're not occurring in jaunty, shouldn't be in the list
<cwillu> k, I'm just going to drop them for now then
<bryce> 0ubuntu9 was a crash in drm_intel_bo_unpin that occurred after watching videos, relating to DPMS
<cwillu> okay
<bryce> alright, wife says we're late for dinner, gotta go.  back in a few hours
<cwillu> ttyl
<DBO> im back jbarnes 
<DBO> did anything fun get discovered?
<cwillu> I was discovered hiding behind a rock
<cwillu> whether I'm fun is still to be determined though
<DBO> i hope by that you mean you know fun things about g45 and X
<cwillu> that would be "still to be determined)
<DBO> ah
<DBO> can you tell me whats been going on (if its not much trouble)
<cwillu> exa or uxa?
<DBO> either or
<DBO> I just want to know whats going on with the scrolling performance issue
 * cwillu doesn't have a performance issue on his buglist for that
<cwillu> bug number?
<cwillu> I know of 339233, 339781, 338681, as corruption issues, and 327844 as hang/crashers on that chipset
<DBO> mmm I think it was mentioned at some point...
<cwillu> <jbarnes> if DBO comes back... I updated fdo bug 18572 with the profile I captured
<ubottu> Launchpad bug 18572 in gnome-applets "modem_applet: waitpid()'s return value causes wedging." [Medium,Triaged] https://launchpad.net/bugs/18572
<cwillu> just saw that in the scrollback
<cwillu> nothing else since I rejoined an hour ago
<DBO> okay
<DBO> thank you cwillu 
<DBO> i was in the middle of preaching the church of GNOME Do to the freshmen choir at WMU
<cwillu> bryce, resorted on bug number (which probably isn't helpful to anyone else but me right now :p), and added dates and triggers where I can find them
<cwillu> I can't bring myself to use gnome-do
<cwillu> I have it installed, I fire it up once a month or so, but it just feels like it slows me down
<DBO> cwillu, its not everyones cup of tea
<DBO> cwillu, i dont care if anyone at all uses it to be honest
<DBO> I hack it for me and me only
<cwillu> some evangelical you are
<DBO> i was being graded
 * cwillu is away again for a couple hours
<cwillu> poke
<bryce> back
<bryce> ended up having to upgrade mom's computer
<bryce> heya tseliot
<tseliot> hi bryce
<bryce> tseliot: hey, if no Virtual is set in the xorg.conf, does it take the largest dimension of the outputs attached at boot, or does it use the maximum allowed by the video card (2048x2048 or whatever)?
<tseliot> bryce: the latter
<tseliot> if you're referring to the Gnome capplet
<bryce> no, just in general by default, before the capplet comes into play
<bryce> > Version 2.1.1-0ubuntu2 seems to set the default Virtual size (maximum 
<bryce> > screen size) to 1920 x 1920, if there is no entry in xorg.conf. I take 
<bryce> > it the maximum screen size for the i915 chipset family is 2048 x 2048, 
<bryce> > so why not have it at that? This would make dualscreen setups a bit easier.
<bryce>   The default settings is found by taking the largest resolution in either 
<bryce> x or y dimension and making a square from that. This allows for easy 
<bryce> rotation should you want to do so.
<bryce>  
<bryce> I'm wondering if that is accurate anymore
<tseliot> it says 2048x2048 on my laptop, even when no other output is plugged in
<tseliot> (other than LVDS)
<bryce> $ DISPLAY=:0 xrandr
<bryce> Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
<tseliot> aah, it's version 2.1.1
<bryce> $ apt-cache policy xserver-xorg-video-intel
<bryce> xserver-xorg-video-intel:
<bryce>   Installed: 2:2.6.3-0ubuntu2
<tseliot> does it use UXA?
<bryce> no
<bryce> it has dontzap set, and everything else is default
<bryce> this is an i965
<tseliot> let me check what my eeepc says
<tseliot> is that framebuffer size available when you boot with only 1 output (i.e. with no external screens)?
<bryce> correct
<tseliot> my eeepc (running intrepid) says 1024x1024
<tseliot> hmm
<tseliot> on jaunty, with my laptop and UXA I get 2048x2048, let me try with EXA
<tseliot> it says 1280x1280 with EXA and 2048x2048 with UXA
<tseliot> but it's not a matter of framebuffer reallocation since that's the framebuffer which is allocated when X starts
<tseliot> bryce: maybe we should have a look at the UXA code?
<bryce> UXA has better memory management behind it, so perhaps that allows it to use larger default virtual
<bryce> with EXA, the memory usage is probably more of an issue, thus they don't go to the hardware maximum.
<tseliot> it can be
<tseliot> bryce: BTW it looks like X-Kit and dontzap ended up in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=494517 https://bugzilla.redhat.com/show_bug.cgi?id=494518
<ubottu> bugzilla.redhat.com bug 494517 in Package Review "Review Request: python-xkit - A simple, transparent and easy to extend xorg parser" [Medium,Assigned]
<bryce> sweet, congrats!
<tseliot> :-)
<bryce> now that's funny
<tseliot> ?
<bryce> we should remember this for the next time they say "Ubuntu never contributes upstream!!1!"
<tseliot> hehe
<bryce> http://who-t.blogspot.com/2009/04/zapping-server.html
<tseliot> yes but we already have a UI in Kubuntu ;)
<tseliot> of course that patch is another thing
<bryce> I find the whole situation rather amusing
<tseliot> it definitely is
<tseliot> tjaalton, jcristau: any ideas as to where libdrm-intel1 gets the dependency on "libdrm2 (>= 2.4.1)" from?
<jcristau> tseliot: dpkg-shlibdeps
<jcristau> tseliot: why?
<tseliot> jcristau: I would like to make it depend on >= 2.3.0 so that psb can replace libdrm
<tseliot> as we'll have 2 versions of libdrm
<jcristau> uh
<jcristau> not going to happen
<tseliot> I know, it's ugly
<tseliot> but it's not something that we'll do in Ubuntu
<tseliot> just for our customised installations
<tseliot> jcristau: I'm using dh_makeshlibs -plibdrm2 -V'libdrm2 (>= 2.3.0) | libdrm-poulsbo1 (>= 2.3.0)' -- -c4
<tseliot> in debian/rules
<jcristau> that's utterly wrong...
<tseliot> jcristau: care to explain?
<tseliot> apart from the ugliness of having libdrm-poulsbo1...
<jcristau> also if you have a libdrm2.symbols files that won't work anyway
<tseliot> yes, I have that file
<jcristau> tseliot: it's wrong because if something needs libdrm 2.4.1, making it depend on 2.3.0 is just asking for breakage
<tseliot> jcristau: this will not happen in Ubuntu but only in OEM installations
<tseliot> where -psb is the only thing you can use
<jcristau> *shrug*
<tseliot> yes, I know...
<tseliot> jcristau: thanks for your help, that worked
 * bryce hugs tseliot
<bryce> sooo glad someone else is looking at -psb stuff :-)
<tseliot> bryce: yes, it's my job
<tseliot> ;)
<bryce> \o/
<tseliot> but we can share the pain if you miss -psb :-P
<bryce> heck no!
<tseliot> hehe
<bryce> btw, volunteered you for something ;-)
<tseliot> for what?
<bryce> jane silber asked for a laptop/projector testing thingee
<tseliot> oh
<tseliot> I get it
<tseliot> hehe
<tseliot> such as?
<bryce> I suggested maybe a better idea would be if I and you gave a short presentation on "projector tips and tricks with ubuntu"
<tseliot> at AllHands?
<tseliot> or using the wiki?
<bryce> yep.  I figure it would be just to demo Screen Resolution, explain about ~/.config/monitors.xml, and how to work around problems
<tseliot> yep to which one?
<tseliot> the former?
<tseliot> i.e. AllHands/UDS
<bryce> at AllHands
<tseliot> ok
<tseliot> sure
<tseliot> it should be pretty easy to do
<bryce> yeah, that's what I figure
<bryce> also, I told her to limit presenters-with-computers to Intel 915 and newer, or ATI (-ati)
<bryce> well, I just cc'd you the email, you can see what I said :-)
<tseliot> yes, right
<tseliot> I've just received it
<tseliot> I don't own an Nvidia card (in a laptop) but if someone has an Nvidia card I could give a brief presentation on that too
<tseliot> with nvidia-settings though
<bryce> nice, yes that'd be good
<tseliot> good, let's gather some ideas for the presentation then
<tseliot> maybe we should cover only clone mode 
<tseliot> which is what you use with projectors
<bryce> yep
<bryce> I also like the idea of pre-setting your Virtual to 2048x2048
<bryce> (which we discussed earlier)
<tseliot> in the driver or in xorg.conf?
<bryce> xorg.conf
<tseliot> shall we set up a wiki page about it?
<tseliot> so that we can add ideas as they come to our minds
<bryce> yes, that's a very good idea
<bryce> whoa...  can you start it?  I just noticed it's 3:45am, I need to get to bed.
<tseliot> sure, as soon as I find a decent name for it
<tseliot> yes, it's pretty late there
<tseliot> try to get some sleep
<bryce> :-)
<bryce> cya tomorrow
<tseliot> night bryce
<jbarnes> bryce: any thoughts about bug 282081?
<ubottu> Launchpad bug 282081 in xserver-xorg-video-intel "[i965] X freezes after screen saving or logout/login on Dell Hybrid Studio" [Unknown,Confirmed] https://launchpad.net/bugs/282081
<jbarnes> it's been idle since january and is against a pretty old driver...
 * jbarnes would like to close it
<cwillu> bug #275809
<ubottu> Launchpad bug 275809 in xserver-xorg-video-intel "[GM965] X freezes when logging in from screensaver - fails in intelSwapBuffers()/ intelCopyBuffers()" [High,Won't fix] https://launchpad.net/bugs/275809
<cwillu> bug #316414
<ubottu> Launchpad bug 316414 in xserver-xorg-video-intel "[i965] X freezes at least once a day after leaving screensavers or fullscreen video" [Undecided,Confirmed] https://launchpad.net/bugs/316414
<cwillu> (ignore that one)
<jbarnes> those sound like vblank related hangs... should be fixed in recent (2.6.28+ iirc?) kernels and libdrm
<cwillu> jbarnes, may find dupes on https://wiki.ubuntu.com/X/Bugs/IntelDriver
<jbarnes> but #357908
 * jbarnes wonders where ubottu got off to
<jbarnes> bug #357908
<ubottu> Launchpad bug 357908 in xserver-xorg-video-intel "[i965] X freezes every ~24hr while scrolling in firefox (EXA enabled)" [High,Triaged] https://launchpad.net/bugs/357908
<jbarnes> heh
<cwillu> jbarnes, launchpad's fault usually, ubottu doesn't have a special link that works any better than ours :p
<cwillu> !botsnack
<ubottu> Yum! Err, I mean, APT!
<jbarnes> helps when I spell 'bug' right too :)
<jbarnes> bug #331596
<ubottu> Launchpad bug 331596 in xserver-xorg-video-intel "[i965] X freezes when TripleBuffer On after resume" [Undecided,Incomplete] https://launchpad.net/bugs/331596
<jbarnes> fyi the old triplebuffer & page flipping implementations are horribly buggy
<jbarnes> and will likely cause corruption and/or hangs after awhile
<cwillu> so that's a won't fix then?
<jbarnes> yeah
<jbarnes> they've been removed in later versions
<jbarnes> (I'm working on adding them back in though)
<cwillu> bah, I can't mark won't fix yet :p
<jbarnes> fdo bug 20664 is the rfe for adding it back in
<ubottu> Launchpad bug 20664 in mozilla-thunderbird "Doesn't work right with Gnome "preferred applications"" [Medium,Fix released] https://launchpad.net/bugs/20664
<cwillu> freedesktop 20664?
<ubottu> Freedesktop bug 20664 in Driver/intel "implement vblank sync'd GL buffer swap" [Enhancement,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20664
<cwillu> hugs
<jbarnes> yeah ubottu should know fdo is shorthand for freedesktop.org :)
<jbarnes> bug #316240
<ubottu> Launchpad bug 316240 in xserver-xorg-video-intel "[iG33] X freezes about a second after running "strace glxgears"" [Undecided,Confirmed] https://launchpad.net/bugs/316240
<jbarnes> bug #327844
<ubottu> Launchpad bug 327844 in xserver-xorg-video-intel "[G45] X freezes about 1-5 min after switching compiz on" [High,Triaged] https://launchpad.net/bugs/327844
<tjaalton> jbarnes: going to be an exceptionally Good Friday?-) (bugwise)
<jbarnes> tjaalton: heh I hope so
<tjaalton> and isn't it a holiday for you too?
<jbarnes> nope
<tjaalton> ah, ok then
<tjaalton> I'm ok with closing the bug, but I guess bryce will be here before too long
<tjaalton> I've got a thinkpad X61 with 965, so if there are any bugs that need confirming being fixed or still there, just shout
<jbarnes> great
<tjaalton> although I'm behind 3G, so pulling stuff will take awhile
<cwillu> bryce, wonder if that's something we could use, a good directory of willing and responsive testers with any given chipset?
 * cwillu volunteers for 945gm and 815 :p
<tjaalton> yay, 5,5kb/s
<bryce> heya
<bryce> 282081 --> expired (thanks jbarnes)
<bryce> 331596 --> wishlist 
<bryce> cwillu: there is a hardware database, so if we were really desperate to find testers with given hardware, we could use that.  however I've never done it before
<bryce> there is also https://wiki.ubuntu.com/X/SwatTeam with a list of hw available for testing
<bryce> kinda out of date though
#ubuntu-x 2009-04-11
<bryce> I've fleshed out https://wiki.ubuntu.com/X/Bugs/IntelDriver a bit more
<tseliot> I've added another I830WaitLpRing() bug to the wiki
<bryce> it'd be nice to update that LpRing table to remove the fixed bugs
 * bryce reorders by chip id
<cwillu> 22741 is a dupe of 28326
<cwillu> which is odd, seeing as it's not the same chip?
<cwillu> oh, nvm, just notice the other line
<bryce> let's try sorting by symptom...
<bryce> there we go
<bryce> hmm
<bryce> well maybe that'll give some ideas on further triaging...  bugs with similar symptoms should test each other's workarounds and steps to reproduce
<bryce> hah, I've reproduced the freeze on i965
<bryce> heya RAOF
<RAOF> Howdie bryce.
<RAOF> What's up?
<bryce> ah, well I was finally able to reproduce that i965 freeze bug that's been going around
<bryce> I'm poking around collecting any data that looks interesting
<bryce> not finding strong clues, but am finding some "interesting evidence"
<RAOF> I think I'll rebuild a kernel with the MMIO tracer enabled, and provide someone with a log of the suspend/resume cycle with the nvidia driver.
<andresmujica> ping bryce
<bryce> andresmujica: just ask
<bryce> tjaalton: mesa 7.4 brought a freeze regression.  Downgraded to 7.3 and it seems to have gone away.
<superm1> bryce, it also brought a regression in myth causing segfaults
<superm1> i've been bisecting all day to find the commit
<superm1> (bug 355242)
<ubottu> Launchpad bug 355242 in mesa "mythfrontend.real crashed with SIGSEGV in QGLWidget::resizeEvent()" [Undecided,Confirmed] https://launchpad.net/bugs/355242
<bryce> superm1: aha, yeah I wondered if that could be the case, I saw that bug too
<bryce> superm1: in looking through the mesa 7.4 changelog, it seems the majority of the changes for -intel were for DRI2 issues, we probably don't care so much about
<superm1> bryce, i dont know what drivers are affected, but i'm able to reproduce it with vesa, so virtualbox has been my friend
<bryce> hmm
<bryce> yeah I can't tell from the bug report whether it's driver-specific or in the genera mesa code
<superm1> well i'm down to like 2 commits left, so i should know soon enough
<andresmujica> hi bryce, i just was going to ask about the freeze 
<superm1> just annoying that it takes like 25min to do mesa builds
<andresmujica> it's only related to x?  mesa and dri? 
<andresmujica> or is kernel involved too?
<bryce> hrm, seems this mesa 7.4 upgrade is kind of poor quality, if we've already found two serious regressions with it
<bryce> superm1: I also looked in the mailing list for recent discussions of regressions but didn't see anything obvious, maybe the problems are some weird conflict with this mesa and ubuntu-specific kernel/xserver junk
<bryce> hopefully timo can weigh in
<bryce> andresmujica: heya, thanks for looking at the freeze bugs :-)
<andresmujica> hehe
<bryce> andresmujica: from what I suspect, there is definitely one freeze bug, which I believe started with the mesa 7.4 upgrade on 4/3, which only affects i965
<andresmujica> yeap, i'm reading about them..
<andresmujica> ok.
<bryce> andresmujica: however there are also plenty of other freeze bugs that still exist
<andresmujica> gonna test it here downgrading
<andresmujica> yeap
<andresmujica> that's what i've noticed..
<bryce> andresmujica: so we have to distinguish between them
<andresmujica> which factor are u using to distinguish them?
<bryce> they're really, really hard to debug though - no error messages, and all have identical symptoms, and a lot seem to come on randomly
<bryce> so far, the most useful thing is if you can pin it to a particular date when it started happening, and from that discern which package changed at that time, that brought the freeze into existence
<bryce> unfortunately, when people first noticed after upgrading from intrepid -> jaunty, the number of changes is too great to sort through, so that's kind of a shame
<bryce> anyway, what you've been posting to the bugs is exactly the right info and questions to present to reporters, so keep it up, hopefully that can get us better knowledge for what to do with the bugs.
<andresmujica> ok. perfect then!
<bryce> if you get answers that show that they're freezes in -intel that still exist in jaunty, please add them to that table so we can keep track of them for later
<andresmujica> ok
<bryce> ok, wife is kicking me out in the shop to get some house projects done... bbiaw
<superm1> well git bisect claims fe5328bfad063f2ccbcafa2cebe6971d7e8e1db7 is first bad commit
<superm1> i'll do a test build with just that commit reverted to check tho
<superm1> well that would have been wishful thinking i guess.  there must be some more (possibly related) commits that are also a factor
#ubuntu-x 2009-04-12
<superm1> oh i should look at what i was reverting ;) it was a comment.  so it must be a commit near there then, and the comment threw bisect off
<tjaalton> bryce: assign me to the bugs, and I'll have a look
<tjaalton> it's really unfortunate that these regressions happened, but maybe the 7.4 branch has fixes for them already
<tjaalton> s/me to the bugs/the bugs to me/
<tjaalton> I'll make sure upstream knows about these if they're not fixed already
<tjaalton> it's high on my list since  i've been so vocal to follow upstream on this :)
<bryce> tjaalton: 359392 is the master bug for this
<bryce> tjaalton: other possibly related bugs are at https://wiki.ubuntu.com/X/Bugs/IntelDriver
<bryce> notice all the i965-specific freezes starting from early april
<tjaalton> ok, I'll hunt them once I get back home
<bryce> d805c820: fix potential recursive locking deadlock in _mesa_HashWalk() maybe?
<bryce> thanks, we're heading out for easter brunch.  bbiab
<knome> hello.
<tjaalton> yeah if it's 965 related I should be able to reproduce and test potential fixes
<knome> on hardware drivers, nvidia-180 says first that another version of the driver is in use
<knome> and when i activate it, it says that it is disabled, but still in use
<knome> what can i do to activate it?
<tjaalton> knome: upgraded from intrepid?
<knome> tjaalton, yes.
<tjaalton> so is 180 installed now?
<knome> it is
<tjaalton> is it used? (look at the logfile)
<knome> which logfile?
<tjaalton> Xorg.0.log
<tjaalton> dmesg should tell as well
<superm1> checking dpkg -l | grep nvidia would probably be useful too to make sure none of the 177 bits are still installed
<knome> tjaalton, LoadModule: "nvidia"
<knome> superm1, there is even some 96-bits
<tjaalton> knome: the version string would tell which version is used
<knome> tjaalton, 180.44
<knome> after boot jockey insists that 180 isn't used.
<knome> and can't activate
<tjaalton> so it's lying
<knome> supposedly
<knome> 3d is working fine, though.
<knome> just wondering
<tjaalton> dunno why
<knome> should i file a bug?
<tjaalton> not sure
<tjaalton> maybe :s
<tjaalton> s/s/)/
<knome> which files should i include?
<knome> and against which package?
<tjaalton> use ubuntu-bug
<tjaalton> jockey I suppose
<knome> filed bug #360161
<ubottu> Launchpad bug 360161 in jockey "Jockey can't activate a driver even if Xorg.0.log tells it used" [Undecided,New] https://launchpad.net/bugs/360161
<knome> my screen also goes partly black now and then
<knome> eg. if browsing web with firefox, part of the window background might become black.
<knome> is this known?
<knome> there is no exact steps to reproduce.
<knome> this *might* have something to do with my gtk theme, but i'm very sceptical about that.
<tjaalton> haven't seen it myself
<knome> right
<knome> i'll try to get a screenshot of it once it happens again
<knome> or a photograph
<andresmujica> bryce: please check bug #360193, i was able to reproduce the freeze using mesa 7.3 and the application alarm-clock
<ubottu> Launchpad bug 360193 in ubuntu "x server freezes consistently" [Undecided,New] https://launchpad.net/bugs/360193
<bryce> andresmujica: interesting.  My gut suggests it may be a separate freeze issue
<bryce> after all, we already have about 20 known freezes before we even got to april 3rd.  ;-)
<bryce> from what I've gathered, the april-3rd freeze is not triggerable by a specific user action, it just comes on "randomly" (gods I hate that term!)
<bryce> which is why my gut thinks that freezes that are reproducible easily with a specific application, and that aren't resolved by going 7.4->7.3, really sound like a separate issue
<andresmujica> hi bryce
<andresmujica> well
<andresmujica> i'm testing a lot
<bryce> good! :-)
<bryce> yeah I will try reproducing on my laptop too
<andresmujica> and found 2 freeze actions
<andresmujica> and 1 "natural" freeze with mesa 7.3
<andresmujica> sudo apt-get install alarm-clock
<andresmujica> and then start alarm-clock
<bryce> oh, also keep in mind there are issues that 7.4 actually fixes, it's not all just new bugs ;-)
<andresmujica> your laptop is frozen
<andresmujica> ssh from a remote machine and kill the alarm-clock 
<bryce> ok
<andresmujica> and get your system back
<bryce> hmm
<andresmujica> aslo with strace gcalctool or strace firefox
<bryce> ok that sounds like a very different issue, that's not a classic X freeze
<andresmujica> yeap
<andresmujica> i believe a focus thing
<bryce> if you can freeze on strace glxinfo, there's a known bug on that
<andresmujica> i' m waiting to get another "natural" freeze to kill app per app
<bryce> cool
<bryce> ok, switching computers
<andresmujica> hmm nop freeze with strace glxinfo
<andresmujica1> just got the freeze again, and effectively is not the same as the alarm-clock one, as i cannot recover the system by killing apps... 
<andresmujica1> the bad thing is i'm using mesa 7.3 
<andresmujica1> and xserver-xorg-core/xserver-common 1.6.0-0ubuntu1
#ubuntu-x 2010-04-12
<Sarvatt> Ng: can ya attach your Xorg.0.log too? since i'm using your info for the report and it doesn't match the other guys
<Ng> sure
<Ng> I'll attach .old since that should match up with the drm_debug=0x01 boot
<Sarvatt> okie Ng, https://bugs.freedesktop.org/show_bug.cgi?id=27589 if you wouldn't mind subscribing incase they ask for more info :)
<ubottu> Freedesktop bug 27589 in Driver/intel "[GM45] Occasional flickering unless powersave=0 is used on lenovo laptops." [Normal,New]
<Ng> Sarvatt: cool thanks, subscribing now
<Sarvatt> well its linked now so it'll show up in the launchpad bug, forgot about that :D
<DanaG> hmm, has the version of nouveau planned for Lucid been locked down?  I'm having this issue, which I'd call a release-blocker for some hardware:
<DanaG> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/547124
<ubottu> Launchpad bug 547124 in xserver-xorg-video-nouveau "Starts in low graphic mode due to segmentation fault at 0xc4" [High,Confirmed]
<DanaG> I've added a backtrace with debug symbols.
<DanaG> ah, looks like it's already being commented on. cool.
<RAOF> DanaG: Yeah.  Can you try edgers?  There's a libdrm commit that looks jucily like a fix for that.
<DanaG> Yup, already tested it, in fact -- works fine in Edgers (as long as you keep the userspace and kernel components matching).
<RAOF> Right.
<RAOF> That, of course, being the big (Linus-fire-breathing) trick.
<DanaG> hmm, I can try fetching source with that package, depending on how long it'll take to build that myself.
<DanaG> ah, just libdrm... cool.
<RAOF> If it works fine in edgers that's all I really need to know.
<DanaG> heh, nv17 is a card that never should have existed.
<DanaG> It's absolute bollocks that they replaced the geforce3 with a "4 mx" that's really not even a geforce3.
<RAOF> That's your GeForce â4â MX, right?
<DanaG> Yeah.
 * RAOF had one of those, too.
<DanaG> I mean, even cutting down a geforce 3, I can understand.... but to skip back two generations? Fail.
<DanaG> If ATI did the same, the 9200 would be a souped-up Radeon 7500, not a tweaked Radeon 8500. =Ã¾
<DanaG> no, it would be a 7000.
<DanaG> Cool, rebuilt libdrm... works great with that patch.
<DanaG> er
<DanaG> lemme double-check.
<DanaG> gdm seems to be doing something funky.
<DanaG> yup, it works.  Had to reboot to un-failsafe it.
<RAOF> Sweet.
<DanaG> And now that I'm not on edgers, it's not offering 3D -- which is a good thing, since nv17 3D is just a "bag of hurt".
<DanaG> hmm, is there a slightly-less-"edgy" xorg-edgers that has the nouveau that would go with 2.6.34 kernel?
<DanaG> great... the display-switch hotkey on this laptop forcibly goes behind the OS's back and does god-only-knows what, and royally breaks the video output.
<DanaG> on the old Toshiba, ubuntu netbook would be far nicer than winxp... if not for toshiba's stupidity (that needs a driver that's only in 34 kernel).
<RAOF> DanaG: edgers, with /usr/lib/xorg/extensions/nouveau_vieuex.so deleted?
<DanaG> Or rather, dpkg-diverted.
<RAOF> Yah,
<DanaG> My brother was wanting me to set the thing up (it's his old laptop) for my grandmother (who lives way across the country).
<DanaG> Or maybe just build the new toshiba-acpi out-of-tree.
 * DanaG gives up and sticks XP on the thing... and will be glad to be rid of it.
<DanaG> Too much stuff broken by the combination of nvidia + toshiba.
<RAOF> :/
<DanaG> I can't, in good conscience, set up Ubuntu on this old Toshiba, for somebody who lives way across the country. Especially with things as bad as the "I hit two keys and the screen died" sort of stuff.
<DanaG> And as a bonus, I can stop griping about the nvidia thing... since it won't be in my hands anymore. =Ã¾
<RAOF> That laptop's can't be your gforce2mx, though.
<DanaG> no, I mean, the toshiba IS the one with the MX.
<RAOF> At what point did some madman want to stick a gforce 2 mx into a laptop.
<RAOF> That ain't no laptop card!
<DanaG> And some madman also used not only a P4, or a Celeron, but both -- P4-based Celeron!
<DanaG> Ew.
<DanaG> If P4 == crap and Celeron == crap, then that thing == crapÂ².
<bjsnider> DanaG, are you now absolving nvidia of any blame for your crappy laptop?
<DanaG> Actually, it's my brother's.
<DanaG> I would never have chosen something that sucky. =Ã¾
<DanaG> In this case, Toshiba is the one to blame.  They even managed to screw up the EDID, so it claims to be 969x768.
<bjsnider> it is not nvidia's fault that they spend 30 seconds a year working on the 96 driver?
<DanaG> That's not what I meant.  Toshiba were just the ones to choose the stuff to go into the laptop... and they chose badly.
<DanaG> Anyway, that's all way off-topic, anyway.  Oops, I just said "Anyway" twice -- or now it's 3 times.
<ripps> Hmm... just booted into new -20 lucid kernel. Xorg seems to be higher than usual, but I'm not experiencing any performance loss with my browser and pulse. Guess jus wait and see if the usual lag shows up.
<ripps> There it goes
<ripps> uptime 25 min
<ripps> this makes no sense, what happens at ~25 minutes that could be causing this lag
<ripps> Everytime I move something, either changing window in screen or moving something with my mouse, I get a serious amount of lagging and stutter. Everything visual and audio become choppy...
<Sarvatt> it go away if you switch to a vt and back?
<ripps> Sarvatt: nope
<ripps> killing gnome-session or otherwise restarting Xorg fixes things; for another half hour
<ripps> Xorg ~20% normally, around ~10% in VT. Not much audio lagging there.
<RAOF> A mem-leak which takes about 25 minutes to make you hit swap?
<RAOF> Something triggers gnome-settings-daemon to probe the xrandr properties crazily?
<ripps> whoa, killing gnome-settings-daemon made Xorg jump to ~75%. Massive slowdown, than back down to normally laggy ~20%
<ripps> According to top, Xorg is only using 3.8% memory, is that enough to hit swap?
<ripps> Of course, this might have nothing to do with Xorg, it's just a victim here.
<RAOF> What's actually happening when everything goes pear-shaped?  Is there a high memory load, or high CPU usage, orâ¦?
<ripps> RAOF: I've been trying to figure it out, but I can't find any sortof trigger besides ~25 minutes, and either nautilus or a browser open. If I'm not using the computer and just have Transmission and evolution open, it doesn't seem to hit lag zone.
<ripps> But I can just be scrolling down a page in chrome and at around ~25 minutes, lag zone hits. I get this in 2.6.33 mainline as well, but it only happens for a minute before it seems to recover and behave normally.
<RAOF> And what are the symptoms other than âit seems to get laggyâ?  Is there an unusual memory load?  Unusual CPU load?
<ripps> RAOF: the only thing I can notice is that Xorg's cpu usage tends to be a bit higher. There doesn't seem to be an abnormal amount of swap being used according to free -m (in fact, it says only 39mb is being used by swap now)
<RAOF> So the CPU usage isn't 100%?  Load average is reasonable?
<RAOF> Let's get some logs!  Xorg.0.log and dmesg.
<RAOF> One of those might provide something to bite into.
<ripps> RAOF: I've been checking all the logs in /var/log. I'm not finding anything useful.
<ripps> I'll pastebin them if you want
<RAOF> They'll be better than nothing.
<ripps> Xorg.0.log: http://pastebin.com/3sDYpmZ5
<ripps> dmesg: http://pastebin.com/3sDYpmZ5
<ripps> correction, dmesg: http://pastebin.com/gCfekW1m
<ripps> messages: http://pastebin.com/WqKAFCvC
<Sarvatt> darnit, guess I can't use chromium anymore at all, my system starts going swap crazy after a few hours no matter what versions of everything i'm using.. my gem_objects are rediculious using chromium, 3k objects using 1.2GB after 2 hours uptime..
<Sarvatt> [21157.585651] Out of memory: kill process 19759 (chromium-browse) score 2358912 or a child
<Sarvatt> [21157.585663] Killed process 19759 (chromium-browse)
<Sarvatt> [21209.492436] pulseaudio invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
<ripps> debug: http://pastebin.com/s3e3dvTH
<ripps> Sarvatt: do you see that with google-chrome-unstable?
<Sarvatt> huzzah it actually killed itself on its own in under 5 minutes for once, usually I spend almost 20 barely able to move the mouse pointer before giving up
<RAOF> You're right.  Apart from your tuner drivers being broken I don't see anything particularly informative in those logs.
<ripps> I kind of forgot about that tuner, I haven't used it in years... I should just remove it.
<Sarvatt> ripps: yeah no different with google-chrome-beta even
<ripps> I don't think compiz is responsible for the problem. First of all, the problem persists, even when I revert to metacity; Second, the compiz effects aren't actually slowed down, I can use scale and expo with decent speed. But scrolling or opening a window grinds video/audio to a momentary halt. It like theres something up with gtk or X11 rendering.
<ripps> I'm about ready to reinstall my entire ubuntu to see if it fixes the problem, I'm an upgrade from Karmic to Lucid Alpha 1 and I figure it can't hurt to clean up the system.
<ripps> I have my /home on a seperate partition, so It should be pretty clean and straight forward reinstall
<Sarvatt> valgrinding X sure is a fun adventure
<ripps> I've read a few comments on Identi.ca where some people think that lucid beta2 is much more unstable than the alphas. I think a recent upgrade has been giving alot of problems
<Sarvatt> oh ripps your problem might just be a pulse problem
<RAOF> Sarvatt: What do you think about bug #541492?  The only thing reported to work reasonably there is disabling DRI, which seems a serious feature regression.  It doesn't look like we've got the âbig hammerâ kernel patch, which also isn't a fix but makes things crash less.
<ubottu> Launchpad bug 541492 in xserver-xorg-video-intel "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)" [Unknown,Confirmed] https://launchpad.net/bugs/541492
<RAOF> In a surprising turn of events, it looks like i845 is more stable *with* kms than without.
<ripps> Sarvatt: nope, I already tried killing pulse, no such luck.
<RAOF> Upstream seems to have a good idea of what's going wrong, just not a good idea of how to fix it.
<RAOF> I guess we could disable DRI for release, and then fix it in an SRU when there's a fix available.  Maybe.
<ripps> I'm going back to 2.6.33 mainline so I can d/l the lucid-beta2 iso and reinstall ubuntu.
<Sarvatt> RAOF: 8xx is a mess, I think 865 is the only one thats even remotely stable and theres pretty much no way the fixes are going to be in lucid.. he keeps pushing out huge patch series on the lists that refactor whole subsystems in preparation of trying to fix things on 8xx
<Sarvatt> blacklisting KMS on 8xx was working for a lot of people from what I saw because we disabled UMS support in intel 2.9.1 for awhile (meaning people got vesa automatically with nomodeset) and I see just as many problems now that we have UMS again except people have to manually pick vesa now too
<RAOF> Right.  There seems to be at least as many and as serious problems with UMS as KMS.
<RAOF> The question is what to do about it.
<Sarvatt> oh nice, thats a  differen't fdo bug that i was looking at earlier
<Sarvatt> which big hammer patch did you mean?
<RAOF> Fedora has a patch which doesn't fix things, but which introduces a sufficient delay that it doesn't hit the problem so often.
<Sarvatt> i was just digging through agp commits that are different between our 2.6.32 and upstream
<RAOF> Bugger.  ctrl-w shouldn't be so close to ctrl-v
<Sarvatt> RAOF: do you mean drm/i915: Apply a big hammer to 865 GEM object CPU cache flushing.?
<RAOF> https://bugzilla.kernel.org/attachment.cgi?id=25084 is the patch that I'm talking about.
<Sarvatt> because we've had that for a long time
<Sarvatt> ah yeah we just have the equivalent to that for 865 only
<Sarvatt> (which is probably why 865 actually kind of works)
<RAOF> Hm.  Not according to my grep of ubuntu-lucid
<RAOF> wbinvd is called from exactly 2 places in lucid's kernel - drm_cache.c and ati_pcigart.c
<RAOF> If we had the big hammer patch, it's been lost along the way somewhere.
<Sarvatt> huh, you're right
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/gpu/drm/i915/i915_gem.c;h=e2421869a40cf809f509c57e58a770a7c0e4043a;hp=e4408daf8cef099d388611268be5cbd5605c1dc4;hb=cfa16a0de5392c54db553ec2233a7110e4b4da7a;hpb=e76a16deb8785317a23cca7204331af053e0fb4e
<Sarvatt> ah removed here http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e517a5e97080bbe52857bd0d7df9b66602d53c4d
<RAOF> So, the big hammer patch doesn't fix the problem, but makes it happen (much) less often.
<Sarvatt> have you seen any reports that its crashing with vesa?
<RAOF> No.
<Sarvatt> call me crazy but i think its more than a little crazy to expect things like compiz to work on a 10 year old GPU that was worse than a 4 year old GPU when it was released in a modern distro, they haven't had any acceleration on windows since vista in 2006 and vesa should just workâ¢
<RAOF> vesa won't necessarily get the resolution correct, though, right?
<RAOF> If we don't care about compiz we could just disable DRI on those cards.
<Sarvatt> i'm interested in knowing if anyone has problems with fbdev ontop of KMS on those GPU's
<Sarvatt> hmm http://bugs.freedesktop.org/show_bug.cgi?id=27187
<ubottu> Freedesktop bug 27187 in Driver/intel "[i855GM] gtt chipset flush is not cache coherent" [Normal,New]
<RAOF> That'd be a duplicate, surely?
<RAOF> Or, rather, should be.
<Sarvatt> nope thats 855 specific, patches dont work on 845 going by the other bug..
<RAOF> âThe new chipset flush is a magic dance involving a flock of canariesâ
<Sarvatt> RAOF: what netbook did you get?
<RAOF> Anâ¦ Asus N10J
<RAOF> It's slightly heavier than my x200s :)
<RAOF> But it's got a crazy gpu switch on the side, an nv98, and an hdmi port.
<RAOF> It's kinda fun.
<Sarvatt> ah darn AMI bios
<RAOF> It has, however, reinforced my opinion that netbooks aren't really useful for actual work :)
<Sarvatt> i just discovered the wonders of modifying EFI setup variables in insyde bioses, opened up a crazy amount of options I didn't have before and I'm sure switchable graphics ones have a lot more options :D
<RAOF> Oooh, cool.
<Sarvatt> pfft I've used a netbook as my primary machine for 1.5 years now and haven't looked back, 8.9" too
 * RAOF is firmly of the opinion that they're a poor-man's x200s
<RAOF> 12" is where it's at.
<RAOF> You get a full size keyboard, and a CPU that's faster than mental computation.
<Sarvatt> yup I'm poor! :) I have 4 other laptops but the 10 hour battery is what makes it for me, spend most of my time using it on the road
<Sarvatt> 11-12" is what i'm going to get next for sure though, already eyeballing some new ones
<Sarvatt> oh sheesh, lenovo has NIC/ac adapter whitelists in the bios too? I thought only HP was that crappy..
<RAOF> AMI bios, so I can't play with funky options?
<Sarvatt> RAOF: btw looks like theres more than just the backported fix for nouveau in the old nouveau api situation - http://cvs.fedoraproject.org/viewvc/F-12/libdrm/nouveau-fix-bo-failure.patch?view=markup
<RAOF> Bah.  Why isn't the second fix in libdrm git?
<RAOF> Also, why explicitly cast to void *?  That's throwing away the compiler warning that would have told you that you're doing something obviously wrong and stupid.
<RAOF> :(
<Sarvatt> yeah with my insyde bios i can just dump the full list of options and patch the ones i want, never had any luck doing this with other brands before. here's a listing off one of mine (summary at the bottom) http://pastebin.com/fqAxCqmi
<RAOF> Silly me.  Need to read more context.
<Sarvatt> theres no NOUVEAU_BO_PIN in the 0.0.16 api
<RAOF> Yeah.  I should think before talking.
<Sarvatt> xserver: Branch 'server-1.7-branch' - 20 commits -- whoa
<asac> bryceh: tjaalton: http://pastebin.com/SfEsJXN7 ... can i just upload ?
<asac> or can you stage and upload?
<asac> (thats the last one ;))
<asac> for lucid
<tseliot> asac: it looks good to me. Do you have access to the git branch too?
<asac> tseliot: i dont think i have access
<asac> can you apply and i push
<asac> ?
<asac> or just replay?
<tseliot> asac: yes, I can apply your changes for you
<asac> thanks
<tseliot> asac: let me check if there's something else pending first
<asac> kk
 * asac stands in line
<tseliot> asac: yep there seem to be pending changes: git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=ubuntu
<tseliot> Sarvatt: is your patch ^^ ready to be uploaded?
<ScottK> tseliot: We got that KDE issue sorted over the weekend.
<tseliot> ScottK: that's great news :-)
<ScottK> Yeah, I was worried about that one.
<bjsnider> tseliot, is there a big nvidia-current breakage right now?
<tseliot> bjsnider: no, why?
<bjsnider> the lucid channel has been choked with complaints all weekend
<bjsnider> also several people are saying they managed to use the nvidia-installer
<tseliot> bjsnider: complains about what? About not being able to complete the installation in Jockey?
<tseliot> yes, you can use the installer, and screw your system in the process ;)
<bjsnider> i thought it was disabled
<tseliot> you can override that block
<bjsnider> <franta> NET||abuse: current is 195 and with nvidia-current 3D doesn't work for me :( but when I install binary distribudion from nvidia over it it works
<bjsnider> there were some complaints about jockey reporting that "a different version" is in use
<tseliot> I have fixed that today
<tseliot> (the 2nd issue)
<tseliot> and "3D doesn't work for me" without any logs doesn't mean much to me
<tseliot> (and without knowing how the driver was installed)
<bjsnider> tseliot, i'll get more info about what the deal was on the weekend and report it to you, but i think it was the jockey thing.
<bjsnider> a lot of people put too much faith in what jockey tells them unfortunately
<asac> tseliot: i can also upload this as 2.1
<asac> but lets wait a bit longer for Sarvatt 
<tseliot> bjsnider: ok, if so, revision ubuntu7 should fix it
<tseliot> asac: yes, let's wait a little bit
<bjsnider> tseliot, is it realistically possible to recover from using the nvidia-installer or should that person do a wipe & reload?
<tseliot> bjsnider: maybe by passing --uninstall to the installer and reinstalling mesa
<seb128> is there a known ati issue after user switching?
<seb128> we get quite some bugs on the desktop side saying that screen stays blank after switching
<tseliot> seb128: yes, it's a known issue, nothing we can do about it
<seb128> tseliot, why not? I didn't check but is that a fglrx bug?
<seb128> I'm pretty sure I saw an issue on a box using the opensource one
<tseliot> seb128: yes, I was referring to fglrx. If it affects -ati then it must be a different issue
<seb128> ok, is there a known issue on ati open source? ;-)
<tseliot> I wouldn't know. Anyone ^^ ?
<tseliot> asac, Sarvatt: my bad, there doesn't seem to be any pending commit. Feel free to upload. I'll commit your changes to git
<asac> kk
<asac> tseliot: if something explodes let me know ;)
<tseliot> asac: sure :-P
<asac> uploaded
<tseliot> asac: ok, let me upload the git branch
<tseliot> asac: ok, done
<asac> cool
<Sarvatt> sorry about that asac and tseliot
<Sarvatt> darn I was packaging up the new geode with the missing icon fix commit but Q-FUNK already pushed it to debian even :)
<Sarvatt> the compiz change to not start at >= max texture size instead of > max texture size sure is ruffling alot of feathers
<Sarvatt> > max texture size was working for radeon people with dual screen setups, but people on intel with 1 monitor thats 2048xwhatever can't use it
<Sarvatt> hmm looks like dual monitor 2048 virtual on intel worked too, just not single monitor
<Sarvatt> well that doesn't look good..
<Sarvatt> 221 objects
<Sarvatt> 26755072 object bytes
<Sarvatt> memory usage is fine with edgers, totally busted with lucid
<Sarvatt> ahhh wait I disabled BO reuse in driconf this boot
<ripps> Okay, it time to potentially break my desktop. Let's reinstall Ubuntu
<ripps> Okay... livecd is broken, just drops me to a commandline, no X
<ripps> okay, how about trying xorg-edgers, and than if that fails, I'll try d/ling the daily livecd
<ripps> Well, xorg-edgers seems to load just fine, we'll see if I still get the massive slow down in ~25 minutes
<ripps> Hmm... well, it's been about 50 minutes, and I haven't seen any massive slowdowns/lag/stuttering so I guess xorg-edgers fixed it. (I've probably just jinxed it)
<ripps> dang, I jinxed it. After lagging has showed up.
<ripps> It happened after loading a large image in chrome while running aptitude update in terminal... might be related, probably not.
<ripps> hmm... I gonna play with some ati driver options in xorg.conf, see if maybe limiting the agpsize will help
#ubuntu-x 2010-04-13
<Sarvatt> ok, fglrx + preempt kernel = recipe for disaster
<bryceh> Sarvatt, erf
<bryceh> Sarvatt, is it supposed to work?
<Sarvatt> kas_spin_lock is totally not preempt safe - http://launchpadlibrarian.net/43764353/OopsText.txt
<Sarvatt> sheesh, pains me when I see people using -preempt on a laptop, I hope they never leave the ac adapter :)
<Sarvatt> -preempt uses just under 10 watts more idling for one of my machines, constant 1000+ wakeups/second in powertop
<Sarvatt> bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/542925 -- attached a debdiff if its not too late to get the fix in
<ubottu> Launchpad bug 542925 in xserver-xorg-video-ati "[RN50] mpg files no video or audio on ATI ES1000" [Medium,Triaged]
<bryceh> Sarvatt, thanks, I'll take a look at it tomorrow
<bryceh> (I'm about to run out for the evening)
<bryceh> actually, maybe I can beg a few minutes from the wife
<RAOF> Have fun!
<bryceh> (date night; gonna go see that hot tub time machine movie)
<bryceh> Sarvatt, uploaded
<Sarvatt> woohoo thanks, enjoy the worst named movie ever :)
<bryceh> Sarvatt, RAOF, yeah we can take fixes through to Thursday, and then after release we can do SRU's
<bryceh> so keep the debdiff's flowin' :-)
<RAOF> :)
<bjsnider> what is a debdiff?
<bjsnider> i know what a diff is
<virtuald> a diff to a debian source tree
<virtuald> i think
<bjsnider> how would one go about making such a diff?
<RAOF> With the âdebdiffâ tool; basically, you make a new candidate package, and debdiff produces the diff between the current package and the new package.
<bjsnider> coolio
<bjsnider> then what do you do with it?
<RAOF> Attach it to the bug it's meant to fix, generally.
<Sarvatt> sheesh, that was painful.. took almost 2 hours to update a days worth of packages in fedora from a raawhide livecd snapshot from april 11th. all of this new DRI2 stuff in xserver 1.8 sure does kill performance, I want my tearing back :)
<RAOF_> Do we have anyone here capable of sponsoring an -intel package to break 3D on lots of user's hardware? :/
<bryceh> RAOF_, yes
<bryceh> RAOF_, well if it's ready soonish; I'm about to hit the sack
<hyperair> RAOF_: to break 3D on lots of users' hardware? why?
<bryceh> hyperair, 8xx I assume
<hyperair> eh?
<bryceh> well, it's sack-hitting time.  night
<RAOF> Bah.  Sorry bryceh.
<Mirv> bryceh: woohaa. I just found out the intel slowdown thing I mentioned might be a bug in the ondemand CPU throttler instead. I happened to suspect something fishy once again and added CPU applet to GNOME panel...
<Mirv> with ondemand I get 2-3 times slower performance in gtkperf than with forced clock speed. the 2-3 depends on whether straight after boot or later.
<Sarvatt> RAOF: what intel patch? the cliprects one?
<apw> Sarvatt, bryceh ... what is your feeling on the patches from RAOF to disable acceleration for various nouveau chipsets?  if we want them in the release i need to commit them now, but it isn't 100% clear that they have been tested by those afffected; they have indicated nouveau.noaccel=1 works for them but not used a patched kernel
<apw> i believe the symptoms are not booting without them
<Sarvatt> apw: it's very much needed, I haven't looked over the patches though. they haven't been tested?
<apw> its not clear they _have_ been tested is a better position
<apw> the users appear to have said that they used noaccel on the kernel command line
<apw> and the patches look like they do that at least
<apw> Sarvatt, do you have any of the affected h/w as i do have test kernels
<Sarvatt> have they been booted on machines that dont have quirks to see if it works right otherwise at least?
<apw> or indeed any nouveau h/w that isn't on the list
<apw> i don't have any nvidia h/w so i can't say i know it has been booted either way
<apw> hense my concern :)
<Sarvatt> apw: I wont be able to test it for probably 6 more hours or so until I get off of work
<apw> http://people.canonical.com/~apw/raof-nv-accel-lucid/
<Sarvatt> can ya link a kernel?
<Sarvatt> thanks, will try it ASAP
<apw> pretty much need to made a decision 'now' to hit the deadlines for freeze
<apw> the patches are in the same directory
<Sarvatt> anyone here using nouveau that can test a kernel really fast? :)
<apw> Sarvatt, my feeling is that if it boots and doesn't explode on any nvidia h/w its better to have it than now
<Sarvatt> yeah agreed
<apw> not ... as it makes people boot (assuming it matches correctly) and if it does not ... then they still boot and they can get an update
<apw> but having stopped all thinkpad booting once this week, i am nurvous about any not known tested code
<Sarvatt> i couldn't figure out why that works on 2.6.34 and not our kernel, I think its our battery patch actually
<Sarvatt> the async one
<Sarvatt> hmm yeah the nouveau patches *look* fine to me
<apw> Sarvatt, i thought that too, the first thing i did was back out the battery async patch
<apw> no effect.  it was related to a couple of bugs in the replacement code in part
<apw> at least for thinkpads, however even with that fixed it still kills mac pros and i don't yet know why
<Sarvatt> trying to switch to nouveau and reboot into that kernel remotely, i'm so glad jockey-text exists now :)
<Sarvatt> darn one of my other laptops has a 10de:0244 but 10de:0242 is quirked
<Sarvatt> apw: working fine here
<Sarvatt> on a machine not quirked
<apw> Sarvatt, well thats something at least
<Sarvatt> sudo cat /sys/module/nouveau/parameters/noaccel 
<Sarvatt> 0
<Sarvatt> worst case is it breaks the 3 quirked chipsets that were already broken I'd guess :D
<apw> Sarvatt, i have two other non-quirked confirmations for the patches
 * apw pokes bryceh 
<bryceh> apw, yep
<apw> oh ...
<apw> wondering what you thought about the patches from RAOF diabliing accel for three nvidia cards
<apw> you don't happen to have one of them do you?
<apw> people.canonical.com/~apw/raof-nv-accel-lucid/
<apw> we now have a trio of tests on 'other' nvidia h/w suggesting they don't break things for non-quirked h/w
<apw> and i am feeling they might be worth the risk, as they make unbootable h/w bootable ... what is your take
<bryceh> apw, just looked through the patches, and they look fine
<bryceh> they're limited to only have effect against the specific hardware so should be really low risk
<apw> thats waht i feel, if you have any nvidia h/w you could boot test them too
<apw> expecting them to not trigger
<apw> if you are happy, then i think i am ready to take the risk
<bryceh> if you've already had a couple other people boot check them, that satisfies me. 
<apw> sarvatt, bjf and jfo all have booted with them
<bryceh> perfect
<apw> ok ... fingers crossed then
<tormod> https://wiki.ubuntu.com/X/InputConfiguration talks about  ENV{x11_options.name}="value", is this valid?
<jcristau> no
<tormod> so there is no way to set arbitrary options from udev? was there?
<ripps> geez, what's with all the lucid live cd's they're all broken. The desktop cd has a kernel oops early on and can't load X, and the alternate CD has no network modules installed
<ripps> All I want to do is reinstall Ubuntu....
<tormod> Sarvatt, I think the gallium hook is finished now...
<jcristau> tormod: there was.  there isn't now.
<tormod> jcristau, thanks, do you know when it was in Ubuntu?
<jcristau> tormod: it went away with server 2:1.7.6-2
<jcristau> replaced by inputclass
<tormod> jcristau, your reply on "release thoughts" was really good :)
<Sarvatt> AGREED! I was just going to mention that :)
<Sarvatt> protos never were an issue here, it takes all of 10 minutes to completely update and package them all.. and I wouldn't exactly call the 3 month intel release process a good model since theres almost no stable release support there
<tormod> if they want more people to test latest git, they should make it easier for us packagers to package it, rather than the odd guy wanting to compile the whole pile :)
<jcristau> also they should make it not broken half the time.  granted it's not much more broken than the "releases", but still.
<ripps> hmm... with xorg-edgers, it seem like there's some errors rendering ass subtitles. 
<ripps> in mplayer
<jcristau> tormod, Sarvatt: note that you're allowed to comment as well if you have an opinion on that stuff :)
<tormod> we'll be dismissed as ubuntu fanboys :) and canonical has so much money and all that
<bryceh> heh
<Sarvatt> hard to write a meaningful comment on my phone but I was planning on it :)
<bryceh> yeah I got hate mail last time I posted to xorg-devel with ubuntu perspective feedback about release stuff
<BUGabundo> eheh
<BUGabundo> so we are eaten by wolfs if we say something 
<BUGabundo> and eaten by wolfs if we shut up
<bryceh> BUGabundo, that seems about the gist of it
<BUGabundo> many upstreams seem to dislike ubuntu 
<BUGabundo> go figure
<BUGabundo> but then again, 'I'm a fanboy'
<BUGabundo> so my POV doesn't count
<Sarvatt> my only real complaint about ubuntu is the amount of patches carried around for most packages that deviate significantly from upstream. enabling features or providing a better out of the box experience is a goal I agree with but just about every major package I grab I find patches from years ago that I question the relevance of but I'm not able to follow the code well enough to say for sure its not
<bryceh> Sarvatt, is that an issue you've seen with the X packages?
<bryceh> Sarvatt, admittedly we've got an assload of ubuntu patches in xserver, many of which are not cherrypicks
<Sarvatt> xserver compiz and gnome-screensaver are the most recent ones i've looked at off the top of my head, its just when I see bugs with errors happening in the code path the patch from 4 years ago with no description and not upstream touches my I spend hours trying to research the patch (which happens a *lot*)
<bryceh> yeah we could probably do better with xserver.  OTOH I think we did a pretty good housecleaning when 1.7 got merged
<bryceh> maybe for meerkat you, raof, and timo can do a more thorough scrub
<bryceh> e.g. there's a bunch of xserver patches which really are just null pointer asserts which might not be needed anymore, but I kept them in lucid just to be extra conservative
<seb128> bryceh, bug #553401 is that something on your list for lucid?
<ubottu> Launchpad bug 553401 in xkeyboard-config "typo in some symbol files in xkb-data" [Undecided,Confirmed] https://launchpad.net/bugs/553401
<seb128> bryceh, I'm not sure if it's right or not, just ran across it while searching for a duplicate and it has a change which seems easy to review
<bryceh> seb128, it's not on my todo list, but yeah I noticed it as well but also was not sure if it's right or not
<bryceh> seb128, is it a serious issue, or just code cleanup?
<seb128> ok, I just wanted to point it
<seb128> well users comment suggest it makes layout work instead of returning errors 
<seb128> see comment #1
<seb128> I'm not sure if that's true though
<seb128> I just mentioned it in case somebody there was familiar with xkb
<seb128> let me ping svu ;-)
<bryceh> ok well as there's a debdiff included I can just slap it in; it doesn't sound like it holds much risk
<bryceh> thanks for contacting svu
<bryceh> seb128, ahh nevermind, don't bug svu
<seb128> bryceh, <svu> seb128: well, the patch makes sense indeed. 
<seb128> bryceh, too late
<bryceh> the fix is to remove semicolons from a ubuntu patch
<seb128> right...
<jcristau> yeah the patch seems correct.
<bryceh> oh not a ubuntu patch but a cherrypick from upstream, so worth notifying svu
<bryceh> seb128, uploaded
<seb128> bryceh, thanks!
<bryceh> seb128, ok _now_ I have no further todo's planned for xkeyboard-config
<bryceh> all the high priority xkeyboard-config bugs tagged lucid are resolved
<seb128> good ;-)
<seb128> and nice to see we got that fix in too
<RAOF> apw: I've booted that kernel and it didn't affect my non-quirked hardware, and the reporter of the GeForce 3 boot-hang found that it successfully booted the otherwise unbootable hardware.
<jcristau> Sarvatt: you've got quite some experience building X from git with edgers and all, i think that's valuable to that discussion, since making that easier is what keithp uses to justify his changes afaict
<bryceh> morning RAOF
<RAOF> bryceh: Good morning.
<RAOF> bryceh: Sorry about missing you last night.  There's a debdiff on bug #541492, and a commit in pkg-xorg/libdrm for another bug.
<ubottu> Launchpad bug 541492 in xserver-xorg-video-intel "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)" [Unknown,Confirmed] https://launchpad.net/bugs/541492
<bryceh> ok
<bryceh> RAOF, had to redo the debdiff a bit since I already did a -3ubuntu2 just a bit ago
<bryceh> libdrm uploaded
<bryceh> intel -3u3 uploaded
<RAOF> Thanks muchly.
<bryceh> man, this is just depressing:  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg
<RAOF> :(
<RAOF> In some ways that's partially to be expected, though.  There's certainly upward pressure on that graph towards the end of a cycle, where there are more people testing.
<bryceh> yep
<RAOF> Man, the intel bugs are volatile though!
<bryceh> yeah here on out we're not going to be able to wrestle the bug stats down
<bryceh> RAOF, volatile as in tempers?
<RAOF> That too:)
<RAOF> I mean volatile as in âcontribute most of the jaggedness to the totals curveâ
<bryceh> with -ati I'm amazed at a) how many are really just looking for free tech support, not really reporting an actual "defect" for us to fix, and b) how often people pinpoint the issue to the *kernel* modesetting (UMS is fine) yet still file the bug against xorg.  Heh
<bryceh> RAOF, ah yeah
<bryceh> RAOF, well in truth with this style of stacked graph, whatever significant package were on the bottom would cause spikiness
<bryceh> here -intel is towards the top - http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
<bryceh> well, this one shows we made a pretty solid dent prior to -beta2:  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
<RAOF> Well, yeah.
<bryceh> wish we'd gotten more sent upstream though
<RAOF> Actually, that's something that we should probably discuss at UDS - with a significant part of X now in the kernel, how do we want to do the triage?
<bryceh> yeah that'd be a good topic
<bryceh> mainly it boils down to the question, if we just sent all the output and modesetting bug reports to linux, is someone still going to be about to forward those bug reports upstream?
<RAOF> Right.
<RAOF> But it's also that those are quite a specific type of kernel bug report, and it's a type that us X guys generally have significant insight into.
<bryceh> so far, if it's clear it's a kernel drm or modesetting issue I've just been shoving it on over and not worrying about it.  If it's not clear I send it upstream and once I see a kernel patch proposed upstream, then I move it to linux.
<bryceh> in the latter we've done half the work so I don't feel bad about it.  The former case though I feel a bit guilty in that I don't know if JFo or other kernel folk are going to forward bug reports upstream
<bryceh> but sending bugs upstream isn't hard, just drudge work
<RAOF> Yeah.
<bryceh> yeah regarding the insight... that was my motivation for writing up everything I know about modesetting issues and posting to the kernel mailing list
<bryceh> these kinds of bugs are quite common and have a fairly well defined set of steps to troubleshoot and I don't think it's good if only a few of us have the necessary insights to troubleshoot them
<bryceh> anyway, like you said it's a good topic to discuss
<bryceh> honestly I just don't think we really have the manpower on just the X side
<jcristau> hire more people :)
<bryceh> jcristau, but who to hire?
<jcristau> yeah good question..
<bryceh> jcristau, fact is we have graphics slots open on the jobs page.  Finding people interested + skillful with X is tough
<jcristau> right :/
<bryceh> at least on the kernel side, even if they don't have X skills, they have ability to fiddle kernel code, and so could learn X as they go
<bryceh> a lot of resolution issues are just quirks or minor algorithm fixups that don't require much X depth, just knowing where to slap the appropriate C code in
<RAOF> Yeah.
<bryceh> problem is that with quirks we used to be able to have users easily test them via setting an option in xorg.conf, but there's no equivalent mechanism in the kernel yet
<bryceh> once there is though, the process of handling those bugs could probably be handled by the bug triagers pretty well
#ubuntu-x 2010-04-14
<jg> bryceh: beta 2 wouldn't even boot at all on that Latitude XT I've got.  Sigh.
<bryceh> jcristau, what do you think of this patch - http://launchpadlibrarian.net/32728179/xserver-xorg-backclear.patch
<bryceh> jcristau, it's from the fglrx folks and solves a rather longstanding issue for fglrx users, but I'm uncertain how it'd affect !fglrx folks
<bryceh> jcristau, anyway my guess is the patch just pushes issues to other use cases
<Sarvatt> bryceh: that bug makes my head hurt
<Sarvatt> read probably 200 comments on it just now, i'd say 90% of them are people giving *really* bad advice people might actually try :)
<Sarvatt> ahhh darnit, the new git-core update we got made me think my packaging repos were messed up and I started over, but the huge warnings are happening everywhere now after all
<bryceh> Sarvatt, yeah there's a lengthy blog post I did a while back on all the evils of me-too storms
<Sarvatt> oops, looks like it was an actual change in git functionality that broke how I use it, crap
<Sarvatt> no, i'm just an idiot and was updating the wrong package. need sleep :)
<Sarvatt> bryceh: yeah I remember that, almost makes me wish we could tag bug comments as inappropriate and have a filter for them :)
<bryceh> yep
<RAOF> That's an interesting idea.  Allow maintainers to flag comments as âThe maintainer thinks that taking this advice is a BAD IDEAâ or somesuch.
<bryceh> I still think we need launchpad to require > N karma in order to comment on someone else's bug, especially once it's gotten more than a dozen comments
<RAOF> That would probably work, particularly if it encouraged people with insufficient karma to file a new bug.
<bryceh> (or just click 'affects me too')
<RAOF> That too.
<RAOF> Although we'd miss bugs that way.
<Sarvatt> is affects me too even useful? if it affects someone I want to see their system info
<RAOF> Because there's a significantly higher than 0 chance that this particular bug does *not* affect them too, and they've got a different one.
<Sarvatt> specifically if its a bug requiring a hardware specific quirk to be added
<bryceh> Sarvatt, it's useful in making the reporter feel they have done their part, without cluttering our bug tracker with useless 'me-too' comments ;-)
<RAOF> That could have a technological solution - if apport-collect didn't laboriously attach everything as an individual comment, but instead just added a link with âhere's the data of another person who thinks they've got this bugâ we could make that happen.
<RAOF> Making apport-collect less intrusive would be a worthwhile goal regardless, I tihnk.
<bryceh> yep
<RAOF> Launchpad just isn't sufficiently awesome.  It'd be useful to be able to issue queries like âwhat hardware has been reported affected by this bugâ, and suchlike...
<bryceh> or the inverse... "Show me what bug reports have been reported against this hardware"
<RAOF> Hell, yes.
<bryceh> imagine if launchpad had the ability to show you a list of bugs that excluded ones that aren't applicable to it
<bryceh> er applicable to the hardware you are on
<bryceh> would eliminate many false-positives
<bryceh> well, one day we'll have that, in time for debugging our flying cars
 * bryceh > dinner
<Sarvatt> part of me wants to drop a huge number of patches in edgers packages just so things are closer to upstream for people asked to test on bug reports, but then the other part wants to do things like backporting EXA from master to 1.7 branch :D
<KiBi> at 3:30am? Crazy guy
<KiBi> Sarvatt: please backport EXA stuff; that'll spare me some work :)
<KiBi> (the other part here needs to sleep, sucky one..)
<RAOF> Sarvatt: Dropping patches in edgers seems reasonable to me; upstream bug testing is one of its purposes.
<Sarvatt> KiBi: I've been doing it for a month or so already - http://sarvatt.com/downloads/patches/exa_backport_to_1.7.6.patch
<KiBi> ah, fat huge patch :)
<KiBi> (thanks for the pointer anyway)
<Sarvatt> haven't heard any complaints, i've been doing it that way because i dont have time to bring in xserver 1.8 and rebuild the world and its supposed to be a significant speed up
<Sarvatt> (plus it fixes the xfig crashing the server bug)
<Sarvatt> thats just a git diff xserver-1.7.6..master exa/ btw
<KiBi> Sarvatt: what I wanted to do would be more like cherry-picking targeted fixes so I guess I'm going to sleep later :)
<Sarvatt> oh nice, http://cgit.freedesktop.org/xorg/xserver/commit/?id=1760d2bef9f5b248cb2332f6ebf0220eb02bab42 applies to our 1.7.6 too, can finally test out chromium webgl :)
<Amaranth> Sarvatt: But then programs will start trying to use it and almost certainly run in to some sort of bugs
<Sarvatt> I'm not suggesting using it ubuntu or anything, i'll be glad if I do find something broken by it so I can report it :)
<Amaranth> Well I can't say bug 562773 was unexpected but I was rather surprised to see it filed against compiz
<ubottu> Launchpad bug 562773 in xorg "Enable automatic graphics switching (between integrated and discrete graphics) similar to OSX" [Undecided,New] https://launchpad.net/bugs/562773
<RAOF> Don't you know?  Compiz *is* OSX.
<Ng> hrm, disabling DRI on 855
<Ng> is that going to have a nasty effect on compiz performance?
<jcristau> it's going to make compiz not work.
<Ng> jcristau: that's unfortunate. my old X40 which sees ~1hr usage a day has been doing really well on Lucid, I don't think it's crashed at all, but I guess people with crappier laptops, or heavier usage, are having problems
<Ng> why oh why doesn't everyone buy a nice laptop? ;(
<rye> is font rendering applied here?
<rye> Terminus font on http://wiki.openvz.org/Download/template/precreated looks scaaary
<apw> anyone aware of bug#546743
<apw> anyone aware of bug #546743
<ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
<apw> bryceh, was it you who was looking after ATI
<tseliot> apw: does booting with radeon.modeset=0 solve the problem?
<apw> tseliot, booting with nomodeset seems to sort it out yes
<apw> seems to be a boot panic, flashing caps locks with it
<tseliot> apw: [drm:radeon_i2c_sw_put_byte] *ERROR* i2c 0x08Â  -> it looks like the i2c functions are not working correctly
<apw> ouch
<tseliot> apw: maybe disabling kms for this chip wouldn't be such a bad idea at this point in the release cycle
<tseliot> unless there's a fix somewhere
<apw> tseliot, so many exclusions
<tseliot> apw: I wish we could fix every bug but, unfortunately we can't :-/
<apw> indeed, i am wondering however if the blacklists should really be done in userspace somehow
<apw> so the list can be updated
<tseliot> apw: but then we would have to blacklist radeon in the initramfs too, which we can't do on per card model basis
<tseliot> I guess. I may be wrong though
<Sarvatt> hmm apw thats a new one, I've seen at least 5 confirmations ES1000 was working fine
<apw> Sarvatt, hrm, beep
<Sarvatt> those logs dont really help, they are on the old drm kernel and its probably totally different now
<Sarvatt> asked him for more recent ones
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=2739d49cd7f1f44876cad614b072da698967b370 is the only rn50 specific we dont have already
<rickspencer3> apw hi
<apw> rickspencer3, ...
<rickspencer3> apw, same discussion
<apw> Sarvatt, thanks for poking that hornets nest
<rickspencer3> we sadly got out of sync regarding the 845, 855 instabilities
<rickspencer3> trying to rectify that now
<rickspencer3> apw, sadly, I am not really a good technical resource for helping you understand the work around
<rickspencer3> bryceh is, of course, bu tI don't expect him online for a bit
<Sarvatt> heres a dmesg from someone on rn50 thats working fine, they only have one connector listed - http://launchpadlibrarian.net/41443377/BootDmesg.txt
<bryceh> heya
<Dr_Jakob> Hmm it looks like xserver-xorg-core-dbg is broken in Lucid.
<Sarvatt> Dr_Jakob: sudo apt-get purge xserver-xorg-core-dbg, reboot and install xserver-xorg-core-dbg after?
<Sarvatt> works for me
<Dr_Jakob> Ok I'll try
<Sarvatt> upgrading doesn't work, CRC errors, it's not specific to xserver-xorg-core-dbg for me and it happens to any dbg packages for things currently in use when I  upgrade
<Dr_Jakob> ah ok
<Dr_Jakob> Still get the CRC error tho...
<Sarvatt> apw: sorry looking into it in 20 minute chunks between jobs so its taking awhile, really need to find out the panic message when it panics for him but it seems related to the external tmds on there
<Dr_Jakob> this is 64bit btw...
<Sarvatt> odd, i've been having that problem for months and that routine works for me every time
<Sarvatt> does it load it if you manually load the symbols in gdb?
<Dr_Jakob> Hmm my gdb-fu isn't that good?
<Sarvatt> symbols /usr/lib/debug/usr/bin/Xorg
<Sarvatt> (or is it just symbol..)
<Dr_Jakob> hmm that worked...
<Sarvatt> i dont know what the deal is there, been a problem for months though. Dr_Jakob try enabling the ddeb repo and install -dbgsym instead of -dbg?
<Sarvatt> add deb http://ddebs.ubuntu.com lucid main restricted universe multiverse #debugging ddebs to your /etc/apt/sources.list and update then install xserver-xorg-core-dbgsym
<Dr_Jakob> Reading symbols from /usr/lib/debug/usr/lib/xorg/modules/libshadowfb.so...(no debugging symbols found)...done.
<Dr_Jakob> hmm the package was only 160kb..
<Sarvatt> ugh, tried manually loading those symbols too? thats annoying, wonder why I dont hit that
<Sarvatt> the dbgsym was only 160k?
<Dr_Jakob> Get: 1 http://ddebs.ubuntu.com/ lucid/main xserver-xorg-core-dbgsym 2:1.7.6-2ubuntu3 [8,612B]
<Dr_Jakob> Fetched 8,612B in 0s (231kB/s) 
<jcristau> probably because the -dbg already exists so there's nothing to put in dbgsym
<bryceh> yeah you don't want both -dbg and -dbgsym
<Sarvatt> i just installed xserver-xorg-core-dbg and its working fine, go figure :(
<Sarvatt> the crc's match when i compare them
<Dr_Jakob> Sarvatt: 64bit?
<Dr_Jakob> can you md5sum Xorg and debug Xorg?
<Sarvatt> nope 32
<Dr_Jakob> Hmm :-/
<Dr_Jakob> Well I head home now, I'll try a 32bit VM tomorrow: I'm currently trying to solve https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/545298
<ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [Undecided,Incomplete]
<vish> hmm , anyone noticed that there is a problem when running flash video? memory is used enormously  , even swap gets used
<Dr_Jakob> Sarvatt: thanks for all the info.
<apw> bryceh, about?
<bryceh> yeah
<apw> bryceh, rickspencer3 says you have some machines which have 'serious i915 issues'
<apw> and so i am wondering what the issues are, as the kernel is uploaded
<bryceh> apw, ??
<bryceh> apw, afaik the only thing we're really worrying about at this stage are a few 8xx cards
<apw> bryceh, hrm if you don't know then i guess they don't exist
<bryceh> but we shut off dri in them the other day in ums
<apw> then perhaps its all nothing
<bryceh> we might ask you to do a couple more kms blacklists, but testing so far isn't indicating it solves the freezes anyway
<bryceh> apw, do you need to roll a kernel rev to add blacklists?
<apw> yep blacklists are a full kernel upload
<apw> do you think you have a few you need?
<apw> if so we might want to plan on getting one upload like late friday with the accumulation
<apw> and start asking for permission
<bryceh> well like I said we have been considering it for a few 8xx chips, but so far testing with i915.modeset=0 on those cards hasn't shown it improves things, so maybe not
<apw> i have a bad dell bug outstanding which i need to get fixed, which if i do i suspect will be allowed past freeze too
<bryceh> let me check the state of the bug reports in question
<bryceh> apw, lp #542208
<ubottu> Launchpad bug 542208 in linux "Please blacklist i830 from Kernel mode-setting" [Critical,In progress] https://launchpad.net/bugs/542208
<bryceh> apw, maybe you already did that one?
<apw> crap i have patches for it but they arn't in
<bryceh> the other two we're considering are 541492 (i845) and 541511 (i855)
<Sarvatt> ah crap, everything I said earlier didn't go through
<apw> ok so i may as well hold this one till the decisiion is made on the other two ?
<Sarvatt> <Sarvatt> anyone seen a bug report for these rs600 failures to start? inspiron xt is the most common model
<Sarvatt> <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32b3c2abaf8c61c80a8b02071c73f05252122ffe is the fix but I dont have a bug report handy to link it to
<Sarvatt> <Sarvatt> jg was complaining about it earlier
<apw> bryceh, or should i shove it in now ... 
<bryceh> 2 minutes... reviewing recent bug report comments
<Sarvatt> <Sarvatt> Keybuk had the problem originally but he worked with upstream for the fix, dont think he filed a bug on LP
<Sarvatt> <Sarvatt> vish: yeah I'm experiencing the same problem with intel right now, disabling BO reuse in driconf fixes it
 * Sarvatt grumbles at the crappy signal
<bryceh> apw, I think we should go ahead with blacklisting i830, i845, and i855
<bryceh> apw, want me to dig up the pci ids?
<apw> sure ...
<apw> mvo, is testing the i830  blacklist 'now-ish'
<bryceh> i830: 8086:3577, i845:  8086:2562, i855: 8086:3582
<bryceh> apw, want it in the form of a bug report?
<apw> it'll need one yeah at this stage
<apw> but i'll get the kernel building, you got any h/w to test it?
<bryceh> no, I don't have any 8xx hardware
<apw> damn
<bryceh> the jerry guy seems pretty responsive though and has two of the three chips
<apw> whats hit irc nic?
<bryceh> don't think he's on irc
<apw> oh
<Sarvatt> sorry thats latitude XT that has the RS600 that can't boot lucid
<bryceh> lp id is jerrylamos
<Sarvatt> got one - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
<ubottu> Launchpad bug 544590 in linux "[RS600] video freeze with KMS (X and plymouth)" [High,Confirmed]
<bryceh> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/563277
<ubottu> Launchpad bug 563277 in linux "Please blacklist older 8xx cards from using KMS" [Undecided,New]
<vish> Sarvatt: hmm , where do i have to disable it?  I'm using ATI , btw , also heard the same complaint from another lucid user on a mac hardware
<vish> the " disabling BO reuse in driconf"
<bryceh> Sarvatt, what are your thoughts vis-a-vis blacklisting 830, 845, 855 from kms?
 * vish brb
<apw> bryceh, are you asking for more than those 3 ID above to be blacklisted on that bug ?
<bryceh> apw, yeah, while we're at it we may as well do the earlier chips.  I don't think anyone has been testing them but if these three dont' work, those older ones won't either
<bryceh> apw, those earlier ones aren't even supported upstream any longer in the newer -intel so we're going to have to drop them down to -vesa 
<bryceh> apw, what do you think?
<apw> i am really in your hands ... that sounds plausible
<bryceh> apw, fwiw, blacklisting kms is going to give us only marginal benefits as near as I can tell, so I'm a bit on the fence
<apw> bryceh, as in they are as bad on UMS as well?
<apw> bryceh, these older ids don't seem to be in the driver, so i don't think it will attach to i915
<bryceh> apw, yeah the testers say the freezes still happen, just less often
<bryceh> alright
<bryceh> ok cool, wasn't sure.  Like I said they're no longer supported by upstream, so no surprise they're not even in i915 anymore
<apw> yeah not there at all
 * bryceh removes them from bug report
<apw> ok .. i am building test kernels with those blacklists in
<apw> we should get some feedback on i830 from mvo when he's done testing
<bryceh> ok great
<apw> and we should get as many of us as possible to boot test it on non-affected h/w
<apw> if that passes i can upload it later tonig
<apw> as it seems we cna only fix the dell thing before release if we can upload tommorrow
<apw> so we should upload this before freeze ...
<apw> i'm off to the s/m will check the builds when i get back
<komputes> bryceh: Any PPA that may workaround this bug: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/301958
<ubottu> Launchpad bug 301958 in xorg-server "[needs-packaging] no working driver for sis 671/771 video cards" [Unknown,Confirmed]
<komputes> Djalma B. Martins  wrote on 2009-07-04 that extracting the driver from the RPM (linked in the bug) works. Could this be packagd/
<Sarvatt> komputes: none that I'm aware of, that "needs-packaging" bug refers to a fork of the sis driver from a *very* long time ago that no longer works with xserver 1.7, the other distro that was shipping it has also dropped it in the latest release
<komputes> Sarvatt: thanks for the update - is the guy who does the SIS driver for linux still active. I remember emailing him a year ago but never getting a response
<Sarvatt> nope, he stopped working on that driver 4 or 5 years ago I believe
<bjsnider> won't vesa work with it?
<vish> Sarvatt: how do i disable the BO reuse?
<Sarvatt> komputes: try looking into using sisfb and manually picking your resolution and using fbdev for the server if its just a resolution problem you have
<Sarvatt> vish: driconf
<vish> thanks ..
 * vish  installs driconf
<Sarvatt> vish: do you have a bug or know of a bug about it already? might end up having to default BO reuse to off
<komputes> Sarvatt: by "using sisfb" I assume you mean adding "sisfb" to /etc/modules - not too sure what you mean by fbdev
<Sarvatt> vish: or are you using edgers?
<vish> Sarvatt: nope , i reverted from edgers a couple of weeks ago , i dont think there is a bug
 * vish files one
<vish> Sarvatt: bug should be in which , btw?
<Sarvatt> mesa or xserver-xorg-video-intel
<Sarvatt> vish: cat /sys/kernel/debug/dri/0/gem_objects will show you the crazy memory usage
<vish> hmm , let me play flash again , just restarted session to clear swap
<BUGabundo> evening 'p
<BUGabundo> great... now I'm left with an artifact on my screen... from a mouse over tooltip. how can I remove this ?
<vish> anyone seen this >  http://www.youtube.com/watch?v=C_ozjS55mW8
<vish> err , not a spam youtube link , but rather a capture of and X error ^ ;)
<vish> of a*
<BUGabundo> lol
<vish> BUGabundo: i mentioned it since there was spam running on several channels , "Have you seen my boobs or are my boobs small" with a link :s
<vish> but that link is bug I'm facing ;p
<BUGabundo> vish: reminds me of yesterday apache.org shortlink atack
<vish> Sarvatt: weird , i dont have an option for "BO reuse" in driconf :(
<tormod> did anyone find out about the CRC mismatch in gdb? I get it with /usr/lib/dri/savage_dri.so
<bryceh> tormod, haven't heard anything
<Sarvatt> tormod: manually load the symbols with symbol /usr/lib/debug/usr/lib/dri/savage_dri.so
<tormod> Sarvatt, I tried but it did not help
<Sarvatt> tormod can ya paste the output of objdump -s -j .gnu_debuglink /usr/lib/dri/savage_dri.so ?
<tormod> sarvatt:  0000 73617661 67655f64 72692e73 6f000000  savage_dri.so...
<tormod>  0010 090b30b4                             ..0.            
<Sarvatt> strange, it works here, that with the lucid mesa?
<Sarvatt> debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of 929AF169
<Sarvatt> actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be 929AF169
<Sarvatt> i have edgers at the moment, switching back to lucid mesa to check it
<Sarvatt> your CRC should be b4300b09 so you definitely aren't using edgers, silly question
<Sarvatt> vish: oh, you aren't using intel?
<Sarvatt> tormod: yeah the lucid archive ones are screwed up here too
<Sarvatt> debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of 72419D41
<Sarvatt> actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be B4300B09
<Sarvatt> all the xserver ones are screwed up too, hmm
<jcristau> binutils fuckage?
<Sarvatt> sounds like it
<jcristau> sounds like a great time in the release cycle for that
<Sarvatt> or pkg-create-dbgsym since PPA packages are fine
#ubuntu-x 2010-04-15
<Sarvatt> tormod: the -dbgsym package works -dbg has the wrong CRC
<Sarvatt> debug_file: /usr/lib/debug/usr/lib/dri/savage_dri.so has CRC of B4300B09
<Sarvatt> actual_file: /usr/lib/dri/savage_dri.so thinks CRC should be B4300B09
<Sarvatt> (after purging dbg and installing dbgsym)
<Sarvatt> bryceh: has this been the craziest week for bugs or what? :D
<Sarvatt> wowsa, my VPS moved to a new datacenter and they put me on a 8 core xeon instead of the slow dual core opteron I had before, time to build some kernels!
<bryceh> Sarvatt, has it?  sadly it seems rather pedestrian compared with some releases
<bryceh> always the last few weeks before release get kind of crazy
<bryceh> I'm actually a bit optimistic that 8xx is our only big worry at the moment
<Sarvatt> ati and nouveau are in nasty shape, we've got <NV50 nouveau's reporting phantom TV connectors a lot of the time coupled with the fact plymouth is broken on nouveau with >1 output, there are quite a few ati generations with issues like rn50 with a tdms hooked up that refuses to start that i just found out about this morning (nasty because thats a *very* popular server chipset), and tons of reports about screwed up multihead issues on other ati. K
<Sarvatt> MS should have been disabled on the server kernels for sure. then there's the flickering lenovo and people with switchable GPU's using the intel side are getting, I wasn't able to work out a way to use failsafe easily because the initramfs-tools blacklists were getting ignored after a certain point in the boot and KMS was loading anyway. clutter 1.2 is HORRIBLY slow on intel without xserver 1.8 because of the GLX swap method its using
 * bryceh holds hands over ears, shuts eyes, and 'lalalala's
<bryceh> honestly though, all those issues seem bad but we've had releases that were much worse
<bryceh> or at least seemed much worse
<bryceh> I'm sure jcristau is sitting over there laughing at us for sucking so bad ;-)
<Sarvatt> i think we're going to set a record for the number of complaints that the livecd wont even start up this release :)
<bryceh> Sarvatt, I dunno
<bryceh> I can see that possibly with -nouveau, but even -nv tended to suck pretty hard in that regard
<bryceh> -ati and -intel seem to be pretty solid in my own testing
<bjsnider> but clutter isn't going to be used as much because gnome-shell isn't the default yet, so that intel issue isn't too bad
<RAOF> Sarvatt: I thought I was pretty on top of the nouveau bugs, and I can't recall a lot of phantom TV problems.  We could pick up Fedora's patch to quirk that off if there's a widespread problem.
<RAOF> Sarvatt: I think the problem where the blacklist gets ignored is that the blacklist only prevents the module being autoloaded, which it does, but then X starts up and the DDX specifically requests it's kernel module, which exists, and so gets loaded.
<Sarvatt> wish it was that easy, it was getting loaded by plymouth :(
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/539655
<ubottu> Launchpad bug 539655 in linux "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [High,Triaged]
<Sarvatt> https://bugs.edge.launchpad.net/bugs/533135
<ubottu> Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged]
<RAOF> Oh, balls.  Because plymouth has a drm backend, which will be doing the same thing.
<Sarvatt> yeah i tried adding a new check in plymouth for the extra command line option i added to not load but didnt have any luck
<Sarvatt> ahhh that second bug wasnt filed against nouveau, no wonder
<RAOF> Neither was the first bug.  I'm well aware of the plymouth bug, though, because I've been duping lots of nouveau bugs against in.
<RAOF> s/in./it./
<Sarvatt> oh nice - http://lists.freedesktop.org/archives/nouveau/2010-April/005576.html
<RAOF> A little bit late, but yeah.  I've been watching that.
<RAOF> HURRAY!  At least the macbook pro noaccel quirk seems to be working as planned.
<bryceh> RAOF, Sarvatt, hey this is probably the last chance we have to toss in patches without doing paperwork... are there any patches on your radars that you'd like to have me upload?
<bryceh> I'm about to head over to my mom's to help with some stuff but have a few minutes
<RAOF> Are you taking care of vesa-on-855-845?  That's the change on my current radar.
<bryceh> that one I think will be worth doing the paperwork on, so I'm ok waiting a couple days there
<bryceh> should be an easy patch, but I want to see how the no-kms / no-dri changes shake out before going that route
<RAOF> That's reasonable.
<Sarvatt> bryceh: none that I can think of unfortunately
<bryceh> Sarvatt, I still have on my todo list to look at that redhat patch to rejigger how lvds modesetting works, just haven't had time to dig into it
<bryceh> might look at it when I get back tonight or tomorrow morning if there's time
<Sarvatt> bryceh: OpenBSD backported quite alot to intel 2.9.1 since they have GEM but no KMS now but I haven't been able to dig up a link yet
<Sarvatt> might be worth looking over
<Sarvatt> yeah looks like its not public yet, darn
<Sarvatt> i was asking if it'd be possible to push it straight to 2.9 branch so everyone could collaborate and send along the commits we are backporting on it but didn't get a response
<bryceh> mm
<Sarvatt> ahh found a tarball at least  - http://old.nabble.com/New-intel-X-driver-requires-testing.-td28210444.html
<bryceh> alright, I have a few minor cherrypicks from xserver upstream which I'll upload later tonight
<Sarvatt> going to take a year to compare it from the tarball :D
<bryceh> heh, yeah
<Sarvatt> http://sarvatt.com/downloads/patches/openbsd2.9.1.patch
<Sarvatt> thats a huge patch
<RAOF> You're sure that's not just an entirely new driver which happens to share some filenames? :)
<vish> Sarvatt: nope , I'm using ATI , and another mac Lucid user also has same problem
<RAOF> Has anyone figured out why Xorg seems to prefer vesa over any of the other fallback drivers we've got set?
<bryceh> RAOF, don't think so
<bryceh> RAOF, worth studying for meerkat tho
<RAOF> Man, I wish evolution wasn't such a memory hog.
<tjaalton> RAOF: got a logfile?
<RAOF> tjaalton: Of Xorg picking the wrong fallback?  Yeah, many.   http://launchpadlibrarian.net/43695726/XorgLog.txt is a fine example.
<tjaalton> right, should use fbdev
<RAOF> nouveau loads, nv loads, vesa loads, fbdev loads... nouveau bails, vesa picks it up.
<tjaalton> but how did that work before? that part was not changed aiui
<tjaalton> i mean, how should it know to load fbdev instead of vesa?
<RAOF> No, it should try nv before vesa.
<tjaalton> oh
<RAOF> I don't think we've ever really tested âI'd like driver A, then if driver A fails try driver B, then fallback to vesa or whateverâ before.
<RAOF> As far as I know, it's always been âtry the driver that should work, or vesa if it doesn'tâ
<tjaalton> does this case have xorg.conf?
<RAOF> No.
<tjaalton> ok
<RAOF> If it had xorg.conf X wouldn't be trying to fallback at all, would it?
<tjaalton> not true anymore
<RAOF> It'd try the driver specified, then bail?  That's the behaviour I remember?
<tjaalton> since -2u1
<RAOF> Ah.  With xorg.conf.d?
<tjaalton> no, the patch from suse (merged in 1.8)
<tjaalton> which allows us to use xorg.conf.d & inputclass..
<RAOF> Ok.  That seems a better behaviour, yes.
<tjaalton> maybe something to ask rÃ¼diger..
<tjaalton> RAOF: seeing what happens with beta1 would be interesting too, to confirm if this is a regression or a bug in nv
<RAOF> I *think* this has been consistent throughout lucidâ¦  I wonder if I've got a beta 1 livecd handy?
<tjaalton> hm, cdimage.u.c doesn't have it
<tjaalton> though it should be enough to build the previous xserver version and start with that
<tjaalton> or comment out the patches
<RAOF> Of course.  Hurray for packaging-in-vcs.
<tjaalton> indeed :)
<tjaalton> speaking of which, bryceh: please push mesa to git
<bryceh> tjaalton, done
<tjaalton> bryceh: thanks
<tjaalton> fyi, I'm merging a couple of patches from upstream to allow adding stuff in /etc/X11/xorg.conf.d as well
<tjaalton> first in debian
<tjaalton> now if you do that the system dir is bypassed, breaking things..
<tjaalton> the downside is that the conf snippets would move to /usr/share/X11/xorg.conf.d, but that can be done with Breaks and bumping the serverminver
<bryceh> tjaalton, getting a bit late for such changes, no?
<tjaalton> bryceh: yes
<tjaalton> but it's basically a bugfix
<tjaalton> pointed out on the ffe
<bryceh> looks like uploads are now being blocked and require archive admin approval to get in
<tjaalton> already?
<tjaalton> well, that doesn't mateer
<tjaalton> *matter
<bryceh> subject: [ubuntu/lucid] xorg-server 2:1.7.6-2ubuntu4 (Waiting for approval)
<tjaalton> ok
<bryceh> hi seb128
<seb128> hey bryceh
<bryceh> tjaalton, any thoughts on these two patches?
<bryceh> make lvds modesetting more robust (upstreamed for 2.11, still applies to 2.9.1)
<bryceh> http://cvs.fedoraproject.org/viewvc/F-12/xorg-x11-drv-intel/lvds-modes.patch?revision=1.2&content-type=text%2Fplain&view=co
<bryceh> ati:
<bryceh> Fix default mode setup for invalid edid's
<bryceh> http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-drv-ati/radeon-6.12.2-lvds-default-modes.patch?view=markup
<tjaalton> bryceh: 2.11.0 is released, does it have that?
<tjaalton> looks like it
<tjaalton> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7d0e6ff4dadcf243b1006ce6f85bd06c5f4e4908
<tjaalton> surprised that the ati one isn't upstream
<RAOF> That looks like sound reasoning on the ati patch.
<tjaalton> heh
<tjaalton> maybe it's less useful with ati kms
<tjaalton> ?
<RAOF> Maybe.  IIUC the DDX should be able to bend kms to its will - adding modes, etc.
<RAOF> So while your boot -> X experience would be of an undriven display, once X started you'd get a suboptimal mode, but at least you'd get something.
<tjaalton> ok
<RAOF> I'm not sure if that's what the patch would *do*, but it's certainly possible.  Userspace can definitely add modes (at least for nouveau; I haven't tested radeon).  I can do so via xrandr.
<tjaalton> right, different from setting the initial mode
<tjaalton> bryceh: err, patch 115 is garbage
<tjaalton> html
<tjaalton> well, all of the new ones are
<tjaalton> git show ftw
<tjaalton> and having the upstream remote to make that work
<bryceh> bleah, I fixed that in the upload
<tjaalton> ah, good :)
<bryceh> this whole thing of using git for maintaining the packaging is like the most irritating thing to me
<tjaalton> bzr is no different
<tjaalton> or any other dvcs
<bryceh> well it's not like we actually *use* the vcs
<bryceh> we still have each of the patches done in quilt, so it's sort of like we're using one vcs inside another
<RAOF> I think that's silly, yes.
<seb128> how would you want to do it otherwise?
<tjaalton> it would quickly become a mess
<bryceh> I mean it's like washing the dishes before putting them in the dishwasher
<tjaalton> though upstream patches from the branch we're following should be fine to cherry-pick as is
<seb128> the only issue is quilt, would be much nicer if dpatch or simple-patchsys was used ;-)
<tjaalton> bah
<tjaalton> quilt is fine
<seb128> I hate it
<tjaalton> i hate dpatch, so here we go :)
<seb128> it's so annoying to use and slow and getting in your way
<seb128> I always forget to quilt add
<seb128> do my changes
<RAOF> Yeah.  That part is weird.
<seb128> and go "ups", need to scratch the whole dir and start again
<seb128> I'm probably too stupid to use it
<tjaalton> or just do your stuff, git diff > foo.diff and add it to series
<seb128> that's what I tend to do
<seb128> so you don't use quilt :-p
<tjaalton> unless it interferes with other patches, of course
<seb128> I can do that with simple-patchsys too
<bryceh> seb128, that's pretty much what I do too.
<seb128> I tend to quilt push the change before the one I want to edit
<seb128> and then copy the dir
<seb128> do my change
<seb128> and diff
<seb128> not to mention you have to export QUILT_PATCHES to be able to edit a patch
<tjaalton> that's in .quiltrc already ;)
<seb128> it shows how much the thing is meant to be used to do packaging, if you don't export environment variables you need to know about it doesn't work
<seb128> way to lower the work to start contributing
<seb128> anyway enough rant on quilt ;-)
<tjaalton> bryceh: funny how your commits show as merges while there were no changes to be merged, it should've been a direct push
<tjaalton> and conflicts in changelog
<bryceh> it's because of asac's commit
<tjaalton> no I already had that
<bryceh> I didn't
<tjaalton> these were after your latest push
<tjaalton> oh
<tjaalton> well always git pull before you start :)
<bryceh> see, now...
<bryceh> #insert git rant #14
<tjaalton> s/git/$DVCS/?
<bryceh> tools should *save* you work, not add extra steps for no real value
<tjaalton> oh there's valuea
<tjaalton> -a
<Ng> rebase \o/
<tjaalton> now I should get that release from the queue to work on it
<tjaalton> if it wasn't behind dvcs
<bryceh> tjaalton, you'd have to remind me what the value was
<bryceh> for me it's mostly just making me feel like an asshole for not pulling and pushing all the time
<tjaalton> bryceh: it's a team effort, no other way around it
<bryceh> tjaalton, yeah and I suck it up and do the git stuff, I still see no value in it
<tjaalton> so it would be better to just have the archive as the version storage?
<tjaalton> and do apt-get source; <stuff>; dput?
<bryceh> yep
<tjaalton> hrm :)
<tjaalton> that's probably fine for a one-man-team :)
<bryceh> well it's not like we do a huge amount of development on the packages
<RAOF> If we replace that with $VCS $BRANCH ; <stuff> ; $VCS $PUSH (as source-package-branches is moving to?)
<bryceh> tjaalton, well a lot of packages are basically just that
<bryceh> tjaalton, or maybe one person does the merge, and another person does most of the patch work until the next merge
<tjaalton> and I'd rather not do a merge by hand
<tjaalton> anymore
<bryceh> and doesn't it seem like on the packages where we *do* work together that we're constantly having to either bug someone to push a commit, or doing it for them?
<tjaalton> things just move too fast
<tjaalton> like having several uploads of the same package on the same day...
<tjaalton> having to merge the changes of an upload or a few per release is a price i'm willing to pay
<tjaalton> it's only a few minutes of work
<mvo> seb128: edit-patch!
<seb128> mvo, ;-)
<seb128> I need to try that one day
<mvo> if you hate quilt, try it next time you need to do somethingwith quilt
<mvo> it should just work
<mvo> (unless there are bugs of course ;)
<seb128> cool
<seb128> I know who to bug about bugs :p
<mvo> hehehe
<mvo> and it inegrates with $vcs of choice, so no more "ups, forget to bzr/git add that one"
<Dr_Jakob> Anyway I can get the Lucid installer to either not try to update itself or get it to use a proxy to do it.
<bryceh> Dr_Jakob, sure you have the right channel?
<Dr_Jakob> Heh, sorry.
<mvo> tseliot: hm, I got three warnings via debconf that I should install nvidia-current on my system (lucid -> lucid upgrade)
<tseliot> mvo: one for nvidia-common, one for the kernel and one for the headers, I guess
<mvo> probably
<mvo> I assume the releae upgrader will deal with that automatically via the nvidia-common import and the nvidia.old_drivers check?
<mvo> tseliot: or is there additional code needed?
<tseliot> mvo: yes, update-manager should deal with that, therefore we should not get those warnings in a dist-upgrade from u-m. You would still be bugged if you updated from the command line though
<tseliot> mvo: assuming that what I remember about update-manager is correct
<Sarvatt> Dr_Jakob: you were right btw, archive -dbg packages for mesa and xserver are screwed up, the -dbgsym packages all work though
<Dr_Jakob> Sarvatt: ah ok
<Sarvatt> I was using everything from a PPA and they strip them differently there so they worked
<Dr_Jakob> Heh okay
<Dr_Jakob> Do I need to switch to PPA or have never versions been uploaded?
<Dr_Jakob> well for me me the dbgsym packages where empty..
<Sarvatt> just purge the -dbg and -dbgsym packages you might have installed and reinstall just the -dbgsym
<Sarvatt> no reboots or anything needed that I was saying before
<Sarvatt> its just X related packages it looks like
<Sarvatt> http://sarvatt.com/downloads/dbgsym.py -- if you run that with say ./dbgsym.py /usr/bin/Xorg it'll tell you every dbg package with wrong CRC's
<seb128> Sarvatt, oh, handy
<Sarvatt> well every file in /usr/lib/debug/ with wrong CRC's that is
<Sarvatt> i need to file a bug about this, trying to find packages that have -dbg that work right to compare the build rules
<seb128> Sarvatt, it assumes rpm though?!
<seb128>     dpkg_output = commands.getoutput("rpm -qf "+debug_file)
<Dr_Jakob> Reading symbols from /usr/lib/xorg/modules/libvgahw.so...Reading symbols from /usr/lib/debug/usr/lib/xorg/modules/libvgahw.so...(no debugging symbols found)...done.
<Sarvatt> thats just for one of the command line options
<Dr_Jakob> Need to get 7,972B of archives.
<Dr_Jakob> After this operation, 164kB of additional disk space will be used.
<Dr_Jakob> dbgsym is still "empty"
<Sarvatt> you did a sudo apt-get purge xserver-xorg-core-dbg xserver-xorg-core-dbgsym first?
<Dr_Jakob> dbgsym wasn't installed
<Dr_Jakob> and I removed -dbg before.
<Sarvatt> ok I'm sorry, I swear I tested that last night
<Sarvatt>         dh_strip -pxserver-xorg-core --dbg-package=xserver-xorg-core-dbg
<Sarvatt>         dh_strip -s --remaining-packages
<Sarvatt> hmm
<Dr_Jakob> Sarvatt: sorry to ask this but do you have a ETA on when the issue would be resolved?
<Dr_Jakob> Or should I just compile X by hand or switch to PPA?
<herman_> hi how can I adjust the contrast of my lcd notebook, my video is an intel X4500
<herman_> is there some software that i can do that?
<Sarvatt> bryceh: did you see xorg-server 2:1.7.6-2ubuntu4 failed to build because of 115 still?
<Sarvatt> Dr_Jakob: no idea on an ETA unfortunately, compiling by hand will definitely work for now, just apt-get source xorg-server, cd xorg-server-foo, sudo apt-get build-dep xorg-server then debuild -uc -us -b
<Dr_Jakob> ok thanks
<Sarvatt> sorry about that :( i'll let you know as soon as its fixed
<Dr_Jakob> Right thanks.
<Dr_Jakob> I can image things are hectic right now.
<Dr_Jakob> Errm, it doesn't build due to what I assume is patch 115?
<Dr_Jakob> "Patch 115_xext_fix_cursor_ref_counting.patch does not apply (enforce with -f)"
<jcristau> kill it from debian/patches/series
<Dr_Jakob> jcristau: thanks
<Sarvatt> something in the build changes since 1.6.x screwed up the debug symbol extraction with pkg-create-dbgsym that creates the ddeb's - http://ddebs.ubuntu.com/pool/main/x/xorg-server/
<jcristau> Sarvatt: would that explain that the -dbg themselves get screwed up?
<Sarvatt> yeah it has to be pkg-create-dbgsym I believe because it works fine on PPA (where pkg-create-dbgsym is skipped) and self built packages without it installed, archive packages get run through pkg-create-dbgsym to make the ddebs and i dont think its handling the dh_strip rules right
<Sarvatt> -dbg works fine when not run through pkg-create-dbgsym I mean
<jcristau> ah right
<Dr_Jakob> Sarvatt: 115, 116, 117, 118 where all broken.
<Sarvatt> plus -dbg is screwed up in mesa as well but the ddeb from pkg-create-dbgsym work in that case, just not xorg-server
<Sarvatt> Dr_Jakob: sorry about that, you grabbed the source for a screwed up upload thats waiting for approval to be fixed I believe
<Dr_Jakob> ah ok
<Sarvatt> sorry for all of the pain :)
<Dr_Jakob> Well I still have to fix bug 545298
<ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [Undecided,Incomplete] https://launchpad.net/bugs/545298
<Sarvatt> ok got a bug here about the -dbg problems https://bugs.edge.launchpad.net/ubuntu/+source/pkg-create-dbgsym/+bug/562418
<ubottu> Launchpad bug 562418 in xorg-server "xserver-xorg-core-dbg debug symbols mismatch" [Undecided,Incomplete]
<Dr_Jakob> ok thanks
<jcristau> bryceh: your xorg-server commit seems to have changed nothing but changelog
<jcristau> the "Update patches in previous upload to fix FTBS issue" one
<bryceh> jcristau, commit b1bebad6 was the one that fixed the patches
<jcristau> heh ok
<jcristau> was confused when seeing that commit mail :)
<bryceh> jcristau, yeah for as simple as the patches were I totally fucked up the upload.  Dunno why, I've been cherrypicking patches all month.
<bdmurray> bryceh: I have had my system lock up on me 2 times today and I found this in my Xorg.1.log - http://pastebin.osuosl.org/32447
<bryceh> bdmurray, hmm, were you able to find any other bug reports reporting that error message?
<bdmurray> bryceh: I haven't looked in the hopes you'd had them all memorized
<bryceh> bdmurray, it's nothing I recognize offhand
<bdmurray> bryceh: cool, cause I was looking at the wrong log.  sorry about that
<bryceh>             if (ioctl(xf86Info.consoleFd, VT_WAITACTIVE, xf86Info.vtno) < 0)
<bryceh>                 FatalError("xf86OpenConsole: VT_WAITACTIVE failed: %s\n",
<bryceh>                            strerror(errno));
<bryceh> that's the code producing the error, it's in lnx_init.c in the xserver
<bryceh> pretty sure we've not done any changes on the X side which would affect that code path
<bryceh> my guess is it's something lower level than X, since it's just trying to open a VT
<bdmurray> bryceh: that was really really old
<bdmurray> the log I was looking at
<bryceh> oh
<bryceh> huh, you've got me confused.  I need coffee.
<bdmurray> My system has exploded a couple of times today but not related to that error message
<bryceh> ok, well see the troubleshooting docs to narrow the problem down
<bdmurray> right its a full system lock up though I have to power cycle it
<bryceh> kernel panic?
<bryceh> no ssh?
<bdmurray> yeah, no ssh and not able to ping so really probably the kernel
<bryceh> yep
<bryceh> X failures don't take down the network
<tormod> bdmurray, just in general, netconsole can sometimes show some messages which otherwise do not reach the filesystem before crashes
<bdmurray> tormod: How can I set that up?
<tormod> bdmurray, https://wiki.ubuntu.com/KernelTeam/Netconsole
<jcristau> Documentation/networking/netconsole.txt in the kernel source has instructions
<bdmurray> okay this is happening right now - http://pastebin.osuosl.org/32450
<bdmurray> I was able to ssh in this time
<jcristau> heh, gpu reset every .04s
<bdmurray> yeah the monitors are cycling through some garbage
<bdmurray> Is there anything I should get before rebooting?
<jcristau> i'd take it to #radeon
<jcristau> they might have a clue what's going on
<stanley_> Hi guys I am in some serious trouble here...my cursor won;t work it just froze and even after a restart won't do anything once I log into my profile...at the login screen it does, but once I log into my profile it just stops working
<kklimonda> hey, is installation of NVIDIA X drivers from their .pkg installer supported in 10.04 yet?
<bjsnider> no, and it won't be
<kklimonda> thanks
<bjsnider> that would pooch the xorg/mesa system
<tormod> stanley_, try log in with Failsafe Terminal / session / xterm or whatever they call it
<stanley_> ok...then do what?
<tormod> stanley_, is your  cursor fine there?
<stanley_> yes it is
<stanley_> works great everywhere except when i log into my profile
<tormod> stanley_, what graphics card and driver?
<stanley_> I am not sure what driver, but I have an NVIDIA GeForce Go 6150 (UMA)
<stanley_> If i log into another profile the cursor works fine...
<stanley_> it there something I could reset in my profile to fix this or something I should reinstall?
<tormod> stanley_, did you change Desktop Effects settings in your profile?
<stanley_> Thanks for all your help man, it literally hasn't worked all day and I guess just decided it will start working again now
<Sarvatt> bdmurray: what GPU? what kernel version? try booting with pci=nomsi?
<bdmurray> Sarvatt: I've trying to report the bug to Launchpad at the moment - getting OOPses though
<bdmurray> Sarvatt: I finally got bug 564181 reported
<ubottu> Launchpad bug 564181 in xserver-xorg-video-ati "GPU soft reset infinite loop" [Undecided,New] https://launchpad.net/bugs/564181
<Sarvatt> yep bdmurray try booting with pci=nomsi
<bdmurray> Sarvatt: is this specific to 2.6.32-21?
<Sarvatt> you bug is?
<Sarvatt> ah hah you have a XFX RV730 too
<bdmurray> I had not seen this before this kernel.  So is the boot option specific to this kernel?
<Sarvatt> darn the XFX rv730 quirk upstream doesn't look related - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=efa8450f6c93c9d4c99adfea2f52f1d02d878d5b
<Sarvatt> if it's new to 2.6.32-21 thats definitely interesting
<Sarvatt> the pci=nomsi probably doesn't apply, I thought that was an IGP card
<Sarvatt> quite a bunch of those getting the same exact errors without disabling MSI
<tormod> the MSI troubles, are they limited to x86_64?
<bdmurray> Is there some better test case than using googleearth?
<bdmurray> I mean is there something similar to googleearth that would be better for recreating the bug
<jcristau> there isn't a generic "make my gpu hang" test-case i don't think :)
<jcristau> depends on the particular bug
<bryceh> jcristau, well there is gem_hang  ;-) ;-)
<jcristau> hehe
<bryceh> bdmurray, mdz did a tool which we used to help trigger freezes on intel back in jaunty/karmic you could dig up
<bryceh> bdmurray, found it - http://launchpadlibrarian.net/25683477/repro.sh
<bryceh> bdmurray, the use cases that script exercises may not be relevant for your particular freeze but better than nothing
<bryceh> bdmurray, back in jaunty we used that to help make some of the freeze bugs happen faster, for verification purposes.  YMMV.
<bdmurray> bryceh: I can make it happen very quickly!  I was just thinking that googleearth was not the most accessible test case. ;-)
<bryceh> if it happens quickly, it's probably a decent test case
<bryceh> sometimes a 3D game or flash website will trigger bugs in a similar way as googleearth, but like jcristau says often the hangs are pretty situational
<bdmurray> bryceh: so would getting a gdb backtrace be useful in this case?
<bryceh> not really
<bryceh> freezes tend to give stack traces that just show it's stuck waiting on the gpu
<bryceh> which is like, duh ;-)
<bryceh> bdmurray, what generally tends to be needed is a gpu dump - see the freeze page in X/Troubleshooting 
<bryceh> basically you run the reg dumper thingee to get a register dump, and also snag the error file from sysfs
<jcristau> radeon has that too?
 * jcristau is less familiar with it than with intel
<bryceh> jcristau, yep
<jcristau> cool
<bryceh> jcristau, there's two tools actually, one for pre-R500 and one for R500 and newer
<jcristau> i meant the error state in sysfs
<bryceh> oh, that I am not sure of, I think they may not have that yet
<jcristau> ok
<jcristau> thanks :)
<bryceh> at least, it's not been something I've been told to collect from people
<bdmurray> bryceh: I don't see anything about radeon freezes on that page - https://wiki.ubuntu.com/X/Troubleshooting/Freeze
<bryceh> page needs updated...  Well the directions are also at https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen - scan for 'Register Dumps for -ati"
<bdmurray> bryceh: hrm, I've only been able to ssh into 1 time when it was hung
<bryceh> bdmurray, tried with ethernet?
<bryceh> bdmurray, when a system is frozen to the point that it's not ssh-able, it starts to smell kernel-ish
<bryceh> but you could try sshing in and running top prior to triggering the bug, and see if the issue is caused driving the cpu load
<bryceh> or tail -f on kernel logs to see if it issues any error messages before locking up
<bdmurray> bryceh: I've updated the bug with the output I received from netconsole
<bryceh> bdmurray, ok
<bdmurray> don't get too excited!
<bryceh> heh
<Sarvatt> bdmurray: can you try booting with radeon.dynclks=0 added to the grub kernel command line?
#ubuntu-x 2010-04-16
<Sarvatt> bdmurray: http://bugs.freedesktop.org/show_bug.cgi?id=26887
<ubottu> Freedesktop bug 26887 in DRM/Radeon "fence errors with rs785 and kernel 2.6.33" [Critical,New]
<bdmurray> will do shortly thanks
<Sarvatt> if that works thats something to add to the notes for sure
<Sarvatt> someone else had that problem a month or two ago (vish I think?)
<bryceh> bdmurray, have you noticed these freezes prior to today?
<bdmurray> bryceh: no not at all
<bryceh> bdmurray, do you update daily?
<bdmurray> bryceh: pretty close
<bryceh> bdmurray, there was one update to -ati today, although I think it wouldn't cause any user-noticeable effect, it just drops an unnecessary config file
<bryceh> bdmurray, but it would be helpful if you could downgrade to 1:6.13.0-1ubuntu1 which would rule out that and another change
<bryceh> my guess is you'll still be able to repro it
<Sarvatt> yeah theres absolutely no way that has an affect on what he's getting, the 6.12.192-6.13 uprade on the other hand..
<bdmurray> we need some what was updated on my system in the last update tool
<bryceh> yeah
<Sarvatt> yeah a graphical apt log viewer that shows the history and condenses the info sure would be nice
<bdmurray> it'd need to show apt and update-manager stuff
<bryceh> /var/log/dpkg.log shows this info, so as a first order you can look in it
<bdmurray> synaptic has some strangely incomplete history
<Sarvatt> someone poke someone interested in making stuff with quickly or something :)
<bryceh> bdmurray, I've listed out in the bug several X packages which have changed recently that could be worth testing downgrades
<bryceh> I reviewed the changes for each and nothing lept out at me as likely to cause this problem
<bryceh> but then, I wouldn't have included the patches if I could spot an obvious problem with htem ;-)
<Sarvatt> bdmurray: did you try the dynclks change?
<bdmurray> Sarvatt: no, doing that now
<bdmurray> Sarvatt: it hasn't crashed yet
<Sarvatt> good idea, saying that always makes it happen :)
<bryceh> heh
<bdmurray> yeah it finally barfed again
<Sarvatt> wow, you've gotta be kidding me.. looking through server motherboards to see what the common GPU's are there these days and.. matrox g200?!
<Sarvatt> i had one of those before linux kernel 1.0! :)
<Sarvatt> the large number of boards with XGI gpu's confuses me, guess thats where they disappeared to
<vish> Sarvatt: freezes in compiz? i read the backlog , but i dont understand what bdmurray is mentioning , does the system become slow to respond?  that i what I'v been experiencing, for a month
<vish> what i do is restart compiz and everything gets back to normal.. IMO , doesnt seem like a compiz bug , but i dont know where to report it as it is random and i didnt have anything getting logged :( 
<bdmurray> vish: what I was mentioning is a total system crash
<bdmurray> bryceh: I've narrowed it down
<Sarvatt> vish: lots of fence timeouts and soft lockups
<Sarvatt> vish: http://www.google.com/search?sourceid=chrome&client=ubuntu&channel=cs&ie=UTF-8&q=vish+going+to+reset+gpu :D
<Sarvatt> (first result)
<Sarvatt> yours looks really different looking at that though
<Sarvatt> bdmurray: so xserver-xorg-video-ati 1:6.12.192-2ubuntu2 is working ok but 6.13 isn't?
<vish> hehe , pastebin and google bad ;p
<vish> Sarvatt: btw , how do i workaround the memory bug in ATI ?  Bug 563400 , i dont seem to have the option for BO reuse in driconf
<ubottu> Launchpad bug 563400 in xserver-xorg-video-intel "Playing flash video causes memory hogging" [Undecided,Confirmed] https://launchpad.net/bugs/563400
<Sarvatt> yeah thats an intel thing
<Sarvatt> i have no idea
<Sarvatt> sudo apt-get purge adobe-flash would work :D
<vish> ;p
<Sarvatt> will keep an eye out about it though
<Sarvatt> it's only in chromium here
<Sarvatt> well chrome too
<vish> hmm ,happens here in firefox and chrome[ium]
<Sarvatt> haven't worked out running chromium through valgrind yet, darn wrappers
<vish> Sarvatt: also having this bug > http://www.youtube.com/watch?v=C_ozjS55mW8  , i should file this in xserver-xorg-video-ati  or mesa?
<vish> if i log into a second account its like a disco ;)
<Sarvatt> hmm what GPU again?
<Sarvatt> rv515 maybe?
<Sarvatt> or rv530
<Sarvatt> vish: if its either of those boot radeon.newpll=0
<vish> i think it is rv530 ..
<Sarvatt> looks like the pll rework stuff we pulled in isn't exactly fixing things, some people on rv515 and rv530 were getting what you see there on first boot for awhile but now its just guest sessions
<vish> or rv515
<vish> Sarvatt: how do i check the GPU?
<Sarvatt> yeah all of the bugs closed about flickering on both of those chipsets because of newpll=1 have people saying thats happening with guest sessions now
<Sarvatt> vish: grep PCI: /var/log/Xorg.0.log
<vish> weird : $ grep PCI: /var/log/Xorg.0.log
<vish> (--) PCI:*(0:1:0:0) 1002:7145:1025:0094 ATI Technologies Inc Radeon Mobility X1400 rev 0, Mem @ 0xd0000000/134217728, 0xc8100000/65536, I/O @ 0x00002000/256, BIOS @ 0x????????/131072
<Sarvatt> yep thats a RV515
 * vish scratches head
<vish> Sarvatt: how did you find that?
<Sarvatt> there were tons of reports with that same pci id :) there's a list here though - http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/ati_pciids_gen.h
<vish> ah :D
<Sarvatt> 1002 is ati, 7145 is the product id on that list
<vish> neat , thanks..
<Sarvatt> interested in hearing if radeon.newpll=0 fixes it for you too though
<Sarvatt> bryceh: has anyone contacted you about these synaptics ClickPad patches?
<Sarvatt> oh tseliot closed the -synaptics task...
<Sarvatt> ah found the bug, i thought it was odd the kernel support was brought in this late but not the userspace side but it makes sense now, at least they get 1 button with just the kernel side :)
<RAOF> What signal does X die with when it dies with an EQ overflow?
<RAOF> Or do I just get the reporter to set a breakpoint in xorg_backtrace?  I guess that'd work.
<Sarvatt> RAOF: same bug on a NVA5 - http://bugs.freedesktop.org/show_bug.cgi?id=26980#attach_33897
<ubottu> Freedesktop bug 26980 in Driver/nouveau "GT230M/nouveau: X server hangs spontaneously" [Normal,New]
<RAOF> Sarvatt: Right.  I was looking for a backtrace, because there appear to be at least three separate bugs there.
<RAOF> (I mean, there are three separate fedora bugs that it could be)
<RAOF> Every time I interact with a bugzilla instance I appreciate launchpad just a little bit more.
<Sarvatt> well its not https://bugzilla.redhat.com/show_bug.cgi?id=566987 since we dont even have pcie aspm enabled
<ubottu> bugzilla.redhat.com bug 566987 in xorg-x11-drv-nouveau "X freezes the clock stopped, keyboard seemed not to be responding, every so often the mouse would track but no response to clicks." [High,Assigned]
<RAOF> It's probably not https://bugzilla.redhat.com/show_bug.cgi?id=532579 either.
<RAOF> :)
<ubottu> bugzilla.redhat.com bug 532579 in xorg-x11-drv-nouveau "[nouveau] - X crashes before login: [Mat Booth] [9500 GT]" [High,Assigned]
<Sarvatt> argh, forgot to bump nouveau abi's for .21
<RAOF> You know what would make this easier?  Having a nouveau_gpu_dump tool like the intel ones.  This particular symptom apparrently means âthe GPU wedged somehowâ
<Sarvatt> copied the maverick 2.6.34-rc4 kernel into edgers, i'm about to pass out though so not going to get around to updating nouveau and figuring out how to require it
<Sarvatt> it's going to take 20+ hours to build on amd64 anyway
<RAOF> :)
<Sarvatt> just got some chromium codec updates so I think I can guess why :)
<RAOF> Chromium doesn't take *that* long to build, does it?
<RAOF> âª La la la la / la la la lai / all god's little children, the gotta die â«.  Nick Cave.  Such a happy dude.
<vish> Sarvatt: if i use  radeon.newpll=0   i get error [  10.019888] radeon: Unknown parameter `newpll'
<vish> and i cant start compiz :(
<Sarvatt> new_pll=0
<vish> oh , k.. 
 * vish tries
<Sarvatt> newpll=0 made it not load at all :)
<Sarvatt> sorry about that if i said that
<vish> hehe , yeah .. rebooting
<RAOF> It's a nice trick to *really* prevent the driver being loaded ;)
<vish> np.. :)
<vish> Sarvatt: yay , that does it , setting radeon.new_pll=0   solves the guest session problem :)
<vish> thanks..
<vish> Sarvatt: i think i got hit by bdmurray's bug , http://paste.ubuntu.com/415461/
<vish> everything just froze and i couldnt do anything :(
<vish> that happened with the new_pll=0 , or is this a different bug?
<vish> the error log just went on repeating and there is a huge log file with the repeat error
<bjsnider> what's the jockey-text command to select nvidia-current?
<bjsnider> tseliot, what happens if a guy is running the sudo jockey-text -e xorg:nvidia-current command and it is returning unkown driver?
<Sarvatt> its xorg:nvidia_current
 * tseliot nods
<bjsnider> he says it still returns unknown driver
<bjsnider> i noticed the description for nvidia-173 and 96 mentions vdpau
<bjsnider> tseliot, instead of using transitional packages, couldn't you use provides: conflicts: replaces: ?
<bjsnider> i mean for nvidia-current
<tseliot> bjsnider: those descriptions are wrong then
<tseliot> and no, conflicts/replaces won't work in this case
<bjsnider> it won't upgrade people?
<tseliot> in short, yes
<tseliot> make sure that nvidia-common is installed and then type "jockey-text -l" to see what's available
<bjsnider> he didn't have nvidia-common but he just installed it.
<bjsnider> does jockey run as a service? would he have to restart?
<tseliot> just close jockey and make sure that jockey-backend is not running any more, then launch jockey again
<Sarvatt> vish: thats not good, sounds like we have a serious regression recently then since you're on completely different hardware
<Sarvatt> bdmurray: did you say you dont have the problem using 6.12.192 but do with 6.13?
<vish> Sarvatt: yeah , everything was nice initially , only recently as we near release all new bugs seem to occur :(
<vish> even if GLmartix screensaver is running CPU usage just shoots up
<vish> rather, with any GL* screensaver
<vish> even if i preview from screensaver settings , the CPU spikes 
<bdmurray> Sarvatt: yes that is correct
<Sarvatt> vish: do you have time to mess with it? can you try downgrading -ati to 6.12.192-2ubuntu2 to see if its any different?
<vish> Sarvatt: downgrade ,by just downloading the 6.12.192-2ubuntu2 and installing it right?  i havent tried downgrading earlier
<Sarvatt> yeah
<Sarvatt> just that one package
<bdmurray> it might be in your /var/cache/apt/archives folder too
<vish> Sarvatt: ok , will do that in a bit , the freeze happened today once at random , but the CPU spike is constantly reproducible , will check it out
<Sarvatt> i dont see anything between 6.12.192 and 6.13 that should affect rv515 the same way :(
<Sarvatt> bryceh: 117_fix_crash_with_createglyphset.patch in xserver is the same as 110_findglyphbyhash-fix.patch
<Sarvatt> how the heck did they both apply
<Sarvatt> easily I guess - http://paste.ubuntu.com/415626/
<jcristau> yay for fuzzy patch applying :)
<Sarvatt> heads up that lbm-nouveau is now deprecated in xorg-edgers if anyone in here was using it, I'm uploading a xserver-xorg-video-nouveau package now that requires a 2.6.34 based kernel and there is one in the PPA that'll have to be manually installed (2.6.34-1-generic|preempt|generic-pae|whatever) and mainline kernels based on .34+ with the lucid config work also
<Duke`> wow I see updates on karmic too o/
<Sarvatt> i'm leaving all the old lbm-nouveau packages in the PPA so they are removed by ppa-purge properly and put a note on the main page about it
<Sarvatt> man, rs600 is in horrible shape  - http://lists.freedesktop.org/archives/dri-devel/2010-April/000094.html
<Sarvatt> i think dell latitude XT is the only laptop with it, haven't been able to find another.. lucid isn't bootable without disabling KMS currently on those
<Sarvatt> wiki says abit is the only one that released a motherboard with RS600 since AMD/ATI tried to clear all RS600 parts out of the market after the merger
<Sarvatt> bryceh: patch series that reverts all of the -ati accel stuff back to 6.12.192-2 status - http://sarvatt.com/downloads/radeon/
<vish> Sarvatt: it doesnt let me to downgrade , gdebi keeps saying "Error: A later version is already installed"
<bryceh> Sarvatt, thanks; do you think we need to go that far?
<bryceh> Sarvatt, and btw you're a mind-reader, I was *just* contemplating about doing this ;-)
<bryceh> sweeeet - http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=a69e749d0562887af6bd236c38802472e54640c4
<vish> hmm , is it safe to uninstall  xserver-xorg-video-ati first and then install the lower version, to downgrade?
<bryceh> vish, I've posted a ppa with the patches reverted - https://edge.launchpad.net/~bryceharrington/+archive/silver
<bryceh> vish, please test that
<bryceh> also note you can downgrade usually by just doing apt-get install foobar=1.2.3
<vish> bryceh: ah neat , thanks
<vish> hmm , the ppa has yet built :s 
<vish> and when i try ~$ sudo apt-get install xserver-xorg-video-ati=1:6.12.192-2ubuntu2
<vish> i get E: Version '1:6.12.192-2ubuntu2' for 'xserver-xorg-video-ati' was not found
<bryceh> vish, ah yeah I think the version has to be present in your apt cache in order to downgrade like that
<bryceh> anyway, the ppa should be built some time today, I'm sure the buildd's are bogged down with release stuff right now
<vish> i downloaded and added the deb to the cache as xserver-xorg-video-ati_1%3a6.12.192-2ubuntu2_i386.deb   but still it doesnt detect
<vish> well , i'll just wait 
<Sarvatt> vish just sudo dpkg -i xserver*.deb where you downloaded it
 * vish tries
<vish> yay, downgrading...
<Sarvatt> woohoo flight booked for UDS :)
<bryceh> Sarvatt, :-)
<vish> Sarvatt: i think the memory leak for my ATI happens for any video or any increased graphics usage.. i hadnt played any flash video files but still memory /swap 70% was used :(
<vish> is used*
 * vish reboots
<vish> bryceh: Sarvatt: downgrading, for sure , prevents high CPU usage by the GL* screensavers
 * vish now waits and watches an memory problems or  fence timeouts
<Sarvatt> google earth has been good at breaking radeon wonderfully for a few years now :D
<Sarvatt> oh sweet, thanks for pushing that ati with the reverts bryce, i was on the road and unable to so i just sent along the patches
<bryceh> Sarvatt, that was half th ework ;-)
<bryceh> actually I just pushed it to a ppa; I'd sort of like to get some indication that this is the right way to go before pushing it to lucid
<Sarvatt> yeah thats what I meant, i wanted to put it in a PPA but couldn't
<bryceh> go teamwork ;-)
<Sarvatt> I didn't create the patch series in the wrong order did I? :D
<bryceh> nope, they all applied just fine
<Sarvatt> oh nope it built, phew
<bryceh> yeah in reviewing that, it occurs to me that it was probably unwise for upstream to shove in so many performance reworking patches so close to their release
<Sarvatt> they pulled an intel :)
<bryceh> if it were me I would have held those back for putting in after the .0 release
<bryceh> these silly driver developers :-)
<bryceh> I don't even want to look at -intel right now
<Sarvatt> dont think i'd merge that ati uevent patch, the intel one causes lots of problems in fedora..
<bryceh> yeah no plans to
<Sarvatt> at least its upstream now though and likely to get fixed 
<vish> bryceh: your ppa is the same as xserver-xorg-video-ati 1:6.12.192-2ubuntu2  ?  or a  6.13 + patches  ?
<bryceh> looks like good xorg-edgers fodder though
<bryceh> vish, 6.13 - patches actually ;-)
<Sarvatt> vish: its 6.13+ extra fixes with just the sketcky stuff removed that was added between 6.12.192 and 6.13
<vish> hehe ;)
<bryceh> vish, it is close to 6.12.192 but has some additional upstream changes beyond that (which I think should be quite safe)
<vish> ah ok. , will test that too
<Sarvatt> i dont understand why 6.12.192-2 is fine for you too though vish, looked like those commits only affected r600+
<bryceh> Sarvatt, what's vish's card?
<vish> Sarvatt: not sure , but only since the .13 update this week  , i have been noticing the screensaver and the memory problems
<Sarvatt> rv515 (the flicker monster that hes having to use new_pll=0 on still)
<Sarvatt> only thing i can think of is those extra commits work right with exa from xserver 1.8 and not 1.7.x (fedora is backporting 1.8's exa even in F-12)
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/log/exa (all of the stuff from december on isn't in 1.7 branch just about)
<Sarvatt> vish: so it was hanging with the relocation errors for you too like bdmurray or was it just spewing that and not actually locking up on your rv515?
<Sarvatt> vish: are you on x64? have you tried bryce's PPA version if not? can you build the package yourself? it's pretty important that we get testing ASAP and theres about a 15 hour queue for x64
<Sarvatt> add the ppa and update, sudo apt-get build-dep xserver-xorg-video-ati, apt-get source xserver-xorg-video-ati, then cd to the directory and debuild -uc -us -b to build it
<Sarvatt> just dug out a machine to throw a HD2400 pro in but i wont be able to try it out until later over the weekend
<vish> i'm on 32bit , the freeze just locked everything , i couldnt do anything ..
<vish> i'v added the bryceh's ppa , but since it was still building , i was updating other stuff.. will do the above once the update is done
<Sarvatt> vish: 32 bit has been built for 2 hours, should be there whenever you are able to try it (and thanks for trying out all of these things) :)
<vish> Sarvatt: hehe! i was just about to ask you regarding a problem.. when i doing apt-get it pulled source from the main repos ;)
<vish> nvm , got the ppa now though :)
<vish> weird , didnt notice the ping so long :s
<Sarvatt> just pinged you a few minutes ago :)
<vish> yeah , i didnt notice it 7 mins earlier, probably was busy trying to figure out how to get the source from the ppa  ;)
<Sarvatt> no need to get the source now at least :)
<vish> yup , just installed , will reboot and keep you informed...
<vish> neat, with bryceh 's ppa , no problem of screensaver using high CPU..
<vish> will watch out for other memory or fence timeouts problems
<bryceh> vish, had you filed a bug report about your issue?  What's the lp#?
<vish> bryceh: i had filed a bug for the memory problem , but it might be unrelated to Sarvatt's BO reuse  > Bug 563400  , i notice the memory leak even without watching flash , havent filed a bug for the screensaver though
<ubottu> Launchpad bug 563400 in xserver-xorg-video-intel "Playing flash video causes memory hogging" [Undecided,Confirmed] https://launchpad.net/bugs/563400
<bryceh> vish, thanks
<vish> np..
<bryceh> uploaded to lucid
#ubuntu-x 2010-04-17
<rafiyr> Anyone know of an existing fix for evdev rotation?
<KiBi> rafiyr: mobile device?
<rafiyr> latitude XT (flip screen tablet)
<rafiyr> there's a scaling issue if you just twiddle the options with xinput
<rafiyr> I was just about to fix, but figured I'd check to see if its already been fixed first
<KiBi> ok; just wondering whether that might have had something to do wit some debian bug I just took care of (and no, nothing to do)
<ricotz> Sarvatt, hello, would it be worth it to include a patched "ia32-lib package" to enable opengl acceleration for nouveau with precomiled 32bit applications on 64bit systems (like google-earth)
<Sarvatt> ricotz: i dont do that because updating that massive monster every few days along with mesa is crazy :) yes its possible though,  note that it wont work with wine since thats hardcodes opengl vendor names
<ricotz> Sarvatt, i also thought so because of its size -- is it possible to create a package which overwrite some files on purpose and let the "broken" package be installed
<ricotz> so creating something like a "patch package" for ia32-lib
<Sarvatt> ricotz: have you tried updating ia32-libs before? its pretty easy, would be easier to just update it than do all that i'd think
<Sarvatt> its the fact that the main user for the 32 bit opengl wouldn't work anyway that stopped me from doing it, not enough time in the day to update all the rest of the stuff as it is but if you wanted to do it it'd be much appreciated
<Sarvatt> the radeon r600+ people would appreciate it too since r600 has a higher gl version in edgers than lucid
<ricotz> Sarvatt, yeah i think i could update it, but uploading 600mb is not possible for me :(
<Sarvatt> if i had the disk space on my vps to do it i'd set you up an account, but i'm already pushing my limits :(
<Sarvatt> bryceh: ugh, did you see? https://bugs.launchpad.net/bugs/564181
<ubottu> Launchpad bug 564181 in xserver-xorg-video-ati "[RV730] GPU soft reset infinite loop scrolling in firefox with compiz" [High,New]
<tormod> vish, would you be willing to bisect that memory hog issue on your X1400?
<vish> tormod: sure.. just a sec
<vish> tormod: hi.. i'm using the bryceh's ppa but still i dont think it is solved.. better but still a problem
 * vish waits for tormod's instructions :)
<tormod> vish, (sorry was afk) first, install git-core, and then the rest is well explained here: http://www.x.org/wiki/radeonhd#gitBisecting
<tormod> but start with git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
<tormod> vish, yes bryceh's ppa backed out a bunch of R6xx stuff, but you have an R500 card...
<vish> ok..
 * vish reads wiki instructions
<tormod> you might want to do a test build and verify the issue is there, before you start the bisecting
<vish> hmm weird , Xorg memory usage in sysmonitor stays nearly the same at 33.7Mib
<vish> but when i'm watching a flash video , and opening a lot of apps like inkscape and others , the swap starts to get eaten :s
<vish> tormod: is there any instructions for doing a test build?
<tormod> vish, just do the ./autogen.sh && make && sudo make install
<vish> righto..
<tormod> hmm maybe you have to run ./configure first, you'll see...
<tormod> (no forget configure, you're running autogen which calls configure)
<vish> tormod: i get the following error while building >  http://paste.ubuntu.com/416263/
<tormod> vish, you did install the build-dep packages?
<vish> tormod: hmm , no , i have to install  build-dep alone or any other packages?
<tormod> no, just run sudo apt-get build-dep xserver-xorg-video-ati
<vish> k..
<ricotz> Sarvatt, ping
<ricotz> perhaps you can give this a try https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1080802/+listing-archive-extra
<joaopinto> hi
#ubuntu-x 2010-04-18
<ripps> I think the Xorg slowdown is gone now, but it's been replaced with a pretty bad memory leak. Now my swap partition slowly fills up, even when I have no large apps open. It can fill my entire 2 gb partition in only a few hours.
<Sarvatt> server 1.8 branch in edgers now, or wait for MM to open and keep lucid on 1.7.x I wonder..
<Sarvatt> darn launchpad publisher got stuck not publishing libxdmcp and now theres a huge dep wait chain
<vish> ripps: you are using ATI?  i'm having the same problem
<vish> i have a 3.39GiB swap and sometimes it gets filled to 70% :s
<Sarvatt> i get it on intel too but only with chromium here
<Sarvatt> or chrome
<vish> Sarvatt: only with the flash video or any video?
<Sarvatt> flash is so invasive who knows
<vish> it sometimes happens even without flash.. but easier/quicker to do it with flash ... i use inkscape a lot and view a lot of image folders but still it is really getting bad :(
<Sarvatt> i dont go out of my way to watch videos though
<Sarvatt> valgrind inkscape?
<Sarvatt> guess you'd need to valgrind the server while running inkscape, thats fun
<vish> havent had an inkscape update in a long time.. and the problem persists even after i close the apps.. 
<Sarvatt> cat /sys/kernel/debug/dri/0/gem_objects wrapped over to negative numbers for you? :)
<vish> hmm , not yet , but i have seen negative numbers when my swap is getting rapidly filled
<vish> this is "ps aux" from last night >  http://paste.ubuntu.com/416321/
<vish> and after 10hr >  http://paste.ubuntu.com/416492/  and all i did was open inkscape once and play a couple of videos in vlc
<vish> $ free
<vish>              total       used       free     shared    buffers     cached
<vish> Mem:       2060208    1980144      80064          0      91052     503460
<vish> -/+ buffers/cache:    1385632     674576
<vish> Swap:      3550324       3612    3546712
<vish> thats free , swap is just starting ;)
<Sarvatt> hello cairo-dock
<vish> lol!
<vish> and that is slow right now , since i just had the system in idle and was probably using the sys only for ~1-2 hrs
<Sarvatt> i'd try turning that off to see if it's any better :)
<vish> will try that..  
<vish> need to use something else for window list
<Sarvatt> i dont see anything out of line besides that java maybe in those pastes?
<vish> Sarvatt: yeah , that java is vuze but it has always been that way , is uses 6% of ram usually
<vish> 6-7%
<vish> i have a conky running so i notice that and firefox always in the top 2
<Sarvatt> oh you're using cairo-dock in cairo mode, i was valgrinding it in gl
<vish> Sarvatt: yeah the open gl doenst work well, has some problems , i'm using the "cairo-dock -c"
<vish> Sarvatt: btw , i'm using their weekly ppa > https://launchpad.net/~cairo-dock-team/+archive/weekly/
<vish> hmm , i used the reload in synaptic [which usually shoots the X cpu usage] and swap just jumped to 22MIb from ~7
<vish> Bug #355355 is for the synaptic problem , but thats a different bug though
<ubottu> Launchpad bug 355355 in synaptic "Update Manager causes high Xorg CPU usage when checking for updates" [Medium,Confirmed] https://launchpad.net/bugs/355355
<ricotz> Sarvatt, are you still here?
<Sarvatt> yeah just waiting for the next publisher run before i pass out. how is that ia32-libs working out?
<ricotz> Sarvatt, my attempt is working great, so just download the packages on buildtime and one have a source of 100k
<Sarvatt> sweet! i'll copy it over as soon as all of these libs build, thanks for doing that
<ricotz> Sarvatt, only needs a rebuild on an update and everything is uptodate
<Sarvatt> OOPS-1569EC308
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1569EC308
<Sarvatt> boo, canonical only :) uess i'll just bump the version and reupload since i cant rebuild
<ricotz> Sarvatt, i could keep an eye on the ia32-lib package in the ppa if you add me to the team ;-)
<Laney> hiya
<Laney> so I just rebooted my Macbook running lucid, and noticed that the tap to click behaviour has changed
<Laney> two fingers now is middle click instead of right click
<vish> Laney: iirc , there was a huge flame war and it got changed ;)
 * vish finds bug#
<vish> Laney: Bug 432814
<Laney> oh, good
<ubottu> Launchpad bug 432814 in gnome-settings-daemon "Touchpad: Action for middle and right click is reversed since jaunty" [Low,Fix released] https://launchpad.net/bugs/432814
<Laney> since jaunty?
<Laney> the mind boggles
<vish> Laney: not sure , i never used it , but the tap was reversed and got changed back it seems
<Sarvatt> i'd say probably 90% of the synaptics bugs are just people complaining about the defaults :D
<vish> ;)
<Laney> I can't actually tell from that bug what happened
<Sarvatt> now its really the same as upstream so they can complain upstream :)
<Laney> too much text
<Laney> is it back to 2 fingers for right click now?
<tormod> some people should go to sleep soon ;)
<tormod> Sarvatt, are you preparing xorg-edgers for server 1.8?
<tormod> vish, from your ps aux I don't see that Xorg is eating memory
<Sarvatt> tormod: thinking about it, started updating libs just to get some of the xcb fixes so people could test and it'd be pretty easy to move to 1.8.x. not sure if we should do it for lucid or wait for mm to open in a few weeks
<\vish> oops !
<\vish> !test
<ubottu> hrm?
<tormod> I think there can be a lot of people wanting to try out latest X without upgrading (with no return option) to MM
<tormod> so you have my moral support :)
<Sarvatt> staying the heck away from 1.9 for now though, thats for sure
<Sarvatt> oh alrighty!
<tormod> oh I was thinking 1.9/master :)
<tormod> but once 1.8 is setup, throwing in master (once its ok) should be easy, no?
<\vish> tormod: hi did i miss anything after "] <tormod> vish, from your ps aux I don't see that Xorg is eating memory"  
<tormod> \vish, no
<Sarvatt> it'll just break and we'll have to update a crapload of package deps every update if we do master is what i'm worried about :)
<\vish> btw , this is the current one , now the swap is starting to be used , and i havent played flash video , will be doing that in a bit  http://paste.ubuntu.com/416561/
<\vish> and the gem_objects is still fine now , hasnt gotten negative >  http://paste.ubuntu.com/416563/
<tormod> well Xorg has grown from 36 to 56 MB, but that's not much compared to vuez and firefox and the other usual suspects
<Sarvatt> do you really have that much crap running all the time? :D
<\vish> hehe ;)
<\vish> Sarvatt: which ones  inkscape.. or ?
<\vish> btw , that is how i usually have the system running , this problem has been only for the past 10 days
<tormod> well that's one 1GB of gem object bytes
<tormod> Sarvatt, is that the kernel exploding?
<tormod> \vish, how much video RAM do you have?
<\vish> i think it is 512MB
<vish> tormod: how do i find that without rebooting and checking my bios?
<vish> video ram
<tormod> you should see it dmesg and Xorg.0.log
 * vish checks
<tormod> dmesg|grep VRAM
<vish> tormod: radeon: VRAM 128M   and radeon: GTT 512M
<tormod> I guess GTT includes memory that can be "borrowed" from system RAM
<Sarvatt> tormod: nice, xorg-edgers is annoying apparently :)
<Sarvatt> (xorg-devel)
<tormod> Sarvatt, you mean according to upstream with specific corporate affiliations?
<vish> might be "radeon: 512M of GTT memory ready."   it mentions "upto 512MB HyperMemory"
<tormod> I guess everything that makes people use something than Fedora is annoying
<tormod> *else than
<lapion> hello, anyone know how to set the value for hangtimer on i915, or even disabling it completely ?
<Sarvatt> need to recompile your kernel to change it
<vish> tormod: so. this is a kernel problem and not an X issue.. not needed to bisect the -ati  driver?
<Sarvatt> need to change the #define DRM_I915_HANGCHECK_PERIOD 75 line in drivers/gpu/drm/i915/i915_drv.h
<tormod> vish, well if another version of -ati makes a change, please do it
<vish> k..
<lapion> hmm can xserver add a timestamp to x.org.log ?
<tormod> vish, check if the gem object bytes number correlate with the swapping issue
<tormod> lapion, there are patches for it, but if you don't need high time resolution you can use some log stamper tools
<vish> tormod: the gem_object keeps increasing:  http://paste.ubuntu.com/416616/ 
<tormod> vish, you had a 71MB increase in used RAM (free, +/- buffers), can you track that with ps aux?
<vish> tormod: the ps aux now > http://paste.ubuntu.com/416619/   X has increased from  56804 > 58456 , looks like everything just keeps creaping up a bit
<vish> rrs  41316  >  43244
<vish> rss*
<lapion> tormod, thanks, working on compilation bit.
<lapion> I have not compiled under ubuntu yet.. only SuSE, redhat and slackware
<lapion> btw. in the recent update i955 was blacklisted was this done on kernel level ?
<tormod> lapion, yes the latest kernel update (see its changelog) blacklisted KMS for a number of 915 cards, so they will use UMS instead
<tormod> vish, but did you see some other app increase close to 71 MB over that time?
<vish> tormod: nope..
<lapion> hence the black screen I get with that kernel..
<vish> no single app gains[ed] memory like that
<tormod> lapion, so KMS worked for you, but now they forced broken UMS on you?
<lapion> well it worked but crashed after a long time.. usually if I had the processor running on native-clockspeed, when underclocked it could run for days.. it's my tv/relzax searchs ystrem\
<lapion> usually it would crash while tvtime was still active..
<lapion> hence the reason I think the hangcheck is a bit buggy
<lapion> git is go(o?)d !!
<tormod> (l)? ;)
<Sarvatt> tormod: ok protos all uploaded, will get a newer xserver in there when I wake up in a few hours :)
<Sarvatt> tormod: btw can you renew my membership? can't renew myself :)
<tormod> Sarvatt, cool! I guess updating many proto packages is not so much work as the rest (re the xorg-devel discussion)...
<lapion> tormod, linus'changelog or ubuntu-dev changelog ?
<tormod> lapion, ubuntu, /usr/share/doc/linux-image-2.6.32-21-generic/changelog.Debian.gz
<lapion> hmm can't find any patches in launchpad to find out what needs to be reversed
<tormod> lapion, are you building the kernel from ubuntu git?
<lapion> no kernel-source
<lapion> package
<tormod> anyway, I see only i8xx cards blacklisted, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary
<lapion> hmm of course I can allways enable kms at boot\
<lapion> btw tormod I have never had a hangcheck related crash while the processor was set to run at a clock speed lower then native clockspeed
<tjaalton> https://edge.launchpad.net/~tjaalton/+archive/test/+packages
<tjaalton> "the final merge" for lucid :)
<jcristau> hehe
<tjaalton> if slangasek accepts it of course
<tjaalton> wasn't completely refusing the idea when I asked..
<tjaalton> bryceh, Sarvatt: ^
<tjaalton> probably will say a thing or two about the new wacom & vmmouse
<bryceh> tjaalton, nice, will be interesting to see if slangasek accepts it this late in the release though
<tjaalton> bryceh: yeah
<tjaalton> there are options though..
<tjaalton> but they would be more work
<tjaalton> (if the goal would be to just allow having /etc/X11/xorg.conf.d as well)
<tjaalton> but we'll see
<tjaalton> hmm getting dark, enough work it seems and time to head home ->
<Sarvatt> hmm funky issue with the proto builds, I guess they all need a pkg-config dep now?
<Sarvatt> http://launchpadlibrarian.net/44676877/buildlog_ubuntu-lucid-i386.x11proto-core_7.0.16%2Bgit20100418.81c3cc1c-0ubuntu0sarvatt_FULLYBUILT.txt.gz
<Sarvatt> all the warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd lines in every one built on a PPA
<jcristau> yeah XORG_DEFAULT_OPTIONS does that.
<vish> is this something that can occur >  kernel: [78341.171633] radeon 0000:01:00.0: dadb8c00 reserve failed for wait
<vish> i notice such messages in the syslog
<Sarvatt> jcristau: should a pkg-config build dep be added to the build deps for all the protos or am I on the wrong track?
<jcristau> Sarvatt: i think you're on the right track :)
<Sarvatt> phew, wasn't sure if it was something funky because I updated xutils-dev with the newest tarballs
 * Sarvatt just woke up and isn't all with it :)
<Sarvatt> debian/rules get-tarballs rocks btw, thanks for that :)
<jcristau> np :)
<jcristau> was impossible to update those packages without at least some automation
<Sarvatt> wow 15 minutes to build a proto package on launchpad
<jcristau> 14'59 of them in autoreconf? :)
<Sarvatt> well its been 13 minutes and its not even at the autoreconf stage yet, i was just guessing around 15 :D
<Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+build/1698361
<Sarvatt> just updating all of the essential files took most of the time, build deps went fast
<Sarvatt> yeah like 30 seconds to do the actual build :)
 * Sarvatt kills launchpad uploading all the rest of the protos and libs
<Sarvatt> jcristau: so with this proto merge, the build deps on the world are going to have to change right?
<jcristau> Sarvatt: need to avoid that, either with provides or empty transitional packages
<Q-FUNK> re
<tjaalton> bryceh: the merged packages have been uploaded for review <thumbs up>
#ubuntu-x 2011-04-11
<RAOF> Prf_Jakob: It's not the size of the library that's the problem, it's that the nvidia libgl *dirties* ~5MiB of memory (on x86-64, apparently *more* on i386) on load.
<RAOF> albert23: Oh, really?  Yeah, that'd be right.  Gak!
 * RAOF wonders if multiarching mesa is acceptable at this point.  Probably not!
<RAOF> albert23: Got a bug filed about that?
<albert23> RAOF: sure, bug 755720
<ubot4> Launchpad bug 755720 in ia32-libs (Ubuntu) "32 bit dri drivers cannot find libdricore and libglsl (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/755720
<RAOF> Ta.  I'll fix that with (hopefully!) today's mesa upload.
<albert23> thanks
<bjsnider> RAOF, why wasn't that ever a problem before?
<RAOF> bjsnider: Possibly becuause no-one's tried it before?
<bjsnider> tried what?
<RAOF> Using the 32bit mesa on a 64bit system?
<RAOF> You'd mostly notice if you were using wine on x86-64, and the mesa libGL doesn't support wine very well.
<bjsnider> no, i meant the tmb of memory dirtied by the blob
<bjsnider> 5mb
<albert23> RAOF: btw, I tested your mesa 7.10.2 packages on ironlake and nouveau. Both doing fine. Even unity works on nouveau :-)
<RAOF> albert23: Thanks :)
<RAOF> bjsnider: Apparently that's a well-known, longstanding property of nvidia's libGL.  I just didn't know it :)
<bjsnider> RAOF, well, i don't know why you didn't, since it's open and well-documented, with an extremely robust public bug tracking system
<bjsnider> oh, and none of the code is shared between platforms.
<RAOF> Wait.  It's 10:30.  WHY ISN'T MY COFFEE MACHINE ON?!
<RAOF> Fun fact: chrpath on x86-64 doesn't understand IA32 objects.
<RAOF> Oh, this'll require an ia32-libs update, too, won't it.  Hm.
<tjaalton> RAOF: so, we need to upload what we want for natty within the next three hours :)
<tjaalton> or so
<tjaalton> which includes your mesa and xserver 1.10.1rc2?
<tjaalton> breakfast->
<RAOF> Someone had highlighted me before my IRC bouncer caught flames.  Was it tjaalton by any chance, offering to upload mesa?
<tjaalton> 08:07 < tjaalton> RAOF: so, we need to upload what we want for natty within the next three  hours :)
<tjaalton> 08:07 < tjaalton> or so
<tjaalton> 08:08 < tjaalton> which includes your mesa and xserver 1.10.1rc2?
<RAOF> Yes indeed.
<tjaalton> we would've uploaded mesa on friday, but you didn't push it to git :)
<RAOF> Yah, I saw.
<RAOF> It's done now, though, and available on http://cooperteam.net/Packages
<RAOF> With a bonus ia32-libs fix.
<tjaalton> i'll grab it
<RAOF> I've also got a nouveau upload staged, let me grab it.
<tjaalton> mesa uploaded
 * RAOF is somewhat disappointed how much more performant nouveau on his *netbook* is compared to intel on a reasonably beefy laptop.
<tjaalton> hehe
<tjaalton> bryceh_: about? was gonna ask about xserver patch 208 ("switch on release")
<RAOF> I'm always a fan of breaking the X protocol :)
<tjaalton> heh
<tjaalton> well, this might create issues for a11y
<RAOF> Nouveau's also up on cooperteam
<tjaalton> uploaded
<RAOF> Now let's see if I can't make DBO happy and fix X/libX11/libxcb
<tjaalton> what bug is it?
<RAOF> Bug #740126 - apparently it's fairly widespread and not WaitMSC specific.
<ubot4> Launchpad bug 740126 in compiz (Ubuntu) "compiz hangs randomly several times per day (affects: 3) (heat: 20)" [High,Incomplete] https://launchpad.net/bugs/740126
<tjaalton> hmh
<tjaalton> ooh, the libx11 commit you mentioned on #u-d would fix my vdr box issues
<RAOF> tjaalton: But that's in the libx11 1.4.2 upload that you've already done!
<tjaalton> RAOF: oh, good :P
<tjaalton> then the next yavdr release should get it
<RAOF> :)
<tjaalton> i'll upload xserver as-is
<seb128> bug #748487 seems to get some duplicates
<ubot4> Launchpad bug 748487 in xserver-xorg-video-nouveau (Ubuntu) "compiz assert failure: compiz: nouveau_context.c:260: nouveau_update_renderbuffers: Assertion `!ret' failed. (affects: 3) (dups: 6) (heat: 475)" [Medium,New] https://launchpad.net/bugs/748487
<seb128> not sure if it should be tracked in some way
<tjaalton> hmm, there was a mesa update pushed earlier today, I'll check if it has something nouveau'y in it
<seb128> tjaalton, thanks ;-)
<tjaalton> seb128: so far no hits. maybe it needs to be upstreamed then
<tjaalton> which I can take care of
<seb128> that would be nice
<seb128> well I don't have the issue since I'm on intel but since it got a few duplicates it would be nice to get upstreamed at least
<tjaalton> yep
<bdmurray> RAOF: is the ia32-libs task in bug 755720 still valid?
<ubot4> Launchpad bug 755720 in mesa (Ubuntu) (and 1 other project) "32 bit dri drivers cannot find libdricore and libglsl (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/755720
<Sarvatt__> bdmurray: yeah ia32-libs needs to be updated
<Sarvatt__> ScottK: did you have a launchpad bug for the corruption? I'm not seeing it
<ScottK> I did.  Let me find it.
<Sarvatt__> got a test package for you but need to put the bug # in the changelog
<ScottK> Sarvatt__: Bug #750964
<ubot4> Launchpad bug 750964 in xorg (Ubuntu) (and 1 other project) "Screen corruption in menus and titlebars (affects: 2) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/750964
<Sarvatt__> thanks a bunch, updated it with a PPA that has an xserver-xorg-video-intel with what should be the fix in it, would be much appreciated if you could test it. its a very small change at least
<ScottK> Will do.  
<Sarvatt__> nvidia 270.41.03 uploaded to x-updates if anyone was looking for it
<Sarvatt__> screwed up the maverick one, fixing that up now
<bjsnider> what does the changelog say?
<Sarvatt__> Fixed a bug causing the X server to hang every 49.7 days on 32-bit platforms. and a ton of new gpu support
<bjsnider> that's it?
<Sarvatt__> yep
<bjsnider> sounds like they're not even really working on it
<Sarvatt__> all the new gpu support took them a whole month to add, we have a ton of systems that were waiting on this updated driver to ship
<seb128> bug #757906 seems a frequent unity crash for intel users
<ubot4> Launchpad bug 757906 in unity (Ubuntu) "compiz assert failure: compiz: intel_tex_image.c:726: intelSetTexBuffer2: La declaraciÃ³n `!texImage->Data' no se cumple. (affects: 5) (dups: 4) (heat: 42)" [Medium,New] https://launchpad.net/bugs/757906
<seb128> if someone wants to have a look to it
<seb128> https://bugzilla.redhat.com/show_bug.cgi?id=681161 is similar
<ubot4> bugzilla.redhat.com bug 681161 in xorg-x11-drv-intel "[abrt] mutter-2.91.90-2.fc15: intelSetTexBuffer2: Process /usr/bin/mutter was killed by signal 6 (SIGABRT)" [Unspecified,New]
<seb128> https://bugs.freedesktop.org/show_bug.cgi?id=35234
<ubot4> Freedesktop bug 35234 in Drivers/DRI/i965 "mutter: intel_tex_image.c:726: intelSetTexBuffer2: Assertion `!texImage->Data' failed" [Major,New]
<Sarvatt__> ScottK: looks like it works, I've got packages prepared but need to figure out when its ok to upload with the freeze
<Sarvatt__> http://sarvatt.com/downloads/merges/intel-natty/
#ubuntu-x 2011-04-12
<Sarvatt__> hrm I'm not sure when it should go in, looks like main is frozen before beta freeze is lifted?
<Sarvatt__> RAOF: err, compiz memory leak happening with the nvidia blob too not just intel
<bjsnider> you got that right
<bjsnider> have to restart compiz every few hours
<RAOF> On alt-tab?
<Sarvatt__> sarvatt   1911  0.5  0.7 133924 30920 ?        Sl   Apr06  37:33 compiz is with the blob here, I never alt+tab
<bjsnider> neither do i
<Sarvatt__> was surprised the blob was doing it too though, rules out some of the places I was looking.. gonna need a valgrind
<RAOF> Is there a bug filed, and can you valgrind it?
<bjsnider> fixing cairo didn't help
<RAOF> Fixing cairo was never *meant* to help compiz
<RAOF> So we've got two known OMG bugs on the go, then :)
<Sarvatt__> I hit the min/max under compiz one a crapload and didn't realize it
<RAOF> The endless-waiting-in-_XReply one?
 * Sarvatt__ has a bad habit of min/maxing windows passing time :)
<Sarvatt__> yeah
<RAOF> Ok.  Make a coffee, finish fixing mono, track down crazy _XReply bug.
<Sarvatt__> bjsnider: do you use unity or a classic session?
<bjsnider> unity
<bjsnider> i thought that cairo was being run as a thread in compiz and with the cairo problem fixed the mem usage would be, but no joy
<RAOF> bjsnider: No, the cairo problem was a fixed 5MiB cost for every process that linked to cairo (ie: every GUI app).
<bjsnider> well, i think in my case looking at the numbers, compiz has been gobbling up lots of ram since i started using natty 2 weeks ago. the other processes are ok
<Sarvatt__> gonna try to look at it in the morning and wanted to be sure you were using unity, I sure as heck can't reproduce it with the blob on a classic session at least
<bjsnider> well, that narrows it down
<bjsnider> i can see compiz ending up at >500 mb after a few hours
<bjsnider> i don't have a swap file so i have to head that off before it goes too far
<ScottK> Sarvatt__: We won't unfreeze.  Go ahead and upload and the release team will figure out the best time to get it in.
<ScottK> Sarvatt__: I just uploaded it.
<ScottK> It's in queue for release team review.
<Sarvatt__> ScottK: thanks a ton for that
<ScottK> Sarvatt__: It's in.
<Sarvatt_> hrm got one http://paste.ubuntu.com/593017/
<Sarvatt_> just close the lid with g-p-m set to blank the screen under unity on intel
<Sarvatt_> comes back up in a weird state where you can interact with things partially but compiz is hung
<RAOF> Partially?
<Sarvatt_> yeah cursor is working, it changes when i hover over a resize area but cant change windows or anything
<RAOF> Right.
<Sarvatt_> i just attached gdb to compiz there while it was in that state
<RAOF> I *think* that's another manifestation of the same bug.
<RAOF> X is happily motoring along, compiz is sitting waiting for X to reply to its request.
<Sarvatt_> hmm either http://cgit.freedesktop.org/xcb/libxcb/commit/?id=f0565e8f06aadf760a9065a97b8cf5ab9cbd18de helped or I just got lucky being able to reproduce it 3 times in a row there earlier :)
<tjaalton> there was talk on the xcb list last month about a new release, but nothing came out of it, yet
<RAOF> sarvatt: Hm.  If I read that commit correctly it should result in compiz dying with an IO error.
<RAOF> Sarvatt_: Yeah; that'll result in the X connection being shut down, which compiz is unlikely to be happy with.
<RAOF> Sarvatt: If you want a nice reproducer, revert bzr r1091 from unity.  That'll make maximize kill things again ;)
<Sarvatt_> must just need to have it closed for a longer period of time to reproduce it then, had it closed >30 minutes each time before
<Sarvatt_> oh maximize is fixed now?
<Sarvatt_> woohoo
<RAOF> Yeah.  Well, worked around, at least.
<Sarvatt_> ugh, intels gonna need another upload now too
<Sarvatt_> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=686018f283f1d131073ef5917213e6a8ac013f26 fixing all the 915gm hangs
<seb128> could someone reassign, set bug settings as appropriate for bug #757906
<ubot4> Launchpad bug 757906 in unity (Ubuntu) "compiz assert failure: compiz: intel_tex_image.c:726: intelSetTexBuffer2: La declaraciÃ³n `!texImage->Data' no se cumple. (affects: 6) (dups: 6) (heat: 56)" [Medium,New] https://launchpad.net/bugs/757906
<tjaalton> seb128: done
<seb128> tjaalton, thanks
<seb128> tjaalton, I've dumped some similar bugs I found googling about the error in the comments
<seb128> not sure how useful they are though ;-)
<tjaalton> seb128: we'll see :)
<lool> Hey
<lool> syndaemon is using 100% here, even after logging out and back in; did anybody see this so far?
<lool> looks like https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/754470
<ubot4> Launchpad bug 754470 in xserver-xorg-input-synaptics (Ubuntu) "syndaemon consumes 100% CPU (affects: 31) (dups: 1) (heat: 150)" [Undecided,Confirmed]
<lool> cnd: ^
<cnd> lool, I haven't seen it
<cnd> I thought syndaemon was deprecated...
<cnd> I guess not since I'm running it :)
<Sarvatt> the disable touchpad while typing option in the gnome capplet uses it
<cnd> lool, can you install the dbgsym package and gdb it to see where it's stuck?
<lool> cnd: Actually I rebooted after a kernel upgrade and it doesn't happen for me anymore
<lool> I got it three times after logging out and killing it, but now that I rebooted it's gone
<lool> cnd: I'll gdb it if I reproduce though
<cnd> lool, ok, thanks!
<Sarvatt> updating libxcb is always an adventure.. https://launchpadlibrarian.net/69144345/buildlog_ubuntu-natty-i386.libxcb_1.7%2Bgit20110412.42c4adef-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> at least it doesnt need autoreconf patches refreshed every time now
<bryceh_> Sarvatt, did that -intel patch get taken care of by anyone already?  Should I roll up a ppa and solicit testers?
<Sarvatt> bryceh_: nope not yet, it'll need a bit of cleaning up for 2.14.0 because of has_kernel_flush
<bryceh_> ok
<bryceh_> Sarvatt, did everything get in yesterday that needed in?  mesa and whatnot?
<Sarvatt> bryceh_: yep!
<bryceh_> ok great
<tjaalton> i bought an esprimo v5535 with sis mirage 3+ (672) on it, oh my..
<bryceh_> tjaalton, get it for a good price?
<tjaalton> bryceh_: that would've meant "free" :)
<bryceh_> heh
<bryceh_> guess it'll keep you busy at least
<tjaalton> well, it's a bit faster than the old thinkpad t23, so once flash runs on it I'll pass it on to the kids
<bryceh_> I got an old via system hereabouts (one of those walmart PCs back when they were selling linux) 
<tjaalton> does openchrome work with it?
<bryceh_> unfortunately the cpu isn't well supported by the kernel so last I tested (which was a while ago) I couldn't even get it booting
<bryceh_> figure I'd need to roll my own kernel with a custom config.  maybe someday
<tjaalton> huh, that's.. bad
<tjaalton> via cpu?
<bryceh_> C3  iirc
<tjaalton> right, so the optimizations make it unbootable
<tjaalton> or the cpu family support in -generic
<bryceh_> yeah at the time I looked at it, it just needed a config setting that we don't include by default
<bryceh_> but even when it does work, the system is slow as snot
<tjaalton> hehe
<tjaalton> this one seems to be noisy
<tjaalton> the fan is on full blast even when idling
<bryceh_> ew
<tjaalton> i suspect overheating issues
<tjaalton> in the future
<bryceh_> hot gpu or does it just not support power modes?
<tjaalton> it was the same on win7
<bryceh_> ah
<tjaalton> i'll try with only the battery..
<bryceh_> it's crazy how many gpu's I've burned through so far working on X
<bryceh_> 4-5 I think
<bryceh_> (mainly ati)
<tjaalton> though seems like the live-session doesn't support cpu throttling
<tjaalton> oh, just overheated them?
<bryceh_> tjaalton, any theories on bug 747205?
<ubot4> Launchpad bug 747205 in libdrm (Ubuntu) (and 1 other project) "[arrandale] Black screen on all outputs when external VGA is connected (affects: 7) (dups: 2) (heat: 50)" [High,Triaged] https://launchpad.net/bugs/747205
<tjaalton> bryceh_: well, it's worse with compiz. but the register dumps are what ickle wants now
<tjaalton> i mean with metacity it's almost equally broken, just that you get back to normal by unplugging the monitor
<bryceh_> right
<BlackZ> hello, are nvidia drivers expected to be broken on natty?
<Sarvatt> only nvidia-173 and nvidia-96
<BlackZ> Sarvatt: I can't get my video card working with nvidia-current
<Sarvatt> what GPU is it? can ya describe how its broken? like can you not install the package at all?
<BlackZ> Sarvatt: nvidia geforce 7500 LE; I can't run the default Ubuntu desktop session (even unity doesn't run completely); I can successfully install the package and build the kernel module
<Sarvatt> BlackZ: yeah that one needs the nvidia-173 driver and not nvidia-current unfortunately :(
<Sarvatt> oh wait, I'm sorry
<bjsnider> no, it shuld work
<bjsnider> 6k and onwards
<bjsnider> BlackZ, have you got any crazy ppa add-ons?
<BlackZ> bjsnider: no, fresh natty install
<Sarvatt> BlackZ: can you pastebin a /var/log/Xorg.0.log (or .old) from a failed startup?
<BlackZ> Sarvatt: http://pastebin.ubuntu.com/593259/
<tjaalton> um, looks normal
<Sarvatt> yeah that looks fine, how about ~/.xsession-errors?
<BlackZ> Sarvatt: http://pastebin.ubuntu.com/593263/
<Sarvatt> sudo apt-get purge nvidia-173 for starters
<BlackZ> Sarvatt: it's not installed
<BlackZ> Sarvatt: however I have no problems at booting time; I have problems when starting a session in gdm (e.g. the default Ubuntu one)
<BlackZ> Sarvatt: if I use the nouveau drivers all works good
<Sarvatt> i'm not sure whats going on with your sessions there but it looks like the nvidia driver is working fine, do you have any packages missing by any chance? sudo apt-get install ubuntu-desktop offer to install anything?
<BlackZ> Sarvatt: no, it doesn't
<BlackZ> Sarvatt: however I only have this problem on natty; on maverick the proprietary nvidia drivers works good
<bjsnider> BlackZ, did you install all updates as of today?
<BlackZ> bjsnider: yes
<jcastro> Sarvatt: other than the occasional artifact in the dash the thinkpad X120E is running great with the open drivers, thanks for sorting out snagging the patch from upstream
<bjsnider> Sarvatt, how much ram would you say compiz should typically be using in natty?
<JanC> I think RAM usage depends on what plugins you have enabled and probably also on display size, number of workspaces, & such?
<bjsnider> JanC, right. in this case, it's just stock default unity
#ubuntu-x 2011-04-13
<bryceh_> RAOF, happen to know what the procedure is for switching between fglrx and ati?  The only howtos I ran across looked rather hairy (and a bit oldish)
<RAOF> bryceh_: IIUC the ati control panel has a button that you press.
<bryceh_> hmm, ok
<bryceh_> I suppose if people have problems we just point them at AMD...
<bryceh_> RAOF, btw sarvatt didn't think it'd be worth having people test that -intel patch quite yet
<RAOF> Ah, ok.
<bryceh_> <bryceh_> Sarvatt, did that -intel patch get taken care of by anyone already?  Should I roll up a ppa and solicit testers?
<bryceh_> <Sarvatt> bryceh_: nope not yet, it'll need a bit of cleaning up for 2.14.0 because of has_kernel_flush
<bjsnider> bryceh_, wouldn't jockey allow you to deactivate fglrx at which time you'd be using ati by default?
<Sarvatt> bryceh_: oh I just meant we're gonna need to backport the commit and cant just cherrypick it, we definitely do need to get it in I was just busy at the time
<Sarvatt> or we could just revert http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=cc930a37612341a1f2457adb339523c215879d82 :P
<Sarvatt> bryceh_: you mean like for the hybrid stuff in fglrx now? that runs on scripts we dont ship that rename libs.
<Sarvatt> (so it doesnt do anything)
<Sarvatt> its really incompatible with how we package fglrx, not sure whats going to happen with it but tseliot was discussing it with them and might have some info on it. they back up and replace the system libs when you pick ati and move things back when you want to switch to intel
<Sarvatt> it also doesnt work for switching between fglrx and ati, only for fglrx and intel hybrids
<bryceh_> Sarvatt, ok yeah I suspected this as the case
<mdeslaur> hmm...is it a known issue that with today's iso, jockey shows the nvidia driver as being installed, even though I am clearly using nouveau?
<tseliot> mdeslaur: what's the output of "jockey-text -l" ?
<mdeslaur> tseliot: it says "xorg:nvidia_current - blah blah (Proprietary, Enabled, In use)"
<Sarvatt> have you rebooted since installing it?
<mdeslaur> and underneath "xorg:nouveau - blah blah (Free, Disabled, Not in use)"
<Sarvatt> (stupid question but have to ask, sorry)
<mdeslaur> Sarvatt: yes
<tseliot> mdeslaur: what about the output of "update-alternatives --display gl_conf" ? (please put it on pastebin)
<mdeslaur> Sarvatt: oh, I didn't change _anything_ in jockey...that's what it came up as by default
<tseliot> mdeslaur: also your jockey.log  in /var/log/ might help
<mdeslaur> tseliot: ok., hold on...I'll file a bug and put all those in it
<tseliot> thanks
<mdeslaur> tseliot, Sarvatt: bug 759804
<ubot4> Launchpad bug 759804 in jockey (Ubuntu) "after fresh install, jockey thinks nvidia binary driver is in use (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759804
<tseliot> mdeslaur: you're still using nvidia, at least its GL libraries
<tseliot> you can't be using nouveau as it's blacklisted when nvidia is enabled
<tseliot> so, in short, Jockey is right ;)
<Sarvatt> the nvidia kernel module isn't built
<mdeslaur> tseliot: did you look at the xorg log file?
<tseliot> mdeslaur: it seems that the kernel module wasn't loaded. What does "dkms status" say?
<mdeslaur> tseliot: it doesn't say anything
<tseliot> mdeslaur: please try "sudo dpkg-reconfigure nvidia-current" and see what happens. I bet that somehow dkms failed
<mdeslaur> Error! There are no instances of module nvidia-current 270.30 located in the DKMS tree
<mdeslaur> ok, it seems to have built it now
<mdeslaur> I'll try rebooting
<tseliot> ok
<mdeslaur> ok, looks like I'm running -nvidia now
<mdeslaur> hmm...not a nice bug
<janimo> RAOF, I see you commented on this one https://bugs.freedesktop.org/show_bug.cgi?id=32254 . Is the fix supposed to be in natty, the comment does not mention which branch the fix went into
<ubot4> Freedesktop bug 32254 in Other "EGL+OpenGL API failed to work" [Normal,Resolved: fixed]
<tseliot> mdeslaur: can you close your bug report, please? I don't think we can figure out what happened before...
<mdeslaur> now jockey says "This driver is activated but not currently in use"
<mdeslaur> tseliot: I can reinstall and reproduce at will I bet you
<Sarvatt> janimo: because it went into master, it'll be in 7.11, no it wont be in natty
<janimo> Sarvatt, ah thanks. Too bad though
<tseliot> mdeslaur: if you can reproduce it, please attach your /var/lib/dkms/nvidia-current/270.30/build/make.log
<mdeslaur> tseliot: ok, I'm reinstalling now, and will attach that log
<tseliot> mdeslaur: as regards the fact that Jockey says that the driver is not in use, I'd like to see your new jockey.log
<mdeslaur> tseliot: sure, one sec
<mdeslaur> tseliot: done
 * tseliot has a look
<mdeslaur> tseliot: I have reinstalled, and hit the issue again
<mdeslaur> tseliot: there is no log file in /var/lib/dkms
<tseliot> mdeslaur: you must have something in /var/lib/dkms/nvidia-current/270.30/build/
<mdeslaur> the only thing I have in /var/lib/dkms is a file called dkms_dbversion
<mdeslaur> that's it
<mdeslaur> no other subdirectory
<tseliot> mdeslaur: your last jockey.log should contain some errors
<mdeslaur> tseliot: huh?
<mdeslaur> tseliot: do you want my new jockey.log file?
<tseliot> mdeslaur: yes, if you installed the driver using jockey
<mdeslaur> tseliot: I don't touch _anything_ in jockey. I just open the window, and click close
<mdeslaur> jockey already thinks nvidia is installed
<Sarvatt> did you check the enable 3rd party software box during the install?
<mdeslaur> Sarvatt: yes, I did
<mdeslaur> Sarvatt: would you like me to reinstall without checking it?
<tseliot> mdeslaur: ok, if you do this manually, please capture the output of the operation so that I can see what dkms says
<Sarvatt> thats ok, wont help figure out why the heck its getting in the state where it thinks its installed and activated but isnt really, it wont install if you dont check that box
<mdeslaur> tseliot: you want me to trigger dkms and capture the output?
<tseliot> mdeslaur: I'd like you to reproduce the issue and capture the output
<Sarvatt> he just did
<tseliot> let me check again
<mdeslaur> tseliot: I'm not sure what you mean....the output of _what_?
<tseliot> mdeslaur: I guess you remove the driver and then re-install it with apt, right?
<Sarvatt> tseliot: the problem is when you check the activate the 3rd party drivers box during the install it tries to install the blobs and for some reason its not actually installing it but jockey thinks its installed and activated
<mdeslaur> tseliot: not at all
<tseliot> mdeslaur: how do you do it?
<mdeslaur> tseliot: I don't do _anything_. I install, and then open jockey. That's it.
<Sarvatt> he only opens jockey to see what the status is and it says activated and in use
<tseliot> mdeslaur: "install" how?
<Sarvatt> from a livecd
<mdeslaur> tseliot: from a livecd (well, from a usb key)
<tseliot> aah, ok
<tseliot> mdeslaur: that's not supposed to work
<Sarvatt> he's installing onto a disk, that part is supposed to work
<mdeslaur> tseliot: what's not supposed to work?
<Sarvatt> not trying to install it in a live session where it's not supposed to work
<mdeslaur> nono, I'm not trying to do anything in a live session....I'm installing a laptop from the livecd
<tseliot> mdeslaur, Sarvatt: right but while this *should* work it never did. It's likely a bug in the installer which doesn't copy your compiled module
<tseliot> then when you boot into your installed system you get no nvidia module
<tseliot> *kernel module
<Sarvatt> so this has always been a problem and didnt just start happening?
<tseliot> yep
<tseliot> (the former)
<tseliot> this problem is something I can probably fix though:  https://launchpadlibrarian.net/69240249/Screenshot-Additional%20Drivers-1.png
<Sarvatt> cool, thats the main problem
<Sarvatt> oh wait, thought that was the activated and in use pic
<mdeslaur> so, for our 60% of users that have an nvidia card, and click the "3rd party" checkbox, they will have no way of activating the -nvidia drivers
<Sarvatt> what he's saying is when you do a fresh install, nvidia thinks its installed and in use and you cant activate it tseliot
<mdeslaur> Sarvatt: yes, there are two different issues
<tseliot> Sarvatt: yes, it's that picture
<tseliot> yep
<mdeslaur> issue #1: dkms doesn't get triggered for -nvidia during install. Issue #2: once -nvidia dkms module is rebuilt, jockey thinks -nvidia is not in use
<tseliot> actually
<Sarvatt> mdeslaur: #2 might be intentional until you reboot and it'd show activated and in use
<mdeslaur> Sarvatt: I did reboot between rebuilding the module and opening jockey again
<Sarvatt> apologies if you're saying its still saying that after reboot, i didn't follow it all
<Sarvatt> ahh sorry
<tseliot> issue #1: modules built by dkms are not copied to the installed system.
<tseliot> issue #2: Jockey doesn't detect the driver as activated and in use in some cases
<mdeslaur> tseliot: yes, exactly
<tseliot> mdeslaur: while I can fix issue #2, you should talk to cjwatson about issue #1
<tseliot> it might be useful to ping pitti too
<mdeslaur> I'll add ubiquity to the bug
<tseliot> mdeslaur: I think it would also be worth updating the bug description with these 2 issues
<Sarvatt> its gotta be specific to nvidia, otherwise wl wouldn't work and it does
<tseliot> ah
<Sarvatt> i need to double check that, i might have been using brcm80211 in these recent installs instead and not have noticed
<tseliot> it would be interesting to know
<Sarvatt> bryceh_: think 40-xserver-xorg-video-intel.rules is triggering too much? http://paste.ubuntu.com/593618/ :)
<bryceh_> Sarvatt, heh
<bryceh_> Sarvatt, probably about time for us to turn it off anyway
<Sarvatt> running the rule and dumping was triggering these http://paste.ubuntu.com/593614/ and they stopped when i got rid of the udev rule
<Sarvatt> RAOF: hrm software-center started working without 113_fix_tls.diff again
<Sarvatt> the tls patch was causing problems on amd64 with mesa master so i haven't been adding it in edgers
<dbarth> bryceh_: hey bryce; hi
<dbarth> i'm suddenly getting some x crashes since monday or so, and i can only get that kind of backtrace in the xorg log: http://pastebin.ubuntu.com/593615/
<dbarth> no real test case, but the info is that it's almost the first time in the cycle that i've had crashes with my server at all
<bryceh_> hmm interesting
<bryceh_> dbarth, RAOF posted a new (bugfix) release of mesa on Monday
<dbarth> ah right, i heard about it
<dbarth> so do you want me to downgrade and see for a day or two?
<Sarvatt> not fixed in that, i'm digging up the bug number for that one
<dbarth> i don't want to add another bug report to the pile with so little info
<bryceh_> dbarth, your /var/log/dpkg.log should have the details of what exactly got upgraded; I'd probably start by downgrading packages to isolate what package regressed
<dbarth> and wait a little bit to see if the sudden crashes go away
<dbarth> ok, i'll do that
<dbarth> thanks
<Sarvatt> dbarth: that backtrace is a known problem, i've only been able to reproduce it closing the lid for >30 minutes here
<Sarvatt> trying to find the bug for it so you can track it still
<Sarvatt> only happens in a unity session
<dbarth> Sarvatt: ah thanks
<dbarth> uh, /that/ doesn't sound good 
<Sarvatt> dbarth: hrm I take that back, got it confused with the other one where X doesn't crash, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/740126 
<ubot4> Launchpad bug 740126 in compiz (Ubuntu Natty) (and 1 other project) "compiz hangs randomly several times per day (affects: 4) (heat: 24)" [High,Confirmed]
<Sarvatt> i've seen that backtrace a few times in the past few days though, robert_ancell had it http://paste.ubuntu.com/592987/ checking to see if he filed a bug
<dbarth> Sarvatt: ah that one is the xcb hang
<dbarth> (or let me check)
<dbarth> well, it's an xcb hang
<Sarvatt> that xcb hang was what I was saying I could reproduce and only had happen in unity, sorry about that :)
<dbarth> nw
<dbarth> but i'm aware of 2 of those
<dbarth> one that was involving an xgetwindowproperty
<dbarth> and that we workarounded
<dbarth> and that other one
<dbarth> but which may actually be triggered by another change we made to fight the stacking issues
<dbarth> there is a daily build of compiz where you can turn the stackattack otpion off
<dbarth> and that may help with this bug
<dbarth> ie not trigger it that often
<dbarth> Sarvatt: is there a bug that i could subscribe to for the backtrace?
<Sarvatt> i'm not seeing one, it'd be appreciated if you could file one against xorg-server and we can dupe it later if we find it
<Sarvatt> neither of the 2 people i've seen the backtrace from ended up filing a report and i'm not seeing a one filed against xorg xorg-server or compiz
<Sarvatt> guess i should check intel, both of the other reporters were on intel
<bryceh_> I don't see one against -intel
<bryceh_> jeesh so many bugs
<bryceh_> Sarvatt, on https://bugs.freedesktop.org/show_bug.cgi?id=34014 check comment 28  :-/
<ubot4> Freedesktop bug 34014 in Driver/intel "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000004)" [Major,Resolved: fixed]
<Sarvatt> bryceh_: ugh...
#ubuntu-x 2011-04-14
<bdmurray> bryceh_: have you guys seen bug 754470?
<ubot4> Launchpad bug 754470 in xserver-xorg-input-synaptics (Ubuntu Natty) (and 1 other project) "syndaemon consumes 100% CPU (affects: 40) (dups: 2) (heat: 204)" [High,Confirmed] https://launchpad.net/bugs/754470
<RAOF> bdmurray: cnd certainly has; I think he's on to it.
<bryceh_> yeah
<bryceh_> oh hey RAOF
<RAOF> bryceh_: Heidi ho.
<Sarvatt> oh wow, ppa packages pre-natty got removed?
<Sarvatt> err lucid
<bjsnider> Sarvatt, from which ppa?
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ppa/+packages 
<Sarvatt> hmm someone must have done it
<ScottK> That or Soyuz is borked due to LP related network outages and so the status you see may be wrong.
<cnd> tjaalton, I don't see anything wrong with the 1.10.1rc2 merge
<cnd> I'm not sure what's going wrong...
<cnd> but there were quite a few input fixes that went into the update
<tjaalton> cnd: yeah that was puzzling me too..
<cnd> tjaalton, I've got some other things I'm working on atm
<tjaalton> cnd: sre
<tjaalton> +u
<cnd> do you need me to take this too, or would you be able to handle it?
<tjaalton> just unassign it for now
<cnd> ok
<cnd> tjaalton, according to the upstream bug report, it's confirmed against upstream too
<tjaalton> except whot couldn't reproduce it
<tjaalton> which made me think it's something in ubuntu doing it
<cnd> tjaalton, yeah, but someone else could reproduce it
<cnd> so I think it's just a matter of having the right setup/devices
<tjaalton> hmm right, i thought he was one of the subscribers, but not
<cnd> I'll try the test case here to see if I can hit it
<cnd> I can hit it
<tjaalton> good :)
<cnd> basically, you get a press, but no release at first
<cnd> then you press and release again to get a press and a release event
<cnd> so you end up with
<cnd> press
<cnd> press
<cnd> release
<cnd> press
<cnd> press
<cnd> release
<cnd> etc.
<tjaalton> okay
<cnd> and I just confirmed that the previous release was working fine
<cnd> I'll try to see if I can figure it out since I've come this far :)
<tjaalton> great, thanks :)
<tjaalton> I'll call it the day..
<Sarvatt> bryceh_: drirc attachments paid off finally https://bugs.launchpad.net/ubuntu/+source/unity/+bug/745996
<ubot4> Launchpad bug 745996 in unity (Ubuntu) (and 1 other project) "All unity windows are invisible (panel, launcher, dash) (affects: 7) (dups: 1) (heat: 48)" [High,Invalid]
<Sarvatt> i'm curious if kwin needs ARB_fragment_shader disabled on 945 still
<Sarvatt> guess not because I haven't seen any bugs about it this cycle since we disabled the patch making false the default
<Sarvatt> http://pad.lv/724569
<Sarvatt> darn, ubot4 doesn't know about the launchpad url shortener
<ScottK> Sarvatt: It's been working fine for me on my 945 laptop, so whatever you have is fine.
<ScottK> (better than Maverick)
<bryceh_> Sarvatt, yeah I'd noticed that yesterday.
<Sarvatt> sure would be nice to have an --iknowwhatimdoingdangit option to pass to ubuntu-bug so it let me file bugs with non-ubuntu packages installed :P
<Sarvatt> bryceh_: think its worth opening a compiz task for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/761065 ?
<ubot4> Launchpad bug 761065 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[Sandybridge] Spurious "*ERROR* Hangcheck timer elapsed... blt ring idle" messages in dmesg when using compiz (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> bryceh_: I love how it adds the relevant lines from dmesg in the description now btw!
<bryceh_> Sarvatt, :-)
<Sarvatt> hrm I should try under mutter
<bryceh_> Sarvatt, actually I think that's just because when a file is below a certain size, it's just inlined in the description rather than attached
<bryceh_> Sarvatt, however might be a neat feature to grep for "*ERROR*" from dmesg and insert that separately
 * bryceh_ todo's
<Sarvatt> argh why did it .gz the logs that time
<Sarvatt> guessing the upstreamer wont work on it with that? :P
<Sarvatt> ScottK: awesome, thanks for the heads up (and sorry to ping you to say thanks) :)
<bryceh_> Sarvatt, send_upstream.cgi doesn't actually do anything with the logs
<bryceh_> Sarvatt, the upstreamer tool I'm still in progress on will download the logs and uncompress them, but I'm a ways from having that ready for use
<bryceh_> what would you guys think about having a UDS session to browse through the xserver wishlist bugs?  I think some of them might be resolved, others we may be able to wontfix, the rest might be useful to share knowledge about.  Might even be one or two we could do something about.
<bryceh_> there's currently about 20 or so xserver wishlist bugs; might be challenging to get through them all in a session but if we're speedy we could do it.
<bryceh_> tjaalton, git push your xorg-server tree
#ubuntu-x 2011-04-15
<RAOF> The wishlist bugs session sounds like a good one to me.
<bryceh_> RAOF, ok I'll craft a blueprint
<bryceh_> RAOF, meanwhile it seems one of monday's updates introduced a regression - see bug 757968
<ubot4> Launchpad bug 757968 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup (IPEHR: 0x14000000) - Black screen (affects: 2) (dups: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/757968
<bryceh_> RAOF, any ideas offhand?  If the user can repro it, I'm going to have them individually downgrade mesa, xserver, -intel, and compiz to see which causes it.
<RAOF> bryceh_: looking.
<bryceh_> if I were to bet, I'd guess mesa.
<RAOF> Me too.
<RAOF> If it's reproducible, and downgrading mesa fixes it, it shouldn't be too hard to identify the bad commit.
 * bryceh_ nods
<bryceh_> alright, sounds like a plan
<bryceh_> RAOF, btw I have a suspicion the libdrm patch ickle gave us is bad
<RAOF> The even-more-relaxed-tiling fixes one?
<bryceh_> I've got 2-3 similar-ish bugs that I've got traced to regressing around the time that patch went in
<RAOF> Hm.
<bryceh_> so far one test of downgrading it indicates that without that patch it freezes less often (maybe there's another freeze bug)
<bryceh_> the bugs are freezes and/or black screen issues
<bryceh_> so, if I can gather some more solid evidence I might revert that patch...100_intel_remember_named_bo.patch
<bryceh_> RAOF, I do note that debian took a couple other patches along with that one for 2.4.23-3, so perhaps one of them corrects issues that this patch brought?
<RAOF> Fun fact: âbreak WriteToClient if who=0x14f92d0â is *very importantly* not the same as âbreak WriteToClient if who==0x14f92d0â :)
<Sarvatt> that or there were more parts of 2.4.24 needed too
<RAOF> bryceh_: Possibly?
<RAOF> The other parts of 2.4.24 *claimed* to be about older kernels, and certainly looked that way.
<bryceh_> right
<bryceh_> if I can confirm that downgrading solves these issues, I can also see about having them test against the newer version if it's in a ppa somewhere
<Sarvatt> these time zone differences between us all suck :)
<bryceh_> anyway, thinking we should hold off on 2.4.24 until these regressions are better understood
<bryceh_> Sarvatt, howso?
<RAOF> I can upload 2.4.24 into X staging pretty easily.
<bryceh_> ok, that sounds like a good step
<bryceh_> I'll have folks test against that
 * RAOF turns on the coffee machine and sets to uploading.
<RAOF> Uploaded to ubuntu-x-swat.
<RAOF> AAaand built.
<bryceh_> thanks
<tjaalton> bryceh_: whoopsie daisy.. done
<njpatel> RAOF, I loved seeing that email in the morning....thank you for your work helping to track this down :)
<RAOF> njpatel: It's a nice thing to end the week on :)
<njpatel> Indeed :
<njpatel> :)
<ara> good morning tseliot
<tseliot> good morning to you ara :)
<seb128> bryceh_, some of the duplicates of the "intel_tex_image.c:726: intelSetTexBuffer2: Assertion `!texImage->Data' failed" have apport infos if that's useful
<bradm> hi, is there anything I can do to help with bug 727620?  I have to reboot my laptop 5 or 6 times, and then log into and kill X about the same before I get a usable session
<ubot4> Launchpad bug 727620 in xserver-xorg-video-ati (Ubuntu) (and 2 other projects) "[Radeon HD 5650 and 5470] Driver crash during recovery boot and in normal boot (Regression from 2.6.38-3 to -4) (affects: 9) (dups: 1) (heat: 58)" [High,Incomplete] https://launchpad.net/bugs/727620
<tjaalton> bradm: why don't you use the workaround mentioned in comment #26
<bradm> tjaalton: I did try that and had some issues, should give it another go I guess.  it'd be good to have the bug fixed though
<tjaalton> bradm: strongly in the upstream territory though, it needs kernel changes that won't get in 2.6.38
<tjaalton> from what I can tell anyway
<bradm> tjaalton: right, I suspected that might be the case but its not really 100% clear in the bug thats whats happening
<tjaalton> bradm: have you looked at the upstream bug?
<bradm> tjaalton: I did
<tjaalton> "The switcheroo code
<tjaalton> needs more work to switch properly on some systems it seems."
<bradm> yes, there's a lot of it seems, and supposition, was just wondering if I could do anything to help clear it up
<bradm> its not clear to me whats happening now with the bug
<tjaalton> i can confirm it if you like
<tjaalton> the bug report, not the bug happening
<bradm> well, it does say status incomplete, made me think something was missing
<tjaalton> there
<bradm> cool, thanks
<bradm> its definately still happening for me at least
<tjaalton> i don't doubt that
<bradm> oddly I couldn't see anything in my bios to tell it to just use the radeon, but it is downrev a bit
<bradm> but it needs windows to do a bios update :-/
<tjaalton> it's updated from windows?
<bradm> all HP provide is a windows .exe
<bradm> its possible there's a way of flashing from linux but its not obvious from the time I've spent looking 
<bradm> which, admittedly, hasn't been an enormous amount
<tjaalton> it's usually just a self-extracting zipfile
<tjaalton> use unzip to extract it
<tjaalton> there are docs for creating a bootable cd that you can use for flashing your bios
<bradm> nope, its not a zip file
<bradm> ah, its a cab file
<tjaalton> have a link to it?
<bradm> ftp://ftp.hp.com/pub/softpaq/sp50501-51000/sp50942.exe
<bradm> I've found some references that say the bios is encrypted by one of the dlls provided
<tjaalton> right, that tool really needs windows..
<tjaalton> fail
<bradm> very much so
<bradm> my next laptop won't be a HP :)
<BlackZ> Sarvatt: I filed a bug for the issue I described you the other day: bug #761718
<ubot4> Launchpad bug 761718 in nvidia-graphics-drivers (Ubuntu) "Can't start Ubuntu default session properly (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/761718
<tseliot> BlackZ: what happens if you downgrade to the previous version of nvidia-current  and reboot?
<BlackZ> tseliot: this is what I was just trying ;)
<tseliot> everything seems to be ok, BTW
<BlackZ> yeah, looks quite weird
<BlackZ> tseliot: downgrading to the previous version doesn't help at all
<BlackZ> (and I was having the problem what that version as well)
<tseliot> BlackZ: I suspected that. It means that something else busted your system. Maybe unity?
<BlackZ> tseliot: I don't think so. Even the classic Ubuntu session doesn't start properly
<BlackZ> tseliot: I can only start the one without any effect
<tseliot> BlackZ: it's probably compiz then
<BlackZ> tseliot: yeah, I think so
<tseliot> BlackZ: see if you can find something interesting in your ~/.xsession-errors after you reproduce the problem
<BlackZ> tseliot: unfortunately no, I can't
<tseliot> BlackZ: can you reproduce the problem if you start the classic session without effects and then type: compiz --replace
<tseliot> ?
<BlackZ_> tseliot: bingo! the problem is compiz..
<BlackZ_> tseliot: it seems to crash at "Starting unity-window-decorator"
<tseliot> BlackZ_: ok, please update the bug report and assign the bug to compiz
<BlackZ_> tseliot: will do! thanks :)
<BlackZ_> tseliot: btw I still can't figure out why it works with the nouveau drivers..
<bjsnider> why don't the other nvidia users have th is bug?
<bjsnider> me, for example
<BlackZ_> bjsnider: no clue, this is really really weird
<cnd> bryceh_, got a bug fix for evdev pushed to git for bug 573006
<ubot4> Launchpad bug 573006 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Touch screen driver clicks at wrong location (affects: 8) (heat: 52)" [Medium,New] https://launchpad.net/bugs/573006
<cnd> please upload when it's convenient
<bryceh_> cnd, ok will do
<cnd> bryceh_, got a fix for synaptics bug 754470 pushed to git too :)
<ubot4> Launchpad bug 754470 in xserver-xorg-input-synaptics (Ubuntu Natty) (and 2 other projects) "syndaemon consumes 100% CPU (affects: 65) (dups: 4) (heat: 342)" [High,In progress] https://launchpad.net/bugs/754470
<tjaalton> cnd, bryceh_: pushed the reverted patch for bug 757972 to git
<ubot4> Launchpad bug 757972 in xorg-server (Ubuntu) (and 2 other projects) "Easystroke doesn't recognize button release (affects: 5) (heat: 30)" [Medium,In progress] https://launchpad.net/bugs/757972
<cnd> tjaalton, thanks!
<tjaalton> cnd: sorry for just throwing the ball on your court yesterday ;)
<cnd> tjaalton, np :)
<cnd> it's a bit of a lull right now
<cnd> and it very well could have been caused by some of my patches
<tjaalton> heh, well your patches were, for the most part, already on our tree
<tjaalton> in
<tjaalton> aanyway, seems that there are less bugs flowing in that I feared
<tjaalton> beta2 and all
<tjaalton> some freezes yeah, but could just as well be compiz ones
<tjaalton> and i really hope/believe that bug 507602 is finally fixed by libx11 1.4.2
<ubot4> tjaalton: Bug 507602 on http://launchpad.net/bugs/507602 is private
<tjaalton> duh
<tjaalton> bug 507062
<ubot4> Launchpad bug 507062 in libx11 (Ubuntu Natty) (and 3 other projects) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed. (affects: 407) (dups: 267) (heat: 2474)" [Medium,Incomplete] https://launchpad.net/bugs/507062
<tjaalton> 267 dupes..
<tjaalton> there's more, I'm sure
<bryceh_> wow
<tjaalton> i ran the test code on the upstream bug for an hour or so, and couldn't reproduce it
<tjaalton> though I should probably try it on beta1 too, to see if the code actually works
<mvo> tjaalton: I think I saw a similar one for software-center recently, same pattern
<tjaalton> mvo: yeah, many of those are from s-c
<mvo> bug #761972
<ubot4> mvo: Bug 761972 on http://launchpad.net/bugs/761972 is private
<mvo> why my stuff? synaptic, software-center? *grumpf* ;)
<tjaalton> heh
<tjaalton> ah well
<tjaalton> so it's a fresh one, probably didn't fix it then
<tjaalton> duh
<bryceh_> mvo, you're not alone.  Many times I've gone to report an emacs, xterm, firefox, etc. bug only to end up finding out it's actually a friggin X bug.
<mvo> at least I'm not alone!
<tjaalton> there are also some interesting commits on the libxcb tree, but it's a risky business pulling those. there really should be a reliable way to trigger this, but I'm afraid that's asking for too much..
<bryceh_> yeah, we've been burned with xcb cherrypicks in the past.  quite a fragile library
<bryceh_> reboot time. bbiab
<tjaalton> best to try it via an sru
<tjaalton> or oneiric..
<tjaalton> most likely
<bryceh> cnd, [ubuntu/natty] xserver-xorg-input-synaptics 1.3.99+git20110116.0e27ce3a-0ubuntu12 (Waiting for appro
<bryceh> cnd, [ubuntu/natty] xserver-xorg-input-evdev 1:2.6.0-1ubuntu12 (Waiting for approval)
<cnd> bryceh, ta!
<Sarvatt> darn, i started packaging up a new libxcb but gave up halfway through the 100+ new symbols. guess i should finish it :P
#ubuntu-x 2011-04-16
<bryceh> what's the best way to tell if I'm running r600 vs. r600g?
<bryceh> ah, glxinfo:  OpenGL renderer string: Gallium 0.4 on AMD RV770
<soreau> bryceh: The g in r600g stands for Gallium
<bryceh> soreau, yes I'm aware ;-)
<soreau> bryceh: I misread your statement there
<bryceh> humber:~$ grep r600 /var/log/Xorg.0.log
<bryceh> [   236.995] (II) RADEON(0): [DRI2]   DRI driver: r600
<bryceh> [   237.000] (II) AIGLX: Trying DRI driver /usr/lib/dri/r600_dri.so
<bryceh> [   237.002] (II) AIGLX: Loaded and initialized r600
<bryceh> was surprised I don't have the 'g' on those.  But "r600" == "r600g" here
<soreau> Hey guys, Im looking in driconf and there are a lot of options missing
<soreau> even in expert mode
<soreau> Is there some package missing?
<LLStarks> bryceh, i'm about to buy a laptop with a 6770m. will i be able to patch fglrx whenever the xserver abi changes or will be stuck with radeon except for april and october?
<Sarvatt> no you cant patch fglrx for abi changes, we might not do 1.11 for 11.10, and it'll work fine with radeon since its a rebranded 5xxx series
<soreau> Sarvatt: Any idea about driconf?
<soreau> Im pretty stumped on this one
<Sarvatt> soreau: what about it?
<Sarvatt> sorry, missed those messages umm
<Sarvatt> what GPU is it?
<soreau> Sarvatt: It used to have a near plethora of options, now its next to nothing. rv350/r300g
<LLStarks> sarvatt, oneiric will be 1.10.x?
<Sarvatt> i'm guessing you're talking about the options that were exposed with r300c instead of r300g
<soreau> Sarvatt: hmm.. maybe so but it doesnt make sense for gallium to expose less I would think
<Sarvatt> the options were only there for the classic driver, its not based on the gpu it's based on what the dri driver exposes
<soreau> ok
<Sarvatt> LLStarks: its possible, we're going to talk about it at UDS
 * soreau ppa-purges xorg-edgers to see
<Sarvatt> soreau: LIBGL_DRIVER_PATH=/usr/lib/dri-alternates/ driconf should show the r300c ones to be sure
<soreau> Oh interesting
<Sarvatt> r300c is in there so it gets loaded when KMS isn't used automatically
<soreau> Sarvatt: Is that to say, you can run any app with the classic drivers by setting this path?
<Sarvatt> yep
<soreau> and these are updated classic drivers from xorg-edgers, not stock ubuntu
<Sarvatt> its the same in the archive
<soreau> Sarvatt: ok thanks for that information
<Sarvatt> libgl1-mesa-dri installs both in both the ppa and natty
<Sarvatt> the only major changes between the ppa and natty are that i have libtxc_dxtn in there, texture-float is enabled and the tls patches in edgers
<Sarvatt> oh and the whole libglapi-mesa package split
<Sarvatt> err tls patches are disabled in edgers which breaks some obscure apps
<soreau> Sarvatt: s3tc??
<Sarvatt> yeah
<soreau> How does that work to enable/disable it?
<Sarvatt> the lib should be pulled in automatically so its enabled
<soreau> But it causes problems for many apps that do not use this compression format..
<Sarvatt> many being a few proprietary apps yeah
<soreau> huh
<Sarvatt> oh ya mean having it installed causes problems in some apps?
<soreau> Yes
<Sarvatt> is that a radeon specific thing? what does the driconf option to enable it default to?
<soreau> There is no driconf option in gallium exposed apparently
<soreau> This was actually the problem I was referring to in the first place
<LLStarks> sarvatt, what makes 1.11+ so prohibitive? i though randr and the rest of xinput2 were safe for later this year.
<Sarvatt> are you sure the problems were just with the screwed up release? I put the latest 1.0.0 in there
<Sarvatt> libtxc_dxtn070518 had some nasty bugs in it
 * Sarvatt has to run, sorry
<Sarvatt> soreau: oh you're on maverick? I haven't updated that in months in xorg-edgers, I've been talking about natty all this time sorry
<soreau> Sarvatt: Well the fact remains.. classic exposes many more options than gallium
<ScottK> Sarvatt or RAOF: Are you aware of this: http://bugs.kde.org/show_bug.cgi?id=270942
<ubot4> KDE bug 270942 in compositing "Direct Rendering is wrongfully disabled on Intel graphics since mesa 7 10 1" [Normal,Unconfirmed]
#ubuntu-x 2011-04-17
<yofel> I can confirm that the patch does make kwin work fine again on my 945GME
<Sarvatt> -    if (strstr((const char *)renderer, "GEM"))
<Sarvatt> +    if (strstr((const char *)renderer, "Intel"))
<Sarvatt> RAOF: I think that'd be a better option, Intel is not in the gl renderer string if DRI2 isn't used since swrast would be used instead, and that will work with future mesa updates as well. what do you think?
<Sarvatt> regarding http://bugs.kde.org/show_bug.cgi?id=270942
<ubot4> KDE bug 270942 in compositing "Direct Rendering is wrongfully disabled on Intel graphics since mesa 7 10 1" [Normal,Unconfirmed]
<Sarvatt> GEM was in the gl renderer string to differentiate between KMS and !KMS but !KMS no longer works with x-x-v-intel anyway
<Sarvatt> (which is why it was removed, its bogus and has been for over a year)
<ScottK> Well unfortunately kwin was depending on it being there.  We can fix that in KDE 4.7 for oneiric, but it'd be heplful if we got it back for now.
<ScottK> Sarvatt: ^^^
<kklimonda> hey, any idea why did I loose Two-finger scrolling some time ago in natty? It has worked fine till then.
<kklimonda> (I still see the related option in gnome-mouse-properties, and I can choose it, but it doesn't seem to change anything)
<tjaalton> ScottK: why can't you make the same change for natty?
<ScottK> tjaalton: Upstream says it would be too invasive for a point release update.
#ubuntu-x 2012-04-09
<cnd> Sarvatt, so it turns out the trackpad 10 finger crash issue is a real issue in synaptics
<cnd> completely separate from the signal logging issue
<cnd> we may need to {un,re,}dupe bugs
<jcristau> ick.  are we really unloading drivers from the sighandler?
<cnd> jcristau, yep
<jcristau> that seems insane
<cnd> jcristau, to be fair, it is only during server shutdown I think
<cnd> so I don't think we ever actually return from signal context
<cnd> so it's technically safe
<jcristau> ah, sigterm and friends, not sigio
<jcristau> that makes more sense
<cnd> bryceh, so now I have a fix for the apple trackpad crashes, and it has nothing to do with the logging in signal context issue
<cnd> the patch has now become much larger, due to the many paths where messages are logged in signal context
<cnd> and the patch has to be manually backported because some of those paths have changed
<cnd> I think it's too late in the cycle to push a rather large patch that does not have any real affect other than to cause valgrind not to crash
<bryceh> cnd, oh okay, well that's too bad
<cnd> bryceh, I'm going to mark the bug as won't fix, but upload my current patch
<cnd> so if anyone wants to run under valgrind they can apply the patch and rebuild
<bryceh> cnd, alright, maybe add an task for q-series if it's worth tracking for the next release
<cnd> bryceh, I'm hoping we can get it from upstream
<cnd> but I guess that depends on what upstream release we use for q
<Sarvatt> cnd: i only duped ones that i was sure would be the same thing, people saying they got the crash brushing dust off the touchpad and stuff. jupiter4 didn't fix the 10 finger crash here, guess i have a long fingernail causing an extra touch if i was hitting it with 10 :)
<cnd> Sarvatt, ok, cool :)
<cnd> I have a fix uploaded in synaptics
<Sarvatt> yeah got it building now
<cnd> just waiting for it to be approved
<Sarvatt> thank you thank you thank you in advance :)
<cnd> :)
<cnd> yw
<Sarvatt> cnd: 20 fingers isn't crashing :)
<cnd> Sarvatt, how are you managing that?!
<jcristau> with his feet
<Sarvatt> volunteered the wife to help
<cnd> Sarvatt, also, how did you manage to get 20 fingers on that device? :)
<Sarvatt> playing hungry hungry hippo in all 4 corners
<cnd> it's only so large
<cnd> heh
#ubuntu-x 2012-04-10
<Sarvatt> RAOF: this probably doesnt help but http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff is rebased against xserver master
<Sarvatt> "almost" no coding style changes applied to it so it would need to be completely refreshed :(
<Sarvatt> i redid the patch 2 times, the first i made it follow upstream coding style but i used an older version of the patch :(
<Sarvatt> which was completely different than the latest one
<Sarvatt> it will never stop cracking me up imagining a male doing an 11 finger gesture for chases patch, my mind is in the gutter
<RAOF> Heh.
<bjsnider>  the male mind is pretty much always in the gutter
<tjaalton> whot sanctioned the g-s-d wacom patch, time to send it upstream
<pepee> hi. I have this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/962704  and it's driving me crazy :(
<ubottu> Launchpad bug 962704 in xserver-xorg-input-synaptics (Ubuntu) "cursor jumps to screen border when touching trackpad border" [Undecided,Incomplete]
<Sarvatt> bryceh: ok we have an issue on intel
<Sarvatt> (see #distro)
<Sarvatt> oh you arent on canonical irc
<Sarvatt> luckily its already fixed but theres probably a bunch of dupes floating around
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/921236
<ubottu> Launchpad bug 921236 in xserver-xorg-input-evdev (Ubuntu) "[12.04 Xorg, xserver 1.11.3] Dual monitor, after entering password, mouse pointer stuck on LHS of screen, no desktop." [High,Confirmed]
<Sarvatt> seems intel needs http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=1c2932e9cb283942567c3dd2695d03b8045da27f to avoid the same type of crash when the display configuration is changed
 * bryceh looks
<Sarvatt> is it even possible to update intel still?
<bryceh> hah, and just *after* I finished forwarding a slew of gpu lockup bugs upstream
<Sarvatt> not sure what to do with the bugs, that specific bug is fixed and unrelated, people are reopening it with the intel bug
<Sarvatt> ah theres also https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/972852
<ubottu> Launchpad bug 972852 in xorg-server (Ubuntu) "X server hangs when connecting or disconnecting external monitor and input devices" [High,Triaged]
<bryceh> we got a bunch of those lockups with external monitors
<bryceh> forwarded 3-4 or so :-/
<bryceh> so... this is good.  shall we ppa the patch for testing or is it sufficiently proven we should put it in precise directly?
<Sarvatt> hasn't been proven yet but the upstream bug for it looks good, asking him to try it
<Sarvatt> bryceh: so maybe https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/972852 as the master bug now?
<ubottu> Launchpad bug 972852 in xorg-server (Ubuntu) "X server hangs when connecting or disconnecting external monitor and input devices" [High,Triaged]
<bryceh> could be
<Sarvatt> the 92xxxx one was unrelated and already fixed, but i guess we could just fix the same bug again even though its different
<Sarvatt> eh lets just use 921236 again
<Sarvatt> i'll just ask for testing in a ppa
<bryceh> maybe 978084 too?
<bryceh> and 974830?
<Sarvatt> no to the first thats a gpu hang..
<bryceh> ok
<bryceh> hey, looks like upstream is quick on the draw; already have patches flagged for several of the ones I upstreamed
#ubuntu-x 2012-04-11
<RAOF> Darxus: Hey, could I get you to check a grub-gfxpayload-lists upload to fix your splash madness?
<tjaalton> seb128: hey, the g-s-d wacom patch was approved by the wacom maintainer, I've yet to push it upstream, but you could add it to the package :)
<seb128> tjaalton, sure
<tjaalton> or should I push it to the bzr branch? dunno if I can
<seb128> tjaalton, do you have a upload rights for g-s-d?
<tjaalton> seb128: yes
<tjaalton> core dev
<tjaalton> hmm i thought the bzr branches were owned by ~ubuntu-desktop
<seb128> tjaalton, yes, but coredev is a subteam of ~ubuntu-desktop to resolve that issue :p
<seb128> or rather member of ...
<tjaalton> ah, ok
<seb128> tjaalton, so feel free to push to the vcs, upload
<tjaalton> seb128: ok, will do
<seb128> tjaalton, thanks
<Prf_Jakob> Sarvatt, bryceh: Somebody broken the llvmpipe blacklist in Unity.
<Darxus> RAOF: Just woke up, about to test.
<Darxus> RAOF: Confirmed it works, updating bug.
<mdeslaur> bryceh, tseliot: FYI, I am going to publish the driver security update for the stable releases in a few minutes
<tseliot> mdeslaur: great, thanks, I'll take care of the driver in Precise soon
<tjaalton> mdeslaur: which driver?
<tseliot> nvidia
<mdeslaur> http://nvidia.custhelp.com/app/answers/detail/a_id/3109
<tjaalton> hum, ok
<mdeslaur> tseliot: thanks. Do you want my debdiffs for the older drivers?
<tseliot> mdeslaur: only for the ones in oneiric, if possible, thanks
<mdeslaur> tseliot: ok, sent via email
<tseliot> mdeslaur: thanks
<Prf_Jakob> Sarvatt: So, we have bug that we probably like to get a fix in for.
<Prf_Jakob> Or work around.
<Prf_Jakob> The work around is you give the vmwgfx module the argument "enable_fbdev=1"
<Prf_Jakob> Luckely the bug only happens when you syspend the VM from inside the guest.
<bryceh> mdeslaur, thanks
<bryceh> Prf_Jakob, got details on the llvmpipe breakage?  need my help?
<mdeslaur> bryceh: thanks for the help! :)
<Prf_Jakob> bryceh: I just started the legacy driver by disabling vmwgfx.ko, and it looked like it used llvmpipe.
<Prf_Jakob> Hmm I'm not getting llvmpipe when I just disabled 3D.
<Prf_Jakob> Hmmm just retried it, it didn't happen...
<Prf_Jakob> bryceh: sorry for the noise.
<Prf_Jakob> bryceh: I would like to know if there is a possibility to get a fix in for the kernel driver?
<Prf_Jakob> As I asked before.
<Prf_Jakob> BBL dinner.
<bryceh> Prf_Jakob, it is hard but not impossible; there is a process to follow for that.  As a general rule, the fix needs to get into the mainline kernel first (and ideally also the stable kernel)
<Prf_Jakob> bryceh: ah, its just a argument addition.
<Prf_Jakob> Is it even possible to do that?
<Prf_Jakob> I'm gussing modprobe is involved.
<bryceh> Prf_Jakob, ogaswara or apw would probably be the people to talk to
<bryceh> Prf_Jakob, by argument do you mean adding a kernel module parameter?
<apw> yeah if its just changing the module config that is outside the kernel anyhow
<bryceh> apw, who controls that?  slangasek's team?
<Sarvatt> bryceh: x-x-v-vmware could install a modprobe.conf rule to add the option, or it could just be twiddled to default on in the kernel
<Sarvatt> Prf_Jakob: how's the llvmpipe blacklist broken? seems to be ok here still http://paste.ubuntu.com/925255/
<Sarvatt> blacklisting llvmpipe from using unity is intentional
<Sarvatt> ah missed the later conversation about that one, sorry
<Sarvatt> bryceh: like this http://paste.ubuntu.com/925266/
<bryceh> Sarvatt, right, thanks
<bryceh> Prf_Jakob, so if it's just changing a module param, we should be able to handle that using normal final freeze bug fixing processes
<bryceh> key thing is to just assure that wide enough testing has been done to catch potential regressions
<Prf_Jakob> bryceh: okay, thanks
<Prf_Jakob> Sarvatt: Sorry for the noise, I should have verified the bug.
<Prf_Jakob> Sarvatt: Thanks, how would I go about intructing QA noobs on how to test this?
#ubuntu-x 2012-04-12
<mdeslaur> anyone have any idea how I could fix LP: #979473?
<mdeslaur> bug 979473
<ubottu> Launchpad bug 979473 in xserver-xorg-video-intel (Ubuntu) "when --scale is used with xrandr, mouse doesn't move beyond original size" [Undecided,New] https://launchpad.net/bugs/979473
<mdeslaur> ah, looks like it's https://bugs.freedesktop.org/show_bug.cgi?id=39949
<ubottu> Freedesktop bug 39949 in Server/Ext/RandR "RandR panning & scaling don't work" [Major,New: ]
<bryceh> mdeslaur, heya
<mdeslaur> hi bryceh
<bryceh> mdeslaur, I seem to recall this trouble started around when the pointer barriers work went in.  I don't know if there's a simple switch to turn that off, but if there is I suspect that'd be your workaround
<mdeslaur> hrm, probably a dupe of bug 883319
<ubottu> Launchpad bug 883319 in xorg-server (Ubuntu) "xrandr --scale restricts area in which mouse moves" [Low,Triaged] https://launchpad.net/bugs/883319
<bryceh> mdeslaur, RAOF has been doing most of the work around that feature, and I would suggest chatting him up
<mdeslaur> weird, I thought it was working 11.10...maybe I haven't used my netbook in a while...
<bryceh> yep, there's also a similar --panning issue
<bryceh> mdeslaur, yeah see my comments #5/6
<mdeslaur> ok, I'll dupe it and I'll try the latest patch in the upstream bug. Thanks bryceh
<bryceh> mdeslaur, yep.  and please do raise with RAOF; I'm not sure if this is on his radar, but he's the go-to-guy for pointer barrier issues
<mdeslaur> bryceh: cool
<mdeslaur> ROAF: HELP! :)
<mdeslaur> RAOF: HELP!
<RAOF> mdeslaur: You rang, m'lud?
<mdeslaur> RAOF: hehe, it's regarding bug #883319...do you have a fix in sight?
<ubottu> Launchpad bug 883319 in xorg-server (Ubuntu) "xrandr --scale restricts area in which mouse moves" [Low,Triaged] https://launchpad.net/bugs/883319
<mdeslaur> RAOF: I'm currently testing the last patch in the upstream bug for kicks
<RAOF> That's probably what the fix would look like.
<mdeslaur> RAOF: ok, bryceh thought I should nag you about it :)
<RAOF> It's not pointer-barrier related; it's âdon't let the pointer wander off the crtcsâ related.
<RAOF> I can give the patch a bit of a review, though.
<mdeslaur> RAOF: ok, just booted with the patch, and it appears to solve my issue...i'll mention it in the bug
<tjaalton> oh noes, can't make the desktop switcher popup go away
<tjaalton> meh, it was some apport popup which stole the mouse focus
<cnd> bryceh, Sarvatt: do you know of a bug for xinput erroring out when trying to list device axes?
<cnd> I don't see any bugs against xinput
<cnd> I can file one, I just figured someone else would have beat me to it
<cnd> I have the fix in hand
<cnd> google isn't finding anything either
<cnd> I guess I'll make a new one
<cnd> it's actually a bug in libxi, btw
<bryceh> there is one bug in libxi
<bryceh> 968218
<bryceh> but it's not about xinput erroring out, so not your issue.  Yes, file a new one
<bryceh> cnd, make sure you tag it 'precise' so it shows up on our lists
<cnd> bryceh, done, bug 980041
<ubottu> Launchpad bug 980041 in libxi (Ubuntu) "Button mask and labels are reported wrong, array offset of 1 element" [Medium,Fix committed] https://launchpad.net/bugs/980041
<cnd> it's uploaded, just waiting for approval
<cnd> I got it in right before the final freeze, hopefully :)
<bryceh> ok
<bdmurray> what is a better place for bug 979687?
<ubottu> Launchpad bug 979687 in ubuntu-meta (Ubuntu) "After booting i am dropped to console" [Undecided,New] https://launchpad.net/bugs/979687
<bryceh> bdmurray, hmm
<bryceh> bdmurray, stick it in nvidia-graphics-drivers, we'll figure out where it needs to go
<bryceh> sounds like it needs some upstart rule tweakage or something
<bjsnider> here's the problem with that bug:
<bjsnider> NVIDIA: could not open the device file /dev/nvidiactl (No such device or address).
<bjsnider> i wonder fi he installed using the nvidia-installer instead of nvidia-current
<Sarvatt> also he's booting in 13 seconds, did the sleep 1 requirement before lightdm for nvidia to settle for faster booters ever get fixed?
<Sarvatt> RAOF: any idea there?
<Sarvatt> only asking because you were talking about finding that out last uds and might have an idea
<Sarvatt> s/uds/sprint/
<Sarvatt> oh there it is https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/873495
<ubottu> Launchpad bug 873495 in lightdm (Ubuntu) "LightDM fails to start when installed in OEM mode after nvidia-current or nvidia-current-updates are installed" [Medium,Triaged]
<Sarvatt> i think the root of that bug is that lightdm stopped attempting 5 respawns before giving up and gives up at 1 now
<Sarvatt> err 2 attempts
<Sarvatt> -rw-r--r-- 1 root root  35K Apr 12 17:38 /var/log/Xorg.0.log
<Sarvatt> -rw-r--r-- 1 root root  46K Apr 12 14:46 /var/log/Xorg.0.log.old
<Sarvatt> -rw-r--r-- 1 root root  11K Mar  2 16:28 /var/log/Xorg.1.log
<Sarvatt> -rw-r--r-- 1 root root  11K Mar  2 16:27 /var/log/Xorg.1.log.old
<Sarvatt> -rw-r--r-- 1 root root  14K Oct 21 14:30 /var/log/Xorg.2.log
<Sarvatt> -rw-r--r-- 1 root root 6.9K Jul 26  2011 /var/log/Xorg.2.log.old
<Sarvatt> -rw-r--r-- 1 root root  14K Oct 21 14:30 /var/log/Xorg.3.log
<Sarvatt> -rw-r--r-- 1 root root 6.9K Jul 26  2011 /var/log/Xorg.3.log.old
<Sarvatt> -rw-r--r-- 1 root root  14K Oct 21 14:30 /var/log/Xorg.4.log
<Sarvatt> -rw-r--r-- 1 root root 6.9K Jul 26  2011 /var/log/Xorg.4.log.old
<Sarvatt> -rw-r--r-- 1 root root  14K Oct 21 14:30 /var/log/Xorg.5.log
<Sarvatt> -rw-r--r-- 1 root root 6.9K Jul 26  2011 /var/log/Xorg.5.log.old
<Sarvatt> that implies it was changed in october
<Sarvatt> it used to try respawning 6 displays but only does :0 now before dumping to failsafe
<bryceh> I need to add a retry button to failsafe-x
<Sarvatt> Xorg.1.log was me doing it from a VT, it definitely only tries to start once now before dumping to failsafe
#ubuntu-x 2012-04-13
<bjsnider> so lightdm starts too fast for the blob?
<Sarvatt> sometimes, only when its a SSD that i've heard of
<Sarvatt> lightdm starts X when graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1 is satisfied in the upstart script, not when its actually ready which could be seconds later
<Sarvatt> talk about racy
<Sarvatt> modprobe nvidia_current doesnt mean its ready to use
<bjsnider> should be modprobe nvidia since there's an alias
<Sarvatt> how can udev-fallback-graphics.conf be extended to actually wait till its ready is the problem i think
<Sarvatt> yeah same diff
<Sarvatt> its getting satisfied just by modprobing
<Sarvatt> and trying to start
<Sarvatt> but then its loading an 19mb kernel module and setting up /dev/nvidiactl and all the other crap or whatever its called
<bryceh> can we have upstart block until all those nodes exist?
<bjsnider> i don't know how you can be sure they do unless you test for them
<Sarvatt> its an upstart problem for sure but yeah, how does that get fixed
<bjsnider> there's nvidia0 and nvidiactl
<Sarvatt> its an issue on radeon too
<bjsnider> there could also be nvidia1 and so forth and so on if there are more than 1 graphcis cards
<Sarvatt> if x loads radeon instead of it getting modprobed before its almost never ready by the time x starts so they get uninitalized memory copied to the screen and have corruption if they have an ssd
<Sarvatt> its perfectly happy just loading vesafb to satisfy the upstart crap, showing a vesafb splash for .1 seconds before x, x modprobing radeon because its not loaded yet when x-x-v-radeon is tried to load and showing corruption
<Sarvatt> boot -> plymouth -> load vesafb because radeon isnt providing /dev/fb0 via radeondrmfb yet -> lightdm -> start X -> X modprobes radeon because it isnt yet -> copyfb from the transition uninitialized frambuffer contents is the common error i'm seeing there
<Sarvatt> and i cant spell anymore, thats my queue to sleep :)
<RAOF> We certainly can fix udev-fallback-graphics.
<RAOF> We'd do something like start on modprobe nvidia-current, and then have a task that polls for the relevant device nodes to appear.
<Sarvatt> it seems like the same deal to me though, assuming modprobe was successful isnt enough to assume lightdm is ok to start
<Sarvatt> unless its intel
<bjsnider> RAOF, what if the system doesn't have nvidia-current and how do you know if it does and even if it does maybe that's not he driver the user wants to use
<bjsnider> etc.
<bryceh> wonder if the drivers already include some mechanism to flag readiness, and if not, if they'd be open to adding one
<RAOF> bjsnider: Simple - then another start-on triggers.
<bjsnider> just found out nvidia released a new blob today
<RAOF> Ah, the security fix blob is out?
<bjsnider> it is
<Sarvatt> a few days ago?
<bjsnider> i am preparing it
<Sarvatt> it took tjaalton a few days to upload it to precise
<bjsnider> 295.40?
<bjsnider> it just landed in their archive on the 11th by whatever timezone this is
<Sarvatt> it fixed a few other issues too besides the security stuff
<Sarvatt> but yeah unreleased systems, etc, was a super important update on next gen crap
<Sarvatt> broke old cuda though
<Sarvatt> that relied on the security vulnerability to work :)
 * Sarvatt is glad we dont ship cuda stuff
<Sarvatt> need to ping tjaalton and security people to update -current version too
<RAOF> I thought mdeslaur was on that?
<mdeslaur> huh? I fixed stable releases
<Sarvatt> they did nvidia and nvidia-173 and nvidia-96 but not -updates versions
<mdeslaur> Sarvatt: in which release?
<Sarvatt> mdeslaur: https://lists.ubuntu.com/archives/oneiric-changes/2012-April/012027.html holy crap i missed it
<Sarvatt> sorry!
<Sarvatt> its just -updates in precise thats still a problem
<mdeslaur> I don't think 173 and 173-updates in precise got updated either
<Sarvatt> and nevermind nvidia-currents-updates in precise did get an update and i missed it, sheesh, totally sorry for you getting pinged :)
<RAOF> Do we have a version of 173 that works in precise?
<Sarvatt> RAOF: nope
<RAOF> Didn't think so :)
<Sarvatt> there is no 173 thats installable in precise
<mdeslaur> ah, well problem solved :)
<mdeslaur> the only one I didn't update was nvidia-graphics-drivers-updates that's in oneiric-proposed
<bjsnider> when was the last time they touched -173?
<bjsnider> october?
<bryceh> should we drop it?
<bjsnider> i think they make it compatible with the kernel just before an ubuntu release
<bjsnider> used to anyway
<Sarvatt> yeah theres definitely an issue promoting -proposed to -updates for nvidia-graphics-drivers-updates in previous releases
<Sarvatt> wonder how that can be circumvented, i dont think any nvidia driver update has gone to release-updates from release-proposed even though foo-updates was made to be able to update things
<bjsnider> date of last nvidia 173 driver upload: 07-25-11
<Sarvatt> yeah, there was a newer nvidia-173 but it was still xserver 1.10 only
<bjsnider> same date they released the last 96 and 71 blobs
<Sarvatt> i dont think we'll get a 173 for precise, but only alberto knows for sure
<bjsnider> people should just be using nouveau at this point. there's no acceptable excuse
<Sarvatt> sure there is, geforce 6150
<Sarvatt> lots of laptops using IGP nvidia from then
<bjsnider> nvidia-current should support that
<hyperair> Sarvatt: ping.
<hyperair> Sarvatt: is synaptics in precise still responsible for scroll-coasting?
<tjaalton> Sarvatt: hope you meant tseliot there :)
<tjaalton> bryceh: the workqueue links seem broken for some packages like nouveau, drops in the advanced query page
<bryceh> tjaalton, yes, the problem is for packages where the upstream project launchpad name != the source package name, or if no upstream project is set in launchpad, it fails.  this is high on my todo list
<tjaalton> bryceh: ok, it used to work not too long ago though
<tjaalton> so something changed on lp?
<bryceh> tjaalton, sort of but that's not why
<bryceh> they added a way to limit searches to the "official upstream" (as opposed to just any arbitrary upstream project like unity)
<bryceh> the other day I added support for that into the chart, so the workqueue chart can exclude bugs that have already been forwarded upstream
<bryceh> but I'd only tested it with -intel so didn't notice the issue until yesterday
<bryceh> hah bug 980693
<ubottu> Launchpad bug 980693 in gdb (Ubuntu) "System freeze after attaching gdb to Xorg" [Undecided,Invalid] https://launchpad.net/bugs/980693
<bryceh> tjaalton, fixed
<tjaalton> bryceh: great, thanks :)
<tjaalton> hmh, -wacom bugs don't have all the same logs attached as the rest
<Sarvatt> tjaalton: hmm yeah looking at source_xorg.py it only attaches Xorg.0.log for video bugs
<bryceh> yeah if there's anything else we need for -wacom lemme know and I'll stick it in
<Sarvatt> except it does for actual synaptics bugs... weird
<bryceh> (or do a merge request for a branch against xdiagnose)
<Sarvatt> tjaalton: maybe add it to keyboard_packages?
<Sarvatt> those packages seem to be getting good logs attached
<bryceh> no; keyboard_packages should just be keyboard
<bryceh> think we need a separate thingee for non-keyboard inputs
<bryceh> and then move -evdev and -synaptics to that
<Sarvatt> oh yeah see that now, only explination i could come up with why synaptics and evdev get attach_2d_info and wacom doesnt
<bryceh> yeah
<bryceh> Sarvatt, are you doing a patch?  if not, I can.
<Sarvatt> i dont think thats right, thats just adding xkb info the bug.. but http://paste.ubuntu.com/928396/
<Sarvatt> maybe better to just unconditionally attach the xorg logs for everything? :P
<bryceh> hmm, there is a is_xorg_input_package() routine
<bryceh> but that includes a check for xf86-input
<Sarvatt> yeah i'm not getting why synaptics and evdev include video info
<Sarvatt> none of the debugging interest stuff is on there either https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/980834
<ubottu> Launchpad bug 980834 in xf86-input-wacom (Ubuntu) "Intuos4 not working after unplugging and plugging back in usb cord" [Undecided,Incomplete]
<Sarvatt> thats actually the only apport collected wacom bug in precise :P
<Sarvatt> hmm found a closed one, https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/949097 and it does have video info on it
<ubottu> Launchpad bug 949097 in gnome-settings-daemon (Ubuntu) "Serial Wacom Tablet touch not in absolute mode when logged in" [High,Fix released]
<Sarvatt> maybe that first one gave up after CurrentDmesg: Error: command ['sh', '-c', 'dmesg | comm -13 --nocheck-order /var/log/dmesg -'] failed with exit code 1: comm: /var/log/dmesg: Permission denied
<bryceh> yeah that could be
<bryceh> thought I had a check for permissions on that though.  *digging*
<bryceh> actually hmm.  dmesg is collected by apport itself, not our hook
<kklimonda> hey, what's the status of blue tint on nvidia drivers? does someone has a bug number I can subscribe to? :)
<kklimonda> (it's irritating as I can't really remove libvdpau and adding workarounds to mms.cfg makes flash plugin really unstable)
<kklimonda> (blue tint in youtube videos on nvidia drivers to be exact.. sigh, too much things on my head)
<Sarvatt> kklimonda: looks like https://bugs.launchpad.net/ubuntu/+source/adobe-flashplugin/+bug/967091
<ubottu> Launchpad bug 967091 in adobe-flashplugin (Ubuntu) "Wrong tint with Nvidia after upgrading to 11.2" [Undecided,Confirmed]
<kklimonda> Sarvatt: yeah, that's the one. Thanks :)
<Sarvatt> its funny because google led me to your blue tint bug from nvidia setting the wrong hue years ago
<Sarvatt> but that was with xv
<bryceh> Sarvatt, any other apport hook tweaks before I upload?
<kklimonda> ah yes, I remember that bug - seems like nvidia is bend on making me see blue people everywhere ;)
<Sarvatt> bryceh: cant think of any, not even sure that one is needed since it was attaching good info previously and that bug is an anomaly :)
<bryceh> yeah, it's kind of a corner case where this is even an issue
<bryceh> the bulk of our bugs get filed against xorg, so all the right info is going to be included
<bryceh> however LTS means a long time, and that can mean many bug reports...
<bryceh> Sarvatt, fixes uploaded
<tjaalton> oh, thanks guys.. was building a puzzle and couldn't reply :)
<imbrandon> ok i got an issue
<imbrandon> if somone is arround, i got 3 montors, 2 work fine, 3rd is greenscreen
<imbrandon> i create a conf file for the 3rd
<imbrandon> and put it in X11/conf.d dir
<imbrandon> and then ONLY the 3rd works
<imbrandon> anyone got a moment to help me sort this out ?
<imbrandon> http://paste.ubuntu.com/928611/
<imbrandon> that conf makes the 3rd one work fine, but only that one
<imbrandon> the first two are hooked up via seperate dvi, the 3rd is usb displaylink adapter
#ubuntu-x 2012-04-14
<LLStarks> hi, i haven't been able to get the nouveau module to load for the past few weeks
<LLStarks> i get FATAL: Module off not found.
<LLStarks> not sure what that's supposed to mean
<Sarvatt> LLStarks: that means you have nvidia-current installed i believe
<Sarvatt> can't use wayland with it installed
<Sarvatt> err cant use nouveau sorry
<Sarvatt> nouveau is aliased to off in the nvidia package
<LLStarks> that's harmful towards my hybrid-graphics testing
<LLStarks> i can't switch drivers on the fly
<Sarvatt> of course you cant, nvidia sets up alternates for all of the mesa and x crap you  need to be using to use nouveau
<LLStarks> well, i could before
<LLStarks> but now i can't
<Sarvatt> it hasnt changed in a few releases
<LLStarks> i'm getting invalid symbols and crap
<Sarvatt> i dont know what you're doing but assuming bumblebee, update-alternatives switching to mesa needs to be called switching to mesa instead of nvidia the same as it has for the past few releases
<LLStarks> nouveau.ko will not load
<LLStarks> no matter what
<LLStarks> i'm not worrying about mesa or the ddx
<Sarvatt> using the nvidia alternates sets up the blacklist for nouveau
<LLStarks> >nvidia-current_hybrid.conf
<LLStarks> really?
<LLStarks> alias nouveau off
<Sarvatt> nothing has changed there, i dont know what changed for you recently because thats weird, its been 2 releases since its changed
<LLStarks> wyf
<Sarvatt> yeah
<Sarvatt> using nvidia does that
<LLStarks> this is new
<Sarvatt> new as in 11.04
<LLStarks> don't do this
<LLStarks> it's not necessary
<Sarvatt> dont tell me, tell tseliot, or tell whatever stuff you're using outside of the distro thats not calling update-alternates to switch to mesa when you switch to nouveau
<LLStarks> leave the modules alone, alternates are the only thing that need to be messed around with until PRIME lands later this year
<Sarvatt> the alternates set up the blacklist, if its switching it should be fine
<Sarvatt> maybe whatever you're using isn't calling update-initramfs to remove the blacklist from the initrd?
<LLStarks> it's not switching
<LLStarks> if i want to use wine, i need to modify the ld_library_path
<LLStarks> afaik, nouveau loading first does not harm nvidia-current
<Sarvatt> sure it does, it refuses to load if you do it
<Sarvatt> nvidia prints messages about how you need to blacklist nouveau to use it
<LLStarks> it's not a problem for me if nouveau is available
<LLStarks> or loaded for that matter
<LLStarks> the focus should be on keeping the card off using bbswitch as opposing to letting any driver load unless explicitly modprobed
<Sarvatt> LLStarks: keeping bbswitch internal to something not in any distro doesn't help that cause :) bbswitch is awesome.
<LLStarks> Sarvatt, well, it's the one thing that none of the people at dma_buf prime haven't considered
<LLStarks> there is no other acpi solution
<LLStarks> *people hacking away at
<alex_mayorga> Can anyone here look at https://bugzilla.mozilla.org/show_bug.cgi?id=745481 should I file it to launchpad too?
<ubottu> Mozilla bug 745481 in Untriaged "MapsGL doesn't render properly on nouveau" [Normal,New: ]
<Sarvatt> alex_mayorga: wow, you can use mapsgl on nouveau? its a constant stream of gpu hangs on intel, i'm amazed webgl on mesa isn't blacklisted in firefox but other webgl pages do work fine
<alex_mayorga> Sarvatt: I could until a few days ago =(
<alex_mayorga> Filed it on Launchpad as the problem happens on Chromium Bug #981883 
<ubottu> Launchpad bug 981883 in xorg (Ubuntu) " MapsGL doesn't render properly on nouveau" [Undecided,New] https://launchpad.net/bugs/981883
<alex_mayorga> Ask me anything =)
<LLStarks> mapsgl just sucks
<Sarvatt> chromium shouldn't even allow webgl on mesa 8 because its busted, what chromium are you using?
<LLStarks> it doesn't work right with snb
<tjaalton> alex_mayorga: could you file it upstream? :)
<alex_mayorga> Sarvatt: 18.0.1025.151 (Developer Build 130497 Linux) Ubuntu 12.04
<alex_mayorga> tjaalton: How?
<Sarvatt> oh maybe its just fixed in later chromium, not the one in the archive :( i'm on 20.x
<alex_mayorga> Sarvatt: I use Mozilla's Nightly too and is the exact same bad rendering so I don't think is the browser
<tjaalton> alex_mayorga: fdo mesa, nouveau dri
<alex_mayorga> Sarvatt: Where do you get latest Chromium from? The PPA I have hasn't been updated in ages
<alex_mayorga> tjaalton: Let me give that a try
<Sarvatt> alex_mayorga: yeah its not, but mesa doesn't work well with webgl and needs to be blacklisted :( theres a very high chance any fix wont even be able to be backported to SRU to precise too now that nouveau is getting reworked
<Sarvatt> oh sorry i meant chrome not chromium, gave up on chromium because the daily builds stopped too
<alex_mayorga> Maybe I got that into myself https://bugzilla.mozilla.org/show_bug.cgi?id=729817#c50 =(
<ubottu> Mozilla bug 729817 in Graphics "freezes and crashes @ nouveau_dri.so when on github" [Critical,Verified: fixed]
<Sarvatt> hmm INTEL_HIZ=0 fixes mapsgl on intel
<bjsnider> Sarvatt, how do you expect ivybridge to be working with precise in terms of stability and performance?
<alex_mayorga> I can tell that it was working fine some weeks ago
<Sarvatt> bjsnider: its awesome, unless you care about eDP or the limited 3 head support they have :)
<bjsnider> edp?
<Sarvatt> internal some video connection laptops use
<Sarvatt> bjsnider: 11.10 is great on ivybridge too, thats mostly what i've been doing since the OEM machines will ship with 11.10
<alex_mayorga> http://webglsamples.googlecode.com/hg/aquarium/aquarium.html still works fine on Nightly, so maybe is Google's fault after all
<mlankhorst> is ivy bridge out yet?
<Sarvatt> except it needs oneiric-updates, they broke things in vbios 2 times after 11.10 came out
<Sarvatt> mlankhorst: nope..
<bjsnider> the release date is the 23rd i think
<mlankhorst> aw
<alex_mayorga> tjaalton: Should I still file upstream?
<alex_mayorga> Looks more like a "page issue"
<mlankhorst> does it overclock better than sandy bridge? :p
<Sarvatt> no clue, reference boards and laptops i have dont allow overclocking
<mlankhorst> ah sad, running my 2500k pretty stably on 4.6ghz 24/7, ivy would probably be slower than that :)
<bjsnider> not for graphics
<bjsnider> the metrics i've seen it hit are a lot higher than sandybridge
<Sarvatt> if you're overclocking a desktop its safe to say you arent using an IGP :)
<mlankhorst> yeah
<imbrandon> ok whom can i bribe with hardware to make my usb displaylink dvi adapter "just work" , its got me pulling my hair out
<jwi> imbrandon: i think 3.4 has a new driver for those devices
<imbrandon> 3.4 ?
<imbrandon> sorry i'm wayyyy un X knowhow, been hacking linux for years, X is black magic to me
<imbrandon> i'm guessing Xorg 3.4 ? i'm on precise upto date with the xorg-displaylink driver installed
<jwi> imbrandon: the upcoming 3.4 linux release :)
<imbrandon> ahhh
<imbrandon> kernel :)
<imbrandon> kk
<imbrandon> well i kinda have it working 
<imbrandon> sorta
<imbrandon> lol
<imbrandon> its green screen on boot ( its a 3rd monitor ) other two are native diplay port on a mac mini
<imbrandon> and i can add a conf file to the .d dir
<imbrandon> and reboot and it works perfect
<imbrandon> peoblem is the other two are then out of commission 
<imbrandon> heh
<imbrandon> so that is where i lay. broken and only 2 of 3 displays working :(
<imbrandon> but i do have an extra on my desk :)
<imbrandon> usb adapter not display :)
 * imbrandon wonders off, anyone hilight my name if you have ideas , i'm game, and if it helps i'll send you one to keep if it takes that
<alex_mayorga> Sarvatt, tjaalton : So should I upstream the bug?
<Sarvatt> alex_mayorga: it would be much appreciated if you would pass it along to bugs.freedesktop.org because it needs to go there to get fixed, but i dont think anyone will respond honestly and blacklisting webgl which you convinced mozilla to stop doing is the more appropriate option  :(
#ubuntu-x 2012-04-15
<tjaalton> bryceh: hmm, check out the intel bug reports.. think maybe the xdiagnose update caused it to report GPU lockup bugs?
<tjaalton> or was the latest upload meant to fix that?-)
<bryceh> tjaalton, the upload fixed exec permissions on a bunch of scripts including that one
<Sarvatt> cnd: safe to say your synaptics fix for the 11 finger issue fixed my macbook air, over a week of closing the lid again and its not crashing X
<Sarvatt> cnd: thank you so freaking much for fixing that :)
#ubuntu-x 2013-04-08
<tjaalton> 4/win 21
<tjaalton> bah
<tjaalton> hmm, either mesa 9.1 has no bugs, or noone tested it
<bryce> heh
<ScottK> Not testing is the more sure way to have no bugs.
<tjaalton> yep :/
<tjaalton> ScottK: do you have intel gfx btw, and if so mind giving it a go with kwin?
<ScottK> I do, but the relevant machine is dead ATM.  Need to do a reinstall first.
<tjaalton> ah, ok
<ScottK> (not happening tonight as it's almost time for bed)
<tjaalton> sure thing
<RAOF> I've been using the Mir mesa for some time - that's based on 9.1-rc2 and so suffers from everyone's favourite terrible dash performance, but aside from that everything works.
<tjaalton> RAOF: yeah, and that's fixed on the ppa one
<mlankhorst> morning
<mlankhorst> tjaalton: hey I run mesa 9.1 here, though not the official packaged version, just the cherry picked git snapshot
<mlankhorst> bryce: did you upload ubuntu5 xserver?
<bryce> no
<mlankhorst> ok good :)
<tjaalton> hmm yeah I think we could just update mesa to the 9.1 snapshot
<tjaalton> and 9.1.2 coming next friday-ish
<mlankhorst> just keep what's there now and get it in ubuntu first..
<tjaalton> ok :)
<tjaalton> I'll just add e6616948b
<mlankhorst> looks good to me
<tjaalton> pushed
<mlankhorst> I'm going to test the drm_device_keep_trying on panda first before I push it, seemed to have worked on my macbook now, tegra too, so just omap remaining
<mlankhorst> more annoying than I thought, blob is fragile, easiest way seems to be unsquashing squashfs, and trying from there
<mlankhorst> welp, it worked
<mlankhorst> [    20.218] (II) config/udev: Adding drm device (/dev/dri/card0) card0 /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
<mlankhorst> [    20.218] (II) config/udev: Ignoring already known drm device (/dev/dri/card0)
<mlankhorst> cute, race triggers on nfs too
<mlankhorst> hm maybe not a race, triggers second time too
<tjaalton> so i915 gen5 still has slow blur
<tjaalton> well, didn't even know it had regressed until now
<mlankhorst> just push and sru later?
<tjaalton> maybe
<mlankhorst> I think I found my suspend failure
<ppisati> guys, i heard there was a fix for x-input in R bt that was hard to backport to Q
<ppisati> something about touchscreen input that impacts our nexus7 img
<ppisati> can anyone confirm it?
<ppisati> (and sorry for the lame description :) )
<tjaalton> ther is no fix in raring
<tjaalton> what I have crashes the server after opening the dash and touching somewhere
<ppisati> tjaalton: ah
<ppisati> tjaalton: i was told different
<mlankhorst> tjaalton: hm shall I try to figure out the touch crashing issue in 1.14 branch?
<tjaalton> mlankhorst: it's not the same crash
<tjaalton> aiui
<mlankhorst> tre
<mlankhorst> true*
<mlankhorst> but I want to get 1.14 with patches working stably first
<tjaalton> ok
<mlankhorst> wow, reading through the input stack is weird
<mlankhorst> it's like an onion, layers, layers, layers..
<ogra_> and smelly ... 
<mlankhorst> hm fun, guess it's a magic union
<mlankhorst> any bets on the magic thing where it crashes on being pointer barriers?
<tjaalton> the guy on the upstream bug says the crasher was there with 1.13 too
<tjaalton> so not that
<mlankhorst> tjaalton: the specific function hasn't been touched since before 1.12 or so
<mlankhorst> anyway it looks like I may have a fix
<tjaalton> mlankhorst: this was the memory corruption crasher you were able to repro with synaptics?
<mlankhorst> yeah I think so
<mlankhorst> if you look at ProcessTouchEvent, there are 2 destinct structs, ev->device_event and ev->touch_ownership_event, in a union with different sizes
<mlankhorst> and first thing that function does is int emulate_pointer = ! !(ev->device_event.flags & TOUCH_POINTER_EMULATED);
<mlankhorst> device_event.flags is at a different offset than touch_ownership_event.flags
<mlankhorst> ev->device_event.corestate
<mlankhorst> ends up saving at some random offset
<mlankhorst> seems to be a lot better at surviving now..
<mlankhorst> yeah, that fixed the valgrind error for me
<mlankhorst> \o/
<mlankhorst> no more random memory corruptions
<tjaalton> cool, i'll try if it fixes my crasher too
<mlankhorst> considering each time you pressed you ended up corrupting some random memory, most likely
<mlankhorst> seems I didn't fix my nouveau suspend bug when I leave my pc off for longer periods though, boo :((
<tjaalton> well the one with 1.13 + backports happened almost instantly
<tjaalton> look at the backtrace on the upstream bug
<tjaalton> open dash - touch the indicators - boom
<mlankhorst> random memory corruption is random :P
<tjaalton> well the way to reproduce was different than on 1.14, and very easy :)
<tjaalton> but anyway, I'll try it
<tjaalton> mlankhorst: doesn't apply on top of the backports ;)
<mlankhorst> I'm sure you can find a way to do it manually :p
<tjaalton> yeah, tomorrow
<tjaalton> ah, it was easy
<tjaalton> building
<tjaalton> rebooting the nexus
<tjaalton> crashed
<tjaalton> so it wasn't that :)
<mlankhorst> boo different bug then, I could reproduce the corruption on 1.13.3 too though iirc
<tjaalton> hope it isn't fixed by the barrier work in 1.14
<tjaalton> testing one other commit now
<tjaalton> nope, not that..
<llstarks> bryce, re your changes to the hybrid spec. shall i assume this work is postponed until amd and nvidia publish egl drivers?
<tjaalton> the diff is just changing the assignee?
<bryce> yeah just an assignee change
<llstarks> to in-house?
<tjaalton> raof is in-house :)
<bryce> raof's busy with mir now, so freeing the WI's for anyone else that might want them
<bryce> community owners would definitely be fine; I probably should have set them to ubuntu-x-swat actually
<llstarks> when i see canonical-x, i interpret that as "secret project for the next few months" :)
<bryce> llstarks, fair enough; updated
<llstarks> that wasn't the problem, i was referring to the changes a few days ago. i'm just wondering where this work fits in when slutty snail is going to probably focus on mir and the converged platform
<bryce> llstarks, I think you answered your own question there...
<llstarks> thanks for the clarification
<bryce> llstarks, basically it's backburnered in favor of phone stuff, but as low hanging fruit becomes available we can certainly look into it.  And help on anything in this space is welcomed.
<llstarks> i plan to do some experimental mir+optimus stuff over the next few weeks
<llstarks> uncharted territory
<tjaalton> mlankhorst: so it's the same trace after all what I'm seeing, both with 1.13+backport & 1.14
<tjaalton> xi2mask_isset returns 0
<tjaalton> enough for today..
<RAOF> llstarks: Cool. You should be able to have a bit more fun with that soon, after use-dma-buf has landed.
<llstarks> fun, but not much in the way of code though. maybe a script or two if i have time. modprobe.d hybrid stuff needs an overhaul, so maybe i'll look at that too.
#ubuntu-x 2013-04-09
<mlankhorst> morning
<RAOF> Yo yo!
<tjaalton> plymouthd seems to crash here on boot
<mlankhorst> because of the race?
<mlankhorst> bbbbaaacktrace!
<tjaalton> no, it doesn't race anymore after changing lightdm.conf locally
<tjaalton> I guess the crash was the reason it was racing so reliably :)
<mlankhorst> haha
<tjaalton> the plymouth crasher is bug 733453
<ubottu> bug 733453 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in script_obj_deref_direct()" [High,Confirmed] https://launchpad.net/bugs/733453
<mlankhorst> valgrindddd
<tjaalton> how to run it during boot?
<tjaalton> just edit init/plymouth.conf?
<mlankhorst> I guess so, don't see why that wouldn't work
<mlankhorst> though you'd want to pipe the output to somewhere
<mlankhorst> &>> /run/something
<tjaalton> right
<seb128> tjaalton, mlankhorst: you also have the good old trip of "mv bin bin.real" and make "bin" a wrapper script calling valgrind bin.real --log-file=/tmp/...
<seb128> trip->trick
<mlankhorst> seb128: well in case of X I just change the symlink in /etc/X11/X to point to my wrapper script
<seb128> well, if you have a symlink, sure you can just change the target
<seb128> but most binaries don't have a smylink
<mlankhorst> true
<tjaalton> hmm, either it's not working or logging is somehow off
<tjaalton> --log-file=foo that is
<tjaalton> tried /tmp and /run
<mlankhorst> tjaalton: root is ro at that point, maybe point to /dev ?
<mlankhorst> oh and plymouth might fork
<mlankhorst> so you'd need --trace-children=yes
<tjaalton> ok
<tjaalton> still nothing
<mlankhorst> hmz..
<tjaalton> hrm, alt-tabbing is slow on ivb
<tjaalton> with mesa 9.1
<seb128> tjaalton, is plymouth working? your wrapper is correctly +x and call the full path to the binary?
<mlankhorst> he's modifying the init script
<tjaalton> seb128: yep
<tjaalton> tried both
<mlankhorst> my guess is root still rootonly since it gets called before mountall
<tjaalton> now I have a wrapper
<seb128> try doing an echo"test" > /tmp/debug
<tjaalton> right
<tjaalton> root is ro, nothing
<tjaalton> tried /dev, /run, /tmp
<mlankhorst> heh
<mlankhorst> mkdir /dummy
<mlankhorst> and in the init script /sbin/mount -n -t tmpfs /dummy /dummy
<tjaalton> didn't get that to work either, maybe need to add an initramfs hook or something
<tjaalton> but did check how mesa performance has dropped on gen4 i915..
<tjaalton> that or the dash has changed dramatically since precise
<tjaalton> lunch ->
<mlankhorst> oh cool, git-bzr works well enough to clone a repository
<tjaalton> hum, what's bug 1134492 about then
<ubottu> bug 1134492 in xorg-lts-quantal (Ubuntu) "xserver-xorg-lts-quantal breaks Kubuntu" [Undecided,New] https://launchpad.net/bugs/1134492
<mlankhorst> presumably libegl stuff
<mlankhorst> iirc kwin depends on libegl, which we don't install by default
<tjaalton> ah
<tjaalton> but doesn't kubuntu 12.04.2 use the backport stack?
<tjaalton> iirc it does
<mlankhorst> the bug is about installing kubuntu-desktop separately, I believe
<mlankhorst> oh wait kubuntu-desktop is kept, lts-quantal is installed after
<tjaalton> kubuntu-desktop installs just fine here
<mlankhorst> it will install fine, the bug is about installing kubuntu-desktop first, then installing xserver
<mlankhorst> and having a resolution that will remove kubuntu-desktop i believe
<tjaalton> good thing I've booted 12.04.1 off a usb stick
<tjaalton> so I can try :)
<mlankhorst> I forgot which one it was though
<mlankhorst> tjaalton: hah I have a ssd and a chroot, race you to it!
<tjaalton> :)
<tjaalton> i have a local mirror
<mlankhorst> wait libglu gets removed, why ._.
<mlankhorst> oh nm
<mlankhorst> that user just misconfigured his stuff
<mlankhorst> no alarm
<mlankhorst> Empfohlene Pakete:
<mlankhorst>   libgl1-mesa-glx-lts-quantal
<tjaalton> recommends not enabled?
<mlankhorst> indeed..
<tjaalton> heh
<ogra_> note that flavours like lubuntu do that by default
<mlankhorst> not my problem
<ogra_> (no idea about kubuntu, but they might too)
<mlankhorst> though I guess I could explicitly enable it
<tjaalton> meh, blur/fade regressed on haswell too
<tjaalton> with mesa 9.1
<tjaalton> what a fail
<tjaalton> the recent work in master made it better but it's still worse than it was with 9.0
<mlankhorst> the question we should be asking is whether it can be resolved in time or not :/
<tjaalton> right
<tjaalton> wonder if git master builds
<mlankhorst> not with radeon afaik
<tjaalton> bah
<tjaalton> hm, I could just try reverting the bad commit that caused the perf regression
<tjaalton> no change on hsw, although it seems it didn't regress after all..
<tjaalton> snb is just as happy with the revert as with the 19 patches
<tjaalton> so looks like it worked there
<tjaalton> who cares about serious sam 3 performance anyway? :)
<bryce> tjaalton, did you chat with slangasek about 9.1 in raring?
<seb128> bryce, tjaalton: what's the status on the performances issues of the new version on gen5 cards? that should probably be resolved before talking about landing the update...
<Sarvatt> https://devtalk.nvidia.com/default/topic/539249
<bryce> seb128, 6 lines up tjaalton says he has been trying to revert the problematic patch; no luck so far
<seb128> bryce, ok, I restarted my IRC and didn't have that backlog, thanks
<bryce> seb128, I suggested talking with slangasek or another release admin before landing it with any regressions
<bryce> seb128, ah I may have misread his comments; sounds like he successfully reverted the change but hasn't yet confirmed the fix on gen5 hardware, I guess
<tjaalton> bryce: not yet
<tjaalton> bryce, seb128: pitti tested the reverted version, it's better than the ppa version but slightly worse than 9.0.3 on raring
<tjaalton> does anyone have IVB to test on?
<tjaalton> I do, but it means killing my session :)
<tjaalton> so, this latest one with just the one revert on top of 9.1.1 looks like the best solution for now
<tjaalton> uploaded -intel 2.21.6
<mlankhorst> \o/
<tjaalton> fixes at least one bug
<mlankhorst> push to git?
<tjaalton> done
<mdeslaur> so...in quantal, what exactly is supposed to install the proper kernel headers so the nvidia dkms module gets built?
<mlankhorst> tjaalton: oh can you add --enable-valgrind to rules?
<tjaalton> it's on the queue
<mdeslaur> I can't believe this doesn't even work out of the box
<tjaalton> mdeslaur: the image should have it, but there was a bug in the builder that removed them..
<mlankhorst> ah nm it should have VG enabled afaict
<tjaalton> quantal is so passÃ© anyway :)
<tjaalton> mlankhorst: well this one should first get past the queue :)
<mdeslaur> tjaalton: so if you install nvidia once your quantal is up-to-date, it doesn't actually work without you manually installing the kernel headers?
<tjaalton> mdeslaur: correct
<tjaalton> I think
<tjaalton> haven't tried
<mdeslaur> awesome. guess 2013 isn't the year of the linux desktop.
<tjaalton> hehe
<tjaalton> well technically that was in 2012
<mlankhorst> tjaalton: I just want valgrind so I can get rid of most false positives on a default boot, and only get the USEFUL backtraces :P
<tjaalton> surely 13.04 will kick butt, and include other bugs
<mdeslaur> tjaalton: I included a 6 month SRU grace period :P
<tjaalton> mdeslaur: nobody cares about quantal, other than maybe because of the lts backport stack
<mlankhorst> that^
<mlankhorst> if people cared about quantal my xxv-nouveau would have been accepted a lot sooner in quantal-proposed
<mlankhorst> been a month now?
<mdeslaur> the people who opposed turning non-lts releases into a rolling release should be _forced_ to do sru maintenance and testing :P
<mlankhorst> I'm not against rolling releases, but I think waiting for raring to be released first wouldn't have been a bad idea
<mdeslaur> well, that's a separate issue
<tjaalton> mdeslaur: yeah rolling ftw, interim releases are a big pita
<mlankhorst> nobody cares about the interim :/
<mlankhorst> people care more about the quantal lts stack in precise than about quantal
<tjaalton> flavors do, but for how long
<tjaalton> I hope this can be revisited after T
<llstarks> i'd like a rolling repo
<llstarks> i'm only on "stable" ubuntu for maybe a day or two each year anyway. release and toolchain upload are now simultaneous though
<llstarks> i'm going to test nvidia 319.12, i want to see what xrandr outputs with the new randr 1.4 support for optimus
<llstarks> http://us.download.nvidia.com/XFree86/Linux-x86/319.12/README/randr14.html
<llstarks> they're basically telling us how to implement it
<bjsnider> llstarks, it is good news for optimi users, no?
<llstarks> i don't know yet. it's an always-on driver situation. nvidia+modesettng
<bjsnider> if you use the nvidia-installer be careful it doesn't overwrite anything
<llstarks> i'm still trying to figure out the xorg.conf
#ubuntu-x 2013-04-10
<llstarks> Testing new nvidia blob. Very exciting and hope to figure out the randr 1.4 stuff soon
<mlankhorst> it only supports UDL from what I can tell
<mlankhorst> no optimus yet
<RAOF> And can't be a render slave?
<mlankhorst> well thats what i gathered from actually reading the readme
<RAOF> Likewise.
<llstarks> I'm 90% of the way to getting this setup. X just wants to be black 
<llstarks> But nvidia is rendering something in the background
<mlankhorst> from what I can tell it won't cooperate with intel unless intel is the slave
<llstarks> Instead of modeset?
<mlankhorst> well modeset too
<mlankhorst> anyway there's always nouveau to play with
<mlankhorst> it actually has a drm driver that does more than passing around a page array :P
<llstarks> Nvidias optimus xorg.conf confuses me. How do specify my lvds output
<tjaalton> anyone here have radeon SI?
<tjaalton> aka HD7xxx or such
<tjaalton> packaging glamor atm..
<tjaalton> project name is 'glamor', tarball glamor-egl, builds libglamor, and it's hosted under xorg/driver..
<tjaalton> something is not right
<RAOF> tjaalton: I do, but I'd need to build a desktop system to actually power it ;/
<tjaalton> ah :)
<tjaalton> ok, I'll keep on looking
<tjaalton> if mesa 9.1 is accepted there's little reason not to add glamor too
<tjaalton> I have a new (unreleased) card, but it's not SI based :/
<tjaalton> despite the promisingly high model number
<tjaalton> hmm the hwe guys certainly does have those
<tjaalton> *do
<RAOF> How can you possibly have an unreleased card that's *not* SI based?
<RAOF> They're releasing more last-gen cards?
<tjaalton> it's a low-spec one
<mlankhorst> RAOF: nvidia still does fermi cards
<RAOF> <sigh>
<llstarks> the all new radeon 7120! now with gcn-free blast processing!
<jwi> RAOF: they're releasing the same last-gen cards as last year, with new labels
<tjaalton> sorry to disappoint, but it actuall stars as HD8xxx :)
<tjaalton> *starts
<mlankhorst> woops
 * mlankhorst notes you need a working card to start xserver
<RAOF> Heh
<mlankhorst> and I just completed my lazy chroot thing
<mlankhorst> ~/nfs/linux$ enter q64
<mlankhorst> quantal-amd64.local:~/nfs/linux$ 
<mlankhorst> ~/nfs is bind mounted
<Prf_Jakob> slightly off topic, but I'm guessing there is some overlap, does anybody know where the debian X team hangs out?
<tjaalton> Prf_Jakob: on #debian-x @oftc
<Prf_Jakob> k thanks!
<tjaalton> hum, the simplified lightdm.conf on the race bug doesn't seem to work
<tjaalton> good thing I tested it first :)
<mdeslaur> ok, nvidia 304.88 released for precise and quantal
<mlankhorst> unsurprisingly
<tjaalton> really?
<tjaalton> mdeslaur: cool
<tjaalton> hmm wait, it's something else
<tjaalton> i've somehow broken plymouth
<mlankhorst> do you still have that plymouth valgrind thing running?
<tjaalton> no
<tjaalton> moved the binary back in place
<tjaalton> and even reinstalled the package
<tjaalton> it's funny that plymouth-splash.conf says "plymouth must be started asap to avoid racing with gdm.."
<tjaalton> orly
<tjaalton> ?
<tjaalton> anyway
<tjaalton> as I feared..
<tjaalton> another race! :)
<tjaalton> now plymouth-splash stops too early
<tjaalton> this is with my laptop which never(?) had the original race
<tjaalton> ok, need to fix plymouth-stop.conf then
<tjaalton> as well
<tjaalton> huh, didn't work
<tjaalton> thought that plymouth-splash shouldn't stop before *dm is running
<tjaalton> guess this is the price we pay for having an event based init >:/
<Sarvatt> adding a sleep 2 is the only thing that is working on oem machines that hit it reliably, had them test all kinds of different things including the various xserver patches :(
<tjaalton> also the lightdm.conf change?
<Sarvatt> yeah a few different permutations of it, slangaseks and the one you said was working for you
<tjaalton> guess they hit what i'm seeing now
<Sarvatt> (neither of those worked for me, slangasek's didn't even start lightdm)
<mlankhorst> Sarvatt: can I see the plymouth debug log and lightdm log from a failing boot with the depend on started plymouth-splash fix in place?
<Sarvatt> mlankhorst: 3 layers of QA indirection involved outside of the company, I couldn't even get any logs.. 
<tjaalton> i can
<mlankhorst> plus xorg.0.log from that boot too
<mlankhorst> oh great
<tjaalton> quite simply it's plymouth-splash that's stopped along with plymouthd, so lightdm has no chance of starting at that point
<mlankhorst> so the 'stopped plymouth' line is really needed then?
<tjaalton> hmm right
<tjaalton> that's what my desktop had all the time
<mlankhorst> I was hoping it wouldn't be needed, ah well :/
<Sarvatt> hmm we dont have http://cgit.freedesktop.org/plymouth/commit/?id=a6129abfc527ac247685d80fc5c20144be1badca it looks like
<tjaalton> works again, with the side-effect that the handoff to lightdm isn't smooth
<Sarvatt> or http://cgit.freedesktop.org/plymouth/commit/?id=6ccedf7b6ecdc8314ed97355cfe5499fffb13a1e
<mlankhorst> sounds useful
<Sarvatt> so if you see plymouthd crashing again ( i remember you hitting that tjaalton?) it might be worth adding those
<tjaalton> yeah
<tjaalton> it was on the desktop
<mlankhorst> oh
<mlankhorst> could plymouth-stop not depend on lightdm?
<mlankhorst> might make that specific race less likely
<mlankhorst> hm then again seems to be a noop for that dm
<ogra_> mlankhorst, plymouth-stop is also used on servers
<ogra_> no dm there 
<mlankhorst> why is it so hard to just get a machine to crash
<ogra_> use a hammer :)
<mlankhorst> 'use hammer on OEM'
<mlankhorst> it's not very effective
<ogra_> oh
<ogra_> optimus support 
<mlankhorst> not optimus
<ogra_> hmm, then the german news sites lie 
<mlankhorst> it still fails on muxless afaik
<ogra_> ah, yeah, they talk about still missing kernel bits
<Sarvatt> which is everything newer than sandybridge era pretty much
<mlankhorst> not even kernel bits
 * ogra_ fell for the headline 
<mlankhorst> well kernel bits too
<mlankhorst> but more basically xserver needs to support gpu screens
<dupondje_> mmmm, nvidia finnaly has Optimus support on Linux :) Anyone tried it yet ?
<ogra_> dupondje_, see the last 20 lines ?
<dupondje_> ah no :p
<dupondje_> ah well, gonne try it out :) see what it does
<tjaalton> mlankhorst: still want the debug log?
<Sarvatt> tjaalton: i'd like to see it to compare to a good boot if ya don't mind, haven't been able to hit a race while using plymouth:debug
<tjaalton> http://pastebin.com/ZGpffWpy
<tjaalton> something stops plymouth before lightdm is ready to start
<tjaalton> I have bootcharts too
<Sarvatt> so you're getting plymouth quit called and [ply-terminal.c]                    ply_terminal_deactivate_vt:couldn't deallocate vt 7: Device or resource busy, i'm getting lightdm doing a plymouth deactivate and it working fine
<tjaalton> I think that's just fallback from the way it fails
<tjaalton> since it's actually changing the vt
<tjaalton> eh
<tjaalton> fallout
<tjaalton> bbl ->
<mlankhorst> plymouth ping, then plymouth quit? hmz
<mlankhorst> tjaalton: I need the xorg/lightdm/plymouth debugs from a single boot to understand this
<tjaalton> mlankhorst: there is no xorg/lightdm logs from this boot
<tjaalton> since lightdm doesn't get started
<mlankhorst> ah
<mlankhorst> who is telling plymouth to quit, then?
<tjaalton> dunno
<tjaalton> kill timeout 60
<tjaalton> though it exits way earlier, so not that :)
<mlankhorst> pre-stop execs plymouth quit
<tjaalton> yep, lol
<mlankhorst> what is JOB in pplymouth-stop ?
<tjaalton> no idea
<mlankhorst> meh could you add some destinctiveness? it seems plymouth quit ignores everything that follows
<mlankhorst> so you could just add something like plymouth quit calledfromXXX to each point in /etc/init
<mlankhorst> hopefully that will tell you from the log who called it
<tjaalton> gah, had the hung compiz after user-switch again, with mesa 9.1
<tjaalton> feels like it's a ivb specific bug then
<tjaalton> mlankhorst: it's from plymouth-stop
<mlankhorst> I feared so
<tjaalton> makes absolutely no sense to me
<mlankhorst> could you see what $JOB is?
<tjaalton> where?
<mlankhorst> by adding it as argument
<mlankhorst> in plymouth-stop
<tjaalton> ah
<tjaalton> "rc"
<mlankhorst> well I was right in my guess then
<mlankhorst> but.. why the f
<tjaalton> what guess?-)
<mlankhorst> can you dump $RUNLEVEL ?
<tjaalton> N 2
<mlankhorst> (my guess that $job would be rc)
<tjaalton> oh in the job?
<mlankhorst> yeah see what runlevel it believes has stopped
<mlankhorst> I guess if you said that RUNLEVEL was 2, it would mean that everything in rc2.d before plymouth started
<mlankhorst> tjaalton: ^  correct?
<tjaalton> boot.log shows entries from rc2.d
<mlankhorst> tjaalton: add a sleep 10 at the end of /etc/init/rc
<mlankhorst> init.d *
<tjaalton> same
<mlankhorst> do you have a upstart log with timestamps and verbosity on jobs starting?
<tjaalton> not yet
<mlankhorst> it's an interesting twist though
<tjaalton> well, adding the sleep means I get to see the message from cryptswap
<Sarvatt> tjaalton: oh you're forcing plymouth into the initrd to reproduce it? aka cryptsetup installed
<tjaalton> yes
<tjaalton> but looks like swap has at some point stopped working
<tjaalton> no idea when :)
<mlankhorst> tjaalton: just for fun can you dump $PREVLEVEL if  that's easier?
 * mlankhorst curiously wonders if that's 2 too
<tjaalton> N
<tjaalton> huh
<mlankhorst> I guess none, that's fine
<tjaalton> runlevel is 2
<mlankhorst> what if you change the condition?
<mlankhorst> or (runlevel [2345] and stopped rc RUNLEVEL=[2345])
<dupondje_> Bleh, installed nvidia driver, but get the following when starting gnome-shell now:
<dupondje_> Xlib: extension "GLX" missing on display :0
<dupondje_> :(
<mlankhorst> join us and hack on nouveau
<mlankhorst> we have well behaving graphics hardware!
<dupondje_> :)
<mlankhorst> *) compared to other vendors
<dupondje_> I have a dream: perfectly running Optimus :)
<mlankhorst> you can make it happen if you hack on nouveau
<tjaalton> mlankhorst: no dice
<bjsnider> dupondje_, this is with the new beta blob?
<mlankhorst> not much
<dupondje_> bjsnider: yep, but think I had same issue with other versions also
<mlankhorst> only thing it's good for atm is usb displaylink connectors
<bjsnider> llstarks was saying there's some complicated stuff in thew xorg.conf file
<dupondje_> so there must be something wrong somewhere I bet ... but what :)
<bjsnider> maybe go to the #nvidia channel and ax
<dupondje_> bjsnider: thx, i'll try it out ;)
<bjsnider> as soon as nvidia supports wayland, they will have finally conquered the universe
<mlankhorst> I really like nvidia's drm driver implementation
<mlankhorst> tjaalton: but upstart log would still be nice :)
<tjaalton> mlankhorst: added --verbose, but it's not that verbose or I can't find where it's supposed to log
<tjaalton> initctl log-priority
<tjaalton> info
<tjaalton> doesn't work
<llstarks> bjsnider, not really comlicated, just annoying since nobody can get it working on lvds
<mlankhorst> tjaalton: I'm going to bed, I'll poke upstart some tomorrow, see if i can get it to log
<tjaalton> k
<tjaalton> mlankhorst: it's on dmesg
<mlankhorst> well that saves me future poking of upstart
<tjaalton> strange, the upstart logs show no mention of plymouth-splash
<tjaalton> ..because of it getting started before upstart, due to the initramfs
<tjaalton> bah
<dupondje_> just gave up on getting nvidia working
<dupondje_> god damn what a bunch of crap :(
<llstarks> just wait bor
<llstarks> *bro
<dupondje_> that my dream comes true? :)
<dupondje_> Optimus in Nouveau ? :)
<Sarvatt> kind of crazy that hybrid amd+intel "just works" with fglrx these days and wasn't in any news :P
<llstarks> no, let me figure this out and we'll have a plan of action for nvidia-319 optimus on raring and snarky squirrel
<llstarks> to dupondje_ 
<llstarks> intel+radeon was broken and fixed and broken again throughout last year
<llstarks> amd+radeon was the only thing that worked reliably
#ubuntu-x 2013-04-11
<mlankhorst> woops, nexus7 panic on nfs4 still exists
<tjaalton> mlankhorst: so there's a way to fix the race once and for all
<mlankhorst> \o/
<mlankhorst> Bring out the low orbital satellite death ray!
<tjaalton> the short-term fix is to add a job that emits an event on startup or started plymouth-splash, and use that in *dm
<tjaalton> *dm.conf
<tjaalton> that should cover the case where plymouth is in initramfs, for one reason or another
<mlankhorst> can it be trivially backported to precise/quantal?
<tjaalton> I hacked it locally to work nicely with 'and (started cryptdisks-enable or started plymouth-splash)' but it works only in this one case :)
<tjaalton> should be
<tjaalton> this is where the bikeshedding starts :)
<tjaalton> like, what to call the job
<mlankhorst> bug99something
<tjaalton> 982889 :)
<tjaalton> .conf
<mlankhorst> just call it something ugly and then let the sru admin decide the final name
<tjaalton> yeah, not the time for that now
<mlankhorst> it's what I end up doing, anyway
<mlankhorst> reviewer always gets to decide the name ;P
<mlankhorst> ugh building on nexus7 is taking ages
<mlankhorst> I have a good feeling about the fix though, your backtrace from bug 56578 seemed like a dupe of the corruption I was hitting
<ubottu> bug 56578 in mlview (Ubuntu) "Please sync mlview (universe) from unstable" [Undecided,Fix released] https://launchpad.net/bugs/56578
 * mlankhorst slaps ubottu around a bit iwth a large trout
<tjaalton> I tried the patch and it didn't fix it for me
<mlankhorst> yeah that's why I'm compiling myself, see what's still wrong
<tjaalton> it's the same one whot is seeing, and what I had with 1.14 too
<tjaalton> ah
<tjaalton> good
<tjaalton> hmm should I push my tree somewhere?
<tjaalton> 1.14 is pain, the backport is easier to handle
<mlankhorst> 1.14 was working for me though with the patch I wrote
<tjaalton> with synaptics
<tjaalton> for nexus7 you'll need to do tricks to be able to run unity
<tjaalton> or run the backport
<mlankhorst> I'm just running nexus7 + 1.13
<mlankhorst> default image
<mlankhorst> I'm trying with all of the patches linked from that bug
<tjaalton> yeah
<tjaalton> that's what I meant to push somewhere
<mlankhorst> it's building that's a pain
<tjaalton> build it parallel=3
<mlankhorst> nfs4 mount causes the nexus to reboot, so I had to force nfsvers=3
<mlankhorst> and wireless is not that good here :(
<tjaalton> copy the source locally
<mlankhorst> yeah next time :P
<tjaalton> faster that way
<mlankhorst> I'll try connecting it through usb
<mlankhorst> actually should be doable on my panda, it already bridges the network to a wireless access point anyway
<mlankhorst> I don't run the access point atm since it seems to cause memory corruption
<tjaalton> added 'status plymouth-splash | grep -q "start/running" && exit 0' before exec lightdm in the job, without adding any preconditions
<tjaalton> seems to work, but there's a strange timeout
<tjaalton> and this would only fix lightdm..
<mlankhorst> yeah getting same crash on nexus
<mlankhorst> http://paste.ubuntu.com/5697733/
<mlankhorst> we're missing c0a752d2864872023216005375a6a1973fadeffe but probably harmless
<mlankhorst> fix for #57301 too, dno about that, probably needs the commit before that as well
<tjaalton> doesn't hurt to try
<mlankhorst> I feel like just doing a raw diff on exevents.c and grabs.c, see what differs..
<mlankhorst> hm same, except pointer barriers
<mlankhorst> ogra_: I have no luck so far with digging through the pointer barrier stuff :/
<ogra_> :/
<ogra_> sad
<mlankhorst> I think that x1.14 is crashing in the same way tbh
<ogra_> hard to tell since you dont have awroking driver for it 
<ogra_> *a working
<tjaalton> I built 1.14 without the video abi changing bits
<mlankhorst> the only thing I can see that's different is pointer barriers though, which shouldn't get in the way anyway
<mlankhorst> tjaalton: yeah but compiz isn't the same either
<tjaalton> what does that change?
<mlankhorst> they're handled in different places with the old patch from what I can tell
<tjaalton> you mean unity?
<mlankhorst> hm I'll try the same 1.13 on macbook, see if it crashes
<tjaalton> i used the staging version which was ported to 1.14
<mlankhorst> as I expected, 1.13.3 works on the macbook
<mlankhorst> hm the only difference seems to be that I don't get the window drag thingy with synaptics
<mlankhorst> oh right, 3 buttons is middle click
<ogra_> hmm, so we just need to ship macbooks with the nexus7 images ?
<mlankhorst> nah
<mlankhorst> macbook uses synaptics
<mlankhorst> tjaalton: I'm going to assume for now that the reason I can't trigger it on my macbook is that it's a different bug, I don't get the 3 fingers move window thing that I did get on nexus7
<mlankhorst> ogra_: can I enable the onscreen keyboard from the nexus on desktop?
<mlankhorst> ah got it
<mlankhorst> BOOM
<mlankhorst> now lets see if the same happens on 1.14
<mlankhorst> oops looks like it was the original bug, forgot to reapply the patches to 1.13 :/
<tjaalton> mlankhorst: it's not the same driver either
<tjaalton> mlankhorst: i told you ;)
<mlankhorst> tjaalton: true but I was hoping I could find a way to reproduce it on the macbook
<tjaalton> sure, would've been easier
<tjaalton> any touchscreen device should do
<mlankhorst> oh btw also fun, I noticed that in plymouth card0 is used blindly, instead of looking for boot vga
<tjaalton> i pinged whot the other day btw, said he's been busy with other bugs lately and hasn't had time to look into this again
<mlankhorst> :(
<tjaalton> kinda promised to look soon I think
<mlankhorst> lets see if I can crank up the debugging and figure it out myself then
<mlankhorst> or at least make some xorg-integration-tests thing out of it
<DamienCassou> hi everyone
<DamienCassou> I'm building a package for an upstream project that can only be compiled to 32bits. This project depends on the presence of libGL.so.1 and libX11.so.6 at execution time. What are the best packages to depend on?
<DamienCassou> is it libx11-6 and libgl1?
<tjaalton> libgl1-mesa-glx
<jcristau> the best package to depend on is ${shlibs:Depends}, and let dpkg-shlibs figure it out from there.
<tjaalton> yeah, true
<jcristau> *dpkg-shlibdeps
<DamienCassou> tjaalton: thank you. It looks like there are other providers of this binary like nvidia*. Will that be ok?
<tjaalton> should be
<DamienCassou> jcristau: thanks. I already have this one but these packages didn't get installed
<tjaalton> you need to fix the packaging then
<DamienCassou> tjaalton: do you some minutes to mentor me?
<tjaalton> DamienCassou: sorry, no. try #ubuntu-motu
<DamienCassou> ok, thank you
<mlankhorst> why does xinput2 have to be some complicated
 * mlankhorst guesses it's related to TouchRemovePointerGrab being a stub
<mlankhorst> I think I'll give up, there's too much obfuscation between dix and Xi to make sense of anything.. the whole emulation, touch listeners and active vs passive grabs is not helping much either
<mlankhorst> cnd: ^ looks like you managed to stay interested in xi2 longer than me!
<gotwig> is nvidia-319 coming to ubuntu linux 13.04?
<gotwig> public repo?
<gotwig> Multi/Universe?
<tjaalton> tseliot knows when
<gotwig> tjaalton: but you think it comes?
<mlankhorst> what do you need from 319 that you care so much?
<gotwig> mlankhorst: do you even know what it offers...??
<gotwig> mlankhorst: you are able to render stuff on nvidia graphics card, and display it via intel drivers
<mlankhorst> .. on a precise xserver?
<mlankhorst> you know more than me then
<mlankhorst> or precise kernel for that matter
<cnd> mlankhorst: yeah, xinput2.2 is a hairy hairy beast...
<mlankhorst> 2.3 now, pointer barriers
<mlankhorst> but I don't believe it's the cause of the bug, so xi2.2 is fine with me too
<cnd> heh
<tjaalton> gotwig was wrong
<tjaalton> can't use -intel
<mlankhorst> well perhaps if you hack xserver you could, by pretending nvidia is the primary device
<tseliot> it supports prime but definitely won't work in Precise
<mlankhorst> you need the drm-trololol-gpl patches first
<mlankhorst> i doubt they were in 3.5 kernel, so unless the backported hsw has them it won't work even with the 3.5 kernel\
<tseliot> didn't they work around the gpl symbols?
<mlankhorst> yeah by using the drm helper stuff they wrote
<tseliot> it's all in our 3.8 kernel
<tseliot> yep
<mlankhorst> but 3.8 is not in precise yet, I think?
<mlankhorst> ohey, it even might be
<mlankhorst> oh well I'll have to file a bug to get the dependencies for xserver-xorg-lts-raring ready then
<tseliot> right
<mlankhorst> will we still get 9.1?
<tjaalton> probably
<tjaalton> http://packages.qa.ubuntu.com/qatracker/milestones/266/builds/41730/testcases/1515/results
<tjaalton> mostly intel testers though
<tjaalton> anyone with radeon & nouveau please test ^ :)
<mlankhorst> worksforme? what exactly do you want from the tests?
<gotwig> hey
<tjaalton> gotwig: realized you can't use -intel driver with nvidia? :)
<bjsnider> he asked about raring, not precise
<mlankhorst> bjsnider: yeah still wont work with optimus in the way he described it..
<bjsnider> still, one must admire the strength of his convictions
<mlankhorst> meh it was probably on phoronix like that
<gotwig> any chance to see nvidia-319 on ubuntu 13.04 repo?
<bjsnider> at some point it will be there
<gotwig> bjsnider: but for that we need more actual packages of Xorg and xrandr I guess?
<bjsnider> i don't see why
<gotwig> e.g xrandr 1.4
<gotwig> and normaly you need kernel 3.9, for the prime helpers
<gotwig> but kernel 3.8 is going to be the default kernel for ubuntu, right?
<bjsnider> well, maybe, but i don't think there's any rush because some people have tried it the past couple of days and reported it doesn't work
<gotwig> bjsnider: for me it also doesnt work normaly
<gotwig> bjsnider: I use optimus
<gotwig> but when you look at the changelog.. well, there are not many improvements
<bjsnider> that's what they've been testing
<gotwig> and if you install nvidia-319, bumblebee-nvidia gets removed. Why?
<bjsnider> because the two are mutually exclusive
<seb128> intel_do_flush_locked failed: Input/output error
<seb128> hate you too intel
 * seb128 reboots
<gotwig> bjsnider: they are what?
<dupondje_> gotwig: trying to install nvidia blob ?
<dupondje_> :)
<mlankhorst> he believes it will give him optimus :/
<dupondje_> hÃ©hÃ© :P
<gotwig> dupondje_: what?
<gotwig> Let me believe :(
 * gotwig cries
<dupondje_> it isn't even capable to give me a gnome-shell here :(
<gotwig> dupondje_: I ask if nvidia-319 is going to come to ubuntu repos
<dupondje_> you can try the xorg ppa :)
<dupondje_> mlankhorst: which I could help getting nouveau optimus ready :)
<gotwig> dupondje_: When I try to use such PPA's, my multitouch does no longer work
<gotwig> when nvidia-319 is in ubuntu repos, I am sure that I am not going to break my system, and all dependencies are in place
<gotwig> dupondje_: nouveau is a good thing. The optimus support is a nice idea
<dupondje_> I hope for you :) Tried to install it yesterday, and gnome-shell didn't even start :(
<gotwig> dupondje_: do you think, nouveau is going to be able to use prime helpers?
<mlankhorst> ._.
<dupondje_> so *sad*
<gotwig> dupondje_: its not gnome shells fault
<dupondje_> I know .. its the **** nvidia driver's fault ;)
<gotwig_> hey there sry..
<gotwig_> like i said, its not GS fault
<bjsnider> dupondje_, you're a fellow gnome-shell user?
<dupondje_> bjsnider: yep :)
<gotwig> hey
<gotwig> I have an asus zenbookux32vd
<gotwig> I have optimus, nvidia and intel hd graphics
<gotwig> When i try to follow this guide to reset the DPI with xrandr https://help.ubuntu.com/community/AsusZenbook it doesnt work
<gotwig> However, if I e.g apply VGA1 when I use an external display it works
<gotwig> how can I find out the name of my notebook screen for xrandr?
<bryce> xrandr -v
<gotwig> xrandr program version       1.3.5 Server reports RandR version 1.4
<bryce> it's probably called LVDS1
<bryce> sorry, xrandr -q
<gotwig> eDP1
<bryce> ah, one of those.
<gotwig> ok
<gotwig> I can now set the gama
<gotwig> but the DPI are still untouched
<gotwig> why
<gotwig> I set higher and lower
<gotwig> nothing changes
<gotwig> same issue
<gotwig> from ubuntu 12.04 - 13.04
<gotwig> bryce: what can I do
<bryce> gotwig, http://lmgtfy.com/?q=ubuntu+raring+how+to+change+the+font+dpi+settings
<gotwig> bryce: text scaling is not the same
<gotwig> bryce: I already use text scaling, and btw. these AskUbuntu answers are more than bad. They are noob friendly.. this is a good article: http://robswain.tumblr.com/post/14209540835/xorg-gnome-3-on-high-dpi-screens
<gotwig> bryce: maybe I am just stupid
<gotwig> I think it works
<gotwig> but I just cant notice it
<tjaalton> mlankhorst: btw, I had uploaded 2.21.6-0u1 already
<tjaalton> so you'd need to update the changelog if you merge from d-e
<tjaalton> mlankhorst: too late :)
<bryce> mlankhorst, I went ahead and included the change in my upload.  If it should not go in let me know asap so I can reverse it.
<bryce> and yeah +1 to changelog entries :-)
<tjaalton> huh, we don't have xrandr 1.4 in x11-xserver-utils yet
<tjaalton> didn't know that
<tjaalton> ..but provider stuff is patched in
<tjaalton> oh I did it, getting old it seems
<bryce> heh
<bryce> I've been running into that myself.
#ubuntu-x 2013-04-12
<mlankhorst> bryce: oh worst part was doing a kernel bisection, then look at last 8 commits and notice you're getting awfully close to looking at a regression you fixed ;)
<mlankhorst> luckily someone broke the kernel right after my fix so I didn't go insane
<tjaalton> mlankhorst: ooh, looks like 3.9 does indeed support nvd9 better
<tjaalton> accel and all
<tjaalton> not that well though :)
<tjaalton> hooked my laptop to my dp-monitor, ran xrandr and get a funky display
<tjaalton> nothing on DP, it's like both displays are on the laptop panel
<tjaalton> uh, we didn't touch -ati at all this cycle?
<tjaalton> sorry
<tjaalton> stale git tree :)
<tjaalton> mlankhorst: we need to push -ati f402805b22e4f to quantal & precise backport
<tjaalton> should fix bug 1085751
<ubottu> bug 1085751 in Fedora "[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!" [High,Confirmed] https://launchpad.net/bugs/1085751
<mlankhorst> oh sure
<mlankhorst> some pci id stuff too btw
<mlankhorst> unless I already did but can't remember
<mlankhorst> but I took today as time off, so I cant look into it now :)
<tjaalton> np
* Sarvatt changed the topic of #ubuntu-x to: Before asking for help here, please file a bug report using 'ubuntu-bug xorg'.  See http://wiki.ubuntu.com/X/Reporting for tips. Testing of mesa 9.1.1 for inclusion in 13.04 on radeon and nouveau greatly appreciated! http://goo.gl/n2ua8 for details.
<tomreyn> Sarvatt: i'm reading http://packages.qa.ubuntu.com/qatracker/milestones/266/builds/41730/downloads  which says "Make sure you are running the latest version of ubuntu": does this refer to 12.10, to the latest raring alpha, or to the latest raing snapshot?
<tomreyn> if raring: is booting from a usb key, then installing all updates on the aufs sufficent for testing?
<Sarvatt> tomreyn: raring only unfortunately, I guess it would be possible to test on a liveusb, you would need to add the PPA and update it, then sudo service lightdm stop then sudo service lightdm start from a VT
<tomreyn> ok, so logout / login is not enough?
<tomreyn> i was thinking this would restart X + DM
<Sarvatt> yeah that would work, it's not KDE :P
<tomreyn> obviously restarting it manually is a more reliable approach
<tomreyn> if there's another approach which just installs a minimal raring on disk, such as on my existing swap partition, that'd be fine, too.
<tomreyn> would have to be mostly automated, though
#ubuntu-x 2014-04-07
<mlankhorst> ricotz: done, not sure how you couldn't do that yourself :p
<mlankhorst> Prf_Jakob: does [PATCH] st/xa: Bind destination before setting new state fix the vmware xa crash?
<Prf_Jakob> mlankhorst: ah no, its another patch, I'll let you know which one
<mlankhorst> ok ty
<mlankhorst> well I still have 2 days to test before vmware workstation trial ends :P
#ubuntu-x 2014-04-09
<Prf_Jakob> tjaalton: 
<Prf_Jakob> 2355a6441435b8e66a032c44f0794066338e30a3 "cso: fix sampler view count in cso_set_sampler_views()"
<Prf_Jakob> 9bb2ec6fd1464d92f44b8aa693616edda9724312 "svga: replace sampler assertion with conditional"
<Prf_Jakob> e853ade5441e8bf8f862ecf379c231cb439c5c00 "svga: move LIST_INITHEAD(dirty_buffers) earlier in svga_context_create()"
<Prf_Jakob> tjaalton: only the first is needed for the fix, the last fixes something else.
<tjaalton> Prf_Jakob: fix what?
<Prf_Jakob> oh right wrong person
<Prf_Jakob> mlankhorst: ^ :)
<tjaalton> figured :)
<Prf_Jakob> tjaalton: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1284134 first patch fixes this :)
<ubottu> Launchpad bug 1284134 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [High,Incomplete]
<Prf_Jakob> tjaalton: basically start LibreOffice Calc, resize window, X server crash.
<tjaalton> ok
<tjaalton> yeah I'll let mlankhorst test those
#ubuntu-x 2014-04-10
<mlankhorst> morning
<mlankhorst> ah useful, I'll give it a shot
<mlankhorst> Prf_Jakob: what do the other commits firx?
<Prf_Jakob> mlankhorst: second just removes the assert we where hitting (would have crashed anyways)
<Prf_Jakob> Last fixes another crash on "hardware" that doesn't support AA lines.
<mlankhorst> ok
<mlankhorst> Prf_Jakob: last one fails to apply cleanly, but with some force it works. :-)
<Prf_Jakob> mlankhorst: ah okey, that might be a rescent thing then
<mlankhorst> uploaded mesa 10.1.0-4ubuntu4
#ubuntu-x 2015-04-07
<furkan> any ideas on how i can debug dpms? it seems to have stopped working for me
<furkan> i manually type "sleep 1; xset dpms force off" into the terminal, and nothing happens
<furkan> the screen simply doesn't turn off... at the lock screen, it fades to black, but backlight stays on and mouse pointer is visible
<furkan> this is on 15.04... earlier this was only happening after suspend/resume, now it happens all the time
<furkan> looks like a kernel issue... i booted up in 4.0 rc7 and it works fine
<furkan> spoke too soon.. still doesn't work after suspend/resume
#ubuntu-x 2015-04-08
<furkan> but on 3.19.0-12 it doesn't work at all
<furkan> so, still a difference
<tjaalton> furkan: can't reproduce the checkerboarding bug or the corruption. the dpms issue is real, testing a commit now
<furkan> tjaalton: this is interesting... i unplugged my secondary monitor, and everything works much, much better
<tjaalton> is the other monitor a 4k one?
<furkan> no checkerboarding, no "snow" in the virtual terminal, no delay when switching between virtual terminals (with 2 monitors, it takes a few seconds), and no graphics corruption when initially logging in (i didn't mention that in the bug report because i thought that was "normal", i'll take a vid for you if you want)
<furkan> i have just my 27" 2560x1440 monitor connected now
<tjaalton> and the other one?
<furkan> i unplugged it.. i'll plug it in and try it in landscape mode first
<furkan> before switching to portrait, which is how i originally had it
<tjaalton> the resolution?
<furkan> oh right
 * furkan tests
<tjaalton> tried rotating the other one, still nothing
<furkan> nope... killed my desktop
<furkan> i took a pic
<furkan> https://www.dropbox.com/s/fd1tdi67og8iz91/IMG_20150408_132316.jpg?dl=0
<furkan> that's what happened when i tried to change from 2560x1440 to 1920x1080
<furkan> so you have a dual-monitor setup too?
<furkan> what are your resolutions?
<tjaalton> 25x14, 19x10
<furkan> oh, so almost the same
<tjaalton> hooked to the same monitor via dvi & hdmi
<furkan> and you tried rotating the 19x10 monitor?
<tjaalton> yes
<furkan> wait, hooked to the same monitor? you mean 1 screen connected with 2 cables?
<tjaalton> yup
<tjaalton> i only have one
<furkan> hmm
<furkan> ok i will try connecting it again in landscape
<furkan> ok so i have the monitor in landscape now
<furkan> switching between vts is no longer instantaneous
<furkan> but no checkerboarding/snow
<furkan> after suspend/resume
<furkan> changing resolution still trips it up, i need to switch into a VT and service lightdm restart
<furkan> so i made the switch to portrait, right now i have checkerboarding, but no "snow"
<furkan> even after 2 suspend/resume cycles (1 when i had the monitor in landscape, and 1 after i switched to portrait)
<furkan> i bet it'll be back after i restart though
<tjaalton> so which one is in portrait?
<furkan> yeah so i restarted, at first no snow, then suspend/resume and the snow is back... so it seems to reproduce that bug i need to boot directly into that display configuration
<furkan> i have 27" 2560x1440 in landscape mode
<furkan> and 24" 1920x1200 in portrait mode, on the left-hand side
<furkan> i suppose i could also try putting it on the right-hand side as a final test
<furkan> interesting, this time my screen didn't become garbled after changing resolution
<furkan> and VT switches are instantaneous
<furkan> ok well after restarting, no difference
<furkan> but at that moment, just after switching the screen from one side to the other, i was getting instantaneous VT switches, now i'm not
<furkan> but snow/checkerboarding still there
<tjaalton> have you tried 4.0?
<furkan> https://www.dropbox.com/s/4koy953b7faj095/VID_20150408_134129.mp4?dl=0
<furkan> that's the corruption when initially logging in.. pretty minor so i hadn't thought much of it before, but it doesn't happen with a single monitor connected
<furkan> and yeah i was using 4.0 for a while, and same issues
<tjaalton> try #radeon then, and file a bug on bugs.freedesktop.org
<furkan> but i didn't have the issue with Xorg 1.16, so what if it's an Xorg bug and not a kernel bug?
<furkan> and when i downgrade to 3.16 i still have the issue
<furkan> whereas before upgrading to 15.04, i didn't
<furkan> so i think that rules out the kernel, no?
<tjaalton> same devs
<furkan> ah
<tjaalton> pretty much
<furkan> ok will do, then
<furkan> thanks for the pointer
<furkan> btw, another regression, unrelated to X: after rebooting or suspend/resume, i need to unplug my headphone and plug it back in for it to be recognized again
<furkan> if i submit too many bug reports i feel like i'll become the "boy who cried wolf", but right about now i'm wishing that i stayed with 14.04 :P
<tjaalton> well, can't reproduce that either, something wrong with jack detection I guess
<tjaalton> file that against pulseaudio
<tjaalton> for starters
<furkan> tjaalton: i guess i understand the "snow" thing now
<furkan> when on a VT, it sets the same resolution on both monitors
<furkan> so since my smaller monitor is 1920x1200, it sets that resolution on both
<furkan> and before suspending, it's scaled to full screen
<furkan> after suspend/resume, you get the 1920x1200 terminal drawn on the top left corner of the screen, and the blank areas are white
<furkan> in 4.0, the terminal isn't scaled to full screen but the blank areas are black (then after suspend/resume it turns white)
<furkan> really not the worst out of the bugs i've seen so far, but something is really broken w/ dual monitor support on a radeon card
<tjaalton> furkan: yep, saw the same, no corruption though, just white borders
<furkan> tjaalton: i know this must be an upstream bug, but just to share the hilarity https://www.dropbox.com/s/caawhzn8zfycc00/VID_20150408_165520.mp4?dl=0
<furkan> the time difference between switching, where the secondary monitor is on the left vs. the right
<furkan> *switching to a VT
<tjaalton> it is what it is.
<furkan> well with the open-source drivers w/ kernel modesetting, it's supposed to be instantaneous
<furkan> whereas with the proprietary drivers it's not
<furkan> so while the bug itself is no big deal, i think it's indicative that something is going wrong
<furkan> tjaalton: do you use vanilla Ubuntu, or one of the derivatives?
#ubuntu-x 2015-04-09
<furkan> tjaalton: confirmed that it's not a radeon bug... same issue with fglrx, and the checkerboarding doesn't happen in kubuntu
<furkan> i posted another comment on the bug report again a few hours ago, saying that i had tested it in kubuntu
<furkan> so it's probably not Xorg (since it doesn't happen on KDE), and almost definitely not the open-source radeon driver (since i don't think it shares any code with fglrx), so i think that probably leaves Unity/compiz
<furkan> tjaalton: when you get the opportunity, would you mind testing again with both screens not aligned at the top, i.e. with y > 0 for the landscape monitor
<furkan> but how could it be unity/compiz... because it first started happening when i upgraded to xserver-xorg-lts-vivid from the x staging ppa when i was running trusty
<furkan> so then maybe it *is* an xorg bug
<furkan> well at least i have dpms back, after switching to fglrx
<furkan> (but i did lose my virtual terminals)
<furkan> with an AMD card on linux i guess there's no winning combination
<tjaalton> kde uses qt, not gtk
<tjaalton> and use xterm or such ;)
<ricotz> tseliot, jfyi pushing blob 346.59 tarballs to xorg-edgers
<tseliot> ricotz: ok, I'll use your tarballs then
<tseliot> so that you don't have to re-upload them
<ricotz> tseliot, thanks, i hope it didnt already clash with your work
<tseliot> ricotz: no problem, I'll delete mine and download yours. I'm still testing the packages
<tjaalton> furkan: you'll get your dpms back in the next vivid kernel update
<tjaalton> oh it got tagged, 3.19.0-13.13
<furkan> tjaalton: ah, great news, thanks :D
<furkan> i hope it continues to work after suspend/resume as well!
<furkan> and.. i've been playing around with kde (i installed the kubuntu-desktop package)
<furkan> i'm finding it really strange that kde doesn't crash after changing my display settings, but unity does
<furkan> the display corruption happens in both, but kde recovers whereas unity doesn't
<furkan> and the totally crazy thing about the display corruption is that it shows parts of the screen buffer from the previous boot
<furkan> like first when i booted up into a kubuntu live usb, and changed the monitor configuration, when it was switching resolutions you could see portions of what i had open on my screen before rebooting
<furkan> and likewise when i rebooted back into my ubuntu install, when changing resolutions i would see portions of the wallpaper from the kubuntu live cd
<furkan> if it's on a fresh boot, i see white rectangles instead
<furkan> so it's as if there are portions of old stuff that's left over in the VRAM
<furkan> so if you shut down the PC, it gets cleared, but if you do a reboot, those contents are still in the VRAM and they get "leaked"
<furkan> i'm sure that's an upstream issue, as it doesn't happen with fglrx
<furkan> but somehow kde manages to handle the situation anyway
<furkan> so that's why i installed kde, but i can't stand it, gonna nuke it now and go back to unity
<furkan> tjaalton: i just added the kernel testing ppa and installed 3.19.0-13, and also did an apt-get upgrade and noticed that my libdrm* packages got upgraded... now dpms is back (even after suspend/resume) and my desktop no longer crashes after a resolution change... so i will close that bug
<furkan> i still get the checkerboard corruption after suspend/resume... but, not the worst out of those bugs
<furkan> tjaalton: never mind... resolution change causes a black screen (it used to show corruption, now just black) - it was only changing the screen's vertical position which no longer triggered screen corruption + crash
#ubuntu-x 2015-04-10
<furkan> tjaalton: my bug report got marked as confirmed and high priority (no idea who confirmed it), but after what you said about qt/gtk, i booted up into fedora 22 alpha (Xorg 1.17.1 + Gnome 3) and was able to reproduce the bug, although it's harder to produce, here's a 10 second vid: https://www.dropbox.com/s/85n2iq27zm00dlo/VID_20150410_033406.mp4?dl=0
<furkan> so you're probably right that it's an upstream bug
<furkan> except who knows which package
<furkan> it's harder to see in the video, but pretty clear near the end of the 10 seconds
<furkan> i'm just repeatedly maximizing and restoring a window
<tjaalton> just file it on xserver for now
<tjaalton> or dri - radeon
<tjaalton> hm though you said it was triggered by the xserver upgrade
<tjaalton> or file it against the ati driver
<tjaalton> it at least has people that look at the bugs
<furkan> will do, now that i've reproduced it on 2 distros, they can't say it's an ubuntu bug
<furkan> since it doesn't happen w/ fglrx, it could also be a glamor thing
<furkan> but i don't have any machines w/ nvidia or intel gfx to test that theory with
<furkan> (if i'm correct in assuming that fglrx doesn't use glamor)
<tjaalton> it doesn't
#ubuntu-x 2016-04-11
<tseliot> mamarley, ricotz: just FYI I'm packaging on 364.16
<tseliot> https://developer.nvidia.com/vulkan-driver
<ricotz> tseliot, hi, there is no armhf?
<tseliot> ricotz: apparently not. I'll put the driver in the vulkan PPA
<ricotz> tseliot, ok
<ricotz> tseliot, note the disabled kms change
<tseliot> ricotz: what change?
<tseliot> oh Disable KMS by default again.  It was still causing problems for some users.
<tseliot> ricotz, mamarley: I would like to know more about the regressions with KMS, so that I can file a bug report and have the problem fixed by NVIDIA
<mamarley> darkxst: ^
<darkxst> tseliot, it was crashing in cogl_framebuffer_create or so, I will grab a stacktrace next time I reboot
<tseliot> darkxst: yes, please. Also, if you have a small code sample to reproduce the problem, that will certainly help
<tseliot> darkxst: that and your nvidia-bug-report.log
<darkxst> tseliot, ok, might be a few days, but will get it to you
<tseliot> darkxst: ok, thanks
#ubuntu-x 2016-04-12
<alkisg> Some schools are starting to report nouveau segfaults recently. The weird part is that they're still in the same 12.04 installation that they were for years.
<alkisg> [   63.415500] firefox[2221]: segfault at 4 ip b0a28e79 sp bfc5d0d0 error 4 in nouveau_vieux_dri.so[b0a1f000+2f000]
<alkisg> Linux pc01 3.13.0-83-generic #127~precise1-Ubuntu SMP Fri Mar 11 12:54:55 UTC 2016 i686 i686 i386 GNU/Linux
<alkisg> xserver-xorg    1:7.6+12ubuntu2
<alkisg> Should I be looking for a xorg regression, or could it be that firefox is now trying some opengl code that it wasn't trying in the past, and it's breaking existing installation?
<alkisg> They report that it happens when they're "just surfing" or "right clicking to save a picture"
<tjaalton> ancient stuff, not really interested, sorry
 * alkisg doesn't see any recent xorg updates for 12.04 in the apt logs...
<tjaalton> because there haven't been any in years
<tjaalton> but they're running the trusty stack, or kernel at least
<alkisg> The kernel only
<tjaalton> so check the kernel then
<alkisg> Hmm you think the kernel is more likely the cause than firefox?
<alkisg> For now this seems to work around it : "rm -f /usr/lib/i386-linux-gnu/dri/nouveau_vieux_dri.so"
<alkisg> ...that's for 3d support only, isn't it?
<tjaalton> yes
<alkisg> Cool, they'll be fine without it :)
<alkisg> Thank you tjaalton
<tseliot> one more vulkan driver...
<mamarley> tseliot: Where is that?  I see only 364.16.
<tseliot> mamarley: https://developer.nvidia.com/vulkan-driver
<tseliot> 364.91
<mamarley> That appears to be only for MicrosoftÂ® WindowsÂ®.
<tseliot> right. I'm not sure why I've just received a notification about it. 364.16 is already in the vulkan PPA BTW
<mamarley> Yep, I installed it yesterday.  I get a segfault from vkcube thoughâ¦
<tseliot> :/
<tjaalton> vkcube is broken
<tjaalton> try sascha willems demos
<Azelphur> Hey folks, odd question. I bought a little bluetooth gamepad, connects and works fine (it identifies as a keyboard and sends keystrokes). I'm wondering if there's some way I could abuse it as a macro pad? binding the keystrokes it sends to run commands, I know of stuff like xbindkeys but I don't think it can do per-device binds?
#ubuntu-x 2016-04-13
<darkxst> Azelphur, try evdev (no idea if it support bindings, but xbindkeys is too high level for per-device bindings)
#ubuntu-x 2018-04-10
<mamarley> ricotz: 396 beta is apparently out.  I will handle it.
<mamarley> It looks like this driver drops 32-bit support.
<soee_> ;-)
<tjaalton> that was on the news
<soee_> mamarley: ping me when it lands in ppa
<mamarley> Sadly, this new packaging scheme is going to make the packages for the 32-bit libraries *much* more tricky, since the 32-bit libraries actually come out of the 32-bit build.  That means we will need a 32-bit build of the driver even though it doesn't actually support 32-bit kernels, presumably with a different package set for each architecture.
<mamarley> Implementing this very likely exceeds my capabilities.
<ricotz> mamarley, sounds like fun :(
<mamarley> ricotz: I gave up trying to get support for 32-bit libraries on Bionic.  I was able to get it to work for all previous releases though.
<mamarley> I have packages up in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages, but for Bionic there is no support for 32-bit applications on 64-bit kernels.
<ricotz> I see
<JanC> eh, why would there be no support in the kernel for that?
<JanC> (is that even possible?)
<mamarley> JanC: It isn't the kernel, the problem is that in Bionic the 390 drivers use multiarch, which means that the 32-bit libraries for running 32-bit OpenGL applications on 64-bit Linux come from the 32-bit packages compiled for i386.  With 396, NVIDIA dropped support for 32-bit kernels and stopped releasing the 32-bit installer, making the current method of building the 32-bit compatibility library packages not work.
<mamarley> Some kind of trickery will need to be done to work around that, but I am not skilled enough to know what the best method would be.
<JanC> oh, I guess was misunderstanding your previous message  :)
<ricotz> mamarley, I am already looking
<ricotz> mamarley, it builds
#ubuntu-x 2018-04-11
<ricotz> mamarley, hi, did you drop the 4.16 patch on purpose?
<ricotz> soee, are you running 396.18 already?
<mamarley> ricotz: I did; it no longer seems necessary.
<ricotz> mamarley, I see, I didn't test without it yet
<soee> ricotz: 390.48
<soee> I'm waitig for them to land in ppa
<soee> *the new one
<soee> mamarley: the one in your staging ppa are ready?
<ricotz> soee, ok, I am not comfortable to upload it there, since it breaks vulkan
<ricotz> mamarley, ^
<mamarley> soee: I am running the package from my staging PPA and besides the vulkan-breaking thing, it works fine if you want to try it out.  Keep in mind that this does drop GeForce 400/500 support, so if you have one of those cards, you will need to stay on the 390 driver.
<mamarley> (This is contrary to the information posted on the download page, but I tried it on such a card to find out for sure and it didn't work.)
<ricotz> mamarley, the release notes state it still is Fermi support
<ricotz> aahh
<soee> mamarley: i'm on 1060
<soee> the vulkan problem is from Nvidia devs side ?
<mamarley> soee: I'm pretty sure that is the case.
<soee> on the devtalk @ nvidia.com user posted this: libnvidia-glvkspirv.so has to be added to NV_GLX_LIBRARIES in ebuild and then it runs fine again. 
<soee> this can be done by packagers?
<soee> https://devtalk.nvidia.com/default/topic/1032079/dota2-seems-to-be-broken-with-396-18-and-vulkan/?offset=1
<mamarley> soee: That file does indeed seem to not be installed by the current packaging.  Let me have a lookâ¦
<mamarley> That does seem to fix it.
<mamarley> soee: But that only seems to apply to Bionic, and I didn't think you were running Bionic?
<mamarley> (The file is installed correctly in the old packaging which is used on everything but Bionic.)
<ricotz> oh noes
<ricotz> yeah for dlopen'ed libraries :(
<mamarley> Ah, it makes sense that it is dlopened because if it was linked normally, it would just fail to start instead of crashing.  I should have thought of that.
<ricotz> the package build would fail in the first place
<mamarley> Yeah, that too.
<ricotz> soee, thanks! :)
<mamarley> I just uploaded a fixed package for Bionic.
<ricotz> mamarley, oh, https://launchpad.net/~ricotz/+archive/ubuntu/red/+sourcepub/8980247/+listing-archive-extra
<mamarley> ricotz: Is the missing library added to that build?
<ricotz> yes
<soee> mamarley: yes, im on Xenial till Neon jumps to Bionic
<soee> And it can't be fixed in Xenial ?
<mamarley> soee: I think ricotz is looking at that.
<ricotz> mamarley, with the fermi support dropped, I can't test on xenial easily
<soee> i can :D
<ricotz> soee, so simply calling vulkaninfo segfaults even with libnvidia-glvkspirv.so.396.18 installed?
<ricotz> does "LD_LIBRARY_PATH=/usr/lib/nvidia-396 vulkaninfo" work?
<ricotz> does "__GL_NextGenCompiler=0 vulkaninfo" work?
<soee> ricotz: i need some ppa with xenial driver to install and i can test
<soee> i check if mamarley has anything in hes
<ricotz> soee, yes, use his staging ppa
<soee> brb
<soee_> ricotz: i have 396 for mamarley ppa installed
<soee_> __GL_NextGenCompiler=0 vulkaninfo | pastebinit
<soee_> https://pastebin.com/ijcA0bKS
<soee_> LD_LIBRARY_PATH=/usr/lib/nvidia-396 vulkaninfo | pastebinit
<soee_> https://pastebin.com/QwN3wfjC
<ricotz> soee_, ok, and vulkaninfo alone fails?
<soee_> vulkaninfo | pastebinit
<soee_> https://pastebin.com/DA70Gkje
<ricotz> soee_, did you say vulkan isn't working for you?
<ricotz> didn't ...
<soee_> no, that is what you both say i think :)
<soee_> taht vulkan is broken with this driver version
<ricotz> ok, the bionic package was missing this library and failed there
<soee> so xenial is not affected?
<ricotz> obviously not, since the packaging is different and this library was never missing
<soee> so to sum it up, now it shoudl run on all versions fine after you fixed bionic build ?
<ricotz> yes
<soee> great! thank you very much :)
<soee> i should be able to try playing Tomb Raider with vulcan when Feral releases it later this month
#ubuntu-x 2020-04-07
<ricotz> tseliot, hi, jfyi https://www.nvidia.com/Download/driverResults.aspx/159360
#ubuntu-x 2020-04-09
<tseliot> ricotz, hey, that should be in the PPA, soon to be uploaded in focal too
<ricotz> tseliot, thx
