#ubuntu-x 2006-12-18
<Ubugtu> New bug: #76233 in xserver-xorg-video-ati "No 3D GL Acceleration (DRI) for ATI Radeon 7500x" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76233
<Ubugtu> New bug: #76155 in linux-restricted-modules-2.6.15 (restricted) "Kubuntu 6.06 security update to linux-image-2.6.15-27-k7 breaks nVidia1.0.8776+2.6.15.12-1 Xorg crashes when exiting" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76155
<Ubugtu> New bug: #76260 in xorg "x11-common conflicts with xxkb, but xxkb depends on x11-common inderectly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76260
<Ubugtu> New bug: #76297 in xserver-xorg-video-i810 "GLX broken" [Undecided,Needs info]  http://launchpad.net/bugs/76297
<Ubugtu> New bug: #76327 in mesa "Edgy's DRI performance halved" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76327
<Ubugtu> New bug: #76330 in linux-restricted-modules-2.6.17 "Latest security update breaks nvidia kernel module" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76330
#ubuntu-x 2006-12-20
<Ubugtu> New bug: #76618 in xterm (main) "Contents LD_LIBRARY_PATH cleared by xterm" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76618
#ubuntu-x 2006-12-21
<Ubugtu> New bug: #76689 in xorg-server (main) "Lose Colors and Text with Compiz on PPC" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76689
<Ubugtu> New bug: #76791 in xorg (main) "X savage driver problems (dapper)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76791
#ubuntu-x 2006-12-23
<Ubugtu> New bug: #76978 in xorg (main) "Nvidia FX5500 use vesa instead of nv (Feisty Herd1)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76978
<Ubugtu> New bug: #77022 in xorg-server (main) "having nvidia-glx installed messes up i810 dri" [Undecided,Unconfirmed]  http://launchpad.net/bugs/77022
#ubuntu-x 2007-12-17
<ubotu> New bug: #176809 in xserver-xorg-video-intel (main) "X crashes when starting any 3D app with 965GM" [Undecided,New] https://launchpad.net/bugs/176809
<ubotu> New bug: #165253 in xserver-xorg-video-openchrome (main) "cannot select via or openchrome driver in screens & graphics dialog" [Undecided,Incomplete] https://launchpad.net/bugs/165253
<ubotu> New bug: #116919 in xserver-xorg-input-synaptics (main) "The Synaptic Touchpad is not disabled automatically when an external mouse is attached." [Undecided,New] https://launchpad.net/bugs/116919
<mvo> bryce: can I nag about the file overwrite problem in libx11-data <-> libx11-6 for dapper->hardy upgrades again?
<bryce> sure, what's the bug id?
<mvo> its launchpad bug #176555
<ubotu> Launchpad bug 176555 in libx11 "libx11-6 / libx11-data conflict during upgrade from Dapper" [Medium,Confirmed] https://launchpad.net/bugs/176555
<bryce> ok, were there any issues found with adding that conflicts?
<mvo> bryce: the patch is wrong (sorry, haven't looked at it)
<mvo> bryce: it should be a replaces instead of a conflict
<mvo> sorry, I haven't looked at the patch, just at the bug (I got it in my auto-upgrade-tester script)
<bryce> aha
<bryce> ok, rolling patch
<mvo> cool, thanks
<tjaalton> uh, it used to have that.. but then I filed a sync request
<bryce> tjaalton: hrm, sounds like something to push upstream?
<tjaalton> or something like that, and it got dropped
<tjaalton> perhaps, it's simple
<mvo> heh :) I remember that we fixed this but then I wasn't sure anymore
<bryce> in any case, if you want to reupload the change, I've stuck it here:  http://people.ubuntu.com/~bryce/Uploads/
<bryce> sounds like the priority would be to get this into debian though
<tjaalton> oh wait, it's committed already, but -2 is not released yet :)
<tjaalton> +Replaces: libx11-6 (<= 2:1.0.0-1)
<tjaalton> bryce: I've got the xorg merge ready, xresprobe is now gone
<bryce> awesome
<bryce> tjaalton: hold off on that until after alpha-2 is out (later this week)
<tjaalton> why?
<tjaalton> we need testers, no?
<bryce> well...
<bryce> ok if you're confident it's not going to break things too badly for people, it can go in
<tjaalton> it's not that much different compared to alpha1 ("no xorg.conf") :)
<bryce> heh, true
<bryce> speaking of which, what needs done to fix that?  I should put some time into that bug
<bryce> (btw, deb of the libx11 change is up - http://people.ubuntu.com/~bryce/Uploads/)
<tjaalton> and that's simple to fix in livecd-rootfs (create a new file after it removes the existing one)
<tjaalton> then the situation would be the same as after preinst
<tjaalton> =empty file, and a md5sum that matches it
<bryce> how do you mean?
<bryce> like add a call to dexconf in one of the livecd scripts?
<tjaalton> no, the session runs reconfigure already, but currently that fails
<tjaalton> so we don't need to touch anything in addition to livecd-rootfs
<tjaalton> I'm not sure what actually broke this in hardy, but it's a lot more complicated to fix in xserver-xorg
<tjaalton> l-r removes the file because it needs to have a clean start (=dpkg-reconfigure xserver-xorg), but that fails because the postinst notices that there is no xorg.conf, and thinks that's how the user wants
<bryce> hrm
<bryce> heya tormod
<tormod> heya bryce
<bryce> hmm
<bryce> so, is the right fix to make livecd-rootfs not remove that file to begin with, or to add a control for the dpkg-reconfigure xserver-xorg call to make it generate the xorg.conf even if it's missing, or...?
<tjaalton> I'm thinking that let it remove the file, then touch a new one (=md5sum matches since it's empty as the one created on preinst) :)
<tjaalton> and do that in livecd-rootfs
<bryce> will that fix the issue though?
<tjaalton> it should
<tjaalton> since that's pretty much how the preinst would have done
<tjaalton> although I'm not sure if the md5sum should be recreated also
<tjaalton> probably
<tjaalton> look at livecd.sh from livecd-rootfs
<tjaalton> it does all sort of cleaning on the chroot
<bryce> ok
<mvo> bryce: for me xserver-xorg postinst hangs on dapper->hardy in noninteractive mode, it seems like something is trying to read from stdin, could you think of anything that might cause this? it may well be a artifact, I'm digging into it currently
<jcristau> probably a bug in the debconf code in the postinst?
<mvo> its not reading from stdin, its something with debconf
<mvo> 0 is connected to a debconf pipe
<jcristau> right
 * mvo looks closer
<bryce> hmm, if postinst doesn't know how to configure the hardware I guess it might prompt for the device or something, however wouldn't running in non-interactive mode prevent that?
<jcristau> debconf won't prompt if DEBIAN_FRONTEND=noninteractive
<mvo> http://paste.ubuntu.com/2819/ has the debug log
<mvo> I killed it at this point via ctrl-c, it seems to hang forever
<bryce> hmm, I'm not too familiar with the cirrus driver
<jcristau> bryce: it has nothing to do with the driver
<bryce> jcristau: is it quitting when it doesn't find valid modes?
<jcristau> the postinst calls db_stop, and hangs there
<bryce> before that there's a modes call, and it looks like it returned an empty string
<tjaalton> well, that part of the postinst is now gone anyway ;)
<bryce> right, which is why I'm wondering if the cirrus driver lacks xrandr support or something
<tjaalton> the debug log is from an older version which still used xresprobe..
<bryce> ahh
<mvo> is it? it should be the latest available one in hardy
<mvo> 1:7.3+7ubuntu3 unless I'm very mistaken
<tjaalton> mvo: it is, I haven't uploaded +8ubuntu1 yet
<jcristau> actually s/the postinst/dexconf/
<tjaalton> ah ok, but still?
<mvo> should I wait for this upload instead of poking it some more?
<jcristau> i don't think it's related to choosing modes. that part doesn't hang.
<jcristau> dexconf calls db_get xserver-$SERVER/config/display/modes, writes the screen section, then calls db_stop, and hangs there
<jcristau> i have no clue about debconf though :/
<bryce> hmm, if it's dexconf failing, the only noteworthy error exit after db_stop, is this:
<bryce> # Ensure we can write to our destination if it already exits.                            
<bryce> if [ -e "$XF86CONFIG" ]; then
<bryce>   if [ ! -w "$XF86CONFIG" ]; then
<bryce>     bomb "unable to write to \"$XF86CONFIG\""
<bryce>   fi
<bryce> fi
<jcristau> it's hanging at db_stop 
<jcristau> not after that, i think
<bryce> hmm, well all that does is this:
<bryce> db_stop () {
<bryce>         echo STOP >&3
<bryce> }
<jcristau> hrm.
<jcristau> i think i hit something like that a while ago, and didn't manage to understand what went wrong
<mvo> I think I have a better trace, give me a sec
<mvo> http://paste.ubuntu.com/2822/ <- that include ctrl-c bits at the end, it hangs at "read -r _db_internal_line"
<mvo> I suspect the earlier db_stop and then a db_unregister might be the problem?
<jcristau> yeah
<jcristau> right, so postinst calls dexconf, which calls db_stop, and the postinst tries to use debconf after that -> fail
<jcristau> mvo: try moving the if block around db_unregister before "if [ -z "$UPGRADE" ] || dpkg --compare-versions "$2" le "1:7.0.14"; then"
<mvo> jcristau: yeah, that fixes it
<jcristau> mvo: thanks
<mvo> thanks for looking into it with me :)
<tjaalton> so should I change that for this upload?
<mvo> if you have a upload pending, it would definitely be nice to have it
<tjaalton> ok will do
<jcristau> tjaalton: i'll push a fix to the debian-unstable branch
<mvo> I can run another upgrade test tomorrow to check if all is good, its 100% reproducable here in my VM
<tjaalton> jcristau: ok, I'll pull from you then :)
<mvo> maybe a comment somewhere that explains that dexconf can run db_stop would be good as well so that its easier to find this kind of error in the future (or to avoid it entirely :)
<jcristau> mvo: indeed
<jcristau> tjaalton: i'll test a lenny -> sid upgrade before i push the change
<tjaalton> jcristau: ok, cool
<bryce> brb (lunch)
<jcristau> for some reason, a lenny -> sid upgrade works fine.
<jcristau> i'd have thought it would hit the same bug
<tjaalton> jcristau: lenny has newer xserver-xorg than 7.0.14, right? Doesn't it in that case skip the dexconf-phase completely?
<jcristau> ah. hum. true
<jcristau> pushed
<jcristau> mvo: thanks again
<tjaalton> btw, I get a lintian warning: 'xorg source: stronger-dependency-implies-weaker depends -> recommends ${F:XServer-Xorg-Detect-Depends}'
<tjaalton> any idea why? this was not the case with +7ubuntu*
<jcristau> the Detect stuff is only in Recommends afaics?
<tjaalton> yes
<jcristau> i suspect a lintian bug
<mvo> cheers, happy to help
 * mvo waves
<bryce> tjaalton: how's this look?  http://people.ubuntu.com/~bryce/Testing/livecd-rootfs/
<tjaalton> bryce: I think that should do
<bryce> think we should check with cjwatson first, or just upload?
<tjaalton> bryce: nah, he already said that it's fine to commit to bzr and upload
<bryce> is there an easy way we could test this out to make sure it solves it?
<tjaalton> create the rootfs and reconfigure xserver-xorg on it
<tjaalton> maybe that would do
<tjaalton> ok, uploading xorg merge with the debconf-fix
<tjaalton> I can test the livecd stuff tomorrow
<bryce> cool, thanks
<bryce> I'm committing the change to bzr now
<tjaalton> great
<bryce> looks like the last change was UNRELEASED; I don't know what that means
<bryce> oh, I think I understand
<tjaalton> it's also used by the debian git
<tjaalton> to accumulate changes before an upload
<bryce> ok here we go - http://people.ubuntu.com/~bryce/Testing/livecd-rootfs/
<bryce> that's generated against hardy and includes colin's unreleased change
<bryce> so tomorrow, if it tests out ok, I think it can be uploaded
<tjaalton> hmm, the release should probably be hardy :)
<tjaalton> or do you mean that change it when it works
<bryce> right
<tjaalton> ?
<tjaalton> ok
<bryce> hmm, I can't push to bzr
<tjaalton> maybe it needs core-dev powers?
<bryce> probably
<tjaalton> damn, I need to learn bzr then :)
<bryce> anyway, that should be good for testing
<tjaalton> sure
<bryce> heh, this is all I did:
<bryce>   622  bzr clone https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk livecd-rootfs
<bryce>   623  cd livecd-rootfs
<bryce> work work work
<bryce>   638  bzr diff > leave_token_xorg.patch
<bryce>   641  bzr commit
<bryce> edit edit
<bryce>   644  bzr push https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk
<tjaalton> sounds git enough :)
<bryce> yup
<tjaalton> ok, I'll push that tomorrow when (!) it works
<bryce> kewl
<tjaalton> time to go to bed now, night!
<bryce> my goal for today is to finally get this xserver git-head built
<bryce> so I'm keeping fussing with it - now need to get mesa git-head built...  *sigh*
<bryce> anyway, night, cya tmrrw
#ubuntu-x 2007-12-18
<jcristau> tjaalton: lintian bug filed.
<ubotu> New bug: #126861 in xserver-xorg-video-intel (main) "OpenGL crashes x61s" [Undecided,New] https://launchpad.net/bugs/126861
<bryce> beh, backporting mesa from git-head is a PITA
<bryce> it's not worth this much effort :-P  I'm calling time
<tjaalton> hehe
<bryce> btw, we probably should move libpciaccess-dev into main during hardy; if/when people ask for xserver backports we'll want that in
<bryce> huh, this is odd - https://bugs.launchpad.net/xorg-server/+bugs
<bryce> are those misfiled bugs?
<tjaalton> no, it's the "upstream component"
<tjaalton> meaning upstream xorg
<tjaalton> although it's misnamed
<bryce> oh, is this how launchpad tracks bugs linked to it from bugzilla?
<tjaalton> it's not automatic, someone has created that one
<bryce> huh
<tjaalton> when you mark a bug to affect a project, it selects this "X.org X server" automatically for some components, like savage
<tjaalton> it would be better to have just X.org I think
<bryce> yup
<tjaalton> but there's no way to edit the project
<tjaalton> oh, there is X.Org already
<tjaalton> ah, so xorg-server is a subproject
<superm1> twb, what exactly were you trying to accomplish with openchrome?
<twb> Because I don't want to rollout hardy, I'm trying to force xserver-xorg to use vesa in xorg.conf
<twb> I'm doing fully automated d-i net installs to a bunch of (hopefully) homogeneous laptops.
<superm1> twb, would a backport of openchrome help then?
<superm1> perhaps
<twb> Possibly
<twb> I tried seeding these, which apparently had no effect:
<twb> xserver-xorg xserver-xorg/config/autodetect_video_card boolean true
<twb> xserver-xorg xserver-xorg/config/device/driver select vesa
<twb> Oh damn
<superm1> if you want to grab the dsc and build it on gutsy you can give it a spin
<twb> Now I *read* the first one I see it should be false :-/
<superm1> hehe
<superm1> :)
<twb> I wasted ninety minutes testing that
<tjaalton> yes, set that to false and it should work
<superm1> you will get a lot better performance out of openchrome than vesa, so if these all support openchrome, it would be worthwhile to switch it over
<tjaalton> that's what I use here :)
<twb> I'm quite cabable of backporting by hand should the need arise, but for the immediate future I want to make vesa work.
<superm1> k
<superm1> bryce, speaking of which, should that MIR idea for openchrome be revisited now?
<tjaalton> bryce: are you still around?
<superm1> considering it uses a different module name 
<superm1> and no longer just 'via'
<tjaalton> superm1: it probably should
<tjaalton> and perhaps replace via as the default (like fedora9 does)
<superm1> well but not all the cards support openchrome?
<tjaalton> I thought it was just a fork
<superm1> it forked from unichrome at some point
<tjaalton> hmm
<superm1> but there was separate development, and hence different supported hardware
<superm1> i swear there is a table somewhere that lists it all
<superm1> let me see if i can find it
<tjaalton> the driver code :)
<twb> Upstream svn openchrome calls itself openchrome_thingy.so
<twb> Where thingy ~= dri
<superm1> so via forked into unichrome, and unichrome forked into openchrome
<superm1> http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=HardwareCaveats
<twb> Incidentally if anyone knows how to simply tell the default driver to work on the LCD head, that would be great, too.
<tjaalton> hmm, so 2d is supported for all of them?
<twb> I tried telling it the panel resolution (1280x800, yecch) and playing with the Fn-<display> chord, but only got garbage on the laptop LCD except when using svn openchrome or vesa.
<twb> (Telling it in the device stanza, I mean.)
<tjaalton> openchrome seems to support lot more chips than via
<twb> Somebody suggested that the via driver is just an old snapshot of unichrome
<twb> He might have been on crack at the time, tho...
<ubotu> New bug: #177138 in xserver-xorg-video-intel (main) "Display will not start because bad frecuency choosed by Intel i810 driver" [Undecided,New] https://launchpad.net/bugs/177138
<ubotu> New bug: #177029 in linux-restricted-modules-2.6.22 (restricted) "Video Play back corrupted after making ANY change to Desktop Effects" [Undecided,New] https://launchpad.net/bugs/177029
<pochu> Hey folks. The bug we talked about the other day has been fixed upstream, and commited to HEAD, see freedesktop bug #13108. The launchpad bug is 173265. This affects (afaik) only intel chipsets, and the way to reproduce is to put a video in the background (e.g. hide it with another window), and after some seconds (more than 10 it seems) display it.
<ubotu> Freedesktop bug 13108 in Driver/intel "[overlay] XV window hidden for some seconds causes SEGFAULT when taken into foreground again" [Major,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=13108
<pochu> bug 173265
<ubotu> Launchpad bug 173265 in xorg-server "Xorg crashed with SIGSEGV" [Unknown,Confirmed] https://launchpad.net/bugs/173265
<pochu> Is it possible to get this patch in? There seems to be various dups, although I haven't marked them as such as I'm not really sure.
<bryce> pochu: heya, I'll take a look today once I've finished merging in -psb
<pochu> bryce: thanks. Let me know if you need me to do some tests :-)
<bryce> sure
<bryce> tjaalton: had a chance to test the patch for bug #174537?
<ubotu> Launchpad bug 174537 in xorg "[Hardy] No Xorg in live cd" [Critical,Confirmed] https://launchpad.net/bugs/174537
<tjaalton> bryce: I haven't succeeded to build a livecd :/
<bryce> hrm; should we just go ahead and push it out, and see how it goes?
<tjaalton> because openoffice refuses to install
<tjaalton> I guess so
<bryce> ok, do you want to upload it, or I could ask slangasek?
<tjaalton> (the new openoffice depends on a library that is in universe, and doesn't build)
<tjaalton> either works
<bryce> ok, go ahead and upload; I'll let slangasek know it's incoming
<tjaalton> so now that I push the change, it'll upload a new version automatically?
<tjaalton> ah no
<bryce> <bryce> slangasek: we're fairly confident that the change fixes the issue, and at least certain it won't make anything worse, so I'm going to have timo go ahead and upload it
<bryce> <slangasek> ok
<bryce>  the OOo build issue is also on my list to chase up today
<bryce> <cjwatson> bryce: patch looks fine to me, if it'll do the job
<bryce> <bryce> cjwatson: cool thanks
<tjaalton> cool
<tjaalton> pushed already
<tjaalton> and now uploaded
<tjaalton> hopefully that's all it takes :)
<bryce> thanks!
<tjaalton> yeah, I'll test the daily cd tomorrow
<tjaalton> for some reason those have been generated without any OOo issues
<tjaalton> but even better if the new version is built by tomorrow
<tjaalton> bedtime again, cya ->
#ubuntu-x 2007-12-19
<bryce> cya
<ubotu> New bug: #177373 in xorg (main) "[hardy alpha 1 amd64] touchpad not detected / configured during install" [Undecided,New] https://launchpad.net/bugs/177373
<superm1> are the current daily disks supposed to be booting up entirely without an xorg.conf every time?
<seb128> do you guys know about bug #175774?
<ubotu> Launchpad bug 175774 in compiz "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Undecided,Confirmed] https://launchpad.net/bugs/175774
<seb128> that doesn't happen when using XAA
<tjaalton> seb128: yep
<seb128> tjaalton: do you have an xorg or intel bug about it already?
<seb128> or should I reassign this one?
<tjaalton> I don't know if there's a bug already, but saw it with my new X61 (which has 965GM)
<tjaalton> and there's a bug about it on debian
<tjaalton> the same happens with ati r200
<tjaalton> so it's not necessarily a driver bug, but could be
<seb128> I've reassigned to the intel driver
<tjaalton> ok, it's fine
<ubotu> New bug: #175774 in compiz (main) "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Undecided,Confirmed] https://launchpad.net/bugs/175774
<ubotu> New bug: #176318 in libxft (main) "X applications crash after upgrade" [Undecided,New] https://launchpad.net/bugs/176318
<ubotu> New bug: #177097 in linux-restricted-modules-2.6.22 (restricted) "nvidia-glx-new driver in gutsy 64 freezes the system with Geforce 7300" [Undecided,New] https://launchpad.net/bugs/177097
<ubotu> New bug: #177492 in xserver-xorg-video-intel (main) "EXA is balls-achingly slow (945)" [Undecided,New] https://launchpad.net/bugs/177492
<pochu> bryce: your package in bug 173265 didn't work for me
<ubotu> Launchpad bug 173265 in xorg-server "Xorg crashed with SIGSEGV" [Medium,Fix committed] https://launchpad.net/bugs/173265
<pochu> (I haven't tried the upstream patch btw)
<bryce> pochu: oh I'd assumed you'd already tested the patch, so it just needed to be brought in.
<bryce> pochu, ok let me know when you have a confirmed fix for it
<seb128> hey bryce
<bryce> heya seb128
<seb128> bryce: have you seen the compiz EXA bug I mentionned something like 10 hours ago?
<bryce> no I hadn't
<seb128> let me get the bug number ;-)
<seb128> bryce: bug #175774
<ubotu> Launchpad bug 175774 in compiz "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Undecided,Confirmed] https://launchpad.net/bugs/175774
<seb128> bryce: not sure if that's an intel bug, but if you need extra informations let me know, there was no such issue in gutsy and using XAA workaround the issue
<seb128> ah, tjaalton commented on the bug already ;-)
<seb128> bryce: anyway just mentionning it because I get the issue on my laptop and can provide debug informations if required
<bryce> erf, switching to EXA instead of XAA was supposed to fix the 965gm compiz issues
<bryce> seb128: ok thanks, noted.  I'll triage the bug and keep track of it
<bryce> I have a couple 965gm systems I can test on as well
<seb128> ok
<seb128> on gutsy compiz was working correctly out of the video overlay issue
<bryce> I may not get to it soon, but I'm building a list of high priority bugs to work on after the holidays and will add this to it
<bryce> from timo's comment, sounds like this is a known issue, so maybe it's already being worked
<bryce> but I can mention it to Intel at my next meeting with them, mid-january if it's not fixed by then
<tjaalton> yes, michel dÃ¤nzer apparently is on it
<tjaalton> bryce: did you notice that the l-r-m for .24 don't have the changes we made (dropping libGL diversion for fglrx etc) :(
<bryce> tjaalton: no I didn't
<bryce> tjaalton: was any reason given for dropping it?
<tjaalton> no, BenC didn't reply yet
<tjaalton> maybe it was just an oversight.. and it has not been built on other than sparc anyway (any of the uploads), so there's still hope ;)
<pochu> bryce: sorry, I didnt had the time. Will ping you once I have a working patch
<bryce> pochu: cool thanks
<tjaalton> bah, another lrm upload..
<bryce> you know, I suspected switching Inkscape to Launchpad would be beneficial for bug triaging compared with sourceforge, but I really had no idea just how significant it'd be
<bryce> http://people.ubuntu.com/~brian/project-graphs/inkscape/plots/inkscape-month-new.png
<bryce> that is all over just 2 weeks
<bryce> well, 3 weeks, but the most intense activity has been the last 2 weeks
<tjaalton> how come we have ~40000 open bugs on ubuntu then :P
<bryce> maybe just because Inkscape kicks ass?  ;-)
<tjaalton> hehe
<bryce> actually yeah I need to figure out how to recruit one or two of the triagers to work on xorg bugs next ;-)
<tjaalton> first we unsubscribe from all l-r-m bugs :)
<tjaalton> that would "close" third of all our bugs
<tjaalton> 1800 -> 1200
<tjaalton> I'll do another sweep of xorg bugs
<tjaalton> soon
<bryce> cool
<bryce> I'll lend a hand
<jcristau> if you could do a sweep of http://bugs.debian.org/debian-x@lists.debian.org while you're at it... ;)
<tjaalton> hehe
<bryce> heh, in our ample free time sure
<tjaalton> actually, I've thought about checking those to see where we have dupes. the rest should be just noise :)
<bryce> on a few occasions I've tried going through debian|freedesktop bugs while looking at launchpad, to find matching bugs.  However, in practice I found it a lot harder to link up bugs than I'd expected.
<bryce> partly since Lauchpad bug reporters don't provide the wealth of detail that the average fdo or deb bug reporter does
<jcristau> i'm only able to do that when i recognize something i've already seen on xorg-team@
<ubotu> New bug: #177552 in xterm (main) "Fontconfig settings not used in all applications" [Undecided,New] https://launchpad.net/bugs/177552
<ubotu> New bug: #177559 in linux-restricted-modules-2.6.22 (restricted) "package nvidia-glx-new None failed to install/upgrade: trying to overwrite `/usr/bin/nvidia-xconfig', which is also in package nvidia-xconfig" [Undecided,New] https://launchpad.net/bugs/177559
<bryce> hey tjaalton, now that the new xorg.conf-lite xorg is uploaded, how do you think we should handle xorg.conf when upgrading from gutsy (and dapper)?  Should we force a regeneration of it, or try to do something clever to fix up the xorg.conf automatically, or...?
<ubotu> New bug: #132232 in xorg (main) "E-VGA GeForce 6200 LE non-compatible?" [Undecided,Invalid] https://launchpad.net/bugs/132232
#ubuntu-x 2007-12-20
<tjaalton> bryce: yes, I think at some point that needs to be done
<tjaalton> currently it just affects new installations
<tjaalton> but we have more pending changes to come :) (discover, input-hotplug..)
<bryce> yeah
<ubotu> New bug: #177609 in xorg-server (main) "nvidia-glx won't upgrade" [Undecided,New] https://launchpad.net/bugs/177609
<ubotu> New bug: #177614 in xorg (main) "[Feisty,Gutsy] Switching to tty yields black screen (SiliconMotion)" [Undecided,New] https://launchpad.net/bugs/177614
<superm1> hey bryce 
<bryce> heya
<superm1> could you look briefly to see if you agree this bug is classified in the right area: https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/104613 ?
<ubotu> Launchpad bug 104613 in linux-restricted-modules-2.6.24 "restricted-manager does not correctly enable XvMC with nVidia binary graphics drivers" [Undecided,New] 
<superm1> i wasn't sure if it should really be handled in l-r-m
<superm1> or if it makes more sense in restricted-manager
<bryce> hmm
<superm1> i just revived it a few minutes ago since there has been a lot of confusion surrounding it from #ubuntu-mythtv and on the forums
<bryce> restricted-manager might be a better choice for it
<bryce> I guess it depends on whether it's lrm or restricted-manager that does the xvmc setting
<superm1> well if it was in lrm, then people installing from just nvidia-glx or nvidia-glx-new would benefit too
<bryce> in any case, I suspect it'll get faster attention from r-m, and if it's determined to really belong to l-r-m, they can bounce it there later
<superm1> but then again restricted manager usually handles these configurationy things
<superm1> similar to how xorg.conf is typically modified to turn off things like the nvidia splash screen
 * bryce nods
<superm1> okay i'll reclass it to restricted-manager again then.  thanks :)
<bryce> cool, sure :-)
<superm1> i was going to let you know as well, there was some discussion on beta mailing list.  the amd driver might be getting support to automatically install drivers from the .run file
<tjaalton> well, nvidia* is uninstallable on hardy right now :)
<superm1> so that work that tseliot is doing with envyng might not be all that necessary for them 
<superm1> by autoinstall i'm meaning nicely with the package manager 
<superm1> and such
<bryce> it'll be interesting to see how that turns out
<superm1> yeah, i've been reluctant to join your guys' discussion so as to not trump it since this stuff isn't final
<ubotu> New bug: #158215 in xserver-xorg-video-nv (main) "Screen does not display properly after boot up\" [Undecided,New] https://launchpad.net/bugs/158215
<ubotu> New bug: #177658 in xserver-xorg-video-ati (main) "[hardy] Blank GDM screen with ATI R420 [X800XT PE]" [Undecided,New] https://launchpad.net/bugs/177658
<ubotu> New bug: #158109 in xserver-xorg-video-nv (main) "For Hardy: enabling desktop effects with NVidia card on LiveCD is impossible" [Undecided,New] https://launchpad.net/bugs/158109
<ubotu> New bug: #176888 in xserver-xorg-video-intel (universe) "xbacklight not working in hardy, intel GM965" [Undecided,New] https://launchpad.net/bugs/176888
<ubotu> New bug: #144277 in xorg (main) "Mouse latency (sweep-selection precision) in Ubuntu" [Undecided,New] https://launchpad.net/bugs/144277
<ubotu> New bug: #177680 in xorg (main) "leaking pixmaps" [Undecided,New] https://launchpad.net/bugs/177680
<ubotu> New bug: #155366 in xserver-xorg-driver-nv (main) "Rendering of transparent backgrounds broken" [Undecided,New] https://launchpad.net/bugs/155366
<ubotu> New bug: #148138 in xserver-xorg-driver-ati (main) "High cpu usage on Xorg with gnome-terminal and transparency" [Undecided,New] https://launchpad.net/bugs/148138
<ubotu> New bug: #159238 in gnome-terminal (main) "Garbage in gnome-terminal (dup-of: 120858)" [Undecided,Invalid] https://launchpad.net/bugs/159238
<ubotu> New bug: #139313 in xorg (main) "nvidia dual head twinview (pseudo-xinerama): gnome-panel and maximized windows span both heads on first login" [Undecided,Confirmed] https://launchpad.net/bugs/139313
<superm1> bryce, i've gotten word that catalyst 7.12 was publicly announced.  it should be sane for inclusion in hardy as firegl hardware is again officially supported.
<bryce> ah good to know
<superm1> it has its quirks (as i've reported and they are listed on the known issues), but it is a good improvement
<ScislaC> superm1: do they have aiglx working with the new xorg yet?
<superm1> it should be on non firegl hardware
<ScislaC> (from everything I've seen Catalyst 7.11 &  FGLRX 8.42 don't work with hardy's version)
<ScislaC> and that was also my personal experience
<ScislaC> superm1: do you have a link to the known issues?
<ScislaC> I'm curious if the new one will also peg one of the cores on my dual core as well
<ScislaC> superm1: reading on Phoronix :)
<ScislaC> bryce: evil bug... "Connecting a display device that supports 1680x1050 to a system running Linux may result in a maximum display resolution of 1280x1024 only being available"  Does AMD specifically target all of my hardware to find a way to make it a pain? ;)
<superm1> haha
#ubuntu-x 2007-12-21
<bryce> tjaalton: you abouts?
<superm1> bryce, matthew tippet said hello :)
<bryce> hey, hello back :-)
<superm1> i'm assuming you saw the mail to ubuntu-devel about that libGL change?
<bryce> yes
<bryce> I'm wondering if something just didn't get checked into lrm git or something?
<superm1> there is more to it, but it boils down to avoid using the mesa one, because there is no gurarantee that it wont be broken
<superm1> well i think there was a miscommunication somewhere along the way, probably someone who tried it with mesa and said woah this works
<superm1> lets stop diverting
<bryce> could be
<ubotu> New bug: #163325 in scim (main) "File browser doesn't response when I press a key (dup-of: 66104)" [Undecided,Incomplete] https://launchpad.net/bugs/163325
<tjaalton> bryce: I'm here now
<tjaalton> there is no lrm git
<tjaalton> oh AMD replied, fair enough :)
<tjaalton> so fglrx continues to suck, that's too bad
<tjaalton> BenC didn't use the version I uploaded for 2.6.24, so all the changes are "lost"
<tjaalton> and he doesn't seem to want to comment why that happened, either
<superm1> interesting?
<tjaalton> what is?
<superm1> all the changes are "lost"
<superm1> they werent in some vcs?
<tjaalton> no
<tjaalton> lrm isn't maintained in a vcs
<bryce> hmm, I thought lrm used git
<tjaalton> nope
<bryce> huh
<tjaalton> I asked that on #ubuntu-kernel
<bryce> ok
<tjaalton> well, it's the biggest source package there is (>>100MB)
<tjaalton> maybe it's doable though
<tjaalton> but the situation currently is that nvidia*/fglrx are uninstallable
<superm1> yeah i noticed that when trying to master hardy mythbuntu disks
<tjaalton> since they provide xserver-xorg-video, which xserver-xorg conflicts with
<tjaalton> ok, fglrx debian maintainer informed about the libGL mess
<superm1> thanks tjaalton 
<tjaalton> no thank you for checking it out
<tjaalton> +, :)
<ubotu> New bug: #177852 in xorg-server (main) "Unale to manually configure monitor resolution and refresh rate with latest xorg-server in hardy." [Undecided,New] https://launchpad.net/bugs/177852
<ubotu> New bug: #177862 in xserver-xorg-video-intel (main) "xserver crash on vt switch" [Undecided,New] https://launchpad.net/bugs/177862
<ubotu> New bug: #177870 in xorg (main) "SGI licenced code in Xorg is non-free" [Undecided,New] https://launchpad.net/bugs/177870
<ubotu> New bug: #177907 in xorg-server (main) "I watch all video  .avi in black and white" [Medium,Confirmed] https://launchpad.net/bugs/177907
<pochu> I moved that one to xserver ^ as I also have that and slomo told me it was X, as both totem with Gstreamer, and Mplayer fail. Let me know if that's not xserver, and what it is then ;)
<pochu> Just found bug 149791, nevermind :)
<ubotu> Launchpad bug 149791 in xserver-xorg-video-intel "Black & White Video Output (Gutsy)" [Medium,Confirmed] https://launchpad.net/bugs/149791
<ubotu> New bug: #35845 in xkeyboard-config (main) "compose:ralt option broken with 0.8 update" [Medium,Fix released] https://launchpad.net/bugs/35845
<ubotu> New bug: #177719 in xorg-server (main) "Xorg crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/177719
#ubuntu-x 2007-12-22
<ubotu> New bug: #178026 in xserver-xorg-video-ati (main) "please sync xserver-xorg-video-ati 1:6.7.197-1 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/178026
<ubotu> New bug: #178027 in xorg (main) "xorg does not start on ati X1300" [Undecided,New] https://launchpad.net/bugs/178027
<tjaalton> hmm, this is interesting.. one game of flightgear made every compiz effect ten times slower :)
<ubotu> New bug: #178168 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-legacy won't install, error in dpkg-divert" [Undecided,New] https://launchpad.net/bugs/178168
<ubotu> New bug: #44666 in xorg-server (main) "Xnest + xdm causes total system lockup on remote login" [Medium,Invalid] https://launchpad.net/bugs/44666
<ubotu> New bug: #177766 in linux-restricted-modules-2.6.24 (restricted) "Wireless LED does not light up (network connection works)" [Undecided,Confirmed] https://launchpad.net/bugs/177766
<ubotu> New bug: #178176 in linux-restricted-modules-2.6.24 (restricted) "package xorg-driver-fglrx 8.443.1-1 failed to install/upgrade: el subproceso post-removal script devolviÃ³ el cÃ³digo de salida de error 2" [Undecided,New] https://launchpad.net/bugs/178176
#ubuntu-x 2007-12-23
<ubotu> New bug: #178181 in xserver-xorg-video-radeonhd (universe) "Please sync xserver-xorg-video-radeonhd 1.1.0-1 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/178181
<ubotu> New bug: #178275 in xorg (main) "[Hardy] X broken: can't retrieve EDID data" [Undecided,New] https://launchpad.net/bugs/178275
<ubotu> New bug: #178282 in xrandr "xrandr set any parameter failed with x error" [Undecided,New] https://launchpad.net/bugs/178282
<ubotu> New bug: #178310 in xserver-xorg-driver-sis (main) "Random crash with SiS video card" [Undecided,New] https://launchpad.net/bugs/178310
#ubuntu-x 2008-12-15
<bryce> heya
<alex_mayorga> bryce: hi
<alex_mayorga> bryce: can you check the trail on my bug report?
<bryce> id#?
<bryce> alex_mayorga: anyway if it's 146706 it looks like it's awaiting upstream response currently
<tjaalton> bryce: (early) morning, I got a patch from whot for the keymap problem ;)
<bryce> tjaalton: yay!
<bryce> tjaalton: how'd the exams go?
<tjaalton> bryce: well, the first is in 11h ;)
<bryce> tjaalton: get any sleep on the plane?
<tjaalton> yes, a bit too much I guess, since I woke up 2h ago (4am)
<bryce> heh, well that's better than not having any!
<tjaalton> yeah, the sfo-heathrow flight felt short, since I slept most of it
<tjaalton> the TSA decided to remove three spraycans from my luggage, that was not so cool
<bryce> tjaalton: btw here's my xserver patch to fix signal throwing, that should be included:  http://launchpadlibrarian.net/20358645/135_rethrow_signals.patch
<bryce> tjaalton: I apologize for my silly government :-(
<bryce> I've had them do that in my luggage too.  sucks.
<tjaalton> yeah, well they were not for me but my brother-in-law, and he probably knew the risks
<bryce> ah, what kind of spray cans?
<tjaalton> some special paint to renovate vinyl upholstery and such
<tjaalton> he's got a '65 Pontiac Grand Prix..
<bryce> ooh sounds daangerous
<tjaalton> yeah, my dirty socks could've been painted turquoise
<tjaalton> patch downloaded
<alex_mayorga> bryce: it is, but it somehow worked today :)
<bryce> tjaalton: we've gotten totally snowed in
<bryce> tjaalton: fortunately it waited until this morning to do it, but we've got like 3 inches
<tjaalton> bryce: omg ;)
<bryce> hehe
<tjaalton> well, at least it looks nice
<tjaalton> practically no snow here, ~0C
<bryce> it's a lot for us, and there'll be more coming this week
<tjaalton> oh nice
<tjaalton> hopefully here too
<bryce> terri's excited because she gets off from school
<tjaalton> if only we had that rule as well :)
<tjaalton> "no exams, have fun!"
<bryce> one year when I was in college at USC in Los Angeles we got out of exams on account of the city devolving into rioting
<tjaalton> haha, excuses
<tjaalton> just kidding, I remember those
<tjaalton> bryce: so, if the layout patch proves to work, should we push for alpha2?
<tjaalton> building it now
<bryce__> tjaalton: yep definitely
<tjaalton> bryce__: hum, seems that the new sighandler-patch broke the build
<tjaalton> ./.libs/libosandcommon.a(xf86Events.o): In function `xf86SigHandler':
<tjaalton> /tmp/buildd/xorg-server-1.5.99.3/obj-i486-linux-gnu/hw/xfree86/common/../../../../hw/xfree86/common/xf86Events.c:408: undefined reference to `SigAbortDDX'
<tjaalton> I'll push what I have so you can have a look
<tjaalton> I'll test without 135
<bryce__> ok
<bryce__> tjaalton: yeah I expected some of this code has changed so I'll need to update the patch for 1.6.  I'll review it after the upload
<superm1> bryce__, here's that pic if you want to compare your diagram to the real one: http://picasaweb.google.com/superm1/Misc#5279905239276667570
<tjaalton> bryce__: should I drop it for now?
<bryce__> tjaalton: leave it there but commented out I guess
<tjaalton> bryce__: that's the intent
<bryce__> superm1: cool thanks
<tjaalton> yep, the layout-patch works
<tjaalton> bryce__: ok, uploading now
<bryce__> tjaalton: thanks
<tjaalton> bryce__: drivers uploaded too, but not the binary ones. tseliot/superm1 might want to check those first
<tjaalton> sweet, half of them fail to build :P
<tjaalton> trivial changes needed but still
<tjaalton> grr, every damn input driver fails to build, apart from evdev/synaptics/wacom
<tjaalton> and not all of them have fixes upstream
<bryce> tjaalton: erf
<tjaalton> bryce: well, vmmouse is the only driver not built that actually matters, the rest are in universe
<bryce> tjaalton: ahhh
<bryce> tjaalton: ok if you could file a bug about vmmouse assigned to me, I will take care of that one later when I get time.
<tjaalton> and vmmouse probably needs the same commit as -mouse, since they share a lot
<tjaalton> the build failure was similas if not identical
<bryce> ok
<tjaalton> once i get home, sure
<tjaalton> if i don't pass out before :)
<tjaalton> hum, 'crash out' probably is what i was after..
<bryce> hehe
<tjaalton> hmm, apparently the new server causes segfaults for some intel users
<crevette> ah
 * crevette will wait a bit to update
