#ubuntu-x 2007-03-12
<Ubugtu> New bug: #48974 in linux-restricted-modules-2.6.17 (restricted) ""white" gdm freeze on logout" [Low,Unconfirmed]  https://launchpad.net/bugs/48974
<tepsipakki> oh my, we have an old vesa-driver (1.2.1 vs. 1.3.0).. the new one should fix many bugs
<tepsipakki> and fedora has some patches for it which seem useful
<Mithrandir> shiny. bling. must. have.
<Mithrandir> ?
<tepsipakki> heh
<tepsipakki> one of the patches work around broken ATI video BIOSes
<tepsipakki> and one is to limit the valid modes
<tepsipakki> err, seems that we do in fact have 1.3.0
<Ubugtu> New bug: #91515 in nautilus (main) "ctrl-z makes Nautilus exit (dup-of: 23244)" [Medium,Needs info]  https://launchpad.net/bugs/91515
<Ubugtu> New bug: #91591 in xorg (main) "X server crashes on resolution change" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91591
<Ubugtu> New bug: #91603 in xorg-server (main) "Xorg crashed when opening default GNOME session (also failsafe) from GDM" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91603
<crimsun> tepsipakki: do you plan to request a sync of xserver-xorg-video-intel?
<crimsun> oh, I guess that's out of the question due to xorg-server. N/m.
<tepsipakki> it does compile with 1.2 but it needs some headers copied from the xorg-server sources..
<tepsipakki> so a sync is not possible
<crimsun> right
<Ubugtu> New bug: #91652 in xrdb (main) "reported crash on login" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91652
<Ubugtu> New bug: #91665 in mesa (main) "glxgears -iacknowledgethisisnotabenchmark patch dropped" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91665
<Ubugtu> New bug: #91307 in xorg (main) "Debconf error while apt-get dist-upgrade" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91307
<Ubugtu> New bug: #91699 in xserver-xorg-input-evdev (main) "FTBFS with current xorg headers" [High,Confirmed]  https://launchpad.net/bugs/91699
<Ubugtu> New bug: #91706 in xorg (main) "Kubuntu Feisty Herd 5: Logging out from second x-session causes garbled screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91706
<Ubugtu> New bug: #90291 in compiz (main) "Window rendering freezes sometimes with Desktop Effects (dup-of: 89870)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90291
<Ubugtu> New bug: #91586 in xorg (universe) "dual monitor (mergedfb) stopped working after update in 7.04 approx from 27 february" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91586
#ubuntu-x 2007-03-13
<Ubugtu> New bug: #91835 in xorg (main) "Samsung SyncMaster 740N monitor always detects 1024x768 as maximum resolution, when its native resolution is 1280x1024." [Undecided,Needs info]  https://launchpad.net/bugs/91835
<tepsipakki> seb128: howdy
<tepsipakki> seb128: currently -evdev fails to build, so maybe we should update it to 1.1.5. I'll do it today
<seb128> tepsipakki: hi
<seb128> did you read what I replied to pitti on #ubuntu-devel yesterday
<seb128> ?
<tepsipakki> hmm, at what time?
<tepsipakki> I was offline mostly
<tepsipakki> maybe my backlog still has it ;)
<tepsipakki> ah, found it
<tepsipakki> seb128: so you think we should just patch it?
<seb128> yep
<seb128> I was not comfortable doing the update when we did 7.2
<seb128> that's not to do it one day before beta freeze
<tepsipakki> ok
<Ubugtu> New bug: #91036 in xorg (main) "restricted-manager picks wrong BusID for video cards" [Undecided,Confirmed]  https://launchpad.net/bugs/91036
<Ubugtu> New bug: #91661 in xorg (main) "Xorg radeon driver is slower in feisty, some gtk-buttons gets scrambled" [Undecided,Needs info]  https://launchpad.net/bugs/91661
<tepsipakki> seb128: I'll prepare a new -video-vesa with a patch (hack) from fedora which makes Radeon X1400 cards to work again
<seb128> tepsipakki: ok, thank you
<tepsipakki> hmm, there are other patches in fedora for vesa.. like this one http://cvs.fedora.redhat.com/viewcvs/devel/xorg-x11-drv-vesa/vesa-1.2.1-validmode.patch?rev=1.2&view=auto
<tepsipakki> seb128: new vesa available at the usual place
<tepsipakki> it contains only one patch
<seb128> tepsipakki: k, thanks, will have a look when I'm done with GNOME 2.18
<tepsipakki> I put a new xorg as well, it reverts setting the synaptics HorizScrollDelta to zero
<tepsipakki> seb128: thanks, take your time
<tepsipakki> ogra had problems with his touchpad, so it was obviously disabled on purpose, although not mentioned on the changelog
<tepsipakki> now to the grocer's.. rest of the family is starving :) ->
<Ubugtu> New bug: #91966 in xserver-xorg-video-i810 (main) "screen artifacts after resume with i810 driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91966
<Ubugtu> New bug: #91556 in xorg (main) "Edgy and Feisty don't work with Leadtek GeForce 8800 GTS" [Undecided,Needs info]  https://launchpad.net/bugs/91556
<Ubugtu> New bug: #41616 in xserver-xorg-video-ati (main) "redraw issues" [Medium,Needs info]  https://launchpad.net/bugs/41616
<tepsipakki> seb128, kylem: seems that there is no TB meeting today, but thanks for showing up!
<seb128> np
<kylem> ah. bummer.
<Ubugtu> New bug: #91404 in xorg (main) "Screen momentarily flashes black - NVidia" [Undecided,Needs info]  https://launchpad.net/bugs/91404
<pochu> tepsipakki: #ubuntu-meeting
<pochu> tepsipakki: they are with core-devs ;)
<pochu> good luck
<tepsipakki> oh? seems quiet to me
<tepsipakki> hmm, action
<Ubugtu> New bug: #91466 in compiz (main) "Enabled Desktop Effects hides drives in "computer file browser" (dup-of: 89189)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91466
#ubuntu-x 2007-03-14
<Ubugtu> New bug: #92190 in xrdb (main) "[apport]  xrdb crashed with SIGFPE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92190
<tepsipakki> hmm, we have a couple of xrdb crashers
<Ubugtu> New bug: #19710 in xserver-xorg-video-neomagic (main) "[nm]  dpms is broken" [Medium,Needs info]  https://launchpad.net/bugs/19710
<Ubugtu> New bug: #92251 in libxft (universe) "[Remove]  Remove libxft (universe) from feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92251
<Ubugtu> New bug: #91950 in xorg (main) "Moving the windows problems." [Undecided,Needs info]  https://launchpad.net/bugs/91950
<Ubugtu> New bug: #92285 in xorg (main) "flgrx drivers unstable!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92285
<Ubugtu> New bug: #92295 in xorg (main) "md5sum: /etc/X11/xorg.conf: No such file or directory" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92295
<tepsipakki> seb128: I put xserver-xorg-input-evdev_1.1.5 on the usual place.. I looked around for a patch that would fix the FTBFS but couldn't find one. Fedora has 1.1.2 with one patch which looks identical to the one Debian has (10-bitfield-fixes.patch)
<tepsipakki> I also informed pitti about it
<tepsipakki> (via the bugreport)
<tepsipakki> which is bug #91699
<Ubugtu> Malone bug 91699 in xserver-xorg-input-evdev "FTBFS with current xorg headers" [High,Confirmed]  https://launchpad.net/bugs/91699
<tepsipakki> so, the big change in 1.1.3 was the merge of input-hotplug, but that's what 7.2 is all about (xorg-server 1.2)
<tepsipakki> :)
<tepsipakki> tv ->
<seb128> tepsipakki: I'm not going to upload 1.1.5 one day before the freeze
<tepsipakki> I understand completely
<tepsipakki> but it's there
<tepsipakki> for people to test
<seb128> ok
<seb128> I'll have a look on the vesa update before freeze though
<tepsipakki> thanks
<tepsipakki> about evdev: there aren't many commits on git since 1.1.5 was released three months ago :)
<tepsipakki> but I'll build a binary for people to test
<tepsipakki> and maybe it's good for upload post-beta
<tepsipakki> ooh, [ANNOUNCE]  xserver 1.2.99.902, [ANNOUNCE]  xf86-video-intel-1.9.92
<tepsipakki> more crack to test
* pochu wants that!! :)
<pochu> I'll be glad to test it :)
<tepsipakki> Anholt replied to my post on xorg-list that this intel-driver should be better with recognizing the monitor
<pochu> tepsipakki: does that mean that the driver will detect my screen resolution, and that stuff?
<tepsipakki> maybe
<tepsipakki> seems that some of the intelligence is in the server now
<pochu> that would be wonderful :)
<tepsipakki> looking at the changes
<pochu> though it already does it :)
<pochu> though it doesn't work perfectly
<pochu> tepsipakki: if u are going to build them, can you please give me a link, to test them? :)
<tepsipakki> sure
<pochu> ty :)
<Ubugtu> New bug: #92335 in debconf (main) "Debconf ask for process priority during install (dup-of: 68267)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92335
<Ubugtu> New bug: #92373 in mesa (main) "LibGL error" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92373
<pochu> tepsipakki: please, ping me once you have built the driver :)
<Ubugtu> New bug: #41349 in xserver-xorg-video-via (main) "GLX failure: couldn't get an RGB, Double-buffered visual" [Medium,Needs info]  https://launchpad.net/bugs/41349
#ubuntu-x 2007-03-15
<Ubugtu> New bug: #91056 in xkeyboard-config (main) "[Feisty]  synaptic keypad lock button launches KDE Help Center" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91056
<cjwatson> tepsipakki: any news on the xresprobe thread mdz started on ubuntu-devel?
<cjwatson> there doesn't seem to have been followup there
<Ubugtu> New bug: #91850 in xserver-xorg-video-ati (main) "messy desktop effects on Thinkpad R40" [Medium,Unconfirmed]  https://launchpad.net/bugs/91850
<Ubugtu> New bug: #27604 in linux-restricted-modules-2.6.15 (restricted) "[madwifi]  Thinkpad z60t wifi does not work" [Medium,Unconfirmed]  https://launchpad.net/bugs/27604
<tepsipakki> cjwatson: right, I promised to reply
<Ubugtu> New bug: #23244 in gtk+2.0 "Multiple Latin layouts in XKB" [Low,Confirmed]  https://launchpad.net/bugs/23244
<Ubugtu> New bug: #47399 in gtk+2.0 "Ctrl+q selects all (dup-of: 23244)" [Low,Rejected]  https://launchpad.net/bugs/47399
<tepsipakki> pochu: http://users.tkk.fi/~tjaalton/xorg72/crack
<pochu> tepsipakki: :D
<tepsipakki> didn't fix the issue I have..
<pochu> tepsipakki: the fonts one?
<tepsipakki> fonts are fine, but the resolution isn't
<pochu> let's see how works here :)
<tepsipakki> I'm beginning to hate Lenovo for that monitor
<pochu> hehe
<tepsipakki> although it's the same with a Sun 19" flat
<pochu> going to test, I'll be back soon better than ever! :)
<tepsipakki> you wish :)
<pochu> little fonts issue is gone :)
<pochu> and I think corrupted screen when starting X is algo gone, though I'm not sure (because I'm not sure it happened every time)
<tepsipakki> hm, I can get the native resolution via d-sub
<tepsipakki> but on restart it gets 1280x1024 but the virtual size is 1680x1050
<tepsipakki> I mean on logout
<tepsipakki> restarting the server makes it good again
<tepsipakki> hm, survives maybe five restarts, then the screen gets all messy
<Ubugtu> New bug: #37030 in linux-restricted-modules-2.6.20 (restricted) "compatibility beetween dri and radeon" [Medium,Confirmed]  https://launchpad.net/bugs/37030
<Ubugtu> New bug: #36958 in xserver-xorg-input-synaptics (main) "No touch-and-drag with Synaptics pad (dup-of: 40503)" [Medium,Confirmed]  https://launchpad.net/bugs/36958
<Ubugtu> New bug: #36959 in xserver-xorg-input-synaptics (main) "Scroll button not working in Synaptics pad (dup-of: 40503)" [Medium,Unconfirmed]  https://launchpad.net/bugs/36959
<Ubugtu> New bug: #47982 in xorg (main) "transparency, ati driver, gnome applet" [Medium,Rejected]  https://launchpad.net/bugs/47982
<Ubugtu> New bug: #87247 in hw-detect (main) "ati graphics card not detected on MacBook Pro (dup-of: 87244)" [Undecided,Confirmed]  https://launchpad.net/bugs/87247
<Ubugtu> New bug: #92527 in libx11 (main) "[fiesty]  XMoveWindow Function in xlib" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92527
<pochu> the new intel driver rocks! :)
<pochu> no more corrupted screen when starting X (it was for a moment with the old)
<pochu> and I can login with a user, then logout, and login with a different one (with the other I could, but then I had some problems with the screen)
<tepsipakki> can you do that five times in a row?
<pochu> tepsipakki: logout and login again?
<pochu> or logout and login in with a different user?
<tepsipakki> don't know if it matters
<tepsipakki> I tried with the same user
<pochu> ok, gonna try
<pochu> but logout and login again, or restart X ?
<tepsipakki> login&logout, although I think it doesn't matter
<tepsipakki> restart should do
<pochu> oks
<pochu> good luck pochu! :)
<pochu> np here
<pochu> what's your problem?
<pochu> I have loged out and in about 7 times :)
<tepsipakki> hmm, I restarted it several times, and maybe every third time it had a wrong mode. but previously the screen got corrupt and I had to reboot
<pochu> I haven't restarted X, though
<pochu> just logout and login, but that doesn't restart x, right?
<tepsipakki> are you running gdm?
<tepsipakki> gdm should restart it by default
<pochu> ah, ok
<pochu> didn't know :)
<pochu> I have learned something for today ;)
<tepsipakki> what
<tepsipakki> it doesnt'
<tepsipakki> and so have _I_ :)
<pochu> tepsipakki: so I should restart X 5 times :S
<pochu> will do later :)
<pochu> hehe
<tepsipakki> I couldn't reproduce it..
<pochu> better :)
<tepsipakki> and glxgears worked as well
<tepsipakki> although I bet there was a reboot in between
<Ubugtu> New bug: #92418 in gnome-terminal (main) "control+A zooms out in gnome-terminal (dup-of: 23244)" [Low,Needs info]  https://launchpad.net/bugs/92418
<Ubugtu> New bug: #38823 in linux-restricted-modules-2.6.12 (restricted) "Missing nvidia 3d acceleration" [Medium,Rejected]  https://launchpad.net/bugs/38823
<kylem> 2.6.12?!
<kylem> oh. breezy.
<tepsipakki> yeah :)
<Ubugtu> New bug: #92599 in xorg (main) "unable to set proper screen refresh rate" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92599
<Ubugtu> New bug: #92563 in xorg (main) "x broken in feisty with radeon driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92563
<Ubugtu> New bug: #91954 in xserver-xorg-video-ati (main) "Some ati users get a black screen and sound, must use the vesa driver to get xorg to work" [Undecided,Confirmed]  https://launchpad.net/bugs/91954
<Ubugtu> New bug: #55841 in xorg (main) "X session gets sluggish for no apparent reason" [Undecided,Unconfirmed]  https://launchpad.net/bugs/55841
#ubuntu-x 2007-03-16
<Ubugtu> New bug: #92408 in xorg (main) "X11 does not support laptop lcd native resolution" [Undecided,Confirmed]  https://launchpad.net/bugs/92408
<Ubugtu> New bug: #92045 in xorg (main) "When I install Edgy my monitor gets unclear" [Undecided,Needs info]  https://launchpad.net/bugs/92045
<Ubugtu> New bug: #92667 in xorg (main) "bad seing of the Desktop on a DELL and the live cd" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92667
<Ubugtu> New bug: #91810 in compiz (main) "Cannot open trash bin, desktop effects sometimes make windows contents not visible. (dup-of: 89189)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91810
<tepsipakki> seb128: I've made a new xorg which fixes one bug (#52032) and disables horizontal scrolling again for synaptics, since the feature is broken on some hardware
<tepsipakki> also, a new xresprobe
<tepsipakki> which limits the autoprobing to vesa
<tepsipakki> debdiffs in the usual place
<tepsipakki> hm, maybe I'll ask Mithrandir for approval first
<seb128> yeah
<Mithrandir> tepsipakki: I prodded you about the new -vesa last night, I don't know if you saw it?
<tepsipakki> on #u-d?
<tepsipakki> I saw it was uploaded
<Mithrandir> yes, I asked about it, since I didn't know if it was well tested or not, etc.
<tepsipakki> hmm, right. I'll ask those who suffer from the bug to test
<Mithrandir> thanks.
<tepsipakki> xresprobe and xorg should be easy, no?
<Mithrandir> yes, I'll review them once they're in the queue
<tepsipakki> ok
<tepsipakki> seb128: go for it when you have time :)
<tepsipakki> one thing I've been wondering is why our vesa is so slow compared to Fedora
<tepsipakki> and they have a patch "vesa-1.2.1-fix-shadowfb.patch: Fix massive performance regression relative"
<Mithrandir> how big is that one?
<tepsipakki> http://cvs.fedora.redhat.com/viewcvs/devel/xorg-x11-drv-vesa/vesa-1.2.1-fix-shadowfb.patch?rev=1.1&view=auto
<tepsipakki> does that link work?
<Mithrandir> doesn't look too scary.
<Mithrandir> yes, link's fine.
<Mithrandir> post-beta?
<tepsipakki> fine by me
<tepsipakki> then they have one more patch for vesa :) http://cvs.fedora.redhat.com/viewcvs/devel/xorg-x11-drv-vesa/vesa-1.2.1-randr-crash.patch?rev=1.1&view=auto
<tepsipakki> not that I've seen it happen on Ubuntu
<Ubugtu> New bug: #92760 in xorg (main) "X crashes on IBM X60s w. Intel 950 chipset" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92760
<Mithrandir> hm, I'd be ponderous of that one, but if fedora has it in their tree and has had for nine months it's probably good.
<tepsipakki> hum, it seems that the vesa-1.2.1-fix-shadowfb.patch got dropped
<tepsipakki> it's not in the latest .spec
<Mithrandir> hm
<tepsipakki> but the range-hack is (which is what the new version in the queue has)
<Ubugtu> New bug: #22528 in xorg (main) "ubuntu hoary to breezy fails to restart X" [Medium,Rejected]  https://launchpad.net/bugs/22528
<tepsipakki> Mithrandir: a patch for mesa, fixes bug #90622 http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=2dfb3a217f730d6783fb2ac8b73248dc682f923c;hp=af1d1e08e40c8c70dfa81e39724be11da94f938d
<Ubugtu> Malone bug 90622 in mesa "Maps disappearing when zooming in on google earth" [Undecided,In progress]  https://launchpad.net/bugs/90622
<tepsipakki> looks good?
<Mithrandir> yes, looks ok
<Ubugtu> New bug: #92298 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Medium,Rejected]  https://launchpad.net/bugs/92298
<Ubugtu> New bug: #90641 in xorg (main) "gnome logs out automatically after inactivity" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90641
<Ubugtu> New bug: #28004 in xserver-xorg-video-ati (main) "[RV350]  graphic total corrupted (6.99.99.904)" [Medium,Fix released]  https://launchpad.net/bugs/28004
<Ubugtu> New bug: #47793 in xserver-xorg-video-i810 (multiverse) "DRI module load fails (undefined symbol: _glapi_Dispatch)" [Medium,Rejected]  https://launchpad.net/bugs/47793
<Ubugtu> New bug: #34725 in xserver-xorg-video-i810 (main) "Resolution Problem" [Medium,Rejected]  https://launchpad.net/bugs/34725
<Ubugtu> New bug: #30133 in xserver-xorg-video-i810 (main) "cannot dpkg-reconfigure xserver-xorg from xterm" [Low,Rejected]  https://launchpad.net/bugs/30133
<Ubugtu> New bug: #39453 in xserver-xorg-video-i810 (main) "Display corruption from fresh install" [Medium,Rejected]  https://launchpad.net/bugs/39453
<Ubugtu> New bug: #39920 in xserver-xorg-video-i810 (main) "xserver crashed with intel 865 graphics chip" [Medium,Needs info]  https://launchpad.net/bugs/39920
<Ubugtu> New bug: #37618 in xserver-xorg-video-i810 (main) "Some character is missing when using GTK apps in KDE environment in i810 driver." [Medium,Rejected]  https://launchpad.net/bugs/37618
<Ubugtu> New bug: #41390 in xserver-xorg-video-i810 (main) "Switching to external monitor without it being attached breaks the screen" [Medium,Needs info]  https://launchpad.net/bugs/41390
<Ubugtu> New bug: #92808 in xorg-server (main) "After automatic update only old kernel works." [Undecided,Unconfirmed]  https://launchpad.net/bugs/92808
<tepsipakki> I've built a new xorg-server to test if the dropped fedora patch (which won't get upstream) makes a difference in performance
<tepsipakki> I'll test it shortly
<pochu> tepsipakki: I can also test it (intel gma) if you tell me what should I expect ;)
<tepsipakki> it's 1.2.0-3ubuntu3.1, so nothing shiny :)
<pochu> hmm, I have your 1.2.99.902 because the intel driver :)
<Mithrandir> tepsipakki: could I ask you to take a look at the build failure of mesa?  I have an upload by Paul Sladen, but would, tbh, be more comfortable if you did it since you're getting to know the code well enough.
<tepsipakki> Mithrandir: ok, I'll have a look
<cjwatson> 18:32 <firephoto> Is anyone aware of the xorg memory leak with xserver 1.2 or does that need a bug filed? https://bugs.freedesktop.org/show_bug.cgi?id=10009#c9
<Ubugtu> Freedesktop bug 10009 in Server/general "xorg 7.2 (xorg-server-1.2.0) consumes memory" [Normal,New]  
<cjwatson> do we have that?
<tepsipakki> no
<Mithrandir> tepsipakki: thanks a lot.
<tepsipakki> cjwatson: I've looked at it though
<cjwatson> seems like an obvious pre-beta candidate to me
<tepsipakki> I'll put it in the same test-version I mentioned earlier
<tepsipakki> or maybe just that for beta
<tepsipakki> heh, "mesa-6.5.2-hush-synthetic-visual-warning.patch" in fedora :)
<tepsipakki> would close (and prevent) a number of bugs
<tepsipakki> Mithrandir: hmm, seems that mesa lacks a dependancy on x11-proto-xext-dev. I'll try to build it in pbuilder first
<Mithrandir> tepsipakki: thanks a lot
<tepsipakki> actually, I'll try to build the current version just to make sure
<cjwatson> I've filed bug 92822 about the memory leak
<Ubugtu> Malone bug 92822 in exaile "[apport]  exaile.py crashed with AttributeError in get_bitrate()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92822
<cjwatson> er
<cjwatson> I mean bug 92882
<Ubugtu> Malone bug 92882 in xorg-server "significant memory leak in xserver 1.2" [High,Unconfirmed]  https://launchpad.net/bugs/92882
<tepsipakki> ok, thanks
<tepsipakki> right, mesa failed just as I thought
<tepsipakki> now the new version with added dep
<Ubugtu> New bug: #92882 in xorg-server "significant memory leak in xserver 1.2" [High,Unconfirmed]  https://launchpad.net/bugs/92882
<tepsipakki> oh, should I bump the version of mesa?
<tepsipakki> now that -3ubuntu2 is already uploaded
<tepsipakki> hah, another failure
<tepsipakki> /usr/bin/ld: cannot find -lXext
<tepsipakki> collect2: ld returned 1 exit status
<tepsipakki> ah
<tepsipakki> libxext-dev
<Mithrandir> tepsipakki: I'll reject the version in the queue already.
<Mithrandir> so just ignore that one
<tepsipakki> ok, the build went fine
<tepsipakki> you can find it at http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> there is also xresprobe which should get in
<Mithrandir> I'm on GPRS right now, but I'll be on DSL in a couple of hours, so unless somebody beats me to it, you won't see an upload from me before midnight-ish
<Mithrandir> mesa uploads over GPRS = not fun, I'd imagine
<tepsipakki> that's fine
<tepsipakki> hehe
<Ubugtu> New bug: #92908 in xorg-server (main) "Xorg xserver 7.2 uses up all available memory with certain apps" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92908
<tepsipakki> heh, first dupe for the memory leak
<tepsipakki> actually, there was #77606 already.. missed that one. The leak was not new, it seems
<tepsipakki> no, I even commented that one :)
<tepsipakki> Mithrandir: see bug #90169
<Ubugtu> Malone bug 90169 in mesa "SecondLife, GL.O.B.S. and other GL apps have a Black Window on Radeon drivers - Patch available" [Undecided,Confirmed]  https://launchpad.net/bugs/90169
<tepsipakki> those are from upstream, but four separate patches
<Ubugtu> New bug: #92652 in xkeyboard-config (main) "C-cedil not present in US-International keyboard" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92652
<Ubugtu> New bug: #92848 in xorg (main) "X dark display with games" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92848
<Ubugtu> New bug: #91659 in xorg (main) "Max selectable screen resolution 1024x768" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91659
<Ubugtu> New bug: #92930 in xresprobe (main) "[Feisty]  xresprobe with i810 or i815 kills your xsession" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92930
<Ubugtu> New bug: #91606 in linux-source-2.6.20 (main) "system doesn't boot on motherboard asus crosshair (chipset nvidia nforce 590 sli). "noapic nolapic irqpoll" doesn't help (dup-of: 91556)" [Undecided,Confirmed]  https://launchpad.net/bugs/91606
<Ubugtu> New bug: #92769 in xorg (main) "x11 resolution chooser not working" [Undecided,Needs info]  https://launchpad.net/bugs/92769
#ubuntu-x 2007-03-17
<Mithrandir> tepsipakki: 90169> I thought we fixed that with the previous mesa upload?
<Ubugtu> New bug: #92010 in xorg (main) "nvidia-legacy only offer low resolution" [Undecided,Needs info]  https://launchpad.net/bugs/92010
<tepsipakki> Mithrandir: you mean the one paul sladen uploaded?
<tepsipakki> this is different
<Ubugtu> New bug: #88740 in xorg (main) "No support for ATI x1400" [Undecided,Needs info]  https://launchpad.net/bugs/88740
<Mithrandir> tepsipakki: ok.
<tepsipakki> but I didn't include them in the fixed -3ubuntu2
<Mithrandir> ok, so we might want a -3ubuntu3 with that patch in?
<tepsipakki> yes we might, do you want me to prepare one?
<tepsipakki> new xorg-server is there
<tepsipakki> with debdiff
<tepsipakki> I'm running it atm
<tepsipakki> ok, new mesa in that webfolder
<Mithrandir> ok, so new mesa, new xorg-server?
<tepsipakki> yes
<tepsipakki> if they look ok to you
<Mithrandir> the new mesa fixes the buildability as well as the second life black window?
<Mithrandir> and xorg-server fixes the memory leak?
<tepsipakki> xorg-server has an old patch re-enabled, it might fix some of the performance regressions some have seen with composition managers
<tepsipakki> yes and yes
<Mithrandir> ok, cool.
<Mithrandir> I'll take a look at it and upload.
<Mithrandir> thanks a lot for your efforts.
<tepsipakki> about that xorg-patch; it still seems to be useful since the compmanagers don't seem to handle bg=none properly
<Mithrandir> ok
<tepsipakki> and fedora still has it with 1.3rc
<tepsipakki> oh and xresprobe
<tepsipakki> don't forget that one :)
<tepsipakki> it limits the autoprobing to vesa
<Mithrandir> yup, goodie
<tepsipakki> I found one case where it fails, though; autoprobing uses the best driver it can get, so if discover1 doesn't have the card mapped to a driver, autoprobing knows which driver to use
<tepsipakki> but the impact is minimal
<tepsipakki> only affects laptops (since others use ddcprobe) etc
<tepsipakki> I'll see how to fix that
<tepsipakki> ..hopefully soon enough before the beta
<tepsipakki> or, we could just patch discover-data to be uptodate, like before :)
<tepsipakki> when we found it to be lacking some
<Mithrandir> hm, ok
<tepsipakki> anyway, bedtime... thanks! ->
<Mithrandir> see you around.
<tepsipakki> you too, good night <zzzz>
<Ubugtu> New bug: #93041 in xorg (main) "Xorg failes to start on sparc" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93041
<Ubugtu> New bug: #92117 in acpi (main) "/fan dir empty! (dup-of: 88815)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92117
<Ubugtu> New bug: #92994 in linux-source-2.6.20 (main) "Since update to feisty, CPU fan in laptop won't stop spinning (dup-of: 88815)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92994
<Ubugtu> New bug: #23464 in linux-restricted-modules-2.6.15 (restricted) "Celestia dies with segmentation fault, on atiogl_a_dri.so" [Medium,Needs info]  https://launchpad.net/bugs/23464
<Ubugtu> New bug: #24768 in linux-restricted-modules-2.6.15 (restricted) "Fglrx crashes X" [Medium,Rejected]  https://launchpad.net/bugs/24768
<Ubugtu> New bug: #24684 in linux-restricted-modules-2.6.15 (restricted) "Xorg gets 100% of CPU constantly" [Medium,Rejected]  https://launchpad.net/bugs/24684
<Ubugtu> New bug: #38991 in linux-restricted-modules-2.6.15 (restricted) "[Dapper]  New nVidia 1.0.8756 graphics driver produces wrong refresh rate" [High,Rejected]  https://launchpad.net/bugs/38991
<Ubugtu> New bug: #46767 in xresprobe (main) "Desktop installer setting wrong resolution in Dapper RC" [Medium,Confirmed]  https://launchpad.net/bugs/46767
<Ubugtu> New bug: #93078 in xserver-xorg-video-ati (main) "Incorrect resolution on Medion MD 97300 with ATI Radeon Xpress 200M" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93078
<Ubugtu> New bug: #37916 in xresprobe (main) "dapper livecd: xorg not started in 1400x1050" [Medium,Needs info]  https://launchpad.net/bugs/37916
<Ubugtu> New bug: #42932 in xorg (main) "dapper livecd not started in 1440x900, but in 1024x768" [Medium,Needs info]  https://launchpad.net/bugs/42932
<Ubugtu> New bug: #44379 in linux-restricted-modules-2.6.15 (restricted) "nvidia-glx-config incorrectly configures for nforce2" [Medium,Rejected]  https://launchpad.net/bugs/44379
<tepsipakki> Mithrandir: arf, the vesa driver might need a patch to fix a crash on randr resolution change
<tepsipakki> bug #91591
<Ubugtu> Malone bug 91591 in xorg "X server crashes on resolution change" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91591
<tepsipakki> and fedora has a patch which could fix that. I'll ask the reporter to test
<Ubugtu> New bug: #46586 in xkeyboard-config (main) "Logitech Media Keyboard Elite not fully supported" [Medium,Confirmed]  https://launchpad.net/bugs/46586
<Ubugtu> New bug: #93151 in xterm (main) "Missing a .desktop file" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93151
<Ubugtu> New bug: #40905 in xkeyboard-config (main) "Enter key sends wrong signal on compaq evo n1000c" [Medium,Needs info]  https://launchpad.net/bugs/40905
<Ubugtu> New bug: #93156 in xserver-xorg-video-nv (main) "1440x900 resolution not working" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93156
<Ubugtu> New bug: #93168 in xorg (main) "Xorg crashes when watching video" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93168
<Ubugtu> New bug: #54294 in xorg (main) "Failed to allocate mem resource #6 ..." [Undecided,Unconfirmed]  https://launchpad.net/bugs/54294
<Ubugtu> New bug: #93192 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93192
<Ubugtu> New bug: #21893 in xserver-xorg-video-ati (main) "Incorrect max texture size reported by ATI dri drivers" [Medium,Fix released]  https://launchpad.net/bugs/21893
<Ubugtu> New bug: #45602 in xorg (main) "[Dapper]  Screen Resolution just 640x480 with LCD Display (dup-of: 43917)" [Medium,Unconfirmed]  https://launchpad.net/bugs/45602
<Ubugtu> New bug: #12829 in xresprobe (main) "Select resolutions based on vertical refresh rate and maximum horizontal sync" [Wishlist,Confirmed]  https://launchpad.net/bugs/12829
#ubuntu-x 2007-03-18
<Ubugtu> New bug: #92092 in xserver-xorg-input-mouse (main) "loss of mouse buttons" [Undecided,Needs info]  https://launchpad.net/bugs/92092
<Mithrandir> tepsipakki: ugh.
<Mithrandir> tepsipakki: can you provide a new package, please?
<tepsipakki> yes
<tepsipakki> Mithrandir: new package in http://users.tkk.fi/~tjaalton/xorg72/new
<Mithrandir> thanks
<Ubugtu> New bug: #93229 in gdm (main) "Window for "gdmflexiserver -n" disappears on desktop switch (dup-of: 73931)" [Medium,Rejected]  https://launchpad.net/bugs/93229
<Ubugtu> New bug: #93348 in xorg (main) "X11 crashes with a dual-head configuration after lauching for example the screensaver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93348
<Ubugtu> New bug: #93318 in xorg (main) "After my last Feisty update I could not start X server. " [Undecided,Unconfirmed]  https://launchpad.net/bugs/93318
<Ubugtu> New bug: #93362 in xserver-xorg-video-via (main) "Via unichrome video driver misplaces OpenGL viewport" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93362
<Ubugtu> New bug: #49983 in libxinerama (main) "Xinerama+fglrx+kde is not working after upgrade to dapper" [Undecided,Unconfirmed]  https://launchpad.net/bugs/49983
<troughton> hi im looking for a chanel someone can help me with a live usb drive
<Ubugtu> New bug: #93354 in xorg (main) "Ubuntu Feisty freezes when changing resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93354
<Ubugtu> New bug: #93440 in xorg (main) "Wrong default resolution for thinkpad r52" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93440
#ubuntu-x 2008-03-10
<ubotu> New bug: #200407 in xorg (main) "Notifications" [Undecided,New] https://launchpad.net/bugs/200407
<ubotu> New bug: #200411 in xorg (main) "[hardy] Recent update gives 400x300 resolution after login" [Undecided,New] https://launchpad.net/bugs/200411
<ubotu> New bug: #185423 in wine (universe) "Wine crashes and close my session went to login screen (dup-of: 178292)" [Undecided,New] https://launchpad.net/bugs/185423
<ubotu> New bug: #197639 in linux-restricted-modules-2.6.24 (restricted) "[hardy] fglrx xv output not available for video playback" [High,Confirmed] https://launchpad.net/bugs/197639
<tjaalton> bryce: around?
<bryce> tjaalton: heya, just on the way to bed.  what's up?
<tjaalton> bryce: hi, I won't hold you for long, just wanted to get your ack/nack for bug #87947
<bryce> ok
<tjaalton> xcb enabled libx11 is breaking apps that use old java's (up to java6)
<tjaalton> that's well known, and there's the environment variable to use sloppy locking instead
<tjaalton> my plan is to use sloppy locking by default
<bryce> that sounds like the most logical solution to me as well
<tjaalton> it still prints an ugly trace, but the app runs
<bryce> well that's better than a crash
<tjaalton> so, I'll upload a new libxcb once I get the logic right ;)
<bryce> sounds like it's unlikely to cause further regression, but it'll be smart to keep an eye on it
<tjaalton> the other option would be to set the variable in /etc/environment, but upgraders would still be affected
<bryce> true
<bryce> would it be possible for people to turn it off with an env variable?
<tjaalton> that's what I'm trying to accomplish
<tjaalton> the first iteration didn't work out :)
<ubotu> Launchpad bug 87947 in libxcb "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [High,Fix committed] https://launchpad.net/bugs/87947
<bryce> yay
<tjaalton> ubotu is snappy today
<ubotu> Sorry, I don't know anything about is snappy today - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<tjaalton> bryce: also, I'd like to pull some upstream fixes for at least xserver and libx11
<bryce> sure
<bryce> I was thinking we ought to look for upstream fixes
<bryce> I've got some more xrandr gui changes I'm going to work on tomorrow
<pwnguin> heh, reflections?
<bryce> night
<tjaalton> night
<tjaalton> ffs, can't get the logic right with sloppy lock.. it's either always on or always off
<tjaalton> and the reason must be something stupid
<ubotu> New bug: #200086 in xserver-xorg-video-ati (main) "[hardy] visual effects require proprietary drivers don't needed in gutsy" [Undecided,Confirmed] https://launchpad.net/bugs/200086
<ubotu> New bug: #200568 in linux-restricted-modules-2.6.24 (restricted) "Ubuntu hardy does not provide suspend or hibernate on Thinkpad laptop T61 with NVidia" [Undecided,New] https://launchpad.net/bugs/200568
<ubotu> New bug: #200589 in linux-restricted-modules-2.6.24 (restricted) "fwlanusb crashes the system" [Undecided,New] https://launchpad.net/bugs/200589
<tjaalton> hmm, should I just merge libx11-1.1.4..
<Ng> we support the x3100, right? :)
<tjaalton> it's basically a 965 AFAIK
<Ng> ok
<Ng> because I seem to own one now :o
<tjaalton> heh
<Ng> I couldn't resist buying an X300 ;)
<tjaalton> damn you :)
<Ng> it sucks working within lunchbreak distance of a really good lenovo dealership ;)
 * Ng worried by tjaalton's hints of jealousy, I don't want to see any uploads with "break Ng's laptop" in the changelog
<tjaalton> hehe
<tjaalton> I just got an X61, and soon after comes X300 :P
<Ng> tjaalton: just booted alpha6 and it's at least guessed the right resolution I think :)
<ubotu> New bug: #200632 in xserver-xorg-video-intel (main) "[gutsy] Opengl applications' windows are not refreshed with compiz when partially hidden on the right (intel drivers)" [Undecided,New] https://launchpad.net/bugs/200632
<ubotu> New bug: #200638 in xserver-xorg-video-openchrome (main) "The OpenChrome driver provided in Synaptics is old" [Undecided,New] https://launchpad.net/bugs/200638
<Ng> although it did just display a lot of noise when it quit X to shutdown the livecd
<Ng> I think I've seen a bug about that before
<ubotu> New bug: #200654 in linux-restricted-modules-2.6.24 (restricted) "Screen flickers badly before screensaver with fglrx 8.2" [Undecided,New] https://launchpad.net/bugs/200654
<seb128> bryce: around?
<bryce> yup
<seb128> bryce: in case you didn't notice g-s-d is broken again for radeonhd users apparently
<bryce> ok, I'll look.  bug id#?
<seb128> bryce: your patch was sort of working because the configure was not setting HAVE_XRANDR in the previous version, so the xrandr code was just disabled for everybody
<seb128> the new version does set it correctly
<seb128> so the xrandr code is used
<seb128> I think you need a runtime check there
<seb128> bug #199260
<ubotu> Launchpad bug 199260 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV when using radeonhd driver" [Medium,Incomplete] https://launchpad.net/bugs/199260
<seb128> bub #197645
<seb128> bug #199245
<ubotu> Launchpad bug 199245 in gnome-settings-daemon "gnome-settings-daemon crash opening any window: "BadWindow" X error under Xvnc" [Low,Incomplete] https://launchpad.net/bugs/199245
<bryce> thanks, looking
<seb128> you are welcome
<seb128> as said what 92_gsd-xrandr-version-check.patch was basically to disable the xrandr code for everybody
<seb128> since the configure was not setting the define
<bryce> hmm, 199245, comment 1 suggests it's an issue with the keyboard plugin
<bryce> 199260 unfortunately does not have a backtrace
<seb128> I was just picking some on the list
<bryce> ah
<seb128> let me find the mails I read about that yesterday
<bryce> ok
<seb128> bug #197153
<ubotu> Launchpad bug 197153 in gnome-control-center "gnome-settings-daemon crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/197153
<seb128> and bug #199960
<ubotu> Launchpad bug 199960 in gnome-settings-daemon "error starting GNOME Settings Daemon" [Undecided,Confirmed] https://launchpad.net/bugs/199960
<seb128> those should be the correct ones
<bryce> yeah, I remember when I put the XRANDR define fix, I was not expecting that alone would solve it, and was very surprised that it did
<bryce> the issue seems to be that radeonhd promises xrandr 1.2 but for some reason isn't delivering
<bryce> I wonder if there's some other way to detect and disable it
<tjaalton> Ng: actually, X61 has the same chip, so it definately is working ;)
<Ng> tjaalton: interesting. I noticed in lspci it looks a lot like a 965 ;)
<Ng> I have no sound or suspending or brightness control yet though ;)
<ubotu> New bug: #173418 in xorg (main) "[Hardy] NVIDIA cards using vesa driver and low screen resolutions on livecd" [Undecided,Confirmed] https://launchpad.net/bugs/173418
<bryce> tjaalton: btw, did you make a decision on my force-all-greedy patch?  (bug 177492, http://people.ubuntu.com/~bryce/Uploads/)
<tjaalton> bryce: I just forgot it :/
<tjaalton> but I'll upload it tomorrow
<tjaalton> btw, the patch for libxcb is making me crazy
<tjaalton> I just can't understand why this doesn't work: http://users.tkk.fi/~tjaalton/dpkg/100_sloppy_lock.diff
<tjaalton> the if-clause is never true
<tjaalton> but I made a test program where it works
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [Critical,Confirmed] https://launchpad.net/bugs/177492
<bryce> tjaalton: lemme take a quick look.
<tjaalton> dropping 'if' had some other problems
<tjaalton> oh right, it would set sloppy_lock = 0; if the variable is not set
<bryce> ok, well the if() statement looks redundant
<bryce> is what you want to do, to interpret the value set in LIBXCB_ALLOW_SLOPPY_LOCK?
<tjaalton> basically yes, but so that if it's not set leave sloppy_lock=1
<bryce> http://pastebin.ubuntu.com/5556/
<bryce> the != 0 is just checking if the pointer is NULL, so will return true always, whether the string is set to 0, or 1 or "foobar"
<bryce> using atoi() to convert the string into an integer is probably what you want
<tjaalton> the if() is straight from the old patch for feisty (which was pulled later), so maybe it didn't work there either :/
<bryce> it looks like it was just checking if the env var was present; looks like it could have been set to anything (even 0), and that would turn it on
<tjaalton> right..
<tjaalton> ok, now the question is should I keep the same variable name
<tjaalton> or use LIBXCB_NO_SLOPPY_LOCK like before
<bryce> hmm
<bryce> LIBXCB_DISABLE_SLOPPY_LOCK would probably be more explicit
<tjaalton> refreshed the link
<bryce> that looks ok
<tjaalton> ok, thanks
<tjaalton> sigh, trying to debsign the -intel for upload, but it's not my day apparently
<tjaalton> hmm, wrong tool
<tjaalton> bryce: ok, -intel uploaded..
<bryce> awesome, thanks
<seb128> bryce: any news on the g-s-d crasher?
<bryce> seb128: I've been looking at the bugs and sorting things out, but haven't discovered the underlying cause there
<bryce> seb128: we already have a check for xrandr version=1.2 afaik, so it seems there is something more at work
<seb128> bryce: ok, I'll have a look tomorrow and drop the patch if I don't find what is causing the issue
<seb128> bryce: GNOME 2.22.0 is due this week and we have quite some user running hardy to try it
<seb128> it's not good to have GNOME crashing for many of those so we need to fix the situation either way
<bryce> seb128: which patch would you be dropping?
<seb128> the xrandr gsd changes
<seb128> we can reapply those once the issue is fixed
<seb128> but as said we need a stable GNOME by wednesday
<ubotu> New bug: #199960 in gnome-settings-daemon (main) "error starting GNOME Settings Daemon (dup-of: 198951)" [High,Confirmed] https://launchpad.net/bugs/199960
<seb128> bryce: we had the patch not applied for a week and nobody noticed so I don't think it'll be a real issue
<ubotu> New bug: #197813 in firefox-3.0 (main) "blogspot webpage messed up in rendering (dup-of: 186186)" [Undecided,Confirmed] https://launchpad.net/bugs/197813
<ubotu> New bug: #200785 in xserver-xorg-video-nv (main) "please sync from Debian unstable" [Undecided,New] https://launchpad.net/bugs/200785
<ubotu> New bug: #200788 in xserver-xorg-input-aiptek (universe) "please sync from Debian unstable" [Undecided,New] https://launchpad.net/bugs/200788
<bryce> seb128: I think this patch may be our culprit:  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=c6c284e64b1f537a3243856cf78cf3f2324e4c2b;hp=33b94da6327d3423b4ebc1a58d5894c9904e67c9
<seb128> bryce: ah?
<seb128> bryce: it's not obvious from the changeset ;-)
<seb128> bryce: btw thanks for the bug triage and looking to the issue
<bryce> well, the bug we were having before was that pointer was NULL; in looking at the traces (wish we had mroe detailed gdb output), it seems the pointer is defined, but to a random value
<bryce> Matthias Hopf is one of the radeonhd developers and I saw him discussing the problem in a mail post, and mentioned he had a fix, so I looked around in git and found this
<bryce> sort of a convoluted path to find a patch, but we just need to get someone to test it.  I'm packaging the patch for testing presently
<bryce> but this would totally explain why we're seeing the same effect on several drivers, but not on the "main" ones
<bryce> the main ones probably have workarounds 
<seb128> ok, I was going to ask why not the main ones
<seb128> that's worth testing ;-)
<bryce> btw, I did check thoroughly into the version 1.2 detection, and it's definitely there.  Plus, the drivers being reported as having problems definitely do advertise xrandr 1.2 support (radeonhd even says partial 1.3 support), so version checking wouldn't help in this case anyway
<seb128> I've buggy configuration there
<seb128> but I can test on a radeonhd box tomorrow
<seb128> gra
<bryce> excellent, thanks
<seb128> I've *no* buggy configuration there
<bryce> I'll post dsc and deb
<seb128> you should use a ppa ;-)
<bryce> honestly I'm not sure what the advantage of ppa is (I did try it out after your last suggestion)
<bryce> it gives amd64 builds, but otherwise is extra maintenance overhead, and you can't put debdiffs or README's into it
<seb128> build for free on several archs
<seb128> and apt sources easy to use
<bryce> just x86 and amd64, no?
<seb128> extra maintenance overhead? 
<seb128> you just have to dput
<seb128> x86 lpia amd64
<bryce> for like if you need to clean things up later, you must use the web ui, you can't just ssh in.  Also it's harder to organize the files (like if 3 packages need installed together)
<seb128> well, depends of your workflow
<bryce> probably
<seb128> I don't use it a lot neither, but I think it's cool
<bryce> I can sure see it useful for several use cases
<seb128> I've no amd64 install so getting binaries in a easy way is already something
<bryce> I usually compile to deb before uploading anyway, so having to wait the extra time for the ppa to finish building kind of disrupts my workflow
<seb128> and an apt source is easier to use than wget random debs and installing those
<bryce> that may be, however I haven't had that many complaints
<seb128> for testing one deb wget is fine
<seb128> for things like daily language pack updates a ppa rocks ;-)
<bryce> heh, I bet
<bryce> anyway, I'm thinking/planning on making more extensive use of it for x testing and auto-driver builds when I get time to set those up
<ubotu> New bug: #200791 in xorg (main) "[hardy] the mouse doesn't respond (move) in X after upgrade of diplay manager (gdm and kdm)" [Undecided,New] https://launchpad.net/bugs/200791
<ubotu> New bug: #200797 in linux-restricted-modules-2.6.24 (restricted) "nvidia not loading in 2.6.24-12-generic" [Undecided,New] https://launchpad.net/bugs/200797
<bryce> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=184e571957f697f2a125dc9c9da0c7dfb92c2cd9
<bryce> oops mis-paste
<bryce> mm, found several other xrandr patches that would be good to have.  I'll make a bundle of them; these could solve a few issues...
#ubuntu-x 2008-03-11
<ubotu> New bug: #200805 in xorg-server (main) "xorg uses laptop video BIOS 'Panel Size' for external monitors, so apps end up confined to small space in top left of screen" [Undecided,New] https://launchpad.net/bugs/200805
<ubotu> New bug: #200807 in linux (main) "Nvidia driver not loading in Hardy 2.6.24-12 (dup-of: 200797)" [Undecided,New] https://launchpad.net/bugs/200807
<ubotu> New bug: #199260 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV when using radeonhd driver (dup-of: 198951)" [Medium,Incomplete] https://launchpad.net/bugs/199260
<bryce> tjaalton: cool, the patch for bug 199700 looks like it will clear up one of the xrandr bugs I noticed in testing the xrandr gui
<ubotu> Launchpad bug 199700 in xorg-server "xrandr changes break composite on 2nd head" [Low,Confirmed] https://launchpad.net/bugs/199700
<bryce> hrm, the patches I backported seem not to fix the issue.  rats.  I am not running across other likely candidate patches tho...  maybe just need a way to shut off the xrandr stuff for these drivers
<ubotu> New bug: #200868 in nvidia-settings (universe) "nvidia-settings doesn't have permissions to write xorg.conf" [Undecided,New] https://launchpad.net/bugs/200868
<tjaalton> bryce: I'll probably pull in all the changes that are in the server-1.4-branch, and cherry pick some that were proposed
<bryce> tjaalton: ok
<tjaalton> like a couple of modesetting patches from intel
<tjaalton> bryce: what do you think of libx11-1.1.4? it was released last week, and contains a bunch of manpage fixes, a couple of important patches and some Compose-file fixes
<bryce> the patches might be nice, esp. if they close any of our high/critical bugs
<bryce> is it mostly a bugfix release?
<tjaalton> yes
<tjaalton> fixes bug 66104
<bryce> in that case I'd support it, if it's not too late in the freeze
 * tjaalton slaps ubotu
<tjaalton> I'll test it first
<tjaalton> I also filed a couple of driver sync-requests (nv, aiptek). also we'd need the latest wacom from upstream, but I haven't been able to make it compile :/
<ubotu> New bug: #13346 in xkeyboard-config (main) "[xkb] new japanese layout" [Medium,Invalid] https://launchpad.net/bugs/13346
<ubotu> Launchpad bug 66104 in libx11 "[Gutsy] scim: input freezes in various applications under XIM mode" [High,In progress] https://launchpad.net/bugs/66104
<bryce> tjaalton: the xrandr gui bugs are a bit perplexing to me; I am waiting for further feedback from testers but don't understand why it is breaking on radeonhd, which *should* support xrandr 1.2.  Unfortunately the backtraces provided don't give enough context to figure it out.
<bryce> meanwhile I've been reviewing other bugs/patches
<bryce> tjaalton: would you mind uploading bartman's package update from https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/197069?
<bryce> (if it's not already)
<ubotu> Launchpad bug 197069 in xserver-xorg-video-amd "xserver-xorg-video-amd: wide resolutions don't work" [Undecided,New] 
<ubotu> New bug: #200886 in linux-restricted-modules-2.6.24 (restricted) "gnome applications do not detect multiple screens" [Undecided,New] https://launchpad.net/bugs/200886
<tjaalton> bryce: sure
<tjaalton> I read from the newspaper that the gas price in the US might advance to $4/gallon this year.. I wonder what would happen if it was $8 like it is here :)
<tjaalton> damnit compiz/nvidia for eating my memory
<tjaalton> shower->
<bryce> tjaalton: maybe for every $1 it increases while under Republicans, we invade another oil producing nation?
<bryce> tjaalton: I've just finished reviewing all the xorg bugs-with-patches listed at http://daniel.holba.ch/really-fix-it/.  
<bryce> most turned out to be invalid.  Some were out of date, others weren't really patches (xorg.conf's, etc. tagged as patches), others were patches rejected by subsequent review comments, etc.  There were just a few (like the -amd patch) that looked worth applying
<bryce> once daniel's page updates we should see the list trimmed down a lot
<tjaalton> yeah I took a brief look at it yesterday
<bryce> tjaalton: here is some additional background on the above patch:  http://www.jukie.net/~bart/blog/fixing-x-for-geode-lx
<tjaalton> ah that one
<bryce> ah, check Martin-Eric's reply there
<bryce> sounds like we could just sync 2.7.7.7 to get it
<tjaalton> yep, maybe wait for that
<tjaalton> hmm, maybe I'll just add the two patches for current libx11, saves all the paperwork
<bryce> yeah
<bryce> btw, today is Inkscape 0.46 release day :-)
<tjaalton> congrats :)
<bryce> or at least, release for Linux.  Windows still has some critical bugs so I'm going to hold off on doing the PR for a couple weeks to give the windows porters some additional time
<tjaalton> it's been a while since I used it.. designed a custom label for a beer bottle
<bryce> hopefully there's still time to get it into Hardy, Fedora, Debian, etc.
<bryce> nice :-)
<bryce> hey, with 0.46 you can now also use it for editing/creating PDFs with text and graphics
<tjaalton> cool
<bryce> night
<soren> No, it's not.
<tjaalton> heh
<Ng> backlight support isn't really X's problem, is it
<tjaalton> no, I think it might be some drm changes that broke it
<Ng> well, it may well be that it's just not supported on this hardware yet
<Ng> acpi is seeing the key events and updating the bar thingy onscreen, but the brightness doesn't change
<tjaalton> it's broken for me too
<Ng> interesting
<tjaalton> has been working fine before
<Ng> I don't have a working datapoint on this to know, but I suppose I could boot a gutsy livecd or somehting
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/197929
<Ng> thanks :)
<Ng> I can live without sound if I have to, but not burning out my retinas is quite useful ;)
<tjaalton> for mee it's too dim :/
<tjaalton> like 30% or so
<Ng> ouch. I did get that the first time I booted today, but I rebooted just now and it's gone back to always being 100%
<tjaalton> that's worse :)
<Ng> I'd rather burn my display into the wall behind me than not be able to read it at all ;)
<tjaalton> hehe
<ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Undecided,Incomplete] 
<Ng> hmm, why is that set at Incomplete?
<ubotu> New bug: #200876 in linux (main) "Graphic, Nvidia on Kernel 2.6.12-14 not detected   (dup-of: 200797)" [Undecided,New] https://launchpad.net/bugs/200876
<ubotu> New bug: #200917 in linux (main) "kernel 2.6.24-12 very slow and not nVidia support  (dup-of: 200797)" [Undecided,New] https://launchpad.net/bugs/200917
<seb128> is there anything obviously wrong there, http://paste.ubuntu.com/5571 ?
<seb128> the corresponding config is http://paste.ubuntu.com/5570
<seb128> that's weird, the xorg.conf specifies nvidia and the log has vesa without nvidia trace
<tjaalton> that's failsafe for you :)
<tjaalton> check .old
<seb128> shouldn't that display the displayconfig-gtk interface on failsafe?
<tjaalton> it doesn't?
<tjaalton> it should yes
<tjaalton> there have been reports about nvidia being unable to load, but no updates there either
<tjaalton> other than the kernel
<tjaalton> that log is from gutsy with feisty kernel, so no wonder it doesn't work
<seb128> he has geforce 6200, apparently nv works but breaks when activating glx
<seb128> and nvidia doesn't work either
<tjaalton> Current Operating System: Linux JLS 2.6.20-16-386 #2 Tue Feb 12 05:38:06 UTC 2008 i686
<tjaalton> he needs to compile nvidia-glx* against that
<tjaalton> I thought it was hardy
<seb128> no, he's using gutsy
<tjaalton> but with a custom kernel, so it's up to him to fix that :)
<seb128> linux didn't get upgraded apparently
<seb128> he likely removed linux-image or whatever is responsive for the transition
<tjaalton> yep
<seb128> thanks
<tjaalton> np
<ubotu> New bug: #200946 in xorg-server (main) "Can't change screen resolution" [Undecided,Incomplete] https://launchpad.net/bugs/200946
<Ng> tjaalton: I just updated to the new -intel and it's a hell of a lot slower :/
<Ng> (I mean the new package that update-manager offered me this morning. I guess it's not doing the greedy thing for this chipset?)
<tjaalton> yep, known
<tjaalton> ..by now :)
<tjaalton> greedy is not on
<tjaalton> the patch is broken somehow
<Ng> ok
<tjaalton> hrm, I shut down compiz and restart it again and it uses default ordering for desktops again (4 in one row)
<tjaalton> againagain
<tjaalton> ah, this is metacity :)
<tjaalton> heh
<ubotu> New bug: #200965 in xserver-xorg-video-intel (main) "Intel driver does not allow all resultions (and conflicts with 915resolution)" [Undecided,New] https://launchpad.net/bugs/200965
<ubotu> New bug: #200463 in xorg (main) "my monitor is out to sign to install ubuntu" [Undecided,New] https://launchpad.net/bugs/200463
<ubotu> New bug: #200904 in xserver-xorg-video-intel (main) "[Hardy 6][regression]  xserver-xorg-video-intel" [Undecided,New] https://launchpad.net/bugs/200904
<ubotu> New bug: #200884 in nvidia-settings (universe) "nvidia-settings does not detect active nvidia driver" [Undecided,New] https://launchpad.net/bugs/200884
<tjaalton> mvo: did you get my message on #u-d? the original patch with TexturedVideo disabled works much better, although all the effects are disabled on top of the video frame
<tjaalton> but at least it's very snappy, and CPU usage is low
<mvo> tjaalton: aha, that sounds good. yeah, all effects are disabled then, but I think that this is fine
<tjaalton> yep
<mvo> tjaalton: I was told vista does the same when it plays videos with aero (or whatever their compiz is called)
<tjaalton> mvo: hmm, I'll test :)
<tjaalton> (yes, my laptop has vista too..)
<mvo> tjaalton: I don't have a install to test that :)
<tjaalton> it came with the laptop, and it's the only windows at my disposal, so I need it to program my remote :)
<mvo> haha
<mvo> yeah :)
<tjaalton> oh and to read/change the values of my car on-board diagnostics comp. :)
<tjaalton> s/of/on/
<tjaalton> hmm, now I need some video clip
<tjaalton> mvo: the aero effects seem to work, blur/translucent window borders etc on top of a video frame
<tjaalton> but <shrug>, who cares
<ubotu> New bug: #201032 in xorg (main) "[hardy][regression]xorg gets wrong screen dpi" [Undecided,New] https://launchpad.net/bugs/201032
<ubotu> New bug: #201050 in xorg-server (main) "dexconf using macintosh78 instead of macbook78" [Undecided,New] https://launchpad.net/bugs/201050
<bryce> morning
<tjaalton> morning, check the intel patch, it doesn't seem to work :)
<bryce> dah
<bryce> tjaalton: perhaps we should just revert the patch for now; I don't know that I'll have time to look into it today
<ubotu> New bug: #201076 in linux-restricted-modules-2.6.24 (restricted) "Dual-Head Monitor Refresh Issue on Second Screen" [Undecided,New] https://launchpad.net/bugs/201076
<ubotu> New bug: #201085 in linux-restricted-modules-2.6.24 (restricted) "nvidia 3D" [Undecided,Incomplete] https://launchpad.net/bugs/201085
<tjaalton> bryce: yeah, I can revert it. I also tested the overlay patch for 965, works great
<bryce> ok
<bryce> yeah the overlay patch sounds good to include
<ubotu> New bug: #201103 in linux-restricted-modules-2.6.24 (restricted) "[Hardy] B43 Performance very slow" [Undecided,New] https://launchpad.net/bugs/201103
<ubotu> New bug: #77064 in linux-restricted-modules-2.6.24 "patch allowing lrm builds against custom kernels" [Undecided,Incomplete] https://launchpad.net/bugs/77064
<ubotu> New bug: #200813 in xserver-xorg-input-keyboard (main) "dead keys broken in hardy" [Undecided,New] https://launchpad.net/bugs/200813
<ubotu> New bug: #89211 in libx11 (main) "Monitor & Display (in System Settings) is always crashing" [Undecided,Confirmed] https://launchpad.net/bugs/89211
<ubotu> New bug: #96703 in libx11 (main) "Kubuntu System Settings crashes on exit" [Undecided,New] https://launchpad.net/bugs/96703
<ubotu> New bug: #186247 in sun-java6 (multiverse) "[Hardy]sun-java6-bin: suit.properties.tmp (Permission denied) (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/186247
<ubotu> New bug: #186355 in ubuntu "hardy, locking assertion failure when running netbeans (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/186355
<ubotu> New bug: #186356 in sun-java6 (multiverse) "hardy, locking assertion failure when running netbeans (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/186356
<ubotu> New bug: #188906 in sun-java6 (multiverse) "[hardy alpha4]Some trouble with sun-java (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/188906
<ubotu> New bug: #200951 in ubuntu "2.6.24-12 sound fix breaks x-server resolution (dup-of: 200797)" [Undecided,New] https://launchpad.net/bugs/200951
<ubotu> New bug: #198702 in linux-restricted-modules-2.6.24 (restricted) "Screensaver flashes the screen and does not look good" [Medium,Confirmed] https://launchpad.net/bugs/198702
#ubuntu-x 2008-03-12
<ubotu> New bug: #201253 in xserver-xorg-input-synaptics "Synaptics Driver doesn't load for Lenovo ThinkPad Travel Keyboard" [Undecided,New] https://launchpad.net/bugs/201253
<ubotu> New bug: #201257 in xserver-xorg-video-intel (main) "[Hardy] i965 TVout Interference: Gnome panel smaller than detected resolution" [Undecided,New] https://launchpad.net/bugs/201257
<ubotu> New bug: #201264 in xserver-xorg-video-intel (main) "blur and reflection compiz Ã²lugins not working" [Undecided,New] https://launchpad.net/bugs/201264
<ubotu> New bug: #201316 in ubuntu "2.6.24-12 generic kernel has no nvidia module with update. Loads safe mode. (dup-of: 200797)" [Undecided,New] https://launchpad.net/bugs/201316
<tjaalton> bryce: soren asked some time ago to change the default mouse driver to vmmouse, which falls back to using 'mouse' when the host is not a virtual machine. I could patch the server do that if it's ok?
 * soren hugs tjaalton 
<jcristau> tjaalton: will it fall back if vmmouse isn't there?
<tjaalton> jcristau: yes
<tjaalton> ah :)
<tjaalton> jcristau: I don't have any code yet
<jcristau> ok
<tjaalton> but yes, that should be considered as a must-have feature :)
<Ng> why does vmware need its own mouse driver? they emulate network cards and cdroms and allsorts, but they can't emulate a simple mouse?!
<soren> They can.
<soren> And do.
<soren> However, if the vm uses the vmmouse driver, everything just works sooo much better.
<soren> You don't have to grab the mouse input, you can just move in and out, it does absolute positioning... I recommend you try it and see for yourself.
<soren> :)
<soren> (kvm supports vmmouse, too)
<Ng> in theory I have a vmware image somewhere, but I've not used any virtualisation in anger since I bought vmware about 8 years ago ;)
<Ng> and that was just to run Outlook, of all things
<Ng> on a more useful note - what's textured video all about and why would I want to enable it? :)
<tjaalton> you wouldn't
<tjaalton> at least not now
<tjaalton> since it sucks with the current driver.. you get all the effects but it's very slow
<jcristau> you would if you want video to integrate correctly with compiz
<tjaalton> right
<tjaalton> but it eats all your cpu and more
<tjaalton> :)
<jcristau> well
<jcristau> works for me
<tjaalton> right, maybe for !965
<Ng> ok
<Ng> thanks :)
<Ng> I've not tried video yet on this chipset
<Ng> not much point until I get audio ;)
<tjaalton> the latest l-u-m should work
<Ng> it's not *that* audio bug
<Ng> this chipset just isn't supported in a released ALSA yet
<soren> Oh, new laptop?
<Ng> yep
<soren> Which one?
<Ng> X300 :)
<tjaalton> Ng: ah, loss
<soren> Oh. I thought you were leaning towards the HP.
<Ng> soren: I was, but I am weak ;)
<soren> :)
<Ng> if anyone has any clues for building LUM with a snapshot of alsa, I'm all ears, but that's getting off-topic for here I guess
<soren> Just a bit :)
<tjaalton> just as offtopic for me to ask soren why I can't install any kvm guests :)
<soren> Heh :)
<soren> tjaalton: Maybe you're not pressing the right keys?
<tjaalton> soren: there's no 'any' key :/
<soren> Hm.. Is there a XF86Any keysym? That would be pretty neat :)
<Ng> haha :)
<tjaalton> hehe ;)
<mvo> Ng: ohhhhh ... you got a X300? how sweet
<Ng> yeah, apart from probably being the first person to install linux on it, it's great ;)
<Ng> I can't find *anything* on the web about it that isn't me filing bugs ;)
<tjaalton> I'd be glad to be the first person filing bugs about it
<Ng> hehe
<ubotu> New bug: #200847 in ubuntu "ubuntu Hardy Heron update on mar 10 evening.  wiped out nvidia (dup-of: 200797)" [Undecided,New] https://launchpad.net/bugs/200847
<mvo> tjaalton: whats up with nvidia-glx-new currently? is there some conflict with it and the xserver? I got some reports about upgrades stoping because of that
<tjaalton> mvo: shouldn't be, no updates there for a while
<mvo> ok, thanks - I will investigate
<mvo> tjaalton: my bad, sorry. seems to be "envy" releated
<tjaalton> mvo: heh, ok
<ubotu> New bug: #192508 in xorg "mouse keys turns on randomly" [Low,Confirmed] https://launchpad.net/bugs/192508
<bryce> tjaalton: yep, mouse -> vmmouse is ok
<tjaalton> bryce: cool, just took a brief look at what needs to be done for it
<tjaalton> xserver-xorg-core does not currently depend on any drivers (directly), so I'm not sure if the server should check first if vmmouse is available, since it doesn't seem to do that for mouse either
<ubotu> New bug: #201421 in xorg (main) "Xorg fails to configure 945 and no USB keyboard" [Undecided,New] https://launchpad.net/bugs/201421
<tjaalton> bbl->
<ubotu> New bug: #201491 in xorg (main) "Screen DPI detected incorrectly" [Undecided,New] https://launchpad.net/bugs/201491
<bryce> tjaalton: I'm taking a sick day today.  This flu that I've been working at getting over is taking a long time to go away, and I'm feeling pretty worn out today
<tjaalton> bryce: sorry to hear that.. get well!
<bryce> btw, yesterday I coded up a little X utility - http://bryceharrington.org/files/xorg_info.c
<bryce> it determines the driver and chipset by parsing the Xorg.0.log, and collects a few other useful bits of info
<bryce> gcc xorg_info.c -o xorg_info -lX11 -lXxf86misc -lXrandr -lXv
<tjaalton> ok, I need to try it out later
<tjaalton> the live-session doesn't seem to include any headers :)
<ubotu> New bug: #201596 in xserver-xorg-video-intel (main) "xv is not working on intel 965 (x3100) when using compiz" [Undecided,New] https://launchpad.net/bugs/201596
<Ng> hmm
<Ng> that bug report seems to be the same chipset as me, and Xv seems to be fine
<tjaalton> same here
<Ng> at least, I played the nelson mandela video and it was fine ;)
<Ng> also the latest package makes scrolling in FF nice again :)
<tjaalton> yep, the new greedy patch was somehow broken
<tjaalton> running nvidia beta blob version 171.06.. still seeing pink/yellow shadows
<tjaalton> hmm, someone fixed the font rendering
<tjaalton> no more fuzzy fonts
<pwnguin> i thought that was a dpi thing
#ubuntu-x 2008-03-13
<Ng> hmm, maybe that bug report does have a point
<Ng> this laptop is struggling to play a 720p h.264 file
<Ng> interestingly it doesn't much improve in fullscreen
<Ng> although right now it is still syncing to disk because kcryptd is processing it
<Ng> I can see myself losing encrypted / over the performance loss :/
<Ng> still choppy without that
<Ng> smooth without compiz
<Ng> tjaalton: shouldn't unredirection of fullscreen windows make them perform as if compiz wasn't running?
<Ng> or is compiz stealing resouces from Xv?
<jcristau> compiz isn't involved in xv at all if you use the overlay
<Ng> well mplayer is giving me every indication that it's using Xv, but I don't see any of th eusual signs of it
<Ng> (like moving the window really fast and having the overlay lag it a little
<Ng> VO: [xv] 1280x720 => 1280x720 Planar YV12 
<Ng> whereas with -vo x11 it plays smothly
<Ng> +o
<jcristau> with -vo x11 it uses your cpu
<Ng> I know
<Ng> but Xv should perform better than x11
<Ng> not worse :)
<bryce> sorry about the performance patch; I'll look at it when I'm feeling better.  I'm sure it's something simple
<tjaalton> bryce: it touches another file now than the old patch?
<tjaalton> pwnguin: nope
<ubotu> New bug: #163865 in gnome-screensaver (main) "something steals focus of fullscreen 3d apps" [Undecided,Confirmed] https://launchpad.net/bugs/163865
<ubotu> New bug: #201741 in linux-restricted-modules-2.6.24 (restricted) "fgl_glxgears are blinking with fglrx 8.03" [Undecided,New] https://launchpad.net/bugs/201741
<tjaalton> there's no end of fglrx bugs
<Ng> woo binary drivers
<tjaalton> soren: I'd test the vmmouse-patch but can't install the build-deps because of the glibc b0rkage :)
<soren> :(
<tjaalton> jcristau_: have you looked at xf86Config.c before, and if yes do you know how to check if the driver is available (I guess it's on some array)?
<tjaalton> uh, gabor forwarded his intel/xv problem upstream
<tjaalton> hm, the vmmouse patch works, but dexconf writes mouse, so it's probably enough just to make dexconf always use vmmouse
<ubotu> New bug: #44481 in linux-source-2.6.15 "Mouse driver interferes with Wacom tablets" [Medium,Incomplete] https://launchpad.net/bugs/44481
<bryce> tjaalton: yeah the 965 fix I did in one of the 965-specific files, by Jesse's suggestion.  The broken patch has to apply across all chipsets so must be in a different file with the init call that is used for all chipsets, thus the different file
<bryce> tjaalton: sick again today :-(
<tjaalton> bryce: ah ok..
<tjaalton> bryce: sorry to hear :/
<bryce> eh, it's the hazard of having a schoolteacher for a fiancee
<tjaalton> heh, my wife is a teacher, and spent Mon-Wed home because she lost her voice last Friday :)
<tjaalton> but that's not contagious
<bryce> cool, what's she teach?
<bryce> oh hey, regarding the flgrx bugs, I was just on a confcall with amd, and they asked to see our bug list, so I'm forwarding them a link to our bug tracker
<bryce> they asked for the "top 5" but there's only 30 bugs total in lrm*24, and I figure they can just cherry pick what they want
<tjaalton> she has a 3rd grade class, and on top of that teaches Swedish for some 7th graders
<tjaalton> I tried the nvidia beta but it doesn't fix any of the bugs that I'm seeing..
<tjaalton> but nice to hear that amd shows interest
<bryce> yeah we'll see.  last time they weren't too helpful
<bryce> but yes, they're exactly the right guys to be looking at these bugs
<tjaalton> atieventsd crashes during upgrades etc. nice stuff
<tjaalton> btw I added five patches for xorg-server from the stable branch or from the proposed set, including the randr patches
<bryce> awesome
<bryce> yeah those looked very useful, although I wasn't able to link them up with any of our existing randr bugs
<bryce> ok, I'm going afk to lay down.  l8r
<tjaalton> yep, rest in peace :)
<ubotu> New bug: #201650 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/201650
<ubotu> New bug: #192299 in linux-restricted-modules-2.6.24 (restricted) "fgl_glxgears crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/192299
<ubotu> New bug: #201535 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/201535
<ubotu> New bug: #201855 in xorg (main) "X crashed seemingly at random." [Undecided,New] https://launchpad.net/bugs/201855
<ubotu> New bug: #121452 in linux-restricted-modules-2.6.24 (restricted) "splash split between screens in multihead setup" [Undecided,New] https://launchpad.net/bugs/121452
<ubotu> New bug: #201373 in linux-restricted-modules-2.6.24 (restricted) "NVidia does not work in linux-image-generic 2.6.24.12.13 (x86_64)" [Undecided,Fix released] https://launchpad.net/bugs/201373
<ubotu> New bug: #201933 in xserver-xorg-video-intel (universe) "[Hardy] vlc changes lfp brightness to xbacklight value when playing video with xv (i915)" [Undecided,New] https://launchpad.net/bugs/201933
<ubotu> New bug: #201937 in xorg (main) "[Hardy][regression] input devices (in particular Logitech mice) that require evdev to work properly are now broken" [Undecided,New] https://launchpad.net/bugs/201937
<ubotu> New bug: #201968 in linux-restricted-modules-2.6.24 (restricted) "nvidia driver not properly configured by restricted drivers manager" [Undecided,New] https://launchpad.net/bugs/201968
#ubuntu-x 2008-03-14
<ubotu> New bug: #39943 in linux-source-2.6.15 "Crash in installation" [Medium,Incomplete] https://launchpad.net/bugs/39943
<ubotu> New bug: #201936 in ubuntu "Nvidia Suspend and Hibernate not working on T61P (dup-of: 198184)" [Undecided,New] https://launchpad.net/bugs/201936
<Ng> tjaalton: see the latest comment on 201596 about texturedvideo?
<Ng> gonna try that out when I boot up at work :)
<tjaalton> oh crap
<tjaalton> I'll upgrade my laptop to be sure
<tjaalton> uh, so it turns out that I had that setting on my xorg.conf..
<tjaalton> and I see the error
<tjaalton> bryce: how do I gather the data for intel tvout quirks?
<tjaalton> there are a couple of bugs that would be easy to fix
<tjaalton> hmm think I got it
<ubotu> New bug: #201983 in linux-meta (main) "vesafb refuses mode 865 for dell XPS m1330 (dup-of: 129910)" [Undecided,New] https://launchpad.net/bugs/201983
<Ng> tjaalton: do you know what the rationale behind the backlight breaking patch was?
<Ng> can we get that reverted?
<tjaalton> no idea why it was made, and yes it should be reverted
<tjaalton> +able to get
<Ng> I'll pester some kernel people when they wake up
<tjaalton> nice
<ubotu> New bug: #202164 in xorg (main) "[hardy] displayconfig-restore causes X to crash" [Undecided,New] https://launchpad.net/bugs/202164
<Ng> tjaalton: sounds like mjg59 has also mentioned reverting that commit, the kernel people said since it's a regression we can get it in for hardy \o/
<tjaalton> rock on :)
<tjaalton> mjg59 himself suggested to revert that patch to test if it had an effect, and it did
<Ng> aha
<Ng> they were wondering about another one that they think is connected
<Ng> f1d7313019c06f76322d3069d830d16ff308f209 is the other
<bryce> tjaalton: for tvout quirks, we need the pciid - this is the 'Subsystem' id that shows up with lspci -vvnn
<bryce> it also shows up in the pci scan in Xorg.0.log, although it's not usually obvious which line is the vga card there
<ubotu> New bug: #151382 in linux-restricted-modules-2.6.24 (restricted) "nvidia with compiz and with dual core freeze" [Medium,New] https://launchpad.net/bugs/151382
<ubotu> New bug: #202220 in xorg (main) "i cant set it up to 1280*960 screen resolution, please make it work, yesteday i was wrong it was not F5555, it is FS7555 COMPAQ monitor" [Undecided,New] https://launchpad.net/bugs/202220
<ubotu> New bug: #151586 in xserver-xorg-video-intel (main) "Gutsy - Compiz windows will not maximize by default" [Undecided,New] https://launchpad.net/bugs/151586
<ubotu> New bug: #202299 in xorg (main) "Xorg appears two times in the system monitor and seems to use a lot of RAM (Hardy)" [Undecided,New] https://launchpad.net/bugs/202299
<ubotu> New bug: #179773 in xorg (main) "window borders disappear with enhanced visual effects turned on" [Undecided,New] https://launchpad.net/bugs/179773
<ubotu> New bug: #202264 in xorg "Ubuntu 7.10 - fglrx driver - ATI Technologies Inc Radeon X1200 Series does not work out of the box" [Undecided,New] https://launchpad.net/bugs/202264
<ubotu> New bug: #202261 in xorg (main) "Setting an external screen in "Screens and graphics" makes login fail" [Undecided,New] https://launchpad.net/bugs/202261
<ubotu> New bug: #202247 in xorg (main) "m1330 screen flicker" [Undecided,New] https://launchpad.net/bugs/202247
<ubotu> New bug: #202208 in xorg (main) "[Hardy] Playing OpenGL games causes a refresh rate error" [Undecided,New] https://launchpad.net/bugs/202208
<ubotu> New bug: #202244 in xorg (main) "System lockups when starting gdm with fglrx" [Undecided,New] https://launchpad.net/bugs/202244
#ubuntu-x 2008-03-15
<tjaalton> bryce: yeah, seems to be simple enough
<tjaalton> night.. 've had a few too much :P
<ubotu> New bug: #202388 in xserver-xorg-video-ati (main) "[hardy] black screen and pc unresponsive with Radeon 9600" [Undecided,New] https://launchpad.net/bugs/202388
<ubotu> New bug: #202461 in linux-restricted-modules-2.6.24 (restricted) "fglrx errors with R500" [Undecided,New] https://launchpad.net/bugs/202461
<ubotu> New bug: #202509 in xorg (main) "wrong autoconfigured monitor resolution on Eizo L365 / GeForce4 MX" [Undecided,New] https://launchpad.net/bugs/202509
<ubotu> New bug: #202515 in xserver-xorg-input-synaptics "synaptics touchpad is unusable with a macbook pro" [Undecided,New] https://launchpad.net/bugs/202515
<ubotu> New bug: #201927 in ubuntu "blind keys do not wait (dup-of: 200813)" [Undecided,New] https://launchpad.net/bugs/201927
<ubotu> New bug: #184312 in xkeyboard-config (main) "keyboard layout, french alternative, no right control" [Undecided,Confirmed] https://launchpad.net/bugs/184312
<ubotu> New bug: #202393 in ubuntu "[Firefox 3.0b4 in Hardy alpha 6] some png pictures are not displayed on web pages after a zoom in (dup-of: 182038)" [Medium,Incomplete] https://launchpad.net/bugs/202393
<ubotu> New bug: #202670 in linux-restricted-modules-2.6.24 (restricted) "Nvidia restricted driver locks system with xserver launch" [Undecided,New] https://launchpad.net/bugs/202670
<bryce> tjaalton: you around?
<tjaalton> bryce: yup
<bryce> I'm thinking if we're going to disable displayconfig-gtk for hardy, we should do it soonish
<bryce> what do you think?
<tjaalton> you mean drop it from the menu?
<bryce> we can leave it installed, just not present in the menu
<bryce> so if there are people who still are stuck with xinerama drivers, it's available
<bryce> but it won't be in the menu to confuse the vast bulk of people for whom it would just cause trouble
<tjaalton> yep, probably a good move
<bryce> ok let me do up a patch real quick
<bryce> (I'm feeling a lot better finally btw)
<tjaalton> good to hear :)
<bryce> ok, posted here http://people.ubuntu.com/~bryce/Uploads/
<bryce> (untested)
<bryce> I just stripped out the lines that enabled it in the desktop file.  Perhaps it'd be better to remove that file entirely, but hopefully that'll do it.
<bryce> do we need any special permission to upload stuff now?
<tjaalton> they'll be queued
<tjaalton> hmm, the latest d-g is 0.3.8
<tjaalton> having the desktop file allows the user to add it to the menu with the editor
<tjaalton> menu editor that is
<bryce> ok, posted a 0.3.8 version - http://people.ubuntu.com/~bryce/Uploads/
<bryce> that one just removes the categories; hopefully that's sufficient
<bryce> I'm getting to really hate X gui config tools in general
<tjaalton> :P
<tjaalton> uploaded
<bryce> thanks
<bryce> I guess I'm mostly just mad that seb keeps rejecting patches, costing days of my time, without really giving much help in trying to sort out other solutions
<bryce> it's very frustrating
<tjaalton> I can imagine..
<bryce> and upstream is no longer responding to my patches or answering questions
<bryce> and all the users are complaining about missing features and whatnot.  bleah.
<bryce> I say we go back to vi xorg.conf as our supported X configuration approach :-)
<tjaalton> hehe
 * bryce fix commits bug 144641
#ubuntu-x 2008-03-16
<ubotu> Launchpad bug 144641 in displayconfig-gtk "GUI screen config tool should generate an randr 1.2 configuration where possible" [Critical,Fix committed] https://launchpad.net/bugs/144641
<tjaalton> night
<bryce> night
<ubotu> New bug: #202712 in linux-restricted-modules-2.6.24 (restricted) "[Hardy] very poor 3D performance of fglrx" [Undecided,New] https://launchpad.net/bugs/202712
<ubotu> New bug: #199736 in mythtv "please include dvb-fe-nxt2004.fw firmware and get_dvb_firmware script" [Undecided,Invalid] https://launchpad.net/bugs/199736
<tjaalton> heh, seems that the xcb devs have fixed xlib/xcb to never make apps crash due to locking assertions. a bit too late for hardy though, I guess
<ubotu> New bug: #201466 in xorg (main) "gdm_slave_xioerror_handler error in ubuntu hardy heron Alpha 6" [High,Confirmed] https://launchpad.net/bugs/201466
<ubotu> New bug: #33339 in xrandr "Xrandr and Screen Resolution applet show huge refresh rate" [Low,Invalid] https://launchpad.net/bugs/33339
<ubotu> New bug: #39108 in linux-restricted-modules-2.6.15 "Glx-legacy freezes very often with a GeForce 4 MX" [Medium,Invalid] https://launchpad.net/bugs/39108
<ubotu> New bug: #202836 in xorg (main) "Xubuntu 8.04 alpha 6 LiveCD Russian language issue" [Undecided,New] https://launchpad.net/bugs/202836
<ubotu> New bug: #202848 in linux-restricted-modules-2.6.24 (restricted) "GeForce FX5200 drivers xorg bug" [Undecided,New] https://launchpad.net/bugs/202848
<ubotu> New bug: #202572 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202572
<ubotu> New bug: #202781 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202781
<ubotu> New bug: #202199 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202199
<ubotu> New bug: #202376 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202376
<ubotu> New bug: #202430 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202430
<ubotu> New bug: #201151 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/201151
<ubotu> New bug: #201940 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/201940
<ubotu> New bug: #202274 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV on login (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202274
<ubotu> New bug: #202855 in linux-restricted-modules-2.6.24 (restricted) "nvidia_drv.so crash after logout" [Undecided,New] https://launchpad.net/bugs/202855
<ubotu> New bug: #202863 in xserver-xorg-driver-vmware "Screen resolution in VMware is huge" [Undecided,New] https://launchpad.net/bugs/202863
<ubotu> New bug: #202872 in gnome-settings-daemon (main) "gnome-settings-daemon crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/202872
<bryce> tjaalton: something we could backport?
<ubotu> New bug: #202939 in xorg (main) "quadro nvs 130m not supported by nv driver" [Undecided,New] https://launchpad.net/bugs/202939
<ubotu> New bug: #8177 in vbetool (main) "vbetool should subsume ddcprobe, use x86emu" [Medium,Confirmed] https://launchpad.net/bugs/8177
<tjaalton> bryce: looks like it's a bit complicated for a backport
<superm1_> so with the xserver changes in not recording a resolution to debconf, that makes bug 188764 interesting to try to solve
<ubotu> Launchpad bug 188764 in usplash "[hardy]640x480 usplash on a 1024x768 LCD laptop" [High,Confirmed] https://launchpad.net/bugs/188764
#ubuntu-x 2009-03-09
<bryce__> tjaalton: you about?
<bryce__> tjaalton: trying to figure out the libdrm git merge stuff
<tjaalton> bryce__: yes, what's up?
<bryce__> tjaalton: well in this case it's not a git merge against debian but (aiui) bypassing debian to merge straight from upstream
<bryce__> tjaalton: however I cannot see the upstream branches in this git repo
<bryce__> I did find a 2.5.4-1 branch you did for debian but it's dated last Nov and seems missing a lot of stuff, so assuming that's not it
<bryce__> er s/2.5.4/2.4.5/
<tjaalton> I'll check the status
<jcristau> 2.4.5 was released in feb so it's probably not dated last nov.
<jcristau> the date in the changelog entry is from when that changelog entry was started
<bryce__> also, there's a lot of unreleased stuff queued up in the ubuntu git; there are 3 patches related to -nouveau - I'm assuming I drop all three, but there's one which is kernel headers which I'm unsure about
<tjaalton> bryce__: our kernel doesn't ship nouveau
<tjaalton> neither does upstream yet
<bryce__> so I should omit that as well?
<tjaalton> keep the parts that touch the headers
<tjaalton> 2.4.5 should have the rest
<tjaalton> um, it should have it all
<tjaalton> the parts about libdrm-nouveau should be fine
<tjaalton> bryce__: the 2.4.5 tag was added after it was released and pulled in debian, that's why it's not there I guess
<bryce__> ok, so for getting the 2.4.5 bits into our git tree, how do I finagle that?  Mind if I just skip git and merge it manually?
<tjaalton> but if you need to use another origin (=upstream), you need to add the remote
<tjaalton> or merge with debian-unstable
<tjaalton> and release as -0u1
<tjaalton> wouldn't be the first time
<tjaalton> oh, and because libdrm-intel1.symbols was fixed there, -intel wouldn't need the explicit Depends anymore :) (once built against it)
<tjaalton> a silly typo that was
<tjaalton> or rather a copy-paste error
<bryce__> is 2.4.5 in debian-unstable?
<bryce__> sorry, I'm becoming increasingly more confused here
<tjaalton> the branch yes
<jcristau> yes, 2.4.5 is in the debian-unstable git branch
<bryce__> any issues holding that branch back, or is it in a releasable state?  I.e., if I git pull that, is there any further work needed?
<jcristau> not that i know of
<tjaalton> just fix the conflicts (changelog, control, rules)
<bryce__> hmm, after dropping the nouveau patches 02 and 03, patch 04 (the headers) no longer applies
<tjaalton> drop that as well
<bryce__> ok
<tjaalton> maybe I didn't make it clear
<jcristau> the reason it's not uploaded yet is because it might break mesa and/or drivers in sid, and i don't want to do that before i can upload server 1.6.
<tjaalton> only the packaging changes are needed
<bryce__> jcristau: ok thanks; I put 1.6 in last friday so should be good to go
<bryce__> dh_install: libdrm-dev missing files (usr/include/nouveau/*), aborting
<jcristau> bryce__: remove that from debian/libdrm-dev.install
<bryce__> ok
<tormod> bryce_: or configure with --enable-nouveau-experimental-api=yes
<crdlb> is jaunty's X supposed to include the log file path in 'xset q'?
<jcristau> no
<crdlb> the compiz wrapper script currently uses that; is there an alternative?
<jcristau> no
<jcristau> :)
<tormod> crdlb: what does it use the log for?
<crdlb> to make sure you're using a good driver
<jcristau> it should stop doing that
<tormod> you should rather check it is using a good 3D driver
<crdlb> it's a workaround for the fact that checking that isn't reliale
<crdlb> reliable*
<crdlb> eg, last I saw, nv will happily whitescreen you with compiz
<jcristau> nv is not a 3d driver
<tormod> you should use "xdriinfo driver 0"
<jcristau> tormod: doesn't work with dri2
<crdlb> right, but it still reports GLX_EXT_texture_from_pixmap even though it's not really supported with software mesa
<tormod> jcristau: oops. but who uses dri2 :)
<jcristau> nv doesn't report anything related to 3d...
<jcristau> maybe swrast does, but if you know you're on swrast you can bail out anyway
<jcristau> and that doesn't need the Xorg log
<tormod> xdriinfo will return "swrast" in that case, no?
<jcristau> tormod: dunno, but glxinfo will tell you 'OpenGL renderer string: Software Rasterizer'
<bryce__> dh_install: debian/tmp/usr/include/drm/nouveau_drm.h exists in debian/tmp/ but is not installed to anywhere
<bryce__> dh_install: debian/tmp/usr/include/drm/xgi_drm.h exists in debian/tmp/ but is not installed to anywhere
<bryce__> dh_install: debian/tmp/usr/include/drm/via_3d_reg.h exists in debian/tmp/ but is not installed to anywhere
<bryce__> dh_install: debian/tmp/usr/include/drm/r300_reg.h exists in debian/tmp/ but is not installed to anywhere
<bryce__> dh_install: missing files, aborting
<bryce__> make: *** [binary-arch] Error 1
<crdlb> yes, the wrapper already checks for swrast with glxinfo
<crdlb> I guess it was more necessary before swrast, since LIBGL_ALWAYS_INDIRECT=1 glxinfo would still report t_f_p then
<tormod> bryce__, maybe we can add fglrx cruft detection to the -ati or xorg apport hook?
<bryce__> tormod: love to see a patch
<bryce__> tormod: what is your idea re apport hook?  
<tormod> bryce__: I have to admit I never looked at an apport hook...
<tormod> But I imagined something grepping dmesg (or kern.log) for fglrx modules bits for instance
<bryce__> tormod: and then include that in the bug report, or are you thinking it should inhibit bug reporting in this case?
<tormod> no, it should add it to the bug report, maybe adding the wiki link so the reporter can clean up, and ask the reporter to close the bug if it fixes it.
<bryce__> yeah that should be doable with apport
<bryce__> tormod: if you write a python script that implements that idea, I can integrate it into apport proper
<tormod> bryce__: I looked at the current ati hook, added this:
<tormod>     try:
<tormod>         script = subprocess.Popen(['sh', '-c', 'grep fglrx /var/log/kern.log'], stdout=subprocess.PIPE)
<tormod>         report['fglrx'] = script.communicate()[0]
<tormod>     except OSError:
<tormod>         pass
<bryce__> ok
<tormod> that was just monkey copy and paste but you get the idea
<bryce__> okay, committed to git
<tormod> bryce__: cool! we can think about the wiki link later. these sections ends up as attachment right? I will read up about apport another day.
<bryce__> right
<bryce__> yeah I suspect most users wouldn't read the bug report and see the wiki link
<bryce__> I think it is also possible that we could make apport prevent filing the bug if fglrx is installed, and maybe display an error dialog with that wiki link on it (or equivalent directions), but that's beyond my apport-fu at the moment
<bryce__> whew, libdrm has built
<bryce__> ok, reboot time, brb
#ubuntu-x 2009-03-10
<bryce> libdrm2 uploaded
<bryce> tjaalton: when you get a chance, I'd love to have your review on it, to make sure I haven't loused things up too badly
<bryce> I ended up keeping all the nouveau stuff using tormod's config option
<bryce> dunno if it works though, it would be nice if someone could test it out
<bryce> I've tested on -intel and it seems ok; -amd could use a doublechecking
<tjaalton> bryce_: did you push your changes?
<bryce_> tjaalton: for libdrm?  I thought so
<bryce_> bryce@chideok:~/src/libdrm/libdrm-ubuntu-git-2.4.5$ git commit -a
<bryce_> # On branch ubuntu
<bryce_> nothing to commit (working directory clean)
<bryce_> bryce@chideok:~/src/libdrm/libdrm-ubuntu-git-2.4.5$ git push origin ubuntu
<bryce_> Everything up-to-date
<bryce_> guess so
<bryce_> I've got -intel merged and ready to go, but it isn't building
<tjaalton> hmm ok, didn't see the message on debian-x@, but maybe it's just my filters
<bryce_> I guess libdrm hasn't hit the mirrors yet or something.  Seems to be building ok - https://edge.launchpad.net/ubuntu/jaunty/+source/libdrm/2.4.5-0ubuntu1
<tjaalton> I'll probably have time to look at it today
<tjaalton> but if it builds.. :)
<bryce_> since alpha-6 is frozen just now, I'm debating about whether to hold off on doing -intel
<bryce_> oh also tim gardner's in town so I talked with him about the -ati drm kernel stuff, gave him airlied's tree/branch, and he'll be pulling it in maybe tonight
<tjaalton> oh
<bryce_> so I'm wondering whether to put in a git snapshot of -ati while I'm at it...
<bryce_> or wait until post alpha-6 for that.  maybe that'd be safer
<tjaalton> that'll give accelerated 2d on r6xx+
<bryce_> right
 * bryce_ growls at bug reporter on 247771
<tjaalton> heh
<tjaalton> we sold our flat last week btw, it took only three days
<bryce_> whoa, congrats
<bryce_> that's the hard part, in this market ;-)
<tjaalton> now we have two months to find a new place
<tjaalton> yea
<tjaalton> h
<bryce_> think that gives you enough time?
<bryce_> how tight are your criteria?
<tjaalton> our neighbor has their flat on sale since August, and the buyers had been looking at that for some time but weren't pleased with it, so when our flat came up they contacted us immediately
<bryce_> heh, nice
<tjaalton> well, there are a couple of candidates, but they all tend to have something wrong with them
 * bryce_ nods
<tjaalton> so we need at least three bedrooms and an office
<tjaalton> third kid on the way..
<tjaalton> due next August
<bryce_> congrats again :-)
<tjaalton> thanks :)
 * bryce_ still working on 1st
<tjaalton> oh and that also means that I'll have to get another car :/ :)
<tjaalton> but I'm not into SUV's (even the "european" kind), so the list of models that can take three kid seats isn't long
<bryce_> you could get a pickup and then just throw them all in the bed
<bryce_> if one pops out, well you got spares
<tjaalton> hehe :)
<bryce_> yeah 5 person family kind of rules out the cooler cars...
<tjaalton> my first porsche will have to wait :)
<bryce_> hey you could get a Humvee
<bryce_> then when the kids grow up, you can replace the babyseat with a mounted SMG.  now that would be cool
<tjaalton> there's one in the neighborhood :)
<bryce_> an SMG?  wow, no wonder you want to move
<tjaalton> without any cool gadgets :)
<bryce_> ah
 * bryce_ urfs at bug 339982
<ubottu> Launchpad bug 339982 in xorg "X hangs for no apparent reason" [Undecided,New] https://launchpad.net/bugs/339982
<tjaalton> "that happens"
<bryce_> yeah
<bryce_> I wish we had a better procedure for troubleshooting X hangs
<bryce_> wow, why do we get so many -nvidia bug reports?
<tjaalton> a cynical answer would be that because people use it even if it's buggy :)
<bryce_> but why do they keep insisting on reporting bugs about it??
<tjaalton> out of despair..
<bryce_> silly fools
<tjaalton> but now we have tseliot working on them full time ? :)
<bryce_> some day I'm going to write a script that scans the xorg bugs and moves all the bugs mentioning nvidia to the appropriate tracker, and give some automatic message about the iniquity of running proprietary drivers, and the hopelessness of trying to get support for them
<bryce_> I have a feeling tseliot will be too busy with oem stuff
<bryce_> I'm also going to write a script that looks at xorg bug reports with fewer than 3 lines of description and just auto-close them as "not enough info"
<tjaalton> ah, so that's what he was appointed to
<tjaalton> afk, gone to work->
<bryce_> heh, queried all the -177 bugs for patches... nada
<tjaalton> nvidia? hardly surprising ;)
<bryce_> at least I checked ;-)
<bryce_> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/98548
<ubottu> Ubuntu bug 98548 in nvidia-graphics-drivers-177 "[nvidia-glx-new] X hung ups on GeForce Go 7600" [Undecided,Incomplete]
<bryce_> (it's +1 month)
 * bryce_ begins the -nvidia -177 bug massacre with https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/279571
<ubottu> Ubuntu bug 279571 in nvidia-graphics-drivers-177 "compiz + nvidia anti-aliasing = problems with opacity and shadows (several blinking effects)." [Medium,Invalid]
<bryce_> good night
<tjaalton> night
<tjaalton> bryce_: the libdrm merge looks fine, but did you touch the 2.4.5-1 changelog entry? looks like some parts were dropped from there
<Ng> does libdrm 2.4.5 bring anything exciting? :)
 * Ng still needs to track down what's causing occasional X deaths
<bryce_> hrm, the libdrm 2.4.5 didn't enable -intel 2.6.3 to build
<bryce_> tjaalton, jcristau: does the -intel 2.6.2/.3 driver also require kernel drm changes?
<bryce_> hrm, yeah /usr/include/drm/i915_drm.h is provided by linux-libc-dev now, however the changes 2.6.2/.3 needs are in libdrm
<bryce_> bugger
<bryce_> looks like we need http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=0f973f27888e4664b253ab2cf69c67c2eb80ab1b in the kernel
<mnemo> after install updates just now my xorg no longer starts on intel g45
<mnemo> I get:
<mnemo> /etc/gdm/Xsession: Beginning session setup...
<mnemo> /etc/X11/Xsession.d/60x11-localhost: 4: Syntax error: Bad fd number
<mnemo> is that a known issue?
<mnemo> this is my 60x11-localhost file:
<mnemo> http://pastebin.com/f66a6fde
<mnemo> the >& part looks like a typo
<mnemo> that file ships in x11-common
<tjaalton> bryce_: yes, it'll need some commit(s)
<mnemo> bryce_: and x11-common was updated by you today according to debian/changlog
<bryce_> mnemo: that's right
<mnemo> the file in the source package has the same typo
<seb128> urg
<seb128> if that's a change which will breaks x startup for everybody upgrading better to hurry on a new upload
<mnemo> i think it is yeah
<bryce_> seb128: yeah this is the change asac had asked for
 * crevette stops its upgrade
<mnemo> bryce_: my xorg starts again with I just leave out the &
<bryce_> https://bugs.edge.launchpad.net/ubuntu/+bug/276357
<ubottu> Ubuntu bug 276357 in xorg "disable xauth for local users" [High,Fix released]
<bryce_> mnemo: hmm
<mnemo> bryce_: yeah its bash typo only
<mnemo> the xauth fix is good but the redirection is bad
<bryce_> this is identical to what redhat used and asac asked for - http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.2&view=markup
<mnemo> they probably meant 2>&1 > /dev/null or just ">/dev/null"
<mnemo> hmm, strange maybe the RH guy did the typo then?
<mnemo> i've never seen >& before but im not bash expert
<bryce_> maybe they use a better shell than us ;-)
<mnemo> yeah
<seb128> did anybody test this change?
<bryce_> I've seen >& elsewhere before
<crdlb> he probably meant &>
<seb128> mnemo: could you open a bug about that so we can track the issue?
<mnemo> will do
<mnemo> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/340676
<ubottu> Ubuntu bug 340676 in xorg "xorg fails to start due to "bad fd number"" [Undecided,New]
<mnemo> i think the default sh in ubuntu is dash and the default sh in fedora is bash, isnt that so?
<mnemo> still that doesnt look like valid bash to me
<crdlb> does that script get run by sh? I'm pretty sure &> is a bashism anyway
<mnemo> the upstream version has #!/bin/sh
<mnemo> but the ubuntu version doesnt have it
<mnemo> so maybe it's some weird sh:ism
<mnemo> I'll test it
<mnemo> hmm its sourced by Xsession though so I cant just add #!/bin/sh to test it
<mnemo> bryce_: what command can I use to install the 5ubuntu15 version?
 * maxb is puzzled. packages.ubuntu.com claims that no package contains an 60x11-localhost in any release.
<mnemo> maxb: use "dpkg -S 60x11-localhost"
<maxb> I don't have an /etc/X11/Xsession.d/60x11-localhost file
<mnemo> maxb: did you install the latest updates for jaunty? I think bryce added just now
<maxb> I can't see any recent uploads of x11-common in jaunty-changes
<maxb> oh, there it is
<maxb> Hmm, the jaunty-changes emails seem to be lagged several hours behind uploads
<mnemo> bryce_: do I need to enable some special repo to test it, or should I fetch the .deb from somewhere and "dpkg -i" on it? this is what I see now --> http://pastebin.com/m6603bd85
<bryce_> mnemo: should be in the regular repo soon.  I basically just backed out the &> change
<mnemo> mmkay
<bryce_> uf, it's lunchtime and I still haven't had breakfast...  bbiab
<maxb> bryce: a small thing... but the new 60x11-localhost doesn't follow the naming convention that seems to be established for Xsession.d entries, of NNpackagename[_suffix]
<bryce> maxb: good point
<bryce> maxb: I can't fix it easily at the moment; please file a bug to do the rename and assign to me
<maxb> will do
#ubuntu-x 2009-03-11
<tjaalton> bryce: note that files in /etc are conffiles, and removing them needs extra care
<tjaalton> so just renaming it means that people will have them both
<bryce> tjaalton: oh for 60x11-localhost?
<tjaalton> yes
<bryce> how should it be done?
<tjaalton> there are examples in that package
<tjaalton> can't remember which script it was
<tjaalton> x11-common.postrm
<bryce> I'll have you review before I put in any changes
<bryce> thanks for the heads up.
<tjaalton> this is why I think the scripts should be in /usr/share/X11 or something
<bryce> probably so
<tjaalton> and leave /etc/X11/Xsession.d for the admin
<bryce> yeah I think too much gets in /etc/X11 in general
<tjaalton> I should probably fix mesa too at some point.. there's this script for fglrx which is obsolete, and the removal isn't handled properly
<tjaalton> did you notice the comment about libdrm changelog?
<tjaalton> looks like you edited the 2.4.5-1 entry
<tjaalton> hum, shower->
<bryce> no missed that
<bryce> tjaalton: what was the problem?
<tjaalton> bryce: see the commit diff: http://git.debian.org/?p=pkg-xorg/lib/libdrm.git;a=commitdiff;h=cf2534023a3fdce5b7a44b50d76defaa78ff78be
<tjaalton> two missing changelog entries from 2.4.5-1
<bryce> ah sorry
<bryce> boy, git and I really don't get along.
<tjaalton> well it's due to a merge error, and no VCS could get it right :)
<tjaalton> normally I'll first take what's in debian and then apply our changes on top of it
<tjaalton> using meld
<bryce> the sad thing is that the libdrm merge was worthless anyway, because -intel still won't build
<tjaalton> but nouveau can be synced now :)
<bryce> depends on some 2-line change needed in kernel drm code :-(
<tjaalton> that's how it's going to be in the future
<tjaalton> although it's been mostly an issue with intel, since they are changing things all the time
<tjaalton> a stable driver? haha
<bryce> yeah I know.  I talked with tim about it yesterday and today
<bryce> it's going to suck
<tjaalton> someone from the kernel team should monitor the upstream drm code I guess
<tjaalton> but maybe it's too much overheaed
<tjaalton> -e
<bryce> well, I guess if the changelog was the only thing messed up in the merge, that's pretty good, I worried more that there was something wrong in the .install's or something
<tjaalton> did you bump the version in rules? (dh_makeshlibs -plibdrm2 -V'libdrm2 (>= 2.4.5))
<tjaalton> afaik no new symbols were added since 2.4.3, which is what debian has
<bryce> I did bump the version, however I didn't know if that was needed or not
<tjaalton> it'll make drivers built against this version not work with 2.4.3 while they should, but it's not a huge issue
<tjaalton> meaning packages will depend on libdrm 2.4.5 and fail to install if only 2.4.3 is available
<bryce_> wow, https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs is messed up
<popey> is there general broken-ness in the evtouch input driver at the moment? I am getting xorg blowing up on calibrate
 * popey has asked his mate to file bug 341215
<ubottu> Launchpad bug 341215 in xf86-input-evtouch "[Jaunty] calibration crashes xorg on HP TX1000" [Undecided,New] https://launchpad.net/bugs/341215
<bryce_> popey: did you look in lp?
<popey> there is a couple of older reports that claim to be fixed
<bryce_> popey: then afaik there is no general brokenness.
<popey> bryce_: guess that depends how common the evtouch is
<bryce_> you've not provided enough info in your bug report to say
<popey> what's needed?
<bryce_> http://wiki.ubuntu.com/X/Reporting
<popey> i used ubuntu-bug so expected that to attach everything
<bryce_> I think it's not set up for -evtouch
<bryce_> I probably should fix that
<popey> want me to file a bug? :)
<bryce_> nah I'm fixing it presently
<popey> ta
<popey> just realised this is using binary nvidia, bryce_ , should I test with nv too?
<bryce_> yep; if it's an -nvidia problem there's hardly anything we can do
<popey> ok, will test under both
<bryce_> btw, why do you use -nvidia?
<popey> its not my pc
<popey> but the user is new to ubuntu, and i think he likes the 3d desktop stuff
<bryce_> hmm
<bryce_> if you and he ever feel like experimenting, there is also the -nouveau driver
<bryce_> we don't officially support it in canonical yet, but it's been getting lots of improvements lately and in karmic we may be looking at relying on it more
<bryce_> it would be interesting to hear if it works adequately for people's needs yet
<popey> yeah, thats an idea
<popey> didn't even realise it was packaged
<bryce_> yep
<bryce_> ok, added a bunch more x packages for apport support to our git tree.  once alpha6 freeze is over it'll get uploaded.
<popey> thanks
<popey> ok, bryce_ it happens with -nv too
<bryce_> good, so it's something we can presumably fix
<bryce_> make sure the bug report has the necessary info (Xorg.0.log, lshal, etc.)
<bryce_> popey: also, did you try -evdev with this device?  It doesn't work with all input devices but it'll probably become the universal input driver going forward
<bryce_> I think it doesn't handle touch devices very well yet though
<popey> bryce_: not yet
<bryce_> ok, worth trying just in case
<popey> bryce_: will go back there and get all the debug stuff, need to add dbgsyms etc to get a meaningful trace i guess
<bryce_> yep
<popey> thanks for the help
<bryce_> sure, I'll subscribe to the bug to catch the updates for you
<bryce_> s/for/from/
#ubuntu-x 2009-03-13
<stgraber> bryce_: Any hope of having bug 327484 fixed by release or should I just add a hack in LTSP to force that device to use VESA instead of geode ?
<ubottu> Launchpad bug 327484 in xserver-xorg-video-geode "X crashing with Geode GX2 on Jaunty" [Undecided,New] https://launchpad.net/bugs/327484
<bryce_> tjaalton: when you get a chance please review the patch I posted on bug #340807
<ubottu> Launchpad bug 340807 in xorg "Rename /etc/X11/Xsession.d/60x11-localhost to match convention" [Undecided,New] https://launchpad.net/bugs/340807
<bryce_> stgraber: it needs a "bt full"
<bryce_> stgraber: I probably won't have time to do a fix for it for jaunty unless it's something trivially easy like a nullptr ref
<stgraber> bryce_: bt full attached
 * stgraber should have put it in a file and attached the file
<bryce_> it's ok
<bryce_> hmm
<bryce_> replying on bug...
<stgraber> if you need any more information, I have that thin client right next to me with gdb opened on the X server
<bryce_> ok yeah
<stgraber> only limitation is that it doesn't have an harddrive and only has 90MB of RAM so can't store big files in the ramfs
<bryce_> ok, reply on bug
<stgraber> bryce_: attached the gdb output you requested, not sure it's really helpful most only contains line numbers without any real content (function name, ...)
<bryce_> stgraber: yeah, you're just stepping in the signal handler code there
<bryce_> stgraber: anyway, I guess forward it upstream; probably not something we can fix at the ubuntu level
<stgraber> ok, so I should force it to VESA for now ?
<stgraber> I have 800 of these deployed :) so I need them to at least open a gnome session.
<tjaalton> bryce_: sure
<tjaalton> bryce_: hmm, the postrm tries to rm 99xorg-localhost, when it was called 60x11-localhost?-)
<tjaalton> I'll add a comment on the bug
<bdmurray> bryce_: bug 341720 isn't really in compiz is it?
<ubottu> Launchpad bug 341720 in compiz "compiz.real crashed with SIGSEGV in glXCreateContext()" [Medium,New] https://launchpad.net/bugs/341720
<bryce_> bdmurray: here's the error - dlopen: /usr/lib/xorg/modules/extensions//libglx.so: undefined symbol: miInitVisualsProc
<bdmurray> bryce_: right so it's failing since glx is missing?
<bryce_> bdmurray: no; either the user tried to load fglrx (which isn't available yet for Jaunty), or they tried to load radeon but still had fglrx kernel module junk installed
<bryce_> so either way it's a user configuration issue, not compiz
<bryce_> both problems are already reported, so whichever issue it is, the bug's a dupe
<bryce_> bdmurray: from the log it sounds like an xorg.conf was used, but none is attached the the bug; that would be sufficient to determine which issue it was
<bdmurray> bryce_: the compiz package hook doesn't grab that, do you think it should?
<bryce_> yep
<bryce_> whatever the case is, you can refer them to https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver since that's what they need
<bryce_> bdmurray: probably you also want to look in the kernel modules to see if fglrx or nvidia is loaded, and flag those situations, since those bugs will likely be unfixable by us
<bdmurray> I think apport flags those kernel modules anyway
<bryce_> e.g.:
<bryce_>     try:
<bryce_>         script = subprocess.Popen(['grep', 'fglrx', '/var/log/kern.log', '/proc/modules'], stdout=subprocess.PIPE)
<bryce_>         matches = script.communicate()[0]
<bryce_>         if (matches):
<bryce_>             report['fglrx-loaded'] = matches
<bryce_>     except OSError:
<bryce_>         pass
<bdmurray> NonfreeKernelModules: fglrx
<bryce_> hmm, where's that flagged?
<bryce_> I see it in ProcModules.txt and Xorg.0.log
<bdmurray> right in the description see bug 342501 as an example
<ubottu> Launchpad bug 342501 in firefox-3.0 "Work offline in ProfileManager does nothing" [Medium,Confirmed] https://launchpad.net/bugs/342501
<bdmurray> oh, its not flagged in the compiz bug we are looking at
<bryce_> ok right, but for some reason it's not flagged on ... right
<bdmurray> because no Nonfree ones are in use
<bryce_> but "fglrx" is shown in http://launchpadlibrarian.net/23780003/ProcModules.txt
<bryce_> fglrx is also in http://launchpadlibrarian.net/23780008/XorgLog.txt
<bryce_> so both the kernel module and X driver module are installed and being loaded.  Not sure why it's not being flagged
<bryce_> you can see though that the fglrx version is wrong... in the Xorg.0.log it complains:
<bryce_> [atiddxSetup] X version mismatch - detected X.org 7.1.-1.902, required X.org 7.4.-1.906
<bryce_> I'm interpreting that to mean "Hey, this driver is compiled for X.org 7.1 but we need 7.4"
<bryce_> anyway, X600 should be quite finely supported with -ati, no need for fglrx
<bryce_> tjaalton: http://people.ubuntu.com/~bryce/totals.svg
#ubuntu-x 2009-03-14
<tjaalton> bryce_: nice drop during the past week :)
<bryce_> tjaalton: drop?
<bryce_> oh on the graphs
<bryce_> yeah, launchpad seems to be busted :-(
<bryce_> already filed a bug about it
<bryce_> tjaalton: in other news, I'm going to be having a baby boy :-)
<tjaalton> bryce_: woohoo, congrats!
#ubuntu-x 2010-03-15
<MarcoPau> nobody?
<verbalshadow> Sarvatt: thanks, i'll file a bug soon on the ati drivers
<bjsnider> libv, i read the phoronix story about this "greater modularization" but i don't see how the current system differs
<bjsnider> isn't it already modularized?
<libv> bjsnider: it isn't
<libv> xserver is
<libv> everything else isn't
<bjsnider> i like how you're going directly around the developers to the users
<libv> libdrm is not just libdrm, it is also libdrm_intel, libdrm_radeon, libdrm_nouveau
<libv> all tracked with a single version number
<bjsnider> i don't know if you're right or they are, but your tactic is populist in nature
<libv> populist?
<libv> what?
<libv> i am the least populist X.org developer.
<bjsnider> well, you're encouraging users to use your git tree instead of main right?
<libv> and with that, the least popular.
<libv> i am doing this to prove my point
<libv> people claim that what i am doing is utterly impossible
<libv> and therefor try to shut me and my ideas up, and keep things in a broken state for everyone
<bjsnider> what point are you trying to prove?
<libv> that it is not impossible, and that it actually makes quite a lot of sense.
<libv> people can no longer use this clearly false argument
<bjsnider> what are you trying to prove is possible?
<libv> to modularize out the dri drivers from mesa.
<bjsnider> why would that be desirable?
<libv> *sigh*
<libv> http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1
<Sarvatt> RAOF: I believe you actually need to use the noaccel nouveau module option instead of xorg.conf now, think thats a relic of UMS
<RAOF> Sarvatt: I was wondering that myself, so I tested it :)
<Sarvatt> oh spiffy, sorry then :)
<RAOF> I got a *wonderfully* slow X server, using ShadowFB.
<Sarvatt> i'm going to suggest they just disable Xv instead of completely disabling accel
<RAOF> But the Xv issue is not the only one - there's the corruption of the desktop wallpaper, too.
<Sarvatt> ohh missed that, I need to stay away from bugs when I'm half asleep :)
<Sarvatt> RAOF: didn't karmic have clutter 0.8.x that netbook-launcher used? i'm positive 0.8.x needed opengl 1.4 support and that person using savage in that bug had 1.2
<Sarvatt> they didnt lower it to opengl 1.2 until after clutter 1.0
<RAOF> I'm not sure.  Regardless, savage shouldn't be SIGSEGVing on glGetString (GL_EXTENSIONS); as far as I can tell there's a GL context bound.
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/netbook-launcher/+bug/467474 (sorry had to dig it up)
<ubottu> Launchpad bug 467474 in netbook-launcher "netbook-launcher crashed with SIGSEGV in glGetString()" [Medium,Triaged]
<RAOF> Clutter certainly wasn't checking for 1.4 and erroring out if it didn't find it.
<superm1> bjsnider, i'm here on and off, please ping with specific questions though
<pgraner> bryceh: you about?
<Sarvatt> anyone know a way to force firmware into the initrd if the module doesn't claim it needs it? want to figure it out for nouveau blob ctxprogs usage
<Sarvatt> hmm what to do about the nvidia-settings issue.. -96 and -173 can't load the X display configuration page in nvidia-settings because some of the extensions from newer drivers (NoScanout) aren't available in the older drivers and it fails to load
<Sarvatt> upstream ones work of course because they bundle the right nvidia-settings with the blobs
<bryceh> Sarvatt, file a bug report and assign to tseliot
<Sarvatt> want me to latch onto an existing or file a new one and dupe the others to it?
<Sarvatt> theres a *lot* of others, would be faster to do a new one and dupe as i come across them if thats ok
<bryceh> yep that's fine
<Sarvatt> alrighty https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-settings/+bug/539196
<ubottu> Launchpad bug 539196 in nvidia-settings "nvidia-settings X display configuration window doesn't work on nvidia-173 and nvidia-96" [Undecided,New]
<rye> Hello. Having found about nVidia GPU overhearing with their proprietary drivers and experiencing substantial redraw slowdown with their latest version I decided to give nouveau a second try.
<rye> Is there anything particular required to set up to make it work with current lucid on GeForce 8400M ?
 * rye was here not so long ago running in circles, screaming and shouting about nvidia, blacklist and /usr partition
<rye> So far - no nvidia modules installed, blacklist rules are removed. Plymouth is not starting up. With no other options, kernel modesetting is enabled and after X starts, it gives a static green-bars image
<rye> with kernel modesetting disabled (i believe that's nouveau.modeset=0) I can get to X, but the resolution is 800x600 on 1280x800 screen.
<rye> no xorg.conf is present, defaults are applied
<tjaalton> rye: nouveau only supports kms, so with nomodeset you probably get -nv or vesa?
<rye> tjaalton, hm, vesa. Right
<rye> tjaalton, ok, by default kms is enabled, so if I don't get it working then that's a bug
<rye> ?
<tjaalton> sure
<tjaalton> try booting without splash
<rye> I mean is there anything I can do to get some useful debug info, I remember having nouveau working in the past... a week ago?
<bryceh> tjaalton, heya
<vish> bryceh: hi , Bug #515548 , was due to a bug in the radeon drivers , afaik , nothing to do with the kernel , shall i revert the status that the automatic script set?
<ubottu> Launchpad bug 515548 in xserver-xorg-video-ati "Radeon errors overflow in gdm logs. Makes root run out of space." [Undecided,Incomplete] https://launchpad.net/bugs/515548
<bryceh> vish, have you tested it against the latest drm?
<vish> bryceh: i havent tried the ppa , but i'm running the latest lucid kernel , with the xedgers ppa , which fixed the problem
<vish> havent yet tried drm ppa*
<bryceh> vish, don't need to test the drm ppa anymore, it's now in lucid
<bryceh> vish, mention that the -radeon from the xorg-edgers fixed the problem, and indicate the exact package name and date, since stuff in xorg-edgers changes day by day
<bryceh> vish, if you can identify the exact patch / changeset which solved the issue, attach the patch to the bug report.  That will up the priority on the bug report
<vish> bryceh: ah , ok. so the status can be reverted? Sarvatt added the fix for the bug in xedgers ppa. now sure if it landed in karmic , i have mentioned the changes required in the comments 
<vish> s/karmic/lucid
<vish> bryceh: comment 4 and 3 those are the patches we need to fix the bug
<bryceh> yes if you do those things set the status to Confirmed
<rye> tjaalton, hm, the neighbor notebook with ATI Radeon - M52 [Mobility Radeon X1300] can't get to GDM as well, disabling with radeon.modeset helps.
<rye> is there any known regression that may make two substantially different kms-enabled devices to stop working suddenly (i.e. my Nvidia GF 8400m w/ nouveau and ATI Mobility Radeon X1300) ? Checking whether Intel netbook follows those two
<rye> tjaalton, by 'can't get to GDM' i mean that for ATI the plymouth screen stays when X is supposed to be there. checking now with splash disabled.
<rye> starting w/o splash works for ATI, hm, plymouth is at 0.8.0~-14
<tjaalton> bryceh: howdy
<tjaalton> rye: probably something plymouth related then
<tjaalton> afk ->
<Sarvatt> woohoo, super major r600+ improvement in -ati just landed, 10x performance increase in DFS which was the biggest complaint about those chipsets i've seen
<rye> hello again, is "(EE) [drm] failed to open device" supposed to be in Xorg with nouveau?
<Sarvatt> flash uses DFS a ton and it was really slowing things down with KMS on r600+
<Sarvatt> vish: both the ddx and libdrm fixes for your bug have been in lucid proper for awhile, no need to use edgers
<johanbr> rye, I've seen that when the kernel/libdrm/X versions are not in sync
<Sarvatt> rye: need more full logs to troubleshoot, could be a ton of things
<Sarvatt> regarding the drm failed to open device problem at least
<rye> Sarvatt, ok, will make sure that I am running latest as of now
<Sarvatt> you're using stock lucid not a PPA right?
<rye> Sarvatt, hm... let me find out. I should not be using PPA, but that rang a bell
<rye> PPA
<rye> awesome
<rye> Sarvatt, I have to apologise for the noise, again. Will file a bug against myself to check the origin of the packages installed. OTOH i verified that the packages in PPA do not work :)
<vish> Sarvatt: thats good to know  , thanks :)
<rye> Sarvatt, with stock lucid packages I get usable GDM + Plymouth shiney
 * rye tries to set up multihead now. Silences himself for at least 30 minutes
<Sarvatt> what PPA were you using?
<rye> Sarvatt, xorg-edgers-nouveau-lucid
<Sarvatt> oh, didnt realize that had my packages in it, guessing my hooks to blacklist nouveau and vga16fb arent working
<Sarvatt> i haven't tested it on nouveau at all so I have no idea if anything is screwed up
<Sarvatt> wife has had my nouveau laptop for the past few days :(
<bjsnider> yeah, it's aaalll the wife's fault
<Sarvatt> so I think we need to change /lib/udev/rules.d/69-xserver-xorg-input-synaptics.rules to ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ATTRS{idVendor}=="056a", ENV{x11_driver}="wacom"  or something for starters
<Sarvatt> to stop wacom from claiming all tablet devices
<Sarvatt> serial tablets of other brands should be covered by the pnp subsystem checks at the top
<bryceh> Sarvatt, that'll make it fall through to -evdev?
<Sarvatt> hmm wait, need to look at some logs to see whats happening. TOUCHSCREEN and TABLET are seperate matches already
<Sarvatt> really need to find a darn cheap touchscreen somewhere to mess with this
<Sarvatt> INPUT_TOUCHSCREEN stuff is getting shoved over to wacom for some reason
 * Sarvatt tries to find superm1's bug report again..
<bryceh> Sarvatt, tjaalton:  I brainstormed some todo's that need done between now and lucid release, to help coordinate efforts...  https://wiki.ubuntu.com/X/Projects
<bryceh> Sarvatt, tjaalton: if you can think of things not on that list, let me know and I'll add them
<bryceh> and if there's any tasks you want to have ownership on, let me know that too (or just mark yourself the owner in that list)
<KiBi> :W 7
<KiBi> oops, sorry.
<Sarvatt> superm1: Dell actually has drivers for your devices touchscreen under ubuntu that just need updating to the latest ones with xserver 1.7 support, do you have access to the source package to update it?
<Sarvatt>  http://support.dell.com/support/downloads/driverslist.aspx?os=UD94&catid=-1&dateid=-1&impid=-1&osl=EN&typeid=-1&formatid=-1&servicetag=&SystemID=LAT_2100&hidos=LNUX&hidlang=en&TabIndex=&scanSupported=False&scanConsent=False
<Sarvatt> Latitude 2100
<Sarvatt> thats a deb package of the blob drivers I linked for you the other day, cant seem to download it completely to check it out though
<Sarvatt> bryceh: Investigate/develop way to override video settings when KMS is used (work with kernel team) -- I have been toying with that in my free time, I managed to get xforcevesa working partially by adding a check in initramfs-tools for it, blacklisting drm i915 nouveau and radeon modules if its there, and having the gdm init script exit1 so failsafeX is used when its on the command line
<Sarvatt> the only hinderance I've had is actually making the blacklisting stick, late in the boot process drm/i915 is loaded even if its blacklisted
<Sarvatt> so failsafeX is working but its fbdev on top of KMS
<bryceh> mm
<Sarvatt> couldn't figure out why it was happening, i think I might have to extend the /proc/cmdline checks in plymouth that check for single to not load if xforcevesa exists as well which would be easy
<bryceh> Sarvatt, sounds like good progress though
<bryceh> Sarvatt, do you want to take ownership of this task, or just be listed as a resource/contact?
<Sarvatt> sure, I think I can get it working soon but I dont have commit rights to the relevant packages so it might not be appropriate
<Sarvatt> i'm not sure if I'm going about it the right way, theres a whole lot of options to do it
<bryceh> ok, I'll jot you down.  I'll be happy to take care of sponsoring where you need committing
<Sarvatt> wasn't sure about what arg to use either, just went with xforcevesa for now since that was around before
<tjaalton> bryceh: ok, mesa 7.7.1 and xserver 1.7.6 probably should be on the list. also wacom 0.10.5 which is hopefully released soonish
<bryceh> tjaalton, ok thanks
<Sarvatt> yeah wacom seems important, a lot of serial tablet fixes in it
<tjaalton> Sarvatt: probably wiser to change the wacom udev rule not claim all tablets
<Sarvatt> I would add xserver-xorg-video-ati to the list as well since it fixes the 100% cpu usage if any kind of flash is happening also on r600+
<tjaalton> but like the old fdi file did, match the vendor id's (like for the serial devices now)
<tjaalton> yeah ati 6.13 too
<Sarvatt> just the one vendor id match I pasted should be enough I would think, the other brands are serial ones matched earlier?
<tjaalton> but that was for synaptics?
<sebner> bryceh: I guess there is no calender feature (visualisation of the tasks) planned?!
<sebner> bryceh: + for gtg
<Sarvatt> ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ATTRS{idVendor}=="056a", ENV{x11_driver}="wacom
<tjaalton> well you mentioned synaptics.rules, so got confused there :)
<Sarvatt> oh sheesh sorry!
<tjaalton> in that case yes, you're right
<Sarvatt> was looking at synaptics kernel source and had it on the brain at the time
<jcristau> tjaalton: and xinput 1.5.1! it's critical! (ok, not really, just manpage updates) :)
<tjaalton> jcristau: good catch!
<tjaalton> :)
<tjaalton> bryceh: pinged whot about the wacom releas
<tjaalton> e
<tjaalton> so I'll choose that from the list
<tjaalton> Sarvatt: file a bug about that so I won't forget
<bryceh> tjaalton, ok
<bryceh> got -ati too
<tjaalton> and assign it to me
<Sarvatt> this ideacom touchscreen device I'm looking at registers as generic usbhid mouse/keyboard devices not a usbtouchscreen one, no wonder its bugging me out
 * bryceh waits for wiki to finish saving *whistle* *whistle*
<tjaalton> oh yeah there's that touchscreen task too, hope it's not multitouch :)
<bryceh> oh sorry, yes multitouch
<tjaalton> whot posted an rfc about it today
<bryceh> will fix once wiki is done saving
<bryceh> tjaalton, ah cool I'll check it out
<Sarvatt> http://launchpadlibrarian.net/40842504/XorgLog.txt
<Sarvatt> xorg log booting with a touchscreen thats loading wacom
 * sebner feels slighty ingored by bryceh :p
<tjaalton> bryceh: it's far from being ready though, so maybe a bit volatile for lucid :)
<Sarvatt> oh ok the device has ID_INPUT_TABLET=1 in the udev log
<bryceh> sebner, sorry a bit busy at the moment
<bryceh> sebner, did you mean to ask on #gtg?
<bryceh> sebner, not sure what you're referring to, tbh
<sebner> bryceh: nah, I know that you are somehow heavily involved and did see you active here so I thought about shooting a quick question. Something like lightning,.. 
<bryceh> tjaalton, at a minimum we want to get it in a PPA.  But there is strong motivation to get it into lucid even if it introduces risk for us
<bryceh> (in fact, this is one reason I'm getting the X stabilization work tasked out, so we can bring in some additional people to work on X so we can make more resources available for MT work)
<tjaalton> bryceh: oh well.. :)
<bryceh> tjaalton, yeah the concerns about X stabilization risks is known to pitti and rickspencer3 and hopefully this msg will flag them that you have some concerns here too
<rickspencer3> what huh?
<rickspencer3> bryceh, should you invite tjaalton to your pow-wow tomorrow?
 * sebner waves at rickspencer3 :)
<rickspencer3> ironically, I am talking to RAOF about this atm
<rickspencer3> hi sebner
<bryceh> rickspencer3, yep, sounds like Sarvatt would be good to invite too
<tjaalton> pow-wow?-) sounds like some commercial
<tjaalton> oh, indians
<bryceh> tjaalton, US colloquialism for "big meeting"
<tjaalton> bryceh: what time was that?
<bryceh> haven't decided... tough finding a time where me, tseliot, and raof all are awake at the same time
<bryceh> rickspencer3, suggestions on a time?
<rickspencer3> bryceh, hmmm
<rickspencer3> with dst I'm all confused now
<tjaalton> this is about more than just MT?
<RAOF> 7AM my time (2000UTC) seemed to work for last week's Do meeting.
<rickspencer3> I think 1pm tomorrow will be 9am in Sydney and 10pm in England
<rickspencer3> bryceh, maybe you can convince RAOF to do 8am and Jan to do 9pm?
<bryceh> tjaalton, yeah the meeting is for general X work, who wants to take which tasks, make sure we have everything covered
<bryceh> rickspencer3, ok works for me
<bryceh> mm, ok 1pm seems to be 2000UTC, 
<bryceh> am I calculating right?
<RAOF> I'm happy to do 7am or 8am.
<Sarvatt> any time is good for me as long as I know beforehand, my hours are pretty flexible and I don't imagine it'd take too long so I could squeeze it in between jobs
<tjaalton> either of those is fine by me, 2200UTC is getting a bit late
<RAOF> Does http://timeanddate.com/worldclock/meetingtime.html?day=16&month=3&year=2010&p1=240&p2=136&p3=137&p4=179 cover everyone?
<tjaalton> should be in bed already :)
<bryceh> ok 2000UTC it is.  google calendar meeting invite thingee coming right up
<bryceh> rickspencer3, got an email addy for Jan?
<rickspencer3> bryceh, PM'd
<bryceh> ta
<tjaalton> bryceh: btw, push your xserver changes to git ;)
<tjaalton> unless they are there already, haven't checked recently
<bryceh> invite sent
<bryceh> tjaalton, pushed
<bryceh> I wish I understood why I continually fail to git push
<tjaalton> debuild -S -sa -i".git"; dput ../foo; git push origin ubunt, simple as that ;)
<tjaalton> +u somewher
<tjaalton> e
<tjaalton> damnit
<bryceh> lol
<tjaalton> new shiny lenovo keyboard still making me mistype
<KiBi> tjaalton: -i alone works fine in most cases
<tjaalton> KiBi: hasn't for me, and never bothered to find out why :)
<Sarvatt> hmm http://www.dealextreme.com/details.dx/sku.15611
<KiBi> tjaalton: I think native packages need some -I in addition or something.
<KiBi> Always did for me; but nevermind :)
<Sarvatt> I put DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.git" in ~/.devscripts (someone here told me that trick)
<tjaalton> KiBi: yes, when packaging xorg. I need to check my settings some time
<tjaalton> Sarvatt: they should have a 24" version too
<KiBi> /usr/share/perl5/Dpkg/Source/Package.pm:(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg(?:tags)?|_darcs|\.git|
<KiBi> It knows about much more than you need to type ;)
<tjaalton> yeah I know that but it still never worked. maybe some setting overrode it or something
<tjaalton> I'll try tomorrow :)
<Sarvatt> should add .bzr to that :)
<tjaalton> it is, just not on that same line :)
<Sarvatt> hmm ok so superm1's specific touchscreen is resistive and reporting as a tablet instead of a touchscreen, that makes sense
<bjsnider> -i".git" ignores all subfolders with that name or just in the top level?
<Sarvatt> so the issue looks like, udev's idinput checks for BTN_TOOL_PEN or BTN_STYLUS and assigns it ID_INPUT_TABLET=1 if so, and doesn't check further down the list where it looks for BTN_TOUCH to assign ID_INPUT_TOUCHSCREEN=1
<Sarvatt> 65-xorg-evdev.rules doesn't assign evdev to ID_INPUT_TABLET at all
#ubuntu-x 2010-03-16
<Sarvatt> the only thing matching ID_INPUT_TABLET is 69-xserver-xorg-input-wacom.rules
<Sarvatt> http://sarvatt.com/downloads/patches/xserver-xorg-input-evdev_2.3.2-3ubuntu2.debdiff
<Sarvatt> added a match for ID_INPUT_TABLET to the udev rules to have it load evdev by default, seems we missed that
<bryceh> Sarvatt, uploaded
<bryceh> hmm, I wonder if we've screwed up the -evdev package though.  I don't see a .orig.tgz
<bryceh> tjaalton, could you look to see if the -evdev merge was done correctly?
<bryceh> http://packages.ubuntu.com/lucid/xserver-xorg-input-evdev - not seeing a .orig here either
<Sarvatt> hmm yeah what happened there
<Sarvatt>  8753eea10df08b960237f38bd2251846 377170 xserver-xorg-input-evdev_2.3.2.orig.tar.gz
<Sarvatt>  1c9aa314a9dc8dd2a93389d27e6feff7 20437 xserver-xorg-input-evdev_2.3.2-3ubuntu1.diff.gz
<Sarvatt> in the dsc for the 2.3.2-3ubuntu1 i sent ya a debdiff for
<Sarvatt> oh dang ya already pushed it to git, was about to do that :D
<bryceh> heh, yeah one of the rare instances I actually remembered to push ;-)
<bryceh> Sarvatt, btw looks like we're in freeze; the upload is blocked for archive admin review
 * bryceh bumps up the upper limit on http://www2.bryceharrington.org:8080/X/Graphs/totals.svg  :-(
<Sarvatt> ahh yeah sorry, funny because the last evdev you sponsored for me was during a3 freeze also :)
<bryceh> heh
<bryceh> well, whatever went wrong with the package, we can probably fix next time we do a merge
<bryceh> I've a feeling that at the least we're going to be pulling a git snapshot of -evdev before we're through
<bryceh> heh, bumping up the bounds makes the graph look less scary now
<Sarvatt> YAY!
<Sarvatt>  - Fixed a bug that caused the X server to crash when rendering occurred while the X server was not on the active VT.
<Sarvatt> thats my exact resume hang problem and BUGabundo's VT switching problem
<Sarvatt> in nvidia 195.36.15
<Sarvatt> http://paste.ubuntu.com/395913/
<Sarvatt> we can close out nvidia-graphics-drivers bugs with backtraces like that once its updated
<bryceh> awesome
<bryceh> Sarvatt, that's a pending change in the nvidia driver?
<bryceh> Sarvatt, do you have a bug # for this?
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/534755 for one, was starting to go through the list to find more now and adding that to the title
<ubottu> Launchpad bug 534755 in nvidia-graphics-drivers "(Needs 195.36.15) gdm/session killed when jumping to TTY" [Undecided,New]
<Sarvatt> yeah its a just released blob update - http://www.nvnews.net/vbulletin/showthread.php?t=148947
<bryceh> oh hey, meant to ask if you had done that script to search Xorg.0.log files?  It'd be handy for this
<bryceh> Sarvatt, ^
<Sarvatt> afraid not :(
<bjsnider> there is no 195.36.15
<Sarvatt> new one https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/534754
<ubottu> Launchpad bug 534754 in nvidia-graphics-drivers "(Needs 195.36.15) X crashes during suspend/resume" [Undecided,New]
<Sarvatt> i just linked the nvnews post and the blobs are on the ftp bjsnider 
<bjsnider> does it build without a patch on the .33 kernel?
<Sarvatt> no idea but we have a .32 anyway :D
<bjsnider> some crazy people run the .33 kernel
<Sarvatt> finding lots more with this same backtrace, gotta dig through a ton of logs to find it though.. its in like gdmlog3.txt for some people
<bjsnider> they never put "improved compatibility with recent kernels" in their changelogs anymore
<bryceh> Sarvatt, are you marking them as dupes as you find them?
<superm1> Sarvatt, they won't be updated unless something ships with 10.04 that needs them
<superm1> Sarvatt, i was really hoping to make sure things worked OOTB with the open driver too like they did in karmic
<superm1> it was nice that people were able to boot a karmic usb stick and have a working touchscreen
<bjsnider> superm1, if dkms fails and leaves an exit code, is there a way to investigate for further information?
<superm1> bjsnider, fails during what?  if it was during a build, it should generate an apport report
<bjsnider> during a build. it said exit code 6
<bjsnider> but i couldn't find a useful log
<superm1> make.log should have hopefully been useful
<bjsnider> where's that stored?
<superm1> it should have come in it's own key in the apport report
<superm1> or /var/lib/dkms/module/version/build/ etc
<bjsnider> i just wish the failure message was a bit more specific. in this case, it was trying to apply a patch that wasn't appropriate. if it has just mentioned that it would have saved a bit of time
<Sarvatt> superm1: yeah I completely understand, it's hard to mess with those things when you dont have any devices that work the same way though. bryce just sponsored an evdev upload that lets evdev work for tablet devices (what yours is showing up as, not a touchscreen), it would help alot if you could attach an Xorg.0.log to that bug after installing that and moving 69-xserver-xorg-input-wacom.rules out of the way 
<Sarvatt> err, archive is frozen actually so it'd be a few days
<superm1> doh
<superm1> okay :)
<Sarvatt> ENV{ID_INPUT_TABLET}=="?*", ENV{x11_driver}="evdev"
<Sarvatt> adding that line in /lib/udev/rules.d/65-xorg-evdev.rules
<Sarvatt> (remove evtouch too)
<Sarvatt> or just move 69-touchscreen.rules out of the way
<Sarvatt> wacom udev rules need to be adjusted a bit to not claim all tablet devices and that fix isnt in yet, thats why i was saying make sure 69-xserver-xorg-input-wacom.rules isnt there
 * Sarvatt needs to join ubuntu-bugcontrol
<RAOF> Perhaps there should be an X package set?
<Sarvatt> hmm, looks like the glxinfo callout in the apport hooks is creating new bug reports about glxinfo crashing :D
<RAOF> Yay!
<Sarvatt> when run outside of X its trying to glxinfo to attach the info?
<RAOF> Oh, that'll be people with half-installed nvidia drivers, I'll wager.
<Sarvatt> yeah exactly what i'm looking at, been working on nvidia-graphics-drivers bugs the past few hours
<Sarvatt> nvidia xorg.conf, no nvidia kernel module and it fails to start X yet its trying to attach glxinfo output
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/532425
<ubottu> Launchpad bug 532425 in nvidia-graphics-drivers "glxinfo crashed with SIGSEGV in __libc_start_main()" [Undecided,New]
<RAOF> Heh.
<RAOF> Yeah, there it is: glXQueryExtensionsString.  glxinfo is quite happy to run outside of X; it'll just bail saying it can't find a display.
<Sarvatt> apport collected glxinfo.txt contents - Error: command ['glxinfo'] failed with exit code -11 :D
<Sarvatt> gnome-screensaver-gl-helper sure does hate the blob
<libv> since you guys are into packaging more than into raw development; check the mesa-dri-* trees out in http://cgit.freedesktop.org/~libv/ 
<tjaalton> Sarvatt, bryceh: yeah looks like the new evdev upload made it a native package :)
<tjaalton> so probably get that dropped from the queue, or just reupload then non-native version
<tjaalton> *the
<tjaalton> bryceh: oh, so the old -evdev was busted, but if the new upload went through fine it should correct itself
<tjaalton> though I can't get to the lp page
<tjaalton> oopses
<bryceh> Sarvatt, I had put in a change a month or so ago to check for DISPLAY before running glxinfo
<bryceh> Sarvatt, so if the bug report(s) in question pre-date that, dont' worry about it
<bryceh> if they're more recent, then that would be interestingly weird
<bryceh> hey, good news everybody, I have a new graph!
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg
<tjaalton> less disappointing one than totals?
<bryceh> indeed!
<bryceh> yeah this limits to just X bugs tagged 'lucid'
<tjaalton> oh that's almost readable :)
<bryceh> a much more reasonable 300 bugs
<bryceh> and really, *this* is the graph we should be looking at.  It's the ones we know are relevant right now
<tjaalton> yep
<apw> we are finding that i915 powersave is an issue for some cards when turned on with drm 2.6.33 ... i hear you guys may know about it, and may be able to tell me which ones are known good and which bad
<apw> Sarvatt, bryceh, RAOF ^^
<johanbr> hmm... with the latest nouveau bits from the ppa, the boot hangs at the plymouth splash screen, just before switching to gdm
<johanbr> booting without splash works
<rye> johanbr, hm, from ppa? In my case I get that even in stock lucid
<johanbr> rye, oh... might be something in the main archive that's botched, then
<tjaalton> it's called plymouth
<tjaalton> file a bug against it
<tjaalton> but there should be no need ot use any ppa's anymore aiui
<tjaalton> s/ot/to/
<Sarvatt> ok ok I'm here for a good chunk of time today until after the meeting, knocked out my afternoon jobs early.
<Sarvatt> apw: do you want PCI IDs or are generations ok? 915 and 945 variants are affected, I would add 8xx series as well to be on the safe side but I have not seen direct reports that they need it yet
<Sarvatt> thats regarding powersave=0
<apw> Sarvatt, ok thanks so 945 and below are all bust yes?
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=26266 is the bug I was following about it, I still have the problem on my machine
<ubottu> Freedesktop bug 26266 in Driver/intel "[945] Screen lockup some time after wakeup from standby (to ram)" [Critical,Assigned]
<rye> tjaalton, the same plymouth worked on my intel-based netbook... but failed with -radeon and -nouveau
<Sarvatt> apw: the method you are using to determine module options, is it overrideable?
<Sarvatt> yeah <= 945 for sure right now
<apw> Sarvatt, i only have modeset at the moment but yes thats changing the default of you haven't set it on the command line, so we can override it to test
<Sarvatt> like if I have a blacklisted chipset for the powersave option, can i still load it with powersave=1 to force it on?
<apw> i will be planning to do that if at all possible
<Sarvatt> ah nice, was just worried about that
<Sarvatt> to be honest the powersave module option is an incredibly small amount of power savings on my 945 netbook anyway, I can't tell a difference in powertop because the low is ~6.9 watts either way
<apw> Sarvatt, is g45 > or < i945
<Sarvatt> >
<apw> Sarvatt, perhaps to put it a better way, is the list in pciidlist in i915 in order
<Sarvatt> hmm doesn't look like it, one sec i'll try to put together a list
<apw> Sarvatt, can i also assume that UMS is handling any powersaving (or more likely not doing it)
<Sarvatt> apw: honestly I'm not 100% on that, but I believe that is a correct assumption
<apw> lets hope so :)
<Sarvatt> asking over in the intel channel
<Sarvatt> apw: drivers/gpu/drm/i915/i915_drv.c has a sorted pci id list
<apw> Sarvatt, ahh that was the one i was quoting :)
<Sarvatt> oh sorry about that! was looking at the modinfo list which was out of order
<Sarvatt> 27ae would be the last yeah
<Sarvatt> hmm
<Sarvatt> the problem seems to be in framebuffer compression for sure on my machine, the only relevant ones on that list with .has_fbc=1 are
<Sarvatt> INTEL_VGA_DEVICE(0x2592, &intel_i915gm_info),
<Sarvatt> 	INTEL_VGA_DEVICE(0x27a2, &intel_i945gm_info),
<Sarvatt> 	INTEL_VGA_DEVICE(0x27ae, &intel_i945gm_info),
<Sarvatt> ah apw I knew there was a launchpad bug - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/492392
<ubottu> Launchpad bug 492392 in linux "[lucid, intel] After suspend, flickering screen and then blank screen." [Medium,Fix released]
<Sarvatt> weird, would anyone mind moving this to mesa? I can't. https://bugs.edge.launchpad.net/xorg-server/+bug/539373
<ubottu> Launchpad bug 539373 in xorg-server "[Mesa] Selection in blender does not work with r600" [Undecided,New]
<Sarvatt> nevermind, worked it out
<Sarvatt> meeting in 20 minutes right? :)
<bryceh> yep
<pitti> o/
<bryceh> heya
<bryceh> pitti, rick says he's going to be a bit late
<Sarvatt> heyo!
<bryceh> hi Sarvatt
<bryceh> RAOF, tseliot?
<RAOF> Good (somewhat early) morning :)
<Sarvatt> morning RAOF :)
 * RAOF is just reading #ubuntu-kernel backscroll
<jpetersen> hey
<bryceh> RAOF, sorry to get you out of bed early, and sorry to tseliot for staying up late
<bryceh> hi jpetersen!  well met
<bryceh> let's go ahead and get started
<tjaalton> howdy
<bryceh> heya tjaalton
<bryceh> the main purpose of this meeting is to get more manpower organized around X stabilization
<bryceh> the motivator for this is that we've gotten tasked to make some progress with multitouch, and that's going to tie up some manpower which otherwise would be going to stabilization work
<bryceh> (namely me)
<bryceh> So we need your help to ensure we maintain good level of manpower on X stabilization in general
<tseliot> hey
<bryceh> I know this impacts projects you guys have been working on, so double thank-you for your flexibility, it's really appreciated
<bryceh> in this meeting, I want to focus mainly on the non-multitouch aspects, but if anyone is particularly interested in working on that let me know; we can move tasks around pretty fluidly where there's interest
<bryceh> before I go further... any comments or questions?
<pitti> I have one wrt. multitouch, but let's do that at the end
<bryceh> ok
<Sarvatt> I wrote down quite a lot of bug related questions/issues I came up with while spending the whole afternoon focusing on bug work, not sure when to bring them up :)
<pitti> and get to the main purpose first
<bryceh> Sarvatt, excellent.  Let's cover some of the high level stuff and then get into specific problems/bugs/needs
 * Sarvatt nods.
<bryceh> (for reference, here's the multitouch blueprint listing the work items we've identified so far: https://wiki.ubuntu.com/X/Blueprints/Multitouch)
<bryceh> I sketched out a todo list for X stabilization, most of you have seen this:
<bryceh> https://wiki.ubuntu.com/X/Projects
<bryceh> hopefully that doesn't look too intimidating...  I tried to slice and dice the work down into chunks that would be more manageable
<bryceh> one strategy I try to use for tackling this stuff is to try and get bugs filed upstream, and get their help solving them
<pitti> (those canned bug searches are awesome!)
<bryceh> this is effective since they're a lot smarter than me, and can come up with better solutions than I can most of the time
<Sarvatt> I've asked my main question about it before but just want to be sure, n-trig seems to be the targetted device for multitouch support at the moment? That is the only device I'm aware of that looks even somewhat feasable to bring multitouch support for into lucid and there are quite alot of issues with it that I'm sketchy about.
<bryceh> so then my job is to just make sure the bug report isn't completely insane, and that it's been reasonably well tested and characterized, and then just cut and paste into bugzilla
<bryceh> Sarvatt, yes n-trig is the main focus
<Sarvatt> there are 3 versions of the n-trig touchscreens that I know of, one supports single touch and stylus, one supports multitouch and the newest one can support both
<Sarvatt> but each requires different firmware to be loaded
<tseliot> right
<Sarvatt> and the firmware appears to come from the windows drivers
<bryceh> wb rickspencer3
<bryceh> Sarvatt, good questions, let's chat more about MT later
<Sarvatt> ahh sorry about that, thought the topic was MT before I went rambling :)
<bryceh> no prob
<bryceh> so you can see in the list I roughly divided the tasks into three buckets.  
<bryceh> the first group I think we must get done, the second should get done, and the third would be nice to have done
<rickspencer3> this meeting shouldn't be about MT, it should be about everything *but* MT
<rickspencer3> ;)
<bryceh> In general I think X is in fair shape, but we have a HUGE backlog of bug reports
<bryceh> we spent a lot of time in the cycle doing blueprint work and bringing in a lot of new features
<bryceh> the fear is that many of these new features have new bugs as well
<rickspencer3> bryceh, is this a fair time to introduce jpetersen
<bryceh> please do!
<rickspencer3> (excuse the interruption)
<pitti> Sarvatt: while you are editing the wiki, can you please fix the "radeon bugs" link to be -ati, not -radeon?
<rickspencer3> so, jpetersen has been working on Indicatory stuff
<pitti> Sarvatt: (just tried it, but you have the lock)
<rickspencer3> but I've asked him to join us here so that he could spend the rest of his 2 (maybe more) weeks helping lighten the load for xorg stuff
<rickspencer3> maybe he'll work directly on xorg stuff, or maybe he'll take over other work so other people can do that
<rickspencer3> jpetersen comes highly recommend by jono and jcastro
<Sarvatt> sure thing, was adding my name to a few tasks, done
<rickspencer3> so, welcome!
<bryceh> jpetersen, welcome aboard!
<jpetersen> thanks :)
<tseliot> welcome :-)
<Sarvatt> nice to meet you jpetersen :)
<RAOF> Welcome
<bryceh> jpetersen, can you give us some background about what level of debugging work you've done?
<bryceh> jpetersen, (just trying to get a feel for types of tasks you would be interested in or most effective at)
<jpetersen> bryceh, ok before i worked for Ubuntu I worked on the application framework for Maemo 5 
<jpetersen> bryceh, we worked on a clutter based window manager and we had to work together with the X team there for bug fixes
<bryceh> ok great
<bryceh> RAOF, tseliot, I know you've been busy on some non-X work, how much time do you think you'll have going forward, and are there particular things you'd like to focus on?
<bryceh> also, any input regarding how you think we should attack the stabilization work for X overall?
<bryceh> Sarvatt and tjaalton, interested in your input as well
<bryceh> also, what do you guys think of this approach of placing the main focus on pushing bug reports upstream?  I know it's a lot of effort but I've found it tends to work reliably
<pitti> RAOF: would you be interesting in shepherding the nouveau bugs, since you've been working on them already and they certainly need particular attention?
<RAOF> I'm obviously happy to pick up the -nouveau tasks.
<tseliot> bryceh: I handed the 16 colours support for plymouth to Keybuk but I took some new bugs which are both gnome and synaptics related (g-s-d), in addition to my work on kdm. Then of course I have some more work on mesa and nvidia and some other stuff. Let me have a look at your list
<pitti> bryceh: I won't have too much time left, but I could give a hand with -evdev bugs, since I'm reasonably familiar with the input layer and how X handles them
<tjaalton> bryceh: the merges are easy and not a lot of work. working on getting a (more) stable wacom snapshot might take more time
<bryceh> pitti, great thanks
<tseliot> bryceh: I guess "going through all of the -nvidia bug reports" is something I'll have to do sooner or later and there are a few things on my radar already
<RAOF> didirocks is doing well with UNE, and f-spot's pretty much done.  I will be able to dedicate lots of time.
<tjaalton> tseliot: good luck :)
<tseliot> heh, thanks, I'll need it
<pitti> bryceh: hah, bug 537801 is exactly my taste ;)
<ubottu> Launchpad bug 537801 in xserver-xorg-input-evdev "Touchscreen doesn't work after karmic->lucid upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/537801
<bryceh> tseliot, ok.  I have wondered if scripts could help... like detect if they manually installed nvidia and close the bug with a suitable apology
<bjsnider> tseliot, are you planning on packaging the new nvidia blob that was released last night?
<bryceh> RAOF, I was also thinking you might be interested in taking the xserver bugs, since a lot of random stuff ends up there and it would give you a good breadth of X work, that might help get you up to speed for next cycle
<tseliot> bryceh: can you send me a bunch of scripts that I could use as an example, please?
<bryceh> RAOF, there tend to be a lot of gdb backtraces filed into xorg-server, and those tend to be pretty straightforward to debug
<tseliot> bjsnider: I didn't know about that but I was waiting for it
<bryceh> tseliot, sure can do
<tseliot> thanks
<RAOF> bryceh: That sounds like a good idea.  I was going to suggest that I take the -intel tasks, too, unless someone else wants them.
<bryceh> RAOF, ok great, yeah that's a big one, but Sarvat and Geir help a lot there too
<bryceh> oh btw
<bryceh> to get a visualization on how the bug situation looks I did a graph:
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg
<Guest26447> btw, I'm Geir Ove (just joined after coming home)... I'm an IRC-analphabet, hence the nick...
<bryceh> it looks like between nvidia and intel, that's like half the bugs almost
<bryceh> Guest26447, heya!
<tseliot> yes, that's a lot
<bryceh> I think I can take -ati
<pitti> bryceh: is that because intel is really that bad still, or just because we have the freeze detection on intel, and not on other drivers?
<bryceh> pitti, a combination of both
<Guest26447> Freeze detection should amount to 50-60 bugs currently...
<RAOF> Which would be about half those intel bugs.
<Sarvatt> I don't even know where to start, but I put my list of concerns here - http://sarvatt.com/downloads/issues.txt
<bryceh> Sarvatt, yeah it's a good point that we need ways to force into failsafex or other debugging modes
<bryceh> moving to KMS seems to have obsoleted a lot of our traditional debugging techniques
<bryceh> and doesn't appear to give us replacement techniques... although maybe we just need to poke around more
<bryceh> Sarvatt, regarding trigger happy freeze detection, you may be right.  I was hoping to get upstream to clue us in better but no word so far.
<RAOF> For modelines we should be able to add them with xrandr, although that's wildly inconvenient compared with xorg.conf.
<bryceh> I think if we start pushing the Intel bugs upstream they'll push back if the bugs are invalid, and we can adjust tools from there
<bryceh> RAOF, yeah
<Guest26447> About -intel freeze trigger happiness: I looked a bit on the code during a train ride on the weekend, and there seems to be two ways to trigger the error handler with the udev event: one if the GPU is hung and otherwise if any other error is detected.
<Guest26447> The current title suggests only the GPU hung case.
<bryceh> Guest26447, yeah I have it on my todo list to fix up the apport hook based on your latest suggestions, just haven't gotten to it yet
<tseliot> Sarvatt: if you give me a bug number for the gnome-screensaver + nvidia GL bugs I can ask Nvidia about it
<RAOF> Also on the subject of failsafes, we should get vesa to fail to load when KMS is active; for me, it badly-programs the hardware and I get a âbloomâ on my lvds.
<Guest26447> bryceh, hold it off a little bit, since I have found out some more since last time... Sorry this is so incremental...
<bryceh> ok
<bryceh> Guest26447, I like incremental actually ;-)
<bryceh> RAOF, yeah I've seen that too
<Guest26447> bryceh, I'll put together another incremental email soon....
<RAOF> I've got a bug report on LP & bugzilla about that.  If push comes to shove, that *should* be an easy patch to write myself.
<bryceh> ok, if anyone needs sponsoring, tseliot, tjaalton and myself are all core-dev so can push patches
<Sarvatt> I have xforcevesa working by adding it to initramfs-tools, and adding a check for xforcevesa to the gdm init scrit and doing an exit 1 if it's there which starts failsafe. Can anyone think of a better way to do it?
<tseliot> bryceh: absolutely
<bryceh> RAOF, tseliot, do you think it would be better to have jpetersen help you with some of your other tasks to free you for more X work, or shall we turn jpetersen loose on doing X bug upstreaming?
<Sarvatt> I can't seem to get the blacklist to stick, it eventually loads things later when plymouth kicks in
<bryceh> jpetersen, or would you be interested in tackling X debugging directly?  (e.g. are you familiar with gdb and/or X internals at all?)
<jpetersen> i am familiar with gdb and some X internals
<RAOF> jpetersen: If you've worked on a clutter-based window manager before, you'd perhaps like to tackle some of the UNE tasks?  That's all clutter & clutk.
<superm1> Sarvatt, it's currently living in casper, so if you find a better place, make sure to remove it from casper too
<tseliot> bryceh: I would like to take care of those bugs personally, so maybe he can focus on upstreaming or on whatever he prefers
<jpetersen> RAOF, I could do that
<RAOF> jpetersen: https://wiki.ubuntu.com/UNE/lucid-bugs is a nice list of UNE tasks, if you want a browse.
<Sarvatt> superm1: hmm just looked and that casper hook will blow up horribly if KMS is in use
<superm1> Sarvatt, well it only emulates what the old xforcevesa used to do, and i've only tested it on nvidia hardware personally
<bryceh> jpetersen, what type(s) of video cards do you have on hand?
<superm1> Sarvatt, so by all means, move the logic elsewhere that is more KMS aware :)
<jpetersen> bryceh, just some different intel cards
<bryceh> Sarvatt, getting back to your list...  ATI> on my todo list to merge 192, I'll look at those bug reports.  synaptics> TBH everyone gripes about the default settings no matter how they're set, but yeah would be nice to hammer some of that out
<bryceh> jpetersen, ok, if you have time outside the UNE work, perhaps you can help RAOF with triaging the -intel bugs
<jpetersen> bryceh, yes I think I can do that
<bryceh> jpetersen, we've got a tutorial on how to triage X bugs at https://wiki.ubuntu.com/X/Triaging
<RAOF> jpetersen: Great, thanks!
<bryceh> I think that explains most of what you need to know.  There's also a lot more info under wiki.ubuntu.com/X
<bryceh> ok, we're at the hour, but I think we have a good plan in place now
<jpetersen> thanks I will look at that pages
<bryceh> I'll write up the results of this meeting, thanks everyone for volunteering, I think we mostly have everything covered now
<bryceh> rickspencer3, any final words?
<bryceh> pitti, or thoughts from you?
<rickspencer3> make it so?
<pitti> bryceh: ohe question, how far does the MT support go? just making drivers available? because I don't think we have any application right now which would actually make use of those?
<pitti> bryceh: (not meeting related, it's the Q that I announced at the beginning)
<pitti> bryceh: thanks a lot for organizing this
<bryceh> pitti, just drivers.  Purely low level hardware-specific enablement work
<bryceh> pitti, anything beyond that is gravy (and probably out of scope)
<tseliot> I think OEM will take care of the rest
<pitti> bryceh: so that it's "there" for developers/OEMs to play around with, but we don't have a commitment to making GNOME multitouch-capable or so? :-)
<bryceh> pitti, exactly
<pitti> bryceh: *phew* :)
<bryceh> well, maybe lucid+1 for that
<tseliot> well, X developers would have to come to an agreement on multitouch first ;)
<bryceh> alright thanks everyone!  expect a summary email within a few hours, and I'm open to questions whenever
<tjaalton> don't think there are toolkit support planned yet
<pitti> like, how to represent it in an Xevent?
<tjaalton> s/are/is/
<tseliot> there are some patches for clutter and gtk+
<tjaalton> well, that still doesn't sound like a plan :)
<tseliot> tjaalton: because it's not ;)
<bryceh> Sarvatt, RAOF, regarding the glxinfo crashes in apport, yeah I think just checking for DISPLAY is insufficient.  We need something else to test to see if GLX is available
<bryceh> or alternatively, patch glxinfo to check itself, and to exit with an error code instead of crashing in such a case
<RAOF> Can we simply suppress error reports from glxinfo crashing in the apport hook?
<RAOF> Because catching all possible crashes sounds hard :)
<bryceh> RAOF, yeah if we can detect it
<bryceh> or even just drop glxinfo entirely
<bryceh> I think the number of cases where we actually need the info is quite tiny
<bryceh> like, certain types of mesa bugs
<bryceh> although this feels a bit like sweeping the issue under the carpet ;-)
<RAOF> The information the glxinfo crashes when you try to run it seems like an important data point to have on the bug.
<bryceh> true
<Sarvatt> pitti: on the n-trig multitouch side it just goes through wacom and supports hardcoded multi finger gestures like 2 finger tapping for right click and 2 finger scrolling with no way to have multiple pointers (per finger) or let applications detect do things with the multi finger stuff.. its basically just like a touchpad, nothing exciting :)
<pitti> Sarvatt: I just wasn't aware that events (linux input and X) can have a list of coordinates
<Sarvatt> wacom handles it internally, checks if theres multiple fingers in use and enters gesture mode if so, stops the cursor and waits for the second finger to be lifted to process it as an event based off of filters. multitouch is just a single cursor and a new button event to X with that
<Sarvatt> synaptics does the same thing for 2 finger scrolling and stuff
<bryceh> pitti, I think some of this may be new with the mpx stuff
<bryceh> RAOF, btw keybuk was asking about whether the lbm_nouveau name support is still needed
<bryceh> or can we drop the patches that added that
<RAOF> We can drop them; we'll just need to pull patched versions of all those packages into xorg-edgers & the testing PPA.
<RAOF> It would be a bit easier for the PPAs if we didn't drop them, but they're not needed for Lucid.
<bryceh> RAOF, ok can you follow up with keybuk about that when you get a chance.  Or toss debdiffs at me again and I can sponsor
<bryceh> it doesn't matter to me whether we keep the patches or not but he might have a stronger preference
<RAOF> I will.
<Sarvatt> RAOFL: I already did a task you put your name on on the wiki (didn't see it until after) hope ya dont mind :)
<RAOF> Sarvatt: You're welcome :)
<Sarvatt> hmm I like the name RAOFL :)
<Sarvatt> so..many..plymouth...bugs...
<Sarvatt> filed against driver packages
<RAOF> Pylmouth has not been a smooth ride.
<Sarvatt> bryceh: how often is http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg updated?
<bryceh> daily I think, let me check
<bryceh> hourly
<bryceh> 40 min after the hour
<bryceh> well, there's actually two scripts
<Sarvatt> ugh, depressing to spend 7 hours straight clearing things out and its going up :)
<bryceh> tell me about it
<Sarvatt> was doing alot of nvidia-graphics-drivers-180 ones this morning though and those arent on there
<bryceh> I think getting a handle on the intel freezes is probably key
<bryceh> Sarvatt, you mean ones that weren't tagged 'lucid'?  yeah those won't be included here
<bjsnider> Sarvatt, were those legitimate bugs or support requests?
<Sarvatt> i'm making sure theres no nvidia-graphics-drivers-180 bugs tagged lucid so yeah :)
<Sarvatt> and likewise for nvidia-graphics-drivers bugs tagged karmic, looked like KDE people used it as a catchall target for blob problems
<Sarvatt> bjsnider: look at the latest nvidia-graphics-drivers bug and you tell me for example https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/539351
<Sarvatt> :D
<ubottu> Ubuntu bug 539351 in nvidia-graphics-drivers "[amd64][nv8600gt] karmic/lucid nvidia proprietary cause system crash when xserver-xorg starts" [Undecided,New]
<bjsnider> that's a support request
<bjsnider> his hardware is no doubt broken
<bjsnider> anyway, he should be complaining to nvidia
<bryceh> Sarvatt, yeah X was being used as a catchall in general a lot more than it should when I started
<bjsnider> ubuntu does a poor job telling people where to go to file bugs on the nvidia driver
<Sarvatt> anything with a title like package nvidia-185-kernel-source 185.18.36-0ubuntu9 failed to install/upgrade is pretty much guaranteed to be a PPA package upgrade issue
<bryceh> bjsnider, open to suggestions
<RAOF> bjsnider: I'm not really aware of a better place.
<bjsnider> bryceh, i knew you'd say that
<bjsnider> i have the info in my ppa description, if anybody reads it
<bryceh> bjsnider, in fact we're pretty clear in Jockey to say "This is a binary-only driver that we can't really support since it's closed source" or some such
<Sarvatt> I dont know what to do with the ones with titles like Xorg crashed with SIGSEGV in _nv001644X()
<bryceh> people appear to ignore that and file lots of bug reports to us anyway
<Sarvatt> (and there's *alot*)
<Sarvatt> thats basically wontfix
<bjsnider> yeah but do you say "go to nvforums.com/... blah blah"
<bryceh> bjsnider, I guess we could, is that a feasible out?
<jcristau> bjsnider: is there any point in saying that?
<bryceh> or is it just the equivalent of saying "go away!"
<bjsnider> there's a specific page that nvidia has put up explaining exactly how to file a bug with them
<bjsnider> jcristau, not sure what you're getting at. you mean nvidia won't care if a bug is filed?
<bjsnider> or users won't care?
<bjsnider> Sarvatt, all of those bugs would be nvidia-specific issues right?
<bryceh> Sarvatt, pretty much any crash that is isolated to -nvidia code like that is going to need to go to nvidia since we don't have the source code.  I think scripting something to auto-close those with a pointer to nvidia (or the forums as bjsnider suggests) would be entirely appropriate
<Sarvatt> yeah like https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/532580 for example
<ubottu> Ubuntu bug 532580 in nvidia-graphics-drivers-180 "Xorg crashed with SIGSEGV in _nv001646X()" [Undecided,Confirmed]
<jcristau> bjsnider: the former
<bjsnider> jcristau, cynical
<bryceh> Sarvatt, we have code to automatically detect nvidia crashes and file them to nvidia-graphics-drivers.  That code could be enhanced to also examine the backtrace and kick out ones that look non-viable
<bjsnider> this is what my ppa description says:  If you have a display bug in the Nvidia driver, please report bugs in the nvforums site here: http://www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14
<jcristau> bjsnider: maybe.  but wrong?
<bjsnider> i think they fix the bugs they have the manpower to fix, especially if they impact revenue customers
<superm1> is the nvidia bug report script ran during an apport capture for an nvidia crash?
<jcristau> bjsnider: right, that makes sense
<bryceh> superm1, no not from the apport crash hook
<superm1> if not, then perhaps add that and then in your auto close you can tell people to use that to file their bug with nvidia since there is nothing ubu developers can do
<bryceh> hmm, or even just launch it directly for them
<superm1> yeah that's what i mean
<superm1> launch it for them to capture everything nv would have wanted in a bug report
<bjsnider> then hope they don't waste time reporting it on launchpad
<Sarvatt> bryceh: what bug status is appropriate is what I'm wondering, I can't set wontfix but I can start tagging bugs in a way you can pick up later if you want
<superm1> well if they do, then your autocloser would do justice in explaining what they can do
<bryceh> Sarvatt, oh yeah you need to join the ubuntu-bugs or whatever team to get rights for setting wontfix
<bryceh> bdmurray, could you hook Sarvatt up with joining the bugs team so he can wontfix stuff as needed?
<Sarvatt> I think allowing the bug, tagging it a special way and running a script over it later would be the way to go so they can have the relevant info collected for them if they do want to report it
<bjsnider> but how would apport know when to run the nvidia crash report and when the bug has to do with the ubuntu packaging scripts?
<superm1> bjsnider, well maybe just run the nvidia crash report tool every time when filing an nv bug?
<Sarvatt> it would be alot more fine grained than that, I wasnt suggesting closing *all* blob bugs just ones obviously the blob's fault like Xorg crashed with SIGSEGV in _nv001646X()
<Sarvatt> or were you guys talking about closing out all blob bugs?
<bryceh> probably we're talking about several overlapping things
<bjsnider> superm1, maybe there's some way to make apport intelligent enough to say "this is probably not a bug ubuntu can fix. please report it to..."
<bdmurray> bryceh: sure if you are vouching for him
<Sarvatt> a good portion of them are actually relevant
<bryceh> bdmurray, I vouch for Sarvatt
<bjsnider> Sarvatt, i asked earlier how many of these nvidia bugs are real bugs and how many are support requests or nvidia bugs
<bryceh> bjsnider, don't think we have that data, but you're right a good chunk are really support requests
<bryceh> but the trick is how to distinguish them
<Sarvatt> support request ones would have to be manually identified for sure
<Sarvatt> oh, there's always the convert to a question option I totally missed somehow...
<bryceh> bdmurray, do you need Sarvatt to poke a button somewhere?
<bjsnider> too bad there's no way to just click a button and have all of the nvidia ones closed and sent on to nvidia
<bryceh> one thing I've pondered is if we could detect if the user had manually installed -nvidia from the web
<bryceh> if so, those could be closed en bulke with some pointer to an nvidia installation guide
<bryceh> bjsnider, we can do arsenal scripts to some degree, so long as there are ways to programmatically determine what bugs to apply the rules to
<bryceh> usually the hard part is actually doing the cut-and-paste into the foreign bug tracker
<bjsnider> well, for example a pattern like _nv001646X() is obviously an nvidia bug
<bryceh> right
<bjsnider> nvidia could possibly be some help here
<bdmurray> bryceh: nope he's all set
<bjsnider> they could provide common patterns
<bryceh> bdmurray, excellent thanks!
<Sarvatt> bdmurray and bryceh:  thank you *very* much for that :)
<bryceh> Sarvatt, you are now beknighted with the wontfix wand
<bryceh> I think this means you can also set priorities on bugs, and see private bugs
<Sarvatt> bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/509117 -- which side of that bug do you want to focus on?
<ubottu> Ubuntu bug 509117 in nvidia-graphics-drivers "when kernel module fails to build Xorg crashes with SIGSEGV in CloseWellKnownConnections ()" [Critical,Triaged]
<Sarvatt> the problem in the description is fixed
<Sarvatt> \they still won't get X up with a nvidia xorg.conf and a kernel module failed to build, but it wont segfault anymore :)
<bdmurray> bryceh, Sarvatt: yes priority and private apport crashes
<bryceh> I'd consider it closed at this point
<bryceh> I think we have bug reports already open against jockey and other things to DTRT in these cases
<bryceh> you could doublecheck the jockey bug reports tho just to make sure we're covered
<bryceh> the idea is that if the kernel module fails to build, tell the user and don't configure the system to try to use nvidia
<Sarvatt> dang, now I wish I could set priority 8 hours ago when I started this bug rampage :)
<superm1> and there is automatically another report filed about it failing to build too from DKMS
<bryceh> right
<bryceh> Sarvatt, so any 'dkms failed to build' that are older than a few months can probably be closed
<Sarvatt> i'm using https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/492392 as the master bug for freeze after suspend hangs with intel incase it helps, if its 915 or 945 and they say it hangs with a black screen a few minutes after resume its pretty much guaranteed to be that
<ubottu> Ubuntu bug 492392 in linux "[lucid, intel] After suspend, flickering screen and then blank screen." [Medium,Confirmed]
<Sarvatt> I meant to bring this up during the meeting, but maybe we should start a wiki page where we can collaborate on symptoms and list the bugs to dupe things to
<Sarvatt> i work my way from the newest to the oldest bugs so i dont dupe much until I find the first report of it, and that usually doesn't happen because there's hundreds to go through :D
#ubuntu-x 2010-03-17
<bryceh> Sarvatt, good idea
<bryceh> Sarvatt, sometimes I've used pages under http://wiki.ubuntu.com/X/Bugs for that sort of work
<bryceh> sometimes it helps to start putting bugs into tables with their symptoms
<bryceh> Sarvatt, also, I have automatically generated tables for -ati and -intel using the tagged symptoms and chip name
<bryceh> if you think that sort of thing could be useful for -nvidia, we can also do one for that
<bryceh> however it'd require symptom tagging all the -nvidia bugs, and getting the chip names identified and such
<bryceh> I made some scripts for doing this when we tagged -intel and -ati which could probably be modified to work on -nvidia
<bryceh> it'd be a bit of work, but I know exactly what needs done.  Let me know if you want to undertake it and I can give specifics.
<Sarvatt> ok starting to fill out https://wiki.ubuntu.com/X/Bugs with symptoms and actions to take
<Sarvatt> yeah its formatted horribly but thats easy to fix after making a significant list :)
<Sarvatt> how do we want to start collecting lists of gpu's that need UMS quirks? a new tag?
<Sarvatt> or just mark it when we see it somewhere
<bryceh> Sarvatt, in the past I just stuck [Needs quirk] in the subject
<bryceh> Sarvatt, afaik most remaining cases where quirks are needed will need done in the kernel, so we'll want a separate bug report for each piece of hw which we can forward to the kernel team to add the quirk
<Sarvatt> btw about Backport Xv fixes and other fixes from -intel 2.10 (and 2.11), I really don't think thats going to be possible realistically from looking at it
<Sarvatt> time to turn the computer off for tonight, thanks for all the help and getting me into bugcontrol :)
<bryceh> Sarvatt, I'd be interested in hearing why not?
<Sarvatt> well,  there was *so much* code refactoring between the initial drmmode overlay support addition just after 2.9.0 which we could easily bring in (and manually define DRM_MODE_OVERLAY_LANDED to enable) and the subsequent fixes that might be needed, the later fixes there wont apply to UMS which is like the main target for overlay support anyway (8xx not having textured video) and it might be dependant on PutImage acceleration which was one of the 
<Sarvatt> major features in 2.10 for decent performance 
<bryceh> mm, well I can still take a look when I get some time
<bryceh> the Xv stuff actually went in pretty early on in the 2.10 tree so I think it has a higher chance of being a clean port
<Sarvatt> I still think intel 2.10 might be a better choice at this point, selectively blacklisting KMS initially for 8xx people will guarantee they have vesa and a workable desktop and I still can't find any reports of the 8xx situation being better with UMS, just reports that nomodeset fixed things for them *because* it was forcing vesa to be used as intel couldn't work with it because of being built with --kms-only
<bryceh> also I suspect it's self contained away from the stuff which changed
<Sarvatt> yeah but there were a huge number of fixes for it throughout the 2.10 cycle (including the removal of UMS overlay so that code didn't get fixed along with the KMS fixes)
<Sarvatt> so much for turning the computer off, got stuck updating xorg-edgers stuff since i'm behind :D
<Sarvatt> woohoo sold off a bunch of old ram I had lying around, *almost* enough to buy that 8.9" eGalax touchscreen overlay for some evtouch testing :D
<Sarvatt> why oh why does apport attach Xorg logs .gz and not in a format gedit can read sometimes? :D
<Sarvatt> seems to be only when filed against xserver-xorg-video-intel and not generic xorg like this https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/540017
<ubottu> Ubuntu bug 540017 in xserver-xorg-video-intel "i915 crashes after resume (not powersave mode problem) (dup-of: 539533)" [Undecided,New]
<ubottu> Ubuntu bug 539533 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__()" [Undecided,Confirmed]
<Sarvatt> xserver 1.7.6 out
<tjaalton> yep
<tjaalton> bryceh: is versions_current still going to be broken in the foreseeable future? I'd file some sync requests but it's harder to check what there are :)
<bryceh> tjaalton, it's going to be broken a little while longer, but it's high on my todo list to fix
<bryceh> Sarvatt, not sure it's apport that does that or launchpad
<bryceh> but I know launchpad enforces a size limit on individual file uploads
<tjaalton> bryceh: ok, I'll check the (short) list manually
<bryceh> I assume the compression is to get around that
<tjaalton> it's annoying that ffox sometimes doesn't open those itself, but uses file-roller
<tjaalton> since it's perfectly capable to open gzipped text
<bryceh> tjaalton, agreed
<bryceh> heya tjaalton and jpetersen
<bryceh> er tseliot and jpetersen :-)
<tseliot> hi bryceh
<jpetersen> hi bryceh 
<tseliot> and hi jpetersen
<jpetersen> hey tseliot 
<tseliot> bryceh: can you send me those scripts of yours when you can, please? (i.e. how to close bug reports)
<bryceh> tseliot, certainly
<bryceh> in fact here I've been drafting the email describing them :-)
<tseliot> I remember that something went wrong last time I tried with my scripts (which I lost)
<bryceh> tseliot, sent
<tseliot> hehe, excellent
<Sarvatt> bryceh: pretty sure its apport - /home/robert/Downloads/XorgLog: application/octet-stream; charset=binary
<Sarvatt> its 21k
<Sarvatt> mime type is screwed up on the file so it doesn't transparently decompress the .gz
<Sarvatt> well it doesn't have the .txt extension they usually have either after extracting it, cant imagine it would compress a 21kb file and leave a 1.8mb gpu dump on the same bug uncompressed on purpose..
<bryceh> mm ok
<bryceh> Sarvatt, might ask pitti for more rationale then
<bryceh> seb128, present for you
<seb128> hey bryceh
<seb128> oh?
<bryceh> seb128, http://www2.bryceharrington.org:8080/X/Reports/desktop-bugs/milestone-bugs.html
 * seb128 clicks
<seb128> oh, I love that list ;-)
 * seb128 hugs bryceh
<bryceh> :-)
<seb128> bryceh, how do you determine what is a desktop component? using the packages the desktop-bugs team is watching?
<bryceh> seb128, that's right
<seb128> ok, so +packagebugs for the team in launchpad?
<seb128> bryceh, thanks a lot!
<bryceh> seb128, exactly
<seb128> that will be handy for looking at lucid tasks
<bryceh> glad to know the reports are useful :-)
<seb128> bryceh, the page is updated daily I guess?
<bryceh> hourly
<seb128> even better
<seb128> you rock ;-)
<bryceh> script takes some time to run, but ~15 minutes
<bryceh> that's for desktop as well as X, mozilla, audio, and openoffice
<seb128> does that require anything special?
<seb128> would it be faster to run from the dc? ie on a people page
<bryceh> seb128, there are also JSON reports if you want to pull this data into bughugger
<seb128> I don't want to load your server if we can use canonical servers for the same job
<seb128> ah, nice
<seb128> though I find the webpage easier to read than bughugger screen
<bryceh> yeah
<seb128> but bughugger let you do query which can be handy too
<bryceh> well, the reports are generated from the same data as bughugger so it's not really any extra work to get both
<seb128> bryceh, while you are there do you know about a way to "watch" xrandr events?
<seb128> like a xrandr --monitor or something
<bryceh> not sure what you mean
<bryceh> there is xtrace but not sure that's what you're after
<seb128> not sure if you read my laptop screen activation issue
<seb128> basically if I suspend with external dvi on and laptop lcd off
<bryceh> oh you mean for watching for things which poll/set stuff via libXrandr?
<seb128> and wake up without the dvi screen
<seb128> I get no screen
<bryceh> have you seen doign a vt switch brings it back?
<seb128> mars 16 20:59:16 <federico>	seb128: server/hw/xfree86/modes/xf86RandR12.c:xf86RandR12EnterVT()
<seb128> mars 16 20:59:32 <federico>	seb128: basically see if something runs RRGetInfo() when unsuspending
<tjaalton> it does
<seb128> is what federico recommended
<seb128> so I'm trying to set if RRGetInfo() get called
<seb128> yes it does
<seb128> set -> see
<bryceh> yeah I've seen that one as well (or something similar)
<bryceh> afaik there is nothing which watches xrandr events, although they often print into Xorg.0.log
<seb128> mars 16 20:51:18 <federico>	seb128: that should already work, BTW - xserver got fixed so that it re-probes the outputs (and sends out RANDR events if appropriate) when it enters from a VT switch, and that happens when you unsuspend...
<seb128> mars 16 20:51:34 <federico>	seb128: I don't know if that would be affected by KMS, though
<bryceh> tail -f Xorg.0.log *might* get what you need
<seb128> I'm trying to figure if that issue is from the xorg side
<seb128> ie if that event doesn't get fired on waking up from suspend
<bryceh> otherwise I think debug print statements would be needed.  Maybe federico has more clue
<seb128> or if g-s-d just doesn't act on it
<seb128> ok, thanks
<bryceh> I'm curious if the fix for xserver is included for 1.7.6 (which tjaalton will be merging in soonish) or is in newer code than that
<tjaalton> I don't think it has anything related last I looked
<seb128> it might already be in 1.7.5
<seb128> federico said he doesn't know how well that plays with kms though
<tjaalton> what is?
<bryceh> yeah
<seb128> tjaalton, the "re-probes the outputs after suspend"
<seb128> he said it's working in non-kms cases
<seb128> but he didn't try with kms
<seb128> and he was not sure if that could create issues
<tjaalton> yeah it's an old commit
<tjaalton> from last May
<jcristau> the entervt code should still be called on resume
<seb128> the xrandr output seems to be correct
<seb128> but I'm still unsure if xorg or g-s-d should be activating screens
<seb128> well xrandr does list the laptop lcd screen as active
<jcristau> sounds like a kernel bug then
<seb128> which is wrong since nothing is on screen
<seb128> so xrandr seems to list correctly how things should be
<seb128> ie what screen should be active
<jcristau> it's not just brightness which is off?
<seb128> but that doesn't match reality
<seb128> no
<seb128> if I dock the laptop again xrandr says the dvi is on
<seb128> but the monitor led stay on orange
<seb128> ie no signal
<seb128> I do basically type xrandr before undocking
<seb128> while undocked
<seb128> and after docking again
<seb128> and I get no screen after undocking or docking again
<seb128> xrandr correctly list what should be active
<seb128> but the screen gets no signal
<Ng> man I wish X would timestamp its log entries
<jcristau> 1.8 does.
<Ng> something keeps making my screen flicker every half an hour or so (I think) and I can't tell if it corrolates with all the EDID stuff in logs
<Ng> jcristau: good good :)
<Ng> ok, doesn't corrolate with the log
<Ng> I can't tell what it is though. I do hope my laptop isn't developing issues
<tjaalton> Ng: flickers when it should go to sleep?
<tjaalton> probably g-p-m not doing it's business
<tjaalton> happens here too
<Ng> tjaalton: nup, I'm using it, I just get a tiny little flicker along the bottom, but I work in a maximised window that's sitting on top of nautilus' background window, so it's quite hard to tell if it's a window briefly corrupting or the display as a whole
<Ng> I have all the stupid "dim when idle" type options set off, and the display shouldn't be sleeping until it's been idle for half an hour
<jcristau> what chip?
<Ng> GM45
<jcristau> weird.
<Ng> yeah
<Ng> hrm, I have a horrible feeling this is happening at the driver/hardware level
<Sarvatt> Ng: I'd actually see if disabling the client side decorations patches for GTK+ fixes that issue
<Ng> Sarvatt: I thought that was already done in Lucid? aiui the CSD stuff is deferred
<seb128> Sarvatt, we did disable that one 3 weeks ago
<Sarvatt> oh? I've been getting the maximized gnome terminal title changes scrambling my display until I moved the mouse up to the panel that I got from it before since then and just assumed it was still on, sorry
<Sarvatt> bryceh: intel apport script is *definitely* too trigger happy, we're getting good bug reports masked because the gpu resets while still dumping and processing the previous reset and thats screwing things up
<Sarvatt> https://bugs.launchpad.net/bugs/539837
<ubottu> Ubuntu bug 539837 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__() (dup-of: 539533)" [Undecided,New]
<ubottu> Ubuntu bug 539533 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__()" [Medium,Confirmed]
<Sarvatt> does it make sense to have the dump udev rule like it is? isn't it getting run even if apport is disabled as it is now since its calling the apport script straight from the udev rule when theres a drm change event with RESET=1 in the env?
<Sarvatt> maybe putting it in -dbg where we can ask people to install it later when we ask for more info might be a good idea
<Sarvatt> hmm, we could go a step further by putting a modprobe.d conf with options drm debug=4 (or some other value) in the -dbg package for extra good upstreamable reports? bad idea? :D
<jpetersen> apport-gpu-error-intel.py seems to crash when there is no 'MachineType' key/value in the report, I attached a patch to https://launchpad.net/bugs/539533
<ubottu> Ubuntu bug 539533 in xserver-xorg-video-intel "apport-gpu-error-intel.py crashed with KeyError in __getitem__()" [Medium,Confirmed]
<bjsnider> Sarvatt, is the nouveau driver in the edgers ppa for lucid using galium?
<bjsnider> ricotz, already posed the question
<jibel> tseliot, hi, could you please have a quick look at bug 533970 . 
<ubottu> Launchpad bug 533970 in linux "package linux-image-2.6.31-20-generic 2.6.31-20.57 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [Undecided,Confirmed] https://launchpad.net/bugs/533970
<jibel> There are likely duplicates but hard to diagnose. Thanks.
 * tseliot has a look
<tseliot> jibel: I'm pretty sure that we fixed that in Lucid
<tseliot> jibel: in DKMS, that is
<jibel> tseliot, the duplicate is from a few days ago in lucid.
<tseliot> jibel: was it a dist-upgrade to Lucid?
<jibel> tseliot, no
<tseliot> hmm...
<tseliot> jibel: let me check with cjwatson
<jibel> tseliot, ok, thank you
<tseliot> jibel: #536711 might be different from #533970. I'll ask further information in the latter report
<jibel> tseliot, ok. There are many similar issues. Is there a way to distinguish them before triagers duplicates all of them ?
<tseliot> jibel: yes, using DEBCONF_DEBUG=developer should show me what's going on. For example: DEBCONF_DEBUG=developer sudo apt-get install -f
<jibel> tseliot, will do on recent reports of that kind. Thanks for your help.
<tseliot> jibel: thanks to you
<Sarvatt> bjsnider: darn my responses to him got lost, guess I wasn't connected at the time
<bjsnider> to ricotz?
<bjsnider> what were the responses?
<ricotz> Sarvatt, hi
<ricotz> Sarvatt, http://paste.ubuntu.com/396815/, compiz gives me not output, seems to fallback to metacity automatically
<Sarvatt> ricotz: that looks fine, running compiz --replace in a terminal gives no output at all? if you're using an actual VT you need to use DISPLAY=:0 compiz --replace, not sure if you tried from a VT or gnome-terminal
<Sarvatt> try compiz --debug --replace?
<Sarvatt> try LIBGL_DEBUG=verbose compiz --replace
<ricotz> Sarvatt, ok, one moment
<Sarvatt> they just merged a nv30 and nv40 unification in mesa and I'm expecting theres problems there you're hitting
<ricotz> libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so
<ricotz> libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so
<ricotz> libGL: Can't open configuration file /etc/drirc: No such file or directory.
<ricotz> libGL: Can't open configuration file /home/rico/.drirc: No such file or directory.
<ricotz> ^ output for LIBGL_DEBUG=verbose compiz --replace
<ricotz> Sarvatt, is it normal that /etc/drirc is missing
<Sarvatt> yep
<Sarvatt> only there if you installed driconf or manually changed it
<ricotz> ok, didnt do that
<Sarvatt> i'm not used to compiz being completely silent like this when theres errors, guess I'm used to having the wrapper still
<ricotz> Sarvatt, or is compiz blacklisting nouveau
<Sarvatt> nope it shouldn't be, I've used compiz on nv50 recently. i'm digging through the patches now
<ricotz> Sarvatt, using "LIBGL_DEBUG=verbose compiz --debug --replace" gives some complains about plugin files (compiz (core) - Debug: Could not stat() file /home/rico/.compiz/plugins/libccp.so : No such file or directory)
<Sarvatt> yeah I get that too
<ricotz> but i see no problem in that
<ricotz> ok
<Sarvatt> yeah they're in another package not installed by default
<ricotz> Sarvatt, are you the nouveau expert or RAOF?
<Sarvatt> i'm confused, it should be doing a printf any time it launches the fallback window manager
<Sarvatt> are you using metacity compositing?
<ricotz> yes
<Sarvatt> ahhh that explains it, cant start compiz with metacity compositing enabled
<Sarvatt> thats a global problem not nouveau specific
<ricotz> ahh ok, ill check
<Sarvatt> metacity --no-composite --replace & (or uncheck the option in gconf) then compiz --replace
<Sarvatt> its not actually launching the fallback, metacity is just refusing to give up compositing control to compiz
<ricotz> same output as before
<Sarvatt> you're sure metacity compositing  is disabled? no transparency? does the screen change to show just the background for a few seconds when you try to start compiz?
<ricotz> yes, i am using docky which is a good indicator when compositing is gone ;-)
<Sarvatt> pastebin ~/.xsession-errors?
<Sarvatt> RAOF: you're using an NV40, have you had any problems like this with xorg-edgers today or yesterday?
<ricotz> Sarvatt, no output
<ricotz> i think he is still asleep ;-)
<Sarvatt> just got my nvidia laptop back, 38 hours to fix all the bad hdd sectors on my wife's old one :( setting up nouveau on there now to see if I have any problems
<ricotz> Sarvatt, ok, ty
<ricotz> Sarvatt, another thing, are you able to run mutter on your main setup?
<Sarvatt> yep thats what I use all the time
<ricotz> ok, hoping gnome-shell is usable
<Sarvatt> it was here on nouveau about 3 weeks ago when I built it last at least, will check once i get nouveau setup
<ricotz> mutter/clutter needs to built against mesa git then?
<Sarvatt> superm1 or tseliot: can we add jockey-text commands to the nvidia maintainer scripts in a way where it will get setup right if installing nvidia-current from a console? like in recovery mode
<superm1> Sarvatt, you mean the postinst etc?
<Sarvatt> yeah
<Sarvatt> so it's actually working if you install it in recovery to try to fix things
<superm1> i'd say that's probably not a smart idea, because you have no ideas on the state of dbus when that might be running
<superm1> and you cant install from a chroot anymore
<Sarvatt> ah ok I don't know much about how jockey is set up so I didn't know if it was possible
<superm1> not to mention the circular loop of the fact those scripts get called when installing "from" jockey
<Sarvatt> oh really? can't install from a chroot? that means I can close a crapload of bugs about it installing against the host kernel thats not available in a chroot
<superm1> well it's possible now, but it wouldnt be if that change was made
<superm1> at least not easily
<Sarvatt> oh I see, there are quite alot of bugs about it not being able to install in a chroot because theres no headers for uname -r available
<Sarvatt> ricotz: sorry this is taking awhile, had a few weeks worth of updates to grab
<ricotz> Sarvatt, ok
<Sarvatt> huh, sudo jockey-text -d xorg:nvidia_current doesn't call update-initramfs?
<Sarvatt> need to remove the backlist from the initrd I thought
<Sarvatt> guess it does it silently because lbm-nouveau is still loaded 1 second in 
<Sarvatt> ricotz: sarvatt@arcueid:~$ DISPLAY=:0 compiz --replace
<Sarvatt> Launching fallback window manager
<Sarvatt> Couldn't find a perfect decorator match; trying all decorators
<Sarvatt> Starting gtk-window-decorator
<Sarvatt> compiz no workie here either
<Sarvatt> but I get messages..
<Sarvatt> probably just a transient mesa problem, hopefully it'll be fixed soon :D
<Sarvatt> installing your ppa packages and trying mutter
<Sarvatt> X crashed
<ricotz> Sarvatt, mutter will need to be built against edge mesa, i think
<Sarvatt> your PPA works fine on intel
<ricotz> mhh ok
 * ricotz need to grab dinner
<Sarvatt> plymouth is segfaulting and things are all screwed up because of it, ahh
<Sarvatt> things are all kinds of screwed up and I can't mess with it remotely (not near the machine now) :(
<Sarvatt> Window manager warning: Fatal IO error 11 (Resource temporarily unavailable) on display ':0.0'.
<ricotz> Sav
<ricotz> Sarvatt, using "MESA_DEBUG=1 LIBGL_DEBUG=verbose compiz --debug --replace" brings up a new line "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable"
<bjsnider> nvidia-current needs to conflict with nvidia-xxx-libvdpau to prevent mismatched libvdpau drivers
<Sarvatt> thats normal and nothing  to worry about ricotz, it always tries to load that lib since its not able to be distributed with mesa
<ricotz> Sarvatt, i have tried with latest mesa git, but it isnt working either
<ricotz> so hopefully there is a fix coming soon
<Sarvatt> can ya send me your /var/log/Xorg.0.log and dmesg just to look over? compiz isn't working here but I'd like to see how the packages are working on your system otherwise
<Sarvatt> guess I should build mesa with debug enabled to troubleshoot it more
<ricotz> yes this should generate more output
<ricotz> i just used your current packaging now
<Sarvatt> oh, you aren't using all of the xorg-edgers packages?
<Sarvatt> rebuilt mesa yourself?
<ricotz> yes
<ricotz> i am using all packages, and for testing i built the mesa git now
<Sarvatt> add --enable-debug to the confflags-common section in the rules
<ricotz> did you get the Xorg.0.log?
<Sarvatt> oh sorry didnt see the PK
<Sarvatt> PM
<Sarvatt> nope DCC sends are screwed up with my bouncer it looks like
<Sarvatt> woohooooo jcristau's patches to move libdrm headers to $(includedir)/libdrm instead of $(includedir)/drm went upstream,  no more interfering with linux-libc-dev half of every release cycle :)
<RAOF> Sarvatt: Good morning.
<Sarvatt> that gets old fast because linux-libc-dev updates overwrite the libdrm-dev headers when you just use Replaces: linux-libc-dev in libdrm-dev
<Sarvatt> heyo RAOF!
 * bryceh waves
<Sarvatt> can you try xorg-edgers and see if gallium works for you on your NV40 if you get any time today RAOF?
<RAOF> Already have done; compiz fails silently.
<ricotz> Sarvatt, i sent it to you via email
<Sarvatt> thanks ricotz 
<Sarvatt> looks like you arent alone on compiz failing silently on nv40 right now :D
<ricotz> RAOF, hi, was hoping you have an idea, wanted to try nouveau :-)
<ricotz> RAOF, did you have time for docky yet?
<RAOF> No, sorry.
<RAOF> Sarvatt: neverputt SIGSEGVs in nouveau_dri.so; I'd guess edgers is just plain broken for now.
<Sarvatt> yeah a crapload of gallium changes in mesa the past few days including the nv30-nv40 unification :(
<RAOF> Aaaand that's my morning 10 minutes of xorg-edgers :)\
<Sarvatt> building intel gallium now to see what happens when you have both classic and gallium dri drivers available
<ricotz> Sarvatt, now i just installed your ppa mesa packages of 20100313 and its working
#ubuntu-x 2010-03-18
<Sarvatt> tip for nvidia backlight bugs on lenovo laptops.. https://bugs.launchpad.net/bugs/540112
<ubottu> Ubuntu bug 540112 in nvidia-graphics-drivers "Can not change LCD brightness on Lenovo Y450 laptop" [Low,Incomplete]
<bryceh> best bug comment ever:  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/522485/comments/3
<ubottu> Ubuntu bug 522485 in xserver-xorg-video-ati "Mouse pointer disappears after recovering from suspend" [Undecided,Invalid]
<chrisccoulson> bryceh - you're lucky. i had someone paste their entire life story on 2 bugs i'm subscribed to today ;)
<chrisccoulson> the same essay on each...
<bryceh> "and then my dog ran over my girlfriend..."
<bryceh> chrisccoulson, I had one xkeyboard-config bug where two guys got into it hot and heavy over a crimean keyboard layout
<chrisccoulson> lol
<chrisccoulson> some comments make for an interesting read ;)
<bryceh> something about what russians or turks did to tartars 200 years ago
<bryceh> even made its way upstream, and the xkeyboard-config maintainer is in Moscow, and when he opted not to do the change asked for, whew knives flew
<jcristau> yeah that one was wild
<RAOF> How do ants eat a laptop?
<RAOF> Hm.  My camera seems to have been infected by 10.04 branding.  Everything's a shade of purple, and streaky :(
<BUGabundo> aahaah
<bjsnider> what kind of ants were these exactly?
<bryceh> bjsnider, that calls for a pun but I can't think of one
<johanbr> bryceh, "it's better to have your computer bitten by bugs than eaten by ants" ?
<Sarvatt> well XAA: disable render accel in -ati just now should fix part of bug #513956
<ubottu> Launchpad bug 513956 in xserver-xorg-driver-ati "[XAA] garbled screen with compiz but no KMS on ATI Radeon Mobility 7500" [Unknown,Confirmed] https://launchpad.net/bugs/513956
<bryceh> Sarvatt, yeah although I'm uncertain there was any configuration where EXA worked for jesse
<RAOF> Is there any way we can fiddle with acpi lid status from userspace?  I'm suspicious that bug #53618 's low-res on laptop open is due to the intel assuming lvds is disconnected because the lid's closed, and so X bails with no screens.
<RAOF> Leaving the actual bug as to why X is getting SIGQUITted.
<bryceh> RAOF, I recall there were some various acpi tools, but I don't remember if they could update the lid status
<RAOF> Hm.  i915 doesn't seem to have any lid-status options, either.  Are they just quirking lids on an as-discovered basis?
<bryceh> Sarvatt, graph went down today :-) http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg
<tjaalton> btw I tested whot's wacom-branch that'll likely become 0.10.5 very soon.. works fine
<bryceh> tjaalton, great
<tjaalton> bryceh: openchrome is twice on the graph
<bryceh> that's weird
<tjaalton> or is the other "the remainder"?
<bryceh> maybe
<tjaalton> same color though
<bryceh> but I didn't do the remainder thing for this graph, as there weren't as many packages
<bryceh> it's completely rewritten graph code (done in python instead of perl this time), but uses the same gnuplot code
<bryceh> the black is suspicious
 * bryceh adds to his todo list to investigate this one day
<bryceh> tjaalton, sometimes I think having my sons' room right outside my office was a bad design choice
<tjaalton> bryceh: hah :)
<tjaalton> I woke up at 5:30 this morning
<tjaalton> same yesterday
<tjaalton> waiting the time when we switch to summertime
<tjaalton> the weekend after next I think
<tjaalton> bryceh: we keep the crib in our bedroom, and the middle-one still comes every night there, so it's pretty crowded there ;)
<tjaalton> s/there$//
<bryceh> heh
<bryceh> tjaalton?
<bryceh> tjaalton, it's baaack
<bryceh> http://bryceharrington.org/X/Reports/ubuntu-x-swat/PkgList/versions_current.html
<tjaalton> bryceh: excellent, thanks
<Ng> awesome, X just crashed when I opened a huge png in firefox
<richthegeek> Can someone take a look at #540564. Seems like it might be quite important.
<richthegeek> prepare to type kick...
<richthegeek> !help | richthegeek
<ubottu> richthegeek, please see my private message
<tseliot> bug ##540564
<tseliot> heck, bug #540564
<ubottu> Launchpad bug 540564 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/drm_fops.c:146!" [Undecided,New] https://launchpad.net/bugs/540564
<tseliot> richthegeek: hmm... kernel oops with the Nvidia proprietary driver, it may not be easy to debug. apw, any ideas?
<richthegeek> tseliot, one moment
<richthegeek> sorry, I meant #540834
<richthegeek> bug #540834
<ubottu> Launchpad bug 540834 in ubuntu "Lucid daily live build does not get past Plymouth" [Undecided,New] https://launchpad.net/bugs/540834
<richthegeek> #540564 isn't exactly a massive issue compared to #540834
<richthegeek> i gotta get to uni now, won't be able to do any testing until this evening (currently 11.31 for me, not around till 5.31)
<tseliot> richthegeek: I guess that happens using nouveau (try booting in safe mode). Also, you might want to ask Keybuk in #ubuntu-devel about plymouth
<richthegeek> tseliot: safe mode on a livecd? what's the key combo for that?
<tseliot> tjaalton: ^^
 * tseliot hasn't used that mode for a while now
<richthegeek> right, im off, leave this running though./
<tjaalton> it's probably hung then
<tjaalton> if nothing works
<tjaalton> commented
<rye> richthegeek, are you sure it is not related to #534469 ?
<rye> richthegeek, what happens if you actually unplug the second display?
<Sarvatt> phew crazy morning already and it's only been 2 hours :D
<Sarvatt> bryceh: XAA is used by -ati if <=32MB vram which that Jesse person had, he should have an option in bios to up that which would fix all his EXA problems :(
<Sarvatt> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg went down?? I see a huge spike, maybe that went up after you said that
<Sarvatt> nouveau is busted for me completely
<Sarvatt> removing quiet splash makes plymouth segfault and boot is hung
<Sarvatt> not removing it leaves the splash screen up 100% of the time and I can't get gdm to start right
<tseliot> Sarvatt: was this caused by a update of nouveau?
<tseliot> an
<Sarvatt> no, plymouth :(
<Sarvatt> it was working fine with the same nouveau before these last few plymouth updates (back around 0.8.0-~12 or -~14)
<tseliot> Sarvatt: you might want to ask Keybuk about that in #ubuntu-devel
<Sarvatt> I dont have time to troubleshoot it more though, completely swamped with other things at the moment.. in the middle of trying to fix 6 other bugs and wont be near that machine today
<Sarvatt> people emailing me "reminding" me to update xorg-edgers packages every day now..
<rye> Sarvatt, how many displays do you have attached to your nouveau box?
<knittl> hi. i really want suspend to work with nvidia :D
<Sarvatt> just the 1
<knittl> where can i install new drivers?
<rye> hm... Then bug #533135 does not apply
<ubottu> Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135
<Sarvatt> knittl: they arent in the archive yet, but the new ones will almost certainly fix your resume problems
<knittl> Sarvatt: is there a ppa available?
<Sarvatt> not that I know of
<knittl> nvidia website?
<Sarvatt> not compatable with lucid
<knittl> will it break alternative system or sth?
<Sarvatt> yeah
<knittl> aw crap
<Sarvatt> just give it a few days, everyone is swamped trying to get beta 1 ready
<knittl> I installed 195.36.15 from the nvidia installer and I've done four
<knittl> successful suspend/resume cycles, so it does seem to fix the problem.
<knittl> where has he got 195.36 from? :D
<knittl> oh hm. beta is due today. alright then
<knittl> #534754
<Sarvatt> tseliot: I've been marking nvidia-graphics-drivers bugs guaranteed fixed by 195.36.15 as (Needs 195.36.15) in the subject whenever you update it
<knittl> bug #534754
<ubottu> Launchpad bug 534754 in nvidia-graphics-drivers "(Needs 195.36.15) X crashes during suspend/resume" [High,Triaged] https://launchpad.net/bugs/534754
<ricotz> Sarvatt, hi, have nouveau running with compiz
<knittl> thx ubottu
<tseliot> knittl, Sarvatt: I've uploaded 195.36.15 to Lucid but it will be built only after the beta
<Sarvatt> got nvidia-graphics-drivers bugs down to 1 page so they are easy to spot
<Sarvatt> ahh there ya go knittl :)
<tjaalton> if it's plymouth that breaks nouveau then keybuk needs to be made aware of it ASAP
<knittl> tseliot: great. thank you :)
<knittl> where's the build queue again?
<tseliot> Sarvatt: really, 1 page? Impressive
<Sarvatt> ricotz: yeah I heard, old mesa? I'll let ya know if I see any mesa commits that fix it so you can update
<ricotz> yes, the older mesa package from ppa
<ricotz> some graphic errors, but it is stable
<tseliot> knittl: https://launchpad.net/builders/ perhaps?
<Sarvatt> tseliot: why the heck is drm loading - http://launchpadlibrarian.net/41177525/OopsText.txt
<Sarvatt> tseliot: the problem is nouveau isnt blacklisted for them
<tseliot> let me check
<Sarvatt> just looked at the bug you linked in another channel
<tseliot> maybe /usr on a different partition?
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/540564
<ubottu> Ubuntu bug 540564 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/drm_fops.c:146!" [Undecided,New]
<Sarvatt> maybe, asking
<tseliot> thanks
<tseliot> I plan on dealing with that too
<knittl> tseliot: no, not what i was looking for. nevermind, not that important
<tseliot> knittl: my upload hasn't been approved yet (as we're in beta freeze)
<tseliot> maybe you'll see it tomorrow (?)
<knittl> no problem ;)
<knittl> Fixed a bug that caused the X server to crash when rendering occurred while the X server was not on the active VT.
<knittl> \o/
<knittl> :)
<Sarvatt> knittl: yeah the people that needed that fix were very easy to identify because they all had the same backtrace showing it still rendering after a VT switch (such as when suspending)
<knittl> i also need that fix ;)
<Sarvatt> ricotz: commits prefixed dri/nouveau don't apply to gallium nouveau drivers so no need to rebuild and check those incase you're doing that
<Sarvatt> thats classic mesa nouveau_vieux_dri.so for <NV30
<ricotz> Sarvatt, not doing that ;-), thanks
<ricotz> Sarvatt, why does mesa hasnt got a "make dist"?
<Sarvatt> because mesa's build system is horrible :) the maintainers mostly use scons on windows.. you can use something like this though - tar --exclude=debian --exclude=debian/* --exclude=.git --exclude=.git/* -cf - mesa | gzip -9 >mesa_7.9.0+git20100318.xxxxxxxx.orig.tar.gz
<Sarvatt> uploading a new mesa to edgers now since it fixes the texture tiling problems on intel now that its defaulted to on
<Sarvatt> i need to bump libdrm in there but it needs a lot of build system changes, not enough time in a day
<bryceh> Sarvatt, whoops, yeah it was down at the point I mentioned it to you
<bryceh> Sarvatt, looks like a bunch of new nouveau reports came in plus some other stuff
<tjaalton> probably your tagging run that made that :)
<bryceh> Sarvatt, btw can you renew my xorg-edgers membership?
<Sarvatt> sure thing, done
<Sarvatt> hmm yeah tagging run was a little off
<Sarvatt> marked this karmic - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/537801
<ubottu> Ubuntu bug 537801 in xserver-xorg-input-evdev "Touchscreen doesn't work after karmic->lucid upgrade" [Undecided,Fix committed]
<bryceh> tjaalton, oh yeah could be
<bryceh> tjaalton, I fixed a unicode bug that was causing the script to crash early on in processing
<bryceh> tjaalton, btw I got the bottom bit of the graph back
<Sarvatt> oh didnt remove the lucid tag so no big deal
<bryceh> Sarvatt, yeah it would have put lucid on there if it saw it
<bryceh> er, if it didn't see it there already
<bryceh> although admittedly it's not hard to confuse the scripts
<bryceh> ahhh ok so that's why there's so many more packages listed
<bryceh> it used to crap out halfway through processing and was going through them package by package
<tjaalton> bryceh: whee, ok
<bryceh> makes the graph look smooshed though.  hmm
 * bryceh cheats and just makes graph wider
<bryceh> tjaalton, looks like whatever I fiddled with solved the -openchrome doubling too
<bryceh> oh wait, now there's a double -vesa
<tjaalton> <g>
<bryceh> aha there we go
<Sarvatt> woohoo, my wife was using one of my laptops for 2 weeks or so and now she's complaining about going back to windows now that hers is fixed because she got so used to having all the useful info on the panel :) its just too bad I had lucid on there and she got frustrated hitting enter restarted gdm and the splash is pretty pointless on with non KMS since we only have the smooth transition stuff with KMS 
<Sarvatt> drivers and its only there for a second
<Sarvatt> no photoshop is the deal breaker for her though
<Sarvatt> plus she hated the new min/max/close button placement and moving things to the right in the correct order looks messed up since the minimize button border is designed to be in the middle
<Sarvatt> I dont think anyone on the design team uses gnome panel drawers because the background is screwed up also :)
<hyperair> heh
<hyperair> go complain on #ayatana
<bryceh> Sarvatt, email shuttleworth ;-)
<bryceh> Sarvatt, my wife is not fond of the button movement idea either
<hyperair> i am not fond of the button movement.
<bryceh> but I have so far refrained from upgrading her to new ubuntus until they're released
<bryceh> (and usually not for a couple weeks after)
<hyperair> but i've never once used any of ubuntu's default themes for more than a day.
<tjaalton> my wife eats my dogfood
<Sarvatt> i loved the stock human netbook theme
<tjaalton> though I had karmic until january
<Sarvatt> anyone used photoshop through wine? i'm guessing cs4 wont work but she usually uses cs3 anyway
<tjaalton> check winehq
<tjaalton> http://appdb.winehq.org/objectManager.php?sClass=application&iId=17
<tjaalton> looks like cs3/4 won't work
 * hyperair hasn't used photoshop in over two years.
<hyperair> i think i installed it once, but never used it
<hyperair> i think it was cs3.
<bryceh> Sarvatt, there is a photoshop-like UI for gimp.  I forget the name though
<tjaalton> it's merged for 2.8
<tjaalton> which should arrive for christmas
<kazade> Hi all, I need some help. My bro has just upgraded to Lucid, but now KMS causes him a blank screen, he's using nouveau how do I instruct him into a failsafe (vesa) mode?
<kazade> he can only see as far as grub, and only then by pressing shift otherwise the refresh rate goes out of range or something immediately after
<kazade> anyone?
<rafiyr> I've just reported bug 541453, which requires a small patch be applied to the wacom X driver to get basic functionality for ntrig devices to work on lucid, out of the box.
<ubottu> Launchpad bug 541453 in lucid "basic ntrig functionality broken in lucid" [Undecided,New] https://launchpad.net/bugs/541453
<tjaalton> rafiyr: is it upstream?
<rafiyr> no
<tjaalton> huh, didn't know there was a project called lucid
<rafiyr> and won't be
<tjaalton> why not?
<rafiyr> lucid lynx, ubuntu 10.04
<tjaalton> yes, but you filed it against a project, not package
<rafiyr> The only thing that patch does is enable the wacom driver to support another manufacturer's hardware.  They didn't seem particularly interested when I sent the patch to the mailing list
<rafiyr> Ah
<tjaalton> "Lucid Editor NOT UBUNTU"
<rafiyr> Sorry, not quite sure where to file.  I suppose it would have been easier to file the patches separately to the packages
<rafiyr> :)
<tjaalton> done
<tjaalton> who proposed the patches and when?
<tjaalton> I'd check the list
<rafiyr> I proposed a similar patch several months ago rafi@ugcs.caltech.edu is the address I think I used
<bryceh> rafiyr == Rafi Rubin I assume?
<tjaalton> found it
<bryceh> rafiyr, oh hey you're a caltechie too?  :-)
<rafiyr> Yup
<rafiyr> undergrad plus a number of years as research staff after
<rafiyr> currently at upenn working on my phd
<rafiyr> Are there a lot of techers making trouble for ubuntu?
<tjaalton> rafiyr: well seems like you need to resend it, Ping didn't decline it but want's to be sure it doesn't break anything
<bryceh> rafiyr, I just went there for my masters
<bryceh> rafiyr, haven't run into any others
<rafiyr> tjaalton: oh. I guess I misread or missed something, that was a while ago
<rafiyr> when were you there?
<bryceh> rafiyr, btw it will work with various processes better to attach files individually to bug reports rather than in a tar
<tjaalton> rafiyr: since it needs kernel support too it's likely too late for lucid, especially since it's not upstream
<rafiyr> understood
<bryceh> for example, patch files get auto-detected and make it through certain filters so they bubble up to the top of priority lists
<tjaalton> indeed
<bryceh> also makes it easier to look at the patches online, rather than downloading and uncompressing the tar
<rafiyr> I'll check with jiri to see why its not upstream yet, and if he can fix that.
<bryceh> so stuff gets more review
<tjaalton> rafiyr: yeah it needs upstream review
<rafiyr> I didn't see an obvious method to attach multiple patches
<tjaalton> one at a time
<bryceh> rafiyr, there isn't, just do separate comments for each
<rafiyr> Ah
<bryceh> well, if you reply to a bug via email you can do multiple attachments
<bryceh> but not thru the web
<bryceh> btw xf86-input-wacom_ntrig_2010_02_03.patch is already in lucid; I put that one in last week, for 0.8.4.1-0ubuntu5
<rafiyr> Well, first time using launchpad, so I'll just call this a learning experience.
<rafiyr> oh, thought that only hit your ppa
<rafiyr> thanks
<bryceh> no it looked sane so I just put it in the distro proper
<rafiyr> And yeah, I'll resend it to linuxwacom.
<bryceh> 2010_03_10_ntrig.patch - this is a kernel patch?
<bryceh> yep
<Sarvatt> kazade: adding blacklist=nouveau to the kernel command line in grub should work
<tjaalton> Sarvatt: but is plymouth busted as you suggested?
<kazade> Sarvatt, thanks that's good to know. Luckily he had a previous kernel so that got him into vesa mode :)
<tjaalton> blacklisting does the same
<Sarvatt> it wont load the drm renderer for plymouth if nouveau is blacklisted so it should still work for vesa?
<Sarvatt> i haven't tested that
<rafiyr> If the march 10nth patch isn't applied to the release kernel, can we shift to using wacom instead of evdev by default?
<rafiyr> More context: wacom as the default driver to support the n-trig touch sensor.  wacom is already the default for the pen sensor.
<tjaalton> bryceh: you said on the n-trig patch that you uploaded something a week ago? the one in the archive was touched by me though
<tjaalton> s/patch/bug
<tjaalton> and there's no wacom-tools anymore :)
<bryceh> tjaalton, durff
<bryceh> tjaalton, I see there's no xsfbs/ in -wacom's debian dir, should I add that so I can set up the patch system?
<tjaalton> bryceh: that's one option
<bryceh> tjaalton, other options?
 * bryceh adds xsfbs
<tjaalton> well that's probably the easiest one, though it adds some bloat to the diff
<bryceh> tjaalton, hey with the xorg-pkg-list versions report, I've been collecting each day's page, I guess for historical reference.  Is there actually some value to continuing to do that?
<bryceh> if you care only about the current day's versions, I could limit it to just producing one page, and get rid of the historical data
<bryceh> if there's some value to it I can leave it as is, it doesn't actually take up that much disk space
<tjaalton> bryceh: oh, didn't know/remember that. can't think of a reason to keep those right now
<bryceh> alright
 * bryceh todos a cleanup
<tjaalton> but if they are harmless, then why not keep them for awhile
<tjaalton> or not :s
<bryceh> hehe
<bryceh> well now that I've got more reports I'm trying to mold the older ones into some sense of consistency with the new ones
<bryceh> -wacom uploaded for real this time
<rafiyr> bryceh: how do I grab the src package to take a look?
<bryceh> rafiyr, not sure if the source package is available.  I can pop it into the ppa though.
<bryceh> ...done
<bryceh> should show up there in a couple minutes
<rafiyr> bryceh: If I just do a general update of the package will I get the fixed binary, or is that pushed to beta1?
<tjaalton> rafiyr: does it work without the kernel bits?
<bryceh> rafiyr, if you have the ppa installed, yeah you should get it by just doing a general update
<bryceh> if you don't have the ppa installed, then it will come via a regular update in a day or two
<tjaalton> the archive is frozen, no?
<tjaalton> at least until tomorrow
<bryceh> tjaalton, right, which is why it will come in a day or two
<tjaalton> hum right
<rafiyr> tjaalton: I think it should work fine with the 34-rc1 kernel
<rafiyr> but the last couple firmwares really broke everything, and will at least need that update
<tjaalton> rafiyr: so the kernel patches were from .34rc1?
<rafiyr> tjallton: mostly, but the last one was a minor fix for BTN_TOUCH, that hasn't made it to the mainline yet.
<rafiyr> -wacom doesn't really care about that event and is unaffected
<tjaalton> ok
<tjaalton> wonder if the waltop will work with a similar patch
<rafiyr> It should be easy to test
<tjaalton> yeah I'll try that next weekend
<rafiyr> I will need to test -wacom from that ppa.  I know the pen works fine, but I haven't used touch on such an old version for quite a while
<bryceh> rafiyr, I have a fujitsu multitouch laptop I can use for testing.  How do I check to see what mt hardware it uses?  lsusb, lshw, lspci don't give any indication of what manufacturer it is
<bryceh> other than Intel or 'Linux Foundation'
<rafiyr> no vendor id?
<rafiyr> Bus 003 Device 002: ID 1b96:0001 N-Trig Duosense Transparent Electromagnetic Digitizer
<rafiyr> That first 4 digit hex code is manufacturer
<bryceh> rafiyr, nope
<rafiyr> is it serial?
<tjaalton> which model is it?
<rafiyr> wacom was mostly serial for a long time
<bryceh> http://pastebin.com/gmkcEnfg
<rafiyr> Oh, try "sudo lsusb"
<bryceh> http://pastebin.com/p6zPqQP5
<bryceh> lshw for good measure:  http://pastebin.com/GfWg11AR
<tjaalton> it's a wacom
<tjaalton> probably serial then
<bryceh> how can I verify that?
<rafiyr> Xorg.0.log
<Sarvatt> hmm thats odd, nouveau headers in libdrm get installed to ${includedir}/nouveau ?
<bryceh> (II) config/udev: Adding input device Serial Wacom Tablet (/dev/ttyS0)
<bryceh> aha
<tjaalton> it doesn't work?
<rafiyr> for what its worth there was a press release that fujitsu and n-trig are going to work together for a next gen device.  One capable of supporting (gasp) more than 5 fingers
<bryceh> heh, like the most obvious place for it, didn't even think to look
<tjaalton> the pen should work at least
<bryceh> rafiyr, awesome, the venusians will be so happy
<tjaalton> wow, I have ten fingers
<tjaalton> :)
<rafiyr> well they actually said 10 or more
<tjaalton> lots of handwaving
<Sarvatt> too bad wacom only handles 1 or 2 finger gestures :D
<rafiyr> plenty of talk about mt being interesting for multi-person interaction.  And for that, I could see wanting a bit more than 10.  Like for elementary schools wanting to support 10+ children finger painting on a giant table display that cost more than the teacher
<nishanth> can someone help me fix the desktop visual effects
<nishanth> ?
<tjaalton> just ask, don't ask to ask
<Sarvatt> would kind of help if you gave us more info on what the problem is :)
<bryceh> tjaalton, can I ping you?
<bryceh> ;-)
<tjaalton> bryceh: well you just.. oh, nevermind ;)
<bryceh> ok, so stylus works out of the box.  nice.  no eraser though, and touch is not working
<nishanth> well i tried to change the appearance preference from none to extra and it does not do it
<rafiyr> is it just a matter of the X  config?
<nishanth> it gives a prompt saying desktop effect could not be enabled after blinking a couple of times
<Sarvatt> where's this wacom patch at that extends it for n-trig support?
<Sarvatt> the udev rules need updating for sure
<rafiyr> http://ofb.net/~rafi/xf86-input-wacom_ntrig_2010_02_03.patch
<nishanth> is there a way i can fix this?
<Sarvatt> nishanth: please run ubuntu-bug xorg and link the bug report here, we need to see logs
<rafiyr> The actual delta is just:
<rafiyr> -	{ 0xE3, 2540, 2540, &usbTabletPC   }  /* TabletPC 0xE3 */
<rafiyr> +	{ 0xE3, 2540, 2540, &usbTabletPC   },  /* TabletPC 0xE3 */
<rafiyr> +	{ 0x1 , 1122,  934, &usbTabletPC   }  /* N-Trig TabletPC */
<rafiyr>  
<rafiyr> -	if (sID.vendor == WACOM_VENDOR_ID)
<rafiyr> +	if (sID.vendor == WACOM_VENDOR_ID || sID.vendor == 0x1b96)
<bryceh> mm, with some futzing in gimp, pressure sensitivity works, and the eraser will draw if I push hard, but no erasing
<nishanth> can you tell me how to do it plz... i am very new to linux
<Sarvatt> open a terminal or press alt+f2 and type ubuntu-bug xorg
<bryceh> Sarvatt, it's in the multitouch ppa you set up for me
<rafiyr> bryceh: first off test the input device to make sure you're seeing the events (xinput test).  And if so, you might want to futz with the pressure curve setting with xsetwacom
<Sarvatt> sheesh chrome is using REDICULIOUS amounts of ram the past week or so, 10 launchpad tabs is using 1.5GB memory
<rafiyr> Yeah, things have gotten so bloated, lynx is eating 3.5MB, tsk tsk
<bryceh> rafiyr, yeah xinput test is seeing the eraser events
<rafiyr> bryceh: xsetwacom -x get eraser Presscurve
<Sarvatt> i believe you need to create a input/wacom symlink and another symlink for input/wacom-touch for the touch device? the wacom udev rules are only creating the symlinks for wacom vendor id's
<tjaalton> are those links used by anything, or just for convenience?
<rafiyr> Do udev and hal actually just poke at serial devices looking for wacom digitizers?
<rafiyr> The driver can certainly tolerate using a single device node for all three tools (that's the way I used to use it, until I split off touch).
<Sarvatt> oh it's a serial device? are you sure its even using wacom and not evdev then bryceh?
<tjaalton> evdev doesn't handle serial devices aiui
<rafiyr> If it did, you could check by trying to draw a straight line :)   (wacom smooths, evdev doesn't)
<Sarvatt> oh bryceh> +(II) config/udev: Adding input device Serial Wacom Tablet (/dev/ttyS0)
<nishanth> ok i did "ubuntu-bug -p xorg" it opened something called launchpad
<nishanth> now what?
<Sarvatt> guess he added the new match to the rules, are the subdevices not getting set up?
<Sarvatt> do everything it says to file it and paste a link to the bug report when its done
<tjaalton> the wacom rules already have entries for serial devices
<tjaalton> has
<Sarvatt> yeah but only wacom and fujitsu
<tjaalton> and this was wacom
<Sarvatt> huh.. i thought he was working with n-trig.. I'll shut up now :)
<tjaalton> he thought so as well ;)
<tjaalton> I think
<tjaalton> now I'll shut up
<rafiyr> <sheep mode> shutting up</sheep mode>
<nishanth> is there a way to fix the desktop visual effects
<nishanth> also does anyone know how to fix plymouth?
<tjaalton> what hw do you have?
<tjaalton> the graphics card
<nishanth> tjaalton : are you asking me?
<tjaalton> yes
<nishanth> oh ok
<nishanth> is there a way to find out what it is?
<tjaalton> lspci |grep VGA
<nishanth> VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
<rafiyr> While multitouch isnât factory enabled for the touchpad, it can be turned on through the Control Panel.
<rafiyr> bryceh: there's you're problem just go to the control panel...
<rafiyr> More seriously is the screen actually multi touch, or just the touchpad
<rafiyr> The xorg log should report the actual wacom model, I think, that might help to answer the question.
<rickspencer3> RAOF, hi
<nishanth> tjaalton: VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
<rickspencer3> just checking wrt the x meeting on Thursday
<rickspencer3> it's been a couple days, wondering if you've been able to make progress?
<tjaalton> nishanth: got it
<bryceh> yep, wacom.  draws nice straight lines
<nishanth> tjaalton; is this some driver related problem?
<tjaalton> nishanth: if you already have effects working it's not a driver problem
<bryceh> got the eraser working.  was a pebkac bug
<rafiyr> what's pebkac?
<nishanth> tjaalton: I dont have effects working
<tjaalton> bryceh: needed to configure it in gimp?
<bryceh> (i.e. have to click the eraser on the eraser button first.  dhurr)
<RAOF> rickspencer3: I presume you mean the meeting on Wednesday (or Tues your time?).  I've had some progress on the bug triage, but I wanted to finish off f-spot first.  I've got more time scheduled for X going forward.
<rickspencer3> RAOF, yest hat meeting
<rickspencer3> RAOF, ok, thanks
<nishanth> tjaalton: i tried to change the visual effect from none to extra and it could not do it
<rafiyr> um, yeah, with each physical tool, you click the gimp tool you want it to represent.  Just like drawing with the mouse.
<tjaalton> nishanth: then file the bug
<tjaalton> nishanth: create the lp account etc
<Sarvatt> thats an arrandale :(
<RAOF> rickspencer3: I've got all the nouveau bugs in either upstreamed or waiting for information from the reporter state, at least.
<tjaalton> Sarvatt: ok, so won't work?
<nishanth> tjaalton: i did 
<rickspencer3> RAOF, nice
<Sarvatt> it should work, theres just issues for some people, need a bug report to look at it more
<tjaalton> nishanth: so which bug # is it?
<tjaalton> can't see it on the xorg list
<bryceh> (--) Serial Wacom Tablet eraser: Wacom General ISDV4 tablet
<nishanth> tjaalton: how can i check if it is there?
<bryceh> (II) "Fujitsu FUJ02E3": Device reopened after 1 attempts.
<tjaalton> nishanth: check your profile bug stats
<Sarvatt> i dont see a nishanth user on launchpad, what name did you create the account with?
<bryceh> rafiyr, pebkac == 'problem exists between keyboard and chair'
<bryceh> or in this case I guess it should be pebsac == 'problem exists between screen and chair' ;-)
<rafiyr> ;)
<nishanth> tjaalton : check now
<tjaalton> Driver		"vesa"
<tjaalton> there's your problem
<tjaalton> you are not using the intel driver..
<nishanth> is there a  way to know what driver i am using?
<tjaalton> for one reason or another failsafe kicked in
<tjaalton> well, vesa
<nishanth> i think it is vesa
<tjaalton> I just said that :)
<tjaalton> it says so on your xorg.conf
<tjaalton> sudo rm /etc/X11/xorg.conf
<Sarvatt> nishanth: you manually changed the driver to vesa?
<Sarvatt> or did you install it recently with the safe graphics option maybe?
<Sarvatt> not sure if casper's xforcevesa xorg.conf gets transferred if you install in that mode
<bryceh> what is "Virtual core XTEST pointer" ?
<tjaalton> the appearance capplet should probably point out if the driver is vesa
<nishanth> ok i removed it
<nishanth> tjaalton: why did you want me to remove it?
<tjaalton> nishanth: because you don't want to use it
<tjaalton> nishanth: then reboot
<nishanth> i installed 9.10 with safe graphics mode and then i upgraded to 10.04
<nishanth> so  all i had to do was remove xorg.conf?
<tjaalton> yes
<nishanth> is there any other thing that i need to install to take its place?
<tjaalton> no
<Sarvatt> nope
<nishanth> ok
<Sarvatt> that was the problem though, i'm surprised vesa even worked for you
<Sarvatt> makes sense though, you should need to install karmic in safe graphics mode because its too old to support that new of a video card
<tjaalton> should jockey offer to remove the obsolete xorg.conf if it knows the hw is properly supported?
<tjaalton> in the new version
<ricotz> Sarvatt, i think you need to update xserver-xorg-video-nouveau aswell http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=e2146d3b29a4bea3d584c145e3190c3313692ed9
<nishanth> yay!! it worked
<tjaalton> there you go
<nishanth> but still did not fix plymouth
<tjaalton> run 'ubuntu-bug linux' then
<tjaalton> or perhaps it's plymouth again
<Sarvatt> ricotz: i needed to update libdrm and such first before anything and that *just* finished... give me some time man :)
<nishanth> so just type ubuntu-bug linux in terminal ?
<tjaalton> yes
<nishanth> ok
<tjaalton> it'll gather logs that the kernel team needs
<ricotz> Sarvatt, sorry dont wanted to push you
<bryceh> rafiyr, since this is a serial touchscreen laptop, is it at all relevant for our testing of MT?
<bryceh> otherwise I'll have to wait until the new hw comes
<tjaalton> bryceh: btw, some errors in the versions_current list. for instance -ati versions in debian are old
<rafiyr> bryceh: if its mt, it will be eventually
<bryceh> tjaalton, ok I'll investigate
<tjaalton> bryceh: seems to be the only one
<nishanth> strange it did not give me a  new launch pad  page saying report it 
<Sarvatt> oops, looks like I got booted from freenode, nishanth: what exactly is your problem with plymouth?
<nishanth> i dont see the plymouth animation when booting
<Sarvatt> when is the last time you updated your system?
<Sarvatt> you don't see the ubuntu logo at all when you boot up?
<nishanth> today afternoon
<Sarvatt> theres not really much animation to it, if you boot fast enough I dont think it even loads the progress indicator dots, thats why I was wondering if you saw the ubuntu logo at all
<nishanth> i am having a new problem now
<Sarvatt> whoa is this new?? Get:1 http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ lucid/main libosmesa6-dev 7.9.0~git20100318.3c0eab71-0ubuntu0sarvatt [828kB] -- I swear it used to just say the ppa.launchpad.net part not the specific PPA its from
<nishanth> my mouse does not work on youtube videos
<RAOF> Sarvatt: Yeah, I think that is new.
<nishanth> i think it has got to do something with compiz cofig setting manager
<RAOF> nishanth: What do you mean by âdoes not workâ, and why do you think it has something to do with ccsm?
<Sarvatt> firefox or chromium? does it work with effects set to normal instead of extra?
<RAOF> Hooray for user-error bug reports.
<nishanth> well let us say you want to watch  a video from the middle  instead of the begining
<nishanth> i am going to uninstall compiz
<RAOF> nishanth: You mean: left mouse button doesn't work in youtube?  Right, nspluginwrapper bug.  Hold down the right mouse button & left click works :)
<nishanth> oh it worked
<Sarvatt> nishanth: this kind of thing is more appropriate in #ubuntu+1
<nishanth> is there a way to fix it?
<apw> bryceh, here are some test kernels with the i915 powersave turned off for <= 945: http://people.canonical.com/~apw/i915-powersave-broken-lucid/
<apw> [    4.719350] [drm] dynamic power saving: broken=1 enabled=0
<apw> that tells you that we think it was broken, and it was not enabled ... kerenel command line option is king
<apw> bryceh, images are actually still syncing ... be there in < 10m
<apw> Sarvatt, RAOF ^^
<RAOF> apw: Thanks.
<Sarvatt> apw:  sweet, will give it a spin as soon as its up
<Sarvatt> btw i'm fairly sure only intel_i915gm_info intel_i945gm_info need it, it's a framebuffer compression problem here on mine and only those two have .has_fbc = 1
<Sarvatt> but being safe just incase is nice anyway :)
<RAOF> Damnit!  apport-collect is failing again :(
<bryceh> RAOF, error?
<RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/537745/comments/5 seems to be one, and another apport-collect just set the tag without attaching anything.
<ubottu> Ubuntu bug 537745 in xserver-xorg-video-nouveau "nouveau can't set screen resolution lucid 2.6.32-16" [Medium,Incomplete]
<bryceh> oh that nutty precondition failed thingee again
<RAOF> I think the backtrace in that comment means that it's a launchpad problem, not an apport one, right?
<Sarvatt> oh hmm, i didn't think 915-945 ever had lvds downclocking support which would make the first hunk in drivers/gpu/drm/i915/intel_display.c useless but looks like it can
#ubuntu-x 2010-03-19
<bryceh> rickspencer3, which is the best day of the week for me to send my Intel upstream bugs report to Intel?  Monday?
<KB1JWQ> What's the kernel option to force VESA from within grub?
<RAOF> Sarvatt's been working to make xforcevesa do that again.  But depending on your card, there are other ways.
<KB1JWQ> Hmm.
<KB1JWQ> nomodeset maybe?
<KB1JWQ> THis is an nvidia card that needs a vesa driver for at least another two days.  
<KB1JWQ> The beta freeze being lifted will likely change this, but...
<KB1JWQ> (bleeding edge hardware)
<RAOF> Yeah.  Nomodeset will disable nouveau, because the X component doesn't work without kms.
<RAOF> You'll fall back on either nv or vesa, depending on which one works.
<KB1JWQ> Nope, same black screen issue. 
<RAOF> What card is it that doesn't work with nouveau, by the way?
<KB1JWQ> startx from single user mode works with vesa declared in xorg.conf, but no mouse or keyboard.
<KB1JWQ> nvs3100m
<RAOF> You can get to single user mode, though?  What sort of resolution is your terminal there?
<KB1JWQ> Garbage, unfortunately.
<KB1JWQ> But I have to throw a special option to get there.
<KB1JWQ> text or single doesn't work.
<KB1JWQ> init=/bin/bash is all that does. :-/
<RAOF> Probably nomodeset would work as well.  You could also try passing nouveau.noaccel=1, which would disable everything but modesetting, which is more likely to work.
<Sarvatt> blacklist=driver will use vesa
<Sarvatt> or it should :D
<Sarvatt> like blacklist=nouveau
<bjsnider> RAOF, that's a brand new quadro chip he's got
<bjsnider> only supported by the 195 blob
<RAOF> bjsnider: Only supported *with acceleration* by the 195 blob; modesetting changes a lot less than accel.
<bjsnider> yes but i figured that's why nouveau doesn't support it
<KB1JWQ> RAOF: Yeah, nomodeset fails
<RAOF> I don't suppose it's possible for you to grab a dmesg when it's failing? :)
<KB1JWQ> So pass it blacklist=noveau?
<KB1JWQ> I don't *think* so.
<RAOF> IE: got a second machine you can ssh into it with? :)
<KB1JWQ> Actually yes.
<RAOF> Oh, well then.  Unless it's actually locking the box, you can grab all the logs we could possibly want :P
<RAOF> And just for added bonus debug: you're using the 2.6.32-16 kernel, right?  Previous kernel versions had all sorts of vga16fb-related nouveau problems.
<KB1JWQ> Let me verify.
<KB1JWQ> Can't start the ssh server because it's unable to connect to Upstart
<KB1JWQ> Got it working.
<KB1JWQ> (It's the X stuff that kills me, I know my CLI fairly well)
<KB1JWQ> Ah heck, because it's ONLY got a shell, all I can hit is PTY allocation request failed on channel 0
<KB1JWQ> during ssh.
<KB1JWQ> *ponder*
<KB1JWQ> Let me reboot, see if I can ssh into it and grab the x log that dies.
<RAOF> That'd be what we're after :)
<KB1JWQ> Holy crap I'm in.
<RAOF> We'd also want dmesg, because modesetting is now a kernel affair.
<KB1JWQ> Full Have the whole thing, installing pastebinit
<KB1JWQ> http://pastebin.com/tEvhp2Dn
<KB1JWQ> http://pastebin.com/esBhQR7L
<KB1JWQ> Yeah, looks like 2.6.32-14-generic
<KB1JWQ> The following packages have been kept back:
<KB1JWQ> Forgive my lack of debian knowledge, why would it do that? :-)
<RAOF> Because you need to pass dist-upgrade (to apt-get) or full-upgrade (to aptitude) for it to install new packages during the upgrade?
<KB1JWQ> dis-tupgrade
<KB1JWQ> Yeah.
<KB1JWQ> Thanks. :-)
<KB1JWQ> Sorry, googling as fast as I can.
<RAOF> It looks like you might also want to remove your xorg.conf
<KB1JWQ> RAOF: Completely?
<RAOF> Yup.
<KB1JWQ> Along with xorg.conf.failsave?
<RAOF> That can happily stay.
<KB1JWQ> k
<KB1JWQ> Update complete, rebooting.
<KB1JWQ> Hey, at least it reboots when told to.
<KB1JWQ> Holy crap.
<KB1JWQ> It boots now.
<KB1JWQ> Sound works.
<KB1JWQ> Video works.
<KB1JWQ> Mouse and keyboard work.
<KB1JWQ> Wireless doesn't, but that's expected.
<KB1JWQ> (Intel is releasing new firmware shortly that rectifies this)
<KB1JWQ> RAOF: Okay, I'll bite.  Why did I want to get rid of my xorg.conf?
<RAOF> Because it looked like it was confusing X, and for anything but the binary drivers it's unnecessary; X autodetects the correct drivers.
<KB1JWQ> They have a restricted driver update for nvidia.
<KB1JWQ> Is that going to hose me, or should I install it?
<RAOF> I don't know.  I think that if hardware drivers offers it then that means the nvidia-glx drivers claim to support your card.
<KB1JWQ> How hard is it to roll this back if it blows up again?
<rickspencer3> bryceh, Monday is good, yes
<RAOF> Not terribly hard; the worst case is that you run jockey-text in ssh to remove the nvidia drivers.
<KB1JWQ> Restarting, let's see if it works.
<KB1JWQ> Worked.
<KB1JWQ> And COmpiz works too.
<KB1JWQ> RAOF: I owe you a beer.
 * RAOF will be at UDS :)
<KB1JWQ> UDS?
<RAOF> Eh, it's all other people's work there.
<RAOF> Incidentally, before you installed the nvidia drivers, did you get the ubuntu splash screen?  Did kms work?
<KB1JWQ> Okay, I should probably clarify my position a bit.  I'm a RedHat admin, never used Ubuntu before.  Making the switch on the desktop away from MacOS.
<KB1JWQ> RAOF: No to both.  After, yes.
<bryceh> UDS == Ubuntu Developer's Summit
<RAOF> Ok.  You'll have got keybuk's awesome VGA text-mode splash screen then.
<BUGabundo> !uds
<ubottu> The Ubuntu Developer Summit is being held from May 10th - 14th in Brussels, Belgium - See https://wiki.ubuntu.com/UDS for more information.
<KB1JWQ> I live in Los Angeles.  LONG way to go for a beer. :-)
<KB1JWQ> RAOF: Tell me where to go, I'll do it.
<KB1JWQ> The splash screen, not the summit.
<RAOF> It's near Brussels, but it's probably not interesting for you unless you've got a burning desire to help shape the next release of Ubuntu :)
<KB1JWQ> Hmm, plymouthd crashed apparently.
<KB1JWQ> And there's already a bug report open.
<KB1JWQ> Slick
<RAOF> Apport is 32 separate shades of awesome.
<KB1JWQ> Yeah, this is insanely slick.
<KB1JWQ> Y'know, once you get a GUI working and all.
<RAOF> Also, the launchpad-ubuntu-package-bugs opensearch plugin + Do's opensearch plugin is love.
<KB1JWQ> Plugin for what exactly?
<KB1JWQ> Firefox, or Ubuntu?
<RAOF> The opensearch plugin is for firefox (or anything else which understands opensearch, I guess).
<KB1JWQ> This is the fastest system I've ever used.
<KB1JWQ> I think I'm in love. ;-)
<KB1JWQ> But the purple has got to go...
 * RAOF really likes the purple.
<RAOF> Well, aubergine :)
<KB1JWQ> Yeah, but I"m used to a BLACK terminal window.
<KB1JWQ> THis is a little too much of a pimping good time for my tastes.
<KB1JWQ> There we go, black terminal. :-)
<bjsnider> KB1JWQ, here's a really unfair question. why use ubuntu when you can use fedora? i mean if you're a redhat admin
<KB1JWQ> bjsnider: That's a very fair question.
<KB1JWQ> bjsnider: It comes down to maintainability.  Fedora has this obnoxious habit of breaking things mid-cycle.
<KB1JWQ> I've been meaning to learn debianisms anyway, and the hardware support seems to hit Ubuntu a little faster.
<KB1JWQ> The forced upgrade death-march of an 18 month lifecycle with no deviation means that I'd be perpetually chasing something I can't maintain.
<KB1JWQ> Not saying I'll never use it on this box, but as of today, Ubuntu seems to be the best option.  
<KB1JWQ> bjsnider: The community's another huge plus.  People like you and RAOF just helped me get something set up that I'd have spent days working on.  
<bjsnider> but aren't you far more knowledgeable on fedora? you could even use centos i suppose, although that rig's hardware might be too new for its kernel
<KB1JWQ> bjsnider: By that theory I'd have stuck with FreeBSD. :-)
<KB1JWQ> And most of what I do day in and day out is application specific.  Postfix is postfix, for instance, no matter what it runs on.
<bjsnider> that isn't what the apache guys told me
<bjsnider> but they're ornery
<bryceh> KB1JWQ, well, we're glad to have ya :-)
<bjsnider> not that i'm arguing that ubuntu is the superior choice for a home system. that's very obvious
<Sarvatt> apw: i'm actually going to give this a shot to see if thats all thats needed in my case - http://sarvatt.com/downloads/patches/0001-drm-i915-Disable-FBC-on-915GM-and-945GM.patch
<KB1JWQ> bjsnider: Precisely.  It's a desktop box, and coming from Mac OS, I'd prefer something that's widely supported.
<KB1JWQ> Ubuntu serves as a reference platform for a lot of things.
<KB1JWQ> As to the Apache folks, I had dinner last night with one of their infrastructure guys.  He raises "whining" to an art form. :-D
<bjsnider> KB1JWQ, that rig cost as much as a crackbook pro, so why get that instead?
<KB1JWQ> bjsnider: Because the one I have has a spilled drink into keyboard.
<KB1JWQ> There's no accidental damage applicable to it, so the hell with it.
<KB1JWQ> As shipped from lenovo it was $1400 or so.
<Sarvatt> xorg-edgers member list is starting to look like a canonical party list :D
<ricotz> RAOF, hello, is there progress investigating the mesa-nouveau-compiz problem?
<tseliot> ricotz: what problem? Nouveau doesn't work with compiz, at least AFAIK
<ricotz> tseliot, it is working with enabled 3d support, but the changes in mesa caused it to break
<tseliot> ricotz: ah, the experimental 3d support
<ricotz> tseliot, yes, it is working with mesa of 2010-03-13
<tseliot> nice
<apw> Sarvatt, about?
<shadeslayer> hi the synaptic touchpad driver in lucid is pretty borked,this was a known issue in jaunty and was fixed in karmic,but seems to have reappeared in lucid
<shadeslayer> also theres no horizontal scrolling support
<RAOF> ricotz: I haven't invested any effort in it; nouveau's 3d sometimes works & sometimes doesn't.
<RAOF> This is why it's in xorg-edgers and not the main archives.
<ricotz> RAOF, i know -- btw when i use lbm from edgers the used module should be lbm_nouveau?
<RAOF> Yup
<ricotz> RAOF, can i help solving this problem somehow? i tried to get a trace which leads to "st_texture.h:128" with compiz and "nv40_fragtex.c:113" with mutter
<ricotz> in mesa source
<ricotz> with mesa git c9c0baabdc653f162f9ce51cb17775aed1a707f7
<RAOF> ricotz: You'd want to talk to #nouveau about that.
<RAOF> Have a look at those files, and see if there's anything obvious?
<ricotz> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_texture.h?id=c9c0baabdc653f162f9ce51cb17775aed1a707f7#n128
<ricotz> RAOF, ^, g2g
<shadeslayer> yeah so like i was saying : xserver-xorg-input-synaptics : seems pretty borked right now with soft lockups with the synaptic touchpad
<shadeslayer> im repoting a bug against it right now,and if you would like additional details please let me know
<shadeslayer> ok the bug is : https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/541868
<ubottu> Ubuntu bug 541868 in xserver-xorg-input-synaptics "Synaptic touchpad has soft lockups in lucid" [Undecided,New]
<shadeslayer> hope that helps,please ask if any more info is required
 * hyperair wonders if anyone is getting graphical artifacts with 2.6.34-rc1
<KB1JWQ> hyperair: Custom kernel I presume?
<hyperair> KB1JWQ: yes.
<hyperair> + xorg-edgers
<hyperair> i965 card
<apw> Sarvatt, i've slurped up that patch you suggested (slightly modified) and my patch and produced a pair of test kernels for them ... just sent out an email to kernel and X asking for feedback on both
<Sarvatt> apw: nice, thank you
<Sarvatt> i'm trying to reproduce the hangs with different drm debug levels
<Sarvatt> drm.debug=0x2 is useless at least, its taking an hour or two to trigger and 0x4 spams the log a few times every second
<Sarvatt> ah nice theres the i386 kernel, installing it now and will try to reproduce
<apw> Sarvatt, sweet
<Sarvatt> with drm.debug=0x02 the only thing I noticed was that it called [drm:intel_crtc_cursor_set], to turn the cursor back on after typing around the same time it hung, took 4 hours to make it hang that time on -16 with powersave=1.. may be awhile until I can really say this fbc-broken kernel is fully working
<Sarvatt> been on it post resume about 30 minutes now though
<Sarvatt> hyperair: what kind of artifacts? are you on lucid yet?
<Sarvatt> the only artifacts I get aren't edgers related and I'm on 945, they happen when I'm doing stuff in gnome-terminal and it kind of corrupts/blacks out the screen until i move the mouse back up to the panel
<hyperair> Sarvatt: when images are loading in firefox, scrolling makes weird horizontal lines appear in the image, kind of like the edge of the status bar got rendered onto the image.
<hyperair> Sarvatt: and occasionally, notify-osd appears with graphic corruption
<hyperair> Sarvatt: mostly the volume up/down one
<hyperair> Sarvatt: hovering over it and dehovering restores notify-osd's popups
<hyperair> Sarvatt: then banshee's cover art gets graphical corruption..
<Sarvatt> hyperair: lucid?
<hyperair> Sarvatt: karmic
<Sarvatt> what kind of graphic corruption on notify osd?
<tjaalton> no-one cares about karmic anymore :)
<hyperair> tjaalton: heh. sorry, but i still kinda need this machine to work. i don't have enough time to spend fixing issues yet
<Sarvatt> oh hyperair I'm sure its that old crappy mesa checkout in edgers for karmic :D
<hyperair> Sarvatt: ._. it might be..
<hyperair> Sarvatt: how do you describe what kind of graphic corruption?
<hyperair> Sarvatt: i mean it's got colours.
<hyperair> er
<hyperair> weird colours
<hyperair> and it is completely obscured
<hyperair> o hey my cursor's messed up from time to time too
<Sarvatt> background missing just around icons was the last one i saw
<hyperair> not quite it
<hyperair> my I cursor seems to be a little strange too
<hyperair> like i'm seeing double
<hyperair> with some random colours at the side
<hyperair> http://www.ubuntu-pics.de/bild/47853/screenshot_01_XQ8b5f.jpg
<hyperair> see thunderbird's icons?
<Sarvatt> darnit
<Sarvatt> i'm just upgrading to mesa 7.9 for karmic, sorry tormod if you read this :)
<cwillu_at_work> where would a user specific setting that breaks the touchpad be living?
<Sarvatt> describe breaks?
<cwillu_at_work> it works in gdm, and stops working in my normal user account, but works in a guest account
<cwillu_at_work> a plugged in mouse works fine in all accounts
<Sarvatt> hyperair: i'll upload a new mesa for karmic now, just going to bump it to 7.9 since it takes 5 minutes to do karmic by hand if I have lucid's and just replace debian/ vs an hour or so to do a whole new mesa and make sure its right
<hyperair> Sarvatt: cool. what should i restart then?
<hyperair> entire X?
<Sarvatt> you're using compiz right? is the corruption still there without it?
<Sarvatt> that's the first thing i'd check
<hyperair> hmm
<hyperair> lemme try..
<Sarvatt> mesa in edgers for karmic needs updating really bad though anyway even if thats not the problem :D
<Sarvatt> <965 is screwed in there right now unless people manually disable texture tiling support in driconf
<hyperair> ouch.
<hyperair> why?
<Sarvatt> was enabled by default and hitting assertions for a few weeks
<Sarvatt> just got fixed 2 days ago
<hyperair> Sarvatt: you're right. it's not happening in metacity.
<Sarvatt> doh, forgot to upload libdrm to karmic too yesterday even though I did it, go figure I uploaded mesa right before
<hyperair> er.
<Sarvatt> mesa will fail to build but i'll retry it
<hyperair> now that compiz has restarted itself, i suddenly can't reproduce it
 * hyperair grumbles
<Sarvatt> apw: 2 hours strong with no FBC post resume and powersave=1
<apw> Sarvatt, with the kernel with just your fbc disable patch ?
<Sarvatt> yeah
<Sarvatt> your fbc-broken -17 kernel
<apw> thats awsome, lets see what other people say
<apw> as that is a smaller cleaner fix
<Sarvatt> yeah it helps narrow down where the problem is too even if it does eventually hang since theres not much else done with powersave. you said you edited it some? can ya send me what you applied to this kernel so I can bring it up upstream?
<cwillu_at_work> ah, yet another gconf-schema-not-installed-for-whatever-reason problem;  gconf-schemas --register-all brought the touchpad back
<Sarvatt> hyperair: as soon as libdrm builds on i386 i'll retry those mesa's, they needed the libdrm update due to the annoying nouveau_class.h changes in libdrm..
<Sarvatt> btw mesa 7.7.1 is going to be released next friday
<tjaalton> and wacom was released today
<tjaalton> wacom 0.10.5
<Sarvatt> ricotz: ya should bring up your issue in #dri-devel or #nouveau, give them a log with the trace messages when you try to start compiz
<ricotz> Sarvatt, thanks, have to looked into it on your box?
<ricotz> i am getting different segfault positions with mutter and compiz
<ricotz> Sarvatt, i have used gdb, but i am not that familiar yet, i only get the positon not the whole trace
<Sarvatt> try installing at least libgl1-mesa-dri-dbg and libgl1-mesa-glx-dbg then gdb --args mutter --replace then run then bt full once it segfaults?
<ricotz> Sarvatt, ok, thanks
<ricotz> Sarvatt, http://paste.ubuntu.com/397910/
<ricotz> Sarvatt, and with compiz http://paste.ubuntu.com/397911/
 * Ng wonders how much pain will be involved in upgrading an 855GM laptop to lucid
<Sarvatt> <shining^> +Sarvatt: yeah the first one is what I just noticed and what I am investigating now
<Sarvatt> <shining^> +and second one looks different but is the sampler view code we suspect
<Sarvatt> ricotz: ^
<shadeslayer_> RAOF: did the apport-collect thing,hope that helps...
<Sarvatt> RAOF: yay tseliot has a nva3 that the nouveau guys have been looking for a dump of for months
<shadeslayer_> Sarvatt: any idea if 3D support will make it till the final release?
<Sarvatt> shadeslayer_: for what?
<Sarvatt> nouveau? guaranteed no if so
<shadeslayer_> of Lucid..
<shadeslayer_> yes nouveau
<Sarvatt> theres 3D support in lucid, i dont know what GPU you have
<Sarvatt> yeah there wont be 3D support
<Sarvatt> its *wildly* unstable
<shadeslayer_> hm.. and what about nvidia+plymouth?
<shadeslayer_> Sarvatt: for NV50 too?
<Sarvatt> it'll be ugly and low resolution as well as hardly any colors but it should work, there is no smooth transition from the splash to the desktop like there are with KMS drivers so its only displayed for about a second at the moment..
<shadeslayer_> yeah theres a bug against it
<Sarvatt> what for NV50 too? there wont be 3D support for anything nouveau until +1
<shadeslayer_> hmm... too bad :(
<shadeslayer_> i guess ill have to dump the splash then
<Sarvatt> and I dont know if I'd call it support, planning on having an experimental dri package people can install seperately if they want to break things and I doubt it'll be really stable in that timeframe
<shadeslayer_> Sarvatt: you mean : libdrm-nouveau1?
<Sarvatt> nah libgl1-mesa-dri-experimental or something
<shadeslayer_> whats that for?
<Sarvatt> its most likely not going to be stable enough to globally install with libgl1-mesa-dri
<shadeslayer_> what does it do tho?'
<shadeslayer_> Sarvatt: have a look https://bugs.launchpad.net/bugs/526892
<ubottu> Ubuntu bug 526892 in plymouth "No graphical splash on VGA16fb (e.g., nvidia binary drivers), plymouth uses text plugin ("Ubuntu 10.04" in text)" [Medium,In progress]
<shadeslayer_> how is it WIP?? :P
<Sarvatt> the graphics devices can load sooner, they used to
<shadeslayer_> hmmm
<Sarvatt> you'll see the splash longer if it has to fsck, or if you have to enter a password for an encrypted home directory, otherwise theres not really anything that can be done besides loading the devices earlier and it'll still only be there for a few seconds
<Sarvatt> would you rather the boot take longer so you can see it?
<shadeslayer_> lol no
<shadeslayer_> i would rather have the login screen bought up and then load the processes in the background till i enter my pass
<Sarvatt> thats exactly what happens
<shadeslayer_> nice
<Sarvatt> theres just no way to transition from the splash and leave it on the screen while the login screen is loading when KMS isn't used, especially with a binary driver we have no control over :D the only option I see would be to load plymouth on another VT initially when the drm renderer isnt used and not switch to the login screen's VT until it signals that its done loading maybe?
<Sarvatt> apw: pushed it upstream - http://lists.freedesktop.org/archives/intel-gfx/2010-March/006292.html
<apw> excellent ... i am off next week ... if you need anything smb should have the branches available with those one
<tseliot> Sarvatt: do we have a 3d enabled nouveau (with mesa I assume) in some ppa?
<Sarvatt> tseliot: yeah but upstream mesa nouveau is pretty busted right now - https://edge.launchpad.net/~xorg-edgers/+archive/ppa
<tseliot> Sarvatt: ok, I asked as, with that patch that they gave me, they told me that I can even try 3D :-)
<Sarvatt> sweet, can you pass along your patch? I can add it to linux-backports-modules-nouveau in xorg-edgers for you
<tseliot> Sarvatt: I'm still rebuilding my kernel to test it but here it is: http://0x04.net/~mwk/0001-drm-nv50-Add-NVA3-support-in-ctxprog-ctxvals-generat.patch
<Sarvatt> the kernel nouveau wont work for 3D though
<tseliot> oh, well, 2D acceleration should be enough for now
<Sarvatt> uploading a new lbm-nouveau with that patch added to xorg-edgers now, should be up within an hour
<tseliot> fantastic, thanks
<Sarvatt> *whoa* we got a fglrx now?
 * tseliot whistles
<BUGabundo> we do ?!?
<BUGabundo> really?
<BUGabundo> can you begin to imagine HOW MANY ppl we would make happy ?
<tseliot> :-)
 * BUGabundo blows calculator stack trying the math
<Sarvatt> i would be 100% happy with R600 -radeon, its not like the nvidia situation :D
<BUGabundo> talking about nvidia
<BUGabundo> what's going on with nouveau?
<BUGabundo> #+1 is filled with ppl complaning it fails to boot
<Sarvatt> i went back 20 pages of +1 backscroll and i only see one person with a nvidia xorg.conf trying to use nouveau
<BUGabundo> pages?
<bjsnider> there was a guy who said it resulted in a black screen and expressed a desire to use nv
<Sarvatt> thats all my bouncer forwards to me
<Sarvatt> 1000 lines not including joins/parts
<bjsnider> i think his hardware was too new or whatever
<BUGabundo> bjsnider: I read that one
<BUGabundo> humm
<BUGabundo> no, I think that was another one
<cwillu_at_work> Seq at 2:36?
<cwillu_at_work> and nasso_ at ten to 1
<BUGabundo> yep
<cwillu_at_work> and 3 or 4 more this morning
<tseliot> Sarvatt: what do I need to do to enable lbm nouveau? Shall I set an alias?
<Sarvatt> just activating the PPA and deactivating nvidia-current will work
<Sarvatt> i've got it blacklisting nouveau and vga16fb
<tseliot> Sarvatt: my system begs to differ ;)
<tseliot> aah
<Sarvatt> do you still have /etc/modprobe.d/nvidia-whatever?
<Sarvatt> maybe the udev and plymouth support things for lbm-nouveau were just backed out, eek
<tseliot> no nvidia-$flavour in modprobe.d here
<Sarvatt> lbm-nouveau loading in dmesg?
<tseliot> nope
<Sarvatt> wait, are you sure you didnt boot that 2.6.32-17 kernel?
<Sarvatt> lbm-nouveau is only for 2.6.32-16
<hyperair> yay corruption doesn't seem to happen any more =D
<hyperair> thanks Sarvatt!
<Sarvatt> no worries, sorry i forgot to hit rebuild :D
<tseliot> $ uname -r
<tseliot> 2.6.32-16-generic
<tseliot> this is with a blacklisted nouveau and vga16fb
<tseliot> :~$ dmesg | grep nouveau
<tseliot> [    9.505893] Error: Driver 'nouveau' is already registered, aborting...
<tseliot> :~$ cat /etc/modprobe.d/blacklist-alberto.conf
<tseliot> blacklist nouveau
<tseliot> blacklist vga16fb
<tseliot> and I updated the initramfs with sudo update-initramfs -u -k 2.6.32-16-generic
<tseliot> Sarvatt: I installed only linux-backports-modules-nouveau-2.6.32-16-generic
<Sarvatt> ok I have no clue whats wrong there, sounds like the lbm-nouveau support was dropped from plymouth though
<Sarvatt> anyone know where the ubuntu plymouth bzr branch is? i cant find the darn thing anywhere
<Sarvatt> lp:ubuntu/plymouth.. go figure
<Sarvatt> what the heck is going on with plymouth right now though, it gave me the fugly text logo on intel that boot
<Sarvatt> sorry, I shouldn't say fugly because its *much* better than the tricolor progress bar text had before, just wasn't expected since I got the real one this morning
<Sarvatt> my nvidia blob laptop suspends \o/ \o/
<Sarvatt> lbm-nouveau support is still in plymouth so its not that, udev rules still there too
<Sarvatt> oh wait, tseliot's problem was he only installed lbm-nouveau, no wonder :D
<BugsCrash> hi ,  Somebody help me about gma 500 on ubuntu 10.0.4 (acer 751/h) please (driver)
<Sarvatt> there is none as far as I know
<Sarvatt> besides vesa which it should use automatically
#ubuntu-x 2010-03-20
<Sarvatt> wow, really didn't notice how much louder this laptop was being with 195.36.08 until I just upgraded to .15 and its been silent for a few hours
<CosmiChaos> http://launchpadlibrarian.net/41345183/Lspci.txt
<CosmiChaos> xD oops
<CosmiChaos> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/541749
<ubottu> Ubuntu bug 541749 in nvidia-graphics-drivers "PCIExpress 1.0 16x Port (nforce 630i) and 16x-Card 8600 GTS only synced at bus-type 4x" [Low,Incomplete]
<CosmiChaos> can somebody help me on that
<Sarvatt> I'm sorry, I can only help so fast :)
<Sarvatt> have been going over your logs and looking through the kernel source to see if your machine is quirked for 4x for some reason
<Sarvatt> (i'm the one that asked for the logs)
<Sarvatt> annoying how xfx makes you register to view manuals or bios update info
<Sarvatt> its not like you'll *ever* notice any difference between 4x and 16x though, it just got me curious
<Sarvatt> the onboard most certainly does not use 1x though, just noticed your comment
<Sarvatt> err someone else's comment..
<CosmiChaos> how ever 18lanes seems a bit low espeacially if nic/igp/hdaudio/ide-busmaster seem to chunk some
<CosmiChaos> im notis there a way to find out what is exactly leeching pci lanes
<CosmiChaos> Looks like XFX cheated on my if they claimed this board has all the features + a true 16x pci express 1.0a port
<CosmiChaos> what do you want from registered zone, manuals, driver, bios? product specs is public...
<CosmiChaos> i see no info how many lanes the controller has
<CosmiChaos> may it be an issue that the fanspeed is by default 53%?
<Sarvatt> ok just tried out the beta 1 livecd and I gotta say it looks slick :) the themes actually look better with different fonts, mine are kind of screwed up. I dont see how nvidia can be made less ugly booting because the blob ddx actually completely powers down the display and turns it back on before X starts..
<Sarvatt> its a shame because nouveau makes it look so pretty
<Sarvatt> it actually looks better booting off the livecd than installed, plymouth loads right away
<Sarvatt> instead of 90% of the boot process being in vgacon..
<bjsnider> Sarvatt, but if lucid boots in only a few seconds who cares if the boot screen is pretty
<bjsnider> i'll trade that for a working, full-featured graphics driver any day
<Sarvatt> anyone around that can fix up fglrx-installer? https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/494699/comments/15
<ubottu> Ubuntu bug 494699 in fglrx-installer "Does not support current Lucid kernel (2.6.32) or xserver (1.7)" [Critical,Fix released]
<Sarvatt> hmm i see it in the 32 bit 0ubuntu1 package at least - -rw-r--r-- root/root        15 2010-03-19 20:34 ./usr/lib/fglrx/ld.so.conf
<Sarvatt> missing from amd64
<RAOF> You know what's good?  Triple brie.
<tjaalton> wow, suddenly we are below 2900 bugs
<Duke`> how many before?
<tjaalton> 3000+
<Duke`> for video drivers only?
<tjaalton> no, all the packages x-swat is a bug contact of
<tjaalton> https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs
<shadeslayer> hi anyone here using a synaptic touchpad?
<shadeslayer> this is a pretty nasty xorg-synaptics issue
<tjaalton> file a bug
<shadeslayer> tjaalton: did that
<shadeslayer> tjaalton: as more and more users are upgrading their touchpads have been rendered useless or worse keep jumping around
<tjaalton> the driver didn't change
<shadeslayer> tjaalton: and idk whether this is a issue with hal or xorg,since with the nouveau driver i had loads of problems,and with the nvidia driver the touchpad works a tad bit better
<shadeslayer> tjaalton: https://bugs.launchpad.net/bugs/541868
<ubottu> Ubuntu bug 541868 in xserver-xorg-input-synaptics "Synaptic touchpad has soft lockups in lucid" [Undecided,New]
<shadeslayer> tjaalton: hdpb has the same issue only a bit worse...
<shadeslayer> hdpb: oh and please comment on https://bugs.launchpad.net/bugs/541868 if you havent already..
<ubottu> Ubuntu bug 541868 in xserver-xorg-input-synaptics "Synaptic touchpad has soft lockups in lucid" [Undecided,New]
<hdpb> i have no response at all.  I have tried changing settings in System>Prefs>Mouse>trackpad and get no response
<shadeslayer> hmmm weird thing... my touchpad comes up as Alps with xinput list
<hdpb> shadeslayer: did last night
<hdpb> mine shows as synaptics in xinput...
<tjaalton> "same issue"...
<tjaalton> it's not the same bug then
<tjaalton> hdpb: file a new one
<shadeslayer> tjaalton: like i said its worse on his
<shadeslayer> tjaalton: btw is alps and synaptic the same thing?
<tjaalton> same driver
<shadeslayer> hmm ok
<tjaalton> hdpb: you said it worked before beta?
<shadeslayer> tjaalton: oh and double tap seems to be disabled...
<hdpb> tjaalton: yes.  the last update i did was on 3/16 or 17.
<tjaalton> hdpb: well the driver hasn't changed in a long time
<tjaalton> so it's something else then
<shadeslayer> tjaalton: hal?
<tjaalton> no
<tjaalton> hal isn't used
<shadeslayer> tjaalton: hmmm
<shadeslayer> tjaalton: it certainly isnt KDE/gnome since hdpb is on gnome and im on kde and both of us have the issue
<tjaalton> it's. not. the. same. issue
<tjaalton> hdpb's device isn't working at all
<shadeslayer> ok sorry
<hdpb> i'd update and see if it works since i've only tried live-usb, but i don't want to be stuck with no touchpad...
<hdpb> confuses me more that it is essentially a fresh install running live-usb, so it shouldn't be a conflict w something I installed, right?
<tjaalton> no idea
<shadeslayer> hdpb: try this,zsync to the latest iso and burn it to the usb
<tjaalton> beta is new enough
<tjaalton> dailies don't necessarily work
<tjaalton> hdpb: file a bug from the live environment
<tjaalton> it should collect all the logs
<hdpb> i'm fairly noob, can you walk me thru it?
<tjaalton> run 'ubuntu-bug xorg' on a terminal
<shadeslayer> hdpb: oh just do ubuntu-bug xserver-xorg-input-synaptics
<tjaalton> simple as that
<tjaalton> or that
<hdpb> ok.  told shadeslayer on U+1 i'm fairly new, but learn by doing, so i jumped in
<hdpb> will need to jump off to do it... for obvious reasons, i'm not in it now
<hdpb> see you soon!  thanks for the help!
<hdpb> taa
<hdpb> tjaalton: usb isn't leaving me enough space to do the bug report automatically...
<tjaalton> hdpb: too bad
<hdpb> is it possible to change the location apport saves it to so i can send it from the hd, not usb? in apport-cli?
<tjaalton> dunno
<tjaalton> actually yes, --save
<CosmiChaos> hello does anyone has anmore ideas or thoughts upon: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/541749
<ubottu> Ubuntu bug 541749 in nvidia-graphics-drivers "PCIExpress 1.0 16x Port (nforce 630i) and 16x-Card 8600 GTS only synced at bus-type 4x" [Low,Incomplete]
#ubuntu-x 2010-03-21
<bjsnider> nvidia has now promoted 195.36.15 from pre to official
<LLStarks> what's all this talk about ati open drivers now suddenly becoming good?
 * abhinav is away: Abhinav|away
 * abhinav is away: breakfast
<knittl> weeeeeeee, working standby <3
<abhinav> hi. would this be a good place to get help regarding lucid (10.04) issues ?
<BUGabundo> abhinav: unless specific X problems, no
<BUGabundo> you should try #ubuntu+1 
<abhinav> BUGabundo: k, thanks
<abhinav> What does the ubuntu-x-swat ppa provide that the non-ppa repos don't ? (in context of ATI radeon drivers)
<tjaalton> nothing
<tjaalton> there are no ati packages
<abhinav> tjaalton: so I can comment it out ? I had it active during karmic, and it got disabled on update to lucid.
<tjaalton> yes
<abhinav> tjaalton: ok, I see the following on the wiki/ppa page https://launchpad.net/ubuntu/lucid/+source/xserver-xorg-video-ati
<tjaalton> that's from the main repo
<abhinav> tjaalton: ok, thanks :) 
<BUGabundo> how is nvidia CUDA support in lucid?
<tjaalton> BUGabundo: included in nvidia-current
<BUGabundo> cool
<tjaalton> though only the driver portion of it
<tjaalton> the sdk isn't packaged
<tjaalton> nor is the toolkit
<Sarvatt> xf86Msg(X_WARNING, "PreInit returned NULL for \"%s\". This is usually harmless.\n", idev->identifier); ? :D
<Sarvatt> vs  xf86Msg(X_ERROR, "PreInit returned NULL for \"%s\"\n", idev->identifier);
<Sarvatt> oh boy, it'd be nice to have something similar to ppa-purge in the release upgrade process, it just disables the PPA but if that still has newer than whats in lucid it sticks around
<Sarvatt> ok I have some issues with this - http://testcases.qa.ubuntu.com/Hardware/X/ProprietaryDrivers#Upgrade%20From%20Manual%20Install%20Testing
<Sarvatt> that is *never* going to succeed
<Sarvatt> the drivers from nvidia.com require manual reinstallation every kernel abi update
<Sarvatt> I'm really confused about https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/522328 and that test case on the wiki because it should never succeed as its written
<ubottu> Ubuntu bug 522328 in nvidia-graphics-drivers "[Test xpr-008] Lucid upgrade broke when upgrading from manually installed nvidia proprietary drivers" [High,Triaged]
<Sarvatt> bryceh: what do you think about the PreInit error string change I posted above?
<bryceh> heya
<Sarvatt> heyo!
 * bryceh looks
<bryceh> hmm, well we could redo the test I guess (or mark it known-fail)
<jcristau> Sarvatt: is that still necessary after we stop setting the driver to evdev for non-event devices?
<bryceh> the basic thing it's trying to test is that if a user manually installs fglrx, then upgrades, the system is not going to end up upbootable
<tjaalton> jcristau: where is it handled? the evdev rule?
<Sarvatt> failsafeX should be the intended outcome and by all accounts it seems thats working correctly for ubuntu at least, I'm not sure about non-gdm though
<Sarvatt> jcristau: hmm good point, will check that since we're already not setting evdev for non event devices in lucid
<tjaalton> right, not seeing those errors anymore
<tjaalton> so it's done :)
<jcristau> Sarvatt: yeah i think i have that in git but not uploaded in sid
<tjaalton> it is
<Sarvatt> btw jcristau did you see that we missed setting evdev by default for ID_INPUT_TABLET?
<jcristau> Sarvatt: ah?
<bjsnider> Sarvatt, you mean xpr-008 on this page: http://testcases.qa.ubuntu.com/Hardware/X/ProprietaryDrivers#Upgrade%20From%20Manual%20Install%20Testing
 * jcristau needs to run, can you fix it in git or file a bug?
<bjsnider> would never succeed?
<Sarvatt> i wasn't sure if you wanted that change in debian too but it seemed like an oversight, touchscreens that identify as tablet's (like resistive tablet overlays) that work right with evdev werent loading evdev
<Sarvatt> sure jcristau 
<tjaalton> doing
<tjaalton> *fixing
<tjaalton> pushed
<Sarvatt> wacom needs locking down a bit to not load for every ID_INPUT_TABLET as well
<tjaalton> yes
<Sarvatt> https://bugs.launchpad.net/bugs/537801
<ubottu> Ubuntu bug 537801 in xf86-input-wacom "Touchscreen doesn't work after karmic->lucid upgrade" [Medium,Confirmed]
<tjaalton> I'll inform ron about it
<Sarvatt> gotta run too, doh
<tjaalton> heh, a colleague is pissed because his old laptop doesn't work with a newer X anymore (ISA bus in it) :)
<bryceh> tjaalton, heh
<bryceh> tjaalton, friday a bunch of us got together downtown, including kees and MostAwesomeGuy (Corbin)
<bryceh> kees had an old laptop with an ati card which didn't work right with KMS
<bryceh> so he spent the whole day with corbin banging his head on the bug
<bryceh> by the end of the day I go, "You know... you could get a new laptop for just $500..."
<tjaalton> bryceh: hehe :)
<bjsnider> nvidia-settings control file in lucid still says "amd64 i386 lpia"
<tjaalton> bryceh: had a quick chat with ron about wacom. I'll prepare the new version and he'll pull it (with our changes) on top of his tree and releases it sometime next week
<bryceh> tjaalton, excellent
<bryceh> bjsnider, feel free to post a bug report about that.  tseliot may take a look.  extra points for including a debdiff :-)
<bjsnider> i doubt i can include such a thing, since i have no idea what it is
<bjsnider> he has to release the new version anyway, so it's no big deal to change the control file to read "any" instead
<Sarvatt> jcristau: you're right, we dont need to shut up the PreInit returns NULL messages now that evdev only handles event devices, I thought we would since stuff like lid switch event devices gave the error but I guess they don't anymore :)
<Sarvatt> hmm xorg-server 1.7.6 failing to build, looks like that cursor patch ya threw in recently bryceh - http://launchpadlibrarian.net/41532730/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.6~git20100321%2Bserver-1.7-branch.c552ec12-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> are you sure thats still relevant?
<jcristau> what patch?
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/110_fix-swcursor-crash.patch;h=ec2db45ab460c78305fdd2445b703654023f3f24;hb=dcd61b292cdcf379b911a7112425d59ad5a79ef7
<Sarvatt> that was reported against hardy or intrepid, dont think its relevant anymore
<Sarvatt>   * Add 109_fix-swcursor-crash.patch: Avoid dereferencing null pointer
<Sarvatt>     while reloading cursors during resume.
<Sarvatt>     (LP: #371405)
<bryceh> 109_fix-swcursor-crash.patch is the corrected patch
<Sarvatt> <Sarvatt> ah bryceh, ya commited the bad patch to git, it should be if (!cursor_screen_priv || !cursor_screen_priv->isUp)
<Sarvatt> fixed it up in git
<Sarvatt> 109 was still wrong in git, was the same as 110
<bryceh> I fixed it before uploading it
<Sarvatt> i dont think its still relevant on 1.7 branch though, looks like its already accounted for going by http://cgit.freedesktop.org/xorg/xserver/log/hw/xfree86/modes/xf86Cursors.c?h=server-1.7-branch
<Sarvatt> dunno why it was messed up in git still then, no biggie though
<Sarvatt> oops you got it too
<Sarvatt> sorry about that
<tjaalton> and now after all this, drop the patch?-)
<bryceh> tjaalton, for the -ati version, apt-cache madison produces the following:
<bryceh> http://pastebin.com/vKKmqJXc
<bryceh> problem is that it's seeing two results for experimental and unstable
<bryceh> These lines are being mixed up:
<bryceh> xserver-xorg-video-ati | 1:6.12.6-1 | http://ftp.debian.org/debian/ unstable/main Sources
<bryceh> xserver-xorg-video-ati | 1:6.9.0-1+lenny4 | http://ftp.debian.org/debian/ unstable/main Sources
<bryceh> These are as well:
<bryceh> xserver-xorg-video-ati | 1:6.12.192-1 | http://ftp.debian.org/debian/ experimental/main Sources
<bryceh> xserver-xorg-video-ati | 1:6.12.99+git20100201.a887818f-1 | http://ftp.debian.org/debian/ experimental/main Sources
<bryceh> it's not clear to me how to have it select between these
<bryceh> prefer first one seen?
<jcristau> largest version
<tjaalton> yep
<tjaalton> some archs are falling back, that's why there are several versions listed
<tjaalton> http://packages.debian.org/search?keywords=xserver-xorg-video-ati
<tjaalton> bryceh: btw, the list was last updated on 18th
<Sarvatt> oh looks like that cursor patch IS still relevant on 1.7 branch (and master) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507916
<ubottu> Debian bug 507916 in xserver-xorg-video-intel "xorg: Xorg segfault on swsusp resume" [Important,Open]
<Sarvatt> i'm going to add http://sarvatt.com/downloads/patches/0001-dix-be-more-verbose-when-we-run-out-of-opcodes.patch to edgers too, it's got me curious
<Consul_Falx> hello folks
<Consul_Falx> am using 64bit Kubuntu Lucid beta1 on a centrino1duo laptop with ATI radeon mobility X1450 shit ...
<Consul_Falx> actually, all things work fine, but the graphics from the very beginning is slightly but visibly distracted
<Consul_Falx> any advice how to configure that?
<Consul_Falx> (the system is on defaults, XOrg 7.5, using radeon open driver)
<bryceh> tjaalton, manually updated for now
<tjaalton> bryceh: okie
<Sarvatt> i dont think anyone but you knows what you mean by distracted there Consul_Falx :D what do you mean?
<Consul_Falx> Sarvatt: flickery, snowy or like that ...
<Sarvatt> like while the ubuntu logo splash screen is on the screen?
<Sarvatt> and goes away when the KDE loading screen comes up?
<Sarvatt> it changes the display 3 times during boot and looks pretty fugly now especially if you boot fast and use KDE where you dont get the smooth plymouth-X transition, i dont know what you mean by flickery or snowy though
<Sarvatt> VGACON comes up with the fsck messages, then console-setup changes the fonts on vgacon, then drmfb loads and some text goes on there sometimes before the splash is displayed on that
<Consul_Falx> Sarvatt: it started upon the first splash used during the install process, now it flickers all time, even if a tty without xserver running is open ...
<Sarvatt> and thats only up for a second or so unless you have to enter a password or wait for a fsck if you dont use GDM
<Sarvatt> ok, run ubuntu-bug xserver-xorg-video-ati and put [RV515] in the title if you don't mind
<Sarvatt> we need a bunch of logs and that'll add them to a bug report automatically
<bryceh> attach photos to the bug to show what's going on
<Consul_Falx> and, btw, the fsck occurs too and fails
<bryceh> Consul_Falx, actually if you can reproduce it on regular ubuntu, not kubuntu, that would help too
<Sarvatt> are you using multiple monitors?
<Consul_Falx> bryceh: I suppose the flickering will not show in screenshots
<Consul_Falx> no, I have only one set up by default during the installation
<Consul_Falx> and I cannot afford installing another clean ubuntu distro, bryceh
<tjaalton> just install ubuntu-desktop
<tjaalton> it'll pull gnome
<Consul_Falx> vu@ethereal-laptop:~$ ubuntu-bug xserver-xorg-video-ati
<Consul_Falx> kfmclient(2094)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from  "/var/tmp/kdecache-vu/ksycoca4"
<Consul_Falx> Launched ok, pid = 2098
<Consul_Falx> : Fatal IO error: client killed
<tjaalton> kde fail
<bryceh> Consul_Falx, well, understand my focus is ubuntu so bugs against other distros are not a priority for me to look at
<Consul_Falx> bryceh: well, I do definitely understand... I will get down to playing with this later since there's no obvious simple solution to this and I have things to do -.-
<Consul_Falx> so long, people
<kklimonda> may problems with user switching be related to nouveau or should I search higher in the stack? When I login to the guest session everything is fine but when I get back I have dark screen with mouse cursor and I can't switch to ther VTs (or rather I have no login prompt on them)
<RAOF> Logs might make it easier to determine what's happening.
<Sarvatt> i guess mesa-common-dev should depend on libdrm-dev now? Requires.private: libdrm >= 2.4.15 in dri.pc installed there
<jcristau> the only user of afaik is the server, afaik
<jcristau> bah
<jcristau> the only user of dri.pc is the server, afaik
#ubuntu-x 2011-03-14
<RAOF> WIN!  I can now corrupt the function parameters on IA32 rather just calling off into random memory!
<tjaalton> RAOF_: fixing the TLS bug?
<RAOF> tjaalton: Yup.  I may be slightly insane, because I think I'm beginning to understand mesa dispatch.
<tjaalton> <g>
<RAOF> Although I'm *not* sure why I appear to be corrupting all the arguments on IA32.
<RAOF> On x86-64 it was because I wasn't saving enough registers, but (a) registers aren't *used* in passing arguments in IA32 and (b) I'm only clobbering %eax, which is safe to clobber, and (c) I'm not even really doing that.
<RAOF> Because, obviously, on IA32 mesa calculates the base address of the dispatch table at init time and writes that directly into the function definitions.
<tjaalton> glad I don't do assembler. at all :P
<tjaalton> some mips years ago
<RAOF> There's some sparc assembler here too.  That'll be broken also, but sucks to be on sparc.
<mvo> RAOF: ohhh, progress on the mesa issue? that is excellent! that will make my software-center users happy :)
<RAOF> Yeah, sorry about that.
<mvo> well, not really your fault, the joy of natty. I'm happy that you dived so deep into it for the fix
<mvo> sounds very painful to debug it
<RAOF> I get to learn all sorts of arcana about IA32 assembly, the System V ABI, the TLS ABIâ¦
<RAOF> And that x86-64 assembler is much nicer.
<RAOF> And now, as I stare at gdb disassembly, I realise that it's time to learn more about relocations and the PLTâ¦
<mvo> geeh, good luck
<jcristau> sparc asm isn't nearly as horrific as x86
<RAOF> More difficult for me to test, though.
<tseliot> RAOF: did you rebuild the X packages in the ubuntu-x-swat PPA bumping the video ABI number?
<lag> cnd: Good day
<lag> cnd: Did you receive my email with the non-empty device.* files?
<cnd> lag, yep, but it's a bit low in the queue :(
<cnd> I'm trying to get through a backlog
<cnd> and I have to get a root canal in a few hours too
<cnd> so...
<cnd> hopefully tomorrow?
<lag> Sure
<lag> Good luck with the root canal - rather you than me
<cnd> bryceh_, tjaalton: would one of you be able to upload an update to python-libavg? (bug 733247)
<ubot4`> Launchpad bug 733247 in libavg (Ubuntu) "Please upgrade to libavg v1.5.4 (affects: 1) (heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/733247
<cnd> I can prepare a source package if you need
<jcristau> i thought libavg was broken by mesa tls fun anyway?
<cnd> jcristau, I gave them a hacky patch :)
<cnd> it literally loads libstdc++ using python before doing any opengl stuff
<jcristau> ewww :)
<tjaalton> cnd: hey, I'm not at my ws atm, so can't sponsor it until maybe 2.5h from now
<cnd> tjaalton, I won't be around then
<cnd> maybe tomorrow
<tjaalton> cnd: put the package somewhere and I'll download it then
<cnd> tjaalton, ok, I'll get to that in a bit
<cnd> I have to leave now
<tjaalton> cnd: ok
<sweeze> with latest xserver-xorg-video-ati from xorg-edgers, ForceGallium=true in xorg.conf no longer works.  I've temporarily copied /usr/lib/dri/r600g_dri.so over r600_dri.so, but what's the "right" way to get the gallium driver from the packages to be used?
<sweeze> (braid w/ s3tc libtxc_dxtn.so hack seems to work w/ gallium, but not classic drivers)
<Sarvatt> sweeze: it's always used by default, /usr/lib/dri/r600_dri.so is the gallium one. if you have an r600g_dri.so its hanging around from an old build
<sweeze> Sarvatt: hmm... looks like not true in libgl1-mesa-dri package in ppa?  
<sweeze> `strings /usr/lib/dri/r600_dri.so |grep -i gallium` is empty
<sweeze> but on r600g_dri, gallium strings show up
<Prf_Jakob> Is there a ppa to get a kernel capable of KMS on radeon cayman cards?
<Sarvatt> hmm good question.. lets see
<Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/
<Prf_Jakob> ah cool
<Prf_Jakob> Whats the magic ppa name for that repo?
<bryceh_> it's not actually a true PPA
<Sarvatt> linux-firmware 1.48+ from natty has the firmware if you aren't on natty
<Sarvatt> yeah have to install it manually
<Prf_Jakob> ah
<Prf_Jakob> Yeah maverick
<Sarvatt> https://launchpad.net/ubuntu/+source/linux-firmware/1.48/+buildjob/2297992
<Sarvatt> can grab the firmware deb there
<Prf_Jakob> Thanks!
<Sarvatt> there's no accel or anything yet though
<Prf_Jakob> I just want a native resolution on my 30" :-/
<Prf_Jakob> Hmm I guess I need some xf86-video-ati bits to go with that as well.
<Prf_Jakob> Hmm that kernel just made my screen go black and the network didn't work :-/
<Sarvatt> sudo apt-get build-dep xserver-xorg-video-ati && dget -u -x https://launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-ati_6.14.99%2Bgit20110307.6319a33c-0ubuntu0sarvatt~maverick.dsc && cd xserver-xorg-video-ati-6.14.99+git20110307.6319a33c && fakeroot debian/rules binary
<Prf_Jakob> Sarvatt: awesome!
<RAOF> bryceh_, tjaalton, Sarvatt: What do you think of uploading a temporary fix for the mesa tls annoyance?  I've got it for platforms without asm optimisations and for x86-64 asm.  IA32 is still kicking my arse, and I don't care about sparc.
<RAOF> We could upload a mesa with assembly disabled on i386, which would work.
<bryceh_> RAOF, sure
<bryceh_> RAOF, in fact we should probably start pushing buttons on the xserver update, what do you think?
<RAOF> Probably, yeah.
<tjaalton> RAOF: i guess nothing would break?-)
<RAOF> Although you might know better; I've been diving through things man was not meant to know.
<Sarvatt> think we're going to end up just disabling tls completely at this rate?
<RAOF> Sarvatt: Why?  It works for x86-64 ;)
<RAOF> And that's an ABI change that'll freak out the server, IIUC.
<bryceh_> RAOF, I've been distracting myself with some toolsmithing work lately, but I think what I should do is test booting the ppa on a few machines, then put out the usual announcement, and maybe tues/weds we can do the uploads
<RAOF> bryceh_: Sounds reasonable.
<RAOF> I'll need others to help with the uploads, as usual; the DMB didn't get a quorum last night :(
<tjaalton> meh
<bryceh_> RAOF, not a problem
<jcristau> RAOF: i think the enable-glx-tls server is happy to load drivers built with --disable-glx-tls
<jcristau> RAOF: it's the other way around that doesn't work
<RAOF> Ah, ok.
<jcristau> (because tls enabled drivers require symbols only found in tls enabled loaders)
<RAOF> Right.
<tjaalton> ideas how this is possible http://launchpadlibrarian.net/66332175/DpkgTerminalLog.txt
<tjaalton> from bug 734676
<ubot4`> Launchpad bug 734676 in xorg-server (Ubuntu) "package xserver-xorg-core 2:1.9.99.902-2ubuntu2 failed to install/upgrade: installing xserver-xorg-core would break existing software (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/734676
<tjaalton> only thing I can think of is a very stale mirror
<bryceh_> tjaalton,   xserver-xorg-video-tseng provides xserver-xorg-video-8 and is present and installed.
<bryceh_> tjaalton, perhaps uninstall -tseng and try again?
<tjaalton> bryceh_: yeah, but the archive should have the new one
<bryceh_> tjaalton, PPAs involved?
<tjaalton> I guess there's no other reason than a stale mirror then
<tjaalton> no idea, not mine
<bryceh_> I wonder if having -fglrx installed would produce that error message (although obviously not in this case since it's -intel)
<tjaalton> i guess it's proven that fglrx/nvidia has been removed on upgrade :)
<bryceh_> heh, ok true
<tjaalton> i'll close this on
<tjaalton> e
#ubuntu-x 2011-03-15
<bryceh_> RAOF, ok testing going ok so far on some -intel systems but it appears -ati/-radeon is getting uninstalled
<bryceh_> also -video-all and -geode get uninstalled
<RAOF> Ah, geode.
<RAOF> Did I actually upload that?
<RAOF> No.
<RAOF> Silly i386-only drivers.
<RAOF> Fixing.
<RAOF> While mesa builds.  And builds.  And builds!
<bryceh_> yep, wrong ABI for -ati, says it depends on abi 9
<bryceh_> good news is with latest updates unity on dual-head looks a LOT better
<bryceh_> although I can't drag windows from external monitor to lvds for some reason (titlebar gets stuck).  Works going the other way though
<bryceh_> feels like a bug with the logic for drag-to-maximize (monitors are one-above-the-other)
<RAOF> I wouldn't be surprised if unity didn't like that one bit.
<RAOF> One on top of the other isn't a common case :)
<bryceh_> it's a docking station with the monitor on a ledge above it, so top/bottom makes most sense
<RAOF> Yeah, I've used that ordering before, too.
<bryceh_> plus probably not a bad thing to be testing an unusual use case ;-
<bryceh_> )
<RAOF> And things were kinda broken :)
<bryceh_> I can test -ati on a couple systems once that's in
<bryceh_> otherwise, things look good
<RAOF> Man.  Release your shiny new laptops, Sony, so I can build mesa for amd64 and i386 in under 2 hours.
<bryceh_> hmm, lots of held-back packages  - http://paste.ubuntu.com/580381/
<bryceh_> hrm, that's wrong; it's trying to depend on the wrong xserver
<bryceh_> heh, wayland ppa madness.  ok nevermind that one
<bryceh_> nope, I'm wrong
<bryceh_> on one machine it dist-upgraded to 2:1.9.99.902-2ubuntu2 (and stuff broke as pastebinned)
<bryceh_> on another machine it sees 2u2 but only upgrades to 2u1
<RAOF> Hm.  Ok.  Let's see if I can't fix thatâ¦
<bryceh_> heh, crashed unity on my above/below system
<bryceh_> ok with a couple more dist-upgrades and reboots the 2u1 system is booting 2u2 ok
<RAOF> Who wants to upload a partial fix for the TLS madness?
<ScottK> You all ought to go grab this guy: https://lists.ubuntu.com/archives/ubuntu-qa/2011-March/001485.html and explain to him he's supposed to be helping you out.
<RAOF> Ah, wayland testing.
<RAOF> It is perhaps a *little* bit soon for that :)
<ScottK> Right, first you make him to other stuff so that he can prove himself to be allowed to do wayland testing.
<RAOF> Argh.  What's happening here?  The disassembly of glGetString shows a perfectly well-behaved crazy dispatch function, but *calling* glGetString through the PLT appears to go to the wrong place!
<tjaalton> RAOF: still need sponsoring?
<tjaalton> ah, looks like not
 * RAOF rather likes disassemble/m
<ara> RAOF, hello
<RAOF> Heydi ho!
<bryceh_> heya tseliot
<tseliot> hi bryceh_
<bryceh_> RAOF, did you push your latest -intel change to git?
 * RAOF checks
<RAOF> Aha!  Mesa's jumping into the NoOp table.  That's obviously not going to work :)
<tjaalton> RAOF: also, mesa needs a push
<RAOF> Gah.  Yup.
<tjaalton> git push origin; debuild... ;)
<bryceh_> you have no idea how happy it makes me to know I'm not the only one that forgets sometimes ;-)
<RAOF> tjaalton: Wheras I like to check that things build *before* pushing to pkg-xorg, so it doesn't work quite as well!
<tjaalton> heh, ok
<tjaalton> test the build before dch -r
<tjaalton> :P
<bryceh_> we should hack 'git status' into dch or dput ;-)
<jcristau> upstream's modular/release.sh has a "did you push stuff to git" check :)
<tjaalton> yeah something similar might be possible
<Prf_Jakob> Sarvatt: Thanks, with that ati driver built and installed, together with the kernel and firmware package I have kms on my cayman.
<tjaalton> tseliot: is there a way to disable building fglrx dkms for kernels newer than what the driver supports?
<tjaalton> new bugs keep flowing in, where the build fails against a backported kernel version
<tjaalton> 20 per week
<tseliot> tjaalton: I don't think so
<tjaalton> dkms needs such a feature
<tjaalton> since this will repeat every cycle
<tseliot> tjaalton: do you mean a feature to make it skip module builds when using unsupported kernels?
<tjaalton> tseliot: for those kernels, yes
<tseliot> tjaalton: or are you thinking that it should return a different error
<tjaalton> it shouldn't try to build the module
<tseliot> ok
<tjaalton> because otherwise apport kicks in
<tseliot> I think we can ask Mario about it
<tseliot> i.e. whether such feature would be accepted upstream
<tjaalton> btw, why is _get_newest_kernel* from dkms's common.postinst duplicated in nvidia-current.postinst?
<tjaalton> at least they look identical
<tseliot> because I originally implemented that function in the nvidia package and then it was accepted in DKMS
<tjaalton> ah
<tseliot> I can get rid of it
<tjaalton> _is_kernel_name_correct too
<tseliot> I have other stuff I'm working on for nvidia so I could add that to my todo list
<tseliot> yep
<tjaalton> ok
<tjaalton> cool
<cnd> tjaalton, if you're still up for it, the source package for libavg is attached to bug 733247 now
<ubot4`> Launchpad bug 733247 in libavg (Ubuntu) "Please upgrade to libavg v1.5.4 (affects: 1) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/733247
<cnd> I've been mentoring OXullo on packaging, he seems to have left the source.changes file
<cnd> do you need that, or can you generate that yourself?
<tjaalton> I can generate it
<cnd> tjaalton, can you enlighten me on how you generate it? :)
<tjaalton> dunno if there's a better approach than just extracting the source and debuild -S
<tjaalton> the changelog needs a touch too
<cnd> tjaalton, ahh, thought there might be a way without rebuilding
<tjaalton> hmm didn't need to touch the changelog
<cnd> tjaalton, I wondered why you would have needed to do that
<tjaalton> dunno, some old habit I guess
<tjaalton> cnd: anyway, uploaded
<cnd> tjaalton, thanks!
<tseliot> cnd: do you happen to know something that broke dragging here in LP: 733989 ?
<tseliot> bug 733989
<ubot4`> Launchpad bug 733989 in xserver-xorg-input-synaptics (Ubuntu) "dragging with Dell Mini 10v track pad is unforgiving (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/733989
<cnd> tseliot, let me check
<cnd> tseliot, I doubt anything has changed
<cnd> there is a difference in natty though
<tseliot> cnd: what difference?
<cnd> we've enable semi-multitouch in the kernel driver
<cnd> but I don't believe this should be causing click and drag to behave differently
<cnd> I could be wrong though
<cnd> actually, I may be wrong
<tseliot> cnd: is there a way to disable it?
<cnd> tseliot, let me check
<cnd> I was driving the patches for the semi-multitouch functionality
<cnd> but then I handed them off to someone else upstream
<cnd> and actually, I'm not even sure if semi-multitouch is there :)
<tseliot> cnd: ok, thanks
<cnd> no, it's there
<cnd> tseliot, do you have a mini to test with?
<tseliot> cnd: yes, kind of
<cnd> tseliot, ok, I'd suggest trying it out
<cnd> there was one point where I added a hack to the kernel driver
<cnd> to mask out touches in the button area
<cnd> so that click and drag still worked
<cnd> we may need to add that in
<tseliot> cnd: yes, the main problem is that the screen doesn't work at times...
<cnd> ugh
<tjaalton> tseliot: filed bug 735505 against dkms
<ubot4`> Launchpad bug 735505 in dkms (Ubuntu) "RFC: add a mechanism to disable building a module for known bad kernels (affects: 1) (heat: 6)" [Wishlist,New] https://launchpad.net/bugs/735505
<tseliot> tjaalton: ok, thanks, I'll discuss it with Mario
<tjaalton> cool
<lesshaste> which package has the radeon driver?
<tjaalton> cnd: libavg failed to build on armel https://launchpad.net/ubuntu/+source/libavg/1.5.4-0ubuntu1/+buildjob/2322628
<cnd> tjaalton, ahh, I'll take a look
<tjaalton> assembler-goodness
<jcastro> hi, are we supposed to be looking for volunteers? https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers/Natty/WeeklyProgram
<jcastro> I ran into this page and said "oh maybe I can help here."
<cnd> tjaalton, yeah, looks like it just won't work on arm...
<cnd> I'll point this out to Oxullo, maybe he can fix it up
<tjaalton> jcastro: there's no publid driver to test on ati
<tjaalton> cnd: if it's not meant to build there, it can be fixed easily
<tjaalton> *public
<cnd> tjaalton, what do you propose to fix it?
<cnd> other than actually fixing the source
<cnd> do you mean to take arm out of the debian/control arch list?
<tjaalton> cnd: it's "Architecture: any", change that to "i386, amd64"
<cnd> yeah
<tjaalton> or is it x86
<tjaalton> dunno :P
<tjaalton> i386, duh
<tjaalton> powerpc failed too
<jcristau> seems consistent with https://buildd.debian.org/status/package.php?p=libavg
<tjaalton> hehe, right
<cnd> tjaalton, jcristau: yeah, I'm thinking they'll probably just wittle the arch list down to x86
<cnd> but maybe they can nop the one line that calls an x86 assembly function
<tjaalton> actually the errors on debian were due to missing build-deps it seems
<jcristau> hmm.  yeah.
<jcristau> tjaalton: actually.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580678#22
<ubot4`> Debian bug 580678 in src:libavg "libavg - FTBFS: checking whether the Boost::Thread library is available... no" [Serious,Open]
<jcristau> -msse ftl
<tjaalton> uh
<cnd> bryceh_, when you get a chance, please upload the new xinput (pitti approved it)
<Sarvatt> bryceh_: did you upload intel already? you added a few extra sandybridge ids that shouldn't be in there
<Sarvatt> 0100 0104 0108 are bridge chips not GPU's
<bryceh_> oh ok
<bryceh_> wasn't clear from https://patchwork.kernel.org/patch/159971/
<Sarvatt> guess it doesn't matter in the intel hook, i just added them to the compiz blacklist and blocked compiz on sandybridge systems using discrete gpus in the past :P
<bryceh_> cnd, btw pushed
<cnd> bryceh_, thanks :)
<cnd> bryceh_, btw, we find out on thursday where we're moving to
<cnd> exciting times
<bryceh_> cnd, awesome :-)
<bryceh_> cnd, if it turns out you're moving to Portland, bring a good umbrella.  It's been raining in sheets the last few days
<cnd> ugh
<cnd> now you tell me...
<cnd> :)
<bryceh_> and really windy
<bryceh_> the other day I watched a humongous limb fall out of one of the trees onto my neighbor's roof
<cnd> uh oh
<cnd> did it do much damage?
<bryceh_> fortunately not
<bryceh_> they had workers out the next day and got everything back to normal in a couple hours
<cnd> that's good
<bdrung> i have font glitches (http://img192.imageshack.us/f/glitches.png/). against which package should i file a bug report? against the intel driver?
<jcristau> probably
<jcristau> http://intellinuxgraphics.org/how_to_report_bug.html
<bryceh> bdrung, that looks like a bug we already know about (and I think I forwarded it upstream a while back)
<bdrung> bryceh: bug number?
<bryceh> sec
<bryceh> https://bugs.freedesktop.org/show_bug.cgi?id=34584
<ubot4`> Freedesktop bug 34584 in Driver/intel "[i945gm] Screen Corruption with new Xorg stack with terminal programs (bisected)" [Critical,New]
<bryceh> even though it says terminal programs, people see it in firefox too
<bdrung> i saw it in evolution and liferea too
<bdrung> on all my intel system (including sandybridge)
<bdrung> bryceh: should i comment this bug or open a new one?
<bryceh> yep, it isn't a terminal-specific issue but something to do with text rendering so affects multiple apps
<bryceh> bdrung, comment that bug
<bryceh> bdrung, probably testing the git commit that ickle pointed to is the next action
<RAOF> That should be available in the drm-intel-next kernel.
<bryceh> doesn't sound like there's high confidence it would fix it, but feedback one way or the other would probably help move things forward
<bdrung> i am running linux-image-2.6.38-999-generic_2.6.38-999.201103141005_amd64.deb
<bdrung> the drm-intel-next kernel is affected too
<bryceh> RAOF, btw do you mind chiming in on cnd's email?  I don't know offhand why that doesn't work, maybe you have a guess.
<bryceh> bdrung, ok so yup that is probably going to be useful feedback for ickle
 * RAOF checks his mail
#ubuntu-x 2011-03-16
<RAOF> Ooooh. I need ___tls_get_addr rather than __tls_get_addr!
 * RAOF likes that mesa's redefinition of assembler syntax lies in ass yntax.h
<RAOF> WOOOO!  IA32 win.
<RAOF> Ish.
<tjaalton> RAOF: hey, when do we start breaking natty again by uploading 1.10 final & the rebuilds?
<RAOF> tjaalton: Tomorrow, I think.
<tjaalton> RAOF: alright
<RAOF> Although if you wanted to do it while I sleep that would also be ok :).
<RAOF> Coordinating with bryceh, of course.
<tjaalton> ok, either is fine
 * RAOF goes to sleep
<ara> hello bryceh
<cnd> tjaalton, got a moment to help me out with another upload?
<cnd> or bryce?
<tjaalton> cnd: yep
<cnd> tjaalton, so the package is a new package
<cnd> it's got an FFe
<cnd> and it's only for universe
<cnd> I'm an ubuntu dev, and you're an ubuntu dev, so I was wondering if we needed to go through revu?
<cnd> the two of us satisfy the 2 ubuntu dev sponsorship rule
<tjaalton> heh
<cnd> and the wiki page says motus can upload directly
<tjaalton> well, let me review it anyway :)
<cnd> ok
<cnd> tjaalton, https://bugs.launchpad.net/bugs/733266
<ubot4`> Launchpad bug 733266 in ubuntu "[needs-packaging] empcommand (affects: 1) (heat: 10)" [Wishlist,Confirmed]
<cnd> tjaalton, there's 6 more games just like these
<cnd> but they haven't received FFe approval yet
<cnd> that's why I want to skip revu if possible
<cnd> less paperwork
<cnd> but don't feel you need to review them all
<cnd> I've also mentored Oxullo, so the packaging is up to my standards :)
<tjaalton> debian/copyright is probably the most important thing to get right before an upload, after it builds of course
<cnd> I've been reviewing his work as we go
<cnd> yeah, they're in dep5 format and should be correct
<tjaalton> the source package has .pc directory in it, should be removed on clean :)
<tjaalton> i guess
<cnd> tjaalton, I assume it was created with bzr bd -S
<cnd> but I'll see what's up with it
<tjaalton> that's alright
<cnd> hmm, not sure how he got a .pc in there
<cnd> I'll have to ask him what he did
<tjaalton> looks fine otherwise, and that doesn't make the package useless, so I'll upload it
<tjaalton> that=.pc
<cnd> tjaalton, are you sure that's not because you ran dpkg-source -x?
<cnd> cause there's no .pc in the debian.tar.gzr
<cnd> nor in the orig.tar.gz
<tjaalton> ah, maybe it's the new source format that does it, on extract
<cnd> tjaalton, it's interesting that it does that, even where there are no patches
<tjaalton> right
<cnd> tjaalton, thanks for the upload :
<cnd> :)
<tjaalton> np, had to take a break from playing rb: beatles anyway :)
<cnd> heh
<Sarvatt> usr/lib/nvidia-current
<Sarvatt> usr/lib/nvidia-current/libGL.so.1
<Sarvatt> usr/lib/nvidia-current/libnvidia-glcore.so.270.30
<Sarvatt> usr/lib/nvidia-current/tls
<Sarvatt> usr/lib/nvidia-current/tls/libnvidia-tls.so.270.30
<Sarvatt> seriously? libGL in my initrd?
<Sarvatt> thanks cairo-gl
<brobostigon> good afternoon everyone,
<brobostigon> where is the right place for me to ask about trying wayland on natty?
<brobostigon> an if already existing DE's, like gnome-shell will work with it,or not.please.
<jcastro> jibel_: ok so I've posted on nvidia's linux forums, phoronix just ran it, just waiting on OMG. That outta be enough I hope. :)
<jcristau> tjaalton: i think with 3.0 (quilt), dpkg-source creates .pc on unpack
<tjaalton> jcristau: yeah, and on repack it's dropped
<lesshaste> hi
<lesshaste> I get this weird font/screen corruption using the radeon driver.. has anyone else seen anything like it? http://img857.imageshack.us/f/screenshot1p.png/
<lesshaste> oh and I get [263922.948625] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
<lesshaste> I just saw that
<lesshaste> lots of them
<brobostigon> would it be possible to do multi-monitor, with two graphics cards, of totally different kinds and makes?
<bryceh> brobostigon, no
<bryceh> brobostigon, used to be you could do that with Xinerama but not anymore (for now)
<bryceh> brobostigon, you can do it with two NVIDIA cards both running -nvidia
<bryceh> there are some other misc. oddball combos of cards/drivers that would work, but in general with open source drivers and common kinds of cards, no upstream doesn't support that
<brobostigon> bryceh: sosame driver? whether intel,nvidia or ati?
<bryceh> brobostigon, no only -nvidia
<bryceh> possibly -fglrx/-fglrx, I haven't tested that
<bryceh> but definitely not intel or ati
<bryceh> and mixing drivers is almost guaranteed to fail
<brobostigon> bryceh: ah, i see, ihtink i understand.
<brobostigon> bryceh: thankyou,
<bryceh> brobostigon, your welcome
<lesshaste> anyone know if there is an ubuntu bug report for this?
<brobostigon> bryceh: that means,my plan and idea,might work
<bryceh> lesshaste, for what?
<lesshaste> I get this weird font/screen corruption using the radeon driver.. has anyone else seen anything like it? http://img857.imageshack.us/f/screenshot1p.png/
<lesshaste> oh and I get [263922.948625] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
<bryceh> lesshaste, is that natty?
<lesshaste> bryceh: lucid
<bryceh> oh no idea then
<lesshaste> bryceh: it's a regression I think
<lesshaste> it used not to do this
<lesshaste> the computer is not new
<bryceh> we've not done any X changes to lucid in a long time afaik
<bryceh> lesshaste, did your kernel get updated maybe?
<bryceh> could be a drm bug
<lesshaste> bryceh: right but the radeon driver is broken relative to older ubuntu distros
<lesshaste> bryceh: ah yes
<lesshaste> bryceh: it did
<lesshaste> a few times actually for lucid
<bryceh> sure, yeah radeon frequently has graphics mess ups like this, I could identify the driver just looking at the screenshot ;-)
<lesshaste> what's my best plan?
<bryceh> hmm
<lesshaste> they want me to upgrade the kernel at #radeon
<bryceh> sure
<bryceh> yeah, if it were me I'd be looking at changing kernel versions too
<bryceh> if you do think it's a regression though, I'd go backwards
<bryceh> look for an earlier version where you *can't* reproduce it
<bryceh> lesshaste, also there is a lucid backport of the maverick kernel.  That could be worth a test too
<lesshaste> oh yes
<lesshaste> that sounds perfect
<bryceh> another idea is I'd fiddle with switching on or off KMS
<bryceh> I think we shipped -ati with kms on by default in lucid, so boot kernel with radeon.modeset=0 or something like that
<bryceh> or if I'm wrong, then radeon.modeset=1 ;-)
<bryceh> fwiw, #radeon is probably not going to be of much help for lucid bugs; http://askubuntu.com would be a better support channel
<lesshaste> oh.. they have gone all modern! :)
<lesshaste> thanks I didn't know about that
<bryceh> lesshaste, your welcome, good luck
<lesshaste> I think I need it :)
<lesshaste> installing backports and proposed everything...
<bryceh> lesshaste, fwiw, -ati on maverick was pretty stable; on natty it's stable but I see a few graphics bugs here and there
<lesshaste> it was ok on jaunty too :)
<lesshaste> something just went wrong
<lesshaste> hardy was great ! :)
<bryceh> yeah that was pre-KMS
<lesshaste> hi again bryceh :)
<lesshaste> still totally screwed up
<lesshaste> 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
<lesshaste> [  220.961057] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
<lesshaste> appears repeatedly in dmesg
<lesshaste> Build Date: 08 March 2011  08:22:50AM
<lesshaste> xorg-server 2:1.7.6-2ubuntu7.6 (For technical support please see http://www.ubuntu.com/support) 
<sandraw> hi i need some help with this: http://pastebin.com/k9davXre
<sandraw> im having problems building tslib on natty
<sandraw> it is linked to this bug: Launchpad bug 714353 in xf86-input-tslib (Ubuntu) "Does not support Input ABI 12: FTBFS against Xserver 1.10" [High,Confirmed] https://launchpad.net/bugs/714353
<ubot4`> sandraw: Bug 714353 on http://launchpad.net/bugs/714353 is private
<ubot4`> Launchpad bug 714353 in xf86-input-tslib (Ubuntu) "Does not support Input ABI 12: FTBFS against Xserver 1.10 (affects: 2) (heat: 10)" [High,Confirmed]
<lesshaste> how do I use xorg-edges to update the kernel?
#ubuntu-x 2011-03-17
<sithlord48> does the open ati driver allow the use of texture compression ? or will that be something i ned the properitary driver for ? i have an ati4830 
<RAOF> If by âtexture compressionâ you mean the compressed texture formats like S3TC, then âkindaâ.
<sithlord48> honestly i don't know im trying to play a game in wine and it fails to launch due to lack of hw texture compression support. figure the driver is a good place to start
<RAOF> I think kernel support landed in 2.6.38, and I think mesa support is in 7.10.  That merely leaves you with needing libdxtc.
<sithlord48> um 2.6.35 is my kernel
<RAOF> Well, it's not going to work against anything older than Natty.
<sithlord48> ah well then, i would attempt on my netbook but its a pos intel 945 chip...
<sithlord48> so for now i would have to use the properiatry driver if i wanted that option?
<RAOF> Yes.
<RAOF> And you'd need to build libdxtc, too, which isn't packaged in the archives.
<RAOF> (Although I guess it might want to be; sucky patents!)
<sithlord48> the only issue i have w/ that is that driver breaks my xsever basicly after every kernel upgrade.
<RAOF> You're installing from the Ubuntu packages, right?
<sithlord48> no .. 
<RAOF> Well, don't do that; it'll break your xserver each kernel upgrade :)
<sithlord48> no no ... from the ati page., the included driver is almost always old. 
<RAOF> Right.  But it *works*.
<sithlord48> very true.. 
<sithlord48> or i can upgrade to natty.. 
<sithlord48> i have it on my netbook , just i compile w/ this so i try to keep it as "current" but i can just set up a vm easily.
<sithlord48> well thank you for the info RAOF
<RAOF> Sponsor trawl time!  Who'd like to upload a re-enabled IA32 assembler version of mesa?
<tjaalton> RAOF: yeah
<tjaalton> RAOF: looks like was uploaded already
<leshaste> hi 
<leshaste> do I report problems with xorg-edgers to the ubuntu bugzilla?
<tjaalton> leshaste: what problems? if they are upstream bugs they should go to bugs.freedesktop.org
<hrw> hi
<hrw> someone has a cure for radeon GPU lookup?
<tjaalton> hrw: is it reported on launchpad?
<hrw> I will check after reboot - now I am using other machine which lacks good browser speed
<hrw> [490105.390045] radeon 0000:01:00.0: GPU lockup CP stall for more than 10100msec
<hrw> [490105.390086] GPU lockup (waiting for 0x004D1010 last fence id 0x004D100D)
<tjaalton> so you haven't reported it there yet+
<tjaalton> ?
<tjaalton> that's the first step
<hrw> first is "check is it reported" and I will do
<hrw> ok, reboot
<RAOF> bryceh: We should now be ready for 1.10RC3, right?
<tjaalton> why not final?
<RAOF> The build broke between RC3 and final.
<tjaalton> so revert the commit that broke it with a patch
<tjaalton> ?
<tjaalton> or maybe not. which commit was it btw?
<RAOF> One of the doc ones.  Back after dinner.
<leshaste> tjaalton: I get lots of image/font corruption
<tjaalton> leshaste: sounds upstreamish, file on b.fd.o
<leshaste> tjaalton: could you give me a hand with that? It's not obvious to me which component for example
<tjaalton> leshaste: what hw?
<leshaste> 01:05.0 VGA compatible controller: ATI Technologies Inc RS480 [Radeon Xpress 200G Series]
<tjaalton> product xorg, component driver/radeon
<leshaste> ok.. thanks.. Then it asks for the version.  http://pastebin.com/3zuERScS is the X log
<leshaste> I see X.Org X Server 1.8.2 but it wants 7.x
<tjaalton> oh, please test natty first
<hrw> re
<leshaste> I can't really do that easily
<tjaalton> livecd out of the question?
<hrw> I found it - bug 729717 
<ubot4`> Launchpad bug 729717 in xserver-xorg-video-ati (Ubuntu) "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait 0x2ea/0x350 radeon (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/729717
<leshaste> xorg-edgers is meant t up to date no?
<tjaalton> you have the maverick kernel for instance
<leshaste> tjaalton: I have the latest xorg-edgers one for lucid I believe
<tjaalton> and I'm not sure if mesa in edgers is updated
<tjaalton> oh lucid
<tjaalton> totally unsupported combination I guess :)
<leshaste> there is "== New in Mesa - 03/08/2011 ==" at https://launchpad.net/~xorg-edgers/+archive/ppa
<tjaalton> try natty alpha3 livecd and then file a bug if there's one
<tjaalton> on launchpad
<leshaste> the xorg edgers page does say you can report bugs!
<tjaalton> so file one
<leshaste> but maybe on launchpad not freedesktop right?
<tjaalton> I don't know all the answers..
<tjaalton> the first question will be to test on natty anyway...
<hrw> I added apport informations to bug
<leshaste> tjaalton: ok.. back to the other question.. what 7.x version corresponds to  X.Org X Server 1.8.2 ?
<tjaalton> leshaste: you don't need to specify that
<leshaste> ok
<tjaalton> still, they are going to ask to test with the latest kernel..
<leshaste> in the subject, they like to have useful information :)
<tjaalton> so please try with natty alpha3 first
<leshaste> how?
<jcristau> useful information is 'test with a recent version'
<tjaalton> leshaste: download a livecd, boot with that
<leshaste> oh I see
<tjaalton> no need to install anything
<leshaste> good point
<leshaste> ok.. It's all a little frustrating as it all worked fine until lucid
<tjaalton> if you can reproduce the problem easily, then you should be able to confirm if it's still there or not
<leshaste> hardy was great :)
<leshaste> I can reproduce it .. there is a web page that seems to do the trick
<tjaalton> hrw: sure it's the same bug?
<leshaste> intrepid/jaunty were fine too
<tjaalton> hrw: ok the dmesg oops does look similar
<tjaalton> hrw: you could try to install the -7 kernel by hand
<tjaalton> linux-image-2.6.38-7-generic
<tjaalton> not sure if it's built yet though
<hrw> sure
<hrw> installing
<hrw> amazing... first time I got gpu lockup so fast after reboot
<hrw> ok, booting to 2.6.8-7.35
<leshaste> hi
<leshaste> bryceh: turns out that 2.6.38 fixes the problem but 2.6.35 does not
<leshaste> any idea what [   24.456286] [drm:radeon_get_legacy_connector_info_from_bios] *ERROR* Unknown connector type: 8 means though?
<lesshaste> hi.. somewhere between 2.6.35 and 2.6.38 the radeon driver was fixed for my system.   which means that it doesn't really work for lucid or maverick  at least
<lesshaste> is this of interest to anyone?
<tjaalton> not really :)
<tjaalton> unless you can bisect it
<tjaalton> which is close to being hopeless
<lesshaste> that was my bisection :)
<lesshaste> after maverick and before 2.6.38 :)
<lesshaste> I can tell you exactly how to reproduce it and what the drm error is too
<lesshaste> actually if I could easily install 36 and 37 then I could just test those
<lesshaste> it's not hard to do
<lesshaste> is there a nice way to do this?
<Sarvatt> lesshaste: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<lesshaste> Sarvatt: oh yes I have all those already
<lesshaste> that's how I got 2.6.38
<lesshaste> well if anyone were interested, I would be happy to say where the problem was fixed
<lesshaste> at least down to the resolution offered by http://kernel.ubuntu.com/~kernel-ppa/mainline/
#ubuntu-x 2011-03-18
<tjaalton> RAOF, bryceh, Sarvatt: so uploading 1.10 et al will be postponed to next week?
<bryceh> tjaalton, probably safest bet
<tjaalton> bryceh: ok
<bryceh> although looks like raof fixed up -geode and -ati, so maybe it's good to go now
<tjaalton> i could upload those when tseliot is around to upload nvidia
<tjaalton> though I think most of the input drivers are rebuilt for no good reason, only evdev and synaptics support XI2.1
<Sarvatt> tjaalton: tseliot is on vacation until monday, he said whats in the PPA is good to go outside of a version change in the changelog
<bryceh> hi Sarvatt
<bryceh> on the one hand it seems like it'd be better to wait and do it like Monday morning tjaalton's time, which would mean we'd have one of us around at all times in case of problems
<bryceh> on the other hand, it seems unlikely that there's going to be problems, and doing it now gives a good bit of additional time for testing before beta
<tjaalton> on the other hand if RAOF has it all under his trigger to rebuild&dput the drivers, I'll gladly let him to do the uploading :)
<bryceh> he doesn't have coredev yet
<tjaalton> oh right
<bryceh> tjaalton, hmm, I think the weight of the balance favors having more testing time
<tjaalton> well, to publish them somewhere for dget
<bryceh> plus you me and sarvatt are going to be around for the next day, we can handle problems
<tjaalton> RAOF: PING!
<tjaalton> :)
<bryceh> tjaalton, I'm going to boot on -ati now just to doublecheck but otherwise I say go for it :-)
<tjaalton> bryceh: okay
<tjaalton> shouldn't be that late down under..
<bryceh> hmm, -ati box got dropped to failsafe mode
<tjaalton> oo, libx11 1.4.2
<bryceh> hmm, something's busted with -ati
<bryceh> it works when I run 'startx' as root or a user, but when gdm starts it, boom\
<bryceh> no obvious errors tho
<tjaalton> strange
<tjaalton> the previous version works?
<bryceh> yep
<bryceh> well, the version from before updating the X stack worked
<tjaalton> there's 6.14.1 btw
<tjaalton> not packaged yet
<bryceh> obviously downgrading would not go on this xserver
<tjaalton> right
<bryceh> sheesh, why no errors anywhere?  It doesn't even generate a new Xorg.0.log, all that gets created is the failsafe-x one
<bryceh> tjaalton, do you have a ati system handy you could test putting the PPA on?
<tjaalton> bryceh: not set up, I do have an old firegl and an agp-board, but they're not in a case or anything
<bryceh> let me try booting earlier kernel
<bryceh> no go
<bryceh> however
<bryceh> since startx works... I think the problem may not be X
<tjaalton> right
<tjaalton> nothing in the gdm log either?
<bryceh> I notice the session with startx loads with a gnome-terminal open but no decorations, no panel, no background
<bryceh> no gdm log is produced
<bryceh> hmm
<bryceh> .xsession-errors shows "Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
<bryceh> maybe startx isn't setting up auth
<bryceh> oh
<bryceh> heh
<bryceh> when I upgraded to the ppa, since -ati wasn't there, apparently apt decided to uninstall all of gnome
<tjaalton> hah
 * bryceh apt-get install ubuntu-desktop ;-)
<RAOF> tjaalton: PONG!
<tjaalton> RAOF: :)
<tjaalton> RAOF: so we were thinking about pushing the final abi to the archive
<bryceh> ok, desktop happy now :-)
<tjaalton> could I just pull all the packages from the ppa and push them as-is
<tjaalton> without the rebuild hassle
<tjaalton> RAOF: oh, and isn't only evdev and synaptics needing rebuilds for the new XI?
<tjaalton> the ppa has all the input drivers
<tjaalton> rebuilt
<bryceh> what package provides window decorations?
<tjaalton> bryceh: unity?
<bryceh> no, got that installed
<RAOF> compiz-gnome?
<bryceh> aha, point to RAOF
<RAOF> tjaalton: Actually, none of the input drivers need rebuilding; that was an artefact of my over-eager script.
<tjaalton> RAOF: heh, ok that's good
<bryceh> alrighty, that looks proper
<RAOF> Let me run through http://cooperteam.net/Packages and check that all's good to go.
<tjaalton> RAOF: sure, it's easier to wget from there anyway, I guess
<bryceh> RAOF, do you want to send a note to the lists or would you prefer me to?
<bryceh> (or shall we just surprise them?)
<RAOF> Bah, stupid compiz crash.
<tjaalton> surprise attack is the best kind
<RAOF> I think it'd be easier if you send the note; I'm pretty much done for the day.
<bryceh> alrighty
<RAOF> Hm, don't need the already-uploaded mesa in thereâ¦
<RAOF> Looks like everything's there.
<tjaalton> 1.10-0ubuntu1 builds?
<RAOF> And installs and runs.
<RAOF> It's already built in the PPA.
<tjaalton> oh cool, so the build-failure was in the packaging?
<tjaalton> actually, the ppa seems to have that one as pending
<RAOF> What build-failure?
<RAOF> Oh, ah.
<tjaalton> the diff between rc3 and final
<RAOF> No.  There was a cherry-pick to take from post final to make sdksyms work.
<RAOF> Suddenly, context happens :)
<tjaalton> ah
<RAOF> Because the wonderful udeb-builds-don't-work problem that has plagued me locally became a global problem.
<tjaalton> ok then, I'll pull those and upload, and will sort out any kinks during the day, and hand over to bryceh/Sarvatt when they start their day :)
<RAOF> Sweet.
<RAOF> You've got an nvidia driver to go?
<tjaalton> I can pull the one from the ppa
<tjaalton> RAOF: push the server changes and others, if you haven't yet
<tjaalton> to git
<RAOF> Done for xserver, ati, intel.  Checking nouveau.
<tjaalton> cool
 * RAOF should update the rebuild-the-world script to do the git-y thing, too.
<RAOF> Hm, whoops.  Looks like nouveau's git is already out of date.
<RAOF> Aaand nouveau's in git too.
<tjaalton> niice
<tjaalton> uploading
<tjaalton> 1Mbit uplink ftw
<tjaalton> not
<tjaalton> damnit
<tjaalton> nvidia-current doesn't build-depend on a specific server version
<RAOF> We should update nvidia-current (and fglrx) to just list the abis it supports in the packaging, and then have an alternate depends on all of them.
<tjaalton> but now it's getting the wrong abi in depends
<RAOF> Yeah.
<RAOF> Re-rebuild it is :)
<tjaalton> well, I'll add the build-dep
<tjaalton> there
<tjaalton> nice, nvidia failed to build on amd64
<tjaalton>  cdbs : Depends: python-scour but it is not going to be installed
<soren> ?!?
<soren> tjaalton: Do you have a link to the build log?
<tjaalton> http://launchpadlibrarian.net/66646771/buildlog_ubuntu-natty-amd64.nvidia-graphics-drivers_270.30-0ubuntu2_FAILEDTOBUILD.txt.gz
<tjaalton> 0ubuntu1 built fine
<tjaalton> so probably some chroot problem
<soren> That would be my guess, too.
<soren> Glide built just fine on the same box just now.
<tjaalton> I'll retry it
<tjaalton> built fine
<fagan> hey, I have a small question, I just bought a second video card so now I have an ATI and a nVidia in the one machine. The hardware tool picked up on the nv one 
<fagan> but not the ATI
<fagan> So I installed the driver manually, will that break anything or was that just a bug with the detection process?
<fagan> its in 10.10 I havent tested it in 11.04 since its my work machine 
<fagan> (and the fact I just came from 11.04 and the closed source ATI driver was broken)
<jcristau> the closed driver won't coexist peacefully
<jcristau> drivers, even
<fagan> jcristau: hmmm well I could just use the ATI card with the open source driver since it works fine without the closed one but its a shame that they dont work.
<fagan> On windows the only things that clash are the control centers
<fagan> but I suppose they must have put a lot of effort into making them work on windows obviously 
<fagan> Ok im upgrading to 11.04 then since ill be using the nv driver as my main 
<fagan> ill report bugs since thats all the rage :)
<cnd> was there a change somewhere that hides cursors from touch devices somehow?
<cnd> I can't complain :)
<cnd> but I just did a dist-upgrade
<tjaalton> not just touch devices
<tjaalton> it's been awhile
<cnd> tjaalton, can you describe when the cursor disappears?
<cnd> it only seems to disappear when I use my touchscreen
<tjaalton> hmm not sure
<tjaalton> doesn't seem to happen here
<tjaalton> maybe I was wrong
<cnd> tjaalton, it seems that the cursor is hidden any time the contents of the x window under it changes
<cnd> if you run "xinput test-xi2"
<cnd> then move your cursor over the terminal window
<cnd> it will flicker
<cnd> as raw motion events are printed
<cnd> same thing if you hold a button down and drag on the root window in a gnome desktop
<Sarvatt> apw: did you update mesa between tests?
<Sarvatt> apw: https://lists.ubuntu.com/archives/natty-changes/2011-March/009496.html
<Sarvatt> pretty big change for i386 mesa yesterday
<apw> Sarvatt, nope flipping just the kernel is enough to bust me, so i assume its enabling the optimisation which triggered it
<apw> Sarvatt, and indeed, we have a panic so ... i think mesa is off the hook
<Sarvatt> ah, phew
<Amaranth> Sarvatt: oh, btw, mesa 7.11 snapshots from xorg-edgers seem to have fixed my fullscreen flash issues
<Amaranth> and the odd screen flashing I'd get while loading an HTML5 video
<cnd> bryceh, I've pushed a fix to xorg-server packaging tree
<cnd> just fyi
<cnd> it doesn't have to be uploaded asap, as I think only xinput test-xi2 exploits the bug
<cnd> I've also pushed a fix for synaptics that isn't needed asap
<afiestas> hey
<afiestas> I just installed a fresh Kubuntu Natty from alpah3, and upgrade
<afiestas> after the upgrade (before everything was fine)
<afiestas> xrandr is not showing my crtc
<afiestas> http://paste.kde.org/7606/ xrandr output
<afiestas> I'm going to reboot and try to start the kernel without the HDMI cable plugged
<afiestas> same result :(
 * afiestas is scared
<afiestas> I think I got the problem, intel driver wasn't isntaleld :/
<afiestas> rebooting
<afiestas> Mueeheh dunno why but intel driver was not installed, really impressive the fbdev performance
<bryceh> afiestas, look at your /var/log/dpkg.log
<afiestas> bryceh: http://paste.ubuntu.com/582223/
<tjaalton> afiestas: your mirror was lagging behind, and you forced the upgrade
<afiestas> tjaalton: okz, thanks
<tjaalton> afiestas: so the xserver upgrade probably removed it, along with xserver-xorg-video-all
<afiestas> yes, because I didn't had vesa either
<afiestas> the odd thing is that KWin was perfectly working with fbdev :s
<tjaalton> but slow?
<bjsnider> Sarvatt, i just tested the preinstall script in nvidia-common and it doesn't actually suppress the nvidia-installer. it simply adds a yes/no question. the user can hit enter and continue. there is not even a detailed error message like "this installer is not compatible with ubuntu...".
#ubuntu-x 2011-03-20
<brobostigon> good afternoon everyone.
<brobostigon> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/720468/comments/10
<ubot4`> Launchpad bug 720468 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x7f9c002d) (affects: 25) (dups: 21) (heat: 206)" [High,Fix released]
<brobostigon> the published fix seems to hve not worked.
<brobostigon> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715096/comments/9
<ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 18) (dups: 15) (heat: 216)" [High,Incomplete]
<brobostigon> its getting confusing now, as where put reports for gpu lockup's on intel, as there seems to be quite a few.
<brobostigon> can someone advise please.
<brobostigon> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/720468/comments/10
<ubot4`> Launchpad bug 720468 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x7f9c002d) (affects: 25) (dups: 21) (heat: 206)" [High,Fix released]
<brobostigon> i amstill getting gpu lock up, even after the fix, but there are a few gpu lockup bugs revolving around intel.
<brobostigon> any advice.
<jcristau> http://intellinuxgraphics.org/how_to_report_bug.html
<brobostigon> jcristau: i followed all of that a few weeks ago, and then the bug i reported was reported as a duplicate of that main gpu lockup bug.
<jcristau> well then it's probably not the same
<brobostigon> 730099 was my original bug,
<brobostigon> howeevrm i see no point in reporting to that, if its considered a duplicate, and will be ignored.
<brobostigon> jcristau: so for it to be different can the bug i originally reported be un-duplicated. please.
<tjaalton> brobostigon: bug 715096 is still open
<ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 18) (dups: 15) (heat: 216)" [High,Incomplete] https://launchpad.net/bugs/715096
<tjaalton> and your bug is a dupe of that
<brobostigon> tjaalton: so what do i do?
<brobostigon> tjaalton: and i have proved info onto that bug. aswell.
<tjaalton> brobostigon: is it the same with current natty?
<brobostigon> provided*
<brobostigon> tjaalton: with updates untill 10am this morning, yes,
<tjaalton> I don't see you mentioning that there
<brobostigon> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/715096/comments/9
<ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 18) (dups: 15) (heat: 216)" [High,Incomplete]
<tjaalton> yes, a link to another bug
<brobostigon> tjaalton: but that has the details of the dmesg dump etc
<tjaalton> better to post it on the bug yours is marked as a duplicate of
<brobostigon> so ie 715096 ?
<tjaalton> no
<tjaalton> oh, yes
<tjaalton> getting confused
<tjaalton> or report it upstream
<brobostigon> ok, let me copy that dmesg dump, showing the bug into that.
<tjaalton> attach it, don'áº paste it inline
<brobostigon> attach a text file containing.
<brobostigon> that dump.
<tjaalton> yep
<brobostigon> ok. 
<brobostigon> done https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/715096/comments/10
<ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 19) (dups: 15) (heat: 140)" [High,Incomplete]
<tjaalton> good
<brobostigon> so thats the one, i should file stuff to, if it happens again, and or reoccurs?
<tjaalton> yep
<tjaalton> and I think you should be able to undupe your own bugs if needed
<tjaalton> just open the bug and see the panel where it says it's a dupe
<tjaalton> and change that
<brobostigon> is there any need and or ppoint in doing that, as you said, i shouldreport to a different bug.?
<tjaalton> no, just saying
<brobostigon> ah, ok. thank you. i will note that down.
<tjaalton> you can check it out now, to see if I'm wrong..
<tjaalton> don't need to commit the change, just check that you can delete the dupe info
<brobostigon> let me try and see if i can.
<tjaalton> it's possible that only members of the respective package team and members of ubuntu-bugs can do that, but..
<brobostigon> yep, i cansee where,
<brobostigon> dont know if it will let me or not.
<tjaalton> is there a yellow "ball" in front of the "duplicate of bug..." line?
<brobostigon> yes.
<tjaalton> click it
<tjaalton> it opens a dialog where you can clear the bug field
<tjaalton> so that's how you do it
<brobostigon> got it, i have made notes.
<brobostigon> :)
<tjaalton> niice
<brobostigon> tomboy to the rescue.
<Eren> I've installed binary ATI drivers, 11.2. However, all the files are gone into /usr/lib/fglrx (including libraries, x modules, etc.)
<Eren> I've set module path to /usr/lib/fglrx on X, however, these modules in fglrx directory searches for libraries in /usr/lib/fglrx/
<Eren> there are similar problems on the net with workarounds, but these workarounds do not work as well, any ideas?
<tjaalton> haven't used fglrx in years. besides, if you use the ati installer, all bets are off
<tjaalton> don't think we even try to support it
<Eren>  I see from Xorg.0.log that "dlopen: libatiuki.so.1: cannot open shared object file: No such file or directory"
<Eren> whereas, this file is present in /usr/lib/fglrx directory
<Eren> I, at least, want to give a try :)
<Eren> tjaalton: what would you suggest for new-brand AMD E-350, with APU ?
<tjaalton> windows :)
<Eren> I just deleted it :)
<tjaalton> never heard of that one before
<tjaalton> i mean the chip
<Eren> http://www.phoronix.com/scan.php?page=article&item=amd_fusion_e350&num=1
<Eren> some guys in ubuntu forums managed to get VAAPI work
<Eren> I cannot even start X server though :)
<tjaalton> well, natty should work according to that article
<tjaalton> no idea about vaapi
<Eren> "dlopen: libatiuki.so.1: cannot open shared object file: No such file or directory"
<Eren> that's the problem right now, I tried setting LD_LIBRARY_PATH, but no luck
<Eren> any way to set prefix for dlopen in x?
<tjaalton> sure, I just don't remember how / have never needed that
<Eren> huh, I'm stuck :)
<bjsnider> don't we have the latest fglrx in x-updates?
<bjsnider> it was sent in on dec 17. not sure if that's the latest or not
<tjaalton> probably not, 11.2 is from last month
<bjsnider> not sure why it wasn't updated
<Eren> I am still digging it, tbw
<Eren> if you are interested in updating the binary driver, I would like to test it
<Eren> https://help.ubuntu.com/community/BinaryDriverHowto/ATI needs updating as well
<tjaalton> it's a wiki ;)
<Eren> :)
<Eren> need to sleep..
<Eren> good night all
<brobostigon> nos da everyone, sleep well.
#ubuntu-x 2012-03-12
<ripps> Is there anyway to tryout and experimental dri driver without installing it to /usr/lib/dri? Like how you can load libraries using LD_LIBRARY_PATH?
<Sarvatt> LIBGL_DRIVER_PATH
<Sarvatt> except its not working at the moment with upstream mesa git after automake fun
<Sarvatt> using system libglsl and libglapi :(
<tjaalton> uh, so screensaver doesn't want to let go of the blank screen, even after killing it.. vt's don't work either, everything else does
<apw> bryceh, where were we with the edid patch thing, any luck proving whether it works ?
<apw> broder, i have an updated patch which addes an edid/ prefix to the firmware paths -- that seems safest overall
<tjaalton> RAOF: still about? do you know if colorhug works with wled displays?
<tjaalton> Sarvatt: btw the commit id's you gave for intel-vaapi-driver were both the same ;)
<tjaalton> so the other one was probably the cherry-picked commit-id?
<Sarvatt> tjaalton: http://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=99ded53e66af1903f1d58ffbc24404d435a6de84 and http://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=368731d104da84605fcf6683d6ce014916fe76b0
<tjaalton> hmm, neither applies cleanly on what I have
<Sarvatt> it cherry-picks fine on whats in pkg-multimedia git, did you cherry-pick 99ded53 first?
<Sarvatt> http://paste.ubuntu.com/880344/
<tjaalton> oh, so it does. doesn't apply on my ubuntu branch though..
<tjaalton> I'll figure it out..
<tjaalton> oh, hehe.. I had a snapshot already in the branch 
<bryceh> apw, well, I at least proved the edid I was using didn't work
<bryceh> apw, I figure I'll come up with a different edid and try again, but am off today so a task for tomorrow
<apw> bryceh, ack, thanks
<FernandoMiguel> evening
<RAOF> tjaalton: I believe it does work with wled displays; if not, it should in future.
<RAOF> tjaalton: (Where "it" is the colourhug)
<Sarvatt> tjaalton: i would hope so considering a very very large portion of laptops use them :) huey pro certainly does
<RAOF> I presume tjaalton's talking about wide gamut LED displays, rather than just random led-backlit displays.
#ubuntu-x 2012-03-13
<Sarvatt> RAOF: ignore the patch names, how crazy does this look to you? http://paste.ubuntu.com/881301/
<Sarvatt> going to need to condense these 50+ assigned private ivybridge bugs into something public for a SRU, ugh
<RAOF> Sarvatt: What's getbuffer doing in there? 
<RAOF> It doesn't look like an ivybridge fix; is that for something else?
<RAOF> Oh, whoops.  That xfixes upload *may* have broken ABI.
<RAOF> Or, rather broken ABI that we care about.  Stupid structure packing.
<Sarvatt> RAOF: now I'm going to be disappointed when its not quetzalcoatl
<Sarvatt> it will be fun misspelling that in debian/changelog 99% of the time
<Sarvatt> oh wait thats not the adjective :)
 * RAOF is hoping for âQuesting Quetzacoatlâ
<RAOF> And also popping out for a moment.
<tjaalton> Sarvatt: quetzal is the bird, quetzalcoatl is some "feathered mesoamerican deity" :)
<tjaalton> RAOF, Sarvatt: yeah I'm not that worried that it wouldn't work with wleds, but a friend of mine kinda is
<tjaalton> though he's also willing to just try it out since the colorhug is so affordable
<RAOF> And just to be sure, by âwledsâ you mean wide gamut led backlit displays, right?
<RAOF> Such as, say, a Dell U2410?
<tjaalton> is the marketing name "white leds"? then yes
<RAOF> That makes it sound like just a simple led backlit display; if so, definitely yes.
<tjaalton> he heard that some devices have a hard time getting the calibration right
<tjaalton> ok thanks
<RAOF> (Also definitely yes for wide-gamut led backlit display âº)
<tjaalton> right, I was pretty sure about that already, just wanted to confirm :)
<tjaalton> not that you can actually get one anyway, the backlog is six weeks long..
<RAOF> Also, it's easy to update the firmware, there's room for 60-odd calibration matricies, and Richard is adding more matrices as he gets access to more hardware (that's one of the things the first round of pre-order customers are doing; calibrating the colorhug using their existing photometers)
<Sarvatt> wow 4 months lead time to get one
<tjaalton> hmm weston, why not sync it?
<RAOF> A fair question.  Sarvatt, any comments?
<Sarvatt> RAOF, tjaalton: at this point its better than nothing, not sure if bryce cares about wstart and the background getting dropped :)
<tjaalton> Sarvatt: thanks, syncing :)
<Sarvatt> tjaalton: wait
<Sarvatt> did you test build it?
<Sarvatt> debian puts wayland egl in a different package
<tjaalton> heh
<tjaalton> well it's in NEW
<tjaalton> I'll try
<Sarvatt> yeah /usr/bin/ld.bfd.real: cannot find -lwayland-egl
<tjaalton> hmm actually, wayland egl got moved
<tjaalton> what, we should have it in the same package
<Sarvatt> hmm
<tjaalton> _should_, don't necessarily have it yet, I looked at the issue during one merge..
<tjaalton> sigh
<Sarvatt> tjaalton: libwayland-egl needs to be in /usr/lib/multiarch/mesa-egl/ with the rest of the egl libs, works that way
<tjaalton> so we ship it in both libegl1-mesa and libegl1-mesa-drivers
<tjaalton> cool
<tjaalton> ..
<tjaalton> I'll change that
<Sarvatt> dri/usr/lib/${DEB_HOST_MULTIARCH}/egl/egl_gallium.so usr/lib/${DEB_HOST_MULTIARCH}/egl looks wrong too
<Sarvatt> libegl1-mesa-drivers.install.linux.in
<Sarvatt> should be in mesa-egl i imagine
<Sarvatt> erg libxfixes is removing unity
<tjaalton> update
<tjaalton> ..again
<Sarvatt> ah ok
<Sarvatt> us.archive.ubuntu.com is lagging, still offering 5.6.0-0ubuntu1
<tjaalton> it's libxfixes3 1:5.0-4ubuntu3 that you want
<tjaalton> the previous one broke the abi
<Sarvatt> its pulling down 1:5.0-4ubuntu4 which breaks the old unity offered
<tjaalton> oh
<tjaalton> hmm
<tjaalton> ok not sure what's wrong then :)
<tjaalton> I managed to upgrade before the new libxfixes got built
<Sarvatt> they're going back to the ubuntu2 xfixes and rebuilding unity against it but unity got stuck in depwait and had to be rebuilt again, just finished 20 minutes ago
<tjaalton> heh
<Sarvatt> Binary: libwsbm-dev libwsbm1
<Sarvatt> doh
<Sarvatt> gotta fix cedarview packaging now
<tjaalton> I noticed that moving windows across workspaces is broken in fabulous ways if the wall animation timeout is 0 (=disabled)
<tjaalton> has been for some time though
<tjaalton> what about the guy wanting to have gallium i915_dri back? should it build fine etc so it can be shipped in -dri-experimental?
<Sarvatt> tjaalton: dri/usr/lib/${DEB_HOST_MULTIARCH}/libwayland-egl.so usr/lib/${DEB_HOST_MULTIARCH} in libegl1-mesa-dev, doesn't that need to be in mesa-egl too?
<tjaalton> actually, why are we moving the wayland bits?
<tjaalton> expecting the blobs to reiplement them?
<Sarvatt> it needs to be in the same place as egl
<Sarvatt> egl's getting moved to use with alternatives for blobs yeah
<Sarvatt> tegra, cedarview, all the arm crap
<tjaalton> ok if it needs to be there then fine
<Sarvatt> well weston failed until i moved libwayland-egl* to /usr/lib/multiarch/mesa-egl/
<tjaalton> man this is hard to get right
<tjaalton> in my head at least :)
<Sarvatt> tell me about it, mesa is crazy
<Sarvatt> main reason i'd like to not bring back i915g
<jcristau> can't the folks who want i915g just build it themselves?
<tjaalton> ok so yes libwayland-egl.so needs to be there too, since we already create a link pointing there..
<tjaalton> ..which is racy, dunno which one gets installed
<tjaalton> Sarvatt: ok pushed, looks ok now?
<Sarvatt> tjaalton: yeah minus libegl-gallium.so not being usable, but i've got to dig out a gallium using system to look at that one. at least weston will build against that. want me to test build and try building weston just to be sure?
<tjaalton> Sarvatt: if it's not much trouble, sure
<Darxus> I just realized there's a chance of compatible wayland and gtk packages in 12.04 Precise.  What are the chances of gtk 3.4 being included?  
<seb128> Darxus, gtk 3.4 is already in precise for 3 months
<Darxus> Oh.  Nice.  So some gtk apps can already run through wayland on precise with only packages in the precise repositories?
<Sarvatt> i imagine gtk+ needs to enable wayland support, but not sure thats something thats wise :)
<Sarvatt> its bad enough keeping wayland and mesa up to date together because the api changes so much, gtk+ would complicate things greatly
<Sarvatt> many assumptions you're running git master of everything always to use it still
<Darxus> Sarvatt: Yeah except wayland did a 0.85 release that gtk is maintaining compatability with until the 3.4 relese.
<Darxus> And the wayland 0.85 release is what's packaged for precise.
<Sarvatt> well ya might want to ask in #ubuntu-desktop or file a wishlist bug, its definitely not enabled at the moment
<Darxus> seb128: seb128 Where is gtk 3.4?  This looks like 3.3 is in precise:  http://packages.ubuntu.com/search?suite=precise&keywords=libgtk
<Darxus> Sarvatt: Okay, thanks.
<Sarvatt> Darxus: from my perspective the problem is going to be when we do LTS backports, backporting X/mesa/kernel from 12.10 into 12.04 for newer hardware support, wayland will be included, thats guaranteed going to break 3.4 gtk+ wayland (gotta be crazy to think 0.85 will last that long without major breaks)
<Sarvatt> it's kind of too late already too, we're well past feature freeze but ya have to talk to the desktop guys about it to be sure
<Darxus> Thanks.
<Darxus> I don't see how enabling wayland in gtk, so it works when precise is released but breaks when other packages get backported in the future is worse than never having it work in precise at all.
<seb128> Darxus, 3.3 is the 3.4 serie, it just didn't turn stable yet
<Darxus> seb128: Nice, thanks.
<Sarvatt> Darxus: I bet ricotz would be interested in enabling it in the gnome ppa if you catch him on, possibly getting it ready to go for when 12.10 opens
<Darxus> Sarvatt: Good to know, thanks.
<Sarvatt> he keeps wayland up to date in xorg-edgers and is interested in it and also does lots of gnome stuff
<Sarvatt> i'll ping him when i see him on
<Darxus> Cool.
<cnd> RAOF, I need help getting unity 3d on behemoth again :(
<cnd> I don't understand why it's always broken...
<cnd> when you have a minute, please ping me
<cnd> RAOF, nm, unity --reset fixed it
<cnd> RAOF, though I do need you to review the xorg-gtest patches :)
<RAOF> cnd: Sure :)
<cnd> RAOF, as for the xorg-gtest MIR, we have a lot of work to do
<cnd> we have to push to get xorg-macros 1.17 released upstream
<cnd> we have to get the latest xorg-gtest released
<cnd> and then both packaged up and updated in precise
<cnd> all after the feature freeze...
<RAOF> Well, we can leave that.
<cnd> really, we have to do it anyways
<RAOF> The tests are now available for those who want to build locally.
<cnd> because xorg-gtest is currently broken in precise
<cnd> the gtest update that removed the static libs breaks xorg-gtest
<RAOF> Oh, because it builds against the static library I removed.  Superb!
<cnd> yeah
<RAOF> cnd: Do you have any magical way of easily pulling patches out of git send-email's output (rather than saving each mail and applying)?
<cnd> ask for where one can pull patches from?
<cnd> do you need my patches?
<cnd> if so, my personal xorg-gtest repo on fdo in the "source" branch has my commits
<cnd> RAOF, ^^
<RAOF> That's probably easier :)
<cnd> RAOF, remember you'll need the latest xorg macros
<cnd> and they need to be updated to appear as though they are 1.17
<cnd> or manually reset the minimum version requirements to 1.16 when you test it out
<Sarvatt> RAOF: btw barriers are screwed up on some input drivers
<Sarvatt> mtrack is a mess but synaptics is fine
<RAOF> Sarvatt: ???!
<Sarvatt> how do i go about finding out why? :)
<Sarvatt> it takes literally 10 attempts to make the launcher pop out with xf86-input-mtrack
<Sarvatt> guess i should try evdev, thats the one that would suck to have broken
<RAOF> Ok.  So the barrier blocking behaviour works fine, but the launcher reveal is brokenish?
<RAOF> Kindly build http://paste.ubuntu.com/882498/ (you'll need âgcc -o barrier-test barrier-test.c -std=c99 $(pkg-config --libs xi xfixes)â)
<Sarvatt> its like i cant press hard enough to make it pop out
<Sarvatt> had to switch back to synaptics to use autohide
<RAOF> If you run that it'll dump the velocity values you generate when you hit the thingy.
<Sarvatt> incredibly frustrating :)
<Sarvatt> what should i use for threshold?
<RAOF> Anything; it doesn't really matter.
<RAOF> Although don't set it higher than a couple of thousand, or you won't be able to get past it  :)
<Sarvatt> http://paste.ubuntu.com/882516/
<Sarvatt> first is synaptics which works great
<Sarvatt> it could just be an mtrack specific problem, will try evdev out
<Sarvatt> nevermind evdev doesn't work
<RAOF> Sarvatt: Aaah.  Thanks for that.  mtrack is doing something crazy - notice how the ids for synaptics stay constant while you're hitting the barrier, and the mtrack ones don't?  That indicates that mtrack is sending motion events which *don't* hit the barrier in between.
<RAOF> Could you try an xinput test, see what actual events are hitting the server when you try to run against the barrier?
<bryceh> Sarvatt, is the mesa currently in xorg-edgers going to be pulled into precise, or are we on to doing individual cherrypicks at this point?
<Sarvatt> bryceh: yeah 8.0.2 is releasing this week
<Sarvatt> RAOF: this is so chatty, do you want a log of just me pressing against the edge and it not revealing?
<Sarvatt> http://paste.ubuntu.com/882529/
<RAOF> Yah, that'd be fin.
<RAOF> Sarvatt: Is that constant motion right-to-left?
<RAOF> Or, at least, constantish?
<Sarvatt> http://paste.ubuntu.com/882531/ thats me pressing against it 3 times trying to reveal it from the middle of the screen
<Sarvatt> well i guess i do speed up as i get closer to the edge
<Sarvatt> i try to push it hard
<RAOF> You'll probably have better luck pushing it more gently.
<RAOF> It looks suspiciously like mtrack is sending some leftâright motion events in the stream.  Which'll break the barrier stuff.
<RAOF> Could you perhaps do the same with test-xi2?  That should give the raw relative events.
<Sarvatt> http://paste.ubuntu.com/882537/ thats 7 or so times being constant with how hard i'm pressing against the edge
<Sarvatt> ok i'm happy as long its the unsupported universe driver is at fault :)
<Sarvatt> i had to switch while synaptics was causing me crashes with the lid closed to get things done, but synaptics seems to be working again after cnd's fixes
<RAOF> I'd like to know the xi2 results too, as I think that's a better velocity measure.
<Sarvatt> holy hell thats even chattier
<cnd> woot! synaptics with clickpad support released upstream
<RAOF> Yes.  Yes it is.
<cnd> clickpad+clickactions even
<Sarvatt> i wonder if that'll even fit on pastebin
<Sarvatt> cnd: aweeesome!
<cnd> now I just need to reopen the FFe
<Sarvatt> http://paste.ubuntu.com/882543/
<Sarvatt> first attempt brought out the launcher, took 5 attempts or so after that to bring it out the next time
#ubuntu-x 2012-03-14
<RAOF> Huh.
<RAOF> That's not what I expected.
<RAOF> I may need to revise my hypothesis.
<bryceh> Sarvatt, this look at all familiar?  https://launchpadlibrarian.net/93758841/white_window-all_screens2.png
<bryceh> occurs with chromium intermittently apparently
<Sarvatt> bryceh: nope only seen one white screen when everything in the background was fine
<Sarvatt> bryceh: intel?
<bryceh> of course ;-)
<bryceh> it's lp #935630
<ubottu> Launchpad bug 935630 in mesa (Ubuntu) "White rectangular" [Undecided,Incomplete] https://launchpad.net/bugs/935630
<bryceh> actually wait, this has a radeon card in it too
<bryceh> but yeah, -intel
<bryceh> someone else seeing it, is on -radeon
<bryceh> bet it's a compiz bug
<Sarvatt> bryceh: the mesa bug i'm thinking that ended up with all white windows like that crashed in mesa every time not long after, you upstreamed it, i dont see anything standing out in that bug
<Sarvatt> looks like i closed the bug, the guy gave really good debug info on it so i was keeping track of it :(
<cnd> it's raining releases :)
<cnd> RAOF, there's a new xorg-macros
<Sarvatt> i already updated macros in debian twice and it hasn't been released, a third!?
<bryceh> katamari coming
<cnd> Sarvatt, it's my fault :)
<cnd> I added some testing and c++ related stuff to macros
<cnd> it's now 1.17
<Sarvatt> i saw the leadup but havent seen the release, its late here :)
<cnd> I just got the email
<Sarvatt> pushing it to git
<Sarvatt> after a build test
<Sarvatt> might as well 0ubuntu1 xutils-macros unless you plan on pushing more :P
<Sarvatt> err xutils-dev
<Sarvatt> pushed
<eruditehermit> hey
<eruditehermit> when using synaptics, my mouse doesn't highlight menu items
<eruditehermit> is this something you guys have seen?
<RAOF> I believe that's either a compiz bug or a gtk bug.
<eruditehermit> it works with psmouse proto=exps
<eruditehermit> RAOF, so it is a known problem?
<RAOF> eruditehermit: Yeah, I'm pretty sure it is.
<eruditehermit> cool
<eruditehermit> thanks RAOF
<RAOF> cnd: Huh.  I presume you actually built your xorg-gtest patches; why am I having so much trouble?
<RAOF> cnd: BAH!  It's because you lied.  Your source branch does not contain all the commits on the list (specifically, it doesn't have 3/9 - hide evemu under #ifdef)!
<Sarvatt> tjaalton: so wayland-demos needs to be removed now right?
<Sarvatt> bryceh: do you have any desire to have wstart and your background in wayland-demos anymore? weston was synced, aka the wayland-demos rename and lost all customizations
<tjaalton> Sarvatt: I guess so
<Sarvatt> tjaalton: ok filing the bug
<cnd> RAOF, it doesn't?
<cnd> I pushed exactly what sent to the list
<RAOF> Huh.  My pulls don't see that commit, and it causes build failures.
<cnd> RAOF, you have commit f12dbf8526643c2a0c88b5c52ed9f82a7cb232cf?
<RAOF> Yes.
<RAOF> And f12dbf8~1 is f46d862b2 - Install xorg-gtest source code in $(prefix)/src/xorg-gtest in my pull.
<RAOF> cnd: http://cgit.freedesktop.org/~cndougla/xorg-gtest/log/?h=source doesn't seem to list it, either.
<Sarvatt> tjaalton: hmm should weston provide wayland-demos maybe? https://bugs.launchpad.net/ubuntu/+source/wayland-demos/+bug/954722
<ubottu> Launchpad bug 954722 in wayland-demos (Ubuntu) "Please remove wayland-demos from the archive for precise" [Undecided,New]
<cnd> RAOF, http://cgit.freedesktop.org/~cndougla/xorg-gtest/commit/?h=source&id=f12dbf8526643c2a0c88b5c52ed9f82a7cb232cf
<cnd> it's the 6th commit from top
<cnd> "Add a meta-header xorg-gtest.h"
<RAOF> Oh, right.
<RAOF> I'm looking at a different thing - src/xorg-gtest-all.cpp
<RAOF> Which unconditionally includes device.cpp
<cnd> ahh, yes
<cnd> sorry
<cnd> I forgot to check when evemu isn't installed
<cnd> I'm testing that right now
<RAOF> How do you get around the double build of device.cpp?
<cnd> double build?
<cnd> RAOF, I just pushed a fix to xorg-gtest-all.cpp
<cnd> pull again from the source branch
<cnd> it should build without evemu
<RAOF> I get http://paste2.org/p/1939451 when I build *with* evemu.
<tjaalton> Sarvatt: maybe so, if if ships same binaries
<cnd> argh, let me double check
<RAOF> Incidentally, it'd be a good idea to build the xorg-gtest library during build, but not install it.
<Sarvatt> tjaalton: well we'll see if the archive admins complain :)
<cnd> RAOF, that's what make check is for
<RAOF> Ah, so it is.
<cnd> RAOF, I can build it with and without evemu
<cnd> with the very latest in my source branch
<RAOF> So can I.
<cnd> it looks like you are trying to build device.cpp separately from xorg-gtest-all.cpp in the output you pastebined
<RAOF> That's not tip; that's with all patches up to 8/9 installed.
<cnd> hmm...
<cnd> are you sure?
<cnd> I have 9/9 here
 * RAOF tends to test-build with each patch when reviewing.  People like it if all intermediate steps build, for some reason.
<cnd> oh, you mean you've built up to 8/9
<Sarvatt> for good reason, it is git after all :)
<cnd> if every git commit builds in my series I'll be pleasantly surprised
<RAOF> Sarvatt: Indeed.  And since git has a stupid merge modelâ¦ :{
<cnd> I tried to do things in a sane way
<Sarvatt> stupid, ha! :)
<cnd> but overhauling the build system is not an easy task over multiple commits
<Sarvatt> i like seeing history instead of merged foo branch with 40 commits as one commit thanks :)
<cnd> Sarvatt, I tend to think git merge --no-ff is helpful
<cnd> having had to backport all of the input stack from 1.12 into 1.11 :)
<RAOF> Sarvatt: It's a matter of opinion; I find treating the merge as a single unit is most often the most useful way to think about it.
<cnd> I agree
<cnd> but I don't bother with --no-ff for git branches
<cnd> because no one else does
<RAOF> Since your merge is generally *conceptually* one unit of work, broken up into a bunch of smaller parts - the individual commits.
<Sarvatt> i just hate going through something like http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/unity-greeter/precise/changes
 * Sarvatt picked the first bzr branch that popped up in his browser
<Sarvatt> yes i know rXXX broke it, but it did 30 things at once
<RAOF> That's not a terribly good example, because it's a packaging branch :)
<RAOF> So the unit of measure there is the "release" :)
<RAOF> Huh.  I'm a bit surprised that it doesn't have the upstream history, though.
<Prf_Jakob> https://bugs.freedesktop.org/show_bug.cgi?id=44697 <-- is this something you guys have seen?
<ubottu> Freedesktop bug 44697 in Mesa core "Update from 7.12 to 8 (git) breaks compiz/unity" [Normal,New: ]
<Sarvatt> Prf_Jakob: thanks, replied
<Sarvatt> most likely wont still be a problem, price you pay for following git master :P
<bryceh> Sarvatt, no I don't really care anymore
<cnd> RAOF, I just updated my source branch a bit more
<cnd> I'm done for the day though
<cnd> please let me know if there are any issues
<cnd> I'll work on them tomorrow
<cnd> thanks!
<RAOF> I'll check.
<tjaalton> oh geez, the weston sync made it in phoronix..
<dupondje> Could somebody give https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397 a look?
<ubottu> Launchpad bug 931397 in xorg-server (Ubuntu Precise) "Xorg crashes with AutoAddDevices "false"" [High,Confirmed]
<bryceh> dupondje, yeah I looked at it, and can reproduce it myself.  Next step is probably some intimate git-bisection work to find the failure, just haven't had time yet.
<dupondje> It seems fixed already in a newer version
<dupondje> i'll see if I can do some bisect
<bryceh> that'd be great
<LLStarks> is multitouch for touchpads or touchscreens?
<bryceh> LLStarks, both
<LLStarks> bryceh, how do i make use of it? all that new xinput code seems to have done is eliminate skipping when multiple points of contact are made on the touchpad.
<bryceh> LLStarks, cnd has posted some emails and stuff to ubuntu-devel@ and ubuntu-x@, with some of the commands that turn things on and customize them.
<bryceh> some of it depends a lot on your hardware.
<cnd> LLStarks, are you asking how to develop applications with multitouch support?
<cnd> sorry to message and run, I need to get some lunch
<cnd> biab
<FernandoMiguel> evening
<FernandoMiguel> what's that white bar over HUD?
<FernandoMiguel> http://i.imgur.com/m21U1.png
<bryceh> FernandoMiguel, it's even shadowed!
<FernandoMiguel> I know
<bryceh> FernandoMiguel, compiz bug probably; there've been other such white box bugs reported, dig through the compiz bug pile
<FernandoMiguel> k
<bryceh> I bumped one over there the other day
<LLStarks> cnd, just use multitouch for cool things like gestures or multi pointer
<cnd> LLStarks, what is your definition of "use"?
<cnd> do you want to use multitouch to develop applications using gestures?
<LLStarks> no
<cnd> or do you want to play with multitouch applications?
<LLStarks> play
<LLStarks> synaptic gesture is fedora-only
<LLStarks> afaik
<cnd> we have the same synaptics for trackpads
<cnd> but those aren't really multitouch
<cnd> LLStarks, unity has gestures
<cnd> but we don't have many applications with gestures yet
<cnd> we're still developing easy-to-use gesture APIs
<LLStarks> only unity? what about gnome-shell?
<cnd> if you have a touchscreen, you can test out some gesture support in eog and evince
<jcristau> LLStarks: canonical works on unity not gnome shell..
<cnd> LLStarks, nothing is preventing gnome-shell from using utouch for gestures like unity does, but no one has attempted to yet
<cnd> RAOF, I hope xorg-gtest is all ready for your usage today :)
<RAOF> cnd: I'm just sending a mail to xorg-devel saying that the source branch now builds fine for me, and throwing a reviewed-by at it.
<cnd> RAOF, what about the interface for other projects?
<cnd> i.e. the xorg-gtest.m4 script and Makefile-xorg-gtest.am
<RAOF> That looks like a reasonable solution to me.
<cnd> ok
<RAOF> I guess you could write a custom Makefile, rather than use an autotools generated one, and that might be nicer.  I'm not entirely sure how that would look, though.
<cnd> I'm worried about trying to support such an approach long term
<RAOF> The "include a makefile" approach?
<cnd> yeah
<cnd> and making it work properly with all the permutations of configurations
<cnd> like silent build options
<RAOF> Oh, right.
<RAOF> Silent build isn't *terribly* hard to implement manually, but it's more annoying, yeah.
<RAOF> I don't think the build permutations would be terribly hard to support, though?
<cnd> I don't really know
<cnd> and I don't have time to try to think about it :)
<RAOF> :)
<cnd> I've already devoted too much time to autotools this past week...
#ubuntu-x 2012-03-15
<RAOF> I'll see if I can whip something up.
<cnd> RAOF, that would be cool
 * RAOF gets frustrated with technology and goes to get some food.
<bryceh> RAOF, hah I just had the exact same thought
<cnd> anyone know how to see a diff of a whole file
<cnd> i.e. with all context
<cnd> bzr diff that is
<cnd> got it
<cnd> --diff-options "-U -1"
<cnd> RAOF, do you have an idea of when you might be able to turn around a makefile snippet?
<cnd> this is all a dependency for fixing utouch tests
<cnd> which badly need xorg-gtest to work again :)
<RAOF> Aaah :)
 * RAOF fires up emacs.
<cnd> RAOF, if it's a day or two, then that's not a problem
<cnd> otherwise, I think we need to figure out a contingency plan
<RAOF> Shouldn't be that long.
<cnd> ok
<cnd> in the meantime, I'm manually installing libgtest-dev_1.6.0-1ubuntu1 :)
<broder> hmm, tap-to-click seems to keep getting turned on when i boot up, even though the setting is off. if i open the capplet and toggle the setting on and off, then i stop getting tap-to-click. what should i file a bug against?
<tjaalton> broder: gnome-settings-daemon is my bet
<broder> hmm, yeah. i think you're right. i don't see a bug in the code, though. bah
<Sarvatt> broder: do you have a clickpad?
<Sarvatt> synclient -l | grep ClickPad
<broder> Sarvatt: no
<broder> "SynPS/2 Synaptics TouchPad"
<Sarvatt> broder: yeah a synaptics clickpad I meant, i just noticed ClickPad=1 seems to unconditionally enable tap to click
<broder> it's not a clickpad, and synclient isn't identifying it as one
<Sarvatt> oh you use older releases don't ya
<broder> i'm actually on precise finally :)
<broder> (and i'm in the process of upgrading the product i work on at work to oneiric, so i'll be totally off the unreasonably old releases)
<Sarvatt> broder: is the g-s-d mouse plugin enabled? i had it (along with xrandr and xsettings) mysteriously get disabled a few times on package upgrades
<Sarvatt> org/gnome/settings-daemon/plugins/mouse in dconf-editor
<broder> yep, it's active
<broder> turning tap-to-click on and then back off in gnomecc seems to fix it until the next reboot
<seb128> Sarvatt, I doubt it's on upgrade
<seb128> Sarvatt, did you ever run unity-greeter in your session?
<seb128> Sarvatt, it does that for you, those plugins are disabled in the greeter, and when run in your session they disable them for your user
<Sarvatt> seb128: does --test-mode count?
<seb128> yes
<Sarvatt> yep indeed that was the problem then!
<Sarvatt> thanks, was really stumping me why it happens
<seb128> "known bug" ;-)
<seb128> yw
<seb128> it took me a while to figure as well
<broder> ...huh. tap to click actually seems to have gotten turned back on, possibly when my screensaver activated
<broder> nope, it just gets turned on intermittently
<bryceh> cnd, see this?  http://www.youtube.com/watch?v=vOvQCPLkPt4
<FernandoMiguel> evening
<cnd> bryceh, yeah, MS has been talking about improving touch performance for a little bit now
<cnd> maybe 6 months
<cnd> they're working closely with the makers of the panels
<bryceh> mm
<cnd> hopefully we'll benefit from it too :)
<tjaalton> hm, apport opened chromium for some reason, firefox is the default..
<tjaalton> x-www-browser points to chromium for some reason, but apport should use xdg-open
<bryceh> tjaalton, hmm according to apport/NEWS, it started using xdg-open around 1.24 (2011-10-19)
<bryceh> wonder if it's something lower down like in launchpadlib?
<tjaalton> could be, filed a bug about it just in case
<tjaalton> seems that ubuntu-bug ends up using xdg-open, but the crash reporter doesn't
<bryceh> hmm, is that evand's crash reporter code?
<tjaalton> whoopsie? maybe
<tjaalton> it's just the daemon?
<bryceh> more ubuntu wayland hand wringing on moronix
<bryceh> they suddenly expect that end users should be able to transition off X11 to wayland in 12.10?
<RAOF> Totally possible!
<RAOF> As long as the users aren't particularly demanding.
<RAOF> :)
<FernandoMiguel> someone recall me what wayland is 
<bryceh> FernandoMiguel, it's unicorns and rainbows
<FernandoMiguel> ah those
<bjsnider> replacement for xorg
<bryceh> FernandoMiguel, less snarkily, Wayland is a 3D display server as opposed to X which is 2D with 3D bolted on.  A lot of people got  their hopes up very early on that it would "replace X".  But there's still a long way to go, and it irritates me to see phoronix teasing people with what we're (at the moment not) doing in Ubuntu
<FernandoMiguel> ack
<RAOF> There's quite a lot of work that'll need to be done before it's ready to "replace X".  Where by "replace X" we mean "run X clients in their own X server, and wayland clients alongside them".
 * RAOF is still interested in turning lightdm into a wayland compositor and running an X server under it, though.
<eruditehermit> Sarvatt, hey, are you about?
<bryceh> RAOF, certainly that would be one way to eliminate our login corruption bug.  ;-)
<RAOF> With all sorts of new and exciting corruption bugs possible!
<bryceh> out with the old bugs, in with the new!
<FernandoMiguel> and in the mean time make LP team get paid 
<FernandoMiguel> nite
#ubuntu-x 2012-03-16
<cr3> hi folks, the mouse is excruciatingly slow after starting ubuntu but seems to behave a few minutes later. does this sound like a problem with X?
<mona-x> Sarvatt: i have a reproducible way of crashing X (xserver-xorg 1:7.6+7ubuntu7.1 from xorg-edgers). I need yet to narrow it down (it happens when I start firefox which has a lot of open tabs from last session, but it seems like restoring/reloading one specific tab triggers it). what's the best way to report this? I assume I cannot use apport/reportbug since this is not an official package?
<mona-x> oops, actually this is an official package
<mona-x> well, i got to go, sorry...
<bryceh> cr3, there's been some changes in the input later the last couple months but I'd probably suspect the kernel first for something like that.  If you remember when you first started noticing it, boot a kernel from prior to that and see if it goes away.
<cr3> bryceh: I've only been running Precise for a couple weeks, is that prior to the changes?
<Sarvatt> sounds like the external outputs are being polled like a madman at startup like that bug from oneiric
<bryceh> cr3, no there haven't really been many serious changes to the X stack the last couple weeks
<bryceh> Sarvatt, could be
<cr3> Sarvatt: is there a workaround I need to apply or should I expect this to be fixed shortly?
<cr3> the problem is not so crippling, just not something I'd like to see endusers confronted with
<Sarvatt> can you file a bug first? we can't tell without one :)
<cr3> Sarvatt: ubuntu-bug kernel?
<Sarvatt> ubuntu-bug xorg
<cr3> Sarvatt: will do
<bryceh> cr3, it's not likely to be a widespread bug
<bryceh> (else we'd have gotten more bug reports lately)
<bryceh> Sarvatt, wasn't that a displayport-related bug?  My memory's getting a bit vague on that
<cr3> bryceh: this is a fresh install on a ThinkPad X200, so no display port in this case
<bryceh> Sarvatt, will those probe pollings show up in Xorg.0.log or does he need to flip on drm.debug?
<Sarvatt> phantom hdmi on some lenovo laptop i think, it was worked around in g-s-d in oneiric though and the bad interactivity at startup should be gone
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/855124
<ubottu> Launchpad bug 855124 in Linux "XRANDR operations very slow unless (phantom) HDMI1 disabled" [High,In progress]
<Sarvatt> it was g-s-d probing it like crazy at startup and every probe killed desktop interactivity i believe
 * cr3 reported bug #957298
<ubottu> Launchpad bug 957298 in xorg (Ubuntu) "Mouse is very slow after starting a session on Precise" [Undecided,New] https://launchpad.net/bugs/957298
<bryceh> cr3, had you had an older ubuntu on the system previously?
<bryceh> hah you do have displayport
<bryceh> mm, gpu lockups
<bryceh> actually, not a lockup.  EQ overflowing is probably a symptom of the lagging
<cr3> bryceh: the laptop was running lucid before, I was only running oneiric in a vm, so I couldn't tell you whether this is a regression (even though I checked the regression checkbox)
<bryceh> Sarvatt, not spotting evidence of excessive output polling in the Xorg.0.log
<bryceh> and xrandr.txt not showing any phantom outputs left connected
<bryceh> cr3, but one thing you could try is to set up an xorg.conf with snippets like this:
<bryceh> Section "Monitor"
<bryceh>         Identifier "HDMI1"
<bryceh>         Option "Ignore" "True"
<bryceh> EndSection
<bryceh> do that for each port in your 'xrandr' output that you're not using
<bryceh> if Sarvatt's right, then that should make it stop.
<cr3> bryceh: how can I create the base xorg.conf?
<bryceh> See https://wiki.ubuntu.com/X/Config for an example
<bryceh> cr3, you can omit the Driver line
<cr3> bryceh: sudo Xorg -configure returns a fatal error, am I supposed to run that from the console before logging in?
<cr3> bryceh: or did you mean I should just put those monitor sections under /usr/lib/X11/xorg.conf.d/?
<bryceh> cr3, no, scroll down to the Quick xorg.conf section, cut and paste that and delete the Driver line
<cr3> bryceh: ah, my bad, didn't realize it was that simple :)
<cr3> brb
<Sarvatt> actually you may want to go /org/gnome/settings-daemon/plugins/xrandr in dconf-editor and try unchecking it and restarting
<Sarvatt> bryceh: he's on the kernel with the phantom output probing time fix :(
<bryceh> Sarvatt, yeah didn't spot evidence of that type of bug from the logs
<cr3> bryceh: works! I updated the bug with the workaround you provided
<bryceh> huh
<Sarvatt> oh fun
<bryceh> cr3, alrighty, well we definitely know how to fix this type of bug
<cr3> bryceh: sweet, as long as your definition of fix is not creating an xorg.conf file :)
<bryceh> cr3, hey one more favor - can you take another look at the wiki.ubuntu.com/X/Config page and see if the layout is clearer now?
<bryceh> cr3, nope, it needs a quirk to the kernel
<cr3> bryceh: definately clearer, the sudo Xorg -configure command might detract people when it would fail
<bryceh> yeah, that's totally borked.  Was playing with it yesterday.
<bryceh> for some reason Xorg -configure generates an xorg.conf that assumes there's a monitor on every probable output and configures them all.
<cr3> bryceh: heh, that's likely to happen :)
<cr3> bryceh: feel free to ping me again when the quick in the kernel is fixed, I could remove my xorg.conf file and provide feedback
<cr3> s/quick/quirk/
<bryceh> cr3, I posted a few more questions to the bug, that need answered first
<bryceh> cr3, namely, try individually enabling each output and see which one(s) must be disabled to make the issue go away
<bryceh> also, test a docking station if you have it
<cr3> bryceh: yeah, just answered, you'll have to wait until I finish some work to test rebooting a few times :)
<bryceh> no prob
<FernandoMiguel> evening
<bdmurray> bryceh: could you look at http://ubuntuone.com/2BsjpXA9nDVB1ZGd8FK646?
<bryceh> looking
<bdmurray> the is some "corruption" in the audacious window and right above the terminal
<bryceh> wow, 3D text console
<bdmurray> I think its out of focuse ;-)
<bryceh> made a nice raised text effect ;-)
<bdmurray> right below "Ever Neve" you can see what I'm talking about
<bryceh> bdmurray, so, looks like no content retrieved for that particular attachment?
<bdmurray> I'm concerned about the visual corruption of my windows
<bryceh> anything unusual about the bug in question?  private or deleted attachment or something?
<bdmurray> this is the X channel right?
<bryceh> oh, the white bar on the bottom?
<bdmurray> ;-)
<bdmurray> the green line with dots around it
<bryceh> aha, helps to zoom out
<bdmurray> oh heh
<bryceh> bdmurray, so looks like a fairly standard graphics corruption issue
<bryceh> could likely be a driver bug.  Else might be compiz or even the app.
<bdmurray> it happens with lots of apps
<bryceh> ok, then that rules out app issue
<bryceh> I've seen plenty of corruption issues like this before, but I don't think I've seen one reported recently
<bryceh> if it can be repro'd in gnome shell or classic gnome (no effects), then that would absolve compiz
<bryceh> bdmurray, when did it start doing this?
<bryceh> bdmurray, and does it always happen or is there some steps to make it reproduce?
<bdmurray> I don't have good steps to recreate it, it may have started last week
<bryceh> booting a kernel from prior to last week might be useful then
<bryceh> there haven't been any major changes to mesa lately, just a couple probably unrelated things, however mesa is sometimes to blame for these kinds of problems.  Last major update was 8.0.1 on Feb 23rd
<bdmurray> okay, thanks for looking
<bryceh> bdmurray, which driver is this?  -intel?
<bdmurray> bryceh: radeon
<bryceh> interesting
<bryceh> bdmurray, I'm not seeing it on my radeon, but I've not updated in a bit.  I should do so...
#ubuntu-x 2012-03-17
<Sarvatt> ricotz: sheesh, wayland/weston are broken again ALREADY?
<Sarvatt> looks like it needs a newer libxkbcommon
<ricotz> tjaalton, ping
<tjaalton> ricotz: pong
<ricotz> tjaalton, hi :)
<ricotz> there is a problem with the internal package deps of mesa
<tjaalton> how so?
<ricotz> libegl1-mesa-dev should depend on libegl1-mesa-drivers
<ricotz> after moving libwayland-egl and libEGL the symlinks are broken without *-drivers
<tjaalton> which symlinks?
<ricotz> lrwxrwxrwx 1 root root 18 MÃ¤r 16 22:46 /usr/lib/x86_64-linux-gnu/libEGL.so -> mesa-egl/libEGL.so
<ricotz> lrwxrwxrwx 1 root root 26 MÃ¤r 16 22:46 /usr/lib/x86_64-linux-gnu/libwayland-egl.so -> mesa-egl/libwayland-egl.so
<ricotz> tjaalton, you made these last changes to mesa ;)
<tjaalton> hate hate hate
<ricotz> tjaalton, if you are going to fix this, please upload a wayland update before it to which removes the hard-deps creation
 * ricotz hopes this wasnt directed too me
<tjaalton> no, mesa..
<tjaalton> well, the mesa-*/ mess
<ricotz> yeah, what is the point of moving them into "mesa-egl"?
<ricotz> i guess nvida-tegra?
<ricotz> *nvidia-tegra
<tjaalton> something like that
<ricotz> ok
<ricotz> tjaalton, are you ok with uploading wayland in front?
<tjaalton> sure
<ricotz> thanks
<tjaalton> so the dep on drivers should be on debian too, as far as I can tell
<tjaalton> ricotz: do you mind me asking why do you care?
<tjaalton> i'll just throw this in git
<ricotz> building with wayland-egl is broken otherwise if you dont manually depend on *-drivers
<tjaalton> yeah but what needs wayland-egl?
<ricotz> this hard-dep caused by wayland only creates issues imo, and doesnt serve any good while there is nothing using it in the archive
<ricotz> i am building some packages with enabled wayland-backends
<ricotz> like gtk, cogl, clutter
<ricotz> still a lot wip upstream
<ricotz> but it seems to be shapen up, and running mutter/g-s on wayland doesnt seem impossible currently
<tjaalton> so.. why does wayland need a rebuild?
<ricotz> http://anonscm.debian.org/gitweb/?p=pkg-xorg/wayland/wayland.git;a=commitdiff;h=02570597e9c232c748fbb61932da21f21baf5b80;hp=136915fbd44feff7074270f3b518c1afbdc450fb
<tjaalton> hah, thought that was in the archive already
<tjaalton> wayland uploaded, mesa can wait
<ricotz> mesa needs to wait until wayland is finished of course
<ricotz> tjaalton, but you need to push a mesa update too to unbreak the archive afterwards
<ricotz> when wayland got published mesa and wayland wont be installable
<tjaalton> fair enough, uploaded
<tjaalton> grr
<tjaalton> mesa git didn't get updated, 0ubuntu4 is missing
<tjaalton> so the upload was rejected
<tjaalton> bryceh: mind pushing mesa to git?-)
<tjaalton> wait, it'll fail
<tjaalton> bryceh: just force push it, I'll merge the changes on top of it..
<tjaalton> wayland can be uninstallable for a few days, no one will notice :)
<Sarvatt> wayland uninstallable? its mesa thats broken right now
<tjaalton> huh?
<Sarvatt> The following packages will be REMOVED:
<Sarvatt>   glmark2-es2 libegl1-mesa libegl1-mesa-dev libegl1-mesa-drivers libgles1-mesa-dev
<Sarvatt>   libgles2-mesa-dev libkwinglesutils1 libopenvg1-mesa-dev mesa-utils-extra
<tjaalton> ffs
<tjaalton> this calls for some whisky
<tjaalton> bryceh: nevermind, I'll merge -0u4
<tjaalton> that was quick.. now what
<Sarvatt> it just needed the libegl1-mesa-drivers dep and a rebuild against the newer wayland that doesn't generate hard dependencies
<tjaalton> right, blissfully forgot about all that
<Sarvatt> tjaalton: thanks a ton for doing all that headache
<Sarvatt> it would have been a LOT more disruptive on a weekday
<tjaalton> i've nothing else to do either, despite st paddy's day :)
<ricotz> tjaalton, thanks!
<ricotz> Sarvatt, that was my thinking too
<Prf_Jakob> ss/win 17
<FernandoMiguel> olÃ¡
<ricotz> tjaalton, it seems to be time for libwacom in debian
<ricotz> tjaalton, you might have unpushed changes locally too
<tjaalton> ricotz: i did. need to merge -0u3 too
<ricotz> tjaalton, ok, mbiebl was asking when this can hit debian
<tjaalton> oh it's at -0u4 already
<tjaalton> well, I could put it in collab-maint then
<tjaalton> or pkg-xorg
<ricotz> great, whatever you like
<bryceh> tjaalton, ah sorry about that
#ubuntu-x 2012-03-18
<Sarvatt> bryceh: how do you feel about cedarview BS in multiverse for 12.04? we have drivers, they only work on i386 and only with unity 2D, and any kind of GL crashes the system. I whipped up packaging in a few hours the other day and don't want this crap to be private since someone can possible benefit from it but not sure it makes sense in the archive given all the limitations and lack of support (it'll never work in 12.10 when we do xserver 1.13, the int
<Sarvatt> el group caring about it for the LTS is guranteed never to care)
<Sarvatt> not sure if it makes sense to push it into 12.04 at this point, i feel like a PPA would be better since we'll get bugs that cant be fixed
 * Sarvatt feels sorry for anyone buying these things, at least most manufacturers outside of asus and HP were smart enough to drop netbooks this generation until atom uses ivybridge gpus next generation
<Sarvatt> libwsbm is already in precise for it, outside of this there are 3 packages for the drm driver, userspace X/3D drivers and vaapi drivers but i'm torn on pushing it into 12.04 directly. they are just gong to build up bugs we can't fix.
<Prf_Jakob> ssss/win 17
<bjsnider> Sarvatt, intel didn't produce a good driver for that hardware?
<Sarvatt> its intel UMG not the open source guys, no of course not :)
<bjsnider> ok
<Sarvatt> its 32 bit only even in windows even though the cpu supports x64 fine
<bjsnider> depending on the ram it may not need the addressing space
<Prf_Jakob> Its no the extra addressing space but the 8 extra regs that are nice.
<Sarvatt> Prf_Jakob: any benefit to running the tech preview or did it just fix auto-install stuff on 12.04?
<Sarvatt> there was a internal discussion on it and people thought they needed to update to that to try the 3D stuff which absolutely isn't true, just the option they had to enable was not obvious
<Sarvatt> one person said they were presented with a dialog that it only worked for windows guests that i've never seen
<Sarvatt> anyway st patty's day, off to enjoy whats left of it :)
<Prf_Jakob> Sarvatt: the tp is faster but not needed.
<tjaalton> bryceh: no problem, and tbh I did notice the upload but forgot to remind you to push the changes, so my bad :)
<bryceh> Sarvatt, I guess the important thing is avoiding implying that the codebase is being actively maintained by the ubuntu-x guys
<tjaalton> hm, compiz crashed with the intel_miptree_release() error when starting terminator
<FernandoMiguel> night
#ubuntu-x 2013-03-11
<Sarvatt> ricotz: any interest in updating llvm-3.3 or shall i disable r600 shader compiler and radeonsi in edgers?
 * Sarvatt votes disabling those two but you seem interested in keeping that going :)
 * RAOF would be much more interested in radeonsi if you could use it on the X servers > 1.12
<tjaalton> RAOF: what's the blocker?
<RAOF> tjaalton: It needs glamour to do any acceleration, and that doesn't work on > 1.12.
<tjaalton> huh, ok
<RAOF> DDX acceleration built on *GL: a better idea in theory than in practice âº
<RAOF> At least the history of the various attempts seems to suggest that.
<tjaalton> yeah
<Sarvatt> sounds like there will be an xa based ddx for f19 so it might be usable in the distant future :)
<Sarvatt> definitely 0 point in shipping radeonsi in the meantime
<tjaalton> well, it's there already
<mlankhorst> hm didn't know that, might as well get rid of the craziness then
<mlankhorst> but doesn't r600 use the llvm backend too?
<mlankhorst> so maybe disable radenosi for now as it only increases package size, but keep llvm
<tjaalton> increases by how much?
<mlankhorst> -rw-r--r-- 1 root root 1,3M jan 24 10:52 radeonsi_dri.so
<tjaalton> hmm k
<tjaalton> so nuke it
<mlankhorst> \o/
<mlankhorst> oh that's still old one, I'd have to recheck on 9.1
<mlankhorst> I guess I got better at it, only 260k ish there
<tjaalton> uploading -intel 2.21.4
<seb128> tjaalton, \o/
<seb128> it should fix those image corruption issues ;-)
<tjaalton> yeah, it has that fix :)
<tjaalton> although I forgot to close it on the changelog
<keldwud> hmm, bug report first?
 * keldwud thinks about it :)
<keldwud> yeah, I don't have enough information to file a bug report according to the specifications in the topic link. I will try and gather more information first.
<keldwud> thin I found my bug, probably not related to this channel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793
<ubottu> Launchpad bug 887793 in Linux "Kworker constantly taking about 100% CPU" [Medium,Confirmed]
<keldwud> sorry for the false alarm :)
<tomreyn> tjaalton: "that fix" = CVE-2013-0913 / https://lkml.org/lkml/2013/3/11/501 ?
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0913)
#ubuntu-x 2013-03-12
<kees> tomreyn: final version appears to be: https://lkml.org/lkml/2013/3/11/677
<tomreyn> thanks
<tjaalton> tomreyn: huh?
<tomreyn> <tjaalton> uploading -intel 2.21.4
<tomreyn> <tjaalton> yeah, it has that fix :)
<tomreyn> ... is what i was referriing to
<tjaalton> no
<tjaalton> that was not the kernel..
<tomreyn> okay thanks
<RAOF> tjaalton, Sarvatt: Sounds like glamor works for 1.14 & 1.13.x; we should keep radeonsi enabled in -edgers.
<tjaalton> RAOF: oh cool
<tjaalton> we still have it on raring too
<tjaalton> but glamor needs an update?
<tjaalton> hum, is it even in the archive?
<tjaalton> what a mess :P
<RAOF> tjaalton: Nope, not in the archive; that needs to be done ):
<RAOF> :)
<mlankhorst> ooh fun
<mlankhorst> could it be made part of the xorg group?
<tjaalton> i recently got an unreleased 8xxx series card, but it's not even si-based.. duh
<tjaalton> el cheapo series
<mlankhorst> :>
<tjaalton> was disappointed for not being able to test this stuff.. even to just notice it's "utter failure" or whatever phoronix calls it this week
<mlankhorst> hahah
<tjaalton> mlankhorst: yeah it probably makes sense under pkg-xorg
<mlankhorst> yeah if it does get MIR'd, I'll ask to get pixman and all the blob packages in the xorg package list too :)
<tjaalton> oh that list, right
<mlankhorst> but ok when you checked the race condition I'll upload xorg-server 1.13.3 :)
<mlankhorst> brb
<tjaalton> well, at least the git version doesn't break anything here
<tjaalton> although if you need the race case tested then yes, within the next hour
<mlankhorst> Lies!
<tjaalton> hah
<tjaalton> soon
<tjaalton> disabled swap and eth0 bridge so it's actually able to hit it
<mlankhorst> it should show something in the xorg log if you do hit it
<tjaalton> first I'll try with the current one
<tjaalton> mlankhorst: ok, I have the current package obviously doing something there, now trying the new one
<tjaalton> ooh, reproduce the race with it
<tjaalton> +d
<mlankhorst> does it survive?
<tjaalton> no
<mlankhorst> ah boo, logs?
<tjaalton> low-graphics mode
<tjaalton> http://pastebin.com/ebwTGe1C
<tjaalton> here's the previous one http://pastebin.com/yRpBX0jA
<mlankhorst> it's happy about it though
<mlankhorst> afaict
<mlankhorst> so where does it go wrong? :S
<tjaalton> beats me
<mlankhorst> can you paste correct log too?
<tjaalton> with this kernel?
<tjaalton> um, xserver
<mlankhorst> sure 
 * mlankhorst has the feeling it fails somewhere else in a similar fashion
<tjaalton> this matches my old tests, so there's nothing new
<mlankhorst> [     5.162] (II) intel(G0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen <tjaalton@ubuntu.com>)
<mlankhorst> is it a hybrid?
<tjaalton> no
<tjaalton> ivb sdp
<tjaalton> the package is from the archive
<tjaalton> here's a working one http://pastebin.com/kYRdDYv4
<mlankhorst> it's saying G0 though
<mlankhorst> which is weird
<mlankhorst> iirc that was graphics offload
 * mlankhorst rechecks
<tjaalton> just (0) with the working one
<mlankhorst> yeah but what is it trying to bind to..
<mlankhorst> [     4.779] (==) Matched intel as autoconfigured driver 0
<mlankhorst> [     4.779] (==) Matched intel as autoconfigured driver 1
<mlankhorst> o.O
<mlankhorst> oh well, both have that
<tjaalton> when it fails plymouth doesn't have a chance of showing the splash, it's showing vt1 instead
<tjaalton> but still would like to try with it disabled, can't remember what to put on cmdline
<tjaalton> removing splash isn't enough
<tjaalton> plymouth.enable=0, maybe
<mlankhorst> tjaalton: what if you remove the drmSetMaster call from plymouth? :p
<mlankhorst> it will probably fail
<mlankhorst> just checking if the race is gone then
<tjaalton> I'll try without plymouth a few times, first was successful
<mlankhorst> or something like in activate if (!ply_terminal_is_active (backend->terminal)) return;
<mlankhorst> probably src/plugins/renders/drm/plugin.c or something
<mlankhorst> that should hopefully be enough to prevent it from stealing master
<tjaalton> ha, failuer
<tjaalton> -re
<mlankhorst> when
<tjaalton> [     4.765] drmSetMaster failed with -1(Operation not permitted)
<tjaalton> without plymouth
<mlankhorst> o.O
<tjaalton> http://pastebin.com/HzXGPRMS
<mlankhorst> oh duh
<mlankhorst> drmsetmaster doesn't return err code
<mlankhorst> tjaalton: pushed new version
<mlankhorst> my guess is it will fail with -EINVAL, lets see >:X
<mlankhorst> I'm hoping for -EINVAL, in fact
<mlankhorst> if so, I'll ask you to test a kernel patch
<tjaalton> building
<tjaalton> bah, plymouthd _was_ still running, I'll disable it harder
<mlankhorst> that's fine, I just want that error again :P
<tjaalton> alright
<tjaalton> [     4.901] drmSetMaster failed with 22(Invalid argument)
<mlankhorst> yay
<mlankhorst> let me grab the raring kernel
<tjaalton> guess I need it too?-)
<tjaalton> oh I have it..
<mlankhorst> is a .patch good enough?
<tjaalton> yep
<mlankhorst> tjaalton: http://paste.ubuntu.com/5607392/
<mlankhorst> blergh should probably have fixed it, missing fops_put(old_fops); ah well
<mlankhorst> wont be able to load drm module :p
<tjaalton> the last hunk failed to apply
<mlankhorst> I'll try 3.8 ish
<mlankhorst> applies cleanly against 3.8.0 here
<mlankhorst> http://paste.ubuntu.com/5607407/
<tjaalton> not -12.21
<mlankhorst> is that 3.8 kernel?
<tjaalton> yep
<tjaalton> maybe .2 or such
<mlankhorst> I'll try v3.8.x branch then
<mlankhorst> still applies cleanly o.O
<mlankhorst> just apply with hand, it's a small patch
<mlankhorst> idea is that f_op gets replaced only once, and not reset on failure
<mlankhorst> and then it drops drm_global_mutex before calling f_op->open
<mlankhorst> drm_open re-takes global_mutex to prevent races
<tjaalton> hah
<tjaalton>     UBUNTU: SAUCE: drm -- stop early access to drm devices
<tjaalton> that's a nearly three year old patch..
<tjaalton> why it didn't apply
<tjaalton> mind reviewing that one?
<mlankhorst> zap it
<mlankhorst> this solution *should* work better
<tjaalton> and apply yours?
<mlankhorst> yeah
<tjaalton> k
<tjaalton> wonder if that patch is what's causing the race in the first place..
<mlankhorst> nah it's a fail attempt to work around it
<mlankhorst> then again maybe
<mlankhorst> though I would expect open to fail in that case with -EAGAIN
<tjaalton> don't recall having this bug before maybe a year ago
<mlankhorst> I think it would still fail with that workaround because it's not complete
<mlankhorst> just taking global mutex seems to be a reasonable fix :p
<mlankhorst> it could otherwise return the second open call before firstopen is called in drm
<tjaalton> building
<mlankhorst> hm or worse, possibly before load finishes
<mlankhorst> only it wouldn't happen on first open, but if 2 devices open in parallel, like xorg and plymouth
<mlankhorst> first one would nicely block on global_mutex, second one would race ahead without any locking at all
<tjaalton> hmm no kms on vt
<mlankhorst> o.O
<mlankhorst> drm failed to load?
<tjaalton> no it was fine
<tjaalton> second boot, kms fine, vt change and the mouse cursor follows :)
<tjaalton> and can't find the greeter again
<tjaalton> restart lightdm and it's fine
<tjaalton> ha, failure
<mlankhorst> was afraid of that, meh :/
<tjaalton> mlankhorst: same as before
<mlankhorst> still -EINVAL?
<tjaalton> yep
<mlankhorst> on setmaster right?
<tjaalton> [     4.856] (II) config/udev: Adding drm device (/dev/dri/card0)
<tjaalton> [     4.856] drmSetMaster failed with 22(Invalid argument)
<tjaalton> [     4.861] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64
<mlankhorst> was afraid of that
<mlankhorst> tjaalton: could you add a printk to drm_setmaster_ioctl to find out which exactly it triggers on?
<tjaalton> where?
<mlankhorst> drm_stub.c
<mlankhorst> I'm hoping it's complaining about file_priv->minor->master, in which case I should revive the first part of bryce's attempt
<tjaalton> building
<mlankhorst> or better yet, plymouth should not call drmsetmaster and just bug out early if it didn't get master, it lost to xorg-server :P
<tjaalton> or just wait for the system compositor..
<mlankhorst> http://paste.ubuntu.com/5607513/
<mlankhorst> could you try that?
<tjaalton> so not the printk stuff?
<mlankhorst> could keep it, but this is for plymouth to not take master if not on active vt
<mlankhorst> at least, I guess it works like that
<tjaalton> mlankhorst: didn't try the plymouth patch yet, but the failing check was "if (file_priv->minor->master)"
<mlankhorst> good, plymouth one is probably the fix
<mlankhorst> I hope
<tjaalton> funny that it follows the same pattern. first boot I get the cursor-on-vt issue, second one is fine, third one fails
<tjaalton> fails with failsafe (hah)
<mlankhorst> resetting or full power off?
<tjaalton> reset
<tjaalton> mlankhorst: nope, still failed
<mlankhorst> I guess I'll revive the spin patch on setmaster then
<mlankhorst> pushed
<mlankhorst> tjaalton: can you retest xorg-server with the patch refreshed patch?
<tjaalton> building
<tjaalton> hm, it's probably not normal that on nearly every boot I have dmesg full of ext4_orphan_cleanup
<tjaalton> ..messages
<tjaalton> [     4.888] (II) config/udev: Adding drm device (/dev/dri/card0)
<tjaalton> [     4.888] (II) spinning!
<tjaalton> [     5.111] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64
<tjaalton> works
<mlankhorst> \o/
<mlankhorst> now reset the rest to previous state, and see if it still works?
<mlankhorst> eg default plymouth and kernel
<tjaalton> yep
<mlankhorst>  * radeon_driver_firstopen_kms - drm callback for last close
<mlankhorst> void radeon_driver_lastclose_kms(struct drm_device *dev)
<mlankhorst> :D
<tjaalton> works
<tjaalton> now I have the mouse cursor on top of a vt (blinking cursor on top-left), heard the bongos
<tjaalton> it didn't spin, but the intel driver spent half a second on "something"
<tjaalton> [     4.950] (++) using VT number 7
<tjaalton> [     5.451] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen <tjaalton@ubuntu.com>)
<mlankhorst> could it be plymouth? :P
<tjaalton> could, I enabled it again
<tjaalton> booted fine a couple of times
<mlankhorst> presumably plymouth shouldn't attempt to attach if xorg-server ended up starting
<mlankhorst> could you try with the plymouth patch?
<tjaalton> now I just got a blank screen
<mlankhorst> fun :/
<tjaalton> root      1638  1339  0 15:21 ?        00:00:00 plymouth --ping
<tjaalton> plymouth doesn't exit
<mlankhorst> can you attach to plymouthd, see if it's stuck on something?
<tjaalton> [+0.01s] DEBUG: Waiting for ready signal from X server :0
<tjaalton> [+0.01s] DEBUG: Stopping Plymouth, no displays replace it
<tjaalton> from lightdm.log
<tjaalton> ply_terminal_deactivate_vt
<tjaalton> http://pastebin.com/C9wvXrF9
<tjaalton> I need to run ->
<mlankhorst> boo it needs debug symbols
<mlankhorst> oh that's from lightdm
<mlankhorst> blargh I need some way to reproduce this if I want to fix it :/
<mlankhorst> boooo this one's too slow
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=62198 gen3 possibly messed up in x-x-v-intel 2.21.4 if anyone comes across corruption bugs on them
<ubottu> Freedesktop bug 62198 in Driver/intel "x11-drivers/xf86-video-intel-2.21.4 and transparency" [Normal,Reopened]
<tjaalton> i'll check it out
<tjaalton> or maybe not
<tjaalton> forget 965gm is gen4
<mlankhorst> my eee is gen 3 :P
<mlankhorst> I'll test tomorrow
<Sarvatt> Duke`_: probably what you're hitting
<Duke`_> hum the last two updates seems ok for me
<Duke`_> I remember having a glxgears with transparent background, instead of black
<Duke`_> ok, I just installed 2.21.4, going to reboot
<Sarvatt> Duke`: ah sorry, another bug then
<Sarvatt> i updated edgers right after you complained in case it was a transient bug, so much changes every day and i hadn't for a week
<Duke`> eh ;)
<Duke`> the 20130301 version was terrible, X totally broken
<Duke`> black screen and it was hard to switch to a VT
<burp> dear ubuntu-x people
<burp> nvidia-current 304.84 in the precise ubuntu-x-swat PPA depends on xserver-xorg-core
<burp> but the new https://wiki.ubuntu.com/Kernel/LTSEnablementStack depends on xserver-xorg-core-lts-quantal
<burp> so they can't be readily installed together
<burp> (and maybe shouldn't :)
<burp> I haven't been able to find any more information on this
<burp> except these gentlemen on askubuntu who ran into the problem: http://askubuntu.com/a/257889
<burp> will ubuntu-x-swat stick with the current situation, or are there plans for compatibility with the LTSEnablementStack?
<jcristau> what does the lts stack buy you if you're using nvidia's driver anyhow?
<burp> I'm not sure yet. :)
<burp> but currently if you install bumblebee on a 12.04.2 system, X doesn't startup anymore
<burp> that would be reason #1 to clear things up
<burp> also, bumblebee systems have Intel graphics as wel
<burp> l
<burp> (the LTSEnablementStack seems to be default on new 12.04.2 installs. I just got burned by this problem.)
<Sarvatt> sudo apt-get install xserver-xorg-lts-precise :)
<bryce> yeah bumblebee should probably update their depends
<Sarvatt> that'll downgrade you back to the older stack
<burp> it's not bumblebee
<burp> bumblebee only depends on nvidia-current
<burp> but nvidia-current depends on xserver-xorg-core
<burp> is there no solution possible where the enablement stack is also supported?
<tjaalton> don't use the ppa?
<burp> one needs the PPA if one has a NVIDIA 7xx no?
<burp> (this laptop has NVIDIA GeForce 710m)
<bryce> burp, ah.  mlankhorst was working on getting that resolved.  Check with him.
<tjaalton> well there are other versions available on precise
<tjaalton> if bumblebee depends on nvidia-current then fix that
<Sarvatt> the nvidia driver is whats messed up in the ppa
<tjaalton> sure
<tjaalton> but why use the ppa?
<Sarvatt> bjsnider: ya didnt pick up tseliot's recent packaging changes it looks like
<Sarvatt> because newer blob drivers actually are worth upgrading to? :P
<tjaalton> and there's nvidia-310, no?
<Sarvatt> 304.84 is still newer
<tjaalton> probably doesn't matter for this hw?
<burp> so should I not want to install the latest nicely packaged nvidia binary drivers on this Ivy Bridge i7 with NVIDIA GeForce 710m in Optimus configuration?
<Sarvatt> it fixes a kde logout problem, xrandr rotation, and speeds up font rendering, perfectly valid reasons to want to update it..
<burp> It felt like a logical thing to do at the time.
<tjaalton> ok then, so wait for it to get fixed :)
<burp> :)
<Sarvatt> thanks for the heads up it was broken
<burp> I should probably double-check if it has been reported and if not report it, no?
<Sarvatt> burp: nah its not a distro bug, reporting it here was right :)
<burp> ok great thanks!
<Sarvatt> bjsnider: patch incoming for fixing the precise blob depends
<Sarvatt> bjsnider: http://paste.ubuntu.com/5608946/
<Sarvatt> burp: just uploaded it, should be up in a few hours
<burp> wow, that's awesome, thank you very very much!
<bjsnider> Sarvatt, is it just in precise?
<mlankhorst> bjsnider: it's only needed for precise, unless you want to backport the enablement stack to quantal ;)(
<Sarvatt> bjsnider: yeah, its a pain in the rear i know :(
<mlankhorst> but you could probably harmlessly sync those changes back to later
<Sarvatt> could just make them all except precise then make the precise at the end slapping that patch on though
<Sarvatt> mlankhorst: except he's still doing lucid blobs even :)
<mlankhorst> o.o
<Sarvatt> would need to extend the number of abis it provides
<mlankhorst> not for much longer?
<bjsnider> burp, you have which chip?
<bjsnider> i can't find a record of that one
<Sarvatt> bjsnider: rebadged 620m
<burp> http://www.notebookcheck.net/NVIDIA-GeForce-710M.84746.0.html
<bjsnider> he shouldn't be using the ppa then
<bjsnider> too new
<bjsnider> only geforce 6k/7k hardware
<burp> I shouldn't?
<Sarvatt> burp: does it work? :P
<burp> hehehe
<burp> it seems to!
<burp> I'm only just installing the thing
<burp> but optirun glxspheres is doing the right thing much faster than the intel is doing it
<Sarvatt> -310 probably doesn't even work on it since the one in precise is so old
<bryce> good sign
<bryce> Sarvatt, :-/
<burp> cancel that
<burp> actually the intel with vblank_mode=0 is much faster than than optirun
<mlankhorst> hah
<Sarvatt> try optirun glxinfo and see if it says nvidia
<burp> it does :)
<burp> OpenGL Renderer: GeForce 710M/PCIe/SSE2
<burp> vs OpenGL Renderer: Mesa DRI Intel(R) Ivybridge Mobile
<burp> nvidia gives 120+ frames per second
<burp> intel almost 200
<burp> :)
<burp> I sure hope that nvidia is sleeping most of the time
<mlankhorst> it has to copy twice
<burp> shees I should probably get me a real irc client
<mlankhorst> nobody said optimus worked well
 * mlankhorst tests on lapptop
<Sarvatt> on a real app it'd probably be much better :)
<burp> I'm just happy that there's something with which I can keep it sleeping
<burp> lemme try primus just for reference
<burp> a much more respectable 160+ frames per second
<burp> I'm actually really happy with this cheapskate performance laptop so far
<burp> if anyone's interested
<burp> Acer V3 571G with Full HD IPS display (very pretty), Intel i7 quad core (real quad), 8G RAM and big slow hard disk for 800 eurobucks
<burp> seems to run ubuntu 12.04.2 fine!
<burp> (no I'm not selling)
 * mlankhorst wonders where you get glxspheres from
<Sarvatt> mesa demos, we just dont package it
<mlankhorst> ah
<burp> jeez
<burp> on this system it seems to come from virtualgl
 * mlankhorst builds
 * burp wonders what IRC client is en vogue these days
<burp> irssi still? or something else?
<Sarvatt> oh nope, its packaged with virtualgl
<mlankhorst> icechat?
<burp> err, seems to be windows?
<mlankhorst> dno
<burp> it does say "the chat cool people use"
<burp> I see what they did there
<mlankhorst> hm guess you're right
<mlankhorst> ugh c# too
<mlankhorst> 275.781442 frames/sec - 289.647733 Mpixels/sec
<burp> what graphics?
<mlankhorst> radeon and i915
<Sarvatt> 76.287995 frames/sec - 80.123756 Mpixels/sec whee ultrabook hd4000 :)
<mlankhorst> was with DRI_PRIME=1 so it rendered on the radeon
 * mlankhorst tries i915
<mlankhorst> erm native radeon*
<Sarvatt> oh 32 bit version is much faster
<mlankhorst> how do I kill off vblank?
<Sarvatt> vblank_mode=0
<mlankhorst> that doesn't seem right :p
<mlankhorst> oh.. right, no syncing between i915 and radeon probably
<Sarvatt> isn't that what you're working on........?
 * Sarvatt coughs
<mlankhorst> it's tear free!
<mlankhorst> but that doesn't mean userspace performs its own sync correctly
<Sarvatt> woohoo, starcraft 2: heart of the swarm time :)
<Sarvatt> lets see if this bugger works in wine
<mlankhorst> Sarvatt: anyway syncing should work tear free, but if both ddx drivers don't tell that they wrote or read something, you could have 2 reads off the same frame
<mlankhorst> so it shows as higher fps ;P
 * mlankhorst will be sure to break wine this friday
<RAOF> mlankhorst: Hey, do you know off hand what would happen if I close() a prime dma-buf fd after importing it? Do I lose access to that buffer?
#ubuntu-x 2013-03-13
<mlankhorst> RAOF: not much, once you import it it's kept alive through the gem handle
<mlankhorst> if it's a self import the dma-buf will die, but you don't need it in that case anyway
<RAOF> mlankhorst: I suspected as much. Boo, ish.
<mlankhorst> boo for sane design?
<RAOF> Well, if the gem handle didn't keep it alive be a quick and simple way to revoke access to buffers ;)
<RAOF> mlankhorst: Your x-x-v-nouveau upload in quantal-proposed doesn't close a bug?
<mlankhorst> RAOF: it was from the previous rejected one
<RAOF> mlankhorst: You should include the bug numbers of the things that it's fixing (ie: include the previous changelog). Does the regression not have a bug #?
<mlankhorst> erm the previous changelog is included
<mlankhorst> 1:1.0.3-0ubuntu0.1 was rejected
<RAOF> But you didn't include that changelog in the changes file, which is where we extract the bugs from.
<mlankhorst> ah
<RAOF> So you would have wanted to do âdebuild -v$PREVIOUS_UBUNTU_VERSIONâ
<RAOF> Which I think would be âdebuild -v1:1.0.2-0ubuntu4â?
<mlankhorst> ok I'll re-upload
<mlankhorst> wow, someone was building nouveau on sparc, crazy
<mlankhorst> oh well it's there now
<alkisg> Hi, Precise 12.04, Intel 82G33/G31, google-earth complains "unsupported graphics card... need 16MB of VRAM" and it doesn't start at all.
<alkisg> I've tried different combinations of the BIOS DVMT settings to no avail. Even tried setting videoram 32768 in xorg.conf, didn't do anything either.
<alkisg> Is this a bug in google-earth? Is it a problem with linux not being able to handle DVMT? Will a BIOS firmware update help? Can I do anything to make google-earth work in that system?
<mlankhorst> error messages lie :p
<alkisg> So, a bug in google-earth?
<mlankhorst> I would just check if your configuration is correct first, and look up that error message in google
<alkisg> I tried both before coming here, of course
<alkisg> I wonder though if this is my problem: (1) google-earth misdetects vram due to dvmt, (2) it prompts to continue and it *would work* anyway, but (3) it crashes because of this bug, and not because of the vram problem:
<alkisg> http://code.google.com/p/earth-issues/issues/detail?id=1477
<alkisg> I.e. I just found out that people report that google-earth 7 crashes in linux in general...
<mlankhorst> there you go then :)
<alkisg> It seems weird though that only 10 people would be affected from oct 31, 2012 up to now
<alkisg> And that there wouldn't be a fixed released after so many months...
 * alkisg tries in another PC...
<alkisg> Nope it does work on an nvidia-based PC
 * alkisg installed the ancient http://packages.medibuntu.org/pool/non-free/g/googleearth/googleearth_5.1.3533.1731-0medibuntu1_i386.deb which works fine, and calls it a day :) Thanks!
<mlankhorst> fwiw, never trust error messages with suggestions
#ubuntu-x 2013-03-14
<ricotz> Sarvatt, tjaalton, hi
<ricotz> i was looking at the mesa packaging for edgers
<tjaalton> yo
<mlankhorst> hey
<ricotz> is it intended not to install the GLES3 headers which we did in edgers?
<ricotz> mlankhorst, hi
<mlankhorst> might be on accident, let me check
<ricotz> --- a/debian/libgles2-mesa-dev.install.in
<ricotz> +++ b/debian/libgles2-mesa-dev.install.in
<ricotz> @@ -1,3 +1,4 @@
<ricotz>  dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv2.so usr/lib/${DEB_HOST_MULTIARCH}/mesa-egl
<ricotz>  dri/usr/include/GLES2 usr/include
<ricotz> +dri/usr/include/GLES3 usr/include
<ricotz>  dri/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/glesv2.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
<tjaalton> guess I couldn't decide where to put them
<mlankhorst> we don't package gles3, do we?
<tjaalton> there is no libGLESv3.s0
<tjaalton> .so
<ricotz> the symbols are included in the gles2 lib
<ricotz> afair
<mlankhorst> ah
<tjaalton> heh, right
<tjaalton> then it's the right place
<mlankhorst> I suppose we could update the packaging in git then
<mlankhorst> I pushed out the 9.1 branch to ubuntu+1 btw
<tjaalton> go ahead
<ricotz> mlankhorst, feel free to use --author ;)
<mlankhorst> ricotz: only if you actually do all the testing for me and come up with a full debdiff :P
<ricotz> mlankhorst, hehe, as i said this diff was in edgers for some time, but was dropped there too for some reason
<mlankhorst> let me check
<ricotz> the mesa-debian.patch in hooks
<ricotz> will push an update of it soon, when my test build works out
<ricotz> looks like llvm 3.3 trunk is needed for master/9.2
<mlankhorst> fun
<mlankhorst> ok I'll do a test rebuild with the changes from that hook, and then push it to debian-experimental
<mlankhorst> argh I hate bazaar
<ricotz> mlankhorst, of course only this one change ;)
<mlankhorst> http://paste.ubuntu.com/5613472/ happy?
<ricotz> mlankhorst, thanks
<mlankhorst> ok I'm testing against debian-experimental too
<mlankhorst> if that works too I'll push it out
<mlankhorst> pushed
<Sarvatt> ricotz: oh crap, since when was edgers built against proposed?
<Sarvatt> all messed up now because of libudev1, urg
<mlankhorst> probably always, you just never noticed
<ricotz> Sarvatt, building against proposed is fine with me
<ricotz> Sarvatt, not doing it seems more trouble imo
<Sarvatt> ricotz: its building against libudev1 in the ppa that may not even get released
<Sarvatt> things are uninstallable unless someone enables -proposed and thats a bad thing to tell people to do now..
<mlankhorst> Sarvatt: copy a lower version to ppa?
<ricotz> Sarvatt, i thought getting systemd in is sure but it will be held till after beta
<tjaalton> for a devel series it makes no sense to build against -proposed
<Sarvatt> and if someone enabled proposed yesterday to work around it they got an unbootable system :)
<ricotz> Sarvatt, this is solved due some initramfs failure
<ricotz> Sarvatt, i understand your concerns, but if you call for edgers you should get it ;)
<Sarvatt> tjaalton: things have changed majorly since that commit and reverting it is a huge pain, i'm trying another route now by squashing anholts branch into a patch to see if it helps
<tjaalton> Sarvatt: ah, ok..
<Sarvatt> anholt's branch fixes slow blur on KDE at least, will be good to get him feedback that it also fixes unity
<Sarvatt> (and applies cleanly to 9.1)
<tjaalton> _if_ it fixes?
<tjaalton> :)
<mlankhorst> \o/
<tjaalton> and if it does, we can push it to raring next week. someone could file a ffe for it though :)
<Sarvatt> armhf is still busted
<tjaalton> oh right
<Sarvatt> squashing the 5 commits on his branch related to it into a patch to apply on top of 9.1 i meant, his whole branch would be 9.2 :P
<tjaalton> right
<mlankhorst> Sarvatt: ugh sorry about that
<mlankhorst> completely forgot
<mlankhorst> can you remind me tomorrow about armhf?
<mlankhorst> I need to upload llvm-3.2 to my ppa, my poor panda cant build it without running oom even with swap enabled
<tjaalton> maybe just limit what to build from mesa on arm
<tjaalton> limit some more
<mlankhorst> my panda's still on precise :)
<tjaalton> mine too.. again
<mlankhorst> but hey I use it as a way of testing the backport in advance anyway, so it's all good
<Sarvatt> tjaalton: anholt's branch changes do fix the slow blur problem, i threw it in https://launchpad.net/~sarvatt/+archive/jg
#ubuntu-x 2013-03-15
<agrestringere> hello, I'm looking to do some testing on 13.04 so I wanted to know the best way upgrade from 12.04 to the 13.04 daily build...
<RAOF> agrestringere: You'll need to go through 12.10, but that'll be easy; that's just a do-release-upgrade away. I think you can also âsudo do-release-upgrade -d -pâ to get from 12.10 to raring, but if we haven't got that sorted out yet you can simply edit /etc/apt/sources.list and replace âquantalâ with âraringâ.
<agrestringere> RAOF, okay thanks, is there a way to revert if things get really messed up?
<RAOF> Downgrades are not supported; you can, however, try it in a sandbox by passing â--sandboxâ to do-release-upgrade
<bjsnider_> a downgrade would be a good thing to use a btrfs snapshot for
<RAOF> If you happened to be using btrfs, yeah, it's entirely safe.
<RAOF> (Modulo btrfs bugs)
<bjsnider> i was speaking more theoretically at this point
<RAOF> Oh, it's implemented - check out apt-btrfs-snapshot.
<bjsnider> yeah but i'm not sure people should be using btrfs yet. not convinced it's ready freddy
<RAOF> It's actually _not_ 100% safe, because applications might change their configuration in non-forwards-compatible ways; it's not uncommon for at application to migrate to a new format on run, which would leave your data stranded if you roll back.
<bjsnider> you'd have to back up /home too
<bjsnider> certain aspects of it
<RAOF> Right, and it becomes an essentially impossible project.
<bjsnider> impossible?
<RAOF> How do you tell if an application has moved something into a form that is unreadable by one of its previous versions?
<bjsnider> well, you back up the key dirs, and then replace the upgraded ones upon downgrading
<bjsnider> .local, .cache et al.
<RAOF> So, now we're destroying work on rollback.
<bjsnider> right, but i was also assuming the original question was the case
<bjsnider> "do some testing"
<bjsnider> not permanently upgrade
<RAOF> Ah, so we've got different goals for ârollbackâ. Fair enough.
<RAOF> In that case you'd just snapshot $HOME as well as /
<bjsnider> i just interpreted that phrasing as being very temporary
<RAOF> Make it very clear that going back will wipe your system back to the previous state.
<bjsnider> i dunno why there isn't a dpkg-downgrade type thing
<RAOF> Because of all these problems?
<bjsnider> well, if the user wants to do this, it's their responsibility
<RAOF> Having a dpkg-downgrade would suggest that you could downgrades are supported, which is quite different from "you can try this, and if it doesn't work you can throw away everything you've done after this point and go backâ
<RAOF> You obviously *can* downgrade packages - apt-get install foo=$OLD_VERSION will work as long as $OLD_VERSION is in the archive, and you can manually do it with dpkg and downloading from launchpad essentially as far back as you care to go.
<ScottK> And if it breaks, you get to keep both halves..
<agrestringere> okay, so how does the sandbox work?
<agrestringere> I'll read the documentation, thanks for the info...
<RAOF> agrestringere: It sets up an overlay filesystem, and makes all the changes on that overlay.
<RAOF> So you can go back by throwing away the overlay, but if you want to keep it you should probably throw away the overlay and upgrade again without the sandbox.
<agrestringere> that's what I'll do, I read that it installs root to temp, looks cool, I'll give it a shot
<agrestringere> interesting view on rollbacks, it doesn't make sense that you can't rollback, I mean if upgrading is just a dpkg thing can't you store an entire history of actions and changes like you do in git and just "checkout 12.04.2"?
<RAOF> That's what the btrfs discussion was. You certainly *can* do that, if you're willing to have your *entire* system rolled back to how it was when you installed 12.04.2. Including all of your personal data.
<RAOF> That's not what people want from a rollback, though.
<RAOF> And when you try to start implementing what people want, you run into all the funky edgecases.
<agrestringere> seems like something only useful for server people because of uptime concerns
<RAOF> Rollback?
<RAOF> No, it'd totally be useful in a fairly wide range of circumstances if it were possible to implement well. :)
<agrestringere> Complexity.
<tjaalton> Sarvatt: great, thanks
<agrestringere> have a good night, once again thanks for the instructions
<mlankhorst> morning
<xnox> RAOF: well there is apt-brtfsnapshot and by default we have @ and @home separate. So one can roll-back /system/ but not personal data, but there are all sorts of corner cases.
<tjaalton> one could separate dotfiles from $home..
<xnox> cause e.g. postgresql databases in /var/lib are _not_ system, but data yet again which shouldn't be rolle back.
#ubuntu-x 2013-03-17
<mlankhorst> Sarvatt: https://bugs.freedesktop.org/show_bug.cgi?id=62434 ? I guess that was the arm bug?
<ubottu> Freedesktop bug 62434 in Drivers/Gallium/r600 "[bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)" [Blocker,New]
#ubuntu-x 2014-03-10
<mlankhorst> Prf_Jakob: can you look at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1284134 ?
<ubottu> Launchpad bug 1284134 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [Undecided,New]
 * barry waves
<Prf_Jakob> mlankhorst: sure
<Prf_Jakob> barry, mlankhorst: Well I can repro it.
<mlankhorst> oh goodie
<barry> Prf_Jakob: \o/
<barry> Prf_Jakob: i was going to create a fresh trusty vm, but if you can reproduce it i won't.  happy to do anything needed to help gather info
<Prf_Jakob> barry: what version are you unsing?
<Prf_Jakob> using*
<barry> Prf_Jakob: version of...?  trusty, fully dist-upgraded, fusion 6.0.2, os x 10.9.2
<Prf_Jakob> barry: Right yeah, version of fusion/WS/player.
<Prf_Jakob> thanks
<zuke> hi everyone
<HERM3S> Hello - http://ubuntuforums.org/showthread.php?t=2210394
<HERM3S> I have installed nvidia-331 and removed bumblebee - now, I am seeing a blank screen with a mouse icon "X" on one of my monitors
#ubuntu-x 2014-03-11
<HERM3S> any Xorg gurus home?
<tomreyn> your best place for support is #ubuntu and then there is /topic
<HERM3S> I was told to come here
<HERM3S> I did submit a bug as well tomreyn 
<tomreyn> oh sorry then, i guess you'll just need to be patienct then.
<tomreyn> i don't rmeember seeing the bug report url / id, though.
<HERM3S> yep, seems that way
<HERM3S> any xOrg gurus home?
#ubuntu-x 2014-03-12
<mlankhorst> morning
<ricotz> mlankhorst, hi :), xdiagnose requires pyhton3.3 again instead of python3.4?
<mlankhorst> ugh?
<mlankhorst> ricotz: not that I know of?
<ricotz> 2.6.2build1 depends on python3.4, maybe some dh-python fail?
<mlankhorst> I have no idea
<mlankhorst> oops also included my whole .git directory
<tjaalton> bah
<tjaalton> should've known ;)
<ricotz> changing the build-deps: python3-all > python3
<ricotz> should do it
<tjaalton> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I"
<mlankhorst> hm not a bad idea
<tjaalton> in .devscripts already
<mlankhorst> yeah!
#ubuntu-x 2014-03-13
<sforshee> mlankhorst: do you still have that macbook? mjg59 has some new switcheroo patches you might want to try out: http://www.codon.org.uk/~mjg59/tmp/retina_patches/
<tomreyn> is radeon DPM enabled by default in 14.04 ?
<mlankhorst> sforshee: sure
#ubuntu-x 2014-03-14
<superkuh> It has been a week and a half of multiple hours per day of trying to understand and compile the X stack so I can install xorg-server 1.8 on ubuntu lucid. I have failed. I know the xorg-edgers used to have packages for this. But they were deleted. Does anyone know where I might acquire these? I am too inept to compile the entire stack myself.
#ubuntu-x 2014-03-15
<Sarvatt> if he comes back https://launchpad.net/~sarvatt/+archive/xorg-testing might help, but i doubt it because proto and lib updates were only in edgers and that ppa depended on it to build
<Sarvatt> superkuh: [21:06:33] <Sarvatt> if he comes back https://launchpad.net/~sarvatt/+archive/xorg-testing might help, but i doubt it because proto and lib updates were only in edgers and that ppa depended on it to build
<superkuh> Thanks Sarvatt. I will try.
#ubuntu-x 2014-03-16
<Mikel__> hello
<Mikel__> I'm following a guide that says that I have to download sudo apt-get install nvidia-331 nvidia-settings-331 from xorg-eders ppa
<Mikel__> but there's no nvidia-settings-331
<Mikel__> anyone knows why?
<Sarvatt> Mikel__: just grab nvida-settings, it'll pull in the latest one and works with older driver releases too
<Mikel__> Ok Sarvatt , thanks
<Mikel__> how can I check if bumblebee is running correctly?
<Mikel__> (I'm on Ubuntu 12.04.4 LTS)
#ubuntu-x 2015-03-10
<smallfoot-> Now that AMD has finaly (about god damn time) released new catalyst driver, will we see X.Org Server 1.17?
<furkan> did they really?
<mlankhorst> after fglrx is uploaded
<furkan> i don't see an updated driver on amd.com?
<tjaalton> right, nothing released yet
<tjaalton> don't misread phoronix
<smallfoot-> oops, sorry, I did misread Phoronix
<smallfoot-> god, I hate AMD, they are so slow
<smallfoot-> I don't like Nvidia either, but at least they don't hold X and Linux innovation back
<tjaalton> what's the rush anyway, still six weeks until the release :)
<smallfoot-> 6 weeks for AMD, don't expect much
<smallfoot-> 6 weeks in AMD time, it will take another 6 months for them
<smallfoot-> also its already been Feature Freeze
#ubuntu-x 2015-03-11
<furkan> mlankhorst: http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-15.04-15.3-Beta
<furkan> :)
<tjaalton> yes, he's aware of it..
<mlankhorst> yeah tomorrow..
<tjaalton> or even monday :)
<furkan> lol good news
<furkan> hopefully it fixes my gfx corruption issues
<furkan> i'll probably wait for the trusty backport though
#ubuntu-x 2015-03-12
<smallfoot-> Does Weston or GDM or LightDM or gnome-shell have any systemd session that uses Wayland backend?
#ubuntu-x 2015-03-13
<snafu109> hi there!
<snafu109> trying to get some attention on https://bugs.freedesktop.org/show_bug.cgi?id=86288
<ubottu> Freedesktop bug 86288 in Server/General "[nvidia-prime]Freeze while using touchpad" [Critical,Resolved: fixed]
<snafu109> sorry that should be https://bugs.launchpad.net/xorg-server/+bug/1220426
<ubottu> Launchpad bug 1220426 in xorg-server (Ubuntu) "[nvidia-prime]Freeze while using touchpad" [Low,Triaged]
<snafu109> upstream patch is available and i built test packages which have been tested by a few users
<snafu109> would be great to get merged for vivid
#ubuntu-x 2015-03-14
<tjaalton> it's already in vivid
<dupondje> since I upgraded my xserver package, xfreerdp lags like hell :s
<dupondje> any clue?
<mlankhorst> needs more info..
#ubuntu-x 2015-03-15
<dupondje> mlankhorst: when xfreerdp is doing some screen updates, xorg goes to 100% cpu :s
<dupondje> really strange
<mlankhorst> ah :/
<dupondje> downgraded xserver to 2:1.16.2.901-1ubuntu4
<dupondje> and its perfect again
<dupondje> xserver-common xserver-xephyr and xserver-xorg-core that is
<dupondje> upgrading to 2:1.17.1-0ubuntu1 breaks it again
<dupondje> so must be somewhere in between those versions
<dupondje> is there some (easy) way to bisect/debug?
<dupondje> mlankhorst: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1432384
<ubottu> Launchpad bug 1432384 in xorg-server (Ubuntu) "Performance regression in 2:1.17.1-0ubuntu1+" [Undecided,New]
<mlankhorst> dupondje: apport-collect for that bug
<dupondje> done
<dupondje> ok found the problem
<dupondje>  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
<dupondje> made me think
<dupondje> :)
<tjaalton> how did you manage to do that then
<dupondje> I have no idea, checking my dpkg.log's
<tjaalton> some ppa's enabled?
<dupondje> got removed when playing around in september ...
<dupondje> wtf
<dupondje> but strange xorg-server upgrade triggers this?
<tjaalton> you dind't have video-all installed?
<tjaalton> still shouldn't be possible
<tjaalton> that it gets removed instead of updated
<tjaalton> the log will tell
<dupondje> video-all was not installed nope
<mlankhorst> modesetting was removed but I removed all dependencies on it
<dupondje> seems like nothing else has a depends on xorg-server-video-all
<tjaalton> apt-get --fix-policy install
<tjaalton> so video-all got deinstalled earlier, and this upgrade then broke
<mlankhorst> tjaalton: apt-get -f ?
<tjaalton> no need for -f
<tjaalton> at least it works without here
<mlankhorst> ah I'm still on trusty, didn't see a fix-policy there in the manpage..
<mlankhorst> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578020 it seems..
<ubottu> Debian bug 578020 in apt "apt-get: --fix-policy not documented" [Wishlist,Open]
<tjaalton> --fix-policy is old
<tjaalton> yeah
<mlankhorst> ah so it's like fix-broken for recommends :p
<tjaalton> yeah
<tjaalton> hmm echo
<furkan> mlankhorst: is there a way to run xorg 1.17 on trusty?
<mlankhorst> not yet
<mlankhorst> I'll create a lts-vivid in x-staging soon
<furkan> ah nice, thanks!
#ubuntu-x 2016-03-14
<tjaalton> furkan: downgrade mesa first
<furkan> tjaalton: just tried that now, same result (i had purged the ppa, so i added it back and only upgraded  xserver-common xserver-xorg-core xserver-xorg-dev xserver-xorg-video-intel
<tjaalton> ok
<furkan> are you able to see the same thing with glamor?
<furkan> i'm willing to do a bisect, but preferably if you had any pointers on how to make that easier lol (like if you have a script you use or something)
<furkan> i can build mesa fine, but last time i tried building xorg it just didn't work out
<tjaalton> i'll have a look later
<furkan> if you want some test pages to try in Firefox, in gmail your name in the top right corner shows up in red
<furkan> and in facebook when you mouse over somebody's name and you get the little overlay popup with their basic profile information, the "shadow" around the box is red
<furkan> also a thin red line under the facebook navbar at the top of the page
<tjaalton> furkan: I see the red line
<tjaalton> also a system hang on skylake when switching between modes
<tjaalton> but that's a kernel thing
<ricotz> tjaalton, hi, did you already pushed an updated vulkan package somewhere?
<tjaalton> ricotz: the loader lib? i've uploaded 1.0.3.1 to debian, still in NEW
<tjaalton> I see 1.0.5.0 is tagged
<ricotz_> tjaalton, hi, yes, that one ;)
<tjaalton> i'll fix the ppa tomorrow
<ricotz_> tjaalton, thanks!
<ricotz_> tjaalton, there might be a new libva release coming (API 0.39)
<tjaalton> alright
<JanC> I've never been able to get libva to work properly; is there any testing being done for it?
<tjaalton> not by me
<tjaalton> and it's in universe
#ubuntu-x 2016-03-15
<furkan> tjaalton: any tips on how i can run Xorg from git? to bisect these couple of bugs that i've encountered?
<furkan> i built successfully and installed into /opt/xorg
<furkan> and then i symlinked /usr/bin/Xorg to /opt/xorg/bin/Xorg
<furkan> but when i restart lightdm, it attempts to start xorg in failsafe mode and it fails because it can't find some modules (fbdev, keyboard, mouse)
<furkan> if it used my regular xorg.conf file instead of the failsafe config, it would find the necessary modules in /usr/lib/xorg/modules
<furkan> i didn't rebuild the modules since there's no ABI bump going from 1.18.1 to 1.18.2
<furkan> oh actually maybe there was an ABI bump
<Sarvatt> furkan: no abi bumps there, if you need to bisect 1.18.1..1.18.2 be sure you are on server-1.18-branch
<Sarvatt> master has abi bumps and needs recompiling all drivers of course
<furkan> ah that must be why
<furkan> i just did a git clone and didn't checkout any branch so it's probably master
<furkan> thanks :)
<tjaalton> furkan: I'd just take a reversed diff of 1.18.1..1.18.2 and apply it on top of the packaging
<tjaalton> err
<tjaalton> diff of 1.18.1+some to .2
<tjaalton> bisect that way
<ddd_> hi, could i have a question about intel vulkan driver for ubuntu 16.10?
<tjaalton> if you mean 15.10 then no
<tjaalton> i mean, you are free to just ask, but there won't be a driver for it
<furkan> tjaalton: i don't get the red text/lines in firefox when running upstream xorg 1.18.2
<furkan> so maybe it's one of the ubuntu patches, if there are any?
<furkan> i see, maybe some of those xmir patches
<furkan> anyway.. off to sleep now
<furkan> i did bisect the stray cursor issue though
<furkan> that's upstream
<furkan> the bug is upstream, that is
<tjaalton> furkan: what was the red line thing again?
<tjaalton> i'm seeing something on debian as well
<tjaalton> but need to know it's the same thing
<tjaalton> ok guess it is, not happening with -intel or 1.18.1
<furkan> tjaalton: some grey text/shadows showing up in red on Firefox, like a red line under the Facebook navbar, or tge dropshadow when you mouse over a user name to display the little preview box of their profile info
<furkan> if you use feedly that's another easy page to test, all the menu items on the left show up in red instead of grey
<tjaalton> furkan: did you file the cursor bug?
<tjaalton> I'm seeing the red things on debian too
<tjaalton> which has pretty much vanilla xserver
<tjaalton> looks like the regression fixes didn't make it to 1.18.2
<tjaalton> well, they aren't even in master
<furkan> tjaalton: not yet, but will do, how do I file against x-staging though?
<tjaalton> no upstream
<tjaalton> bugs.fd.o
<tjaalton> that's what mrcooper asked
<furkan> Oh ok, yeah I've done that before
<furkan> Yeah gonna do that for the mouse cursor one
<furkan> But for the red text I'll have to see if I can reproduce it with the upstream build
<tjaalton> no need to
<tjaalton> I have three patches to try
<tjaalton> that never got applied upstream
<tjaalton> [PATCH xserver 0/3] Fixups for GL_RED patch.
<furkan> Oh ok
<tjaalton> regression fixes for the core profile support
<furkan> Ah
<furkan> So wait are you suggesting I file that one too or no?
<tjaalton> no
<tjaalton> I'll test that
<furkan> Ok sounds good
<tjaalton> bah, turns out the fixes were squashed into another commit
<furkan> tjaalton: so i grabbed the src package from x-staging
<furkan> how do i pass --disable-xmir to it when building?
<furkan> hmm but if you see the red stuff in debian too, it must be one of the other patches that are in common between debian/ubuntu, so i guess not xmir
<tjaalton> furkan: no, 1.18.1 is good on both
<furkan> tjaalton: right, but the patches may need to be updated for 1.18.2
<furkan> basically i'd have to do 2 bisections
<furkan> first bisect to see which debian/ubuntu patch causes the issue
<furkan> and a second bisect to see which upstream patch it conflicts with
<tjaalton> debian has only a couple of trivial patches, they don't suddenly break stuff
<tjaalton> i filed it upstream, ajax repro'd it
<furkan> interesting
<furkan> i wonder why i can't reproduce it when i build from git
<furkan> i'm filing the cursor bug now
<furkan> done: https://bugs.freedesktop.org/show_bug.cgi?id=94560
<ubottu> Freedesktop bug 94560 in Server/General "[regression, bisected] Xorg 1.18.2 stray cursor appears when some applications are launched maximized on rotated display" [Normal,New]
<furkan> tjaalton: i just built the package from x-staging and the red is back
<furkan> i will go ahead and try to remove the patches and see what happens
<furkan> ok well apparently i need to learn how to use quilt
<furkan> can't just remove the patches from the debian/patches directory
<tjaalton> edit debian/patches/series
<furkan> thanks that did it
<furkan> but yeah you're right... those debian patches seem pretty trivial
<furkan> there's also the build flags...
<furkan> tjaalton: is there any way for me to check what flags were passed to autogen.sh?
<furkan> when i compiled from git i just used ./autogen.sh --prefix=/opt/xorg --enable-glamor --with-xkb-path=/usr/share/X11/xkb --enable-config-udev
<tjaalton> furkan: dpkg-buildflags
<tjaalton> ah
<tjaalton> debian/rules?
<tjaalton> and for the full set ppa build logs
<tjaalton> it's https://bugs.freedesktop.org/show_bug.cgi?id=94554 btw
<ubottu> Freedesktop bug 94554 in Server/Acceleration/glamor "[glamor, 1.18.2 regression] red text/gfx in firefox" [Normal,New]
<furkan> tjaalton: yep... it's one of the autogen parameters
<furkan> i looked at debian/rules
<furkan> it saves the flags in debian/xserver-xorg-dev/usr/share/xserver-xorg/configure_flags.mk
<furkan> when i was building from git, i was just using --prefix=/opt/xorg --enable-glamor --with-xkb-path=/usr/share/X11/xkb --enable-config-udev
<furkan> compared to what the deb package uses:
<furkan> --build=x86_64-linux-gnu lt_cv_prog_compiler_static_works=no --disable-silent-rules --disable-static --without-dtrace --disable-strict-compilation --disable-debug --enable-unit-tests --with-int10=x86emu --with-extra-module-dir="/usr/lib/x86_64-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules" --with-os-vendor="Ubuntu" --with-builderstring="xorg-server 2:1.18.2-1ubuntu0.2 (For technical support
<furkan> please see http://www.ubuntu.com/support)" --with-xkb-path=/usr/share/X11/xkb --with-xkb-output=/var/lib/xkb --with-shared-memory-dir=/dev/shm --enable-mitshm --enable-xres --disable-xcsecurity --disable-tslib --enable-dbe --disable-xf86bigfont --enable-dpms --enable-xshmfence --disable-config-hal --enable-config-udev --enable-xorg --disable-linux-acpi --disable-linux-apm --disable-xquartz --disable-xwin
<furkan> --disable-xfake --disable-xfbdev --disable-install-setuid --with-default-font-path="/usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins" --enable-aiglx --enable-composite --enable-record --enable-xv --enable-xvmc --enable-dga
<furkan> --enable-screensaver --enable-xdmcp --enable-xdm-auth-1 --enable-glx --enable-dri --enable-dri2 --enable-glamor --enable-dri3 --enable-libdrm --enable-present --enable-xinerama --enable-xf86vidmode --enable-xace --enable-xselinux --enable-xfree86-utils --enable-xwayland --enable-systemd-logind --with-systemd-daemon --enable-suid-wrapper --enable-dmx --enable-xvfb --enable-xnest --enable-kdrive
<furkan> --enable-xephyr --enable-xmir --with-sha1=libgcrypt --enable-xcsecurity
<furkan> oops, didn't realize how long that was
<furkan> so anyway, i built from git using those same flags (with a couple of modifications, like no mir) and can reproduce it now
<furkan> bisected... will share results
<furkan> https://bugs.freedesktop.org/show_bug.cgi?id=94554#c1
<ubottu> Freedesktop bug 94554 in Server/Acceleration/glamor "[glamor, 1.18.2 regression] red text/gfx in firefox" [Normal,New]
#ubuntu-x 2016-03-16
<furkan> tjaalton: dave sent out a patch
<furkan> https://lists.x.org/archives/xorg-devel/2016-March/049102.html
<tjaalton> oh, nice
<furkan> tjaalton: also, it looks like we will be getting a 1.18.3 pretty soon lol
<tjaalton> maybe so
<furkan> according to dave
<furkan> since there were too many regressions in 1.18.2
<tjaalton> said where?
<furkan> 22:59	<furkan>	are all these regressions normal for a point release?
<furkan> 23:00	<furkan>	i think we need 1.18.2.1 :)
<furkan> 23:00	<airlied>	yeah ajax will probably do a 1.18.3 farily quick
<furkan> 23:01	<MrCooper>	no, I think ajax went overboard with 1.18.2, I'll follow up on his release announcement
<tjaalton> ok
<furkan> i noticed a 3rd regression when posting my log file for the cursor bug
<furkan> and MrCooper linked a fix for it lol
<tjaalton> yeah that one I knew about
<jcristau> furkan: for a point release that includes so many changes, it's not surprising
<Free99> hey all, I'm running 14.04 x64 on i915, upgraded to kernel 4.4 because of hardware enablement but this messed up my ability to dual screen
<Free99> would xorg-edgers help?
<furkan> Free99: i don't know the answer to your question, but i'd recommend x-staging over xorg-edgers
<Free99> furkan, last update was 119 weeks agon on staging..
<furkan> oh right, forgot you're using trusty
<furkan> for xenial it's up to date
<furkan> actually, xenial is the only repo i see available https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
<Free99> how can I grab their X stack?
<furkan> maybe you should just upgrade to 16.04 :)
<furkan> if you want latest kernel/X
<Free99> yeah, but I have school work for which I need a working tablet.. crazy as this sounds, I'm less afriad of upgraded kernel/X on 14.04 than jumping to RC16.04
<furkan> does dual screen work when you boot up into an older kernel?
<Free99> yep, but then my tablet stops functioning
<furkan> if you want to help fix the bug... i'd recommend doing a bisect
<Free99> ok, I wouldn't mind helping out
<Free99> I don't have too much time though, maybe half an hour
<furkan> it would take longer than that, but that's something you'd do if it really was a bug
<furkan> it might help to see your dmesg and Xorg logs
<furkan> after the problem happens of course
<furkan> also, what GPU? intel?
<Free99> problem is pretty simple actually, xrandr on kernel 3.13 shows my external displayport display connected just fine
<Free99> kernel 3.19+ it stops showing up, but udev still detects when I dis/connect it
<Free99> intel yeah
<Free99> http://paste.ubuntu.com/15403452/ <- Xorg.0.log on 4.4 kernel
<Free99> http://paste.ubuntu.com/15403475/ <- xrandr output (I tried forcing my mode, so ignore those extaneous lines)
<Free99> anything obviously screwy?
<furkan> nothing that i can make out unfortunately, but your X version is really, really old
<Free99> ;) LTS baby!!!
<furkan> you should run this:
<furkan> sudo apt-get install --install-recommends linux-generic-lts-wily xserver-xorg-core-lts-wily xserver-xorg-lts-wily xserver-xorg-video-all-lts-wily xserver-xorg-input-all-lts-wily libwayland-egl1-mesa-lts-wily
<furkan> that should give you 4.2 kernel and xorg 1.17
<Free99> furkan, you rock man (or lady) thank you!
<Free99> sudo service lightdm is adequate for reloading the graphics stack without rebooting? or should I reboot
<tjaalton> best to reboot
<tjaalton> actually
<tjaalton> where did you get the 4.4 kernel?
<furkan> Free99: np, hope it does something useful
<furkan> tjaalton: do you ever run X in gdb?
<Free99> furkan, it worked!
<furkan> nice :)
<Free99> tjaalton, apt-get install linux-generic-lts-xenial
<furkan> oh that's actually been released?
<Free99> but I've been trying to get towards compiling my own kernel with grsec patches
<tjaalton> Free99: did it also install linux-image-extra-4.4..
<Free99> tjaalton, thanks for your work on X, I see you do a lot of these packages
<tjaalton> guess it did
<Free99> actually no
<furkan> i'm running 14.04 on my laptop
<furkan> and looks like it's there
<furkan> linux-generic-lts-xenial linux-headers-4.4.0-13 linux-headers-4.4.0-13-generic linux-headers-generic-lts-xenial linux-image-4.4.0-13-generic linux-image-extra-4.4.0-13-generic linux-image-generic-lts-xenial
<furkan> first time i've seen a linux-generic-lts-* come out before the actual release
<Free99> tjaalton, I've been stuck making a udev rule which detects when I boot/resume with my monitor connected and sends part of my X display to the right of the eDP1... any thoughts on including that in standard LTS?
<Free99> I'm emulating windows in a sense, boot with multiple displays and they default to being expansions of the regular desktop
<tjaalton> Free99: so did not install the -extra package? no wonder it failed then, because you didn't have i915.ko
<Free99> http://paste.ubuntu.com/15403452/ <- Xorg.0.log on 4.4
<tjaalton> nevermind, it's using intel so i915.ko is there
<furkan> so Free99 are you still running 4.4 now?
<furkan> or 4.2?
<Free99> nope, jumped to 4.2 per furkan's help
<Free99> oh, hi furkan. Thought that was tjaalton writing me
<furkan> i wonder if 4.4 works now that you have the newer X (unless you didn't install that)
<Free99> I didn't have a newer X.. maybe 4.4 would work. I can try later tonight
<Free99> still having a weird issue with this X stack where if I boot with the monitor connected, plymouth and etc are cloned on both monitors, but once I login, the display turns off on my laptop and all content goes to the external monitor
<Free99> if I run my script which sets xrandr --auto and then xrandr --output DP2 --right-of eDP1, I lose output on everything
<Free99> I have to switch to tty1 and restart lightdm, but only after disconnecting and reconnecting the external display
<Free99> then stuff works pretty well
#ubuntu-x 2016-03-17
<ricotz> tjaalton, hi :), in case you care https://bugs.launchpad.net/ubuntu/+source/libva/+bug/1558730 && https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1558731
<ubottu> Launchpad bug 1558730 in libva (Ubuntu) "Sync libva 1.7.0-1 (universe) from Debian unstable (main)" [Undecided,New]
<ubottu> Launchpad bug 1558731 in intel-vaapi-driver (Ubuntu) "Sync intel-vaapi-driver 1.7.0-1 (universe) from Debian unstable (main)" [Undecided,New]
<tjaalton> ricotz: I've tried to sync it but lp is broken atm
<ricotz> tjaalton, oh, alright, thanks
<tjaalton> internal debian mirror can't sync new stuff because of new deb archive features
<ricotz> tjaalton, dget *.dsc and push?
<tjaalton> i've also pushed the first step to enable the gallium vaapi driver to git
<tjaalton> oh right
<tjaalton> that works too
<tjaalton> forgot
<ricotz> tjaalton, ah, vdpau for nvidia works fine though ;)
<tjaalton> it's for radeon
<ricotz> intel still has its own
<ricotz> yeah and nouveau
<ricotz> tjaalton, thanks for looking into it!
<tjaalton> this finally makes it useful
<ricotz> you can close the bugs when you pushed it
<tjaalton> and guess I was on crack or something when thought moving libva in main would pull ffmpeg et al
<ricotz> ... for non-intel ;)
<tjaalton> which it shouldn't
<tjaalton> still would need a MIR for that
<ricotz> or go a similar route like with vulkan?
<tjaalton> that won't be in the main archive though
<ricotz> but I guess it is more entangled in mesa
<tjaalton> or what do you mean?
<ricotz> I mean having an extra mesa source which only builds the vaapi drivers
<tjaalton> yeah that wouldn't fly
<tjaalton> archive admins would block it
<tjaalton> I guess
<tjaalton> no, I bet
<ricotz> alright
<tjaalton> goddamn these package specific debhelper plugins
<tjaalton> --with libva wth?
<tjaalton> need to install this just to build a source package
<ricotz> tjaalton, for the "syncs"?
<tjaalton> yep
<tjaalton> at least the old version was enough
<ricotz> just use the built package and sign it?
<tjaalton> well, there probably would be a way to run dpkg-genchanges but meh
<tjaalton> done already
<tjaalton> hah, forgot syncpackage can take a .dsc :P
<tjaalton> well good thing the first uploads got rejected because .changes said unstable, syncpackage created proper ones
#ubuntu-x 2016-03-18
<ricotz> tjaalton, hi
<ricotz> is something holding back updates for wayland and wayland-protocols?
<tjaalton> why?
<tjaalton> i haven't touched them
<ricotz> alright, just wondering why there is still no wayland 1.10 and wayland-protocols 1.3
<tjaalton> they're not in debian either
<tjaalton> hm, vlc shouldn't need any tricks for vaapi?
<tjaalton> bdw is fine, kbl isn't
<tjaalton> vainfo shows that it can load the driver
<ricotz> tjaalton, i965-* installed?
<ricotz> vainfo is happy on skl here
<tjaalton> yes
<ricotz> i think vlc defaults to auto and source for a proper way
<tjaalton> it just tries to load "vdpau backend libvdpau_i965.so
<tjaalton> "
<ricotz> there is a vdpau bridge for vaapi too
<ricotz> tjaalton, you should be able to force in the settings too though
<tjaalton> where's that?
<tjaalton> the bridge
<ricotz> vdpau-va-driver
<tjaalton> vdpauinfo works on bdw but not kbl, so I guess that's the missing bit
<tjaalton> huh
<tjaalton> I have that
<ricotz> could be some missing pci'ids
<tjaalton> yeah guess vdpau-video needs an update
<ricotz> e.g. https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=c60283ab1423aa6323723beb5335b52c1adf8f6f
<kangz> Hey, I'm trying to use the vulkan intel driver on the xenial beta1 livecd and get 
<kangz> /usr/lib/x86_64-linux-gnu/libvulkan_intel.so: undefined symbol: _mesa_sha1_compute
<tjaalton> known
<tjaalton> ricotz: vainfo works though
<kangz> Ah googling didn't show up a bug will dig more in your tracker
<tjaalton> it just needs fixing
<tjaalton> been broken for a few weeks already
<tjaalton> but there's nothing interesting anyway
<tjaalton> :)
<kangz> Nothing interesting to see, but a lot of interesting to develop
<kangz> interesting things*
<kangz> Anything I can do to help apart pointing out that compiling with --with-sha1 should fix it? (from https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2015-09-04 )
<tjaalton> a local build built off git works, buildd builds broken
<tjaalton> ah
<tjaalton> that might explain it actually
<kangz> afk
<tjaalton> ricotz: had to switch back to -intel on kbl to make vdpauinfo work
<tjaalton> bdw works with both
<ricotz> tjaalton, switched back from what?
<tjaalton> modesetting
<ricotz> o
<ricotz> k
<tjaalton> kangz: I can't get even the current source to build anymore, so meh
<tjaalton> ah, so great that there are a gazillion .gitignore files all around the tree
<tjaalton> good luck trying to find all generated files to purge
<kangz> heh, I'll try to compile it locally and just copy over libvulkan_intel
<kangz> rm -r then reclone :P
<tjaalton> or just rm -r then git reset
<kangz> yep
<ricotz> git clean -dxf
<tjaalton> oh right :P
<tjaalton> must be tired, forgot -x
<ricotz> ;)
<tjaalton> kangz: what did you try to get that undefined symbol error?
<tjaalton> looks like that issue is gone now
<tjaalton> but the driver is completely broken on skylake at least :)
<tjaalton> all demos just crash
<kangz> The instruction on the PPA on a clean start of the Xenial beta1 live cd
<kangz> On a Thinkpad Carbon X1 (Broadwell)
<tjaalton> yeah the ppa driver is broken, and this version should fix the missing symbol thing
<tjaalton> i'll try broadwell too
<tjaalton> nope
<kangz> :S
<kangz> On my end it doesn't compile either
<kangz> I guess I'll just wait a bit until I can get back to my workstation
<kangz> Thanks for your help!
<tjaalton> oh, it works after all
<tjaalton> I'll upload it then
<tjaalton> vkcube doesn't
<tjaalton> but the willems demos do
<tjaalton> I just wasn't in the correct directory :P
<tjaalton> new snapshot seems to work too
<tjaalton> uploaded that too
<tjaalton> kangz: thanks to the hint to enable --with-sha1=foo
<tjaalton> er, thanks *for*...
<kangz> Thanks, I'll try again using the updated PPA
<tjaalton> it'll take a while to build
<tjaalton> weird that skylake is somewhat broken
<tjaalton> for instance bloom demo has a rotating spaceship, but it doesn't rotate on skl
<tjaalton> same thing for gears
<tjaalton> bdw works better, but still some demos crash or don't show anything useful
<kangz> could be related to push constants, I'm not sure
<kangz> Sascha's triangle demo works with your updated ppa, thanks!
<tjaalton> cool
#ubuntu-x 2016-03-19
<jjjjjjooooooeeee> I filed https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1555434 a short while ago, initially thinking it was a kernel bug.  Since isolating it to the 1.18 xserver package, there's been no activity.  Could someone on the X team take a look?
<ubottu> Launchpad bug 1555434 in linux (Ubuntu) "Black screen/system lockup on 4.4.0-11" [Medium,Confirmed]
<slavik81> Hey tjaalton. You helped me out a couple weeks ago. I just wanted to say thanks. I did manage to get things working on Ubuntu 14.04 by building from source, and I put together some instructions: https://gist.github.com/cgmb/7f5ee12c00af5c655235
<ricotz> tjaalton, \o/ https://01.org/linuxgraphics/downloads/skylake-guc-6.1
<tjaalton> ricotz: is there working code for that? :)
<ricotz> tjaalton, intel-drm-nightly https://cgit.freedesktop.org/drm-intel/commit/?id=ab65cce821cc46ccdc0b62f99bb79f75c1c7412c
#ubuntu-x 2017-03-15
<alkisg> Hi, I got this segmentation fault on 16.04 + hwe, would reverting to non-hwe kernel+xorg help?  http://paste.debian.net/919983/
<alkisg>  
<alkisg> Using ubuntu-mate, with marco window manager that has compositing: org.mate.Marco.general compositing-manager true
 * alkisg tries disabling compositing in the mean time... :)
<tjaalton> it's a mesa bug, you could try updating it via ppa:ubuntu-x-swat/updates
<alkisg> Thank you tjaalton, will do
#ubuntu-x 2017-03-16
<tjaalton> 1.19.3 uploaded to ppa:canonical-x/x-staging
<michael-vb> Hello, wondering if someone can give me a hint about the following.
<michael-vb> In the VirtualBox Guest Additions we install a drm driver into /lib/modules which should get auto-loaded at boot time.  A user is claiming that in a Debian Sid virtual machine, X.Org often starts before the module is loaded.
<michael-vb> Is this expected?  Not sure what else the user might have done of course.  And if it is expected, should I be doing something to prevent it?
<tjaalton> the driver probably isn't in the initrd image
<tjaalton> ?
<alkisg> Kernel 4.8 broke 16bpp modes in virtualbox for me (I see two smaller broken images of the screen instead of one large one), while in 4.4 it worked, would that be related to the vbox code? Should i report that to the vbox bug tracker or to the kernel or to xorg?
<michael-vb> tjaalton: don't think so.  I tried putting it into initrd's on various systems (though it is only Debian that puts graphics drivers there), but it felt too fragile for me.  For me it works without.  Am I just lucky?
<michael-vb> I assumed that the initrd graphics drivers were for the boot splash.
<tjaalton> kms drivers
<tjaalton> if you put it in /lib/modules it's a kms driver?
<michael-vb> Exactly.
<tjaalton> so it belongs there
<michael-vb> Of course, I usually test Ubuntu which ships it by default.
<tjaalton> ships what?
<michael-vb> So that is probably why I am not noticing.
<michael-vb> vboxvideo.ko
<tjaalton> ah
<michael-vb> And if it is in the initrd would that be expected to work?
<tjaalton> I'd say so
<tjaalton> otherwise X might start before the driver has a chance of loading
<tjaalton> I guess
<michael-vb> Oh dear, back to initrd fun then.  It seems to go wrong in so many different ways when you try to add something from outside.
<michael-vb> Actually, remembering, with Ubuntu one could just drop a file into some directory and ask to have the initrd rebuilt.
<michael-vb> Thanks.
<tjaalton> should be the same trickery
<tjaalton> unless there's some ubuntu'ism
<tjaalton> in initramfs-tools
<michael-vb> Hopefully not.
<tjaalton> you can check the diff to be sure :)
<tjaalton> /usr/share/initramfs-tools/scripts/init-top/framebuffer
<tjaalton> nope
<tjaalton> /usr/share/initramfs-tools/hooks/framebuffer
<tjaalton> copy_modules_dir kernel/drivers/gpu
<tjaalton> so install a new hook
<michael-vb> Ahem.  That file exists in 0.125ubuntu9 but not in 0.127 from Sid.
<alkisg> Here's what I'm seeing with kernel 4.8: https://snag.gy/H3FeMW.jpg
<michael-vb> alkisg: if you are using Guest Additions then probably yes.
<alkisg> michael-vb: ubuntu 16.04.2, I think it has some video module preinstalled?
<alkisg> I didn't install anything manually
<michael-vb> Can't remember what Ubuntu 16.04 provides.  Especially not .2.  Could you pnopaste your Xorg.0.log from the guest for reference?
<michael-vb> In any case, the Ubuntu maintainer for the VirtualBox drivers is not in this channel, so perhaps we should not be troubling other people with this.
<michael-vb> We could switch to #vbox for now with it.
<alkisg> michael-vb: if it's a vbox issue, of course, I'll come there, thank you
<michael-vb> tjaalton: so it looks like Debian (Sid at least) does not do kms drivers in the initrd.
<tjaalton> michael-vb: then I don't understand the original bug
<tjaalton> why it happens
<michael-vb> Should Xorg wait for udev to finish loading drm drivers before starting?  (It is udev, isn't it?)
<tjaalton> whatever starts xorg
<tjaalton> lightdm has
<tjaalton> After=systemd-user-sessions.service getty@tty7.service plymouth-quit.service
<michael-vb> And in Sid that is probably gdm.  So I should probably be asking whoever takes care of that.
<tjaalton> look at it's service file
<michael-vb> Thanks.
<michael-vb> Have to be moving, children to feed...
<tjaalton> After=rc-local.service plymouth-start.service systemd-user-sessions.service
<tjaalton> dunno what happens if there is no plymouth
<tjaalton> hmm nothing
#ubuntu-x 2017-03-17
<alkisg> I tried gathering more info for the "16 color depth split image" issue, and I got these:
<alkisg> My test case is, boot from the live cd, then run `sudo -i; wget http://paste.debian.net/plain/922125 -O /etc/X11/xorg.conf; chmod -w /etc/X11/xorg.conf; service lightdm restart` - sometimes it moves xorg.conf elsewhere and I have to do it  twice
<alkisg> It doesn't happen in KVM, http://termbin.com/kszu - using vesa instead of modesetting
<alkisg> vbox + ubuntu-mate 16.04.2 have the issue, http://termbin.com/m78q - with the modeset driver
<alkisg> vbox + ubuntu-mate 16.02.1 do NOT have the issue, http://termbin.com/66xu - with the modeset driver
<alkisg> So if I understand this correctly, it's a regression in the modesetting driver, and I should report it there?
<alkisg> ...where is "there"? :)
<tjaalton> xserver
<tjaalton> but test 1.19.3 first
<tjaalton> why using 16bpp?
<alkisg> tjaalton: is it enough if I test the 17.04 live cd?
<tjaalton> no
<tjaalton> it has 1.18.4
<alkisg> Which ppa would I need?
<tjaalton> ppa:canonical-x/x-staging
<alkisg> Thank you. We are using 16 bpp in thin clients in ltsp, because remote X needs half  the bandwidth there
<alkisg> It's like XDMCP, not VNC/RDP which compress data...
<tjaalton> you mentioned vbox before..
<alkisg> Yes, I was testing with vbox, and it was loading the modeset driver
<alkisg> So any client that will fall back to modesetting, will have that issue, I assume
<tjaalton> so is it the same issue with thin clients?
<alkisg> I think that if e.g. they have an intel card, no; but if they have something that would fall back to modesetting, like I don't know, sis, they would
<alkisg> Which graphics card should I choose to verify it on a real client?
<tjaalton> modesetting is only used if there's a kms driver
<tjaalton> and no "native" x driver
<tjaalton> so sis will have vesa
<alkisg> So that would be a really rare scenario?
<alkisg> Thin clients are unfortunately still used in thousands of schools worldwide
<alkisg> But if it'll just affect vbox, it's not an issue
<alkisg> Although, it just broke between 16.04.1 and 16.04.2, is it worth reporting it anyway?
<tjaalton> test 1.19
<tjaalton> 1.18 is dead to me :)
<alkisg> Sure, doing so...
<tjaalton> so what's the bug again?
<alkisg> tjaalton: https://snag.gy/H3FeMW.jpg
<tjaalton> default lightdm looked fine here
<tjaalton> unity doesn't load though
<alkisg> xdpyinfo | grep Depth, says 16?
<tjaalton> but I guess that's expected
<tjaalton> the background looks "bad", so I think so
<alkisg> compiz did have issues with 16 bpp in the past, but we don't care about that part
<tjaalton> yes, depth is 16
<tjaalton> test with intel
<alkisg> Intel uses the modesetting driver?
<tjaalton> on 16.04.2/16.10 and up
<tjaalton> i mean intel hw
<alkisg> But if the problem only happens with the modesetting driver, and intel doesn't use that, how would I see it in intel hardware?
<tjaalton> uh
<tjaalton> the xserver is patched to not load intel
<alkisg> Ah, ok then
<tjaalton> falls back on modesetting
<tjaalton> but only on 16.10 and the hwe backport
<tjaalton> same effect if you uninstall -intel on 16.04(.1)
<alkisg> On my current pc, I have: [    19.307] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
<alkisg> 16.04.2
<alkisg> Can I test on that?
<tjaalton> yes
<alkisg> OK, be back in 2 mins, thanks...
<alkisg> xorg crashes here when I try 16bpp
<alkisg> I tried it 3 times, and I had to REISUB to reboot
<alkisg> I have 2 graphics cards though, maybe it conflicts somewhere there, let me try it on another intel machine with just 1 card
<alkisg> I think that's the failed xorg: http://termbin.com/oumo
 * alkisg tries with 1 card...
<alkisg> It doesn't have an issue on 16.04.1, now upgrading that machine to .2...
<tjaalton> it has the same xserver
<tjaalton> could've just installed -intel if that's what you tested with on .1
<tjaalton> *uninstalled
<alkisg> in vbox, the problem didn't happen in 16.04.1 and did happen in 16.04.2
<alkisg> I already ran the apt command, will see in 2 mins...
<tjaalton> vbox updated then
<tjaalton> 4.4 vs 4.8
<alkisg> apt install --purge xserver-xorg-hwe-16.04 xserver-xorg-input-all-hwe-16.04; service lightdm restart => no issue yet, rebooting the machine...
<alkisg> Eh updating removed xorg.conf, so it wasn't a valid test yet...
<tjaalton> removed? doubt that
<tjaalton> oh
<tjaalton> actually yes, purging xserver-xorg(-hwe-16.04) does remove it
<alkisg> (yup; the intention there was to have xserver-xorg in purged state instead of ^rc)
<alkisg> I have the same issue with the 1-card machine, http://termbin.com/nkwv
<alkisg> -rw-r----- 1 root whoopsie 1,9M ÎÎ¬Ï  17 09:57 /var/crash/_usr_lib_xorg_Xorg.0.crash
<alkisg> Caps lock etc doesn't work at this point, but I do have ssh access
<tjaalton> broken config?
<alkisg> http://paste.debian.net/plain/922125
<alkisg> It works on 16.04.1 on the same machine
<alkisg> Let me try 4.4 + newer xorg...
<tjaalton> drop device/monitor sections, just leave identifier/defaultdepth on screen section.. that's what I used
<alkisg> Rebooting with http://termbin.com/npzg...
<alkisg> (had the same symptoms with 4.4 + newer xorg)
<alkisg> Same results with newer xorg.conf, here's the Xorg.0.log, http://termbin.com/56gt
 * alkisg tries -depth 16 manually...
<tjaalton> wait
<tjaalton> apt-cache policy libgbm1
<tjaalton> apt-cache policy libgl1-mesa-dri
<alkisg> xinit -- -depth 24 => OK, xinit -- -depth 16 => Xorg: ../../../../hw/xfree86/common/xf86Helper.c:1948: xf86ScrnToScreen: Assertion `pScrn->scrnIndex < screenInfo.numScreens' failed.
<tjaalton> nevermind, gbm/dri mismatch was for software rendering "bug"
<tjaalton> I don't know then, if i915.ko is loaded it should work just fine
<alkisg> libgbm1=12.0.6-0ubuntu0.16.04.1 500, libgl1-mesa-dri = 12.0.6-0ubuntu0.16.04.1 500
<tjaalton> and does work here
<alkisg> Maybe different chipset?
<tjaalton> shouldn't matter
<alkisg> I can test with the live CD, if it'll help
<alkisg> (to ensure that it's not an issue with my installation)
<tjaalton> which cpu do you have then
<alkisg> # lspci -nn -k | grep -A 2 VGA
<alkisg> 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller [8086:041e] (rev 06)        Subsystem: Gigabyte Technology Co., Ltd 4th Generation Core Processor Family Integrated Graphics Controller [1458:d000]        Kernel driver in use: i915
<tjaalton> well that's old
<alkisg>  grep model /proc/cpuinfo  => model name      : Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz
<tjaalton> oh sorry
<tjaalton> 4th gen core
<alkisg> Well, it still shouldn't crash :D
<tjaalton> not gen4
<tjaalton> haswell
<alkisg> After testing with the ppa, where would I file a bug report for this?
<tjaalton> which one?
<alkisg> The one you proposed that I should test xorg 1.19 with
<alkisg> Let me check the logs...
<tjaalton> your original bug
<tjaalton> that's in vbox I bet
<alkisg> Yes
<alkisg> Well, I have 2 cases where modesetting works in 16.04.1 and has issues in .2, in vbox the issue is split screen, in intel it's a crash
<tjaalton> and same 4.8 kernel on both?
<alkisg> Yes
<alkisg> I tried with 4.4 on intel, it still crashed
<tjaalton> while you say "modesetting" works it's using -intel on .1?
<tjaalton> because it's essentially the same xserver
<alkisg> On the stock 16.04.1, it worked. Would that load intel?
<tjaalton> yes
<alkisg> Then yes
<tjaalton> but
<tjaalton> you were testing on vbox..
<tjaalton> where it loads whatever
<alkisg> (09:45:22 ÏÎ¼) ***alkisg tries with 1 card...
<alkisg> (09:52:11 ÏÎ¼) alkisg: It doesn't have an issue on 16.04.1, now upgrading that machine to .2...
<alkisg> That was one of the recent tests I did "just now"
<tjaalton> yeah I'm just super confused at this point. file whatever
<tjaalton> I can't reproduce this "crash" with skylake
<alkisg> Where would I file it?
<alkisg> I'll start with the intel crash
<tjaalton> tried it on 16.04.1 and 17.04+ppa
<alkisg> Could you please try: xinit -- -depth 16
<tjaalton> I'm reading the log instead
<tjaalton> and I can see how the lightdm background looks crappy
<tjaalton> and login fails
<tjaalton> so it's using 16bpp alright
<alkisg> Yes, but I meant, so that we have a common action to try to reproduce it
<alkisg> It's simpler than trying a xorg.conf
<tjaalton> I don't have your environment
<alkisg> (which can vary)
<tjaalton> oh
<tjaalton> xinit
<tjaalton> misread
<alkisg> sudo service lightdm stop; xinit -- -depth 16
<tjaalton> works
<alkisg> OK, then I guess it only affects a few intel chipsets
<alkisg> I'll see at home if I can reproduce it with a 6th gen one
<alkisg> (i3 6100p if I remember correctly)
<tjaalton> well, could repro it with BDS
<tjaalton> BDW
<alkisg> Nice :)
<tjaalton> i guess the intel X driver does some tricks
<alkisg> tjaalton: should I test the staging ppa?
<tjaalton> file a bug on freedesktop drm/i915
<tjaalton> it doesn't help
<alkisg> OK, thank you very much
<alkisg> tjaalton: can I test with forcing the intel driver instead of the modesetting one?
<tjaalton> test what?
<tjaalton> depth 16 works there
<alkisg> Ah, ok
<alkisg> Reported https://bugs.freedesktop.org/show_bug.cgi?id=100246, hopefully I got it right
<ubottu> Freedesktop bug 100246 in Driver/intel "Xorg crashes with 16bpp on i3-4150" [Normal,New]
<tjaalton> wrong component, and never paste logs :)
<tjaalton> should be dri/i915
<tjaalton> dunno why I can't change that..
<michael-vb> tjaalton: regarding the person who had Xorg loading before the video driver, I suggested he add "ExecStartPre=/bin/udevadm settle" to the display manager service file (it was lightdm) and that seemed to do the trick.
<michael-vb> The question is, who should I talk to about that?  It seems to me that something on those lines would make general sense, but it might well be something else on those lines.
<tjaalton> michael-vb: file a bug against lightdm
<michael-vb> I should check, but it probably affects gdm too.
<michael-vb> And I have a suspicion it might want fixing somewhere further upstream.
<tjaalton> i don't know where that would be
<michael-vb> Any idea who might, or just file the bug as you suggested and wait for the response?
<tjaalton> you can try the udev/systemd folks..
<michael-vb> Looking at the .orig archives for gdm3, plymouth and systemd, gdm3 is "After" plymouth-start.service and plymouth-start.service is "After" systemd-udev-trigger.service.  The manual page is not quite clear to me: does udevadm trigger also wait for all events to be handled?
<tjaalton> dunno
<michael-vb> Right, looking at it I get the feeling that it is a problem in the Debian lightdm package.
<michael-vb> So your first suggestion applies.
<alkisg> michael-vb: I bumped into this page today: https://wiki.archlinux.org/index.php/LightDM#LightDM_does_not_appear
<alkisg> It may happen that your system boots so fast that LightDM service is  started before your graphics drivers are properly loaded. If this is  your case, you will want to add the following config to your  lightdm.conf file:     [LightDM]    logind-check-graphical=true 
<alkisg> I don't know if it applies or helps in that person's case....
<michael-vb> Interesting in any case.  Thanks.
<alkisg> np
<alkisg> tjaalton: I could not reproduce the xorg crashing issue at home, on i3-6100.
<alkisg> About the other issue that I was having with the ghost e-DP1 monitor, it's like this: kernel 4.4 => no ghost monitor, 4.8 => a ghost monitor called e-DP1, 4.11 => a ghost monitor called DP-1, while the real VGA one is DP-2. Should I test anything else before reporting it, and where would I report it? Thanks again!
<michael-vb> alkisg: the user tried your suggestion above and it worked.  They also see the same problem with Fedora and lightdm.  (They helpfully initially said "Fedora" without mentioning lightdm, leaving me assuming GNOME Shell.)
<alkisg> michael-vb: glad I could help; so it appears others have bumped into that as well, since it's documented in a wiki
<michael-vb> Yes, thanks.
<tjaalton> alkisg: dri/drm/i915
<alkisg> tjaalton: thank you very much again
<tjaalton> your cpu is a skylake, so same as here
<tjaalton> might suggest it's actually a bug in i965_dri
<tjaalton> so mesa
<tjaalton> gen4 was busted too, hung the machine
<alkisg> Nonono it took us 6 months of talking to the mayor to get those machines, we won't see new ones for the next 10 years :D
<tjaalton> huh?
<tjaalton> skylake is fine is it not?
<alkisg> It sure is, I thought that when you said "gen4", you were referring to my work pc, which is i3-4xxx
<alkisg> (the one that had the xorg crash issue)
<alkisg> So skylake has the ghost monitor issue, while broadwell has the xorg crash issue
<tjaalton> gen4 = 965GM
<tjaalton> = old
<alkisg> OK; but I don't think we tested that anywhere today
<tjaalton> the "crash" is on < gen9
<tjaalton> I did
<alkisg> Ah, so I could reproduce it on some older machines that I have
<alkisg> Thanks, and sorry for misunderstanding
<tjaalton> you already did..
<alkisg> I only tested on broadwell, I didn't test on 965gm
<tjaalton> i did
<alkisg> Yup, I got that part.
<tjaalton> you tested haswell
<alkisg> i3-4xxx is haswell? eh, sorry, my bad then
<alkisg> Too many numbers and names :D 8th generation and 4xxx and haswell... confusing :D
 * alkisg notes that the ghost monitor issue also happens on another skylate processor, model name      : Intel(R) Pentium(R) CPU G4400 @ 3.30GHz
#ubuntu-x 2018-03-12
<ricotz> tjaalton, hi, will vulkan 1.0.68 make it into bionic?
<tjaalton> ricotz: most likely, 1.1.70 too
<tjaalton> just about to upload it to debian
<ricotz> ok, it is still on 1.0.61.1+dfsg1-1ubuntu1 ;)
<tjaalton> right
<tjaalton> oh
<tjaalton> it should've been synced earlier
<tjaalton> anyway, there's a FFE ug
<tjaalton> bug
<ricotz> this was my intention to point out :)
#ubuntu-x 2018-03-13
<soee_> mamarley: 390.42 released :)
 * ricotz noticed :)
<ricotz> tseliot, hi
<ricotz> tseliot, https://paste.debian.net/plain/1014452
<ricotz> the content of debian/templates/nvidia-kernel-source-flavour.install.in doesn't look like the best idea
<mamarley> ricotz: I guess you are already working on it then?
<mamarley> Sorry, I was hacking on another project yesterday and didn't notice.
<ricotz> mamarley, yeah, I am looking at it, but I am not sure how to deal with anything before bionic yet
<mamarley> ricotz: I would think just do it the same way we did 390.25 (use the old-style packaging).
<ricotz> mamarley, this will cause source package conflicts and maybe a burden to keep conflict/replaces updated with later releases
<mamarley> Hmm, yes.  Well I guess the only alternative would be to use the new-style packaging without glvnd.
<ricotz> bbl
<mamarley> tseliot: ^Perhaps you have some input on this?
<tseliot> mamarley: are you talking about Ubuntu releases older than 18.04?
<mamarley> Yes.
<tseliot> I am going to backport the new packaging without glvnd
<tseliot> I just need to finish hybrid graphics support
<ricotz> mamarley, https://launchpad.net/~ricotz/+archive/ubuntu/experimental/+sourcepub/8852483/+listing-archive-extra
<ricotz> tseliot, ^ there you can grab the tarballs
<ricotz> tseliot, do you already a have a wip branch for those backports?
<tseliot> ricotz: thanks, I'll get those tarballs
<tseliot> and no, not even a WIP branch yet
<ricotz> tseliot, ok
<ricotz> tseliot, don't use the package of those builds though ;)
<ricotz> *packaging
<tseliot> no, I always use mine
<ricotz> good
<tseliot> let's see if I can make the nvidia-kernel-source install file simpler
<ricotz> I see the intention doing it like this, but it isn't even sorted :(
<ricotz> I didn't dare to check, but are there any files filtered out that way?
<ricotz> mamarley, copied to have it at least for bionic now
<ricotz> mamarley, are you running 4.16 already?
<mamarley> ricotz: Awesome!  I am about to head to work right now, but I will try it a bit later.
<mamarley> ricotz: Nope, sorry, I was planning on upgrading at -rc6.
<ricotz> mamarley, alright, no problem
<mamarley> ricotz: But I will of course patch the driver for 4.16 if necessary when I upgrade.
<ricotz> mamarley, I have added a patch
<mamarley> Oh, OK.  Thanks!
<ricotz> but let's call it a hack
<soee_> So for 16.04 debs we will have to wait right?
<mamarley> soee_: Yes, sorry. :(
<soee_> mamarley: np :)
<tseliot> ricotz, mamarley: I have just pushed a solution for nvidia-kernel-source to my 390 branch
<ricotz> tseliot, ok, don't forget to add debian/nvidia-fallback.service
<tseliot> ricotz: I must have deleted that by accident, let me fix that
<tseliot> ricotz: I had to force update, but it's there now
#ubuntu-x 2018-03-14
<tseliot> ricotz: don't use the code I pushed yesterday, as I hadn't tested it, and it's broken
#ubuntu-x 2018-03-15
<tseliot> ricotz, mamarley: I don't know if it's the new nvidia, but gnome-shell crashes pretty often here in bionic
<tseliot> oh, and I added a new kernel patch for 4.15 and prime sync
<ricotz> tseliot, alright
<ricotz> tseliot, currently not running gnome-shell here
<ricotz> runs fine on 4.16rc4 here
<tseliot> ricotz: yes, it looked like a problem with appindicators, so not even the stock shell
<tseliot> ricotz: I only need to get around a build-dep on dh_systemd (which I don't need), then I should be ready to upload
<ricotz> tseliot, I see, I am not running the ubuntu session, so only the GNOME if I use it
<ricotz> tseliot, dh_systemd is included in debhelper since 10.x
<tseliot> ricotz: I know. I just need to make sure that lintian doesn't complain about it, since I want to backport all that to 16.04
<ricotz> 9.20160709 even
<tseliot> it recommends this: debhelper (>= 9.20160709~) || dh-systemd
<tseliot> but the one in 16.04 is older
<tseliot> but should still work, as we use it in ubuntu-drivers-common
<ricotz> just do that
<tseliot> I need to lose the --with systemd thing
<ricotz> debhelper (>= 9.20160709), debhelper (>= 9.20160709~) || dh-systemd
<ricotz> ah right
<tseliot> and call dh_systemd_enable in the debian/rules. No problem
<tseliot> ricotz, mamarley: I've just uploaded the new driver in bionic. BTW, the patch that I mentioned should fix LP: #1752739
<ubottu> Launchpad bug 1752739 in nvidia-graphics-drivers-390 (Ubuntu) "PRIME Synchronization doesn't work with linux-kernel 4.15." [High,In progress] https://launchpad.net/bugs/1752739
 * tseliot pushed all the changes to the 390 branch
<soee_> Why nvidia isn't working on things like prime working on linux?
<tjaalton> they are
<tjaalton> that's part of why GLVND exists
<tseliot> soee_: disabling the dGPU doesn't work yet, but I'm working on it. The rest should work
<tseliot> tjaalton: I don't see nvidia-graphics-drivers-390 (390.42-0ubuntu1) in the archive. Is the archive frozen?
<tseliot> the emails I receive don't say so
<tseliot> *received
<tseliot> Announcing to bionic-changes@lists.ubuntu.com
<ricotz> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/390.42-0ubuntu1
<tseliot> why can't I see it here? https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390
<ricotz> might be in limbo between -proposed and archive
<tseliot> yes, that confirmation email arrived 23 minutes ago
<tjaalton> tseliot: you need to pay attention to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<tjaalton> looks like it's a valid candidate for the next publisher run
<tjaalton> there you can see how getting something like xorg-server to the release is a pain
<ricotz> tseliot, you can trust apt here
<tjaalton> totally random autopkgtests failing, no other way than blindly rerun those, or ask someone to mark them as failing
<ricotz>      390.42-0ubuntu1 500
<ricotz>         500 http://archive.ubuntu.com/ubuntu bionic-proposed/restricted amd64 Packages
<tseliot> tjaalton: this is quite funny
<tseliot> dpkg: dependency problems prevent removal of dkms:  nvidia-dkms-390 depends on dkms.
<tjaalton> where's that?
<tseliot> I suspect the tests need to be updated
<tseliot> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/n/nvidia-graphics-drivers-390/20180315_153148_58ed5@/log.gz
<tjaalton> the tests aren't holding it back
<tseliot> I got there from the i386 test http://autopkgtest.ubuntu.com/packages/n/nvidia-graphics-drivers-390/bionic/i386
<tjaalton> it says "valid candidate"
<tseliot> autopkgtest for nvidia-graphics-drivers-390/390.42-0ubuntu1: amd64: Test in progress (always failed), armhf: Test in progress (always failed), i386: Always failed
<tjaalton> yes, you can of course fix those but it's not holding it back
<tseliot> yes, but we should fix them
<tjaalton> tests marked as red are
<tjaalton> or would be
<tseliot> yep
<soee_> Any chnace to have latest driver on 16.04 soon ?
<tseliot> soee_: not in the archive, I need to backport the driver packaging, and it's a non trivial amount of work
<tseliot> I'll do that as soon as my work in bionic is complete
#ubuntu-x 2019-03-12
<alkisg> tjaalton: Hi Timo! Re: LP #1815172, I would need to contact the schools that were seeing the issue and ask them to do a reverse VNC connection. I.e. it requires a bit of effort. Is it necessary, or can we just let them test after it's published?
<ubottu> Launchpad bug 1815172 in linux (Ubuntu Cosmic) "Black screen on skylake after 18.0 => 18.2 update" [Medium,New] https://launchpad.net/bugs/1815172
<alkisg> E.g. if there's just a 10% possibility for a regression, I'd just let them test it after it's released...
<tjaalton> alkisg: the bug won't get verified without testing, and the package won't get released without all bugs verified
<tjaalton> but, wasn't this fixed with the current package already?
<alkisg> Yes, it was
<tjaalton> ok, then i think we can bypass the re-test
<alkisg> Great
#ubuntu-x 2019-03-16
<ricotz> tjaalton, hi, vulkaninfo reports 1.1.97 while 1.1.101.0 packages are installed?
<ricotz> I assume the vulkan-tools packages wasn't built properly against the newer vulkan-loader while there was not explicit version bump in the package
<tjaalton> could be
<tjaalton> need to automate bumping the build-dep..
<Vuurdraak> hi everybody , i encounter various problems today when i installed the latest 4.4.0.143 kernel, the drivers from the extra driver ppa no longer work on the new kernel, only the main 384 driver works & nouveau, when installing the 4.15 kernel, no single driver including nouveau works anymore on my system -> ubuntu 16.04 lts 64bit
<Vuurdraak> i was asked to report it here 
<Vuurdraak> sorry i mean 384 nvidia driver
<tomreyn> "extra driver ppa" seems to be https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
<tomreyn> accroding to chat on #ubuntu, Vuurdraak has been trying to build nvidia-graphics-drivers-415 from the PPA on 16.04 and ran into "too many arguments to function âget_user_pagesâ" (known as bug 1573508 for supported packages)
<ubottu> bug 1573508 in nvidia-graphics-drivers-384 (Ubuntu Xenial) "SRU Request: nvidia-*: nvidia-* kernel module failed to build [error: too many arguments to function âget_user_pagesâ]" [High,Fix released] https://launchpad.net/bugs/1573508
<Vuurdraak> this was the make.log: https://pastebin.com/zEQwLjM4
<Vuurdraak> sorry for using pastebin :')
<tomreyn> Vuurdraak: you will probably not receive a response to this report here during the weekend, maybe none at all. but there is a chance the PPA dev's will read it next week.
<Vuurdraak> yeh its okay, i just did it to report it
<tomreyn> you could also file a bug report here: https://bugs.launchpad.net/~graphics-drivers
<tomreyn> according tot he topic this is the preferred approach
<tomreyn> Vuurdraak: file it here https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-415/+filebug and once you did, click on "Subscribe someone else" and add "Graphics Drivers" (~graphics-drivers)
<Vuurdraak> i get an error page when trying to file the bug 
<Vuurdraak> i made a new past, cause the original one expiers in one day: https://paste.ubuntu.com/p/dTdgj4M4bZ/
<Vuurdraak> @ tomreyn
<tomreyn> Vuurdraak: what does the error say when you try to file a bug?
<tomreyn> i won't file it for you, the original reporter must be affected by a bug.
<Vuurdraak> Oops!
<Vuurdraak> Sorry, something just went wrong in Launchpad.
<Vuurdraak> Weâve recorded what happened, and weâll fix it as soon as possible. Apologies for the inconvenience.
<Vuurdraak> (Error ID: OOPS-cd34e1eb47798220d92f78fe298784d6) 
<Vuurdraak> weirdly enough when i tried to get to the bug report thing from the main launchpad website, i cant even get to the bug report page, it automaticly sends me to ubuntu help
<Vuurdraak> when im at: https://launchpad.net/ubuntu , and click on the "Report a bug" link that points acording to the browser to: "https://bugs.launchpad.net/ubuntu/+filebug" when i click it it sends me to: "https://help.ubuntu.com/community/ReportingBugs"
<Vuurdraak> maybe im not allowed to report bugs ?
<tomreyn> it doesn't really help to run a linux distro based on rotten infrastructure. :-/
#ubuntu-x 2019-03-17
<tjaalton> ?
<tjaalton> filing bugs needs you to be logged in
<tjaalton> I don't think vuurdraak was
<tjaalton> or even has an account on lp
<tjaalton> oh, lp oops? yeah, weekend :D
<tomreyn> LP seems to be happy to break on weekends as much as it does during the week, so... ;-)
#ubuntu-x 2020-03-11
<tjaalton> tseliot: check ubuntu-devel-discuss@, someone is concerned about some file install path
<tjaalton> nvidia_layers.json
<tjaalton> also https://github.com/godotengine/godot/issues/36790
<tjaalton> tseliot: when will 440.64 enter focal?
<tseliot> tjaalton, probably today, I was just waiting to test the nvidia-settings, then it should be all good to go
<tjaalton> ok, great
<tjaalton> it fixes build with 5.6, do you think the fix is easily backported to 390 too?
<tjaalton> ah there seems to be some failure, I'm asking for the log..
<tjaalton> or could just build it myself..
<tseliot> tjaalton, we'll see what is wrong there. Where can I find the new oem kernel? (ppa?)
<tjaalton> bootstrap ppa, both oem and unstable kernel (no diff between them)
<tjaalton> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap
<tjaalton> though only oem has a working metapackage..
<tseliot> ok, thanks
#ubuntu-x 2020-03-12
<tseliot> tjaalton, I missed your message about the json file. Which thread is that?
<tjaalton> there aren't many, 'libnvidia-gl-435'
<tjaalton> and not a thread, just a single email :)
<tseliot> I don't really see it here
<tjaalton> ubuntu-devel-discuss?
<tjaalton> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2020-March/018601.html
<tseliot> oh, I'm subscribed to ubuntu-devel, I had no idea about ubuntu-devel-discuss
<tjaalton> it's the open list
<tjaalton> -devel is moderated and pretty much dead
<tjaalton> well, both are moderated, -devel has some other restrictions
<tjaalton> been like that for 15y :)
<tjaalton> sorry, 13
<tseliot> well I've just subscribed
<tseliot> I have filed https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-435/+bug/1867128
<ubottu> Launchpad bug 1867128 in nvidia-graphics-drivers-440 (Ubuntu) "Install nvidia_layers.json in /usr/share/vulkan/implicit_layer.d" [Medium,In progress]
<tjaalton> ok, cool
