#ubuntu-x 2007-04-16
<ubotu> New bug: #50414 in xserver-xorg-input-mouse (main) "Using Belkin Switch Box, mouse and X do not behave" [Undecided,Unconfirmed]  https://launchpad.net/bugs/50414
<ubotu> New bug: #50504 in xorg (main) "changing display resolution in dapper causes crash" [Undecided,Needs info]  https://launchpad.net/bugs/50504
<ubotu> New bug: #106884 in xorg-server (main) "xorg catches signal 11 visiting iPhone pages on apple.com" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106884
<ubotu> New bug: #51003 in xserver-xorg-input-keyboard (main) "British keyboard options on Macintosh has no letters." [Undecided,Needs info]  https://launchpad.net/bugs/51003
<ubotu> New bug: #51089 in xorg-server (main) "Dapper-64 bit UI Freeze, need hard reboot to get out" [Undecided,Needs info]  https://launchpad.net/bugs/51089
<ubotu> New bug: #51284 in xserver-xorg-input-mouse (main) "Trust PS/2 optical mouse not working (light turns off after a while)" [Undecided,Needs info]  https://launchpad.net/bugs/51284
<ubotu> New bug: #51425 in xorg-server (main) "reproducible X restarts involving GdkPixbuf-CRITICAL" [Undecided,Needs info]  https://launchpad.net/bugs/51425
<ubotu> New bug: #52056 in linux-restricted-modules-2.6.17 (restricted) "login/passwd/ppp updates on 6 july 2006 crash the X server" [Undecided,Needs info]  https://launchpad.net/bugs/52056
<ubotu> New bug: #106894 in linux-restricted-modules-2.6.20 (restricted) "Monitor not capable of full resolution on nvidia card with restricted driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106894
<ubotu> New bug: #106933 in xorg (main) "1400x1050 compiz trouble with ati driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106933
<tepsipakki> Mithrandir: is it possible to get x-x-v-intel in feisty after the release? I'd guess it would be impossible to remove -i810-modesetting then?
<Mithrandir> after release> no, not really.
<Mithrandir> ok, we're fixing this now by swapping them
<tepsipakki> hooray :)
<tepsipakki> did you get my question yesterday about xorg (uploading only the ATI vendor string fixes, not the workaround for vesa)
<Mithrandir> yes, too late, sorry. :-/
<tepsipakki> ok
<tepsipakki> maybe for SRU?
<Mithrandir> the images we have now might well be the final images.
<tepsipakki> wow
<tepsipakki> <blush> I never built x-x-v-intel_1.9.94.. missing header, it should be easy to fix though
<tepsipakki> .93 had problems and upstream supposed to fix them by .94 but apparently something is still missing
<tepsipakki> I'm on it
<ubotu> New bug: #41991 in linux-restricted-modules-2.6.15 (restricted) "ltmodem use hangs 686 kernel" [High,Confirmed]  https://launchpad.net/bugs/41991
<tepsipakki> Mithrandir: new version of the intel-driver built and tested.. the fix was simple, a commit broke one of the Makefile.{am,in}'s
<tepsipakki> upstream commit that is
<tepsipakki> Mithrandir: a new version uploaded
<ubotu> New bug: #105675 in linux-restricted-modules-2.6.20 (restricted) "Nvidia Legacy driver for 7.04, 2.6.20-14-generic" [Undecided,Needs info]  https://launchpad.net/bugs/105675
<kylem> tepsipakki, what version are you uploading?
<kylem> ah, 1.9.94
<ubotu> New bug: #90319 in xorg (main) "cursor redraw lingers" [Medium,Unconfirmed]  https://launchpad.net/bugs/90319
<ubotu> New bug: #106649 in linux-restricted-modules-2.6.20 (restricted) "Restricted-Manager installs older nvidia-glx package (not -new)" [Medium,Confirmed]  https://launchpad.net/bugs/106649
<ubotu> New bug: #107030 in libxcomposite (main) "Desktop efects doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107030
<ubotu> New bug: #106518 in linux-restricted-modules-2.6.20 (restricted) "update-manager error installing nvidia-glx" [Undecided,Needs info]  https://launchpad.net/bugs/106518
<ubotu> New bug: #107056 in xserver-xorg-video-i810 (main) "Xserver crash when starting OpenOffice on dual-screen laptop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107056
<ubotu> New bug: #107063 in linux-restricted-modules-2.6.17 (restricted) "remotely exploitable bug in MadWifi Atheros driver" [Undecided,Fix released]  https://launchpad.net/bugs/107063
<ubotu> New bug: #99737 in linux-restricted-modules-2.6.20 (restricted) "3d crashes with 2.6.20 and nvidia 1.0-97xx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99737
<ubotu> New bug: #52750 in xkeyboard-config (main) "missing symbols < > in German keyboard layout" [Undecided,Needs info]  https://launchpad.net/bugs/52750
<ubotu> New bug: #52632 in xserver-xorg-input-mouse (main) "PS2 2 butotn doesnt work on IBM A20M laptop with 6.06" [Undecided,Needs info]  https://launchpad.net/bugs/52632
<ubotu> New bug: #32191 in linux-restricted-modules-2.6.15 (restricted) "display errors - distorted lines" [Medium,Unconfirmed]  https://launchpad.net/bugs/32191
<ubotu> New bug: #107084 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-legacy does not work with 386 kernels" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107084
<ubotu> New bug: #106895 in xorg (main) "error running install command for nvidia with 2.6.20-15" [Undecided,Needs info]  https://launchpad.net/bugs/106895
<ubotu> New bug: #106906 in linux-restricted-modules-2.6.20 (restricted) "nvidia drivers wont work after upgrade to feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106906
<ubotu> New bug: #106632 in xorg (main) "Only 640x480 resolution found after update" [Undecided,Needs info]  https://launchpad.net/bugs/106632
#ubuntu-x 2007-04-17
<ubotu> New bug: #107110 in linux-restricted-modules-2.6.20 (restricted) "Ubuntu with Nvidia crashes when loading beryl, glxgears, etc..." [Undecided,Unconfirmed]  https://launchpad.net/bugs/107110
<ubotu> New bug: #102781 in linux-restricted-modules-2.6.20 (restricted) "display does not repaint on resume with desktop effects" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102781
<ubotu> New bug: #80303 in linux-source-2.6.17 (main) "returning from suspend disables/crashes mouse (dup-of: 59867)" [Undecided,Confirmed]  https://launchpad.net/bugs/80303
<ubotu> New bug: #67551 in totem (main) "Movies are too bright (dup-of: 32963)" [Undecided,Needs info]  https://launchpad.net/bugs/67551
<ubotu> New bug: #58323 in xorg (main) "System hangs when i choose screensaver AntSpotlight" [Undecided,Unconfirmed]  https://launchpad.net/bugs/58323
<ubotu> New bug: #59204 in xorg (main) "Black screen after boot (nvidia)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/59204
<ubotu> New bug: #66412 in linux-restricted-modules-2.6.17 (restricted) "Frequently no interrupts from /dev/nvidia0 in edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/66412
<ubotu> New bug: #76108 in xorg (main) "Flakey graphics colours kubuntu edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/76108
<ubotu> New bug: #18469 in xserver-xorg-video-tdfx (main) "Distorted output when using Xv" [Medium,Needs info]  https://launchpad.net/bugs/18469
<ubotu> New bug: #29419 in xserver-xorg-video-tdfx (main) "Blurred and chipped Video image " [Medium,Needs info]  https://launchpad.net/bugs/29419
<tepsipakki> hmm, maybe release notes should mention that ATI X1xx owners can't use the livecd
<tepsipakki> it's a driver bug apparently
<tepsipakki> in vesa
<ubotu> New bug: #106983 in xorg (main) "Screen corruption on feisty live cd" [Undecided,Confirmed]  https://launchpad.net/bugs/106983
<ubotu> New bug: #107231 in xorg (main) "X crash at gnome's startup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107231
<ubotu> New bug: #63362 in xorg (main) "Viewsonic VA1912w Series Monitor not correctly installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/63362
<ubotu> New bug: #66803 in xorg (main) "No support for via video driver on Averatec 2260" [Undecided,Unconfirmed]  https://launchpad.net/bugs/66803
<ubotu> New bug: #68043 in xorg (main) "Applying gamma settings in Monitor and Display disables direct rendering with Edgy 6.10 RC" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68043
<ubotu> New bug: #56427 in xorg-server "Fatal crash on X startup on Ultra 10" [Medium,Confirmed]  https://launchpad.net/bugs/56427
<ubotu> New bug: #57107 in xorg (main) "keyboard-layout Belgian-other-iso: no closing bracket [" [Undecided,Unconfirmed]  https://launchpad.net/bugs/57107
<tepsipakki> Mithrandir: I know the answer, but this patch would fix bug 89853 http://users.tkk.fi/~tjaalton/dpkg/xorg-server.debdiff2
<ubotu> Malone bug 89853 in xorg-server "[regression]  7.2 broke vesa: "No matching modes found"" [High,Needs info]  https://launchpad.net/bugs/89853
<Mithrandir> -updates.
<tepsipakki> ok, then we need to put in the relnotes that owners of such laptops need to use the alternate-cd?
<tepsipakki> to install
<tepsipakki> is the wiki-page free for editing?
<ubotu> New bug: #83809 in xorg (main) "Desktop noise on Edgy Installation with nvidia 6600GT" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83809
<tepsipakki> s/free/open/
<Mithrandir> yes, if there are no current locks, it is free to edit.
<tepsipakki> right, I'll add a notice about the issue
<ubotu> New bug: #107243 in xorg (main) "XServer failed on live cd" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107243
<ubotu> New bug: #12301 in xorg (main) "monitor off at boot is bad" [Wishlist,Confirmed]  https://launchpad.net/bugs/12301
<ubotu> New bug: #55445 in xorg (main) "Installer freeze unpacking xserver-xorg" [Undecided,Rejected]  https://launchpad.net/bugs/55445
<ubotu> New bug: #102356 in xorg "xubuntu 704 screen resolution incorrectly set" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102356
<ubotu> New bug: #47350 in xorg (main) "X doesn't use proper refresh" [Medium,Rejected]  https://launchpad.net/bugs/47350
<ubotu> New bug: #47794 in xorg (main) "[fglrx]  API ERROR: could not register entrypoint for ... (dup-of: 47371)" [Medium,Unconfirmed]  https://launchpad.net/bugs/47794
<ubotu> New bug: #49557 in xorg (main) "Loss of video during install!!!" [Undecided,Rejected]  https://launchpad.net/bugs/49557
<ubotu> New bug: #52195 in xorg (main) "xorg fails to upgrade if  program installed in /usr/X11R6/bin" [Undecided,Rejected]  https://launchpad.net/bugs/52195
<ubotu> New bug: #50992 in xorg (main) "Vesa driver in xorg.conf for Intel 82852/855GM by default" [Undecided,Fix released]  https://launchpad.net/bugs/50992
<ubotu> New bug: #51285 in xorg (main) "X hangs on startup on Imac G5 1.8 Ghz (dup-of: 23445)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/51285
<ubotu> New bug: #47579 in xorg (main) "Logitech MX518 mouse does not work completely" [Wishlist,Rejected]  https://launchpad.net/bugs/47579
<ubotu> New bug: #56100 in xorg (main) "regression: poor X11 performance on Dell Latitude D810" [Undecided,Rejected]  https://launchpad.net/bugs/56100
<ubotu> New bug: #57914 in xorg (main) "xorg crashes when viewing long text lines" [Undecided,Needs info]  https://launchpad.net/bugs/57914
<ubotu> New bug: #106365 in linux-restricted-modules-2.6.20 (restricted) "wrong Kernel Modul with Nvidia-GLX " [Undecided,Unconfirmed]  https://launchpad.net/bugs/106365
<ubotu> New bug: #34697 in linux-source-2.6.20 (main) "kernel panic when X server terminates" [Medium,Fix released]  https://launchpad.net/bugs/34697
<ubotu> New bug: #57817 in xorg-server (main) "Upgrade to  1:1.0.2-0ubuntu10.4 buggy" [Undecided,Fix released]  https://launchpad.net/bugs/57817
<ubotu> New bug: #107301 in xorg (main) "Xorg crashes on boot w/ vesa" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107301
<ubotu> New bug: #107320 in xserver-xorg-video-intel (universe) "Large font in the GDM login text field after installing xserver-xorg-video-intel" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107320
<ubotu> New bug: #107115 in linux-restricted-modules-2.6.20 (restricted) "log out or switch user results in crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107115
<kylem> tepsipakki, pingaling?
<tepsipakki> pongaling
<kylem> tepsipakki, i hear from ajax that you might have a vesa patch that should help on r5xx gpus?
<tepsipakki> for xorg-server, yes
<kylem> did you upload? BenC has a symptomatic machine it would be good to test on.
<tepsipakki> see bug 89853
<ubotu> Malone bug 89853 in xorg-server "[regression]  7.2 broke vesa: "No matching modes found"" [High,Needs info]  https://launchpad.net/bugs/89853
<kylem> thanks!
<tepsipakki> there's a link to the package
<tepsipakki> np, too bad I didn't debug this earlier.. the bug is old enough
<kylem> it's cool
<kylem> did you talk to Mith/colin about delaying feisty over it?
<tepsipakki> it's going to -updates
<kylem> k.
<tepsipakki> so, yes
<kylem> thanks!
<tepsipakki> ..yes I did talk, no feisty will not be delayed ;)
<kylem> hehe.
<tepsipakki> almost 40 xorg bugs closed/reassigned today.. whee, lot of low-hanging fruits
<kylem> :)
<ubotu> New bug: #56268 in xorg (main) "xorg wrongly rewrites xorg.conf on detection of new PCI card" [Low,Confirmed]  https://launchpad.net/bugs/56268
<ubotu> New bug: #54108 in xorg (main) "No Resolution CHeck" [Undecided,Needs info]  https://launchpad.net/bugs/54108
#ubuntu-x 2007-04-18
<ubotu> New bug: #53351 in xorg (main) "Screen redraw inconsistent (animations like cursor or XGL jerky)" [Undecided,Fix released]  https://launchpad.net/bugs/53351
<ubotu> New bug: #107127 in xserver-xorg-video-ati (main) "Feisty: Xubuntu + Compiz = Smaller than screen visual." [Undecided,Unconfirmed]  https://launchpad.net/bugs/107127
<ubotu> New bug: #99921 in xserver-xorg-video-ati (main) "3d effects mess up the desktop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99921
<ubotu> New bug: #54532 in xorg (main) "monitor DDC not correct in ubuntu dapper livecd?" [Undecided,Needs info]  https://launchpad.net/bugs/54532
<ubotu> New bug: #54633 in xserver-xorg-input-mouse (main) "mouse wheel zoom consistency" [Undecided,Needs info]  https://launchpad.net/bugs/54633
<ubotu> New bug: #106709 in xorg (main) "When resolution is changed to anything above 1280x1024@60, I cannot get the entire screen to fit correctly on the monitor." [Undecided,Needs info]  https://launchpad.net/bugs/106709
<ubotu> New bug: #107368 in linux-restricted-modules-2.6.20 (restricted) "nvidia-new-kernel-source package creates improperly named driver causing X not to start for custom compiled kernels" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107368
<ubotu> New bug: #107375 in xorg (main) "Xorg ATI resolution incorrect" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107375
<ubotu> New bug: #107380 in xserver-xorg-video-intel (universe) "Sometimes after logging in screen goes blank" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107380
<ubotu> New bug: #91042 in gdm (main) "GDM login text field shows overly large characters (dup-of: 107320)" [Undecided,Needs info]  https://launchpad.net/bugs/91042
<ubotu> New bug: #106642 in xorg (main) "Entire system freezes (including virtual terminals) on resolution change." [Undecided,Needs info]  https://launchpad.net/bugs/106642
<ubotu> New bug: #107395 in xorg (main) "Resolution configured wrong on r200" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107395
<ubotu> New bug: #20501 in xorg (main) "[amd64]  Crash X sometimes with powernow-k8" [High,Rejected]  https://launchpad.net/bugs/20501
<ubotu> New bug: #105953 in xserver-xorg-video-nv (main) "Edgy & Fiesty LiveCD and fresh install hang with graphical corruption at splash screen(nVidia)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105953
<mvo> could some one have a look at this? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/107464
<ubotu> Malone bug 107464 in update-manager "dist-upgrade failure (edgy->feisty) - SystemError from cache.commit(): installArchives() failed - cannot create `./usr/lib/libGL.so.1.2'" [Undecided,Unconfirmed]  
<mvo> its the second report I got about this
<tepsipakki> mvo_: hm, that's probably due to l-r-m
<tepsipakki> or not
<tepsipakki> oh, xorg-driver-fglrx also has that file
<mvo_> the stange thing is that its not a normal file overwrite error
<mvo_> probably dpkg-divert madness
<tepsipakki> now that we have restricted-manager, maybe it's time to not make nvidia-glx/x-d-fglrx divert but instead let r-m change the xorg.conf
<tepsipakki> since that's what other distributions seem to do (gentoo for instance)
<tepsipakki> of course it's not doable for feisty
<tepsipakki> the driver can be told to search libGL from a specific path
<tepsipakki> that would also make these drivers installable in parallel
<tepsipakki> which, IIRC, has a spec somewhere
<tepsipakki> mvo: yes, it's probably something in xorg-driver-fglrx (=l-r-m)
<ubotu> New bug: #107489 in xorg (main) "x server crash after return from sleep mode" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107489
<mvo_> tepsipakki: thanks for looking into it
<ubotu> New bug: #105987 in xorg (main) "Ubuntu 6.10 hangs on first boot" [Undecided,Needs info]  https://launchpad.net/bugs/105987
<ubotu> New bug: #24030 in xkeyboard-config (main) "Dvorak Left Hand keyboard layout needed" [Medium,Fix released]  https://launchpad.net/bugs/24030
<ubotu> New bug: #107548 in xman (main) "Xman can't find manual pages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107548
<ubotu> New bug: #34590 in xorg (main) "DRI not Automatically Enabled for ATI Rage Mobility P/M - Mach64" [Wishlist,Confirmed]  https://launchpad.net/bugs/34590
<ubotu> New bug: #107572 in adept (main) "Adept error message at startup (dup-of: 42553)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107572
<ubotu> New bug: #104556 in xorg (main) "Xubuntu 6.06 hangs on boot" [Undecided,Needs info]  https://launchpad.net/bugs/104556
#ubuntu-x 2007-04-19
<ubotu> New bug: #95446 in linux-restricted-modules-2.6.20 (restricted) "Beryl does not work with ATI when fglrx is installed" [Undecided,Rejected]  https://launchpad.net/bugs/95446
<ubotu> New bug: #55940 in xserver-xorg-input-mouse (main) "PS2 mouse generates sometimes more events as expected" [Undecided,Needs info]  https://launchpad.net/bugs/55940
<tepsipakki> ffs, our xserver lacked a mode for 1440x900@60
<tepsipakki> kylem: did ben test the patched xserver on his mac?
<tepsipakki> Mithrandir: is 7.04.1 out of the question?
<Mithrandir> not utterly, but it's quite a bit of work.
<tepsipakki> yes, I realize that
<tepsipakki> maybe I could make an unofficial image for those who can't use the released livecd
<tepsipakki> I guess there would be others besides me asking for updates to the images if a point release would be made :P
<Mithrandir> you should work on getting the fixes for the X bits into -updates at least, since that's where a .1 would be built from.
<tepsipakki> yeah
<tepsipakki> there are people testin the server
<Mithrandir> coolie
<Mithrandir> make sure we get minimal changes which are reviewable.  We really, really don't want a repeat of the previous X fuckup. :-)
<tepsipakki> additional modeline for 1440x900@60Hz, and the patch from fedora
<tepsipakki> I remember that one :)
<ubotu> New bug: #107638 in xrdb (main) "[apport]  xrdb crashed with SIGFPE when starting Monitor and display settings" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107638
<ubotu> New bug: #47321 in xorg (main) "Dapper Regression: No OpenGL for ATI Radeon IGP 320M" [Medium,Needs info]  https://launchpad.net/bugs/47321
<ubotu> New bug: #107464 in mesa (main) "dist-upgrade failure (edgy->feisty) - SystemError from cache.commit(): installArchives() failed - cannot create `./usr/lib/libGL.so.1.2'" [Undecided,Confirmed]  https://launchpad.net/bugs/107464
<ubotu> New bug: #21471 in linux-restricted-modules-2.6.15 (restricted) "WiFi Detection of and Use of Netgear WG311v2" [Medium,Unconfirmed]  https://launchpad.net/bugs/21471
<ubotu> New bug: #94899 in xkeyboard-config (main) "Shortcut Alt-PrintScreen for taking a screenshot does not work" [Low,Unconfirmed]  https://launchpad.net/bugs/94899
<ubotu> New bug: #94656 in xorg (main) "older cards fail Feisty default GDM install" [Low,Unconfirmed]  https://launchpad.net/bugs/94656
<ubotu> New bug: #55270 in control-center (main) "Double-click timeout is not applied to X (dup-of: 28052)" [Low,Rejected]  https://launchpad.net/bugs/55270
<ubotu> New bug: #54781 in pbbuttonsd (main) "Terrible keyboard performance on PPC" [Undecided,Needs info]  https://launchpad.net/bugs/54781
<ubotu> New bug: #99739 in xorg (main) "screensaver preview crash closing my session" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99739
<ubotu> New bug: #107723 in xorg (main) "X crashes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107723
<ubotu> New bug: #107646 in xorg (main) "nvidia kernel module has version mismatch with nvidia xorg module" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107646
<ubotu> New bug: #107732 in libx11 (main) "Security update of libx11-6 leads to crash of Opera 9.10 on Ubuntu 6.10 (edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107732
<ubotu> New bug: #107711 in xorg (main) "Ubuntu i386 7.04 can't be installed, it dissables many things like x win." [Undecided,Unconfirmed]  https://launchpad.net/bugs/107711
<ubotu> New bug: #107734 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107734
<ubotu> New bug: #102939 in xorg (main) "poor output quality on external projector + Fn key issue" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102939
<ubotu> New bug: #107601 in linux-restricted-modules-2.6.20 (restricted) "video output corruption with nvidia driver and not with nv driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107601
<ubotu> New bug: #105106 in xorg (main) "7.04 Beta: X Config Failure at Installation" [Undecided,Needs info]  https://launchpad.net/bugs/105106
<ubotu> New bug: #107744 in linux-restricted-modules-2.6.20 (restricted) "nv_drv gets loaded instead of nvidia_drv when selecting nvidia in xorg.conf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107744
<ubotu> New bug: #42540 in xserver-xorg-video-ati (main) "XServer fails on startup - Mac + ATI Rage 128 - no VESA" [Medium,Needs info]  https://launchpad.net/bugs/42540
<ubotu> New bug: #107768 in xorg (main) "right Alt key disabled on certain laptops" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107768
<ubotu> New bug: #107780 in libx11 (main) "rdesktop segmentation fault after libX11-6 update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107780
<ubotu> New bug: #107592 in xorg (main) "Upgrade to Feisty deleted monitor refresh rates, not being able to log-in graphically" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107592
<ubotu> New bug: #107759 in xorg (main) "The detection of display resolution is wrong" [Undecided,Needs info]  https://launchpad.net/bugs/107759
#ubuntu-x 2007-04-20
<ubotu> New bug: #107831 in xorg (main) "Feisty don't work with nVidia GeForce 8800 GTS and 8800 GTX" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107831
<ubotu> New bug: #107837 in xserver-xorg-video-vesa (main) "Xorg restarts when running "glxinfo"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107837
<ubotu> New bug: #107847 in linux-restricted-modules-2.6.20 (restricted) "[feisty amd64]  nvidia binary driver causes failure of X to start owing to failure to load kernel module" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107847
<ubotu> New bug: #107786 in linux-restricted-modules-2.6.20 (restricted) "switch from dekstop to console and back  black screen" [Undecided,Confirmed]  https://launchpad.net/bugs/107786
<ubotu> New bug: #107900 in xserver-xorg-input-mouse (main) "Mouse buttons 6 and 7 provide a new function after upgrade." [Undecided,Unconfirmed]  https://launchpad.net/bugs/107900
<ubotu> New bug: #107903 in xorg (main) "Rdesktop Crash After XOrg Update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107903
<ubotu> New bug: #107876 in xorg (main) "Microsoft IntelliMouse Explorer 3.0 not installed correctly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107876
<ubotu> New bug: #107909 in linux-restricted-modules-2.6.20 (restricted) "Files corrupt in ubuntu-7.04-dvd-i386.iso" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107909
* Starting logfile irclogs/ubuntu-x.log
<Mithrandir> tepsipakki: can you get something about the VESA X failure into the release notes?  I hear reports that disconnecting the monitor while X starts is a workaround (albeit not a very practical long-term one)
<tepsipakki> I'm not sure it's the same bug..
<Mithrandir> ugh. :-/
<tepsipakki> we need a backtrace of the original, I've built debug-versions of the server and driver.. there are two guys who have helped
<tepsipakki> although I did mark it as a dupe
<tepsipakki> hrm
<tepsipakki> the bug is not in vesa, but the server
<tepsipakki> since herd5 didn't have the new vesa
<Mithrandir> ok
<tepsipakki> fedora has patches which should help, but with those it segfaults instead
<Mithrandir> hardly an improvement
<tepsipakki> so ajax would like to have a backtrace
<tepsipakki> yeah
<ubotu> New bug: #107920 in xorg (main) "[apport]  package x-window-system-core failed to install/upgrade: " [Undecided,Unconfirmed]  https://launchpad.net/bugs/107920
<ubotu> New bug: #107921 in xorg (main) "[apport]  package xorg failed to install/upgrade: " [Undecided,Unconfirmed]  https://launchpad.net/bugs/107921
<tepsipakki> Mithrandir: actually, that "disconnect the monitor" guy replied to a couple of old bugs, and I've told him now to open a new one to see if it really is a dupe
<tepsipakki> which I doubt, since it's not a laptop
<tepsipakki> but you never know with X...
<Mithrandir> ok
<ubotu> New bug: #97272 in linux-restricted-modules-2.6.20 (restricted) "nvidia kernel module is older then the nvidia x module" [Undecided,Rejected]  https://launchpad.net/bugs/97272
<ubotu> New bug: #53241 in xserver-xorg-input-keyboard (main) "British keyboard layout not working" [Undecided,Unconfirmed]  https://launchpad.net/bugs/53241
<ubotu> New bug: #107945 in libx11 (main) "Security update of libx11-6 causes IDL segfault" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107945
<ubotu> New bug: #107947 in linux-restricted-modules-2.6.20 (restricted) "Nvidia binary driver causes progressive breakage" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107947
<ubotu> New bug: #102411 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx-new]  resume from hibernation doesn't work" [Undecided,Confirmed]  https://launchpad.net/bugs/102411
<ubotu> New bug: #93549 in linux-restricted-modules-2.6.20 (restricted) "nvidia-settings is not displayed in menus" [Undecided,Confirmed]  https://launchpad.net/bugs/93549
<ubotu> New bug: #107915 in linux-restricted-modules-2.6.20 (restricted) "Feisty upgrade error and crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107915
<ubotu> New bug: #107975 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107975
<ubotu> New bug: #108007 in mesa (main) "[apport]  package libgl1-mesa-dev failed to install/upgrade: " [Undecided,Unconfirmed]  https://launchpad.net/bugs/108007
* netjoined: irc.freenode.net -> brown.freenode.net
<ubotu> New bug: #108056 in xserver-xorg-video-intel (universe) "xserver-xorg-video-intel does not work with 82852/855GM" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108056
<ubotu> New bug: #38629 in linux-restricted-modules-2.6.15 (restricted) "Bug in upstream NVidia driver causes Cegeda (and maybe wine) poor performance" [Medium,Unconfirmed]  https://launchpad.net/bugs/38629
<ubotu> New bug: #108115 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108115
<ubotu> New bug: #108087 in linux-restricted-modules-2.6.20 (restricted) "compiz only shows contents of 3 windows" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108087
<ubotu> New bug: #82195 in linux-restricted-modules-2.6.20 (restricted) "Cannot modprobe fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82195
<ubotu> New bug: #108165 in mesa (main) "[apport]  package libgl1-mesa-dev failed to install/upgrade: " [Undecided,Unconfirmed]  https://launchpad.net/bugs/108165
<ubotu> New bug: #108172 in linux-restricted-modules-2.6.20 (restricted) "Crash during upgrade to feisty" [Undecided,Needs info]  https://launchpad.net/bugs/108172
<ubotu> New bug: #108191 in linux-restricted-modules-2.6.20 (restricted) "Cannot run 2.6.20-15 kernel nvidia driver on my AMD64 computer. 2.6.20-14 modules work well" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108191
<ubotu> New bug: #108192 in xkeyboard-config (main) "some keys on my generic USB keyboard do not work properly ufter upgrading from kubuntu 6.10 to 7.04" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108192
<ubotu> New bug: #108210 in xorg-server (main) "1680x1050 resolution won't work." [Undecided,Unconfirmed]  https://launchpad.net/bugs/108210
<ubotu> New bug: #104344 in xorg (main) "hp media center pc864n mouse scroll doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104344
<ubotu> New bug: #99030 in linux-restricted-modules-2.6.20 (restricted) "X takes approx. 20 min to start. with nvidia driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99030
<ubotu> New bug: #99271 in linux-restricted-modules-2.6.20 (restricted) "screen saver?  come on................." [Undecided,Unconfirmed]  https://launchpad.net/bugs/99271
<ubotu> New bug: #99158 in mesa (main) "Text in (some) openGL applications is scrambled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99158
<ubotu> New bug: #99274 in xorg (main) "Two X-Server Errors on Two Systems" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99274
<ubotu> New bug: #96155 in xorg (main) "CTL-ALT-BKSP does not restart the desktop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96155
<ubotu> New bug: #96276 in linux-restricted-modules-2.6.20 (restricted) "wifi and nvidia graphics/desktop effects broken after beta update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96276
<ubotu> New bug: #96498 in Ubuntu "install/live fails to configure the correct graphics card (dup-of: 42731)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96498
#ubuntu-x 2007-04-21
<ubotu> New bug: #108327 in xorg (main) "ATI Radeon 7200 not detected by x in livecd." [Undecided,Unconfirmed]  https://launchpad.net/bugs/108327
<ubotu> New bug: #108098 in xorg (main) "60Hz refresh frequency only on live cd" [Undecided,Needs info]  https://launchpad.net/bugs/108098
<ubotu> New bug: #108014 in xkeyboard-config (main) "Maltese keyboard layout error" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108014
<ubotu> New bug: #108057 in xkeyboard-config (main) "Romanian keyboard layout has incorrect characters" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108057
<ubotu> New bug: #108010 in xorg (main) "i810 default VideoRam insufficient for xinerama / high res" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108010
<ubotu> New bug: #107979 in xorg (main) "[x700] [feisty]  Feisty fails on start X server" [Undecided,Needs info]  https://launchpad.net/bugs/107979
<ubotu> New bug: #108402 in linux-restricted-modules-2.6.20 (restricted) "7.04 (fglrx) display corruption and hard lock with X1650 on SIS chipset" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108402
<ubotu> New bug: #107870 in xorg (main) "7.04 screensaver freezes keyboard and mouse" [Undecided,Needs info]  https://launchpad.net/bugs/107870
<ubotu> New bug: #108404 in xorg (main) "Fail to start X server on Live CD on NX9420 laptop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108404
<ubotu> New bug: #44562 in xorg (main) "Switch user causes screen resolution to change" [Medium,Unconfirmed]  https://launchpad.net/bugs/44562
<ubotu> New bug: #48048 in xorg (main) "could not install dapper with S1910 Eizo-Monitor" [Medium,Needs info]  https://launchpad.net/bugs/48048
<ubotu> New bug: #83024 in linux-restricted-modules-2.6.20 (restricted) "openGL apps (like games) dont work with the nvidia driver" [Undecided,Needs info]  https://launchpad.net/bugs/83024
<ubotu> New bug: #87986 in linux-restricted-modules-2.6.20 (restricted) "[Xubuntu Feisty]  nvidia-glx from the repository doesn't work" [Undecided,Needs info]  https://launchpad.net/bugs/87986
<ubotu> New bug: #85449 in linux-restricted-modules-2.6.20 (restricted) "[feisty]  nvidia-glx 1.0.9xxx causes graphical glitches, artifacts and random system crashes on an integrated GeForce2 MX" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85449
<ubotu> New bug: #97069 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx]  New Nvidia Driver not displaying 1600x1200 resolution" [Wishlist,Needs info]  https://launchpad.net/bugs/97069
<ubotu> New bug: #78057 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx]  nvidia proprietary driver defaults to 800x600 resolution" [Undecided,Needs info]  https://launchpad.net/bugs/78057
<ubotu> New bug: #98504 in linux-restricted-modules-2.6.20 "nvidia-glx fails to install during upgrade" [Undecided,Needs info]  https://launchpad.net/bugs/98504
<ubotu> New bug: #108464 in linux-restricted-modules-2.6.20 (restricted) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Needs info]  https://launchpad.net/bugs/108464
<ubotu> New bug: #104918 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx-new]  Asus z71v usually fails to recover from suspend-to-ram (since Edgy)" [Undecided,Confirmed]  https://launchpad.net/bugs/104918
<ubotu> New bug: #108484 in xorg (main) "Desktop size larger than display" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108484
<ubotu> New bug: #108491 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108491
<ubotu> New bug: #108516 in xorg (main) "feisty live cd freezes after starting xorg ati x1400" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108516
<ubotu> New bug: #25608 in xorg (main) "problem with microsoft wireless desktop elite keyboard/mouse (ps/2 ports)" [Medium,Needs info]  https://launchpad.net/bugs/25608
<ubotu> New bug: #108523 in xserver-xorg-input-mouse (main) "Logitech optical mouse scroll wheel not working correctly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108523
<ubotu> New bug: #26196 in xserver-xorg-input-mouse (main) "[dapper]  Back/forward buttons broken" [Medium,Confirmed]  https://launchpad.net/bugs/26196
<ubotu> New bug: #108419 in desktop-effects (main) "desktop effects crashed or could not be enabled (dup-of: 90850)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108419
<ubotu> New bug: #6279 in xorg (main) "[Dapper]  Firefox hard locks when RenderAccel is enabled" [Medium,Needs info]  https://launchpad.net/bugs/6279
<ubotu> New bug: #108546 in xorg (main) "Webpage causes high load of Xorg" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108546
<ubotu> New bug: #35444 in linux-source-2.6.15 (restricted) "Computer freezes with nvidia-glx and via-rhine" [Medium,Unconfirmed]  https://launchpad.net/bugs/35444
<ubotu> New bug: #108565 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108565
<ubotu> New bug: #35173 in linux-restricted-modules-2.6.15 (restricted) "[nvidia-glx-legacy]  xorg freezes when using nvidia-legacy driver" [Medium,Confirmed]  https://launchpad.net/bugs/35173
<ubotu> New bug: #108578 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-new: X does not start on reboot. Possible Module Mis-match?" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108578
<ubotu> New bug: #108422 in xorg (main) "Lock screen and switch user freeze in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108422
<ubotu> New bug: #108629 in xorg (main) "Undefined symbols using OSS ati-driver: mismatching driver-files" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108629
<ubotu> New bug: #108672 in xorg (main) "Viewing a file with totem plugin makes X crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108672
<ubotu> New bug: #107782 in linux-restricted-modules-2.6.20 (restricted) "X Crash after nVidia GeForce 5700 drivers installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107782
#ubuntu-x 2007-04-22
<ubotu> New bug: #105344 in nvidia-kernel-common (restricted) "nvidia-glx-new incorrect xorg.conf settings (dup-of: 48077)" [Undecided,Rejected]  https://launchpad.net/bugs/105344
<ubotu> New bug: #108614 in Ubuntu "samsung syncmaster 970p + nvidia 9150 incorrect image (dup-of: 31830)" [Undecided,Needs info]  https://launchpad.net/bugs/108614
<ubotu> New bug: #108787 in xrdb (main) "[apport]  xrdb crashed with SIGFPE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108787
<ubotu> New bug: #28648 in xserver-xorg-input-synaptics (main) "Slow movement regression of synaptics touchpad on v0.14.3+seriouslythistime" [Medium,Confirmed]  https://launchpad.net/bugs/28648
<ubotu> New bug: #108775 in linux-restricted-modules-2.6.20 (restricted) "Problems with screen resolution after installing proprietary nVIDIA drivers" [Undecided,Needs info]  https://launchpad.net/bugs/108775
<ubotu> New bug: #106691 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx]  glitches appear when using Twinview with compiz/beryl and the gnome-panel at the top is not set to "expand"" [Undecided,Needs info]  https://launchpad.net/bugs/106691
<ubotu> New bug: #108836 in xorg (main) "xorg stops responding with radeon x600 when graphics card is under load" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108836
<ubotu> New bug: #107633 in linux-restricted-modules-2.6.20 (restricted) "Dell Inspiron 8200 freezes after ~5 mins of work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107633
<ubotu> New bug: #108894 in xserver-xorg-video-ati (main) "Xvideo works only once per X server starts" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108894
<ubotu> New bug: #108937 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108937
<ubotu> New bug: #33075 in linux-restricted-modules-2.6.15 (restricted) "Dell Inspiron 8200 Nvidia proprietary driver causes display errors (vertical lines on the right, and mirror effect on the bottom)" [Medium,Confirmed]  https://launchpad.net/bugs/33075
<ubotu> New bug: #108996 in xrandr (main) "crashed on login to x" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108996
<ubotu> New bug: #37004 in linux-source-2.6.15 (main) "Wireless USB keyboard/mouse not working" [Medium,Needs info]  https://launchpad.net/bugs/37004
<ubotu> New bug: #108095 in xserver-xorg-video-nv (main) "Feisty Desktop CD and Display Resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108095
<ubotu> New bug: #109038 in xrandr (main) "[apport]  xrandr crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109038
<ubotu> New bug: #109054 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in sigaction()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109054
<ubotu> New bug: #83536 in xorg-server (main) "X.org crashes when scrolling in Firefox" [Undecided,Needs info]  https://launchpad.net/bugs/83536
<ubotu> New bug: #41610 in xserver-xorg-video-ati (main) "Screen Resolution tool fails to switch between MergedFB "dualhead" and "clone" modes" [Low,Confirmed]  https://launchpad.net/bugs/41610
#ubuntu-x 2008-04-14
<ubotu> New bug: #217002 in xserver-xorg-video-via (main) "Xserver crashes with VIA chipset" [Undecided,New] https://launchpad.net/bugs/217002
<ubotu> New bug: #217092 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new 169.12+2.6.24.500-500.23~envy fails to start" [Undecided,New] https://launchpad.net/bugs/217092
<ubotu> New bug: #216667 in xserver-xorg-input-vmmouse (main) "[hardy] USB mouse does not work on PowerPC live cd (20080413)." [Undecided,Confirmed] https://launchpad.net/bugs/216667
<james_w> seb128: does http://paste.ubuntu.com/6973/ correctly preserve translations?
<seb128> james_w: hum, was it translatable before? it's not between _()
<james_w> oh yeah, I didn't notice that.
<seb128> james_w: and I would rather use 2 times the same strings rather than introduce a variable, especially than we will be wanting to change one variant next cycle
<james_w> ah, ok
<james_w> should I mark them translatable?
<seb128> yes please
<seb128> the string is already in the translations apparently
<seb128> that was the one used by the upstream variant
<james_w> seb128: any better?
<james_w> http://paste.ubuntu.com/6977/
<james_w> the rest of the file uses gettext() rather than _()
<james_w> I haven't tested the localisation though.
<seb128> hum, using gettext
<seb128> james_w: seems to be alright
<ubotu> New bug: #217182 in xorg (main) "Rotate Screen in TabletPC stylus and pointer mouse not coincidence" [Undecided,New] https://launchpad.net/bugs/217182
<ubotu> New bug: #217189 in xserver-xorg-video-intel (main) "Rotating screen does not flip X/Y dimensions" [Undecided,New] https://launchpad.net/bugs/217189
<james_w> I'm not very familiar with debugging this type of segfault, if we have
<james_w> rw_mode_get_width (mode=0x3) at randrwrap.c:1104
<james_w> where mode is a pointer, and then a valgrind with 
<james_w> Invalid read of size 4
<james_w> Address 0xf is not stack'd, malloc'd or (recently) free'd
<james_w> from that function does that indicate that the pointer is being overwritten somewhere
<james_w> following the flow of the code I can't see anything wrong in the logic yet
<seb128> james_w: that means the code access a non valid memory address
<seb128> james_w: usually that's something used after being freed for example
<seb128> james_w: or a pointer being overwritten
<james_w> ok, it's not obvious to me where this could be happening.
<james_w> the stacktrace omits some functions, would this be due to optimisations?
<seb128> james_w: yes, likely
<seb128> james_w: looking to the code
<james_w> there are a bunch of code paths that call that function, so I'm not sure exactly which is being taken to trigger this, I've tried to follow them all, and haven't seen anything yet
<seb128> ==11339== Use of uninitialised value of size 4
<seb128> ==11339==    at 0x4073179: rw_mode_get_height (randrwrap.c:1118)
<seb128> ==11339==    by 0x804D636: rebuild_gui (xrandr-capplet.c:526)
<seb128> ==11339==    by 0x804F1AD: run_application (xrandr-capplet.c:1755)
<seb128> ==11339==    by 0x804F83B: main (xrandr-capplet.c:1799)
<jcristau> gdb doesn't tell you that?
<seb128> jcristau: there is a lot of static functions in this source and I think that the -O2 builds don't list those
<jcristau> gdb should be able to handle them
<seb128> well, -O2 stacktrace are not accurate for sure, I'm not sure to what it's due
<ubotu> New bug: #213295 in ubuntu "Shutdown does not take place (dup-of: 118605)" [Undecided,New] https://launchpad.net/bugs/213295
<seb128> optimization makes some call being not listed
<jcristau> inlining maybe
<seb128> could be yes
<seb128> james_w: do you get the issue?
<james_w> no, I haven't been able to reproduce
<ubotu> New bug: #217004 in xorg (main) "[hardy beta] install failure (regression) with ProSavageDDR graphics chipset" [Undecided,New] https://launchpad.net/bugs/217004
<seb128> james_w: I'll copy -O0 deb onlines and ask him to get a new valgrind log
<james_w> seb128: great, thanks
<james_w> a stacktrace may be useful as well
<seb128> james_w: 
<seb128> list_clone_modes (Configuration *config, RWScreen *screen)
<seb128>     RWMode **modes;
<seb128>     for (i = 0; config->outputs[i] != NULL; ++i)
<seb128>     {
<seb128> 	if (config->outputs[i]->connected)
<seb128> ...
<seb128>     if (!modes)
<seb128> 	return NULL;
<seb128>  
<seb128> and
<seb128> ==11339== Conditional jump or move depends on uninitialised value(s)
<seb128> ==11339==11339== Conditional jump or move depends on uninitialised value(s)
<seb128> ==11339==    at 0x804CF64: get_current_modes (xrandr-capplet.c:336)
<seb128> ==11339==    by 0x804D601: rebuild_gui (xrandr-capplet.c:516)
<seb128> ==    at 0x804CF64: get_current_modes (xrandr-capplet.c:336)
<seb128> ==11339==    by 0x804D601: rebuild_gui (xrandr-capplet.c:516)
<seb128>  
<seb128> james_w: that seems to indicate that the if condition in the loop is never true and it uses an uninitialised value
<seb128> james_w: using 
<seb128> - RWMode **modes;
<seb128> + RWMode **modes = NULL;
<seb128> might be enough
<james_w> yeah, that sounds sensible
<seb128> l336 is the "if (!modes)" one
<tjaalton> (II) SAVAGE(0): Configured Monitor: Using hsync value of 0.00 kHz
<tjaalton> (II) SAVAGE(0): Configured Monitor: Using vrefresh value of 0.00 Hz
<tjaalton> great
<james_w> and that function calls the one at the top of the stacktrace eventually, with an item from the **modes
<tjaalton> quality there, no DDC info -> use 0 by default
<james_w> seb128: shall I prepare a debdiff of that change for upload, or would you like me to work with submitter first to test it?
<seb128> james_w: I've no clue if that's enough to fix the issue of will just forward the bug to some other place, would be nice to get him testing the change
<james_w> sure, I can do that.
<seb128> thanks
<seb128> james_w: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/215396 too btw
<ubotu> Launchpad bug 215396 in gnome-control-center "gnome-display-properties crashed with SIGSEGV in _start() [when running xgl]" [Medium,New] 
<seb128> james_w: could be the same bug
<seb128> james_w: did you try to run the capplet under valgrind using xgl?
<james_w> no, I didn't
<james_w> that one has "on_screen_changed (scr=0x0", which is probably the cause
<seb128> right
<seb128> james_w: ok, so your packages work but you built using -O0 right?
<james_w> yes, noopt,nostrip
<seb128> ok, so it doesn't tell us if the fix is enough
<seb128> I've asked for a new valgrind log
<seb128> noopt will do -O0 and variables will be initialized
<seb128> which will hide the non-initialized issues
<james_w> ah, ok, shall I build some packages with the patch but normal build options?
<seb128> you have other pending changes right? I would say to just upload the patch from this morning and this init now
<seb128> or maybe try to fix the other crasher under xgl
<james_w> it sounds like he is suffering from an issue that would trigger this, i.e. (config->outputs[i]->connected) is probably never true for him
<seb128> right
<james_w> yeah, I'll look in to the other one that you pointed me to and see if we can roll in that fix as well.
<seb128> cool, thanks
<james_w> I don't think I can't reproduce any of these Xgl bugs anymore though unfortunately, it fails so early for me that it barely covers any of the code.
<james_w> this other one looks pretty straightforward though.
<seb128> right
<tjaalton> soren: please push your fix for mdetect, I'll change the vmmouse-handling.. Of course I should've noticed that the damn package doesn't exist for !{amd64,i386} :P
<tjaalton> so no wonder those suckers have no mouse
<soren> tjaalton: You run mdetect as root, right_
<soren> ?
<tjaalton> soren: yes, it's done on xserver-xorg.postinst (dexconf)
<soren> tjaalton: Great.
<tjaalton> hum, xserver-xorg needs to depend on mdetect then
<tjaalton> now it only recommends it
<tjaalton> soren: do you have mdetect installed by default on your virtual machines? I wonder if Recommends should suffice
<soren> tjaalton: I don't.
<tjaalton> ok, so it needs to be bumped
<tjaalton> soren: what do you think of bug 216276?
<ubotu> Launchpad bug 216276 in kvm "Regression: mouse support stopped working" [Undecided,New] https://launchpad.net/bugs/216276
<tjaalton> (EE) xf86OpenSerial: No Device specified.
<soren> tjaalton: Er, yeah, vmmouse requires a device to be set.
 * soren hasn't read the bug, but from the context, I guess that's the issue.
 * soren reads the bug
<tjaalton> soren: ah, ok.
<soren> Well, just /dev/input/mice works fine.
<soren> AFAIR.
<soren> Is that so bad?
<tjaalton> soren: no, if it doesn't change :)
<soren> What? The presence of /dev/input/mice? Why would that change?
<tjaalton> it shouldnt
<tjaalton> anyway, I'll add a check to add the device if it's a virtual setup
<soren> Ok, cool. We should check that it works, though, but I belive it does.
<soren> tjaalton: Ok. It should be almost functionally equivalent, but if you're more comfortable that way, that's cool.
<soren> "almost" because in case we're converting a physical install to a virtual install (something I intend to work on a bit for intrepid), it'll need config changes.
<seb128> james_w: how is the update going?
<james_w> I'm hainvg trouble tracking this other one down
<james_w> the NULL parameter isn't used.
<james_w> it also reports that config is NULL, but there is a check for that in the function
<seb128> how used?
<seb128> hum
<seb128> let me have a look
<seb128> james_w: on what line is the check?
<james_w> 122 here
<james_w>     g_return_val_if_fail (current != NULL, NULL);
<seb128> no
<seb128> your version has not been uploaded
<seb128> current is 0ubuntu5
<seb128> and it has 
<seb128>     current = configuration_new_current (app->screen);
<seb128>     if (app->current_configuration)
<seb128> 	configuration_free (app->current_configuration);
<james_w> current, not config sorry
<seb128> 122 is the if line
<james_w> ah, did I add that?
<seb128> yes
<seb128> is there an update pending upload?
<seb128> I'm not sure if your debdiff were work on progress or sponsoring request, maybe there was some misunderstanding and something should have been uploaded but has not been yet?
<james_w> no, it's fine, I just didn't remember adding that line
<seb128> your check is weird
<james_w> it's fine, I was just confused about what was uploaded and what wasn't/
<seb128> static void
<seb128> on_screen_changed 
<seb128> if should return
<seb128> and not return value, no?
<james_w> yeah, I thought it was odd as I was doing it, but didn't think to check.
<james_w> I've been in python land for too long.
<seb128> ;-)
<seb128> ok, anyway
<seb128> let's change that one to just return and get the 3 changes uploaded?
<james_w> yeah, I'll do that.
<seb128> the xgl error dialog, the init we added this morning and this check?
<seb128> ok, good, thanks
<seb128> we are getting better at each iteration ;-)
<james_w> should I disable the help button as well?
<james_w> s/disable/remove/
<ubotu> New bug: #216276 in xorg (main) "Regression: mouse support stopped working" [Undecided,Fix committed] https://launchpad.net/bugs/216276
<seb128> james_w: yes please
<seb128> james_w: other requests came my way meanwhile ;-)
<seb128> james_w: could you also change 01_debian_ubuntu.patch (you can rename it) to remove the debian specific choices rather, those are confusing for desktop users apparently
<seb128> james_w: and the firefox entry in capplets/default-applications/gnome-default-applications.xml.in needs to be updated for use firefox-3.0 as icon name
<james_w> sure, any bug numbers you want closing for these changes?
<seb128> let me look
<seb128> mpt mentionned those on #ubuntu-desktop, not sure if they are in launchpad
<james_w> ok
<seb128> james_w: no bugs apparently
<james_w> seb128: http://paste.ubuntu.com/7005/
<james_w> how's that?
<seb128> james_w: looking
<seb128> james_w: loosk good to me, I'll sponsor the upload, thanks
<james_w> thanks
<james_w> and huge thanks for actually finding the bugs :-)
<seb128> and thank you for working on those ;-)
<Q-FUNK> bryce: ?
<Q-FUNK> anyone?
<Q-FUNK> any news on sync'ing -geode from debian?
<bryce> tjaalton: do you really think we should disable atieventsd?  I noticed a lot of bug reports on it crashing.  What does it do exactly?  Just a manager for multi-head or something?
<tjaalton> bryce: yep, something to do with multi-head.. and it seems rather unstable
<tjaalton> ..if it crashes when updating some libs for example
<bryce> hmm, well if it's not strictly required for basic use of fglrx, then I'd also favor disabling it.
<bryce> people will be upset at not being able to configure multiscreen, but hey, only so much crashy proprietary software we can reasonably support ;-)
<bryce> fwiw, I raised that issue with ATI and am awaiting their feedback on it.
<bryce> I will also let them know we plan to disable that tool due to crashes in it
<tjaalton> ok cool. it was enabled in December I think
<tjaalton> so it's not a regression to turn it off by default
<ubotu> New bug: #213753 in xserver-xorg-video-ati (main) "Cannot get normal graphical session running after install" [High,Incomplete] https://launchpad.net/bugs/213753
<bryce> tjaalton: btw, any reservations if I push the xserver patch for the firefox XAA offscreenpixmaps issue?  (bug #182038).  Basically it inverts the logic for that option, setting XAAOffscreenPixmaps False by default
<ubotu> Launchpad bug 182038 in xorg-server "Black rectangle instead of image in FF3 [Hardy]" [Medium,Confirmed] https://launchpad.net/bugs/182038
<tjaalton> bryce: nope, I guess we'll hear if it causes trouble ;)
<bryce> (er, True by default??  Anyway, inverts it.)
<tjaalton> but as fedora has done the same, it's probably not that bad
<bryce> ...uploading...
<bryce> ...awaiting approval... ;-)
<ubotu> New bug: #217396 in xorg (main) "Hard lockup in X about once a week" [Undecided,Incomplete] https://launchpad.net/bugs/217396
<ubotu> New bug: #99898 in linux-restricted-modules-2.6.24 (restricted) "kdevelop make X crash" [Undecided,Confirmed] https://launchpad.net/bugs/99898
<ubotu> New bug: #215689 in xorg (main) "Wacom tablet is not supported anymore" [Undecided,Confirmed] https://launchpad.net/bugs/215689
#ubuntu-x 2008-04-15
<ubotu> New bug: #217568 in xserver-xorg-video-ati (main) "Error activating XKB configuration" [Undecided,New] https://launchpad.net/bugs/217568
<ubotu> New bug: #217627 in xkeyboard-config (main) "Japanese keyboard layout is incorrct in the case of upgrading 7.10 to 8.04" [Undecided,New] https://launchpad.net/bugs/217627
<ubotu> New bug: #217210 in ubuntu-jp-improvement "[hardy beta] Error activating XKB configuration (dup-of: 217627)" [High,Confirmed] https://launchpad.net/bugs/217210
<james_w> seb128: hi.
<seb128> hey james_w
<james_w> I've got another proposed patch for you
<james_w> http://paste.ubuntu.com/7101/
<james_w> apologies for the formatting, this file is a pretty terrible mix of tabs and spaces
<james_w> I think the bug is caused by decode_edid returning NULL, and so info->manufacturer_code segfaults
<seb128> looks good, no worry about the formatting
<james_w> info is fine to be null in the else branch and afterwards, so I just added the check
<bryce> hey guys
<seb128> hey bryce, how are you?
<james_w> the second part of the change was just chasing all callers looking for anything that didn't handle NULL from this function (this isn't the only way to get NULL from it though).
<james_w> hey bryce 
<seb128> james_w: ok
<bryce> seb128: feeling married ;-)
<seb128> james_w: while you are at it, when running gnome-display-properties you get CRTC and Output lines g_printed, can you comment those?
<seb128> bryce: ah right, congratulations!
<james_w> congratulations bryce 
<bryce> nice work on the patch james.  amazing how little null pointer checking fedora is doing
<tjaalton> bryce: congrats! I hope the weather was nice :)
<bryce> bdmurray took some photos - http://www.murraytwins.com/gallery/HarringtonWedding
<james_w> yeah, your audit helped a lot, but there's still a few places.
<bryce> tjaalton: it was the most awesomest weather you could ever have
<tjaalton> bryce: heh, seems like it
<james_w> bryce: I'll have a little time today to push these patches back upstream if you like.
<bryce> james_w: that'd be great
<bryce> james_w: not much response on the ones I sent up last week, although sounds like suse merged them into a new git tree (*shrug*)
<seb128> could somebody quickly glance at http://paste.ubuntu.com/7102/ and tell me if that looks alright?
<bryce> img 1103 - that's cworth with bdmurray's twins; 1105 is bdmurray and tedg, keescook is in 1098 and others
<james_w> bryce: ok, where do I send them, to ssp, or is there a list?
<bryce> james_w: send them to the gnomecc mailing list
<james_w> seb128: I'm not comfortable with gettext, sorry.
<james_w> bryce: sure.
<bryce> I usually cc ssp, although he's hardly ever responded
<seb128> james_w: that's alright
<bryce> seb128: looks ok to me 
<seb128> thanks
<bryce> am I remembering right that N_() is "do not translate"?
<seb128> bryce: nice pictures, I didn't know that you know cworth
<bryce> seb128: yeah he lives just down the road a bit; we get together for board games periodically and bump into each other at conferences ;-)
<seb128> bryce: the struct is static so they can't be translated there, the N_() make those being listed in the template and the _() calls then translate the string used
<seb128> bryce: ah ok, small world ;-)
<james_w> bryce: I removed the help button in yesterday's upload, is that the best thing for hardy?
<tjaalton> mm, bunnies
<bryce> james_w: yeah in fact I had "do something with help button" on my todo list since the start.  I'd hoped to write some help text, but your patch is a more realistic solution
<bryce> tjaalton: yeah we gave out bunny food as our wedding favors.  ;-)  Thankfully no one got the idea to use it as rice to throw at us!
<tjaalton> hehe :)
<tjaalton> we had rice I guess.. too bad the car we got into was a convertible :=)
<bryce> there were a LOT of children at the wedding in just the right age range to appreciate beaches and bunnies, they had lots of fun
<james_w> bryce: yes, it's easy to re-enable it if we have some help text though.
<tjaalton> one kid threw a handful right onto my face when I got comfortably on the backseat
<bryce> tjaalton: heh
<bryce> james_w: ok maybe I'll draft something up tomorrow if I have time
<seb128> I would not bother with that
<seb128> it likely requires to modify the build system, to have a structured xml, etc and hardy is frozen now
<bryce> seb128: oh, okay
<seb128> better to focus effort on bugs fixing
<bryce> tjaalton: you know how I took as a goal to get -intel to <100 bugs for hardy... for intrepid I'm thinking maybe take the goal of getting our total X bugs to <1000 (from ~1500 currently)
<tjaalton> bryce: ambitious but hopefully doable :)
<bryce> yup
<james_w> seb128: http://paste.ubuntu.com/7103/
<seb128> james_w: looks good, thanks, could you just document the new prints change in the changelog though?
<james_w> ah yes, of course, sorry
<seb128> np
<james_w> http://paste.ubuntu.com/7105/
<seb128> looks good, I'll sponsor the upload, thanks
<james_w> thank you.
<james_w> seb128: I've tested the debdiff in https://bugs.edge.launchpad.net/ubuntu/+source/nautilus-python/+bug/215714/ and it works, would you be willing to sponsor it?
<ubotu> Launchpad bug 215714 in nautilus-python "The path for python extensions should reflect the 2.0 api" [Medium,Confirmed] 
<seb128> james_w: sure
<seb128> I'll do that after lunch
<james_w> thanks
<Q-FUNK> hm
<ubotu> New bug: #217694 in xorg (main) "Incorrect resolution Hardy beta nvidia & 1680x1050 LCD" [Undecided,New] https://launchpad.net/bugs/217694
<mvo> tjaalton: hello, do you have a moment? I think we talked a while ago about x11-common and that it shouldn't fail if it can not remove /usr/X11R6/bin? I got a report that dapper->hardy can fail if that is not empty and I think that we need to fix it. I'm happy to work on it 
<mvo> tjaalton:  just want to confirm with your first
<tjaalton> mvo: oh right, sure
<tjaalton> so it can be a 3rd party app that installed stuff in there, and then it could be moved aside and let the user know about it?
<mvo> bug #217724
<ubotu> Launchpad bug 217724 in xorg "xqbiff prevents x11-common from removing /usr/X11R6/bin" [High,Confirmed] https://launchpad.net/bugs/217724
<mvo> yeah
<mvo> everything is better than to fail in the preinst
<mvo> I would say move away and debconf note it, with critical priority if its that important (I have no idea), but failure is the worst solution :)
<mvo> tjaalton: I milestoned it and will check it out after I finished with my current stuff (unless you are quicker of course :P)
<ubotu> New bug: #217724 in xorg (main) "xqbiff prevents x11-common from removing /usr/X11R6/bin" [High,Confirmed] https://launchpad.net/bugs/217724
<tjaalton> mvo: heh
<tjaalton> maybe it would make sense to also add a Conflicts against every package in dapper which has stuff in there.. because otherwise you can't remove those packages fully after the migration, right?
<Q-FUNK> tjaalton: anything to add to bug #211385 ?
<ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,Incomplete] https://launchpad.net/bugs/211385
<tjaalton> Q-FUNK: yes, I basically agree with what you said
<tjaalton> so I'll follow up on the bug
<Q-FUNK> ok, thanks
<mvo> tjaalton: right, a conflicts; foo << (version-with-stuff-in-x11r6)
<tjaalton> mvo: yeah.. apt-file failed on me, but there should be a way to get a list of apps that use that dir?
<mvo> tjaalton: we can simply grab the contents file in dapper
<tjaalton> mvo: right, that's what apt-file should use too
<mvo> joy, looks like the contens file in dapper is empty
<tjaalton> k.. :P
<tjaalton> bbl, haircut ->
<mvo> tjaalton: http://people.ubuntu.com/~mvo/tmp/xorg_7.3+10ubuntu10.debdiff <- please have a look when you are back
<ubotu> New bug: #216683 in firefox-3.0 (main) "Black rectangle instead of image in FF3 [Hardy] (dup-of: 182038)" [Undecided,New] https://launchpad.net/bugs/216683
<jcristau> tjaalton: bug 217647 might want 9500033b9ecdfaf5a56a4355ffc94d74cb17ca17
<ubotu> Launchpad bug 217647 in xorg-server "Crash at startup on PS3 (hardy)" [Undecided,New] https://launchpad.net/bugs/217647
<ubotu> New bug: #217804 in xorg (main) "External screen goes BLACK or GRAY" [Undecided,New] https://launchpad.net/bugs/217804
<Q-FUNK> oh.  new core package?
<mvo> tjaalton: did you had a chance to look at my debdiff yet?
<ubotu> New bug: #217867 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/217867
<tjaalton> mvo: yeah, sorry it took a while
<tjaalton> mvo: looks good. should I commit it and upload for RC?
<mvo> tjaalton: yeah, that would be cool. I will just run a upgrade test, should be finished in some minutes (~20min)
<tjaalton> jcristau: thanks, it looks like a valid patch to add even at this stage
<mvo> tjaalton: all looks good, please go ahead with the upload
<mvo> tjaalton: maybe we should add a conflicts against xqbiff as well
<mvo> tjaalton: it got removed from ubuntu, but at least the dapper version still has stuff in /usr/X11R6/bin
<tjaalton> mvo: yep, I'll add it
<mvo> tjaalton: great, thanks
 * mvo hugs tjaalton
 * tjaalton hugs mvo back
 * mvo -> bed
<ubotu> New bug: #183970 in xserver-xorg-video-ati "[livecd] LiveCd on HP Compaq 6715s stops when trying to display desktop" [Undecided,New] https://launchpad.net/bugs/183970
#ubuntu-x 2008-04-16
<ubotu> New bug: #218000 in xorg (main) "XRandR Rotation with -intel doesn't work with a composite manager" [Undecided,New] https://launchpad.net/bugs/218000
<james_w> bryce: hi, you're not still up are you?
<ubotu> New bug: #218087 in wacom-tools (main) "replace wacom 0.7.4 with 0.7.8-3  for hardy" [Undecided,New] https://launchpad.net/bugs/218087
<ubotu> New bug: #218122 in xserver-xorg-video-intel (main) "[hardy] Mac mini. Intel 945GM. Random screen flickering. Black screen after that." [Undecided,New] https://launchpad.net/bugs/218122
<ubotu> New bug: #218214 in linux-restricted-modules-2.6.24 (restricted) "fglrx 8-01 pointer corruption" [Undecided,New] https://launchpad.net/bugs/218214
<ubotu> New bug: #218229 in xserver-xorg-driver-ati "can't get DRI working" [Undecided,New] https://launchpad.net/bugs/218229
<bdmurray> bryce: around yet?  I'm in a place where I can test 181121
<ubotu> New bug: #218242 in xorg (main) "DG33BU - Intel GMA 3100 - graphics driver problems" [Undecided,New] https://launchpad.net/bugs/218242
<ubotu> New bug: #216630 in linux-restricted-modules-2.6.24 (restricted) "Ubuntu 8.04 x86_64 2.6.24-16-generic nvidia restricted kernel module fails to load" [Undecided,New] https://launchpad.net/bugs/216630
<pwnguin> wait
<pwnguin> did ubuntu pick up nouveau?
<pwnguin> ah, no, update manager just sucks at picking the right changelog to show =/
<ubotu> New bug: #218263 in xserver-xorg-input-keyboard (universe) "[Hardy] numlock and capslock leds don't light up on MacBook" [Undecided,New] https://launchpad.net/bugs/218263
<ubotu> New bug: #218345 in linux-restricted-modules-2.6.24 (restricted) "fglrx 8.4 released today. Any chance for hardy?" [Undecided,New] https://launchpad.net/bugs/218345
<james_w> bryce: hi, I'd like to ask you about the capplet font issue if you have a minute.
<bryce_> ok
<james_w> there were a few cairo calls that I dropped as I wasn't sure how to handle them given that upstream changed code in the same area
<james_w> it wasn't entirely clear what the aim of the calls were.
<bryce_> ok
<james_w> also, I noticed that when you forwarded the patches to gnomecc that someone pointed out that your description of the changed font size was the opposite to the change made in the patch
<james_w> i.e. you said it made it smaller, when it made it bigger
<bryce_> fwiw, I'm sitting directly behind Soeren here at the X conference.  
<james_w> oh really?
<bryce_> yeah that patch may be reversed
<james_w> I didn't realise you were at a conference, sorry.
<james_w> how is it?
<bryce_> pretty good, it just started today.  they went over X server status, and redhat talked about all the things they're doing, including mention of the xrandr gui
<james_w> cool
<james_w> I'm happy to spend some time on the issue tomorrow, I'd just like to know what the intent of the code was
<bryce_> soeren's as quiet in RL as he seems to be in email ;-)  but I'm hoping to chat with him a bit later
<james_w> heh
<james_w> I can drop the change that increases the font size, but I'm not sure what the cairo calls are trying to do.
<james_w> They appear to try to center the text, is this something that will show up with more than one monitor?
<bryce_> sure, so with the font patch, I'm surprised it even applies if it's reversed.  
<james_w> yeah, I'm not sure what happened there.
<bryce_> what I was doing to test it was to hack the code so I could override the display name, and type in something really long, "supercalifragilistic foobar 42\"" and see how that displays, then adjusted the font size down
<bryce_> with the text centering, I think our patch is no longer needed; iirc upstream also changed the text to center
<bryce_> in any case, I just installed the latest code and it looks fine
<james_w> ah, ok.
<james_w> -    layout_set_font (layout, "Sans Bold 12");
<bryce_> in fact, I'd had a much older version installed, and was showing someone, and it messed up my display, so I apt-get install libgnome-desktop-2'd, ran th egui again, and presto, eerything fixed up
<james_w> +    layout_set_font (layout, "Sans Bold 16");
<james_w> that's the current patch
<bryce_> let's just drop it
<james_w> excellent, that was the dpi fix I assume
<james_w> sure, I'll propose that to seb tomorrow. It's definitely post-RC material
<bryce_> no, that's just setting the font of the text inside the brown cairo layout box
<bryce_> yup
<james_w> I mean the dpi fix was what stopped it breaking your screen
<james_w> thanks for your help. Enjoy the rest of the conference.
<james_w> When are you back?
<seb128_> could also one of you figure if the clone option is supposed to be on by default when there is only one screen?
<james_w> hi seb128_ 
<james_w> I can look at it, I think the problem is in -desktop.
<seb128_> hey james_w
<bryce_> james_w: the conference runs three days, so I'll be back Monday
<bryce_> seb128, hah I noticed that too
<bryce_> ideally, it would be nice to gray out the clone checkbox if only one monitor is present
<bryce_> although if that's done in glade it might be tricky
<bryce_> james_w:  are you james_w@canonical.com?
<mario_limonciell> hey bryce you around?
<bryce_> yeah
<mario_limonciell> given that the AMD driver came out finally, any word on whether you are going to try to squeeze it into LRM post RC (particularly due to the fact that aticonfig for 8.04 is fixed)?
<mario_limonciell> that's the driver that we are certifying our AMD based systems on, so if not, we'll just be putting it in in the factory
<bryce_> right, there was a bug in on that earlier
<james_w> bryce: james.westby@
<james_w> I'm not sure what the alternate one is
<bryce_> james, ok thanks
<seb128> bryce_, james_w: should we also try to disable xrandr rotation on ati cards?
<seb128> those seem to just break xorg in a way which forces you to restart
<bryce_> mario_limonciell: if you've tested it, then I'd be open to pushing it in.  Timo has been doing the last few lrm updates, so I'd want to get his input first.
<bryce_> seb128: do you mean based on the chipset or the driver?
<mario_limonciell> bryce_, i've been testing earlier releases of it against our hardware (since that's what we are cert'ing on), but I can't speak for the general case on it
<seb128> bryce_: no real idea, I didn't try on enough card to know if that's an ati driver issue or specific to some cards
<bryce_> mario_limonciell: ah ok, well let's wait until tjaalton can give word on it.  I'm at an X conference at the moment (and only with -intel gfx) so am not in a position to easily package and test.
<bryce_> seb128: I think it may be a driver issue.  It fails on all ati hardware I've tested it on.
<bryce_> er wait, no it did work on kees' ati
<bryce_> so all but one
<seb128> kees has a special card apparently
<seb128> compiz and xrandr rotation working there ;-)
<tjaalton> bryce_: seems that it fixes some issues that are reported, so if the kernel guys / RM is ok with it, so am I
<bryce_> tjaalton: ok cool
<bryce_> tjaalton: are you in a position to do the upload?  
<bryce_> seb128: hang on, alex deucher is right next to me, let me ask
<tjaalton> bryce_: not before tomorrow, but it's probably post-RC anyway
<tjaalton> if ack'ed
<bryce_> seb128: ok alex says that rotation is expected to work and he's not aware of bug reports about it, but will take a look if we send it to him
<bryce_> tjaalton: right
<seb128> bryce_: ok, thanks
<bryce_> seb128: meanwhile yeah we should disable rotation.  unfortunately there's no way of detecting which driver is running
<bryce_> (I mean, aside from parsing Xorg.0.log, which I have a patch for, but you didn't like it...  *grin*)
<tjaalton> mario_limonciell: if you could persuade someone from the kernel team to ack the new fglrx, please :)
<seb128> bryce_: right ;-)
<mario_limonciell> tjaalton, we've got a call with rtg tomorrow morning.  I'll bring it up
<tjaalton> mario_limonciell: cool, thanks
<mario_limonciell> tjaalton, do you have a bug number for me to give rtg to reference the ack?
<kees> my ati chipset rules.  compiz works and xrandr doesn't crash.  ;)
<kees> I just need to go bug alex about the svideo port now
<mario_limonciell> kees, If I understand correctly, that is protected by some IP due to macrovision constraints
<bryce_> %#@ macrovision
<mario_limonciell> it costs an arm and a leg to certify systems for it too
<mario_limonciell> but yes, lots #$&* is directed in its general direction
<bryce_> :-)
<bryce_> mario_limonciell: track @ bug 218345
<mario_limonciell> great thanks. 
<kees> mario_limonciell: seriously?
#ubuntu-x 2008-04-17
<kees> mario_limonciell: svideo used to work pre-gutsy...
<mario_limonciell> kees, on that particular card?
<kees> mario_limonciell: yeah
<kees> I need to figure out the right place to report the issue.  I continue to be lazy...
<mario_limonciell> kees, well if it was implemented, that would have been due to reverse engineering and not due to docs released then :)
<mario_limonciell> i'd guess with the X.org bug tracker though?
<kees> mario_limonciell: hehe.  possible.  xrandr actually lists it as a port, but never sees anything "connect" to it.
<mario_limonciell> kees, how often do you "really" want to use svid though in the first place?  Once I went to DVI/VGA/HDMI, no looking back :)
<kees> mario_limonciell: right, it's not for myth at all -- it'd be for things like showing photos on a TV when traveling to family's houses
<mario_limonciell> ah yeah
<mario_limonciell> that'd make sense
<mario_limonciell> tell them to buy a new TV :)
<bryce_> ok got the low down on the compiz/ati issue from alex.  sounds pretty bad
<ubotu> New bug: #212526 in linux-restricted-modules-2.6.24 (restricted) "monitor/video garbage (out of sync) even in a console (ALT+F2)" [Undecided,New] https://launchpad.net/bugs/212526
<ubotu> New bug: #215664 in compiz (main) "Color of the windows shadow changes (dup-of: 186382)" [Undecided,New] https://launchpad.net/bugs/215664
<ubotu> New bug: #128299 in linux-restricted-modules-2.6.22 "avm fxusb_cz driver mod" [Undecided,New] https://launchpad.net/bugs/128299
<tjaalton> whoa, new sun-java6 fixed the assertion bug when using xcb
<james_w> seb128: hi, http://paste.ubuntu.com/7274/ <- that's the change I was discussing with bryce last night, would you accept it?
<james_w> obviously post-rc, so there's no rush if you are busy
<seb128> james_w: I'm not sure to understand what the patch as doing
<seb128> james_w: the version attached on bug #201589 is different
<ubotu> Launchpad bug 201589 in gnome-control-center "Screens Resolution tool shows text labels not centered, overlapping monitor area " [Low,Fix released] https://launchpad.net/bugs/201589
<seb128> I've no objection against dropping the change though
<james_w> yeah, this patch has had a few changes in it's history. There's two parts really, the change to the font size, and the cario stuff yo center it.
<james_w> upstream reduced the font size at some point to less than we were using, and when that was merged it wasn't noticed, and so we ended up increasing it, so we want to drop that part and just go with upstream
<james_w> the cairo stuff was commented by me, as upstream changed things in that area, and it meant that the text wasn't visible with those calls.
<seb128> makes sense
<seb128> let's go back with what upstream is doing
<james_w> bryce said that the latest version looks ok even with those lines commented, so I guess upstream solved it a different way.
<seb128> ok, cool
<seb128> let's do that
<james_w> great, thanks.
<james_w> I'm going to try and look at the clone issue today, and I also want to to work on the evolution/n-m bug if that is still open.
<seb128> thank you for working on the changes ;-)
<seb128> ok
<seb128> upstream were discussing the nm issue
<seb128> you might want to join their chan on gimpnet to discuss the bug, that's usually makes thing easier than having to figure what to change etc
<james_w> I'll have a look, last time I looked the proposed patch wasn't satisfactory.
<james_w> ah, thanks for the tip.
<james_w> the code is pretty strange, I have a hunch that the meaning of the flags has actually reversed over time.
<ubotu> New bug: #218592 in linux-restricted-modules-2.6.22 "acx hangs network" [Undecided,New] https://launchpad.net/bugs/218592
<james_w> this clone checkbox is pretty strange.
<james_w> seb128: I've got a patch, but my screen is messed up now from testing, I'll be back shortly with it
<james_w> seb128: http://paste.ubuntu.com/7282/
<james_w> so it turns on clone mode if there is a pair of screens at 0,0 with the same width and height. I think that was the original intent of the code.
<seb128> james_w: ok, good
<james_w> I realised I can plug my desktop monitor in to my laptop, and so it's had some testing in dual screen as well.
<seb128> ;-)
<seb128> I should try that too, I only tested on configurations where there is one monitor so far
<seb128> but plugging my desktop monitor on the laptop should be easy enough ;-)
<james_w> yeah, unfortunately I can only get 640x480 in clone mode, and coming back out of it messes up my laptop screen.
<seb128> what video driver?
<james_w> intel
<james_w> I managed to fix it up the first time with some xrandr calls, but not the second time.
<ubotu> New bug: #218671 in xserver-xorg-input-elographics (universe) "MinY < MaxY leads to unexpected behaviour" [Undecided,New] https://launchpad.net/bugs/218671
<ubotu> New bug: #218736 in xorg (main) "[Hardy] xine/mplayer/vlc/gstreamer output video in wrong colourspace" [Undecided,New] https://launchpad.net/bugs/218736
<mario_limonciell> tjaalton, bryce rtg said that he's fine so long as slangasek is 
<mario_limonciell> (and bryce is, which was already determined)
<mario_limonciell> er i guess that was directed at a ghost :)
<mario_limonciell> <mario_limonciell> tjaalton, bryce rtg said that he's fine so long as slangasek is 
<mario_limonciell> <mario_limonciell> (and bryce is, which was already determined)
<federico1> bryce: pingety ping :)
<federico1> bryce_: ping
<bryce_> heya
<federico1> bryce_: hey!
<federico1> how's the married man?
<bryce_> hehe
<bryce_> he's wishing for more than continental breakfasts at the moment ;-)
<bryce_> federico1: I am noticing soeren is as quiet in person as he is in email ;-)
<federico1> oh, you are in xdevconf?
<federico1> yeah, he is - quiet freak genius, you know the type
<federico1> bryce_: I wanted to ask you guys...
<federico1> bryce_: "Detect displays" does nothing.  I'm tracing it, and randrwrap.c:fill_out_screen_info() calls XRRGetScreenResources().  That one gives only one output and crtc.  Is my xorg.conf fucked, or does my driver (radeon) not support hotplug, or do you have an idea of what's going on? :)
<federico1> I'm about to build xorg-driver-video with debug info to see what's up
<jcristau> federico1: could you pastebin the output of 'xrandr -q'?
<federico1> cacharro$ xrandr -q
<federico1> Screen 0: minimum 640 x 350, current 1400 x 1050, maximum 1400 x 1050
<federico1> default connected 1400x1050+0+0 0mm x 0mm
<federico1>    1400x1050      50.0* 
<federico1> (and a bunch of other resolutions)
<bryce_> -radeon and -radeonhd support xrandr 1.2, so should work
<jcristau> federico1: yeah that's randr 1.1
<bryce_> federico1: what version of driver and x server are you running?
 * federico1 raises an eyebrow
<federico1> cacharro$ rpm -q xorg-x11-driver-video
<federico1> xorg-x11-driver-video-7.3-99
<federico1> hmm, how can I get the actual driver version?  from thelog file?
<bryce_> yep
<bryce_> your Xorg.0.log should indicate it in the first three lines after loading it
<jcristau> i'm guessing 6.3
<federico1> (II) LoadModule: "radeon"
<federico1> (II) Loading /usr/lib/xorg/modules//drivers/radeon_drv.so
<federico1> (II) Module radeon: vendor="X.Org Foundation"
<federico1>         compiled for 1.4.0.90, module version = 4.2.0
<federico1>         Module class: X.Org Video Driver
<federico1>         ABI class: X.Org Video Driver, version 2.0
<federico1> (II) LoadModule: "ati"
<federico1> (II) Loading /usr/lib/xorg/modules//drivers/ati_drv.so
<federico1> (II) Module ati: vendor="X.Org Foundation"
<federico1>         compiled for 1.4.0.90, module version = 6.6.3
<federico1>         Module class: X.Org Video Driver
<federico1>         ABI class: X.Org Video Driver, version 2.0
<federico1> aha!
<federico1> so that 6.6.3 is biting my ass?
<jcristau> yup
<jcristau> you need 6.8 (iirc) for randr 1.2
<federico1> jcristau: ok,thanks
<federico1> for some reason we have a bunch of -ati release tarballs in our srpm
<federico1> both 6.6.3 and 6.8.0
<federico1> let me untangle this and I'll let you know
<federico1> jcristau: are you also working on the gnome-display-properties stuff?
<bryce_> federico1: yep, some distros have stuck with 6.6.3 for stability.  I guess when xrandr got added, there came to be a lot of instabilities.
<federico1> interesting
<federico1> ok, I'll poke our X people
<bryce_> federico1: jcristau isn't working on the gui
<federico1> bryce_: ok 
<federico1> bryce_: please do tell me where to pull from if you or soeren have some git love :)
<bryce_> federico1: sure
<bryce_> federico1: I suspect we're both too distracted by the conference to do much hacking on it this week though
<tjaalton> mario_limonciell: ok thanks, so I should('ve) push(ed) it to my ppa for people to test
<mario_limonciell> tjaalton, what's your PPA link?  I'll give it a run
<federico1> bryce_: ok - have fun :)
<federico1> bryce_: change that continental breakfast; it gets old fast
<bryce_> hehe
<bryce_> federico1: are you receiving responses from soeren?  I haven't seen any emails from him in about a month
<federico1> bryce_: I got hist last reply about a week ago
<tjaalton> mario_limonciell: it's not there yet :)
<federico1> bryce_: please ping me if you get together to chat over irc :)
<mario_limonciell> tjaalton, oh, read your statement wrong.  Let me know when it is
<bryce_> federico1: certainly
<tjaalton> mario_limonciell: sure. it takes awhile to build the tarball etc. but it's pretty straightforward. I'll finish it after Lost :)
<bryce_> tjaalton: status is looking pretty good now - http://people.ubuntu.com/~bryce/Xorg/status_20080417.html
<bryce_> [the -ati numbers are wrong on that link]
<tjaalton> hehe :)
<bryce_> bug 204603 is the last milestoned X bug (well, also 198759)
<ubotu> Launchpad bug 204603 in xserver-xorg-video-intel "occasional hard crash on vt switch" [Medium,In progress] https://launchpad.net/bugs/204603
<tjaalton> hmm, xserver-xgl is not on the team package list
<tjaalton> not that I'd worry too much about it :)
<bryce_> me either
<bryce_> compare http://people.ubuntu.com/~bryce/Xorg/status_20080410.html and http://people.ubuntu.com/~bryce/Xorg/status_20080417.html, there's been nice progress this past week
<tjaalton> bug 218785 is strange, I had the same problem yesterday
<ubotu> Launchpad bug 218785 in xorg "have to reinstall nvidia drivers on every reboot" [Undecided,New] https://launchpad.net/bugs/218785
<tjaalton> although a reinstall is not necessary, 'jockey-gtk --enable kmod:nvidia_new' is enough
<tjaalton> must be something in lrm
<bryce_> yeah I was messing with -nvidia and -nv a couple days ago and pulling my hair out
<bryce_> although that wasn't latest hardy, so figured it wasn't worth a lot of troubleshooting time
<ubotu> New bug: #218334 in xorg (main) "black screen of death" [Undecided,Incomplete] https://launchpad.net/bugs/218334
<james_w> hi bryce 
<james_w> hi federico1 
<james_w> federico1: you might well want http://paste.ubuntu.com/7310/ as well
<federico1> james_w: give me a description for "git commit -m" and I'll put it in
<james_w>   * Invert the logic in the detection of clone mode so that it works for a
<james_w>     single screen as well. Without this change single screens are always
<james_w>     reported as clone, which makes no sense.
<james_w> that was my changelog entry
<federico1> james_w: ah, nice, thanks
 * federico1 commits
<federico1> yeah, I was wondering why that was turned on :)
<james_w> do you think the clone checkbox should be insensitive if there is only one screen?
<federico1> james_w: pushed!
<james_w> thanks
<federico1> james_w: yeah... can we do tooltips on insensitive widgets now?  if so, add a tooltip to say "cloning a display needs more than one monitor" or something :)
<federico1> james_w: if you have a git repo somewhere, please ping me so that I can pull the love from you
 * federico1 is a total git-remote whore these days
<james_w> I'm not sure about that. I'm sure you know more about gtk+ than me :-)
<federico1> james_w: let me check quickly
<james_w> heh, I don't have a git repo I'm afraid. We haven't really got the whole VCS <-> source package thing worked out yet.
<james_w> I've got to cook now, sorry.
<federico1> james_w: yes, you can!  gtk_widget_set_tooltip_text() works fine for insensitive widgets
<federico1> james_w: I have a super-quick script to build me an rpm from my git repo
<federico1> james_w: let me mail it to you
<james_w> I'd like to see it
<federico1> james_w: mailed
<federico1> you'll need to s/rpmbuild/apt-whatever, I assume :)
<federico1> james_w: cook in peace - it's therapeutic
<federico1> don't forget the PEPPER
<federico1> lots of it
<bryce_> heya james_w
<federico1> w00t
 * federico1 gets hotplug goodness
<federico1> time to restart X
<federico1> bryce_: woot, I changed to the ati 6.8.0 and I have some hotplug goodness :)
<federico1> bryce_: but side-by-side doesn't work; I think it's the virtual size thing.  What do I need in my xorg.conf, if anything?
<bryce_> federico1: you need something like this in your Screen section
<bryce_> 	SubSection "Display"
<bryce_> 		Depth		24
<bryce_> 		Modes		"1280x1024" "1024x768" "800x600" "640x480"
<bryce_> #		Virtual		2560 2560
<bryce_>                 Virtual         3840 1200
<bryce_> 	EndSubSection
<bryce_> note that if you go above 2048x2048, composited desktop won't work 
<federico1> excellent
<federico1> bryce_: thanks :)
<bryce_> no prob
<federico1> time to restart X again
<bryce_> oh btw, that's yet another thing that would be nice to fix - we don't have any mechanism for modding the Virtual line in xorg.conf, and I suspect many users will be wishing for that
<bryce_> however, I guess until we have left-of/right-of implemented in the GUI it's a moot point.
<federico1> bryce_: huh?  I can already drag-and-drop the monitors in gnome-display-properties
<federico1> bryce_: and they snap to the corners and everything
<bryce_> oh?  I'd tried that but it didn't seem to do anything so I assumed it wasn't done yet.  Cool.
<bryce_> so then that makes the Virtual thing high priority
<federico1> bryce_: well, I could drag them, but reconfiguration didn't work.  I assumed it was the Virtual thing... let me restart and I'll tell you :)
<tjaalton> mario_limonciell: I'll have to postpone the new fglrx to next day, but will get to it early in the morning
<mario_limonciell> okay 
<ubotu> New bug: #212367 in linux-restricted-modules-2.6.24 (restricted) "glxinfo crashed with SIGILL" [Undecided,New] https://launchpad.net/bugs/212367
<ubotu> New bug: #210458 in linux-restricted-modules-2.6.24 (restricted) "nVidia GLX-driver breaks console" [Undecided,Incomplete] https://launchpad.net/bugs/210458
<ubotu> New bug: #212496 in compiz (main) "compiz.real crashed with SIGSEGV in _nv000069gl() (dup-of: 190232)" [Undecided,Invalid] https://launchpad.net/bugs/212496
<ubotu> New bug: #214452 in linux-restricted-modules-2.6.24 (restricted) "glxinfo crashed with SIGSEGV in _nv000092gl()" [Undecided,New] https://launchpad.net/bugs/214452
<ubotu> New bug: #211555 in linux-restricted-modules-2.6.24 (restricted) "glxinfo crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/211555
<ubotu> New bug: #211725 in linux-restricted-modules-2.6.24 (restricted) "glxinfo crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/211725
<ubotu> New bug: #198451 in linux-restricted-modules-2.6.24 (restricted) "glxinfo crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/198451
<ubotu> New bug: #214167 in linux-restricted-modules-2.6.24 (restricted) "glxgears crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/214167
<ubotu> New bug: #185785 in mesa (main) "glxinfo crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/185785
<ubotu> New bug: #213342 in linux-restricted-modules-2.6.24 (restricted) "Firefox seems to lock up glxinfo whenever I go to 'My Yahoo Mail"" [Undecided,New] https://launchpad.net/bugs/213342
<ubotu> New bug: #216514 in mesa (main) "glxinfo crashed with SIGSEGV in _XSend() (dup-of: 194249)" [Undecided,New] https://launchpad.net/bugs/216514
<ubotu> New bug: #216970 in linux-restricted-modules-2.6.24 (restricted) "glxinfo crashed with SIGSEGV Nvidia Vanta 16MB" [Undecided,New] https://launchpad.net/bugs/216970
<ubotu> New bug: #211590 in mesa (main) "glxgears crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/211590
<ubotu> New bug: #214846 in linux-restricted-modules-2.6.24 (restricted) "aticonfig crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/214846
#ubuntu-x 2008-04-18
<bryce_> heya
<bryce_> hi soren
<bryce_> heya james
<bryce_> james_w: after dinner tonight I caught up with soeren and started peppering him with xrandr gui questions
<bryce_> james_w: he answered them sort of non-committally and then edged away from me very quickly!  :-P
<ubotu> New bug: #219069 in xorg (main) "FUJITSU SIEMENS Lifebook: VGA out cannot enabled (Hardy)" [Undecided,New] https://launchpad.net/bugs/219069
<seb128> hey james_w
<james_w> hi seb128 
<seb128> james_w: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/219014, have you seen similar issues during your testing? does the change drop you suggested will fix this one?
<ubotu> Launchpad bug 219014 in gnome-control-center "screen resolution pictures are connected" [Undecided,New] 
<james_w> I'm not really sure what the problem is in the first part, do you know?
<james_w> "The two images don't look correct touching like in the picture attached."
<james_w> what does he mean by "not correct?"
<seb128> look at the screenshot
<james_w> the 19" is smaller than the 15"?
<seb128> I think the complain is that the rectangle are touching
<seb128> where he expects some space between the drawings
<seb128> I've to agree it doesn't look really good this way
<seb128> there is lot of empty space
<seb128> so the monitors could use some rather than conflicting in the same corner
<james_w> I was under the impression that they were supposed to be touching.
<seb128> ah, maybe
<james_w> I suppose they don't have to be, but I though the aim was the screen would span the two monitors.
<seb128> the screenshot looks weird to be honest
<james_w> yeah, it's not great
<james_w> the second part of his problem should probably be filed as a separate bug against the driver by the sounds of it.
<seb128> james_w: not sure, is there anything detecting the screens plugged and doing dynamic change?
<seb128> it should run xrand --auto which is mapped to the screen switching key
<james_w> I don't think there is anything that detects it.
<james_w> hitting the "Detect displays" button and then applying may fix it up.
<seb128> ok, so that's not a driver bug, he just needs to press the key
<james_w> I guess it's a wishlist bug to have hotplug support wherever it needs to go for this.
<seb128> right
<mvo> is it known that xorg sometimes uses vesa instead of nv? I have a fresh altnernative install and get vesa on a nvidia 7600
<tjaalton> mvo: what's the pci-id of the card?
 * mvo checks
<tjaalton> basically all the id's that the nv source lists should load nv
<mvo> 10de:00f1
<mvo> (its a 6600, sorry)
<tjaalton> hmm, not in nv.ids
<tjaalton> I'll check teh source
<tjaalton> the
<tjaalton> nope, not listed.. try forcing it on the xorg.conf
<tjaalton> oh right.. I guess it wont load
<tjaalton> since the driver should refuse to load if the id is not listed there
<mvo> oh
<tjaalton> so, either it's a mistake or left out intentionally
<mvo> ok, thanks
<mvo> should I file a bug?
<tjaalton> you could build the driver with the id added in nv_driver.c
<tjaalton> yes
<tjaalton> static SymTabRec NVKnownChipsets[]
<mvo> LP or upstream bugtracker?
<tjaalton> why not both :)
<mvo> because I'm lazy :P
<tjaalton> let me check the nv bugs first
<tjaalton> hehe
<tjaalton> see bug 207428
<ubotu> Launchpad bug 207428 in xserver-xorg-video-nv "GF 7050 not supported" [Low,Confirmed] https://launchpad.net/bugs/207428
<tjaalton> a similar case
<tjaalton> mvo: file on LP for now
<mvo> I filed #219101
<mvo> is it worth just adding the pci id to see what happens?
<tjaalton> mvo: yes, add it like the rest and compile
<mvo> ok
<ubotu> New bug: #210526 in linux-source-2.6.22 "The touchpad freezes everytime I restore system from standby (dup-of: 59867)" [Undecided,Incomplete] https://launchpad.net/bugs/210526
<ubotu> New bug: #219101 in xserver-xorg-video-nv (main) "nvidia 6600 not supported" [Undecided,New] https://launchpad.net/bugs/219101
<ubotu> New bug: #209477 in linux-restricted-modules-2.6.24 (restricted) "trigger crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/209477
<mvo> look fine
<mvo> looks fine when adding the pci id
<tjaalton> oh, nice
<tjaalton> new lrm (fglrx 8.4) uploaded to my PPA (https://edge.launchpad.net/~tjaalton/+archive)
<tjaalton> mvo: could you attach the Xorg.0.log from the patched nv to the bug. I'll forward it upstream
<mvo> tjaalton: added, thanks!
<ubotu> New bug: #219232 in linux-restricted-modules-2.6.24 (restricted) "KDE4 hangs (black screen) on logout with fglrx driver" [Undecided,New] https://launchpad.net/bugs/219232
<ubotu> New bug: #216279 in tasks "Translation template is not being generated (dup-of: 188690)" [Undecided,New] https://launchpad.net/bugs/216279
<ubotu> New bug: #218489 in xorg (main) "X freeze when switching between OpenOffice and Firefox" [Undecided,New] https://launchpad.net/bugs/218489
<ubotu> New bug: #219285 in xorg (main) "Hardy Heron: screen turns off, Xorg 100%" [Undecided,New] https://launchpad.net/bugs/219285
<ubotu> New bug: #66478 in flashplugin-nonfree (multiverse) "Crash when viewing flash sites (dup-of: 14911)" [Undecided,New] https://launchpad.net/bugs/66478
<ubotu> New bug: #63257 in flashplugin-nonfree (multiverse) "Firefox, shutdowns automatically when using a flash player...  (dup-of: 14911)" [Undecided,New] https://launchpad.net/bugs/63257
<ubotu> New bug: #67806 in firefox (universe) "Firefox crash on gmail (dup-of: 14911)" [Undecided,Confirmed] https://launchpad.net/bugs/67806
<ubotu> New bug: #67242 in flashplugin-nonfree (multiverse) "firefox crashes on flash content (dup-of: 14911)" [Undecided,New] https://launchpad.net/bugs/67242
<ubotu> New bug: #219294 in xterm (main) "xterm segfaults if more than 9999 scroll lines" [Undecided,New] https://launchpad.net/bugs/219294
<ubotu> New bug: #219321 in xorg-server (main) "package xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.3 [modified: usr/lib/xorg/modules/extensions/libglx.so] failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/219321
<tjaalton> mvo: that ^^ bug is strange, because it happens during upgrade from gutsy to hardy, but the version that fails is from gutsy. so the upgrade process updates x-x-c twice and fails (obviously because of diversions..). theres a dupe somewhere too
<inkscape_bryce> heya tjaalton
<tjaalton> bryyce: howdy, how's XDC today?
<tjaalton> no fglrx-8.4 for 8.04 btw, but maybe for .1
<tjaalton> (or whatever the version might be at the time)
<bryyce> ok
<bryyce> XDC going pretty well.  So far today was Tinderbox for X, XCB, and now Wine & X
<bryyce> I'm going to try to show/share some of my earlier Crucible/X test framework stuff with Chris Bell
<tjaalton> ok cool
<tjaalton> ask someone if TTM is going to make it in 2.6.26 :)
<tjaalton> I guess it's the one Intrepid will use
<tjaalton> k, dinner & some random movie, bbl ->
<mvo> tjaalton: hm, maintainer scripts are meant to be idempotent - still, strange problem
<mvo> tjaalton: I asked him for the upgrade logs, that should give us a apt/dpkg terminal log
<bryyce> tjaalton: keithp says TTM will go in "after I rewrite it"
<bryyce> tjaalton: which he thinks will be about 1 month
<bryyce> tjaalton: what was the issue with getting fglrx 8.4 in?  just too late in the cycle, or were there bugs?
<mvo> it seems like 855 give problem with video playback under compiz, do we know anything about this? or do we have hardware to confirm this?
<seb128> mvo: my old laptop has an intel 855 card I think, I can try things tomorrow if you want, what is the issue?
<bryyce> mvo, I've not been aware of further issues with 855, but jesse said there's probably more.
<mvo> someone reported that video playback is broken with compiz for them, and I only have a 830 system for testing
<mvo> seb128: yeah, that would be cool, just check if totem video playback works
<seb128> mvo: ok, I will do that tomorrow after upgrading
<mvo> thanks
<tjaalton> bryyce: too late..
<bryyce> tjaalton: ah ok
<tjaalton> mvo: bug 217867 is a dupe
<ubotu> Launchpad bug 217867 in xorg-server "package xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.3 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/217867
<tjaalton> bryyce: ah, so there's hope for TTM after all :)
<bryyce> tjaalton: keithp didn't elaborate but his tone had a disgruntled aspect to it that made me think there's a story behind it
<tjaalton> it would also mean that .27 is a more probable target for TTM
 * bryyce nods
<ubotu> New bug: #215465 in xscreensaver (main) "[fglrx amd64] queens crashed with SIGSEGV (dup-of: 181121)" [Medium,Incomplete] https://launchpad.net/bugs/215465
<bryyce> keithp didn't commit to a particular kernel version
<ubotu> New bug: #214255 in xscreensaver (main) "[nvidia] glmatrix crashed with SIGSEGV (dup-of: 110125)" [Medium,Incomplete] https://launchpad.net/bugs/214255
<ubotu> New bug: #218018 in xscreensaver (main) "[nvidia] The queens screensaver crashed in preview mode (dup-of: 110125)" [Undecided,Incomplete] https://launchpad.net/bugs/218018
<tjaalton> I wonder if we could pull the latest stable drm to .26 when .27 is released
<tjaalton> speculation..
<munckfish> Hi all
<munckfish> I've just managed to upgrade my PS3 gutsy install to Hardy
<munckfish> and I'm about to start trying to get the backtrace stuff
<munckfish> for the crash I was experience
<munckfish> I want to 
<munckfish> generate a pristine xorg.conf using the newly installed dexconf
<munckfish> what do I have to do to ensure what's generated is exactly as would be generated by the live CD on boot?
<munckfish> is it safe to just run dexconf? Or do I need to 
<tjaalton> munckfish: ok, just run 'dpkg-reconfigure -phigh xserver-xorg'
<munckfish> clean out the debconf db somehow?
<tjaalton> dexconf should work too
<tjaalton> there's not much to clean
<munckfish> so just accepting the defaults in dpkg-reconfigure will do it?
<munckfish> ok
<tjaalton> should be fine
<tjaalton> -phigh doesn't ask any questions IIRC
<munckfish> ok thx
<munckfish> btw, I can at least get X to run now using my gutsy xorg.conf
<munckfish> and I didn't notice the invalid pointer problem yet
<munckfish> but I'll see how it goes
<tjaalton> ok
<munckfish> I did have X spontaneously restart though
<munckfish> only evidence I could find was in .xsession-errors
<munckfish> I'll raise something in LP later
<munckfish> tjaalton: does dexconf rely on there being at least a bare bones xorg.conf?
<tjaalton> nope
<munckfish> I just ran it, and it's failed
<tjaalton> use -o
<tjaalton> -o foo
<tjaalton> mv foo /etc/X11/xorg.con
<tjaalton> f
<munckfish> xorg.conf no such file .......
<munckfish> then FATAL: Module battery not found.
<tjaalton> dexconf -o foo works
<tjaalton> at least here
<ubotu> New bug: #219377 in xorg (main) "Can't install Ubuntu using the liveCD because the radeonhd driver is not on the cd" [Undecided,New] https://launchpad.net/bugs/219377
<bryyce> tjaalton: for r500/r600 what driver do we pick on the cd?  fglrx?
<tjaalton> bryyce: ati
<tjaalton> fglrx is not on the cd, neither is nvidia*
<bryyce> ok
<bryyce> tjaalton: btw alex just gave me a bunch of patches he says we should really have for 6.8 (all breakages discovered right after the release)
<tjaalton> bryyce: excellent..
<tjaalton> bryyce: although I'd prefer a new release if there were such issues..
<tjaalton> didn't ajax point out that "releases are cheap" :)
<bryyce> yeah but the current git tree is full of a lot of feature work he says is really not stable enough for us yet
<bryyce> so he's cherrypicked these patches for us.
<bryyce> (I agree, a point release would have been nice)
<tjaalton> yeah, point-releases are cheap..
<munckfish> Hi again guys, I've uploaded the backtrace now to LP 217647
<munckfish> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/217647
<munckfish> has anyone got a moment to help analyse it a little?
<bryyce> tjaalton: http://paste.ubuntu.com/7445/
<munckfish> Sort of as I expected the invalid pointer is the 'idsdir' handle
<munckfish> idsdir = (DIR *) 0x101f0000
<bryyce> munckfish: mmm
<munckfish> so simple stuff out the way first the directory it's trying to access /usr/share/xserver-xorg/pci/ does exist
<bryyce> good backtrace...  looking at src
<munckfish> ok cool
<munckfish> would a strace help any?
<munckfish> or ltrace
<munckfish> ?
<bryyce> hmm, probably not
<bryyce> you could step through the function in gdb... that's probably what I'd do next
<bryyce> set a break on chooseVideoDriver, then step through and see how the pointers are getting used
<munckfish> can I do that without the source?
<tjaalton> bryyce: a nice bunch of patches
<munckfish> I mean just with the debug syms?
<bryyce> munckfish: actually even that's not really necessary...  seems like it's narrowed down sufficiently
<munckfish> I'm guessing not
<bryyce> munckfish: one sec
<munckfish> bryce: nae problem
<munckfish> wow, there's two of you! are you both the same person?
<tjaalton> multibryce!
<tjaalton> we need'em both ;)
<munckfish> bry[y]?ce
<munckfish> well, I guess two's more powerful that one!
<munckfish> bryce cloning
<bryyce> try this patch:  http://bryceharrington.org/files/closedir.patch
<bryyce> munckfish: yuup :-)
<munckfish> k bryyce I'll rebuild and be back to report
<bryyce> tjaalton: should we roll those into a package for testing?  Or...  it would be nice to tie the patches to specific bugs.  I may spend some time tonight to try to link them to bug reports.
<tjaalton> bryyce: both, yes
<tjaalton> at least if it should get in before release, I doubt it will
<bryyce> yeah not unless we could tie the patches to extremely bad bugs
<tjaalton> right
<bryyce> but shooting for sru's or 8.04.1 might be more realistic
<tjaalton> night folks ->
<bryyce> night
<munckfish> so ... bryyce what's the real reason for your clone?
<bryyce> munckfish: 'bryce' is my login at home, 'bryyce' is my laptop here at the X dev conference
<munckfish> oh i c
<munckfish> you're at the X conf cool
#ubuntu-x 2008-04-19
<munckfish> mmm X conf 08 in sunny california, a world away from still not quite convincingly spring here in Edinburgh, lucky you
<bryyce> it's quite nice, I'm in shorts
<bryyce> apparently it's going to be snowing next week back home (portland oregon)
<bryyce> munckfish: so what do you work on?
<munckfish> bryyce: you mean for ubuntu or generally?
<bryyce> both
<munckfish> well, by day I'm a software eng / team lead for a smallish elearning/gaming software company here in Scotland
<bryyce> cool
<munckfish> by night (and by breakfast time) I'm applying love and care to PS3+Hardy
<munckfish> and just generally trying to find a useful niche in the ubuntu 
<munckfish> volunteer world
<munckfish> what about you are you full time Canonical?
<bryyce> yep, pretty much
<bryyce> in theory I also do Inkscape in my freetime, however I find myself more often just working extra hours on Xorg instead
<munckfish> bryyce: right, somehow I'm not surprised
<munckfish> were you at DebConf 07 ?
<bryyce> nope
<munckfish> I remember sitting in on various stuff, saw some of the debian X maintainers there of course
<munckfish> really inspired to get involved actually
<bryyce> cool
<munckfish> and it was here in Edinburgh so I didn't have to move very far
<munckfish> :)
<munckfish> blimey xserver build takes quite a while - I'm sure this is longer than the kernel build time now. Is it possible to use ccache when building the xserver deb?
<bryyce> sure
<bryyce> I think also it's set up by default to use -j0; I've been wanting to figure out how to make it use more cpu's (I have a 4 cpu system that goes woefully underutilized)
<bryyce> bbiab
<mvo> munckfish: anything new about the ps3 kernel ?
<munckfish> mvo: umm I cheated a bit
<munckfish> I didn't use the update manager in the end
<munckfish> sorry
<munckfish> :S
<munckfish> first I installed linux-powerpc64-smp
<munckfish> then upgraded using the instructions on https://help.ubuntu.com/community/FeistyUpgradesManual
<munckfish> but converted for hardy
<munckfish> so I now have a functioning hardy base
<munckfish> and the kernel thing is fine
<munckfish> so, I'll need to revisit gutsy at some point to try out the upgrade
<munckfish> then I can tell you if there are any problems
<munckfish> mvo: what solution can we use to solve the upgrade path problem? meta package? or something specific in the UpdateManager?
<mvo> munckfish: a transitional package or a quirks rule in update-manager, both will work
<mvo> the later is easier
<mvo> for former more generic :)
<munckfish> uhu
<munckfish> so ... which would you recommend?
<munckfish> taking into account that we've probably not got a chance 
<munckfish> to get hardy done for PS3 for it's initial release
<mvo> a quirks rule in update-anager sounds fine
<munckfish> excellent
<mvo> I just need the name of the old and the new kernel package
<munckfish> ok
<munckfish> I tell you what
<munckfish> ...
<munckfish> I'm a little unsure of this
<munckfish> Let me check this out a bit more thoroughly
<mvo> munckfish: ok, no rush, just catch me within the next few days
<mvo> munckfish: I need to go to bed now anyway
 * mvo waves
<munckfish> If I raise something in LP on it you'll see it right?
<munckfish> bryyce: that patch fixed it
<bryyce> excellent
<munckfish> Now moving on to the wrong driver problem (vesa -> fbdev)
<munckfish> bryyce: thx for that!
<bryyce> :-)
<munckfish> bryyce: ok my passing shot for tonight. I've uploaded a gdb session stepping through the chooseVideoDrver function
<munckfish> https://bugs.launchpad.net/ubuntu-ps3-port/+bug/219424
<munckfish> there's a lot of null pointers in it, and not much real action
<munckfish> if you have a chance to review it
<munckfish> and you need more or different traces let me know I'll get whatever we need.
<munckfish> enjoy the conference
<bryyce> ok cool
<bryyce> conference has ended, I'm chillin' tonight and will be heading home tomorrow morning
<munckfish> ok well safe journey, maybe speak over the weekend not sure. C ya!
<bryyce> sure!
<ubotu> New bug: #219487 in xserver-xorg-input-synaptics "Typing blocks external mouse" [Undecided,New] https://launchpad.net/bugs/219487
<ubotu> New bug: #219424 in ubuntu-ps3-port "xorg-server wrongly tries to load 'vesa' driver instead of 'fbdev' on PS3" [High,In progress] https://launchpad.net/bugs/219424
<ubotu> New bug: #219353 in linux-restricted-modules-2.6.24 (main) "compiz corruption upon resume" [Undecided,New] https://launchpad.net/bugs/219353
<ubotu> New bug: #219391 in xserver-xorg-video-ati (main) "xv doesn't work on ATI ES1000" [Undecided,New] https://launchpad.net/bugs/219391
<ubotu> New bug: #219350 in xorg (main) "wrong refresh rates shown" [Undecided,New] https://launchpad.net/bugs/219350
<ubotu> New bug: #219468 in xorg (main) "[Hardy] Synaptics touchpad disabled by default after upgrade" [Undecided,New] https://launchpad.net/bugs/219468
<ubotu> New bug: #219548 in xorg (main) "Xorg constant 70% CPU load" [Undecided,New] https://launchpad.net/bugs/219548
<ubotu> New bug: #214379 in linux-restricted-modules-2.6.24 (restricted) "compiz.real crashed with SIGILL" [Medium,Won't fix] https://launchpad.net/bugs/214379
<ubotu> New bug: #219620 in linux-restricted-modules-2.6.24 (restricted) "AVM WLAN USB adapter causes ernel crash (dup-of: 200589)" [Undecided,New] https://launchpad.net/bugs/219620
<ubotu> New bug: #219624 in linux-restricted-modules-2.6.24 (restricted) "nvidia driver (nvidia-glx or nvidia proprietary) crash the system" [Undecided,New] https://launchpad.net/bugs/219624
<komputes> is anyone in the office?
<Q-FUNK> :)
<Q-FUNK> I'm home
<ubotu> New bug: #219630 in xorg-server (main) "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,New] https://launchpad.net/bugs/219630
<ubotu> New bug: #219639 in xorg (main) "[Hardy] the new X server with no xorg.conf does not work with nvidia restricted drivers" [Undecided,New] https://launchpad.net/bugs/219639
<ubotu> New bug: #219569 in xserver-xorg-input-synaptics "Touchpad ultra sensitive on kde (3.5.9 and 4) initialization (Hardy Heron)" [Undecided,New] https://launchpad.net/bugs/219569
#ubuntu-x 2008-04-20
<bryce> heya
<Q-FUNK> hey
<Q-FUNK> hm. repeat if necessary.
<ubotu> New bug: #133876 in xorg (main) "english keyboard layout unavailable on LiveCD, when russian language has been chosen during bootup" [Undecided,Confirmed] https://launchpad.net/bugs/133876
<ubotu> New bug: #219795 in linux-restricted-modules-2.6.24 (restricted) "After install nvidia restricted driver, resolution becomes too high" [Undecided,New] https://launchpad.net/bugs/219795
<ubotu> New bug: #219831 in xserver-xorg-video-intel (main) "Crash when displaying three 3MB bitmaps, cannot Cntl-Alt-Backspace out of it" [Undecided,New] https://launchpad.net/bugs/219831
<ubotu> New bug: #219846 in xserver-xorg-video-intel (main) "xv video freezes computer if display is rotated" [Undecided,New] https://launchpad.net/bugs/219846
<ubotu> New bug: #219983 in linux-restricted-modules-2.6.24 (restricted) "ath_pci not loading at boot time" [Undecided,New] https://launchpad.net/bugs/219983
<ubotu> New bug: #219985 in xserver-xorg-video-radeonhd (universe) "Put radeonhd 1.2 into hardy" [Undecided,New] https://launchpad.net/bugs/219985
<tormod> hi, any chance we can get radeonhd 1.2.0 into Hardy (universe)? Bug #219985
<ubotu> Launchpad bug 219985 in xserver-xorg-video-radeonhd "Please sync xserver-xorg-video-radeonhd 1.2.0-1 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/219985
<ubotu> New bug: #219995 in xorg (main) "Different color depth on different virtual screens   " [Undecided,New] https://launchpad.net/bugs/219995
<jcristau> a few days before release, i'd say 'of course not', but then i have no idea how that works
<tjaalton> I'm thinking the same, doubt that slangasek would approve it
<tormod> generally it's "of course not", but there are many exceptions.
<tjaalton> but as a SRU it might be ok
<tjaalton> should even
<tormod> yes, SRU should be fine. But we have to wait for it to "mature" in Intrepid first then, right?
<tjaalton> not sure..
<tjaalton> maybe that's the current policy, but should be changed imo
<tjaalton> at least when the package has been "matured" in debian
<Q-FUNK> hm
<Q-FUNK> here, I'm getting more and more puzzled as to why -geode works on its own in a snatdalone host, but not in LTSP
<Q-FUNK> komputes: speaking of which, does my experimental -amd 2.7.7.8 fix those Koolu boxes?
<komputes> Q-FUNK: somewhat, I am testing out a solution, there is still the flicker issue. I hope that after installing your fix and restarting X, the configuration will be made automatically
<Q-FUNK> ok
<Q-FUNK> http://launchpadlibrarian.net/13589055/171_xf86AutoConfig_geode_addition.diff
<ubotu> New bug: #220019 in xorg (main) "[hardy] X random crash when playing videos (Intel 915GM)" [Undecided,New] https://launchpad.net/bugs/220019
<Q-FUNK> komputes: well?
<komputes> Q-FUNK: I will reply to the bug on monday.
<ubotu> New bug: #211759 in xserver-xorg-video-ati (main) "Ubuntu 7.1 Live-CD boots to black screen (ATI Xpress 1250)" [Undecided,Confirmed] https://launchpad.net/bugs/211759
<ubotu> New bug: #220036 in xorg (main) "Multi-Pointer X Window Server " [Undecided,New] https://launchpad.net/bugs/220036
#ubuntu-x 2009-04-13
<bryce_> yeah no freeze on strace glxinfo here either
<bryce_> definitely noticing performance issues tho
<bryce_> hah!
<bryce_> ok, so strace gcalctool does a reproducible freeze
<bryce_> strace firefox segfaulted firefox.  weird
<pwnguin> heh, what's the driver order for nv,nvidia and nouveau?
<pwnguin> ie, if i remove xorg.conf, will i get nouveau or nv?
<pwnguin> i guess i can just find out
<pwnguin> if i don't come back, blame RAOF!
<RAOF> Ah.  Another nouveau tester? :)
<pwnguin> always
<pwnguin> this is more of an x autoconfig thing
<RAOF> Well, nouveau's not going to do that for you :P
<pwnguin> i was hoping i could ditch xorg.conf
<RAOF> Not with nouveau; X will choose the nv driver.
<pwnguin> insane. it looks like i can travel into the past with guest session
<pwnguin> oh
<pwnguin> im stupid and dont understand what "rotate" means in logrotate 
<pwnguin> fun. alt-sysreq-k and nv don't get along
<RAOF> Yeah.  nv probably can't get back from an inconsistent card state.
<pwnguin> here we go
<pwnguin> [config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied (Connection ":1.41" is not allowed to own the service "org.x.config.display20" due to security policies in the configuration file)
<pwnguin> from /var/log/gdm/:20.log
<cwillu> pwnguin, log rotating means keeping old logs by cycling through a list of files
<cwillu> oh, nvm, that wasn't a serious question :p
<bryce_> heya cwillu
* You're now known as ubuntulog
<LLStarks> sigh.
<bryce> tjaalton: maybe we should switch greedy back on (bug 359600)?
<ubottu> Launchpad bug 359600 in xserver-xorg-video-intel "Solved slow 2D performances with EXA" [Undecided,New] https://launchpad.net/bugs/359600
<tjaalton> bryce: I noticed..
<tjaalton> maybe it matters again, so why not
<bryce> tjaalton: think it could cause regressions?
<tjaalton> bryce: hardy still has it? I don't recall any
<bryce> we dropped it at the start of jaunty
<bryce> 2:2.5.1-1ubuntu1
<tjaalton> ah
<bryce> hrm, I wish I'd thought to test this out earlier
<superm1> ooh it's nice and snappy with that on my d630 too
<tjaalton> me too..
<bryce> ok, keep testing it for problems... I'll talk to management on if we can get the patch re-accepted
#ubuntu-x 2009-04-14
<dmandell> msg bryce error was "Failed to set tiling on front buffer: rejected by kernel"
<kees> bryce: ^^ that was doug trying the -intel.  X wouldn't start with it.
<wgrant> X segfaults with the new driver here.
<LLStarks> hello?
<bryce> bugger
<bryce> wgrant, kees, dmandell, thanks for testing it
<bryce> jbarnes: btw, regarding the performance issues, some people have been noticing that flipping on greedy migration makes the performance go back to normal.
<bryce> wgrant: the segfault is expected (it's why we disabled it to begin with)
<superm1> bryce, what conditions are causing the segfault?  is it caused by the way the patch re-implements enabling greedy (as opposed to turning it on in xorg.conf), or just particular hardware combos that are causing it?
<bryce> as far as I can tell (and I could be wrong), the code that gets run is essentially the same code as gets executed when it's set in xorg.conf 
<bryce> s/could/am probably/
<LLStarks> stupid question, how do i sync to vblank without compiz?
<Mirv> bryce: (bug #356951) were there mesa 7.3 deb:s available somewhere still? I could risk a crash on my machine trying those.
<ubottu> Launchpad bug 356951 in linux "Compiz sometimes hangs the machine" [High,In progress] https://launchpad.net/bugs/356951
<Mirv> currently running with compiz disabled on i965
<Mirv> (or if anyone knows)
<Mirv> the branch seems to have only DRI2-related intel-specific things since 7.4 http://cgit.freedesktop.org/mesa/mesa/log/?h=mesa_7_4_branch
<Mirv> if someone would have a lot of time, bisecting since the last 7.3 snapshot could be worthwhile, but it would be far easier if there was some simple trigger to the problem
<tjaalton> Mirv: superm1 already did that, but it didn't seem to help
<tjaalton> I could give it a go this evening once I've fixed my car :/
<Mirv> tjaalton: bisecting or what?
<tjaalton> Mirv: bisecting
<tjaalton> bug 355242
<ubottu> Launchpad bug 355242 in mesa "mythfrontend.real crashed with SIGSEGV in QGLWidget::resizeEvent()" [Undecided,Confirmed] https://launchpad.net/bugs/355242
<tjaalton> once of the crashers
<tjaalton> -c
<Mirv> ok. hmm, mobility m6 (9000) is quite far from i965, though
<Mirv> has someone tested none of the current patches included in the packaging is causing the crashes?
<tjaalton> oh, hehe
<tjaalton> didn't check that it was radeon and not intel..
<Mirv> I've quite a lot of real (paid) work to do but I could try running one specific mesa-version.. maybe I could just disable all the current patches and run it with compiz on and report on that
<tjaalton> yeah, probably worth a shot
<Mirv> if bryce has success with 7.3 + i965, it probably means good enough information already on that front
<Mirv> but ok, compiling that now
<philsf> IIUIC, the new evdev is used for autodetecting hotplugged devices, including keyboards, so there's no need for defining layouts in xorg.conf. In my case, the correct layout is detected, but with the wrong variant. 1- Does this evdev method have the ability to detect layout variants? 2- Since my particular variant is missing from the GUI, should I file a wishlist bug against what package: gnome-* for the GUI, hal-* (-info?) for the hotplug stuff?
<tjaalton> philsf: just put it in /etc/default/console-setup
<tjaalton> look for XKBVARIANT
<tjaalton> restart hal, and possibly X
<philsf> tjaalton: will it work both for console and X?
<philsf> tjaalton: there's also the issue of the GUI recently (since Intrepid) missing this variant
<tjaalton> which variant?
<philsf> abnt2 brazillian layount, thinkpad variant (the right Ctrl is substituted by the slash/question)
<philsf> I reported a bug about it (the GUI, mostly), and only now I found out about evdev/hal and such
<philsf> Bug #359719 - now I'm not sure it's reported against the correct package
<ubottu> Launchpad bug 359719 in xserver-xorg-input-keyboard "abnt2 keyboard layout missing thinkpad variant" [Undecided,New] https://launchpad.net/bugs/359719
<tjaalton> xkb-data would be better
<philsf> is this where the GUIs gets the list of layouts/variants?
<tjaalton> yes
<tjaalton> (AIUI)
<philsf> great, I'll dig more into it, thanks for the pointer
<tjaalton> you can check the upstream git repo for a reason why it was removed
<tjaalton> if it worked in intrepid
<tjaalton> http://cgit.freedesktop.org/xkeyboard-config/
<philsf> it worked in Hardy. I didn't try Intrepid, but some folks confirmed the GUI is also missing this option in that release
<tjaalton> ok
<jcristau> with xkb-data git, using a thinkpad model and br layout will set the thinkpad variant
<tjaalton> ah, model
<jcristau> probably same with 1.5 actually
<tjaalton> most likely
<philsf> is patching /usr/share/X11/xkb/keycodes/evdev overkill?
<tjaalton> the evdev shuffle was before 1.5
<philsf> (aiming at automagic detection)
<jcristau> philsf: what would you want to autodetect?
<philsf> jcristau: the thinkpad variant of abnt layout
<jcristau> well. just set the model to thinkpad.
<jcristau> keycodes/evdev would be the wrong place for this anyway
<philsf> jcristau: I may be misunderstanding, but in my case I think both variants use the same keycode. Is it even possible to auto-detect the variant in this case?
<jcristau> no
<jcristau> you could put some smarts in console-setup to detect that the machine is a thinkpad and set the model appropriately on install, i guess
<philsf> jcristau: I was thinking this was an already solved problem, and that only a small device-specific string/info/fdi was missing. could it be the case?
<jcristau> no idea
<philsf> ok :) should I turn the above bug bug to xkb-data instead? gnome-*? both?
<tjaalton> just try setting the model. if it works, then no bug is needed
<philsf> tjaalton: I had tried setting all four possible thinkpad models (as from vendor IBM in the gnome GUI), with the br layout, but the different key didn't work.
<tjaalton> philsf: ok, in that case move the bug to xkb-data
<philsf> I already did, thanks for the pointers (source package xkeyboard-config)
<tjaalton> bryce: btw, I've not seen any freezes with mesa 7.4, but my -intel is 2.6.3-0u2
<bryce> tjaalton: how long have you been running mesa so far?
<bryce> tjaalton: and do you have compiz enabled?
<bryce> well, certainly could be an -intel change.  If you're certain mesa is not causing it, try upgrading to u9 and see if the freezes appear
<tjaalton> I've installed it on March 31st
<tjaalton> and compiz is runnig
<tjaalton> +n
<tjaalton> suspending messes up the uptime, so I need to check when was the last time I booted it up
<tjaalton> hmm three days ago
<tjaalton> anyway, I'll upgrade it now to see if it'll freeze
<DBO> bryce, I dont know if you remember talking to me or not, but I though I would mention I fixed my render performance issue simply by dropping the up_threshold on the OnDemand governor to 35 from its default
<DBO> my battery life shortened by about 10 minutes overall, but the usability difference is huge
<seb128> bryce: I'm use mesa 7.4 and intel 0ubuntu8 for over a week full day and didn't get any freeze there
<seb128> I didn't do recent updates for other packages though
<tjaalton> heh, someone on that bug is requesting mesa 7.5
<tjaalton> superm1: have you checked libqt upstream if there are commits that fix the segfault?
<superm1> tjaalton, there is no more development on qt3 afaik.  they've moved to qt4 development
<tjaalton> ah, heh
<bryce> ok so we have all combinations
<bryce> mesa 7.4 + old -intel : no freeze, mesa 7.3 + new -intel : no freeze, and mesa 7.4 + new -intel : no freeze
<bryce> *sigh*
 * bryce !<3 freezes
<seb128> I'm still running ubuntu11 for the server, could that make any difference?
<seb128> can people having the issue ssh the box?
<bryce> seb128: doubtful, but at this stage nothing is off the table
<bryce> seb128: yes, being able to ssh to the box is a differentiating symptom between X freezes and kernel freezes
<seb128> ok, and you are sure it's xorg locked? I had case where compiz was eating cpu and being the issue
<bryce> seb128: I did so when I first got the freeze and poked around in every kernel, X, etc. file I could find, but didn't see error messages
<seb128> (not recently but just saying)
<bryce> hmm
<seb128> ie you tried to restart compiz?
<bryce> I did not try killing compiz in that case
<seb128> worth trying
<bryce> yeah
<seb128> because compiz being frozen looks similar to xorg being frozen usually
<bryce> should add that to the freeze page
<bryce> I did reproduce a freeze by strace alarm-clock, which produced identical symptoms
<bryce> however killing that process restored X 
<seb128> well the clock freeze should make gnome-panel not responding
<seb128> but workspace switches etc should still be working
<bryce> hmm, only had one workspace set up on that machine
<bryce> in any case, I'm not sure I like this idea of client apps freezing up X
<seb128> they don't freeze xorg
<seb128> the calendar case freeze the panel usually
<seb128> which means no taskbar update, no menu, no fusa, etc
<seb128> but you can still use nautilus on the desktop and alt tab between open applications
<seb128> compiz freezing can lead to apparent freeze because it's grabbing events
<bryce> well, I could not ctrl-alt-backspace (although it's enabled), couldn't vt switch, couldn't click anything with the mouse, screen did not update, etc.
<bryce> nope, alt-tab was not working either
<seb128> ok, so that's not the usually clock hanging issue
<seb128> perhaps you get a hang in the middle of a dnd or something
<bryce> supposedly strace firefox produced the same freeze situation, however I couldn't reproduce - firefox just segfaults
<seb128> in which case the pointer is grabbed for the dnd which lead to a lock until you stop the application having the lock
<juliux> hi is this a real bug or a misconfiguration on my side?
<juliux> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/359960
<ubottu> Launchpad bug 359960 in xorg "xorg segfaults if gdm starts, system is unusable" [Undecided,New]
<superm1> jcristau, what is with those vocal users on debian bug 515214?  i guess i dont see the case that someone really doesn't want hal doing work for them...
<ubottu> Debian bug 515214 in xserver-xorg "X can run perfectly well (or even better) without HAL. Please make this a" [Normal,Open] http://bugs.debian.org/515214
<tjaalton> superm1: no-one does :)
<tjaalton> I wonder if commit 1df6716281579e (xserver) would fix the duplicate wacom entry crashes
<tjaalton> although looking at the backtrace wouldn't suggest so, since pInfo isn't NULL
<tjaalton> something similar might do
<tjaalton> anyway, night ->
#ubuntu-x 2009-04-15
<tjaalton> bryce_: there's a(nother) patch which might fix the wacom crashes, I'll prepare a new server on my PPA
<bryce_> ok
<Mirv> hmm, if I get a freeze today, have to check ssh:ing and killing compiz. earlier I just did alt-sysrq-k (to get garbled screen ie. change to terminal) and ctrl-alt-delete to reboot cleanly
<bryce> I >just now< had a freeze
<bryce> 2nd one since downgrading to 7.3
<bryce> I was tabbing back and forth quickly and it locked
<bryce> went to another machine and killed compiz, but still was locked
<tjaalton> ok, so mesa is off the hook?-)
<bryce> well, compiz is off the hook at least
<tjaalton> s/mesa/mesa upgrade/
<bryce> tjaalton: well, take a look at https://wiki.ubuntu.com/X/Bugs/IntelDriver
<bryce> tjaalton: notice the number of freezes first reported around 4/7-4/10
<bryce> allow for a day or two of suffering before reporting, puts you at 4/5 or earlier
<bryce> now look at this list of stuff that was changed around that timeframe:  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged]
<tjaalton> but if downgrading mesa didn't help..
<bryce> before I downgraded, I got a freeze within 2 hrs.  After downgrading, my first freeze came 24 hrs later, the second freeze came another 48 hours later
<tjaalton> debugging is easier if it happens more often ;)
 * tjaalton runs
<bryce> seriously though, I just threw a dart at that list and mesa looked like the ripest candidate
<bryce> open to other ideas
<bryce> nothing else on that list really strikes me as likely
<bryce> it's possible it's been freezing up all along, since I usually turn compiz off after testing it for a while
<superm1> looking from the other side, there is that patch on mesa 7.4.x git that is supposed to address intel deadlocks. perhaps helpful to go in the right direction?
<bryce> forwards is a nice direction too...
<superm1> i dont know the circumstances of the deadlock that patch is supposed to address though, might be completely unrelated deadlock
<tjaalton> superm1: which one
<tjaalton> ?
<Mirv> I see only a generic non-intel one
<superm1> yeah that's right my bad.  it is generic
<tjaalton> and I see only DRI2-related intel fixes
<superm1> http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=d805c82068feffda03266855a843de261a45865c
<Mirv> well it's generic, but of course might have been done because of an intel problem
<tjaalton> ah, innocent-looking commit header
<bryce> what about 174_set_bg_pixmap_of_cow_to_none.patch to xserver
<tjaalton> or bumping the max texture size
<bryce> fits the timeframe, and it futzs with how compiz works
<tjaalton> upstream declined it for 7.4 and idr pointed out that it would need other changes too..
<tjaalton> which then broke radeon
<bryce> which patch is that one?
<Mirv> it's in mesa
<bryce> ahhhhh
<bryce> now _that_ could explain why we have only gotten reports on i965
<tjaalton> 103 in mesa
<tjaalton> bump_965_texture_limit
<bryce> since only i965 supports the 4kx4k textures anyway
<tjaalton> right
<bryce> I'll try a build with that disabled, that is a very good hypothesis
<bryce> switching machines...
<Mirv> I'm also running mesa without 102/103/104 patches now.
<tjaalton> Mirv: and still froze?
<Mirv> tjaalton: not yet
<tjaalton> good :)
<superm1> okay i've got a fix for bug 355242
<ubottu> Launchpad bug 355242 in mesa "mythfrontend.real crashed with SIGSEGV in QGLWidget::resizeEvent()" [High,Fix committed] https://launchpad.net/bugs/355242
<superm1> that involves adding a very small patch
<tjaalton> nice!
<superm1> http://pastebin.com/f426f1a5e
<bryce_> weird, lost my network-manager key
<superm1> is git.debian.org not working right now?  this is my first time pushing to it, so i might just be messing up something with it..
<tjaalton> seems to be out of reach atm
<superm1> okay i'll try to push again before i go to bed, otherwise i'll try again in the mornin
<bryce_> hrm, firefox won't start now
<tjaalton> superm1: attach it to the upstream bug too
<tjaalton> oh, done already
<bryce_> tjaalton: seen siretart's post about reverting to the intrepid -intel?
<tjaalton> bryce_: will he maintain it then?-)
<tjaalton> s/will/would/
<bryce_> yeah
<bryce_> I'll feel pretty sheepish if the solution to all our problems is just to go back to 2.4.1 ;-)
<tjaalton> heh
<bryce_> oh hell, git.debian.org is down eh?
<tjaalton> if only the greedy patch would work
<tjaalton> yes
<bryce_> well, even if the patch worked, slangasek says on his system greedy turns firefox black
<tjaalton> ah
<tjaalton> would -intel then have to replace/conflict the -intel-2.4 package?
<bryce_> dunno
<tjaalton> seems to be the other way around
<superm1> bryce, were you planning on pulling in 775ca8e3fa5ddf090115907c78889ed8311cd3ae to fix freedesktop bug 20479 too?  I have a sneaking suspicion it's going to solve the other mythtv mesa bug
<ubottu> Freedesktop bug 20479 in Driver/Radeon "[R100 Mobility M7 7500] Problems with 16bit mode using radeon driver" [Normal,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=20479
<superm1> i'm doing another build with it to verify tho
<bryce> good god, froze again
<bryce> in the middle of an upgrade to boot
<bryce> heh, after upgrading mesa to 7.4
<tjaalton> ah, maybe I know why it hasn't frozen on me yet..
<bryce> but shouldn't I have had to reboot before that takes affect?
<tjaalton> I've got libgl1-mesa-dri without our own patches
<tjaalton> installed
<tjaalton> 7.4-0ubuntu1 UNRELEASED :P
<bryce> ahhhhhghgh
<tjaalton> so, the texture size bump is a very good candidate..
<bryce> dude, that's not the sound of pieces falling into place is it?
<tjaalton> hehe
<tjaalton> normally these are upgraded with the proper versions from the archive, dunno why it didn't happen this time..
<Mirv> dunno, but same here, not showing as being upgradeable
<bryce> I was in the middle of rebuilding mesa without that patch when my system froze :-P so let's try that again...
<tjaalton> I'll upgrade now to make sure it hangs here too
<Mirv> I'm pretty happy if I don't get hangs anymore, so not upgrading :)
<tjaalton> bryce_: so the hang you're seeing with 7.3 is probably fixed in 7.4 ;)
<bryce> hahaha
<bryce> yeah, I probably traded a once a day hang for a once an hour hang ;-)
<tjaalton> and now we are all laughing at it :P
<tjaalton> (if it really _is_ fixed by dropping patch 103..)
<bryce> *build build*
<tjaalton> *crash crash*
<Mirv> tjaalton: not funny ;)
<bryce> hey, I'll take *crash crash* over *Freez... any day
<Mirv> I'm doing my "compile very important work-related stuff" thing, it has usually been good at reproducing any freezing problem
<tjaalton> Mirv: I'm trying to make mine crash/freeze :)
<bryce> so far no one's found good steps to reproduce
<bryce> however having firefox loaded, and alt-tabbing seems like a good approach maybe
<tjaalton> yeah, big windows
<bryce_> I've got the mesa builds, but am waiting for one more freeze before applying
<knome> bug #361568
<ubottu> Launchpad bug 361568 in nvidia-graphics-drivers-180 "Black areas appear on the screen randomly" [Undecided,New] https://launchpad.net/bugs/361568
<Mirv> mesa 7.4 without patches 102/103/104 is still solid here. I think I used to encounter crash this far to a work day previously.
<Mirv> (if using compiz, like now)
<bryce_> Mirv: still having trouble reproducing crash one last time..
<bryce_> X is surprisingly stable when you don't want it to be
<quassel208> https://bugs.launchpad.net/ubuntu/+bug/361291
<ubottu> Launchpad bug 361291 in ubuntu "regressions in kde4.2.2" [Undecided,New]
<quassel208> say ubuntu dictators thake a look at the other site, there are bugs that need to be fixed, like freezing and the regressions
<tjaalton> hit'n'run
<mvo> tjaalton: I was just debugging #351394 and it seems that the "nv" driver is not supporting some cards (9600gt in the bugreport). I assume I can use /usr/share/xserver-xorg/pci/nv.ids to detect what can be used with nv?
<siretart`> hey there
<jcristau> mvo: nv.ids has a (strict) subset of the supported hardware
<siretart`> martin olsson suggested that I should talk to you on ubuntu-devel@l.u.c
<mvo> jcristau: thanks. out of curiosity, why is it a subset? is there a better way to get the full set?
<jcristau> http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_driver.c#n797
<jcristau> see NVIsG80 and NVIsSupported
 * mvo looks
<tjaalton> hahaha, bug 361639
<ubottu> Launchpad bug 361639 in xorg "unneccessary dependency from xserver-xorg to hal" [Undecided,New] https://launchpad.net/bugs/361639
<tjaalton> it's spreading
<jcristau> mvo: and then there's the fun with NVGetPCIXpressChip which i'm not sure i understand
<jcristau> tjaalton: have fun :)
<tjaalton> yeah, the -nv is a mess
<tjaalton> jcristau: I should probably wishlist/in-progress it :)
<tjaalton> siretart`: you are planning to put -intel-2.4 in universe?
<siretart`> tjaalton: I've suggested that on the mailing list, since it happens to work for me.
<siretart`> tjaalton: scottk then told me that I'd need another ACKs from motu-release from that.
<tjaalton> siretart`: what happens when it's removed from the archive?
<siretart`> tjaalton: if what gets removed?
<tjaalton> siretart`: -intel-2.4, it's not going to be there forever :)
<siretart`> tjaalton: yes. so what?
<tjaalton> besides, I'm sure there would be bugreports against the maintained packages..
<tjaalton> siretart`: -intel would have to Replace it right?
<siretart`> why?
<tjaalton> to support upgrades?
<siretart`> oh, I'm not suggesting to include it in main, nor install it by default
<tjaalton> I understand, but people won'
<siretart`> therefore IMO there is no point in considering upgrade paths
<tjaalton> duh
<jcristau> you'd probably need conflicts and replaces, since they'd presumably share some files
<tjaalton> still, it's going to haunt the team
<tjaalton> jcristau: -intel-2.4 has them
<siretart`> yes, the intel-2.4 conflicts, replaces and provides the -intel package
<siretart`> it is a hack for people with hardware that happens to work better with the 2.4 branch until the 2.7 branch matures for older intel chips like mine
<tjaalton> I'd prefer to keep it in a PPA..
<siretart`> k
<siretart`> would you please mention that on the mailing list so that others can comment on that?
<tjaalton> yes
<tjaalton> finally managed to freeze compiz
<tjaalton> ssh works
<jbarnes> what's the backtrace look like?
<tjaalton> checking
<tjaalton> note that this is with the "bump the texture size on 965" patch
<tjaalton> I haven't been able to crash it with plain mesa 7.4
<jbarnes> yeah iirc there were some other places that needed fixing with that
<tjaalton> anyway, here's the backtrace: http://pastebin.ubuntu.com/151506
<jbarnes> looks like it hung the chip somehow
<tjaalton> mouse works, but that's it
<tjaalton> killing X hung it for good
<Mirv> I've had quite a heavy day without any crashes using 102/103/104 patches, so this is starting to look relatively clear
<Mirv> I mean freezes
<Mirv> and without using, ghr.
<Mirv> now that I have this working so well, I won't try putting the texture size patch back since I enjoy this :)
<bryce> jbarnes: check https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/358574 which I think is the same bug, and has some kernel error messages to it
<ubottu> Launchpad bug 358574 in linux "[drm:i915_gem_idle] *ERROR* hardware wedged" [Medium,Triaged]
<jbarnes> bryce: it's possible, I'm not too familiar with the texture size stuff
<bryce> jbarnes: btw, one option I'm considering for solving the performance issue is to just switch greedy migration back on
<bryce> this is patch http://launchpadlibrarian.net/25354124/05_intel_exa_force_greedy.patch we carried back in hardy
<bryce> however, unfortunately it causes a segfault:  https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/360798
<ubottu> Error: This bug is private
<jbarnes> Michel recently suggested disabling Migration optimization altogether
<jbarnes> Option "EXAOptimizeMigration" "off"
<jbarnes> in fdo bug 20739
<ubottu> Launchpad bug 20739 in nobootloader "Install mkvmlinuz and create vmlinuz on pegasos." [Medium,Fix released] https://launchpad.net/bugs/20739
<bryce> ahh interesting; I'd missed that
<jbarnes> I've never tried it... sounds promising though
<bryce> cool, will give it a go, thanks!
<bryce> jbarnes: oh btw on the i965 freeze, dunno if you saw the scrollback but current working theory is that it is caused by 103_bump_965_texture_limit.patch
<jbarnes> yeah saw that... good to isolate it
<jbarnes> upstream mesa may already have a fix
<bryce> fits with the evidence that it is i965-specific
<jbarnes> since I remember hearing about something similar shortly after the texture size bump went in
<tjaalton> idr explained that the other commit would break radeon
<bryce> ah interesting, on which list?
<tjaalton> mesa3d-dev
<tjaalton> 7.4 rel candidate 1 thread
<bryce> ok
<tjaalton> so I'd just drop it and reopen the bug it fixed..
<bryce> tjaalton: are we fairly convinced this is the case?  I'm going to go test my laptop with it dropped... however since reproducing the freeze takes so long, would be nice to have the external verification that others have pinpointed to this patch
<tjaalton> bryce: the other patch fixes tfp for dri2, so patch 103 should be the only one that matters with exa
<bryce> Interesting:  "Each time we bump up the max texture size it means we also increase the max drawing surface size (render to texture and all that).  One consequence of this is the fixed point arithmetic in the swrast triangle code may start failing."
<bryce> ok, bbiab.  testing time
<bryce> in complete irony, I finally gave up trying to reproduce the freeze on my laptop, and the exact moment I went to install the mesa debs, guess what
<bryce> plunk
<tjaalton> heh
<bryce> ok, booted with the "fixed" mesa, now to wait and see if it freezes...
<Mirv> bryce: so I have 102/103/104 patches disabled and definite improvement, so if it's not tfp/dri2 patch (on exa!) or one-line vblank patch (theoretically could be), it's pretty surely the bump texture patch
<Mirv> I couldn't work for a full day with compiz enabled earlier
<bryce> sweet
<bryce> Mirv, did you need 102 or 104 disabled?  It'd be interesting to know if you get the same benefit with only 103 disabled
<tjaalton> Mirv: actually, you should need 102
<tjaalton> I mean, you want it, since vblank still has issues and it was disabled again a while back..
<bryce> heya tormod
<kees> tjaalton: I think I've got a dup of 358643, but it crashes in a different place.
<kees> tjaalton: 361972
<tjaalton> kees: ok, there are a couple of candidates to try
<tjaalton> kees: http://cgit.freedesktop.org/xorg/xserver/commit/?id=efa31092d6703397121a0ada4f7205a8ecad3d3d
<tjaalton> and 1df6716281579e2937743d840ab1079343c503ac
<tjaalton> for the server
<kees> tjaalton: okay, cool.  I have other stuff I have to do first, but if there are packages built to test those fixes, I can do that.
<tjaalton> there aren't yet
<tjaalton> maybe I could push those to my ppa
<tjaalton> and test it myself :P
<tjaalton> actually, no time for testing, but it's uploaded
<tjaalton> kees: it'll show up in https://edge.launchpad.net/~tjaalton/+archive/ppa
<tjaalton> includes the first commit, which should fix crashes when the configfile has devices that aren't present
<tjaalton> not necessarily the same as the other bug
<kees> tjaalton: okay, thanks.
<kees> tjaalton: let me start my VMs again, one sec
<tormod> hi bryce :)
<tjaalton> kees: so, if lshal doesn't show input.x11_driver = 'vmmouse', the fdi file is busted
<tjaalton> Xorg.0.log should also show that it's using vmmouse
<cwillu> bryce, on my 945, neither disabling migration nor enabling greedy migration improves things.  The 2.6.30rc works perfectly with EXA though, subjectively the same performance as 2.6.28 under UXA, and as I had in 8.10 and previous using greedy migration
<tjaalton> that's good news
<bryce> cwillu: nice
<bryce> less nice is that disabling migration or enabling greedy would be easy things to roll out...  
<bryce> guess we can hope the kernel team knows something to try cherrypicking...
<tjaalton> we've got jbarnes here ;)
<bryce> obi wan jbarnes, you're our only hope
<albert23> bryce: it's the bit 17 swizzle patch, that is in 2.6.30-rc2
<bryce> albert23: ahh
<bryce> weird, I was just now looking at that
<bryce> https://bugs.freedesktop.org/show_bug.cgi?id=16835
<ubottu> Freedesktop bug 16835 in Driver/intel "[945 tiling] Low performance due to no A17 workaround" [Major,Resolved: fixed]
<jbarnes> there's also exec buffer fencing
<jbarnes> that went in post-2.6.28
<jbarnes> helps 945 chips a lot
 * cwillu feels helped :)
 * cwillu tries turning on vblank
<cwillu> nice
<cwillu> my big internal gear isn't tearing, and I'm getting more than 0.3fps
 * cwillu knows what to ask for for christmas
<jbarnes> heh
<cwillu> that's odd though, the screensaver preview doesn't get composited.  Is that normal?
<cwillu> i.e., if I spin the cube, I have a black square showing the glmatrix screensaver in the middle of the screen
<jbarnes> for 945 there are really 3 big perf fixes: a17 swizzle, mchbar alloc, and execbuf fencing
<jbarnes> cwillu: you have to use uxa+dri2 to get redirected direct rendering
<cwillu> ah, k
<cwillu> guess I got used to uxa pretty quick
<cwillu> and vblank is still slow as hell under uxa, but that's to be expected?
<tjaalton> dri2 doesn't support it
<tjaalton> aiui
<bryce> I've reported the perf findings with the 2.6.30-rc2 to the kernel team
<bryce> also check out the benchmark results michael larabel posted
<bryce> ok, given the lack of really solid positive results from turning off migration, I'm going to postpone working that change into a patch for now
<bryce> sounds like the kernel team has a better lead on a real fix
#ubuntu-x 2009-04-16
<bryce> heya michaellarabel
<michaellarabel> Hi bryce
<bryce> michaellarabel: thanks again for those charts, I had *just* been lamenting the lack of solid results for changing migration code, before I noticed your charts in my inbox
<bryce> michaellarabel: by chance have you done a comparison of EXA Greedy vs. Option "EXAOptimizeMigration" "off"  ?
<michaellarabel> Heh, that's actually what I have running at this very minute that will be appended to the other charts.
<bryce> I'm wondering if they both provide equivalent performance benefits?  It sounds like the latter may avoid some of the corruption issues that greedy carries.
<michaellarabel> Then on another system, I am running it with 2.6.30-rc2, libdrm 2.4.9, and bisecting the Intel Git to try to narrow down the perf regressions some more.
<bryce> sweet
<michaellarabel> bryce: I think testing might just be about done with EXAOptimizeMigration off.
<jbarnes>  <jbarnes> for 945 there are really 3 big perf fixes: a17 swizzle, mchbar alloc, and execbuf fencing
<jbarnes> michaellarabel: ^^ from before you joined
<bryce> jbarnes: all three of those are in 2.6.30-rc2 right?
<jbarnes> mchbar alloc isn't yet
<bryce> ok
<jbarnes> just refreshed that one yesterday... had to separate out some code for license reasons
<michaellarabel> bryce: Just sent you the "XAOptimizeMigration off results.
<michaellarabel> EXAOptimizeMigration*
<bryce> cool, looking
<bryce> so far I've heard only one problem with greedy in xorg.conf - firefox black screen corruption
<bryce> unfortunately the person who found it is our release manager (i.e. the guy that decides whether any changes to jaunty can go in)
<michaellarabel> and jbarnes: vol 4 of the new documentation is 404 on Intel site - http://intellinuxgraphics.org/Vol_4_G45_subsystem.pdf
<jbarnes> michaellarabel: oops, I'll ping those involved
<michaellarabel> and bryce would it help if you had the 2.6.30-rc2 results for all of those test runs or were just the few from the other one good enough?
<bryce> I'd love to see the full set
<michaellarabel> Okay, I'll run the full set on the new kernel.
<bryce> if there's sufficient space to fit them all
<michaellarabel> it will automatically make room on the graphs, just getting a bit scrunched but will scale to fit room.
<bryce> I assume the kernel fixes will have across-the-board performance benefit by N%, but it's entirely possible the improvements help in some configurations but not in others.
<michaellarabel> bryce: Just normal EXA would you like on 2.6.30-rc2 for the full set or which options?
<bryce> e.g., the kernel performance improvements may not show up in EXA greedy, thus making that option less attractive.  
<bryce> I'd like to see the exa no migration the most I think
<bryce> unless there is a big difference between that and exa greedy
<michaellarabel> I can easily run both, but will start with EXA and no special options.
<bryce> great
<bryce> wow, EXAOptimizeMigration Off bites
<bryce> seems to be little different than no change except on a couple tests
<bryce> michaellarabel: that 'JXRenderMark Transformed Blit Bilinear' test looks wacked
<michaellarabel> bryce: PTS usually runs each test three times or so depending upon the profile etc, so it should be accurate. though I can look into it further to see if something weird is going on in that test.
<bryce> michaellarabel: it's just curious that nomigration gives such huge OPS.  I don't know what that test is measuring exactly, but the difference between that and EXA Greedy is huge and seems a bit suspicious
<bryce> like... I wonder if nomigration is bailing out and refusing to do the operation or something
<bryce> in any case, this has convinced me to dust off the greedy patch and try to get it into shape for shipping.  Dunno if we can convince slangasek to accept it, but looks like it's worth giving it a go.
<michaellarabel> I know the developer of JXRenderMark and will ask him next time I see him in my forums or on IRC.
<bryce> cool
<bryce> I'd also be interested in hearing which JXRenderMark tests will most closely relate to real world user work (e.g. ones that would correlate to various compiz effects or whatnot)
<michaellarabel> Okay
<bryce> whoa, greedy migration is terrible on my laptop
<bryce> also I am getting major corruption (black shadows).  weird
<michaellarabel> what chipset is your laptop using? I hadn't experienced any corruption on the 945 with the Atom netbook nor on another 945-based desktop.
<cwillu> you're on 965 aren't you?
<michaellarabel> bryce: Just sent with 2.6.30-rc2 kernel in there... It's looking good.
<bryce> yes, I'm on i965
<bryce> dell 1420, pretty bog standard i965
<michaellarabel> I think I have system each of 915, 945, 963, 965, G35, G43, G45. Though I highly doubt I would have time to run all of the tests.
<bryce> EXA vs. EXA Greedy seems like the two to test
<bryce> later on, a UXA vs. EXA multi-chip rundown would be interesting, but UXA in jaunty just isn't stable enough to consider yet
<bryce_> sorted the black border issue I had.  Was just an incomplete mesa upgrade
<bryce_> was just an incomplete upgrade.  last time it froze was in the middle of an upgrade
<bryce_> running "greedy" now and there's no prob
<Mirv> bryce_: no I didn't need 102/104 disabled, I just disabled those all three before it was certain it's the max texture patch.
<Mirv> tjaalton: ok, without problems so far even without the vblank patch
<Mirv> I could run another build with just 103 disabled and use that now
<Mirv> though I guess for 965G it's quite clearish anyway that its problems go away by disabling that patch now
<bryce_> :-)
<bryce_> well, the more verification the better...  we're going to have to SRU the fix, so that demands pretty thorough testing be done
<Mirv> ok, going to do another build and use just with 103 disabled from now on
<tjaalton> Mirv: so you've tried vt changes and suspending with vblank?
<Mirv> tjaalton: well vt changes only now (seems to work multiple times), but suspending maybe 5 times now
<tjaalton> ok, those used to mess things up, making it very slow
<tjaalton> I guess mesa 7.4 fixed that
<Mirv> cube is still purring
<Mirv> maybe
<maxb> window level all
<bryce_> feh.  with 7.4 sans patch 103, I've gotten 3 freezes in as many hours
<bryce_> tjaalton: reverting 103 doesn't seem to solve it.
<Mirv> hmm, I'm still running the one from two hours ago, but the day is young still. it couldn't be the vblank patch? 
<Mirv> it's so annoying things seem so random
<tjaalton> bryce_: are you sure?
<tjaalton> I've reverted both 103 and 104 and it's been as stable as before
<Mirv> I've already completed stuff I wasn't able to do when 103 was active. I'd hope bryce would just have some old library in use or something ;) Or X not restarted completely so that libraries would be reloaded, or...
<tjaalton> bryce_: double-check that libgl1-mesa-dri is the version without that patch..
<Mirv> or, running a build from the same source directory so that 103 was already applied before it was disabled
<Mirv> (I always take a fresh apt-get source mesa before building a new one, and remove the patch in addition to removing it from series)
<bryce_> come now guys, give me some credit, I'm not a complete moron ;-)
<bryce_> half maybe...
<tjaalton> hehe
<bryce_> yes, I triple checked that the mesa was correct, did a re-upgrade and reinstalled 3 times
<bryce_> all three freezes occurred when alt-tabbing
<tjaalton> using greedy?
<bryce_> yes
<tjaalton> I'm not :)
<bryce_> ok
<tjaalton> maybe it has something to do with it
<bryce_> yes that could be
<bryce_> all 3 freezes occurred only since switching to greedy
<bryce_> mm
<bryce_> god how I hate -intel
<tseliot> bryce_: do you want -psb instead?
<tseliot> :-P
 * bryce_ runs screaming
<tseliot> hehe
<bryce_> next you'll be offering me -nv or something ;-)
<tseliot> yes, that would be my 2nd choice
<bryce_> ok, rebooting sans-greedy.  brb
<Mirv> not using greedy either
<bryce_> I suppose it's useful to know these two things intefere before we roll them out...
<bryce> nope
<bryce> still froze up, even with greedy removed
<bryce> 4th time freezing with alt-tab
<bryce> also, it seems to be reproduced reliably, freezing after 30-60 min use
<bryce> alt-tab seems to grow slower over time leading up to the freeze
<bryce> night.
<Mirv> hmm, not seeing anything like that, weird
<michaellarabel> bryce: Running 2.6.30 + 2.7 -intel with both EXA and UXA and will have those results soon
<Mirv> michaellarabel: that's exciting! :)
<michaellarabel> Mirv: I think these results might be surprising. Watching the screen, it looks like there are still some massive slowdowns.
<cwillu> wirechief in #ubuntu+1 is reporting that mesa 7.4-0ubuntu2~bug359392~1 makes his crashes go away on 965
<Mirv> tjaalton/bryce: would it be wise to remove the max texture patch anyway if at least me and tjaalton are seeing much better stability? ie. was there any real, tangible benefit of the patch?
<tjaalton> Mirv: I'm for it
<tjaalton> it's only to allow compiz when the virtual size is above 2k*2k
<tseliot> jcristau: any ideas as to why this happens (and including privates.h doesn't solve the problem)? http://pastebin.ubuntu.com/152082/
<jcristau> no
<tseliot> ok, thanks anyway
<michaellarabel> bryce and Mirv: results for 2.7 and 2.6.30 with EXA and UXA should be in your inbox
<tseliot> tjaalton: if I wanted to use libdrm 2.3.0 in Jaunty (to use -psb) which part of the kernel should I modify? gpu/drm and include/drm? Is this documented somewhere?
<tjaalton> tseliot: those should do.. and it's not documented, sounds rather crazy :)
<tseliot> tjaalton: it *is* crazy ;)
<jcristau> psb is such a freaking disaster..
<tjaalton> yeah..
<tseliot> getting it to work is the problem ;)
<tjaalton> the recent thread on kernel-team@ depicts it perfectly
<tseliot> hehe
<tseliot> I read that
<tjaalton> so they just threw a tarball of new code to be merged to the hardy kernel..
<tjaalton> limited audience, but still
<Mirv> michaellarabel: thanks a lot, indeed interesting
<tormod> is there any chance of getting radeonhd 1.2.5 as SRU?
<bryce> tormod: not really; put it in through backports instead
<bryce> if there are critical fixes, those might be sru-able
<bryce> (individually)
<tormod> bryce: bug 359082 is important for r6xx/r7xx so I wondered if one should bother SRU individual fixes
<ubottu> Launchpad bug 359082 in xserver-xorg-video-radeonhd "radeonhd driver doesn't resume from suspend on r6xx/r7xx" [Undecided,Fix committed] https://launchpad.net/bugs/359082
<tormod> since we are not using radeonhd by default it should have more relaxed policy - it should be back in universe maybe
<bryce> tormod: true, well we can move -radeonhd back there for karmic
<bryce> tormod: anyway, slangasek is the one who you have to get approval from on sru's
<bryce> tormod: it's been my experience when asking for version bumps that he tells you to cherrypick out the exact patches you need, rather than bump the whole version
<bryce> but you're welcome to just ask him directly; maybe he'd make an exception in this case
<tormod> yes that sounds like standard practice, but radeonhd is there just for testing anyway...
<bryce> for radeonhd, I'll give my +1 to any solution you and he agree on
<tormod> hmm a blank check :)
<tormod> radeonhd is not on the cd right?
<tormod> (it is not)
<michaellarabel> bryce: Have you looked at the 2.7 + 2.6.30 performance?
<bryce> michaellarabel: yeah I saw your article on that, is that what you mean?
<bryce> sad that there's still problems, but I guess not unsurprising
<michaellarabel> the link I sent on ubuntu-x this morning, http://global.phoronix-test-suite.com/?k=profile&u=phoronix-31974-10432-20657
<bryce> also I keep turning up more reports of regressions when using "greedy"
<bryce> ah sweet
<michaellarabel> So what are you looking at doing for Jaunty?
 * bryce looks
<bryce> well, for the jaunty release itself, it is too late to make course corrections, unless we had 99.99% certainty that the option to change would improve performance without causing regressions
<bryce> so what we've done for now is to at least document the options in the release notes
<michaellarabel> okay
<bryce> https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes
<bryce> one disadvantage to greedy is that it could make it hard to get support from Intel on bugs in the future - see http://bugs.freedesktop.org/show_bug.cgi?id=16773 for example
<ubottu> Freedesktop bug 16773 in Acceleration/EXA "Broken systray when using "MigrationHeuristic" "greedy"" [Normal,Reopened]
<bryce> michaellarabel: at this point, my hopes rest mainly on the kernel team being able to sru the appropriate patches from 2.6.30 to jaunty.  (But please don't quote me on this.)
<michaellarabel> Okay.
<tormod> I read somewhere that Intel will drop EXA soon anyway... I guess no support on EXA from them then.
<bryce> your tests indicate that those kernel changes bring some relief, and upstream feels them to be the "right" solution, so it seems to me to be the right thing to do
<bryce> gahh
<bryce> Intel drops support for legacy stuff far too quickly.
<tormod> there is not much left between legacy and experimental obviously ;)
<bryce> I understand their motivations, but it boxes us distros into the corner not having options to work around problems
<bryce> tormod: bingo
<bryce> we still have users for whom XAA is the only thing that works ;-)
<bryce> anyway
<bryce> at least Intel puts it out as 100% open source
<jbarnes> yeah it's double edged
<jbarnes> we clearly can't support everything we have today (as shown by our huge bug count)
<jbarnes> so unless we drop stuff, nothing will really improve since we'll have no focus
<bryce> jbarnes: like I said, I understand the motivations, and it makes sense.  It just is painful when the new stuff doesn't work yet, to see the current stuff going legacy already.
<jbarnes> we'll continue to support 2.7
<jbarnes> and we'll work to make sure that by the time 2.8 comes out it won't suck
<tormod> do you intend to clean up UXA and make it stable for everyone before the next *XA ;)
<jbarnes> that's the intent
<jbarnes> of course our track record leaves plenty of room for skepticism
<jbarnes> (trust me I'm pretty frustrated by the current situation too)
<bryce> sometimes it seems that upstream moves so quickly, that by the time something is stable enough for end users, it's already unsupported by upstream
<bryce> anyway, now I'm just ranting ;-)
<jbarnes> yeah, but most of these new features have been in development and planned for quite awhile
<jbarnes> so hopefully we're not just making stuff up and dropping the old stuff cause it's not shiny anymore :)
<jbarnes> e.g. gem, kms, dri2 have all been in the works for a long time now
<superm1> tjaalton, i'm still having a hard time pushing to git $ git push origin ubuntu
<superm1> fatal: The remote end hung up unexpectedly
<superm1> can i only push via ssh protocol, and git:// is only for pulling?
<bryce> superm1: you can switch over to ssh for read/write
<superm1> how do I switch the branch over?
<bryce> no clue
<bryce> I just do a new checkout
<superm1> haha
<bryce> I think you can fiddle with the config file in .git/
<superm1> i swear some day it'll all just click and i'll understand git
<bryce> optimist
<bryce> jbarnes: you know, trying to think about this a little more holistically, it often seems that when upstream feels the new thing is "ready", what they mean is that they feel it is "ready for testers" and want to get bug feedback on any remaining issues
<bryce> jbarnes: whereas at the distro level, "ready" would mean "ready for end users" with no bug reports needed
<bryce> in theory, if the former is done sufficiently, the latter should just fall into place
<bryce> but in practice it seems the two get muddled up
<bryce> anyway, I dunno, maybe it'll go better in karmic.
<jbarnes> bryce: yeah definitely
<jbarnes> (about the two getting muddled up I mean)
<jbarnes> I'm mainly unhappy with our bug count at this point, and I can only imagine how distros and users feel about it :)
<jbarnes> my hope is that we'll be able to focus on making fewer code paths more robust
<superm1> bryce, yah .git/config has it in plain text. thanks for the pointer.  so whenever alioth's cron job runs and gets my ssh key in there, i'll finally be able to push
<bryce> jbarnes: yeah in fact I've spared you the brunt of our bug load; if I ever get a good solid chunk of time to upstream bugs, I will be bloating your numbers considerably (we're going on 300 bugs now)
<bryce> (plus bunches more in mesa and xserver that probably should go to intel)
<jbarnes> yeah I noticed... I troll launchpad and your pages sometimes and I'm a little frightened
<jbarnes> our fdo bug count is way too high as it is...
<bryce> part of the reason I've not upstreamed them already, is that the entry bar for -intel in fdo is higher than most of these bugs meet (e.g. needing to test a git version of the driver, needing to set debug flags, capture data from secondary tools, etc.)
<bryce> in some respects I think having a high entry bar is good in keeping the bug load down
<bryce> but in other respects, it doesn't mean the bugs don't exist, just that they don't reach you
<bryce> anyway, what I've been doing on our end is to try and make it easier for users to file bugs that meet the upstream requirements.  I hope that will end up helping.
<jbarnes> yeah that helps a lot
<bryce> jbarnes: fwiw, of the 280 or so bugs, 20% are upstream now (comparible with the proportion of xserver bugs upstream)
<jbarnes> cool
<jbarnes> there's a fairly high dup % upstream too
<jbarnes> dunno how launchpad is
<bryce> we tend to try keeping it pretty clean dupe-wise, but often it's hard to say for certain if a given bug is a dupe or not
<bryce> since for upstreaming bugs there is sort of a "1-issue 1-person" rule, we tend to prefer people not get too aggressive at duping up bugs
<jbarnes> yeah and when I say dupe I mean "caused by the same thing" not similar symptoms
#ubuntu-x 2009-04-17
<bryce> michaellarabel: btw I think you need a s/Intel/Canonical/ in the second to the last paragraph on http://www.phoronix.com/scan.php?page=article&item=ubuntu_netbook_performance&num=8
<bryce> "As of this week, Intel is looking at fixing some of the performance problems when using EXA with Intel graphics by enabling the greedy migration heuristic by default."
<michaellarabel> oops, yeah. Fixing now.
<jbarnes> bryce: btw I wonder how the perf would look with my exa pixmap management patch (the one I added to freedesktop 20739)
<ubottu> Freedesktop bug 20739 in Driver/intel "[i945] X crashes in fbBlt() when using Sun Java Plugin 6 + firefox3.0 on Asus EEEPC 1000" [Critical,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20739
<bryce> jbarnes: I set up a ppa for it - https://edge.launchpad.net/~bryceharrington/+archive/blue
<jbarnes> cool
<bryce> jbarnes: not sure why manoj has not responded on that bug... he was in a dither about it when he first filed it, but strangely went silent the past week
<bryce> man, I wish we had an automated phoronix set up that I could just point at a ppa or a patch, and have it automatically give results
<jbarnes> that would be cool
<pwnguin> Matthew Garrett is currently: angry
<bryce> pwnguin: ??
<pwnguin> "Seriously Intel. Sort it the fuck out."
<pwnguin> http://mjg59.livejournal.com/110535.html
 * bryce shudders at memories of psb support
<superm1> i've got a set of patches to fix that radeon mesa bug too now. just need to narrow it down and see if they're all necessary, or if I can fix it with just one
<superm1> (bug 341898)
<ubottu> Launchpad bug 341898 in mesa "MythTV Frontend does not work with RADEON DRI" [High,Confirmed] https://launchpad.net/bugs/341898
<superm1> tjaalton, bryce the patch got a basic look over from arlied in #dri-devel, so i'd like to squeeze this in if we could.  were you guys gonna make any changes to the other applied patches regarding the intel issue?  
<superm1> or were you saving those for SRUs instead
<superm1> er s/arlied/airlied/
<tjaalton> superm1: I'd need to read the backlog first :) but yes, I'd be ok with that patch
<tjaalton> and editing .git/config should be enough to allow pushing
<superm1> yeah finally got it pushed earlier
<tjaalton> change the url to ssh+git://foo-guest@
<superm1> i just ended up doing ssh://foo-guest@, didn't realize ssh+git:// was a protocol
<tjaalton> ah, both should work
<tjaalton> just noticed that I had that
<superm1> so are you guys doing any other intel deltas to mesa that should go in this same upload, or just treat them mutually exclusive?
<tjaalton> I'm not sure, bryce?
<tjaalton> it probably doesn't matter if there's one more upload
<superm1> okay.
<superm1> so hopefully i don't need to touch mesa for a long time now, debugging these has been very difficult :)
<tjaalton> here's hoping ;)
<bryce_> superm1, tjaalton: I'd also be okay with dropping 103 in mesa
<tjaalton> bryce_: cool
<tjaalton> I think I'll ask my boss (and wife) if there's a chance to get to the UDS..
<bryce_> what it gains is not something that was available in intrepid, thus is not a regression.  And if it eliminates even just some of the freezes, it's a win
<tjaalton> yeah
<bryce_> tjaalton: that would be great if you can come!  Did you get on the sponsorship list?
<tjaalton> bryce_: no, but I think my boss could send me.. that way I wouldn't have to spend my holidays to get there
<bryce_> ah good
<tjaalton> we are moving in two weeks, so we should be settled a month from now
<tjaalton> +down
<tjaalton> the specs are just too interesting to miss ;)
<bryce_> :-)
<bryce_> yeah I got some presentations to write
<bryce_> oh hell what is the cat up to
<bryce_> brb
<tjaalton> :)
<bryce_> left the cupboard where we keep the TP open
<bryce_> apparently toilet paper roll wrappers make a nice crinkley sound when you sink your claws into them...
<bryce_> anyway, I got sick of debugging the freeze bugs blindly.  I'm going to package up cworth's tools tomorrow and stick them in a ppa.  We already have the 2.6.30-rc2 kernel so the hard part's done
<tjaalton> heh
<tjaalton> yep, it's really frustrating..
<Mirv> my i965 is btw GMA X3100 (mobile GM965), if interested. indeed with the max texture size jaunty seems now rock stable even on heavy duty (like compiling and installing ubuntu in virtualbox at the same time, while spinning the cube and browsing the web)
<Mirv> again I missed some words, "with the max texture size patch disabled" I meant
<bryce_> what's the max texture size in your case?
<tjaalton> read the second comment too :)
<cwillu> are i815's running xaa by default?  (i.e., with an empty xorg.conf, they're running xaa?)
<jcristau> cwillu: probably yeah
<bryce> tjaalton: btw what's the status on the mesa upload with 103 disabled?
<tjaalton> bryce: it was discussed on #u-d a couple of hours ago, but I don't know how it ended :)
<tjaalton> just got back
<tjaalton> bbiab ->
<bryce> tjaalton: ok I've committed the change and will upload it at this time
<tjaalton> bryce: great, thanks
<tjaalton> bryce: I wonder if it's patch 104 giving you the trouble?
<tjaalton> but not Mirv or me
<bryce> tjaalton: jesse also pointed me at https://bugs.freedesktop.org/show_bug.cgi?id=20704
<ubottu> Freedesktop bug 20704 in Server/general "memory leak: Keep resizing glxgears window with compiz will make X hang" [Major,Reopened]
<tjaalton> it _shoudln't_ matter if exa is used, but who knows
<tjaalton> oh
<tjaalton> sounds like fun, I'll try it..
<tjaalton> heh, I could use my laptop as an instrument
<tjaalton> there's this high pitch squeak with glxgears running, and the pitch changes with the size of the window
<tjaalton> the larger it is, the lower the pitch
<jbarnes> ouch sounds like one of your input gains might be turned up too high?
<bryce> hehe
<tjaalton> it's not coming from the speaker :)
<jbarnes> ooh
<tjaalton> with nice tremolo
<tjaalton> actually more like a vibrato :)
<tjaalton> it's leaking memory, but not that much
<tjaalton> plugged the charger and now the sound is gone :(
<tjaalton> I need a new battery
<bryce> buzzing battery doesn't sound good
<tjaalton> yeah, it's broken alright
<tjaalton> when I log in I get a popup saying that the charge is 48% and that it means the battery is likely broken
<tjaalton> it's been acting weird for some weeks now
<mdz> howdy folks
<bryce> heya mdz
<jbarnes> ooh "installation complete" on my shiny new jaunty install
<mdz> bryce: I'm now on my affected laptop
<mdz> bryce,jbarnes: I saw mvo's comment on the bug that PCI ID 8086:2a02 may be a common thread
<mdz> that matches what I have as well
<mdz> I'm not sure if that just means "GM965" or if it's more specific
<mdz> it looks like there are only two PCI IDs with that name
<jcristau> #define PCI_CHIP_I965_GM        0x2A02
<jbarnes> yeah 2a02 is 965GM
<mdz> bryce: would my time be better spent testing rolling back that mesa patch, or on trying to find a reproducer?
<jbarnes> I'd say reproduce first, otherwise you won't know if the rollback works
<seb128> I'm using 00:02.0 0300: 8086:2a02 (rev 0c) and I've no hang freeze and speed issue
<jbarnes> seb128: with or without the mesa patch?
<seb128> and I'm using this box full time with compiz one
<seb128> stock jaunty
<seb128> no xorg.conf change (out of virtual for multi screen)
<bryce> mdz: yes, start by verifying you have the issue
<bryce> vs. having seb's luck
<mvo> seb128: and you switch workspaces a lot :)
<mvo> seb128: rev c as well, just like the bug reporter ...
<seb128> mvo: yes, I've my mailed full screen on one screen and IRC on an another screen, I think I switched several time by minute all day long
<seb128> mailed -> mailer
<seb128> I always switch using the keyboard shortcuts if that makes any difference
<bryce> for me, it reproduced mostly with doing alt-tab
<mdz-mini> I've been aqble to recproduce the bug with only a minute or so of tinkering
<mdz-mini> well, a freeze anyway
<rickspencer3> mdz-mini: do you have steps?
<bryce> mdz-mini: wow, excellent
<mvo> mdz-mini: on your t61?
<bryce> mdz-mini: check that you can ssh into the machine and check your syslog to rule out just a kernel bug
<mdz-mini> mvo, yes
<mdz-mini> bryce, yes I can
<bryce> ok good, so chances are high you've got this issue
<mdz-mini> rickspencer3, I played a movie on workspace #4 then switched from workspace 1 to 5 and back many times
 * rickspencer3 tries
<jbarnes> ah a movie
<rickspencer3> mdz-mini: what format moving?
<rickspencer3> movie I mean
<mdz-mini> rickspencer3, happened to be an mp4, but this happened with DVD as well
<mdz-mini> I used totem
<mdz-mini> totem-xine
<rickspencer3> k
<mdz-mini> I have a shell on the machine
<mdz-mini> nothing in dmesg
<mdz-mini> nothing in Xorg.0.log
<mdz-mini> X server backtrace:
<mdz-mini> #0  0x00007f2522cdbcd7 in ioctl () from /lib/libc.so.6
<mdz-mini> #1  0x00007f2520c493bd in drm_intel_gem_bo_start_gtt_access () from /usr/lib/libdrm_intel.so.1
<mdz-mini> #2  0x00007f251003a241 in intelFinish () from /usr/lib/dri/i965_dri.so
<mdz-mini> #3  0x00007f2521948ac6 in __glXDisp_SwapBuffers (cl=0xac8d530, pc=<value optimized out>) at ../../glx/glxcmds.c:1425
<mdz-mini> #4  0x00007f252194bde2 in __glXDispatch (client=0xac8e120) at ../../glx/glxext.c:523
<mdz-mini> #5  0x000000000044e304 in Dispatch () at ../../dix/dispatch.c:437
<mdz-mini> #6  0x0000000000433d8d in main (argc=10, argv=0x7fff2d101828, envp=<value optimized out>) at ../../dix/main.c:397
<bryce> is that after trying to kill X or sysrq or something?
<mdz-mini> no
<mdz-mini> haven't touched it
<bryce> hmm, anyway, drm_intel_gem_bo_start_gtt_access has been associated with the freeze bug, so that's not unexpected
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/327844
<ubottu> Ubuntu bug 327844 in xserver-xorg-video-intel "[G45] X freezes about 1-5 min after switching compiz on" [High,Triaged]
<bryce> although this is one of those cases where the symptoms aren't an exact match for the "traditional" bug
<mdz-mini> this is one I'm confident I can reproduce
<rickspencer3-afk> I'm running two movies now, and can't freeze my 'puer
<rickspencer3-afk> I'm going to run rotate forever for a while
<mvo> hm, different pci id for this one: 8086:2e22 
<jbarnes> hm I still don't see it even with movies
<mdz-mini> strace shows it looping with:
<mdz-mini> ioctl(12, 0x400c645f, 0x7fff2d1015b0)   = ? ERESTARTSYS (To be restarted)
<mdz-mini> --- SIGALRM (Alarm clock) @ 0 (0) ---
<bryce> oh speaking of strace
<bryce> there's another insta-freeze bug if you run 'strace alarm-clock'
<bryce> but it goes away if you pkill alarm-clock
<bryce> supposedly, ditto strace firefox, although I couldn't reproduce that one
<mdz-mini> rebooting, will try again with more debug symbols
<mdz-mini> bryce, /topic in this channel is stale ;-)
<bryce> hehe
<mdz-mini> I happen to be using an external lcd display
* bryce changed the topic of #ubuntu-x to: Ubuntu 9.04 Coming Soon! | https://wiki.ubuntu.com/X
<mdz-mini> significantly larger pixel-wise than the built-in one
<mdz-mini> so working the gpu a bit harder I suppose
<bryce> mdz-mini: mirrored or extended?
<mdz-mini> bryce, I turn off the buil-in
<mdz-mini> built-in
<bryce> ok
<jbarnes> what resolution is the external monitor?
<mdz-mini> I'm going to try to reproduce on the built-in display to see if that's a factor
<mdz-mini> jbarnes, 1920x1200
<bryce> well, patch 103 involves desktop size, so it could fit our theory
<jbarnes> I was also thinking of the infamous pipe underrun
<jbarnes> the debugging for that has unfortunately been removed (it was incompatible with kernel interrupt handling)
<bryce> humm
<mdz-mini> after a cold boot, I'm having trouble reproducing
<bryce> tjaalton, superm1: I'm seeing something funky in the mesa git tree
<jbarnes> I'm spinning a patch for pipe underrun debugging now
<tjaalton> bryce: shoot
<jbarnes> bryce: what do you see?
<bryce> tjaalton, superm1: when I do a debuild from in the git tree, I get different results than if I do a debuild off of apt-get source mesa
<bryce>  .gitattributes         |    4 ++++
<bryce>  debian/changelog       |    8 ++++++++
<bryce>  debian/patches/series  |    2 +-
<bryce>  progs/demos/extfuncs.h |   15 +++++++++++++++
<bryce>  progs/glsl/readtex.h   |   26 --------------------------
<bryce>  5 files changed, 28 insertions(+), 27 deletions(-)
<bryce> the .gitattributes progs/demos/extfuncs.h and progs/glsl/readtex.h are mystery changes
<bryce> I can't see evidence of them in recent git changes though
<tjaalton> from a debdiff?
<bryce> I decided to do my mesa patch off of the apt-get source mesa, so our upload is clean
<bryce> the extfuncs.h change seems to be adding some glVertexAttrib1fv_func variables
<bryce> the readtex.h change appears to be deleting that header entirely
<bryce> git says my tree is clean though...
<tjaalton> but where is that diffstat from?
<jcristau> readtex.h doesn't exist in git afaict. and never has
<bryce> tjaalton: I did an apt-get source mesa, which gave me a 0ubuntu2 dsc
<jbarnes> stuff in progs/demos shouldn't matter, they're just test programs
<bryce> tjaalton: I committed my changes to disable patch 103, then did a debuild -S to produce a 0ubuntu3
<bryce> then I debdiff'd those two and got the above
<bryce> jbarnes: yeah I know, this is totally innocuous, however it worries me that there is any discrepancy at all
<jbarnes> yeah it's a bit weird
<bryce> jbarnes: likely it's just my crappy git skillz
<jcristau> progs/demos/extfuncs.h is in the tarball but not in git afaict
<tjaalton> jcristau: hmm, seems to be in my copy
<tjaalton> of the git tree
<jcristau> tjaalton: hrm.
<tjaalton> but not known by git
<tjaalton> so this might be due to _my_ sucky git fu :)
<bryce> tjaalton: btw there was also a patch 05 (not in series though)
<tjaalton> bryce: that I can't see :)
<bryce> ok, that one probably was me then :-)
<jcristau> i usually do 'git clean -dnx' to see if my working copy has changes wrt git
<tjaalton> hehe
<tjaalton> Would remove lib/
<tjaalton> Would remove patches/
<tjaalton> Would remove progs/demos/extfuncs.h
<tjaalton> Would remove progs/glsl/readtex.c
<tjaalton> Would remove progs/glsl/readtex.h
<tjaalton> Would remove src/glx/x11/depend
<tjaalton> wtf
<bryce> oops :-)
<bryce> git clean -dnx  looks clean in my copy
<jbarnes> still haven't seen it on my 965
<superm1> i try to always look at git status before i do a commit and git diff just to make sure i'm only committing what i want to
<bryce> never heard of git clean before
<jbarnes> mdz-mini: any luck reproducing?
 * bryce appends to "git commands and options to know"
<tjaalton> superm1: did you upload 0u2 based on 0u1 or the git tree?
<tjaalton> I suspect the former
<mdz-mini> jbarnes, not since the cold boot. still trying
<superm1> tjaalton, i apt-get source'd mesa, added my patches, and then added the same patches to the git tree
<superm1> so yeah the former; was that wrong to do?
<tjaalton> superm1: well, more work for you :) (but it confirmed that it's my tree that's buggy)
<superm1> i also generally do a debdiff between dsc's for packages i've not worked with before to make sure their build systems and/or vcs' aren't injecting new stuff that i dont expect in the debdiff
<mdz-mini> is there any reason to suspect it's related to suspent/resume?
<mdz-mini> that would explain why it occurs infrequently for some
<bryce> the apr 3rd freeze has not been definitively associated with suspend/resume
<bryce> however there have definitely been reports about X freeze issues relating to resume
<tjaalton> mine dies if I've booted attached to the dock
<mdz-mini> it seems to need to be in a certain state, but I'm not sure how to get it there
<mdz-mini> when I woke it up after being suspended all day, it was easy
<bryce> mdz-mini: if jesse's right, it might be a memory issue
<bryce> so either a memory region has to fill, or has to get filled with the right combination of stuff
<mdz-mini> jbarnes, is there an easy way to get the X server to allocate lots of chunks of memory?
<tjaalton> I have four gigs, so it could well be hard for me to reproduce
<jbarnes> suspend/resume could definitely change global chip state that we don't restore
<jcristau> tjaalton: boot with mem=1G? :)
<tjaalton> btw; 20:50 < agd5f> r6xx/r7xx 3D driver pushed
<jbarnes> mdz-mini: running lots of GL apps pounds the memory manager pretty hard
<jbarnes> or stuff like openarena or other big apps
<tjaalton> jcristau: good idea, and actually only 3G is available anyway :)
<tjaalton> it has leaked 200meg so far, in 2h
<tjaalton> there, no swap
<jbarnes> oops suspend/resume failed... seems to have crashed my X server (had a video playing)
<bryce> tjaalton: sweet
<mdz-mini> ok I just reproduced again
<bryce> ok, I'm going to go snag some lunch, then work on the freeze debug tool packaging.  be back shortly
<jbarnes> ah no wait X is up, but hung
<jbarnes> yep in start_gtt
<jbarnes> right after resuming
<rickspencer3> So I just ran the rotate forever script with 100ms sleep with three movies running on three desktops
<mdz-mini> different stack trace
<rickspencer3> 25 minutes later, the system is working fine
<mdz-mini> jbarnes, we have a different bug# for that
<mdz-mini> I think
<mdz-mini> for a freeze directly after resume
<mdz-mini> latest stack trace
<mdz-mini> http://pastebin.ubuntu.com/153009/
<Mirv> we would almost need a table about who is trying what on which chipset and which driver
<Mirv> but at least I can fairly surely say the ~bug359392 packages from PPA work as well as did my own build without the max texture patch. used for 10 hours and now having the rotate script running
<tjaalton> Mirv: do you have plenty of RAM?
<Mirv> tjaalton: 2 gigs
<tjaalton> pretty standard these days I guess
<mdz-mini> jbarnes, what sort of info might I be able to get from it while it's hung?  do you want a login?
<jbarnes> reg dump
<jbarnes> or if you have the kernel package & gpu tools package you could get a batchbuffer dump
<mdz-mini> jbarnes, regdump: http://pastebin.com/f38c68b88
<jbarnes> mdz-mini: so did you have to suspend/resume to reproduce it?  or just plug in the external monitor?
<mdz-mini> jbarnes, when I had trouble reproducing, I tried suspend/resume a few times, then launching more apps, then adding some glxgears instances
<jbarnes> ok so at least one suspend/resume was required...
<mdz-mini> the setup when it finally froze was video + browser + 2xglxgears + terminal all on separate desktops
<mdz-mini> after a few suspend/resume cycles
<mdz-mini> not sure which elements were essential
<mdz-mini> if I could get it unwedged it would be interesting to try again with the same instance of the server
 * rickspencer3 tries suspend/resume then repro
<mdz-mini> jbarnes, bryce is it more useful for me to keep trying to distill this down to a simpler reproducer or to try to analyze the frozen state?
<jbarnes> the register dumps didn't have anything interesting that I could see
<jbarnes> w/o the kernel patches I'm not sure there's much else we can grab unless dmesg has an oops or something
<mdz-mini> no such luck
<jbarnes> if you can reproduce it fairly easily (maybe try a few more times) then you could start bisecting
<mdz-mini> i915_wait_irq                                      /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
<mdz-mini> (wchan)
<jbarnes> yeah it's just waiting for some rendering to finish
<jbarnes> cool mine hung in suspend this time
<jbarnes> totally wedged
<jbarnes> ug
<Mirv> with the PPA mesa, I'm (i965 2a02, 2GB RAM) now running successfully rotate-forever with Flight Gear, full screen looping video, firefox and two glxgears while doing suspend-resume-cycles. I guess I could try with mem=1G and see if I get it to hang.
<mdz-mini> Mirv, I think we're talking graphics memory here rather than main memory
<Mirv> mdz-mini: well, I guess intel allocates it from the main memory relative to its size, as it does not have own integrated memory usually
<jbarnes> yeah gem allocates from main memory
<jbarnes> and swaps stuff in and out of the graphics mapping
<bryce> mdz-mini: boiling down the steps to reproduce would be the most helpful
<mdz-mini> bryce, ok, I'll start working on a script
<Mirv> bryce: did you btw have a) amd64 b) less than 2GB of RAM? and 2a02?
<bryce> mdz-mini: at some point I'll want you to also put on the 2.6.30-rc2 kernel and verify you can still reproduce it there, since the debug tools have to be run on that kernel
<bryce> Linux salisbury 2.6.28-11-generic #41-Ubuntu SMP Wed Apr 8 04:38:53 UTC 2009 i686 GNU/Linux
<bryce> MemTotal:        1534756 kB
<bryce> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
<bryce> 	Subsystem: Dell Device [1028:01f3]
<mdz-mini> jbarnes, doesn't it allocate a fixed chunk regardless of how much main memroy there is? or am I confused?
<jbarnes> mdz-mini: no not anymore... with GEM it's all dynamic
<mdz-mini> fun
<bryce> jbarnes: btw fyi, gpu tools which don't need to be run as root, we can add to apport (our automatic bug reporting script)
<jbarnes> cool
<Mirv> bryce: ok, I was just guessing if somehow dropping 103 only helped amd64 users, but I've yet to check if tjaalton is also running amd64
<jbarnes> I'd guess the big ones need root though, since they access debugfs files
<bryce> jbarnes: intel_reg_dump unfortunately appears to need root, which is why we aren't including captures of that for all bug reports (tho would be nice if we could)
<tjaalton> Mirv: 32bit
<Mirv> tjaalton: ok, not a factor then. less than 2GB memory?
<tjaalton> Mirv: no, 3
<jbarnes> mdz-mini: another thing to check would be to see if you're still getting gfx interrupts after the hang
<jbarnes> grep i915 /proc/interrupts
<Mirv> tjaalton: ok, some magic then might be in having less than 2GB memory, but otherwise there is nothing in common
<tjaalton> Mirv: I'll boot with mem=1G so we'll see what happens
<mdz-mini> jbarnes, will check that next time
<jbarnes> I might just have seen it too
<jbarnes> I was idle though after a resume
<jbarnes> no more interrupts
<jbarnes> I wonder if pci=nomsi will help
<jbarnes> also the render clock gating reg looks busted
<bryce> mdz-mini: also at some point you'll want to test the mesa upload I just did, to see if your freeze is one that is fixed by dropping this patch 103
<bryce> I think it's still in the approval queue atm
<mdz-mini> hasn't frozen yet but it rendering very slow
<mdz-mini> came back to normal after a while
<jbarnes> mdz-mini: your last reg dump was from after the hang right?
<mdz-mini> jbarnes, correct
<bryce> mdz-mini: does the slowness increase over time or is it constantly slow?
<mdz-mini> bryce, it gow slow and then nirmal again
<mdz-mini> got
<mdz-mini> jbarnes, I ran the reg dumper twice, that was the second run in cast that matters
<jbarnes> ok
<jbarnes> shouldn't matter
<mdz-mini> this mini 9 keyboard is awful
 * bryce is curious if the mini 12 kbd is better
<mdz-mini> I wonder if the vt switch on suspend/resume is a factor
<mdz-mini> hmmm
<jbarnes> mdz-mini: could be... if you can reproduce it across vt switch rather than suspend/resume it would mean the bug probably isn't due to lost chip state
<mdz-mini> I ran my repro script for 10 minutes without a crash
<mdz-mini> then suspended and resumed
<mdz-mini> ran it again
<mdz-mini> and it crashed after 10 seconds
<mdz-mini> backtrace the same as last time
<mdz-mini> no i915 interrupts
<mdz-mini> jbarnes, anything else I should look at?  next I'll reboot and try with a vt switch
<jbarnes> does grep i915 /proc/interrupt show that it's MSI
<mdz-mini> 2295:     449673     415505   PCI-MSI-edge      i915@pci:0000:00:02.0
<jbarnes> ok yeah try with vt switch
<seb128> mdz-mini: what do you do exactly to trigger it?
<mdz-mini> seb128, I'll post the script
<seb128> I've tried with video playing, glxgear, workspace switching, alt-tab, suspend resume, no such issue there
<seb128> same PCI-MSI-edge on my config
<seb128> mdz-mini: thanks
<mdz-mini> it just start some apps and switches workspaces
<mdz-mini> starts
<seb128> ok, I guess there is something else than the video chipset needed there
<seb128> I've been using this box full day for the week and never ran into the issue, so I don't think those actions will trigger it now
<mdz-mini> jbarnes, vt switch did not seem to trigger it, tried twice
<mdz-mini> suspend/resume seemed to do it
<jbarnes> ok
<jbarnes> care to try pci=nomsi
<jbarnes> btw what was the irq count on the last hagn?
<jbarnes> hgn?
<jbarnes> hang
<mdz-mini> 2295:      52909      53155   PCI-MSI-edge      i915@pci:0000:00:02.0
<mdz-mini> I'm going to add a suspend to the script, confirm that works after a warm boot, then if it's reliable i'll try nomsi
<jbarnes> sounds good
<mdz-mini> no joy
<jbarnes> nomsi didn't help?
<mdz-mini> no, reproducer isn't reliable enough yet to test
<jbarnes> yuck
<jbarnes> I'm putting together a kernel patch to give us some additional debug info too
<mdz-mini> ok
<bryce> btw, the 2.6.30-rc2 kernel is at http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc2/
<jbarnes> has anyone been able to reproduce with a more recent kernel?
<bryce> (I'd love to chunk that into a proper ppa if anyone has a clue on how to do that)
<mdz-mini> bryce, what's stopping you from just uploading it?
<mdz-mini> I'm completely failing to reproduce anymore
<tjaalton> no source package for mailine builds
<tjaalton> +n
<mdz-mini> hmm, ask the kernel team. surely they generate one and just don't publish it yet
<bryce> heisenfreeze
<bryce> reproducibility is inversely proportionate to the availability of means to debug
 * albert23 has the compiz freeze with 2.6.30-rc2
<albert23> intel_reg_dump: http://paste.ubuntu.com/153058/
<albert23> intel_gpu_dump that is
<mdz-mini> just got it again
<mdz-mini> after some random number of tries with the script
<bryce> hrm, this intel-gpu-tools package appears to need libdrm 2.4.6... >just< newer than we have in jaunty
<bryce> jbarnes: is this going to work if I force it to build against libdrm 2.4.5 or do I really truly need .6?
<jbarnes> bryce: just make sure you skip 2.4.7 and go to 2.4.9
<bryce> erm, the problem is more one of packaging for use with jaunty...
<bryce> either I need to get the tool to build against the libdrm we have, or I need to package up a newer libdrm as well
<jbarnes> I'm not sure what it requires
<jcristau> getting the packages from sid would probably work, if this is for debugging?
<bryce> jcristau: sort of; I'm trying to get this packaged for other ubuntu-ers to use
<jcristau> then maybe putting the sid packages into a ppa?
<bryce> yeah maybe
<bryce> jcristau: do you have intel-gpu-tools already packaged?
<jcristau> not yet
<bryce> guess I should have asked that before I started...
<jcristau> was considering replying to cworth to ask for a tarball release actually :)
<bryce> yeah that'd be nice
<tjaalton> I can't seem to be able to exhaust the RAM even without swap and mem=1G
<jcristau> anyway, week end now. good luck with the debugging.
<bryce> cya jcristau
<bryce> ok, guess I'll snag the debian libdrm into the ppa, then toss intel-gpu-tools in there and cross my fingers that it builds
<tjaalton> so now dustin has the same laptop as I do, and he's seeing the freezes..
<mdz-mini> bryce, script emailed
<mdz-mini> not reliable but it's the best I have so far
<bryce> ok thanks
<mdz-mini> rickspencer3 just called saying the script reproduced the problem for him, first time
<jbarnes> I just posted a patch to the launchpad page that might dump some additional info
<jbarnes> (assuming we're getting an error interrupt)
<mdz-mini> I'll see if we can get a module built for our stock kernelwith the patch
<jbarnes> I hope it patches in ok... upstream has kms while 2.6.28 doesn't
<albert23> jbarnes: Did you see my intel_gpu_dump for the freeze? http://paste.ubuntu.com/153058/
<jbarnes> albert23: yeah was checking it out with anholt
<albert23> jbarnes: do you need anything else from the debugfs?
<jbarnes> albert23: yeah the other files would be good to have too
<jbarnes> i915_gem_active 
<jbarnes> there are quite a few, but many are probably empty
<albert23> jbarnes: and some seem to be locked
<bryce> mdz-mini: sweet
<mdz-mini> bryce, where can I get intel_gpu_dump?
<bryce> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
<bryce> mdz-mini: unfortunately it has a deps on a newer libdrm, so am working on that presently
<bryce> meantime you can snag it from debian
<mdz-mini> bryce, how about a atatic amd64 binary?
<mdz-mini> static, even
<bryce> I can't build it in my regular build environment due to the libdrm dep, but am hoping the ppa can do it
<bryce> ok, theoretically the tools are there now -- https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test/
<bryce> but we'll have to wait for ppa to get them all built
<bryce> next... sussing out kernel source packages...
<mdz-mini> nxvl says the repro script locked his system up tight (no ssh)
<jbarnes> mdz-mini: can you send me the script?  jbarnes@virtuousgeek.org
<mdz-mini> jbarnes, it's attached to the bug, but sure, I'll send a copy
<jbarnes> oh I didn't see it, I'll grab it from there
<mdz-mini> sent
<mdz-mini> it needs to run under compiz, requires that wmctrl is installed, and needs a 1x6 workspace layout
<albert23> jbarnes: I have added the files to the LP bug
<jbarnes> albert23: cool thanks
<bryce> albert23: ooh good idea
<bryce> jbarnes: maybe you can adapt that into something that could be included in intel-gpu-tools
<jbarnes> yeah cworth and anholt are rapidly improving the tools
<jbarnes> I think the reg dumper will move there soon too
<bryce> jbarnes: it is rather ubuntu-centric at the moment but could probably be adapted without too much work
<bryce> sweet
<jbarnes> one day we'll even get chip reset right I hope, which will make these types of hangs a little less fatal
<jbarnes> ugg... "make install" from a kernel tree still doesn't build an initramfs for me, nor does it update grub
<bryce> jbarnes: shall I also stick your -intel underrun patch into this PPA, or would you prefer to keep this separate from the regular testing?
<jbarnes> better keep that one out
<bryce> ok
<mdz-mini> albert23, your stack trace matches (one of) mine
<jbarnes> geez I can't even login now
<jbarnes> after updating to the latest bits
<mdz-mini> jbarnes, ??
<jbarnes> hangs the machine while playing the login sound
<mdz-mini> are you using ext4 or anyything crazy like that?
<jbarnes> nope
<jbarnes> that's with my test kernel though
<jbarnes> I could very well have broken something
<mdz-mini> jbarnes, I've noticed that when it's wedged, sometimes I can do a clean reboot, sometimes it hangs up on the way down and only responds to sysrx
<mdz-mini> sysrq even
<jbarnes> aha!
<mdz-mini> rickspencer3 reports that repro.sh froze his system without a suspend/resume
<jbarnes> [drm:i915_driver_irq_handler] *ERROR* render error detected, EIR: 0x00000001
<jbarnes> [drm:i915_driver_irq_handler] *ERROR* instruction error: 0x00000001
<mdz-mini> jbarnes, is that your new debug?
<jbarnes> yeah
<mdz-mini> woo
<bryce> instruction 1 eh?
<jbarnes> that's the instruction error reg
<jbarnes> now to lookup what that means :)
<jbarnes> oh well that's not very useful it gave me a reserved value
<bryce> reserved value?
<jbarnes> the low 3 bits indicate the ring the instruction came from
<jbarnes> values of 1-7 are marked "reserved"
<jbarnes> could be a doc error of course
 * jbarnes updates his patch to get more info
<jbarnes> fwiw netconsole helped out here
<jbarnes> the machine hard hung but I got quite a few messages anyway (even though my ssh sessions were dead)
<mdz-mini> i have always been able to ssh in, though there are some reports similar to yours
<bryce> yay!  finally intel-gpu-tools has built debs:  https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
<bryce> jbarnes: also, I've stuck the underrun patch here:  https://edge.launchpad.net/~bryceharrington/+archive/green
<bryce> jbarnes: I'm not certain that the underrun patch is appropriate for 311895 or not; if not, if you could suggest a better bug it would be useful for, I'll update the name
<jbarnes> bryce: well it sounds like that bug already has output from when the debug code was in
<jbarnes> so we know it's an underrun
<bryce> right... is there a more appropriate bug to use this patch with?
<jbarnes> bryce: have you ever seen the type of jitter underruns cause?
 * jbarnes digs up a video
<mdz> bryce: so I can't use intel-gpu-tools without upgrading libdrm2, which is part of the stack that we're inspecting right?
<bryce> mdz, correct - also need 2.6.30-rc2
<jbarnes> anything that looks like this https://bugs.freedesktop.org/attachment.cgi?id=24795 is like to be underrun related
<mdz> I'd rather not change out any components when I have it in a reproducible state
<jbarnes> so if you get a report that sounds like that, the debug patch will confirm it
<bryce> jbarnes: ok I see.  
<bryce> mdz, alright
<bryce> I'm going to slap these tools on my laptop and have a go at it
#ubuntu-x 2009-04-18
<mdz> jbarnes: did albert23's i915 debugfs stuff net any clues?
<jbarnes> it seemed ok but I've got to go through each instruction with the docs next to me
<bryce_> are the docs online?
<jbarnes> yeah
<jbarnes> at intellinuxgraphics.org
<bryce_> ok thanks, I'll link to them
<jbarnes> trying to refine my debug patch a little
<mdz> ogasawara is working on building a module with jbarnes' patch for the jaunty kernel
<jbarnes> I'll be posting a new one shortly
<ogasawara> jbarnes: should I just wait for the new one?
<jbarnes> yeah give me a few minutes please
<mdz> bryce_: did you have any luck reproducing the bug with the script?
<bryce> oh yeah let me try that first
<bryce_> 1280 * 4: syntax error in expression (error token is "1280
<mdz> bryce_: it doesn't work under metacity
<mdz> it seems to configure workspaces differently, and I haven't bothered to make it work there
<bryce> aha
<bryce> I started it up, and *then* activated compiz
<bryce> it definitely is unhappy 
<bryce> ok, froze
<bryce> ok, tooltime
<jbarnes> ogasawara: ok just posted an updated patch to the lp
<jbarnes> man my machine is failing hard
<ogasawara> jbarnes: ok cool
<mdeslaur> unfortunately, I can't help. I have an nvidia card.
<mdz> mdeslaur: oh, sorry, you were a false positive in my search
<jbarnes> oops had a register address wrong in that last patch
<jbarnes> not harmful, and that reg wasn't very interesting anyway
<ogasawara> jbarnes: I can fix it up really quick if it'll help
<jbarnes> IPEIR should be 0x2064 rather than 0x2088
<ogasawara> jbarnes: np, I'll update it
<jbarnes> cool
<jbarnes> I'm checking the other ones now
<bryce> yay, got a freeze dump for you jbarnes
<jbarnes> oh yay :)
<mdz> it's after midnight here, I'm going to have to pick this up again tomorrow
<mdz> thanks so much to all of you for working this issue
<bryce> night mdz, thanks for your help as well
<mdz> please remember to update the bug report so that others can pick up where you leave off
<jbarnes> mdz: ok later, thanks
<bryce> jbarnes: http://launchpadlibrarian.net/25686110/freeze_dump.txt
<mdz> Buffer size too small in MI_STORE_DATA_INDEX (2 < 3)
<bryce> yeah
<bryce> interesting
<jbarnes> that might just be junk after the end of the ring
<jbarnes> the head pointer should indicate where the hang happened
<bryce> MI_NOOP ?
<jbarnes> yeah just padding
<jbarnes> lots of padding :)
<bryce> 3DSTATE_DRAWING_RECTANGLE sounds interesting
<jbarnes> bryce: see if you can get i915_interrupt too
<jbarnes> it's one of the debugfs files
<bryce> path?
<bryce> nevermind
<bryce> Interrupt enable:    00020053
<bryce> Interrupt identity:  00000000
<bryce> Interrupt mask:      fffcdfac
<bryce> Pipe A stat:         00040000
<bryce> Pipe B stat:         00000206
<bryce> Interrupts received: 43680
<bryce> Current sequence:    517905
<bryce> Waiter sequence:     517991
<bryce> IRQ sequence:        517746
<bryce> jbarnes: uploaded tarball of all the files to the bug
<jbarnes> cool thanks
<jbarnes> bryce: those files are empty :p
<bryce> bah
<bryce> huh, you're right
<bryce> cp: reading `0/i915_batchbuffers': Cannot allocate memory
<jbarnes> bryce: wanna join #intel-gfx?  anholt has questions
<kirkland> bryce: hey
<kirkland> bryce: i just upgraded mesa to 7.4-0ubuntu3
<kirkland> bryce: is that the one thought to provide the 965+compiz fix?
<bryce> kirkland: yes
<kirkland> bryce: fwiw, i upgraded to that rebooted, reran mdz's repro.sh script;  still hangs X
<bryce> ok
<bryce> bugger
<bryce> kirkland: there is now some additional debug tools I've packaged for ubuntu
<bryce> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
<bryce> requires installing a new kernel and new libdrm
<kirkland> bryce: okay, what are we trying to get out of this?
<bryce> kirkland: register dumps that the intel guys can grok to figure out what's gone wrong
<bryce> I posted my stuff on bug 359392 just now
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] https://launchpad.net/bugs/359392
<bryce> a second set might give extra insight
<kirkland> bryce: okay, gimme a moment
<kirkland> bryce: doesn't look like intel-gpu-tools - 1.0-0ubuntu1  has built yet ...
<bryce> god I hate ppas
<bryce> there was an older ~pre2 there which is identical
<bryce> I guess ppa supersedes packages at point of upload, rather than waiting until the new thingee has built?
<bryce> anyway, looks like amd64 has built, so presumably i386 is nearly done
<kirkland> k, amd64 is what i need
<kirkland> bryce: which of the libdrm debs do i need?
<bryce> kirkland: if you add the apt sources.list lines from the ppa into your /etc/apt/sources.list, and do apt-get install intel-gtp-tools it will pull in exactly what it needs
<kirkland> bryce: perfect, thanks.
<kirkland> bryce: rebooting into this jankey environment :-)
<bryce> :-)
<kirkland> bryce: okay
<kirkland> bryce: X hung again, but slightly differently
<kirkland> bryce: i still have control of my mouse
<bryce> yeah that's typical
<kirkland> bryce: but keyboard is unresponsive
<kirkland> bryce: oh?  hmm, i didn't rember that
<kirkland> bryce: okay, where do you want the freeze_dump.txt ?
<bryce> bug 359392
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] https://launchpad.net/bugs/359392
<kirkland> bryce: k
<bryce> maybe snag also the files in /sys/kernel/debug/dri/0/i915* while you're at it
<kirkland> bryce: sure
<kirkland> bryce: done
<bryce> kirkland: thanks!
<kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392/comments/102
<bryce> kirkland: go ahead and restore your system to normal, I think that'll do it for now.
<ubottu> Ubuntu bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged]
<kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392/comments/103
<bryce> god that bug's getting long :-)
<kirkland> bryce: yeah, i'm not jealous, i promise
 * kirkland thinks bryce has one of the hardest jobs in ubuntu :-)
<pwnguin> how much of the -x team's work is writing code versus testing / filing reports for intel?
<pwnguin> seems like a lot of what goes on is wrangling patches from various sources
<bryce> kirkland: heh thanks
<bryce> pwnguin: pretty much
<bryce> pwnguin: most of the X coding is limited to reworking upstream patches to apply to our stuff, or little quirks or enable/disable options and stuff
<bryce> pwnguin: the bug load is just too high to be able to spend much time doing coding for any one particular issue
<bryce> unless it's either really important, or really trivial
<pwnguin> heh
<pwnguin> indeed, it kinda seems like the worst thing that can happen to a bug is to be triaged medium
<bryce> I have been doing a fair bit of scripting type coding, for support tools and so forth
<pwnguin> low priority bugs seem to have tiny fixes
<jbarnes> ok I have to go home now too.. I'll leave my machine running (still hasn't hung with mdz's test script even after suspend/resume)
<bryce> jbarnes: any leads from the info collected so far?
<bryce> pwnguin: to be honest I mostly ignore the priorities on bugs
<jbarnes> my best guess is that we're actually looking at a few bugs here
<jbarnes> but until we can accurately reproduce things we won't know for sure
<bryce> hah, my gut was right
<bryce> jbarnes: yes I've sensed since the start that there are more than a couple bugs going on
<bryce> pwnguin: what I do is skim for bugs with patches, git commit ids, backtraces, fixed-upstream, needs-sponsoring, or other indications that the bug is "ripe".  I'll pick those off regardless of priority set
<LLStarks> bryce what is this delicious new ppa you've created?
<bryce> LLStarks: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
<LLStarks> i see
<ogasawara> bryce, jbarnes:  I've attempted testing with the updated patch, but my system is locking up hard
<ogasawara> bryce: could you give it a try and see if you get the same?
<ogasawara> bryce: I've posted a comment to the bug
<ogasawara> bryce: I gotta drop off, but will be checking back in later.  feel free to email if you need anything else.
<Mirv> tjaalton: I wasn't either able to crash ith mem=1G, ran rotate-forever for the night
<Mirv> tjaalton: what about resolutions btw, I've 1400x900, does your and dustin's machine have same screen?
<Mirv> oh, I guess I shouldn't update compiz since now all 2a02:s are blacklisted
<tjaalton> Mirv: I have a 10x7 screen
<Mirv> ok, there is simply nothing to differentiate non-crashing 2a02 rev 0c:s from crashing ones :(
<Mirv> or maybe if taking a hard look at lspci, but still
<tjaalton> I'll try the script now
<tjaalton> heh, dholbach has a X61s (very similar to X61) and no problems
<tjaalton> maybe it's the models they sell in the US that have problems :)
<Mirv> maybe it's 110V that causes the crashes ;)
<Mirv> then we could disable compiz based on country ;)
<tjaalton> ooh, must be.. power drainage
<tjaalton> sweet, now it crashed
<tjaalton> running repro.sh
<tjaalton> it got to the fourth workspace
<Sarvatt> do the crashing ones have dual channel memory by any chance?
<tjaalton> this is a laptop, dunno
<tjaalton> sigh, for some reason reboot doesn't actually reboot, it'll just bounce back to runlevel 2
<bryce> I got frozen again
<bryce> this time I did it the old fashioned way, just used it for several hours
<bryce> this was after updating to today's mesa
<bryce> I expected it would freeze, but what was curious was that it took 4 hours to do
<bryce> anyway, I posted the intel_gpu_dump and etc. data onto the bug report
<bryce> it seems to be considerably different from the output I got when freezing with the repro.sh script
<bryce> so I wonder if that means they're independent bugs
<bryce> jbarnes: ^ is that a correct conclusion to draw?
<bryce> or can the same root bug cause differing intel_gpu_dump output?
<tjaalton> heh, after shutdown compiz refuses to work
<Mirv> tjaalton: 2a02 was blacklisted...
<tjaalton> gah..
<bryce> there is a config thingee to force it
<Mirv> but right, I had missed repro.sh, I have it running now though not getting a crash
<Mirv> I just edited /usr/bin/compiz and commented out the 2a02 line
<bryce> sudo gedit .config/compiz/compiz-manager
<bryce> and add this line:
<bryce> SKIP_CHECKS=yes
<bryce> we should probably recommend testers enable compiz that way, rather than editing the script
<tjaalton> I edited the wrapper like Mirv 
<tjaalton> last time it hung before finishing the first cycle, but not this time
<tjaalton> I'll let it run for a while
<Mirv> should the repro.sh be visibly able to switch between ws 4 and 0? for me the visible thing is that it stays at workspace 0, but I just cannot change the workspace since it always rotates back
<Mirv> oh, later comment, excepts 1x6 workspace
<bryce> yeah has to be 1x6
<bryce> are you two on the 2.6.30 kernel with the intel_gpu_tools stuff installed?
<tjaalton> you have to have 1x6 grid
<tjaalton> ok, hung again
<tjaalton> not yet
<tjaalton> this is stock jaunty
<tjaalton> what ppa was it again
<tjaalton> ?
<Mirv> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc2/
<bryce> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test/
<Mirv> and not yet
<Mirv> oh right the intel_gpu_tools
<bryce> I've tried to make the directions fairly paint by number but let me know if I missed anything
<tjaalton> heh, intel_gpu_top is funny
<tjaalton> every task is 100% when it's hung
<tjaalton> well, makes sense I guess
<Mirv> tjaalton: so you managed to crash easily with repro.sh? are you still using the mem=1G? I'm not getting a crash but using also full 2G now again.
<tjaalton> Mirv: not using mem=1G and it crashes, yes
<Mirv> hmmh
<tjaalton> Mirv: are you running the stock mesa?
<Mirv> tjaalton: yes, ubuntu3 now, earlier was that ubuntu2~bug359392
<bryce> those two should be basically identical
<Mirv> I've done a couple of suspends as well while running the script, no problems
<tjaalton> ok I got a dump
<tjaalton> next I'll try without patch 104
<tjaalton> no difference
<Mirv> still running smoothly, ca. 10 suspend-resumes done as well
<tjaalton> next I'll build mesa 7.3 and try repro.sh with it
<mdz> morning folks
<tjaalton> morning mdz
<mdz> tjaalton: it appears the mesa patch was not to blame for this particular set of bugs
<tjaalton> mdz: no, but neither was the mesa upgrade ;)
<tjaalton> 7.3 froze immediately
<tjaalton> just finished testing it
<tjaalton> repro.sh is probably a bit too ruthless
<mdz> yes, it's useful to have a case which freezes, but I worry that it may not be the same bug which people encounter in normal usage
<tjaalton> right
<mdz> the visual artifacts are the same, though
<mdz> I think it's reasonably likely
<mdz> it sounds like there is one bug which is fixed by reverting the mesa patch, but it is not the one experienced by most people in the bug report
<ogra> mdz, i'm pretty sure i saw the issue way earlier 
<ogra> like around the berlin sprint
<mdz> ogra: which one is "the" issue?
<mdz> we are certain at this point that there are multiple bugs which can cause X to freeze
<ogra> for me thats the alt-tab animation being delayed by about two seconds, workspace switching being very slow, freezes every two days
<ogra> when i had enabled UXA (which i did to overcome the first two) i could see my swapspace being eaten, after two/three days my system hit OOM
<mdz> ogra: those are at least two separate bugs
<ogra> right, and UXA isnt relevant atm anyway, i switched that off yesterday
<ogra> but i remember that my X exposed issues in berlin already 
<ogra> and it didnt change much since
<tjaalton> the delayed animations one is just generic slowness with the -intel driver jaunty has
<tjaalton> and UXA has memleaks, probably affects EXA too but not as much
<ogra> yeah, i still see zero swap used since i switched off UXA
<ogra> running constantly my system used to use about 2G swap after a day before ...
<ogra> the genric slowness came together with the freezes here though
<tjaalton> that's weird
<tjaalton> sure it's not after turning UXA off?
<mdz> ogra: it's changed a lot since then actually, including a whole new upstream mesa
<ogra> i turned off UXA yesterday, i had my first freezes shortly after the sprint
<ogra> and turned on UXA about two to three weeks after the sprint
 * ogra turns off all important apps and runs the testscript now 
<Sarvatt> for what it's worth, i'm running mesa 7.5 (with only 03 patch in the debian/ubuntu series), xserver-xorg-video-intel 2.7.99/libdrm-2.4.9 on 2.6.30-rc2 with the latest drm-intel-next stuff from a few hours ago and UXA (with and without KMS) is still freezing with alot of compositing activity on my 945GME. With the ubuntu packages I had hard freezes usually when alt-tabbing or opening a new gnome-terminal but with my packages the mouse i
<Sarvatt> s still moveable but the same things trigger it. updating just libdrm/-intel/kernel alone had the same exact crashes as ubuntu packages, the mesa upgrade is the only thing that changed it at all.
<ogra> hmm, glxgears eats a complete CPU core ... it feels like i have no GL accel at all and its software rendering
<ogra> and shouldnt it constantly switch workspaces ?
<ogra> it only did one run and left me on the first then
<tjaalton> you have a 1x6 grid?
<ogra> nope, all default
<ogra> 4 workspaces
<tjaalton> you need to have that
<tjaalton> one row
<ogra_babbage> yup, that helped
 * ogra_babbage is impressed how good pulse copes ... not the slightest coppyness with the video sound
<ogra_babbage> *choppyness
<albert23> With Virtual 2048 2048 in display subsection in xorg.conf I could run the test script without freezing for more then an hour
<albert23> After removing that etting X froze again in less then 2 minutes
<albert23> I originally used it to solve the slow cube rotation. Effect is that you get more EXA offscreen memory
<albert23> For me EXA offscreen memory goes up from 19 to 49 MB
<jbarnes> bryce: it's possible we're seeing different gpu dumps but still the same root cause
<jbarnes> bryce, mdz: ran the test script all night with stock jaunty bits from yesterday, no hang, even did a suspend/resume shortly after starting it
<jbarnes> unfortuantely I didn't have the right number of virtual desktops so I've got to start it over this morning :/
<Mirv> jbarnes: do you see any sense in albert23's suggestions of Virtual setting (increasing EXA offscreen memory)? at least that would be worth trying also by others who experience the hang easily
<Mirv> albert23: if you don't mind, I quote you in the bug report?
<Mirv> (oh well, these are publicly logged channels anyway)
<Mirv> so quoted :)
<ogra_babbage> tell them also that sitting in front of your screen for to long while the script runs might harm your stomack
<ogra_babbage> :)
#ubuntu-x 2009-04-19
<bhuey> hello, I'm having problems with my X configuration
<bhuey> I'm trying to get the NVidia driver working with this machine and but it's not displaying correctly
<bhuey> It's basically not sending a signal to the monitor
<bhuey> but the text console works find
<bhuey> fine
<bhuey> I have the kernel driver, nvidia, loaded and the 180 verions of the glx liberies are load
<bhuey> there aren't any obivous problems with the X log
<bhuey> anybody ?
<bhuey> the "nv" driver works otherwise from the manual change
<RAOF> bhuey: You'd need to pastebin at least your Xorg.0.log & xorg.conf before anyone could say anything useful.
<bhuey> RAOF: bin pastebin where ?
<RAOF> Anywhere.
<RAOF> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<RAOF> Should do.
<bhuey> ok
<bhuey> http://paste.ubuntu.com/153795/
<bhuey> RAOF: there
<bhuey> the screen is in powersave mode otherwise
<bhuey> What do you folks think ?
<RAOF> bhuey: That looks pretty much right to me.
<bhuey> what's going on then ?
<bhuey> the screen is off
<bhuey> or goes into power save mode
<pwnguin> well
<pwnguin> you do have a dpms setting
<bhuey> what's that ?
<bhuey> this is the default configuration that I use with some nvidia instruction to create an xorg.conf
<pwnguin> something power mangement system
<bhuey> what's preventing the display from coming up ?
<pwnguin> does gdm come up?
<bhuey> it's not visible
<bhuey> when I change the driver it comes up
<pwnguin> anything interesting in dmesg or syslog?
<bhuey> let me see
<pwnguin> if you're using an xorg.conf, it might help to pastebinit
<bhuey> ok
<pwnguin> RAOF: this reminds me. should i be able to run multiple x servers on nouveau?
<bhuey> nothing interesting in the syslog
<RAOF> pwnguin: 
<RAOF> pwnguin: Yes, as long as you turn off acceleration.
<RAOF> pwnguin: (I think)
<RAOF> It'll definitely fail if you're trying for acceleration, because of the lack of drm multi-master.
<pwnguin> define accelleration
<pwnguin> certainly not glx
<pwnguin> anything involving mtrr?
<RAOF> Video hardware doing any drawing other than scanning out the frontbuffer to the screen.
<RAOF> In other words: Option "NoAccel" "True"
<pwnguin> i get something like error: setting MTRR (base = 0xe0000000, size = 0x08000000, type = 1) Invalid argument (22)
<pwnguin> in gdm.log
<bhuey> http://paste.ubuntu.com/153832/
<bhuey> that's my xorg.conf
<bhuey> default configuration for the most part
<pwnguin> apparently you really want the nvidia driver ;)
<pwnguin> bhuey: one last guess. check out /var/log/gdm
<bhuey> gdm should be fine, it comes up fine in nv
<pwnguin> and it doesnt come up in nvidia
<pwnguin> find a log where it ran under nvidia
<bhuey> http://paste.ubuntu.com/153834/
<pwnguin> well, aside from completing missing freetype, i donno what's wrong
<bhuey> who else should I talk to about this ?
<pwnguin> #nvidia
<pwnguin> and maybe their forum turned bug report tool
<bhuey> oh wait,
<bhuey> it comes up on the other monitor instead of the first one
<bhuey> interesting
<pwnguin> oh rihgt
<pwnguin> i forgot to ask if you had two video ports
<bhuey> nv and nvidia apparently switch the ports
<pwnguin> heh
<bhuey> how do I get it to use the second monitor ?
<pwnguin> man nvidia
<bhuey> ok
<pwnguin> well crap
<pwnguin> no manpage (nv has one)
<bhuey> no man pages for that
<bhuey> what about nvidia-settings ?
<pwnguin> /usr/share/doc/nvidia-glx should have a very long text manual
<pwnguin> that covers xorg.conf options
<pwnguin> out of curiosity
<pwnguin> why do you prefer nvidia to nv?
<bhuey> dual screen support and glx
<pwnguin> ah
<bhuey> I'm unaware of the open source driver being able to handle thi
<bhuey> this
<pwnguin> nouveau can
<bhuey> if somebody has an xorg.conf that can do this I'd like to see it
<bhuey> handle this ?
<bhuey> which ?
<bhuey> both ?
<pwnguin> dual screen
<pwnguin> glx not so much
<bhuey> glx is a complicated problem
<pwnguin> well, my 6600gt runs glx im told
<pwnguin> but honestly, all i want anymore is just want a quiet desktop that can decode video
<bhuey> I've got the same card
<bhuey> it's budget but works great
<pwnguin> in that case
<pwnguin> gallium3d actually runs (usually) on 6600gt's
<pwnguin> however, i dont think the ubuntu builds come with it
<pwnguin> given that it's highly unstable and works for like one chipset
<bhuey> yeah, I'm able to get mostly what I want from the nvidia configuration tool but I cant save the file
 * bryce waves
<Mirv> morning
<tjaalton> *2
<bhuey> pwnguin: thanks it's working now. I wonder if I can turn one of the monitors into a kind of portait mode
<bhuey> I can rotate the entire image but not just one monitor
<Shappie> Hi all. Im trying to make a big desktop setup with my ATi card (fglrx driver). Can somebody help me?
<Shappie> I have installed the latest drivers from ATi site. Because the ones shipped with Jaunty didnt want to install (using Kubuntu btw).
<Shappie> When i go to the Catalyst Control Center i cant choose for big desktop as usually...
<Shappie> It only says: unknown in grey
<Shappie> Anybody an idea?
<pwnguin> bhuey: i know you can in nouveau with xrandr, havent tried with twinview
#ubuntu-x 2010-04-19
<Sarvatt> darn, i really need to check patches more carefully to see if they are upstream, quite a number are applying with fuzz and duplicating themselves while mass rebuilding the stack from git
<RAOF> Mmm, delicious.
<RAOF> Sarvatt: Have you asked the kernel team for a build of nouveau/linux-2.6?  Since they're already doing drm-next and drm-intel-next, it should be easy for them to do one for nouveau, too.
<Sarvatt> <Sarvatt> if by kernel team you mean apw who I think is the only one that does those builds, then nope because he's been so busy. i dont think they are fully automated and are going through a transition due to the karmic-lucid config stuff because they dont build a lot of days now
<Sarvatt> <Sarvatt> the drm-next daily kernel isn't that far behind usually
<Sarvatt> this xserver 1.8 patch removal hook is getting nuts :D
<RAOF> Hm.  I wonder what http://lists.freedesktop.org/archives/intel-gfx/2010-April/006611.html fixes?
<RAOF> That might be yet another part of the 855 problems.
<Q-FUNK> re
<RAOF> Man, I hate bugs with logs that show every sign of being perfectly normal.
<Sarvatt> yeeep
<Sarvatt> especially when theres no signs of being anything wrong, then you ask them to reproduce and reattach all of the logs and they run apport-collect using a totally different driver with no problems either :)
<Sarvatt> and you're subscribed to it so you get spammed with 20-30 emails from the apport-collects
<RAOF> It looks like disabling DRI has had unexpected side-effects.
<RAOF> I should add an evolution filter for apport-collects.
<RAOF> Oh, no.  I have a *horrible* feeling that disabling KMS might be partially responsible for this.
<Sarvatt> link?
<RAOF> Bug #566103 is one, bug #566133 is another.
<ubottu> Launchpad bug 566103 in xserver-xorg-video-intel "blank screen and complete lockup when X starts on Intel 855GM Chipset " [Undecided,New] https://launchpad.net/bugs/566103
<ubottu> Launchpad bug 566133 in xserver-xorg-video-intel "xserver fails to start after splash, screens turns black, no response, hard reboot needed" [Undecided,New] https://launchpad.net/bugs/566133
<RAOF> You know how in the pre-.33 drm days vga16fb was dependably breaking nouveau?  And it wasn't breaking intel, or ati, because they got their drmfb loaded first?
<RAOF> Possibly that only matters with kms, but I remember playing with this intel laptop making vga16fb load before i915 and got slightly strange behaviourâ¦
<Sarvatt> so its got the xrandr info attached, but didn't attach any xorg logs..
<RAOF> bug #566133 has an xorg log.
<ubottu> Launchpad bug 566133 in xserver-xorg-video-intel "xserver fails to start after splash, screens turns black, no response, hard reboot needed" [Undecided,Incomplete] https://launchpad.net/bugs/566133
<RAOF> A curiously gzipped log, but a log nonetheless.
<Sarvatt> did -20 have the 8xx blacklist?
<Sarvatt> (WW) intel(0): i845 or i855 chip detected.  Disabling DRI to prevent system instability.
<Sarvatt> (**) intel(0): Kernel mode setting active, disabling FBC.
<Sarvatt> ...
<RAOF> Hah.  More fool me.
<RAOF> Yeah.  I *read* that!
<Sarvatt> ah ok [   13.070621] fb0: inteldrmfb frame buffer device
<RAOF> It'd be nice if we could make it clear that you should run apport-collect *after* experiencing a bug, not after having worked-around it.
<seb128> hey there
<seb128> where should bugs about login screen not taking keyboard input in vmware be reassigned?
<Sarvatt> depends, can ya link one of the bugs so I can take a look? /var/log/gdm/:0-greeter.log (or /etc/default/console-setup contents) from an affected system would be useful to have, I've seen reports of the vmware autoinstall stuff screwing up the xkb layout settings causing that exact problem in lucid
<seb128> Sarvatt, bug #565858
<ubottu> Launchpad bug 565858 in xorg-server "login screen does not accept keyboard input on vmware fusion" [Undecided,New] https://launchpad.net/bugs/565858
<Sarvatt> go figure 0 logs..
<seb128> bug #565037
<ubottu> Launchpad bug 565037 in xorg-server "gdm does not take input on login" [Undecided,New] https://launchpad.net/bugs/565037
<Sarvatt> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/console-setup/+bug/548891
<ubottu> Launchpad bug 548891 in console-setup "keyboard input broken due to invalid "SKIP" keyboard model" [High,Confirmed]
<seb128> Sarvatt, thanks
<Sarvatt> no worries, i'll note that as the master bug to dupe others to if i come across any and look into it a bit more when I have some free time, thanks for getting me to look :)
<Sarvatt> got a xserver 1.8 PPA for testing before I merge it all into edgers if anyones interested - https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+packages?field.series_filter=lucid
<Sarvatt> it requires both that and edgers activated
<ricotz> Sarvatt, hi, why arent you creating proper tarballs, so like running ./autogen.sh; ./configure --prefix=/usr ?
<ricotz> and then using "make dist" or "make distcheck" if possible
<Dr_Jakob> So I have updated bug 545298 with a solution that works for me.
<ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [Undecided,Confirmed] https://launchpad.net/bugs/545298
<jcristau> tjaalton: ^^
<tjaalton> Dr_Jakob: ok, thanks for finding the root cause
<Dr_Jakob> tjaalton: I think I found a better fix in the udev rule for vmmouse instead of xorg.conf.d
<tjaalton> Dr_Jakob: it's ok to match the path, the other driver do it as well
<tjaalton> and I uploaded it already, waiting in the queue
<Dr_Jakob> tjaalton: ok thanks for the quick turn around.
<Dr_Jakob> I did opt for the udev rule instead but I have sent out a patch to xorg-devel, lets see if I get any comments.
<ara> hello, one user is reporting (lucid, nvidia driver) xorg eating huge amounts of CPU
<ara> is there anything like that reported already?
<tseliot> with what flavour of the driver?
<tjaalton> Dr_Jakob: heh, yeah that's basically the same
<tjaalton> same result
<Dr_Jakob> yeah
<ara> let me ask him
<ara> nvidia-current
<tseliot> ara: no, I don't think there are any bug reports about that
<ara> how is the best way to debug it?
<ara> tseliot, do you mind if I tell the user to join here to better explain the issue?
<tseliot> ara: some logs would be fine, to begin with
<tseliot> yes, sure
<ara> tseliot, thanks
<tseliot> np
<bigjools> hi ara
<ara> hey bigjools, tseliot, who is responsible of packaging the nvidia driver, will help you debugging your issue
<bigjools> great#
<ara> tseliot, bigjools is part of the launchpad team (soyuz?)
<tseliot> bigjools: can you put the following files on pastebin, please?
<bigjools> yeah Soyuz
<tseliot> ara: let me check
<tseliot> ara: no, I'm not
<ara> tseliot, no, I was introducing you to bigjools :-)
<tseliot> bigjools: /var/log/Xorg.0.log and the output of dmesg
<tseliot> hehe, sorry, I misread what you wrote
<tseliot> too much multitasking here ;)
 * bigjools pastes
<bigjools> http://pastebin.ubuntu.com/418640/ and http://pastebin.ubuntu.com/418641/
<bigjools> also, every time I boot I get the "X won't start" dialog and have to select the option to reconfigure the Xorg.conf
 * tseliot has a look at the logs
<tseliot> bigjools: can you reproduce the problem on boot and archive the logs from failsafe X, please?
<bigjools> tseliot: sure thing - I might reboot now as this desktop is getting unusable, do you need any more logs or anything before I do that?
<tseliot> bigjools: nothing else, thanks
<bigjools> ok, brb
<bigjools> tseliot: ha, the archive logs/configs option told me it had archived them in $backup_location or something like that...!
<bigjools> I viewed the log, it said the Xserver was already running... weird
<tseliot> bigjools: look in either your home directory or in /var/log and you should file an archive which has "failsafe" in its name
<bigjools> tseliot: right, got them
<tseliot> bigjools: ok, please upload the archive somewhere
<bigjools> tseliot: http://people.canonical.com/~ed/failsafeX-backup-100419160532.tar
<tseliot> bigjools: can you boot without the "splash" parameter, please?
<tseliot> (you can do it in the grub menu before booting)
<bigjools> tseliot: ok, gimme 10
<bigjools> tseliot: right, removing splash made it boot fine
<tseliot> bigjools: some weird interaction with plymouth, perhaps? Maybe try asking Keybuk in #ubuntu-devel (show him the :0.log file from the archive)
<bigjools> will do, thanks
<tseliot> np
<bigjools> any thoughts on the slowness?
<tseliot> I can't see any obvious problem in the logs. Please file a separate report about that and I'll subscribe upstream so that they can investigate the issue
<bigjools> tseliot: against which package should I file the bug?
<bigjools> well, I guess I can just use ubuntu-bug
<bigjools> well if it didn't start asking about sound stuff after I selected the display option :/
<tseliot> bigjools: try plymouth. If it's the wrong package we can reassign the bug
<bigjools> copy
<Sarvatt> eww, logs look funky now - http://pastebin.com/9iNWREvC
<sithlord48> hi can someone help me i upgraded to lucid and can't install new video drivers for ati card keep getting a set FORCE_ATI_UNINSTALL enviromental var to force removal
<umarux> Is there a way to improve the graphical performance of a Radeon x1600 under Lucid? I get very poor FPS when watching movies and such.
<umarux> The default drivers are very slow
<Sarvatt> umarux: boot with nomodeset added to grub
<Sarvatt> won't be pretty but it's significantly faster 
<umarux> What will it do?
<Sarvatt> you wont notice the difference between KMS and UMS speeds on intel because intel has UXA and DRI2 under UMS, using DRI1+EXA was always alot faster
<umarux> I'll give it a shot, thanks
<Sarvatt> it disables kernel mode setting, mostly the only thing you'd notice is suspend/resume speed, faster VT switching and a prettier boot process
<umarux> oh ok
<Sarvatt> thats stuff you'd notice losing if you switched to UMS with nomodeset I mean
<umarux> Sarvatt: Wow, thanks for the nomodeset tip, my FPS have a huge jump, I can even watch 720p video now without a problem and before i couldn't even watch 480
<umarux> Now to figure out my final problem. Why lucid doesn't recognize my laptops support for changing the screen brightness, doesn't even show up like it should in /proc/video/
<Sarvatt> nothing I do will turn off vsync on this latest git everything + xserver 1.8 branch..
<Sarvatt> and if i change the swap intervals in driconf to anything but never sync I get 45 fps instead of a constant 60, argh
<Sarvatt> guess thats a change some people might like compared to not having any sync to vblank support on 1.7.x :D
<tormod> Sarvatt, woohoo running your xserver 1.8 now
<tormod> kind of tricky though that the 1.7 -ati in xorg-edgers has a higher version than the 1.8 in xorg-testing....
<Sarvatt> tormod: oh did I upload -ati to edgers by mistake? whoops!
<tormod> no, I think it is ~/+ issue :)
<Sarvatt> ah crap, sorry
<tormod> was kind of bummed here, b/c I cannot configure wireless on the console, iwconfig seems to mess up
<Sarvatt> tormod: almost ready to copy over ya think? it just needs vmmouse and wacom changes (the input changes are a pain to do manually atm) a metapackage and a quick upload of all the video drivers
<tormod> works fine here
<Sarvatt> that changelog is a monster
<Sarvatt> its down to 6 patches \o/
<Sarvatt>   * + debian/xdmx-tools.install: handle xdmx binary being renamed Xdmx
<Sarvatt>   * + debian/xserver-xorg-core.install: install evdev xorg.conf.d snippet built with the server in /usr/share/X11/xorg.conf.d/.
<tormod> maybe instead of hooks we should create a xorg-edgers branch on git.d.o?
<Sarvatt> those are the only manual changes
<tormod> then just use -d origin/xorg-edgers
<Sarvatt> yeah I was going to ask if that would be a possibilty, maybe having the changes in git would help when its eventually merged
<Sarvatt> but I wouldn't want to spam the debian-x lists :)
<jcristau> Sarvatt: xdmx got renamed dmxinfo or so, not Xdmx.  Xdmx is the server.
<tormod> just ask around here :)
<jcristau> and we can disable the commit hook for edgers, or send it somewhere else, if needed.
<tormod> Sarvatt, oh you mean the commits go there?
<Sarvatt> ohh ok thats makes more sense
<tormod> jcristau, sounds good
<Sarvatt> libdrm mesa and xorg-server are the biggies, everything else is easily synced with experimental/unstable/ubuntu. libdrm especially because of the frequent symbol changes, thats the 
<Sarvatt> biggiest pain to keep sed hooks up to date :)
<tormod> Sarvatt, what do think about the ever-increasing gem object bytes? is bug 565981 a real bug or red herring?
<ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981
<Sarvatt> I get it too on intel, no idea at all whats causing it
<Sarvatt> somethings leaking objects for sure though, i got up to 2.5k once and wrapped back to a negative number of gem objects. if i use compiz with bo reuse enabled on intel right now with chrome I get about 2 hours before my system is stuck swapping forever and unresponsive with 1.5GB memory and no swap
<Sarvatt> but disabling BO reuse in driconf and not using compiz stops it from happening..
<tormod> so it seems to be quite serious, and touching many people
<Sarvatt> 9897 objects
<Sarvatt> 1234710528 object bytes
<Sarvatt> hah
 * Sarvatt found an old saved one
<tormod> wow, I usually have only some hundred objects, but maybe I reboot too often
<Sarvatt> thats on a 965, i cant get 945 over 2.5k before its totally dead
<bryceh> is this leak on lucid or just xorg-edgers?
<bryceh> I saw a bug report earlier complaining about leaks, but it was not clear what the issue was
<tormod> it's in lucid AFAIU, and also with edgers and 2.6.34 FWIW
<bryceh> hrm
<Sarvatt> its in lucid, I had this problem with 2.9.1 as well
<Sarvatt> switched back to edgers awhile back just to see if it was any different :)
<tormod> I think the bug reports are spread out, many apps get the blame
<tormod> maybe search lp for OOM reports
<bryceh> do we know precisely which package and/or version causes it?
<tormod> bryceh, then it wouldn't have been so bad :)
<tormod> it's not a kernel leak, since memory gets back after restarting Xorg
<tormod> but you can not see Xorg or any app growing. could be Xorg holding references to the objects
<Sarvatt> tormod: check out upstream drivers/gpu/drm/drm_gem.c and see if theres any changes :)
<Sarvatt> since its not just intel
<jcristau> it's only with compiz running?
<jcristau> (or any gl compositor?)
<Sarvatt> i haven't tried poking it to figure out more yet, compiz + bo reuse + texture tiling + flash seems to be the main ingredients and its fine with metacity (no compositing) and bo reuse/texture tiling disabled
 * Sarvatt reboots into mutter
<tormod> I turned off compiz now and I can not reproduce with my eog case
<jcristau> and does it come back down when you run metacity --replace, or killing X is needed?
<Sarvatt> tormod: whatever you do don't grab the compiz source and look at the patches we have to it :)
<jcristau> just to get some data points...
<tormod> hmm we used to blame compiz for everything before, but nowadays it's upstart :)
<jcristau> tormod: when you can't blame upstart, blame plymouth
<jcristau> ;)
<tormod> jcristau, killing X is needed
<bryceh> heh, was just gonna say
<bryceh> plymouth is the new upstart
<Sarvatt> metacity --replace still has the problem yeah
<Sarvatt> restarting X was needed here too after the driconf changes
<tormod> stopping compiz dropped the number of objects a lot, but I guess that is normal?
<tormod> bytes count did not drop much
<Sarvatt> it didn't here - 1793 objects 703676416 object bytes
<Sarvatt> 1788 objects 703811584 object bytes -- before
<jcristau> bleh
<Sarvatt> the number doesn't really go down, it'll go down 20 or so then go up 50 and back down 20 eventually (just rough numbers)
<Sarvatt> 3 hours uptime here :D
<jcristau> with no compiz i have ~800 objects, 20MB
<jcristau> otoh with compiz all windows are redirected so you get more offscreen pixmaps
<jcristau> but, probably not by that much..
<Sarvatt> 965?
<jcristau> gm45
<Sarvatt> tormod: hold off upgrading from xorg-testing, i'm uploading a compiz with no patches to it since it needs an insane amount of build deps :)
<tormod> Sarvatt, you'll be pushing compiz snapshots now?
<Sarvatt> no I just want to test without all of these patches from the dapper days to fix the blob that are probably not needed :)
<tormod> sounds like a good idea
<tormod> how does one debug the gem objects? for instance, cat /sys/kernel/debug/dri/0/clients gives me the xorg pid + another process which does not exist
<tormod> that was probably the compiz I stopped, a new compiz shows up in clients
<jcristau> heh the ioctls number for X is, err, big. :)
<tormod> jcristau, some hundreds per second
<tormod> and compiz  does some tens per second
<jcristau> i guess at least one per frame :)
<Sarvatt> tormod: using he plymouth drm renderer?
<tormod> Sarvatt, no not yet
<tormod> lp lost its CSS now?
<tormod> nice 90's look, but I can not find any "send comment" button
<RAOF> When it does that, I hit refresh and it fixes it.
<tormod> nvm there is a add comment or attachment link under the useless comment field
<bryceh> it's not fixing it now
<bryceh> RAOF, cjwatson sees the problem too... edge seems to have busted css
<RAOF> :(
<bryceh> at least launchpad is still up
<bryceh> (for now)
 * bryceh distracts RAOF with a volcano
<RAOF> It's a *long* way away; even something as shiny as a volcano needs to be a little closer for distraction :)
<jcristau> it's far away, but it still prevents me from flying tomorrow.
 * jcristau just got a cancellation email
<RAOF> bryceh: What's your feeling about i855 & i845?  It seems that dri-disablement hasn't helped (enough?), and strangely seems to have regressed things like resume-from-suspend for some people on i855.
<bryceh> RAOF, apparently there's a larger volcano that this little guy can fire up, let's see if that one makes a better distraction for you
<bryceh> RAOF, yeah I'm wondering about that too
<jcristau> it seems there's a chance you can get 855 fixed in .1; no progress on 845 it seems.
<RAOF> bryceh: That one *would* be cool.  Volcanos under glaciers make for fun!
<bryceh> RAOF, it would be helpful if the DRI disablement could be opted around with an xorg.conf setting or some such, so we can see if by re-enabling it it makes the issues go away
<bryceh> RAOF, I'm not convinced that disabling KMS caused the issues
<bryceh> I'd like to see more data to prove that
<bryceh> also changing the kernel is hard
<RAOF> jcristau: Right.  That big intel-agp patch seems to be landing in drm-intel-next.
<bryceh> RAOF, maybe set up a PPA with the DRI change reverted, so we can get data on if just re-enabling it resolves the issues?  That could be a simpler fix
<jcristau> yeah it's likely to end up in .35 first, and then get backported, afaict
<bryceh> one thing I'm wondering is if we've been chasing a corner case
<RAOF> jcristau: It looks a tiny bit scary; it refactors code common to all the intel cards, right?
<bryceh> as in, if 90% of 8xx was just working, the remaining 10% might have been especially active in the bug reports, and we assumed they represented a tip of the iceberg, when they were really just a small but vocal minority
<bryceh> and so by addressing their issue we could have busted stuff for some (small?) portion of the other 90%
<RAOF> bryceh: Possibly; there's certainly been âmy i855 was working wonderfully, and now it's terribly slow and compiz doesn't workâ bugs, and (at least one) thread on ubuntuforums.
<bryceh> so it may be that there is simply no configuration which will work 100% of the time with what we've got
<jcristau> RAOF: i assume there's a way to just change stuff for 8xx when backporting.  danvet's current series looks big and scary, yeah.
<bryceh> this makes me think that we just make all the various permutations user-settable, list it as a known issue in the release notes, and document well how to configure things, and wish users the best.
<jcristau> but i assume he moved stuff around in the process of understanding the code and the bug..
<bryceh> kind of late in the release to do substantial fixing
<Sarvatt> someone actually said 855 worked well before? i dont believe it! :D
<RAOF> bryceh: That seems like a good idea; default to vesa, allow fbdev by i915.modeset=1, allow 3D by an xorg.conf
<jcristau> Sarvatt: probably not since gem or so..
<RAOF> jcristau: Yeah.  It looked to me like backporting the patch in such a way as to make it only apply to 8xx would mean taking the idea and rewriting it.
<jcristau> if i were you i'd just release note 855 and 845, and punt to .1 :)
<bryceh> Sarvatt, yeah our feedback mechanisms with X are piss poor, as we really only hear when things are broken
<bryceh> so gets really hard to judge when an issue is serious or just one guy with bad hardware
<jcristau> srsly.  http://cgit.freedesktop.org/~danvet/drm/commit/?h=stuff/i8xx_cache_coherency_for_oga&id=925114122c4bc9864951478e62169e9f34f9d41c "write random stuff, and wait until it sticks"
<RAOF> Yes.
<jcristau> this hardware is messed up :)
<RAOF> Yes :)
<jcristau> from the tested-by list, it seems he's rounded up most of the remaining 855 owners ;)
<bryceh> heh, "probabilistic"
<bryceh> "We use a monte carlo approach to getting graphics to your screen"
<jcristau> "if it doesn't work, blame the volcano"
<bryceh> sounds good to me
<Sarvatt> 2298 objects 970698752 object bytes whee
<bryceh> RAOF, what do you think about updating that DRI patch to use an xorg.conf settable parameter, and then just listing this as a known issue with the workarounds documented?
#ubuntu-x 2010-04-20
<RAOF> bryceh: It wasn't obvious to me how to make it work with a âDRI "on"â override; it would be easy enough to add a new parameter, though.
<bryceh> RAOF, that sounds fine
<RAOF> I'm not sure that disabling DRI bought us much, though.
<bryceh> want to just drop the patch entirely?
<RAOF> Yeah.
<bryceh> if the patch is dropped, then users can opt to turn off DRI the usual way
<RAOF> I think drop the patch, and drop to vesa.
<bryceh> hmm, I think I tend favoring documenting the workarounds, rather than forcing to vesa
<bryceh> (of course, I say this not owning any 8xx...)
<RAOF> Well, it wouldn't be forcing vesa.  And the nice thing about defaulting to vesa is that the user will have a working X to check for workarounds.
<jcristau> bryceh: you can just drop those pci ids from the server autoconfig for intel.  then by default it'll choose vesa+fbdev, and if people want to force it they can set intel in xorg.conf?
<RAOF> jcristau: Exactly.
<RAOF> If the user happens to have a system where -intel freezes X almost immediately after starting X, it's much more difficult for them to find & apply workarounds.
<bryceh> hmm
<jcristau> every new comment from danvet on that bug 27187 makes the story even more sad..
<ubottu> Launchpad bug 27187 in initramfs-tools "failure with 2.6.15 on vmware 5.5 (scsi disk)" [Medium,Fix released] https://launchpad.net/bugs/27187
<jcristau> bad ubottu 
<Sarvatt> well thats new - http://paste.ubuntu.com/418914/
<bryceh> if we go with vesa for this for release, I think that will make it quite hard to get it re-enabled for .1
<bryceh> RAOF, with that said though, since I won't be involved in the .1 stuff, I'll defer to your preference here
<RAOF> bryceh: Because it will be difficult to get testing?
<bryceh> dropping to vesa seems to be rather extreme, but then it does not look like we can expect any simple fix any time soon from upstream
<bryceh> RAOF, that, but also because generally it's expected any change be provably free of causing regression
<RAOF> Which will be difficult, moving from vesa.  Yeah.
<bryceh> someone with a working 8.04 that finds it broken on going to 8.04.1 risks getting really bad press, so archive admins will be very hesistant to accept such changes
<bryceh> otoh it seems silly to argue that we should release with known breakage now, just so it's easier to justify updating in .1
<RAOF> So, our story for people who have broken i855 is going to be either âWe've turned off all the features of your video card to stop it from crashingâ or âIf your graphics keep crashing, try $LIST_OF_WORKAROUNDSâ.
<bryceh> pretty much
<RAOF> Can we get them to a known-stable X just from the kernel command line?
<jcristau> does blacklist=i915 work?
<Sarvatt> well todays kernel doesn't work well, dmesg is flooded with [  172.258651] [drm:i915_gem_do_execbuffer] *ERROR* Object f437eea0 appears more than once in object list
<Sarvatt> jcristau: thats getting ignored later on in the boot process for me at least
<jcristau> or does that just blacklist it from the initramfs, not the actual system?
<jcristau> Sarvatt: damn, ok
<RAOF> âi915.disable=yesâ would prevent the kernel module from loading; I'm not sure if that's sufficient to force a working configuration, though.
<jcristau> istr some xforcevesa cmdline option in ubuntu a while back, does that still exist?
<Sarvatt> jcristau: nope :( I tried adding it back but ran into problems where those blacklists were getting ignored later in the boot
<Sarvatt> its there for livecd's, all it does is make a xorg.conf with vesa in it which will break people using KMS horribly :)
<Sarvatt> and installs that xorg.conf too if you install booting with it
<jcristau> it would probably be easy to hack up some /proc/cmdline parsing in xf86AutoConfig.c, but eww.
<jcristau> like 'if /proc/cmdline contains failsafe, don't bother with the native driver, go with the fallbacks'.  still, eww.
<Sarvatt> jcristau: do you know if pci_device_has_kernel_driver from libpciaccess checks for KMS or just if there is a kernel module loaded for it?
<Sarvatt> yeah I added it to grub's upstart script actually, can just exit 1 and it'll start failsafe automatically and our failsafe checks if KMS is in use to use fbdev or vesa
<Sarvatt> err sorry GDM
<jcristau> Sarvatt: if (stat(/sys/bus/pci/xxxxx/driver) == 0) return true; else return false;
<jcristau> not sure if that exists in the non-kms case
<bryceh> yeah, xforcevesa is gone
<wgrant> Bug #565981 is a bit scary.
<ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981
<bryceh> Re: Bug #565981 -- could this be the memory bug discussed earlier?
<ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981
<bryceh> oh reported by Tormod... so yeah sounds like it
<wgrant> bryceh: Thanks.
<bryceh> wgrant, when did you first notice this problem?
<bryceh> wgrant, or are you able to reproduce it?
<Sarvatt> i want to say it was around the -19 kernel here
<bryceh> it would be helpful if we could pinpoint it specifically to the kernel or to xorg-server
<wgrant> bryceh: I've been suspicious of it for a few weeks, but it has only been causing real thrashing for a couple of weeks now.
<bryceh> hmm, alright
<bryceh> well then probably not the xserver
<wgrant> And since it is easily reproducible, I might grab an older kernel and see what happens.
<wgrant> Hm, actually, maybe not. My bootloader is fragile enough as it is.
<bryceh> is it easy enough to reproduce that the testing could be done with LiveCD's?
<jcristau> i'd blame libdrm or xf86-video-intel rather than the server tbh.
<jcristau> that or kernel.
<bryceh> jcristau, we've had people claiming same behavior with -ati
<jcristau> hmm. or mesa.  so many pieces..
<bryceh> I hate releases
<Sarvatt> libdrm wasnt updated, intel and mesa were though and whatever it is I get it with the latest git too
<Sarvatt> looks like it was around the beginning of april, after 3-30 sometime judging by how often i started updating edgers again when I switched back :D
<wgrant> Oh, oops, I thought the repro instructions weren't working well any more, since it appeared to only increase from 192MiB to 198MiB. Then I closed firefox and it went negative, so I was reading it an order of magnitude too low.
<wgrant> So yes, it's still easily reproducible.
<bryceh> well, xorg-server did get an update around 3-30
<Sarvatt> i switched because i wanted to see if it was a problem there too
<Sarvatt> oh yeah 1.98GB you had there :D
<bryceh> the updates to -intel have been mostly cherrypicks
<bryceh> aside from the Xv backport stuff we got from Debian it's been pretty pedestrian
<Sarvatt> trying to narrow it down some more to start looking
<bryceh> mesa got a version bump, but that was more recently
<wgrant> I might downgrade to xorg-server 2:1.7.6-1ubuntu1 and see what happens.
<bryceh> and I don't think it changed at all in late march
<wgrant> (25/03/2010, that was)
<bryceh> wgrant, that would help
<Sarvatt> wgrant: your input devices would stop working is what'd happen :)
<wgrant> Sarvatt: I was hoping there wasn't an ABI bump :(
<Sarvatt> oh nevermind we dont have the dropped udev rules
<wgrant> Oh, right.
<Sarvatt> darn dont have the -18 kernel anymore
<wgrant> Sarvatt: That's easy to fix, fortunately...
<wgrant> It's not like we're Debian.
<jcristau> hmm? :)
<wgrant> Well, I guess you have snapshot.d.o.
<jcristau> yep.
<jcristau> and you'd have lp instead?
<wgrant> Right.
<Sarvatt> hmm why do we have "addÂ someÂ fallbackÂ placementsÂ forÂ VRAMÂ onlyÂ objects", that was reverted upstream because it caused problems?
<jcristau> isn't that radeon?
<Sarvatt> yeah
<Sarvatt> that r100 compiz fix
 * Sarvatt tries reverting that dri2 fix
<wgrant> Downgrading the server to -1ubuntu1 might have fixed it, although I'm running with a rather manual config, so it's not a wonderful test.
 * bryceh eyeballs patches
<bryceh> hmm
<bryceh> from our changelog, none of the patches sound likely to cause memory leaks, I think we'd need to test patch by patch
<bryceh> at least if -1ubuntu1 is proven to not have the issue at least we know it's not an upstream bug but one of the distro patches
<Sarvatt> bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/553647 - http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=94ccaae1ff45c11453141469f5659b6d2a16c4bf
<ubottu> Launchpad bug 553647 in xorg-server "xserver crash (repeatable, triggered by mouse-click)" [High,Incomplete]
<Sarvatt> 1ubuntu1 didn't have that dri2 fix that ended up being done differently upstream in the end
<wgrant> Yeah, -2ubuntu1 is good, -2ubuntu2 is bad.
<bryceh> ah, so it would be 114_dri2_make_sure_x_drawable_exists.patch
<wgrant> I looked at that patch before, but didn't feel too suspicious.
 * wgrant upgrades again, and is pleased to have a working keyboard.
<bryceh> Sarvatt, 114_dri2_make_sure_x_drawable_exists.patch is one you'd suggested - know if there's a better patch available, or should we just drop it for now?
<Sarvatt> still waiting on xserver without that patch to build to see if it fixes the issue here too
<Sarvatt> there are better patches available, they went through a ton of revisions but i have no idea if they apply to 1.7 branch
<Sarvatt> digging up the bug
<bryceh> well, at this stage we'd need something reasonably simple
<bryceh> https://bugs.edge.launchpad.net/ubuntu/+bug/550218
<ubottu> Launchpad bug 550218 in xorg-server "xserver crashes when closing application using clutter" [High,Fix released]
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=26394
<ubottu> Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,Assigned]
<Sarvatt>  -- Bryce Harrington <bryce@ubuntu.com>  Wed, 31 Mar 2010 16:37:45 -0700
<Sarvatt> wow I got the time exactly right
<Sarvatt> yeah thats not going to apply cleanly, I see hunks in DRI2WaitMSC thats not on 1.7
<Sarvatt> yeeep thats for sure the problem, 3 runs of tormods eog background loop and its hovering around 60MB
<Sarvatt> will try to backport those patches tomorrow, looks doable but I have to pass out
<Sarvatt> 188 objects
<Sarvatt> 55336960 object bytes
<Sarvatt> (with at least 20 chrome tabs open including flash ones)
<Sarvatt> actually fedora probably already backported them since it affects F-12 too!
<Sarvatt> nope
<Sarvatt> The patches are now on xserver master, please give that a try and close the bug
<Sarvatt> if it fixes the problem for you.
<Sarvatt> that's going to be so lovely once we have 8 xserver release branches in lucid's lifespan
<Sarvatt> with the 3 month release cycles
<Sarvatt> oops I meant 12, 8 until the next LTS release :)
<Sarvatt> this is rougher than it looked
<stefanlsd> Im getting random gdm restarts on Lucid. Happened about 6 times this morning, any ideas where I can look? Ive checked normal log files and dont find anything conclusive...
<RAOF> stefanlsd: What graphics card, log files pastebinned, etc?
<RAOF> Too slow :/
<stefanlsd> RAOF: sorry, having issues here :)  its a nVidia Corporation GT200 [GeForce GTX 260M] (running propietry drivers).  cant find anything relating to a crash in the logs under /var/log
<RAOF> What, specifically are ârandom gdm restartsâ?  Crash from a working session back to gdm?
<stefanlsd> RAOF: yeah. just working, and screen goes black and im at GDM login again
<stefanlsd> (happened twice since last post)
<RAOF> There *should* be something either in dmesg or in /var/log/Xorg.0.log.old about that.
<tjaalton> it's a blob, so not much we can do about
<stefanlsd> http://pastebin.ubuntu.com/419026/ is my Xorg.0.log.old
<stefanlsd> dont really see anything
<stefanlsd> Just switched to opensource nv driver to see if i can reproduce it
<RAOF> ddxSigGiveUp is âX has been asked nicely to shutdownâ, right?
<stefanlsd> mm. Would the backtrace stuff help? not sure since its not really a crash...
<RAOF> Yeah.  To *me* it looks like something is telling X nicely to shut down, and it's complying.
<stefanlsd> RAOF: hehe. thats nice of X :)
<stefanlsd> nv drivers looks better so far, will run it today
<RAOF> stefanlsd: dmesg doesn't have any complaints in it?
<stefanlsd> RAOF: yeah, nothing in dmesg. no crash on nv driver yet though
<vish> hmm , in this comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565981/comments/5  wgrant is referring to xserver-xorg  or xserver-xorg-core ?
<ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Critical,New]
<vish> not sure which package to downgrade and test 
<wgrant> vish: xserver-xorg-core and xserver-common. xserver-xorg is the source.
<wgrant> Er, xorg-server is the source.
<vish> wgrant: ah, thanks.. so only those 2 i need to downgrade?
<wgrant> vish: Potentially xvfb too, unless you want apt to be angry.
<vish> we dont want that ;)  k.. thanks downgrading those 3..
<Sarvatt> just uploaded an xserver with the 2 commits backported, can anyone try it out? i'm about to  head out to work
<Sarvatt> 1.7.6-2ubuntu7
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/bugs
<Sarvatt> vish, wgrant ^ :)
<vish> Sarvatt: sure.. i had downgraded as per what wgrant mentioned and it seems to be working fine too..
 * vish adds ppa
<Sarvatt> removing that patch isnt really an option
<Sarvatt> open quadrapassel and close it to see why :)
<Sarvatt> lol
<Sarvatt> dangit, I didn't think he'd really do it :(
<vish> Sarvatt: damn you! ;p
 * vish should stop blindly trying things mentioned on irc :s
<vish> wow , that was a weird crash ..
<Sarvatt> vish: sorry about that, that happens closing any clutter based app though
<vish> Sarvatt: hehe , np.. ;) luckily i had no unsaved docs :)
<Sarvatt> yeah xserver failed to build, ahh well will have to mess with it later
<Sarvatt> oh hmm, looks like silly mistakes, here goes try 2
<Sarvatt> here's what i've got so far - http://sarvatt.com/downloads/patches/119_dri2_drawables.patch
<Sarvatt> plus http://sarvatt.com/downloads/patches/120_glx_drop_destroywindow.patch which applied cleanly
<Sarvatt> ah damn I forgot to account for http://cgit.freedesktop.org/xorg/xserver/diff/hw/xfree86/dri2/dri2ext.c?id=895f40792a14d8b88923bf3b428d31ae3bb31e46 
<Sarvatt> darn, i'm not sure what to do here
<Sarvatt> they added dri2DrawableRes = CreateNewResourceType(DRI2DrawableGone, "DRI2Drawable"); to DRI2Setup in dri2.c, we have an older dix abi and have to register it seperately, I split it out to this 
<Sarvatt> +    dri2DrawableRes = CreateNewResourceType(DRI2DrawableGone);
<Sarvatt> +    RegisterResourceName(dri2DrawableRes, "DRI2Drawable");
<Sarvatt> guess I have to #include "registry.h" in dri2.c too to do that? this is a bit over my head, need someone else to look at it :)
<ricotz> Sarvatt, seen this? https://bugs.freedesktop.org/show_bug.cgi?id=26394
<ubottu> Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,Assigned]
<bryceh> heya
<NinoScript> Is this the appropiate place to ask about an xmodmap issue?
<Sarvatt> ok try 4! hopefully this one works, found another dri2 commit that was changing things slightly in the way - http://sarvatt.com/downloads/patches/119_dri2_drawables.patch
<Sarvatt> heyo bryceh!
<bryceh> heya Sarvatt, how goes?
<apw> bryceh, whats the gen on this DVI detect issue 
<Sarvatt> just fighting this dri2 fix backport :)
<bryceh> apw, gen which?
<bryceh> apw, good morning :-)
<apw> whats the story on that twin dvi issue
<apw> is there any work around for it?
<apw> morning :)
<Sarvatt> nomodeset :)
<bryceh> apw, was there a patch on the upstream bug report?  I forget
<apw> yeah i was wondering how bad things are, if there was a workaround, seems nomodeset at least
<apw> so it can likely wait for an SRU kernel
<bryceh> apw, yeah
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/bugs/+build/1700415 -- if that fails i'm at a brick wall pretty much, it depends on too many big changes 
<bryceh> apw, the bugs I've assigned your way recently were ones that looked like they had a reasonable fix that could be considered for SRU
<bryceh> apw, at this point I'm assuming it's basically too late for Lucid
<apw> bryceh, yeah i don't think we'll get a new kernel in a hurry before release
<apw> after release we may be able to do something more, as this is an LTS and we can SRU h/w support etc
 * bryceh nods
<bryceh> so yeah, don't stress over the ones I sent your way, I just wanted to be sure they didn't get lost in the shuffle since they looked sru-worthy
<Sarvatt> making RS600 use modeset=0 is pretty important too since its entirely broken, but luckily thats one of the rarest ATI's out there
<Sarvatt> except dell used it in latitude XT's :(
<bryceh> Sarvatt, do we have a bug # on that one?
<Sarvatt> dont have one handy but i'll look in a bit, there are 2 bugs, one register wasn't getting set up right making KMS not work at all, then there was a agp bug with it thats pretty serious even after that
<Sarvatt> both went to stable but stable hasn't updated in weeks and theres probably 50+ ati patches queued by now :)
<bryceh> heh
<bryceh> *sigh*
 * bryceh --> more coffee
<Sarvatt> but dell latitude XT's are completely unbootable without nomodeset at the moment
<NinoScript> Is this the appropiate place to ask about an xmodmap issue?
<Sarvatt> Keybuk and raffi had the problems with those latitude XT's
<Sarvatt> dang thats a lot of mail in my inbox
<Sarvatt> darn apport-collect spam
<Sarvatt> darnit.. http://launchpadlibrarian.net/44910586/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.6-2ubuntu7.4_FAILEDTOBUILD.txt.gz
<bryceh> Sarvatt, ok let me know when you locate a bug # for it.  If nothing else we can add it to ReleaseNotes
<Sarvatt> digging..
<Sarvatt> bryceh: 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> thanks
<Sarvatt> but theres another bug even after that - http://lists.freedesktop.org/archives/dri-devel/2010-April/000094.html
<Sarvatt> (which sounds serious)
<Sarvatt> ohh i'm missing hunks from dri2ext.c
<Sarvatt> must have been removed in another patch
<Sarvatt> DRI2ExtensionInit still has     dri2DrawableRes = CreateNewResourceType(DRI2DrawableGone);
<Sarvatt> yeah I'm stuck, hopefully someone else tries to backport it :)
<bryceh> Sarvatt, ok just spoke with JFo
<bryceh> Sarvatt, so the process for now is if we see bugs that need a kernel patch, just give him a ping
<bryceh> he'll then get it in front of andy or stefan or whomever
<bryceh> I think this'll be better than overwhelming apw with them
<apw> bryce sounds good
<vish> Sarvatt: is the ppa fine to use for the gems bug?  i notice you^ mentioning some problem above.. is it related or different?
<vish> or for a different bug*
<Sarvatt> its the same, i'm trying to backport the fixes that dont have the problem that they only applied to xserver master but i'm not having any luck because of the significant changes done between
<Sarvatt> vish: just disable the 2 glx 1.4 enablement patches and 114 from the xserver patch series, thats the only real option unless someone can backport it
<Sarvatt> 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff
<vish> Sarvatt: hmm , well , let me know when it is safe to use the ppa :)
<Sarvatt> its not really an upstream problem in the first place since those backports weren't done to 1.7 branch
<vish> for testing
<Sarvatt> vish: its safe because it isnt building and it doesn't look like i'll be able to fix it i'm saying
<vish> :s
<Sarvatt> going to keep trying using that ppa, not going to upload one with those patches dropped there if that's what you mean
<Sarvatt> got too many darn PPA's, trying to find somewhere to put something usable for now
<vish> nah , dropping is not really an option as you pointed out ;)  i can just use the 2ubuntu1 version.. but was just asking to test your fix
<Sarvatt> it is an option if we drop the 2 glx 1.4 enablement patches, the only reason we need the 114 patch is because of those
<Sarvatt> i'll put it in x-updates
<Sarvatt> uploading now
<Sarvatt> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<Sarvatt> going to take awhile though at this rate, crappy cell connection :)
<Sarvatt> oh helps if i dont put my phone under a coat
<Sarvatt> whoa wait, xserver built with my backports
<Sarvatt> 2ubuntu7.5 in the bugs ppa
<Sarvatt> now does it work? :D vish: can ya try https://edge.launchpad.net/~sarvatt/+archive/bugs/+packages ?
<Sarvatt> the patches need some serious review
<Sarvatt> http://sarvatt.com/downloads/patches/119_dri2_drawables.patch
<Sarvatt> and http://sarvatt.com/downloads/patches/120_glx_drop_destroywindow.patch
<vish> Sarvatt: installing , will report back
<Sarvatt> vish: thanks! i wont be able to downgrade and test it until I get home in a few hours since theres a crapload of packages
<Sarvatt> updates https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/565981 with what I can see
<ubottu> Launchpad bug 565981 in xorg-server "[KMS] gem objects not deallocated" [Critical,Confirmed]
<Sarvatt> err updated rather
<sbeattie> is fglrx failing on an upgrade from karmic a known issue? I'm getting a different dpkg-diversion error than in (fixed) bug 552782... dpkg is complaining about overwriting libdri.so with libdri.so.xlibmesa rather than the mismatch on removing the diversion.
<ubottu> Launchpad bug 552782 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: mismatch on package" [High,Fix released] https://launchpad.net/bugs/552782
<Sarvatt> not a good sign he's not back yet :)
<Sarvatt> should have told him to install ppa-purge and sudo ppa-purge -p bugs sarvatt if its broken
<Sarvatt> horribly broken? :)
<Sarvatt> looks like it needs the 4 commits not just the two, ajax just sent a pull request for 1.8 branch for tem, maybe fedora will backport it to fedora 12
<Sarvatt> http://cgit.freedesktop.org/~ajax/xserver/log/?h=glx-fixes-for-1.8
<vish> Sarvatt: doesnt seem good.. i had three freezes in 3 boots could do nothing couldnt enter VT or couldnt even do an SAK
<vish> looks like the freezes/lockups occur with compiz cube desktop switches
<vish> and boot is also delayed , , let me pastebin  the messages
<sbeattie> fglrx failure on karmic to lucid upgrade filed as bug 567425
<ubottu> Launchpad bug 567425 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: rename involves overwriting" [Undecided,New] https://launchpad.net/bugs/567425
<vish> Sarvatt: not the desktop switching , but the windows preview plugin seems to be the problem , if i disable it i'm able to switch desktops , previously when i just hover over the app icon on cairo-dock to switch the desktop , everything just locked
<vish> thats 5 lockups in 5 boots?  or is it 6.. :(  
 * vish downgrades
<BUGabundo> 6 lookups in 5 boots! 
<BUGabundo> yep, stable
<BUGabundo> oh he is gone :)
<bryceh> Sarvatt, it occurs to me that it would be nice to have a way to easily view all linux bugs we've forwarded from the X side... might help in re-locating issues, or to spot dupes or whatever
 * bryceh hmms
<vish> Sarvatt: btw , from the syslogs:  http://paste.ubuntu.com/419425/ http://paste.ubuntu.com/419432/
<vish> from ^   /var/log/messages , rather
<Sarvatt> vish: yeah looks like 2ubuntu7~xup is what you want to fix it then
 * vish tries x-updates
<\vish> Sarvatt: thats bad as well :(  same problem
 * \vish downgrades again
<Sarvatt> vish: sheesh, I didn't even disable the patches
<Sarvatt> oh yeah I did.. hmm
<Sarvatt> ok i disabled them but i had manually edited the 114 patch in, sorry, that was a case of doing too many things at the same time :)
 * vish sleeps... enough reboots for one day ...  ;)
<Sarvatt> fixed one uploading now, I know that'll work because I tested the heck out of it last month with these clutter problems :)
<Sarvatt> looks like i extracted the source package on top of one i had modified already, doh
<Sarvatt> bryceh: that identification string in the xorg log is normal now :)
<Sarvatt> nvidia released a 96.43.17 driver to fix a major problem in lucid making nvidia-96 unusable, seems pretty important we pick that up ASAP
<Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?p=2236176
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-96/+bug/553200
<ubottu> Launchpad bug 553200 in nvidia-graphics-drivers-96 "Mouse and keyboard stop working after selecting user" [High,Fix committed]
<Sarvatt> ah alberto is on the ball with a ppa package :)
<Sarvatt> i wonder if aplattner knows installing the blob from nvidia.com will screw up the system in lucid, he's telling people to in that bug and its getting screwed up :P
<Sarvatt> tormod: sorry, missed your email but no I haven't been building kernels lately because of the kernel-package changes
#ubuntu-x 2010-04-21
<bryceh> Sarvatt, ok thanks... how did that happen?  Never seen my name in an Xorg.0.log before :-)
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=5461b39585e739ed2df0d2200dc657123cfe71ff
<bryceh> humm
<bryceh> wow, I totally do not favor having my email address in everyone's Xorg.0.log
<bryceh> although, if they're putting Maintainer in there, wouldn't that be ubuntu-devel@ or ubuntu-x@ instead?
<jcristau> dpkg-parsechangelog reads it from debian/changelog
<bryceh> jcristau, for what reason is this done?
<RAOF> Where are we at on the gem objects leak?  Sarvatt - you seem to have that in hand.  Do you need any help?
<Sarvatt> RAOF: yes, I threw my hands in the air at the idea of backporting the fix from master to 1.7 branch
<bryceh> so what's our plan?
<bryceh> sounded like we could drop some patches to get it back to working order?
<RAOF> Why do we have GLX 1.4 backported from master, anyway?  I haven't found a justification for that, yet.
<Sarvatt> disabling the glx 1.4 enablement patches if noone can backport it
<bryceh> bbiab
<Sarvatt> bryceh: it's mostly been tjaalton and asac in there for the past month :D
<jcristau> bryceh: the idea was to try to identify our builds vs local custom builds.  probably not that useful.
<RAOF> What do we lose by dropping glx 1.4 support?
<Sarvatt> glx 1.3 and 1.4 support? :D
<RAOF> Right.  Looking at the changelog, GLX 1.4 wasn't in Karmic, so dropping support won't be a regression in a release.
<RAOF> We lose both 1.3 and 1.4 support?
<Sarvatt> yeah 1.3 was the biggie
<RAOF> Again, we clearly didn't have that in Karmic.
<jcristau> RAOF: correct, that went in for server 1.8.
<RAOF> But clutter obviously uses 1.3 if it's available, and we've been testing that codepath for most of lucid.
<Sarvatt> it's kind of broken though, for instance xephyr doesn't work with glx 1.4 even though it claims it does because of the patches so it cant be used for gnome-shell and stuff
<Sarvatt> RAOF: no we haven't, 1.3 support only got added to clutter in 1.2 branch
<Sarvatt> we didn't update that until mid march?
<Sarvatt> and it was broken causing crashes ever since :)
<RAOF> Ok.
<Sarvatt> http://bugzilla.openedhand.com/show_bug.cgi?id=2028
<RAOF> Still, dropping GLX 1.3 support will possibly expose different clutter bugs.
<ubottu> bugzilla.openedhand.com bug 2028 in Core "clutter broken under Xephyr" [Normal,Resolved: wontfix]
<Sarvatt> http://sarvatt.com/downloads/patches/xserver-1.8.0-glxdri2-resource-conversion.patch
<Sarvatt> thats the fix for it for 1.8 branch squashed into 1 commit
<RAOF> Yeah.  Not exactly the trivial fix :/
<jcristau> i think i'll revert the glx 1.4 stuff for debian..
<Sarvatt> ^ best bet by far..
 * Sarvatt is hoping fedora backports it for F-12 since its a problem there too :)
<jcristau> hehe
<RAOF> It sounds like dropping glx 1.4 is the right solution.
<bryceh> I think we need to escalate the issue.  Since it affects clutter we probably shouldn't make a decision here unilaterally
 * bryceh ->> #ubuntu-desktop
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/566324
<ubottu> Launchpad bug 566324 in xorg-server "Xorg crash" [Undecided,Confirmed]
<Sarvatt> yay 845 fun
<bryceh> *sigh* why is it people keep calling these crashes when they're actually freezes?
<Sarvatt> whats the master bug for 8xx being trash?
<bryceh> we don't have one on the X side.  There's one I filed about shutting off KMS but it's probably closed now
<bryceh> er, filed against linux
<bryceh> Sarvatt, there's also a wiki page under X/Bugs/ for the 8xx issues which could probably benefit from your review and polish
<Sarvatt> X/Bugs/Lucidi8xxFreezes
<Sarvatt> This page does not exist yet. You can create a new empty page, or use one of the page templates.
<bryceh> hmm
<Sarvatt> got it
<bryceh> oh, no /Bugs/ in there
<bryceh> let me insert that, one sec
 * bryceh renames to X/Bugs/Lucidi8xxFreezes
<Sarvatt> RAOF: I dont think nomodeset will affect it since intel has DRI2 on UMS
<Sarvatt> jcristau: we're finding lots of problems with clutter 1.2 + glx 1.2 :(
<RAOF> Yeah; it doesn't affect t it.  It doesn make intel unusably slow, though.
<RAOF> As in, multi-second delays between me typing and it appearing on screen
<Sarvatt> but i could be testing wrong, i'm using LIBGL_ALWAYS_INDIRECT=1 to launch things using the server 1.2 glx instead of the client's 1.4
<Sarvatt> RAOF: got any ati's? you can disable KMS and go back to direct glx 1.2 there
<RAOF> I do have an ati.  Sadly, it's in my server box, which is currently in a shipping container somewhere between Sydney and Hobart.
<Sarvatt> mines in my server box missing a HDD sadly as well, go figure :)
<RAOF> rickspencer3: So, there's some good news and some bad news.
<rickspencer3> ok
<rickspencer3> RAOF, go ahead
 * rickspencer3 bracecs
<RAOF> rickspencer3: The good news is that removing the GLX 1.4 backport doesn't affect most of our drivers; intel & ati with kms both support at least GLX 1.3 without that patch.
<rickspencer3> but I thought we were rolling back to 1.2
<RAOF> We are, but to do that we remove the GLX 1.4 backport patch; it skips 1.3
<rickspencer3> anyway, so the bad news?
<Sarvatt> its GLX 1.2 in the server, the client side drivers can do 1.4 with KMS (intel can do 1.4 without KMS too)
<RAOF> The bad news is that this made my initial testing wrong; it looks like disabling GLX 1.4 breaks clutter.
<rickspencer3> fuuuuuuuuu
<RAOF> And by âBreaks clutterâ I mean âSome apps don't render anything, and netbook-launcher doesn't render textâ
<rickspencer3> well ... that's a bit of a deal breaker
<rickspencer3> RAOF, has anyone done any root cause analysis of the memory leak?
<rickspencer3> like tried to figure out and fix *that* bug?
<Sarvatt> so is a 1.5GB a day memory leak and crashing the server when you close a clutter app :(
<rickspencer3> how widespread is this, though?
<rickspencer3> I haven't had any issues like this
<rickspencer3> on my UNE running netbook
<rickspencer3> RAOF, Sarvatt can you guys paste me the link again?
<RAOF> The memory leak?  All the X team seem to be happily reproducing it, and I think ogra was hitting it.
<rickspencer3> the bug #, I mean, can you paste me that?
<RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/565981
<ubottu> Launchpad bug 565981 in xorg-server "[KMS] gem objects not deallocated" [Critical,Confirmed]
<Sarvatt> basically it looks like the xserver patch we picked up is working as intended and just papering over the real problem
<Sarvatt> it's not destroying things that would crash the server
<Sarvatt> making them build up like they are
<Sarvatt> and it has a side effect of not destroying things that wouldn't crash the server too :)
<tjaalton> bryceh: corrected the X/Config page a bit about the xorg.conf.d directories. dunno what to do with Input
<tjaalton> bryceh: also, I need to quit irc for a few weeks, but I'll read emails if you have something :)
<tjaalton> so, hopefully by this time next month my masters thesis is reviewed and accepted.. bye!
<lapion> tormod, I compiled the kernel with a hangcheck set to 300, and kms enabled for i855, it's working fine, btw 2.6.32-19 also worked for 2 days at a time without any crashes
<lapion> but with the -19 I had the clockspeed of the processor set to half its official speed
<Ng> fwiw I've not had any crashes from my 855 laptop, but it only sees light use for an hour or two a day
<Ng> (in lucid I mean, it's been running it since beta1)
<lapion> Ng have you done regular updates ?
<Ng> lapion: I haven't updated it in a week or two because I didn't really want to get the DRI-disabling update to -intel ;)
<lapion> your laptop contains an Intel 855 video chipset, or is your laptop a model 855 of zome brand?
<lapion> What kernel are you using ?
<lapion> Ng, well my laptop was running underclocked ( 1.4 GHZ in stead of 2.8 ghz) on kernel 2.6.32-19 for 3 days all the time compiling and recompiling a kernel, also continually displaying tv from a pcmcia analog tv-card
<lapion> so not really  idle..
<Ng> lapion: it's my spare laptop at home, it's a thinkpad X40 which has the intel 855 chipset
<Ng> I'm not sure offhand which kernel it has
<Ng> my gf uses it to browse the web in the evenings
<lapion> cool.. try doing "uname -a" in a terminal
<Ng> yeah I'm just several miles away from the laptop, it's not a problem of technical proficiency, just immediate proximity ;)
<lapion> it has been running lucid lynx ?
<Ng> yes
<lapion> very cool..
<Dr_Jakob> So I'm trying to figure when the fix for bug 545298 will land?
<ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [High,Fix committed] https://launchpad.net/bugs/545298
<vish> Sarvatt: -xup2 is better :)  hasnt caused problems , I'm also watching out for the memory problem..
<stefanlsd> Im doing the GEM leak test, and after installing the ppa updates, glxinfo still says 1.4
<jcristau> stefanlsd: paste?
<jcristau> it's supposed to say 1.4 client-side
<stefanlsd> glxinfo | grep "GLX version"
<stefanlsd> GLX version: 1.4
<stefanlsd> jcristau: where should i see 1.2 then? following https://wiki.ubuntu.com/X/Testing/GEMLeak
<jcristau> stefanlsd: yeah with the reverted server patch it should say GLX version: 1.2
<Sarvatt> stefanlsd: you're using proprietary drivers
<jcristau> ah, heh, that would do it
<bjsnider> it won't do any good for us evil nvidia users to test the glx patches would it?
<jcristau> no
<Sarvatt> no point because you aren't even using glx from xserver anyway :)
<bjsnider> troo enuff
<lapion> anyone here interesed in getting information out of a running system with it's i915 server crashed ?
<lapion> nvm the window of access has just closed..
<bryceh> lapion, don't think anyone has the bandwidth at the moment
<bryceh> if it's a crash, collect a full backtrace (see http://wiki.ubuntu.com/X/Backtracing)
<bryceh> however maybe by 'crash' you really meant it's 'frozen', so see the freeze page at X/Troubleshooting for what to collect
<lapion> hmm the x-server restarted 6 times. I have 5 xorg logs with a different display number, followed by one Xorg failsafe with the same timestamp. too bad in the meantime the whole system ( even ssh ) froze up..
<lapion> it started out as a crash and ended up being a freeze
<bryceh> if ssh froze you may have a kernel bug instead
<lapion> it is a kernel bug related to the i915 kms.. because it only happens when the kms driver crashes..
<bryceh> ok yeah, then probably you want to pop over and chat with the kernel guys
<bryceh> however, things are down to the wire so people are not focusing so much on new bugs but finishing up ones already reported, so ymmv
<lapion> this a the big i915 bug due to which i855 is blacklisted
<stefanlsd> Sarvatt: aah ok. so this mem leak wouldnt of affected nvidia driver users?
<bryceh> lapion, uhh do you have i855 or i915?
<lapion> i855
<bryceh> oh, yeah we already know about the issues on i855
<bryceh> thought you had an i915 from your original comment
<bryceh> yeah don't bother sending another bug report, this is well known territory
<lapion> that's the driver.
<lapion> btw, while using the lucid lynx beta2 disc, activating dual screen mode gives black screens with mouse cursor, 5 out of 6 times
<lapion> both screens blacked out.. this is on a different laptop with an Intel  945GM/GMS, 943/940GML
<vish> Sarvatt: no problems of memory leak , but is this ok?: $ cat /sys/kernel/debug/dri/0/gem_objects
<vish> 2519 objects
<vish> 127299584 object bytes
<vish> thats with -xup2
<hyperair> 2519 sounds fine.
<hyperair> speaking as one of the victims of the i965 leak in jaunty.
<hyperair> and karmic, come to think of it. that's why i'm still running xorg-edgers and custom kernels.
<Sarvatt> vish: 127MB is perfectly reasonable
<vish> \o/ ..
<Sarvatt> vish: can you try running netbook-launcher, and any clutter app you can think of to see if there are any problems?
<vish> Sarvatt: i dont use the netbook launcher.. will quadrapassel do?
<Sarvatt> and also try when booting with nomodeset since it'll use DRI1 on your radeon and have a lower client glx version
<vish> Sarvatt: i'm already using new_poll=0
<Sarvatt> i'm working on setting up a radeon machine for testing
<vish> Sarvatt: hmm , will opening quadrapassel crash X now ? [checking first ;)]
<Sarvatt> yeah that just changes the way it picks timings and stuff, with KMS you wouldn't really see a difference dropping the glx version unless you were going through indirect rendering because clients could still be 1.4
<Sarvatt> except on intel where you get DRI2 with UMS too
<Sarvatt> no it wont
<vish> oops , got caught up playing .. :D
<vish> Sarvatt: no problems with quadrapassel
<genii> Is GEMLeak testing under nv driver in 64 bit needed? https://wiki.ubuntu.com/X/Testing/GEMLeak so far has none listed
<paul__> lo
<Sarvatt> tormod: dh_strip does have -s --remaining-packages options if you didn't see it, generic debhelper ones
<paul__> are there still some 'regression' bugs in lucid that you are aware of causing x server to segafult on start?
<tormod> Sarvatt, oh thanks I forgot the generic dh ones
<tormod> so why doesn't it work there then? :)
<paul__> nvidia card, InitOutput in the bt, and non-match symbols (which I gather was just being discussed on -devel)
<tormod> so the dh_strip wrapper in pkg_create_dbgsym does not use --remaining-packages ...
<Sarvatt> maybe pkg-create-dbgsym should use the real dh_strip in the case that packages actually have -dbg packages?
<bryceh> heya Sarvatt
<Sarvatt> heyo!
<paul__> if anyone looks at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/568079, and needs any more information to diagnose the issue, let me know.
<ubottu> Launchpad bug 568079 in xorg "[Lucid] X server crashes on start" [Undecided,New]
<Sarvatt> dropping the glx patches has fixed 2 bugs I've seen so far with swrast as well as the memory leaks :D
<Sarvatt> oh I missed the discussion on the gem object leak bug because I've been testing all day, better reply to those
<tormod> bryceh,  I updated the savage mesa SRU description a bit
<bryceh> tormod, great thanks
<jg> bryceh: I sorta gather that the chance of having a working RS600 driver soon is between epsilon and zero, given what I see going on...
<tormod> in our wiki we have https://wiki.ubuntu.com/X/Config/Input and https://wiki.ubuntu.com/X/InputConfiguration
<tormod> esp the first is wrong about 10.04
<bryceh> jg, due to the stage we're in for the release things are pretty tightly frozen; what we're prioritizing attention to are bugs where we have patches already identified, that need shepherding to get incorporated post-release as SRUs
<tormod> the second says (correctly AFAIK): Note: The x11_options properties are not supported in Ubuntu 10.04. Use xorg.conf.d snippets instead.
<Sarvatt> where does nvidia-settings save its settings again?
<bryceh> I recall seeing a kernel patch go across the board for RS600 earlier that I passed along to the kernel team, but I don't have track of where things are there
<bryceh> jg, I do know the kernel team is already working on the post-release kernel update so maybe it'll be included there
<bryceh> Sarvatt, does it save anything anywhere other than xorg.conf?
<Sarvatt> yeah all the settings like hue adjustments and stuff
<bryceh> Sarvatt, that I don't know; perhaps there is a dotfile in the home dir, like dri uses?
<Sarvatt> jg: do you have a bug? i pointed out the fix on someone elses bug to get KMS to work at all but there are still problems not fixed upstream yet since thats basically the rarest ATI GPU out there, AMD pulled them all from the market after the ATI/AMD merger 
<paul__> Sarvatt/bryceh: do you know if what I've just reported in 568079 is known/on the rader or a new issue?
<paul__> before I head out and leave you guys to it :)
<jg> Sarvatt: I can enter another bug if you like; but it sounded like it was already in the system...
<jg> Sarvatt: I have a nice, new, Intel graphics based laptop on order, so it is about to become moot for me personally, though it would be sort of nice if someday that tablet machine might be usable again.
<Sarvatt> jg: found it https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
<ubottu> Launchpad bug 544590 in linux "[RS600] video freeze with KMS (X and plymouth) (upstream patches available)" [High,Triaged]
<Sarvatt> i've been poking people about the problem for the past few weeks, trying to get it in as a SRU though for sure
<Sarvatt> if you had a bug it would help because they'll need testing the justify it and its a super rare GPU
<Sarvatt> or just clicking this affects me too even
<jg> Sarvatt: do you want me to just chime in on that bug?
<Sarvatt> please, yeah
<jg> ok.
<bryceh> paul__, I don't think it's on anyone's radar.  Not really enough info in that bug report to look into it
<bryceh> paul__, would need a full backtrace as a minimum.  You'll probably get an automated response to collect that at some point.
<paul__> the debug symbols don't match ;/
<paul__> (There's a bug on that ;/
<Sarvatt> sorry paul__, i've got 10 important things going on at once and haven't had a chance to look at it yet :(
<paul__> np
<jg> Sarvatt: done.
<bjsnider> Sarvatt, there's a file i think called ~/.nvidia-settings.rc
<bjsnider> something like that
<bjsnider> nvidia-settings-rc
<Sarvatt> jg: thanks, if you need an immediate fix adding radeon.modeset=0 (or just nomodeset) will make it work
<bryceh> yeah I think we're all pretty swamped at the moment manhandling existing bugs towards solutions, we're quite short on bandwidth to look at new bug reports, and probably are only going to be able to look into ones where someone's done the legwork to identify a patch already
<bryceh> wish we had more bug triagers right now
 * paul__ nods
<paul__> kinda why I spent some time trying to find the right place to idle
<jg> Sarvatt: I tried that; no luck.  in beta 1 I could do an install, and work around; in beta 2, I couldn't even do the work around.
<Sarvatt> bjsnider: THANKS thats exactly what I was looking for, I thought it was in a .nvidia-something directory
<paul__> otoh, it's fairly old hardware
<Sarvatt> jg: yeah it wouldn't work in beta 2 but it will with a current livecd
<bryceh> paul__, there's a plentitude of docs at http://wiki.ubuntu.com/X/ for debugging/troubleshooting/etc. problems
<paul__> warning: the debug information found in "/usr/lib/debug/usr/lib/xorg/modules/libshadowfb.so" does not match "/usr/lib/xorg/modules/libshadowfb.so" (CRC mismatch)
<Sarvatt> because in beta 2 it was installing a modprobe conf to force modeset=1 
<paul__> whilst the debug symbols don't match
<paul__> i'm kinda assuming those docs are gonna be pointless :)
<Sarvatt> paul__: can you try installing the xserver in x-updates? the -dbg packages in there will work properly
<jg> Sarvatt: ah, ok.  as I've come down with a cold, I think I will just hope the new laptop shows up and duck for now, at least until I'm feeling better.
<paul__> will do (i'll go google for how to do that)
<Sarvatt> paul__: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<Sarvatt> paul__: the rest of the info on this page does not apply but the installation and removal sections on here will tell you how to set it up - https://wiki.ubuntu.com/X/Testing/GEMLeak
<bjsnider> Sarvatt, is there or was there a bug with installing the 32-bit libvdpau driver in nvidia-current on 32-bit systems?
<paul__> thanks - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/568079
<ubottu> Launchpad bug 568079 in xorg "[Lucid] X server crashes on start" [Undecided,New]
<Sarvatt> afraid I have no idea on that one, I saw a ton of bugs with nvidia-whatever-libvdpau upgrade problems from people using ppa versions though
<paul__> hopefully that's slightly more useful for osmeone at some point
<Sarvatt> oh wow, a TNT2 vanta
<paul__> it's an old box
<paul__> that just acts as router
<paul__> and dev box
<paul__> if it's too old to care about, say and i'll just buy a new dev box
<paul__> More reporting it in case there's a more serious issue somewhere ;p
<Sarvatt> paul__: try booting with nouveau.sodoff=1 to see if it works?
<bryceh> Sarvatt, huh, your memory leak bug is on slashdot and phoronix
<Sarvatt> oh fun
 * Sarvatt turns off VPS so it doesn't explode
<bryceh> so expect tons of people to show up and help
<bryceh> oh wait
<bryceh> expect an avalanche of peanuts ;-)
<paul__> that's a kernel boot option I assume?
 * paul__ wonders if he wants to reboot his router ATM
<Sarvatt> paul__: you just want to start X to use it remotely? have you tried just using vesa?
<paul__> nope
<paul__> yes, just remotely, vesa no
<paul__> I can reboot the box after adding nouveau.sodoff=1, but i'd need to add that to grub's config
<Sarvatt> i wouldn't put it past it being caused by there being no connectors so nouveau doesn't set up an output then vga16fb gladly loads and is screwing things up
<paul__> I could probably plug in a monitor later to test that theory
<paul__> in terms of  nouveau.sodoff=1
<paul__> would that just need to go at the end of a kernel line in grub's config?
<Sarvatt> it would go right after quiet splash
<Sarvatt> that will just make nouveau not load at all
<paul__> brb
<paul__> yea nouveau.sodoff=1 works
<bjsnider> Sarvatt, i think the 32-bit nvidia-current tries to create symlinks to the /usr/lib32 vdpau driver, which isn't installed unless you're on amd64
<Sarvatt> paul__: knowing if it works with a monitor plugged in or only happens with no monitor would be useful if you ever get around to testing that (without that nouveau.sodoff)
<paul__> yea, will test tomorrow
<paul__> i'll idle here over night to remind me
<paul__> :)
<Sarvatt> wouldn't be surprised if that GPU was messed up with nouveau in the first place and needs blacklisting but you're the first to report a bug about it :)
<paul__> hah
<paul__> a p3 box works for giving me gcc+gdb and a command line :)
<paul__> kinda forget how old it is;p
<Sarvatt> I remember paying $149 for my TNT vanta for a 486 machine ages ago, thats why it surprised me because I had one at some point :)
<paul__> http://dnmouse.org/forum/viewtopic.php?f=3&t=65
<paul__> reading that (unsupported list) and a 2006 post listing vanta as supported
<paul__> I wonder if they dropped support
<paul__> for old cards
<Sarvatt> it says unsupported?
<paul__> on that forum yes
<paul__> http://forums.fedoraforum.org/showthread.php?t=204752
<Sarvatt> unfortunately there are no binary drivers you can use on your card, they stopped updating the 71.xx series that worked with your card
<Sarvatt> if it's headless and just used remotely though it shouldn't matter what you use?
<paul__> what I have atm with nouveau.sodoff=1 I think works for what I do
<paul__> so yea
<paul__> gn thanks 
<Sarvatt> no worries, will update the bug if i find anything
<RAOF> Sarvatt: Good morning.
<Sarvatt> heyo RAOF!
<RAOF> Sarvatt: What's up? :)
#ubuntu-x 2010-04-22
<Sarvatt> talking in traffic so not really here yet, sorry :P
<RAOF> I hope you're not IRCing while driving :)
<bryceh> heya RAOF
<RAOF> bryceh: Good morning.
<bryceh> RAOF, phoronix and slashdot are full of opinion about our little memory bug this morning
<bryceh> RAOF, some light reading while you enjoy your coffee/tea ;-)
<RAOF> I'd prefer to read the X sources :)
<bryceh> smart man!
<RAOF> I've got a theory that the leak is because GLX resources allocated with glXCreateWindow (a GLX 1.3 call) have a different XID to their associated X window and thus fall through the cleanup-cracks.
<RAOF> Without the guard in the 114 patch, that means that crash.  With the guard, that means that we don't clean them up.
<bryceh> mm
<bryceh> so, it looks like drawable->pDraw is defined but not always a valid pointer
<bryceh> so without 114, that leads to a crash when it's destroyed
<bryceh> with patch 114, it doesn't depend on drawable->pDraw being defined, and does a dixLookupDrawable to retrieve it
<bryceh> and then only frees drawable->pDraw when it can get a successful lookup
<bryceh> however, this means that for the case where drawable->pDraw is valid but not look-uppable, those aren't getting freed, and leak memory
<RAOF> Right.
<bryceh> so what I'm wondering is if this particular case can be detected and accounted for in some other way
<RAOF> It should be possible to do that.
<bryceh> (catching up on the upstream bug report)
<bryceh> lesson learned here, don't consider a bug fixed if the upstream report is still open with ongoing discussion......
<RAOF> :)
<bryceh> boy this is kind of hard to follow
<bryceh> RAOF, this appears to jibe with your theory:  https://bugs.freedesktop.org/attachment.cgi?id=34730
<bryceh> ok
<bryceh> RAOF, Sarvatt, here's my take
<bryceh> if we want to keep patch 114, we should test reverting 120286aef59dabdb7c9fa762e08457e5cc8ec3a6
<bryceh> it sounds like patch 114 obviates the need for 120286ae, from the bug discussion
<bryceh> that's option 1
<bryceh> option 2 is to drop patch 114, and instead pull/backport the patches that went upstream
<bryceh> that is, patches https://bugs.freedesktop.org/attachment.cgi?id=35005 and https://bugs.freedesktop.org/attachment.cgi?id=35006
<bryceh> hmm, actually the latter may be the same as reverting 120286ae actually
<bryceh> aha yes
<bryceh> RAOF, Sarvatt, have either of you tested with patch 114 and https://bugs.freedesktop.org/attachment.cgi?id=35006 ?
<bryceh> that might be the least invasive approach
<bryceh> (if it works!)
<RAOF> bryceh: I see no way in which that could resolve the memory leak?
<bryceh> as I understand it, that glxDestroyWindow() call is what generates the dangling pointer
<bryceh> iow, if that stops doing what it's doing, then patch 114 should be able to successfully clear the objects without causing leaks
<bryceh> however my grokkage of this is really low
<bryceh> anyway, that's my take on it, I could easily be wrong
<bryceh> alright, back to -ati bugs for an hour then EOD for me, but let me know if you guys reach a decision on what we should do, and I can push patches or set up sru's accordingly.
<bryceh> crap, I promised to do some MT stuff today, too.  Hmm, -ati then MT, then EOD.
<Sarvatt> bryceh: did you see that dropping the glx 1.4 patches also fixes all clutter apps failing to start with swrast? https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/561734
<ubottu> Launchpad bug 561734 in gnome-games "quadrapassel doesn't start: Failed to initialise clutter: Unable to select the newly created GLX context" [Medium,Confirmed]
<Sarvatt> that was a plesant surprise when I was testing SIS and nouveau earlier
<bryceh> Sarvatt, no didn't see that
<bryceh> btw in the scrollback I blathered a bit while looking at the usptream bug report.  It looks like testing some of the subsequent patches to the one jesse did (our #114) might scare up a fix
<bryceh> but that said, I'd have nothing against just dropping the three patches
<Sarvatt> the subsequent patches are all early versions of whats upstream though
<bryceh> mm
<bryceh> yeah I didn't check what actually got into the tree
<Sarvatt> there is also a regression already with the upstream patches
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=27767
<ubottu> Freedesktop bug 27767 in Driver/intel "[bisected] bottom panel of gnome desktop is wrong" [Major,New]
<bryceh> yeah I noticed the chatter about subsequent bugs
<bryceh> although didn't see that one in particular
<RAOF> Yeah; it seems the stack of four upstream patches seriously break compiz in particular circumstances.
<Sarvatt> they work fine here oddly enough, i'm using them now
<Sarvatt> but i dont use a bottom bar on this netbook :)
<RAOF> Sarvatt: Have you started two copies of a GLX-using app?  Apparently doing that is likely to cause the second app to appear as a static snapshot of the first in compiz.
<Sarvatt> like 2 glxgears?
<RAOF> I think that f0006aa58f6cf7552a239e169ff6e7e4fda532f4 from master is sufficient to close the leak we have.
<RAOF> Sarvatt: I guess so?
<Sarvatt> 2 running fine
<Sarvatt> 4 running fine
<Sarvatt> trying quadrapassel
<RAOF> There's an additional patch on xorg-devel to fix some corner case with compiz, at least.  Let me find it agian.
<Sarvatt> quadrapassel is screwed up like you said
<Sarvatt> (quadrapassel:7656): Clutter-WARNING **: The required ID of 1723017 does not refer to an existing actor; this usually implies that the pick() of an actor is not correctly implemented or that there is an error in the glReadPixels() implementation of the GL driver.
<Sarvatt> tons of that spammed
<bryceh> RAOF, yeah that looks sensible
<RAOF> I've been running a server with that patch (and 114 dropped); gem objects seem stable, and everything appears to work ;)
<Sarvatt> i must be missing mails from xorg-devel
<RAOF> How does one turn a message ID into a link to the online archives?
 * RAOF smells a *really* useful evolution plugin
<Sarvatt> http://lists.x.org/archives/xorg-devel/2010-April/007663.html
<Sarvatt> ?
<Sarvatt> yeah thats not in my xorg-devel list, what the heck
<Sarvatt> ah spam folder, go figure
<RAOF> Hm.  That's not the one I was thinking of, either.
<Sarvatt> hmm yeah
<RAOF> http://lists.x.org/archives/xorg-devel/2010-April/007554.html is what I was after
<RAOF> Anyway, you can reproduce craziness with quadrapassel
<Sarvatt> yup
<RAOF> Given that patch series is still receiving follow-ups like this it's clear that they won't be suitable for Lucid for a while, if ever.
 * RAOF also wants a âmark thread as uninterestingâ plugin
<bryceh> I wrote something for mutt to do that
<bryceh> store the message-ids when thread is marked uninteresting, then when new mail comes in check the reply-to to see if it matches any in the to-ignore message-id list
<RAOF> Sarvatt: Also, why not do this here? :)
<Sarvatt> oh boy the memory leak bug is starting to show signs of becoming the me-too bug for memory problems :)
<RAOF> I can't imagine whyever for! :D
<Sarvatt> probably should make it clear that a sure sign you are affected by the memory leak is 1GB+ object bytes or something, because some people are saying there's a leak with 280MB thats normal and is most likely a driver problem instead (like Conn O'Griofa's report)
<Sarvatt> ah just realized I marked Yes under the bug fixed column even though the bug isn't here originally for SIS and nouveau, meant to imply I did not have any problems with it
<Sarvatt> there, updated the wiki
<Sarvatt> well whenever it goes through :)
<Sarvatt> tried to make it clear what was considered as having this specific bug, and ask for testing by people who aren't experiencing it as well
<Sarvatt> so what combination of patches need testing? f0006aa58f6cf7552a239e169ff6e7e4fda532f4 on top of the current lucid?
<RAOF> Drop 114 from current lucid, replace with f0000
<RAOF> I'll upload that to a PPA now.
<RAOF> Nouveau doesn't seem adversely affected by rolling back GLX, as expected.
<Sarvatt> yeah, only positively affected since clutter works again :)
<RAOF> :)
<Sarvatt> darn, fresh install reminded me that https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/510059 was still a problem after a year
<ubottu> Launchpad bug 510059 in gvfs "Gvfs keeps asking for password when trying to mount Samba share" [Low,Confirmed]
<Sarvatt> RAOF: shoot me links to anything you want me to try to break, will test them out tomorrow on a bunch of machines since I have some free time for a change :) night!
<virtuald> does this mean 10.04 won't ever have GLX 1.4?
<RAOF> Not necessarily, and that's not necessarily what you think it is.
<RAOF> Sarvatt: I'll point you at https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa for your âcan we get both GLX 1.4 *and* an X server that doesn't leak like a sieveâ delectation.
<RAOF> Ok.  I've managed to convince myself that f0006aa58f6cf7552a239e169ff6e7e4fda532f4 does the right thing.  That's applied to xorg-server 2:1.7.6-2ubuntu7~xtesting~dri2fixes in https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa.
<RAOF> Feel free to test that, everyone.  I won't put it on the GEMLeak page yet, because I think dropping the GLX patches is safer, but we might want to pull this in later.
<RAOF> Good night, all!
<Dr_Jakob> Terribly sorry for nagging but I'm trying to figure out when the fix for bug 545298 will land in the debs? Will it make it into the RC?
<ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [High,Fix committed] https://launchpad.net/bugs/545298
<bjsnider> tseliot, someone cam into the +1 channel last night, said he'd clean installed the beta 2 i386 cd, and when he tried to install nvidia-current, this happened: http://pastebin.com/xe0Wp3pk
<tseliot> bjsnider: I don't see any real error there. He should try a daily image instead of the beta
<bjsnider> well, the error is that it's trying to apply links to some 32-bit libs that aren't installed on i386
<eax> Hi there - I have a problem with my Nvidia FX5600 -  I cannot chose other resolutions than 320x240 and 640x480. What can I do to run the correct resolution? Using the nvidia controlpanel this is..
<tseliot> your /var/log/Xorg.0.log should tell you what's going on
<eax> What should I be looking for? It seems like it is loading "nvidia-auto-select" and then "Virtual screen size determined to be 640 x 480"
 * Ng idly wonders if either of the potential GEM leak fixes means DRI can come back on 855 :D
<tseliot> eax: if put it on pastebin I'll have a look at it
<eax> tseliot: Sure one moment :)
<eax> tseliot: pastebin.org/168054
<tseliot> eax: it can't read the EDID of your monitor. This is why it doesn't know what resolutions are available
<eax> tseliot: How can I fix that? :)
<eax> It might be because it's an old CRT monitor?
<tseliot> eax: what resolution would you like to use?
<eax> An old IBM P77
<eax> 1280x1024:)
<tseliot> eax: what's the refresh rate?
<eax> tseliot: 75 I mean
<tseliot> eax: and what's the output of this command? gtf 1280 1024 75
<eax> Tseliot: Output is:   # 1280x1024 @ 75.00 Hz (GTF) hsync: 80.17 kHz; pclk: 138.54 MHz
<eax>   Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
<eax> Tseliot?
<apw> bryceh, hey you have nvidia h/w ... could you confirm that nomodeset and noveau.modeset=0 still work on the -rc kernel?
<tseliot> eax: sorry, I was on the phone
<apw> someone is claiming they don't but i cannot test
<eax> tseliot: Perfectly all right :)
<tseliot> eax: can I see your xorg.conf?
<tseliot> /etc/X11/xorg.conf
<eax> tseliot: Sorry, 1 moment :)
<eax> tseliot: http://eax.dk/xorg.conf
<tseliot> eax: ok, I think I can give you a modified version of your xorg.conf which might solve your problem
<eax> tseliot: Great! Thanks :D
<eax> Tseliot: How's it going? :)
<tseliot> I'm working on it (actually I'm working on multiple things at the same time)
<eax> Tseliot: Cool thanks :)
<tseliot> eax: try with something like this: http://pastebin.ubuntu.com/420496/
<eax> tseliot: Thanks! :) Trying now
<tseliot> and restart the xserver
<eax> Yeah thanks :)
<eax> tseliot: Didn't fix it :( I still cannot select 1280x1024 in the nvidia settings manager :/
<tseliot> eax: can I see the new log, please?
<eax> tseliot: http://pastebin.org/168139
<tseliot> eax: how many screens are you using?
<eax> tseliot: Two, but the second one is an LCD that works when activated :)
<tseliot> eax: aah, I think I know what's going on
<eax> tseliot: Yes? :)
<tseliot> one sec
<tseliot> eax: actually, I was wrong. You might have better luck asking here: www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14
<tseliot> it might be a bug in driver 173
<eax> Hey, sorry about that my internet connection crashed :S
<tseliot> eax: actually, I was wrong. You might have better luck asking here: www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14
<tseliot> (06:12:56 PM) tseliot: it might be a bug in driver 173
<eax> tseliot: Okay thanks :)
<tseliot> this is what you might have missed ^^
<tseliot> np
<eax> Yeah I missed that :)
<eax> Okay, thanks a lot for your help :)
<lotia> greetings all. any need for more reports (will likely be negative) from people using the x-updates x-swat ppa with proprietary drivers.
<bryceh> lotia, nope
<lotia> bryceh: thanks
<lotia> i do have a machine using the nouveau driver, but I can't enable compiz with it. will any info from that be useful?
<bryceh> lotia, maybe, although since it doesn't have 3D it's not expected to have the bug
<bryceh> lotia, go ahead and test it and report what you find to RAOF
<lotia> bryceh: RAOF? apologies. is that a nick or something else?
<bryceh> lotia, nick
<bryceh> lotia, he should be online within a couple hours
<lotia> bryceh: thanks again.
<rye> hi, just installed nvidia-current in current lucid and it appears that libglx was not updated/fixed via alternatives - is that supposed to be so?
<Sarvatt> did you install it via jockey?
<Sarvatt> bryceh: do we have notes on how to install blob drivers outside of X anywhere since its so specific and broken if you do it via a package manager?
<bryceh> Sarvatt, don't think we've got official docs on that
<Sarvatt> rye: if you installed it outside of jockey you need to sudo update-alternatives --config gl_conf, pick the one for the nvidia drivers you have installed, then sudo ldconfig and sudo nvidia-xconfig as the last step
<Sarvatt> or do the easier method of just sudo apt-get purge nvidia-current, then activate them in hardware drivers or use sudo jockey-text -e xorg:nvidia_current
<bryceh> Sarvatt, basically I think you have to uninstall the packaged nvidia completely first, then you can use the nvidia installer
<bryceh> we don't support upgrading from one to the other.  breakage happens.
<Sarvatt> bryceh: its more that you cant install the nvidia drivers via sudo apt-get install nvidia-current for instance
<Sarvatt> all of the alternatives configuration is done by jockey..
<bryceh> Sarvatt, ah
<bryceh> huh, I thought the alternatives handling was done in the postinst?
<Sarvatt> i wouldn't complain about it so much if it was :)
<bryceh> Sarvatt, have you spoken with tseliot about this?
<rye> Sarvatt, hm, when i started jockey I was not prompted to install any proprietary drivers at all, therefore i installed nvidia-current manually
<Sarvatt> bryceh: yeah but I couldn't get ahold of him when he wasn't busy
<Sarvatt> rye: sounds like you did a sudo apt-get purge nvidia-* at some point in the past, just reinstall nvidia-common
<tormod> Sarvatt, with xorg-testing xserver -6 I got a server crash after closing quadrapassel
<Sarvatt> xserver-6?
<tormod> 2:1.8.0+git20100419+server-1.8-branch.7d5e6012-0ubuntu0sarvatt6
<Sarvatt> interesting, so its not even fixed upstream? i've closed it at least 50 times over the past few days with no crashes on intel
<Sarvatt> i'm about to update it from git, maybe the squashed patch I have is different
<Sarvatt> just put everything in the main xorg-edgers PPA
<lapion> I have a system with a frozen i915 driver and am logged in thru ssh, can anyone tell me what information I should gather before the terminal freezes up as well ?
<bryceh> heh, I think we have more x freeze bug reports than we're likely to be able to look at
<bryceh> lapion, there's guides at wiki.ubuntu.com/X if you want to troubleshoot the bug yourself
<lapion> http://pastebin.com/01rSnYQA
<tormod> looks like the PPA builders spend 10 minutes on installing updates and dependencies before they get to debian/rules build, is this normal?
<tormod> build needed 55s :)
<Sarvatt> tormod: yup, thank dpkg for being extra slow now :)
<tormod> oh yes, it is syncing all the time, like firefox
<Sarvatt> 13 minutes+ to install update the few base files for an x11proto package, 30 seconds to build it
<tormod> can't they leave the syncing business to the OS damnit?
<Sarvatt> still *nowhere* near as slow as yum so I can't complain about the extra safeguards :)
<bigjools> the chroots prob need updating, then it will be quicker
<rye> Sarvatt, thanks, i removed nvidia-common completely before to test nouveau with my setup. Given that it now starts up with more than one display I decided to return to nvidia until further notice on that bug report is found. Installed nvidia-common and jockey became helpful. Thanks again!
<Sarvatt> muahaha got my eye on you mozilla daily team - https://edge.launchpad.net/ubuntu/+ppas
<tormod> you're closing in :)
 * ilmari loves the description of xorg-edgers
<RAOF> The GEMLeak page is looking reassuringly green.
<bryceh> RAOF, I've slapped a couple package downgrades into x-retro
<RAOF> bryceh: For 8xx users?
<bryceh> yeah an -intel for them, and an -ati for some of the recent corruption bugs
<bryceh> RAOF, also ran across bug #565903
<ubottu> Launchpad bug 565903 in xserver-xorg-video-ati "graphics corruption opening windows with glx 1.4 (ok with glx 1.2)" [Medium,Triaged] https://launchpad.net/bugs/565903
<bryceh> RAOF, guessing that even if we fix that freeze there may still be some bugs
<RAOF> That not an unreasonable guess :)
<bryceh> fwiw, compared with past releases it feels like we have a higher proportion of graphics corruption bugs than usual
<RAOF> Does that mean that we're getting more graphics corruption, or less wholesale crashes? :)
<bryceh> well, I'd been guessing the latter, but after seeing 565903 now it is making me wonder
#ubuntu-x 2010-04-23
<bryceh> RAOF, I've committed the glx revert to git; shall I go ahead and upload for pitti to review?
<skimj> Is it possible to set a conditional umask based on a regex? So that if a file is created with a name matching pattern A it gets permissions X but if it matches pattern B it gets permissions Y?
<RAOF> bryceh: Yes please.
<bryceh> skimj, wrong channel, this is for X.org discussion
<skimj> oops sorry.
<skimj> wrong tab
<bryceh> RAOF, ok xserver uploading
<Sarvatt> \o/
<bryceh> will be nice having that one put to bed.  hope there's no serious side effects
<bryceh> [ubuntu/lucid] xorg-server 2:1.7.6-2ubuntu7 (Waiting for approval)  
<RAOF> We've got a contingency plan in the first upstream commit of the glx-as-resource refactor.
<bryceh> right :-)
<Sarvatt> bryceh: fixed up that intel 2.8 you put in the retro ppa, backported all of the commits it needed to build against xserver 1.7. but I think you got the versions confused because EXA was ripped out before 2.8 :)
<Sarvatt> it actually builds against xserver 1.8 too, going to try it out for the heck of it
<Sarvatt> I forgot alllll about the cursor flicker :)
<ryan__> I have a ubuntu ppc problem anyone up for the challenge
<Sarvatt> i believe #ubuntu-ports is the channel you want?
<ryan__> No one in those rooms
<ryan__> I guess I will try again
<Sarvatt> is it X related?
<ryan__> in that my display is limited to 256 in x
<ryan__> any attempts to change the xorg fle causes the system to hang at boot
<RAOF> You're limited to an 8 bit display?
<ryan__> yes and the display option show no other listing in the drop downs
<RAOF> What version of Ubuntu?
<ryan__> 9.04
<ryan__> 9.04 ppc
<Sarvatt> ryan__: ati?
<ryan__> yes i have a imac g3
<ryan__> an
<Sarvatt> the jaunty kernel was screwed up for ppc with ati
<Sarvatt> can you upgrade to karmic?
<ryan__> hmm i had to use a no-video command to install
<Sarvatt> i can't remember the specifics but I had the same problem, the powerpc kernel for jaunty was screwed up though due to some patches brought in just before release
<ryan__> I guess I can try installing 9.1 with the update manager and see wha happens
<Sarvatt> they helped out x86 but screwed up powerpc :(
<Sarvatt> ah you have a rage 128 in that thing
<Sarvatt> ryan__: http://tjworld.net/wiki/Linux/Ubuntu/PowerPC/AppleiMacG3
<Sarvatt> (first hit on google...)
<Sarvatt> the "Bug: Xorg doesn't use high-resolution true-colour mode" section specifically
<ryan__> i have attempted to change the xorg before
<ryan__> any changes cause the boot to freeze
<Sarvatt> openfirmware/yaboot are pains in the butt to use with linux, i have a crazy boot stanza to fix consoles
<ryan__> i then have to escape to a shell
<Sarvatt> (on my ibook)
<Sarvatt> are you booting with nosplash?
<ryan__> so would it be advised to update to 9.1 before attempting changes
<Sarvatt> well the problems I was talking about were limited to radeon I believe, I have a radeon 9200 in my ibook
<ryan__> it boots with splah i suppose
<ryan__> ok weird i was attempting to modify my yaboot file and i show no files in mnt directory
<ryan__> oh
<ryan__> reading up a paragraph
<ryan__> doh
<bjsnider> imac g3 is a bit old
<ryan__> hell yes it is
<ryan__> i was running it for my kids with panther and panther ate it
<ryan__> ok sarvatt i canged the yah boot for no splash screen and odified the xorg i am going to reboot we'll see
<Sarvatt> osx 10.3 ate it? i'm scared how slow even ubuntu is going to run on it :)
<vish> Sarvatt: the xup2 seems stable , but as Conn mentions it seems to grow much slower.. a lot slower :s
<vish> Sarvatt: btw , new_pll=0  still causes jumping screen in new session and guest sessions
<vish> with xup2^
<Sarvatt> that persons problems are more likely specific to ati and low memory systems and not that bug
<vish> ah k..  but the jumping/dancing screen is present with -xup2
<Sarvatt> dont know what you're saying, it was fixed without it and now it isn't?
<Sarvatt> or new_pll=0 didnt really fix it?
<vish> Sarvatt: new_pll=0 did fix the problem .... it is not a problem with the 2ubuntu1 but i get it with -xup2 , i recall it is also a problem with the 2ubuntu5[or the latest lucid stock ] I'll downgrade to the stock as retest
<Sarvatt> i'm confused, you weren't using 2ubuntu1 when you said it was fixed, you were using newer?
<vish> if i use new_pll=0 with 2ubuntu1 , i dont get the problem of the screen freaking out... but if i use the new_pll=0  with -xup2 i get the screen jumping
<skimj> I just got a new(ish) MB with Intel GMA X4500. My xorg log says xvmc is disabled. I've got xorg 2.9, do I need 2.10 to get xvmc or is there something else? It looks like the video is using the i915 driver.
<Sarvatt> i'm confused because there's no way you were using 2ubuntu1 when you tried new_pll because 2ubuntu2-5 were released around the same time as ati 6.13 that you were testing downgrades on?
<Sarvatt> (when you said it was working) just trying  to narrow down where it might be
<Sarvatt> skimj: xvmc is 100% useless but if you want to use it with lucid you need to disable KMS
<Sarvatt> or upgrade to 2.10+ to use it with kms yeah
<skimj> OK. I'll try 2.10. Why do you say it's useless? I'm trying to get mythtv to run without stuttering. I just upgraded the MB (with video) trying to improve things. XvMC seems to be the only thing wrong in any of the logs.
<vish> Sarvatt: hrm... the 2ubuntu1 was because i was downgrading earlier to avoid the memory leak.. I believe it is a problem again after update 2ubuntu3 -> 2ubuntu5 ... I'll test each version and let you know which is the problematic version
<vish> Sarvatt: btw , why isnt new_pll=0 the default for the rv515 cards?  I'm still having to add it to the kernel line
<Sarvatt> 2ubuntu5 is the only real change but i dont see how those could be causing it
<Sarvatt> ask the kernel team :)
<vish> hehe ;)
<Sarvatt> did everything i could short of writing the patches myself, identified what the problem was and what gpu's were affected and brought it up on the kernel list with a list of all reports that need the quirking..
<Sarvatt> maybe you can poke someone since you work for canonical? :)
<Sarvatt> if its really a problem with 2ubunu5 and not with 2ubuntu1 (even though you need new_pll=0 still) thats interesting
<vish> Sarvatt: hmm , i dont work for canonical, but will poke folks :)
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=27510
<ubottu> Freedesktop bug 27510 in Acceleration/EXA "Xorg crashes when right-clicking on NoScript Icon in Firefox" [Major,Resolved: fixed]
<Sarvatt> seems thats hitting a lot of ati users
<Sarvatt> oh bryce already forwarded another report about that
<skimj> Sarvatt: would you be willing to help debug a bit? I added the xorg-edgers ppa and did an upgrade. Now the intel module fails to load. Here's a snippet from the xorg log http://paste.ubuntu.com/420830/
<Sarvatt> you didnt upgrade intel for some reason?
<Sarvatt> you need to update everything in that ppa, it's not compatible with lucid packages
<Sarvatt> it was probably because i didn't upload an xorg metapackage yet and you did a safe upgrade so it didn't remove xserver-xorg-video-all/etc
<Sarvatt> try a sudo apt-get dist-upgrade?
<skimj> so I did an apt-get upgrade which got a lot of things. X failed to load after that so I did an apt-get update ...intel 
<skimj> OK I'll try it with the dist-upgrade.
<Sarvatt> did it say any packages were held back?
<skimj> yes, I've got 4 packages held back
<Sarvatt> which?
<skimj> knm-runtime kopete network-manager-kde plasma-widget-networkmanagement
<Sarvatt> ah not related
<Sarvatt> dist-upgrade offering intel?
<vish> hmm,.. what was the command to downgrade a package , which has the deb in /var/cache/apt/archives?
<skimj> nope. It's offering libmsn0.3, knm-runtime kopete network-manager-kde
<Sarvatt> whats the version on your installed xserver-xorg-video-intel package?
<skimj> 2:2.11.0+git20100422.72fd7d19-0ubuntu0sarvatt2
<Sarvatt> huh
<Sarvatt> did you ever compile intel from source in /usr/local or anything?
<Sarvatt> oh sorry it says /usr/lib/xorg/modules/drivers/intel_drv.so there
<skimj> nope never from source. I did have everything from the ppa installed, then I uninstalled with the ppa-purge tool, and now reinstalled
<Sarvatt> i'm stumped, can you try again and paste the full log?
<skimj> try from reboot?
<Sarvatt> yeah
<Sarvatt> absolutely sure you had 2.11 installed when you booted there?
<Sarvatt> hmm wait
<Sarvatt> why isnt it 2.11.0+git20100422.72fd7d19-0ubuntu0sarvatt3 ?
<skimj> yes, I did. So here's the weird thing. It's working now. The only change was dist-upgrade with knm-runtime kopete network-manager-kde plasma-widget-networkmanagement
<Sarvatt> nevermind thats a local build with pageflipping disabled... :)
<Sarvatt> thats really odd skimj, probably can find out why from your /var/log/apt/term.log
<skimj> if you want to look at the term.log: http://paste.ubuntu.com/420830/
<vish> Sarvatt: how do i downgrade a package to one which is in the /var/.../cache?
<Sarvatt> dpkg -i /path/to/file?
 * vish tries
<Sarvatt> skimj: that was the xorg log snippet link
<Sarvatt> skimj: i've got to run, about to pass out. its all working now though?
<skimj> oops sorry. http://paste.ubuntu.com/420837/
<skimj> yes, it's all working now. Thanks.
<vish> bah didnt work... /me downloads package .. is easier ;)
<Sarvatt> thats really odd, why didnt intel get upgraded there.. you're also missing synaptics
<Sarvatt> skimj: something definitely went funky there, it didn't pull in synaptics either
<skimj> should I do something different?
<Sarvatt> do you have xserver-xorg-input-synaptics installed?
<skimj> I don't see it
<skimj> i just forced it with apt-get install xserver-xorg-input-synaptics
<Sarvatt> install xserver-xorg-video-all and xserver-xorg-input-all?
<Sarvatt> i'll upgrade a bunch of systems tomorrow and see if i can figure out what happened, got me stumped
<skimj> FWIW, that's also pulling in video-ati
<skimj> OK, let me know if I can get you any more info, logs, etc.
<Sarvatt> something tells me the ppa-purge might have messed up, and it fell back to aptitude and offered a solution involving removing some packages
<Sarvatt> must pass out though, sorry for the trouble and thanks for pointing out the problems :)
<Sarvatt> darnit, i just had to start updating another machine to edgers and now i'm back :D bjsnider have you seen any nvidia blob releases that work with xserver 1.8 without IgnoreABI by any chance?
<ricotz> Sarvatt, i think you can include the ia32-lib from https://launchpad.net/~ricotz/+archive/staging/+packages now?
<ricotz> RAOF, hello, or perhaps you can ^
<bjsnider> Sarvatt, which one is xserver 1.8?
<jcristau> eh?
<bjsnider> is that the one in lucid?
<jcristau> no
<jcristau> it's the one in f13
<bjsnider> well, nvidia has to be given a bit of time to update their driver for it i suppose
<jcristau> first release candidate was over 2 months ago.  considering the ABI bump is trivial this time, that should be more than enough...
<bjsnider> i think the hdmi audio issue is a much bigger problem
<bjsnider> it's a longstanding issue that is keeping some people on the 185
<bjsnider> they've had plenty of time to fix that one
<Ng> ooh, I see the gem leak bug is fix committed
<Ng> did we revert the glx backport or just drop in the extra patch RAOF found?
<jcristau> the former afaik
<Sarvatt> bjsnider: the 195 drivers supported xserver 1.8 for months but you need to use IgnoreABI, was just wondering if you had come across any newer betas or anything so I could put them on xorg-edgers but I dont see any
<Alan> Hi, I'm having a problem setting my button map for my mouse
<Alan> I used to set it with a HAL policy, now it looks like i should be seting it with a udev rule
<Alan> I've got the udev rule set up correctly, and "udevadm info ..." shows that x11_options.ButtonMapping is set and correct on my mouse device, however X is completely ignoring this button mapping
<Sarvatt> <jbarnes> on the machines I tested, fbc would get enabled, but actuall take more power
<Sarvatt> <jbarnes> because it never finished a compression pass
<Sarvatt> <jbarnes> a few others reported the same thing
<Sarvatt> <jbarnes> that may be why the feature isn't enabled on windows
 * Sarvatt doesn't feel bad about submitting a patch completely disabling FBC on 915-945 now
<Alan> Ok, so i fixed my problem, it appears that Ubuntu Lucid has already deprecated configuring X with udev?
<Alan> or maybe jsut some aspects?
<Sarvatt> Alan: yeah, udev is used transparently now, you configure things through xorg.conf or xorg.conf.d snippets and it is described pretty well in man xorg.conf
<Sarvatt> i have to run but i can point you to wiki's describing the new world order that is much easier to manage in about 45 minutes
<Alan> Sarvatt: but is it right that it should ignore properties set in udev rules?
<Alan> huh, i just found an article about the new configuration stuff...
<bryceh> Sarvatt, btw do you have much feel for the status of multi-card support (3+ displays) upstream?  I know that's work being done but is it likely to be Meerkat material?
<Sarvatt>  Alan: sorry for the delay, ended up running late. http://fedoraproject.org/wiki/Input_device_configuration is a really good guide, our xorg.conf.d snippets are in /usr/share/X11/xorg.conf.d/ if you want to see whats there currently. if you want to change options you just add an InputClass section to your xorg.conf with the options you want in it
<Sarvatt> err sorry, lucid's are in /usr/lib/X11/xorg.conf.d/
<Sarvatt> i dont know what device you are setting up but for synaptics for instance you can see the full list of options in man synaptics (or synclient -l)
<Sarvatt> bryceh: need to look into it more but from what I know, GPU switching for systems with multiple GPU's yes, multiple GPU's at the same time no way
<Sarvatt> bryceh: you can do 3+ displays on ati 5xxx though with 1 GPU
<bryceh> know if anyone's tested that with an ati 5xxx on lucid?
<Sarvatt> pretty sure lucid can't handle it at all, we dont even have KMS support for them
<Sarvatt> its weirdly limited too, you have to use certain combinations of connectors to do it
<Sarvatt> http://www.botchco.com/agd5f/?p=51 is an *awesome* summary of it
<bryceh> aha thanks
<Sarvatt> i'm sure fglrx can handle it, no experience with it at all though
<Sarvatt> i'm seeing reports of odd problems on 5xxx with stock lucid though, one connector works and the other doesn't, stuff like that
<Sarvatt> pretty sure arrandale/clarkdale can handle 3+ displays too, know i saw a commit from jbarnes mentioning it
<Sarvatt> in the increase the stride limit on igdng commit
<bryceh> mm
<Dr_Jakob> Sarvatt, bryceh: so the packages that are in the repos now will go out on the final iso?
<Sarvatt> Dr_Jakob: your vmmouse fix got uploaded on the 19th, the archive was just frozen for the RC and its in the archive now
<Dr_Jakob> Yeah, I verified that the fix was in the stuff I pulled from the repo.
<Sarvatt> Dr_Jakob: nah there will be more updates that are just major bug fixes no doubt
<Sarvatt> the vmmouse update will be on the daily iso from today, it just isn't in the -rc release cd
<Dr_Jakob> Right, and the final iso will be based on one of the dailies?
<Sarvatt> whatever's in the archive at the time it's made, probably on tuesday? not sure of the exact date
<Sarvatt> bryceh: looks like i was wrong about that commit saying 3 displays was possible - " It can go up to 32k.  Upping this lets me use my 2560x1600 and 1920x1200 monitors in an extended desktop configuration."
<Sarvatt> bryceh: i'm pretty sure you can do displays on multiple GPU's with seperate screens on nvidia with the blob?
<bryceh> yes
<Sarvatt> i've seen a bug about it at least and it needed lots of xorg.conf fiddling
<bryceh> right, with nvidia it's done via xorg.conf-ary
<Sarvatt> think i'll dig through the arrandale docs and see what it has to say :)
<bryceh> the nvidia config program takes care of that a bit
<Dr_Jakob> Ok, thanks. I got a bunch of managers breathing down my neck about this bug.
<Sarvatt> they pulled them off the intel website but i saved copies
<bryceh> I guess there's one thing we can be certain of
<bryceh> when this feature becomes available, in order to integrate it we'll probably have to break everything else
<bryceh> that's just how intel rolls ;-)
<Sarvatt> Dr_Jakob: have you seen the bug where a messed up xkb layout is getting applied from the vmware autoinstaller (?) and the keyboard isn't usable for login?
<Sarvatt> trying to dig it up, it's gotten alot of dupes
<Dr_Jakob> Sarvatt: can't say I have. Do you have a bug number.
<Sarvatt> digging for it
<vish> Sarvatt: the second session ,  screen jumping bug: .. it happens with 2ubuntu1 as well :/  it seems the new_pll=0 only works and keeps thing quite for some time ~6hrs of uptime, then it happens , everything is still jumping :(
<vish> so if you are testing the bug with a fresh boot ,  and try the guest session it wont have a problem , but after ~6hrs the problem arises even with new_pll=0
<Sarvatt> darnit where is it hiding
<Sarvatt> Dr_Jakob: https://bugs.edge.launchpad.net/ubuntu/+source/console-setup/+bug/548891
<ubottu> Ubuntu bug 548891 in console-setup "keyboard input broken due to invalid "SKIP" keyboard model" [High,Confirmed]
<Dr_Jakob> Sarvatt: hmm so we are not hitting this issue as far as I can tell in the beta of the Fusion/Workstation/Player.
<Sarvatt> ah nice, is it publically available? i'll mention that when the next person asks about the problem
<Dr_Jakob> http://communities.vmware.com/community/beta/ws
<Dr_Jakob> Tho looking at the forums, I can see that somebody has reported it.. hmm.
<Dr_Jakob> Oh, its after you update console-setup.
<Sarvatt> btw I plan on enabling svga in the xorg-edgers PPA here soon, it's already enabled in the 10.10 kernel config and I have that in xorg-edgers, just need to package up the libdrm/mesa sides 
<Dr_Jakob> Its totaly unsupported
<Dr_Jakob> Just FYI
<Sarvatt> that's what xorg-edgers is all about :)
<Dr_Jakob> just make sure you have video-vmware version 11.x.y
<Sarvatt> it'll have git master updated whenever i see changes
<Dr_Jakob> right ok good.
<Sarvatt> changes there don't go to the xorg-commit mailing list do they?
<Dr_Jakob> Hmmm
<Dr_Jakob> they do.
<Dr_Jakob> http://lists.freedesktop.org/archives/xorg-commit/2010-February/025157.html
<Sarvatt> ah ok just haven't seen a commit in awhile
<Dr_Jakob> I have been stuck fixing weird input driver bugs ;-)
<Dr_Jakob> Also video-vmware only holds the old video driver and driver selector.
<Dr_Jakob> the 3D enabled driver comes from mesa
<Sarvatt> speaking of which i need to update that in edgers now anyway because of the new abi in there
<Dr_Jakob> Sarvatt: I like to in advance apologies for the circular dependancy between mesa and xorg for when added the X org driver to mesa.
<Sarvatt> yeah I've already been down that road when I was first enabling nouveau gallium and building the xorg state tracker by mistake :)
<Dr_Jakob> Sarvatt: do xorg-edgers ship r300g?
<Sarvatt> it's a work in progress, we've got it in another PPA at the moment trying to work out how to package it
<Dr_Jakob> ok
<Sarvatt> can you give me any tips on packaging gallium dri drivers at the same time as classic dri drivers? for instance i'm unsure what happens when both radeon_dri.so and radeong_dri.so exist at the same time
<Sarvatt> like for nouveau or svga it's no issue to package them together with classic dri
<Sarvatt> too bad tormod isn't here, he's the one most interested in shipping r300g and has been trying to work it out here - https://edge.launchpad.net/~xorg-edgers/+archive/radeon/+packages
<Dr_Jakob> the X driver tells libGL which driver to load, for radeon this is currently "radeon", libGL then adds /path/*_dri.so and dlopens it.
<Dr_Jakob> so just adding radeong_dri.so wont break anything.
<Sarvatt> ah ok so actually having the gallium driver be radeon_dri.so is going to be required
<Dr_Jakob> yeah, or adding a xorg.conf option to tell the driver to say radeong instead of radeon.
<Dr_Jakob> maybe even add it to xorg.conf.d if that works for video drivers.
<Sarvatt> hmm you can specify it to load radeong_dri.so in xorg.conf or just the path to radeon_dri.so? I didn't know that was possible but it would greatly simplify it if you could specify the name and not have to rename things
<Dr_Jakob> You can't now, but it wouldn't be hard to make the driver look obey a "DRIDriverName" option.
<Sarvatt> ah ok I get it now, it'd use radeong_dri if I went and used radeong_drv also
<Dr_Jakob> Hmm dunno, it might be hardcoded to "radeon" inside the driver or the name of the driver.
<BUGabundo> http://www.phoronix.com/vr.php?view=ODE3MA  what's this I read about an X mem leak??
<Sarvatt> BUGabundo: fixed already and didn't affect you on nvidia, it sure was good for ad revenue I'm sure though
<BUGabundo> I bet
<Sarvatt> oh hoh, looks like I might be able to abuse --with-dri-searchpath to have it look in the gallium directory first, then split the gallium drivers out to another package mangling the names that isn't installed by default
<virtuald> there's a newer xorg-server in main that in the x testing ppa
<virtuald> than*
<Sarvatt> virtuald: do you mean x-updates? because the one from there was uploaded to main, its the same thing
<Sarvatt> this --with-dri-searchpath hack just might work :)
<Sarvatt> so i'm thinking build everything at once in the config-dri rules target that has --with-dri-searchpath=/usr/lib/dri-gallium:/usr/lib/dri, only install mesa classic dri (and nouveau/svga) in /usr/lib/dri, copy the gallium dri drivers to /usr/lib/dri-gallium/ with the expected names, and have a seperate libgl1-mesa-dri-gallium (or whatever) package that's optionally installed with the /usr/lib/dri-gallium stuff
<Sarvatt> guess it doesn't matter where nouveau goes, it just works fine in /usr/lib/dri
<Dr_Jakob> sounds good
<Dr_Jakob> Could I request that the vmwgfx_dri.so ends up in the correct place?
<Dr_Jakob> That is /usr/lib/dri
<Sarvatt> ah yeah need to work out how to handle that right since it'll have the _drv.so too right?
<Dr_Jakob> just stuff that into /usr/lib/xorg/modules/drivers/
<Dr_Jakob> vmware_drv.so will then check if your enviroment is sane and load it.
<Dr_Jakob> if not it will fallback to vmwlegacy_drv.so  (renamed vmware_drv.so, the new vmware_drv.so is just a driver picker liker ati_drv.so).
<Sarvatt> yeah whenever I get that together it'd probably be better off in a seperate package installing both anyway
<Dr_Jakob> well the driver picker is quite paraniod about the enviroment (must be able to load vmwgfx_drv.so, must be able to open the drm device) otherwise it falls back to the old driver.
<Sarvatt> yeah i'll make sure it's all in /usr/lib/dri and /usr/lib/xorg/modules/drivers when i do it, nice that you have vmware picking the right one instead of having to patch xf86AutoConfig.c to add vmwgfx :)
<Sarvatt> jcristau: is there any way to give other people access to personal branches on git.debian.org? like if tormod created a mesa packaging branch on there and I wanted to commit to it
<bdmurray> isn't bug 568605 a dup of bug 564181?
<ubottu> Launchpad bug 568605 in linux "ATI radeon KMS driver - gpu lockup" [High,New] https://launchpad.net/bugs/568605
<ubottu> Launchpad bug 564181 in xserver-xorg-video-ati "[RV730] GPU soft reset infinite loop scrolling in firefox with compiz" [High,Triaged] https://launchpad.net/bugs/564181
<bryceh> bdmurray, maybe
<bryceh> bdmurray, with X freezes I've learned from experience not to dupe them together too aggressively
<bryceh> it's better to forward each one upstream and let the experts tell us that they're dupes rather than guess wrongly and lose a bug in the cracks
<bryceh> also even if they are the same bug sometimes having several users investigating them in parallel can make it easier to find the solution since there's more eyes and hands 
<bryceh> once a solution is found, often then it is pretty straightforward to identify dupes via ppa testing
<bryceh> also I hate the "X freezes" me-too bugs of death ;-)
<jcristau> Sarvatt: use acls?
#ubuntu-x 2010-04-24
<Sarvatt> http://sarvatt.com/git/cgit.cgi/mesa/ is a start for now :D
<Sarvatt> ok think libgl1-mesa-dri-gallium is all set to go - http://sarvatt.com/git/cgit.cgi/mesa/
<Sarvatt> package description wording needs some work but oh well :)
<Sarvatt> now to spend a year test building
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/539772 is starting to be the new intel lid close hang bug with tons of duplicates :)
<ubottu> Ubuntu bug 539772 in xserver-xorg-driver-ati "Lucid 2.6.32-16 crashed to login screen - miCopyRegion" [Unknown,Confirmed]
<Sarvatt> finding lots of dupes all over the place
<__mikem> hey Sarvatt what sort of "infrastructure" were you refering to with that PPA package?
<Sarvatt> i need to decide how to package gallium stuff properly first before i dig into vmwgfx
<__mikem> oh
<Sarvatt> is there no howto on google for building vmwgfx?
<__mikem> I loath building stuff from source with a passion
<Sarvatt> i think i found the most useful backtrace ever - http://launchpadlibrarian.net/43423955/ThreadStacktrace.txt
<__mikem> Sarvatt: what will that tell you?
<rafiyr1> So cute, I'm tempted to print it and hang it on the wall.
<tormod> so are clutter apps broken on all non-KMS drivers now?
<tormod> clutter seems to be built on sand
 * tormod wonders why we use clutter in 10.04
<RAOF> tormod: Wait, what!
<tormod> Failed to initialise clutter: Unable to find suitable fbconfig for the GLX context
 * RAOF thinks we use clutter in 10.04 because no-one's written a good 2D-accelerated animation framework yet.
<tormod> we shouldn't use animation then until the graphic stack is ready :)
<RAOF> Sadly, history suggests that the graphics stack won't be ready until we've been breaking it with animation for a release or so :)
<tormod> or just declare that we only support ati/intel/blobs :->
<RAOF> tormod: What driver are you using?  I thought Sarvatt had tested a non-DRI2 driver.
<tormod> savage, worked until yesterday's xserver fix
<RAOF> tormod: Want to try my fixier fix?
<tormod> sure
<RAOF> https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa
<jcristau> tormod: arguably, non-kms drivers aren't part of the graphic stack anymore
<RAOF> It'll need a version bump or manual install; it's now been superceded by the new xserver.
<RAOF> jcristau: That's a pretty aggressive deprecation schedule :)
<jcristau> RAOF: you're saying there's stuff outside of intel/ati/nvidia that's still relevant?
<RAOF> jcristau: None that's current, certainly.
<RAOF> We probably need to make it explicit what old hardware we really care about, though.
<RAOF> We need to be somewhere between âeh, it's old hardware, it doesn't matter if we break itâ and âno hardware that was once supported will ever lose supportâ, and I think we need to make that decision conciously.
<vish> folks, the new_poll=0 quirk for rv515 and rv535 is not a complete fix , it just seems to delay the occurrence of problems by about 5-6hrs
<vish> alteast in rv515 that is , the problems happen in 5-6 hrs ^
<tormod> RAOF, same error with u7~xtesting~dri2fixes
<tormod> granted savage is a special case and recently got some extra patches so it just worked (until now)
<tormod> but does clutter work on other DRI1 drivers now?
<RAOF> It *should* work with dri2fixes.  Or, at worst, should crash when you close the window.
<RAOF> Because dri2fixes was u5, with the patch that caused the leak dropped + a patch to prevent the crash, which only changed the DRI2 code.
<jcristau> the crash on closing the window was in dri2 stuff.
<tormod> I can go back to -u5 just to confirm it
<RAOF> tormod: That might be nice, maybe?
<RAOF> Oh, poot.  That stupid kernel bug has flipped my hdd read only.
<tormod> bollox I get same error on -u5, so I guess it is just savage then, thought I had it working once though...
<tormod> have to say that lucid is not very useful anyway on this laptop, because of the gbloat
 * tormod looks for LXDE
<jcristau> you could try to figure out why it doesn't like savage's fbconfigs i guess
<jcristau> s/it/clutter/
<tormod> I think knarf did that, and we added his patch
<tormod> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/103_savage-expose_fbmodes_with_nonzero_alpha.patch;hb=ubuntu
<tormod> hmm he notes in the bug report savage users have to use 24bit
<tormod> and apparently 16bit is default
<tormod> woohoo quadrapassel works on 24bit
<tormod> maybe we need to release note this
<tormod> I am not so sure defaulting to 24bit on savage is a good idea, it was set to 16bit for a reason
<tormod> RAOF, when forcing 24bit, -u5 works fine, ~dri2fixes crashes after some time
<tormod> (only the app crashes)
<RAOF> Thanks.  Was that what changed?  Does -u5 work with 16bit?
<tormod> no with 16bit (default) neither -u5, drifixes, u7 work
<RAOF> Ok.
<RAOF> There's probably some more evil lurking in the DRI1 + GLX 1.4 codepath.
<tormod> and likely bugs in savage mesa
<tormod> (quadrapassel:4076): Clutter-WARNING **: The required ID of 1060953 does not refer to an existing actor; this usually implies that the pick() of an actor is not correctly implemented or that there is an error in the glReadPixels() implementation of the GL driver.
<RAOF> It's a non-stop cavalcade of lightly-tested code!
<RAOF> That's the dri2fixes error?
<tormod> yes
<RAOF> I suspect I know how to fix that.
<tormod> it starts out with a couple of:
<tormod> (quadrapassel:4076): ClutterGLX-CRITICAL **: Unable to make the stage window 0x3c00040 the current GLX drawable
<RAOF> Yeah, but *everyone's* clutter gives that CRITICAL warning :)
<tormod> looks good ;)
<tormod> with -u7 it spews a lot of messages, but does not crash
<jcristau> there's no dri1 + glx 1.4...
<jcristau> dunno what raof was talking about there
<tormod> I think he meant using DRI1 when the rest of the stack is reworked for GLX1.4
<ricotz> tormod, hello, is the new gallium packaging change the solution for 10.10?
<ricotz> tormod, "/usr/lib32/dri-gallium" should be added to "confflags-dri" for i386 compatibility, so it will be possible to patch the ia32-libs
<bjsnider> Sarvatt, nvidia has released a driver that supports x-server 1.8
<tormod> ricotz, I don't know if any gallium drivers will be ready for 10.10 but maybe r300g
<tormod> but xorg-edgers will make sure people can test it
<tormod> yes, we can add the lib32 path
<tormod> some people have been testing r300g in our radeon gallium ppa since a few weeks and it looks pretty goof
<tormod> *good :)
<ricotz> tormod, ok, or perhaps another solution would be to add a ia32-libs-mesa-dri-gallium package to edgers mesa instead of patching ia32-libs with the same split package
<tormod> ok, I am clueless about 64-bit compatibility, I never had such hw
<ricotz> this is only for compatibilitly issues with precompile gl apps like googleeath, ...
<ricotz> tormod, what is the reason of splitting out gallium to a new deb?
<tormod> so that we can easily ship gallium and classic drivers from the same build and repo
<ricotz> ok, so i think it is better to provide 2 independent debs, which wouldnt required the path juggling
<tormod> in the radeon gallium PPA I have been shipping both in one package, for people to play with LIBGL_DRIVERS_PATH, but that's not n00b-friendly enough
<tormod> and have them conflict against each other?
<ricotz> yes, and the gallium package would provide the real mesa package name
<tormod> I find the path juggling rather elegant :) but again I have experience with 64bit stuff
<tormod> *no experience
<ricotz> ok
<tormod> hmm I wonder if the conflicts would confuse people
<ricotz> this make it a bit harder patching ia32-libs, but its possible
<tormod> anyway with the current way, we should also add some depends and stuff so that reverting from xorg-edgers etc does the right thing
<ricotz> the mesa package is full of conflicts ;-)
<ricotz> ok, i will do some changes to ia32-libs
<tormod> good. I will your suggestion in mind though, I am not against it
<ricotz> tormod, i will adapt ia32-lib to the current packaging in edgers, but the path addition is needed get it to work
<tormod> ricotz, uploaded with path addition now
<ricotz> tormod, taking a bit longer here ;-)
<hyperair> so i hear we can now use intel gallium3d drivers..
<hyperair> is it faster or slower than conventional intel?
<Dr_Jakob> hyperair: slower, and i965g wont work at all.
<hyperair> heh okay, i'll take that as fair warning and keep my distance for now =p
<hyperair> thanks for the info =)
<Dr_Jakob> if you have a i915g and want to play around with drivers please feel free
<Sarvatt> wow, libgl1-mesa-dri-gallium actually works :D
<Sarvatt> thanks tormod!
<Sarvatt> now to document it
<Sarvatt> maybe we should upload an apport that refuses to accept bug reports if libgl1-mesa-dri-gallium is installed just incase :)
<Dr_Jakob> Sarvatt: whats in libgl1-mesa-dri-gallium? Only r300g?
<Sarvatt> i915_dri.so  i965_dri.so  nouveau_dri.so  r300_dri.so  swrastg_dri.so
<Dr_Jakob> heh, you can do without i965_dri.so, not even trivial/tri works.
<Sarvatt> probably a good idea, someone might actually try it :)
<Dr_Jakob> swrastg_dri.so could probably be renamed to swrast_dri.so
<Sarvatt> was fixing that right as you said it :)
<Sarvatt> ah hah, having libmyth-0.22-0 installed in karmic brings in the blob drivers on upgrade to lucid, thats where people were getting the blob installed on non nvidia from still
 * Sarvatt just read the discussion in #ubuntu-devel
<bjsnider> because of vdpau?
<Sarvatt> ricotz: added you as a member, thought you were going to request it through launchpad but you never did :D
<Sarvatt> yeah
<Sarvatt> nvidia-185-libvdpau
<bjsnider> libvdpau1 needs to be altered so it upgrades and replaces those packages
<Sarvatt> yeah for sure
<bjsnider> hahaha
<bjsnider> i just looked at the control file for it, and it does replace the debian versions o those packages, but not the ubuntu versions
<Sarvatt> doh!
<bjsnider> Replaces: nvidia-libvdpau, nvidia-libvdpau1, nvidia-libvdpau-ia32
<bjsnider> and conflicts too
<bjsnider> this is because of the big disconnect between debian and ubuntu over the nvidia blob packaging
<bjsnider> they've gotten too far apart
<bjsnider> !info libvdpau1 lucid
<ubottu> libvdpau1 (source: libvdpau): Video Decode and Presentation API for Unix (libraries). In component main, is optional. Version 0.3-2 (lucid), package size 23 kB, installed size 124 kB
<bjsnider> yeah so if you look at the version, there are no ubuntu changes, it's synced from debian
<ricotz> Sarvatt, oh, thanks, i have asked you awhile ago on irc here ;-)
<Sarvatt> hehe apparently intel responded to someone asking about the lack of GMA500 drivers for linux saying it was up to the distro they are using to fix the problem
<bryceh> !!
<bryceh> Sarvatt, who exactly said that?
<bryceh> got a link?  I should forward that to rick
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-psb/+bug/330906/comments/70
<ubottu> Ubuntu bug 330906 in xserver-xorg-video-psb "MASTER: GMA-500 lacks driver for 8.10 and 9.10 (poulsbo works only on 8.04 and 9.04)" [Wishlist,Won't fix]
<Sarvatt> btw meego has psb support with current userspace :)
<Sarvatt> was digging through all the meego source a week or two ago and saw the mass of patches
<bryceh> hmm, second hand, no names associated with it
<bryceh> oh?
<bryceh> *sigh* meego
<Sarvatt> yup didn't mean to imply it was an official response, sorry
<bryceh> np
<bryceh> would be nice to have those patches in a ppa or something
<Sarvatt> tempted to get a psb machine to work out adding support for it
<bryceh> no
<bryceh> I value your sanity too much.
<bryceh> ;-)
<bryceh> actually would be great to get some -psb owners involved in helping with Ubuntu-X
<bryceh> it's a tough, tough platform to support
<bryceh> er, s/platform/driver/
<Sarvatt> http://meego.gitorious.org/meego-os-base/kernel-source
<Sarvatt> http://sarvatt.com/downloads/patches/linux-2.6.34-img-graphics-driver.patch -- too big to view on gitorious
<bryceh> Sarvatt, did you run across any patches to stuff other than the kernel?
<Sarvatt> nope I need to dig through the rpms for it still
<bryceh> apw, ^^ maybe this patch should go on the meerkat kernel todo list.  maybe worth thinking about for 10.04.1
<Sarvatt> nothing special in libdrm
<Sarvatt> maybe they make everyone download the blob driver that needs an agreement externally that does it all
<Sarvatt> need to pick apart the moorestown meego image
<Sarvatt> what the heck is up with these packages
<Sarvatt> KERNEL=="event*", SUBSYSTEM=="input", ATTRS{name}=="TSC2007 Touchscreen", ENV{x11_options.MinX}="150"
<Sarvatt> they're using xserver 1.8, evtouch has a bunch of udev rules passing x11_options?
<hyperair> hmm x11_options in udev rules eh
<hyperair> i will have to port my hal fdi rules over
<Sarvatt> hyperair: they aren't supported afaik, you use xorg.conf (or xorg.conf.d snippets) now
<hyperair> Sarvatt: oh i see.
<hyperair> Sarvatt: so how does one specify that only touchpads get 3button emulation?
<Sarvatt> hyperair: http://fedoraproject.org/wiki/Input_device_configuration
<hyperair> ohoho cool
<hyperair> Sarvatt: is there any official documentation?
<hyperair> Sarvatt: like a list of options, and matchwhatever things?
<hyperair> nevermind matchwhatever things are there
<Sarvatt> man synaptics or man xorg.conf tells ya
<Sarvatt> http://edc.intel.com/Software/Downloads/IEGD/ thats what i was thinking of for psb
<BUGabundo> even|ng
<Sarvatt> there is no support for gma500 in meego currently.
<Sarvatt> guess that answers that
<Sarvatt> can't register with intel to grab that IEGD driver to look through either - You attempted to reach edc.intel.com, but the certificate that the server presented has been revoked by its issuer. This means that the security credentials the server presented absolutely should not be trusted. You may be communicating with an attacker. You should not proceed.
<Sarvatt> the meego netbook repo is private too, thats why i couldn't find any juicy patches :D
<bryceh> ahh
<bryceh> now this is starting to sound like the psb we know and love
<Sarvatt> they have a new platform coming out too thats just as crappy as psb but incompatible and bound to be used in netbooks, yay :)
<bryceh> lovely
#ubuntu-x 2010-04-25
<virtuald> $ dpkg --compare-versions 2:1.7.6-2ubuntu7~xtesting~dri2fixes gt 2:1.7.6-2ubuntu7 ; echo $?
<virtuald> 1
<virtuald> why is this?
<RAOF> virtuald: Because I uploaded that package before 2ubuntu7.
<RAOF> Why don't I fix that now...
<virtuald> ok. what should i do if i have any crashes or other strange behavior?
<RAOF> Add a comment to the clutter-crash bug, I thin k.
<RAOF> That'd be bug #550218
<ubottu> Launchpad bug 550218 in xorg-server "xserver crashes when closing application using clutter" [High,Fix released] https://launchpad.net/bugs/550218
<RAOF> Because that's the bug that the glxfixes packages should fix.
<Sarvatt> woohoo nvidia 195.36.24 with xserver 1.8 support
<BUGabundo> yay?
<bjsnider> it also supports fermi/tesla
<Sarvatt> putting it on xorg-edgers and x-updates now
<BUGabundo> need crazy testers?
<Sarvatt> i am completely failing to see the benefit of having fglrx/nvidia and such able to be installed at the same time when it doesn't actually work and we lost the ability to install things from the manufacturers websites for it..  not to mention jockey removes the packages when you dectivate anyway! bug #569871 has got to be the 100th bug i've replied to in that situation
<ubottu> Launchpad bug 569871 in fglrx-installer "Fglrx does not setup the ATI driver files properly." [Undecided,New] https://launchpad.net/bugs/569871
<bjsnider> Sarvatt, the nvidia-installer doesn't work particularly well, unless you think overwriting system files is a good idea
<bjsnider> you can't really have one universal installer. it has to be distro-specific
<Sarvatt> that doesn't stop people from using it and filing bugs because its guaranteed broken instead of possibly working before
<bjsnider> well, nvidia tells them not to use it, and ubuntu does, and if they use it anyway so be it. it's their problem
<BUGabundo> Sarvatt: so an user can have two GPUs? from ati and nvidia at the same time
<Sarvatt> nvidia tells them not to use it? since when
<Sarvatt> we have aaronp telling people to use it in a bunch of launchpad bugs
<bjsnider> "Whenever possible, it is recommended that you use your Linux distribution's NVIDIA Linux graphics driver packages. This will ensure better integration with the distribution's native package management system and reduce the likelihood of problems after system updates, etc.."
<Sarvatt> BUGabundo: they can't have that with proprietary drivers now, having fglrx + nvidia installed at the same time doesn't work but we allow it and peoples systems are all kinds of screwed up because of it
<bjsnider> you should be able to use jockey to switch between fglrx and nvidia
<Sarvatt> except  it uninstalls it when  you deactivate one
<Sarvatt> so its just people who install outside of jockey who are getting things screwed up
<bjsnider> they shouldn't be doing that
<Sarvatt> if you mean they shouldn't be installing from outside of the package manager I agree, but making it so things are broken if you install with a package manager doesn't make sense
<bjsnider> ok, maybe i don't understand what you're saying here. jockey is broken?
<BUGabundo> no
<BUGabundo> just makes it impossible to have both
<bjsnider> i still don't get it
<Sarvatt> jockey is the only way to use proprietary drivers, apt, synaptic, etc all dont work right
<Sarvatt> worse installing with apt ends up allowing combinations that will be broken but jockey doesn't just because it uninstalls when you deactivate one anyway
<Sarvatt> and people are shooting themselves in the foot using apt-get (if they are in recovery for instance because jockey requires X even with jockey-text)
<BUGabundo> eheh
<bjsnider> they're ok with apt-getting a restricted driver as long as they update the xorg.conf right?
<Sarvatt> no because the alternatives are only set up right if they use jockey
<bjsnider> my understanding is that apt-getting nvidia-current updates the glx alternatives
<bjsnider> i think you're wrong about that
<bjsnider> alberto told me that installing nvidia-current updates the alternatives
<Sarvatt> i'll test it out in a bit when the wife gets off that laptop, it didn't when I did it last and if it does now then \o/
<bjsnider> when did you try it last time?
<Sarvatt> hmm looking at the postinst's it does, woohoo! so the problem is still that nvidia and fglrx is broken if installed at the same time and fglrx is the desired one since the default level for nvidia is higher than fglrx
<bjsnider> yeah but why would someone want or need both installed at once? they're mutually exclusive
<Sarvatt> if someone switched to an ati card from nvidia for instance, i agree they shouldn't be allowed at the same time and thats what I was getting at :)
<bjsnider> Sarvatt, jockey doesn't let them exist at the same time right?
#ubuntu-x 2011-04-18
<RAOF> ScottK: But that could be carried as a patch in natty, though, right?
<Sarvatt> pretty sure he means rewriting the detection mechanism to not use the gl renderer string is whats too invasive, just changing GEM to Intel wouldn't be invasive at all
<RAOF> Why use GEM in the first place, though? :/
<Sarvatt> same reason its using driver date in the blacklist files.. craziness
<RAOF> Well, that's *also* going to break now that the driver date is removed :)
<RAOF> I've some sympathy with the âGL strings are part of the ABI, you shouldn't change them in a stable releaseâ point of view, though.
<Sarvatt> it was removed from mesa 7.9.2 :(
<Sarvatt> (also)
<Sarvatt> wine does a lot of things based on the gl renderer string too, I hope its not broken in special ways also
<RAOF> How much wine works on Intel, anyway?
<Sarvatt> works great unless you're on amd64 at the moment :)
<Sarvatt> good old https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/755720
<ubot4> Launchpad bug 755720 in mesa (Ubuntu) (and 1 other project) "32 bit dri drivers cannot find libdricore and libglsl (affects: 2) (heat: 14)" [High,Fix released]
<Sarvatt> ok good wine doesn't care about GEM or driver date
<Sarvatt> ./dlls/wined3d/directx.c:    if (strstr(gl_vendor_string, "Intel(R)")
<Sarvatt> ./dlls/wined3d/directx.c:            /* Intel switched from Intel(R) to IntelÂ® recently, so just match Intel. */
<Sarvatt> ./dlls/wined3d/directx.c:            || strstr(gl_renderer, "Intel")
<Sarvatt> ./dlls/wined3d/directx.c:            || strstr(gl_vendor_string, "Intel Inc."))
<Sarvatt> comments off, only GM45 uses IntelÂ® instead of Intel(R)
<ripps> Anybody have any idea why proprietary nvidia has such bad tearing in Natty, it's alot worse than it was in Maverick
<bjsnider> there isn't any tearing in natty
<bjsnider> the only time tearing would have been an issue in maverick is if metacity was being used instead of compiz, since metacity has always had tearing and compiz syncs to vblank
<ripps> bjsnider: I'm using Natty, I know that my vdpau videos have serious tearing, even when I have compiz to redirct fullscreen, vsync, and force refresh to 120.
<bjsnider> forget about vdpau for a minute. is there tearing on the desktop?
<bjsnider> do regular windows tear?
<RAOF> ripps: Refresh to 120Hz?  Is that actually your refresh rate?
<ripps> RAOF: no, but I read from a couple of sources that improves things, and things do seem alot smoother than when it's just 60. But the compiz refresh rate doesn't seem to affect vdpau whatsoever
<RAOF> Do you have two monitors?  I hear that nvidia won't actually vsync on *either* monitor until you set the primary monitor with a crazy env variable.
<ripps> RAOF: yeah, I don't think desktop tearing is too bad, not that I'd care if it was. I only use one monitor. And I already tried specifiying in my nvidia-settings.rc that I want DFP-0 to have vsync priority
<bjsnider> it sounds like you've already tried every possible fix, even some that haven't been invented yet
<RAOF> VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0 ?
<ripps> RAOF: yep, I have that in both my .xsessionrc and .gnomerc
<ripps> I've discovered that by enabling/disabling "copy to texture" plugin in compiz will temporarily fix/improve vdpau tearing
<ScottK> RAOF: Sarvatt is correct.  Changing kwin would be too invasive and such a patch doesn't yet exist anyway.  I think our only hope for Natty is to add the dropped string back.
<ScottK> It's tested to work and seems low risk to me.
<ScottK> Do you see any harm in it?
<RAOF> It could potentially confuse code that's expecting the new string on mesa 7.10.?
<RAOF> It would be easy to change the string that kwin's looking at; drop GEM and replace it with Intel.
<RAOF> (I mean, in kwin)
<RAOF> That's a change with more restricted possible side-effects.
<ScottK> Can we just add the old string back without dropping the new?
<RAOF> But!  It's entirely possible that *other* code is checking for âGEMâ, which might make reverting the mesa string better.
<RAOF> I guess we could concatenate the strings.  That looks like it should work for kwin.
<ScottK> I don't know which is best, but if I read the bug correctly, Intel broke the ABI, so that's the logical place to fix it.
<ScottK> If that would work, then I'd say that's likely best.
<RAOF> Heh.  âNot only did this contain lies, it contained lies that wouldn't be useful even if true.â
<Sarvatt> <Sarvatt> -    if (strstr((const char *)renderer, "GEM"))
<Sarvatt> <Sarvatt> +    if (strstr((const char *)renderer, "Intel")) -- that was a change for kwin I was suggesting that wouldn't be invasive
<Sarvatt> but either way works, i'll just put a patched kdebase-workspace in xorg-edgers for the people using KDE I guess
<Sarvatt> http://sarvatt.com/downloads/patches/kdebase-workspace.patch
<RAOF> sarvatt: Which place do you think it's best to fix in for 11.04?  Mesa or kdebase?
<ScottK> yofel_: ^^^
<ScottK> I think the biggest question is what else might have depended on that.
<ScottK> IIRC kees has an unpacked copy of the archive he can grep through all the source code with.
<ScottK> RAOF: You might ask him to check.
<RAOF> So, we've only been testing with the new string since early March.
<Sarvatt_> urg http://web.archiveorange.com/archive/v/NG4bEpKZYXhax5O0z7gm
<RAOF> There's a testcase for that?
<RAOF> Neat!
<RAOF> Yup, there it is.
<mars> bryceh, ping
<mars> bryceh, unping
 * yofel fetches his eeePC and tries that kdebase patch
<Sarvatt> yofel: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/753370/comments/9
<ubot4> Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 54)" [Medium,Confirmed]
<yofel> Sarvatt: sorry, was busy, that patch seems to work for me too
<debfx> Sarvatt: about bug #753370: wouldn't it be safer to just revert the commit that changes the renderer string?
<ubot4> Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 56)" [Medium,Confirmed] https://launchpad.net/bugs/753370
<debfx> I've tested this patch which works fine: http://bugsfiles.kde.org/attachment.cgi?id=58999
<Sarvatt> debfx: I wasn't really proposing the kdebase-workspace for the distro, someone else must have flagged it with patch. just uploaded it for the PPA because reverting the string changes from mesa 7.11 is not going to happen
<Sarvatt> for kubuntu there is no situation where Intel being in the renderer string doesn't have DRI2 in use though
<Sarvatt> but I can see them not wanting it that way in upstream kwin because they have to support older mesa releases and such
<debfx> Sarvatt: kde will change the driver feature detection in 4.7 so this will only be an issue in natty
<Sarvatt> 4.7 is coming out in june?
<Sarvatt> thats about when 7.11 will hit oneiric
<Sarvatt> ah cool the timelines do line up good
<debfx> yep
<Sarvatt> debfx: yeah s/GEM/Intel/ isn't the way to go for sure and it'll just have to be a hack added to xorg-edgers until KDE 4.7 comes around since it ships mesa 7.11, indirect is OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2 and would still pass the direct check
<debfx> Sarvatt: adding the GEM string wouldn't be an option?
<RAOF> sarvatt: Oh?  What breaks then?
<debfx> RAOF: could you sponsor my debdiff on bug #753370
<ubot4> Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 58)" [Medium,Confirmed] https://launchpad.net/bugs/753370
<RAOF> debfx: No, sorry - no main upload priviledges :/
<debfx> oh, okay
<RAOF> I've made that change locally but haven't tested it properly.
<debfx> at least on my system the blur effects works again after that change
#ubuntu-x 2011-04-19
<vish> so.. when we switch to wayland, will this channel be renamed to #ubuntu-w ? 
<tjaalton> you're not around to see it anyway ;)
<vish> :D
<tjaalton> x won't go away, at least it'll live as a wayland client for a long time to come
<vish> aah!
<tjaalton> RAOF: I'll merge xserver 1.10.1
<Sarvatt> tjaalton: no point is there, 1 commit you already added as a patch?
<Sarvatt> WTH.. vblank_mode=0 glxgears under an xtrace display is fine on sandybridge, stutters and doesn't update outside of an xtrace display
<tjaalton> Sarvatt: nicer package version, and the current one isn't uploaded either
<tjaalton> merge pushed
<tjaalton> hmm, still no abi-compatible virtualbox release..
<Sarvatt> OSE? theres a precompiled one on the virtualbox website
<Sarvatt> http://download.virtualbox.org/virtualbox/4.0.4/VBoxGuestAdditions_4.0.5-Xorg110.iso
<tjaalton> yeah, i was thinking of the situation in natty
<Sarvatt> someone pointed out the commit needed in a bug report when we first did 1.10, guess that didnt get uploaded..?
<tjaalton> hmm, i'll check the package
<tjaalton> right, it's just been rebuilt to pick up new deps, so it's still broken
<tjaalton> debfx: ^
<Sarvatt> looks like the guest additions dont even compile atm
<Sarvatt> /var/lib/dkms/virtualbox-ose-guest/4.0.4/build/include/iprt/assert.h:231:1: internal compiler error: Segmentation fault
<tjaalton> heh
<tjaalton> I'll try the latest source if it builds..
<Sarvatt> http://www.virtualbox.org/changeset/36301
<Sarvatt> http://www.virtualbox.org/changeset/36389
<Sarvatt> http://www.virtualbox.org/changeset/36300
<tjaalton> yuck
<tjaalton> the first one is familiar looking..
<Sarvatt> a bunch of header manipulation in later commits too so it compiles
<tjaalton> guess I'll pass on building the beast :)
<Sarvatt> portal 2 doesn't work in wine, bah! :)
<tjaalton> hehe
<lilstevie> Sarvatt: damn you
<debfx> tjaalton: what is broken in virtualbox?
<Sarvatt> lilstevie: it doesn't work with fglrx or nvidia either, looks like its a wine and/or portal 2 problem
<lilstevie> Sarvatt: meh I have an ATi 5750
<lilstevie> I however don't own portal 2
<Sarvatt> yeah 5770 is what i tested it on first
<Sarvatt> http://bugs.winehq.org/show_bug.cgi?id=26835
<ubot4> bugs.winehq.org bug 26835 in -unknown "Portal 2 exits at menu screen." [Normal,New]
 * Sarvatt is hoping for a miracle when he wakes up
<tjaalton> debfx: guest additions don't work in natty
<tjaalton> debfx: also, I'm filing a bug report that you probably should use OBSOLETE_BY in dkms.conf, to tell dkms not to build on kernels newer than what the vbox version supports
<debfx> tjaalton: the ones from the additions iso image?
<tjaalton> debfx: i don't know where they are from :)
<tjaalton> but if they are not distributed by ubuntu, it's not something you can fix, right?
<debfx> both is in ubuntu, the virtualbox-ose-guest-x11 package and virtualbox-guest-additions (the iso image)
<debfx> I could update virtualbox-guest-additions to the 4.0.5 pre-release
<lilstevie> Sarvatt: a miracle for me would be someone giving me portal2 :p
<debfx> about OBSOLETE_BY: how do I know which kernel version will break the module? ;)
<tjaalton> debfx: yeah that would be good I think. and as Sarvatt pointed out, current version in natty doesn't even build
<tjaalton> debfx: just put the one that the distro version is shipped with, the user can override it
<tjaalton> debfx: do you still need a bugreport for it?
<tjaalton> so, for natty you'd put 'OBSOLETE_BY=2.6.39', unless you know it builds with it
<debfx> a bug report would be good, yes
<tjaalton> in which case 2.6.40 would be ok
<tjaalton> alright, I'll finish it
<debfx> Sarvatt: internal compiler error -> please report a bug against gcc :)
<ricotz> Sarvatt, hey :)
<tjaalton> debfx: filed bug 765680
<ubot4> Launchpad bug 765680 in virtualbox-ose (Ubuntu) "prevent building the dkms modules on kernels newer than is known to be supported (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/765680
<ricotz> Sarvatt, could you renew my xedgers membership?
<debfx> tjaalton: thanks
 * ricotz is having wifi problems and gets disconnected often
<debfx> tjaalton: maybe you could sponsor my debdiff on bug #753370 ?
<ubot4> Launchpad bug 753370 in mesa (Ubuntu) (and 1 other project) "No Desktop Effects in Kubuntu 11.04 Beta1 (affects: 9) (dups: 2) (heat: 58)" [Medium,Confirmed] https://launchpad.net/bugs/753370
<tjaalton> debfx: I can
<debfx> cool, thanks!
<tjaalton> debfx: uploaded
<debfx> tjaalton: I'm not sure if adding OBSOLETE_BY is a good idea
<debfx> I'd rather have something that displays a warning when the build fails with an unsupported kernel version
<debfx> also dkms shouldn't fail package installations when a build fails
<debfx> I should probably file a bug against dkms :)
<tjaalton> debfx: think I tried that already :)
<tjaalton> oh you found that
<tjaalton> and i agree OBSOLETE_BY is a hack, but the best there is atm
<tjaalton> xserver 1.10.1 uploaded
<debfx> tjaalton: for oneiric dkms needs to stop generating apport bugs for unsupported kernels, otherwise I'll start redirecting them ;D
<tjaalton> debfx: heh, sounds good
<debfx> either by a kernel version variable or by detecting if the kernel is from the ubuntu archive
<ScottK> RAOF: Did you all reach a conclusion on what to do about the GEM/Intel question?
<tjaalton> ScottK: uploaded already
<tjaalton> and accepted
<ScottK> tjaalton: Excellent.  Thanks.
<Sarvatt> ricotz: I extended your membership the day they emailed us, we had the same join date (but the years differed) so I'm expiring too :)
<Sarvatt> but I can't extend my own membership even though i'm an admin
<ricotz> Sarvatt, oh, thank you, actually i didnt looked at the team page and just relied on the email
<ricotz> and there wasnt a "your membership was renewed" mail yet ;)
<soreau> Sarvatt: ping: I was wondering if installing xorg-edgers on lucid will update the kernel as well
<bryceh> soreau, no
<soreau> bryceh: Ok thank you
<bryceh> soreau, you can look at the package details of the ppa to see what gets installed
<ScottK> My blur is back on KDE/Intel.  Thanks everyone.
#ubuntu-x 2011-04-20
<LLStarks> hi, is there any reason why i'd be unable to access a tty using recovery mode or ctrl+alt+num?
<RAOF> Because something's messed up your VTs?
<RAOF> Such asâ¦ da da da DAAAAM, nvidia? :)
<RAOF> Bah.  Stupid intel stupid dpms stupid waaaaaaraghrfl
<ScottK> Nvidia is much simpler.  "Meh.  Nothing I can do."
<LLStarks> raof, 945gm
<LLStarks> i always get a blinking cursor
<LLStarks> no VT
<LLStarks> cleared 99% of my home's hidden folders and wiped /
<LLStarks> no luck
<RAOF> Maybe getty's not being spawned?
<LLStarks> would a xorg log be helpful?
<RAOF> Not really.
<RAOF> Unless X isn't coming up properly.
<LLStarks> x is loading fine, but there's no backend terminal i can use.
<RAOF> The x log is unlikely to be very interesting.
<LLStarks> raof, do you have any recommendations for triaging?
<RAOF> I'd suggest that upstart is actually what you want to be debugging.
<LLStarks> i have a bootchart, would that reflect getty's non-presence?
<RAOF> Yes.
<RAOF> Ok, so it looks like GM45 at least won't GPU hang on dpms events.  Or, rather, the missing vblank issue will kill X before it triggers.
<Sarvatt> RAOF: that was reported on ati too, but heck if I can find it
<RAOF> What, missing vblanks?
<Sarvatt> almost identical backtrace, the _CallCallbacks/DRI2WaitMSCComplete one?
<Sarvatt> you were talking to the guy in #xorg-devel a few weeks ago actually, let me see if I can find the log
<RAOF> Oh, that one.
<RAOF> So, I know how to trigger *something* like that with reckless abandon on intel - have a client hang waiting for vblank, and then start another GL app :)
<Sarvatt> RAOF: which bug are you talking about then? btw they dont really want intel_gpu_dump output anymore, /sys/kernel/debug/dri/0/i915_error_state has the good info
<LLStarks> this really sucks. i have no access to a tty unless i chroot through a liveusb. is there anyway to Xorg -configure without a tty and shut-down x?
<tjaalton> LLStarks: try putting 'GRUB_GFXPAYLOAD_LINUX=text' in /etc/default/grub
<tjaalton> and run update-grub
<LLStarks> thanks timo
<tjaalton> if that works, follow the instructions here https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
<tjaalton> to file a bug
<LLStarks> i'll see if this works
<ripps> I added libbluray to the Natty builds of mplayer2 in my ppa. Too bad this won't allow it to play commercial bd's with aacs or bd+
<tjaalton> surprised?
<ripps> well, it would require installing libaacs and having a valid key set for the disc being played. I haven't discovered an easy way of implementing this. Not to mention it would probably get my ppa shut down if it was discovered
<maxb> Is there a better way to toggle between radeon and fglrx than installing and uninstalling fglrx?
<maxb> ooh, gl_conf alternative
 * maxb tries it
<tseliot> maxb: and make sure you do "sudo ldconfig" and "sudo update-initramfs -u" after you change the alternative
<maxb> Can anyone offer me any advice on writing a useful bug report for my mouse pointer disappearing when positioned close to one edge of my secondary monitor?
<maxb> It does not occur if I switch from radeon to fglrx, but does that mean I should report it against the radeon driver, or could it be in mesa? (I believe fglrx replaces that too?)
<maxb> tseliot: Ah, thanks. I failed to do so, but I will remember for next time :-)
<maxb> I also had a catalyst control centre autogenerated xorg.conf I needed to nuke
<tseliot> right, that too
<LarsTorben> are here developers ??
<zniavre> good afternoon 
<zniavre> do i need to report that nvidia updated their 173 driver ? > ftp://download.nvidia.com/XFree86/Linux-x86/173.14.30/
<zniavre> but unity can't work with them 
<tseliot> zniavre: there's no need to do that. I'll upload it today
<bjsnider> znaii don't see why it wouldn't run compiz/unity
<bjsnider> zniavre,  don't see why it wouldn't run compiz/unity
<Sarvatt> RAOF: YokoZar said he'd update ia32-libs tonight so 32 bit mesa will work again \o/
<zniavre> bjsnider, the fact is ...  unity works with nouveau+dri-experimental but does not with the 173.14.30 (after gdm unity can't load the desktop its blinking ad-vitam)
<bjsnider> zniavre, the driver hasn't been packaged yet
<zniavre> bjsnider,  they are 
<zniavre> https://launchpad.net/ubuntu/natty/+source/nvidia-graphics-drivers-173/173.14.30-0ubuntu1
<bjsnider> does opengl work at all?
<zniavre> yes
<bjsnider> compiz won't start?
<zniavre> compiz can work with gnome-classic session only
<zniavre> not with unity after gdm the desktop is blinking and does not load unity-panel and launcher 
<zniavre> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/767613
<bjsnider> well i think you shuld report a unity bug
<ubot4> Launchpad bug 767613 in unity (Ubuntu) "unity does not start with nvidia173.14.30 (affects: 1) (heat: 6)" [Undecided,New]
<bjsnider> ok
<zniavre> :o)
<zniavre> i reported with driver from repos
<bjsnider> there's no real reason to use the 173 if it can't run unity
<bjsnider> unless you're a kde user i guess. there are still a few of them kicking around
<zniavre> nouveau can run unity but that s all in fact the rest is a real apin to use (flash opengl apps etc...)
<bjsnider> if you've got no unity with the 173 and have to run the classic desktop i think nouveau can probably do it better than the 173
<zniavre> i m not against you 
<Sarvatt> hmm, didn't someone report unity not working with nvidia-current on a opengl 2.1.2 era nvidia too? a 7500gt I think?
<bjsnider> well, that would have to be a geforce pre-8k
#ubuntu-x 2011-04-21
<aquarius> hm. I keep getting GPU crashes (I think that's what they are), and then when I reboot the machine to get my display back, I ge tthe "System program problems detected" dialog. When I say "yes, report the problem", I get *another* crash dialog saying "apport-gpu-error-intel.py closed unexpectedly". I think this means that the program trying to diagnose the crash is itself crashing?
<aquarius>  So I have two questions: how do I diagnose and report the GPU crash, and am I correct in my assumptions? :)
<tseliot> aquarius: I think you should report the problem with apport then, otherwise you won't be able to report the other erro
<tseliot> error
<tseliot> you can talk to pitti about apport in #ubuntu-devel
<aquarius> tseliot, I spoke to seb128 and he says that apport-gpu-error-intel.py is part of the X packages; it's not an apport problem
<tseliot> aquarius: oh, right, so maybe bryceh knows more about it
<bryceh> aquarius, run apport-gpu-error-intel.py by itself, copy and paste  the error messages printed out into a bug report, and assign to me
<bryceh> aquarius, you can file the bug report against 'xorg'
<aquarius> I'll happily try running that apport-gpu python thing myself to see how it fails, but I don't know how apport decides to run it.
<aquarius> I would file a bug report but apport won't let me, because apparently my version of upstart is out of date, sigh
<bryceh> aquarius, regarding the GPU freeze, basically what the tool does is while your system is frozen it collects your dmesg and /sys/kernel/debug/dri/0/i915_error_state, so you can grab those and file a bug report manually if you want
<aquarius> bryceh, aha, that sounds useful. I'll do that.
<bryceh> aquarius, part of the problem may be that today apport was turned off from filing gpu lockups
<bryceh> but... you should get an error message not a crash
<bryceh> hiya tseliot
<tseliot> hi bryceh
<bryceh> tseliot, http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-natty-workqueue.svg is looking really good this release
<tjaalton> wait a couple of weeks :)
<tseliot> hehe
<tjaalton> though then we can start fresh on totals-oneiric-workqueue.svg
<bryceh> tjaalton, yeah within 2 weeks I won't care how the natty chart looks  \o/
<bryceh> and I've got toolage ideas on how to keep the O bugs under even better control
<aquarius> bryceh, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/768176 filed. Hopefully it contains the info you need.
<ubot4> Launchpad bug 768176 in xorg (Ubuntu) "GPU hang (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> [   10.351148] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
<bryceh> that's unusual
<bryceh> aquarius, delete your /etc/X11/xorg.conf and ~/.drirc
<bryceh> neither of those look necessary and esp. the drirc could be mussing things up
<aquarius> sure thing. Will deleting them take immediate effect on my machine, or just after an X restart?
<bryceh> xorg.conf only takes effect on startup
<bryceh> .drirc I'm less sure about
<aquarius> I have deleted them and my graphics doesn't seem to have gone away or anything, so that's OK :)
<bryceh> btw for gpu lockups, you need to collect the dmesg and /sys/kernel/debug/dri/0/i915_error_state *while* it's frozen; otherwise they are boring
<aquarius> oh!
<aquarius> um. Given that I only have one machine, is that doable?
<aquarius> actually...I could probably ssh in from my phone. Will give it a try next time it happens.
<bryceh> probably not
<bryceh> (this is one reason why the apport hook exists...)
<aquarius> ya. Can I run the apport hook in the same way that apport itself does, so I can see why it's failing?
<bryceh> yep, it's just a python script, go ahead and execute it
<bryceh> /usr/share/apport/apport-gpu-error-intel.py
<bryceh> my wager is "    if not packaging.enabled():
<bryceh> " is returning false
<aquarius> correct: python -c "from apport.packaging_impl import impl as packaging; print packaging.enabled()" -> False
 * bryceh nods
<bryceh> right, that's 'cause apport is switched off for release now
<bryceh> you could try sneakily commenting out those lines
<aquarius> so running the script by hand doesn't do anything. But that's not what happened after the GPU hang and reboot; I got an apport crash dialog for apport-gpu-error-intel.py itself, which suggests it was crashing, not just silently exiting.
<bryceh> yeah... *that* sounds interesting to me
<aquarius> although I did upgrade after getting the crash, to see if I'd be able to file the bug.
<bryceh> ah
<aquarius> so perhaps it was crashing before, then I upgraded and got a new apport which said to not run the script after all.
<aquarius> darn.
<bryceh> well, I can attest the hook has been working fine for most people (the resultant reports have been keeping me quite busy)
<bryceh> aquarius, yes that does seem plausible
<aquarius> ahaha!
<aquarius> have just copied the script and made it skip the pacakging.enabled() check. And now when I run it I get the  "apport-gpu-error-intel.py closed unexpectedly" crash dialog.
<aquarius> now filing that itself as a bug :)
<bryceh> thanks!
<bryceh> I really need to write some python tests for that...
<aquarius> erm! confused. I said "report bug" on the "apport-gpu-error-intel.py closed unexpectedly" dialog, and it's filed https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/768184 which is the bug for the GPU hang!
<ubot4> Launchpad bug 768184 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x01800020) (affects: 1) (heat: 6)" [Undecided,New]
 * aquarius does the baffled look.
<bryceh> heh
<aquarius> so maybe apport-gpu-error-intel isn't actually crashing after all, but apport gets confused and says that it is.
<bryceh> looks similar to 765416 or 757399; slightly different chip though
<aquarius> I am happy to provide whatever other information you'd find useful :)
<bryceh> aquarius, can you tell me is this a recently upgraded natty from maverick or have you been running natty for a while?
<aquarius> I've been running natty for a while
<bryceh> have you had other gpu freezes since upgrading or is this the first?
<aquarius> since about, um, November.
<aquarius> This isn't the first, but it's about the third, and they've all happened in the last week or so.
<bryceh> do you know if you can reproduce this freeze at will?
<aquarius> I think. (I've been having compiz-locking-up-but-I-can-switch-to-a-VC hangs for a long time; this is different.)
<aquarius> I can't reproduce it, sorry
<bryceh> mm ok this is all good info
<bryceh> it'd be most helpful if the bug were easily reproduced
<aquarius> I agree entirely :)
<bryceh> then I'd have you downgrade to a kernel from last week, possibly do a git bisect, etc.
<bryceh> or alternatively have you try one of the newer mainline kernels
<bryceh> we also have a few proposed patches for similar issues (but different chips)
<aquarius> sadly, it doesn't seem to be prompted by anything specific that I do. (I mean, obviously *something* I did made it happen, but there is no thing that I do that reliably makes it happen.)
<bryceh> and those are always the best of the best bugs ;-)
<bryceh> well, let's just keep an eye on it for now; I've got some similar bugs on my end
<bryceh> if you can get to a point that it's frustrating enough for you, that you'd notice if the bug were gone, you can start testing mainline kernels
<aquarius> sure. Sorry I can't do more than whine and say "it crashes! for no discernable reason and with no way of replicating it! but you have to fix it anyway!" :)
<bryceh> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<aquarius> yeah; so far it hasn't happened much; the GPU is way, way behind compiz and the kernel thermal stuff for interrupting my work :)
<bryceh> aquarius, nah, it's useful anyway.  but obviously we want to have a way to know if a fix actually fixes it
<bryceh> if I have time I'll probably send the report upstream and see what they have to say
<aquarius> cool. If it happens again I'll try more stuff.
<bryceh> there's been a spate of these rare lockups on 965, that various people (including mark!) have reported
<aquarius> heh. How to get your bug fixed quickly: buy the same laptop as mark :)
<aquarius> I am told that Amber Graner has the same laptop as me, which means that kernel bugs ought to get fixed quickly ;)
 * gord makes note, find out what laptop mark has
<aquarius> he did at one point have the dell M1330, which is what I've got. But he replaces his machine more often than I do :)
<bryceh> actually, from what I can tell, you want to have the same hw as mdz
<bryceh> mdz is way better at following up on bugs, and quite prolific at filing them
<bryceh> anyway, getting late for me.  night.
<Sarvatt> +        AC_MSG_ERROR([LLVM is required to build r300g])
<Prf_Jakob> Sarvatt: OpenSUSE is (was?) shipping r300g with LLVM disabled. Can you believe it? Poor users with SWTCL chipsets... and bad reputation for us too.
<Sarvatt> Prf_Jakob: debian and ubuntu too
<Sarvatt> and fedora 14 I believe
<Sarvatt> yep
<Prf_Jakob> if its going to cause troubles for you please chip in.
<Sarvatt> nah wont be a problem, was just pasting that as heads up we're going to have to do it
<Prf_Jakob> Sarvatt: which llvm version are you guys shipping with btw?
<tjaalton> 2.8 currently
<Prf_Jakob> ok, there is a bug in 2.8 that causes it to fail on any AVX processor.
<Prf_Jakob> its fixed in 2.9
<Sarvatt> 2.8, luckily the swtcl r300g wont ever  be combined with a sandybridge
<Prf_Jakob> arn't you going to use llvmpipe for swrast?
<Sarvatt> 11.04 is done pretty much, this will all be in 11.10 which will have 2.9
<Prf_Jakob> ok
<bjsnider> Sarvatt, if nouveau was blacklisted but nvidia wasn't installed would nouveau be used anyway?
<Sarvatt> nope nv should be used
<sithlord48> can anyone tell me if Hardware texture compression is possible w/ the intel i915 driver in natty (i have the xcrack ppa version)
<tjaalton> no
<tjaalton> http://www.phoronix.com/scan.php?page=news_item&px=OTIzMQ
<sithlord48> can i make wine think it has HW texture support ?
<tjaalton> dunno
<sithlord48> well thats the goal i have a game i want to play (via wine) and it requires hw texture support.. 
<Sarvatt> s3tc support is in the ppa but if you're using amd64 you're out of luck since wine uses the 32 bit libs in ia32-libs which doesn't have it
<sithlord48> i have 32bit on this machine..
<sithlord48> how can i enable it ?
<Sarvatt> its enabled (if you're talking about xorg-edgers), must not be what you're looking for if it still doesnt work
<Sarvatt> what game?
<sithlord48> lord of the rings online
<Sarvatt> sithlord48: is libtxc_dxtn0 installed?
<sithlord48> not sure let me check that 
<sithlord48> is that the package? i cna't find it 
<Sarvatt> err sorry, libtxc-dxtn0
<sithlord48> i see that now that i've opened a package manager.. :D
<sithlord48> no it was not.. 
<sithlord48>  i've installed xorg ppa. wine 1.3 (from teh c-korn ppa w/ pulse support) and now this libtxc-dxtn0 . brb to test
<Sarvatt> alternatively you can just install driconf and toggle the first option on the second tab
<tjaalton> huh, mesa has s3tc now? or maybe I should stop reading phoronix..
<Sarvatt> oh good llvm-2.9 is in experimental
<sithlord48> sorry i crashed X. but i did get it working w/ libtxc-dxtn0 .althouth the intel GMA945 chipset is still garbage
<Sarvatt> yeah much too slow for that game
#ubuntu-x 2011-04-22
<Sarvatt> RAOF: sony vaio SB's are out in the wild apparently and nicely broken :)
<Sarvatt> RAOF: see #radeon backscroll on the fun ways its broken :)
<Sarvatt> (those being one of the new amd/intel hybrid Z replacements)
<micahg> hi bryceh, wayland seems to depend on libcairo2-dev, but libcairo2 has an unversioned breaks on wayland (bug 768681)
<ubot4> Launchpad bug 768681 in wayland (Ubuntu) "Wayland wont install because unmet dependencies (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/768681
<bryceh> micahg, yeah I know
<micahg> bryceh: k, you want me to do anything with the bug?
<bryceh> micahg, it should be filed against libcairo rather than wayland
<bryceh> micahg, no change to wayland is needed; it needs the cairo-gl support turned back on in libcairo
<bryceh> micahg, long story... basically cairo-gl results in higher per-app memory usage when the nvidia binary driver is loaded
<micahg> bryceh: ok, I'll move it then, thanks
<micahg> and that's obviously not happening for natty before release :)
<bryceh> yup, unfortunately
<BlackZ> Sarvatt, tseliot: with the nvidia-173 package all works properly
<tseliot> BlackZ: what was you problem again?
<BlackZ> tseliot: bug #761718
<ubot4> Launchpad bug 761718 in nvidia-graphics-drivers (Ubuntu) (and 1 other project) "Can't start Ubuntu default session properly (affects: 2) (heat: 10)" [Undecided,Invalid] https://launchpad.net/bugs/761718
<tseliot> ah, weird
#ubuntu-x 2011-04-23
<ScottK> bryceh: You've got three copies of  xserver-xorg-video-intel in queue for natty-proposed.  If they're all the same, let me know and I'll pick two at random to reject.  If not, tell me how to figure out which one to keep.
<bryceh> ScottK, they're all the same so pick one at random.  When I dput it it gave me a gpg key error so I resent it.
#ubuntu-x 2011-04-24
<LLStarks> bryceh, i've lost proper ddc/edid reading on i945gm with the release stack
<LLStarks> can't get higher than 1024x768 with vga
<LLStarks> lvds is fine
<LLStarks> http://paste.ubuntu.com/598424/
<LLStarks> raof, you around?
<LLStarks> i'm also getting scrambled graphics whenever i try to hook up something through  vga for a few seconds.
#ubuntu-x 2012-04-16
<cprofitt> anyone home
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/981019
<ubottu> Launchpad bug 981019 in nvidia-common (Ubuntu) "3D desktops crash or are unusably slow" [Undecided,Confirmed]
<Sarvatt> cprofitt: reporting it on http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 is going to be a lot more effective, we just ship their binary drivers, its not like we can fix it
<cprofitt> Sarvatt: not sure it is 100% their driver though...
<cprofitt> I reverted back to 295.20 and still had issues... the problem may be with kernel or xorg
<Sarvatt> if its fine with nouveau like the bug says its pretty clear cut, but that bug is very vague
<cprofitt> just not sure how to proceed to triage
<cprofitt> I can use Unity 2D with the driver just fine as well... it appears to be something with 3D
<cprofitt> when I rever to 295.20 Unity 3D works better, but 3D games still end up looking like slideshows
<cprofitt> Is there any thing I can do to help sort that out?
<Sarvatt> 295.xx is a longterm release and will be updated many times in the future in 12.04, might be worth switching to nvidia-current-updates so you get future updates automatically now. but yeah that bug is basically "i have problems with 295.xx" so of course people will click it too if they do and its not going to go anywhere, a distinct bug for your issue will be more useful with actual apport info listing what gpu you have and stuff. its certainly not 
<Sarvatt> a widespread problem and might be specific to your gpu
<Sarvatt> but if you want it fixed for real reporting it on that forum directly to nvidia is the way to go
<cprofitt> alright... I am going to reinstall -- fresh install... then update... then if the problem persists I will follow the steps in the nvidia forums
<cprofitt> thanks
<Sarvatt> i didnt help, but no worries, its the sad reality with the binary drivers :(
<Sarvatt> I did see that 295.40 has issues on old IGP nvidias from the reports, you have one of those?
<Sarvatt> like 6150
<Sarvatt> or 7100
<Sarvatt> oh hmm 7050 i guess it is
<cnd> Sarvatt, yay!
<cprofitt> I have an 8800 GTS 320
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/980672
<ubottu> Launchpad bug 980672 in unity (Ubuntu) "compiz crashed with SIGSEGV" [Undecided,Incomplete]
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/980879
<ubottu> Launchpad bug 980879 in unity (Ubuntu) "compiz crashed with SIGSEGV" [Undecided,Invalid]
<cprofitt> finding some more bugs with this
<cprofitt> https://bugs.launchpad.net/compiz-core/+bug/980521
<ubottu> Launchpad bug 980672 in unity (Ubuntu) "duplicate for #980521 compiz crashed with SIGSEGV" [Undecided,Incomplete]
<Sarvatt> yeah i'm actually seeing lots of bugs about 295.40 now that i'm looking, i think they rushed out the update for the security fix too fast :)
<cprofitt> yeah... looking like it...
<cprofitt> not sure why reverting to 295.20 still caused me issues, but a fresh install will help me troubleshoot
<cprofitt> the text box had been an upgrade from 11.10
<Sarvatt> you might have to purge nvidia, then install 295.20 to work right, but im not sure about that
<cprofitt> yeah... reading that now...
<Sarvatt> not sure downgrades work properly, the packaging for nvidia is nuts and lots of room for things to go wrong
<cprofitt> the install is already in progress though...
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/980298
<ubottu> Launchpad bug 980298 in unity (Ubuntu) "compiz crashed with SIGSEGV in GLWindow::glDraw() from UnityMTGrabHandlesWindow::glDraw()" [Undecided,Confirmed]
<Sarvatt> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/295.20-0ubuntu1 the debs are there if you click the amd64/i386 links
<cprofitt> there are times it becomes a mess just to find related things in LP
<Sarvatt> i use google to find things on launchpad, thats pretty sad :)
<cprofitt> that is why I don't file bugs until I have a great deal of certainty as to what it is
<cprofitt> lol -- me too
<cprofitt> at least some of these folks are getting errors... I was just getting 'slow'
<Sarvatt> well slow is a different issue so safe to assume the crashes arent related to your problem
 * cprofitt nods
<Sarvatt> honestly if you reported it on nvnews forums it will get the highest possible chance of getting fixed in the next driver release, we only engage nvidia over issues about new platforms not working, something like 8800gts specifically being abnormally slow might not get noticed on launchpad
 * cprofitt nods
<Sarvatt> but it would still be worth reporting on launchpad, maybe theres an issue with how it was installed causing it that we could notice
<Sarvatt> ubuntu-bug nvidia-graphics-drivers only takes 30 seconds to do
<cprofitt> I will do that after the reinstall -- if the issue is still present... and will report via the nvidia forums as well.
<bjsnider> Sarvatt, what are the nature of the bugs?
<bjsnider> not having any trouble with my gt520 yet
<cprofitt> I can't speak to the others...
<cprofitt> my issue was the update that I did today caused Unity 3D to be non-functional with Nvidia 295.40
<Sarvatt> bjsnider: sounds like if you hit whatever cprofitt is hitting you would notice, super slow 3D
<cprofitt> I just reinstalled and updated only the nvidia driver
<cprofitt> Unity was useable -- testing a game now
<cprofitt> then will update the rest to see if the issue comes back
<cprofitt> there is a chance something was latent due to it being an upgrade from 11.10
<bjsnider> well, maybe it's a compiz issue, because i'm using mutter
<bjsnider> is all opengl slow?
<cprofitt> yes, it seems to be... games were slow as well
<cprofitt> I used Unity 2D and launched games they had issues
<cprofitt> interesting... no issues on initial install of 12.04 Beta 2... and upgrade of 295.40 drivers only
<cprofitt> exiting the game caused some issues though... took about 20 seconds to redraw the desktop
<RAOF> hyperair: Yo!  Did you end up sending something to xorg-devel@ about the coasting scroll thing?
<Sarvatt> the person who wrote the patch did
<Sarvatt> RAOF: guessing you're referring to the coasting thing?
<RAOF> Sarvatt: Yes.
<Sarvatt> yah check out the "[PATCH synaptics] Fix coasting speed" thread, whot merged it but was waiting on the signoff before pushing from what i saw
<RAOF> Yeah, we've pulled that into precise.
<RAOF> But the initial patch seemed wrong, and hyperair fixed it.  I'm not sure if that problem was in the patch on the list, though.
<Sarvatt> he certainly didnt mark it as such in the actual patch if so
<cprofitt> Sarvatt: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982710
<ubottu> Launchpad bug 982710 in nvidia-graphics-drivers (Ubuntu) "Nvidia 295.40 - Ubuntu 12.04 Beta 2 Fresh Install (slow performance in Unity 3D)" [Undecided,New]
<Sarvatt> cprofitt: long shot but maybe try adding Option "UseEvents" "True" to the device section of /etc/X11/xorg.conf?
<RAOF> cprofitt: Does the same problem happen with the 295.33 drivers?  There's at least one known performance hit (in rare cases) to the security fix that went in to .40
<cprofitt> RAOF: I have not reverted this install yet, but I did my previous one and the performance issue got slightly better, but there was still an issue
<cprofitt> Sarvatt: will try that
<Sarvatt> i dont see any NVIDIA(1): WAIT's in the logs that i had when that helped me with on my last nvidia 8xxx machine so its really a random guess
<cprofitt> random guesses are worthy of a try
<cprofitt> seems like a rock and a hard place right now
<cprofitt> do not want a security hole... but do not want people to find fault with the new release based on Nvidia drivers
<RAOF> To be clear: I don't think it's particularly likely that the security fix is the cause of performance problems; AFAIK it just interfered with some infrequently used 3D paths on some cards.
<cprofitt> Sarvatt: that setting resulted in a black screen and no login
<cprofitt> removed it and got to login screen
<cprofitt> gah... can't register on the NVnews forums
<cprofitt> page not found error
<cprofitt> :-)
<bjsnider> cprofitt, how does nouveau work?
<cprofitt> bjsnider: it worked fine for Unity
<cprofitt> I did not test it with games -- not sure it is supposed to work there
<bjsnider> itmight
<cprofitt> I will test that as well
<hyperair> RAOF: er whoops, i forgot to.
<cprofitt> thanks everyone... gotta get some sleep so I can work in the AM
<cprofitt> have a great day, night, morning
<RAOF> hyperair: :)
<RAOF> hyperair: Just to be clear, the changes you made were in HandleScrolling, right?
<hyperair> RAOF: i'm not subscribed to the list. could you help me forward it please? :-)
<RAOF> hyperair: Of course.
<hyperair> RAOF: yeah, you could just do an interdiff to see the changes
<hyperair> there's only one extra hunk
<hyperair> i just amended the way the coasting_friction was deducted from the speed.
<Sarvatt> it got applied and pushed now like it was sent upstream, if theres a problem it needs a new patch :)
<hyperair> i see
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=5a1612d4496b51682c9043aa064025c545249de6
<hyperair> Sarvatt: http://paste.debian.net/163369/
<hyperair> RAOF: ^
<hyperair> so that's the amended patch =)
<hyperair> hmm since it now actually has my name on it, i guess i should send it to xorg-devel myself..
<RAOF> Would be easier, yes.
<RAOF> You'll need to add a signed-off-by tag, too.
<hyperair> ah. shit.
<hyperair> it's already sent.
<hyperair> Â¬_Â¬"
<hyperair> now what?
<Sarvatt> hyperair: reply with Signed-off-by: Chow Loong Jin <hyperair@debian.org>
<Sarvatt> or whatever
<hyperair> nevermind that, thunderbird broke my patch >_>
<hyperair> i'll just resend it as an attachment
<Sarvatt> looks fine to me
<hyperair> yeah, it looks fine, until you try to git am
<hyperair> then git complains of a broken patch
<Sarvatt> oh yeah malformed
<Sarvatt> git send-email works really well with gmail now easily
<hyperair> hmm really
<hyperair> i should try that next time
<Sarvatt> http://paste.ubuntu.com/932043/ in ~/.gitconfig
<hyperair> hmmm can i not specify my password there?
<hyperair> i transplant the .gitconfig around
<RAOF> Yeah, if you don't specify the password it'll prompt for it.
<hyperair> okay
<Sarvatt> oh cool
<Sarvatt> it used to be a PITA setting up mstmp for gmail access in git send-email but its super easy now
<Sarvatt> not sure what you use for @debian.org but heard ya moaning about gmail in evolution earlier so figured it might be that :)
<hyperair> actually come to think of it, i have postfix installed...
<hyperair> which directly hooks up to gmail
<hyperair> and yeah, i use gmail for my @debian.org.
<Sarvatt> you didn't pick no config at the debconf prompt when you installed devscripts and inherited postfix?!
 * Sarvatt hates doing that on every system :)
<Sarvatt> i have >500k emails in my gmail so i totally feel your pain wrt evolution
<hyperair> haha
<hyperair> well i installed postfix out of curiosity
<hyperair> and then found out it could send via gmail using sasl
<hyperair> so there we go =)
<Sarvatt> oh so you already had an MTA, lucky. i could care less about having a MTA installed just to use debuild :)
<hyperair> debuild?
<hyperair> did debuild need an MTA?
<hyperair> i use sbuild though
<hyperair> and there were a crapton of other things that needed an MTA, which i couldn't remember
<hyperair> er right, like my cron jobs
<cprofitt> reported the Nvidia driver problem on the nvnews.net forums now
<cprofitt> http://www.nvnews.net/vbulletin/showthread.php?p=2546106
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982762
<ubottu> Launchpad bug 982485 in nvidia-graphics-drivers-updates (Ubuntu) "duplicate for #982762 nvidia 295.40 breaks unity 3d" [Undecided,Triaged]
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+bug/982485
<ubottu> Launchpad bug 982485 in nvidia-graphics-drivers-updates (Ubuntu) "nvidia 295.40 breaks unity 3d" [Undecided,Triaged]
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982710
<ubottu> Launchpad bug 982485 in nvidia-graphics-drivers-updates (Ubuntu) "duplicate for #982710 nvidia 295.40 breaks unity 3d" [Undecided,Triaged]
<tseliot> cprofitt: I've replied to your email about it
<cprofitt> tseliot: thanks 
<cprofitt> I will try to get that additional file for you when I get home
<tseliot> thanks
<tjaalton> bryceh: back to the drawing board with the wacom touchscreen patch :) upstream committed this http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=e40cb71a910164d1cb2c366d3c001eeaac79aaaf but if that alone doesn't fix it we'd need debug logs to figure out why gsd_wacom_device_is_screen_tablet was zero there
<tjaalton> bryceh: so, since you have an actual device, could you post debug logs from g-s-d to the bug?
<tjaalton> if you have time
<tjaalton> I'll reopen it
<seb128> bug #943880
<ubottu> Launchpad bug 943880 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGABRT in __libc_message() from malloc_printerr() via XIDestroyDeviceProperty" [High,Confirmed] https://launchpad.net/bugs/943880
<seb128> is somebody working on that issue?
<tjaalton> I think cnd was
<seb128> it's showing up in the top retraced bugs
<seb128> I've added a precise milestone to it
<cnd> seb128, no one knows what it is
<cnd> it looks to be some corruption, but I can't reproduce it
<cnd> valgrind doesn't show anything either
<seb128> cnd, ok, well I guess the precise milestone still makes sense in any case, that's a bug we will want to SRU fix if we get a fix at some point
<cnd> yeah
<bryceh> Sarvatt, regarding regressions from 295.40, we don't seem to have very many new bugs filed against nvidia-graphics-drivers
<bryceh> wherre does nvidia-current-updates_hybrid.conf come from?
<Sarvatt> nvidia-common
<bryceh> well, I can see that :-)  but I mean why is it there?  is this from alberto's hybrid graphics work?
<Sarvatt> yeah, i dont know what its doing :)
<bryceh> bug 981048 implies it isn't getting removed on nvidia disable, making the system unbootable
<ubottu> Launchpad bug 981048 in jockey (Ubuntu) "nvidia-current-updates_hybrid.conf persists after nvidia drivers are disabled" [Undecided,Confirmed] https://launchpad.net/bugs/981048
 * mlankhorst has a hacky setup that basically does the same :x
<bryceh> since we're not yet advertising hybrid support, wondering if this should be disabled.  if it ends up being flimsy, then is going to be tough to support post-release
<Sarvatt> huh? i thought nvidia-current-updates_hybrid.conf would be part of the hybrid-detect part but its installing the blacklist as nvidia-current-updates_hybrid.conf?
<Sarvatt> i guess hybrid-detect is writing out a new blacklist outside of the package
<bryceh> eek
<Sarvatt> dont see it doing that looking at it though, its just calling update-alternatives to switch
<bryceh> hmm
<Sarvatt> what the heck is nvidia-current-updates_hybrid.conf
<kklimonda> what does hybrid-detect do?
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/956091 is the same bug
<ubottu> Launchpad bug 956091 in jockey (Ubuntu) "Jockey does not remove 'nouveau' driver blacklist when deactivating nvidia driver" [Undecided,New]
<mlankhorst> yikes
<Sarvatt> where is this _hybrid suffix coming from?
<bryceh> https://wiki.ubuntu.com/X/HybridGraphics
<bryceh> unfortunately that page doesn't document the _hybrid bits
<bryceh> but I propose we add Q's there for alberto to fill in
<Sarvatt> the alternatives setting up the modprobe.d conf file to /etc dont know about whatever this _hybrid.conf version is so its getting left there
<kklimonda> ah, interesting - I've wrote something similar to switch betwee nvidia and virtualbox gfx, but put it into initramfs as it seemed easier to avoid potential race between changing gpu and launching lightdm
<Sarvatt> i dont see hybrid-detect setting any thing special up there, its just calling update-alternatives and ldconfig to switch between mesa and nvidia if the gpu changes since the last boot
<Sarvatt> tseliot: any clues whats going on?
<kklimonda> ah, I can see how starting works now - clever little thing, I wonder if systemd has something similar
<tseliot> Sarvatt: doesn't it work if you remove the package with --purge?
<Sarvatt> oh ok nvidia changed a bit, ./debian/rules:               $(CURDIR)/debian/$(PKG_driver)$(sysconfdir)/modprobe.d/$(PKG_driver)_hybrid.conf
<tseliot> oh and in the postrm I have rm -f /etc/modprobe.d/#DRIVERNAME#_hybrid.conf
<tseliot> this was introduced in 295.33-0ubuntu1
<tseliot> to fix bug #958848
<ubottu> Launchpad bug 958848 in NVIDIA Drivers Ubuntu "nouveau remains blacklisted after uninstall of nvidia drivers" [Undecided,New] https://launchpad.net/bugs/958848
<Sarvatt> i wonder if they are installing from a ppa without that change, the postrm looks right to me
<Sarvatt> and i cant find any version info in the bug
<bryceh> Sarvatt, yeah both the bug and dupe were filed against jockey which (ironically) doesn't include version info for nvidia
<Sarvatt> but that doesnt make sense, 295.40 went into precise right away
<Sarvatt> installing nvidia and removing it to see if i can reproduce
<Sarvatt> both apt-get remove and apt-get purge removed it but i can't test jockey deactivate because no nvidias here
<Sarvatt> err, i guess it only happens on actual hybrids even? lrwxrwxrwx   1 root root   47 Apr 16 13:00 nvidia-graphics-drivers.conf -> /etc/alternatives/i386-linux-gnu_nvidia_modconf
<Sarvatt> bryceh: oh rereading it and the key word is disabled
<Sarvatt>   * debian/rules:
<Sarvatt>     - Make sure that nouveau is blacklisted even when nvidia
<Sarvatt>       is disabled. This is necessary in order to get hybrid
<Sarvatt>       graphics to work.
<Sarvatt> sounds like tseliot intentionally did that
<tseliot> Sarvatt: yes, otherwise nvidia couldn't be loaded
<bryceh> ah
<bryceh> hmm
<tseliot> and I can't rebuild the initramfs on boot after blacklisting nouveau and require a reboot ;)
<tseliot> Sarvatt: if the file is removed both with and without --purge I guess your problem is solved as Jockey simply calls apt-get remove
<tseliot> through libapt
<Sarvatt> tseliot: the file isnt even getting installed here
<Sarvatt> thats why remove/purge works
<tseliot> Sarvatt: can you try apt-get install --reinstall nvidia-current
<tseliot> or, even better, purge it and then install it again
<tseliot> if the file is removed when the package is upgraded then something's wrong
<Sarvatt> i just did that but trying again
<Sarvatt> now i have the _hybrid one, wth!
<tseliot> :)
<tseliot> the mysteries of apt... ;)
<tseliot> I should probably make sure that the file is there, somehow...
<tseliot> but I wouldn't know how to reproduce it
<Sarvatt> well a lot of people are complaining because they can't use bumblebee now because of it
<Sarvatt> by a lot i mean 1 that i've seen
<tseliot> Sarvatt: :)
<tseliot> Sarvatt: why? Does Bumblebee use nouveau?
<tseliot> I thought it used intel + nvidia
<jcristau> i thought it used duct tape
<tseliot> that should work too :P
 * mlankhorst doesn't know ;s
 * tseliot -> dinner
<cprofitt> Sarvatt: is there anything else I need on the bug https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982710
<ubottu> Launchpad bug 982710 in nvidia-graphics-drivers (Ubuntu) "Nvidia 295.40 - Ubuntu 12.04 Beta 2 Fresh Install (slow performance in Unity 3D)" [Medium,Triaged]
<cprofitt> I looked at the triage documentation and did not see anything special for video cards...
<cprofitt> so marked it triaged... but if you see something that is needed please let me know
<cprofitt> thanks again for you assistance yesterday
<bryceh> cprofitt, you should mention the gpu lockup on your report to the upstream forum
<bryceh> cprofitt, I assume you did a purge and reinstall?
<tjaalton> bryceh: forgot to git add the xserver patch?
<tjaalton> ah no, it was added earlier
<tjaalton> is that patch upstream?
<tjaalton> assuming it isn't, added a note to the bug
<bryceh> tjaalton, drive-by contrib presumably
<tjaalton> right
<bryceh> if he doesn't send it in, I'll try to remember to forward them later.  there's a handful of other nullptr patches in our tree that should go up.
<bryceh> tjaalton, I quit bothering sending them in when peter kept rejecting them as "just papering over problems"  ;-)
<tjaalton> bryceh: yeah, the next cycle would be great time to try again :)
<bryceh> tjaalton, what I think we may want to do is once 12.10 opens, any of the nullptrs that look like they got fixed some other way upstream, drop the patches and see if the bugs come back.  They'll be trivial enough to diagnose if they come back.
<tjaalton> yeah
<cprofitt> bryceh: I actually did a purge and reinstall... then a complete fresh install and only installed the video driver
<bryceh> cprofitt, ok
<bryceh> cprofitt, I think next step may be to wait on word from your upstreamed bug (thanks for doing that)
<bryceh> cprofitt, sounds like workaround is to downgrade to .33 or .20?
<cprofitt> bryceh: yep -- going to try that as well... though may not get to it tonight -- Cub Scouts (I am the lucky Den Leader)
<cprofitt> by the way you guys in here have been fantastic... it is much appreciated.
<bryceh> cprofitt, Be Prepared!
 * cprofitt smiles
<cprofitt> yep
<jcristau> cnd: do you plan on sending the displayid patch to keithp?
<jcristau> err displayfd
<cnd> jcristau, he's Cc'd
<cnd> do I need to do anything else?
<jcristau> hmm.  usually not.
<Sarvatt> RAOF: http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/29956
<FernandoMiguel> boua noute
<bryceh> Sarvatt, bug #982889 is another "X starting faster than drm is ready" bug, but with -intel
<ubottu> Launchpad bug 982889 in xserver-xorg-video-intel (Ubuntu) "xorg fails to start after boot on core i5" [Undecided,New] https://launchpad.net/bugs/982889
<Sarvatt> [     2.441] 
<Sarvatt> X.Org X Server 1.11.3
<Sarvatt> are you freaking kidding me?
 * Sarvatt drools on that person's SSD speed :)
<bryceh> and it's done by 2.555
<bryceh> 0.1sec X.org
<Sarvatt> lightdm used to try starting x on 6 displays before giving up but it changed to just 1, sure would be nice to get that old functionality back to avoid these bugs since i have no clue how to fix it in the upstart scripts
<bryceh> it's an Intel Z68 board
<bryceh> wonder if he's OCing it
<Sarvatt> i915 is ready 2.76 seconds in, x gives up 2.55, sheesh
<bryceh> Sarvatt, having lightdm retry 6 times seems a bit hacky
<bryceh> Sarvatt, I think upstart is the best way to do it, but if it can't be done that way, and if having lightdm do it is too hacky, could we just put the retry into X itself?
<bryceh> whereever it's trying to load the drm driver, if it isn't there make it sleep 1 sec, try again, repeat 5-10 times before giving up?
<bryceh> hmm, ok apparently ^that is the way to do it, as per slangasek and apw.
<apw> bryceh, i am not sure how long the load can take, i'd probabally do a couple immediaitly before any sleeping
<apw> bryceh, it would cirtainly be good to know it was that EAGAIN you were hitting either way
<bryceh> apw, unfortunately I *think* the code that loads the kernel module is in the ddx drivers
<bryceh> in which case, this'd be doable for -intel but no go on the blobs
<bryceh> ok, looks like the logic in question is in libdrm.  hrm.
<Sarvatt> looks like cprofitt isnt the only one http://phoronix.com/forums/showthread.php?70452-Did-The-NVIDIA-295-40-Linux-Driver-Fall-Off-A-Cliff&p=258872#post258872
<bjsnider> just with the 8800gts?
<Sarvatt> yeah looks like old IGP ones are busted, and 320mb versions of 8800gts are slow from all the reports
<Sarvatt> cnd: any way to disable the 4 finger tap gesture?
<cnd> Sarvatt, not that I know of
<Sarvatt> i'm bringing up the dash just from 2 finger scrolling too much
<cnd> why?
<cnd> hmm...
<cnd> that's odd
<cnd> are you accidentally touches with four fingers?
<cnd> touching*
<Sarvatt> probably because i use the middle and ring fingers and the pinky and index are hovering over the pad
<Sarvatt> yeah accidental 4 finger tap
#ubuntu-x 2012-04-17
<Sarvatt> cant just install ginn and reassign the 4 finger tap gesture?
<cnd> Sarvatt, no
<cnd> unity has a root window grab
<cnd> which takes precedence
<cnd> there's no way to override it without telling unity to stop doing it
<cnd> Sarvatt, it sounds like maybe our touch stack shouldn't listen to touches that are below a certain threshold for pressure or width
<cnd> maybe you could play around with utouch-frame to make it ignore touches until they cross a threshold?
<RAOF> Sarvatt: Winning!
<RAOF> :(*
<bjsnider> RAOF is a big chuck sheen fan
<RAOF> Am I?
<bryceh> yes he's a wizard
<RAOF> I should use âwizardâ as a superlative more often.
<Sarvatt> hmm http://paste.ubuntu.com/933420/
 * Sarvatt wonders why he always finds bugs at 11pm when hes trying to go to sleep :)
<RAOF> Because your tired brain is less able to filter out all the strange behaviour :)
<bjsnider> answer: it's the curse of working from home
<Sarvatt> cnd: which update in the past week actually turned the 4 finger gestures back on?
<Sarvatt> i cant find it in the changelogs
<Sarvatt> its getting triggered from 2 finger scrolling 100% for sure, switched how i'm scrolling and absolutely only doing 2 finger :(
<Sarvatt> Warning: failed to get previous touch value
<Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:207): failed to get touch from frame
<Sarvatt> those get spammed when it happens
<Sarvatt> heh whole screen is stuck orange now that i figured out what 3 finger pinch does
<Sarvatt> RAOF: caught the bouquet? :)
<RAOF> Sarvatt: It didn't get thrown :)
<Sarvatt> oh all the bridesmaids have the same one in an earlier pic
<RAOF> Ah, yes.
<cnd> Sarvatt, there were some fixes in unity 5.10
<cnd> in particular, three touch pinch was fixed so it works again
<cnd> and three touch gestures in general work again due to a fix in the window finding code
<cnd> nothing really changed in four touch handling though
<Sarvatt> thats... weird
<Sarvatt> it 100% for sure wasnt working a week ago
 * Sarvatt disables coasting and hopes that has a knock off effect at stopping making dragging trigger it then
<cnd> Sarvatt, there may have been some fixes in the utouch stack
<cnd> but nothing really comes to mind
<Sarvatt> if that fixes it i'm gonna be bummed, the coasting is super nice
<Sarvatt> downgrading to synaptics 1.5.99.902-0ubuntu4
<Sarvatt> oh freaking fun, that actually does seem to have fixed it
 * Sarvatt gives it a day to be sure but i could trigger it just 2 finger scrolling for 10 seconds before making it pop up the dash
<RAOF> That sounds like the dash is receiving scroll events or somesuch?
<Sarvatt> well its getting stuck sending touch events that arent really happening for some reason, i had 3MB of Warning: failed to get previous touch value in ~/.xsession-errors with 1.5.99.902-0ubuntu5
<Sarvatt> from ~8 hours uptime
<Sarvatt> that stinks, coasting was nice :)
<Sarvatt> its definitely fixed not popping up the dash all the time on macs with 1.5.99.902-0ubuntu4
<cnd> Sarvatt, I'm not sure how coasting could be involved
<cnd> but we have coasting turned off anyways in ubuntu
<cnd> because synaptics coasting is a terrible hack
<cnd> :)
<Sarvatt> cnd:  have you seen 1.5.99.902-0ubuntu5? ignore the commit message in the patch, it was altered when it got uploaded
<Sarvatt> i'd bet 10 beers at uds that patch was causing the spurious dash popups on bcm5974, been scrolling for 5 minutes now and havent triggered it
<cnd> Sarvatt, are you turning the momentum on yourself?
<Sarvatt> no
<cnd> it should be disabled ootb
<cnd> hmm...
<cnd> how is it getting turned on?
<Sarvatt> straight stock, with that patch coasting works out of the box
<cnd> there's a problem here...
<Sarvatt> when its coasting its getting stuck sending craploads of invalid touch events and eventually thinking 2 fingers touch is a 4 finger touch
<Sarvatt> if i interrupt the coast and change directions the dash pops up
<cnd> I don't understand why it would be sending touch events
<cnd> but still, coasting should be off by default
<Sarvatt> whats the coasting property you're thinking of?
<Sarvatt> with 1.5.99.902-0ubuntu5 2 finger scroll coasts with no changes, its definitely on
<cnd> I'm pretty sure that in the past I patched ubuntu's synaptics to disable scroll coasting
<cnd> but I confirm it is enabled by default
<cnd> Sarvatt, this is the bug I was thinking of: https://bugs.launchpad.net/xorg-driver-synaptics/+bug/728643
<ubottu> Launchpad bug 728643 in xserver-xorg-input-synaptics (Ubuntu) "Kinetic scrolling improperly interacts with modifier keys" [Undecided,Won't fix]
<cnd> I guess I remember the resolution wrong
<Sarvatt> filed https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/983614 to follow up on tomorrow, i cant keep my eyes open anymore and have to pass out :)
<ubottu> Launchpad bug 983614 in xserver-xorg-input-synaptics (Ubuntu) "The dash is opening spuriously with on bcm5974 touchpads with xserver-xorg-input-synaptics 1.5.99.902-0ubuntu5" [Undecided,New]
<Sarvatt> cnd: bugfix: make clickpads have a button area is still an ok "bug fix" imo personally even still this late :) only people who complained were on apple where the button area is blocked with the upstream synaptics xorg.conf.d file
<Sarvatt> have you ever seen a non apple without a button area? i haven't
<Sarvatt> lots of bugs on it that could be closed
 * Sarvatt feels bad for complaining when it was initially enabled now when disabling it for macs was such an easy fix
<cnd> Sarvatt, there's nothing stopping you from proposing the fix?
<cnd> I won't stand in your way :)
<cnd> I think it would probably be fine either way, but I don't have a strong enough opinion to fight for it
<cprofitt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/982710
<ubottu> Launchpad bug 982710 in nvidia-graphics-drivers (Ubuntu) "Nvidia 295.40 - Ubuntu 12.04 Beta 2 Fresh Install (slow performance in Unity 3D, and EQ Overflow)" [High,Triaged]
<cprofitt> Nvidia has acknowledged and is aware
<cprofitt> http://www.nvnews.net/vbulletin/showthread.php?t=178460
<tjaalton> seb128: btw, I think we should drop the current wacom patch on g-s-d and go with http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=e40cb71a910164d1cb2c366d3c001eeaac79aaaf instead (edited to apply)
<seb128> tjaalton, feel free to do an upload ;-)
<tjaalton> seb128: oh right, sure
<seb128> tjaalton, I though that was not working though?
<tjaalton> seb128: it isn't but it's a step in the right direction
<tjaalton> current one actually regresses for some
<tjaalton> since the function returns random data
<seb128> ok
<tjaalton> oh, it's already in 3.4.1, so we're good :)
<tjaalton> or is it
<tjaalton> it is
<seb128> tjaalton, right
<seb128> tjaalton, it got merged before the tarball
<tjaalton> yeah
<bryceh> heh https://bugs.freedesktop.org/show_bug.cgi?id=48652#c39
<ubottu> Freedesktop bug 48652 in DRM/Intel "only external screen is working with asus zenbook ux31e [CPU eDP]" [Major,New: ]
<hyperair> RAOF: ping. do you happen to find that the pixel-perfect scrolling from synaptics hangs up every now and then in precise?
#ubuntu-x 2012-04-18
<RAOF> hyperair: What do you mean by "pixel perfect scrolling"?  You mean the smooth-scrolling that gtk3 gets?
<hyperair> RAOF: yeah that
<hyperair> RAOF: i just wrote a small test program that dumps out the delta_x/y that it receives via GDK_SMOOTH_SCROLL_MASK, and will test it otu the next time my scrolling freezes up
<RAOF> I've noticed that it dies in evolution sometimes, but I chalked that up to evolution struggling on the challenging internet connection I have here.
<hyperair> hmm
<hyperair> in this case it dies in everything that uses Gtk3's GtkScrolledWindow
<hyperair> the last time this happened, i ran an evince window in gdb and found that it was generating + and - delta_y events which were cancelling each other out
<RAOF> Ah, right.
<RAOF> Yeah, now noticed that.
<hyperair> reloading the psmouse module fixes it
<RAOF> http://paste2.org/p/1983874
<RAOF> Ra raw.
<RAOF> That's test-xi2 output.
<RAOF> Looks like the raw valuator is fine, but the cooked valuator is stuck at -2147483648.00
<hyperair> what's this cooked valuator?
<RAOF> The thing that GTK listens to.
<hyperair> hm
<RAOF> ie: it's the value of the axis after any acceleration, processing, etc.
<hyperair> i see
<hyperair> Sarvatt: ping
<hyperair> what's the gesture that's hooked up to opening the dash?
<Sarvatt> hyperair: 4 finger tap
<hyperair> hmm
<hyperair> how does 2 finger scrolling end up as a 4 finger tap..
<hyperair> and in the first place, how is utouch even working when the utouch patch has been disabled?
<hyperair> RAOF: is it safe to bring up the 117_gestures.patch yet?
<hyperair> perhaps that's the key to this
<Sarvatt> 117_gestures.patch is obsolete after real multitouch
<hyperair> i see
<hyperair> i'm not getting "real multitouch" on my laptop though
<hyperair> evince and eog no longer respond to pinch and rotate
<hyperair> could you try disabling coasting and seeing if that helps?
<hyperair> CoastingSpeed=0
 * RAOF suspects integer overflow
<RAOF> Yeah, something's overflowing.
<Sarvatt> well that was fun, took 20 minutes to get into a unity 3d session again trying to restart lightdm, so much for staying off the pc on a sick day :)
<RAOF> Sarvatt: You're sick?  Boo :(
<Sarvatt> was just getting dumped back to the greeter, trying 0ubuntu5 out now
<Sarvatt> odd thing is, i couldn't reproduce it in a guest session
<RAOF> You've probably got an odd setting.
<RAOF> Somewhere.
<RAOF> hyperair: Have you filed a bug?
<Sarvatt> i'll invalidate out the bug if i still dont notice it tomorrow
<RAOF> hyperair: Also, I don't suppose you know whether the same problem occurs with evdev?
<RAOF> Hm, actually, evdev can't duplicate it because it won't have a scroll valuator.  Bah.
<hyperair> RAOF: you mean regarding the valuator?
<hyperair> RAOF: i haven't filed a bug, actually. i was looking for a way to reproduce this
<RAOF> Yeah.
<hyperair> it randomly happens, but often enough to get annoying
<RAOF> hyperair: Well, I'm pretty sure you'll be able to reproduce it by just continually 2-finger scrolling down.
<hyperair> oh it's happened
<hyperair> O_o
<hyperair> hmm turns out that it's emitting GDK_SCROLL events with GDK_SCROLL_SMOOTH direction with delta_x=0 and delta_y=0
<bjsnider> Sarvatt, turns out the 295.40 blob doesn't work on anything less than or equal to the g80, which is what the 8800gts.gtx have. that's a minor snafu
<RAOF> hyperair: Yeah, that's exactly right.
<RAOF> And if you check out xinput test-xi2, you'll find that the scroll events all have a valuator of -2147483648.00
<RAOF> And it's *stuck* on that value, so delta_x is obviously 0.
<hyperair> RAOF: no, delta_y
<hyperair> delta_x is still working
<RAOF> Bah, that's what I meant.
<hyperair> heheh
<hyperair> where's test-xi2 anyway?
<RAOF> xinput test-xi2 $DEVICEID
<hyperair> whoops, when i scroll on that window compiz detects it on the root window (i think) and switches the deskto
<kklimonda> how are fglrx packages versioned? the amd driver on their website has version 12.3, but we are at 2:8.960
<jcristau> "weirdly"
<tjaalton> right
<kklimonda> well, that I can see ;
<kklimonda> ;)
<tjaalton> the version we have is what the driver says it is. amd uses some year.release schema
<kklimonda> tjaalton: that's.. confusing
<kklimonda> people go to the amd website, see that their version is at 12.3 and go all like "omg, ubuntu drivers are so out of date - I have to update" and proceed to breaking their system
<tjaalton> tseliot: maybe the fglrx package could mention the "marketing version" on the package description?
<kklimonda> in all the time I've spent on my LoCo channel using upstream nvidia/amd drivers have been the biggest source of support questions
<jcristau> it's all part of an evil plan to make people stop wanting to install those drivers
<kklimonda> also, because people are sort of smart they know they have to remove all the packages with nvidia in the name to install upstream nvidia driver
<kklimonda> and by doing that they remove nvidia-common which would prevent nvidia installer from installing the driver ;)
<tjaalton> good for them
<tjaalton> :)
<kklimonda> and then they go their merry way telling others how bad Ubuntu is ;)
<kklimonda> which isn't that good ;)
<tjaalton> let's move that to jockey then
<tjaalton> dunno
<kklimonda> I'm pretty sure the battle is completely lost
<kklimonda> a lot of new ubuntu users are so called "power users" from windows
<kklimonda> and power users know exactly enough to destroy their systems ;)
<kklimonda> (especially how to copy and paste random scripts from the web)
<tjaalton> yes
<tjaalton> with 'sudo' on every line
<tseliot> tjaalton: do you think they would look for the driver version in the package description?
<tjaalton> tseliot: where do they get the package version?-)
<tseliot> tjaalton: either Jockey or update-manager, I'd say
<tjaalton> doesn't it show the description too
<tseliot> maybe Jockey does it
 * tseliot can't remember
<tseliot> update-manager does not
<tjaalton> just leave it as is
<tseliot> tjaalton: and that would require one more manual step in the packaging
<tjaalton> software-center doesn't show it
<tjaalton> no idea where the text is from
<tseliot> P.S. marketing versions are crazy :P
<JanC> kklimonda: s/power users/tweakers/   ;)
<kklimonda> JanC: potatoe potato ;)
<JanC> nah, lots of power users don't have time to tweak all day
<JanC> although maybe that would only affect the frequency of breaking their system  ;)
<mars> Hi everyone, quick question: I am trying to run intel_gpu_dump on Precise and found that the program is missing.  Was it renamed?
<albert23> mars: you don't need it anymore. If the gpu hangs, it will dump contents automatically in /sys/kernel/debug/dri/0/i915_error_state
<mars> albert23, that's what I thought, thanks
<tjaalton> bryceh: was there a kernel build with drm-intenl-next-queued somewhere? I only see -next on the mainline ppa
<tjaalton> -n
<bryceh> tjaalton, yes
<bryceh> since Intel renames their branch-to-test so frequently we decided to just give it our own naming, which is drm-intel-experimental
<bryceh> currently that maps to daniel's drm-intel-next-queued
<tjaalton> oh there it is
<tjaalton> had to reload the page :)
<bryceh> when they switch to drm-intel-proposed-next-testing-queued-really, we can just update the mapping :-)
<tjaalton> yeah I noticed the discussion you had the other day :)
<bryceh> hopefully if they change it again, we can catch it sooner
<bryceh> seems this time it changed in january, but I only realized it this past week
<tjaalton> jesse asked poolie to test it to see if it fixes bug 745112, that's why I was asking
<ubottu> Launchpad bug 745112 in linux (Ubuntu Precise) "[arrandale] desktop is messed up with external monitors (x86_64)" [High,Triaged] https://launchpad.net/bugs/745112
 * bryceh nods
<bryceh> tjaalton, hey do you know offhand what package provides the scripts for dpkg-reconfigure keyboard-configuration?
<tjaalton> bryceh: keyboard-configuration? :)
<tjaalton> that's the package name being configured
<bryceh> duh, ok thanks :-)
<bryceh> oh, but source package is our old friend console-setup
<tjaalton> yeah, ok
<bryceh> bingo, found the bug :-) 
<tjaalton> is it 985065?
<bryceh> tjaalton, that's right
<cnd> bryceh, as soon as I get a couple more reviewed-bys on my input patches from whot I plan to push a big SRU for xorg-server with them
<cnd> it would help to have someone else on the ubuntu side double check the patches just for sanity
<cnd> I have them all here: http://cgit.freedesktop.org/~cndougla/xserver/log/?h=input-fixes
<cnd> they were all found as I was attempting to fix bug 974887
<ubottu> Launchpad bug 974887 in xorg-server (Ubuntu) "unity 3d touch stops registering clicks" [Medium,In progress] https://launchpad.net/bugs/974887
<cnd> so basically, I'm giving you a heads up, and if you have some spare moments and feel like reviewing them ahead of time, please do
<cnd> RAOF, you too
<cnd> oh, I forgot to mention that I won't be including the last two commits because they would be ABI breaks and I don't think anyone will use them in precise
<bryceh> cnd, ok, got a few plates in the air at the moment, but will review them when things calm down
<cnd> thanks
#ubuntu-x 2012-04-19
<hyperair> RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=48777 <-- i wonder if this would fix the xi2 scroll-jamming issue
<ubottu> Freedesktop bug 48777 in Input/synaptics "While tap-dragging: when approaching the touchpad edge, the cursor snaps to the display edge" [Normal,Assigned: ]
<kklimonda> hum, any idea on bug 800022? people seem to have to export LIBVA_DRIVER_NAME="fglrx" for va-api to work (and some applications not crashing)
<ubottu> Launchpad bug 800022 in fglrx-installer (Ubuntu) "XvBA Hardware Acceleration doesn't work" [Undecided,Confirmed] https://launchpad.net/bugs/800022
<kklimonda> or is it an incorrect link..
<RAOF> hyperair: No, I'm pretty sure that's not it - I talked with whot, and he said it was a known limitation in the implementation that he needs to fix :/
<hyperair> RAOF: you mean the scroll-jamming is a known implementation?
<hyperair> er known limitation
<hyperair> that sucks =\
<RAOF> Apparently so.
<hyperair> is he around?
<hyperair> i'd like to ask which value's overflowing
<hyperair> perhaps we can have a hack in place to stop this from happening
<RAOF> No, he's not.
<RAOF> Why are gentoo users so *aggresively* ignorant when asking for help?
<bryceh> RAOF, :-/
<bryceh> sadly they're that way when giving help sometimes too...
<mlankhorst> Ah ignorant helpers are even worse. :(
<bryceh> cnd, posted reviewed-by to the xorg-devel list for that branch.
<cnd> thanks!
<cnd> I'm preparing an SRU of xorg-server right now
<bryceh> cnd, I didn't spot anything that directly concerns me, it looks fine.  but it seems a lot of code to consider for sru'ing
<cnd> yeah
<cnd> they are all necessary though
<cnd> they're the results of me seeing input lockups and such
<bryceh> there's some changes which are just code refactors, and others (if I understand right?) enable functionality that wasn't functioning before.
<bryceh> cnd, for getting it accepted into sru, if you  could elaborate on those bugs it might help in getting it approved
<cnd> the code refactoring changes were required for subsequent fixes
<cnd> I don't remember any new functionality
<cnd> but I will be sure to provide a detailed summary of the change
<bryceh> cnd, it's certainly possible I just misunderstood some comments as meaning it enabled functionality that wasn't working before
<bryceh> 2efbed23 "When activating an explicit grab, update owning listener" I guess was the one that I wondered about being new functionality.  
<bryceh> cnd, anyway, other than that, good work!  hope the sru goes in smoothly.
<cnd> bryceh, ahh yes
<cnd> that is kinda new functionality, kinda bug fix
<cnd> but without it, popup menus won't work
<cnd> so if on a touchscreen you press on a gtk app menu
<cnd> or in the menu bar
<cnd> and you hold as the menu drops down
<cnd> then you drag your finger down
<cnd> without the change, the menu won't see the events
<cnd> and you have to lift your finger and touch again to actually select an item
<bryceh> ah, yeah that does sound like a bug fix.  Was it working previously or has it just never worked?
<cnd> it was working previously because another bug was shadowing it :)
<cnd> whot had been telling some folks that he thought it wasn't really fixable
<cnd> some of the gtk devs had asked
<cnd> so it's new functionality in that it wasn't a bug that was planned to be fixed :)
<bryceh> interesting
<bryceh> cnd, maybe just toss a sentence in the description like "Fixes broken popup menus, where they fail to..."
<cnd> yeah
<bryceh> do we have a bug # open for that?  if so link that in too.
<bryceh> cnd, also, are all these patches together one bug fix, or do they address distinct problems?  I suspect if you can break it into several SRUs they'll go through the process faster than going in as one big lump
<bryceh> but maybe chat up one of the SRU admins about that, maybe it doesn't matter (or would be more work than worth)
<cnd> bryceh, I'm targeting them to bug 974887
<ubottu> Launchpad bug 974887 in xorg-server (Ubuntu) "unity 3d touch stops registering clicks" [Medium,In progress] https://launchpad.net/bugs/974887
<cnd> I plan to note each patch individually to explain why it's needed
<cnd> but in the packaging it will be one big squashed patch
<bryceh> cnd, ok
<bryceh> Sarvatt, what do you think the regression potential is for the SRU bug #968218 ?
<ubottu> Launchpad bug 968218 in libxi (Ubuntu Oneiric) "ssh x11 forwarding precise to oneiric causes glibc malloc(): memory corruption" [High,Triaged] https://launchpad.net/bugs/968218
<jcristau> ha, reminds me of bugs.debian.org/660411
<bryceh> jcristau, indeed, it's the same bug (and same patch).  thanks for the pointer
<jcristau> you're not fixing that for the older releases?
<jcristau> it's still somewhere on my to-do list to fix it in squeeze... (http://bugs.debian.org/661652)
<ubottu> Debian bug 661652 in release.debian.org "pu: package libxi/2:1.3-7" [Normal,Open]
<bryceh> jcristau, looks like the SRU was proposed only for oneiric.  but if the issue is affecting earlier releases, would certainly make sense to sru it for those as well.
<jcristau> it affects squeeze so presumably also lucid
<cnd> argh!
<cnd> why is the escape key mapped to "delete everything I just wrote in the bug description update"
<cnd> I often hit escape out of habit because I'm a vi user
<cnd> and I just lost a good 20 minutes of write up
<jcristau> sometimes i do that with ^w
<bryceh> Sarvatt, mind doublechecking my hackjob on your patch?  https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/968218/comments/16
<ubottu> Launchpad bug 968218 in libxi (Ubuntu Oneiric) "ssh x11 forwarding precise to oneiric causes glibc malloc(): memory corruption" [High,Triaged]
<Sarvatt> bryceh: the upstream commit should apply directly?
<jcristau> Sarvatt: not to lucid
<jcristau> bryceh: http://anonscm.debian.org/gitweb/?p=users/jcristau/libxi.git;a=commitdiff;h=d33c64350c961e3b096565b30e1e98f7c9a569dc is what i had if that helps
<jcristau> Sarvatt: (no touch / scroll stuff in XI 2.0)
<bryceh> jcristau, thanks
<cnd> bryceh, do you have a bug for the change you made to xorg-server for re-enabling patch 227?
<cnd> or: how should we propose the SRU with the touch changes and that change?
<bryceh> cnd, 930936 would be the bug
<cnd> bryceh, how did it get disabled?
<cnd> oh, it was never enabled...
<cnd> d8e24bf6634b0ef80a21ac1d1b13412d88aa7800
<cnd> oops
<cnd> http://paste.ubuntu.com/937318/
<cnd> bryceh, I've updated the bug report for the SRU
<bryceh> cnd, ok thanks
<Sarvatt> note to self: don't try cnd's crack jupiter ppa :)
<cnd> Sarvatt, huh?
<Sarvatt> pointer acceleration is all screwed up in 0ubuntu11~jupiter7
<cnd> really?
<cnd> I just uploaded to proposed
<Sarvatt> moving 1 finger from top to bottom at a steady speed, the acceleration is all over the place
<cnd> so if it's broken I need to fix it
<cnd> Sarvatt, what device?
<Sarvatt> bcm5974, macbook air 4,2
<cnd> I don't have any issues here
#ubuntu-x 2012-04-20
<bryceh> WHEW!
<bryceh> all the gpu lockup bugs worth forwarding are now forwarded upstream.
<Sarvatt> hyperair: so i'm getting random 4 finger taps being registered with 0ubuntu5 synaptics again, what a headache
<Sarvatt> i downgraded to 0ubuntu4 for 2 days so was positive it never happened there :(
<Sarvatt> tried every permutation of disabling coasting i could find
<hyperair> hmm that's really weird
<hyperair> i didn't touch anything in there that should even remotely affect taps..
<hyperair> or finger counting
<Sarvatt> synclient CoastingSpeed=0 should definitely be disabling coasting completely
<hyperair> yes it should
<Sarvatt> yeah input is just screwed on this thing
<hyperair> =\
<Sarvatt> i have megs of Warning: failed to get previous touch value in ~/.xsession-errors, theres "something" really wrong going on
<Sarvatt> Warning: failed to get previous touch value
<Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:207): failed to get touch from frame gets spammed like 8 times every tme the dash gets popped up
<Sarvatt> s/tme/the/
<Sarvatt> i'm sure it has nothing to do with the synaptics change ya did and no problems just downgrading here, its just exacerbating the real problem
<Sarvatt> that happens even without the coasting working it just doesnt pop up the dash when it is
<bryceh> heh, every time we get a new nvidia there's some contingent of folks that want the prior one
<mlankhorst> bryceh: that's true for EVERY change
<mlankhorst> it doesn't even matter what the change is! :D
<bryceh> mlankhorst, heh true enough
<bryceh> guess the nvidia-ites come out of the woodwork is just 'cause there's so many of them
<FernandoMiguel> boua noute
<bdmurray> bryceh: what happened with that touchscreen relative vs absolute change?
<bryceh> bdmurray, right good question.  I was going to test something but got diverted by all the gpu lockups
<bryceh> tjaalton, still need me to test that fix (where was it again?)
<bdmurray> 16:02 < tjaalton> ppa:tjaalton/ppa
<bdmurray> 16:02 < tjaalton> gnome-settings-daemon
<bdmurray> 16:02 < tjaalton> 3.4.0-0ubuntu3.2
<bryceh> thx, on it
<bryceh> tjaalton, bdmurray with Installed: 3.4.0-0ubuntu3.2, on the login screen it works right, but after logging into the session the pointer is moving incorrectly still.  
#ubuntu-x 2012-04-21
<tjaalton> bdmurray: that one is old, precise already has the correct patch included in 3.4.1, but it's not enough
<tjaalton> deleted it from the ppa
<Darxus> [ 8963.997565] EXT4-fs error (device sda1): ext4_ext_search_left:1273: inode #21374007: comm flush-8:0: ix (10742) != EXT_FIRST_INDEX (0) (depth 1)!
<Darxus> I've been having scary hard drive flakyness that seems to correspond to buying my new radeon video card.  http://www.chaosreigns.com/tmp/dancer.2012-04-21.dmesg.txt
<Darxus> Help?
<Darxus> I'm using the Radeon drivers.
<Darxus> With Oneric.
#ubuntu-x 2012-04-22
<Andy80> hi
<Andy80> first of all, thank you so much for making Nvidia 295.33 version of the driver available on your PPA :)
<Andy80> let's see if with this version I don't have all the stability issues I've with 295.40 and my 8800 GS card
<Sarvatt> Andy80: the next nvidia release which fixes it is *extremely* close, shouldnt be too much longer where you have to use that
#ubuntu-x 2013-04-15
<mlankhorst> g'morning
<tjaalton> boo, mesa 9.1 crashes nouveau on suspend
<mlankhorst> I'm not sure that's mesa's fault..
<mlankhorst> what exactly is the error?
<mlankhorst> you could try [PATCH] drm/nouveau: idle all channels before suspending -- it's a hack but meh
<tjaalton> bug 1168900
<ubottu> bug 1168900 in mesa (Ubuntu) "Xorg crashes after suspension with Mesa 9.1.1-0ubunt0.3" [Undecided,Incomplete] https://launchpad.net/bugs/1168900
<tjaalton> i should be able to repro it
<tjaalton> crashes with old mesa too
<tjaalton> so not due to _this_ update, phew
<tjaalton> :)
<tjaalton> looks exa related here as well
<tjaalton> hmm, I'll try with current kernel
<mlankhorst> I had the same issue regardless of mesa
<tjaalton> same thing with 3.9rc6
<mlankhorst> tjaalton: yeah maintainer nacked my patch
<mlankhorst> you could try with it
<tjaalton> you have a kernel built with it?-)
<mlankhorst> not really
<mlankhorst> but you only need to rebuild nouveau, make drivers/gpu/drm/nouveau/nouveau.ko
<tjaalton> alright, seems to build
<tjaalton> but doesn't load
<tjaalton> I'll just build the whole kernel
<mlankhorst> I saw some suspend failures on mailing list that indicated the channels were not halted correctly, and that it was a cause of failure
<mlankhorst> or at least I was guessing based o nevidence :-)
<tjaalton> mlankhorst: nope, still crashes
<mlankhorst> booo
<tjaalton> there seem to be several such reports against raring
<mlankhorst> unsurprisingly, linux 3.7 and later had a drm kernel module rewrite for nouveau
<tjaalton> I'll try 3.6
<tjaalton> still broken
<tjaalton> duped some with bug #1084960
<ubottu> bug 1084960 in xserver-xorg-video-nouveau (Ubuntu) "Resume from Standby mode doesn't work with Nouveau on Geforce GT430" [High,Triaged] https://launchpad.net/bugs/1084960
<mlankhorst> I can actually suspend on my 480
<mlankhorst> but prolonged suspend dies
<tjaalton> suspend works, resume doesn't :)
<mlankhorst> resume works for me on short suspends
<tjaalton> sigh, we still have nvidia-experimental on raring..
<tjaalton> -*
<mlankhorst> :>
<mlankhorst> weird, my config says one thing, but vmlinux indicated another
<mlankhorst> oh make clean doesn't clean everything, grr
<mlankhorst> tjaalton: I may have a fix for the tegra now
<mlankhorst> oops, still missing some part :P
<tjaalton> ok..
<mlankhorst> caused the event queue to overflow
<mlankhorst> blergh dno what the right solution would be, the things related to touch are way too complicated >:(
<mlankhorst> seems the easiest way to reproduce it is to hit the icon in top left, then immediately start a dragging movement, with valgrind enabled it will crash
<seb128> tjaalton, hey, want to get the patch from https://bugs.launchpad.net/ubuntu/+source/libwacom/+bug/1167504 in Debian and then sync the package over so we stay in sync ?
<ubottu> Launchpad bug 1167504 in libwacom (Ubuntu) "screen rotation for finger input fails on x230t" [Undecided,New]
<tjaalton> seb128: yeah, sounds like a plan
<seb128> tjaalton, thanks
<tjaalton> there was a patch upstream already
<tjaalton> not in git yet though but I'll steal it
<mlankhorst> push it upstream? :P
<tjaalton> it's on git.gnome.or
<tjaalton> g
<tjaalton> seb128: I'll upload it later today or early tomorrow so we can still sync it for raring
<seb128> tjaalton, thanks
<seb128> tjaalton, I will assign to you/unsubscribe sponsors
<tjaalton> assigned already
<tjaalton> and poof sponsors gone
<seb128> ;-)
<mlankhorst> ah right, I only have access to fd.org
<mlankhorst> oh wow..
<mlankhorst> *motion_event = *event; I suddenly get why that line was wrong ._.
<sarnold> my thinkpad's brightness keys don't work well in raring; another lenovo and an acer user reported the same thing on my bug report. I might have mis-filed it in the first place, and recently heard that gnome-settings-daemon might be the proper target -- but got other advice to come here and ask :)
<sarnold> so, should this bug be re-assigned somwhere else? https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1156477
<ubottu> Launchpad bug 1156477 in gnome-settings-daemon (Ubuntu) "laptop brightness keys regression" [Undecided,Confirmed]
<jwi> sarnold: it's a firmware issue actually (at least the thinkpad one) - duplicate of bug 1098216
<ubottu> bug 1098216 in linux (Ubuntu) "Regression in brightness control on Lenovo Thinkpad X230 and X1 Carbon" [Medium,Triaged] https://launchpad.net/bugs/1098216
<jwi> try pressing the brightness keys ten times in a row, just for giggles?
<sarnold> jwi: wow, thanks!
<sarnold> jwi: the results depends upon the brightness setting I set with /usr/lib/gnome-settings-daemon/gsd-backlight-helper --set-brightness -- if I set it to '90', no amount of key banging changes the brightness again.
<sarnold> jwi: if I set it to '70', the brightness changes quite a lot, but I can't get it to maximum brightness, even with my best key-banging
<jwi> sarnold: so it's even weirder than I thought it was. thanks lenovo.
<sarnold> jwi: no kidding. I bought a lenovo 'cause I figured they wouldn't do anything stupid. like this. heh. :)
#ubuntu-x 2013-04-16
<mlankhorst> tjaalton: ugh, you're now aware that reverting video abi 14 to 13 is just 2 comits
<tjaalton> yes
<tjaalton> it still would've needed unity devs to port to it so it's backportable
<tjaalton> if you meant pushing it to raring earlier
<mlankhorst> yeah
<mlankhorst> plus unity devs would need to add fallback code for precise to work on both
<tjaalton> yeah that's what I meant
<tjaalton> they still need to :)
<mlankhorst> sadly
<mlankhorst> tjaalton: do I need to do anything else except revert the GET_REQUIRED_HW change? tegra is crashing
<mlankhorst> oh, looks like 048674a6aeb61149a1b5f6b0bc3762ddf57f38ee is wrong for arm
<tjaalton> hmm, I reverted other stuff too
<tjaalton> not just two commits it seems
<tjaalton> http://pastebin.com/XartYGns
<mlankhorst> ah
<mlankhorst> are the dix commits needed? tegra hooks into input?
<mlankhorst> tjaalton: anyway I am getting same results on my nvc0 as on my other card I was testing with
<mlankhorst> so looks good to me
<mlankhorst> except the copy problems that were already fixed :-)
<tjaalton> oh mesa?
<tjaalton> can't remember why I reverted all those
<tjaalton> probably out of laziness
<mlankhorst> yeah
<mlankhorst> maybe not, still crashes
<mlankhorst> tjaalton: can you try ssh://people.freedesktop.org/~whot/xserver whot/touch-grab-race-condition-56578-v2 on the nexus with the abi reversions + rebuilding evdev (just in case) ?
<tjaalton> tried already
<tjaalton> back in the days
<tjaalton> the way it crashes with 1.14 is not like with 1.13
<tjaalton> unless I didn't try that method, changing between dash and indicator menus
<tjaalton> iirc reprod it by simply hitting the indicators a lot
<mlankhorst> tried with the -v2 branch, or the original?
<tjaalton> v2
<tjaalton> 6538ca09ac33842 Merge remote-tracking branch 'whot/touch-grab-race-condition-56578-v2' into nexus
<tjaalton> from my local branch
<mlankhorst> does it have     Xi: Do not handle ET_TouchOwnership in ProcessTouchEvent
<tjaalton> no
<tjaalton> I tried that with 1.13
<mlankhorst> can you put your tree somewhere? I think I'm missing one of the abi revert commits
<tjaalton> all the reverts are on the paste
<tjaalton> I don't have xserver set up anywhere
<tjaalton> git
<mlankhorst> k
<mlankhorst> I was having background issues on x1.14, it was no longer drawn correctly
<tjaalton> same
<mlankhorst> tjaalton: took a lot of effort, but 1.13.3 is failing in the same way for me as 1.14 + touch branch now
 * mlankhorst has magic fingers!
<tjaalton> mlankhorst: oh, cool
<tjaalton> I mean, if you've fixed 1.13 to somehow not fail immediately :)
<tjaalton> final test build of mesa, then upload
<mlankhorst> haha sadly it probably still counts as immediately
<mlankhorst> or at least with my steady hand I can do it in 2 taps
<mlankhorst> I guess I need to reorder the patches first, then do a normal bisection
<mlankhorst> and reorder the corruption fixes to be applied first :)
<tjaalton> mesa uploaded
<tjaalton> -ing
<mlankhorst> want a nv4b test too?
<tjaalton> go for it
<mlankhorst> hm nv43 i mean
<mlankhorst> ooh lockup and crash
<mlankhorst> still on 9.0.3
<mlankhorst> if piglit locks up again, I'll just settle for the 'does it run succesfully to desktop' test instead
<mlankhorst> ok locks up on piglit, plan B :)
<mlankhorst> tegra thing seems to not be a regression from the touch branch, I removed everything from the whot branch and it still happened
<mlankhorst> ok piglit is locking up on 9.1.1 too, but nouveau devs don't put much effort into supporting < nv50 and it boots to desktop, I'll add it to the tested list :)
<mlankhorst> https://errors.ubuntu.com/?user=ubuntu-x-swat&period=day
<tjaalton> yeah, thanks :)
<tjaalton> eod ->
<mlankhorst> eod
<tjaalton> hmm should I upload glamor too..
<tjaalton> anyone here with a radeon hd7xxx?
 * mlankhorst slaps tjaalton with EOD
<tjaalton> waiting for slangasek to react :)
<tjaalton> would be cool to have working radeonsi support in raring, but without any hw to test it with..
<tjaalton> hmm glamor would need to enter main too, so maybe not
* 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.
#ubuntu-x 2013-04-17
<tjaalton> how come we have a bug report about nvidia-319?
<mlankhorst> because people are insane
<ricotz> tjaalton, probably someone using xedgers
<tjaalton> ok, where do I throw it then?
<tjaalton> in the 'invalid' bin?
<ricotz> tjaalton, probably a misconfigured optimus setup
<ricotz> tjaalton, so i guess unsupported/invalid then
<tjaalton> yeah, closed
<tseliot> ricotz: I have packaged the nvidia-modprobe tool which nvidia-319 requires. Is it already in edgers? Shall I upload it there?
<ricotz> tseliot, hi, it isnt in edgers, feel free to upload it there with a matching version suffix
<tseliot> ricotz: ok, good
<ricotz> tseliot, i hope it is debsrc3?
<ricotz> nvidia-settings should be transformed to it too, so the original upstream bz2 tarball can be used
<tseliot> ricotz: yep, the file says 3.0 (quilt)
<ricotz> good :)
<tseliot> ricotz: yes, I can do that too
<bjsnider> tjaalton, it was reported on a package called nvidia-319?
<ricotz> bjsnider, xedgers contains those
<bjsnider> ricotz, you said above that it wasn't in edgers
<bjsnider> or did you just mean the modprobe thing?
<ricotz> bjsnider, i mean the nvidia-319 package
<tjaalton> bjsnider: it mentioned nvidia-319
<tjaalton> against xorg
<mlankhorst> and with that horrible hack posted on the switching stack bug, I declare EOD
<tjaalton> omg, bug 1170074
<ubottu> bug 1170074 in mesa (Ubuntu) "April 17 Mesa update introduced regressions" [Undecided,New] https://launchpad.net/bugs/1170074
<tjaalton> a game doesn't work on nouveau
<tjaalton> updated the headline
<mlankhorst> meh ill look tomorrow
<mlankhorst> finally something interesting nouveau wise ;D
<smallfoot-> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1170074
<ubottu> Launchpad bug 1170074 in mesa (Ubuntu) "mesa 9.1 regressed Tibia on nouveau" [Undecided,New]
<smallfoot-> April 17 Mesa update introduced regressions
<tjaalton> ha, updated the headline already ;)
<smallfoot-> I am on a GeForce 8600 using nouvoue driver, Tibia worked yesterday, today it doesn't
<smallfoot-> ah, I see
<smallfoot-> yeah, I don't know if its just on nouvoue or on across the board of all Mesa
<mlankhorst> is there a demo or something?
<smallfoot-> yes
<smallfoot-> http://static.tibia.com/download/tibia985.tgz
<smallfoot-> around 25 mb
<tjaalton> url on the bug
<smallfoot-> it segfaults on startup
<smallfoot-> commercial proprietary game by CipSoft GmbH, german company, the executable is clean
<tjaalton> pastebin the segfault?
<mlankhorst> It's eod, but I'll look at it first thing in the morning..
<smallfoot-> the segfault is just "Segmentation fault", nothing more
<smallfoot-> eod?
<smallfoot-> end of day? oh, I see
<tjaalton> here it just complains about libGL.so.1
<smallfoot-> oh sorry, I forgot to mention that
<smallfoot-> if you're on ubuntu 64, you might need to install ia32libs
<tjaalton> k
<smallfoot-> as the tibia binary is 32-bit only
<mlankhorst> tjaalton: dont you dare ;P
<tjaalton> heh
<tjaalton> works fine on intel anyway
<mlankhorst> good!
<mlankhorst> I was afraid I'd have to break into your home and leave your toilet seat up, then you'd get in trouble with your significant other, bahahha
<tjaalton> she's not around
<tjaalton> :)
<tjaalton> kids are, but asleep by now
<tjaalton> apitrace doesn't seem to work
<tjaalton> so I'll just skip and let you deal with it tomorrow
<smallfoot-> so its nouvoue specific, possibly nv50 specific
<bryce> smallfoot-, can you run `gdb Tibia`, then `bt full` and paste the output of that into the bug?
<smallfoot-> Okay
<smallfoot-> "No stack."
<smallfoot-> :(
<bryce> smallfoot-, ah sorry, do `run`, then let it crash, and then do `bt full`
<smallfoot-> oh
<smallfoot-> http://paste.ubuntu.com/5716784/
<bryce> smallfoot-, thanks that's helpful.  Mind a few more steps to gather some extra data?
<smallfoot-> sure
<bryce> smallfoot-, apt-get install libgl1-mesa-dri:i386 xserver-xorg-core-dbg 
<bryce> smallfoot-, then repeat the procedure (gdb Tibia, run, then bt full)
<bryce> er wait
<bryce> smallfoot-, apt-get install libgl1-mesa-dri-dbg:i386 xserver-xorg-core-dbg 
<bryce> smallfoot-, then repeat the procedure (gdb Tibia, run, then bt full)
<mlankhorst> don't you need libgl1-mesa-glx-dbg:i386 too?
<bryce> couldn't hurt, but looks like most symbols are in the dri pkg
<smallfoot-> should i get libgl1-mesa-glx-dbg:i386 too?
<bryce> smallfoot-, sure, why not.  
<bryce> the more -dbg's the merrier
<bryce> :-)
<smallfoot-> ok :)
<bryce> bbiab (lunch)
<smallfoot-> http://paste.ubuntu.com/5716822/ -- backtrace with debug libraries
<bryce> smallfoot-, perfect, thanks
<smallfoot-> :)
<bryce>          tmp = 0x4 <Address 0x4 out of bounds>
<smallfoot-> *clueless*
<smallfoot-> hmm adress out of bounds sounds bad :s
<bryce> yup
<bryce> question is why it's set to '4'
<bryce> (memory addresses usually look like 0x88e6e08)
<mlankhorst> no, my mesa bug, and I'll look at it tomorrow :'(
<bryce> fine :-)
<bryce> tjaalton, mesa 9.1.1 changes not pushed to git?
<tjaalton> bryce: still on ubuntu+1
<bryce> mlankhorst:
<bryce>   * Add some more patches to fix image copy regressions on nouveau.
<bryce> ^ would help to list what patches were added, for grepping purposes.
<mlankhorst> I thought I just lazily copied them to debian/patches/series
<tjaalton> the four patches on series
<tjaalton> oh hell
<tjaalton> it still has the patches from anholt commented out :D
<tjaalton> shouldn't be there at all
<mlankhorst> [Supermassive fail (instant)]
<bryce> seems there's some cruft too... patch 116 not in series, and there's two 118's
<mlankhorst> second one needs to be removed
<mlankhorst> merge failure
<mlankhorst> 116 was kept for historical reasons, can be dropped
<tjaalton> I don't have those here
<tjaalton> so probably local cruft?
<smallfoot-> new minor X.org Server was released today, it contains security fix
<mlankhorst> yeah and unless you plug in usb devices and chvt, you won't hit it..
<bryce> tjaalton, ah was looking at the wrong branch
<smallfoot-> Ubuntu has updated their X.org Server?
<bryce> seem to be cleaned up on ubuntu+1.  just need to merge that to ubuntu.
<mlankhorst> I don't know, but it makes me want to look for more vulnerabilities in xserver, to get sru's done faster..
<tjaalton> bryce: yes, actually the other way around, then push the result as ubuntu
<tjaalton> with additional force
<tjaalton> if needed
<tjaalton> actually, easiest is to just add the changelog entry and force push it then as ubuntu
<tjaalton> merging old upstream there ends up in misery
<tjaalton> nevermind, old 'merge -s ours' trick worked
<tjaalton> pushing it
<tjaalton> there
<tjaalton> now pull, and use the ubuntu branch for changes
<Prf_Jakob> Hmm so I tried the beta2 CD on my MacBookPro5.1, in the past I have allways needed to use nomodeset but the X server at least start in the installer now it doesn't start :-/
<tjaalton> does it work without nomodeset?
<Prf_Jakob> nope, nouveau fails to set the mode
<mlankhorst> it would be nice if you come up with those things before it's so close to release ;P
<Prf_Jakob> haha :p
<Prf_Jakob> the nouveau thing is a old bug.
<Prf_Jakob> happens on 12.10
<Prf_Jakob> actually looks like I lied, X doesn't start on the 12.10 installer either.
<Prf_Jakob> Which is weird because I'm pretty sure I installed it via the gui...
<Prf_Jakob> okay got X to work by installing nvidia-current
<bjsnider> Prf_Jakob, what nvidia chip does the crackbook have?
<Prf_Jakob> its a 9400GT/9600GT combo
<bjsnider> surprised there's  nouveau issue on that
<Prf_Jakob> http://www.everymac.com/systems/apple/macbook/specs/macbook-core-2-duo-2.4-aluminum-13-late-2008-unibody-specs.html
<Prf_Jakob> ops no
<bjsnider> isn't the 5.1 newer than 2008?
<Prf_Jakob> http://everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-2-duo-2.8-aluminum-15-late-2008-unibody-specs.html
<Prf_Jakob> nope
<Prf_Jakob> I think there is a 2009 model as well
<Prf_Jakob> ^ thats what I got anyways
#ubuntu-x 2013-04-18
<mlankhorst> Prf_Jakob: NVAF by any chance?
<Prf_Jakob> I don't think so
<Prf_Jakob> I do have a MacBookAir with NVAF tho
<Prf_Jakob> lets see what dmesg says
<Prf_Jakob> mlankhorst: hmm just modprobeing the nouvaue driver with modeset=1 brings down the host
<Prf_Jakob> 02:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9600M GT] (rev a1)
<Prf_Jakob> 03:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9400M] (rev b1)
<mlankhorst> Prf_Jakob: nothing in dmesg?
<Prf_Jakob> when I modprobe?
<mlankhorst> yeah
<Prf_Jakob> its insta-depth
<Prf_Jakob> death*
<mlankhorst> real death or just backlight turning off death?
<Prf_Jakob> death as in network dies
<mlankhorst> oh the death kind of death
<Prf_Jakob> yeah it dies pretty much directly, and tailf /var/log/dmesg doesn't get my anything
<mlankhorst> I dont have hat hardware, sadly
<mlankhorst> a laptop with 2 nvidias would be nice for hacking
<Prf_Jakob> I don't think you can run them both at the same time with that model.
<Prf_Jakob> Some later ones can I think
<mlankhorst> that was my guess, and nouveau will run the POST script if it sees a card being powered down
<mlankhorst> but fixing that would mean adding a static int first; if (first++ == 1) return -ENODEV; (or 0) to the kernel module and a full rebuild
<Prf_Jakob> can't I just blacklist the device somehow?
<mlankhorst> maybe through generic kernel mechanisms, i dont think nouveau has something specific about that
<mlankhorst> hm interesting, the backtrace of tibia has has len  and src reversed
<tjaalton> looks like till was right, adding the one patch from ddrake seems to have fixed stuff on the nexus
<tjaalton> ah, too soon :)
<mlankhorst> hah
<mlankhorst> tjaalton: whot knows the issue, just doesn't know how to fix it
<tjaalton> yeah
<mlankhorst> I was right about the touch still being alive after ungrab :(
<tjaalton> but till claims the two patches fix it for him..
<tjaalton> so I want to prove him wrong :)
<mlankhorst> yeah one of the patches is a workaround for stuff that was fixed by whot's branch, so it's not needed to grab that patch
<mlankhorst> the one from the xorg mailing list
<tjaalton> i'll try it anyway
<mlankhorst> it is only useful when you dont grab whot's branch
<tjaalton> exactly
<mlankhorst> anyway seems the sequence is having a button grab, release button grab, end touchapt
<mlankhorst> -apt
<mlankhorst> ah there we go
<mlankhorst> util/u_mm.c:184:u_mmAllocMem: Assertion `size >= 0' failed.
<mlankhorst> hm weird stuff
<mlankhorst> oh
<mlankhorst> too simple
<mlankhorst> I wonder why it didn't show up during piglit, though..
<mlankhorst> there are some duplicate symbols for some functions with x86 prefix..
<mlankhorst> src/gallium/auxiliary/rtasm/ and src/mesa/x86/rtasm/
<mlankhorst> tjaalton: on a positive note, that does confirm nobody cares about x86 any more
<tjaalton> heh
<mlankhorst> ah well maybe I can update it with the gallium version, they have diverged at one point
<mlankhorst> .. maybe not, sed job time
<mlankhorst> well my hack worked
<ara> hello!
<ara> do you guys know if anyone if having a look to the hangs for sandybridge gpus in raring?
<ara> it happens to me at least once a day
<ara> bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946899
<ubottu> Launchpad bug 946899 in linux (Ubuntu) "[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung" [High,Triaged]
<mlankhorst> oh
<mlankhorst> ara: that's not going to be useful, there's too many potential causes of gpu hangs :/
<tjaalton> ara: does it hang hard?
<tjaalton> or is it just an apport popup you get every now and then
<ara> mlankhorst, it hangs completely
<ara> I need to hard reboot it to bring it back to life
<tjaalton> there are a few things to try. like disabling rc6 power savings, fbc ..
<tjaalton> bbiab ->
<mlankhorst> tjaalton: hm the next time we should just upload next release right away instead of waiting for a fix from intel
<tjaalton> mlankhorst: orly? :)
<tjaalton> but we got lucky with your patch
<mlankhorst> not really, I would have done so anyway regardless day of week
<mlankhorst> very straightforward and obvious to reproduce bug
<mlankhorst> I guess it's time to start worrying about lts-raring uploads now :)
<Dark_light> whos maintaing mesa for 13.08? 
<mlankhorst> there is no 13.08
<Dark_light> mlankhorst: I'm pretty sure it's clear that I meant the beta :P 
<Dark_light> ubuntu 13.08 beta
<Dark_light> who's the mesa maintainer? 
<mlankhorst> what 13.08 beta
<ogra_> 13.08 ?
<ogra_> beta ?
<ogra_> Dark_light, there will be a 13.10 ... definitely no 13.08 
<ogra_> ubuntu releases happen in april (.04) and october (.10)
<ogra_> no releases inbetween
<Dark_light> oh right
<Dark_light> sorry it was a bad typo 
<ogra_> and we dont have maintainers ...
<Dark_light> well a packager
<ogra_> packages are usualy handled by teams
<Dark_light> whoever pushed mesa 
<Dark_light> ok 
<seb128> you better ask your question
<Dark_light> so does this whole team handle all the X packages mesa included? 
<Dark_light> ok
<seb128> or state what you want to know
<ogra_> you could check who uploaded last and talk to him/her ... but even that might just have been a sponsor for a bugfix from the bugtracker
<Dark_light> the mesa 9.1.1 update broke a few things most likely opengl 3.0 related 
<Dark_light> it could be an issue only related to sandy bridge 
<Dark_light> I'm not sure wether it's a regression in mesa itself or if it's a patch that's been applied 
<Dark_light> the only evidence I have is a steam game I'm beta testing that worked mostly fine till I upgraded mesa this morning now it just segfaults 
<Dark_light> I've already talked to the devs but they basically don't care much about  mesa because it's not mature enough I've asked in mesa-dri and they told me to git bisect it to find the cause  
<ogra_> googling for "sandybridge ubuntu bug" gets me bug 1041790 as the first hit
<ubottu> bug 1041790 in xserver-xorg-video-intel (Ubuntu) "[snb] GPU lockup IPEHR: 0x0b160001 IPEHR: 0x0b140001, workaround i915.semaphores=0" [High,Triaged] https://launchpad.net/bugs/1041790
<ogra_> did you consider researching on the bugtracker first ?
<Dark_light> well no since the upgrade has been this morning and I'm on 13.04 how could someone have already reported it?
<Dark_light> also it's not X related 
<Dark_light> it's opengl related most likely
<Dark_light> as everything else is business as usual 
<Dark_light> I have dmp file from the game (that I don't know how to handle) if that can help tracing the root cause
<Sarvatt> Dark_light: what game?
<Dark_light> Sarvatt: Euro trucks simulatr 2
<Sarvatt> guessing you mean euro truck simulator 2 since you mentioned a .dmp file and it being a beta and "mostly fine" would mean 2 fps? :P? http://forum.scssoft.com/viewtopic.php?f=119&t=8346 
<Dark_light> indeed :) 
<Dark_light> not 2 fpses
<Dark_light> here it was working
<Dark_light> almost perfectly
<Dark_light> it had only some issues with flickering and it crashed if the bed icon was red (have to rest) and you opened the map on the menu
<Dark_light> so it was playable 
<smallfoot-> in repository there is mesa 9.1.1-0ubuntu2
<smallfoot-> but 9.1.1-0ubuntu3 is supposed be released
<Sarvatt> looking for bug reports on the mesa bugzilla about it, it's something that will get fixed in 9.1.x updates later if its broken
<smallfoot-> but its not in repo
<Sarvatt> smallfoot-: its in raring-proposed
<smallfoot-> I see!
<smallfoot-> thanks!
<Dark_light> the thing is I don't even know what to report 
<Sarvatt> err
<Sarvatt> https://launchpad.net/ubuntu/raring/+source/mesa/9.1.1-0ubuntu3
<Sarvatt> still says PENDING for some reason
<Dark_light> in the meantime how can I downgrade to 9.0.3 ? 
<smallfoot-> aww
<Dark_light> one of the main reasons I switched to ubuntu was to get proper opengl support for this game .-.
<Sarvatt> did you email them your .dmp?
<Dark_light> Sarvatt: to whome the games dev ? 
<Sarvatt> yeah they were asking for the dumps to be emailed if you have a problem, http://forum.scssoft.com/viewtopic.php?f=119&t=8379&start=10#p22559
<Dark_light> I've already told them about the previous issues but they were very clear on the fact that they couldn't do anything about it, I've emailed about this last issue too but they just stopped answering 
<Dark_light> I'm in a limbo, the games devs say mesa is too immature and mesa's devs are way too busy to care about something like this 
<Dark_light> And I can't fix mesa let alone fixing the game :P 
<Sarvatt> you'd be really surprised, the intel guys really want steam games to work, https://01.org/linuxgraphics/documentation/how-report-bugs-0 would be the best bet for filing a bug if there's any way you'd be willing to do that
<Dark_light> Sarvatt: I can but I'm not really sure what to write besides that the game segfaults when opening the quick job menu 
<Sarvatt> i've got it installing now
<smallfoot-> ubuntu-x rocks, you fixed the bug i reported yesterday in less than 24 hours, and also fixed the X input leak security bug
<Dark_light> Sarvatt: what card are you testing it on? 
<Sarvatt> hd4000, which sandybridge do you have? 2 or 3?
<Sarvatt> err 2000 or 3000
<Dark_light> 3000
<Sarvatt> if it affects that it'll probably affect mine too, but i'll try on a hd3000 if not
<Sarvatt> so how do you reproduce it?
<Sarvatt> just open the quick job menu in game?
<Dark_light> you just start the game and try to get a quick job (I'm not sure on a new account)
<Dark_light> yep
<Dark_light> it loads the map
<Dark_light> and a second after that it crashes 
<Dark_light> *the menu
<Dark_light> it was working ok on 9.0.3
<Dark_light> I would downgrade for now but can't figure out how to this it cleanly with apt-get 
<Sarvatt> i like this game but i'm not crazy enough to run it on an intel igp, its not the fastest even on a gtx 460m :)
<Sarvatt> and looks extra ugly if you lower the quality settings
<Dark_light> meh I don't care that much about the looks plus having a gaming desktop just to play this game and europa universalis would be overkill :P 
<Dark_light> what I wonder though is how come valve's games work mostly fine with mesa while for scssoft it's not mature enough 
<Dark_light> I don't mean to criticise but I just don't get it 
<Dark_light> Sarvatt: just in case how can I downgrade mesa with apt-get? I know the old packages are in /var/cache/apt/archives 
<Sarvatt> its a crapload of packages, you're gonna have to grab them off launchpad.. pastebin the output of dpkg -l "*mesa*" ?
<sarnold> Dark_light: you wouldn't, apt only does one direction... but you can use dpkg --remove and dpkg -i with your .deb files..
<Dark_light> sarnold: http://bpaste.net/show/92392/ 
<Dark_light> ops I meant
<Dark_light> Sarvatt: ^^
<Dark_light> sarnold: but does it resolve the deps too? 
<Dark_light> they are all deps that should be in the archives 
<sarnold> Dark_light: not easily, no :(
<Dark_light> so I should hunt them down one by one, that's going to be fun 
<Dark_light> both regular and multilib 
<Dark_light> I really hope it doesn't come to this :P 
<Dark_light> it's not hard but it's an hassle 
<Sarvatt> start looking into how to pin packages, i'm making up a list of all the files you'll need to download
<Sarvatt> http://paste.ubuntu.com/5719278/
<Sarvatt> ok you want to download those all to some empty directory and sudo dpkg -i *.deb there
<Dark_light> and then lock them 
<Dark_light> right?
<Sarvatt> yeah
#ubuntu-x 2013-04-19
<llstarks> what's the best way to build and test xorg 1.14 right now?
<RAOF> llstarks: It's not in edgers? (I don't follow it, so it may well not be)
<llstarks> it is not
<RAOF> Booo.
<llstarks> and xorg-testers is defunct
<bjsnider> you could grab the source and use the latest xorg-edgers build scripts to build debs
<bjsnider> assuming it doesn't fail for lack of the right symbols and whatnot
<Sarvatt> llstarks: https://launchpad.net/~canonical-x/+archive/x-staging
<Sarvatt> unity wont work with it atm, darn thing gets uploaded every day and needs patches applied :)
<llstarks> wonderful, that should work for my testing. last resort before stressing myself with arch
<llstarks> is unity compiss still being developed or is the transition to qml happening here?
<Sarvatt> i'll upload a new one now
<llstarks> wait, when was 7.0 landed?
<Sarvatt> its in maintenance mode but still lots of stuff happening with it
<Sarvatt> not sure its actually 7.0
<llstarks> that's some feature freeze we've got going on
<Sarvatt> or maybe they'll call the 7.0 features 8.0 in SS :)
<Sarvatt> pretty sure they just bumped it to 7.0 to keep the branches sane after they started landing new stuff and backed it out
<Sarvatt> ok uploaded, give it 45 minutes or so and unity will be fine
<bjsnider> compiss?
<llstarks> compiz is dead. dev disowned it and so did canonical
<llstarks> the last relic of beryl and wobbly windows
<llstarks> the reason i started using ubuntu
<ScottK> Not the last relic.
<ScottK> The compositing code in kwin is a compiz fork.
<llstarks> i keep forgetting that kde exists
<bjsnider> llstarks, you definitely use gnome-shell then
<llstarks> yup
<llstarks> gotta have my insta-search
<bjsnider> it's the only thing a person of conscience should be using, obviously
<bjsnider> i'm not sure what kde's philosophy is at this point, or how it's relevant. would it work on a smartphone or something?
<ScottK> There's plasma active for small tablets
<llstarks> i suppose active plasma or whatever the hell it is would
<ScottK> yes
<MCR> ricotz, hi. I there's a new fglrx beta out for some time now: http://support.amd.com/us/kbarticles/Pages/AMDCatalyst13-3LINBetaDriver.aspx
<MCR> ricotz, could you update xorg-edgers PPA with it please ?
<seb128> intel_do_flush_locked failed: Input/output error
<seb128> shrug, another gpu hang when dnding wins between screen on my i5 docked laptop
 * seb128 reboots
<tjaalton> hmm
<tjaalton> I'll try that
<tjaalton> +to reproduce
<tjaalton> seb128: I tried to reproduce but couldn't, guess it doesn't happen that often?
<seb128> tjaalton, define "often", I don't dare doing dnd between my 2 screens
<tjaalton> otoh, unplugging the tv corrupted the top-half of the laptop panel
<seb128> it happens at least once a day
<seb128> and I do like 5 dnd a day
<tjaalton> seb128: like not immediately
<seb128> no
<seb128> I tend to use the workspace expose and dnd stuff in that view to workaround it
<tjaalton> seb128: could you test what happens on unplug?
<seb128> tjaalton, you mean?
<tjaalton> seb128: unplug the external monitor
<seb128> tjaalton, unplugging what? one of the 2 screens?
<tjaalton> seb128: you have two external monitors, and laptop screen closed?
<tjaalton> lid closed
<seb128> yes
<seb128> well lid is not closed
<seb128> but laptop screen is turned off from the display capplet
<tjaalton> so three screens in total?
<tjaalton> ah
<seb128> I stopped closing the lid because the laptop screen wouldn't be detected on boot
<seb128> and then I can't undock my laptop
<seb128> or rather I can but get no screen :p
<tjaalton> ok, guess you can't test my bug then :)
<tjaalton> file yours btw
<seb128> I unplugged one of the 2 screens
<seb128> that reactivated my laptop screen and moved the content that was on the external that got unplugged to it
<tjaalton> now unplug the other screen
<seb128> replugged the external one and I'm back to my initial config
<tjaalton> k
<seb128> tjaalton, unplugging the second screen leads me with my laptop screen in use and working
<tjaalton> alright, thanks
<tjaalton> I can reproduce this too, bah
<tjaalton> seb128: btw, I think your bug is fixed in 3.9 kernel, but hard to sru :/
<tjaalton> and my bug was bug #1157678
<ubottu> bug 1157678 in xserver-xorg-video-intel (Ubuntu) "[ffe] unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,Fix committed] https://launchpad.net/bugs/1157678
<seb128> tjaalton, you can reproduce the gpu hand on dnd between screens?
<seb128> kernel :-(
<tjaalton> seb128: no, but there are a number of commits to fix pageflip issues, which should help with it
<tjaalton> hey, it's all kernel these days, even more so in the future :)
<tjaalton> maybe some mesa but that's about it
<tjaalton> who forgot to push -intel git?
<tjaalton> bryce: ^ :)
<tjaalton> wth, fixed the lightdm race upstart job by accident..
<tjaalton> ohyes
<tjaalton> http://pastebin.com/2bZu24yG
<tjaalton> ok not that version, but it's still fixed \o/
<mlankhorst> tjaalton: that hack is awful and you should feel awful ;)
<mlankhorst> and the if was unneeded there
<tjaalton> mlankhorst: old version
<tjaalton> slangasek made a better one, and I fixed that too
<tjaalton> here http://pastebin.com/reb2kPJw
<tjaalton> added plymouth --ping, and dropped --no-wait from initctl
<tjaalton> now it's working for both cases, normal and plymouth-in-initrd
<mlankhorst> ah good
<tjaalton> this should be added to plymouth in any case, enabling it in *dm.conf can be left as SRU material if necessary
<llstarks> re xorg 1.14 discussion last night: x-staging ppa isn't really functional, lacks drivers like synaptics
<llstarks> causes unstable apt
<llstarks> still no luck with nvidia 319 on hybrid, might need to try arch to eliminate distro as a variable
#ubuntu-x 2013-04-20
<tjaalton> hasty llstarks
<tjaalton> synaptics probably just needs a bump
<tjaalton> bryce: did you upload -intel?
<tjaalton> apparently so according to #ubuntu-kernel, so push git too :)
<bryce> tjaalton, ahem, it's both uploaded and pushed; check again
<tjaalton> thanks :)
<tjaalton> oh, minutes before my ping, the commit email was just slow to arrive then
<bryce> ah.  odd, I pushed it a while ago maybe an hour or so
<bryce> anyway, 10pm on a friday night, time for no more working
<tjaalton> yeah, cool
<tjaalton> 8am saturday, just checking we get the fixes in
<tjaalton> hmm no plymouth update yet
<bryce> grr
<tjaalton> it'd need a lightdm upload still, but having this in now wouldn't hurt
<tjaalton> well *dm
<bryce> ickle did the triage request-for-retest on all the mesa gpu lockup bugs.  So our bug graph is looking very good right now
<bryce> http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue.svg
<tjaalton> yeah I poked him about it yesterday
<bryce> aha
<tjaalton> or more like just notified we got 9.1.1 in
<bryce> I banged down the xserver bugs a bit this week.  Looks like you've been very active too.
<tjaalton> I did some blob triage
<mlankhorst> morning
<llstarks> morning
<tjaalton> llstarks: synaptics just needs a version bump on the ppa
<llstarks> intel too
<tjaalton> yeah
<tjaalton> intel uploaded now
<llstarks> should be interesting getting a proper xserver and -modesetting from staging and then targetting nvidia-319 from edgers without pulling in everything else
<tjaalton> huh, synaptics is there and a newer version too than is in raring now
<llstarks> i'm not booted into ubuntu atm, i can get you a list of conflicts
<tjaalton> https://launchpad.net/~canonical-x/+archive/x-staging
<tjaalton> unless it didn't actually build against the new xserver
<llstarks> probably not, apt wanted to hold everything back or uninstall
<tjaalton> uploaded
<tjaalton> just in case
<llstarks> i'll try later today, need to pass out. thanks
<Sarvatt> ugh this new gmail interface.. didn't realize i was top posting and quoting the entire bug when responding to bugs.debian.org :P
<llstarks> thunderbird bro
<llstarks|temp> tjaalton: that apt log i promised http://pastebin.com/DAE43C5v
#ubuntu-x 2013-04-21
<tjaalton> why can't he stay on the channel for a bit longer..
<tjaalton> the ppa should just work now
<erapp_000_> i'm here tjaalton 
<erapp_000_> windows blue is just stupid
<erapp_000_> i checked the ppa a few hours ago against a fresh raring daily. no go.
<tjaalton> erapp_000_: and?
<tjaalton> just keep one nick :)
<erapp_000_> i'm juggling 2 machines atm
<tjaalton> about to crash myself, so guess you're on your own
<erapp_000_> thanks, i'll try again
<erapp_000_> i must be overlooking something
<tjaalton> ok
<tjaalton> I'll check tomorrow if there are any issues left
<bjsnider> everybody in here is llstarks
<Sarvatt> llstarks: if you're here in any form you have something installed not compatible with xorg-video-abi-14 keeping it held back, maybe an old nvidia package or virtualbox
<tjaalton> oh debian backported drm from 3.4.x to the wheezy kernel, and now someone is basically asking us to do the same
<tjaalton> for precise
<jcristau> sorry :)
<tjaalton> :)
<tjaalton> too bad that the backport stack(s) are not discoverable to 12.04{,.1} users
<llstarks> ping bryce and mlankhorst: http://i.imgur.com/vLFnnur.jpg
<llstarks|spare> x-staging reqs libudev0 (not in raring archive) and the drivers built against the new abi
<llstarks|spare> figured this out the hard way
#ubuntu-x 2014-04-14
<shadeslayer> tjaalton: Sarvatt ping
<tjaalton> pong
<shadeslayer> would it be possible for you to upload the patch mentioned in comment 31 on bug 1294666
<ubottu> bug 1294666 in xserver-xorg-video-intel (Ubuntu) "[HSW mesa kde needs Xorg-1.15.1] Multiple tiling-esque artifacts in KDE" [High,Fix committed] https://launchpad.net/bugs/1294666
<tjaalton> yeah mlankhorst will add that
<mlankhorst> shadeslayer: ok working on it
<shadeslayer> thanks!
<tjaalton> hm, should've seen it with broadwell.. but purged kde already
<mlankhorst> shadeslayer: feel free to test ppa:canonical-x/x-staging soon, uploading to ubuntu as well
<shadeslayer> yay, thx
<tjaalton> bloody lp timing out all the time
<tjaalton> hm, nouveau still seems to crash on resume
<nerochiaro> does anyone know how can i test if 2-finger touchpad gestures work ? they don't seem to be working at all when i create a test QML application but perhps it's a QT problem, so that's why I wanted to check in some other way
<nerochiaro> any ideas ?
<nerochiaro> RAOF: ^ do you know who is the best person to ask ?
<t1mp> nerochiaro: try 2-finger scroll in browser? or does that not classify as a 'gesture'?
<nerochiaro> t1mp: it seems only to be triggered from the edge of the touchpad, so i would think it's a mousewheel event
<nerochiaro> t1mp: oh wait, 2 fingers scroll, sorry
<t1mp> I never had nay other multi-touch stuff working on my laptop, but that may be a hardware limitation
<t1mp> hmmm.. touchpad-edge-swipes like on unity8 on devices would be cool to have on my laptop
<t1mp> right-edge swipe on the touchpad to switch between running applications :)
<nerochiaro> t1mp: btw just tried, 2 finger scroll on webbrowser-app isn't working
<nerochiaro> t1mp: but 3-fingers scroll works, kind of
<t1mp> 3-finger scroll?
<t1mp> interesting. That doesn't work for me
<nerochiaro> t1mp: put down two fingers and wiggle the 3rd around
<nerochiaro> t1mp: guess some touchpads are only 2-touch enabled
<RAOF> Bah, nobody stays around to my morning :)
<RAOF> t1mp: xserver-xorg-input-synaptics doesn't send two-finger multitouch events; it consumes them itself to synthesise scroll events instead.
<RAOF> t1mp: And most touchpads will _report_ more than 2 fingers touching the touchpad, but only send coordinates for the first 2.
<RAOF> t1mp: Because apparently Apple is _still_ buying up _all_ the non-terrible touchpad hardware :(
#ubuntu-x 2014-04-15
<Sarvatt> RAOF: it costs $.10 more to add a real multitouch touchpad to a laptop, that adds up! :)
<Sarvatt> only apple is willing to put something decent in there..
<nerochiaro> i hve been told that at the moment touchpads will not send xi2 two-finger touch events to applications due to the mouse interpreter converting them to mousewheel. is there a way to disable this behavior globally, so i can test how apps will behave when they receive them ?
<tseliot> mlankhorst, RAOF: ^
<tjaalton> 01:56 < RAOF> Bah, nobody stays around to my morning :)
<tjaalton> 01:57 < RAOF> t1mp: xserver-xorg-input-synaptics doesn't send two-finger multitouch events; it consumes them itself to  synthesise scroll events instead.
<tjaalton> 01:57 < RAOF> t1mp: And most touchpads will _report_ more than 2 fingers touching the touchpad, but only send coordinates  for the first 2.
<tjaalton> 01:58 < RAOF> t1mp: Because apparently Apple is _still_ buying up _all_ the non-terrible touchpad hardware :(
<tjaalton> nerochiaro: ^
<nerochiaro> tjaalton: yes, but can we temporarily disable this behavior somehow ? I want to see how my app would react when 2 finger events are not consumed by the stack anymore
<tjaalton> disable synaptics
<tjaalton> so that it'll load evdev instead
<nerochiaro> tjaalton: can you please point me in the right direction on how to do that ?
<tjaalton> nerochiaro: the most brutal way would be to remove the driver.. or move it aside, or change the xorg.conf.d snippet to not do anything
<nerochiaro> tjaalton: i'll try the last one you suggested. seems the least brutal
<Prf_Jakob> mlankhorst: did you push the svga fixes to the ubuntu packages?
<Prf_Jakob> mlankhorst: I updated bug 1284134 if that is okay?
<ubottu> bug 1284134 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [High,Fix released] https://launchpad.net/bugs/1284134
#ubuntu-x 2014-04-16
<mlankhorst> Prf_Jakob: hm let me check :P
<mlankhorst> i believed I did, though
<mlankhorst> yeah
<Prf_Jakob> mlankhorst: okay :)
#ubuntu-x 2014-04-18
<Quintasan> Hi, I'm trying to use nvidia-prime here on my ThinkPad T430 but I have ended in a weird situation - http://wstaw.org/m/2014/04/18/plasma-desktopSF1827.png
<Quintasan> sudo /usr/bin/prime-select query returns "unknown"
<Quintasan> any attempt to switch to nvidia or intel via prime-select results in
<Quintasan> Error: alternatives are not set up properly
<Quintasan> Error: nvidia mode can't be enabled
<Quintasan> sudo /usr/bin/prime-supported obviously returns "yes"
<Quintasan> Is it me doing something wrong or should I report a bug?
#ubuntu-x 2014-04-19
<markqvist> Hi! I'm trying to build xserver-xorg-input-synaptics/clickpads from source on Trusty, but I can't configure since I'm missing "utouch-grail". Tried installing libgrail6, libgrail-dev and grail-tools packages, but no success. Does anyone know what I am missing?
<markqvist> Never mind, think I checked out the wrong source :P
<markqvist> I did, building just fine now :)
#ubuntu-x 2015-04-14
<furkan> is there any reason why i shouldn't be able to build Mesa from git on Ubuntu 14.04? i narrowed down my bug to between Mesa 10.1.3 and 10.3.2
<furkan> and i'm using the instructions from here to build Mesa from git: http://wiki.x.org/wiki/radeonBuildHowTo/
<furkan> it builds fine and i'm able to install it to /opt/xorg and point my LIBGL_DRIVERS_PATH environment variable to it
<furkan> but then when i try to log in, unity fails to launch and i just get kicked back to the lightdm greeter
<furkan> i couldn't really find anything useful in the logs that i looked at
<furkan> i thought maybe i need to apply the ubuntu patches, but i'm not sure how to go about doing that
<tjaalton> shouldn't need anything special
<furkan> based on that guide, i did "./autogen.sh --prefix=/opt/xorg --with-dri-drivers="radeon" --with-gallium-drivers="radeonsi,swrast" --with-dri-driverdir=/opt/xorg/lib/dri/"
<furkan> and then make, followed by make install
<furkan> and when i try "ldconfig -p | grep libGL.so" the libraries from /opt/xorg show up first
<furkan> but when i try glxinfo i get "glxinfo: symbol lookup error: /opt/xorg/lib/libGL.so.1: undefined symbol: __glX_tls_Context"
<furkan> i also tried adding --enable-glx-tls to the autogen script, but no difference
<furkan> googling the error gives me 2 results from #dri-devel IRC logs lol
<tjaalton> ldd /opt/xorg/lib/libGL.so.1
<tjaalton> xorg log too
<furkan> tjaalton: here's the first http://pastebin.com/hMvbyz14
<furkan> and the second: http://pastebin.com/2jDmFhTk
<furkan> i get the same __glX_tls_Context error in the xorg log
<tjaalton> --enable-glx-tls for mesa
<tjaalton> since the xserver is built with it
<furkan> tjaalton: yeah, i included that, you mean with autogen.sh right?
<furkan> (mentioned above)
<tjaalton> yes
<tjaalton> oh, I see
<tjaalton> forgot to run make install perhaps
<furkan> can't be, i ran that too, and i can verify that it copies everything into /opt/xorg
<furkan> yeah i just tried it again to make sure it was putting everything in the right place, it's all going straight in /opt/xorg
<furkan> is it possible that ubuntu just ignores those?
<tjaalton> no
<furkan> and the configuration in that guide is still up to date?
<furkan> i created the file /etc/ld.so.conf.d/a-local-xorg.conf
<furkan> put "/opt/xorg/lib" in it, and ran ldconfig
<furkan> and setting the LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri/ environment variable
<furkan> but if i'm understanding right, that part may be unnecessary if using the --enable-glx-tls flag
<furkan> "Problem with this configuration is that AIGLX doesn't respect it. This means that compiz doesn't get advantage of new driver.
<furkan> It is possible to get the new libGL and dri drivers used without setting LIBGL_DRIVERS_PATH:"
<tjaalton> dunno
<tjaalton> you probably need to remove /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf
<tjaalton> or at least try with that elsewhere
<furkan> tjaalton: i'll give that a shot
<furkan> i've got it narrowed down to between 10.2 and 10.3.2 now
<furkan> since i just noticed Maarten had a 10.2 build in trusty-proposed
<furkan> tjaalton: i think that fixed it dude...
<furkan> glxinfo doesn't throw the error anymore
 * furkan tries restarting X
<furkan> this is so weird
<furkan> when i put that file in ld.so.conf.d, X starts in low graphics mode
<furkan> i removed it, but left the LIBGL_DRIVERS_PATH environment variable intact
<furkan> now it runs fine
<furkan> and:
<furkan> furkan@furkan-trusty:~$ LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null | grep so$
<furkan> libGL: OpenDriver: trying /opt/xorg/lib/dri//tls/radeonsi_dri.so
<furkan> libGL: OpenDriver: trying /opt/xorg/lib/dri//radeonsi_dri.so
<furkan> that double-slash looks weird
<furkan> but i also get "OpenGL ES profile version string: OpenGL ES 2.0 Mesa 10.2.1 (git-1b69ea1)"
<furkan> which is what i just built
<tjaalton> nice
<furkan> tjaalton: i think i found the bad commit
<furkan> "4a5519f1e019dbf1103e4f3abe0a695637a87518 is the first bad commit"
<furkan> r600g,radeonsi: set correct initial domain for shared resources
<furkan> i've got a but report filed @ freedesktop and was asked to do the bisect, so we'll see if it gets fixed
#ubuntu-x 2015-04-15
<bennabiy> I am having an issue with losing graphics after grub with 14.04
<bennabiy> Intel Mobile 4 Series Integratedgraphics
#ubuntu-x 2015-04-17
<bennabiy> Did a recent update drop driver support for Intel Mobile 4 Series chipsets?
<tjaalton> no
<bennabiy> I am only able to pull up video, either through a liveCD or LTSP booting, when using VESA driver, otherwise the screen flickers and goes blank about 10 seconds post grub menu
<bennabiy> but the system is up and running, just no display
<tjaalton> and only one kernel installed to choose from?
<tjaalton> if you say it's a regression then try the previous kernels
<bennabiy> only one kernel installed
<bennabiy> I am trying to remote into the system to see if there are any errors.
<tjaalton> so what do you mean "recent update"?
<tjaalton> what version is this? and the kernel?
<tjaalton> if vivid, make sure you have at least 3.19.0-13
<bennabiy> trusty 
<tjaalton> installed when?
<bennabiy> just now
<bennabiy> 3.13.0-49-generic
<bennabiy> using X.org 1.15.1
<tjaalton> the image doesn't have that kernel, did you manually remove the install kernel?
<tjaalton> use a release image
<bennabiy> This is an LTSP installed chroot, but it also happens from a linuxmint 17.1 liveCD
<tjaalton> so nomodeset works? get the relevant bits of a non-working boot from /var/log/kern.log and put it somewhere
<bennabiy> nomodeset works, just 640x480
<tjaalton> yes
<bennabiy> https://pastebin.mozilla.org/8830478
<bennabiy> from a machine which lost video, but I can remote in
<tjaalton> what hw is it?
<bennabiy> this is a hp st5742
<bennabiy> thin client
<bennabiy> it was just working on a previous install, and when I did a fresh install of 14.04 / mint 17.1 the video on the server is fine, but not on the clients generated from the repositories
<bennabiy> nor from the live CD
<bennabiy> which is strange, but once again, nomodeset works there
<bennabiy> When 14.04 first came out, these had no problems with the graphics, but something changed with the latest 14.04
<tjaalton> then you need to install earlier kernels and bisect which broke it
<bennabiy> I have 3 other labs all running fine with the same hardware, and this one was running 13.04 just fine
<bennabiy> do you have a suggestion as to which one to go back to?
<tjaalton> 14.04 installer comes with -24
<tjaalton> no
<tjaalton> file a bug
<tjaalton> test these
<bennabiy> So try -24, if it works,... ?
<tjaalton> https://launchpad.net/ubuntu/trusty/+source/linux
<tjaalton> you get the earlier ones there
<tjaalton> remember to install -extra too
<bennabiy> ok
<tjaalton> if you say stock 14.04 worked
<tjaalton> best to try -24 to rule out it's not something else messing things
<tjaalton> use the latest of -XX.YY, so for -24 test -24.47
<bennabiy> ok
<bennabiy> let me try that.
<bennabiy> ok, so installed linux-image-extra-3.13.0-24-generic as well as same without extra
<bennabiy> any other packages that I would need to install?
<tjaalton> not at this point
<bennabiy> trying it now
<bennabiy> hrm. -24 did not work
<tjaalton> so your setup is busted
<bennabiy> same thing happened at the same point
<bennabiy> what should I do about it?
<bennabiy> nomodeset works, which means that the basic functionality of the system works
<bennabiy> How can I pinpoint what is "busted"?
<tjaalton> I don't know how you build your ltsp setup, and don't care to know either. but something in it is not ok if stock trusty doesn't work either
<bennabiy> This is not just happening with LTSP, but also with a liveCD it does the same thing
<tjaalton> and doesn't work on any machines of the same kind?
<tjaalton> the hw could be broken too
<bennabiy> Even though it was just working on a 13.04 system?
<bennabiy> and works when I boot back into that system?
<bennabiy> 3.8 kernel
<tjaalton> you said trusty worked
<tjaalton> anyway, same applies.. find out where it broke
<bennabiy> I know it worked at a different location with the same hardware
<bennabiy> I have 2 other labs running the same hardware clients, with 14.04 installed (with linuxmint 17) which I think were installed before 14.04.2
<bennabiy> I appreciate your input, I want to track this down.
<bennabiy> I am downloading a fresh copy of the ISO to make a live USB, will test to see if stock 14.04.2 works
<bennabiy> here is a copy from dmesg. https://pastebin.mozilla.org/8830489
<tjaalton> rule out hw issues first
<tjaalton> cabling etc
<tjaalton> [   14.279246] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3
<bennabiy> Would cabling be the issue if it is displaying just fine up to that point?
<tjaalton> fair point :)
<tjaalton> still
<tjaalton> dunno
<bennabiy> I am not saying you are wrong... just wondering ;)
<tjaalton> easy to verify
<tjaalton> I'm off ->
<bennabiy> Thanks for your help
<bennabiy> If I needed to test an older image of 14.04 (pre .2) where would I go?
<bennabiy> I am getting this error in [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 and am unable to see anything on the screen after a brief flicker
<bennabiy> Does the same thing with an Ubuntu 14.04.2 liveCD as well as a linuxmint 17.1 (based on 14.04.2) liveCD. 14.04 stock worked, as well as mint 17 stock
<tjaalton> releases.ubuntu.com
<bennabiy> thank you again tjaalton 
<bennabiy> I have searched there, but still not finding the stock 14.04
<bennabiy> bah, found it :)
<bennabiy> actually, I did not find it...
<bennabiy> I am looking for 1386 14.04 image
<tjaalton> old-releases.u.c
<bennabiy> tjaalton: thanks. that did it
<bennabiy> tjaalton: This is strange, would there be something which would cause the displayport to not work once it hits a certain point?
<bennabiy> I hooked up a VGA monitor and it worked fine
<bennabiy> but I hook up to the display port and it does not
<bennabiy> but if I boot to a different install, the display port works fine
<bandit-led> any idea how to get dkms to build and install nvidia properly? I like to run it after a kernel update but it is not working since nvidia-uvm was added to nvidia 
<bandit-led> sudo dpkg-reconfigure nvidia works but i have to install the kernel then reboot and rebuild the module and restart again
<bandit-led> running NVIDIA binary driver - version 346.59 
<bandit-led> sudo dkms install -m nvidia -v 346-346.59 -k 4.0.0-rc1-02232015 is what i usually run
<bandit-led> just changing the kernel and nvidia versions
<bandit-led> hmm nap time maybe  i will get a response by the time i get up from my nap :)
<furkan> interesting, i tried compiling mesa from git on Ubuntu 15.04, following the instructions on freedesktop.org, and it works perfectly fine
<furkan> i dunno why 14.04 was so problematic
<furkan> when i add the file in /etc/ld.so.conf.d to point to /opt/xorg/lib, Xorg just segfaults
<bandit-awake> hmmm this channell seems sleepy
#ubuntu-x 2016-04-18
<flexiondotorg> Morning.
<flexiondotorg> I've been seeing people run into this bug more and more in recent weeks - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1522922
<ubottu> Launchpad bug 1522922 in xserver-xorg-video-intel (Ubuntu) "Screen flickering in Intel i915 driver" [High,Triaged]
<flexiondotorg> I have an affected computer.
<flexiondotorg> It would appear there are unrelease upstream fixes or some commit that can be reverted.
<flexiondotorg> I'm happy to help work on this.
<tjaalton> i don't see the latest patch on upstream list
<tjaalton> which would make review impossible
<flexiondotorg> tjaalton, What about the option of reverting the commits mentioned in the opening post?
<tjaalton> i'm sure that would regress something
<tjaalton> replied to the ml thread
<flexiondotorg> ty
#ubuntu-x 2016-04-22
<furkan> flexiondotorg: tjaalton i noticed the screen flickering on my X201 after upgrading to linux-generic-lts-xenial
<furkan> so i downgraded to linux-generic-lts-wily, flickering went away
<furkan> i'm running Ubuntu 14.04 on that laptop
<tjaalton> furkan: try 4.6
#ubuntu-x 2016-04-23
<soee> http://news.softpedia.com/news/nvidia-364-19-short-lived-unix-driver-adds-vulkan-api-1-0-support-wayland-fixes-503325.shtml
<ricotz> mamarley, hi, jfyi, I am currently uploading 364.19
<ricotz> soee, ^
<soee> hi ricotz, into drivers ppa ?
<ricotz> yes
<soee> ricotz: nice, thank you
<mamarley> ricotz: Sorry, I have been ultra-busy trying to get a new router set up and I didn't get a chance to fool with drivers.  Thanks for uploading it!
<ricotz> mamarley, hi, don't worry and just to be clear, you don't have to apologise everytime if you havent got it ready before me or alberto
#ubuntu-x 2016-04-24
<soee> the latest drivers works fine on Xenial :)
<soee> *driver
#ubuntu-x 2018-04-16
<soee> Latest driver works fine with Kernel 4.17-rc1
<soee> Just wanted to inform if someone didn't test :)
#ubuntu-x 2018-04-18
<soee_> Is it normal that (when using ppa) 396.18 wants to upgrade to 396.18.02 ? I thought Vulkan version was separate so far no?
<mamarley> soee_: Do you accidentally have my staging PPA enabled?
<mamarley> Because 396.18.02 is in my staging PPA but is not in the main PPA.
<mamarley> I figured you of all people would probably want to install that driver anyway. :P
<soee_> mamarley: might be :)
<soee_> mamarley: whats the maikn difference with normal and vulkan drivers ?
<mamarley> I assume it is very similar to 396.18 but with the new Vulkan stuff added.  I am running it and I haven't had any problems.
<soee_> are there any advetages over normal driver?
<soee_> i mean performance (in game sthat use Vulkan API) ?
<mamarley> Beats me, I haven't benchmarked it.
 * soee_ beats mamarley
<ricotz> mamarley, hi, I have prepare some bionic updates which are based on the current 390 git branch
<mamarley> ricotz: OK, what do you need me to do?
<mamarley> Forward-port the changes to 396?
<ricotz> mamarley, I guess you want to rebase your 396.18.02 to avoid conflicts
<mamarley> Sure.
<ricotz> I have an updated 396.18 too
<mamarley> OK, I will include these changes in my 396.18.02 build as well.
<mamarley> Where are they at?  I don't see any recent uploads.
<ricotz> no need for a 390.48 update on your side
<ricotz> mamarley, inhttps://launchpad.net/~ricotz/+archive/ubuntu/red/+packages
<mamarley> Thanks!
<ricotz> mamarley, I guess 396.18.02 would require some vulkan snapshot while there is no released 1.1.73
<mamarley> I'm not sure.  I don't actually have any Vulkan applications installed on my PC (besides vulkaninfo, but that works).
<ricotz> what is the "apiVersion" reported by the driver?
<ricotz> vulkaninfo | grep -e "Version"
<mamarley> apiVersion     = 0x401048  (1.1.72)
<ricotz> ok
<ricotz> tjaalton, hi, do you know if there is going to be a vulkan loader 1.1.73 release?
<tjaalton> ricotz: no idea
<ricotz> vulkan releasing is a total mystery :\
<tjaalton> yep
<ricotz> there even was a 1.1.70.1
<ricotz> https://vulkan.lunarg.com/doc/sdk/1.1.70.1/linux/release_notes.html
<ricotz> tjaalton, looks like the existence of the branch "sdk-1.1.73" suggests something https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/commits/sdk-1.1.73
<tjaalton> but not tagged
<ricotz> maybe happening soon then
<ricotz> tseliot, hi
<ricotz> tseliot, please push your latest 304 and 340 branches
<ricotz> and 384 too
<tseliot> ricotz: I can see some conflicts between my local 340 branch and the one on github...
<ricotz> tseliot, you tend to rewrite your branches a lot ;)
<tseliot> ricotz: yes, I know
<ricotz> tseliot, so could you push the branches to make them match the uploads
<tseliot> ricotz: yes, I want to check first
<ricotz> ok, thanks
#ubuntu-x 2018-04-19
<tjaalton> RAOF: hey, what about xmir, is it still used in bionic and up?
<tseliot> ricotz: I've just pushed 340, 304, and 384
<ricotz> tseliot, thanks
#ubuntu-x 2018-04-20
<RAOF> tjaalton: XWayland on Mir is not yet feature-comparable, but I don't think anyone is actually *using* XMir.
<RAOF> tjaalton: So, feel free to drop it when Crusty Crayfish opens, I guess?
<tjaalton> RAOF: ok, sure thing.. maybe once 1.20 is merged
<tjaalton> it's mean that hwe-18.04 stack wouldn't have xmir anymore, but guess that's fine
#ubuntu-x 2019-04-15
<ricotz> tseliot, hi, I guess the linux-module-nvidia-xxx-5.0.0-11-generic should have stricter dependency on nvidia-kernel-common-xxx ?
<ricotz> apw, hi ^
<tseliot> ricotz: the thing is the kernel module doesn't really depend on user space. nvidia-kernel-common includes udev rules and other stuff
<tseliot> we should make sure that user space doesn't use the wrong kernel module though
<ricotz> hmm, but I assume problems with the userspace binaries if they don't match the version of the kernel source
<ricotz> of course it works if there were no changes to the kernel source
<ricotz> or does nvidia really have a stable module ABI?
<tseliot> it will all be updated at the same time in the archive though
<ricotz> this is no guaranty for a consistent update
<tseliot> nope
#ubuntu-x 2019-04-16
<tjaalton> -. m   Ã¶l Ã¶,nlllk   kl  i lk  k  lkbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb  y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton> y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton> y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton>  v y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton> y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton>  vvcvnccccccccccccc-ghhh
<tjaalton> n
<tjaalton> 3~y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton> y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton> y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<tjaalton> y
<tjaalton> 20:12 [oftc] -!- You have been marked as being away
<Duke``> ??
<tomreyn> tjaalton: you got a cattack there
<tjaalton> uh
<tjaalton> not a cat, 2y old
<tomreyn> similar ;)
<tomreyn> common counter measures include screen locking, play-pen locking
<tjaalton> this laptop stays cool enough that the cat couldn't bother.. the old t420s though )
<tjaalton> :)
<tomreyn> i assume thats the name of your toddler. or your thinkpad's.