<tjaalton> the intel problem is this: https://bugs.freedesktop.org/show_bug.cgi?id=19017
<ubottu> Freedesktop bug 19017 in Driver/intel "fail to start Xorg with the latest xserver (server-1.6 branch)" [Blocker,New]
<tjaalton> so probably worth to revert that one until it's fixed
<tjaalton> but DHW ->
<bryce> tjaalton: ok I'll put on my todo list to look at it
<bryce> wow - http://www.phoronix.com/scan.php?page=news_item&px=NjkyNw
<superm1> what's that mean for everyone's favorite graphics driver?
<bryce> superm1: indeedy
<bryce> heya tseliot
<tseliot> hey bryce
<superm1> tseliot, how soon are you planning on uploading 180.16 (do you need a sponsor)?  my mythbuntu team is needing it because mythtv is a build dep on it as of trunk, so we're trying to get VDPAU mythtv builds out
<tseliot> superm1: 180.11 is already available in Jaunty
<superm1> the API changed in 180.16
<superm1> that API is what's used in myth unfortunately :(
<tseliot> superm1: ah, I didn't know
<tseliot> superm1: I have to make sure that nothing changed (in the packaging) but I think I'll do it soon
<superm1> tseliot, alrighty :)
<tseliot> currently I have 2 urgent updates to do
<tseliot> but after these updates I'll update the driver
<superm1> ok
<tseliot> (I hope this week)
<bryce> superm1: what do you think of bug 307796?
<ubottu> Launchpad bug 307796 in fglrx-installer "fglrx-kernel-source should depend on gcc" [Wishlist,Triaged] https://launchpad.net/bugs/307796
<superm1> yeah i think it makes sense
<superm1> i saw that fly by at some point but forgot about it
<bryce> also take a peek at 307643 - 3 reports of that issue, some sort of merge problems with one of the fglrx config files
<bryce> superm1: yay, -fglrx bug triage is caught up.  5 more sent in to ATI
#ubuntu-x 2008-12-16
<superm1> yeah i'm aware of that config file thing.  i asked amd to not keep anything in /etc that's not a config file, but i might just add a mv_conffile clause to the postinst if i dont get a timely reply from them (which i dont expect)
<bryce> superm1: yeah I think that's a good idea
<wgrant> Hrm, I can't rebuild xserver due to the new linux-libc-dev having /usr/include/drm/drm.h, which libdrm-dev also has.
<tjaalton> wgrant: which version? mine doesn't have it
<tjaalton> morning btw
<wgrant> tjaalton: linux-libc-dev 2.6.28-3.4
<wgrant> I downgraded to -2.3 and it works fine.
<wgrant> (I'm applying the patch to stop xserver segfaulting with -intel, which caused me some annoyance this morning, and it making apt unhappy)
<tjaalton> hrm
<bryce> heya
<wgrant> tjaalton: Ergh, sorry, I meant to move that bug hours ago but got distracted.
<tjaalton> wgrant: np
<tjaalton> hi bryce
<tjaalton> so the intel crash is fixed, but the kernel change means that anything that requires the drm headers fail to build
<wgrant> Is the intel crash fixed?
<tjaalton> upstrea
<tjaalton> m
<wgrant> Ah, yes.
<wgrant> Server 1.6 has the new pointer acceleration algorithm, doesn't it?
<wgrant> I'm trying to get -synaptics 0.99.3 working reasonably.
<tjaalton> wgrant: yes it does
<wgrant> -synaptics upstream has very strange defaults :(
<wgrant> No tap-to-click if you have buttons, for example.
<tjaalton> bryce: I'll try to fix vmmouse now, and see if it could be pushed upstream then
<bryce> tjaalton: ok
<tjaalton> bryce: I think we should get rid of a couple of packages, like x-x-v-tga and -vga
<tjaalton> tga is usable only on alpha, and -vga is otherwise useless since we have vesa for x86
<tjaalton> both are already in universe
<tjaalton> and have no bugs, ie. no one using them :)
<tjaalton> bug 308504, bug 308505
<ubottu> Launchpad bug 308504 in xserver-xorg-video-vga "please remove xserver-xorg-video-vga from the archive" [Undecided,New] https://launchpad.net/bugs/308504
<ubottu> Launchpad bug 308505 in xserver-xorg-video-tga "please remove xserver-xorg-video-tga from the archive" [Undecided,New] https://launchpad.net/bugs/308505
<tjaalton> nvidia 180 seems to work but only with -ignoreABI
<tseliot> tjaalton: did you try the other flavours too?
<tjaalton> tseliot: nope
<tseliot> tjaalton: in any case I'll have to try the drivers with the new X and (if they work) rebuild the packages
<tjaalton> tseliot: can you force the ignoreABI in the drivers somehow?
<tseliot> tjaalton: I guess not. It's something you can force in the xorg.conf
<tjaalton> ok
<mvo> hey tseliot! I was looking into the gnome-desktop update today and debian/patches/100_load_desired_settings.patch would need porting to the new 2.25.x code - could you please have a look? Is that somethign that can/should go upstream ?
<tjaalton> tseliot: there's bug 308410 now.. where should the drivers be disabled, jockey?
<ubottu> Launchpad bug 308410 in nvidia-graphics-drivers-177 "Latest Xorg removes nvidia driver ... conflicting xorg-xserver-video-4" [Medium,Confirmed] https://launchpad.net/bugs/308410
<tjaalton> oh, you owned that already
<tseliot> tjaalton: I would like to install Jaunty and see how it goes here before I blacklist the driver
<tjaalton> but it won't work anyway unless you force the option somewhere
<tseliot> I'll see what I can do
 * tseliot > lunch
<seb128> tseliot: any news about the patch update?
<tjaalton> 177 segfaults
<seb128> tseliot: hello
<tseliot> seb128: I have to patch and test a package in intrepid but after that I'll work on your patch (I guess today)
<seb128> tseliot: ok, I'm going to drop the patch for now, it's blocking the whole GNOME for 2 weeks now
<seb128> tseliot: I really want to get moving on those updates before holidays
<tseliot> seb128: ok, no problem
<tseliot> seb128: I'll let you know when the patch is ready so that we can re-include it
<seb128> tseliot: ok thanks
<seb128> tseliot: where are the specific api used?
<seb128> ubuntu_gnome_rr_config_save_desired is used in g-c-c apparently but not g-s-d is that expected?
<tseliot> seb128: g-s-d uses libgnome-desktop
<seb128> tseliot: right, but none of those new api you added right?
<tseliot> therefore I didn't touch g-s-d directly
<seb128> ok
<mvo> hm, this sounds like we should add a stub for now or wait until the patch is done
<tseliot> seb128: does this reply to your question?
<seb128> I hate distro changes
<tseliot> seb128: and so do I ;)
<crevette> seb128, I have 3 days of starting tomorrow, so I can manage to help a little at least
<crevette> +ff
<crevette> off
<seb128> crevette: good thanks
<seb128> tseliot: could you look to this patch update before the intrepid changes? there is probably no hurry for intrepid but we are blocking jaunty updates on this update now
<seb128> I would say unblocking jaunty is higher priority than intrepid
<tseliot> seb128: ok, I'll do it now
<seb128> thanks
<tseliot> seb128: did you put your source somewhere?
<tseliot> the new control-center which doesn't build, I mean
<tseliot> and the new libgnome-desktop
<seb128> mvo has the new g-c-c
<mvo> tseliot: new gnome-contorl-center is ported and in bzr
<mvo> tseliot: that should fine
<seb128> tseliot: http://people.ubuntu.com/~seb128/gnome-desktop_2.25.3-0ubuntu1.diff.gz http://people.ubuntu.com/~seb128/gnome-desktop_2.25.3-0ubuntu1.dsc http://download.gnome.org/sources/gnome-desktop/2.25/gnome-desktop-2.25.3.tar.gz
<mvo> maybe we should put gnome-desktop into bzr too? so that we can easily work on it together?
<tseliot> mvo: yes, please
 * mvo waits for a yes/no from seb128 first
<seb128> mvo: go for it
<seb128> mvo: let me now if you put the current jaunty version and if I should push my changes or if you want to put directly my version there
<mvo> seb128: I will put your version there I think
<seb128> mvo: ok cool
<mvo> seb128: you are on VAC ;) so I can do it, no problem 
<seb128> hehe, that's true
<mvo> tseliot: bzr branch lp:~ubuntu-core-dev/gnome-control-center/ubuntu ; cd ubuntu; bzr-buildpackage should give you the g-c-c bits
<tseliot> mvo: ok, good. I think I have all I need now
 * tseliot gets the source from bzr
<mvo> https://code.edge.launchpad.net/~ubuntu-core-dev/gnome-desktop/ubuntu
<tseliot> mvo: ok, thanks
<mvo> cheers, thanks for working on the patch update!
<mvo> tseliot: hm, while g-c-c applies all patches the changes do not compile anymore, I'm having a look now (somewhere in the xrandr capplet) but will not have that much time unfortunately for it today)
<tseliot> mvo: libgnome-desktop is the problem
<tseliot> mvo: I'm working on it anyway
<seb128> mvo: that's because it requires the patch I commented in the gnome-desktop update
<seb128> mvo: or g-c-c requires upstream changes due to the new gnome-desktop api breakage
<mvo> some it it is api changes (_rr_screen_new() needs e.g. a GError now etc)
<mvo> some of it is the libgnome-desktop
<mvo> I commit what I have
<seb128> mvo: look to the svn it's likely they updated the capplet there too
<seb128> I guess they will roll a new tarball soon
<mvo> the changes required are trivial, but the fact that the file xrandr-capplet.c is touch in a bunch of different patches makes it not easy for me to see where it should be applied
<mvo> (well, the api changes, not the changes to make libgnome-desktop work :)
<mvo> tseliot: I fixed one of my mistakes in 80_apect_in_dropdown.patch in g-c-c (just FYI and to avoid duplication of work). still some smallish ones left, that seems to be just additions of a GError as last parameter
 * mvo -> break
<tseliot> mvo: I'm still on the gnome-desktop part
<tseliot> but thanks for letting me know
<tseliot> mvo, seb128: libgnome-desktop builds again (in pbuilder) \o/
<seb128> tseliot: excellent ;-)
<seb128> tseliot: the change is ready to be used or do you want to do extra testing before?
<tseliot> seb128: builds != works
<seb128> ok
<tseliot> I built it in pbuilder only. I have to install Jaunty to make sure that
<tseliot> it works
<tseliot> s/I have/I want/
<seb128> do you have the updated patch somewhere?
<tseliot> seb128: I can upload it to my website if you want
<tseliot> seb128, mvo: http://albertomilone.com/ubuntu/gnome/jaunty/100_load_desired_settings.patch
<seb128> tseliot: thanks
<tseliot> seb128: I'll install Jaunty anyway since I'm really not confident with patches I didn't test myself (at runtime)
<seb128> ok, let me know, I'll probably delay the upload until tomorrow now, it's getting late for a round of upload, newing, transition etc today
<tseliot> seb128: sure
<mvo> tseliot: thanks, I check it out, feel free to upload it in bzr (but I'm fne with getting it from the website)
<tseliot> mvo: I'm upgrading to Jaunty so as to try it at runtime. Then I'll put it in my bzr branch
<bryce> tjaalton: removing packages - sounds good
<tseliot> bryce: is it a known bug the fact that the intel driver segfaults on jaunty? (xf86setcrtcconfig() or something similar)
<bryce> tseliot: which graphics chip?
<bryce> tseliot: it worked ok when I tested it prior to UDS, but didn't retest it yesterday.  I'll upgrade now and see
<tjaalton> yes it's known, and fix released already, but xorg-server doesn't build because of the libdrm/linux-libc-dev deathmatch
<bryce> ah ok
<tseliot> ok
<tseliot> the pci-id is 8086:27a2 anyway
<bryce> ah ok 965
<tjaalton> bryce: could you confirm the removal bugs and subscribe ubuntu-archive?
<tjaalton> I've requested -openchrome to be synced from experimental, there should be no changes left
<tjaalton> that version merged the randr-branch, so a lot of the old bugs should get closed with it
<tjaalton> (and new ones pop up, of course..)
<tseliot> mvo: did you notice the compilation errors in xrandr-capplet.c? They don't depend on what I did. It looks like the author updated the function prototypes but the actual functions don't reflect these changes (e.g. line 1778). Shall I fix these bugs too?
<mvo> tseliot: that are probably the ones I ran into as well, it looks like its just the new GError argument
<tseliot> mvo: right
<tseliot> mvo: what do you suggest that I do?
<mvo> tseliot: feel free to fix, otherwise I have a go on it (seb mentioned there might be already fixes in svn for it, but its probably easy enough)
<mvo> (easy enough == famous last words ;)
<tseliot> mvo: ok, I'll make (yet) another patch. It should be easy to do
<tjaalton> bryce: btw, I tried to fix vmmouse, and just copying xf86OSmouse.h from -mouse makes it get forward, but fails building libvmmouse.la. probably something easy but didn't get to it yet
<bryce> removal bugs confirmed and u-a subbed
<tjaalton> cool, thanks
<bryce> yesterday I banged xkeyboard-config down from 117 to 73 bugs :-)
<tseliot> \o/
<tjaalton> ooh :)
<bryce> and went through all the ones related to hotkeys and gave troubleshooting advice
<bryce> there's one keyboard bug that's got a ton of dupes.  I don't understand what's going on but I marked it confirmed.  It's been going on a while and seems to be some weird mis-interaction between the installer, x, and g-c-c
<bryce> keyboard layouts seem to get forgotten or set up wrong during upgrades
<bryce> anyway, probably something we should look into for jaunty.  I marked it critical for now.
<bryce> tjaalton: oh also might want to look at 308649 for xserver (patch was attached)
<tjaalton> bryce: yeah
<tjaalton> pushed
<tjaalton> (not released yet if there are other fixed to include)
<bryce> tjaalton: did you want me to look into the vmmouse issue?
<bryce> I also still need to update my signal patch, hopefully I can get to that today
<tjaalton> bryce: well, if you could that would be nice. probably something really simple
<tseliot> mvo: did you upload the fix for the dropdown patch to the bzr branch?
<mvo> tseliot: hm, should be. let me check
<mvo> tseliot: rev36 should have it
<tseliot> ok
 * tseliot > dinner
<tjaalton> heh, alexia death seems to have figured out a way to fix wacom hotplug.. by using dbus
<tjaalton> a set of dbus-send commands to add the devices
<bryce> interesting
<bryce> would it solve it for us?
<bryce> tjaalton: btw I filed some sync req's for video drivers with a build number and new version in experimental
<bryce> (listed at https://wiki.ubuntu.com/X/PackageNotes)
<tjaalton> the driver would need to do that by itself, but we'll see what upstream thinks about it
<bryce> ok
<bryce> tjaalton: btw freeze immanent
<tjaalton> I've requested openchrome to be synced, so changed the merge to a sync on that page
<bryce> ok great
<tjaalton> and voodoo in experimental is just a rebuilt version, no point in merging that
<tjaalton> freeze.. great
<tjaalton> bryce: hmm, what change does r128 have, or is the comment just an oversight :)
<bryce> tjaalton: hmm?
<tjaalton> the PackageNotes page
<bryce> ah could be old info
<bryce> otherwise, just an oversight
<tjaalton> heh, ok I'll remove that then.. could be mine too
<bryce> btw, I'm preparing an email for amd and nvidia to summarize UDS decisions; could you review for me?  -- http://pastebin.ubuntu.com/86556/
<tjaalton> sure. libdrm is already 2.4.1, and 2.4.2 should be out soonish
<bryce> any chance of 2.5.x?
<tjaalton> alpha2 has a prerelease of randr-1.3, so it doesn't support all the features yet
<tjaalton> I've no idea of libdrm versioning.. but they shouldn't care about libdrm anyway
<bryce> ok, I'll list it as alpha3
<tjaalton> yes
<tseliot> the RandR capplet works again (after 3 patches), yay!
<tjaalton> tseliot: great :)
<tjaalton> bryce: seems that hal 0.5.12-rc1 already has the patch to list joysticks having input.joystick capability
<tjaalton> or maybe not, but my joystick does list that now
#ubuntu-x 2008-12-17
<bryce> tjaalton: is there a workaround to get xserver to build?
<wgrant> bryce: With the libdrm conflict?
<bryce> yeah
<wgrant> I downgraded it manually in my chroot, but I don't think there's any workaround for the buildds...
<wgrant> Other than hunting kernel guys.
<bryce> mm, according to bug 308387 it *should* be fixed
<ubottu> Launchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,In progress] https://launchpad.net/bugs/308387
<bryce> or worked-around at least
<wgrant> Ah, very recently.
<bryce> funny my pbuilder chroot failed since I'd just updated it...  retrying
<bryce> wgrant: btw how was your flight home?
<wgrant> It was good - fairly uneventful, though we almost missed the Sydney->Melbourne connection.
<wgrant> Yours?
<bryce> it was perfect; eerily so.  
<bryce> short, no babies, no one in the seat next to me, no security line waits, etc.
<bryce> hmm
<bryce> dpkg: dependency problems prevent configuration of pbuilder-satisfydepends-dummy:
<bryce>  pbuilder-satisfydepends-dummy depends on libdrm-dev (>= 2.3.1); however:
<bryce>   Package libdrm-dev is not installed.
<bryce> dpkg: error processing pbuilder-satisfydepends-dummy (--configure):
<bryce>  dependency problems - leaving unconfigured
<bryce> Setting up bsdmainutils (6.1.10ubuntu3) ...
<wgrant> Oh, and the bus to the BART station didn't come, so we had to walk. That was inconvenient.
<bryce> ahh now it's going
<bryce> portland got hit by a snowstorm a day after I arrived home; about 10cm in some places, and streets are iced over
<bryce> it was cold but sunny today, with the roads passable, so  we were able to get out and go to the market this afternoon.  But another storm's coming tomorrow morning so I think that'll lock us in the rest of the week :-)
<superm1> i just got sent back home because my flight from AUS->ORD got canceled because of some snowstorm at ORD (probably remnants of what you saw bryce :))
<bryce> superm1: wow
<bryce> superm1: hey btw, you'd mentioned something early last week about a touchscreen machine or something that I needed to look at?
<superm1> bryce, yeah, BenC is supposed to give it to you
<superm1> bryce, he was using it all week at UDS
<bryce> ah ok
<superm1> it should have fully support by the kernel evdev driver.  the X driver is lacking though
<bryce> I'm off next week, so probably won't get a chance to do much with it until january anyway
<bryce> (unless it turns out to be something simple)
<superm1> yeah that should be fine.  we're not rushing on it, but just want to make sure the support lands sometime by when jaunty is out since we'll have other products after jaunty using the same display
 * bryce nods
<superm1> i looked at it a little bit and with a few hackish quirks it looks like you can get the pen moving, but i dont know the code that well, and just wanted to see if i could get it that far before handing the hardware off
<bryce> I just had a call with one of our oem guys about this; sounds like we're going to give touch good attention for jaunty
<superm1> yeah by fixing the evdev driver rather than hacking on wacom everything should start to just work :)
<superm1> (that is for non wacom displays)
 * bryce nods
<superm1> also whenever you've got it to a satisfactory functionality, mirco muller had an interest in it, so you'll be passing it on to him when it gets to that point probably
<bryce> okay
<bryce> tjaalton: ok fixed up the signal patch (bug 226668), and committed to git.
<ubottu> Launchpad bug 226668 in xorg-server "Xorg crashes do not work with apport" [Wishlist,Fix committed] https://launchpad.net/bugs/226668
<pwnguin> aww, nouveau is broke
<pwnguin> well, missing
<bryce> missing?
<pwnguin> the modules thing is mia
<pwnguin> linux-nouveau-modules
<tjaalton> bryce: ok, excellent. I've now requested rebuilds of x86/amd64
<pwnguin> tjaalton: fyi, i think wacom works in jaunty
<tjaalton> pwnguin: nice
<pwnguin> i sent a mail to the list, lemme know if you think i'm wrong ;)
<tjaalton> I haven't tested it but if tom thinks it works.. :)
<tjaalton> bryce: you marked xorg-server for release, did you upload it?
<tjaalton> ah there it is
<tjaalton> cool
<bryce> yep
<pwnguin> on a scale from 0 to finished, does anyone know where nouveau in jaunty is at?
<bryce> pwnguin: 7E
<pwnguin> =/
<pwnguin> mostly, I'd like to know whether I'm doing something wrong or it's just too early to expect installable packages
<bryce> what exactly is your question?
<tjaalton> it should be installable on jaunty
<pwnguin> The following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: linux-nouveau-modules but it is not installable
<pwnguin> E: Broken packages
<tjaalton> hmm ok
<bryce> tjaalton: do you have an idea on that?
<bryce> does -nouveau depend on kernel stuff?
<tjaalton> sure, it needs newer drm stuff, so there's a package which builds those
<tjaalton> I'm not sure which source package provides that though. the package description suggests to use module-assistant first
<tjaalton> pwnguin: grab the package, drop the dep and test :)
<pwnguin> heh
<tjaalton> hmm no, the kernel doesn't have any version of the module
<tjaalton> off to work ->
<pwnguin> so was i really supposed to fiddle with the package and test again?
<bryce> pwnguin: yeah
<bryce> fwiw, -nouveau is not officially supported by us yet (we won't triage bugs against it this release for example)
<bryce> we'll accept and upload fixes of course, but at this stage it's considered completely experimental
<tjaalton> pwnguin: it'll refuse to work without the drm module
<tjaalton> raof should know the state of the package, but he's not online atm
<pwnguin> thats what i figured; i'll ping him later
<bryce> tjaalton: bug 308410 could use your attention
<ubottu> Launchpad bug 308410 in nvidia-graphics-drivers-177 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed] https://launchpad.net/bugs/308410
<tjaalton> bryce: expected, and rebuilding those wouldn't help much, since they don't work with the new xserver without force
<bryce> tjaalton: could you comment on the bug about this?
<tjaalton> done
<bryce> heh, no more ctrl-alt-backspace on my dev box
<tjaalton> -retro ftw!
<bryce> fwiw, with all of today's updates my eaglelake box is working much better
<tjaalton> good
<tjaalton> bryce: heh, good move to delete the comments :)
<tjaalton> from the spec
<bryce> tjaalton: I moved them to the wiki page
<tjaalton> ah
<bryce> whiteboard != forum
<tjaalton> yeah
<bryce> we're going to get a *lot* of comments about this once people become aware of the change
<tjaalton> sure, let them come
<lool> tjaalton: Is there an upstream bug for intel not building against linux' drm headers?
<tjaalton> lool: I don't know
<tjaalton> although I could file one
<lool> tjaalton: Well they might not be aware of this if they still use libdrm's headers
<tjaalton> they are aware, airlied is trying to persuade intel to get their act together
<tjaalton> 2.6rc1 fails to build as well, using libdrm master
<tjaalton> freedesktop bug 19132
<ubottu> Freedesktop bug 19132 in Driver/intel "2.5.99.1 fails to build using drm headers from 2.6.28" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19132
<tjaalton> same error as with 2.5.1
<pwnguin> are we finally dispensing with control-alt-bksp?
<pwnguin> cleverly hidden
<tjaalton> yes
<pwnguin> i gotta say, blueprints is confusing as hell
<tjaalton> in general or this particular one
<tseliot> tjaalton: is the new intel driver available now?
<tseliot> the one with the fix to my problem
<tjaalton> tseliot: it was a bug in the server
<tjaalton> and it's available
<tseliot> ok, thanks :-)
<lool> tjaalton: thanks
<tseliot> seb128: I gave mvo all the patches you need and he merged them. Now you can push gnome ;)
<seb128> tseliot: ok thanks!
<jcristau> lool: upstream knows about it, they'll probably fix up the kernel headers at some point. until then just build against libdrm?
<tseliot> tjaalton: 3D effects (Compiz or Kwin) are very slow with the Intel driver now
<tseliot> but hey, at least X starts now
<tjaalton> tseliot: check the permissions on /dev/dri/card0
<tseliot> tjaalton: crw-rw---- 1 root video 226
<tjaalton> ..and if you're not on video-group -> fail
<tjaalton> tseliot: btw, are you on linuxwacom-discuss?
<tseliot> tjaalton: no, where is it?
<tjaalton> the mailing list?
<tseliot> tjaalton: aah, ok
<tjaalton> https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss
<tseliot> I'll post there soon
 * tseliot > lunch
<tjaalton> well, alexia death has looked into using dbus for hotplugging
<tjaalton> and looks like it's possible to write a callout script which does things once you plug a tablet
<tjaalton> +in
<tjaalton> so, wacom hotplug should be around the corner, but there still are issues about where to store the config options etc.
<lool> jcristau: Yup just what we're doing
<tseliot> tjaalton: that would be interesting
<tseliot> tjaalton: compositing is so slow that even KWin noticed and told me that it was better to disable it
<tjaalton> tseliot: well, did you fix the permissions then?
<tjaalton> you need to have rw-access to /dev/dri/card0
<tseliot> tjaalton: I added myself to the video group
<tjaalton> and logged out & in?
<tseliot> tjaalton: I restarted Ubuntu
<tjaalton> ok
<tjaalton> dunno what's wrong then
<tseliot> and I get direct rendering
<tseliot> tjaalton: can you enable dbus in the xserver?
<tjaalton> done in git
<jcristau> tjaalton: it's called enable-config-dbus
<tjaalton> jcristau: hah, so it is
<tseliot> tjaalton: that will allow me wacom hotplug
<tseliot> allow me to do
<jcristau> you can't do wacom hotplug with config/hal?
<tjaalton> jcristau: only one device (stylus/eraser/..)
<tjaalton> to fully use wacom you need to set up at least three devices
<jcristau> i thought NIDR was exported just for that reason?
<tseliot> NIDR?
<tjaalton> well I don't know what the details are
<jcristau> tseliot: the function that creates a new input device
<tjaalton> NewInputDeviceRequest
<tseliot> jcristau: ok but does the wacom driver work with it?
<tjaalton> http://sourceforge.net/mailarchive/forum.php?thread_name=200812162159.29671.alexiadeath%40gmail.com&forum_name=linuxwacom-discuss
<jcristau> dunno. that's not the point though. if it doesn't, it can presumably be made to work
<tseliot> tjaalton: I replied to her
<tseliot> btw do you know why I get this is my Xorg.0.log? Failed to set tiling on front buffer rejected by the kernel
<tseliot> it says the same about back and depth buffer
<tjaalton> nope, no idea
<tseliot> http://pastebin.com/m4606b1d9
<tseliot> the full log ^^
<tjaalton> upgrade your kernel
<tjaalton> check dmesg for segfaults
<tseliot> tjaalton: upgrade my kernel to which version?
<tjaalton> to the latest one, yours is -2 while there is -3 available
<tseliot> tjaalton: I can't see it in the repository
<tjaalton> then change your mirror, preferably to just archive.u.c
<tjaalton> gone ->
<tseliot> found
<tseliot> hmm, it doesn't seem to solve the problem
<tjaalton> ok
<tseliot> also I can't switch to vt without corrupting the screen
<tjaalton> disable usplash
<tseliot> right
<bryce> superm1: erf, ATI is changing the bug escalation rules again
<bryce> superm1: now they are no longer accepting new bugs once we've reached 5 (non-feature) EPR's
<lool> Hi folks
<crevette> salut lool
<lool> On ATI R500 I had screen corruption all over the place until I forced EXA
<lool> I'm using compiz
<lool> Should we make EXA the new default for ati?
<bryce> lool: yep
<bryce> lool: in fact I've a blueprint open on doing exactly that... probably post-alpha2 I'll switch us over
<bryce> I'd have done it already by now, but just been busy
<lool> bryce: ok cool
<bryce> tjaalton, tseliot, should bug #308410 get a mention on the alpha-2 release notes?
<ubottu> Launchpad bug 308410 in nvidia-graphics-drivers-177 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed] https://launchpad.net/bugs/308410
<geeksquad> how do you restore the icons folder in /usr/share
<geeksquad> hello
<bryce> geeksquad: wrong channel.
<geeksquad> whitch is the right channl
<geeksquad> other than #ubuntu
<geeksquad> bryce
<bryce> dunno
<bryce> this channel is only for X.org in ubuntu though.
<geeksquad> oh maybe #gnome will work
<tjaalton> bryce: just mention that blobs don't work. jockey doesn't offer them anymore
<bryce> tjaalton: I think once alpha-2 is out, I'm going to pull a new -ati git snapshot and flip EXA on by default
<bryce> *hopefully* that will be Friday
<tjaalton> bryce: yeah
<tjaalton> so, alexia tells me that she (?) managed to get wacom hotplug working using the dbus-script as a hal callout-script like debian-setup-keyboard is
<tjaalton> the driver is a bit buggy so that some options are wrong, and of course no user settings are set, but that can be fixed while the device is plugged in
<tseliot> yes, I talked to Alexia and I think we can work together
<tseliot> bryce: do you know what can make my 965 slow when using 3D effects in Jaunty?
<tseliot> bryce: log: http://pastebin.com/m4606b1d9
<tseliot> videos have no tearing any more though
<bryce> tseliot: mm, in your log I see some errors about tiling buffers rejected by the kernel
<bryce> (WW) intel(0): Existing errors found in hardware state. <-- doesn't sound good either
<bryce> however, I'm not familiar with these errors yet so don't know their significance
<tseliot> ok
<bryce> tjaalton: https://wiki.ubuntu.com/Hotkeys has a 'should be' diagram there now too.  let me know if there are any inaccuracies in it
<tjaalton> bryce: nice pics, looks good so far :)
<tjaalton> btw, now my laptop (965) refuses to start X properly :)
<bryce> tjaalton: what did you run into?
<bryce> I'm doing another ->intrepid upgrade on another 965 system (my laptop)
<bryce> after alpha-2 I think I'm going to try a from-scratch reinstall
<tjaalton> the display just goes blank, flashes a couple of times before that
<tjaalton> maybe it didn't like me booting into xp to update my phone & remote
<bryce> tjaalton: run intel_reg_dumper to collect the register settings while it's blank, then again when you get it working with vesa or a livecd or something, and send both to jesse
<bryce> mm, could windows have left the gfx card registers in an inconsistent state for linux?
<tjaalton> or just the fact that I have master snapshot of libdrm
<bryce> tjaalton: btw I got confirmation that we are *not* doing KMS for jaunty.  That rumor we heard friday was apparently just a rumor
<tjaalton> bryce: ok
<tjaalton> yeah, downgrading libdrm helped
#ubuntu-x 2008-12-18
<bryce> https://wiki.ubuntu.com/XorgCtrlAltBackspace spec written
<tjaalton> morning
<tjaalton> looks like intel is taking the "won't build with kernel headers" seriously.. freedesktop bug 19132
<ubottu> Freedesktop bug 19132 in Driver/intel "2.5.99.1 fails to build using drm headers from 2.6.28" [Critical,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19132
<wgrant> Hmmm.
<wgrant> X isn't liking me.
<wgrant> Not much at all.
<wgrant> I have to start GNOME manually now, and be careful not to do too much that involves randr, or X dies bloodily.
<wgrant> Nothing at all in the logs.
<jcristau> wgrant: not even on stderr? (gdm.log)
<wgrant> jcristau: error setting MTRR (base = 0xc0000000, size = 0x10000000, type = 1) Invalid argument (22) ddxSigGiveUp: Closing log
<wgrant> Does that look relevant?
<jcristau> no, that shouldn't kill it
<wgrant> Indeed, not all of those logs have it. There's nothing else.
<wgrant> Just lots of screen corruption and an X restart.
<mvo> what driver is that?
<wgrant> i810, on i915.
<tjaalton> uh, why not -intel
<wgrant> Because I can't think straight. -intel it is.
<tjaalton> heh, ok
<wgrant> I live in the past.
<tjaalton> don't we all
<tjaalton> *sigh*
<jcristau> tjaalton: re: the (x)calloc patch, did you also change xfree -> free?
<tjaalton> jcristau: doesn't look like it. I haven't tested it either
<jcristau> k
<tjaalton> if it works
<tjaalton> how to test that btw?
<tjaalton> never used it..
<jcristau> me neither :)
<tjaalton> heh .)
<tjaalton> :)
<tseliot> tjaalton: if I wanted to rebuild X with --enable-dbus all I would have to do (e.g. in intrepid) is add "--enable-dbus" to the confflags in the debian/rules of xserver-xorg, right?
<tjaalton> tseliot: yes, except it's called --enable-config-dbus
<tseliot> tjaalton: ok, thanks
<tseliot> mvo: I have put the nvidia drivers in separate bzr branches (e.g. 173-intrepid, 173-jaunty, etc.) and I have fixed the bug you reported yesterday. I would like to know how I can avoid keeping the same binary blob in each branch. You managed to keep the orig.tar.gz separate from the packaging scripts in g-c-c. How did you do that?
<mvo> tseliot: it uses the debian/watch file to download the actual orig.tar.gz
<mvo> tseliot: not sure if that could work with nvidia as well (I don't know a lot about that package)
<mvo> tseliot: stacked branches might work as well 
<mvo> tseliot: thanks a lot for fixing the bug :) !
<tseliot> mvo: can I keep a branch with say driver 177 without the debian directory and use that for other branches?
<tseliot> mvo: or any docs about stacked branches?
<mvo> tseliot: I think stacked branches might work for that, its a relatively new feature, I'm not sure how they are used
<mvo> tseliot: #bzr will know
<mvo> http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html
<tseliot> mvo: ok, thanks a lot
<mvo> was something I found as well
<mvo> one of those things I alwayed watned to look at bug never quite managed
<tseliot> I'll have a look at it since it can save me a lot of time
 * mvo nods
 * mvo is away for dinner
