#ubuntu-x 2006-10-02
<Ubugtu> New bug: #63445 in xorg "When editing xorg.conf for logitech mouse, wacom settings are added, and I'm locked out of X server." [Undecided,Unconfirmed]  http://launchpad.net/bugs/63445
<Ubugtu> New bug: #63461 in mesa-utils "Xlib:  extension "GLX" missing on display ":0.0"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63461
<Ubugtu> New bug: #63500 in xorg "Latest xorg does not work with savage driver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63500
<Ubugtu> New bug: #63503 in xserver-xorg-video-ati "graphics lockups with radeon DRI" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63503
<Ubugtu> New bug: #63152 in xorg (main) "[Edgy-Beta]  vesa driver for an ATI 9600" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63152
<Ubugtu> New bug: #62775 in casper "Incorrect keyboard in live session" [Undecided,Fix released]  http://launchpad.net/bugs/62775
<Ubugtu> New bug: #63551 in xorg "X.org doesn't detect widescreen resolution" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63551
<Ubugtu> New bug: #63559 in linux-restricted-modules-2.6.17 "Have to reinstall nvidia kernel module on reboot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63559
<Ubugtu> New bug: #63560 in xorg "installing 915resolution for the correct resolution shouldn't be necessary" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63560
<Ubugtu> New bug: #63037 in xorg-server (main) "Freeze during startup of installer with edgy beta" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63037
<Ubugtu> New bug: #63584 in xorg (main) "[edgy]  Freeze when switching to VT in AIGLX" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63584
<mvo_> rodarvus: imake was moved into xutils-dev in edgy it seems. we may have to create a transition package because the upgrade seems to not pull it in automatically but keeps the old version
<rodarvus> mvo_, right, this is on my todo list
<mvo_> rodarvus: cool, thanks
<Ubugtu> New bug: #63396 in imake (main) "Upgrading to edgy beta leavs imake and makedepend" [Undecided,Confirmed]  http://launchpad.net/bugs/63396
<rodarvus> there was an 'xutils' package, which was apparently dropped on our upgrade to debian's xorg package
<rodarvus> (which was not handled by me)
<rodarvus> I guess I'll just create a transitional xutils package inside xorg for now
<mvo_> rodarvus: ok, thanks a lot! I'm reviewing upgrade issues right now and came across this one
<rodarvus> mvo_, thank YOU for the report!
<Ubugtu> New bug: #63611 in xrdb "xrdb crashes on startup" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63611
<Ubugtu> New bug: #63618 in linux-restricted-modules-2.6.17 "atheros laptop LED not activated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63618
<Ubugtu> New bug: #63625 in linux-restricted-modules-2.6.17 "edgy - nvidia-glx install causes x to fail" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63625
<Ubugtu> New bug: #63627 in linux-restricted-modules-2.6.17 "Graphic Acceleration dont work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63627
#ubuntu-x 2006-10-03
<Ubugtu> New bug: #63673 in xorg "right alt-shift won't switch language anymore" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63673
<Ubugtu> New bug: #63674 in linux-restricted-modules-2.6.17 "TexturedVideo option is unsupported" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63674
<Ubug2> New bug: #63682 in mesa-utils "glxinfo crashed at login" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63682
<Ubug2> New bug: #63672 in update-manager "crashes X when displaying changes for openssh-client" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63672
<Ubug2> New bug: #63689 in linux-restricted-modules-2.6.17 "direct rendering not working with nvidia propriatry driver." [Undecided,Unconfirmed]  http://launchpad.net/bugs/63689
<Ubug2> New bug: #63352 in mesa "Creative labs X-Fi sound card unsupported" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63352
<Ubugtu> New bug: #60600 in xorg (main) "correct font is not restore after switch back from X" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60600
<Ubugtu> New bug: #63705 in update-manager "X crashes when viewing changes for ssh" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63705
<Ubugtu> New bug: #63712 in xorg-server "The screen becomes black after 10 minutes." [Undecided,Unconfirmed]  http://launchpad.net/bugs/63712
<Ubugtu> New bug: #63719 in emacs21 "Characters displaying as rectangles" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63719
<Ubugtu> New bug: #62932 in linux-source-2.6.17 "Edgy kernel oops during bootup on toshiba laptop" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62932
<Ubugtu> New bug: #61981 in linux-source-2.6.17 "toshiba_acpi: ktoshkeyd initialisation failed" [Undecided,Confirmed]  http://launchpad.net/bugs/61981
<Ubugtu> New bug: #63305 in linux-source-2.6.17 "toshiba_acpi fails to load on Edgy Beta" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63305
<Ubugtu> New bug: #63727 in xserver-xorg-video-i810 "i810 dies after resume, didn't work, worked, didn't work." [Undecided,Unconfirmed]  http://launchpad.net/bugs/63727
<Ubugtu> New bug: #63796 in xserver-xorg-video-tdfx "X doesn't launch with voodoo 5 5500" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63796
<Ubugtu> New bug: #63577 in linux-restricted-modules-2.6.17 (restricted) "[edgy]  Freeze when switching to vt or selecting shutdown" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63577
<Ubugtu> New bug: #63819 in xutils-dev "xutils-dev provides imake|xmkmf, which is needed by non-dev packages" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63819
#ubuntu-x 2006-10-04
<Ubugtu> New bug: #63862 in xorg "wacom entries appear even when not having a tabletpc" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63862
<Ubugtu> New bug: #63865 in xserver-xorg-driver-mga "screen freeze returning from xscreensaver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63865
<Ubugtu> New bug: #63868 in xorg "Radeon 3D doesn't work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63868
<Ubugtu> New bug: #63880 in linux-restricted-modules-2.6.17 "after update, fglrx fails" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63880
* netjoined: irc.freenode.net -> brown.freenode.net
<Ubugtu> New bug: #63518 in xorg (main) "wrong resolution with Intel 915GM; 915resolution is ineffective; restarting gdm required every time" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63518
<Ubugtu> New bug: #63912 in linux-restricted-modules-2.6.17 "Module fglrx isn't loaded" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63912
<Ubugtu> New bug: #63830 in xserver-xgl "Open office crashes and takes Xgl with it" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63830
<Ubugtu> New bug: #63062 in xserver-xorg-video-savage (main) "Artifacts on screen when playing example content" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63062
<Ubugtu> New bug: #63806 in update-manager "Software Updates aborting user session" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63806
<Ubugtu> New bug: #63930 in xfonts-utils "please backport to dapper" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63930
<Ubugtu> New bug: #63931 in linux-restricted-modules-2.6.15 "no acceleration in edgy beta" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63931
<Ubugtu> New bug: #63610 in update-manager "Update Manager crashes Xorg when clicking on a particular package" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63610
<Ubugtu> New bug: #63905 in xserver-xorg-driver-nv "mouse cursor disappears" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63905
<Ubugtu> New bug: #63956 in xorg "My Radeon9500 runs with 8 Pixelpipelines, instead of 4" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63956
<Ubugtu> New bug: #63742 in xorg (main) "widescreen problems" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63742
<Ubugtu> New bug: #61390 in xorg (main) "Desktop CD starts with wrong resolution" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61390
<Ubugtu> New bug: #63981 in xorg "Duplicate config files are sourced by Xsession" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63981
<Ubug2> New bug: #63994 in xserver-xorg-video-ati "regression after latest xorg upgrade in edgy: video mode 1440x960 got missing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63994
<Ubug2> New bug: #63995 in xserver-xorg-driver-nv "Garbled screen _sometimes_" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63995
<Ubug2> New bug: #64003 in xorg "font selection broken in Emacs and other things" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64003
<Ubugtu> New bug: #64033 in xorg (main) "T43 sometimes fails to resume from suspend" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64033
#ubuntu-x 2006-10-05
<Ubugtu> New bug: #64081 in xorg "Oops (xorg) after dapper->edgy dist-upgrade Toshiba Portege 4000    " [Undecided,Unconfirmed]  http://launchpad.net/bugs/64081
<Ubugtu> New bug: #64049 in xorg (main) "upgrade from breezy to edgy won't restart X" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64049
<Ubugtu> New bug: #62143 in xdm (universe) "Ubuntu and Xubuntu (Edgy Knot3) end sessions with a black screen" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62143
<Ubugtu> New bug: #62134 in linux-restricted-modules-2.6.17 (restricted) "When Using AIGLX on Edgy cant turn of Laptop" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62134
<Ubugtu> New bug: #64089 in xorg "edgy's xserver-xorg postinst configuration runs repeatedly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64089
<Ubugtu> New bug: #64118 in xserver-xorg-video-mga (main) "no MGA 200 support in Edgy Eft Beta Kubuntu" [Undecided,Rejected]  http://launchpad.net/bugs/64118
<Ubugtu> New bug: #64121 in xorg "Edgy & Dapper: Lower Resolution on one account interferes with another" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64121
<Ubugtu> New bug: #64114 in xorg-server (main) "Edgy Beta 1 breaks X on Neomagic chipset" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64114
<Ubugtu> New bug: #64128 in xserver-xorg-driver-ati "ati/radeon driver has issues with resolution of external displays" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64128
<Ubugtu> New bug: #64172 in xorg "Doesn't upgrade from Dapper" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64172
<Ubugtu> New bug: #59618 in xorg (main) ""Safe graphics mode" doesn't use VESA" [Undecided,Confirmed]  http://launchpad.net/bugs/59618
<Ubugtu> New bug: #64198 in xserver-xorg-video-ati "LiveCD can't start X on Apple Xserve" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64198
<Ubugtu> New bug: #63883 in linux-source-2.6.17 "kernel 2.6.17-10.26 still doesn't boot on toshiba laptop" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63883
#ubuntu-x 2006-10-06
<Ubugtu> New bug: #62547 in linux-restricted-modules-2.6.17 (restricted) "no dri cannot init AGP  in 2.6.17-10 AMD64" [High,Fix committed]  http://launchpad.net/bugs/62547
<Ubugtu> New bug: #64276 in xorg "Beryl crashes X on starting" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64276
<Ubugtu> New bug: #64174 in xserver-xorg-video-ati (main) "GUI doesn't appear on startup, ATI X300 not recognised?" [Undecided,Needs info]  http://launchpad.net/bugs/64174
<Ubugtu> New bug: #64304 in xserver-xorg-input-synaptics "ButtonReleased events for left mouse-button not being sent properly to X" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64304
<Ubugtu> New bug: #64331 in linux-restricted-modules-2.6.17 "crashing xorg.  unstable behaviour" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64331
<Ubugtu> New bug: #64431 in mesa "audio output of SigmaTel* STAC9271 is too silent" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64431
#ubuntu-x 2006-10-07
<Ubugtu> New bug: #64502 in xorg "desktop-cd ubuntu 6.10 beta boots but 'blank screen' only" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64502
<Ubugtu> New bug: #64567 in xserver-xorg-video-ati "[r128]  Driver does not support internal CRT of iMac on PPC" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64567
<Ubugtu> New bug: #64585 in xserver-xorg-video-ati "Ati X800 GTO doesn't work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64585
<Ubugtu> New bug: #64589 in xserver-xorg-video-ati "Problem with Radeon9000 and ati/radeon driver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64589
#ubuntu-x 2006-10-08
<Ubugtu> New bug: #62382 in linux-source-2.6.17 "[regression] : Toshiba ACPI driver corrupted since 2.6.17-8" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62382
<Ubugtu> New bug: #64678 in xkeyboard-config (main) "apt-get dist-upgrade fails from Dapper to Edgy (different from #57121)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64678
#ubuntu-x 2007-10-03
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #57579 in xorg-server (main) "Kubuntu LiveCD doesn't complete boot on Dell Inspiron 640m" [Undecided,New]  https://launchpad.net/bugs/57579
<ubotu> New bug: #145873 in xserver-xorg-video-i810 (main) "gnome panel discolored" [Low,New]  https://launchpad.net/bugs/145873
<ubotu> New bug: #148540 in xserver-xorg-video-intel (main) "Xorg crashes when using multiple screens on gutsy using latest intel driver" [Undecided,New]  https://launchpad.net/bugs/148540
<ubotu> New bug: #148505 in xorg (main) "ATI Mobility Radeon X1400 is not supported" [Undecided,New]  https://launchpad.net/bugs/148505
<ubotu> New bug: #148568 in xserver-xorg-video-ati (main) "[gutsy]  ATI ES1000 doesn't work" [Undecided,New]  https://launchpad.net/bugs/148568
<ubotu> New bug: #145299 in linux-restricted-modules-2.6.22 (restricted) "cannot access others tty's when using nvidia driver" [Undecided,Incomplete]  https://launchpad.net/bugs/145299
<ubotu> New bug: #136812 in xorg (main) "gutsy upgrade broke keyboard layout" [Low,New]  https://launchpad.net/bugs/136812
<ubotu> New bug: #148666 in compiz (main) "compiz.real crashed with SIGSEGV in glGetString() (dup-of: 144241)" [Medium,New]  https://launchpad.net/bugs/148666
<ubotu> New bug: #144241 in linux-restricted-modules-2.6.22 (main) "Xinerama: compiz.real crashed with SIGSEGV in glGetString()" [Undecided,New]  https://launchpad.net/bugs/144241
<ubotu> New bug: #148746 in xorg (main) "tty1-6 don't work in gutsy" [Undecided,New]  https://launchpad.net/bugs/148746
#ubuntu-x 2007-10-04
<ubotu> New bug: #148760 in linux-restricted-modules-2.6.12 (restricted) "NVIDIA driver not found Error 404" [Undecided,New]  https://launchpad.net/bugs/148760
<ubotu> New bug: #148765 in xorg (main) "Black screen after kernel has loaded 100%" [Undecided,Incomplete]  https://launchpad.net/bugs/148765
<ubotu> New bug: #148677 in displayconfig-gtk (main) "Dual Monitor Gui on Gusty X64 broke" [Undecided,Incomplete]  https://launchpad.net/bugs/148677
<ubotu> New bug: #132591 in linux-restricted-modules-2.6.22 (restricted) "Update fglrx to 8.40.4" [Medium,Triaged]  https://launchpad.net/bugs/132591
<ubotu> New bug: #148866 in xterm (main) "xterm terminfo file uses wrong mode by default" [Undecided,New]  https://launchpad.net/bugs/148866
<ubotu> New bug: #148875 in xkeyboard-config (main) "Full keymap for Genius TwinTouch" [Undecided,New]  https://launchpad.net/bugs/148875
<ubotu> New bug: #148887 in xorg (main) "xorg failsafe mode doesn't works" [Undecided,New]  https://launchpad.net/bugs/148887
<ubotu> New bug: #39140 in baltix (main) "Avoid picking 60Hz refresh rates for CRTs" [Medium,New]  https://launchpad.net/bugs/39140
<ubotu> New bug: #148892 in linux-restricted-modules-2.6.22 (restricted) "TFT via HDMI" [Undecided,New]  https://launchpad.net/bugs/148892
<ubotu> New bug: #148902 in mesa (main) "r300 needs update for 200m" [Undecided,New]  https://launchpad.net/bugs/148902
<ubotu> New bug: #148940 in xfs (universe) "[X font server]  integer overflow and heap corruption vulnerability" [Undecided,New]  https://launchpad.net/bugs/148940
<ubotu> New bug: #148943 in linux-restricted-modules-2.6.22 (restricted) "nvidia.ko: No such file or directory" [Undecided,New]  https://launchpad.net/bugs/148943
<ubotu> New bug: #148974 in compiz (main) "compiz (dup-of: 144241)" [Medium,New]  https://launchpad.net/bugs/148974
<ubotu> New bug: #148080 in linux-restricted-modules-2.6.22 (restricted) "Hibernation fails with blank screen on a Dell Dimension 5100" [Low,Triaged]  https://launchpad.net/bugs/148080
<ubotu> New bug: #149043 in xserver-xorg-video-intel (main) "GDM fail to start on Intel Mobile 945GM/GMS" [Undecided,New]  https://launchpad.net/bugs/149043
<bdmurray> bryce: did you see 127101 becaume un fix released?
<bryce> bdmurray: hmm
<bdmurray> I think was able to verify that it didn't work, I am rebooting now
<bryce> yeah I think I noticed that yesterday.  but not sure what to do next
<bdmurray> Do you have hardware for it?
<bryce> hmm, not sure, but I'm currently doing reinstalls on most all of my systems, so will check once they're done
<bdmurray> man, bugs.freedesktop.org is slow to load for me
<bryce> kees, do you have time to do an xorg upload?  I've finished doing a bunch of testing and am confident about it.
<keescook> bryce: sorry, not at the moment, perhaps later this afternoon
<bryce> ok
#ubuntu-x 2007-10-05
<ubotu> New bug: #146142 in xorg (main) "gnome-mouse-properties: Horizontal Scrolling is useless" [Low,Fix released]  https://launchpad.net/bugs/146142
<ubotu> New bug: #85746 in xorg (main) "feisty kubuntu installer - X started but nothing shown" [Undecided,Incomplete]  https://launchpad.net/bugs/85746
<ubotu> New bug: #128526 in xresprobe (main) "probing for X, causes scrambled Frame Buffer" [Undecided,New]  https://launchpad.net/bugs/128526
<ubotu> New bug: #149260 in mesa (main) "wine-git/google earth crashes with DRM_I830_CMDBUFFER: -22 on Thinkpad X60" [Undecided,New]  https://launchpad.net/bugs/149260
<tepsipakki> bryce: hey, seems that tormod has been doing great work with -ati
<bryce> :-)
<bryce> tepsipakki: what in particular?
<tepsipakki> hopefully there'll be a new release soon, or should we upload his version?
<tepsipakki> tracking upstream changes and asking people test his ppa
<bryce> I was looking at the changelog from upstream and noticed a lot of fixes it would be nice to have
<bryce> including bug 86072
<ubotu> Launchpad bug 86072 in xserver-xorg-video-ati "ATI ES1000 515e not recognized" [Medium,In progress]  https://launchpad.net/bugs/86072
<bryce> hmm, well it would be a shame to waste his hard work - if you're comfortable with how it looks, I would favor uploading it as well
<tepsipakki> if RC is next Thursday, we should act soon I think
<bryce> agreed
<bryce> tepsipakki: yesterday it was decided to postpone the freeze until Friday
<bryce> (maybe it's friday for you already?)
<tepsipakki> yep, 09:18 here :)
<tepsipakki> AM
<bryce> heh
<bryce> btw, I packaged up a snapshot of the intel git head for testing:  http://people.ubuntu.com/~bryce/Testing/intel/
<tepsipakki> oh, something happening there too :P
<ubotu> New bug: #148686 in xserver-xorg-video-intel (main) "screen blinks a lot during boot " [Undecided,New]  https://launchpad.net/bugs/148686
<tepsipakki> bryce: I'll merge -ati by tormod and ask his opinion if it should be uploaded when he shows up
<bryce> great
<ubotu> New bug: #149297 in xserver-xorg-video-intel (main) "xserver-xorg-video-intel package missing changelog" [Undecided,Confirmed]  https://launchpad.net/bugs/149297
<ubotu> New bug: #149304 in xorg (main) "Use of "next" instead of "continue" in bash script failsafeXServer" [Undecided,New]  https://launchpad.net/bugs/149304
<ubotu> New bug: #149367 in xrandr (main) "plug my HD tv makes xrandr display wrong resolution for my active screen" [Undecided,New]  https://launchpad.net/bugs/149367
<ubotu> New bug: #149377 in xrandr (main) "window title stuck where gnome panel was if moved while using dual head with xrandr " [Undecided,New]  https://launchpad.net/bugs/149377
<ubotu> New bug: #138079 in dell "Dell Inspiron 1520 nVidia 8600M GT doesn't work" [Medium,Confirmed]  https://launchpad.net/bugs/138079
<ubotu> New bug: #149430 in xserver-xorg-video-intel (main) "No DMPS on DVI port of ADD2 card" [Undecided,New]  https://launchpad.net/bugs/149430
<ubotu> New bug: #149490 in xserver-xorg-video-intel (main) "X crashes on suspend" [Undecided,New]  https://launchpad.net/bugs/149490
<ubotu> New bug: #97637 in compiz (main) "Beryl/Emerald won't allow gnome-screensaver screen-unlock dialog to have input focus (dup-of: 122549)" [Undecided,New]  https://launchpad.net/bugs/97637
<tepsipakki> tormod: looks like there is going to be a new -ati this weekend :)
<tormod> the 6.7.195?
<tepsipakki> probably yes, since pci-rework isn't complete yet afaik
<tormod> will you push it into Gutsy as soon as it is out?
<tepsipakki> well, I asked someone to take a look at the debdiff of a merger with your package, but apparently it had too many changes already..
<tormod> but all the changes are good :)
<tepsipakki> so, why not upload a version with a subset of them
<tepsipakki> I know :)
<tepsipakki> but then the delta between a shipping driver and the new upstream would be smaller :)
<tepsipakki> cunning plan, eh? :)
<tormod> wicked :)
<tormod> but many of alex's commits depend on each other
<tepsipakki> true..
<tormod> those you asked, did they see a debdiff between 194-1ubuntu1 and -tv6 ?
<tepsipakki> basically, yes
<tepsipakki> http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
<tormod> if the fixed bugs would be triaged properly with high,important etc it would maybe be easier to slip it through the release managers?
<tormod> X not starting is pretty critical. But I don't have the triaging magic power.
<tepsipakki> you should join ubuntu-bugs then :)
<tormod> qa-team? that sounds like... work :)
<tormod> seems like many people have tested the -tv6 and are happy. maybe we should make a list of hardware tested?
<tepsipakki> actually, bugsquad is the team name I think
<tormod> I think it would be scandalous to release gutsy with the current gutsy ati, especially when fixes are available.
<tepsipakki> I agree
<tepsipakki> but, the freeze is not yet effective, so _technically it could be uploaded :)
<tormod> when's the freeze
<tepsipakki> later today..
<tepsipakki> bryce: ping?
<bryce> hi tepsipakki
<tepsipakki> bryce: hi, we were just discussing the ati situation
* bryce nods
* bryce reads backlog
<bryce> sorry, was caught up in email discussion about agenda items for uds
<tormod> we could take out the "remove cruft and dead code" commits, if that would help some release manager
<bryce> if you point me at bugs, I can take care of marking them triaged/high/-rc candidates, etc.
<tepsipakki> me too
<tepsipakki> I have the list in front of me
<bryce> tepsipakki: who did you talk to that said the delta was too much?
<tepsipakki> if we mark all the "fix committed" bugs as high/critical and milestone rc?
<tepsipakki> bryce: mdz, but he didn't say it quite like that.. a sec
<bryce> the angle I've been working is to demonstrate it fixes 86072.  James Troup is the guy in charge of all of Canonical's IT infrastructure
<bryce> so if the newest -ati solves his problem, it gives us a LOT of weight
<tepsipakki> 17:43 < mdz> tepsipakki: I won't speak for the release team, but "works for someone" is not  very compelling.  wouldn't you prefer to upload something better tested after  release, rather than pushing in something less tested before release?
<bryce> ah
<tepsipakki> bryce: I think it does fix that
<bryce> yeah sounds like we just need to tighten up our story a bit, with good evidence of proven things it fixes, etc.
<bryce> ideally, associating each change with a specific high priority bug would help
<tepsipakki> yes, I didn't do that.. easily fixed
<bryce> I've been taking that approach with some of my other changes.  sort of a PITA, but reviewers are getting more strict, so I find it helps a lot
<bryce> in any case, the extra triaging work helps clear more bugz :-)
<tepsipakki> sure. I did point out those three "fix committed" bugs which all had the same issue; no X
<tormod> could we work out this together on a wiki page or using gobby?
<tepsipakki> heck, I'll mark those as critical :)
<bryce> no, let's save critical for nuclear bomb situations... High should be sufficient
<tepsipakki> hrm, ok :)
<tormod> critical is only for bugs reaching a good portion of the users.
<tepsipakki> right
<bryce> also at some point here, maybe next week, we should go through the whole xserver-xorg-video-ati bug list and close out all the ones that are fixed now, and ask folks to re-test the ones we're not sure about
<bryce> (unless you feel it's all already covered - but I think a top-to-bottom review focused on -ati could be a big help going into Hardy since so much has changed.)
<tepsipakki> absolutely
<tepsipakki> I've now marked those bugs we talked about as high
<tepsipakki> bryce: so, do you think we could upload 194-1ubuntu2 with fixes for these bugs, or wait for .195 and file a FFe request?
<tepsipakki> or do both
<bryce> tepsipakki: I think your strategy of uploading an intermediate, to make the delta between it and the release smaller, is quite wise
<bryce> it'll also help for testing
<bryce> so, for Hardy it sounds like the focus will be for "shoring up old features"
<bryce> colin says that in our past releases, sometimes features were completed for the release, and folks moved on; some of those features need additional polish or rework based on findings since then
<tepsipakki> bryce: ok, I'll re-merge and upload then :)
<bryce> for X, really the only thing that came up was discover-data
<bryce> what I've proposed doing for Hardy is for us to extract the pci id list from discover-data, so discover can finally be dropped entirely
<tepsipakki> upstream&debian are going to do that from the drivers
<bryce> I think we still need something like the pci id list, in order to do overrides, but in general I think we can rely more on X to autodetect stuff, and try to minimize the size of it
<tepsipakki> what about new upstream versions, any chance of xserver-1.5?
<tepsipakki> scheduled for February I think
<bryce> the discussion was focused only on ubuntu-specific things
<bryce> well, definitely definitely 1.4 of course
<tepsipakki> ah
<bryce> since Hardy is a LTS, I'm a bit iffy on putting in 1.5 at the last minute
<tepsipakki> is it going to be LTS right from the start, or later (like 8.04.1 or so)
<tepsipakki> ?
<bryce> on the other hand, I'm a lot more comfortable with what the process is now, so if we have to do it, it scares me less than 1.4 for gutsy
<bryce> I assume from the start
<tepsipakki> ok
<tormod> tepsipakki: by "re-merge" do you mean you will take out some patches?
<tepsipakki> tormod: yes..
<tormod> which ones?
<tepsipakki> I guess only 02 and 04 can be safely removed?
<tepsipakki> haven't tried
<tormod> and the "cruft" part of 09
<tepsipakki> well, 02 needs to be there, otherwise 03 won't apply
<tormod> are you sure 02 can be removed .ok
<tepsipakki> can't be removed
<tormod> it's basically one piece of work, that Alex commited bitwise.
<tepsipakki> the cruft part of 09 is self-explanatory, so that can stay IMHO
<tormod> we could do 08 separately/later but that would just be kind of ridiculous.
<tepsipakki> 04 is big though
<tepsipakki> right
<tormod> 04 is big in lines, but it's removing an unused function...
<tepsipakki> I was just coming to that :)
<tormod> (two unused functions)
<tormod> the question is if the release managers have put on their "manager" hats :)
<tepsipakki> well, if the idea was to upload this intermediate version first then they need not to bother.. :)
<tepsipakki> ok, new debdiff with bug-closers (?) http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
<tepsipakki> now tv for awhile->
<tormod> tepsipakki: so same patches, but with LP links?
<tormod>  /(LP: #86072. #144011)/s/./,  (if that matter, not sure)
<tepsipakki> oh, right
<bryce> too bad we don't have more LP ID's
<tepsipakki> well, bug #139241 should be easy :)
<ubotu> Launchpad bug 139241 in xserver-xorg-video-ati "DRI hangs on radeon Xpress 200M [1002:5975] " [High,Confirmed]  https://launchpad.net/bugs/139241
<bryce> I might suggest rephrasing things a little, so that for instance if patch 02 is a pre-req for another patch that fixes a LP issue, to describe it as "pre-requisite for patch X, which fixes LP NNN"
<tepsipakki> sounds good
<tepsipakki> I think bug 141547 is another candidate that this version should fix
<ubotu> Launchpad bug 141547 in xserver-xorg-video-ati "[Gutsy]  after ati driver update, only a black screen (light is on)" [Undecided,Incomplete]  https://launchpad.net/bugs/141547
<tepsipakki> oh, that's fixed already
<tormod> 139241 needs a patch though
<tepsipakki> yep
<tepsipakki> that's also a big strange, since I think he had a different card when he reported that
<tormod> I think the pci id list has changed in between
<tepsipakki> RS482 is 10025974, RS485 is 10025975 :)
<tormod> are you sure?
<tepsipakki> yes
<tepsipakki> looking at current discover-data
<tormod> I saw the same in another bug
<tormod> bug #144760 also made me pretty confused with pci ids
<ubotu> Launchpad bug 144760 in xorg "compiz/DRI crashes on Xpress200M/AMD64 [1002:5975]  (dup-of: 139241)" [Undecided,Confirmed]  https://launchpad.net/bugs/144760
<ubotu> Launchpad bug 139241 in xserver-xorg-video-ati "DRI hangs on radeon Xpress 200M [1002:5975] " [High,Confirmed]  https://launchpad.net/bugs/139241
<tepsipakki> ah, ok
<tormod> http://launchpadlibrarian.net/9504887/vvnn clearly shows 482=5975 at the time
<tepsipakki> yes, maybe that has been since fixed
<tepsipakki> so it really is 485
<tormod> yes I guess so
<tormod> I try to put the confirmed pci id in the summary when I can
<tormod> however in the driver source you'll find PCI_CHIP_RS482_5975 !
<tepsipakki> lovely
<bryce> http://people.ubuntu.com/~brian/testing_graphs/xserver-xorg-video-ati.html - nice to see the big drop over the past week
<tormod> tepsipakki: you saw my upstream bug for 139241?
<tormod> bryce: yes, I take some of the honour :)
<tepsipakki> tormod: yes, that patch should do it?
<tormod> tepsipakki: yes it looks simple enough
<tormod> tepsipakki: you could ask upstream anyway, why they haven't committed it?
<tepsipakki> hmm, alex is not online
<tormod> tepsipakki: maybe because there was no upstream reports about RS485
<tepsipakki> but that's the one :)
<tepsipakki> you just said that the source lists both 5974 and 5975 as RS482
<tepsipakki> when in fact 5975 should be RS485
<tormod> the source just uses it as macros
<tormod> it will report them as ATI Radeon XPRESS 200 5974 (PCIE) and  ATI Radeon XPRESS 200M 5975 (PCIE)
<tormod> nobody complained about 5974, so I guess 5974 cards work and 5975 cards fail. Probably all "mobility" versions fail.
<tepsipakki> ok
<bryce> tormod yes good work!  :-)
<tepsipakki> but the point was that 5975 is RS485, and 5974 is RS482 :) so, the source should be updated to reflect that like the current pci-ids :)
<tepsipakki> but that's not important now
<tepsipakki> I'll mention that in the changelog though..
#ubuntu-x 2007-10-06
<tepsipakki> oh bummer, archive frozen
<bryce> yeah just saw that
<bryce> work through slangasek 
<tepsipakki> and I was looking for more bugs to close with this
<tepsipakki> duh
<tepsipakki> I will
<bryce> <slangasek> bryce: "freeze" only means "release team reviews and judges"; if they're high priority updates, upload them :)
<bryce> tepsipakki: so I got a pre-okay for you for the -ati upload :-)
<tepsipakki> woohoo \o/
<tepsipakki> ok, I got a nice inter-dep chain of the patches: 02 -> 03 -> 07 -> 09
<tepsipakki> and 05 -> 09
<tepsipakki> so now they are all covered; they either fix bugs or are required for a later patch :)
<tormod> tepsipakki, I was thinking making an upstream patch for that rs482/5 thing
<tepsipakki> tormod: cool
<tormod> pre-okay \o/
<tepsipakki> ok, final check for the diff: http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
<tepsipakki> patch 10 should be under [tormod volden]  though :P
<bryce> (LP: 132716) -> (LP: #132716)
<tormod> heh all those prerequisites, you could make a graphical map to explain this :)
<bryce> heh no kidding
<tepsipakki> bryce: damn, will fix
<bryce> I sort of wonder if listing them in reverse would be better so the fixes are at the top.  ;-)  but I think it should be fine like this; at least it will be clear that the patches are necessary and not just extras along for the ride
<tepsipakki> also pre-req -> prereq
<tepsipakki> bryce: right, I'll just make more errors if I start shuffling them around :)
<bryce> patch 04 doesn't list as a prereq nor as a bug fix
<tepsipakki> true, I'll add an explanation
<bryce> otherwise, changelog looks good
<bryce> should I review the patches themselves?  I assume they're all tested and good.
<tepsipakki> well, they are upstream, so.. :)
<bryce> heh, we all trust alex
<tepsipakki> blindly
<tepsipakki> not!
<tormod> we have no choice :)
<bryce> :-)
<ubotu> New bug: #149639 in xorg (main) "Xorg crashes very frequently" [Undecided,New]  https://launchpad.net/bugs/149639
<tormod> seriously, they have been tested on quite a number of cards.
<tepsipakki> ok, diff updated, now chat with RM ->
<tormod> I made that upstream patch, but now n
<tormod> now bugs.fd.o is failing...
<tepsipakki> typical
<tormod> alex is back in #xorg-devel
<tepsipakki> yes, and ati uploaded
<tepsipakki> tormod: will you poke him?
<tepsipakki> bryce: I milestoned all the bugs that this upload should fix
<tepsipakki> five of them
<bryce> great
<tormod> tepsipakki: I poked alex
<tepsipakki> tormod: yep, thanks
<ubotu> New bug: #44792 in xserver-xorg-video-ati (main) "Fixed resolution usign ati driver with Radeon 7500SE" [Medium,Incomplete]  https://launchpad.net/bugs/44792
<tepsipakki> hmm, ati bug count soon below 100 (105 now)
<bryce> yay!
<bryce> hmm, I see 125
<tepsipakki> uh, so do I now
<tepsipakki> maybe it's b.e.lp.net playing tricks
<tepsipakki> sort by recently changed
<tepsipakki> actually, it doesn't matter what sort method to use, they all list 20 less
<bryce> huh, weird
<tepsipakki> yeah.. well, it'll get below 120 anyway :)
<bryce> :-)
<tepsipakki> anyway, bedtime. good night!
<ubotu> New bug: #149653 in xorg (main) "Xorg crash with xrandr1.2 and dual screens with compiz" [Undecided,New]  https://launchpad.net/bugs/149653
<bryce> night
<bryce> tepsipakki: if you're not yet asleep, I have a quetion on bug 126425
<ubotu> Launchpad bug 126425 in xorg-server "Intel driver (using EXA) crashes system when starting compiz" [Undecided,Confirmed]  https://launchpad.net/bugs/126425
<bryce> they propose dropping patch 120 from xserver; I was wondering why we are carrying it.
<tormod> tepsipakki: I just reported that sorting issue to launchpad this morning
<tormod> good night I guess :)
<tormod> I am off to bed as well. Cool that we got that far with the ati driver tonight!
<tormod> 6.7.194-1ubuntu2 got through! that was fast
<tormod> good night
<bryce> awesome, good work you two!
<bryce> and just now of course alex released 6.7.195 ;-)
<ubotu> New bug: #40249 in xserver-xorg-input-synaptics (main) "Laptop test: touchpad scroll on Dell Inspiron 600m doesn't work" [Medium,Fix released]  https://launchpad.net/bugs/40249
<ubotu> New bug: #149662 in xorg (main) "Upgrade to Kubuntu 7.10 beta in Spanish fails to get some .deb's" [Undecided,New]  https://launchpad.net/bugs/149662
<ubotu> New bug: #149684 in linux-restricted-modules-2.6.22 (restricted) "linux-restricted-modules-2.6.22-13-generic is not available and makes boot finish on failsafe x interface" [Undecided,New]  https://launchpad.net/bugs/149684
<ubotu> New bug: #149700 in xserver-xorg-driver-vmware (main) "Resolution greater than screen resolution used by vmware driver by default" [Undecided,New]  https://launchpad.net/bugs/149700
<tepsipakki> aw dammit, ati failed to build because of a typo in patch 10 I guess.. but we could just as well sync with debian which has .195. delta is small :)
<bryce> yup
<ubotu> New bug: #149726 in linux-restricted-modules-2.6.22 (restricted) "[Gutsy]  xorg-driver-fglrx: multihead breaks catastrophicly" [Undecided,New]  https://launchpad.net/bugs/149726
<bryce> tepsipakki: ok that's permission to upload :-)
<ubotu> New bug: #149732 in xorg (main) "After last update,Xorg can't want to start" [Undecided,New]  https://launchpad.net/bugs/149732
<bryce> heya mvo
<tormod> ati 6.7.195-1 is out in Debian...
<bryce> maybe we should just sync to that?
<bryce> tormod, we have permission from RM to upload 195
<tormod> excellent!
<bryce> tormod: and unfortunately our -ati upload FTBFS
<tormod> oops that bad. it was just happily building when I went to bed.
<tormod> did tepsipakki build it himself first?
<bryce> not sure, maybe not
<bryce> <tepsipakki> aw dammit, ati failed to build because of a typo in patch 10 I guess.. but we could just as well sync with debian which has .195. delta is small :)
<tormod> yes that's better. the delta is real small, basically Michel's exa commits.
<bryce> :-)
<tormod> I was thinking about building test packages of .195, but maybe that's not needed if you just upload it.
<bryce> probably not
<mvo> hey bryce
<bryce> mvo, how goes?  long time no see :-)
<mvo> bryce: good, thanks! the usual almost-at-release madness
<bryce> yup
<bryce> I'm proud of where we're at with gutsy but also know we can do a lot better for hardy
<bryce> mvo, fwiw I reinstalled onto an ati laptop recently and was impressed to see compiz come up and "just work"
<mvo> bryce: woah, that is cool. it at  a good level currently, I'm quite happy with the status
<bryce> you've done a great job at getting compiz ready to go, I'm quite impressed.
<bryce> I think gutsy is going to be an upgrade people notice.  :-)
<mvo> thanks!
<tormod> bryce, I found a (yet another) bug in xresprobe, and I have a debdiff in bug #148231. It could be that it fixes a lot issues,
<ubotu> Launchpad bug 148231 in xresprobe "[gutsy]  bad modes in xorg.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/148231
<tormod> please take a look and tell me if you want me to fix all the non-vesa cases as well.
<tepsipakki> tormod: ouch, that vesa change was mine..
<tepsipakki> yep, b0rked sed-line
<tormod> tepsipakki: sorry about that ati 10_ patch, I guess I should have tested better, like you ;)
<tormod> tepsipakki: almost all the other driver cases have the same "non-robustness"
<tepsipakki> no problem, most important that there now is a new release, and jcristau was as fast as always uploading it to experimental :)
<jcristau> ;)
<tepsipakki> merge done, quick check of the debdiff and then upload
<tepsipakki> done
<tormod> great
<tepsipakki> bryce: I'll check patch 120 now
<tepsipakki> ah, that's for making composite faster with current drivers
<tepsipakki> without that it would crawl
<tepsipakki> but we should evaluate it again when hardy opens, and perhaps enable EXA on some hardware (which would obsolete that hack)
<tormod> I added xresprobe improvements for other drivers. Does anyone have a xorg.conf collection for regression testing?
<tormod> actually it would be much better to fix the drivers to report this in a consistent way...
<ubotu> New bug: #149661 in linux-restricted-modules-2.6.22 (restricted) "[Gutsy]  Update fails to install "linux-restricted-modules-generic"" [Undecided,New]  https://launchpad.net/bugs/149661
<ubotu> New bug: #149782 in linux-restricted-modules-2.6.22 (restricted) "linux-restricted-modules missing for 2.6.22-13" [Undecided,New]  https://launchpad.net/bugs/149782
<ubotu> New bug: #130696 in linux-restricted-modules-2.6.22 (restricted) "xine and totem-xine crashes with the fglrx driver" [Medium,New]  https://launchpad.net/bugs/130696
<ubotu> New bug: #57345 in xorg-server (main) "No devices detected. after update to xserver-xorg-core 1:1.0.2-0ubuntu10.3 (dup-of: 57153)" [Medium,Fix released]  https://launchpad.net/bugs/57345
<ubotu> New bug: #149850 in xorg (main) "Cannot change resolution in Gutsy LiveCD with Vmware" [Undecided,New]  https://launchpad.net/bugs/149850
<ubotu> New bug: #66104 in scim (main) "scim input freezes in various applications" [Medium,Confirmed]  https://launchpad.net/bugs/66104
<ubotu> New bug: #149682 in linux-source-2.6.22 (main) "kernel crash after logo loadup (dup-of: 149661)" [Undecided,New]  https://launchpad.net/bugs/149682
<ubotu> New bug: #149866 in xserver-xorg-video-ati (main) "Open source radeon driver problems" [Undecided,New]  https://launchpad.net/bugs/149866
<ubotu> New bug: #149868 in xserver-xorg-video-ati (main) "Open source radeon driver problems" [Undecided,New]  https://launchpad.net/bugs/149868
<ubotu> New bug: #149559 in gxine (universe) "Gxine crashes on launch with BadMatch error (dup-of: 130696)" [Undecided,Incomplete]  https://launchpad.net/bugs/149559
<ubotu> New bug: #146228 in linux-restricted-modules-2.6.22 (restricted) "Gutsy Reboot on Resume, nvidia-glx-new and linux-2.6.22-12" [Undecided,New]  https://launchpad.net/bugs/146228
<ubotu> New bug: #149929 in xorg (main) "X broken by -13 kernel, -12 still OK" [Undecided,New]  https://launchpad.net/bugs/149929
<tepsipakki> bah, seems that there are no RM's available to let the new ati through
<ubotu> New bug: #149952 in xserver-xorg-video-nv (main) "Gutsy Regression: Nvidia Riva 128 not supported (Cairo errors)" [Undecided,New]  https://launchpad.net/bugs/149952
<tormod> tepsipakki:  no luck?  it's uploaded but in the review queue?
<tepsipakki> tormod: right
<tormod> when is the hard freeze?
<tepsipakki> no idea..
<tormod> the RC release is the 11th, so there should be some days
<bryce> tormod, wow yeah I wonder how we hadn't run into issues with those sed lines before
<tormod> hi bryce
<tormod> yeah it's quite a mess
<tormod> bryce: I thought I found another dupe of 127008, but they say it's still broken: bug #128526
<ubotu> Launchpad bug 128526 in xresprobe "probing for X, causes scrambled Frame Buffer (dup-of: 127008)" [Undecided,Incomplete]  https://launchpad.net/bugs/128526
<ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)" [High,Fix released]  https://launchpad.net/bugs/127008
<bryce> tormod: hmm, I wish solfred had given some details beyond just "still broke"
<tormod> you'd expect that to be "exactly same as before" but I am not 100% he's got the same issue as the reporter.
<tormod> "same problem" often means "I have a problem too with a similar card" :)
<tormod> actually the F4 workaround doesn't work for him, so maybe he's got something else.
<bryce> right
<bryce> if I had a dollar for every time I heard, "I have the same problem, except I am running a completely different driver, on a different version of Ubuntu"
<tepsipakki> bryce: well, X still works even if the modes line has cruft :/
<tormod> yes, if no modes are lost, it's maybe no practical problem, just looks stupid
<tepsipakki> right :)
<ubotu> New bug: #149957 in xorg (main) "Cannot install Gutsy Beta on Samsung R60+" [Undecided,New]  https://launchpad.net/bugs/149957
#ubuntu-x 2007-10-07
<ubotu> New bug: #149970 in xorg (main) "Cursor disappears when busy if compiz is on" [Undecided,New]  https://launchpad.net/bugs/149970
<tormod> 'night
<rawler> hey people
<rawler> I did a dist-upgrade today, and for one, the nvidia-driver broke (some packages were missing on the mirror), once that was resolved, I'm now having problems with my keyboard..
<rawler> non-english characters are broken, and not even ctrl+alt+f1 works..
<rawler> tried a dpkg-reconfigure xserver-xorg, but that didn't help..
<rawler> anyone know anything about this?
<rawler> strange.. it seems to be resolved after removing swedish from the gnome-keyboard-config, and then re-adding it.. (ignoring some errors)
<ubotu> New bug: #150019 in xorg (main) "Must Click Desktop to See Panels" [Undecided,New]  https://launchpad.net/bugs/150019
<ubotu> New bug: #150022 in xorg (main) "X Crashes While Opening Screensaver Window" [Undecided,New]  https://launchpad.net/bugs/150022
<rawler> nice, it seems to come back on "reset to defaults"
<rawler> goodie, that gave me an opportunity for troubleshooting.. :)
<rawler> if I click "reset to defaults", i get a popup telling me there was an error, encouraging me to check, amongst other things, gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
<rawler> ulrik@ulrik-desktop:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
<rawler>  layouts = [] 
<rawler>  model = 
<rawler>  options = [] 
<rawler>  overrideSettings = true
<rawler> if I then add an english layout, the same error pops up again, and the gconf-settings are now;
<rawler> ulrik@ulrik-desktop:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
<rawler>  layouts = [se  sv-latin1,us] 
<rawler>  model = 
<rawler>  options = [grp grp:alts_toggle] 
<rawler>  overrideSettings = true
<ubotu> New bug: #150024 in xorg (main) "Every Third Time I Login, I get Errors for Items on Panel" [Undecided,New]  https://launchpad.net/bugs/150024
<rawler> lastly, I remove and re-add the swedish keyboard, which makes everything behave again, now gconf looks like;
<rawler> ulrik@ulrik-desktop:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
<rawler>  layouts = [se] 
<rawler>  model = 
<rawler>  options = [grp grp:alts_toggle] 
<rawler>  overrideSettings = true
<rawler> so, from what I can see, something in the gconf-defaults explicitly spell out (incorrectly) "se  sv-latin1" for default..
<rawler> now, I don't know enough about gconf to know where to change this.. anyone else?
<ubotu> New bug: #150025 in xorg (main) "Bulletproof X broken for nVidia" [Undecided,New]  https://launchpad.net/bugs/150025
<ubotu> New bug: #150038 in linux-restricted-modules-2.6.22 (restricted) "updates of linux-restricted-modules-common clobber /etc/default/linux-restricted-modules-common" [Undecided,New]  https://launchpad.net/bugs/150038
<ubotu> New bug: #150059 in xorg (main) "Unable to start X after installing 7.10 beta w/ ATI Mobility FireGL V5250" [Undecided,New]  https://launchpad.net/bugs/150059
<ubotu> New bug: #150061 in xorg (main) "Resolution settings losses its settings every time I reboot" [Undecided,New]  https://launchpad.net/bugs/150061
<ubotu> New bug: #150078 in xserver-xorg-video-ati (main) "r128 driver wakes up too often (85/sec at idle)" [Undecided,New]  https://launchpad.net/bugs/150078
<ubotu> New bug: #150098 in xserver-xorg-video-ati (main) "X crashes on ATI Radeon R100 for driver version 6.7.194" [Undecided,New]  https://launchpad.net/bugs/150098
<ubotu> New bug: #150092 in xserver-xorg-video-ati (main) "xrandr and radeon drives BenQ FP231W incorrectly" [Undecided,New]  https://launchpad.net/bugs/150092
<ubotu> New bug: #150109 in xserver-xorg-video-intel (main) "[Gutsy Beta]  Black screen when resume from Suspend to RAM" [Undecided,New]  https://launchpad.net/bugs/150109
<ubotu> New bug: #150114 in xserver-xorg-video-intel (main) "[Gutsy Beta]  Intel is much slower than i810" [Undecided,New]  https://launchpad.net/bugs/150114
<ubotu> New bug: #150125 in linux-restricted-modules-2.6.22 (restricted) "nvidia-glx-new breaks sound" [Undecided,New]  https://launchpad.net/bugs/150125
<ubotu> New bug: #136801 in xserver-xorg-video-ati (main) "Open a MP3 -> totem crash" [Medium,Incomplete]  https://launchpad.net/bugs/136801
<ubotu> New bug: #150142 in xserver-xorg-video-intel (main) "Starting X on G33 fails" [Undecided,New]  https://launchpad.net/bugs/150142
<ubotu> New bug: #149954 in xorg (main) "gdm failsafe starts, but does not bring one to the desktop" [Low,New]  https://launchpad.net/bugs/149954
<ubotu> New bug: #149202 in scim (main) "keyboard doesn't work in nautilus (dup-of: 66104)" [Low,New]  https://launchpad.net/bugs/149202
<ubotu> New bug: #147649 in xorg-server (main) "gutsy: rhythmbox visualization kills X" [Medium,New]  https://launchpad.net/bugs/147649
<ubotu> New bug: #150175 in xserver-xorg-video-ati (main) "ATI Radeon driver does not accept custom PAL resolution" [Undecided,New]  https://launchpad.net/bugs/150175
<tepsipakki> yeah, ati accepted
<ubotu> New bug: #150274 in xserver-xorg-video-ati (main) "XVideo doesn't work" [Undecided,New]  https://launchpad.net/bugs/150274
<ubotu> New bug: #150278 in xserver-xorg-video-ati (main) "latest update of xserver-xorg-video-ati moved screen to high on ati raedon mobilty 7500" [Undecided,New]  https://launchpad.net/bugs/150278
<ubotu> New bug: #150302 in xorg (main) "LiveCD puts monitor into standby mode" [Undecided,New]  https://launchpad.net/bugs/150302
<bryce> heya tepsipakki
<tepsipakki> hi bryce, ati got accepted today :)
<tepsipakki> again..
<tepsipakki> I've pushed a new ati for my ppa, possibly fixes bug 150278
<ubotu> Launchpad bug 150278 in xserver-xorg-video-ati "latest update of xserver-xorg-video-ati moved screen to high on ati raedon mobilty 7500" [Undecided,Incomplete]  https://launchpad.net/bugs/150278
<tepsipakki> and someone already mentioned on another bug the symptoms of freedesktop bug 12720
<tepsipakki> https://bugs.freedesktop.org/show_bug.cgi?id=12720
<tepsipakki> that fix should cover both
<ubotu> Freedesktop bug 12720 in Driver/Radeon "picture misses colors and has pixel-lines instead" [Major,New]  http://bugzilla.freedesktop.org/show_bug.cgi?id=12720
<ubotu> Freedesktop bug 12720 in Driver/Radeon "picture misses colors and has pixel-lines instead" [Major,New]  
<tepsipakki> huh, I was faster than ubotu
<ubotu> New bug: #150361 in xserver-xorg-driver-ati (main) "Display corrupted after last ATI driver update" [Undecided,New]  https://launchpad.net/bugs/150361
#ubuntu-x 2008-09-29
<solarion> anyone know what the status is with elantech touchpads?
<wgrant> solarion: I believe it's waiting on kernel support - see bug #123775.
<ubottu> Launchpad bug 123775 in linux "Elantech touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Unknown,Confirmed] https://launchpad.net/bugs/123775
<tjaalton> wgrant: I've uploaded inputproto and libxi to my ppa, xserver to follow. includes the API changes
<wgrant> tjaalton: SHall we get people for whom xinput is erroring for to test them?
<tjaalton> wgrant: no synaptics yet
<tjaalton> or xinput
<wgrant> Well, I meant after that.
<tjaalton> yeah, sure
<tjaalton> I'll do those next
<wgrant> Great - once you've done those I'll do my bit.
<wgrant> Do you know of any existing efforts to give g-c-c proper device-specific property support? I might consider working on that for Jaunty if nobody else can be bothered.
<tjaalton> you'd have to ask gnome upstream about it.. or just declare that you're doing it :)
<tjaalton> xinput done
<tjaalton> Ng: you had problems with the synaptics settings being lost after resume? could you check the logfile if there's something new
<tjaalton> after it happens
<tjaalton> wgrant: synaptics updated & uploaded
<wgrant> tjaalton: Excellent, I'll grab it in 9 minutes when LP finishes with it, hopefully.
<tjaalton> wgrant: ok cool. I'll be around for ~2h before going to see WALL-E, so be quick to poke if there's something missing :)
<tjaalton> uh, synaptics failed to build
<wgrant> Urgh.
<tjaalton> ../../src/synaptics.c:728: error: too many arguments to function 'XIRegisterPropertyHandler'
<tjaalton> bah
<seb128> tjaalton: hey, do you know if anybody is working on fixing xvfb?
<tjaalton> seb128: hmm, no..
<tjaalton> wgrant: ok, see the bug
<tjaalton> wgrant: in a patch of mine
<wgrant> tjaalton: I don't see any patches of yours in the bug...
<tjaalton> wgrant: I mean, that build problem was due to a patch in the synaptics upload :)
<tjaalton> buggy refresh
<wgrant> Oh, you mean "ok, I see the bug". Right.
<tjaalton> um, yes :)
<tjaalton> wgrant: heh, the failure was due to the xserver being too old.. so I need to bump the build-dep
<wgrant> tjaalton: Ah, you don't actually need to...
<wgrant> You probably just started the build before the new xserver was published (*/2))
<wgrant> Er, */20
<tjaalton> well, it depends on the properties API, so it should be bumped anyway
<wgrant> True.
<Ng> tjaalton: it wasn't synaptic settings as such, I disabled my touchpad in the BIOS. It's the xinput settings I'm running for scrollwheelemulation that's being lost across suspend/resume, presumably (as I think you suggested) because the device disappears and re-appears
<tjaalton> Ng: yes, probably because of that
<tjaalton> so it'd need g-s-d support
<Ng> yeah
<wgrant> Generic property support in g-s-d would be rather useful.
<Ng> which reminds me, I need to scan my rough idea sketch about a capplet for that stuff to show to tseliot
<Ng> I reckon it's going to involve a bunch of nasty white/black listing because the xinput API seems to be awfully generic and unhelpful ;)
<wgrant> Ah, tseliot is looking at implementing it in capplets too?
<Ng> like every mouse-ish device seems to report having 32 buttons :/
<Ng> wgrant: he said he was interested, yeah
<Ng> I'm starting to lose my conviction that it's actually particularly necessary, unfortunately
<wgrant> Why?
<Ng> wgrant: touchpads not withstanding (mine is disabled, so I've not seen what properties they expose yet), it just seems like the options aren't particularly useful in a general use case
<Ng> the only thing I can think might be handy would be a "help my scrollwheel isn't working, click here and then scroll up" to detect such things (since they're mapped as buttons and figuring out which buttons to put on the Z axis is non-obvious
<wgrant> Ng: Hmmm... Disabling, middle button emulation, speed...
<Ng> disabling yeah, but there are tricky aspects to that - I disabled my touchpad in the bios because if I disable it with the existing mouse capplet it also takes out the buttons on the trackpoint, leaving me with no mouse buttons at all
<wgrant> Erm.
<wgrant> I doubt it.
<wgrant> Or does the trackpoint share the device?
<Ng> I believe they are shared through the same device
<wgrant> Ah. Stupidity.
<Ng> I guess it's easy enough to stop people destroying their system with a "click here to confirm these settings otherwise they will revert in 30 seconds" thing, but still
<Ng> I'm pretty sure most people don't care about middle mouse buttons, and even fewer care about scrollwheel emulation (which is the only bit I particularly care about)
<wgrant> We could do that, or we could force people to have at least one checked.
<Ng> yeah I think it should do that
<Ng> and if you only have an external USB mouse enabled and unplug that, something else should become enabled
<Ng> the only question is what. I can give you the correct answer for my laptop, but possibly not for some random Toshiba laptop on the desk next to me
<wgrant> No, we alter the USB spec such that it has a hardware locking feature that doesn't let the device out when it's enabled. Much better solution.
<Ng> haha :)
<Ng> the buttons/scrolling thing is particularly distressing though
<wgrant> Hm?
<Ng> these days mice come with umpteen buttons and scroll in multiple directions, but afaik there's no way to actually tell what they are
<Ng> other than asking lots of questions
<wgrant> Is there really no spec to report them?
<Ng> I could be wrong, but I don't think so. scroll events are just other buttons
<wgrant> How do Those Other OSes do it?
<Ng> drivers
<wgrant> Scroll events can also be special, can't they?
<wgrant> Delta-based, or something like that..
<wgrant> So you have to install a custom driver?
<wgrant> I can't say I've ever used a mouse with more than 5 buttons.
<wgrant> (including scrollwheel)
<Ng> generally you get a CD with your mouse and that has the software that sits on top of windows' generic mouse drivers and has a configurator for "this button means launch windows explorer, that one means go back a page in IE, etc"
<wgrant> Ah. So there's no standard UI.
<wgrant> We must be able to do better than that.
<wgrant> I'm quite surprised that there's no obvious way to ask the mouse what it does.
<Ng> I'm curious if there's a way to map back from the devices that X reports to their underlying HAL device
<Ng> specifically to get the USB ids if there are any
<Ng> that way there could at least be some kind of database of devices, or hooks for manufacturers to add their own
<wgrant> I didn't see one. But it would certainly make sense...
<wgrant> Maybe evdev could set a property.
<wgrant> As long as we can have immutable properties...
<Ng> with no disrespect to the authors of this API, it seems kinda like it's a "damn we need something because xorg.conf is going away", not "let's make a great way for people to configure their devices" :/
<wgrant> What can you see as missing?
<Ng> well a link to the HAL device seems like a must
<wgrant> One would think so.
<Ng> I'd like to know if the devices do actually expose any real information about how many buttons they have,b because all of the ones I have just say 32 which is clearly nonsense, so that property should probably either return "Unknown" or not exist
<wgrant> Indeed.
<Ng> with the disclaimer that I've been probing with xinput(1) more than with the raw API, I don't see a way to set per-device acceleration
<wgrant> I haven't seen one... but that's not so much an issue with the API.
<Ng> (which seems like it could be one of the main use cases for this for "ordinary" users (I'm thinking about where you have a touchpad and a usb mouse and high acceleration for the former makes no sense, but is entirely valid for the latter)
<Ng> true, that's not an API design thing
<wgrant> My main complaint is that there's no way to transmit floats - but that's more just because an XAtom doesn't exist for such things.
<wgrant> That could be why there's no acceleration exposed.
<Ng> can't that be solved with some powers of ten and ints? ;)
<Ng> I think the two biggest user problems with input devices are "my scroll wheel(s) didn't Just Work" and "I want these extra buttons to do something useful". I don't know how to solve either of those things gracefully, but they should be solved. If that means g-s-t needs to listen for random button events and launch things, so be it
<wgrant> I'd considered that... maybe some officially-sanctioned fixed-point representation.
<Ng> gnome already has a capplet which listens for random keyboard events to launch commands
<wgrant> metacity handles keyboard shortcuts, doesn't it?
<wgrant> Those commands are fixed, though (something I disagree with).
<Ng> hrm, yes that was a poor descriptoin, there's a capplet to *configure* something to listen for those events
<Ng> I think there is value in having fixed ones, but there should be some generic ones too (which compiz supports, via command0-command10)
<Ng> play/pause ones certainly make sense, since those are actual hardware buttons on a lot of systems now
<Ng> forward/back seems to be quite common on funkier mice
<Ng> tseliot: aha, just the person. we were just talking about the horrifying scope of an input device configurator ;)
<wgrant> tseliot: I was going to implement one, but I hear you also had the idea.
<tseliot> Ng, wgrant: yep
<tseliot> wgrant: what are you planning to do?
<tseliot> or how are you planning to do it?
<wgrant> tseliot: Hack some more useful per-device XInput property support into at least gnome-mouse-properties and g-s-d. I'd thought a little about the UI, but not a whole lot further yet.
<wgrant> To what depth are you asking?
<tseliot> wgrant: I was thinking about using fdi files for each device which the user wants to configure
<wgrant> Ah, to that depth. I see.
<wgrant> I was thinking that g-s-d would do it.
<wgrant> Can we reload fdi files on the fly?
<Ng> http://mairukipa.tenshu.net/xinput-capplet.pdf was the idea I had (apologies for the awful scan, and PDF format ;)
<wgrant> And can't they not set XI properties, just normal xorg.conf ones?
<tseliot> hmm, I wouldn't know about using xorg.conf options in fdi files
 * tseliot has a look at Ng's link
<wgrant> tseliot: /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi looks like it has normalish xorg.conf properties to me. Or is there a tag name that I'm missing?
<Ng> tseliot: to recap a bit what was said above, basically while sketching that I kinda realised there's not very much useful stuff that can be set at the moment, and there are problems with some of the options (e.g. disable my touchpad and I'll lose the buttons on my trackpoint, so a "click here within 30 seconds to confirm your settings" option seems wise ;)
<tseliot> wgrant: right, that's a good example
<tseliot> Ng: yes, it's what I was about to suggest
<Ng> :)
<Ng> one other thing... [09:38] < Ng> I think the two biggest user problems with input devices are "my scroll wheel(s) didn't Just Work" and "I want these extra  buttons to do something useful". I don't know how to solve either of those things gracefully, but they should be solved. If  that means g-s-t needs to listen for random button events and launch things, so be it
<tseliot> also we cannot predict how many options a device will have available
<Ng> but I didn't look at touchpads at all, that fdi file suggests they have lots of nice things to configure
<tseliot> therefore we might want to use a treeview to contain all the options
<Ng> hmm
<Ng> that would be the easy option, certainly :)
<tseliot> I was thinking about calling XInput from Python, unless we want to do the app all in C
<wgrant> Aren't the capplets entirely C?
<Ng> would a non-C capplet be accepted by gnome? I got the impression they don't like python
<tseliot> I would like to make something which can be used separately from GNOME or KDE
<wgrant> As much as I love Python, it's perfectly doable (and acceptable upstream) in C.
<tseliot> so that we don't have to rewrite the same thing for KDE
<tseliot> it's just an idea
<tseliot> I would like to use my X-Kit to parse and create fdi files
<tseliot> but X-Kit is written in Python
<tseliot> or we can do it all in C
<wgrant> It seems a but odd to do that when we've just got nice shiny XInput property support.
<wgrant> *a bit
<tseliot> and then I will port it to KDE
<tseliot> yes, I know
<tseliot> are you guys going to the next UDS?
 * wgrant is hoping too... but doubts his application will be accepted.
<wgrant> s/too/to/
<Ng> I will be at UDS, but to work, so I can't really attend any sessions
<tseliot> well, I applied for sponsorship too, so maybe we can meet there and talk about this
<Ng> so my discussions will be limited to lunchtimes and dinner/beer ain the evenings ;)
<Ng> I should be able to participate in fosscamp though, since our technical involvement with that is basically zero
<tseliot> Ng: who do you work for?
<wgrant> Sponsored people aren't at FOSScamp, are they?
<Ng> tseliot: Canonical
<tseliot> ah, ok
<Ng> I'm a sysadmin, and some of us go to UDS to provide the SIP/icecast hookups :)
<Ng> wgrant: dunno :/
<wgrant> How is the area that you use in the Google campus for VoIP? I forget - but most of the other venues are shocking.
<Ng> wgrant: we're in a new area of google this time, so that's unknown at present
<Ng> it's a really hard problem, unfortunately
<Ng> we have a polycom conference phone on each desk, with extension microphones on larger desks, but even then the acoustics of the rooms generally lend themselves very badly to a large group of people being recorded
<Ng> (and really big desks work very badly, because you end up with three conversations at each end of the table, all of which are equal volume on the voip stream, making remote participation basically impossible :(
<wgrant> The icecasts are usable in most cases (except for some really bad situations, but they're fortunately rare), and VoIP works well between VoIP participants... but VoIP-to-room has only been usable in three or four sessions for me.
<Ng> yeah, I think we're going to discourage the remote SIP participation and push icecast and a per-track IRC channel (either someone in the session will watch that, or it'll be projected on the wall, hardware willing)
<Ng> there may also be some other surprise experiments, hardware/google willing :)
<wgrant> Heh.
<tseliot> seb128: calling synaptic from the gnome-control-panel requires a text file containing something like "screen-resolution-extra\tinstall\n". Can I add the file to say, /usr/share/gnome-control-center/, or shall I make a temporary file (thus risking to overwrite an already existing temp file) and pass it to Synaptic?
<seb128> tseliot: why does it need a text file?
<seb128> tseliot: can't you use a *char which has the string?
<tseliot> no, I can't pass it a string
<tseliot> mvo knows why
<seb128> we don't create temporary files for other softwares who call synaptic
<wgrant> tseliot: Erm, how would it overwrite an existing temp file?
<tseliot> seb128: --set-selections-file is what allows you to pass a file to synaptic
<wgrant> If you're doing it that way, it is a security flaw and you're doing it wrong.
<mvo> seb128: we do (unfortunately) because gksu does not let us use stdin in synaptic (it closes that fd), so t control it it needs a file
<tseliot> wgrant: it can happen that a temp file with the same name exists. And I know that there is a right way to use temp files
<mvo> tseliot: check debian/patches/80_gst-packages-common.patch from the gnome-system-tools package
<tseliot> mvo: ok, thanks
<mvo> tseliot: it has code that you can use (like create_temp_file that does the right thing etc)
<tseliot> mvo: great, it's what I was looking for
<mvo> excellent!
<l33> hi
<l33> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mutouch/+bug/275650
<ubottu> Launchpad bug 275650 in xserver-xorg-input-mutouch "mutouch driver in hardy is Y axis Inverted" [Undecided,New] 
<jcristau> tjaalton, bryce: i uploaded x-x-i-mutouch today, fixes lp bug 275650, fwiw
<ubottu> Launchpad bug 275650 in xserver-xorg-input-mutouch "mutouch driver in hardy is Y axis Inverted" [Undecided,New] https://launchpad.net/bugs/275650
<jcristau> well, should fix, anyway :)
<bryce> jcristau: ah excellent, I'll take a look
<bryce> jcristau: the package isn't at ftp://ftp.debian.org/debian/pool/main/x/xserver-xorg-input-mutouch/ yet; is there I place it's held I can grab it from?
<jcristau> http://incoming.debian.org/
<bryce> thanks
<bryce> sync request filed - #275650
<solarion> wgrant: there's apparently a driver in existance
<solarion> wgrant: the last update (besides mine) on bug 123775 is saying Alpha5 is out and it might work now
<ubottu> Launchpad bug 123775 in linux "Elantech touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Unknown,Confirmed] https://launchpad.net/bugs/123775
<solarion> which it doesn't
<solarion> I guess the question is, how can I move things along?'
<solarion> the tap-to-click behavior is driving me crazy
<bryce> hi tormod
<tormod> hi bryce
<mnemo> what prefix should I use if I install the xorg intel driver on ubuntu?
<mnemo> just doing plain "sudo make install" doesnt seem to work
<bryce> from debian/rules:  ../configure --prefix=/usr [...]
<mnemo> bryce: hmm, what is debian/rules used for exactly? is it a build script? i know how to find the file and I see the prefix in there but I wonder what that file is used for? is it available for all debian packages?
<bryce> yes it is a build script for generating .deb files
<bryce> each debian package has a debian/rules file
<mnemo> oh excellent, this is very useful info for me
<mnemo> thanks bryce
<bryce> standby, I can give you a link with more info
<bryce> mnemo: this seems to be a fairly friendly tutorial on building debian packages in ubuntu:  http://women.debian.org/wiki/English/BuildingTutorial
<bryce> a lot more info is available on this from https://wiki.ubuntu.com/PackagingGuide/ if you'd like to learn it in more depth
<mnemo> thanks
<mnemo> bryce: im reading the packaging howto now, and I got a question (if you got time)... why do people use "fakeroot"? i mean, why does a program required me to lie to it about being root when the operation actual can run successfully without root?
<bryce> I don't know exactly, but all packaging systems I've used have required running as root
<mnemo> strange, sounds like a bug to me :D i'll try to google for the answer later
<bryce> perhaps non-root doesn't have sufficient access to the packaging system internals
<mnemo> but fakeroot has?
<bryce> actually, it is possible to build packages with non-root via debuild 
<bryce>  debuild -i -uc -us $pkg.dsc
<bryce> but that may use fakeroot internally, not sure
<mnemo> wait, yeah maybe the same binary is used to read and write some package data and to write the package data root might be required and instead of elevating in the middle of the program they decided that the program always will require root
<tjaalton> bryce: apart from evdev, all the drivers include their own fdi file
<tjaalton> bryce: I'll reply to the wacom thread tomorrow :)
<bryce> tjaalton: ah ok
<tjaalton> there seems to be some misinformation that needs to be corrected
<wgrant> solarion: The driver isn't in Linus' tree, so this isn't an X problem.
<wgrant> It's not in Linus' kernel, so it's not in our kernel by default, so it's a kernel problem.
<pwnguin> which wacom thread?
#ubuntu-x 2008-09-30
<tjaalton> pwnguin: the tablet-thread on u-d-d
<bryce> heya tjaalton
<wgrant> s/thread/war/
<tjaalton> wgrant: well that too
<tjaalton> bbl->
<pwnguin> ah, i dont actually read u-d-d
<pwnguin> im a bit dissapointed that vicenzo didn't send any mail to the toshiba tablet team he started
<tjaalton> bryce: hey dude
<tjaalton> hmm, writing this mail could take the whole day
<bryce> tjaalton: which email?
<tjaalton> bryce: the follow-up to the tablet-thread
<tjaalton> actually, I'll start a new one
<bryce> tjaalton: ah, ok; I ignored that thread (just looked like a flame war)
<wgrant> It's certainly getting that way...
<tjaalton> people don't realize that things do work just like before if they want to
<tjaalton> bryce: and that's the reason why I'll start a new thread..
<bryce> night
<tjaalton> night bryce
<tjaalton> dammit, forgot to remove the sig
<wgrant> tjaalton: Heh, I wondered if you intended to send that.
<wgrant> tjaalton: Is the XI property API stuff in your PPA done?
<tjaalton> oh :)
<wgrant> Not entirely what I expected... I presume an X crash combined with some bad kernel interaction.
<wgrant> Damn video drivers.
<tjaalton> wgrant: evdev uploading
<wgrant> I guess this means yet another input driver ABI bump...
<tjaalton> only those that support properties, which is evdev/syaptics
<tjaalton> +n
<wgrant> Are you sure? There seems to have been a renumbering of some constants in the first patch.
<tjaalton> hmm
<wgrant> (I'm looking at the one sent to the list, not the one you applied, so I might be wrong)
<tjaalton> well, does evdev work for you otherwise?
<wgrant> It seems to.
<wgrant> I have devices.
<jcristau> wgrant: the patch sent to the list applied to master, which has all the XI2 changes
<wgrant> I have a minimal xorg.conf.
<wgrant> So I presume evdev is working its magic.
<wgrant> jcristau: I suspected something of the sort.
<wgrant> So it's probably not as dangerous as I initially suspected.
<tjaalton> the backported properties only changed the numbering of the new stuff
<jcristau> the XI 1.4 stuff hasn't changed, so only property-using drivers are affected
<wgrant> OK, excellent.
<jcristau> might be good to at least bump serverminver though
<tjaalton> sigh, so many places to touch :)
 * wgrant kicks buildd-master.
<tjaalton> I've forgot what was the name of the function that wacom should use in order to be able to init multiple instances using the same driver
<wgrant> There are 10 idle i386-xen buildds, yet the build hasn't started.
<tjaalton> NewFoo..
<jcristau> NIDR, i think :)
<tjaalton> oh right, not NDIR:)
<tjaalton> lunchshlibs for libxi6
<tjaalton> whoops
<tjaalton> *lunch ->
<wgrant> Mmmm. lunchshlibs.
<wgrant> tjaalton: Still hardlocks... any idea how to debug this?
<Ng> how come we're blacklisting eaglelake?
<Ng> (that's G45/X4000, right?)
<tjaalton> Ng: no, something newer
<tjaalton> wgrant: could be that the evdev upload was incomplete, but can't check right now
<tjaalton> I'm at a seminar..
<Ng> (II) intel(0): VESA VBE OEM: Intel(r)Eaglelake Graphics Chip Accelerated VGA BIOS
<Ng> that's in my Xorg.0.log at home, which is a G45
<Ng> I have no idea what Intel codenames mean, I just remembered that from logs
<tjaalton> ok, bryce said it would be something experimental
<Ng> http://ark.intel.com/chipsetgroup.aspx?codeName=26554
<tjaalton> maybe a  newer revision
<Ng> well it's different to the PCI ID I have
<tjaalton> ok
<tjaalton> jcristau: is NIDR a part of the input-hotplug stuff that daniels wrote?
<jcristau> yeah. but it's not exported to drivers atm i think
<tjaalton> right, looked through the changelog.. magnus even did some fixes to it last year
<tjaalton> unfortunately he's the only one who seems to care about wacom with current servers. too bad he seems to be doing something else atm
<tjaalton> I mean, work or <gasp> real life
<bryce> tjaalton: what needs done for wacom?
<bryce> (heya btw)
<tjaalton> bryce: a lot, but it's upstreams headache
<bryce> probably needs rework due to input-hotplug-ness
<bryce> I wonder what that entails
<pwnguin> afaik, input hotplug has some work done on it
<pwnguin> its the serial devices like tabletPC that get the shaft
<bryce> pwnguin: any ideas on how those could be handled via i-h, or is it completely impossible?
<pwnguin> i-h is the hal stuff?
<pwnguin> my theory has been to detect the laptop model and set it up that way
<bryce> ah good call
<bryce> i-h != hal, but they do come together
<pwnguin> but i have no clue how to write .fdi rules for that
<bryce> or rather, i-h relies on hal
<bryce> ah, see http://wiki.ubuntu.com/X/Config for examples
<bryce> fdi files are pretty straightforward once you get the hang of them
<bryce> well, as straightforward as XML can be straightforward
<pwnguin> whats the difference between append and merge?
<tjaalton> wacom already has an fdi file, that's not the point
<bryce> well, I haven't seen a formal definition, but my guess is that append adds a new entry, and merge combines your new settings with any pre-existing settings already made
<tjaalton> to fully enable the device, you'd need to open it several times (pen/stylus/..) and that's not possible with hal
<tjaalton> so the driver needs to be reworked to use NewInputDeviceRequest
<tjaalton> the problem is that it's not exported to drivers as jcristau pointed out
<tjaalton> I'm not sure if master is any different
<jcristau> tjaalton: that should be easy to fix
<tjaalton> jcristau: well yes, but to make the driver use it?-)
<jcristau> well, hopefully not too hard
<tjaalton> whot said that -joystick has some hack to work around the current situation, but NIDR is the preferred way
<jcristau> but, i've never looked at linuxwacom code, so...
<tjaalton> jcristau: bug 276357, looks fine for debian as well?
<ubottu> Launchpad bug 276357 in xorg "disable xauth for local users" [High,Triaged] https://launchpad.net/bugs/276357
 * Ng sure there is deeper borkage to be found in changing your hostname, but I can't specifically name anything
<Ng> I'm just sure that NM shouldn't be doing insane things with my hostname just because I join a network :(
<jcristau> NM shouldn't change your hostname
<jcristau> that's utterly wrong and broken, imo
<tjaalton> but isn't xauth useless for local users?
<jcristau> why?
<Ng> tjaalton: run "xauth list" :)
<Ng> jcristau: I agree, but there are people who will be netbooting dozens/hundreds of identical images and setting the hostname from DHCP, which NM is likely to be doing from 0.7
<Ng> it really is growing into a full system-wide network interface configurator
<jcristau> it really has no business setting the hostname...
<bryce> tjaalton: ideas on lp #275825
<ubottu> Launchpad bug 275825 in xorg "X does not detect a keyboard after upgrade" [Undecided,New] https://launchpad.net/bugs/275825
<bryce> ?
<tjaalton> bryce: evdev not installed?
<tjaalton> maybe xserver-xorg-core should depend on it
<bryce> yeah
<tjaalton> jcristau: maybe I just don't see the point in it
<tjaalton> or dcbw for that matter ;)
<bryce> tjaalton: this is seen only on upgrades, not fresh installs.  My guess is maybe there was some old hal bits that omitted the x11 _driver?  See http://heh.fi/tmp/x-problem/x.log esp at the end
<tjaalton> I remember seeing a bug about this before, where the user changes the hostname from X
<tjaalton> um, "when X was running"
<bryce> tjaalton: -evdev is installed
<tjaalton> bryce: dunno, would have to look closer
<bryce> http://heh.fi/tmp/x-problem/lshal is the lshal output - note that input.xkb.model = 'evdev'
<tjaalton> but not driver
<bryce> right
<ion_> What's responsible for setting input.x11_driver?
<tjaalton> debian-setup-keyboard
<tjaalton> check /etc/hal/fdi/policy
<ion_> debian-setup-keyboard doesn't seem to set anything resembling input.x11_driver
<ion_> On another box that has been running intrepid for a while, input.x11_driver is correctly set.
<tjaalton> right
<tjaalton> it doesn't
<tjaalton> but /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi does
<tjaalton> older hal maybe?
<ion_> That file looks right. I'll take a better look.
<tjaalton> or you have some fdi files lying around that break it
<ion_> I just installed a fresh 8.04 and then ran do-dist-upgrade -blahblah
<ion_> And X didn't find HIDs.
<tjaalton> cool, a new background image
<tjaalton> ion_: heh.fi is down?
<tjaalton> hm no
<ion_> hald with --verbose=yes didn't seem to print anything interesting.
<tjaalton> ion_: I don't see any keyboards in the lshal output, btw..
<bdmurray> bryce: what does EDID quirk: Detailed timing is not preferred, use largest mode at 60Hz mean?
<ion_> tjaalton: How about the "AT Translated Set 2 keyboard"?
<tjaalton> ion_: oh, right :)
<bryce> bdmurray: that means a quirk is needed for working around monitor brokenness
<bryce> bdmurray: see http://wiki.ubuntu.com/X/Quirks
<tjaalton> ion_: still, 10-x11-input.fdi is not run
<tjaalton> or read
<ion_> So it seems. I wonder how to debug that?
<ion_> I'll strace hald.
<bdmurray> bryce: could the quirk be new between hardy and intrepid?
<bryce> bdmurray: basically it means that the edid from the monitor was saying "I like resolution foo", but that can't be trusted, so instead pick the highest resolution at 60Hz
<bryce> bdmurray: maybe; I'd need to check
<bdmurray> bryce: the quirks page doesn't say where to find the files with quirk information
<bryce> bdmurray: which info exactly do you need?
<jcristau> tjaalton: re: localuser.sh, it probably makes sense to add it. i guess i'd just like the NM people to stop being crazy...
<tjaalton> jcristau: yeah that's another story ;)
<bdmurray> bryce: I was jut looking at bug 273543 and saw that message in Xorg.log
<ubottu> Launchpad bug 273543 in xorg "Laptop external screen resolution wrong" [Undecided,New] https://launchpad.net/bugs/273543
<bdmurray> bryce: Additionally, it seems like if the wiki page tells people a file to check it'd be useful to know where that file can be found
<tjaalton> ion_: --verbose should show the order the fdi files are loaded
<bryce> bdmurray: ah, it does say a couple paragraphs above that, the file is in the file hw/xfree86/modes/xf86EdidModes.c, however I could see how that's missed.  I'll update.
<ion_> I renamed /var/cache/hald/fdi-cache away, it works now. According to strace, hald stat'd the x11 fdi file but never opened it.
<bdmurray> bryce: right, where can I look at that file?
<tjaalton> ion_: did you reboot?
<tjaalton> ion_: after the upgrade
<bryce> bdmurray: it's in the xorg-server package
<ion_> Yes
<tjaalton> ion_: bug pitti then, that cache should probably be removed at some point :)
<ion_> Perhaps hald's postinst should just rm it. :-)
<tjaalton> I'm not sure if it was from the hardy install or what
<tjaalton> but nice that you found out why it didn't work
<tjaalton> gone ->
<bdmurray> bryce: there's no bug number referenced for the quirk used...
<bryce> bdmurray: bummer
 * bryce looks at the bug again
<jcristau> seems like it's just different choices for initial configuration between the two xserver versions
<bryce> bdmurray:    /* Acer AL1706 */
<bryce>     if (memcmp (DDC->vendor.name, "ACR", 4) == 0 &&
<bryce>         DDC->vendor.prod_id == 44358)
<bryce>         return TRUE;
<bryce> (found by searching on the prod_id number)
<bdmurray> bryce: right I saw that, some them reference a bug number though and that one doesn't
<bryce> yeah, next to look in upstream's git log
<bryce> I always put in bug id's but not everyone does
<bryce> aha
<bryce> commit cc4eb1c7ea1bace7ed69cfd80c99d22933282ae1
<bryce> Author: Keith Packard <keithp@neko.keithp.com>
<bryce> Date:   Fri Apr 13 15:04:29 2007 -0300
<bryce>     Add quirk for Acer AL1706 monitor to force 60hz refresh.
<bryce>     
<bryce>     This Acer monitor reports support for 75hz refresh via EDID, and yet when
<bryce>     that rate is delivered, the monitor does not sync and reports out of range.
<bryce>     Use the existing 60hz quirk for this monitor.
<bryce>     (cherry picked from commit 1328a288e9030a472a915077160f090d1afd4126)
<bryce> bdmurray:  I don't think keithp works to a bug tracker - he just knows when X is bad or good
<bryce> bdmurray: is this giving you the info you're looking for?
<bryce> that quirk appears to have been in the codebase since before hardy
<bdmurray> bryce: yeah, I think so.  People could also use http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=tree to check for quirk info right?
<bryce> yes
<bryce> the one caveat is that there may be differences between that and what we actually ship in ubuntu
<bryce> I always grab the current source, then cd into it, run './debian/rules patch', and then look at the file
<bryce> that accounts for any quirk patches we are carrying
<bryce> bdmurray: oh also monitor quirk bugs like 273543 can be filed against xorg-server rather than xorg
<bdmurray> bryce: cool, I'm trying to work through the regression- tagged X bugs
<bryce> ah cool
<bryce> I'm making another pass through the -ati bugs today
<bdmurray> If you see any bugs tagged unnecessarily as regressions feel free to remove the tag
<bryce> ok
<bdmurray> tjaalton: bug 260589 might have the information you need now
<ubottu> Launchpad bug 260589 in xkeyboard-config "combining diacritics replaced by deadkeys" [Unknown,Confirmed] https://launchpad.net/bugs/260589
<Sonne> hi
<Sonne> do you think it is safe to backport xcb from intrepid to hardy?
<bryce> Sonne: probably; why do you ask?
<Sonne> because i want to use awesome3, and it requires newer xcb than the ones in hardy
<Sonne> i know xcb are part of xorg's "internals", but i don't know xorg infrastructure so much to be able to determine the risk of such an action :)
<Sonne> well i'll try, let's hope i don't break anything :)
<Sonne> aw... i just found out that even intrepid's xcb are not new enough..
<Sonne> i fear i will have to git
<bryce> good luck
<Sonne> any better ideas than git'ing lastest xcb-util, copying debian/, incrementing changelog and debuilding?
<Sonne> :P
<bryce> that ought to work
<bryce> you may need to rebuild libx11 as well
<Sonne> oh, there's no need to git, xcb 0.3.0 are out already as release
<Sonne> hrm
<Sonne> why's that?
<bryce> xcb replaces some of libx11's internals.
<bryce> but I don't know how it's all glued together internally
<Sonne> i know less than you, so wish me luck.. 
<jcristau> Sonne: xcb-util and libxcb aren't the same thing..
<Sonne> well they pertain to the same source package
<jcristau> no
<Sonne> http://packages.ubuntu.com/intrepid/libxcb-event0 <-- so it says here...
<Sonne> source is xcb-util
<bryce> Sonne: jcristau's right.  libxcb-event != libxcb
<Sonne> nice
<bryce> xcb-util is a wrapper atop libxcb
<Sonne> hrm
<bryce> maybe you'll need to upgrade both?
<Sonne> the package i'm trying to compile says it doesn't find xcb-{event,aux,atom,keysyms,icccm} and cairo-xcb
<Sonne> what should i do then?
<Sonne> except for the cairo thing, all seem to pertain to xcb-util
<Sonne> so xcb-util and libxcb seem to be separate projects.. maybe i don't need to backport both
<bryce> could be
<bryce> could you pastebin the full error log?
<Sonne> you mean cmake's?
<bryce> yeah
<Sonne> http://rafb.net/p/mMY4AQ88.html
<Sonne> actually it's no longer reproducible, i've tried luck and installed the backported xcb-util
<Sonne> now it's only complaining about cairo-xcb, i still have to figure out what the hell it's about
<Sonne> stating to google, only people that got to compile this thing made it on archlinux
<bryce> yeah there's probably also an xcb-enabled cairo package that it's looking for or something
<bryce> not in ubuntu; maybe available from the cairo website
<Sonne> maybe ubuntu's cairo already silently integrates xcb patch...
<Sonne> i'll take a look to debian/patches
<Sonne> nah, nothing
<Sonne> let's take a look at cairo's website
<jcristau> cairo in sid has the xcb backend enabled, at least
<jcristau> i'd guess intrepid also has that
<Sonne> hrm
<Sonne> xcb support is included in upstream cairo
<Sonne> but it's disabled via ./configure in debian/rules
<Sonne> so, a little 'enable' instead of 'disable' and a debuild should do the trick
<bryce> aha
<jcristau> not sure what old cairo package you're looking at then..
<Sonne> hardy's
<Sonne> cairo-1.6.0
<Sonne> should i backport that too from intrepid?
<jcristau> probably not
<Sonne> guess it's risky
<Sonne> or maybe not
<Sonne> on hardy's sources, xcb support is marked as "experimental"
<Sonne> maybe it's not on intrepid's
<Sonne> oh, on intrepid is still marked as experimental & unsupported, but it's enabled by default
<Sonne> there must be a reason i guess
<Sonne> well, intrepid's cairo requires too many libs from intrepid, i'll stick with 1.6
<jcristau> the reason it's enabled in the cairo package now is that awesome 3 needed it
<Sonne> but awesome3 isn't in intrepid either
<jcristau> right
<Sonne> is it being worked on?
<jcristau> but, ubuntu packages come from debian...
<jcristau> most of them anyway
<Sonne> on launchpad there's just a bug report suggesting to use debian/experimental's 
<Sonne> and people exchanging their opinions
<Sonne> no traces of "serious" work at first sight
<Sonne> meh, now i need libev, which require debhelper >=7...
<Sonne> i'm starting to no longer see the end of this
<Sonne> oh my, it compiles!
 * Sonne cheers
<Sonne> no, it doesn't
<Sonne> haha, now it does!
<Sonne> thanks jcristau and bryce :)
<bdmurray> bryce: bug 260341 seems really interesting
<ubottu> Launchpad bug 260341 in xserver-xorg-video-intel "[945G] wrong LCD resolution detected" [Undecided,Confirmed] https://launchpad.net/bugs/260341
#ubuntu-x 2008-10-01
<tjaalton>  /away
<tjaalton> uh
<jcristau> tjaalton: thinking about it, we could only do the xhost trick for local sessions (otherwise you're telling the x server to trust some random user). not sure it's worth it...
<jcristau> as in, you need to detect those somewhat reliably
<tjaalton> jcristau: running 'id -un' isn't enough?
<tjaalton> jcristau: that's what fedora does, allows only the session user to connect
<jcristau> in xinit it's ok, since that creates a local session anyway
<jcristau> but, if you put that in Xsession.d, you have to handle remote sessions, where `id -un` on the client may not have anything to do with uids on the server
<tjaalton> hmm, ok
<tjaalton> wgrant: I've now installed the packages from my PPA, and xinput list-props $id just gives me a BadRequest
<tjaalton> so something is broken in the backport
<jcristau> what's the request id?
<wgrant> tjaalton: Ergh.
<tjaalton> jcristau: Major 146, minor 41
<tjaalton> (XInputExtension)
<jcristau> hrm
<jcristau> #define X_WarpDevicePointer 41
<jcristau> that's XI2
<wgrant> Those were just renumbered in XI2...
<wgrant> But.
<wgrant> Hmm.
<wgrant> Hmmm.
<jcristau> did you update inputproto, then libxi, then xinput?
<tjaalton> I should have, but maybe some build-dep was broken so xinput was built against the old packages
<tjaalton> will check
<jcristau> 41 used to be GetDeviceProperty
<wgrant> Sounds like xinput was built before publishing.
<tjaalton> yeah
<tjaalton> grr
<tjaalton> hmm no, it was built against my versions
<wgrant> It's a bit odd that it hardlocks my laptop.
<jcristau> and libxi was built against the right inputproto?
<tjaalton> just listing the props?
<wgrant> tjaalton: Correct.
<tjaalton> jcristau: yes..
<tjaalton> I need to go through them once more..
<wgrant> Well, it did last night, but I've not changed anything since and daren't try again right now.
<james_w> tseliot: hi, are you around? I have a system with quite an old nvidia card and jockey doesn't suggest that I may want to install a different driver for it. How can I debug this?
<tseliot> james_w: what does jockey do, exactly?
<james_w> "No proprietary drivers are in use on this system"
<james_w> and nothing listed in the UI at all
<james_w> it's correct, but I thought it would show the chance to turn nvidia on
<jcristau> james_w: if it's an old card, then that may not be an option?
<james_w> it used to be nvidia, were some dropped in Intrepid?
<tseliot> james_w: can you put the output of "sudo aptitude search nvidia" in pastebin?
<tseliot> maybe some modalias packages are not available
<james_w> sure
<mvo> james_w: how did you upgrade?
<james_w> I don't remember now, it was very early
<mvo> I wonder if its driver -71 or -96 were we have no xserver 1.5 support ?
<mvo> james_w: aha, ok :) I'm looking for testing feedback of the current upgrader for people with nvidia hardware/drivers
<james_w> mvo: it's my second machine, so I'll consider reinstalling hardy and upgrading
<james_w> http://paste.ubuntu.com/52840/
<tseliot> james_w: nvidia-common wasn't installed during the dist-upgrade
<mvo> james_w: aha, ok. that system looks like a good test candidate
<tseliot> try installing nvidia-common and then launch jockey again
<tseliot> NOTE: don't try to install -71 or 96 (they don't work)
<mvo> haven't we blacklisted those yet?
<tseliot> mvo: no, not yet
<mvo> aha, ok
<tseliot> I have worked on the gnome-control-center
<james_w> nothing
<james_w> the same as before
<tseliot> james_w: can I see the output of this command? lspci -n | grep 300
<james_w> 02:00.0 0300: 10de:0201 (rev a3)
<tseliot> james_w: this is weird. Your card is supported: :/usr/share/jockey/modaliases$ grep 0201 *
<tseliot> nvidia-71:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-71
<tseliot> nvidia-96:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-96
<tseliot> did nvidia-common install other packages?
<james_w> nvidia-{71,96,173,177}-modaliases
<tseliot> e.g. nvidia-96-modaliases, nvidia-71-modaliases
<tseliot> ok, try killing jockey-backend
<tseliot> and start jockey again
<tseliot> ps aux should show jockey-backend
<james_w> aha!
<james_w> thanks
<james_w> but you say don't install 71 or 96?
<tseliot> ok, now don't install those drivers
<tseliot> they are not compatible with the new Xorg ABI
<james_w> are they likely to be fixed by the release?
<tseliot> therefore I didn't bother patching them to make them compatible with kernel 2.6.27
<tseliot> I have no idea...
<james_w> ok, thanks for your help
<tseliot> you're welcom
<tseliot> e
<bryce> whoa, jim gettys reported bug 276782 to launchpda
<ubottu> Launchpad bug 276782 in xserver-xorg-video-ati "X server crashes on rotation in xf86ResizeOffscreenLinear+0x3b" [Undecided,New] https://launchpad.net/bugs/276782
<Ng> heh, shouldn't he be fixing it too? ;)
<bryce> ;-)
<james_w> hey bryce.
<james_w> would you have a moment to look at bug 276680?
<ubottu> Launchpad bug 276680 in gnome-control-center "gnome-display-properties: "Detect Displays" does not work" [Undecided,New] https://launchpad.net/bugs/276680
<james_w> I'm not really sure which component is at fault here
<bryce> heya james_w, one sec, looking at a bug for heno atm
<james_w> sure, no rush
<jcristau> james_w: if he starts X with vga disconnected, the server doesn't allocate a framebuffer big enough for the vga monitor's native resolution
<james_w> jcristau: the "Virtual" setting?
<jcristau> yeah
<jcristau> his first xrandr output says 'maximum 1024 x 1024'; 1280x1024 doesn't fix
<jcristau> fit, even
<james_w> so the framebuffer allocated depends on what's plugged in when X starts?
<jcristau> yes
<jcristau> if there's no Virtual directive, anyway
<james_w> ok, so close the bug as Invalid and ask him to set a Virtual
<jcristau> well, it's still a bug that we can't resize the framebuffer
<jcristau> just not one that'll be fixed tomorrow
<james_w> thanks
<bryce> james_w: yeah if it's the virtual directive stuff, we surely have a bug open on that already; in any case it's an upstream issue
<bryce> tjaalton: btw, I've been cherrypicking some -ati patches from current git
<bryce> tjaalton: maybe it'd be better to just grab a new snapshot, but release team probably would prefer cherrypicks
<tjaalton> bryce: good.. upstream should learn how to release though ;)
<bryce> yeah...
<bryce> of course then I think I probably should volunteer to help with that...
<bryce> I'll be happy if they just apply one or two of my patches ;-)
<bryce> http://www.bryceharrington.org/ubuntu/Ati/
<tormod> bryce: it seems upstream leaves it all up to the distros to make a stable driver, which of course makes for duplicated work.
<tormod> one could say that upstream here is redhat though :)
<bryce> :-/
<tormod> maybe some people from a couple of distros should make a stable branch and cherry-pick things to it. it doesn't have to be Alex doing that.
<bryce> tormod: well in fairness the git tree for -ati currently looks mainly like bug fixes so far
<bryce> (although some of the changes in recent weeks are what's caused the bugs)
<bryce> hmm, you know, establishing a stable branch might not be a bad idea.
<tormod> currently yes, the problem is that you never know before afterwards :)
<tormod> if Alex likes the idea, he might be helpful in saying "this should go in stable", or "now the tree is stable, time to branch"
<tormod> he likes to think that master is always stable, but it's hard to convince release managers about that.
<bryce> yes, he's given that kind of advice for me previously (gutsy iirc)
<ion_> Btw, i was under the impression the reason for the ABI change that made some versions of fglrx incompatible with X in intrepid was because of MPX. Since intrepid doesnât have MPX, what caused the ABI change?
<tormod> just having a parallel branch almost like master would help to get things past the RM :) 
<tormod> 6.9.0.1 looks much better than 6.9.0+git20080925 :)
<bryce> agreed
<bryce> hmm, well too late really for intrepid in any case
<bryce> (probably...)
<bryce> likely a good practice for jaunty tho
<bryce> esp if we run into trouble with -fglrx again
<ion_> Probably, if the ABI change caused by MPX is yet to come. :-)
<bryce> ion_: I heard the X changes that broke -fglrx was the devprivates rework.  Dunno if that involves MPX or not
<bryce> afaik the MPX changes still lay in the future
<tormod> mpx changes came past 1.5 I think
<ion_> Alright, thanks
<Ng> tjaalton: do the brightness hotkeys on your thinkpad work?
<ion_> They do on mine, if thatâs relevant.
<jcristau> ion_: most important abi changes from 1.4 to 1.5 are devprivates rework, which was part of the selinux work, and also pci-rework
<jcristau> iirc
#ubuntu-x 2008-10-02
<pwnguin> ok, this is crazy
<pwnguin> https://bugs.launchpad.net/ubuntu/+source/thinkfinger/+bug/276850
<ubottu> Launchpad bug 276850 in thinkfinger "thinkfinger disabled mouse and keyboard in x" [Undecided,New] 
<bryce> jcristau: can you reproduce lp #276887 on debian?
<ubottu> Launchpad bug 276887 in xkeyboard-config "Input to TTYs goes to X after returning" [Critical,Confirmed] https://launchpad.net/bugs/276887
<jcristau> bryce: i get some 'fun' stuff on vt switch, but it seems to be mostly the alt-f7 release, not other stuff i type on the console
<jcristau> xev sees a keyrelease for XF86_Switch_VT_1, then keyrelease for control, alt, and f7
<jcristau> hrm.
<jcristau> bryce: actually it looks like i can reproduce
<bryce> jcristau: ahh
<ion_> Huh. On one intrepid box, multiple gdm logins work just fine. On another, only the first one receives input.
<jcristau> bryce: probably xserver bug. or maybe evdev driver. talk to whot, i guess?
<bryce> jcristau: kees was able to reproduce without evdev
<jcristau> ok
<jcristau> anyway, 2:30am here, and i need to be more awake than the students tomorrow morning, so, sleep :)
<bryce> night
<bryce> thanks
<jcristau> np
<wgrant> bryce: Do you know what a reasonable value for XRandR max brightness is?
<wgrant> g-p-m is trusting it a bit too much, I think.
<bryce> wgrant: nope
<jcristau> wgrant: very machine-dependent
<wgrant> I think that gpm_brightness_xrandr_output_set is on crack, then.
<wgrant> It seems to loop, incrementing it by one each iteration, presumably to get a gradual change.
<wgrant> But that doesn't work so well when it changes it to 15000.
<wgrant> (it also sleeps for 5ms each time)
<wgrant> I see that on another machine it's 7...
<wgrant> Do I complain at X, or do I complain at g-p-m?
<wgrant> 15125 doesn't sound like a particularly sane value for XRandR brightness.
<wgrant> jcristau: Do you think I should complain at X for giving me a bogus value, or should I complain at g-p-m for trusting it? Can X be expected to give a sane value in circumstances where the hardware doesn't support it?
<bryce> wgrant: you should probably raise it to g-p-m
<bryce> wgrant: since it sounds like xrandr is simply exposing hardware-provided values
<bryce> let me take a quick look at the source though
<wgrant> bryce: Dell backlights are controlled through other means.
<wgrant> g-p-m will stop if X says that it failed, but X doesn't.
<wgrant> Maybe g-p-m should be taught to not use more than 10 increments or something.
<bryce> wgrant: I see this is new code in 2.24 that wasn't in 2.22 apparently, so that leads me to think it's incorrect implementation in gnome
<wgrant> bryce: Right, I've looked through those bits of code fairly thoroughly.
<wgrant> It's probably fine unless X reports ridiculous values.
<bryce> ok, so it's using XRRChangeOutputProperty to set the brightness I gather
<wgrant> Yes.
<wgrant> On my machine we get something like this:
<wgrant> TI:11:04:06	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,322 - percent=50, absolute=7563
<wgrant> TI:11:04:06	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,324 - hard value=15125, min=0, max=15125
<bryce> and XRRQueryOutputProperty to retrieve them
<wgrant> Yep.
<bryce> so on the xrandr side, those are going to be fairly generic functions
<wgrant> And now we get:
<wgrant> TI:11:04:49	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,322 - percent=100, absolute=15125
<wgrant> TI:11:04:49	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,324 - hard value=7563, min=0, max=15125
<wgrant> So we have 7562 iterations.
<wgrant> Which is very slow.
<bryce> mm
<wgrant> And those values look like they come straight from X.
<wgrant> (from XRRQueryOutputProperty, at least)
<bryce> right, but I think gpm needs to be smarter at how it uses them
<bryce> I think the numbers are likely to be valid representations from the underlying hardware (I guess)
<wgrant> Right. It should probably limit the number of increments.
<wgrant> They don't apply to my hardware.
<wgrant> So it should really fail.
<wgrant> But it doesn't.
<bryce> I wonder if that shared_value_abs calculation is incorrect
<wgrant> I don't think so.
<wgrant> It's max/2.
<wgrant> And max is very large.
<bryce> what does this say? 
<bryce> $ xrandr --prop | grep -i light
<bryce> 	BACKLIGHT_CONTROL: kernel
<bryce> 	BACKLIGHT: 7 (0x00000007) range:  (0,7)
<wgrant> 	BACKLIGHT_CONTROL: combination
<wgrant> 	BACKLIGHT: 15125 (0x00003b15) range:  (0,15125)
<wgrant> As expected.
<bryce> okay
<bryce> wgrant: can you manually poke at it with xrandr --output <output> --set backlight <number>
<wgrant> X Error of failed request:  BadName (named color or font does not exist) Major opcode of failed request:  153 (RANDR) Minor opcode of failed request:  11 () Serial number of failed request:  18 Current serial number in output stream:  18
<wgrant> So maybe it does fail.
<bryce> wgrant: see if that 0,15125 is a smooth range, like if you poke 1000, 2000, ... 15000 does that give reasonable increments
<wgrant> bryce: It doesn't do anything - it's a Dell.
<wgrant> But if it fails, then g-p-m should break out of the loop. But it doesn't...
<bryce> ah, has to be BACKLIGHT, not backlight
<bryce> xrandr --output LVDS --set BACKLIGHT 3 dims my display
<wgrant> It works.
<wgrant> But does precisely nothing.
<bryce> $ xrandr --output LVDS --set BACKLIGHT 7 sets it to max
<wgrant> That's what I would expect.
<bryce> this fails:
<bryce> ~$ xrandr --output LVDS --set BACKLIGHT 8
<bryce> X Error of failed request:  BadValue (integer parameter out of range for operation)
<bryce>   Major opcode of failed request:  153 (RANDR)
<bryce>   Minor opcode of failed request:  13 ()
<bryce>   Value in failed request:  0x3c
<bryce>   Serial number of failed request:  19
<wgrant> But Dell does things specially (it's handled by hald-addon-dell-backlight
<bryce>   Current serial number in output stream:  20
<bryce> hmm, well mine is a dell inspiron 1420n
<wgrant> Right, it fails appropriately if I put it out of range.
<wgrant> Wait.
<wgrant> It just gradually went dark, I think.
<wgrant> It did this for a while in hardy.
<wgrant> Grrrr.
<wgrant> Indeed, it works, but very, very slowly.
<bryce> on a different dell with -ati I have backlight range (0,255)
<bryce> take it yours is intel graphics?
<wgrant> i915, yes.
<wgrant> Inspiron 630m.
<wgrant> Let's see if it goes dark again...
<bryce> interesting, on the ati system I can poke whatever I want into the backlight value but the backlight doesn't change
<wgrant> Right, this is similar to the behaviour I was seeing for a while in Hardy, without having to poke anywhere... if I set BACKLIGHT low, over a little under a minute it will get there.
<wgrant> If I set it high, it'll get there, but very slowly.
<bryce> bleah
<bryce> ok, well at least this sort of rules out g-p-m
<bryce> wgrant: why not report it to bugs.freedesktop.org against the xserver and see how it goes?
<wgrant> I believe I do really have 0->7.
<wgrant> That's what the brightness keys used to do, at least.
<wgrant> But they seem to largely be in hardware.
<wgrant> Although the OSD was right.
 * wgrant files it.
<bryce> fwiw, I notice in the xrandr manpage for properties that both decimal and hex values can be given
<bryce> however I sort of doubt this is a mixup between number systems.  Sounds like it's hardware giving bad data
<wgrant> bryce: Hmmm, it seems that g-p-m can't really be blamed for my other bug either.
<wgrant> There really are many thousands of brightness key events.
<wgrant> But there weren't in Hardy AFAICT.
<wgrant> THey just keep coming until I press another key...
<tjaalton> morning
<wgrant> Morning tjaalton.
<tjaalton> Ng: yes, work just fine
<tjaalton> hey wgrant
<tjaalton> our nurse is sick so I had to stay home.. probably can have a look at the properties stuff again some time today
<wgrant> I'd really like to know why it particularly dislikes me.
<bryce> heya tjaalton
<tjaalton> hey bryce, remember to push the patch to git too ;)
<bryce> oh feh
<bryce> er, which patch?
<tjaalton> evdev
<bryce> hm, didn't know evdev was in git
<tjaalton> yeah, probably so.. i haven't been too vocal about what packages are
<tjaalton> synaptics is too
<tjaalton> since we need stuff from master
<tjaalton> so it's easier to pull with git
<bryce> to be honest having things in git hasn't been that convenient for me
<bryce> admittedly it may just be due to me getting confused by git, but...
<tjaalton> hmm :)
<tjaalton> I probably should update the git docs in wiki
<Ng> tjaalton: huh, weird, my x61 owning chum says his aren't working at all
<tjaalton> Ng: ask him to try a livecd
<Ng> yeah good plan
<tjaalton> or a fresh user
<Ng> tjaalton: the same guy is also seeing http://gallery.casualgenius.com/corrupt_boot.jpg about 1 in 3 boots :o
<tjaalton> oh, still
<tjaalton> I don't anymore
<Ng> hmm, but you did?
<Ng> I think he's using some weird version of usplash. he's a bit of a magpie about downloading random crazy debs
<tjaalton> yes, I did, but not anymore with the current kernel
<Ng> interesting
<Ng> tjaalton: do you happen to know if there was a bug about it?
<tjaalton> Ng: I think so, but can't remember which one
<Ng> ok
#ubuntu-x 2008-10-03
<bdmurray> bryce: did you see bug 87661 was updated?
<ubottu> Launchpad bug 87661 in mesa "[apport] polytopes crashed with SIGILL in _mesa_x86_64_transform_points4_perspective()" [Medium,Fix released] https://launchpad.net/bugs/87661
<bryce> no, thanks.  
<bryce> I've re-upped -evdev
<bdmurray> it looks like its fixed upstream now
<bryce> yep
<bdmurray> bryce: did anybody ask about bug 277452?
<ubottu> Launchpad bug 277452 in xorg-server "Ubuntu 8.10 Beta won`t start" [High,Incomplete] https://launchpad.net/bugs/277452
<bryce> bdmurray: no not so far
<bryce> erf, log.rar??  /me dislikes it when people archive up their logs
<bdmurray> let alone a rar
<bdmurray> there's another nv bug that might be related but the pci id is different
<bryce> yeah and there's just a single file in it, so it's not even a workaround of lp's one-attachment-at-a-time issue
<bdmurray> bryce: they said alpha 6 worked for them though...
<bryce> hmm
<bryce> well I'm pretty sure we didn't rev -nv between alpha6 and now
<bdmurray> I've found another bug 277473, with pci id 10de:0531
<ubottu> Launchpad bug 277473 in xserver-xorg-video-nv "intrepid: couldn't start x server when using liveCD to run system directly and  intall (nvidia)" [Undecided,New] https://launchpad.net/bugs/277473
<bryce> hmm
<bryce> well, that's certainly true, but the error messages on both bugs indicate an unsupported chip.  odd
<bdmurray> I think there are a few more lying around too
<bryce> bdmurray: are they all the same chipset?
<bdmurray> no they are not exactly the same
<bryce> hmm, well -nv hasn't changed since July
<bdmurray> Yeah, I see that
<bdmurray> Is there a list of devices supported by a driver somewhere?
<bryce> yeah looking for that now
<bryce> it's in nv_driver.c
<bryce> ok, regarding bug #277452, which has 0x10de07e3, that''s not listed in nv_driver.c
<ubottu> Launchpad bug 277452 in xserver-xorg-video-nv "-nv doesn't support 0x10de07e3 (GeForce 7050/nForce 610i)" [High,Confirmed] https://launchpad.net/bugs/277452
<bryce> lemme look in git
<bryce> there's a 2.1.12 of the driver
<bryce> although 0x10de07e3 still is not listed
<bdmurray> hmm, is there just a lot of hardware that isn't supported yet?
<bryce> same thing with 277473
<bryce> probably
<bryce> -nv development is sloooowww
<bryce> so, bdmurray, basically you can just get either the pci id like 10de07e3, or the model name like 7150M, and do a grep -sir in the -nv source tree, and if nothing prints, then it's unsupported hardware
<bryce> 2.1.12 only adds one new supported chip
<bryce> +  { 0x10DE0640, "GeForce 9500 GT" },
<bryce> er wait
<bryce> my bad, there's a bunch actually
<bryce> http://pastebin.ubuntu.com/53566/
<bryce> bdmurray: if you spot bug reports for any of those, let me know and I can fix them
<bryce> for any other than that, we'll just have to suggest they use -vesa or -nvidia for now
<bdmurray> Should the Live CD fallback to -vesa?
<bryce> yeah I think so
<bdmurray> a lot of these are Live CD problems...
#ubuntu-x 2008-10-04
<bryce> if it's correct that it worked with alpha6 but not beta, then something is misfiring with how X is being set up.  hmm
<bryce> the 1.5.1 merge was sep 24
<bryce> timo put in a driver fallback patch sept 9, was that pre-alpha6 though?
<bryce> tjaalton: you around? ^^
<bryce> hmm, sept 9 was between alpha 5 and 6, so I don't think timo's patch would be to blame
<bryce> lemme look at what went into 1.5.1
<bryce> bdmurray: did you see any of the bugs where they posted an Xorg.0.log from their alpha6 session?
<bryce> I'm wondering if previously the livecd put them on -vesa
<tjaalton> bryce: there was a freeze exception for this
<tjaalton> bryce: but it didn't get in for beta
<bryce> tjaalton: oh you know of the fix?
<tjaalton> bryce: it's committed alread
<tjaalton> y
<bryce> ah okay, what was the change?
<tjaalton> jcristau knows more about it.. brown paper bag stuff :)
<bryce> was it a fix to xorg-server or -nv or...?
<tjaalton> the .ids -stuff didn't work like before
<tjaalton> xorg-server
<bryce> ahh
<tjaalton> got to hit the hay, so.. have a nice weekend :)
<bdmurray> I'm not sure I'm following everything, X is broken for some Live CD users with Beta?
<bryce> ok, night
<bryce> bdmurray: in the past, debian/ubuntu had it's own mechanism for mapping driver to pci id's
<bryce> bdmurray: but with xserver 1.5, they've added code in the core system for doing this now
<bryce> so debian has switched over to this new system, and apparently in doing so there was an issue that made it behave somewhat differently than the old system
<jcristau> not quite
<jcristau> when gravity's code went upstream, it was modified to look in some #defined location instead of hardcoded /usr/share/xserver-xorg/pci/
<jcristau> except we didn't define it, so it didn't look anywhere at all
<jcristau> bryce: btw look at NVIsSupported, it matches on id & 0xfff0, so it works on more cards than are explicitly listed
<bryce> jcristau: hm, what was I not quite right about?
<jcristau> that we switched to a new system
<jcristau> it's the same system, just in the upstream tarball instead of debian/patches/ :)
<bryce> bdmurray: anyway, so looks like that issue is what's causing the different detection behavior with the livecds
<bryce> bdmurray: guess we'll be getting a lot of bug reports on this one
<bdmurray> bryce: maybe we should get it added to the caveats then?
<bryce> bdmurray: yeah
<bryce> bdmurray: 261977 seems to be the master bug for this
<bdmurray> bryce: so I'll mark bug 277452 as a dupe of 261977 and any others I find. sound good?
<ubottu> Launchpad bug 277452 in xserver-xorg-video-nv "-nv doesn't support 0x10de07e3 (GeForce 7050/nForce 610i)" [High,Confirmed] https://launchpad.net/bugs/277452
<bryce> bdmurray: sounds very good
<bryce> thanks for doing that
<bryce> I'm working on a new git snapshot for -ati which should close a slew of bugs
<bdmurray> bryce: yep, I might mail the bug squad too
<wgrant> bryce: Are you aware of the -synaptics config GUI in System->Preferences-Mouse?
<bryce> wgrant: yeah
<bryce> wgrant: not familiar with the internals tho
<wgrant> bryce: Just wondering why you advised LaserJock to write a fdi file for the config options exposed there.
<bryce> wgrant: wasn't aware that synaptics was special cased
<wgrant> bryce: Ah. Well, it turns out all of the options that he needed were exposed there.
<bryce> great
<bryce> mjg59 had written the synaptics gui earlier, but I didn't know it worked with input hotplug
<wgrant> bryce: I ported it to XInput properties a couple of months ago.
<wgrant> I believe we've even dropped the awful hack from -synaptics.
<bryce> ok good, didn't know that
<wgrant> LaserJock points out that we really need to fix up docs, as lots are broken by input-hotplug... I'm trying to update various Synaptics-related ones now.
<wgrant> I wonder if I can get a UI freeze exception to add a couple of extra often wanted options to the GUI (two-finger scrolling).
<bryce> worth a try
<wgrant> Is that an ubuntu-release question, or some docteam?
<bryce> hmm, I'm not sure who officially approves UI freeze exceptions, but I'd probably start by asking slangasek
<wgrant> I just did. Thanks.
<bryce> jcristau, tjaalton: how's -nouveau coming along in your opinion?  something we should look at for intrepid?
<bryce> ok, sync'd it from experimental
<tjaalton> bryce: haven't tried for a while, but it needs a snapshot of libdrm to be useful
<tjaalton> *in a while..
<jcristau> bryce, tjaalton: not just libdrm, nouveau needs drm modules from git
<tjaalton> oh that too
<tseliot> tjaalton: I'm thinking of removing (i.e. not including) nvidia-xconfig in the nvidia packages. This would fix https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/248327
<ubottu> Launchpad bug 248327 in nvidia-graphics-drivers-177 "Broken X if nvidia-xconfig is used" [Low,Confirmed] 
<tseliot> I'm also working on this (a FFE will be required for a new upstream release): https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/274866
<ubottu> Launchpad bug 274866 in nvidia-settings "nvidia-settings creates invalid xorg.conf" [Medium,Confirmed] 
<tseliot> tjaalton: what do you think about the problem with nvidia-xconfig?
<tjaalton> tseliot: if there's no source for -xconfig, then dropping it might be wise
<tseliot> tjaalton: the source is not in the nvidia installer. There is only a binary "nvidia-xconfig"
<tjaalton> tseliot: ok, but the -settings one should be fixable?
<tseliot> tjaalton: yes, I have packaged a new release
<tseliot> which solves the problem (at least the changes in code seem to suggest that the problem is solved)
<superm1> tjaalton, tseliot and i were talking about the repercussions of removing nvidia-xconfig.  there are some projects that use it still (but not explicitly in rdepends), so I proposed a compatibility shim instead 
<superm1> that uses xkit to turn on the driver
<superm1> at least basic functionality - not reimplementing "all" of nvidia-xconfig
<tseliot> tjaalton: we should add a dependency on python-xkit (which is in main) and install a script named nvidia-xconfig to /usr/bin which enables the nvidia driver
<mnemo> does the x.org intel driver use a frame buffer by default?
<tjaalton> superm1, tseliot: ok, sounds like a plan
<tseliot> ok
<tseliot> I'll work on it
<mnemo> if I disable DRI for the intel driver, am I still using the code from the drm and mesa repositories listed here: http://www.intellinuxgraphics.org/download.html
<mnemo> ??
<tjaalton> mnemo: no
<crevette> hello
<crevette> is an ubuntu repository for intel driver snapshots?
<tjaalton> crevette: not that I know of
<crevette> hello tjaalton
<mnemo> tjaalton: so if DRI is disabled and I dont have the "drm" kernel module loaded... how does the xserver communicate with the graphics card?
<tjaalton> mnemo: um, with the intel DDX driver?
<mnemo> tjaalton: so basically the xserver is sending data directly to the graphics card then?
<jcristau> well, yes, that's what a driver does..
<mnemo> I got a crash on intel G45 hardware with DRI off and EXA (no compiz) and this is my xorg.log --> http://rafb.net/p/RVwNLB13.html
<mnemo> so can I be sure that this bug is in the 2D xorg driver for intel? i.e. the xserver-xorg-video-intel code??
<jcristau> pretty much
<tjaalton> AIUI even the 2.5 prereleases still have bugs with G45
<mnemo> yes I tried git head as well, same bug
<mnemo> im trying to analyze it though so I can file a usable bug report
<tjaalton> you should probably file it upstream too
<mnemo> yup
<tjaalton> thanks :)
<mnemo> from the xorg log it seems that the ring buffer (used for sending commands to the GPU) becomes full and the intel driver loaded into xorg waits for 2 seconds and then it assumes something it wrong because the ring buffer is not being emptied/processed
<mnemo> the code refers to this buffer as an "LP" buffer, do you know what LP means in this context?
<mnemo> I tried to read the intel docs but "LP" is not mentioned in there
<tjaalton> no idea
#ubuntu-x 2008-10-05
<pwnguin> printer?
<pwnguin> old printer ports used to be referred to as LP ports, i donno how they're structured but a ring buffer seems possible
<pwnguin> http://elonen.iki.fi/code/misc-notes/ringbuffer/
<pwnguin> how about load pointer and consume pointer
<wgrant> There are reports on ubuntuforums that vboxvideo isn't used automatically.
#ubuntu-x 2009-09-28
<tjaalton> looks like the DPMS issues should be solved by pulling c1d901d723 to the server
<tjaalton> lool: do you have something for the xorg-server git?
<lool> tjaalton: Yes but needed bryce to push first
<tjaalton> he did that already
<lool> Ah cool let me rebase and puhs
<tjaalton> ok
<lool> tjaalton: Pushed
<lool> ah no
<lool> now it's pushed
<lool> ce13d12..80a6590
<lool> tjaalton: I shall build, test, and upload it now
<lool> tjaalton: We don't do ubuntu tags right?
<tjaalton> lool: nope
<tjaalton> lool: hah, I was about to add the same :)
<tjaalton> the same patch I mean
<lool> tjaalton: Well I had commented on bug report that I had it ready to avoid duplication   :-)
<tjaalton> lool: I was following the wrong bug then :)
<jcristau> isn't that patch in 1.6.4?
<lool> jcristau: Apparently we're still at 1.6.3
<lool> 1.6.4 might make it post beta, but I wouldn't want to pick up a new upstream today myself; perhaps bryce or tjaalton can though
<lool> tjaalton: Built, tested, debdiffed, uploaded
<lool> So I'm logging in with startx
<lool> And on the second login I don't have keyboard or mouse
<jcristau> i think i've seen that, too
<lool> i.e. my system boots, gdm starts, I can move the mouse, I stop gdm and startx, I can use mouse and keyboard, I logout, startx, and then I'm stuck
<lool> the system is working fine though
<jcristau> confirmed it's in 1.6.4, fwiw.  you'll probably want to update to that before release, as it's all bugfixes
<diverse_izzue> tormod, could you also observe gtkperf differences between KMS and non-KMS on ATI as discussed a few days ago?
<tormod> diverse_izzue: yes, I made the wiki page
<diverse_izzue> link?
<tormod> https://wiki.ubuntu.com/X/RadeonKMS
<diverse_izzue> brilliant, i'll add my values when i get around doing that
<tormod> you can see my gtkperf numbers are not so different on DRI/DRI2, but the broken glblur is bad
<diverse_izzue> yeah. for me it's really perceived speed which is lacking - the system is no fun to work with under KMS
<diverse_izzue> did you fullscreen the glblur?
<tormod> no I didn't
<diverse_izzue> are the upstream people hanging out on some channel?
<tormod> upstream radeon is on #radeon of course :)
<diverse_izzue> have you bothered them with that issue already?
<tormod> diverse_izzue: which issue in particular?
<lool> jcristau: The IDLETIME/DPMS change is in 1.6.4 you mean?
 * lool filed LP #438044 about the no kbd+mouse issue
<ubottu> Launchpad bug 438044 in xorg "No keyboard and mouse on second startx login" [Undecided,New] https://launchpad.net/bugs/438044
<jcristau> lool: yeah
<jcristau> all logs in https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/438044 show the devices being added.  which one corresponds to the bug?
<ubottu> Launchpad bug 438044 in xorg "No keyboard and mouse on second startx login" [Undecided,New]
<diverse_izzue> tormod, the reduction in drawing speed, especially the gtkperf result
<Ng> sweet, DisplayPort is full of JustWork goodness \o/
<tzanger> good afternoon
<tzanger> the most recent x-swat intel driver seems to die on resume from sleep (suspend to ram) - I'm just curious whether the updates in the edgers ppa has corrected that or not? is there a changelog somewhere I can query instead of bugging people here?
<bryce_> tzanger, git log
<bryce_> tzanger, and honestly if you're still running the xswat git snapshot rather than what we're shipping in karmic, you should be bugging folks on #intel-gfx, not here.
<tzanger> ahh, okay, I wasn't sure where to go
<tzanger> I'm running 9.04 so I didn't think it'd be prudent to try and run drivers from a newer release
<Company> what's the preferred way to do synaptics config in karmic?
<Company> xorg.conf? hal? something else?
<tzanger> hmm, the #intel-gfx people suggest I check to make sure the GPU's not being posted on resume, but when I asked how one goes about checking that and preventing it if so, he suggested asking ubuntu-people, so I'm asking here...
<tormod> tzanger, try: grep vbe-post /var/log/pm-suspend.log
<tzanger> hmm, I have a vbetool but not a vbe-post, is there a special package for that
<tzanger> hmm the log is just a text file concatenating a few sources that look like they came from /proc, is that expected?
<tzanger> nevermind I missed your grep command
<tzanger> no sign of vbe-post in the log file
#ubuntu-x 2009-09-29
<tzanger> I'm trying to debug an X crash on resume with 2.6.31 on 9.04 (intel 2.7.1 driver on a GM or GL960) -- VBE is not posting on resume (checked pm-suspend.log) but not sure where to go from here. suspend is fine, as sometimes when I resume it takes a few seconds for X to die and I can see y screen as it was when I suspended
 * Ng wishes X would refuse to let me move my mouse pointer into areas of the virtual display which aren't part of a physical display
<Ng> but I suspect that all falls down for weird setups where there is a gap between physical displays :(
<virtuald> will radeon get default modesetting? i haven't seen any problems with it but you might know more. 
<tseliot> virtuald: not in karmic
<Kano> hi, did anybody run top on a live image?
<Kano> i have got 100% load with nvidia gfx card and 32 bit intel
<Kano> for one core with Xorg
<Kano> that kills vt switching too
<Kano> anybody else with that problem?
<tseliot> Kano: with nvidia or nv?
<tzanger> I'm trying to debug an X crash on resume with 2.6.31 on 9.04 (intel 2.7.1 driver on a GM or GL960) -- VBE is not posting on resume (checked pm-suspend.log) but not sure where to go from here. suspend is fine, as sometimes when I resume it takes a few seconds for X to die and I can see y screen as it was when I suspended
<tseliot> tzanger: is this with KMS enabled?
<tzanger> what's KMS?
<tzanger> kernel mode selection?
<tseliot> kernel mode settings
<tzanger> I don't think so
<Kano> tseliot: nv, nvidia binary is fine
<tzanger> how may I check it?
<tseliot> tzanger: can you reproduce the problem in Karmic?
<tzanger> tseliot: haven't tried, I would prefer not to do a dist-upgrade and end up with the same issue
<tseliot> Kano: can I see your /var/log/Xorg.0.log?
<tjaalton> tzanger: that's why we have livecd's
<tseliot> tzanger: suspend/resume is extremely fast with KMS
<tzanger> tjaalton: good point; I never woul dhave thought to try suspend with a live cd
<tzanger> tseliot: hmm, it's not extremely fast... several (5-6) seconds
<tseliot> tzanger: it's very fast on my netbook with KMS on Karmic
<tjaalton> jaunty didn't have intel kms
 * tseliot nods
<Kano> tjaalton: why has your paste.u.c no upload feature?
<jcristau> why do you think #ubuntu-x has anything to do with it?
<Kano> tjaalton: the intel onboard system: http://paste.debian.net/47753
<Kano> you get the failed entries when you try vt switch
<Kano> tseliot: thats nvidia: http://paste.ubuntu.com/281287/
<Kano> nfsboot
<tjaalton> haven't seen that
<tseliot> Kano: maybe it's worth seeing dmesg too
<Kano> nothing special in dmesg
<Kano> no permanent errors or so
<Kano> ps aux |grep bin/X is more interesting
<Kano> http://paste.debian.net/47755
<Kano> do you see the line with 99.5
<Kano> thats the same on both
 * tseliot has a look
<Kano> root      1943 99.5  0.8  68608 21972 ?        Rs   12:38  41:43 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-v2qsYS/database -nolisten tcp vt7
<Kano> thats a bit extreme
<jcristau> attach gdb, see where it's spinning?
<Kano> how to do so?
<tseliot> https://wiki.ubuntu.com/X/Backtracing
<Kano> well x is still running, it is not crashed
<jcristau> Kano: ssh, gdb -p $(pidof X), bt
<Kano> http://paste.debian.net/47756/
<Kano> anything else?
<jcristau> do that a few times
<Kano> always the same
<jcristau> ok.
<Kano> well not when i quit gdb
<Kano> then i get something else some times
<jcristau> ah.
<Kano> http://paste.debian.net/47757/
<Kano> http://paste.debian.net/47758/
<Kano> is that wait for something busy wait?
<jcristau> no, it's the loop around select()
<Kano> well a loop without wait will result in 100% load
<jcristau> you know what select() is, right?
<Kano> no ;)
<Kano> but i see the load, not on your system?
<Kano> interestingly with intel onboard 64 bit it does not happen
<Kano> with nv there is no diff
<tseliot> freedesktop-bugs #22893
<ubottu> Launchpad bug 22893 in screem "Screem hangs when editing php file." [Medium,Invalid] https://launchpad.net/bugs/22893
<tormod> for those not on the ML: https://lists.ubuntu.com/archives/ubuntu-x/2009-September/000630.html
<bryce> tormod, thanks
<bryce> tormod, yeah alberto mentioned 2.9.0 to me too
<bryce> once I'm back from leave I'll add them in.  I figure since we're close to beta release, we ought to wait until post-beta-freeze anyway
<bryce> we may need a FFe for -intel
<tormod> seems like upstream makes releases now in the hope of getting them into the coming distro releases, so it would be a pity not to...
<tormod> yes karmic is really frozen for beta now
<bryce> there's also new libdrm and xorg-server 1.6.4 that could be worth pulling
<tormod> hold on a bit for 1.6.4 , there are dga issues
<jcristau> 1.6.4 is broken
<bryce> ah, shame
<albert23> Didn't the desktop meeting decide not to update?
<jcristau> but, should be fixed soon
<albert23> rickspencer3so we are agreed, the karmic X stack today is the Karmic X stack we will ship with, modulo any blockers found by users in the beta?
<bryce> oh heh
<tormod> bryce, are you in the desktop meetings?
<bryce> yeah I've been on leave so am not up to speed on decisions made at recent meetings
<albert23> this was today
<bryce> s/I've been on leave/I am on leave until the 1st/
<tormod> are there any X people in this desktop meetings?
<albert23> Today was tseliot
<bryce> right
<jcristau> well i think it'd make sense to update at least the server from the stable branch, and mesa from a random snapshot to the release :)
<tormod> +1
<bryce> is libdrm 2.4.14 safe/worthwhile?
<tormod> seems safe
<tormod> some chipsets added for intel, some 64-bit fix for radeon, and a memory leak
<tormod> bryce, in any case, the 2.4.14 in xorg-edgers should be a pretty clean package
<bryce> ok
<bryce> I talked to jbarnes last week and he advocates -intel 2.9.0... says it's mostly bug fixes.  There's been some 8xx fixes upstream that I'd really like to see included in Karmic
<bryce> but I'll have to check with Rick as per today's meeting
<albert23> For 865 you would also need a kernel fix from 2.6.32 (agp/intel: Fix the pre-9xx chipset flush.)
<bryce> albert23, ah good to know - can you file a bug about that and subscribe me to it?  I'll follow up and make sure it gets in.
<albert23> it's bug 407793
<ubottu> Launchpad bug 407793 in xserver-xorg-video-intel "[i865g][Karmic Alpha 3] X corruption and freeze when clicking "Other" on GDM login screen" [High,Triaged] https://launchpad.net/bugs/407793
<bryce> ok thanks
<albert23> Did you register your son on LP?
<bryce> yep
<tormod> bryce, congratulations with your "release" by the way :)
<bryce> :-) thanks
<RAOF> Congratulations!
<bryce> albert23, ok I stuck it on the kernel team's todo list.  Likely should be pulled now, but let me know if it looks stuck or something
<albert23> thanks
#ubuntu-x 2009-09-30
<bryce> hm, ok rick says no further X updates except cherrypicking
<tormod> I could not find any desktop meeting in #ubuntu-meeting logs?
<albert23> tormod: http://irclogs.ubuntu.com/2009/09/29/%23ubuntu-desktop.html starting at 17:42
<tormod> albert23, thanks
<bryce> tormod, they're usually held on #ubuntu-desktop
<tormod> what is the x-testers PPA 
<tormod> hm I would have been interested in hanging around at that meeting. I though the Desktop team were fixing gnome bugs, not deciding the X stuff :)
<tormod> I wonder if tseliot knows about xorg-edgers and x-updates PPA?
<bryce> I don't think there is an x-testers ppa..
<bryce> he should know about xorg-edgers.  dunno if he knows he should be pushing stuff to it
<bryce> hrm, I kind of wish we were a bit more caught up with all this stuff... guess its my bad for being offline the past month
<tormod> It seems like none of the people in that meeting is on the ubuntu-x ML for instance, that is a structural problem and not your fault for having a leave
<tormod> <tseliot>	and this is why I think they should live in a PPA at first
<tormod> <pitti>	tseliot: are these in the x-testers PPA? I'd love to try them and see whether they fix suspend/resume
<bryce> ah, yeah he must mean xorg-edgers
<tormod> <tseliot>	pitti: not yet, sorry, I think I'll work on it (I've been busy with oem stuff)
<tormod> I feel we are a bit disconnected here
<tormod> (my remark, not a quote that last one)
<bryce> I sense I'm going to have a lot of patch porting work in my near future
<tormod> for commit in $(git log); do cherry-pick $commit; done :)
<tormod> I think I will leave the bug triaging and debugging to the Desktop team :)
<seb128> weird comment
<bryce> I think he just means the amount of work required to backport and test all the patches needed is well beyond what the X team can do alone
<bryce> I suspect he may be right, although I've not really investigated
<bryce> but yeah, I had been anticipating that we'd pull all these fixes as updates, so I could spend the last couple weeks working on xserver crashers instead
<seb128> well, we did pull a new version to fix issues previous cycle
<seb128> and we got jaunty without compiz on some intel card to workaround the issues we didn't manage to track
<seb128> so we are rather careful about updates this time
<bryce> seb128, actually no, in Jaunty we opted *not* to pull new versions to fix the issues
<seb128> ok
<bryce> seb128, perhaps you don't recall, but we opted to stay with the -intel 2.5 instead of 2.6 which was released, and instead I spent much time doing cherrypicking
<seb128> in any case non trivial updates are always risky
<seb128> I though the locking issues on intel did start after some update
<seb128> but it has been a while ;-)
<seb128> in any case I'm not the one who decided
<bryce> it was ironic all the fixes we needed for Jaunty were released (mostly in kernel code)
<bryce> we just didn't have time to cherrypick everything we needed
<bryce> seb128, the locking issues first started being reported at UDS berlin, very early on.  Just most people didn't notice them right away because they hadn't upgraded yet.
<seb128> anyway let's not discuss jaunty now
<seb128> dunno if you read the meeting log
<seb128> but there was no strong argument in favor of doing the non trivial update
<seb128> and people felt it's late in the cycle to try that many changes
<seb128> but whoever has good argument can probably argue with pitti and rick
<bryce> seb128, I did look at the meeting log; it didn't appear that anyone had any tangible concerns, just generic worry
<bryce> "fix all the bugs, and btw please don't change anything while you do it."  ;-)
<seb128> bryce, no, it was rather "do we have a good reason to throw that many changes in now"
<seb128> bryce, and "do we feel we can test that properly and act if things break before karmic"
<seb128> and there was no real reply to the first question
<bryce> seb128, the replies I see are, a) "Fixes bunch of regressions on 8xx", b) "fixes backlight breakage", c) "FFe's have been filed and approved"
<bryce> seb128, anyway it'll be embarrassing to release without this stuff in, but really it's my fault for having taken time off
<seb128> you can't say it's your fault, it's rather the team fault to not have taken on your tasks while you were on leave
<seb128> but argue with rick or pitti if you think we should really do the update
<seb128> the rational was that after beta is late for that number of change
<seb128> and that cherrypicking might be less risky
<seb128> we are sort of sitting between a rock and an hard place now
<seb128> anyway I'm not really the guy to talk with about those
<seb128> I was just relying the meeting conversation
<seb128> it's probably a good idea to talk to pitti tomorrow
<tjaalton> bryce: the intel "2009Q3" release consists of all these new releases, so yes, I'm in favour of updating to the current stable stack
<tjaalton> and I've been slacking with wacom.. should've uploaded it last week
<tjaalton> but, stuff..
<bryce> yeah, me too
<bryce> but however I think we're now too late to update X components any further
<bryce> it appears the desktop team semi-firmly decided not to allow updates
<tjaalton> hrm
<tjaalton> ooh, "xf86-input-wacom now available"
<tjaalton> but surelyn not for karmic :)
<tjaalton> -n
<bryce> hey btw at XDC they got a consensus around merging the DDX drivers back into the xserver codebase
<tjaalton> haha :)
<bryce> so if you were worried things were going to get boring for us X packagers, none to worry!
<tjaalton> yeah the notes suggested so
<tjaalton> well, it should make things somewhat simpler too, I hope
<tjaalton> at least the amount upstream regressions should go down
<bryce> of course so much has moved into the kernel now
<tjaalton> yep
<bryce> btw, how'd your rowing team do?
<tjaalton> hehe
<tjaalton> there were ~115 teams, and we finished as 103rd or so :)
<bryce> !!
<bryce> well, hey you finished, that's way better than most of us could do!
<tjaalton> but it took 30min less than the last time (6h15min)
<pwnguin> thats a long row
<tjaalton> yep, 58km
<tjaalton> http://www.sulkavanvene.fi/kuvat/sulkavansoutu1.jpg
<bryce> wow
<tjaalton> so the hardest thing was to stay in sync
<bryce> bet it takes a lot of practice
<tjaalton> and holding a steady pace
<pwnguin> bet it takes a lot more willpower
<tjaalton> yeah, once in every second year doesn't quite cut it :)
<tjaalton> after we finished no-one was willing to go next year, but when got to the sauna & barbeque -phase opinions had changed ;)
<pwnguin> if you're tired im guessing the guy behind you might not be and still wants to win
<tjaalton> we took short breaks a pair at a time (there were seven pairs and the cap'n)
<tjaalton> http://www.vastavalo.fi/albums/userpics/11563/DSCN0116p.jpg
<tjaalton> that's a better picture
<tjaalton> but yeah, a sore butt and hands full of blisters cannot be avoided ;)
<bryce> ah no gloves?
<tjaalton> and tape, but still
<bryce> ah heh looks like there was no guy behind timo!
<tjaalton> haha
<tjaalton> that's not from our team, just some pic I found
<tjaalton> (they were mostly ladies anyway.. sometimes I felt the same about our team though=
<bryce> the boats do sort of resemble viking longboats
<tjaalton> yeah
<tjaalton> we call them "church boats"
<tjaalton> because families used to go to the church etc with similar boats
<bryce> can they go in the open oceans or just fjords?
<pwnguin> anything can go in the oceans, its a matter of what comes back
<tjaalton> heh
<bryce> lol\
<pwnguin> i doubt you could row your way back against an ocean current
<tjaalton> in lakes only (we don't have fjords :). there were some annoying spectators going round us on muscleboats, and the waves weren't nice to handle
<tjaalton> because some rows would not reach the water so the pace broke
<bryce> tjaalton, since lucid is going to be an LTS, and since the 1.7 release sounds like it was pretty shaky, and the 1.8 plans outlined at XDC sound a tad ambitious, I'm wondering that it may be wisest for us to stick with a 1.6.x xserver
<tjaalton> bryce: hmm, I think debian squeeze will aim for 1.7, so wouldn't it make sense to follow them and benefit from it?
<tjaalton> rc3 is in experimental
<bryce> well, it could be.  I've been on the fence on it.  My gut says not having MPX in the LTS would be shortsighted.  However so far XDC has not been filling me with confidence about 1.7
<tjaalton> also it seems like rhel6 will ship it
<tjaalton> but, maybe wait a month and think about it when lucid opens?-)
<bryce> couldn't hurt
<tjaalton> has there been any talk about 1.8 release schedule?
<bryce> yes there was
<tjaalton> fd.o is still down, so no notes available
<bryce> the discussion was to go to more of a routine, regular release schedule, tied to the GNOME development cycle
<tjaalton> nice
<tjaalton> but
<bryce> so every 6 months, shortly prior to GNOME's releases
<tjaalton> it's usually too late for our cycle?
<bryce> yes, that's something I'm a little concerned about
<bryce> but I don't know that we have a whole lot of pull ;-)
<tjaalton> unless the release management is improved like whot suggested
<bryce> right that also got a lot of talk
<tjaalton> meaning less regressions
<tjaalton> less chance of..
<bryce> there was rough consensus around changing things like whot's suggestions, and go with a stricter control over main in a more Linus-like fashion
<pwnguin> probably, you want to give them some practice at this regular release thing before trusting them on it ;)
<bryce> where in this case Keith (or Peter) would be the Linus
<bryce> pwnguin, indeed
<pwnguin> when did gnome start doing regular releases? 2003?
<bryce> dunno
<tjaalton> when 2.0 was released, I guess
<pwnguin> so way earlier
<pwnguin> before ubuntu, lets say
<tjaalton> actually no, 2.0 was june 2002, 2.2 was feb 2003
<tjaalton> so after that
<bryce> this was all stuff discussed on XDC day 1; I didn't actually go in today... baby kept us up too much last night and I needed to spell my wife for the day.  but I'll be going back tomorrow
<tjaalton> oh, congrats!
<bryce> http://outflux.net/~bryce/arr_baby.jpg
<tjaalton> maybe I shouldn't be telling this, but our baby has been a good sleeper so far ;)
<tjaalton> yarr!
<Ng> bryce: we might not have a lot of developer pull, but they might want to remember that if they care about desktops they really need to care about ubuntu ;)
<Ng> but even if they release slightly before gnome that means we get an x server release about 2 months before each development cycle starts, so we have over 6 months to stabilise it :)
<jcristau> Ng: i'm not sure why redhat should have to care about ubuntu tbh.
<Ng> jcristau: that depends how honest they are about being upstream :)
<Ng> if you're genuinely an upstream you care about your users
<Ng> if you're not then that's fine :)
<tjaalton> we'll see what happens with rhel6
<mnemo> bryce: I attached dmesg, xorglog to bug 438657 (so maybe you'd want to change it from INCOMPLETE and remove  needs-lspci-vvnn  needs-xorglog
<mnemo> ) https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/438657
<ubottu> Launchpad bug 438657 in mesa "[G45] Blender: crash in brw_prepare_vertices after "Render this window"" [Unknown,Confirmed] https://launchpad.net/bugs/438657
<ubottu> Launchpad bug 438657 in mesa "[G45] Blender: crash in brw_prepare_vertices after "Render this window"" [Unknown,Confirmed]
<virtuald> ive got a 70 MB syslog with lots of messages like [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! [drm:r100_cs_packet_parse_vline] *ERROR* unknown crtc reloc [drm:r300_packet0_check] *ERROR* No reloc for ib[25]=0x6538 [drm] ib[24]=0x0000194E
<virtuald> [drm] ib[25]=0x82B50215
<virtuald> always [drm] ib[24]=0x0000194E
<virtuald> and always No reloc for ib[25]=0x6538
<virtuald> the other [drm] ib[25] changes but not every time
<bryyyce> virtuald, those are kernel messages.  they can be safely ignored but if they bug you, direct your complaints to #ubuntu-kernel.  Not really anything we can do about those from Xorg-space.
<virtuald> ok
#ubuntu-x 2009-10-01
<tseliot> jcristau, tjaalton: do you happen to know how I can get only the changes up to a certain tagged release or from a certain branch in git?
<jcristau> git pull $remote tag $tag
<jcristau> git pull $remote $branch
<tseliot> perfect, thanks
<bryce> ouch, we seem back up to almost 2100 bug reports
<jcristau> you should never have kids again
<jcristau> ;)
<tjaalton> true
<tjaalton> :)
<bryce> guess not
<bryce> -nvidia seems to get the most blame - http://people.ubuntu.com/~bryce/totals.svg
<bryce> reorganized - http://people.canonical.com/~bryce/totals.svg
<tjaalton> many misfiled bugs against x11-xserver-utils
<tjaalton> people running some test suite
<virtuald> is compiz supposed to work on rv570?
#ubuntu-x 2009-10-02
<tseliot> apw: can you have a look at this kernel patch, please? http://lists.freedesktop.org/archives/intel-gfx/2009-May/002449.html
<tseliot> apw: it should fix bug #145501
<ubottu> Launchpad bug 145501 in xserver-xorg-video-intel "[i855GM] [PATCH] laptop screen remains on with external monitor and lid closed" [Unknown,Confirmed] https://launchpad.net/bugs/145501
<apw> tseliot, hmmm it looks familiar
<tseliot> apw: we already have the X part in, we're missing that patch for KMS though
<tseliot> s/part/patch/
<apw> ok ... will look at it
<tseliot> thanks
<ScottK> tseliot: I've got a karmic box here that has no keyboard after resume from suspend (can't type in the password).  I've ssh'ed into it.  Would you have any suggestions on useful information I could collect to debug why?
<tseliot> ScottK: your /var/log/Xorg.0.log, dmesg, and check that hal is on
<ScottK> OK.  How do I check hal is on?
<tseliot> ps aux | grep hal
<ScottK> Of course
<ScottK> Thanks
<tseliot> np
<ScottK> Yeah, it's on.
<tseliot> it's worth having a look at the logs then
<ScottK> tseliot: Bug 440612
<ubottu> Launchpad bug 440612 in xorg "Lost keyboard after resume from suspend" [Undecided,New] https://launchpad.net/bugs/440612
<tseliot> ScottK: ok, thanks, I'll have a look at it
<ScottK> Great.  Thanks.
<jcristau> which X log has the suspend/resume in it?
<jcristau> ScottK: ^^
<ScottK> No idea
<jcristau> can you attach one that does?
<ScottK> It should be in dmesg I guess
<jcristau> dmesg is the kernel log, not X
<ScottK> Oh.  Then XorgLog I would guess
<ScottK> I let apport pick what to attach
<jcristau> weird.
<jcristau> weird.
<jcristau> err
<jcristau> does a vt switch bring the keyboard back?
<ScottK> It did not.
<ScottK> I restarted kdm and that brought it back.
<ScottK> I've had this machine on Karmic since ~Alpha 3 and this is the first time this has happened.
<ScottK> It's a fresh install of karmic, not an upgrade, btw.
<virtuald> isn't compiz supposed to work with radeon kms? it works without kms.
<lesshaste> avidemux instantly restarts X every time
<lesshaste> is this a known bug?
<bryce> lesshaste, did you see it in launchpad?
<lesshaste> bryce: not obviously
<lesshaste> there a lot of avidemux crashes bugs
<lesshaste> but I don't see an instantly restarts X one
<lesshaste> all I have  to do is type "avidemux" and press return
<bryce> then collect a full backtrace and report it
<lesshaste> bryce: ok but can you help me do that?
<lesshaste> as I say it restarts X
<lesshaste> so I don't know how to get a backtrace
<bryce> I am pretty busy, but most of what you need to know is at wiki.ubuntu.com/X/
<lesshaste> the problem is that sudo force_start=1 /etc/init.d/apport restart doesn't seem to make apport work :(
<tormod> lesshaste, there might be a backtrace in Xorg.0.log or the gdm log
<lesshaste> tormod: I am guessing this is useless to you http://pastebin.ca/1589879
<tormod> lesshaste, that's actually a good start
<lesshaste> tormod: oh :)
<lesshaste> what else can I provide?
<lesshaste> I am make it do it again with just 9 easy key presses :)
<tormod> lesshaste, the whole log attached to your bug report
<lesshaste> tormod: the whole of the gdm.log ?
<lesshaste> it's sort of short
<lesshaste> I was hoping the X log would have something useful
<tormod> sorry the whole Xorg.0.log
<lesshaste> ah that was in the gdm log
<tormod> attach them both
<lesshaste> ok
<lesshaste> thanks
<tormod> did you install xserver-xorg-core-dbg ?
<tormod> lesshaste, next would be to do what they told you in #xorg
<mac_v> tormod: the x crash with cairo dock and compiz cube, i was telling you about a few days ago > Bug 436546
<ubottu> Launchpad bug 436546 in cairo-dock-core "X crashes when using compiz cube and cairo-dock" [Undecided,Confirmed] https://launchpad.net/bugs/436546
<mac_v> tesliot helped getting the Xorg gdb too... 
<mac_v> it still crashes :( no improvement
<tormod> mac_v, you're using mesa from xorg-edgers, but -intel from karmic?
<mac_v> tormod: i'v purged edgers and now using x-updates
<tormod> ok
<bryce> tormod, has sarvatt been around lately?
<tormod> he's here seems like
<tormod> mac_v, I got confused since I read -intel in the apport stuff, you're on -ati of course
<tormod> it reminds me I should update the mesa 7.6.1, it got some flush fixes
<tormod> scratch that, the flush stuff was on master
#ubuntu-x 2009-10-03
<Duke`> Hi
<Duke`> I'm trying to build deb packages with xorg-edgers's xorg-pkg-tools
<Duke`> I run "auto-xorg-git -t "~" -g -H hooks -d origin/ubuntu -p mesa", it creates the .orig.tar.gz, the diff.gz, the .dsc, the .build and the .changes
<Duke`> but I have no .deb file at the end. Is it expected?
<Duke`> do I have to make the .deb manually?
<Duke`> what's next?
<tormod> Duke`, yes these files are the source package. to build binary packages you can run debuild -b -us -uc
<tormod> usually we upload the source package to a PPA
<Duke`> ok, thanks, I'll look at this command
<tormod> don't forget apt-get build-dep mesa before building binaries
<Unggnu> hi all
<Unggnu> I just wanted to ask if the patch from this report could make it into Karmic: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/435241
<ubottu> Launchpad bug 435241 in xserver-xorg-video-intel "Intel KMS ignores some monitor resolutions (SHP 31)" [Undecided,Confirmed]
<Unggnu> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blobdiff;f=drivers/gpu/drm/drm_edid.c;h=bbcb2e22675b127ce64454e69ba7a9abe55b6cc9;hp=80cc6d06d61b6ba53ae316a8de5112c8cf434a09;hb=5c61259e6c7290082108e93815f7f72f27da14f4;hpb=26bbdadad356ec02d33657858d91675f3e9aca94
<Unggnu> * http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=5c61259e6c7290082108e93815f7f72f27da14f4
<Duke`> hum, is there a way to make the building use more than one CPU core?
<Unggnu> Duke`: sure -j CORENUMBER
<Duke`> can I pass it to debuild?
<Unggnu> some say you should use 1,5xCores
<Unggnu> I don't know, but it works with dpkg-buildpackage
<Unggnu> afaik
<Duke`> I know the option for make, but I'm generating deb package
<Duke`> ok
<Duke`> I'll try next time I build one :)
<Unggnu> Imho the Debian-Script should recognize the core number on its own and pass it
<Duke`> currently it's using one core of two, and it's slow :(
<Unggnu> It has a huge impact if you have a quad core and compile the kernel or wine or similar big things
<Unggnu> +especially
<Duke`> yeah, I already experienced these benefits with only a dual core :)
<Unggnu> that's why the build script should recognize its on their own, I mean the difference is even more severe with an i7
<Duke`> ok, I have all my deb packages \o/ It was a bit long.
<Duke`> thank you for your help tormod
<tormod> Duke`, np. you know you can just d/l debs from xorg-edgers also right?
<Duke`> yes, I've done that for months, but I need to track some performance regression
<Duke`> so I'll try to do some bisecting myself...
<tormod> I see, recompiling the whole mesa is quite long
<tormod> yes, you know the tricks with mesa env vars so you can just test the libs without reinstalling?
<Duke`> aahhhh, I've heard about them once but I forgot their existence...
<Duke`> I should look at it, yeah
<tormod> to save you the whole debuild > install debs, rerun cycle
<tormod> maybe you can even git-bisect a built tree and only rerun make (or debian/rules build)
<Duke`> without cleaning up? possible
<tormod> for env vars, see http://dri.freedesktop.org/wiki/TestingAndDebugging
<tormod> http://dri.freedesktop.org/wiki/Building also mentions LD_PRELOAD
<lv_> hi folks - i'm having a hard time getting my extended desktop to work with ubuntu jaunty jackolope using an intel 945GM --- if I am to go through the process of enabling UXA - should i solve this problem
<lv_> ?
<lv_> as of now an output of lshw is showing my graphics controller to be 'unconfirmed'
<ScottK> Urgh.  No compositing today all of a sudden on my mini 10v.  Bug report soon.
<ScottK> Meh, of course as soon as I want to replicate the problem, it goes away
<Duke`__> hehe
<mdeslaur> hmm...I've updates karmic, and now Xorg uses 100% of the CPU all the time.
<mdeslaur> s/updates/updated/
<mdeslaur> the only thing that looks related in dpkg.log is mesa
<pwnguin> hmm
<pwnguin> is compiz running?
<mdeslaur> pwnguin: no, I turn off desktop effects.
<mdeslaur> although I tried turning compiz back on, same thing
<pwnguin> my guess was compiz was somehow running in software mode
<mdeslaur> not even touching the keyboard and Xorg is using 100% cpu
<pwnguin> have you browsed /var/log/Xorg.0.log?
<mdeslaur> yeah, but the only thing that looks odd is: (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
<mdeslaur> hold on, I'll try logging out and loggin back in
<mdeslaur> hmm...logging out and logging back in, the problem is solved and I have "(II) Open ACPI successful (/var/run/acpid.socket)"
<mdeslaur> looks like X is starting before the acpid socket is there for some reason
<mdeslaur> when I fresh boot
<jcristau> shouldn't make a hugh difference though
<jcristau> huge, even
<mdeslaur> hmm...I was on vt 9 after a fresh boot, and now I'm on vt 7
<mdeslaur> sorry, opposite
<mdeslaur> 7 after a fresh boot, 9 now
<pwnguin> you might see if there are other xorg logs of recent origin
<mdeslaur> I found one from a week ago, no difference except for the acpi failure
<mdeslaur> bug 441706
<ubottu> Launchpad bug 441706 in xorg "100% cpu usage with latest updates, acpid socket missing" [Undecided,New] https://launchpad.net/bugs/441706
<pwnguin> mdeslaur: how attached are you to 3d?
<jcristau> oh, nvidia.  fun.
#ubuntu-x 2009-10-04
<mdeslaur> pwnguin: you want me to try nv?
<mdeslaur> pwnguin, jcristau: nice try, but I have the exact same problem with the nv driver
<pwnguin> mdeslaur: actually i wa thinking nvidia
<pwnguin> err nouveau
<mdeslaur> pwnguin: same problem with the nouveau driver
<lesshaste> something odd has happened to my X display with the simplest symptom being that the display runs over to the right of the screen so I can't see it all. Also in /var/log/Xorg.0.log I see http://pastebin.com/f7daea46b
<lesshaste> this followed a standard update 
<directhex> argh. wifey's netbook fails to initialize DRM on cold-boot
<lesshaste> hi all
<lesshaste> bryce: just reported https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/442395 . Anything more specific needed?
<ubottu> Launchpad bug 442395 in xorg "X spontaneously restarts when avidemux is started" [Undecided,New]
<albert23> lesshaste: If you have a second PC available, you could try and make a full stacktrace
<albert23> lesshaste: see https://wiki.ubuntu.com/X/Backtracing
<lesshaste> albert23: I'll see if I can find one
<lesshaste> actually can you use screen to this somehow?
<lesshaste> I am suffering from this bug it seems http://bugs.freedesktop.org/show_bug.cgi?id=19643
<ubottu> Freedesktop bug 19643 in DDX/xorg "X server crash after undocking laptop with LVDS off" [Normal,New]
<lesshaste> the attached patch says "If the screen has no modes defined, can lead to a null pointer
<lesshaste> dereference in VidModeGetFirstModeline().
<lesshaste> "
<lesshaste> so would a sensible workaround be to define some modes in xorg.conf somehow?
#ubuntu-x 2010-10-04
<penguin42> I can reliably trigger ttm_bo_validate to return ENOMEM on Radeon; any ideas how to debug - I assume something is asking for a stupid size
<asac> RAOF: Sarvatt: one question. what happened to the EGL texture pixmap KHR extension we had in your package at some point? 
<asac> or did we never add it there
<Sarvatt> asac: guessing you're talking about mesa? it's there - EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenVG 
<Sarvatt> EGL extensions string:
<Sarvatt>     EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image
<asac> Sarvatt: is that in your ppa?
<asac> someone from our graphics group complained that after upgrade it was gone
 * asac has to restart bbib
<asac> Sarvatt: back for a bit ;)
<asac> unity didnt start here :((
<Sarvatt> asac: no not in a PPA, libegl1-mesa-drivers                                 7.9~git20100924-0ubuntu2
<asac> Sarvatt: ah ok
<Sarvatt> what's wrong?
<asac> well
<asac> not sure
<asac> someone said he was running your ppa and now he doesnt have the extension anymore
<asac> but most likely he ran my version which now got superseded in your ppa or so
<asac> just guessing here
<asac> as long as its in archive its ok
<asac> you might want to include all the gles etc. goodies in your ppa at some points
<Sarvatt> I am :)
<Sarvatt> since august
<asac> Sarvatt: so why is that extension not in your ppa? ;) ... or maybe its missing in the headers?
<Sarvatt> which ppa? xorg-edgers?
<asac> hm
 * Sarvatt has about 20 ppa's with mesa in it
<Sarvatt> but there shouldn't be any missing that extension
<asac> heh
<asac> ok so you say xorg-edgers has it now?
<asac> and main archive? thats good enough
<asac> thanks
 * asac tries unity one more time ... stay tuned
<Sarvatt> ricotz: so, should I add a Recommends: ia32-libs-mesa-dri-experimental [amd64] to edgers libgl1-mesa-dri-experimental?
<ricotz> Sarvatt, did you talked to YokoZar?
<Sarvatt> nope just went over the logs in ubuntu-devel where you guys were talking, sounds like its appropriate in edgers for now at least until the archive one catches up
<ricotz> it might be more convinient to have this Recommend
<Sarvatt> yah thats what I said :)
<ricotz> then do it ;)
<Sarvatt> so its automatically installed when you install it
<Sarvatt> okie
<Sarvatt> i wasn't sure if you guys were renaming the package or anything
<Sarvatt> ia32-libs really needs better versioning :)
<ricotz> yeah, the date should be updated, but they might want to keep in sync with debian
<ricotz> i mean the date string in the version
<Sarvatt> yeah, 20090808 is silly since its been completely refreshed so many times since then
<ricotz> right
<tseliot> mvo: can you remove nvidia-173 from your blacklist, please? We have a driver that works now and there's no need to migrate users to nouveau
<jcristau> Sarvatt: seen 644943?
 * Sarvatt looks
<Sarvatt> first guess - http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=69d65f9184006eac790efcff78a0e425160e95aa
<Sarvatt> i'm seeing the same thing in gnome-terminal and xchat with 2.12 with compiz enabled and its fixed by that
<jcristau> sounds quite plausible.
<jcristau> i guess the ones reporting it from nvidia could have a similar bug there.
<Sarvatt> thanks for the heads up, was about to look for bugs with that exact same issue to ask for testing since i've only reproduced/fixed it locally
<tjaalton> tseliot, mvo: see the end of http://paste2.org/p/1016479, could the missing file be the reason why jockey doesn't create an xorg.conf for the user?
<tseliot> tjaalton: it could be but that's not really an error
<tjaalton> tseliot: maybe it is for jockey
<tseliot> tjaalton: yes, let me check the code
<tseliot> tjaalton: is the package correctly installed?
<tjaalton> tseliot: knittl reported it yesterday, so maybe he knows better :)
<tjaalton> I'll leave you to it, need to run ->
<tseliot> ok
<Sarvatt> so I've got 2 x-x-v-intel patches that need to go through the SRU process, would it be better to target 2 separate uploads or batch them together? one of them is extremely safe - http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0
<bjsnider> tseliot, i was saying yesterday that according to the postinst script, that error is expected in i386
<tseliot> bjsnider: yes, and it doesn't cause dpkg to fail
<bjsnider> right at the end of that pastebin it just says it failed and doesn't specifically say why
<tseliot> hence I find it hard to believe that it can cause that failure
<bjsnider> i was saying the same thing yesterday
<tseliot> good
<Sarvatt> darn, that x-x-v-intel commit doesn't fix xterm, just gnome-terminal and xchat
<Sarvatt> the xchat one with compiz is *very* annoying, fonts resize themselves and disappear at will
<Sarvatt> http://sarvatt.com/downloads/xterm.png
<jcristau> shiny
<Sarvatt> xterm problem is still there on master of everything except server 1.9 branch, couldn't be that easy of course
<knittl> tjaalton: hm? i was afk
<tjaalton> knittl: tseliot left already
<knittl> hm ok
<tjaalton> maybe I need to upgrade my box to see if I can reproduce it..
<Sarvatt> jcristau: are you guys seeing the xterm problem on intel in debian too?
<jcristau> not afaik
<jcristau> the reason i saw that bug is i'm subscribed to xterm lp bug mail :)
<penguin42> Sarvatt: is that just typing or moving back and forward?
<Sarvatt> with xterm its just typing, and it goes away on its on if you let it sit or move the window
<penguin42> Sarvatt: Hmm seems fine here on 945GM
<tjaalton> i can reproduce it
<Sarvatt> in xchat/gnome-terminal on 945 i'm getting fonts disappearing or moving around with the inconsolata font at 10 with slight hinting without the patch I pushed to git
 * penguin42 is on the 'default' font whatever that is
<penguin42> is 'ttm' an allocator for memory on the card itself? i.e. if it's saying ENOMEM is it complaining aboutmemory on the card rather than system?
<Sarvatt> ok the xterm problem might be a compiz problem it looks like, can't reproduce with compiz from git
<Sarvatt> and if it's not in debian it's somewhere between 0.8.4 and 0.8.6 or in one of the patches we carry
<jcristau> could be an xserver 1.7 vs 1.9 difference, too?
 * Sarvatt checks on a f14 livecd
<Sarvatt> anyone around in here using xorg-edgers on lucid with an intel GPU by any chance? :)
<Sarvatt> if so could you launch xterm and type a bunch of characters and see if you get any corruption around them?
<penguin42> Sarvatt: Sorry, my machines are upto Maverick
<penguin42> Sarvatt: Question; The 945GM's 2048 horizotnal limit, is that a hard limit or are there some combinations that it lets it go wider?
<Sarvatt> you can go up to 4096x4096 if you don't use compositing, but you'll lose Xv and such as well
<penguin42> Sarvatt: So when does the GUI stop you doing that; I see two bugs people saying the GUI won't elt them put the monitors side by side, one of which says it worked in Lucid (bug 654515 and bug 651994)
<ubot4> Launchpad bug 654515 in xorg (Ubuntu) "Dual-head setup only possible with stacked screen combination (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/654515
<ubot4> Launchpad bug 651994 in gnome-control-center (Ubuntu) "Dual-monitor possible with top-bottom screen configuration only (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/651994
<Sarvatt> it stops with a black screen if you try to change it after compiz is already started because it isn't smart enough to disable compiz after the fact when it resizes
<penguin42> It looks like in that case though something is limiting it to 2048
<penguin42> Sarvatt: It seems reasonable for it to stop them going above 2k horizontal
<Sarvatt> hmm, if i run xterm inside of an xtruss trace I can't reproduce it either
<penguin42> looks like Mobility 9600 really isn't very happy with modeset
<bjsnider> penguin42, ttm is supposed to manage graphics ram, not system ram
<penguin42> bjsnider: Hmm ok, that makes sense - so getting out of memory from it is slightly less surprising than if it was system memory
<penguin42> bjsnider: But still, it's a bit unfortunate
<bjsnider> how much graphics memory does that thing have?
<tjaalton> intel gfx uses a portion of the main memory
<penguin42> bjsnider: 512MB, although I think only 256 is mapped via PCI
<penguin42> bjsnider: I can reliably trigger the ttm code giving -ENOMEM using google maps in chromium on KDE with desktop effects
<bjsnider> tjaalton, i didn't think intel chips had any discreet graphics ram
<penguin42> (this is on Radeon)
<penguin42> (and why the heck did .Xauthority move?)
<jcristau> because gdm
<tjaalton> ok, missed that line then :)
<penguin42> jcristau: Is there a standrd right answer as to how people are supposed to connect to an existing X display if they ssh in ?
<jcristau> penguin42: make gdm not be stupid :/
<penguin42> is there a reason why gdm started doing it this way?  I just had someone asking aobut how to get x11vnc going, and there isn't a simple answer
<jcristau> no idea
<Sarvatt> a mobility 9600 with 256/512MB vram? no way..
<Sarvatt> most of those had 64
<Sarvatt> sure you aren't looking at the GART size?
<penguin42> Sarvatt: No, mine is an HD4350 with 256/512 - the 9600 was a separate thing
<Sarvatt> oh sorry
<penguin42> Sarvatt: The Mobility 9600 is I'm seeing people who need nomodeset for it
<Sarvatt> doing 10 things at once and misread
<penguin42> if there are a couple of bugs assigned to linux that are in the intel drm code should they be tagged or marked in some particular way?
<Sarvatt> "`xorg-needs-kernel-fix`This is an xorg bug which is dependent on a kernel patch" is the closest thing really, but thats more for bugs against X packages that are really in the kernel
<penguin42> ok, was just looking for a way to flag it to the guys who knew - I've added the function/offset to the title of both of them 
<Sarvatt> if you have a backtrace it helps a lot to put that in the subject of the bug somewhere so we can find it with a search
<penguin42> Sarvatt: Yeh, I've got 3 of them all that are in intel_release_load_detect_pipe+0x21
<Sarvatt> null pointer dereference?
<Sarvatt> lucid stock kernel or maverick?
<Sarvatt> i've seen a few of those but haven't seen the fix
<penguin42> maverick stock; actually I think there are about 6 of them
<penguin42> http://bit.ly/cHVm7a  that's all 7
<RAOF> Sarvatt: You'd do both patches (and any follow up patches needed for that flush commit) in a single SRU.  Which might fix multiple open bugs.
<Sarvatt> RAOF: ahh ok, I was thinking about reverting that and trying to get the sandybridge fix through since the bugs referenced in the changelog aren't actually fixed by it. darn xterm having a different problem than gnome-terminal and xchat
<RAOF> Who uses xterm, anyway? :)
<Sarvatt> gotta find other bugs (or report them *gasp*) for the other compiz text rendering problem if anything :)
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0 doesn't work
<RAOF> Da da daaaaaaaa!
<Sarvatt> gstreamer-properties still tries to auto select Xv
<RAOF> Is there an overlay adaptor available?
<RAOF> I mean, that just disables the textured video port.
<Sarvatt> device says unsupported in both cases and there are no options for textured or overlay, the one i pushed to git actually works though :D
<RAOF> And gstreamer-properties doesn't auto-select Xv in that instance?
<Sarvatt> rebooting into the upstream intel to see what xvinfo says
<Sarvatt> nope, xv is disabled completely and it doesn't hang, with the upstream one it hangs still playing a video in totem with autoselect in gstreamer-properties
<RAOF> Yay us, I guess.
<Sarvatt> I just used parts of what was in the bug report referenced in the commit, they probably didn't want to add the whole xvideo option back to the driver but i'm grabbing some info now to add to the report about how it doesn't work
<bryceh> what do you guys think about putting http://lists.freedesktop.org/archives/intel-gfx/2010-October/008286.html in for an sru?
<Sarvatt> http://lists.freedesktop.org/archives/intel-gfx/2010-October/008299.html
<bryceh> (I suspect it wouldn't pass sru team review, but figure it needs asked)
<Sarvatt> it'd be nice but i think its a big stretch personally
<RAOF> I think it'd be pretty hard to argue that adding support for monitor hotplug events is a bugfix :)
 * penguin42 is now curious, something does happen automagically on monitor hot plugs - so what does that change?
<RAOF> Fair question.
<RAOF> I thought gnome-settings-daemon was watching udev & doing stuff, but that doesn't appear to be the case.
<penguin42> (especially because I keep meaning to file a bug to say that the default behaviour is not flexible enough since it always appears on the wrong side of my laptop!)
<RAOF> penguin42: Come to UDS (or participate remotely)!  We'll be having a âwhat to do with multiheadâ session at some point. :)
 * penguin42 might be able to do some of those, they're evenings for me
<penguin42> RAOF:  Relaly wants it to remember particular states for particular monitors; e.g. if I plug that monitor in then it goes on the left, if I plug that one in it's a projector and ....
<RAOF> gnome-settings-daemon _should_ work there; it does for meâ¢.
#ubuntu-x 2010-10-05
<Sarvatt> 7.9 might be releasing now
<Sarvatt> oh yeah RAOF, no 3D on evergreen even though we have 7.9, it needs the updated ddx for sure
<RAOF> Does that inconvenience you a lot?
<RAOF> I wonder if that performance problem in 6.14 I saw reported on IRC got (a) filed or (b) resolved?
<Sarvatt> not at all, I wasn't sure and I think you weren't sure if we got it so was letting you know :)
<RAOF> Ok.  Maybe I should get an evergreen; my poor geforce 7600go struggles mightily with Civ V :)
<Sarvatt> someone linked this in #radeon earlier and its a really nice fast openarena benchmark run - http://hifi.iki.fi/oa_benchmark.tar.gz
<Sarvatt> was getting sick of using phoronix test suite and its taking 45 minutes per test :)
<Sarvatt> ok here goes, note I only have 1366x768 available on my tv :)
<Sarvatt> default options are mostly low-medium, wonder if it was autodetected
<Sarvatt> oops, wrong window :)
<Sarvatt> dang RAOF, now you got me hooked on civ 5..
<RAOF> Don't worry - the archive is almost locked down :)
<Sarvatt> demo over, boo!
 * Sarvatt buys
<Sarvatt> RAOF: uhoh, I hope what that test case was made for did not regress *again*
<RAOF> I haven't changed my mesa.  I think?
<RAOF> Um...
<Sarvatt> ... white screen
 * RAOF checks his notes.
 * Sarvatt hopes he has a non archive package somewhere
<RAOF> No, white screen isn't what that testcase tests.
<RAOF> It tests the âNo clutter for you!  Bad GLX drawable!â problem.
<Sarvatt> CLUTTER_VBLANK=none required..
<RAOF> Where?
<RAOF> What mesa?
<Sarvatt> 945
<Sarvatt> hopefully its just something local screwing it up
<Sarvatt>  7.9~git20100924-0ubuntu2
<RAOF> GM45 is very happily running unity here.
<RAOF> On, indeed, that mesa.
<RAOF> libcluter-1.0-0 1.2.12-0ubuntu13?
<Sarvatt> yep
<RAOF> Arse.
<Sarvatt> now it's starting up black instead of white
<RAOF> Yeah.  That's the work around for the big white flash on startup being increadibly annoying.
<Sarvatt> now it worked
<Sarvatt> what is this crap
<RAOF> What changed?
<Sarvatt> nothing
<Sarvatt> I ran it 6 times in a row
<Sarvatt> CLUTTER_VBLANK=none unity works 100%, it didn't use to pass CLUTTER_VBLANK when launching it with unity
 * Sarvatt wonders what the heck changed post RC..
<RAOF> Well, we uploaded a new mesa.
<RAOF> 0ubuntu2
<RAOF> Are you running unity from gdm, or from within a session?
<Sarvatt> I was using 0ubuntu2 before it was uploaded to confirm it fixed things
<Sarvatt> inside a session
<Sarvatt> desktop one, trying unity and unity -p
 * RAOF tries to reproduce there.
<bjsnider> is unity built on webkit, like gnome-shell?
<RAOF> No, and gnome-shell isn't built on webkit.
<RAOF> (It's built on gjs, the gobject-javascript bindings which (ab)use firefox's JS engine)
<bjsnider> gnome-shell's appearance properties is a css file
<bjsnider> there must be a layout engine at work
<bjsnider> i assumed it was webkit
 * Sarvatt squints at http://launchpadlibrarian.net/56915042/unity_0.2.46-0ubuntu3_0.2.46-0ubuntu4.diff.gz
<RAOF> Sarvatt: Yeah, I can reproduce this in a desktop session with clutter -p
<RAOF> I mean, um, unity -p
<Sarvatt> hopefully launching it with mutter directly wont be broken like this, busy looking at what might have broken it because we absolutely made sure this was fixed for RC
<Sarvatt> yeah mutter is fine
<Sarvatt> maybe its just busted with compiz
<RAOF> I'm using metacity
<Sarvatt> mutter --replace --mutter-plugins=libunity-mutter and the session works fine here so i'll just chalk it up to more busted unity fun and not freak out again. it still doesn't work without GL_ARB_non_power_of_two (aka ATI) so this is minor :)
<RAOF> I suspect that unity when run as a window might be selecting the wrong drawable to listen to swap_complete on?  Maybe?
<RAOF> bjsnider: gnome-shell just uses a css-parsing library, IIRC, it doesn't embed an html renderer.  Same as the css-based gtk theme engine.
<bjsnider> i see
<cwillu_at_work> has anything been pushed out to 8.04 intel recently?
<cwillu_at_work> a friend of mine lost his x after a normal apt-get upgrade with no special repositories enabled, and is kinda frustrated with the whole concept right now
<cwillu_at_work> (intel, netbook interface)
<cwillu_at_work> er, 10.04 I mean
<Sarvatt> nope
<RAOF> Most recent thing which could possibly have triggered it is the gdm update on 2010/09/27
<RAOF> Next back would be linux-2.6.32-25.44 on 2010/09/18
 * cwillu_at_work checks the changelog
<Sarvatt> http://launchpadlibrarian.net/56057053/gdm_2.30.2.is.2.30.0-0ubuntu3_2.30.2.is.2.30.0-0ubuntu4.diff.gz
<Sarvatt> try reverting that in /etc/init/gdm.conf
<RAOF> That's a pretty long shot.
<RAOF> But, hey!  Why not try.
<Sarvatt> thats a hell of a kernel update changelog
<Sarvatt> https://lists.ubuntu.com/archives/lucid-changes/2010-September/011691.html
<RAOF> Yeah.
<RAOF> A bunch of i915 changes there.
<RAOF> It's the more likely culprit.
<cwillu_at_work> got some more logs from him; I'm no longer sure that it's an x crash
<cwillu_at_work> could a malformed .profile cause the session to die?
<RAOF> I don't know.
<cwillu_at_work> okay, I don't think this is an x problem;  he commented out the sketchy thing in .profile, and although it's still not logging in, it's also not immediately returning to the login screen
<cwillu_at_work> seems more likely that he got hit by an update to dash that tightened up validation or some such
<cwillu_at_work> he's got a bunch of things being complained about now
<cwillu_at_work> okay, .profile errors _will_ cause an xsession to break
<cwillu_at_work> which probably shouldn't be the case, but whatever
<cwillu_at_work> sorry to make you guys dig through changesets :(
<cwillu_at_work> AngryParsley> so I guess the problem was that I copied my .profile over, but never restarted my machine for weeks afterwards
<cwillu_at_work> yay for a user who admits fault :p
<RAOF> :)
<JanC> even wrong permissions on some files could cause troubles with Xorg 
<JanC> or with the session at least
<tseliot> mvo: did you receive the message that I wrote yesterday on IRC?
<mvo> tseliot: hello - I did. update-manager will not explicitely remove nvidia, only if it e.g. conflicts with xserver-xorg-core. so if 173 works u-m should be happy
<tseliot> mvo: perfect, thanks
<penguin42> isn't sure what to do with bugs 651994 and 654515
<ubot4> Launchpad bug 651994 in xserver-xorg-video-intel (Ubuntu) "Dual-monitor possible with top-bottom screen configuration only (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/651994
<ubot4> Launchpad bug 654515 in xserver-xorg-video-intel (Ubuntu) "Dual-head setup only possible with stacked screen combination (affects: 2) (heat: 12)" [Undecided,Invalid] https://launchpad.net/bugs/654515
<penguin42> they're over 2k horizontal, but both claiming they had working configs on Lucid
<Duke`> latest xserver-xorg-video-intel (20101004) is broken
<Duke`> on lucid
<Duke`> X segfaults
<Sarvatt> got a log? someone else said it was broken on maverick too, i haven't tested it yet
<Sarvatt> http://paste.ubuntu.com/506247/
<Duke`> same log for me
<Duke`> after "[    16.553] (II) intel(0): Setting screen physical size to 338 x 211", it breaks
<Sarvatt> what gpu?
<Duke`> btw, the given screen physical size is strange (338 x 211)
<Duke`> i945
<Duke`> http://paste.ubuntu.com/506627/
<Sarvatt> any chance you could try earlier x-x-v-intel's to narrow down where it broke?
<Duke`> the 20101002 is ok
<Duke`> the 20101004 is ko
<Duke`> I fail at driver building from git
<Duke`> at autogen.sh stage :-(
<Duke`> ./configure: line 11185: syntax error near unexpected token `RANDR,'
<Duke`> ./configure: line 11185: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'
<Sarvatt> Duke`: install xserver-xorg-dev and xutils-dev?
<Duke`> and this f****** laptop has serious hardware bugs (it just lost power link, now on battery only until I reboot -___-) 
<Duke`> better with xserver-xorg-dev
<Duke`> but now :
<Duke`> Requested 'libdrm >= 2.4.22' but version of libdrm is 2.4.20
<Duke`> ;_;
<Sarvatt> not building against xorg-edgers?
<Duke`> I use xorg-edgers packages
<Duke`> but for lucid
<Duke`> maybe there isn't the latest libdrm
<Sarvatt> libdrm 2.4.22 is in edgers/lucid
<Sarvatt> intel wouldn't build otherwise
<Sarvatt> weird
<Duke`> yeah
<Sarvatt> whats it say when you sudo apt-get install libdrm-dev?
<Sarvatt> maybe held back for some reason
<Duke`> it says it's up to date
<Duke`> I see the deb packages in pool but not in list
<Sarvatt> oh Duke`
<Sarvatt> you got caught in the accidental libdrm epoch bump
<Sarvatt> i bet
<Duke`> ;_;
<Sarvatt> there's a note on the edgers page about it, the epoch was bumped for a few days by accident  :(
<Duke`> hu ho
<Duke`> how can I fix that?
<Sarvatt> looks like i deleted the note because it was like 3 months ago
<Sarvatt> sudo apt-get install libdrm2/maverick libdrm-dev/maverick libdrm-radeon1/maverick libdrm-nouveau1/maverick libdrm-intel1/maverick libkms1/maverick etc
<Sarvatt> err lucid instead of maverick
<Sarvatt> sorry about that man
<Duke`> np
<Sarvatt> leaving the bumped epoch would have been more of a PITA in the long run
<Sarvatt> it screwed up all the symbols and stuff
<Duke`> how can I list all packages installed from xorg-edgers?
<Sarvatt> hmm maybe I should add that feature to ppa-purge
<Sarvatt> oh you can look in software center
<Sarvatt> key software-center doesn't help much, just shows stuff in there not available in the archive :)
<Sarvatt> oh nevermind I dont even have xorg-edgers enabled, its just showing me stuff I have installed from here still
<Sarvatt> renderbench and intel-gpu-tools
<Sarvatt> Duke`: you can just ppa-purge xorg-edgers and reactivate it too, easier :)
<penguin42> Sarvatt: So I now have two bugs both about >2048 wide displays that worked on Lucid
<penguin42> possibly 3
<Sarvatt> i dont have any more insight into them
<penguin42> any idea what to do with them?
<Duke`> ppa-purge? how does it works?
<Sarvatt> Duke`: it goes over the list of all packages in the PPA, compares it to what you have installed, deactivates the PPA and for each one adds it to a list to sudo apt-get install package1/dist package2/dist so it downgrades them to the archive ones
<Duke`> Warning:  Could not find package list for PPA: xorg-edgers ppa
<Duke`> oh noes :(
<Sarvatt> Duke`: <danvet> Sarvatt, latest xf86-video-intel looks indeed broken
<Sarvatt> <danvet> I'll take a stab at it, otherwise just prod ickel ;)
<Duke`> hopefully maverick will be released in a week, so I'll can upgrade and clean a bit my packages ;p
<Duke`> I upgraded libdrm & libkms manually (download and install)
<Duke`> ok, I could compile it
<Duke`> let's restart
<albert23> penguin42: sounds like it might be bug 619663 (fixed with libdrm commit from freedesktop bug 28515)
<ubot4> Launchpad bug 619663 in xserver-xorg-video-intel (Ubuntu) (and 2 other projects) "[maverick] Non-mirrored dual-screen gives narrow display on secondary monitor (affects: 15) (dups: 2) (heat: 88)" [Undecided,Confirmed] https://launchpad.net/bugs/619663
<ubot4> Freedesktop bug 28515 in DRM/Intel "[i915] Failed to allocate framebuffer when exceed 2048 width" [Normal,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=28515
<Duke`> 7c7294ec00d6c3a454a17a1b9983d14d0655162c is the first bad commit
<Duke`> "shadow+dri2: Allow dri2 to be independently enabled with shadow"
<Duke`> http://paste.ubuntu.com/506664/
<penguin42> albert23: Do you think that is good enough for me to merge the others into it?
<Sarvatt> Duke`: yeah none of the other commits touch 945/gm45 thats broken
<Sarvatt> Option "Shadow" "True" probably works if you need it working now
<albert23> penguin42: I'm not sure. The others don't seem to have logs from running with dual monitors
<penguin42> albert23: If they did what would you be looking for in it?
<albert23> penguin42: (EE) intel(0): Failed to allocate framebuffer. 
<penguin42> albert23: OK, I'll ask the victims to give the logs
<Duke`> Sarvatt: it seems to be a big commit that may break pretty bad ^^
<penguin42> albert23: And if it has that then it's OK to dupe ?
<albert23> penguin42: in my opinion, yes
<penguin42> ok, will do - I spotted another one
<Sarvatt> oh how I wish we released at the normal time and could have pulled in all the Q3 releases, quite a few x-x-v-intel and libdrm fixes
<jcristau> Sarvatt: but 101010 was *so* important!
<Sarvatt> I think the schedule is permanently moving back a few weeks now so it'll be tight every time from now on too
<Sarvatt> RAOF: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/651294
<ubot4> Launchpad bug 651294 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "X crash on KDM logout (still - yes, really) (affects: 3) (heat: 14)" [High,Confirmed]
<jcristau> Sarvatt: it seems hard to make the kdm people understand that relying on regen is not a winning plan
<penguin42> So what do you do for someone whose hardware is giving bogus resolutions about the panel in their laptop?
<RAOF> Sarvatt: Oh, *BAH*. That's no fun.
#ubuntu-x 2010-10-06
<Sarvatt> nvidia 260.19.x seems to have killed most gt310 and gt330 users, and the CustomEDID option some people with optimus are using is broken to boot :(
<RAOF> sarvatt: That's re: the current #ubuntu-desktop discussion?
<Sarvatt> oh? didn't see, I just see tons of bugs and posts on nvnews about it
<Sarvatt> everyone seems to be on one specific model sony vaio actually
<Sarvatt> VPCF11
<Sarvatt> ah the vpc f11 bugs are all using CustomEDID which is hanging
<RAOF> Not bug #655446
<ubot4> Launchpad bug 655446 in xorg (Ubuntu) "Xorg won't start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/655446
<Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?t=155218
<Sarvatt> looks like its all vaio gt3xx's, vaio z which needed a huge amount of hackiness to even use 256.xx is broken too
<bjsnider> there are also a lot of +1 channel discussions from blob users who have a black screen on boot
<Sarvatt> these crappy vaio's are popular machines it looks like :(
<bjsnider> i wonder if nvidia is going to release another blob in the very near future
<Sarvatt> vaio gt2xx's had the same problem dating back a year ago too and it was only fixed in 256.44 - http://www.nvnews.net/vbulletin/showthread.php?t=140482
<bjsnider> perhaps the 256.53 would be the lesser of two weevils
<Sarvatt> i wonder if the fix didn't make it to 260.19.x because they developed them in parallel and 256.44 was newer or something
<RAOF> Or we could just blacklist it, and give them vesa!  That'll be popular :)
<bjsnider> i don't know how you go back to the 256 now that you've already got the 260
<RAOF> The 260 also (apparently) fixes a pretty major performance regression in text rendering, so it's not exactly a win-win.
<RAOF> It'd technically be very easy to go back to 256.  :)
<Sarvatt> 260.19.06-really-256.53.whatever
<bjsnider> that would be ugly
<Sarvatt> 256 would mean backporting 260 with the fix wouldn't be possible and we'd be stuck with the slow 256's
<bjsnider> but then a whole bunch of people wouldn't be able to use it at all
<bjsnider> that's one way to get people on the nouveau driver
<Sarvatt> RAOF: if nouveau works I think I'd lean towards keeping 260 and updating later for sure because the impact is limited to vaio's with quad core cpu's, dual core optimus ones didn't work out of the box as it was anyway
<Sarvatt> for gt3xx generation gt2xx generation did and it is a regression there though
<Sarvatt> ugh :(
<bjsnider> gt2xx can't be all bad. i'm ok on it
<RAOF> But do you have a VPCF11 sony viao laptop?
<Sarvatt> just vaio
<bjsnider> you mean all the people who have come into the +1 channel today bellyaching about this are using vaios?
<Sarvatt> VPCCW is the big gt2xx vaio fixed in 256.44 and broken again in 260
<Sarvatt> i *only* see reports from vaio users
<RAOF> sarvatt: I don't think there's any way we'd drop back to 256 on the basis of a specific single make of laptops having a problem.
<bjsnider> well, i'll ask the ones tomorrow about it
<Sarvatt> here's a Sager Np5125 but thats an optimus laptop and is broken because the CustomEDID option is broken 
<hallyn> is https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia/Nouveau still the right way in maverick to try out nouveau if i'm currently using nvidia drivers?
<hallyn> (only have one laptop handy so prefer to keep experimentation to a minimum right now, but OTOH i'm getting these random 0-10 second delays in screen updates that are just not conducive to getting work done)
<Sarvatt> hallyn: to use nouveau you just disable the binary drivers
<Sarvatt> if you want 3D support with nouveau you install libgl1-mesa-dri-experimental
<hallyn> 'disable' the binary drivers by removing the nvidia-glx package?
<hallyn> (sorry, the whole thing about nto having an xorg.conf just has me all confused these days :)
<Sarvatt> hallyn: in system - administration - additional drivers
<Sarvatt> the disable button next to nvidia-current there
<hallyn> do you know the name of the program that brings up?
<Sarvatt> jockey-gtk
<Sarvatt> you can just purge nvidia-current and remove your /etc/X11/xorg.conf by hand if thats easier
<hallyn> thanks - i'm running jockey-gtk right now.  didn't see a disable tickie-mark, so i hit 'remove'
<hallyn> maybe not what i wanted :)
<hallyn> was sort of hoping for a symlink i could redirect
<Sarvatt> you can switch with update-alternatives/ldconfig but its a pain in the rear
<hallyn> Sarvatt: cool, seems to be done, i'll re-log-in in a bit to test - thanks!
<Sarvatt> hallyn: thanks, let me know if it works out because I'm curious
<bjsnider> Sarvatt, i've got a guinea pig here who's got a blob issue but not on a vaio
<Sarvatt> bjsnider: 256.xx was fine for them and 260.xx doesn't work?
<bjsnider> i'm trying to get that info
<Sarvatt> because i'm not doubting there's blob issues
<hallyn> Sarvatt: worked out great, actually.  In fact, now I get the high-res console to see the rest of bootup messages before x actually starts.  (with glx it just goes blank).  and (crosses fingers) so far none of the random hangs.  still have my 1600x900 resolution, not using any 3d right now so not sure if that's working
<Sarvatt> hallyn: need to install libgl1-mesa-dri-experimental to get accelerated 3D in case you want that :)
<Sarvatt> it may have problems and isn't supported by upstream yet so its not installed by default but it works great here
<hallyn> Sarvatt: yup, i installed that.  just don't have any 3d apps ahandy :)
<hallyn> oh, look at that, got a hang
<Sarvatt> hah! :)
 * hallyn starts to wonder if xterm is the problem
<Sarvatt> if you install it compiz starts by default and that may be a problem
<hallyn> no, i'm running wmii...
<hallyn> at first is uspected compiz (i was using that with glx very pbriefly)
<hallyn> this is crazy.  switching to gnome-terminal...
<Sarvatt> are there any errors in dmesg?
<Sarvatt> worst case scenario, you may need to boot with nouveau.noaccel=1 added to the kernel command line
<hallyn> Sarvatt: but it also happened with nvidia... still worth trying noaccell in that case?
<Sarvatt> oh? odd..
<hallyn> nothing in dmesg :(
 * Sarvatt isn't familiar with wmii
<Sarvatt> what hangs, just individual terminals or the whole screen? how do you recover?
<hallyn> it just recovers after awhile.  often jsut the terminal hangs, i *think* sometimes the whole screen does, but i could be wrong about that
<hallyn> Sarvatt: well, it's pretty random, so it not having happened doesn't mean much, but it really may be xterm hanging
<Sarvatt> hallyn: a wmii problem would be my first guess, i see a few bugs on their tracker about some apps hanging with a blank window that might be related
<hallyn> Sarvatt: no, it happens with gnome+metacity as well
<hallyn> heck, could be the keyboard driver for all i know
<hallyn> need to write a little app that read kbdinput and prints out timestamps next to each char it reads
<hallyn> then have my kids sit there and type 2 chars per second for a few minutes :)
<hallyn> a lego robot, maybe
<Cobalt> Hey guys. I just got a Apple Magic Trackpad. I was wondering how I could force it to use the Synaptics driver in Xorg.
<bjsnider> Sarvatt, the guy i was mentioning earlier has an 8400 gs and it won't work with the 260 blob
<Sarvatt> Cobalt: sudo mv /usr/share/X11/xorg.conf.d/60-magictrackpad.conf{,.bak}
<jcristau> or just override it in xorg.conf
<Cobalt> Sarvatt: Sorry, on Karmic.
<Cobalt> jcristau: That's what I wasn't too sure how to do. The Ubuntu Wiki had a blurb on adding a section in Xorg. They edited out of the page yesterday and I can't find it anymore.
<jcristau> i don't remember what was in karmic.
<Cobalt> I don't want anything fancy, I was just wondering if I could get single-click to work.
<Sarvatt> not sure about karmic, i'm surprised it works at all there
<Cobalt> It points, but no click actions except with the nubs. And only button1 too.
<Cobalt> Hence my wish for exploring a bit further. Oh I will upgrade, but since everything else works fine, I'm not in too much of a hurry.
<Sarvatt> Cobalt: it might just workâ¢ if you try a maverick kernel but that might cause other problems
<Cobalt> I tried a Lucid kernel on this once. It messed up the wireless pretty bad. Eee PC, you know. I have reservations about a bolt-on Maverick kernel.
<Sarvatt> yeah rt2600 is no fun
<Cobalt> What's the command to dump a sample Xorg config file to standard output?
<Cobalt> Well, RT nothing is fun, actually. I've had only grief with their products.
<Sarvatt> sudo X :1 -configure ?
<Cobalt> Ah yeah, just Googled that actually. Seemed a bit too simple. Gah sometimes, something obvious is just too obvious.
<Sarvatt> should be one at ~/xorg.conf.new after that
<raymondjtoth2> any one know how to install Mesa 3D GL driver for intel grahic
<raymondjtoth2> i never did icpiling like to get all new stuff i just install Mesa 3D GL driver
<raymondjtoth2> any one here
<raymondjtoth2> ?
<raymondjtoth2> any one know how to install Mesa 3D GL driver for intel graphic card
<raymondjtoth2> i did install Mesa 3D GL driver
<raymondjtoth2> i mean
<raymondjtoth2> libgl1-mesa-dri-experimental
<raymondjtoth2> i need help install mesa 3d gl driver i did install libgl1-mesa-dri-experimental
<raymondjtoth2> any one
<raymondjtoth2>  any one know how to install Mesa 3D GL driver for intel grahic
<raymondjtoth2> <raymondjtoth2> i never did icpiling like to get all new stuff i just install Mesa 3D GL driver
<raymondjtoth2> <raymondjtoth2> any one here
<raymondjtoth2> <raymondjtoth2> ?
<raymondjtoth2>  i did install libgl1-mesa-dri-experimental
<raymondjtoth2> <raymondjtoth2> any one
<raymondjtoth2> :(
<raymondjtoth2> any one
<raymondjtoth2>  any one know how to install Mesa 3D GL driver for intel grahic
<raymondjtoth2> <raymondjtoth2> <raymondjtoth2> i never did icpiling like to get all new stuff i just install Mesa 3D GL driver
<raymondjtoth2> <raymondjtoth2> <raymondjtoth2> any one here
<raymondjtoth2> <raymondjtoth2> <raymondjtoth2> ?\
<Cobalt> You need to be patient, I think.
<jcristau> it's installed by default, you don't have to do anything.
<tseliot> maybe he meant gallium?
<raymondjtoth2> how i upgade to new build of it
<raymondjtoth2> i ike to have all new stuff in it
<raymondjtoth2> i need 3d for 945GM Graphics how i get the driver for that one
<raymondjtoth2> thanks?
<raymondjtoth2> flash video seam slow 
<raymondjtoth2> on it
<raymondjtoth2> and laging
<jcristau> tseliot: there is no intel gallium driver
<raymondjtoth2> what i do
<raymondjtoth2> jc i got a 945GM Graphics
<raymondjtoth2> intel 945GM Graphics
<jcristau> you said that already.
<raymondjtoth2> o ok 
<raymondjtoth2> jc any thing i can do
<raymondjtoth2> never did conpiling befor
<raymondjtoth2> or hand install driver
<raymondjtoth2> jcristau any idea
<Duke`> :|
<raymondjtoth2> any i dea
<Cobalt> See, with this Bluetooth pairing thing, is it guaranteed every time I reboot my Magic Trackpad will be on /dev/input/event13? I have a funny feeling the answer might be 'NO'.
<Cobalt> Also, I have a trackpad on my laptop which does not come up with X -configure.
<jcristau> no
<Cobalt> I wonder if its configs lie elsewhere.
<raymondjtoth2> any one eles see my q
<Cobalt> raymondjtoth2: Not me.
<penguin42> Cobalt: I bet it'll always be /dev/input/by-id/something
<Cobalt> penguin42: Yeah, but it would be a bummer to have to manually change xorg.conf each time manually to factor that in.
<penguin42> Cobalt: No, I mean the bit after by-id/ will always be the same
<Cobalt> Oh.
<Cobalt> Strange, it mentions something from 'Broadcom'. Which is not what it is. :S
<Cobalt> I think it's grabbing the BT adapter.
<Cobalt> Still, something to try next time.
<Cobalt> First I need to restart X to see if any of that actually works.
<penguin42> Cobalt: Yeh so there is by-id and there is a by-path, but the path might change depending where you plug it in
<Cobalt> It's an internal Bluetooth adapter. Some devices don't show up. But event13 which is the Apple Trackpad shows up as Broadcom something.
<Cobalt> And Broadcom is the make of the BT adapter.
<bryceh> http://www.weebls-stuff.com/songs/Narwhals/
<Cobalt> I've got it already.
<raymondjtoth2> is jc here'
<Sarvatt> man, i want to see the bug count graph after today's over because i'm going crazy on the intel apport bugs
<Sarvatt> got a pretty good routine going on how to spot dupes fast. start by picking a generation, run intel_error_decode on i915_error_state.txt, and you can categorize them by EIR PGTBL_ER and IPEHR matching to spot the dupes
<Sarvatt> literally hundreds of these go through though and intel_error_decode in maverick's intel-gpu-tools isn't good enough to grab the info for all generations
<Sarvatt> when chipset generation EIR and PGTBL_ER match the triggers described in the bug are almost always matching up
<bryceh> Sarvatt, why don't you add that logic to the apport hook so it dupes things up properly?
<Sarvatt> just matching EIR isn't enough, on 965 class hardware i'm seeing 3 different PGTBL_ER's with EIR: 0x00000010 so far
<bryceh> (when you're done with the awesome cleanup)
<Sarvatt> bryceh: because I'm just figuring this out now, will do :)
<Sarvatt> quite a few are just the same people submitting lots of the same thing
<bryceh> aside from being dupes, are you finding the collected crash reports are actionable or upstreamable?
<Sarvatt> not at all
<bryceh> hrm
<Sarvatt> people just hit submit and dont describe whats happening 99% of the time
<bryceh> they probably think the magic of apport collection gathers 100% of the needed info
<bryceh> in which case ironically the apport script might be doing more harm than good
<Sarvatt> the info is useful when i find a real bug report and have the big database of potential dupes to get more info from though  :)
<bryceh> wish we had a crash database separate from the bug tracker
<Sarvatt> now *that* would be nice
<Sarvatt> BlackZ: what's up?
<bryceh> it might be possible to have the apport script prompt the user with a dialog to provide more info or something
<BlackZ> Sarvatt: oh, if you want, we can talk in #ubuntu-motu or here, both channels are OK for me
<BlackZ> Sarvatt: but I think the question I was about to do you is a bit OT for this channel :)
<Sarvatt> considering us X guys made ppa-purge for xorg-edgers I dunno about that :)
<Cobalt> Sarvatt: It autodetects the Magic Trackpad then automatically loads evdev. I can't seem to disable evdev and make it use Synaptics instead, to find if there's some better usability there. :S
<Sarvatt> why does this have to be so complicated? need to create a team so other people can commit to ppa-purge since its just using xorg-edgers now
<bryceh> Sarvatt, didn't it get added to the repo that contains add-apt-repository?
<Sarvatt> not that i'm aware of?
<bryceh> hmm there is https://bugs.edge.launchpad.net/ubuntu/+bug/446216
<ubot4> Launchpad bug 446216 in software-properties (Ubuntu) (and 1 other project) "add-apt-repository should have an option to remove ppa from sources.list (affects: 11) (heat: 48)" [Wishlist,Fix released]
<bryceh> and https://code.edge.launchpad.net/~bryceharrington/software-properties/rm-apt-repository/+merge/25988
<bryceh> anyhoo, time for some breakfast
<Sarvatt> it's hard working up the will to go back to these other 40+ bug tabs I had open now that I got distracted :)
<raymondjtoth2> any one see my q
<cnd> jcristau, hi there
<cnd> as I'm trying to do some development on X, I'm wishing the debian packaging worked more like ubuntu's kernel packaging
<cnd> we keep everything in git, and the debian packaging and our own patches we apply on top of the upstream kernel are maintained as separate commits to the tree
<cnd> when a new upstream kernel is released, the whole tree is rebased
<cnd> it makes patch work much simpler, and allows us to easily track upstream development
<Sarvatt> booo, hiss!! :)
<cnd> what would be your thoughts on doing something similar for debians X packaging?
<cnd> Sarvatt, are you not in favor of the ubuntu kernel approach, or are you just trying to incite a riot :)
<Sarvatt> very much in favor of using the upstream tarballs and patching on top of that, I love the way it's set up now personally :)
<raymondjtoth2> how i install 915resolution
<raymondjtoth2> i dont see it
<jcristau> you don't
<raymondjtoth2> why that
<raymondjtoth2> tell me i need it if 8 or 9 card
<cnd> Sarvatt, it'
<cnd> it's still patching on top of upstream
<cnd> just in git form instead of tarball + quilt patches
<cnd> the orig tarball can still exist as is, the debian diff would look odd though
<cnd> my gut instinct says who cares what the debian diff looks like if we can do our development much faster/better
<jcristau> why would the debian diff look odd?
<jcristau> wouldn't it just be the same as it is today, with the patches applied inline instead of in debian/patches?
<cnd> jcristau, yes, that's what I'm thinking
<cnd> it would just look odd if you expect it to have stand alone patches
<jcristau> (today it's a mix)
<cnd> ahh, I didn't know that
<cnd> I'm actually working on a tree right now
<cnd> sort of a rough draft of this work flow
<cnd> let me push it somewhere
<jcristau> when a patch is already upstream we normally just cherry-pick it to the debian branch
<cnd> ahh, that makes sense
<cnd> which is sort of half of the work flow I'm envisioning
<Sarvatt> xorg-edgers will be... fun.. if that change happens, only as easy as it is now because ubuntu changes are self contained patches on top of debian. guess i'd have to add some logic to maintain lists of commits to revert instead of patches to disable like it works now
<cnd> Sarvatt, it should be easier actually
<cnd> use git revert
<cnd> which creates a new commit that undoes the debian patches we don't want
<Sarvatt> and hope the commit didn't touch the changelog so it actually reverts?
<cnd> when you rebase onto the latest X, it will come along too
<cnd> the ubuntu kernel commits don't actually change the changelog
<cnd> the changelog is generated at build time
<cnd> well, actually it's generated at upload time
<cnd> we'd need to replicate what the ubuntu kernel does there
<cnd> ok, I'm remembering things now, the ubuntu kernel workflow adds a new git commit for each upload to the archive
<cnd> and the contents of the commit is just the changelog entry
<cnd> so all the patch commits leave the debian changelog alone
<cnd> so you can easily revert things
<jcristau> would you mind taking that to email e.g. on debian-x?
<cnd> jcristau, sure
<cnd> I'll make a tree and send an email about it
<Sarvatt> barely put a dent in them - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<Sarvatt> RAOF: asking about the vaio 260.19.xx problem in #nvidia to see if its a known problem, bug reports are still flooding in and they are all vaio gt2xx or gt3xx systems so thats holding up
<tjaalton> Sarvatt: that's.. a depressing graph :)
<bjsnider> it still looks to me like there's more broken hardware than justt he vaio
<penguin42> Sarvatt: I think the good news is the free Radeon driver is actually getting useable and I suspect more people are using it so finding more bugs
<Sarvatt> the radeon problems are almost all in the kernel, intel is the one thats making it nuts
<cnd> Sarvatt, jcristau: how are ubuntu changelog entries handled when debian moves from one release to another, but there were ubuntu entries in between
<cnd> it seems like we interleave them
<Sarvatt> yeah we merge them back with merge-changelog
<cnd> Sarvatt, ok, I'll take a look at it
<cnd> Sarvatt, based on the merge-changelog code (I just glanced at it, man page was no help), it looks like it merges the changelogs and orders entries based on the package version?
<cnd> does that sound right?
<Sarvatt> yep
<cnd> Sarvatt, so is this the process when you make a new ubuntu release:
<cnd> 1. make changes
<cnd> 2. run merge-changelog
<Sarvatt> our goal is to not have a diff over debian as much as possible in the first place
<cnd> 3. dch -i
<cnd> ?
<cnd> of course :)
<cnd> actually, I'm guessing 2 and 3 are swapped
<Sarvatt> which package are you using as an example? it varies a lot, some are perpetually ubuntu versioned like the server
<cnd> I'm interested in xorg-server right now
<cnd> what do you mean by perpetually ubuntu versioned?
<Sarvatt> never need to run merge-changelog, i fix up the changelog diff with git mergetool when merging the debian branch into ubuntu
<cnd> ahh
<cnd> ok
<Sarvatt> cnd: ./auto-xorg-git -t + -H hooks -d origin/ubuntu -u git://yourgitrepo.git -b yourbranch -g -p xorg-server -a 0ubuntu0cnd would work for the server if you have master and your changes in that branch, just need to add the patches to drop in hooks/xorg-server.prepatch, if you're just testing locally its easier to not bump the abi's in hooks/xorg-server.prebuild and just rebuild what you care about against it
<Sarvatt> i just run it once and let it fail then fakeroot debian/rules clean and retry after adding the patch to drop in the hook to work out what patches in ubuntu need to be fixed or dropped
<Sarvatt> there's only 3 or 4 ubuntu specific patches that are really needed anyway out of that huge mess in the server
<cnd> Sarvatt, thanks for the pointers
<cnd> I'll give it a go
<cnd> jcristau, Sarvatt, to follow up, I think Sarvatt's scripts fulfill my needs, and I'm not sure the gitorized packaging branches would have worked out the way I intended in the end
<Sarvatt> woohoo 3 of the arrandale/clarkdale bug reporters with (IPEHR: 0x01820000) are saying its fixed, need to ask for retesting on this mass of other bugs with the same error after duping them
<Sarvatt> that error state seems common to lid closing or dpms events
<Sarvatt> maybe i shouldn't dupe them and just ask for testing individually instead, all it takes is one person to say no to keep a bug with 50 dupes open :)
<jcristau> just close it when one of them say it's fixed :)
<Sarvatt> well at least I learned to say hibernate in 4 languages looking at PGTBL_ER: 0x00000003 bugs :)
<Sarvatt> that one looks to be common across gen3 and gen4 but i'm not duping cross chipset just in case, got separate master bugs
<Sarvatt> lol I was amazed I found an actual bug that could go upstream, then I see it's in karmic and I'm sure its fixed https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/510738
<ubot4> Launchpad bug 510738 in xserver-xorg-video-intel (Ubuntu) "[g45] Stormbaan Coureur crashes: 'render error detected' (EIR: 0x00000010 PGTBL_ER: 0x00800000 IPEHR: 0x780a0101) (affects: 2) (heat: 10)" [Undecided,Confirmed]
<Sarvatt> got the apport bugs condensed to 60 so far and I'm stopping for the day, there's still about 30 left to run intel_error_decode on not counting the ones where the people didn't use the apport generated title - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?field.searchtext=PGTBL_ER
<Sarvatt> bryceh: weren't you looking for examples of when fdo bug statuses dont show up right in launchpad?
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/634683 https://bugs.freedesktop.org/show_bug.cgi?id=30097
<ubot4> Launchpad bug 634683 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[gm45] Running piglit/occlusion-query-discard locks GPU (affects: 4) (heat: 163)" [High,Triaged]
<Sarvatt> verified fixed critical shows up as confirmed critical
<Sarvatt> guess the fdo bug should be resolved instead of verified or does that look right?
<RAOF> High, Triaged?  That got closed in the 20100924 mesa snapshot upload.
<bryceh> hang on, gotta reboot
<Sarvatt> RAOF: oh I didn't even look at the launchpad side of the bug, I swear you closed it in the mesa changelog!
<RAOF> It was probably during that time where LP wasn't closing bugs for us.
<bryceh> Sarvatt, it's possible (likely) that the watch just didn't get triggered to update
<bryceh> I'll reset it
<bryceh> Sarvatt, ok, check it again in about an hour and ping me if it's not set correctly then
<Sarvatt> well I guess it could be worse - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
<Sarvatt> oh thats only a little over a month, whoops
<penguin42> Sarvatt: What was the release date back then?
<Sarvatt> 4/29
<penguin42> so you get a whole raft of fglrx-installer ones in the last few weeks until it just works by release?
<Sarvatt> looks like someone cleaned those up right before october 1st for maverick
<Sarvatt> mid september rather
<penguin42> Sarvatt: What do you reckon for something I've suggested as bug 636418
<ubot4> Launchpad bug 636418 in jockey (Ubuntu) "update should clean up/warn about jockey (affects: 1) (heat: 176)" [Undecided,New] https://launchpad.net/bugs/636418
<Sarvatt> the warning would be nice, but as of the latest packages it already cleans up the installed ones right so that wont happen since tseliot added abi checks
<penguin42> ah ok
<penguin42> we just get so many people arriving on +1 suddenly finding they can't get graphics in an alpha/beta/rc
<Sarvatt> fglrx->natty xserver 1.10 will remove fglrx on upgrade, the checks weren't there this cycle though and it was a mess
<Sarvatt> wait, I may be wrong
<dandel> I'd say contact amd first, and check to see when/if xserver 1.10 will be supported before just blindly removing fglrx.
<Sarvatt> not sure if there are blacklists for specific drivers or if it removes everything wth the old abi
<Sarvatt> they'll gladly not support it for years if no one ships it
<dandel> xserver 1.10 is slatted for 11.x right?
<Sarvatt> that was just an example, hasn't been decided or anything
<Sarvatt> if 1.9.x rocks as much as 1.7.x did maybe not
<Sarvatt> haven't seen a 1.10 release schedule yet
<dandel> The only real concern i have is the fglrx kernel bugs.
<Sarvatt> oh wait, its 6 months, pretty much for sure it'll be 1.9.x
<Sarvatt> had a brain fart there, intel guy is the release manager so was thinking 3 months :)
<dandel> I just hope that libva will get fixed correctly.
<Sarvatt> i doubt it, libva is a real mess
<dandel> maverik is missing packages.
<RAOF> :)
<dandel> it'd be good if libva could get ramped semi-frequently.
<RAOF> What are we missing, libva-wise?
<dandel> glx
<Sarvatt> 965 "support"
<RAOF> Sarvatt: You mean the 965 support that results in an assert as soon as something tries to use it? :){
<dandel> for one... libva-glx or libva-glx1 
<Sarvatt> i'm sure the debian maintainer could use the help if you want to help out with it
<dandel> i just flat installed the libva 1.0.4 packages from the experimental debian repo.
<Sarvatt> yeah it's not even released in debian
<Sarvatt> just been brewing in git for a long time
<dandel> libva is a pain, but is important and should of been properly put into the 10.10 release (but packages are missing)
<Sarvatt> so why not help out with it?
<RAOF> It'd be more important if anything used it.
<RAOF> And a reasonable selection of hardware supported it :)
<Sarvatt> i want to stab my eyes out every time i look at that code
<RAOF> It'd be nice if there was a (free) gstreamer libva element.  That'd make me care about libva a lot more.
<RAOF> Fluendo's gstreamer elements are kick-arse.
<dandel> RAOF, it's in use by newer releases of vlc, ffmpeg, xbmc, mplayer, gnash and is picking up support increasingly on the api's. 
<jcristau> if it doesn't support any hw that's kind of moot
<dandel> It's supports nvidia video cards via vdpau.
<RAOF> And fglrx via the (non-free?) xvba thingy.
<dandel> an amd dev said that xvba got too much news coverage early in the dev cycle and it has no set ready date.
<Sarvatt> jcristau: poulsbo and fglrx isn't good enough for you? :)
<jcristau> Sarvatt: surprisingly, no
<bryceh> *cough*
<RAOF> I mean, I'm in no way against having it in the archive, and will give it some support, but it's hard find the motivation to invest time in it when it'll only run on top of the existing APIs of blobs.
<RAOF> Which means that it'll become more interesting as it actually starts to support Intel hardware.
<dandel> anyways, xvba doesn't work for me (yet), but that's somewhat anticipated... i have a evergreen based video card.
<RAOF> Doesn't fglrx support evergreen properly yet?
<dandel> it supports evergreen properly... it's just i don't have video accelerated decoding yet.
<Sarvatt> http://wiki.debian.org/DebianMultimedia has some places to go to see what the status is for libva
<RAOF> So, not full support for evergreen then.
<dandel> however, i do get to run unigine heaven with tessellation enabled.
<dandel> and the rendering for that program is correct... however, gluxmark2 (last i checked) had some defects in the 10.8 and 10.9 driver.
<dandel> it's just that ati has no proven bug report methods that get quick results and testing... The location i use to report bugs has long delays. (a month just for confirmation of the bug as reproduce-able)
<dandel> RAOF, do you want to actually see what i get when i try to run a vaapi based decode?
<RAOF> Not particularly, no :)
<dandel> i get a moziac of the output image.
<dandel> the output is decoded with the gpu, but it's just that the output images are incorrect.
#ubuntu-x 2010-10-07
<bjsnider> RAOF, gstreamer-vaapi is free, although it is very raw at this point
<bjsnider> it works but doesn't have any subtitle support right now
<RAOF> Oh, and it actually works & exists now?  I've been aware that there's been work on that area, I just haven't followed closely.
<RAOF> (vdpau on fluendo on my tiny little netbook is sufficiently useful to crowd out other investigations)
<bjsnider> you have to actually...
<bjsnider> horro of horros...
<bjsnider> PAY for that right?
<RAOF> Indeed you do!  Shocking, I know.
<bjsnider> pardon me while i throw myself off the nearest tall building in despair
<bjsnider> RAOF, you've always been madly in love with gstreamer, but others prefer mplayer and/or vlc
<RAOF> Yeah, I know.
<bjsnider> i think there's a movement on to make kde's media player engine vlc instead of xine
<RAOF> But gstreamer is (rightly) the default, so it's reasonable to care more about it.  Particularly when that aligns with my own interests :)
<bjsnider> it's RIGHTLY the default
 * RAOF still isn't sure why kde's media player isn't a thin layer around gstreamer :)
<jcristau> because gstreamer has a g
<jcristau> they can't possibly allow that in kde
<RAOF> Worse, it's gobject based!
<bjsnider> yeah but why did they pick xine, of all things?
<RAOF> Because it's an actual engine, I think.
<RAOF> Like, is intended to be used as such.
<RAOF> Does vlc provide that sort of thing?  I've only interacted with it as a (kick-arse) player for Windows/Mac.
<bjsnider> evidently so
<bjsnider> but anything that can be used at the command line could theoretically be used that way
<RAOF> Yeah, but that's *made* of ugly.
<jcristau> so is kde, so that's fine
 * jcristau hides
<bjsnider> xine couldn't even do 24-bit flac until very recently
<bjsnider> it still can't do flac 5.1
<RAOF> See?  GStreamer :P
<bjsnider> why is gstreamer better than mplayer?
 * RAOF doesn't actually know if the gstreamer decoders support that, 'cause he doesn't have (a) a 24bit soundcard, (b) 5.1 speakers.
<bjsnider> gstreamer does do both
<bjsnider> but so does mplayer and so does vlc
<RAOF> Mainly because mplayer is the whole widget, with a terrible UI.
<bjsnider> ok, forget the stupid ui
<bjsnider> it's been dropped anyway
<RAOF> So it's now just a commandline client?
<bjsnider> yes
<bjsnider> but nobody who seriously uses it had installed mplayer-gui for years
<bjsnider> there are much better gui clients, like gnome-mplayer and smplayer
<RAOF> A commandline client isn't particularly programmer-friendly.
<bjsnider> it doesnt eh best subtitles, and it was the first app that had vdpau
<RAOF> The thing that I particularly like about gstreamer is that it can be, and is, our media framework.
<RAOF> (Also that it's trivially pluggable, which is important)
<bjsnider> so it's better because it's what we currently have? i do not accept that reasoning
<RAOF> It's better because nothing else can reasonably be our media framework.
<RAOF> Nothing else (bar xine, I think?) does the sort of plugability we need.
<bjsnider> what if videolan could?
<RAOF> Then it might be a good idea, but it'd need to be significantly better than gstreamer to justify the switch.
<RAOF> Is videolan actually intended to be used as a media player framework, though?  I know that it's possible to use it as such, but isn't it much more focused on vlc?
<bjsnider> you know, it's developed as heavily as anything i've seen, so it might not have been yesterday, and it might be today
<bjsnider> if you ever try to build it, it's significantly different after 6 weeks than it was earlier
<bjsnider> quite unlike xine, by the way
<RAOF> That's not exactly an unconditional win :)
<bjsnider> vlc probably cooks your supper and tucks you into bed by now
<RAOF> Well, get it stabilised, supporting plugabble codecs, and used by GNOME applications and I'll care significantly more about it :)
 * freeflying 
<warewolf> hm
<warewolf> ok, #ubuntu is useless, I have an X problem so I'll try poking around here.
<warewolf> I updated my T91MT running lucid last night, and now stuff is all kinds of broken.
<warewolf> single user mode gets stuck before getting to that curses UI menu thing, and X acts like there are no mouse/keyboard devices defined.
<warewolf> I can get a shell via init=/bin/bash, but have no idea how to troubleshoot upstart.
<RAOF> Sounds like udev might be broken?
<warewolf> I just disabled the one and only custom rule I had in there for android adb
<warewolf> oh I suppose I could have looked at the xorg log. duh.  lemme see.
<warewolf> er
<warewolf> I don't even see *mention* of keyboard in the xorg conf at all.
<RAOF> You have an xorg.conf?
<warewolf> yeah, but it's really short.
<RAOF> Many people won't.
<warewolf> just some stuff for the T91MT's touchscreen, with Sarvatt's help
<warewolf> er
<RAOF> Ok.
<warewolf> s/xorg conf/xorg log/
<warewolf> I expect to see something about a keyboard device in the xorg log
<RAOF> Only if udev's working.
<RAOF> If udev isn't working then X won't see *any* input devices.
<warewolf> ok, another notch in udev being broken.
<warewolf> yeah, that sounds about right then.
<warewolf> how the fsck did I break udev by doing a system update last night? *boggles*
<warewolf> I suck at troubleshooting udev
<warewolf> ok
<warewolf> dpkg-reconfigure udev and update_initramfs=all fixxored
<Sarvatt> sorry richard, I just walked in the door and missed your messages, get it working? wonder what the heck happened there
<Sarvatt> warewolf: did you see there were proprietary drivers for that piece of junk now that probably work on lucid? :)
<Sarvatt> i think one of those guys that was packaging up the PSB stuff has a PPA with them on launchpad, bernardo something?
<Sarvatt> drivers are called emgd
<Sarvatt> i still can't download anything but windows drivers direct from intel, trying to download for any linux distro gives me an exe
 * Sarvatt goes back to trying to root his G2
<RAOF> Good plan!
<bjsnider> does jockey not block the nvidia run files anymore?
<RAOF> As in: prevent them from working?  Did it ever?
<bjsnider> it prevented them from installing starting with lucid
<bjsnider> but now all these n00bs are in the +1 channel talking about how they installed the .run files
<Sarvatt> warewolf: speak of the devil... http://woot.com/
<Sarvatt> just ordered a 5770, time to go through some of this fglrx pain :)
<RAOF> :)
<bjsnider> tseliot, does jockey not block the nvidia run files anymore?
<tseliot> bjsnider: jockey never did that
<bjsnider> ok, well i must hve misunderstood then
<bjsnider> it's nvidia-current that does it, but it's not part of the metapackages, so it's not there by default
<warewolf> Sarvatt: hah
<Sarvatt> bryceh: would it be possible to move intel to the top of the chart so the other packages are easier to follow? http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<dandel> Sarvatt: lol... that report shows how popular ati hardware is on linux.
<Sarvatt> dandel: i think you're looking at it wrong
<Sarvatt> fglrx being at the top doesn't mean it has the most, the fglrx bugs are represented by the tiny blue strip at the top only
<dandel> if that's the case, the #1 used hardware is intel (which is not surprising)
<Sarvatt> you cant really pull any use numbers out of that, intel is really skewed because we have automatic crash reporting bugs for that package only which is getting triggered by some non fatal crashes and flooding launchpad
<dandel> i see... and that bug report results are not as bad... i know i removed a few packages results manually because i did bleeding edge tests (2.6.36 kernel tests)
<Sarvatt> cnd: dunno if you got my message about it, but wouldn't it make more sense to install 60-magictrackpad.conf in a utouch package instead of evdev since utouch isn't installed by default everywhere and there is a loss of functionality using evdev without it?
<cnd> Sarvatt, utouch is merely a meta package
<cnd> you could argue it could go into libutouch-grail1
<cnd> but that is installed everywhere
<cnd> to answer the question more directly, we don't want a different experience between the desktop and netbook installs
<cnd> right now the desktop has a subset of the features in netbook because compiz doesn't have gestures like unity does
<cnd> but we don't want there to be divergent features between the two
<cnd> and to be honest, I was on your side too
<jcristau> so you regress the desktop instead :)
<cnd> I would rather have left the magic trackpad alone for now
<cnd> but I was overruled by others :)
<cnd> the desktop never regressed
<cnd> in lucid, the synaptics functionality wasn't present
<jcristau> oh, ok
<cnd> we had a choice in maverick to either enable synaptics functionality, or enable gestures
<cnd> due to time constraints
<bjsnider> Sarvatt, why in the world are you buying an ati card?
<bjsnider> do you enjoy pain?
<cnd> and all the synaptics functionality should be duplicated in our gesture framework in Natty (hopefully)
<cnd> it not in Natty, certainly by the O
<Sarvatt> woo baby, http://cgit.freedesktop.org/mesa/drm/commit/?id=726210f87d558d558022f35bc8c839e798a19f0c is going to fix a massive amount of these apport intel bugs
<Sarvatt> bjsnider: I don't have any ati's to break anymore and there was nothing better at $120
<Sarvatt> hell, I want a poulsbo machine still :)
 * Sarvatt likes broken stuff
<Sarvatt> but i draw the line at 8xx intel's
<jcristau> heh
<bryceh> Sarvatt, nice work - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick.svg
<Sarvatt> bryceh: that aint even half of it, and a large chunk of the duped ones are going to be closed whenever I can get that libdrm fix SRUed :)
<Sarvatt> i'm going through and adjusting the titles of all of them now and will dupe after since that makes it easier so they stopped going down for a bit
<Sarvatt> then i can start actually fixing things.. lol
<bryceh> cool
<bryceh> special attention to 656243 would be deserved
<Sarvatt> yep thats the libdrm problem
<Sarvatt> already have it in git, asked for testing of the PPA one on the many bugs
<Sarvatt> haven't started condensing that one too much because people report the symptoms differently and want to get feedback on the different symptoms, but there are 3 major ones i'm looking at so far
<bryceh> cool
<Sarvatt> bryceh: when should I start looking for sponsors and preparing the bugs for SRU? I'm just assuming I'd have to wait until release first :)
<bryceh> nope you can prepare SRUs as soon as you are confident in the fix
<bryceh> in fact the release team sometimes pulls in SRUs pre-release if there's time and the bug looks acceptable to them
<bryceh> also, sru bugs generally need a week or so of testing before the archive team puts them out, so filing them now means they can be tested while the release is finishing up, and can go out a few days post-release
<Sarvatt> oh heck, I've had a sandybridge fix ready and tested by many HWE people for the past week but assumed it was bad form to try to SRU before release unless it was critical
<Sarvatt> RAOF: forgot to commit something to x-x-v-intel git?
<Sarvatt>   * Cherry-pick e30f0338 to free the Screen pixmap on close.  Fixes a memory
<Sarvatt>     leak on server regeneration, and another crash on KDE log out hidden by
<Sarvatt>     LP 628077.
<ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i865] Crash on logout with KDM (affects: 1) (heat: 111)" [High,Fix released] https://launchpad.net/bugs/628077
 * Sarvatt just noticed it missing in the debdiff
<Sarvatt> hmm, not where where this bug should go http://launchpadlibrarian.net/55916325/XorgLogOld.txt
<Sarvatt> bryceh: well the apport reports are for sure better than 90% of the normal bugs, the automatic duping just needs to  be fixed up a bit. at least I can tell whats actually happening without relying on what they say, like if they have a video playing in firefox and just say firefox is causing the crash and its a lot easier to spot dupes
<Sarvatt> looking at non apport bugs is painfully slow now :)
 * penguin42 is going to try and apply THomas Hellstrom's ttm fix that Dave Airlie pushed today , see if it fixes his -12 errors
<Sarvatt> if PGTBL_ER + chipset generation match they can be duped, IPEHR: 0x7xxxxxxx are all 3D engine related on 965+, IPEHR: 0x018xxxxxx are enable/disabling/resizing the monitor related, IPEHR: 0x01810000 is always accelerated video playback on 8xx, etc
<Sarvatt> guess I should read the docs
<Sarvatt> beats the heck out of manually going over the logs for 10+ minutes on each bug to find a trace of the problem
<penguin42> did Radeon hd5xxx ever work on Lucid? I had a bug raised where it was wrongly doing KMS for them but couldn't cut it - was there ever anything to address that?
<Sarvatt> penguin42: I don't know for sure but I'll find out tomorrow when I get my 5770 in, as far as I remember it shouldn't have even tried to work at that point and vesa would be used until fglrx was installed
<penguin42> ah it's listed in lucid-updates
<penguin42> Sarvatt: Bug 560306
<ubot4> Launchpad bug 560306 in xserver-xorg-video-ati (Ubuntu Lucid) (and 3 other projects) "[lucid] ATI hd5xxx cards wrongly doing kms? (affects: 38) (dups: 5) (heat: 154)" [High,Fix released] https://launchpad.net/bugs/560306
<Sarvatt> hmm that shouldn't have been happening
<Sarvatt> it even loaded the rv710 microcode
<penguin42> Sarvatt: Hence why I reported it
<Sarvatt> oh looks like I responded there and didn't check up on it after too, I thought the radeon.modeset=1 that we had forced in the x-x-v-ati synced from debian was screwing it up
<Sarvatt> lets see, one person saying no problem in the lucid -rc..
<penguin42> Sarvatt: With that guy just reporting it still happening on 10.04.1 it would be good to get it fixed next time a CD gets regenerated (is there going to be a .2 ?)
<Sarvatt> haven't made it down that far in the  bug yet :)
<Sarvatt> ugh its another dumping ground bug so far, people reporting all kinds of other problems thinking its the same
<penguin42> yeh - whether it is or not is a good question
<Sarvatt> like the dvi-0/dvi-1 issue
<penguin42> Sarvatt: I don't have a 5k to try it out, if 10.04.1 actually works for you it would be good to note it
<Sarvatt> yeah will do for sure
<Sarvatt> there was a bug where the dvi port assignments were messed up and only one of the two was working on radeon that I see a few people mentioning but i'm (almost) positive that was fixed
<penguin42> oh well, that's the sods law of having two ports, it'll always use the wrong one
<Sarvatt> evergreen firmware isn't the issue since .33 didn't support it in the first place but I guess it got added anyway
<Sarvatt> radeon thinks its an rv710
<jcristau> you didn't backport evergreen kms?
<Sarvatt> nope
<Sarvatt> not that i'm aware of
<jcristau> k
<Sarvatt> we released before it was even remotely stable if i'm remembering right, you guys had more room to do it :)
<jcristau> ah right, we got that in may
<Sarvatt> penguin42: yeah people are just hitting the dvi problem, I know theres a fix for that and will try to work it out when the card comes. we got time with 10.04.2 being released in january :)
<Sarvatt> backporting 5xxx KMS sure would be nice though
<Sarvatt> there's no logs on that bug to look over to see whats happening now on them
<Sarvatt> oh dang, missed some of the later responses, people hitting it on maverick?
<penguin42> that's a pity, the drm-fixes patch I pulled didn't fix my -12 error :-(
<Sarvatt> -12 error?
<penguin42> Sarvatt: I can get an ENOMEM out of the ttm code by scrolling around google maps in chromium-browser (daily-ppa) in KDE with desktop effects on (HD4350)
<penguin42> I have managed to trigger it on Gnome without desktop effects once, but I can trigger it in KDE with de in seconds
<Sarvatt> is it one of those crazy AGP versions?
<penguin42> no, PCI-e, 512MB ram on it
<Sarvatt> penguin42: do you have a bug on it by any chance? not having any luck finding any with that that aren't from IGP's
<penguin42> Sarvatt: I commented on bug 583891
<ubot4> Launchpad bug 583891 in debian (and 1 other project) "X.org crashes sometimes. [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! (affects: 9) (heat: 46)" [Undecided,Confirmed] https://launchpad.net/bugs/583891
<Sarvatt> of course its filed against linux and has no X related logs :(
<Sarvatt> and quite a few of the people have old 9xxx series IGP's like the other bugs
<penguin42> Sarvatt: I was wonderign whether to add an also-affects to Xorg
<Sarvatt> that wouldn't get good logs in there but I doubt its the same bug hitting your card and those IGP's the other people have
<penguin42> ok, should I file a separate one, and what would be useful for debug?
<Sarvatt> they have things like [    8.435421] [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of ASIC bug ?) in it
<Sarvatt> does the system completely hang when it happens?
<penguin42> Sarvatt: No
<Sarvatt> oh, it does for the IGP people too
<penguin42> Sarvatt: Just the Chromium process dies
<Sarvatt> if you could trigger it then run ubuntu-bug xorg it'd put some useful logs on it, that'd be appreciated
<penguin42> Sarvatt: OK, will do - I don't think there is anything useful in any of the logs to be honest
<Sarvatt> i haven't found anyone else on r600+ reporting it so far
<Sarvatt> your dmesg to see what's happening at startup would be useful
<penguin42> ok, let me just switch back to the kernel without my debug in
<penguin42> Sarvatt: I'd thought Dave's post to lkml/dri-devel today sounded promising though - but I think I've patched that in to my build and it hasn't helped
 * Sarvatt takes a look
<Sarvatt> penguin42: just curious, have you tried 6.13.2 from here? https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<penguin42> no, I haven't but can do
<penguin42> Sarvatt: You want the bug against xserver-xorg-video-ati ?
<Sarvatt> penguin42: if you have that 6.13.2 installed then just xorg since it wont let you
<Sarvatt> xorg and xserver-xorg-video-ati attach the same info
<Sarvatt> can just move it over after
<penguin42> Sarvatt: Well I was just going to report it with the standard stuff first and then try 6.13.2
<Sarvatt> sounds good, thanks for that since if we upstream it they're going to ask you to try newer :)
<penguin42> Sarvatt: OK, bug 656522
<ubot4> Launchpad bug 656522 in xserver-xorg-video-ati (Ubuntu) "drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! from google-maps in chromium-browser (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656522
<penguin42> Sarvatt: Still does it with 6.13.2-0ubuntu1~xup1
<Sarvatt> penguin42: hmm, that bug is proving tricksy to track down, you really are running out of memory somewhere. have you tried disabling the memory remap option in bios by any chance? your bios looks to be full of all kinds of iommu fail
<penguin42> Sarvatt: I can try, not sure if it has any options for that - what makes you say it has lots of iommu fail; I know it has plenty of intremap fail :-(
<Sarvatt> that ^
<penguin42> what?
<Sarvatt> 1.50	9/15/2009	Instant Flash	874.94KB	1. Modify for Intel HD Audio.
<Sarvatt> 2. Change 'Memory Remap Feature' function default = 'Enabled'.
<Sarvatt> the interrupt remapping problems
<penguin42> ok, will try that - what does it actually do?
<penguin42> hang on; aren't interrupt and memory remapping separate things?
<Sarvatt> its all in intel-iommu
<penguin42> what's memory remapping?
<Sarvatt> magic that breaks thing very often :)
<penguin42> ah; I had noticed that I only get 256MB of the cards memory mapped into the PCI-bar -b ut that's a limit of PCI bars isn't it?
<Sarvatt> http://en.wikipedia.org/wiki/IOMMU explains it better than i ever could
<penguin42> is there a way to see how much ttm memory is allocated/in use?
<RAOF>  /sys/kernel/debug/dri/0/gem_objects should be a reasonable proxy, I think.
<Sarvatt> not sure off the top of my head, there might be something ttm specific in debugfs?
<penguin42> Sarvatt: I don't see an option for IOMMUI
<penguin42> IOMMU or remapping in the bios
<penguin42> only turning VT or VT-d on and off
<Sarvatt> no memory remap option? VTd?
<penguin42> no memory remap option; there is a VT-d option - is that related?
 * penguin42 has just flipped an option for the default graphics card type from PCI to PCI-e but I think that's just for selecting between multiple cards
<Sarvatt> yeah thats DMAR and interrupt remapping, really this is magic to me that i just see pop up as broken in bug reports often :)
<penguin42> the interrupt remapping is some VT related stuff; so VT-d might be involved but I haven't followed it well enough
<penguin42> right, so starting kde with desktop effects enabled and gem_objects says 874 objects, 100MB object bytes 0 pinned, 0 pin bytes, 0 gtt bytes, 0 gtt total
<penguin42> starting chromium with no pages loaded and that's upto 993/128MB
<Sarvatt> it just sounds like theres some artificial size barrier along the way giving you the ENOMEM
<penguin42> zooming in and we're at 206MB
<penguin42> zoomed out hit 430MB, so maybe it did flip over 512MB?
<Sarvatt> sheesh, filled up that fast?
<penguin42> yeh
<penguin42> zooming out in particular
<Sarvatt> is it going down or going over the limit ever? did it crash already?
<penguin42> it's also being very jerky, not fuilly repainting and stuff - it's not happy
<penguin42> yeh it does go down a bit
<penguin42> it's not completing a redraw, I'm getting the satellite imagery but none of the overlays
<Sarvatt> i think theres ttm info somewhere in debugfs, +EXPORT_SYMBOL(ttm_page_alloc_debugfs);
<penguin42> I have a ttm_page_pool
<penguin42> the only none-0 line curently reads wc refuills 267 freed 0 size: 136704
<penguin42> 635125760 object bytes
<RAOF> A mere 600MB
<penguin42> on a 512MB card
<RAOF> Which would be a problem, if ttm isn't evicting pages properly.
<RAOF> If it was working properly that wouldn't be too much of an issue.  Unless you actually need to be texturing from all 600MB there, in which case performance will die.
<penguin42> I mean this is kind of a nice bug in the sense that I can trigger it in seconds, except that I have to login to KDE to do it
<Sarvatt> cant reproduce it in gnome?
<penguin42> Sarvatt: I have done once, although I haven't tried turning on desktop effects in gnome (I have them on in KDE)
<Sarvatt> what do you use normally?
<penguin42> gnome without desktop effects
<penguin42> I'll just go and get something to eat; back in 15mins; but I'll give Gnome+desktop effects a go and see if it breaks
<Sarvatt> gnome with effects would be interesting
<Sarvatt> :) food! good idea
 * penguin42 tries KDE every so often, it's getting closer to what I like but it's model of using storage devices just doesn't work for me since KDE4
 * penguin42 files a PA bug - switching from KDE to Gnome leaves PA broken
<penguin42> right
<penguin42> oh god, wobbly windows
<penguin42> Sarvatt: I can't quite get it to pop, even with full desktop effects
<penguin42> (In gnome)
<penguin42> The amount of space is still big, but not as big and it's obviously still got redraw issues
 * penguin42 comes to the conclusion that the daily chromium builds are using GL in some way where as the standard set aren't
<RAOF> I think that is the case, yeah.
<penguin42> the standard repo chromium is fine
#ubuntu-x 2010-10-08
<Sarvatt> kaay chromium dlopen's /usr/lib/libGL.so.1 apparently to work around a problem in the nvidia blob libGL, ours is in /usr/lib/foo/, there is no libgl dependency on the package, and libgl1-mesa-dri is a build dep?
<Sarvatt> guess we dont need the libgl dep anyway since it doesnt work :)
<RAOF> We need to work out whether we care that we're breaking the linux OpenGL ABI.
<bjsnider> why does chromium need opengl?
<RAOF> Because it wants to do hardware accelerated graphics, I guess.
<RAOF> Also, WebGLâ¢
<bjsnider> thanks for the trademark
<bjsnider> i was worried it wasn't trademarked but you have assuaged my fears
 * RAOF loves his gnome-keyring Do plugin.
<bjsnider> so now al we need is a flawless opengl implementation on linux
<bjsnider> should be the case in about 300 years
<RAOF> WebGL should work now, at least.
<bjsnider> somebody probably once said that about opengl
<RAOF> And OpenGL works now*
<RAOF> *: For some values of works :)
<bjsnider> i could challenge that, but it's like shooting fish in a barrel, isn't it?
<bjsnider> by the way, what is mesa up to now? opengl which version?
<RAOF> Mu
<RAOF> (As in: the question is incorrect)
<bjsnider> 2.1 still?
<RAOF> No.
<RAOF> Roughly speaking, somewhere between 2.0 and 4
<bjsnider> ok, what's it up to on modern hardware that has a decent mesa driver?
<RAOF> It *claims* 2.1, but I don't think it fully supports all the 2.1 features.  Similarly, it supports 3.x features.
<bjsnider> that's probably not even enough qualifications
<RAOF> And some GL 4.x features, too.
<bjsnider> and that's mainy for the last intel chips before they started going to that closed-source company for hardware right?
<RAOF> No; that's for radeon (and to a lesser extent nouveau).
<RAOF> And some features are basically driver independent.
<RAOF> (Like the "use the ES 2.0 profile for GLSL on desktop GL" feature)
<bjsnider> let me ax you a specific question i've been wondering about
<bjsnider> you work with the nouveau guys right?
<bjsnider> if you found a serious flaw in the nouveau driver, could you personally code in a solution?
<RAOF> It depends; I could probably fix a serious but shallow problem, but I don't have a good grasp of the deep.
<RAOF> (That's something I plan to work on over the Natty timeframe)
<bjsnider> well, i'm not talking about the kinds of patches to the nvidia blob that kick around and change 3 linkes or whatever
<bjsnider> i'm talking about something requiring significant changes
<bjsnider> hundreds of lines
<RAOF> Again, it depends on the actual problem.
<RAOF> Let's take, for example, my most recent kernel hacking: the Intel 965 resolution change wierdness.
<bjsnider> i doubt you could. i doubt anyone could fix the kinds of problems i have in mind except the nouveau devs themselves
<bjsnider> and in that sense, nouveau and nvidia are the same. we are depending in both cases on those developers and ONLY those developers to fix things FOR US
<RAOF> We *can* provide more useful bug reports for the nouveau developers.
<bjsnider> i knew you'd say that
<RAOF> Well, that's probably because it's true :)
<bjsnider> did you see those benchmarks on phoronix where nouveau is one third as fast as nvidia ont he same hardware?
<RAOF> Man, that's pretty good.
<bjsnider> what if i asked you to, in the natty timeframe, fix it so that the performance was even par?
<RAOF> No.
<bjsnider> and who could do that?
<RAOF> Nvidia, given 2 years.
<RAOF> The performance of the nvidia driver has taken *hundreds* of full-time developers *years* to produce.
<RAOF> The free drivers are unlikely to reach performance parity with either the nvidia or fglrx blobs unless they become the development focus of the respective companies.
<bjsnider> ok, lemme rephrase: as fast as the theroetical limit of the gallium framework given what is known about nvidia hardware
<RAOF> I don't know; "theoretical limit" is a bit problematic, because the gallium framework is basically mutable, *and* hasn't really seen a huge amount of profiling - if you found a serious bottleneck, you could fix it.
<bjsnider> alright, further qualification: your subjective view of it's theoretical limit
<bjsnider> the question is, could you, RAOF, personally push the driver that far in the natty timeframe?
<RAOF> No.
<bjsnider> could anyone at canonical?
<RAOF> I don't think *anyone* could.
<RAOF> But, no, I don't think there's anyone better for that at Canonical.
<bjsnider> well, the nouveau guys could if it was their only goal, leaving everything else aside
<bjsnider> i suspect that's the same deal for all graphics drivers. so us normal regular users can't do much but bellyache about it: same as nvidia
<RAOF> I don't think that's a useful metric, really.
<RAOF> Regular users certainly *can* do things; and we've contributed code to the free drivers.
<bjsnider> well, nvidia has a bug reporting system too
<bjsnider> it's not as transparent as launchpad though
<bjsnider> but it's there
<RAOF> But we can't contribute code.
<RAOF> And I mean that in the most expansive sense of "we".
<bjsnider> you just said you couldn't contribute anything more than trivial changes
<bjsnider> and if you can't, reguylar users can't either
<RAOF> Well, there's a bit of a difference between "I probably can't fix the deep problems that you're thinking of *now*" and "can't contribute anything more than trivial changes".
<RAOF> I'm not an expert in the internals of nouveau at the moment, but the thing about open-source is that I could *become* one.
<bjsnider> how hard would it be to become an experton nouveau's internals compared to, say, gnome-shell, which is javascript?
<RAOF> More difficult, certainly.
<bjsnider> (i'm cheating, since js was chosen specifically to invite contributions)
<RAOF> *Particularly* because there's no official documentation.
<RAOF> It's relatively much easier to pick up i915.
<bjsnider> yeah, well i thought i read an article where the nouveau guys said they didn't need any since they'd reverse-engineered everything
<bjsnider> do a lot of non-intel people contribute to i915?
<RAOF> Yes.
<bjsnider> to be fair though, that is not exactly on par with nvidia graphics hardware, is it?
<RAOF> A fair number of non-AMD people contribute to radeon, too.
<bjsnider> what about contributors who aren't being paid to do so?
<RAOF> There are a bunch.
<RAOF> Certainly a couple.
<RAOF> The nice thing about documentation is egde cases.  Which sometimes the documentation doesn't contain anyway, but when it *does* contain them it's really, really nice.
<bjsnider> edge cases?
<bryceh> bjsnider, edge case as in a chip model that has some unique feature or implements a feature in a weird way
<RAOF> Things like the i965 resolution change bug: (sometimes!) when changing to a lower resolution, the display would go all wonky.
<RAOF> Perusing the documentation, it turned out that the hardware cursor was required to have at least one pixel on the screen; when switching down, with the mouse in an area which was outside the new resolution, we'd have the cursor fully outside the new framebuffer.
<RAOF> Constraining the cursor so that it remains on the framebuffer fixed this.
<RAOF> And the bug would have been significantly more difficult to diagnose if I didn't have the documentation.
<RAOF> Without it, you're left with "it looks like the digital display looses sync sometimes when we decrese resolution with the mouse in a particular spot!?"
<bjsnider> so all we need is the documentation, but nvidia can't release it because of nda's with other companies, and so we won't have it anyway
<RAOF> Well, not all we need.
<RAOF> It *would* be helpful, but we also need manpower (which is easier to acquire with documentation, though)
<RAOF> bryceh, Sarvatt: Do you think we can solve bug #636311 with a change in the conf-files?  I haven't quite figured out a way to distinguish the two different devices the keyboard shows up as.
<ubot4> Launchpad bug 636311 in xserver-xorg-input-evdev (Ubuntu) (and 2 other projects) "Keyboard special keys interfere with mouse (affects: 12) (dups: 1) (heat: 68)" [High,Incomplete] https://launchpad.net/bugs/636311
<RAOF> Oh, hm.  That could be done in udev, by not tagging the second device with IS_KEYBOARD.
<Sarvatt> the SUSE xserver crash handler is so nice - https://bugs.freedesktop.org/attachment.cgi?id=39285
<jcristau> is that the patches emmes just sent?
<jcristau> looks impressive
<Sarvatt> oh wow they sent it upstream?
<Sarvatt> i saw it about 6 months ago in their source packages, was meaning to try to get it going on our stuff
<jcristau> 14193 N   Fri 08/10/2010 18:25+0200 Matthias Hopf      (1.5K) [PATCH] Create reasonable backtraces via gdb automatically
<Sarvatt> yeah thats the same thing though
<cnd> Sarvatt, do you know where the debian packaging for xinput is maintained?
<cnd> I can't find it on git.debian.org
<Sarvatt> jcristau does it outside of pkg-xorg
<Sarvatt> one sec
<Sarvatt> the full list takes awhile to load on this netbook :)
<Sarvatt> http://git.debian.org/?p=users/jcristau/xinput.git;a=summary
<cnd> ahh, ok
<cnd> thanks!
<cnd> Sarvatt, is there a way to tell auto-xorg-git where that repo is?
<cnd> it seems confused :)
<Sarvatt> yeah it doesnt work for things outside of pkg-xorg :(
<cnd> ok, I'll hack it up so it does
<cnd> :)
<jcristau> i should probably get that into pkg-xorg.
#ubuntu-x 2010-10-09
<penguin42> I've got a bug which is the 2nd I've seen in a few days where a laptop has misidentified the resolution of its inbuilt LVDS at a higher res than it really is
<penguin42> bug 657113
<ubot4> Launchpad bug 657113 in xserver-xorg-video-ati (Ubuntu) "Thinkpad T30: Auto-detection selects wrong screen resolution (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/657113
<penguin42> the other one was bug 654170
<ubot4> Launchpad bug 654170 in xserver-xorg-video-ati (Ubuntu) "screen remains blank after boot / wrong resolution (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/654170
<geneiros> hi there everyone...
<geneiros> Does someone can help me in a XORG issue?
<geneiros> anyone?
<penguin42> geneiros: What's up?
<geneiros> hi there penguin42...
<geneiros> i have a problem with xorg in kubuntu, and i would like to know if this is the right place to ask for help...
<penguin42> geneiros: The right place is normally #ubuntu or #ubuntu+1 generally but they might point you here if you have an odd X problem - so heck, ask the question already :-)
<geneiros> thanks...
<geneiros> i've been using kubuntu 10.10 rc
<penguin42> ok
<geneiros> and today i have this strange beavior that my xorg went from 60mb to 140 in no time and when closing all apps it didnt decrease the memory usage...is this normal?
<geneiros> in lucid there was a bug with gems objects...
<penguin42> ah so I don't know enough to help you, but there are those around who might - but it's pretty dead on here at the moment
<geneiros> i see...
<geneiros> tomorow a great day?
<penguin42> I dunno when the guys will be around
<penguin42> geneiros: So, erm which graphics card?
<geneiros> nvidia 7600
<geneiros> go
<geneiros> i have nvidia 260 drivers
<penguin42> ah ok, I don't know - I don't follow the nvidia stuff (I'm an ATI user) - you could try on #ubuntu+1 I know some of those guys have nvidias
<geneiros> ok...
<geneiros> as an ati user...
<geneiros> how well is the ati supported??
<geneiros> i never had an ati card...
<geneiros> the nvidia is a little bit strange sometimes...
<geneiros> like...
<geneiros> my plymouth doesnt show...
<geneiros> since 10.04 that i dont see anythin from power on to gdm...
<geneiros> and no fix came out...
<geneiros> does your plymouth plays well?
<penguin42> I get plymouth I think, most Nvidia users seem to get a text mode thing rather than anything nicer
<geneiros> yes...
<kirill> hello there are ther somebody who can help me with drivers
<kirill> i have a problem when i try to make it in xubuntu but all right in ubuntu
#ubuntu-x 2010-10-10
<geneiros> hi there kirill
<kirill> o
<kirill> hi geneiros
<kirill> can u help me?
<geneiros> i'll try
<kirill> i got drivers fron viaarena and install it on ubuntu but when i try it on xubuntu i got errors when i try to make and make install
<kirill> i cant understand how i can resolve this problem with make
<kirill> i reinstall build essential but it dont help me
<geneiros> what is the error?
<kirill> error 2
<geneiros> and what drivers are you trying to install?
<kirill> viaarena - unichrome9
<geneiros> does the make runs well?
<kirill> i think may be rivers for gnome dont work on xcf
<kirill> on ubuntu all ok
<kirill> i do the same things on xubuntu like on ubuntu
<penguin42> kirill: The 2 is the last bit - what went before
<kirill> but on xubuntu they dont work
<kirill> ./vinstall
<kirill> then cd via
<kirill> then make
<kirill> then error2
<penguin42> just error 2? Nothing else?
<kirill> yes
<geneiros> thats strange
<kirill> what i error2?
<penguin42> ENOENT - No such file or directory
<kirill> oooooooo
<penguin42> normally something tells you what it was trying to do before going splat
<kirill> downalod arhive
<libv> urgh
<kirill> then unpack it
<kirill> then ./vinstall
<kirill> got a new dir
<kirill> enter new dir
<kirill> then make
<kirill> then make install
<libv> kirill: VIA barely understands english, let alone free software
<libv> kirill: give up now.
<geneiros> do you have kernel source installed?
<kirill> hmm
<kirill> i donno
<kirill> im newby
<kirill> i do the same thing like in ubuntu thats all
<geneiros> the error of folder is lib/modules/2.*.*/build?
<kirill> o
<kirill> how i can download and reinstall kernel?
 * libv shakes his head and returns to debugging vbe on a 6y old laptop
<kirill> ok i reinstall xubuntu now and try again
<kirill> senk u
<kirill> bye
<JanC> anybody know how well ATI/Intel switching graphics work with Ubuntu?
<JanC> in 10.10 I mean
<geneiros> i have only nvidia card...cant help...
<geneiros> do you mean hibrid cards?
<penguin42> JanC: I've been lurking on #ubuntu+1 for quite a while now and I don't think I've seen anyone ask
<JanC> it's some new tech with Core i3 and such where you can switch between the intel & radeon card at runtime on windows
<JanC> used in laptops
<penguin42> JanC: Yeh it's been around for a while ; I use a machine at work that has such a setup
<penguin42> but I just keep it locked on Intel
<JanC> but I was mostly wanting to know if it was possible to use the ATI card  ;)
<penguin42> JanC: The Bios on the thinkpad I have allows you to select between switchable and one or the other in the bios
<JanC> it's an MSI laptop
<penguin42> JanC: Theoretically I think the kernel now has the feature enabled (VGA Switcheroo) don't know what hardware it works on though
<JanC> anyway, the intel part works fine, just don't know how to use the radeon part  âº
<penguin42> JanC: Do you see a /sys/kernel/debug/vgaswitcheroo ?
<JanC> nope, didn't have much time anyway
<JanC> I might have a look at that when I go to my parent next time  âº
<penguin42> JanC: See http://asusm51ta-with-linux.blogspot.com/
<JanC> thanks, I'll have a look at it
<JanC> Ubuntu might need to grow support for this though, as it proposes to install fglrx, but when you install it, it doesn't boot anymore  ;)
<JanC> well, boots, but doesn't start X
<bjsnider> where's the best place to look for a log message when compiz fails to load?
<ari-tczew> does ubuntu use package nvidia-kernel-common ?
<ari-tczew> I would merge this one in natty.
<bjsnider> no it does not
<bjsnider> it uses nvidia-common though
<ari-tczew> bjsnider: so package can be deleted?
<bjsnider> what do you mean?
<bjsnider> ari-tczew, sorry, i misinterpreted your original question. You can probably delete that package
<ari-tczew> bjsnider: ok, I'll open a request.
<Alan> Damn, can you guys work out where you want configuration to be? :P
<RAOF> It hasn't changed since Lucid :)
<Alan> Yes it has
<RAOF> Lucid had it in /usr/share/X11l/xorg.conf.d; we backported that patch (didn't we?)
<Alan> What was /usr/lib/X11/xorg.conf.d/ now appears to be /usr/share/X11/xorg.conf.d/
<Alan> RAOF: not that i can see
<Alan> still at /usr/lib in Lucid for me
<RAOF> Oh.  Well, either way, it's unlikely to move from /usr/share/X11, which is where it should have been in the first place.
<Alan> :P
<Alan> At least this isn't a major problem
<RAOF> Also, that shouldn't _really_ affect you; /etc/X11/xorg.conf.d will override those snippets (IIRC), and /etc/X11/xorg.conf will override _everything_ :)
<Alan> Unlike the last 4 releases which have required completely different hacks to make my mouse button remapping work
<Alan> RAOF: I thought /etc/X11/xorg.conf.d/ didn't work in Lucid?
<Alan> i thought that's why i ended up using the /usr/lib/X11.... one in the first place...
<RAOF> It might not have worked in Lucid, you're right.
<Alan> well i'm glad things have straightened out
<RAOF> Yeah.  This should be the final state.
<RAOF> For a while, at least.  Until we decide to go for some form of XML-based registry config :)
<Alan> ugh
<Alan> yeah
<Alan> basically, i've been through Xorg.conf hacks, hal hacks, udev hacks, more hal hacks and then xorg.conf hacks to make this damned thing work over the last several releases....
<RAOF> Yeah.  We've been moving the foundations a bit.
<Alan> oh good, just dropped my thing in /etc/X11/xorg.conf.d/ and it worked
<RAOF> Yay!  Sane configuration!
<RAOF> Incidentally, what specifically do you need to configure?
<Alan> I love the .d/ habit in Linux
<Alan> I have a multi-button mouse, and the side-button on the mouse is significantly more ergonomic than using a middle mouse button ever is, so i remap that button to be another button-2
<Alan> and seeming as i use middle mouse button A LOT... it's a pretty important thing for me
<Alan> http://www.alanbriolat.co.uk/2010/04/remapping-mouse-buttons-on-ubuntu-lucid/
 * RAOF adds that to his UDS blueprint queue.
<ari-tczew> could someone take a look on bug 653274
<ubot4> Launchpad bug 653274 in linux (Ubuntu) (and 1 other project) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver (affects: 7) (heat: 44)" [Undecided,Confirmed] https://launchpad.net/bugs/653274
<ari-tczew> whether it's linux or plymouth affected
#ubuntu-x 2011-10-03
<noobish> last night I had s3tc GL extensions reported by glxinfo after installing libtxc-dxtn0 from edgers. Today I reboot and the extensions are not listed by glxinfo. ldconfig -p shows the library is found. Any ideas?
<RAOF> noobish: Made any other changes?
<noobish> just moved an export for LIBGL_DRIVERS_PATH from .profile to .bashrc
<noobish> I did briefly install the i386 version of libtxc_dxtn.so to /usr/lib32 and run ldconfig. But I've since removed that and re-ldconfig'd
<noobish> oo
<noobish> there's an env var i forgot about
<noobish> R600_ENABLE_S3TC=1
<RAOF> What arch are you on, i386 or amd64?
<noobish> amd64
<noobish> exporting that var has glxinfo reporting the extensions now
<noobish> But not when the 32bit version of glxinfo runs, so I'm now reinstalling the i386 version of the lib to lib32
<RAOF> You might want to install it to /usr/lib/i386-linux-gnu.  I think /usr/lib32 will work too, though.
<noobish> hmm, i don't have that dir
<noobish> just the x86_64-linux-gnu
<noobish> i386 glxinfo reports the exts now too
<noobish> this is on natty, so i think the edgers ppa is just bringing part of the multiarch changes over?
<noobish> i know the x86_64-linux-gnu dir didn't exist before i added edgers
<RAOF> Ah, yeah.  That'd be right.
<noobish> Everything looks in order now but sadly this game, eve still complains about smader model 3 support lacking, grr
<noobish> *shader
<noobish> oo, i think my kernel is too old. 2.6.38
<noobish> is drm-next in mainline the same as airlied's drm-radeon-testing branch?
<noobish> off to test 2.6.39-020639rc4. Thanks for letting me sound ideas off you RAOF
<RAOF> noobish: Why test 2.6.39?  The current development version is 3.1; Oneiric has 3.0 stable kernels.
<noobish> Because 2.6.39 is the one that doesn't disable s3tc commands. I just didn't want to go too far not knowing what was stable and what was bleeding edge.
<noobish> and what would require 11.10 instead of 11.04, etc
<johanbr> Could someone please have a look at bug 582809? This makes Ubuntu essentially unusable for the 143 people listed as affected. There are patches available, but no fixes have been incorporated into the ubuntu synaptics package.
<ubot4> Launchpad bug 582809 in xserver-xorg-input-synaptics (Ubuntu Maverick) (and 6 other projects) "Synaptics Clickpad touchpad buttons are not working (affects: 174) (dups: 10) (heat: 835)" [Undecided,Confirmed] https://launchpad.net/bugs/582809
<tjaalton> johanbr: what about it? there are no upstream-sanctioned patches available afaict
<johanbr> tjaalton, right... the upstream effort seems stalled
<johanbr> otoh, the patches that are available do work (unlike the unpatched driver)
#ubuntu-x 2011-10-04
<noobish> any suggestions where to look for cruft from xorg-edgers that's causing my 32bit version of fglrx libGL trying to load swrast_dri.so instead of fglrx_dri.so? I've done a ppa-purge
<RAOF>  /usr/lib/i386-linux-gnu would be a reasonable candidate.
<noobish> on this distro it's just /usr/lib32
<RAOF> If you've installed from xorg-edgers it's likely that it installed something in /usr/lib/i386-linux-gnu
<noobish> doesn't exist, but i do have a /usr/lib32/i386-linux-gnu
<RAOF> That's a strange abomination of a path?
<RAOF> What's in there?
<noobish> but it just contains a symlink to ../gdk-pixbuf-2.0
<noobish> i believe edgers did create /usr/lib/x86_64-linux-gnu
<noobish> uh
<noobish> i'm dumb, /usr/lib32/i386-linux-gnu does exist, and it just has that same symlink as above
<noobish> err, no i'm not dumb! that's what i said earlier
<noobish> bah i'm tired
<RAOF> :)
<bjsnider> does that path exist for multiarch in reverse?
<noobish> poking around in /usr/lib/x86_64-linux-gnu/xorg i see that the extra-modules link is broken
<Sarvatt> noobish: fglrx libGL.so.1 wouldn't ever load swrast, that means you have a 32 bit libGL floating around being used instead of the fglrx one most likely from ia32-libs. i'm guessing update-alternatives --list gl_conf says mesa is in use meaning 64 bit is broken too?
<noobish> fglrx is listed first, then mesa
<noobish> glxinfo amd64 version reports direct rendering
<noobish> 64 seems fine
<noobish> although i can't get glxgears to run correctly
<bjsnider> who's the vendor in glxinfo?
<Sarvatt> have you not rebooted since switching?
<noobish> i have rebooted
<noobish> ATI
<noobish> for server/client/ and opengl
<noobish> oo wait
<noobish> the i386 build of glxinfo shows mesa for the client glx vendor string
<Sarvatt> there is no ia32-libs or fglrx for natty in edgers so its nothing related to the ppa, i suggest just removing fglrx and reenabling it via jockey to fix it
<bjsnider> where is it looking
<noobish> i think it's /usr/lib32/libGL.so
<bjsnider> that's an ia32-libs path
<noobish> yeah, not sure where it came from but i don't think it's part of either fglrx or edgers
<bjsnider> what's that command...
<noobish> eh?
<Sarvatt> dpkg -S
<bjsnider> ldconfig|grep libGL
<Sarvatt> dpkg -S /usr/lib32/libGL.so
<bjsnider> something like that
<noobish> bjsnider: that's what i did to see /usr/lib32/libgl.so
<bjsnider> it's too late in the evening for thinkin'
<noobish> yep
<bjsnider> yeah run Sarvatt's command
<noobish> ia32-libs-dev: /usr/lib32/libGL.so
<bjsnider> find out what put it there
<noobish> i think that was installed with edgers?
<Sarvatt> no you had to do that manually
<bjsnider> purge it
<noobish> mmk
<bjsnider> then reinstall fglrx
<bjsnider> then reboot
<noobish> i don't remember installing it
<bjsnider> well, it didn't install itself
<noobish> :)
<noobish> yeah that's got to be it, thanks. I'm rebooting
<Sarvatt> if ia32-libs-dev really breaks proprietary drivers that needs a bug filed, doubt it's commonly tested so probably an old bug :)
 * Sarvatt passes the heck out
<bjsnider> maybe there should be a wiki page about "remove old ia32libs and -dev so it doesn't break your opengl"
<noobish> that lib, plus removing  a symlink /usr/lib32/libGL.so.1 -> /usr/lib32/mesa/blah blah fixed it, that symlink wasn't found in any installed pkg
<noobish> dpkg -S, very useful command!
<bjsnider> ricotz, any idea why i don't seem to need the mutter package in oneiric? it installs /usr/bin/mutter and yet i don't need it to run gnome-shell
<ricotz> bjsnider, gnome-shell uses libmutter, so there is no need for the mutter executable
<bjsnider> i see
#ubuntu-x 2011-10-05
<seb128> hey guys
<seb128> what infos would be useful for a bug about a touchpad that stops working in the middle for an xorg session?
<seb128> " if i use the hotkey, when enabling it, I see:
<seb128>  [  4485.492] (II) SynPS/2 Synaptics TouchPad: failed to open grail, no gesture support
<seb128>  [  4485.492] (--) SynPS/2 Synaptics TouchPad: touchpad found
<seb128>  but the touchpad isn't driving the pointer"
<seb128> "xinput --list-props "SynPS/2 Synaptics TouchPad" says
<seb128> Device Enabled (132): 1
<jcristau> output of evtest, xev, check that nothing has a grab on it.
<seb128> jcristau, thanks
<seb128> (it's not me having the issue but asking for those infos to be added to the bug)
<jcristau> though a grab would probably not stop the pointer from moving
<scoundrel50a> hi, I have a new laptop, that i have 11.10 installed on, but for the past week, since one of the upgrades, I havent been able to get it to load. It loads the background, and not the gui......can anybody help please?
<scoundrel50a> Once the background has loaded, I can get a terminal, but clicking on Ctrl+Alt+F1 and have been updating every day using that.....
<scoundrel50a> upgrades should read updates
<scoundrel50a> is there anybody able to help? 
<scoundrel50a> hello?
<tjaalton> scoundrel50a: does lightdm start from the terminal (sudo start lightdm)
<seb128> bug #868400
<ubot4> Launchpad bug 868400 in xserver-xorg-input-synaptics (Ubuntu) "Synaptics touchpad stops working (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/868400
<seb128> bryceh, tjaalton, RAOF: ^ could you look at that issue?
<seb128> the sabdfl get it on different thinkpads and it seems quite often
<tjaalton> seb128: I'm off for a few hours, will have a look after if no-one else beats me to it..
<seb128> tjaalton, no hurry, thanks
<scoundrel50a> tjaalton: sorry had to go out, are you still there?
<tjaalton> scoundrel50a: on and off
<scoundrel50a> ok, just entered that command, and something happened, what is supposed to happen
<tjaalton> lightdm to start
<scoundrel50a> oh, not sure what lightdm is, but its stopped at startiong cups 
<tjaalton> you have all the updates in?
<scoundrel50a> I update everyday using this
<scoundrel50a> it seems to have stuck
<tjaalton> "using this"?
<scoundrel50a> yes
<scoundrel50a> no display has come up
<scoundrel50a> sorry using Ctrl+Alt+F1 for updates
<tjaalton> so there's no x behind f7?
<scoundrel50a> I dont know what that means
<tjaalton> vt7, alt-f7
<scoundrel50a> when I start Ubuntu, it shows the background, but nothing else loads, I will reload, and see what happens, give me a sec
<scoundrel50a> rebooted, and clicked Alt+F7 but nothing happened
<tjaalton> what gfx hardware does it have?
<scoundrel50a> its a lenovo 550 laptop
<tjaalton> so.. intel?
<scoundrel50a> yes
<scoundrel50a> rebooting again to get the information from the other partition
<tjaalton> you said it worked for a while?
<scoundrel50a> yeh, it did up till about a week ago, and there was a big update, and it stopped working
<scoundrel50a> ok, got the graphics card info
<tjaalton> lspci would've been enough
<tjaalton> install pastebinit, then run 'pastebinit /var/log/Xorg.0.log'
<scoundrel50a> its a Pentium (R) Dual Core CPUwith Mobile Intel GM45 Express Chipset x86/MMX/SSE2
<scoundrel50a> how would I send it to use, just using the terminal
<scoundrel50a> because I am using a different laptop to talk to you
<scoundrel50a> I can get in using Ubuntu 2d
<scoundrel50a> would that work?
<tjaalton> uh
<tjaalton> so, in other words X is running just fine
<scoundrel50a> Ubuntu doesnt work, but 2D does
<tjaalton> you're on the wrong channel then
<scoundrel50a> no
<tjaalton> yes
<scoundrel50a> I am talking abotu 11.10
<tjaalton> this is about X
<tjaalton> try #ubuntu+1
<tjaalton> your personal unity session is somehow broken
<tjaalton> nothing to do with X
<scoundrel50a> oh, sorry, didnt know, will try that, thanks for the help
<seb128> jcristau, tjaalton, bryceh: 
<seb128> <sabdfl> seb128, evtest says:
<seb128> <sabdfl>   This device is grabbed by another process.
<seb128>    No events are available to evtest while the
<seb128>    other grab is active.
<seb128>    In most cases, this is caused by an X driver,
<seb128>    try VT-switching and re-run evtest again.
<seb128> is there any way to tell what is having the grab?
<tjaalton> that needs to be run from a vt
<seb128> why?
<seb128> it works under x for me
<tjaalton> it does?
<seb128> tjaalton, yes
<seb128> tjaalton, http://pastebin.ubuntu.com/702862/
<seb128> and it reacts to events by displaying those
<tjaalton> oh, news to me. didn't use to work in the past
<seb128> tjaalton, well, still, any way to see what process is grabbing the device? ;-)
<tjaalton> unity?-)
<tjaalton> x220 tablet has a multitouch panel on it, and the touchpad
<seb128> tjaalton, if that's unity killing the process should restore the device right?
<tjaalton> seb128: hopefully yes
<seb128> tjaalton, https://launchpadlibrarian.net/82023565/xinput.txt is his xinput
<seb128> â   â³ TPPS/2 IBM TrackPoint                   	id=14	[slave  pointer  (2)]
<seb128> â   â³ SynPS/2 Synaptics TouchPad              	id=11	[slave  pointer  (2)]
<tjaalton> yes
<tjaalton> does the trackpoint work?
<tjaalton> i don't see any other failure than some X client grabbing it. apparently evtest from a vt would work
<jcristau> the synaptics driver still grabs the device by default iirc?
<jcristau> (evdev doesn't)
<tjaalton> ah ok
<tjaalton> i'll test on mine
<jcristau> haven't checked in a while though
<tjaalton> oh, the output says that too
<tjaalton> "in most cases..."
<tjaalton> seb128: so, please ask him to test it on a vt
<tjaalton> seb128: evtest that is
<bryceh> tjaalton, hey noticed you dropped POT building from xkeyboard-config's rules, however #868554 suggests the POT building logic is still needed.
<bryceh> tjaalton, were there other reasons for dropping it?  If not, mind if I re-add it?
<tjaalton> bryceh: i'll check in a minute
<tjaalton> bryceh: ok, sorry about that. there should be a way to clean up afterwards though, trying to figure it out
<tjaalton> the old rule shows as a diff in git and diff.gz
<bryceh> ah
<tjaalton> umm, the result of the rule, rather
<tjaalton> bryceh: i'll handle the bug, need to understand how the pot-magic with lp works anyway
<bryceh> tjaalton, ok great
<tjaalton> bryceh: ok I think it works better now, just need to figure out how to push it from this laptop :)
<bryceh> tjaalton, awesome
<bryceh> heh, "Precise Pangolin"
<bryceh> what the hell is a Pangolin?
<tjaalton> the english name didn't say anything, but I know the creature :)
<tjaalton> as presented by sir david attenborough on the tv
<bryceh> Perky Penguin would have been better
<tjaalton> "ant(pine)cone" in finnish
<bryceh> hehe
<tjaalton> bryceh: check the commit to xkb-data, seem sane to you? :)
<bryceh> tjaalton, looks good
<tjaalton> alright, time to upload
<bryceh> and time for some lunch.. bbiab
<bdmurray> cnd: what 2 finger touches should be available / work?
<RAOF> I don't believe there are any 2-finger gestures in geis/unity.
<bdmurray> well something in firefox makes it zoom in / out
<RAOF> So, synaptics should be providing a right click on 2 finger tap, and a scroll for two-finger drag.
<Sarvatt> bdmurray: about:config, search for browser.gesture.pinch. and disable?
<bdmurray> Sarvatt: my question was what other things can I do with my 2 fingers
<bdmurray> about:config is neat though and shows some stuff
<Sarvatt> note: i dont even know if that stuff works, was a long shot :)
<RAOF> Yeah - Firefox won't have multitouch integration yet, surely?
 * bryceh waves to RAOF 
<RAOF> Good morning bryce :)
<bryceh> bdmurray, hey you may  have already noticed, but I stuck in a greasemonkey script which makes the launchpad OOPS id's into hyperlinks to the +filebug page (with the oops id)
<bdmurray> bryceh: I didn't look closely but that sounds like fun
<bryceh> bdmurray, and I tested out your changes to buttontags, nice... works more quickly
<bdmurray> bryceh: oh yeah that was pretty slick it uses the lp api via javascript
<bdmurray> bryceh: the only chagne I saw / see was send_upstream
<bdmurray> and a message about revisions being removed
<bryceh> ah, stuck it in my branch not the trunk, one sec
<bdmurray> bryceh: Did some revisions disappear because I'm on 171
<bryceh> bdmurray, probably just bzr's merge wonkiness at work
<bryceh> bdmurray, maybe try cloning a copy of the tree and doublechecking?
<bdmurray> well I see my last change still in code browse so it seems fine
<RAOF> Ok.  Who just killed my X server?
<RAOF> Ah, CloseDownClient, my old nemesis.
#ubuntu-x 2011-10-06
<bryceh> 'precise' is going to be a pain for googling purposes
<RAOF> This is true.
<Sarvatt> bryceh: yeah precocious pufferfish would be so much easier :(
<bryceh> heya Sarvatt
<Sarvatt> heyo!
#ubuntu-x 2011-10-07
<Sarvatt> anyone slightly more sober than me willing to upload the 6 libpciaccess rdeps to a PPA with libpciaccess 0.12.1-2 from ubuntu-x-swat/ppa to ensure they dont break the builds and comment to that effect in https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/864123 so accelerated GL is available to wine when using open source drivers in 11.10?
<ubot4> Launchpad bug 864123 in libpciaccess (Ubuntu) "libpciaccess0:386 is uninstallable on amd64 (affects: 4) (heat: 20)" [Undecided,Confirmed]
<bjsnider> i can do that tomorrow possibly. i've got a testing ppa laying around. too late tonight
<Sarvatt> bjsnider: apparently its tonight or not ever, I think the the wine maintainer is doing it though but if not i'll do it first thing in the morning just in case
<xranby> hi are there a easy way to check the refresh reate for a vga connected monitor.. ?  im having some terrible user interface experience when testing the arm-imx5 oneiric images
<xranby> the feeling are really.. odd   while the pointer flies and updates so fast like its on fire...  any event you send to the gui mouyse click takes about 7sec to be recieved
<xranby> andwhen the 7 seconds pass a blimp of snappyness occours  gui gets instantly updated and then it takes some seconds for next event to get processed
<xranby> running gnome-system-monitor alone consumes about 30-80% of cpu time
<xranby> when it are refrehing the gui
<xranby> so i start to suspect that its .. refreshing and redrawing too fast?
<xranby> since the mousepointer are hyperactive
<xranby> other arm boards behave ok
<xranby> so this are imx53 image specific
<bjsnider> i think if you just type xrandr at the console it will give you a bunch of info
<xranby> bjsnider: http://paste.ubuntu.com/704070/    
<xranby> looks to me that its refreshing at 60hz
<xranby> can this cause any trouble ? xrandr: Failed to get size of gamma for output default
<xranby> what do the star after 60 mean ?   (60*)
<bjsnider> i think that denotes what the current refresh rate is
<bjsnider> but i don't use xrandr much because i'm on nvidia, so i'm not an expert on that
<xranby> ok
<xranby> here the gpu are integrated into the cpu
<xranby> so all i know about the gpu are that its the imx53 chips built in gpu 
<xranby> i found  some specs   it contains  OpenGL ES 2.0 3D accelerator (AMD Z430)   OpenVG1.1 graphics accelerator (AMD Z160)
<xranby> the gpu are capable of 200Mpix/s
<xranby> this gpu also goes under the name of adreno 200
#ubuntu-x 2011-10-08
<bjsnider> Sarvatt, does x-updates still have any kind of relevance in oneiric?
<bryceh> bjsnider, it won't until oneiric is released
<raevol> hey all
<raevol> i just ppa-purged xorg-edgers, restarted, and then tried to install fglrx, and now my X won't start
<raevol> any advice?
<bryceh> uninstall fglrx
<raevol> how would i do that from the command line :(
<raevol> well i got my oeneric beta downloaded so i'll just install that
<raevol> here's hoping oeneric fglrx isn't toast :)
<bryceh> man jockey-text
<RAOF> xranby: Arm stuff is generally moderately weird; I'm not sure to what extent it actually *supports* xrandr, so the output of that tool might not be trustworthy.
#ubuntu-x 2011-10-09
<fictional> would anyone know what coltrols the window decoration/resolution/drawing?
<JanC> fictional: the window manager?
<fictional> yes
<fictional> im trying to determine where im haveing an issues at
<fictional> imtring to run a game that worked fine bfore an upgrade the issue im haveing is with wine/vmbox/nvidia
<fictional> the issue is ic an run the game fine in lower resolutions under wine and vmbox
<fictional> but when i go to change resolutions in game or maximize the window the game still runs but odnt  draw the picture just black it goes along with a bug of the white windows i can link
<JanC> that sounds like a bug in the graphics driver (or maybe in compiz?)
<fictional> i uninstalled compiz and tried different drivers from nvidia
<fictional> i was thinking of updated to gnome 3 but dunno if it would help
<fictional> i can link you the bug with the white windows if you like to get a better idea
<JanC> if it doesn't work with a "plain" window manager like Metacity, I doubt it will work in gnome shell...
<fictional> i thinkt he white window is still happening in ubuntu no effects just slightly different
<JanC> fictional: it's unlikely I will be able to help
<fictional> what is plain window manager?
<JanC> maybe wait until some of the experts are around  âº
<JanC> fictional: I mean something that doesn't do compositing & 3D effects
<fictional> do you know how i get it to metacity?
<JanC> if there is no compiz, it should use that by default, I suppose?
<Q-FUNK> on -intel, I randomly get some windows' left-side clipped by about one console character's width, in gnome 3, on Oneiric.  is this a known issue?
#ubuntu-x 2012-10-01
<Sarvatt> ehoover: no need, googling it turned up the wine bug, easy test case attached there :)
<Sarvatt> http://bugs.winehq.org/show_bug.cgi?id=31406
<ubottu> bugs.winehq.org bug 31406 in directx-d3d "Borderlands freezes in game when items details are displayed" [Normal,Resolved: upstream]
<ehoover> Awesome, do you guys need anything else from me?
<Sarvatt> nope! thanks again for that
<ehoover> No, thank you guys so much for looking into it!
<mlankhorst> morning
<tjaalton> yo
<mlankhorst> ok q-lts-backport updated to recent stack :p
<mlankhorst> I think armhf would work too, but there was some fun interaction between the ti-omap ppa that will prevent it from working for now
<tjaalton> x11-xserver-utils with xrandr snapshot uploaded
<mlankhorst> needs a custom xorg-server + updated EGL binaries
<tjaalton> heh
<mlankhorst> which is about good enough to upload it to q-lts-backport I suppose, needs some solution for libgl1 though
<mlankhorst> is it ok if I make people specify the solution manually for now?
<tjaalton> what do you mean?
<tjaalton> for arm?
<mlankhorst> seems to require apt-get install xserver-xorg-lts-quantal libgl1-mesa-glx-lts-quantal for now, else it removes a bunch of stuff
<mlankhorst> but that was testing on arm, which doesn't use libgl
<mlankhorst> I think I found the solution though if the abi requires different packaging in fglrx
<mlankhorst> if there are conflicting packages they are simply deleted, and only added back if another package explicitly requires it
<mlankhorst> tjaalton: should we upload qxl/r128/mga to satisfy those with ocd in http://people.canonical.com/~platform/desktop/versions.html ?
<tjaalton> ocd?
<mlankhorst> obsessive compulsive
<tjaalton> ah
<tjaalton> -qxl needs newer spice
<tjaalton> dunno if it's in yet, there's a ffe for it
<mlankhorst> ah
<tjaalton> hmm, so -qxl will be an issue
<tjaalton> should probably drop it from -video-all for the backports
<tjaalton> or backport spice too..
<popey> is there an alternative to xrestop? it seems there's a bug in it upstream which causes it to kill x when you run it. https://bugzilla.redhat.com/show_bug.cgi?id=851885
<ubottu> bugzilla.redhat.com bug 851885 in xorg-x11-server "xrestop crashes X" [Unspecified,New]
<mlankhorst> tjaalton: I thought it was only a build-depends, though..
<tjaalton> mlankhorst: how do you satisfy the b-dep without providing the binaries?
<tjaalton> api changed
<jcristau> popey: if xrestop crashes X that can't possibly be a bug in xrestop.
<popey> jcristau, ok, noted :)
<tjaalton> popey: yeah, please file it against the xserver
<tjaalton> -r128 6.9.1 uploaded
<tjaalton> and -mga 1.6.2
<mlankhorst> yay
<popey> ok tjaalton 
<mlankhorst> tjaalton: we could just drop qxl for the backport, it's meant for new hardware enablement so no point in porting it
<tjaalton> mlankhorst: yeah
<mlankhorst> https://launchpadlibrarian.net/107849042/Stacktrace.txt oh fun
<mlankhorst> RAOF: ping?
<tjaalton> where's that from?
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1014419
<ubottu> Launchpad bug 1014419 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in FreeGrab()" [Medium,New]
<tjaalton> that's kinda old
<mlankhorst> oh :p
<tjaalton> i mean, we've gone via 1.12 to 1.13 now :)
<mlankhorst> yeah
<mlankhorst> but was looking at it because the backtrace was interesting and something that could theoretically still happen
<mlankhorst> not sure if -core would help here
<mlankhorst> oh another bug valgrind found in intel *sigh*
<tjaalton> impossible :)
<mlankhorst> tjaalton: can you upload intel?
<tjaalton> mlankhorst: yup, done
<mlankhorst> thanks
<mlankhorst> ok seems xorg-server is clean now on my intel system, *tries ati*
<tjaalton> valgrind-wise?
<mlankhorst> yeah just a lot of scary warnings from ioctl's
<mlankhorst> maybe I should add some valgrind annotations to libdrm, so it will shut up about the ioctl's
<mlankhorst> nouveau seems ok too
<mlankhorst> argh just as I give it a all clear ati decides to crash on me, evil ati :(
<ehoover> Sarvatt: There's a testcase for bug 1059276 that just used XCB directly, would you like me to update the description to link to that instead?
<ubottu> Launchpad bug 1059276 in libxcb (Ubuntu) "Wine locks up when running multithreaded applications that touch both OpenGL and X11" [Medium,Triaged] https://launchpad.net/bugs/1059276
<Sarvatt> did i enable the patch system properly in https://launchpadlibrarian.net/118032526/libxcb_1.8.1-1ubuntu1.debdiff ?
<Sarvatt> ehoover: yeah can ya just add that one too?
<ehoover> Sarvatt: I don't know what you're asking (sorry, was down in the lab).
<Sarvatt> ya said you had a testcase that uses xcb directly?
<jcristau> Sarvatt: there's one attached to https://bugs.freedesktop.org/show_bug.cgi?id=54671
<ubottu> Freedesktop bug 54671 in Library "Wine locks up when running multithreaded applications that touch both OpenGL and X11" [Normal,Resolved: fixed]
<ehoover> Yeah, I've just finished adding the XCB test case to the description.
<ehoover> I meant the "did i enable the patch system properly"?
<ehoover> Sarvatt: oops, it looks like I might have overriden your description changes.
<Sarvatt> no biggie, had them saved
<bryceh> Sarvatt, on bug 1059276, need sponsorship?
<ubottu> Launchpad bug 1059276 in libxcb (Ubuntu) "Wine locks up when running multithreaded applications that touch both OpenGL and X11" [Medium,Triaged] https://launchpad.net/bugs/1059276
<Sarvatt> bryceh: would be much appreciated, but the ppa finally finished publishing so i'm about to try it out now first to be sure it fixes the test cases
<Sarvatt> had to use a ppa because its a pain in the butt building those for both arches :P
<bryceh> Sarvatt, okie doke.  Ping me if/when you're ready for uploads
<Sarvatt> these humble games make me desperately want delta debs :)
<Sarvatt> redownloading 2gb just for a package dependency change is a PITA
<mlankhorst> heya
<Sarvatt> bryceh: both test cases pass, ship it!
<Sarvatt> mlankhorst: it's nuts how much you play that game :)
<mlankhorst> Sarvatt: doing it with a friend, not alone
<mlankhorst> helping him test the mod he's writing for a school project
<Sarvatt> oh only 148 hours.. seems like every time i log in you're in it :) RAOF has you beat in civ 5!
<mlankhorst> if it was alone I would have been long bored with it
<mlankhorst> Sarvatt: because you log in when I play :p
<mlankhorst> and it's evening here lol
<Sarvatt> mlankhorst: wow, 31 days playing TF2. you are the winner :)
<mlankhorst> haha
<mlankhorst> Sarvatt: and that's only after it started recording..
<mlankhorst> but I have a live now, I think
<Azelphur> pfft, 31 days is nothing
<Azelphur> http://steamcommunity.com/id/Azelphur/
<Sarvatt> holy crap :)
<Azelphur> xD
<mlankhorst> it's not world of warcraft o.O
<Azelphur> I been there and done that with WoW too :D
<Azelphur> but nah, most of my TF2 time is idling, since you can get free stuff just by going afk haha
<mlankhorst> nothing to be proud of, more ashamed of
<Azelphur> haha
<Azelphur> obviously havn't played TF2 for 6000+ hours, xD
<mlankhorst> you do realize you only get a fixed amount of items per week right?
<Azelphur> you do now, you didn't originally
<Azelphur> which is where I built up about 4500 of those 6000 hours xD
<mlankhorst> oh right, bet you don't have cheater's lament, then
<Azelphur> amusingly, I do
<mlankhorst> aw
<Azelphur> and I cheated
<mlankhorst> I hate you
<Azelphur> haha
<Azelphur> mlankhorst: if your into items, check out page 6 http://tf2items.com/id/azelphur
<mlankhorst> I don't care about that :p
<Azelphur> hehe
<Azelphur> I do it all under wine too, btw \o/
<bryceh> Sarvatt, the ppa packages are identical to the debdiffs, other than the version number (and precise-proposed)?
<bryceh> yep looks like
<bryceh> Sarvatt, upload sponsored
<Sarvatt> bryceh: yep sure are, thank you for that! I didn't want to harass you guys so just subscribed sponsors
<bryceh> Sarvatt, no prob, was in the mood to upload something ;-)
<bryceh> well, actually, I'm thrilled to see our graph going down at this stage in the release (this hasn't happened before afaik!)  http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-quantal-workqueue.svg
<mlankhorst> nouveau's likely going to stay open though
<mlankhorst> :(
<mlankhorst> but yeah I tried valgrinding some, it really does help finding some bugs proactively
<bryceh> mlankhorst, to get them off this graph it's sufficient to simply get them forwarded upstream
<mlankhorst> ah
<bryceh> bugs that have open upstream bug tasks are excluded from the count
<bryceh> (the graph is trying to only count "bugs we can actually do some action on")
<mlankhorst> bryceh: I mean more in finding bugs early also means there's not going to be bug reports about them
<mlankhorst> having valgrind and all the -dbg symbols for easy local backtracing does help a lot
<Sarvatt> wow, and i haven't even been looking at many public bugs this cycle because we're swimming in so many private ones
<bryceh> also, if bug reports don't make sense, setting them to incomplete with a question to the reporter also excludes them from the list
<mlankhorst> ah k
<mlankhorst> but for nouveau, what's the point of doing bug reports if upstream won't look at it :-(
<bryceh> mlankhorst, Sarvatt yeah there's been a lot less bug filing this cycle, which is either great news, or means all our users are sticking to 12.04 ;-)
<mlankhorst> HEY! I'm on 12.04!!
<Sarvatt> hell I stuck to 12.04 until 2-3 weeks ago :)
<bryceh> that's two data points to proving the latter!
<bryceh> actually three, I'm on 12.04 too (since the valve stuff targets 12.04)
<mlankhorst> bryceh: but in my case it's since I need to keep testing the X stack, and I'm actually on quantal for stuff that matters..
<tjaalton> i have only my main desktop still on 12.04, and probably will update to the backport stack at some point
<bryceh> mlankhorst, yup.  it's awesome how much more serious attention we're all putting on 12.04.  I thought 10.04 got a lot of post-release attention but it was nothing like we're doing with 12.04
<mlankhorst> well I want things to just work, I did actually hit that synaptics suspend bug on my laptop at one point
<bryceh> mlankhorst, if -nouveau is complete fubar, what's going to happen when that gets backported to 12.04 via your lts stack?
<bryceh> some of those nouveau bugs may be dupes, like all the screen corruption issues
<mlankhorst> bryceh: well people don't HAVE to use the new stuff, so if they don't things stay the same
<Sarvatt> ugh libxcb-util soname bump, thats going to need a lot of rebuilds next cycle
<jcristau> again?
<Sarvatt> back in may
<jcristau> ah
<jcristau> meh, it has like 3 rdeps
<Sarvatt> oh thought it was more for some reason, intel driver at least
<jcristau> or am i thinking of something else
<jcristau> hmm
<jcristau> yeah i think i'm just confused
<Sarvatt> util-wm had a bunch of obscure window managers i had to rebuild in edgers last time, that got a bump too
<mlankhorst> bryceh: yeah probably although it depends if their cards are simialr enough or not :-)
<mlankhorst> closed one more bug, muaha
<bryceh> mlankhorst, tomorrow would you mind browsing through them and duping whichever ones do look similar?
<mlankhorst> sure
<bryceh> awesome, thanks
<jcristau> Sarvatt: ah right xcb-util was deferred in june because of the upcoming wheezy freeze back then
<jcristau> hrm
<jcristau> looks like the soname bump was avoidable...
<mlankhorst> omap one closed too, seemed to have been invalid :p
<mlankhorst> bryceh: are you not tracking geode or is there no bug for it?
<bryceh> mlankhorst, hmm, thought we were tracking that, no reason not to.  lemme check
<tjaalton> no bugs on quantal
<tjaalton> for geode
<mlankhorst> I'm fairly sure the fix I did just leaves it working on a compile level only, so it's probably more evidence nobody is using it
<mlankhorst> either that or the fix did work
<bryceh> yes we are tracking it, just no quantal bugs like tjaalton says
<tjaalton> the maintainer was pinging me some time ago, wanted to sync some cleanup version so I guess it works as is
<bryceh> the type of user for geode is unlikely to care about non-lts releases.  And actually might be they all just stick with 10.04 or something home built.  It's rather appliance-ish
<tjaalton> oh we could sync 2.11.13-6
<mlankhorst> tjaalton: ah :-)
<bryceh> tjaalton, wasn't there an exa update or something for it?
<tjaalton> bryceh: not sure
<tjaalton> and actually, our version is newer than on debian, so can't sync it
<tjaalton> remember telling him that..
<Sarvatt> err, noone can even use geode on 12.10 can they since its PAE only?
<mlankhorst> quite possibly
<tjaalton> you can't install it
<tjaalton> :)
 * Sarvatt looks it up
<tjaalton> he keeps syncing from git but doesn't touch the upstream version, so meh
<Sarvatt> not seeing any geodes that support PAE and 12.04 was the last release with a non PAE kernel so.. yeah
<mlankhorst> can we drop it from main then?
<tjaalton> and -video-all
<tjaalton> same thing
<mlankhorst> yeah :p
 * mlankhorst prepares salutory parting shot
<mlankhorst> cirrus too? should be using modesetting driver by now
<tjaalton> is it?
<Sarvatt> mlankhorst: they just disabled the cirrus drm driver
<bryceh> I think I have one of the geodes in some drawer somewhere, if anyone wants it.  has to be booted via PXE
<stgraber> hmm, most geodes won't boot anyway
<Sarvatt> -modesetting wasn't working as good as -cirrus or something
<stgraber> they died when we started being pure i686
<mlankhorst> Sarvatt: sigh, ok
<stgraber> except for some Geode LX that are i686 and may still boot
<mlankhorst> geode lx should work, using shadowfb
<mlankhorst> earlier actually had hardware acceleration and won't work for sure
<mlankhorst> ok pushed the commit for xorg to kill off geode, can anyone upload it?
<mlankhorst> and bed
<mlankhorst> night all :-)
<tjaalton> same
 * mlankhorst steals bryceh's steam key
<bryceh> heh
<Prf_Jakob> So who do I need to buy a beer/whiskey to get into the Steam beta? :-)
<mlankhorst> well make hellstrom come to uds :p
<Prf_Jakob> 3 kids of which two are ~1 year old twins makes that unlikely :-/
<Prf_Jakob> Where is it btw?
<mlankhorst> copenhagen
<Prf_Jakob> Oh thats actually close.
<Prf_Jakob> Send him a email
<Prf_Jakob> ~4h car ride
<mlankhorst> i will
<Prf_Jakob> I will try and make it as well
<Prf_Jakob> Even tho I'm on leave from VMware right now.
<Sarvatt> worst part about not going to UDS in copenhagen - finding out valve will be there the week after you realize you can't go :(
<mlankhorst> cant you pay extra to get passport done sooner? :p
<mlankhorst> here you can get it in the next day instead of next week if you pay some extra
<Sarvatt> mlankhorst: i already mailed mine off, i coulda got it done the same day for money if i realized it would take 1.5 months through the mail :(
<Sarvatt> yeah i live right outside of dc where the passports are made, i got my last one 10 years ago done the same day, tried to save $100 this time, big mistake
<Prf_Jakob> Is UDS invite only btw?
<Sarvatt> nope
<Sarvatt> invite only if you are expecting it to be sponsored and paid for by canonical
<Prf_Jakob> Ah ok
<RAOF> Everyone else is welcome to rock up!
<Prf_Jakob> 3:46h train ride for $50 (one way).
<RAOF> Damn Europeans and their awesome transit systems.
<Sarvatt> I know right..
<Prf_Jakob> Also not that far away...
<Sarvatt> hotel will probably be nuts though
<mlankhorst> pssh sleep on t he conference floor or party all night with caffein :p
<Prf_Jakob> $957 for the whole thing.
<mlankhorst> so you don't need any food? >:-)
<Sarvatt> Prf_Jakob: UDS discount rates?
<Sarvatt> UDS includes breakfast and dinner
<Prf_Jakob> Sarvatt: yes
<Sarvatt> err lunch
<Sarvatt> just not dinner
<Prf_Jakob> $957 for the hotel.
<Prf_Jakob> According to XE.com
<Sarvatt> oh was hoping you could save more by using the discount rate, they almost always have one
<Prf_Jakob> Well thats for what 5nights.
<RAOF> So you can visit Legoland!
<Prf_Jakob> Haha
<mlankhorst> RAOF: do you have a roomie yet?
<RAOF> mlankhorst: I don't think so, no.
<mlankhorst> want one?
 * RAOF is just trying to find the wiki page to see if he has one already :)
<Prf_Jakob> mlankhorst: You might need start working on sponsering Thomas btw, I'm not sure we have started a new budget quarter yet.
<mlankhorst> https://wiki.canonical.com/UbuntuEngineering/UDS/R/PeopleName
<Sarvatt> Prf_Jakob: its too late afaik :(
<Prf_Jakob> Sarvatt: oh okay :-/
<RAOF> Currently getting the lucky dip roomie!
<Sarvatt> dip roomie?
<mlankhorst> panda died on me! argh
<mlankhorst> back
<Sarvatt> mlankhorst: get a laptop for use in your bed, argh :)
<mlankhorst> haha
<mlankhorst> i'll take the eee one again
<mlankhorst> but leave it in my room :P
<bryceh> wb RAOF 
<Sarvatt> mlankhorst: why are you up at 1:34? :P
<RAOF> Three day weekends are pretty good :)
<RAOF> Pity I don't have enough leave to make every weekend a 3-day weekend :)
<Sarvatt> RAOF: .au holiday?
<RAOF> Sarvatt: Using up my leave.
<Sarvatt> oh gotcha :)
<bryceh> RAOF, btw you may want to read the TB irc log from today; I got some clarifications on what you can do vis a vis all the nvidia experimental stuff.  tl;dr TB considers you empowered to handle all the approvals for getting into -precise
<RAOF> bryceh: Excellent. Will look into them.
<Sarvatt> RAOF grew superpowers while on vacation :)
<RAOF> Maybe next Monday I'll grow more!
 * RAOF has taken Mondays off for pretty much the rest of the year.
<bryceh> RAOF, also I jotted down my understanding of all the process steps for this at https://wiki.ubuntu.com/X/DriverUpdates with links to the TB discussions.
<mlankhorst> oh speaking of which we need to sru llvm-3.1 to precise too :p
<bryceh> actually they decided no new powers, just implied powers gained from the previous TB :-)
<Sarvatt> RAOF: thats US sundays so noone in the US will notice :)
<RAOF> mlankhorst: For the purposes of backportage?
<mlankhorst> yeah and new wayland
<RAOF> That's going to start getting nasty.
<mlankhorst> it's actually a clean standalone package so not that hard
<mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+packages is cleaned up mostly
<RAOF> Wayland could get nasty should something actually start using it :)
<bryceh> quite
<mlankhorst> RAOF: at that point the api is presumably stable enough to build mesa with
<RAOF> That would indeed be the hope, yes.
<mlankhorst> worst case we rename it but things can only improve by putting in a new wayland
#ubuntu-x 2012-10-02
<mlankhorst> other than that xorg needed a change to add some conflicts so you don't mix parts of the stack, some x11proto-* neeeded updates, and xrandr sru'd. that's all acceptable right?
<Sarvatt> xrandr is easy, renamed package would be ok that has no dependencies, protos on the other hand..
<Sarvatt> libxcb soname changes will be fun for 13.04 backports :)
<mlankhorst> Sarvatt: no point, it's not going to break anything existing
<RAOF> I thought we were just going to sru the x11proto-*?
<bjsnider> a lot of stuff links to xcb
<mlankhorst> RAOF: yeah this is just the list
<bjsnider> i think vlc does
<Sarvatt> hopefully xserver 1.7 never happens again when all the libs and protos need updates
<mlankhorst> eg what's currently in https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+packages
<mlankhorst> I think it makes sense to keep it as it is now with this set of renamed/unrenamed packages + xrandr
<bryceh> RAOF, when you get a moment can you approve nvidia-common and jockey from the upload queue?  it's getting towards EOD for me today, but I'd like to get cracking on testing first thing tomorrow morning.
<RAOF> bryceh: Certainly. I don't like writing this email, anyway :)
<bryceh> thanks
<RAOF> bryceh: What bug is the nvidia-common upload fixing?
<RAOF> bryceh: The changelog suggests https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/976779 , but that's clearly wrong.
<ubottu> Launchpad bug 976779 in nvidia-common (Ubuntu Precise) "hybrid-detect changes file in /usr" [Undecided,Fix committed]
<bryceh> yeah typo'd that.  The correct bug # is 1047681 for both packages
<RAOF> bryceh: Ok, I've rejected both nvidia-common and jockey; please re-upload with the right bug reference (jockey didn't seem to have any bug reference at all). Ta.
<RAOF> bryceh: And could you also get the changes file to include the changelog for the nvidia-common upload currently in precise-proposed, too?
<bryceh> ok, kick out the nvidia-common I just uploaded
<RAOF> Sorry for the delay there :/
<bryceh> RAOF, ok new packages up
<RAOF> Dear launchpad: FASTER!
<RAOF> bryceh: Done. Enjoy!
<bryceh> RAOF, thanks!!
<tjaalton> ooh, multitouch support for wacom
<tjaalton> intuos5 becomes useful :)
<mlankhorst> yay
<mlankhorst> sigh so many people trying nomodeset as a workaround, it doesn't do what they think :(
<RAOF> It does work around their graphics working :)
<mlankhorst> So if I want to register a blueprint for r, would that be kernel-r-dma-buf-synchronization ?
<mlankhorst> shrug ill try
<tjaalton> mlankhorst: sounds about right (the spec)
<mlankhorst> yeah it's pretty much 'if you dont know what it it's for, you likely don't want to come' things
<tjaalton> the geode maintainer agreed to drop the driver feom video-all
<mlankhorst> ah k, upload? :D
<tjaalton> so no need to backport it
<tjaalton> *from
<tjaalton> yeah, i'll upload it a bit later
<mlankhorst> so many different nouveau bugs unique in their own way, sigh :(
<tjaalton> mlankhorst: xorg accepted
<mlankhorst> yay
<tjaalton> meh, no haswell dp/edp for 3.7
<mlankhorst> yeah I know
<mlankhorst> oh wait did we have plans to backport that?
<tjaalton> depends
<mlankhorst> going to be fun with the modeset rework
<Sarvatt> mlankhorst: i wonder if it would make sense to just SRU the -lts packages as something like ubuntu-desktop-q in a SRU to the ubuntu-desktop metapackage
<mlankhorst> Sarvatt: well I intend to make xorg-server-lts-quantal the package for now
<mlankhorst> add a recommends on linux-lts-quantal and a depends on libgl1 is probably enough
<bryceh> tjaalton, happy b-day
<Hanmac> hay i got problem messages like "[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !" 
<Hanmac> there is my pastie: http://pastebin.com/E8491jBM an friend says that IRQ may be broken ... 
<Hanmac> my versions are: http://pastebin.com/Cf9Mpch1
<bryceh> anyone with an nvidia card mind testing something for me?
<bryceh> enable precise-proposed, update, and then upgrade jockey-common jockey-gtk and nvidia-common.
<bryceh> then run jockey-gtk and verify that it gives the option to install an experimental nvidia driver (should be the last in the list)
<bryceh> you don't have to actually install the driver (it's actually the same as nvidia-updates right now), but if you do install it and hit problems let me know.
 * Hanmac hopes someday about an fglrx-legacy driver :(
<bryceh> oh btw I've  tested this on my own hardware, just looking for a second independent confirmation
<bryceh> 'tis done
<bryceh> RAOF, LP #1047681 ready for you to take a look at.  There's one caveat I've mentioned that I'd appreciate your thoughts on, but other than that it looks good and is ready to go.
<ubottu> Launchpad bug 1047681 in jockey (Ubuntu Quantal) "Add package nvidia-experimental for tracking nvidia beta drivers" [Wishlist,In progress] https://launchpad.net/bugs/1047681
<RAOF> bryceh: What is the failure-mode of the current jockey?
<bryceh> standard python gui crash, ending in error message that it can't convert 'experimental-304' to an int
<RAOF> Hurray!
<RAOF> Hm.
<bryceh> on the plus side, apport has no trouble catching it ;-)
<RAOF> Heh.
<bryceh> RAOF, so... think that crash is worth worrying about?  Anything we can do to prevent it?
<Sarvatt> should we do a new mesa checkout or is friday for the final 9.0 going to be ok?
#ubuntu-x 2012-10-03
<bryceh> having a new checkout could only help, I should think?
<RAOF> bryceh: Maybe give jockey & nvidia-common a bit of time to percolate out first.
<bryceh> RAOF, *nod*
<bryceh> hey, a few weeks ago I mentioned the idea of providing mesa updates (for Intel graphics) through the x-updates PPA.  At the time there were some concerns raised.  Sarvatt I think you demurred about having mesa and libdrm updates in there for proprietary driver users that might not need it.
<bryceh> I'd like to open discussion on this again.  We have driver updates for Intel (needed by certain games) which include mesa, i915 (via dkms), cairo, wayland, and the ddx.
<bryceh> currently we're staging them in dedicated ppas but I'm thinking that being able to point to a single ppa for updates would be simpler to communicate to folks.
<bryceh> would love to hear feedback.  Dinner calls, so will be back later tonight.
<Sarvatt> bryceh: i915 via dkms is a lofty goal but wont happen, they end up touching intel_agp every kernel version and thats built in so can't be a module you can just dkms to get the updates.. back when I had an objection it was because blobs ended up needing the newer libdrm but thats not the case for the last few releases, no problems with it anymore :P cairo is kind of sketchy because it broke all EXA drivers for a long time in 1.12 even though intel wa
<Sarvatt> s fine, but there is more in the world than just intel.. if it's reenabling accelerated gradients they want in there thats fine, everything should be ok now but it wasn't until after feature freeze so we're stuck with that in 12.10's cairo
<Sarvatt> if they want cairo 1.12 in precise for there it's going to break nouveau and ati at the very least and need updates of those too, not that thats a big of a deal
<Sarvatt> lts backports might be more appropriate though
<bryceh> https://launchpad.net/~ubuntu-x-swat/+archive/intel-graphics-updates/+packages is one of the ppas.  mesa9's the other.
<bryceh> Sarvatt, the i915 dkms package is included there if you want to tease it apart and see what they're touching
<RAOF> Sarvatt: The idea here is the x-updates PPA, right? If they want the new cairo, we can just include the new nouveau & ati, right?
<Sarvatt> yeah will be interesting to see how it works considering intel_agp wont bind to any of our haswell systems so i915 won't work and that part can't be modular
<RAOF> Yeah, that's moderately annoying :)
<bryceh> I figure it'd be pointless for nouveau and ati folks to install x-updates if we didn't put the new bits there...  ;-)
<Sarvatt> RAOF: yeah updating those is no big deal, just something that wouldn't be considered we'd have to watch out for :P
<tjaalton> bryceh: thanks!
<tjaalton> marked desktop-q-hybrid-graphics as implemented
<tjaalton> xrandr snapshot got in earlier
<tjaalton> mesa snapshot? ok then
<tjaalton> oh this time the 9.0 branch has actually changed
<tjaalton> 63 commits, not bad
<RAOF> tjaalton: Thinking of hybrid graphics - do they work for you with the recent unity?
<tjaalton> RAOF: work in which way?
<RAOF> Get rendering
<tjaalton> the radeon fixing patch actually broke it here, nouveau throws in the towel
<tjaalton> but it's a good tradeoff I think :)
<tjaalton> mentioned it to airlied back then, but haven't had time to look closer
<tjaalton> but I'll give it a go to see where it's at
<RAOF> Civ V no longer does any rendering with DRI_PRIME set, but only under Unity.
<tjaalton> ah
<tjaalton> I've only tested it so far that glxgears hangs the machine after a few seconds :)
<tjaalton> told that it's to be expected
<RAOF> Awesome.
<RAOF> Civ V works under metacity.
<RAOF> ...I *think* I verified that it's actually using r600 there.
<RAOF> But there's something odd happening, 'cause glxgears -fullscreen works just fine.
<mlankhorst> hey
<mlankhorst> RAOF: well if rendering takes too long intel will show the frame before it finished drawing
<mlankhorst> what if you turn off vsync?
<Hanmac> my radeon driver keeps crashing with  "irq 18: nobody cared (try booting with the "irqpoll" option)" ... someone an idea to fix that?
<mlankhorst> whats on irq 18 in /proc/interrupts?
<Hanmac>  18:          0          1        197      70917   IO-APIC-fasteoi   ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, radeon
<Hanmac> before i get the irq error i also get this:
<Hanmac> [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8500)=0xCAFEDEAD)
<Hanmac> [drm:r600_resume] *ERROR* r600 startup failed on resume
<Hanmac> mlankhorst is this an software problem or iam the problem? :( .... or have you an idea to fix that?
<mlankhorst> oh so it crashes during resume?
<Hanmac> not that i knew ... i am working on something, and than the output goes gray or stripes sometimes i still see a square where the mouse was sometimes i see it not, if i see the square i can move it but its damm slow, and if i click it chanes nothing on the output ... and tty1-tty6 has the same stripes too
<Hanmac> it may even happen before i could login oO
<Hanmac> the only known solution is to goto tty1 and try to reboot with typing blind
<mlankhorst> is that really the only thing in the log?
<mlankhorst> and precise or quantal?
<Hanmac> quantal http://pastebin.com/E8491jBM << part of the log, http://pastebin.com/Cf9Mpch1 << installed packages
<xclaesse> outch, cannot set more than 1024x768 on my external screen since latest ubuntu upgrade :/
<xclaesse>  xrandr does not list any higher resolution
<xclaesse> in logs I see this: [    17.229] (II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync
<tjaalton> "latest upgrade"=
<xclaesse> but nothing higher
<tjaalton> ?
<xclaesse> did apt-get dist-upgrade this morning, rebooted, and tadaaaamm :)
<tjaalton> so what changed?
<xclaesse> dunno what packages it upgraded exactly, but there were some x stsuff
<tjaalton> running edgers?
<mlankhorst> kernel update?
<xclaesse> yeah kernel as well, IIRC
<xclaesse> running Quantal
<xclaesse> Linux X230 3.5.0-16-generic #25-Ubuntu SMP Fri Sep 28 22:31:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<mlankhorst> Hanmac: is it like https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1043328  ?
<ubottu> Launchpad bug 1043328 in xserver-xorg-video-ati (Ubuntu) "corrupt screen both in terminal (KMS) and in X" [Undecided,New]
<tjaalton> xclaesse: does it work with -15?
<tjaalton> if yes, file a bug against the kernel
<xclaesse> tjaalton, let me reboot to try :)
<tjaalton> xclaesse: pastebin /var/log/dpkg.log if the older kernel doesn't work
<Hanmac> mlankhorst the curruption on my pc looks a bit different but similar enough ... thanks for pointing it
<mlankhorst> interesting tiling corruption :p
<xclaesse> tjaalton, actually I've got no other kernel installed
<mlankhorst> .. :/
<xclaesse> does ubuntu *finally* remove older kernels when upgrading instead of waiting for /boot to be full? 
<mlankhorst> it should keep at least the previous one though
<xclaesse> ok so maybe there just were no kernel updates since I installed
<xclaesse> made a clean install last weekend
<tjaalton> xclaesse: ls /boot
<tjaalton> ah
<tjaalton> install pastebinit and run 'pastebinit /var/log/dpkg.log' then
<mlankhorst> I'm going to see if I can get https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1044680 fixed at least
<ubottu> Launchpad bug 1044680 in xserver-xorg-video-ati (Ubuntu) "Xorg crashed with SIGABRT in radeon_get_pixmap_bo()" [Medium,Confirmed]
<xclaesse> tjaalton, /boot contains only -16 ;)
<xclaesse> tjaalton, http://paste.ubuntu.com/1257505/
<mlankhorst> tjaalton: pah, /lib/modules is a lot better indication anyway
<tjaalton> xclaesse: file a bug anyway, ubuntu-bug xorg
<mlankhorst> tjaalton: I'm fairly sure there might already be a bug about it :/
<mlankhorst> then again maybe not
<mlankhorst> oh my 570 is now partying too
<mlankhorst> 6570*
<tjaalton> I'm not going to ask the logfiles one at a time
<tjaalton> better to have them somewhere
<tjaalton> nothing suspicious on the upgrade log
<xclaesse> tjaalton, I never remember how to fill a bug in mp
<xclaesse> lp
<tjaalton> unless it's your valgrind fix that btoke it :P
<mlankhorst> I was testing my 6570, it seems to have done weird things
<tjaalton> xclaesse: I just told you
 * Hanmac is back from yetanother reboot
<xclaesse> ah, ubuntu-bug is a command...
<tjaalton> yep
<xclaesse> the "report a bug" link in lp is a trap
<mlankhorst> normally it's ok but for xorg we collect a whole bunch of logs so we don't have to ask for them
<xclaesse> tjaalton, I hope it included all you need: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1060808
<ubottu> Launchpad bug 1060808 in xorg (Ubuntu) "external monitor resolution cannot go above 1024x768" [Undecided,New]
<xclaesse> tjaalton, in the meantime, is it possible to "force" the screen resolution?
<tjaalton> xclaesse: maybe, not sure how
<tjaalton> xclaesse: is the external screen connected all the times?
<xclaesse> when I'm at office, yes :p
<tjaalton> try booting without it attached
<xclaesse> but it's a laptop on dock station
<tjaalton> there is bug 1049534 but you said it worked after the fresh install
<ubottu> Launchpad bug 1049534 in xserver-xorg-video-intel (Ubuntu) "[regression from 12.04] VGA Monitor uses reduced resolution" [Medium,Triaged] https://launchpad.net/bugs/1049534
<tjaalton> xclaesse: which installation image did you use?
<xclaesse> tjaalton, quantal daily live, last weekend
<xclaesse> was working perfectly yesterday
<Hanmac> mlankhorst: there is my curruption scene: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1043328/comments/5 ... looks similar right?
<ubottu> Launchpad bug 1043328 in xserver-xorg-video-ati (Ubuntu) "corrupt screen both in terminal (KMS) and in X" [Undecided,Confirmed]
<tjaalton> xclaesse: check the monitor configuration capplet
<xclaesse> tjaalton, aahh,  reboot without docking, then dock once logged worked!
<tjaalton> ok
<tjaalton> good to hear then
<xclaesse> but I'm 200% sure that booting while docked was working previously
<mlankhorst> http://pastebin.com/KPFAVvzr I think this might be that SIGABRT ati bug..
<Hanmac> ... hm i need to get the bug an higher Importance ... imo that the system crash multible times per day sounds like very critical ...
<mlankhorst> oh nm its a closescreen thing
<xclaesse> tjaalton, thanks for the help!
<xclaesse> commented on the bug that docking after being logged fixed it
<tjaalton> xclaesse: it's probably a dupe of the other bug, a race in the kernel dri driver
<mlankhorst> tjaalton: I'm going to update xxv-ati, might fix a bug
<tjaalton> mlankhorst: ok
<tjaalton> hmm, no vga capable monitors in the house anymore :/
<tjaalton> oh, forgot about the tv..
<mlankhorst> tjaalton: pushed
<tjaalton> oh, a new snapshot
<mlankhorst> yeah seemed to have a bunch of relevant fixes :)
<mlankhorst> oh nm
<mlankhorst> can skip it, it just removes mibstore.h
<tjaalton> right :)
<mlankhorst> you didn't update debian-experimental when you updated the snapshot :P
<tjaalton> meaning RAOF?
<mlankhorst> you as in whole ubuntu-x, but yeah raof it seems :)
<mlankhorst> could still upload it for the libdrm dependency fix but I don't think it is that important
<Hanmac> mlankhorst did you push the xxv-ati package changes? i very looking forward to it
<mlankhorst> I'll see if I can fix the crash in closescreen first
<tjaalton> xclaesse: is the display cloned when you boot docked?
<tjaalton> what happens here is that the displays are cloned when booting up with the external one attached
<tjaalton> and it'll use extended mode when plugging it in post-login
<tjaalton> not a driver bug
<tjaalton> hmm, guess it isn't cloned for you, if the laptop is using the native resolution
<xclaesse> tjaalton, it is cloned in boot splash and gdm, but not once logged
<tjaalton> xclaesse: ok
<Hanmac> mlankhorst sorry if i anoy you, but where do you publish the xxv-ati package? i want to look when its finish
<mlankhorst> Hanmac: no point, no real fix in it
<Hanmac> that makes me sad :'(
<tjaalton> you can try a newer mainline kernel
<Hanmac> tjaalton do you mean me?
<tjaalton> yes
<Hanmac> my linux image is 3.5.0.16.* ... is this new enough?
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<tjaalton> try 3.5.5
<tjaalton> need to install both -image and -image-extra
<Hanmac> yeah i know ... but where are the lowlatency packages? ... 
<tjaalton> nowhere
<tjaalton> it's mainline..
<tjaalton> you don't need fancy options for testing if your gfx work
<Hanmac> ok download them for testing ... the problem is that i cant provoke the bug ... (and someday i need the lowlatency features back ...)
<Hanmac1> tjaalton why do you think an new kernel could help with my problem?
<tjaalton> Hanmac: because that's where most of the magic is
<Hanmac> hm from my kern.log it looks that drm & radeon & r600  are the evil guys: https://launchpadlibrarian.net/118212480/kernlogpart.txt
<Hanmac> i downloaded an 3.5.5 and one 3.6.0 ... so i could test if some of them is working longer ...
<ricotz> Hanmac, the kernel contains the actual drivers -- and yes test those two
<tjaalton> 3.5.5 has "drm/radeon: make 64bit fences more robust v3"
<tjaalton> mlankhorst: is that what you're backporting?
<tjaalton> re #radeon
<ricotz> tjaalton, irc quantal master-next already contains 3.5.5 so i guess it will be out soon
<tjaalton> yep
<tjaalton> went through the drm changes in 3.5.5
<tjaalton> earlier today, it's a long list :)
<mlankhorst> tjaalton: yeah trying to see if v3.6 works
<ricotz> yeah
<mlankhorst> if that works I'll try to see if I can get it working on the 3.4 kernel
<mlankhorst> i think it should be similar to get working
<tjaalton> why 3.4?
<tjaalton> quantal has 3.5 :)
<mlankhorst> erm quantal kernel at least
<mlankhorst> oh right, my panda is on 3.4 :P
<Hanmac> i would not have this problem if fglrx did not drop my graphic card from the supported :(
<tjaalton> you should feel blessed
<mlankhorst> at least you're not seriously considering rewriting ttm
<mlankhorst> or at least rip the memory management out too
<Hanmac> my pc only need to suvive this month ... i will do an rebuild of the hard&soft-ware when the new CPU's are out ...
<mlankhorst> no idea what it's doing now, sigh!
<mlankhorst> oh right the depmod on first new kernel
<Hanmac> hm i get still "[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !" with the 3.5.5 but it seems not SO bad ... (i mean not so bad than output-curruption)
<mlankhorst> yeah it recovers from whatever causes it to hang up for me :/
<mlankhorst> but it's still hanging up
<Hanmac> hm if the 3.5.5 does not crash for me, when do i get the packages as ppa or in the default ubuntu repo? (ps and i would likeit if i get lowlatency packages too)
<tjaalton> -17 will have 3.5.5
<tjaalton> *will be based on 3.5.5
<Hanmac> what do you mean with "-17"? i dont get it ...
<tjaalton> 3.5.0-17, the official package
<tjaalton> meaning you'll get the usual flavours with it
<Hanmac> OH ok ... i dont care much about versionsnumbers ... i only wonder why its called "3.5.0-17" when its an "3.5.5" inside ... 
<tjaalton> dunno
<mlankhorst> wee bugs bugs bugs
<Hanmac1> 3.5.5 was no help for me :/
<mlankhorst> Hanmac1: Yeah I tested drm-next too, and filed a bug upstream
<Hanmac> can you give me a link to the upstream bug? so i can monitor it?
<tjaalton> mlankhorst: link it to the lp bug
<mlankhorst> I already did, both ways
<tjaalton> ah
<Hanmac> currently i am running 3.6 daily ... but i dont think this solv something
<mlankhorst> I tested drm-next, still broken there, so you will be out of luck by trying that..
<Hanmac> mlankhorst: about " shows SMALL pieces of horizontal corruption on plymouth and Xorg" i have some image made by mobile phone that could show LARGE pieces of corruption 
<Hanmac> https://launchpadlibrarian.net/118210933/IMG_20121003_102910.jpg << as you can see, you see nothing good :P
<mlankhorst> same thing
<Hanmac> hm I notice that the temperature. showing by sensors  is going higher in the moment is crashing ... 
<mlankhorst> no surprise there
<mlankhorst> that's usually the case with HCF commands
<mlankhorst> https://en.wikipedia.org/wiki/Halt_and_Catch_Fire
<Hanmac> "the CPU does not usually catch fire" ... until something is VERY wrong :D
<Hanmac> mlankhorst my graphic "card" is "ATI Radeon HD 3300 Graphics" so the error does not happen on "RadeonHD 6570" alone ..
<mlankhorst> weird, maybe different issue? my 5450 works fine
<Hanmac> sorry i dont know :/ maybe it picks the wrong radeon driver? is r600 for an "RadeonHD 3300" currect?
<mlankhorst> it's a rs780d if I may believe wikipedia
<mlankhorst> does precise work?
<Hanmac> precise had work because i used fglrx ... 
<mlankhorst> might be a different bug then
 * mlankhorst retries 5450 just to be sure
<mlankhorst> ugh erm 5450? i meant 5570, evil numbers :p
<Hanmac> hm i need to find the manual because google dont find anything when i type the mainboard name
<Hanmac> okay i dont know what grapic chip it is only "ATI Radeon HD 3300 Graphics" ... ps its onboard ... i found the mainboard name: dfi lp jr790gxm3h5
<mlankhorst> don't worry about that
<mlankhorst> try apport-bug xorg and file a new bug
<Hanmac> hm ps if you ask i should make a fresh install? yeah its planed for this month
<mlankhorst> its not windows, fresh install wont solve this problem
<Hanmac> mlankhorst there are other funny thinks wich confuses me ... like the panel calendar shows the wrong month-panel after clicking, and the automatic smart checking is for some reason not loaded (that means the disks gui says: smart is not enabled, but i could run smart manualy) ... the problems does or appear on the ubuntu live cd so i think it may be some config problem ... Â¿
<Hanmac> my system is upgraded since lnyx ... i think sometime an fresh install is useful 
<Hanmac> PS: @ mlankhorst there is my bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1060987
<ubottu> Launchpad bug 1060987 in xserver-xorg-video-ati (Ubuntu) "corrupt screen both in terminal (KMS) and in X with HD3300 " [Undecided,New]
<mlankhorst> thanks
<Hanmac> should I add my kern.log to the bug?
<mlankhorst> it's already attached that by opening the bug :)
<tjaalton> dmesg is, but it's not interesting from this boot
<mlankhorst> tjaalton: well yeah it needs to be from the corrupted one
<Hanmac> PS: you may be wonder but lightdm & wayland are installed but not used currenty ... 
<Hanmac> what may be more wonderable: for some reason gdm is still a bit broken, so currently i use kdm but still with gnome-classic
<bryceh> mesa 9 scheduled for next wed
<tjaalton> yeah and there's autotools stuff still pending
<tjaalton> started the merge but patch 118 needs an update
<mlankhorst> I'll get it working then
<tjaalton> pushed what I had
<Hanmac> ok 3.6.0daily is not save too but it was an different "bug" hm
<mlankhorst> well since 118 was supposed to fix build errors I'll try without first
<tjaalton> it won't work
<tjaalton> well, it'll have linking issues
<tjaalton> mattst88 posted a set of patches to fix various issues, but that was last week
<tjaalton> not merged there yet but apparently targeted for 9.0 too
<mlankhorst> ok I'll pick those, then
<tjaalton> patch 13/16 should be enough
<tjaalton> "automake patches for 9.0"
<bryceh> given that oct 11th is past final freeze, think we can still get the tagged 9.0 included in the release?  I'm thinking maybe this puts us into SRU territory
<tjaalton> yeah
<tjaalton> it's already a month late :)
<mlankhorst> sigh stupid mail archives
<mlankhorst> I'm fairly spammers are smart enough already to defeat @ substitution
<bryceh> mlankhorst, if they even care
<mlankhorst> yet we still all mangle email addresses
<mlankhorst> :/
<bryceh> we're not exactly their target audience ;-)
<mlankhorst> tjaalton: pushed, untested, doing build test now
<Hanmac> mlankhorst: about my bug, what do you mean with "no hardware lockup " in my bug?
<mlankhorst> Hanmac: the other one has some kind of hardware lockup in dmesg, yours didn't
<Hanmac> you mean stuff like [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8500)=0xCAFEDEAD) ? its in the kernlog
<mlankhorst> oh ok attach it then
<Hanmac> i attached my entire kernlog
<mlankhorst> probably a dupe then :)
<Hanmac> hm probably not ... i get IRQ problems, he gets none (but its because my radeon shares the irq with others)
<mlankhorst> tjaalton: seems to build
<tjaalton> cool
<ehoover> Sarvatt: Is there something else that needs to be done to get Bug #1059276 fixed in Precise as well?
<ubottu> Launchpad bug 1059276 in libxcb (Ubuntu) "Wine locks up when running multithreaded applications that touch both OpenGL and X11" [Medium,Fix released] https://launchpad.net/bugs/1059276
<mlankhorst> ehoover: looks good to me
<ehoover> mlankhorst: well, a package was built for quantal but not for precise (https://launchpad.net/ubuntu/+source/libxcb)
<mlankhorst> Sarvatt: are you sru'ing it?
<Sarvatt> the regression potential part needs to be filled out first, was giving it a few days of using it to see if there were any obvious regressions but its been ok
<Hanmac> mlankhorst i notic that debian has fglrx-legacy packages ... who should i ask for ubuntu ones?
<Sarvatt> Hanmac: file a bug, assign tseliot (~albertomilone on launchpad), he already had plans to do it afaik
<mlankhorst> I prefer to have radeon fixed though
<ehoover> ah, i thought a package would still get built and it just wouldn't get pushed as part of the stable repo.
<ehoover> (my bad, sorry to be a troublemaker)
<tseliot> Sarvatt: yes, well, the main problem is that the legacy driver doesn't support the new X abi
<bryceh> tseliot, ha of course
<Sarvatt> doh!
<tseliot> :(
<Hanmac> tseliot shit you are right :'(
<tseliot> I might introduce it in Quantal but we'll see
<tseliot> I have yet to introduce Nvidia's new legacy driver
<mlankhorst> I believe best way forward is to make radeon better than fglrx, not a high bar I know :p
<Hanmac> i dont think you can make radeon as fast as fglrx was ... fglrx had 10times more fps than radeon ...
<mlankhorst> that means that somewhere there is probably a simple speedup that could be done to at least double the fps in radeon, would just need to find it :p
<Hanmac> sorry that i cant help with that ... i dont even understand ogre 100%
<mlankhorst> just need to know command line stuff really
<mlankhorst> and some C
<Hanmac> i did some C stuff with glfw, but writeing graphic-driver is too freaky for me :/
<mlankhorst> Why?
<Hanmac> i dont know ... i prefer my code more object orientented than pure C is ...
<mlankhorst> can't get more object oriented than raw drivers!
<Hanmac> hm it may be interesting but 3.6daily crashs a bit more worse than 3.5.5 ...
<dj_ryan> well i tried to make xinerama, nvidia + intel work
<dj_ryan> but ubuntu is excessively crashy
<dj_ryan> so i have to give up on triple monitor
<dj_ryan> X11 is so so far behind the times it's sad
 * mlankhorst wonders why he has nvidia-common on armhf :x
<Sarvatt> mlankhorst: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/977245
<ubottu> Launchpad bug 977245 in nvidia-common (Ubuntu) "nvidia-common can't be used by jockey with arm/gles drivers" [Medium,Fix released]
<Sarvatt> its renamed ubuntu-drivers-common now because it hasn't been nvidia specific in a long time :)
#ubuntu-x 2012-10-04
<mlankhorst> ah
<tjaalton> sigh, fed up with kubuntu users filing useless bugs because it doesn't have xdiagnose installed
<mlankhorst> make it part of kubuntu-desktop then :p
<tjaalton> xdiagnose depends on gtk
<tjaalton> so that's not an option before it's split
<mlankhorst> add 'write qtdiagnose' for todo in r then :-)
 * mlankhorst wonders if he should
<tjaalton> split the frontend and write a new one, yes
<tjaalton> doesn't ubuntu-desktop pull qt anyway?-)
<mlankhorst> well I like qt, I guess that means I'll volunteer
<tjaalton> great!
<mlankhorst> nah but it should be possible to split it up in a qt and gtk frontend
<tjaalton> right
<xnox_ac100> hello, I get desktop lock-ups ~5-15 minutes - can't do anything even switch to tty. I filed bug 1061441 and I am willing to do anything to get a working desktop.
<ubottu> Launchpad bug 1061441 in xorg (Ubuntu) "graphical desktop locksup and becomes non-responsive" [Undecided,New] https://launchpad.net/bugs/1061441
<mlankhorst>  dmi.chassis.asset.tag: To Be Filled By O.E.M.
<mlankhorst> always the greatest vendor!
<tjaalton>  UpgradeStatus: Upgraded to quantal on 2012-01-04 (273 days ago)
<tjaalton> whoa
<mlankhorst> that just means their system clock is off :p
<mlankhorst> mine would travel years into the future if i repeatedly suspended/resumed it
<tjaalton> xnox_ac100: when did it start?
<tjaalton> smells like bad hw
<mlankhorst> xnox_ac100: does a precise livecd work?
<xnox_ac100> tjaalton: i work on foundations team on ubiquity. I needed python3 bits of various software very early on. But I did upgrade *after* UDS not before =))))
<mlankhorst> tjaalton: argh all bugs are going down except intel :((
<xnox_ac100> tjaalton: it started.... after yesterdays reboot.... how many dist-upgrades that was, I am not sure.
 * xnox_ac100 can check the logs I suppose
<tjaalton> there should be no updates that result in this
<tjaalton> mlankhorst: let's sort it out then
<xnox_ac100> So I had uptime since 16:00 UTC 1st of October. reboot at 20:00 3rd of October and it all went to downhill from that.
<mlankhorst> :/
<mlankhorst> did you upgrade before that?
<tjaalton> right, no x related updates there
<mlankhorst> some linux kernel though
<xnox_ac100> yes, full dist-upgrade just before the reboots. I did have rebooted for kernel update.
<xnox_ac100> mlankhorst: oh...
<tjaalton> well I bet 3.6 would still work
<tjaalton> I've no issues with sandybridge here
<tjaalton> even with 3.5
<mlankhorst> mine chronically overheats :p
 * xnox_ac100 is running 3.6-final currently => locks up. rc4 was good, let me reinstall that just in case I lock up again.
<tjaalton> ok then, try an earlier 3.5 kernel
<tjaalton> you should have plenty installed
<tjaalton> so you probably got 3.5.0-16 installed, try -15
<xnox_ac100> well actually i have only 4, as I only have 200MB /boot with full disk encryption
<tjaalton> disk is cheap :)
<xnox_ac100> also i did mark myself as affected by bug 1041790
<ubottu> Launchpad bug 1041790 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2] GPU lockup IPEHR: 0x0b160001 IPEHR: 0x0b140001" [Medium,Confirmed] https://launchpad.net/bugs/1041790
<mlankhorst> xnox_ac100: full disk encryption ftw
<mlankhorst> even though it limits my ssd to 400mb/s instead of more XD
<xnox_ac100> tjaalton: yeah... i have plenty in the lvm, just not much left for /boot, and now i want to split a chunk of it for UEFI boot partition....
<xnox_ac100> i did recently create an unencrypted lvm for sbuild
<mlankhorst> hehe, I cheated by rolling my own kernels :P
<mlankhorst> I only need 1 initramfs
<xnox_ac100> lol =) nice
<mlankhorst> but all my test systems boot off nfs anyway
<xnox_ac100> so i have -15, -16 & mainline rc4 and final. Will try -15 next I guess....
<tjaalton> if there's a regression I'd think it's reverted/fixed in the upcoming -17
<tjaalton> since it merged 3.5.5
<xnox> well if you see xnox drop out, yet xnox_ac100 stays, then you know.... i locked up again.
<mlankhorst> I ignore join/quit messages since its too much spam
 * Hanmac is sorry that i spam you :'(
<mlankhorst> I no longer see it :p
<tjaalton> mlankhorst: so how's mesa doing?
<mlankhorst> it builds and i pushed it back
<tjaalton> ok, I'll test it briefly and upload
<mlankhorst> we might want to see if we can drop some of the build patches before doing the final 9.0 upload though :)
<tjaalton> oh right there was patch 14
<mlankhorst> yeah it caused a conflict
<tjaalton> huh?
<Hanmac> mlankhorst the last time i SAW the output crashing and i had enough time to make an dmesg output ...
<mlankhorst> tjaalton: well the upstream patch for 118 conflicted with the other patches we had in that tree
<tjaalton> wth? laptop drops to failsafe after upgrade
<mlankhorst> O_O
<tjaalton> mlankhorst: oh I see
<tjaalton> ah, using 3.6.. no wonder
<Hanmac> http://pastebin.com/JL03Ef0E << mlankhorst that is my dmesg before its totaly crash ... shortly before the scene got's green, and the tty1 gots purple
<mlankhorst> Hanmac: dupe it for now I suppose, not much that can be done until upstream responds
<Hanmac> ps: the linux-image-3.5.0-17 packages are coming (maybe) today ... (the meta packages are pointing to it) but i dont think it solv my problem :'(
<tjaalton> we know, and haven't suggested it would
<mlankhorst> Hanmac: I don't mean to be rude but we're aware of the problem and affected too, if you keep focusing our attention to it we get distracted from finding a solution and our other work on solving problems for others
<mlankhorst> tjaalton: any idea when the 3.5.5 linux image comes?
<tjaalton> mlankhorst: uploaded already
<tjaalton> https://lists.ubuntu.com/archives/quantal-changes/2012-October/010845.html
<tjaalton> armhf failed to build it seems
<tjaalton> others are in NEW
<mlankhorst> ah :)
<Hanmac> hm it seems the failing "GPU softreset" & "[drm:r600_resume] *ERROR* r600 startup failed on resume" only destroys the X-Output (so it does not change anymore) but tty does still work
<Hanmac> "irq/18-radeon Tainted" are the bad guy that destroy tty1 too 
<Hanmac> is this information helpful?
<mlankhorst> Hanmac: no we already collected all that information from your log, nothing to add
<mlankhorst> and please use the bug report instead of here
<tjaalton> building mesa
<tjaalton> mlankhorst: added a changelog entry for the patch ;)
 * Hanmac is joyful because of new packages
<mlankhorst> tjaalton: yeah I'm just marking a whole bunch of xorg-server bugs incomplete now when they were filed at x < 1.13 or one of the rc's
<tjaalton> mlankhorst: cool
 * xnox_ac100 locked up. booting into 3.5 -15
<tjaalton> mlankhorst: the build patches are now in 9.0
<mlankhorst> \o/
<mlankhorst> thought so
 * xnox_ac100 ponders if it's actually compiz locking me up
<tjaalton> can you ssh in?
<xnox_ac100> no. I should set up this netbook for ssh in.
<xnox_ac100> tjaalton: what do you want me to check on the next lock up?
<tjaalton> xnox_ac100: well, if you can log in with ssh it means it's not a full system lockup
<tjaalton> also, does mouse work?
<tjaalton> might just be some app taking the input grab
<tjaalton> you can try chvt
<tjaalton> via ssh
<Hanmac> xnox_ac100 i maybe need more information, what is your xserver version, whats your graphic card, what do you mean with "locking up"?
<tjaalton> Hanmac: please, don't
<Hanmac> okay :(
<xnox> Hanmac: check irclogs from today, if you are interested =)
 * xnox setup working ssh now.
<xnox_ac1001> hmm... actually it's a full system lock down. it doesn't even reply to pings.
<Hanmac> so it puts finger in its ears and ignores you? that is very mean
<tjaalton> xnox_ac1001: ok so it happens with -15 too?
<xnox_ac1001> tjaalton: -15, 3.6rc4, 3.6final now going to -16 again (can't remember now) with or without unity/compiz
<tjaalton> ok, dodgy hw then
<tjaalton> check your ram
<xnox_ac1001> hmmm....
<xnox_ac1001> memcheck or is there anything else?
<tjaalton> selectable from the grub menu
<tjaalton> memcheck yes
<xnox_ac1001> ok
 * xnox_ac1001 doesn't deal with hw that often.
<xnox_ac1001> it works without a hitch usually =)
<tjaalton> that's all I can think of
<xnox_ac1001> sounds plausible. since it's out of the blue in dependant of everything.
<tjaalton> you can check dpkg.log for the upgrade diff, but don't think you'll find anything suspicious there, if the kernel update has already been ruled out
<xnox_ac1001> and compiz....
<xnox_ac1001> ruled out.
<xnox_ac1001> and unity. no updates to X as you said....
<tjaalton> mesa uploaded
<mlankhorst> yay
 * Hanmac says yay too
 * xnox_ac1001 doing memtest now
<Hanmac> tjaalton where do you upload the mesa? is there an link where i can look?
<mlankhorst> quantal-proposed presumably
<mlankhorst> or simply quantal
<tjaalton> quantal
<Hanmac> hm is this the right package for looking? https://launchpad.net/ubuntu/+source/mesa
<tjaalton> it's not accepted yet
<xnox_ac1001> you can fetch it from unapproved queue
<tjaalton> right
<mlankhorst> but it won't do you any good since your problem is in the kernel..
<Hanmac> but i could still dream that its going better ...
<xnox_ac1001> hmmm... http://forums.linuxmint.com/viewtopic.php?f=59&t=113043 recommends i915.i915_enable_rc6=0
<tjaalton> it shouldn't break like that
<xnox_ac1001> ok
<tjaalton> I mean, break all of a sudden
<tjaalton> if it worked fine before
<xnox_ac1001> bug 993187 sounds like a winner
<ubottu> Launchpad bug 993187 in linux (Ubuntu Precise) "ubuntu 12.04 completely freezes frequently." [Critical,Won't fix] https://launchpad.net/bugs/993187
<xnox_ac1001> including the comment #493 about buggy ethernet driver locking the system up
<xnox_ac1001> but i am pondering about trying comment #321 boot param settings
<tjaalton> that bug is the worst bug in the history of mankind :)
<tjaalton> bug report
<xnox_ac1001> tjaalton: nah the worst bug was brother printers don't print on tuesdays.
<mlankhorst> :>
<xnox_ac1001> with reporter confirming the bug every tuesday & bug triangers unvalidating it every wednesday
<tjaalton> people are still posting new comments there even though it was closed months ago
<tjaalton> as impossible to follow
<mlankhorst> haha
 * xnox_ac1001 the reporter had weekly reports to print on tuesdays....
<xnox_ac1001> it took a while for the pattern to be noticed.
<tjaalton> heh
<tjaalton> guess it would be helpful to mark this bug as private..
<tjaalton> should help with the hand-waving
<xnox_ac1001> tjaalton: please don't =)
<xnox_ac1001> google indexed each comment and i would never find out about those two comments and learn that "sandybridge is disappointment of the year 2011@
<tjaalton> ok then, I won't touch it :)
<mlankhorst> tjaalton: you forgot to push the xserver-xorg-video-nouveau commit after pushing?
<tjaalton> mlankhorst: no, should be there
<mlankhorst> oh right, i forgot to fetch
<mlankhorst> tjaalton: I added a small exa fix for nouveau, can you upload it?
<tjaalton> sure
<tjaalton> mesa accepted
<tjaalton> mlankhorst: btw, if you have nothing else to add to a package, you can finalize the changelog entry with dch -r
<mlankhorst> tjaalton: I know but I can't upload :-)
<tjaalton> you can commit the change
<tjaalton> to git
<tjaalton> it doesn't matter who is listed on the changelog entry
<tjaalton> as the signer
<tjaalton> what matters is who has signed the package files
<tjaalton> hmm, didn't the patch fix any of the lp bugs?
<tjaalton> uploaded anyway
<Hanmac> yeah the build begins
<mlankhorst> most nouveau bugs might be in mesa :/
<mlankhorst> or kernel
 * Hanmac wonder behind with door my zonk is hiding ...
<tjaalton> amd64 build now failed twice
<mlankhorst> on what?
<tjaalton> mesa
<tjaalton> some bug in parallel build
<tjaalton> builds fine here
<Hanmac> the error was  "SIRegisterInfo.td:2:1: error: Unknown token when parsing a value " ... hm it uses llvm maybe this was the problem?
<tjaalton> no, there's a known bug in the parallel build, still not fixed upstream
<tjaalton> it doesn't fail every time
 * mlankhorst tries -j32
<mlankhorst> seems xatracker needs -ldrm and -pthread still and glapi is missing symbols too :/
<tjaalton> details.. :)
<mlankhorst> tjaalton: seems debuild -b -j256 works here?
<tjaalton> how many times did you run it?
<tjaalton> also, since you don't have 256 cores I doubt it'll hit the race :)
<mlankhorst> fine I'll let it loop a bunch of times :P
<tjaalton> I'm running with -j8
<mlankhorst> 4 cores?
<tjaalton> 4+4
<tjaalton> HT
<mlankhorst> ah
<mlankhorst> yeah i have the i5 no ht :(
<mlankhorst> next system!!
<tjaalton> it seems to be failing on gallium/radeon though, generating *.td isn't finished before llvm-tblgen is run
<tjaalton> I mean all the failures have been there now
<mlankhorst> tjaalton: yeah repeatedly doing it on that directory fails
<mlankhorst> those incs seem like they should be added though by make depend
<tjaalton> the lp build passed this time
<mlankhorst> xorg-server seems to love to hang on the xvfb randomly, didn't manage to reproduce it :/
<mlankhorst> but that's at least radeon nailed down, talk about thinkos :)
<Hanmac> hm nearly all packages for 3.5.0-17.26 are finish ... only the armhf takes so long :'( ... hm launchpad should have some "notic me when the build is finish" option ...
<tjaalton> you shouldn't care about that
<tjaalton> it's not going to help
<mlankhorst> you mean xorg-server?
<Hanmac> i meand https://launchpad.net/ubuntu/+source/linux/3.5.0-17.26 ... i wait for the packages so i could upgrade my linux and linux-lowlatency packages ... 
<Hanmac> i know it does not solv my problem :( but i am happy about new packages ... its like x-mas :D
<Sarvatt> RAOF: seen https://bugs.launchpad.net/unity/+bug/1057000 ?
<ubottu> Launchpad bug 1057000 in unity (Ubuntu) "[Ubuntu 12.04.1/12.10] nVidia drivers 304.51 prevent autohidden Unity launcher from revealing" [High,Confirmed]
<Sarvatt> that got uploaded to quantal today, whoops :(
<tjaalton> sigh
<mlankhorst> argh, my keyboard is detected as a mouse..
<Hanmac> yeah the 3.5.0-17.26 packages are finish ... they took > 8 hours ... i could read a book in this time ...
#ubuntu-x 2012-10-05
<bryceh> RAOF, SRU bug #1037483 looks ripe for pushing out for nvidia-current-updates
<ubottu> Launchpad bug 1037483 in nvidia-settings (Ubuntu Precise) "[SRU] Needs NVIDIA driver 304.43 [HW-Certification blocker]" [Medium,In progress] https://launchpad.net/bugs/1037483
<mlankhorst> morning
<Sarvatt> mlankhorst: "morning" man :)
<mlankhorst> bryceh/RAOF: Any objections if I nuke a bunch of renamed mesa/xorg packages from the stack and let those fall back to the old unrenamed packages?
<mlankhorst> libosmesa6, xnest, xdmx, xephyr
<mlankhorst> xfbdev
<mlankhorst> libglu1 (now a separate package, so I didn't see a reason not to keep the old one from mesa 8 instead)
<Sarvatt> if you say xvfb next yeah
<mlankhorst> yeah
<Sarvatt> libglu1 should be easy?
<mlankhorst> mesa 9 no longer packages it
<tjaalton> installed precise on my laptop next to quantal.. time to fix the intel pageflip issue there
<Sarvatt> damn 101_copy-fb.patch not being the same as upstream, thats the only thing stopping it from being easy :)
<mlankhorst> and osmesa6 might get a soname bump in r to osmesa8, so we could keep it unrenamed
<tjaalton> yeah likely so
<Sarvatt> hell you could probably keep it as osmesa.so.6, not 100% sure though
<tjaalton> that's what we do now
<mlankhorst> Sarvatt: either way it's something that's going to give more pain to rename than to keep the old version
<Hanmac> my ubuntu was installed as lynx and then upgraded until i reach quantal ... (i think someday i should make an clean install again ..)
<Sarvatt> its only bumped to 8 because fedora/suse bumped to 8 and rebuilt everything against that afaik
<Sarvatt> but hey its whiskey o'clock here
<mlankhorst> yeah but unless there is a reason to upgrade osmesa i feel like we should just keep the current binary
<Sarvatt> havent heard anyone complain we kept it 6 all throughout 7.xx
<Sarvatt> and 8.0.x
<tjaalton> it hasn't changed
<jcristau> the only thing you should need to upgrade from mesa is the dri drivers, really
<mlankhorst> and egl in the future :/
<mlankhorst> but I'm hoping at that point that nvidia dev has his proposal for a stable libGL in
<mlankhorst> is libgl1-mesa-dri-experimental still used? seems to be empty
<tjaalton> it is
<tjaalton> someone wanted to have i915g there
<mlankhorst> ~/nfs/xorg/mesa/debian$ find libgl1-mesa-dri-experimental |grep i915
<mlankhorst> ~/nfs/xorg/mesa/debian$ 
<tjaalton> it's not there _now_ :)
<mlankhorst> ok can just kill it off for the renamed stack, then
<tjaalton> yep
<mlankhorst> are the udeb files used anywhere in ubuntu?
<tjaalton> installer
<tjaalton> so you need them for .2
<mlankhorst> ok
<Sarvatt> i dont think any x related udebs are used no
<tjaalton> oh right
<tjaalton> heh
<tjaalton> forgot
<mlankhorst> :p
<RAOF> Yeah, we don't use X11 in debian-installer. You're good :)
<mlankhorst> shrug I'll leave it for now, it would be more work to remove udeb  generation
<Sarvatt> changing one line in debian/rules is easy, but why do it if its not breaking anything :P
<mlankhorst> Sarvatt: it's the testing that's hard
<mlankhorst> hm tempted to append originalname-lts and xorg-renamed-package, so simply having a package conflict on xorg-renamed-package would be enough to kill all renamed packages, and i wouldn't need to repeatedly sru the original xorg-server every time a new version is released
<mlankhorst> to each provides*
<mlankhorst> and in case of conflicts/replaces, add originalname-lts to conflicts/replaces too
<mlankhorst> hm that part is not needed i think
<tjaalton> give an example with real package names :)
<mlankhorst> provides: xxv-intel, xxv-intel-lts, xorg-renamed-package, xorg-renamed-package-lts-quantal
<tjaalton> oh, virtual packages you mean?
<mlankhorst> yeah
<mlankhorst> it's just because xnest and such have a versioned depends on xserver-common, which could be replaced with xserver-common >= currentversion | xserver-common-lts
<jcristau> eww
<mlankhorst> jcristau: well it was never going to be nice, anyway
<mlankhorst> and if it helps upstream is going to stay untouched :)
<jcristau> would it be possible to build xserver-common from the xorg-server-lts-foo without renaming it?
<tjaalton> hmm probably
<mlankhorst> then people who don't use lts-quantal would upgrade xserver-common automatically to it..
<mlankhorst> or 'package withheld'
<tjaalton> yeah that's the problem, and that the manpage for Xserver(1) might change :)
<mlankhorst> well if people want to keep that package unrenamed it shouldn't be hard to keep it like that..
 * mlankhorst doesn't care either way
<jcristau> mlankhorst: considering the contents of that package, upgrading it shouldn't be a big deal, hopefully
<mlankhorst> ok leaving it unrenamed it is, then
 * mlankhorst hopes launchpad won't bork on that
<jcristau> just an idea anyway...
<tjaalton> should be easy to change back
<tjaalton> if needed
 * mlankhorst adds a rename entry for xserver-common to xserver-common :P
<tjaalton> the only "risk" is if it's confusing to see options for Xserver that the current installed version doesn't have
<mlankhorst> is protocol.txt backward compatible?
<mlankhorst> seems that is being parsed at least..
<jcristau> iirc it's read by the selinux stuff
<jcristau> or xace anyway
<tjaalton> dri2 was the last thing added to it in 2009
<tjaalton> *latest
<jcristau> yeah eamon kind of vanished
<mlankhorst> tjaalton: dri2.5 coming up though..
<jcristau> and then this didn't get updated
<mlankhorst> but ok if it won't break I don't care
<mlankhorst> now how do I get this building again
<mlankhorst> dh_install: dri/usr/include/GL/osmesa.h exists in debian/tmp but is not installed to anywhere
<ricotz> bjsnider, i am curious did you look into updating libva while there are some newer releases
<mlankhorst> argh why would that get installed with --disable-osmesa
<mlankhorst> >:(
<tjaalton> building current mesa from quantal?
<mlankhorst> yeah renamed
<mlankhorst> killing off osmesa is.. fun
<mlankhorst> hopefully fixed now
<tjaalton> oh right
<akheron> mlankhorst: remember me? :)
<akheron> I changed from xubuntu to default ubuntu a while ago, and my X hasn't crashed ever since
<Hanmac> and now you are back because your x is crashing again?
<akheron> well, actually it has hanged a few times, but nothing similar to the old behavior of crashing twice a day
<akheron> Hanmac: no, just to report that things are not so bad :)
 * Hanmac knows what is bad ... currently i need to reboot more than five times each day because something breaks my output
<mlankhorst> ok mesa builds
<mlankhorst> # Make sure Xvfb at least starts up
<mlankhorst> PATH=debian/tmp/main/usr/bin/:/bin:/usr/bin \
<mlankhorst>           debian/tmp/main/usr/bin/xvfb-run -s "-screen 0 1280x1024x24 -nolisten tcp -noreset" true
<mlankhorst> xvfb-run: error: Xvfb failed to start
<mlankhorst> haha
<tjaalton> hum, would it be too bold to replace -intel's 101_copy-fb.patch with the commit from upstream, for precise
<tjaalton> would help in backporting the pageflip fixes
<bjsnider> ricotz, in x-updates? i thought about it
<ricotz> bjsnider, i thought more about debian, if i have seen this right, you were involved there
<ricotz> and the git repo seems messed up and abandoned :\
<bjsnider> oh, i didn't know that
<bjsnider> i will check into it
<ricotz> alright
<Hanmac> ricotz you are looking like an expert can you look at my bug, maybe you can find the culpit? #1060987 
<mlankhorst> Hanmac: I've told you enough that upstream needs to respond, we don't know what's wrong and can't help you :/
<mlankhorst> asking someone else will just give you the same answer twice
<bjsnider> ricotz, btw you can put the latest clutter-gst and totem in the ppa. i built them here and installed them and they work fine
<ricotz> bjsnider, at least clutter-gst-2.0 is suppose to land in quantal, yeah totem should be updated there
<ricotz> assuming you meant the gnome3 ppa ;)
<bjsnider> of course
<mlankhorst> oops, wonder if that's why xserver broke, probably best not to have xserver-common conflict with itself
<ricotz> Hanmac, i mentioned it already i don't have an amd gpu here so can't test it -- and yes, most part of the driver is located in the kernel which makes it a possible source of the problem
<Hanmac> so i am forced to sit on this vulcano until i buy newer hardware ? :'(
<ricotz> mlankhorst, regarding nvidia hopefully this gets fixed, not that i care about unity, but maybe if 310 is out 304 gets an update too
<ricotz> Hanmac, you can go for testing kernel 3.7 and hope it makes a difference -- http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
<ricotz> and of course #radeon
 * mlankhorst notes that a package conflicting with itself has interesting effects on apt
<bjsnider> "not that i care about unity" hahaha rock n roll
<Hanmac> the 3.7 (3.6 daily) did not help yet, but i may have differnt errors (currently i load the newest daily)
<bryceh> mlankhorst, no objections here.  I was wondering if those were sufficiently client-ish that they could be omitted, so good.
<mlankhorst> bryceh: yeah i seemed to have broken something though, even with hints it no longer did the upgrade correctly. I'm testing if it was because I made xserver-common conflict with itself.
<mlankhorst> or at least i was taught that if you could prove 1=0 then you cna do all kinds of fun things that defy logics :)
<bryceh> mlankhorst, I think I derived that answer on more than a couple final exams in college...
<mlankhorst> hehe :P
<mlankhorst> Provides: xorg-input-abi-, xorg-renamed-package, xorg-renamed-package-lts-quantal, xorg-video-abi-, xserver-xorg-core
<mlankhorst> figures..
<tjaalton> so how does the intel backport work on precise? I've tried the old version with the upstream copy-fb patch but it fails to start
<tjaalton> assuming it conflicts with plymouth, or maybe needs something else backported?
<mlankhorst> I didn't look at it yet
<tjaalton> hmm
<tjaalton> actually failsafe does start, lightdm doesnt'
<mlankhorst> for some reason I have no abi any more
<tjaalton> oh heh, of course
<tjaalton> failsafe uses vesa
<tjaalton> duh
<tjaalton> and looks like it just needs the compat commit
<tjaalton> excellent
<mlankhorst> accidentally killed all calls
<tjaalton> oh yes, just needed to change pScreen to match the old api
<tjaalton> so now I should have all the pageflip backports for precise
<mlankhorst> oh that
<tjaalton> plus the do-copy-fb commit
<tjaalton> backported
<mlankhorst> well xorg-server backport fixed again, was a bit overzealous with sed
<mlankhorst> multilib is fun and breaking things in a new way I fear :/
<tjaalton> flip_test passes
<tjaalton> hum, or maybe not
<tjaalton> both versions fail the same way
<tjaalton> or maybe it's testing plain kms
<mlankhorst> hm this thing hates me.. :/
 * mlankhorst wonders if it's easier to rename libglapi
<mlankhorst> or maybe I'm just hitting a bug in apt..
<mlankhorst> seems like it.. 32-bits libglapi-mesa-lts-quantal is unpacked, then it tells dpkg to extract 32-bits and 64-bits libgl1-mesa-glx-lts-quantal, it misses 64-bits libglapi-mesa-lts-quantal and things go boom
<mlankhorst> blegh eod even if i started late :P
<bryceh> hey guys, I've posted status summary of where we are with bugs across all the X packages.  I doubt I'll have time to look into those things (maybe some nvidia bugs), but wanted to highlight the problem areas in case you want to tend to some of them.  the xserver crashes in particular could use some attention.
<bjsnider> tjaalton, you took a shot at packaging gstreamer-vaapi i see
<tjaalton> bjsnider: some time ago
<bjsnider> http://anonscm.debian.org/gitweb/?p=users/tjaalton-guest/gstreamer-vaapi.git;a=summary
<tjaalton> haven't touched it since
<bjsnider> does it build?
<bjsnider> new release happened today i guess
<tjaalton> someone touched it on quantal I think
<tjaalton> so I guess it builds
<tjaalton> sigh, where to upload -intel for precise.. all the ppa's have a newer version already :)
<tjaalton> let's just use proposed then..
<tjaalton> or maybe not, now the patch fails to apply.. wtf
<tjaalton> heh, pebkac
<tjaalton> ok pushed -intel to precise-proposed, with a detailed test case on the bug..
<tjaalton> time for EOD
<bryceh> heh, that email didn't take long to hit phoronix.  must be a slow news day
<mlankhorst> bryceh: probably :P
<mlankhorst> although i did gain some insight in the making of phoronix on xdc2012
<bryceh> oh?
<mlankhorst> seems tons of beer is involved in making news!
<mlankhorst> and some of the articles are really jus ttrolling after all
<bryceh> mlankhorst, did michael admit that?
#ubuntu-x 2012-10-06
<mlankhorst> RAOF/bryceh: What would it take to create a drm backport for 3.7? Although I fear the delta might be too big because of the defered fput changes which made it into 3.6
<tjaalton> mlankhorst: difficult, because of the agp changes (which is builtin)
<mlankhorst> yeah was afraid of that :/
<tjaalton> dunno if it would be possible to revert them from drm
<mlankhorst> oh right that's why it locks up, no defered fput
<mlankhorst> maybe for r we can at least advertise some support for hybrid graphics then
<tjaalton> hopefully gnome will have some support as well
<mlankhorst> for once i wish nvidia weren't so following and would just get into contact with me
<tjaalton> what for?
<mlankhorst> if the proposals I threw on the list would work for them or not
<mlankhorst> but I fear that they're not replying either because 1. they don't care, 2. it would work for them, 3. afraid of backlash by replying publicly, 4. held back by lawyers form replying :/
<mlankhorst> or a combination of those
<tjaalton> the five patch series?
<mlankhorst> yeah, mostly worried about the interface
<Sarvatt> the agp changes are mostly intel stopping using intel_agp for newer stuff, could possible do a drm and just nouveau dkms? *note i haven't looked
<Sarvatt> actually a large part of the intel_agp changes were just backported in 3.5.0-17
<Sarvatt> https://lists.ubuntu.com/archives/quantal-changes/2012-October/010991.html
<mlankhorst> Sarvatt: yeah but the defered fput which would fix hangs for prime are probably too deep to be backported
<bjsnider> alright, i tested the latest vaapi code in vlc on ivb
<bjsnider> so, using vaapi, 3 of 4 cpus are at approximately 10% but no higher. the 4th cpu is at approximately 20%
<bjsnider> without vaapi, all 4 cpus are at 10-15%
<mlankhorst> bjsnider: are you trying 1080p?
<bjsnider> negative, not yet anyway
<bjsnider> 720p x264 at about 5000k
<mlankhorst> at that point vaapi starts to become interesting at least
<bjsnider> alright, i tested mega-high bitrate 1080p x264, and here's the deal
<bjsnider> with vaapi 3 cpus are at 10% or less, one cpu is at 40
<bjsnider> without vaapi all 4 are at around 20
<bjsnider> what i'd really like to do is test gstreamer but i haven't figured it out yet. also the code is for 0.10, not 1.0
<mlankhorst> probably best to zap other cores during testing
<mlankhorst> ~$ for n in /sys/devices/system/cpu/cpu*/online; do echo 0 | sudo tee -a $n; done
<Sarvatt> bjsnider: might be a bit late for new libva :(
<Sarvatt> oh vaapi code in vlc, helps to read all of the scrollback :)
<bjsnider> Sarvatt, doesn't matter anyway, because libva 1.1.0 breaks the intel code, so we'd have to wait for another release of that
<bjsnider> ok, i tested gstreamer-vaapi using playbin2. mega-high bitrate 1080p x264 file plays with all 4 cores at less than 10%
<bjsnider> same file played in totem, which is gstreamer 1.0 and no vaapi -- all 4 cores spiking very high, at least one over 60% at all times
<bandit-led> getting artifacts at startup after login to gnome-classic and frequent total lockups 
<bandit-led> kernel 3.6 and 12.10 
<bandit-led> x64'
<bandit-led> bah looks like its updating to 304.43 let me tries that see if its fixed
<bjsnider> ok, that was a fairer test. used playbin for both. all 4 cores at least twice as high without vaapi as with it
#ubuntu-x 2013-09-30
<mlankhorst> morning
<tjaalton> same
<mlankhorst> oh btw i think the package scripts work again properly
<jcristau> mlankhorst: any reason you didn't add xserver-xorg-video-modesetting to -all on armel?
<Sarvatt> probably just forgot since we dont build armel
<jcristau> also making changes on 4 archs that should be done everywhere is just silly
<mlankhorst> jcristau: I don't know which archs have support for -modesetting capable drivers, afaik only robclark's branch did, but yeah I'm working on the other drivers
<mlankhorst> oh I had some updates in my tree that were overwritten by your changes :P
<jcristau> mlankhorst: there shouldn't be anything in armhf that's not also on armel since you can run armel userspace on armhf host afaik?
#ubuntu-x 2013-10-01
<ph_> hey guys - i just upgraded to Ubuntu Gnome 13.10 with a daily build, then upgraded to gnome-shell 3.10 via gnome3-next ppa. All good so far. But I then was told it's better to upgrade to gnome3-staging due to gnome-settings-daemon issues. So I did that, but at that point my monitor is detected as being 7" (it's a 55" monitor), and I get this in my Xorg.0.log http://pastebin.com/2rhcaLk4 
<ph_> it's getting DPI set to (40,40) from EDID which makes my fonts and cursors and Icons HUGE
<ph_> hi is anyone online who can help me sort out an X DPI problem at all?
<tjaalton> meh
<tjaalton> wth, now I need to remove .Xauthority every time or no login
<tjaalton> waiting for the lightdm fix then
<tjaalton> log in from lightdm, log in via ssh -X, and next time can't log in from lightdm anymore
<mdeslaur> tjaalton: what are the permissions on .Xauthority when that happens?
<tjaalton> mdeslaur: 600
<mdeslaur> tjaalton: and your own user?
<tjaalton> yep
<mdeslaur> huh
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1036830 was filed earlier
<ubottu> Ubuntu bug 1036830 in lightdm (Ubuntu) "Can't log in unless remove .Xauthority or use gdm" [Undecided,Confirmed]
<tjaalton> https://code.launchpad.net/~robert-ancell/lightdm/handle-corrupt-xauthority/+merge/188256 should fix it
<tjaalton> but my file looks intact
<bjsnider> tjaalton, someone was in here complaining about that a couple days ago
<tjaalton> yeah me, at least :)
<bjsnider> no, someone who is not you
<tjaalton> but I thought it was temporary
<tjaalton> i think we're all on that bug now
<bjsnider> all you lightdm people
#ubuntu-x 2013-10-02
<ricotz> mlankhorst, hello :)
<ricotz> mlankhorst, was there are a reason not to sync libx11?
<ricotz> while building it in a ppa it bails on xsltproc with "... Bus error ...", maybe you saw something like this yet? https://launchpadlibrarian.net/152123093/buildlog_ubuntu-saucy-i386.libx11_2%3A1.6.2%2Bgit20131002.18a5278b-0ubuntu0ricotz_FAILEDTOBUILD.txt.gz
<tjaalton> a3/away
<tjaalton> uh
<mlankhorst> ricotz: yes that was exactly the reason
<mlankhorst> bug in w3m somewhere or something, and i cant reproduce it..
<tjaalton> well the current version fails just as well
<tjaalton> doko poked me about it
<ricotz> mlankhorst, i see, i thought so :\
<tjaalton> anyone here with gen5 intel, arrandale/ironlake?
<tjaalton> aka original 'core'
<tjaalton> there are updates to w3m available in debian
<tjaalton> -8 -> -11
<tjaalton> a couple of patches to fix "potential segfault" too
<tjaalton> i'll sync it
<tjaalton> w3m update is now in proposed
<mlankhorst> ok, syncpackaged libx11
<tjaalton> cool
<tjaalton> to the ppa first?
<mlankhorst> naw
<mlankhorst> we already know the only thing that broke libx11 was w3m, so if it's still broken some other solution has to be found anyway
<tjaalton> right
<mlankhorst> and building
<mlankhorst> https://launchpadlibrarian.net/152143920/buildlog_ubuntu-saucy-i386.libx11_2%3A1.6.1-1_FAILEDTOBUILD.txt.gz
<mlankhorst> looks like 0.5.3-11 is still borked
<tjaalton> bah
<mlankhorst> we should just upload libx11 and create it without the .txt documentation
<mlankhorst> blah tomorrow, afk
<ricotz> xorg-sgml-doctools could be synced too (doesnt solve the libx11 issue though)
<tjaalton> the specs aren't getting built on debian?
<tjaalton> then again I don't see why not
<ricotz> tjaalton, yeah, according to the build log they aren't built there
<tjaalton>  Functional specs building enabled:       no
<ricotz> tjaalton, could be they are disabled due build-indep and the binary amd64 upload already contained the arch-all packages
<tjaalton> probably
<tjaalton> but it has no build logs available
<ricotz> yes, because they were uploaded and built locally
<tjaalton> bah :)
<tjaalton> right, it runs debian/rules build-arch
<tjaalton> oh well, it builds on sbuild just fine
<ricotz> heh, it builds fine here too, but the builders dont like it ;)
<ricotz> maybe even another ancient kernel issue
<ricotz> https://bugzilla.samba.org/show_bug.cgi?id=9515
<ubottu> bugzilla.samba.org bug 9515 in Build "can not build samba4 in the RHEL5.3" [Normal,New]
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1163805 looks like it happens a lot..
<ubottu> Ubuntu bug 1163805 in libx11 (Ubuntu Raring) "libx11 ftbfs in raring (building the docs)" [High,Invalid]
<ricotz> Sarvatt, hey :), how are you?
<mdeslaur> I have a question about Mir
<mdeslaur> I noticed that to support the Raspberry Pi, you need to add a backend to weston
<mdeslaur> Since weston is just a reference compositor, does that mean that every compositor implementation would need to add hardware specific code?
<mdeslaur> Does using Mir improve that? In other words, if a compositor uses Mir, does that get abstracted?
<mdeslaur> perhaps I'm misunderstanding something fundamental?
<tjaalton> mir only(?) has an egl backend, so the platform needs to have drivers to provide that
<mdeslaur> oooohhh...they're not using egl on the raspberry pi...I see
<tjaalton> gl(es)
<tjaalton> sry
<tjaalton> i've no idea if it can work
<mdeslaur> er, yeah, gl
<tjaalton> so for weston the default backend is drm, but rpi doesn't have open driver aiui
<tjaalton> *drivers
<mdeslaur> tjaalton: so it mir gains an alternate backend because it needs a funky driver for hardware support, and some compositor is using mir, it gets that backend support for free, right?
<ricotz> tjaalton, btw, could you still sync libevdev?
<tjaalton> ricotz: done, no guarantees
<tjaalton> mdeslaur: well, it's the drivers that need to learn new tricks, not the way around I think
<tjaalton> but yes, like you said aiui
<tjaalton> also I think you'd get less vague answers on #ubuntu-mir :)
<ricotz> tjaalton, thanks, it builds and doesnt have any rdepends yet, so i hope it gets accepted
<mdeslaur> tjaalton: thanks!
<ricotz> tjaalton, have you done it for xorg-sgml-doctools too yet?
<tjaalton> nope
<tjaalton> fixed
<ricotz> thanks
<tjaalton> mlankhorst: the package-status page still seems to not update the debian versions :/
<mlankhorst> hm meh :/
<mlankhorst> sorry, bike broke and I had to walk home for an hour instead
<mlankhorst> not in the best of moods
<tjaalton> take your time :)
<mlankhorst> I wonder why it doesn't update debian versions though, afaict it can pull all the versions from launchpad just fine
<mlankhorst> ok libx11 ubuntu1 uploaded, i killed the .txt files
<tjaalton> looks like just retrying the build could've worked
<mlankhorst> i bet we could kill libx11-doc without anyone caring
<mlankhorst> well i did retry the build, no luck
<tjaalton> ok
<mlankhorst> and in the ppa i tried like 5 times
<tjaalton> heh..
<tjaalton> i blame the buildd
<tjaalton> or did they all fail?
<mlankhorst> only fails with w3m on i386
<mlankhorst> unfortunately the -doc is only built on i386
<tjaalton> hah
<mlankhorst> but it's a arch all package
<tjaalton> right
#ubuntu-x 2013-10-03
<seb128> hey guys
<seb128> could anyone look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1234178 ?
<ubottu> Ubuntu bug 1234178 in xorg (Ubuntu) "Capturing screen only returns black when resumed before" [Undecided,New]
<mlankhorst> seb128: we're attempting to get the new 3.0 xxv-intel driver in, could mark that bug too :)
<tjaalton> seb128: bug 1234027
<ubottu> bug 1234027 in xserver-xorg-video-intel (Ubuntu) "FFe: new upstream release 2.99.903" [Wishlist,Confirmed] https://launchpad.net/bugs/1234027
<tjaalton> should fix it
<tjaalton> yeah
<tjaalton> well, he could test it first
<tjaalton> although I should be able to reproduce it..
<seb128> well, what if you don't get the ffe?
<mlankhorst> then we'll upload a new ddx
<seb128> ok
<tjaalton> we'd be screwed :)
<mlankhorst> and that^
<tjaalton> commented on the bug
<seb128> I did some pinging on #ubuntu-release for your ffe
<mlankhorst> but if you want you can test the one from ppa:canonical-x/x-staging and add test results :)
<tjaalton> I subscribed u-r just now
<tjaalton> was hoping for someone with gen5 to test it first
<tjaalton> just in case
<seb128> how do you figure the gen of a card again?
<mlankhorst> glxinfo has it
<tjaalton> gen5 is the original core
<tjaalton> gen6 is sandybridge
<seb128> I've an i5
<seb128> what gen is that?
<seb128> OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile x86/MMX/SSE2
<tjaalton> it's just the processor model, every gen since core has that
<tjaalton> ahh!
<tjaalton> you're a winner
<seb128> lol, I guess I would
<mlankhorst> indeed :D
<tjaalton> ironlake is gen5
<seb128> I'm usually the only one to get those image corruption bugs :p
<tjaalton> actually we're waiting for rc4 which should fix even more bugs
<seb128> ok, let me know when you get something ready to test
<seb128> I don't want to do useless round of testing of versions known to be buggy ;-)
<mlankhorst> you can try ppa:canonical-x/x-staging xserver-xorg-video-intel
<tjaalton> like bug 1216252
<ubottu> bug 1216252 in xf86-video-intel "scrolling in chrome leads to distorted images" [Medium,Confirmed] https://launchpad.net/bugs/1216252
<tjaalton> yeah the ppa version is stable
<seb128> hum, are those bugs in saucy or regressions?
<tjaalton> bug in saucy
<seb128> ok, so it's ok
<tjaalton> bug since raring
<seb128> let me try that driver update then
<tjaalton> no regressions with the new version so far
<seb128> let me see if I've my usual gut to run into issues with those driver updates
<seb128> the new driver works fine here
<tjaalton> nice
<seb128> no visible problem in an unity session (with an hangout and video)
#ubuntu-x 2013-10-04
<tjaalton> intel update acked
<tjaalton> and uploaded
<tjaalton> just noticed we still have wayland 1.0 because of https://launchpad.net/ubuntu/+source/wayland/1.1.0-2ubuntu2/+build/4969824
<tjaalton> nice
<tjaalton> nevermind :)
<tjaalton> oh well, need to update wayland in order to be able to bump mesa as sru
<ara> RAOF, ping
<tjaalton> ara: guess it's EOW for him already
<mlankhorst> heh :p
<mlankhorst> same for me :D
<tjaalton> slacker :)
<mlankhorst> feels good though
<tjaalton> I bet
<RAOF> ara: Last-chance pong :)
<ara> RAOF, hey
<ara> RAOF, any chances to review the old upload in raring for xorg? https://launchpad.net/ubuntu/raring/+queue?queue_state=1&queue_text=xserver-xorg-video-intel
<ara> (4.2)
<ara> not upload, approve, I mean
<tjaalton> there's a new one!
<tjaalton> :)
<tjaalton> uploaded 12min ago
<ara> tjaalton, then the new one :)
<ara> RAOF, ^
<ara> RAOF, it is pretty critical for certification, all of haswell gpu based systems are blocked on it :(
<tjaalton> I'll upload the backport versions too
<RAOF> Looks ok; accepted into proposed.
<tjaalton> ara: it's not needed on quantal?
<tjaalton> that particular fix
<ara> tjaalton, not needed
<tjaalton> hmm, why do the lts uploads show as 'new'
<mlankhorst> tjaalton: it's a bug, it always shows as NEW, unless there is a previous version in proposed
<mlankhorst> feel free to bug someone about it
<tjaalton> ah
<mlankhorst> it doesn't check updates
<tjaalton> yeah, whoever thought the renames was a good idea ;)
#ubuntu-x 2013-10-06
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-319/+bug/1235890
<ubottu> Ubuntu bug 1235890 in nvidia-graphics-drivers-319 (Ubuntu) "Include 325.xx series and 331.xx series" [Undecided,New]
<tjaalton> heh
<maxiaojun> oh, you works for  hardware enablement?  https://launchpad.net/~tjaalton
<tjaalton> tseliot will add a new driver when the time is right
<maxiaojun> 325.15 released at 2013.08.05
<tjaalton> it was beta last time I heard
<maxiaojun> straight fact is here: http://www.nvidia.com/object/linux-display-amd64-325.15-driver.html unless NVIDIA lies on release date
<tjaalton> the download page still offers 319.xx as the default
<tjaalton> maybe 325 was a short-lived branch
<tjaalton> and not packaged because of that
<tjaalton> http://www.nvidia.com/object/unix.html
<tjaalton> confirms that
<maxiaojun> ok, if it was your policy
<maxiaojun> btw, the state of 319.xx is also strange
<maxiaojun> http://packages.ubuntu.com/search?keywords=nvidia-319
<tjaalton> tseliot didn't want to touch the default version this late
<maxiaojun> why it is missing in 12.10 and 13.04?
<tjaalton> ah
<tjaalton> why would it be there?
<maxiaojun> it is in 12.04 though
<tjaalton> lts matters
<tjaalton> and current devel series
<maxiaojun> it means it is added later?
<maxiaojun> you mean
<tjaalton> to lts yes
<tjaalton> interim releases not likely
<maxiaojun> but why the lts has seemingly identical nvidia-319 and nvidia-319-updates
<tjaalton> -updates has to start from somewhere
<maxiaojun> so shouldn't it be 319.60?
<tjaalton> it takes time
<tjaalton> better ask tseliot directly if you want answers
<maxiaojun> saucy has nvidia-319 be 319.32 while nvidia-319-updates be 319.60
<tjaalton> because 13:27 < tjaalton> tseliot didn't want to touch the default version this late
<maxiaojun> also a tiny issue, nvidia-current still points to 304.xx even on saucy
<maxiaojun> btw, ubuntu-x-swat should provide 319.60 now and found those short-lived/beta drivers on xorg-edgers now
<tjaalton> welcome to the team!
<tjaalton> nvidia-current is going away
<tjaalton> probably should be removed already
<maxiaojun> ok, you will do it 14.04?
<tjaalton> do what?
<tjaalton> remove -current? probably
<maxiaojun> remove nvidia-current
<bjsnider> maxiaojun, i put the 319 blob in the x-updates ppa recently
<maxiaojun> cool, latest is 319.60 now...
<bjsnider> i don't understand your point
<pepee> hi. can someone give an estimation on when will this be merged?  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1232557
<ubottu> Ubuntu bug 1232557 in xserver-xorg-video-ati (Ubuntu Saucy) "X.Org Server terminates when I close video player or run glxgears" [High,Triaged]
<soee> guys do you have problems with dependencies when trying to install 331 on saucy ?
<bjsnider> you might offer some specifics
<soee> yes one second
<soee> http://pastebin.com/6DaZEsG6
<bjsnider> what happens if you try to install nvidia-settings-331?
<bjsnider> the other two are no problem because they're replaced
<soee> http://pastebin.com/vs8HRzpQ
<bjsnider> did you try -f install?
<soee> yes it does nothing
<soee> http://pastebin.com/4WXh5sM5
<soee> atm i have 325 installed from exgers repo
<soee> its on laptop with optimus technology so i also have bumblebee
<bjsnider> well, that response by apt doesn't make sense given what the packaging scripts say
<bjsnider> so something else is going on
<bjsnider> those two packages have provides: conflicts: replaces: on them. there should be no complaint
<soee> yeah i have no idea whats the problem here exactly
<bjsnider> hold on i'll check the scripts
<soee> ok, thank you
<bjsnider> yep, provides conflicts replaces
<bjsnider> there's no reason for that thing to fail, and you also have a 204 problem
<bjsnider> 304 i mean
<bjsnider> soee, what does the bumblebee software carry along with it?
<soee> bjsnider, could you explain a bit more: what does the bumblebee software carry along with it ?
<bjsnider> well, what do you have to install and configure to get it to work
<ricotz> bumblebee packaging needs to be patched a bit to "work" with 331
<bjsnider> ok, that's the thing then. that's all i could think of
<soee> well basically im installing bumblebee with primus to be able to run alls with nvidia 
<soee> ricotz, so the bumblebee is the reason if this conflicts ?
<ricotz> soee, yes
<soee> ricotz, ok good to know
<soee> bjsnider, thak you for your help
<bjsnider> seems like it's complaining about 304 as well
<ricotz> soee, pushed an updated bumblebee which is suppose to fix this
<soee> ricotz, how long may it take till it shows up in repo ?
<ricotz> 20min or so
<soee> ok so ill test it today
<ricotz> soee, keep in mind 331 is beta and 325 the stable one, so special things might break
<soee> ok ill keep it in mind
<bjsnider> 331 causes the computer to spin out gold through the usb ports, so naturally it's popular
<soee> bjsnider, ricotz is gone but hes changes fixed the problem, im going to install 331 now
<bjsnider> good show old sod
<soee> bjsnider, finished but maybe take a look at some warnings http://pastebin.com/A2fnpca6
<soee> brb
<bjsnider> no big deal
<bjsnider> i guess you language settings are screwed up
<soee> ok, all seems to work fine
<soee> bjsnider, yeah maybe on this kubuntu beta2 there is some problem
<tjaalton> pepee: I'll upload it in a bit
<tjaalton> pepee: waiting in the queue
<pepee> cool, thanks tjaalton 
#ubuntu-x 2014-09-29
<hyperair> hmm, so i just managed to try ubuntu out with a displaylink monitor, and it looks like the screen doesn't refresh at all unless the cursor moves around in it
<hyperair> then it only refreshes the square in which the cursor is in
<hyperair> ooh setting refresh to 59.90 worked
<hyperair> how strange
<hyperair> hmm, 60.1 works too
<mlankhorst> hyperair: let me guess, usb displaylink with modesetting?
<hyperair> mlankhorst: yeah
<mlankhorst> using which driver?
<hyperair> mlankhorst: udlfb?
<mlankhorst> hyperair: no i mean, are you on intel, nouveau or ati?
<hyperair> intel
<mlankhorst> hyperair: SNA?
#ubuntu-x 2014-09-30
<hyperair> mlankhorst: yep, SNA
#ubuntu-x 2014-10-03
<dupondje> tjaalton: seems like one of my both bugs got fixed upstream
<dupondje> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=linux-3.17&id=6fbb702e27d78ad2458df048b58cca3454bc0965
<dupondje> gotto test first
#ubuntu-x 2015-09-29
<furkan> for the remote possibility that somebody is wondering... my dpms issue seems to have been fixed with a recent update
<nobuto> hello, can somebody take a look at https://launchpad.net/bugs/1500504 ? It affects my daily use, but I have no idea what I should try next.
<ubottu> Launchpad bug 1500504 in xserver-xorg-input-synaptics (Ubuntu) "[FUJITSU FMVS90TB] SynPS/2 Synaptics TouchPad detected, but not working at all" [Undecided,New]
<tjaalton> lacking kernel support then
<tjaalton> if evtest doesn't work
<tjaalton> or doesn't show events
<nobuto> tjaalton: ok sad... but thanks anyway.
<tjaalton> you might try if the bios has an option to use i2c for it, that could work
<nobuto> tjaalton: I checked BIOS, but it only had touchscreen on/off. I could not find advanced options such as i2c.
<tjaalton> ok
#ubuntu-x 2015-10-01
<flexiondotorg> tseliot, I'm the Ubuntu MATE lead.
<tseliot> tseliot: hi
<flexiondotorg> tseliot, I've been trying to educate the Ubuntu MATE community to raise bugs rather than whine into the ether.
<tseliot> it sounds like a good idea ;)
<flexiondotorg> From a discussion on G+ I persuaded a couple of user to file the following - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1501658
<ubottu> Launchpad bug 1501658 in xorg (Ubuntu) "Missing fonts and flickering font rendering" [Undecided,Confirmed]
<flexiondotorg> Have tested Ubuntu myself, but this appears to affect Ubuntu MATE, Lubuntu, Xubuntu and Kubuntu.
<flexiondotorg> Relevant to nouveau only.
<flexiondotorg> Installing the nvidia proprietary driver resolves the issue.
<flexiondotorg> How can I help progress this?
 * tseliot looking
<tseliot> flexiondotorg: is the problem solved by installing the nvidia driver or by installing the intel microcode?
<flexiondotorg> I'll get on the bug and get them to reply.
<tseliot> flexiondotorg: thanks
<flexiondotorg> yw
#ubuntu-x 2015-10-03
<alkisg> Hi, is `-nolisten tcp` now somehow "embedded" as a Xorg default? It is not listening in 15.10, and in `man Xserver` I can't see the opposite `-listen tcp` option to enable it...
<alkisg> `ps` says: X :7 vt7 -auth /path/toxauthority -depth 16 -br
<alkisg> ...I didn't define -nolisten tcp
<alkisg> yet netstat says that Xorg has no open ports in 6000 etc
<alkisg> (this is part of the LTSP code, which was running fine until my latest 15.10 tests)
<alkisg> OK I tried `-listen tcp` and it works, but I don't see it documented anywhere, I don't know when it was introduced so that I check properly in the ltsp code when we should pass it and when not...
<alkisg> Got it, http://cgit.freedesktop.org/xorg/xserver/commit/?id=cc59be38b7eff52a1d003b390f2994c73ee0b3e9
#ubuntu-x 2016-10-06
<tseliot> ricotz, mamarley: hey, did you get back to Philip Langdale, or shall I?
<mamarley> tseliot: I didn't say anything to him.
<tseliot> ok, as I think I have fixed his problem in my local branch
<mamarley> Cool, if you let me know what you did, I can apply the fix in the PPA packages too.
<tseliot> sure, I have a couple of fixes, and I can give you the patches after I'm done testing them
<mamarley> Thanks!
#ubuntu-x 2017-10-02
<tjaalton> yes
<tjaalton> ricotz: so there's going to be a special OEM kernel for xenial which is based on artful + newer drm, currently on dinq commit that enabled CFL
<tjaalton> this is why nvidia needed patching
<ricotz> tjaalton, oh, interesting
#ubuntu-x 2017-10-03
<soee> mamarley: https://devtalk.nvidia.com/default/topic/1024719/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-387-12-beta-/
<soee> this would be new beta version ?
<ricotz> it absolutely is! ;)
<soee> ricotz: packaging ?
<ricotz> soee, will take a look
<soee> \o/
<ricotz> soee, mamarley, I guess basic smoketesting worked out here, will upload to personal staging ppa
<ricotz> soee, I assume you are on artful?
<soee> ricotz: no, no
<soee> I'm on Xenial (Neon)
<ricotz> ok
<ricotz> mamarley, soee, it is up
<soee> :D
<soee> hmm 
<soee> somehow it does not see yet updates for me
<soee> ah wait i have to install it
<ricotz> tjaalton, fyi, nvidia 387.12 beta has "drm-next" support
<soee> reboot
<mamarley> ricotz: Awesome, thanks!
<soee> and back
<mamarley> (I was in an all-day meeting today so I didn't see this message until now.)
<soee> https://i.imgur.com/h00dz3Z.png
<soee> thanks for packaging :)
 * mamarley is leaving now and will install it when he gets home.
<mamarley> I will probably just copy it into my own staging PPA so I don't have to add yet another PPA to all my boxen.
<ricotz> mamarley, it makes more sense to actually use the official ppa packages yourself too, aka using *the* ppa ;)
<mamarley> Oh, you've already copied it?
<mamarley> Indeed you have.  OK.
<mamarley> I'll go ahead and package nvidia-settings then if you haven't already done that.
<ricotz> mamarley, haven't done settings, I didn't plan to though
<mamarley> I am going to put it in my staging PPA anyway.  If you don't want it in the main PPA yet, that is fine.
#ubuntu-x 2017-10-05
<ricotz> tjaalton, hi, I assume you will need llvm-5.0 backports too soon?
<tjaalton> ricotz: yes, I have it on x-staging
<tjaalton> though fails to build on some archs
<ricotz> oh, nice
<ricotz> I pushed some no-change rebuilds to xedgers
<tjaalton> I guess you don't build on ppc et al?
<ricotz> I see, arm64
<ricotz> I think powerpc is deprecated?
<ricotz> (and ppc64el worked)
<tjaalton> powerpc might be
<ricotz> tjaalton, did you talk about that with chris?
<tjaalton> no
<ricotz> but I guess it still needs to be build successfully
<ricotz> firefox/rust will need llvm-5.0 too soon, so better have it prepared
<ricotz> of course trusty/zesty are needed too
<ricotz> chrisccoulson, hi, is this on your agenda or will this be delegated? ^
<tjaalton> zesty still built powerpc binaries
<ricotz> yeah, no way to ignore it
<tseliot> nvidia 384 is in artful-proposed
<ricotz> tjaalton, btw, better add a trailing "~" for tight build-deps like on libclc in mesa for easier backports
<tjaalton> yep
#ubuntu-x 2017-10-06
<mamarley> tseliot: I just noticed that the nvidia-graphics-drivers-384 package you uploaded doesn't take into account the fact that libEGL is now handled by GLVND.  If you look at the "rules" file for one of the PPA uploads of 384, you can see what I did to fix that.
<mamarley> Oh wait, he's not hereâ¦
#ubuntu-x 2017-10-07
<ricotz> tjaalton, hi, the llvm-5.0 failure on arm64 is a binutils 2.26 bug -- this should build successful here https://launchpad.net/~ricotz/+archive/ubuntu/mozilla/+packages
<tjaalton> ricotz: oh, coik
<tjaalton> uh
<tjaalton> cool
<ricotz> tjaalton, feel free to point doko to it :)
<tjaalton> sure will, thabks
<tjaalton> shit
<tjaalton> this phone kbd is tiny
<ricotz> heh
#ubuntu-x 2018-10-03
<tjaalton> RAOF: hey, do you have the power to ack packages from NEW?
<RAOF> tjaalton: Nope, sorry. What were you after
<RAOF> ?
<RAOF> (I can do review from NEW for SRUs where the new package is a strict backport from devel, but I can't press the button)
<tjaalton> ah, vulkan pkg split and spirv-tools
<tjaalton> it's for cosmic, have tried pinging -release for weeks and also various folks but nothing helped so far
#ubuntu-x 2018-10-05
<alkisg> Hi, some schools need xserver-xorg-video-r128 and I was wondering why it's not preinstalled, is it because it has known issues and people should be using vesa instead, or just because they're old/rare cards?
<alkisg> I did do a quick test and it seems to work fine on ati rage 128 pro, although it was on a celeron @400mhz so all I could run was glxgears, no firefix/youtube etc...
<tjaalton> just old
<alkisg> Thanks, will install it to my schools. :)
#ubuntu-x 2019-10-01
<KitsuWhooa> I accidentally did a silly thing; Didn't mean to send that here
<tomreyn> KitsuWhooa: it doesn't seem to me / my client that you sent anything here recently other than <KitsuWhooa> I accidentally did a silly thing; Didn't mean to send that here
<KitsuWhooa> Oh, even worse :p
<KitsuWhooa> Thanks for letting me know
<tomreyn> you're welcome ;)
