#ubuntu-x 2006-08-21
<Seveas> hi seb ;)
<rodarvus> hi Seveas!
<seb128> Hi
<rodarvus> I sitting closes to seb128 :)
<Seveas> So you want incom-ing-x-bugs spammed in here?
<rodarvus> (and watched your conversation)
<rodarvus> yes, that would be a nice feature to have
<rodarvus> do you think it is possible?
<Seveas> of course
<rodarvus> thanks, really appreciated!
<Seveas> incoming x bugs are sent to all x-swat teammembers, right?
<rodarvus> Seveas, right
<rodarvus> do you wan't some account to be subscribed to x-swat?
<Seveas> yes -- an account that still needs to be created ;)
<Seveas> working on that 
<Seveas> rodarvus, Ubugtu X bugbot has to be accepted to the team, then I can set it up
#ubuntu-x 2006-08-22
<rodarvus> fabbione, I added a patch for pci domains support to xorg-server on dapper-updates
<rodarvus> (this patch was requested by ben, for a customer, I think)
<fabbione> ok
<fabbione> feh
<rodarvus> unfortunately this patch breaks X for a few configurations, so I'm reverting it, for the moment
<rodarvus> (actually, I'm test building it locally, before the upload)
<fabbione> rodarvus: make sense yes
<Seveas> fabbione, could you accept Ubugtu as a member of the X swat on launchpad please
<fabbione> Seveas: why does it need to be memeber of the group?
<rodarvus> fabbione, I asked Seveas for Ubugtu to announce new X.Org bugs here
<fabbione> ah ok
<fabbione> sure
<rodarvus> (makes it easy to catch important bugs quickly)
<fabbione> done
<rodarvus> thanks!
<Seveas> @config channel plugins.bugtracker.bugreporter
<Ubugtu> 
<Seveas> @config channel plugins.bugtracker.bugreporter /home/dennis/ubugtu/data/bugmail-x
<Seveas> @config channel plugins.bugtracker.bugsnarfer True
<Seveas> @config list plugins.bugtracker 
<Ubugtu> New bug: #57153 in xorg-server "xorg-server 1:1.0.2-0ubuntu10.3 breaks X: "no screens found"" [High,Fix released]  http://launchpad.net/bugs/57153
<Ubugtu> New bug: #57216 in xorg-server "New update kills ATI detection" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57216
<Seveas> rodarvus, it's working
<rodarvus> Seveas, thanks a lot!
<Ubugtu> New bug: #57221 in xorg-server "gdm never starts after upgrade of xserver-xorg-core" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57221
<Ubugtu> New bug: #57222 in xorg-server "xorg-core update 10.3 breaks X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57222
<Ubugtu> New bug: #57227 in xorg-server "xserver-xorg-core 1.0.2-0ubuntu10.3 missing some device drivers? X doesn't start: stops to fatal error" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57227
<Ubugtu> New bug: #57229 in xorg "Kubuntu drops me unpredictably to tty1, tty2 etc" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57229
<Ubugtu> New bug: #57232 in xorg-server "1.0.3 breaks X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57232
<Ubugtu> New bug: #57236 in xorg-server "My X will not start again after last update" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57236
<Ubugtu> New bug: #57238 in xorg-server "X doesnt start: No devices detected." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57238
<Ubugtu> New bug: #57239 in xorg-server "video card no detected anymore" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57239
<Ubugtu> New bug: #57263 in xorg-server "Failed to detect GPU after upgrade" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57263
<Ubugtu> New bug: #57276 in xorg-server "X fails to find savage card after upgrade to xserver-xorg-core 1.0.2-0ubuntu10.3" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57276
<Ubugtu> New bug: #57278 in xorg-server "Kubuntu dapper: xserver-xorg-core 10.3 doesn't work with nvidia_glx" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57278
<Ubugtu> New bug: #57282 in xorg-server "After upgrading dapper 22:nd of august, X doesn't start" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57282
<Ubugtu> New bug: #57283 in xorg "latest xserver fails" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57283
<Ubugtu> New bug: #57287 in xorg-server "X fails to find ATI Radeon chip after upgrade to xserver-xorg-core-1:1.0.2-0ubuntu10.3" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57287
<Ubugtu> New bug: #57288 in xorg-server "latest update of xserver-xorg-core fails PCI scan" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57288
<Ubugtu> New bug: #57290 in xorg-server "Xserver fails after restart" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57290
<Ubugtu> New bug: #57292 in xorg-server "Recent versions in dapper-updates break mga200 detection" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57292
<Ubugtu> New bug: #57295 in xorg-server "xserver-xorg-core update on August 22, 2006 blows up" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57295
<Mithrandir> rodarvus: how do you feel about building kdrive from xorg-server?
<Ubugtu> New bug: #57297 in xorg-server "Update to version 1:1.0.2-0ubuntu10.3: xserver not longer starts" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57297
<Mithrandir> we're aiming for most-duplicated bug report?
<Mithrandir> rodarvus: also, what's happening with xapps?  I thought we were just going to sync them?
<Ubugtu> New bug: #57304 in xorg-server "updating to the newest package 1.0.2 ubuntu10.3 makes the xserver unable to start" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57304
<rodarvus> Mithrandir, yes, I think kdrive could be built by xorg-server indeed. I haven't checked the source code inside xorg-server to be sincere, but it surely deserves an investigation
<rodarvus> basically the reason I haven't done that before is because there was a reasonable chance the version of kdrive inside xorg-server was crap (and I didn't have had much time to deal with it yet)
<rodarvus> Mithrandir, we have the current version of all xapps
<rodarvus> I intended to sync them initially, but found out debian was seriously outdated on this regard
<Mithrandir> rodarvus: I just did a build of xorg-server with --enable-kdrive and the server seems to work fine for me at least.
<rodarvus> what is the difference of --enable-kdrive and --enable-xephyr
<rodarvus> (I built it locally too, but didn't tested yet)
<Mithrandir> xephyr is one of the kdrive servers
<rodarvus> isn't it the server we want/need?
<Mithrandir> Xsdl is another
<Mithrandir> (Xvesa another, Xfake a third, etc)
<Mithrandir> yes, if we want to enable any kdrive servers, Xephyr is the one we want.
<Mithrandir> I don't think we'd want any others.
<rodarvus> agree
<Mithrandir> it'd fix 57077 too
<Mithrandir> I can't find the version of kdrive in the server though.. might need to talk to rburton about that.
<rodarvus> right
<Mithrandir> (whether xorg-server is newer than xserver-kdrive or not)
<rodarvus> it is inside hw/kdrive I think
<rodarvus> but it breaks
<rodarvus> (build breaks, I mean)
<Mithrandir> worked for me
<Mithrandir> do you have a build failure now?
<rodarvus> I built entering obj-*/hw/kdrive + make (after debuild with --enable-xephyr)
<rodarvus> I expected it to build automatically during the .deb build, but it didn't happened
<Mithrandir> did for me
<Mithrandir> oh, do --enable-kdrive
<Mithrandir> it'll give you a xephyr server
<rodarvus> oh, nice
<Mithrandir> without, it won't build any of the kdrive stuff, AIUI
<tom_> hi chaps, after that xserver-xorg-core update broke my x, I have tried everything suggested on the forum and in #ubuntu but cant get my xserver running
<tom_> probably due to my having messed up the xserver installation before realising that this was a general ubuntu problem
<tom_> currently my xserver error log says:  (EE) no devices detected
<tom_> Fatal server error
<tom_> no screens found
<tom_> what should I do?
<ubugbla> New bug: #57308 in xorg "Xorg and ATI X600 - RV370/380 (5B62) doesn't work" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57308
<rodarvus> tom_, it looks like you are still running the broken version of xserver-xorg-core.
<tom_> rodarvus: I tried  upgrading to 10.4 and downgrade to 10.0 
<rodarvus> tom_, sudo apt-get install xserver-xorg-core:1.1.0.2-0ubuntu10.2
<rodarvus> upgrading to 10.4 should fix you problem, indeed
<tom_> I'll run that again just check
<rodarvus> it was published to the archive, and most (all?) mirrors should already have it by now
<tom_> but I think I may have caused another problem by removing xserver-xorg before following the instructions
<tom_> I tried to reinstall but I think I may have lost some packages
<Mithrandir> that shouldn't cause any problems, I'd think.
<tom_> rodarvus:  is "sudo apt-get install xserver-xorg-core:1.1.0.2-0ubuntu10.2" a typo?
<tom_> I thought it was 10.4
<tom_> and that doesnt seem to work
<rodarvus> it is 10.4. the only reason I asked you to install 10.2 is because I don't know which mirror you are using - your mirror could be outdated and that would let you start X as usual
<tom_> but doing apt-get install xserver-xorg-core=1:1.0.2-0ubuntu10.4 works
<tom_> and says is already the newest version installed
<tom_> rodarvus: I think you missed the "=" ?
<tom_> when I insert that and try with 10.2 it says that version is not found
<rodarvus> tom_, yes, I did, please add it back :)
<tom_> rodarvus:  I added it, but 10.2 aint found and 10.4 says I've already got the newest version installed
<rodarvus> what 'dpkg --list xserver-xorg-core' returns for you? (please output only the relevant line)
<tom_> erm, what is the relevant line?
<tom_> under version is says 10.4
<rodarvus> so you already got the latest version. if X is not working, its another issue (probably unrelated to 10.3)
<tom_> rodarvus: the whole line is: xserver-xorg-core 1.0.2-0ubuntu10.4 X.Org X server -- core server
<rodarvus> right
<Mithrandir> tom_: you could try doing dpkg-reconfigure -phigh xserver-xorg to reconfigure the X server again.
<tom_> ok, yes, that what I thought, somewhere along the line I created another issue whilst trying to fix this one
<tom_> Mithrandir: done that a few times already
<tom_> any idea how to go about this other problem, whatever it is?
<tom_> + fixing
<tom_> what causes the no screens found error normally?
<Mithrandir> can you put your xorg.conf and Xorg.0.log in a pastebin somewhere?
<tom_> is there a command I can to re-install everything that x needs to function properly
<tom_> Mithrandir: yes, let me just copy them over to this machine...
<tom_> http://paste.ubuntu-nl.org/21410
<tom_> http://paste.ubuntu-nl.org/21411
<tom_> Mithrandir: here you go http://paste.ubuntu-nl.org/21410 http://paste.ubuntu-nl.org/21411 :)
<Mithrandir> tom_: looking at them.  The network here isn't the quickest one around
<rodarvus> tom_, even tough dpkg believes you are running 10.4, it seems you are really running 10.3
<tom_> okay ??
<rodarvus> is there any chance you --forced it somehow?
<tom_> yes
<tom_> I think I may have tried a -f at some point if that is what you mean?
<rodarvus> download http://people.ubuntu.com/~rodarvus/packages/dapper/xorg-server/xserver-xorg-core_1.0.2-0ubuntu10.4_i386.deb
<rodarvus> install it (dpkg --install ...)
<rodarvus> ...
<rodarvus> profit!
<Mithrandir> rodarvus: any reason why the Xorg.0.log doesn't include the full Ubuntu version number?
<rodarvus> Mithrandir, not really, actually
<rodarvus> and indeed, it would be really helpful
<tom_> rodarvus: I've tried that before, but I'll try it again...
<tom_> same problem persists
<tom_> rodarvus: as you (?) pointed out, it would appear that I have some other problem, shall I submit a new bug?
<tom_> or have you got any more ideas of other things to try?
<tom_> is there a command I can to re-install everything that x needs to function properly?
<rodarvus> there is nothing else easily apparent from your Xorg.0.log file
<rodarvus> please follow the steps in https://help.ubuntu.com/community/DebuggingXAutoconfiguration
<rodarvus> there  is quite a lot of helpful information on this page
<rodarvus> and eventually if the informations there doesn't fix your problems, it teaches you on how to prepare a proper bug report
<Ubugtu> New bug: #57313 in xorg-server "xserver doesn't start on hp compaq nc8000 laptop" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57313
<Ubugtu> New bug: #57319 in xorg-server ""X -scanpci" fails to find graphics adapter" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57319
<tom_> thanks rodarvus 
<tom_> got it in the end
<rodarvus> what was it?
<tom_> somehow, the right driver wasnt installed for the video card anymore
<tom_> the video card was a savage
<tom_> and it turns out there is a package: xserver-xorg-driver-savage
<tom_> which wasnt installed
<Mithrandir> you probably uninstalled it while debugging, then
<tom_> yeah, somehow
<Ubugtu> New bug: #57325 in xorg-server "(EE) No devices detected." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57325
<Mithrandir> but if it's fixed, that's good. :-)
<tom_> yeah though it has taken up most of my day
<tom_> though at least now I have some idea what X is!
<Mithrandir> we're _really_ sorry about that.
<rodarvus> the last 12 hours were not the best hours of my life, but I'll get over it
<tom_> sure, well its the first major problem I have had running ubuntu for 18 months
<Mithrandir> we've managed to piss off a lot of users and the only thing I can say is "we promise to do better in the future".
<tom_> sure, I guess its been pretty damn stressful for you guys
<tom_> well, best of luck with making sure it doesnt happen again :)
<Mithrandir> thanks. :-)
<Mithrandir> and again, sorry for fucking it up in the first place.
<tom_> I dont imagine the work you guys are doing is easy
<tom_> Mithrandir: everyone makes mistakes from time to time ;)
<Mithrandir> tom_: yeah, I guess.  About time it was us, then.
<Mithrandir> We'll get over it
<tom_> :)
<Ubugtu> New bug: #57329 in xserver-xorg-video-via "upgrade to latest xorg has stopped my CLE266 from working" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57329
<Ubugtu> New bug: #57333 in xserver-xorg-video-via "22-Aug-06 xorg update killed X on my Latitude D810" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57333
<heimweh> join #ubuntu-devel
<Ubugtu> New bug: #57338 in xorg-server (main) "Graphic mode is broken" [Medium,Needs info]  http://launchpad.net/bugs/57338
<Ubugtu> New bug: #57339 in xorg-server "Fatal server error: no screens found" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57339
<Ubugtu> New bug: #57345 in xorg-server "No devices detected. after update to xserver-xorg-core 1:1.0.2-0ubuntu10.3" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57345
<Ubugtu> New bug: #57358 in xorg-server "Update breaks xserver (fix = apt-get install xserver-xorg-core=1:1.0.2-0ubuntu10)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57358
#ubuntu-x 2006-08-23
<Ubugtu> New bug: #57364 in xorg-server "Xorg doesn't detect any graphic cards" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57364
<Ubugtu> New bug: #57370 in xorg-server (main) "xserver-xorg-core" [Medium,Fix released]  http://launchpad.net/bugs/57370
<Ubugtu> New bug: #57371 in xorg-server "killer upgrade: xserver won't start" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57371
<Ubugtu> New bug: #57375 in xorg-server "xserver-xorg-core update breaks X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57375
<Ubugtu> New bug: #57376 in xorg-server "X doesn't start after upgrade to 1:1.0.2-0ubuntu10.3" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57376
<Ubugtu> New bug: #57400 in xorg-server "No ChangeLog for fix of bug 57153" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57400
<rodarvus> how people manage to file bugs like this one? ^^^
<Mithrandir> they read the changelog and wonder what the fix was?
<Mithrandir> actually, he's confused about changelog vs changelog.Debian
<rodarvus> he says "There is a new version 1:1.0.2-0ubuntu10.4 of xserver-xorg-core which I assume fixes bug 57153 of version 1:1.0.2-0ubuntu10.3. But there is not ChangeLog entry for those versions. The latest entry in ChangeLog is about version 1:1.0.2-0ubuntu10."
<Ubugtu> Malone bug 57153 in xorg-server "xorg-server 1:1.0.2-0ubuntu10.3 breaks X: "no screens found"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57153
<rodarvus> there is obviously a changelog
<rodarvus> (you need to have one)
* Mithrandir grrs at the broken locale support in Xlib at the moment
<Mithrandir> rodarvus: do you get a "locale not supported by Xlib" thingy if you run xterm in an UTF8 locale?
<rodarvus> Mithrandir, yes, its happening here too
<rodarvus> I'll try to take a look at this bug in a while, as soon as I finish some other stuff I'm working on at the moment
<Mithrandir> thx
<Ubugtu> New bug: #57408 in xserver-xorg-video-ati "[radeon]  enabling EXA results in black screen" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57408
<Ubugtu> New bug: #57415 in xorg-server (main) "Inconsistent cut-and-paste behaviour" [Untriaged,Confirmed]  http://launchpad.net/bugs/57415
<Mithrandir> rodarvus: do you keep the X packages in an RCS somewhere?
<rodarvus> no. I wanted to either maintain our packages in the XSF repository (but I can't right now as I'm not part of the team), or bzr
<rodarvus> *but* bzr had problems importing such a large repository, last I tried
<rodarvus> (I tried importing X into it once)
<rodarvus> the plan was to have separate branches to each patch we apply on our X packages
<rodarvus> (since branching seems to be such a cheap operation on bzr)
<Mithrandir> yeah
<Mithrandir> https://launchpad.net/products/xorg-server/trunk/+source ; fill in the stuff there and prod ddaa to get the import going?
<Mithrandir> actually, xorg is moving to GIT so we probably will have to wait for that to happen
<Ubugtu> New bug: #57452 in xserver-xorg-video-sis "sis driver won't start X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57452
<Ubugtu> New bug: #57466 in xserver-xorg-driver-nv "weird error in text input field in gtk applications" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57466
* Starting logfile irclogs/ubuntu-x.log
* Mithrandir kicks bzr and tailor in the nuts
<Mithrandir> bzrlib.errors.InvalidRevisionId: Invalid revision-id {Egbert Eich <eich-at-freedesktop-dot-xorg>-20041018122145-bf29d4b91e4a312a} in 97/im%2552m.c-20060823154647-fe49568e519d2115
<Mithrandir> rodarvus: disabling loadable i18n modules works around the problem.
<Ubugtu> New bug: #57498 in xserver-xorg-driver-ati "Xserver crash on start up" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57498
#ubuntu-x 2006-08-24
<Ubugtu> New bug: #57525 in xresprobe "fails on ATI Mobility X700 (Acer TravelMate 8100)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57525
<Ubugtu> New bug: #57540 in xorg-server ""Fatal server error: no screens found" on recent xserver-xorg-core upgrade" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57540
<Ubugtu> New bug: #57554 in xorg-server "radeon M7500 not recognized after upgrading to xserver-xorg-core 1.0.2-0ubuntu10.3 " [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57554
<Ubugtu> New bug: #57560 in xutils-dev "lndir, xon and others lost in repackagin process" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57560
<Ubugtu> New bug: #57579 in xorg-server (main) "Kubuntu LiveCD doesn't complete boot on Dell Inspiron 640m" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57579
#ubuntu-x 2006-08-25
<Ubugtu> New bug: #57692 in libx11 "last update affects xterm" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57692
<Ubugtu> New bug: #57721 in xorg "Website crashes xorg!" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57721
#ubuntu-x 2006-08-26
<Ubugtu> New bug: #57767 in xorg "display is garbled on intel 855gm" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57767
<Ubugtu> New bug: #57770 in xorg "Xorg Crashes every time on xorg dual-head configuration." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57770
<Ubugtu> New bug: #57776 in xorg "custom xorg.conf should not be overridden" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57776
<Ubugtu> New bug: #57790 in xorg-server "xserver-xorg-core_1.0.2-0ubuntu10.4_i386.deb significantly degrades performance of VMware Server 1.0.1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57790
<Ubugtu> New bug: #57802 in xorg "[edgy]  external monitor not well recognized" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57802
<Ubugtu> New bug: #57814 in mesa ""radeon_cp_reset called without lock held"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57814
<Ubugtu> New bug: #57817 in xorg "Upgrade to  1:1.0.2-0ubuntu10.4 buggy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57817
<Ubugtu> New bug: #57830 in xorg-server "xserver-xorg-core breaks the Xserver on Intel" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57830
<Ubugtu> New bug: #57840 in xorg "X hangs system on switch back" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57840
#ubuntu-x 2006-08-27
<Ubugtu> New bug: #57844 in xorg "Hard freeze using savage DRI" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57844
<Ubugtu> New bug: #57862 in xorg "Display is unusable with default settings" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57862
<Ubugtu> New bug: #57878 in xkeyboard-config ""Serbia and Montenegro" no longer exists" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57878
<Ubugtu> New bug: #57880 in xserver-xorg-driver-ati "r200_vtxfmt.c:1044: r200VtxFmtFlushVertices: Assertion failed." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57880
#ubuntu-x 2007-08-20
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #133604 in xserver-xorg-video-ati (main) "ati 6.6.193 causes overheat while watching videos" [Undecided,New]  https://launchpad.net/bugs/133604
<ubotu> New bug: #129917 in xterm (main) "Rogue entries in the menu" [Low,New]  https://launchpad.net/bugs/129917
<ubotu> New bug: #133626 in xorg (main) "Broken "us" layout on some installations" [Undecided,New]  https://launchpad.net/bugs/133626
<ubotu> New bug: #133030 in totem (main) "totem-xine and mplayer cannot play any video (dup-of: 111257)" [Medium,Incomplete]  https://launchpad.net/bugs/133030
<ubotu> New bug: #126250 in xserver-xorg-video-intel (main) "rhythmbox crashed with signal 5" [Medium,New]  https://launchpad.net/bugs/126250
<ubotu> New bug: #133712 in xorg-server (main) "[Gutsy]  Rhythmbox crashes X-Server" [Undecided,New]  https://launchpad.net/bugs/133712
<ubotu> New bug: #133737 in xclock (main) "Calendar display hidden behind open windows in gnome-panel clock" [Undecided,New]  https://launchpad.net/bugs/133737
<tepsipakki> bryce: you made it in phoronix.com :)
<bryce> heya tepsipakki
<bryce> ouch
<tepsipakki> heh
#ubuntu-x 2007-08-21
<ubotu> New bug: #133560 in xserver-xorg-driver-via (main) "VIA Chrome 9 HC IGP Not Supported" [Undecided,New]  https://launchpad.net/bugs/133560
<bryce> tepsipakki: I've posted a bunch to http://ubuntuforums.org/showthread.php?p=3224316
<tepsipakki> bryce: yeah, makes perfect sense
<tepsipakki> btw, X.org 7.4 is now scheduled for February 2008
<kylem> i wouldn't worry too much about it
<kylem> (phoronix etc.)
<tepsipakki> me neither
<tepsipakki> 1.3.99.0 is now in experimental, since pixman got past NEW.. I'll try it out sometime just for fun
<tepsipakki> it also has the patches which make discover obsolete (for xorg)
* kylem nods
<tepsipakki> hey kylem, I've seen you hanging out on #d-x :)
<kylem> it's moderately unfortunate ubuntu doesn't yet have something to compare to experimental
<tepsipakki> yeah
<kylem> :)
<tepsipakki> bryce: have you tried compiling your xserver merge with current mesa?
<tepsipakki> I remember there were issues with that in the past
<bryce> tepsipakki: yeah I've been having some problems there
<bryce> it works ok with dsfg-6*, but if I try building against dsfg-11, stuff breaks
<tepsipakki> I wonder if it was due to our mesa
<tepsipakki> do you have it somewhere so I can test?
<bryce> unfortunately I just have it here locally
<bryce> I recall jcristau mentioning some issues when he started looking at mesa 7.  Maybe there's some mesa patches we're missing?
<bryce> you know, it's not a bad idea to set up a dev environment for us to share.  I think I'll plan on setting up a sandbox here on one of my machines
<bryce> or else on one of the canonical machines if it seems better
<bryce> kylem: yeah I'm accumulating enough experimental packages in my Testing dir, that it'd be nice to have a more structured way for people to pull and test against them
<bryce> I thought maybe PPA would enable something like that, but it also feels a bit clumsy for that
<kylem> indeed.
* Starting logfile irclogs/ubuntu-x.log
<jcristau> bryce: i didn't add any new patches on top of mesa 7.0.1 iirc
<bryce> jcristau: ok.
<bryce> I've narrowed the issues down a bit.  I took the current ubuntu xorg-server source and copied in all the debian/patch/'es (no other changes other than patches).  I can successfully build now if I disable patch 49_map_keyboard_driver_to_kbd.diff
<bryce> 49_map_keyboard_driver_to_kbd.diff was giving a 'fail to patch' error.  Not sure yet why.
<jcristau> weird
<ubotu> New bug: #133799 in mesa (main) "intel945gm missing support for GL_POINT_SMOOTH and GL_POINT_SMOOTH" [Undecided,New]  https://launchpad.net/bugs/133799
<tepsipakki> bryce: could you build a source-package out of it so I could take a look?
<bryce> probably my own damn fault I'm sure
<tepsipakki> :)
<bryce> yup, I've confirmed it's that one patch that's causing the patching failure
<bryce> but what's odd is I manually applied the patches in sequence, and patch 49 applied cleanly 
<bryce> unfortunately 49_map_keyboard_driver_to_kbd.diff is one of the primary patches I want
<bryce> tepsipakki: yeah hang on
<tepsipakki> bryce: I can try merging it here starting from a clean tree, and compare the results
<bryce> tepsipakki: ok
<bryce> tepsipakki: I'm uploading, should be done shortly
<bryce> tepsipakki: http://people.ubuntu.com/~bryce/Testing/xorg-server/
<tepsipakki> oh, I thought you were trying to merge with -12
<bryce> tepsipakki: actually I am
<bryce> tepsipakki: the approach I've taken is to copy in all the patches from -11's debian/patches/ and get them building, in isolation from any other debian/* changes
<bryce> so far it builds if I leave out patch 49
<bryce> next I'll look at the changes outside debian/patches/.
<bryce> the error message I get with patch 49 isn't too helpful:
<bryce> 001_ubuntu_add_extra_modelines_from_xorg.patch
<bryce> Applying patches...failed! (check stampdir/log/patch for details)
<bryce> make: *** [stampdir/patch]  Error 1
<bryce> pbuilder: Failed autobuilding of package
<bryce> ...
<tepsipakki> try debuild, then you can see the log
<jcristau> if you take the changes from debian/xsfbs/ it should now cat stampdir/log/patch
<tepsipakki> ah
<tepsipakki> hmm, could the xvfb Depends: xfonts-base be put as Recommends as it's in Debian (making the diff smaller). Recommends are installed anyway
<tepsipakki> also, packages which provide xserver-xorg-video should probably be changed to provide the ABI version of the server they are supposed to be used with
<seb128> tepsipakki: when are Recommends installed?
<jcristau> they're not installed on buildds, and some packages use xvfb-run at build time
<jcristau> and some might (incorrectly) not build-dep on xfonts-base
<tepsipakki> hmm, ok I'll leave it then ;)
<ubotu> New bug: #133457 in xorg (main) "[gutsy]  alternate install monitor frequency too high" [Undecided,New]  https://launchpad.net/bugs/133457
<tepsipakki> bryce: I've completed the merge, and patch 49 succeeded, but 106 didn't :)
<tepsipakki> jcristau: should the xsfbs-changes be in -12?
<tepsipakki> jcristau: nevermind.. it did show the log afterall :)
<tepsipakki> uh, something has happened to patch 106.. it used to be readable :)
<tepsipakki> there, patches applied fine, some offsets but that's cosmetic
<tepsipakki> now trying to build
<tepsipakki> Creating destination directories for mesa module ...  error:   Source directory /usr/share/mesa-source/src/mesa/array_cache does not exist
<tepsipakki> configure: error: Failed to link Mesa source tree.  Please specify a proper path to Mesa sources, or disable GLX.
<jcristau> all references to array_cache should go away
<tepsipakki> right.. I disabled patch 127.. need to bring it back
<tepsipakki> what about 125/126, safe for mesa7?
<tepsipakki> meant for building with 6.5.3
<jcristau> yeah, no change to 12[5-7] 
<jcristau> i think i just took them from your package
<tepsipakki> seems to be so :)
<tepsipakki> fedora has added a new patch to their composite hacks..
<tepsipakki>  xserver-1.3.0-no-pseudocolor-composite.patch: Refuse to initialize
<tepsipakki>   Composite when Render is missing or when the root window is using
<tepsipakki>   a pseudocolor visual. (#217388)
<tepsipakki> now it seems to build
<tepsipakki> and finished
<tepsipakki> and works
<mvo> aha, lots of X hackers here :) does anyone can think of a way to detect when a window is using glx? 
<tepsipakki> mvo: lots of noise maybe ;) (sorry, can't think of a way)
<mvo> heh :) 
<kylem> mvo, what are you trying to do?
<tehk> Run it with compiz in gutsy on a nvidia gpu. It will crash and let you know! Just joking. I really do not know.
<mvo> kylem: if we turn on compiz-by-default we will have issues with windowed 3d. I want to find a way to detect non-fullscreen glx apps and issue a warning 
<mvo> possible even try to workaround some issues
<mvo> but a warning would be a good start
<ubotu> New bug: #132983 in xserver-xorg-video-ati (main) "video playback is not fluent" [Medium,New]  https://launchpad.net/bugs/132983
<ubotu> New bug: #133830 in xorg (main) "1680x1050 not recognized on xubuntu 7.10 tribe4" [Undecided,New]  https://launchpad.net/bugs/133830
<ubotu> New bug: #133831 in xserver-xorg-input-synaptics (main) "[Gutsy]  after resume synaptics touchpad goes haywire." [Undecided,New]  https://launchpad.net/bugs/133831
<tepsipakki> rock; Build Operating System: Linux Debian (xorg-server 2:1.3.99.0-2ubuntu1)
<tepsipakki> oops, didn't change the vendor string
<tepsipakki> yeah, G965 works without Device-section
<ubotu> New bug: #133864 in xorg-server (main) "Upgrading from drapper: xserver failes (XGI)" [Undecided,New]  https://launchpad.net/bugs/133864
<bryce> tepsipakki: https://bugs.launchpad.net/ubuntu/+bug/126255 - what we were talking about
<ubotu> Launchpad bug 126255 in xserver-xgl "FTBFS" [Undecided,Confirmed]  
<tepsipakki> bryce: that's xserver-xgl..
<tepsipakki> bryce: I did manage to merge xorg-server though.. and also am testing 1.3.99.0 on couple of machines, a candidate for PPA when it's opened
<bryce> I've also made progress with my xorg-server merge - I think the issue I ran into earlier may have been due to a mesa version issue
<tepsipakki> my debdiff is here: http://users.tkk.fi/~tjaalton/dpkg/xorg/xorg-server.debdiff
<tepsipakki> nothing special there
<tepsipakki> patch 106 was broken though
<tepsipakki> it was maybe rediffed against a configured tree
<bryce> I've wondered if we should drop the -fno-stack-protector
<bryce> btw, did you do the merge manually or using MoM?
<bryce> yeah I also noticed patch 106 was busted
<tepsipakki> manually
<bryce> ahhh
<tepsipakki> always do
<bryce> I think grab-merge fscked things up for me
<tepsipakki> only the changelog is something to take from the MoM-generated tree
<tepsipakki> grab-merge is handy for fetching the packages too
<bryce> btw, I suspect most of the auto* stuff in patch 106 could/should be dropped, as it doesn't seem relevant to the patch
<tepsipakki> but otherwise I've done things manually, and then compared the debdiffs etc
* bryce nods
<bryce> grab-merge seems to have worked ok for me on the smaller packages
<tepsipakki> 106 only needs the -fPIC lines.. two hunks :)
<bryce> yup
<tepsipakki> you can see it in the debdiff above
<bryce> ah yeah that's a lot nicer
<bryce> the only other change I was thinking about is I notice the Build-Depends list libgl1-mesa-dev 6.5.1, and wondered if it should be 6.5.3?
<bryce> tepsipakki: since I don't have anything to add beyond what you've done, do you want to put this in for an upload, or would you like me to?
<tepsipakki> I can do it :)
<bryce> awesome, thank you :-)
<tepsipakki> the mesa-dep should be fine I think.. a sec
<bryce> also, I've been wondering how best to handle backporting fixes from 1.3.99/1.4.  Do you have thoughts on that?  Would it be worthwhile to go through the changelog and flag fixes we want, or wait until the bug is reported and then search for the fix, or...?
<tepsipakki> push them to the right PPA? :)
<tepsipakki> just kidding
<tepsipakki> I guess they need to be pulled carefully, since some changes need others etc.. it could be an bottomless swamp
<tepsipakki> -n
<bryce> yeah
<tepsipakki> hmm, I'll test without ssp on my ati
<tepsipakki> the libgl1-mesa-dev build-dep version is not that important IMO, since mesa-swx11-source build-dep is already versioned
<bryce> ok
<tepsipakki> and if someone has managed to install mixed versions it's his fault :)
<tepsipakki> jcristau: should the libgl1-mesa-dev build-dep version match mesa-swx11-source?
<jcristau> tepsipakki: not necessarily, i think
<tepsipakki> that's what I thought, since they should match each other anyway..
<tepsipakki> bryce: note that patch 108 was not applied for quite some time, so I dropped it from the diff and changelog. Fedora has dropped it as well
<bryce> ok
<tepsipakki> it's their crack, after all
<jcristau> the versioned dep on -source is because the symlinking script and Makefile.am have to be in sync with the mesa source layout
<tepsipakki> jcristau: maybe the version from libgl1-mesa-dev could be dropped, no?
<jcristau> 6.5.1 is in stable, so that's fine by me
<tepsipakki> ah
<tepsipakki> fairly cosmetic though
<bryce> heya alex-weej
<alex-weej> hi bryce
<alex-weej> my resolution-independence plan kinda hit a wall
<bryce> oh?
<alex-weej> i spoke with Benjamin Berg, upstream gtk engines maintainer, apparently there are a lot of places internally where we'd need to round to integers
<alex-weej> which means big huge steps as you scale up or down
<bryce> ah
<alex-weej> but that's not why i'm here
<bryce> what did they suggest?
<alex-weej> you can probably help me bryce :)
<bryce> hope so :-)
<alex-weej> http://rafb.net/p/p58Rw657.html
<alex-weej> from ubuntu-devel, couldn't be bothered to type it all out again :P
<bryce> heh
<bryce> yeah, displayconfig-gtk does not play well with lrm stuff yet
<bryce> I'd posted a bug already about how you can't select binary drivers
<bryce> can you also enter a bug against it about this issue too?
<alex-weej> sure, is it definitely a problem (i haven't actually tested it, i just assumed nothing had changed)
<bryce> it might be worthwhile to test displayconfig-gtk from bzr; iirc there's been work on it since what's available in gutsy
<alex-weej> bzr :O i've never used it
<bryce> alex, it's much like svn or git
<bryce> standby
<bryce> bzr co http://bazaar.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
<bryce> then bzr diff to get a diff of any changes you make
<tepsipakki> running xserver on ati without specifying no-stack-protector in debian/rules
<tepsipakki> so far so good
<bryce> tepsipakki, I've just finished reading through the 1.3.99 changelog, and have flagged some of the changes that sound worth investigating:  https://wiki.ubuntu.com/X/Fixes_to_Backport
<tepsipakki> that's one hell of a list :)
<bryce> yup
<bryce> but the number of items of interest is not too huge
<bryce> I'm going to write a script to try to identify the commit id's for them from xserver git log
<tepsipakki> yes, looks good
#ubuntu-x 2007-08-22
<bryce> tepsipakki: https://wiki.ubuntu.com/X/Fixes_to_Backport
<bryce> tepsipakki: I identified (nearly) all the commit ID's for the changelog entries that looked interesting
<tepsipakki> wicked :)
<tepsipakki> I'm trying to build dri-driver for my r200 with an experimental zero-copy-tfp patch, but it just isn't my day (/night)
<ubotu> New bug: #132065 in compiz (main) "screen stops refreshing after rotate when running compiz fusion" [Undecided,New]  https://launchpad.net/bugs/132065
<tepsipakki> bryce: what about libx11+xcb, have you thought about that?
<bryce> tepsipakki: oh yeah, we should include that in the plans for gutsy+1
<bryce> http://www.desktoplinux.com/news/NS4979518777.html
<ubotu> New bug: #133726 in xserver-xorg-video-intel (main) "totem fails with BadAlloc with mpeg4 film" [Medium,New]  https://launchpad.net/bugs/133726
<ubotu> New bug: #130914 in compiz (main) "[Compiz/nvidia-glx-new] Running glxgears while using compiz restarts x (dup-of: 130325)" [Undecided,New]  https://launchpad.net/bugs/130914
<ubotu> New bug: #34620 in Ubuntu "Live CD / "Cannot Display this Mode"" [Medium,Invalid]  https://launchpad.net/bugs/34620
<ubotu> New bug: #29984 in Ubuntu "Frequecy too high after installation with Nokia 446PRO + Geforce 420Mx" [Low,Confirmed]  https://launchpad.net/bugs/29984
<tepsipakki> bryce: heh, getting the facts straight
<tepsipakki> bryce: so, it's ok if I upload the xorg-server without -fno-stack-protector?
<tepsipakki> works fine here
<tepsipakki> with ati..
<bryce> heya tepsipakki
<bryce> tepsipakki: Yes I think so.  It would be nice if we could get verification from the original bug reporters, but I think it's fine
<tepsipakki> that's easy to revert if needed
<bryce> excellent, thanks
<jcristau> re: desktoplinux.com, they talk about automatic monitor detection, but that's in 1.3, not 1.4...
<bryce> yeah.  I sent a correction about that to the reporter
<jcristau> oh, sjvn. didn't notice it was him...
<tepsipakki> uh, I'm too tired.. I'll upload xorg-server tomorrow, main is frozen anyway. bye!
<jcristau> good night tepsipakki 
<bryce> tepsipakki: sounds good, and good night :-)
<ubotu> New bug: #45290 in Ubuntu "system freeze when screensaver is trying to start (dup-of: 67487)" [Medium,Incomplete]  https://launchpad.net/bugs/45290
<bryce> tepsipakki: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/133192
<ubotu> Launchpad bug 133192 in xserver-xorg-video-ati "Screen displays garbage" [Undecided,Confirmed]  
<bryce> tepsipakki: I wonder if we should include both the newer and older -ati's?  hrm
<ubotu> New bug: #134141 in xorg (main) "fix for scroll wheel in x60 tablet fujitsu p1510 fujitsu p1610" [Undecided,New]  https://launchpad.net/bugs/134141
<ubotu> New bug: #42898 in xorg-server (main) "Connecting External Monitor does not work on Thinkpad x60" [Medium,Confirmed]  https://launchpad.net/bugs/42898
<ubotu> New bug: #132909 in xserver-xorg-input-mouse (main) "frozen mouse pointer at login" [Undecided,New]  https://launchpad.net/bugs/132909
<ubotu> New bug: #55142 in linux-restricted-modules-2.6.17 (restricted) "ATI Xpress 200 5A61 Chashes" [Undecided,Incomplete]  https://launchpad.net/bugs/55142
#ubuntu-x 2007-08-23
<ubotu> New bug: #134153 in xorg (main) "[gutsy]  xorg failed to start on an Intel 945 using Kubuntu desktop CD daily build 20070822.1" [Undecided,New]  https://launchpad.net/bugs/134153
<bryce> tepsipakki: possibly your xorg-server upload will take care of this vesa issue
<ubotu> New bug: #133214 in xserver-xorg-driver-ati (main) "doesn't load the gnome desktop" [Undecided,New]  https://launchpad.net/bugs/133214
<tepsipakki> bryce: it will
<kylem> need sponsoring?
<tepsipakki> kylem: no, I can upload it :)
<tepsipakki> bryce: having them both.. maybe a better idea to keep airlied busy for the next two months :)
<kylem> tepsipakki, ah. good.
<tepsipakki> bryce: did you notice that ati-6.6.193 is a dead end, and they decided to merge randr-1.2 -branch in it, and released 6.7.191? :)
<tepsipakki> so, we need that
<bryce> yup
<bryce> I talked with them about it earlier today
<tepsipakki> ok, I didn't read the backlogs :)
<bryce> they were pondering merging that branch to main and I jumped in and said if they did, we'd be up for putting it in gutsy :-)
<tepsipakki> ah, right :)
<tepsipakki> so, how do we proceed? I can do the package and upload
<tepsipakki> and put it somewhere for people to test before it gets in
<bryce> yes
<tepsipakki> or maybe not in that order, but anyway
<bryce> right
<bryce> get some debs built and then post them to the X Test forum so the guys there can test it
<tepsipakki> hmm, need to set up an account then :)
<bryce> there's two ati users there that have been quite thorough in their testing
<bryce> yup :-)
<tepsipakki> ah, good
<bryce> we probably also ask at least half a dozen of the recent ati bug reporters to try it out as well
<bryce> I figure if we can point to a couple bugs that the new release has proven to fix, then it'll make justifying the change easier
<tepsipakki> there should be loads of them
<tepsipakki> I think that saying "upstream won't support that code" is a strong argument :)
<tepsipakki> all that it takes
<bryce> btw, I also have continued some work on identifying xserver backports - https://wiki.ubuntu.com/X/Fixes_to_Backport
<tepsipakki> airlied just said that they'll have pretty much all of 1.4 instead input-hotplug for F8 :)
<bryce> yeah hopefully so.  I'm keeping an eye on how the -avivo uvf exception goes
<bryce> I'm looking forward to ubuntu having a much more stable X than fedora ;-)
<tepsipakki> a respectible goal ;)
<tepsipakki> -table, duh
<bryce> ok, bbl (movie time)
<tepsipakki> and I should be dropping the kids for daycare
<tepsipakki> then work
<tepsipakki> later ->
<tepsipakki> bryce: bug 103945 is a dupe of bug 89853 :)
<ubotu> Launchpad bug 103945 in xorg "desktop cd fails to start gdm with hp nc6400 (widescreen, ati-based laptop)" [High,Confirmed]  https://launchpad.net/bugs/103945
<ubotu> Launchpad bug 89853 in xorg-server "[regression]  7.2 broke vesa: "No matching modes found"" [Unknown,Confirmed]  https://launchpad.net/bugs/89853
<tepsipakki> but they'll both get fixed, so no worries
<tepsipakki> oh, maybe it's not a direct dupe after all..
<bryce> tepsipakki: ah good to know
<tepsipakki> oh, debian already has 6.7.191-1 :)
<tepsipakki> that was quick
<bryce> yay
<bryce> let's get it in :-)
<tepsipakki> let's
<bryce> well, I should say - let's get some .debs of it posted for testing... *then* let's get it in.  ;-)
<tepsipakki> sounds better. I'll build it here
<bryce> tepsipakki: also, could you post .debs of your xorg-server for the folks in the forum to test?
<bryce> heya seb128
<tepsipakki> bryce: or just upload it?
<tepsipakki> it's few weeks until the next freeze
<seb128> hi bryce
<tepsipakki> hey seb128, you have an ati board right?
<seb128> tepsipakki: indeed
<seb128> radeon 9600 pro
<tepsipakki> seb128: right, you are one of the lucky testers for 6.7.191 :)
<bryce> hmm, with things like xorg, xorg-server, and major drivers, I typically prefer to get independent verification before putting in for an upload
<tepsipakki> bryce: ok, that's fine
<bryce> since this is going to be pulling in a number of patches, I'd really like to see one or two users verify it 
<tepsipakki> uh, I need to reinstall the box first, it'll take a while
<tepsipakki> since it didn't netboot yesterday
<tepsipakki> but hang on
<tepsipakki> (some depends-problems with kernel)
<bryce> hmm, I think I can build a .deb here locally if you're having some troubles
<tepsipakki> bryce: yeah, go ahead and build the ati
<tepsipakki> oh, new d-i image
<bryce> oh whoops, I thought we were talking about xorg-server
<tepsipakki> that should do it
<tepsipakki> booting.. it should install just fine now
<tepsipakki> so.. less than an hour to have debs ready :)
<bryce> excellent
<jcristau> xorg-server -12 got quite some testing in sid and lenny at this point, fwiw
<bryce> jcristau: good to know
<tepsipakki> yep, it should be safe
<jcristau> bryce: the patch "Use kbd driver when xorg.conf specifies "keyboard" or "Keyboard" (bug #11301)" (from your Fixes_to_Backport page) is in -8, fwiw
<ubotu> Launchpad bug 11301 in nautilus "If a file is downloaded to a directory that is open in Nautilus, that file doesn't appear in the folder window when the download completes" [Medium,Fix released]  https://launchpad.net/bugs/11301
<jcristau> ubotu: not that one, fdo #11301 :)
<tepsipakki> heh :)
<tepsipakki> bad ubotu
<jcristau> "remove CID support" was already done in 7.2
<jcristau> and "xnest: fix linking since dbus" isn't relevant with 1.3 because you don't have dbus anyway
<bryce> jcristau: thx, page updated
<jcristau> the commits about Xvesa aren't relevant because the only kdrive-based server we/you're shipping is Xephyr
<tepsipakki> jcristau: don't you have a paper to write? :)
<tepsipakki> (not that I mind a bit if you go through the list :)
<tepsipakki> (but positively)
<jcristau> tepsipakki: we stopped about 2 hours ago, so now i'm just not sleeping because of too much coffee
<tepsipakki> hehe :)
<bryce> jcristau: I've heard we've got some people very interested in Xephyr for Ubuntu
<bryce> however I only marked it because I wanted to get every fix related to vesa
<jcristau> Xvesa is the code under hw/kdrive/vesa, which we're not shipping
<tepsipakki> uh, still can't install gutsy.. now it's ubuntu-desktop claiming gnome-nettool can't be installed
<bryce> ok, I wasn't sure about that
<bryce> page updated
<jcristau> "ffs: handle 0 argument" was also fixed some time ago
<jcristau> it was upstream in 1.2, fixed in debian in 2:1.1.1-11
<jcristau> "xfree86/linux acpi: fix tokenising" was in 2:1.1.1-16
<jcristau> "Multiple integer overflows in dbe and render extensions" was in 1.2 too
<jcristau> "Fix for a divide by zero that can be triggered by a malicious client." was presumably also fixed earlier, it's CVE-2007-2437
<ubotu> The X render (Xrender) extension in X.org X Window System 7.0, 7.1, and 7.2, with Xserver 1.3.0 and earlier, allows remote authenticated users to cause a denial of service (daemon crash) via crafted values to the (1) XRenderCompositeTrapezoids and (2) XRenderAddTraps functions, which trigger a divide-by-zero error. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2437)
<bryce> updated
<jcristau> looks like 2:1.3.0.0.dfsg-4 on our side
<jcristau> i think that's all that looks familiar in the list :)
<bryce> cool, thanks, that helps a lot
<tepsipakki> bryce: btw, I emailed the guy who has been doing randr work for wacom (Magnus Vigerlf). He's been busy lately and hasn't followed xorg upstream for some months now, but said that once 1.4 is out he'll take a closer look
<bryce> ok cool
<bryce> 'night
<tepsipakki> yeah, night.. I'll put those debs somewhere once the machine has managed to install itself
<ubotu> New bug: #66755 in ubuntu "mouseup events sometimes (randomly?) lost (dup-of: 47971)" [Undecided,New]  https://launchpad.net/bugs/66755
<ubotu> New bug: #28473 in xserver-xorg-driver-ati (main) "Freeze when moving between workspaces" [Medium,Fix released]  https://launchpad.net/bugs/28473
<ubotu> New bug: #134248 in ubuntu "window video format bad playback, possibly other formats also (dup-of: 122979)" [Undecided,New]  https://launchpad.net/bugs/134248
<ubotu> New bug: #134284 in xorg (main) "The X intel driver is not functioning correctly" [Undecided,New]  https://launchpad.net/bugs/134284
<tepsipakki> bryce: the packages are here: http://users.tkk.fi/~tjaalton/dpkg/
<tepsipakki> I replied one forum post, but can't add new ones on the dev section
<tepsipakki> ..until I have the power to do so
<bryce> awesome
<ubotu> New bug: #134310 in xorg (main) "GeForce2 Go + Nvidia driver causing system freezes" [Undecided,New]  https://launchpad.net/bugs/134310
<ubotu> New bug: #47359 in xorg-server (main) "Mouse Icons do not change in dual screen setup" [Medium,Confirmed]  https://launchpad.net/bugs/47359
<ubotu> New bug: #47638 in ubuntu "Artifacts on application buttons" [Medium,Confirmed]  https://launchpad.net/bugs/47638
<ubotu> New bug: #46643 in ubuntu "SONY VAIO VGN-FS215E no more screen (black screen) during edubuntu / ubuntu installation" [Medium,Incomplete]  https://launchpad.net/bugs/46643
<ubotu> New bug: #134228 in xorg (main) "Gutsy Tribe 4 Live CD cannot boot: Xorg fatal error" [Undecided,New]  https://launchpad.net/bugs/134228
<bryce> hi tormod
<tormod> hi bryce
<tormod> trying out ati 6.7.191 now - no luck on X700 :(
<tormod> (log in https://bugs.freedesktop.org/show_bug.cgi?id=5473)
<ubotu> Freedesktop bug 5473 in Driver/Radeon "Blank screen with Radeon Mobility X700 (Acer Ferrari 4005)" [Major,Reopened]  
<tormod> oh btw vesa is also broken on X700...
<ubotu> New bug: #134349 in linux-restricted-modules-2.6.20 (restricted) "modules.alias.override/ath_hal won't detect an Apple MacBook Atheros card" [Undecided,New]  https://launchpad.net/bugs/134349
<jcristau> tormod: with which version of xserver-xorg-core?
<tormod> jcristau: xserver-xorg-core_1.3.0.0.dfsg-12ubuntu1_i386.deb from Timo.
<jcristau> hmm weird
<tormod> While looking for duplicates, I found bug #89853, with the comment that -12 should fix this.
<ubotu> Launchpad bug 89853 in xorg-server "[regression]  7.2 broke vesa: "No matching modes found"" [Unknown,Confirmed]  https://launchpad.net/bugs/89853
<tormod> but I am not sure how long vesa has been broken, haven't tried it for a while.
<bryce> hrm
<jcristau> ajax's patch in -7 fixed it for some people so i was hoping you were using -6ubuntu<mumble>
<jcristau> :)
<bryce> hehe
<tormod> jcristau: hang on - maybe I used the old xorg with vesa and didn't try vesa after upgrading xorg... I'll check.
<bryce> tormod: no, I doublechecked that in your log
<bryce> tormod: Build Operating System: Linux Ubuntu (xorg-server 2:1.3.0.0.dfsg-12ubuntu1)
<jcristau> hehe, i kind of thought including the package version in the log would be useful sometimes :)
<tormod> jcristau: just what I thought too :)
<tormod> I had the new -12 I am afraid.
<tormod> xorg crashes in InitOutput
* tormod fights with gdb and Xorg, and gdb and Xorg just want to fight with each other
<tormod> does anyone have a debug build handy? the -dbg package doesn't make it, and I just run this from a live cd. building would take forever.
<bryce> tepsipakki might, but I think he's asleep at the moment
<tepsipakki> I'm back, just had to stand for three hours before an audience :)
<bryce> ahh, wb :-)
<tepsipakki> (hndel, the messiah..)
<tepsipakki> tormod: make sure you don't have the patched vesa from my repo
<tormod> tepsipakki: no I haven't
<tepsipakki> ok
<tepsipakki> I remember that making it crash
<tormod> are the xorg drivers still being stripped in -dbg packages?
<tepsipakki> shouldn't be
<tepsipakki> dh_strip --dbg-package=xserver-xorg-video-ati-dbg
<tormod> tepsipakki: Bug #78293
<ubotu> Launchpad bug 78293 in xorg-server "libraries get stripped even with debug build" [Undecided,New]  https://launchpad.net/bugs/78293
<tormod> (I filed that in January, but haven't checked recently)
<jcristau> tormod: check out the changelog entry for 2:1.2.0-4
<jcristau> hmm no that's not it
<jcristau> let me check
<tepsipakki>   [ Julien Cristau ] 
<tepsipakki>   * Don't strip modules when DEB_BUILD_OPTIONS contains nostrip.  Thanks,
<tepsipakki>     Cyril Brulebois!
<tormod> tepsipakki: can you check your build log?
<tepsipakki> tormod: I'm afraid pbuilder doesn't save that :/
<tepsipakki> at least it didn't
<tormod> where did ubotu go ? :)
<tepsipakki> for a pint
<tepsipakki> ;)
<tormod> #0  0xb7c7aaec in ?? () from /usr/lib/xorg/modules/drivers//vesa_drv.so
<bryce> tepsipakki: do you use the --logfile option for pbuilder?
<tepsipakki> no :)
<tepsipakki> I'll rebuild
<jcristau> tormod: the drivers use standard dh_strip. so if you build with nostrip it should be ok
<tormod> I don't build :) I use tepsipakki's -dbg.
<jcristau> you have a -dbg for vesa?
<bryce> tepsipakki: I was reading the UVF/FF exception process and saw that they like having the build-log and install-log (at least, for MOTU UVF exceptions)
<tormod> jcristau: eh right, no I haven't (blush)
<tepsipakki> bryce: yep, I'll rebuild ati too
<jcristau> anyway bug 78293 is fixed for a long time :)
<bryce> tepsipakki: do you think we should drop 120_fedora_disable_offscreen_pixmaps.diff?  (https://bugs.freedesktop.org/show_bug.cgi?id=11626)
<tepsipakki> bryce: unfortunately, without that compiz-performance is unbearable.. for the next release we'll hopefully get zero-copy tfp working for more than just r300, then we should be able to drop all those fedora-hacks :)
<tepsipakki> I've been playing with that on my r200, but somehow the zc-tfp -patch has no effect
<bryce> ok cool
<tepsipakki> that's one of the reasons why I don't think "compiz-by-default" is a feasible goal for gutsy.. it's still not stable enough
<tepsipakki> but that's just me :)
<tepsipakki> "stable" meaning less regressions
<tepsipakki> and stuff
<bryce> tepsipakki: there was a lot of discussion last week on ubuntu-devel@ with much the same feeling from many
<tepsipakki> there was? how did I miss that.. checking now
<jcristau> that's also basically what krh was saying on his blog a few days ago
<tepsipakki> right, I _have_ read that thread
<tepsipakki> :)
<tepsipakki> krh's recent work regarding windowed 3d looks great
<bryce> tepsipakki: did you see tormod's bug 22985 about still needing patch 105_fdo_att7409_bug5437.diff? 
<ubotu> New bug: #134365 in xserver-xorg-video-intel (main) "Playing Video in Totem blanks screen for 2 seconds" [Undecided,New]  https://launchpad.net/bugs/134365
<ubotu> Launchpad bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Confirmed]  https://launchpad.net/bugs/22985
<tepsipakki> tormod: regarding that bug; upstream has said that the forward is the "pci-rework" stuff IIRC
<tepsipakki> +way
<bryce> tepsipakki: since it sounds like the patch still applies, would there be any harm in including it for now until that rework hits?
<bryce> or am I misunderstanding...
<tepsipakki> apparently it doesn't apply on top of 6.7.191
<bryce> tormod: let me know if the issue still exists in 6.7.191, and if so I'll try refreshing the patch to apply against it
<tepsipakki> tormod: you could ping agd5f/airlied on #xorg about it..
<tormod> bryce: as said in the fdo bug, 6.7.191 doesn't even start on X700.
<bryce> ah, hrm
<tormod> agd5f/airlied are cc'ed on that fdo bug.
<tormod> about vesa, the pScrn->display->modes linked list in vesa.c (line 683) is broken
<tepsipakki> tormod: yes they are, but perhaps they'd be more responsive on irc :)
<tormod> tepsipakki: they are not in #xorg ATM
<tepsipakki> ah, crap
<jcristau> -devel
<tormod> jcristau: thanks, of course :)
<tormod> how can I tell gdb where ../../src/vesa.c is?
#ubuntu-x 2007-08-24
<tormod> I added some gdb results to bug #89853, all I have time and energy for today.
<ubotu> Launchpad bug 89853 in xorg-server "[regression]  7.2 broke vesa: "No matching modes found"" [High,Fix committed]  https://launchpad.net/bugs/89853
<tormod> good night
<ubotu> New bug: #134395 in xserver-xorg-video-intel (main) "[gutsy]  corrupt textures" [Undecided,New]  https://launchpad.net/bugs/134395
<ubotu> New bug: #134401 in xorg (main) "p1610 fujitsu tablet screen does not autorotate and touchscreen does not work" [Undecided,New]  https://launchpad.net/bugs/134401
<ubotu> New bug: #134448 in xorg-server (main) "3D acceleration doesn't work when multiple sessions are open" [Undecided,New]  https://launchpad.net/bugs/134448
<ubotu> New bug: #67051 in xserver-xorg-input-keyboard (main) "Tajik keyboard not working correctly" [Undecided,Incomplete]  https://launchpad.net/bugs/67051
<tormod> tepsipakki: before you release any new ati driver, please include the "Always assume LVDS is connected" commit. It fixes (at last) my X700.
<tepsipakki> tormod: really? that's wonderful news :)
<tepsipakki> I guess it's wise to wait for .192 before pushing it in
<tepsipakki> there's a fix that calculates the default Virtual value correctly
<tormod> it is! after all these years, my card finally works without patches.
<tormod> yes there's a a lot of things coming into git ATM
<ubotu> New bug: #95867 in xserver-xorg-video-i810 (main) "Gnome recognizes the resolution 1368x768 instead of 1366x768" [Low,New]  https://launchpad.net/bugs/95867
<tepsipakki> hmm, I could just pull those commits in and build a new package
<tepsipakki> those two
<tormod> tepsipakki: that would be nice, while we wait for .192 we can get the X700 people try this.
<tepsipakki> tormod: you can find a new version on the same place to test
<ubotu> New bug: #134463 in xserver-xorg-driver-i810 (main) "No 1280x1024 resolution with i965" [Undecided,New]  https://launchpad.net/bugs/134463
<ubotu> New bug: #134464 in xserver-xorg-video-intel (main) "in dual head config a row of pixels is drawn on the wrong monitor" [Undecided,New]  https://launchpad.net/bugs/134464
<ubotu> New bug: #59474 in vmware-player "[feisty]  VMWare bridged networking doesn't work with madiwifi-ng" [Medium,Invalid]  https://launchpad.net/bugs/59474
<tepsipakki> hmm, tribe5 has compiz on by default
<ubotu> New bug: #134467 in xserver-xorg-video-ati (main) "[gutsy]  system halts "Black Screen" with xserver-xorg-video-ati.1.6.6.193-1ubuntu1" [Undecided,New]  https://launchpad.net/bugs/134467
<tepsipakki> ah, has been since tribe2
<ubotu> New bug: #134478 in xorg (main) "mouse stops working when switching to different X vt" [Undecided,New]  https://launchpad.net/bugs/134478
<ubotu> New bug: #134482 in xorg (main) "VT switching to locked AIGLX session shows nothing but white screen." [Undecided,New]  https://launchpad.net/bugs/134482
<ubotu> New bug: #134486 in xorg (main) "Gnome screen unlock should also show already opened sessions" [Undecided,New]  https://launchpad.net/bugs/134486
<soren> I've just attached a new LCD screen to my machine. My Xorg.0.log is at http://pastebin.ca/669121  The problem is that the log shows the 1440x900 resolution (the max), but I can't seem to chose that with xrandr (and gdm shows up with 1280x1024, too). What to do?
<soren> I have no xorg.conf, so running the script in /topic won't do me any good.
<tepsipakki> soren: running without the conf isn't probably a good idea for you
<soren> tepsipakki: Clearly not.
<tepsipakki> generate the conf, and then change the driver to "intel"
<tepsipakki> if it's not already
<soren> I dpkg-reconfigured it, forcing it to use intel instead of i810 and now I'm happy :)
<tepsipakki> oh, cool :)
<soren> Didn't X used to have a "autogenerate a conf file" option?
<soren> "X -docoolstuff" or something.
<jcristau> Xorg -configure
<soren> Aha!
<soren> I'll try that next time I feel like cycling X.
<jcristau> it might be better than dpkg-reconfigure in some cases, and worse in some others...
<soren> Any particular reason why no xorg.conf means "use i810" rather than "use intel"?
<soren> Even if I removed the i810 driver package, it didn't fall back to intel, but rather to vesa. eek.
<tepsipakki> the server probably has some hardcodings..
<jcristau> without xorg.conf? that's weird
<soren> jcristau: That's what I thought.
<soren> tepsipakki: Based on what? pci id's?
<jcristau> it should just try stuff in /usr/lib/xorg/modules/drivers/
<jcristau> i think
<soren> jcristau:  I don't think so.
<soren> The logs never mention anything about any other video driver than i810.
<jcristau> can i see that log?
<tepsipakki> jcristau: http://pastebin.ca/669121
<tepsipakki> mentioned above
<jcristau> ah, indeed, hw/xfree86/common/xf86AutoConfig.c has some hardcoded stuff based on pci ids
<tepsipakki> yuck :)
<jcristau> aiui gravity's trying to fix that
<soren> I thought -intel was supposed to replace -i810 ?
<tepsipakki> it is
<tepsipakki> but some chips still have problems with intel, so i810 is kept for those
<tepsipakki> I'd wish more frequent releases of intel..
<bryce> morning
<bryce> yeah I was just fiddling with that code yesterday, and noticed it's hardcoded to use i810 instead of intel
<bryce> http://people.ubuntu.com/~bryce/Patches/xorg-server/psb_auto.patch
<ubotu> New bug: #134578 in xserver-xorg-video-ati (main) "Open source ati driver freeze with compiz" [Undecided,New]  https://launchpad.net/bugs/134578
<ubotu> New bug: #126385 in xserver-xorg-video-nv "Suspend/Hibernate with nv driver and NVIDIA 8400M GS doesn't work (dup-of: 121801)" [Undecided,New]  https://launchpad.net/bugs/126385
#ubuntu-x 2007-08-25
<tepsipakki> blargh
<tepsipakki> a user is requesting me to add "pad" to the wacom-madness :)
<tepsipakki> "no thank you"
<ubotu> New bug: #70537 in xorg (main) "System Randomly Locks X " [Undecided,In progress]  https://launchpad.net/bugs/70537
<ubotu> New bug: #134669 in xserver-xorg-video-intel (main) "Unfortunate Selection of Primary Display" [Undecided,New]  https://launchpad.net/bugs/134669
<bryce> tepsipakki: heh, agreed
<tepsipakki> input-hotplug is around the corner anyway
<ubotu> New bug: #134644 in xserver-xorg-input-mouse (main) "mouse quits working" [Undecided,Incomplete]  https://launchpad.net/bugs/134644
<tehk> Does anyone elses X crash when running GLXgears while using compiz?
<tehk> (in gutsy)
<ubotu> New bug: #134725 in xserver-xorg-video-i810 (main) "xrandr rotates screen, does not change resolution" [Undecided,New]  https://launchpad.net/bugs/134725
<rikai> bryce, i'll have to disagree with the post you made on ubuntuforums, i cant think of any work more sexy than xorg. If it weren't for X, we wouldnt have all those nifty effects and gui's period. ;)
<tehk> Is there any reason displayconfig-gtk displays two Screen 1s
<ubotu> New bug: #134737 in compiz (main) "Glitchy opengl apps (dup-of: 116793)" [Undecided,New]  https://launchpad.net/bugs/134737
#ubuntu-x 2007-08-26
<ubotu> New bug: #134817 in xserver-xorg-video-ati (main) "6.7.191 driver very slow for me (with composite) compared to 6.6.193" [Undecided,New]  https://launchpad.net/bugs/134817
<ubotu> New bug: #134846 in xorg (main) "akregator disables all video on Dell GX110" [Undecided,New]  https://launchpad.net/bugs/134846
<ubotu> New bug: #134809 in xorg (main) "[gutsy]  Gnome restart does not work in Tribe-5" [Undecided,Confirmed]  https://launchpad.net/bugs/134809
<ubotu> New bug: #134906 in xorg-server (main) "no man page for Xephyr" [Undecided,New]  https://launchpad.net/bugs/134906
#ubuntu-x 2008-08-18
<Ng> tjaalton: I saw mvo's post about evdev and input property jazz and emulatescroll - very happy to see that's possible in the new world order and my xorg.conf can finally die \o/
<tjaalton> Ng: yep, things are getting better, slowly but steadily ;)
<Ng> :)
<mvo> Ng: I managed to life without the scroll-wheel on middle button for two days, then I was so unerved that I had to check out how to get it back :)
<Ng> hehe
<Ng> I consider it a vital feature ;)
#ubuntu-x 2008-08-19
<bryce_> I got tired of hosting my scripts on people.ubuntu.com due to the security/etc. changes so have moved them all to http://bryceharrington.org/X
<tseliot> bryce_: will feature freeze prevent us from adding phase 1 to the screen resolution capplet?
<bryce_> yes, we should get it in before then.
<tseliot> bryce_: ok, currently python-xkit is in universe therefore we can't make the capplet depend on xkit. With my patch the capplet will check the existence of the python script and act as usual if none is found
<tseliot> bryce_: we should get screen-resolution-extra package into universe ASAP
<tseliot> bryce_: the code is here: https://code.launchpad.net/screen-resolution-extra
<bryce_> ok
<bdmurray> bryce_: any opinion on bug 152109?  how many it's fixed does it take to close the bug?
<ubottu> Launchpad bug 152109 in xserver-xorg-video-ati "gsm/startx will ignore xorg.conf resolution settings and run with very low resolution" [Medium,Incomplete] https://launchpad.net/bugs/152109
<bryce_> hm
<bryce_> "Firstable, ..."  heh
<bryce_> yeah that's a pretty old one and a lot's changed with resolution setting since then.  I think one "it's fixed" is enough.  Someone else can always reopen it
<bdmurray> Lastable - Fix Released!
#ubuntu-x 2008-08-20
<bdmurray> bryce_: I had an X crash and reconnected to my screen sessions and now can't start any gui apps
<bdmurray> from those screen session
<bryce_> weird
<bdmurray> using 'xhost +' worked around but that's not right
<bryce_> ahh, so they probably had an old XAuthorization or something
<bryce_> that's probably standard operating procedure
<bryce_> there's probably a way to re-get the auths
<bryce_> (if you care)
<bdmurray> yeah kind of
<bdmurray> I don't recall this happening on previous releases
<bryce_> start with man xauth
<bryce_> also doublecheck that X didn't start with a different $DISPLAY or something obvious like that
<bdmurray> bryce_: is 'AUDIT: Tue Aug 19 16:27:13 2008: 2667 X: client 29 rejected from local host ( uid=1000 gid=100 pid=31094 )' informative?
<bryce_> I think that confirms my earlier guess
<bdmurray> bryce_: setting the environment variable for XAUTHORITY fixes it too and my ~/.Xauthority is empty
<bryce_> cool
<bdmurray> my .Xauthority should be empty though should it?
<bdmurray> er, shouldn't
<bryce_> not if you launched X properly
<bryce_> (afaik)
<bdmurray> well, it restarted after a crash
<bryce_> hmm
<bdmurray> so its not my fault
<bryce_> you could try restarting X and see if it comes back.  If not,maybe try turning off gdm and launch X via startx and see if something useful appears on the console output
<bdmurray> no luck with restarting
<bdmurray> and I've no virtual consoles to kill gdm from
<bdmurray> :(
<bryce_> can you ssh into it and /etc/init.d/gdm stop ?
<bdmurray> error in locking authority file then
<bdmurray> user not authorized to run the X server
<tjaalton> x11perf -aa10text results on 965 w. compiz got 50% better with the exa upgrade patch from fedora
<tjaalton> ~53000 -> 85000
<tjaalton> still nothing stellar though
<Ng> wrt http://www.phoronix.com/scan.php?page=article&item=intel_x4500hd&num=1 - do we know what the support will look like for x4500s in intrepid?
<Ng> (the second page kinda suggests that intrepid will have some of the stuff required)
<Ng> my 945 desktop is getting a bit tired :D
<tjaalton> Ng: the intel driver already supports it
<Ng> tjaalton: ok, well I'm probably going to buy a motherboard with such a chip in the next few days, so I guess that box will be getting an Intrepid upgrade and I'll report back how it goes :)
<tjaalton> Ng: cool :)
<Ng> (mainly I want a mobo with a S/PDIF output, but since the 945 is very much failing to play HD content, I might as well step up to a better graphics chip too)
<tseliot> tjaalton: I would like to upload 1 new version of the NVIDIA (177) driver and some fixes for the other flavours. Will you be available later? (I'm uploading the source right now)
<tjaalton> tseliot: I'm here
<tseliot> tjaalton: ok, thanks, I'll give you the links to the files as soon as the upload is complete
<tjaalton> tseliot: so you need a sponsor? sure, I can upload them
<tseliot> tjaalton: yes, I don't have any kind of upload privilege and, even if I were a MOTU I couldn't upload the drivers since they are in main.
<tjaalton> first motu, then core-dev ;)
<tseliot> tjalton: yep, we'll see ;)
<tseliot> tjaalton: here's the list of links: http://albertomilone.com/ubuntu/newlrm/pitti/lista_ia.txt
<tjaalton> tseliot: thanks, downloading
<tjaalton> tseliot: the builds need tarballs too, since you've used -sa
<tjaalton> 173 & 177 uploaded
<tjaalton> tseliot: hmm I'll apt-get them
<tjaalton> uploaded
<tseliot> tjaalton: thanks. Sorry about the -sa thing, it's just that I use a script to create the source for all the drivers
<tjaalton> tseliot: np
<tseliot> bryce: I uploaded the package (screen-resolution-extra) to REVU
<tseliot> bryce: dholbach will review it too since we need 2 MOTUs
<tseliot> bryce: I have sent you an email with the link to my upload to REVU. Daniel told me that he would review it tomorrow
<bryce> tseliot: ok cool
<bdmurray> bryce: not every -ati bug uses the same driver right?
<bryce> no, all -ati bugs use the same driver
<bryce> however, to confuse things, the '-radeon' driver is an alias for -ati
<BraveSpear> anyone know anything about dexconf?
<bryce> so sometimes you'll get reports about -radeon, but that just means -ati
<bdmurray> what about r300?
<bryce> BraveSpear: a bit
<jcristau> bdmurray: r300 is the dri driver
<jcristau> -ati is a wrapper around radeon, r128 and mach64
<BraveSpear> I need to set screen resolution and refresh rate on a livecd i'm creating.  From what I understand, dexconf creates the xorg.conf on the fly.. I need to know how to have the livecd boot with a resolution of 1024x768 x 16bit color with 60hx frefresh rate
<BraveSpear> When it boots up, it auto detects the monitor and vid card, and dynamically sets the resolution, refresh and color depth on the fly. If it worked on all pc's, then it wouldn't be an issue (the livecd is one I am creating for our work-at-home users that need to access citrix via a web browser through vpn).
<BraveSpear> Any ideas how to do this?
<bdmurray> So my inability to recreate a -ati bug might not mean it is fixed then?
<bryce> BraveSpear: if I understand correctly, you're seeing some problems with certain pc's not getting autodetected properly, so are trying to default all pcs to the same minimal settings?
<bryce> yes you can force that in dexconf (you could also force the driver to be vesa, if you really want lowest common denominator settings).  However, generally we focusing on fixing the corner cases that don't work
<BraveSpear> bryce: thats what I've done as a workaround - XFORCEVESA as a kernel option, but I can only get 800x600 resolution that way.  Unless you know of a way to get it to default to 1024x768??
<BraveSpear> and thats what my manager wants -- lowest common denominator - he wants the cd to run on as many pc's as possible.
<bryce> It should go to 1024x768 if it can; unfortunately I think only 640x480 and 800x600 are guaranteed
<BraveSpear> If I can get this running, it will be a cost savings of millions of dollars for my company.
<BraveSpear> hmmm - maybe the kvm switch I am using is causing it to default to 800x600..
<BraveSpear> I'll try directly connected to the monitor.
<bryce> yeah many kvm switches don't forward the edid from the monitor
<bryce> so if you're testing monitor detection, don't use a kvm
<BraveSpear> thanks :P
<BraveSpear> I've been using linux as a casual user for a couple of years, and my boss seems to think that makes me qualified to create a livecd that will change the way our division does business
<BraveSpear> ;)
<bryce> to be honest, I suspect forcing to vesa and forcing reduced resolution isn't necessarily going to work better than the stock xorg autodetection, unless you're targeting extremely old or extremely unusual hardware
<BraveSpear> Well, I guess using gentoo for a couple of years counts for something
<bryce> hehe
<bryce> ah, gentoo's fun, I used that for a number of years myself
<BraveSpear> rofl - gentoo is fun like an enema is fun :P
<BraveSpear> :)
<bryce> hehe
<BraveSpear> well, directly connected to the monitor, the cd boots up to 1280x1024 @ 76hz
<BraveSpear> with the vesa driver
<bryce> btw, there is a version of dexconf at /etc/gdm/failsafeDexconf you should look at
<bryce> it does something similar to what you're doing (except without ambitions to get >800x640)
<bryce> BraveSpear: ah good, so that's fully supported then.  It should do 1024x768 as well if you use the Screen Resolution applet
<BraveSpear> so you think the vesa setting will work on 95% + of all computers?
<BraveSpear> (thats my managers requirement - not mine)
<bryce> well, there had been some problems with vesa on some ATI hardware, but I believe that's been resolved now.  I could be wrong
<bryce> but assuming that issue's gone, then yeah 95% with vesa at 1024x768 seems reasonable
#ubuntu-x 2008-08-21
<tjaalton> bryce: I'll start uploading the input properties stuff now, starting from inputproto
<bryce> heya tjaalton.  sounds good
<tjaalton> hum? lp doesn't show builds other than i386 anymore?
<tjaalton> need to wait for the proto to get in the archive first, then libxi and xserver after that
<crevette> hello
<tjaalton> hey
<kees> bryce: say, can include/misc.h have MAXCLIENTS raised?
<kees> bryce: maybe to 1024 from the current 256?
<kees> (a friend with like 20 work spaces and lots of RAM just ran into it, and it doesn't seem to be run-time configurable)
<pwnguin> how much extra ram will that allocate?
<kees> pwnguin: that I don't know.
<kees> I've opened bug 260138 for it, with upstream bug links, and proposed patches.  (they're untested, though)
<ubottu> Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Undecided,New] https://launchpad.net/bugs/260138
<pwnguin> i have to ask
<pwnguin> why does nabble know so much about mailing lists?
<pwnguin> kees: so uh. the stuff im reading says you'll need more than a simple header change?
<pwnguin> (if you've tested the patches, that's at least a good sign)
<kees> pwnguin: nope, I haven't tested anything -- just prepared patches based on the discussion.
<kees> pwnguin: I have no idea what the impact would be, but I figured since I could do the other legwork, I could contribute that bit.
<kees> honestly, if someone who know this area says "wtf? no way" that's fine too.  :)
<pwnguin> so that bit operation macro you wrote. it operates on ints?
<pwnguin> s/wrote/extended/
<tjaalton> at least rhel4 has those patches
<tjaalton> 20:52 < ajax> you trade more clients for fewer resources per client
<bdmurray> bryce: bug 219952's recent comments don't look like an -video-ati bug right?
<ubottu> Launchpad bug 219952 in xserver-xorg-video-ati "ubuntu 8.04 RC donÂ´t run in acer extensa 7620G - HD 2400 XT [1002:94c8] " [High,Incomplete] https://launchpad.net/bugs/219952
<tjaalton> bdmurray: it might still be the driver. the original issue seems resolved though (no picture with livecd)
<bdmurray> tjaalton: it's before X starts though right?
<tjaalton> bdmurray: ah, right.. that's the kernel/usplash doing something funny
<tjaalton> so this bug is fixed
<bdmurray> and they should open a new bug with those screenshots?
<tjaalton> I'd say so, yes
<bryce> yep
<tjaalton> bryce: I've pushed the IDP patches for xorg-server in git, and it should be ready to go. Anything to add?
<tjaalton> after that, driver support (evdev, synaptics) and a new xinput (and/or gui support) :)
<tjaalton> bryce: also, the "evdev keyboard model" mess is not over yet. Since it broke jp106 & ABNT2, svu and daniels thought that it would be best to force the evdev _rules_, not model, and to allow changing the model like before, and no need to force it in gnome-settings-daemon either
<bryce> hrm
<pwnguin> so what's the point of no return on this
<tjaalton> the evdev rules just need to add support for jp106 & ABNT2 (and whatnot)
<tjaalton> this is already in upstream. we just need to make sure no-one notices anything when they upgrade. it shouldn't be too hard
<tjaalton> pwnguin: what do you mean?
<pwnguin> i recall someone important saying that no one feature was worth holding back the whole release, but i cant recall when a feature has been tried and rolled back
<pwnguin> i can recall a few times where a feature was pushed in and left there
<tjaalton> we can't avoid evdev
<tjaalton> forever..
<jcristau> it's like the future or something
<tjaalton> yeah, or something
<pwnguin> im just wondering if there is such a mechanism in place
<pwnguin> recall pulse audio troubles in hardy =/
<tjaalton> pwnguin: it should not hold back anything.. the next alpha is due in two weeks so there's plenty of time to upload :)
<tjaalton> well, pulse..
<pwnguin> in the mean time, HAL is on its way out for devicekit...
<tjaalton> looks like it'll get sorted out finally
<tjaalton> the pulse mess that is
<pwnguin> i get the impression that pulse would have gone faster if it had been called "audioKit"
<pwnguin> for some reason the *Kits have a level of inevitability
<tjaalton> apart from the jp106 & ABNT2 brokenness, the input-hotplug change has been quite smooth
<bryce> yup
<bryce> although, it's not solved as many issues as I'd hoped... quite clearly input X drivers for uncommon devices don't get as much attention as they need
<pwnguin> thats why i worry about this devicekit thing
<pwnguin> it seems like every few years everyone runs away from the complexity of properly handling the broken hardware of the world
<tjaalton> bryce: what devices do you have in mind?
<bryce> tjaalton: game controllers, tablets, etc.
<jcristau> why wouldn't game controllers work with evdev?
<pwnguin> depends on your definition of game controller
<pwnguin> as for why it might not work, have you tried any jcristau?
<jcristau> no
<pwnguin> well, you're not alone
 * jcristau <- not a gamer
<pwnguin> heh
<pwnguin> gamers dont use joypads on PC
<pwnguin> they're so pedestrian
<pwnguin> plus, there's so many of them, with different numbers of buttons and sticks and layouts
<pwnguin> so we wind up with a few games in Ubuntu that are Designed for Xbox 360
<bryce> it's not so much they don't work, just that there's some manual configuration needed that we could probably do a lot more cleanly
<bryce> also there's some driver issues, like certain buttons not working, or features not working in the same modes, etc.  little stuff
<tjaalton> hmm, my rumblepad doesn't seem to like evdev, or the other way around
<tjaalton> (WW) Logitech Logitech RumblePad 2 USB: Don't know how to use device
<tjaalton> but usually it's just that the fdi-files need to know about the devices (like the apple trackpads)
<tjaalton> evdev should have the same features as mouse has, plus properties
<tjaalton> and non-serial tablets should work OOTB
<tjaalton> by now
<tjaalton> evdev only has two bugs, of which one is likely fixed and the other one is asking for the moon
<tjaalton> maybe I'll debug joysticks tomorrow then ;)
<pwnguin> tjaalton: so protocol IV stuff is serial -- i should be making fdi rules for that?
<tjaalton> pwnguin: serial devices can't be autodetected AIUI
<tjaalton> you need some input from them first
<pwnguin> heh
<pwnguin> theres another trick
<pwnguin> dont detect the serial
<pwnguin> detect the laptop that should have one
<tjaalton> that should work
<tjaalton> could
<pwnguin> unfortunately, the laptop team is dead
<tjaalton> so revive it?-)
<pwnguin> well, i kinda have
<pwnguin> the toshiba tablet team!
<tjaalton> btw, just matching the laptop model doesn't work. you need to match the device
<tjaalton> and then tell it to load the driver for that device
<pwnguin> "device"
<tjaalton> you can't say "oh, this is toshiba FOO, load wacom" and expect it to work :)
<tjaalton> see the output of lshal
<tjaalton> your mouse probably has several devices
<tjaalton> of which only one is the device that the driver can handle
<tjaalton> the one that has info.capabilities ~= input.mouse
<pwnguin> lshal's pretty damn long
<pwnguin> heh
<pwnguin> udi = '/org/freedesktop/Hal/devices/pnp_WACf004' info.capabilities = {'input', 'input.tablet', 'input.tablet.tabletPC'} (string list)
<pwnguin> those ones
<tjaalton> there you go
<tjaalton> is that a serial device?
<pwnguin> yes
<tjaalton> sweet
<pwnguin> two of em
<pwnguin> err
<tjaalton> so the wacom fdi should match the info.product of it
<pwnguin> tjaalton: the launchpad team "Toshiba Tablet Team" should have an email you can reach random wacom tester/motu/devs at
<tjaalton> ok
<bdmurray> bryce: about bug 163044 if I can't recreate that is not an indication it is fixed right?
<ubottu> Launchpad bug 163044 in xserver-xorg-driver-ati "[M6] terminal display error when reading PDF files" [Unknown,Confirmed] https://launchpad.net/bugs/163044
<bryce> bdmurray: generally if you were able to reproduce the bug in some fashion, and then with current code the problem does not occur, then that's considered a verification of a fix
<bryce> however, if you're never able to reproduce the problem, and it just works, that's not sufficient to confirm it as fixed.
<bdmurray> bryce: okay, but I never saw the bug originally so won't comment
<bryce> if you have identical hardware to the reporter, then *maybe* that can be considered fixed, but it'd still be good to ask the original reporter to confirm.
<pwnguin> tjaalton: where is this wacom.fdi?
<pwnguin> tjaalton: so I can see this wacom rules mentioned in the changelog and in the source package, but it's not in the binary...
<pwnguin> anyone wanna confirm what i think is wrong with this patch?
<pwnguin> +	mkdir -p debian/$(package_xorg)/usr/share/hal/fdi/policy/20thirdparty/
<pwnguin> +	dh_install debian/10-wacom.fdi usr/share/hal/fdi/policy/20thirdparty/
<pwnguin> +err
<pwnguin> <-- fails
#ubuntu-x 2008-08-22
<tjaalton> pwnguin: duh, you're right
<tjaalton> pwnguin: actually, seems that those lines were just missing from the latest upload, for whatever the reason
<tjaalton> bryce: my rumblepad works right with the joystick driver. the problem is that the fdi file needs a lot of "quirks" because every device that evdev can't handle needs to be listed
<tjaalton> but since that is done upstream it just takes some time to get all the devices in there
<tjaalton> (gather the information from distros etc)
<bryce> hmm
<bryce> yeah I was playing with mnemtok's controller tonight trying to get it working
<tjaalton> like the synaptics fdi file is in upstream master
<soren> tjaalton: Don't worry any more about the evdev+kvm tragedy. It's 80% fixed, and the remaining 20% is on the way.
<mvo> what happend?
<tjaalton> soren: *phew*
<soren> mvo: Was that a question for me?
<mvo> soren: yes, I was curious what happend so that its fixed now (well, almost)
<soren> mvo: We came up with a way to detect if evdev was used on the host and added an entirely new translation mechanism for that.
<tjaalton> bryce: btw, joystick isn't installed by default
<tjaalton> dunno if it should be or not
<tjaalton> probably
<bryce> yeah I think it should
<tjaalton> Installed-Size: 24
<soren> mvo: In gtk-vnc, that is.
<tjaalton> probably won't fit on the cd :)
<mvo> soren: aha, ok. so I should finally abandon the old xvncviewer :) ?
<soren> mvo: Which accounts for all the frontends we really care about (virt-manager, vinagre, virt-viewer, etc). SDL (i.e. the frontend you get if you run kvm from the command line) is still lacking, but that's on its way.
<soren> mvo: There's gvncviewer, which uses gtk-vnc.
<mvo> excellent news, I like that
<soren> mvo: I don't think it has a "-via" option, though.
<soren> I use that all the time.
<tseliot> tjaalton: can you upload these drivers for me, please? http://albertomilone.com/ubuntu/newlrm/pitti/lista_ia.txt
<tjaalton> tseliot: ok, will do
<tseliot> tjaalton: thanks
<tjaalton> tseliot: uploaded
 * mvo waves to tseliot
<tseliot> mvo: hi ;)
<tseliot> tjaalton: great, thanks again
<pwnguin> well
<pwnguin> the marketing copy on ubuntu.com says it just works"
<pwnguin> I'm sure one or two people would say that joysticks are part of just working =/
<tseliot> pwnguin: "it just works" != "anything piece of hardware will work" ;)
<tseliot> any
<tseliot> not anything
<pwnguin> im sure people will deliberately misconstrue it anyways
<tseliot> of course
<pwnguin> especially if it previously worked
#ubuntu-x 2008-08-23
<tjaalton> joysticks didn't "just work" before, since the driver is not installed by default, and it needed special attention to xorg.conf..
<Ng> tjaalton: sooo, got the new motherboard. today's daily live CD boots up, but I'm not seeing any X love ;)
<Ng> the live cd is a bit useless for debugging though, so I'm gonna dist-upgrade the hardy install so I can at least ssh in and have persistent logs and stuff
<Ng> hmm
<Ng> it kinda works a bit
<Ng> but it seems rather fragile
<Ng> and when X does start, I'm getting no input from my usb kb/mouse
 * Ng hmms
<Ng> X clearly hasn't crashed though, I can see the cursor blinking in the gdm username box, and numlock works
<Ng> gar, why isn't sshd running
<Ng> maybe this is bug 254840, but xserver-xorg-input-all is installed
<ubottu> Launchpad bug 254840 in xorg-server "[intrepid] mouse and keyboard stop working under gdm and gnome" [Medium,Triaged] https://launchpad.net/bugs/254840
<Ng> oh, haha, it's something to do with booting into recovery and starting gdm directly. normal boot seems to make input work \o/
<jcristau> hal not started, then?
<Ng> probably something like that, yeah ;)
<Ng> ok, next up, no Xv
<jcristau> X gets the list of input devices from hal, so if that's not running you lose
<jcristau> Ng: chipset is intel g4x?
<Ng> yep, brand new board, G45, so X4000HD
<jcristau> ok, so no xv is a bug in an ubuntu patch for xserver-xorg-video-intel
<Ng> I wasn't at all expecting this to be easy/smooth, and I'm very happy to work through these issues :)
<jcristau> it disables the textured video adapter by default
<Ng> aha
<jcristau> which is kind of a bad idea when there's no other adapter
<Ng> yes :)
<Ng> is that something I can re-enable by config, or do I need to wait for an updated package?
<jcristau> Option "TexturedVideo" iirc
<jcristau> in the device section
<Ng> hmm, that means I have to make an xorg.conf! ;)
<jcristau> printf 'Section "Device"\n\tOption "TexturedVideo"\nEndSection\n' > /etc/X11/xorg.conf should be all you need
<Ng> ok
<Ng> also, for some reason the display is dropping out every 30s or so
<Ng> I'll check the DVI connection and stuff, probably need to duck out for a few hours, but then I'll be back on this :)
<Ng> jcristau: thanks, btw :)
<jcristau> np
 * Ng boggles, something isn't working now, X isn't coming up at all
<Ng> jcristau: is there some way I can dial up the debugging on what the driver is doing?
<Ng> the Xorg.0.log looks fine, but my TV is showing nothing :/
<Ng> I did poke the bios settings to give it 128MB of shared RAM, maybe that was a mistake
<pwnguin> anyone feel like helping dig out a stupid xorg crasher?
<pwnguin> https://bugs.edge.launchpad.net/ubuntu/+source/wacom-tools/+bug/259035
<ubottu> Launchpad bug 259035 in wacom-tools "Xorg crashed with SIGSEGV in DeleteInputDeviceRequest() (wacom)" [Undecided,Incomplete] 
 * Ng tries git drm and intel
<Ng> hmm, that's not working particularly well, but I don't know much about how this works without gem (which I assume isn't available in intrepid)
#ubuntu-x 2008-08-24
<Ng> is -intel 2.4.1 going to be able to sneak into intrepid?
<Ng> it seems to work with vt switching on G45 better
<Ng> which is weird since it looks like our 2.4.0 has at least some of the 2.4.1 fixes as patches
<Ng> jcristau: debian 
<Ng> err
<Ng> jcristau: debua bug #494441 - I got that when I was messing around with having an xorg.conf. not having it works fine
<ubottu> Error: Launchpad bug 494441 could not be found
<jcristau> Ng: so 2.4.0 is broken, and 2.4.1 works?
<Ng> jcristau: ish, yeah. in intrepid's 2.4.0 changing vt seems to pretty much break everything, and also if usplash is enabled then X doesn't start properly
<Ng> jcristau: but 2.4.1 seems a lot happier
<Ng> having textured video is nice too, although it seems like it's not syncing properly, I'm getting.... well I'm not sure how to describe it correctly, but I can see a break move down the video sometimes where it's like above the break and below it aren't quite rendering in sync
<Ng> I think this is the vblank sync thing? (although this is HDMI output to a TV, so I'm not sure that there is a vblank ;)
<Ng> I switched from DVI to HDMI this morning and I don't seem to be having the display blank out every minute or so, so maybe there is something wrong with the DVI connector, or my cable
<Ng> but switching to HDMI is fine by me ;)
<Ng> I'll play with XvMC later, but aiui that only helps with mpeg2?
<jcristau> i don't think xvmc is supported on your chipset
<Ng> ah
<jcristau> only 915/945 and g33, according to the manpage
<Ng> it seems like the hardware has video acceleration stuff, but maybe that's just not supported via current X stuff?
<jcristau> yeah it's just missing from the driver
<Ng> ok :)
<jcristau> there's also a branch for xvmc on 965 but it's not quite done afaik
<Ng> from what I can find on blog postings, it seems like the drm/gem stuff is nearing done, but won't be in the kernel until 2.6.28
#ubuntu-x 2009-08-17
<rek> hi
<rek> hi all
<rek> hi, i need proprietary drivers i used with hardy heron now i'm running 9.10 i tried to install some glx packages but in system administration hardware drivers i don't see anything....and my pc after a few minutes stops working and i need to reset help...... 
<ScislaC> bryce: you guys love to torture me by continually breaking my tablet's usability during the dev cycles ;)
<bryce> :-/
<ScislaC> Alexia_Death: your brush dynamics enhancements in gimp rock for the record :D
<bryce> ScislaC, everyone always blames Ubuntu for when stuff breaks, and gives credit to upstreams when stuff works ;-)
<ScislaC> bryce: I don't blame Ubuntu... I blame myself for never keeping a stable OS for longer than a month ;)
<bryce> ScislaC, I suppose since upstreams are always perfect, any error must be the result of an imperfection introduced during integration into the distro ;-)
<ScislaC> bryce: AHA! Finally found a bug report on the issue...
<bryce> #?
<ScislaC> bryce: now that I'm done posting too many times to the report... ;)  it's #410267
<ScislaC> I'm pretty sure the wacom-tools assumption is incorrect
<ScislaC> bryce: anything in particular you think I can add to that report that it's lacking?
<bryce> reading
<bryce> well, it's likely not a -vesa bug.  I don't think that'd interact much with input devices, plus it really hasn't changed since jaunty
<bryce> ScislaC, are you able to reproduce it with !-vesa?
<ScislaC> uhm, I use -ati? (I'm assuming that -vesa is a more generic driver)
<ScislaC> bryce: that was at you... in case you don't peek back here soon ;)
<bryce> ok
<ScislaC> bryce: thank you for helping with that bug :)
#ubuntu-x 2009-08-18
<bryce> morning
<jbarnes> bryce: hi
<jg> hi bryce
<Q-FUNK> I'm wondering whether backporting or SRU would be most appropriate to push a more recent -geode into Hardy?
<hyperair> backport
<hyperair> it isn't in karmic, is it?
<jg> bryce: you recommend I try the stable updates for this ATI box I have, and the bleeding edge on Koala to for the Intel?
<bryce> jg, yep, how's that worked out?
<Q-FUNK> hyperair: it's already in karmic.  
<bryce> Q-FUNK, we have an x-updates PPA that is appropriate for such backports
<jg> bryce: just starting now; it took a while to convert all those flac's to mp3's yesterday.  I'll try the ati first (not on my main laptop, strangely...).
<bryce> Q-FUNK, https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/
<hyperair> Q-FUNK: what's the package name?
<bryce> hyperair, xserver-xorg-video-geode
<hyperair> $ apt-cache policy xserver-xorg-video-geode
<hyperair> W: Unable to locate package xserver-xorg-video-geode
<Q-FUNK> bryce: GX2 support is just so hopelessly broken in Hardy that we'd pretty much need to push something 2.11.* to Hardy to make -geode usable on LTSP.
<bryce> $ apt-cache madison xserver-xorg-video-geode
<bryce> xserver-xorg-video-geode |   2.11.3-1 | http://archive.ubuntu.com karmic/main Sources
<bryce> Q-FUNK, well good luck with that ;-)
<Q-FUNK> I'd rather wait until we have 2.11.4 out, since it changes the acceleration default to XAA for GX, which has been long requested.  
<Q-FUNK> we should have 2.11.4 out later this week, at which point I'd push it into Karmic, followed by either SRU or backport into jaunty, intrepid and hardy.
<Q-FUNK> bryce: yeah, I remember the last SRU for -geode.  the horror, the horror.
 * bryce nods
<bryce> one of the many reasons that motivated me to set up x-updates, so we have a place *we* control for such things
<Q-FUNK> required too much cherry-picking of individual git commits.  that's why I'm pondering whether backport might be a beter route.
<bryce> Q-FUNK, btw you're welcome to join ubuntu-x so you can put updates of -geode into x-updates directly
<Q-FUNK> bryce: oh, that sounds good
<bryce> I've also reconfigured ubuntu-x to not innundate you with bug mail if you don't want (it's now sent to a mailing list you can opt in/out of)
<Q-FUNK> oops! i think I just added myself to the list too.
<Q-FUNK> how do I backtrack that ?
<Q-FUNK> nice collection of PPA
<bryce> there's a check box near your team subscription info
<Q-FUNK> ok
<Q-FUNK> well, let's see what the moderator says about our application :)
<jg> bryce: seems to work ok on the laptop panel.  I've got this external CMO 1680x1200 panel, though.  What do I do to get it to run at that resolution? The usual virtual display subsection added to the screen section?
<bryce> jg, yes; the Display configuration applet in System should take care of setting that up for you (YMMV tho)
<jg> bryce: didn't seem to detect the higher resolution....
<jg> So it didn't configure a wide enough size...
<bryce> jg, if you reboot with the monitor attached, it'll detect it properly.  Then use the Display tool to set the Virtual res and you should be good.
<bryce> jg, or just shortcut it by writing the xorg.conf yourself if that's more comfortable
<jg> bryce: I'm anal: I'll try the reboot, just to see if it works right....
<bryce> jg, X for some reason sets things up based on the largest resolution it sees at time of boot, and doesn't resize on the fly.  This is better with KMS, but even in Karmic we don't have KMS for -ati in place yet (proving a bit buggy still).
<jg> bryce: even at boot, it doesn't detect the full resolution of the CMO display; the biggest it sees is 1440x900...
<Q-FUNK> incoming = ~ubuntu-x-swat/x-updates/ubuntu/
<Q-FUNK> correct?
<bryce> Q-FUNK, correct
<bryce> jg, odd, now that is sounding buggy.
<jg> bryce: yup....
<bryce> jg, pastebin your Xorg.0.log someplace?
<jg> bryce: http://pastebin.com/d25c5dd9b
<bryce> ok it's definitely seeing 1680x1050
<bryce> oh you need 1680x1200
<jg> that's the 
<jg> IIRC, the CMO may be x1050...
<jg> Let me check the model number
<bryce> EDID vendor "AUO", prod id 33044
<bryce> AUO has been infamous for putting in invalid EDID into their monitors; we've got a bunch of quirks against it
<bryce> but that may not be the issue here
<bryce> it looks like it's picking 1280x800 as the highest common resolution between the two monitors
<jg> its a A220Z1-G/1
<jg> excuse me, a A220Z1-G01
<jg> that's 1680x1050
<bryce> jg, what's your 'xrandr' output show?  Does it list the 1680x1050 resolution as available on the CMO?
<jg> now that I've adjusted the virtual, yes.... and on the gnome applet.  Only at 60hz though.
<jg> bryce: which is probably bandwidth topping out...
<bryce> #
<bryce> (II) RADEON(0): #5: hsize: 1680  vsize 1050  refresh: 60  vid: 179
<bryce> 60 may be the best it can do
<bryce> does the hardware docs suggest otherwise?
<jg> yup.
<jg> no.
<bryce> ok
<jg> the Intel driver seems to deal with it (slightly better, anyway), in terms of id'ing the mode properly.
<bryce> so you should be able to force it to what you want via 'xrandr --output VGA-0 --mode 1680x1050 --left-of --output DVI-0 --mode 1280x800'
<bryce> or tweak as suits your exact circumstances
<bryce> it's possible to hardcode that in your xorg.conf (see https://wiki.ubuntu.com/X/Config) or just put the correct xrandr line in your ~/.xstartup
<jg> bryce: it may be the driver is doing "the right thing" as I'm seeing some video artifacts when it is driving at that resolution.  There may not be enough bandwidth in the laptop's driver...
<bryce> ah
<jg> bryce: the cursor has some funny artifacts.
<jg> I betcha it's just barely out of bandwidth....
<bryce> jg, hmm, at this point agd5f would be the guy to talk to
<bryce> oh wait
<bryce> yeah that's an issue others have reported
<bryce> I think it's a general bug.  I had it too in jaunty, but it seems to be gone in Karmic fwiw
<bryce> we've a newer -ati backport for jaunty available at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<bryce> I don't know if that version has the fix or not, but should be quite safe to try
<jg> bryce: ah, fresh crack....
<jg> bryce: should I just try the driver, or go for bleeding edge 7.5 builds?
<bryce> I'd try the driver first
<bryce> if you want to go more bleeding edge, we've got a git snapshot package at https://edge.launchpad.net/~xorg-edgers/+archive/ppa
<jg> bryce: the ati driver?
<bryce> yeah
<bryce> the 6.12.2 driver has been amply tested and should be reasonably safe
<jg> bryce: the cursor still has the funny artifacts.
#ubuntu-x 2009-08-19
<MsMaco> hello folks. ive been trying to help this tommy_ fellow get his screen to do its native 1024x768. we went through xrandr --newmode and --addmode and now it shows in his screen config gui (yay) but it fails when he tries to do xrandr --output default --mode 1024x768_60
<MsMaco> ive hit the limits of my xrandr knowledge, so...can anyone help?
<tommy_> please :-)
<MsMaco> i *thought* those were all the necessary steps...but maybe not... and if so, i suppose the answer is just "file a bug"
<tommy_> everybody's sleeping it appears
<MsMaco> its not an ordinarily busy channel... but i dont *think* everyone here's british
<tommy_> neither am I lol
<MsMaco> many ubuntu devs are british or otherwise european so finding them at this time of night can be hard
<tommy_> ah gotcha
<MsMaco> if youre in the US, there tend to be more people around noon-ish or late morning
<tommy_> I mean using it now I'm almost somewhat not even noticing the frames
<tommy_> but it's still annoying
<tommy_> well I just rand xrandr by itself again
<tommy_> and even though I told it to run at 1024x768 in the gui, it still says 800x600 in xrandr
<tommy_> Screen 0: minimum 640 x 480, current 800 x 600, maximum 1024 x 768
<tommy_> so it's an option now atleast, I just can't get it to set to the max
<MsMaco> right it still says that cuz switching to 1024x768 failed
<MsMaco> xrandr -s 1024x768
<MsMaco> maybe?
<MsMaco> thats an old way to do it, but worth a shot
<tommy_> failed
<tommy_> see if I can get any luck out of the other channel
<tommy_> hello anyone around?
<tommy_> hello anyone here?
<MsMaco> tommy_: i asked a friend that does some X stuff and he said that error sounds like the driver's refusing to accept the mode
<MsMaco> i still dont know why he doesnt join this channel
<tommy_> well upon restart
<tommy_> the 1024x768 option dissapeared from the gui
<tommy_> and xrandr
<tommy_> windows has no problem doing it
<tommy_> so I know its possible
<MsMaco> its not the hardware. its likely the driver being stupid
<MsMaco> which graphics chip do you have anyway?
<tommy_> I don't think it knows what kind of display it is so it's just using generic settings
<tommy_> not too sure to be honest
<MsMaco> lspci
<MsMaco> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. Ubuntu pastebin is at  http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<tommy_> hm?
<MsMaco> pastebin the output of "lspci"
<tommy_> !pastebin 00:00.0 Host bridge: Intel Corporation 82440MX Host Bridge (rev 01)
<tommy_> 00:00.1 Multimedia audio controller: Intel Corporation 82440MX AC'97 Audio Controller
<tommy_> 00:00.2 Modem: Intel Corporation 82440MX AC'97 Modem Controller
<tommy_> 00:02.0 VGA compatible controller: Silicon Motion, Inc. SM712 LynxEM+ (rev a0)
<tommy_> 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 CardBus Controller (rev 05)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<tommy_> 00:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
<tommy_> 00:07.0 ISA bridge: Intel Corporation 82440MX ISA Bridge (rev 01)
<tommy_> 00:07.1 IDE interface: Intel Corporation 82440MX EIDE Controller
<tommy_> 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller
<tommy_> 00:07.3 Bridge: Intel Corporation 82440MX Power Management Controller
<tommy_> did that work?
<MsMaco> you didnt actually read the output of the pastebin factoid, huh?
<MsMaco> anyway....
<tommy_> lol
<MsMaco> silicon motion
<tommy_> hows pastebin work 
<MsMaco> Ubuntu pastebin is at  http://paste.ubuntu.com
<MsMaco> you paste stuff in the text box and hit submit. it gives you a link
<MsMaco> you give us the link, and then we dont get 15 lines of stuff in the channel
<tommy_> got it
<tommy_> does that help any?
<MsMaco> im asking a friend
<bgamari> Honestly, I doubt I'll be very much
<bgamari> help
<MsMaco> you've a better chance of figuring out if the modeline's slightly wrong than i do
<bgamari> it sounds as if you just need to throw a debugger on the xserver and figure out why the driver is failing
<bgamari> You've checked the Xorg log, right?
<MsMaco> no
<MsMaco> didnt think about that
<MsMaco> tommy_: this is ben.
<tommy_> be prepared to walk me through this lol
<MsMaco> he works on intel graphics, but i figured he might have some idea how X works in general...or at least a better idea than i do
<tommy_> yeah I'm at a complete loss
<bgamari> first look in /var/log/Xorg.log
<MsMaco> bgamari: would a tail -f while doing the xrandr stuff we did before make sense?
<bgamari> sure
<MsMaco> tommy_: two terminals. in one "tail -f /var/log/Xorg.log"
<MsMaco> in the other...do you still have the xrandr commands we did before?
<tommy_> unfortunately not
<MsMaco> ok
<tommy_> xrandr doesn't even have 1024x768 as an option anymore
<tommy_> after a restart it reset to default
<MsMaco> xrandr --addmode "1024x768" "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync" 
<MsMaco> that was the mode we used
<MsMaco> doh
<MsMaco> that's newmode
<MsMaco> then after that it was: xrandr --addmode default 1024x768
<tommy_> that tail comand did nothing
<MsMaco> itll show the end and follow it as the file changes
<tommy_> just gave me a > prompt
<MsMaco> so if theres a new error added to it, itll show it
<MsMaco> hrm
<MsMaco> and then "xrandr --mode default 1024x768" was the last part...where the error happened...
<MsMaco> wiat.
<MsMaco> it should be Xorg.0.log
<MsMaco> not Xorg.log
<tommy_> I've got xorg.r.log
<tommy_> yeah
<bgamari> Unfortunately I've got to run in 5 or so
<MsMaco> bgamari: bedtime?
<bgamari> Naw, need to go meet my girlfriend
<tommy_> cannot find output 1024x768
<MsMaco> output was default
<MsMaco> bgamari: ah ok
<tommy_> ok what did we do to get it to work before
<tommy_> I got the tail working
<MsMaco> did the name change from default to something else?
<MsMaco> pastebin plain old "xrandr"'s output
<tommy_> it's still called default
<MsMaco> maybe if you put "" around the 1024x768?
<tommy_> it was
<tommy_> ok...
<tommy_>  xrandr --addmode "1024x768" "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync"
<tommy_> ?
<tommy_> cannot find output
<tommy_> what did we do last time
<MsMaco> oh no no i said above "oops that shouldve been newmode"
<tommy_> oooh gotcha
<tommy_> hold o
<tommy_> nothin
<tommy_> it gave me the the whole xrandr command menu
<tommy_> hold on less quotes
<MsMaco> hola andresmujica
<andresmujica> hola msmaco
<andresmujica> maco as in mackenzie?
<MsMaco> aye
<tommy_> this isn't working
<andresmujica> oui. hi, what's up?
<tommy_> it just keeps giving me the proper syntax formatting thing for xrandr
<MsMaco> trying to make his screen to 1024x768
<tommy_> it's not recognizing how it's formatted
<MsMaco> *do
<MsMaco> are you copying and pasting my quotes?
<tommy_> yes only I changed it to newmode
<MsMaco> i think i have stupid curly quotes in my irc client...that could break things
<MsMaco> or do they show as normal straight quotes when you look in your terminal?
<tommy_> they're normal
<tommy_> type it one more time :-)
<tommy_> cause whatever you told me to do last time worked
<MsMaco> well last time we named it 1024x768_60
<MsMaco> i dont think the name should make a difference but *shrug*
<tommy_> I'm lost
<MsMaco> maybe xrandr --newmode "1024x768_60" "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync"
<MsMaco> since thats what we did before the reboot
<tommy_> it's not accepting your formatting
<tommy_> for one reason or another
<tommy_> should there be two spaces in those two spots?
<MsMaco> its a copy and paste from my terminal...same as i pasted to you before
<tommy_> well what the shit
<tommy_> I don't get it
<MsMaco> _xrandr --newmode "1024x768_60.00" 
<MsMaco> er without the _
<MsMaco> and then "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync" the same
<MsMaco> if the formatting of the name matters, i will be peeved
<MsMaco> andresmujica: do you know how to work this xrandr thing?
<andresmujica> tommy_ you can try http://xtiming.sourceforge.net/cgi-bin/xtiming.pl  and this http://www.arachnoid.com/modelines/   those can help you generate a working modeline.  However, i would try renaming the xorg.conf file so it gets autogenerated by the system itself.    i don't really use xrandr... the applet works good enough for me.. :)
<MsMaco> andresmujica: its a new install and it only detected 640x480 and 800x600 by default
<andresmujica> ohh.. 
<andresmujica> sis video card.
<MsMaco> so we're trying to add 1024x768 so the applet can do it
<MsMaco> yes, sis
<tommy_> it's not accepting it still
<MsMaco> from what i recall *shudder*
<tommy_> here I'm sending this entire thing to pastebin
<tommy_> did you see it
<MsMaco> you have to give me the link
<tommy_> o
<tommy_> http://paste.ubuntu.com/255515/
<MsMaco> ok try without quotse then
<tommy_> around anything?
<MsMaco> yeah
<andresmujica> yeap without the quotes
<tommy_> bash: syntax error near unexpected token `;'
<MsMaco> whys there a ; in it?
<MsMaco> oh because you bumped it
<andresmujica> xrandr --newmode 1024x768_60.0 63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync
<MsMaco> i can see it in the pastebin
<tommy_> http://paste.ubuntu.com/255520/
<MsMaco> oh it has got it in there
<MsMaco> ok
<MsMaco> xrandr --addmode default 1024x768_60.0
<tommy_> http://paste.ubuntu.com/255521/
<MsMaco> yay its associated with the output device now
<MsMaco> so were at the point before where itd show in the applet
<MsMaco> now lets see if Xorg.0.log says anything when you do this:
<MsMaco> xrandr --output default --mode 1024x768_60.0
<tommy_> I tried switching it through the gui
<tommy_> screen blinked
<tommy_> xrandr: Configure crtc 0 failed
<tommy_> nothing changed in the log
<MsMaco> :(
<tommy_> I'm so confused
<tommy_> it's like it tried and then said "F*CK YOU"
<MsMaco> mmm yeah
<MsMaco> by the way.... even without the "u" not really supposed to say that
<tommy_> ok sorry
<tommy_> just getting frustrated
<MsMaco> well... getting around it with fsck is not too uncommon since thats an actual command...
<MsMaco> anyway
<tommy_> lol
<MsMaco> ben's hypothesis was that the driver is screwing up
<andresmujica> try generating the correct modeline with http://xtiming.sourceforge.net/cgi-bin/xtiming.pl  you'll need your monitor specs thou.  probably a freq thingie
<MsMaco> yeah the modeline we tried was a generic 1024x768 one
<MsMaco> maybe your screen is not-so-generic
<tommy_> thats what xp says it is
<MsMaco> no i mean in terms of those other numbers
<MsMaco> 1024 1072 1176 1328  768 771 775 798 <- these ones
<tommy_> oooh
<MsMaco> and that 63.50 number
<tommy_> so now how would I figure this out?
<MsMaco> do what andres said
<tommy_> k
<andresmujica> behind you monitor you'll find a plate with some specs on it, or at least the monitor model, so you can check in google about the right specs for your monitor so it can be used by the xtiming.pl 
<MsMaco> laptop
<MsMaco> lshw?
<andresmujica> holly gosh.. i thought it was a CRT model... 
<MsMaco> *grumble* screws should be far more difficult to lose. then i wouldnt have half-put-together furniture
<tommy_> Modeline "1024x768@0" 0.00 1024 1056 1056 1088 768 787 787 807
<tommy_> thats what it spit out at me
<andresmujica> hmm 0.00 ?
<MsMaco> yeah thats what i was staring at
<tommy_> yeah found that odd too
<tommy_> should I try it on my other comp with xp?
<tommy_> they're identical machines
<MsMaco> well we're obviously on the same page
<tommy_> but that ones actually running at 1024
<tommy_> maybe that'll give me the right hrz
<tommy_> khz*
<andresmujica> take into account that the modeline potentially can cause DAMAGE to your computer.
<MsMaco> if its wrong
<tommy_> well we got it wrong once and it didn't blow up
<tommy_> lol
<tommy_> I've got like 8 of these anyway
<andresmujica> so i'll recommend you to find the right specs for your laptop, so you can test with confidence..
<tommy_> it I fry one it won't be that big of a deal
<andresmujica> hehehe
<tommy_> would it be documented anywhere?
<andresmujica> i don't know if you can find that info in windows.  
<andresmujica> Yeap if it' s a laptop it should be available at the specs from the vendor
<tommy_> lemme see if I can find it
<tommy_> or see if you can find it before me
<tommy_> lol
<tommy_> 13.3 XGA(1024x768) TFT LCD
<tommy_> is all I'm able to find
<MsMaco> lshw maybe tell you the exact lcd model?
<tommy_> whats that
<tommy_> a command?
<tommy_> http://paste.ubuntu.com/255531/
<andresmujica> which one is the laptop?  
<tommy_> hm?
<andresmujica> model/vendor 
<tommy_> IBM ThinkPad iSeries 1300 7WU
<tommy_> 1300 1171-7WU
<tommy_> found it
<andresmujica> oh well.. time to go.  didn't find anything valuable in google.. :(  i'll keep trying different modelines (anyway it should be autodetected, so it must be a bug somewhere around..)
<andresmujica> what did u found?
<tommy_> http://www.broadbandreports.com/forum/remark,14829837
<andresmujica> yeap, but it's with a trident card..
<andresmujica> but its worth a try.
<andresmujica> good luck!!
<tommy_> oh
<tommy_> hm
<tommy_> well I'll poke around
<tommy_> so I'd just do those commands again
<tommy_> only with new values?
<andresmujica> why don't you try with some livecd's, maybe one of them gives the right config... (jaunty, hardy, karmic4) 
<andresmujica> so we can chase down the bug.
<tommy_> actually
<tommy_> I had DSL loaded on here
<tommy_> and it worked fine
<tommy_> say I stuck in the liveCD for that, how would I find the value, just do xrandr ?
<andresmujica> g'night.. see ya msmaco.. ahh Damn Small, try using that xorg.conf  get it from there!!! you've got the solution! 
<tommy_> just view the file?
<MsMaco> save it to a flash drive
<MsMaco> and copy it over
<MsMaco>  /etc/X11/xorg.conf
<tommy_> ok great
<tommy_> lemme go find the cd and boot it in a twin machine
<tommy_> I"ll be back in 2
<tommy_> ok dsl is booting from cd
<tommy_> ok now I'm lost
<tommy_> still here ms?
<tommy_> anyone here?
<tommy_> hellllo?
<tommy_> andreas
<tommy_> or duke
<tommy_> or anyone
<Duke`> ?
<tommy_> I need help
<tommy_> I've got a laptop, and can't get the resolution high enough to fill the entire viewing area
<tommy_> I've got 1" frames on all sides
<Duke`> which resolution?
<tommy_> the highest I'm able to go is 800x600
<tommy_> I need it at 1024x768
<tommy_> I was able to get this far with it ... http://paste.ubuntu.com/255557/
<Duke`> what is screen size?
<tommy_> 13.3 
<tommy_> check out that paste bin and see if you can help me at all
<tommy_> I'm very new to linux I dunno much
<Duke`> I'm not good at modelines, so I can't tell you if it's correct
<Duke`> are you sure your laptop can to 1024?
<Duke`> *can do
<tommy_> I loaded a live CD of DamnSmallLinux and it loaded fine at 1024x768 full screened, but I dunno where I can find the settings at
<tommy_> yes positive
<MsMaco> he used a script to get a modeline, but it gave 0.00 clock rate...which...er...
<tommy_> I've got an identicle machine next to me
<tommy_> it's running at 1024 
<MsMaco> DSL shouldve had the xorg.conf in /etc/X11/xorg.conf
<MsMaco> if you copy it from DSL to Ubuntu it should work
<tommy_> that file doesn't exist
<Duke`> you can write at xorg@lists.freedesktop.org describing your problem
<MsMaco> DSL uses XFree86, doesnt it?
<MsMaco> instead of X11?
<tommy_> I dunno it's got an X11 dir
<Duke`> MsMaco: maybe an older driver
<tommy_> just no xorg.conf
<Duke`> so not so old...
<tommy_> someone told me to create one with some code
<tommy_> but being a live cd there's no file writing capability
<tommy_> theres no way to get the values from it without that file?
<Duke`> try looking in /var/log/Xorg.0.log
<tommy_> I may have just found something
<tommy_> http://www.perimeterless.org/?p=106
<tjaalton> eww, siliconmotion
<MsMaco> haha
<MsMaco> that looks kinda like andres's reaction too
<tjaalton> logfile would still be helpful
<tommy_> hahaha
<tommy_> it doesn't kick anything to the log
<tjaalton> Xorg.0.log?
<tommy_> never changed
<tjaalton> sorry, don't believe you ;)
<tommy_> lol
<MsMaco> tjaalton: had him tail -f it while he set it up with xrandr
<MsMaco> on ubuntu, i mean
<tjaalton> xrandr doesn't matter
<tjaalton> the driver doesn't support randr-1.2 anyway
<MsMaco> well we were doing --addmode and --newmode stuff
<tjaalton> I'm interested in why it fails to set the native mode, and that's in the logfile
<tommy_> I'll paste bin it hold on
<MsMaco> tjaalton: fails to set? it doesnt offer the native mode at all....
<MsMaco> or do you mean after we added the mode?
<tommy_> hsync out of range
<tommy_> for 1024x768
<tjaalton> MsMaco: it should start with that mode, no?
<tjaalton> tommy_: right, full log please
<tommy_> http://paste.ubuntu.com/255560/
<MsMaco> tjaalton: im not sure what order X tries to do things, i just know its not detecting the native range as even being something the screen can do
<tommy_> thats not the full log
<tommy_> everything silicone motion related tho
<MsMaco> tjaalton: so we were playing with xrandr trying to convince X that yes, the screen really can do that
<tommy_> and then some
<tjaalton> MsMaco: but you can't tell the server what the monitor can do, other than via xorg.conf
<tjaalton> just force the monitor values to xorg.conf and it should be fine
<tjaalton> it's still a bug though
<tjaalton> DSL probably forced the range
<tommy_> like it said to do in that link I sent?
<tjaalton> would be nice to know though
<tjaalton> tommy_: yes
<tommy_> ok I'm gonna give it a shot
<tommy_> I'll be back 
<tommy_> hm
<tommy_> there's absolutely nothing in my monitor section
<tjaalton> so create one
<tommy_> should i just add the parts in bold like it said to or add all those values
<tommy_> stupid question
<tommy_> don't answer that
<tommy_> lol
<tjaalton> put everything from that blog to an empty file, and replace your current conffile with it
<tjaalton> well, not everything..
<tommy_> it won't let me save
<tjaalton> surely you must be root
<tjaalton> sudo -i/-s
<tommy_> how do I save in nano
<tjaalton> ctrl-x
<tjaalton> to exit
<tommy_> saves on exit?
<tjaalton> it'll ask..
<tommy_> heard 
<tommy_> thanks
<tommy_> ok restart
<tommy_> wish me luck
<tommy> PERFECT
<Guest35750> thanks everyone
<tjaalton> good
<Guest35750> why am I guest now?
<Guest35750> lol
<tommy_> there
<tommy_> but yes thank you very very very much
<MsMaco> yay!
<tommy_> god that was a headache lol
<MsMaco> tjaalton: thank you for making up for my failure
<tommy_> mainly from staring at such a tiny screen trying to read
<tjaalton> MsMaco: np
<tommy_> thanks both of you
<tommy_> life savers!
<tommy_> I can finally goto bed now
<tommy_> lol
<bryce> heya tjaalton
<tjaalton> hey bryce
<bryce> tjaalton, have you gotten any info on when mesa 7.6 is likely to come?  or any rc's?
<bryce> tjaalton, I'm wondering pretty strongly if it'd make sense to pull in a git snapshot for now maybe
<tjaalton> bryce: no idea, haven't seen any talk about that
<tjaalton> I think there's going to be 7.5.1 before any 7.6rc
<bryce> I heard a rumor it might not be until mid/late september for 7.6 at the earliest
<bryce> so maybe getting too late for karmic
<tjaalton> might be
<Ng> http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/
<Ng> I can't remember if I pasted that yet or not. it's been on my todo list to do so and wasn't removed ;)
<bryce> Ng, christ that sounds complicated
<Ng> bryce: I came away with a headache, and the nugget of fact that there are patches that make it all play nicely ;)
<bryce> well, in theory ;-)
<bryce> urf reading the comments again the old saw comes up that "xorg needs more developers"
<bryce> xorg has plenty of developers, it's just that they're implementing features instead of attending to their bug reports
<bryce> (well, in general; -intel often does good, as do other pockets here and there)
<jcristau> plenty of developers, really?
<bryce> jcristau, yeah, most of the bugs/bugfixes we see are outcomes of regressions caused by feature development, moreso than say just new hardware or longstanding regressions
<bryce> jcristau, it's the same situation I see in inkscape
<bryce> just piling on more developers doesn't make bugs go away, rather it means you get a higher rate of feature work, which means you get *more* bugs
<bryce> of course, if the new features actually work, that's nice, once the bugs get worked out ;-)
<bryce> anyway, it irritates me when I see "distros need to be providing more developers to help xorg".  It's more QA that's needed.
<jcristau> yes.  qa isn't just done by machines though ;)
<bryce> that's not entirely always true.  ;-)
<bryce> anyway, it's well past time for bed.  nite.
<jcristau> bye
<diverse_izzue> i have a problem with dual screen on karmic. if use use two screens such that the primary screen doesn't change (that is external screen right of internal), everything works fine. If i place the external screen left of the internal one so that it becomes the primary screen, i have some trouble.
<diverse_izzue> a) i cannot place the gnome panel on the other screen
<diverse_izzue> b) the primary screen doesn't adjust its size to the dimension of the external monitor, so if i maximize windows they become too large.
<bryce> Ng, stuck that second patch into xserver, thanks for mentioning it to me
<Ng> win
<Ng> I will now claim full credit for karmic being awesome ;)
<Ng> I mean, thanks!
<tjaalton> I'd be happy if the screensaver worked
<tjaalton> maybe this will help
<bryce> tjaalton, how's it not working?
<tjaalton> bryce: it doesn't kick in
<tjaalton> the screen just stays on forever
<bryce> I've seen that on my laptop, but it's very intermittent
<bryce> sometimes it works, sometimes not
<tjaalton> maybe it works until I suspend the first time
<tjaalton> happens both on my laptop and desktop
<bryce> I get the same on my desktop come to think of it... sometimes the screen blanks on its own, sometimes it stays on forever
<bryce> heisensaver
<tjaalton> yeah
<Q-FUNK> howdy!
<Q-FUNK> can anybody sync -geode from debian?
<Q-FUNK> minor fix cherry-picked from git
<Q-FUNK> or well, the patch is small but the benefit significant:  restores usability on GX2 hardware
<Q-FUNK> it simply disables the buggy EXA support in the GX driver, which makes it fall back on XAA.
<tjaalton> use requestsync
<Q-FUNK> doesn't work
<Q-FUNK> change logs appear to be out of sync on the server
<tjaalton> well, no-one here can sync it
<Q-FUNK> ok
#ubuntu-x 2009-08-20
<jms> why would the display config screen in jaunty not offer resolutions over 1600x1200 on my external (vga) monitor?
<RAOF> Could you pastebin the output of "xrandr -q"?
<jms> http://paste.debian.net/44661/
<RAOF> Ok, so that's why the display config screen won't offer higher resolutions :).
<RAOF> It looks like it should only be offering up to 1024x768; is that what it's offering?
<jms> it's offering 1024x768
<jms> i think it's misinformed
<RAOF> Probably.  I'd guess that your monitor doesn't provide correct DDC information.
<jms> RAOF: well, yeah, except hwinfo is rather better informed
<jms> and so is ddcprobe for that matter
<jms> although... hm, interesting
<RAOF> Hm?
<jms> what's the difference between "timing", "ctiming" and "dtiming"?
<RAOF> Do idea.
<RAOF> No idea :)
<jms> ddcprobe shows a max timing of:
<jms> timing: 1024x768@75 Hz (VESA)
<jms> but it also shows the correct maximum of:
<jms> ctiming: 1600x1200@60
<jms> so whatever voodoo nonsense xrandr uses to determine available modes, it ought to be offering the ctiming ones but isn't
<RAOF> That'd be a driver issue.
<RAOF> You should probably file a bug against the driver.
<jms> (II) intel(0): Printing DDC gathered Modelines:
<jms> (II) intel(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
<jms> pretty sure the driver knows about the mode too
<jms> hm, Bug #395140
<ubottu> Launchpad bug 395140 in xserver-xorg-video-intel "[karmic] external monitor not recognized correctly" [Undecided,Fix released] https://launchpad.net/bugs/395140
<jms> nope, similar but unrelated i think
<RAOF> jms: I'd guess that the intel driver is filtering that out; it seems to suggest a refresh rate of 0.0Hz, which I wouldn't be surprised if the driver filtered out as obviously wrong.
<hyperair> hmm? external monitor? it usually works for me, very well
<tjaalton> what card is it?
<tjaalton> jms: ^^
<jms> tjaalton: intel
<tjaalton> model?
<hyperair> intel produces many cards.
<jms> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
<jms> (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile IntelÂ® GM45 Express Chipset
<tjaalton> are you using clone mode?
<jms> no
<jms> the two displays don't have the same mode. and i'd be happy if vga-only worked as expected really
<tjaalton> ok
<jms> brb, rebooting
<directhex> simultaneously fighting getting a TPM chip working with the 1600x1200 problem
<directhex> hence reboots
<jg> bryce: ping
<AndyB> Hi, i am trying to install this https://edge.launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill package so i can use desktop effects with my ati card. I have added the software sources but it does not say what do to next. Any advice?
<mdz> bryce, I had a crash this morning which looked very much like bug 343528
<ubottu> Launchpad bug 343528 in xserver-xorg-input-evdev "Xorg crashed with SIGSEGV in EvdevMBEmuBlockHandler()" [Medium,Fix released] https://launchpad.net/bugs/343528
<mdz> bryce, but I'm quite certain I was running 1:2.2.2-1ubuntu2
<bryce> hmm
<bryce> mdz, and you see 	pEvdev = (EvdevPtr) 0x0  in the #0 call in your backtrace?
<jg> bryce: I "up"graded to koala on this intel laptop: but it is a bit exciting, from the display point of view.  If I try the gnome display preferences program and enable the cmo panel, my screen goes almost entirely black (a few lines at the top seem to survive).
<bryce> mdz, weird.  I rebuilt the package and verified the patch is getting applied properly and so on.  To my knowledge, it may still crash since we're papering over what is probably some deeper bug, however it should *not* produce the exact same backtrace.  i'd like to look at your trace if you still have it handy.
<jg> bryce: and the X server has crashed at least once while playing around....
<bryce> jg, bummer, does the same thing happen if you use only the xrandr tool?  (Gnome's implementation of the Xrandr stuff has proven to be incorrect in the past.)
<jg_> bryce: to answer your question, xrandr is just as exciting.  typing xrandr<cr> does the same thing.
<bryce> wow
<jg_> definitely dramatic.
<jg_> downright cool...
<bryce> indeed
<bryce> something is really bad on your system
<bryce> can you post your Xorg.0.log.old somewhere?  (Or file a bug via `ubuntu-bug xorg`)
<bryce> I have never yet seen a bug where running xrandr crashes the system.
<jg_> bryce: didn't crash the system.
<jg_> just screwed up the video on the panel entirely.
<bryce> ohhh
<jg_> (on the built in panel; all I did was type xrandr, no arguments.
<jg_> quite fun, acutally.
<jg_> bryce: exactly repeatable; plug the panel in, type xrandr, and the same thing happens again.
<mdz> bryce, I couldn't retrace it, because it didn't leave a crash report behind (it is actually the crash which inspired my mail to -devel about apport)
<mdz> bryce, the trace from the X server log is at http://pastebin.com/f1424d503
<bryce> mdz, ok my guess here is that maybe it's crashing now due to something other than a null pointer
<jg> bryce: anything you'd like me to try?
<bryce> jg, well if you're game, we do have some debugging tools to use for cases like this, let me grab a link
<bryce> jg, https://wiki.ubuntu.com/X/Troubleshooting/Freeze
<jg> I'm game....  
<bryce> jg, what anholt will want is that batchbuffer dump
<jg> bryce: the thing is, it isn't a freeze.
<jg> Cursor still responds, and changes....
<bryce> jg, changes?
<jg> shape changes as to underlying windows.
<bryce> hmm
<bryce> ok, then maybe it can be treated as a blank screen issue
<jg> so the server is still alive; the screen mostly dark, but a few lines on the top clearly come from someplace real (part of a panel).
<bryce> https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen - go to the section 'Register Dumps for -intel'
<superm1> bryce, regarding bug 341898, what's in 529d1d72 ? did upstream mesa finally acknowledge it's a mesa bug?
<ubottu> Launchpad bug 341898 in xorg-server "(Needs mesa 529d1d72) MythTV Frontend does not work with RADEON DRI" [Unknown,Fix released] https://launchpad.net/bugs/341898
<bryce> hmm, well what you describe doesn't fall neatly into one of the known failure cases.  But my guess is that upstream would like either the register dumps or the batchbuffer dump
<bryce> jg, maybe jbarnes can give some advice here?
<jg> yeah, I've not seen anything quite like this bug in > 25 years of messing with video cards....
<jg> bryce: I agree the register dumper is the place to start....
<bryce> superm1, your comment on the upstream bug indicated that patch fixed it - https://bugs.freedesktop.org/show_bug.cgi?id=20843#c4
<ubottu> Freedesktop bug 20843 in Server/general "Xorg server 1.6 causes mythtv to not show QT3 QWidgets properly" [Normal,Resolved: fixed]
<superm1> bryce, oh, that only fixed it for -vesa
<bryce> superm1, maybe that bug report has become an aggregation of various unrelated issues?
<superm1> yeah
<bryce> :-(
<superm1> well it's two issues that aggregated on there with similar symptoms
<superm1> one of them was on -vesa and the other on -ati
<jbarnes> jg, bryce: well the probe path is clearly doing *something* bad :)
<superm1> the remaining open item was on -ati
<jbarnes> jg: what chipset?
<jg> jbarnes: Intel 945, IIRC.
<bryce> superm1, it really makes it hard to determine the current status on a bug report, when it involves multiple unrelated issues on differing hardware. 
<superm1> as soon as we have new mythbuntu disks rolled for karmic (ttf-bitstream-vera is the end of me right now), we've got trunk builds of mythtv with QT4, which I heard don't exhibit these situations
<jbarnes> jg: any reg dump differences before & after?
<superm1> bryce, i agree.  i'll try to update the status of it and the description after I can have this data point with mythtv 0.22 / QT4
<jg> jbarnes: I'm collecting data now.
<bryce> superm1, because the bug is targeted to karmic, I'm getting management asking me for status on the bug
<bryce> superm1, ah, so it is a QT bug?
<superm1> bryce, well that depends on who you talk to :)
<superm1> the mesa folks say its a QT bug, the mythtv folks say it's a mesa bug, and QT3 isn't developed anymore
<jg> jbarnes: lots of differences...
<superm1> i'm really hoping it just goes away with QT4 like I have heard.  if not, then at least QT4 people can weigh in on it too
<jbarnes> jg: can you file a bug at fdo with the dumps attached?
<jg> bryce, jbarnes: looks like 11 registers differ
<jg> jbarnes: sure.
<jbarnes> thanks
<jbarnes> are they the mode timing regs by chance?
<jg> jbarnes: what all do you want exactly?
<jbarnes> (H_TOTAL etc)
<bryce> superm1, ok thanks
<jbarnes> jg: usual stuff, driver kernel x mesa versions
<jbarnes> dmesg & x log
<jbarnes> reg dumps from before & after
<bryce> superm1, it would be wonderful if we could split the bug up into its constituent bugs, but if you think you'll be able to get the bug closed soonish it may not matter
<superm1> bryce, yeah as soon as all of ttf-bitstream-vera's rdepends are cleaned up, I can verify it myself whether it's fixed
<bryce> superm1, great thanks
<jg> jbarnes: they are ADPA DSPACNTR DSPABASE PIPEACONF PIPEACONF PIPEASTAT DPLL_A DSPBSTRIDE DSPBBASE FENCE 3 FENCE 4 and FENCE 5
<superm1> if it's not, then splitting it up is probably the next step and getting more updated data etc
<bryce> superm1, we also have a newer mesa git build in xorg-edgers that could be tested
<jbarnes> jg: oh hm
<jg> lots of fun registers....
<bryce> jbarnes, pipea bug?
<superm1> bryce, okay good to know.  hopefully dont need to go down that route :)
<jbarnes> jg: unless the pipe config got messed up or we're pointing at a different base I don't see why those would mess up your panel
<jbarnes> bryce: that usually leads to hard hangs
<jg> jbarnes, bryce: bug 23429
<ubottu> Launchpad bug 23429 in console-tools "console-tools can't handle 12x22 fonts" [Medium,Won't fix] https://launchpad.net/bugs/23429
<jcristau> clearly ubottu needs some more brains. :)
<bryce> fdo #23429 ?
<bryce> freedesktop bug #23429 ?
<ubottu> Freedesktop bug 23429 in Driver/intel "Video gets screwed up on built in panel when external monitor plugged in and xrandr run." [Critical,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=23429
<Ng> bryce: hrm, not sure those anti-random-power-event patches helped any :/
<bryce> Ng, no?
<bryce> Ng, I'd assumed they were confirmed to fix it
<Ng> I updated this morning and got a new xserver core. set all my power management settings back from "never do anything" this afternoon and this evening I was just browsing the web and my laptop suspended
<Ng> I wonder if there were associated changes to g-p-m
<Ng> I also badly wish that syslog mentioned pm events and what triggered them
<bryce> yeah
<bryce> that's what I was just thinking myself...  if the fixes aren't fixing it, at least give us better debugging tools
<Ng> I've just stabbed g-p-m and will leave it running in a terminal with --verbose, but I'm going to be really really offline for most of the next week
<bryce> Ng, ironically my monitors just now blanked ;-)
<bryce> (however I've not yet rebooted this box into the "fixed" xserver
<bryce> +)
<Ng> heh
<bryce> Ng, maybe there are multiple bugs that result in the same symptom
<bryce> so maybe the patches have helped, but they're just not sufficient to eliminate it entirely
<Ng> yeah
<Ng> or my laptop just hates my freedom ;)
<bryce> Ng, is it screaming, "Put windoze on me pleeaaaseee..."?  :-)
<Ng> haha
<Ng> I ripped off its vista sticker, so it had better not!
#ubuntu-x 2009-08-21
<tjaalton> Ng: right, the guy who made those patches is the g-p-m maintainer, so you need a newer g-p-m..
<tjaalton> we all do :)
<hyperair> what patches?
<tjaalton> hyperair: http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/
<tjaalton> both are in karmic, so we just need a newer g-p-m
<tseliot> bryce: where's the new nvidia-driver? https://launchpad.net/ubuntu/karmic/+source/nvidia-graphics-drivers-180/
<tjaalton> tseliot: what do you mean?
<tseliot> tjaalton: see the discussion in ubuntu-devel
<bryce> tseliot, rejected by archive admin again
<tseliot> bryce: that was the one with -185 in the source
<tseliot> tjaalton: uploaded the one with 180
<tseliot> tjaalton was really the subject of my previous sentence... therefore s/:/
<tseliot> s/://
<bryce> ok
<bryce> nite
<tseliot> night bryce
<kazade> hi, I noticed that there are some patches here ( http://people.freedesktop.org/~glisse/kms/ ) for R600 KMS, can we expect to see KMS on R600 in Karmic soon?
<tjaalton> doubtful
<kazade> :(
<tjaalton> but that's just me, I don't know what bryce/apw have planned
<kazade> ok, I just actually read the patch and it says: "This only provide a kms drm fb device for this hw and allow X to run with no acceleration" so yeh, not ready :)
<apw> heh.  kernel support is there for some cards, but without mesa support its useless and that is a complex problem i believe
<kazade> it's typical that I only just upgraded from an R300 (AGP) (when I knew KMS was coming) to an R500 (PCIe) and now I can't go back to try out KMS :/
<kazade> *R600
<kazade> well, at least I assume it's an R600... how can I tell?
<tjaalton> yeah, there are many moving parts, and I'm not sure if it's robust enough just yet
<kazade> well, I've got an HD3200... but I can't find anywhere whether that is an R500 chip, or R600... 
<tjaalton> r600
<kazade> ah ok thanks
<tjaalton> hd2xxx-> is r6xx/7xx
<tjaalton> er
<tjaalton> well, yes
<superm1> jbarnes, i've actually got the hardware for bug 416792 at my desk for today. is there anything else you'd like me to add to that bug while i've got it?
<ubottu> Bug 416792 on http://launchpad.net/bugs/416792 is private
<jbarnes> superm1: zhenyu said he posted a fix to intel-gfx, but I don't ahve it handy
<jbarnes> iirc it was for the agp device
<superm1> intel-gfx being an intel kernel git tree, or ML or what?
<jbarnes> ml
<jbarnes> intel-gfx@lists.freedesktop.org
<superm1> i'm probably not too sure what i'm looking for, but if you were referring to http://lists.freedesktop.org/archives/intel-gfx/2009-August/003824.html, the host bridge ID of this system is 0x0044 which was already supported
<jbarnes> superm1: could be the "VGA plane" patch
<jbarnes> looks like that patch might also be in "Patch to fix fdo bug #21064"
<ubottu> Launchpad bug 21064 in gnome-panel "gnome panel crah when trying to add applet" [Medium,Fix released] https://launchpad.net/bugs/21064
<superm1> but those both look like they are the non-KMS case aren't they?
<jbarnes> there should be a kms equivalent for the vga one I think
<jbarnes> though maybe not... zhenyu is the real expert here
<superm1> okay i won't get ahead of myself here then trying to look into it too much then :)
<jbarnes> yeah sorry I'm only just starting to hack on iron lake stuff
#ubuntu-x 2009-08-22
<mdeslaur> karmic dist-upgrade failed to update to nvidia-glx-185 properly, and nvidia-glx-185 hangs my laptop: bug #417373
<ubottu> Launchpad bug 417373 in nvidia-graphics-drivers-180 "nvidia-glx-185 on karmic hangs laptop with black screen" [Undecided,New] https://launchpad.net/bugs/417373
<kazade> hey, can someone point me in the right direction to test the new R600 3D acceleration in Karmic? do any of the Xorg-edgers style PPAs have it?
<jcristau> hmm so you're no longer using the mesa git repo?
<tjaalton> jcristau: I guess it's temporary until 7.6 is out
<tjaalton> or a release candidate
#ubuntu-x 2009-08-23
<kazade> hi, I've just been spending some time in #radeon trying to compile Alex Deutcher's R600 3D acceleration support on Karmic, but it's not working and they seem to think that perhaps there are some custom patches in Ubuntu which are breaking it. I don't suppose any of you had any luck compiling that branch?
<tjaalton> you have the needed kernel bits too?
<kazade> I've tried building using these instructions: http://www.phoronix.com/forums/showthread.php?t=18589 and also building in tree, I'm just trying rebuilding in tree one final time, it's possible I messed up the first time
<kazade> ok, i'm back. I recompiled radeon.ko and drm.ko and installed them. Now I get this: http://pastie.org/592031 so I rebuilt the ttm.ko module and it made no difference :(
<kazade> bryce, any chance of getting an r6xx/7xx 3D acceleration ppa in xorg-edgers :p
<RAOF> Gah.  Too late.
<tjaalton> probably the old ttm.ko is still being loaded
<kazade> got it working... needed to load the "ttm" module at boot
<kazade> it just wasn't being loaded by the look of it
<kazade> I added "ttm" to /etc/modules and now I have Compiz on an R600 with the OSS stack ;)
<RAOF> Possibly it was also the initramfs having an older drm.ko and loading it, too.
<RAOF> That's always fun for nouveau.
<kazade> I'm just glad to have 3D back after a couple of months of 2D only :)
<RAOF> Thinking of nouveau, we should get a new snapshot of drm + DDX before feature freeze.
<tjaalton> RAOF: there already is a new libdrm, is it enough?
<RAOF> Yes, it is.
<kazade> Do you reckon we'll have this ATI R600 3D out of the box in Karmic? I'm using it and there's only a little text corruption in the terminal when compiz is enabled.. everything else seems fine :)
<RAOF> It will be simple enough to do the update; I'm just not sure if I'll get time to go through the full process.
 * RAOF should be working right now!
<tjaalton> and I should be painting walls :)
<RAOF> Ok.  The new libdrm hasn't made it through NEW yet.  Excuse!
<mac_v> hi... anyone around? need some advice with ATI xorg-edge ? :)
<mac_v> could someone instruct me how to set the kernel setting mentioned in comment #7 https://bugs.freedesktop.org/show_bug.cgi?id=23386
<ubottu> Freedesktop bug 23386 in Driver/Radeon "Artifacts with cairo dock 2.0 [openGL]" [Normal,New]
<mac_v> bryce: ^?
<xax> hi. ever since Ubuntu 9.04, kernel 2.6.28-13-generic, I only see noise on my screen right after the splash screen. I can hear sound and I can even log in (blindly), but the whole screen is filled with garbage. this problem didn't come up in and before 2.6.28-11-generic. I have an ATI card. is this a known problem?
#ubuntu-x 2010-08-23
<Sarvatt> jg: talk about timing, all of that intel stuff got pulled when we were talking about it earlier and 2.6.36-rc2 came out with it, it should be up here tomorrow and has way too many eDP fixes to count :) http://kernel.ubuntu.com/~kernel-ppa/mainline/
<jg> Sarvatt: ok, I'll take it for a spin then...  
<jg> of course, rc2's tend to be a bit "exciting"....d
<Sarvatt> picking out what fixed it will be fun if it ends up working for you
<Sarvatt> (58 commits)
<Sarvatt> of course it could have been fixed in rc1 for you too but you wouldn't know because i915 couldn't load right on it in the first place :)
<jg> Sarvatt: heh.  And keithp finished up the 1.9 server too...
<jg> Sarvatt: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d0498a2bf7455159b317f19531a3e5db2ecc9c4 looks hopeful...  
<Flynsarmy> I'm on Ubuntu 10.04 on a laptop with nvidia-propreitry. I have an external to the right in twinview but the leftmost 10-20px get cut off. left, top and right are all in-line with the edge of hte monitor. How can I fix this?
<c10ud`> hi all, i'm using this nice ppa for my video card, however i need to downgrade from 256.44 -> 256.35 due to an hard x lockup in the nvidia binary blob (nvidia already knows about this)
<c10ud`> which is the best way for such a downgrade?
<jg> Sarvatt: no joy on RC2.
<cnd> bryceh, we're looking towards uploading a bunch of stuff for utouch today
<cnd> which requires an upload of the new evdev
<cnd> do you think you could take a look at it and upload it if it's ok?
<cnd> we've been testing it ourselves, you can test it out from the ppa:utouch-team/unstable ppa if you want
<bryceh> cnd, 1:2.3.2-6ubuntu1~utouch3 ?
<cnd> bryceh, yep
<cnd> it incorporates the changes you suggested in your review
<bryceh> cnd, ok looks good to me, uploaded
<cnd> bryceh, thanks!
<bryceh> I reversioned it to -6ubuntu1 btw
<bryceh> cnd, also, can you commit the changes to git?
<cnd> bryceh, I don't have commit rights
<bryceh> argh
<bryceh> ok, I can commit it
<bryceh> we should get you commit rights though
<cnd> that's fine with me
<bryceh> (even though it sounds like mark wants us to move to bzr)
<cnd> bryceh, sorry about that...
<bryceh> cnd, tjaalton or jcristau can hook you up when they're online I think
<cnd> I think a case could be made given that our work is highly based on debian's packaging
<cnd> a case for staying in git
<bryceh> well, it does make me curious about the state of the bzr/git syncing functionality
<bryceh> cnd, ok let me know if there's any problems with -evdev
<cnd> bryceh, will do
<tjaalton> cnd: create a guest account on alioth.debian.org, and join pkg-xorg
<cnd> tjaalton, ok
<tjaalton> cnd: jcristau (or some other admin) could then add you to the group, and off you go
<tjaalton> bryceh: re git->bzr; reference?-)
<cnd> tjaalton, I created an account, corp186-guest. How do I get rid of the "-guest"?
<tjaalton> cnd: by becoming a DD :)
<cnd> uhhh, ok I guess :)
<bryceh> tjaalton, the multitouch mailing list
<tjaalton> bryceh: ah, alright
<cnd> tjaalton, I've requested addition to pkg-xorg
<cnd> thanks for the pointers :)
<tjaalton> cool, np
<tjaalton> humm, so is it nowadays possible to work with bzr&git from the same repository copy?
<cnd> tjaalton, when bzr-git isn't broken
<cnd> like it is in maverick...
<tjaalton> cnd: ok. I haven't tried it in a loong time
<jg> Sarvatt: no luck with RC2
<asac> o/
<asac> RAOF: heya !!! ;)
<asac> hope you had a good night :-P
<asac> RAOF: what do you think about making xserver-xorg -> Depends: xserver-xorg-driver-all | linaro-xserver-xorg-driver-fakeall ?
<asac> linaro-xserver-xorg-driver-fakeall would live in a ppa ... and would only depend on -fbdev ... and would probably provide xserver-xorg-driver-all
 * asac has to get rid of all the driver cruft on linaro/arm
<asac> RAOF: actually xserver-xorg-driver-all -> ...-video-all
<Sarvatt> asac: just remove everything but what you want from scripts/vars.arm in the xorg metapackage? it looks like its just a placeholder noones looked at anyway
<asac> Sarvatt: hmm. 
<asac> good point
<asac> will check with ogra
<asac> ok i missed the xserver-xorg-video-8 provides
<asac> seems we can alrewady remove everything we didnt want
<asac> RAOF: so unless i come back, scratch that noise from above ;)
<jg> Sarvatt: well, RC2 was not useful; same symptoms.
<Sarvatt> dang, sorry to hear that jg, thanks for letting me know it wasn't fixed though :(
<jg> Sarvatt: yeah, such is life.  at least there is a kernel known to run though....  
#ubuntu-x 2010-08-24
<RAOF> For those playing at home: annotating a WakeupHandler with debugging has an adverse effect on performance :)
<Sarvatt> cnd: serverminver isn't used (or even shipped) anymore AFAIK
<RAOF> That's true, as of 1.8.99.905-1 from memory.
<RAOF> Really, the correct thing would be to bump inputabi, butâ¦ uurgh.
<Sarvatt> RAOF: nice, you worked out the gnome-screensaver fade problem?
<RAOF> Yup.
<RAOF> Edge cases FTW!
<RAOF> Also, thanks go to the guy on the Fedora bug report who did a bunch of analysis.
<RAOF> Now, lunch.  Then a sponsor for Xserver 1.9 & a please-don't-crash radeon update!
<Sarvatt> RAOF: you going to UDS? don't see you on https://wiki.canonical.com/UbuntuPlatform/UDS/N yet :)
<RAOF> I just need to get an email back from the travel agent confirming my flights.
<RAOF> Then I'll be up there :)
<Sarvatt> haven't confirmed my flight yet, I think I may be going to the plumbers conference straight after
<RAOF> That could be likely.
<Sarvatt> my anniversary is exactly in the middle of the two.. the wife wont be happy :)
<Sarvatt> (halloween)
<RAOF> That's a badly positioned anniversary :(
<RAOF> Anyone feel like closing a few bugs by sponsoring xorg-server and xserver-xorg-video-ati?
<tjaalton> RAOF: I can do that after lunch
<tjaalton> now ->
<tjaalton> (back in an hour)
<RAOF> tjaalton: Sweet.  They're in pkg-xorg git or http://cooperteam.net/Packages/
<RAOF> âª My heart's calculatin', my true love will be waitin', be waitin' at the end of my ride â«
<tjaalton> RAOF: you're losing it ;)
<tjaalton> anyway, uploaded
<Ng> is there a classier way to get the nouveau KMS driver to interact with the binary nvidia driver than just blacklisting nouveau on the kernel commandline?
<Ng> (and should the nvidia package maybe do that blacklisting if not?)
<tseliot> Ng: the nvidia package already blacklists nouveau in the initramfs
<tseliot> provided that the nvidia driver is enabled
<tseliot> i.e. that it's the selected "alternative"
<Ng> hmm
<Ng> perhaps I broke something
<tseliot> Ng: "update-alternatives --display gl_conf" should tell you what's the alternative in use
<Ng> it says it's in auto mode and pointing at /usr/lib/nvidia-current/ld.so.conf
<tseliot> Ng: this means that you didn't use jockey to enable the driver (don't do that)
<tseliot> ;)
<Ng> I may well have just installed nvidia-current
<tseliot> yes, that's what I thought
<tseliot> "sudo update-initramfs -u" should still blacklist the driver in the initramfs
<Ng> interesting
<Ng> I'll have a play with that, thanks
<tseliot> np
<Sarvatt> Dr_Jakob: next release probably, we dont have the extra 13mb+ to spare on the livecd 
<Sarvatt> re: llvm mesa
<Milos_SD> Hi
<Milos_SD> can you please give me address for pixman packages in xorg-edgers?
<Milos_SD> I need to get older version
<Milos_SD> Sarvatt: can you give me direct link to older packages of libpixman-1.0
<Sarvatt> http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/p/pixman/
<Milos_SD> thanks
<Dr_Jakob> Sarvatt: yeah, its like a 8mb increase in size per driver.
<Dr_Jakob> for 32bit
<ginggs> tjaalton: hi, have you had a chance to discuss whether to fix http://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/553415 in 1.7.6 or backport 1.7.7 for lucid?
<ubot4> Launchpad bug 553415 in xorg-server (Ubuntu Maverick) (and 6 other projects) "mouse trapped in box for Open Motif (affects: 26) (dups: 3) (heat: 114)" [Undecided,Fix released]
<tjaalton> ginggs: not right now, but I'll test the patch locally tomorrow to see if it fixes a similar issue with maple (which, aiui, has a java-based ui but I managed to get it stuck in a similar manner)
<cnd> bryceh, when you pushed the evdev stuff to git, which repo did you push to?
<cnd> I don't see anything in http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=shortlog;h=refs/heads/ubuntu
<Sarvatt> RAOF: got some initial mesa-demos packaging here if you want to mess with it - http://sarvatt.com/downloads/mesa-demos/
<Sarvatt> it needs some love, I haven't wrapped my head around the dh 7 magic to skip dh_auto_install yet so its installing all xdemos :)
<Sarvatt> + copyright stuff
<bryceh> cnd, actually I hadn't gotten around to committing it yet
<bryceh> cnd, are you set up with commit permissions?  want to go try them out?
<cnd> bryceh, I assume I should have received an email?
<cnd> I haven't seen anything, so I'm guessing I don't have perms
<bryceh> yeah dunno
<jcristau> https://alioth.debian.org/projects/pkg-xorg says you should be good to go
<cnd> jcristau, oh?
<cnd> ok, I'll try it out
<jcristau> uid=230910(corp186-guest) gid=230910(corp186-guest) groups=230910(corp186-guest),41008(pkg-xorg),81008(scm_pkg-xorg)
<cnd> bryceh, jcristau: how do you recommend pushing?
<cnd> there's an up to date debian-unstable branch
<cnd> and an old ubuntu branch
<cnd> I assume I'll push to ubuntu
<cnd> but should I just take the debian-unstable and cp -a * from the ubuntu evdev over the top?
<jcristau> so the ubuntu branch hasn't been kept up to date?
<cnd> or should I take the current ubuntu branch and do likewise?
<cnd> jcristau, ubuntu's been shipping the debian-unstable for a while
<cnd> I think
<bryceh> jcristau, it's up to date however we sync'd -evdev last it looks like
<jcristau> bryceh: ah right
<bryceh> cnd, so yeah, start from the debian-unstable branch
<bryceh> (actually I probably shouldn't give git advice... I always seem to louse it up *grin*)
<cnd> heh
<cnd> bryceh, what I did locally is start from debian-unstable
<cnd> then cp -a ../xserver-xorg-input-evdev-2.3.2/* .
<jcristau> so maybe rename the ubuntu branch to lucid, and start a new ubuntu branch from the sync point?
<cnd> where the other dir includes the ubuntu package
<cnd> jcristau, I can do that too
<jcristau> (i guess it depends if people are likely to care about the lucid stuff)
<cnd> jcristau, since lucid is an lts, I would guess it could be handy
<cnd> and git branches are lightweight :)
<jcristau> ack
<cnd> jcristau, bryceh, why don't I attempt something and push it to a repo
<cnd> and you can check it out to make sure it makes sense
<jcristau> sure
<bryceh> ok
<cnd> I probably won't get to it for a few hours though
<cnd> jcristau, how do I get access to git.debian.org?
<cnd> do I need to upload my ssh key somewhere?
<jcristau> https://alioth.debian.org/account/editsshkeys.php
<cnd> jcristau, ok, thanks
<jcristau> or you can login with your alioth password
<cnd> jcristau, how do I start a new git repo on git.debian.org?
<cnd> do I need to ssh there first?
<jcristau> yep
<cnd> hrm, if I knew my alioth username was going to be for shell access too, I might have chosen more wisely :)
<cnd> jcristau, how do I get my own users git area?
<jcristau> mkdir ~/public_git
<cnd> ahhh
<cnd> I was trying to mkdir in /srv/git.debian.org/git/users
<jcristau> then the repos you put in there show up on gitweb (after a few hours)
<cnd> ok
<cnd> jcristau, my connection to git.debian.org is rather flaky
<cnd> do you know if there's anything wrong with it, or if there's something I should do?
<jcristau> seems to work for me
<jcristau> its load is stupidly high, but that's not unusual
<cnd> I keep getting connection timeouts
<cnd> while trying to connect
<cnd> I am seeing this now over ssh, but I also saw it earlier when trying to clone a repo
<jcristau> oh.  it's running fail2ban, so may have locked you out for a bit.
<cnd> what does that mean?
<jcristau> http://wiki.debian.org/Alioth/SSH#A...butAliothrespondstopings
<cnd> jcristau, thanks, sounds like I just need to wait a few mins
<Sarvatt> whoa, all this time I didn't know the hidden copy-packages feature lets you copy from debian
<Sarvatt> that'll make x-updates easy :) https://edge.launchpad.net/debian/+archive/primary/+copy-packages?field.name_filter=libdrm&field.status_filter=published&field.series_filter=squeeze
<Sarvatt> if only it didn't time out 90% of the time
<Sarvatt> ah darn, you can't rebuild for ubuntu releases that way
<Sarvatt> launchpad supports debian ppa's now? hmm
<Sarvatt> adapting my xorg-edgers update scripts for debian would be super simple if so
#ubuntu-x 2010-08-25
<minimec> Hi. Again i am living this unendable ATI nightmare. Ubuntu switched X-Sserver three times in for distributions and all the time it was like starting from scratch with an ATI RS690 (x1250). Now testing 10.10 here we go again. With xserver 1.9 I have again a flickering screen with HDMI, a dissorted Image in Googleearth, a glxgear framerate limited to 300frames in 5 seconds, and not even gallium to test. I can test that with the x-edgers dr
<minimec> Can we hope for gallium in 10.10?
<RAOF> minimec: In 10.10?  No.
<RAOF> It's not a panacea, either.  At this point it's more differently broken :)
<minimec> RAOF: definitly not? So I don't see a reason to continue with 10.10... Let's hope for a good 2.6.35 Kernel in lucid to get the new ATI features...
<RAOF> Incidentally, glxgears going at 300frames / 5 seconds is totally intentional.
<RAOF> This is why we say glxgears Is Not A Benchmarkâ¢.
<RAOF> You'll notice that 300 frames / 5 seconds corresponds toâ¦ 60 frames/sec, which is the 60Hz of your screen's refresh rate.
<RAOF> Behold!  For vsync now works!
<minimec> RAOF: I know. In fact... I have a regression in 'Look+Feel' of the whole system. That GPU runs definitly slower on 10.10...
<RAOF> Also, the X server itself doesn't have a particularly large influence on the open drivers - you say that HDMI worked for you at some point?
<RAOF> It's probably kernel changes which have broken that.
<minimec> RAOF: HDMI worked first time in Karmic and worked in Lucid.. Now I get the sreen, but the image is adjusting all 10 sec or so.
<tjaalton> have you tried with the lucid kernel?
<minimec> RAOF: At leat I have to say, that video playback has evolved on the ATi opensource driver and there is (almost) nothing to complain anymore.
<minimec> tjaalton: Talking to me? I see no reason to use an 'obsolete' kernel (missing some ATI features) on a testing system...
<minimec> tjaalton: ... using a ATI device ;)
<RAOF> minimec: Using a lucid kernel (and getting HDMI working) would mean that your HDMI woes are kernel related.
<RAOF> It's aâ¦ test.  For your testing system :)
<minimec> RAOF: THat is in fact some an argument. I installed the x-edgers ppa to have my HDMI working.
<RAOF> For bonus points you could test to see _when_ HDMI broke; you could go through all the released kernels from Lucid to current Maverick and find the last one which worked.
<RAOF> It works in x-edgers?  Do you have kernel modesetting disabled?
<minimec> RAOF: So HDMI is working with the current 10.10 kernel with the x-edgers ppa
<minimec> RAOF: No. KMS is default and activated.
<RAOF> Colour me surprised; userspace doesn't do very much on the modesetting front now.
<tjaalton> yeah, I would've thought it was in the kernel..
<minimec> RAOF: the RS690 is some special GPU based basically on the r300. That's why I guess we have 'good' x-edgers support for this card (kms included)
<RAOF> xorg-edgers has the same x server as Maverick, so we can pretty much discount that...
<RAOF> Hm.  And xserver-xorg-video-ati doesn't seem to have any interesting commits re: HDMI for your card.  Unless it's really an r600 :)
<minimec> RAOF: http://www.x.org/wiki/RadeonFeature It is definitly not.
<minimec> RAOF: You are right... I also have the HDMI problems with the x-edgers ppa. I switched too much from my 'productive'- to my 'test'- system. Ok this will end in a bug report. 
<tjaalton> try with the lucid kernel to see if that helps..
<minimec> tjaalton: Yep. THis will be part of bug tracking (or an 34 kernel from the kernel mainline)
<om26er> using xorg-edgers ppa(linux-image-2.6.35-19-generic) on Lucid. if I install libgl1-mesa-dri-gallium using nvidia 9800gtx+ keyboard and mouse does not work at gdm. though I can still kill X by alt+sysrq+k any help?
<cnd> bryceh, jcristau: I've pushed up lucid and maverick branches for evdev to git://git.debian.org/users/corp186-guest/xserver-xorg-input-evdev.git
<cnd> http://git.debian.org/?p=users/corp186-guest/xserver-xorg-input-evdev.git;a=summary
<cnd> in case you want a gitweb version
<cnd> Sarvatt, RAOF: is it possible to get fglrx on maverick yet, or are we still waiting for updated drivers?
<tseliot> cnd: there's no driver yet
<tseliot> I'm the maintainer BTW
<cnd> tseliot, ok, thanks!
<cnd> tseliot, do you know when it will be available?
<tseliot> cnd: maybe... but I can't discuss it here
<cnd> tseliot, ok
<cnd> it's not information I *need*
<cnd> just want it for my laptop :)
<cnd> so don't worry about it
<tseliot> cnd: ok, good to know ;)
<Sarvatt> cnd: oh I totally missed your messages here, sorry!
<cnd> Sarvatt, np :)
<tseliot> Sarvatt: BTW my late congrats on joining Canonical :-)
<jcristau> cnd: looks good (evdev git branches)
<Sarvatt> cnd: from what I have read that is public information, fglrx 10.10 will be the first one with new features and 10.8-10.9 will just be bug fix releases, ubuntu may get a beta of 10.10 if it supports xserver 1.9 I imagine somehow :)
<Sarvatt> cnd: btw mesa in xorg-edgers supports 3D on hd 5xxx chips now
<Sarvatt> thanks tseliot!
<Sarvatt> cnd: but not 2D acceleration, they are doing that on a seperate branch of the driver because its got freezing problems at the moment
<Sarvatt> -radeon without acceleration is probably faster than fglrx at 2D though :)
<tseliot> heh
<cnd> Sarvatt, can you briefly walk me through the steps to tell if I have an hd 5xxx chip?
<cnd> just lspci?
<Sarvatt> do you know if its a HD 5000 or higher series?
<cnd> I have an RV710/730
<cnd> I don't know anything other than what I can find in ubuntu
<Sarvatt> ah that uses r600
<cnd> Sarvatt, so is there any hardware 3d acceleration I can get in maverick?
<jcristau> yes
<Sarvatt> you have it already
<cnd> oh, then it's just plain borked :)
<Sarvatt> it's significantly better in mesa 7.9 though
<cnd> unity is all messed up
<cnd> Sarvatt, do I just need to use the xorg-edgers ppa to get the new mesa?
<tseliot> r600 works great here but you need the latest mesa to use unity
<Sarvatt> oh yeah unity is messed up on all ati's it seems like at the moment :(
<Sarvatt> i thought it was just r500 and older ones though
<Sarvatt> unity is broken on intel 945 and 965 and nouveau here too
<tseliot> ah
<Sarvatt> cnd: just curious - glxinfo | grep GL_ARB_texture_non_power_of_two
<tseliot> I think that should be in the new mesa
<cnd> Sarvatt, I do have that
<Sarvatt> i thought it was in mesa 7.8 for r600+ 
<cnd> without any new mesa
<Sarvatt> ah ok not the same problem
<tseliot> that wasn't the only problem
<Sarvatt> cnd: try CLUTTER_VBLANK=none unity
<Sarvatt> that actually fixes it for me on intel
<cnd> Sarvatt, ok
<Sarvatt> it was all white before
<cnd> Sarvatt, it's all screwed up now
<cnd> Sarvatt, should I just try out the latest mesa?
<Sarvatt> thought it was before? :)
<cnd> I just don't know where it is
<cnd> Sarvatt, more screwed up :)
<Sarvatt> cnd: can you push the maverick branch as ubuntu instead for consistency?
<cnd> Sarvatt, should I keep lucid as is and just call rename maverick to ubuntu?
<Sarvatt> sure if ya want, i doubt we'll use the lucid one since SRU's are usually by people not on pkg-xorg :) xserver uses ubuntu-lucid though, might make sense to use that too
<cnd> ok
<Sarvatt> is there no way to configure unity? its taking up a bit too much space on this netbook
<Sarvatt> it's odd, looks like it could have just been a docky theme
<bjsnider> what's the command to check for nvidia alternatives?
<tseliot> update-alternatives --display gl_conf
<bjsnider> this guy is having trouble playing interlaced european video using vdpau on his ion netbook
<bjsnider> but the hardware should be good enough
<Sarvatt> ugh, a mesa 7.9 merge in debian git is rough, trying to work out how to do this without manually fixing hundreds of conflicts :)
<tjaalton> it's always like that, you can't avoid it ;)
<jcristau> Sarvatt: remove/modify conflicts, hopefully?
<Sarvatt> http://paste.ubuntu.com/483534/
<Sarvatt> almost done fixing it up, its not as bad as I thought :D
<Sarvatt> never done mesa before and thought i might have been missing a merge strategy that makes it easier or something
<jcristau> merge -s ours $old_upstream_branch into the new one helps as a first step
<tjaalton> there should be something on the wiki about that
<tjaalton> iirc
<jcristau> it's somewhere hidden in http://wiki.debian.org/XStrikeForce/git-usage
<tjaalton> and also on https://wiki.ubuntu.com/X/GitUsage
<jg> afternoon Sarvatt 
<jg> Sarvatt: I'm struggling trying to build a RC2 kernel to try a suggestion of jbarnes.  Where would I find directions?
<Sarvatt> yeah XStrikeForce/git-usage is insanely helpful and on my bookmark bar :) jg: hey there! I haven't built a kernel myself in about 6 months and i'm really not sure with all of the changes in the kernel-package package, maybe this wiki will help? https://help.ubuntu.com/community/Kernel/Compile
<Sarvatt> jg: yeah the section starting with "The following instructions are based on this link:"  near the end is what you should use
<Sarvatt> the way i do it doesn't build an initrd or anything and I do it all manually, be sure to disable comedi and ti-st from staging when you do a make menuconfig because they don't build currently
<jg> I noticed :-(.  I want to be fully upstream, so I can easily test with jbarnes.
<Sarvatt>  sudo apt-get install fakeroot kernel-wedge build-essential makedumpfile libncurses5-dev git-core kernel-package; sudo apt-get build-dep linux; cp -r /usr/share/kernel-package $HOME; git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git; cd linux-2.6; cp /boot/config-$(uname -r) .config; make oldconfig; make menuconfig (disable comedi and ti-st from staging drivers) then make-kpkg clean; CONCURRENCY_LEVEL=`getconf _NPROC
<Sarvatt> ESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-jg --overlay-dir=~/kernel-package kernel_image kernel_headers
<Sarvatt> hopefully that should work :)
 * Sarvatt writes that down for next time he's asked
<Sarvatt> probably could just use /usr/share/kernel-package as the --overlay-dir=, not sure why they did it that way in those steps
<Sarvatt> i would add a git checkout v2.6.36-rc2 in there after cloning, i think make-kpkg had a problem with non tagged versions recently
<Sarvatt> also be prepared to delete /etc/kernel/postinst.d/nvidia-common or remove nvidia-common, it doesn't like kernels made with make-kpkg :)
<Sarvatt> dang, not having any luck working out this merge without making a mess of the history.
<Sarvatt> creating a new branch off of upstream/master, merge -s ours upstream-experimental into it, then merging ubuntu on top of that for debian/ and merging that into ubuntu sound right? that gets me the least amount of conflicts but 2 merges in the history
<jcristau> yeah that's basically it
<Sarvatt> seems like this will make a mess when 7.9 is in experimental, and oops make that 3 merges in the log since i haven't commited this one yet :)
<jcristau> wait, why are you merging ubuntu twice?
<Sarvatt> it deletes debian/ when i make a branch off upstream/master, merge -s ours upstream-experimental then merge that new branch into ubuntu
<jcristau> uh.
<Sarvatt> i probably did one of the steps wrong with a pull instead of a merge or reverse, will try again
<cnd> bryceh, jcristau, Sarvatt: sorry for the delay, but I finally did get ubuntu evdev changes pushed to git.debian.org
<cnd> ubuntu became ubuntu-lucid
<cnd> and the maverick branch name became ubuntu
<bryceh> cnd, excellent
<dandel> Sarvatt, the catalyst 10.8 driver is out.
<Sarvatt> dandel: thanks for the heads up, will package it up when i get some free time
<Sarvatt> oh yeah, lunch break. I guess that time is now :)
<Sarvatt> the release notes are for 10.7...
<Sarvatt> hah
<Sarvatt> 6% performance drop is no longer observed while running fgl_glxgears and glxgears on specific cards 
<dandel> Sarvatt, the #1 feature change is: OpenGL ES 2.0 support
<Sarvatt> I dunno, 6% performance increase in glxgears has my vote
<dandel> OpenGL ES 2.0 support is good for firefox v4.x
<dandel> so that's what has my vote.
<bryceh> GL ES support will be interesting to the ubuntu mobile guys I'd bet
<dandel> yes, and it's also interesting for console devs.
<dandel> increasingly the Consoles and mobile devices are gaining OpenGL ES Support
<Sarvatt> yeah I was just being sarcastic :) chromium has had welGL/gles support for almost a year now too
<Sarvatt> WebGL rather
<Sarvatt> its just too bad this doesn't work on maverick
<Sarvatt> well they added support for xserver 1.8 silently in 10.6, maybe it will
<Sarvatt> ok its uploaded to x-updates now
<asac> any idea mesa has or will implement framebuffer objects in swrast?
<BUGabundo> howdy
<BUGabundo> I got a SSD for my laptop yesterday, and did a fresh install of maverick with BTRFS
<BUGabundo> the 1st few boots I had 13 secs with nouveau. once I installed nvidia blob, it went to 23 sec.
<BUGabundo> so I'm willing to give the newer nouveau with 3D support a try.
<BUGabundo> what should I know? how stable and fast is it? what ppa has it? (x-edgers?)
<Sarvatt> <Sarvatt> asac: it has for a long time afaik? I see GL_ARB_framebuffer_object/GL_EXT_framebuffer_object under swrast
<Sarvatt> <Sarvatt> BUGabundo: you can just install libgl1-mesa-dri-experimental in maverick
<BUGabundo> Sarvatt: thanks. no ppa?? how do I do it with jockey ?
<Sarvatt> dont need a PPA, just deactivate nvidia-current in jockey  and enable effects
<Sarvatt> hit cancel when it pops up saying the only way to have desktop effects is by installing the blob :)
<BUGabundo> I'm lost
<Sarvatt> (after installing libgl1-mesa-dri-experimental)
<BUGabundo> so I isntall libgl1-mesa-dri-experimental
<Sarvatt> then deactivate nvidia-current, then reboot and you have 3D
<BUGabundo> disblabe blob in jockey
<BUGabundo> okay
<BUGabundo> eheh 
<BUGabundo> 10 sec boots here I came
<Sarvatt> when you go to enable desktop effects it'll say you need to install the blob but you can just hit cancel
<BUGabundo> LOL
<BUGabundo> hope that gonna be fixed :D
<BUGabundo> how fast and well support is it?
<Sarvatt> dri-experimental isn't supported :)
<BUGabundo> multi monitor, and stuff
<BUGabundo> ahhhh
<Sarvatt> it runs fine though
<Sarvatt> depending what GPU you have
<Sarvatt> geforce 7xxx and older is probably bad :)
<BUGabundo> t8300 (2.4gh) with nvidia 8400m G
<Sarvatt> its fine on that, i've had my wifes laptop on the same thing pretty much with nouveau for about 8 months now
<Sarvatt> turion x2 tl-60 with a 8400m gs
<Sarvatt> as always there's always xorg-edgers if you have problems that might be fixed :)
<Sarvatt> remove dri-experimental first though i've got nouveau in the main dri package there
<BUGabundo> ill try to remember
<BUGabundo> since its not supported, are you interested in any kind of reports
<BUGabundo> ?
<Sarvatt> yeah if its broken it'll be nice to know when not to update her laptop :D
<BUGabundo> AHAHAHAH
<Sarvatt> nouveau is in ia32-libs in edgers too for wine
<BUGabundo> ?
<Sarvatt> wine needs 32 bit DRI libs, its not in ia32-libs in maverick
<BUGabundo> ahhh
<BUGabundo> not installiung wine for now
<Sarvatt> pretty sure google earth needs 32 bit too if you use that
<BUGabundo> yeah, that's just wine
<BUGabundo> $ sudo aptitude install libgl1-mesa-dri-experimental 
<BUGabundo> let the mayhem begin 
<BUGabundo> oop
<BUGabundo> forgot to re-enable 3d
<BUGabundo> oi, its already enabled :S
<BUGabundo> rebooting
<BUGabundo> hoy this nouveau 3D is FAST 
<BUGabundo> ok
<BUGabundo> that didn't make my boot any faster :(((
<bjsnider> you could reduce the grub timeout from 10 seconds down to 1 or 2
<BUGabundo> and its X that is taking 5 precious seconfs
<BUGabundo> bjsnider: there's no timeout at all
<BUGabundo> it boots directly 
<bjsnider> well, i don't approve of that
<Sarvatt> BUGabundo: try after doing a   echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash && sudo update-initramfs -u
<BUGabundo> bjsnider: stock maverick install
<Sarvatt> sudo delete /etc/initramfs-tools/conf,d/splash and sudo update-initramfs -u after  to revert that chane
<Sarvatt> sudo delete?
<Sarvatt> sorry doing 10 things at once :)
<BUGabundo> let me upload bootcharts
<BUGabundo> so you guys can look at them
<Sarvatt> did you reboot twice? maybe ureadahead was working that time
<BUGabundo> only once
<BUGabundo> only hve 6 boots since install
<Sarvatt> oh wow, git rerere is my new best friend
<BUGabundo> Sarvatt: http://bootcharts.f.bugabundo.net/
<Sarvatt> BUGabundo: thats unreadably small
<BUGabundo> click to expand
<BUGabundo> right side, full size png
<Sarvatt> what kind of SSD did you get? I'm guessing an intel x25-v
<Sarvatt> oh nevermind thats a nice max speed :)
<asac> 22:27 < asac> LIBGL_ALWAYS_SOFTWARE=1 glxgears
<asac> 22:27 < asac> 1180 frames in 5.0 seconds
<asac> 22:27 < asac> that cant be right ;)
<asac> is that not supported anymore?
<Sarvatt> BUGabundo: btrfs? RAOF was mentioning how btrfs had a *huge* performance regression in maverick right now
<BUGabundo> sure it can asac. its magic
<BUGabundo> Sarvatt: I read about it
<BUGabundo> but seems to be workign fine for me
<Sarvatt> asac: whats wrong about it? :)
<BUGabundo> I told you that, when I entered the room
<asac> Sarvatt: i dont see a fbs difference for glxgears with and without it
<asac> on full screen
<asac> is that ok?
<Sarvatt> yeah glxgears isn't a benchmark of anything useful, those numbers dont look wrong to me
<asac> good. i confirmed in glxinfo that its really software rast
<asac> thanks
 * asac goes test unity with that ;)
<Sarvatt> 922 frames in 5.0 seconds = 184.349 FPS on a turion x2
<BUGabundo> WOW
<BUGabundo> jumping to TTYs and back is WAY faster
<BUGabundo> 208 frames in 5.0 seconds
<BUGabundo> asac left ? :(
<BUGabundo> Sarvatt: what did asac do to get that!?
<Sarvatt> probably has a fast cpu :)
<BUGabundo> :((
<Sarvatt> and no compiz running
<BUGabundo> ahh
<BUGabundo> FAIL
<BUGabundo> well going for a new reboot
<BUGabundo> to see if that command you gave did anything
<jg> Sarvatt: I'm still losing: near the end of building the packages, it says: dpkg-gencontrol: error: package linux-image-2.6.36-rc2-jg+ not in control info
<Sarvatt> jg: yeah thats the error you get if you dont build from a tag and use master, I'm not sure how to fix it outside of just building from the tagged release
<Sarvatt> git checkout v2.6.36-rc2
<jg> I did....
<Sarvatt> oh? hmm
<BUGabundo> mew
<BUGabundo> 20 sec
<BUGabundo> a bit lower
<BUGabundo> still not the 13 sec of the 1st boots
<BUGabundo> uploading now
<Sarvatt> maybe it's because you had local changes, ugh
<BUGabundo> local changes?
<BUGabundo> I have a new kernel ... LOL
<BUGabundo> and yeah, I instaled a bunch of packages
<Sarvatt> that was directed at jg
<BUGabundo> let me remove some stuff from the start
<BUGabundo> ahhhhhh
<BUGabundo> not in my log 
<BUGabundo> LOL
<Sarvatt> jg: I'm really sorry but I don't know how to fix it and am in the middle of some work, maybe someone in #ubuntu-kernel would know?
<jg> Sarvatt: thanks for your help.
<Sarvatt> will look in a bit otherwise
<Sarvatt> jg: http://ftp.us.debian.org/debian/pool/main/k/kernel-package/kernel-package_12.036_all.deb
<Sarvatt> that should fix it
<Sarvatt> need to rm -rf ~/kernel-package and cp -r /usr/share/kernel-package $HOME again after updating it, looks like the version in maverick is screwed up with .35-rc4 and newer kernels. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588126
<ubot4> Debian bug 588126 in kernel-package "kernel-package: Fails to build linux-image on 2.6.35-rc4 if CONFIG_LOCALVERSION is set" [Important,Fixed]
<Sarvatt> jg: if you're on i386 and can send me the patch I can try building you one on my vps in about 45 minutes
<Daekdroom> RAOF, ping
<jg> Sarvatt: that seemed to finally fix it....  I have a couple packages to try to install....
<jg> Sarvatt: ok, if I want to rebuild a single driver, now what do I do?
<Sarvatt> hope you used ccache the first time? :D
<Sarvatt> really though you might be able to just run the make-kpkg line again without cleaning it first and have it only build that again, i'm not sure
<Sarvatt> jg: thanks for getting me to look into it because I've been wanting to figure out how to do it these days :)
<Sarvatt> hyperair: have you seen that linux-phc has dkms packages now??
<Sarvatt> jg: btw there should be no need to use a tagged release in that new kernel-package afaik
<ripps> did the latest kernel fix wacom bamboo? 
<ripps> input: mt: Add support for the Bamboo Touch trackpa
<RAOF> Daekdroom: Contextless pong.
<Daekdroom> RAOF, bug 617201 isn't fixed yet
<ubot4> Launchpad bug 617201 in xserver-xorg-video-ati (Ubuntu) (and 1 other project) "Xserver crash in radeon_frame_event_handler (affects: 4) (dups: 2) (heat: 30)" [High,Fix released] https://launchpad.net/bugs/617201
#ubuntu-x 2010-08-26
 * RAOF fires up his radeon system.
<RAOF> That patch fixed it for me, and is broadly correct.
<Daekdroom> Well, what was that fix for anyway?
<Daekdroom> Because I'm getting a very similar traceback call.
<RAOF> Reference-count DRI2 buffers and take a ref when scheduling a swap so that the buffers are still valid when the vblank event occurs.
<RAOF> The problem was when a client sent a SwapBuffers request and then quit before the swap was complete.  That would result in it's buffers being freed, but the swap-complete callback would still try to use them.
<RAOF> There was also a similar -intel problem that got fixed in a similar way.
<Daekdroom> RAOF, http://pastebin.com/RT9sizAq
<Daekdroom> That's from earlier today.
<RAOF> That looks like a different trace to me; you don't happen to have a second system so you could attach gdb and get a proper backtrace?
<Daekdroom> No second system, unfortunately.
<Daekdroom> But yeah, it looks slightly different to me, but didn't happen untill today
<RAOF> Booo.  How easy is it for you to reproduce this?
<Daekdroom> Just open this specific Wine program, why?
<RAOF> Well, because you could give me ssh access and I could gather a proper backtrace :)
<Daekdroom> I don't like handling ssh :S
<RAOF> Well, you can find my public keys on launchpad.
<RAOF> Alternatively, you can _kinda_ get a proper backtrace on one system, but it's a bit faffy.
<RAOF> Oh!
<RAOF> What wine program?
<Daekdroom> Huh, a game plataform called BYOND.
<RAOF> Linky?
<Daekdroom> Tried to reproduce it somehow in a native app and still didn't find a single one
<RAOF> I mean, I could try running it :)
<Daekdroom> RAOF http://www.byond.com/ trying to run a game with hardware 2D acceleration, regardless if OpenGL or DirectX will cause a instant Xcrash
<Daekdroom> I still have quite a few other native apps here I can try
<RAOF> I'll give byond a whirl.  If you find another app which exhibits the crash, pipe up :)
<Daekdroom> Ok, I'll dig it.
<RAOF> Daekdroom: Bah.  Any tips for running byond in wine?
<Daekdroom> RAOF, oh, msvcrt
<Daekdroom> Forgot to mention that override
<RAOF> Which version?
<Daekdroom> I use the vc6run one from winetricks
<Daekdroom> *vb6run
<Daekdroom> Ah, nvm, vcrun6
<Daekdroom> Hm, yeah, that last one
<RAOF> And what game kills it for you?
<RAOF> Well, that's promising ):
<RAOF> :)
<RAOF> Find a winning crasher? :)
<Daekdroom> RAOF, apparently, any game as long as I try to activate 2d hardware accel
<Daekdroom> (that, of course, requires the game to have graphics)
<RAOF> Sweet.  That just killed it.
<Sarvatt> RAOF: http://sarvatt.com/git/cgit.cgi/mesa.debian/ in case it helps any, going to try to do the rest tomorrow
<RAOF> Sarvatt: Thanks muchly.
<Sarvatt> still have the problem with demos though, the majority of that crap doesn't have any license :( i've got a really crappy package started here http://sarvatt.com/downloads/mesa-demos/
<Sarvatt> seems like its a bit too late for a r300g
<RAOF> Indeed it does.
<RAOF> Particularly since it breaks ums support.
<RAOF> Re mesa-demos: I'd like to ship all the demos, but that can wait for Natty.
<Sarvatt> maybe we should just just rip the ones we want out and put them in a subdirectory in the mesa tarball since we're repacking it, and have a seperate build step?
<RAOF> Are we repacking the mesa tarball still?
<Sarvatt> yeah its still split into 2
<Sarvatt> or will be that is
<RAOF> MesaLib andâ¦ ?
<Sarvatt> did MesaGLUT move too? 
 * Sarvatt looks
<RAOF> From what I can see we don't build glut from the mesa source package at the moment anyway.
<RAOF> Oh, poot.  How are we getting an invalid buffer there?
<RAOF> Oh, whoops!
<RAOF> Mea culpa.
<hyperair> Sarvatt: what? dkms packages for phc? where?!
<hyperair> Sarvatt: and i thought the cpufreq governer was builtin rather than built as a module so phc couldn't be built as a module?
<NCommander> Does anyone know if this symbol still exists in our version of Xorg?
<NCommander> XF86VidModeSetViewPort
<tjaalton> libxxf86vm1
<jcristau> that's not in Xorg... what tjaalton said
<kklimonda> hmm.. any known problems with nouveau locking up? I get one when using firefox from time to time. Only thing in /var/log/messages I can see is [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2. After that I can't even kill X with sysrq+k - console flashes for a second, I can see [drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon and then I'm back to frozen X.
<kklimonda> up to date maverick, no ppas enabled
<RAOF> kklimonda: That kernel message is the GPU locking up; what GPU do you have?
<kklimonda> RAOF: nVidia Corporation G84M [Quadro NVS 140M] (rev a1)
<RAOF> Gah.
<RAOF> That's not particularly known, but there's not a huge set of debugging options for nouveau.
<kklimonda> RAOF: anything I can do to help? :)
<RAOF> If you can find a dependable trigger it'd be useful and poke it upstream.
<RAOF> Sarvatt: I've pushed my work on those mesa packages to ubuntu-maverick on pkg-xorg; feel free to pick it up and run with it if you've got time today :)
<ion> sarvatt: Is the new fglrx release in x-updates compatible with the current xserver-xorg? (It would be really nice if it had a Breaks relation to incompatible ABIs.)
<Sarvatt> ion: I don't know, they dont mention it in the release notes when they make it work with newer ones and I dont have anything to test it on :)
<ion> Hehe
<dandel> ion, if your talking about fglrx 8.76.7, it works just fine on ubuntu 10.04
<ion> maverick
<Sarvatt> RAOF: SWEET, I'm on it now
<tseliot> ion: no, there's no fgrlx for maverick yet
<Sarvatt> RAOF: any opinions regarding dri-experimental shipping gallium drivers with the same name as dri? should I just set up diversions for now?
<Sarvatt> radeong got renamed to r300 screwing up my ddx patch to allow both installed side by side, could rename it as part of the build and go that route but it seems a dead end and other gallium drivers like the intel ones and swrast still wont work that way
<Sarvatt> r300 is the only extra one i'd like to throw in -experimental really though so maybe we should do that still. I can't decide whats more evil, patching a ddx to allow loading a different dri driver name or adding a diversion
<Sarvatt> anyone have any opinions on that? :)
<Sarvatt> http://www.mail-archive.com/xorg-devel@lists.x.org/msg09741.html -- said ddx patch
<tjaalton> I'm for the simplest approach; ship the gallium version as r300_dri
<tseliot> Sarvatt: I like your patch better, even though it can add maintenance burden. Oh and did I mention the fact that I hate diversions ;) ?
<tjaalton> it's experimental anyway
<tjaalton> package, driver less so I hear ;)
<jcristau> just decide whether you want to ship r300c or r300g
<tjaalton> i think it should be decided for nutty anyway
<tjaalton> hmm, or what was it called again
<tjaalton> ah, well nutty feels about right here ;)
<Sarvatt> its too late to do r300g as the main one and many people will complain about losing accelerated 3D in UMS but r300g is the better of the two, ugh
<Sarvatt> yeah I like nutty too :)
<Dr_Jakob> Sarvatt: you could ship both and have the X driver return different names depending if you have UMS or KMS.
<jcristau> Dr_Jakob: i suspect ums is getting uninteresting quite fast
<Sarvatt> Dr_Jakob: my patch does that
<Sarvatt> it only allows gallium in the dri2 path
<Sarvatt> i just didn't make gallium the default in that one
<Dr_Jakob> ah ok
<Dr_Jakob> never mind then...
<dandel> I'm proposing a few package changes, however, i need some help from an nvidia guy who has OpenCL support working on their system.
<jg> Sarvatt, my bug exists in jbarnes' latest git.  Oh well...
<Sarvatt> ok everything seems to be working (egl/gles/vg/etc), time to go over http://sarvatt.com/downloads/filelist_mesa_7.9.txt to make sure everything is right
<Sarvatt> jg: dang, sorry man :( jbarnes mentioned even the windows drivers are having all kinds of eDP bugs yesterday
<jg> Sarvatt: yeah, well I can finally build at test for jbarnes, when he has a spare moment.  And it was known to work at one point, so we can see the register state in working vs. non-working.
<jg> unfortunately, that kernel won't resume properly, but at least the machine is no longer an expensive paperweight.
<Sarvatt> I guess r300c is the way to go in maverick, i'll just fork the packaging for xorg-edgers again and make r300g the only option :)
<Sarvatt> anyone know if there is something special that needs to be done to use the egl _screen versions of the mesa demos?
<Sarvatt> the _x11 ones work fine
<Sarvatt> osmesa demos don't build, a bunch of talloc undefined references
<Sarvatt> uploaded a preliminary mesa 7.9 here - https://edge.launchpad.net/~sarvatt/+archive/mesa
<Sarvatt> and holy crap mesa builds fast with DEB_BUILD_OPTIONS='parallel=24', 4 minutes! :D
<Sarvatt> this needs some serious review by the arm people to see if there are any problems
<Sarvatt> hopefully there's a mesa RC soon to rebase this onto
<tseliot> Sarvatt: do you have 23 cores???
<Sarvatt> the machine i'm building on has 24 yeah
<tseliot> then I think you could have done DEB_BUILD_OPTIONS="parallel=25"? (I think it's nr. of cores +1)
<jcristau> depends.
<tseliot> on what?
<tseliot> (I'm curious)
<Sarvatt> 12 of those are hyperthreaded, 24 is probably overkill :)
<jcristau> tseliot: at some point you're io bound anyway
<Sarvatt> its got a real slow disk too
<tseliot> yes, I see what you mean
<bilalakhtar> I would like to report a problem. Whenever I boot maverick with all updates, the GDM login comes. If I press any key from now on, X shuts down instantly and starts again in a second or two. This happens only once. After the second start, it behaves properly. Is this fine?
<jcristau> no
<bilalakhtar> s/Is this fine?/Is anyone else facing this problem/g
<bilalakhtar> jcristau: ^^
<jcristau> no idea about that one.
<Sarvatt> jg: looks like someone else has to use 2.6.35-rc6 on your same laptop too - http://blog.mydream.com.hk/howto/ubuntu-10-10-maverick-with-hp-elitebook-2540p
<jg> Sarvatt: I just filed a proper bug report at: https://bugs.freedesktop.org/show_bug.cgi?id=29821
<ubot4> Freedesktop bug 29821 in DRM/Intel "eDP screen "flashes" on and off after boot." [Critical,New]
<tjaalton> i've got a hp blade with 12 cores hyperthreaded to 24 "cores" _and_ fast disks. I'll test some insane builds on it before it's put into production :)
<tjaalton> oh and 96GB memory
<tjaalton> could just build it in a ramdisk
<Sarvatt> hmm libdrm-nouveau1 seems to be holding back a lucid -> maverick release upgrade - http://pastebin.com/6hQKa08c
<Sarvatt> tjaalton: sweet! this just has 512mb memory and 10gb of virtualized disk space :)
 * Sarvatt loathes OpenVZ
<tjaalton> http://pastebin.com/CHCufLTN
<tjaalton> the packaging phase is single-threaded, so it took 5m46s in total
<ion> Whatâs that top-like software?
<tjaalton> htop
<ion> thanks
<ion> Dâoh. I already have installed it in the past, but completely forgotten about it.
<Sarvatt> htop ftw!
<Sarvatt> tjaalton: whats the speed on those xeons?
<tjaalton> Sarvatt: 2.67GHz
<tjaalton> time debian/rules build took 2m3s
<Sarvatt> yeah thats like twice as fast, the 4 minutes wasn't packaging
<tjaalton> heh, ok
<Sarvatt> ok I dropped the Breaks: xserver-xorg-video-nouveau (<< 1:0.0.16) from libdrm-nouveau1 in maverick's package, versioned it higher than what's in maverick's archive and now I can dist upgrade from lucid to maverick, can anyone think of any other way to fix that? :)
<cnd> jcristau, are you about?
<jcristau> cnd: sort of
<cnd> I see that you're the author of config/udev.c in xserver
<cnd> I wanted to know your thoughts on how best to resolve an issue I'm having
<cnd> do you have the time to chat about it?
<jcristau> yep?
<cnd> so I want to be able to use an InputClass to match just the Apple Magic Trackpad
<cnd> unfortunately, the apple bluetooth input products rename themselves after being configured by a user in os x
<cnd> so my trackpad now says it's product name is "cndougla's trackpad"
<jcristau> ugh
<tjaalton> :D
<Sarvatt> fun!
<jcristau> does apple ever do anything right?
<cnd> unfortunately, I don't see any great way to fix this
<cnd> but I also see bugs in the udev code
<jcristau> can we match on product id instead of name?
<cnd> for example, even on usb devices, the wrong udev node is checked for the usb id
<cnd> the parent node should be checked it seems, but the event* node is checked
<cnd> so usb devices don't even get usb_id set properly anymore
<cnd> on top of that, the usb device ids listed for bluetooth devices is the device ids of the bluetooth receiver
<cnd> not the actual device
<cnd> the only way to get the actual device id is to parse the modalias
<cnd> jcristau, so, I'm wondering if you have any good ideas of how we should deal with this :)
<Sarvatt> can you tag it in udev and MatchTag?
<cnd> Sarvatt, you could, but tags are limited
<cnd> tags are meant to say what class of device it is
<cnd> and if we start using bits for individual devices, we'll run out quickly :)
<cnd> apple already does this renaming for at least three devices I have
<jcristau> we don't have the device id in the udev db except in the modalias?
<cnd> jcristau, correct, for bluetooth devices
<jcristau> fun..
<cnd> I think for all bluetooth devices, but I only have my apple gear
<cnd> I'm willing to write a patch for the udev parsing
<cnd> I just want to make sure you can't think of any better way
<jcristau> not really, this sounds ugly
<cnd> for example, maybe it's better to define a udev rule for bluetooth devices to parse the modalias for the device id instea
<cnd> d
<jcristau> might want to talk to #udev or linux-hotplug@vger
<cnd> yeah, I'll ask
<cnd> jcristau, my current thinking is to have a bluetooth udev rule parse the modalias and then set the product and vendor ids from the data
<cnd> but xserver will still need a patch to look for the usb ids on the parent node instead of the device node
<cnd> so just fyi that I'll be looking into this
<jcristau> ok
<cnd> jcristau, I think it may be possible to get the id a different way
<cnd> I'm not terribly familiar with udev
<cnd> it's not obvious how to get all the data out of udevadm :)
<jcristau> udevadm info --export-db should have most of it
<cnd> jcristau, I don't see any attrs though
<cnd> that's where I get confused
<cnd> there's attrs, and then there's properties
<cnd> what's the difference?
<Sarvatt> oh hmm, got a reply saying something might be able to be done to work around the libdrm Breaks: screwing up dist-upgrade in update-manager. that'd certainly be better than dropping the breaks
<mvo> Sarvatt: bug #614993 you mean?
<ubot4> Launchpad bug 614993 in update-manager (Ubuntu) (and 1 other project) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: Holding Back xserver-xorg-video-nouveau rather than change xorg-video-abi-8.0 (affects: 7) (dups: 5) (heat: 58)" [High,Confirmed] https://launchpad.net/bugs/614993
<Sarvatt> yeah
<mvo> Sarvatt: IIRC a conflict helped (instead of the break) when I looked with that problem, the resolver is sometimes a bit dumb
<Sarvatt> i couldn't work out an easy way to test that, i did try it but couldn't get update-manager to let me do a release upgrade without patching/rebuilding x-x-v-nouveau 0.0.16 too
<Sarvatt> since the conflicts left things in a broken state
<mvo> Sarvatt: I played with it by patching /var/lib/apt/lists/archive.ubuntu.com*maverick*main*Packages and let apt go wild on it, but of course that is rather hackish
<mvo> Sarvatt: I can have a look again tomorrow, today I'm a bit too tired for anything complicated
<Sarvatt> removing the breaks: was a bad idea, it ended up deciding to hold x-x-v-nouveau back to 0.0.15 which held back all of x from upgrading until i did a sudo apt-get install xserver-xorg-video-nouveau/maverick :)
<Daekdroom> RAOF, just noticed from MaverickChanges that you fixed it. Thank you :)
#ubuntu-x 2010-08-27
<RAOF> Sarvatt: It's past FF; we'll just ship r300c and not do r300g at all.
<RAOF> Sarvatt: Also, git commit 6a154a5208613ec is incorrect - those symbols that got dropped from libOpenVG were public; we need to re-expose them (they got dropped in the mapi move).
<RAOF> Let the crazy mesa building begin!
<bryceh> :-)
<bryceh> I hope my reply to hugh's email wasn't too pushy
<RAOF> I don't recall it being pushy at all?
<bryceh> ok good, I just hadn't seen a reply
<bryceh> perhaps it's just that I'm thinking too far down the line for it to be relevant
<RAOF> I'm not exactly thinking hard about UDS at this point, no :)
<RAOF> How many times do we _really_ need to build mesa? :/
<RAOF> Wait.  Is mesa building i965_dri.so for OSMesa32?
<RAOF> I wish I wish I wish mesa didn't take forever to build :/
<tseliot> RAOF: the new mesa?
<jcristau> every mesa ever.
<tseliot> yes, I know, I was just curious to know whether we were getting the new mesa or now
<tseliot> *not
<tseliot> it's still better than rebuilding a kernel...
<RAOF> tseliot: Yeah, the new mesa.
<RAOF> Oh, dear lord it still hasn't finished.
<tseliot> nice
<tseliot> we may get unity to work with radeon
<tseliot> (it did with an old snapshot of mesa)
<RAOF> Yeah, that's one of the motivations.
<tjaalton> sounds like you're not parallelizing the build
<RAOF> Yeah, I'm not.
<RAOF> I should work out why the last parallelised build didn't work properly.
<tjaalton> it made a difference?
<jcristau> isn't "because mesa's build system" good enough? :/
<RAOF> To the build time?  Dunno, I didn't count.  To the build CPU usage?  Yes.  Did the result work properly?  No.
<RAOF> It takes quite a while to lzma compress ~100Mb of binaries
<tjaalton> yep
<RAOF> Now, is egl working this timeâ¦
<chrisccoulson> RAOF, shouldn't you be asleep now?
<RAOF> Not at 8:30 pm
<chrisccoulson> oh, i thought you were further ahead than that ;)
<jcristau> only in the other half of the year
<RAOF> chrisccoulson: Shouldn't you still be in bed?  It's surely still the morning for you :)
<RAOF> :P
<chrisccoulson> lol
<chrisccoulson> i actually got to bed early last night - 1am!
<RAOF> Sweet!
<tjaalton> but... friday :)
<RAOF> ARGH.  Why is libEGL looking in /usr/local/lib/egl?
<Sarvatt> RAOF: hmm yeah, I'm not sure what's up with vgu symbols being dropped from libOpenVG
<Sarvatt> looking into it, I mean vgu.h and vgu.c are still there. according to khronos VGU is supposed to be shipped in another lib, libOpenVGU
<Dr_Jakob> Sarvatt: really? Can you point to where it says so?
<Sarvatt> one sec, trying to dig it up again, here's the nokia page though - http://library.forum.nokia.com/index.jsp?topic=/Nokia_Symbian3_Developers_Library/GUID-7EFBEEAD-3E74-5165-B305-313F7DE4BEB4.html
<Sarvatt> it doesn't say anything in openvg-1.1.pdf from khronos about separate libraries, hmm
<Dr_Jakob> hmm...
<Dr_Jakob> I can ask on the OpenVG working group.
<Sarvatt> ok the sample implementation on the khronos website is all in libOpenVG but apparently there are a bunch of things actually using it expecting the separate libOpenVGU that the proprietary implementations ship..
<Dr_Jakob> Ugh...
 * Sarvatt kicks self for not using tests/quick.tests in piglit that time
<Sarvatt> vish: regarding unity, can you try the mesa in this PPA? https://edge.launchpad.net/~sarvatt/+archive/mesa
<vish> ooh! yay!
<vish> Sarvatt: will try that in a bit :)
<Sarvatt> thanks :)
<vish> np..
<Sarvatt> tormod says its fixed but I believe he's using r300g not r300c that we'll ship :(
<Sarvatt> RAOF: swrast is looking good - http://sarvatt.com/downloads/mesa-swrast/
<penguin42> anyone else seeing a ~30second boot pause just after loading the Radeon driver?
<jcristau> missing firmware?
<penguin42> jcristau: Hmm - but X+3d seems to be working
<jcristau> k.
<penguin42> jcristau: Actually, looking more closely - I get a burst of drm/radeon messages and it loads the microcode, does some other stuff and then the hang is after drm] Initialized radeon 2.5.0 20080528 for 0000:07:00.0 on minor 0
<vish> Sarvatt: hi, nope dint help , all i get is a blank white screen.  one change i see is that unity does not keep reloading , which might be due to changes in unity that mikkel mentioned
<vish> xsession-errore > http://paste.ubuntu.com/484542/
<vish> errors*
<vish> Sarvatt: any other debugging you might need?
<ohmy> rebonsoit
<Sarvatt> heh nouveau is not a happy camper in mesa 7.9, dont think any piglit test has passed yet :) going to compare it to 7.8.2 after this is done
<Sarvatt> oh darn, it just warned on all of these because of the unknown PIPE_CAP's on nouveau - http://sarvatt.com/downloads/piglit/nouveau/
#ubuntu-x 2010-08-28
<knittl> how can i help troubleshoot display errors with sleep/resume?
<knittl> hmmmm. (EE) open /dev/fb0: No such file or directory
<knittl> this is interesting?
<knittl> everybody asleep? :>
<knittl> also: [drm] failed to open device
<knittl> (shortly before)
<kklimonda> !weekend | knittl 
<ubot4> knittl: It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<knittl> kklimonda: oh ok. i didn't see it that way
#ubuntu-x 2010-08-29
<bjsnider> Sarvatt, new nvidia driver, with the following fix: Added support for xorg-server video driver ABI version 8, which will be included in the xorg-server-1.9 series of releases.
<bjsnider> http://www.nvnews.net/vbulletin/showthread.php?p=2309077
<RAOF> vish: Does unity load if you add CLUTTER_VBLANK=none to the environment?
<vish> RAOF: hi, i'v been trying from the live dailies, i tried that once but dint work..  should i try with Sarvatt's ppa?
<RAOF> vish: Yeah.  The live dailies don't have mesa 7.9; there are still some problems with the packgaing, and some regressions I need to deal with.
<vish> RAOF: so i just need to add it to /etc/environment and restart session?
<RAOF> I think that should work.
<vish> ok , /me tries again.. :)
<RAOF> I do it by starting a regular desktop session and running unity manually.
<vish> RAOF: you add it to the ~/.profile? or the enviroment?
<RAOF> I start unity with âCLUTTER_VBLANK=none unityâ in a terminal.
<vish> ah!
<ari-tczew> do developers plan fix nvidia issue? bug 616023
<ubot4> Launchpad bug 616023 in nvidia-graphics-drivers (Ubuntu Maverick) (and 1 other project) "nVidia card : X won't start since 1.9 update, no screens found (affects: 81) (dups: 3) (heat: 434)" [High,Triaged] https://launchpad.net/bugs/616023
<jcristau> ari-tczew: it's something only nvidia can fix
<jcristau> afaict
<ari-tczew> jcristau: assigned to tseliot
<Sarvatt> speaking of, 256.52 is out with xserver 1.9 support
<Sarvatt> oh should have read the scrollback, bjsnider already mentioned it :) it's in x-updates at any rate
<ari-tczew> Sarvatt: I'll install 256.52 and I'll give feedback whether it works
<Sarvatt> bjsnider: if you need a quick patch for backporting maverick+ nvidia-current to lucid - http://sarvatt.com/downloads/patches/nvidia-graphics-drivers-lucid-backport.patch
<Sarvatt> jcristau: you're hitting that annoying  problem where dist upgrading is bringing in fglrx/nvidia too in debian now? i can't for the life of me figure it out, dropping the breaks: for the last ABI from xorg-server is the only thing I can find that fixes it
<jcristau> Sarvatt: removing lenny from my sources.list fixed it
<Sarvatt> i need to get a machine in that state again and try replacing the breaks with a conflicts
<jcristau> Sarvatt: it's totally weird
<Sarvatt> oh? hmm
<jcristau> i had to downgrade a machine from squeeze to lenny to test a stable update, and when upgrading back apt decided to pull in random crap
<jcristau> and now intel is giving me grief
<bjsnider> Sarvatt, to lucid? you backport the drivers to lucid, not me. i stop at karmic
<Sarvatt> bjsnider: oh, why don't ya copy the ones out of x-updates into your PPA then? I remember you saying people were complaining about that
<Sarvatt> darn, intel's ddx isn't split up as much as radeon's. was thinking it'd be easy to make Shadow default to on on 8xx generation but all of the options are handled in src/intel_driver.c
<jcristau> shouldn't be too hard.
<jcristau> there's an IS_I8XX macro ;)
<bjsnider> Sarvatt, i tell them to go to the x-updates ppa, because i don't want to have drivers spread out all over the place. they do what i tell them to do
<ari-tczew> Sarvatt: Your package works fine - nvidia
#ubuntu-x 2011-08-22
<RAOF> Aug 22 17:59:50 Faye kernel: [  299.663018] [Hardware Error]: Machine check events logged.  Woo!
<RAOF> That's why she's called Faye :)
<Sarvatt> RAOF: every sandybridge system i've seen does that in 3.0+, and that one was named asuka before you named it faye :)
<jcristau> i think #831336 should be reassigned somewhere that's not xterm
<jcristau> like unity or something
<bryceh> jcristau, did you look at GdmLog2.txt?
<bryceh> *** glibc detected *** /usr/bin/Xorg: free(): corrupted unsorted chunks: 0x0000000002b844c0 ***
<bryceh> however I can't tell that he was actually using gdm at the time of the crash rather than lightdm
<jcristau> bryceh: ah, no, didn't see that one, i only looked at the most recent logs
<bryceh> that was the only one I could find with an actual error
<jcristau> i assumed the error, if any, would be in .xsession-errors
<jcristau> which isn't in there i think
<bryceh> nope; for xterm I should have that be automatically gathered
<jcristau> it's more likely to have private data than the other logs i guess
<bryceh> true
<Dink> I was looking through xserver-xorg bugs and not sure if what I am experiencing is related to some "fixed" bugs #778490, #774978, #740785,#775705. When I start FF6 everything crashed and goes back to gdm login.  Currently xserver-xorg-input-synaptics version 1.3.99+git20110116.0e27ce3a-0ubuntu12.1
<Dink> FF6 works fine when I run ubuntu in safe mode
<Dink> This is 64bit natty running in vm
<Dink> All I can get is
<Dink> connect(4, {sa_family=AF_INET, sin_port=htons(6000),sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECO
<Dink> NNREFUSED (Connection refused)
<bryceh> Dink, collect a full backtrace (see http://wiki.ubuntu.com/X/Backtracing for details)
<Dink> bryceh: I tried but before I could type backtrace while FF6 was running it killed X
<bryceh> Dink, heh, do it from console or ssh
<Dink> hmm so open up ff6 via gui while on a ssh/console session then try gdb ?
<Dink> still not sure ff6 will stay open log enough but will try 
<bryceh> Dink, no you need to run X within gdb.  See the url I gave you for directions how.
<Dink> cool got it
<Dink> Where do you want it ?
<bryceh> Dink, in a bug report
<Dink> (gdb) backtrace full
<Dink> #0  0x00007f201f835335 in PrlCtlUpdateGLXSize ()
<Dink>    from /usr/lib/xorg/modules/drivers/prlvideo_drv.so
<Dink> Is that the stuff that should be outputted ?
<RAOF> Yeah, that's the sort of thing which should be outputted.  What's prlvideo? :)
<bryceh> RAOF, sounds like a driver we don't support ;-)
<Dink> Parallels 
<RAOF> bryceh: It does indeed, yes :)
<Dink> I am running this in Parallels 
<bryceh> virtualized thingee
<bryceh> Dink, ok you need to file a bug with Parallels
<RAOF> Dink: So, it seems likely that the Parallels X driver has a bug; Firefox is generally excellent at triggering such things.
<Dink> bryceh: ok thanks will do. 
<bryceh> sometimes with these virtualized video drivers, they need to rebuild their drivers to match what we're shipping in ubuntu
<Dink> RAOF: thanks for the info. 
<bryceh> I don't know if that's what's happening here, but that's the most common issue we see with these drivers
<bryceh> e.g. GLXSize makes me wonder if they need to update the prl driver to support mesa 7.11 which RAOF just put in relatively recently
<bryceh> RAOF, heya
<RAOF> bryceh: Good morning / evening :)
<RAOF> Hm.  Or maybe afternoon?
<bryceh> RAOF, speaking of drivers we don't support,  I wanted to get your thoughts on bug #815000
<bryceh> yep 3pm; High Naptime
<bryceh> RAOF, I'm thinking we should bump that over to the kernel, but do you think there's anything we would/could/should do on the X end?  
<bryceh> ick... in more troubling news, looks like xvfb broke again... https://bugs.launchpad.net/~doko/+reportedbugs (bug #829470)
<RAOF> I think you're right, and that should be a kernel bug.  I'm pretty sure there should be a KMS poulsbo driver, but it doesn't seem to be loading.
<bryceh> alright, I'll bump it
<RAOF> Hm.  Which of doko's bugs are you referring to?
<bryceh> 829470
<bryceh> but I'd bet most of those are outcomes of broken xvfb
<bryceh> so far not able to repro on my hw
<RAOF> I'll see if it does here.
<bryceh> xvfb in general seems not to fail (launching xterm or whatever).  Going to try the build test in pygtk next
<bryceh> RAOF, do you remember when we talked about maybe adding xvfb to the xorg-server build scripts, to catch these types of issues ourselves?  Know if that idea went anywhere?
<RAOF> Yeah.  It has not yet gone anywhere.
<bryceh> Xlib:  extension "RANDR" missing on display ":99".
<bryceh> hmm perhaps that's innocuous
<RAOF> xvfb does not support RANDR, and I'm fairly sure that GTK no longer blows up if it's running on a server which does not support RANDR.
<bryceh> yeah running the test locally I'm noticing the fatal error is actually  TypeError: Unsupported type: <class 'gtk._gtk.WindowType'>
<RAOF> So this doesn't seem to be an xvfb bug, but rather a failing test that's not reported well.
<bryceh> yeah
<bryceh> probably some gnome3 transition problem.
<RAOF> Yeah, may well be.
<bryceh> RAOF, we're still getting a lot of those false gpu hang bugs; thankfully real gpu hangs seem to be extremely rare
<bryceh> on one of my upstream reports someone said they see it on ubuntu but not mandriva (or whatever that distro is called these days).
<bryceh> RAOF, otoh apw seems not sure what else to look at on our end.  we're running short on ideas
<RAOF> bryceh: As in: we're running out of bugs for the kernel team to fix?!
<RAOF> Oh, or that the GPU lockup doesn't seem to occur on Mandriva, and they're running the same kernel?
<bryceh> right
<bryceh> however as it's (usually) a symptomless-hang, you'd not notice it on a non-Ubuntu system unless you were specifically looking for it in dmesg
<RAOF> Hah.  Right.
<RAOF> I presume apw has got the testers to try an upstream / drm-intel-next kernel?
<bryceh> we've done that before, although not recently (if there's a particular fix you're thinking of)
<bryceh> when he'd investigated before, he felt it wasn't the kernel code that was bad but rather an issue with how the drivers were being loaded
<bryceh> ickle says the bug itself is an invalid memory issue, which makes me wonder if it's some sort of race condition during driver initialization
<bryceh> then by the time the driver has faulted and reset, the memory is kosher (or gets re-initted)
<bryceh> I'm also wondering if it has to do with something done during the great bootspeed optimization campaign
<bryceh> unfortunately the gpu hang tools didn't really capture this properly until well after that work was done, so hard to correlate to that
<bryceh> of course, I can't reproduce it on any of my machines
<bryceh> such is the curse of being an X maintainer ;-)
<bryceh> I've been trying to look for commonalities between different reporters, like if they have specific proprietary kernel modules loaded, or similar hardware or something.  But from the recently reported bugs there's quite a bit of variance from person to person
<RAOF> Is it the same GPU at least?
<bryceh> current reports are against i915, 1945, 1965
<bryceh> I don't see it on my i945
<bryceh> s/l/i/g
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.tag=oneiric+-kubuntu+-xubuntu+-ppc+-omit&field.tags_combinator=ALL
<RAOF> Well, that's a nice wide range at least. :)
<bryceh> even the arrandale chris van hoof gave me doesn't show it; and it's positively thick with bugs at the moment
<bryceh> #830276 looks like a false gpu hang but appears to actually hang
<bryceh> alright, enough bug work for the day... food, then xdiagnose.  bbiab
<Sarvatt> IPEHR: 0x7xxxxxxx have always been mesa problems if i'm remembering right, IPEHR: 0x018xxxxx were always hangs during dpms cycles
<bryceh> Sarvatt, ooh good to know; would that happen to be documented anywhere that you know?
<Sarvatt> nope just trends i noticed going through hundreds of bugs, we get a rash of 0x018xxxxx dpms bugs right after release every single release since lucid
<Sarvatt> well its documented in the gpu docs
<RAOF> As in the register specifications?
<Sarvatt> yeah, why am I not finding it again..
<RAOF> This might be good to be documented on a wiki page?
<bryceh> yep
#ubuntu-x 2011-08-23
<bryceh> tacked it onto the end of https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
<bryceh> looking at the oneiric gpu lockups, they seem to follow this trend
<bryceh> wonder what 0x6xxxxxxx signifies
<RAOF> bryceh, Sarvatt: Hm.  Andy's just enabled the vmwgfx kernel module in the latest kernel upload.  What do you think about turning on the associated mesa stuff?
<bryceh> hrm
<bryceh> how stable do we think it is?
<RAOF> I have no idea.  Sarvatt, you've played with it, haven't you?
<bryceh> something we could put into -experimental ?  (or do we still have that package?)
<RAOF> We do still have that package; it's got classic r300 and r600 drivers, and i915g.  Oh, and llvmpipe.
<bryceh> might not be a bad idea to stage it there for a bit just in case.
<RAOF> Yeah.
<bryceh> but I don't have strong feelings one way or the other
<RAOF> We'd also have it build an xserver-xorg-video-vmware-ish package; it uses the xorg state tracker from gallium.
<bjsnider> RAOF, still awake and whatnot?
<RAOF> bjsnider: Yeah, 'course.
<RAOF> (It's almost midday ;))
<bjsnider> question about gallium
<bjsnider> uh, ok
<bjsnider> it's night
<RAOF> What's the question?
<bjsnider> anyway, if a state tracker is added to gallium, does a driver, nouveau for instance, have to do anything to add support for that tracker or is it automatic?
<RAOF> I'm not entirely sure.  I think the answer is somewhere in the range from "no, it's automatic" to "yes, but only very minimal hookup assuming the driver supports the appropriate gallium interfaces".
<bjsnider> i thought, in reading the original documentation, that the answer was "definitely no"
<bjsnider> so if an opengl 4.xx state tracker is added all gallium drivers would immediately support it
<RAOF> I think that's not necessarily going to be the case; I'm not sure if the existing gallium interfaces can express all of GL 4.x.
<bjsnider> well, in that case, it's not going to be an issue for about 40 years
<bjsnider> but even if it's a small state tracker that accelerates text off the gpu or something
<RAOF> Or, rather, I'm pretty sure that some of GL 4.x, particularly geometry shaders, requires driver support that doesn't currently exist.
<RAOF> I think my thinking might be slightly reversed; state trackers need to know something of the pipe drivers, but pipe drivers don't necessarily need to know about state trackers.
<RAOF> So the gallium EGL tracker just has all the pipe drivers built in; it used to have code to select which pipe driver to dlopen, etc.
<bjsnider> you mean as new drivers are added, the state trackers have to be modified to take that into account?
<RAOF> Yes.
<RAOF> Or, at least, the *targets* do.  If you wrote a new pipe driver capable of accelerating GLES, gallium's egl_gallium.so wouldn't use it until you'd updated some stuff.
<bjsnider> well, either way it's a fair amount of work
<RAOF> I don't think that's the case; I think it's a fairly small amount of work.  Once you've got the state tracker or pipe driver, of course.
<bjsnider> but would that be thousands of lines of code or just a few dozen?
<RAOF> I guess I could look at historical precedent - getting the xorg state tracker to work with nouveau, or ati.
<RAOF> IIRC those were done in few commits of not much code.
<bryceh> hmm, weird, why does ubuntu-bug xkb-data work but ubuntu-bug xkeyboard-config doesn't?
<RAOF> bryceh: Because xkeyboard-config isn't a binary package?
<bryceh> it must be
<bryceh> my understanding of apport hook naming must be off
<bryceh> hmm, no, seems my understanding is right, it's just not working like it's supposed to
<bryceh> if you have a hook named 'source_foo.py' as opposed to just 'foo.py' it's supposed to include all binary packages produced by foo
<bryceh> ahh, but it doesn't support filing against the source package name itself!
<bryceh> which is weird.
<RAOF> Time for pittiping!
<bryceh> indeed; going to dig through some python code a bit first
<bryceh> (aha found it)
<bryceh> ehh wonkiness
<bjsnider> that's the advantage of being a motu. when you find a bug in something you can just infiltrate the code and correct it.
<bryceh> s/a motu/open source/ ;-)
<bryceh> in this case, I don't have commit access to apport's bzr tree anyway, so still have to get the patch approved by pitti, so don't matter that I'm motu
<bryceh> >>> cache = apt.Cache()
<bryceh> >>> cache['xkb-data']
<bryceh> <Package: name:'xkb-data' architecture='i386' id:1126L>
<bryceh> >>> cache['xkeyboard-config']
<bryceh> Traceback (most recent call last):
<bryceh>   File "<stdin>", line 1, in <module>
<bryceh>   File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 177, in __getitem__
<bryceh>     raise KeyError('The cache has no package named %r' % key)
<bryceh> KeyError: "The cache has no package named 'xkeyboard-config'"
<bryceh> unfortunately... dunno how to look up source packages via apt.Cache()
<bjsnider> i could look through the code but not correct the problem
<bjsnider> well, i suppose there's a chance i could correct it
<bjsnider> a borken clock is right twice a day
<bryceh> fwiw, found the issue already reported as bug #359810.  Posted my fix there
<tjaalton> hmm, would be nice to have a one-off debugging script to trigger via the kernel cmdline, and which would save the critical logs for later use
<tjaalton> for instance when KMS doesn't work
<jibel> I get bug 831884 with today's desktop ISOs on 2 intel systems. 
<jibel> X fails to start on Live CD on intel: [drm] failed to set drm interface version
<tjaalton> hum, where's ubotu
<tjaalton> jibel: which package did you file it against?
<jibel> tjaalton, xserver-xorg-video-intel http://pad.lv/831884
<tjaalton> jibel: not seen that one before
<tjaalton> jibel: from which machine did you file the bug?
<tjaalton> since it's intel too and running oneiric
<jibel> tjaalton, I generated the report from the ASUSTeK Computer INC. 1015PE with N10 graphics card
<jibel> tjaalton, but I get the exact same problem on a Dell N4010 with an Arrandale booting from USB.
<jibel> https://bugs.launchpad.net/bugs/585853 looks similar.
<jibel> that would confirm a problem with lightdm
<tjaalton> jibel: yeah, so it's a race condition between plymouth and lightdm..
<jibel> tjaalton, yup, I'll ask the desktop team. I'll close the intel task once we narrowed it down. thanks for looking into it.
<seb128> stop the blame it on lightdm game ;-)
#ubuntu-x 2011-08-24
<tjaalton> RAOF: I suppose we want xserver 1.10.4 for oneiric?
<tjaalton> still at 1.10.2.902
<RAOF> tjaalton: Yup.
<RAOF> It's one of my TODOs, but don't let that stop you from doing it :)
<tjaalton> heh, ok. I'll probably merge it then
<tjaalton> we need to upstream patch 503, unless it's in master
<tjaalton> uh no, patch 504
<RAOF> Which one's 504?
<tjaalton> the wacom-jumping-to-0,0
<tjaalton> fix for that
<RAOF> Ah, that one.
<RAOF> Didn't Chase already send that upstream?
<tjaalton> not sure it's upstream yet, I ran off for my vacation when it was done
<tjaalton> well couldn't find it on the list, but that doesn't prove anything :)
<RAOF> Or is it part of the neverending-stream-of-multitouch?
<tjaalton> hum, could be, actually
<tjaalton> yeah, rings a bell now
<RAOF> Because it wasn't an issue on an upstream Xserver.
<tjaalton> right
<tjaalton> and that's why it's numbered as 5xx
<tjaalton> duh
<RAOF> :)
<rodrigo_> hi
<rodrigo_> I have 2 computers connected to a monitor, and only on my oneiric box, the monitor loses the signal randomly, and so displays nothing
<rodrigo_> xorg or kernel driver?
<tjaalton> depends on the driver
<tjaalton> um
<bryceh> rodrigo_, if a KMS driver, then kernel
<tjaalton> the hw and then the driver :)
<rodrigo_> it's the nvidia driver
<tjaalton> well, it's the same blob then
<rodrigo_> so, anything I can do to fix it?
<tjaalton> file a bug and assign to tseliot :)
<bryceh> no, do a bit more experimentation first
<bryceh> "loses signal randomly" is so generic as to be worthless as a bug report ;-)
<rodrigo_> yeah, what log files should I look at?
<bryceh> characterize the problem.  Eliminate the other computer from the equation.  Identify if it's a regression and if so, when did it start.  Experiment with ways to reproduce it.  Change out monitor and/or video card.
<rodrigo_> .xsession-errors doesn't seem to contain anything
<rodrigo_> ok
<bryceh> dmesg or /var/log/Xorg.0.log
<bryceh> however for this type of problem they almost never have anythingn useful
<bryceh> there's also a nvidia configuration tool; dunno if it has any settings of use but at least make a pass through it and test anything that looks worthwhile
<rodrigo_> ok
<bryceh> _then_ file a bug itemizing your findings, and assign to tseliot, and he can approach NVIDIA about it
<tjaalton> well if the other machine is on nvidia too then it's a regression in the driver
<tjaalton> if not, then all bets are off
<bryceh> guess could be a fault in the kvm or whatever he's using to connect the monitor
<bryceh> not-enough-info ;-)
<rodrigo_> hmm, nvidia-settings shows the temperature of the GPU, 80+ÂºC, is that ok, isn't it too hot?
<rodrigo_> the other computer doesn't use nvidia driver
<bryceh> rodrigo_, sounds like item #1 for your research journal ;-)
<rodrigo_> :)
<bryceh> (no, I don't think it's too hot, but worth study; an overheated gpu can cause power downs)
<rodrigo_> hmm, it's happened in the last few days, when temperatures are quite high here, might be this indeed
<tseliot> rodrigo_: something similar always happens to me (no matter what graphics card I use) and I have to press the scan button of my monitor to get my 2nd pc screen back
<bryceh> heya tseliot! :-)
<tseliot> rodrigo_: can you try with nouveau and see if you can reproduce the issue?
<tseliot> hi bryceh
<mgariepy> Hello, i updated the bug lp:#785280 concerning the transparency problem with intel driver and remote Xorg server, someone have identified the first problematic commit. Can someone take a look at this ?
<tseliot> Sarvatt: I think what mgariepy reported affects sandybridge
<Prf_Jakob> So on 11.10 alpha how do I stop the framebuffer console so I can reload my driver? "echo 0 | sudo dd of=/sys/class/vtconsole/vtcon[0-1]/bind" doesn't seem to work
<Prf_Jakob> driver here being the kms kernel driver.
<RAOF> Prf_Jakob: Hm.  I've never managed to get that to work myself, but I've not tried terribly hard; a reboot is fast enough to make it not worth the hassle for me.
<Prf_Jakob> Works like a charm on 11.04 for me, so I'm a bit suprised to see it go away.
<Prf_Jakob> (at least with vmwgfx).
<Prf_Jakob> While you are here, who is responsible for the DRI udev rules?
<RAOF> To which udev rules are you referring?
<RAOF> Do you mean /lib/udev/rules.d/78-graphics-card.rules ?
<RAOF> Which sets up PRIMARY_DEVICE_FOR_DISPLAY, or something else?
<Prf_Jakob> The ones that sets up permissions on the nodes.
<Prf_Jakob> /dev/dri/card0 and the rest
<Prf_Jakob> The standalone driver we have doesn't register the nodes as "drm" class but instead they get the class of "vmwgfx", so we need to install our own rules to get the correct permissions on the nodes.
<Prf_Jakob> Currently I just hacked to to 0666 which isn't particular secure.
<RAOF> Two places - 50-default-udev.rules sets the "video" group on everything in the drm class, and 70-udev-acl.rules sets up the "console user gets ACL" bits, again for drm class.
<RAOF> They're both in the udev package.
<Prf_Jakob> ok thanks I'll take a look
<RAOF> So, either register the nodes as "drm", throw in a new udev rule, or file a bug against udev asking for vmwgfx to be handled like that.
<RAOF> Since that's in the upstream kernel, I'd guess that the ultimately-correct option would be either register-as-drm, or for those standard udev rules to be updated for vmwgfx.
<Prf_Jakob> I don't think we can register them as drm because they get the class name from the module name (and we have baked in a copy of drm into the standalone repo).
<Prf_Jakob> Okay, forgot to clarify, this is not a problem for the upstream driver. Only the standalone one we have on the side.
<RAOF> Ah.
<Prf_Jakob> Which is drm+ttm+vmwgfx in a seperate repository.
<Prf_Jakob> We had to support a rather wide range of kernels, it was just easier to a standalone version.
<RAOF> Then ship a udev rule with it; the relevant magic is SUBSYSTEM=="drm", KERNEL=="card*", TAG+="udev-acl" for the ConsoleKit integration, and SUBSYSTEM=="drm",		GROUP="video" for the (legacy) video grouping.
<Prf_Jakob> Ah thanks!
<Prf_Jakob> For how long as that been the case?
<Prf_Jakob> I know the old rules we got worked around 9.10 ish.
<RAOF> I think the video group stuff has been possible forever; I'm less sure of the udev-acl.
<Prf_Jakob> Yeah I don't recognize that.
<RAOF> Oh, and the rule with the udev-acl tag needs to be executed before the 70-udev-acl.rules rule, which means install at 69 or below.
<Prf_Jakob> ok
<RAOF> I think udev-acl has been around for at least a couple of releases.
<Prf_Jakob> right
#ubuntu-x 2011-08-25
<RAOF> bjsnider: You were asking about how state trackers and drivers interact?  The recent patches to hook r600g up to the xorg state tracker would be a good example ;)
<bjsnider> sounds like a page turner
<bryceh> ahahaha, figured out that xvfb bug
<RAOF> bryceh: Oooh, what's that?
<bryceh> RAOF, after a lot of digging through xvfb code, it ended up being a bug in fakeroot instead
<bryceh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630591
<ubot4> Debian bug 630591 in apt "apt: apt-cache fails with current fakeroot" [Minor,Fixed]
<RAOF> Awesome :)
<bryceh> 829470 has the analysis
<RAOF> Would you believe that (a) compiz is super slow running under valgrind and (b) leaks like a sieve?
<RAOF> Which is a bit annoying, 'cause I was hoping that it'd be more obvious where (probably mesa is) leaking gem_objects
<bryceh> ugh, firefox is substituting some sort of graphic for "ff"
<bryceh> RAOF, I would indeed believe that
<RAOF> ==27498== ERROR SUMMARY: 4941712 errors from 2347 contexts (suppressed: 867727 from 65)
<RAOF> Almost as many errors as I have bytes in gem_objects!
<RAOF> :)
<bryceh> yay!
<bryceh> RAOF still around?
<bryceh> I think we could maybe test Xvfb in xserver's debian/rules, but xvfb-run depends on xauth being available so I'm not sure if we can invoke that.
<RAOF> bryceh: Now post-lunch, yeah.
<RAOF> We could, I guess, build-depend on xauth?
<bryceh> RAOF, yeah that's what I'm wondering
<bryceh> I've been experimenting with just calling Xvfb directly, but utilizing xvfb-run would give a better test
<RAOF> There doesn't seem to be any circular dependency issue there; it just depends on libx11 and friends.
<bryceh> ok lemme give it a go
<tjaalton> i merged 1.10.4 yesterday, might want to pull that too
<tjaalton> at least before you try to push ;)
<bryceh> tjaalton, yeah saw that in git
<tjaalton> ah, cool
<tjaalton> i've done a procmail rule to put the git commits in a separate folder. easier to follow when no debian-x bugmail is there to distract you :)
<bryceh> aha got it
<RAOF> Oh, man.  apitrace is pretty awesome.
<bryceh> RAOF, ok you can cross xvfb off your todo list :-)
<RAOF> Sweet.
<RAOF> What intel hardware do you have trivially available?
<bryceh> I've pushed it to the git tree, you can roll it out when you do the 1.10.4 deploy.  Hopefully it shouldn't require any tweaking; if it does let me know.
<bryceh> RAOF, an i945 running natty and an arrandale running oneiric but failing to run X for some reason
<RAOF> I guess I'm particularly interested in arrandale, actually; it doesn't seem like this leak appears on GM45, so I presume gen 4 and earlier are ok, and it appears on this SandyBridge, so it looks like gen 6 is affected, leaving only gen 5 :)
<RAOF> I'll just test that hypothesis again, though.
<tjaalton> I have oneiric on sandybridge
<tjaalton> so compiz leaking memory?
<RAOF> tjaalton: Yeah; on alt-tab.
<tjaalton> ah that, well it ceases to work after some time
<RAOF> Ceases to work?
<tjaalton> don't have the popup anymore, though I use the more sane traditional one :)
<RAOF> Ah.
<RAOF> Yeah, it's the unity alt-tab that's got problems for me.
<tjaalton> windows do change though
<tjaalton> here compiz is taking 860MB atm
<tjaalton> which is kinda lot
<RAOF> And by "problems" I mean "leaks ~25MB per alt-tab, leading to fairly rapid OOM"
<tjaalton> heh, ok
<tjaalton> compiz is also constantly taking at least 30% cpu
<RAOF> Oooh, interesting.
<RAOF> The trace of alt-tab madness has the same behaviour on my GM45, but I don't see that just running compiz.
<tjaalton> apitrace would probably need to be packaged, no?
<RAOF> I've got a Debian ITP up.  It does really want to be packaged, yes.
<tjaalton> ah, good
<RAOF> It doesn't quite work properly on compiz, but it works enough.
<RAOF> tjaalton: Could you switch to Unity's alt-tab and check that it doesn't leak gem_objects for you?
<tjaalton> RAOF: yeah
<tjaalton> i mean, yeah I can do that :)
<RAOF> :)
<RAOF> while true; do echo "********************************"; sudo egrep "[[:digit:]]+ objects" /sys/kernel/debug/dri/0/i915_gem_objects ; sleep 5 ; done
<RAOF> Quite useful.
<tjaalton> hum, the default alt-tab does the same
<tjaalton> i mean stock compiz version
<tjaalton> had 3720 objects, now after a few it's up to 3773
<tjaalton> and the popup does appear, after holding alt down for a few secs
<RAOF> The stock compiz version has a known leak, but it's much smaller.
<tjaalton> ah ok
<tjaalton> RAOF: I can't seem to reproduce the leak on a sandybridge laptop
<RAOF> tjaalton: Strange.  DBO's just fixed it in trunk, though.
<RAOF> At least, for me.
<tjaalton> the first alt-tab increases the number of gem_objects, but another one doesn't
<RAOF> I generally did about 40 alt-tabs; that raised the bytes used by a lot.
<RAOF> (About 1GB or so)
<tseliot> is this still the case?
<RAOF> With the unity in Oneiric, yes.  With the unity in trunk, no.
<tseliot> and they're going to upload the fix, aren't they?
<tjaalton> sigh, yet another thunderbird beta and all plugins incompatible
 * RAOF is still soldiering on with Evolution
<tjaalton> and addresbook just as broken as with version 6
<RAOF> tseliot: I'm not sure if they're going to upload the fix before beta freeze; DBO's gone to bed because it's insane-o-clock where he is.
<tjaalton> "welcome to shredder", you don't say!
<tjaalton> (the codename of tb 7beta)
<tseliot> RAOF: it's ok, as long as they'll upload before the release ;)
<tseliot> s/'ll//
<tseliot> upload it
<RAOF> tseliot: I think it's a fair bet there'll be at least one unity upload between here and release :)
<tseliot> what's wrong with me today?
<tseliot> RAOF: and not leaking memory doesn't sound like a feature to me :)
<RAOF> tseliot: Thanks for following up on that nvidia corruption-after-suspend bug.
<tseliot> RAOF: np. Now that they've confirmed that disabling grub's fb doesn't help, I can bug Nvidia to death ;)
<alkisg> Hi, 1 out of 10 times, after suspend/resume, I'm getting the following errors, and I have to restart X:
<alkisg> dmesg: [ 9626.944239] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
<alkisg> Xorg.0.log: (EE) intel(0): Failed to set tiling on front buffer: Input/output error
<alkisg> Complete dmesg: http://paste.ubuntu.com/674409/  Complete Xorg.0.log: http://paste.ubuntu.com/674410/
<alkisg> Under which package should I report this? xserver-xorg-video-intel? Against the kernel?
<tjaalton> alkisg: .38 is fail, intel-wise. try a newer kernel
<jcristau> and if your gpu hangs, you want to capture the error state
<alkisg> Ah, thank you tjaalton - that also happens with .32 and .35, but I'll try the kernel ppa
<bryceh>  /sys/kernel/debug/dri/0/i915_error_state
<jcristau> yeah, that.
<alkisg> Got it, thanks a lot guys
<bryceh> if you can reproduce against the current 3.0 kernel, upstream will be interested
<alkisg> Sure, as long as I can get that to my lucid box... /me searches the kernel ppa...
<alkisg> https://launchpad.net/~kernel-ppa/+archive/ppa ==>                 linux-lts-backport-oneiric               , as easy as it gets :)
<tjaalton> lucid??
<alkisg> Yeah sorry... I'm an LTS guy
<tjaalton> a ton of backports then
<bryceh> tjaalton, might be better off backporting the entire kernel rather than bits and bobs
<alkisg> Ouch, hmm... I might just stop using suspend then, and install oneiric to another partition just for the bug report
<tjaalton> bryceh: yeah it was running .38 already, not just drm backported
<tjaalton> alkisg: you probably have libdrm, -intel and mesa already backported?
<bryceh> alkisg, that probably would be a bit easier
<tjaalton> the livecd should work as well
<alkisg> tjaalton: I think no, I think I'm using the version from lucid-updates
<alkisg> Thanks, livecd is probably what best suits me
<tjaalton> actually
<tjaalton> somehow I thought you had sandybridge, so no heavy backporting necessary
 * alkisg is all ears...
<alkisg> Just libdrm, intel and mesa?
<tjaalton> but if you can reproduce it with oneiric, all the better
<alkisg> Sure I don't think it'll take me more than half  an hour
<alkisg> dmesg, xorg.log, and error state - anything else?
<tjaalton> i guess that'll do
 * alkisg will also read https://wiki.ubuntu.com/X/Reporting 
<tjaalton> well, you can use apport-cli -p xorg
<bryceh> alkisg, if you've booting oneiric, there is a apport-gpu-error-intel.py udev hook which *should* automatically capture gpu hangs and collect all the required data automatically
<alkisg> Perfect, thanks again guys
<bryceh> heh, Michael Larabel found my wayland-demos package
<tjaalton> so it seems
<tseliot> :)
<ricotz> might be a dump question, but why isnt libegl1-mesa-dev depending on mesa-common-dev?
<ricotz> RAOF, hi ^
<tjaalton> should it?
<ricotz> libgl1-mesa-dev depends on it
<ricotz> so it would guess so
<ricotz> but i might not too little about it
<ricotz> s/not/know
<tjaalton> well, if there are no headers importing the ones in mesa-common-dev then I don't see why it should depend on it
<ricotz> ok, so if an application depends on libegl...-dev it should pull in mesa-common-dev by itself to use them
<tjaalton> if it uses the headers provided by mesa-common-dev, yes
<ricotz> i was just thinking that it is more convinient if mesa does this 
<ricotz> that is reasonable, of course
<tjaalton> compiz fails to run with swrastg complaining that tfp is missing, though at least glxinfo says it's there
<tjaalton> meh
<tseliot> tjaalton: is compiz supposed to work with swrastg?
<tjaalton> tseliot: so I'm told, that at least gnome-shell worked with it on fedora 15
<tjaalton> could be that it's llvm failing somehow, since it feels as if it's timing out
<tseliot> ah, with llvm
<tjaalton> swrastG :)
<tseliot> right, I didn't notice the g
<Prf_Jakob> Hmm I need to install two udev rules if I want the PRIMARY_DISPLAY_THINGY to work correctly.
<bryceh> alright, new xdiagnose 1.1 uploaded; keep an eye out for any issues in apport bug reports...  I've been testing it and seems to be working solid, but I did a good bit of refactoring so bugs are certainly possible
<RAOF> Prf_Jakob: The PRIMARY_DISPLAY thing is a boot-time optimisation; you can safely ignore it if you don't mind until udev has finished probing everything before starting X.
<Prf_Jakob> ok
#ubuntu-x 2011-08-26
<cnd> bryceh: RAOF: thought you might be interested to know that pbuilder create now works for me on oneiric
<bryceh> cnd, excellent
 * bryceh sighs @ bug #834136 and bug #834070
<ubot4> Launchpad bug 834136 in xserver-xorg-video-dummy (Ubuntu) "Depends on a package that doesn't exists (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/834136
<ubot4> Launchpad bug 834070 in xserver-xorg-video-intel (Ubuntu) "Daily builds oneiric-desktop-amd64.iso since 08/17/11 are useless (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/834070
<Sarvatt> i've run into the daily builds not starting lightdm too
<Sarvatt> works fine after a sudo service lightdm start
<Sarvatt> oh but filed against intel, clearly the right place
<Sarvatt> well thats fun, can't change the package its filed against on launchpad in chromium dailies
<bryceh> hmm, setting dupes seems busted too
<bryceh> https://bugs.launchpad.net/launchpad/+bug/834266
<ubot4> Launchpad bug 834266 in launchpad ""831884 is not a valid bug number or nickname" (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> RAOF: vmwgfx in 7.11 was busted, it looked exactly like the screenshot in this bug https://bugs.freedesktop.org/show_bug.cgi?id=40397 and according to that bug xorg-vmwgfx is deprecated anyway. would be really nice to get it in 12.04 though when we have 7.12
<ubot4> Freedesktop bug 40397 in Other "vmwgfx 3D Glitchy" [Normal,New]
<Sarvatt> (no xa-vmwgfx in 7.11)
<Sarvatt> having it installed made a standard boot with autologin unusable since unity thought it could work with it - http://sarvatt.com/downloads/vmwgfx1.png
<Sarvatt> not sure how Amaranth has it working
<Amaranth> Sarvatt: I just grabbed whatever was in xorg-edgers when I set it up and the kernel module for the latest kernel
<Amaranth> Sarvatt: I disabled 2D acceleration and debug, only 3D is enabled
<Sarvatt> ah it musta broke when i tried it last week
<Sarvatt> everything 3D related died with an assert
<Sarvatt> (in 7.12 that is)
<Amaranth> http://paste.ubuntu.com/675528/
<Amaranth> Sarvatt: and here is es2_info and glxinfo: http://paste.ubuntu.com/675530/
<Amaranth> no idea what build I did that with
<Sarvatt> i need to start adding the git hash to the gl version string
<Sarvatt> oh wait you built it yourself outside of git anyway
<Sarvatt> i'll start building st/xa next mesa upload so i can upload vmwgfx_branch of xf86-video-vmware which needs xatracker.pc from mesa
<Prf_Jakob> Oh I see you are talking about vmwgfx
<Prf_Jakob> 3D should work fine with XA on 32bit, 64bit seems a bit broken, haven't had time to look into it.
<Prf_Jakob> st/xorg should also work fine, but now you don't get the nasty circular dependancy.
<bryceh> Sarvatt, ideas on bug 835128?  (Friend of slangasek's)
<ubot4> Launchpad bug 835128 in linux (Ubuntu) "Blank display on Vaio Z (VPCZ2) unless I use nomodeset or attach an external monitor (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/835128
#ubuntu-x 2011-08-27
<Sarvatt> cnd: am I going to break the world if I upload xserver 1.11 to edgers without 500_xi_2.1.patch enabled?
<cnd> Sarvatt: nope, I'd encourage it :)
#ubuntu-x 2011-08-28
 * penguin42 is trying to debug a virt-manager problem where one of the dialogs doesn't appear for me - but to my surprise it is showing up in xwininfo -root -tree and at +708+349 which seems sane; why would something show up on xwininfo but not be visible? 
<penguin42> answer; because it's not mapped....
<Rovanion> How do I compile libgbm-dev from git? I need it to compile mesa from git, which fails missing gbm.h
<bryceh> Rovanion, wrong channel
<Rovanion> bryceh: Which is the right channel?
<Rovanion> I was told in #ubuntu-devel to ask here..
<bryceh> one of the freedesktop or xorg channels would be more appropriate
<Rovanion> But do you know how to do this? I would very much appreciate an answer if you do
<bryceh> Rovanion, http://dri.freedesktop.org/wiki/Building
<bryceh> you might find it easier to use xorg-edgers; I don't know if it's mesa package is up to the version you need to test, but it'd be a lot simpler than building it yourself
<bryceh> l8r
<Rovanion> bryceh: Thank you!
<Sarvatt> Rovanion: gbm.h comes from mesa, did they mess up the build system again similar to https://bugs.freedesktop.org/show_bug.cgi?id=40145 or are you using an older git checkout?
<ubot4> Freedesktop bug 40145 in Other "gbm.h header not found when building egldisplay.c" [Normal,Resolved: fixed]
<Sarvatt> if its the former try #dri-devel or file a bug against mesa (with the build log) on bugs.freedesktop.org, if its the latter they fixed it with http://cgit.freedesktop.org/mesa/mesa/commit/?id=61d2dfbe488cf5de5881c20fe1ead97f2ab5dabb
<Rovanion> Sarvatt: I've gotten an answer on the Wayland-devel mailing list. He said that he solved it locally on his side by forcing the include path. I'm trying to figure out how to do that myself.
<Rovanion> Sarvatt: But yes, I'm on git pulled today. So it's probably a recent build system messup.
<Rovanion> I made it work by removing the if-statement around the part of the Makefile that included gbm
<Rovanion> Will make a bugreport as it seems to be working now
<Rovanion> https://bugs.freedesktop.org/show_bug.cgi?id=40443
<ubot4> Freedesktop bug 40443 in General "gbm.h not included when it should be." [Normal,New]
<Azelphur> Anyone have any idea what's causing this? http://paste.ubuntu.com/676882/ line 435 and onwards is where it gets interesting
<RAOF> Azelphur: Looks like your gpu has locked up.
<RAOF> Azelphur: dmesg will probably have something more, but it's highly likely to be an nvidia driver problem.
<Azelphur> yea, I figured it'd either be driver or hardware
<Azelphur> dmesg didn't mention anything, :(
<Azelphur> It likes to freeze every now and again, sometimes it'll stop for a few seconds then come back, sometimes it'll stay stuck.
#ubuntu-x 2012-08-20
<mlankhorst> morning
<RAOF> Howdie.
<mlankhorst> still talking to danvet, before I really woke up this time, not a good idea :)
<mlankhorst> but the alternatives are worse, heatwave here :/
<mlankhorst> Anything i can work on that doesn't require much logical thought today?
<mlankhorst> oh right, could look at vdpau blobs again :)
<tjaalton> oh duh, libglsl.so is merged into libdricore.so..
<mlankhorst> :>
<tjaalton> hmm, debian hasn't installed it
<mlankhorst> tjaalton: oh hey we're again a intel version behind
<tjaalton> yup
<mlankhorst> git merge debian-experimental seems to be enough
<mlankhorst> I guess jcristau beat us this time :)
<jcristau> haven't tested at all
<tjaalton> we can do that for you :)
<tjaalton> or the quantal test puppies can
<jcristau> i wanted to remove /etc/modprobe.d/i915-kms.conf in this version
<jcristau> since it's not needed post wheezy
<mlankhorst> hm does that mean sync to debian again?
<tjaalton> nah the apport hook is the only dif
<tjaalton> f
<tjaalton> after that change
<tjaalton> but close
<jcristau> i'm going to need some maintainer scripts love to get the conffile removed properly
<tjaalton> those are always icky..
<mlankhorst> yeah
<jcristau> it's written, just not tested yet :)
<mlankhorst> blegh I need some work that's not dma-buf related for a change :)
<mlankhorst> anything i could work on for a while?
<tjaalton> well..
<tjaalton> there's the crasher on precise due to synaptics upgrade in -updates
<tjaalton> so figuring out why going to 1.6.2 triggered it would be cool
<tjaalton> or is the server missing something
<mlankhorst> likely server related sadly
<mlankhorst> and i don't have the faintest clue what is differing between x1.12 and 1.11 in ubuntu
<mlankhorst> tjaalton: it's not a problem in quantal right?
<tjaalton> mlankhorst: some dupes of 956071 at least have been reported on quantal
<tjaalton> bug 956071
<ubottu> Launchpad bug 956071 in xserver-xorg-input-synaptics (Ubuntu) "Xorg crashed with SIGSEGV in XIGetDeviceProperty()" [High,Confirmed] https://launchpad.net/bugs/956071
<tjaalton> there's also a similar bug on debian
<tjaalton> and upstream
<tjaalton> well, forwarded upstream by the same guy
<mlankhorst> quantal added on 2012-07-18, did we already have the x1.12 stack then? *looks*
<tjaalton> there's one filed 7h ago
<mlankhorst> aw looks that way, ok I'll take a look
<mlankhorst> tjaalton: I think I might have seen that bug when I was playing with valgrind :)
<tjaalton> oh good
<mlankhorst> or at least some bug during synaptics probing, but it was a weird one and didn't make much sense, maybe it will show up again under more paranoid settings
<tjaalton> suspend/resume testing should reveal that before too long
<tjaalton> also, it can crash seconds after typing the password, which is kinda late in the resume cycle..
<mlankhorst> yeah I get some weird erorr during a log output
<mlankhorst> which didn't make sense
<mlankhorst> I'll just increase the tracking that valgrind does
<tjaalton> the sigsafe logging patches should be in 1.13 though..
<tjaalton> if that's related
<mlankhorst> valgrind worked fine without on x1.11
<tjaalton> k
<tjaalton> -synaptics was probably the old version too
<mlankhorst> but I'll update quantal first :)
<seb128> tseliot, tjaalton, mlankhorst, RAOF_: hey, what's the status on nvidia binary drivers on quantal then? did the driver update work?
<mlankhorst> seb128: from ubuntu-devel, it is updated to document it's not compatible, unless there has beeen an update since :)
<seb128> do we have an ETA on compatible driver?
 * mlankhorst doesn't know nvidia's plans
<tjaalton> no eta
<tjaalton> "next release"
<seb128> :-(
<mlankhorst> but at least it's not fglrx
<tseliot> seb128: the update doesn't work therefore I simply made sure that the driver conflicts with the new X abi
<seb128> well, ati works fine so fglrx is less of an issue
<seb128> nouveau is suboptimal still though :-(
<mlankhorst> sadly
<seb128> tseliot, ok, thanks
<mlankhorst> maintainer has spent a lot of time turning every line of code upside down..
<mlankhorst> hopefully we'll start seeing fixes again soon
<tseliot> :)
<mlankhorst> (there's even some lines of code that haven't changed \o/)
<tjaalton> single-threaded mesa build on top of a nfs share via wifi is.. surprisingly slow :)
<mlankhorst> no what's surprisingly slow is apt-get install over nfs on a gigabet network with a ssd backing..
<mlankhorst> gigabit*
<mlankhorst> what you described is unsurprisingly slow :)
<tjaalton> hehe
<tjaalton> yeah
<tjaalton> preseeded netboot install over gigabit is like 15min here
<tjaalton> full desktop
<mlankhorst> I just use debootstra plocally
<mlankhorst> usually for apt-get updates in chroot too
<tjaalton> oh well, I know the build passes, now it's just finding the right files for dh_install
<mlankhorst> brb
<mlankhorst> tjaalton: oh great.. same bug as another one I was hitting
<mlankhorst> updatetouchstate overflows
<mlankhorst> cnd: ^ seems to happen on quantal 1.13rc4 too
<tjaalton> mlankhorst: woo, thanks
<mlankhorst> well I fear it could be a dup of the other synaptics bug then
<tjaalton> hmm libdricore is now versioned
<tjaalton> libdricore8.1.0.so.1.0.0
<mlankhorst> great..
<tjaalton> probably no point in splitting it from libgl1-mesa-dri though
<mlankhorst> true just leave it in :)
<tjaalton> wha.. the gallium dri's are huge, over 41MB apiece
<mlankhorst> debug symbols enabled?
<mlankhorst> tjaalton: oh btw https://bugs.launchpad.net/oem-priority/+bug/956071/comments/59
<ubottu> Launchpad bug 956071 in xserver-xorg-input-synaptics (Ubuntu) "Xorg crashed with SIGSEGV in XIGetDeviceProperty()" [High,Confirmed]
<mlankhorst> the crasher backtrace i hadnt seen before
<tjaalton> ahh
<tjaalton> right, the binaries haven't been stripped yet, oops
<tjaalton> no libgallium.so then, the patch would need to be reworked
<phillw> Hi folks, could some one please advise as to against what this bug should be reported...http://pastebin.com/SRLnr5fB
<tjaalton> the kernel
<phillw> tjaalton: thanks!
<tjaalton> although
<tjaalton> what does "get live session working" mean
<tjaalton> ?
<phillw> it means that the tester has to insert nomode to get it to run?
<phillw> In my distinctly amateur opinion I'd suspect nvidia-graphics-drivers since it could well be fallout from the new X stack. 
<tjaalton> no
<tjaalton> you don't have that on a live-cd
<Sarvatt> tjaalton: --with-llvm-shared-libs saves a bunch of space but needs the patch on https://bugs.freedesktop.org/show_bug.cgi?id=52167 still
<ubottu> Freedesktop bug 52167 in Mesa core "llvmpipe test programs link fails when ld --as-needed option is used" [Normal,New]
<tjaalton> Sarvatt: i'll whine again after seeing what they look like after dh_strip :)
<phillw> okies, so it is a kernel regression?
<tjaalton> phillw: not necessarily
<tjaalton> is there a boot splash? does X start but hang later?
<phillw> I'm surmising from the tester that he needs to alter the boot sequence to get X to actually run. Once he knows where to file the bug, he will be able to give more information. He's an experienced tester, just unsure as to what to report this one against.
<tjaalton> ubuntu-bug xorg
<phillw> thanks.
<tjaalton> that's a good place to start..
<phillw> it can always be re-assigned later.
 * mlankhorst recovers from brain thermal cutout
<mlankhorst> bryceh: you added 217_revert_bgnonevisitwindow.patch, is it still needed?
<mlankhorst> similar to some other patches, for example some old workarounds in xorg-server should probably be upstreamed or dropped entirely..
<tjaalton> yes, there was a task about it but it got marked as done, though I think we should be more aggressive about them..
<mlankhorst> agreed
<mlankhorst> i dropped a 0->null change now, since it really doesn't add anything to keep it
<mlankhorst> RAOF_: ping?
<tjaalton> head hurts trying to fix 116_use_shared_galliumcore.diff
<tjaalton> got to give up for now
<mlankhorst> next person to make a cd can fix it? :p
<tjaalton> mlankhorst: hehe, exactly. or maybe RAOF_ :)
<mlankhorst> brr, fighting ttm is no fun :(
<mlankhorst> screw it, most common case will be re-using local reservation object anyhow *does ugly hack*
<tjaalton> btw, virtualbox is broken with the new server :)
<tjaalton> reportedly
<mlankhorst> sigh :s
<jcristau> when is vbox not broken
<tjaalton> whemn it's not installed i guess..
<bryceh> mlankhorst, 217_revert_bgnonevisitwindow.patch is not actually enabled, it was dropped a year ago because it was included in 1.11.0.  But looks like raof left the patch itself in place for some reason
<mlankhorst> hm suppose we ought to get rid of all the patches not in series to clean up confusion then :)
<bryceh> definitely
 * mlankhorst just created a very scary patch
<mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip makes reservations sort of global, scared to test if it boots..
<tjaalton> wth, "configure: error: --with-driver=dri is deprecated"
<tjaalton> built just fine earlier today
<tjaalton> oh, with --enable-osmesa it fails that way.. nice
<tjaalton> if it's forced
<tjaalton> ahah, --enable-dri
<mlankhorst> tjaalton: yay obsolete packages gone :)
<tjaalton> mlankhorst: they got removed the same time when the stack got copied
<tjaalton> oh bloody osmesa
<tjaalton> doesn't find glapi/glapitable.h
<tjaalton>         -I$(top_srcdir)/src/mapi \
<tjaalton> probably should be top_builddir
<tjaalton> no
<tjaalton> well, needs both :)
<tjaalton> 726f534bbb3f is similar for glx
<tjaalton> ffs, "libdricore*" is not enough to get all the links to be copied to the package dir
<barry> howdy folks.  over in #ubuntu-devel i've been chatting with tjaalton and bryceh about today's big problems with 12.10 in a vmware fusion 4.1 host.  is there a vmware dev here who would like to help me debug the problem?
<barry> bug 1039157
<ubottu> Launchpad bug 1039157 in xorg (Ubuntu) "X problems in Fusion guest" [Undecided,New] https://launchpad.net/bugs/1039157
<bryceh> pst Prf_Jakob ^
<tjaalton> Prf_Jakob: ^ vmware-tools needs some love for newer kernels
<tjaalton> so that it would build :)
<barry> Prf_Jakob: hi.  i'm using 12.10 in fusion 4.1.3 (730298).  i know i'm bleeding edge but perhaps i can help test vmware-tools for 12.10?
<tjaalton> right, helps if you copy from the right directory, *sigh*
<tjaalton> at long last.. mesa debs created, without libgallium.so though
<tjaalton> RAOF_: updated mesa git to build, if libgallium.so is commented out from libgl1-mesa-dri.install.linux.in.. if you have time to look at the patch and what it needs to make it work again, that would be great
<tjaalton> I started but after the trivial bits it was unclear what was needed, since some bits have been automakeified
<tjaalton> like libdricore build
<RAOF_> Yay.
<tjaalton> "have fun" :)
<Sarvatt> "thank you so much" :)
<tjaalton> if you're up for it that is ;)
<Prf_Jakob> tjaalton: ugh seems like a lot of things are broken in 12.10
<Prf_Jakob> tjaalton: have you guys forgotten to enable the vmwgfx kernel module?
<Prf_Jakob> barry: still around
<Prf_Jakob> ?
<barry> Prf_Jakob: yep!
<Prf_Jakob> lsmod | grep vmwgfx ?
<Prf_Jakob> yeah its using the old driver for some reason.
<barry> @resist[~:1001]% lsmod | grep vmwgfx
<barry> @resist[~:1002]% 
<barry>  
<Prf_Jakob> I'm guessing its because vmwgfx isn't loaded.
<barry> Prf_Jakob: yeah, i've tried installing both open-vm-tools and building vmware-tools from the "cd"
<Prf_Jakob> We don't ship vmwgfx kernel driver or X drivers in tools for newer distros.
<Prf_Jakob> cat /boot/config-`uname -r` | grep VMWGFX
<barry> CONFIG_DRM_VMWGFX=m
<barry>  
<Prf_Jakob> okay
<Prf_Jakob> modprobe vmwgfx
<Prf_Jakob> sudo service lightdm restart
<Prf_Jakob> should sudo modprobe as well.
#ubuntu-x 2012-08-21
<barry> yep.  waiting for login screen to come back up
<barry> hmm, black screen
<Prf_Jakob> try to VT switch to a console.
<Prf_Jakob> ctrl+alt+f1
<Prf_Jakob> If you are on linux, ctrl+alt+space ctrl+alt+f1
<barry> i think it's ctrl-fn-command on os x, but nope, it's not switching
<barry> i'm still ssh'd in though
<barry> *ctrl-fn-command-f1
<barry> however:
<barry> % lsmod | grep vmwgfx
<barry> vmwgfx                121226  2 
<barry> ttm                    83595  1 vmwgfx
<barry> drm                   275528  3 vmwgfx,ttm
<barry>  
<Prf_Jakob> sudo service lightdm start
<Prf_Jakob> incase doing it from X killed it.
<barry> yep, just did that again.  i hear bongos, so i do think it's restarting
<Prf_Jakob> Hmm
<Prf_Jakob> Anything interesting in Xorg.0.log?
<barry> not too much, perhaps this:
<barry> [  1104.435] (WW) Warning, couldn't open module modesetting
<barry>  
<Prf_Jakob> Don't think so
<Prf_Jakob> Is 3D enabled?
<Prf_Jakob> on the host?
<Prf_Jakob> Does it say it has 3d in Xorg.0.log
<barry> grep -i 3d /var/log/Xorg.0.log
<barry> [  1104.440] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available.
<barry> [  1104.440] (--) vmware(0): Direct rendering (3D) is disabled.
<barry> [  1104.440] (II) vmware(0): No 3D acceleration. Not setting up textured video.
<barry> i definitely have Accelerate 3D Graphics turned on in settings
<Prf_Jakob> Ok, thats normal if you don't have 3D turned on.
<Prf_Jakob> Oh... hmm.
<Prf_Jakob> What does it say drm?
<barry> % grep -i drm /var/log/Xorg.0.log
<barry> [  1104.412] (II) config/udev: Adding drm device (/dev/dri/card0)
<barry> [  1104.436] (--) vmware(0): DRM driver version is 2.4.0
<barry> [  1104.746] (II) config/udev: Adding drm device (/dev/dri/card0)
<barry>  
<Prf_Jakob> looks okay
<barry> what do you think about adding vmwgfx to /etc/modules and rebooting?
<Prf_Jakob> That might work
<barry> worth a try i guess ;)
<Prf_Jakob> sudo service lightdm stop
<Prf_Jakob> sudo killall Xorg -9
<Prf_Jakob> might work as well
<Prf_Jakob> and then starting it again.
<barry> interesting, no Xorg process found
<barry> let's try a reboot
<barry> % grep -i 3d /var/log/Xorg.0.log
<barry> [     8.737] (II) vmware(0): Gallium3D XA version: 1.0.0.
<barry> [     8.737] (--) vmware(0): Direct rendering (3D) is enabled.
<barry>  
<barry> and yep, the llvm-based corruption seems to be gone, as is the tiny fonts on lightdm
<barry> Prf_Jakob: i have to go eod now.  i've updated bug 1039157 with what i know so far.  if you have any other debugging suggestions, please comment on the bug and we can chat tomorrow.  thanks!
<ubottu> Launchpad bug 1039157 in xserver-xorg-video-vmware (Ubuntu) "X problems in Fusion guest" [Critical,New] https://launchpad.net/bugs/1039157
<Prf_Jakob> barry: ok, thanks
<Sarvatt> i'll try to figure out why its not auto loading tomorrow, from the looks of it with my old logs x-x-v-vmware actually did the modprobing before though and its not now under xserver 1.13
<Prf_Jakob> Yeah, I was thinking about that.
<Sarvatt> would be nice to have it modprobed earlier in the boot though so theres a splash, adding it to /lib/udev/rules.d/78-graphics-card.rules might make that happen
<Sarvatt> oh vmwgfx doesn't have any modaliases
<Sarvatt> thats why its not auto loaded by udev?
<Prf_Jakob> Heh, I don't even know what a modalias is :)
<Sarvatt> modinfo i915 lists the devices it auto loads from udev for, nothing on vmwgfx even though theres 1 pci id
<Prf_Jakob> Ah
<Prf_Jakob> What does the splash use btw?
<Prf_Jakob> libkms, OpenGL?
<Sarvatt> if theres /dev/fb0 it uses that, theres specific backends written for each kms driver, although i think that changed in 12.10 and it uses the newer dumb ioctls. there is a libkms backend for the drm renderer that would work though thats also in 12.04 though
 * Sarvatt passes the heck out, sorry to disappear suddenly :)
<tjaalton> RAOF: busy with the baby?-)
<RAOF> tjaalton: Yeah; Sam's gone out for an appointment, so I'm holding the baby :)
<tjaalton> alrighty
<mlankhorst> RAOF: ping
<RAOF> Pong
<mlankhorst> RAOF: you dropped the core patch and are encouraging -core to be passed, how do you pass that by default?
<RAOF> mlankhorst: In lightdm
<RAOF> mlankhorst: I should see if that's been uploaded, actually.
<tjaalton> RAOF: wondering if the libgallium patch should actually be modified to add the gallium stuff in libdricore, if what you said that's what upstream might take
<mlankhorst> RAOF: yeah but could that be sru'd for precise somehow for next lts stack?
<tjaalton> also, probably no reason to move libdricore out of libdir to libdir/dri
<tjaalton> hmm need to add that to debian
<RAOF> mlankhorst: Hm, possibly
<RAOF> dvorak is poorly optimised for 1 handed typing!
<mlankhorst> use a smartphone :D
<mlankhorst> or a dumbphone with t9
<tjaalton> or get a carrying sling :)
<mlankhorst> or use text to speeds
<mlankhorst> it shoot laugh your ascend!
<RAOF> No irc on my phone :)
<RAOF> I can't find the baby sling, either :(
<tjaalton> nasty name for that thing btw :)
<RAOF> Not for launching babies at all!
<mlankhorst> we never said that
<tjaalton> :)
<mlankhorst> it looks like the stress of parenting is getting to you if you would think we would think about such cruel things
<mlankhorst> do you manage to sleep at nights, even?
<RAOF> Yeah; plenty.
<RAOF> ZoÃ«'s pretty good that way.
<RAOF> ...and xserver uploaded.
<jcristau> upload with one hand?
<tjaalton> git push with the other
<jcristau> where's the baby then? :)
<tjaalton> damn ;)
<RAOF> Up in the air.
<RAOF> You throw her up, type something, and then catch her.
<mlankhorst> RAOF: lucky you, I have to face the wraith of ttm maintainers :)
<mlankhorst> which I guess in a way wouldn't be too unsimilar from a crying baby at night
 * mlankhorst ducks
<RAOF> Heh
<tjaalton> hum, trying to build mesa with --with-llvm-shared-libs, but fails
<tjaalton> g++  -L/usr/lib/llvm-3.1/lib  -lpthread -lffi -ldl -lm  lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM-3.1 -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -ldl -Wl,--end-group
<tjaalton> /usr/bin/ld: ../../auxiliary//libgallium.a(u_dl.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
<oyvind> bjsnider: Latest nvidia-settings 304.37 for amd64 has failed to build in X updates PPA. Looks like the archive was distributed in a slightly unclean state. Removing objects under src/libXNVCtrl/ in advance should fix the build..
<tjaalton> /usr/bin/ld: note: 'dlclose@@GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libdl.so so try adding it to the linker command line
<tjaalton> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libdl.so: could not read symbols: Invalid operation
<tjaalton> oh, and bumping build-deps like llvm isn't nice for backports, I guess
<mlankhorst> your libdl is screwed?
<mlankhorst> either that or you forgot -ldl :)
<jcristau> he has -ldl there twice
<mlankhorst> ah
<jcristau> and ld even says it found dlclose there
<tjaalton> dunno, fedora has a recent snapshot and they use --with-llvm-shared-libs, so wonder why it fails to build here
<mlankhorst> tjaalton: well what if you remove one of those 2 and build it manually?
<tjaalton> mlankhorst: still the same
<mlankhorst> did you remove the first one or the second one?
<tjaalton> tried both
<tjaalton> doesn't the error suggest that something is wrong with libgallium.a?
<mlankhorst> static libraries are weird
<mlankhorst> I think you might need to remove the -Wl,--start-group and -Wl,--end-group and keep the last libdl
<tjaalton> broke even harder :)
<mlankhorst> sigh
<mlankhorst> can you send me what you have?
<tjaalton> git pull
<tjaalton> no wait
<tjaalton> merged master and bumped the version to 9.0~git..
<tjaalton> there
<tjaalton> it was the same error with the previous snapshot
<mlankhorst> blegh needs quantal to build, give me a sec
<tjaalton> yup
<mlankhorst> updating chroot
<mlankhorst> ok i seem to get the same error :)
<tjaalton> good :)
<mlankhorst>  g++  -L/usr/lib/llvm-3.1/lib  -lpthread -lffi -ldl -lm  lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM-3.1 -Wl,--end-group -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -ldl
<mlankhorst> seems to work
<mlankhorst> but I have no idea where the start-group and end-group are inserted..
<tjaalton> src/gallium/Makefile.template
<mlankhorst> it should be just protecting llvmpipe and lgallium, not the rest
<jcristau> isn't that a ld bug?
<mlankhorst> possibly
<mlankhorst> seems Sarvatt had already reported it as https://bugassistant.libreoffice.org/show_bug.cgi?id=49504
<ubottu> bugs.freedesktop.org bug 49504 in Mesa core "[Bisected] Mesa master compilation broke when built with --with-llvm-shared-libs" [Normal,Resolved: duplicate]
<mlankhorst> and duplicate bug had this attached https://bugassistant.libreoffice.org/attachment.cgi?id=65103
<mlankhorst> so maybe just cherry pick that?
<tjaalton> it's not in master
<tjaalton> but if you mean cherry-pick from bugzilla then yes
<mlankhorst> yeah :)
<mlankhorst> sigh, why do I know such things are a problem even before finding the bugzilla entry :s
<tjaalton> ok I'll add that to the debian branch
<tjaalton> and do yet-another merge..
<mlankhorst> :>
<mlankhorst> wish I had something to push to mesa so you'd immediately rebuild again :p
<mlankhorst> I can push to most of X now
<tjaalton> me too, never abused it though
<tjaalton> once had plans to break -sis, but meh
<mlankhorst> the trick is you don't want to see it as 'abuse' :)
<tjaalton> touch something and you're the defacto maintainer
<mlankhorst> hm lets see about virtualbox then
<mlankhorst> yay
<mlankhorst> virtualbox won't even netboot despite advertising it? o.O
<om26er> my screen' dpi is 138 but its always hardcoded to 96 in ubuntu. is there a way I could change that?
<om26er> xrandr --dpi 138/eDP1 seems to have no effect
<mlankhorst> tjaalton: surprisingly, works here..
<tjaalton> mlankhorst: huh, ok
<mlankhorst> virtualbox seems to start fine
<mlankhorst> although compiz is corrupted if i try
<tjaalton> yeah that's the bug then
<tjaalton> but is it general llvmpipe-borkedness or something else..
<mlankhorst> no idea
<tjaalton> check the log :)
<mlankhorst> it's using llvmpipe at least..
<tjaalton> there you go
<tjaalton> so it's fallout from dropping unity2d
<mlankhorst> so.. nothing to worry about then?
<tjaalton> right
<tjaalton> sry :)
<tjaalton> but hey, now you have time to fix the libgallium.so build?-)
<mlankhorst> probably
<mlankhorst> what needs fixing?
<tjaalton> don't know what good --with-llvm-shared-libs brought
<tjaalton> make the patch apply and build the .so
<mlankhorst> oh that
<mlankhorst> you know that would mean the whole llvmpipe patch could be dropped, too
<tjaalton> but it might be easier(?) to merge it in libdricore
<tjaalton> probably so yeah
<tjaalton> wanted to see what it did
<tjaalton> and don't see much
<mlankhorst> will virtualbox be sru'd to precise for .2?
<mlankhorst> since the dkms module will no longer build and the xorg one needs an update
<tjaalton> nah
<tjaalton> vbox users can stay on .1
<tjaalton> i mean the stack on .1
<mlankhorst> :/
<tjaalton> why not?
<tjaalton> it's not like the "hw" needs enabling
<mlankhorst> still leaves the kernel build failure, though
<tjaalton> wait, what?
<mlankhorst> if you enable the 3.5 kernel on precise
<tjaalton> make it conflict
<tjaalton> it's possible today..
<tjaalton> breaking the setup that is
<mlankhorst> yeah, I'll ask leann
<tjaalton> nah, make vbox conflict with the kernels that it doesn't support
<tjaalton> easier
<jcristau> conflicting with kernels is teh suck
<tjaalton> well :)
<mlankhorst> but right i don't care enough today, I'll add a point to backports to think about it later
<tjaalton> or sth
<mlankhorst> yeah
<mlankhorst> ok enough caring for now, I'll look at the gallium patch
<tjaalton> great
<tjaalton> would take more time if I tried :/
<mlankhorst> I kind of want to ask raof about it first, i sort of understand the patch but not the reasoning behind it
<tjaalton> sure
<tjaalton> seems to be having some network issues
<mlankhorst>  seems sort of like since it's using libgallium everywhere anyhow, it could just change libgallium.a to libgallium.so and be done with it
<mlankhorst> tjaalton: seems a variant of it was already merged though
<tjaalton> oh?
<mlankhorst> the patch adds --enable-shared-dricore
<tjaalton> there's the libdricore support upstream yes
<mlankhorst> oh nm it was just from my first partial apply
<tjaalton> :)
<mlankhorst> can the entirety of libgallium.a be built shared?
<tjaalton> no idea :)
 * mlankhorst tries a automake hack
<mlankhorst> well looks a bit harder to make it shared than I thought
<mlankhorst> it's part autotools and part custom makefiles..
<tjaalton> yeah :/
<mlankhorst> ok next attempt
<mlankhorst> more luck now
<tjaalton> how much more? :)
<mlankhorst> oh as in 'almost feeling confident it links libgallium.so correctly'
<tjaalton> cool
<seb128> mlankhorst, hey
<seb128> + [ubuntu-x-swat] Detect gfx hardware changes (maybe by checking the modaliases?) and inform users about the change: TODO
<seb128> mlankhorst, please try to find somebody rather than a team for workitems, team assignments tend to not work, everybody waits on somebody else to pick the stuff up which often never happens :p
<mlankhorst> seb128: yeah unfortunately half of my team went to sleep or didn't wake up yet :)
<seb128> fair enough ;-)
<mlankhorst> tjaalton: I think libtool leads to aggression in a natural way
<mlankhorst> yay.. builds static and shared :)
<debfx> mlankhorst: virtualbox upstream requires contributions to be licensed under the MIT license. if you can agree to that posting the patch and a license statement to vbox-dev@virtualbox.org would be great.
<mlankhorst> debfx: you send it then, copyright belongs to canonical ;)
<debfx> mlankhorst: huh?
<mlankhorst> I mean unless I'm mistaken since I did it as part of my work for canonical, the copyright belongs to canonical, not me personally :)
<mlankhorst> but shrug it should be fine, I'll send it
<mlankhorst> tjaalton: blegh is it really worth it building libgallium shared?
<tjaalton> mlankhorst: ask the ones who try to keep the cd image under 700M :)
<jcristau> those people still exist?
<tjaalton> that said, i'm not sure if we have more to use for quantal
<tjaalton> not sure
<mlankhorst> shrug I think I'm close
<tjaalton> seb128: do you know? ^
<mlankhorst> some linking error in llvmpipe :s
<seb128> tjaalton, mlankhorst: what's the issue?
<tjaalton> is the installer image size still 700M
<mlankhorst> lets see if it's just llvmpipe breaking..
<mlankhorst> woops, probably made all symbols invisible :)
<mlankhorst> *amused* even on his homepage ulrich drepper manages to be ulrich drepper
<mlankhorst> "If you have problems with this page it probably means you are using a junk browser. Especially the one from the monopolist. Get something better. Use Firefox or Mozilla."
<tjaalton> mlankhorst: ok, we have enough space for mesa, so don't worry about the patch anymore. we can fix it later
<tjaalton> stash your changes somewhere :)
<tjaalton> mlankhorst: i promised to upload it later today, mind giving it a go on some machine if you have some to spare? since I don't know what the llvm-shared-libs actually did, testing some gallium based driver would be great
<tjaalton> I have some radeon card to test with
<tjaalton> but can't get to the machine until maybe 3h from now
<Prf_Jakob> barry: ping
<barry> Prf_Jakob: pong
<Prf_Jakob> Ah you are here.
<barry> yep, how's it going?
<Prf_Jakob> fine, haven't done anything more on the bug.
<Prf_Jakob> HAve a interface change for mesa that needs to be done before the stable branch is created.
<barry> Prf_Jakob: np, the workaround is getting me thru.  i was thinking about changing the bug title to "vmwgfx kernel module not getting loaded by default".  would that be helpful?  (if not, i'll leave it as is)
<mlankhorst> tjaalton: ok
<mlankhorst> tjaalton: I can stash it, but it seems to be a pain to get it really working
<jcristau> bah, speaking of mesa my fix still hasn't made it in.
<Prf_Jakob> barry: that is the real issue.
<barry> Prf_Jakob: done
<Prf_Jakob> thanks
<mlankhorst> tjaalton: I can build libgallium.so just fine, it's the linking that's proving to be a pita :)
<mlankhorst> tjaalton: but what do you want me to do, test if it works on a radeon card?
<barry> Prf_Jakob: thanks for looking into this and helping me out!
<Prf_Jakob> np
<mlankhorst> tjaalton: hm, seems to be just swrast failing
<mlankhorst> but I'll put the changes together into something almost coherent
<mlankhorst> ok lets see if those binaries work on quantal :)
<tjaalton> mlankhorst: yeah test the non-libgalliuminized (!) version to see it works, i believe intel is mostly fine
<mlankhorst> inte's easiest to test for me right now :p
<mlankhorst> tjaalton: not getting a desktop, weird
<mlankhorst> oh, old kernel
<mlankhorst> just some kernel panics on 3.5.0-11 I suppose, nothing really wrong :p
<mlankhorst> tjaalton: I have no idea what's wrong with the drivers but glxgears spins fine, so dno..
<mlankhorst> it was broken before too, though
<tjaalton> hmm, quantal works on snb for me
<tjaalton> though the machine has 3.5.0-8
<mlankhorst> tjaalton: yeah but it was broken before too, guessing the ddx was screwy instead
<tjaalton> ok
<tjaalton> uploaded xorg that adds -modesetting to video-all
<mlankhorst> yay \o/
<tjaalton> had it in git for some time..
<mlankhorst> blegh, updating lts-quantal can wait
<Sarvatt> tjaalton: modesetting's in universe :(
<tjaalton> Sarvatt: yes, informed -release that it needs to be moved to main
<tjaalton> ogra_: is it armhf you care about for llvmpipe?
<tjaalton> haha
<tjaalton> mesa *.install.in totally messed up
<tjaalton> hrm, if we're not going to get swx11 back, maybe it would be best to drop the separate 'dri' build target and have sane paths in *.install.in
<mlankhorst> tjaalton: we don't know that yet
<tjaalton> it's useful on s390
<tjaalton> fedora builds it only on that arch
<tjaalton> and nothing else, since it has no gfx hw
<mlankhorst> and for all we know there is some insane reason to keep it
<mlankhorst> if it has no graphics hardware why would you need it? o.o
<tjaalton> fine, I'll mess with the .install files then
<tjaalton> running apps remotely?
<tjaalton> no idea
<mlankhorst> after quantal is released there'll be no objection from me to drop it :)
<tjaalton> it's dropped already
<tjaalton> in git
<mlankhorst> meant the separate dri stuff
<tjaalton> ok
<mlankhorst> but shrug i suppose in worst case you do it now and it turns out we would have to revert that common
<tjaalton> ok correction, fedora builds swrast on s390, no swx11 at all
<mlankhorst> I retract all my objections :)
<tjaalton> right
<tjaalton> I'll take the heat to revert the packaging, it isn't that hard
<tjaalton> if it should happen
<tjaalton> or maybe I'm just a coward and fix the install files instead
<mlankhorst> hey for stable releases it's good to be a coward :)
<tjaalton> argh
<jcristau> tjaalton: i'd prefer to keep swx11.
<jcristau> it's still useful if you don't have glx
<jcristau> that's for debian, you can do what you like in U :)
<mlankhorst> in that case no point in changing the directory off
<tjaalton> yeah I kept it there, it should build again soon
<tjaalton> either I change the directory, or edit all install.in to copy the stuff from dri/.. to ..
<tjaalton> dunno which makes more sens
<tjaalton> e
<mlankhorst> whatever gives the smallest delta with debian
<tjaalton> ok it's easier to revert the install.in
<tjaalton> than to retest big changes to rules
<mlankhorst> :-)
 * mlankhorst always favors the lazy approach
<tjaalton> jcristau: what about the libosmesa build? I ripped those targets, but the downside is that the static libs are gone
<jcristau> dunno
<mlankhorst> tjaalton: libosmesa is still built right?
<tjaalton> mlankhorst: yes, but during the dri target build
<mlankhorst> ah good :)
<tjaalton> and since you can only build either static or dynamic libs, the static ones are now "lost"
<tjaalton> same thing with libglut
<tjaalton> libglu, whatever
<mlankhorst> yeah, just have no idea what libosmesa does, just know wine can use it :p
<tjaalton> E: libgl1-mesa-dri: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/dri/i915_dri.so /mnt/src/git.d.o/lib/mesa/build/dri/src/mesa/libdricore/.libs
<tjaalton> wth
<mlankhorst> shared dricore probably
<tjaalton> oh well, needs fixing then
<tjaalton> less lintian errors anyway
<mlankhorst> yeah usually the autotools relink before install
<tjaalton> getting there
<mlankhorst> but those specific ones don't autotool
<tjaalton> need a break.. ->
<ogra_> tjaalton, yeah, dont bother with armel
<tjaalton> mesa-8.0-llvmpipe-shmget.patch on fedora. probably worth checking out at some point
#ubuntu-x 2012-08-22
<RAOF> BAH!
<RAOF> Stupid mesa stupid egl damn broken implementations bah.
<tjaalton> what's up?-)
<mlankhorst> RAOF: oh hey what was the idea behind the shared gallium patch?
<tjaalton> no more rpath issues btw, slangasek fixed it
<tjaalton> problem was installing the drivers from the build-tree
<mlankhorst> ah ofc
<tjaalton> so getting close..
<tjaalton> unity works on intel, ship it
<mlankhorst> :D
<RAOF> tjaalton: EGL is broken on !intel because of wayland changes.
<RAOF> And I was playing around with some prototype EGL code.
<RAOF> And wondering why it wasn't working...
<tjaalton> ah
<mlankhorst> :D
<RAOF> mlankhorst: The shared gallium patch was basically the same as libdricore - take all the static archives in src/gallium and make a shared library out of them, rather than including them in all the gallium drivers.
<mlankhorst> oh so I was moving in the right direction then
<mlankhorst> I just get troubles at the linking phase now
<RAOF> Yeah, it was pretty frustrating.
<mlankhorst> have you seen the preliminary patch I created?
<RAOF> Ultimately upstream would like to have a monolithic everything_dri.so, as I understand it. That would be a bigger change, but easier to maintain I think.
<RAOF> mlankhorst: No, I didn't - is it on the list, or in git?
<mlankhorst> git
<tjaalton> oh everything_dri.so..
<mlankhorst> it fails to link swrast
<tjaalton> i wonder what good did llvm-shared-libs bring
<RAOF> tjaalton: Not adding ~20MiB of llvm to each and every gallium driver?
<tjaalton> ah, ok then
<mlankhorst> Cave johnson here, let me tell you something, when I buy a hard disk, I want to use it. None of this sissy dynamic link everything. I paid for the best and I want the best!
<tjaalton> hmm that's what we used to have before too, no?
<tjaalton> just not it has to be enabled separately?
<tjaalton> *now
<RAOF> Yeah, we used to patch that in.
<tjaalton> heh, ok
<tjaalton> that's good then
<tjaalton> the drivers are still huge
<tjaalton> radeonsi_dri.so is 35M
<RAOF> Yeah, that's without libgallium, right?
<tjaalton> all the gallium ones are 27-35M
<tjaalton> yep
<tjaalton> sounds about right?
<RAOF> libgallium factors out ~25 MiB of that.
<tjaalton> ok
<mlankhorst> 25?
<mlankhorst> wow
<RAOF> Yeah, sounds about right.
<mlankhorst> libgallium.so is only 8 mb..
<tjaalton> only 2MB here (precise)
<tjaalton> oh wait
<tjaalton> hehe
<tjaalton> the stripped binaries are much more manageable
<RAOF> :)
<tjaalton> 4-5M
<tjaalton> no point in looking in debian/tmp/dri..
<mlankhorst> hm weird
<mlankhorst> oh great, make can swallow errors
<mlankhorst> I think I accidentally got it to work today, I don't know how
<RAOF> Heh
<mlankhorst> doing one more test run to see if it's really the case
<tjaalton> slangasek also told that libxatracker isn't linked properly, it's missing -ldl -lm
<mlankhorst> dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so.0.0.0 exists in debian/tmp but is not installed to anywhere
<mlankhorst> dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so exists in debian/tmp but is not installed to anywhere
<mlankhorst> dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so.0 exists in debian/tmp but is not installed to anywhere
<mlankhorst> scary..
<tjaalton> :)
<mlankhorst> is he in this channel? he made a mess of the git tree
<tjaalton> mess?
<tjaalton> builds fine here
<mlankhorst> of course it does
<jcristau> committed with patches applied?
<mlankhorst> jcristau: winner :D
<tjaalton> ah :)
<jcristau> bad vorlon
<tjaalton> quite easy to do that :)
<mlankhorst> ah too bad he's not in any channels I'm in, can someone else point and laugh at him for me? :)
<tjaalton> you're not on #ubuntu-devel?
<mlankhorst> I'm in too many channels already, I cut out at 10 :p
<jcristau> 10??
<tjaalton> damn, need to run.. installing quantal on the ati box just finished but can't test mesa there until late this evening ./
<tjaalton> :/
<mlankhorst> jcristau: easier that way
<tjaalton> i have 20+
 * jcristau has like 80 irssi windows open
<mlankhorst> jcristau: professional lurker :)
<tjaalton> hah
<jcristau> :)
<tjaalton> that's a lot
<jcristau> bunch of them are privmsg tho
<tjaalton> 20 is the limit after which alt+key shortcuts stop working
<jcristau> still...
<RAOF> tjaalton: I'll run it on this ati box if you like.
<tjaalton> RAOF: that would be great, I'll be on the bus for the next 1,5h and can do stuff but not test :)
<tjaalton> afk ->
<mlankhorst> tjaalton: ok refreshed the patch
<mlankhorst> tjaalton: yeah that's why I give up on 10, personal irc comes after that :)
 * mlankhorst has ignore on joins/quits from everyone, and nicks on some people who keep dropping out and auto rename
<mlankhorst> ok now to figure out how to add version to libgallium
<tjaalton> no need
<tjaalton> it's internal
<mlankhorst> so is libdricore right?
<jcristau> yes
<tjaalton> yeah but they added a version for some reason
<tjaalton> ewll
<tjaalton> *well
<tjaalton> the reason was probably that you could have several of those installed, but this is strictly a packaging detail right now so I wouldn't bother :)
 * mlankhorst bets the symbols would still conflict, leaving fun issues to debug
<mlankhorst> ah well I'll leave it the same for now
<RAOF> Upstream versioned it to make it easier on developers.
<tjaalton> looks like I didn't have that messy commit when I built it locally :)
<tjaalton> mlankhorst: adding libgallium.so to .install.in means it'll fail on !x86 !armhf
<tjaalton> ugh
<tjaalton> now mixing things again
<mlankhorst> tjaalton: oh right armel..
<tjaalton> or sth
<tjaalton> anyway, probably best to copy it in rules
<RAOF> We don't build libgallium on armel?
<tjaalton> probably, was thinking of llvm again..
<mlankhorst> I could upload to my armel ppa
<tjaalton> leave it as is, like it was before..
<tjaalton> my bad :)
<mlankhorst> ah k
<tjaalton> so now only the libxatracker linking issues remain
<mlankhorst> oh I didn't actually test if it ran or not
<mlankhorst> just if it built :p
<tjaalton> hehe
<tjaalton> needs ati or nvidia hw then
<mlankhorst> oh I know, lets netboot that thingy in precise again
<mlankhorst> btw other drivers will depend on libgallium.so.0 too
<jcristau> which other gallium drivers are there?
<jcristau> not counting llvmpipe
<mlankhorst> well just simple grep, seems libgbm1, libxatracker1, and libegl1 might depend on it
<tjaalton> vmwgfx?
<jcristau> tjaalton: ah right.  but that's also x86 :)
<mlankhorst> so maybe it needs a libgallium0 package..
<tjaalton> jcristau: oh, indeed
<tjaalton> mlankhorst: or just drop it, the space savings aren't that critical anymore
<jcristau> mlankhorst: dunno about xatracker, but i would sure hope libegl doesn't link in gallium
<tjaalton> if it saves 20MB that's still peanuts
<mlankhorst> libegl1-mesa-drivers/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so
<tjaalton> at this point anyway
<jcristau> hrm
<tjaalton> if there's risk of breaking something then maybe leave it unenabled for now?
<mlankhorst> well lets quantify it
 * mlankhorst tries out both
<RAOF> egl_gallium.so isn't totally necessary (although it *is* the only way to get OpenVG support)
<mlankhorst> I'm just going to compare size
<mlankhorst> but would it be worth it trying to upstream it?
<tjaalton> not if they have other plans (the monolithic dri.so?)
<mlankhorst> $ du -sh ?ummy*
<mlankhorst> 39M     dummy
<mlankhorst> 233M    dummy2
<mlankhorst> 45M     summy
<mlankhorst> 287M    summy2
<mlankhorst> blegh 6 mb
<mlankhorst> 2 contains all the -dev and -dbg files
<RAOF> tjaalton: I don't think that rose to the level of a *plan* 
<tjaalton> RAOF: ok, so in that case it might be worth it :)
<RAOF> That was more âthanks for the dricore patch. I've always wanted to do something like that, but roll everything up into a monolithic dri.soâ
<RAOF> So it's probably on the TODO list, just after âlearn Portugueseâ
<tjaalton> ahh
<mlankhorst> so do we keep the patch or..
<seb128> tjaalton, mlankhorst: how much extra space are we talking about on the deb?
<tjaalton> keep it, and ship with it if it works, but if there's risk of breaking something maybe spend some more time on it?
<mlankhorst> seb128: 6 mb uncompressed if the entirety of mesa was shipped, so less than that
<seb128> mlankhorst, how much on the deb? 6mb is quite some
<mlankhorst> let me test build one more time
<tjaalton> testing the xatracker link fail
<mlankhorst> seb128: what debs do you mean specifically? I bet not all of them are shipped
<tjaalton> libgl1-mesa-dri
<seb128> mlankhorst, I'm trying to figure what would the impact on the CD to drop that optimisation, it was done for a reason ;-)
<RAOF> I recall that it nabbed on the order of 10 MiB of CD space when I first did it; the gains may be less now that dricore is upstream.
<mlankhorst> RAOF: probably, it's 5 mb saved uncompressed for just libgl1-mesa-dri
<mlankhorst> but yeah looks like libgl1-mesa-dri compresses well so it saves like 300 kb compressed..
<seb128> well, the liveCD is not deb compressed, it's squashfs compressed I think
<seb128> I guess we could try to drop that optimization and wait for the next daily iso and see the difference
<mlankhorst> but the total still rounds up to 1.4mb because the other parts need to compress parts of libgallium too
<mlankhorst> see http://paste.ubuntu.com/1160450/
<tjaalton> the debs are xz-compressed now
<seb128> tjaalton, deb compression doesn't matter for the liveCD, they do for the alternate
<RAOF> Wah! Nearly 7pm. Time to stop!
<tjaalton> seb128: i know, but while comparing deb sizes..
<mlankhorst> tjaalton: same compression is used :) but I imagine squashfs compression might be different
<seb128> tjaalton, mlankhorst, RAOF: well, your call at the end to see how much work it is and if you think it's worth it, CD space is still a limited resources and some mb can mean we need to drop support for a language spoken by some hundred of million of people
<mlankhorst> I think we ought to measure it
<seb128> so it's not like there was not a tradeoff
<mlankhorst> could I bug someone to master a cd with both debs to see the space difference?
<mlankhorst> but I'll post it on mesa-dev
<seb128> mlankhorst, well the deb difference probably done a rough estimation, they are not compressed the same way but they are both compressed
<tjaalton> mlankhorst: duh, of course. i'll get me coat
<mlankhorst> hm, suppose I should test first before posting it
<mlankhorst> seb128: I think I'm going to try to get it upstream, if it gets accepted there we wouldn't need to keep it.
<seb128> mlankhorst, that would be great
<tjaalton> yeah
<tjaalton> -modesetting moved to main
<tjaalton> meh, no success in getting xatracker linked properly
<tjaalton> later ->
<UraniumSlug> Hey all, updated my nvidia drivers having xorg dependency issues.
<UraniumSlug> Any one else done this too?
<mlankhorst> UraniumSlug: it's done on purpose
<mlankhorst> new nvidia drivers claim to be compatible, but aren't..
<UraniumSlug> mlankhorst, what's the work around?
<mlankhorst> not installing new x server :-)
<UraniumSlug> I've tried using the xorg-edgers ppa nvidia-current package.
<UraniumSlug> Not getting past the login screen with them though.
<mlankhorst> yeah they just broke, no good fix right now, depends on new nvidia drivers
<mlankhorst> tjaalton: hm glxgears spins
<mlankhorst> and login screen comes up right
<UraniumSlug> mlankhorst, thanks for the info, much appreciated.
<popey> hello Xers!
<popey> Is there any technical reason why we couldn't backport nvidia-current in quantal to precise?
<popey> I am told there are some compelling features (xrandr support) improved in the version in quantal
<mlankhorst> popey: I would imagine that would be for nvidia-current-updates, but no idea when that updates, we mostly deal with the things we can influence here :)
<popey> mlankhorst, well, I'm asking because someone on the backports team wanted to know if there was a technical reason we shouldn't backport that driver, I don't know :)
<mlankhorst> I don't know if there is any technical reason, but nvidia-current-updates would be the right place to put it, maybe bryceh or Sarvatt know
<popey> ok
<popey> ta
<mlankhorst> popey: but let me know, it would be useful when the quantal server works with nvidia so I could copy it to my q-lts-backports ppa :)
<RAOF> popey: nvidia-current-updates is the package deliberately designed to do post-release updates. I don't think we've ever managed to *do* one, but that's what its for :)
<popey> hah!
<mlankhorst> RAOF: actually the version is newer
<mlankhorst> 295.40-0ubuntu1.1 vs 295.49-0ubuntu0.2
<popey> is it a time/resource reason for not doing it, technical or some thing else?
<mlankhorst> popey: because not updating to newest and shiny all the time is more likely to keep systems running, or because we don't find it a high piority, pick one :)
<mlankhorst> it's not 'oh new version, lets update' but more like 'things broke, is there a new version that fixes it?' :-)
<popey> well, the specific thing that prompted me asking is because colour profiling seems broken with the nvidia proprietary driver because it doesn't support xrandr 1.2 
<mlankhorst> then use that as justification for requesting an update :-)
<popey> whats the process? file a bug?
<mlankhorst> RAOF: is the process the same for the binary drivers?
<tjaalton> just ask tseliot to update it?
<mlankhorst> tseliot: ^
<tseliot> yes?
<tseliot> popey: please file a bug report and feel free to assign it to me
<tseliot> (against nvidia-graphics-drivers-updates)
<popey> ok!
<mlankhorst> yay for nvidia is not completely removed types of bugs..
<bryceh> thanks tseliot 
<tseliot> :)
<mlankhorst> ah great, my libgallium patch might get folded in to the patch for automaking whole of gallium :)
<Prf_Jakob> Wouldn't it be better to just fold all the gallium drivers into a single binary.
<Prf_Jakob> Enable -fvisibility=false and get an even smaller total binary size.
<Prf_Jakob> And faster loading
<mlankhorst> Prf_Jakob: in that case you might as well link everything into libGL completely
<Prf_Jakob> mlankhorst: there is no real gain for that, since DRI driver only export on symbol.
<Prf_Jakob> And doing a mega classic dri driver might be harder.
<mlankhorst> but it won't help for vdpau and other gallium drivers that aren't dri :)
<Prf_Jakob> At least mega dri drivers would be officially supported, the whole shared thing is hacky as hell since we have no formal ABI or promise of ABI over that boundry.
<mlankhorst> true
<Prf_Jakob> Loading extra gallium drivers arn't that bad since they are relativly tiny 400-700k
<Prf_Jakob> Also why you guys don't just upx all binaries I don't get.
<mlankhorst> because it doesn't make the cd smaller :-)
#ubuntu-x 2012-08-23
<tjaalton> RAOF: hey, have you had time to test the new mesa with ati yet?
<RAOF> Sorry, no.
<tjaalton> ok, no worries, I just need to build another test rig for that :)
<tjaalton> actually, got one on the floor somewhere..
<tjaalton> will test nouveau too
<mlankhorst> tjaalton: i think the corruption was due to incorrect drivers and having vesafb loaded before radeon
<tjaalton> mlankhorst: which bug?
<mlankhorst> tjaalton: well when I did a smoke test on radeon yesterday
<tjaalton> ahh ok
<tjaalton> I'll reboot this box now to see how it goes
<tjaalton> then swap it with gf8600
<tjaalton> hd6450 worked
<tjaalton> omg it only gave ~59fps in glxgears where gf8600gt gives 1800
<tjaalton> so, both work
<tjaalton> now only need to fix xatracker linking
<Prf_Jakob> yes please
<tjaalton> :)
<tjaalton> Prf_Jakob: it's missing -ldl and -lm somwhere
<tjaalton> actually not -lm
<Prf_Jakob> Hmm ok
<tjaalton> at least my builds have it
<tjaalton> not sure where to add it..
<tjaalton> hmm, how do I check if a lib has unresolved symbols?
<tjaalton> ie. not linked properly
<tjaalton> since with libgallium patch applied libxatracker links to it, but would check if it uses libdl/libm directly
<tjaalton> (libgallium is linked to libdl/libm)
<jcristau> tjaalton: ldd -r
<jcristau> (after the fact)
<jcristau> or link with -Wl,-z,defs to make it fail on unresolved symbols
<tjaalton> jcristau: thanks
<tjaalton> not getting the result I was expecting :)
<tjaalton> ldd run on the same system mesa was built on shows libdl & libm, but -r gives unresolved symbols for drm*
<tjaalton> it's the same for 8.0.x though, so not a regression \o/
<tjaalton> libxatracker1 would depend on libgl1-mesa-dri though because of libgallium, but that's fine I guess..
<tjaalton> somehow doesn't depend on libllvm-3.1
<tjaalton> libgl1-mesa-dri does, is dh_shlibdeps trying to be clever?
<tjaalton> ok, think it's time to upload mesa
<tjaalton> or should we split libgallium out of -dri..
<tjaalton> mmh, can be done later
<tjaalton> huh, fails to sbuild
<tjaalton> sigh, parallel building can make it fail
<mlankhorst> tjaalton: have you read the upstream comments?
<tjaalton> what where?
<mlankhorst> on mesa-dev
<tjaalton> i know the one email from airlied that got no replies
<mlankhorst> meant about libgallium
<tjaalton> ah
<tjaalton> yes
<mlankhorst> so maybe better to drop it for now :)
<tjaalton> ok, will disable it
<tjaalton> looks like the patch might affect parallel builds too, at least it built without it just fine
<mlankhorst> maybe the depends are fucked
<mlankhorst> although make loves to eat errors there so I never know for sure if a build succeeds or not :p
<tjaalton> testing if weston builds now..
<tjaalton> nope
<tjaalton> ricotz, Sarvatt: so how have you ignored the test failures in weston on xorg-edgers?`the diff is too large to handle
<Sarvatt> http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/hooks/weston.patch
<tjaalton> ah, thanks
<ogra_> tjaalton, not sure you have seen it, rsalveti just uploaded an -omap driver with proper probing support, do you think we could include it in the deps of -all on arm builds ?
<tjaalton> ogra_: I uploaded it, but yes sounds good
<Sarvatt> hmm wonder if modesetting should be there too
<mlankhorst> Sarvatt: it should be there on x86 now at least
<Sarvatt> yeah its missing on arm though
<mlankhorst> do you know any sane arm then?
<mlankhorst> that would support it
<Sarvatt> your panda?
<mlankhorst> already works with omap driver..
<Sarvatt> exynos, displaylink?
<Sarvatt> arm might want displaylink support
<mlankhorst> oh right
<mlankhorst> let me move it to -all then
<ogra_> ++
<tjaalton> bumping the weston build-deps on mesa bits to 9.0~ sounds sane?
 * mlankhorst wonders why ati driver is built on arm..
<tjaalton> don't look too closely :)
<mlankhorst> is cirrus needed too? would be better with modesetting required..
<tjaalton> cirrus on arm?
<Sarvatt> i was wondering too and apparently there are arm boards with pcie
<Sarvatt> (re ati and nouveau on arm)
 * ogra_ isnt sure which insane qemu implementations are out there, might be that there are arm based machines with cirrus ... but unlikely 
<ogra_> right, the recent marvell server boards have pcie 
<mlankhorst> doubt it has anything resembling vga
<ogra_> its not very likely that anyone uses them with graphics cards though
<mlankhorst> tjaalton: can we drop cirrus and request modesetting to be used?
<tjaalton> mlankhorst: x86?
<mlankhorst> any
<tjaalton> probably
<ogra_> i would leave cirrus, noouveau and ati out of arm
<mlankhorst> I think cirrus should be moved out of main to universe :)
<ogra_> all arm boards i have seen in my life default to xfbdev anyway ... most of the time going beyond that means an unpackaged binary blob 
<ogra_> only for omap and tegra we have exceptions in teh archive yet 
<tjaalton> if kvm is now using the kms driver with -modesetting, then yes
<tjaalton> not kvm but quantal
<mlankhorst> i believe it would be the case, but didn't check yet :p
<tjaalton> weston uploaded
<mlankhorst> it's doing something
<mlankhorst> oh right
<mlankhorst> ok this old kernel seems to lack cirrus at least
 * mlankhorst gave up on kvm and used qemu straight :)
<mlankhorst> virt-manager is a lot harder than kvm -hda quantal-vb.vmdk (originally a virtualbox image)
<mlankhorst> tjaalton: after a lot of effort (sigh llvmpipe) it seems cirrus uses modesetting :)
<mlankhorst> so I think it could be dropped safely
<mlankhorst> ogra_: what is the tegra one then?
<ogra_> in the nvidia-tegra package, we're still waiting for an abi 13 release from nvidia (they are workin on it)
<ogra_> you dont want that included anywhere 
<ogra_> its a binary blob like the x86 nvidia packages
<mlankhorst> oh right
<mlankhorst> what about omap, is that good enough to move to -all or should it stay in universe
<tjaalton> mlankhorst: omap for arm.. that's where you started, right? :)
<tjaalton> adding it to video-all for arm
<mlankhorst> tjaalton: yeah how do we get it in main?
<tjaalton> mlankhorst: ask on #ubuntu-devel I guess
<tjaalton> before pushing xorg to the archive, so it won't block installer builds
<tjaalton> it won't need a MIR
<mlankhorst> ogra_: thanks :)
<mlankhorst> tjaalton: feel free to push, mir done
<mlankhorst> nm ill hand it off :)
<tjaalton> Sarvatt: x11-apps ready for quantal?
<Sarvatt> tjaalton: oh it was released, let me fix that, sorry
<tjaalton> so it seems, versions_current is lagging behind
<tjaalton> the changelog doesn't mention rendercheck :)
<tjaalton> non-issue
<mlankhorst> bryceh/tjaalton: can we kick cirrus to universe and stop building ati/nouveau on arm?
<Sarvatt> oops :(
<tjaalton> mlankhorst: yes
<tjaalton> kvm was the only reason to keep cirrus around
<tjaalton> Sarvatt: don't worry about it :)
<mlankhorst> tjaalton: yeah i want to keep it because the old cd i was using didn' t enable it yet, could probably be dropped from main later
<mlankhorst> s/main/universe/
<bryceh> mlankhorst, yeah
<mlankhorst> or leave it in for the release until r :)
<mlankhorst> I dumped all my work wrt ttm and dma-buf synchronization on my git tree, friday is last day before vacation :p
<bryceh> tjaalton, are you using http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package_status.html ?
<mlankhorst> im not going to check my corporate mail so only if it's really important mail my personal one :)
<tjaalton> bryceh: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html
<bryceh> fdo has been up and down this past week so that's affected this script, although it *should* be current presently; lemme know if not
<tjaalton> mlankhorst: have fun :)
<bryceh> tjaalton, yeah I believe those are aliased together; should be same data
<tjaalton> bryceh: looks like it yep
<mlankhorst> bryceh: all in all looks really green 
<tjaalton> I just skimmed through the list to see if there's anything to update before ff
<bryceh> mlankhorst, congrats on vaca, how long you going to be gone?
<mlankhorst> 2 weeks
<bryceh> nice
<bryceh> tjaalton, I tuned down the frequency it runs to not impact fdo as much.  Some day I'll rewrite it so it can update from LP more frequently and FDO less frequently, but right now it does all the updates synchronously...
<bryceh> it currently updates once every 6 hours
<mlankhorst> and after that resync clock for a week then xdc2012 :)
<tjaalton> bryceh: yeah that's fine, we're mostly green anyway, and debian is frozen :)
<bryceh> I notice we have nvidia-current-updates at 295.49 in precise, but x-updates is up to 304, as is quantal and -edgers.  Should we consider putting that in precise's -updates package?
<bryceh> https://launchpad.net/~xorg-edgers/+archive/drivers-only looks like it's no longer used; maybe we should delete that PPA?  ddx-only driver updates aren't really that helpful anymore
<ricotz> bryceh, i guess disable should be enough
<mlankhorst> bryceh: i think someone already opened a bug for that against -current
<bryceh> true; easy enough to revert if someone thinks it's needed
 * bryceh switches off the drivers-only ppa
<bryceh> mlankhorst, nvidia-current is a binary package so no bugs against it.  I did skim through the nvidia precise bugs but didn't spot anything; let me take a closer look.
<mlankhorst> hm current-updates?
<bryceh> aha https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates
<bryceh> bug 1037483
<ubottu> Launchpad bug 1037483 in nvidia-settings-updates (Ubuntu Precise) "Needs NVIDIA driver 304.37" [Medium,In progress] https://launchpad.net/bugs/1037483
<mlankhorst> ah there we go
<bryceh> thanks
<mlankhorst> g' night :)
<bryceh> cya
<mlankhorst> 15
#ubuntu-x 2012-08-24
<mlankhorst> morning x
<RAOF> Hey mlankhorst 
<mlankhorst> hey raof :)
<mlankhorst> hypothetically if my vacation led me to australia next 2 weeks, what would be fun to visit there? :P
<RAOF> Where in Australia?
<RAOF> Anywhere?
<mlankhorst> starting from tamworth but shrug dno yet, whats reachable by car i suppose
<RAOF> Reachable by car from *Tamworth*?
<RAOF> You know Tamworth is at least 200Km away from everywhere, right?
<mlankhorst> yeah :p
<mlankhorst> visiting a friend there
<mlankhorst> but i dont mind travelling once i visited
<RAOF> That's approximately as far north as I've been in Australia (not quite true, I've stayed at a property outside of Armidale).
<RAOF> I'm not particularly familiar with it :)
<mlankhorst> oh :p
<RAOF> If you're amenable to driving south for a couple of days, though, I'd highly recommend staying a night or two in the Blue Mountains.
<RAOF> Going to the Genolan caves, and generally having doing a bunch of walks around there.
<RAOF> There's obviously plenty of fun things to do in Sydney, too.
<mlankhorst> ah :)
<RAOF> You could make it to the coast as a (fairly long) day trip, though; Coffs Harbour is meant to be nice, although I've never been there.
<RAOF> (And that *is* more north than I've been in Australia ?)
<mlankhorst> ill keep those in mind, thanks :)
<popey> seems quantal inside virtualbox is using llvmpipe instead of the 3d accelerated passthrough via virtualbox-guest-x11. Where should I file a bug for this?
<popey> the result is s l o w desktop performance
<mlankhorst> is 3d acceleration passthrough setup correctly?
<mlankhorst> in the guest
<popey> define "setup"
<tjaalton> was there something with the dkms package failing on 3.5
<tjaalton> ?
<popey> usually I just install virtualbox-guest-x11 and it 'just works'
<popey> http://paste.ubuntu.com/1164193  is my glxinfo
<popey> http://paste.ubuntu.com/1164194 is my xorg.0.log
<popey> which looks to me like it's loading the right driver
<mlankhorst> glxinfo looks correct..
<mlankhorst> oh nm :p
<tjaalton> yeah but drm fails
<tjaalton> popey: you have virtualbox-guest-dkms installed and the modules built?
<tjaalton> if not, there's your problem
<popey> it is/was installed.. reinstalling and I get success messages from DKMS..
<popey> will reboot to test it again.
<mlankhorst> or just restart lightdm
<popey> true
<popey> nope, that didn't fix it
<popey> glxinfo still reporting Gallium 0.4 on llvmpipe
<tjaalton> another xorg log please, together with dmesg
<popey> http://paste.ubuntu.com/1164211
<popey> http://paste.ubuntu.com/1164212
<mlankhorst> just reboot first
<popey> i did :)
<tjaalton> vesafb.. doubt it'll help
<tjaalton> popey: try 'modprobe vboxvideo'
<popey> *boom*
<mlankhorst> tjaalton: yeah that fixes it
<popey> x died by the look of it
<tjaalton> ok, stop it first :)
<popey> dropped back to the lightdm logon screen
<popey> hahaha
 * popey rewinds time
<tjaalton> dunno why it doesn't autoload tho
 * popey reboots and tries again
<mlankhorst> anyhow resolved invalid, not a bug for us but for virtualbox :p
<popey> :)
<tjaalton> yeah something missing if it's not getting loaded
<popey> hmm, with the driver loaded I just get a black screen
<mlankhorst> works fine here
<popey> can't get back to tty either now
<popey> mlankhorst, did you login or just get to lightdm?
<popey> my user is set to autologin, and I just get a black screen with vboxvideo loaded
<tjaalton> maybe it's another nvidia
<popey> http://paste.ubuntu.com/1164233/ is my xorg.log
<popey> http://paste.ubuntu.com/1164235/ is dmesg
<popey> (now booted with vboxvideo forced loaded in /etc/modules)
<tjaalton> (EE) AIGLX error: vboxvideo does not export required DRI extension
<tjaalton> there
<mlankhorst> so still not working right
<popey> wonder if the vbox driver that comes with latest vbox works better than the one in the repo
<mlankhorst> tjaalton: hm vbox guest additions don't load video by default
<tjaalton> hum is it experimental perhaps?
<mlankhorst> probably
<tjaalton> popey: the one in the repo is at least patched to build
<mlankhorst> worksforme btw
<popey> they just released 4.1.20
<popey> current one in ubuntu is 4.1.18
<mlankhorst> oh damn, thought i had sent that patch to vbox already
<tjaalton> the changelog doesn't look too interesting
<popey> "Warning: unsupported pre-release version of X.Org Server installed.  Not
<popey> installing the X.Org drivers.
<popey> "
<popey> bah
<popey> well that broke i
<popey> +t
<popey> should I file a bug somewhere?
<mlankhorst> erm you dont need the guest additions iso
<popey> yeah, was just trying it, but undone that now
<mlankhorst> debfx: ping?
<hyperair> is there a vaapi backend for gma500_gfx?
<hyperair> okay forget it
 * hyperair tosses the machine out the window
<Sarvatt> hyperair: cedartrail or poulsbo?
<hyperair> Sarvatt: poulsbo i think
<Sarvatt> 12.04.1 has cedartrail blobs with va but that doesn't work with poulsbo
<hyperair> it's an eeepc
<Sarvatt> made in the past year?
<Sarvatt> lspci would say gma3600 or 3650
<hyperair> eh i don't know, i've given up on that machine
<hyperair> i had to unplug the bloody inbuilt keyboard, because alt was going haywire
<hyperair> the stock kernel in precise was giving some really strange issues
<hyperair> it's got 2GB of RAM, and uses DDR2 RAM, if that helps
<hyperair> the stock precise kernel landed on a black screen. switching to tty1 and back to tty7 brought half the screen back
<hyperair> rather, both the top and bottom half of the screen were being rendered onto the top half
<hyperair> so if you moved your mouse around, parts under the cursor would flip between the stuff in the bottom half of the screen and stuff in the top half of the screen
<hyperair> restarting X solves the issue -- it only happens during the first X run it seems
<hyperair> i didn't see anything particularly different in the Xorg log, except for some weird magic hex value
<Sarvatt> hmm -queuebot/#ubuntu-release- New source: libdri2 (quantal-release/primary) [1.0.0~git20120510+26fee2e-0ubuntu1]
 * Sarvatt scratches head
<mlankhorst> libdri2?
<mlankhorst> http://www.smallperturbation.com/sites/default/files/post_images/2012-08-17_one_does_not_simply.jpg
<nerdopolis> Hello. is there a way to get the build options that get passed to mesa's ./configure that is used by Ubuntu? I noticed Ubuntu's mesa binaries are much smaller then the mesa binaries I build
<soreau> nerdopolis__: mesa is split into several packages. the files might not all be installed to the same place
<soreau> nerdopolis__: For instance here are packages containing 'mesa' http://packages.ubuntu.com/search?keywords=mesa&searchon=names&suite=precise&section=all
<nerdopolis__> soreau: the lib/i386-gnu-linux/(dri|gbm|egl_gallium) folders should be the same size I would assume though
#ubuntu-x 2012-08-25
<nerdopolis__> soreau: say what does the -g cflag do? I'm having difficulties finding what it does on Google and the man page
<soreau> nerdopolis__: -g enables debug symbols
<nerdopolis__> soreau: then I guess don't want that.
<soreau> From gcc man page: -g  Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2).  GDB can work with this debugging information.
<nerdopolis__> soreau: that means it uses more space... I looked at Ubuntu's mesa package. they have -Os as a CFLAG. I was accidentaly passing -0s as a MAKEFLAG
<soreau> yea and don't mix up  O with 0 ;)
<nerdopolis__> Soreau: yeah. that was the problem too. 0 and O look the same in kate's default font... I just realized that
<soreau> nerdopolis__: You can see the install directories used for what configure options in the build log https://launchpadlibrarian.net/99008970/buildlog_ubuntu-precise-amd64.mesa_8.0.2-0ubuntu3_BUILDING.txt.gz
<soreau> https://launchpad.net/ubuntu/+source/mesa/8.0.2-0ubuntu3/+build/3370278
<soreau> Here https://launchpad.net/ubuntu/+source/mesa if you scroll down click the > button next to the package you're interested in, you can get the build stats for it
<nerdopolis__> dang. -Os didn't work
<nerdopolis__> soreau: I guess I'll try to run the Ubuntu build script for mesa... then capturing the command line arguments for ./configure...
<soreau> nerdopolis__: You can apt-get source mesa and look at debian/rules to see the config options too
<nerdopolis__> soreau: that file isn't that easy to read. they have conditionals for hurd in there!
<soreau> nerdopolis__: Then just use launchpad
<soreau> it has the package build log
<nerdopolis__> soreau: good idea. I captured what gets captured to the ./configure by running and pausing. It seems so far --with-gallium-drivers= nothing. I think Wayland will need that as well as egl...
<nerdopolis__> well... WESTON will need that
<soreau> nerdopolis__: Ubuntu packages gallium drivers afaik
<soreau> nerdopolis__: this doesn't have line numbers but search for 'configure' about the tenth instance down https://launchpadlibrarian.net/99008970/buildlog_ubuntu-precise-amd64.mesa_8.0.2-0ubuntu3_BUILDING.txt.gz
<soreau> you can see several different configure lines with different prefixes
<soreau> or actually it's the same prefix but building mesa in different parts
<nerdopolis__> soreau: It just seems that way. look at all the posts that are there http://lists.freedesktop.org/archives/mesa-dev/2012-August/date.html
<soreau> nerdopolis__: What posts specifically?
<nerdopolis__> Soreau: sorry. I guess Darxus asked me about mesa-dev on the #wayland channel...
#ubuntu-x 2012-08-26
<dileks> hi
<dileks> I added ppa:ubuntu-x-swat/q-lts-backport to my sources.list
<dileks> is it possible to have somewhere on <https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport> a hint to apt-pinning the packages from this repo?
<dileks> it took me a few minutes to get it right
<dileks> /etc/apt/preferences.d/ubuntu-x-swat-q-lts-backport-precise-pin-400: http://nopaste.snit.ch/159941
<dileks> https://help.ubuntu.com/community/PinningHowto
<dileks> lemme see if I can edit this and add mine as an example
<dileks> looks like I am not allowed to edit this wiki-page
<JanC> dileks: you need a U1/LP account to edit wiki pages
<dileks> hmm, I have a LP (PPA) account - thats not adequate?
<JanC> it seems like I can edit it, at least
<JanC> dileks: did you log in to the wiki succesfully?
<dileks> I could login but was not at the page I wanted to edit
<JanC> go back to that page & refresh it?
<JanC> and of course it probably requires cookies
<dileks> UserDocumentation
<dileks> go ahead was my slogan not back
<dileks> but going back helped
<dileks> JanC: are you editing?
<dileks> https://help.ubuntu.com/community/PinningHowto#Precise_Example
<JanC> dileks: I did a small change adding an extra space to test  ;)
<JanC> dileks: seems like you managed to edit it too
<dileks> yes
<dileks> missing a link to ppa-page
<JanC> maybe you should also add a warning about compatibility issues at the beginning
<dileks> yeah
<dileks> is there a warn symbol? /!\ (trac syntax) seems not to work
<dileks> https://help.ubuntu.com/community/HelpOnSmileys
<dileks> JanC: done
#ubuntu-x 2013-08-19
<robotfuel> it looks like 3d acceleration broke on nouveau starting on friday in saucy, phoronix benchmarks like open arena are taking almost 4 times longer to run.
#ubuntu-x 2013-08-20
<dfarmer> Hi, I'm trying to figure out what the status is with optimus support (nvidia-prime, raring kernel/xorg) -- does it support power management or just acceleration?
<tjaalton> just acceleration
<tjaalton> and external outputs
<tjaalton> although not easy to set that up atm
<dfarmer> Alright. Thanks. I may still give it a shot anyway
<dfarmer> I've been Googling around and not really finding anything, I guess nvidia hasn't said anything else about power management?
<tjaalton> what do you mean by "power management"
<dfarmer> Having the discrete GPU switch off when it's not being used
<tjaalton> right, not happening
<tjaalton> since it needs to draw the screen
<tjaalton> several things blocking it, one obvious one is the libGL abi
<tjaalton> you can only have one active
<tjaalton> in this case it's the nvidia libs
<tjaalton> but they're trying to fix that with khronos
<dfarmer> Ah ok. I didn't realize the issue there was that fundamental. 
<dfarmer> So pretty much what bumblebee is doing with a separate x server and compositing is really the only workable way to have switchable graphics until that gets resolved in the future.
<tjaalton> and xserver replaced with something else
<dfarmer> Thanks for educating me a bit :)
#ubuntu-x 2014-08-19
<mitz-> quit
#ubuntu-x 2014-08-22
<ricotz> Sarvatt, hi, there is a typo in the mesa packaging "libllvm-3.5" > "libllvm3.5"
<Sarvatt> ricotz: whoops, thanks
<ricotz> Sarvatt, ;)
<mlankhorst> Sarvatt: yeah sorry about that, i had to revert llvm again :P
<mlankhorst> but keep 3.5 in edgers please
#ubuntu-x 2015-08-17
<eanyx> Hi, would like to know what is the status of Ubuntu x-mir?
#ubuntu-x 2015-08-19
 * RAOF notices Sarvatt's x-x-v-i changes, and goes âOh! Have they finally released their *two years* of work.â Nope!
<Sarvatt> RAOF: NOPE!
<Sarvatt> lol
<tjaalton> hell no
<tjaalton> and changes after that snapshot have broken shit again
<tjaalton> git master is in crisis mode
<Sarvatt> squeak shit in before feature freeze, hopefully get a year of development full of fixes in wily
<RAOF> I just checked debian/changelog. It has actually been two full years since a non-prerelease xf86-video-intel release was made.
<tjaalton> fun
<Sarvatt> i went through intel bugs and saw at least 80 bugs that would be fixed by this
<RAOF> They might want to give up the fiction that they provide tarballs of xf86-video-intel :)
<Sarvatt> i dunno whats up with that, sounds like he doesnt want to release until it fixes every little problem qa comes up with
<tjaalton> strange that all the ddx's that actually people use "never" see releases
<Sarvatt> at least the prerelease tarballs were useful though
<tjaalton> yes
<Sarvatt> yeah ati intel etc
<tjaalton> nouveau, amdgpu seems to follow the trend too :)
<Sarvatt> nothing releases anymore lol
<tjaalton> RAOF: i've pushed a mesa snapshot to -experimental, have you checked if the mir patch still applies/works?
<RAOF> I have not; I can do that now if you like.
<Sarvatt> please please please
<tjaalton> hmm there probably is an earlier snapshot in ubuntu+1
<tjaalton> I think the patch applies at least
<tjaalton> nah
<tjaalton> but probably nothing too hard
<tjaalton> two hunks failed
<Sarvatt> i havent checked either, i just disable the xmir stuff, ugh
 * RAOF should really get around to dynamically loading EGL platforms for mesa and upstreaming the Mir one.
<tjaalton> I'd probably need to merge experimental to ubuntu+1 first
<tjaalton> ohyes
<Sarvatt> looks like my llvm-toolchain-3.7 fix to make mesa 4.11 work on i386 doesnt work, ugh
<Sarvatt> test suite just dies
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa/+build/7812906 dat 5 hour timeout, at least it doesnt just actually fail to build now
<Sarvatt> 11.0 rather
<Sarvatt> dunno if i should attribute this to wily being fucked because of the toolchain change or.. its fine in unstable
<Sarvatt> just added i686 as an option instead of just i586 that debian uses for i386
<tjaalton> asked doko about it?
<Sarvatt> debconf/plumbers week, dont want to harass anyone :D
<Sarvatt> apparently llvm is desktops problem, weirdly
<tjaalton> RAOF: pushed mesa ubuntu+1, includes fixed mir patch that at least builds
<tseliot> ricotz: I'm fixing up my 355 branch, and there really is no need to apply buildfix_kernel_3.18.patch . It builds correctly in wily (the nvidia check worked)
<ricotz> tseliot, ok, better recheck 346/352 too then
<tjaalton> uploaded mesa snapshot to canonical-x-staging..
<tjaalton> now intel..
<tjaalton> ah Sarvatt did it already
<tjaalton> ok, testinngg.
<jcastro> ricotz: man, I already have two -1's from the techboard on adding a GUI hook.
<mamarley> jcastro: Using the new PPA as staging for backports sounds like a good idea.  I think if we need an additional staging PPA, it would be better to create a new PPA under the graphics-drivers team since I can't upload to xorg-edgers. 
<jcastro> sure
#ubuntu-x 2015-08-20
<tjaalton> hmm rotation is broken on wily -intel
<tjaalton> not due to -intel but something else..
<tjaalton> -intel snapshot uploaded
<tjaalton> -amdgpu too
<vincx> Hi, question about the Proprietary GPU Drivers PPA. Is there a way to get AMD's drivers in also? What is needed and what can I do?
<mamarley> We would need someone to maintain them.  I don't have any AMD cards, so I wouldn't be able to do it, sorry.
<mamarley> If you know of another PPA with the AMD drivers, perhaps we could talk to the person who maintains that.
<Vincx> I'll check with AMD, if they could maintain a PPA
<tjaalton> haha
<ricotz> keeping up with xserver/kernel api/abi changes is already enough for them ;)
<Vincx> Yes, that's already enough for AMD, but the reason for this conversation is to say "for now...". 
<Vincx> Would OBS be sufficient?
#ubuntu-x 2015-08-21
<jcastro> well if the intent is to get the drivers in the distro then probably not?
<tseliot> ?
<tseliot> jcastro: what is wrong with having a PPA now?
<jcastro> well, that only solves half the problem?
<tseliot> we don't have the resources for what you last suggested
<tseliot> at least as far as I know
<jcastro> well, it doesn't need to be perfect, because the blingers know about the PPA
<jcastro> it just needs to not be crushingly slow
<tseliot> maintaining all that would be a nightmare
<tseliot> I'm talking about actual kernel patching, not only packaging changes
<jcastro> maybe we can ask for more help then?
<tseliot> if you can find what I suggested in my last email to the technical board, then things should be ok
<jcastro> ok, I'll talk to leanne and see what we can do there
<tseliot> jcastro: please make it clear that I won't be the one doing the work
<jcastro> right
<jcastro> tseliot: out of curiosity, how often does that happen?
<jcastro> please don't say all the time, heh
<ricotz> tseliot, kernel-patching? this gpl mistake was kind of a review problem of the kernel team
<tseliot> jcastro: the last example: LP:Â #1479913
<jcastro> that seems to be for fglrx?
<tseliot> jcastro: pretty often, I would say
<tseliot> jcastro: it could have easily affected nvidia
<ricotz> jcastro, no, nvidia too
<ricotz> aka flush_workqueue
<tseliot> I had a similar problem with nvidia in wily
<tseliot> yes, that one
<tseliot> imagine having to fix that on even more drivers
<tseliot> (which I already do for private OEM projects)
<jcastro> is this usually connected to a new backported kernel?
<jcastro> so like, if I'm on "normal" 14.04 without backported kernels this shouldn't be a problem right?
<tseliot> not really, it happened in vivid too
<tseliot> it was just an abi change
<tseliot> (same bug report I mentioned)
<jcastro> ok so the ask from you would be what, test kernels with the proprietary drivers before being published?
<tseliot> we already have such system in place. Something went wrong (and will go wrong again)
<tseliot> when kernels break binary drivers, the kernel team ask me to fix them
<jcastro> and if you don't fix them the kernel team publishes the kernel anyway?
<tseliot> that's what happened. The thing is I should fix the drivers before the kernels are published but I didn't have enough time to do it (it was a bit late when I was told)
<tseliot> they usually wait for me to finish
<jcastro> ok, so it's all process stuff then
<tseliot> yep
<jcastro> I'll ask will to talk to leann and figure out what's up
<jcastro> so you guys can concentrate on the drivers themselves
<tseliot> yes, you might want to ask if her team has the resources to allocate, to fix any new drivers that may be uploaded (should the drivers really become part of Ubuntu)
<jcastro> hey so thinking outloud, don't flip out when I say this...
<jcastro> but would the work be cut down if we concentrated on LTS-only? 
<tseliot> :)
<tseliot> cut down to an extent, yes, reasonable, not so much
<ricotz> by reducing the support to 9 months of normal releases, there are not many supported versions anyway ;)
<tseliot> right
<ricotz> tseliot, e.g. do you care for precise?
<jcastro> tseliot: ok, I was just thinking about low hanging fruit
<tseliot> ricotz: I have to, we still have OEM projects that run precise
<jcastro> like, if you're behind on the drivers for X,Y, and Z but the LTS is up to date, then it's not so bad.
<ricotz> I was specifically asked in the past for updated nvidia driver for precise in xedgers though 
<ricotz> ok
<tseliot> jcastro: again, prove that you have the resources to do it. That's the main problem
<ricotz> jcastro, currently there is nothing to skip, utopic is gone already
<jcastro> tseliot: I don't have any, it's just us and mmarley, and maybe jderose
<ricotz> or hire new resrouces ...
<tseliot> jcastro: that is obviously not enough
<jcastro> yeah which is why I was thinking of low hanging fruit
<jcastro> I recognize that this is difficult
<tseliot> what ricotz said. Possibly a small team
<tseliot> adding a PPA is very easy, especially for gamers
<jcastro> yeah
<jcastro> ok so what happens when this kernel issue hits the people with the PPA?
<tseliot> the packages in main/restricted are officially supported
<ricotz> ( in relation to that: not sure how the ubuntu-x team is doing after maarten is gone )
<tseliot> tjaalton and Sarvatt maintain the X stack now. I don't think we are going to replace Maarten
<tseliot> jcastro: I will try to help but any such task won't have a high priority on my TODO list. After all, some breakage is expected. ppa-purge to the rescue ;)
<tseliot> a messed up PPA is much better than a messed up archive (and the OEM projects that depend on it)
<jcastro> ack
<mamarley> The PPA can still have updates for all supported releases, right?
<jcastro> yeah
<tseliot> yep
<tseliot> ricotz: by the way, the new code in my 355 branch works now. You might want to have a look at the changes
#ubuntu-x 2016-08-22
<gabr1e11> Hi everybody, first time here. Looking for help on getting Vulkan running on my Intel HD3000. According to Canonical PPA this may be the place to ask. Thanks in advance
#ubuntu-x 2016-08-23
<rcano> Hi everybody, it is my first time here. I'm trying to get the Vulkan drivers for Intel running on my MacBook Air with an Intel HD3000. According to the Canonical PPA this is the place to ask for advise. Thanks in advance
<tjaalton> i'm not sure anv supports haswell
<rcano> I've tried to run the examples in LunarG and installed the drivers from the PPA, but it looks like the Vulkan driver is not detected
<tjaalton> the ppa is dead
<tjaalton> I'll just clean it up, yakkety has mesa 12 that provides mesa-vulkan-drivers
<rcano> Ok, I see. Any clue if that will work for a MacBook Air 2011 with HD3000?
<tjaalton> no
<tjaalton> no idea
<rcano> Ok, I'll wait for it then and see if there is any luck. Many thanks for the heads up!
<soee> 367.44 out :)
 * mamarley slaps soee around a bit with a large trout.
#ubuntu-x 2016-08-24
<mamarley> Well, 367.44 is up in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages, but soee and ricotz are both goneâ¦
<mamarley> ricotz: soee: 367.44 is up in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  The Linux 4.7 patch was dropped and the Linux 4.8 patch still applies.
<ricotz> mamarley, oh :(
<mamarley> Oh, you packaged it too?
 * ricotz already pushed it to the pppa
<mamarley> Darn.  I tried to let you know last night, but you were gone by the time I finished packaging the driver. :/
<ricotz> I see, sorry
 * ricotz needs to sleep at least once a day ;)
<mamarley> You should get a bouncer or Quassel or something. :)
<ricotz> there is always email though
<mamarley> Indeed, I wasn't thinking about that, but I can probably get your email address off your Launchpad page.
<mamarley> Or, no I can't.
<mamarley> But I have an old email from you with your address, so I will keep that in mind for the future.
<tseliot> mamarley, ricotz: just FYI I'm working on the new 367. I had to make some changes to the scripts that start nvidia-persistenced, and I will have to change gpu-manager too, so that bbswitch doesn't fail to switch off the dGPU when persistence mode is enabled (which is always now)
<mamarley> So those changes will probably apply to 370 then too.
<tseliot> yep
#ubuntu-x 2017-08-22
<soee_> VIDIA 384.69 Linux Driver Released With A Few Fixes
<soee_> *NVIDIA
<mamarley> soee: I was expecting that would come out early this week. :)
<soee> :D
#ubuntu-x 2017-08-24
<ricotz> mamarley, hi, any reason not to copy 384.69? 
<mamarley> ricotz: Nope, go ahead.  It has been working fine on my two test systems.
<ricotz> mamarley, same here, after some smoketesting
<ricotz> mamarley, thanks!
<mamarley> No problem
<tseliot> I'm going to upload it in artful. I have support for 384.69 in my local branch
<mamarley> tseliot: OK.  Did you ever set it up to use the external libglvnd?
<tjaalton> glvnd won't happen in artful
<mamarley> OK
<tjaalton> i'll probably ask for it's removal until debian is ready
<tjaalton> debian NEW processing is very slow these days..
<tjaalton> mesa upload has been sitting there for weeks
<tjaalton> and since the serverside is not done yet there is no reason to rush it in artful
<tjaalton> also, easier to backport mesa to xenial then :P
<mamarley> Strangely, Linux 4.13 does not break compatibility with either the latest or legacy NVIDIA drivers.
<ricotz> tjaalton, hi, https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa/+sourcepub/8197387/+listing-archive-extra still failing arm*
<tjaalton> ricotz: did you limit libxatracker to x86?
<ricotz> tjaalton, I would say so
<ricotz> it is failing in vc4 now
<tjaalton> ah it's vc4
<tjaalton> ok
<ricotz> which wouldn't be nice to skip ;)
<tjaalton> have you poked anhold?
<tjaalton> anholt
<ricotz> no
<tseliot> mamarley: yes, in a local branch
<tjaalton> ricotz: maybe try modifying src/gallium/drivers/vc4/Makefile.am to add "-I$(top_builddir)/src" to AM_CFLAGS?
<tjaalton> -I../../../../../src
<tjaalton> that's one too deep
<ricotz> tjaalton, you mean top_srcdir?
<tjaalton> ricotz: that's already included, and is the wrong one
<tjaalton> because the header is built under build/src/broadcom..
<ricotz> right, I haven't looked at, just judged from your follow up
#ubuntu-x 2017-08-25
<tjaalton> ricotz: rc5 builds just fine here
<tjaalton> on arm* without any mods
<ricotz> tjaalton, the tarball release or directly from git?
<tjaalton> tarball
<ricotz> I guess the generated headers are included there already
<tjaalton> could be
<ricotz> ok
<ricotz> tjaalton, mesa builds after some patching
<tjaalton> yes
<tjaalton> send it to the list
<ricotz> tjaalton, not sure if this is wanted upstream that way https://paste.debian.net/plain/982979
#ubuntu-x 2018-08-21
<mamarley> ricotz: 396.54 is ready in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages :)
<ricotz> mamarley, nice, I guess this is still not in sync with the vulkan dev-driver?
<mamarley> ricotz: I didn't check.
<ricotz> ok
#ubuntu-x 2018-08-22
<KitsuWhooa> Hey. I have the X-Swat stable ppa installed on Ubuntu 18.04, but it's missing libdrm-dev, making Qt5 (qtbase5-dev) impossible to install. Any suggestions?
<tjaalton> KitsuWhooa: what do you mean, bionic has libdrm-dev..
<KitsuWhooa> The ppa doesn't have a version for it for bionic
<KitsuWhooa> https://tasossah.com/txt/x-swat_qt5 the whole log
<KitsuWhooa> At least that's what it looks like to me. Apologies if I misunderstood it
<tjaalton> bionic has 2.4.91
<KitsuWhooa> Yeah, but it looks like the ppa doesn't have its own version that depends on the right version of, say, libdrm2
<tjaalton> it doesn't need one
<KitsuWhooa> Apt complains about " libdrm-dev : Depends: libdrm2 (= 2.4.91-2) but 2.4.92+git20180609.c1f2d9b9-0ubuntu0ricotz~16.04.2 is to be installed" though, which confuses me
<tjaalton> you're using some other ppa
<tjaalton> don't mix them
<tjaalton> edgers?
<KitsuWhooa> I don't think I did, unless there were some leftovers from the upgrade, which I doubt
<tjaalton> apt-cache policy libdrm-dev
<KitsuWhooa> 2.4.91-2 with the only repo listed being archive.ubuntu.com
<KitsuWhooa> and it's not installed
<tjaalton> apt-cache policy libdrm2
<tjaalton> you have leftovers from another ppa installed
<KitsuWhooa> oh wow
<KitsuWhooa> I see that now, yeah
<KitsuWhooa> Welp, that's dumb of me. Apologies
<KitsuWhooa> I don't remember installing that, but considering it says it's installed from /var/lib/dpkg/status, that seems to be the case
<tjaalton> you've disabled the ppa, that's why
<tjaalton> check /etc/apt/sources.list.d
<KitsuWhooa> I usually use ppa-purge for these things
<KitsuWhooa> That was the first thing I checked, and there are only two ppas there. The c_falco mame one and the x-swat one
<KitsuWhooa> Which is why I got confused
<KitsuWhooa> Anyway, I'll downgrade the packages and sort it out. Thank you for the help, and apologies for the inconvenience 
<tjaalton> np
#ubuntu-x 2018-08-23
<soee> mamarley: hi, some time ago i had problems installing latest drivers and i tried again yesterday and now all works fine - so i wanted just to inform :)
<NaughtySquid> morning
<NaughtySquid> i got the nvidia-396 update today from the PPA but it doesn't seem to work correctly and now Steam won't launch?
<NaughtySquid> trying to install mesa-utils:i386 wants to remove the 64bit version - which obviously isn't right
<NaughtySquid> mamarley: ?
<NaughtySquid> looks like the driver is totally broke, not even glxgears works
<NaughtySquid> going to totally purge and re install it and see what happens
<NaughtySquid> back, seems somehow the update from the previous 396 nvidia driver to the latest via the ppa is borked?
<NaughtySquid> purging it entirely and re installing has fixed it
#ubuntu-x 2019-08-20
<tjaalton> tseliot: xorg-server with glx vendor selection uploaded to eoan
<tjaalton> it got merged to server-1.20-branch last night
<tjaalton> plus an abi fix
<tjaalton> from gitlab
<tseliot> tjaalton: great, thanks! I am going to make things easier on the nvidia side now
#ubuntu-x 2019-08-21
<ricotz> tseliot, hi, did you thought about introducing nv-codec-headers yet?
<ricotz> might be more a pkg-multimedia thing though
<tseliot> ricotz: no, I haven't looked into that. I assume the package is not in Debian?
<ricotz> tseliot, no, they aren't packaged, just on dmo -- https://www.deb-multimedia.org/dists/testing/main/binary-amd64/package/nv-codec-headers
<ricotz> tseliot, jfyi https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925941
<ubottu> Debian bug 925941 in ffmpeg "nvenc not in ffmpeg" [Normal,Open]
<tseliot> ricotz: ok, thanks for the link