<bryce> tjaalton: regarding the vmmouse breakage:  it expects header /usr/include/xorg/xf86OSmouse.h which used to be provided by xserver-xorg-dev but is no longer
<bryce> tjaalton: I also tried building the latest 2.6.2 release of -vmmouse, but same issue
<bryce> hmm
<bryce> tjaalton: so it appears that the OSMouse code was deleted from xserver (http://cgit.freedesktop.org/xorg/xserver/commit/?id=b89a59248a4a0ff06b9a0ddee45881efc6063063)
<bryce> tjaalton: which I gather makes -vmmouse badly, badly broken
<jcristau> that's a lot of badly
<bryce> ok maybe just one badly
<bryce> ooh got it to compile
<bryce> putting the old header file from the server into the driver code, and one minor fix, and it builds.  Lots of warnings about deprecated interfaces though.  the vmmouse guys need to look into this more.
<tjaalton> bryce: yes, it's the "one minor fix" of yours that I couldn't figure out :)
<tjaalton> adding the header and running configure/make made it compile, so I figured there was something wrong in the packaging
<tjaalton> so I dropped vmmouse from input-all so it wouldn't prevent installations
<bryce> tjaalton: I'll email the vmmouse guy to bring this to his attention
<tjaalton> I've filed a bug about it too, a sec
<tjaalton> freedesktop bug 19119
<ubottu> Freedesktop bug 19119 in * Other "vmmouse doesn't build against xserver 1.6" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19119
<bryce> done
<bryce> jcristau: want me to file this in the debian bts?  I'm assuming you won't care about it until post-lenny, by which time hopefully there'll be a better fix available.
<wgrant> Are we planning to pull from the xserver 1.6 branch again some time soon? I wonder if some of those fixes fix my crasher that appeared in -0ubuntu2.
<bryce> wgrant: not that I know
<tjaalton> surely after alpha2
<bryce> wgrant: I think the plan is to stick with stock 1.6 + pulled patches
<wgrant> 1.6 hasn't been released yet.
<bryce> k
<bryce> sorry, thought you were talking about the post-1.6 stuff
<wgrant> Ah, no.
<tjaalton> well, the stable branch usually is well maintained, so I don't see a reason why not to follow it if need be
<tjaalton> point releases are of course preferred
<tjaalton> but those might take time
<tjaalton> once 1.6 is released it'll be bugfixes only..
<wgrant> Woo, float XAtom support!
<tjaalton> yep
<wgrant> Well, at least a semi-rejected patch for it.
<bryce> I'm working on https://wiki.ubuntu.com/X/Blueprints/WacomTabletsUi next... anyone have any comments/ideas to include there while I'm at it?
<bryce> alberto covered most of it already, just need to fill in test section, etc.
<bryce> anyone?  bueller?
<tjaalton> great movie :)
<bryce> indeedy.  ok guess I'm about done with this one
<bryce> I'm curious about the dbus-based approach to configuring tablets, and how that might affect alberto's tool
<tjaalton> I think he needs to play with it first
<tjaalton> night
<bryce> night
#ubuntu-x 2008-12-19
<bryce> ok, fleshed out more of https://wiki.ubuntu.com/X/OptionsEditor
<bryce> (that one is getting rather long.....)
<jcristau> bryce: yeah, if it's filed upstream it's fine
<tjaalton> hmm, turns out that nouveau upstream does accept bugs, but not about 3D support just yet
<bryce> tjaalton: we're under 2000 bugs today
<tjaalton> bryce: rejoice!
<bryce> we're also about 2-3 bugs from getting -nv off https://bugs.edge.launchpad.net/ubuntu/+upstreamreport
<tjaalton> I still don't know how to read that page
<tjaalton> ah, wikipage
<tjaalton> xorg shouldn't be on that list
<tjaalton> since the bugs are either just accumulated there because people are lazy or uneducated, or packaging bugs
<bryce> pretty much the three columns worth looking at are the ones under %
<bryce> the first one is % marked triaged, second is % with an upstream link, and third is % that have been reported upstream
<bryce> so the idea is you want to get all three to high values
<tjaalton> the second column counts every 3rd party project
<tjaalton> not just upstream
<bryce> yeah I know :-(
<bryce> I tried bringing that up in Jorge's talk at UDS but guess I didn't get my point across
<tjaalton> if packages had a single "real" upstream project linked to them, it would be easier to count I guess
<bryce> I'd like to make an Xorg-specific version of that page some day.  Some day...
<tjaalton> that would be nice
<wgrant> Packages can have upstreams linked, but it's so rarely done that it's probably not useful for that page.
<lool> tjaalton: Could you wait a little longer before mass rebuilding Xorg modules next time?  armel server wasn't built so I'll repush them again
<tjaalton> lool: I haven't pushed anything since Monday
<tjaalton> probably auto-rebuilds then
<lool> tjaalton: It's probably there since monday
<lool> It's just that we're noticing now :)
<tjaalton> there are a bunch of input-drivers which fail to build, but no-one uses them and they are in universe, so I'll get to them later
<jcristau> heh, https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/304275
<ubottu> Launchpad bug 304275 in libxi "[Intrepid] Recursive dependency for libxi-dev." [Undecided,Incomplete]
<jcristau> sometimes automated mails are not so helpful :)
<jcristau> also i'm guessing https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/304313 should be closed if the Replaces are in place
<ubottu> Launchpad bug 304313 in libxi "libxi-dev and x11proto-input-dev conflict with same files" [High,Triaged]
<jcristau> and, it looks like https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/289762 should go back to gimp or gtk, which should detect when the device goes away
<ubottu> Launchpad bug 289762 in libxi "crashes if I disconnect my drawing tablet while it is open" [Medium,Confirmed]
<lool> tjaalton: I'm preparing a pile of rebuilds for armel; perhaps they are also rebuilds for other arches; I'll send you a list of .changes I'll push just after alpha 2 so that we don't dup work
<lool> -tga ftbfses on all arches
<jcristau> unless you're planning on an alpha port, -tga should be removed
<lool> (I'll let this decision to bryce and tjaalton; I'm happy to do the actual changes to drop it)
<lool> xserver-xorg-video-vga also failed to build
<jcristau> it'd fail to work even if it built, so you can remove it...
<lool> jcristau: Is it being dropped upstream?
<jcristau> pretty much.
<lool> tjaalton: This is what I'll be pushing after alpha 2:
<lool> wacom-tools xserver-xorg-input-evdev xserver-xorg-video-ati xserver-xorg-video-cirrus xserver-xorg-video-fbdev xserver-xorg-video-i128 xserver-xorg-video-i740 xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-nv xserver-xorg-video-r128 xserver-xorg-video-s3virge xserver-xorg-video-tdfx xserver-xorg-video-v4l xserver-xorg-video-vmware
<lool> evtouch also failed to build
<lool> With the above, we should have input-all installable on armel
<lool> Ah I see evdev has a git branch
<lool> tjaalton: (I guess you don't commit simple rebuilds to the git tree since I don't see xserver-xorg-input-evdev 1:2.1.0-0ubuntu2 in git, so I wont add the 1:2.1.0-0ubuntu3 rebuild either)
<pwnguin> sigh
<pwnguin> "I have updated the driver to support both Xorg 1.6 later and earlier.  Does anyone have time to test it on your system?  You'll need to build and install wacom_drv.so from the new linuxwacom package on your system. I prefer you have an Xorg 1.6 running.  Please reply to me directly so I can email the package to you."
<pwnguin> how does someone run an open source project for years without experimenting with branching?
<pwnguin> (also is 1.6 even out? or just 1.5.99b3
<bryce> pwnguin: he probably means 1.5.99b3
<pwnguin> (is that in the jaunty repos?)
<pwnguin> ive not been paying a lot of attention lately --  new job
<bryce> ah congrats
<bryce> yep, entered jaunty last week
#ubuntu-x 2008-12-20
<tjaalton> lool, jcristau: yes, tga and vga should be dropped soonish
<tjaalton> lool: go for it
<bryce> ok, time for some -intel driver bug spamming...
<bryce> heya tjaalton
<bryce> spamming complete... 170 bugs affected
<pwnguin> heh
<pwnguin> you know, i actually subscribe to entire packages
<bryce> pwnguin: so then enjoy all the emails from me.  :-)
<bryce> bbl
<bryce> oh hey, btw I've also switched -ati from XAA to EXA by default.  Lemme know of any new problems this causes.
<lool> Cool
<lool> bryce: Hmm your automatic notice was also sent to bugs which were already upstreamed
<lool> Such as #149430
<bryce> lool: yeah I considered excluding them, but figured re-testing with latest may make sense, in case the issue had gotten resolved upstream but the bug not updated.
<lool> bryce: Some of the bugs in your -ati uploads didn't have any # and probably weren't closed as a result: was this on purpose?
<lool> Sorry if it was
<mahfiaz> hi everybody, I am having problem with this intel default setting which sets external monitor to primary
<mahfiaz> is there any workaround, and can this be applied to ubuntu by default, I suppose working around weird defaults would make sense
<mahfiaz> bryce, anybody?
<bryce> lool: no wasn't on purpose; I cursed and then went back after and closed them manually
<bryce> mahfiaz: the defaults are not weird if you consider the case of someone connecting to a projector
<jcristau> with randr 1.3 you can at least change the primary
<bryce> mahfiaz: the reason it's like this, is that there are two crtcs and afaik the LVDS can only be connected to the second.  The first is the primary display if anything is connected to it
<jcristau> sounds right
<mahfiaz> bryce, jcristau, bad thing is it is laptop, and on whenever I connect, it is on the external
<mahfiaz> but I get the point, not anybody is able to figure out how to get picture to the external one then
<mahfiaz> but this i why default is cloning
<mahfiaz> jcristau, on intrepid I have randr 1.2, I think I have to upgrade to unstable give it a try, I will keep you posted
<mahfiaz> bryce, I also sometime told you that I had never seen openoffice external monitor support working, but I works fine, when multiple monitors are available
<joumetal> i815 isn't working at all with latest upgrades.
<joumetal> however using kernel without i810 drm (hopefully right word) it works as before.
<tormod> joumetal: so you delete or unload i810.ko ?
<joumetal> i am using custom kernel now.
<tormod> joumetal: ok. does it freeze at X startup? logs?
<joumetal> yes at startup. it's giving a 10 line long backtrace.
<tormod> well please add the backtrace to your bug report
 * joumetal goes reporting
<joumetal> reported as bug 310075
<ubottu> Launchpad bug 310075 in xserver-xorg-video-intel "[i815] xserver doesn't start in jaunty" [Undecided,New] https://launchpad.net/bugs/310075
#ubuntu-x 2008-12-21
<Ng> I've noticed that things like gdm and the failsafe x stuff have reeeeally tiny fonts on my TV. it's 1920x1080, but with low dpi, and they're just tiny and unreadable. Is it possible to change that somehow?
<bryce> hey, I'm getting lots of good replies on the -intel bulk mailing.  Not as many "it works now" as I'd hoped, but some...  lots of people are doing testing though :-)
<marijus> hello, why do i get aiglx: screen 0 is not dri2 capable in my xorg log on intel i915 - jaunty? 
#ubuntu-x 2009-12-14
<BedPost> hey so I'm having some real weird problems with either compiz or x, anyone got a minute to help?
<Sarvatt_> the failure to start and kicking me to a garbled failsafe login is even happening with edgers now on all the kernels, every time i have to fsck it happens
<Sarvatt> gdm exit status 1 message then failsafe starts
<RAOF_> Sarvatt: What would you think of getting xorg-edgers mesa trunk to build a gallium package that dpkg-divert'ed the necessary bits?
<RAOF_> Because nv40 gallium is sufficient to run compiz at (annoyingly) better than i915-speeds, with only minor visual glitches :)
<tjaalton> what bits need to be diverted?
<RAOF_> As I understand it, libgl mostly.
<RAOF_> I'm moderately sure that the gallium libgl is incompatible with the normal mesa variant.  However, Sarvatt is the one who'se looked into it most closely.
<RAOF_> Mmmmmm.  Wobbly windows is an excellent example of where nouveau doesn't quite work :)
<metellius> tseliot: you are certain that there is no specific driver package for the drm package that can be compiled?
<metellius> drm driver
<tseliot> metellius: I wish there was one :-/
<tjaalton> it comes with the kernel
 * tseliot nods
<metellius> I see
<metellius> I guess I'll have to continue the kernel compilation process then... I paused halfway, thinking there might be another way
 * tseliot 's attemps to make a DKMS package to update drm failed miserably
<metellius> is it (relatively) easy to do the whole kernel compile on another (also 32bit) karmic pc and copy the result over to my laptop?
<tjaalton> check https://help.ubuntu.com/community/Kernel/Compile
<ara> bryce, hi
<tseliot> ara: I think he's still asleep ( ~4 AM there)
<ara> tseliot, ok, it was regarding my bug https://launchpad.net/bugs/496497
<ubottu> Ubuntu bug 496497 in xserver-xorg-video-nv "[nvidia] After upgrading to Lucid from Karmic, X crashed " [Undecided,New]
<ara> tseliot, I enabled nvidia 185 and it removed xorg-xserver package
<ara> nice
<tseliot> ara: that's because we don't have an nvidia driver that works with lucid's X yet
<tseliot> ara: I'm working on it. I've been busy with oem stuff
<tseliot> I'll upload new drivers this week
<ara> tseliot, nice :)
<tjaalton> tseliot: are you renaming it as well?
<ara> tseliot, can you tell me when you're done, please?
<tseliot> ara: sure
<tseliot> tjaalton: we didn't come to an agreement about the new names, did we?
<tseliot> see pitti's objections in the blueprint
<tseliot> tjaalton: the blueprint is here: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers
<tjaalton> thanks, reading
 * tseliot -> lunch
<tjaalton> tseliot: well, superm1 has a point, it can be done
<tjaalton> hmm wait, I need to think this over :)
<tjaalton> yeah, I don't think simple package relationships are enough to make it work correctly
<tjaalton> and relying on update-manager isn't enough
<tjaalton> here's an idea; ignore all crash bugs from the blobs, where the stacktrace points to libGL or the driver
<tseliot> tjaalton: right we'll still need something like nvidia-common in some cases
<tseliot> tjaalton: what's the purpose of your idea?
<tjaalton> tseliot: we can't do anything about the crashes
<tjaalton> they just clutter up the buglist
<tseliot> tjaalton: aah, so it wasn't related name schemes in any way
<tjaalton> no :)
<tseliot> ok, I think it's a good idea then ;)
<tjaalton> bryce_: your totals graph doesn't include private bugs, which means ~150 bugs more :)
<tjaalton> those won't show up on searches either, so they just need to be made public in order to be visible
<Sarvatt> RAOF: nice, you can run compiz on nv40? it just freezes here on nv50 :(
<Sarvatt> where is the "Dropping master" message that writes over top of the plymouth splash right before X starts coming from?
<Sarvatt> hmm havent seen debian/patches/02_silent_master.diff in libdrm before
<tseliot> Sarvatt: you might want to ask Keybuk about that
<Sarvatt> thanks, found it though, its libdrm and that patch thats not in git removes it
<Sarvatt> i pushed the 2.4.14-1ubuntu2 release changes to libdrm git
<Sarvatt> btw, noticed we're building r600 with mesa now, does that even work with libdrm 2.4.14?
<Sarvatt> ah i was remembering the versions wrong, whole bunch of libdrm releases when I wasn't around
<tseliot> heh, right
<Sarvatt> thought 2.4.14 was 2.4.12
<tseliot> Sarvatt: 2.4.14 lacks the 3D ioctl support for r6xx/r7xx gpus but otherwise it should work
<tseliot> wait, I'm confusing it with the kernel drm
<bryce> morning
<tseliot> morning bryce
<Sarvatt> wish they didnt sneak in a bunch of buggy intel libdrm changes right before 2.4.16 released :D
<Sarvatt> morning bryce!
<Sarvatt> hmm control+alt+fx keys arent working from a vt to switch back to X, evdev getting suspended on vt switch with the udev change maybe?
<Sarvatt> chvt 7 works fine if i log in
<tjaalton> have you upgraded to 2.3.2?
<Sarvatt> yeah but i havent restarted x since then, will try now
<tjaalton> it fixed my booting problems
<Sarvatt> control+alt+f7 still doesn't work from a VT
<Sarvatt> i get [   78.329930] (II) "AT Translated Set 2 keyboard": Device reopened after 1 attempts. after i chvt 7 to get back is why i was thinking of the udev stuff
<tjaalton> ok
<bryce> oddly, on my -ati system running Karmic, monitor power savings had started working perfectly the last couple months of Karmic, but in the last week or two has not been powering off the monitors anymore
<bryce> wonder what'll happen when I go to lucid ;-)
<tjaalton> *boom*
<tjaalton> :)
<bryce> yeah most likely
<Sarvatt> they are making it so we have to have libdrm headers actually get installed now, intel won't build against linux-libc-dev headers unless they come from a 2.6.33 kernel.. ugh
<tjaalton> edgers, bah :)
<Sarvatt> i stopped using it because intel's been so unstable for the past 1.5 months
<Sarvatt> but if we pull in 2.10 later...
<tjaalton> there probably will be a 32.x
<Sarvatt> its too big to go to stable i believe and its a new feature not a fix :(
<Sarvatt> (KMS overlay support)
<tjaalton> then the kernel team will pull it
<Sarvatt> wonder what debian is going to do, they cant pull in 2.10rc2 into experimental 
<Sarvatt> oh they're on a 2.9.1 still, thought they had 2.9.99.901 already
<Sarvatt> hyperair: i think its because of the pm-utils 1.30rc1 dropping hal quirks
<Sarvatt> 98smart-kernel-video is gone, im not sure how it does things now
<Sarvatt> it had add_parameters --quirk-no-chvt in there before though
<Sarvatt> i dont get a vt switch suspending though
<Sarvatt> ah its in 98-video-quirk-db-handler now, i'm not sure but it looks like it checks the vendor and device id's now though to figure out quirks?
<hyperair> Sarvatt: the intel-gfx people said that the kernel chvts anyway
<Sarvatt> hyperair: try pm-sleep --quirk-no-chvt manually?
<hyperair> Sarvatt: i checked, pm-utils is't the cause of the chvt
<Sarvatt> ah ok
<hyperair> Sarvatt: when i did echo mem > /sys/power/state, it chvt'd as well
<Sarvatt> if i get a chvt i dont even notice it, screen goes off the second the fan and power light go off
<hyperair> yeah that's how it is for me when i'm on single-head
<Sarvatt> ahh gotcha, i've never run multihead on this thing
<superm1> bryce, would you mind committing this to git?  i can't seem to get to debian git from where i'm at right now behind some proxies.  i'm going to upload it shortly to lucid
<superm1> http://pastebin.com/f588376f
<bryce> superm1, sure
<superm1> thanks
<tjaalton> failsafe fails when kms is already in use
<tjaalton> at least on my intel
<bryce> fails in what manner?
<Sarvatt> same here
<tjaalton> no picture
<Sarvatt> garbled screen
<bryce> is it because vesa is being loaded?
<tjaalton> I can change the vt to a virtual console, but still nothing on screen. when changing back to the vt where X should be running, I see what the previous vt had
<tjaalton> probably
<tjaalton> dunno if fbdev would work better
<bryce> could we detect kms in some fashion, and make it not force vesa in that case?
<bryce> btw, why did it go into failsafe mode to begin with?
<bryce> tjaalton, I'd tried fbdev early on but found it didn't work right on some cards
<tjaalton> bryce: evdev crashed for some reason, the new version seems to work
<tjaalton> well, intel/ati/nv should not use vesa then :)
<tjaalton> sorry, nouveau
<bryce> mm
<bryce> tjaalton, could you file a bug against xorg (and marked wishlist) to make failsafe-x use fbdev in these cases, and assign to me so I don't forget?
<tjaalton> yep
<tjaalton> I need to test fbdev first :)
<tjaalton> otherwise I'd just let the server pick, if fbdev doesn't work
<tjaalton> afk->
<Sarvatt> when i change to a vt it goes black, and i cant change from vt to x no matter what here without doing it manually. as for why it goes failsafe at all the only thing i've been able to figure out is it happens when i need to fsck on  my own kernels. but with the ubuntu 2.6.32-7 kernel i get failsafe 50% of the time pretty much consistently for no apparent reason..
<Sarvatt> can i just edit /etc/X11/xorg.conf.failsafe to use fbdev to see if it works any better, or is that set somewhere else?
<Sarvatt> dont know if i just have old stale files lying around
<bryce> Sarvatt, yeah edit it there (or leave Driver blank)
<Sarvatt> oh yeah i get a gdm stopped with exit status 1 message before the garbled failsafe starts
<bryce> the places to look for error messages are the Xorg.0.log[.old], dmesg, and /var/log/gdm/
<bryce> yeah failsafe-x shuts down gdm when it starts up
<Sarvatt> i dont get any logs there during failsafe, looked everywhere i could
<bryce> (in the past, if it didn't, gdm would just try to respawn X; dunno if it'd still do that or not)
<Sarvatt> its only got the good boots
<bryce> hmm weird
<bryce> I wonder if gdm has a verbose or debug mode
<Sarvatt> failsafe_log=${BPX_LOG:-"/var/log/gdm/failsafe.log"}
<Sarvatt> hmm wonder why i dont have one
<Sarvatt> serverargs="${serverargs} -br -once -config $xorg_conf_failsafe -logfile /var/log/Xorg.failsafe.log" oh ok theres the xorg log
<Sarvatt> this ones using edgers but i got the same problem on both  http://paste.ubuntu.com/341434/
<Sarvatt> going to try out fbdev, i'm not using edgers anymore
<Sarvatt> thats odd, switching it to fbdev made it load intel with swrast?
<Sarvatt> sudo tune2fs -C 34 /dev/sda1 then reboot gives me failsafe 100% of the time on any kernel btw, max mount count before checking for that partition is 34
<bryce> Sarvatt, hmm, and no error messages as to why?
<bryce> tjaalton, what's the status on xf86-input-wacom?  Does it just need a MIR or is there more to be done?
<Sarvatt> i dont see anything at all, plymouth shows the graphic and theres no feedback that a fsck is even happening outside of the hdd light going. i'll try without a splash
<Sarvatt> it faded to white for a second then came up with the failsafe X menu though, I picked use low resolution mode for this session and it started up and the logs look normal outside of it using swrast
<Sarvatt> well I guess it used xorg.conf for some reason instead of xorg.conf.failsafe, Xorg.0.log says it did at least [    0.021742] (==) Using config file: "/etc/X11/xorg.conf"
<Sarvatt> ah old log even though the timestamp is current.. what the heck
<Sarvatt> http://paste.ubuntu.com/341471/
<bryce> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
<bryce>   weird
<bryce> maybe an abi mismatch?
<Sarvatt> Provides: xserver-xorg-video-6
<Sarvatt> its working great
<Sarvatt> way better than vesa ever did and at native resolution
<RAOF> Hm.  If tselliot comes back in, point him at nouveau-kernel-source as a template for using dkms to do drm updates.
<bryce> RAOF, maybe drop him an email?
<RAOF> Let's see if I can find his email address...
<bryce> alberto.milone@canonical.com
<Sarvatt> switching to vt8 to check on the error messages when your control+alt+f-keys dont work from a vt = bad idea :D
<Sarvatt> thats the 8th reboot in a row i've gotten failsafe though forcing a fsck, pretty safe to say its always gonna happen
<RAOF> Thanks.  Thta's easier :)
<bryce> Sarvatt, hmm so the fsck is stealing the vt, and gdm is probably crapping that it can't take it to start up X, or some such
<bryce> however I would think the gdm logs would mention something about that if this is the case
<Sarvatt> http://sarvatt.com/downloads/failsafeX-backup-091214172957.tar
<Sarvatt> is failsafe x supposed to start on vt2?
<bryce> it shouldn't care what vt its on
<bryce> [    0.000000] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
<bryce> [    0.000049] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
<bryce> [    0.000073] (WW) xf86OpenConsole: VT_GETSTATE failed: Bad file descriptor
<bryce> bingo
<Sarvatt> Fatal server error:
<Sarvatt> Server is already active for display 0
<Sarvatt> ah yeah same log i was looking at
<bryce> yeah this is looking like gdm is trying to fire up X on a specific vt and getting a 'bad fd' error
<bryce> and crapping itself
<bryce> failsafe-x is less fussy about what vt to use, so just picked the first unused one I guess (vt2)
<bryce> perhaps the gdm upstart job needs to be given smarts to detect if a fsck is going on, and block on that
<Sarvatt> i think there was just a change in the fsck routine at boot in the past few days because i saw Keybuck talking about it in another channel, something about running alot of things in parallel during a fsck and letting the kernel scheduler sort it out and booting faster
<Sarvatt> i have no clue though, lemme see if it still happens without plymouth
<Sarvatt> nevermind I know it does, didnt have it installed yesterday when i first noticed it
<Ng> ooh brief visual corruption there
<Sarvatt> oh the failsafe x archive log option doesnt add Xorg.failsafe.log to the tar
<Ng> bryce: does upstart have sufficient clue to say "/home is available" whether it's a separate mount or not? If not shouldn't it be waiting for all local filesystems to be mounted?
<Ng> in fact shouldn't gdm always start after local mounts are done?
<jcristau> why local? nfs /home should be there, too, no?
<Ng> a fair point, I was only thinking about the fsck case
<bryce> Sarvatt, right there should be no point - that's just the log for the failsafe session itself, which by definition is fine if the user was able to get in and generate the tar in the first place ;-)
<Sarvatt> ah good point, i was just going to file a bug using the files in there and was thinking of it that way :D
<bryce> Ng: beyond my upstart-fu...  I assume it ought to be able to either detect if the mounts are there, or test if vt7 can be used, but I really have no clue
<bryce> I'd suggest filing a bug report but probably keybuk would just close it as wontfix
<Ng> heh
<Ng> should xinput stuff be working atm in lucid?
<Ng> my trackpoint isn't showing up
<Ng> it works though
<Ng> I just can't poke at its properties
<bryce> xinput should be working afaik
<Ng> aha, got it, the trackpoint's properties are on PS/2 Generic Mouse and I just need to include " in some of the names
<Ng> no more trackpad \o/
<Sarvatt> bryce: should I file a bug against xorg or gdm or something else even about the fsck thing?
 * Sarvatt doesnt know what the problem is even
<bryce> Sarvatt, mm
<bryce> Sarvatt, probably the change needs to go to gdm's upstart script
<bryce> Sarvatt, oh you know what, this reminds me of a bug I ran across
<bryce> Sarvatt, try commenting out the line in gdm.upstart that refers to tty7
<bryce> 	  and tty-device-added KERNEL=tty7
<Sarvatt> maybe you could check if KMS is in use the same way pm-utils does before picking the fallback_driver in /etc/gdm/failsafeXServer? 
<bryce> or if it is missing try adding it
<bryce> how does pm-utils do it?
<Sarvatt> using_kms() { grep -q -E '(nouveau|drm)fb' /proc/fb; }
<bryce> Sarvatt, would you mind filing a bug against xorg assigned to me, suggesting that?  Sounds like it should be straightforward but probably I won't get to it until after the holidays
<Sarvatt> cat /proc/fb
<Sarvatt> 0 inteldrmfb
<Sarvatt> okie
<Sarvatt> grep -q -E '(nouveau|drm)fb' /proc/fb && echo "yes"
<Sarvatt> yes   is what I meant to paste there
<bryce> Sarvatt, https://bugs.launchpad.net/bugs/491162
<ubottu> Ubuntu bug 491162 in gdm "gdm does not start X unless remove "tty-device-added KERNEL=tty7" from upstart gdm.conf" [High,Fix released]
<Sarvatt> ohh
<Sarvatt> i heard about that bug but didnt read it, guess it should be worked around when the new mountall is uploaded
#ubuntu-x 2009-12-15
<Sarvatt> wow they sure sat on that one, 04_fedora_glx14-swrast.diff just went to xserver master
<Sarvatt> vga16fb seems to be always loaded now since 2.6.32-7 though, fbdev should work with that?
<Sarvatt> then again i think thats 640x480
<Sarvatt> no change adding the and tty-device-added KERNEL=tty7 line back to the gdm upstart conf
<bryce> hrm
<Sarvatt> (failsafe after fsck)
<Sarvatt> the plymouth-desktop transition is really darn nice now though using the lucid kernel
<Sarvatt> going to try adding "and stopped udevtrigger" and see if that works for now, i know its the opposite of all this fast boot stuff wants but i'd rather not have failsafe every silent background fsck
<bryce> Sarvatt, agreed
<Sarvatt> where is PRIMARY_DEVICE_FOR_DISPLAY=1 exported? maybe they could add something similar for FSCK_COMPLETED or something
<Sarvatt> switched it to this, lets see if it works like it used to
<Sarvatt> start on (filesystem
<Sarvatt>           and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
<Sarvatt>                or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1)
<Sarvatt>           and stopped udevtrigger
<Sarvatt> woohoo it worked
<bryce> sweet
<Sarvatt> hope i did that right - https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/496796
<ubottu> Ubuntu bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New]
<Sarvatt> dkms: Revert the code that runs DKMS as the user "nobody". -- sweet I can use ccache again! thanks superm1!
<superm1> Sarvatt, yeah i really want to fix that so that it doesn't build as root, but dont have a good solution still, so this is the better way to go for now
<Sarvatt> it was trying to create a new cache folder for the nobody user before because my /usr/local/(g)cc links to ccache, but i dug myself into that hole :D
<superm1> Sarvatt, i might still tweak how this new bulletproof-x stuff for building the modules works.  its a functional solution right now, but has the potential to be racy
<Sarvatt> if the upstart job has to build the module, does it just continue to failsafe while it builds?
<Sarvatt> i'm looking at it now but not sure because fb0 would probably exist even if it needed to build
<Sarvatt> oh i guess it checks if dkms exists every time gdm starts there and checks if it needs to build nvidia or fglrx if so, but the gdm upstart job is already started and exits if it does?
<Sarvatt> i really need to read up on all this new upstart stuff :D
<bryce> no it shouldn't go into failsafe just because it needs time to build the module
<bryce> yeah I need 'upstart for dummies' too
<verbalshadow> anyone have problems with ati graphics in the new kernel(ish) 2.6.32.8.8 i get "white scanlines" and the mouse freezes
<Sarvatt> ohh i see, i missed the whole failsafe x upstart job in the xorg metapackage tying it all together
<Sarvatt> so is it possible build-successful could return true and make gdm start before the graphics-device-added or udev settles I guess?
<Sarvatt> startup - filesystem mounted (2.5 seconds in) - (dkms runs upstart job starts here?) - udev starts (6 seconds in) - fb0 initialized to vga16fb (9 seconds in) - (gdm would start here or possibly earlier if dkms upstart returns build-successful?) - nvidia module loading (10-12 seconds in) - udev settles after udevtrigger stops and gdm would start here even if graphics devices werent ready and no dkms was installed (16-24 seconds in)
<Sarvatt> any way it could pass build-successful that fast if I'm not misinterpreting it? :D just looking at the timestamps on my nvidia box
<superm1> Sarvatt, yeah that's the worry
<superm1> either that or it issues build-successful while dkms is checking the status before quiting the gdm job
<superm1> i'm going to do a more thorough look at it tomorrow to try to reproduce some of these race conditions
<superm1> someone proposed a really novell solution on a bug that i like
<superm1> creating a "dummy" job for fglrx and nvidia that starts on starting gdm
<superm1> at this point they're all hypothetical anyway
<Sarvatt> nvidia sure does load late in the boot process, and takes a full 2 seconds to load here not doing anything else
<Sarvatt> a dummy upstart scripts that get installed with nvidia common that just returns true that gdm depends on to start, but an actual upstart script that replaces it installed along with nvidia-kernel-source maybe? :D
<tjaalton> bryce: Ron hasn't packaged it yet, said there were still some issues
<superm1> Sarvatt, well it would be a dummy script in the sense that all it did was delayed the boot, but yes it would be installed by the equivalent of nvidia-kernel-source
<superm1> and fglrx-kernel-source
<tjaalton> RAOF: do we still need a nouveau patch on top of 2.4.16? I'd think not, at least not yet
<soren> Do we have any clue what is causing bug #494627?
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,New] https://launchpad.net/bugs/494627
<soren> ..and more importantly: Is any sort of fix in sight? :)
<tjaalton> soren: no idea.. switching to nouveau probably fixes it ;)
<soren> tjaalton: Package description says " Note that these drivers are INCOMPLETE, and are only really useful for testing at this point.
<soren> "
<soren> Is that still accurate?
<soren> ..or can one actually reasonably use them?
<tjaalton> I'm not sure where we stand right now
 * soren takes it for a spin
