#ubuntu-x 2007-02-12
<Ubugtu> New bug: #84630 in linux-restricted-modules-2.6.17 (restricted) "linux-restricted-modules causes modules mismatch with nvidia installer" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84630
<Ubugtu> New bug: #84662 in xorg-server (main) "Xnest: ghost mouse" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84662
<Ubugtu> New bug: #58112 in xorg (main) "Add a debconf option to disable composite extention" [Medium,Confirmed]  https://launchpad.net/bugs/58112
<Ubugtu> New bug: #84674 in linux-restricted-modules-2.6.17 "Disappearance of /sbin/lrm-video" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84674
<Ubugtu> New bug: #84725 in linux-restricted-modules-2.6.17 (restricted) "Pb with ipw3945 module (Inspiron 6400)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84725
<Ubugtu> New bug: #84731 in xorg (main) "Syncing and merging X.org 7.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84731
<Ubugtu> New bug: #84745 in mesa (main) "Flickering apps while in indirect mode" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84745
<Ubugtu> New bug: #84506 in xorg (main) "radeon in feisty: black screen at start gdm" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84506
<Ubugtu> New bug: #84768 in linux-restricted-modules-2.6.15 (restricted) "nvidia driver doesn't work with DVI output" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84768
<Ubugtu> New bug: #40621 in acpi-support (main) "vbetool breaks resume on R50e" [Medium,Confirmed]  https://launchpad.net/bugs/40621
<Ubugtu> New bug: #67636 in xserver-xorg-video-nv (main) "Edgy crashes while booting if TV out connected" [Undecided,Unconfirmed]  https://launchpad.net/bugs/67636
<Ubugtu> New bug: #84590 in xrandr (main) "Incorrect resolution detected, with refresh of "-19568 Hz"" [Undecided,Confirmed]  https://launchpad.net/bugs/84590
#ubuntu-x 2007-02-13
<Ubugtu> New bug: #2066 in libxfont (main) "Unable to load any usable fontset" [Undecided,Unconfirmed]  https://launchpad.net/bugs/2066
<Ubugtu> New bug: #52163 in libxfont (main) "Scalable bitmap font names reported but not usable after failed XSetFontPath() call" [Undecided,Unconfirmed]  https://launchpad.net/bugs/52163
<Ubugtu> New bug: #36314 in xserver-xorg-video-ati (main) "direct rendering missing on ATI Radeon XPRESS 200M " [Medium,Confirmed]  https://launchpad.net/bugs/36314
<Ubugtu> New bug: #43154 in xserver-xorg-video-via "computer freezes with some applications using 3D" [Medium,Confirmed]  https://launchpad.net/bugs/43154
<Ubugtu> New bug: #47508 in acpi-support (main) "Suspend and Hibernate are broken on an IBM Thinkpad R50e (dup-of: 40621)" [Medium,Needs info]  https://launchpad.net/bugs/47508
<Ubugtu> New bug: #84938 in xorg (main) "dependancy on xfonts-scalable unnecessary" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84938
<Ubugtu> New bug: #77928 in xserver-xorg-input-keyboard (main) "xorg handling of "special" keys inconsistant" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77928
<Ubugtu> New bug: #70886 in xserver-xorg-input-keyboard (main) "Dead keys for diacritics not complete" [Undecided,Unconfirmed]  https://launchpad.net/bugs/70886
<Ubugtu> New bug: #84969 in linux-restricted-modules-2.6.17 (restricted) "aticonfig --enable-monitor fails" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84969
<Ubugtu> New bug: #83726 in xorg (main) "[feisty-herd3]  X Display in Power-Saving mode on Startup, LiveCD even" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83726
#ubuntu-x 2007-02-14
<Ubugtu> New bug: #84996 in xorg (main) "Live DVD uses VESA : fails to detect video card and monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84996
<Ubugtu> New bug: #85002 in xorg (main) "Current vesa driver fails to load" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85002
<Ubugtu> New bug: #85059 in xorg (main) "xorg fails with Matrox MGA G200 AGP and GATEWAY EV70 apparently due to DRI" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85059
<Ubugtu> New bug: #83898 in linux-source-2.6.20 (main) "Ethernet interface disappears after hibernation on DQ965COEKR running Feisty herd 3" [Undecided,Needs info]  https://launchpad.net/bugs/83898
<Ubugtu> New bug: #85091 in xorg (main) "sudden reboot or freeze" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85091
#ubuntu-x 2007-02-15
<Ubugtu> New bug: #85223 in xorg-server (main) "Crash of graphic system from time to time" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85223
<Ubugtu> New bug: #85369 in xorg (main) "need to add "Option" "MonitorLayout" "LVDS" on xorg.conf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85369
<Ubugtu> New bug: #77540 in linux-restricted-modules-2.6.17 (restricted) "Edgy Suspend/Hibernate problem (another)" [Undecided,Confirmed]  https://launchpad.net/bugs/77540
<Ubugtu> New bug: #85035 in xkeyboard-config (main) "Problem with Microsoft confort curve 2000 USB keyboard" [Medium,Confirmed]  https://launchpad.net/bugs/85035
<tepsipakki> whee
<tepsipakki> so, is main open again?
<cjwatson> only once herd-4 releases
<tepsipakki> ah, it hasn't yet ;)
<tepsipakki> kylem: deb http://users.tkk.fi/~tjaalton/xorg72 feisty xorg-test
<tepsipakki> if you haven't already
<tepsipakki> sources also available
<Ubugtu> New bug: #44630 in xterm (main) "xterm rendering this font real ugly" [Medium,Needs info]  https://launchpad.net/bugs/44630
<Ubugtu> New bug: #57560 in xutils-dev (main) "lndir, xon and others lost in repackagin process" [Undecided,Rejected]  https://launchpad.net/bugs/57560
#ubuntu-x 2007-02-16
<Ubugtu> New bug: #85473 in xserver-xorg-video-trident (main) "gnome windows corrupt upon downward movement" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85473
<tepsipakki> X1R7.2 is now officially released: http://xorg.freedesktop.org/wiki/PressReleases/X11R72Released
<tepsipakki> +1
<Ubugtu> New bug: #84558 in xorg (main) "6.10 installer is unuseable at 800x600" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84558
<tepsipakki> binary-nvidia doesn't seem to like the new xserver, but I'll try rebuilding restricted-modules
<Ubugtu> New bug: #72040 in xresprobe (main) "Screen turns black - Installation on IBM M52" [Undecided,Unconfirmed]  https://launchpad.net/bugs/72040
<tepsipakki> ok, freeze is over? :)
<Ubugtu> New bug: #23253 in xserver-xorg-video-savage (main) "Using xv with media player get blue screen in Breezy" [Medium,Rejected]  https://launchpad.net/bugs/23253
<Ubugtu> New bug: #33617 in xserver-xorg-video-savage (main) "X.org does not initialize screen on IBM T20, T21, T22" [High,Confirmed]  https://launchpad.net/bugs/33617
<cjwatson> yes
<cjwatson> I think seb128 has the sync lock at the moment
<cjwatson> what should go first?
<tepsipakki> x11proto*
<tepsipakki> wait a sec, I'll dig the proper list
<seb128_> hi
<tepsipakki> hi
<cjwatson> tepsipakki is digging up the list of the first round of syncs to happen for X.org 7.2
<seb128> ah, good
<tepsipakki> ok, lets start: x11proto-core x11proto-damage x11proto-input x11proto-randr xcb-proto
<tepsipakki> those from experimental
<tepsipakki> (actually all these syncs are from there)
<cjwatson> any ordering for the prototypes? I guess not
<tepsipakki> nope, they are just -dev packages
<cjwatson> we'll probably have to wait for a publisher run in between each stage
<tepsipakki> sure
<cjwatson> have you confirmed that there are no other prototype updates from upstream that haven't been packaged yet?
<seb128> so "x11proto-core x11proto-damage x11proto-input x11proto-randr xcb-proto" are good to sync from experimental? do we need some extra testing first?
<tepsipakki> cjwatson: let me check for the last time :)
<tepsipakki> seb128: these are safe
<seb128> ok
<tepsipakki> xcb-proto is new, btw
<tepsipakki> not in ubuntu yet
<seb128> tepsipakki: what is your launchpad id?
<tepsipakki> seb128: tepsipakki ;)
<seb128> easy ;-)
<tepsipakki> cjwatson: nope, those are the ones
<cjwatson> ok
<tepsipakki> actually, x11proto-input for 7.2 is 1.3.2
<tepsipakki> but experimental has 1.4.1
<tepsipakki> feisty already has 1.3.2-4ubuntu1
<seb128> should we sync it then?
<tepsipakki> hmm, funny that the debian changelog claims it to be for 7.2
<tepsipakki> I'll ask #debian-x
<seb128> ok, thank you
<tepsipakki> 11:56 < jcristau> I think it is
<tepsipakki> :)
<tepsipakki> (safe to include)
<cjwatson> http://gitweb.freedesktop.org/?p=xorg/proto/inputproto.git FWIW
<tepsipakki> debdiff 1.3.2-4u1 vs 1.4.1-1: http://users.tkk.fi/~tjaalton/xorg72/pool/feisty/xorg-test/x11proto-input.debdiff.gz
<cjwatson> the Ubuntu change was irrelevant; it should have been build1
<tepsipakki> yes but that gives an idea what upstream changed
<tepsipakki> of course it is seen from git as well..
<cjwatson> looks ok
<cjwatson> mostly input hotplug
<tepsipakki> yep
<cjwatson> hopefully that metrolink stuff isn't used; if so I guess it can be fixed up later
<tepsipakki> "
<tepsipakki> Clean up some random detritus from the MetroLink merge."
<tepsipakki> so, fire away seb128 :)
<seb128> I've just finished to clean sync bugs, doing xorg now
<seb128> tepsipakki: so "x11proto-core x11proto-damage x11proto-input x11proto-randr xcb-proto" from experimental?
<tepsipakki> yes
<seb128> tepsipakki: looks like we have an epoch on x11proto-damage and Debian not
<tepsipakki> oh..
<tepsipakki> so it seems
<tepsipakki> bah
<tepsipakki> i'll do the merge
<seb128> there is no merge to do
<seb128> basically get the debian package and dch -i it and use a revision with the epoch
<tepsipakki> yes
<tepsipakki> I hate epochs
<seb128> tepsipakki: ok syncs are ready
<seb128> done
<tepsipakki> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<tepsipakki> is this the recent change?
<seb128> yep
<cjwatson> use build1 not ubuntu1 if it's just a fake-sync with new epoch
<tepsipakki> ok
<cjwatson> if you have a decent relationship with #debian-x, it might be possible to persuade them to bump epochs to accommodate us
<cjwatson> it wouldn't be the first time
<tepsipakki> yes, maybe later
* cjwatson nods
<tepsipakki> nexus6 /tmp 5015 % quota |grep WWW
<tepsipakki> WWW      98.48 of  100 MB used (98.48%)
<tepsipakki> hehe
<tepsipakki> I'll put that proto there, a sec
<tepsipakki> ok, http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> http://users.tkk.fi/~tjaalton/xorg72/new/x11proto-damage_1.1.0-1build1.dsc
<seb128> tepsipakki: ok, thank you, looking at it
<seb128> tepsipakki: uploaded
<tepsipakki> nice, thanks
<cjwatson> beat me to it :)
<seb128> tepsipakki: thank *you* for working on that ;)
<cjwatson> seb128: please remember -v though
<tepsipakki> heh
<tepsipakki> ok, so the next batch will have to wait for a while?
<seb128> cjwatson: ah right, will do for the next one
<seb128> tepsipakki: "a while" is not that much
<cjwatson> publisher will run at 11:03 UTC
<tepsipakki> it's, like, half an hour! :)
<cjwatson> given that all this ought to build within an hour, you should be able to start with libraries after that
<cjwatson> for stuff that takes longer to build, it can be best to wait to confirm that the binaries will make it
<tepsipakki> on my laptop xorg-server took 30min, mesa 1h+, the others were much faster
<tepsipakki> and it is a Stinkpad T23 after all
<tepsipakki> damn.. damageproto for 7.2 is 1.0.3 not 1.1.0.. Julien Cristau is checking if it is a problem
<tepsipakki> shouldn't be: http://gitweb.freedesktop.org/?p=xorg/proto/damageproto.git;a=commitdiff;h=df33455a4506362eff4d393dc7d58c9d73ddf870
<cjwatson> doesn't look problematic
<tepsipakki> seems that xorg-server needs a patch, otherwise it'll advertise 1.1 when it supports only 1.0..
<tepsipakki> http://www.nabble.com/xorg-server:-Changes-to-'upstream-unstable'-t3224973.html
<Ubugtu> New bug: #52054 in xserver-xorg-video-ati (main) "locks up with some mouse clicks" [Undecided,Fix released]  https://launchpad.net/bugs/52054
<tepsipakki> I'll add that to xorg-server.. jcristau will upload a new version this weekend which has this, so we can merge then again
<cjwatson> nod
<seb128> tepsipakki: we will not likely get the xorg-server before the WE anyway, will we?
<tepsipakki> maybe not
<seb128> I'm not sure than uploading a new xorg-server on friday evening is a good idea
<tepsipakki> hehe
<seb128> probably better to wait monday
<tepsipakki> yes, let's do that
<tepsipakki> it seems that support for damage-1.1 was added post-1.2.0, so that patch is needed
<tepsipakki> until 1.2.1 is released
<tepsipakki> hi jcristau :)
<jcristau> hi tepsipakki 
<jcristau> I figured it would be simpler to join here rather than read the logs on the web :)
<tepsipakki> hehe
<tepsipakki> I need to play some badminton, but when I come back I guess we can continue with the uploads
<seb128> cjwatson: si that ok if I accept xcb-proto (source NEW)?
<seb128> hum
<seb128> the package has a debian/copyright.debian with no copyright nor license 
<jcristau> yay
<seb128> ah, they build the copyright from debian/rules
<tepsipakki> ok, I'm back
<seb128> wb tepsipakki
<seb128> tepsipakki: is xcb-proto required to continue?
<tepsipakki> it's needed for libx11
<tepsipakki> but we can push others first
<seb128> ok
<tepsipakki> so, those that can now be synced are: libfontenc xtrans libxau libxdmcp
<tepsipakki> libice and libsm need epochs, libxfont isn't yet in experimental
<tepsipakki> jcristau: feel like uploading libxfont to experimental?-)
<jcristau> heh
<tepsipakki> also, there are some packages which need an epoch on Ubuntu.. is it possible to bump it also in Debian so that we could avoid doing that every time?
<tepsipakki> I know it needs team approval
<jcristau> yeah, probably
<jcristau> please send a mail with the list of such packages to debian-x
<tepsipakki> ok, I'll do that now
<tepsipakki> hmm, I only know those that are new in 7.2
<tepsipakki> bet there are others
<jcristau> libxfont on its way to ftp-master
<tepsipakki> whoa :)
<seb128> rock
<tepsipakki> hard rock
<seb128> tepsipakki: "libfontenc xtrans libxau libxdmcp" synced
<tepsipakki> seb128: thanks
<seb128> tepsipakki: do you want to do libice and libsm updates or should I?
<tepsipakki> you can do them
<tepsipakki> if it's simler that way
<tepsipakki> +p
<seb128> I don't care, it's as easy to dch -i than to wget your package for me
<seb128> ok, let me do those then if that's fine with you
<seb128> just the epoch to use?
<tepsipakki> yes
<seb128> ok
<jcristau> libxfont 1:1.2.7-1 should be in incoming, fwiw
<tepsipakki> yeah
<kylem> morning folks.
<tepsipakki> seb128: yes, I forgot to change the maintainer field in x11proto-damage
<seb128> well, do we need to if we do no change to the package?
<tepsipakki> good question
<seb128> tepsipakki: libice and libsm uploads done
<tepsipakki> great, then you can sync libxcb and grab libxfont from incoming.d.o
<tepsipakki> oh, libxcb is new
<cjwatson> seb128: (retroactively, yes :-))
<seb128> cjwatson: ok, thanks, pitti had a second look and we approved it since ;)
<cjwatson> I don't believe that *build*-style uploads need a Maintainer changes
<cjwatson> change
<seb128> ok, good
<seb128> tepsipakki: libxfont synced
<seb128> tepsipakki: do we need libxcb to continue?
<tepsipakki> yes
<tepsipakki> libx11 is after that
<jcristau> you need libxcb for libx11, don't think you need it for anything else?
<jcristau> s/don't/I &/
<tepsipakki> jcristau: see https://launchpad.net/ubuntu/+source/xorg/+bug/84731
<Ubugtu> Malone bug 84731 in xorg "Syncing and merging X.org 7.2" [Undecided,Unconfirmed]  
<tepsipakki> there might be errors though
<seb128> tepsipakki: what version of libxcb is required? if it's to NEW can you get an Ubuntu version we can upload? we will sync later when it's accepted for Debian
<jcristau> but there are no interface changes in libx11
<jcristau> seb128: libxcb is already in experimental
<tepsipakki> jcristau: so we can continue with other libs?
<jcristau> tepsipakki: yes, imo
<tepsipakki> seb128: yes just sync it
<seb128> I misred the " oh, libxcb is new"
<seb128> jcristau, tepsipakki: thanks
<tepsipakki> heh
<tepsipakki> jcristau: feel like pushing more libs?-)
<jcristau> which ones?
<tepsipakki> on my list are such gems like libxdamage libxfixes libxfontcache libxkbfile libxmu libxpm libxrandr libxrender libxres libxss libxt libxv libxvmc :)
<tepsipakki> ..which are missing from experimental
<tepsipakki> seb128: in the meantime, you can sync libxevie and libxcomposite :)
<jcristau> do you really need all of them? :)
<tepsipakki> hehe :)
<tepsipakki> I'm not sure, actually
<seb128> tepsipakki: libxcb libxevie libxcomposite synced
<seb128> ok, I'm away for ~1 hour
<tepsipakki> ok, thanks
<seb128> tepsipakki: I'll continue when I'm back if there is other things to sync
<tepsipakki> yeah
<jcristau> I'm probably not going to upload libxdamage 1.0.4 anyway, I'll go straight to 1.1
<tepsipakki> oh, I've missed that
<jcristau> uploading libxfixes now
<jcristau> libxfontcache has practically not changed
<tepsipakki> ok
<jcristau> same for xkbfile
<jcristau> same for xmu
<jcristau> I'll upload libxpm
<tepsipakki> libxv&xvmc have some ChangeLog hook changes, nothing else
<jcristau> I'll leave them alone then
<tepsipakki> yes, feel free
<jcristau> the only significant change in libxrandr was already in debian/patches/
<jcristau> libxrendr didn't change much either
<jcristau> same for xres
<jcristau> and xscrnsaver
<jcristau> I'll upload libxt
<tepsipakki> ok, thanks
<jcristau> done
<tepsipakki> I think some of those that were dropped can be synced from unstable, checking that now
<tepsipakki> libxmu would need an epoch anyway, made an mistake to put that on the list
<tepsipakki> seb128: when you get back, you can sync libxcursor and grab libxfixes, libxpm, libxt from incoming.d.o
<tepsipakki> then there are plain epochs like libxext, libxi
<cjwatson> here, I'll do those
<tepsipakki> ooh :)
<cjwatson> libxcursor libxfixes libxpm libxt done
<cjwatson> libxext and libxi are just s/.*/1:&build1/ in the version?
<tepsipakki> s/1/2/, yes ;)
<cjwatson> shouldn't libx11 be done before some of these?
<cjwatson> oh, I see jcristau said there were no interface changes, ok
<tepsipakki> right
<jcristau> yeah, we'd have a problem if libx11's soname changed :)
<cjwatson> I wasn't thinking soname, I was thinking interface additions which other things might check for at configure time
<jcristau> but afaik there is no shlibs bump here
<cjwatson> ok
<tepsipakki> seems that we have the libraries pretty well covered now
<tepsipakki> libxaw had some "LIB_MAN_SUFFIX=3 configure" stuff.. otherwise it just needs an epoch
<cjwatson> that isn't already handled some other way?
<cjwatson> there were multiple approaches to that
<tepsipakki> and the manpages have migrated from libxaw-headers to libxaw7-dev
<cjwatson> is there a Replaces?
<cjwatson> (or non-clashing filenames)
<jcristau> the manpages sections stuff should be fine now
<jcristau> as in fixed upstream
<cjwatson> that's what I thought too
<tepsipakki> I had some conflicts when I apt-get updated one of my machines
<tepsipakki> but the second run fixed it
<jcristau> hmm
<jcristau> then replaces might be needed
<tepsipakki> actually, one conflict from /usr/share/man/man3/Xaw.3.gz
<tepsipakki> which is the only manpage
<cjwatson> libxext uploaded
<cjwatson> hmm, not so much, forgot -sa
<jcristau> tepsipakki: looks like an ubuntu-only problem
<tepsipakki> damn :)
<jcristau> (just looking at the changelog in debian, so i might be wrong)
<jcristau> but actually, shipping the manpage in libxaw-headers might be more appropriate anyway
<jcristau> so maybe I should move it in debian :)
<tepsipakki> hehe
<tepsipakki> do it!
<jcristau> but then *I* will need the replaces :)
<tepsipakki> bummer :)
<tepsipakki> ok, what do i put in the Maintainer-field for libx11 (and the rest that follows)?
<cjwatson> the default value is listed in http://wiki.ubuntu.com/DebianMaintainerField
<cjwatson> ok, I have to go I'm afraid, so I can't do libxi
<tepsipakki> no problem, thanks
<jcristau> uploading libxaw
<tepsipakki> whee
<tepsipakki> jcristau: I've put libx11 in http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> there's also a debdiff
<tepsipakki> and in it you can see some patches which were included in the old version
<jcristau> I'm pushing today's upload to alioth now, I'll have a look at it after that
<jcristau> *uploads, even
<tepsipakki> ok
<tepsipakki> I need to go home and am offline for ~two hours, thanks so far for all the effort!
<jcristau> np
<jcristau> re: loadable i18n, you need to enable that in configure if you want it
<jcristau>     Drop --enable-loadable-i18n from confflags, it does not work with 1.0.3.
<jcristau>     See http://lists.freedesktop.org/archives/xorg/2006-July/016861.html
<jcristau>     Closes: #392567  Thanks Jrme Marant
<jcristau> but this ^^^ is in the changelog
<jcristau> so...
<seb128> re
<seb128> tepsipakki: pong, what is to do now?
<jcristau> seb128: epoch bump for libxi, I think
<seb128> jcristau: ok, thank you
<Ubugtu> New bug: #38949 in xserver-xorg-video-ati (main) "R128 DRI lockup on PPC" [Medium,Unconfirmed]  https://launchpad.net/bugs/38949
<tepsipakki> jcristau: ok, I'll just drop it then, thanks for noticing
<Ubugtu> New bug: #85557 in xserver-xorg-video-ati (main) "AIXGL ATI Mobility Radeon X700 freezes with glxgears, glxinfo reports no rendering, radeon driver used" [Undecided,Needs info]  https://launchpad.net/bugs/85557
<tepsipakki> seb128: if you're up, there's libxaw with epoch bump at http://users.tkk.fi/~tjaalton/xorg72/new
<seb128> tepsipakki: looking
<tepsipakki> also lix11, but I wonder if it could cause breakup, thus best left for monday
<seb128> yeah, I'll not touch that one on friday evening :p
<seb128> I don't do disruptive upload when I'm not around in the next hours usually
<seb128> and especially not on friday ;)
<tepsipakki> that leaves us libx11, libdrm&mesa + xorg-server left to do, plus the utils
<seb128> and the drivers no?
<tepsipakki> of course, but they could be again coordinated with Debian
<tepsipakki> actually not much has happened there, apart from i810 maybe
<tepsipakki> some updates here and there
<jcristau> drivers from 7.1 are compatible with the new server in any case
<tepsipakki> yes, they can be dealt with later one by one
<Ubugtu> New bug: #84034 in Ubuntu "gdm crash when dimming screen (dup-of: 80512)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84034
<seb128> tepsipakki: libxaw uploaded
<tepsipakki> yeah, I guess that's it for the weekend, or should we upload apps as well?
<seb128> I'm still around for like an hour, if you have other things we can upload which will not break anything we can do them
<tepsipakki> maybe it's best to continue with this on Monday. I'll go and grab me a beer ;)
<seb128> ok, cool
<seb128> enjoy, you deserve it ;)
<seb128> thank you for the hard work on those xorg upgrades
<tepsipakki> heh, I'll toss you one ;)
<tepsipakki> there
<tepsipakki> so far it has been fairly trivial.. the fun part is ahead
<seb128> yeah
<tepsipakki> and thanks to jcristau this has been a bliss
<seb128> right, thank you jcristau ;)
<jcristau> np :)
<jcristau> it's funny how the packages were created for ubuntu, came to debian, and now go back to ubuntu :)
<tepsipakki> homecoming party!
<jcristau> but I think it's better for everyone if we don't have massive differences in our X packages
<tepsipakki> definately
<seb128> right
<seb128> and not only X ;)
<jcristau> yeah :)
<tepsipakki> it's nice to see Brice cleaning up the bugs on Debian, so that the real ones are revealed. Same should be done on Ubuntu
<tepsipakki> but I know at least a dozen ati-bugs that can be closed when the new mesa is in ;)
<jcristau> heh
#ubuntu-x 2007-02-17
<Ubugtu> New bug: #85666 in xorg (main) "xon missing since repackaging" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85666
<Ubugtu> New bug: #35895 in xkeyboard-config "Not multimedia keyboard" [Medium,Fix committed]  https://launchpad.net/bugs/35895
<Ubugtu> New bug: #85745 in xorg-server (main) "xorg crash meanwhile watch video on firefox" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85745
<Ubugtu> New bug: #85764 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85764
<Ubugtu> New bug: #85808 in xcursor-themes (main) "Feisty Herd4: X cursor theme does not obey." [Undecided,Unconfirmed]  https://launchpad.net/bugs/85808
<Ubugtu> New bug: #85868 in xorg-server "xorg does not recognize 1440x900 screens of toshiba laptops. A nightmare for newbies" [Undecided,Needs info]  https://launchpad.net/bugs/85868
<Ubugtu> New bug: #85901 in linux-restricted-modules-2.6.17 (restricted) "[apport]  package linux-restricted-modules-2.6.17-11-386 failed to install/upgrade: " [Undecided,Unconfirmed]  https://launchpad.net/bugs/85901
#ubuntu-x 2007-02-18
<Ubugtu> New bug: #85943 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV while playing a movie in Totem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85943
<Ubugtu> New bug: #86011 in xorg (main) "20" Widescreen TFT not detected" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86011
<Ubugtu> New bug: #86021 in libxdmcp (main) "XDMCP does not work without reverse dns" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86021
<Ubugtu> New bug: #40422 in xorg (main) "Dell 2405FPW and resolution 1920x1200" [Medium,Confirmed]  https://launchpad.net/bugs/40422
<Ubugtu> New bug: #86072 in xorg (main) "ATI ES1000 515e not recognized" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86072
<Ubugtu> New bug: #86105 in xorg (main) "feisty's xv says no open ports" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86105
#ubuntu-x 2008-02-11
<ubotu> New bug: #190857 in xserver-xorg-video-ati (main) "no screens found for IGP 320M" [Undecided,New] https://launchpad.net/bugs/190857
<ubotu> New bug: #190865 in xorg (main) "[hardy][regression] letters cropped by 1 pixel from the top (gtk2, openoffice, qt3)" [Low,New] https://launchpad.net/bugs/190865
<ubotu> New bug: #187262 in linux-restricted-modules-2.6.24 (main) "Please add Dell driver for Conexant HSF modem in Hardy" [Undecided,New] https://launchpad.net/bugs/187262
<ubotu> New bug: #190839 in xfs (universe) "Large file corruption on XFS" [Undecided,New] https://launchpad.net/bugs/190839
<tjaalton> mvo: hey, I bet you have some experience with apt & diversions? The nvidia&fglrx packages divert some files, and there are strange bugs about not being able to upgrade/remove the packages.. Someone suggested to run 'rm -f' before dpkg-divert on postrm, and that should be a general rule of some sort
<tjaalton> mvo: so, do you think it makes sense?
<mvo> hello tjaalton
<mvo> tjaalton: I have seen those bugreport, its pretty anoying. dpkg-divert is a source of grief for me, because a diversion can not be declared declarative, but needs to be in the the post/pre scripts. that always made me unhappy
<mvo> as for the rm -f, that is a bit of a sledgehammer approch. do we know more about those faulures?
<tjaalton> mvo: actually, I didn't recall that correctly, see the suggestion on bug 36625
<ubotu> Launchpad bug 36625 in linux-restricted-modules-2.6.24 "can't remove nvidia-glx" [Medium,Confirmed] https://launchpad.net/bugs/36625
<tjaalton> I've thought that envy was a source of these reports
<tjaalton> but it should divert too
<Q-FUNK> tjaalton: that CPUID patch seems to build on all supported architecutres now, btw.  wanna try merging it?
<tjaalton> Q-FUNK: later
<ubotu> New bug: #190954 in xkeyboard-config (main) "Some compose sequences are not available" [Undecided,New] https://launchpad.net/bugs/190954
<tjaalton> Ng: did you have time to find out which commit broke your intel?
<Ng> tjaalton: I suck :(
<tjaalton> hehe
<ubotu> New bug: #188389 in mesa-utils "Top panels doesn't exist on any windows until I do 'metacity --replace'" [Undecided,New] https://launchpad.net/bugs/188389
<ubotu> New bug: #191000 in xserver-xorg-video-intel (main) "X Server fails to start (Hardy alpha 4_Desktop CD)" [Undecided,New] https://launchpad.net/bugs/191000
<ubotu> New bug: #191024 in xserver-xorg-input-synaptics "Synaptics touchpad not detected" [Undecided,New] https://launchpad.net/bugs/191024
<ubotu> New bug: #191045 in linux-restricted-modules-2.6.24 (restricted) "Installation of nvidia-glx-new interferes with xserver-xorg-video-intel" [Undecided,New] https://launchpad.net/bugs/191045
<ubotu> New bug: #191048 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new & 3D desktop effects slow system to a crawl / cause blank windows" [Undecided,New] https://launchpad.net/bugs/191048
<ubotu> New bug: #191057 in xorg (main) "cannot logon to GNOME" [Undecided,New] https://launchpad.net/bugs/191057
<ubotu> New bug: #191031 in xorg (main) "X.org 7.3 window not aligned properly (Hardy Alpha 4)" [Undecided,Incomplete] https://launchpad.net/bugs/191031
<ubotu> New bug: #191100 in xorg (main) "[hardy] X crashes when I start f-spot with "dbus-launch f-spot"" [Undecided,New] https://launchpad.net/bugs/191100
<ubotu> New bug: #190979 in xorg (main) "No boot screen" [Undecided,Incomplete] https://launchpad.net/bugs/190979
<ubotu> New bug: #190960 in xorg (main) "sis 672 videocard driver is unsupported" [Undecided,Incomplete] https://launchpad.net/bugs/190960
<ubotu> New bug: #190929 in xorg (main) "Gnome doesnt shutdown" [Undecided,Incomplete] https://launchpad.net/bugs/190929
<bryce> hmm, alex put up a Open GPU Documentation site...  wonder if that contains more than just the two docs they posted last fall?
<tjaalton> bryce: there were four docs
<tjaalton> they released two of them late last year iirc
<bryce> oh right, they released a couple more not long ago
#ubuntu-x 2008-02-12
<ubotu> New bug: #176504 in ubuntu "[hardy] scroll wheel on synaptic mouse pad doesn't work (dup-of: 173411)" [Undecided,New] https://launchpad.net/bugs/176504
<ubotu> New bug: #191129 in xorg (main) "No scrolling on inspiron 6400" [Undecided,New] https://launchpad.net/bugs/191129
<ubotu> New bug: #191149 in xserver-xorg-video-ati (main) "[Hardy] No 3D-Effects OOB on Radeon Mobility 7500 (IBM T4x)" [Undecided,New] https://launchpad.net/bugs/191149
<desertc> you all seen this yet?
<desertc> http://www.phoronix.com/scan.php?page=news_item&px=NjMyOQ
<ubotu> New bug: #191160 in mesa (main) "glxinfo crashed with SIGSEGV in dlclose()" [Undecided,New] https://launchpad.net/bugs/191160
<tjaalton> bryce: maybe you noticed, but david is very busy atm perhaps we need to come up with a solution to input-hotplug
<tjaalton> +,
<tjaalton> I'll try to make the hal-script work, and ask help again if can't
<ubotu> New bug: #191185 in linux-restricted-modules-2.6.24 (restricted) "have to reload ath_pci after suspend+resume" [Undecided,New] https://launchpad.net/bugs/191185
<MacSlow> Greetings everybody!
<tjaalton> hey MacSlow 
<MacSlow> Chris Jones told me you try to keep up-to-speed with TTM
<tjaalton> with the emphasis on word "try" :)
<MacSlow> hehe... I know what you mean
<tjaalton> tbh I haven't tried it lately, but krh posted some instructions to easily have all the crack on a separate directory so I could try it out again
<MacSlow> tjaalton, yeah... I remember a post from krh to the xorg-ml stating that he started merging his work into the master-branch 
<tjaalton> yeah, DRI2
<MacSlow> indeed
<MacSlow> I've "reserved" the comming weekend for getting a fresh upstream xorg plus related parts onto my i965 laptop
<tjaalton> I could devote a couple of hours
<tjaalton> after lunch :)
<tjaalton> bbl ->
<tjaalton> MacSlow: do you know if krh has committed DRI2 upstream yet?
<tjaalton> doesn't look like it
<MacSlow> he wrote something about his DRI2 work on the xorg-ml
<MacSlow> but I don't have the link to that post handy
<tjaalton> he said about merging it the next day after that post, but it's been a week already :)
<tjaalton> intel-batchbuffer doesn't build, and the last commit suggests that it needs DRI2
<tjaalton> pulling DRI2 doesn't help either, now mesa fails to build, bah :)
<ubotu> New bug: #191281 in xorg (main) "[hardy] Xorg freezes randomly" [Undecided,New] https://launchpad.net/bugs/191281
<ubotu> New bug: #183790 in compiz (main) "Strange window borders with compiz and X3100 (Hardy Alpha 3) (dup-of: 175774)" [Undecided,New] https://launchpad.net/bugs/183790
<ubotu> New bug: #141289 in acpi-support (main) "lcd backlight is switched off after resume from STR on Lenovo/IBM ThinkPad R61i (dup-of: 189260)" [Undecided,New] https://launchpad.net/bugs/141289
<ubotu> New bug: #134391 in linux-source-2.6.22 (main) "Gutsy Tribe 5: Backlight does not come back on after resuming from suspend (dup-of: 189260)" [Undecided,Won't fix] https://launchpad.net/bugs/134391
<ubotu> New bug: #155444 in linux-source-2.6.22 (main) "Dark screen (no backlight or VERY low brightness) after wake up (dup-of: 189260)" [Undecided,Confirmed] https://launchpad.net/bugs/155444
<bryce> tjaalton: great let me know what still needs done with input hotplug
<bryce> tjaalton: I'm making good progress on the xrandr gui, and hoping to have it ready for upload in a couple days
<ubotu> New bug: #191302 in mesa (main) "[gutsy] r300_dri.so: undefined symbol - no dri" [Undecided,New] https://launchpad.net/bugs/191302
<ubotu> New bug: #191306 in linux-restricted-modules-2.6.24 (restricted) "NVIDIA X Server Settings defaults to a non-existent path (Hardy)" [Undecided,New] https://launchpad.net/bugs/191306
<tjaalton> bryce: hopefully the hal-script can be made to work..
<bryce> I've got the gui speaking xrandr 1.2 now (at least for getting data), and the gui allows browsing each output
<tjaalton> it'll be a separate lib on top of libxrandr?-)
<bryce> no, since I had pretty much finished the libxrandr work I decided to press on with setting it up.  redoing all that work into a separate library will take 2-3 days, and since FF is only a couple days away I want to focus on getting all of this actually working
<bryce> actually I've been thinking about just dispensing with doing a separate lib, and instead just pull all my code changes out of libxrandr and gnome-control-center and make my own stand alone, self-contained tool
<bryce> it'd be easier to work in, the downside would be that this approach wouldn't end up helping gnome or xorg at all
<bryce> (or kubuntu)
<bryce> but maintaining a library is a significant commitment...
<tjaalton> right
<ubotu> New bug: #123362 in xserver-xorg-video-ati (main) "RADEON with [Radeon X300 (PCIE)] RV370" [Undecided,Fix released] https://launchpad.net/bugs/123362
<ubotu> New bug: #191374 in xorg (main) "Wacom tablet lag" [Undecided,New] https://launchpad.net/bugs/191374
<ubotu> New bug: #49977 in linux-restricted-modules-2.6.15 (restricted) "After kernel upgrade to 2.6.15-25 X server cannot find nvidia module " [Undecided,Won't fix] https://launchpad.net/bugs/49977
<ubotu> New bug: #31270 in linux-restricted-modules-2.6.22 "xorg hangs in startup with nvidia-glx 8178" [Wishlist,Fix released] https://launchpad.net/bugs/31270
#ubuntu-x 2008-02-13
<ubotu> New bug: #188642 in compiz (main) "default live CD boot shows rendering artifacts/defects along window edges (dup-of: 175774)" [Undecided,New] https://launchpad.net/bugs/188642
<bryce> http://bryceharrington.org/files/screenrez_8.png
<tjaalton> bryce: looks good. should there be a "clone" bullet too?
<bryce> http://bryceharrington.org/files/screenrez_9.png
<tjaalton> ah :)
<bryce> it was getting clunky to have a bullet for that and making the code crufty
<bryce> xrandr internally treats "clone" as a kind of relation
<bryce> so the code ends up cleaner this way.  I hope users don't get confused by it..
<tjaalton> btw, did you have something for xorg-server that's not committed yet?
<bryce> hmm, maybe
 * bryce thinks
<tjaalton> the dix-patch
<bryce> there's a poulsbo patch, but I don't think it's going into hardy proper
<bryce> dix-patch?
<tjaalton> I mean the one that's already uploaded ;)
<tjaalton> * Add a patch from Matthew Garrett to fix touchscreen issues with DIX.
<bryce> is that not already checked in?
<tjaalton> I can't see it
<bryce> ah, I committed but didn't push
<bryce> check if you see it now
<tjaalton> yep, it's there no
<tjaalton> +w
<bryce> sorry about that
<bryce> tjaalton: btw, we had our platform team meeting just now (on #ubuntu-meeting)
<tjaalton> no problem, that happens
<tjaalton> ok, what did you discuss?
<bryce> here I'll pastebin for you
<tjaalton> I can also check the irclogs
<bryce> http://paste.ubuntu-nl.org/55828/
<tjaalton> yeah, I'll contact cjwatson
<bryce> the xrandr gui now correctly detects my dual screen setup :-) :-)
<bryce> (I'm still too chicken to click Apply on anything... have to click that tomorrow though...)
<tjaalton> heh
<tjaalton> bryce: what's the "hardy-console" stuff?
<bryce> was adding i18n support to hardy-console
<tjaalton> ah, ok
<bryce> https://blueprints.launchpad.net/ubuntu/+spec/hardy-console
<tjaalton> yes, I see the problems all the time :)
<tjaalton> anyway, I'll ask colin about input-hotplug now
<bryce> cool
<bryce> maybe wait until after the meeting in #ubuntu-meeting is done; he'll have more attention then
<tjaalton> ah ok
<bryce> ok, over now
<bryce> heya seb128
<bryce> seb128: btw, I've got a patch for gnome-control-center coming in a few days (potentially after FF)
<bryce> seb128: http://bryceharrington.org/files/screenrez_9.png
<seb128> hey bryce
<seb128> bryce: do you work with upstream or at least discuss the feature and UI with them?
<seb128> bryce: is that an user only config or does it change xorg.conf etc?
<tjaalton> user only
<bryce> it does not change xorg.conf
<bryce> seb128: I spoke briefly with keithp about the changes to libxrandr but haven't spoken with gnome yet - getting the libxrandr changes accepted upstream will be a prerequisite for gnome to accept the changes
<seb128> ok
<bryce> seb128: however I did see in a discussion on gnome-control-center several months ago by glatzor about displayconfig-gtk that upstream basically said it had to be redone the way I'm doing it
<seb128> right
<seb128> but please discuss the UI, etc before doing the code
<seb128> because I don't want another non trivial patch than we will have to keep for ages because we didn't discuss it with upstream before and they disagree on how to do the changes
<bryce> hmm, well if you suspect they're going to reject it, perhaps I should just package it as a standalone tool
<seb128> oh, no, I don't say they will
<seb128> I say to better discuss the feature and UI now based on your mockup to make sure that's something we agree on
<seb128> they might have good comments
<seb128> and so we make sure we don't waste energy to do something which will not be accepted
<seb128> that's one of the complain we get from upstream sometimes, that distro do things on the side and then send everything upstream which rather than discuss it first with them to do it in a way which will work for everybody
<mvo> where is the new code currently? in some bzr branch?
<bryce> seb128: well they also complain we don't contribute things in the first place.  they ought to be happy that we're redoing it in a fashion that can be incorporated
<bryce> mvo, yeah
<seb128> bryce: ok, let's say we disagree on that then, that's alright
<seb128> they are happy we contribute
<seb128> though sometime that leads to thing they will not accept because they disagree on the implementation and it's really lot of work for us to maintain the changes in a distro specific way
<seb128> and they receive bugs which are distro specific, etc
<seb128> and that creates tensions where we could discuss thing first to make sure that's done in a way they will accept the change
<bryce> hrm.
<bryce> well, I worry they would just ask for a whole bunch of changes which would require a lot more time to have to be put into it
<bryce> design by committee, etc.
<seb128> I didn't say they have to accept the changes now
<seb128> but just make sure we go in a way which will make the patch acceptable for upstream at some point
<seb128> maybe not this cycle but the next one, that's fine
<bryce> yeah, like I said the libxrandr changes have to be done first anyway
<seb128> alright
<mvo> bryce: its cool that you extend the display capplet for this, that is the right approach
<seb128> still if anybody wants to send a mail to the control-center list with the mockup and saying we plan to work on something like that once those libxrandr changes are done they that would be welcome
<seb128> we could get UI comments from them already, etc
<seb128> sorry if it seems I'm not happy about the changes, that's not the case, I think that's great too ;-)
<seb128> I just know I'm the one who will have to update the patch every 2 weeks when GNOME roll new tarballs
<seb128> and merging glade changes is not fun, I already do it for the desktop effects thing ;-)
<bryce> hmm, yeah I understand
<bryce> fwiw, there's no glade changes in this, just plain gtk code
<seb128> ah good, I didn't look at the capplet recently and I though they were all using glade nowadays
<seb128> should make the work easier ;-)
<bryce> this one appears to not have been touched in years
<bryce> well, ok I'll send an email
<seb128> bryce: thanks
<bryce> emailed.  sent them this link - http://bryceharrington.org/files/screenrez_a.png
<bryce> bleah, I got an AMD meeting in 6 hrs.  time for bed.  night.
<tjaalton> night :)
<seb128> bryce: thanks and good night
<bryce> seb128: seen the responses on gnomecc?
<seb128> yes
<seb128> see why you should mail upstream first?
<seb128> ;-)
<bryce> eh
<bryce> hmm, I swore I checked that site before I started, and there wasn't much there besides the mockups
<bryce> in any case, that code doesn't appear to be in a shippable state
<seb128> maybe they have just updated it before replying
<bryce> seb128: but otoh it shows that gnome intends to adopt redhat's work instead of anything we do
<seb128> not really
<seb128> mclasen is a redhat guys
<seb128> but he's not a gnome-control-center maintainer
<seb128> there is no g-c-c maintainers from redhat actually
<seb128> so we might to decide to pick whatever is better
<seb128> but that keeps happening between novell and redhat
<seb128> they do their thing and after that there is always the same discussion on which one to use
<seb128> happened with netapplet and network-manager
<seb128> with xgl and aiglx
<seb128> with the new clock applet thing
<bryce> huh
<bryce> hmm, in any case, looking through the code it appears they also started from the screen resolution tool but seem to have been focused less on hooking up to xrandr, and more towards some sort of dynamic monitor detection/refresh functionality
<bryce> they seem to be missing all the xrandr 1.2 stuff
<seb128> that's why their solution might not be the best one
<seb128> and that's not sure upstream will use it
<bryce> it's using glade, btw
<bryce> ok, well I'm going to press on with what I've done - it's closer to the xrandr 1.2 goals and I'm more familiar with the code
<seb128> good
<bryce> I'll try drawing in some of their design ideas.  maybe a merge would be feasible at some point, if the monitor auto-refresh stuff looks good
<seb128> as said there is no redhat bias in the gnome-control-center team I think
<seb128> so there is no reason we would not decide on the best solution
<bryce> ok, I wasn't sure of that... some of the comments made it sort of seem that way
<seb128> no g-c-c maintainers commented yet
<seb128> vuntz is an upstream guy, mclasen from redhat and fcrozat from mandriva
<bryce> ahh, ok
<bryce> wasn't familiar with any of the names
<tedg> Okay guys, I have a weird problem that I have no idea how to write a bug report about.
<tedg> It seems that on my intel card, the output every so often dies.
<tedg> Like seriously, just the output.
<tedg> The screen will go all white and if I restart X it'll stay all black.
<tedg> X seems to be running all happy as GDM starts and even playes the login sound.
<tedg> I don't see anything in my logs that is different when this happens.
<tedg> It probably only happens ever few days, maybe even a week though.
<tedg> Is there some information I can grab at that time that'd be useful?
<tjaalton> tedg: when did you first see this? are you running the latest driver?
<tedg> tjaalton: Yes, I've only really run Hardy on this box.  So for the last few months.
<tedg> tjaalton: I got the box in Dec.
<tjaalton> tedg: does bug 139094 look similar?
<ubotu> Launchpad bug 139094 in xserver-xorg-video-intel "white screen on intel GMA 900 graphics card " [Undecided,Confirmed] https://launchpad.net/bugs/139094
<tedg> tjaalton: A little, but not quite as it runs normally for days, and then breaks.  But, it might be related.
<tedg> Theirs looks easier to reproduce ;)
<tjaalton> heh
<tjaalton> what chip is it? (lspci -vv |grep VGA)
<tedg> Intel 945GM/GMS, 943/940GM
<tedg> I'm not sure why both of those are in the lspci.
<tedg> But it's one string.
<tedg> HAL reports the same.
<tjaalton> ok..
<tjaalton> I'm not sure where to start debugging
<tedg> Me neither :)
<tjaalton> I'll check bugs.fd.o
<tedg> Is there someplace that I can query more information from the driver when it happens?
<tedg> It really feels (from a user perspective) like the output driver isn't getting set right.
<tedg> I wonder if I log in as GDM if I can query xrandr....
<tedg> Perhaps it's a really weird resolution/refresh rate that's confusing my LCD.
<tedg> Does that make sense, or is it crazy?
<tjaalton> hard to tell :)
<tjaalton> does it gradually turn white or all of a sudden?
<tedg> All of a sudden.  It's only happened once or twice when I'm at the computer.
<bryce> tedg, if you put xhost + in your .xinitrc or something before starting up, you should be able to call something like DISPLAY=":0.0" xrandr
<tedg> Just by law of averages, it seems to be mostly when I'm not at the computer :(
<bryce> then could it be a screensaver thing?
<tedg> bryce: Is there a way that I can do "xhost +" after X has started, like remotely?  I'm a little nervous putting xhost in xinit.
<tedg> bryce: I don't think so, it has happened while I've been sitting there.
<tjaalton> hmm, right.. it could be a screensaver that triggers it
<tedg> It just happens very rarely.
<tjaalton> oh right, so if it happens while the session is active..
<bryce> afaik, you have to run xhost from a client inside the xserver you're adjusting
<tedg> Hmm, okay.  I'll try to get some more info the next time it happens.
<tjaalton> do you use compiz?
<tedg> It doesn't happen enough that it's a real blocker, but it would make people think "Ubuntu is unstable" if it happened to normal users.
<tedg> tjaalton: When it doesn't crash, yes. ;)
<tedg> It's not on right now because it crashed this morning.
<tjaalton> so it could be a bug in the mesa/dri-land
<bryce> ew
<tedg> tjaalton: Yeah, but the weird part is that it doesn't come back when I restart and GDM is running.
<tedg> I dont' have a GDM theme that uses OpenGL.  (Hardy+1)
<tjaalton> ok so gdm is running in the background and you can hear the drums?-)
<tedg> Yeah, I hear the drums.
<tedg> I didn't try to login... that might be an interesting test.
<tjaalton> right, it's not a gpu hang then
<tedg> I could probably login, Alt+F2 and do the xhost.
<tedg> It really feels like just the output module of the GPU is not there.
<tjaalton> I guess it's a worthy bug for upstream ;)
<ubotu> New bug: #191646 in linux-restricted-modules-2.6.24 (restricted) "[hardy] Xorg freeze at multi user logon, when both uses compiz" [Undecided,New] https://launchpad.net/bugs/191646
<tedg> Does X11 use HDCP over DVI?  Could it be misnegotiating with the monitor?
<tjaalton> hmm, hdcp is a DRM technique ;)
<tjaalton> anyway, AFAIK the negotiation is done once, when the server starts or the device is plugged
<tedg> Should be, but I was curious if witching to things like VTs and back would cause a renegotiation.
<tedg> DRM is always a problem, I was curious if it might be here also ;)
<tjaalton> if restarting the server doesn't help, then it's probably not the monitor
<ubotu> New bug: #28604 in linux-restricted-modules-2.6.15 (restricted) "Cannot prelink against non-PIC shared library /usr/lib/libGL.so.1.0.8178" [Medium,Won't fix] https://launchpad.net/bugs/28604
<ubotu> New bug: #39107 in linux-restricted-modules-2.6.15 (restricted) "1.0.8756+2.6.15.8-1 renders very badly in some games" [Low,Fix released] https://launchpad.net/bugs/39107
<ubotu> New bug: #191697 in xserver-xorg-video-intel (main) "displayconfig-gtk don't work (dup-of: 151647)" [Undecided,New] https://launchpad.net/bugs/191697
<ubotu> New bug: #127905 in linux-restricted-modules-2.6.22 "Xorg crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/127905
<ubotu> New bug: #133268 in linux-restricted-modules-2.6.22 "Xorg crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/133268
<ubotu> New bug: #141267 in linux-restricted-modules-2.6.22 "package linux-restricted-modules-2.6.22-11-generic 2.6.22.3-11.4 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,Fix released] https://launchpad.net/bugs/141267
#ubuntu-x 2008-02-14
<bryce> seb128: hrm, from what I can tell I did not get a response from any gnomecc developers :-/
<seb128> bryce: be patient, that's not even a day
<bryce> ok
<tjaalton> mvo_: regarding the problems with nvidia/fglrx postrm & diversions, there's a proposed patch in bug 130208
<tjaalton> mvo_: http://launchpadlibrarian.net/9881445/linux-restricted-modules-2.6.22_2.6.22.4-13.6ubuntu1.debdiff
<ubotu> Launchpad bug 130208 in linux-restricted-modules-2.6.24 "package nvidia-glx None failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Medium,Confirmed] https://launchpad.net/bugs/130208
<tjaalton> mvo_: if you have time to check if the mechanism looks good..
<tjaalton> tseliot proposed another patch (bug 36625), but this looks better to my eyes
<ubotu> Launchpad bug 36625 in linux-restricted-modules-2.6.24 "can't remove nvidia-glx" [Medium,Confirmed] https://launchpad.net/bugs/36625
<mvo_> tjaalton: the logic looks ok, also "==" is a bashism, it should be "=" instead
<mvo_> and I would use $() instead of ` `
<tjaalton> mvo_: cool, thanks! I guess I'll add that for -8
<tjaalton> there are a lot of dupes about that, but I kept them separate since some had these suggestions about how to fix it
<mvo_> nice, my only concern left would be that the output of dpkg-divert might change depending on the locale, but quickly looking over the dpkg-divert code, this seems to be not the case
<mvo_> tjaalton: yeah, its cool that this is attacked now :)
<tjaalton> I'm trying to keep the l-r-m-2.6.24 bug list sane :)
<tjaalton> .22 has 220 open bugs
<tjaalton> .24 "only" 52 at the moment
<bryce> yay
<ubotu> New bug: #191779 in xorg (main) "No nvidia driver after februar, 13th update" [Undecided,New] https://launchpad.net/bugs/191779
<ubotu> New bug: #112514 in linux-restricted-modules-2.6.24 (restricted) "Firefox Menu Font Size Is To Large" [Low,New] https://launchpad.net/bugs/112514
<ubotu> New bug: #191783 in compiz (main) "window title changes cause window decorator to render poorly (dup-of: 186382)" [Undecided,Incomplete] https://launchpad.net/bugs/191783
<ubotu> New bug: #190166 in xserver-xorg-input-synaptics "scrollpad doesn't work on 8.04" [Undecided,Incomplete] https://launchpad.net/bugs/190166
<ubotu> New bug: #42459 in linux-restricted-modules-2.6.15 (restricted) "driver not working in dapper drake" [Medium,Fix released] https://launchpad.net/bugs/42459
<tjaalton> yay, soon below 1400 open team bugs
<tjaalton> over 400 less than what it was two months ago
<bryce> :-)
<bryce> I got bored breaking my displays and sorting out crtc issues so am reviewing bugs
<seb128> good work guys ;-)
<bryce> thanks seb128
<bryce> tjaalton: btw, did we get to a decision on XAA vs. EXA on 965?  I'm debating about uploading my patch for bug 175774
<ubotu> Launchpad bug 175774 in xserver-xorg-video-intel "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Critical,In progress] https://launchpad.net/bugs/175774
<mvo> if you do exa, we could keep compiz enabled there ...
<tjaalton> well, if it can be patched to keep exa & greedy for 965..
<tjaalton> bryce: didn't upstream say that patch would break stuff?
<bryce> tjaalton: I never really got a response from upstream on it
<bryce> but I've been running it on one of my 965 machines I use a lot, with no issues  evident
<tjaalton> ok.. anyway, exa without any tricks is unusable on 965
<tjaalton> and the rest could use xaa
<tjaalton> and with tricks the shadow looks fine, since it bypasses most acceleration paths
<tjaalton> seb128: do you personally know any hal experts? I'm waiting a reply from upstream about a problem I have with hal-set-property. it would be vital for input-hotplug
<tjaalton> h-s-p works when run by hand but not from a hal script
<tjaalton> which would suggest that there's some priviledge issues
<seb128> tjaalton: not really, ask pitti rather when he's around tomorrow
<tjaalton> seb128: ok cool, I will
<ubotu> New bug: #190729 in compiz (main) "the composite extension it's not available after instal ati restricted driver (dup-of: 173663)" [Medium,New] https://launchpad.net/bugs/190729
<ubotu> New bug: #190799 in xorg (main) ""additional startup programs" crash xserver" [Medium,New] https://launchpad.net/bugs/190799
<ubotu> New bug: #191989 in xorg (main) "Losing access to system option in low screen resolution" [Undecided,New] https://launchpad.net/bugs/191989
#ubuntu-x 2008-02-15
<bryce> tjaalton: would you mind doing an upload for me when you get a chance?  Here's a patch to add a quirk for an upcoming laptop model - http://people.ubuntu.com/~bryce/Uploads/xserver-xorg-video-intel_2.2.0.90-2ubuntu3.dsc
<tjaalton> bryce: uploaded
<bryce> rockin' thanks
<tjaalton> bryce: how come you still don't have core-dev powers?-)
<bryce> laziness
<tjaalton> heh
<bryce> actually I've written up the app, fixed up my wiki page, and everything, I just need to send the mail. 
<tjaalton> ok, hopefully I'm done with lrm for the day
<tjaalton> night
<bryce> tjaalton: night
<bryce> tjaalton: btw I've added this quirk patch to our xorg-server:  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=fc092334ac0a323b80a9602cb8bf60ca9dee3bfa
<bryce> tjaalton: it adds several kinds of quirks for dealing with buggy EDID
<bryce> I've compiled xorg-server with the patch to verify it applies, and it looks good
<jcristau> bryce: what's the diff between patches 150 and 43?
<bryce> oh, good catch
<jcristau> (i'm wondering how you got that to apply :))
<bryce> oh I have another patch (maybe two) and then was going to test.
<bryce> tjaalton: another dell quirk to upload when you have a chance:  http://people.ubuntu.com/~bryce/Uploads/xserver-xorg-video-intel_2.2.0.90-2ubuntu4.dsc
<ubotu> New bug: #192024 in xserver-xorg-video-intel (main) "java applications don't start giving a backtrace on ground of locking assertion failure" [Undecided,New] https://launchpad.net/bugs/192024
<ubotu> New bug: #175647 in linux-restricted-modules-2.6.24 (restricted) "Compiz-fusion with seperate x screen doenst work properly, gtk menus slow" [Undecided,Incomplete] https://launchpad.net/bugs/175647
<tjaalton> bryce: ok, intel uploaded
<tjaalton> bug 187855
<ubotu> Launchpad bug 187855 in xorg "keyboards events generated wrongly create issues" [Undecided,Incomplete] https://launchpad.net/bugs/187855
<tjaalton> ah that one
<tjaalton> daniels said that it would be a kernel issue, but I'm not sure how serious he was
<tjaalton> mmm, compiz eats 869MB RES
<bryce> yum
<tjaalton> bryce: btw, did we decide to sync ati from experimental? alex said he's preparing a release soon
<bryce> tjaalton: let's wait for the release
<tjaalton> ok
<bryce> if it comes in time, and brings needed features and is sufficiently stable, we can consider pulling it in
<bryce> but from what you described before, it sounds like the features that have gone in are maybe not as well tested as we'd like
<tjaalton> we need to either get r5/6xx support in ati or figure out how to fix vesa for them again
<bryce> yup
<bryce> 'night
<tjaalton> night, I'll do some uploads in the meantime ;)
<ubotu> New bug: #137828 in linux-restricted-modules-2.6.24 "Dell Latitude nVidia card not handled correctly" [Undecided,Fix released] https://launchpad.net/bugs/137828
<ubotu> New bug: #147133 in ubuntu "ACX driver working badly (dup-of: 58384)" [Undecided,New] https://launchpad.net/bugs/147133
<ubotu> New bug: #144984 in linux-restricted-modules-2.6.22 "Gutsy 9/25 Update broke nvidia-glx-new" [Undecided,Invalid] https://launchpad.net/bugs/144984
<ubotu> New bug: #192087 in xorg (main) "Feisty - Gusty - Hardy Gnome Lock (not sure xorg related)" [Undecided,New] https://launchpad.net/bugs/192087
<ubotu> New bug: #192088 in xserver-xorg-video-intel (main) "[hardy] X freezes system after cold boot on i830M using DRI" [Undecided,New] https://launchpad.net/bugs/192088
<ubotu> New bug: #192107 in xorg (main) "xorg fails to start i Hardy with ATI X1400 " [Undecided,New] https://launchpad.net/bugs/192107
<ubotu> New bug: #191851 in totem (main) "error while playing a ogg file (dup-of: 39050)" [Undecided,New] https://launchpad.net/bugs/191851
<tedg> Okay, just to give more data... I got the mysterious white screen thing this morning.
<tedg> xrandr was happy.
<tedg> nothing in the logs.
<tedg> When I asked xrandr to switch modes, then things go REALLY unhappy.
<tedg> Before I could always switch to a VT, but after asking xrandr to switch modes the display flickered.
<tedg> And then no more VTs.
<tedg> But, they were still responsive, I was able to shutdown the machine.
<tedg> And upon reboot, all better.
<tjaalton> tedg: did you file a bug already?
<tjaalton> I'm wondering if it's just dodgy hardware..
<tedg> No, I haven't.  I didn't feel like I could file a bug that was anything other than "Incomplete".
<tedg> I can do that though.
<ScislaC> anyone know if the fglrx that's in the repo will be what you guys stick with for hardy? (it sounds like there were some slight performance improvements and compatibility with xserver-xorg 1.4 was added in 8.02)
<tjaalton> ScislaC: 8-02 is the latest in hardy
<tjaalton> pretty fresh though
<ScislaC> tjaalton: not showing in the repo after I just did a reload in synaptic...
<tjaalton> ScislaC: it'll get there in time
<ScislaC> tjaalton: either way... woohoo! :)
<ScislaC> I can finally upgrade to the hardy kernel and xserver!!!! (I've had those packages and fglrx locked in synaptic since gutsy)
<bryce> heya ScislaC
<ScislaC> hi bryce! I'm gonna be a happy boy. :)
<ScislaC> bryce: btw, just so I can be prepared, do I need to do anything magical after my xserver upgrades (will I need to dpkg-reconfigure xserver-xorg)? will my current xorg.conf cause issues?
<bryce> not as far as I know
<bryce> timo might know differently tho
<tjaalton> it _should_ work
<bryce> hrm, I don't know what to think about redhat's xrandr gui work
<bryce> sort of steals wind from the sails, but I'm not sure if it's something we'd want to deploy for hardy
<bryce> (and I've not yet been able to get it to actually work)
<tjaalton> must be fun :/
<bryce> tjaalton: q's for you on #ubuntu-devel
<tjaalton> k
<ScislaC> bryce: hopefully you find it as amusing as I did... I just backed up my xorg.conf just in case it would be necessary for later, and saw a ton of backups from the past... they were suffixed with stuff like "-iwishitworked", "-pleasedontbreak", "-Ihatefglrx", etc. :)
<bryce> lol
<ScislaC> upgrade worked well :)
<bryce> nice
<ubotu> New bug: #178648 in linux-restricted-modules-2.6.24 (restricted) "sysctl table check failed: /dev/ath .7.9 Unknown sysctl binary path" [Medium,Fix released] https://launchpad.net/bugs/178648
<ScislaC> bryce: if there is a bug that prevents a gnome/kde session from ending if a program is running (it's keytouch and I confirmed it on launchpad)... if it's not a "regular" package is it not a priority to fix it?
<bryce> hmm, not sure
<bryce> ScislaC: maybe ask bdmurray?
<ScislaC> fair enough
<ScislaC> bdmurray: do you happen to know the answer to the question I just asked bryce? :)
<ubotu> New bug: #192253 in xorg (main) "xorg glx module is missing" [Undecided,New] https://launchpad.net/bugs/192253
<bdmurray> ScislaC: it'd probably depend on the release - is this on Hardy?
<ScislaC> bdmurray: yes
<bdmurray> and so if keytouch is running you can not log out of your desktop session is that right?
<ScislaC> correct
<ScislaC> but if you kill it before you choose to log out or shut down, everything is fine
<bdmurray> Without having seen the bug that sounds like something worth fixing.
<ScislaC> https://bugs.launchpad.net/ubuntu/+source/keytouch/+bug/186713
<ubotu> Launchpad bug 186713 in keytouch "[hardy] keytouch blocks logout" [Undecided,Confirmed] 
<ScislaC> btw, is it not kosher that I marked it as confirmed?
<bdmurray> A bug can be / should be confirmed in multiple situations and this seems to meet 2 of them.
<bdmurray> So yes it is kosher
<ScislaC> bdmurray: excellent :)
<bdmurray> You can learn a bit more about how we use statuses at http://wiki.ubuntu.com/Bugs/Status
<ScislaC> bdmurray: thanks for the reference link :)
<bdmurray> no problem
<bdmurray> ScislaC: How do I know if keytouch is running?
<bdmurray> Is it just keytouchd running that screws it up?
<ScislaC> bdmurray: you need to start it via preferences or session management...
<ScislaC> and yes... keytouchd
<bdmurray> It'd be interesting to know if there is a debian bug about it since we autosync with them
<bdmurray> Come to find out there isn't so that might be worth forwarding to them.
<ScislaC> I have to run right now, but will do so tomorrow :)
<ScislaC> thanks for the wonderful X work guys :D
#ubuntu-x 2008-02-16
<ubotu> New bug: #192126 in ubuntu "Ubuntu 8.04 alpha 4 - top toolbar buttons do not respond to mouse click (dup-of: 173411)" [Undecided,New] https://launchpad.net/bugs/192126
<ubotu> New bug: #192221 in nvidia-settings (universe) "[Hardy] Incorrect replacement of nvidia-glx with nvidia-glx-new" [Medium,Triaged] https://launchpad.net/bugs/192221
<bryce> \o/ got screen disabling working FINALLY!!
<tjaalton> nice
<bryce> mmm nice
<tjaalton> yet another lrm upload, bleh
<bryce> hrm, maybe it _would_ be easier to get redhat's tool working than mine.  erf
<tjaalton> oh?
<bryce> well, redhat has shown zero interest in working with us
<tjaalton> that's unfortunate..
<bryce> gnome is more likely to accept whatever redhat does over what we do, unless our stuff is clearly better
<bryce> so, if my goal is to end up with zero code that I have to maintain personally, the only option seems to be to chuck what I've done and just accept redhat's work
<bryce> I can see already that to get my stuff finished up it's going to take a *lot* of debugging
<bryce> plus I need to sort out how to make the changes persistent from boot to boot, which they've already solved
<tjaalton> via gconf?
<bryce> no, they came up with a very different approach, using a daemon
<tjaalton> uh, YAD
<bryce> yeah
<bryce> however it also provides monitor hotplug, which would be nice to have
<bryce> it just feels like my last 2 weeks would have been for waste
<tjaalton> well, at least you master randr inside out now ;)
<bryce> I don't really like their ui though
<ubotu> New bug: #192360 in linux-restricted-modules-2.6.24 (restricted) "libglx.so link in current nVidia drivers is broken" [Undecided,New] https://launchpad.net/bugs/192360
<bryce> well, goodnight
<tjaalton> yeah, it's late there ;)
<tjaalton> night
<ubotu> New bug: #118239 in nvidia-settings (universe) "create new xorg.cong nvidia settings  keyboard to be on quarty " [Low,Confirmed] https://launchpad.net/bugs/118239
<ubotu> New bug: #108060 in nvidia-settings (universe) "Custom nvidia-settings changes should be automatically loaded on log in" [Undecided,New] https://launchpad.net/bugs/108060
<ubotu> New bug: #134563 in linux-restricted-modules-2.6.24 (restricted) "Gnome terminal crashes when using desktop effects" [Undecided,Fix released] https://launchpad.net/bugs/134563
<ubotu> New bug: #137432 in linux-restricted-modules-2.6.22 "[nvidia-glx-legacy] nvidia module won't load with 2.6.22-10 kernel (gutsy)" [Undecided,Incomplete] https://launchpad.net/bugs/137432
<tjaalton> oh, the fedora configurator uses gnome-settings-daemon, which is already there
<tjaalton> so it's not yet-another-daemon after all
<ubotu> New bug: #128296 in linux-restricted-modules-2.6.24 (restricted) "avm drivers need pci_register_driver instead of pci_module_init" [Undecided,Fix released] https://launchpad.net/bugs/128296
<ubotu> New bug: #137062 in linux-restricted-modules-2.6.24 (restricted) "Going into/out of fullscreen occasionally freezes compiz" [Undecided,Fix released] https://launchpad.net/bugs/137062
<tjaalton> ..and now we are under 1400 bugs in total
<ubotu> New bug: #128301 in linux-restricted-modules-2.6.24 (restricted) "2 usefull missing avm drivers fcpcmcia and fcusb2" [Undecided,New] https://launchpad.net/bugs/128301
<ubotu> New bug: #192402 in linux-restricted-modules-2.6.24 (restricted) "Extension for libglx.so moved" [Undecided,Confirmed] https://launchpad.net/bugs/192402
<ubotu> New bug: #192394 in linux-restricted-modules-2.6.24 (restricted) "[hardy] compiz does not start anymore" [Undecided,New] https://launchpad.net/bugs/192394
<ubotu> New bug: #192320 in linux-restricted-modules-2.6.24 (restricted) "nvidia compiz not working" [Low,Confirmed] https://launchpad.net/bugs/192320
<ubotu> New bug: #192425 in xserver-xorg-input-evdev (main) "Logitech MX Revolution mouse doesnt move pointer correctly" [Undecided,New] https://launchpad.net/bugs/192425
<ubotu> New bug: #192429 in xserver-xorg-video-intel (main) "[Hardy] bottom part of lavalite screensaver not seen using xserver-xorg  2:2.2.0.90-2ubuntu2 on 845G chipset" [Undecided,New] https://launchpad.net/bugs/192429
<ubotu> New bug: #192490 in linux-restricted-modules-2.6.24 (restricted) "nvidia driver 169.09, does not provide RGB GLX visual" [Undecided,New] https://launchpad.net/bugs/192490
<ubotu> New bug: #192465 in compiz (main) "8.04 compiz crashes after upgrad 2.6.24-8-generic (dup-of: 192253)" [Undecided,New] https://launchpad.net/bugs/192465
<bryce> tjaalton: =8-)
<bryce> of course, probably around 200-300 of the lrm bugs aren't really X bugs
<bryce> some day it'd be fun to go through and look at all the packages with < 10 bugs
<bryce> bet there's some old cruft hidden around in those nooks and crannies
<tjaalton> bryce: I think I've done that already :)
 * bryce empties xserver-xorg-input-joystick of its single bug 116977
<ubotu> Launchpad bug 116977 in linux-source-2.6.20 "Driver not correctly identifying the number of buttons on a Namtai Buzz! Controller" [Undecided,Incomplete] https://launchpad.net/bugs/116977
<bryce> tjaalton: I had to do a bit of hacking to get redhat's monitor tool working, but I've got it up and running
<bryce> it is able to change resolutions of each monitor independently and that seems to work relatively well
<bryce> however I'm not sure how to disable one monitor or the other, and am not sure how you'd specify 'left-of'/'right-of', etc.
<tjaalton> nice
<tjaalton> maybe they know that the gui needs some work
<bryce> the underlying xrandr code is cleaner than the cracked out stuff I threw together the past couple days
<ubotu> New bug: #78151 in linux-restricted-modules-2.6.24 (restricted) "dvb-usb-wt220u-02.fw not available in restricted modules package" [Undecided,Fix released] https://launchpad.net/bugs/78151
<bryce> however as written it has gtk-isms so wouldn't be reusable by kde
<bryce> nothing major though, just g_assert type stuff
<tjaalton> who cares :)
 * tjaalton runs
<bryce> settle ;-)
<bryce> their screen layout stuff is pretty and functional however it could be an accessibility issue
<bryce> since there's no way to get to the other monitor settings without using the mouse
<bryce> no mechanism for specifying mirrors
<tjaalton> ok..
<bryce> what was wild, was I had run the gui several days ago and tried setting one of my monitor resolutions to 1600x1200, but it didn't work (the daemon wasn't running)
<bryce> so, having forgot that entirely, I started up the daemon and my right monitor switches to 1600x1200.  I go, WTF???
<bryce> but was simple to fix ;-)
<tjaalton> it should use gnome-settings-daemon for that?
<bryce> I gather that is the plan
<bryce> "This is all intended to be added to gnome-desktop,
<bryce> gnome-settings-daemon, and gnome-control-center for 2.24.
<bryce> "
<tjaalton> yep
<ubotu> New bug: #192516 in linux-restricted-modules-2.6.24 (restricted) "nvigia-glx-new libglx.so is wrong" [Undecided,New] https://launchpad.net/bugs/192516
<bryce> http://bryceharrington.org/files/screenrez_b.png
<tjaalton> hjuuuge
#ubuntu-x 2008-02-17
<tjaalton> mmm, xorg bugs 108 -> 90
<ubotu> Launchpad bug 108 in malone "Searching for a product " " generates error." [Medium,Fix released] https://launchpad.net/bugs/108
<tjaalton> hah
<tjaalton> xkeyboard-config has a lot of old bugs of which many are fixed now
<bryce> cool
<tjaalton> gah, it's late.. night!
<ubotu> New bug: #192524 in linux-restricted-modules-2.6.24 (restricted) "Hardy: Dangling libglx.so symlink in nvidia-glx-new breaks 3D acceleration" [Undecided,New] https://launchpad.net/bugs/192524
<ubotu> New bug: #37345 in xkeyboard-config (main) "Missing config entry for logicdo Logitech Cordless Desktop Optical" [Wishlist,Incomplete] https://launchpad.net/bugs/37345
<ubotu> New bug: #192613 in xorg (main) "New version of X will not keep resultion I specify" [Undecided,New] https://launchpad.net/bugs/192613
<Q-FUNK> grmbl.  it seems that some dropped the patch to get deadkey-macron on the finnish keyboard, in Hardy...
<ubotu> New bug: #192674 in ubuntu "Failed to initialize the GLX module in kernel 2.6.24-8-generic (dup-of: 192253)" [Undecided,New] https://launchpad.net/bugs/192674
<ubotu> New bug: #192679 in xorg (main) "Video playback does not work" [Undecided,New] https://launchpad.net/bugs/192679
<ubotu> New bug: #172503 in linux-restricted-modules-2.6.24 (restricted) "menu display delayed when using multiscreen with nvidia and compiz" [Undecided,New] https://launchpad.net/bugs/172503
<ubotu> New bug: #192702 in linux-restricted-modules-2.6.24 (restricted) "Ubuntu 8.04 alpha 4 - restricted driver (ATI) causes low graphics mode and touchpad double click error" [Undecided,New] https://launchpad.net/bugs/192702
<ubotu> New bug: #192741 in xorg (main) "X crashes." [Undecided,New] https://launchpad.net/bugs/192741
#ubuntu-x 2009-02-09
<RAOF> Oh, balls.
<RAOF> I'd like to sync a newer nouveau snapshot from Debian (bugfixes, ability to run without kernel component), but that requires libdrm-nouveau1 to be built from libdrm sources.
<tjaalton> bryce: thanks!
<tjaalton> RAOF: if you'd wrap up a patch for it.. ;)
<RAOF> tjaalton: libdrm?  I might.
<tjaalton> yep
<bryce> heya tormod 
<tormod> hi bryce
<bryce> how goes?
<tormod> well, thanks. and quite busy :)
<bryce> yep, seems to be going around ;-)
<tormod> did you look at my logging patch ?
<bryce> I did, but only briefly (just flew home from sprint in berlin and still a bit jet lagged)
<bryce> offhand it looked good, I think it can be done
<tormod> u-dev sprint?
<bryce> yep
<tormod> did you also go to fosdem?
<bryce> nope
<tormod> I wanted to go this year, but - too busy
<bryce> ETOOMUCHTRAVEL ;-)
<tormod> well I hope you can consider my logging patch, because your log patch... how can I say it?
<bryce> ??
<tormod> the log becomes a bit too scrambled
<bryce> scrambled?
<tormod> mixed up with timestamps everywhere in the middle of lines
<bryce> hrm
<tormod> maybe it's a bit ddx dependent, surely looks bad on radeon
<tormod> see for example this log with my patch: http://launchpadlibrarian.net/22291743/13.%20Xorg.0.log.patched.WORKING
<bryce> do you have an example of a bad log?
<tormod> was just looking for one, not here. must be some on launchpad?
<bryce> fwiw, I can't actually take credit for the patch - it was written by canonical's oem team.  but definitely something I've wanted in there
<jcristau> i guess the problem is LogVWrite can be called with something that's not a full line
<tormod> or worse, there was something written before LogVWrite was called
<jcristau> same thing :)
<tormod> jcristau, sort of :) I proposed to move the time stamp to logWriteVerb 
<bryce> jcristau: is x log timestamping something debian would take a patch for?
<mnemo> bryce: any idea when the drm kernel patch for the "temporary intel freezes" will be commited to jaunty? --> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/320813/
<ubottu> Error: Could not parse data returned by Ubuntu: timed out (https://launchpad.net/bugs/320813/+text)
<tormod> jcristau: see bug #285787
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/285787/+text)
<bryce> mnemo: yes in fact I talked with Tim about that last week; he's planning on waiting until upstream has reached a final decision on what they're going to take
<tjaalton> mnemo: when linus pulls it in his tree
<tjaalton> (hi)
<bryce> heya tjaalton
<mnemo> bryce: airlie has sent that patch to linus already
<jcristau> bryce: i'd rather see it go upstream, i think. debian specific patches -> fail.
<tjaalton> mnemo: yes, but linus hasn't pulled that yet
<mnemo> aah okay
<bryce> jcristau: fair enough
<tormod> I also think ubuntu-specific X log format = fail
<tjaalton> bryce: howdy
<tjaalton> I can reproduce the "maxclient patch breaks compiz on nvidia" -bug
<bryce> tormod: then maybe we should drop the patch at beta
<bryce> tjaalton, I see coincidentally ajax has started talk of some XID fixup for 11.1
<tjaalton> bryce: where's that?
<bryce> tjaalton: xorg-devel@
<tjaalton> aww, need to subscribe to that
<bryce> Subject: XC-MISC / X-Resource / core protocol extension proposal
<jcristau> tormod: seen my reply to your acer quirk patch?
<tormod> jcristau: yes, saw it, will respond a bit later
<jcristau> ok :)
<tormod> bryce: apropos X startup performance, I just finished a 55 comment long debugging in bug 319363 - turned out gdm switched to failsafe because the computer took more than 10 seconds to start the mga driver...
<ubottu> Launchpad bug 319363 in xorg "Can not get 1024x768 video mode by undetected monitor and Matrox G100 8MB graphics adapter" [Undecided,Confirmed] https://launchpad.net/bugs/319363
<tjaalton> haha
<tormod> 333 P2 that was :)
<tormod> guess what I feel about failsafeX
<bryce> patches welcomed
<bryce> actually that's probably not failsafe-x but rather gdm
<bryce> if not for failsafe-x, you'd end up on the old ncurses error screen
<bryce> tormod: ok, your log patch fix uploaded
<tormod> bryce: maybe the timeout in gdm (ok that is gdm's fault I guess) should be scaled with cpufreq :)
<jcristau> tormod: maybe whatever is taking 10 seconds to start X should be fixed...
<tormod> it's just that failsafeX makes debugging a bit more difficult. Maybe LP could scan the logs and mark them if they are VESA logs.
<tormod> jcristau: the PC is just that old
<bryce> tormod: in what way does it make it more difficult?  the failsafe-x scripts are quite simple and if there are ways they can be improved, I'd love to hear
<tormod> it creates misunderstandings in the bug reports - well it could be just me. So many times I have to explain that I don't want that VESA log but I need the other log and the user can't find it or create one and so on.
<tjaalton> it's true..
<tormod> But I have learned as well: now I ask them to boot with "text" and run xinit
<tormod> BTW a trick for getting info in the event of a "black screen" for instance: xinit -e 'sh -c "xrandr --verbose > log" '
<bryce> tormod: hrm, but I force that log to Xorg.failsafe.log.  They still include that one?
<bryce> tormod: cool, added to https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<maco> the stuff wgrant was doing with moving features into syndaemon in october, that gets rid of the need for SHMConfig and synclient, right?
<maco> (at least for the features that have been migrated, i mean)
<tormod> bryce, did you notice xorg-server build broke?
<tormod> libgl1-mesa-dev: Depends: libgl1-mesa-glx (>= 7.3) but it is not going to be installed
<tormod> oh I guess it only broke on anything !386
<bryce> tormod: no didn't notice that
<bryce> tormod: link?
<tjaalton> it has been broken for ports some time now
<bryce> ah ok.  amd64 too?
<tjaalton> nothing to see, move along..
<tjaalton> no, amd64 is fine
<bryce> seemed to build ok on amd64
<tjaalton> so is armel and lpia
<bryce> ok, yeah I know about those breakages
<tormod> sorry for the noise, I haven't got xorg-server build reports for a long while :)
<bryce> ok no prob
<bryce> better to have a few false alarms than be delayed in solving a build breakage issue
<tormod> bryce, keeping the log patch until Beta sounds like a good idea
<bryce> tormod: btw I booted with the original log patch and see the issues you described
<tormod> bryce: you didn't test it before you uploaded it :)
<bryce> tormod: you caught me :-)
<tormod> ok I am not so angry at failsafeX any longer, since the original log should be in that failsafe tarball
<bryce> at the sprint, with sucky wireless, was hard to do testing
<maco> but easy to upload big files? ;)
<tormod> you have a dev sprint without good internet connection? that's funny
<bryce> maco: a) .dsc's are small files to upload, and b) I do build and upload on my home machine
<tormod> probably to keep you working and not watching youtube
<bryce> tormod: oh it was horrible, I was lucky to be connected most of the time
<maco> i forgot only the .dsc had to go
<maco> at uds, you mean?
<maco> too many geeks, not enough bandwidth for all of 'em
<bryce> maco, no dev sprint
<bryce> yeah partly it was overloaded, partly there weren't enough AP's for all the rooms
<bryce> can I complain about the chairs too?  sitting in them all week + bad airplane seats on way home = threw out my back yesterday when I got home.  Owwww :-(
 * maco hands bryce a cookie
<maco> and a bag of ice
<bryce> thanks maco :-)
<bryce> oh on positive note, I got lucky and got to sit in 1st class on trip home.  sat 2 seats away from Clive Owen.  that was cool
<maco> my version of the equivalent sort of luck is running into Dan Kaminsky on Saturday then having him join my friends and i for drinks in the hotel bar
<bryce> :-)
<maco> so uh, any answer to the question i asked before?
<bryce> maco: I could guess but probably would be wrong
<bryce> maco: best ask wgrant or tjaalton
<maco> wgrant is /away right now
<maco> oh. both are.
<maco> ok, well i *think* based on a conversation i had with wgrant back in oct that thats how it works, i just wanted to double-check
<bryce> maco: you could email them (or mail ubuntu-x@)
<maco> well i was asking to double-check something i was going to say on u-d-d, but i just put in a disclaimer that i think that's how it works but wgrant was doing it so he can correct me
<maco> holy screen artifacts, batman
<maco> are screen artifacts in kde4 a you-guys thing or kde4-guys thing?
<bryce> depends
<tseliot> maco: it's something they have to deal with in Qt4
<maxb> Could someone consider reverting the "Increase MAX_CLIENTS" xorg-server patch until the problems it causes are worked out? It's the most popular problem in #ubuntu+1 right now. (bug 326344)
<ubottu> Launchpad bug 326344 in xorg-server "compiz/kwin freezes on login as of xorg-server 1.5.99.902-0ubuntu2" [Critical,Confirmed] https://launchpad.net/bugs/326344
<andersk> Packages with that patch reverted are available in my PPA: https://launchpad.net/~anders-kaseorg/+archive/ppa I have confirmed that the problem is gone with the patch removed. 
<maxb> Whoops :-) Guess I should have searched all PPAs before uploading to my own
<bryce> maxb: done
<zmiq_> hi, I have some trouble with xorg-intel driver, and found a patch that solves it; can anybody apply the patch and recompile for me? I'm using jaunty. Thanks
<maxb> zmiq_: Would it not make more sense for you to do it locally?
<zmiq_> any hints about how to do it? Just download everything -devel, apply the patch and make will work?
#ubuntu-x 2009-02-10
<maxb> apt-get source xserver-xorg-video-intel
<maxb> apt-get build-dep xserver-xorg-video-intel
<maxb> cd xserver-xorg-video-intel-VERSION
<maxb> apply patch
<maxb> dch -l zmiq "My local package to do foo"
<maxb> (^That adds an entry to the debian/changelog, thus giving the package a distinct version number)
<maxb> dpkg-buildpackage -b
<zmiq_> many thanks; I'll try asap!!
<zmiq_> the truth is I have been waiting for two months for a patch, which is now developed and tested as working, and don't want to wait anymore; it's regarding Option "SDVOBOutput"
<zmiq_> developed by Wang Zhenyu
<zmiq_> more at: http://bugs.freedesktop.org/show_bug.cgi?id=17823
<ubottu> Freedesktop bug 17823 in Driver/intel "[945GM] Unable to switch to VGA with 2.4.2, VGA-1 replaced by TV-1" [Critical,New]
<zmiq_> maxb: i've completed all steps; will dpkg-buildpackage -b also install the new module? in which direcotry?
<stgraber> bryce: are your aware that geode GX2 are broken in Jaunty (more than they were in Intrepid) ?
<stgraber> back in Intrepid, I just had to mention the Driver to use (geode) and force XAA to have them working, now I get a X seg fault in all cases
 * stgraber goes looking for a bug on LP
<stgraber> bryce: bug 327484
<ubottu> Launchpad bug 327484 in xserver-xorg-video-geode "X crashing with Geode GX2 on Jaunty" [Undecided,New] https://launchpad.net/bugs/327484
<bryce> stgraber: no I hadn't heard
<stgraber> these things are usually extremely buggy and hard to get to work but there always were workarounds :) For jaunty the only one I found so far is using vesa which kind of sucks ...
<bryce> stgraber: unfortunately I think AMD laid off their geode support people
<bryce> and I gather they will no longer be producing geode
<stgraber> indeed, unfortuanately we have a few hundreds of these things out there :)
<bryce> stgraber: if you can locate a patch, or a new release which fixes the issue, we can upload it
<bryce> else, at least get a full backtrace, in case it's just something simple like a null pointer
<bryce> however my guess is that it is missing some support
<bryce> stgraber: also check the geode mailing list
<bryce> morning everyone
<bryce> tjaalton, jcristau: does Option "ModeDebug" impact performance?  if not, would there be any reason not to switch it on while we're in development?  (up to beta perhaps?)
<jcristau> bryce: sounds like a good idea
<crevette> good evening gentlemen
<bryce> heya crevette
<crevette> I have a bug recently with jaunty where I can see what it is displayed after usplash, removing usplash to the "kernel " line in grub fixes the issue
<crevette> s/can/can't/
<crevette> are you aware of such issue ? I remember having the same bug in intrepid :)
<bryce> crevette: yes
<crevette> okay so I don't need to spam you more
<bryce> crevette: bug in usplash; you can sub to it
<bryce> 327230
<bryce> crevette: kees is looking at it currently - you could help him with some testing if you'd like
<crevette> wonderful
<crevette> kees: don't hesitate if I can help you
<kees> crevette: okay, I've got 8 builds of usplash I need tested.  :)
<crevette> hehe
<kees> crevette: basically, to isolate the change that broke for some people
<crevette> kees: do you need I enumerate my hardware ? 
<kees> crevette: nope
<kees> crevette: okay, ready?
<kees> crevette: here's the list: http://people.ubuntu.com/~kees/usplash-testing/
<crevette> I've few minutes free
<kees> in order, test 242 242.1.1 242.1.2 242.1.3 242.1.4 243 and 244
<crevette> do you have i386 deb ? 
<kees> each directory has 2 deb, both are needed.  at some point, after a reboot, it'll fail.  242 should work, for example.
<kees> crevette: give me a moment, I can build those...
<crevette> okay thanks
<crevette> too bad I don't have a VM of jaunty
 * crevette opens another bug in the meanwhile
<kees> crevette: okay, i386 debs are up.
<crevette> wonderfull
<crevette> first reboot
<crevette> 242 works
<kees> okay, good.  that's expected (242 is basically 0.5.27).
 * crevette will try the dichotomy way
<crevette> let pick on in the middle :)
 * kees nods
<crevette> 242.1.4 is affected
<kees> okay.  /me suspects 242.1.3
<kees> though why it would cause this, I have no idea.
<kees> if 242.1.2 works and 242.1.3 is busted, then I'll revert the signal handler changes.
<crevette> which one do you want me to test ?
<kees> try 242.1.2 next.
<crevette> 242.1.2 works
<crevette> let's got for 242.1.3
<kees> okay, ... 242.1.3 next, I guess.  :)  Thanks so much for doing this testing
<crevette> no problemo, always happy to help
<crevette> 242.1.3 works too
<crevette> so 242.1.4 is guilty 
<crevette> :)
 * kees ponders
<kees> uhm
 * kees scatches his head
<kees> seems the diff between 242.1.3 and 242.1.4 is only in the changelog...
<crevette> should I try again to reboot to see if it works again
<tjaalton> bryce: i thought upstream turned it on already, but maybe only for master
<kees> yeah, can you?  maybe this problem isn't always present on every boot?  geh, I wish I could reproduce this locally
<crevette> let do it again
<crevette> 242.1.3 didn't work the 2nd time
<kees> okay, that does imply a race with the alarm handler... copying up another test version...
<kees> crevette: http://people.ubuntu.com/~kees/usplash-testing/ 0.5.29~kees1
<kees> that's 244 with the changes between 242.1.2 and 242.1.3 removed
<crevette> okay
 * kees hugs crevette
<bryce> thanks crevette :-)
 * crevette hugs kees & bryce
<crevette> :)
<crevette> See you soon
<crevette> so it seems to work
<crevette> I admit I didn't tested twice :)
<kees> heh.
<kees> okay, well, maybe I can get bryce to test the ~kees1 build too?
<kees> bryce: do you need i386 or amd64 debs?
<bryce> sure thing
<bryce> i386
<kees> cool, they're up there for ya
<kees> http://people.ubuntu.com/~kees/usplash-testing/
<kees> the ~kees1 build reverts a signal handler clean up.
<bryce> installed; rebooting
<kees> cool, thanks
<bryce> ok, came right up
<kees> whee
<bryce> so, I can confirm the fix
<kees> okay, I'll push this version, though it's not clear to me _why_ it broke.  :P
 * crevette goes to eat its soup bowl
<kees> crevette: thanks again.  I've uploaded an official 0.5.29 which reverts the signal handler changes, so hopefully this bug should stay dead.  :)
<crevette> kewl, thanks a lot
<kees> np
<tjaalton> bryce: btw, the compiz-freeze with intel still happens for me, but it's harder to trigger with the latest patch :/
<bryce> tjaalton, ok
<tjaalton> so it's only partially fixed
<mnemo> tjaalton: same here but here it seems to repro more and more often the longer you run X though
<tjaalton> mnemo: there's another patch to try
<tormod> tjaalton: I still have /etc/X11/Xsession.d/65mesa-check-x86-64 here, is this a conf file that needs to be deleted even if it's not shipped any longer, or is it just me?
<jcristau> yes, the postinst should take care of that
<tormod> jcristau: thanks. just rm it no question asked?
<jcristau> tormod: it's a bit more complicated than that
<tormod> I was afraid so :)
<bryce> tjaalton: so do you think slipping ModeDebug into dexconf would be ok for pre-beta?  or is there a better way we could do it?
<jcristau> bryce: don't do that. swap the default in the code
<jcristau> tormod: xsfbs.sh has remove_conffile_lookup, remove_conffile_commit, remove_conffile_rollback. there's another example on the debian wiki somewhere iirc
<bryce> jcristau: why not?  would be easier to swap than patching the xserver
<jcristau> tormod: http://wiki.debian.org/DpkgConffileHandling
<tormod> bryce: it's easier to revert it in the server than to try to rewrite xorg.conf's later
<jcristau> bryce: because dexconf only runs on initial install, and is the wrong place to set defaults anyway
<jcristau> also, what tormod says
<tormod> jcristau: but but this is not really a configuration file... nobody should have changed if not only to disable it
<jcristau> it's a conffile...
<jcristau> though i can understand if you don't care enough and want to just remove it :)
<jcristau> tormod: the xsfbs.sh stuff also makes sure the conffile is restored if for some reason the upgrade gets aborted (the rollback function)
<tormod> well that's almost useful - maybe reason enough
<tjaalton> tormod: what shipped it?
<tjaalton> bryce: by patching the server, yes
<tormod> tjaalton: libgl1-mesa-dri
<tjaalton> tormod: ok.. nothing in the changelog
<tormod> I hope jcristau looks another way :) I don't think Ubuntu supports broken release upgrades anyway.
<jcristau> heh
<tjaalton> tormod: oh, I dropped it
<tjaalton> meh
<tjaalton> there should be a /usr/share/X11/Xsession.d
<tjaalton> or similar
<tjaalton> and /etc/X11/Xsession.d left for the local admin
<jcristau> (we had the same problem with xfree86-common -> x11-common, i think the files in /etc/X11/Xsession.d/ were left around on sarge->etch upgrades :/)
<jcristau> (so you'd end up with two copies until you purged xfree86-common. which means two ssh-agents starting. which means fail.)
<maxb> It's a shame dpkg doesn't make the corner-cases of conffile handling easier
<tormod> I thought you had to declare what's a conffile? Or is everything under /etc conffiles?
<maxb> debhelper declares everything under /etc for you
<maxb> Though I believe it would be frowned upon to put something in /etc/ that wasn't a conffile
<tormod> there is certainly a good bunch of stuff under /etc that is not meant to be edited, no more than you would recompile something under /usr/bin
<maxb> I guess it would be ok if you had a comment informing the local admin that the file is liable to have local changes destroyed on upgrade
<maxb> though still not ideal
<tormod> for instance there is gdm.conf, with gdm.conf-custom for making changes
<tormod> oh, gdm.conf has such a warning :)
<maxb> though is still a conffile
#ubuntu-x 2009-02-11
<maco> what packages did xutils and x-dev turn into?
<andersk> xorg-dev? 
<maco> the pakage description for xutils said it turned into a bunch of smaller packages
<maco> but i dont know where to find a list of what those packages are
<andersk> aptitude show xutils 
<maco> the depends line?
<andersk> Right. 
<maco> k thanks
<RAOF> tjaalton: You suggested I provide a patch to make libdrm spit out a libdrm-nouveau package, so we can get a newer nouveau snapshot.  This will require pulling in some post-2.4.4 commits from git; would you prefer that as a bunch of patches, or a new tarball?
<RAOF> Sweet.  autofoo during build.
<tjaalton> RAOF: i'd prefer patches
<RAOF> So would I, and since libdrm runs autoreconf during build, that's nice and easy.
<tjaalton> yeah
<RAOF> modesetting-newttm, I see.  What fun!
<tjaalton> hehe
<bryce> kewl, xorg bugs squashed down to 100 now
<bryce> (from ~200 earlier today)
<tjaalton> wow :)
<maco> bryce: as in Fix Released??
<RAOF> Hm.  How does one generate the initial symbols file?
<tjaalton> RAOF:build it, and you'll see it fails. grab the symbols and and edit the package version information
<RAOF> Cool.  That's what I was going to try first :)
<bryce> maco: no; mostly moved to more correct packages (people dump all random X bugs in xorg if they don't know where they really go).  Plus a couple handfuls -> invalid for various reasons.
<tjaalton> and since you got access to git.d.o, you can push it there for review
<maco> bryce: oh ok, my eyes were ready to pop out of my head :)
<bryce> http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-month-open.png
<RAOF> tjaalton: Oh, that was aimed at me?  Oh, wow.  We *do* have an ubuntu branch of libdrm in there.  I always thought the VCS field was wrong!
<tjaalton> RAOF: no, they are mostly right. I'm on a crusade to convince bryce that having all changes in a git branch is a nice thing :)
<RAOF> Oh, well.  I guess I'll get to learn how to use git properly, then.
<bryce> I await the sales pitch :-)
<tjaalton> bryce: hehe
<tjaalton> RAOF: you only need maybe five commands
<bryce> (actually after last week I'm a bit more receptive to the idea)
<tjaalton> once you get used to it, it's really simple
<bryce> "get used to it" is the operative phrase it seems ;-)
<tjaalton> yes, well, it has bitten me a couple of times, but I've tried to document those on the wiki
 * RAOF is already hitting hard-edges.
<tjaalton> for instance when merging new upstream tags of mesa..
<tjaalton> it's fine if you follow a branch, but trying to move from a branch to a tagged devel release from master.. yuck
<tjaalton> but it's easy now, and documented
<tjaalton> bryce: well, for one thing, you always have the history, even if the package has been synced since
<tjaalton> and it's nice to stage the changes on a shared repo instead on your hd
<tjaalton> so the changes are less ad-hoc
<RAOF> Ok.  So, how do I make 'git diff' show the differences between HEAD and my working tree?
<tjaalton> git diff HEAD?
<tjaalton> hmm, which HEAD?-)
<RAOF> Ah.  Of course.  Why doesn't 'git diff' give that to you?
<RAOF> Or, alternatively, what is 'git diff' giving me? :)
<tjaalton> git diff only shows uncommitted changes
<RAOF> To files which were previously committed, it seems.
<RAOF> It doesn't show file additions, which was freaking me out.
<tjaalton> git status
<RAOF> That makes sense of the output.
<RAOF> OOOOOh, I get it now.
<tjaalton> git clean -f; git reset --hard 1309t8h3g098h; those will become familiar to you ;)
<RAOF> 'git diff' shows the changes to your working tree that _won't_ be committed when you commit.
 * RAOF thinks that seems 100% arse-ended, but whatever.
<tjaalton> hmm, I'm lost now :)
<RAOF> I was wondering why the patches weren't showing up in 'git diff' output, but debian/control etc was.
<tjaalton> which branch are you on? remember to 'git checkout -b ubuntu origin/ubuntu' first
<RAOF> Yup.  I remembered that bit.
<RAOF> This is because I'd run 'git add debian/patches/02_add_libdrm-nouveau.patch', but hadn't run 'git add debian/control'.
<RAOF> Now that I've added everything, 'git diff' gives no output.
<tjaalton> git diff only shows the changes to files that are already known by git
 * bryce boggles why git is more popular than bzr.  vhs vs. betamax I guess
<tjaalton> git status shows new file additions etc
<tjaalton> RAOF: no need to git add d/c
<tjaalton> bryce: well, I can't understand why I have to use 'bzr log|less' instead of just b
<RAOF> tjaalton: Oh, because 'git commit -a' is now the defalt?
<bryce> 'git commit -a' is a useful command
<tjaalton> uh, bzr log
<bryce> 'git show <commit-id>' is another
<tjaalton> RAOF: yes, I only use that
<RAOF> I have half-remembered git halucinations :)
<bryce> tjaalton: yeah that bugs me too... I mentioned it to james_w last week (he was asking for bzr annoyances)
<RAOF> There's the bzr-pager plugin; that should be installed by default :)
<bryce> apparently the bzr guys did it that way intentionally, but dunno why
<tjaalton> bryce: there were other similar cases too, but can't remember right now
<tjaalton> maybe it's just me, but it feels like bzr pushes the changes upstream by default, and not on a local branch?
<RAOF> If you 'bzr checkout', yes.
<tjaalton> also, it's really annoying to have to specify the path _where_ to push every time
<RAOF> If you 'bzr branch', no.
<bryce> no, it uses local branches
<RAOF> It remembers the default push location for me.
<bryce> tjaalton: you do?  I never have to do that...
<tjaalton> every doc I've read says that
<bryce> well, maybe one time
<tjaalton> maybe they are not ment for me then  :)
<RAOF> Um.  Does libdrm-intel1's long description really want to say that it's built from a snapshot of DRM code, and shouldn't be expected to be stable? :)
<tjaalton> also, I need to rename the checked-out dir because it's always 'ubuntu' :)
<tjaalton> RAOF: whoops, no :)
<tjaalton> copy-paste ftw
<RAOF> I'll roll that change up :)
<bryce> tjaalton: having the history seems useful, but since I can also see it at https://edge.launchpad.net/ubuntu/+source/<package>, including debdiffs, the need is lessened a bit
<bryce> staging the changes is useful, but given how often I forget to push anyway.....  ;-)
<tjaalton> hehe :)
<bryce> I can imagine it helps when merging upstream + debian git into a new ubuntu version, however it seems this benefit comes mostly from the more complex packages, most of which we already have in git.  Also you usually do all those merges yourself, so it's so far been a pain I've not had to endure.  (for which I must give you thanks!)
<RAOF> Is there any reason to use git-buildpackage?
<bryce> my guess is that this latter point is the main sales point, but it's not one I understand very deeply so would need further selling on it to drive it home
<RAOF> Oh, yes.  To make it actually work :/
<bryce> for me, the question is not so much bzr vs. git, but vcs vs. no vcs
<bryce> since adding the vcs adds several additional steps in the process, and thus adds extra spots I can forget to do stuff and screw things up
<maco> tjaalton: i always make a directory with the package name, cd into it, and then branch because i once accidentally branched a "trunk" right over another "trunk" where i already had modifications
<maco> (for two different programs)
<tjaalton> maco: heh, right
<bryce> otoh I've been getting used to using git with xorg-server now, and already have found it handy for xorg.  I'm a bit at a point of wondering if it might be useful for -intel and xkeyboard-config
<tjaalton> bryce: it does add a few steps, but once it's in your blood you don't think of those steps anymore, it just flows naturally :)
<bryce> I've pretty much given up on ever seeing a viable bzr-git bridge things.  If it did come I suspect it'd add as much complication as it saves
<bryce> tjaalton: yeah and I'm sure if I wrote the GPL out for every commit, that would eventually get in my finger muscle memory as well.  ;-)
<tjaalton> bryce: this has much less typing, that's for sure :)
<bryce> hey, sometimes I wonder ;-)
<tjaalton> bzr-git; yes, and I'm not sure if it could solve the collaboration we now have with debian
<tjaalton> um, I mean keep
<bryce> what is the collaboration?
<tjaalton> pulling changes from our branch in to debian-*
<tjaalton> has happened a couple of times
<bryce> only a couple times?
<tjaalton> I've got no figures :)
<bryce> yeah I can see that as a benefit - for instance, especially if they pulled bulletproof-x from us
<tjaalton> but for the most part I've been pushing those there
<tjaalton> hehe
<bryce> however so far I get the impression that they would prefer our changes go upstream instead, so they pull from upstream, not from us
<RAOF> Why are so many files deleted from the upstream tarball in libdrm?
<tjaalton> RAOF: because they are shipped by the kernel
<tjaalton> bryce: well, packaging changes
<tjaalton> not so much upstream
<RAOF> That's a reason to not install them, but they'll still be there after unpacking the source, right?
<RAOF> Because the diff can't delete files.
<tjaalton> oh upstream tarball.. what files?
<RAOF> They're in the .orig.tar.gz, but not the debian tree.
<RAOF> Almost all of shared-core
<tjaalton> only userland bits are preserved
<RAOF> Right.  I think I know why I'm confused.
<tjaalton> except for nouveau
<RAOF> But also, I thought they weren't in the upstream tarball, either.
<bryce> tjaalton: let me ask this differently... what do you personally find most useful/beneficial with using git for -evdev for example?  What are the top things you would miss if you did not use vcs for it?
<tjaalton> bryce: right, one point I've forgot to mention; using 'git show foo' to pull upstream patches
<tjaalton> though you need to have the upstream repo in .git/config too, but it's a no-brainer
<bryce> xorg ---> 88 now
<tjaalton> so 'git show foo > 100_rad_feature.patch'
<bryce> yep, I do this already both with -intel and -ati
<mnemo> hmm, all my themes got borked when I install this mornings updates ;(
<mnemo> http://temp.minimum.se/Screenshot-Calculator%20-%20Programming.png
<mnemo> well, the default theme still works but I was using Dust and also clearlook theme has same problem etc
<bryce> mnemo: don't see the issue
<mnemo> mmkay
<bryce> mnemo: look in your /var/log/dpkg.log for what exactly changed
<bryce> then test reverting individual debs (which should be in /var/cache/apt/archives/) to find specifically what package causes the change
<mnemo> oh nice, I didn't know you could revert stuff like that... that's _very_ useful for debugging
<bryce> yep
<mnemo> found a bug in LP for this now --> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/327793   looks like many people got hit by theme issues during the night
<ubottu> Ubuntu bug 327793 in metacity "Window decorations in title bar missing with compiz enabled" [Undecided,New]
<tjaalton> bryce: did it answer your question?-) Also, tracking new upstream releases is less error-prone, since you know exactly what you've done to make it build etc
<bryce> tjaalton: well I agree git show is very useful in general, but don't see how managing my package in git would make it additionally more useful
<bryce> for the second point, could you explain more?  that sounds significant but not sure I understand the benefit completely
<tjaalton> ok, so without a vcs you grab the new tarball, and copy debian/ from the previous version in it. then you build it and if it doesn't, make changes one at a time so it does, and document them in debian/changelog
<tjaalton> this is nontrivial for libraries, where you have to update the shlibs files etc. and keeping track of things becomes harder
<tjaalton> also, if you are interrupted, it's harder to pick up where you were
<bryce> ah, okay.  does this happen often?
<tjaalton> interruptions? all the time :)
 * crevette raises an INT13
<bryce> heh, no, needing to update things for libraries ;-)
<bryce> I'm well versed in the interrupt thing ;-)
<bryce> (for instance, I get interrupted before I remember to push my changes to the vcs that I just finished uploading)
<tjaalton> when there are new (or changed) symbols in the new version. happens with libdrm at least, haven't touched that many libs yet
<bryce> xorg ----> 73
<tjaalton> looks like I'll be able to start my masters soon, at last
<tjaalton> *thesis
<bryce> tjaalton: congrats :-)
<tjaalton> the paperwork will take a while, but I hope to be able to graduate before christmas
<bryce> wow, that's not so long
<bryce> less than a year
<bryce> xorg ------> 61
<tjaalton> most of the topic is already done, it's just a matter of getting it written down and published
<tjaalton> wow, they fit in one page now :)
<tjaalton> bug 321340 should be fixed now, it's an openchrome bug
<ubottu> Launchpad bug 321340 in xorg "Cannot install 7.10, 8.04 xubuntu, Kubuntu on Averatec 3280" [Undecided,Incomplete] https://launchpad.net/bugs/321340
<tjaalton> moving it
<bryce> thanks
<bryce> yeah, goal is to get xorg off of https://bugs.edge.launchpad.net/ubuntu/+upstreamreport.  It was at #20 when I started.
<RAOF> The symbols file should refer to libdrm-nouveau1, rather than libdrm2, right?
<tjaalton> RAOF: depends on the symbols
<bryce> yay, xorg -> 58; bumps it down off the +upstreamreport \o/
<bryce> wow, inkscape is in the top 100 now
<tjaalton> cool
<tjaalton> I've marked a bunch of sync candidates on the versions_current page
<tjaalton> driver
<tjaalton> s
<bryce> tjaalton: cool
<bryce> at some point here I'll get around to getting xkeyboard-config merged
<bryce> erf, xorg jumped back up onto the chart
<tjaalton> where's the chart?
<bryce> http://people.ubuntu.com/~bryce/Plots/
<bryce> click X, then xorg
<tjaalton> oh that one
<bryce> also see http://people.ubuntu.com/~bryce/Graphs/totals.svg
<mnemo> bryce: i wanted to help out test the new intel freeze patch but I cant get the kernel code using the method I typically use? --> http://rafb.net/p/MHBYuK52.html
<tjaalton> weird, works here
<bryce> mirror issue??
<tjaalton> probably
<mnemo> I got "main server" configured in "software sources" at least
<mnemo> is there any other way to get the code?
<mnemo> there is a git repo for it right?
<mnemo> found it, git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git 
<mnemo> I guess it's okay to test the drm patches against that?
<tjaalton> yes, but easier to just use the package and then copy the drm.ko in place
<mnemo> cant I build drm.ko from the git tree?
<tjaalton> yes
<tjaalton> but it's a huge tree
<mnemo> but I will just build that module dir?
<tjaalton> don't know how to do that
<mnemo> all the kernel makefiles have a target called modules
<mnemo> so you can do:
<mnemo> make -C /lib/modules/`uname -r`/build M=$PWD modules
<tjaalton> just wget the package from http://a.u.c
<tjaalton> k
<bryce> tjaalton: do you think #226827 is actually an X bug?
<tjaalton> bryce: hard to tell, can't reproduce that's for sure
<bryce> xorg -------> 48
<tjaalton> heh
<tjaalton> that's probably a new all-time-low
<bryce> sweet
<mnemo> I have a g45 bug I havnt filed yet so make that 49 =P
<mnemo> or is that just for the xserver package?
<bryce> xorg
<mnemo> ok
<bryce> also I knocked out a couple more so we're at 46
<mvo> has anyone of you played with kenrel-mode-setting yet?
<bryce> mvo, not me
<bryce> mvo, heya :-)
<mvo> hey bryce :) 
<mvo> I did the other day on my i965 system and it did not quite work out (blank screen after the fb driver got loaded). and I was wondering if I was just unluky
<bryce> possibly.  there's a lot of things that can cause blank screens
<crevette> like usplash :)
<bryce> mvo, most recently was a usplash bug kees just fixed today
<bryce> yeah
<mvo> hm, I think I disalbled usplash on this machine. I haven't really diagnosed it in detail, funny thing that I was able to use vga= to force it into a mode and then it came up ok. but I guess its just the joy of pre-release kernels :)
<bryce> ahh
<bryce> ok, /me --> bed.  cya tomorrow
<mnemo> nn
<bryce> tjaalton: there's still some xorg bugs I think could be moved to better homes.  if you have some time to review them it'd be verry nicce
<tjaalton> bryce: sure, I can look at them. night
<tjaalton> mvo: umm, I'm not sure but I thought KMS was meant to replace the framebuffer driver, so using vga= would break things
<mvo> tjaalton: but with kms it will still present a /dev/fb device, no?
<tjaalton> mvo: I haven't tried, so don't know
<tjaalton> but AIUI using vga= means that it'll use vesafb
<mvo> when I checked the intelfb module was loaded, but again I could be wrong, just played with it briefly
<mvo> having vesafb would explain why it suddenly worked :)
<tjaalton> yeah :)
<RAOF_> tjaalton: OK.  There's something that looks very much like a version of libdrm that builds libdrm-nouveau1 in pkg-xorg git.  It'd be good if you could check it sometime to ensure I haven't made any howlers in git.
<RAOF_> I haven't actually built the new drivers to see that it works yet, though, so it's not ready to upload.
<mvo> tjaalton: you are quite right, vga= loads the vesafb driver, so my tests earlier today were mood
<tjaalton> mvo: that happens :)
<superm1> tseliot, i'm really wary of this solution to bug 326720
<ubottu> Launchpad bug 326720 in nvidia-graphics-drivers-180 "package nvidia-180-libvdpau None [modified: /var/lib/dpkg/info/nvidia-180-libvdpau.list] failed to install/upgrade: trying to overwrite `/usr/lib/libvdpau.so.1', which is also in package nvidia-glx-177" [Low,Fix released] https://launchpad.net/bugs/326720
<superm1> that means that if a package builds against libvpdau that it also requires an nvidia driver installed
<superm1> vdpau wasn't available in nvida-glx-177, so this shouldn't have been a problem
<bryce> heya superm1
<superm1> hi bryce 
<tseliot> superm1: yes, I know but we need to make sure that it doesn't conflict with any other nvidia flavour 177 or whatever Nvidia decides to make available
<superm1> tseliot, I would rather that there is a conflicts/replaces then.  adding that dependency won't work
<superm1> libvdpau was introduced in the 180 series, so this problem shouldn't have come up
<superm1> wasn't it?
<tseliot> superm1: it was introduced in 177, I guess
<tseliot> superm1: anyhow feel free to revert that change
<superm1> tseliot, ah yeah it was introduced in 177.82 it looks like.  just looked at the deb
<superm1> tseliot, so this being the case, I think just replaces: is the right solution
<tseliot> superm1: ok, fair enough
<tseliot> superm1: to tell the truth Update Manager should remove 177 in dist-upgrades so there shouldn't be real problems any more
<superm1> okay i'll upload a fix with just Replaces then for that rather than depends.  
<superm1> i wish nvidia would just release libvdpau as open source already so that this problem would resolve itself though
<tseliot> yes, that would help too
<superm1> tseliot, other than you no one gave any feedback on that patch I had for the screen resolution tool.  i was kinda surprised given how strong feedback was in both directions for the zapping feature.  is there anyone else I should poke to ask about it you think?
<tseliot> superm1: about your patch? No, I guess not. Your change doesn't affect all users and shouldn't clutter the UI
<superm1> tseliot, okay.  when will you have your other changes ready so I can merge it into the branch?
<tseliot> I gave seb128 my new patches therefore I think you should just wait for the new packages 25.90 to be available
<tseliot> then you can ask either mvo or seb128 just to be sure
<superm1> tseliot, do you have a merge proposal branch for those?  I'll just merge that locally and adjust my changes to take them into account now then
<tseliot> superm1: also, wouldn't it be better if you defined the names of nvidia-settings and amdcccle in some macros in the patch instead of touching the makefile (which in turn is touched by other patches)?
<tseliot> superm1: no, sorry my bzr was broken therefore I couldn't push my changes
<superm1> tseliot, I suppose that would make sense, I was hoping upstream would be willing to accept the changes too eventually, so it made sense to patch the makefile for them to take the patch as is
<superm1> i sent a feature request to gnome-control-center's bugzilla, but no one responded to it
<bryce> heya tseliot, how goes?
<tseliot> superm1: I wouldn't hold my breath on it. You did well though
<tseliot> bryce: hey, fine, thanks, a bit anxious but I'm ok
<tseliot> bryce: and you?
<superm1> tseliot,yeah i'm hoping it's not just denied because it supports closed drivers.  closed drivers exist, might as well work around their deficiencies rather than try to make your tools work with them
<bryce> tseliot: I'm ok.  threw out my back the other day but otherwise stuff is going well
<bryce> last week was pretty busy, but think I'll be caught up by today.
<bryce> tseliot: was just wondering if there's anything you're waiting on me for?  I got pretty behind on email last week.
<tseliot> bryce: I sent you an email about the xorg-options-editor but there's no hurry
<bryce> ok cool, yes I still have that on my plate to get to
<tseliot> bryce: does you back hurt too much?
<bryce> yeah
<bryce> I think sitting in bad chairs in the hotel + bad bed + bad airplane seat did it to me
<tseliot> the airplane can do that too
<tseliot> I hope you get well soon
<bryce> yep, I'm sure I will
 * tseliot > dinner
<bryce> jcristau: how have you been finding -ati 6.10.99.0 compared with 6.9.0?  I'm thinking of upgrading jaunty to that version; any major issues to worry about?
<crevette> hello
<crevette> I wonder why my session can't run compiz whereas my girlfried can ...
<crevette> at least the capplet telle me I can't
<bryce> what's your card?
<crevette> Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller
<bryce> ok, which version of ubuntu?
<crevette> jaunty
<bryce> should work 
<crevette> but I seen this behaviour since intrepid 
<crevette> this is weird because my girlfriend one the same laptop, in her session can run compiz :)
<tjaalton> did she log in first?
<crevette> she didn't log today
<crevette> the only active session is mine
<tjaalton> ok, the second running session has no dri with intel
<crevette> but I'm the only one which logged in today
<bryce> grep DRI /var/log/Xorg.0.log ?
<tjaalton> it's a session problem, not in x
<tjaalton> running compiz from a terminal should tell something
<crevette> compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0"
<crevette> compiz.real (core) - Fatal: No manageable screens found on display :0.0
<mnemo> hmm, I just found a "sync to vblank option" in ccsm.. I didnt know there was one
<mnemo> seems to work too, if I enable the benchmark plugin I can see the FPS go down to ~60
<mnemo> pretty nice
<bryce> ccsm?
<mnemo> compiz config setting manager
<mnemo> +s
<bryce> ah
<mnemo> by the way, at FOSDEM this year eric anholt said in a talk that "vblank is a mess" right now... he also said that their top priority ig going to be fixing that over the next releases (now that KMS, UXA etc is landing)
<bryce> hrm
<bryce> interesting; any particular reasons for the mess?  Something we should avoid for now I gather?
<mnemo> the talk was recorded.. phoronix will publish it eventually I think
<mnemo> its up actually
<mnemo> here it is:
<mnemo> http://www.phoronix.com/scan.php?page=article&item=intel_rebuild_x&num=2
<bryce> thanks
<bryce> darn, flash is busted for me right now
<mnemo> ;/
<mnemo> crappy audio though
<mnemo> actually the audio is useless all the way through, you'd probably be better of asking eric for the slides
<bryce> ugh, so intel is going not going to merge uxa back into exa after all
<mnemo> nah doesnt seem like it
<bryce> too bad
<mnemo> I wonder which one they are testing more carefully
<bryce> neither?  ;-)
<mnemo> for me UXA works _much_ better but on the wiki site I saw many old cards handle UXA pretty poorly
<mnemo> hehe
<bryce> there's problems with new cards too
<mnemo> maybe im lucky, UXA works perfectly for me.. nice FPS etc as well
<bryce> me too
<bryce> heya RAOF
<tjaalton> RAOF: you forgot to include one patch
<tjaalton> bryce: if the vblank madness isn't sorted out soon, we can disable it again in mesa
<bryce> ok
<bryce> tjaalton: yeah I think leading up to -beta there are going to be a few things we should look at disabiling
<bryce> maybe we could use a checklist... 
<mnemo> fwiw, I'd also prefer vblank disabled at least one more release
<mnemo> maybe fedora will ship it on and fix some of the bugs ;>
<RAOF> tjaalton: Oh?  Which patch?
<RAOF> Oh.  You mean I missed one from git?
<RAOF> Oh.  GAH!
<bryce> https://wiki.ubuntu.com/X/BetaReviewChecklist
<tjaalton> bryce: looks good
<bryce> anything else we should think about?
<bryce> guess we can add to it as we think of stuff
<tjaalton> yeah
<btQuark> just had a look at the betalist
<btQuark> i'm having fun with some r500 cards on 8.10 here and my 2 cents is: XAA is nice but close to worthless for realworld usage aka 3D, i'm using EXA here and did not experience a crash
<btQuark> in half a year
<btQuark> although the missing DRI2 is painfull. but anyway its ATI so pain was one of the main features advertised on the package
<btQuark> ah. yeah. well. there's that fglrx. that must've been included for those who did not yet have enough pain in their lives. definitly s/m stuff
<RAOF> Right.  Let's see if this new nouveau snapshot works, then...
<RAOF> That seems to be a 'yes'.
<bryce> :-)(
<RAOF> Hm.  How do you deal with copyright for a patch that adds a bunch of files under different holders?
<RAOF> Ok.  I think libdrm is OK.
<bryce> xorg ----------> 36
#ubuntu-x 2009-02-12
<bryce> xorg ------------> 25
<bryce> xorg --------------> 18    DONE
<bryce> tjaalton: for maybe the first time, the xorg package has mostly only bugs that are relevant to it :-)
<bryce> plus three that don't have enough info so it's not sure where to file them
<bryce> tjaalton: could you add a section to X/GitUsage explaining how to add a new package to git control?  E.g., xserver-xorg-video-ati
<tjaalton> bryce: wow!
<tjaalton> bryce: sure, I'll look at it later today
<tjaalton> it's basically just 'git checkout -b ubuntu' while you're on the branch that you want to branch from
<tjaalton> and then 'git push origin ubuntu' to push it the first time
<jcristau> bryce: i have no clue about the radeon driver
<btQuark> there's something i always wonder about
<btQuark> how can one construct such utter bullcrap as the fglrx driver
<btQuark> and why can nvidia construct something that is stable and equipped with a nice user interface and good functionality
<btQuark> i've just tried the newest fglrx straight from the amd website and it is plain offensive
<btQuark> an insult
<btQuark> i mean, at least it does not crash after seconds
<btQuark> it just crashes after i move a window with video content - but it had Xv and i was not in need to switch to X11 rendering with my Workstation Graphics board as needed before
<btQuark> and they're still not able to the least to make their own powerplay work on linux
<btQuark> the opensource driver does a better job - i actually felt the graphics chip being grilled although not used
<btQuark> and they dont even seem to have heard the word posix
<btQuark> if the ati/radeon driver would only have dri2 and some more speed optimizations
<btQuark> it would be perfect
<btQuark> maybe some more optimizations in for the powerplay
<superm1> tseliot, are all of your changes in the latest gcc upload, or did seb128 need to merge in a few more?
<seb128> what changes?
<superm1> tseliot said that there were a few updated patched for the gnome display tool that he sent to you to put in
<superm1> i was going to update my vendor fallback patch after they were in the archive
<seb128> I did upload 2.25.90 with his patches yesterday
<seb128> go for it
<superm1> okay great thanks
<tseliot> right
<bryce> morning
<superm1> g'mornin
<tseliot> morning
<seb128> superm1: btw did you get that patch discussed or review by somebody?
<superm1> seb128, me and tseliot talked about it 
<seb128> superm1: and when you open a bug upstream this way it would be nice to tag the patch, https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
<superm1> seb128, ah was not aware of these guidelines.  i'll make those changes in bzr then (but won't bother with uploading to the archive again with just commented changes like that)
<seb128> I've no strong opinion on the change but it would be nice to get somebody in the desktop team to approve your change before uploading desktop components
<seb128> thanks!
 * NCommander shines the bryce light into the midnight sky
<bryce> yep?
 * NCommander hopes you can help w/ an evdev issue
<NCommander> bryce, I'm playing with some ARM hardware with a working touchscreen, but the touchscreen is inverted. I tried the inverted options in xorg.conf, but they dn't seem to work
<NCommander> any ideas
<bryce> NCommander: not offhand; ogra may know, he's the master of touch devices
<NCommander> bryce, he sent me to you.
<bryce> tell me more about what you've already tried
<NCommander> InvertX/InvertY
<NCommander> Which didn't seem to work
<bryce> did you file a bug report?
<NCommander> bryce, well, it might be user error, w.r.t to syntax and such, I was hoping if you would know
<mahfiaz1> is there good how-to on adding synaptic device to xserver?
<bryce> NCommander: that's possible; I've never had a touchscreen to experiment with so am unfamiliar with the syntax myself
<NCommander> Right, that's my problem.
<tjaalton> bryce: I edited the GitUsage page a bit, 'Basic Tutorial' now mentions that pull/checkout is how you also create the ubuntu branch
<bryce> tjaalton: ok, I have a couple evdev revs to commit, but git is not working for me at the moment
<bryce> $ git push origin ubuntu
<bryce> fatal: The remote end hung up unexpectedly
<tjaalton> you mean the ones that were uploaded already?
<bryce> *ubuntu2 was uploaded already, *ubuntu3 is still in process here
<bryce> I'm having bug 328127 currently, which may be why git is broken
<ubottu> Launchpad bug 328127 in gnome-keyring "gnome-keyring-daemon returns Agent admitted failure to sign using the key." [Low,Triaged] https://launchpad.net/bugs/328127
<tjaalton> ok, ubuntu2 is missing from git
<bryce> right, I'm just saying I'll get it in as soon as I sort out my git breakage :-)
<tjaalton> heh, figured as much :)
<tjaalton> I'll upgrade to see if I have the same problem
<bryce> the `unset SSH_AUTH_SOCK` workaround doesn't seem to solve it btw
<tjaalton> what do you have as the origin url in .git/config
<tjaalton> I suspect the docs need an update :)
<bryce> [remote "origin"]
<bryce> 	url = git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-input-evdev
<bryce> 	fetch = +refs/heads/*:refs/remotes/origin/*
<tjaalton> bingo
<tjaalton> I have 'url = ssh+git://tjaalton-guest@alioth.debian.org/git/pkg-xorg/x-x-i-e
<bryce> yeah I was just following the directions in the docs to get to this point
<tjaalton> so if you clone like in the docs -> fail
<tjaalton> oh wait, the docs are right :)
<tjaalton> the wikipage I mean
<bryce> well the docs are for xorg/xserver, so for -evdev I started from the git URL printed out when I did an apt-get source
<tjaalton> you can change it directly in .git/config and it should work
<tjaalton> right
<bryce> oh oops, already rm -rf'd the tree
<tjaalton> hehe
<bryce> $ git clone git clone ssh://user-guest@alioth.debian.org/git/pkg-xorg/debian/xserver-xorg-input-evdev
<bryce> Initialized empty Git repository in /home/bryce/src/xserver-xorg-input-evdev/git/.git/
<bryce> fatal: no matching remote head
<bryce> hrm
<tjaalton> you need to change the $user
<bryce> dah, right
<bryce> hrm, still getting the same thing
<bryce> git makes me feel like such an idiot ;-)
<bryce> is 'pkg-xorg' right in the url?
<tjaalton> no
<tjaalton> sorry, yes
<bryce> hrm
<tjaalton> but s/debian/driver/
<bryce> ok... is my username 'bryce'?
<bryce> yep
<tjaalton> check the config from your xorg-server?
<bryce> $ git clone git clone ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/debian/xserver-xorg-driver-evdev
<bryce> Initialized empty Git repository in /home/bryce/src/xserver-xorg-input-evdev/git/.git/
<bryce> fatal: no matching remote head
<tjaalton> 20:21 < tjaalton> but s/debian/driver/
<tjaalton> :)
<bryce> what is the standard way for determining the url for a given package?
<bryce> same thing
<tjaalton> from the frontpage of git.d.o maybe
<tjaalton> append '.git'?
<bryce> ok, I think I looked for xkeyboard-config there yesterday but didn't see it
<bryce> nope
<tjaalton> it's called -input-evdev btw :)
<bryce> aha got it
<bryce> git clone git+ssh://bryce-guest@git.debian.org/git/pkg-xorg/driver/xserver-xorg-input-evdev
<bryce> needed the +ssh (and maybe s/alioth/git/)
<tjaalton> I used the one you pasted earlier and just changed s/driver/input/
<tjaalton> xkeyboard-config is pkg-xorg/data/xkb-data
<bryce> aha
<bryce> yeah, would be too consistent for it to be named xkeyboard-config ;-)
<tjaalton> ype
<tjaalton> yep
<bryce> tjaalton: committed and pushed
<bryce> tjaalton: mind verifying it pushed right?
<tjaalton> bryce: sure :)
<bryce> pushed one more small typo fix
<tjaalton> bryce: evdev?
<tjaalton> reboot, brb
<mahfiaz1> is there any trick to get external monitor to work on T61 with nvidia (Quadro NVS 140M)?
<bryce> mahfiaz1: nvidia-config ?
<tjaalton> bryce: I can't see any changes in evdev.git
<mahfiaz1> bryce, I tried it, but it ends up in loop of X restarts, it seems like there is some problem like it cannot initialize after some change of settings, things start to work after restart. I will give it some more try
<bryce> tjaalton: hrm
<bryce> $ git push origin ubuntu
<bryce> Agent admitted failure to sign using the key.
<bryce> Password: 
<bryce> error: src refspec ubuntu does not match any.
<bryce> fatal: The remote end hung up unexpectedly
<bryce> error: failed to push some refs to 'git+ssh://bryce-guest@git.debian.org/git/pkg-xorg/driver/xserver-xorg-input-evdev'
<tjaalton> bryce: probably still something wrong in your .git/config then
<bryce> [remote "origin"]
<bryce>         url = git+ssh://bryce-guest@git.debian.org/git/pkg-xorg/driver/xserver-xorg-input-evdev
<bryce>         fetch = +refs/heads/*:refs/remotes/origin/*
<tjaalton> looks correct
<bryce> *sigh*
<tjaalton> maybe the agent error is messing things up
<bryce> yeah could be
<tjaalton> dunno
<tjaalton> right
<tjaalton> because you don't actually have a password on alioth
<tjaalton> this relies on key-authentication
<bryce> after doing the `unset SSH_AUTH_SOCK` workaround, I try:
<bryce> $ git push origin ubuntu
<bryce> error: src refspec ubuntu does not match any.
<bryce> fatal: The remote end hung up unexpectedly
<bryce> error: failed to push some refs to 'git+ssh://bryce-guest@git.debian.org/git/pkg-xorg/driver/xserver-xorg-input-evdev'
<bryce> $ git push
<bryce> Everything up-to-date
<tjaalton> you have a local branch called 'ubuntu'?
<tjaalton> 'git status'?
<tjaalton> can you login to git.debian.org?
<bryce> $ git status
<bryce> # Not currently on any branch.
<bryce> nothing to commit (working directory clean)
<bryce> and no, I cannot log into git.debian.org
<tjaalton> you need to 'git checkout -b ubuntu origin/ubuntu' first..
<tjaalton> to create the local branch
<tjaalton> mentioned on wiki, then you can start committing stuff
<bryce> yes, I did that...  it shows your -1ubuntu1 commit in debian/changelog
<bryce> the last git log message before I added mine was:
<bryce> commit 56826701ad181dba4fdacc157ca53454ed12f20b
<bryce> Author: Timo Aaltonen <tjaalton@cc.hut.fi>
<bryce> Date:   Thu Jan 22 15:22:25 2009 +0200
<bryce>     Update the changelog for release.
<tjaalton> but the 'not currently on any branch' suggests that you are on top of origin/ubuntu
<bryce> maybe I forgot the -b ubuntu when I did the checkout
<bryce> ok, I think maybe it pushed now
<bryce> sheesh I suck at git
<bryce> too many flags I guess
<bryce> do you see it now?
<tjaalton> success :)
#ubuntu-x 2009-02-13
<LLStarks> sup.
<bryce> xkeyboard-config   54 --> 34
 * RAOF should get a standing FFe for nouveau.
<RAOF> Instead, he shall do the washing up.
<tjaalton> RAOF: I'll review libdrm this evening and upload
<bryce> night guys, I'm beat
<RAOF> While I think of it, xf86drmMode.h is broken.
<tjaalton> bryce: heh, night :)
<RAOF> bryce: Good work.  Sleep well!
<RAOF> I'd file a bug, but with my capped internet it'll take 10 minutes for launchpad to load
<bryce> tjaalton: all bugs in xkeyboard-config have been reviewed, old ones closed out, viable patches applied, upstreamable bugs upstreamed, etc.
<tjaalton> a heroic effort for sure
<bryce> there's a couple more that could be turned into proper patches with a bit of work, but I'll leave them for now.  Everything else is pretty much good to go for now.
<tjaalton> three releases within two hours :)
<bryce> hey, all the xorg work yesterday made a decent dent in overall bug numbers:  http://people.ubuntu.com/~bryce/totals.svg
<bryce> think next will be focusing on ATI.  Or maybe get blueprints squared away first
<bryce> -intel needs a lot of attention, too, but where to begin
<tjaalton> heh
<bryce> anyway... bed.  cya.
<tjaalton> bye
<LLStarks> hi
<LLStarks> does i915.modesetting=1 work with .29?
<tjaalton> no idea
<LLStarks> well.
<LLStarks> how do i enable kms then?
<LLStarks> is having a native res bootup considered kms?
<LLStarks> or does x have to launch?
<tjaalton> I've not used it yet, so..
<LLStarks> what i've seen so far is awesome.
<LLStarks> i can tell that plymouth is going to be orgasmic
<tjaalton> native bootup res is kms
<tjaalton> well, only after someone goes through the pain of writing a theme..
<RAOF> Unless it's just a vesa mode, right?
<tjaalton> yes
<RAOF> Hah!  Launchpad email interface FTW!
<LLStarks> brb
<LLStarks> testing out my roll
 * LLStarks tosses a 20-sided kernel
<tjaalton> hehe; http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.99.902-sod-off-poulsbo.patch?view=markup
<bryce> tjaalton: hah
<janc> bryce, are you around at this moment?
<janc> or anybody else who knows Xorg in Ubuntu very well?
<janc> last weekend I transported a multiseat-system from linuxservice.be to FOSDEM
<janc> and while talking to the company's owner he said he couldn't use Ubuntu on his "multiseat extfreme" which has 12 seats (12 LCD screens, 12 keyboards, 12 mice)
<janc> something about an X error that says there are "too many input devices"
<janc> but on Debian it just works
<janc> so I'm sure this must be possible to fix in Ubuntu  ;-)
<tjaalton> perhaps it just won't work with input hotplug
<janc> tjaalton, it works in 8.10 with up to at least 6 seats?
<janc> or do you mean it won't work in 9.04 at all?
<tjaalton> if it works in 8.10 then it's not that
<janc> I thought maybe it's a built-time parameter?
<tjaalton> you'd better ask the guy who did that
<janc> I mean the number of possible input-devices might be a built-time parameter (so it would be the packager who decides this)?
<tjaalton> I've not heard of anything like that
<tjaalton> sounds silly
<janc> hm, then I wonder what makes the difference between Ubuntu & Debian  :-/
<tjaalton> what version of debian?
<janc> I'm not sure, would have to ask him
<janc> I'll ask him for more details when I have the time to investigate further
<tjaalton> ok
<tjaalton> if it doesn't work in ubuntu, then I believe it'll be equally broken in debian experimental :)
<janc> but I know this limitation also existed last year's FOSDEM (thus Ubuntu 7.10)
<tjaalton> ok, so it's the other way around
<tjaalton> maybe he used the experimental version which is basically the same in jaunty
<janc> last year it worked in Debian too...
<janc> don't know which Debian though
<tjaalton> ok, well with this information there's not much I can say
<janc> yeah, that's why I hoped for a compile-time option  ;)
<tjaalton> at least the evdev driver shouldn't have such limitations
<janc> hm, actually, this might be related to Xgl too, as that is also needed for these multiseat-systems
<tjaalton> Xgl is dead
<janc> then how does compiz work with nvidia cards now?
<tjaalton> the xserver supports AIGLX
<tjaalton> for quite some time now
<janc> yeah, I know, but AFAIK nvidia doesn't, and he also needs an X-server on top of Xorg or something  ;)
<wgrant> nvidia has for ages...
<tjaalton> then he must have some really old drivers
<tjaalton> quite pointless to speculate what he had or didn't have :)
<janc> no, he needs an X-server running on top of Xorg for other reasons (from what I understood), it's just that there is no other useable option than Xgl or something
<janc> so he uses nvidia because they support Xgl
<janc> or something like that
<tjaalton> right, "something like that" :)
<janc> maybe I should find out how exactly these multiseats work
<bryce> haha
<janc> but I think it's important to keep them working on Ubuntu
<janc> and make them work as well as on debian
<tjaalton> no-one has been actively breaking anything
 * tjaalton whistles
<wgrant> Didn't Xgl even get killed off upstream?
<tjaalton> yes
<janc> he sells these systems to schools and such, so we want to keep the multiseat concept working  :-)
<tjaalton> then I'd expect him to complain if they don't :)
<janc> well, this is mostly an after-hours business for him...
<janc> and he can use debian instead of ubuntu, while I'd prefer he'd use Ubuntu on all systems  ;-)
<tjaalton> if it's a highly customized version (as it sounds), I don't care that much :)
<janc> it's not super-customized AFAIK (he only uses the default packages)
<janc> I mean, packages from the repos
<janc> no software that is compiled/packaged on the machine
<janc> or in an unofficial repo
#ubuntu-x 2009-02-14
<tjaalton> interesting.. tuxracer doesn't work with nvidia on jaunty
<tjaalton> *** etracer error: Couldn't initialize video: X11 driver not configured with OpenGL (Resource temporarily unavailable)
<tjaalton> sigh, and intel seems to crash on resume even without uxa
<mnemo> tjaalton: I current have 2826M RES on compiz.real in top... how can I file a meaningful bug report on that?
<mnemo> I mean can I enumerate the heap allocations and get the megabyte count for each allocation site?
<mnemo> for example, i would want the stack to the malloc that created these big chunks
<mnemo> i know valgrind can do something like this but only for apps you started from valgrind
<mnemo> i wonder if there is a way to "attach" valgrind to an existing process and then check the memory or something
<tjaalton> mnemo: sorry, I've no experience about that
<jcristau> fwiw MAXDEVICES is a build-time constant. (set to 20, apparently)
<tjaalton> ok, but not 6
<tjaalton> hmm
<tjaalton> but does the output device count? in that case "6 seats" might be the default limit (3 * (mouse, keyboard, output))
<jcristau> that's input devices
<tjaalton> ok..
<jcristau> with evdev you get a bit more than that. there's the vck and vcp, and then one for each physical device
<tjaalton> ok, so six sounds about right after all?
<jcristau> yeah
<tjaalton> hehe
<tjaalton> it's just hard to argue with the middle-man
<tjaalton> or easy, depending on how you see it
#ubuntu-x 2009-02-15
<quassel208> hi in jaunty i cant select anymore 1400 x 900, did you guys put a old driver there?
<mnemo> quassel208: have you solve the problem you had with not being able to select "1400 x 900" ??
<Ng> hmm, I forget where it was, but someone mentioned a thinkpad brightness regression in 2.6.27-11. finally rebooted from -9 and indeed my brightness keys are borked
<mnemo> Ng: maybe you can work around it using the "xbacklight" tool?
<Ng> I have no desire to do that :)
<Ng> I'll boot back into an older kernel
<mnemo> file a bug at least
<Ng> there seem to be several already, I'm collecting them together
<mnemo> aah ok
<tjaalton> someone still using intrepid?
<tjaalton> :)
<RAOF> I'm always surprised when people aren't running the bleeding-edge, development version :)
<stgraber> well, people who want working ATI drivers tend to stay on the stable version :)
<tjaalton> I upgraded my desktop yesterday, so every system is on jaunty now
<tjaalton> -ati works fine
<superm1> i've got a system still at 804 because my wifi doesnt work well in 810 or 904 still personally
<stgraber> if by fine you mean unaccelerated 2d, no 3d and no xv, yes it does :)
<stgraber> (I'm using it so I know it by far doesn't work fine with recent Radeon HD cards)
<mnemo> I got two jaunty and one intrepid... I keep email, irc and skype on intrepid just so I know I have something stable in case jaunty xorg is borked and I need to ssh into my real machine and grab stacktrace or something
#ubuntu-x 2010-02-15
<geser> tseliot: Hi, randomaction found a new issue with mesa over the weekend. in short: libgl1-mesa-swx11 is missing the ld.so.conf snippet
<tseliot> geser: is there a bug report about it?
 * tseliot reboots (brb)
<tseliot> geser: what was the error, exactly?
<geser> tseliot: no bug was filed (as far as I know). the problem is that rss-glx build-depends on libgl1-mesa-swx-dev which pulls in libgl1-mesa-swx11 but as it also has libGL1.so in /usr/lib/mesa but no ld.so.conf config the lib don't get found
<tseliot> geser: I think we can easily get rid of this problem by removing the abi-note tag from mesa and putting the libraries back in /usr/lib/
<tseliot> I think I'll do it after alpha 3 though as I need to focus on plymouth now
<geser> what ever works, should I file a bug for tracking?
<tseliot> geser: yes, please and assign it to me
<geser> tseliot: bug #522048
<ubottu> Launchpad bug 522048 in mesa "libGL.so.1 from libgl1-mesa-swx11 doesn't get found by applications" [Undecided,New] https://launchpad.net/bugs/522048
<tseliot> geser: thanks
<ara> tseliot, hey, have a couple of minutes for a chat?
<tseliot> ara: sure
<Sarvatt> tseliot: if they help any - http://sarvatt.com/downloads/patches/0001-Add-100_no_abi_tag.patch.patch  http://sarvatt.com/downloads/patches/0001-Install-alternatives-for-libgl1-mesa-swx11-as-well.patch
 * tseliot has a look
<tseliot> Sarvatt: both patches are appreciated :-) I'm extremely busy with plymouth and I couldn't have worked on them until alpha 3. Feel free to push/upload them. Thanks
<tjaalton> but only one of them is needed, right?
<tjaalton> hmm no, the alternatives is needed anyway
<Sarvatt> the abi tag one doesn't interfere with anything for now at least, i'm unsure what tseliot wants to do with mesa alternatives after having that so i didn't mess with that yet
<tseliot> Sarvatt: the abi tag is fine. As regards the other one, it should fix a bug (reproducible when libgl1-mesa-swx11 instead of libgl1-mesa-glx is installed)
<tseliot> right?
<Sarvatt> would be nice if we could get rid of the alternatives from mesa and move them to the things that provide an alternative libGL :D
<tseliot> but then you would have to uninstall the other packages that provide that alternative in order to switch back to mesa
<tseliot> which is not what we want
<Sarvatt> what if they provided both alternatives?
<Sarvatt> i need to build mesa with these changes to see if it needs more work, not sure i got everything there for swx11
<tseliot> do you mean, each nvidia driver and the fglrx driver should provide the alternative for mesa in addition to their own?
<jcristau> sounds like a mess
<jcristau> they don't depend on the mesa libGL so you might end up with dangling symlinks
<tseliot> Sarvatt: the latter can be a temporary fix as, thanks to the former, I should be able to move the mesa libraries back to their original location
<jcristau> or a missing libGL.so.1
<jcristau> (or maybe i'm missing something)
<tseliot> jcristau: I was asking to see if I was understanding things correctly
 * tseliot is still jet-lagged
<tseliot> Sarvatt: in conclusion the 1st patch should be ok. The 2nd should be ok (if well tested) as a short term fix (you might as well wait for my long term solution, it's up to you).
<Sarvatt> mesa is building in here with the libgl1-mesa-swx11 change - https://edge.launchpad.net/~sarvatt/+archive/bugfixes
<Sarvatt> need to figure out why mesa master stopped building for the past 3 days now :( https://launchpad.net/~xorg-edgers/+archive/ppa/+build/1508637/+files/buildlog_ubuntu-lucid-i386.mesa_7.8.0~git20100214.db18996d-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> hmm dpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/libglu1-mesa/usr/lib/libGLU.so.1.3.070800 (ELF format: 'elf32-i386'; RPATH: '').
<Sarvatt> so yeah libgl1-mesa-swx11 removes libgl1-mesa-dev libgl1-mesa-glx libglu1-mesa-dev libsdl1.2-dev ubuntu-desktop
<Duke`> :/
<Sarvatt> geser: http://paste.ubuntu.com/377015/
<Sarvatt> looks like libgl1-mesa-swx11 needs to be providing libgl1 as well also?
<geser> Provides: libgl1, libgl1-mesa-swrast, mesag3 (from the package in the archive)
<Sarvatt> yep same, odd
<Sarvatt> the changes i pushed in git seem to be fixing the steps to reproduce in your bug at least, don't know what else I should check
<geser> the dpkg output is because libgl1 is temporarily not installed until libgl1-mesa-swx11 is installed later
<geser> Sarvatt: if you want another test case for your mesa changes: try rebuilding rss-glx as it build-depends on libgl1-mesa-swx11-dev
<Sarvatt> doing that now
<Sarvatt> alternatives look fine still after installing the build deps, package is building now
<Sarvatt> configure: error: GL library was not found.
<Sarvatt> make: *** [config.status] Error 1
<Sarvatt> alternative is working fine from what I can see but autoconf doesn't like the non standard location?
<geser> have you looked at the config.log what exactly failed?
<Sarvatt> it does a AC_CHECK_LIB([GL],[glNewList]) and can't find glNewList in -lGL or -lMesaGL so it fails
<Sarvatt> that mean we need to install gl.pc in another package as well?
<Sarvatt> it's there though - 00224d20 T glNewList
<BUGabundo> hey
<BUGabundo> last night updates, manage to get 2.6.32-13-generic to boot fine (no 3D), while -12 stop starting X with high resolution
#ubuntu-x 2010-02-16
<ripps> oh please! someone backport this into the ati driver, kms xv is horrible right now. http://lists.x.org/archives/xorg-driver-ati/2010-February/013827.html
<bjsnider> does dh_installdocs normally look for a file called "faq" to install?
<bjsnider> oh, wait. i see where it's getting these instructions
<bjsnider> there's a guy in +1 that is using an nvidia card, doesn't have the nvidia or nouveau ddx driver running, but has working glxgears
<RAOF> bjsnider: Define âworking glxgearsâ.  glxgears should produce a picture with *any* DDX, and glxinfo should report direct rendering for pretty much any DDX, including VESA.
<bryceh> RAOF, see on phoronix fedora has 3d on nouveau?
<tjaalton> yes
<bryceh> hi tjaalton, how goes?
<tjaalton> but they have bskeggs so it's ok :)
<tjaalton> bryceh: hey, pretty busy with life. two exams left and the damn thesis..
<bryceh> tjaalton, plus all the kids... how do you do it?
<bryceh> tjaalton, graduation coming soon?
<tjaalton> and problems with nfsv4 which is holding back the thesis, but hopefully those are resolved soon
<bryceh> nfsv4... my old life...
<tjaalton> bryceh: the deadline is July 31st, but the thesis should be ready by the time lucid is released
<tjaalton> and I haven't even started writing yet
<RAOF> Urgh.
<RAOF> bryceh: Yeah, tjaalton pointed me at dri
<RAOF> Fedora's dri-drivers-experimental package, and I learnt just how awesome debian source packaging is :)
<bryceh> hehe
<RAOF> Versus âjust throw it in the .spec fileâ.
<tjaalton> bryceh: yeah, it's part of the new environment based on AD/krb5, and installs from altiris. quite a transition from full *nix-platform to one where "money is no object"
<tjaalton> including an exchange cluster which has a TB of memory :P
<bryceh> whoa
 * bryceh shudders @ exchange
<tjaalton> yeah, scalability and all that..
<bryceh> my dad has been a total windows junkie, but this weekend he had me wipe his laptop and put ubuntu on it... and he's extremely happy
<bryceh> I'd given him a netbook with ubuntu (one of those poulsbo-based ones) a while ago, so he knew what it was like
<tjaalton> my parents have yet to join the computing world. they're a bit old for that though (~70y)
<bryceh> his laptop is nvidia hardware, and I just set up -nv!  He was happy since he got video, flash, and all that working fine
<bryceh> I thought maybe I'd hold off on putting him on -nvidia and move him to nouveau once lucid's out
<tjaalton> good plan
<bryceh> hi ara
<ara> hey bryceh
<RAOF> bryceh: The lack of proper 18bit dithering didn't bother him?  I guess he might not know anything different.
<bryceh> I could see it, but he didn't seem to mind
<bryceh> I figured, "Hey, he's happy, don't push it.  Expectations low means plenty of room to improve from."  ;-)
<bryceh> RAOF, he was about ready to chuck the hardware and buy a new laptop, so this saved him a bundle
<bryceh> really all he uses the computer for is playing farmville and watching hulu
<RAOF> :)
<jcristau> Sarvatt: managed to get efifb->i915 working by enabling CONFIG_VT_HW_CONSOLE_BINDING
<BUGabundo>  pastebinit /var/log/Xorg.0.log.old   http://paste.ubuntu.com/377558/
<BUGabundo> I booted and got a green screen and no TTY
<BUGabundo> CAD on TTY1 rebooted , and it was all fine
<Sarvatt> hmm odd jcristau - CONFIG_VT_HW_CONSOLE_BINDING=y in the ubuntu kernels
<BUGabundo> eh
<Sarvatt> ahh crap, no wonder mesa stopped building, the gallium rules file I was keeping around got overwritten by the karmic rules file 
<BUGabundo> bah
<BUGabundo> so that's why I have no 3D ?
<Sarvatt> yep
<Sarvatt> now the nouveau api is completely screwed, not sure nouveau will build against this older libdrm
<BUGabundo> err
<BUGabundo> would that also explain my fail to boot, I pasted earlier ?
<BUGabundo> Sarvatt: Maximum number of clients reachedkmail: cannot connect to X server :0.0
<BUGabundo> I'm having a serious problem launching new windows after a few hours
<BUGabundo> and have to reboot
<Sarvatt> what the heck do you have using 512 clients?
<BUGabundo> how do i check how many I have?
<BUGabundo> cause I know I don't 
<BUGabundo> one gnome terminal, one chromium, two pidgin, one gwibber
<BUGabundo> that's all windows I have opened
<BUGabundo> $ ps auxw | wc -l
<BUGabundo> 199
<BUGabundo> Sarvatt: fresh boot, while aptitude upgrading http://paste.ubuntu.com/377756/
<BUGabundo> ======= Backtrace: =========
<BUGabundo> /lib/libc.so.6(+0x76a66)[0x7fcf5d23ba66]
<kklimonda> BUGabundo: do you think it's related to nouveau? :)
<BUGabundo> kklimonda: it was the only update (mesa) I got on this reboot
<BUGabundo>  17:54:23 up 10 min,  3 users,  load average: 0.09, 0.61, 0.52
<BUGabundo> I want to grab a snack, close the lit of my laptop , set to turn off screen only), when I came back, I couldn't interact with it, everything seemed to work, other then the LCD
<BUGabundo> so I jumped to TTY1 blingly and pressed CAD, fsck the disks, rebooted, aptitude upgrade X stuff, and got that
<kklimonda> BUGabundo: I had the same bug
<kklimonda> BUGabundo: check dmesg
<kklimonda> there should be something around the time lcd shut down for good
<BUGabundo> $ dmesg | pastebinit 
<BUGabundo> http://paste.ubuntu.com/377760/
<BUGabundo> nothing usefull there
<BUGabundo> oh on past boot
<kklimonda> not even boot but the whole last session :)
<pgraner> bryceh: mind if I add a multi-head column to the nouveau testing wiki?
<bryceh> pgraner, ok
<bryceh> pgraner, better make it 'dual-head' for clarification
<pgraner> bryceh: I have a few multi-head cards and I'm finding nouveau is failing on the higher end ones
<pgraner> bryceh: ack
<bryceh> pgraner, since -nvidia can do >2 heads, but -nv doesn't
<pgraner> bryceh: wildo
<Sarvatt> alot of complication with nouveau lately like I expected, they completely broke libdrm so it needs a nouveau module that wont be upstream until 2.6.34 so if we did a git snapshot that libdrm or a release if they do one soon it wouldnt work with our lbm-nouveau now
<Sarvatt> ugh looks like mesa requires that new libdrm-nouveau1 now as well so I can't skirt around it
#ubuntu-x 2010-02-17
<bjsnider> would the intel libdrm in karmic lpia be different than karmic i386?
<kklimonda> hmm.. I can't get nouveau to boot anymore: http://pastebin.com/f69948a29 - after ureadahead finishes loading files I can see some kernel oops scrolling fast though terminal and then I get black screen
<kklimonda> looks like it was a PEBKAC
<Sarvatt> bjsnider: yeah if you try to backport a newer libdrm to karmic where libdrm-intel1 doesn't build on lpia
<bjsnider> Sarvatt, i'm not talking about backporting anything, i'm just talking about what's int he archive. is the lpia build somehow different?
<bjsnider> a ppa build i sent in failed on lpia because of a missing symbol
<bjsnider> worked on amd64/i386 though
<Sarvatt> bjsnider: if you're really building against libdrm 2.4.14-1ubuntu1 it should be fine but if you're building against a newer libdrm than that the rules need adjusting because libdrm-intel1 doesnt build on lpia
<Sarvatt> heads up that the xorg-edgers/ppa might be broken for a bit later on today when I upload all the new nouveau stuff. got it all packaged now but not going to upload it until i'm home later incase something fails
<Sarvatt> did a lbm-nouveau based off upstream nouveau with drm interface version 0.0.16 and libdrm 2.4.18 and mesa needs that newer libdrm to build now as well
<bjsnider> Sarvatt, that's what happened. Apparently this need the libdrm-intel1 package
<bjsnider> why doesn't that package build on lpia?
<jcristau> i thought lpia was dead
<bjsnider> not on karmic
<Sarvatt> bjsnider: it does build on karmic with the libdrm in karmic, are you sure you're using 2.4.14-1ubuntu1? i looked at the rules in git for that release, maybe the one in the archive is different but that'd be a pretty major problem if it is
<Sarvatt> you can use the libdrm ~karmic from edgers if you want to see if that works, i made sure it builds on lpia in there
<Sarvatt> found another pretty major intel bug I've seen alot of complaints about - http://bugzilla.kernel.org/show_bug.cgi?id=14997
<ubottu> bugzilla.kernel.org bug 14997 in Video(DRI - Intel) "Closing and re-opening the lid does not reactivate the backlight" [Normal,New]
<tseliot> Sarvatt: maybe we just need this patch: http://bugzilla.kernel.org/attachment.cgi?id=25092
 * tseliot is updating his lucid system with intel
<Sarvatt> yeah got my eye on that bug, as soon as I see a fix go upstream i'll point the kernel people at it :D i dont have the problem but I've seen a few people in #ubuntu-desktop complain about not being able to close the lid
 * tseliot nods
<bjsnider> Sarvatt, what i mean is, the driver file i'm building needs the libdrm-intel1 package, which isn't on lpia. and i wondered why it wasn't.
<jbarnes> bryceh: are you shipping libdrm 2.4.18 yet?
<jbarnes> if not, you definitely should be :)
<jbarnes> it has a few fixes for random hang bugs that were biting a lot of people
<jcristau> i like how the libdrm 2.4.18 announce doesn't say anything about libdrm-radeon getting out of experimental status
<jcristau> which is probably the most noteworthy change in there
<Sarvatt> jbarnes: it's kind of sketchy, if we updated to libdrm 2.4.18 then all this nouveau stuff we just put in will be broken, I wish we could have had the 2.4.18 release 2 days earlier :D
<jbarnes> Sarvatt: well maybe you could cherry pick the intel bits between .17 and .18 then
<Sarvatt> yeah for sure
<Sarvatt> i'll do that in git when I get home if noone else has
<Sarvatt> argh, forgot libdrm/radeon: Fix section size mismatch to reset the section. was a bug fix we need as well, wish we could just use 2.4.18
<jcristau> get .18, revert the nouveau interface changes, might be easier?
<Sarvatt> well we could just revert nouveau: interface changes for 0.0.16 DRM and nouveau: bump MAX_PUSH to 512
<Sarvatt> nouveau: Regenerate nouveau_class.h. breaks the ddx in lucid currently as well
 * tseliot is uploading nvidia 195.xx
 * tormod parses a couple of month's worth of irc backlog
<tormod> everything set for Feature Freeze here? :)
<tormod> Sarvatt, I saw your call for a newer intel-gpu-tools, I have asked Eric about a new upstream release
<tormod> Sarvatt, me breaking ppa-purge -p? What was that about?
<BUGabundo> on boot, GDM has horizontal green lines
<BUGabundo> going to a TTY and doing $ sudo gdm stop
<BUGabundo> seems to re-spawn GDM and I autologin
#ubuntu-x 2010-02-18
<LLStarks> hey bryceh, would you recommend ati or nvidia for a new linux box if i exclusively use non-free drivers?
<bjsnider> nvidia, no contest
<LLStarks> reasoning?
<bjsnider> you're using the blobs, right?
<bjsnider> the nvidia driver gives you vdpau, opengl 3.2, xrender accel
<bjsnider> support for newest x servers and cards right away
<JanC> OTOH, like I saw twice during the last 10 days, people can't seem to get there laptop to work together with a beamer if they have nvidia  ;-)
<LLStarks> what about free drivers? how are nv, nouveau, radeon, and radeonhd?
<bryceh> they all suck
<bryceh> buy a mac
<bjsnider> they're all crap
<LLStarks> no 3d?
<bryceh> radeon's ok
<bryceh> at least for R500 and earlier
<bjsnider> the intel driver is the ony good foss graphics driver
<JanC> radeonhd has 3D if you have the exact same card as the developers IIRC  ;)
<JanC> (or was it the radeon driver?)
<LLStarks> intel graphic drivers are godly. intel graphic hardware is crap.
<LLStarks> how is gallium coming along?
<LLStarks> can i expect nouveau to perfect it and all of xf86-intel to use it by the end of 2011?
<bjsnider> not ready for prime time
<JanC> AFAIK gallium is a tool (library) to make 3D graphics drivers, it's not a graphics driver in itself...
<bjsnider> possibly
<JanC> ?
<LLStarks> heh. i though gallium was replacing mesa.
<LLStarks> or do i have a completely incorrect view of how graphic stacks work?
<bjsnider> not anytime soon, that's for sure
<JanC> well, mesa is used for something like that too  ;)
<JanC> as I understand mesa, it implements OpenGL in software, and lets drivers override that by hardware-supported methods
<LLStarks> hm
<bjsnider> i don't know how anyone tolerates the fglrx/ati drivers
<JanC> """Gallium3D is a software library for 3D graphics device drivers being developed by VMware (previously Tungsten Graphics).[1] Gallium3D operates as a layer between the graphics API and the operating system with the primary goal of making driver development easier, bundling otherwise duplicated code of several different drivers at a single point."""
<JanC> http://en.wikipedia.org/wiki/Gallium3D
<bjsnider> when i put this system together i tolerated it for 15 minutes before returning the card
<LLStarks> wut. vmware gobbled tungsten?
<JanC> maybe for the better (let's hope)
<LLStarks> anyway, i have a question about the 2.6.33 backport plans. which option is being considered most heavily?
<JanC> LLStarks: I guess vmware wanted 3D graphics knowledge for VMs
<LLStarks> that's good. 3d emulation sucks.
<LLStarks> as long as they keep it gpl
<JanC> well, I guess they want 3D passthrough  ;)
<kklimonda> bryceh: if I have to add resume=/dev/sdXY to resume from hibernation should I mark test as passed or nt?
<kklimonda> not*
<kklimonda> bryceh: I'm talking about nouveau evaluation
<bryceh> not
<bryceh> mark it failed and list what you did to work around it
<bryceh> kklimonda, btw thanks for helping with testing :-)
<kklimonda> bryceh: and when testing dual head should I mark it as failed if nouveau fail to detect that I've plugged my monitor until I use xrandr or display from preferences menu?
<kklimonda> plugged or unplugged
<bryceh> if you can get it to work after fiddling with xrandr, count it passed
<bryceh> kklimonda, but we're not sticklers on what counts as passed or failed; kind of use your judgment, if you feel the driver is really sucking on something, fail it.  If you think it's adequate, give it a thumbs up
<bryceh> remember we're comparing against -nv, so that's a pretty low hurdle ;-)
<kklimonda> bryceh: I should mark all tests as passed then - maybe leave hibernation one as failed..
<bryceh> kewl
<kklimonda> bryceh: are all required bits for nouveau uploaded to archive or do I still have to use xorg-edgers ppa?
<kklimonda> I'd like to reinstall system when alpha3 is released and test it on clean install
<bryceh> kklimonda, I'm pretty pleased with the testing that folks have done.  It's giving me confidence that we're going in the right direction with nouveau.  We may have some issues to square away but I don't feel like we're going to need to go back to -nv or anything drastic
<bryceh> kklimonda, there are still a few bits outstanding for nouveau.  I think we may have them all in by the end of the week
<kklimonda> bryceh: for example packages that have been uploaded to archive seem to be missing nouveau_kvm_hook for initramfs.. or maybe I don't have the right package installed
<kklimonda> bryceh: I'm really pleased with nouveau myself - especially now that there are so many weird problems with nvidia driver in lucid :)
<bryceh> yeah I'm not sure whether linux-backports-modules is in yet, but we'll need that in the archive before we can really start wrapping things up
<RAOF> kklimonda: The kms hook really needs to go into the framebuffer hook shipped with initramfs-tools.
<tjaalton> any pending changes to mesa, or should I upload what's in git now?
<tjaalton> Sarvatt: ^
<tjaalton> xserver 1.7.5 merged
<sebner> tseliot: your new nvidia upload to lucid drops my glxgears frames rate about 5-10k (to half maybe)
<tseliot> sebner: what does glxinfo say?
<sebner> tseliot: http://pastebin.com/m59fe117a
<tseliot> sebner: it's not the final release so it might be a temporary regression
<sebner> kk
<tseliot> sebner: do 3D applications seem slower?
<sebner> tseliot: definately
<tseliot> glxgears is not a benchmark
<tseliot> ok
<tseliot> sebner: also what does this command say? "ldconfig -p | grep GL" and does the X log show anything interesting?
<sebner> tseliot: http://pastebin.com/m213d74b2 Xorg log shows acpi failure (dunno if this is new though)
<tseliot> sebner: maybe nvidia is doing something "new" ;)
<tseliot> but other than that it should be fine
<sebner> heh
<sebner> kk
 * sebner will just wait until mighty tseliot gets his hands on a new and fixed driver then :)
<tseliot> ;)
<Sarvatt> tjaalton: whats in git now works for mesa, the bug fix for building rss-glx is waiting on moving libGL back to /usr/lib as far as I can see but the alternatives for libgl1-mesa-swx11 are working fine
<bryceh> heya Sarvatt
<bryceh> Sarvatt, what's your opinion on sticking with 2.9.1 vs moving to 2.10 for -intel?
<Duke`> no execbuf error for days... Duke` is happy \o/
<bryceh> Duke`, is that with stock lucid or xorg-edgers?
<Duke`> xorg-edgers
<Duke`> on karmic
<bryceh> tjaalton, heh the comments on the phoronix article are arguing every single opinion on this.
<bryceh> a third think we're crazy not to be using the 2.6.33 kernel, a third think we're crazy to be considering backporting *anything* from 2.6.33 for an lts, and a third are crazy themselves
<RAOF> Are you sure those groups have no intersection? :)
<bryceh> RAOF, ;-)
<BUGabundo> ehe
<BUGabundo> bryceh: what are we backporting from .33?
<bryceh> it's a bit irritating how closely phoronix follows our development discussions.  It's like having a conference call and someone hooks the phone to the loudspeaker at comdex
<bryceh> BUGabundo, drm
<bryceh> BUGabundo, RTFPhornix ;-)
<BUGabundo> ?
<BUGabundo> that I don't know
<bryceh> probably for the best
<tjaalton> bryceh: haha :)
<tjaalton> Sarvatt: ok, I'll probably upload it tomorrow until someone gets to it before me
<bryceh> tjaalton, mesa?
<BUGabundo> any news on fixing 3D in nouvuea?
<BUGabundo> been broken since Sunday
<tjaalton> bryceh: yep
<bryceh> tjaalton, great
<RAOF> BUGabundo: -ENOTSUPPORTED!  Without having looked at it, I'd guess that it now requires libdrm 2.4.18 and a drm interface version 0.0.16, which means pulling from nouveau's linux tree rather than linus.
<BUGabundo> ok
<BUGabundo> thanks
<RAOF> If we end up planning on pulling 2.6.34 intel & radeon into linux-backports-modules, we may well end up pulling in the 0.0.16 nouveau drm interface soon.
<persia> Hey.  Seems that the latest x11-common pulls in a heap of -dev packages.  Is this intentional?  What use case does it support?
#ubuntu-x 2010-02-19
<RAOF> persia: Where are you getting this x11-common?  I see âdebconf (>= 0.5) | debconf-2.0, upstart-job, debianutils (>= 1.13), lsb-base (>= 1.3-9ubuntu2)â as the full list of depends for x11-common=1:7.5+1ubuntu3
<bryceh> persia, there haven't been any recent changes to x11-common which would change that
<bryceh> (at least, not in git)
<persia> Ugh.  I can't replicate for some reason.
<persia> I really just saw this with a lucid upgrade (which I didn't perform).
 * persia goes hunting, and apologises for the noise
<bryceh> no prob
<persia> In case anyone else complains, blame onboard.
<RAOF> So, we need to put the update-initramfs hook for nouveau in a package somewhere.  lbm-nouveau-2.6.whatever would be the obvious choice, but that needs to be parallel-installable, so that'd be awkward.
<RAOF> The linux-backports-modules-nouveau-lucid-{generic,generic-pae} metapackages from linux-meta would be another option, but they're not set up to actually ship files at all.
<RAOF> Finally, xserver-xorg-video-nouveau would be possibly the easiest option, but feels a bit wrong because it's not really the same package as the kernel module.
<RAOF> Does anyone have any firm opinions one way or the other?
<bryceh> RAOF, no firm opinion
 * bryceh ponders
<bryceh> don't we run update-initramfs with -nvidia?
<RAOF> We might, if we now try to blacklist nouveau when we install -nvidia.
<RAOF> But before then, why would we?  nvidia.ko doesn't want to be in the initramfs.
<bryceh> I think it was being done for removing nouveau
<bryceh> tseliot would probably be the one to solicit an opinion from
<RAOF> That would probably be right.  We'd need to blacklist nouveau good and early, lest it be in the initramfs and grab the hardware before nvidia.
<bryceh> right
 * RAOF heads off to send *another* offer to the real estate agent.
<bjsnider> RAOF, i thought you didn't want nouveau to be the default in lucid
<bryceh> RAOF, aha debian/nvidia-96.postinst.in
<bryceh> bjsnider, ?
<bjsnider> because nouveau depends on an experimental libdrm
<libv> heh, you're all wasting your time. People will fight anything that means changing any of their current mindset or working practices. Reasons like "we are trying to run a business and making the linux desktop work" are deemed completely irrelevant upstream. All that matters to some people upstream is their own fun and big statements proclaiming how great they are. There is no point discussing, just do the work, and prove things _hard_ an
<vish> hmm , something in today's -edgers update makes high Xorg CPU usage if xchat is opened :(  
<vish> it turns out that if the progress meter graph is displayed it burns CPU on and ATI
<vish> similar to Bug #355355
<ubottu> Launchpad bug 355355 in update-manager "Update Manager causes high Xorg CPU usage when checking for updates" [Medium,New] https://launchpad.net/bugs/355355
<vish> xorg (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3
<vish> xserver-xorg (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3
<vish> xserver-xorg-input-all (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3
<vish> xserver-xorg-video-all (1:7.5+1ubuntu2) to 1:7.5+1ubuntu3
<vish> xserver-xorg-video-ati (1:6.12.99+git20100215.47136fa3-0ubuntu0sarvatt) to 1:6.12.99+git20100218.a3b730ec-0ubuntu0sarvatt
<vish> xserver-xorg-video-radeon (1:6.12.99+git20100215.47136fa3-0ubuntu0sarvatt) to 1:6.12.99+git20100218.a3b730ec-0ubuntu0sarvatt
<vish> those were the updates ^
<vish> oh , not xchat alone ....  it happens with _any_ progress bar , if i activate widget factory [which previews themes] Xorg starts to use high CPU
<vish> and only when the progressbar is using the _murrine_ engine
<tjaalton> bryceh: isn't nv needed for the fallback, and for those devices where the server automatically chooses it and not nouveau?
<RAOF> There are a couple of cards that fall into that category; the rivas at least won't be driven by -nouveau and should be driven by -nv, yeah.
<bryceh> ah ok
<RAOF> I think I'll put the kms hook in x-x-v-nouveau for now.  Are we aiming for libdrm 2.4.18 for alpha 3, or shall I pass on updating the DDX until after A3?
<bryceh> I think we should at least do 2.4.18 sans the API bump patch for a3
<RAOF> Ok.  So I'll look at pulling a newer DDX, changing the dependency to the lbm metapackage (already in git), and putting in the kms hook this evening.
<bryceh> RAOF, oh, I just changed the dependency to the lbm metapackage
<bryceh> sorry, didn't realize you'd already done that
<bryceh> we needed it to get the cd's buildable
<RAOF> That's fair enough.
<bryceh> $ git push origin ubuntu
<bryceh> fatal: The remote end hung up unexpectedly
<bryceh> ^ that's from trying to push the aforementioned change to the nouveau git tree
<RAOF> I'll merge it in to my tree locally, if you like
<bryceh> thanks
<dholbach> hiya
<dholbach> so I just had the nouveau driver installed, I rebooted and I just get a black screen
<dholbach> after a while I get the drum sound of the gdm login, but the monitor doesn't seem to get any signal
<tjaalton> what if you boot without splash?
<tjaalton> could be a plymouth bug
<RAOF> Why must git-buildpackage mock me?
<RAOF> Any ideas what's happening here? http://pastebin.ca/1802514
<dholbach> tjaalton: same :/
<tjaalton> RAOF: never used it..
<RAOF> dholbach: Do you have a dmesg?  Particularly: is vga16fb loaded?
<dholbach> aniel@bert:~$ dmesg  | grep -i vga16fb
<dholbach> [    2.211558] vga16fb: initializing
<dholbach> [    2.211563] vga16fb: mapped to 0xffff8800000a0000
<dholbach> daniel@bert:~$ 
<RAOF> Ding.
<RAOF> We need to add lbm_nouveau to the initramfs so that it'll take over before vga16fb gets loaded.
<tjaalton> so people upgrading now will "hose" their systems?
<RAOF> Possibly.
<dholbach> what do I do now? :-D
<tjaalton> unload the module and load lbm_nouveau instead
<tjaalton> then start gdm
<RAOF> You could also check that adding this: http://pastebin.com/d7755dc1b to /usr/share/initramfs-tools/hooks/nouveau_kms and make it executable, and run update-initramfs.
<RAOF> There was a hook in the linux-backports-modules-nouveau package; that seems to have been lost along the way.
<dholbach> hum, seems I can't rmmod vga16db easily
<dholbach> how do I find out what "uses it"
<RAOF> The VTs, I think.
<dholbach> man, I'm so glad I don't have to do this very often
<tjaalton> dholbach: stop gdm first
<dholbach> tjaalton: did that already
<tjaalton> ok
<RAOF> tjaalton: Will that work?  His VTs are useing vga16fb, aren't they?
<dholbach> daniel@bert:~$ sudo rmmod -f vgastate vga16fb
<dholbach> ERROR: Removing 'vgastate': Resource temporarily unavailable
<dholbach> ERROR: Removing 'vga16fb': Resource temporarily unavailable
<dholbach> daniel@bert:~$ 
<jcristau> need to unbind first, i think
<dholbach> RAOF: 
<dholbach> daniel@bert:~$ sudo update-initramfs -u
<dholbach> update-initramfs: Generating /boot/initrd.img-2.6.32-13-generic
<dholbach> woozy: Possible missing firmware /lib/firmware/nouveau/nvac.ctxvals for module lbm_nouveau
<dholbach> woozy: Possible missing firmware /lib/firmware/nouveau/nvac.ctxprog for module lbm_nouveau
<dholbach> ...
<dholbach> ...
<dholbach> ...
<RAOF> dholbach: That's ok.  That'll mean if you've got a geforce 8 or higher you won't get accel, but it should at least bring up X.
<dholbach> alright, I'll take the plunge
<RAOF> Oh!  And nothing depends or recommends nouveau-firmware.
<RAOF> That got lost from linux-backports-modules-nouveau, too.
<dholbach> grub, a lot of flickering back and forth, "No signal detected", gdm's drum sound, no screen
 * dholbach installs firmware
<dholbach> grub, less flickering back and forth, "No signal detected", gdm's drum sound, no screen
<dholbach> daniel@bert:~$ dmesg  | grep vga16fb
<dholbach> [    2.216952] vga16fb: initializing
<dholbach> [    2.216957] vga16fb: mapped to 0xffff8800000a0000
<dholbach> daniel@bert:~$ 
<dholbach> RAOF: ^
<RAOF> :(
<dholbach> http://paste.ubuntu.com/379657/
<dholbach> detected a tv connector - wow - i didn't even know I had one
<dholbach> RAOF: does the pastebin tell you anything?
<tseliot> tjaalton: are you going to update radeon soon? I would like to add this quirk: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=e68d3a3890fc81c51f2006b5548da1e8756ad2fd81c51fi
<dholbach> tseliot: Bad object id: e68d3a3890fc81c51f2006b5548da1e8756ad2fd81c51fi
<tseliot> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=e68d3a3890fc81c51f2006b5548da1e8756ad2fd
<dholbach> :)
<tjaalton> tseliot: nah, you can add it on top of the current one as a patch :)
<tseliot> tjaalton, dholbach: something must have messed with my clipboard
<tjaalton> bryce has handled it so far
<tseliot> tjaalton: yes, I just wanted to avoid uploading this patch if you had already planned to update the driver
<tseliot> ok
<tjaalton> I'll do libdrm and mesa
<tseliot> good
<tjaalton> xserver would probably need a FFe by now :/
<dholbach> RAOF, tjaalton: shall I just deinstall those nouveau packages or is there anything I can test?
<tjaalton> actually so does libdrm
<tjaalton> meh
<tjaalton> dholbach: tbh I haven't played with nouveau yet
<tseliot> tjaalton: the xserver? Why?
<tjaalton> tseliot: 1.7.5
<RAOF> dholbach: Final check - was the initramfs you built for the kernel you booted into?
<tseliot> oh, I missed another release
<tseliot> tjaalton: if it's only bug fixes I don't think we need a FFE
<tjaalton> tseliot: but will they get stuck in a queue?
<dholbach> RAOF: let me retry to make sure
<dholbach> sudo update-initramfs -u -k all
<RAOF> That should make it happen.
<tseliot> tjaalton: no, I don't think so
<tjaalton> tseliot: ok cool, I'll upload that as well then
<tseliot> good
<dholbach> daniel@bert:~$ ls -l /usr/share/initramfs-tools/hooks/nouveau_kms
<dholbach> -rwx--x--x 1 root root 242 2010-02-19 11:43 /usr/share/initramfs-tools/hooks/nouveau_kms
<dholbach> daniel@bert:~$ dmesg | grep vgs16fb
<dholbach> [    2.197797] vga16fb: initializing
<dholbach> [    2.197801] vga16fb: mapped to 0xffff8800000a0000
<dholbach> daniel@bert:~$ 
<dholbach> RAOF: ^ no dice
<tjaalton> why does nouveau conflict with that anyway?
<tjaalton> intel is working ok with it
<RAOF> And why does booting into recovery mode suddenly make it work, even with vga16fb?
<dholbach> anything else I could test?
<tjaalton> RAOF: at least plymouth is not used then
<RAOF> tjaalton: Yeah.
<RAOF> dholbach: Test without splash?
<dholbach> I did that
<dholbach> didn't help either
<RAOF> does recovery mode work for you, too?
<tseliot> dholbach: what does this command say? grep nouveau /etc/modprobe.d/*
<dholbach> tseliot: nothing
<dholbach> RAOF: let me try
<tseliot> ok
<dholbach> RAOF: no dice either
<dholbach> RAOF: even worse - I can't ssh into it
<dholbach> tjaalton, RAOF, tseliot: anything else I can try before I remove those packages again?
<dholbach> to me it sounds like this should at least be in #ubuntu-devel's topic or something
<tjaalton> dholbach: I'm out of ideas..
<dholbach> it's going to screw a bunch of people
<RAOF> I'm out, too.
<dholbach> if they can't ssh into it from another machine or have a live cd handy they're screwed
<tjaalton> I'll try it on the desktop I have
<tseliot> dholbach: do you have an X log and the output of dmesg we can have a look at?
<RAOF> Has the patch to make X autoload nouveau not yet made it into the main packages?
<dholbach> tseliot: http://people.canonical.com/~dholbach/dmesg http://people.canonical.com/~dholbach/Xorg.0.log
<tjaalton> RAOF: hah, good point
<dholbach> RAOF: can I try that patch somewhere?
<tjaalton> there we go
<tjaalton> it loads nv
<tseliot> tjaalton: we don't have an ubuntu branch for radeon, do we? (I bet I asked you the same thing last time I uploaded radeon)?
<tjaalton> I'll upload 1.7.5 merge asap
<tjaalton> tseliot: no
<tseliot> ok
<dholbach> if you have the patch, I'm happy to build packages locally to try it out
<tjaalton> dholbach: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=cfdca8e85ca73f18edaeff1a411e356afac2bc4c
<tjaalton> ..selectively
<tseliot> dholbach: it looks like you loaded nouveau (the kernel module) but you're using the "nv" X driver
<RAOF> I've just booted up my laptop; it's booted fine, and is using nv successfully with the nouveau kernel module loaded.
<tseliot> dholbach: maybe try creating this xorg.conf? http://pastebin.ubuntu.com/379673/
<tseliot> hmm...
<RAOF> Oh, whoops.  I think because I've got the initramfs hook.
<dholbach> RAOF: the hook that I have?
<dholbach> tseliot: I'll try tjaalton's patch first (just building), if that fails, I try that xorg.conf
<RAOF> dholbach: The hook that you have, yes.
<tseliot> dholbach: oh, I missed that patch. That should work
<dholbach> tseliot: I haven't lost hope yet :)
<tseliot> that's the spirit ;)
<RAOF> Rebuilding the initramfs with that hook made it work for me.
<RAOF> And, again, booting without âquiet splashâ works, ish for me.
<dholbach> new xserver installed
<dholbach> let's see what happens
<dholbach> yeeeeeeeeehaw
<RAOF> Win?
<dholbach> yep
<dholbach> let's get all those changes uploaded asap
<dholbach> the firmware change, the added initramfs hook and the xserver patch
<RAOF> Why does vga16fb get loaded anyway?
<dholbach> xorg-xserver
<dholbach> I dunno, but right now people who upgrade and restart will get bitten
<tjaalton> xorg-server uploaded
<dholbach> thanks guys for fixing this
<RAOF> tjaalton: I've got a nouveau with the initramfs hook and updated to build against libdrm 2.4.18.  I'm just test-building it.
<tjaalton> RAOF: so I should basically drop all the patches you added, and revert the two commits?
<RAOF> Yes.
<tjaalton> right
<RAOF> I can extract out the update requiring 2.4.18 if libdrm will take a while.
<tjaalton> no I'm on it
<tjaalton> hmm, what's the best way to generate a reverse patch?
<tjaalton> git show foo > ...
<jcristau> git revert, git format-patch, git reset --hard?
<RAOF> That'd work.  git revert foo; git show foo'scommit
<tjaalton> maybe I'm not doing it hard enough, stops right away
<tjaalton> hmm, patch -R could be useful
<tjaalton> then git diff
<tseliot> radeon uploaded
<tjaalton> one hunk failed, otherwise it worked
<tjaalton> right, needed to revert the smaller commit first
<tjaalton> RAOF: libdrm pushed and uploaded
<RAOF> tjaalton: xserver-xorg-video-nouveau in alioth git should be ready to go, too.
<RAOF> But I can't upload it, 'cause it's in main.
<tjaalton> RAOF: ok, I'll upload it too
<RAOF> Thanks.  It's getting late here - you might want to give it a quick sanity check first.
<tjaalton> sure
<tjaalton> "if it builds, ship it"
<tjaalton> :P
<RAOF> Well, it certainly builds, I can check that mechanically :)
<RAOF> And with that, I bid goodnight.  Thanks!
<tjaalton> thank you
<tjaalton> oh bah, forgot to build-check libdrm. missing symbols
<tjaalton> well, symbol
<dholbach> RAOF: what is going to depend on nouveau-firmware?
<dholbach> and where is usr/share/initramfs-tools/hooks/nouveau_kms going to live?
<tjaalton> the hook comes with xserver-xorg-video-nouveau
<tjaalton> I think the lbm package should depend on the firmware, not sure though
<dholbach> isn't that ... like ... very important stuff? :)
<tjaalton> yes
<tjaalton> ask on #ubuntu-kernel :)
<tseliot> naah, who wants a working graphics driver these days :-P
<tjaalton> totally overrated
<tseliot> absolutely
<tjaalton> I'll have my terminal kthxbye
<kklimonda> tjaalton: does it make sense for the hook to come in the xorg driver package? is nouveaufb unusable without xorg driver for some reason?
<tjaalton> kklimonda: that's where RAOF put it, probably because he could touch the package more easily
<kklimonda> ach, I see
<apw> tjaalton, the x userspace for i915 will that cope with a .33 kernel?
<jcristau> yes
<tjaalton> apw: right
<tjaalton> apw: aiui there should be no abi breaks anymore, at least planned ones, apart from the nouveau one we talked about
<apw> tjaalton, we need to understand the scope of the patches this nouveu stuff is going to drop on us
<tjaalton> apw: it only touches nouveau
<tjaalton> and the upstream ddx needs it
<apw> yes. but i need to understnad the maintenance issues it will cause for us if we have that on top of the other backports we are contemplating
<apw> who would be able to point me at what is needed
<tjaalton> so backporting fixes will be tough without it
<tjaalton> sorry being slow, baby on lap, 
<tjaalton> duh
<tjaalton> and cant type on my e71
<tjaalton> apw: RAOF is the one on top of things
<apw> and tracking any stable upstream branches will be hard with it, so i need to know what it looks like to try and figure out how much pain it represents
<tjaalton> there was no nouveau in .32, so the stable branch will be a non-issue :)
<apw> tjaalton, and there will be in the .33 stable branch
<apw> which is why it matters
<tjaalton> maybe airlied could answer that
<tjaalton> if there will be nouveau fixes in .33.x
<tjaalton> since there is no released ddx/libdrm with the .33 abi
<tjaalton> so it would feel pointless to add nouveau fixes on the stable branch
<Sarvatt> RAOF: any ideas about this? http://launchpadlibrarian.net/39392763/buildlog_ubuntu-lucid-i386.linux-backports-modules-2.6.32_2.6.32-13.999~git20100218~xorgedgers_FAILEDTOBUILD.txt.gz
<Sarvatt> not having any luck building nouveau with the new api
<Sarvatt> argh gotta disappear again, so busy the past few days
<Sarvatt> if anyone is still getting the sigquit and gdm restart after pressing enter the first boot issue, can you try compiling this kernel module and loading it before reproducing it? I can't make it happen anymore http://sarvatt.com/downloads/trace-signal.c
<Sarvatt> compile instructions at the top of the source
<fagan> hey all if I remove the nvidia driver in lucid does x automagicly fall back to nouveau?
<fagan> I want to test it im just wondering if its as easy as removing the other driver
<bjsnider> Sarvatt, looks like lbm_list_sort was defined once and then redefined again as something different
<bjsnider> that's bizarre
<Sarvatt> there is no list sort in the nouveau tree, i had to grab that stuff from linux-2.6 in the update-nouveau script
<Sarvatt> fagan: if you have xserver 1.7.5-1ubuntu1 thats all you need, if not you need nouveau in xorg.conf
<bjsnider> one of the deaders you're loading has list sort. two, actually
<bjsnider> headers
<Sarvatt> window redraws are so darn slow with this newest gtk+ that has client side decorations enabled
<bryceh> Sarvatt, RAOF, apw put together another backports module for testing:  http://people.canonical.com/~apw/drm-backport-lucid/
<apw> i have some reports of it working ok, even with the nouveau bits if you blacklist the lbm-nouveau
<bryceh> er, actually that's a backport of drm .33 to the .32 kernel not an lbm
<apw> thats what i mean, if you have lucid with the lbm, if you blacklist that, then the kernel one seems to work
<bryceh> Sarvatt, RAOF, so I think to incorporate this for Lucid, we'd merely need to remove some of the lbm_ hacks we'd put in earlier
<apw> i think the lbm hacks must have been 'try both' style hacks so we might not need to remove them even
<bryceh> I'm thinking we might wait until right after alpha-3 to upload this stuff, since getting it into a3 would be kind of a rush
<apw> bryceh, yeah the kernel is done for a-3
<bryceh> apw, think we need a FFe for this stuff?
<apw> we should get together on monday, and go over the testing we have by then and make a final go/no-go decision on this one
<bryceh> ok, that sounds good
<apw> i don't think we get any new features do we, just working things which didn't
<apw> but we can ask on monday once we've deciced where we are going
 * bryceh nods
<apw> dunno if we can get a test matrix filled or something, i have some of my boys testing
<apw> just to get a feel ... i'd like to have at least all of us tested on everything we have
<bryceh> we can continue using https://wiki.ubuntu.com/X/Testing/NouveauEvaluation for the test matrix
<bryceh> I stuck in a date column exactly because I anticipated we'd be making changes as we go
<apw> yeah in the meantime we might want to collect the ones with my kernel in a new table at the bottom and integrate them once we 'go'
<bryceh> apw, ok
<apw> so we can see what has been tested easy to help decision makeing
<DanaG>  '(12:55:21 PM) mwk: DanaG: upgrade libdrm, recompile DDX      (12:56:44 PM) DanaG: libdrm2 version is 2.4.18+git20100217.2d9990c7      (12:57:35 PM) DanaG: ddx is 0.0.15+git20100219+9b4118d    (12:58:31 PM) DanaG: What's new since then?
<DanaG> is xorg-edgers ppa not new enough?
<DanaG> xorg log: http://pastebin.com/d7f22c765
<tjaalton> apw: airlied said that there probably will be nouveau updates in .33.x, since F12 has that
 * bryceh sends email to ubuntu-x@ about -nouveau and begins the count for how long until it appears on phoronix
<bryceh> tjaalton, yeah, I think apw has some skepticism.  Guess we'll see
<bryceh> tjaalton, btw how did the libdrm merge go?
<DanaG> hmm, for nouveau help on lucid, is this channel okay?  Nobody's answered in #ubuntu+1.
<tjaalton> bryceh: it wasn't that hard, just had to make sure the revert patch was flawless
<bryceh> DanaG, this is more of a developer/integrator channel, but feel free to ask about nouveau and if someone knows they'll chip in with an answer
<tjaalton> DanaG: nouveau in edgers is broken due to the abi change
<DanaG> aah.  So it'll be fixed eventually?
<tjaalton> yes
<tjaalton> though lucid has most of it
<tjaalton> already
<tjaalton> and is working I hear
<bryceh> only most?
<tjaalton> apart from the abi change
<bryceh> ah right, only the non-broken parts ;-)
<tjaalton> yep, and what's on top of that
<DanaG> I did think it odd that it said it opened it successfully (got "10"), and then said it failed to open.
<bryceh> heh, already on phoronix - http://www.phoronix.com/scan.php?page=news_item&px=ODAwMg
<BUGabundo> night
<BUGabundo> guys need your help
<BUGabundo> after the last batch of updates to X and nouvoue the upgrade complains of no firmware
<BUGabundo> and i cant start GDM/X
<BUGabundo> Sarvatt: RAOF: ^^^^^^
<BUGabundo> $ pastebinit Xorg.0.log http://paste.ubuntu.com/379998/
<BUGabundo> $ pastebinit Xorg.0.log.old  http://paste.ubuntu.com/379999/
<BUGabundo> $ pastebinit Xorg.1.log http://paste.ubuntu.com/380000/
<BUGabundo> using Sarvatt ppa-purge
<BUGabundo> Errors were encountered while processing:  nvidia-current  nvidia-glx-185 E: Sub-process /usr/bin/dpkg returned an error code (1)
<BUGabundo> i'm back
<BUGabundo> no X
<BUGabundo> not even recovery console
<fmarl> BUGabundo, try installing the nouveau-firmare package
<BUGabundo> fmarl: will do
<BUGabundo> shouldnt it be pulled as a depency ?
<fmarl> I dunno..
<fmarl> the firmware it's optional depending on the video card
<BUGabundo> ok
<BUGabundo> still upgrading to PPA, again
<BUGabundo> lets see if that saves me 
<Sarvatt> BUGabundo: xorg-edgers is broken for nouveau right now until I can get the linux-backports-modules-nouveau built with the api changes
<BUGabundo> BAHABAAB
<BUGabundo> i just upgraded :(
<BUGabundo> Sarvatt: alternatives?
<Sarvatt> the stuff already in lucid
<BUGabundo> didnt work
<BUGabundo> i just tried that
<fmarl> compile from source :)
<BUGabundo> vesa only, once i tried jockey all hell broke lose
<Sarvatt> you installed the nouveau-firmware package?
<BUGabundo> not yet
<BUGabundo> i have all the logs here
<Sarvatt> its just not a depends yet like it needs to be
<BUGabundo> if u wnat to take a pic
<BUGabundo> *peak
<BUGabundo> so purge PPAs (again), initram the kernel, boot vesa, install fw, then jokey?
<Sarvatt> sorry man, I really dont have much time to debug it at the moment :(
<BUGabundo> np
<Sarvatt> purge ppa, install nouveau-firmware and you're good to go
<BUGabundo> just give me an working X at full resolution
<BUGabundo> thanks
<BUGabundo> can purge-ppa do both at the same time?
<Sarvatt> maybe remove "quiet splash" from the kernel command line if that doesnt work
<Sarvatt> do both what?
<BUGabundo> already dod that
<BUGabundo> Sarvatt: ppa-purge both nouveua and xedgers
<Sarvatt> oh you have both PPAs? afraid not, the script is broken at the moment and only works for whatever/ppa
<Sarvatt> but everything in xorg-edgers/nouveau should be supersceded by stuff in lucid already
<BUGabundo> ok
<Sarvatt> yep it is
<BUGabundo> # ppa-purge xorg-edgers, it is
<BUGabundo> The following packages will be DOWNGRADED:   libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa mesa-utils xserver-xorg-input-evdev   xserver-xorg-input-synaptics xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-radeon xserver-xorg-video-sis
<Sarvatt> no xorg-server-core and such?
<Sarvatt> xserver-xorg-core i mean
<BUGabundo> The following extra packages will be installed:   intel-gpu-tools libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa mesa-utils xserver-xorg-input-evdev   xserver-xorg-input-synaptics xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-radeon xserver-xorg-video-sis Suggested packages:   libglide3 gpointing-device-settings touchfreeze firmware-linux
<BUGabundo> i did notice i had no Xorg last time
<Sarvatt> oh xserver in lucid is a higher version already
<BUGabundo> nouveau-firmware next
<BUGabundo> The following packages will be REMOVED:   libx11-xcb1{u} libxcb-dri2-0{u} 
<BUGabundo> but nothing installed
<BUGabundo> nouveau-firmware:   Installed: 20091212-0ubuntu1
<Sarvatt> xserver-xorg-video-intel in edgers had those as depends for XvMC support, no biggie
<BUGabundo> seems i already had it
<BUGabundo> # dpkg -l | grep xorg | pastebinit  http://pastebin.com/d2631efb4
<BUGabundo> # dpkg -l | grep nvid ii  nvidia-current-modaliases                         195.36.03-0ubuntu1
<Sarvatt> ok it looks like the libdrm in lucid now doesnt have the lbm-nouveau patch to it
<BUGabundo> going for another reboot
<Sarvatt> sorry BUGabundo, it probably wont work
<BUGabundo> hope to be rigt back
<BUGabundo> what?!
<BUGabundo> why !?
<Sarvatt> libdrm needs a patch for nouveau that didnt get brought along
<BUGabundo> :(
<BUGabundo> so lucid users are screed right now?
<Sarvatt> http://sarvatt.com/downloads/patches/libdrm-lbm-nouveau.patch
<BUGabundo> no vesa, no nouveua nor blob?
<Sarvatt> where'd you get that?
<Sarvatt> other things are fine its just nouveau
<BUGabundo> i couldnt even install blob
<BUGabundo> Sarvatt: what should i do with that patch?
<BUGabundo> i never patch X!
<Sarvatt> nevermind about that, the libdrm patch is there after all
#ubuntu-x 2010-02-20
<BUGabundo> eheh
<BUGabundo> so reboot and test?
<BUGabundo> anything u need me to bring from the _other side: ?
<Sarvatt> why can't you install nvidia-current? you probably need to install nvidia-common as well btw, looks like you purged it somewhere along the line
<BUGabundo> reinstalling
<BUGabundo> Sarvatt: can i install -current from chroot?
<BUGabundo> or should i boot first?
<Sarvatt> i have no idea, if you do it from the command line you need to set up the xorg.conf manually as well I think
<BUGabundo> oh ok
<BUGabundo> though udev took care of all of that now
<bryceh> scary:  http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
<BUGabundo> Sarvatt: http://paste.ubuntu.com/380034/
<bryceh> *sigh* gonna have to redo the scale on that graph again already
<BUGabundo> bryceh: 150% increase
<BUGabundo> or better 50% increasw
<Sarvatt> is the 2.6.32-14 kernel even the main kernel yet or did you manually install it? did you forget headers for it?
<BUGabundo> WTH
<BUGabundo> i only had .13 on last boot
<BUGabundo> 2.6.32-14.19 0         500 http://neacm.fe.up.pt lucid/main Packages         500 http://archive.ubuntu.com lucid/main Packages
<BUGabundo> its in the archive
<Sarvatt> yeah but not the linux-meta yet so you dont automatically get the headers and kernel upgrade..
<Sarvatt> at least i havent gotten it yet
<BUGabundo> yeah
<BUGabundo> ill boot into .13
<BUGabundo> its already mirrored
<Sarvatt> try sudo apt-get install linux-headers-2.6.32-14 linux-headers-2.6.32-14-generic and reinstall nvidia-current
<Sarvatt> you wont be able to install nvidia-current for -13 either since you have -14 installed with no headers
<BUGabundo> The following NEW packages will be installed:   linux-headers-2.6.32-14 linux-headers-2.6.32-14-generic
<BUGabundo> run-parts: executing /etc/kernel/header_postinst.d/dkms 2.6.32-14-generic /boot/vmlinuz-2.6.32-14-generic
<Sarvatt> plus theres no nouveau for -14 yet anyway
<BUGabundo> yeah
<BUGabundo> this moves faster then we can keep up
<BUGabundo> [00:16] <crimsun>      linux | 2.6.32-14.20 |         lucid | source
<BUGabundo> LOL
<Sarvatt> wouldn't be a problem if you waited for it to come through upgrades instead of installing the kernel manually :D
<BUGabundo> Sarvatt: i DID NOT jump the gun on anything
<BUGabundo> all i have is from regular updates
<BUGabundo> via aptitude safe-upgrae
<Sarvatt> weird..
<BUGabundo> specially since i've been running nouveau for 2 weeks, i try to keep it clean
<BUGabundo> so i can provide as good feedback as possible
<BUGabundo> and not mess updates
<Sarvatt> no idea what pulled in just the kernel upgrade
<Sarvatt> thats strange
<BUGabundo> :/var/log/apt# pastebinit history.log http://pastebin.com/d3c82e8c6
<BUGabundo> ./var/log# pastebinit aptitude http://pastebin.com/d57e34f4f
<BUGabundo> HTH
<Sarvatt> none of those even show linux-image-2.6.32-14 getting installed
<BUGabundo> $ apt-cache policy linux-image-2.6.32-14-generic linux-image-2.6.32-14-generic:   Installed: (none)   Candidate: 2.6.32-14.19
<BUGabundo> its not installed
<Sarvatt> huh, you pastebinned a long of nvidia-current failing to make the module for 2.6.32-14
<Sarvatt> log rather
<BUGabundo> i know
<BUGabundo> what can i say, its a mistery
<Sarvatt> update-initramfs: Generating /boot/initrd.img-2.6.31-14-generic
<Sarvatt> Cannot find /lib/modules/2.6.31-14-generic
<Sarvatt> oh .31
<Sarvatt> argh lol
<BUGabundo> # apt-get install linux-image-2.6.32-14 ?
<BUGabundo> LOLOLOL
<BUGabundo> E: Couldn't find package linux-image-2.6.32-14
<Sarvatt> -generic
<BUGabundo> so, purge header?
<Sarvatt> yeah
<BUGabundo> and boot into -13 ?
<Sarvatt> it failed because something is screwy, did you manually remove /lib/modules/2.6.31-14-generic or something? just purge linux-image-2.6.31-14-generic if anything
<BUGabundo> not that i recall
<BUGabundo> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<Sarvatt> you probably have something left behind in /boot from that kernel then that needs deleting
 * BUGabundo picks up the HAMMER
<BUGabundo> :/boot# ls -l | pastebinit  http://pastebin.com/d4cff30eb
<BUGabundo> Sarvatt: nothing there
<BUGabundo> # mlocate 2.6.31-14 brings nothing either
<Sarvatt> you were doing it from a karmic livecd weren't you? lol
<Sarvatt> when you pasted those logs......
<BUGabundo> yes
<BUGabundo> no lucid livecd at hand
<BUGabundo> i'm still on it
<BUGabundo> chrooted to my system
<BUGabundo> let me guess its picking stuff from /sys ?
<Sarvatt> uname..
<BUGabundo> oh F
<BUGabundo> sorry for the trouble
<BUGabundo> rebooting
<Sarvatt> it installed fine for -13, as long as your /etc/X11/xorg.conf is the nvidia one its fine to reboot
<BUGabundo> let see whats on the other side
<BUGabundo> i have no xorg,conf
<Sarvatt> you need one for nvidia to work
<BUGabundo> should i run nvidia-soemthing ?
<Sarvatt> no idea what its called, i just keep the xorg.conf around
<BUGabundo> # pastebinit xorg.conf-backup-100206200857 http://pastebin.com/d6e9e9950
<Sarvatt> nvidia-xconfig?
<Sarvatt> thats what it says at the top of my xorg.conf
<BUGabundo> The program 'nvidia-xconfig' can be found in the following packages:
<Sarvatt> but i  probably made it with the blob straight from nvidia
<BUGabundo> ill try that
<Sarvatt> yep that backup one is fine
<BUGabundo> wish me luck
<Sarvatt> just looked at your paste
<Sarvatt> yeah lbm-nouveau builds fine straight from linus' tree, too bad i cant merge the nouveau one into that
<BUGabundo> Sarvatt: thanks. blob and compiz back on
<BUGabundo> ping me back once nouveau is ready for more testing
<Sarvatt> if you remove the xorg.conf nouveau should just work
<Sarvatt> i put a note on the edgers page saying nouveau was broken with it for now
<Sarvatt> mesa requires the api bump to build nouveau now so i didnt drop it from libdrm but i havent been able to get the lbm-nouveau going
<Sarvatt> hmm guess i could just remove the list_sort stuff completely, nouveau upstream tree is based on 2.6.32 without it..
<Sarvatt> bryceh: yeah all those lbm-* hacks did just extend support for the renaming, didnt replace nouveau in anything so everything should work fine with the backported drm with normal module names. about intel 2.9.1, I'm not sure honestly.. we *could* transition 8xx people onto fbdev on top of KMS instead of -intel if we went 2.10.. 2.9.1 + ppa packages of newer ones in #ubuntu-x would probably be a better idea for a LTS though. Do we have a way we co
<Sarvatt> uld make 8xx series GPUs default to UMS if we go with 2.9.1? because the KMS overlay support in 2.10 is a pretty vital feature for those cards that cant do textured video
<Sarvatt> backporting future things will be a heck of alot easier on 2.10 though
<Sarvatt> i'm trying out that linux-image-2.6.32-14-generic_2.6.32-14.19drmbackportapw2 on all  my machines now
<Sarvatt> wow what the heck, screen is going all garbled for a few seconds when i scroll in xchat
<Sarvatt> yeep, compile a kernel in the background and then scrolling in xchat does it and doesnt when i'm not compiling, guess its the client side decorations gtk+ change thats making Xorg use craploads of cpu time
<BUGabundo> Sarvatt: something fishy has been around since the weekend updates
<BUGabundo> several users compaling of the same slowdown
<BUGabundo> some point to GTK bug
<BUGabundo> not sure what
<BUGabundo> but now I can type full sentnces, way before they show up in my screen
<Sarvatt> yeah I know what it is, something not ready getting shoved in to make feature freeze and it'll get fixed later :)
<BUGabundo> eheheh
<BUGabundo> I know
<Sarvatt> disabling compiz fixes the screen getting garbled under heavy system load here but metacity is *super* slow minimizing and maximizing with this gtk+ change on this netbook
<BUGabundo> now I'm using compiz
<BUGabundo> wasn't all week
<BUGabundo> it was still super slow
<BUGabundo> specailly over FreeNX and ADSL
<Sarvatt> lol wonder how things handle if i launch a gtk app over a ssh connection now that you mention that
<BUGabundo> eheh
<BUGabundo> you would go to sleep a awake hopping it had finished
<Sarvatt> what status should I set bugs to where they are for a feature that wont be included until 10.10 at least? like the backlight OSD under intel KMS bugs
<Sarvatt> just leave it confirmed?
<BUGabundo> probably
<BUGabundo> or in progress
<BUGabundo> if you have code for it
<Sarvatt> so many -intel bugs that are 100% kernel bugs, no wonder theres so many open intel bugs :)
<bryceh> Sarvatt, yeah I've been just moving those to the kernel when I spot them.  When you spot ones that you're 100% sure are kernel bugs, retarget them to 'linux'
<bryceh> I figure it's fine for people to keep filing these against xorg, since that'll ensure they get the proper debugging files before we refile to the proper place
<bryceh> also if you see ones that you're pretty sure should be fine in lucid, go ahead and close them out; I've been doing similarly as I have time
<kklimonda> hmm.. xserver-xorg-video-nouveau is trying to pull a -generic kernel when I already have -pae..
<tjaalton> kklimonda: because -nouveau depends on it, and there's no linux-backports-modules-nouveau-lucid-generic-pae available which it could depend as an alternative
<tjaalton> so file a bug against nouveau and linux-meta
<kklimonda> ach, I see - thanks. should probably wake up before I start asking stupid questions
<tjaalton> no it's a valid issue that has gone unnoticed
<RAOF> Hm.  It seems that /lib/modules/2.6.32-$ABI/modules.order is there to provide a consistent order of module loading - is that right?  Might this be why vga16fb breaks nouveau but not the other KMS drivers?  All the other KMS drivers appear prior to vga16fb in modules.order.
<RAOF> Well, I'll call that hypothesis...  partially confirmed.  Adding nouveau to modules.order before vga16fb makes boot work for me.
<RAOF> And trying the reverse to i915 seems to introduce subtle corruption.
<Sarvatt> ok nouveau is all working again with 3d on edgers
<BUGabundo> YAY
<BUGabundo> will test tonigh
<Sarvatt> its even slower now, you might not want to :)
<BUGabundo> ohhhh ok 
 * BUGabundo changes ideas
<BUGabundo> even nvidia blob is slow in lucid
<BUGabundo> only 180FPS in compiz benchmark plugin
<BUGabundo> I used to get over 300 in 9.04
<jcristau> 180 fps is still 3 times as much as your refresh rate, so..
<BUGabundo> jcristau: well nouveu is only at 30
<BUGabundo> well it was... if the new one is slower
<BUGabundo> ..... 15FPS? lol
<Sarvatt> nvidia-settings -a AccelerateTrapezoids=1
<Sarvatt> might want to try that out
<BUGabundo> ORLY?
<BUGabundo> ERROR: Error parsing assignment 'AccelerateTrapezoids=1' (Unrecognized attribute name).
<Sarvatt> ah yeah we have an old nvidia-settings still
<Sarvatt> ya can add it to xorg.conf still
<bjsnider> nvidia-settings is still at 180.25?
<Duke`> wow huge dead code cleanup in xf86-video-intel
<Sarvatt> anyone currently using karmic on x64 that could tell me if /etc/X11/Xsession.d/65mesa-check-x86-64 exists on their system?
<hyperair> ls /etc/X11/Xsession.d/65- <-- tab completion doesn't work, so i guess it isn't around.
<Sarvatt> i cant find that script in any of the karmic packaging but someone is saying it exists, i'm guessing they had it from an old upgrade and didnt get removed
<hyperair> hmm
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/460809
<ubottu> Ubuntu bug 460809 in mesa "ASM optimizations in mesa are disabled on Intel 64bit CPU" [Undecided,Confirmed]
<hyperair> i'm using xorg-edgers, if that counts
<hyperair> ASM optimizations?
<jcristau> Sarvatt: yeah sounds like the postinst should have removed it on upgrade, and didn't
<Sarvatt> tormod	tjaalton: I still have /etc/X11/Xsession.d/65mesa-check-x86-64 here, is this a conf file that needs to be deleted even if it's not shipped any longer, or is it just me?	21:35
<Sarvatt> jcristau	yes, the postinst should take care of that
<hyperair> perhaps hookscripts should never go under /etc
<hyperair> like distribution-shipped hookscripts
<Sarvatt> 2009/02/10 #ubuntu-x irc log
<jcristau> hehe
<Sarvatt> over a year ago :D
<hyperair> jaunty wasn't even released then, let alone karmic >_>
<dbro> Hello Xorg experts- I have a problem where xorg memory usage creeps up over time. Eg right now it consumes 40% of my 640MB ram and seems to be causing all kinds of swapping and slowness. Is this the right place to ask for help troubleshooting this?
<dbro> it appears to match the symptoms in this bug report (but I don't see much guidance there about fixing it) https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/98783
<ubottu> Ubuntu bug 98783 in xorg-server "MASTER: memory leak" [Wishlist,Incomplete]
<jcristau> symptoms don't really matter.  what matters is an easy way to reproduce.
<Sarvatt> I'm guessing you're using the nvidia proprietary drivers
<Sarvatt> because thats been a problem for a *long* time with those and it doesn't look like something we can fix with those
<dbro> is there an alternative? something that would play nicely with flash video would be nice
<Sarvatt> alot of work is being put into the alternative (nouveau) but realistically 10.10 will be the release where nouveau is at a state where it can replace the blob for most people in my opinion
<Sarvatt> if you dont mind fiddling nouveau is in lucid now, and you can get 3D support from the xorg-edgers PPA
<dbro> does 10.10 mean ubuntu 10.10 ?
<Sarvatt> i've already ditched the proprietary drivers on my nvidia system on lucid + xorg-edgers, but the 3D support is slow right now so if you have a high resolution screen I wouldn't bother. if you dont need 3D though the nouveau in lucid handles flash fine
<Sarvatt> yeah
<dbro> I dont think I need 3d. I don't play games or use fancy desktop effects
<dbro> ok
<Sarvatt> i would try out a lucid livecd once alpha 3 hits in a few days and see how you like it
<dbro> ok thanks
<Sarvatt> wish there was some magical fix for it but the memory leaks have been around for over 4 years now and the proprietary drivers are closed source
<Sarvatt> hmm nouveau is still using a ton more memory than intel for me, 132mb vs 44mb.. the blob would be around 400mb by now though
<Sarvatt> woohoo http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=commit;h=d9076a54d74e371a11e1206b4a26e2e428045b9e
<Sarvatt> and we've got the r600+ irq firmware in our linux-firmware now too
<tjaalton> Sarvatt: bah, so it seems
<tjaalton> and I didn't do anything the last time
<tjaalton> go me :)
<tjaalton> Sarvatt: pushed something to git
<dbro> does this help wrt to previous request for easy way to reproduce behavior?
<dbro> switching between different desktop screens also increases memory usage
<tjaalton> still, if you are using the blob there's nothing we can do
<dbro> should I try to see if this also happens when using nv ? Is that helpful?
<tjaalton> not really, since they don't care about that either :)
<tjaalton> nouveau on the other hand..
<dbro> ok, I'm willing to give it a try- this memory leak is driving me mad!
<tjaalton> ram is cheap, just buy some more :)
<dbro> that would get me a longer time-to-restart, but not a fix, right?
<tjaalton> right
<bjsnider> Sarvatt, the nvidia blob has a memory leak issue? impossible
<tjaalton> also, it's not like the xserver doesn't have memleaks of it's own, but in this case the driver is most likely to blame
#ubuntu-x 2010-02-21
<dbro> nouveau has similar - but milder - behavior. Memory usage increases by 0.2MB when I minimize and restore a system monitor window.
<dbro> virtual memory increases by a bit more than 2MB
<dbro> can anyone else see this same behavior?
<dbro> is there more information I can provide? eg xrestop or something like that?
<RAOF> dbro: And does that continue to increase indefinately?
<RAOF> dbro: Other interesting datapoints include dmesg & Xorg.0.log.
<dhillon-v10> bryceh: can you have a look at this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/429384 it is reported against karmic alpha 5 so does it make sense to ask the reporter to check if this problem exists in lucid devel. release and mark the bug incomplete or should I just leave this one alone
<ubottu> Ubuntu bug 429384 in xserver-xorg-video-intel "[i965] [karmic i386 alpha 5] X hangs (intel 965gm)" [Undecided,New]
<bryceh> dhillon-v10, yes, we probably will only care about lucid bugs here on out
<dhillon-v10> bryceh: alright so can I'll mark others with karmic tag incomplete :)
<bryceh> dhillon-v10, thanks, that'd be a big help
<bryceh> dhillon-v10, btw once the original reporter has tested it on lucid, tag it 'lucid'
<bryceh> dhillon-v10, when I go through X bugs, I only look at ones tagged 'lucid' now
<dhillon-v10> bryceh: np :) oh yeah I'll keep that in mind :) 
<bryceh> dhillon-v10, generally I don't count it as tested against lucid if some other random person tested it, since they usually haven't provided the full collection of needed info that the original reporter gave
<bryceh> and plus, who knows if the person *actually* had the same bug, or just something that seemed similar to them
<bryceh> but use your judgment there
<bryceh> usually we want the other person to report their issue as a separate bug report.  We have to do that anyway if we upstream the bug.
<dhillon-v10> bryceh: alright, thanks for the advice
<dbro> RAOF: it increases only when I perform those actions. The increment happens when I trigger it, not simply due to passing time
<dbro> RAOF: what should I look for in dmesg? I can't see anything since bootup
<dbro> RAOF: and what should I look for in Xorg.0.log? No obvious errors apparent there either
<RAOF> dbro: Various forms of nouveau kernel debug spew; also it would allow me to determine a couple of things about your setup such as your card generation, whether it needs firmware, whether it *has* firmware, etc.
<RAOF> dbro: Just pastebinning them would be good; I can easily check through them for items of interest.
<dbro> ok, should I put it in a pastebin page or something like that?
<dbro> ok
<dbro> RAOF: re Xorg.0.log - how many lines should I include? It seems to go back to before the current boot
<RAOF> dbro: All of them will do.  If you've got âpastebinitâ installed, just go âdmesg | pastebinitâ and âpastebinit /var/log/Xorg.0.logâ.
<dbro> RAOF: ok. http://www.pastebin.com/m39087e9d
<dbro> and the dmesg is here:  http://www.pastebin.com/m43f96c9f
<dbro> and my xorg.conf is http://www.pastebin.com/m764f40e5
<dbro> (it's got a lot of commented lines... sorry about that)
<RAOF> THat pastebin seems to be empty?
<dbro> uh oh...
<dbro> first one?
<RAOF> The last 2.
<dbro> sorry- I should't have included the "www." in those 2.
<dbro> so they are http://pastebin.com/m43f96c9f
<dbro> and http://pastebin.com/m764f40e5
<RAOF> Ta.  I'm off for a while, but I'll have a look at them when I get back.
<dbro> thanks, I'll keep an eye on this window
<dhillon-v10> bryceh: mission accomplished :) the only bugs left in new state are in lucid
<dhillon-v10> bryceh: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?search=Search&field.status=New
<bryceh> dhillon-v10, nice
<dhillon-v10> bryceh: yeah around 33 left, now time to fix them :)
<bryceh> actually we'll probably need to have them test against the 2.6.33 drm; quite likely their bugs are fixed there
<bryceh> so if we end up bringing that in, we'll be able to close the bugs
<RAOF> dbro: Hm.  Interesting.  How much does your graphics actually work again? :).  You've got the nvidia binary driver loading as well, which is unlikely to improve matters :)
<RAOF> dbro: Also, you've got quite an old nouveau kernel module which isn't using KMS.
<RAOF> That's not necessarily a problem, but it might be fixed in a newer version.  Also, you've got the same chipset as me, so I'll see if I can reproduce it.
<RAOF> dbro: I can't reproduce your memleak: I've minimised & restored a system monitor window about 20 times now; memory usage has oscilated between 32MiB and 31.9MiB.  Virtual size has remained static at 154.7MiB.
<RAOF> dbro: It might be interesting for you to try a Lucid alpha 3 livecd; that should have nouveau by default so would be a good environment to see if your bug has been fixed.
<dbro> ok. is that available now?
<dbro> how can I get the extra nvidia driver to not load?
<RAOF> Alpha 3 is not yet out; you could either blacklist the nvidia driver or remove the nvidia-source package (I'm not sure what Ubuntu version you're running, so I'm not sure what the exact package name will be).
<dbro> RAOF: thanks for the suggestions. I removed the nvidia source package, then rebooted. there was no mention of the nvidia driver in dmesg, only nouveau was loaded. and now I see no change in Memory usage by x when minimizing and restoring the system monitor window. However, I do see an increase in xorg's virtual memory usage when minimizing and restoring the system monitor window.
<dbro> about 2MB per minimize,restore cycle
<dbro> RAOF: should I try to use a more recent version of nouveau, eg by following these instructions? https://edge.launchpad.net/~xorg-edgers/+archive/nouveau 
<RAOF> dbro: You could give it a whirl.  Of course, I'd be more interested in your Lucid experience (once Alpha 3 has landed), since that's what we're going to be supporting :)
<dbro> upgrading to the lucid versions of the nouveau packages seems to involve a lot of other package removals and upgrades- is there a way to avoid that?
<RAOF> You don't want to do that - I was thinking more a livecd situation.
<dbro> ok
<dbro> I will try the live cd -- expected to be available feb 25, right?
 * RAOF rechecks the release schedule.  Why isn't it in my google calendar?
<RAOF> Yup.  25th, all things going smoothly.
<dbro> thanks again. good night!
<tjaalton> bryceh: you need to take nvidia-graphics-drivers a separate entry on the bug chart, it's starting to make the "Remainder" look bad/worse :)
<tjaalton> serial wacom support for xserver now in git
#ubuntu-x 2011-02-14
<tjaalton> RAOF: whee, you found the commit to fix the mesa assert?
<tjaalton> I was told that the assert itself was unnecessary, but that there probably was something to it
<tjaalton> nouveau dri hasn't crashed on me during the weekend.. helps if the window count is kept low
<tjaalton> but can't understand why links from TB don't work on my desktop, laptop is fine
<tjaalton> (ffox opens them as 'www.%u.com')
<RAOF> tjaalton: You're after the nv50 hunk of 7401590de for the mesa assert.
<RAOF> Which, piglit pending, should totally be nominated for 7.10
<hyperair> hi. where can i find xrandr's C functions documentation?
<hyperair> that monolithic manpage isn't bringing me anywhere
<jcristau> read the protocol spec
<jcristau> the libXrandr api is a thin wrapper around that.
<hyperair> hmm okay
<hyperair> but what about the strange datatypes that it returns?
<hyperair> all i'm trying to do is get the current resolution
<jcristau> like what?
<hyperair> of individual outputs
<hyperair> XRRScreenConfiguration*
<hyperair> XRRScreenSize*
<hyperair> yeah, stuff like that
<jcristau> what's strange about a struct?
<hyperair> oh wait a sec, the structs are documented!
<hyperair> =O
 * hyperair facepalms
<tjaalton> RAOF: ah, cool.. will check
<RAOF> hyperair: :)
<hyperair> RAOF: are the stuff mentioned inside XRandr(3) all the functions i can use? the protocol document seems to mention some other stuff..
<hyperair> like RRGetOutputInfo and the like
<jcristau> no, the manpage wasn't updated after 1.1
<RAOF> hyperair: I'd be looking at the protocol doc in x11proto-randr-dev
<hyperair> oh okay.
<jcristau> and <X11/extensions/Xrandr.h>
<hyperair> thanks.
<klattimer> Does anyone have any ideas about this bug; https://bugs.launchpad.net/compiz/+bug/718663
<ubot4> Launchpad bug 718663 in xserver-xorg-driver-vesa (and 2 other projects) "Blank unity desktop (affects: 1) (heat: 8)" [Undecided,New]
<jcristau> not enough info there.
<tjaalton> yep, best to use 'ubuntu-bug' when filing a new bug
<tjaalton> there are three "upstreams" marked for that bug
<tjaalton> or projects, none of which is ubuntu
<klattimer> tjaalton: ah :/ 
<klattimer> what info do you need?
<tjaalton> klattimer: please run 'apport-collect 718663'
<tjaalton> it'll attach relevant information to the bug
<klattimer> tjaalton: done
<klattimer> this'll take a minute
<tjaalton> hmm does it have a poulsbo in it?
<tjaalton> guess we'll see
<tjaalton> ah no
<klattimer> tjaalton: sorry I'm having trouble with apport now :/
<klattimer> running it as user works but fails to collect log files, running it as root tells me gtk couldn't be initialised 
<klattimer> :/
<tjaalton> it should ask for your password
<tjaalton> to collect the logs
<klattimer> tjaalton: that doesn't happen :/
<tjaalton> wait, you're on 10.10?
<tjaalton> aka maverick
<klattimer> tjaalton: nope natty
<klattimer> ah, it appears gdm was causing problems 
<tjaalton> then you don't have all the updates
<klattimer> hmm
<tjaalton> since xserver-xorg should be 1:7.6~3ubuntu4
<klattimer> I just updated this morning 
<tjaalton> from maverick?
<klattimer> tjaalton: no on natty
<klattimer> this is a natty install 
<klattimer> right through 
<klattimer> I'm working on indicator-datetime (contracted) 
<klattimer> so I need to use natty 
<tjaalton> ok so what does 'apt-cache policy xserver-xorg' show as the installed version?
<klattimer> installed 7.5, candidate 7.6
<tjaalton> see
<klattimer> hmm, maybe something was a little wrong during the update
<klattimer> thanks tjaalton
<tjaalton> how did you upgrade?
<klattimer> tjaalton: apt-get update, apt-get upgrade 
<klattimer> but it seems all of the xorg stuff was either half installed, or not installed 
<klattimer> maybe something went wrong during the upgrade
<tjaalton> it refuses to remove packages
<tjaalton> so doesn't always work during the devel phase
<tjaalton> use dist-upgrade or update-manager..
<klattimer> tjaalton: thanks ;)
<gordboy> so why are x-swat/x-updates offering a beta nvidia driver (that doesn't work properly) when their mission statement says they offer *stable* upsteam ? it would be very nice if you offered 260.19 nvidia driver, instead
<tseliot> gordboy: maybe because they're supposed to work with the new Xserver with the IgnoreABI option. I don't have a real answer for you though
<gordboy> tseliot: interesting. if that were the case, then why are the xorg-edgers (the bleeding cutting edge, break your system weekly ppa) offering the stable driver ? seems to me there is a bit of confusion ...
<tseliot> gordboy: I wouldn't know, maybe 270.18 was really meant to be uploaded to xorg-edgers instead
<ricotz> bjsnider, ^^^ ;)
<tjaalton> klattimer: so do things work better after the upgrade?
<tjaalton> klattimer: all that the logs reveal is that compiz had segfaulted three times
<tjaalton> the x log was fine
<tjaalton> hmm, I take that back, the xserver had crashed as well
<bjsnider> gordboy, what distros is this?
<gordboy> bjsnider: lucid
<gordboy> i know maverick had trouble with 260 and the NVRM: os_raise_smp_barrier(), invalid context! thing. but lucid doesn't
<bjsnider> well, i uploaded the 270 blob because nvidia doesn't generally break things retroactive to previous x-servers. it works fine here on maverick
<klattimer> tjaalton: yeah thanks
<klattimer> you can close the bug
<tjaalton> klattimer: cool
<gordboy> bjsnider: ok. well just so you know, the 270 on lucid gives freezes and full log files. the 260 is fine. tested on 8500gt, 9500gt and ge210
<bjsnider> alright, well if i were you i'd go back to using the standard lucid driver
<gordboy> bjsnider: the problem with that, is that flash 10.2 crashes immediately with 195, and libvdpau1. i know this is an inexact science ...
<bjsnider> yeah but thi is above our pay grade
<bjsnider> we can't fix closed-source flash and a binary graphics driver
<bjsnider> at some point we have to throw up our hands and bow to the absurd
<gordboy> point taken. but the 260 works well with lucid, and is the current stable offering. just saying
<jcristau> then use that?
<gordboy> the only place to get it is from xorg-edgers :)
<jcristau> or nvidia.
<bjsnider> gordboy, it works well for _you_ in lucid. i could probably scare up a dozen bug reports from others who say it causes problems for them
<gordboy> i'll trade my 3 definites for your dozen maybes, any day :)
<bjsnider> tseliot, i submitted a bug about some packaging issues with nvidia-current, as you requested
<bjsnider> 704607
<tseliot> bug 704607
<ubot4> tseliot: Bug 704607 on http://launchpad.net/bugs/704607 is private
<bjsnider> what?
<tseliot> bjsnider: thanks for reporting. I'm working on nvidia today so I should fix it now in my git branch
<bjsnider> very trivial changes. easy to implement
<bjsnider> tseliot, i also created a bug about moving the nvidia preinstall script to jockey-common from nvidia-common. can you tell pitti about it? i don't think he was alerted it's bug 704597
<ubot4> bjsnider: Bug 704597 on http://launchpad.net/bugs/704597 is private
<tseliot> bjsnider: oh, right the hook for the installer. Thanks for reminding me about it. I'll talk to pitti
<bjsnider> good, because i don't know what channels he's in
<thesheff17> RAOF: ping.....I finally believe I got the backtrace  from the crash through gdb. http://pastebin.com/Hc19Q0fg not sure if that helps at all but let me know if you have any ideas to fix it.
<jcristau> well, fglrx.
<thesheff17> jcristau: yea I know...I'm really looking for a 4 port video card PCI-express that supports up to 4 monitors without breaking the bank. I got this ATI FirePro 2450 512MB PCI-e x16 Graphics Video Card for about 150 off ebay :-/  
<kklimonda> hey, does nouveau in natty support power managment?
<Sarvatt> kklimonda: http://nouveau.freedesktop.org/wiki/PowerManagement
<kklimonda> Sarvatt: btw, I've had a problem with Firefox causing X to use 100% of cpu (pretty much halting everything) when I browsed google images, or other pages with a lot of images using nouveau. Any idea what would cause it? That was the reason I went back to nvidia
<kklimonda> so, from the matrix is seems that there is some power managment for nv50, as long as I don't have a fan connected to it? :)
<Sarvatt> it could be a lot of things :( have you been able to narrow it down any? only happen with compiz or something like that?
<Sarvatt> kklimonda: no fan speed adjustment control which isn't a big deal since your laptop doesn't have a separate fan
<kklimonda> Sarvatt: no, but it did happen every time.
<kklimonda> Sarvatt: I think I didn't run compiz
<kklimonda> I could check it - it should be simple test :)
<ricotz> Sarvatt, hi :)
<Sarvatt> hiya! whats up ricotz?
<ricotz> i wanted to play a bit with wayland
<ricotz> Sarvatt, do you think pixman 0.21.4 would be considered for a sync?
<Sarvatt> oh yeah we need a cairo-gl in xorg-edgers
<ricotz> Sarvatt, is it? the current cairo package builds its gl extension?
<Sarvatt> ricotz: really I've been torn on that, I dont think 0.21.x is a good idea for natty since 0.22 wont be out and its the development branch but 0.21 already went into unstable.. was hoping to put the stable 0.20.x in unstable once squeeze released
<jcristau> yeah a development snapshot in natty doesn't seem like a good plan
<ricotz> Sarvatt, there was a 0.20 release in exp once, perhaps this one can be pulled
<Sarvatt> it didn't build on our toolchain until that -O2 bug got fixed in our GCC a few weeks ago so we couldn't sync it then
<ricotz> ok, but isnt this package saved somewhere?
<Sarvatt> ricotz: also waiting for notify-osd to get updated to not be screwed up with the newer pixman, I pinged MacSlow about it
<Sarvatt> ricotz: well it's already up to 0.20.2 upstream and that never had a debian release
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/654921
<ricotz> so making an ubuntu only version of it, is no option?
<ubot4> Launchpad bug 654921 in notify-osd (Ubuntu) "Black border in the notifications when effects are turned off (affects: 10) (dups: 1) (heat: 68)" [Undecided,Confirmed]
<Sarvatt> ricotz: thats pretty much our only option besides staying at 0.18.4 and losing out on all the arm speedups :D
<ricotz> so should be worth it ;)
<ricotz> Sarvatt, i will do it
<Sarvatt> ricotz: awesome, thank you for doing that!
<jcristau> i'm wondering if i should get pixman 0.20 into testing
<ricotz> Sarvatt, http://people.ubuntu.com/~ricotz/pixman/
<ricotz> jcristau, are you going to do an upload to testing?
<jcristau> i don't know yet.
<ricotz> next debian release can probably wait for 0.22 
<Sarvatt> kklimonda: firefox directly from mozilla might be worth testing, they bundle their own pixman in that one and nouveau+pixman 0.18.x have had problems specifically with google image search in the past
<kklimonda> Sarvatt: ok, I will test it out tomorrow
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/608613 i'm looking at you
<ubot4> Launchpad bug 608613 in pixman (Ubuntu) "Nouveau tiling problem with firefox (affects: 2) (heat: 17)" [Undecided,Fix released]
<Sarvatt> they use their own heavily patched cairo too
<ricotz> Sarvatt, do you if natty will ship the needed firmware for nouveau 3d support of nvc0?
<Sarvatt> ricotz: very much doubt it
<ricotz> Sarvatt, hmm :(
<Sarvatt> I dont even know how to get it at the moment, its actual code from the blob so I doubt we could ever ship it :(
<Sarvatt> I believe*
<bryceh> thesheff17, what bug # is this for?
<Sarvatt> ricotz: wonder if its in here - https://github.com/pathscale/envytools/
<ricotz> Sarvatt, yeah, i found that, there are the tools to get ;)
<thesheff17> bryceh: I was working with RAOF to troubleshoot this problem...I haven't filed a bug yet.  It is completely random about every 48 hours with that ATI FirePro 2450 card.  Do you want me to file a bug?
 * penguin42 isn't too sure how to report a bug he's currently seeing - when windows appear they have junk in and then quickly get rendered a fraction of a second later; that's KDE on Radeon HD4350 open driver - any ideas for nailing it down?
<jcristau> goes away when you turn off compositing?
<penguin42> let me try - there appears to be a 'suspend desktop effects' button
<penguin42> jcristau: No, harder to spot though because stuff is faster, but you can still see it
<RAOF> thesheff17: Hm.  That looks like it's probably a fglrx problem.  The backtrace suggests that it's occurring when something is changing the cursor image, though, so that might help you reproduce it.
<thesheff17> RAOF: ah ok...I will have to see if I can pin point it.  I wonder if it is only happening when it changes over a certain app running...maybe chrome
<RAOF> Something like that would seem likely.
<RAOF> I think the time has come to file a bug on fglrx with that backtrace attached.
<RAOF> The backtrace makes it look like it really is a fglrx bug, so it's not likely to be fixable by us, but I understand that the amd guys check launchpad every now and then.
<thesheff17> RAOF: sure will do...it isn't horrible since it only happens every 48 hours or so. should I use these steps to report a bug? https://wiki.ubuntu.com/X/Reporting
<RAOF> thesheff17: Yes, please.  For you, the main thing to attach will be that backtrace.
<thesheff17> RAOF: ok sounds good.
<thesheff17> RAOF: Thanks for the help.
<RAOF> No problem!
<thesheff17> RAOF: not that this would have anything to do with the bug but so I have 2x2 monitors.  The top two monitors I cannot drag applications through the top two monitors.  but I can drag an app down to the bottom monitor and then over to the other one and then up to the other monitor. Does that make sense?
<RAOF> That does make sense, but it might be a fglrx quirk?  There's no X-y reason why you shouldn't be able to have a rectangular array of outputs.
<thesheff17> RAOF: yea not a huge deal just another strange thing I ran into.
<afiestas> Hey, my X's (or maybe the kernel, I'm not sure) are crashing a looooot in Natty
<afiestas> how can I provide more debug info?
<afiestas> it happens randomly when I use Xv (via mplayer/vlc/whatever)
<penguin42> afiestas: What graphics card?
<afiestas> penguin42: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (pr
<penguin42> ok, so it starts up, just sometimes dies?
<afiestas> it crashes when I use Xv (the X video accelerator api)
<afiestas> via Kamoso (Webcam app) Vlc mplayer etc
<penguin42> how does it crash? Does the whole thing lock up? Does it log out? Does it draw aliens?
<afiestas> it stop refreshing, and after a few seconds everything turns black
<afiestas> I can't switch to any tty, but if for example I'm watching a film I still can hear the sound
<penguin42> can you ping it?
<afiestas> mm no idea, but I can try the next time
<afiestas> also I can leave sshd open and get info if needed
<penguin42> yeh, so look for any errors at the bottom of dmesg, and also look for the errors at the end of /var/log/Xorg.0.log
<afiestas> ookiz, I'm going to do some patche for Kamoso now (webcam application) so I will reproduce it hopefully
<RAOF> afiestas: Hm.  Does the apport hook trigger?
<afiestas> RAOF: mm as far as I can tell, nope
<afiestas> can I check it someway?
<RAOF> You could ssh in and grab the error state.
<afiestas> what is error state exactly? what I have to grab?
<RAOF> The output of intel_gpu_dump and /sys/kernel/debug/dri/0/i915_error_state are good.
<RAOF> If it's Xv related I could also throw up a testing package for you; there's a possible problem that may be what you're hitting.
<afiestas> okz
<afiestas> well I'm quite sure that it is Xv related
<afiestas> it crashes only when I'm doing some video stuff
<bryceh> afiestas, grab `dmesg` as well
<afiestas> ookz
<RAOF> Aha!  We have a candidate commit for the i965 gpu hangs.
<bryceh> RAOF, if you mean ae8877e3, I'm already packaging it :-)
<RAOF> Hm.  I means 23f9b1
<RAOF> s/means/meant
<bryceh> oh, then we have fixes for two gpu hangs, lovely
<bryceh> ah wait, same patch
<bryceh> gah I'm on crack
<bryceh> RAOF, yes that's the commit I meant.  I'm also pulling in ae8877e3
<RAOF> :)
<bryceh> RAOF, why do you put up with me
<afiestas> ue ue, package package! xD
<afiestas> right now work on Video stuff in Natty is deadly xd
<bryceh> RAOF, btw what are you working on at the moment?  Would you have time to look at recent commits to mesa?  jcristau said there were some cherrypicks worth including in ubuntu, but looks like I'm not going to get to them today
<bryceh> RAOF, also we're a couple revs behind debian with mesa, although mostly looks like fixes for tangential stuff; still, might be nice to pull in anyway so we're up to date
<RAOF> I'm currently looking at mesa; specifically unbreaking Unity on nv5x+.  I'll check out the cherry-picks.
<bryceh> btw, I uploaded a fix to mesa earlier this morning
<RAOF> Thanks.  I'll pull that in.
<RAOF> Did jcristau happen to mention what cherrypicks were worthwhile, or just following the 7.10 branch?
#ubuntu-x 2011-02-15
<bryceh> just following the 7.10 branch
<bryceh> he pointed to an xserver fix, which I pulled and uploaded
<RAOF> Have you pushed to git?
<bryceh> yeah, pretty sure I did, let me doublecheck
<bryceh> mesa pushed
<bryceh> (the fix had been pushed but not the changelog entry)
<bryceh> later
<RAOF> Why doesn't git have a âpull --allâ that does what you mean, rather than what some internal component means?
 * penguin42 scratches his head at gtk2-engines-oxygen - the code appears to be expecting the underlying gtk to throw critical level log messages but somehow expects it not to abort 
<cnd> RAOF, what's the timeline for pushing rc2 into ubuntu?
<cnd> or whenever you want to tack on xi 2.1
<RAOF> cnd: Oh, has RC2 been released?
<cnd> I don't know
<cnd> sorry :)
<cnd> I can check
<cnd> the official schedule says 1.10 will be released, final, on friday
<RAOF> Yes, it does.
<RAOF> I suspect the official schedule is lying through its teeth.
<cnd> heh
<cnd> I don't even know where to check these things
<cnd> RAOF, where do get releases from?
<cnd> git?
<RAOF> uscan.
<RAOF> http://xorg.freedesktop.org/releases/individual/xserver/ 
<RAOF> cd -(No RC2 release)
<cnd> RAOF, the latest 1.10 stuff there is from 06-dec-2010...
<cnd> where's rc1?
<RAOF> it's there - 1.9.99.901
<cnd> that's what's in ubuntu right now?
<cnd> from 06-dec-2010?
<RAOF> No; we've got a snapshot.
<cnd> oh
<cnd> ok
<cnd> oh yeah, hence the git part :)
<RAOF> Because the ABI broke between RC1 and now, and I didn't want to have an ABI break in 1.10 packages :)
<cnd> yeah
<cnd> RAOF, so let me know when you want to push, but we have to abide by the feature freeze deadline too
<cnd> so if x doesn't release before this coming monday, I'd suggest we push it as it is
<RAOF> Right.
<cnd> basically, what's in my xorg-unstable ppa right now
<RAOF> I don't have a lot of faith in the X release actually being Friday; if you're all ready to go we could push sooner.
<cnd> RAOF, ok, I may want to wait till the end of the week anyways
<cnd> RAOF, bryceh: as a heads up, I realized we currently suffer a (some might say) bad regression
<cnd> if you have a touchscreen, and an xi 2.1 capable client on a window, and you tap on the window to raise it, and your window manager is not touch aware
<cnd> then the window won't raise
<cnd> I think it may be most prudent to push it like that for now, we have potential work arounds
<cnd> and I'm working on the fully "correct" solution, but I can't guarantee it before feature freeze
<RAOF> I presume unity is touch-aware?  Is metacity?
<cnd> no wms are currently touch aware
<cnd> we can make specific ones touch aware
<cnd> and we can also have a kludge
<cnd> a daemon that sits and acts as a touch aware window manager
<cnd> well, not really window manager
<RAOF> There's going to have to be a proper solution upstream in... oh, my.
<cnd> a touch "raiser"
<RAOF> That's quite the kludge :)
<cnd> yeah...
<cnd> that's one work around
<cnd> there are others
<cnd> the problem is that we inhibit pointer events when touch events are handled
<RAOF> What's the final solution going to look like?  I presume this is being discussed with whot and daniel?
<cnd> we could send pointer events in parallel with touch events
<cnd> but that probably is not going to be the final protocol
<cnd> yes, it's being discussed
<cnd> but the final solution is going to be an interleaving of pointer and touch events
<cnd> so if a window has a touch grab, then you address it first
<cnd> if it also has a pointer grab, then you address it next
<cnd> and you check each window like this down the hierarchy
<RAOF> I guess the other interesting piece of information here is: how many Xi 2.1 capable clients do we have?
<cnd> RAOF, none right now :)
<cnd> of course we're trying to kick start it all
<RAOF> So this is a bad regression on the null set of Xi 2.1 clients :)
<cnd> correct :)
<cnd> if a client is not xi 2.1, there's no regression
<cnd> so this isn't a terribly enormous problem
<cnd> and, at worst, we can tell people: just tap the window title bar
<cnd> or any window decorations
<cnd> so that's why I think we should push it as it is, and then figure out how to fix it, if we do any of these kludges
<RAOF> Right.  I don't think this needs much consideration unless you don't think you'll be able to get a fix in Natty.
<cnd> we could also make unity and metacity touch aware
<cnd> and leave the rest
<cnd> and tell people if they have issues to add some stuff to xorg.conf
<cnd> to disable xi 2.1
<cnd> so I think there's a lot of potential work arounds
<cnd> and the problem isn't extremely severe
<RAOF> Yeah.  You don't think that you'll be able to get the final protocol in Natty?  That'd be an obvious solution.
<cnd> yeah, that's the obvious solution :)
<cnd> but it's really hard too :)
<cnd> I think every time they have changed the input stack (i.e. add xi 1.0, xi 1.5, xi 2.0), they have completely rearchitected it internally
<cnd> I would not be surprised if that's what happens in x 1.11
<cnd> I will be attempting to fit the "correct" protocol into the current architecture
<cnd> and after mapping it out some, I don't think it will be that horrible
<cnd> but it took me three days of analyzing the xserver code to figure out how the hell it worked :_
<cnd> :)
<RAOF> l:)
<cnd> x input sucks :)
<cnd> this would be sooooooooooooooooooo^18 much easier starting from scratch (i.e. wayland :)
<RAOF> :).  I hope you get a chance to hack on that!
<cnd> if I can ever finish xi 2.1, I will!
<cnd> then I'll make my own new window system so I can continue making input systems!
<RAOF> Maybe you could finish Y?
<RAOF> I should probably get a new nvidia card so that I have an nv5x+ card that isn't in a tiny, apallingly slow, netbook.
<afiestas> no crashes tonight :(
<bjsnider> RAOF, when you bought a netbook you didn't expect it to be a supercomputer right?
<RAOF> bjsnider: Indeed I did not.  But it would be nice to have a less slow nv5x+ box; I'd test it more :)
<bjsnider> "less slow" is not very ambitious
<RAOF> Offgering to sponsor me a sandybridge + nvidia desktop and a fusion laptop? :)
 * bjsnider runs screaming in the opposite direction
<RAOF> Hm.  Surprisingly, making unity work on nv5x doesn't actually seem to make any more piglit tests pass.  There's clearly a testcase missing.
<bjsnider> RAOF, why doesn't the nouveau project provide you with the appropriate hardware?
<RAOF> Why would they?
<bjsnider> because you obviously need it
<RAOF> I'd not be developing, particularly, with it.  Just testing.
<bjsnider> testing matters
<RAOF> they've got plenty of testers :)
<bjsnider> it's not a trivial thing you're doing
<bjsnider> they've got plenty of testers who can submit meaningful bug reports?
<RAOF> I could, of course, buy a $30 modern gpu.
<bjsnider> not just "the thing doesn't work in the thing"
<bjsnider> mine cost $50
<bjsnider> Sarvatt, new nvidia blob today
<ricotz> bjsnider, oh really? nice
<Sarvatt> uploaded it to the ppa for natty
<tjaalton> what changes does it have?
<Sarvatt>    - Added NV-CONTROL event notification for
<Sarvatt>      NV_CTRL_FRAMELOCK_SYNC_READY
<Sarvatt>      status changes.
<Sarvatt>    - Added support for the following GPUs:
<Sarvatt>      GeForce GTX 560 Ti
<Sarvatt>    - Added a new X configuration option "Interactive", which defaults to
<Sarvatt>      enabled, but can be disabled to allow long-running GPU compute programs
<Sarvatt>      to run concurrently with X.
<Sarvatt>    - Fixed a bug in the VDPAU presentation queue that could cause VDPAU
<Sarvatt>      "display preemption" when rendering to tiny or zero-sized windows or
<Sarvatt>      pixmaps.
<Sarvatt>    - Fixed a bug in VDPAU which prevented use of the overlay presentation
<Sarvatt>      queue following an application exiting without gracefully destroying its
<Sarvatt>      VDPAU presentation queue.
<Sarvatt> oh and works with natty supposedly
<tjaalton> ok, cool
<tjaalton> though nouveau has been stable after switching away from firefox
<ricotz> Sarvatt, nouveau 3d works with my nvc4 :)
<tjaalton> ricotz: you got the fw from somewhere?
<ricotz> tjaalton, you can get out of a mmiotrace
<Sarvatt> ricotz: people saying this blob doesnt work in natty either in #ubuntu-desktop :(
<tjaalton> ricotz: right
<ricotz> Sarvatt, does it work you? (270.26)
<yofel> got some debugging instructions for nouveau freezes? it locks up on my notebook after a few minutes with that [mi] EQ overflowing error
<Sarvatt> ricotz: about to test now
<Sarvatt> ricotz: hundreds of updates to grab :)
<ricotz> Sarvatt, perhaps you could add a patch to nouveau xorg driver which currently only enables 3d on nvc0
<ricotz> the same initialisation seems to work for nvc3 and nvc4
<Sarvatt> yup doing that now
<ricotz> great
<Sarvatt> uploaded that to xorg-edgers
<Sarvatt> xserver-xorg-video-nouveau_0.0.16+git20110214.46acb7e0-0ubuntu0sarvatt3.
<ricotz> Sarvatt, i am currently running a custom kernel to workaround a known problem
<Sarvatt> http://sarvatt.com/downloads/patches/0001-Also-enable-acceleration-on-nvc3-and-nvc4.patch
<Sarvatt> oh?
<ricotz> i think the cause is only the uninitilized "ret" variable in gpu/nouveau/nouveau_channels.c in kernel
<ricotz> which calim mentioned
<ricotz> but to me sure i switched to natty-master-next+linus-master+nouveau-linux-2.6
<Sarvatt> sheesh this is a crazy amount of upgrades
<ricotz> are you updating the world? :P
<Sarvatt> yeah 530MB worth
<Sarvatt> i haven't updated anything but compiz and chromium-browser since xserver 1.10 went in
<ricotz> ah, ok, i am trying to update more often
 * yofel will leave his notebook frozen if someone has an idea
<tjaalton> yofel: https://wiki.ubuntu.com/X/Backtracing
<yofel> if you need the X backtrace from the EQ overflowing error - I collected that on bug 711908
<ubot4> Launchpad bug 711908 in xserver-xorg-video-nouveau (Ubuntu) "[natty] frequent nouveau freeze on GT218 [NVS 3100M] (rev a2) (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/711908
<tjaalton> yofel: gdb backtrace would be more useful
<tjaalton> if you can ssh in from another machine
<yofel> just doing that
<tjaalton> install the dbg packages first
<tjaalton> libdrm2-dbg, xserver-xorg-video-nouveau-dbg, xserver-xorg-core-dbg
<yofel> thansk
<yofel> *thanks
<ricotz> tjaalton, are there piglit packages for natty available
<Sarvatt> ricotz: dont think so, it doesn't really lend itself well to packaging with how often its updated and is very easy to compile locally
<Sarvatt> btw nvidia 270.26 doesn't work with natty xserver
<Sarvatt> http://paste.ubuntu.com/567382/
<ricotz> Sarvatt, ok
<ricotz> Sarvatt, too bad, is it the same xserver git commit mentioned there?
<Sarvatt> yup
<Sarvatt> but i dont believe it
<Sarvatt> because the extension ABI version changed in january preventing nvidias libglx from loading and it loads properly now
<Sarvatt> building latest xserver git at the moment to see if its any different
<ricotz> hmm, fingers-crossed ;)
<Sarvatt> yay docs dont build
<yofel> tjaalton: got it and added it to the report
<tseliot> Sarvatt: BTW if you're interested, I've just pushed my changes to nvidia-current (still in git): https://github.com/tseliot/nvidia-graphics-drivers/commits/master
<Sarvatt> tseliot: awesome!
<tseliot> Sarvatt: they should fix bug #616214, #540143 and #704607
<ubot4> Launchpad bug 616214 in nvidia-graphics-drivers-96 (Ubuntu Maverick) (and 5 other projects) "Should Depend: on appropriate xserver-xorg-video-$ABI (affects: 7) (heat: 58)" [Undecided,Fix released] https://launchpad.net/bugs/616214
<ubot4> Launchpad bug 540143 in nvidia-graphics-drivers (Ubuntu) "Symlinks libnvidia-tls.so.1 are not removed on package uninstall (affects: 1) (heat: 14)" [Low,In progress] https://launchpad.net/bugs/540143
<ubot4> Launchpad bug 704607 in nvidia-graphics-drivers (Ubuntu) "Packaging issues in nvidia-current (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/704607
<tseliot> I haven't uploaded anything to Natty yet because of the ABI
<Sarvatt> building the latest xserver with --disable-devel-docs --without-fop added works, phew
<Sarvatt> #0  0xb5f477e3 in ?? () from /usr/lib/xorg/extra-modules/nvidia_drv.so is all I get, no change
<tseliot> :/
<tseliot> Sarvatt: on amd64?
<Sarvatt> i386, i dont use amd64 on any machines i care about
<tseliot> ah
<Sarvatt> looks like they just allowed extension abi 5 in their libglx and didn't update the xserver checkout it was built against
<Sarvatt> which sucks because they said they would in the next beta release on the forums
<tseliot> Sarvatt: can you generate an nvidia-bug-report.log, please? I'd like to send it to nvidia
<Sarvatt> sure thing
<Sarvatt> looks like it wasnt expected that 270.26 was compiled against the old xserver again - http://www.nvnews.net/vbulletin/showthread.php?s=fc330a9c1191f1a1b11159e26b751c67&t=159610
<tseliot> oh, maybe it's just a mistake
<Sarvatt> tseliot: http://sarvatt.com/downloads/nvidia-bug-report.log
<tseliot> Sarvatt: thanks
<tseliot> Sarvatt: the log says against what commit of the xserver the driver was built
<tseliot> i.e. 780754050bc9cb1489f92a2a890ab5665e3e6358
<tseliot> Sarvatt: what's the commit that broke the ABI again after December?
<Sarvatt> tseliot: there were a ton of them, lets see..
<Sarvatt> tseliot: they fixed the extension abi break that stopped libglx from loading but didn't fix the video abi breaks
<tseliot> Sarvatt: ok
<tjaalton> yofel: thanks, that's exactly what I've seen too
<tjaalton> well, the other crasher
<tjaalton> yofel: can you forward that upstream? if not, I'll do it tomorrow, or check if there's already one filed
<Sarvatt> ricotz: whoops looks like i uploaded the wrong thing to the PPA for nouveau, sorry about that
<Sarvatt> oh nevermind, right one is up there
<ricotz> Sarvatt, yeah, i checked the diff, it is fine, but havent restarted x yet
<yofel> tjaalton: since you understand the error better than me, it would be nice if you could do it
<bjsnider> Sarvatt, nvidia released a driver that still doesn't work with the new x server? i don't understand
<tjaalton> yofel: sure, no problem
<yofel> bjsnider: nope, still crashes X (270.26)
<Sarvatt> oh boy
<Sarvatt> The following packages have unmet dependencies:
<Sarvatt>  xserver-xorg-input-evdev : Depends: xorg-input-abi-12.1
<Sarvatt>  xserver-xorg-input-mouse : Depends: xorg-input-abi-12.1
<Sarvatt> we depend on the minor version too? :D
<Sarvatt> ricotz: http://paste.ubuntu.com/567425/ darn
<Sarvatt> ricotz: what kernel patch did you say you needed? i'm on another machine now and dont have the logs
<ricotz> Sarvatt, using natty/edgers packages, with the current natty kernel it boots normal without fw -- resulting in using swrast -- with fw already kms fails for me
<ricotz> let me search for the line
<dupondje> hi
<dupondje> can somebody change https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/714280 to not-fixed ?
<ubot4> Launchpad bug 714280 in xorg-server (Ubuntu) (and 3 other projects) "The error was 'BadLength (poly request too large or internal Xlib length erro'. (affects: 5) (dups: 1) (heat: 32)" [Undecided,Fix released]
<ricotz> Sarvatt, http://cgit.freedesktop.org/nouveau/linux-2.6/diff/drivers/gpu/drm/nouveau/nouveau_channel.c?id=3428239fc054b0c6d6024aea293f5efa02b5dc95
<jcristau> dupondje: can you get a backtrace from gdb?
<jcristau> (break on _XError)
<dupondje> jcristau: if you give me some hints how to :)
<dupondje> fetching firefox-dbg :)
<jcristau> you'll want libgl1-mesa-glx-dbg and libx11-6-dbg
<dupondje> mmm
<dupondje> "/usr/bin/firefox": not in executable format: File format not recognised
<jcristau> firefox -g or something
<jcristau> also, somebody should fix firefox's X error handler to not be so useless
<dupondje> sorry router needed a reboot )Ã 
<dupondje> jcristau: http://paste.ubuntu.com/567438/
<jcristau> dupondje: in frame 7, print *sgi_req
<dupondje> euh ? :)
<jcristau> at the gdb prompt, type 'frame 7'
<jcristau> and then 'print *sgi_req'
<dupondje> (gdb) print *sgi_req
<dupondje> value has been optimised out
<jcristau> bah.
<dupondje> not very usefull eh :D
<dupondje> if you need more info .. :)
<jcristau> if you can get a noopt mesa build...
<dupondje> how :)
<jcristau> set DEB_BUILD_OPTIONS=noopt
<dupondje> then rebuild mesa ? or ?
<jcristau> yes
<dupondje> works with pbuilder-dist also ?
<jcristau> i have no idea
<dupondje> how can I see its building with noopt ?
<dupondje> nvm :)
<dupondje> lets just change debian/rules ^^
<dupondje> building
<dupondje> still building :(
<dupondje> :p
<ricotz> Sarvatt_, any luck?
<dupondje> jcristau: 
<dupondje> (gdb) print *sgi_req
<dupondje> $1 = {reqType = 98 'b', glxCode = 17 '\021', length = 3, vendorCode = 65539, pad1 = 3, screen = 0}
<jcristau> dupondje: hrm.  that vendorcode makes no sense.
<jcristau> #define X_GLXvop_GetFBConfigsSGIX               65540
<jcristau> should be that one.
<dupondje> thats what I get ;)
<dupondje> jcristau: got enough debug info ? :)
<jcristau> i suppose i should try and reproduce..
<dupondje> the link on the bugreport page gives me a crash directly :)
<jcristau> well i'm not running ubuntu..
<bjsnider> Sarvatt, should i bother to update the maverick/lucid blob? sounds like they didn't do anything helpful
<Sarvatt> bjsnider: I sure as heck ain't gonna do it, up to you if you want it in there but nope it doesn't look like its anything interesting
<RAOF> Looks like we might want f67a559daaa0 from drm-intel if we want e6510 systems to work :)
<dupondje> bryceh: I can reproduce 714280
<dupondje> every single time :s
<jcristau> dupondje: i assume it goes away if you set your locale to something en_*?
<Sarvatt> RAOF: https://patchwork.kernel.org/patch/499221/ too for the backlight to actually work
<jcristau> RAOF: who wants a display on a laptop anyway..
<dupondje> LANG="en_US.UTF-8"
<dupondje> no more crash ...
<jcristau> dupondje: ok, at least that much makes sense.
<bryceh> dupondje, interesting
<dupondje> normally I use nl_BE btw
<dupondje> if you want to try to reproduce
<bryceh> nope, still no crash
<dupondje> weird
<dupondje> got to test smth
<dupondje> brb
<dupondje> ok, now thats the weirdest thing ...
<dupondje> changed LANG back to nl_BE .. and guess what
<dupondje> it doesn't crash ..
<dupondje> ah ok
<dupondje> page was in cache in firefox, and thats why :)
<Sarvatt> RAOF: a new xserver git snapshot will change abi's in a way that breaks all input driver packages so there will be some turmoil.. we're depending on minor abi's too :(
<RAOF> Yeah, that was a mistake.  Although I think we *may* have needed to rebuild anyway, because they'd behave strangly if not.
<dupondje> bryceh: can you remove page from cache ?
<dupondje> and try to view it with locale nl_BE.UTF-8
<jcristau> dupondje: does glxinfo or glxgears crash?
<dupondje> nope
<dupondje> can you set LANG to nl_BE.UTF-8
<dupondje> run firefox
<dupondje> and view http://support.mozilla.com/gd/questions/753448 ?
<jcristau> as i said, i'm not running ubuntu.
<dupondje> @ bryceh  ;)
<jcristau> ok :)
<dupondje> btw
<dupondje> [GLX] currently only allowing the NVIDIA proprietary driver, as other drivers are giving too many crashes. To bypass this, define the MOZ_GLX_IGNORE_BLACKLIST environment variable.
<dupondje> never seen that message before ... 
<jcristau> bryceh: fwiw the locale bit is strtod("1.4") not returning 1.4 if the decimal separator in the current locale.
<jcristau> err, add "is not '.'" at the end there.
<bryceh> dupondje, done, visited url in a restarted firefox with that LANG... no crashes
<bryceh> jcristau, ahh
<dupondje> weird
<dupondje> http://paste.ubuntu.com/567494/
<dupondje> looks clear now its the locale ;)
<bryceh> dupondje, fwiw that GLX warning seems sensible.  -nouveau is kinda hit or miss for 3D
<dupondje> i'm not on nouveau
<dupondje> but ati
<RAOF> That's actually mozilla blacklisting everything but the binary nvidia driver; WebGL won't work on intel or amd.
<bryceh> oh wild
<RAOF> Yeah.  There's a pretty big thread on mesa-dev@ about it, with mozilla and chromium devs complaining about libGL crashes when they enable it.
<jcristau> dupondje: i have no idea why you don't get the same thing from glxinfo.  it seems to do GetFBConfigsSGIX too afaict..
<bryceh> well, I suppose WebGL is still relatively new.  Probably depends on newer GL stuff the other drivers don't have yet.
<RAOF> Actually, they were complaining that they couldn't even probe the driver in use without libGL crashing :)
<RAOF> Both radeon and intel should now support all the features required, though.
<dupondje> jcristau: I wish I could give you the answer :)
<bryceh> jcristau, are you able to reproduce the crash?
<dupondje> <jcristau> as i said, i'm not running ubuntu.
<dupondje> :)
<jcristau> need to try and download a natty cd at some point i guess
<dupondje> I can debug some more if wanted
<dupondje> just tell me what :)
 * albert23 can reproduce the crash with http://support.mozilla.com/gd/questions/753448, not with the link in the bug
<dupondje> locale ?
<jcristau> maybe break without the _XReply in getFBConfigs, see what sgi_req looks like then.  or run firefox through xtrace or wireshark.
<jcristau> s/without/before/
<bryceh> xtrace would be good
<albert23> dupondje: nl_NL
<jcristau> xtrace 1.2.0 may be better if you have a chance to sync that
<dupondje> never used xtrace
<bryceh> dupondje, there's adequate help on it via google
<jcristau> works pretty much like strace or ltrace, except for X protocol instead of syscalls.
<jcristau> so something like 'xtrace -o my_firefox_trace firefox http://support.mozilla.com/gd/questions/753448'
<dupondje> uploaded to the bug
<dupondje> http://launchpadlibrarian.net/64420019/my_firefox_trace
<jcristau> ok, so vendor_op=0x00010004 is indeed GetFBConfigsSGIX.  but the 40 in front of it is supposed to be the length, and that doesn't make sense.
<jcristau> dupondje: can you get me an xtrace from glxinfo?
<dupondje> sure
<dupondje> http://launchpadlibrarian.net/64420572/glxinfo
<dupondje> there
<jcristau> oh crap
<jcristau> glxinfo doesn't do setlocale()
<jcristau> so it takes the glx 1.3 path
<jcristau> bryceh: is the ubuntu stuff in git up to date, or missing some bits?
<bryceh> jcristau, should be up to date
<jcristau> hrm
<jcristau> that doesn't have the right fixes
<bryceh> jcristau, which package?
<jcristau> mesa
<jcristau> you want 4324d6fdfbba17e66b476cf008713d26cac83ad1 e27913f805acbb7d00f83ba625a8605576738a13 cbe9fc12a64c3ae89fd1b20e9e165aa4b76293a5
<jcristau> 108_fix_leaks_dri2_screen_creation.patch is unrelated to that bug
<dupondje> anyway
<dupondje> I go sleeping :)
<dupondje> if some more debugging/testing is needed, feel free to add to the bug or mail me :)
<jcristau> dupondje: thanks
<bryceh> jcristau, got it thanks
<jcristau> i guess there was some confusion with dupondje linking a different commit from the bug
<bryceh> yeah
<bryceh> dupondje, jcristau, uploaded mesa with correct fix.  Thanks for investigating, hopefully it's fixed for good now, sorry for my confusion.
<jcristau> thanks
<RAOF> Sarvatt: Do you have any comments on my gallium fallback RFC?
#ubuntu-x 2011-02-16
<RAOF> bryceh, tjaalton: What do you think about switching to r600g by default and announcing a call-for-testing?
<RAOF> #dri-devel is being very âwhy are you trying to fix r600câ and âyeah, we just made sure r600g works with gnome-shellâ.
<bryceh> RAOF, I'm in favor of switching.  There are trade-offs however
<RAOF> Yes.
<bryceh> on the one hand, what we have has been tested in the distro and seems reasonably stable aside from a few bugs (which we know about and which look reasonably fixable I guess)
<bryceh> on the other hand, upstream is focusing only on the gallium side, so if we upstream bug reports and patches, they'll be more interested
<RAOF> Yeah.
<bryceh> RAOF, obviously it's insufficient to switch just for the sake of making upstream developer's lives better (c.f. lessons learned with -intel taking this approach)
<bryceh> however it's been my experience the ATI guys are much more grounded and give better advice
<RAOF> We'd also be following debian and fedora here, so there is at least a bigger testing pool.
<bryceh> RAOF, ultimately I think if we switch in order to get better responsiveness from upstream on bugs, then we really ought to take good advantage of it by making sure we forward -ati bugs aggressively
<bryceh> RAOF, what were the main reasons we had for sticking with r600c?  just stability concerns?
<RAOF> Yes.
<bryceh> so then yeah, I think it would be ok, so long as we are attentive to forwarding bugs up
<RAOF> We weren't sure whether it would be ready for default, and we hadn't tested it like we have r600c.
<bryceh> the -ati guys are easy to work with and have been dependable for sorting out issues when we've pulled in new ati bits late in the release in the past, so I'd not be uncomfortable doing this.
<RAOF> Ok.  I'll update the new 7.10.1 snapshot with that in mind.
<bryceh> one other thought
<bryceh> actually, nevermind
<bryceh> when do you think you'll have 7.10.1 ready for upload?
<bryceh> if it's going to be more than a week, I'd like to roll out cherrypicks that we know fix issues; the less bugs we have to keep track of, the easier it makes triage ;-)
<bryceh> ok, wife is chomping at the bit to go out to dinner (belated valentines day or she just doesn't want to cook tonight... hard to say)
<RAOF> Approximately now :)
<RAOF> Have dining fun!
<bryceh> ok, if you knock something together, email me and I'll upload tomorrow morning
<tjaalton> RAOF: yeah, sounds good
<RAOF> You wouldn't additionally have any response to the driver selection RFC I sent out to ubuntu-x@ a couple of days ago? :)
<tjaalton> ah, let me check
<tjaalton> RAOF: the galleon switchover stuff?
<tjaalton> uh
<tjaalton> gallium
<RAOF> tjaalton: Yeah.  Exactly.
 * RAOF would *also* like to be involved in a galleon switchover :)
<tjaalton> hehe
<tjaalton> so that patch would be for people to fall back on r600c if they find r600g unstable for them?
<RAOF> It would be to fallback to r600c if they have disabled KMS.
<tjaalton> oh right
<tjaalton> maybe the second option would work then
<RAOF> Currently they can twiddle it with the ForceGallium xorg.conf option.
<RAOF> Or, rather, the second option would be so that it falls back to r600c if they've disabled KMS.
<tjaalton> and ship r600c in the "other" directory, and drop when UMS support is dropped
<RAOF> The first option *additionally* allows users to twiddle gallium/classic.
<RAOF> Independent of KMS.
<RAOF> I guess I'm undecided on the utility of providing that knob.
<tjaalton> hmm, so for r300 the fallback with UMS already happens?
<tjaalton> without extra patching
<RAOF> With the existing ForceGallium patch, yeah.
<tjaalton> ah
<RAOF> This is replacing the existing patch, which works but in a way which potentially breaks people who are testing mesa, with a different (upstream approved) solution.
<tjaalton> oh right, they all are shipped in the same dir
<tjaalton> guess I need to think about it for awhile then :)
 * tjaalton grabs a cup of tea
<tjaalton> why doesn't gallium work with UMS?
<tjaalton> maybe i'm missing something obvious
<RAOF> Probably because it assumes the whole gem/ttm kit and caboodle.
 * RAOF wonders idly what a caboodle is.
<RAOF> Also possible: it's only DRI2, and DRI2 is only available on KMS for radeon.
<tjaalton> ah, that's it then
<RAOF> (Although that's pretty close to a restatement of requiring gem/ttm)
<bryceh> http://www.phrases.org.uk/meanings/kit-and-caboodle.html
<tjaalton> RAOF: does classic work with KMS?
<RAOF> Yes, it does.
<tjaalton> ok
<RAOF> Otherwise option 2 would be the trivial solution, yes :)
<tjaalton> that makes more sense, yep
<tjaalton> right
<tjaalton> this patch would be useful as long as UMS is also available
<tjaalton> no wait. duh
<tjaalton> since kms works with both, the line above is _not_ true :)
<tjaalton> though how long is the classic ones supported
<tjaalton> are
<tjaalton> RAOF: I guess the second option is better. when the option becomes obsolete there'll be a number of people with it in their xorg.conf, that probably have forgot about it by then and wonder why the config broke
<RAOF> Heh, yes.
<tjaalton> and the second one can be silently dropped at some point
<tjaalton> though if it makes upstream there's no need
<RAOF> Yeah.
<RAOF> It can just sit there, waiting for some other driver to do something similar.
<tjaalton> right, like... *chrome? :P
<RAOF> Oh, wow.  Yeah, I guess they might do something like that!
<jcristau> soon each via owner can use a different driver
<tjaalton> more drivers than users :)
<vish> freaky spam's subject!! "Hello alberto.milone! A lot of software is for windows and macOS! Logic Studio 8 Full Pack with Content" 
<vish> but i'm not tseliot! ;p
<tseliot> :D
<tjaalton> I closed bug 710762 as wontfix
<ubot4> Launchpad bug 710762 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Middle mouse button no longer works (affects: 3) (heat: 18)" [Undecided,Won't fix] https://launchpad.net/bugs/710762
<tjaalton> RAOF: you got a new mesa in the works?
<RAOF> tjaalton: 
<RAOF> Yeah.  I should push it to git.
<bryceh> tjaalton, good call.  Might be worth a brief mention on https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<bryceh> well, it's late, time for bed.  cya
<RAOF> Night!
<tjaalton> bryceh: ok, will add
<tjaalton> RAOF: ok, so unity works with the nouveau commit by calim?
<vish> tjaalton: unity depends on middle click
<tjaalton> vish: you have three buttons right?
<vish> iirc it is for "open new instance"
<vish> tjaalton: yea, but there is what they have done.. removed the item from the context menu and made it depend on middle click
<RAOF> tjaalton: Yeah, for me at least.
<tjaalton> RAOF: cool, so I'll be able to test too
<tjaalton> vish: well, there are tradeoffs to re-enable it, as described on the commit (also on the bug)
<vish> sure, but i think it should be mentioned to the unity folks..
<tjaalton> they should've noticed by now
<tjaalton> but anyway, where can I find them?
<vish> tjaalton: its Bug #709707 btw
<ubot4> Launchpad bug 709707 in unity (Ubuntu) (and 2 other projects) "Middle click on application icon should open a new window (affects: 2) (heat: 12)" [Medium,Fix released] https://launchpad.net/bugs/709707
<vish> tjaalton: on #ayatana
<tjaalton> vish: thanks
<vish> np..
<tjaalton> re-enabling the emulation is possible via input properties, so it should be added to "The GUI" if needed
<lool> My desktop doesn't get redrawn properly if I switch to console and back to Xorg, but it does if I switch workspace; is this tracked in a bug already?
<lool> (-intel)
<tjaalton> bryceh is probably best on top of intel bugs atm, I haven't seen that behaviour on mine
<bjsnider> kklimonda, i convinced pitti to change nvidia-common so it's a hard dependency of jockey-common. so starting with natty, to use the nvidia-installer, you'll have to remove all of jockey
<kklimonda> bjsnider: that's great news imo :)
 * dupondje thanks bryceh & jcristau 
<dupondje> issue seems solved :)
<bryceh> dupondje, good to hear, what was the fix ultimately?
<dupondje> installing your patched version ? .
<dupondje> ;)
<bryceh> dupondje, ahh good
<dupondje> btw, you maby have upload rights to fix https://bugs.launchpad.net/ubuntu/+source/gtk-vnc/+bug/711442 ? ;)
<ubot4> Launchpad bug 711442 in vinagre (Ubuntu) (and 1 other project) "vinagre crashed with SIGSEGV in g_socket_send() (affects: 3) (dups: 1) (heat: 269)" [Medium,New]
<bryceh> dupondje, I do, but there's also a Patch Pilot on call right now (sconklin) who is on deck for sponsoring these sorts of things
<bryceh> dupondje, point him to the bug on #ubuntu-devel and ask for sponsorship
<bryceh> dupondje, that'll be the "right way" to handle this.  :-)  If he doesn't respond or if you have any trouble let me know and I'll lend a hand.
<ricotz> Sarvatt, i am going to update mesa in edgers, there were quite some nvc0 commits ;)
<Sarvatt> ricotz: appreciated! :)
<bryceh> weird, after messing around with the keyboard layout prefs dialog debugging some bugs, now my windows no longer take focus when clicked; only when I click the title bars
<bryceh> if I set to focus-follows-mouse, that works, but then unset that and back to broken behavior
<RAOF> That's highly odd.
<RAOF> Does switching to metacity work?
<bryceh> this is with metacity running actually
<RAOF> Well, that bet I was about to make about it being a compiz problem looks pretty silly now. :)
#ubuntu-x 2011-02-17
<bryceh> RAOF, dunno if you've run across it but there is some sort of OOM situation that crops up during livecd testing
<bryceh> RAOF, which has had a tendancy to show itself as an X crash somewhere in the error handling logic
<RAOF> bryceh: I don't do much livecd testing, so I haven't hit it.  Fun!
<bryceh> I've put in some patches for those crashes, but the root cause of the OOM situation remains a mystery
<bryceh> RAOF, anyway, it's been sort of wack-a-mole.  Fix a crash today, wait a couple days, and see where X crashes next.  :-)
<bryceh> RAOF, so keep an ear open for people with bugs like this one - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/720445
<ubot4> Launchpad bug 720445 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in _start() (affects: 1) (heat: 10)" [Medium,New]
<bryceh> specifically, the pattern in the Xorg.0.log - http://launchpadlibrarian.net/64482277/XorgLogOld.txt
<bryceh> it's a sudden spew of "[   191.259] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Cannot allocate memory" followed by a crash somewhere in the error handling stack
<RAOF> We don't have memory details in the apport crashes, do we.
<bryceh> unfortunately no
<bryceh> I don't think I had that problem when installing from CD.  maybe using usb keys it's different?
<RAOF> Possibly?
<bryceh> RAOF, so far, it's entirely been canonical people (mostly in the testing teams) who have reported these kinds of bugs, not community folk in the general public
<bryceh> so that seems odd
<RAOF> Something has to be leaking memory somewhere, and it has to be pretty early into boot.
<RAOF> It's even possible that it's the union filesystem we use.
 * bryceh nods
 * RAOF wants a faster laptop.  Maybe with 8 processors, or something.
<bryceh> given that we don't (afaik) have such a memory leak outside the livecd environment, it makes me doubtful that it's X leaking, however anything's possible I suppose
<RAOF> It could be something in the live environment that X isn't handling.
<RAOF> Any of these crashes with anything but intel?
<bryceh> all have been with intel
<bryceh> it might not be significant though, I think the vast majority of the testing hw is intel gfx
<RAOF> Yeah.
<RAOF> â¦-Wl,-rpath,:::::::::::::::.  Really, compiz?  Really?  You need to check all those empty linker paths?
<bryceh> RAOF, I'm getting towards EOD... any bits or patches you need uploaded?
<bryceh> áááá± áááá± áááá±
<RAOF> mesa would be nice.
<RAOF> Um, ???
<bryceh> been having xkeyboard-config fun today ;-)
<RAOF> What was that string? :)
<bryceh> it was "blah blah blah" in Canadian Inuktitut
<RAOF> :)
<bryceh> which I've never heard of before but has nice letter forms
<bryceh> looks easy to draw in snow or polar bear hides
<RAOF> :)
<RAOF> I haven't yet tested the final mesa build on my netbook (stupid i386!), though it should be good.
<bryceh> got a .dsc or git branch ready for mesa?
<RAOF> http://cooperteam.net/Packages
<bryceh> ok, I think with mesa especially, I shouldn't upload at EOD
<bryceh> but I'll load it on a few systems tomorrow and test it out, and if it looks good will upload it
<RAOF> Yeah, good call.
<RAOF> I might have the various other pieces of the r600g switch ready by then, so we could do that at the same time, or in a subsequent upload.
 * bryceh snags and starts a build
<bryceh> sounds good
<bryceh> I tend to favor being prolific with uploads when we're not in release crunch; it can give folks extra versions to test, which can help in narrowing down when issues appeared
<RAOF> Right.
<bryceh> RAOF, changelog should mention the -1ubuntu[23] changes too
<bryceh> the two patches can be dropped, but the libudev-dev change needs mentioning
<RAOF> The 1ubuntu[2,3] changes are in the changelog.
<RAOF> Ah, but I forgot to include the Debian revisions in the .changes, however.
<bryceh> oh I mean in the 'Remaining Ubuntu changes' section
<RAOF> Oh, right.
<alex_mayorga> bryceh: ping
<bryceh> yeah
<alex_mayorga> I've updated bug 713781
<ubot4> Launchpad bug 713781 in xserver-xorg-video-nouveau (Ubuntu) (and 1 other project) "[natty] Video corruption on kernel 2.6.38-1-generic and nVidia Corporation GT216 [GeForce GT 230M] (rev a2) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/713781
<alex_mayorga> please let  me know if anything else is needed
<alex_mayorga> still not working on 2.6.38-3
<alex_mayorga> should I rename it
<bryceh> alex_mayorga, thanks.  I can take care of that
<alex_mayorga> should I gather something on the working 2.6.37?
<alex_mayorga> bryceh: thanks to you for caring :)
<RAOF> Is that the one I responded toâ¦
 * RAOF wonders, and checks.
<bryceh> RAOF, yep
<bryceh> RAOF, let me know if you'd rather do the upstreaming
<bryceh> alex_mayorga, no that's not necessary, although it might be nice to know what version last worked properly for you
<RAOF> Nah, I'm happy for you to upstream.
<alex_mayorga> 2.6.37-12-generic
<alex_mayorga> bryceh: that's in comment #5
<bryceh> great thanks
<bryceh> alex_mayorga, one thing to try, if you can reproduce it on a livecd or liveusb, is to try booting the i386 image. Could be a 64bit specific issue.
<alex_mayorga> bryceh: which one should I try? daily?
<alex_mayorga> would need to find a USB though
<bryceh> a daily would be fine, whatever works for you
<alex_mayorga> I'd give it a try if I find a big enough USB
<bryceh> ok, forwarded as https://bugs.freedesktop.org/show_bug.cgi?id=34371
<ubot4> Freedesktop bug 34371 in Driver/nouveau "[natty] Video corruption on kernel 2.6.38-1-generic (and on -3) and nVidia Corporation GT216 [GeForce GT 230M] (rev a2)" [Normal,New]
<bryceh> alex_mayorga and RAOF, please add yourselves to the CC of that bug ^^ 
<alex_mayorga> bryceh: done, thanks!
<lilstevie> I am having a problem with X not giving me any output into why it isnt outputting to the display, is there anything better than invoking X with -verbose 20?
<tjaalton> which release?
<lilstevie> 1.9.0
<tjaalton> so ubuntu 10.10?
<lilstevie> yes
<tjaalton> livecd or did it break by itself?
<lilstevie> http://pastie.org/1570123 <- this is the output
<lilstevie> armel
<lilstevie> never had it running
<tjaalton> fix the kernel first
<tjaalton> there are no input devices it seems
<lilstevie> well thats because GPIO buttons and touch screen are the only input devices
<lilstevie> what is wrong with the kernel?
<tjaalton> still, it's either kernel or udev failing
<tjaalton> not X
<lilstevie> ok
<tjaalton> no device has ID_INPUT set by udev
<lilstevie> hm ok
<tjaalton> so either the kernel has no such devices or udev fails otherwise
<tjaalton> hum no, it did find the touchscreen
<lilstevie> ok so that is stopping X from working
<lilstevie> the backlight of the lcd flashes on and off
<tjaalton> dunno why config/udev spams the log like that
<tjaalton> if there's natty alpha2 image for arm, you could try that if it fails the same way
<lilstevie> heh
<tjaalton> bbl->
<bigon> hi when compiling examples of champlain from GIT on natty I get
<bigon> http://pastebin.com/9jhJ2WNJ
<Darxus> Might be worth cherry picking this, required for wayland outside of X with nouveau:  http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=8e645575d469bf08c9d5d98a101ef4cfce6a9180
<Darxus> Although I don't know if everything else needed is already in the natty kernel.
<tjaalton> roughly 80 bugs against fglrx-installer (out of the 370 filed) where the kernel module failed to build
<tjaalton> because there were unofficial kernel packages installed, and dkms barfed
<Sarvatt> tjaalton: you missed the cleanup of those about 2 months ago too, was closer to 800 :)
<Sarvatt> across all the dkms packages
<tjaalton> Sarvatt: and no-one thought about fixing the root problem?-)
<tjaalton> anyway, it should be doable
<tjaalton> bbl->
<Sarvatt> tjaalton: what do you mean? we did at the time
<Sarvatt> oh you mean just the ones with unofficial kernel packages?
<Sarvatt> missed that part, sorry
<tjaalton> yeah, now that there are mainline builds etc that people are testing..
<tjaalton> closed over 30 "fixed upstream" bugs today, another batch waiting for tomorrow
<bryceh> tjaalton, thanks for tending to those
<tjaalton> bryceh: was a refreshing experience :)
<bryceh> tjaalton, I think I can even see the dent it made - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals.svg
<bryceh> or maybe not, that's a humongous graph :-)
<tjaalton> yeah I've been cleaning some bugs along these past two weeks, at least the "remainder" is going down :)
<bryceh> tjaalton, btw I'm sure I've shown you this already but in case not - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> I ended up not really worrying about _total_ bug reports, but rather focusing on bug reports against the current development version
<tjaalton> but speaking of natty, I should test wacom a bit. noticed that there's some crasher reported recently
<tjaalton> yeah
<bryceh> which I've found to be a lot more tractable
<bryceh> and the 'workqueue' variant shows bugs that aren't already incomplete/upstreamed/fix-committed so it's just bugs we have to actually look at
<bryceh> the lines are clickable too so you can go see the exact bugs (more or less)
<tjaalton> yep, nice lists/graphs
<bryceh> also did a tabular view of all bugs in the workqueue - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/workqueue-natty.html
<bryceh> anyway, I'm probably the only person in the world that geeks out this much over bug graphs/lists.  ;-)  But I think it's been really useful for keeping on top of bug reports this release.
<tjaalton> i've noticed, the speed of seeing bugs reported upstream (by you) is breathtaking ;)
<tjaalton> um, bad language
<bryceh> hi jaytaoko
<bryceh> jaytaoko, btw, just fyi I've removed the glxinfo call from the apport hook.
<bryceh> jaytaoko, I am guessing you guys don't need it for compiz/unity reports; in any case glxinfo has been moved to universe so not everyone has it installed, and so the apport hook gets errors in those cases.
<bryceh> jaytaoko, if you do need any of the info that glxinfo produces, maybe you can roll it into the unity support test tool
#ubuntu-x 2011-02-18
<RAOF> bryceh: Revised mesa with better changelog, debian changelog in source.changes, and actual building on i386 is up on cooperteam.net.
<bryceh> RAOF, awesome thanks
<RAOF> Oh, and perhaps incidentally, it also works ;)
<bryceh> RAOF, btw the previous mesa had been failing to build
<bryceh> # Also get rid of other files which aren't installed. Do not
<bryceh> # use -f to ensure we notice disappearing files:
<bryceh> set -e; for file in dri/usr/include/GL/glfbdev.h dri/usr/include/GL/glu.h dri/usr/include/GL/glu_mangle.h dri/usr/include/GL/mesa_wgl.h dri/usr/include/GL/osmesa.h dri/usr/include/GL/vms_x_fix.h dri/usr/include/GL/wglext.h dri/usr/include/GL/wmesa.h dri/usr/lib/libGL.so dri/usr/lib/pkgconfig/gl.pc usr/include/GL/glext.h usr/include/GL/glfbdev.h usr/include/GL/gl.h usr/include/GL/gl_mangle.h usr/include/GL/glxext.h usr/include/
<bryceh> v/pkgconfig/gl.pc ; do rm debian/tmp/$file; done
<bryceh> rm: cannot remove `debian/tmp/usr/lib/i686/cmov/libGL.so': No such file or directory
<bryceh> make: *** [binary-arch] Error 1
<bryceh> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
<bryceh> E: Failed autobuilding of package
<RAOF> bryceh: Yeah, that's what I fixed for i386.
<bryceh> hadn't had a chance to investigate it yet though.  Will try again with your new package
<RAOF> if you were to build that package on amd64 it would have built just fine :) 
<RAOF> It's becaues Debian build i686 swrast packages on i386 and we don't.
<RAOF> Or even because.
<bryceh> huh interesting
<bryceh> dpkg-source: info: upstream files that have been modified: 
<bryceh>  mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/common/dri_util.c
<bryceh>  mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/radeon/radeon_bocs_wrapper.h
<RAOF> Yeah.  From debian's cherry-picks.
<RAOF> Debian cherry-picks into the debian diff, and I think we should too.
<RAOF> It means the cherry-picks get automatically dropped when they get included in the upstream tarball.
<RAOF> Hm.  Sam's out at work.  I'll have to make my *own* coffee this morning!
<bryceh> heh
<bryceh> I will be joining you in a cup, even though it's after 5pm
<bryceh> go little processor go, let's get this mesa built
<RAOF> I could throw up binaries if you wanted.
<bryceh> nah it just finished
<bryceh> might not be a bad idea in the future though
<bryceh> otoh can't hurt to doublecheck the build
<bryceh> I'm installing libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb
<bryceh> anything else worth putting in for testing purposes?
<bryceh> well, lets start with this... rebooting
<RAOF> ...
 * RAOF is too slow :)
<bryceh> metacity looks fine...
<bryceh> ew, unity looks like trash
<RAOF> What card?
<bryceh> RV770
<bryceh> actually it was fine after I did a screen refresh
<bryceh> guessing it's a dual-head issue, since only the left screen showed it
<RAOF> Ah, yeah, entirely possible.
<bryceh> (it redrew the left portion of the screen in the middle of the screen)
<bryceh> anyway, otherwise so far so good
<RAOF> Nux is easily confused about where things should be.
<bryceh> also to be honest I'm not sure that effect might have been there previously
<RAOF> Apart from, I presume, alt-tab still segfaulting in mipmap generation code :)
<bryceh> oh yeah lemme try that
<RAOF> (Still segfaulted here, and also did so on master, so I'm quite confident that yours will segfault too ;))
<RAOF> Oh.  That looks ominous!
<bryceh> yep sure did
<bryceh> also, left screen weirdness reproduces 2-for-2
<RAOF> Is there any dynamic xrandr happening?
<bryceh> fonts are all stretched out 
<RAOF> Is gdm cloned, and on login unity starts before g-s-d sets up the spanned desktop?
 * RAOF doesn't see that, possibly because g-s-d sets up the second head before unity has got far enough to care.
<bryceh> gdm is not cloned
<RAOF> Although it sounds exactly like what happens when I plug or unplug a second head.
<bryceh> I set up side-by-side dual head and set as system default
<bryceh> so login prompt appears only on the left screen
<bryceh> but
<bryceh> I have a bunch of apps that start up in my .xprofile
<bryceh> and I've found they sometimes will initiate prior to the window manager being "done" loading
<bryceh> so I get fun things like xchat not having the themed decorations, and gnome-terminal windows that shift around once the panels launch
<bryceh> goodness unity is buggy
<bryceh> if the launcher is over a gnome-terminal session, gnome-terminal appears to steal the mouse events
<RAOF> I should possibly take up Jason's call and do the (apparently pretty easy) dynamic xrandr integration stuff.
<RAOF> Hm, that doesn't happen here :)
<bryceh> fwiw I'm also running apw's 2.6.38-4-generic pre-release kernel thingee, although that probably doesn't matter
<bryceh> (however now plymouth works all of a sudden)
<RAOF> Heh!
<cnd> RAOF, bryceh: an update: I've got touch events integrated into the pointer event stream properly now
<cnd> after redoing most of the stack
<RAOF> cnd: Yay!
<bryceh> ironically for ~1-2 min boot it displays the ubuntu logo for barely 1 sec
<cnd> I'm now just fixing up touch event handlin
<cnd> g
<cnd> the code is a bit of a mess right now, so once I have it working I need to clean it up a little
<RAOF> cnd: I think it's a fair call that Xserver 1.10 is not being released today; when do you want to incorporate Xi 2.1?L
<cnd> but it will still be hairy when it's ready to go, probably early next week
<bryceh> cnd, so I take it you wouldn't like to hear that the unity guys want us moved back to xserver 1.9 so -nvidia will work?
<cnd> bryceh, (!)?
<cnd> as in, roll back for natty?
<cnd> or roll back just for right now?
<cnd> I had heard the nvidia drivers still worked, but there was some politics with abi versioning and the distro
<bryceh> cnd, just kidding (although they did ask...)
<cnd> gah!
<cnd> if you can't tell, I'm a bit on edge...
<bryceh> <tease>
<cnd> been working the last 11 days straight
<cnd> and I've been bashing my head against the wall trying to figure out pointer grabs :)
<cnd> took me three days to figure it out
<cnd> there can't be many people in the world who understand it...
<RAOF> The few, and the proud.
<cnd> I'd venture a guess of only 3 now :)
<cnd> I can't say I'm very proud
<cnd> I'm very afraid
<bryceh> that kinda describes a lot on the XInput side of things
<cnd> afraid that any time there's a bug in xinput now, I'll have to handle it :)
<bryceh> yay!
<RAOF> I'm not sure that should be a fear so much as a certainty.
<cnd> :(
<cnd> ok, it's 9 PM here and I think things are headed in the right direction
<cnd> so I'm going to call it quits for the evening
<bryceh> night cnd
<cnd> bryceh, RAOF: btw, when would you say is drop dead date for getting stuff into ubuntu before feature freeze?
<cnd> I'm aiming to have things ready on monday, but just in case
<RAOF> Absolutely drop-dead?  Probably wednesday evening, my time.
<cnd> RAOF, ok, hopefully it doesn't come to that :)
<cnd> btw, I'll be dropping X MT support for trackpads...
<cnd> I just don't think the protocol makes sense for trackpads as it is
<cnd> so it'll sadly just be touchscreens that get all the gooey xi 2.1 stuff
<RAOF> If push comes to shove I can do another FF firedrill.
<cnd> RAOF, I don't think anyone wants that again :)
<bryceh> hmm, I probably should focus on wayland for a few days and get some stuff updated there before FF
<RAOF> Yeah, probably a winner.
<RAOF> Hm. I wonder if âdoesn't absolutely suck when plugging in monitorsâ would be regarded as a Unity feature :)
<bryceh> RAOF, the real question is do we have any recourse when it does?
<bryceh> I mean, aside from classic ;-)
<RAOF> Well, that would be a slam-dunk FFe I guess.
<RAOF> Does this work now that I'm no longer strnduping a random memory address?  Lets ask Science!
 * apw wonders if others have noticed as sudden change in brightness control, i think i am getting 3 brightness changes for each key press ... confirmed there is only on press in the input stream
<bryceh> RAOF, I'm going to call this mesa good.  I've run several gl-ish things and am satisfied it's not going to bugger children.  Any last minute regrets?
<apw> RAOF, does unity dump core for you if you plug a wide monitor into your intel kit?  if i end up with more than 2k width it just exits
<RAOF> bryceh: I haven't thought of any regrets yet :)
<bryceh> alrighty here we go
<RAOF> apw: I âhappilyâ get above 2k width (modulo the crazy positioning), but this is a GM45 which has a nice big texture limit.
<RAOF> Canonical should sponsor me a couple of nice big monitors so I can test other, non-laptop things :)
<apw> yeah i hear its a texture limit
<RAOF> compiz probably shouldn't dump core, but it also probably won't work.
<bryceh> it should refuse to start up in such a case
<RAOF> Unless dx feels like making compiz use RandR 1.4 where available.
<RAOF> At which point it actually *could* work, as long as no head is individually > any of the texture limits.
 * RAOF suspects RandR 1.4 support is *way* down the TODO.
<apw> so it sounds like there no plan to fix this?
<apw> that common platforms will be working, plug in a projector and blam
<RAOF> Does metacity kick in nicely?
<apw> nope you end up dead in the water with no window manager, well last i checked
<RAOF> If nothing else, that should be fixed.
<bryceh> [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu1 (Accepted)
 * apw sighs, one more thisn to test
<RAOF> Woot!  Now that I'm not trying to copy a random piece of memory as a file path this works :)
<apw> bryceh, more fun coming down the pipe?
<RAOF> Well, it will at least allow nvidia users to test unity :)
<apw> ohh that reminds me, i am seeing corruption on scroll in gnome-terminal, sort of foreground stippling over the text
<bryceh> alright that's enough unity for me
<apw> have been for some time, known?
<bryceh> apw, yep new mesa snapshot
<apw> heh fun fun fun
<bryceh> apw, funny you should ask, I just went through a bunch of terminal corruption bugs today
<apw> hopefully that -4 kernel will be accepted tommrrow, seems i missed the AAs today
<bryceh> crap, forgot to test that with unity
<bryceh> apw, anyway so far there are 3 different terminal corruption bugs we know about (all different)
<apw> i see it come and go on scroll up, and at times i have felt it was 'repeatable' such that a scroll down where available would reverse it
<apw> heh, then till some of those are gone i'll assume its known :)
<apw> is that a compiz issue or more mesa-ery
<bryceh> my guess would be you're having this one - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/717114
<ubot4> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete]
<bryceh> apw, at this point we don't know what's to blame.  I posted some questions to the bug to help narrow it down
<bryceh> apw, any thoughts or insights you can share might help (e.g. maybe you can help rule out the kernel as a suspect)
<apw> yeah see them
<bryceh> offhand I'm going to guess we have some mesa issues, and I'm curious if raof's new mesa I just uploaded will help
<apw> i'd say its improved, is less reproducible recently
<apw> i've been ignoring it, i'll try and get a feel for how often i really see it
<apw> and then try out the older kernel
<apw> bryceh, i assume you know what it looks like.  i have it right now in a wndow where scrolling down one shows it, one more and its ok again and reversing through the same 3 lines seems the same
<bryceh> apw, here's what I'm guessing - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710961/+attachment/1831040/+files/Still-Present.png
<ubot4> Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (dup-of: 717114)" [Undecided,Incomplete]
<ubot4> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete]
<apw> looking closly at it, the 'dammage' is actually a ghost of what was on that line before the scroll, about half the lines vertically have not been cleared
<bryceh> apw, is this with compiz or without?  (Classic Desktop w/out effects?)
<apw> its more pronnounced than that, but the same range, exactly two lines of fookage each time it occurs
<apw> this is with unity, compiz
<apw> the example there is also exactly two lines of text which are bust
<RAOF> Hm.  That looks a bit like the damage bug that got fixed in -1ubuntu6.
<bryceh> alright lemme restart into unity and try reproducing it myself
<apw> RAOF, i updated earlier today, whats that version of so i can check
<RAOF> xserver-xorg-video-intel; it's quite old, though, so you almost certainly already have it.
<apw> 2:2.14.0-1ubuntu9
<apw> bryceh, i find that its normally most obvious in a long less
<apw> i also note its pretty much output specific
<apw> ie if you see it on a couple of lines of a less output, it willl  be there again if you scroll
<apw> a few pages away and back to the same point
<RAOF> That's a bit strange.  I don't think there's anything Xy that should do that sort of caching except for the glyph cache.
<RAOF> And that doesn't look like glyph cache corruption.
<bryceh> hmm, not seeing anything weird with xterm+less+kern.log or gnome-terminal+less+kern.log
<bryceh> well, with xterm I notice the border seems messed up
<bryceh> ah not messed up, just transparent.  Weird.
<bryceh> compiz shadow is really irritating
<apw> RAOF, ok this corruption is definatly in the window, it can be covered and exposed and its still in there
<bryceh> apw do you see it *only* with terminals or does it show up in any other client apps?
<bryceh> e.g. scrolling slashdot.org in firefox
<apw> i have never notices any corruption of anything else no
<apw> not for launchpad pages for instance which i use almost as much
<RAOF> Hm.  (a) why is the crda regulatory daemon setting my zone to FR, (b) my, aufs is generating a lot of dmesg backtraces.
<bryceh> hmm, unity is significantly more tolerable with gnome-panel manually launched
<RAOF> xterm doesn't seem to be having any troubles here.
<bryceh> yeah no corruption for me either
<bryceh> apw, what video driver, -intel?
<apw> http://people.canonical.com/~apw/misc/corruption.png
<apw> intel yes
<apw> this is a N450 netbook
<bryceh> oh you know what, I override the default terminal theme stuff
<RAOF> That looks like it's reasonably easy to generate?
<RAOF> N450 means... i945?
<apw> note that the shadowing is clearly text which is not on the window, but has been visible recently
<apw> 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
<RAOF> The shadowing?  You mean, the interleaved text?  That looks like it's from quite nearby in the buffer.
<RAOF> apw: grep "intel(0): Chipset:" /var/log/Xorg.0.log?
<apw> yeah its from nearby but not the page above or below
<apw> [    13.397] (--) intel(0): Chipset: "Pineview GM"
<bryceh> yeah even with default theme, not reproducing on -ati / rv770
<RAOF> Not reproducing on GM45
<bryceh> although this is with the new mesa and your -rc4 kernel
<RAOF> Ok. g33
<RAOF> Ah, that's why unity hates big screens, too.
<RAOF> (For you).
<apw> yeah a very very common platform, we need to replace all those macs in design with soemthing normal people have
<apw> so they get some pain from these kinds of bugs
<bryceh> mm, this is new:
<bryceh> [  685.163321] [drm:subconnector_show] *ERROR* Unable to find subconnector property
<bryceh> [  685.163349] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property
<bryceh> [  685.222891] [drm:subconnector_show] *ERROR* Unable to find subconnector property
<bryceh> [  685.222917] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property
 * RAOF wonders idly how hard it would be to port compiz to RandR1.4 to stop apw bitching :)
<RAOF> Hm.  If I reboot my irc bouncer and flip the bios switch I can also have access to an i915-driven GPU.
<apw> RAOF, my plan is to offer my laptop to our leader for a presentation and see how long it takes to get fixed after it explodes
<RAOF> :)
<apw> bryceh, well none of the code which produces that error is new ... so hrm
<Sarvatt> apw: does it go away if you move the mouse to the top left of the screen? :)
<apw> Sarvatt, which ?
<ScottK> apw: Bigger question is would you still be around to find out?
<Sarvatt> apw: the corruption, sorry
<apw> ScottK, heh indeed
<apw> Sarvatt, heh no, i get a nice unity launcher pop over it, but no change in the corruption
<Sarvatt> also curious if it happens on .37
<Sarvatt> ah alrighty, saw one case of a corruption problem with a fix just posted on the intel-gfx list but they said it went away when the mouse was in the top left
<apw> now that is somewhat odd fix is it not?
<apw> yeah .37 is my next test
<Sarvatt> nah they fixed it properly, that was just a symptom the guy had
<Sarvatt> http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2949
<Sarvatt> 2.6.38 is proving to be all kinds of "fun" on intel
<bryceh> tell me about it
<apw> ok back ... on .37 ... the triple brightness issue is still here so i can ignore that as a kernel issue
<apw> its hard to prove a negative, but i've done more wibbling to reproduce it, i managed to reproduce it 3-4 times in the same period on .38, nothing so far on .37
<bryceh> mm interesting
<RAOF> Oh, hurrah.
<bryceh> apw, btw while we have your attention... any updates on the -intel/vesafb conflicts (bug #702090)?  the bugs keep rolling in daily on that one
<ubot4> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 36) (dups: 25) (heat: 287)" [High,Triaged] https://launchpad.net/bugs/702090
<apw> bryceh, not had a chance to fiddle with the ordering there
<apw> mr watson and i were meant to get together to discuss it this week and its nto yet happened hrm
<Sarvatt> apw: if 2.6.38-rc1 works too you might want to try https://patchwork.kernel.org/patch/571511/ and https://patchwork.kernel.org/patch/572241/
<apw> how the heck does it work without those !
<Sarvatt> <3 2.6.38 so far
<Sarvatt> broadcom fail in it invalidated 3 days of hibernate testing here, i'm grumpy :)
<apw> broadcom is always fail
<Sarvatt> apw: those commits are in drm-intel-next too, not sure when you guys build those? could just check in the morning
<apw> we rebuild at 10am utc i think it is
<apw> ahh awsome that 'skip FDI & PCH enabling for DP_A' fix looks to be on the intel fixes branch, so i assume destined for .38
<bryceh> ok EOD'ing
<bryceh> apw, btw looks like your kernel solved my nfsv4 woes, thanks
<apw> yay for new kernels
<RAOF> Yay!  I can now actually interact with the grub menu on my radeon system now!
<RAOF> Oh, bother.  My evergreen card doesn't have *any* acceleration without KMS, so I can't test the ums fallback.
<RAOF> Whoops.  Moderately easy to crash firefox with WebGL
<RAOF> How big a NOT E6510 do you need to have in the bug title before users with E6510 hardware stop posting on it? :)
<bryceh> strange, my gnome-terminal sessions all froze up and my music started repeating the same broken lyrics over and over in a loop
<bryceh> oh wait, I'm listening to techno, it's supposed to sound like that
<bryceh> RAOF, I tried on my i945 dell mini...
<bryceh> RAOF, gnome-terminal doesn't show the corruption
<bryceh> RAOF, weirdly, I launched xterm and got a >frozen< xterm window.  No cursor, completely unresponsive.
<hyperair> hi. does anyone know about ubuntu's x with intel chipsets not sending out XRRNotifyEvents to clients?
<hyperair> it seems to work with xorg-edgers, but not with the stock X in maverick
<RAOF> bryceh: I'll have the switch-to-gallium stuff ready an hour or so after making, then eating dinner.
<bryceh> hyperair, first I've heard of it, but I don't really deal with maverick bugs
<bryceh> RAOF, sounds good; ping me when it's ready
<hyperair> bryceh: hmm strange. basically i plug in a monitor into the VGA port, and only after manually polling the hardwrae with XRRGetScreenResources does the event come in
<hyperair> bryceh: but that X call causes X11 to hang momentarily
<lilstevie> I have X dying and respawning, is there a way of getting more detailed logs from what is killing it as Xorg.0.log has nothing about errors
<bryceh> lilstevie, I'd look in /var/log/gdm for errors
<bryceh> also Xorg.0.log.old
<lilstevie> unfortunantly doesnt give me any errors
<bryceh> lilstevie, ok then start X up in gdb run it to a crash and then gather a full backtrace
<lilstevie> k
<bryceh> actually probably easier to start X and then attach gdb to it (pidof X to get X's pid, then run gdb /usr/bin/Xorg, and then attach <pid>)
<bryceh> see http://wiki.ubuntu.com/X/Backtracing for more tips
<lilstevie> X on its own doesnt crash
<lilstevie> just doesnt work
<bryceh> hyperair, well the automatic XRR kernel events stuff is fairly new, it may just be a missing feature from maverick
<hyperair> bryceh: ah, so it's a kernel events thing? is this a new feature in the kernel, or in X, or somewhere else?
<bryceh> lilstevie, I don't know what you mean by "doesn't work"
<bryceh> hyperair, yeah
<bryceh> hyperair, new kernel drm feature
<lilstevie> bryceh: the screen backlight flashes on then off again
<hyperair> okay, that narrows down my search a bit, thanks =)
<lilstevie> http://pastie.org/1577791 <- this is Xorg.0.log.old
<bryceh> hyperair, I'm not sure if the kernel bubbles the event up to X and then that passes it to clients, or if clients listen directly for kernel events
<hyperair> bryceh: no, the clients get it via some XRR stuff
<bryceh> hyperair, if X passes things along it's conceivable the X we shipped in maverick simply lacked the feature, but I wasn't paying attention to X during maverick so raof would be the one to ask
<hyperair> okay thanks.
<hyperair> RAOF: ^^ =D
<RAOF> hyperair: It requires kernel events (which *were* in Maverick) to be picked up by the DDX and forwarded to X; I'm not sure if the latter was in Maverick.
<bryceh> lilstevie, oh you're not running natty?
<lilstevie> bryceh: no maverik
<lilstevie> maverick
<bryceh> lilstevie, dunno then, you might have something misconfigured, hard to say
<lilstevie> trying to port to a new device
<lilstevie> but struggling to figure out what is broken
<bryceh> you're right though that it's not crashing, just exiting.  the log seems to be complaining about input device stuff
<lilstevie> hm
<bryceh> hard to make any guesses without more info, you could try http://askubuntu.com
<hyperair> RAOF: oh so kernel events were in maverick, i.e. kernel <= 2.6.35?
<hyperair> RAOF: what's DDX?
<lilstevie> the nexus S has the same SoIC and that seems to work with x
<bryceh> DDX is the X driver
<bryceh> so that would be like xserver-xorg-video-intel as opposed to the intel driver inside the kernel 
<bryceh> hyperair, https://wiki.ubuntu.com/X/Glossary
<hyperair> bryceh: thanks
<hyperair> RAOF: i'm trying to look in the kernel git log for the introduction of this whole hotplug kernel events thing so i can figure out how new a kernel i need.
<bryceh> wow http://www.semiaccurate.com/2011/02/15/atom-dead-strangled-slowly-intel/
<bryceh> harsh!
<bryceh> "The other major problem facing Atom is software, especially drivers. Intel has a track record in making graphics drivers that are simply unmatched in the world of chipmaking. I can honestly say that I can not think of a single company that has made drivers as badly as Intel for as long, even if you take the awful hardware into account. Even a blind dog occasionally finds a bone, unless they work for Intel making graphics driv
<bryceh> ers."
<lilstevie> lol
<lilstevie> but true
<RAOF> hyperair: Hm.  I may have had it backwards; the DDX component may have been there but the kernel component not :)
<hyperair> RAOF: nah, i just tried upgrading to xorg-edgers on this computer and it suddenly started workgin
<bryceh> Sarvatt, ^^ you'll find that link an interesting read I think
<RAOF> Dear lord, mesa.  Do you *really* need to take that long to build?
<jcristau> maybe we should get rid of some (all?) of the osmesa packages
<RAOF> Or at least build only one.
<RAOF> I'm sure the user of the 16bit renderer will be *devastated*
<RAOF> Of course, it doesn't help that I'm doing an i386 and amd64 build in parallel.
<tjaalton> heh
<tjaalton> what are those osmesa-stuff for, anyway?
<RAOF> It's an offscreen software rasteriser, from what I gather.
<RAOF> As for what anyone *uses* that forâ¦ well, mesa-dev@ attests to there being at least one dev who notices when it breaks.
<tjaalton> heh, ok
<RAOF> bryceh, tjaalton: Radeon gallium transition stuff is in http://cooperteam.net/Packages ; build order is mesa -> xserver with -ati going whenever.
<RAOF> Note: Due to mesa taking forever to build I haven't actually tested building the xserver against that mesa in a clean chroot.
<tjaalton> RAOF: ok, so mesa is good to upload?
<tjaalton> and xserver too, since the build-dep is bumped
<RAOF> It should be good to upload.
<tjaalton> yeah they all are
<RAOF> But it's not thoroughly tested here.
<tjaalton> bah, it's the weekend anyway :)
<tjaalton> soon
<RAOF> In some places sooner than others :)
<tjaalton> right, so Sarvatt and bryceh can fix the pieces that are left behind :)
<RAOF> I'll throw the binaries up on cooperteam, too; save you some bulid time.
<tjaalton> ok, thanks
<tjaalton> I'm trying to make some sense to this "xinput1 broken" -bug..
<tjaalton> but, after the break->
<RAOF> Now with bonus binaries.
<RAOF> And with that, bed.
<tjaalton> ok, lets try mesa then (don't have radeon)
<tjaalton> wat, there's no menu in mumble anymore?
<tjaalton> +h
<tjaalton> duh
<seb128> bryceh, there?
<seb128> bryceh, let me know if you are around, I want to discuss about the retracers
<seb128> I stopped those to investigate that xorg retracing issue but I would need an xorg crash to be submitted to be able to do that
<cnd> bryceh, I did a ppa-purge of xorg-edgers (which I should have done a while ago...)
<cnd> but now my keyboard doesn't work anymore..
<cnd> any ideas?
<tjaalton> do you have evdev installed?
<cnd> I've debugged in the server, and I know that key events are getting generated
<tjaalton> ok
<cnd> tjaalton, yes, still installed
<cnd> but they seem to get filtered out?
<cnd> in _XkbFilterXF86Private
<cnd> I don't know anything about how keyboard events work...
<cnd> I'm just wondering if there's some magical change to stuff in xorg-edgers
<jcristau> nobody does, it's all black magic
<tjaalton> xorg-edgers doesn't have much, maybe the ppa-purge removed something vital
<tjaalton> well, there's stuff but still
<tjaalton> but filtering sounds odd
<tjaalton> though it sounds what's happening with mumble (XI1 app)
<tjaalton> +like
<cnd> yeah, but this isn't even generating core events...
<tjaalton> hm
<cnd> I'm going to try to purge my xorg-unstable ppa
<cnd> then reinstall it
<cnd> hmm, still no luck
<cnd> I'm going to apt-get dist-upgrade and reboot
<tjaalton> oh you aren't on current natty?
<cnd> I am
<tjaalton> k
<cnd> but I haven't updated in a few days
<tjaalton> yeah that shouldn't make a difference..
<cnd> I know
<cnd> but I figure if I'm screwing up the machine
<cnd> I might as well go all the way :)
<tjaalton> right :)
<cnd> grr... still nothing
<tjaalton> cnd: you've seen the mumble bug? shouldn't XI1 apps continue working just as before with XI2, or do they need to be ported over?
<cnd> tjaalton, I have seen it, haven't had time to investigate
<cnd> they should continue to work as normal
<cnd> so it's a bug
<tjaalton> yeah
<tjaalton> best to file it upstream then and discuss it there
<cnd> tjaalton: I wonder if it has to do with input methods
<cnd> do you know anything about them?
<tjaalton> XIM? not really
<tjaalton> GlobalShortcutX: Using XInput 2.0
<tjaalton> yet the app is for XI1
<tjaalton> ah that's not from the app
<cnd> btw, I don't think it's XIM
<cnd> this all seemed to start when I downgraded from libx11-1.3.4 in xorg-edgers to 1.3.3 in natty
<cnd> and there's some xkb stuff in libx11
<cnd> so I'm going to try to upgrade back to it
<cnd> hmmm... there's no libx11 there anymore...
<cnd> I may be screwed :)
<tjaalton> you have some self-compiled stuff for multitouch?
<tjaalton> eh, so we have an ancient libX11
<tjaalton> wonder if 1.4.1 could fix mumble
<cnd> I do have stuff for multitouch
<jcristau> *cough* klongon crap *cough*
<jcristau> klingon, even
<cnd> I'm all confused...
<tjaalton> jcristau: haha
<cnd> I just want my keyboard to work!
<tjaalton> cnd: dunno if there's some ABI break doing what you see
<cnd> tjaalton, it doesn't work on stock natty packages
<cnd> I've ppa-purged everything
<cnd> I think some xkb file has been screwed up
<cnd> some setting somewhere
<tjaalton> what packages does it touch?
<cnd> trust me, I've downgraded them all again :)
<tjaalton> crap, forgot about RAOF's mesa/xserver/ati
<tjaalton> cnd: I know, but if your multitouch'y packages need something to be rebuilt
<jcristau> tjaalton: friday, 8pm, what could possibly go wrong.
<jcristau> or is it 9 over there
<tjaalton> jcristau: right. I'll get another beer
<jcristau> :)
<tjaalton> (not working anymore btw)
<jcristau> cheers
<tjaalton> bryceh: do you want to take over mesa/xserver/ati from RAOF? I can test them, but if something breaks after uploading them I'd be either in bed or..
<tjaalton> yeah 21:04 here
<tjaalton> oops :05
<bryceh> tjaalton, sure
<tjaalton> bryceh: got the link?
<tjaalton> bryceh: http://cooperteam.net/Packages
<bryceh> oh cool, debs too
<tjaalton> yeah
<cnd> tjaalton: GAH! it was libx11-1.3.4
<tjaalton> cnd: :)
<cnd> so, downgrading from libx11-1.3.4 breaks your keyboard!
<tjaalton> good, I'll merge 1.4.1 to see if it helps with mumble
<cnd> I'd like 2 hours of my life back now :)
<tjaalton> hehe
<tjaalton> hmm, libxi 1.4.1 available
<tjaalton> we have 1.4.0
<tjaalton> nothing too special there
<bryceh> cnd, that's weird
<tjaalton> but I'll sync the packages that don't have any diff
<tjaalton> couple of libs
<bryceh> abi change between previous and libx11-1.3.4?
<bryceh> tjaalton, yeah probably a bunch that could be sync'd http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
<tjaalton> yeah looking at that now (been a looong time..)
<bryceh> there's also drivers that I think the only changes are the rebuilds after the last abi bumpery
<tjaalton> ooh and new xbacklight and xbitmaps
<jcristau> tjaalton: exciting, right? :)
<tjaalton> super-
<cnd> bryceh, it can't really be abi
<cnd> because I had downgraded everything
<cnd> drivers and server
<cnd> but I don't have any alternative explanation either...
<bryceh> could something have statically linked against it?
<tjaalton> you've built something against libx11 1.3.4
<cnd> tjaalton, no, I was running stock ubuntu packages
<cnd> I had gotten rid of all my stuff
<tjaalton> ok
<Sarvatt> cnd: libx11 1.3.4 isn't even in xorg-edgers natty?
<cnd> Sarvatt, it must have been at one point
<tjaalton> confirmed that focus-follows-mouse doesn't dig on unity..
<cnd> and it's still there in the maverick and lucid series I believe
<Sarvatt> nope can guarantee it hasn't been
<tjaalton> or the menubar
<Sarvatt> sounds like ya didnt purge edgers before going maverick -> natty?
<cnd> Sarvatt, perhaps?
<Sarvatt> gotta be it
<Sarvatt> to fix that i add xorg-edgers maverick to sources, apt-get update then purge the ppa before upgrading so it knows all the crap in the old release to remove, kind of a pain in the butt :(
<cnd> yeah
<Sarvatt> thats.. odd
<Sarvatt> the libx11 checkout in there was back from when 1.3.x was master
<Sarvatt> and it has the XKeysymDB removal in it even though its 1.3.4
<Sarvatt> but they didn't remove xkeysymdb until 1.3.6 on the 1.3 branch
<bryceh> ok reboot onto new -ati first
<tjaalton> damh
<tjaalton> damN
<tjaalton> forgot to tell bryce about the build order
<bryceh> so far so good
<tjaalton> quick reboot?
<Sarvatt> sandybridge system? :)
<tjaalton> bryceh: RAOF said something about the build order, but you're installing the binaries so it doesn't matter really
<tjaalton> the xserver does depend on the new mesa though
<bryceh> -ati I rebuilt while other stuff was downloading; assumed that bit was safe to do independently, but maybe not?
<tjaalton> yeah it should be independent
<bryceh> ok the other stuff I'll just load the .debs then
<bryceh> think there's an upload dependency?  Do I need to put mesa in and wait for it before sticking xserver in, or vice versa?
<tjaalton> no the xserver build-deps on the new mesa, so it'll wait until mesa is ready
<bryceh> hrm, wish you could just dpkg -i *.deb with mesa
<tjaalton> hehe
<tjaalton> there are only a few you need
<bryceh> yeah
<bryceh> dpkg -i libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb 
<bryceh> did I miss anything?  that should be enough
<bryceh> actually it looks like I could do everything except libgl1-mesa-swx11  - isn't that the only package that'd screw me up?
<tjaalton> that can be installed as well
<jcristau> that conflicts with -glx iirc
<bryceh> libgl1-mesa-dri-experimental might be "fun" but it shouldn't cause conflicts for installation
<jcristau> both provide libGL.so.1
<tjaalton> oh
<tjaalton> right I was looking at apt-cache search output, duh
<bryceh> heck, I'm gonna give a try to install everything but that
<bryceh> unhappy
<bryceh> oh duh, gotta exclude amd64 pkgs
<tjaalton> heh
<bryceh> there we go
<bryceh> yeah, just rm *swx11*deb ; dpkg -i *.deb
<bryceh> reboot time
<bryceh> metacity fine
<bryceh> unity still crazy, but no crazier
<bryceh> aaaa too crazy for me tho, brb
<bryceh> aha, most of this craziness is compiz
<tjaalton> hum, I wonder where the syncs went
<tjaalton> oh, nowhere
<Sarvatt> sync freeze was in december, i've done like 40 since then
<tjaalton> i thought syncpackage would've uploaded them too, but it just signed them
<tjaalton> probably because i didn't specify the release
<Sarvatt> oh they might have removed that ability, i think archive admins want to do the syncs?
<tjaalton> they can't prevent me from uploading packages signed by me :)
<tjaalton> hm
<tjaalton> of course they can
<tjaalton> by revoking my upload rights :)
<Sarvatt> not sure, the guy who used to upload them when I file just acks my sync requests instead of uploading them now so figured there was a policy change along the way
<tjaalton> it could recognize packages without ubuntuN in the version
<bryceh> ok, -ati, xserver, mesa all tested and uploaded
<bryceh> [   175.611] (II) RADEON(0): [DRI2]   DRI driver: r600
<bryceh> [   175.618] (II) AIGLX: Loaded and initialized /usr/lib/dri/r600_dri.so
<bryceh> hm, shouldn't that be r600g?
<bryceh> nope
<bryceh> wonder how I tell whether I'm running g?
<tjaalton> glxinfo should tell
<bryceh> OpenGL renderer string: Gallium 0.4 on AMD RV770
<bryceh> bingo, thanks
<Sarvatt> r600g default now?
<bryceh> hum, I just pulled glxinfo out of the apport hook yesterday... but it occurs to me that maybe useful info for debuggery
<bryceh> Sarvatt, yep once the buildds are done
<bryceh>  389 N + Feb 18 Ubuntu Installe ( 105) [ubuntu/natty] xserver-xorg-video-ati 1:6.14.0-0ubuntu1 (Accepted)
<bryceh>  390 N + Feb 18 Ubuntu Installe ( 148) [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu2 (Accepted)
<bryceh>  391 N + Feb 18 Ubuntu Installe ( 119) [ubuntu/natty] xorg-server 2:1.9.99.901+git20110131.be3be758-0ubuntu6 (Accepted)
<tjaalton> mesa-utils isn't installed by default though
<tjaalton> and in universe
<tjaalton> because of that
<bryceh> tjaalton, yeah that's why I took it out of the apport hook
<bryceh> was causing the hook to error when glxinfo wasn't installed
<Sarvatt> mesa-utils-extra? what the heck
<Sarvatt> someone add more stuff to it and forget it's in debian now? :D
<tjaalton> Sarvatt: syncs uploaded and accepted
<Sarvatt> tjaalton: \o/ what'd ya get? libxcb?
<tjaalton> that too
<tjaalton> libxi, libxaw, libxext, libxcb, libxfont, xbacklight, xbitmaps
<tjaalton> merged libx11, building it now
<tjaalton> but won't upload it until monday
<Sarvatt> tjaalton: I missed you man :)
<tjaalton> hehe
<tjaalton> I've missed these tools
<Sarvatt> i had a bug for libxext but it was rejected, forgot to look into it
<Sarvatt> think it was header removal, lets see
<tjaalton> there was some changes yes.. could that break something?
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/libxext/+bug/705010
<ubot4> Launchpad bug 705010 in libxext (Ubuntu) "Sync libxext 2:1.2.0-1 (main) from Debian experimental (main) (affects: 1) (heat: 118)" [Wishlist,Incomplete]
<Sarvatt> nothing we care about or ship
<tjaalton> hah, sorry daniel..
<tjaalton> "overruled"
<Sarvatt> lbxproxy
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/102018
<tjaalton> yeah moved to liblbxutil
<ubot4> Launchpad bug 102018 in x11-xserver-utils (Ubuntu) "[needs-packaging] lbxproxy (affects: 3) (heat: 17)" [Wishlist,Triaged]
<tjaalton> bryceh: I've installed mesa here and will reboot in a minute
<tjaalton> the new one
<bryceh> ok
<tjaalton> works
<tjaalton> libx11 update didn't fix mumble
<Amaranth> anyone seeing excessive wakeups on intel when running compiz?
<Amaranth> it used to be 60 wakeups a second if you enabled vsync in compiz but now it's about that either way
<Sarvatt> Amaranth: got second hands visible on your clock?
<Sarvatt> was reading something about having the clock show seconds kept interrupts enabled all the time with compiz
<Amaranth> Sarvatt: I don't even have a panel right now :)
<Amaranth> I've got xchat-gnome and gnome-terminal as far as things drawing to the screen
<bryceh> heya seb128
<bryceh> seb128, you had questions about the retracer?
<seb128> hey bryceh
<seb128> bryceh, not really questions
<seb128> rather I need some xorg crash reported and not retraced to run a retracing and see what is the issue
<bryceh> seb128, ok, I'll keep an eye out for one
<seb128> but it's getting late for this week now so let's see next week rather
<bryceh> seb128, sounds good
<Amaranth> Sarvatt: actually vsync on or off in compiz I get 57.2 wakeups
<seb128> bryceh, thanks
<Sarvatt> Amaranth: terminal cursor blink?
<Amaranth> Sarvatt: It's blinking, yeah
<bryceh> Sarvatt, ooh that'd be evil
<Sarvatt> that did it years ago so i've always disabled it (they mention turning it off on their lesswatts page) :D
<Amaranth> I just noticed it's on, could have sworn it was disabled by default
<Sarvatt> Amaranth: i'm not sure though, let me see if i can dig up the discussion on the intel-gfx list because I think it had some debugging tips for it
<Amaranth> Sarvatt: nope, wasn't the cursor blink :/
<Amaranth> wow, actually it does it when running metacity too
<bryceh> Sarvatt, hey I was just looking at bug #626967
<ubot4> Launchpad bug 626967 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "MASTER: Hang in MI_WAIT_FOR_EVENT on framebuffer switch. (affects: 30) (dups: 42) (heat: 184)" [Medium,Fix released] https://launchpad.net/bugs/626967
<bryceh> Sarvatt, looks like that is believed fixed for natty, but looks like the patch wasn't sru'd to maverick.  Do you think it'd make sense to do so?
<bryceh> or is it too ambiguous what the fix was?
<bryceh> bbiab
#ubuntu-x 2011-02-19
<bryceh> Sarvatt, anyway I'll assume it's not sru worthy, but poke me if it is
<LLStarks> shocker of the night. 
<LLStarks> xrender broken on fresh maverick
<LLStarks> for intel
<bryceh> oho
<bryceh> so not a regression eh?
<LLStarks> i can check lucid
<LLStarks> but i was not expecting maverick to be lacking xrender.
<bryceh> have you ruled out simple test breakage?
<LLStarks> doubtfull. jrendermark and xrender-reliant games were also affected
<LLStarks> btw, screen corruption test on .37 is coming up in a little bit. i'd also like to remark that the classic panel dropdown is a reliable trigger of the symptoms. anything fast moving seems to do so.
<RAOF> Lacking xrender, or broken rendering?
<LLStarks> err:xrender:get_xrender_format_from_color_shifts No XRender format found!
<LLStarks> i don't know what specific files or libraries make up xrender
<LLStarks> so i can't account for its presence or lack thereof
<RAOF> Sounds like a server - or client - problem; xrender isn't driver dependent (although acceleration is)
<bryceh> this is sounding like something which maybe best brought up on xorg-devel@
<bryceh> I was thinking we could forward the bug report up to upstream bugzilla
<bryceh> however I'll bet it needs wider eyes than that
<bryceh> LLStarks, would you be willing to post it to xorg-devel@ for feedback?
<LLStarks> the list? sure.
<RAOF> Although checking whether it works on Natty first would be a good idea.
<bryceh> RAOF, he did that already
<bryceh> (I think he was checking maverick because I asked if it was a regression)
<LLStarks> lucid test is coming up.
<RAOF> Ah, fair enough.
<LLStarks> though i'm fairly certain that i remember my games suddenly breaking during the maverick cycle
<bryceh> RAOF, btw check it - our graph is looking quite good here at the end of the week - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<LLStarks> was maverick that bad? jeez.
<LLStarks> *that troublesome
<bryceh> (it'll notch down even lower once it regens, I just finished rapping down another 8-10 bugs)
<RAOF> Sweet!
<LLStarks> brb
<bryceh> LLStarks, well, in maverick's defense some of the -intel freezes were out of control and apport wasn't working well enough to properly diagnose them
<bryceh> so I think there are lots of dupes in the maverick stats which we've been better at culling out this release
<RAOF> Also, there have been two people X'ing this cycle.  And one of them has been bryceh, master of Launchpad.
<bryceh> however I think as a result we've been able to hone in on the bugs that *do* exist and hopefully can do good at excising them
<bryceh> RAOF, agreed, two heads definitely better than one
<bryceh> fwiw, the lucid graph looks about the same as the maverick one.  Manpower makes a big difference.
<bryceh> RAOF, btw I had them shut off the retracer.
<bryceh> it was just posting back corrupted backtraces
<bryceh> at least this way there'll be the core file still attached so we can manually extract our own backtraces
<bryceh> oh btw, remember the out-of-memory bug I was mentioning the other day
<bryceh> I *think* it may be particular to USB livecd boots
<bryceh> e.g. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/720235
<ubot4> Launchpad bug 720235 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in BlockHandler() (LiveCD environment, image from 20110216) (affects: 1) (dups: 1) (heat: 18)" [Medium,New]
<RAOF> Interesting.  I wonder what's deffirent.
<bryceh> something peculiar about the usb persistent image installation results in running out of memory
<bryceh> yeah dunno, but suggests maybe we could reproduce it by creating usb installs in various ways
<bryceh> however I'm EOW'd and hoping next week to focus on wayland a bit
<RAOF> Yeah.
<RAOF> I'll have xserver RC2 + multitouch to do for the start of next week.
<RAOF> Oh, how did mesa/ati/xserver go?  I haven't checked if they're uploaded yet.
<bryceh> yep, uploaded them several hours ago
<bryceh> I booted unity and metacity with them and seemed no worse than before
<bryceh> I still get that weird initial paint wrongness with compiz, but had that before
<RAOF> And alt-tab works now? :)
<bryceh> mesa might be through the buildd's
<bryceh> oh heck, forgot to test that
<RAOF> Well, it works *here*
<RAOF> So I'm confident it's going to work elsewhere.
<RAOF> Now, let's see if Civ V works on it!
<bryceh> what was the ultimate fix?  did my patch do it?
<bryceh> ironically as annoying as I found that, I never tested my own patch.  whoops
<RAOF> Oh, the fix was âthat bug doesn't apply to the gallium driverâ
<bryceh> alright on the o-o-m bug I left a note for the reporter about what I'd like to see tested; he sounded willing maybe he can do the leg work on it
<bryceh> oh that's right, heh
<soreau> Hello, I'm having a problem with recent updates on r300 card. First I get colored artifacts for xv video and now I cannot vnc into my box without it segfaulting X http://sprunge.us/gBIc
<soreau> Sarvatt: I installed -dbg packages for xserver, -ati and -radeon but there seems to be no symbols still
<ricotz> soreau, you would also need the drm dbg and mesa dbg packages
<elderman> Hello, xsession errors prevented me from logging into a user account on my laptop.  I tracked the problem down to two functions written to my bash profile by ssh-agent.  Is this the right place to look for help?
<elderman> I've already tried #ubuntu and the ubuntu forums
<soreau> I'm having a problem with recent updates on r300 card. First I get colored artifacts for xv video and now I cannot vnc into my box without it segfaulting X http://sprunge.us/gBIc I installed -dbg packages for X, ddx, mesa and libdrm-radoen but it seems there are no symbols
<soreau> gdb gives messages such as:
<soreau> #0  0xb7630fb6 in ?? ()
<soreau> No symbol table info available.
<soreau> Can anyone tell me why -dbg packages do not contain debugging symbols?
#ubuntu-x 2011-02-20
<alex-mayorga> ERROR: hook /usr/share/apport/package-hooks//source_xserver-xorg-video-nouveau.py crashed
<alex-mayorga> what's this?
<alex-mayorga> bryceh: ping
<Turl> hello
<Turl> can somebody take a look at https://bugs.launchpad.net/ubuntu/+source/libva/+bug/595661 ?
<ubot4> Launchpad bug 595661 in mplayer (Ubuntu) (and 3 other projects) "please support h264 hardware acceleration on certain intel video cards (affects: 9) (heat: 46)" [Undecided,Confirmed]
<Turl> it would be great to have that in natty
<Turl> I just installed the libva packages from debian and it enabled h264 decoding on my card
<Turl> so syncing them from debian would be nice
<Turl> the one on ubuntu currently just has mpeg2 decoding
<tjaalton> Turl: bug 721978
<ubot4> Launchpad bug 721978 in libva (Ubuntu) "Sync libva 1.0.8-3 (main) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/721978
<tjaalton> already acked
<Turl> nice
<alex_mayorga> bryceh: ping
<alex_mayorga> I've managed to obtain the requested peek for bug 696104
<ubot4> Launchpad bug 696104 in xserver-xorg-video-nouveau (Ubuntu) (and 1 other project) "nvidia 320m locks up (affects: 1) (dups: 1) (heat: 14)" [Undecided,Incomplete] https://launchpad.net/bugs/696104
<tjaalton> alex_mayorga: no need to add new data to that bug
<alex_mayorga> tjaalton: is the peek useful?
<tjaalton> for upstream perhaps
<tjaalton> but it's a dupe
<tjaalton> they have no idea what's causing it
<tjaalton> and it's an old bug
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=26980
<ubot4> Freedesktop bug 26980 in Driver/nouveau "NVA3 / NVA5 / NVA8 / NVAF (GT2xx/GT3xx) with nouveau: random GPU lockups" [Normal,New]
<alex_mayorga> tjaalton: should I attach my peek there?
<tjaalton> maybe
<tjaalton> and mark your upstream bug as dupe of the above
<tjaalton> if you can
<tjaalton> well i did that
<raevol> so am i understanding correctly, that x-swat provides newer, btu some what stable driver releases for ubuntu?
<tjaalton> they are not actively maintained, aiui
<raevol> aiui?
<tjaalton> as i understand it
<raevol> ah ok
<raevol> hmm i just added the ppa and it provides no updates for me :/
<raevol> strance
<raevol> strange even
<RAOF> For what release?
<raevol> maverick
<bjsnider> raevol, x-updates?
<bjsnider> what graphics card?
<raevol> ati 4670
<raevol> i added this ppa: ppa:ubuntu-x-swat/x-updates
<bjsnider> raevol, did you expect a particular driver, or version? it would just be the latest stable fglrx
<raevol> i was hoping for a more recent version of the oss driver
#ubuntu-x 2012-02-13
<bjsnider> Sarvatt, is gstreamer-vaapi mature in any sense?
<bjsnider> last i looked at it there were some issues
<bjsnider> but that was awhile ago
<tjaalton> RAOF: it's in the NEW queue, hint hint :)
<tjaalton> (along with a bunch of other packages I've pushed..)
 * RAOF is not an archive admin
<tjaalton> oh
<RAOF> I just play one on TV :)
<tjaalton> I thought you were
<RAOF> I have the powers, for SRU work.
<tjaalton> ok
<RAOF> Because Launchpad's permissions scheme is not sufficiently fine-grained.
<tjaalton> i don't know what's wrong with the -vaapi packaging, but it fails to build the glx backend on sbuild, pbuilder is fine.. check for '-lGL' fails for some reason
<tjaalton> had already spent a day on it so meh..
 * RAOF might have a look, given that's likely to break on the buildds.
<tjaalton> yeah you can grab it from the queue I guess
<tjaalton> or git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git
<tjaalton> bf ->
<RAOF> apitrace should be nearly ready, too.
<ricotz> RAOF, hi, do you think colord can be synced?
<RAOF> ricotz: Yes, colord can be syncd
<RAOF> Well, modulo a test-build.
<ricotz> RAOF, good, i built and running it, but probably not actually using it
 * ricotz was hoping to solve a g-s-d problem with it
<RAOF> Ah.
<RAOF> I am planning to sync it; I just felt that a little bit of time marinating in Debian wouldn't hurt it.
<RAOF> It's pretty well seasoned now, though :)
<ricotz> yeah that's right, but avoiding a FFe is easier
<seb128> ricotz, hey
<seb128> ricotz, do you know what is wrong between unity-greeter and new g-s-d?
<ricotz> seb128, hey, no, i havent bothered looking into it, sorry -- i am using gdm
<seb128> ricotz, no worry ... any news about gdm 3.2? ;-)
<ricotz> libcolor in g-s-d makes some trouble though
<seb128> I would still like to get that in precise if we can
<seb128> ricotz, yeah, I read that on #gnome-hackers earlier
<ricotz> seb128, havent looked at gdm 3.2 for some time
<ricotz> but it seems worth some work
<ricotz> seb128, so g-c-c and g-s-d 3.4 are on the table again?
<RAOF> ricotz: The newer colord doesn't make your work any easier, does it?  I could sync it now if you need it.
<ricotz> tjaalton, hi, maybe worth to split up wacom a bit more to avoid breaks/conflicts -- although the plain update it in ppa:ricotz/staging
<seb128> ricotz, dunno about g-c-c yet but g-s-d seems doable, I plan to spend today on that
<ricotz> RAOF, i guess not sine i am already running it, might be an update issue of g-s-d
<ricotz> RAOF, but go ahead ;)
<seb128> ricotz, I will revert the keybinding to gsettings first though, the diff seems easy enough that it should be adaptable to use one codepath or the other at runtime if you are interested to work on that to unblock a possible gnome-shell update
<tjaalton> ricotz: what exactly?
<ricotz> seb128, alright, a runtime solution would be nice
<ricotz> tjaalton, they bumped the soname and the libwacom0 contains some common things
<seb128> ricotz, the commit is line an hundred lines and it's mostly replacing a gconf object by a gsetting one through a file, so it's likely you could do a if else on the environment
<tjaalton> i noticed the soname change
<ricotz> seb128, good :)
<ricotz> tjaalton, so it might be better to move "usr/share/libwacom" into libwacom-common
<tjaalton> ricotz: ok
<tjaalton> hmm, or -data
<ricotz> tjaalton, i think "*-common" is widely used -- your call
<tjaalton> i don't mind either way
<tjaalton> 134 packages with -common, -127 with -data.. yay for consistency :)
<tjaalton> more accurate numbers 83 and 53
<tjaalton> ok so -common it is..
<ricotz> ;)
<ricotz> lol
<tjaalton> hmm -common needs to replace libwacom0 though
<tjaalton> seb128: libwacom 0.3 is now building
<seb128> tjaalton, thanks!
<Lekensteyn> Is this the right channel to talk about Xorg in Precise?
<tjaalton> Lekensteyn: yes
<Lekensteyn> alright, I've found that AutoAddDevices "false" segfaults X
<Lekensteyn> for some reason, the memory in InputOption* has been corrupted, the keys contain garbage values
<Lekensteyn> Reproducable with: sudo gdb --args Xorg :7 -isolateDevice PCI:1:00:0 -sharevts -noreset -nolisten tcp -verbose 3 -config /etc/bumblebee/xorg.conf.nouveau
<tjaalton> ok. why do you need that btw?
<ricotz> tjaalton, small problem
<tjaalton> ricotz: ?
<Lekensteyn> xorg.conf.nouveau stripped to the core becomes: http://paste.ubuntu.com/840248/
<Lekensteyn> it's supposed to make X start faster for Bumblebee, a hack to allow the use of nvidia Optimus hardware
<tjaalton> heh
<ricotz> tjaalton, the wacom changes in this way doesnt use the benefits of a split
<tjaalton> ricotz: what do you mean?
<tjaalton> it is split
<ricotz> libwacom-common should be arch all and libwacom2 should have a unversioned or >= depend
<tjaalton> libwacom-common 0.3-1 needs to replace libwacom0 
<ricotz> the replace is ok
<ricotz> i am just thinking about the next soname bump
<tjaalton> oh right, missed the 'all' part
<tjaalton> copied it from -dev
<tjaalton> why would it be unversioned depends?
<tjaalton> *should
<ricotz> to make it possible it have two library versions in parallel, which is more for convenience reason on transitions
<ricotz> otherwise the split isnt needed at all
<tjaalton> it is needed, since the lib is multiarched
<ricotz>  libwacom-common (>= ${upsream:Version}),
<ricotz> right, so arch: all and a not strict dep on -common
<tjaalton> ok, assuming the data format doesn't change
<ricotz> exactly
<tjaalton> so why not a strict one?
<tjaalton> if the data files are updated, it could break the old lib
<ricotz> this makes library transitions easier
<ricotz> yeah, right
<Lekensteyn> tjaalton: gdb session http://paste.ubuntu.com/840259/
<tjaalton> Lekensteyn: file a bug
<tjaalton> upstream too, if possible
<Lekensteyn> Upstream is Debian right? The involved code is different from the official xorg sources
<tjaalton> Lekensteyn: no, freedesktop.org. it's probably the same issue with 1.12. you could verify that with the packages from xorg-edgers ppa
<jcristau> no, upstream is not debian
<tjaalton> Lekensteyn: first make sure to run the latest server, your's is 1.11.3 while precise has 1.11.4
<Lekensteyn> no issues with xorg-edgers
<tjaalton> -'
<tjaalton> ok then
<Lekensteyn> xorg-edgers (oneiric) -> no issues. Precise daily image (from yesterday) -> faulty
<tjaalton> well it's not running the latest upload
<tjaalton> oh, it is
<tjaalton> the server version string is still 1.11.3
<tjaalton> so file a bug on launchpad
<tjaalton> hmm which xserver version does edgers on oneiric have?
<Lekensteyn> 1.11.2.9 iirc, let me check
<tjaalton> so too old
<Lekensteyn> 1.11.2.902 in oneiric
<tjaalton> yep, run precise + edgers
<Lekensteyn> ok brb then
<ricotz> Lekensteyn, if you are brave enough ppa:ricotz/unstable
<Lekensteyn> it's a Live CD so it cannot get worse than having to reboot :)
<Lekensteyn> what one would you recommend?
<tjaalton> ricotz: i'm keeping the = depends, since it's the safest for upgrades
<ricotz> tjaalton, ok
<tjaalton> also widely used it seems
<ricotz> Lekensteyn, this ppa together with xorg-edgers will give you 1.12 on oneiric
<ricotz> tjaalton, ;)
<Lekensteyn> what about precise?
<Lekensteyn> I'm running a non-presistent Live USB Kubuntu Precise right now
<ricotz> oh you are running precise
<ricotz> i thought you are on oneiric, never mind then
<tjaalton> Lekensteyn: enable edgers
<ricotz> while running from the cd a restart shouldnt be needed and restarting x will work
<Lekensteyn> I don't think I'll need a relogin at all since I'll use a different display number?
<Lekensteyn> no crashes with xorg-edgers/ppa
<tjaalton> thanks for confirming, now file a bug :)
<Lekensteyn> okay :)
<tjaalton> against xorg-server
<Lekensteyn> Lovely. Titles with "Xorg crash".
<Lekensteyn> should it be tagged with "regression"?
<tjaalton> yeah
<tjaalton> and precise
<Lekensteyn> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397
<ubot4`> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false" (affects: 1) (heat: 6)" [Undecided,New]
<tjaalton> thanks
<Lekensteyn> I've not added hardware details. Is that important for this case?
<Lekensteyn> Can you reproduce this issue?
<tjaalton> haven't tried
<tjaalton> hw doesn't matter i think
<Lekensteyn> ricotz: can xorg-edgers/ppa on Oneiric be updated? Each time I enter and leave my Wacom Bamboo tablet, I get three lines with "[dix] Unknown event type 35. No filter" in Xorg.0.log. These errors do not occur in Precise (both xorg-edgers/ppa and default) nor the default packages on Oneiric
<ricotz> Lekensteyn, please try the oneiric packages in ppa:ricotz/unstable as i said ealier it contain 1.12 for oneiric, but i guess it needs a bit of testing before Sarvatt is comfortable with it ;)
<ricotz> Lekensteyn, keep xorg-edgers enabled of course
<FernandoMiguel> evening
#ubuntu-x 2012-02-14
<jschall> What's the safest way to install the latest nvidia beta (295.17)?
<RAOF> Wait for it to land in xorg-edgers? :)
<jschall> RAOF: using xorg-edgers is not safe.
<jschall> RAOF: it is in xorg-edgers, but i don't want the rest of xorg-edgers
<bryceh> jschall, then wait for it to land in x-updates
<Sarvatt> it'll go in x-updates when its a stable release which shouldn't be too much longer, beta stuff doesn't go in x-updates
<Sarvatt> (usually)
<bryceh> Sarvatt, right, then maybe x-testing?  https://launchpad.net/~ubuntu-x-swat/+archive/ppa
<jschall> Is there a way to package the lastest nvidia driver beta in a .deb? I can't use xorg-edgers because the synaptics driver is broken for me.
<bjsnider> i don't think it's going to provide any miracles
<bjsnider> what are you expecting it to do?
<bjsnider> there's a chance it would work if you just download the -edgers deb and manually install it
<cnd> bryceh, RAOF: I sent out a proposal for some default setting changes in synaptics last week
<cnd> there hasn't been any feedback so far
<cnd> should I just make the changes?
<cnd> they are two one-line changes
<bryceh> cnd, I don't have an opinion on that
<cnd> bryceh, you don't have an opinion on the settings,or whether I should just make the change?
<bryceh> cnd, if you want to make the changes and just keep an eye on incoming bug reports, I'd be cool with it
<cnd> ok
<cnd> bryceh, you know which changes I'm referring to?
<bryceh> nope
<cnd> bryceh, locked drags when performing a tap and drag
<bryceh> but I remember reading the proposal and deciding I didn't have an opinon on it ;-)
<cnd> and disabling 3 touch click action
<cnd> ahh
<cnd> ok
<cnd> probably the same as everyone else :)
<bryceh> could be
<bryceh> by locked drag what do you mean?
<cnd> bryceh, when you tap and drag, you will continue dragging even after you lift up
<cnd> you have to tap again to release the left button
<cnd> so if you reach the end of the trackpad, you can continue to drag by lifing, reseting your finger elsewhere, and continuing to drag
<RAOF> cnd: Hm.  Have you noticed the xserver crashing with a null mask in positionSprite when scrolling with your -0ubuntu3 server?
<cnd> RAOF, no, I haven't
<cnd> but I don't check every X crash I get :)
<RAOF> You'd notice this.  Every time I two-finger scroll on this touchpad the server crashes.
<RAOF> This might be my fault, though.  I'm rebuilding without any of my patches and I'll scream at you if it still reproduces :)
<cnd> heh, ok
<cnd> RAOF, bryceh: btw, I'll be at a gtk hackfest this week, weekend, next week
<cnd> I'll be on a plane wed
<cnd> then hacking thurs - tues
<cnd> then flying back wed
<cnd> something like that
<cnd> so if you can't reach me, that's why
<RAOF> Oooh, multitouch in GTK?
<RAOF> BAH!  It turns out that my muscle memory includes âtwo finger scrollâ quite a lot.
<cnd> RAOF, we'll be discussing it :)
<RAOF> You haven't uploaded xserver 0ubuntu3 yet, have you?
<cnd> RAOF, oh yeah
<cnd> I made two uploads today IIRC
<RAOF> Ok.  I'll pull down the archive build of 0ubuntu3 then.
<RAOF> *Very* carefully without scrolling.
<RAOF> If this turns out to not be a problem with my patches, how long are you around?
<cnd> RAOF, tomorrow?
<RAOF> I was thinking more this evening.
<cnd> hmm.. I wasn't hoping too long
<cnd> but you can always ping me and hope :)
<RAOF> I'll see if it *is* a problem in 0ubuntu3; if it is, I think it's the sort of thing that we should either fix ASAP or revert ASAP.
<RAOF> Killing the server whenever you scroll is harmful for productivity :)
<cnd> RAOF, when did this start happening?
<RAOF> False alarm; I've clearly broken something while merging my patches on top of 0ubuntu3.
<RAOF> cnd: Sorry for that!
<cnd> RAOF, np :)
<cnd> bryceh, can you paste me your synaptics caps from your dell netbook
<cnd> dmesg | grep ynaptics
<cnd> I want to try to verify some bits
<bryceh> cnd, http://paste.ubuntu.com/841275/
<cnd> bryceh, thanks
<cnd> looks to be the same as mine
<dholbach> hi guys
<dholbach> do we know anything about bug 931344? crash in XIGetDeviceProperty() 
<ubot4`> dholbach: Error: Bug #931344 not found.
<dholbach> ubot4`, try harder :)
<ubot4`> Factoid 'try harder :)' not found
<RAOF> That seems an odd one to crash in.
<dholbach> I've had it happen a couple of times already :-/
<dholbach> since maybe 3-4 days?
<tjaalton> looks like a dupe in bug 931658
<ubot4`> Launchpad bug 931658 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in XIChangeDeviceProperty() (affects: 1) (heat: 10)" [Medium,New] https://launchpad.net/bugs/931658
<tjaalton> hum no
<dholbach> robbiew seems to have had a similar one (bug 931658)
<dholbach> 931951 is probably a dup I filed, but it's not retraced yet
<tjaalton> dholbach: hmm, x220 has a clickpad-type touchpad?
<dholbach> hum, what does clickpad-type touchpad mean?
<tjaalton> it doesn't have buttons
<tjaalton> but you click the pad
<dholbach> yes, the bottom of the touchpad serves as left-mouse-button
<tjaalton> ok good
<tjaalton> robbie has x220 tablet
<tjaalton> so they are probably related to the new clickpad code
<dholbach> ah ok, so the bugs are different
<tjaalton> happening in different parts of the code, but could still be related..
 * dholbach nods
<dholbach> :-(
<dholbach> arg
<tjaalton> dholbach: try disabling the touchpad from bios, and use the nipple for now
<dholbach> ok, next time it crashes, I'll do that
<dholbach> this time it was compiz crashing
<dholbach> XDefineCursor *shrugs*
<seb128> dholbach, bug number?
<dholbach> seb128, 932024
<seb128> dholbach, danke
<tjaalton> subscribed ubuntu-x to mesa-demos bugmail
<Sarvatt> cool, missed those. a lot of these can be closed
<Sarvatt> so thats where all the fglrx bugs went
<tjaalton> heh, yeah
<tjaalton> i didn't notice it got split at some point
<Sarvatt> tjaalton: can ya accept nominations on it?
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/926918
<ubot4`> Sarvatt: Error: Bug #926918 not found.
<Sarvatt> fixed in precise but not oneiric
<jcristau> bad ubot4`.
<Sarvatt> jcristau: it was private because it had personal info, was my mistake
<Sarvatt> linking before fixing that :)
<tjaalton> Sarvatt: sure. so marking fixed but leaving oneiric open?
<Sarvatt> yeah fixed in ubuntu and precise tasks, easily can be srued to oneiric
<tjaalton> if someone bothers to do it :)
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.11&id=0e9b79c22a53efb8413ba6b4e49085a08221a5d3 is the fix
<Sarvatt> yepyep
<Sarvatt> i'm still fighting another mesa sru thats kicking my butt, fix after refactor ftw..
<Sarvatt> thats actually not even in a 7.11 release
<Sarvatt> thats odd, almost all the bugs are private
<Sarvatt> retracer not cleaning up after it? i thought that was automatic
<tjaalton> cnd: hey, there are a couple of crashers that seem to have clickpad functionality in common
<tjaalton> lots of "unable to find touch point 0" in the log, then segfault
<cnd> tjaalton, hmm... are you sure they are clickpads?
<tjaalton> one is an apple macbook, two are lenovo x220's
<cnd> ok
<Sarvatt> someone filed a MIR for mesa-demos, hmm
<tjaalton> bug 931344 for instance
<ubot4`> Launchpad bug 931344 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in XIGetDeviceProperty() (affects: 1) (heat: 10)" [Medium,New] https://launchpad.net/bugs/931344
<Sarvatt> https://launchpadlibrarian.net/92767242/XorgLogOld.txt
<Sarvatt> hmm https://launchpadlibrarian.net/92806848/XorgLogOld.txt
<tjaalton> Sarvatt: what about it?
<Sarvatt> looks like the same thing but the bug was different
<tjaalton> yeah, slightly
<tjaalton> SegvAnalysis is ~identical though, but i've no idea if you can draw any conclusions from that..
<Sarvatt> that bcm5974 one was from https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931674
<ubot4`> Sarvatt: Error: Bug #931674 not found.
<Sarvatt> argh why isn't apport unmarking private after it deletes the core dumps
<tjaalton> bryceh: the upstream git browsing links on versions_current are wrong, cgit only these days it seems
<Sarvatt> tjaalton, bryceh: http://paste.ubuntu.com/841874/ ?
<Sarvatt> or is it http://paste.ubuntu.com/841878/
<tjaalton> whaa, where's that script?
<Sarvatt> arsenal
<Sarvatt> lp:arsenal
<tjaalton> ok
<tjaalton> i'll steal it for freeipa :)
<Sarvatt> bryceh: if thats right, https://code.launchpad.net/~sarvatt/arsenal/fdo-url-fix
<Sarvatt> tjaalton: careful lest you get ip banned from fdo like bryce did
<tjaalton> Sarvatt: nah, fedorahosted :)
<tjaalton> goes to the end of the todolist anyway
<Sarvatt> tjaalton: btw do you use syncpackage?
<tjaalton> Sarvatt: yep
<Sarvatt> you can add -s launchpadid to sponsor, and -b bugnumber to close the bug automatically
<tjaalton> yeah sorry for not giving you the credit :)
<tjaalton> used -b
<Sarvatt> oh cool, yeah i dont care at all just figured you didnt know in case you sponsor someone elses
<Sarvatt> pretty sure i have enough uploads to not matter anymore
<tjaalton> :)
<Sarvatt> now to sell myself to the DMB, that part weirds me out enough that i haven't done it yet after going through it once before for membership
<cnd> tjaalton, I have seen some crashes when devices are removed
<cnd> haven't had a chance to track them down yet
<cnd> that looks to be the same as the bug you showed me
<cnd> Sarvatt, yeah, going before the DMB sucks
<cnd> I got your back :)
<Sarvatt> cnd: apparently there's an easy way to reproduce the removed device crashes, disable bluetooth on a system with your magic trackpad
<cnd> ahh
<cnd> Sarvatt, when I get a chance I'll look into it
<cnd> I'll assign the bug to me
<Sarvatt> vanhoof just hit it http://paste.ubuntu.com/841908/
<Sarvatt> RAOF: http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff refreshed for current xserver master
<Sarvatt> after http://cgit.freedesktop.org/xorg/xserver/commit/?id=42b6756463ee0476340656707f1088dc6c2fd220
<Sarvatt> RAOF: scratch that, the newly uploaded http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff is the right fix for master, i refreshed 1.11's version and lost the swaps/swapl changes
<cnd> Sarvatt, do you use edge scrolling?
<Sarvatt> 2 finger only
<Sarvatt> got used to osx on this thing when i915 didnt work
<Sarvatt> edge scrolling doesn't work, thats the first time i've noticed :P
<Sarvatt> cnd: should i test something? i'm willing to purge edgers to test out something if it'd help
<cnd> Sarvatt, ok, nm, I wondered if that's why the clickpad stuff wasn't working for you
<cnd> I just found a bug if you have edge scrolling enabled
<Sarvatt> i'm actually using an ancient synaptics at the moment because you uploaded 1.5.99 as 1.5.0
<cnd> no need to reuse edgers for this
<cnd> Sarvatt, that's cause debian hasn't updated to 1.5.99 yet
<cnd> actually, I'm not sure synaptics 1.5.99 has been released yet...
<Sarvatt> it hasn't but its 1.5.99 in configure.ac so my scripts name it that
<Sarvatt> i tested your upstream-ubuntu with bryce's package debian/ the other day
<Sarvatt> err synaptics-clickpad? whatever the one was that worked with 1.12
<cnd> Sarvatt, ahh, that stuff was old and had some issues
<cnd> I'm ironing them out :)
<cnd> Sarvatt, there was a specific issue with macbook trackpads that has been resolved
<Sarvatt> is it in your PPA?
<Sarvatt> or some branch I can pull?
<Sarvatt> or patches on a list i should try? i'm gonna downgrade now
<cnd> Sarvatt, I just pushed the latest stuff up to my git repo on freedesktop.org
<cnd> if you're on upstream 1.12, use clickpad-v2 branch
<cnd> if you're on precise's server, you can wait till I push out updates to my ppa
<cnd> Sarvatt, hold off on that branch
<cnd> I found a small issue
#ubuntu-x 2012-02-15
<Sarvatt> broder: I dunno about breaking xorg 6.9 to make nx faster, there actually is a xorg 6.9 comsumer of ubuntu in windows (xming)
<Sarvatt> of course i havent seen a windows ubuntu thing since hardy
<Sarvatt> 6.9 is the latest free version of xorg for xming and they used that for the portable ubuntu crap that i did use at one point
<Sarvatt> in reference to breaking cairo for xorg < 7.0 because it makes nx slower
<broder> oh, ugh
<broder> and it's actually 6.9.0, too?
<broder> (my patch matched 6.9.0 exactly)
<Sarvatt> well 6.9 is artificial, how did it match 6.9.0?
<Sarvatt> specific xserver version shipped in that xorg release?
<broder> VendorRelease
<broder> which was the xorg release number before xorg 7.0, at which point it became the xserver version
<Sarvatt> trying to figure out what version is shipped in that, thats really less high impact that making nx work for sure but would still break *something*
<broder> i'm very open to ideas for picking out nx specifically, but i couldn't figure out how to tell by querying my X display
<broder> (there was stuff in the environment, but i don't think i should rely on that)
<broder> Sarvatt: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/cairo/precise/view/head:/src/cairo-xlib-display.c#L360 walks through the original logic
<Sarvatt> eww, i see what you mean, and yeah totally the only option i can see
 * Sarvatt wasnt even aware of the versions being reported differently that long ago
<broder> the xming page claims that it's kept current
<Sarvatt> xming isnt important anyway, wasnt trying to imply its worth caring about. they charger for newer stuff and it looks like portable ubuntu dropped of completly
<Sarvatt> 6.9 was just the last free version they ship
<broder> oh i see. suck
<gotwig> hey
<ricotz> bjsnider, hi, https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/932781
<orated> Will Ubuntu Precise release be able to disable Nvidia Optimus?
<tjaalton> orated: automatically? no, disable it from bios if possible
<orated> tjaalton: My BIOS doesn't allow that sadly
<tseliot> tjaalton: I think RAOF worked on an app to disable one card if optimus is enabled
<tseliot> ricotz: too bad. That's the releasing that I'm going to upload in Precise
<ricotz> tseliot, hey, just do it
<tseliot> :)
<tseliot> we can probably update it later when it's fixed
<ricotz> tseliot, this could be a g-s extension problem too
<tseliot> right
<ricotz> tseliot, i dont think it is a good idea to delay nvidia on this
<tseliot> I agree
<ricotz> please upload it
<ricotz> tseliot, could you clean up the packaging a bit, look at the xedgers packaging
<tseliot> ricotz: I will. I'm waiting to finish some other work on hybrid graphics
<tseliot> ricotz: clean up the packaging?
<ricotz> tseliot, oh, i think i cleaned the fglrx packaging, not nvidia
<tseliot> ricotz: I'll have a look at that
<ricotz> i mean the debian/control which was a bit messy
<tseliot> ah, ok
<ricotz> if you are going to look at 8.930 too, be aware that upstream is broken a bit
<ricotz> while shipping a wrong file
<tseliot> I'm waiting for another driver release
<ricotz> tseliot, wrap-and-sort helps
<tjaalton> tseliot: ok
<bdmurray> cnd: would you know anything about my magicpad not pasting anymore with a 3 finger touch (that used to be a middle click)
<cnd> bdmurray, yes, it conflicts with three touch gestures, so we had to disable it
<cnd> you can manually override
<cnd> but that's the best we can do at this point
<bdmurray> and how do I override it?
<cnd> bdmurray, run xinput, and tell me your trackpad's device name
<bdmurray> Apple Wireless Trackpad                   id=12   [slave  pointer  (2)]
<cnd> xinput set-prop "Apple Wireless Trackpad" "synaptics Tap Action" 2 3 0 0 1 3 2
<cnd> oops, forgot a capitalization
<cnd> the tap action prop should start with 'S'ynaptics
<cnd> bdmurray, ^^
<bdmurray> I see thanks!
<cnd> bdmurray, that's safe to put in bashrc if you want
<cnd> well, bashrc probably isn't best
<cnd> whatever that x startup rc script is
<cnd> bdmurray, when you have that enabled, you'll be forgoing three touch gestures in unity
<cnd> fair warning :)
<bdmurray> I don't even know what three touch gestures work! ;-)
<cnd> bdmurray, they might not right now
<cnd> we're working out some bugs in our new stack
<cnd> but three touches on a window in unity will allow you to move the window around
#ubuntu-x 2012-02-16
<tjaalton> oh cool, we now have the wacom goodness in g-c-c
<broder> ugh. the new vmware svga3d rendering is incredibly glitchy
<tjaalton> broder: really? Prf_Jakob said it worked great when we first got it working
<tjaalton> broder: sure you are not using normal swrast?
<tjaalton> well, llvmpipe normal
<broder> tjaalton: not positive. it was running unity 3d
<tjaalton> _that_ is glitchy
<broder> let me bring the vm back up and check
<tjaalton> pastebin the logfile
<tjaalton> I'm not convinced yet :)
<broder> but there was a lot of flickering back to past frames and ghost images
<tjaalton> sounds familiar
<broder> yeah, it's llvmpipe. what do i need to do to switch it?
<broder> dri-experimental?
<tjaalton> that's empty
<tjaalton> I'm not sure what's needed.. pastebin the logfile
<broder> http://paste.ubuntu.com/844056/
<tjaalton> [  1374.489] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available.
<broder> ...oh. i bet i need to tick the box in the vm's configuration, don't i?
<tjaalton> whatever that means
<tjaalton> maybe
<tjaalton> so bug 926859 remains unfixed
<tjaalton> ah, no ubotu
<broder> huh. i can't figure this out - vmwgfx is getting loaded, and i have a /dev/dri/card0
<tjaalton> and still doesn't work?
<broder> nope
<broder> still getting the same message
<tjaalton> weird
<broder> where is that message even coming from? i can't find it in xserver-xorg-video-vmware or mesa
<tjaalton> no idea
<ara> tseliot, hola!
<tseliot> hola, ara!
<ara> tseliot, hey! one of the bugs that are blocking certification for 11.10 has been marked as incomplete (and assigned to you) waiting on your input for a little while:
<ara> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/877682
<ara> tseliot, can you check it, please?
<tseliot> ara: sure. I have a thinkpad w520, maybe I can reproduce it here
<ara> cool, thanks
<tjaalton> great, can't turn numlock off
<tjaalton> does nothing
<tjaalton> though I get the event
<seb128> tjaalton, going to be fixed soon
<seb128> I'm impressed by how many people actually turn numlock off
<seb128> I got surprised because I'm use to the screensaver having it wrong so I usually do an off-on
<seb128> which didn't change the led
<seb128> but I never turn it off otherwise
<seb128> tjaalton, g-s-d issue, you can "gsettings set org.gnome.settings-daemon.peripherals.keyboard remember-numlock-state false"
<tjaalton> well my keyboard doesn't have a separate keypad
<tjaalton> numpad that is
<seb128> tjaalton, let me know if the gsettings commands work
<tjaalton> it's a lenovo thinkpad usb keyboard, so hitting numbers instead of letters atm :)
<seb128> I didn't try it but I assume it does
<tjaalton> I'll try
<tjaalton> didn't hit Fn+ScrLk but some combination of Fn, shift and capslok apparently
<tjaalton> seb128: didn't seem to help
<tjaalton> the running session anyway
<seb128> tjaalton, trying stop gnome-settings-daemon
<seb128> stopping
<seb128> doh, can't type, "try stopping..." ;-)
<tjaalton> surprisingly hard to "type" kill, I get 2533
<tjaalton> nope
<tjaalton> well, g-s-d is just reflecting what the state is, it apparently can't change it
<tjaalton> looks like not even numlockx can change it, the led stays on on xkbvleds
<tjaalton> seb128: what's the bug# :)
<seb128> tjaalton,  the gsd one is bug #933405
<tjaalton> thanks
<seb128> tjaalton, but that one is confirmed a gsd issue, downgrading gsd or settings that key to false fixes it
<seb128> tjaalton, so I recommend you open a new one if yours isn't that
<tjaalton> well I'm not sure where the bug is
<tjaalton> uh oh
<tjaalton> now the keyboard thinks it's got a numpad
<tjaalton> even though I managed to turn numlock off (via VT)
<tjaalton> so the keys act as a numpad or cursor keys
<tjaalton> wth
<tjaalton> ok it is a bug in g-s-d, I can't change the state of numlock back to off with 3.3.5
<tjaalton> 3.2 works
<tjaalton> though to fully fix the state I had to go to the VT
<tjaalton> i'll upgrade my laptop to confirm
<seb128> tjaalton, ok, the gsd bug is about to be fixed
<tjaalton> seb128: do you want me to test it before filing this one?
<tjaalton> in case it's the same
<seb128> tjaalton, yes please
<tjaalton> the workaround probably works if you reboot after it
<tjaalton> seb128: btw, the new wacom capplet works great
<seb128> tjaalton, excellent, thanks for testing!
<seb128> can you calibrate with it?
<seb128> tjaalton, g-s-d with the fix uploaded btw
<tjaalton> no need, the one I have is not a tablet
<tjaalton> great
<tjaalton> actually, the "map buttons" button is greyed out
<tjaalton> seb128: thanks! the new g-s-d works
<seb128> tjaalton, excellent
<tjaalton> printscreen doesn't fire the screenshot app though :)
<tjaalton> after the updates this morning
<seb128> tjaalton, it's not since today, it's since a few days, or a week
<seb128> tjaalton, it stored the images in your xdg Images directory
<seb128> stores
<seb128> upstream GNOME design decision
<seb128> it should do the graphical effect and sound though
<seb128> like tablets,phones do it
<tjaalton> ah ok, yeah there they are..
<jcristau> do people actually enable sound effects on their computers?
<tjaalton> they don't need to, it's on by default :)
<jcristau> well ok, leave them enabled then
<Sarvatt> bryceh: bah whoops, need to remove .git from the cgit urls too
<bryceh> Sarvatt, oh, ok
<bryceh> Sarvatt, cgit hasn't been working for me the past couple days
<tjaalton> so, mesa and wayland* merges before FF?
<tjaalton> 3h to go :)
<Sarvatt> 1h?
<tjaalton> 2100UTC
<Sarvatt> oh
<Sarvatt> eh 8.0.1 was supposed to be released today, might as well wait
<tjaalton> we're still on rc2, debian has 8.0
<bryceh> I fear for upgraders right now
 * Sarvatt hasn't been able to upgrade for over a week
<Sarvatt> i keep hitting it at bad times
#ubuntu-x 2012-02-17
<Sarvatt> Amaranth: any idea if gles compiz is going into precise?
<bryceh> lp #933104
<Sarvatt> bjsnider: whoa didn't notice you did that, thanks for putting 295.20 in x-updates
#ubuntu-x 2012-02-18
<bjsnider> Sarvatt, yeah, and then there were about 3  or 4 major bugs that were reported on it
<bjsnider> so much for a "long term release" or whatever they're calling it
<Sarvatt> the gnome-shell problems?
<bjsnider> yeah, plus there's one guy saying a game crashes
<bjsnider> and otehr stuff i can't remember now
<bjsnider> every distro too, not just ubuntu
#ubuntu-x 2013-02-11
<tjaalton> got green light to update llvm-3.2 for mesa, so I'll upload it in a bit
<ogra_> tjaalton, https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068994/comments/24
<ubottu> Ubuntu bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed]
<tjaalton> ogra_: ooh, excellent
<ogra_> yeah, raster did some debugging :)
<tjaalton> I'll add some of it to the upstream bug and ping whot
<ogra_> great
<mlankhorst> morning
<tjaalton> mlankhorst: push your changes to xorg-server, infinity added some which I'd like to commit there
<tjaalton> audit is now in main \o/
<mlankhorst>   ah
<mlankhorst> tjaalton: I have none to xorg-server atm?
<tjaalton> who released 1.13.2?
<mlankhorst> oh I did, but I think it's on the ubuntu branch already
<jcristau> marcoz is supposed to handle 1.13.x
<jcristau> ah.  in ubuntu, not upstream.  oops :)
<tjaalton> yeah :)
<mlankhorst> hm I don't know if I committed the release to raring changelog though *checks*
<tjaalton> mlankhorst: still unreleased
<tjaalton> ah
<tjaalton> that would explain it then
<mlankhorst> I guess I never did
<mlankhorst> ah well I'll do so now
<tjaalton> cool
<mlankhorst> and seems adconrad did a -0ubuntu2 on top of it
<tjaalton> right,
<tjaalton> -,
<tjaalton> I was merging that when I noticed -0u1 wasn't committed
<mlankhorst> ok pushed
<tjaalton> thx
<tjaalton> oh you pushed infinity's change too, nice
<mlankhorst> did you test the mesa 9.1 package? :)
<tjaalton> I didn't but Sarvatt did
<tjaalton> on some hw
<tjaalton> hum, might give it a go now
<mlankhorst> it should work probably
<mlankhorst> ah well, piglit try #2 on i915
<mlankhorst> looks like the varying packing causes it to hang hard :(
<jcristau> anybody knows what CVE-2013-1591 is about?
<ubottu> Stack-based buffer overflow in libpixman, as used in Pale Moon before 15.4, has unspecified impact and attack vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1591)
<jcristau> also wtf is pale moon?
<tjaalton> "A custom-built and optimized Firefox-based browser for Windows." *shudder*
<mdeslaur> jcristau: this seems to be the only difference in pale moon: http://cgit.freedesktop.org/pixman/commit/?id=de60e2e0e3eb6084f8f14b63f25b3cbfb012943f
<jcristau> thanks
<mlankhorst> oh finally
<mlankhorst> mesa 9.0.2 on my intel mbp has 11 tests fixed, no regressions
<tjaalton> cool
<tjaalton> updating -intel again
<mlankhorst> so I guess it's time to upload
<mlankhorst> tjaalton: hey can you sponsor mesa for me? seems i cant upload to quantal
<tjaalton> mlankhorst: sure, later :)
<mlankhorst> oh seems i should be able to upload now
<bjsnider> tjaalton, any issues with intl on raring right now?
<bjsnider> had a snb user last night in the other channel who couldn't load it after doing a clean install of the latest image
<mlankhorst> tjaalton: nm quantal has xorg package set now :)
<tjaalton> bjsnider: it has worked very well for me on snb, make sure to file a bug and ickle will react :)
<tjaalton> upgraded my ivb desktop today, blissful there too
<tjaalton> i965 with mesa 9.1 seems oddly sluggish with the dash though
<Sarvatt> ricotz: doing mesa as soon as this llvm builds
<ricotz> Sarvatt, oh, i just pushed llvm
<Sarvatt> lol
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
<ricotz> Sarvatt, why are you pushing it to raring?
<ricotz> and an older version too
<Sarvatt> r600 backend isn't in raring's llvm-3.2
<ricotz> Sarvatt, ok, but the raring build will make no difference
<ricotz>  llvm-3.2 - 3.2-2ubuntu2.1~edgers1 (Newer version available) 
<Sarvatt> oh argghhh
<Sarvatt> https://lists.ubuntu.com/archives/raring-changes/2013-January/date.html
<Sarvatt> spot the problem? i was looking on that :)
 * Sarvatt forgot to update the bookmark this month
<ricotz> Sarvatt, i see either way i pushed 3.2-2ubuntu3~
<ricotz> will cancel the other builds then
<Sarvatt> https://launchpad.net/~canonical-x/+archive/x-staging wasn't saying llvm-3.2 in raring was newer when i started the source download an hour ago (10kbps from the ppa ftw..)
<ricotz> lol ;)
<ricotz> i guess we had the same idea then
<ricotz> wanted to look at mesa too
<ricotz> Sarvatt, a drm update would be nice
<ricotz> first
<Sarvatt> sure thing, doing that now
<ricotz> Sarvatt, thanks
<ricotz> Sarvatt, feel free to push xserver 1.14 to raring too
<ricotz> ;)
<tjaalton> Sarvatt: llvm in raring has it now
<tjaalton> maybe not made it out of proposed yet
<Sarvatt> tjaalton: yeah pushed an hour ago and i started looking at updating it in the ppa earlier :)
<fm> how can i get further with https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1116587 ?
<ubottu> Ubuntu bug 1116587 in xserver-xorg-video-intel (Ubuntu) "Lenovo T400: With external monitor the system is rarely working for more than 10 minutes" [Undecided,Confirmed]
<bryce> fm, you're right - nothing in your Xorg.0.log or dmesg.  And if there's no i915_error_state file then it's sounding like it's not "just" a GPU lockup or xserver crash
<bryce> even possible it's not X locking up
<fm> bryce, so what could i do to narrow that down?
<bryce> fm, check .xsession-errors, /var/crash for any .crash files, and /var/log/syslog
<fm> quite annoying to have a system crash every 10 minutes
<bryce> fm, is it exactly regular 10 min, or just more or less?
<fm> no apport popping up at reboot so no .crash, and syslog empty as well
<fm> bryce, no just more or less
<bryce> fm, can you trace to when that first started and what you did leading up to it?  or has it been like that since install?
<fm> i think it does not happen when idle ;)
<fm> bryce, happens since running 13.04, was not there with 12.10
<fm> right now i am on 2.21.2 or so
<bryce> fm, and it started right after upgrading?
<fm> there was an xorg-intel-drv update just today
<fm> bryce, yes happend right after upgrading
<bryce> fm, hmm well no idea what's wrong, but can throw out some advice for tracking it down more
<bryce> fm, I haven't run across reports quite like this, that sound like a GPU lockup but don't have evidence in the logs
<bryce> fm, so something must be a bit unique about your system.  So you might doubly think about anything you've installed  or done that other people wouldn't have done.  or anything unusual about the hardware that others might not have.
<bryce> fm, fwiw, until just recently, this cycle for 13.04 we haven't changed much on X compared with 12.10, aside from targeted bug fixes.  Same xserver, drivers, etc.
<bryce> fm, so issues that crop up on upgrade to 13.04 that didn't happen in 12.10, we often suggest looking first at the kernel or other things, before X, which did receive big bumps.
<bryce> so, like try installing and booting the quantal kernel, and see if you can rule that out
<fm> will look at .xsession-errors next time, haven't looked there
<bryce> fm, or try turning off splash in the kernel config to rule in/out plymouth
<bryce> yeah anything unusual in .xsession-errors would be interesting
<fm> ok, will try an old kernel
<bryce> and ssh in while it's frozen and look for any files changed in /var/log/*
<fm> what is the best way to get it?
<fm> bryce, yeah, can just go to ctrl-alt-1
<bryce> fm, think you can download the .deb off launchpad.  kernel has no dependencies so pretty much grab from whereever's convenient.
<bryce> oho, if you can vt switch, that suggests not a gpu lockup
<bryce> fm, have you been able to just `sudo service lightdm restart` to get it working again?  Or does it require a full reboot?
<bryce> fm, ok gotta go work on some other stuff, but good luck.  If you can copy some of the stuff we discussed onto the bug, it'll help fill in whomever looks at it next.
<fm> bryce, will try lightdm restart
<mlankhorst> hey
<bryce> mlankhorst, hi
<mlankhorst> ok seems mesa 9.0.2 works for me
<mlankhorst> so I uploaded mesa-lts-quantal 9.0.2 too now :)
#ubuntu-x 2013-02-12
<RAOF> Yo! Anyone running mesa 9.1ish?
<mlankhorst> RAOF: it's in canonical-x staging?
<tjaalton> it was about a leaky r600, fixed in that version
<RAOF> mlankhorst: Yeah; I was just wondering if anyone else was seeing horrible memory leaks; turns out it was just my snapshot.
<mlankhorst> right it was a bug in old mesa git, radeon I guess? :P
<RAOF> Indeedy.
<fmms> any idea for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1116587 ?
<ubottu> Ubuntu bug 1116587 in xserver-xorg-video-intel (Ubuntu) "Lenovo T400: With external monitor the system is rarely working for more than 10 minutes" [Undecided,Confirmed]
<tjaalton> fmms: you were here yesterday already
<tjaalton> you might get lucky on #intel-gfx
<tjaalton> guess I need to try repro that bug with my old x61 & tv
<tjaalton> but not today
 * bryce waves
<fmms> tjaalton, yeah, but i guess not everyone is reading every day ... and i guess it is not a driver issue. i can still go to the console and restarting lightdm works
<tjaalton> fmms: enable this ppa https://launchpad.net/~canonical-x/+archive/x-staging and then run 'apt-get install libgl1-mesa-glx libgl1-mesa-dri', do _not_ run dist-upgrade as that'll break unity
<tjaalton> it could be a bug in the dri driver, possibly fixed with the new mesa snapshot
<exalt> mlankhorst: hey are you there ?
<bjsnider> tjaalton, i'm getting tearing if i switch monitor orientation left or right. is that expected?
<tjaalton> bjsnider: dunno
<tjaalton> sounds like a bug
<exalt> hi anyone around with knoledge of linux hybrid graphicscard support in 13.04 ?
<mlankhorst> oh
<mlankhorst> it's a bonus if it works
<exalt> mlankhorst: so you are trying to get it to work ?
<exalt> did you get your macbook already ?
<mlankhorst> yeah the macbook works, less luck with nouveau :p
<exalt> mlankhorst: can you update the launchpad? https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-hybrid-graphics
<mlankhorst> not much to say there
<exalt> is there a better page to monitor the optimus progress?
<mlankhorst> reverse optimus probably works on raring, but its slow and no synchronization
<exalt> mlankhorst: is it probable that thats going to change within months ?
<mlankhorst> nah
<mlankhorst> well kernel parts probably working soon, depends a bit
<exalt> ill be gone now, expect future kruisverhoren 
<exalt> :p
<exalt> thanx for your information
#ubuntu-x 2013-02-13
<RAOF> Ok. New mesa 9.1 snapshot question - is anyone seeing a gem object leak on sandybridge?
<mlankhorst> RAOF: no but I haven't looked for one either, so maybe? :p
<tjaalton> i'm running 9.1 on snb, how can I tell if it leaks or not?
<RAOF> tjaalton: while true ; do egrep "^[[:digit:]]+ objects, [[:digit]]+ bytes" /sys/kernel/debug/dri/0/i915_gem_objects ; sleep 1 ; done
<RAOF> That'll print out the total size; if it keeps increasing over time (not necessarily strictly increasing, but just tending to increase) then you're probably hitting it.
<RAOF> Other symptoms include: after a while everything will crash as the OOM killer flails around before killing compiz.
 * mlankhorst hands RAOF watch -n1
 * RAOF gratefully receives it
<tjaalton> the egrep part is missing something
<tjaalton> egrep: Pariton [ tai [^
<RAOF> Sorry, yeah.
<tjaalton> sorry for the locale
<tjaalton> :)
<RAOF> It's missing the trailing â:â from the second :digit:
<tjaalton> oh
<tjaalton> ok, I'll let it run for a while
 * mlankhorst needs to figure out why nouveau is failing :(
<mlankhorst> not upstream, just wrote some patches for the new synchronization framework, fails on my poor nva8
<tjaalton> RAOF: doesn't seem to be increasing here
<tjaalton> seems to stay around ~770 objects, ~510000000 bytes
<RAOF> tjaalton: Ta. Urgh.
<mlankhorst> RAOF: if you know what application, valgrind to the rescue?
<RAOF> mlankhorst: Plausibly. Tis the mighty compiz, though.
<mlankhorst> I mean it would probably show up as a normal allocation, so just crank up logging on valgrind and kill it after a bit
<RAOF> Yeah. As long as it's not free()ing the bo without bo_unref()ing it, it should leak valgrind-tracable memory.
<RAOF> Now, to see if this abuse of prime does anything interesting...
<mlankhorst> did it?
<shadeslayer> hm, can anyone install the fglrx driver on raring?
<shadeslayer> update-initramfs just goes kaput
<shadeslayer> http://paste.kde.org/670244/
<shadeslayer> I also see a bunch of bug reports
<ogra_> shadeslayer, thats modprobe, not update-initramfs
<ogra_> (talk to #ubuntu-kernel probably)
<shadeslayer> ogra_: okay :)
<shadeslayer> could someone also advise me on this : http://paste.ubuntu.com/1644035/
<shadeslayer> I don't quite understand what's going wrong there
<mdeslaur> I just upgraded to raring, and I have to reboot about 10 times for X to come up. Is "Cannot run in framebuffer mode. Please specify busIDs" a known bug, and is there a bug number?
<tjaalton> hehe
<tjaalton> it's well known
<tjaalton> mdeslaur: for a workaround, remove -modesetting & -fbdev
<tjaalton> pastebin your logfile to be sure
<bryce> tjaalton, does the sleep in /etc/lightdm/lightdm.conf also work around it still?
<tjaalton> bryce: ah, maybe
<tjaalton> haven't tried that one
<bryce> might be a less invasive workaround
<mdeslaur> tjaalton: http://paste.ubuntu.com/1645897/
<mdeslaur> tjaalton: remove that from what, exactly....are those packages?
<tjaalton> [     4.157] setversion 1.4 failed
<tjaalton> bingo
<mdeslaur> ie:  xserver-xorg-video-fbdev
<tjaalton> mdeslaur: xserver-xorg-video-
<tjaalton> yes
<mdeslaur> tjaalton: ok, I only have -fbdev
<mdeslaur> ah, no, I've got the other one too
 * mdeslaur is in fat-finger mode
<mdeslaur> tjaalton: is there a bug #?
<bryce> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/982889/comments/5
<ubottu> Ubuntu bug 982889 in xorg-server (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,Triaged]
<bryce> mdeslaur, bug 982889
<mdeslaur> thanks bryce
<tjaalton> mdeslaur: did you use quantal before?
<mdeslaur> tjaalton: yep, never got that on quantal
<tjaalton> weird
<tjaalton> but maybe it's slightly quicker to boot now, which makes it easier to hit
<mdeslaur> yeah, it's called progress...darn people with they speed optimizations :P
<mdeslaur> hehe :)
<bryce> or kernel got slower...
<fmms> is chris willson here?
<fmms> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1116587
<ubottu> Ubuntu bug 1116587 in xserver-xorg-video-intel (Ubuntu) "Lenovo T400: With external monitor the system is rarely working for more than 10 minutes" [Undecided,Confirmed]
<bryce> fmms, he is ickle on #intel-gfx
<fmms> bryce, thanks
#ubuntu-x 2013-02-14
<cjwatson> Hi
<bryce> heya
<mlankhorst> if realloc crashes, couldn't you try valgrind?
<cjwatson> FWIW, I'm continuing with the tail-end of the respins; it doesn't lose us that much even if we end up respinning for this
<cjwatson> And it will let Kubuntu get going with validation
<mlankhorst> but what exactly is the issue now? I haven't really followed it as I was trying to fall asleep
<cjwatson> bug 1124660
<ubottu> bug 1124660 in xorg (Ubuntu) "Precise 20120213 i386 live session fails in virtualbox" [Undecided,New] https://launchpad.net/bugs/1124660
<cjwatson> As I think Sarvatt pasted, my take is that I don't currently see how the /dev/port patch could have changed memory allocation behaviour, and thus there is a tempting working hypothesis that says that this was lurking all along and that it's possible that we've just gone from fatal server error to a realloc crash, in which case who really cares
<cjwatson> But Sarvatt is right to flag a possible regression and I think we should make sure we understand it
<Sarvatt> backport X stack + vesa is working fine with the newer libpciaccess on intel, http://paste.ubuntu.com/1647335/
<bryce> cjwatson, yes seems plausible
<cjwatson> sleep> tell me about it, I got three hours last night and I've been up for 17 hours now
<Sarvatt> i've only been able to reproduce it in virtualbox so far
<mlankhorst> Sarvatt: what makes you think it's an abi break though?
<mlankhorst> I don't see anything in the patch that owuld indicate that
<bryce> mlankhorst, the stacktrace looked like what you might get from an abi break.  just a guess though.
<mlankhorst> meh valgrind it
 * mlankhorst checks if virtualbox works
<mlankhorst> nope, guess ill netboot and do it over nfs on a crappy 100 mbit :/
<cjwatson> Isn't the failure specific to vbox hardware?
<mlankhorst> probably
<cjwatson> plars might still be around and walkable through it
<cjwatson> 23:58  * plars -> supper, then back for more iso testing
<mlankhorst> but i can run it in a virtualbox over netboot
<cjwatson> that was 80 minutes ago
<cjwatson> ah
<mlankhorst> it's also very slow but I'm not really awake anyway
<Sarvatt> hmm, but vesa works when booting the livecd, its just when you click try ubuntu that there is a crash
<cjwatson> The effect of "Try Ubuntu" is to fall out of ubiquity-dm and let lightdm start
<cjwatson> So it'll be tearing down the server and starting a new one after whatever random plumbing wibble happens around there
<cjwatson> ^- technical term
<RAOF> Heh
 * mlankhorst tries hard not to fall asleep
<mlankhorst> cd is http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-i386.iso ?
<cjwatson> Yes
 * RAOF wonders what will happen first: the fibre-to-the-home rollout hitting his house, or that iso downloading.
<Sarvatt> RAOF: axel?
<mlankhorst> great, virtualbox doesn't work on lts kernel
<RAOF> Sarvatt: ???
<Sarvatt> axel http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-i386.iso
<mlankhorst> ugh
<Sarvatt> axel -n 32 if its slow? :P
<mlankhorst> fine try 2 from quantal itself
<mlankhorst> looks like virtualbox hates me today
<RAOF> Sarvatt: Ah. The "make the server admin hate you" application :)
<mlankhorst> vbox is only mildly slow
<mlankhorst> blah
<mlankhorst> cd panics on me
<mlankhorst> virtualbox from quantal
<RAOF> Hm. Seems to work fine in kvm, too.
<mlankhorst> second try starts normally
<mlankhorst> I'm just going to pretend I didn't see a kernel panic
<cjwatson> :)
<mlankhorst> same  thing happening here though
<cjwatson> The realloc crash?
<mlankhorst> well hitting failsafe-mode but really too tired to look atm, i dont think its a regression though, just something that wasn't hit before
<cjwatson> OK; thanks for the investigation, at present I'm minded to not let this block
<Sarvatt> downgrading libpciaccess just gives me the black screen and [   206.226] (II) VESA(0): VESA BIOS not detected this "fixed", not even failsafe
<bryce> cjwatson, thanks.  should the issue get mentioned in some release notes maybe?
<cjwatson> I would welcome an X developer writing an appropriate note in https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure
<mlankhorst> << dlrrp
<bryce> on it
<GeoffCh> This sounds like a problem I used to run into sometimes on previous distros, not in a VM but on a couple of different laptops.  I found that if I clicked on "Try Ubuntu" it would sometimes hang, but if I closed the window by clicking on (X), I would get back to an X session every time.
<bryce> Sometimes enters failsafe-x mode when booting into Live Session in virtualbox.  (LP: #1124660)
<ubottu> Launchpad bug 1124660 in xorg (Ubuntu) "Precise 20120213 i386 live session fails in virtualbox" [Undecided,New] https://launchpad.net/bugs/1124660
<bryce> more to say than that?
<mlankhorst> what if you try libpciaccess from quantal?
<Sarvatt> bryce: on i386 only, can be worked around by using amd64?
<bryce> Sarvatt, ok
<Sarvatt> mlankhorst: trying that now
<bryce> alrighty, done.
<Sarvatt> mlankhorst: that works!
<Sarvatt> http://cgit.freedesktop.org/xorg/lib/libpciaccess/patch/?id=a798395a1bfd9d06d40e2d8d14377a156c94429a ...?
<cjwatson> bryce: Well, the problem is also that failsafe-X mode doesn't work, AIUI from the bug
<mlankhorst> Sarvatt: sounds likely
<Sarvatt> thats it
<Sarvatt> with that commit added it works again
<cjwatson> Sounds possibly lucky that amd64 works
<bryce> cjwatson, ah right
<cjwatson> OK, let's have that patch for 12.04.3 then, thanks :)
<Sarvatt> SRU after, if someone installs with updates checked it'll pull it in and work after boot?
<mlankhorst> or maybe its reallocating SOMEONE ELSE's allocation
<Sarvatt> alrighty!
<mlankhorst> ;P
<cjwatson> Sarvatt: I'm not in much of a panic about virtualbox not working - dailies aren't a terrible option there
 * Sarvatt nods
<cjwatson> The main value is helping our own testers
<Sarvatt> really sorry for all the trouble here
<cjwatson> But I think they might actually crucify me if I respun at this point for only that :)
<cjwatson> Don't worry, it doesn't look like you broke anything
<mlankhorst> morning
<user12423> I have read that ubuntu 12.04.2 comes with kernel 3.5. Will it work with proprietary ati drivers for radeon 4000 series as they are not compatible with quantal?
<mlankhorst> if you use the old xserver/kernel sure
<mlankhorst> which is what you keep if you upgrade from 12.04.1 to 12.04.2
<user12423> mlankhorst: just old xorg or kernel too?
<mlankhorst> the combination old xserver + new kernel is unsupported
<mlankhorst> it will probably work, but it may set your cat on fire
<user12423> mlankhorst: so that means I just have to work with kernel 3.2. Probably but the kittens will extinguish it 
<mlankhorst> lets hope so :)
<user12423> mlankhorst: yeah :)
<user12423> mlankhorst: amd did a update to its legacy drivers to version 13.1. Do they work with 3.5 and new xorg?
<starks> mlankhorst, prime helpers have landed in drm-next.
<mlankhorst> starks: ah, still not that useful
<starks> needs fencing?
<mlankhorst> doesn't actually do anything
<mlankhorst> at least not what I care about
<starks> can nvidia release a driver against 3.9?
<mlankhorst> makes me wonder why nvidia cares though
<mlankhorst> I'm not nvidia
<tjaalton> what was the metapackage that reverts to the original precise stack?
<tjaalton> xserver-xorg-lts-precise?
<tjaalton> that was it
<mlankhorst> step 4 is unneeded
<mlankhorst> we use autobind patch for now
#ubuntu-x 2013-02-15
<tjaalton> pushed xserver rc2 to staging
<mlankhorst> yay
<tjaalton> ftbfs :)
<tjaalton> built locally, new mesa messed things up I guess
<tjaalton> or a dependency missing
<tjaalton> Package 'xcb-dri2', required by 'gl', not found
<tjaalton> so maybe I'll update mesa too, meh
<Azelphur> Got a friend who's trying to run TF2 on xubuntu with a 7950,  on fglrx-updates it won't start at all, on the latest drivers (--buildpkg quantal) it works, but gets a poor frame rate, any ideas?
<tjaalton> not without some sort of a log
<bjsnider> talk to amd
<Azelphur> tjaalton: what log would you be after?
<Azelphur> and where exactly would we talk to AMD?
<tjaalton> xorg log?
<tjaalton> guess it's not installed right
<tjaalton> "won't start at all" doesn't say anything
<Azelphur> tjaalton: https://github.com/ValveSoftware/steam-for-linux/issues/688 we're pretty sure it's this one
<Azelphur> we get the exact same opengl messages, etc.
<Azelphur> at least, we did on fglrx-updates, on the latest AMD drivers it starts, but with bad performance
<Azelphur> we can get xorg logs though, downgrade to fglrx-updates and replicate the issue.
<Azelphur> tjaalton: http://paste.ubuntu.com/1659634 here is the xorg.log for our current setup (drivers from the amd website with --buildpkg)
<bjsnider> i don't see any problem there. what about glxinfo?
<tjaalton> Azelphur: ok, no idea then
<Azelphur> bjsnider: http://paste.ubuntu.com/1659807/
<bjsnider> yeah, no problems there
<bjsnider> it's almost certainly nothing you're doing that's causing the frame rate problem
<Azelphur> fun
<Azelphur> on Windows he gets like 100-200 FPS on all max settings
<Azelphur> while on Ubuntu he gets 15-100 on low
<Azelphur> so something is up, maybe a post on the AMD forums would be appropriate
<Azelphur> could try edgers just for the hell of it
<tjaalton> it can only break things
<Azelphur> really? I've had loads of issues get un-broken by switching to edgers xD
<Azelphur> edgers fixes things sometimes :)
<tjaalton> won't help with the blob
<Azelphur> try, but can't it be some sort of X issue causing this?
<tjaalton> no
 * Azelphur shrugs
#ubuntu-x 2013-02-17
<a5m0> hi i'm running the xorg-edgers ppa on my xubuntu laptop and it seems that the 3.7 kernel that it's installing is causing a crash/panic whenever i plug in the power brick, i've searched around but it seems like this was an issue that was already fixed in previous kernels, anyone know of a fix?
<tomreyn> a5m0: do you have acpi errors on boot?
<a5m0> no errors on boot that i have seen, only when i plug the already running laptop into wall power
<a5m0> the kernel panics/freezes
<tomreyn> then i dont know, other than suggesting you try mainline
<tomreyn> a5m0: i'm not sure which ubuntu version you're on, though. quantal xorg-edgers has  linux 3.8.0-6.11 since feb 11
<a5m0> uname -a says 3.7.0-7 generic, but i'm on xubuntu with xorg-edgers
<a5m0> 12.10 
<tomreyn> a5m0: you're right, i actually have the same, and the 3.7 kernel, too
<tomreyn> https://launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=quantal lists  linux_3.8.0-6.11 so I was mislead
<tomreyn> a5m0: i had some ACPI issues with the 3.7 kernel, that's why i checked with ricotz + sarvatt whether they could provide a newer one, but i think they ran into dependency hell.
<a5m0> :/ wonder if i should downgrade or if it will ever get fixed
<a5m0> it didn't always do this
<tomreyn> downgrading has always been a pain for me. ppa-purge never worked properly.
<tomreyn> why not try mainline?
<a5m0> wouldn't i have to purge to go to mainline?
<a5m0> how do you suggest i switch to mainline?
<tomreyn> you just need to add the repository
<tomreyn> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<tomreyn> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<tomreyn> read this before you do: http://askubuntu.com/questions/162616/should-i-upgrade-to-the-mainline-kernels
<a5m0> "They will often break drivers" doesn't that defeat the purpose of using xorg edgers?
<a5m0> i thought that xorg-edgers releases their own kernels because it had drivers in them
<tomreyn> i think this warning is primarily about proprietary drivers
<a5m0> ok well i'll try it then
<a5m0> i'm using intel hd4000
<tomreyn> the good thing bout mainline is that you can easily switch between that and the other kernel you have
<tomreyn> also you can easily remove it
<a5m0> i tried sudo apt-add-repository ppa:kernel-ppa/ppa but apt-get gives me a 404, is there a newer one?
<tomreyn> ppa:kernel-ppa should work
<a5m0> W: Failed to fetch http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu/dists/quantal/main/binary-amd64/Packages  404  Not Found
<tomreyn> sorry, i was wrong. this is how to do it: http://askubuntu.com/questions/65661/i-was-told-on-launchpad-to-test-a-mainline-kernel-how-do-i-do-that-with-nvidia
<a5m0> so it has to be done manually every time?
<tomreyn> i guess. i haven't done it in a while
<tomreyn> https://github.com/medigeek/kmp-downloader
<tomreyn> this should help automating it to a sufficient degree.
<a5m0> cool, thanks for the info tomreyn 
<tomreyn> you're welcome
<mlankhorst> bryce: in london?
#ubuntu-x 2014-02-10
<tjaalton> new intel release
<mdeslaur> man, I hadn't updated my trusty laptop in a week or so
<mdeslaur> are the massive graphical corruption issues with intel known at the moment?
<mlankhorst> mdeslaur: yeah in fact
<tjaalton> upgrade
<tjaalton> .910 fixes it
<tjaalton> uploaded earlier today
<mdeslaur> ah, great, thank mlankhorst, tjaalton
<mdeslaur> good thing I didn't gouge my eyes out with a fork after all
#ubuntu-x 2014-02-11
<tjaalton> mlankhorst: pushed xorg merge btw
<tjaalton> pull that before you add the meta stuff
<jcristau> do you guys have a qxl driver that builds on i386?
<tjaalton> looks like it
<tjaalton> https://launchpad.net/ubuntu/trusty/+source/xserver-xorg-video-qxl/0.1.1-0ubuntu3
<jcristau> eww
<jcristau> uploaded as a native package?
<mlankhorst> it would appear so, even if I add the orig.tar.gz it uploads as native
<tjaalton> oh, hehe
<mlankhorst> sometimes it's best not to think about it too hard
 * jcristau doesn't understand why yours builds and ours doesn't
<mlankhorst> tjaalton: fwiw, I pushed the old packages separately, it's easier because I need a 3: epoch
<tjaalton> epoch?
<tjaalton> why does it need an epoch bump?
<tjaalton> it's forever
<mlankhorst> tjaalton: to be newer than all versions in precise
<mlankhorst> for all packages
<mlankhorst> xorg  doesn't need it, but oldxorg (transitional packages) is 3:1
<tjaalton> ok
<tjaalton> so the only way to avoid it would have been to keep the lts source separate?
<tjaalton> hmm no
<jarkko_> any idea when new mesa is going to pushed?
<tjaalton> latest stable is in trusty
#ubuntu-x 2014-02-12
<SpartanS63> Does anyone know how to get a second monitor working with nvidia-prime?
<SpartanS63> Anyone here able to offer support with Nvidia Optimus laptops?
<SpartanS63> Anyone have any experience with multiple monitors on Nvidia Optimus laptops?
#ubuntu-x 2014-02-13
<RAOF> mlankhorst: I couldn't find your mesa 10.1 branch, but egl-platform-mir in my github branch is up to date; you should be able to drop âgit diff egl-platform-mir-upstream-base..egl-platform-mirâ in as a patch.
<tjaalton> RAOF: it's ubuntu+1
<tjaalton> patch updated too
<mlankhorst> RAOF: ubuntu+1
<ricotz> mlankhorst, hi, the xserver build picked up the wrong gcrypt again?
<mlankhorst> no
<mlankhorst> at least not after the other rebuild..
<mlankhorst> the ubuntu5 one, probably
<ricotz> mlankhorst, hmm, yeah ubuntu5 depends on libgcrypt20 but ubuntu6 doesnt
<ricotz> depends on which gcrypt is the wrong one ;), i assumed libgcrypt20 is the wanted one
<mlankhorst> no that's in universe
#ubuntu-x 2014-02-14
<mdeslaur> I there a way to power down the nvidia card that I'm not using in my asus ux32vd?
<mdeslaur> bbswitch?
<Sarvatt> afaik it should power down automatically with nouveau on 3.13+ until you use DRI_PRIME=1
<Sarvatt> if you don't have something plugged into a hdmi or dp port thats only hooked up to nouveau keeping it awake
<Sarvatt> mdeslaur: sorry, shoulda pinged you since it was a delayed response :)
<mdeslaur> Sarvatt: oh! interesting...so no bbswitch necessary anymore?
<Sarvatt> yeah they added runtime pm support to nouveau in 3.13, bbswitch would be needed if you use the blob
<mdeslaur> Sarvatt: awesome, thanks!
#ubuntu-x 2015-02-09
<hyperair> Sarvatt_: hey did you ever reproduce the kernel lockup i mentioned?
<hyperair> aaaaaaaaaaaaaaaaaaaaaaaargh
<hyperair> now all i have to do is swing around in slic3r's 3d view and my kernel hangs
<hyperair> this is bullshit
<Noskcaj> What are the current plans with wayland 1.6.93 packaging?
<tjaalton> 1.7 will be released later this week
<tjaalton> might just as well jump straight to that
<Noskcaj> tjaalton, cool. I've got it packaged as part of ppa:ubuntu-gnome-packaging/shell-3.16, but i'm sure it's better for the x team to do the work
#ubuntu-x 2015-02-13
<tjaalton> ooh, git support in lp
<tjaalton> coming up
 * ogra_ waits for the bzr support on github
<tjaalton> hah
#ubuntu-x 2016-02-16
<soee> nvidia-settings package shouldn't be in version sync with driver ? 
<mamarley> soee: What is out-of-sync?  I think we have 361.28 uploaded for all supported distros.
<soee> mamarley: no no, i'm talking about situation like this if we have installed for example driver 358 but repository contains also driver 361 than nvidia-settings 361 will be installed not 358
<mamarley> That's fine.  New nvidia-settings versions work just fine with old drivers.
<soee> ah, that explain all. thank you
<tjaalton> https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan/+packages
<soee> uh, driver 358 does not work on Xenial, just a black screen after plymouth
<soee> and now the same with 361, i broke something
<soee> mamarley: ping
#ubuntu-x 2016-02-17
<jcastro> hey mamarley and ricotz, I have some preliminary download numbers for the graphics ppa, I'll blog about it this evening
<mamarley> while true; do curl http://ppa.launchpad.net/graphics-drivers/ppa/ubuntu/pool/main/n/nvidia-graphics-drivers-361/nvidia-361_361.28-0ubuntu1~gpu16.04.1_amd64.deb > /dev/null; done
<ricotz> jcastro, nice
#ubuntu-x 2016-02-18
<gsedej> tjaalton, ipng
<gsedej> ping*
<gsedej> i am trying nvidia Vulkan PPA
<gsedej> the nvidia 355 module does not build
<gsedej> on 16.04 alpha
<tjaalton> tseliot: ^
<tjaalton> fyi, I'm about to push a new libvulkan and an actually working vkcube
<tjaalton> and then looking into packaging https://github.com/SaschaWillems/Vulkan.git
<gsedej> I first tried installing maually .run form nvidia site, but looks like some compiler error
<gsedej> there is thread on devtalk.nvidia https://devtalk.nvidia.com/default/topic/917451/255-00-26-installation-fails-on-linux-/
<gsedej> tjaalton, should I wait here or contat via email?
<tjaalton> wait
<tjaalton> no idea when it will be fixed though
<tjaalton> this is kinda a bad week
<gsedej> is it known bug?
<tjaalton> I don't know
<tjaalton> don't have nvidia
<tjaalton> but it's a beta driver in a testing ppa, so not high priority
<gsedej> i have prime, so extra trouble
<tseliot> gsedej: what kernel are you using?
<gsedej> 4.4.0-6
<tseliot> ok, let me have a look here
<gsedej> did you see my link on nvidia talk?
 * tseliot looking
<KNRO> gsedej: what link?
<KNRO> I applied the patch and 355 installs
<gsedej> i get the same error 
<gsedej> https://devtalk.nvidia.com/default/topic/917451/255-00-26-installation-fails-on-linux-/
<KNRO> yes the patch works, I just installed NVdiai 355
<KNRO> but the canonical-x 355 driver doesn't have the patch, it fails on kernel 4.4
<tseliot> whatever that is, I'll fix it
<gsedej> /var/lib/dkms/nvidia-355/355.00.26/build/nvidia/nv-procfs.c does not look pached
<KNRO> gsedej: exactly
<KNRO> gsedej: I was locked out of my system for the last hour because of that
<gsedej> can I help somehow?
<tseliot> the patch is in the packaging but it's not being applied
<KNRO> ohh okay, well, better fix that because LOTS of people are going to use that package
<tseliot> I'm on it
<gsedej> "/usr/lib/dkms/dkms_autoinstaller start" recreates original file
<KNRO> tseliot: Thanks a lot!! appreciate it! :-)
<gsedej> when can I expect fix?
<gsedej> btw, i have Optimus laptop gf940m+Haswell. Haswell does not run single demo on https://github.com/SaschaWillems/Vulkan
<tseliot> in a few minutes?
<gsedej> great
<tjaalton> gsedej: using the prebuilt binaries?
<gsedej> the ppa
<gsedej> oh
<gsedej> yes
<tjaalton> right
<tjaalton> I'll try to wrap a package
<tjaalton> see what's going on
<gsedej> i am using prebuilt binaries from SaschaWillems github
<tjaalton> yeah I tried them too
<tjaalton> didn't work
<tjaalton> new vulkan (libvulkan1, -dev) is now built, next up is new intel driver
<tjaalton> with a new name & pkg
<gsedej> is there a chance that Vulkan (intel) will be present in 16.04 LTS ?
<tjaalton> no
<tjaalton> in 16.04.2 sure
<tjaalton> with lts-y stack
<tjaalton> it's a duplicate mesa source tree, I doubt archive admins would allow that
 * ricotz sees tjaalton torn away by excitement ;)
<ricotz> tjaalton, I guess this is targeted for mesa 12?
<Cheery> W: Failed to fetch http://ppa.launchpad.net/canonical-x/vulkan/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found
<ricotz> be patient...
<tjaalton> wily.. not gonna happen
<tjaalton> ricotz: 11.3/12, yes
<ricotz> haha, right
<ricotz> ok
<Cheery> I wouldn't really care and give a shit. I'd just want drivers that don't break down when I reboot
<tjaalton> this is not the ppa you want
<Cheery> tried manual install on vulkan nvidia drivers, but they did break down when I rebooted
<Cheery> :)
<tjaalton> because the module fails to build, tseliot is on it
<Cheery> there's coming updated package when it works?
<tseliot> yes, I'm almost done
<tseliot> yes
<Cheery> where it will come?
<tseliot> any time now
<Cheery> didn't ask when. I did ask where. :)
<tseliot> my eyesight is not good today
<tseliot> same PPA
<tseliot> https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan
<Cheery> would ask whether they install to wily as well.. but I'm so much stressed out that I just keep a break anyway
<tseliot> yes, the nvidia packages should work
<tjaalton> gsedej: so the demo binaries aren't enough, they need to be put in the git repo bin/ or they won't find the shaders..
<gsedej> tjaalton, I am trying to build gl_vk_chopper now
<gsedej> I am using vulkan ppa, and also downloaded VulkanSDK from lunarg
<gsedej> I am not able to install .deb in the sdk installer
<gsedej> is this ok?
<tjaalton> dunno
<gsedej> dpkg: error processing archive vulkan-loader_1.0.3.1_amd64.deb (--install):
<gsedej>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libvulkan.so.1.0.3', which is also in package libvulkan1 1.0.3~git20160215-0.1
<gsedej> (and so on)
<tjaalton> so they ship their own libvulkan, nice
<tjaalton> don't install the ppa version then
<tjaalton> or the other way around
<Cheery> can you batsignal or smt. when I can try the driver install again?
<gsedej> like the ppa better
<tseliot> nvidia is fixed now. Please give it some time to build in the PPA
<gsedej> if i don't need sdk
<gsedej> tseliot, thanks! i will try it
<gsedej> trynig to build chopper i get error .../lib/libAntTweakBar.a(LoadOGLCore.o):(.data.rel+0x618): undefined reference to `glCullFace'
<gsedej> (many of such)
<gsedej> tseliot, why 2 " nvidia-graphics-drivers-355 "
<Cheery> tseliot: they seem to have appeared there now
<tseliot> one for trusty, one for xenial
<Cheery> none for wily
<tseliot> nope. Either should work in wily though
<Cheery> how do I DL it from here?
<gsedej> tseliot, 2 for xenial http://imgur.com/lT5fnOy
<tseliot> different revisions
<tseliot> 355.00.26-0ubuntu1~vulkan16.04.2 is newer than 355.00.26-0ubuntu1~vulkan16.04.1
<tseliot> wait until the former builds, and there won't be any ambiguity
<Cheery> oh it's still building.
<gsedej> Cheery, were you able tu apt-get upgrade? 
<gsedej> ok
<Kano> hi, why is libpng in the vulkan ppa?
<Kano> btw. i wanted to compile mesa anv but got an error
<Kano> https://paste.debian.net/396735/
<tjaalton> because vkcube needs libpng16
<tjaalton> (not there yet)
<Kano> ok, i dont need vkcube
<Kano> but whats the problem with mesa?
<tjaalton> i don't know, builds here
<Kano> why is vulkaninfo in a lib package? thats wrong
<tjaalton> it just is
<tjaalton> things are in flux
<Kano> somehow vulkaninfo does not work here
<Kano> i used the prebuild one form lunarg sdk first
<Kano> and that worked
<gsedej> and idea why i get "undefined reference to `glCullFace'" ? 
<Kano> undefined symbol...
<Cheery> can I somehow plug non-wily ppa to wily?
<tjaalton> of course
<Cheery> how does that happen?
<tjaalton> did you run apt-add-repository?
<tjaalton> or otherwise enable it
<Cheery> I ran add-apt-repository, but it tried to get wily version of the ppa
<tjaalton> so you edit /etc/apt/sources.list.d/canonical-x-ubuntu...list and change wily to xenial
<Cheery> so I can now just get nvidia-355 and it should start working.. lets try
<Kano> tjaalton: why do you need vdpau to build vulkan?
<tjaalton> I don't, too lazy to rip everything out, feel free to do it
<tjaalton> just fyi, it's not going to be in the distro
<tjaalton> not before upstream has it
<Cheery> ok. the OS warns about a bug, but otherwise everything's all right
<Kano> well basically i wanted to build the complete mesa, but your approach is interesting
<Kano> if that works
<tjaalton> it only needs to ship the driver (with statically linked bits), json and the header
<Kano> would be nice if it would build ;)
<Kano> which gcc did you use?
<tjaalton> whatever is in xenial
<gsedej> tseliot, i instelled nvidia_355
<tseliot> good
<gsedej> but trying to use bumblebee and its missing nvidia-smi nvdida-uvm
<gsedej> any idea?
<gsedej> syslog http://pastebin.com/qaTYmuDr
<tseliot> I don't know what bumblebee is trying to do but the module should be there (look in ls /lib/modules/4.4.0-4-generic/updates/dkms/)
<gsedej> I have issue with nvidia-prime using vulkan 355.00.26 driver. 
<gsedej> after setting "prime-select nvidia", logging out, it does not log in or it has bad graphics. works with gnome-flashback-metacity but no glx
<tjaalton> gsedej: do you have other ppa's enabled?
<gsedej> something wishes to load "nvidia" kernel module, but "nvidia_355" should be loaded
<gsedej> just vulkan ppa
<tjaalton> ok
<gsedej> oh... maybe I should first full remove bumblebee since bumblbee needs special version of nvidia driver
<gsedej> but also lightdm...
<gsedej> Feb 18 18:22:14 usb-tmp lightdm[20946]: rmmod: ERROR: Module nvidia is not currently loaded
<gsedej> tjaalton, i did purge bumblbee but still problem
<gsedej> the module "nvidia" is loaded while module "nvidia" does not exist (modinfo nvidia -> not found) but shoudl be nvidia_355
<gsedej> lsmod http://paste.ubuntu.com/15117273/
<gsedej> syslog http://paste.ubuntu.com/15117308/
<gsedej> i found out that /etc/modprobe.d/nvidia-graphics-drivers.conf sets alias nvidia nvidia_355
<gsedej> so nvidia module should be ok
<gsedej> maybe nvidia-prime (nvidia's prime method not the open source one) does not support DRI3 (req for vulkan)
<gsedej> looks like nvidia-settings does work properly, just GLX doesn't
<gsedej> where could I search for problems?
<tjaalton> check xorg log
<slavik81> Is Intel on Ubuntu 14.04 going to be supported?
<slavik81> For the new vulkan drivers, I mean.
<tjaalton> not sure yet
<tjaalton> things need to settle on xenial first
<OerHeks> slavik81,  yes, the ppa gives trusty & xenial drivers
<OerHeks> https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan
<tjaalton> not intel
<tjaalton> not even the loader
<OerHeks> oh, my bad, then you would need the intel ppa
<tjaalton> huh?
<tjaalton> what intel ppa?
<OerHeks> hmm just checking https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware ..
<OerHeks> I thought they had intel drivers ready
<tjaalton> they? vulkan ppa has the intel driver but only for xenial
<tjaalton> and the pkg name will change
<slavik81> OerHeks: Unfortunately, the Intel Graphics Installer dropped support for Ubuntu 14.04 due to issues with LTS updates conflicting with their updates.
<slavik81> https://01.org/linuxgraphics/forum/graphics-installer-discussions/do-not-use-ubuntu-14.04
<tjaalton> that has nothing to do with vulkan though
<OerHeks> I would wait 2 months for xenial release.
<slavik81> I would wait, but I'm impatient and it's reading week so I have time. If the missing pieces are just packaging, I may instead try to build from source.
<slavik81> Maybe if I succeed and learn something I can contribute back.
<slavik81> Or maybe I'll fail miserably and wait for xenial. We'll see, I guess.
<gsedej> glxinfo gives me error:  libGL failed to load swrast 
<gsedej> X Error of failed request:  GLXBadContext
<gsedej> how to get more info?
<gsedej> does xorg.0.log look ok? http://paste.ubuntu.com/15122026/ 
<gsedej> if someone can check
<tjaalton> looks normal to me
<gsedej> i am not in "video" group. trying now...
<tjaalton> you don't need to be...
<gsedej> darn... what else could go wrong
<gsedej> there are some issues in syslong
<gsedej> syslog
<gsedej> http://paste.ubuntu.com/15117308/
<tjaalton> broken package I guess
<gsedej> nvidia's?
<tjaalton> yes
<gsedej> how to add nvidia-bug-report.log.gz on nvidia forum?
<tjaalton> best to wait for tseliot to confirm if it's a packaging issue
<slavik81> Thanks for the help, btw. I appreciate it.
<gsedej> tjaalton, tseliot, here is text I intent to post on nvidia-forums  http://paste.ubuntu.com/15126342/
<gsedej> I will post it if it's not packiginig issue
#ubuntu-x 2016-02-19
<gsedej_work> tseliot, nvidia-355.00.26 probably have nvidia-prime bug
<gsedej_work> I am planing to report bug on nvidia forums
<gsedej_work> tjaalton, warned me to contact you first
<gsedej_work> here is text I plan to post http://paste.ubuntu.com/15126342/
<gsedej_work> another thing
<gsedej_work> I am missing /usr/lib/xprg/modules/drivers/nvidia_drv.so
<Sarvatt> gsedej_work: first step would be sudo apt-get purge the driver, then install it again. from what i saw in the scrollback your alternatives are screwed up and they'd get fixed reinstalling that way
<tseliot> gsedej_work: the logs look good to me. What does "ldconfig -p | grep GL" say?
<gsedej_work> a second ago I purged
<gsedej_work> i will install again and report
<gsedej_work> btw, Haswell gpu segfaults even at vulkantri
<gsedej_work> (GPU HANG: ecode .... readon : Ring hung
<gsedej_work> tseliot, which packages do I need to install among nvidia-355?
<tseliot> gsedej_work: nvidia-355
<tseliot> that's it
<gsedej_work> hmm, looks like it installs evrything
<tseliot> yes, it will pull its dependencies
<tseliot> that's expected
<gsedej_work> nvidia optimus solution is so problematic on linux... bumblebee guys are doing great work though
<tseliot> things will get better
<gsedej_work> tseliot, Sarvatt purge and reinstall DID work! even vulkancube works
<gsedej_work> sorry for so much trouble
<tseliot> good :)
<gsedej_work> but glmark2 segfaults :D
<gsedej_work> Unigine valley also runs
<gsedej_work> so it's glmark2's problem
<Sarvatt> gsedej: good to hear its working at least, you might not want to use vulkan specific testing drivers if you want full functionality though :D
<gsedej> there is only one nvidia driver for vulkan
<tjaalton> and it's beta
<gsedej> are there some binareis for vulkan-chopper-demo? I was not able to complile it
<tjaalton> no
<tjaalton> I'm done with vulkan for now :)
<gsedej> no chopper in ppa? :P
<tjaalton> no
<gsedej> i have issue with dependency on 16.04 daily, where should I ask (libtinfo5:i386 breaks libtinfo5 on 64b)
<tjaalton> mirror not uptodate?
<kumikumi> what could be the problem, when on a fresh xenial installation, after adding ubuntu-x ppa, no package nvidia-graphics-drivers-355 is found?
<kumikumi> also, the package 'vulkan' can not be found.
<kumikumi> the PPA I was trying to add is ppa:canonical-x/vulkan
<kumikumi> Any suggestions to solve this are welcome, I'm feeling like I'm missing something extremely obvious
<kumikumi> Ive already tried apt-get update and rebooting
<tjaalton> there is no package called "vulkan"
<tjaalton> and there's nothing for wily
<kumikumi> then what are those if not packages? they are listed on this page https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan
<kumikumi> under "overview of published packages"
<tjaalton> source pkg != binary
<tjaalton> read the description
<kumikumi> running the exact commands on the description yields 'unable to locate package vkcube'
<tjaalton> that failed to build
<tjaalton> and I failed to push the fixed version
#ubuntu-x 2016-02-20
<kumikumi> so, how to install the proprietary nvidia driver?
<tjaalton> last I heard it was buggy
<tjaalton> but, install as usual
<tjaalton> apt install nvidia-355
<kumikumi> ok thanks
<kumikumi> there's some dependency issues..
<tjaalton> go on..
<kumikumi> Depends: lib32gcc1 but it is not going to be installed
<tjaalton> apt -f install
<tjaalton> or not
<tjaalton> it should install on trusty or xenial
<kumikumi> I agree
<tjaalton> but tbh, there's nothing of interest
<kumikumi> vulkan demos are not working?
<tjaalton> you could see a cube spinning and a triangle
<tjaalton> that's all
<tjaalton> the loader lib will get into 1604
<kumikumi> cube and triangle sounds exciting
<tjaalton> vkcube should build now
<kumikumi> anyway, lib32gcc1 : Depends: gcc-6-base (= 6-20160210-0ubuntu2) but 6-20160217-0ubuntu1 is to be installed
<kumikumi> any idea what's causing it or how to work around/resolve this issue?
<tjaalton> no idea nor do I care
<tjaalton> you should be running xenial
<kumikumi> I am
<kumikumi> this is a fresh xenial installation
<tjaalton> still 2am saturday morning
<kumikumi> no problem :) thanks for your help
<tjaalton> i've only got hw for the intel driver and it works
<kumikumi> tjaalton: for your information, I just did a new clean installation of xenial, ran apt-get update && apt-get upgrade, then ran the 3 commands in the PPA description, still package vkcube not found
<kumikumi> also, trying to install nvidia-355 package fails due to dependency issues
<kumikumi> Depends: lib32gcc1 but it is not going to be installed
<kumikumi> Depends: libc6-i386 but it is not going to be installed
<bitshifter> Hi, I was wondering if there will be Wiley builds of ppa:canonical-x/vulcan at some point?
<tjaalton> bitshifter: no
<bitshifter> tjaalton: how come?
<tjaalton> because 1604 is close enough
<bitshifter> hmm, how stable is it right now? :)
<tjaalton> stable enough for vulkan
<bitshifter> ok, thanks for the info!
<tjaalton> kumikumi: some temporary fail with xenial then
<kumikumi> bitshifter: don't expect it to work right now, at least with Nvidia
<kumikumi> Vulkan works! (I only had to compile the nvidia driver myself, and I had to patch the driver before it would compile; http://www.linuxquestions.org/questions/showthread.php?p=5501135 )
<gsedej> /usr/include/vulkan/vulkan.h:2924:5: error: âint32_tâ has not been declared
<gsedej> any idea?
<kumikumi> what are you trying to do?
<caps> there is probably something wrong with my system but after adding ppa:canonical-x/vulkan the packages vkcube, vulkan-utils and mesa-vulkan-drivers do not exist
<caps> how can i debug this? (i'm not very familiar with linux)
<kumikumi> caps: I had the exact same problem yesterday
<caps> well actually now that i look 
<caps> W: Failed to fetch http://ppa.launchpad.net/canonical-x/vulkan/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found
<kumikumi> caps: ok you should update to xenial
<caps> same with i386
<caps> oh
<caps> is that another ppa or somethign?
<kumikumi> but even xenial does not work perfectly right now, there's also problems with the packages
<kumikumi> xenial = ubuntu 16.04
<kumikumi> caps: do you have nvidia or intel gpu?
<caps> intel
<caps> i'm on a laptop
<kumikumi> ok I think you should install xenial and then try the PPA again
<caps> okay thanks
<kumikumi> np
<gsedej> kumikumi, trying to build gl_vk_threaded_cadscene
<gsedej> i somehow build gl_vk_chopper but it segfaults
<gsedej> has someone yet succeded building nvidia demos?
<kumikumi> I managed to build some demos, and approximately 50% of them worked and 50% segfaulted
<gsedej> kumikumi,  would you mind writing how to? http://askubuntu.com/questions/737044/building-vulkan-chopper-demo-on-ubuntu
<tjaalton> kumikumi: problems other than the nvidia driver?
<tjaalton> with packages
<kumikumi> tjaalton: at least the vkcube package exists now
<kumikumi> (it doesn't run, though, because it can't find libpng16.so.16)
<kumikumi> gsedej: I said I had success running _some_ vulkan demos, not the helicopter one
<kumikumi> I'd also be interested in how to build the helicopter demo
<tjaalton> what
<bigpet> I have to be the 500th person to ask but when I try to get the vulkan test stuff I get: 
<bigpet> W: Failed to fetch http://ppa.launchpad.net/canonical-x/vulkan/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found
<bigpet> what gives?
<tjaalton> there are no packages for wily, read the ppa description
<tjaalton> kumikumi: ah hell, next upload should fix vkcube I hope
<bigpet> I tried to apply the wadsworth constant to that description
<bigpet> but it seems like that wasn't a good idea in this case :P
<tjaalton> had to look that up..
<bigpet> K,got it working thx
<bigpet> Was just thrown for a loop because in 16.04 I didn't seem to have a xorg.conf or a xorg.conf.d
<bigpet> Was just thrown for a loop because in 16.04 I didn't seem to have a xorg.conf or a xorg.conf.d
<bigpet> So I just created a xorg.conf and it seemed to load fine
<bigpet> Sorry for that
<bigpet> Buggy ass irc client
<kumikumi> tjaalton: vkcube : Depends: libpng16-16 (>= 1.6.2-1) but it is not installable
<kumikumi> (has no installation candidate)
#ubuntu-x 2016-02-21
<marlinc> Anyone who has the following issue? https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/1542757
<ubottu> Launchpad bug 1542757 in mtr (Ubuntu) "mtr no longer works as regular user: mtr: unable to get raw sockets." [Undecided,New]
<tjaalton> kumikumi: do you have universe enabled? https://launchpad.net/ubuntu/+source/libpng1.6/1.6.20-2
<silven> Hello, I want to try out some Vulkan demos, but cant find any info on how to enable DRI3, anyone got any pointers?
<silven> I've got no xorg.conf
<tjaalton> man intel
<tjaalton> or remove it. read the ppa description
<kumikumi> tjaalton: thanks, it worked
<kumikumi> (adding universe repository)
#ubuntu-x 2017-02-13
 * mamarley mutters about people asking questions and then running off before anyone has a chance to answerâ¦
<ricotz> tjaalton, huh? http://www.omgubuntu.co.uk/2017/02/install-mesa-13-0-4-on-ubuntu-ppa
<tjaalton> ricotz: huh what? it's there as you know :)
<ricotz> tjaalton, I had the impression this is the staging part before moving it to gpu ppa
<tjaalton> ricotz: it can still be
<ricotz> if so then promoting it that way is misleading
<tjaalton> I didn't write that article, only the blog post
<tjaalton> which has had a whopping 30 hits
<ricotz> I know, I was indirectly referring to it, but obviously it is looked at and has impact
<tjaalton> i'm sure he'll write another one when the move happens
<tjaalton> so I'm looking at nvidia changes to support libglvnd
<tjaalton> why does it install stuff in /usr/lib32?
<tjaalton> is the git repo used?
<tjaalton> last commit is from 4y ago
<tjaalton> HEAD points to master, which is obsolete
<tjaalton> tseliot: hi, I'm checking nvidia for changes needed to support libglvnd
<tjaalton> should be pretty simple
<tjaalton> can drop lib{GL,GLES*,EGL}.so.* and just ship the _nvidia.so's
<tseliot> tjaalton: I need to check that how things would work with hybrid graphics, and then I would have to update gpu-manager accordinglu
<tseliot> *accordingly
<tjaalton> sure
<tjaalton> I also noticed that at least preinst scripts have a lot of old cruft in them
<tjaalton> also, why doesn't it use multiarch directories but /usr/lib32?
<tseliot> I think there was a reason for that but I can't remember
<tjaalton> heh
#ubuntu-x 2017-02-14
<ricotz> mamarley, hi, are you looking at 378.13?
<mamarley> ricotz: Yes. :)
<ricotz> mamarley, thanks :)
<mamarley> Should be ready later today.
<mamarley> I was hoping tseliot's 4.10 patch would be ready in time for this, but I guess not.  Maybe we got lucky and official 4.10 support is added.
<tseliot> mamarley: if it's not there, I have a patch that builds. Tomorrow I'll test and upload (for 375 at least)
<ricotz> yeah, that would be nice to work out-of-box by now
<mamarley> tseliot: If you send me the patch I can test it on 378 too.
<mamarley> (Assuming no OOB support.)
<tseliot> mamarley: right, let's talk about it again tomorrow, though. I want to test it on my computers first.
<mamarley> OK
<tseliot> as I think I got the cpu hotplug stuff right, but I want to be sure
<mamarley> OK
<ricotz> is there a 375.39 too?
<ricotz> of course there is
<ricotz> tseliot, ^
<tseliot> ricotz: it's a new 375 release, it's all I can say ;)
<ricotz> tseliot, it is already public, so no secrecy needed ;)
<tseliot> where?
<ricotz> http://us.download.nvidia.com/XFree86/Linux-x86/375.39/NVIDIA-Linux-x86-375.39.run
<tseliot> I didn't see anything new here http://www.nvidia.com/object/unix.html
<ricotz> http://www.nvidia.com/download/driverResults.aspx/114708/en-us
<ricotz> tseliot, I guess you could push your zesty package to the ppa
<tseliot> ricotz: I am going to upload to zesty directly, and then it will hit the supported Ubuntu releases 
<ricotz> tseliot, I meant today
<tseliot> in due time (we have testing procedures)
<tseliot> it's EOD, and I'm about to go offline
<ricotz> or do you want to push it now to the archive?
<ricotz> that is why I said to the ppa so we can push the backports
<tseliot> tomorrow ;)
<ricotz> then there will be another tarball in the ppa
<tseliot> I'll re-use your tarball, no problem
<ricotz> another/different
<ricotz> alright
<tseliot> have a nice rest of the day, guys
<ricotz> bye :)
<soee> NVIDIA 378.13 Linux Driver Released
<soee> mamarley: ^ :D
<mamarley> ricotz: soee: 378.13 and 340.102 are up in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<mamarley> Sadly, neither driver added full support for 4.10, though both made (differentâ½) changes that reduced the sizes of their respective patches.  The 4.10 patches are included, but not enabled in dkms.conf due to the hacked-out CPU hotplugging support.  Once tseliot comes up with a proper patch, I will add that and enable it.
<soee> NVIDIA 375.39 Linux Driver Released
<soee> :D
<mamarley> I think ricotz was working on that one.
<soee> i'm on kernel 4.9 atm. so they should work
<ricotz> and 304.135
<mamarley> When it rains, it poursâ¦
<ricotz> all with xserver 1.19 support
<mamarley> 340.101 and 304.134 also had 1.19 support.  They just forgot to update the changelog for these new releases; it is exactly the same as the previous ones.
<ricotz> correct
<soee> bit 16.04 does not have 1.19 :(
<mamarley> Neither does 17.04, yet.
<mamarley> I think it is in x-staging though.
<ricotz> mamarley, did you resync the 378 packaging with the current 375?
<mamarley> No, I didn't think there had been any changes.  Let me check that again.
<ricotz> there are some the 375.39 packages are synced
<mamarley> Great, now I have to do that over again.
<soee> hmm http://pastebin.com/BY124p74
<soee> mamarley: http://pastebin.com/BY124p74
<mamarley> soee: I'm not sure I see the problem there.  It looks like it is just trying to remove the old -375 packages, which is to be expected.
<mamarley> ricotz: Can you tell me which changes you made so I don't have to rebase it again?
<mamarley> Launchpad isn't being very helpful with the diffs.
 * soee reboot
<ricotz> mamarley, the diff won't be really helpful
<ricotz> download the 375 ppa package
<mamarley> Is this just for Zesty?
<soee> first reboot faled
<soee> fter plymouth on second attemt i had something like "faile to set xfermode"
<soee> is it related to driver ?
<ricotz> mamarley, xenial, yakkety and zesty are the same
<mamarley> So I can grab your Zesty 375 package, update it to 378 again, and use that for Zesty, Yakkety, and Xenial?  (And Trusty and Precise don't need a change?)
<ricotz> mamarley, afaics there is no diff at all between 375 and 378
<ricotz> yes
<mamarley> Basically I am trying to figure out what I need to do to bring these changes you made to 375 into 378 in a way that doesn't have me doing any pointless work.
<mamarley> OK, I think I get it now.
<ricotz> just grab the 375 and bump the changelog, control-header and done
<mamarley> For every distro version or just Zesty, Yakkety, and Xenial?
<ricotz> those three, keep the others
<mamarley> OK, got it.
<mamarley> I will do that as soon as I finish with nvidia-settings.
<mamarley> And eat dinner.  I am hungry.
<ricotz> the only change would be your 4.10 patch which is disabled so no need for it either?
<mamarley> I only left it disabled because of the CPU hotplugging hack.  But without the patch, the driver won't compile against 4.10 anyway, so maybe I should just enable it?
<mamarley> (It only applies for 4.10 and not any other kernel version, so the hack wouldn't affect other kernels.)
<ricotz> mamarley, ok
<ricotz> g2g, have fun!
<mamarley> See you later!
#ubuntu-x 2017-02-15
<ricotz> mamarley, still there?
<ricotz> mamarley, copied 340 and 378, but needed to fix 340.102-0ubuntu0~gpu17.04.2
<ricotz> tseliot, tarballs for 304, 340, 375 and 378 are in the ppa (304 soon)
<tseliot> ricotz: ok, thanks
<tseliot> ricotz: BTW do the new drivers support 4.10?
<tseliot> ricotz: never mind, 375 sure doesn't
<mamarley> ricotz: I'm sorry.  What did I mess up so I can watch out for that in the future?
<mamarley> tseliot: Nope, but curiously both the 378 and 340 releases did make changes to reduce the size of the 4.10 patches.
<mamarley> ricotz: I also have nvidia-settings, though I will need to upload the xenial package directly because of a version-number screwup I made in my staging PPA.
<ricotz> mamarley, you simply uncommented the wrong line https://launchpadlibrarian.net/306441551/nvidia-graphics-drivers-340_340.102-0ubuntu0~gpu17.04.1_340.102-0ubuntu0~gpu17.04.2.diff.gz
<mamarley> Oops, sorry.
<mamarley> Yesterday seemed to be a mistake-happy day for me.  I ended up catching most of them, but that one slipped through.
<ricotz> mamarley, what is up the nvidia-settings xenial package again?
<mamarley> My initial attempt FTBFSed because I tried to update it from the nvidia-settings package in the Xenial repository instead of the last one I had packaged.  The failure was because they changed how stripping was handled since then.  I looked at the diff between Xenial and Yakkety and discovered that the only difference was that in Yakkety and up it was compiled on more architectures, so I decided to just use the Yakkety package on Xenial too.  
<mamarley> However, I screwed up the version number by making it higher than I intended.  I deleted that upload but it still wouldn't let me upload the proper version.
<ricotz> mamarley, I see, ok
<tseliot> ricotz, mamarley: my patch for 4.10 works well. I can't really test CPU hotplug here though. At least it builds and works on my testing box
<tseliot> it's a bit of a corner case, anyway
<tseliot> all tested with my GEFORCEÂ GTX 1080 :)
<tseliot> I've also noticed that they dropped support for my laptop's GPU in the transition from 367 to 375
<mamarley> Really, which GPU is that?
<mamarley> tseliot: Is the patch available anywhere yet?
<tseliot> mamarley: I'm going to upload today, so you should be able to see all the patches soon (I have to fix up the legacy drivers too)
<mamarley> OK
<ricotz> tseliot, hmm, with your latop's gpu support, are there known plans to drop older series again aka introducing a new legacy branch?
<tseliot> ricotz: I don't think so
<tseliot> and I'm not sure what to do with the stable Ubuntu releases. If I migrate users to either 340 or to 375, somebody is still going to end up with a broken system
<tseliot> ricotz, mamarley: so the two legacy drivers support the new X ABI while 375 doesn't...
<mamarley> Reallyâ½  That's odd.
<mamarley> Are you sure?  Now that I think about it again, I'm pretty sure I ran 375 with my own build of xserver-xorg 1.19 for a while.
<tseliot> mamarley: they didn't mention the new ABI in the release notes
<mamarley> But I think it was added a few releases back.  Even for 304 and 340, the new ABI was supported in the previous release.  They just forgot to update the release notes for those.
<tseliot> mamarley: you're right: http://www.nvidia.com/Download/driverResults.aspx/111596/en-us
<tseliot> oh, and I had already added support for that in the package. My memory is really bad
<tseliot> I think they broke the ABI again, though
<mamarley> The X people did?  I know they broke it again for 1.20, but there is no point in worrying about that yet.
<tseliot> yes, no need to worry at this point, I think
<tseliot> ricotz, mamarley: I have just uploaded all the drivers in zesty. Please give it some testing. While my desktop works, my laptop is acting up (in general) with 4.10
<mamarley> tseliot: OK, I will try.  You are saying you think it is 4.10 and not the driver causing your laptop problems?
<tseliot> mamarley: yes, even the network dies
<mamarley> I have been running 4.10 on both my laptops and my desktop for a few weeks now without issues.  I'm sorry you are having problems.
<tseliot> it works fine on the desktop
<mamarley> When you say all the drivers, does that include 378 too?
<tseliot> 375, 340, and 304
<mamarley> OK.
<tseliot> i.e. all the drivers that we support in Ubuntu
#ubuntu-x 2017-02-16
<mamarley> ricotz: I reuploaded 340 and 378 with the new patches that tseliot1 wrote.
<tseliot1> mamarley: so, I assume the testing went well?
<mamarley> tseliot1: It did, everything seems to work fine. :)
<tseliot1> mamarley: cool, thanks
<tseliot1> mamarley: BTW, I think 304 from the PPA was missing a patch too
<mamarley> Yeah, I haven't done that yet.  Only so much time in a day.
<tseliot1> I know...
<ricotz> hi, there is way too few time
<ricotz> mamarley, btw, tb 52.0b3 should be there soon
<mamarley> :)
#ubuntu-x 2017-02-17
<alkisg> I'm trying to upgrade to 16.04.2 kernel/xorg in ubuntu-mate-desktop: Â sudoÂ apt-getÂ installÂ --install-recommendsÂ xserver-xorg-hwe-16.04Â  
<alkisg> The following packages will be REMOVED:
<alkisg>  ubuntu-mate-core ubuntu-mate-desktop ...
<alkisg> But I see that xserver-xorg-hwe-16.04Â  provides xserver-xorg, which mate depends on, so I'm not sure why the new stack breaks mate...
<tjaalton> and -core has almost same depends as -desktop
<alkisg> OK, this one does work without uninstalling mate: sudo apt-get install xserver-xorg-hwe-16.04 xserver-xorg-input-all-hwe-16.04
<alkisg> So maybe it can be fixed in the docs, https://wiki.ubuntu.com/Kernel/LTSEnablementStack
#ubuntu-x 2018-02-13
<ricotz> tjaalton, hi, is it possible to add missing resolution (1600x900) locally?
<ricotz> on bionic/xorg
<tjaalton> ricotz: for kms drivers via some kernel cmdline trickery
<ricotz> yes, kms it would be here
<tjaalton> wonder if this would help:
<tjaalton> commit a5e9bcad7ad0887f804905b482894b85751519fb
<tjaalton> Author: Martin Wilck <mwilck@suse.com>
<tjaalton> Date:   Tue Jan 9 20:33:09 2018 +0100
<tjaalton>     xfree86: add default modes for 16:9 and 16:10
<ricotz> looks like something which would fix this
<tjaalton> can you test?
<tjaalton> it could be proposed for 1.19.7
<tjaalton> I just sent a pull request
<tjaalton> for the OutputClass commits
<ricotz> trying
<ricotz> after building it ;)
<mamarley> tjaalton: I noticed you have uploaded an apparently glvnd-enabled mesa to bionic-proposed.  Are updated NVIDIA drivers coming soon?  What does the GPU drivers team need to do?
<tseliot> mamarley: yes
<tseliot> they are almost ready
<mamarley> Cool!
<ricotz> tjaalton, it does what I wanted :)
<tjaalton> mamarley: right, ppa:canonical-x/testing has a preliminary version, but there are at least some conflicts left and other cruft that tseliot is working on still
<tjaalton> one thing that i don't understand how fedora is handling it is that they ship libGLX_indirect.so.0 symlink in both mesa and negativo nvidia rpms
<tjaalton> without any mechanism for it that I could see
<tjaalton> ricotz: which hw btw?
<tjaalton> assuming intel with modesetting..
<ricotz> tjaalton, yes, skylake iris 540
<tjaalton> righy, so it's one of the regressions when we did the switch
<alkisg> Hi! In 18.04, will it be possible to install the nvidia drivers in a template installation that is used by many clients, without having bad effects to clients that don't have nvidia?
<alkisg> (read https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5dffbbac193aa640ffcfa0a431c21b862854e53)
<tseliot> alkisg: yes, I think so
<alkisg> tseliot: great news, thank you guys :)
<tseliot> you're welcome
<tjaalton> ricotz: https://bugs.freedesktop.org/show_bug.cgi?id=37858 might appreciate a comment :)
<ubottu> Freedesktop bug 37858 in Server/General "sandybridge GPU only supports highest resolution in 16:9 aspect" [Major,New]
<ricotz> tjaalton, looks like there was no rush at all :(
#ubuntu-x 2018-02-14
<ricotz> tjaalton, hey, capnproto is not multiarch and while libmir* depends on it is break mesa's multiarch installability
<tjaalton> ricotz: ok, it's not owned by pkg-xorg though?
<tjaalton> though it could be fixed in ubuntu
<tjaalton> a bug report showing the issue would be nice
#ubuntu-x 2018-02-15
<mamarley> glvnd
<mamarley> Oops, sorry, wrong window.
#ubuntu-x 2018-02-16
<mamarley> tseliot: I installed your glvnd nvidia-390 driver from the testing PPA and everything seems to work. :)
<tjaalton> mamarley: great!
<soee> mamarley: ping
<tseliot> mamarley: great, thanks for testing
<mamarley> soee_: pong
<mamarley> tseliot: No problem.
<mamarley> Specifically, I tested regular OpenGL, OpenGL ES, and Vulkan, though Vulkan was only with "vulkaninfo" because I don't have any "real" Vulkan applications installed.
<soee_> mamarley: on #plasma i was told what using nvidia gpu can cause high memory usage by plasmashell - can you confirm it?
<soee_> today after my PC what whoel night on, plasmashell was using trhis moring ~ 1.3GB
<mamarley> I've never seen anything like that happen on any of my systems, but I can't say definitively that it isn't because of NVIDIA.
<mamarley> When we put a GLVND-enabled 390 driver in the PPA, we are also going to need to add additional transitional packages to make sure people on the existing nvidia-390 package in the PPA get updated properly.
<tseliot> yes, that should be easy to add
#ubuntu-x 2019-02-13
<tseliot> tjaalton: hey, do I need to add "xserver-xorg-core (>= 2:1.19.6-1ubuntu2~) | xserver-xorg-core-hwe-18.04" in the xserver-xorg-video-nvidia-390 package?
<tjaalton> tseliot: why does it depend on the server?
<tjaalton> oh
<tjaalton> yes
<tjaalton> I didn't realize the drivers depend on it..
<tseliot> yes, it's the X driver
<tseliot> that would be just for bionic, right? (I assume it's just a transitional package in the other Ubuntu releases)
<tseliot> tjaalton: ^
<tjaalton> yep
<tseliot> ok, thanks
#ubuntu-x 2019-02-15
<soee> mamarley: is it possible to install driver on kwe xorg and kernel?
<soee> *hwe
<mamarley> It needs an update to change the Xorg dependency first.  I have received about 2 quadrillion emails about that.
<soee> :D
<soee> so i wont send another one 
 * mamarley is honestly a bit burned out from dealing with 4 driver serieses on 4 different distributions and dealing with lots of user email, most of which is about problems that aren't his fault and he can't fix.
<tjaalton> that bug should be fixed as of yesterday
<tjaalton> tseliot: ^
<mamarley> In the distro packages it is, but I haven't fixed it in the PPA yet.
<tjaalton> ah
<tseliot> yep
<soee> mamarley: thank you for you work. new builds work fine
<mamarley> :)
#ubuntu-x 2020-02-10
<ohcanada> hello. question related to kernel 5.4 and nvidia-340 support. i have some old quadro 170M and g210 machines which currently use nvidia-340 on bionic-hwe, kernel 5.3. will nvidia-340 continue to be supported on 20.04, after nvidia said they will no longer support 340 driver? if this is the wrong place, where do i ask? thanks [already asked in #ubuntu-kernel, sent here]
<mamarley> tseliot: tjaalton: You guys were discussing this a few days ago.^
<ohcanada> thx
<tjaalton> ohcanada: well, it's possible that the stock xserver will be upgraded to a newer version which breaks the driver abi, so when that happens the nvidia driver would get uninstalled
<ohcanada> right
<tjaalton> previously any updates have been provided as a separate HWE stack
<tjaalton> well not any updates, but backports from lts+1/2/3/4
<tjaalton> mesa is already a rolling update on lts
<ohcanada> i don't really want hew in 20.04, just nvidia-340 support for 5 years. is that too much to ask? :)
<ohcanada> *hwe
<tjaalton> renaming it as -hwe-nn.nn was just too painful
<tjaalton> well, maybe there could be a 'legacy' stack.. dunno. or an external source with the old xserver
<tjaalton> but all of this would be for a single driver
<ohcanada> a single driver that covers *lots* of legacy machines
<ohcanada> obviously i can switch to nouveau. but i kinda got used to proprietary
<ohcanada> anyways thanks for your input
<tjaalton> it's not clear yet what'll happen, maybe in 6mo
<ohcanada> roger that
<tjaalton> I'm not sure what's the feature diff these days between the blob and nouveau.. especially for older hw like that
#ubuntu-x 2020-02-12
<tjaalton> 13:56 -!- Irssi: No new messages in awaylog
<tjaalton> sigh.. damn cat
