#ubuntu-x 2006-09-18
<Ubugtu> New bug: #61133 in xorg "Lack of attendance of graphic card 3Dfx voodoo in Edgy Eft." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61133
<Ubugtu> New bug: #61137 in xserver-xorg-video-ati "Xserver freezes when running glxgears" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61137
#ubuntu-x 2006-09-19
<Ubugtu> New bug: #61234 in xserver-xorg-video-i810 "640x480 with i855gm in edgy, OK in dapper" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61234
<Ubugtu> New bug: #61250 in xorg "xorg consumes 99.9% CPU and hangs on Kubuntu Dapper" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61250
<Ubugtu> New bug: #61267 in xorg "xlibmesa-glu-dev is not available in Edgy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61267
<Ubugtu> New bug: #60905 in linux-source-2.6.17 "[acx111]  default firmware not working for acx d-link dwl-g650+" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60905
<Ubugtu> New bug: #61284 in xorg "When mouse is plugged in, it should just work" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61284
<Ubugtu> New bug: #61306 in xserver-xorg-driver-i810 "performance issue in Edgy with i810 driver" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61306
#ubuntu-x 2006-09-20
<Ubugtu> New bug: #61315 in linux-restricted-modules-2.6.17 "Have to reinstall linux-restricted-modules after every reboot" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61315
<Ubugtu> New bug: #61331 in xorg "extremely bold ttf fonts in kubuntu (edgy)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61331
<Ubugtu> New bug: #60999 in linux-source-2.6.15 "/lib/firmware/acx/2.6.15-26-386/acx/default wrong" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60999
<Ubugtu> New bug: #61363 in libxv (main) "I was watching an mpeg-1 someone made for me from #gimp using xvidcap software, at the end it crashed." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61363
<Ubugtu> New bug: #61399 in xorg "XkbGetKeyboard returns null" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61399
<Ubugtu> New bug: #61410 in xorg-server "X does not start on Pegasos in Edgy because of broken PCI domain support" [Unknown,Unknown]  http://launchpad.net/bugs/61410
<Ubugtu> New bug: #61420 in xserver-xorg-driver-i810 "AIGLX is not turned on by default for 855GM cards" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61420
<Ubugtu> New bug: #61422 in xserver-xorg-driver-i810 "Whiteout when playing UFO:Alien Invasion" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61422
<Ubugtu> New bug: #61451 in linux-restricted-modules-2.6.17 "totem-xine very slow since fglrx 7.0.0-8.25.18+2.6.15.11-5" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61451
<Ubugtu> New bug: #61471 in xserver-xorg-video-i810 "Hardware acceleration broken for Intel 855GM graphics" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61471
#ubuntu-x 2006-09-21
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #61603 in linux-restricted-modules-2.6.17 "nvidia module not found" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61603
<Ubugtu> New bug: #61607 in xserver-xorg-video-ati "3d rendering performance regression Dapper->Edgy with Radeon 9600 M10" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61607
<Ubugtu> New bug: #61614 in xserver-xorg-video-i810 "[edgy]  Cannot choose refresh rate" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61614
<mvo> hey rodarvus, good morning!
<rodarvus> hi mvo!
<mvo> rodarvus: do you have any idea why recently emacs fonts starts to look ugly? did something in the fonts changed?
<rodarvus> not recently, no
<mvo> hm, ok
* mvo starts digging
<rodarvus> there was a bug on xfonts-base, it was "missing" a pre-depends
<rodarvus> but this is supposed to be fixed long ago
<Ubugtu> New bug: #61695 in xserver-xorg-video-ati "dri crash" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61695
<Ubugtu> New bug: #60823 in xorg "Please provide xlibs compatibility package" [Wishlist,Confirmed]  http://launchpad.net/bugs/60823
<Ubugtu> New bug: #61720 in xserver-xorg-video-vesa "vesa driver extremely slow after upgrade from xorg 7.0.0 to 7.1.1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61720
<Ubugtu> New bug: #61746 in xorg-server "Xorg exits when it receives an ACPI button/lid event" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61746
#ubuntu-x 2006-09-22
<Ubugtu> New bug: #61788 in linux-restricted-modules-2.6.17 "Error inserting ath_pci" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61788
<Ubugtu> New bug: #61766 in Ubuntu "Human Theme Artifacts" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61766
<Ubugtu> New bug: #61844 in linux-restricted-modules-2.6.17 "NVIDIA 3d drivers can be configured by GUI" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61844
<Ubugtu> New bug: #61865 in linux-restricted-modules-2.6.15 "Atheros (madwifi) card not recognized after upgrade to 2.6.15-27" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61865
<Ubugtu> New bug: #61883 in xkeyboard-config "abnt2 layout broken when using evdev driver." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61883
<Ubugtu> New bug: #60448 in xorg (main) ".xsession_errors file grows out of control & saturates disk space" [High,Confirmed]  http://launchpad.net/bugs/60448
#ubuntu-x 2006-09-23
<Ubugtu> New bug: #61951 in xserver-xorg-driver-i810 "965/x3000 video not supported" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61951
<Ubugtu> New bug: #61144 in xorg (main) "edgy: remote desktop server fails to find font." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61144
<Ubugtu> New bug: #61727 in libxinerama (main) "Desktop size bigger than monitor resolution on the primary screen when using Xinerama" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61727
<Ubugtu> New bug: #61979 in xserver-xorg-video-i810 "[Regression]  2.6.17-8-generic makes X crash if DRI is enabled in xorg.conf" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61979
#ubuntu-x 2006-09-24
<Ubugtu> New bug: #62106 in linux-restricted-modules-2.6.17 "Cannot set modes other than 'Managed' on Atheros based wifi card" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62106
<Ubugtu> New bug: #62113 in xorg "Xorg D-states on initialisation" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62113
<Ubugtu> New bug: #62135 in xserver-xorg-driver-i810 "Support for Intel 965 (GMA X3000) doesn't work" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62135
<Ubugtu> New bug: #61297 in update-manager "X crash when trying to download last linux-image.... changes!" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61297
<Ubugtu> New bug: #62180 in xorg "glxinfo crash X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62180
#ubuntu-x 2007-09-18
* Starting logfile irclogs/ubuntu-x.log
<sbalneav> Evening all
<Q-FUNK> hiya Scott
<sbalneav>  Quick question: I'm trying to debug Bug #140051  I've installed the xserver-xorg-driver-amd-dbg package, but I'm still 
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [Undecided,New]  https://launchpad.net/bugs/140051
<sbalneav>                   only getting a hex address in the dump from xorg, with no indication as to what routine it dies in.  Any ideas as to how 
<sbalneav>                   I might at least narrow it down to a subroutine within the driver?
<sbalneav> bryce: about?
<bryce> hi sbalneav
<sbalneav> Hey, any thoughts on how I might obtain a little bit better debugging info on Bug #140051?
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [Undecided,New]  https://launchpad.net/bugs/140051
<sbalneav> When I get the bt from xorg, once it pops into the amd_drv.so, there's nothing but a hex offset.
<bryce> hmm
<bryce> have you seen https://wiki.ubuntu.com/DebuggingXorg and https://help.ubuntu.com/community/DebuggingXAutoconfiguration ?
<bryce> another trick:  strace -s 512 -p $(pidof X) 2>/root/x.log &
<bryce> I've heard there is also an 'Xorg -verbose' option but haven't played with that myself
<bryce> also, make sure you have the dbg packages for -amd installed
<sbalneav> Got that installed, thanks for the links, I'll check 'em out
<ubotu> New bug: #140606 in xserver-xorg-input-synaptics (main) "Please sync xserver-xorg-input-synaptics with Debian testing (better tuned for appletouch/ALPS)" [Undecided,New]  https://launchpad.net/bugs/140606
<tepsipakki> bryce_: yep, I'll poke someone today to get the new ati in
<tepsipakki> I'll also merge with the latest version in experimental
<ubotu> New bug: #140624 in xorg (main) "when i start wincfg or wine ,xorg crashes and back to login window" [Undecided,New]  https://launchpad.net/bugs/140624
<mvo> bryce_: I would like to upload http://launchpadlibrarian.net/9337645/xserver-xorg-video-intel_2.1.1-0ubuntu3.debdiff  tonight if you are ok with that
<tormod> tepsipakki: I am looking at the changelog of ati 6.7.192-4ubuntu1: the debian version has commits up to 2d78... I can not find any such commit. I could be a stupid git (user) though :)
<tepsipakki> tormod: heh, true
<tepsipakki> tormod: I mean, there must be a typo, I think :)
<tormod> do you know exactly what is included?
<tepsipakki> I believe the latest change was the one by Michel Dnzer
<tepsipakki> at least that's included
<tormod> from Sept 8, right
<tepsipakki> yep
<tormod> ok thanks. maybe the wrong ID in the changelog is from the debian git repo.
<tepsipakki> ah, right
<tepsipakki> could be
<ubotu> New bug: #139471 in xserver-xorg-video-intel (main) "screensaver preview overlays everything else despite being in a background window" [Undecided,New]  https://launchpad.net/bugs/139471
<ubotu> New bug: #140534 in ubuntu "Launching Googleearth under Compiz crashes X server (dup-of: 130325)" [Undecided,Invalid]  https://launchpad.net/bugs/140534
<ubotu> New bug: #140722 in xorg (main) "xorg uses 100% CPU when exiting Gnome" [Undecided,New]  https://launchpad.net/bugs/140722
<bryce> mvo, yes that looks good to upload
<bryce> heya tepsipakki and tormod
<mvo> bryce: cool, thanks!
<mvo> bryce: are there any news about the new xserver-xorg-core fix for patch 132?
<bryce> yep!  All that's left is to verify it doesn't break ume, and yesterday I worked on getting my ume box going with latest ubuntu.  Today I will figure out how to apply kees' change to it and verify it's all okay
<mvo> great, I found that it breaks fglrx too so now I have a personal interesst ;)
<bryce> yeah I suspected that might be the case
* mvo uploaded xserver-xorg-video-intel and waits for the fallout
<bryce> btw, did you let kyle know?
<tepsipakki> bryce_: hey, pitti promised to take a look at the UVFe request, but didn't have time I guess
<mvo> bryce: oh, right *cough*
<mvo> kylem: I uploaded a new -x-x-video-intel package with a patch to make it use overlay video on < i965 cards (just FYI) 
<kylem> fine by me as long as its ok with bryce
<bryce> kylem: yeah I reviewed and it basically just removes a texturedAdaptor for 965G
<kylem> ok.
<bryce> it looks like there's a low chance of it altering behavior for non-965 chips
<ubotu> New bug: #139180 in linux-source-2.6.22 (main) "[Gutsy]  PCI: Failed to allocate mem resource (dup-of: 54294)" [Undecided,New]  https://launchpad.net/bugs/139180
<keescook> bryce: while you prepare the new xorg-server, can you add the patch to fix CVE-2007-4730?  (as you recommend: prior to the 107 patch?)  I will email it to you.
<bryce> sure
<keescook> thanks.  I seems that edgy and feisty also have it disabled, but not dapper, so I'll release an update for that.
<bryce> excellent
<bryce> I'm still trying to figure out a way to get your fix tested on the ume box.  I've updated it to latest and I think I can just compile it for lpia and then copy the deb over on usb...
<bryce> (the network on it is busted)
<tormod> bryce, displayconfig-gtk can not set up dual-head on the new ati driver (should use xrandr instead of zaphod) https://bugs.freedesktop.org/show_bug.cgi?id=12295  Is this a well known issue?
<bryce> I think it is but don't know a bug ID offhand
<bryce> I know that "doesn't support xrandr" is a known issue in the TODO
<bryce> I recall seeing a bug that dual head was not supported on either ati or nv but don't recall which
<tormod> maybe it should disabled then, depending on the driver?
<tormod> * should be
<tormod> I mean, the dual head set-up in displayconfig-gtk
<bryce> possibly
<bryce> did it cause breakage?
<tormod> yes it makes an xorg.conf that makes the server crash
<bryce> ok, put in a bug report about it if there isn't already one.  if you're comfortable patching displayconfig-gtk a patch would be great
<tormod> IMOH the server shouldn't just crash because of the xorg.conf, but you know what upstream thinks.
<jcristau> upstream thinks it shouldn't crash, but doesn't care enough to fix it, afaics :)
<bryce> "send a patch" ;-)
<bryce> well I suspect their strategy is to make the need for an xorg.conf go away
<bryce> personally I think *some* kind of configuration is always going to be needed, so they really need a wider strategy
<bryce> however I'm not ready to send a patch so am keeping my mouth shut ;-0
<tormod> where is the displayconfig-gtk source anyway? the bazaar link on the wiki page is stale.
<bryce> it's in bzr, hang on I'll get you a link
<bryce> https://code.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
<tormod> thanks, I'll update the wiki page.
<bryce> great
<tormod> oh my, that URL on the wiki page was ok, it's just that it is a bzr URL and not a web link.
<tormod> hmm I can not build displayconfig-gtk on feisty, needs a newer python-distutils-extra :(
<tormod> tepsipakki: I guess this has been asked before, but what is holding back the ati driver?
<bryce> yeah, I've only built it on gutsy
<tepsipakki> tormod: no-one reviewing it
<bryce> tepsipakki: who do we need to review it?
<tepsipakki> bryce: someone of the release-manager team
<tepsipakki> I subscribed them to the bug earlier today
<bryce> like pitti?
<tepsipakki> yes
<bryce> one sec
<bryce> hrm, looks like he's offline for the day
<tormod> are we in beta-freeze?
<bryce> not yet afaik
<tormod> no, I get it. UVF.
<tepsipakki> two days until beta-freeze
<tormod> it's pretty important to get it in before beta, right?
<bryce> extremely
<tepsipakki> bryce: alex said that he'll do .193 later this week
<bryce> probably if we don't get it in by beta it most likely ain't going in
<bryce> tepsipakki: ok
<bryce> what's the bug id for the -ati package again?  I'll ask riddell
<tepsipakki> bug 138987
<ubotu> Launchpad bug 138987 in xserver-xorg-video-ati "[UVF]  new version, 6.7.192 + fixes from git master" [Undecided,New]  https://launchpad.net/bugs/138987
<tormod> rather get 192 in now, and patch in the 193 changes later, won't need UVFe for that.
<tepsipakki> then the changes are smaller so probably easier after .192 is in
<bryce> right
<bryce> I've asked riddell but suspect he's also afk
<bryce> heya seb128
<tormod> try mithrandir
<seb128> hi bryce
<tormod> or cjwatson
<bryce> cj would have me work through one of the others
<bryce> I think pitti or riddell will be on eventually; I'll keep an eye out for them
<bryce> meanwhile...  I am working on new packages for xorg and xorg-server.  So far just one change each.  Either of you know of more patches that need included in those?
<bryce> btw, the change for xorg is to disable the wacom entries, as per henrik's direction.  I'm a little concerned what that's going to break for people.
<tepsipakki> well, they'll be stripped after gutsy anyway
<bryce> yup, but then presumably the input hotplug will start taking over
<tepsipakki> right
<ubotu> New bug: #140794 in xserver-xorg-video-intel (main) "xserver-xorg-video-intel contains no changelog.Debian" [Undecided,New]  https://launchpad.net/bugs/140794
<tormod> bryce, I built feisty packages from the new ati version. Can you mirror them on your Testing/xorg-server-backports-feisty ?
<bryce> sure, url again?
<tormod> http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati_6.7.192-4ubuntu1feisty_i386.deb
<tormod> and http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati-dbg_6.7.192-4ubuntu1feisty_i386.deb
<tormod> thanks a lot!
<tormod> bryce: did you download my debs?
<ubotu> New bug: #140811 in xserver-xorg-video-ati (main) "radeon driver bug causes suspend to fail" [Undecided,New]  https://launchpad.net/bugs/140811
<bryce> tormod: sorry, distracted
<bryce> tormod, ok they're copied
<tormod> bryce: thanks
#ubuntu-x 2007-09-19
<tormod> good night
<ubotu> New bug: #140820 in xserver-xorg-input-synaptics (main) "synaptics touchpad won't left click, right click, or vscroll after recent change in gutsy" [Undecided,New]  https://launchpad.net/bugs/140820
<ubotu> New bug: #38498 in xserver-xorg-video-ati (main) "xorg does not preserve acpi/ibm/video mode" [Medium,Incomplete]  https://launchpad.net/bugs/38498
<ubotu> New bug: #38653 in xserver-xorg-video-ati (main) "[RV350]  Permanent resolution degradation after external CRT usage" [Medium,Incomplete]  https://launchpad.net/bugs/38653
<ubotu> New bug: #39684 in xserver-xorg-video-ati (main) "Screen wents blank on system beep" [Medium,Incomplete]  https://launchpad.net/bugs/39684
<ubotu> New bug: #41357 in linux-restricted-modules-2.6.15 (restricted) "TV-OUT no longer works" [Medium,Incomplete]  https://launchpad.net/bugs/41357
<ubotu> New bug: #41244 in linux-restricted-modules-2.6.15 (restricted) "Fritz!Card PCMCIA driver does not work" [Medium,Incomplete]  https://launchpad.net/bugs/41244
<ubotu> New bug: #41845 in linux-restricted-modules-2.6.15 (restricted) "nvidia xorg driver stopped working when upgrading to dapper" [Medium,Incomplete]  https://launchpad.net/bugs/41845
<ubotu> New bug: #42248 in xserver-xorg-input-synaptics (main) "[Dapper]  Can not turn off touch tapping on Alps touch pad" [Medium,Incomplete]  https://launchpad.net/bugs/42248
<ubotu> New bug: #140836 in xserver-xorg-video-intel (main) "latest xserver-xorg-video-intel breaks desktop effects" [Undecided,New]  https://launchpad.net/bugs/140836
<ubotu> New bug: #42445 in xserver-xorg-video-ati (main) "Cannot change screen resolution. refresh rate" [Medium,Incomplete]  https://launchpad.net/bugs/42445
<ubotu> New bug: #43413 in xserver-xorg-video-ati (main) "strange striped screen" [Medium,Incomplete]  https://launchpad.net/bugs/43413
<ubotu> New bug: #45474 in xserver-xorg-input-synaptics (main) "touchpad kills keyboard and itself" [Medium,Incomplete]  https://launchpad.net/bugs/45474
<ubotu> New bug: #46934 in xserver-xorg-input-synaptics (main) "Touchpad Scrolling on Laptop Samsung X20" [Medium,Incomplete]  https://launchpad.net/bugs/46934
<tepsipakki> yay, there goes a new ati... uploaded
<tepsipakki> s/a/the/
<tepsipakki> and a new nvidia blob released
<tepsipakki> adds support for quadro fx 570 among other things.. and the stinkpad T61p which I'll get in a week or so has one..
<bryce> heya
<tepsipakki> hi, I uploaded the new ati
<tepsipakki> hobbsee and pitti ack'ed it
<bryce> awesome
<bryce> yeah I talked with hobbsee earlier about it
<ubotu> New bug: #140904 in xorg (main) "Mouse set up suboptimal in vmware VM." [Undecided,New]  https://launchpad.net/bugs/140904
<tormod> tepsipakki, your new stinkpad: you'll get hands-on with bug #138718 then.
<ubotu> Launchpad bug 138718 in xorg "gdm greeter crashes when X is using vesa driver" [Undecided,New]  https://launchpad.net/bugs/138718
<tepsipakki> tormod: great, sounds fun :)
<tormod> bryce, does discover guess around if it doesn't find a full pci id match?
<TomaszD> tormod, ?
<tormod> are you able to identify what change made the sis driver work?
<TomaszD> according to the sis gitlog, there weren't that many changes 0.9.3 -> current, but no, I can't
<TomaszD> it just started working flawlessly and even a bit quicker than in feisty, so I'm all happy
<tormod> if we can backport the needed change into Gutsy, everybody will be happy :)
<TomaszD> however, it would be nice to include a proper fix for gutsy, we can't expect people to compile drivers :] 
<TomaszD> yeah, that would be nice
<TomaszD> however I'm just a translator with some compiling experience, but by no means a dev, I write articles about Ubuntu for money, not programs :] 
<tormod> if you already can compile, and have a sis card to test, you can be very useful
<TomaszD> tormod, cool, I'm here if need be
<tormod> there are not many git changes since 0.9.1, shouldn't be too difficult to narrow it down
<TomaszD> exactly
<TomaszD> you mean 0.9.3 right? this is the version gutsy has
<TomaszD> tormod, ? 
<tormod> TomaszD: yes I guess so :)
<TomaszD> ok
<tormod> did you try just recompiling the gutsy package as well?
<tormod> anyway what is the bug report number?
<TomaszD> tormod, but the gitlog got me thinking that quite possibly the original package just needs a recompile
<TomaszD> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/118325
<ubotu> Launchpad bug 118325 in xserver-xorg-video-sis "sis dri DDX interface outdated" [Medium,Triaged]  
<TomaszD> brb
<tormod> maybe it just needs "Define SIS_*_VERSION using PACKAGE_VERSION*"
<tormod> TomaszD: with beta-freeze tomorrow, today is a good day to sort this out :)
<tormod> or it needs "Get rid of the XFree86Server macro." but I just keep guessing here. I'll need to look at the code later.
<TomaszD> tormod, holy crap
<TomaszD> tormod, how do I re-compile the ubuntu package?
<TomaszD> damn it, brb
<tormod> TomaszD: see Building Drivers on https://wiki.ubuntu.com/XorgOnTheEdge
<ubotu> New bug: #140984 in xorg (main) "X server crashes reproducably with vnc viewer for java (4.0) via firefox" [Undecided,New]  https://launchpad.net/bugs/140984
<ubotu> New bug: #140880 in xserver-xorg-input-keyboard (main) "Swedish keyboard is not working - gutsy" [Undecided,New]  https://launchpad.net/bugs/140880
<bryce> tormod, I don't think that discover guesses around, but the xserver postinst script isn't shy about making bold guesses if it has incomplete info
<tormod> bryce: are you sure there are no default to nv for a "default nVidia card" or similar?
<bryce> it may, I'm not sure there
<tormod> bryce: re bug #133385, I can not see the pci id in discover-data, but it chooses nv
<ubotu> Launchpad bug 133385 in xserver-xorg-driver-nv "[gutsy]  "nv" is not new enough to support my chipset (Quadro FX 570M), but is detected as the most appropriate display driver during installation" [Undecided,Confirmed]  https://launchpad.net/bugs/133385
<bryce> like, if it knows its an nvidia pci-id but doesn't match the model number, it'd probably be safe for it to guess -nvidia
<tormod> bryce: how do I patch discover-data correctly? is .lst generated from .xml or visa versa?
<bryce> .xml is the thing to update
<bryce> then run `make pci-26.lst pci.lst`
<tormod> what would the canonical model_name be? what I get from http://pci-ids.ucw.cz ?
<bryce> You can try looking them up on the discover-data sourceforge website, however if it's not already in the .xml it's likely not to be on that website
<bryce> I don't know that there is a programmatic way to get the name... maybe from dmesg?  worst case, if you have the packaging for the product, or can look it up on the manufacturer website, that would give a suitable name
<bryce> you can submit missing pciid mappings through the pciid sourceforge project page; they will sanity check the names
<bryce> sorry, Isaid 'discover data sourceforge website', I meant pciid sourceforge website
<TomaszD> tormod, sorry for leaving for so long, but I had major issues with my wireless router
<tormod> bryce: so I run `make pci-26.lst pci.lst` before I rebuild the source package?
<bryce> yup
<TomaszD> tormod, I'm gonna try recompiling the gutsy sis package if you can guide me how to do that
<TomaszD> ah, just noticed the link in the log
<bryce> TomaszD: I suspect that your issue may not be an issue in the packages themselves, but rather could be due to mixing self-compiled packages with ones from the ubuntu repos
<tormod> bryce: that failed: xml.sax._exceptions.SAXParseException: pci-device.xml:35150:2: mismatched tag
<tormod> bryce: he was using repo packages. His own works.
<TomaszD> yep.
<bryce> ah, then maybe we simply need to put in a rebuild request for one of the packages (-sis?) in the repository
<TomaszD> it's worth a try
<TomaszD> there doesn't seem to be any major changes between the git version and the ubuntu version, only some minor cleanups
<bryce> yup
<tormod> bryce: I just missed a / in the xml. "make" works now.
<bryce> also I ran across a similar error someone saw, but not with -sis and not on ubuntu.  The issue in that case was just needing to rebuild one of the packages
<bryce> tormod, luv xml
<TomaszD> bryce, so will you do it? :] 
<bryce> tormod, kylem and I are thinking we should rip all that data out of the xml discover-data package and create a new thing, maybe more flatfile-ish
<tormod> bryce: and we'll have discover2 as well :)
<tormod> or discover-3 or whatever
<bryce> yup, -3
<TomaszD> a rebuild won't hurt and may certainly help
<bryce> TomaszD: one sec
<bryce> keescook: would you mind kicking a rebuild for xserver-xorg-video-sis?
<bryce> keescook: it hasn't gotten updated in a while, and we think there's an abi mismatch that should resolve if it is just rebuilt against current gutsy libs
<jcristau> an abi mismatch?
<TomaszD> yes, SiS DRI driver expected DDX version 0-0.8.x but got version 0.7.1
<jcristau> 391dad44fa305be4cded31cf2f9a4fba7420af99 would fix that afaics
<jcristau> #if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(6,8,99,900,0) isn't going to be true just because the driver gets rebuilt
<tormod> bryce: I made a debdiff for 133385. Can you bless it?
<tormod> TomaszD: would you be able to try out the gutsy version with the patch from http://cgit.freedesktop.org/xorg/driver/xf86-video-sis/diff/?id=391dad44fa305be4cded31cf2f9a4fba7420af99 ?
<bryce> tormod, certainly
<TomaszD> tormod, after supper, but I don't know how to apply patches
<TomaszD> brb
<ubotu> New bug: #121906 in xorg (main) "Gutsy Tribe 1 installer does not configure X to use ATI driver for ATI All-In-Wonder Radeon 8500 DV (R200 chipset)" [Medium,Incomplete]  https://launchpad.net/bugs/121906
<tormod> keescook: can you sponsor 133385 please?
<keescook> tormod: sure, I'll look in a second, just finishing some email now
<ubotu> New bug: #141043 in xrandr (main) "xrandr doesn't work with non-rectangular display" [Undecided,New]  https://launchpad.net/bugs/141043
<tormod> TomaszD: I explained how to patch and build in the bug report.
<TomaszD> tormod, thanks
<TomaszD> patching...
<TomaszD> compiling...
<TomaszD> built, installed, reloding session, keep your fingers crossed
<keescook> tormod: thanks, uploaded.
<TomaszD> tormod, direct rendering: Yes
<tormod> TomaszD: great
<TomaszD> either the patch worked or just the rebuild worked :] 
<tormod> bryce, I'll make a debdiff for it
<bryce> awesome
<jcristau> TomaszD: there's no way a simple rebuild would have changed anything...
<TomaszD> jcristau, if you say so :]  I'm just guessing
<TomaszD> apt wants to update that package now, from version 1:0.9.3-2 to... 1:0.9.3-2, so the same version
<TomaszD> interesting :] 
<tormod> TomaszD: nothing to care about, it just prefers packages from the repo.
<TomaszD> ah ok
<tormod> bryce: debdiff attached, can you bless it?
<bryce> bug id?
<jcristau> i guess i should update the debian package to git master... but it seems nobody uses sis :)
<jcristau> bryce: bug 118325
<ubotu> Launchpad bug 118325 in xserver-xorg-video-sis "sis dri DDX interface outdated" [Medium,Triaged]  https://launchpad.net/bugs/118325
<tormod> jcristau: the one user is on Ubuntu :)
<TomaszD> lol
<bryce> jcristau, have you heard of a bug on 965 with display artifacts or lockups after xrandr -o 1?
<TomaszD> people use them, but they don't care about dri
<TomaszD> probably don't even know what dri is
<tormod> only a few of the sis cards runs DRI anyway
<TomaszD> true
<TomaszD> I get mind boggling 230FPS in glxgears
<TomaszD> :] 
<tormod> TomaszD: that makes it worth the effort :) It's in gusty now - thanks keescook.
<TomaszD> thanks everyone, glad it made through before beta freeze :] 
<bryce> tormod: done
<bryce> good work you two :-)
<tormod> oops it's not in yet - that was the other debdiff...
<keescook> oop, did I miss something?
<tormod> keescook: can you sponsor #118325 please?
<keescook> tormod: sure, building now
<tormod> keescook: thanks!
<jcristau> bryce: not that i remember
<bryce> yeah I can't find a bug report on it at fdo other; I'll submit a new one
<bryce> (bug #129380)
<ubotu> Launchpad bug 129380 in xorg "It does not refresh well when dragging a window in the rotated screen" [Low,Triaged]  https://launchpad.net/bugs/129380
<jcristau> we're a bit drowning under reports about 1.4 atm :)
<bryce> heh, I can imagine
<ubotu> New bug: #141050 in xserver-xorg-driver-ati (main) "xorg crashes when xv is running, compiz is enabled and switch the desktop" [Undecided,New]  https://launchpad.net/bugs/141050
<TomaszD> while I have your attention, where is the best place for laptop acpi whitelisting in Ubuntu? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/92806
<ubotu> Launchpad bug 92806 in linux-source-2.6.22 "N340S8 laptop needs to have ACPI enabled" [Undecided,Confirmed]  
<keescook> tormod: uploaded.  :)
<tormod> keescook: thanks again!
<keescook> tormod: no problem; thanks for getting the diffs together.  :)
<bdmurray> bryce: have you seen bug 137604?
<ubotu> Launchpad bug 137604 in xorg-server "Black Bar Across Screen with gutsy i810" [High,Triaged]  https://launchpad.net/bugs/137604
<joumetal> it has some boring comments, but if there is something I could do, let me know.
<ubotu> New bug: #141063 in xserver-xorg-video-intel (main) "experimental Intel driver freezes system on video play after suspend" [Undecided,New]  https://launchpad.net/bugs/141063
<ubotu> New bug: #139849 in xorg (main) "DRI (direct rendering) has stopped working in Gutsy" [Medium,Confirmed]  https://launchpad.net/bugs/139849
<bdmurray> bryce: where would bug 140999 go?
<ubotu> Launchpad bug 140999 in ubuntu "gutsy xorg detects 1280x800, gnome thinks its 1024x768" [Undecided,New]  https://launchpad.net/bugs/140999
<bryce> bdmurray: gnome-system-tools probably
<bryce> I'm not super familiar with how it determines what resolutions to display, so it's possible it's depending on another lower level tool.
<bdmurray> bryce: cool, looking that the file xresprobe reports 1024x768 but xorg.conf has 1280x800
<bryce> right
<bryce> he said xresprobe reports 1280x800 too, so it's not likely to be an xorg issue directly
<bryce> for some reason this sounds familiar
<bryce> ohh
<bdmurray> I don't think he said xresprobe reports 1280x800
<bryce> gnome must be failing to retrieve resolutions and defaulting to 1024x768
<bryce> sounds related to bug 3731 
<ubotu> Launchpad bug 3731 in xorg "Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect" [Critical,Confirmed]  https://launchpad.net/bugs/3731
<bryce> nope
<bryce> it's dupe of 49827
<bdmurray> bug 49827
<ubotu> Launchpad bug 49827 in xorg "Available resolutions incompletely set to 1024x768, 800x600, 640x480" [High,Confirmed]  https://launchpad.net/bugs/49827
<bdmurray> really?
<tormod> not a dupe, in 49827 xorg gets it wrong
<bdmurray> Right, this seems like the desktop gets it wrong not xorg
<bryce> well, my guess is that gnome is querying gconf for resolutions, which returns those three resolutions when it doesn't know
<tormod> why does gnome try to figure out available modes instead of just looking at the size of the root window? or even something like xdpyinfo?
<bryce> anyway, it sounds a lot like 49827.  but who knows.  In any case, it should be investigated from the gnome angle.
<bryce> oh wait
<bryce> I finally looked at the screenshot
<bryce> this looks like he's got a second input that's getting detected as 1024
<tormod> he's running "clone" with a ghost screen?
<bryce> something like that yeah
<bryce> I've run across something like that before when attaching a clone projector running at a lower rez
<bryce> bdmurray: regarding bug 137604, yeah tepsipakki was looking into that one the other day
<ubotu> Launchpad bug 137604 in xorg-server "Black Bar Across Screen with gutsy i810" [High,Confirmed]  https://launchpad.net/bugs/137604
<bryce> sounds like it's due to one of the backported patches, but we're not sure which one
<tormod> bryce, I forgot to set maintainer on the sis package (ubuntu1). bad me. does that call for a new upload?
<bryce> maybe; I think it'll kick it out if the maintainer is not @ubuntu.com
<tormod> well the changes file says Ubuntu/i386 Build Daemon <buildd@palmer.buildd>
<jcristau> buildds set the Maintainer in .changes with dpkg-buildpackage -m
<tormod> I just downloaded the source and it has been properly changed in debian/control :)
<tormod> I don't know if keescook did it or it was done automatically.
<tormod> I guess https://wiki.ubuntu.com/DebianMaintainerField is in good progress.
<bdmurray> Does anybody have any ideas about bug 130429?
<ubotu> Launchpad bug 130429 in xorg "[feisty]  brief glitch at the bottom of the screen after gdm starts with i915 graphics card" [Undecided,Incomplete]  https://launchpad.net/bugs/130429
<bryce> jcristau: btw, are you packaging radeonhd for debian, or waiting on a release?
<bryce> bdmurray: for that intel blackbar bug, it looks like its due to one of the patched Ibackported.  i'm going to build some debs disabling various things to see if we can narrow in on which one caused it
<jcristau> bryce: http://lists.debian.org/debian-devel-changes/2007/09/msg01755.html
<tormod> bdmurray: must be the intel driver that is not initializing correctly
<bdmurray> bryce: that sounds great.  I can imagine it is rough for those effected.
<bryce> jcristau: thx
<ubotu> New bug: #139845 in ubuntu "no videoplayer works correctly" [Undecided,Confirmed]  https://launchpad.net/bugs/139845
<bryce> bdmurray: I think I've seen bug 130429 on my dell 945gm laptop too, or at least something similar
<ubotu> Launchpad bug 130429 in xorg "[feisty]  brief glitch at the bottom of the screen after gdm starts with i915 graphics card" [Undecided,Incomplete]  https://launchpad.net/bugs/130429
<ubotu> New bug: #141101 in xorg (main) "[UVFe]  Please sync xserver-xorg-video-radeonhd (universe) from Debian experimental" [Undecided,New]  https://launchpad.net/bugs/141101
<jcristau> bryce: -radeonhd build-deps on xserver-xorg-dev (>= 2:1.4), so it can't be synced directly
<bryce> erf.
<bryce> will it compile against 1.3 or is it depending on1.4-isms?
<jcristau> i haven't tried, but i expect 1.3 will be fine
#ubuntu-x 2007-09-20
<bryce> yup, built fine.  Just had to add a build dep for xextproto
<keescook> oop, tormod vanished.  yup, I set the maintainer field for him.
<ubotu> New bug: #141117 in xorg (main) "backlight-decrease key works, increase doesn't (Dell Inspiron 9400, nvidia binary driver)" [Undecided,New]  https://launchpad.net/bugs/141117
<ubotu> New bug: #141118 in xorg-server (main) "[gutsy]  cursor endian problem" [Undecided,New]  https://launchpad.net/bugs/141118
<ubotu> New bug: #141119 in xorg-server (main) "[gutsy]  X locks on console switch on powerbook" [Undecided,New]  https://launchpad.net/bugs/141119
<ubotu> New bug: #141132 in xorg (main) "[gutsy]  strange freeze-up until mouse moves" [Undecided,New]  https://launchpad.net/bugs/141132
<ubotu> New bug: #141146 in xserver-xorg-video-ati (main) "DPI is set incorrectly by new driver, even when DisplaySize is set in xorg.conf" [Undecided,New]  https://launchpad.net/bugs/141146
<bryce> tepsipakki: 6.7.193 is out
<tepsipakki> wow, I'll package that
<tepsipakki> s/package/merge/
<ubotu> New bug: #141152 in xserver-xorg-video-ati (main) "radeon driver crash (gutsy)" [Undecided,New]  https://launchpad.net/bugs/141152
<ubotu> New bug: #141161 in xserver-xorg-video-ati (main) "[regression]  after recent upgrade to 6.7.192-4ubuntu1 dual-head support is broken" [Undecided,New]  https://launchpad.net/bugs/141161
<bryce> feh, -ati has no end of bugs :-)
<jcristau> bryce: 141161 isn't really a surprise, as the randr-1.2 driver drops support for mergedfb and zaphod
<ubotu> New bug: #141207 in ubuntu "black horizontal bar covering 25% of screen as soon as gnome display manager starts up (dup-of: 137604)" [Undecided,New]  https://launchpad.net/bugs/141207
<ubotu> New bug: #64023 in xorg (main) "The system crashes after I login, switch users, login, and switch back" [Undecided,New]  https://launchpad.net/bugs/64023
<ubotu> New bug: #141262 in xserver-xorg-video-vesa (main) "Installing Ubuntu 7.04 and 7.10 tribe 5, can't start X becouse of X1300 (dup-of: 89853)" [Undecided,New]  https://launchpad.net/bugs/141262
<ubotu> New bug: #141288 in xft (main) "Enable sub-pixel rendering" [Undecided,New]  https://launchpad.net/bugs/141288
<bryce> jcristau: right
<bdmurray> bryce: Have you revisited 134284? The reporter provided lspci info
<bryce> oh thanks
<bryce> I think it's too late to get changes in to main though
<bdmurray> I'll approve it. ;)
<bdmurray> bryce: I just noticed that if I switch from vty7 to vty1 things go very bad.
<bdmurray> I have blinking boxes all over the screen and the system responds to no keypresses.  I am using intel on an i915.
<bryce> bdmurray: I've uploaded a debdiff for 134284
<bryce> er, uploaded to the bug report
<bryce> vty7 to vty1 works fine for me on my 945gm laptop; was just playing with that yesterday
<bdmurray> hrm, I'm trying to reproduce it
<bdmurray> I got different weird stuff to happen this time
<bryce> "different weird stuff happens."  heh you're as bad as the bug reporters you complain about brian ;-)
<bdmurray> I haven't submitted a report though. ;)
<bdmurray> I think I have steps to reproduce now.  My poor laptop.
<bdmurray> bryce: Which debugging page will help me gather the right information?
<bryce> heh, we need to simplify all that
<bryce> just the usual - xorg.conf, Xorg.0.log, lspci -vvnn, photo if possible
<bryce> the photo could be quite handy in this case - your problem sounds a lot like these other intel ones that have been reported
<bdmurray> It fully locks up the system.  That'll still be in Xorg.0.log?
<bryce> in fact, it would be helpful if you could see if you're reproducing one of the existing bug reports, as then we'd have hardware we could test on
<bryce> yup, or Xorg.0.log.old
<bryce> depending on how you reboot
<bdmurray> cool
<bryce> two things we're looking for - generic info like versions and such, that will be there regardless, and second any error messages listed at the end, which could prove illuminating
<bdmurray> There are some odd TV out things in my log, I can get it the crash to happen somewhat reliably after watching video.
<bryce> there's some known issues around TV out on the intel card
<bryce> I think they're hardware bugs though - I notice X simply disables tv-out to solve them
<bdmurray> I wasn't hooked up to a TV though
<bdmurray> Is that part of being able to playback video with compiz
<bryce> well the bug was something about the tv-out output being enabled inappropriately - when no tv was in use
<bryce> no, that's a different issue
<bdmurray> Ah, that makes sense
<bryce> hey, do you know who does the release notes for gutsy?  I need to add a bit to it about -ati and mergedfb/xrandr
<bdmurray> With Feisty they were a wiki page and then migrated to www.ubuntu.com
<bdmurray> Or so I thought I'm not finding a Feisty one at the moment
<bdmurray> bryce: do you believe there is an existing bug report in launchapd then or should I submit a new one?
<bryce> I believe there's an existing one
<bdmurray> yeah, bug 127101 is very close
<ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [Undecided,Confirmed]  https://launchpad.net/bugs/127101
<bdmurray> The video shows what I see
* bryce nods
<bdmurray> Is there anything more I can do to help with it?
<bryce> could you attach your logs and confs and stuff?  sometimes it can be helpful to compare these for several people experiencing the issue, to look for possible commonalities
<bryce> other than that, no, looks like this bug is already known to upstreams, so it'll be a matter of waiting for a fix from them
<bryce> yeah, there's nothing more we can do on our end; we need to keep an eye on what upstream does and backport the fix if/when it emerges
<joumetal> bryce in bug #137604 ppa1 works for me others don't
<ubotu> Launchpad bug 137604 in xorg-server "Black Bar Across Screen with gutsy i810" [High,Confirmed]  https://launchpad.net/bugs/137604
<bryce> joumetal: really!  interesting, not what I would have expected
<bryce> joumetal: you tested all four?
<joumetal> yes. I hope I didn't made any mistakes.
<bryce> ok, well if you're right, this narrows it down to just a few patches
<bryce> thanks! btw :-)
<joumetal> my pleasure.
<bryce> narrows it to 4 patches specifically
<bdmurray> bryce: Ooh, I got a much better log this time
<bdmurray> "Error in I830WaitLpRing(), timeout for 2 seconds" is part of it
<bryce> ah good
<bryce> that sounds familiar though - I think it might be a generic error message
<joumetal> as a guess patch 214 could be the one.
<bdmurray> Launchpad says my log file is trash, I'm a bit offended.  Xorg log file from after a crash  (63.0 KiB, application/x-trash)
* bryce snorts
<bryce> hey, I've closed bug 22985 (and its 25!! dupes) as Fixed just now.  \o/
<ubotu> Launchpad bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Fix released]  https://launchpad.net/bugs/22985
<bdmurray> Sweet!
<bryce> joumetal: I've posted ~ppa5 which has just patch 214 disabled - could you test this and see if it works?  If it does then we have our smoking gun.
<bryce> joumetal: ~ppa6 with 208 disabled is coming soon
<joumetal> yes I'll test
<jouni> bryce ppa5 works for me :)
<bryce> awesome
<joumetal> bryce  so you don't need to do more builds.
<bryce> yup, now to roll out this change
<bryce> heya rawler
<rawler> bryce: hey
<bryce> rawler: btw, I've also set up a ubuntu-x@lists.ubuntu.com mailing list.  So far very low traffic, but it's planned for use during Hardy for testing/development of ubuntu-specific Xorg work.  https://lists.ubuntu.com/mailman/listinfo/Ubuntu-x
<rawler> bryce: just popping in, so I don't forget.. :)
<rawler> bryce: *ahh* I see.. is there a launchpad-team?
<bryce> yup, it's called X-Swat
<bryce> there's also a thread on ubuntuforums.org in the Gutsy Development area, for Xorg testing, which is where most of the ati testers gather
<ubotu> New bug: #141372 in xserver-xorg-video-ati (main) "[gutsy]  failure detecting DVI since xserver-xorg-video-ati 6.7.192" [Undecided,New]  https://launchpad.net/bugs/141372
<rawler> bryce: goodie.. I'll joing up on the launchpad team, and look tomorrow if there's something I can do.. :)
<bryce> awesome, good to have you :-)
<rawler> bryce: well wait until I've actually done something to say that.. ;)
<bryce> hehe
<rawler> skimming through the buglist it seems most of them are kernel and/or hardware specific.. but i seen one or two I think I can handle.. :)
<bryce> yup
<bryce> there's probably many that can (should) be linked to upstream bug reports
<bryce> either at nvidia, or kernel or fdo
<rawler> yeah.. will look at it tomorrow.. for now I'll go to bed.. gotta big-ass ill-handled mess of a software release to deal with tomorrow.. (trust me, comparing that mess with the tracking launchpad offers, is like comparing a rotting corpse to a shiny new corvette cruiser)
<rawler> so nighty, and ttl..
<bryce> night
<bryce> hehe
#ubuntu-x 2007-09-21
<bryce> keescook: would you have a moment to upload xorg-server 12ubuntu6 at http://people.ubuntu.com/~bryce/Uploads/?
<bryce> keescook: it fixes beta bug 137604, and has approval from slangasek
<ubotu> Launchpad bug 137604 in xorg-server "Black Bar Across Screen with gutsy i810" [High,Fix committed]  https://launchpad.net/bugs/137604
<keescook> bryce: sure, one sec.
<keescook> bryce: done
<tepsipakki> bryce: aaronp said he'd release a new nv driver soon, so maybe that would fix the quadro bugs we have
<bryce> tepsipakki: cool
<bryce> tepsipakki: although I think it's getting too late for gutsy
<bryce> I'd like to get bug 127008 fixed though
<ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages" [Medium,In progress]  https://launchpad.net/bugs/127008
<bryce> it's great seeing all the new folks getting involved in xorg stuff. 
<tepsipakki> yep
<tepsipakki> bryce: aaronp plans to release it today :)
<bryce> ah, well maybe it can squeeze in
<tepsipakki> "hopefully tonight", but yeah
<ubotu> New bug: #57586 in xorg (main) "XEmacs segfaults on startup in Edgy" [Undecided,Fix released]  https://launchpad.net/bugs/57586
<ubotu> New bug: #58856 in xemacs21 (universe) "xemacs segfaults on edgy powerpc system (dup-of: 57586)" [Undecided,New]  https://launchpad.net/bugs/58856
<ubotu> New bug: #115056 in xorg (main) "kdesktop_lock doesn't work" [Undecided,Incomplete]  https://launchpad.net/bugs/115056
<ubotu> New bug: #141492 in xserver-xorg-input-synaptics (main) "Macbook scroll and middle/right click stopped working" [Undecided,New]  https://launchpad.net/bugs/141492
<ubotu> New bug: #139241 in ubuntu "gutsy tribe 5 and daily 8-sep-2007 hang while starting up X on radeon 200M" [Undecided,New]  https://launchpad.net/bugs/139241
<ubotu> New bug: #141495 in xorg (main) "on my desktop i see only rectangles!!!" [Undecided,New]  https://launchpad.net/bugs/141495
<ubotu> New bug: #141522 in xserver-xorg-video-intel (main) "[gutsy]  faulty Xv extension since latest update" [Undecided,New]  https://launchpad.net/bugs/141522
<ubotu> New bug: #44708 in xserver-xorg-video-ati (main) "Dual Monitor Problems" [Medium,New]  https://launchpad.net/bugs/44708
<ubotu> New bug: #141547 in xserver-xorg-driver-ati (main) "[Gutsy]  after ati driver update, only a black screen (light is on)" [Undecided,New]  https://launchpad.net/bugs/141547
<ubotu> New bug: #141551 in xserver-xorg-video-ati (main) "ati driver lockup (mobility radeon rv350)" [Undecided,New]  https://launchpad.net/bugs/141551
<ubotu> New bug: #141533 in xserver-xorg-video-ati (main) "Gutsy: Switching workspaces when playing XVideo overlay crashes X" [Undecided,New]  https://launchpad.net/bugs/141533
<tormod> bryce, could you mirror these please? http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati_6.7.193-1ubuntu1feisty_i386.deb and http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati-dbg_6.7.193-1ubuntu1feisty_i386.deb
<bryce> sure thing
<mvo_> bryce: is there a new -ati driver pending before/after beta? I just confirmed https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/141533 (and that worries me)
<ubotu> Launchpad bug 141533 in xserver-xorg-video-ati "Gutsy: Switching workspaces when playing XVideo overlay crashes X" [Undecided,Confirmed]  
<bryce> mvo, there is a new -ati out that I think tepsipakki is planning on rolling out.  Don't know if it'll be before or after beta
<bryce> tormod: sync finished
<tormod> bryce, thanks
<bryce> mvo_: one sec and I'll look upstream for that one
<tepsipakki> bryce: the latest upstream is already in :/
<tepsipakki> +gutsy
<bryce> tepsipakki: ah, ok
<bryce> mvo_: this sounds sort of similar, could you test?    https://bugs.freedesktop.org/show_bug.cgi?id=12175
<ubotu> Freedesktop bug 12175 in Driver/Radeon "Xv crash if video window fully offscreen (rv280)" [Normal,New]  
<tepsipakki> oh, b.fd.o works again \o/
<mvo_> bryce: yes, that sounds like it, what is the diff for "5d044b9f74c7aa7e12f2822896fed881e2ca9d19", do you have that quickly available? if not, I will do a checkout of -ati myself to have a look
<bryce> go for it
<tepsipakki> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commitdiff;h=5d044b9f74c7aa7e12f2822896fed881e2ca9d19
<mvo_> tepsipakki: thanks!
<tepsipakki> mvo_: np. my screen cuts long urls though, so can't test that it works :)
<bryce> it works
<tepsipakki> cool
<bryce> want me to roll an -ati with that patch?
<bryce> er, 'that patch reverted'?
<tepsipakki> go ahead, I'll continue going through the ati bugs :)
<bryce> ok
<tepsipakki> although the tv is on, and distracts me a bit
<mvo_> bryce: its late here, but I want to test it to make sure that it does not break video playback with compiz
<bryce> ok building; will have .deb up in a few minutes
<bryce> bah
<bryce> bdmurray: so with the latest launchpad change, should we expect old Incomplete bugs to suddenly switch to Invalid?
<bryce> mvo, debs are up:  http://people.ubuntu.com/~bryce/Testing/
<tepsipakki> bryce: wow, seems to be so :)
<tepsipakki> that inactive bugs are cleaned out 
<bdmurray> bryce: I'm not sure if a bunch will just change or if it'll be 60 days from now
<bryce> http://people.ubuntu.com/~brian/testing_graphs/xorg.html
<bryce> http://people.ubuntu.com/~brian/graphs/ -- 2000 bugs just died
<bryce> poor poor bugs
<bdmurray> zomg
<mvo> bryce: reverting the commit for ati fixes the problem for me
<bryce> mvo, wow, that was good luck
<mvo> indeed :)
<mvo> and video playback still works
<bryce> ok I'll go ahead and put this in for inclusion
<mvo> thanks
<bryce> sleep well :-)
<mvo> soon, I need to do some more work for the beta first :/
<tepsipakki> that ati/xv crash is debian bug 441902
<ubotu> Debian bug 441902 in xserver-xorg-video-ati "xserver-xorg-video-ati: 6.7.192-1~7.2 crashes xserver with xv video playback on compiz" [Normal,Open]  http://bugs.debian.org/441902
<tepsipakki> there was another proposal for the fix
<bryce> tepsipakki: yeah this patch looks like it's just papering over some other bug
<tepsipakki> I'll reply to the debian bug, hopefully alex will figure it out eventually :)
<tepsipakki> oh, you asked about it on #x-d already :)
<bryce> tepsipakki: yup, figure he already knows, but more info can't hurt
<bryce> heya rawler
<rawler> bryce: hello.. :)
<tepsipakki> bryce: nv 2.1.4 just released
<bryce> tepsipakki: yup, saw the announce :-)
<bryce> tepsipakki: sounds pretty minor though
<bryce> the LVDS fix is probably worthwhile, and of course new products are always good
<jcristau> i think it's just the product names
<rawler> bryce: just a quick question; how exactly does launchpad manage bug status?
<tormod> the new nv would fix bug 133385 the right way
<ubotu> Launchpad bug 133385 in discover-data "[gutsy]  "nv" is not new enough to support my chipset (Quadro FX 570M), but is detected as the most appropriate display driver during installation" [Medium,Fix released]  https://launchpad.net/bugs/133385
<bryce> rawler: for bugs local to launchpad (i.e. ubuntu bugs), bug status is handled manually by folks like us
<tepsipakki> tormod: that's what I had thought too :)
<rawler> bryce: looking at https://bugs.launchpad.net/~ubuntu-x-swat/, bug 19890 has status new, but looking at the bug itself it seems to have been marked invalid a long time ago?
<ubotu> Launchpad bug 19890 in freeglut "conquest-gl: fail to start (Assertion `window->Window.VisualInfo != ((void *)0)' failed.)" [Medium,Invalid]  https://launchpad.net/bugs/19890
<bryce> rawler: however there are some various misc. scripts which also update bug statuses
<tepsipakki> rawler: the ubuntu part yes
<bryce> ah
<bryce> rawler: one of the unique things about LP is that it can track state in external bug trackers
<bryce> or in multiple products
<bryce> which is handy for hooking the bug to upstream bugs
<rawler> ok, so it always displays the "worst-case" status in listings?
<bryce> no, technically it would display both
<bryce> however "Invalid", "Fix Released" are typically hidden in most displays
<rawler> bryce: yeah, in the bug itself, but not in https://bugs.launchpad.net/~ubuntu-x-swat/
<rawler> bryce: or is there a better way to get a list of open bugs related to ubuntu-x-swat?
<bryce> rawler: that listing is for bugs assigned/related to x-swat, but typically we haven't been bothering assigning bugs to x-swat, so this list probably isn't the best place to look
<bryce> I typically just select one of the X products (like xorg, xorg-server, or a driver) and look for bugs that way
<bryce> I like to personally subscribe to a variety of bugs that look interesting to me, and then check back on them
<tepsipakki> yeah, "show package report"
<bryce> from my subscribed bugs, I've picked a dozen to subscribe to that I want to work on closely
<bryce> (no more than a dozen though, else it'd get overwhelming)
<rawler> *ahh* I see.. will go about it that way, in that case.. :)
<bryce> also, there is a bot on this channel that reports newly reported/updated bugs in all products; sometimes those are of interest
<rawler> bryce: allright.. will try to hang here more then.. :)
<bryce> cool :-)
<bryce> rawler: what sorts of things are you most interested in?  you mentioned -nvidia yesterday iirc?
<rawler> bryce: well, I'm not particulary focused on any specific area.. I heard you needed help, so I'm mostly looking for something to do.. :)
<bryce> nice, well welcome :-)
<rawler> I usually try to steer clear of hardware and device-driver-specific things, and user-interfaces (unless it's about testing out new concepts for user interfaces), but anything in between goes... :)
<rawler> thanks, I feel pretty welcome.. :)
<rawler> I'm usually more of a hacker than a QA-guy/forum-sweeper, so I usually try to find bugs that I can reproduce and fix, or feature-requests that I can implement..
<bryce> that'll be a huge help; there's tons of bugs that fit those criteria
<rawler> well.. most of them seems to not match my hardware and/or be hard to reproduce, and be driver-related.. so not really my league.. :)
<bryce> yup, I have that trouble too
<jcristau> those most often need to be reported upstream
<bryce> fortunately, for bugs that affect multiple people, it's generally not too hard to find a community member who'll be willing to test out .debs
<ubotu> New bug: #91006 in compiz (main) "Enabled Desktop Effects makes Gnome Terminal unusable (dup-of: 89369)" [Undecided,Invalid]  https://launchpad.net/bugs/91006
<ubotu> New bug: #97575 in restricted-manager (restricted) "restricted-manager doesn't list my nvidia GeForce Go 7400 (dup-of: 93209)" [Undecided,Invalid]  https://launchpad.net/bugs/97575
<ubotu> New bug: #98542 in ubuntu "starting "wine" or "google earth" crashes the x-server after today's update (dup-of: 96430)" [Undecided,Invalid]  https://launchpad.net/bugs/98542
<ubotu> New bug: #34555 in xorg (main) "Bad display configuration after install (dup-of: 42731)" [Medium,Invalid]  https://launchpad.net/bugs/34555
<ubotu> New bug: #35508 in xorg (main) "1366x768 screen resolution not supported (dup-of: 24927)" [Medium,Invalid]  https://launchpad.net/bugs/35508
<ubotu> New bug: #32219 in xorg (main) "Edubuntu dapper live flight4: only does 640x480 resolution (dup-of: 36306)" [Medium,Invalid]  https://launchpad.net/bugs/32219
<ubotu> New bug: #32401 in totem "totem won't start with totem-xine engine (dup-of: 35229)" [Medium,Invalid]  https://launchpad.net/bugs/32401
<ubotu> New bug: #35944 in xorg (main) "Laptop with integrated SIS gfx and ATI module fails to detect the active card (dup-of: 42731)" [Medium,Invalid]  https://launchpad.net/bugs/35944
<ubotu> New bug: #40783 in xorg (main) "[Dapper]  bad resolution for SONY CPD-210EST screen (dup-of: 42731)" [Medium,Invalid]  https://launchpad.net/bugs/40783
<ubotu> New bug: #40839 in xorg (main) "Dapper Beta LiveCD install doesn't setup monitors/resolutions right (dup-of: 42731)" [Medium,Invalid]  https://launchpad.net/bugs/40839
<ubotu> New bug: #42448 in xorg (main) "DisplaySize not set on Dell Inspiron 8200 (dapper beta) (dup-of: 30743)" [Medium,Invalid]  https://launchpad.net/bugs/42448
<ubotu> New bug: #47759 in update-manager (main) "upgrade from breezy to dapper rc1 fails (dup-of: 41314)" [Medium,Invalid]  https://launchpad.net/bugs/47759
<ubotu> New bug: #50539 in xorg (main) "Thinkpad x60 xorg.conf contains strange entries for Wacom InputDevice (Stylus) (dup-of: 42553)" [Undecided,Invalid]  https://launchpad.net/bugs/50539
<ubotu> New bug: #50737 in totem (main) "totem-xine crashes with 'BadAlloc' when run manually (dup-of: 35229)" [Undecided,Invalid]  https://launchpad.net/bugs/50737
<ubotu> New bug: #52069 in update-manager (main) "update-manager kills entire X session (dup-of: 49834)" [Undecided,Invalid]  https://launchpad.net/bugs/52069
<ubotu> New bug: #54307 in xorg-driver-synaptics (main) "driver does not work with xserver-xorg-core 1:1.1.1-0ubuntu1 (dup-of: 54290)" [Undecided,Invalid]  https://launchpad.net/bugs/54307
<ubotu> New bug: #54565 in xorg (main) "no direct rendering on Dell laptop using Edgy and i810 driver (dup-of: 54858)" [Medium,Invalid]  https://launchpad.net/bugs/54565
<ubotu> New bug: #65909 in flashplugin-nonfree (multiverse) "Flash bug (dup-of: 62988)" [Undecided,Invalid]  https://launchpad.net/bugs/65909
<ubotu> New bug: #81324 in cryptsetup (main) "Problem with cryptsetup password during boot (dup-of: 82084)" [Medium,Invalid]  https://launchpad.net/bugs/81324
<ubotu> New bug: #96039 in totem (main) "Regression in quicktime playback (dup-of: 73102)" [Low,Invalid]  https://launchpad.net/bugs/96039
<ubotu> New bug: #107645 in f-spot (main) "feisty f-spot hangs (dup-of: 89467)" [Undecided,Invalid]  https://launchpad.net/bugs/107645
<ubotu> New bug: #104499 in f-spot (main) "PC Crash when I import data into f-spot (dup-of: 89467)" [Medium,Invalid]  https://launchpad.net/bugs/104499
<ubotu> New bug: #48164 in xorg (main) "Video corruption at installation of xserver-xorg" [Medium,Confirmed]  https://launchpad.net/bugs/48164
<bdmurray> what happened here?
<bdmurray> Did ubotu go crazy?
<tepsipakki> no, they really were closed by lp janitor :)
<tormod> was that all those incomplete bugs going invalid?
<tepsipakki> yep
<bdmurray> bryce: I'm looking at the daily for today and my display is 1024x768 instead of 1280x800(?)
<ubotu> New bug: #57283 in xorg-server (main) "latest xserver fails (dup-of: 57153)" [Low,Invalid]  https://launchpad.net/bugs/57283
<ubotu> New bug: #56277 in linux-restricted-modules-2.6.15 (restricted) "xserver-xorg: FATAL: fglX11CMMFreeSurface: firegl_FreeBuffer() failed!" [Low,Invalid]  https://launchpad.net/bugs/56277
<ubotu> New bug: #55224 in xserver-xorg-video-ati (main) "iMac 1.9Ghz: X fails to load under Edgy (dup-of: 23445)" [Undecided,Invalid]  https://launchpad.net/bugs/55224
#ubuntu-x 2007-09-22
<bryce> bdmurray: hrm, don't know why that'd be
<bdmurray> bryce: does it look at xresprobe or not anymore?
<bryce> yeah still uses xresprobe
<bryce> the one change since yesterday was dropping a patch that causes i810 to get screen corruption during install
<bryce> so if that's what caused the resolution regression (which is not unlikely), then it's at least a trade-off in the right direction
<bdmurray> and the right way to run xresprobe is 'sudo xresprobe vidoedriver' correct?
<bdmurray> The /var/log/Xorg.0.log shows 1280x800 as a valid mode line
<bdmurray> But xresprobe intel shows 1024x768
<bryce> yup
<bdmurray> yup?
<bryce> wow, that was exciting
<bdmurray> Was there a fire? earthquake?
<ubotu> New bug: #72940 in xserver-xorg-video-intel (main) "Framebuffer (kernel bootflag) locks up X after hibernate" [Undecided,Invalid]  https://launchpad.net/bugs/72940
<ubotu> New bug: #93077 in xkeyboard-config (main) "Non-exsisting layouts" [High,Confirmed]  https://launchpad.net/bugs/93077
<ubotu> New bug: #141609 in xorg (main) "startx fails with vesa, ati on T41 with Radeon Mobility M7 LW [Radeon Mobility 7500] " [Undecided,New]  https://launchpad.net/bugs/141609
<ubotu> New bug: #24452 in linux-restricted-modules-2.6.15 (restricted) "No 3d acceleration with ATI RADEON 9550" [Medium,Invalid]  https://launchpad.net/bugs/24452
<ubotu> New bug: #68843 in console-setup (main) "croatian keyboard is broken in installation of ubuntu server, kubuntu and xubuntu - 6.10 (dup-of: 93077)" [Undecided,Confirmed]  https://launchpad.net/bugs/68843
<ubotu> New bug: #69469 in console-setup (main) "Slovenian keyboard does not work in text installer (dup-of: 93077)" [Undecided,New]  https://launchpad.net/bugs/69469
<ubotu> New bug: #112707 in console-setup (main) "Keyboard not working properly when installing Feisty Fawn (Xubuntu) (dup-of: 93077)" [Undecided,New]  https://launchpad.net/bugs/112707
<bryce> bdmurray: nah, I'm working on upgrading my main dev box from feisty to gutsy, and it lost its mind
<bdmurray> bryce: hunh, I guess I will postpone that then
* Starting logfile irclogs/ubuntu-x.log
#ubuntu-x 2008-09-15
<tjaalton> wgrant: peter replied that the tapping commit is probably not what broke two-finger tapping, but the one which changed MaxTapMove
<james_w> is anyone familiar with xvfb
<james_w> ?
<james_w> ah, typical, it works when I try it now.
<wgrant> tjaalton: That's not my experience, nor those on the bug/forum.
<wgrant> tjaalton: Both are needed for it to be fully operational.
<tjaalton> "It could also be caused by 50e872cbc74f6a08ac586bc5e57d7e6a9dfce06a which
<tjaalton> reduced the MaxTapMove - causing issues for at least two of our users. I had a
<tjaalton> IRC discussion with one of them today and setting it back to 200 worked. 
<tjaalton> "
<tjaalton> dunno, maybe better if you tried explaining things :)
<wgrant> tjaalton: People continued to complain that multi-finger tapping didn't work properly.
<wgrant> Two-finger tapping requires both a higher threshold (at least I more my fingers more when multi-finger tapping) and that disentanglement patch reverted.
<wgrant> Others say the same. I'm not sure why it's needed.
<tjaalton> are you subscribed to xorg@
<tjaalton> ?
<wgrant> I am.
<wgrant> I'm not up to date... I've a bit of other mail due to recent events.
<tjaalton> looking at the forum thread it seems that setting Tap Move to 200 fixes things?
<wgrant> There's one where I linked to a version in my PPA with the disentanglement patch reverted, and they said it fixed it.. .let me see if I can find it.
<wgrant> Hm, still looking...
<tjaalton> http://ubuntuforums.org/showthread.php?t=917830 ?
<wgrant> That one.
<tjaalton> hmm ok, if you could follow up on the thread on xorg@ when you have time?
<wgrant> Sure.
<tjaalton> cool, thanks
<bryce> morning
<james_w> thanks bryce 
<bryce> james_w: sure thing
<james_w> bryce: nice post, I agree with you
<emma> how can i tell what my videodriver is?
<bryce> emma: look in your /var/log/Xorg.0.log
<emma> Thank's bryce 
<emma> (incidently I'm using Intrepid development branch)
<emma> (WW) Failed to open protocol names file /etc/X11/xserver/protocol.txt
<emma> That's the first line in my /var/log/Xorg.0.log
<emma> looks ominous.
<jcristau> we should revive xserver-common, and put that file there. ignore it for now.
<emma>     X.Org XInput driver : 2.1
<emma> Would that be the videodriver?
<emma> (--) PCI:*(0@1:5:0) ATI Technologies Inc RS480 [Radeon Xpress 200G Series] rev 0, Mem @ 0xd8000000/134217728, 0xfdef0000/65536, I/O @ 0x0000ee00/256, BIOS @ 0x????????/131072
<emma> That's the video card.
<bryce> james_w: thanks.  I'm interested in seeing how your lp/bzr integration work will help simplify things
<emma> I've never installed any driver, wouldn't it just be the default that comes with intrepid?
<emma> (incidentally, my purpose is to find what my driver is, in order to make a better bug report)
<bryce> emma: probably -ati then.  try `grep _drv /var/log/Xorg.0.log`
<bryce> you should see a line like this:  (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
<emma> (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
<emma> Yes I have that
<james_w> bryce: it's one of my mail aims
<emma> I actually never knew about this channel until just now.
<emma> I guess you guys specialise in the X-server
<emma> I have a concern related to that. In all previous releases since Edgy through Hardy I have been able to follow steps I found a long time ago on ubuntuforums, to make my Logitech Marble Mouse roller ball have full functionality by editing xorg.conf. 
<emma> In intrepid I edited it again but no change in behavior is observed.
<emma> I think maybe it needs a layout section at the bottom.
<emma> but maybe xorg.conf has been emaciated somehow and lacks that.
<jcristau> define 'full functionality'
<emma> It's a roller ball. It has two buttons on each side and it has the roller ball on top.  Previously Ive been able to use xorg.conf to enable holding down one of these buttons while using the rollerball to emulate a scroll wheel.
<emma> I'll show you the ubuntuforums page with the code I have always been able to use.
<emma> http://ubuntuforums.org/showthread.php?t=169423
<emma> in Intrepid there just is hardly anything in xorg.conf and editing it with the lines in the link did not make the marble mouse work.
<emma> I seem to recall though that in the old xorg.conf there was something like 'layout' at the bottom of it, and that's missing. I wonder if that's what's needed in order to make the Section "InputDevice"
<jcristau> need to use the evdev driver, with a proper Device option and ServerLayout section
<emma> stuff work.
<jcristau> or, set the options in hal
<jcristau> or through xinput properties
<emma> Is that easier than it used to be?
<emma> I'll paste you my xorg.conf as it is right now.
<emma> http://club-ubuntu.pastebin.com/d2e057b3d
<emma> There is my xorg.conf as it is right now.
<emma> Well I had some big troubles.
<emma> I tried to put a ServerLayout section in there and it broke X and i had to do a -phigh thing.
#ubuntu-x 2008-09-16
<emma> Ever since edgy doing what is on this link made my logitech marble mouse work with scroll wheel ability -- http://ubuntuforums.org/showthread.php?t=169423
<emma> It worked in edgy, feisty, gutsy, and hardy. 
<emma> But now in Intrepid some how X has changed and now I put the same stuff in there and it does not change the behavior of the mouse at all.
<emma> Does anyone have any ideas?
<tjaalton> morning
<tjaalton> emma: input-hotplug means that evdev "steals" all your input devices
<emma> so that's a bug?
<tjaalton> emma: so that's why "mouse" no longer works unless you do other things 
<tjaalton> no
<emma> i see. what other things should a person do?
<tjaalton> you can use 'xinput' to set the options you like (during a session start, for instance.. GUI support coming later), or add an fdi file which does the same
<tjaalton> which is persistent
<emma> to me it sounds much more complicated than the old way.
<tjaalton> maybe
<emma> but ubuntu's raison de'tre is to be easy.
<tjaalton> or you can add 'Option 'AutoAddDevices "false"' to the ServerFlags section
<tjaalton> and specify keyboard and mouse like before..
<emma> i don't want to mess things up if it was made this way now there must be some good reasons.
<emma> i would just like my marble mouse to be able to scroll wheel effect again.
<tjaalton> man xinput then
<emma> okay
<tjaalton> you can change those settings while the session is running.. that was not possible before
<emma> i may stand a chance of figuring it out but not tonight i have to sleep now. after midight here.
<emma> thanks for the clues. 
<tjaalton> sure, np
<bryce> heya tjaalton
<tjaalton> hi bryce
<tjaalton> bryce: the autotoolized mesa doesn't build intel DRI drivers for lpia, but is i915_dri.so the only one needed there?
<tjaalton> I think it is
<tjaalton> I've got also some xkb-data fixes on the radar before a6
<bryce> cool
<bryce> did the autotoolized mesa build them before?
<bryce> I don't remember that -psb required them, and I don't know if there's any other gfx hw on lpia that uses -intel.  maybe...
<tjaalton> there's bug 270106
<ubottu> Launchpad bug 270106 in mesa "several modules missing in lpia build" [High,Confirmed] https://launchpad.net/bugs/270106
<tjaalton> so while the DRI driver is never really required, it does help with 3D :)
<tjaalton> and it got dropped when the package was autotoolized
<tjaalton> which was July'ish
<bryce> hrm
<bryce> any ideas why it got dropped?  would it be easy to add back in?
<tjaalton> yes it is. it got dropped by accident, since the list of drivers to build varies based on the architecture
<tjaalton> I've got it ready on my tree, but wanted to make sure i915 was enough
<bryce> ah, yeah I believe so
<bryce> i965 might be worth having
<tjaalton> ok, I'll add that too
<james_w> tseliot: hey, have you seen bug 270980
<ubottu> Launchpad bug 270980 in screen-resolution-extra "setVirtual() doesn't set correct value if second display is bigger" [Undecided,New] https://launchpad.net/bugs/270980
<tseliot> james_w: let me have a look at it
<tseliot> james_w: ok, I'll fix it, however when my patch is accepted the virtual resolution will be calculated by the C part, therefore this is a temporary fix
<james_w> ah, ok.
<tseliot> james_w: ok, I have fixed the problem
<tseliot> how can I associate a commit with a bug?
<tseliot> s/commit/revision/
<james_w> tseliot: commit with "--fixes lp:12345"
<james_w> if you have a changelog entry with "LP: #12345" then debcommit in Intrepid will do that for you
<tseliot> yes, of course the changelog has such entry
<tseliot> james_w, bryce: the fix is in this branch: ~albertomilone/screen-resolution-extra/intrepid
<tseliot> bryce: can you upload it for me (when you have the time), please?
<james_w> tseliot: I don't see how the new code is any different, what am I missing?
<tseliot> james_w: I made it look exactly as the C code
<tseliot> and it works well here
<tseliot> I have tested the function and passed it some values in a tuple as the real program would do
<tseliot> and it works well
<james_w> ok
<james_w> the same tests show the old version was broken?
<tseliot> wait, no, now they don't
 * tseliot wonders what happened before...
<tseliot> james_w: this makes little sense
<bryce> tseliot: we're in freeze for alpha6 starting today
<tseliot> the C part is ok
<tseliot> bryce: ok, no problem
<james_w> tseliot: is it whatever passes the values that is wrong then?
<tseliot> james_w: the C program passes those values and that part looks good
<tseliot> james_w: are we sure that the user chose the right settings?
<tseliot> it has always worked for me here and it worked for bryce too
<james_w> tseliot: I'm not sure, I have no prior experience with "Virtual" to know what the correct values are
<james_w> he does say that changing it gave him a working set up
<tseliot> yes, and he's right
<james_w> I can't test at the moment due to other bugs, sorry
<tseliot> no, problem, I'm too tired to do anything else too
<james_w> for param in params[0]:
<james_w> should that not be
<james_w> for param in params:
<james_w> so that it considers all of sys.argv
<james_w> that will only look at the first, and so could lead to taking max(first) -> first
<james_w> so if the second is larger it won't get considered
<james_w> ah, def computeVirtual(*params):
<tseliot> yes
<james_w> so it get's called like "1024x768:0,0 1280x968:1024,0"
<tseliot> 0,0:1680x1050 0,0:1600x1200
<james_w> no, other way round
<james_w> yeah
<tseliot> xposition, yposition, width, height
<tseliot> xposition, yposition:widthxheight
<tseliot> this one looks better ^
<tseliot> so in your example
<tseliot> the x position of the 2nd screen will be 1024
<tseliot> and you will have to add the x position to the width
<tseliot> and get the highest value
<Ng> tjaalton: bug 262605 wouldn't be related to seeing mieqEnequeue errors and X getting wedged, right?
<ubottu> Launchpad bug 262605 in mesa "[intrepid] X locks up or crashes when screensaver activates" [High,Fix released] https://launchpad.net/bugs/262605
<Ng> I just unlocked the screensaver and was left with just my backdrop and a mouse pointer. sshing in showed a lot of these in X logs:
<Ng> [mi] mieqEnequeue: out-of-order valuator event; dropping.
<Ng> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
<jcristau> Ng: seeing mieqEnqueue errors is a symptom of X getting wedged
<jcristau> or, the gpu locking up
<jcristau> so that alone doesn't say anything about the cause
<Ng> there's nothing of note in syslog
<Ng> and the Xorg.0.log just goes from EDID output straight into those messages
<james_w> tseliot: yeah, I can't see what's wrong here
<tseliot> james_w: I have asked that user to try again, just to be sure
<james_w> thanks
<tseliot> james_w: thanks for reporting. BTW I subscribed to the bugs of that package.
 * tseliot > dinner. Bbl
<Ng> jcristau: if it happens again, is there anything I can do to get some more useful information?
<jcristau> Ng: see where X is blocked (gdb helps)
<jcristau> also if it's reproducible it's easier
<superm1> bryce, at some point you had a document that referred to setting up faulty keymappings, but i seem to forget where I saw it.  you have a link handy?
<bryce> probably http://wiki.ubuntu.com/X/Troubleshooting - the keyboard section
<superm1> ah yup.  i'll see if this can help get a few missing keycodes sorted out on the latitude xt
<superm1> thanks
<superm1> it looks like there is no hotkey defined in input.h to trigger a screen rotation is there?
<Ng> bryce: OOI, any ideas what intel's plans are for video acceleration?
<bryce> what's OOI mean?  or are you spewing binary at me?  ;-)
<bryce> Ng: for acceleration, have you looked at UXA?
<Ng> Out Of Interest
<Ng> I've not looked at anything specifically
<Ng> I'm just curious about video acceleration, because I tried to play a 1080p video earlier on and it sucked
<Ng> (on a G45)
<bryce> yeah I think the priority is going to be to get the GEM/UXA stuff worked out first
<bryce> see http://ph.ubuntuforums.com/showthread.php?t=890843
<Ng> bryce: that stuff is more about 2D acceleration though, right?
<bryce> it involves both 2d and 3d
<Ng> I'm thinking more like xvmc
<Ng> basically I think a G45 and a Core2Duo 6300 ought to be able to play 1080p H.264 :)
<Ng> mplayer was close to being able to, with a single thread eating all the CPU and using Xv, so pretty much just using the CPU since no scaling is required
<Ng> jcristau: ok. so far it's not reproducible, but next time I will ssh in and fire up gdb
#ubuntu-x 2008-09-17
<Ng> gallium sounds like the right kind of thing
<emma> I use Ubuntu intrepid. Ever since Edgy the following link enabled the scroll wheel effect in my Logitech Marble Mouse --  http://ubuntuforums.org/showthread.php?t=169423
<emma> However, now something has changed, and making that edit does not change the behavior of the mouse.
<emma>  Does anyone have any ideas or suggestions?
<emma> It stopped working in Intrepid.
<tjaalton> emma: we went through it yesterday..
<tseliot> tjaalton, mvo: I'm working to make sure that the nvidia branch of dkms tree is cleaned up by the drivers so that older versions (left there by that bug which I fixed) are removed. What do you think about this preinst file? http://albertomilone.com//ubuntu/newlrm/nvidia-173-kernel-source.preinst
<tjaalton> tseliot: if it works, looks ok :)
<tseliot> tjaalton: yes, I tried it with echo "rm, etc." instead of rm
<tseliot> and it prints the right output
<tjaalton> ok then
<tseliot> of course I'll do some real testing here ;)
<tjaalton> nah, why bother ;)
<tseliot> oh, wait, a simple "rm -rf /" would be a lot easier
<tseliot> can you test it for me? :-P
<tjaalton> heh
<emma> tjaalton: you said look at xinput, it's sort of opaque and does not seem to translate directly from the xorg.conf lines to anything you put in xinput.
<emma> maybe i'm wrong, could you tell me how do you put those xorg.conf lines into xinput?
<tjaalton> you don't put any lines anywhere, you run the command
<tjaalton> 'xinput list' shows your devices
<tjaalton> 'xinput list-props $id' shows the properties of the device
<tjaalton> 'xinput set-int-prop $id $property 32 $value' changes the setting
<tjaalton> or, you add 'Option AutoAddDevices "false"' to your ServerFlags, and configure the device in xorg.conf like before
<tjaalton> $id can also be the full name
<tjaalton> oh what fun it is getting winxp working on thinkpad X61
<tjaalton> not
<tjaalton> even with sp3 had to use a driver disk to get the hd recognized
<bryce> heya tjaalton
<tjaalton> and all this because vista sucks
<tjaalton> even more
<tjaalton> hey bryce
<bryce> as long as vista sucks people over to ubuntu that's fine
<tjaalton> I've been fighting with my hardware.. got a new phone yesterday and have been trying to make a dump of the contents, but gave up hope getting MMS's or bookmarks out of the old one
<tjaalton> nokia pc suite == crap
<tjaalton> outsourced crap, a nokia employee added ;)
<tjaalton> (a friend)
<bryce> hehe
<bryce> I've still been banging my head on that keyboard hotkey bug from last week
<bryce> I made the mistake of looking in acpi-support and got bewildered by all the other hotkeys-don't-work bug reports :-)
<tjaalton> yeah, it's a dead-end
<bryce> bug 267682
<ubottu> Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Triaged] https://launchpad.net/bugs/267682
<bryce> do you have any other ideas on that?  I'm going to contact the kernel team next
<bryce> tjaalton: you'd mentioned that switching from evdev to kbd made the issue go away - did you ever sort out why?
<tjaalton> no, but I think it's a simple matter of different scan/keycodes
<tjaalton> some of them don't match
<tjaalton> I'd need to know more about how this all is glued together
<tjaalton> but pitti is on leave until next week
<bryce> actually I think he's at the plumber's conference this week
<tjaalton> oh right
<tjaalton> debian has eight revisions on top of our acpi-support.. wonder if those would help
<tjaalton> ie. sync the version from unstable
<tjaalton> * Reinstate thinkpad_acpi.modprobe to fix "Many Thinkpad X60 keys stop working" (Closes: #481253)
<tjaalton> that's from the debian changelog
<tjaalton> although, since it was reported that they worked on hardy..
<bryce> oooh
<bryce> there's been so many contradictory comments I'm not sure who to believe
<tjaalton> bbl->
<bryce> in any case it seems there are multiple bugs.  Perhaps pulling the dell version of that would fix at least some.  I'll put that on my todo for today.
<superm1> hi guys, could you check that this bug's fix got pulled in for 8.10: https://bugzilla.redhat.com/show_bug.cgi?id=461666 ?
<ubottu> bugzilla.redhat.com bug 461666 in xorg-x11-server "Crash in X.org server during a resolution change (monitor hotplug) in VirtualBox" [Medium,Closed: nextrelease] 
<jcristau> "Note that this bug is fixed in the release version of X.org server 1.5.0."
<torkel> bryce/tjaalton: re #267682, suddenly Fn-F2 (lock screen) works for me, even after a reboot, on my T61
<superm1> jcristau, i wasn't aware whether we were on the release version of xorg server 1.5.  i'm packaging the new vbox to upload, and dynamic adjustments weren't working still for me
<tjaalton> superm1: apt-cache policy xserver-xorg-core ;)
<tjaalton> torkel: like it does on my X61
<superm1> ah tjaalton, the easy solution, so yeah indeed release version of 1.5.0.  thanks
<jcristau> meh. bad virtualbox
<jcristau> "- Bump provides of guest-utils to xserver-xorg-video-2.9"
<superm1> it's "supposed" to work according to upstream's changelog
<jcristau> hardcoding the abi version is bad
<jcristau> seeing how it was bumped to 4 anyway.
<superm1> it was hardcoded in the original debian package...
<jcristau> i don't care whose fault it is :)
<jcristau> wow. they ship copies of the xserver headers.
<bryce> jcristau: oh that sounds safe
<jcristau> the 'here, a sigsegv' sort of safe
<jcristau> i'll try to chat with the debian maintainer...
<bryce> tjaalton: could the recent change in hotkey behavior on thinkpads perhaps have something to do with the sep 1st change to hotkey-setup in bug 256887?
<ubottu> Launchpad bug 256887 in hotkey-setup "thinkpad_acpi complains that hotkey-setup is doing the wrong thing" [Undecided,Fix released] https://launchpad.net/bugs/256887
<tjaalton> bryce: doubt it, since it still works without evdev
#ubuntu-x 2008-09-18
<tseliot> tjaalton: why can't I find the source code of xserver-xorg-input-synaptics (the one in Intrepid) here? https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics
<tjaalton> tseliot: because it's xfree86-input-synaptics
<jcristau> s/input/driver/, even
<tjaalton> right
<tseliot> tjaalton: xfree86???
<tjaalton> it's just a name
<tseliot> yes, I know
<tjaalton> that's what the tarball name used to be
<tjaalton> upstream
<tseliot> I'll have a look at the code since my touchpad is not very responsive with the latest release of the driver
<tjaalton> ok
<tseliot> tjaalton: I have tracked down and fixed the problems with my touchpad
<tseliot> I had to change the values of only 3 variables in synaptic.c
<tseliot> what shall I do now? Send a patch to upstream?
<tjaalton> tseliot: you changed some defaults?
<tseliot> tjaalton: yes, RTCornerButton RBCornerButton and MaxTapMove
<tseliot> I set them back as they were in the last version which worked for me
<tjaalton> you should check git master then
<tseliot> link?
<tjaalton> gitc.fd.o?
<tseliot> huh?
<tjaalton> sorry, cgit.fd.o :)
<tjaalton> or http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-synaptics.git;a=summary
<tjaalton> git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-input-synaptics
<tseliot> thanks a lot
<tjaalton> *CornerButton are off by default?
<tseliot> yes
<tjaalton> that probably won't change
<tjaalton> anyway, you can change it with xinput
<tjaalton> if the gui doesn't support it yet
<tseliot> gui?
<tseliot> which package?
<tseliot> maybe I can fix it myself
<tjaalton> the gnome mouse capplet
<tjaalton> gnome-control-center probably
<tseliot> ok
<tseliot> I'll have a look at it
<tseliot> BTW when building the package it complained about the lack of a README and of a TODO file
<tseliot> hmm... synaptic.c has changed a bit
<tseliot> tjaalton: I had a look at the gnome-control-center (the one in trunk in the gnome svn) and they removed the touchpad tab from the gnome-mouse capplet
<tjaalton> tseliot: no, look at the ubuntu package
<tjaalton> wgrant made a new patch for it
<tseliot> tjaalton: ok, I didn't know. Let me have a look
 * wgrant is fairly sure it works.
<tseliot> wgrant: what does it do exactly?
<wgrant> tseliot: What do you mean?
<tseliot> what does the patch do?
<tseliot> your patch
<wgrant> It gives us a Touchpad tab that uses XInput properties to control the touchpad.
<wgrant> Actually, the g-c-c one just sets gconf stuff.
<wgrant> g-s-d does the dirty work.
<tseliot> ah, sorry I should have read patch 26
<tseliot> wgrant: I would like to make it possible to enable right click by tapping on the right side of the touchpad
<tseliot> it should be just additional line of code
<wgrant> tseliot: One can do that for corners.
<wgrant> But I'm not sure about sides.
<wgrant> It's easy enough to add.
<tseliot> yes, for corners
<wgrant> They just removed that from the defaults upstream, right?
<tseliot> yes
<wgrant> Are you able to work out how to hack it into both? It's fairly obvious, I think.
<tseliot> yes, it is
<wgrant> I already deal with a multi-value one somewhere.
<tseliot> at first I modified the driver but then, after talking to tjaalton, we came to the conclusion that I should edit the ui
<tseliot> the maxtapmove should still be fixed in the driver though
<tjaalton> master uses autoscale for maxtapmove
<tseliot> and what would kde users do?
<tjaalton> switch the desktop?
<wgrant> KDE users would get their own solution.
<wgrant> As they don't use g-s-d, I suppose.
<tseliot> tjaalton: yes, I noticed the change. What do you suggest that we do?
<tseliot> wgrant: I'm asking since I use both desktops
<tseliot> I'll talk to Riddell about that
<tjaalton> tseliot: I suggested that you tried the master version of synaptics to see how it works for you :)
<tseliot> tjaalton: is there a script to update the source of the deb package from git or shall I do a make && make install?
<tjaalton> just copy the debian dir on the git clone'd dir
<tjaalton> in
<tseliot> ok
 * tseliot > lunch. Bbl
<wgrant> Um.
<wgrant> Interesting autodetection changes upstream.
<wgrant> Edge scroll being on by default if double-tapping can't be detected, and off if it can.
<wgrant> And two-finger tapping the opposite.
<tjaalton> heh
<wgrant> Er, two-finger scrolling.
<wgrant> Perhaps a good idea, but it is going to confuse a lot of people.
<tseliot> tjaalton: tapping is completely disabled with the driver from git
<tseliot> and the cursor moves more quickly
<tjaalton> ok
<tseliot> tjaalton: can't we just change the maxtapmove in the driver we have in Intrepid and make users modify the right clicking through a GUI?
<tseliot> rather than pulling the latest driver from git
<tjaalton> I just wanted to know how it behaves
<tseliot> ah, ok
<tjaalton> setting maxtapmove back to 200 probably should be done
<jcristau> tap to click is teh evil
<jcristau> :)
<tseliot> tjaalton: 220 please
<tjaalton> tseliot: is it such a big deal?-)
<tseliot> that was the value which was previously used
 * tseliot considers blackmailing tjaalton...
<tseliot> :-P
<tjaalton> hmm ok, according to the ml discussions it was said to be 200, but git should know
<tjaalton> :)
<tjaalton> send a crate of beer and I'll deliver the new driver on a velvet cushion ;)
<pwnguin> canonical - 10 patches to x.org 0.0466%
<pwnguin> i wonder if that includes the time during which daniel stone was employed
<tjaalton> nope
<tjaalton> that was quite an attack from gregkh..
<pwnguin> and hardly constructive
<jcristau> it was also quite true, from what i can tell, so..
<pwnguin> I wonder where progeny falls on that list ;)
<jcristau> progeny doesn't exist anymore
<pwnguin> so?
<jcristau> so it's not relevant?
<pwnguin> i think it might be representative of a different model than say SuSE or RedHat
<tseliot> wgrant: I have never dealt with gconf before and I was wondering how keys such as /desktop/gnome/peripherals/mouse/tap_to_click are connected to real properties
<tseliot> or how/where do I find names such as "vert_scroll_toggle", etc.?
<tseliot> ah, they are in libgnome...
<tseliot> this still doesn't tell me how a new gconf key can be connected to, say, RTCornerButton
 * tseliot looks in the gnome-settings-daemon
<Ng_> jcristau: so I just got an X server running -intel in the infinite loop state
<Ng_> gdb is mostly refusing to attach to it though
<Ng_> the first time, it said: /build/buildd/gdb-6.8/gdb/linux-nat.c:988: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed.
<Ng_> and now it's just hanging when it tries to attach
<jcristau> yay
<Ng_> so I'm not sure I can be any more useful than I was when this happened and I didn't attach gdb ;/
<Ng_> and it looks like I have to reboot now, X will respond to a -9, but segfaults thereafter
<tseliot> wgrant: ok, I understood how it works. Ignore my previous questions
<jcristau> Ng_: maybe disabling dri helps
<Ng_> jcristau: it might help it not crash on me I suppose, but it won't help me find the bugs :)
<jcristau> Ng_: it might help narrow down the bug, too, if gdb doesn't want to cooperate
<Ng_> mebbe
<Ng_> argh, now X crashed right after the desktop finished loading
<Ng_> I really appreciate all the work Intel are doing, but their drivers seem to be a bit.... interesting
<Ng_> what the deuce, it segfaulted again after reboot
<Ng_> I'm really starting to wonder if there is something wrong with this hardware
<Ng> Windows seems to be entirely stable on it though
<Ng> and now it's looping again. This was never entirely stable, but it's never completely broken on multiple successive boots before
<tseliot1> tjaalton: I can implement top-right bottom-right tapping for the right click in the gnome-control-center, however it would be too much work to do in for KDE 4 too (at least for Intrepid). Can't we restore hardy's behaviour in this regard, so that if users enable tapping they get automatically the right click too? If they disable tapping my changes to the driver won't affect them. What do you think?
<tseliot1> tjaalton: this would mean that we keep wgrant's patch as it is and modify only the driver so that it behaves as it used to do in Hardy
<tseliot1> federico1: I have updated screen-resolution-extra in addition to what I wrote in the email which I sent you
<tseliot> tjaalton, federico1: I might have missed your replies because of problems with my Internet connection
<jcristau> you didn't miss anything
<tseliot> jcristau: ok, thanks
<tjaalton> tseliot: you don't need to care about kde
<federico1> tseliot: oh, I hope to start checking it out today or tomorrow (been fixing other stuff)
<federico1> tseliot: I haven't replied yet :)
<tseliot> tjaalton: I do care about it because I use gnome on the desktop and kde 4 on my laptop
<tseliot> federico1: ok, no problem
<tseliot> tjaalton: I hope to fix this by adding the support for input to X-Kit in Ubuntu 9.04, however I would like the right click to work on 8.10 too
<tseliot> tjaalton: would it be a problem to restore Hardy's behaviour?
<tseliot> tjaalton: I could write a patch which we could use only in Intrepid
<tjaalton> tseliot: please do
<tseliot> tjaalton: ok, great, I'll do it
<tjaalton> still no xserver 1.5 support in fglrx 8.9
<tseliot> yes, I know...
<tseliot> an SRU will be required after Intrepid is released
<tseliot> tjaalton, bryce: I have prepared a patch for the touchpad and I have also the source with the changelog, etc. ready. Shall I file a bugreport and post the links to the files there?
<bryce> tseliot: yep
<tseliot> ok
<tseliot> bryce, tjaalton: here's the link (and yes, I know that main is frozen): https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/271823
<ubottu> Ubuntu bug 271823 in xfree86-driver-synaptics "[intrepid] touchpad less responsive and top/bottom-right corner tapping disabled" [Undecided,New] 
<tjaalton> frozen for alpha6
<tjaalton> tseliot: please attach just the patch
<tjaalton> since the driver is maintained in git
<tseliot> tjaalton: ok
<tseliot> tjaalton: ok, I posted the link to the patch
<bryce> should that patch also go upstream?
<tseliot> bryce: no, since upstream code has changed too much
<bryce> ok
<tseliot> bryce: this is just a temporary fix to restore Hardy's behaviour in Intrepid
<bryce> gotcha
 * tseliot > dinner. Bbl
<bryce> tjaalton: btw have you put in for sponsorship for the uds?
<tjaalton> bryce: nope, not yet anyway. I'll ask my boss first if he's ready to send me there like before ;) (to get the daily allowance etc)
<bryce> cool.  looks like the procedure is a bit different this time around
<bryce> instead of me putting in names directly, there's a form to fill out and you pick a brainstorm idea to champion.  the due date for that is the 25th
<tjaalton> yep, I even poked brainstorm.u.c a bit.. what a mess :)
<bryce> yeah
<pwnguin> just pick something that's already done ;)
<tjaalton> and I even commented on the one that demanded widescreen resolutions for failsafe
<bryce> !
<tjaalton> heh
<bryce> okay.....
<bryce> tjaalton: btw, I'm getting to understand acpi-support quite a bit better
<tjaalton> bryce: so, should we purge it?-)
<bryce> no, but it needs some serious work
<bryce> I definitely agree we need to close the gap with debian on this
<bryce> unfortunately it's not so simple as to re-use their package 
<pwnguin> acpi-support was mjg's brainchild, no?
<bryce> like 80-95% we can probably use as is; there's some bits that are there to delete stuff from the ubuntu package, which would need to be redone
<bryce> also debian and us have very different debian/ directories, that would need to be sorted out
<bryce> pwnguin: it started life as some scripts from him, but as I gather, it was mainly put together and maintained by another gyuuuuuuy
<bryce> dah, damn keyboard repeats ;-)
<pwnguin> well, i saw that it was orphaned in debian
<pwnguin> and someone picked it up from mjg, but i havent paid much attention to it otherwise
<bryce> Thom May
<bryce> pwnguin: in Debian Bart Samwel has been extremely active on maintaining it
<pwnguin> it kinda seems like a competitor to HAL
<bryce> aiui, it wrappers HAL
<pwnguin> huh
<bryce> or at least the debian version does
<bryce> our version lacks this (which I think possibly might be the source of some of our recent hotkey/acpi issues)
<pwnguin> well, i just looked enough at it to see if the toshiba scripts did anything relevant to me, and it didnt =/
<pwnguin> (ages ago)
<pwnguin> hmm. tab works, and alt works. wonder what alt+tab doesn't
<bdmurray> bryce: shoud bug 248521 not be an issue anymore?
<ubottu> Launchpad bug 248521 in xserver-xorg-input-vmmouse "vmmouse seems to register incorrect x,y values for mouseclick" [High,Confirmed] https://launchpad.net/bugs/248521
 * wgrant wonders what ATI thinks they're playing at.
<jcristau> wgrant: they want to see everyone switch to radeon
<jcristau> or buy nvidia hw
<wgrant> jcristau: Heh.
<bryce> bdmurray: regarding 248521, talk to timo to be sure
<bdmurray> bryce: okay, I noticed an install I was testing today had no mouse section
<bryce> bdmurray: right, it now uses evdev automatically
<Ng> is anyone else seeing the intel driver getting wedged when they unlock their screen sometimes?
<bryce> nope
<bryce> you're on i855 still yes?
<bryce> is it hanging or crashing?
<Ng> 965
<Ng> I get the background and a cursor, but everything else is wedged, and the log has messages about the server looping
<Ng> I've had it a few times on G45, but not in the same circumstance, that was more logging in related
#ubuntu-x 2008-09-19
<Ng> but something is very wrong with the G45 support afaics. windows seems to be just fine, but xorg crashes a lot, hates switching back to console VTs and drops the signal irregularly
<Ng> not drops, flaps
<bryce> weird, I'm on a 965 right now and am not seeing such problems
<bryce> when did you start seeing this?
<Ng> after the fix got in for it crashing when locking the screen and I switched back to compiz I think, but I lock quite a few times a day and it's only happening once a day at most
<bryce> has it been within the last couple days, or longer?
<Ng> yeah, it happened a few minutes before I mentioned it
<bryce> no I mean, did it *start* happening within the last couple days?
<Ng> oh
<Ng> hmm
<Ng> bryce: first time I mentioned it here was on the 16th
<bryce> ok, when I get to a good breaking point I'll get this machine up to the latest and see if I can reproduce.  I've not updated/rebooted it since early this week
<Ng> groovy
<bryce> (chasing down an -ati banding issue atm)
<Ng> is there a quick guide for what I should be building to run -intel from git?
<bryce> Ng, you mean dependencies?
<bryce> Ng, the current git -intel probably needs gem, which might mean git versions of mesa and libdrm
<bryce> Ng, I went through the exercise last month - http://people.ubuntu.com/~bryce/Testing/Gem/
<bryce> however I think we've pulled in some of that to Ubuntu now, so you may be able to just build xf86-video-intel directly 
<Ng> hmm
<tjaalton> wow that was fast.. svu already committed the abnt2&jp106 patch to xkeyboard-config
<tjaalton> less than an hour after I filed the bug
<seb128> jcristau: hi, do you plan to update pixmap in debian soon? it's required for the new cairo version ;-)
<tjaalton> seb128: already done ;)
<tjaalton> in experimental
<seb128> tjaalton: ok, so the pts is lagging
<jcristau> no, i didn't upload
<tjaalton> ah ok
<jcristau> should be pretty much ready in git though
<seb128> and I meant pixman but you corrected the typo I guess ;-)
<jcristau> yeah
<seb128> jcristau: any reason you didn't upload?
<jcristau> yeah. i'm trying to get work done
<tjaalton> heh
<seb128> ok, nothing broken in the new version
<seb128> I was just wondering if that should be held back for a good reason
<seb128> thanks ;-)
<jcristau> there hasn't been any api/abi change from 0.11.8 though, is cairo not happy with that?
<seb128> the cairo configure requires the new version
<seb128> let me look why exactly
<jcristau> i'll try to get to pixman over the week end. hopefully.
<seb128> ok, thank you
<jcristau> or i could try to blackmail you into getting #491292 fixed in debian :)
<seb128> .la are annoying
<seb128> I'll try to get this one fixed for the next upload ;-)
<bdmurray> tjaalton: bryce said I should ask you if bug 248521 would be fixed now
<ubottu> Launchpad bug 248521 in xserver-xorg-input-vmmouse "vmmouse seems to register incorrect x,y values for mouseclick" [High,Confirmed] https://launchpad.net/bugs/248521
 * Ng has a go at building drm, mesa and xf86-intel
<Ng> this is probably going to go horribly wrong ;)
<Ng> oh right, fail, kernel patching required
<Ng> I figured it was just part of the kernel bits of libdrm
<tjaalton> bdmurray: well, we don't use vmmouse anymore in intrepid :)
<bdmurray> tjaalton: okay, that's what I'd observed on a new install, but what happens to early intrepid adopters?
<tjaalton> bdmurray: the same; input devices on the xorg.conf are ignored
<bdmurray> tjaalton: that's interesting, so everything should just work?
<tjaalton> bdmurray: yeah..
<tjaalton> evdev steals the input devices
<tjaalton> so while the other drivers would load, evdev stomps over them and grabs the devices
<bdmurray> tjaalton: okay, thanks do you want to update that bug or shall I?
<tjaalton> bdmurray: maybe I could check that they really are using input-hotplug
<bdmurray> tjaalton: How would you check?
<tjaalton> bdmurray: I'll ask a few questions
<bdmurray> tjaalton: alright, I'll watch the bug to find out which questions!
<bryce> :-)
<tjaalton> bdmurray: heh, well there are no logfiles but the one from July, so those should reveal if evdev is used or not
<superm1> hi guys, is wacom stuff supposed to be working OOTB on supported devices on intrepid, or should some xorg.conf poking still be necessary?
<tjaalton> superm1: should work, but the driver is buggy
<tjaalton> superm1: needs an update in the kernel too
<superm1> tjaalton, well this is a usbish device, what's supposed to trigger it's detection?
<tjaalton> superm1: hal, so if lshal doesn't show it, file a bug with lshal output
<superm1> wacdump can read it's input file in /dev/input
<superm1> ok let see
<tjaalton> the wacom fdi file might not recognize it
<superm1> lets see, /usr/share/hal/fdi/policy/20thirdparty/10-wacom.fdi right?
<tjaalton> yep
<tjaalton> but check lshal, is the device listed there?
<superm1> well this is an n-trig device that is (somewhat) supported by wacom's framework, i was looking what's involved to add more full support.
<superm1> so most definitely looking at this fdi file, it won't match on it
<tjaalton> yeah
<superm1> well i'll try to force add some stuff to this fdi file to match on the things coming up
<superm1> how is hal's info.product name generated particularly?  It's a pretty ugly name
<superm1> like HID 1b96:0001 right now
<tjaalton> it's from the device
<tjaalton> but that's probably not the right one
<superm1> well it's the same event file that responds to things in wacdump
<superm1> according to lshal
<tjaalton> lshal usually lists a couple of udi's for every device
<tjaalton> ah ok
<bryce> superm1: btw I've made some progress with that gradient banding issue
<superm1> bryce, oh? what's it's status?
<bryce> superm1: apparently the dither registers changed with the newer hardware and that change isn't reflected in the driver.
<superm1> bryce, that type of thing isn't abstracted by atombios?
<bryce> apparently not
<superm1> that seems odd
<bryce> alex has given me new registers (not sure if the docs for this hw are available publically yet), but I tested them and they don't work
<bryce> well, I see in the code there's already 4 different registers listed for dithering on different classes of hw
<superm1> interesting
<superm1> so must not be abstracted then
<superm1> it looks like in this fdi file you don't exactly have the granularity to turn on multiple "Types" do you?  i turned on stylus for this input.product, and that works, but then i dont click touch capabilities
<bryce> hmm, I'd think you could do that
<superm1> yeah i guess i don't know the syntax much on it yet, so i'll poke around
<pwnguin> i would love to find some documentation regarding hal and wacom
<bryce> pwnguin: I put some links on wiki.ubuntu.com/X/Config iirc.  Didn't find stuff on hal + wacom specifically, but I'd also like to dig that up
<bryce> hey, I just got an email from Michael Larabel - he likes the new bulletproof-x system, and sent me a patch, too
<pwnguin> heh
<pwnguin> ah, the phoronix guy
<pwnguin> kind of wierd journalism, to post benchmarks and write code
<superm1> pwnguin, well it looks like you can literally use every variable supported in 'man wacom'
<pwnguin> superm1: right, but im not sure what it's setting up
<superm1> but i'm having a hard time getting multiple instances of devices to come up (eg if the same device file is supposed to support stylus and touch)
<pwnguin> (i dont have my tablet handy right now)
<pwnguin> in my case, i need to do something crazy with the laptop identification
<superm1> is the device not normally supported by the wacom driver, it just turns out you were lucky?
<pwnguin> because it's serial connected
<pwnguin> its a tabletPC
<superm1> well gathering stuff like that together to put into FDI's and building a database would still be useful
<pwnguin> indeed, but i really have no clue what the hell hal is doing. merge add append
<superm1> i've just been using merge for my lines
<superm1> i'm not sure about when to use add or append
<pwnguin> im not even sure what the data structure those operations work on is
 * pwnguin dislikes voodoo programming
<tjaalton> bryce: check bug 272086, things missing from the new failsafe mode
<ubottu> Launchpad bug 272086 in xorg "could not configure display at boot, now defaults to 800x600" [Undecided,New] https://launchpad.net/bugs/272086
<bryce> tjaalton: looking
<bryce> yeah those are just innocuous warnings, but I've fixed up the code anyway; we probably don't need that logic
<tjaalton> ok, cool
<bryce> tjaalton: with -nvidia being dropped from inclusion on the CD, do we still include -fglrx?
<bryce> tjaalton: and if we do, should we?
<tjaalton> we never have
<tjaalton> only the modules, maybe
<tjaalton> but no need for that either
<bryce> what I'm wondering is, how sensitive are we to the late -fglrx with the CD release
<tjaalton> it doesn't matter a bit :)
<bryce> if fglrx isn't included on the CD, does it matter so much if it doesn't come in on time?
<bryce> hmm
<bryce> tjaalton: did we used to ship l-r-m on the CD?
<tjaalton> bryce: ye
<tjaalton> +s
<tjaalton> I think it's still there, but since lrm no longer has modules for nvidia/fglrx..
<bryce> right
<bryce> interesting, this gives us some flexibility then
<tjaalton> fglrx probably wouldn't make it to beta
<tjaalton> won't
<Awsoonn> I have upgraded a laptop to interpid today, and X wont start, ABI mismatch of somesort.
<tjaalton> Awsoonn: full Xorg.0.log please
<Awsoonn> righto.
<bryce> Awsoonn: are you the one who reported 272086?
<bryce> or if not, check if your Xorg.0.log matches the one in that report
<tjaalton> I've seen a couple of those, probably fglrx related
<tjaalton> oh yes, 271905
<tjaalton> bug 271905
<ubottu> Launchpad bug 271905 in xserver-xorg-video-ati "X does not start with last update (ati)" [Undecided,New] https://launchpad.net/bugs/271905
<tjaalton> "compiled for 7.10"
<superm1> so unfull upgrade?
<tjaalton> maybe, straight from gutsy -> not supported
<tjaalton> feisty had "compiled for 7.2.0, module version = 1.0.0"
<tjaalton> hmm, 7.10 might have been 7.1.0
<tjaalton> which would mean.. edgy. oh my
<tjaalton> quite a desperate leap I'd say ;)
<tjaalton> Awsoonn: so where's the log?-)
<Awsoonn> i'm workign on cli here, give me asec
<Awsoonn> :p
<tjaalton> ah
<tjaalton> Awsoonn: where did you upgrade from?
<Awsoonn> my office
<tjaalton> erm
<Awsoonn> ;p
<tjaalton> which version
<Awsoonn> 8.04 -> 8.10
<Awsoonn> :)
<tjaalton> and you use fglrs
<tjaalton> -x
<Awsoonn> it was a fairly fresh install of hardy at that.  yea on teh fglrs
<tjaalton> ok so purge fglrx, clean up your xorg.conf and you are fine
<Awsoonn> attached to bug 271905... done
<Awsoonn> alright, I'll go purge and let you know how it goes~
<tjaalton> I know how it goes, it'll work just fine
<tjaalton> mvo: shouldn't the upgrader purge fglrx on upgrade to intrepid?
<tjaalton> hmm not only that, but also clean up xorg.conf..
<tjaalton> I guess there's no de-jockey
<superm1> dpkg-reconfigure xserver-xorg?
<superm1> or perhaps a stub that uses python-xkit to turn off fglrx
<tjaalton> well that would drop all other customizations too
<tjaalton> but yeah, a clean slate works for me ;)
<superm1> i seem to think that most people who have customized it will be able to recover from the loss of functionality
<tjaalton> yeah
<superm1> how easy is it going to be to turn this functionality on/off in update manager though? whenever the SRU is actually ready to fix fglrx?
<tjaalton> I've no idea
<superm1> er well has there been a discussion on how it's going to be implemented yet then?
<tjaalton> not that I know of
<superm1> well i'm assuming this will get up at the next platform or foundations team meeting then
<superm1> bryce, could you let me know whenever it  gets put onto the agenda so I can sit in on that?
<bryce> superm1: okay
<Laney> Hi guys. One of the recent (last day) updates seems to have slain my X. I'm getting errors about get-edid not being installed. Quick workaround? (in a tty at the moment)
<bryce> superm1: when do you think the last date we could accept a fglrx would be, in order to avoid having to auto-purge fglrx for everyone?
<Laney> on intrepid btw
<bryce> Laney: what driver are you using?  Xorg.0.log please.
 * superm1 looks at the release schedule to think of an answer
<Laney> bryce: Give me a minute - it's difficult to do stuff this way ;)
<superm1> bryce, i think a solution should be ready to activate the week of oct 16 or so
<superm1> bryce, so that there is a week to do testing prior to rc
<superm1> and by solution ready to activate, i'm referring to the purge
<mvo> tjaalton: I have no plan for fglrx users right now, I had kind of hoped we get a new version in time. update-manager can deal with that if required
<Laney> Transcribing these. Xorg.0.log - http://pastebin.com/f59167dfd :0.log - http://pastebin.com/fe8c308b
<tjaalton> superm1: did/does fglrx divert libdri.so?
<superm1> tjaalton, yeah it does now
<Laney> Card is an ATI of some description
<tjaalton> mvo: ok, seems like it'll be post beta at the earliest
<bryce> mvo, do you have an opinion on when the cutoff date should be for us to consider fglrx?
<tjaalton> superm1: ok, so these problems are definately fglrx related then :/
<superm1> tjaalton, well its only in the last upload or two..
<superm1> tjaalton, and the diversion gets cleaned up on postrm
<tjaalton> superm1: aha! :)
<mvo> post-beta sounds not ideal
<bryce> mvo, well I can guarantee it won't be coming before beta is out
<mvo> bryce: I think -rc is the latest date, but even then we should prepare a backup plan (i.e. update-manager removing it etc)
<tjaalton> superm1: you get to own that bug then :)
<superm1> tjaalton, what bug?
<tjaalton> bug 271905
<tjaalton> ubottu dead
 * superm1 kicks ubottu 
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/271905
<tjaalton> the ABI of the fglrx provided libdri.so doesn't match the server
<superm1> are you sure they have fglrx installed?
<tjaalton> confident
<ubottu> Launchpad bug 271905 in fglrx-installer "X does not start with last update (ati)" [Undecided,Incomplete] https://launchpad.net/bugs/271905
<ubottu> Sorry, I don't know anything about dead
<ubottu> Launchpad bug 271905 in fglrx-installer "X does not start with last update (ati)" [Undecided,Incomplete] 
<superm1> okay, i think i'll mark it dup of the other ABI bug
<superm1> since they all come in together like that
<tjaalton> ok, so seems like until the upload it was fine to have fglrx installed, but now when libdri is diverted things break
<Laney> This seems to be what I'm experiencing. Shall I purge fglrx-installer?
<superm1> Laney, yeah you will have to
<Laney> Right. Will report back in a minute.
<Awsoonn> :3 wow, tjaalton, have you been dealing with this bug all day
<Awsoonn> or just a coinsedence?
<superm1> well it shouldn't have been fine to have this fglrx installed anyhow though
<superm1> with libGL diverted
<superm1> should have seen some basic breakage there too
<tjaalton> Awsoonn: no, but when I closed it as invalid there was this funny feeling that I did something wrong (rarely happens though)
<tjaalton> so it got reopened, and now the reason was found
<tjaalton> rejoice!
<tjaalton> :)
<Awsoonn> :) indeed
<Laney> Excellent, that fixed it! And now I have Compiz as a bonus
<bryce> Laney: hopefully you should find -ati is much much better than it used to be
<Laney> bryce: It definitely seems to be. I'm just waiting for my first Compiz crash ;)
<bryce> heh
<superm1> given that nvidia's 177 is a beta driver too, do you  think that will be SRU worthy whenever they call a final?
<Laney> I think it's made scrolling more laggy in Firefox though, although that could be some kind of negative placebo effect
<superm1> (given the modularization of the drivers and all for intrepid)
<bryce> superm1: I think with the modularization, the ability to do sru's ought to be a lot more feasible
<bryce> esp. if we're going from 100% non-functional to functional
<superm1> right
<bryce> hard to argue that there could be potential regressions in that case ;-)
<bryce> but of course it's up to the release team...
<bryce> I'd certainly give it my +1 tho
<bryce> Laney: well you could toggle compiz off and on and see if it makes any difference
<tjaalton> superm1: 180 is released some time in Q4
<Laney> bryce: I am doing
<bryce> laney there are several configuration settings that can affect -ati performance; see man radeon
<superm1> tjaalton, well 180 would be more of a backport type of thing, there should be a final 177 though that comes
<Laney> It is definitely quite significantly more laggy with compiz on. Probably enough for me to leave it off.
<tjaalton> superm1: well, if phoronix is to be trusted, 180 will be the stable version, 177 is beta
<tjaalton> but who knows
<superm1> tjaalton, well if that's the case, then I'd think SRU's are out of the question
<superm1> tjaalton, but traditionally do they jump major version numbers from beta to release?
<superm1> i thought they were pretty consistent about doing a bunch in one series until they hit a final for that series
<bryce> laney, if there's not a bug report on it in launchpad already, feel free to file one - or ask on #radeon to see if it's a known issue or if there's a known workaround
<tjaalton> superm1: hmm, right. 169.09 was the first stable one of that series IIRC
<bryce> laney, I've heard some people report that using a different migration heuristic setting can help, but I think that's more in the kludge category
<Laney> bryce: Radeon bug, not compiz?
<bryce> laney, right
 * Laney nods
<Laney> I'll have a bit of a dig around
<bryce> xserver-xorg-video-ati is the package to file bugs against
<bryce> what's the best way to detect powerpc hardware?
<bryce> (for bug 155685)
<ubottu> Launchpad bug 155685 in xorg "vesa doesn't work with PowerPC, so failsafeXServer fails" [Medium,Triaged] https://launchpad.net/bugs/155685
<superm1> uname ?
<bryce> uname -m it is
<bryce> it prints "ppc" iirc?
<superm1> er hm not too sure
 * bryce snags source
<superm1> it might output ppc64 on some of them 
<superm1> if you really become desperate, you can upload  something that in it's debian/rules runs uname -m ;)
<bryce> hmm, looks like it should print "powerpc" actually
<bryce> hard to say though.  I'll just check for all three
#ubuntu-x 2008-09-20
<bryce> committed
<derekS> is this for xorg?
<bryce> new improved failsafe-x stuff pushed up :-)
<bryce> (also some minor dexconf tweaks)
<mnemo> i just upgraded to intrepid alpha and now X.org wont start because it says "ABI major version does not match xserver version" (this is for the ATI fglrx driver) .... how can I workaround this issue?
<superm1> remove the fglrx driver
<superm1> doesn't work in intrepid yet
<mnemo> ok, where can I do that?
<superm1> apt-get remove --purge xorg-driver-fglrx
<superm1> and then dpkg-reconfigure xserver-xorg -phigh
<superm1> and you should be back on the radeon driver
<mnemo> perfect, thanks... i'll try this
<mnemo> it worked.. thanks again superm1
#ubuntu-x 2008-09-21
<tjaalton> heh, my younger daughter (2yrs) can't get enough of matt's mugshot.. can't read the planet any further :)
<pwnguin> mdz's hackergotchi?
<tjaalton> yep
#ubuntu-x 2009-09-14
<apw> tseliot, i hear you have bryces mantle this month ... just in time for a nasty intel gpu hang to appear
<tseliot> apw: you're right. And I don't seem to be able to reproduce the problem here
<tseliot> apw: did you find a way to reproduce the lockups?
<apw> damn i had two different machines do it in 5 minutes last night.  the second of wihch i was using to debug the first
<apw> i _think_ but am not sure that a suspend/resume in the past may be required to trigger it
<tseliot> ok
<apw> cirtainly two of the ones i've seen on my GM45E were instantly on resume
<apw> i did maybe 5-6 s/r cycles last night and got one
<tseliot> ah
<apw> it was definatly a gpu hang, sequence number thingy not going up any more
<apw> jk mentioned that he had had one and indicated he had noted that he wasn't gettting interrupts any more
<apw> i don't know if he meant they were disabled or not ...
<tseliot> ok, what bug number are you referring to? (just to be sure)
 * apw is looking for the 'how to debug GPU hangs page' to see if there are any preparetory steps to get more debug
 * apw gets the numbers
<apw> the original was filed by mdz
<apw> bug #424055
<ubottu> Launchpad bug 424055 in xserver-xorg-video-intel "[i945GME] X freeze on Dell Mini 10v in Karmic" [Unknown,Confirmed] https://launchpad.net/bugs/424055
<apw> i have bug #429199 and bug #429191 for my two occurances
<ubottu> Launchpad bug 429199 in xserver-xorg-video-intel "[GM45 Express] i915 graphics hang" [Undecided,New] https://launchpad.net/bugs/429199
<ubottu> Launchpad bug 429191 in xserver-xorg-video-intel "[945GME] i915 graphics hang" [Undecided,New] https://launchpad.net/bugs/429191
<tseliot> great, I have a Dell Mini 10v so I should be able to reproduce the 1st bug
<apw> mdz mentioned two other people who have seen it
<apw> my gme945 is also a mini10v, so you are in the right area there, though that has been the one  i have reprod'd it less often on
<apw> mine are both with the -10.32 karmic kernel
<tseliot> ok
<apw> is there any steps i should take (or a script to folllow) to get the most info from the next reproduce by
<apw> tseliot, is this more likely to be kernel or mesa level issue do you think?  should i open kernel tasks on these bugs?
<tseliot> apw: you can either try mdz's script or follow amitk's instructions: http://smackerelofopinion.blogspot.com/2009/06/looking-at-intel-x-hangs.html
<apw> smackerel of opinion is ckings blog
<tseliot> apw: right, wrong person ;)
 * apw notes OSD has lost its mind and is using its second slot only ... sigh ... what else can break
<tseliot> as regards the bug, I wouldn't know, I have yet to look into this problem
<tseliot> this is worse (with nvidia): https://bugs.launchpad.net/ubuntu/+bug/429003
<ubottu> Launchpad bug 429003 in eglibc "[karmic] Xorg (and anything GLX) crashes on startup" [High,Confirmed]
<apw> tseliot, to add to your woes, my ATI based T30 with stock karmic on it, does not repaint the screen properly at all
<apw> so i'd say thats all three major graphics in the crapper one way or anohter.  though that does at least make the intel look good
<tseliot> apw: with and/or without compiz?
<apw> with compiz
<tseliot> have you filed a bug report about it?
<apw> nope not yet ... damn i should do that now ...
<apw> i'll get it updated to 'now' and make sure its still there and get it filed too ... 
 * tseliot installs the new libc6 for testing. Wish me good luck
 * apw has that, so that i think will work :)
<apw> tseliot, i note that the gdm login is ok on this machine ... i assume that is not compositied, it goes to poop as i login
<tseliot> apw: try disabling compiz and see if you notice the same problem
<apw> will do
<tseliot> thanks
 * tseliot restarts X
<apw> tseliot, ok just did 4 s/r cycles on my GM45 and its come back up ok, but i am seeing screen corruption now, and all of my window manager wigets are invisible.  still there but invisible
<apw> oh and now, hitting print screen, has taken it out
<tseliot> apw: what do you mean by window manager widget? Can you take a screen shot, please?
<tseliot> oh
<apw> as in the decorations the wm normally adds, the top bar with the title etc ... all invisible
<apw> you can click (could) on them and move the windows, but they are 'not there'
<tseliot> are you using compiz?
<apw> yep using compiz
<apw> apw@dm$ cat i915_gem_seqno
<apw> Current sequence: 1807468
<apw> Waiter sequence:  1807469
<apw> IRQ sequence:     1807447
<apw> i assume that that is bad?
<apw> tseliot, is there anything else i can gather to help understand this one?
<tseliot> ok so obviously something wrong happens when suspending/resuming
<tseliot> can you add these details to the bug report?
<apw> i'd say its a trigger for sure ... i logged out and in, then did 4 s/r and thats the state i ended up in
<tseliot> or maybe file a new one
<apw> whats your preference, can do either
<apw> i have some pictures of the mess just before it locked too
<tseliot> maybe file a separate bug so that I can upstream it
<apw> ack
<tseliot> if they are really the same bug then we'll merge the 2 reports
<apw> yep understand its easier to merge than split every time
<apw> tseliot, bug #429241
<ubottu> Launchpad bug 429241 in xserver-xorg-video-intel "[GM45E] i915 graphics corruption and hang" [Undecided,New] https://launchpad.net/bugs/429241
<hyperair> is there a known boot-hang with the karmic kernel and ati cards?
<hyperair> boot-hang issue i mean
<tseliot> apw: thanks
<apw> hyperair, not that i am aware of as yet
<apw> tseliot, confirmed my ati experience is fine with compiz disabled
<apw> hyperair, i assume your hang is before login?
<tseliot> hyperair: what do you mean by boot-hang exactly?
<hyperair> apw, tseliot: i'm not sure of the specifics, as i've never actually looked at it yet. this is from descriptions a friend gave me (he went and reinstalled 8.10 due to network issues in jaunty and boot-hang issues in karmic)
<tseliot> apw: ok, can you file a bug report about it (including this detail), please?
<hyperair> apw: it definitely doesn't reach the login screen, at least.
<hyperair> apw: from what i've heard, it's like the usplash times out and then falls back onto a black screen with a blinking cursor.
<tseliot> hyperair: I would need him to reproduce the problem, reboot, boot in Recovery mode and collect /var/log/Xorg.0.log and /var/log/Xorg.0.log.old
 * apw turns into bug file monster
<hyperair> i'll see if i can grab hold of him sometime =\
<tseliot> heh
 * tseliot reboots into jaunty hoping that ubuntu startup disk creator works there
<hyperair> it works for me on karmic =\
<hyperair> it just takes up loads of i/o and hangs my entire machine for a good 10 minutes or so
<apw> tseliot bug #429251
<ubottu> Launchpad bug 429251 in xserver-xorg-video-ati "ATI graphics corruption with compiz" [Undecided,New] https://launchpad.net/bugs/429251
<tseliot> apw: thanks again
<apw> heh ... a world of pain shoved over the wall and he thanks me :)
<tseliot> a world of pain without useful information would be much worse ;)
<apw> i shoved a GPU dump into that GM45E hang no idea what that says mind, hopefully someone can read it
<_B00> good morning :D
<_B00> anyone about?
<tseliot> apw: that's definitely useful. I'll try to get a GPU dump on the Dell Mini 10v too. Upstream developers such as jbarnes should be able to read them (unfortunately I'm not)
<tseliot> _B00: what's up?
<_B00> hi tseliot, just wondering what this is.
<_B00> is it updates for the x-server?
<_B00> as I'm having trouble getting gfx drivers to work on me TNT2 (snigger)
<tseliot> _B00: "this" being what? This channel?
<_B00> yea adn the webby, also the selection in the 3rd party software on ubuntu tweak
<tseliot> _B00: are you using Nvidia's proprietary driver?
<_B00> I've tried loads of variations and settings from various forums
<_B00> even the drivers on nvidia web
<_B00> I read there was a known bug for my card with this release of ubuntu (jaunty 9.04)
<_B00> I think all I have is nv at the moment, after cleaning the drivers out i chose
<_B00> which did not work
<tseliot> _B00: that might be a problem. Installing all kinds of drivers (especially the ones from Nvidia's website) can cause problems with the packages in Ubuntu
<_B00> VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15)
<_B00> I installed a set of drivers one at a time tseliot 
<_B00> then purged the installs after no success
<_B00> "no nvidia driver present nvidia_something_so
<_B00> "
<_B00> I went to the directory and there it was. So no idea personally
<tseliot> _B00: did you uninstall the one from nvidia's website?
<_B00> yea
<_B00> i do a whereis nvidia and nothing shows
<_B00> also gui search :D no results
<tseliot> please try installing the driver (nvidia-glx-71) with either jockey or envyng and, if it doesn't work, please file a bug report on launchpad about nvidia-glx-71
 * tseliot restarts X
<tseliot> apw: can you add the version of mesa that you're using with the -ati driver to the bug report, please?
<apw> tseliot, doesn't that get picked up with the ubuntu-bug ...-ati ... shame on us
<tseliot> apw: my bad. This is what happens when I look at different bugs at the same time...
<tseliot> ;)
<apw> tseliot, is it already in there?
<tseliot> apw: yep
 * apw finds another corruption bug in ati
<tseliot> libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu3
<apw> seems that the OSD gets shows crapola like an old fashioned TV off tune when connecting the network!
<apw> without compiz
<tseliot> :-/
 * apw files more bugs ... boo
<apw> now is that an OSD bug, or a grpahics bug
<tseliot> so xrender is broken too... nice
<apw> only seems to be affecting OSD ...
<apw> nothing else i've tried is ill
<apw> oh xrender, not everyone uses that i guess
 * tseliot nods
<tseliot> can you reproduce the problem with -intel (without compiz)?
 * apw tried
<apw> tries
<apw> tseliot, seems ok on this intel GM945E
<tseliot> apw: ok, let me see if upstream is aware of this
<apw> tseliot, bug #429295
<ubottu> Launchpad bug 429295 in xserver-xorg-video-ati "OSD showing corruption on ATI graphics" [Undecided,New] https://launchpad.net/bugs/429295
<tseliot> apw: great, I'll try to upstream this too
<jcristau> tseliot: so you're the new bryce? :)
<tseliot> jcristau: only for this month
<apw> i think thats a compliment :)
<tseliot> apw: it surely is ;)
 * apw fills his digital camera with pictures of broken ubuntu :/
<apw> i've marked that OSD one for osd as well, so its visible when regular users try and file a duplicate
<tseliot> apw: good move. Thanks
 * tseliot is waiting on the Dell Mini 10 v to finish its endless dist-upgrade...
<apw> heh nasty
<apw> tseliot, anything more i can specifically do on any of these?  else i'll wander off and tread the fine line between them
<apw> obviously if you think any of them are kernel, do yell at me
<tseliot> apw: ok, I'll let you know. Thanks
<apw> the intel stuff is likely to be a major pain point till its fixed 
 * tseliot (sadly) agrees
 * tseliot -> lunch
<tjaalton> isn't it the one where downgrading mesa helps?
<apw> tjaalton, it ?
<apw> i915 hangs, ati corruption, or osd corruption, or something else?
<tjaalton> apw: i915 hangs with compiz
<apw> tjaalton, is there a recommended downlevel for testing there?
<apw> i seem to be able to trigger it pretty quickly if i suspend/resume a lot
<tjaalton> apw: the last 7.5.x version should work
<tjaalton> before the snapshot
<tjaalton> and I see it too
<apw> its the suspend/resume contribution to the issue which worries me, is mesa aware of such things?
<hyperair> re suspend/resume compiz hanging, is it the one where it doesn't redraw, but continues to accept input?
<hyperair> it seems to have disappeared for me recently
<hyperair> but before that, i use a hotkey that restarts compiz
<apw> i've separatly seen that one today as well
<tjaalton> apw: guess the driver state gets broken on susp/resume
<apw> where you could shift desktops using the keys but the screen was blank
<apw> i think it regressed to death pretty soon after that
<apw> bah too many similar issues ... hard to know which one one has
<hyperair> heh yeah
<hyperair> if you're on KMS, switching to a VT works
<hyperair> i'm not sure about without
<tseliot> apw: as regards the problem with osd and ati. Can you try adding the following options (one at the time) in the "Device" section of your xorg.conf? Option "EXANoComposite" Option "EXANoUploadToScreen" Option "EXANoDownloadFromScreen"
<apw> tseliot, one at time as in 'each on its own'
<tseliot> apw: yes, that would be a better explanation of what I meant to say ;)
<apw> tseliot, do those take a parameter?
<apw> ie are they all 'true' in your thing there
<jcristau> no parameter is the same as true
<tseliot> right
<apw> tseliot, nope none of those help
<tseliot> apw: ok, thanks
<apw> tseliot, bug updated
<tseliot> apw: thanks again
 * tseliot is trying hard to make its GPU hang after 5 suspend/resume cycles
<tseliot> apw: any suggestions on how to make the GPU lock up on suspend/resume (other than beating the netbook with a stick). It hasn't locked up after 11 cycles
<apw> tseliot, not really ... i found it tended to happen on resume that was all
<tseliot> ok
<apw> i've not see any other definative trigger
<tseliot> this GPU seems to be bullet-proof...
#ubuntu-x 2009-09-15
<pwnguin> alright. so i'm very lazy and only now upgraded my laptop to karmic
<pwnguin> is 3d rendering now a requirement for rendering? ive got some odd rendering quirks with nouveau
<apw> tseliot, hi, just had another occurance of the corruption and gpu hang.. updated the LP bug
<tseliot> apw: ah, nice, let me update the upstream report
<apw> there is another GPU dump on there
 * tseliot nods
<tseliot> done
<tseliot> apw: on a second thought I think I'll mark 429199 as a duplicate of 429241. After all, all the gpu dumps and all of the details are in the latter
<apw> sure if you want to do that, i'd been keeping the corruption and non-corruption ones apart, but the former are the only ones i've hit since
<tseliot> apw: also did you manage to reproduce 429191 and get a GPU dump?
<apw> tseliot, not seen another occurance on my 10v yet
<tseliot> apw: ok, mine was still very stable after 23 suspend/resume cycles...
<apw> it seems much harder to trigger than the isues on the GM45
<apw> and i use the GM45 based machine more too
 * tseliot has only GM45 chipsets at home
<tseliot> :-(
<apw> tseliot, then you are in for a world of pain like me :/
 * tseliot nods
<tseliot> apw: isn't bug 429241 very similar to what they reported here: https://bugs.edge.launchpad.net/ubuntu/+bug/421736 ? (albeit with different chipsets)
<ubottu> Launchpad bug 429241 in xserver-xorg-video-intel "[GM45E] i915 graphics corruption and hang" [Undecided,Confirmed] https://launchpad.net/bugs/429241
<ubottu> Launchpad bug 421736 in xserver-xorg-video-intel "karmic: Compositing broken on resume from suspend" [Unknown,Confirmed]
<apw> tseliot, there they seem to talk about 'partially transparent things become invisible ' and definatly i've seen that as part of my symtoms at times.
<apw> though they don't seem to talk about it then going on to lokc up solid generally
<tseliot> apw: it's possible that you were facing two bugs, one of which could be 429241. I think I need to update the upstream bug report
<apw> tseliot, give me a sec, as i think the fix for that was in
<tseliot> ok
<apw> the fix toted in bug #419264 was the one below:
<apw> drm/i915: Fix CPU-spinning hangs related to fence usage using an LRU
<ubottu> Launchpad bug 419264 in linux "Uses 100% CPU with latest mesa/libdrm update" [High,Fix released] https://launchpad.net/bugs/419264
<apw> and that at least is in the karmic kernels i was running
<apw> tseliot, dunno what that means for your upstream report update :)
<Ng> apw: talking of G45 hangs, do you happen to know if http://bugs.freedesktop.org/attachment.cgi?id=29294 made it into any trees?
<Ng> I seem to have entirely lost the bug that that attachment came from :/
<Ng> it's referenced in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/424613 at least
<ubottu> Launchpad bug 424613 in xserver-xorg-video-intel "[i945GM] GPU lockup with intel 2:2.8.1-1ubuntu1" [Undecided,Confirmed]
<apw> Ng, no i do not see that commit anywhere
<Ng> I couldn't even begin to comment on its correctness, but it sounds like a good idea ;)
<Ng> jbarnes wonders on http://patchwork.kernel.org/patch/45938/ if it's worthy of stable@kernel.org
<tseliot> apw: sorry, I meant to say that, in addition to the GPU hangs you might be experiencing 421736. Does 419264 have anything to do with it?
<apw> one referenced the other as a dup i thought, hrm perhaps it got unduped
<apw> in which case you are right
<apw> may be there are two issues, that one, and general hanging
<Ng> aha got it, it's https://bugs.freedesktop.org/show_bug.cgi?id=22336
<ubottu> Freedesktop bug 22336 in Driver/intel "[i965] GPU hang with compiz, active system use" [Critical,New]
<apw> Ng, ok it does appear to be in the drm-intel drm-intel-next branch
<apw> and interestingly its GM45 specific if i am reading the leader correctly
<tseliot> apw: as regards this patch http://patchwork.kernel.org/patch/45938/ , would it be possible to put it in a PPA for testing (Intel would like to get some feedback about it)? This is for Freedesktop bug 22336 , as Ng said
<ubottu> Freedesktop bug 22336 in Driver/intel "[i965] GPU hang with compiz, active system use" [Critical,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=22336
<Ng> apw: I have no idea what the process around this is, if upstream like it that much would we naturally cherry pick it? or wait for it to hit a 2.6.31.X?
<apw> well as its has been indicated as likely stable material we would expect to see it come via 31.x when that gets going
<Ng> ok :)
<apw> however, sa its gm5 specific and talks about hangs, and i have GM45 with hangs ... i would be temped to pick it up and test it myself to see if it fixes _my_ issues
<Ng> hehe
<Ng> I too have GM45 and odd random hangs, so I'd be happy to test it too
<Ng> but I can't reproduce the hangs in any meaningful way, so the best I could do is "err yeah it hasn't hung today". my suspend seems to be broken too atm, so I'm having to do shutdowns when I go home, which is ruining my long uptime tests of things ;)
<apw> how it could have had this issue for so long and never hit it is a mystery
<apw> Ng, whats your suspend broken symptoms?
<tseliot> apw: please test it if you can
<apw> tseliot, i'll put together a test kernel against my GM45 curruption and hang bug and see hwo that pans out
<Ng> apw: typically my laptop just doesn't suspend at all recently. it worked with 31-9, but around the -10 upgrade I also started testing all of Keybuk's boot stuff, so it's entirely possible it's his fault
<tseliot> apw: great, thanks a lot
<apw> heheh
<tseliot> apw: did you have the desktop effects enabled when you experienced the suspend/resume hang with the mini 10v?
<apw> yes always have compiz enabled
<tseliot> the netbook-remix UI tricked me into thinking that compiz was enabled...
<tseliot> ok, I'll try with compiz
<tseliot> apw: can you try what Chris suggested in 429241 when you can, please?
<apw> tseliot, does that imply ... i need that additional file when it next occurs, or is the live data good enough?
<tseliot> apw: I think you need to get it (together with the GPU dump, etc.) after you reproduce the problem
<tseliot> sorry for being a pain :-P
<apw> tseliot, these things happen, its a complex problem
<apw> tseliot, i've also asked chris if he can tell if we have a split command in those two, and pointed him to the wrap patch i am about to test
<tseliot> apw: excellent, thanks
 * tseliot -> lunch
<tseliot> apw: I sent you an email. It looks like you will have some testers with i965 for the patch
<apw> tseliot, thanks ...
<apw> i also see Albert has an idea what it might be
<tseliot> apw: Alberto = tseliot ;)
<apw> Alberto == tseliot, Albert == someone else tho.
<tseliot> apw: who's Albert then?
 * albert23 is Albert
<apw> a good question indeed :)
<apw> hello :)
<apw> albert23, i do indeed have one such render error
<apw>  syslog.1:Sep 15 08:14:32 dm kernel: [ 7689.536305] render error detected, EIR: 0x00000010
<albert23> Is that followed by the PBTBL_ER?
<tseliot> aah, ok ;)
<apw> albert23, no it doesn't seem to be
<apw> doh yes it is
<apw> egrep errror
<apw> hmm happened in the middle of the suspend too
<apw> Sep 15 08:14:32 dm kernel: [ 7689.536305] render error detected, EIR: 0x00000010
<apw> [...]
<apw> Sep 15 08:14:32 dm kernel: [ 7689.536315] page table error
<apw> Sep 15 08:14:32 dm kernel: [ 7689.536316]   PGTBL_ER: 0x00100000
<apw> Sep 15 08:14:32 dm kernel: [ 7689.536318] [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
<apw> Sep 15 08:14:32 dm kernel: [ 7689.552146] PM: suspend devices took 1.648 seconds
<albert23> Looks like it
<apw> ok so i'll find and add that patch to my test kerenl
<albert23> Might be worth to try the mesa fix then. It points to a freedesktop bug that's pretty similar to our bug
<albert23> freedesktop bug 23254
<ubottu> Freedesktop bug 23254 in Drivers/DRI/i965 "Compiz doesn't survive suspend/resume cycle" [Major,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=23254
<apw> tseliot, ... is an updated mesa with that fix something you can spin for me
<apw> i'll get this kernel made available too
<tseliot> apw: ok, let me check what's changed in mesa and I'll put the package in a PPA
<apw> sounds gooood to me
<tseliot> hah, it's just a one line patch
<apw> tseliot, i see it would fit with the patch suggested for the kernel, checking the 'relocation points to within the object'
<tseliot> apw: let's hope that a combination of the two patches fixes the bug
<tseliot> at least one
<apw> i am hoping the mesa fix is the whole thing
<apw> that the kernel change just catches it without the mesa fix ... will test that next
<tseliot> sounds like a plan :-)
<apw> tseliot, though both changes sound like things that should go to stable imo
<tseliot> apw: I agree. I think we can upload them after the freeze
<apw> if that mesa fix works we might want to see if ti can be uploaded for A6, as its a bit of a mess
<tseliot> apw: slangasek might disagree ;)
<apw> he might, then he might not
<tseliot> heh, it's worth trying
<apw> obviously we need to test it first :)
<tseliot> right. I'm building it now
<apw> tseliot, most excellent
<tseliot> it built \o/
<apw> yay
<tseliot> apw: I'm using this new PPA: https://launchpad.net/~albertomilone/+archive/x-testing
<apw> tseliot, sounds great
<tseliot> apw: I'll let you know when the upload is complete
<apw> thanks
<tseliot> apw: finished. It can take a while for it to build though
<apw> yep and to publish, and ... and i need to test without first too to see if this other patch would have found it
<tseliot> ok
<apw> tseliot, this kernel patch is _well_ unhappy with the default mesa
<apw>   111.176361] [drm:i915_gem_object_pin_and_relocate] *ERROR* Relocation beyond target object bounds: obj ffff88010895da80 target 2 delta 153751552 size 16777216.
<apw> [  111.176366] [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22
<apw> [  111.249110] [drm:i915_gem_object_pin_and_relocate] *ERROR* Relocation beyond target object bounds: obj ffff88010895da80 target 2 delta 153751552 size 16777216.
<apw> [  111.249115] [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22
<tseliot> apw: what is it that fails?
<tseliot> oh
<apw> tseliot, producing about 5 on login, thats before any apparent problems
<apw> half my screen is missing too :)
<apw> so _if_ that check is right, its well broken :)  what does the mesa fix change?
<tseliot> apw: it fixes the relocation delta
<tseliot>  	 drm_intel_bo_emit_reloc(brw->wm.surf_bo[unit],
<tseliot>  				 offsetof(struct brw_surface_state, ss1),
<tseliot>  				 region_bo,
<tseliot> -				 surf.ss1.base_addr,
<tseliot> +				 surf.ss1.base_addr - region_bo->offset,
<tseliot>  				 I915_GEM_DOMAIN_RENDER,
<tseliot>  				 I915_GEM_DOMAIN_RENDER);
<tseliot>        }
<apw> oh thats pretty seriously off :)
<tseliot> no wonder you're getting some weird relocation problems
<tseliot> ;)
<superm1> tseliot, would you mind pushing bug 385658 to your x-testing PPA so we can get some testing going on it?
<ubottu> Launchpad bug 385658 in xorg-server "'nv' is selected when no xorg.conf is present even if it doesn't support the nvidia hardware" [Unknown,Confirmed] https://launchpad.net/bugs/385658
<tseliot> superm1: it's on my todo list. I haven't had the time to look at the patch yet
<superm1> ok
<tseliot> it looks like there's a problem in the chroot of the PPA :-/
<apw> tseliot, ?  noooooo i need that .deb :)
<tseliot> apw: do you use i386?
<tseliot> if so, I can upload my packages to my webspace
<apw> amd64 on the box in question
<apw> damn damn damn
<tseliot> :-/
<tseliot> apw: do you want to build the source yourself?
<apw> tseliot, can do
<apw> how painful is it deps wise
<tseliot> https://launchpad.net/~albertomilone/+archive/x-testing/+files/mesa_7.6.0~git20090817.7c422387-0ubuntu4.diff.gz
<apw> you should report that thing too
<tseliot> https://launchpad.net/~albertomilone/+archive/x-testing/+files/mesa_7.6.0~git20090817.7c422387-0ubuntu4.dsc
<tseliot> apw: I've just reported that
<tseliot> https://launchpad.net/~albertomilone/+archive/x-testing/+files/mesa_7.6.0~git20090817.7c422387.orig.tar.gz
<tseliot> apw: don't you use pbuilder?
<apw> tseliot, pbuilder no
<apw> i build so very few packages i've never needed it
<apw> its on my list to investigate 'when i have a moment' and has been for 4 months
<tseliot> apw: that would make things easier for you. This way I can build packages for karmic, jaunty, etc.
<apw> i have the chroots etc, so i can build on the right one etc
<tseliot> apw: to be honest, I use "pbuild" which is a script that makes pbuilder even easier
 * apw adds that tot he list
 * tseliot has a look at superm1 's patch
<apw> tseliot, that didn't build for me
<apw> /usr/include/drm/radeon_cs.h:181: error: 'RADEON_GEM_DOMAIN_VRAM' undeclared (first use in this function)
<tseliot> apw: how did you build it?
<apw> debuild -b in a chroot
<tseliot> apw: did you update your chroot and did you make sure that all the dependencies were satisfied?
<apw> i installed the build deps yeah
 * apw updates it more
<tseliot> weird
 * apw gets grumpy ... this should be easy to test
<apw> tseliot, the range check is looking good
<apw> screen is mush, but very stable
<apw> 10s/r without loss
<tseliot> apw: nice
<apw> its puking every update of course, mesa is a bad boy
<tseliot> yes, I know...
<tseliot> welcome to my world
<apw> as bad as the kernel ... 
<tseliot> heh, right
<apw> and hanging X == the worst of both in the mix
<tseliot> hehe
<tseliot> BTW:
<tseliot> +# Copyright 2007 Red Hat Inc.
<tseliot> +# This crappy script written by Dave Airlie to avoid hassle of adding
<tseliot> +# ids in every place.
<tseliot> LOL
<apw> heh
<apw> tseliot, so what package do i need to install from the output of this build ... i assume not all of it is needed
<albert23> apw: I only updated libgl1-mesa-glx and libgl1-mesa-dri
<apw> cool.  i'll do the same ... once it finishes building yawn!
<tseliot> apw: libgl1-mesa-glx libgl1-mesa-dri libglu1-mesa
<apw> tseliot, is there a any docs on what the various layers actually do
<apw> i assume mesa is the hardware abstraction layer for 3d
<tseliot> apw: also, can you try and see if Option "AccelMethod" "EXA" (in the Device section of xorg.conf) helps with the ATI card?
<jcristau> isn't exa the default?
<apw> i thought so, but hey, its a heap anyway ... can't make it worse
<tseliot> jcristau, apw: the log says that xaa is being used (don't ask me why)
<apw> tseliot, it occurs to me that the symptoms on there included the missing borders and stuff
<apw> ignore that thought
<apw> tseliot, ok chaning that and enablinb compiz looks like its hung completly
<tseliot> apw: as regards mesa, try http://www.mesa3d.org/ and http://dri.freedesktop.org/wiki/
<tseliot> apw: ouch, can you add a comment here, please? http://bugs.freedesktop.org/show_bug.cgi?id=23928
<ubottu> Freedesktop bug 23928 in Driver/Radeon "ATI graphics corruption with compiz" [Normal,New]
<tseliot> superm1: I don't see why that shouldn't work. Did you test it?
<superm1> tseliot, Yup
<superm1> i've got some of this hardware that fails without it
<tseliot> superm1: ok, let me add a comment (basically my +1) in the bug report
<superm1> i'm not really sure more widespread testing is necessary given how straightforward it is, just needed a few pairs of eyes to make sure it looked acceptable (imo)
<tseliot> superm1: caution is never enough. Not that I see why your patch should fail. A bunch of testers should be more than enough.
<tseliot> apw: any luck with the build?
<superm1> Ok, can you push it to a PPA then?
<apw> tseliot, yep just installing and booting it now
<tseliot> apw: great
<tseliot> superm1: would this be ok? https://launchpad.net/~albertomilone/+archive/x-testing
<superm1> sure
<apw> tseliot, ok that mesa update gets rid of the kernel bitching about the reloc
<tseliot> superm1: uploaded. I hope the chroot it's not broken
<tseliot> apw: and can you see the whole screen now?
<apw> yep normal service is also returned for my screen ...
<tseliot> :-)
 * apw does some suspend/resume testing
<apw> 5 s/r's and counting
 * tseliot made the dell mini 10v freeze completely (black screen) without the patches after 6 suspend/resume cycles
 * tseliot is downloading the new kernel for testing
<apw> tseliot, _nice_
<tseliot> heh
<apw> my machine seems pretty stable so far ... obviously only time will tell but 4 s/r's were typically fatal
<tseliot> apw: very well, I'll test the fix here too
<tseliot> superm1: can you upload a package for me, please? (slangasek is ok with this)
<superm1> sure
<tseliot> superm1: http://albertomilone.com/ubuntu/karmic/mesa/toupload.txt Thanks
<superm1> tseliot, you'll have to point me at it though.. :)
<superm1> Ok. cool
<superm1> is that the same one that apw just test built locally? so  i can skip a test build right?
<tseliot> superm1: yes, I only changed a detail in the changelog
<superm1> ok thanks
<apw> tseliot, do we know why the PPA builders are sick on this one?
<superm1> tseliot, i didn't see the -nv on you x-testing ppa yet, you sure you uploaded it?
<tseliot> superm1: yes, I did but the PPA is broken :-/
<superm1> but the source didn't even publish?
<tseliot> apw: I'll bug lamont again
<superm1> must be *very* broken :)
<tseliot> superm1: no, sorry
<superm1> is it just your PPA, or the whole PPA system?
<superm1> i can just pop it on one of mine instead if 'ts just yours
<tseliot> superm1: I hope it's just mine
<apw> tseliot, is it something to do with upstart and mountall and things not installing?
<apw> if so its affecting the whole build system ... someone broke it
<superm1> awesome
<tseliot> apw: The following packages have unmet dependencies:   sysv-rc: Breaks: initscripts (< 2.86.ds1-63) but 2.86.ds1-61ubuntu16 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
<tseliot> d'oh!
<apw> yeha thats the overall mess.  the archive admins are applying hammers to it
<apw> it sounds like something which has been laying in wait for a while, a dep circle which is only hit if you upload both packages at the same time
<apw> tseliot, hows the 10v, how many s/r did it survive?
<tseliot> apw: 6 or 7 without problems
<apw> most unexpected
<apw> now my 945 is fixed i am going to test on here too
<apw> (another 10v)
<tseliot> good :-)
<apw> if i add the kernel only and see the same vomit from Reloc tests i think we could
<apw> call my other bug a dup of the main one
<apw> will do the testing now
<tseliot> :-)
<tseliot> 12 suspend/resume cycles and still no problem whatsoever
<apw> tseliot, yay
<tseliot> apw: ok, I guess that 20 suspend/resume cycles are enough ;)
<tseliot> I should stop before I break the netbook lid :-P
<apw> heh yeah ... you can wake it with the power button
<tseliot> right
<tseliot> apw, superm1: it looks like it will take a while before the PPAs are fixed
<tseliot> just FYI
<superm1> archive is broke too it looks like
<superm1> that mesa upload FTBFS all across the board
<tseliot> :-(
 * tseliot -> dinner
#ubuntu-x 2009-09-16
<lesshaste> hi all
<lesshaste>  hi.. I have a firefox problem where it freezes when uploading files... The strace at http://pastebin.com/f118d9b2e seems to actually imply it's an X server problem as firefox is waiting for something from the server which never arrives. the important part starts at line 1770
<tjaalton> lesshaste: do you have /tmp/.X11-unix/X0 or not?
<lesshaste> ls -lat /tmp/.X11-unix/X0
<lesshaste> srwxrwxrwx 1 root root 0 2009-09-16 08:38 /tmp/.X11-unix/X0
<lesshaste> tjaalton: sorry that was meant for you
<tseliot> tjaalton: did you investigate what pitti reported about vmmouse?
<tjaalton> tseliot: yes, the fix was in git but never uploaded
<tseliot> tjaalton: ah, ok. So we shall wait until the freeze is over
<tjaalton> lesshaste: ok. can't tell why it fails then
<tjaalton> tseliot: yes
<tseliot> ok, thanks
<lesshaste> tjaalton: disabling all extensions fixed it!
<lesshaste> all add-ons I mean
<lesshaste> the problem is either the adblock plus or flashblock it seems
<loic-m> tjaalton: hi
<loic-m> tjaalton: is linuxwacom 0.8.4.1 (stable) definitely off for Karmic?
<tjaalton> loic-m: no, been on my todo-list for a while
<loic-m> tjaalton: ok, thanks. I can't get my tablt configured in Karmic ;)
<loic-m> I had another look at the Debian packaging no I've a bit more experience, and it looks messy
<loic-m> Doesn't that causes troubles when upgrading?
<tjaalton> yes
<tjaalton> upstream is going to fix their release model soonish
<tjaalton> and put the driver in git.fd.o
<tjaalton> that'll be a day to celebrate
<loic-m> Indeed... Did they discuss that on the -devel list?
<tjaalton> only briefly
<tjaalton> but now there seems to be http://cgit.freedesktop.org/~whot/xf86-input-wacom/
<tjaalton> whot is cleaning up the driver
<jcristau> whot is awesome :)
<tjaalton> yeah, he's like all over the place :)
<tseliot> superm1: I uploaded nv to my PPA (I had to sign the source though)
 * tseliot would like to see wacom use xinput
<tjaalton> it's going to
<tseliot> http://cgit.freedesktop.org/~whot/xf86-input-wacom/commit/?id=2e01d5b83ae710c4dccfb5d79c7154c38419b9f3
<tseliot> \o/
<loic-m> Didn't realise whot=Peter Hutterer
<loic-m> yes, sounds awesome
<loic-m> What was the problem with lw release tarballs?
<tjaalton> the are just that, blobs, and no way to cherry pick newer changes
<tjaalton> at least I couldn't make git-svn to work
<loic-m> My difficulty is more that the current packaging isn't transparent - i.e. no doc about what was done for the repack, and inline patches even though there's a patch system
<tjaalton> because the build system is a mess
<tjaalton> ie. the packaging
<loic-m> Makes the netry barrier level a tad high
<tjaalton> that'll get fixed when the upstream packaging is like the rest of the drivers
<loic-m> Is there a good way to learn about drivers packaging?
<tjaalton> existing packages I guess
<jcristau> it's pretty basic autotools, plus some magic to make sure we get the right abi provides and depends
<loic-m> is there differences with applications packaging?
<JontheEchidna> I have a bug I need to report, and was wondering if it should be filed against libdrm or xserver-xorg-video-intel. Basically, DRM fails to load and X is forced to resort to the software rasterizer: http://paste.ubuntu.com/272111/
<JontheEchidna> This happens on an alpha 5 livecd, too
<JontheEchidna> xserver-xorg-video-intel makes performance a bit better, but it still is using the software rasterizer :(
<JontheEchidna> *xserver-xorg-video-intel from xorg-edges
<tjaalton> loic-m: got a driver for you to test..
<loic-m> tjaalton: thanks
<tjaalton> 32 or 64bit?
<loic-m> 32 please
<tjaalton> loic-m: http://users.tkk.fi/~tjaalton/foo/xserver-xorg-input-wacom_0.8.4.1-0ubuntu1_i386.deb
<loic-m> tjaalton: no need to test wacom-tools too?
<tjaalton> http://users.tkk.fi/~tjaalton/foo/wacom-tools_0.8.4.1-0ubuntu1_i386.deb
<loic-m> tjaalton: thanks
<loic-m> bbl
<loic-m> tjaalton: your 0.8.4.1 wacom packages work well with my Intuos3 6x8. Input-hotplug, pressure in Gimp, and setting the properties with xsetwacom for the pad
<loic-m> Inkscape draws completely off base, but that's AFAIK a known bug, also in Jaunty
<loic-m> The provided .fdi still doesn't work with wacomcpl, but that was the same in Jaunty too
<loic-m> The Cintiq is another story, will probably take longer to set up till I can really say I tested it, because of the dualscreen configuration
<tjaalton> loic-m: ok, nice to hear
<loic-m> indeed ;)
<tjaalton> could you reply to bug 405800, it would help getting it ack'ed
<ubottu> Launchpad bug 405800 in wacom-tools "Please update wacom to 0.8.4-1 version" [Wishlist,Confirmed] https://launchpad.net/bugs/405800
<loic-m> Sorry, was away. I'll do that right now
<tjaalton> thanks
<loic-m> Done,  tell me if you need anything else.
<Ng> so with gnome screensaver not quite working on suspend atm, I'm reminded just how beautifully fast X gets video back up after resume :)
<Ng> the wrinkle being that input devices
<Ng>  take several seconds. I seem to remember someone saying that fedora had some kind of patch for that
<Ng> (also from a simple usability/polish point of view I wonder if the fadeout of gnome-screensaver should happen *way* faster so suspend happens almost as fast as it's happening atm
<Ng> afaict the fade is about 1s long atm, which subjectively seems like the longest part of the suspend process ;)
<jcristau> heh, the suspend process starts when i close the lid, and finishes right about when the laptop is in its bag :)
<cdE|Woozy> does the suspend process really wait for gnome-screensaver to finish fading out?
<Ng> cdE|Woozy: I was poking at the gnome-session source earlier and it seems that when it wants to blan kthe screen it shells out to gnome-screensaver-command, which afaict doesn't return until the activate/lock has finished fading
<Ng> (see "time gnome-screensaver-command --activate")
<Ng> I kinda assumed it would be dbus magic, and I can well understand that you wouldn't want the actual suspend to happen mid-fade
#ubuntu-x 2009-09-17
<Duke`> wow, I got a serious speed improvement after upgrading this morning
<Duke`> I hope nothing is broken after those optimisations
<virtuald> what package should kms bugs be reported against?
<tjaalton> the kernel
<tjaalton> = "linux"
<virtuald> ok but then do apport include Xorg logs?
<tjaalton> probably not
<tjaalton> you can file it against the driver too
<tjaalton> it'll get reassigned to the kernel if it turns out to be a kernel bug
<virtuald> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/388467 how do i use this?
<ubottu> Launchpad bug 388467 in xorg "apport script to collect information about a gpu hang" [Wishlist,Triaged]
<tjaalton> dunno
<apw> virtuald, i think you can file it against the kernel and then add X stuff using apport-collect
<virtuald> ok
<virtuald> yes, thank you
<apw> virtuald, whats the kms bug you are seeing ...
<apw> i am not sure i'd know a bug was kms related
<virtuald> i haven't posted it
<virtuald> on rv570 when x gdm starts the screens turn off
<virtuald> then they turn on and off with about a minute in between
<virtuald> but it's just black
<virtuald> once there were some garbled lines before they turned off
<tormod> tjaalton: can you have a look at bug 429700?
<ubottu> Launchpad bug 429700 in xserver-xorg-video-savage "please merge xserver-xorg-video-savage 2.3.0-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/429700
<tjaalton> tormod: sure, my mistake
<tormod> thanks
<virtuald> Ok so now I'm on my mobile and can login to my gpu hung computer from here
<virtuald> But I forgot to check on the Wiki what to en
<virtuald> What to do
<tseliot> tjaalton: where did you upload the packages mentioned in bug #405800?
<ubottu> Launchpad bug 405800 in wacom-tools "Please update wacom to 0.8.4-1 version" [Wishlist,Confirmed] https://launchpad.net/bugs/405800
<tjaalton> tseliot: nowhere yet
<tseliot> tjaalton: ok, please let me know if you do it. I have a tablet for testing.
<tjaalton> just uploaded it to my ppa
<tseliot> ok, thanks
<tseliot> tjaalton: my tablet works, xinput mentions it but "xsetwacom list" doesn't return anything
<loic-m_> tseliot: I think that's expected with 0.8.4.1
<tseliot> loic-m_: is it a feature? :-P
<tseliot> AFAIK it's not possible to make the tablet work decently with xinerama without xsetwacom
<loic-m_> tseliot: not that I can think of... xsetwacom still work for sending commands, but the list doesn't show any thing anymore (can't find the thread) since one of the 0.8.3 versions at least
<loic-m_> tseliot: you should try sending a command and see if it works, the "list" doesn't give much (not sure if it's due to new versions of the driver or new Xorg versions)
<tseliot> I'm downloading the source code so as to see what the "list" option does
<tseliot> ListDev() must be failing for some reason
<loic-m_> From my testing of the previous drivers in Karmic, xsetwacom list didn't show anything either, I had to use xinput list --short
<loic-m_> I don't remember for Jaunty, might reboot into it tonight
<tseliot> loic-m_: ok, it's important to know that this isn't caused by a regression in the driver
<tseliot> in the new driver, I mean
<loic-m_> tseliot: you should still test it yourself with 0.8.3 from the repositories, but at least for Intuos3 tablets I tested it didn't work, and some forums threads mentionned it didn't work since 0.8.3 (they're 30 pages long, so hard to remember where it was)
<loic-m_> Ill reboot into Jaunty, bbl
<loic-m> tseliot: xsetwacom list doesn't work either in Jaunty, just checked, so it could be due to Xorg 1.6
<tseliot> loic-m: I'm getting a lot of segfaults from xsetwacom when I try to use the TVResolution0 and TVResolution1 options
<tseliot> or the Twinview option
<tjaalton> might be fun to try 0.9 how the input properties work
<loic-m> I got segfaults with Twinview and 0.8.3.2 in Karmic, never tried the TVResolution# options
<loic-m> however, upstream changelog said it fixed a/some bug(s) with Twinview, it's a shame if it still doesn't work
<tseliot> tjaalton: can they work worse then the current xsetwacom? Will they format my hard disk? :-P
<tjaalton> tseliot: care to find out?-)
<loic-m> Nope, I was wrong, it was about Nvidia non-TwinView setting :(
<tseliot> tjaalton: maybe wacom-tools should be updated?
<loic-m> what's 0.9?
<tseliot> tjaalton: actually, I take back what I said
<tseliot> loic-m: the next release. whot is working on it
<tjaalton> loic-m: the one whot and ping are working on
<tseliot> unless I'm wrong
<tseliot> ok, I'm not ;)
<loic-m> great. Ping say he's going to be busy the next 6 month, I didn't expect next release to be around soon
<tjaalton> I'll try this new version with my waltop after the reboot
<loic-m> btw, Timo, Upstream just released 0.8.4.2 ;)  - I'm sure you wished you waited one more day...
<tjaalton> uh
<tjaalton> what changed?
<tseliot> \o/
<jcristau> "September 16, 2009 - Fixed a mapping issue introduced by non-TwinView support. Label 0.8.4-2. "
<loic-m> just a bugfix of a feature that wasn't there pre-0.8.4.2 then
<tseliot> ok, this might be interesting
<tseliot> it looks more like a regression introduced by the new feature
 * tseliot restarts X
<tjaalton> still crashes the server when trying to use the crappy waltop
<tjaalton> "127f is not supported by linuxwacom"
<tjaalton> what a way to tell that
<tjaalton> if (sID[1] == 0x056A) { ... } else { ErrorF("%x is not supported by linuxwacom.\n", sID[1]);
<tjaalton> great
<tseliot> hehe
<tjaalton> 056A is the vendor id of wacom
<tjaalton> seems like the device was previously detected as a serial tablet
<tseliot> so they dropped the support for your tablet?
<tjaalton> the code path used to be different for some reason, now it actually knows it is a usb device, and fails because the vendor id doesn't match
<tseliot> you could try with if ((sID[1] == 0x056A) || (sID[1] == 0x127f)) {...} etc. just to see whether your tablet is supported or not
<tjaalton> yep, trying that now
 * tjaalton wants an intuos4 L..
<tseliot> heh
<loic-m> tjaalton: intuos3 should be cheap now secondhand, and the support should also be better...
<loic-m> and for wacom tablets, second hand  = new
<loic-m> and you can resell i afterwards (try that with a Waltop...)
<loic-m> s/i/it/
<tjaalton> but intuos4 looks good :)
<tjaalton> this was meant to be a toy for the kids
<tjaalton> at least it doesn't crash now, but there's still the same error msg
<tseliot> tjaalton: maybe there's some other check you haven't noticed
<loic-m> intuos4 sure would be nice, since they reduced the pressure need for registering contact with the tablet, one of my main gripe with Tablets
<tjaalton> tseliot: nah, was looking at the wrong logfile..
<tseliot> aaah, ok
<tjaalton> it sets up the device, but nothing happens when I try to use it
<tseliot> so they did drop the support for your tablet
<tseliot> :-/
<tjaalton> when the driver detected it as a serial device, it worked
<tjaalton> doesn't look like the driver changed
<pwnguin> im not sure why they ever added support for waltop
<tjaalton> who they?
<tjaalton> I don't think wacom added anything, it just used to work
<tjaalton> out of sheer luck
<jcristau> luck is good.
<jcristau> :)
<tjaalton> if it's not bad
<tjaalton> well, evdev works somewhat, but it's detected as a keyboard
<pwnguin> right now my tabletPC is angry about a filesystem from the future
<tjaalton> should be fixed by the latest kernel
#ubuntu-x 2009-09-18
<tseliot> jbarnes: any ideas on what's happening here? (bug #431812)
<ubottu> Launchpad bug 431812 in sysvinit "fbcon loading a mystery (screen powers off)" [High,Confirmed] https://launchpad.net/bugs/431812
<tseliot> AFAIK fbcon is loaded when checking for KMS in the -intel driver
<mac_v> tseliot: Bug 397839 is not fixed even after applying the fixes Richard mentions in his blog... :(  any ideas?
<ubottu> Launchpad bug 397839 in xorg-server "Screen randomly goes off in karmic" [Critical,Fix released] https://launchpad.net/bugs/397839
<mac_v> this is in an ATI X1400
<tseliot> let me check
<mac_v> see my last comment... gpm does not give any output , and i'm not sure how to debug it! :(
<mac_v> it seems to happen much rare than it used to , but still is a problem and the notification area keeps displaying the session is active icon
<tseliot> mac_v: it might be worth notifying hughsie about the problem
<mac_v> in the blog? ... yeah, i was thinking about it , but wanted to add a comment after i had some debug info
<tseliot> mac_v: or on irc.gnome.org (in #gnome-hackers)
<mac_v> hmm... ok , so if i mention the lp bug , they would have a look? [just asking , since i'm not sure how upstream irc guys ask for stuff ] ;)
<tseliot> mac_v: yes, if the report contains information which can help upstream
<tseliot> (in general)
<mac_v> ah ok , thanks
<jbarnes> tseliot: yeah sounds like you need to load i915 and fbcon in your initrd instead
<tseliot> jbarnes: ah, right, let me try
<tseliot> jbarnes: I added i915 and fbcon to initramfs, rebuilt the initrd but I can still reproduce the problem
<jbarnes> what kernel commit are you at?
<tseliot> apw: ^^
<tseliot> jbarnes: in the meantime I have noticed that I get a few errors when fbcon and i915 are in the initramfs: http://paste.ubuntu.com/273572
<jbarnes> tseliot: yeah that looks like a pretty broken config... X isn't even detecting drm
<jbarnes> loading those modules early shouldn't cause that though
<tseliot> jbarnes: but this means that the device wasn't even created (in time?) [drm] Failed to open DRM device for : No such file or directory
<jbarnes> yeah something bad happened
<jbarnes> if /dev/dri doesn't exist that would explain it
<tseliot> 3d acceleration was broken
<tseliot> so it could be
<tseliot> let me check
<tseliot> jbarnes: /dev/dri doesn't exist
<tseliot> jbarnes: also, if I pass i915.modeset=1 grub complains that it's an unknown option
<tseliot> i915.modeset:1 that is
<jbarnes> sounds like some funkiness with your initrd
<jbarnes> udev will create the nodes after drm/i915 load
<jbarnes> or it should
<jbarnes> so either i915 isn't loading or udev is failing somehow
<albert23> tseliot: shouldn't drm be in initrd as well? i915 depends on it.
<tseliot> albert23: I tried putting the dependencies in the initrd too
<tseliot> loading only fbcon in the initrd seems to give me KMS back :-)
<jcristau> the 'unknown option i915.modeset' is expected, when i915 isn't builtin
<Q-FUNK> would anyone have any idea of what could cause bug #429277 ? I would have tought that this is a gnome-settings-daemon issue again, but seb128 claims that this was fixed already.
<ubottu> Launchpad bug 429277 in xserver-xorg-input-mouse "left-handed mouse no longer working" [Undecided,Invalid] https://launchpad.net/bugs/429277
<jcristau> so you filed a bug against a driver that you're not using instead.  nice.
<Q-FUNK> excuse-me?
<jcristau> you're not using xserver-xorg-input-mouse
<Q-FUNK> ah?
<jcristau> â¦
<Q-FUNK> so what driver does a mouse use these days?  
<Q-FUNK> is -mouse used at all, even?
<Q-FUNK> or does it all goe through that new unified input device driver?
<albert23> Q-FUNK: -evdev is normally used
<Q-FUNK> albert23: interesting.  so why is -mouse still shipped then? does it still have some limitted usage cases?
<albert23> Q-FUNK: I think -vmmouse still needs -mouse
<Q-FUNK> sorry if I'm not up-to-date on general X server issues, in this case, on the input modules.
#ubuntu-x 2009-09-20
<bbeck> I was wondering if MPX was included in the xserve of Karmic?
<virtuald> do you know about unresolved symbol in radeon_drv?
<tormod> virtuald, which symbol?
<virtuald> i don't remember it didn't get logged. let me reboot to kms and see
<virtuald> time for fsck...
<virtuald> I Just had to mirkk some
<virtuald> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/431856
<ubottu> Launchpad bug 431856 in linux "rv570 KMS: screens turn off when X starts" [Undecided,New]
<virtuald> hmm my comment disappeared :p
<virtuald> now it's there
<tormod> virtuald, the missing symbol means you have not updated libdrm
<virtuald> i should have all the latest packages and fully purged ppas but i'll check
<virtuald> yup i have the latest libdrm2 libdrm-radeon1 and libdrm-intel1 from main
<virtuald> installing dbg packages
<tormod> 2.4.13-1ubuntu1 ?
<virtuald> yes
<tormod> oh I wonder if the -ati package has been rebuilt since the new libdrm came
<virtuald> <:
<tormod> virtuald, try https://edge.launchpad.net/~xorg-edgers/+archive/drivers-only
<virtuald> should i try rebuilding xserver-xorg-video-ati?
<tormod> no just ^
<virtuald> xserver-xorg-video-ati: Installerad: 1:6.12.99+git20090825.fc74e119-0ubuntu1
<tormod> well actually would be interesting to just rebuild the stock version, also
<virtuald> ok
<virtuald> hmm just click to install or add the ppa?
<virtuald> might not work as the packages probably depend on each other
<tormod> you only need -ati/-radeon pkgs
<tormod> they do _not_ depend on eachother, that's the whole point of the drivers-only ppa :)
<virtuald> gdebi can't handle it anyway
<virtuald> sudo dpkg -i /tmp/*deb worked of course
<virtuald> lets reboot
<tormod> gdebi can't install 2 pkgs at the same time
<tormod> enough to log out and in
<virtuald> You think those messages ended up in logs? Yeah I'm probably blind :)
<virtuald> It worked! I have KMS again.
<virtuald> Btw the new xsplash looks awful on dual screen
<virtuald> Heh seems whenever  I go back and forth between KMS and non-KMS my panels move to the other (right) screen
<virtuald> somewhat annoying
<virtuald> just so you know my computer didn't boot that fast I cheated with my phone
<tormod> xsplash just looks awful
<tormod> so no more missing symbols?
<hyperair> what's wrong with xsplash?
<virtuald> don't think so, checking logs
<hyperair> oh dual screen.
<virtuald> i don't like the placement of the logo
<virtuald> and it looks too zoomed in
<virtuald> might be related to the screen being different sizes
<tormod> xsplash uses scary colours and the (mis)rhythm of the pulsating thing makes me nervous
<virtuald> is there a pulsating thing now?
<virtuald> no more missing symbols
<tormod> virtuald, it has this thing almost like an old electricity meter
<virtuald> but my syslog is almost 40MB
<virtuald> mostly it's pulseaudio and rtkit complaining
<tormod> virtuald, that's bad. mine is 1MB
<virtuald> like a spinning disc wit a red marker?
<tormod> virtuald, except it's all b/w
<virtuald> i'll look harder next time
<virtuald> is it close to the centre?
<tormod> yes
<virtuald> tormod: will you make sure that the packages are rebuilt or should i do something?
<tormod> we need some on to upload a no-change rebuild
<tormod> someone even
<virtuald> yeah it doesn't need to be a FFe? as it's not a feature
<tormod> I believe the -ati driver has a standing FFe
<tormod> I would have uploaded a newer snapshot of course :)
<tormod> but you are right, a bugfix does not need a FFe
<tormod> I already commented on this in a bug report...
<tormod> virtuald, I reopened bug 410058 and attached a debdiff
<ubottu> Launchpad bug 410058 in xserver-xorg-video-ati "Black screen with radeon KMS" [High,Fix committed] https://launchpad.net/bugs/410058
<virtuald> nice
#ubuntu-x 2010-09-20
<strycore> Yo gentlemen
<strycore> is it just me or the latest xorg update in Maverick has brought total chaos to mouse input in many full screen games ?
<strycore> I've got 2 examples right now, but i'm sure i could find many more
<strycore> Quake running with DarkPlaces SDL, the mouse behaves as if there was a 'lookspring' option activated , DarkPlaces GLX behaves normally
<strycore> Half-Life  1 in Wine, i can't look down with the mouse as if the mouse was on an infinite upward motion, with virtual desktop activated everything is ok  
<strycore> so what's wrong with Xinput ?
<nigelb> 45
<ScottK> Sarvatt: kwin is now blacklisting swrast successfully.  Thanks for the feedback.
<coafcv> How can I figure out which driver my graphic card is using? I've installed like a dozen different drivers, none really worked well, and after I gave up hope, it suddenly works, perfectly and even better than before, but I have no idea which driver I have right now. How can I figure this out?
<coafcv> (I'm using an ATI HD 4850)
<bryceh> it says in your Xorg.0.log
<coafcv> bryceh: ok, but which part? the file is pretty big and it lists a lot of different files.
<bryceh> coafcv, about 4/5ths of the lines in the file say it
<coafcv> hmm... there's RADEON in front of some lines. is this the driver name?
<bryceh> yes
<coafcv> oh ok. and which is it? the one ubuntu ships via administration => hardware drivers, or the one you download from ATI?
<coafcv> I'm not really sure what RADEON means here...
<JanC> RADEON is the open source driver
<coafcv> JanC: so it's neither the official ATI one, nor the one in admin => hardware drivers? 
<JanC> the one in hardware drivers is the official AMD/ATI one
<coafcv> oh
<JanC> not sure about the 4850, but my 4350 isn't supported by the official driver anymore
<JanC> in that case you get the open source one...
<coafcv> do you have any idea how the open source RADEON driver could have gotten installed if I only have explicitly installed the official ATI drivers?
<JanC> they are part of Xorg, so installed by default
<coafcv> it's a big mystery to me, since in Ubuntu versions < 10.04.1 I had to install official ATI drivers to get 3D effects, but no it works just fine with RADEON.
<coafcv> and even better. 
<JanC> âº
<JanC> before 10.04 the radeon driver didn't have 3D support for Radeon HD 4xxx
<JanC> but now that the open source drivers are getting better, I think AMD doesn't want to keep them in their closed source driver
<coafcv> oh :-) well, I should have known that before. After I freshly installed 10.04 a few days ago, I immediately activated the official ATI drivers not knowing that radeon would suffice. the ATI drivers crashes my system regularly. 
<coafcv> I could watch movies for like a few minutes, and then it just froze. very frustrating.
<JanC> coafcv: AMD has been providing specifications for their hardware, and AFAIK they also have a couple of developers working on the open source drivers now
<coafcv> that's good news. finally AMD got a clue.
<JanC> they have been doing that for a couple of years actually ;)
<coafcv> oh, heh
<coafcv> one question though: after Kernel updates on old Ubuntu versions, I had to regularly re-install the official ATI drivers. Somehow advancing to a newer kernel messed up the ATI drivers. is the same bound to happen with radeon or can I safely switch to newer kernels without having to recompile/reinstall?
<JanC> the kernel part of the drivers has to be re-compiled for every kernel version, but of course the open source drivers are part of the official kernel  âº
<JanC> open source drivers makes things a lot easier  âº
<coafcv> ah, but Ubuntu makes this automatically and it just works (TM)?
<JanC> for the open source driver, it's automatic in every kernel, for the ATI closed source driver the Ubuntu kernel developers do the work for you, if you compile your own drivers you have to do it yourself every time
<JanC> and as your card is probably not supported anymore by the official AMD/ATI drivers, no point in installing them anymore
<coafcv> I see :) will the open source drivers support my card "forever"?
<JanC> forever is a very long time  ;)
<coafcv> that's why it's in quotes. :p
<coafcv> I mean, for the duration 10.04.1 is supported
<coafcv> so, until April 2013.
<bryceh> coafcv, there are no plans to drop support for any hardware
<bryceh> for the open source radeon driver
<JanC> http://www.x.org/wiki/radeon says "Driver for ATI/AMD Radeon based video chips, everything from Radeon 7000 to Radeon HD 5890 series."
<bryceh> indeed, it still includes support for R100 cards, which are pretty ancient
<JanC> and that Radeon 7000 is pretty old  ;)
<coafcv> ok good :)
<bryceh> pretty much all the stuff you had to hassle with fglrx you no longer need to worry about
<coafcv> :)
<coafcv> many, many thanks for all the info and support.
<bryceh> you can basically forget about X and go about your business now (unless you want to help make X better *grin*)
<coafcv> :)
<bryceh> I'm really happy with the radeon driver, it tends to be quite robust and well developed and rarely seems to have regressions
<bryceh> <knock on wood>
<JanC> yeah, has been running very well on my HD 4350 since Lucid
<coafcv> btw, does X also handle printers or is this a different realm? because ubuntu detects my printer, tries to install a plug-in for it, says the installation failed, but the printer works. thing is, the "do you want to install the plug-in"-window pops up at every restart and it bothers me a bit.
<JanC> printers is CUPS
<coafcv> oh ok
<coafcv> going to restart, thanks again.
<bjsnider> Sarvatt, are we getting the newest blob into the x-updates ppa or what's the deal?
#ubuntu-x 2010-09-21
<bryceh> bjsnider, why is there doubt?
<bjsnider> it's been a few days. i think he missed it. i certainly did
<bjsnider> they released it very quietly
<bjsnider> but it fixes a bug that is very relevant to maverick
<bryceh> I'd guess it's just a matter of release stuff taking priority for his time
<bryceh> bjsnider, if you're interested in helping move things forward, you could volunteer to help get it packaged up and tested
<bjsnider> just give me the upload rights and i'll put it in there myself
<bryceh> lemme check if I'm an admin...
<bryceh> nope
<bryceh> but, just click the button to join this team, and sarvatt or tormod will hook you up:  https://edge.launchpad.net/~xorg-edgers/
<bryceh> bjsnider, thanks ahead of time
<bjsnider> done
<Sarvatt> x-updates is ubuntu-x-swat
<Sarvatt> didn't know they released a driver
<bjsnider> they released it middle of last week
<bjsnider> i completely missed it. phoronix didn't have it
<bjsnider> http://www.nvnews.net/vbulletin/showthread.php?t=155137
<bjsnider> ftp://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-260.19.06.tar.bz2
<Sarvatt> i'm not an admin of ubuntu-x-swat to accept ya :D
<bjsnider> ok but can you get it in there?
<bjsnider> this bug is highly annoying
<bryceh> oh x-updates, for some reason I read that as xorg-edgers
<bryceh> bjsnider, sorry, click to join https://edge.launchpad.net/~ubuntu-x-swat
<bryceh> bjsnider, actually I can add you directly
<Sarvatt> its uploading now
<bjsnider> coolio
<Sarvatt> could ya get nvidia-settings? or i'll get it tomorrow, house is about to start :)
<bjsnider> yeah i'll do it
<bjsnider> Sarvatt, are there any differences between the maverick and lucid nvidia-settings build scripts?
<Sarvatt> nope
<bjsnider> that makes it easy
<ScottK> RAOF or Sarvatt: Are you planning on doing the mesa revert after RC?
<popey> Is someone able to tell what part of the xorg-edgers intel driver fixes bug 619663 ? at the moment the intel driver is broken for dual screen side-by-side on 10.10. 
<ubot4> Launchpad bug 619663 in xserver-xorg-video-intel (Ubuntu) "[maverick] Non-mirrored dual-screen gives narrow display on secondary monitor (affects: 5) (dups: 1) (heat: 28)" [Undecided,Confirmed] https://launchpad.net/bugs/619663
<popey> and thus if it's possible to get that patch into 10.10
<bjsnider> mvo, the latest build of xserver-xorg-dev in maverick does not contain the important file /usr/share/xserver-xorg/serverminver
<jcristau> what still uses that?
<bjsnider> nvidia-current
<jcristau> boo.
<bjsnider> probably the other proprietary drivers also
<tseliot> bjsnider: no, it doesn't
<tseliot> nvidia-current doesn't use that any more
<bjsnider> oh, because i was just looking at the rules file and it does here. have you got newer build scripts?
<bjsnider> ah yes i see
<tseliot> bjsnider: the one in maverick doesn't use it
<bjsnider> tseliot, what do you think about getting rid of the nvidia-current-dev package now that there are no more headers to install? the only file left in that package is libXvMCNVIDIA.a
<tseliot> bjsnider: that's not a change that I will make in Maverick. In Natty we'll have separate packages and hopefully nvidia-current-dev can either be dropped or become an empty package that depends on opencl, etc.
<bjsnider> that would be a good idea
<mvo> bjsnider: thanks, I just touched the package to fix some upgrade issues, I don't know that much about the internals myself (but it looks you found the right people already :)
<Sarvatt> mvo: would you be willing to sponsor a new compiz upload? we've got a problem where I added the sandybridge bridge devices to the previous upload and it's preventing machines not using the intel GPU from using compiz too. darn preproduction machines with no info on them outside of the source :( https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/644372
<ubot4> Launchpad bug 644372 in compiz (Ubuntu) "Compiz Sandybridge blacklisting preventing discreet GPU machines from using it (affects: 1) (heat: 6)" [Undecided,In progress]
<mvo> Sarvatt: sure, I can sponsor one, let me look
<Sarvatt> mvo: thanks a ton for taking a look at it! I have verified it doesn't regress any of my sandybridge machines with 0100 bridge 0102 GPU pci ids, the id's were obtained from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=53767cc0d0a58d36cd445da3a31c65b349eebbba
 * ScottK mumbles to Sarvatt about mesa uploads too.
<Sarvatt> ScottK: want me to prepare a mesa with the revert? I thought RAOF had it under control but haven't spoken to him in a while, we keep duplicating work on mesa and screwing each other up in git
<ScottK> Sarvatt: I'm not qualified to say for sure, but I'd think it's better in now than after RC.
<mvo> Sarvatt: thanks, what about 0x126? it seems to got removed from the intel_driver.h but its still in the blacklist. is that pre-production or something?
<mvo> Sarvatt: just curious, it seems to be a graphics controller, so not really relevant for the bug in question
<Sarvatt> mvo: 0126 is a valid device, its just not lined up so looks like its gone on first glance, they had that added previously
<Sarvatt> +#define PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS	0x0126
<mvo> aha, ok
<mvo> sorry, see it now as well (what a little indent can do ;)
<Sarvatt> yeah when you said that I didn't see it either at first :D
<mvo> Sarvatt: thanks, diff looks fine, commited to bzr and uploaded
<Sarvatt> thanks mvo!
<bjsnider> Sarvatt, the nvidia-current build for mav failed last night because of the serverminver thing. that's going to be another difference between the lucid and mav build scripts, but i think it's ok to use that aspect of the mav scripts on lucid
<Sarvatt> bjsnider: yeah I tried to upload the fix when I woke up but you already got it :)
<Sarvatt> was my silly mistake forgetting to fix it, was rushing to upload it before house started :)
<bjsnider> it looks like it's going to take several days to finish building at this rate
<mvo> yw Sarvatt
<Sarvatt> mesa is so bad off on sandybridge :(
<Sarvatt> bjsnider: btw what did you change? here's the full list of changes needed - http://sarvatt.com/downloads/nvidia-maverick.patch
<bjsnider> i matched the rues file with the upstream version
<bjsnider> yep, it matches that patch
<bjsnider> i did it the old fashioned copy and paste way
<bjsnider> but i think those changes would work on lucid because the file being tested exists
<Sarvatt> normally I just start with the maverick and apply http://sarvatt.com/downloads/patches/nvidia-graphics-drivers-lucid-backport.patch but I was a bonehead last night :)
<Sarvatt> and reused the previous lucid packaging
<Sarvatt> hmm
<Sarvatt> mesa (7.9~git20100909-0ubuntu3) maverick; urgency=low
<Sarvatt>   * Drop the changes from previous upload.  The Unity white screen problem
<Sarvatt>     is clutter bug #632352, fixed in clutter-1.0 1.2.12-0ubuntu12.
<Sarvatt>  -- Christopher James Halse Rogers <raof@ubuntu.com>  Thu, 16 Sep 2010 16:04:28 +0200
<ubot4> Launchpad bug 632352 in clutter-1.0 (Ubuntu) "Clutter fails to update with Mesa 7.9 (affects: 1) (heat: 8)" [Critical,Fix released] https://launchpad.net/bugs/632352
<Sarvatt> ScottK: yeah looks like RAOF already packaged and test built everything but hasn't gotten them sponsored yet - http://cooperteam.net/Packages/
<ScottK> What are the odds of him appearing and saying "Yes, I want that in for the RC"?
<Sarvatt> pretty much 100% he'll say that around 7PM EST when he wakes up, he should be back from the conference now :)
<ScottK> It'll be too late by then.
<ScottK> I'll take it.
<ScottK> Sarvatt and RAOF: Mesa uploaded.  I guess I get to do the odd numbered ones.
<Sarvatt> hah! thanks ScottK, sorry we dropped the ball on that one, it should have gone in a week ago
<Sarvatt> fun, another cyclic dependency added to mesa besides X, wine-dev for the d3d1x state tracker now :)
<bjsnider> to install that state tracker, you need wine-dev?
<bjsnider> is that because they built it with wine's directx code?
<patrickdickey> Hello there.  I'm curious about whether my ATI Graphics Card is supported under the fglrx package. It's an ATI Radeon Express 200M (RC410).
<patrickdickey> Here's the exact description from lspci -v "GA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]"
<bryceh> patrickdickey, no ATI dropped support for your hw from fglrx
<bryceh> patrickdickey, uninstall fglrx and use -ati instead, it should work fine
<patrickdickey> I don't think I have fgrlx installed.  I've got the default drivers that come with xorg (Kubuntu 10.04).
<patrickdickey> xserver-xorg-video-ati <- This is the driver I should use?
<patrickdickey> Thanks. I'm going to try that one out. Hopefully everything works out.  Have a great day:)
<JanC> "try that one out" ?
#ubuntu-x 2010-09-22
<RAOF> Sarvatt: 7PM EST?  No chance. :)
<ulysses> morning
<ulysses> Maverick freezes after login with latest drm/mesa, anyone noticed? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/644740
<ubot4> Launchpad bug 644740 in xserver-xorg-video-intel (Ubuntu) "[i915] drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung (affects: 1) (heat: 8)" [Undecided,New]
<RAOF> Hm, fun.
<RAOF> Oh, I see you've got the same GPU as I do.
<RAOF> And I don't see that crash.
<ulysses> I have KDE 4.5.1, the crash appears only when I enable desktop effects
<RAOF> Sarvatt: I got up at 11am today (which I had organised to take off, because I *knew* I'd be totally worthless at work)
<RAOF> ulysses: Since I don't see that problem, could you try disabling individual effects and seeing which one kills it for you?
<Sarvatt> ahh sorry RAOF, I was just guessing you got home sunday and had time to recover already and had no idea
<ulysses> I'll try later, now I have to go
<RAOF> Sarvatt: I _left_ Sunday :0
<RAOF> I *arrived* Tuesday, late afternoon.
<RAOF> No need to apologise!
<RAOF> Now to go congratulate/commiserate with my brother after his driving test!
<bryceh> heya raof
<RAOF> bryceh: Howdie!
<RAOF> Alex said hi :)
<bryceh> cool
<bryceh> RAOF, anything noteworthy happen?
<RAOF> There was a particularly interesting discussion of unpriviledged X.
<RAOF> Keith wants to make X unpriviledged in a particularly strong sense of the word.
<bryceh> for meego?
<RAOF> As in âno part of X is trustedâ.
<RAOF> No; meego doesn't have multiple users, so the trust issues aren't there.
<RAOF> IE: the basic reason why you can't just strip off the setuid bit of X right now is (a) ums drivers, and (b) input arbitration.
<RAOF> As you, of course, know :)
<bryceh> yep
<RAOF> Meego doesn't care about input arbitration.
<RAOF> So it's a bit easier.
<RAOF> Keith wants X out of *all* trusted paths, and hence out of the input arbitration business.
<RAOF> So one (or more) X server per user, with the kernel+ConsoleKit handling input arbitration.
 * bryceh nods
<RAOF> By changing input devices from broadcast to one-fd-gets-it (like current serial devices)
<RAOF> + a syscall for ConsoleKit to tell the kernel which fd should get input.
<bryceh> speaking of ums, any word regarding 8xx?
<RAOF> No one cares about it :/
<bryceh> hrm
<RAOF> Chris' shadow, that's now merged to trunk, looks like it'll provide a stable and somewhat featureful intel driver for i8xx.
<RAOF> At the cost of 3D, of course :(
<RAOF> I mean, fundamentally some of the hardware is broken, and old enough that there are more productive uses of time.
<bryceh> I found a community guy with hw experience that might work on it
<RAOF> On the X mailing list?  Yeah, that'd be great to have i830 better supported.
<bryceh> ubuntu-x@ yeah
<bryceh> I have a feeling this is one of those things that people don't volunteer to help with because they assume "someone else will do it"
<RAOF> There's of course that other bug where there's no kernel driver for the interface thingy on some i810 cards, too.
<bryceh> so it may be the best thing we can do to help it would be to declare it unsupported in ubuntu, and that no further developer time from canonical will go into it
<RAOF> bryceh: Yeah.  It requires an unusual conjunction of willingness to get one's hands dirty, hardware, and some driver confidence.
 * bryceh nods
<tseliot> RAOF, Sarvatt: shall I use bug 630599 as a reference for fglrx's incompatibility with maverick's xserver or do you have a better bug report?
<ubot4> Launchpad bug 630599 in fglrx-installer (Ubuntu) "Upgrade to 10.10 fails to load xorg (affects: 6) (dups: 5) (heat: 264)" [Undecided,New] https://launchpad.net/bugs/630599
<RAOF> tseliot: That seems like a perfectly cromulent bug report o have as a reference.  I'd probably add the reason to the description, though.
<jcristau> hi RAOF 
<RAOF> Hey there jcristau 
<RAOF> jcristau: I trust your journey back was substantially less epic than mine? :)
<jcristau> it was very much un-epic
<jcristau> so, probably :)
<tseliot> RAOF: yes, good point
<patrickdickey> I came in yesterday afternoon asking about the proper driver for an ATI Graphics Card (RC410 Radeon Xpress 200M). I've got another question.  It seems that my xorg.conf is uisng the "radeon" driver. Is that the correct driver (I was told to install the -ati package), or should it be "ati" in xorg.conf?
<patrickdickey> Ultimately I'm trying to eliminate a really annoying screen flicker on my external monitor, whenver I open things like a virtual machine in VMWare Player, or Rosetta Stone (through Wine).
<Sarvatt> patrickdickey: that is the default driver, you dont need an xorg.conf for it. that problem should be fixed if you boot with radeon.new_pll=0 added to your kernel command line
<Sarvatt> you can hold shift while booting, select the kernel and press e to edit it, then where it says quiet splash, add radeon.new_pll=0 to the end of that line
<Sarvatt> if that works you can edit /etc/default/grub and add it to the GRUB_CMDLINE_LINUX_DEFAULT= line, like GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.new_pll=0", save it, sudo update-grub and reboot
<patrickdickey> Wow, you must have been reading my mind. I was just going to ask you if I needed to put it in that line.  Currently I have i915.powersave=0 there, but I don't think that works for me. 
<patrickdickey> The other issue I have (and it may be related to the flickering) is that in dmesg, it shows that it found my external monitor, but couldn't get it's EDID? From it (It's an Acer P241W monitor). Is there a way of fixing that?  I realize that's probably out of scope from this room.
<patrickdickey> Anyhow, I'll give the radeon.new.pll=0 a try.  Thanks for all of your help (and bryceh's help yesterday also).  Have a great day:)
#ubuntu-x 2010-09-23
<Sarvatt> chrisccoulson: we actually have newer ia32-libs in xorg-edgers that pull in all of the components at build time if you just need to test some gtk stuff in it
<Sarvatt> gotta update that in there to make wine not suck with mesa :(
<ScottK> Sarvatt and RAOF: Is there other stuff you guys need sponsored before RC?
<RAOF> ScottK: I don't have anything queued up, but I suspect sarvatt might want an xserver-xorg-video-intel upload?
<Sarvatt> ScottK: not that I'm aware of, the mesa release guy is in vegas at the moment..
<ScottK> OK.  Considering the mesa revert was sitting there waiting, I thought I'd check.
<ScottK> Thing have gone from totally unpleasant to good with a few warts for me now and I wanted to make sure there wasn't more stuff waiting to make it even better.
<RAOF> Heh.
<RAOF> The 7.9 release may fix more stuff but hasn't happened yet :)
<RAOF> At least there's now a release branch, though.
<RAOF> Hm.  This bug has a 26MiB Xorg.0.log.old attached.  I wonder what causes that?
<RAOF> Aaaaah.  Stupid fbdev.
<Sarvatt> that copyfb patch still needs fixing, I'm really stumped on it and am really swamped with 3 new machines to make work
<RAOF> Didn't you just prevent that patch from activating on gen 6?
<Sarvatt> yeah but its broken on all other intels at the moment..
<RAOF> â¦?
<RAOF> Is there some reason why my GM45 isn't affected, then?
<Sarvatt> have you made it hang or logged out of KDE lately? :)
<RAOF> Oh, _that_ :)
<Sarvatt> it doesnt look like its actually hurting anything, just spewing a backtrace in the  log
<RAOF> Right.
<RAOF> Whereas not briging up X on sandybridge is a somewhat more important bug!
<Sarvatt> blacklisting in compiz was a silly move, should have blacklisted i965_dri.so from the start but intel insists its going to be in a usable state for the Q3 release (7.9..)
<Sarvatt> i think theres a big disconnect between the people I talk to and the people actually working on mesa :D
<RAOF> :)
<ScottK> Sarvatt or RAOF: If there's a release branch for 7.9 now, might it make sense to consider a snapshot update?  I'd be glad to help test it.
<RAOF> Sarvatt's just told me that it fixes a trivially reproducible intel GPU hang, so I'll certainly look at it now.
<Sarvatt> yeah it would, we were just discussing it actually
<ScottK> OK.  Let me know when there's a package to test.
<RAOF> Mesa would be so much less scary if there weren't hundreds of commits in the order of a couple of days.
<RAOF> Damn those GPUs and their insane complexity :)
<ScottK> As long as RAOF makes sure he's not running a patched clutter this time, I think we can test it out fine.
<Sarvatt> hoping http://lists.freedesktop.org/archives/mesa-dev/2010-September/003183.html gets picked up but i'm not holding my breath, going to blacklist these GPU's from i965 anyway
<ScottK> ;-)
<RAOF> :`(
<ScottK> Hey, stuff happens.  The story had a happy ending.
<RAOF> Sorry about that - I should have documented that on the FFe bug and/or tracked the sponsorship request more.
<Sarvatt> hey, at least it was an interesting day :)
<Sarvatt> btw ScottK, what I feared looked to be true with that mesa patch for the KDE problem, horrible memory leaks :(
<RAOF> How did you get that to apply to -0ubuntu3?
<ScottK> Sarvatt: It's all about peeling the onion.
<RAOF> The code it was patching disappeared.
<Sarvatt> I didn't, someone else reported it on the bug
<RAOF> And just for completeness, that bug *definitely* appears on -0ubuntu3, right?  I can't get it to hang locally - it just crashes :)
<ScottK> RAOF: I can get it to hang.
<RAOF> Ok.
<RAOF> Again, my hardware is magical.
<Sarvatt> screwing with drawable destruction voodoo is how we had that big memory leak at the last minute from that patch I added, anything touching that scares me now :)
<ScottK> Or mine is, but in a bad way.
<Sarvatt> err big memory leak in xserver on lucid at the last minute
<RAOF> Yeah.  Problems in drawable destruction can lead to fun unreported memory leaks!
<ScottK> RAOF: Mine is a Dell mini 10v, so it's stuffed with the cheapest they could find of whatever it absolutely had to have.  I'm not surprised it sucks in special ways.
<ScottK> I'll have to try on some other hardware too.
<RAOF> If it didn't mean rebooting my IRC server I'd try on my 945 netbook, too.
<Sarvatt> so yeah, I reenabled vblank in mesa and it's still broken over a year later, I hope more netbooks aren't hitting this problem
<RAOF> (Stupid âswitchableâ graphics that hides the device from the PCI bus entirely)
<Sarvatt> all aspire one AOA1xx's are at least
<RAOF> Sarvatt: by vblank do you mean flipping support?
<Sarvatt> interrupts are screwed, if i run glxgears and dont move the mouse for instance it drops down to around 17fps
<RAOF> Oh.  _That_
<RAOF> There were drm patches for that, I thought?
<Sarvatt> nope, still busted, someone just brought it up again on the intel-gfx list and i've  been trying the patches jbarnes is posting but no luck
<Sarvatt> it makes for one horrible experience with unity and such though
<RAOF> Do we have vblank disabled on those machines?
<Sarvatt> its enabled in mesa unconditionally for dri2 on radeon and intel
<RAOF> And we don't have a nice list of broken pciids/dmi data to blacklist it off in a patch?
<Sarvatt> nope, that was the dri1 version back in intrepid or jaunty I think?
<RAOF> Maybe we should do that.  Screen updates only when moving the mouse aren't my idea of a nice user experience :)
<bryceh> Sarvatt, I finally fixed that broken graph.  It took 30 sec, I don't know why I bothered being so damn lazy about updating it, sorry.  http://localhost/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<bryceh> problem was just that the total had exceeded the bounds of the graph.
<Sarvatt> hah!
<bryceh> *sigh* and I could give the RIGHT link
<Sarvatt> I can't even count the number of times I've done the same thing :)
 * RAOF needs to learn more nouveau driver internals.  Or, alternatively, nouveau needs to grow some mortal-readable error messages.  âEvoCh 0 Mthd 0x0080 Data 0x00000000 (0x0005 0x05)â is not friendly.
<Sarvatt> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick.svg a wrong link?
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<Sarvatt> oh workqueue works, woot
<Sarvatt> thanks bryceh!
<bryceh> fixing the other too...
<RAOF> Hello, intel!
<Sarvatt> i've really been focusing on major specific bugs instead of mass bug work, those graphs are always depressing
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick.svg
<bryceh> Sarvatt, yeah I know
<RAOF> Totals-maverick looks moderately broken.
<bryceh> shift-reload
<RAOF> Except for the part where we've got a big bunch of intel bugs, of course.
<Sarvatt> at least I see a few jumps in intel where i found mass dupes of what i was working on there :D
<Sarvatt> theres a crapload of apport crash bugs on intel
<RAOF> That's true.
<bryceh> intel always has a fair share, but this looks a bit anomolous that half of the bugs reported in maverick were against -intel... what's going on?
<Sarvatt> apport hook being enabled at the start :)
<bryceh> oh apport hmm
<RAOF> The one with the best debugging tools gets the most reports.
<RAOF> We didn't turn it off this time.
<bryceh> are they valid crash/freeze captures?
<RAOF> By and large, yes.
<Sarvatt> i can't keep up with them, there are so many dupes but they take quite a long time to fully review unless I know specifically what the crash I'm looking for looks like (which happens a lot and they are very useful to have in that case)
<bryceh> Sarvatt, yeah I've been sort of pondering giving up on mass bug management and just focus on specific priority bugs myself.  That's basically how I've been working on launchpad (which also has quite a few bug reports).  But I dunno
<bryceh> mass bug management takes a considerable chunk of time, even with automation
<bryceh> Sarvatt, don't you just want to say "SHUTUPSHUTUPSHUTUP!!!" ?  ;-)
<RAOF> And generally doesn't produce a lot of value for us (at least, I'm not sufficiently efficient at manipulating launchpad to make it a positive time investment)
<bryceh> I felt like I was able to squeeze value out of it, but mostly because of sending bug reports upstream
<bryceh> and then cherrypicking the patches back
<RAOF> Right.  That's something you're much better at than I am :)
<RAOF> (still)
<bryceh> yeah it tends to be kinda tedious work (hopefully my current work will be mitigating that some)
<bryceh> I suppose with these graphs, the important thing is not so much the magnitudes but rather the slope
<RAOF> Yeah.
<RAOF> They're not a perfect metric, but the slope is the important one.
<Sarvatt> someone went through and duped the huge amount of fglrx doesn't work in maverick bugs I see (thanks whoever that was!)
<bryceh> yeah I've been surprised by the number of questions about fgrlx-vs-ati lately
<bryceh> oh hey while you're both here... I fielded a question earlier today about whether fglrx+randr supports multi-card setups for >2 heads, or if it's limited to a single card like other drivers
<bryceh> I figured it was probably 1-card, do either of you know differently?
<RAOF> I don't know differently.  Offhand, I'd *suspect* that it would actually handle multi-card reasonably; it's the sort of thing that workstations with 3+ monitors would want.
<RAOF> And given fglrx is targetted at workstationsâ¦ :)
<bryceh> also, I recall someone (airlied? ajax?) was working on multi-card support for -ati... but a few minutes googling didn't turn up any recent news on that front; know if there was any progress?
<Sarvatt> 99% positive it does with evergreen at least, lemme see if I can dig anything up
<Sarvatt> phoronix forums are actually really useful for wacky questions like that
<RAOF> I think it should currently work, modulo strangeness.
<RAOF> (Like having to pay the Xinerama tax)
<Sarvatt> pretty sure I saw them getting >2 displays on a single evergreen card up a few weeks ago on #radeon
<RAOF> Oh, that.
<RAOF> That's Eyefinity, which works, yeah.
<RAOF> As long as you've got DP outputs, apparently :)
<Sarvatt> I have a hunch bryce is asking because he's looking to buy and might be able to accomplish what he wants with 1 card is why I mentioned it :D
<RAOF> Aaah.  Yeah.
<Sarvatt> oh yeah, whoops!
<RAOF> 1 card + DP monitors or active DPâDVI connectors.
<bryceh> yeah the config in question was an RV250 + RV710
<RAOF> I *think* that's expected to work now, modulo requiring Xinerama (and hence disabling Composite).
<bryceh> Sarvatt, no, actually it was via a canonical support customer question
<bryceh> DP == DisplayPort?
<RAOF> There was some brief discussion of Shatter at XDS; per-crtc pixmaps and such have landed already.
<RAOF> Yeah.
<RAOF> The one where adding an âeâ means âDoesn't work properly on Intelâ :)
<Sarvatt> that's a rough question because its most likely broken by different driver releases if it even does work knowing fglrx..
<RAOF> Is there a release of fglrx supporting both RV250 and RV710?  I'd guess not.
<RAOF> As I say, I believe it's expected to work with Xinerama, but you'll lose Composite & compiz and suchlike.
<Sarvatt> wow, I think it's time to turn the brain off for the night here because it's obviously not working :) night guys
 * Sarvatt fires up some minecraft!
<RAOF> Civ V!
<Sarvatt> MoM!
<Sarvatt> never played civ 5, not a huge civilization fan but I loved master of magic and alpha centauri :)
<RAOF> I've got Civ 5 wending it's merry way to me now.
<bryceh> you'll have to tell me if it's good
<RAOF> I most assuredly shall :)
<bryceh> I looked at the screenshots but it looked awfully cluttery.  But then I'm not into eyecandy in video games so much ;-)
<Sarvatt> yeah civ games always came off cluttery to me too, kinda like KDE
 * Sarvatt hides
<RAOF> Gerald the mesa build says: Time to make some coffee, sucker!  I'll be here all day!
<Sarvatt> hmm wonder if that will run on sandybridge graphics, i have a distinct lack of working dedicated GPU's at the moment
<Sarvatt> FFXIV sure as heck wont and it has similar requirements
<Sarvatt> oh wow, looks nice
<RAOF> Min spec suggests that my laptop's 7600 GT should do OK.
<RAOF> And I get to test out whether r600g supports enough GL now to run it on a 4xxx!
<Sarvatt> but but didn't it just get gears again a few days ago?
<RAOF> Maybe?
<Sarvatt> oh wait its mesa, a few days is a few thousand commits
<RAOF> Yeah.
<bryceh> heh
<RAOF> ScottK: Oh, you were on i386 for your mesa, weren't yoU?
<ScottK> RAOF: I was and am.
 * RAOF fires up a i386 schroot, then.
<Sarvatt> was going to say there's one on the VPS but had to delete it earlier to make room for a kernel build, which i couldn't make enough room for out of the 10GB.. :)
<RAOF> :)
<Sarvatt> did you already package it up then? dont want to step on your toes yet again in git :)
<RAOF> Got the packages built, yeah.
<RAOF> There's some cleaning up that still needs doing.
<RAOF> And, obviously, actually testing it!
<Sarvatt> i've been updating 7.9 branch packages daily just in case some obvious nasty bug creeps in, the egl kms/drm change was the only thing major i've noticed
<RAOF> Yeah.  That's done.
<RAOF> Hm.  I should have fired off this build in screen so I could spend some quality time crashing KWin on the new mesa.
<RAOF> Sarvatt: Why are you versioning xorg-edgers packages as 7.10+git, by the way?  It should be 7.10~git :/
<Sarvatt> not enough time to pay much attention to it + automated script that uploaded a + :(
<RAOF> Eh; sok.
<Sarvatt> i really need to fix that so it does a ~ if there's a version bump
<RAOF> You'll need to ppa-purge regardless; it's not like upgrading from xorg-edgers is anything but explicitly disowed.
<Sarvatt> I prefer that way of thinking regarding it :) there are some pretty drastic differences in there at some points, upgrading to a newer synaptics version in ubuntu with an older abi is a PITA
<Sarvatt> like they dont bump the version in master for a few things and the stable branches have a higher version
<RAOF> Sweetness.
<ScottK> RAOF: Here's an odd one for you on this kwin settings thing: On my Dell mini 10v - change kwin settings and system freezes, reboot into a live session and try the same thing and it doesn't freeze, I get the kwin crash.
<ScottK> Both are up to date maverick.
<RAOF> ScottK: Because consistency in bugs is too easy!
<ScottK> OK.
<RAOF> ScottK: i386 packages up at http://cooperteam.net/Packages/
<ScottK> Looking.
<RAOF> (Again, you're after libgl1-mesa-{glx,dri})
<ScottK> Just what I was typing a question about ....
<ScottK> So far it didn't cause a fire.
<ScottK> RAOF: My initial impressions are things seem subjectively slightly faster.  No new bugs immediately obvious.  Both the freeze on kwin setting change and the X crash on logout are still there (as one would expect).
<ScottK> I'll try it on some other systems tomorrow.  It's well into very late here, so I need to get to sleep.
<RAOF> Go for it!
<RAOF> Heh.  The kwin crash is 177 stack frames deep.
<ScottK> mgraesslin is coming to UDS, so you can get even there.
<RAOF> Garh.  How have I killed kwin desktop effects?
<tseliot> RAOF: with what driver?
<RAOF> Intel.
<tseliot> hmm...
<RAOF> But I'm not entirely sure what I've done - they were working, then I applied the interesting parts of the patch on bug #628077 to the DDX, then everything broke.
<ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i865] Crash on logout with KDM (affects: 1) (heat: 169)" [High,Confirmed] https://launchpad.net/bugs/628077
<RAOF> â¦but dropping back to the archive DDX hasn't fixed it.
<RAOF> Hm.  I also enabled some debug in libdrm.  Let's see if that's it.
<tseliot> RAOF: that's weird, I think kwin only checks the availability of certain extensions
<RAOF> Yeah.
<RAOF> The âdisable functionality testsâ checkbox doesn't do anything interesting, either.
<tseliot> yes, I've noticed that
<RAOF> Heh.
<RAOF> I wonder if it's actually hooked up to anything, like that âsave the sessionâ button gnome-session had at one point. :)
<tseliot> RAOF: are you sure the cause is not some update of kdebase-workspace?
<tseliot> ScottK: ^^
<RAOF> I don't think so.
<ScottK> tseliot: Sarvatt pretty well narrowed it down to something to do with that patch.  At one point he produces packages that didn't crash (they had other problems, so weren't directly suitable) and so it's pretty clearly in Ubuntu's X stack.
<RAOF> ScottK: Did he find that it broke kwin?
<ScottK> The patches he had me test did not, as I recall, but that was a while ago when we hat the old mesa, so things were pretty rough overall.
<RAOF> I know what the interesting bit of that âapplies to gitâ patch; it's mostly the FreeScratchPixmap.
<RAOF> That fixes it.
<ScottK> That sounds like good news.
<tseliot> ah
<RAOF> ScottK: With the small downside that it seems to break kwin for no obvious reason ;)
<ScottK> Right.
<ScottK> That would be a problem.
 * RAOF does a bit of a restart dance.
<RAOF> Ok.  Back to all stock Ubuntu packges, and kwin still refuses to enable GL effects.
<RAOF> ScottK: Is there any knob to twiddle to make kwin work again?
<ScottK> RAOF: It's got a safety valve where if you crash kwin too many times, it sets itself off for good.
<ScottK> There will be some thing in ~/.kde/share/config/kwinsomething (probably kwinrc)
<ScottK> You can just rm the kwin related config stuff and start over if you don't want to pick through it.
<ScottK> (sorry I didn't remember that earlier)
<RAOF> Aha.
<RAOF> I suspect it might be the OpenGLIsUnsafe=true
<RAOF> Is this the intended user experience?  You accidentally mess with kwin too much, and it will forevermore refuse to enable compositing?
<RAOF> Sorry, that was a bit snarky.
<tseliot> I guess they're just being overcautious ;)
<RAOF> Well, that can now be deferred to tomorrow.
<ScottK> It's meant to keep users from being overwhelmed by repeated crashers, but it's not particularly developer friendly.
<jibel> Could a member of the ubuntu-x-swat have a look at bug 645064. Since it's a widely used ppa, it may causes issues when comes the time to upgrade to maverick.
<ubot4> Launchpad bug 645064 in update-manager (Ubuntu) (and 1 other project) "nvidia-current from Ubuntu-X-Swat PPA is blocking the upgrade from Lucid to Maverick (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/645064
<tseliot> mvo: maybe we should call "ppa-purge" on dist-upgrades to avoid these problems ^^
<mvo> tseliot: I need to run, I have a look when I'm back (sorry)
<tseliot> mvo: np. Thanks
<mvo> thanks tseliot and jibel
<Sarvatt> that's one of the reasons I'm not sure nvidia-current providing an artifical abi is a good idea since its compatible with both abi's and is causing package manager problems
<bjsnider> but the lucid and maverick versions are providing the same abi, so why is it blocking the upgrade?
<Sarvatt> they aren't, maverick is xserver-xorg-video-8
<Sarvatt> its something to do with xserver-xorg-core having a breaks: on the old abi interacting with apt ordering, doesn't happen if the breaks are gone and not sure how to make it want to remove nvidia before trying to upgrade X
<bjsnider> yes but that virtual package is provided by a lot more than just nvidia-current
<bjsnider> there are 43 packages that provide xserver-xorg-video-6 in lucid, so why is nvidia-current causing this problem and not all the rest of them too?
<bjsnider> and why isn't the package manager preferring to move the video-8 as a newer version, which the nvidia-current maverick package provides?
<jibel> bjsnider, update-manager refuses to upgrade nvidia-current because the ppa is disabled at upgrade time. Since it's manually installed it puts it on hold and blocks the upgrade of the xserver.
<jibel> bjsnider, I haven't dig further but it's the kind of scenario.
<bjsnider> oh, right
<bjsnider> and the ppa has a newer nvidia blob than maverick
<jibel> bjsnider, right
<bjsnider> so all the other 40-some video-8 packages upgrade because the maverick versions are available at that time
<bjsnider> well i'm damned if i know how to fix that
<Sarvatt> i put a note about needing to ppa-purge before upgrading on x-updates like there is on xorg-edgers for now, if anything i'm thinking maybe we can just drop the abi from the PPA versions
<bjsnider> but if it disables the ppa then it should be purging it too
<Sarvatt> it never has, thats why i made ppa-purge
<Sarvatt> it's hell with xorg-edgers :(
<bjsnider> is it possible to purge that ppa?
<Sarvatt> yup
<bjsnider> why is it necessary to provide the abi?
<Sarvatt> sometimes they are late supporting a new ABI and its there to block upgrades
<bjsnider> anyway, updae-manager could be changed to test for that ppa and if it's there, install ppa-purge and then proceed to purge it
<tseliot> Sarvatt: BTW I made fglrx provide the ABI too... I wish there was a better way
<barry> hi folks.  i saw that a new fglrx-modaliases was released, and indeed i've been able to successfully install the fglrx packages. but i still cannot enable desktop effects for my radeon hd 4670 in 64bit maverick
<barry> should that be possible now or do i still have to wait? (fine if so)
<barry> i can't find a log file of the attempt to enable it and don't see any errors in my Xorg.0.log
<ScottK> New mesa snapshot seems to work well on Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<strycore> hello
<strycore> #ubuntu-bugs
<strycore> damnit :P
<strycore> ok Maverick is coming soon and lately I have noticed a strange bug for almost every full screen game 
<strycore> the mouse pointer comes bask to it's original position every second or so
<strycore> I guess it's related to Xinput
<strycore> argh it's driving me crazy
<strycore> ok , nevermind I found the guilty program
<strycore> unclutter
<strycore> I was suspecting either SDL or Xinput :P
#ubuntu-x 2010-09-24
<Sarvatt> so, after disabling DRI on sandybridge, is it worth another upload reverting the compiz blacklist?
<RAOF> I'd guess yes; who's maintaining compiz nowadays?  Still mvo?
<Sarvatt> RAOF: ok we need to --disable-gallium-radeon whenever we update mesa again next
<Sarvatt> they made r300g the default
<RAOF> Whyso?
<Sarvatt> built by default, takes the place of r300g I think in the build output?
<RAOF> So we need to update the bit of the rules file where we delete that, then.
<Sarvatt> might be confusing it with intel, hmm
<Sarvatt> err r300c
<RAOF> It still ends up in gallium/r300_dri.so, right?
<RAOF> (Because we'd still quite like r300g for the egl/gles/openvg stuff)
<Sarvatt> doesn't look like they moved it so yeah
<Sarvatt> sorry, got mixed up. the mesa build gives me a headache :)
<RAOF> Heh :)
<Sarvatt> adding a new build target for llvm will be fun if we ever do it! :)
<RAOF> Eh.
<RAOF> We'll just turn it on unconditionally on amd64, and ignore it for i386 :)
<RAOF> We don't need to build mesa any *more* times! :)
<Sarvatt> too bad i believe most of the people who benefit the most from llvm will be stuck on i386 (old ati IGPs)
<Sarvatt> pentium m and earlier era ones
<Sarvatt> * Add kubuntu_29_fallback_to_xrender_compositing.diff
<Sarvatt>  fallback to XRender compositing in case of Software Rasterizer.
<Sarvatt>  (backport from trunk)
<Sarvatt> \o/ \o/
<RAOF> Yup.
<Sarvatt> ScottK: that was the fix for swrast?
<Sarvatt> i was kind of hoping they would just make the GL compositing fall back to xrender instead of disabled
<ScottK> Sarvatt: I think that's what it does.
<Sarvatt> ahh ok
<ScottK> (the kwin patch)
<Sarvatt> awesome if so, fixes a lot more than swrast then
<ScottK> Sarvatt: http://bazaar.launchpad.net/~kubuntu-members/kdebase-workspace/ubuntu/annotate/head:/debian/patches/kubuntu_29_fallback_to_xrender_compositing.diff
<Sarvatt> thanks, was just digging for it :)
<ScottK> I think it's just swrast
<Sarvatt> ah only swrast :(
<ScottK> You can talk to mgraesslin in person at UDS about extending it for KDE 4.6.
<RAOF> I should point him at the GL|ES 2.0 docs; apparently mesa should be growing a âES compatibility in desktop GLâ mode, and (also apparently) the ES docs have a nice appendix with âhere's all the stuff we mandate that various hardware doesn't implementâ
<Sarvatt> oh really? it's got a nice list of hardware limitations?
<Sarvatt> that's exactly what i've been looking for
<RAOF> I haven't read it, but the âWhat GL calls can you safely useâ session basically ended with âLook at the ES docs!â
<Sarvatt> not seeing it, maybe in the GL 4.1 docs since thats where the ES compat stuff was added. hmm
<RAOF> That might be it?
<RAOF> From memory, it should be appendix A
<Sarvatt> can't find it in any of these, but this will be good reading material for the flights to UDS and plumbers at least :)
<RAOF> Oooh!
<RAOF> That might fix kwin desktop effects switching!
<Sarvatt> what, the commit 2 hours after you packaged one for ScottK last night? :)
 * ScottK waits to try.
<RAOF> You mean "hold on to drawables if we're just switching to another context"?
<Sarvatt> yup
<Sarvatt> saw that on master and of course it was cherry picked right after you packaged one up :)
<RAOF> ScottK: Building the sucker right now for you.
<Sarvatt> the bug was saying the problem it was fixing was caused by one of the commits we reverted in 0ubuntu2 and it was still broken there, but there have been a bunch of other changes that might interact with it
<RAOF> Yes.  The patch on the bug doesn't apply, because it was against the 7.8 code that we reverted to in 0ubuntu2 that was removed in 7.9 (and hence doesn't appear in ubuntu1 or ubuntu3).
<Sarvatt> I meant https://bugs.freedesktop.org/show_bug.cgi?id=30234 referenced in that commit's log
<ubot4> Freedesktop bug 30234 in Mesa core "Mesa xdemo manywin aborted" [Major,Resolved: fixed]
<RAOF> Ah, right.  Yeah.
<Sarvatt> hmm yeah blender's user preferences is broken here too
<bryceh> what's the problem?
<Sarvatt> and i've got that commit, odd
<Sarvatt> there's a freeze on kwin effect setting changes on intel, and raof just spotted a commit that might fix it. i was just off in lala land testing out the other broken things mentioned in the bug for that commit
<Sarvatt> since restarting into KDE on the only machine I use IRC on is a PITA :)
<RAOF> :)
<bryceh> gotcha
<RAOF> Ah, mesa.  sink of endless CPU time.
<RAOF> We should probably ensure libGL doesn't needlessly link to libstdc++ for natty.
<Sarvatt> thats just the swx11 libGL isn't it?
<Sarvatt> (that the warning is for)
<RAOF> Possibly.  I was just watching the warnings stroll past.
<RAOF> ScottK: New packages are available for your testing pleasure; again on cooperteam.net/Packages
<bryceh> RAOF, file a bug for now?
<ScottK> Thanks.
<Sarvatt> I'm still wondering if we should be shipping gl.pc from the dri build target
<Sarvatt> in libgl1-mesa-dev, it has a bunch of extra Requires.private packages in it compared to the one we ship
<RAOF> Interesting.  That could well be important.
<Sarvatt> Requires.private: libdrm >= 2.4.15 dri2proto >= 2.1 glproto >= 1.4.11 x11 xext xdamage xfixes xxf86vm is what libgl1-mesa-glx actually needs
<Sarvatt> Requires.private: x11 xext is what the one we ship from another build target has
<Sarvatt> well thats edgers and probably only there from another confflag i'm using, the one in maverick might not have anything
<ScottK> Installed.  We'll see.
<ScottK> RAOF: Victory!
<ScottK> Also I had effect on login an that very rarely happens on this machine (it does sometimes, so I might have just been lucky).
<ScottK> I was able to reset effect with them enabled and neither freeze nor crash.
<ScottK> RAOF and Sarvatt: My hope is we'll try and get this tested and get it in before RC if it makes sense.
<RAOF> Oh, man.  This fixes so much kde.
<Sarvatt> ScottK: what would you consider the absolute latest deadline for that to be for future reference? It would be extremely nice if we could time it with an actual release instead of another git checkout
<RAOF> Present windows also now has actual windows.
<ScottK> Sarvatt: It would need to be in the archive on Monday.
<Sarvatt> got ya, so testing what you have there it is
<RAOF> Ahem.  And has just locked the GPU, so it's not _all_ peaches and cream.  But it did that before.
<ScottK> Well sure.  If Mesa ever was fully tamed you'd be dissapointed and board.
<Sarvatt> RAOF: tried  INTEL_NEW_FS=1 on your gm45 lately?
<Sarvatt> supposedly wins as many piglits as the old one now
<RAOF> I have not tried that.
<Sarvatt> man, no touchpad scroll *really* sucks, poor people stuck with alps touchpads
<RAOF> Hm.  Yep, it really is present windows that's locking the GPU.
<RAOF> I should really switch the alt-tab away from that :/
<Sarvatt> i still can't believe we got a fglrx that works with xserver 1.9 and its not on phoronix yet :)
<Sarvatt> hmm quite a few id's were ripped out of here in these maverick ones
<Sarvatt> 1002:17xx? never seen those before, maybe its hd 6xxx series but they are gone from the 8.780 ones
<dandel> Is it a bug to be unable to change the tv format on live cd of ubuntu 10.10 (using kms and xrandr)
<RAOF> dandel: With which video driver?  Most should have an xrandr property to change that, I believe, although I think nouveau takes that as a module parameter instead.
<dandel> hmm... radeon driver.... got it figured out a bit
<dandel> i just happend to crash the xserver a few times by using this command (drm failure)... xrandr --output s-video --set tv_standard ntsc
<dandel> it didn't crash when i changed the output to a valid target tho lol.
<RAOF> Hme
<RAOF> Hm.
<RAOF> Feel free to file a bug if you can get a backtrace of that.
<RAOF> But also good to hear that it works, too :)
<dandel> now for a slight kicker... I'm using this to help fix another driver (namely the lack of analog support happauge hvr 1250 tuner cards)
<dandel> i got short backtrace on the laptop also... one sec while i get the xorg file
<dandel> RAOF, here's the backtrace: http://pastebin.ubuntu.com/499512/
<RAOF> ta
<dandel> happens on any invalid output
<RAOF> Hm.  That's not very useful :)
<RAOF> Backtracing X is a somewhat arcane art, though.
<RAOF> wiki.ubuntu.com/X/
<dandel> one sec... i'll see if 10.04 reproduces.
<RAOF> wiki.ubuntu.com/X/Backtracing gives some clues.
<dandel> i'm on a laptop which is fairly new which has a little effect.
<dandel> however, it's not new enough to cause too much problems
<RAOF> I'm surprised that backtrace doesn't appear to have any driver-related frames at all.
<dandel> I know, and I'm not exactly certain as to what happened either.
<andrewaclt> Is the wiki correct in saying that I need to intall the mainline kernel in lucid to debug intel gpu freezes?
<tseliot> mvo: have you had the chance to have a look at bug 645064 ?
<ubot4> Launchpad bug 645064 in update-manager (Ubuntu) (and 1 other project) "nvidia-current from Ubuntu-X-Swat PPA is blocking the upgrade from Lucid to Maverick (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/645064
<mvo> tseliot: not yet, sorry, was hunting a race all afternoon (frustrating that)
<tseliot> mvo: np, I can understand ;)
<Sarvatt> the sandybridge pain never ends, now tiling has to be disabled for resume to work properly on .35
<tseliot> :/
<cwillu_at_work> [672621.387536] [drm] nouveau 0000:01:00.0: no space while hiding cursor
<cwillu_at_work> under nouveaux with compiz, lucid, 2.6.36-rc4 kernel
<cwillu_at_work> few hundred in dmesg, occurs when moving the mouse from my left monitor to the right monitor;  an extra cursor is left behind on the left monitor until I bring the mouse back
<cwillu_at_work> also triggers while typing after mouse movement (i.e., when the mouse cursor would normally be hidden)
<Sarvatt> using xorg-edgers or something?
<cwillu_at_work> yes
<cwillu_at_work> how else do I get compiz love out of nouveau? :p
<Sarvatt> on lucid? rebuild mesa from maverick :D
<Sarvatt> but wouldn't work with that kernel anyway
<Sarvatt> if it doesn't happen without nouveau_dri.so its pretty much guaranteed upstream wont care about a bug report
<cwillu_at_work> I haven't run into this on earlier kernels;  I'm assuming it's just something out of sync then?
 * cwillu_at_work shrugs and puts maverick on this box :p
<cwillu_at_work> incidently, if any of you recall my babbling about broken suspend in a slightly odd fashion earlier this year, I tripped over an lkml thread from the 2.6.28 release cycle talking about a fairly common problem with 64kb lowmem corruption;  maverick's kernel has some debugging enabled to detect such corruption, which also has the effect of avoiding those crashes (as the kernel avoids using that memory), with the cute side effect that the laptop now sus
<cwillu_at_work> pends and resumes fine :p
<Sarvatt> odd, that kernel config option has been enabled since 2.6.28 i'm pretty sure
 * Sarvatt remembers disabling it specifically in his own kernels during 2.6.29
<cwillu_at_work> Sarvatt, I'm getting the memory corruption warnings in dmesg now, which I never got before
<Sarvatt> oh maybe it was fixed to actually work now then! :D
<cwillu_at_work> heh
<Sarvatt> RAOF: from idr - "I'd like to have a 7.9 release candidate on Monday (9/27).  Assuming there are no major issues, I'd like to have a final release on the following Monday (10/4).  Does that work for people?"
<tseliot> idr?
<Sarvatt> yeah intel guy handling the mesa release
<tseliot> aah
<Sarvatt> cutting it so close :(
<tseliot> are we still considering 7.9 for inclusion?
<Sarvatt> 7.9 is already in
<tseliot> oh, I didn't notice
<ScottK> Sounds like the best plan is an updated snapshot next monday (after testing), the mesa RC after Ubuntu RC and then SRU to 7.9 final.
<tseliot> having an RC would be more than welcome then ;)
<tseliot> ScottK: +1
<Sarvatt> need to check if there are mesa 7.9-devel specific KDE blacklist strings because the version string will change and the blacklists will be lost
 * Sarvatt goes digging
<Sarvatt> looks fine to me, its only got 7.7.1 and 7.8.2 in the blacklist
<Sarvatt> new snapshot->RC will have a very minor amount of changes, the crack commiters are focused on 7.10 already :)
<Sarvatt> ScottK: so the new snapshot did fix your KDE freezing problem? sounded like RAOF's freeze was with a specific plugin not enabled by default?
<ScottK> Sarvatt: It did.
<Sarvatt> awesome
<ScottK> Still can't logout though ....
<Sarvatt> RAOF: can you please push what you have to git? I'm going to screw you up if I do it again when you already have it locally :)
<Sarvatt> RAOF seems confident he can get that fixed up ASAP, holding off on another major bug fix x-x-v-intel upload until he cracks it 
<ScottK> OK.  Great.
<andrewaclt> Do I have to run a mainline kernel to debug intel gpu freezes?
#ubuntu-x 2010-09-25
<Sarvatt> well, one day of trying to break stuff with mesa 7.9~git20100923-0ubuntu1 on 945gme and nouveau down and nothing spotted yet
<ScottK> Sarvatt: I notice a number of packages still depending on mesa-utils: http://people.canonical.com/~ubuntu-archive/NBS/mesa-utils - What is the replacement package for mesa-utils?
<Riotta> does this is ubuntu-x-swat or x-edgers channel?
<RandBrittain> Hm, I thought it would be okay to install this fglrx update, since it claimed to build in amd64 even if it didn't in i386. Clearly this was overly bold of me, for now I can't boot normally.
<RandBrittain> Is my best bet going to be going back to the last version of fglrx (and, incidentally, what's the best way of doing that?)
#ubuntu-x 2010-09-26
<RAOF> Woot!  I think that's KDE fixed.
<RAOF> At least as far as ânot crashing the X server on logout with intelâ can be regarded as âfixedâ :P
<Sarvatt> are you kidding me? LOL
<Sarvatt> I had that patch backported in a bunch of the fixed ones I was testing, but didn't try that combination of adding the FreeScratchPixmapsForScreen with that patch at the same time, bah!
<Sarvatt> checking if sandybridge works with that, I can dream :)
<andrewaclt> The wiki says I should run a mainline kernel so I can get a batchbuffer dump. However, I'm having some driver issue it seems. Is there another way to get a batchbuffer dump?
<RAOF> andrewaclt: It depends on which Ubuntu release you're running - Maverick has a 2.6.35-based kernel, so it's ready to go.  10.04 has a 2.6.33-based kernel (at least for its drm), so needs a newer kernel to get proper error_state.
<andrewaclt> RAOF, Yeah, I installed the mainline 2.6.36 kernel, but it's very laggy
<andrewaclt> the mouse pointer is.
<RAOF> After a while, or from the get-go?
<andrewaclt> get-go
<RAOF> I haven't checked recently, but there was a serious memory leak in drm at the -rc1 stage or so.
<andrewaclt> It I mean it's fine for 5-10 seconds, freezes, rinse and repeat
<RAOF> Oh.
<RAOF> That's probably the polling for output loop.
<andrewaclt> Is it fixable? Kind of hard to debug my other issue :)
<Sarvatt> i think theres a i915 module option to disable polling to fix that
<Sarvatt> can change it at runtime, looking for where it is now
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
<Sarvatt> echo 0 | sudo tee /sys/module/drm_kms_helper/parameters/poll
<Sarvatt> err echo N I guess
<Sarvatt> can boot with drm_kms_helper.poll=N added to grub to turn it off too
<andrewaclt> that seems to have done it
<andrewaclt> Sarvatt, Thanks.
<andrewaclt> One last question, if I can't reproduce my gpu freeze on the vanilla kernel what do I do?
<bryceh> andrewaclt, if you can find out an upstream kernel patch that fixes it, you can request that patch be added to the ubuntu kernel
<bryceh> although honestly it's probably kinda too late to get anything more into the kernel
<bryceh> at least, for this release
<arie_> Hello, I am getting [ 7006.027503] fglrxinfo[1395]: segfault at 4 ip 00007f20bfdfd38e sp 00007fff0c55df40 error 4 in libGL.so.1.2[7f20bfda2000+ae000] when I run fglrxinfo
<arie_> this is the line from dmesg btw
<arie_> nothing in Xorg.0.log
#ubuntu-x 2011-09-19
<Sarvatt> woohoo, sandybridge macbook air's work now with http://cgit.freedesktop.org/~keithp/linux/log/?h=fix-edp-vdd-power
<Sarvatt> \now to work out the nightmare that is the mac input stack
<Sarvatt> xf86-input-multitouch/xf86-input-mtrack..
<RAOF> It's not evdev?
<RAOF> Or, rather: their touchpad doesn't use the same protocol as the magic touchpad, which works?
<Sarvatt> RAOF: could be I just don't know the default gestures, not having right click sucked :)
<Sarvatt> have to look into all this stuff when its not almost midnight
<RAOF> Sarvatt: The four-finger gestures seemed to be broken at XDC, but you should be able to four-finger swipe left/right to hide/unhide the launcher.
<RAOF> And four-finger-tap should be "dash"
<Sarvatt> RAOF: so I probably should have mentioned xserver 1.11
<RAOF> Ah.
<RAOF> So no actual multitouch, then :P
<tjaalton> sigh, disabling the touchpad only works until i change to a vt and back
<tjaalton> i hate the damn thing
<macer1> join #ubuntu-bugs
<bjsnider> ricotz, what do you know about monitor power saving in gnome 3? it's not respecting the settings screen
<ricotz> bjsnider, hmm, dont know, it seems to work here, at least the monitor gets turned off
<bjsnider> have you tried to change the settings?
<bjsnider> for me it always turns off in 10 minutes no matter what
<ricotz> i have it set to 1 hour, let me try
<ricotz> i have set it to 1min and it turned black
<ricotz> bjsnider, looks like it is working
<bjsnider> this is in oneiric?
<ricotz> yes
<ricotz> bjsnider, ah, you are on natty with gnome3-ppa, right?
<bjsnider> no, i am on oneiric
<ricotz> bjsnider, mhh, ok
<seb128> is somebody running nouveau on oneiric to try the patch on bug #849954
<ubot4> Launchpad bug 849954 in plymouth (Ubuntu Oneiric) (and 2 other projects) "FFe: enable flicker-free boot with lightdm (affects: 1) (heat: 8)" [Medium,Incomplete] https://launchpad.net/bugs/849954
<Sarvatt> my only nvidia machines arent supported by nouveau, argh
<ricotz> Sarvatt, hey ;), does the new xserver include this badvalue fix?
<Sarvatt> ricotz: do you have a lightdm log from when it crashed handy?
<ricotz> sorry, no
<Sarvatt> if it was dying with an assert that it fixed it'd be in there
<Sarvatt> ok, i doubt it does
<ricotz> oh, i think raof added some patch to the oneirc xserver regarding a badvalue
<Sarvatt> i've got my gtx460m box upgrading
<Sarvatt> oh
<ricotz> https://launchpad.net/ubuntu/+source/xorg-server/2:1.10.4-1ubuntu2
<ricotz> could be related
<Sarvatt> thought ya meant the wfb fix in the one i just uploaded to edgers, sorry
<Sarvatt> adding that to edgers and reuploading now
<ricotz> i just saw the update and was wondering if you already synced it with oneiric
<ricotz> ok :)
<Sarvatt> uploaded, hope it helps :) my gtx 460m laptop is updating now
<ricotz> we'll see ;)
<ricotz> Sarvatt, did you installed the cairo snapshot?
<Sarvatt> yes but I haven't had a chance to even use that laptop with the lid open today yet :)
<ricotz> hehe, alright
<Sarvatt> great, cant get unity up on it after the updates, compiz segfaulting in libutouch-geiss repeatedly
<Sarvatt> ricotz: nothing obviously going wrong, thats a good sign :)
<ricotz> Sarvatt, yeah, there was something about atk_geiss here too
<ricotz> good, i think ickle is planning a new release soon
<Sarvatt> oh firefox bundles its own cairo in the distro now doesnt it, guess I better use something else to say its not horribly broken :)
<ricotz> firefox uses the system lib ;)
<Sarvatt> http://paste.ubuntu.com/693223/ not a good day to update, looks like boot is too racy with a fast SSD
<bjsnider> Sarvatt, what is the mailing list for uploads to oneiric?
<Sarvatt> https://lists.ubuntu.com/mailman/listinfo/Oneiric-changes
<bjsnider> merci
<bjsnider> Sarvatt, is fglrx working in oneiric right now?
<Sarvatt> bjsnider: imagine so, on the off days when oneiric is working
<bjsnider> got a guy over here complaining about slowness with a 5570
<bjsnider> which is absurd
<bjsnider> that card is 100 times more powerful than unity would require
<Sarvatt> bjsnider: tell him to turn off vsync in ccsm maybe?
<bjsnider> that's what he was talking about, but that's just going to introduce tearing
<bjsnider> is this how unity always is with ati hardware?
<Sarvatt> thats how everything is with fglrx is more like it
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/763005 btw
<ubot4> Launchpad bug 763005 in fglrx-installer (Ubuntu) (and 2 other projects) "Compiz's "Sync to Vblank" makes display stutter/slow with some drivers (like fglrx) (affects: 71) (dups: 4) (heat: 306)" [Undecided,Confirmed]
<bjsnider> why would a person use ati hardware, in that event?
<Sarvatt> oh looks like it was merged in compiz a few days ago, might already be out
<popey> i filed bug 854189 ..
<ubot4> Launchpad bug 854189 in xorg (Ubuntu) "nvidia binary driver gives black screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/854189
<popey> a friend has the exact same laptop running oneiric and has no issue with it, which seems odd. 
<bjsnider> popey, has nvidia ever worked on that thing?
<ricotz> Sarvatt, forgot to report back :P - the badvalue fix seems to solve my problem :)
<Sarvatt> nice
<Sarvatt> i'll tell that to the ubuntuforums people
<popey> bjsnider: yes
<popey> bjsnider: and as I said, a friend has an identical laptop which works
#ubuntu-x 2011-09-20
<RAOF> Oh!  *That's* what all the ?Xorg assert failure: *** glibc detected *** $STUFF? bugs are.
<RAOF> It's our apport-integration patch working slightly too well :)
<Sarvatt> RAOF: you've actually seen xorg assert failure bugs? I haven't since karmic
<Sarvatt> we used to get craploads of them
<RAOF> bug #839039 is one.
<ubot4> Launchpad bug 839039 in xorg-server (Ubuntu) "Xorg assert failure: *** glibc detected *** X: munmap_chunk(): invalid pointer: 0x0000000001970070 *** (affects: 1) (heat: 10)" [Medium,New] https://launchpad.net/bugs/839039
<ashams> Hi
<ashams> a bug report suggests a change to the default config
<ashams> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/850923
<ubot4> Launchpad bug 850923 in xserver-xorg-input-synaptics (Ubuntu) "Two-finger scrolling is off by default (affects: 1) (heat: 10)" [Undecided,New]
<ashams> we need an opinion there to continue triagging
<tjaalton> ashams: done
<ashams> tjaalton: thanks
<jcristau> tjaalton: but, but mac os x does it the other way!
<tjaalton> jcristau: indeed!
<tjaalton> I'd like the abomination called lenovo touchpad disabled by default, but doubt that it'll happen :P
<tjaalton> or maybe the driver could tell if it's my palm hitting it instead of the finger
<tjaalton> that would be something
<bjsnider> how could the driver accomplish that?
<Sarvatt> tjaalton: install gpointing-device-settings
<Sarvatt> screw with the palm detection sliders
<Sarvatt> you can do it manually via synclient too
<Sarvatt> but its just magic numbers you have to guess in 3 values, easier with a slider you can adjust in real time to see
<tjaalton> Sarvatt: ooh, will try it out
<tjaalton> oh well, looks like it's just parts of my lower thumb hitting it, so even the narrowest detection range isn't small enough..
<tjaalton> best to just disable it locally
<bryceh> tjaalton, you around?
<soreau> Hey guys, I installed xorg-edgers on natty but glxinfo still reports OpenGL version string: 2.1 Mesa 7.10.2 while mesa master I built reports OpenGL version string: 2.1 Mesa 7.12-devel (git-47b556f)
<soreau> What's the deal?
<bryceh> soreau, I would suspect the edgers scripts don't substitute in the version string, so it'd just be whatever's provided by upstream
<Sarvatt> it's working here
<Sarvatt> OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2
<Sarvatt> OpenGL version string: 2.1 Mesa 7.12-devel
<Sarvatt> (natty edgers)
<bryceh> although I'd expect it'd show something newer than 7.10.2 if that's the case
<soreau> huh
<bryceh> soreau, did you reboot after installing edgers?
<soreau> bryceh: of course
<soreau> How can I check what's going wrong?
<soreau> It installed all the usual packages, X mesa, ddx
<Sarvatt> soreau: pastebin  ldd `which glxinfo` and LIBGL_DEBUG=verbose glxinfo 1>/dev/null outputs?
<soreau> Oh wait..
<soreau> The following packages have been kept back:  libegl1-mesa libegl1-mesa-drivers libffi-dev libgbm1 libgl1-mesa-dri  libgl1-mesa-dri-experimental xserver-xorg-core
<soreau> wtf?
<Sarvatt> hmm
<Sarvatt> does apt-get dist-upgrade work instead of apt-get upgrade?
<soreau> let me try after this upgrade completes
<Sarvatt> thats odd though
<Sarvatt> if anything try installing xserver-xorg-core or libgl1-mesa-dri individually to see more info on why its held back
<Sarvatt> soreau: figure it out?
<soreau> Sarvatt: Oh I got a million things going
 * soreau goes to try it
<soreau> Sarvatt: Yep, dist-upgrade is doing it
<Sarvatt> oh no worries, ya just got me interested in case it's a problem with the PPA packages and not just your local setup
<Sarvatt> oh ok
<soreau> sorry for the delay
<Sarvatt> probably the libffi transition that had to be done because of multiarch
<soreau> I don't really understand why some things are reserved for dist-upgrade
<Sarvatt> upgrade wont remove packages
<Sarvatt> but things have to be removed so the newer one that conflicts can be installed
<Sarvatt> not sure why xorg-server was in that list but libffi5->libffi6 transition would cause that
<soreau> I see
<soreau> Thanks Sarvatt 
<Sarvatt> no worries, glad it was something easy and not the PPA being busted :)
<soreau> Yea me too
<Sarvatt> by the way, are you on amd64? if you ever feel adventurous multiarch is enabled in there so you can install the i386 stuff directly
<soreau> Nope, I a=only have 32bit systems available
<soreau> erm.. only*
<Sarvatt> ah gotcha, only have i386 for natty also because ia32-libs mesa for wine is a nightmare :)
<soreau> Oh yes...
<soreau> As a matter of fact, I'm investigating a bug right now where wine+steam+portal causes a hard lock
<soreau> on rv350
<Sarvatt> multiarch fixes that though if you go oneiric, can install the 32 bit mesa directly
<soreau> Yea I heard on 64bit it's somewhat of a nightmare trying to get 32bit wine stuff going
<tjaalton> bryceh: sitting on a bus, what's up?
<tjaalton> will jump off soon :)
<bryceh> tjaalton, nevermind, just had a question about a wacom fix, but figured it otu
<Sarvatt> I think we've passed jaunty in the most frequently broken development release awards, this cycle is nuts :)
<Sarvatt> granted i started with the intrepid dev cycle
<tjaalton> bryceh: oh cool
<tjaalton> Sarvatt: my thoughts exactly
<bryceh> Sarvatt, what are you seeing as the main sources of breakages?  lightdm, gnome3 transition, ?
<Sarvatt> compiz, unity, lightdm, upstart
<bryceh> so, basically everything we do development on in-house.  heh
<Sarvatt> ha, never thought of that
<tjaalton> :P
<bryceh> good thing you don't use ubuntu-one
<Sarvatt> i gave up on that 2 cycles ago, perpetually broken in development releases
<seb128> half of those which didn't really change this cycle (i.e compiz and upstart)
<bryceh> (presumably it's not upstart itself which was broken but rather upstart scripts in various services?)
<jcristau> bryceh: the breakage for everything else gets to rawhide instead? :)
<Sarvatt> seb128: more specifically upstart rules changing, adding 2 minutes boot time that looks like the system is hung on every system I have and deciding a release note is the way to go, speeding up the already racy init process and exposing breakage other places
<bryceh> Sarvatt, suspect compiz problems were due to unity exercising it in unexpected ways?
<bryceh> jcristau, yay fedora
<tjaalton> rolling rolling rolling..
<seb128> Sarvatt, ok, seems other are more lucky than you ;-)
<Sarvatt> yeah definitely feels that way :)
<seb128> we have reviewed some bootcharts in #ubuntu-desktop and nobody has such hangs
<Sarvatt> the +2 minutes was from ubiquity adding an "auto eth0" line during the install process due to the way I installed
<Sarvatt> wifi doesnt work on lots of these prerelease machines, so i have to plug in an ethernet cable
<seb128> some people have xorg getting busy for 1 second at each screen,resolution probes from g-s-d though
<Sarvatt> and it adds that entry if you're on ethernet, but when you later dont have ethernet plugged in it adds 2 minutes to the boot time
<seb128> which it tends to do a few times at logging
<Sarvatt> (real common use case on laptops I'd think)
<seb128> urg
<seb128> well just a bug during an unstable cycle, it will probably be fixed before stable ;-)
<bryceh> seb128, I talked to keithp and jbarnes about the VGA probe 1 second delay at XDS
<Sarvatt> compiz/unity problems are mostly just soname transitions every thursday/friday and accidentally letting it remove packages, thats my fault
<bryceh> they said it was a known issue but no patch available yet
<seb128> ok
<seb128> is that being worked in some way, or just on a stack of "known issues nobody has time to work on"?
<bryceh> seb128, sounded in between the two
<Sarvatt> I fear the latter which means we're going to ship with it this close to release
<bryceh> I can escalate it to Intel officially, if there's a bug# open for it
<seb128> it has been discussed on https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/828112
<ubot4> Launchpad bug 828112 in unity-greeter (Ubuntu) (and 1 other project) "Password field feedback slow at times (affects: 5) (dups: 1) (heat: 30)" [High,Triaged]
<seb128> not sure if somebody opened a clear xorg or linux bug
<bryceh> yeah I'd need a discrete report, I don't think intel would accept that for an escalation
<seb128> ok, I will ask somebody who gets the bug to open one using ubuntu-bug
<seb128> i.e jasoncwarner gets it on his box
<Sarvatt> what bugs me is I cant reproduce it on anything here and i've got way too many machines
<seb128> dholbach as well
<seb128> they both have recent thinkpads x2.. I think
<seb128> dholbach has a x220
<bryceh> seb128, great thanks; yeah file against xorg so it'll attach the usual files.  I can handle sending it to fdo and gettingn eyeballs on it
<seb128> bryceh, ok, will do, thanks
<Sarvatt> x220 both of them, it really seems limited to lenovo machines and i dont know if the lenovo platform driver is aggrevating it (thats my first hunch)
<bryceh> "platform driver"?
<Sarvatt> thinkpad-acpi
<bryceh> ah
<Sarvatt> thinkpad_acpi rather
<bryceh> well, if that's really just acpi I should doubt it'd affect vga probing but who knows, acpi is dark magick
<seb128> interesting comment on #ubuntu-desktop btw
<soreau> Now it says OpenGL version string: 2.1 Mesa 7.12-devel, at least
<soreau> wonder why it doesn't have the git id string
<Sarvatt> bryceh: chrisccoulson's numbers are more in line with the regression intel is talking about, its the insane thinkpad delays i'm confused about
<Sarvatt> thats why i'm wondering wtf is going on, thinkpad_acpi is my first guess
<chrisccoulson> we've sort-of mitigated it a little bit, by reducing the amount of times we do the probing at session start
<chrisccoulson> but that doesn't help with the crazy thinkpad numbers
<Sarvatt> lightdm is borderline unusable just on thinkpad machines from what i can see
<bryceh> Sarvatt, maybe try blacklisting thinkpad_acpi and see if the numbers return to sanity?
<Sarvatt> that 5 second xrandr probe is making lightdm run at 1fps and its super laggy
<bryceh> nice
<Sarvatt> good call, asking someone with a x220 to try thinkpad_acpi.diediedie=1 so it doesnt load
<Sarvatt> bryceh: "felt a tad more responsive typing wise, but still laggy trackpad/touchpoint wise"
<Sarvatt> so probably not thinkpad_acpi, hrm
<soreau> Sarvatt: Can you tell me where the real libGL.so lives?
<soreau> Is it /usr/lib/i386-linux-gnu/libGL.so or /usr/lib/i386-linux-gnu/mesa/libGL.so?
<soreau> Well I guess one is a symlink to the other which is a symlink to libGL.so.1 which is a symlink to libGL.so.1.2
<soreau> what a chain :P
<bryceh> ls -l /etc/alternatives/gl_conf
<Sarvatt> soreau: second one
<soreau> Sarvatt: Like I said, they're all symlinks so I found out
<soreau> pointing to libGL.so.1.2
<Sarvatt> sorry i'm slow, yeah you got it :)
<soreau> I don't understand why it works that way anyhow. Why can't there just be a single file instead of a lot of confusion
<soreau> rhetorical question because I know there's some insane, in depth theory behind it
<Sarvatt> you nailed it, very involved :)
<RAOF> soreau: Because you only install one file - libGL.so.$SOVERSION.$WHATEVER_MINOR_VERSION_YOU_WANT and the linker looks for libGL.so.$SOVERSION.
<soreau> RAOF: There's no obvious sane reason for all of that overcomplexity. (Don't you know what rhetorical means?)
<RAOF> Sure there is!  How would you be able to parallel install different minor versions of libGL if it were otherwise :)
<soreau> You don't. You install a new version of whatever package provides libGL.so and be done with it
<Sarvatt> its supposed to be api compatible between minor version updates but not the major ones, the actual lib is version .1.2 but things link against the .1 and the links work out the rest so you dont have to worry if you go from .1.1 to .1.2
 * Sarvatt hopes that makes sense after beer o'clock
<soreau> I'm sure it's beer-thirty somewhere..
<soreau> maybe I should go to the store :P
<bryceh> soreau, people like to have multiple video drivers installed simultaneously for various reasons
<soreau> bryceh: Yes, because they're crazy
<soreau> which isn't always necessarily a bad thing
<Sarvatt> glxgears wants libGL.so.1, libGL.so.1 is a link to libGL.so.1.2, if it was bumped to libGL.so.1.3 that libGL.so.1 sould still exist but if it went to libGL.so.2 it wouldnt
<soreau> Sarvatt: And the version is tied to the file name exclusively..
<Sarvatt> glxgears would have to be recompiled and link aganst libGL.so.2 instead
<soreau> ie, you can't just grab libGL.so and check what version it is somehow
<RAOF> Actually, you can; it's embedded in the file as the SONAME.
<Sarvatt> .so isn't a runtime, its what the thing gets compiled against, the .so points to whatever the current one is
<RAOF> So you could consider the links as a performance optimisation if you like.
<RAOF> Because reading a dentry is much faster than reading the dentry, reading a bunch of the file, and parsing out the SONAME.
 * soreau wishes people wouldn't answer questions labeled rhetorical
<soreau> This is about as pointless as trying to discuss why politics, computers and humans all suck
<Sarvatt> noted, non-sensical answering stopped now :)
<soreau> RAOF: I guess :P
<bjsnider> soreau, we also need the alternatives for libgl.so because the nvidia driver provides its own, and if we don't do alternatives it will likely overwrite and destroy mesa's file
<bjsnider> that creates an extra set of links
<soreau> bjsnider: So the nvidia driver just creates one libGL.so, which is the real one?
<soreau> IIRC, fglrx does that too..
<bjsnider> no, i think fglrx uses mesa, but i'm not sure
<soreau> No, it does not
<bjsnider> if you have the nvidia driver installed, you have 2 libgl.so files
<bjsnider> alternatives then switches to link everything to nvidia's libs instead of mesa
<bjsnider> when you remove the nvidia driver, hte links are switched back to mesa
<bjsnider> nvidia doesn't use mesa in any way as far as i can tell, and it has its own memory manager, so it doesn't use gem or ttm either
#ubuntu-x 2011-09-21
<Sarvatt> ricotz: cairo looks good to me
<Sarvatt> 2 days no problems
 * Sarvatt updated pixman too
<ricotz> Sarvatt, great
<tjaalton> meh, apport-collect fail on bug 854985
<ubot4> Launchpad bug 854985 in xorg (Ubuntu) "Freezes computer using a lot CPU (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/854985
<Sarvatt> tjaalton: they dont have xdiagnose installed
<Sarvatt> looks like it was only added via ubuntu-desktop
<Sarvatt> so missing in xubuntu, kubuntu, lubuntu, etc..
<Sarvatt> would pull in gtk3 other places..
<bryceh> RAOF, for a good 'huh?' see bug #850772
<ubot4> Launchpad bug 850772 in xserver-xorg-video-intel (Ubuntu) "False GPU lockup EIR: 0x00000010 PGTBL_ER: 0x00000012 (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/850772
<bryceh> esp. gander at the lspci.txt
#ubuntu-x 2011-09-22
<bjsnider> i've got tearing with the blob on mutter in oneiric
<bryceh> mutter?
<bjsnider> gnome-shell/mutter
<RAOF> bryceh: Looks like they've got an 915G motherboard; I'm not sure why that's not showing as a VGA device, though.
<bryceh> yeah
<bryceh> RAOF, got word that OpenGL 3.0 is now being targeted to mesa 8.0 in feb '12
<bryceh> checked with alex, and gl3 should benefit radeon as well, although there's some bits they have to tend to that may delay it a bit
<bryceh> so we'll have an interesting decision to make at UDS...  stable mesa 7.12 or unstable but featureful mesa 8.0
<bryceh> so jay's glsl shader stuff will wait until then; I chatted with him a bit about all this, he'll get back to us on how important this is for htem in the lts
<bryceh> RAOF, intel responded well to your suggestion of better debugging stuff, and they'll look into what they might do to improve things for 7.12
<RAOF> Sweet.
<bryceh> I also mentioned the boot performance stuff we're working on now; they seemed interested
<RAOF> I guess the other thing that we'd like is hybrid graphics support, but that's too huge to really be a wishlist :)
<bryceh> yeah we'll want to be more specific
<bryceh> next call is going to focus on feature stuff for their 2012 work; might be worth raising then. 
<bryceh> RAOF, would you mind putting some thought into a plan of attack for what we could do for hybrid graphics support?  maybe start braindumping into a wiki page under wiki.ubuntu.com/X/
<bryceh> (google docs to the rescue, heh)
<RAOF> What?  Why would you install mesa 7.11 from a random PPA?  Why would you do that?!
<tjaalton> bryceh: are they going to do both 7.12 and 8.0? I've understood that it's going to be called 8.0 if gl3 makes it, as it seems to be the case
<tjaalton> bryceh: oh you got the doc already? :)
<tjaalton> Sarvatt: meh
<bryceh> tjaalton, from today's call, sort of sounded like they were of the mind it wasn't making it, and so I'm gathering there would be a .12 and an 8.0.
<bryceh> however, the usual folks weren't on the call (worn out from XDC?) so suspect I was getting info 2nd hand
<tjaalton> ok
<tjaalton> I trust phoronix more! :)
<bryceh> heh
<tjaalton> http://www.phoronix.com/scan.php?page=news_item&px=OTkxMg
<bryceh> then mesa 7.12 will include Steam support and be Wayland based
<tjaalton> awesome
<bryceh> yeah I was there for Ian's talk.  I got the impression that they were setting as a goal that they'd have gl 3 by the end of the year, but that it was a very optimistic goal
<bryceh> whereas on the call it today they sounded like a more pragmatic conservative guess
<tjaalton> so lets be very optimistic about it :)
<bryceh> today?  yes guess it's still today for 15 minutes
<RAOF> It's today for at least another 9 hours!
<bryceh> we're running short on today here in the US
<RAOF> Man, your economic problems never end, do they? :)
<tjaalton> :)
<bryceh> not until the rapture anyway
<tjaalton> looks like airlied has been quietly doing x redesign work on his xserver repo
<RAOF> Cool.
<tjaalton> http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvmodelv2-wip
<tjaalton> -2/+39964 :) (the first commit)
<RAOF> Sounds about right.
<tjaalton> though looks like it's mostly copying stuff under drv/
<RAOF> That looks like it's further along than I thought, actually.
<tjaalton> was he at xdc?
<RAOF> No.
<bryceh> nope
<bryceh> was surprising how few intel and redhat guys there were
<RAOF> It would have been interesting to hear what he had to say, if he was :)
<tjaalton> ok, so the redesign work was just briefly mentioned (judging from the phoronix notes)?
<RAOF> Not even that, really?
<RAOF> Oh, it might have been during the merge-the-drivers discussion.
<tjaalton> jameys 'codebase of the future' according to phoronix
<bryceh> mm, think that was the first talk
<bryceh> things felt a bit chaotic that first morning
<tjaalton> why was that? :)
<bryceh> couple of the speakers hadn't arrived yet
<bryceh> was kinda crazy how many people there had projector troubles
<bryceh> I mean, at the _X_ conference
<bryceh> lotta people didn't bother with slides anyway
<RAOF> More troubles than at plumbers!
<tjaalton> RAOF: btw, push xorg-server :)
<RAOF> #$!@#
<RAOF> poolie can't get build-from-branch working fast enough for me.
<tjaalton> what's that?
<RAOF> Making the process of pushing the branch to alioth and the process of submitting a source package to the archive the same thing.
<RAOF> ie: tag the push, and Launchpad builds your package.
<tjaalton> oh, found the proposal
<RAOF> The finest way of ensuring I don't upload without pushing is to make pushes the way to upload :)
<tjaalton> sounds good
<bryceh> of course, we could just stop using git ;-) ;-)
<tjaalton> meh :)
<RAOF> I could still fail to push with bzr :P
<tjaalton> and i'd fail using it outright
<bryceh> I have to admit, I got rather confused yesterday working on -wacom to find there isn't a ubuntu branch anywhere (at least that I could find)
<tjaalton> there isn't?
<bryceh> tjaalton, ^ aha that's one of the things I wanted to ask you yesterday
<tjaalton> should be
<tjaalton> oh oh
<bryceh> didn't find it
<tjaalton> ther is, but it's on my personal repo
<tjaalton> but writable by pkg-xorg
<tjaalton> since there is no pkg-xorg repo for it
<RAOF> Yay!  The compiz staged in the Desktop PPA has a working alt-tab switcher!
<tjaalton> changed in which way?
<tjaalton> bryceh: git+ssh://git.debian.org/git/users/tjaalton-guest/xf86-input-wacom.git
<tjaalton> add bryceh-guest@ to be able to push too
<RAOF> tjaalton: Changed in that when alt-tabbing to a group of terminals (a) he focus is returned to the last-focused window, and (b) the focused window is raised on top.
<bryceh> tjaalton, https://bugs.launchpad.net/ubuntu/oneiric/+source/xf86-input-wacom/+bug/787781 has the patch; feel free to add if you want...  I'm waiting for someone to validate the ppa.
<ubot4> Launchpad bug 787781 in xf86-input-wacom (Ubuntu Oneiric) (and 3 other projects) "Touch screen does not work with single finger touch, Lenovo x220 tablet (affects: 4) (heat: 28)" [High,In progress]
<tjaalton> bryceh: ok
<bryceh> but I'm like 99% sure it's the right fix
<bryceh> and you know a bryce 99% certainty is like 50% likely to be correct
<tjaalton> RAOF: ah, I switched to terminator due to bug 787465
<ubot4> Launchpad bug 787465 in gnome-terminal (Ubuntu) "View->Show MenuBar isn't working in 11.04 (affects: 13) (dups: 4) (heat: 59)" [Low,Triaged] https://launchpad.net/bugs/787465
<bryceh> terminator rocks
<tjaalton> session saving could be better, though the devel version seems to have fixed some issues
<tjaalton> current release is over a year old
<bryceh> what more is there to add?
<tjaalton> the issues with alt-tabbing etc forced me to use fullscreen windows, so terminator was a natural choice :)
<tjaalton> bryceh: it doesn't save the terminal size, though it's quick to fix
<tjaalton> i mean the sizes of the split terminals
<tjaalton> and it could remember the fullscreen state too :)
<bryceh> oh yes, that's certainly true
<bryceh> tjaalton, you should plan on going to XDC next year.  it'll be in europe (Ireland or Germany) so should be an easy trip for you.
<tjaalton> bryceh: yeah, I'll keep that in mind
<tjaalton> only real problem is getting someone to take the kids to school/daycare :)
<tjaalton> luckily my in-laws live quite close
<bryceh> yeah, was a bit of a challenge for me and my wife last week, but we got it sorted (also thanks to in-laws)
<bryceh> if it's 3 days like this time, you might be able to find a suitable flight on on Weds so it only occupies about half a week
<tjaalton> yeah, quite doable
<DeathWolf> hi all
<DeathWolf> is there any hope that anyone could backport 1.10 to lucid?
<tjaalton> DeathWolf: why?
<DeathWolf> 1.10 brings the massive composite & xinerama improvement... and not everyone(corp envs) can afford to move to natty
<tjaalton> don't know of any plans backporting it
<Sarvatt> guess its too late for multiarch libpciaccess?
<Sarvatt> tempted to shove it in x-updates at least so people can use i386 mesa on amd64 for wine and flash
<Sarvatt> (without using all of edgers craziness)
<bryceh> Sarvatt, yeah probably too late for oneiric
<bryceh> Sarvatt, putting it in x-updates might not be a bad idea; how well tested is it so far?
<Sarvatt> been using it for ~2 months now and it works fine
<Sarvatt> its just making it multiarch so the i386 version that libgl1-mesa-dri needs is installable
<Sarvatt> well libdrm-intel1:i386 is what really needs it
<bryceh> Sarvatt, ok yeah sounds fine for x-updates / oneiric
<bryceh> wouldn't put it in for x-updates / natty though
<Sarvatt> oh yeah of course
<Sarvatt> multiarch mesa on natty isnt *really* working even in edgers due to an apt bug that didnt get fixed in natty
<bryceh> bbiab (food time)
<jcristau> Sarvatt: pushed a m-a libpciaccess to debian now..
<Sarvatt> jcristau: awesome, thanks for that! is multiarch dpkg in debian yet?
<jcristau> no :(
<Sarvatt> argh, i was stupid and just updated debian on my NAS to wheezy, eglibc needs 2.6.26 so it's going to be fun fixing it :( can't update the kernel on this arm box and its at 2.6.24
<bladernr> Hi, can someone point me to where I can file bugs against mesa-utils that will be looked at and acted on?
<bladernr> specifically, glxgears and glxheads never exit with a 0 status, they always seem to dump fatal error messages to terminal on exit...
<jcristau> they only do that if you kill them afaict, not if you ask them nicely
<bladernr> how do you ask them nicely?  
<bladernr> closing them using window controls also causes this
<bladernr> as did every signal I tried :/
<jcristau> escape
<bladernr> hrmmm... head -> desk
<bladernr> so the problem is, we use this as a quick verification of 3d rendering during Ubuntu testing... and so checkbox (system testing) fires off glxgears automagically.  Typically, the user shuts the program down by closing the window (which makes perfect sense to me, hitting esc didn't occur to me)
<bladernr> any way to shut it down without hitting escape (was hoping to make the process a little more automated and a little more user friendly)
<bryceh> yeah
<bryceh> wmctrl -c glxgears
<bryceh> bladernr, see do_glx_loop in  xdiagnose/data/workloads/
<bladernr> bryceh:  that causes a fatal IP error message
<jcristau> you'd have to patch glxgears to listen to the event from the wm and shut down gracefully
<jcristau> not hard, just not something anyone's bothered with so far afaik
<bladernr> jcristau:  ugh... easier to just wrap it in some shell and ignore the exit status... at least for my purposes.  I was just looking for a cleaner way to do it
<bladernr> bryceh:  do_glx_loop also results in a fatal IO error for every loop that completes when glxgears closes
<bladernr> also, for the record, this is on Oneiric...
<bryceh> bladernr, right, thought you said you wanted a way to shut it down without hitting esc
<bladernr> ahhh... got it.  
<bryceh> like jcristau  says, glxgears is fairly primitive
<bladernr> out of curiosity, since mesa-utils got moved to universe, is there anything in main that you all would suggest as a basic 3d test?
<bladernr> using glxgears isn't set in stone or anything, it's just what's been used for a while.
<jcristau> i was going to say openarena, but that's not in main either :)
<bryceh> unity ;-)
<bryceh> no I don't know of any gl test code in main
<bryceh> bladernr, really I would suggest looking at piglit (which isn't packaged yet, have to pull from git), or phoronix (which is packaged, but kinda weirdly; it downloads the workloads via the internet)
<bryceh> I've also asked the Dx folks to produce a Unity/Compiz stress test we could use, but haven't heard status on that in some time
<bladernr> bryceh:  yeah... I actually wouldn't be against running Phoronix, except that it's not in main either (this is for Ubuntu Friendly, primarily) and the goal is that users won't have to install extra things to do basic testing...
<bladernr> bryceh:  that and it seems that I can't run Phoronix without having to download an additional 500MB of stuff ;-)
<bryceh> phoronix includes a test script that will run openarena in automated mode for instance
<bryceh> yeah :-/
<bladernr> heh... I non-graphics related, but I installed Phoronix's "CPU" suite, and it pulled down nearly 2GB of extra stuff on a fresh Oneiric + Phoronix 3.4.0 install
<bryceh> bladernr, problem is I think goal of main is to stick with just must-have bits such as would go onto the CD, and anything test-ish typically would be superfluous for anyone but us ;-)
<bladernr> yeah, and that's the balance :)
<bladernr> checkbox is in main, but everything we'd like to have is elsewhere :/
<bladernr> oh well, that's part of the fun, I guess... ok, thanks everyone, gonna work on this some more
<bryceh> bladernr, can you give me a bit more info about what you're trying to put together?
<bryceh> bladernr, the xdiagnose/data/workloads stuff I'm putting together might fit your needs
<bladernr> bryceh:  historically, we've had a VERY basic test in checkbox that just validates that 3d rendering is there and works... 
<bladernr> bryceh:  so until this point, that has simply been running glxgears and asking the user if they saw the pretty moving gears.
<bryceh> bladernr, mm, did it turn up many useful bugs?
<bladernr> it's not stress or benchmark testing by any stretch...
<bladernr> bryceh:  honestly, not that I'm aware of... but it's more a validation test than a bug search... 
<bladernr> heh... it's also been there far longer than I have been, but yes, it's actual value is questionable
<bryceh> well it certainly can't hurt; it at least verifies the gl libs are loaded properly and such
<bryceh> I mean, aside from it being in universe
<Sarvatt> glxgears probably isnt the best of tests anyway considering it'll run happily if there's no accelerated 3D
<bryceh> bladernr, have you looked at /usr/lib/nux/unity_support_test ?  You definitely should be running that, whatever you do
<bryceh> it doesn't display any graphics but it's an important test for validating that the machine will be able to run unity
<Sarvatt> how about /usr/lib/nux/unity_support_test -p
<bryceh> so more important than glxgears
<bryceh> right, with -p
<Sarvatt> err bryce beat me to it while i was looking up where it was stored
<Sarvatt> hah
<bladernr> bryceh:  actually, not at the moment, but I'll add it on the list of things to include for next cycle.  We do have a basic test that came from Natty that checks dbus to verify Unity is running and then ran /usr/lib/unity/autopilot
<bladernr> that was when you could assume that if Unity was running, you were 3d capable 
<Sarvatt> well unity-support-test would work if someone could run unity but decided not to
<bryceh> and would give clues as to why unity wasn't running, if it wasn't
<bryceh> plus it's in main already ;-)
<bladernr> indeed... I just filed a bug to include that in testing...
<bladernr> one of the things we're going to be discussing at UDS is beefing up the graphics testing in Checkbox (at least for now, the plan is to discuss this at UDS)
<bladernr> so if you're at UDS and have free time, feel free to come make suggestions.  Actual graphics testing right now is admittedly pretty weak, and we want to change that
<bryceh> bladernr, heh
<Sarvatt> bladernr: 10 bucks says its schedule the same time as one of the few X talks, thats how it always works out..
<bryceh> bladernr, I think there hasn't been a UDS yet that we didn't have this talk.  It's a tradition!
<bladernr> bryceh:  yeah, but this time under new management ;-) (and I think I've sat in on this talk at the last three UDSs)
<bryceh> bladernr, what my plans are is to build up xdiagnose into an X testing tool that we maintain here on the X side, and fill with yummy bits; it's in main and I'll try to make it reasonably easy to repurpose for automated or interactive testing
<bladernr> bryceh:  that would be awesome
#ubuntu-x 2011-09-23
<bryceh> Sarvatt apparently likes industrial music
 * Sarvatt wonders how you know :)
<bryceh> Sarvatt, new facebook feature apparently: spy on Sarvatt's music feed
<Sarvatt> oh great, new spotify update spamming facebook probably :)
<bryceh> http://www.bryceharrington.org/files/Screenshot-Facebook%20-%20Mozilla%20Firefox.png
<Sarvatt> oh i dont even see that bar on the right in chrome
#ubuntu-x 2011-09-24
<bjsnider> no more tearing in gnome-shell after the 3.1.92 update
<hm> hello everyone 
<hm> I have a question 
<hm> please
<hm> someone can help me please please
<hm> I m running on this laptop the kernel 2.6.35, and everything work great, including 3D aceleration and efects, but when I select from the GRUB the new 2.6.38 just the screen is turning BLACK and the OS start with black screen
<hm> my videocard is the Intel mobile 4 series (915) family
<soreau> Does it work if you boot with nomodeset?
<hm> Hi soreau
<hm> how can do it ?
<soreau> hi
<soreau> /msg ubottu nomodeset
<soreau> if you are in a channel ubottu is..
<hm> wait wait....hehe now I m confusing,...
<hm> should I type it from my console terminal ? isnt ?
<soreau> hm: You might also try asking in #intel-gfx
<soreau> nomodeset is a kernel parameter. /msg blah blah is something you type here on IRC
<hm> hmmm... I will try it
<shadeslayer> i was getting this last night : http://paste.kde.org/126601/
<soreau> <ubottu> A common kernel (boot)parameter is nomodeset, which is needed for some graphic cards that otherwise boot into a black screen or show corrupted splash screen. See http://ubuntuforums.org/showthread.php?t=1613132 on how to use this parameter
<shadeslayer> i was trying to boot kubuntu under EFI mode, with nomodeset and blacklisted the fglrx/radeon driver ( Macbook Pro 8,2 )
<shadeslayer> any ideas how to fix? ( I think i need to recompile my kernel with the dual channel lvds patch )
<soreau> shadeslayer: blacklisting fglrx is not enough
<shadeslayer> soreau: ok, what else?
<soreau> you need to uninstall it completely for radeon to work
<shadeslayer> no no, i don't want to power on discrete graphics :)
<soreau> alternatively, you can disable the intel chip if its an option in your bios
<shadeslayer> soreau: don't have a BIOS :P
<shadeslayer> Macbook's have EFI
<soreau> Oh mac
<shadeslayer> yep
<soreau> good luck with that then
<shadeslayer> heh :P
<shadeslayer> well, i've figured everything out, i get it to boot and everything, can't bring up X tho
<hm> I m reading that article that u posted soreau
<soreau> Good, because that is what its there for :P
<hm> and asking the same thing one the intel-gfx channel too
<hm> Soreau , are u still there ?
<soreau> nope
<hm> well, I just started on the OS using the nomode set from the grub
<hm> with the 3.0 kernel now
<hm> and it started with graphics
<hm> but
<hm> no acceleration
<hm> no compiz
<hm> no 3D
<hm> hello ?
<hm> what I should do now ?
<soreau> hm: You likely wont get 3D without kms
<soreau> but you can tell them what you've found in #intel-gfx
<soreau> show them the output of lspci|grep VGA
<soreau> give them dmesg from the failed session
<hm> yeah I got it
<soreau> and X log if you can get it
<hm> sadly...no one is answering on there 
<soreau> sadly, you havent asked anything yet..
<soreau> Are you sure your messages are reaching the channel? (is your nick registered?)
<soreau> because I can tell you the answer to the first question is no
<hm> if u can read me on here...well I suppose it work on there too
<soreau> Thats not always how it works. Some channels require your nick to be registered to speak
<soreau> due to spam and other reasons
<hm> aahhh ...ok
<hm> should I ask to the operator above on that issue ?
<soreau> operator above?
<soreau> you dont have to say a prayer.. just use a registered nick :P
<soreau> <ubottu> Information about registering your nickname: https://help.ubuntu.com/community/InternetRelayChat/Registration - Type Â« /nick <nickname> Â» to select your nickname. Registration help available by typing /join #freenode
<hm> well assuming all these last issues with this OS, I ve to be very religious to make to work that :-)
<soreau> Man, why is ubottu not in this channel
<soreau> hm: heh, maybe it will help after all ;)
<hm> hehe
<mdeslaur> any known workaround for bug 858450 ?
<mdeslaur> LP #858450
<mdeslaur> did the bot die?
#ubuntu-x 2012-09-17
<mlankhorst> morning
<mlankhorst> blegh took today off but still need to make the presentation, sigh :P
<tjaalton> xdc starts tomorrow?
<mlankhorst> nah day after that, but tomorrow I have other stuff to worry about :-)
<mlankhorst> tjaalton: but can you upload the xorg server now then?
<tjaalton> yes
<tjaalton> finishing up mesa first
<tjaalton> had to do some branch twiddling to get in sync with the 9.0 branch
<mlankhorst> oh right the going backwards thing
<tjaalton> right
<tjaalton> guess I merged from master on aug 31st when the branch was already created, or it got branched from an earlier commit
<smartboyhw> Hi bryceh:)
<mlankhorst> hey
<smartboyhw> Hello mlankhorst:)
<mlankhorst> hello :)
<smartboyhw> lol
<tjaalton> meh, uploads are cheap..
<smartboyhw> lol
<mlankhorst> tjaalton: yeah but you could at least test if quilt push -a worked ;)
<tjaalton> mlankhorst: ..after messing with the patch that used to work, yeah
<mlankhorst> it's a lot easier to say it if you don't actually have push rights *ducks*
<tjaalton> :)
<tjaalton> libglu accepted
<mlankhorst> intel 20.8 out too
<ricotz> tjaalton, hi
<ricotz> tjaalton, would you mind taking a look at libwacom 0.6 and update it?
<tjaalton> ricotz: yeah, need to check with the desktop guys if it's ok to update
<tjaalton> mlankhorst: true
<ricotz> tjaalton, thanks
<mlankhorst> tjaalton: Well the first real push I' ll be doing when I get push rights would probably break at least a fraction of the machines out there ;)
<tjaalton> mlankhorst: and what would that be?-)
<mlankhorst> tjaalton: I don' t know yet, but likely going to be the case :p
#ubuntu-x 2012-09-18
<hrw> http://tygrysek.juszkiewicz.com.pl/~hrw/shots/dualscreen1.jpg - is it normal that I cannot set right monitor to start at 1080,0 when left one is rotated?
<tjaalton> so, if -intel is built with --enable-sna, is it the default then?
<tjaalton> since that's what we've inherited from experimental
<tjaalton> doesn't look like that
<jcristau> iirc no
<jcristau> --enable-sna just means you can set accelmethod
<tjaalton> yeah, still needs the config option
<hrw> can someone answer my xrandr related question?
<tjaalton> hrw: no idea
<tjaalton> don't see why it shouldn't work
<hrw> played directly with xrandr command - have to report bug in kde now
<tjaalton> ah
<tjaalton> mlankhorst: http://www.x.org/wiki/Events/XDC2012/XDC2012AbstractMaartenLankhorst doesn't exist yet, fix it! :)
<ricotz> tseliot, hi, what is the deal with nvidia-graphics-drivers-experimental?
<tjaalton> should be removed, and renamed to something else
<tjaalton> don't know the details
<ricotz> i see, there is still nvidia-settings-experimental
<tjaalton> ah
<tjaalton> just a mistake I think
<ricotz> ok
<ricotz> tjaalton, i hope libwacom isnt blocked yet :)
<ricotz> it isn't really an argument but g-s-d/g-c-c 3.5.92 requires it (they won't be in quantal)
<tjaalton> ricotz: mind filing a ffe for it?-)
<tjaalton> it's already in git since early july
<tjaalton> didrocks promised to prepare the other uploads if it's passed
<ricotz> tjaalton, can you push it experimental, so it can be synced?
<tjaalton> no
<tjaalton> oh wait
<tjaalton> I can..
<ricotz> which other uploads?
<tjaalton> g-s-d & g-c-c
<tjaalton> soname bump, they need to be rebuilt
<ricotz> oh
<tjaalton> anyway, if it needs to go via -proposed a sync won't do
<ricotz> there was no soname bump
<tjaalton> "Bump soname, no additions this cycle but we should've done this in libwacom"
<ricotz> /usr/lib/x86_64-linux-gnu/libwacom.so
<ricotz> /usr/lib/x86_64-linux-gnu/libwacom.so.2
<ricotz> /usr/lib/x86_64-linux-gnu/libwacom.so.2.1.0
<tjaalton> ..0.5"
<ricotz> this is 0.6 ^
<tjaalton> +LIBWACOM_LT_VERSION=3:0:1
<ricotz> hmm, i took the 0.6 tarball from sf
<ricotz> https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2651595/+listing-archive-extra
<ricotz> http://sourceforge.net/projects/linuxwacom/files/libwacom/
<ricotz> tjaalton, dont mistake this, the age got bumped too : C+1:0:A+1
<ricotz> "- If interfaces have been changed or added, but binary compatibility has been preserved, change to C+1:0:A+1"
<tjaalton> yeah
<tjaalton> so no rebuilds needed after all
<ricotz> so please push it to exp
<tjaalton> what's the point?
<tjaalton> is gnome 3.6 in experimental?
<ricotz> i think syncing it would be nicer
<tjaalton> doesn't matter
<ricotz> ok
<tjaalton> would need another upload to get it in unstable
<tjaalton> but don't dare to push it there
<ricotz> yeah, that is why i am suggesting exp, but do as you want :)
<tjaalton> if it was useful in exp then yes, but don't think it would be
<ricotz> alright
<tseliot> ricotz: we're gonna package experimental releases of the Nvidia driver. We won't be using the -experimental flavour like that though. We'll use something like nvidia-experimental-403, etc.
<ricotz> tseliot, i see, but it looks broken, there is no transition for e.g. nvidia-settings
<tseliot> ricotz: wasn't that package removed?
<ricotz> meaning you can install both nvidia-settings and nvidia-settings-experimental
<ricotz> not yet
<tseliot> ricotz: ok, we'll do it soon
<ricotz> i pinged infinity in -dev
<ricotz> but i guess he is ignoring non-canonical ;)
<tjaalton> he's also asleep
<ricotz> i see
<mlankhorst> mupuf: i will probably go by car after all
<mlankhorst> faster from here
<tjaalton> wrong channel? :)
<agrestringere> Got a quick question something seems strange with my Nvidia drivers X-SWAT 304.43...Nvidia Settings lists my card as having 256mb but when I run 'nvidia-smi --query --display=memory' it only reports 127mb Total, 67mb used, 60mb free, I don't get it... 
#ubuntu-x 2012-09-19
<stgraber> heya. A friend of mine just got a new DELL Latitude E6330 with an i7-3520M (ivy bridge). Running on 12.04 with the embedded HD4000 he'd get frequent full system locks (looks like bug 1030643), easily triggered when opening chrome. I know got him on the q-lts-backport PPA and that seem to have solved it. Anything I can try and get so we can have this fixed in 12.04's kernel/X?
<ubottu> Launchpad bug 1030643 in linux (Ubuntu) "Complete system freeze" [Medium,Incomplete] https://launchpad.net/bugs/1030643
<stgraber> I already asked him to try without an external monitor (instead of LVDS + VGA) and to try booting the old kernel with the new X stack
<tjaalton> stgraber: does he have all the updates?
<stgraber> yep, it was on a fully up to date 12.04 system. I believe he also tried the kernel currently in -proposed.
<tjaalton> then it would need bisecting the kernel. ivb is stable for me, but it's a desktop with just one monitor and no chrome
<tjaalton> 3.4 would probably be stable like for others
<stgraber> tjaalton: ok. I'll suggest he first checks that it's still failing when running the current precise 3.2 with the updated X stack (it really should), then go through the kernel mainline builds to confirm that a clean 3.2 has the same issue, then go up until we find a kernel that doesn't have the bug
<stgraber> that should then be giving a start and end point to whoever wants to actually do the bisect to figure out the exact commit
<tjaalton> stgraber: there are a number of commits from 3.3/3.4 backported to 3.2, so the mainlines can be buggy :)
<tjaalton> i'd suggest to start from 3.4-rc1, and if that's stable, bisect comparing with 3.3
<tjaalton> too bad that rc1 had around 150 commits to drm/i915..
<stgraber> ok
<bryceh> MIR for adding s2tc to main:  https://bugs.launchpad.net/ubuntu/+source/s2tc/+bug/1053065
<ubottu> Launchpad bug 1053065 in s2tc (Ubuntu) "MIR for s2tc, required by various games" [Undecided,New]
<bryceh> bug for adding s2tc recommends to mesa:  https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1053029
<ubottu> Launchpad bug 1053029 in mesa (Ubuntu) "Please add dependency on libtxc-dxtn-s2tc0, required by various games" [High,In progress]
<bryceh> Uploaded to quantal as mesa_9.0~git20120917.7cfd42ce-0ubuntu2; should show up on the component mismatches page shortly.
<tjaalton> cool
<bryceh> dunno if it can be sru'd
#ubuntu-x 2012-09-20
<bryceh> hmm, question
<bryceh> we have mesa 9.x in the mesa9 ppa
<bryceh> for precise
<bryceh> can we just do the same change to make that mesa Recommends on s2tc and have that get pulled in from precise's universe?
<bryceh> or would that ppa mesa need s2tc to be in main as well?
<RAOF> That'll work fine.
<RAOF> The main-must-be-closed-under-transitive-dependencies rule is just policy.
<bryceh> ok, suspected so
<bryceh> RAOF, so if the user has only main enabled, and installs this ppa, they'll get prompted to enable universe or some such automatically?
<RAOF> Hm. No, they won't.
<RAOF> How many people don't have universe enabled? It's been enabled by default for a while, right?
<bryceh> I suppose we could just stick s2tc into the ppa
<RAOF> That would also work.
<bryceh> no clue
<bryceh> ok anyway, fixable problem.
<tjaalton> i guess torchlight needs s2tc, resolution got changed to 720x400 but the game didn't start
<tjaalton> on ivb
<tjaalton> nope, still crashes
 * bryceh eod's
<tjaalton> RAOF: so, are we getting a newer ati snapshot? this would probably be the last time to decide :)
<RAOF> We should.
<RAOF> We'll need an extra Xserver patch to prevent my laptop from crashing on startup, though :)
<tjaalton> heh
<tjaalton> for hybrid?
<RAOF> Yeah. airlied's âdon't crash if there's a GPU with no outputs hooked upâ patch.
<tjaalton> ok
<RAOF> I've been happily tootling along, playing Civ V on the ATI card in this laptop.
<RAOF> It's worth a snapshot.
<tjaalton> cool
<tjaalton> hmm, thinking about sna again..
<tjaalton> we get these gpu lockups with uxa only, and little hope in getting them fixed
<RAOF> Oh, really? Urgh.
<RAOF> IIRC sna doesn't have the prime stuff hooked up :)
<tjaalton> it does
<tjaalton> 2.20.8 should have it
<tjaalton> need to check..
<tjaalton> yes
<tjaalton> df68723baae71 and some fixes later on
<RAOF> Ah, cool.
<RAOF> Would you like me to do the -ati snapshot, or shall youL?
<tjaalton> please, you've at least tested it :)
<RAOF> I guess you'd also like me to do the accompanying Xserver upload too, then :)
<tjaalton> heh, yeah
 * RAOF files the FFe
<tjaalton> i've been too lazy to do those
<tjaalton> but since -ati is crazy it's probably best
<RAOF> ...slowly, because I have the baby.
<tjaalton> take your time :)
<mlankhorst> morning
<tjaalton> how's xdc so far?
<tjaalton> RAOF: is bug 1043458 something related?
<ubottu> Launchpad bug 1043458 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in SetCompatOutput()" [Medium,New] https://launchpad.net/bugs/1043458
<tjaalton> intel/ati hybrid
<RAOF> Yes; that's what needs fixing
<RAOF> Did I submit that?
<tjaalton> no, I just see some dupes
<RAOF> Oh! Modesetting!
<RAOF> You so crazy
<tjaalton> oh, indeed
<tjaalton> five dupes now
<RAOF> That's -ati bailing out because the GPU doesn't have any outputs, then modesetting helpfully saying "I can drive that!", and running into the X server bug :)
<tjaalton> how helpful :)
<tjaalton> RAOF: I can push the fixes to xserver for you unless you've started already
<mlankhorst> wow, can't remember my gpg key passphrase, sigh!
<jcristau> what did you drink last night? :)
<mlankhorst> I blame not being at home and not consciously remembering my password
<tjaalton> phoronix beer, obviously
<mlankhorst> hm, seems mesa is broken in my ppa
<tjaalton> RAOF: I'm adding the patch for dynamic gpu poweroff too, would be fun to test how that works
<tjaalton> also, having numbers in these patches is silly
<ricotz> tjaalton, how did you got this funky patch? ;) http://launchpadlibrarian.net/116696132/mesa_9.0~git20120917.7cfd42ce-0ubuntu2_9.0~git20120917.7cfd42ce-0ubuntu3.diff.gz
<tjaalton> wth?
<tjaalton> sigh
<ricotz> is contains quite some xml/html stuff
<ricotz> it might still apply though
<tjaalton> oh it applies and builds
<tjaalton> just looks ugly
<tjaalton> oh yes, used the link, should've opened it and select plain
<tjaalton> and pushed git too, can reset the clock back :)
<tjaalton> had a gpu hang on my ivb, everything looks otherwise fine but fonts in t-bird are funky
<mlankhorst> can someone upload mesa again to the q backports ppa?
<tjaalton> what's wrong there?
<mlankhorst> i was missing llvm-3.1 and recent enough wayland to build it :-)
<tjaalton> ok
<mlankhorst> if it rejects bump version number to ppa4.1
<tjaalton> don't have the script to mangle it ;)
<mlankhorst> update xorg-pkg-tools
<mlankhorst> go to mesa directory and run xorg-pkg-tools/lts-pkg-rename
<tjaalton> i should probably have that checked out
<mlankhorst> yeah need it updated :-)
<tjaalton> what's the lp repo?
<mlankhorst> ppa:ubuntu-x-swat/q-lts-backport
<tjaalton> no for the tools
<tjaalton> can't find them
<tjaalton> here
<mlankhorst> it's in edgers
<mlankhorst> https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
<tjaalton> really?
<mlankhorst> have you updated it?
<tjaalton> sounds like the wrong place for it
<tjaalton> no
<tjaalton> I don't have it at all on this machine
<mlankhorst> just check out that branch and it's in there
<tjaalton> uploading
<mlankhorst> thanks :)
<mlankhorst> seems I lost connection to my machien at home
<mlankhorst> can you do xorg-server 1.13 too to pick up that autobind patch?
<tjaalton> just uploaded more hybrid goodies
<mlankhorst> ah k
<tjaalton> so you got those as well
<tjaalton> uploaded
<mlankhorst> perfect, less chance of things exploding tomorrow then
<tjaalton> oh right :)
<tjaalton> how has it been so far?
<mlankhorst> good, met all the people I've been collaborating with except airlied
<tjaalton> he's not there?
<mlankhorst> sadly not :(
<tjaalton> ok
<mlankhorst> hm looks like the control files are generated wrongly
<tjaalton> both?
<mlankhorst> yeah it was before but I didn't notice it yet
<tjaalton> what's wrong there?
<mlankhorst> it handles conflicts/replaces/provides wrongly when it's all on 1 line, it seems
<tjaalton> right
<mlankhorst> I'll fix it next week, guess it's better to butcher my local install for now
<MestreLion> Is there any way to override the EDID of a given display?
<bjsnider> that's a strange thing to want to do unless the chip is not working
<MestreLion> bjsnider: it was poorly programmed... 
<MestreLion> it says 50Hz is the prefered for all reasolutions
<jwi> MestreLion: Documentation/EDID/* in a kernel tree
<bjsnider> modelines in xorg.conf might work
<MestreLion> so whenever I go to/back from fullscreen, it goes back to 50Hz, and I have to use Catalyst to put it back to 60Hz
<bjsnider> the nvidia blob lets you use an external edid file
<MestreLion> bjsnider: but I need to *remove* the modelines, not include them... how?
<bjsnider> yeah but why not just include the correct modelines?
<MestreLion> the correct modelines are there... they are just not the default
<MestreLion> and the default is used in all games when switching to and from fullscreen
<MestreLion> very few apps allow me to set the frequency... most only deal with resolution... and TV goes to 50Hz
#ubuntu-x 2012-09-21
<tjaalton> quiet
<mlankhorst> tjaalton: I seem to no longer get nouveau correctly :/
<tjaalton> mlankhorst: what do you mean?
<mlankhorst> only intel shows up in xrandr --listproviers
<mlankhorst> +d
<tjaalton> does downgrading xserver fix it?
<mlankhorst> just upgraded to quantal so i don't have the old debs
<tjaalton> I'll try it
<tjaalton> it's possible that the pci probing patch broke it
<tjaalton> in which case airlied would probably like to know about it :)
<mlankhorst> tjaalton: yeah downgrading fixed it
<tjaalton> shite
<tjaalton> hmm, could be the other patch too
<tjaalton> need to figure out which
<mlankhorst> I have to give a demo so I don't have the time right now :p
<tjaalton> sure thing
<tjaalton> I have the hw
<tjaalton> mlankhorst: you speaking?-)
<mlankhorst> yeah wanted to a demo
<tjaalton> no i mean answered keithp's question :)
<mlankhorst> yes :p
<tjaalton> thought so
<mlankhorst> 2013-3-5 next xorg release
<tjaalton> rc1 2012-12-05
<tjaalton> amd should get that :)
<tjaalton> abi/api stability
<tjaalton> well, not yet but when it's settled
<mlankhorst> nothing wrong with xorg 1.14rc1 being done at 2012-12-5
<mlankhorst> do we want it sooner/later?
<tjaalton> matt who?
<tjaalton> mlankhorst: no it's fine, if the features land by then
 * mlankhorst couldn't think of any objections either :)
<tjaalton> i mean, he said that the dates can be adjusted to make more room
<tjaalton> so once they're set we can inform amd that they should start preparing their fine driver..
<mlankhorst> yeah we might even get drivers stable in time for first rc1 o.O
<tjaalton> not the blobs :)
<tjaalton> fglrx will still take ~2-3 months, but at least well before release
<jcristau> bah.  ubuntu doesn't have locales-all?
<tjaalton> what's that?-)
<mlankhorst> ubuntu uses language-pack.* :p
<jcristau> precompiled locale data for all locales
<tjaalton> yeah they trigger building the locales that get installed
<jcristau> so you don't have to generate them one by one
<tjaalton> well, you need to install them one by one, and the trigger then builds them
<tjaalton> iirc
<tjaalton> hmm no
<tjaalton> language-pack-* install the translations
<tjaalton> and also triggers, but don't see why there couldn't be a 'locale-all' package too
<tjaalton> hmm, lts-pkg-rename seems to have removed the .orig.tar.gz
<tjaalton> mlankhorst: would probably be best to copy ${old_orig}, not move it
<tjaalton> heh, it's the fix for compat output selection that breaks optimus
<mlankhorst> tjaalton: it gets moved to a different directory before it does the stuff in lts-stack
<tjaalton> right, but if I run it on my dev tree it's weird that the tarballs are gone :)
<tjaalton> or links to them
<mlankhorst> yeah
<mlankhorst> but it's still a bit buggy it seems , I need to push fixes for it
<tjaalton> huh, tried prime for the first time and the server crashed :)
<jcristau> there he goes
<tjaalton> :)
<tjaalton> guess we see the slides better than the audience ;)
<mlankhorst> jcristau: it did crash too
<mlankhorst> had to reboot
<jcristau> i saw that :)
<jcristau> not completely unexpected i guess?
<mlankhorst> since I'm not running with the reservation stuff it kind of was, I didn't have the system lock up before
<jcristau> ah :/
<mlankhorst> but I suppose it's harmless
<jcristau> that's demo effect for you.
<mlankhorst> Yes!
<tjaalton> that was nice, it crashes earlier here
<tjaalton> mlankhorst: hmm, so what is the <sink-xid> for --setprovideroffloadsink? the id for intel?
<mlankhorst> tjaalton: you dont need it, the X server patch does it for you
<tjaalton> oh
<tjaalton> heh
<tjaalton> well now it crashed on glxinfo
<tjaalton> now the stream got unstable
<tjaalton> yeah I get a crash in DRI2Connect
<tjaalton> wonder if it's because acceleration is disabled on this one
<tjaalton> yep, enabling acceleration makes glxinfo work. glxgears hangs after a few seconds :)
<mlankhorst> yeah
 * mlankhorst needs to find an excuse to defuc nvd9 firmware
<tjaalton> you have the same?
<mlankhorst> as does darktama it seems
<mlankhorst> so we need to figure out what is different
<tjaalton> right
<tjaalton> oh we got the ati snapshot in
<mlankhorst> \o/
<tjaalton> you had a beer there! :)
<tjaalton> or some other suspicious beverage
<xnox> gtk or X or unity bug?
<xnox> bug 1047431
<ubottu> Launchpad bug 1047431 in gedit (Ubuntu) "gedit crashed with signal 5 in _XReply()" [Medium,Confirmed] https://launchpad.net/bugs/1047431
<xnox> wait.... last time i had such question it ended up being the kernel =)
<tjaalton> there was a gtk update, still get it with that? (3.5.18)
<xnox> tjaalton: yeah.
<mdeslaur> meh, since I've updated my thinkpad to quantal, I can't come back from the screensaver anymore
<tjaalton> mdeslaur: not using the sna acceleration with intel?
<mdeslaur> tjaalton: I don,t know what that means
<tjaalton> mdeslaur: probably not then :)
<tjaalton> can you change the vt?
<mdeslaur> tjaalton: yes
<tjaalton> ok, so it's probably bug 966744
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
<mdeslaur> tjaalton: and moving the mouse cursor over the place where the text entry box is supposed to be changes my mouse cursor to a text entry cursor
<tjaalton> mdeslaur: yeah, matches that bug
<mdeslaur> awesome
<mdeslaur> odd, because I wasn't getting the bug in precise
<tjaalton> and I've a hard time reproducing it on quantal :/
<tjaalton> used to hang like that after ~10 suspend cycles, now I can do 30 without the bug
<mdeslaur> so...-intel is busted, -nouveau doesn't work...what's the recommended chipset now? :)
<jcristau> works fine on debian *ducks*
<mdeslaur> lol
<tjaalton> mdeslaur: so can you reproduce it on every screensaver cycle?
<mdeslaur> tjaalton: the 3 cycles I've had so far, yes
<mdeslaur> tjaalton: but not if I manually start the screensaver or a dpms cycle
<mdeslaur> ie: it only happens when I don't touch my laptop for a half hour
<mdeslaur> I haven't figured out why yet
<tjaalton> mdeslaur: what chipset is it?
<mdeslaur> Arrandale
<mdeslaur> Ironlake Mobile?
<tjaalton> yeah
<tjaalton> gen5
<tjaalton> so, there are instructions on how to get a strace from compiz that should show what operation is getting stuck
<mdeslaur> oh, where?
<tjaalton> not convinced that the current straces are valid
<tjaalton> on the bug
<tjaalton> still haven't sent it upstream but if you could get one that looks sane..
<tjaalton> also, testing if sna acceleration is of any help probably wouldn't work, since I have issues getting the panel back up after the screensaver kicks in (just stays blank) :)
<tjaalton> though in your case it should hang with a suspend/resume cycle as well?
<mdeslaur> tjaalton: I can reproduce with comment #68 in that bug
<mdeslaur> tjaalton: disable suspend on lid close, close lid, open lid
<mdeslaur> hrm, not every time though
 * mdeslaur tries again
<tjaalton> mdeslaur: might also try with a mainline kernel
<tjaalton> latest 3.6-rc
<tjaalton> some have reported success with it
<mdeslaur> tjaalton: thanks, I'll try and find some time to try it
<tjaalton> the bug is getting out of hand.. almost 300 comments
<bryceh> tjaalton, thanks slashdot!
<mdeslaur> well, thanks buggy code :P
<bryceh> mdeslaur, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/966744/comments/154
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed]
<mdeslaur> bryceh: yeah, I've downloaded the script
<tjaalton> bryceh: slashdot?-)
<mdeslaur> bryceh: I'll give it a go next time it happens
<bryceh> tjaalton, posted yesterday
<tjaalton> oh.. checking it out
<tjaalton> heh, there it is
<tjaalton> http://linux.slashdot.org/story/12/09/20/1245240/stubborn-intel-graphics-bug-haunts-ubuntu-1204
<tjaalton> how useful..
<bryceh> oh wow NVIDIA publishing some GPU docs, heh
<tjaalton> yeah I was listening to the stream and was wondering if my hearing was ok
<tjaalton> but it's just tegra for now aiui
<tjaalton> btw we have the compiz strace's already
<tjaalton> -'
<tjaalton> the dstack
<tjaalton> meh, if it's fixed in 3.6rc it should be easy to backport
<tjaalton> mdeslaur: eow for me. if 3.6rc fixes it, feel free to leave a msg here or on the bug
<mdeslaur> tjaalton: sure, I'll try and test it this weekend
<tjaalton> thanks
<mdeslaur> tjaalton: have a nice weekend!
<tjaalton> you too, despite the bug ;)
<mdeslaur> hehe :)
<mlankhorst> bryceh: it's just phoronix trolling slashdot
<mlankhorst> >:P
<Sarvatt> mlankhorst: nice crash at the end :) just watched the youtube recording
<mlankhorst> :D
<mlankhorst> it's the demo effect
<mlankhorst> was working fine before but maybe the display clone caused a hard lockup or something
<mlankhorst> but yeah it's just ubuntu quantal with no patches \o/
<Sarvatt> mlankhorst: no patches, but selectively downgrading a few packages! \o/ :P
<mlankhorst> that's only because xorg-server regressed
<Sarvatt> dist-upgrading the day before a demo? crazy man :)
<Sarvatt> lucky unity even started, was a big upgrade at the same time
<mlankhorst> I knew the x server and kernel worked fine from testing on precise
<mlankhorst> Sarvatt: I had no choice though, no way I could fix the script and re-upload the entire x stack in time :(
<ricotz> hey :)
<ricotz> mlankhorst, i guess this is something to consider for the backports stack - https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1054292
<ubottu> Launchpad bug 1054292 in initramfs-tools (Ubuntu) "[xorg-edgers] hid_generic module missing from initramfs" [Undecided,New]
<Saviq> hey, I'd like to point to a smbd bug I've encountered on quantal-backport: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1053414
<ubottu> Launchpad bug 1053414 in samba (Ubuntu) "smbd crashed when trying to connect from Ubuntu" [Undecided,New]
<Saviq> not sure how to mark it so that it doesn't get lost
#ubuntu-x 2012-09-22
<erappleman> mlankhorst, nice presentation. very informative.
<erappleman> should i mark bug 1050202 for freeze exemption?
<ubottu> Launchpad bug 1050202 in X.Org X server "Cherrypick xrandr list providers to complete DRI2 offloading graphics stack" [Medium,Confirmed] https://launchpad.net/bugs/1050202
<tjaalton> q
<tjaalton> ups
<mlankhorst> erappleman: ty :)
<mlankhorst> erappleman: yeah xrandr configuration would be nice
<mlankhorst> pretty much required too, found a bug in xserver that would have been impossible to find otherwise
<mlankhorst> I'm actually waiting for a xrandr 1.4.0 to be tagged though but it might be too far away
<erappleman> mlankhorst, it seemed you weren't satisfied with what landed (even before the crash). neither am i. too many list-only patches just to get everything working properly beyond just the proof of concept stuff that's landed.
<mlankhorst> it's still better than what we have in precise, though
<erappleman> but not enough to advertise. 13.04 will have the power management 3.7 kernel or newer, autoswitching x layer, and other goodies.
<mlankhorst> yeah
<mlankhorst> you could still use DRI_PRIME=1 to use offloading in applications if their card is supported, but it's too likely to break for real use :(
<erappleman> from my experience, all i get is a refusal to render or white polygons
<erappleman> glxinfo only works reliably
<mlankhorst> we might have to update the intel ddx
<erappleman> 2.20.8 isn't recent enough?
<erappleman> i'm using git
<erappleman> not much has changed
<mlankhorst> git should be ok
<erappleman> are you using uxa prime?
<mlankhorst> yeah but you're probably hitting the synchronization issue if you get white polygons
<mlankhorst> or maybe nouveau is buggy, which would be likely too
<erappleman> it's always the nouveau end of things for me. the ddx doesn't always load with x.
<mlankhorst> what xorg-server are you using?
<erappleman> git
<erappleman> err probably 1.13.0 branch git
<mlankhorst> oh, i think there was 1 of the commits causing a regression in ubuntu xorg-server
#ubuntu-x 2012-09-23
<dupondje> patches so that xrandr supports hybrid graphic cards didn't came in yet ?
<dupondje> they for 13.04 ?
<mlankhorst> it's all in, it's just the kernel support making it useless for now :P
<tjaalton> the xrandr snapshot isn't in quantal yet
<tjaalton> also missing additions to the manpage
<mlankhorst> yeah want to push 1.3.901?
<mlankhorst> or some snapshot at least
<tjaalton> right, maybe tomorrow
<dupondje> so tomorrow and with a daily kernel it should work ? :)
<tjaalton> no, the kernel support is lacking still
<dupondje> ah ok
<tjaalton> it's trivial to hang the machine when offloading to the discrete gpu
<AaronCampbell> I have an AMD ATI Radeon 6870 video card with 4 1680x1080 monitors attached.  It was working well with the proprietary drivers in 12.04.  I didn't upgrade to 12.10, I did a complete reinstall, and now it uses the open source driver but everything is REALLY laggy (dragging windows, switching desktops, etc, etc).
<AaronCampbell> If anyone has any ideas what I could try, or suggestions on what additional info would help, let me know.
<AaronCampbell> So far I know that if I set it to mirror the displays it works fine (no lag), but having it act like 1 big desktop breaks it
<AaronCampbell> (well, it works, but the lag is really hard to deal with)
<AaronCampbell> My /var/log/Xorg.0.log - http://pastebin.com/i1RiJnHi
#ubuntu-x 2013-09-17
<jcristau> RAOF: +axserver-xorg-video-ati (1:7.2.0-0ubuntu5) saucy; urgency=low
<jcristau> there's a stray 'a' in the beginning :)
<RAOF> Yeah, that was actually *not* xserver-xorg-video-ati.
<RAOF> Hence the âaâ prefix ;)
#ubuntu-x 2013-09-19
<RAOF> tjaalton: glamor's through NEW now; do you want to do the DDX rebuild?
<Prf_Jakob> Howdy people
<Prf_Jakob> it looks like you guys have the wrong pm-quirk for SVGA, yeilding to suspend hanging the device.
<Prf_Jakob> is this the right place to get that changed or is there a better channel for that?
<Prf_Jakob> http://paste.ubuntu.com/6128545/
<tjaalton> RAOF: ooh
<tjaalton> RAOF: I can yeah
<tjaalton> RAOF: or do you have xmir updates lined up?
<tjaalton> I don't have hw to test it on, but meh
<RAOF> tjaalton: There's a radeon *bug* to fix, but not yet a radeon bug fix âº
<tjaalton> could get something next week
<tjaalton> RAOF: ahh, ok
<tjaalton> which one to do first, MIR for glamor-egl or the rebuild that'll get stuck in the queue
<RAOF> tjaalton: I'm at the QA lab and we've got all the SIs. Ping robotfuel if you want testing :)
<RAOF> tjaalton: Eh, either. Rebuild that gets stuck in the queue adds a nice extra sense of urgency, though ;)
<tjaalton> good point :)
<tjaalton> finally got my mirror in sync, now testing the build..
<tjaalton> pushed to git for now
<tjaalton> built fine
<tjaalton> and pushed to saucy
#ubuntu-x 2013-09-20
<tjaalton> robotfuel: yo, radeon ready for testing on saucy-proposed, so if you have HD7xxx around it would be nice to know how broken it is :)
<tjaalton> err, -ati that is
<robotfuel> tjaalton: so add -proposed apt-get update and install xserver-xorg-video-radeon?
<robotfuel> tjaalton: or do I need more than xserver-xorg-video-radeon?
<tjaalton> robotfuel: it should pull the glamor bits
<tjaalton> so yeah, that's enough
<tjaalton> "glamor: require 0.5.1 or newer"
<tjaalton> so it finally got a new release..
<tjaalton> time to update it then
<tjaalton> this was the latest commit to ati upstream git..
<tjaalton> guess we want the changes post 7.2.0
<tjaalton> especially fa83d3d1636c31
<tjaalton> radeon: disallow glamor on pre-R600 asics
<tjaalton> ehh, 0.5.1 was what I uploaded, so that's good
<tjaalton> hmm I wonder if the driver needs to ship an xorg.conf snippet to enable glamor
<RAOF> tjaalton: I don't believe so, no.
<tjaalton> okay
<RAOF> tjaalton: Yup. We've got 33d8408eec806355c2e55726679ec50ef3b769f1, which enables glamor by default on SI
<RAOF> s/enables/initialises/
<tjaalton> ahh, indeed
<robotfuel> tjaalton: my radeon hd7850 has no 3d acceleration with glamor installed, openarena is getting 9 fps @ 800x600
<RAOF> tjaalton: Bah!
<RAOF> tjaalton: We *do* need an xorg.conf snippet to load glamouregl
<tjaalton> right..
<RAOF> Hm, well, we do, but it doesn't load glamoregl because /usr/lib/x86-64_linux_gnu/xorg/modules isn't in the module search path.
<RAOF> /usr/lib/x86-64_linux_gnu/xorg/extra-modules *is*
<tjaalton> gah
<RAOF> Time to add that path to xserver :)
<RAOF> Alternatively, to install in /usr/lib/xorg/modules, because it's only ever going to be the same arch as the xserver.
<tjaalton> yeah
<tjaalton> the latter is more sane
<RAOF> Indeed.
<tjaalton> ok fixed locally, I'll merge it with the one upstream change and upload
<tjaalton> and looks like xserver-xorg-glamoregl ships a snippet itself :)
<tjaalton> Section "Module" Load  "dri2" Load  "glamoregl"
<tjaalton> EndSection
<tjaalton> plus formatting
<tjaalton> oh you mentioned that already
<robotfuel> tjaalton: it's working after I moved the glamor lib to /usr/lib/xorg/modules \o/
<tjaalton> robotfuel: yeah, figures. it'll get fixed in the next upload
<tjaalton> test build looks fine
<tjaalton> uh so I did upload 0.5.0
<tjaalton> not that it's much different from actual 0.5.1
<tjaalton> sh*t, I should really set EDITOR when doing stuff over ssh..
<tjaalton> mixed with sucky hotel wifi
<RAOF> :)
<tjaalton> ok, uploaded
#ubuntu-x 2013-09-21
<Dandel> I noticed the piglit daily build is not generating lately. I think the issue with it revolves around two things. (outdated headers, and an issue with how detection of strndup is handled )
#ubuntu-x 2014-09-15
<ricotz> Sarvatt, hi :), i thought you already had some local packaging changes for mesa
#ubuntu-x 2015-09-17
<Azelphur> Hoping someone can help with this one, I've upgraded to Ubuntu 15.04 and I can't copy and paste between X screens :(
<Azelphur> Hopefully someone can come up with a better solution than https://dpaste.de/6sRO >.<
#ubuntu-x 2016-09-20
<ricotz> tjaalton, hi, did you thought about doing a new intel-xorg-driver snapshot?
<tjaalton> ricotz: could happen, now that it's barely used anymore :)
<ricotz> tjaalton, I forced it here since some time ;)
<ricotz> I guess I should try glamour again
<ricotz> without it the resolution selection on my Intel Iris was broken
<ricotz> so if it is pretty safe to do, please go ahead and make a new one :)
<mamarley> My NUC has an Iris 540 and Glamour seems to work fine on that.
<mamarley> Unrelated, but Kernel 4.8 introduced a bug with my Skylake system at work, https://bugs.freedesktop.org/show_bug.cgi?id=97878
<ubottu> Freedesktop bug 97878 in DRM/Intel "[SKL][REGRESSION][BISECTED] Dropped frames and FIFO underruns when moving mouse across (plane?) boundary" [Normal,New]
<tjaalton> yeah watermark issues still, should be fixed soon
<tjaalton> ricotz: -intel is quite liberal in adding modes that the edid doesn't list
<tjaalton> mamarley: you should test nightly or drm-intel-next
<tjaalton> oh and it's glamor :)
<mamarley> tjaalton: You mean http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/ ?
<tjaalton> yes
<mamarley> OK, I will try that tomorrow when I get back to work.
<ricotz> tjaalton, I meant I forced to use the intel-xorg-driver to make it work again
<tjaalton> ricotz: I know
<ricotz> so I doubt it was a problem of an incomplete edid
<ricotz> but I havent switched it back since then, maybe it works now
<tjaalton> no it doesn't
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=97163
<ubottu> Freedesktop bug 97163 in Driver/modesetting "Modesetting driver rejects modes with vertical refresh above 60" [Normal,New]
<tjaalton> because of what I said
<ricotz> ah ok, thanks
#ubuntu-x 2016-09-21
<mamarley> tjaalton: Thanks for the recommendation.  I tried a drm-intel-next build and the problem does not occur anymore.
<tjaalton> cool, update the bug
<tjaalton> 4.8 will get the fixes later
<tjaalton> there's some regression still, but it'll get sorted
<mamarley> Already done.
<mamarley> I think I might switch to drm-intel-nightly though because drm-intel-next is still based on 4.8.0-rc2, while -nightly is on -rc7.
<mamarley> From looking through the commit log, https://cgit.freedesktop.org/drm-intel/commit/drivers/gpu/drm/i915?h=drm-intel-next&id=62e0fb880123c98793e5c3ba8355501b0305e92e jumps out as a likely candidate for which commit fixed the issue.
<tjaalton> it's not a single commit
<tjaalton> there's at least a 12 and a 7 patch series applied
<tjaalton> maybe some already in 4.8-rc
<tjaalton> sorry, it was v12 of a 7 patch series, plus another one
<tjaalton> and then maybe some
#ubuntu-x 2016-09-22
<vigo> Hi all, I just had an issue with graphics after waking up from suspend
<vigo> low graphic mode window appeared showing some errors and this is the output of dmesg: https://pastebin.canonical.com/166279/
<vigo> line 938, there is a hang and crash pointing to an error file stored that I pulled out
<vigo> worth a bug?
<vigo> tseliot, ping :)
<tjaalton> file upstream
<tjaalton> probably mesa
<tjaalton> and that gpu hang is well before you suspend
<tjaalton> sorry, you suspended the first time after 12s..
<vigo> thanks tjaalton :), so that crash wasn't triggered by suspend?  I pulled xorg logs will they show information about it?
<tseliot> well, dmesg says "GPU crash dump saved to /sys/class/drm/card0/error", so that should be enough
<vigo> I filed a bug with all the info 
<vigo> tseliot, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1626605
<ubottu> Launchpad bug 1626605 in xorg (Ubuntu) "xorg error when waking up after suspend in YY" [Undecided,New]
<tseliot> vigo: yes, as I suspected the X log is pretty useless, as the "EQ overflow" thing doesn't say much about the problem. The "error" file will probably be more of help. You might want to file an upstream bug report (as tjaalton recommended), and link it to the one on launchpad
<tseliot> vigo: make sure you attach dmesg, error file, and X log there (so that they can diagnose the problem).
<tjaalton> just file it upstream
<tjaalton> we can't do much
<tjaalton> an honest answer
<tjaalton> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
<vigo> tjaalton, tseliot thank you :)
<tjaalton> and the first thing upstream will ask is to run with drm-intel-nightly kernel, which you can find from http://kernel.ubuntu.com/~kernel-ppa/mainline/
<vigo> tjaalton, great, thank you all
#ubuntu-x 2016-09-24
<mamarley> ricotz: Do you know what's going on with this email we got about the Vulkan debug thing?  I checked, and as far as I can tell, we are packaging all the files that come with the driver.
<ricotz> mamarley, this has nothing to do with the nvidia packages
<mamarley> ricotz: Yeah, I didn't think so.
<ricotz> mamarley, those files are part of the vulkan package source, but not installed
#ubuntu-x 2017-09-19
<soee> someone tested nvidia drivers with kernel 4.14 ?
<soee> found some infos http://rglinuxtech.com/?cat=18
#ubuntu-x 2017-09-20
<ricotz> tseliot1, hi :), I assume 304.137 and 340.104 is already on your list?
<tseliot1> ricotz: yes
<tseliot1> ricotz: I was waiting for the public release
<ricotz> great
 * tseliot1 working on the legacy drivers now
<soee_> is there some noew version planned soon ? :)
<mamarley> soee_: A new version of what?
<soee_> mamarley: nvidia driver
<mamarley> New legacy drivers were just released.  Judging by the normal release schedule, I would also expect a new release of the latest branch sometime in the next couple of weeks.
<mamarley> (That's just a guess, I have no insider information from NVIDIA.)
<tseliot> ricotz, mamarley: I've just uploaded the new 304 and 340 in artful
<mamarley> tseliot: Awesome, I will test it later today.
<tseliot> thanks!
<mamarley> tseliot: It looks like NVIDIA made a booboo when they were updating kernel support in 340.104.  A stripped-down version of buildfix_kernel_4.11.patch is still required: https://paste.ubuntu.com/25580747/
<tseliot> mamarley: oh, I didn't test uvm. Thanks for finding out the failure. I'll fix it tomorrow
#ubuntu-x 2017-09-21
<tseliot> mamarley: I've just tested and uploaded the fix for 340. Thanks!
<mamarley> tseliot: Awesome, thanks!
<mamarley> soee_: You're sleeping on the job again: https://devtalk.nvidia.com/default/topic/1024243 ;P
#ubuntu-x 2017-09-22
<soee_> mamarley: will you build 384.90 ?
<mamarley> soee_: I already have, but for some reason NVIDIA has not (yet?) released the ARM build of the driver.  Due to limitations of how the PPA works, if I uploaded now without the ARM build, it wouldn't let me upload the same .orig.tar.gz later with the ARM build.
<soee_> mamarley: can you send me somehow amd64 builds ? :)
<mamarley> soee_: I guess I can put them in one of my alternate staging PPAs.  One secondâ¦
<mamarley> soee_: I just uploaded to https://launchpad.net/~mamarley/+archive/ubuntu/staging3/+packages.
<soee_> mamarley: cool, thanks. Now wait till they build
<mamarley> ricotz: ^If you want, you can go ahead and check these out too so you don't have to do it again after the ARM binaries are made available.  I did backport all the changes made to nvidia-375 in the main repository since the last time we did a release.
<soee_> mamarley: i wonder, why it shows status for Artful and Zesty anbd not for Xenial for example ?
<soee_> looks liek not Xenial build is available ;)
<mamarley> soee_: Status?  I'm not sure what you mean.
<soee_> mamarley: https://launchpad.net/~mamarley/+archive/ubuntu/staging3/+packages why no Xenial build ?
<mamarley> soee_: Because I screwed up and accidentally set the distribution to "artful" on what was supposed to be the Xenial upload, causing it to get overwritten by the actual Artful upload.  I fixed it.
<soee_> :D
<soee> Works fine https://i.imgur.com/5Z5QbHm.png and looks like screenlocker does not crash now on KDE
<ricotz> mamarley, noted -- looks like you are drowning in staging ppas?
<mamarley> ricotz: Haha, yes.  Staging is generally for NVIDIA stuff before it gets moved to the main PPA (but sometimes I use it for miscellaneous other stuff).  Staging2 is for packages compiled against OpenSSL 1.1.  Staging3 is for X-related stuff that I don't want to put in my regular PPA for some reason.  Staging4 was for Qt5.9 packages before Artful got that in the main repository, now it is pretty much unused.
#ubuntu-x 2018-09-17
<tjaalton> 04:01 < Moc> Who should I talk to regarding a packaging script error with Nvidia driver forcing a lot of user to 
<tjaalton>              use a old driver (340) rather than a newer one like 390 ?
<tjaalton> someone on #u-d
<tjaalton> left already
<alkisg> KitsuWhooa: I see flickering even in more recent graphics cards, and it goes away by switching resolution (and I would imagine with pageflip off as well)
<alkisg> Most recent example,  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
<alkisg> As usual, it only affects nvidia cards with nouveau driver
<KitsuWhooa> alkisg: interesting
#ubuntu-x 2018-09-19
<alkisg> KitsuWhooa: hi, so, any idea where should we report this? To nouveau upstream? To xorg? To ubuntu?
<KitsuWhooa> I'm still working on it
<alkisg> Ah great
<KitsuWhooa> bisecting goes from one bug to another
<alkisg> Btw I haven't heard of any instability issues with pageflip off, from a lot of schools
<alkisg> Haha
<KitsuWhooa> https://tasossah.com/s/126f55d9cdb3.jpg
<alkisg> Are you trying on tnt2 with the segfault, or on the other ones with the corruption?
<KitsuWhooa> tnt2
<KitsuWhooa> Looking at the code through gdb, the issue is probably somewhere in DIX. It's a bit of a maze
<alkisg> Hmm, well, even if you fix the real issue that is the segfault, you wouldn't fix the issue that exposed the segfault, i.e. the lack of initialization somewhere, right?
<KitsuWhooa> That is exactly what I am trying not to do
<KitsuWhooa> if I wanted to do that, I could add a check for a valid pointer, and if not return
<KitsuWhooa> but I doubt that would work
<KitsuWhooa> nouveau calls this https://cgit.freedesktop.org/xorg/xserver/tree/exa/exa.c#n66 and this returns an invalid pointer
<KitsuWhooa> and ExaPixmapPriv is a macro
<KitsuWhooa> which is here
<KitsuWhooa> https://cgit.freedesktop.org/xorg/xserver/tree/exa/exa_priv.h#n283
<KitsuWhooa> and this in turn calls DIX functions/macros
<alkisg> KitsuWhooa: would it be possible to do this? (1) dump vars (2) run xrandr 640x480; xrandr 1366x768; (3) dump vars
<alkisg> (1) would be different from (3) in the vars that are not initialized
<KitsuWhooa> not really
<KitsuWhooa> the function gets called multiple times
<alkisg> I'm not talking about the function
<alkisg> Suppose xorg somewhere has a variabled named, I dont know, other_page_resolution
<alkisg> And this in turn messes things up, and breaks where you see it, but you can't trace it back to the wrong initialization, 
<alkisg> so, since xrandr does initialize that internal xorg variable, wouldn't comparing before/after help locate the uninitialized var?
<KitsuWhooa> If it's an uninitialized variable, I can probably use valgrind to detect it
<KitsuWhooa> dumping every single variable would be very impractical, if not impossible
<alkisg> Well since 2 xrandr calls fix it, wouldn't that be the case?
<alkisg> I haven't programmed in C/assembly in recent days, but in the old days, I could dump the whole data/stack etc segments and compare
<alkisg> And then check the address in the linker to find the variable there...
 * alkisg googles about valgrind...
<KitsuWhooa> if you go low level like that, possibly
<KitsuWhooa> but due to the "refresh rate", you'd probably get a lot of false positives 
<alkisg> Wow, just as easy as "valigrind myprogram"? !
<KitsuWhooa> yup
<alkisg> That sounds too good!
<KitsuWhooa> I just switched to one of the cards that have just corruption
<KitsuWhooa> so let's see what valgrind says
<alkisg> Great
<KitsuWhooa> alkisg: does epoptes-client restart whenever a user logs in?
<alkisg> There are 2 epoptes-client processes. The system one and the session one. The session one starts on login, so yeah.
<KitsuWhooa> Because I found that if I kill the one running already and run it manually from a tty, it doesn't kill the remote sessions
<alkisg> You can't kill epoptes (to avoid students doing so),
<KitsuWhooa> from a root vt?
<alkisg> pkill -QUIT -U "$UID" -f '^epoptes-client$'
<alkisg> This sends it a QUIT signal, which it respects
<alkisg> Otherwise it restarts
<KitsuWhooa> I kill -9 its PID
<KitsuWhooa> oops
<KitsuWhooa> it doesn't restart for me
<alkisg> There's a timeout in the restarting
<KitsuWhooa> Ah, I see
<alkisg> So you may start it 20 seconds later, and it might be restarted 60 seconds later, killing your "20 seconds later" instance
 * alkisg wants to simplify this now with systemd which supports restarting
<KitsuWhooa> it doesn't seem to kill it
<KitsuWhooa> all I know is that I do that and I can use the shell across X restarts/crashes
<alkisg> Make sure UID is defined
<alkisg> Eh, you should be able to use the root epoptes-client without restarting it
<alkisg> It survives xorg crashes
<KitsuWhooa> Once I am done with this I can probably tell you how to reproduce it
<KitsuWhooa> and I checked stdout/err and it says nothing when it dies
<KitsuWhooa> something complains about socat dying
<KitsuWhooa> but I don't think that's the cause
<alkisg> Btw if it helps, you can also enable sshd on ltsp clients
<alkisg> I never had that issue though, with root epoptes-client dying
<KitsuWhooa> it would help, but this ugly workaround seems to be okay so far
<KitsuWhooa> so no need yet
<KitsuWhooa> would also be nice if there was an easy file transfer option
<KitsuWhooa> I just pipe tar to netcat at the moment
<KitsuWhooa> to send compiled binaries to clients
<KitsuWhooa> that is a lot of uninitalised byte warnings
<alkisg> I use python -m SimpleHTTPServer on the server, and wget server:8000/file on the clients, or scp
<alkisg> or sshfs
<alkisg> There's also LOCAL_APPS_EXTRAMOUNTS=/some/folder in lts.conf, which sshfs's it for you on login
<alkisg> Or you can login and /home/username is automounted, and put binaries there on the server, and run them on the client
<alkisg> ...the downside being that you need X to login :D
<KitsuWhooa> yeeeeah
<KitsuWhooa> was about to say that there is nothing in /home/
<KitsuWhooa> I don't see anything immediately related in the valgrind output
#ubuntu-x 2018-09-20
<KitsuWhooa> alkisg: I ran xrandr -s 640x480 on X running under valgrind without any clients, and it segfaulted
<KitsuWhooa> on a card that only had corruption before
<KitsuWhooa> this is just getting worse and worse :p
<KitsuWhooa> it doesn't segfault outside valgrind
<alkisg> Heh
<alkisg> Did valgring produce any helpful output on that segfault?
<KitsuWhooa> I think it did but xterm doesn't have a buffer
<KitsuWhooa> at least I don't think so
<KitsuWhooa> is it possible to set a custom terminal for epoptes?
<alkisg> If you're using the remote thing, it's screen, so you press Ctrl+[, then A, and you can scroll
<alkisg> (GNU screen)
<KitsuWhooa> Oh it's ran under screen
<alkisg> Sry
<KitsuWhooa> I tried ^B thinking it's tmux
<alkisg> Ctrl+A, then [
<KitsuWhooa> :p
<KitsuWhooa> yeah
<KitsuWhooa> thanks
<alkisg> np
<KitsuWhooa> I somehow broke it XD
 * KitsuWhooa runs man screen
<KitsuWhooa> it's definitely having update issues
<KitsuWhooa> oh it's not a segfault
<KitsuWhooa> it's a sigabrt
<alkisg> When does that happen? Double free()?
<KitsuWhooa> IIRC when an invalid pointer is being accessed/dereferenced
<KitsuWhooa> could be wrong
 * alkisg reads https://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-6 ...
<KitsuWhooa> it seems to have been thrown by strdup in libdrm.so
<KitsuWhooa> this is going well :p
<alkisg> Haha
<alkisg> You're catching a lot of fishes with this issue :D
<KitsuWhooa> <KitsuWhooa> IIRC when an invalid pointer is being accessed/dereferenced <-- nope, got it confused with sigbus
<KitsuWhooa> way too many
<KitsuWhooa> I see nouveau_vieux  in the backtrace
<KitsuWhooa> "nouveau_vieux_dri.so is a classic Mesa DRI driver, and not a Gallium3D driver, because these cards do not have enough shader capabilities to reasonably support the Gallium3D infrastructure. "
<KitsuWhooa> "Do not file bug reports about this driver. "
<alkisg> In the past I was adviced to "rm -f" it to work around some bugs in tnt2, and it did work around them, but in this case rm'ing it didn't help
<alkisg> (I was adviced about it in #nouveau)
<KitsuWhooa> yeah, the original segfault backtrace doesn't contain it
<KitsuWhooa> I wonder if it's valgrind's strdup that causes the abort
<KitsuWhooa> either way, it happens after I call xrandr to resize
<KitsuWhooa> if you're curious, this is what gets thrown right after I call resize https://tasossah.com/txt/valgrind_x_resize
<alkisg> KitsuWhooa: would that advice from the last line help? Use --track-origins=yes to see where uninitialised values come from
<KitsuWhooa> I may do that later
<KitsuWhooa> I deleted nouveau_vieux and it no longer crashes
<KitsuWhooa> bad news is I don't think valgrind printed anything while switching resolutions
<alkisg> I think xrandr is correctly initializing the previously uninitialized variables, so I wouldn't expect valgrind to complain when using xrandr...
<KitsuWhooa> I'd assume initializing them means "using" them
<KitsuWhooa> which is why I'd expect valgrind to complain
<KitsuWhooa> Also, the moment the mate session started, epoptes killed the remote terminal that ran mate-session, and the session died :p
<alkisg> x=1 initializes x without reading its uninitialized value
<KitsuWhooa> Hm, fair enough I guess
<KitsuWhooa> So, I can start the session with and without xrandr and compare
<KitsuWhooa> because if I run xclock without the session running, it doesn't do double buffering and there's no corruption
<alkisg> Maybe `caja -n` could reproduce it without a full session
<KitsuWhooa> I doubt it, but I can try it
<KitsuWhooa> So, epoptes died and I can't open a remote shell
<KitsuWhooa> the currently open one is stuck and won't respond to Ctrl C
<KitsuWhooa> I can't switch to a VT because X won't release the keyboard
<KitsuWhooa> and I don't think sysrq is enabled
<alkisg> KitsuWhooa: if you're still seeing the client in epoptes, try executing from epoptes this command: sudo openvt bash
<KitsuWhooa> it's not seeing it
<alkisg> Eh, would need to reboot then :/
<KitsuWhooa> I'll go update the squashfs image since I'm at it, then
<KitsuWhooa> it's getting annoying having to reinstall valgrind on every boot :p
<KitsuWhooa> caja -n did nothing. It exited
<KitsuWhooa> oh, compiz is installed
<KitsuWhooa> compiz should do it
<KitsuWhooa> nope
<KitsuWhooa> neither compton
<alkisg> The default display manager is marco
<KitsuWhooa> Ah
<KitsuWhooa> eeeeyup
<KitsuWhooa> starting marco did it
<KitsuWhooa> now I'm looking at a very groovy corrupt glxgears :p
<alkisg> Hehe
<alkisg> I think the following would make testing easier for you, in lts.conf: LDM_USERNAME=kitsu, LDM_PASSWORD=yourpass, LDM_GUESTLOGIN=True, LDM_SESSION=xterm.
<alkisg> With those, on the client login screen, you'd click "login" and you'd get xterm and an sshfs /home/kitsu mount to be able to copy things around.
<alkisg> And from that xterm, you'd run marco or whatever else
<alkisg> (a [Login as guest] button would appear with those vars)
<alkisg> (which would log you in as kitsu, not as "guest")
<KitsuWhooa> I'll have a look in a bit
<KitsuWhooa> thanks
<KitsuWhooa> alkisg: I compared the valgrind output of starting marco with both double buffering enabled and disabled
<KitsuWhooa> it was completely identical
<KitsuWhooa> I'll try with glxgears to see if I get anything else
<alkisg> KitsuWhooa: valgrind marco, or valgrind xorg and then start marco?
<KitsuWhooa> the latter
<alkisg> And "double buffering disabled" means "pageflip off"?
<KitsuWhooa> yup
<alkisg> Hrm, I feel that's bad news, that valgrind can't help in this case...
<KitsuWhooa> nothing useful with glxgears either
<KitsuWhooa> https://tasossah.com/txt/marco_pageflip
<KitsuWhooa> this is after X is done initialising and from the moment marco was started
<KitsuWhooa> none of these look related to me
<alkisg> Well if they're the same in both cases, when it works and when it doesn't... meh
<KitsuWhooa> yeah, they are
<alkisg> KitsuWhooa: hmm would it be possible that it's actually a bug in marco and not in xorg? I mean, the one we're looking for...
<alkisg> Would valgrind marco show it then?
<KitsuWhooa> I really doubt it's a marco bug
<KitsuWhooa> in any case, marco shouldn't make X segfault with the Riva
<alkisg> I mean, of course "somexorgfunction(bad parameters)" crashing would be a problem in both sides,
<alkisg> but if the problem of bad parameters is in marco, maybe that's the one we're looking for
<alkisg> Other window managers might not send bad parameters and not make corruption/crashes
<KitsuWhooa> if that was the case, the segfault would happen in the client handling code on X
<KitsuWhooa> not exa
<alkisg> I'm sure there's a problem in exa as well, but what I'm saying is, what if marco sends bad parameters and then exa can't handle them?
<alkisg> in its server side code?
 * alkisg wonders if its reproducible with any other manager
<alkisg> marco --no-composite, compiz, compton...
<KitsuWhooa> didn't happen with compiz and compton, but I think it's because they didn't enable double buffering
<alkisg> It would also explain why it's not mentioned widely on the internet, since marco only has a limited number of users...
<KitsuWhooa> maybe with ccsm
<KitsuWhooa> hm
<alkisg> I'm about to leave the office, but I'll test tomorrow if it happens e.g. in gnome
<KitsuWhooa> mutter?
<alkisg> Yeah
<alkisg> (if you have enough ram, you could also just install it on the live client)
<KitsuWhooa> I don't sadly
<KitsuWhooa> but I don't think mutter would run well, if at all on something this old
<KitsuWhooa> might fall back to software rendering
<alkisg> I'll try to remember which school had the problem with a geforce 210, and test with that one...
 * alkisg waves for now, bbl...
<KitsuWhooa> see ya
<mamarley> ricotz: I tried to package the 410.57 driver but it has major problems.  The computer boots to the (KDE) desktop, but if I launch any application that uses OpenGL, EGL, or Vulkan, it hangs immediately and permanently in disk sleep.
<mamarley> I think it might have something to do with the fact that the old libglx.so.XXX.XX is gone and replaced with libglxserver_nvidia.so.XXX.XX.  It looks like they might have done something with GLVND.  I will see if I can figure it out.
<ricotz> mamarley, hi, thanks :) (quite a version bump)
<tjaalton> serverside glvnd
<tjaalton> needs 1.20 most likely
<tseliot> yes, that file if for server-side GLVND, it's in their docs
<mamarley> Ah, thanks!
 * mamarley wishes they would have a "packager's changelog" that would document changes like that and list the new libraries that were included.
<mamarley> tseliot: Where in the docs?  It isn't obvious and it also isn't searchable.
<tseliot> mamarley: if you extract the installer, and look in html/installedcomponents.html , you will see a line about libglxserver_nvidia.so
<mamarley> Oh, I didn't realize that the documentation was extracted from the installer too, I thought it was just in https://download.nvidia.com/XFree86/Linux-x86_64/410.57/README/.
 * mamarley beats himself with the cluestick.
<tseliot> haha
 * tseliot hopes NVIDIA will put libglx.so.$version back into the 410 release
<mamarley> tseliot: If you don't mind my asking, where do you get this inside information?
<tseliot> mamarley: what inside information?
<mamarley> tseliot: You already seemed to know about this server-side GLVND thing before it happened.
<tjaalton> it was bound to happen
<tjaalton> nvidia added it to the server
<tjaalton> so now they're finally using it
<tjaalton> not that 1.20 is particularly old
<tseliot> mamarley: I simply tried to package the new release, and noticed the lack of the libglx.so.$ver file, so I had a look at the docs
<mamarley> Aaaand, it looks like the computer I was using for the packaging (and the only computer I have that can run the 410 drivers) hung when I tried to reboot it.  And I'm not there, so it looks like I won't be able to do anything else until I can get back home a hit the reset button. :(
<mamarley> Oh wait, it finally time out and rebooted.
<mamarley> tseliot: It still isn't working right.  When I moved the libglxserver_nvidia.so.410.57 file to /usr/lib/xorg/modules/extensions/ as specified in the documentation, X completely ignored the NVIDIA card and instead used the integrated graphics card (which doesn't even have a monitor attached).
<tseliot> mamarley: are you on 18.10?
<tseliot> or are you running xserver 1.20, somehow?
<mamarley> tseliot: Yes.
<tjaalton> mmm, beta ;)
<tseliot> mamarley: do you have an X log I can have a look at?
<mamarley> tseliot: Sure, just a sec.
<mamarley> tseliot: https://paste.ubuntu.com/p/rW3Jcqth6C/
<mamarley> It looks like it might be ignoring the NVIDIA driver (presumably because libglx.so is missing out of /usr/lib/x86_64-linux-gnu/nvidia/xorg/ ?)
<tjaalton> I wonder if the server is actually built with glvnd support..
<mamarley> Hmm, good point.
<mamarley> The GLVND build dependencies are installed when the server is built, but there isn't anything containing "glvnd" in the actual build log.
<tjaalton> no, but glxvnd is
 * mamarley beats himself with the cluestick again.
<tjaalton> something needed in the config snippet?
<tseliot> was libglxvnd actually built?
<tjaalton> it's not a separate lib
<tjaalton> from what I can tell
<tjaalton> does the doc have anything about it
<tjaalton> ?
<mamarley> Just where the libglxserver file should be installed, as far as I can tell.
<mamarley> It would appear as if Phoronix has benchmarks of the 410 driver running on 18.04.  I wonder how they did that?
<tjaalton> weird
<tseliot> mamarley: that's not really documented in X... anyway, did you create libglxserver_nvidia.so, which points to the nvidia library?
<tseliot> BTW, I'm going to test this when I get back home, next week
<tjaalton> mamarley: it doesn't show anywhere that the nvidia driver is loaded
<tjaalton> the logfile
<tjaalton> what's in xorg.conf?
<soee_> https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-410.57-Beta-Released
<mamarley> soee_: Yeah, we were just talking about that.  It is being rather difficult to package.  Stay tunedâ¦
<soee_> mamarley: they chnage a lot ?
<mamarley> They changed a little thing that is causing a big problem.
<mamarley> tjaalton: Not much in xorg.conf, just a few lines to hardcode which monitor outputs are enabled since my monitors have a habit of crashing at inopportune times and the resulting hotplug events have historically screwed up the desktop configuration.  I may not need that anymore though.
<tjaalton> it's weird that the log doesn't even mention nvidia.. is it a hybrid?
<mamarley> tjaalton: Nope, it is a desktop.  I just have the Intel GPU enabled so I can use it for hardware video transcoding (it doesn't have the 2-stream limit that GeForce GPUs do).
<tjaalton> ha
<tjaalton> ok, surprised that it works 
<tjaalton> or had worked
<mamarley> tjaalton: That what works, the transcoding?  The program I am using uses the DRM interface, not the X interface.
<tjaalton> ok, well it does make it harder to debug :)
<tjaalton> at least confuses me
<mamarley> tjaalton: Well, with both the original libglxserver_nvidia.so and the symlink in /usr/lib/xorg/modules/extensions, it uses the NVIDIA card correctly and OpenGL applications work, but EGL and Vulkan applications still hang in disk sleep.  I am checking what happens with the files in /usr/lib/x86_64-linux-gnu/nvidia/xorg/.
<tjaalton> ah
<mamarley> Disk sleep is the most annoying process state in the entirety of UNIX.
<mamarley> tjaalton: With the files in /usr/lib/x86_64-linux-gnu/nvidia/xorg/, OpenGL and Vulkan work but EGL hangs.
<tjaalton> k
<tjaalton> beta.. :)
#ubuntu-x 2018-09-21
<mamarley> ricotz: I did finally get 410.57 working.  The libglxserver_nvidia file just had to be in the right place and symlinked correctly.  Sadly, the fact that this is the only GLX server implementation provided means that currently the driver will only work on Cosmic, since server GLVND was only added in xserver 1.20.
<tjaalton> doesn't explain how phoronix got it working, and the docs would probably yell loudly if it supported only 1.20 and up
<tjaalton> so maybe the old libglx.so got merged into something
<mamarley> I find that suspect as well, but I can find anything in the documentation about it and just symlinking libglxserver_nvidia.so to libglx.so results in everything hanging, so until I have more information, I do not know how to proceed.
<tjaalton> what does the installer do?
<tseliot> you can check that in the .manifest file of the installer
<mamarley> It puts the file and the symlink both in the /usr/lib/xorg/modules/extensions/ directory, the same way https://download.nvidia.com/XFree86/Linux-x86_64/410.57/README/installedcomponents.html describes.
<tjaalton> so I think the driver has some trickery to load that on < 1.20
#ubuntu-x 2018-09-22
<soee_> mamarley: the build in your ppa is working ?
<mamarley> soee_: In Cosmic, yes.  I haven't had a chance to fool around with any lower versions yet.
<soee_> mamarley: ah i see, i'm on bionic :)
<mamarley> soee_: If the theory presented above about NVIDIA having done some trick to make the server-side-GLVND binary work on non-server-side-GLVND Xservers is correct, the Cosmic package should, in therory, work.  I obviously cannot be held liable if it were to break though.
#ubuntu-x 2018-09-23
<mamarley> ricotz: If you have no objections, I will delete the nvidia-304 packages from the PPA for Bionic and Cosmic since it will not install on these releases due to lack of X server compatibility.
#ubuntu-x 2019-09-17
<alkisg> tjaalton: Timo hi, how important is it that I test https://bugs.launchpad.net/bugs/1815172 currently? If I spend a couple of days, I should be able to find an affected school nearby, but I can't do it e.g. in a couple of hours...
<ubottu> Launchpad bug 1815172 in mesa (Ubuntu Bionic) "[bionic] drm/i915: softpin broken, needs to be fixed for 32bit mesa" [High,Fix committed]
<alkisg> If a problem exists, I'll surely hear about black screens etc, so then it'll be much faster to find an affected school :D
<tjaalton> alkisg: was hoping to get it verified this week
<tjaalton> there were others who were affected, might ask them too
<alkisg> OK, thanks; I have 5-6 other show-stopper issues that are much more pressing atm, so let's ask the others and I can search for a school if those don't reply
<alkisg> One might be xorg-related too, i.e. the window manager `marco` crashes xorg on nouveau, but it doesn't crash it if the resolution is changed before running marco!
<alkisg> This probably suggests "uninitialized variables" somewhere, but I'm not sure if those are on marco or on xorg/nouveau...
<alkisg> Hrm actually since marco is restarted... they're probably in nouveau
#ubuntu-x 2019-09-18
<alkisg> In bionic with hwe and fully updated, is this supposed to boot? It only works with nomodeset:
<alkisg> 38:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c6)
<tjaalton> should
<tjaalton> I think
<alkisg> I think it might be too new?
<tjaalton> shouldn't be with hwe
<tjaalton> test disco?
<alkisg> Thank you tjaalton; it's remote, I can test e.g. a kernel from mainline ppa but not disco, could that make a difference?
<alkisg> (or newer packages from a ppa etc etc)
<tjaalton> what happens without nomodeset?
<alkisg> The teacher reports a black screen right after grub
<alkisg> So the way around it was recovery => continue
<tjaalton> ok, test newer kernel then
<alkisg> Thank you
<alkisg> As far as I can tell, the hwe 5.0 failed, while mainline 5.3 worked
<alkisg> Whoops spoke too soon, it gets console/net but no graphics
<alkisg> [  605.074987] INFO: task gpu-manager:713 blocked for more than 120 seconds.
<alkisg> dmesg => https://termbin.com/yl7x
<alkisg> OK, back to nomodeset for now, if I get it locally I'll test with disco
<tjaalton> quality
<tjaalton> no mention of amdgpu on dmesg?
<alkisg> tjaalton: sure, see the termbin above, lots of amdgpu errors in dmesg
<tjaalton> ah right.. maybe #radeon would want to know
<alkisg> Thank you tjaalton
<tjaalton> could be old firmware causing it
<tjaalton> maybe try installing linux-firmware from eoan
<alkisg> Ah thanks, will try it on Friday when the teacher contacts me again