<tjaalton> the kernel should pull nouveau drm, and the ddx should be updated
<soren> The following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is not going to be installed
<soren> :(
<tjaalton> yes, it should be rebuilt
<tjaalton> to provide video-abi-6
<tjaalton> build it in pbuilder, it's not hard ;)
<soren> Just as is? No changes?
<tjaalton> right
<soren> Cool.
 * soren does that
<soren> tjaalton: Oh, how about the one from xorg-edgers?
<tjaalton> don't know about that one
<tjaalton> probably has some other deps
 * soren feels adventurous
<tjaalton> tseliot: also first/last name
<tjaalton> and email of course
<tseliot> tjaalton: yes, of course
<tseliot> tjaalton: I got stuck in the verify your account thing
<tjaalton> dunno, been too long since I created mine
<tseliot> hehe no wonder the patch caused the build to fail, there was a "static Bool" without a function
<tjaalton> oh, a refresh boog?
<tseliot> oh, maybe that was meant to be put before XkbDDXCompileKeymapByNames (which has no return type)
<tjaalton> check the old version how it looked like
<tseliot> yes, I was right
<tjaalton> great, if it was that simple :)
<tseliot> tjaalton: BTW as regards alioth I was using my username instead of my username-guest to confirm my account
<tseliot> I have an account now
<tjaalton> great
<tjaalton> jcristau: could you add tseliot to pkg-xorg?
<tjaalton> tseliot: then check the wikipage on how to get started https://wiki.ubuntu.com/X/GitUsage
<tseliot> tjaalton: ok, thanks
<tjaalton> lunch->
<jcristau> done.
<tseliot> thanks
<tjaalton> tseliot: once you're done with the patch, feel free to push it :)
<tseliot> tjaalton: ok
<tseliot> tjaalton: where's the debian/patches directory in git?
<tjaalton> tseliot: the same place?
<tjaalton> when you cloned it, you'll end up in debian-unstable branch
<tjaalton> git checkout -b ubuntu origin/ubuntu
<tjaalton> and you are using our branch
<tseliot> yes, I did that
<tseliot> maybe I used the wrong branch, let me try again
<tjaalton> git status will tell you
<tseliot> tjaalton: $ git push origin ubuntu
<tseliot> fatal: The remote end hung up unexpectedly
<tjaalton> check the config
<tseliot> shall I add my username in my git file?
<tjaalton> depends how you cloned it
<tjaalton> .git/config
<tjaalton> change the "origin" remote to have an url like "ssh+git://tseliot-guest@git.d.o..."
<tseliot> tjaalton: and how do I do that?
<tjaalton> edit the file :)
<tjaalton> xorg-server/.git/config
<tseliot> aah, ok
<tseliot> tjaalton: should it be @alioth.debian.org/git/ (as on the wiki page) or @git.debian.org/git/ ?
<tjaalton> both work
<tseliot> ok
<tjaalton> fixed the wiki to point at git.d.o
<tseliot> tjaalton: ok, pushed
<tjaalton> tseliot: thanks, I'll update the changelog and release
<tseliot> oh, I forgot to do that
<tjaalton> you can do that as well ;)
<tjaalton> change "lucid" to UNRELEASED
<tseliot> ok, sure
<tseliot> tjaalton: ok, pushed again
<tjaalton> tseliot: thanks, I'll release it now
<tseliot> tjaalton: thanks for your help
<tjaalton> ..and enable the patch too :)
<tjaalton> tseliot: btw, if you have time, check patch 135 too if it's similar
<tseliot> someone should have had more sleep :-P
<tjaalton> anyway, I'll upload this now
<tjaalton> hehe
<tjaalton> I've enabled it here, will upload now
<tjaalton> 190 that is
<tseliot> tjaalton: ok, I'll pull your commit from git then
<tseliot> and have a look at 135
<tjaalton> yes, that's usually the first thing to do, to avoid conflicts
<tjaalton> especially when you touch the changelog
<tseliot> right
<tseliot> tjaalton: pushed?
<tjaalton> btw, synaptics is in git as well. maitain it there if you don't mind
<tjaalton> yes
<tseliot> ok, sure
<tjaalton> damn typos
<tseliot> git rebase origin/ubuntu
<tseliot> Current branch ubuntu is up to date.
<tjaalton> git pull
<tseliot> oh, right
<tjaalton> rebase is kinda dangerous
<tjaalton> uh
<tjaalton> it's on wiki
<tseliot> git pull = bzr pull
<tseliot> yes, it's what I'm following
 * tseliot -> lunch
<tjaalton> I should probably add a git fetch there
<tjaalton> although pull does mostly the same
<tseliot> tjaalton: who did write patch 135?
<tseliot> as Signed-off-by != Author
<tjaalton> tseliot: bryce, according to the changelog
 * tseliot 's new radeon HD4670 has just arrived
<tseliot> \o/
<tjaalton> with loud fans? :)
<tseliot> it says "arctic cooling: Cool and silent"
<tseliot> we'll see to what degree this is true
<tjaalton> wow, that's humongous
<tseliot> yes, it's a fan with a graphics card attached
<tjaalton> radeon drm doesn't support proper power management yet, so the fans are always on full blast
<tjaalton> hehe
<tjaalton> I'm thinking of getting a passively cooled HD3xxx
<tseliot> didn't Matthew Garret worked on power saving?
<tjaalton> to replace the GF8600GT
<tseliot> usually I don't get cards with fans
<tjaalton> yes, but I'm not sure how far the support is
<tseliot> AMD sent me this card for testing though
<tjaalton> that's a motivator to work on it ;)
<tseliot> absolutely
<apw> bryce_, just a heads up that i have enabled ATI Radeon KMS again as discussed
<tjaalton> apw: what's the status with nouveau?
<apw> tjaalton, "near the top of my list" for review of how we can integrate it
<tjaalton> apw: you probably know that it's going to land in .33, so pulling straight from there is probably easiest
<apw> yeah know its in there, hope so yes
<bryce__> apw, excellent
<apw> bryce__, you heard of anyone complaining that they don't get nvidia output unless they supply 'nomodeset' on the kernel command line?
<apw> unexpected i know, given there is no KMS for nvidia at the moment
<bryce__> hmm on nvidia...
<bryce__> apw, sarvatt was mussing with this yesterday in fact
 * bryce__ reviews scrollback
<bryce__> the specific issue he was chasing was https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/496796
<apw> bryce__, yeah nvidia, i thought it most odd but they seemed to have confirmed the behaviour
<ubottu> Ubuntu bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [High,Triaged]
<bryce__> not sure that's exactly the issue you're looking for though
<apw> hrm, i have suspicious he has filed a bug on the subject which is why i know about it
<bryce__> oh wait, maybe that was against an intel chip
<tjaalton> it was
<bryce__> apw, in any case, that is the main bug I'm seeing people mention right now in regards to kms problems
<apw> nothing till they say nomodeset, then all working
<bryce__> apw, I haven't been looking at -nvidia bugs much though
<tjaalton> well, -nv seems bust anyway
<tjaalton> bug 494627
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,New] https://launchpad.net/bugs/494627
<tormod> I had an X crash and back on vt1 I saw that things I had been typing in Terminal and Firefox had been echoed there. does that ring a bell for anyone? I vaguely remember some bug could cause this, something not deattached when switching vt for X or so. upstart?
<tormod> btw, this was a clean install from the 20091215.1 iso (onto a USB stick)
<bryce__> tormod, you're maybe thinking of that evdev bug we had a while ago
<tormod> gdm 2.26.1-0ubuntu5 changelog mentions 81_initial_server_on_vt7.patch which could be something like this
<tormod> bryce__, I was not able to find anything like this in the evdev changelog. do you remember when this was?
<bryce__> there might have been a security thingee on it
<tormod> yeah I could read a couple of my passwords on the console :)
<bryce__> maybe jaunty?
<bryce__> kees, do you remember a bug where keyboard strokes leaked through from X to the console?
<bryce__> aha!!
<tormod> evdev 1:2.0.99.3-1 mentions "to make sure the console is set to RAW mode.", related?
<bryce__> xserver-xorg-input-evdev (1:2.0.99+git20080912-0ubuntu2) intrepid; urgency=low
<bryce__>   * 101_evdev-close-fd.patch: Fix issue where keystrokes on tty can "leak"
<bryce__>     into the X session after vt switch, due to an fd still being open.
<bryce__>     (LP: #276887)
<bryce__>  -- Bryce Harrington <bryce@ubuntu.com>  Fri, 03 Oct 2008 13:52:36 -0700
<tjaalton> yes
<tormod> hmm why is this not in the packaged changelog.Debian.gz?
<tjaalton> because it was synced since
<bryce__> http://changelogs.ubuntu.com/changelogs/pool/main/x/xserver-xorg-input-evdev/xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu5/changelog
<tormod> tjaalton, but it has some ubuntu versions?
<tjaalton> that has been upstream for a long time
<tormod> the Debian package was based on Ubuntu one?
<tjaalton> yes
<tormod> anyway, thanks! this was the bug I had in the back of my head somewhere
<tormod> but why would I get something like this now? I can try to boot into it again and look at Xorg's fd's
<bryce__> watch lsof maybe?
<tormod> I'll try. I did not switch VT myself in this case, but of course the was the initial switch.
<tormod> ls -l /proc/`pidof X`/fd/ should do the job I think
<kees> bryce__: yeah, it was evdev (you found it, sorry for the late reply)
<tjaalton> doesn't leak here
<tormod> seems like I easily ends up with two X servers, on :0 and :1
<tormod> if i type in wrong password, gdm restarts
<tormod> and then I have two servers. Additionally switching consoles makes for hang or panic. note I am on radeon, not intel :)
<tormod> what's strange is that ps shows failsafe on :0 and normal on :1, but Xorg.{0,1}.log indicates the opposite
<bryce> hmm
<bryce> failsafe should be writing to Xorg.failsafe.log, not to a 0 or 1 log
<tormod> I wonder if it's only me. anyone else tried a fresh install todayish?
<bryce> I upgraded to current on my laptop a few hours ago and it rebooted ok
<bryce> but not a fresh install
<tormod> my main install (upgraded since karmic a2) is fine
<superm1> bryce, keybuk indicated that this and/or case for startup of an upstart script is buggy
<superm1> so that might be whats causing it
<superm1> he wanted to back out all of my changes with upstart dkms etc
<superm1> so  probably should back out the stuff to failsafe-x too
<bryce> superm1, ok, what's the plan to solve the root cause issue?
<tormod> bryce, ok I have Xorg.failsafe.log too, but Xorg.1.log had VESA stuff
<bryce> hrm, this patch 135 rework is thorny
<superm1> bryce, no more building modules during boot
<bryce> tormod, if failsafeX is putting stuff into Xorg.1.log that sounds maybe like a bug
<tjaalton> bryce: btw, probably we could renumber some of the patches, like the ones that are never going upstream
<bryce> tjaalton, not a bad idea
<superm1> which i still dont know how much i agree with, it was a very good last defense for problems
<tjaalton> bryce: so that one should be close to 100 :)
<bryce> tjaalton, do you think I should try sending it upstream?  I assume they'll just reject it.
<superm1> but dkms has grown an apport package hook at least now that will allow users to file bugs on modules that fail to build
<bryce> tjaalton, but then they do always say we don't send them feature development work, so...
<tjaalton> bryce: I don't actually know how useful it is without apport, so can't tell
<bryce> superm1, no building modules during boot - so will be built pre-boot all the time?
<tjaalton> but it sounds like it could be useful.. so why not try?
<superm1> bryce, yeah that's the idea
<superm1> that's how they are supposed to work anyway Today already too
<bryce> superm1, well I would favor such an approach, seems less fragile.  Key is to ensure it has really good error handling
<superm1> well i'm thinking the error handling should be superb now, the problem is the order people install things for whether the autoinstall hook gets called for different kernels
<tjaalton> bryce: also, to fix the driver autoconfiguration to work even when there is a conffile present would probably be valued highly upstream ;)
<bryce> let's just hope keybuk doesn't get it in his head to speed up installation/upgrade time ;-)
<superm1> lol
<bryce> tjaalton, yeah on my todo list
<tjaalton> bryce: it also touches this dkms stuff, so if something goes wrong, it should still be able to fall back to the free driver
<tjaalton> but it's just.. work :)
<superm1> touches what dkms stuff?
<tjaalton> superm1: well, the idea that if there is no module available, it should still manage to get X up
<tjaalton> or was that referring to the nvidia renam stuff
<tjaalton> rename
<superm1> well at least get X up in failsafe mode
<bryce> tjaalton, if you can write up your thoughts on how the driver autoconfig stuff should work, I'll look into coding it over the holidays
<superm1> is this that patch that i tried with you at UDS bryce ?
<bryce> superm1, that's the one
<superm1> sweet.  didn't it look like the main problem with it was just like a missing ;; or something?
<tjaalton> bryce: sure. jcristau even had some ideas how to implement it
<bryce> superm1, was missing an else.  but tjaalton's ideas are to go a bit beyond that and generalize a bit further so it works in a wider range of circumstances whether xorg.conf is there or not
<superm1> bryce, ah very good.
<tjaalton> bryce: also, if you've followed xorg-devel, dan has posted patches to add support for xorg.conf.d-directory, where packages can install config snippets for the drivers etc
<superm1> bryce, something else to be cognizant of, i think that fglrx has some other demands that it wants in "xorg.conf" still other than just the driver name
<tjaalton> and the udev backend probably will drop support for adding options in the rules files, because there should be just one place to configure things
<tjaalton> to avoid the fdi mess
<superm1> so if those were identified sooner rather than later, can try to ask AMD to genericize more
<tjaalton> superm1: with the xorg.conf.d thing it would be trivial. just add some options in a file and ship it with the package
<superm1> ah yeah, good point
<tjaalton> like in /usr/lib/xorg/xorg.conf.d
<bryce> heh, would you guys mind putting this into a wiki page or a bug?  I'll never remember all this :-)
<tjaalton> sure (again..)
<bryce> a page under wiki.ubuntu.com/X/Blueprints/ might make sense
<bryce> or a bug report might be easier
<tjaalton> I'll write it down after giving it some thought, and when there's time for it
<tjaalton> the code has not been merged to master yet, so no rush
<tjaalton> but it's something that sysadmins will learn to like
<tjaalton> so fits lucid perfectly
<tjaalton> (if it'll all work out :)
<bryce> tjaalton, thanks
<RAOF> tjaalton: No, we don't need any nouveau patches on top of libdrm 2.4.16
<tjaalton> RAOF: yeah, I noticed that the current version didn't carry any either
<tjaalton> 2.4.16 is waiting in git
<tjaalton> it was rejected from debian for some copyright issues, but that shouldn't stop us from distibuting it I guess :)
<tjaalton> nothing too serious, should just list all copyright holders in there
<superm1> good, libvdpau finally landed in lucid today
<pwnguin> "VDPAU (Video Decode and Presentation API for Unix) is an open source library (libvdpau) and API designed by NVIDIA originally for its GeForce 8 series and later GPU hardware"
<pwnguin> originally? that mean my 6600gt is supported?
<superm1> no, that means Geforce 8 and later
<RAOF> It means that you can use it get at any vdpau implementation, as far as I understand it.
<bjsnider> pwnguin, look up the purevideo wikipedia page and it has a chart of supported chips
<superm1> right, the NVIDIA vdpau implementation only supports geforce 8 and newer.  a third party implementation can support far more likely
<pwnguin> The original PureVideo engine was introduced with the GeForce 6 series.
<pwnguin> quoth wikipedia
<pwnguin> im guessing the one in multiverse is 8 series or higher, being official nvidia and all
<superm1> it shouldnt be in multiverse, it should be in universe
<superm1> the library isn't the implementation, it dlopens the implementation which is in restricted
<bjsnider> yes but the first version didn't do much to help the cause
<bjsnider> the pv 2-4 versions have basically all of the heavy lifting on the gpu
<pwnguin> everything i see is in restricted/multiverse
<RAOF> A 3rd party implementation could be build on top of an essentially-arbitrary 3D engine; I think someone plans to extend the xvmc gallium state tracker to support vdpau (or possibly VA-API or whatever ATI uses).
<superm1> bug 497185
<ubottu> Launchpad bug 497185 in libvdpau "libvdpau should not be in multiverse" [Undecided,New] https://launchpad.net/bugs/497185
<bjsnider> someone aways plans to do stuff
<RAOF> True.  I think this is a somewhat more concrete plan than the space elevator, though.
<pwnguin> well, thank goodness for low hurdles
<RAOF> :)
<pwnguin> i guess this is a sign i need to upgrade
<bjsnider> yes, it takes your cpu down to 5%
<bjsnider> mine has never gotten above 5% no matter the bitrate or frame size of the video
<pwnguin> monitor's dying, system's noisy, and i cant play ridiclusly high res video smoothly
<pwnguin> however, i just dropped this months play money on a phone
<tjaalton> pwnguin: and that was money well spent ;)
<bjsnider> yeah, there aren't enough phones in this world
<tjaalton> I was referring to the brand & model :)
<pwnguin> to relate the phone to Ubuntu X, is there a recomended set of input keys for media remotes?
<bryce> I've rewritten the rethrow_signals patch
<bryce> I think it'll be less bitrotty the way I've redone it
#ubuntu-x 2009-12-16
<Sarvatt> eww, 7 boots in a row getting failsafe, thanks for the hint that fbdev works at least :D
<Sarvatt> xorg metapackage, brltty, ntp, ifupdown, dhcp3-client, mountall, console-setup. something in that round of updates broke startup for me, hmm
<Sarvatt> or xorg-server actually.. http://paste.ubuntu.com/342254/
<Sarvatt> anyone else come in here this afternoon saying x wouldnt start? :)
<JanC> Sarvatt: I think I saw bryce & others talking about something like that
<JanC> where "like that" == people getting failsafe X
<JanC> it was something related to dkms IIRC
<geser> Hello, I've installed lucid alpha on my new Dell mini 10v and the touchpad is driving me crazy. Drag&Drop is nearly impossible to do as the cursor jumps into the upper right corner as soon as I try to do it.
<geser> is this a known problem? and are any workarounds known?
<hyperair> only drag&drop?
<seb128> I've no such issue there
<tseliot> I can't reproduce the problem here
<geser> if I only use one finger it's ok but when I try to do a quick click and use an other finger it jumps too
<tseliot> with the Mini 10v
<tseliot> maybe you're missing the udev rules for synaptics?
<tseliot> tjaalton: I assume that my patch for synaptics is already in Lucid
<tseliot> the one about the jumpy cursor
<tjaalton> tseliot: actually no, it's in git though
<geser> which package are they in? (I used http://cdimages.ubuntu.com/ubuntu-netbook-remix/daily-live/current/ for installation)
<tseliot> geser: then it's because my patch is not in Lucid yet, as tjaalton said
<tseliot> tjaalton: can you upload it, please?
<seb128> I'm getting the issue too using 2 fingers there...
<tjaalton> tseliot: sure
 * tseliot will become core-dev soon (hopefully) and won't have to bug other core-devs (too much) for uploads ;)
<tseliot> thanks
<tseliot> seb128: yes, that's expected, without my patch
<seb128> ok
<tjaalton> tseliot: uploaded
<tseliot> thanks
<virtuald> mew
<geser> tseliot: I've tested the new package and the touchpad works fine now. Big thanks.
<tseliot> geser: good, thank tjaalton for the upload ;)
<geser> tjaalton: thanks for the upload :)
<tjaalton> np :)
<bjsnider> tseliot, for some reason as yet undetermined, the nvidia 195 blob is almost twice the size (70MB) of the 185/190 drivers
<bjsnider> i thought you might find that interesting/puzzling, but maybe i'm wrong
<tseliot> bjsnider: are you referring to the whole package?
<bjsnider> pkg1/pkg2 combined
<tseliot> bjsnider: you should use pkg0/pkg2 instead
<bjsnider> the 64 nvidia package is 39.1 MB. the previous one was 22
<tseliot> bjsnider: maybe they're shipping bigger and/or more libraries?
<tseliot> I'm working on the new packaging scripts for Lucid and I'll start with 190
<bjsnider> i think i'm using the right packages. i've been doing this for awhile. i just can't figure out what the hell they've put into this driver to make it so much bigger
<tseliot> bjsnider: pkg1 has some prebuilt modules which pkg0 doesn't have (for 32 bit)
<tseliot> prebuilt for suse, redhat, etc.
<bjsnider> yeah, pkg1 is also almost twice as big as before
<bjsnider> i mean i know they've been gradually growing, but this is a huge leap in size
<tseliot> ok, thanks for reporting
<bjsnider> tseliot, in the new scripts, is it possible to have most of the version numbers as variables? it is such a pain in the butt when a new driver comes out to change all of the numbers
<bjsnider> like it is in the .in files
<tseliot> bjsnider: yes, the new scripts will be much saner to maintain
<bjsnider> awesome
<tseliot> and to use
<tseliot> :-)
<bjsnider> and you're putting everything into one package, or so i hear
<bjsnider> but debian is going in the opposite direction
<tseliot> right
<tseliot> but I'll talk to the debian maintainers when I'm done. I think we can share at least part of the code with them
<bjsnider> i'd like to backport the changes you're implementing. any idea whent hey might be done?
<bjsnider> or can i help?
<tseliot> backport to what? Karmic?
<bjsnider> indeed
<tseliot> it can turn into an utter mess
<bjsnider> i already implemented the minor changes in mario's ppa
<bjsnider> i'd say the current one is an utter mess
<tseliot> I'll use alternatives instead of diversions in mesa, fglrx and nvidia
<tseliot> yes, the current one is an utter mess (which is part of the problem for a backport)
<bjsnider> well, blob users face those types of issues when switching from packaged versions to nvidia's installer as well. they know what they're getting into.
<tseliot> bjsnider: usually they don't. Furthermore I'm going to prevent problems with the nvidia installer from happening
<tseliot> but if you warn them, then it's ok
<federico1> hmm, no tseliot
<bjsnider> he was here earlier
<bjsnider> the ddos attacks have kicked everybody off from time to time
<federico1> bryce: ping?
<bryce> hi federico1, what's up?
<federico1> bryce: my man
<federico1> bryce: tseliot mentioned that he's interested in the moblin patches to do transformations in the GnomeRR API
<federico1> bryce: but we didn't have a chance to discuss what that would actually be used for
<bryce> mm ok 
<federico1> bryce: do you know anything about that?
<bryce> no, hadn't discussed it with him.
<federico1> in moblin I think we just use transforms to implement cloning by scaling the display, if one of them doesn't support the same resolution
<bryce> my guess is that it's for an OEM project for some hardware
<bryce> there was one question that I heard of where they needed a zoom functionality but couldn't use compiz
<bryce> another question involved supporting multi-head on an i945 chip that was limited to 4k x 4k so they wanted a workaround to allow external monitors to work with large resolutions
<federico1> haven't heard about the zooming one
<federico1> the other one is a *constant* source of pain for us
<federico1> some stupid OEMs can't make up their minds on whether they want 3D or external monitors
<federico1> (not even Windows supports both)
<bryce> I don't know if his question to you was in relation to either of those or something completely different
<federico1> bryce: ok, I'll ping him later
<bryce> yeah we need xinerama back on intel...
<bryce> federico1, hey btw a side question to you
<federico1> bryce: sure
<bryce> one thing we've been doing in ubuntu is modify xserver to re-throw signals, so if X crashes we have a tool (apport) which collects the backtrace and auto-files the bug report
<bryce> I maintain the patch to rejigger the signal handling myself, but have wondered if it would be of any interest outside ubuntu.  do you guys do anything like that for crash handling?
<bryce> the patch is kind of invasive and ugly so I've been afraid to propose it upstream ;-)
<bryce> federico1, an example of the kinds of bug reports we are able to generate with this type of thing -  https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/459402
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/459402)
<federico1> bryce: one sec
<federico1> bryce: interesting but scary :)
<federico1> bryce: do you need any kind of user input?  if the X server is toast, you can't get much input... :)
<bryce> federico1, right, apport stores a .crash file on /var when this happens, then on a later reboot it prompts them, displays the bug filing page, etc.
<bryce> federico1, heh, ok, I think you answered my question :-)
<federico1> ah, okay
<federico1> makes sense
<federico1> hmmmmmmmmm
<federico1> I'm not very sure what we do these days in opensuse about automatic crash reports
<federico1> since bug-buddy got broken beyond all recognition a few years ago, it has been kind of spotty
<federico1> bryce: anyway, I'm documenting all of this here: http://en.opensuse.org/Moblin/RANDR
<bryce> federico1, thanks I'll pass it along to tseliot
<tormod> what's this (vdso) (__kernel_rt_sigreturn+0x0) that I get in Xorg backtraces?
<tormod> http://paste.ubuntu.com/342983/
<bryce> tormod, realtime kernel?
<bryce> tormod, probably a sconklin question (#ubuntu-kernel?)
<tormod> bryce, don't think so: 2.6.32-8.12-generic
<tormod> I noticed that Sarvatt's pastebin earlier had (vdso) (__kernel_sigreturn+0x0)
<bryce> does the v in vdso stand for virtual?
<bryce> rt == run-time
<bryce> tormod, how's your memory situation?
<tormod> probably, but I have no idea why I have "rt". memory is 1GB
<tormod> if you talk about my laptop and not me :)
<bryce> heh
<tormod> but how it was at the time of the crash I don
<bryce> tormod, hmm well looks like kernel was unhappy about something (low memory, bad system call or some such) and raised a signal
<bryce> the call appears to be a fairly standard signal raising routines if google is to be trusted
<bryce> can you repro the problem?  I've got a rewrite of the xserver signal handling patch if you'd like to give that a try?
<tormod> this things happen if I switch from console to X (with radeon, stock lucid)
<tormod> I think I heard about a similar issue on intel before
<bryce> mm, so could be failing to map some memory during the switch
<bryce> if you can repro it easily enough, maybe try gdb'ing it
<bryce> maybe we can get more info that way?
<tormod> ok will try
<tormod> this is on my USB stick install (poor man's SSD), but I don't see it on my HD install which has xorg-edgers
<tormod> ok will try now, guess that means brb
<bryce> tormod, ok xserver with refreshed apport signal handling hook patch is at https://edge.launchpad.net/~bryceharrington/+archive/blue
<bryce> tormod, ok xserver with refreshed apport signal handling hook patch is at https://edge.launchpad.net/~bryceharrington/+archive/blue
<tormod> bryce, thanks, I guess gdb is fine: http://paste.ubuntu.com/343010/
<bryce> interesting, no kernel_rt_sigreturn call this time?
<tormod> nope
<bryce> according to my source, it's crashing on this line?        radeon_cs_space_add_persistent_bo(info->cs, driver_priv->bo, RADEON_GEM_DOMAIN_GTT | RADEON_GEM_DOMAIN_VRAM, 0);
<bryce> mm, could crash if driver_priv == NULL; that looks unchecked
<bryce> or something inside radeon_cs_space_add_persistent_bo(), however I think that symbol would have been in your stack trace if it descended into it
<bryce> hmm this is weird
<bryce> exaGetPixmapDriverPrivate() gets called twice in that routine
<tormod> one with src one with dst
<bryce> mm
<bryce> FUNC_NAME(RADEONPrepareSolid) also has a pair of calls
<bryce> and in the second of those, it does a NULL ptr check
<bryce>         driver_priv = exaGetPixmapDriverPrivate(pPix);
<bryce> 	if (driver_priv)
<bryce>             info->state_2d.dst_bo = driver_priv->bo;
<bryce> makes me wonder if ALL of these calls need such a check
<bryce> tormod, if you have this up in gdb, next thing I'd do is check if indeed driver_priv is NULL before dereferencing driver_priv->bo
<bryce> or alternatively, insert a print statement 
<bryce> like:        if (driver_priv == NULL)
<bryce>             RADEON_FALLBACK(("driver_priv is NULL\n"));
<tormod> no, I have rebooted, and it got totally stuck after I tried to stop X
 * bryce speculates
<bryce> maybe during the console->X switch there is a brief period where the driver privates aren't available for some reason?
<tormod> I think I should first see if I can reproduce on my main install by uninstalling edgers
<tormod> thing is I have no journal on the USB stick, so these crashes can mess up my fs there
<bryce> ouch
<tormod> yeah I can reproduce here on my HD install
<tormod> are we getting a newer libdrm soon? could be that one
<bryce> maybe; lookos like 2.4.15-1 is available in debian, looks like it's waiting on merge?
<tormod> maybe the merge is waiting for 2.4.16 ?
<tjaalton> it's merged, but .16 was rejected from debian
<tjaalton> I'll upload it as -0ubuntu1
<tormod> why was it rejected?
<tjaalton> debian/copyright was missing stuff
<tjaalton> it was stuck in NEW because it added libdrm-radeon1
<tormod> ok, meanwhile I will see if just upgrading libdrm from edgers will help
<bryce> tjaalton, btw the rethrow_signals patch is rewritten to apply now.  I'll upload it once it's tested sufficiently.
<tjaalton> bryce: yeah, sounds good
<bryce> tjaalton, I'm going on vacation after friday through to the end of the year, any things that I should get squared away before I go?
<tjaalton> bryce: close all the bugs?-)
<tjaalton> I don't know if there's anything special right now. maybe we should prepare a new ati snapshot?
<bryce> does -intel need an update too?
<tjaalton> not really. the beta needs kernel changes..
<bryce> ah ok
<tjaalton> or so I'm told
<tjaalton> because of the pageflip stuff
<bryce> ok then I'll do an -ati update
<bryce> and hammer on bugs with what time remains
<tjaalton> note that I didn't say "fix the bugs", closing is sufficient :)
 * bryce lols
<bryce> ok I have a script for that ;-)
<tjaalton> hehehe
<bryce> actually speaking of which I promised to set up some of my automatic bug scripts for others on the desktop team, including the close bugs one
<tjaalton> yeah, they will benefit from them
<tjaalton> jbarnes: hey, do you know if kernel support for the intel Q4 release will be backported to .32.x or will it require .33?
<tormod> no, libdrm update did not help, guess next to try is DDX
<tjaalton> bryce: heh, the "current" nvidia source package name on debian is just "nvidia-graphics-drivers"
<tjaalton> so at least they don't seem to care if the upgrade goes boom
<bryce> heh
<tjaalton> (the nvidia maintainers)
<tjaalton> and the legacy packages are "nvidia-graphics-legacy-173" etc (binary nvidia-glx-legacy-173 etc)
<bryce> any relation between debian's packages and ours?
<bryce> i.e. should we be considering changing in ubuntu to better match what debian does?
<tjaalton> some, I haven't checked how much they have diverged since
<tjaalton> well, it's something to consider, even if we won't actively merge from them
<jbarnes> tjaalton: q4 should be ok with 2.6.32
<tjaalton> jbarnes: cool, thanks
<bryce> tjaalton, ok if you see tseliot, you might mention the idea to him
<tjaalton> bryce: I will
<tormod> building radeon DDX from git solved the issue. no time for bisecting now. I don't think anything has changed in the radeon_exa_funcs.c stuff we looked at
<bryce> tormod, ok, well I'll up us to a newer snapshot later this week.  got a favorite snapshot id I should use?
<tjaalton> libdrm uploaded
<tjaalton> oh wait
<tjaalton> Connection failed, aborting. Check your network [Errno 111] Connection refused
<tormod> bryce, HEAD is my favorite :)
<tjaalton> whattaheck
<tormod> lp is down for service
<tjaalton> gah
<Sarvatt> pheeew, might get another day of stability then because that libdrm update is going to ruin it :D
<tjaalton> oh right, source v3 rollout and that
<tjaalton> Sarvatt: why?
<Sarvatt> i'm lucky to last an hour without crashing with 2.4.16
<Sarvatt> just crashed there with only 2.4.16 libdrm different than lucid, same problems i'm getting with edgers
<tjaalton> which driver?
<Sarvatt> intel 2.9.1 through git master
<Sarvatt> [ 3389.832500] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error.
<Sarvatt> [ 3389.836934] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error.Fatal server error:
<Sarvatt> Failed to map batchbuffer: Input/output error
<tjaalton> ok then.. jbarnes ^^
<tjaalton> if the new intel builds, maybe time to update that as well
<jbarnes> sounds like a gpu rese4t
<jbarnes> reset
<tjaalton> that's with just a new libdrm
<Sarvatt> if i downgrade libdrm to 11-25 like Duke` also has to do it doesn't happen
<tjaalton> I'll try it myself before uploading
<Sarvatt> try like, loading a folder in icon view with alot of video thumbnails, that almost always seems to trigger it
<Sarvatt> message is a little different when it crashes after suspend/resume
<Sarvatt> [264301.566382] (WW) intel(0): i830_uxa_pixmap_swap_bo_with_image: bo map failed
<Sarvatt> [264301.566535] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
<Sarvatt> [264301.566658] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
<Sarvatt> [264301.566777] (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error
<Sarvatt> then hundreds of those failed to submit batch buffer messages
<bryce> hrm
<Sarvatt> freezes to a solid color when those happen
<bryce> what do you guys think of holding off on doing the update until this is sorted?
<tjaalton> well, if 2.9.99.902 builds, we could update that as well
<bryce> if -intel is looking like it might be getting unstable again, I'd prefer holding off on updating. 
<Sarvatt> that needs the headers from libdrm installed because our linux-libc-dev doesnt have the pageflip ioctls
<tjaalton> that would likely mean the same for nouveau and ati
<tjaalton> Sarvatt: jbarnes said it wouldn't
<tjaalton> well
<tjaalton> not exactly true, I didn't say we use the kernel headers, not libdrm
<Sarvatt> http://lists.freedesktop.org/archives/intel-gfx/2009-December/005166.html
<Sarvatt> get those errors unless you have the headers from libdrm or 2.6.33
<Sarvatt> ah i'll check the irclogs
<tjaalton> then the kernel needs those commits. simple as that
<tjaalton> bryce: I meant that nouveau/ati probably depend on .16 as well
<bryce> I'm just fearful of if we put in known-bad stuff expecting the fixes will arrive in time for release... they might not
<Sarvatt> there was a thread about it on dri-devel last month where they talked about how people should be using libdrm's headers instead of the installed kernel ones because they use getparam things to enable runtime detection of features and they dont want all the ifdef trickery on top of that
<bryce> (as has burned us before...)
<Sarvatt> could just revert this commit from 2.9.99.902 to get it to work though http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906
<tjaalton> I'm just saying.. no need to upload broken stuff
<bryce> Sarvatt, you can verify this resolves the issue for you?
<Sarvatt> doesnt resolve any issue outside of letting it compile :D
<bryce> tjaalton, also I can raise the issues as blockers to Intel if we have bug reports on them
<Sarvatt> intel has been more broken than it ever was for me in jaunty since 11-06
<bryce> Sarvatt, :-/
<bryce> ok
<bryce> well, first I've been told (by jbarnes and others) that libdrm policy is "regression-free"
<bryce> so if we've found regressions in libdrm with -intel, flag those for me and I'll get them raised with Intel ASAP
<bryce> we can focus on at least getting libdrm in and stable, so the nouveau and ati work can continue unimpeded
<bryce> we can hold off on updating -intel until we have confidence that it's rock solid
<bryce> if Sarvatt's findings are right and it's a pile of breakage at the moment, well I'd rather not update intel until we're absolutely confident about it
<bryce> otherwise we'll be swimming in more bug reports :-)
<tormod> Sarvatt, maybe we should add a reinstall of linux-libc-dev in ppa-purge... I got burnt now :)
<tormod> bryce, he talked about libdrm not intel, right?
<bryce> tormod, here's the exact quite from Yingying @ Intel:
<tormod> bryce, if libdrm is held back, the latest ati commit that builds is 0061c4db
<bryce> > For libdrm, we'd suggest Lucid pick up the latest libdrm. We've got
<bryce> > some performance fixes in there, and some useful correctness fixes.
<bryce> > Libdrm has a no-regressions policy which we've been good at, so this
<bryce> > shouldn't be a problem. For -intel driver, the right version is going
<bryce> > to be 2.10 (Intel Q4 version) which will provide KMS-based overlay
<bryce> > support. If Ubuntu wants to support pre-915 chips and KMS, that seems
<bryce> > like a requirement.
<tormod> bryce, I am sure we will get there eventually :)
<bryce> tormod, think I should update to that commit or just hold off until the libdrm stuff is in place?  is there testing value in moving to that snapshot?
<tormod> bryce, it will fix the console switching breakage
<bryce> ok
<bryce> then I'll work on getting that snapshot in
<tormod> well let me test it once more :)
<bryce> meanwhile, if anyone has specific bugs narrowed to the libdrm update, make sure they're in LP and subscribe me to them and I'll ensure they get upstream priority on them
<tormod>  bryce, yes that works: I reverted to old libdrm, built the above ati commit, and it fixed the issue
<Sarvatt> was going to say that commit went into the stable branch too so it should work
<Sarvatt> tormod: thats nasty, guess ppa-purge should check for all provides: and install those too huh..
<Sarvatt> err Replaces:
<tjaalton> looks like having a stable radeon kms needs a lot from .33
<tormod> Sarvatt, ideally, but can get a bit ugly to detect all that, maybe we should just track our Replaces
<tjaalton> by reading a thread from last month
<Sarvatt> will do bryce, i havent filed any bugs on lp because its been edgers packages and i've seen all my issues on fdo bugzilla already
<Sarvatt> note to self: dont use jordan.freenode.net :D
<tormod> Sarvatt, it's netsplit all over I think
<Sarvatt> tjaalton: this was the thread I was talking about, sorry http://marc.info/?l=dri-devel&m=125770698907397&w=2
<tjaalton> Sarvatt: yes I read most of it
<tjaalton> so could be that we'll be shipping them from libdrm, again
<tjaalton> Granted this means the F12 kernel has now got 
<tjaalton> a bunch of patches that should be in 2.6.32 but will have to wait for 
<tjaalton> 2.6.33, distros thinking of packaging radeon kms do take note.
<tjaalton> that's what I said about earlier (if you got that)
<tjaalton> so I think the kernel team will have to pull a lot of drm updates from .33
<bjsnider> then why not just use the .33 kernel at large?
#ubuntu-x 2009-12-17
<Sarvatt> oh yeah tjaalton, you have a 965 dont you? i think yours can recover from those errors that hang me if so
<RAOF> Whose got an nv50+ class card and would like to try nouveau?
<Sarvatt> installing it now
<Sarvatt> well 300mb of other updates to grab too
<Sarvatt> should nouveau-kernel-source recommend the ddx or anything?
<Sarvatt> hmm the kernel's not even trying to load nouveau
<Sarvatt> FATAL: Module nouveau not found.
<RAOF> Sarvatt: Actually, the kernel module sholud be useful even without the DDX; it *should* provide working suspend/resume.
<RAOF> Sarvatt: Pulling from xorg-edgers into lucid?
<Sarvatt> yeah i have edgers on that laptop
<Sarvatt> got the 1217 one
<RAOF> Hm.
<RAOF> Works nicely on _this_ laptop.
<RAOF> You've got a nv5x class chip?
<Sarvatt> no modules in /lib/modules/2.6.32-8-generic/updates/dkms
<Sarvatt> 8400M GS
<RAOF> Ok, that's weird.
<RAOF> Yay!  Tester for firmware loading.
<Sarvatt> NV86
<RAOF> So, I know that 1217 builds happily against 2.6.32-8-generic, because it's done so here.  What's your make.log say?
<Sarvatt> weird, looks like it built it for 2.6.32-7
<RAOF> Is that your running kernel?
<Sarvatt> 2.6.32-8 was i was sure, on -8 now though
<Sarvatt> whats the command to build it again?
<Sarvatt> nouveau, 0.0.15+git20091217, 2.6.32-7-generic, x86_64: installed 
<Sarvatt> guess i installed -8 then installed nouveau-kernel-source before rebooting..
<RAOF> Oh, right.
<RAOF> Yes!  And dkms is no longer run on boot, and I haven't changed the postinst to build for all available kernels.
<RAOF> dkms build -k 2.6.32-8-generic -m nouveau -v 0.0.15+git20091217
<Sarvatt> thats pretty nasty because it seems like what most people installing a new release > a week after release is going to be doing for nvidia or fglrx or nouveau
<Sarvatt> guess i should have sudo-ed that, tons of no permission to delete errors
<RAOF> As I understand it, it's now the responsibility of nouveau-kernel-source to build against all installed kernels when it gets installed/updated, and after that dkms will get triggered on kernel install.
<RAOF> Yeah, you should've ;)
<bryce> yeah that should eliminate a whole class of bugs
<RAOF> Where the module isn't available at boot & X starts up too fast? :)
<Sarvatt> hmm looks like it installed to 2.6.32-7 again...
<RAOF> Also, makes sense for nouveau, 'cause it'd quite like to be in the initramfs.
<RAOF> Sarvatt: You _may_ need to run that command again with "install" rather than "build".
<Sarvatt> oh thanks
<Sarvatt> there we go, rebooting again
<Sarvatt> i'm doing it without nouveau.modeset=1 and quiet splash added just to see if it works right
<Sarvatt> couldnt start without quiet removed before
<Sarvatt> looks like i cant now still
<Sarvatt> new spam in dmesg every 10 ns :D
<Sarvatt> gdm greeter garbled
<Sarvatt> Kernel command line: BOOT_IMAGE=//vmlinuz-2.6.32-8-generic root=UUID=7f0c72b4-6c48-4ef9-9bfd-46a724d96bc5 ro
<Sarvatt> that worked, had to remove quiet splash still.. wish i knew why
<Sarvatt> x is on :1 it looks like though
<Sarvatt> works fine though, dont see any difference from the 12-04 package http://sarvatt.com/downloads/nouveau.txt
<RAOF> You won't need nouveau.modeset=1; kms is enabled by default.
<RAOF> Hm.  nouveau is getting loaded suspiciously late in your boot sequence... is /etc/initramfs-tools/hooks/nouveau_kms_hook executable?
<Sarvatt> i just ran a manual update-initramfs -u to try to put it in and got a bunch of errors putting the firmware in
<RAOF> Hm.
<Sarvatt> http://paste.ubuntu.com/343234/
<Sarvatt> ignore the last error, the latest initramfs-tools is making it give that for all kernels
<RAOF> Also, it's not loading the firmware; I'm therefore surprised that it "works fine", because you've got no acceleration :)
<Sarvatt> oh its not loading the ihex-ed firmwares in the initramfs hooks?
<RAOF> Hm.  I thought it should be, but I don't have an nv5x class card to test on, and they've already included a nv4x voodoo generator in the drm.
<Sarvatt> nouveau_kms_hook is executable
<Sarvatt> the firmwares all have .ihex extentions in /lib/firmware/nouveau/ here
<RAOF> Hm, true.  Nothing else seems to...
<Sarvatt> I dont notice any difference without acceleration to be honest :D
<RAOF> Well, I would, because I've got compiz ;P
<RAOF> I might need to actually build the firmware in some way...
<Sarvatt> i think you can use ctxfw=1 to make it load the firmware for your card?
<Sarvatt> parm:           ctxfw:Use external firmware blob for grctx init (NV40) (int)
<RAOF> Yeah.  I'd need to grab the firmware though, too.
<Sarvatt> is just adding nouveau to the initrd enough? will it pick up ttm and the others automatically?
<RAOF> Yes, it should.
<RAOF> Indeed, it does; the hooks pick up the transitive dependencies of a kernel module.
<RAOF> It might not pick up the firmware, though.  Let me check...
<Sarvatt> can ya just ship the extracted firmware with it? looks like they just ihexed it so it wouldnt ship binaries that get cleaned when you make clean the kernel
<RAOF> I don't have the extracted firmware :).  I guess I need to work to build the ihex into usable firmware; it can't be that hard.
<Sarvatt> can ya add a make firmware_install job to it somewhere?
<RAOF> That would be the plan, yes.
<RAOF> Gah.  You need a whole host of stuff to make firmware_install work.
<RAOF> Phargh.  Where did debian/tmp go?
<tjaalton> Sarvatt: yep
<tjaalton> tseliot: hey, have you started working on the new nvidia packages?
<tseliot> tjaalton: yep
<tjaalton> tseliot: was there a consensus on the renaming business?
<tjaalton> or will you use the ones we have now until it's decided
<tseliot> tjaalton: I think we agreed to use nvidia-current and nvidia-173 and nvidia-96
<tjaalton> well I was dropped off because of the ddos ;)
<tjaalton> so didn't get to say anything
<tseliot> oh
<tseliot> what's your take on this?
<tseliot> pitti let bryce and I decide
<tjaalton> I talked to bryce last night and he advised to contact you :)
<tseliot> ok, if you have any objections to the new names just let me know
<tjaalton> are those for the source packages?
<tseliot> no, just for the binaries
<tjaalton> so what's the "current" source package going to be?
<tseliot> nvidia-graphics-driver-current?
<tseliot> better ideas are always welcome
<tjaalton> what about dropping the current part? does it serve a purpose?
<tseliot> not in the source
<tjaalton> I (again, after 2y) looked at how debian did them..
<tjaalton> the latest is n-g-d, produces nvidia-glx, and ton of other binaries
<tseliot> so would it be nvidia-graphics-driver, nvidia-graphics-driver-173 and nvidia-graphics-driver-96?
<tseliot> it will generate only 3 binaries
<tjaalton> legacy ones are n-g-d-legacy-96xx etc, produce n-glx-legacy-96xx etc
<tseliot> -current, -current-dev, -current-modaliases
<tjaalton> yeah it's fine to ship the binaries in one package
<tseliot> they were a bit against "-legacy" for binaries but maybe it's ok for sources
<tjaalton> we don't have to change the legacy ones, they are fine as they are
<tjaalton> n-g-d-173 etc
<tjaalton> source and binary
<tjaalton> oh wait
<tjaalton> n-g-173 binary
<tjaalton> uh
<tseliot> ;)
<tjaalton> can't be -glx if it ships more than just the lib
<tjaalton> (what a mess..)
<tjaalton> :)
<tseliot> maybe we can talk again about this when I'm back. I have to go now
<tjaalton> sure
<tjaalton> bryce: please use UNRELEASED if you won't upload right away. xorg-server now shows "karmic" as the release :)
<tjaalton> tseliot: I think that calling the merged blob 'nvidia-glx' makes sense, since it's been like that forever
<tseliot> tjaalton: but that can be confusing as it's not just glx and users will start asking where the kernel source is
<tjaalton> and shipping the vdpau support in the same package doesn't mean much. even the free drivers will likely ship it with the rest of the driver
<tjaalton> they don't need to know?
<tjaalton> since it's installed already
<tseliot> well, nvidia-glx-$VER is installed
<tjaalton> Provides: nvidia-kernel-source
<tseliot> yes, of course
<tjaalton> but what other package needs it? why would someone need to find it?
<tjaalton> so the binary will still have a version number?
<tseliot> no other package needs it
<tseliot> no, only legacy drivers will have a version number
<tjaalton> ok
<tseliot> -current will always be just -current
<tjaalton> debian doesn't have one either (even the binary, so they don't care about upgrades breaking)
<tjaalton> +potentially
<tseliot> nvidia-common will deal with upgrades in our case
<tjaalton> not with apt-get
<tjaalton> not everyone uses update-manager
<tseliot> I know but
<tseliot> 1) we support dist-upgrades only through update-manager
<tjaalton> let launchpad know that as well ;)
<tseliot> 2) nvidia-common will complain through debconf and let users know what to install
 * tseliot didn't choose 1)
<tjaalton> who said that?
<tseliot> either mvo_ or pitti
<tjaalton> ok
<tseliot> I *guess*
<tjaalton> well, I don't think it's a huge issue
<tseliot> right
<tseliot> if users choose apt-get they will know what to do when they see 2)
<tseliot> so, shall we use nvidia-graphics-driver, nvidia-graphics-driver-173, nvidia-graphics-driver-96 or nvidia-graphics-driver-current, nvidia-graphics-driver-173 and nvidia-graphics-driver-96?
<tjaalton> the former, imo
<tseliot> I have no strong opinions on this
<tseliot> ok then
<tjaalton> can't describe why I don't like "current" :)
<tseliot> they use it in Mandriva and it seems to work well
<tjaalton> it just doesn't feel right
<tseliot> it could be "latest" but that wouldn't be entirely correct either
<tjaalton> makes the name longer, that's for sure :)
<tseliot> true
<tseliot> I don't think it really matters if we use another name, as long as we have the latest driver (i.e. the one which NVIDIA consider as non-legacy) in the same source package+
<tseliot> s/+//
<tjaalton> debian has just n-g-d, and though it'll likely never be merged, I guess it makes sense to keep the same name here as well
<tseliot> yes, for the source
<tseliot> it makes sense
<tjaalton> ok that one is clear then :)
<tjaalton> well, I don't care about the binary that much to fight against -current, if that's already been ok'd
<tseliot> yes
<tseliot> ok, it sounds like we got to an agreement and/or a compromise ;)
<tjaalton> something along those lines yeah
<tjaalton> now get crackin' :)
<tseliot> right
<tjaalton> I was thinking that maybe the packaging could be in bzr or so, apart from the binaries
<tseliot> I was about to ask you about it
<tseliot> yes, maybe it's better if we use a bzr branch as ubuntu packages use bzr
<tseliot> well, most of them
<tjaalton> I don't know how the tools work with giant binaries.. for instance if I replace one with another, will the diff be a huge binary blob or what
<tseliot> good question. I think you would get a readable diff and a binary blob using the web bzr interface. I don't remember how it works in practice
<tseliot> maybe keeping only the packaging in bzr is a better idea
<tjaalton> but one possibility would be to not have the binaries in bzr, but I don't know if that's possible
<tjaalton> like, it auto-imports every upload AIUI
<tjaalton> otherwise it would just mean copying the binaries from the source package to the tree, and debuild -S  etc
<tseliot> example: the diff for this is 77.8 Mb :-/  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/nvidia-graphics-drivers-180/karmic/revision/21
<tseliot> ouch
<tseliot> does git work any better with binaries?
<tjaalton> ugh
<tjaalton> I don't know
<james_w> hi tseliot 
<spork> Hi all.  I'd like to get Xorg 1.7 on Karmic, with nVidia drivers.  Is this possible?
<tjaalton> spork: no
<tjaalton> spork: meaning that there are no packages for it
<spork> (reason being that I need 1.7 for the multi-card support that dropped in 1.5, and GTX260 support which 1.4 doesn't have)
<spork> so it's build from source, or suffer?
<spork> possibly those are the same thing  ;)
<tjaalton> you mean nvidia binary driver?
<spork> yeah
<tseliot> hi james_w
<spork> Well...  I want dual-head from one of the cards - last time I checked nv driver couldn't do that?
<tseliot> james_w: tjaalton and I were wondering how bzr would work to maintain nvidia drivers in a branch
<tjaalton> spork: no, but nvidia has twinview
<tjaalton> and that works just fine with 1.5
<spork> right, but that doesn't work for two cards
<tseliot> james_w: as nvidia drivers contain the packaging scripts and some big binary blobs
<spork> so I can't run the third screen
<tjaalton> spork: how does 1.7 change it?
<spork> reintroduced support for multiple cards
<spork> libpciaccess broken it at 1.4->1.5, but apparently they fixed it recently
<tseliot> james_w: the problem is that when we include a new upstream release we get a diff which can be as big as 71 Mb (or more) because of the binaries
<tjaalton> spork: nvidia doesn't use that
<spork> ...well 1.4 worked, 1.5 didn't.  Everything I've read said that libpciaccess was the reason, but I'm willing to learn different.
<tjaalton> spork: if you mean vgaarb, it's for free drivers AIUI
 * spork is looking for the xorg bug
 * tseliot -> brb
<spork> http://lists.freedesktop.org/archives/xorg/2009-April/045379.html is some discussion about it
<spork> they mention a vga arbiter (as something that didn't exist at that point, I think)
<spork> ah, here's the bug: https://bugs.freedesktop.org/show_bug.cgi?id=20816
<ubottu> Freedesktop bug 20816 in Server/general "Make multi-card xorg work again" [Normal,New]
<tjaalton> yes, but I don't think that applies to nvidia. the vga-arb touches the kernel drm level too, and nvidia doesn't use that at all
<tjaalton> it should be possible to use a combination of xinerama+twinview
<tjaalton> dunno
<spork> it was, at 1.4
<spork> although it made more sense to use xinerama across all 3
<spork> some odd behaviour with full-screening applications otherwise
<tjaalton> try it on lucid alpha1
<spork> yeah, I was considering that.  I hear Lucid is a bit wobbly still?
<spork> tempting though
<tjaalton> that's why there are livecd's
<tjaalton> for testing
<spork> this 9.10 install is fresh anyway
<spork> I may as well upgrade it and see if the explosions are pretty or not
<tjaalton> first of all, there is no working nvidia blob yet
<tjaalton> packaged
<tjaalton> and since you need that, the livecd won't work either
<spork> ah
<spork> well, I could still test to see if both cards come up
<spork> I'll just have dual head on different monitors  :)
<spork> centre and right instead of centre and left
<spork> I thought I'd seen someone running 1.7+nvidia on a Arch Linux forum
 * spork googles again
<spork> * nvidia 190.42 supports xorg 1.7 if you have a nvdia card gf6 or up
<tjaalton> there's some ppa where it's packaged
<spork> right
 * tseliot -> lunch
<virtuald> now that radeon kms is default, are someone working on power management?
<tjaalton> upstram
<tjaalton> +e
<virtuald> 8]
<james_w> tseliot: it should work fine
<james_w> tseliot: it may not be terribly efficient, but shouldn't be too bad
<virtuald> my x comes up on like every other boot
<tseliot> james_w: ok, thanks
#ubuntu-x 2009-12-18
<ara> tseliot, hi!
<tseliot> ara: hi
<ara> tseliot, are the nvidia drivers now available?
<tseliot> ara: I'm still working on it. As you can see, the blueprint involves some work: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers
<tseliot> mainly https://wiki.ubuntu.com/X/ProprietaryDrivers/IntegrationImprovements
<ara> tseliot, thanks! I'll subscribe to the blueprint :)
<tseliot> ara: good idea. I'll do my best to complete it ASAP
<tjaalton> tseliot: err, are you going to use alternatives instead of diversions?
<tseliot> tjaalton: yep
<tjaalton> ugh
<tjaalton> I thought pitti said it's even more fragile than using diversions
<tseliot> installing fglrx, nvidia (all versions) won't cause a mess
<tjaalton> yes it will
<tjaalton> which one gets the top priority?
<tseliot> I thought that he was against this change but then he told me that he agreed
<tseliot> define a use-case and I'll answer to your priority question
<tjaalton> installing both fglrx and nvidia, I thought that was the driving factor to get this done?
<tseliot> yes, that too
<tjaalton> and what if you have legacy nvidia drivers
<tseliot> same thing
<tseliot> all libraries live in the directory of the driver they belong to
<tjaalton> but which one is used?
<tjaalton> the driver doesn't know
<tseliot> whatever you choose
<tjaalton> so the user needs to choose.. that will end in tears :)
<tseliot> with update-alternatives --set
<tseliot> you = Jockey
<tseliot> it works great in Mandriva
<tjaalton> so how does jockey choose which one to use?
<tseliot> you can activate a driver in Jockey, right?
<tjaalton> yes?
<tseliot> one click on the driver that you want to use, reboot and it will work
<tseliot> maybe I'm missing the point of your question
<tjaalton> well, as long as fglrx doesn't support 1.7 this is pretty academic
<tseliot> you can have mesa, nvidia current, nvidia 173, nvidia 96 and fglrx installed at the same time
<tjaalton> so the use case where you have to choose between fglrx and nvidia will diminish
<tseliot> and you can select what you want to use with Jockey
<tseliot> fglrx will arrive in time
<tseliot> for Lucid
<tjaalton> I hope not :)
<tjaalton> so we can get rid of it :)
<Ng> we're getting rid of all our ati users? ;)
<tjaalton> (fat chance)
<tseliot> in the future it should become a fall back as we will prefer -ati
<tjaalton> Ng: check the phoronix survey results, most of the ati users use free drivers
<tjaalton> and now we have r600_dri
<Ng> tjaalton: most phoronix survey takers with ati hardware? ;)
<tjaalton> not perfect, but good enough for most
<tjaalton> Ng: exactly :)
<tseliot> but if you need a specific feature which only the proprietary driver supports (don't ask me what) you should still be able to switch to it
<Ng> (I honestly have no familiarity with what ati fail is supported by which drivers, I'm just being facetious)
<tjaalton> tseliot: ok. maybe the plan has been reworked further, so my concerns are obsolete.. hope so
<tjaalton> at least this will get rid of all the upgrade bug
<tjaalton> +s
<tseliot> tjaalton: yes, don't worry, I would never put in an Ubuntu release something that doesn't convince me
<tjaalton> tseliot: also, we are getting close to the point where it doesn't make sense for jockey to push users to use fglrx
<tjaalton> I've no first hand experience how well fglrx works nowadays, but a friend of mine seems to have issues and is waiting for lucid..
<tjaalton> and the new free stack
<tseliot> tjaalton: yes, maybe we can make Jockey mark the open driver as recommended
<tseliot> so that users will know that they can keep the open driver
<tseliot> especially users coming from Windows
<tjaalton> I guess we can drop the (unused) nvidia/fglrx patches from the server, since they could only break things
<tjaalton> and since the driver will be hardcoded to xorg.conf like before
<tseliot> tjaalton: what was the problem with those patches again?
 * tseliot doesn't remember
<tjaalton> tseliot: the autoconfig only works if there is no xorg.conf
<tseliot> aah, right
<tjaalton> othewise there's no fallback
<tjaalton> it would just check the top driver
<tjaalton> and since I'm proposing to pull the xorg.conf.d patches from upstream, there would practically always be an xorg.conf
<tseliot> I haven't looked at those patches but if you can keep them there for a while I will see if I can fix that
<tjaalton> shipped by some driver, for instance
<tseliot> aah
<tjaalton> it's not the patches, you'd need to rework the whole logic
<tseliot> yes, of course
<tjaalton> but yes, that would be cool
<tseliot> I haven't had the time to see how the xorg.conf.d stuff works
<tjaalton> mentioned to bryce too
<tjaalton> then it would be possible to have for instance the synaptics quirks in a synaptics.conf
<tjaalton> and not mess with udev rules
<tseliot> that would be great
<tjaalton> the backend probably will drop support for that anyway
<tjaalton> no need to relive the fdi hell
<tjaalton> dan sent the latest versions to the list this week
<tjaalton> xorg-devel@, when you have time :)
<tjaalton> I'll probably test them during the holidays
<tjaalton> and xf86-input-wacom too, should first buy an intuos4 though
<sconklin> bryce, tseliot: did you do any testing of kernel performance differences with the moblin patches I put in the test kernel (a couple of weeks ago now)
<tseliot> sconklin: I didn't but Keybuk did
<sconklin> tseliot: thanks, I'll bug him over in #kernel
<tseliot> np
<Duke`> omg two freezes in 5 minutes (i945, GEM, KMS, kernel 2.6.32)
<Duke`> Sarvatt, I still got those freezes with i945 :(
<Sarvatt> ya mean with updated libdrm? there hasnt been any changes that'd fix it if so
<Duke`> yes
<Sarvatt> i'm using stock lucid for now, that'll work at least until 2.4.16 gets uploaded to lucid then we're gonna have to figure out something else to get around it :D
<Duke`> I note that it often happens when quickly scrolling up and down on a particular website
<Sarvatt> maybe make another PPA with an 11-25 libdrm versioned higher
<Duke`> for example: http://www.pcinpact.com/actu/news/54628-jacques-myard-nationalisation-loi-internet.htm?vc=1&p=3#vc
<Sarvatt> yeah
<Sarvatt> same deal here, that or scrolling in a folder with hundreds of video thumbnails
<Duke`> it froze two times in 5 mins just 10 mins ago
<Sarvatt> wont be able to build ati or intel against the 11-25 libdrm even though it has the features it needs from 2.4.16 :(
<Sarvatt> the Add drmGetDeviceNameFromFd function commit
<Sarvatt> i'm hoping http://lists.freedesktop.org/archives/intel-gfx/2009-December/005221.html makes it into stable too, that seems to fix my flashing and hanging after suspend/resume too
<Sarvatt> with 2.6.33-rc1 i still get the freezing on a solid color after resume most of the time but the blinking is gone, and havent frozen with that patch applied yet. on 2.6.32 I get flashing every 90 seconds or so after resume. some people like jcristau are getting the post resume problem I get on first boot, that would be nasty
<Sarvatt> http://bugzilla.kernel.org/show_bug.cgi?id=14781 https://bugs.freedesktop.org/show_bug.cgi?id=25371
<ubottu> bugzilla.kernel.org bug 14781 in Video(DRI - Intel) "181a533 is causing severe screen flickering on 965GM" [High,New]
<Duke`> I haven't experienced those, but I never use suspend to ram (my hardware is broken)
<Sarvatt> really tempted to buy an ssd for this netbook to not have to use suspend because its so often broken :) just looking at the bootchart of the nc10 on phoronix and it looks like the desktop is up and ready to use in 23 seconds
<Sarvatt> its a little over a minute here on this acer aspire one
<Sarvatt> i usually use this thing as an ebook/manga reader when i'm out all day, got lots of 10-15 minute gaps of time to turn it on and off
<Sarvatt> oh boy, abi break in xserver master about to hit that'll break the nvidia blob i think
<tjaalton> Sarvatt: the config change?
<Sarvatt> nah [PATCH 3/3] Add type name argument to CreateNewResourceType
<tjaalton> oh that
<Sarvatt> in the [PATCH 0/2] Patches to ensure all ResourceTypes are named thread the nvidia guy said the blob uses it still when they were talking about how no drivers would be affected by the abi change
<tjaalton> the reply was rather terse
<tjaalton> ..meaning that he probably wasn't happy with it :)
<bryce_> configure.ac:33: error: must install xorg-macros 1.3 or later before running autoconf/autogen
<Sarvatt> everything needs xorg-macros xutils-dev 7.5 now upstream
<Sarvatt> err xutils-dev I meant, xorg-macros being a part of that :D
<Sarvatt> they went through and made all x components need it last month though, guessing yer trying to build a newer ddx on karmic?
<Sarvatt> r600 : enable gl2, set R600_ENABLE_GLSL_TEST by default.
<Sarvatt> woohoo dont need to manually change the define for r600 people anymore
<bryce_> ah right, thanks Sarvatt
<bryce_> yep, working on a new -ati snapshot
<bryce_> guess needs done in a chroot
<ripps> Is it going to be possible to port my custom_wacom.fdi to the new xorg.conf.d configs?
<Sarvatt> is lucid shooting for mesa 7.7 or 7.8? wondering for r600/nouveau users, probably not much point trying to do nouveau gallium on 7.7
<Sarvatt> i'll try that later tonight and see how it goes, i get over 100 fps at 1280x800 on my 8400M GS laptop with 7.8 gallium
<Sarvatt> plenty usable
<RAOF> 100fps at what?
<Sarvatt> openarena
<Sarvatt> oops thought i said that
<RAOF> Yeah.  I think nouveau might be losing the "please don't ship 3D, it doesn't work" argument.
<RAOF> It made more sense when it didn't drive compiz on nv40+
<Sarvatt> compiz does freeze on my 8400 though when i start it :(
<Sarvatt> looks like a gpu hang
<RAOF> Heh.
<Sarvatt> you start it any special way? any environment variables or anything?
<RAOF> export LD_LIBRARY_PATH; export LIBGL_DRIVERS_PATH; compiz --replace
<RAOF> Apparently you _don't_ want to install it where X can find it; AIGLX apparently doesn't work as well.
<Sarvatt> same as me
<Sarvatt> didnt know if you used like LIBGL_ALWAYS_INDIRECT or anything
<RAOF> No, nothing fancy.
<Sarvatt> i'm still using a build from 11-30, maybe it got fixed after
<RAOF> mesa, X, drm or DDX? :)
<Sarvatt> mesa, rest is fresh from git
<Sarvatt> i haven't tried since updating nouveau though, had any luck with the firmware thing?
<Sarvatt> i dont think its likely to change, could just grab the binaries out of git from before they changed them to ihexed ones and ship those seperate maybe?
<Sarvatt> i saw some other dkms packages doing a make firmware and make firmware_install to ship the firmware, a v4l2 package on mandriva i think it was
<RAOF> Actually, I think what I'll end up doing is uploading a nouveau-firmware package from their firmware tarball.
<RAOF> Sarvatt: Want to give unpacking http://people.freedesktop.org/~pq/nouveau-drm/nouveau-firmware-20091212.tar.gz in /lib/firmware a try?
<Sarvatt> doing it now
<Sarvatt> i'm not at home with the machine so i'll only have logs to go by :D
<Sarvatt> oh i already used ihex2fw on those ihex-ed ones
<Sarvatt> i'll try that tar though just incase
<Sarvatt> rebooting now
<Sarvatt> loaded the firmware fine in dmesg but no accel in xorg.0.log
<Sarvatt> [    2.068644] nouveau 0000:05:00.0: firmware: requesting nouveau/nv86.ctxprog
<Sarvatt> oops think i have to update-initramfs
<Sarvatt> [    0.595218] (EE) NOUVEAU(0): Error creating GPU channel: -19
<Sarvatt> [    0.595232] (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
<Sarvatt> 200mb of updates to grab again then i'll reboot again
<Sarvatt> same deal, NoAccel
<Sarvatt> DISPLAY=:0 LD_LIBRARY_PATH="/home/sarvatt/source/mesa/lib/" LIBGL_DRIVERS_PATH="/home/sarvatt/source/mesa/lib/gallium/" glxinfo is giving me swrast
#ubuntu-x 2009-12-19
<Sarvatt> oh hmm the nouveau module didnt even get loaded that boot after rebuilding the initrd
<Sarvatt> lost the module -- ERROR: modinfo: could not find module nouveau
<Sarvatt> Warning! Cannot do version sanity checking because multiple drm.ko
<Sarvatt> modules were found in kernel 2.6.32-8-generic.
<Sarvatt> Warning! Cannot do version sanity checking because multiple ttm.ko
<Sarvatt> modules were found in kernel 2.6.32-8-generic.
<Sarvatt> Warning! Cannot do version sanity checking because multiple drm_kms_helper.ko
<Sarvatt> modules were found in kernel 2.6.32-8-generic.
<Sarvatt> it all works now RAOF
<Sarvatt> had to reinstall nouveau-kernel-source
<Sarvatt> http://sarvatt.com/downloads/nouveau.txt -- logs if you want them
<Sarvatt> accel is working as is mesa again with the firmware ya linked
<Sarvatt> afk now, bayonetta calling me to play it :)
<Sarvatt> tormod: when you read this log, what do you want to do about xserver in edgers? video input and extension abi's all just got bumped..
<Duke`> grrrr freeze again >:<
<Duke`> reverted back to libdrm*20091125*
#ubuntu-x 2009-12-20
<Sarvatt> what to do, what to do.. leave xserver master at the 12-17 checkout for a bit, drop xserver from edgers entirely or rebuild all drivers and make a new metapackage..
 * RAOF wonders how much to care about making a nouveau-firmware package.  It looks like rapid progress is being made towards generating it in the drm.
<Sarvatt> leaning more towards dropping sever entirely i think
<Sarvatt> oh really?
<RAOF> Well, it's already done for nv40, and if I'm reading it correctly mvk is 1/6th of the way through generating valid nv50+ ctxprogs
<Sarvatt> yeah that nv40 came fast as heck, was surprised to see that like 2 days after the merge
<Sarvatt> they talking about the nv50 firmware in #nouveau or something? dont see anything about it on the list
<Sarvatt> nice, someone working on classic mesa dri for the old nv0x-nv2x cards
<RAOF> Yeah, it's in #nouveau.
<RAOF> Incidentally, does gallium requrie a different libgl to classic mesa dri?  If not, why is it so hard to --enable-gallium-nouveau in your mesa builds?
 * RAOF hits the "washing up" button.
<RAOF> 09:31 <mwk> I should have a working ctxprog generator like the nv40 one ready tomorrow
<RAOF> Well, that was quick.
#ubuntu-x 2010-12-20
<ScottK> Sarvatt_: Has my logout patch stabilized yet?
<RAOF> It hasn't hit master yet, no.
<RAOF> Last update was on Friday; I'd expect more movement of it after the weekend.
<ScottK> Thanks
<RAOF> Note that I also cherry-picked the other glxdrawable refcnt patch in master for those test packages; you shouldn't be seeing the crash reported at the end of the upstream bug.
<RAOF> It's still tracking along nicely?
<bdmz> hi, does anyone know how /etc/environment gets loaded?
<jcristau> pam_env
<bdmz> thanks
<era878> Sarvatt_ are you there?
<era878> Sarvatt_, can you look at my Xorg.0.log, http://pastebin.ubuntu.com/545890/, and tell me why its loading the vesa driver instead of intel. Please could you email me the answer to, era878@gmail.com
<bdmz>  Where would I put an env variable assignment that depends on bash completion and needs to run as early in the boot process as possible?
<jcristau> bdmz: what are you trying to do, and why do you ask here?
<bdmz> I switch between a couple of different JVMs alot, and I keep forgetting to update JAVA_HOME
<bdmz> I ask here because someone in #ubuntu said you guys have are pretty knowledgeable
<bdmz> I know this is the X channel bit I figured I'd ask
<virtuald> bdmz: why not put it in .bashrc?
<bdmz> I need to have it defined before services like tomcat are started
<bdmz> that depend on it to start
<virtuald> ok then set it in the upstart or init script
<virtuald> or you could probably use the alternatives system to chose versions (update-alternatives)
<bdmz> alternatives doesn't set JAVA_HOME
<bdmz> and i'd like to have it set properly regardless of which services are running
<bdmz> do you know of any way to hook into the alternatives system?
<bdmz> it would be nice if I could run a script every time a change was made
<virtuald> no i've never done that :>
<bdmz> thanks anyway for the help, i know this is off topic
<ScottK> RAOF: Still working nicely, AFAIK.
#ubuntu-x 2010-12-21
<tseliot> Sarvatt: are you there?
<Sarvatt> tseliot: yep, whats up?
<tseliot> Sarvatt: what's the status of EMGD? I've seen that there's a PPA: https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsboAlternatives
<tseliot> Sarvatt: do you know if it works decently well?
<Sarvatt> I have absolutely no idea unfortunately
<Sarvatt> we have no release with xserver 1.8 outside of lucid + xorg-edgers
<tseliot> right, it requires a new X
<Sarvatt> requires xserver 1.8 afaik, doubt it works with 1.9..
<tseliot> :/
<Sarvatt> yep doesn't work with 1.9
<Sarvatt> (thanks meego)
<tseliot> Sarvatt: the usual Poulsbo nightmare ;)
<Sarvatt> they're the only ones that shipped anything with 1.8
<tseliot> thanks for your help
<Sarvatt> if its for personal use it would work fine with xorg-edgers+lucid at least :)
<tjaalton> yo, what's the status of natty on intel atm? I'm thinking of upgrading my laptop
<Sarvatt> better off than maverick, thats for sure
<Sarvatt> its gnome/compiz that you'll hit the fun with :)
<tjaalton> hmm, maverick has been working fine :)
<Sarvatt> applets fail to load all the time in the classic gnome session, compiz resets my settings every update, fun stuff
<tjaalton> hehe
<Sarvatt> gtk-window-decorator segfaults really often and takes out borders too, have to disable/reenable the decoration plugin in ccsm all the time
<Sarvatt> actually it segfaults every boot 100% of the time and i have to disable/reenable it
<tjaalton> mmkay
<tjaalton> that reminds me; is it just me or was the default border width changed to 1px in 10.10?
<tjaalton> it's infuriating..
<Sarvatt> lucid's the same :(
<Sarvatt> I think they're doing grips in the corners in natty
<tjaalton> lucid seems fine here
<tjaalton> oh
<Sarvatt> https://blueprints.launchpad.net/ubuntu/+spec/packageselection-dx-n-resizing-windows
<tjaalton> right the borders are, but the resize corner is 1x1 in 10.10
<tjaalton> approximately anyway
<Sarvatt> jcristau: looks like you're getting your wish :)  <doko> cdbs: it is unlikely that debian will make --as-needed the default
<jcristau> yay
<tjaalton> Sarvatt: what's the downside of it?
<Sarvatt> tjaalton: https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031991.html
<tjaalton> Sarvatt: ah that one.. hehe
<bryceh> tjaalton, yeah I finally got fed up with it and edited the theme xml file to increase the border width
<bryceh> I figured if I summed up all the many seconds wasted trying to get my mouse over the border, I could actually do something with all that time
<tjaalton> bryceh: heh :)
<tjaalton> in lucid it's 4pix wide
<bryceh> I set it to 10!
<tjaalton> so enough for me, but dunno what it used to be
<tjaalton> if the blueprint said it was changed for lucid
<tjaalton> 10 seems plenty :)
<bryceh> actually, even setting it to just 2 or 3 makes the corners a lot easier to hit
<tjaalton> yeah
<bryceh> on my desktop I got phat space
<bryceh> file is (for metacity) /usr/share/themes/Ambiance/metacity-1/metacity-theme-1.xml
<tjaalton> thanks, I'll check it out
<bryceh> regarding natty stability... I have it on two machines I actively use.  The unity interface is pretty clunky at present.  Switching to classic works, although I've still had misc. irritants like Sarvatt mentioned, and my laptop no longer suspends.  X seems to be reasonably stable though.
<bryceh> (which we'll fix once we upload the new xserver *grin*)
<Sarvatt> bryceh: suspend or hibernate?
<bryceh> suspend
<Sarvatt> hibernate should be fixed in 2.6.37-rc7
<bryceh> like, close lid, pops up a dialog saying it couldn't suspend.
<bryceh> there isn't even a suspend option listed in any of the menus anymore
<bryceh> my 1.5 yr old son every day, first thing he does is close the lids on all the laptops.  So this is a bit of a problem ;-)
<Sarvatt> there's someone out there that likes a laptop suspending when the lid is closed?
<Sarvatt> I always figured only mac fans liked that :)
 * Sarvatt closes/opens his laptops all day long and doesn't like disconnecting
<bryceh> well, this particular laptop gets really hot when the lid is closed
<bryceh> the disconnecting bit is annoying.  But I try to only use it as a dumb terminal onto other machines so it's not a big deal.
<bmw_> Having a bit of trouble on Kubuntu 10.10 with Radeon HD 3200.  All your drivers are installed and FGLRX is not installed.  Desktop Effects in System Settings is completely grayed out. Please advise. Thank you in advance.
<Sarvatt> bryceh: ok I'm not crazy, fglrx/nvidia install worked on the karmic livecd - https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/524902
<ubot4> Sarvatt: Error: Bug #524902 is private.
<bryceh> Sarvatt, hmmm
<Sarvatt> i think i can narrow down when it broke by looking at closed glxinfo bugs
<bryceh> clever
<Sarvatt> bryceh: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/594701
<ubot4> Sarvatt: Error: Bug #594701 is private.
<Sarvatt> working...
<Sarvatt> that looks like a final lucid livecd
<Sarvatt> LiveMediaBuild: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
<Sarvatt> ah wait
<Sarvatt> it worked because his card wasn't supported so it didnt build a module
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/mesa/+bugs?field.searchtext=XF86DRIQueryExtension%28%29&orderby=-importance&search=Search&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX
<Sarvatt> here we go, thats a good range
<Sarvatt> nothin, forgot LiveMediaBuild in that search
<Sarvatt> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=LiveMediaBuild+XF86DRIQueryExtension%28%29&orderby=-importance&search=Search&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<Sarvatt> thats right, most were against gnome-screensaver :)
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/mesa-demos/+bug/661756 somehow they magically got fglrx installed in maverick
<ubot4> Sarvatt: Error: Bug #661756 is private.
<Sarvatt> ah gpu must not be supported yet again
<Sarvatt> rough guess is it broke around beta 1 for lucid, LiveMediaBuild: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100404) is the earliest lucid report i've found so far
<Sarvatt> LiveMediaBuild: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100406.1) is the second oldest
<Sarvatt> would help if there weren't hundreds of package updates on april 1st :)
<bmw_> Having a bit of trouble on Kubuntu 10.10 with Radeon HD 3200.  All your drivers are installed and FGLRX is not installed.  Desktop Effects in System Settings is completely grayed out. Please advise. Thank you in advance.
<bryceh> bmw_, -> try http://askubuntu.com
<bmw_> Thanx. Have a great day.
<bmw_> bryceh -> not very helpful site. I came here b/c your wiki said I could get some help. Can I?
<bryceh> bmw_, where did it say that?
<Sarvatt> guess I'll boot a livecd and try playing with mkinitramfs, wonder if any of these are busting the vmlinuz symlink because the timeframe is right - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/initramfs-tools/natty/revision/168 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/initramfs-tools/natty/revision/167 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/initramfs-tools/natty/revision/175#mkinitramfs
 * bryceh -> lunch
<bjsnider> Sarvatt, when you tried booting the karmic livecd, did it work?
<Sarvatt> haven't booted a karmic livecd in ages, would help if it was even possible to create a lucid liveusb in maverick+ :)
 * RAOF gasps as the full majesty of X's resource system slowly unfolds before his eyes.
<JanC> RAOF: gasping because it's beautiful or because you're drowning?  ;)
<RAOF> Well, I've just realised where the mechanism which stops everything leaking to hell is.
#ubuntu-x 2010-12-22
<saintly> hello hello, having vesa driver issues..
<saintly> im trying to run Compiz, when i get this statement in the sytem check:
<saintly>  Distribution:          Ubuntu 10.10
<saintly>  Desktop environment:   Xfce
<saintly>  Graphics chip:         Intel Corporation 82852/855GM Integrated Graphics Device (rev 01)
<saintly>  Driver in use:         vesa
<saintly>  Rendering method:      AIGLX
<saintly> Checking if it's possible to run Compiz on your system...  [SKIP]
<saintly>  Checking for hardware/setup problems...           [SKIP]
<saintly> At least one check had to be skipped:
<saintly>  Error: vesa driver in use 
<saintly> Would you like to know more? (Y/n) y
<saintly>  The vesa driver is not capable of running Compiz, you need to install
<saintly>  the proper driver for your graphics card.
<RAOF> saintly: I'd guess you've turned off kernel modesetting.
<RAOF> Also, your we don't support compiz on your GPU, because if you try to turn it on you'll end up with seemingly-random X hangs.
<saintly> so no luck for me eh
<Sarvatt> on day evolution won't suck! only manage to get one email out before outgoing mail stops sending :)
<RAOF> One day there'll be a mail client that doesn't suck.
<Sarvatt> yeah its called gmail :)
<RAOF> That handles threading *really* badly.
<Sarvatt> ?!
<JanC> Sarvatt: lol, Gmail is the worst mail client I ever used  :P
<Sarvatt> i love how it handles threading, all my mailing lists are through gmail
<JanC> even outlook/exchange is more standards-compliant  :P
<JanC> (well, can be beat into being more standards-compliant, at least)
<Sarvatt> guess it's back to thunderbird I go, wanted to give evolution a shot on the new PC since I never used it before
<JanC> outside of crashes every 3-6 days, Evolution works fine here
<RAOF> gmail handles *linear* threading brilliantly.  What it *doesn't* handle is forks in a thread.
<Sarvatt> hmm hasn't crashed yet, but I have to close/reopen it to send email every darn day
<Sarvatt> ahh ok I see what you mean, I just like how it puts the threads in every label if someone responds on another list
<JanC> actually, Evolution crashes only every 1-2 weeks in maverick now
<JanC> and I guess most peopel don't keep their mail client running for that long  ;)
<Sarvatt> hell I wish I could have more than 3-4 days uptime on natty :)
<JanC> I don't read mail on natty  ;)
<JanC> Sarvatt: gmail hides your own answers to a list though, which really sucks...
<JanC> especially when you are a list admin and have to explain that erratic behaviour to new contributors over and over again...
<JanC> when people resend (and re-resend, etc.) their mails because they don't see them arrive
<Sarvatt> bryceh: hmm, why hasn't nvidia-graphics-drivers-96 moved to -updates yet?
<Sarvatt> (in maverick)
<Sarvatt> looking at the patch list and saw that in there, its sitting in proposed
<bryceh> Sarvatt, dunno, I think it needs promoted by pitti
<bryceh> he may be on vacation
<bryceh> Sarvatt, seb128 may be his backup
<Sarvatt> i think it needs changes to other packages since it was blacklisted anyway, will ask tseliot
<Sarvatt> hmm https://bugs.launchpad.net/ubuntu/+source/desktop-file-utils/+bug/592671 appears to be rearing its ugly head with the humble bundle games
<ubot4> Launchpad bug 592671 in desktop-file-utils (Ubuntu) "application cache update (affects: 1) (heat: 19)" [Wishlist,New]
<apw> Sarvatt, heard of any blank screen issues with Natty with recent x changes?  we seem to have a machine (marjo's) which has gained new bad behaviour back to old previously working kernels ... any suggestions as to which package to blame ?
<Sarvatt> how recent? there haven't been any X changes in almost a month
<Sarvatt> can ya point me at any channel with the info in the scrollback?
<apw> Sarvatt, not X then, ... i would say his issue is about a week old, it came with the -10 kernel but booting back to -9 does not work correctly either any more
<apw> Sarvatt, there is none, as he continuiously uses private messages for some reason (most annoying)
<apw> Sarvatt, there is a bug however
<apw> bug #693093
<ubot4> Launchpad bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/693093
<Sarvatt> oh, thanks, looking
<Sarvatt> go figure it's against linux so wont have the informative logs in it :)
<apw> Sarvatt, with the black screen issue on -10 he now gets what he describes as 'low resolution mode' on all older kernels too
<apw> which sounds very strange indeed to me
<apw> Sarvatt, indeed, but i did get the Xorg.log added
<Sarvatt> vesafb picking 1024x768 on a 1024x600 panel, check..
<Sarvatt> not seeing anything really obvious so far outside of that, slow at reading logs sorry :)
<apw> Sarvatt, i know, to my eye X is happy so i'd expect a display
<apw> he claims the backlight is visible
 * apw tries to summon marjo
<marjo_> apw: i'm here
<apw> Sarvatt, the victim himself
<apw> marjo_, you are able to ssh into this machine arn't you
<Sarvatt> marjo_: can you try booting with vesafb.sucks=1 and see if it's any different?
<apw> Sarvatt, is that a technical term
<marjo_> apw: able to ssh in
<Sarvatt> invalid module parameter stopping it from loading :)
<apw> so foo.blacklist_me_dammit=1 would disable any module ?
<Sarvatt> apw: yep, only way I know of to disable built in modules
<apw> interesting
<apw> we should define one which does the same thing ... for all modules
<Sarvatt> blacklist=foo, but that doesn't always work
<Sarvatt> if you have it in /etc/modules or something it'll load after the initrd is done even with blacklist=foo
<apw> Sarvatt, do you think a drm.debug=0x4 might help us?
<Sarvatt> i'm putting my bets on plymouth dying after the vesafb transition because it's happened so much in the past, but if not yeah
<apw> Sarvatt, i think plymouth dies on most machines, but normally X can pick up from it and you just have more black than you wanted
<Sarvatt> apw: i've had plymouth die at just the right time to where it gets stuck on a blank vt and can't recover giving me a black screen at boot more times than I can count
<apw> Sarvatt, ahh not something i've met, but you do meet a lot more bust video than me
<apw> marjo, was that a good or bad sign you logging in there
<Sarvatt> apw: mostly it came from shoving plymouth in the initrd, it's so racy
<marjo> Sarvatt: vesafb.sucks=1 does NOT make any diff;same result
<marjo> Sarvatt: want me to try without vt.handoff=7 splash quiet
<apw> marjo, is there any way you can video the boot?
<marjo> apw: how?!
<apw> subtle flickers etc can tell one loads about the issues
<marjo> apw: there's really nothing to video
<apw> marjo, i use my mobile normally
<apw> marjo, does your grub go purple ?
<Sarvatt> marjo: do you see the text splash or a logo? do you see the logo resize during the boot?
<apw> Sarvatt, this is Natty (marjo right?)
<marjo> apw: natty
<Sarvatt> yeah I get a text splash maybe 1/10 boots
<apw> so you should see 'bios, black with cursor (short), purple without cursor (long), plymouth maybe, black screen (short), maybe more plymouth, X
<apw> marjo, what of that sequence do you see
<apw> and for how long do you see each segment
<apw> likely during the second black the backlight may go off
<marjo> apw, Sarvatt: no logo, disk activity LED lights, drum heard, blank screen
<apw> marjo, and before it goes black ?
<Sarvatt> so its definitely screwed up early, sounds like vesafb isn't working for one (not that I imagine it would at 1024x768 on a 1024x600 panel)
<apw> marjo, it is possible one of my machines is now exhibiting similar beahviour, though i am without backlight
<Sarvatt> updating my screwed up netbook now to see if I hit it too
<apw> something very off going on at the mo
<marjo> apw: ack
<Sarvatt> apw: heh, my screen dies too
<Sarvatt> fades to white here though
<Sarvatt> oh now it's light purple
<apw> wtf is going on all of a sudden
<apw> purple is normal after grub
<Sarvatt> and then X started and its fine
<Sarvatt> it was purple after grub, then it faded to white, then drew purple over the white
<apw> wibble
<marjo> Sarvatt: i don't see the "fade to white" on mine
<apw> Sarvatt, ok whatever i have cleared after some minutes of ignoring it
<apw> it continued to X
<apw> and then hung ... what the helll
<Sarvatt_> jeeze, vesafb makes vt's suck, over 1 minute to get a dmesg
<Sarvatt_> http://sarvatt.com/downloads/VID_20101222_121058.3gp
<Sarvatt_> ah hah, thats with /lib/plymouth/renderers/drm.so moved out of the way, everything works fine using the drm renderer
<apw> Sarvatt_, hrm
<Sarvatt_> marjo: can you try sudo mv /lib/plymouth/renderers/frame-buffer.so{,.bak} and reboot?
<apw> Sarvatt_, oh that kind of fade to white, thats the 'not refreshing the vram' look isn't it ?
<apw> Sarvatt_, which kernel you got?
<Sarvatt_> yeah
<Sarvatt_> thats on -11
<Sarvatt_> framebuffer renderer looks busted here
<apw> bah
<apw> something screwey is going on, these kernels worked last night
<apw> and indeed my amd64 is still working
<apw> but i am seeing wibble behaviour with 11 and 10 all of a suddent
<apw> kernels i ahve been runnig for days
<marjo> Sarvatt: done, rebooted and same behavior on -10
<marjo> Sarvatt: want me to try on -11?
<marjo> Sarvatt: trying -11 now
<marjo> Sarvatt_ ^^^
<Sarvatt_> marjo: thanks for trying, you want to move /lib/plymouth/renderers/frame-buffer.so.bak back to frame-buffer.so if it didnt do anything
<Sarvatt_> apw: hope its no grub :)
<apw> Sarvatt_, la la la cannot hear you
<marjo> Sarvatt_ I misunderstood; i thought you said moving drm.so out of the way worked fine
<Sarvatt_> marjo: nope moving it back worked fine, it was busted when it was using frame-buffer.so which it does some times because its racy
<Sarvatt_> totally depends on how fast you boot as to what it uses from my experience with it
<marjo> Sarvatt_ yikes! it's that "racy"?
<marjo> Sarvatt_: ok moving either drm.so or frame-buffer.so out of the way results in same behavior on -10
<marjo> Sarvatt_ so, no diff
<Sarvatt_> struggling to see what else it could be outside of grub at this point..
<bdmurray> bryceh: the right tag is regression-release for natty or any stable release
<Sarvatt_> since its affecting old kernels you haven't run update-initramfs on so its not something in the initrd, and its happening early
<apw> Sarvatt_, there is exactly no kernel drm changes from 2.6.36-rc6 -> -rc7 which is the diff between -10 and -11
<apw> gurgle
<marjo> Sarvatt_ here's what I've tried with no success
<marjo> set gfxpayload=text
<apw> and now -10 is showing the same symptoms a bit wtf
<Sarvatt_> ah was going to ask that next, didn't help?
<marjo> removed 'splash quiet vt.handoff=7'
<Sarvatt_> apw: we tested the heck out of -10 yesterday for the grub thing too!
<Sarvatt_> or was that another machine? sorry
<marjo> Sarvatt_ in --verbose mode, last output is: "Running /scripts/init-bottom done'
<apw> Sarvatt_, no this was the very same machine!
<apw> Sarvatt_, thats how i know it worked ... and now .. its odd
<apw> i want to cry
<Sarvatt_> apw: have the old grub .debs in /var/cache/apt/archives?
<Sarvatt_> my machine works so I can't test it
<Sarvatt_> oh actually, if I move drm.so out of the way again I can test it, it was moved out of the way before when it was working
<marjo> Sarvatt_ i've also tried removing "set gfxpayload=linux_gfx_mode" with no success
<Sarvatt_> marjo: did this just start in the last day or so?
<maxb> Is this the AOA150 thingy you asked me about testing last week, Sarvatt_ ?
<Sarvatt_> maxb: nope that was a grub problem and got fixed in the most recent grub
<apw> Sarvatt_, ok old grub is broken as expected on reboot, so i have the old one
<marjo> Sarvatt_ no it started with my upgrading on 17 December 
<maxb> Sarvatt_: ah, that must be the grub my ADSL is struggling with right now then :-)
<Sarvatt_> apw: guess what
<Sarvatt_> apw: your grub 20101210~verbose9 works
<Sarvatt_> new grub 20101221 is bonkers, this may be an unrelated problem though
<Sarvatt_> marjo: did it hang with a blinking underscore in the top left of the screen previously by any chance, or was it the same?
<marjo> Sarvatt_ never hung w/ blinking underscore; always gets past the blinking underscore
<apw> Sarvatt_, and you are able to boot this -11 kernel ok on you n270:
<apw> ?
<Sarvatt_> apw: yep, my problem is different, i only have a problem moving the plymouth drm renderer out of the way with the newer grub
<apw> Sarvatt_, this is mad, so you can boot it and i could last night and cannot today ... this is just wibble
<Sarvatt_> apw: maybe I shouldn't mention booting the kernel with no nx-emu works fine too :) as does stock -11 with your 20101210~verbose9 grub packages
<apw> must be some kind of race with something something
<marjo> Sarvatt_ FWIW here's what verbose mode tells me:
<apw> yeah just went back to *verbose9* and it doens't work any better than the grub2 in the archive
<marjo> Sarvatt_ init: plymouth state changed from post-start to running
<marjo> Sarvatt_ init: Handling start event
<Sarvatt_> apw: ah ok definitely a different problem I'm hitting then
<marjo> Sarvatt_ drum heard; blank screen
<Sarvatt_> hmm, wonder if plymouth:debug output would help
<marjo> Sarvatt_ how? please advise
<Sarvatt_> marjo: without a good boot to compare it to it probably wont be that helpful, but you can add plymouth:debug to the kernel command line in grub and a log will show up at /var/log/plymouth-debug.log
<apw> Sarvatt_, i didn't think plymouth was in initramfs, so i don't need to regen those do i ?
<Sarvatt_> oh whoops it is on my netbook according to lsinitramfs, maybe thats why the grub downgrade worked :)
<Sarvatt_> shouldn't be by default unless you forced it at some point
<apw> yeah doesn't seem to be
<Sarvatt_> lets see if i can reproduce problems removing it
<marjo> Sarvatt_ here's some suspicious plymouth:debug output:
<marjo> [ply-utils.c]                               ply_open_module:Could not load module "/lib/plymouth/renderers/x11.so": /lib/plymouth/renderers/x11.so: cannot open shared object file: No such file or directory
<marjo> ^M
<marjo> [./plugin.c]                                create_backend:creating renderer backend for device /dev/dri/card0^M
<marjo> [./plugin.c]                                   load_driver:Attempting to load driver 'i915'^M
<marjo> [ply-terminal.c]                             ply_terminal_open:trying to open terminal '/dev/tty7'^M
<Sarvatt_> http://pastebin.com/SMKx3JxY -- thats mine on a good boot
<apw> Sarvatt_, i see we have a new udev 32 hours ago
<marjo> Sarvatt_ ok, so your good boot has same "no such file or directory messages" as mine
<apw> Sarvatt_, ok this looks to be something outside the kernel
<apw> i regenerated the initramfs for my -10 kernel and not its bolloxed too
<apw> now
<Sarvatt_> does recovery work?
<dijenerate> hi all
<dijenerate> I'm running a series of systems for digital signage and already deployed machines have jaunty on them
<dijenerate> they run intel 945gme chips on atom soc boards
<bryceh> Sarvatt_, we ought to clean up / improve https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<dijenerate> we started to change some of our screens our to a custom display based Panasonic's Viera tc-p42c2x board... essentially a tv
<dijenerate> now, 
<dijenerate> now, we can't get any display res to work using the intel driver... 2.9.1-1ubuntu
<dijenerate> does anyone have any suggestions that could help?
<dijenerate> we cannot upgrade the os at this stage because of other hardware/software dependency issues
<dijenerate> any ideas?
<dijenerate> anyone?
<apw> Sarvatt_, ok ... seems that the issue is that udev is borked
<apw> Sarvatt_, and any kernel which has its initramfs rebuilt after the update gets fooked
<Sarvatt_> apw: wow what the heck is going on, X didn't start for 216 seconds afte I removed plymouth from the initrd
<Sarvatt_> http://pastebin.com/7VtnNJ1f
<apw> Sarvatt_, that is the bug ... and you can confirm my finding
<apw> Sarvatt_, boot an old kernel and then downgrade udev to the previous version
<apw> Sarvatt_, that will re-regen your initramfs and fix you
<Sarvatt_> i already did a update-initramfs -u -k 'all' and busted my old ones removing plymouth
<apw> Sarvatt_, be good if you could try that as it would confirm udev is bust
<apw> Sarvatt_, oh you may be in the poo you may need a USB stick then
<apw> Sarvatt_, oh if you can get in over the network you are ok of course, i couldn't on mine without logining in which i couldn't do
<apw> Sarvatt_, did you manage to downgrade udev ?
<bryceh> bdmurray, so sounds like regression-development is being merged with regression-release?  Is that because bugs are tagged with the release name so can be distinguished that way?
<bryceh> bdmurray, have you thought about maybe simplifying the tag to just 'regression'?
<Sarvatt_> apw: yeah, guess I got booted? besides that fluke 216 second boot its no different
<Sarvatt_> X up around 26 seconds in
<apw> Sarvatt_, so downgrading udev sorted you as well?
<Sarvatt_> i'm back to newer udev again and its fine, sorry to confuse you even more
<apw> hrm odder
<apw> i will try upgrading again, and see
<Sarvatt_> last boot with the downgrade, X was up at 25 seconds in, this boot after upgrading again 26 seconds
<bdmurray> bryceh: it was originally regression-potential but is now regression-release.  https://lists.ubuntu.com/archives/ubuntu-bugsquad/2010-October/002778.html
<Sarvatt_> well got the 216 second boot explained at least,  not used to it being silent in dmesg: Last checked:             Wed Dec 22 14:14:05 2010
<Sarvatt_> apw: BAH wait a second here
<Sarvatt_> [   20.810481] udev[381]: starting version 164
<Sarvatt_> looks like i didn't upgrade again properly
<Sarvatt_> udev 165: X up at 25 seconds, 29 seconds, 29 seconds, doesn't seem to be a problem
<Sarvatt_> I got upstart and dbus upgrades going back to the new udev though
<bryceh> Sarvatt_, apw, using your debugging discussions, I updated https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen a good bit
<bryceh> Sarvatt_, apw, hopefully if others need to debug other kinds of black screen bugs they'll be able to use your approach to pin it down
<Sarvatt_> If the kernel supports Mode Setting (KMS), it puts the video card into its preferred resolution using a frame buffer (vesafb). The framebuffer is initialized with a purple background. -- oh how I wish that was true, maybe 10 years ago when we had 4:3 monitors with native modes in the vbios :)
<bryceh> if there already is a troubleshooting page for this kind of bug let me know so we can merge this into it; seems like these black screen boot problems are technically not X issues so this may not be the perfect place for the page
<bryceh> (otoh people still blame X for these types of bugs so maybe it is)
<bryceh> Sarvatt_, ok feel free to edit.  I made some guesses out of ignorance there ;-)
<bryceh> or if you don't feel like wiki'ing just mention the corrections here and I'll make them in a bit
<Sarvatt_> it's kind of hard because step 4 isn't exactly clear cut and depends on how fast you actually boot :) it'll start drawing to whatever is available and if the KMS fb gets loaded after it just resizes things to native from whatever it was using before
<Sarvatt_> throwing plymouth in the initrd with gfxpayload=text I can get plymouth starting to draw before vesafb is even loaded like 1 second in so things use the text splash
 * Sarvatt_ doesn't understand what grub is doing in the process at the moment
<Sarvatt_> bryceh: this is going to be a novel but i'm editing it, do you realize how many possible varations in each step there are? :) plymouth picks different backends based on how many heads are plugged into the GPU on radeon for instance, cryptsetup being installed packs the gpu modules in the initrd so stuff happens earlier, and the copyfb stuff alters things
<marjo> Sarvatt_ anything else I can try on my system, or just wait for udev fix?
 * marjo assumes "udev is borked" is the root cause
<Sarvatt_> marjo: the udev stuff isn't your problem most likely because it just got released yesterday, I'm out of ideas about what it could be
<marjo> Sarvatt_ ack
<bryceh> back
<marjo> Sarvatt_ time to reinstall Alpha-1 on this puppy?
<bryceh> Sarvatt_, whoa, didn't realize plymouth was trying to be so magical
<bryceh> Sarvatt_, that's gotta be full of bugs
<Sarvatt_> bryceh: why do you think I hate vesafb/vga16fb so much? :)
<bryceh> heh
<marjo> bryceh: through it's trying to be so magical, it seems to introduce "racy" conditions
<marjo> Sarvatt_ and here it was the plymouth 2.7 change i was worrying about
<marjo> hah!
<bryceh> Sarvatt_, well, getting it docced a bit might help in diagnosing the problems, but it's probably ok if it's not exhaustive of all the options.  Stuff changes in the code faster than we can update docs typically, so a bit of generalizing may be worthwhile
<bryceh> marjo, during boot is the worst place to have race conditions ;-)
<marjo> s/plymouth/python
<bryceh> I suppose it's that way in order to do fast boot
<marjo> bryceh: ack
<Sarvatt_> apw: were you able to reproduce it in that you were stuck on a black screen even after X started the same as marjo?
<Sarvatt_> or was it some other issue?
<Sarvatt_> it really looks like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/605667 to me, but vesafb.sucks=1 as well as GRUB_GFXPAYLOAD_LINUX=text should fix it if so an it's not.
<ubot4> Launchpad bug 605667 in linux (Ubuntu) "Kernel Oops - unable to handle kernel NULL pointer dereference; RIP: 0010:[<ffffffff81365730>] [<ffffffff81365730>] fb_release+0x30/0x70 (affects: 2) (heat: 28)" [Medium,In progress]
<Sarvatt_> (that was from last time we had gfxpayload=keep enabled along with vga16fb)
<Sarvatt_> marjo: funny enough, windows 7 wont work on your eee without a bios upgrade because of that 1024x768 problem, it gets stuck with a black screen after the windows splash because it tries to use that invalid mode
<Sarvatt_> they fixed it in bios 0602
<Sarvatt_> not saying its the same problem but might be worth upgrading it anyway, i'm not sure you'll ever see a splash the way things are set up now with vesafb unless its later on from the drm renderer which can use 1024x600
<marjo> Sarvatt_ but that doesn't explain why this system used to work, does it?
<marjo> Sarvatt_ I'm tempted to install natty-Alpha1 just to convince myself; what do you think? i seem to be stuck anyway
<Sarvatt_> nah your xorg log shows it using 1024x600, struggling to work out how it could break down like that
<Sarvatt_> marjo: wait, when you say natty updates on december 17th broke it, do you mean you upgraded from maverick on december 17th?
<marjo> Sarvatt_ no, i upgraded natty->natty
<Sarvatt_> ah darn, that would have made more sense :)
<Sarvatt_> in software center -> history, can you narrow it down to what you upgraded on the 17th?
<marjo> Sarvatt_ do you think you've got everything you need from my system? if so, i'd like to install alpha1 on it
<Sarvatt_> so many possibilities in the week of packages before that
<marjo> Sarvatt_ yes, i was holding off my daily upgrade due to my concern re: python 2.7, then I got encouragement from doko and mvo, so i went for it!
<marjo> and mvo and I couldn't narrow it down to an offending package; we both were tending towards a plymouth bug
<marjo> we had ruled out grub, based on debugging
<marjo> Sarvatt_ ok, i'm going to install natty-alpha1 and see how it breaks from there
<marjo> Sarvatt_ maybe that will help us narrow down the problem
<marjo> Sarvatt_ ping
<Sarvatt_> marjo: heyo, any luck with alpha 1?
<marjo> Sarvatt_ good news
<Sarvatt_> oh?
<marjo> Sarvatt 2.6.37-3 boots; no high res
<marjo> 2.6.37-5 boots; no high res
<marjo> 2.6.37-7 all works! including 1024x600(16:9)
<Sarvatt> hmm, -8 and higher don't?
<marjo> Sarvatt i haven't gone further; what do you want from this working system before I try -9?
<Sarvatt> marjo: is this on that new install, or did ya just install those on the old one?
<marjo> Sarvatt? huh?
<Sarvatt> those kernels, did you install a new alpha 1 install like you said and then tried out the older kernels, or did ya just try those on your old install?
<marjo> Sarvatt: i installed natty-alpha1, but system still had all these old kernels lying around, so i started at -3 (alpha1) and started trying different kernels
<marjo> Sarvatt: i just wanted to narrow down where things broke, since this system used to work fine
<Sarvatt> marjo: /var/log/kern.log would be helpful
<marjo> Sarvatt: ack
<marjo> Sarvatt: attach to bug report or how do you want it?
<Sarvatt> the bug please if thats ok
<marjo> Sarvatt: done
<marjo> Sarvatt: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693093
<ubot4> Launchpad bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 2) (heat: 14)" [High,Confirmed]
<Sarvatt> marjo: yeah digging through it now, wanted kern.log because it has the bad boots too and hopefully can spot the difference there
<Sarvatt> marjo: I think what i'd do next is upgrade just the kernel to the latest so you can rule that out
<marjo> Sarvatt: yes, back to -3
<marjo> Sarvatt: latest == -11?
 * Sarvatt nods
<marjo> Sarvatt: with this system, even the trackpad works!
<Sarvatt> dont believe the kernel is going to be the actual problem and we can rule it out right away if -11 works without all of the other stuff updated
<Sarvatt> the trackpad didn't work before?!
<Sarvatt> vesafb isn't getting used on your successful boot of -7 there
<marjo> no the trackpad also stopped working at some point
<marjo> Sarvatt: is that good? vesafb not getting used?
<Sarvatt> hmm it isn't getting used in *any* of those boots, don't tell me we turned that on after alpha 1? :)
<RAOF> No, it's still crazifying some of my systems.
<RAOF> At least, last time I checked.
<marjo> Sarvatt: boot into -11?
<Sarvatt> marjo: yeah, leave the rest of the userspace at alpha 1 and try -11 out
<marjo> Sarvatt: -11 works like a charm! w/ unity & trackpad & compiz
<marjo> Sarvatt: so which of the 500+ packages is suspect? plymouth?
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=33c08882c0d551afb28baef643279901dcc65fa9 was the only change to x-x-v-intel, hmm
<Sarvatt> on december 13th
<bryceh> Sarvatt, hmm
<Sarvatt> x-x-v-intel, grub, udev are the prime suspects I think marjo, if anything I would try upgrading those one by one and see if it busts
<Sarvatt> (sorry to be such a pain, really shooting in the dark here)
<marjo> bryceh, Sarvatt: and breakage observed on 17 December...
<marjo> Sarvatt: ok, will do; please no apologies
<marjo> Sarvatt: upgrading grub2 first, ok?
<Sarvatt> marjo: I would do x-x-v-intel first
<Sarvatt> least invasive :)
<Sarvatt> doesn't matter I guess
<marjo> Sarvatt: how do i get x-x-v-intel?
<bryceh> Sarvatt, do you suspect the above intel patch?  doesn't look like it could cause this particular problem but who knows
<Sarvatt> udev might pull in a ton of other stuff
<marjo> Sarvatt: so i think i'll do grub2 first (just for kicks)
<Sarvatt> okie, was saying that because grub2 update is going to pull in all the vesafb mess, sudo apt-get install xserver-xorg-video-intel would do it
<Sarvatt> bryceh: it doesn't look like it to me, but with copy-fb I'm not sure, need to go over this more
<marjo> Sarvatt: i upgraded grub2 and now my system is broken (dark screen)
<marjo> Sarvatt: w/ -11 kernel
<Sarvatt> marjo: ok can you ssh in and get the dmesg and attach it to the bug and we can move it over to grub?
<Sarvatt> its... complicated though. vesafb loading now and all and that machine thinks it has a 1024x768 vesa mode that it doesn't work with so it's going to be black with that..
 * Sarvatt looks up vga= modes to try
<marjo> Sarvatt: but isnt' that the exact problem i'm dealing with?
<Sarvatt> kind of, I'm not sure why that is breaking the boot process completely
<Sarvatt> for me using an invalid mode with vesafb just screws up the early part of the boot process and it recovers fine
<marjo> Sarvatt: ack
#ubuntu-x 2010-12-23
<Sarvatt> marjo: ok try booting with vga=315 added to grub
<Sarvatt> if that works, update your bios to fix it
<marjo> Sarvatt: add vga=315 to the kernel command line?
 * Sarvatt nods
<marjo> Sarvatt: no such luck; drum heard, blank screen
<marjo> Sarvatt: still want dmesg?
<Sarvatt> marjo: what does dmesg | grep "vesafb: mode" say when booting with that vga=315?
<Sarvatt> 800x600?
<marjo> Sarvatt: returns nothing
 * Sarvatt scratches head
<Sarvatt> apw: la la la? :)
<bryceh> Sarvatt, any thoughts on bug #692677?  
<ubot4> Launchpad bug 692677 in nvidia-settings (Ubuntu) (and 1 other project) "Desktop login to unity leads to hang and compiz crash when X Server Display Confirmation is clicked on (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/692677
<bryceh> nvidia-setting's glx calls through unity behave differently than when booted with classic desktop
<bjsnider> for something that's "trivial to fix" that is a large patch
<RAOF> Hm.  So, I can't reproduce *that* crash, but nvidia-settings is all manner of messed up here.
<RAOF> Which is odd, because it was working perfectly last night.
<RAOF> SIGFPE!  Woot!
<bryceh> RAOF, hrm
<RAOF> Just updating to the most current stuff & seeing if I can reproduce.
<bryceh> Sarvatt, RAOF:  Example output from new apport hook - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/693667
<ubot4> Launchpad bug 693667 in xorg (Ubuntu) "Yet another apport test (affects: 1) (heat: 6)" [Undecided,New]
<RAOF> You know about the APPORT_STAGING env variable, yes?
<RAOF> Also, that nvidia-settings thing is weird.
<bryceh> oh, hadn't seen mention of APPORT_STAGING before
<bryceh> anyway, I mostly test apport locally anyway
<RAOF> Is DistUpgraded the last time the machine was upgraded from one release to another, or the last time dist-upgrade was run (that's a stupid terminology confusion :()
<bjsnider> what does an apt-get dist-upgrade do exactly?
<RAOF> Upgrade + install new packages if appropriate.
<bjsnider> upgrade to a new distro?
<RAOF> âupgradeâ is just âinstall newer versions of what I've got installed, but don't install any new packagesâ
<bjsnider> well, if it's not upgrading to a new distro then i don't see why it's called "dist-upgrade". sounds like it should do what update-manager -d does
<bryceh> RAOF, specifically it is top -n 1 from /var/log/dist-upgrade/apt.log
<RAOF> It does, dosen't it :)
<bryceh> RAOF,  which isn't precisely what I'm after so I might change it
<RAOF> Hm.  SIGFPE in nvidia_drv for all!
<bryceh> basically what I want is a mechanical way to indicate whether the user's system was upgraded from a prior release, or was a fresh install to natty (possibly with some updates)
<RAOF> Yeah.  That's a fine goal.
<bryceh> my working theory is that the existence of any content in /var/log/dist-upgrade/apt.log would indicate an upgraded machine
<bryceh> but I'm open to better solutions
<bryceh> for now though, being called to dinner... bbl
<RAOF> Hm.  Working theory - switching to display server configuration *sometimes* causes nvidia-settings to resize its window to nonsensical values; from here, maximising will crash the server with an FPE in nvidia_drv, or gtk-window-decorator will BadAlloc first.
<bjsnider> maybe dist-upgrade is one of those things that makes more sense in debian, where there's only a new distro every thousand years or so, than it does in ubuntu, where you can't throw a rock without hitting a new distro
<RAOF> Well, it really does look like 06_thingamy.patch is to blame.
<bryceh> RAOF, oh?
<bryceh> bjsnider, yeah the upgrade vs. dist-upgrade thing has always seemed weird.  
<RAOF> bryceh: Well, I rebuilt nvidia-settings without it and it doesn't seem to trigger the same madness.
<bryceh> hmm, well sounds like the patch needs more work before we can be shipping it
<uros1> any chance to run fan speed control with old NVIDIA 8500GT
#ubuntu-x 2010-12-26
<cdavis> I installed the PPA and did an update but still can't find nvidia-graphics-drivers available for install?
<bjsnider> the package is called nvidia-current
#ubuntu-x 2011-12-19
<RAOF> Huh.
<RAOF> Synaptics would be much more useful if it didn't reset the pointer position to (0,0) every five seconds of movement or so.
<Sarvatt> RAOF: the fix went into rc6 :)
<Sarvatt>  s/fix/revert/
<RAOF> Right.  rc6 makes this Dell all manner of pleasant.
<Sarvatt> cool beans, not surprised
<RAOF> Or, rather, the lack of that fix makes this Dell all manner of unpleasant :)
<RAOF> Sarvatt: Do you remember a bug where synaptics would keep resetting to (0,0)+
<RAOF> ?
<Sarvatt> hmm
<Sarvatt> so theres a bug where unity does that regardless of the driver with wine
<Sarvatt> i havent reported that yet
<Sarvatt> its very annoying with steam menus
<RAOF> Yeah.
<Sarvatt> it happens on evdev and synaptics and mtouch here
<Sarvatt> so its not a synaptics bug if thats what you're hitting
<RAOF> No.
<RAOF> This is the pointer moving, rather than the menu moving.
<Sarvatt> click a menu entry in steam under wine, everything moves up to 0,0 including the menu contents
<Sarvatt> dropdown shows up at 0,0
<RAOF> Yeah, know that one.
<Sarvatt> ok so different
<Sarvatt> synaptics moving to 0,0.. do you have an accelerometer device also?
<RAOF> This is just the pointer resetting to (0,0) in the middle of touchpad movement, which is unsettling.
<Sarvatt> thats the only one i remember
<RAOF> Also interacts really poorly with gnome-shell ;)
<Sarvatt> i haven't actually used synaptics in almost a year here so if its busted i'm not sure, damn alps touchpads being in everything now
<Sarvatt> what system is it busted on? the x201s?
<RAOF> The Inspiron N4110
<RAOF> Which I'm using because (a) I was testing out whether fglrx supports hybrid on it (it doesn't) and (b) it's the fastest i5 in the house with a working harddrive.
<Sarvatt> cool they sending you more crap?
<Sarvatt> its funny the cheaper mainstream dells are using synaptics and the more expensive latitude/precisons are using alps crap
<RAOF> I don't know if it's a synaptics touchpad; it's using the synaptics DDX, though.
<RAOF> No, this is one of the two hybrid systems I got at UDS.
<Sarvatt> precise?
<RAOF> Since the T420s decided to bail on me â¹
<RAOF> Yah, precise.
<Sarvatt> actually i think sforshee made alps use synaptics in precise
<RAOF> It works, as long as you're using -rc6 :)
<Sarvatt> havent played with that yet
<RAOF> dmesg reports synaptics.
<RAOF> So I guess this has an honest to goodness touchpad in it.
<Sarvatt> wow i really need to put in a feature request for hexr now, it only lists lspci devices so touchpad doesnt show up
<RAOF> Heh.  Whoops :)
<Sarvatt> RAOF: so its an alps, there may be something screwy with sforshee's kernel drivers to make alps use synaptics thats already upstream
<Sarvatt> on that specific machine
<RAOF> It could also be the franken input ;)
<RAOF> It looks like evtest is seeing correctish numbers.
<Sarvatt> oh you're on frankenserver?
<RAOF> Yah.
<Sarvatt> very likely then :)
 * Sarvatt makes mental note to try it out in the morning
<Sarvatt> same touchpad as in the e6420 from what i can see
<Sarvatt> i haven't tried sforshee's alps driver out yet that lets it use synaptics
<RAOF> I'll give it a whirl on the e6420 too, once it's finished slurping all my data off the failing harddrive.
<Sarvatt> i'm still in oneiric land, trying to get ivb on oneiric going good before it needs to be done in a month or two
<Sarvatt> RAOF: did you get my messages about frozen synapse?
<RAOF> YEah.
<Sarvatt> i can send ya the linux client that works with the key i sent you if you want
<RAOF> Thanks.
<RAOF> I'll give it a whirl :)
<Sarvatt> or would ya rather have a steam one?
<RAOF> I like steam.  Steam is good :)
<Sarvatt> boo
<RAOF> Boo?
<Sarvatt> i only have a multiplayer key to spare for the non steam one :)
<Sarvatt> you missed the humble bundle with it!
<RAOF> I have tons of games to play :)
<RAOF> Aw, man.  This laptop's keyboard layout is *specificly* designed to make me hit "menu" instead of "control"
<Prf_Jakob> Sarvatt: do you have a list of commits that you cherry-picked for the vmware build to work against 11?
<RAOF> Sarvatt: Were you going to do a libdrm/Intel DDX update?
<RAOF> Sarvatt: Because if not, I might as well do it during 1.11 world-rebuilding.
<bryceh> cnd, wow not even a sliver of lip service that you did anything to help with upstream multitouch - http://www.phoronix.com/scan.php?page=news_item&px=MTAzMDQ
<jcristau> meh, phoronix.
<RAOF> Eh, yeah.
<bjsnider> phoronix is always right about everything
<broder> is mesa supposed fail miserably under valgrind because of some sort of deep graphics magic?
<broder> i'm seeing a lot of uninitialized values on natty in various mesa calls
<jcristau> not afaik
<jcristau> there's a lot of false positives from drm ioctls, but..
<RAOF> Piglit has a "run under valgrind" set of tests, as evidence for the "supposed to work under valgrind" hypothesis.
<broder> working on getting a test with full debug symbols, but i get lots of stuff during mutter's startup: http://paste.ubuntu.com/775784/
<jcristau> all of that is false positives, maybe except the last one
<jcristau> not completely sure about the i965 ones but you don't have symbols for that so meh
<broder> jcristau: http://paste.ubuntu.com/775793/ has symbols
<broder> all of that is during startup
<Sarvatt> RAOF: was waiting on libdrm 2.4.30 which was supposed to be pushed out awhile back so an intel-gpu-tools release could go out too but i guess thats no excuse not to do intel 2.17
<Sarvatt> broder: https://bugs.freedesktop.org/show_bug.cgi?id=35071
<ubot4> Freedesktop bug 35071 in Drivers/DRI/i965 "Valgrind warnings in _mesa_texstore_argb8888" [Enhancement,New: ]
<broder> oh, awesome. thanks
<Sarvatt> Prf_Jakob: it was just http://cgit.freedesktop.org/xorg/driver/xf86-video-vmware/commit/?h=vmware-11.1-branch&id=26845eb54a15d43f09288a87c5f74beac8fb6ec7 which caused a bad compilation on amd64 even though it was successful
<Sarvatt> that was already in a release, vmwgfx_branch was on the old 11.0.3
<Prf_Jakob> ah ok
<Sarvatt> https://launchpadlibrarian.net/79714941/buildlog_ubuntu-oneiric-amd64.xserver-xorg-video-vmware_1%3A11.0.3-2ubuntu0_FAILEDTOBUILD.txt.gz
<Prf_Jakob> Hmm I thought Thomas merged the vmwgfx_branch to master, apperently not.
<Sarvatt> yeah it was merged when i looked this afternoon
<Sarvatt> yup still merged
<Sarvatt> oh you mean the vmwgfx_branch is still on 11.0.3, sorry
<Prf_Jakob> Well we should probably kill that branch now.
<Prf_Jakob> Oh I just followed your link when I looked at log, no wonder I didn't see the merge (was on the vmware-11.1 branch)
#ubuntu-x 2011-12-20
<mok0> Hi
<mok0> In Debian, the package libglw-mesa comes from source package mesa_7.11.2-1, but in Ubuntu it comes from source package mesa-glw. What is the reason for this?
<mok0> ... mesa-glw is only at version 7.4
<mok0> and seems to be unmaintained
<tjaalton> mok0: because lesstif is in universe, and is not going in main
<mok0> tjaalton: uhm... what does lesstif have to do with it?
<tjaalton> mok0: it build-depends on lesstif2-dev
<mok0> tjaalton: so I guess mesa-glw just needs to be updated?
<jcristau> or killed
<tjaalton> ah, that's why there is mesa-glw in the first place
<mok0> It's remained at 7.4 for as long as rmadison knows about
<mok0> jcristau: nooooo
<tjaalton> because the main mesa doesn't build libglw1 for that reason
<jcristau> seriously, motif...
<mok0> tjaalton: yes
<mok0> tjaalton: lots of older apps use it... perhaps not apps in the archives, but users' apps
<tjaalton> example?
<mok0> ribbons
<jcristau> if they have their own apps they can build their own glw...
<tjaalton> google doesn't show up any useful links
<mok0> tjaalton: http://www.cbse.uab.edu/ribbons/
<mok0> had to find the link
<tjaalton> Oct 1 2006: New day, retiring from UAB, but will still maintain ribbons . 
<tjaalton> so, abandoned 5y ago
<mok0> tjaalton: it's still useful
<jcristau> mok0: also what's wrong with 7.4 glw?  it's not like anybody touched it since then
<mok0> jcristau: there is a bug in it, symbol missing from library
<tjaalton> hey, there are binaries for tru64, i should try those out
<tjaalton> :)
<mok0> jcristau: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624156
<ubot4> Debian bug 624156 in libglw1-mesa-dev "libGLw.so missing glwMDrawingAreaWidgetClass" [Important,Fixed]
<jcristau> ah yeah, remember that.
<mok0> Well, I have issues with the policy of removing libraries from the distro
<jcristau> *shrug*
<mok0> People have their own (purchased, etc) software that the want to keep using
<tjaalton> mok0: so.. looks like you did the previous uploads, and you're complaining here?
<mok0> You can't expect my memory to span over more than a few months :-)
<tjaalton> just checking the changelog was enough
<mok0> tjaalton: Actually, I'm was just wondering why the libglw1-mesa package wasn't being built from mesa 
<mok0> ... perhaps the lesstif dependency could be gotten rid of
<tjaalton> mok0: and i told you, it's also pointed out on the mesa changelog
<mok0> tjaalton: sorry
<mok0> tjaalton: I thought a bit of discussion wrt how to fix this was required
<mok0> tjaalton: community, you know
<tjaalton> mok0: it just needs an update, preferably by someone who cares enough to do the work
<mok0> tjaalton: I'll look into it
<mok0> tjaalton: although it would be much nice to build the library from mesa itself
<mok0> tjaalton: don't offhand understand why the lesstiff dependency is required by a this library
<tjaalton> mok0: because it doesn't build otherwise?
<mok0> tjaalton: could be a test program or something that could be omitted, is what I am thinking
<FernandoMiguel> evening
#ubuntu-x 2011-12-21
<cnd> RAOF, I see you pushed the x world to the staging ppa
<cnd> have you tested it at all?
<RAOF> cnd: Almost; I need to push a fixed -evdev and -wacom build.
<RAOF> cnd: Yeah; it *mostly* works.
<cnd> RAOF, what fixes are needed?
<cnd> mostly?
<RAOF> cnd: Oh, wacom is confused by input ABI >= 14 and not having those option changes, and I just messed up the evdev build :)
<cnd> ok
<RAOF> Mostly - synaptics seems to have a weird issue where it sometimes jumps to (0,0).
<cnd> I don't know if you saw it, but the XI 2.2 work is ready to be pulled into master :)
<RAOF> And Civ V under wine seems to get two sets of wildly different input streams.
<cnd> I'll be spending quite some time with synaptics soon
<RAOF> Woot!
<cnd> so I'll be sure to test it well
<RAOF> Apart from that, everything's pretty much good.
<RAOF> At least on what I've tested, which has been a couple of synaptics touchpads, a USB mouse, and the nobby bit.
<RAOF> Once the PPA has finished deleting the failed-to-build evdev and wacom sources and accepts the new ones, it'll be a full house.
<cnd> RAOF, fyi, depending on ppa deletion to work is a recipe for annoyance at the very least
<RAOF> Yeah.
<RAOF> I know.
<cnd> I think it *might* be impossible without behind-the-scenes help if the orig tarball changes
<RAOF> I've been tempted because it's worked with previous packages put up in the PPA.
<cnd> heh
<cnd> tbh, it's not a terrible thing to have high values of ubuntu#
<cnd> at least, I don't think it is :)
<cnd> I need to sleep...
<cnd> but there's code to be reviewed...
<cnd> it's all I've done the entire day pretty much
<cnd> yay, no meetings tomorrow
<cnd> which also means I don't have to get up early
<cnd> time to hit the sack
<RAOF> :)
<RAOF> Ok.  Rejected again, time to bump ubuntu# and reupload.
<cnd> RAOF, bryceh: I screwed up
<cnd> I pushed the latest upstream x11proto-input
<cnd> thinking it was all backwards compatible
<cnd> but it's not backwards compatible with what we currently have in the archive
<cnd> I'm trying to figure out how to fix this
<tjaalton> pushed where?
<cnd> precise
<tjaalton> ah
<tjaalton> so libxi et al that build-depend on it would break if they got rebuilt?
<bryceh> cnd, revert the package by uploading the previous version with a new version number
<cnd> bryceh, since x11proto-input just builds a package with two header files
<cnd> I'm going to try temporarily re-adding in the missing definitions
<tjaalton> aren't we going to update the build-depending packages anyway?
<cnd> tjaalton, eventually, everything will be updated
<cnd> it's the transition period that is bad
<tjaalton> what got removed?
<cnd> tjaalton, everything that is different between our prototype multitouch implementation and upstream
<tjaalton> cnd: ah, right
<tjaalton> so adding them back is the only solution?
<tjaalton> and then wait for the rest to migrate before dropping the old stuff
<tjaalton> again
<cnd> hmmm... adding them back won't work
<cnd> I'll just reupload with a bumped version number
<cnd> 2.1.99.4.really.2.0.2-0ubuntu1
<cnd> bryceh, does that sound alright?
<cnd> tjaalton?
<bryceh> cnd, yep
<tjaalton> cnd: so how are we going to get the new backported stuff?
<cnd> tjaalton, everything is being staged in ppa:ubuntu-x-swat/x-staging
<cnd> once everything is converted over, or at least will build without issue, we will pocket copy packages into the ubuntu archive
<tjaalton> ok so it's not going to precise before the holidays then, hence the revert?
<cnd> correct
<cnd> here's the todo list:
<tjaalton> I really doubt we'd rebuild the drivers or libs, it's all x-swat stuff anyway :)
<tjaalton> i mean before the new stack
<cnd> get evdev with multitouch support built (trivial)
<cnd> get synaptics with multitouch support built (non-trivial, nothing upstream yet)
<cnd> make sure utouch-geis builds (should be trivial)
<cnd> get libxi with multitouch support built (trivial)
<tjaalton> sounds like we might get things sorted at the rally?
<cnd> port qt multitouch patch to new xi implementation (non-trivial, but shouldn't be too hard/long)
<cnd> test to ensure we didn't break anything :)
<cnd> which includes testing binary drivers like nvidia and fglrx to ensure we didn't break ABI in the input backport
<cnd> but I think that's it
<tjaalton> sure, seems fine
<cnd> we also don't have to wait for synaptics, evdev, and libxi
<cnd> but utouch-geis and qt are blockers
<RAOF> tjaalton: If you're desparate to try, ppa:ubuntu-x-swat/x-staging now has a complete set of 1.11 (with 1.12's input stack gloriously backported by Chase).
#ubuntu-x 2011-12-22
<cnd> bryceh, have you and RAOF looked into gtest?
<cnd> I'm looking at your unit tests for xrandr-utils
<RAOF> Which one is gtest?
<cnd> RAOF, google-test
<cnd> I'm in love with it
<RAOF> Ah, ok.  That one.
<cnd> just thought I'd mention it
<RAOF> I'm not really familiar with it.  What does it do to make you fall in love with it?
<cnd> it's based on c++, which means test environments, fixtures, and such can all be managed in a hierarchical way
<cnd> and you don't have to write a main() or register any test cases
 * RAOF sees that it's written in C++, which may result in madness.
<cnd> RAOF, you can check out xorg-gtest, which we posted to xorg-devel today
<RAOF> Hm.  How does automatic test-case detection work in a language with no introspection?
<cnd> we're using it in utouch-frame
<cnd> RAOF, magic?
<RAOF> Aieee.
<cnd> RAOF, check out http://people.freedesktop.org/~cndougla/xorg-gtest/
<cnd> look at the example
<cnd> that's literally all you need to code if you want to have something that builds and tests
<cnd> there's no other code that has to be written
<RAOF> That looks like something that could indeed be useful.
<RAOF> We should really get rid of the "need to be root" bit, there.
<cnd> RAOF, I don't think it's possible if you want to fire up an Xorg server
<RAOF> It should be possible with the dummy drivers, but it isn't at the moment.
<cnd> because any config file you specify must be in /etc/X11 or /usr/share/X11/xorg.conf.d, *unless* you are root
<cnd> yeah, that's true
<cnd> it still doesn't help us for the touch team because we need to use uinput to replay device events
<cnd> which requires root to interact with the kernel
<cnd> but I'm not really suggesting that xorg-gtest would be worth your while as-is
<cnd> because the dummy video driver probably won't get you very far with xrandr
<cnd> but gtest in general is going to be much better than rolling your own
<cnd> I was skeptical at how much better it could make my life, but I really love it after having developed tests and frameworks with it
<RAOF> Yeah, I'm a big fan of not rolling my own.
<RAOF> Actually, aren't there patches to enable xrandr on the dummy driver?
<cnd> I wouldn't know
<cnd> if there were, then xorg-gtest would be perfect :)
<RAOF> The documentation there also suggests that it can hook you up with an existing X11 server, which would be the next best thing.
<cnd> yeah
<cnd> by default when you run tests with --no-dummy-server it will use $DISPLAY
<cnd> and I suppose --no-dummy-server can be used when not root
<cnd> anyways, time to eat dinner and stop working!
<cnd> back tomorrow!
<RAOF> :)
<bryceh> cnd, interesting.  I'm trying to keep xrandr-utils close to X standard practices; what I've got in there parallels the xserver test suite
<bryceh> I like C++ myself but know keithp is not a fan.
<bryceh> heya RAOF, btw I tossed the xrandr-utils patches up on xorg-devel@ a couple hours ago; thanks for your review earlier, I took out that perl test.
<RAOF> bryceh: Sweet; I'll throw some reviewed-by tags your way.
<bryceh> RAOF, thanks!
<bryceh> I had another chance today to learn just how much git rebase kicks ass
<RAOF> Sometimes your own :)
<tjaalton> RAOF: cool, I'll give it a go today :)
<RAOF> tjaalton: It seems to do weird things to wine; I'll be interested to see if you also notice that.
<tjaalton> after going through the xmas shopping mayhem..
<tjaalton> ah, does wine work on amd64 currently?
<RAOF> You can't install ia32-libs-multiarch, but equivs will let you install ia32-libs which will let you install wine.  Then it's just a matter of hunting down libfoo:i386 :)
<tjaalton> ugh, ok
<bryceh> RAOF, I stuck the ppa on a radeon box.  Boots to the ubuntu logo, shows a mouse cursor, but no greeter
<RAOF> Huh.  Odd.
<RAOF> Anything interesting in the logs?
<bryceh> bryce@dorset:~$ apt-cache policy lightdm-gtk-greeter 
<bryceh> lightdm-gtk-greeter:
<bryceh>   Installed: (none)
<bryceh>   Candidate: 1.0.6-0ubuntu4
<RAOF> Heh.
<RAOF> Oh, no.  You're after unity-greeter rather than lightdm-gtk-greeter.
<bryceh> ah right  $ apt-cache policy unity-greeter
<bryceh> unity-greeter:
<bryceh>   Installed: 0.1.1-0ubuntu1
<bryceh>   Candidate: 0.1.1-0ubuntu1
<bryceh> skimming through logs... nothing interesting so far
<cnd> bryceh, are you becoming a git convert?
<bryceh> root@dorset:/var/log/lightdm# more x-0-greeter.log 
<bryceh> (unity-greeter:1864): Gtk-WARNING **: cannot open display: :0
<bryceh> ah, potentially I had fglrx installed
<RAOF> Ah.  I haven't uploaded an fglrx to the ppa.
<bryceh> hmm, no evidence so far
<RAOF> There's a new -ati in there (I think); I may have bollocksed that up.
<bryceh> xserver-xorg-video-ati:
<bryceh>   Installed: 1:6.14.99~git20111219.aacbd629-0ubuntu1
<bryceh>   Candidate: 1:6.14.99~git20111219.aacbd629-0ubuntu1
<RAOF> Yeah, that's a newer snapshot than in the main archive.
<RAOF> Which should be fine.  :)
<bryceh> yeah it feels like X is basically ok, it's just the greeter is refusing to do its thing
<bryceh> actually when I restart lightdm I see a brief glimpse of my desktop
<bryceh> then it comes back to a black screen with movable mouse cursor.
<bryceh> switching to vt1 and back to vt7 gives me the console text with mouse cursor.  maybe something's not painting
<bryceh> [  914.068497] lightdm[915]: segfault at aaaaaaae ip 08051ee8 sp bff44560 error 4 in lightdm[8048000+28000]
<bryceh> [  914.070871] init: lightdm main process (915) killed by SEGV signal
<bryceh> ooh
<bryceh> hmm that might be irrelevant though
<bryceh> root@dorset:/var/log# ps aux | grep lightdm
<bryceh> root      2684  0.0  0.1  40844  3540 ?        Ssl  22:24   0:00 lightdm
<bryceh> root      2688  0.6  1.8  63240 38320 tty7     Ss+  22:24   0:01 /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
<bryceh> ah the lightdm segfault occurs when restarting the service
<bryceh> Dec 21 22:30:11 dorset kernel: [ 1274.512212] type=1400 audit(1324535411.385:27): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/telepathy/mission-control-5" name="/home/bryce/.cache/dconf/user" pid=3445 comm="mission-control" requested_mask="rwc" denied_mask="rwc" fsuid=1000 ouid=1000
<bryceh> wonder if that's relevant
<RAOF> That's empathy being denied access to dconf; I should report that bug.
<RAOF> It does, however, indicate that you appear to have made it all the way through to your session.
<bryceh> yeah
<bryceh> this is what is printed to syslog when I do a sudo service lightdm restart:
<bryceh> http://pastebin.ubuntu.com/778322/
<bryceh> intriguing... ppa-purge of the ppa results in working X session.
<bryceh> let's try again
<bryceh> hmm, apport caught something... crash in "fts.py"
<bryceh> part of zeitgeist
<bryceh> guess coincidental
<bryceh> lp #907661
<ubot4> Launchpad bug 907661 in zeitgeist (Ubuntu) "fts.py crashed with DatabaseLockError in __init__(): Unable to get write lock on /home/bryce/.local/share/zeitgeist/bb.fts.index: already locked (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/907661
<cnd> RAOF, bryceh, fyi, I plan on pushing mt versions of xorg-server and evdev to the x-staging ppa tomorrow
<RAOF> cnd: Awesomesauce.
<cnd> I was hoping keithp would pull Peter's mt branch today, but I can cherry-pick it as-is if he doesn't get to it
<cnd> maybe I'll look into forward porting the qt multitouch patch after that :)
<cnd> anyways, bed time for me
<bryceh> cnd, sounds good
<bryceh> I'm running the ppa on a devoted test box, I can update and test whatever whenever
<bryceh> hmm this is weird, after ppa-purging and re-adding, it doesn't want to install the new X bits
<RAOF> Oh!  Are you trying to run Unity?  It still won't start without mt/gestures.
<bryceh> RAOF, heh ok that'd do it
<cnd> RAOF, that hasn't been fixed yet?
<bryceh> RAOF, ok, I assumed it just required the new input stack.  I take it cnd's upload tomorrow is required then?
<cnd> grrr...
<cnd> bryceh, it's a unity bug
<bryceh> cnd, mm
<cnd> there was a "fix" for it that was obviously wrong on further inspection
<cnd> a week ago I assigned it back to the original fixer, hoping they would resolve it
<bryceh> ok, and I have auto-login enabled so it just logs me into unity automatically; presumably if I switch that off I could go into unity2d or classic
<cnd> maybe they've been on vacation?
<bryceh> at least I've learned ppa-purge isn't reversible with apt-add-repository (as it probably should be)
<cnd> bryceh, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/860707
<ubot4> Launchpad bug 860707 in unity (Ubuntu) (and 1 other project) "Unity crashes when started in an environment without utouch support (affects: 58) (dups: 2) (heat: 270)" [High,Triaged]
<cnd> I might have to fix that myself
 * cnd tries to stay away from unity development
<bryceh> they've probably all been repurposed into cloud developers or something
<bryceh> ok yep switching to gnome classic (no effects) boots in fine
<tjaalton> cnd: btw, debian wants multitouch soon, so there's no need for our own upstream branches, could've used -experimental there
<tjaalton> but it's no biggie
<tjaalton> oh unity still busted? maybe i won't test the ppa afterall :/
<bryceh> tjaalton, definitely busted
<bryceh> tjaalton, classic seems to work
<tjaalton> bryceh: yeah, i'll hold off then.. though it's just my laptop to break, hmm
<bryceh> *nod*
<FernandoMiguel> damn.... my touchpad is a MESS
<cnd> tjaalton, were people getting upset about me pushing ubuntu specific packages?
<cnd> KiBi seems a bit miffed that I would do that
<tjaalton> cnd: yeah we discussed it on debian-x the other day, and told that we didn't know what their plans were and forgot to ask. no harm done :)
<cnd> I just chatted with him on #debian-x, I think he's ok once I mentioned this is a one-time, time-sensitive deal
<cnd> I'm trying to get things into the ppa before I go on vacation
<tjaalton> yeah he's cool
<tjaalton> Sarvatt told him that we (you) were on a deadline
<cnd> I just pushed a fix for the utouch-unity crash: https://code.launchpad.net/~chasedouglas/unity/utouch-crash/+merge/86727
<cnd> hopefully it is reviewed and uploaded soon
<cnd> but I don't know if it will be before the holiday break
<FernandoMiguel> rebooting seems to have fixed my touchpad probs.... for now
<cnd> I decided to create a unity package with a fix for the utouch issue
<cnd> after I see that it builds, I'll push it to the staging ppa
<tjaalton> cnd: oh great, thanks
<cnd> it's now uploaded
<cnd> I haven't had a chance to test it yet
<cnd> I'm just now updating behemoth to precise
<cnd> but it's a simple fix, so it should work
<tjaalton> cnd: hmm don't see unity on the ppa yet?
<cnd> tjaalton, it probably hasn't built yet
<tjaalton> cnd: ah, right..
<tjaalton> start in 23min
<tjaalton> i can wait :)
<ricotz> cnd, hi, you probably want to put fglrx in there too
<cnd> ricotz, RAOF (and maybe others) are handling anything non-input related
<cnd> I don't really know about anything outside of input :)
<ricotz> alright ;)
<tjaalton> ricotz: the version in precise should already handle the new abi
<tjaalton> unless it needs a rebuild to fix the deps
<ricotz> tjaalton, yes, just a rebuild is needed
<ricotz> but an update would be nice too since there is a newer upstream
<ricotz> same goes for nvidia
<tjaalton> tseliot will handle updates
<tjaalton> in january :)
<tjaalton> ie. before those are pushed to precise
<ricotz> alright
<cnd> tjaalton, unity is built
<cnd> have you had a chance to test?
<tjaalton> cnd: upgrading..
<cnd> tjaalton, there *may* be an issue with evdev in the ppa right now
<cnd> but I think it should work if you aren't using a multitouch device
<cnd> it needs to be rebuilt after xorg-server is built in the ppa
<tjaalton> seems to work fine otherwise, but compiz takes all the cpu
<cnd> I get:
<cnd> Xorg: symbol lookup error: /usr/lib/xorg/modules/input/evdev_drv.so: undefined symbol: InitTouchClassDeviceStruct
<cnd> which is what I expect
<tjaalton> huh, works here
<tjaalton> unity-2d loads, apart from the dock
<cnd> ok
<tjaalton> ah, unity-2d-launcher taking 100% cpu :)
<RAOF> tjaalton: Yeah, unity-2d-launcher *also* hates missing multitouch/gestures it seems :)
<tjaalton> at least the upgrade itself was rather uneventful
<RAOF> ricotz: There's already a build on nvidia-current in there; there will be fglrx & the rest of the drivers in there before they land in precise.
<ricotz> RAOF, hi, yeah i figured that, just didnt know when it will be moved
<RAOF> Not before Christmas :)
<ricotz> yeah no more breaks for this year! :)
<cnd> once evdev rebuilds in the ppa it should be all ready for testing
<cnd> and it should have multitouch for touchscreens
<cnd> \o/
<bryceh> cnd, sweet, ping us once it's ready
<cnd> tjaalton, unity-2d probably crashes because qt's multitouch code is now incompatible with the upstream XI implementation
<cnd> I'll probably upload a new qt with the patch commented out
<tjaalton> i'll just wait for evdev though :)
<tjaalton> to build
<tjaalton> though maybe I'll just check it in the morning
<tjaalton> oh, building..
<tjaalton> cnd: ok so the same still happens with these, will check in the morning if there's a new qt available :)
#ubuntu-x 2011-12-23
<cnd> qt may be easier than I thought to forward port
<cnd> I'm still not crazy about the patch, it's rather hairy due to a bunch of #ifdefs
<cnd> but there really isn't that much that changed between the two implementations
<cnd> and the bits that did change are easy to fix
 * cnd is running a test build of qt on behemoth
<RAOF> Yay behemoth!
<RAOF> At least that quad core monstrosity is good for something :)
<cnd> when I upgraded behemoth this morning, it installed a bunch of i386 packages
<cnd> I have no idea why
<RAOF> Either breakage, or dependencies that dropped out of ia32-libs?
<RAOF> apt can now sometimes do that if something's uninstallable on amd64, but a multi-arch: foreign alternative is installable.
<cnd> dunno
<cnd> I've done a lot to behemoth
<cnd> and I may have only ever wiped it once since I've had it
<cnd> so there's bound to be a lot of cruft
<cnd> on the plus side, I've got qt and multitouch working!
<cnd> it was much easier than I thought it would be
<RAOF> Sweet!  That was fast.
<RAOF> Hows about a synaptics that doesn't reset to (0,0) at infuriatingly frequent, yet seemingly random, intervals? :)
<cnd> I'll be pushing it in a few mins
<RAOF> Or, even better, do you see that behaviour?
<cnd> heh, you'll have to wait a bit on that
<cnd> I don't even have a rebuilt synaptics installed yet
<cnd> and because I partially upgraded qt on my system to test
<RAOF> You haven't upgraded from the staging PPA?
<cnd> it would be easier for me to just try it tomorrow
<cnd> apt-get is useless if it thinks your packages are in a broken state
<cnd> it needs a "I know what I'm doing, just install these other packages please" option
<RAOF> Yeah, it's sucky that way.
<RAOF> The ppa is, at least, fully installable.
<cnd> with the updated qt, unity-2d starts up
<cnd> though I'm missing the dock
<cnd> any ideas why that would be?
<RAOF> No idea - I *thought* that was missing geis, because that's what would happen with the non-multitouch frankenserver.
<RAOF> Is unity-2d-launcher spinning at 100% cpu still?
<cnd> well, geis still won't work with this multitouch frankenserver
<cnd> oh, it is
<cnd> compiz does that too
<cnd> so unity 3d is useless
<cnd> and unity 2d's launcher is useless
<cnd> gnome classic with effects is also useless due to the same compiz issue
<RAOF> GNOME Do, however, LIVES ON!
<cnd> heh
<cnd> I'm on vacation now though
<cnd> I'll be back on the 3rd
<RAOF> Like essentially everyone else :)
<cnd> I'm just uploading qt, and I'll send out an email to ubuntu-devel and ubuntu-x about the x-staging ppa
<RAOF> Doing anything interesting?
<cnd> not much
<RAOF> Excellent!
<cnd> heh
<cnd> playing zelda skyward sword I guess
<RAOF> That can be the most fun.
<cnd> yeah
<cnd> less stress
<cnd> urgh, the qt4-x11 tarball is huge
<RAOF> It's ~200MB, isn't it?
<RAOF> Don't try building it on a tmpfs :)
<RAOF> I'll be doing something similar, but with jml's bucks party, and running a one-shot D&D campaign while jml's here thrown into the middle :)
<cnd> 215 MB
<cnd> I have no clue what any of that is
<cnd> I do know what a jml is :)
<cnd> but the rest...
<RAOF> Buck's party not familiar to you?
<RAOF> I mean, it's not like *I* had one, but I thought they were pretty universal across UK/US-derived cultures.
<cnd> no, I have no clue what a "Buck's party" is
<cnd> oh, bachelor party!
<cnd> yeah, I got it
<RAOF> Perhaps more commonly known as a "buck's night", to go with the feminine "hen's night". :)
<cnd> yeah, those terms didn't make it across the atlantic
<cnd> we have bachelor and bachelorette parties
<cnd> don't know if I spelled the latter correctly
<RAOF> Heh.
<cnd> RAOF, I'm getting this error: File qt4-x11_4.7.4.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents.
<cnd> when I try to dput to the ppa
<cnd> I tried downloading the exact orig tarball from precise
<cnd> and then rebuilt the source package
<cnd> it didn't even upload an orig.tar.gz, since the archive already has it
<cnd> any ideas?
<bjsnider> do -S -sd
<cnd> bjsnider, what does that do?
<bjsnider> it uploads without uploading the tarball
<bjsnider> it assumes the tarball is already there
<bjsnider> debuild -S -sd
<cnd> yeah, the second time it didn't upload the tarball
<cnd> the first time it did
 * cnd wonders if the tarball is stuck in the ppa
<bjsnider> what happened the second time?
<cnd> same error came back
<bjsnider> impossible
<cnd> I have the emails :)
<bjsnider> you did an -sd instead of an -sa, and dput the changes file, and got that error?
<cnd> yeah
<bjsnider> and you need to do the -sd against the tarball it's talking about, in precise, not your own tarball
<cnd> correct
<cnd> I downloaded the orig tarball from launchpad from the precise package overview page to be sure
<bjsnider> that's one i have't seen before
<cnd> I've seen weird issues like this before
<cnd> I'm guessing it's a bug somewhere in soyuz, and someone may need to manually delete the tarball from the servers
<bjsnider> did you ask in #launchpad?
<cnd> I am right now :)
<bjsnider> you could do a bit of trickery and add +0 to the version number, thus creating a unique tarball
<bjsnider> but only if it's being superseded by a newer version soon enough
<cnd> yeah, I'm not sure that will happen
<cnd> ever in precise
<cnd> bjsnider, it was still building against the bad tarball in ../build-area
<cnd> I had only replaced the tarball in ../
<bjsnider> so it worked?
<cnd> still building
<cnd> uploading now
<cnd> ok, it worked finally
<bjsnider> cool
<cnd> I don't like how bzr bd copies the orig tarball into the build-area
<cnd> I can kinda see why they do it
<cnd> but I think it just makes things more confusing when there are issues
<cnd> they could just symlink and be done with it
<cnd> anyways, I'm done
<cnd> I'm off for the holidays, but I'll troll, as always :)
<tjaalton> oh new qt didn't fix compiz
<tjaalton> let's install gnome-shell then :)
<tjaalton> yeah it works
<ricotz> cnd, hi
<cnd> hi
<cnd> tjaalton, new qt isn't finished building yet
<cnd> but yeah, compiz seems borked
<ricotz> cnd, the inputstack of xserver git master and the 1.11+input2.2 should be "indentical", right?
<cnd> that's the theory :)
<ricotz> cnd, could look at this https://launchpadlibrarian.net/88180194/buildlog_ubuntu-precise-amd64.xf86-input-wacom_1%3A0.12.0-0ubuntu3_FAILEDTOBUILD.txt.gz
<cnd> it depends on whether you count the new InputOption API
<cnd> yeah...
<tjaalton> ricotz: wacom hasn't been ported
<ricotz> cnd, ah ok
<cnd> that input option api was not backported from 1.12
<ricotz> tjaalton, wacom worked fine with abi 15
<cnd> I couldn't be sure that it would not cause ABI/API issues with other drivers
<ricotz> cnd, i see
<cnd> the whole option parsing API changed, IIRC
<cnd> not just for input modules
<ricotz> cnd, wouldnt it be better the pull this in too rather than creating a "new" abi which isnt abi 16?
<cnd> ricotz, we can't modify any ABI that would affect video drivers
<cnd> i.e. the 1.11 nvidia and fglrx drivers must still work
<cnd> I'm worried that the new option abi would conflict
<ricotz> alright
<ricotz> but the reported abi will be 16?
<cnd> and, it's a little outside of the scope of what we really need to backport
<cnd> yeah
<ricotz> ok
<cnd> in wacom and one other driver (I think synaptics), we might have to dance around the input abi
<ricotz> synaptic works
<ricotz> https://launchpad.net/~ricotz/+archive/unstable/+packages
<ricotz> i havent rebuild them all yet
<cnd> yeah, it might not be forward ported yet
<tjaalton> ricotz: wacom d54d936146fa58fb10a1b6839e1413671f96f86e perhaps?
<ricotz> tjaalton, could be
<ricotz> probably all commits since 0.12 would be needed
<tjaalton> oh strong work dude, removed the wrong disk from a live system :P
<tjaalton> ah, no i didn't, thought the one would've been wd blue instead of black..
#ubuntu-x 2011-12-24
<Fernando_xtmas> morning
<cnd> RAOF, Sarvatt, bryceh: unity utouch fix has been merged
#ubuntu-x 2012-12-17
<mlankhorst> morning
<mlankhorst> bjsnider: I still saw someone using twm in 2008, so why not :p
<bjsnider> mlankhorst, are you around at the moment?
<mlankhorst> yeah?
<bjsnider> have you got any matroska files handy?
<bjsnider> .mkv
<mlankhorst> what for?
<bjsnider> i need someone to test mkvtoolnix-gui
<bjsnider> on my system it is not on the open with list for the files it creates
<bjsnider> using nautilus anyway
<mlankhorst> hm dont see any mkv locally
<bjsnider> you can install the app, open a video with it and create one
<bjsnider> it will just switch containers from avi to mkv
<mlankhorst> does it work for mp4 videos too?
<bjsnider> yes
<bjsnider> it will switch that container
<mlankhorst> ok then
<bjsnider> just add the file, and then click start muxing
<bjsnider> afterwards, right click on the mkv
<mlankhorst> what release?
<bjsnider> i'm assuming you're using gnome with either quantal or raring
<bjsnider> this problem started with quantal
<mlankhorst> nope, kde + precise (quantal xserver)
<bjsnider> not sure how kde handles mimetypes and whatnot
<bjsnider> anyway, forget it. thanks anyway
<mlankhorst> laptop has raring though, or whatever I tell it to boot through nfs
<ricotz> bjsnider, mkvmerge seems to work fine here
<ricotz> 5.9.0 on raring
<tjaalton> updated -intel to 2.20.16
<bjsnider> ricotz, works fine in the sense that it is associated with mkv files?
<ricotz> bjsnider, ah, i missed that part, and no, it isnt listed in "open with" here
<bjsnider> oh, good
<bjsnider> i was beginning to think bad thoughts about my system
<ricotz> i though the app itself isnt working for you
<bjsnider> so it isn't associated with the very files it creates
<ricotz> thought
<bjsnider> i wrote mosu about this and he says he isn't aware of the issue
<bjsnider> one thing i noticed is the desktop file is not named after the package
<ricotz> there is no need for matching names
<bjsnider> ok
<ricotz> MimeType=application/x-mmg-settings;video/x-matroska;audio/x-matroska;
<bjsnider> those are the correct mimetypes
<ricotz> interestingly it doesnt contain "application/x-matroska"
<ricotz> shouldnt be a problem
<Sarvatt> bjsnider: like http://ubuntuone.com/0jMspt3dTZiT4AiAjjmYhW ? quantal
<bjsnider> yeah
<bjsnider> that's quantal?
<Sarvatt> yup
<bjsnider> using lightdm>
<bjsnider> ?
<Sarvatt> yeah just a standard unity session, nothing out of the ordinary on the desktop side
<bjsnider> i'm using gdm, so that's one difference
<bjsnider> i don't necessarily see how that would affect anything
<Sarvatt> and ppa gnome packages? :P
<bjsnider> yeah
<bjsnider> Sarvatt, when you took that screenshot, which version of nautilus was that?
<bjsnider> i just mean major and minor
<bjsnider> i'm assuming it was pre3.6
<Sarvatt> 1:3.5.90.really.3.4.2-0ubuntu4
<Sarvatt> yep 3.4.2
<bjsnider> maybe that's it
<bjsnider> maybe they made some changes in nautilus 3.6
#ubuntu-x 2012-12-18
<bjsnider> nautilus 3.6 is definitely the cause of that issue
<Takyoji> Any way to get a somewhat old AGP card working? It's some NVIDIA chipset, lspci says 'NVIDIA Corporation NV11 [GeForce2 MX/MX 400]'. I know it's not amazing, but I assume it would be better than the Intel integrated graphics chipset.
<Takyoji> There's no options in Additional Drivers, and I'm not sure if nouveau covers the chipset
<Takyoji> or perhaps the chipset is older than the computer itself..
<hyperair> i don't think it covers something that old.
<hyperair> and honestly speaking, i think my sandy bridge outstrips my nvidia geforce4 mx
<Sarvatt> 12.04 with nvidia-96 *might* work, not sure if an nvidia-96 that works with 12.04 was ever uploaded though but one exists
<Sarvatt> and yeah so many intel chipsets are faster than that thing, but if you have agp its not one that is :)
<hyperair> Sarvatt: hang on, are you saying that ancient AGP chipsets are faster than intel's newer chipsets?
<Sarvatt> opposite, if he has an agp capable one and intel is an option its not an intel thats faster :)
 * hyperair is having trouble parsing that.
<hyperair> if he has an agp capable one, and intel is an option, then intel isn't going to be faster?
<hyperair> i.e. agp is going to be faster?
<Sarvatt> yep
<hyperair> but that's not opposite of what i said..
<bjsnider> nv would work
<bjsnider> if he has a board with agp graphics he probably has a very old intel chip too
<bjsnider> since it's been 6+ years since agp slots have been on boards
<Takyoji> I've actually tried installing nvidia-96, but there's broken dependencies
<Takyoji> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/948053
<ubottu> Ubuntu bug 948053 in nvidia-graphics-drivers-96 (Ubuntu Precise) "nvidia-173 and nvidia-96 uninstallable on Precise" [Medium,Confirmed]
<bjsnider> Takyoji, there's a 96 in this ppa if you want to try it: https://launchpad.net/~mati75/+archive/lubuntu
<Sarvatt> wow nvidia-96 that works with 12.04 never got uploaded? glad theres a ppa for that at least
<tjaalton> yeah that should get uploaded..
<Sarvatt> there must be bugs opened for 6+ months now after it came out
<Sarvatt> wish nvidia* wasn't something noone else can touch :)
<tjaalton> well, if the packaging is on github it shouldn't be that hard to create a branch somewhere tseliot can pull later from
<Sarvatt> then again theres no chance alberto will feed packaging changes upstream for the earlier packages so should be nothing to complain about, i'll bug you tomorrow to sponsor an SRU tjaalton if thats ok
<tjaalton> sure
<Sarvatt> need to find the bugs, i know i saw some about 96 not working in the past
<Sarvatt> and fill out the SRU paperwork
<Sarvatt> there was a 96 compatible with xserver 1.12 in june or july
<tjaalton> september, according to the bug
<Sarvatt> yeah 9/4/12 6:02:00 PM, found the bug?
<tjaalton> the one above, it's for both -96 & -173
<Sarvatt> (us date notation)
<tjaalton> Takyoji: do you have a 32 or 64bit installation?
<tjaalton> oh well, uploaded to the queue, though I don't expect anyone to push it forward before january
<bjsnider> ricotz, found out what the problem was with mkvmerge. the desktop file is being parsed with greater scrutiny in nautilus 3.6
<Laibsch> My netbook with intel chipset ran into a regression when updating from Ubuntu Lucid to Precise: https://bugs.launchpad.net/bugs/1087535
<ubottu> Ubuntu bug 1087535 in xserver-xorg-video-intel (Ubuntu) "[i915] [regression] Xorg excessive use of CPU (after update from lucid to precise)" [Undecided,New]
<Laibsch> After an uptime of about 12 hours, X consumes 100% CPU.  I came here to ask how I can go about trying to figure out what is causing this issue.
<Laibsch> I'm looking for help in triaging this bug.
<tjaalton> mlankhorst: what updates do mesa/-intel need for haswell? AIUI quantal should already have all it needs
<tjaalton> (re: bug 1085245)
<ubottu> bug 1085245 in xserver-xorg-video-intel (Ubuntu Quantal) "[Quantal] Include support for Haswell hardware" [Undecided,New] https://launchpad.net/bugs/1085245
<ricotz> bjsnider, ah so the problem might be "InitialPreference=-5", making it invalid?
<bjsnider> no
<bjsnider> i'm going to submit a bug and a fix to get it in the record in case it happens for any other desktop files there'll be a paper trail
<mlankhorst> tjaalton: 20.12 + 9.0.1 I thought was said, but I'll upload tomorrow
<bjsnider> ricotz, so this is from the bug i submitted: As of Nautilus 3.6, desktop files EXEC field require field codes %U, for URL, or %F, for file, or the desktop file doesn't associate the app to its mimetypes.
<tjaalton> ah, bugfixes
<tjaalton> mlankhorst: ^ :)
<tjaalton> oh Sarvatt closed it already
<ricotz> bjsnider, ah interesting
<bjsnider> i figure there might be more desktop files like this so i got it on the record in case the question comes up
<bjsnider> luckily cosimoc was around to pass along the info
<ricotz> good :)
<bjsnider> bryce, do you want the 310 blob to go into x-updates?
<bryce> bjsnider, yeah probably a good idea.  Seems to have proven sufficiently stable (at least, works fine for me).
<bjsnider> it does exclude anything prior to the geforce 8 for the first time
<bjsnider> so the 5, 6 and 7 users will upgrade and it won't work
<bryce> bjsnider, ah good point forgot about that.
<bryce> bjsnider, guess we'd want an nvidia-304 package to deal with that
<bryce> otoh introducing a regression to users, probably a bad thing
<bjsnider> modifying jockey though
<bjsnider> so now you need a new jockey in the ppa
<bryce> hrm
<bjsnider> is that in quantal right now?
<bjsnider> nvidia-304?
<bryce> bjsnider, no, don't think it's even in raring yet?
<bjsnider> well, it's a tricky issue
<bryce> bjsnider, so...  I think you're convincing me to leave nvidia-current alone in x-updates; we have the experimental package for those that really want the -310 improvements
<bjsnider> on the other hand it's a ppa and nobody's forced to use it
<bryce> bjsnider, true but we do promise folks that we'll try to keep x-updates stable; since we know this update would break support on older cards we'd not be honoring that promise.
<bryce> mlankhorst, thanks for working on #1043513 - do you have further ideas on the patch?  Shall I assign it your way?
<mlankhorst> waiting on response first
<bryce> ok
<bryce> mlankhorst, should #1084960 be moved to the kernel or is that something that should stay against nouveau?
<bryce> big #1084960
<bryce> bug #1084960
<ubottu> bug 1084960 in xserver-xorg-video-nouveau (Ubuntu) "Resume from Standby mode doesn't work with Nouveau on Geforce GT430" [Undecided,Confirmed] https://launchpad.net/bugs/1084960
<mlankhorst> bryce: I don' t think kernel team will care, so all nouveau related bugs against nouveau would be ok
<mlankhorst> it's on my todo list, see if i can get suspend working on fermi :-)
<bryce> mlankhorst, alrighty
#ubuntu-x 2012-12-19
<Sarvatt> mlankhorst: dont you love having upload permissions now, you get to be forced to be a patch pilot :)
<mlankhorst> morning
<tjaalton> stupid nautilus/rhythmbox mounted a cd 17 times
<tjaalton> well, tried
<mlankhorst> well my productivity today has been negative, evoked a crash on radeon, and glad about that. :-)
<Laibsch1> My netbook with intel chipset ran into a regression when updating from Ubuntu Lucid to Precise: https://bugs.launchpad.net/bugs/1087535
<ubottu> Ubuntu bug 1087535 in xserver-xorg-video-intel (Ubuntu) "[i915] [regression] Xorg excessive use of CPU (after update from lucid to precise)" [Undecided,New]
<Laibsch1> After an uptime of about 12 hours, X consumes 100% CPU.  I came here to for help to triage this issue.
<Laibsch> brb
#ubuntu-x 2012-12-20
<tjaalton> uh, no omap blobs for quantal?
<tjaalton> not even on the tiomap-dev ppa
<tjaalton> i need to run some cairo benchmarks on the panda..
<mlankhorst> are you sure?
<mlankhorst> powervr4 should be there
<tjaalton> bah
<tjaalton> it's not on the _release_ ppa
<tjaalton> but the trunk one
<tjaalton> oh well, too late now :)
<mlankhorst> ah, I still have my panda on precise because of lack of video acceleration on quantal
#ubuntu-x 2012-12-21
<Takyoji> bjsnider, I've added the PPA for the nvidia-96 package that you've recommended, and updated the sources, but it still seems to not be able to install nvidia-96 due to dependency issues.
<bjsnider> what does it say?
<Takyoji> The following packages have unmet dependencies:
<Takyoji>  nvidia-96 : Depends: xorg-video-abi-10 but it is not installable
<Takyoji> I've used the ppa:mati75/nvidia-96 repository
<bjsnider> the ppa is ppa:mati75/lubuntu
<bjsnider> sudo add-apt-repository ppa:mati75/lubuntu
<Takyoji> Still same error
<Takyoji> sudo add-apt-repository ppa:mati75/lubuntu; sudo apt-get update; sudo apt-get install nvidia-96
<Takyoji> 'nvidia-96 : Depends: xorg-video-abi-10 but it is not installable'
<Sarvatt> errr, isnt it in precise-proposed now?
<Sarvatt> tjaalton uploaded it the other night when it was first brought up
<Sarvatt> xserver video abi 10 is ancient
<Sarvatt> probably got binary copied to newer releases in a ppa there
<Sarvatt> might be stuck in NEW..
<Sarvatt> i dont see it on https://lists.ubuntu.com/archives/precise-changes/2012-December/date.html yet
<bjsnider> it's really easy to rebuild it though
<bjsnider> he's on precise?
<Takyoji> Correct, 32-bit
<bjsnider> what the
<bjsnider> this ppa has stuff from debian, not ubuntu
<bjsnider> the packaging is totally different. so you should steer clear of it i guess
<bjsnider> i don't know why people in that bug report were talking about using this ppa being the solution to the problem
<bjsnider> it's just the start of another problem
#ubuntu-x 2012-12-22
<mlankhorst>  
<mlankhorst> oops, night
<Milos_SD> hi guys
<Milos_SD> can someone help me get 313.09 nvidia module to compile on 3.8-rc1 kernel ?
<Milos_SD> this is the make.log with errors: http://pastebin.com/F30rJLmC
#ubuntu-x 2012-12-23
<bandit-led> any ideas on a time line for a working nvidia 313 for 3.8rc1 or what i need to do to get it working?
#ubuntu-x 2013-12-17
<RAOF> mlankhorst: Oh, hai. Do we plan on using Xserver 1.15 this cycle?
<tjaalton> we'd like to
<mlankhorst> RAOF: yes
<RAOF> Good, good.
<RAOF> I'll take this opportunity to rebase vladmir-upstreaming on master then.
<mlankhorst> was working just fine, except some damage change
<mlankhorst> but really, fix the mir api to not require threads
<mlankhorst> that reduces code of vladmir in half
<mlankhorst> please
<RAOF> And makes the plymouth frontend vastly easier.
<mlankhorst> indeed
<mlankhorst> so do that first :P
<RAOF> I hear your pleas :)
<tjaalton> vladmir?
<mlankhorst> xmir
<RAOF> But with a cooler name.
<RAOF> Maybe I should change the name of the module, too :)
<tjaalton> ok :)
<RAOF> mlankhorst: An event-loop driven API might have to wait for my ipc-generator project I'm thinking of working on over the holidays.
<mlankhorst> lol
<mlankhorst> ipc is more fun, lets do that!
<RAOF> No, it's less fun. Which is why I want to generate it :)
<mlankhorst> haha
<RAOF> Really? â*push->cur++ = pushbuf_krel(push);â? Who thought that was an awesome idea?
<mlankhorst> it's obviously wrong when you see the patch
<mlankhorst> but not obviously wrong when you review the code at first
<RAOF> Well, maybe. But using a statement with side-effects as an lvalue is a pretty odd thing to do.
<hyperair> not that odd
<hyperair> a[i++] = blah; is not uncommon
<RAOF> I mostly see that with rvalues.
<mlankhorst> RAOF: well it's a common pattern in that file. :P
<mlankhorst> so it didn't particularly look out of place
<mlankhorst> hm pixman powerpc still in accepted
<mlankhorst> RAOF: can you look at x11proto-input, unity, unity-2d, libxfixes, libxi, qt4-x11 too?
<RAOF> Sure.
<mlankhorst> oh and mesa, just uploaded that (some debian/control changes). :) after that I think only the lts-saucy stack itself is messing, but I'm waiting for xorg-server 1.14.5 sru/mre in saucy first anyway.
 * RAOF slowly works his way thought more libdrming.
<mlankhorst> :
<mlankhorst> :D
<mlankhorst> dpkg-mergechangelog is awesome, i merged saucy branch into raring, merged raring into quantal, quantal into precise
<mlankhorst> couldn't copy it because precise and quantal have libdrm-nouveau1a
<RAOF> Man, XSync is a pile of fail.
<mlankhorst> yes :-)
<RAOF> So conceptually simple, so full of obscure bugs.
<jcristau> the extension, not the xlib function?
<mlankhorst> he's probably looking at 1.14.5 changelog
<jcristau> ah right
<RAOF> He's actually looking at https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1238410
<ubottu> Ubuntu bug 1238410 in X.Org X server "Inconsistent cursor visibility with cursor plugin enabled" [Medium,In progress]
<mlankhorst> ah :P
<RAOF> mlankhorst: Which could kindly have the SRU paperwork done on it?
<mlankhorst> RAOF: it was part of the MRE since it's fixed in 1.14.5 commits
<mlankhorst> but if you want I'll add some paperwork. :P
<RAOF> Ah, ok. Go about your business.
<RAOF> I don't need paperwork for MRE'd packages.
<mlankhorst> well the other fix has some paperworks
<mlankhorst> but the test there is observing xev timestamps
<RAOF> âOpening spreadsheets in libreoffice crashes Xâ is my favourite sort of bug :)
<mlankhorst> yeah ended up as a CVE
<mlankhorst> I tried to blame this on sweetshark but that didn't work. :P
 * RAOF â EOD
<mlankhorst> thankyou!
<tseliot> mdeslaur: I'm uploading the sources for 13.04 and 13.10 and I'll send you an email as soon as they're ready (it will take a while)
<mdeslaur> tseliot: for the nvidia driver?
<tseliot> mdeslaur: yep
<mdeslaur> cool, thanks
#ubuntu-x 2013-12-18
<tseliot> RAOF: bug #1222670 is one more reason to approve bug #1259237 ;)
<ubottu> bug 1222670 in nvidia-graphics-drivers-319 (Ubuntu Precise) "[nVidia GTX645][10de:11c4] Unable to boot to desktop with nvidia-319 driver" [High,Triaged] https://launchpad.net/bugs/1222670
<ubottu> bug 1259237 in screen-resolution-extra (Ubuntu Precise) "Hybrid graphics enablement in 12.04.4" [Medium,In progress] https://launchpad.net/bugs/1259237
<RAOF> tseliot: Hm. So you just need screen-resolution-extra, bbswitch, and nvidia-prime for Precise?
<tseliot> RAOF: well, the drivers need to be updated to, so that they can work with the new nvidia-settings
<tseliot> *too
<RAOF> tseliot: And those things all need to go into main, don't they?
<tseliot> RAOF: yep
<RAOF> Well, the nvidia-graphics-* want to be accepted into restricted I guess.
<RAOF> tseliot: Enjoy
<tseliot> RAOF: right, restricted for the nvidias. Did you also approve nvidia-settings and screen-resolution-extra?
<tseliot> RAOF: oh, and lightdm too please
<tseliot> RAOF: can you accept all the packages listed in the bug description, please?
<tseliot> RAOF: (3rd line)
<RAOF> Ah. I'm missing lightdm, nvidia-settings, and nvidia-graphics-drivers-173?
<RAOF> Oh, and screen-resolution-extra.
<tseliot> RAOF: and nvidia-graphics-drivers-304-updates
<tseliot> I know, it's a lot of stuff
<RAOF> tseliot: You've got a .git tree in the screen-resolution-extra upload
<tjaalton> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I" in .devscripts already :)
<tseliot> RAOF: let me reupload
<tseliot> tjaalton: I use -i.git
<jcristau> you need -I for native packages
<tseliot> jcristau: right, I mixed it up
<jcristau> :)
<tseliot> RAOF: the package should be there again now
<tseliot> tjaalton: but if I can automate it with that, that's a welcome addition ;)
<tjaalton> yes, add that to .devscripts
<tjaalton> what I pasted
<tjaalton> works with every vcs
<tseliot> tjaalton: no need to specify I.git?
<tjaalton> no
<tjaalton> one of those things that should be the default..
<jcristau> .git and .svn and CVS and ... are included in the default ignore patterns for -i and -I
<tseliot> ah, nice
<tseliot> RAOF: oh, and I didn't see any notifications about lightdm being approved either
 * tseliot -> away. brb
<RAOF> tseliot: I don't suppose you could combine the two lightdm SRUs that are in the queue?
<mlankhorst> ah ah
<mlankhorst> RAOF: mesa, libxi, libxfixes, unity, unity2d, qt4-x11? :D
<tseliot> RAOF: do you have a link to the other SRU?
<tseliot> RAOF: oh, I've found it. Yes, I can combine the two
<tjaalton> k, upgrading panda to trusty.. see how it breaks with llvmpipe
<RAOF> mlankhorst: Sigh. I'll look at that tomorrow, I guess :)
<RAOF> tseliot: Ok. I think I've accepted everything except lightdm now.
<tjaalton> hmm, so OMAP doesn't even try to load swrast
<mlankhorst> :o
<tjaalton> modesetting should be better
<tjaalton> not really
<tjaalton> loads swrast but unity doesn't work
<tjaalton> -omap needs to go in any case
<mlankhorst> but omap still has EXA acceleration i think
<mlankhorst> or something
<tjaalton> well unity doesn't work on it either
<tjaalton> fix it to load swrast then :)
<tjaalton> libEGL warning: DRI2: failed to authenticate
<tjaalton> huh
<tjaalton> nautilus works, so get to open a terminal from it :)
<tjaalton> glxgears doesn't work
<tjaalton> gives just a black window
<mlankhorst> tjaalton: can you recompile with llvm 3.4? :P
<mlankhorst> if using llvmpipe
<tjaalton> 3.4 is the default already?
<mlankhorst> no, still using 3.3, but 3.4 enabled build is on https://launchpad.net/~mlankhorst/+archive/ppa/+packages 
<tjaalton> ah, i mean default llvm is 3.4
<tjaalton> it'll take ages to build
<mlankhorst> tjaalton: you can grab the debs from there
<tjaalton> ah, right
<tjaalton> now nautilus ceased to work
<tjaalton> so those didn't help
<mlankhorst> ;D
<mlankhorst> but does glxgears work?
<tjaalton> no way to test yet
<mlankhorst>     swrast: fix readback regression since inversion fix
<mlankhorst>     
<mlankhorst>     This readback from the frontbuffer with swrast was broken, that bug
<mlankhorst>     just made it more obviously broken, this fixes it by inverting the
<mlankhorst>     sub image gets. Also fixes a few other piglits.
<mlankhorst> though that fixes classic swrast, not llvmpipe
<tjaalton> your deb works, but only because it's not using llvmpipe
<tjaalton> glxgears runs with it
<mlankhorst> ah
<tjaalton> anyway, llvmpipe breaks unity tests, so disable it again then
<mlankhorst>  sure
<tjaalton> but moving to llvm-3.4 is fine too, since it's default
<tjaalton> I'll test it on panda later
<tseliot> what X abi do we use in Saucy? 1.14?
<tjaalton> yes
<tseliot> ok, thanks, I'd better update fglrx for that too then
<tjaalton> huh?
<tjaalton> surely it installs on saucy?
<tseliot> sorry, for lts-saucy (12.04.4)
<tjaalton> ah..
<tjaalton> right
<tseliot> :)
<tseliot> and Linux 3.11...
<mlankhorst> mdeslaur: curse you, again preempting my uploads! (qt4-x11)
<mdeslaur> mlankhorst: ugh, sorry about that :(
<mdeslaur> mlankhorst: get your own archive! :)
<tseliot> mdeslaur: BTW did you see my email?
<mdeslaur> tseliot: yes, sorry, didn't have time to look at it yet
<tseliot> mdeslaur: ok, good, just checking that thunderbird didn't play any tricks on me ;)
<Guest67170> tjaalton, having a, eog problem where images are all blacked out and whatnot in saucy. the developer says it's the intel graphics driver talking to cairo and something getting fouled up. know anything about that?
<tjaalton> Guest67170: "the developer"? dunno, file a bug against xserver-xorg-video-intel
#ubuntu-x 2013-12-19
<tjaalton> RAOF: are there pending saucy backport uploads from mlankhorst still in NEW?
<RAOF> tjaalton: In the precise NEW queue?
<RAOF> I don't think so (there are some from tseliot, though)
<tjaalton> hm ok
<tjaalton> oem is expecting to get them there soon
<tjaalton> i thought they were uploaded already
<RAOF> I'll accept them once I've processed qt4-x11
<RAOF> They're now in binary NEW.
<tjaalton> right both are needed, backports and new nvidia stuff
<RAOF> mlankhorst: Oh, by the way - why is there a bunch of undocumented maintainer-script changes in unity-2d?
<tjaalton> maybe we'll get the rest uploaded today so you could process them tomorrow-ish :)
<RAOF> mlankhorst: Bah. qt4-x11 has been superceded by a security update.
<RAOF> There we go. All the prime stuff should be done now.
<mlankhorst> RAOF: no idea, did I change it?
<mlankhorst> @ qt4-x11 yeah I saw, needs a new fix
<RAOF> mlankhorst: Well, it's in the debdiff, so you've clearly changed it over what's in precise.
<mlankhorst> odd
<mlankhorst> oh 0,0 files
<mlankhorst> looks like it was because I built from source and the debclean didn't clean it up
<mlankhorst> feel free to reject then
<RAOF> Done.
<tjaalton> mlankhorst: can the rest of the stack move now?
<tjaalton> after these i mean
<mlankhorst> win a bit
<mlankhorst> I have a xorg-server saucy sru/mre to confirm first
<tjaalton> ok
<mlankhorst> tjaalton: can you sponsor qt4-x11 and unity-2d from https://mblankhorst.nl/etc
<tjaalton> done
<mlankhorst> RAOF: fixed :)
<mlankhorst> yay my panda chroot crashes
<tjaalton> so is the plan to get the xserver sru in saucy first and then the backports?
<tjaalton> to precise
<mlankhorst> yeah
<mlankhorst> well at that point I can do a massive upload everything
<tjaalton> thing is to get this all in before xmas though..
<mlankhorst> better get verifying then!
<tjaalton> I don't see anything in git
<tjaalton> ubuntu-saucy branch is at 2:1.14.3-3ubuntu2
<mlankhorst> there ya go
<mlankhorst> pushed but it's trusty + a changelog entry, anyway
<tjaalton> looks better :)
<tjaalton> and it's uploaded to proposed?
<mlankhorst> yeah
<tjaalton> can't it be uploaded to precise now too?
<tjaalton> might risk extra work though
<mlankhorst> I'm waiting for someone to accept qt4-x11 and unity-2d
<mlankhorst> at that point I can upload everything
<tjaalton> ah, right
<tjaalton> I'll poke the three bugs
<mlankhorst> I'm poking llvmpipe some
<tjaalton> kinda silly to file bugs for issues fixed in the point-release, since we have MRE in place..
<tjaalton> :)
<tjaalton> just waive it through
<mlankhorst> erm except that some parts were fixed not in the mre
<tjaalton> ah
<tjaalton> in that case yes
<mlankhorst> ah ah, wonder if this fix works..
<mlankhorst> tjaalton: you can just start libreoffice
<mlankhorst> and the crash bug is already fixed through pixman, I think
<mlankhorst> this is just paranoia from my side
<tjaalton> I don't want to crash my session :)
<tjaalton> and the other machines are on trusty
<jcristau> X :1 vt8?
<tjaalton> right, I could crash my wife's session
<mlankhorst> llvm is segfaulting somewhere
<mlankhorst> ==12040==    at 0x83D8B28: (anonymous namespace)::ELFObjectWriter::WriteSymbolEntry(llvm::MCDataFragment*, llvm::MCDataFragment*, unsigned long long, unsigned char, unsigned long long, unsigned long long, unsigned char, unsigned int, bool) (in /usr/lib/arm-linux-gnueabihf/libLLVM-3.3.so.1)
<mlankhorst> ==12040== Jump to the invalid address stated on the next line
<mlankhorst> ==12040==    at 0xAC96AA2: ???
<mlankhorst> ==12040==  Address 0xac96aa2 is 1,850 bytes inside a block of size 2,048 free'd
<mlankhorst> ==12040==    at 0x482F7E4: operator delete(void*) (vg_replace_malloc.c:480)
<mlankhorst> ==12040==    by 0x859FA51: (anonymous namespace)::LoopStrengthReduce::runOnLoop(llvm::Loop*, llvm::LPPassManager&) (in /usr/lib/arm-linux-gnueabihf/libLLVM-3.3.so.1)
<mlankhorst> then it dies
<tjaalton> k..
<tjaalton> well I have the new pixman and it doesn't crash anymore
<mlankhorst> yeah
<mlankhorst> just grab old pixman
<mlankhorst> still shouldn't crash :>
<tjaalton> both are at stock versions, doesn't crash
<tjaalton> another session running though if it matters
<mlankhorst> hm fine I'll try myself
<tjaalton> :)
<mlankhorst> tjaalton: oh right, are you trying to reproduce on nvidia drivers?
<tjaalton> no, intel
<jcristau> intel's not really a good test case for exa
<jcristau> oh but you tested the pixman bug too. hmm.
<mlankhorst> *tries intel*
<jcristau> i think i only tested xephyr and radeon actually
<mlankhorst> that's more than me! :D
<mlankhorst> tjaalton: yeah intel is unaffected
<tjaalton> heh, ok
<tjaalton> i'm useless then
<mlankhorst> oh wait i upgraded pixman too
<mlankhorst> sigh
<mlankhorst> cba
<mlankhorst> it was fixed, done
<mlankhorst> verification-done, la la not going to worry any more
<tjaalton> correct
#ubuntu-x 2013-12-20
<mlankhorst> tjaalton: hm only llvm dependencies and the lts-saucy packages are still in s-lts-backport, afaict. :P
<tjaalton> mlankhorst: what does that mean?
<mlankhorst> rest can be done in a single uploa
<tjaalton> k
<mlankhorst> and it contains only the actual pieces of the lts-saucy stack instead of the preparations
#ubuntu-x 2015-12-17
<tjaalton> RAOF: hey, still around?
<tjaalton> RAOF: pushed mesa 11.1.0 to git and canonical-x/x-staging ppa, if you don't mind checking that Mir still works with it
<tjaalton> also merged libinput 1.1.3
<tjaalton> oh and a new -intel snapshot
<tjaalton> these two straight to xenial, -intel at least seems to work fine on BDW..
<RAOF> tjaalton: Yo!
<RAOF> tjaalton: Not usually around at 19:23 :). I'll do some Mir testing.
#ubuntu-x 2015-12-18
<tjaalton> RAOF: yeah, that was quite desperate.. thx :)
<RAOF> tjaalton: Ok, so that's totally broken.
<RAOF> Also, stupid display servers being less than convenient to test. :)
<RAOF> tjaalton: Everything fails with: Mesa 11.1.0 implementation error: Unsupported accumBits in add_accum_renderbuffer
<tjaalton> haha
<tjaalton> ok, glad I asked then :)
<RAOF> The desktop itself seems fine, so this might be a bug in the mir EGL patch.
<tjaalton> the only thing that needed rebasing was that is_different_gpu moved outside of HAVE_WAYLAND_PLATFORM ifdef in dri2_egl_display struct
<RAOF> There doesn't seem to be anything *obviously* wrong...
<RAOF> Well, *that's* an entirely unhelpful backtrace.
 * RAOF builds again, this time with optimisation off.
<RAOF> Aha!
<RAOF> Well, that's a surprising API change.
<RAOF> Huh.
<RAOF> tjaalton: Ok, so it now doesn't crash, but doesn't render.
<RAOF> Because something is stomping over memory.
<RAOF> tjaalton: I've pushed what I've done so far to git; feel free to either fix or wait for me to fix on Monday.
<RAOF> For now... EOD!
<RAOF> And EOW.
<tjaalton> RAOF: ok thanks, I'm in no rush to push it to xenial
<tjaalton> happy EOW :)
#ubuntu-x 2016-12-22
<soee> is it only me or you also have feeling that ingame performance with latest nvidia driver is better ?
<mamarley> soee: 375.26?  I don't really play games that much, so I'm not sure.  I did check to see if Sauerbraten and Xonotic ran, but my GTX970 can already run those at 60fps, soâ¦
#ubuntu-x 2016-12-23
<alkisg> I have Ubuntu 12.04 with the trusty kernel/xorg, i.e. 3.13/ 2:1.15.1-0ubuntu2~precise5
<alkisg> I have a very new intel graphics card: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:1912] (rev 06)
<alkisg> 1912 does not appear in modules.pcidep of 3.13, but it appears in e.g. 4+ kernels
<alkisg> I only want to be able to use 1024x768 instead of 640x480. But adding that mode in xorg.conf doesn't appear to work. Can I use vesa instead?
<alkisg> ...and, how? :)
<alkisg> Hehe, I managed to get linux-image-4.4.0-57-generic from trusty installed to precise, after also installing kmod from wheezy-backports... :D
<alkisg> Just for the logs, here's the list I used:
<alkisg> http://security.ubuntu.com/ubuntu/pool/main/l/linux-lts-xenial/linux-image-4.4.0-57-generic_4.4.0-57.78~14.04.1_i386.deb
<alkisg> http://ftp.us.debian.org/debian/pool/main/k/kmod/kmod_9-3_i386.deb
<alkisg> http://mirrors.kernel.org/ubuntu/pool/main/k/kmod/module-init-tools_15-0ubuntu6_all.deb
<alkisg> http://ftp.us.debian.org/debian/pool/main/k/kmod/libkmod2_9-3_i386.deb
<tjaalton> alkisg: trusty with lts-vivid stack is first that supports skylake
<tjaalton> anything older and you're on your own
<tjaalton> 1204 is eol in 5mo
<tjaalton> fyi
<alkisg> Yeah we really need to fix the "can't type in greek" issue past 12.04 so that we can move on... :)
<alkisg> Thank you tjaalton!
#ubuntu-x 2017-12-18
<JanC> dupondje: I think there are patches that won't be accepted upstream
<JanC> or something like that
<JanC> (also, Wayland still has lots of other issues where Xorg works fine)
<JanC> e.g. for all it claims to be faster, IME it actually works slower, and is less responsive (and that's on Intel GPU hardware)
<JanC> (not to mention GNOME on Wayland hangs every 1-3 days or so)
#ubuntu-x 2018-12-20
<mamarley> ricotz: Ah, I see you found 416.25.  :)  I had been meaning to let you know, but I never could catch you when you were online.
<ricotz> mamarley, thanks, don't worry, there was some travelling lately
#ubuntu-x 2019-12-16
<tomreyn> https://firefoxgraphics.github.io/telemetry/#view=linux
<tomreyn> 6.4% using nouveau
<mamarley> webrender/mesa-iris represent!  I am the 0.1%!
<tomreyn> :)
<tomreyn> threaded rendering coming to firefox on linux in 2020 (according to plans) https://discourse.mozilla.org/t/have-you-tested-webrender/16137 https://wiki.mozilla.org/Platform/GFX/Quantum_Render
<tomreyn> i can actually load this page https://unicode.org/emoji/charts/full-emoji-list.html on 71.0 with gfx.webrender.enabled=true
<tomreyn> https://wiki.mozilla.org/Platform/GFX/WebRender_Where#Linux
<mamarley> I've found if you have a 4K display, you pretty much need to have at least OpenGL compositing enabled in order for Firefox to scroll at 60FPS.  Otherwise it drops to 30, which I find unusable.
<tomreyn> well, at least it still works ;-)
<tomreyn> try loading the emoji list on standard 71
<mamarley> It loads here, but if I scroll with any speed at all, the rendering can't keep up and it whites out temporarily.
<tomreyn> oh, actually it works. cough, ad blocker, cough.
<mamarley> With WebRender on, it still whites out a little bit if I scroll very fast, but the performance is noticeably better.
<tomreyn> same, here
<tomreyn> i guess this page would benefit a lot of the code path webrendEST enables, but this doesn't seem to be in 71, yet
<tomreyn> amd rx580 here
<mamarley> https://bugzilla.mozilla.org/show_bug.cgi?id=1425260 seems to indicate that gfx.webrender.all does the same thing now.
<ubottu> Mozilla bug 1425260 in Graphics: WebRender "Bring back webrendest functionality" [Normal,Resolved: fixed]
<mamarley> (If I'm understanding this correctly.)
<tomreyn> wow, this is fast!
<tomreyn> it even works with my addons this way. and it doesn't munch too much ram.
<tomreyn> no white during scrolling for me now
