#ubuntu-x 2007-06-18
<ubotu> New bug: #115267 in linux-restricted-modules-2.6.20 (restricted) "[nvidia-glx-new]  CharacterConsole+Compiz/Beryl crash" [Undecided,Needs info]  https://launchpad.net/bugs/115267
<ubotu> New bug: #120858 in xserver-xorg-video-ati (main) "Graphical corruption in gnome-terminal" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120858
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #121000 in xorg (main) "mouse cursor corrupted randomly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121000
<ubotu> New bug: #118999 in linux-restricted-modules-2.6.20 (restricted) "totem xine crash while playing a .mov file" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118999
<ubotu> New bug: #119114 in xorg (main) "Feisty LiveCD - No GUI - Setting video card's bus identifier incorrectly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119114
<ubotu> New bug: #73067 in xserver-xorg-video-ati (multiverse) "[patch]  fglrx under xen dom0" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73067
#ubuntu-x 2007-06-19
<ubotu> New bug: #110472 in linux-restricted-modules-2.6.20 (restricted) "openoffice crash with ATI fglrx when 3D accelerator enabled and composite disabled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110472
<ubotu> New bug: #77073 in linux-restricted-modules-2.6.20 (restricted) "xorg-driver-fglrx dependent on xserver-xorg" [Undecided,Fix released]  https://launchpad.net/bugs/77073
<ubotu> New bug: #77134 in linux-restricted-modules-2.6.20 (restricted) "ATI drivers 8.28.8 crashes 3D games" [Undecided,Needs info]  https://launchpad.net/bugs/77134
<ubotu> New bug: #77153 in linux-restricted-modules-2.6.20 (restricted) "Error building fglrx modules with 2.6.19.1 on edgy" [Undecided,Rejected]  https://launchpad.net/bugs/77153
<ubotu> New bug: #77420 in linux-restricted-modules-2.6.20 (restricted) "fglrx module won't build on feisty (dup-of: 77153)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77420
<ubotu> New bug: #77957 in linux-restricted-modules-2.6.20 (restricted) "[Feisty]  Regression: X freezes on 2.6.20 with fglrx" [Undecided,Fix released]  https://launchpad.net/bugs/77957
<ubotu> New bug: #76338 in linux-restricted-modules-2.6.20 (restricted) "Linux Restricted modules 2.6.20-2 are incompatable with X4100 Mobility. (dup-of: 85907)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/76338
<ubotu> New bug: #83602 in linux-restricted-modules-2.6.20 (restricted) ""no screen found" with fglrx; just dist-upgraded from edgy to feisty (dup-of: 85907)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83602
<ubotu> New bug: #83958 in Baltix (restricted) "outdated and dangerous description in/for xorg-driver-fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83958
<ubotu> New bug: #120939 in libx11 "X11 warnings after upgrade when moving windows" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120939
<ubotu> New bug: #44983 in Ubuntu "Random connection drops from the xserver" [Medium,Needs info]  https://launchpad.net/bugs/44983
<ubotu> New bug: #121194 in xserver-xorg-video-intel (main) "not enough VideoRam allocated" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121194
<ubotu> New bug: #118898 in xorg (main) "Desktop pulldown "Applications/Office" has reference to "Evolution" after I removed Evolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118898
<ubotu> New bug: #120509 in xorg (main) "Gutsy upgrade from Feisty leaves Feisty Docs in System / About Ubuntu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120509
<bryce> new fglrx for testing:  http://people.ubuntu.com/~bryce/Testing/
<bryce> not sure I packaged it correctly; advice appreciated
<ubotu> New bug: #98684 in linux-restricted-modules-2.6.20 (restricted) "Switching users (switch user) blank screen on fglrx (ATI driver)" [Medium,Fix committed]  https://launchpad.net/bugs/98684
<ubotu> New bug: #94849 in linux-restricted-modules-2.6.20 (restricted) "System hangs on restart/shutdown with current fglrx driver loaded!" [Undecided,Fix committed]  https://launchpad.net/bugs/94849
<ubotu> New bug: #96279 in linux-restricted-modules-2.6.20 (restricted) "ati driver update for (X1300 e.q.)" [Undecided,Fix committed]  https://launchpad.net/bugs/96279
<ubotu> New bug: #121233 in xserver-xorg-video-intel (main) ""errors found in hardware state" after VT switch" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121233
#ubuntu-x 2007-06-20
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #121274 in linux-restricted-modules-2.6.22 (restricted) "Gutsy fails to start X with fglrx / ATI Express 200M" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121274
<ubotu> New bug: #121291 in xorg-server (main) "xorg crash (screensaver problem?)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121291
<ubotu> New bug: #119762 in linux-restricted-modules-2.6.20 (restricted) "freezes when ATI Accelerated drivers from restricted drrivers manager is enabled after restart." [Undecided,Unconfirmed]  https://launchpad.net/bugs/119762
<ubotu> New bug: #112292 in linux-restricted-modules-2.6.20 "Restricted Drivers Manager ATI + S-video cable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/112292
<ubotu> New bug: #121328 in linux-restricted-modules-2.6.20 (restricted) "Restricted manager use on live cd for nvidia before install breaks install" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121328
<ubotu> New bug: #121356 in xserver-xorg-input-mouse (main) "options usbhid mousepoll=x ignored" [Undecided,Unconfirmed]  https://launchpad.net/bugs/121356
<ubotu> New bug: #89816 in linux-restricted-modules-2.6.20 (restricted) "Kernel Driver pwc.ko not working (philips webcam) v4l error ?" [Medium,Confirmed]  https://launchpad.net/bugs/89816
<ubotu> New bug: #117013 in Ubuntu "Ubuntu fails to start with fglrx on radeon x1300 (dup-of: 96279)" [Undecided,Confirmed]  https://launchpad.net/bugs/117013
<ubotu> New bug: #96676 in gnome-terminal "[feisty]  function keys don't work in gnome-terminal" [Low,Confirmed]  https://launchpad.net/bugs/96676
#ubuntu-x 2007-06-21
<ubotu> New bug: #121175 in xserver-xorg-video-unichrome (universe) "VGA K8N890 graphics driver not supported" [Undecided,Confirmed]  https://launchpad.net/bugs/121175
<ubotu> New bug: #121516 in xserver-xorg-video-amd (universe) "fglrx causes Torcs to crash when races end" [Undecided,New]  https://launchpad.net/bugs/121516
<ubotu> New bug: #121551 in xorg (main) "Framebuffer Terminal (tty1-tty6) Fails after Login on X11" [Undecided,New]  https://launchpad.net/bugs/121551
<ubotu> New bug: #119113 in xorg (main) "movies play in blue color" [Low,New]  https://launchpad.net/bugs/119113
<mvo__> bryce: hello! did you start with the whitelist that is described in BulletProofX? I'm currently doing some compiz work and there we are going to need a whitelist too
<mvo__> and I was wondering if you started with one already :)
<bryce> hi mvo
<bryce> mvo, I haven't, but I'd love to share a whitelist
<mvo__> bryce: ok, I will think about it a bit and see what I can come up with (+ read the spec again to see if there are more details in it)
<bryce> one thing I'm not sure about is how to get PCI ID's?
<bryce> they don't appear to be listed in lspci (I tried a handful of opts)
<bryce> one other thing I've wondered about is if there's a way we can handle classes of hardware
<ubotu> New bug: #95956 in linux-restricted-modules-2.6.20 (restricted) "Nvidia module disappears after reboot" [Undecided,Incomplete]  https://launchpad.net/bugs/95956
#ubuntu-x 2007-06-22
<ubotu> New bug: #116628 in xorg-server "Sometimes X failed to start the gdm launching window and halt,[Ubuntu 7.04]  (dup-of: 117892)" [Undecided,Incomplete]  https://launchpad.net/bugs/116628
<ubotu> New bug: #121662 in xorg (main) "xorg crash playing video in alternative desktop" [Undecided,New]  https://launchpad.net/bugs/121662
<ubotu> New bug: #121683 in xorg (main) "Font DPI in Gnome wrong in Gutsy on MacBook" [Undecided,New]  https://launchpad.net/bugs/121683
<ubotu> New bug: #8502 in glibc (main) "Please drop UTF-8@euro locales" [Medium,Fix released]  https://launchpad.net/bugs/8502
<mvo> bryce: could you please check if glxinfo works for you in a vesa driver session? it seems to kill my xsession here and I wonder if that is just my local setup
<seb128> mvo: what videocard do you have?
<seb128> mvo: do you have a binary driver diverting libGL installed?
<mvo> seb128: r200 ati, but I set it to vesa to test this new compiz-by-default stuff
<seb128> if that's case, does it happen without it?
<mvo> let me check
<seb128> I've seen some glxinfo crashes to libGL from closed source drivers when cleaning some bugs previous cycle
<mvo> it kills my session at once
<mvo> pretty amazing
<mvo> eh, what would be the best way to detect the currently used driver under X? 
<jcristau> grep drivers /proc/$(pidof X)/maps? :)
<bryce> mvo, ahh, yes there is a report on that from Marc.  I checked it on two of my systems with vesa, but it did not crash X
<bryce> mvo, however I found an upstream bug report on it
<mvo> bryce: cool, can you give me a url ? I want to subscribe :)
<mvo> bryce: do you have a opinion on howto detect the current runing driver? displayconfig is too clever it seems and just gives me the recommended driver currently 
<mvo> there must be a easier way (I think?)
<bryce> sure
<bryce> bug 119341
<ubotu> Launchpad bug 119341 in xorg-server "glxinfo command causes Xorg to abort on Dimension E520" [Unknown,Confirmed]  https://launchpad.net/bugs/119341
<mvo> bryce: thanks! any idea about the "current-driver-decetion"? I may go with the earlier suggestion of /proc/`pidof X`/maps
<bryce> that is the only way I know of to do it
<bryce> I have an email thread from Xorg I can send where that was discussed; I think they suggested a permutation on that
<bryce> http://lists.freedesktop.org/archives/xorg/2007-June/025251.html
<bryce> yeah here it is:  cat /proc/`pidof Xorg`/smaps | grep _dri.so
<mvo> bryce: ok, thanks
<bryce> btw, I think I also sorted out some ideas on pciids and whitelisting
<bryce> lspci -nn displays the pciids
<bryce> the master list of pciids is at http://pci-ids.ucw.cz/iii/?p=%2A
<bryce> the ids are composed of $VENDOR:$MODEL
<bryce> also in general the MODEL numbers are incremental
<bryce> so we can definitely check ranges of ids, like for $VENDOR==1002 && $MODEL<1234
<bryce> mvo or seb128, I've got a new xserver-xorg-video-nv ready for upload; would one of you mind reviewing and sponsoring it for me?  http://people.ubuntu.com/~bryce/Uploads/
<mvo> bryce: I need to do some shopping now, but I could do that in ~2h (unless seb beats me to it :)
<bryce> that'd be cool :-)
<mvo> ok, see you in a bit
<ubotu> New bug: #121792 in xserver-xorg-input-evdev (main) "evdev not working with multiple X instances" [Undecided,New]  https://launchpad.net/bugs/121792
<pwnguin> hi; I'm thinking of adding a feature to nv-- is it dead? I dont see any serious changes in some time
<bryce> the -nv driver?  in fact I'm just about to upload a new version of it
<bryce> http://people.ubuntu.com/~bryce/Uploads/
<bryce> the 2.1.0 nv driver was just released a few days ago
<pwnguin> oh heh
<bryce> pwnguin: so yeah, if you have new features, that'd be great to get them in :-)
<pwnguin> i dont have the code written yet
<pwnguin> it doesnt look like it would be hard, but i think i'd have to get the "open source" details right
<pwnguin> and then test
* bryce nods
<pwnguin> basically, nv doesnt offer a rotate 180 option
<bryce> oh yeah getting more of the rotational features correct would be very nice
<pwnguin> i looked at the patch that added xrandr
<pwnguin> it was pretty small
<pwnguin> right now im thinking, grab the build deps and source package for -video-nv
<pwnguin> but im not sure where to save the work im doing
<bryce> ok I can explain about this
<bryce> ok, first, instead of doing apt-get source, I would suggest checking it out from upstream git, like this:
<bryce> git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-nv
<bryce> then go ahead and make your changes locally to that tree
<bryce> when you're done, you can run the command "git diff > mypatch.diff" to create a patch
<bryce> I'd be happy to help you when you get to the point of needing to make the patch
<pwnguin> ok
<bryce> now, another approach would be to use apt-get source to get the tree, and then save a copy of it.  Then later you can use 'diff -u' to identify the changes between the two trees
<bryce> however I think the git approach is better, and will be easier to do
<pwnguin> alrighty then
<pwnguin> the origina xrandr patch was only a few hundred lines of code, so this might be an evening task ;)
<pwnguin> i'd kinda like to test it personally before sending off patches
<bryce> yup
<pwnguin> shoot. looks like i'd have to test on gutsy
#ubuntu-x 2007-06-23
<pwnguin> -/* $XdotOrg: xc/programs/Xserver/hw/xfree86/drivers/nv/nv_driver.c,v 1.13 2005/06/29 15:56:23 alanc Exp $ */
<pwnguin> +/* $XdotOrg: driver/xf86-video-nv/src/nv_driver.c,v 1.18 2005/09/29 21:47:29 aplattner Exp $ */
<pwnguin> ive seen these before, but ive never paid much attention... is there a name for that format that might lead to an explaination?
<pwnguin> bryce: its really looking like this is a ten line patch to fix it
<ubotu> New bug: #121842 in xorg (main) "touchpad scroll field doesn't work after hibernate" [Undecided,New]  https://launchpad.net/bugs/121842
<ubotu> New bug: #44391 in linux-restricted-modules-2.6.15 (restricted) "poor performances in a game (Stepmania) with fglrx 8.24.8 drivers" [Medium,Fix released]  https://launchpad.net/bugs/44391
<ubotu> New bug: #44745 in xorg (main) "xorg.conf.md5sum was not updated" [Medium,Confirmed]  https://launchpad.net/bugs/44745
<ubotu> New bug: #121913 in xserver-xorg-video-ati (main) "xrandr detects only one screen" [Undecided,New]  https://launchpad.net/bugs/121913
<bryce> pwnguin: yeah those "$var: ...$" bits are tags that get automagically filled in by the revision control system
<pwnguin> ok
<bryce> (i.e., don't worry about them)
<bryce> great to hear you can fix it in 10 lines :-)
<pwnguin> heh
<pwnguin> well
<pwnguin> one of those ten lines may cause far more problems
<pwnguin> there's a variable called rotate; i figured set it to 2 and be done, but there's places related to shadow (im not sure what exactly that is)
<pwnguin> bryce: so uh, how does one build that git tree?
<ubotu> New bug: #121574 in xorg (main) "Open source nv X crashes whenever applications use gl" [Undecided,Incomplete]  https://launchpad.net/bugs/121574
<bryce> pwnguin: lemme take a peek
<bryce> try this:  ./autogen.sh && ./configure && make
<pwnguin> autogen seemed to fail on my feisty desktop
<bryce> what was the error?
<pwnguin> some problem with an env variable i dont recall offhand; im redoing it in gutsy
<bryce> ok cool
<pwnguin> i donno if it matters, but i grabbed the build-dep for the nv package, and i still need autotools, aclocal, and probably more
<bryce> yup
<bryce> I have a command sequence that installs a bunch of generally useful build stuff
<bryce> apt-get install bzr pbuilder revu-tools devscripts-el devscripts dput build-essential fakeroot lintian dpatch
<bryce> most of that is for packaging; I think the build-essential will pull in autotools
<pwnguin> it doesnt
<bryce> oh, hmm
<pwnguin> configure.ac:38: error: possibly undefined macro: AC_DISABLE_STATIC If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
<pwnguin> configure.ac:39: error: possibly undefined macro: AC_PROG_LIBTOOL
<pwnguin> autoreconf: /usr/bin/autoconf failed with exit status: 1
<bryce> well, apt-get install libtool should take care of that
<bryce> however I'm surprised that didn't get pulled in when you did apt-get build-dep xserver-xorg-video-nv
#ubuntu-x 2007-06-24
<pwnguin> ive also found some undocumented options to the driver, but i guess that's for another patch ;)
<bryce> hehe
<bryce> bbiab; going to do some work out in the woodshop
#ubuntu-x 2008-06-16
<pwnguin> well ive assumed it was on the way, but i never saw any actual blueprint or anything for it
<Q-FUNK> hmm... I just noticed:  actually, briceg's package for -nsc doesn't intorduce the -dbg package.  for everything else, yes, his package supercedes what we have in intrepid.
<tseliot> tjaalton: please try my PPA when you can. I have fixed the bugs reported by superm1. There's no hurry though.
<tjaalton> tseliot: ok, I'll check them out tomorrow when I'm back home. GPRS is too slow ;)
<unggnu> hi all
<unggnu> I guess -intel driver 2.3.1 doesn't make it as a backport to Hardy?
<tseliot> ï»¿tjaalton: ok ;)
<unggnu> So I can close a bug as Fixed released if it is fixed in Intrepid and post the link to the 2.3.1 driver for Hardy from bryce?
<Q-FUNK> tjaalton: would you have time to look at bug #240349 ?
<ubottu> Launchpad bug 240349 in xserver-xorg-video-geode "Please sync xserver-xorg-video-geode 2.10.0-1 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/240349
<Q-FUNK> and ï»¿bug #240345   - for this one, I just noticed that bgoglin's package doens't have the -dbg target which mine has.
<ubottu> Launchpad bug 240345 in xserver-xorg-video-nsc "Please sync xserver-xorg-video-nsc 1:2.8.3-3 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/240345
<m-c> Is there an Ubuntu package that I can try the open source AMD/ATI drivers that are being developed based on the recently released specifications?
<m-c> Or are these already used by default, when the Restricted Drivers are disabled?
<m-c> And is there a chat channel or web forum with more information and with links to the latest drivers?
<tjaalton> Q-FUNK: done
<Q-FUNK> tjaalton: thanks!
<tjaalton> m-c: it's used by default, yes
<m-c> I am going to try and use a more up-to-date version 1.2.1 - because there are problems, like colors of pictures and fonts, with the default settings.
<m-c> Following this guide >> http://www.phoronix.com/forums/showthread.php?s=e6059bf57a04b2327f00af4663511407&t=9951
<m-c> The release notes say that my card - RV635 - is specifically targeted in the 1.2.1 release
<m-c> Anyway, I purchased an AMD card yesterday just to participate with these driver developments.  Great to see a open 3D solution available with off the shelf, consumer graphic cards.
<Q-FUNK> m-c: which PCI ID does the card have?
<tjaalton> m-c: that's the radeonhd-driver
<tjaalton> the one used by default is -ati
<tjaalton> and a new version was recently released (6.8.191)
<m-c> Q-FUNK: This should be everything about the card, fyi:  http://pastebin.com/d7f697513
<Q-FUNK> ok, so it's still counted as an ATI product.  excellent.
<m-c> I like to say AMD video card, because I am reluctant to give ATI credit for the exciting release of the open graphic specifications.  ;)
<m-c> Thanks for your thought, off to test the new driver.
<Q-FUNK> tjaalton: http://forum.ubuntu-fi.org/index.php?topic=12898.msg102216#msg102216
<Q-FUNK> tjaalton: days like these, I cannot help but laugh
<m-c> Hi - I do not really understand the process involved with making changes to the xorg.conf , while still relying primarily on the Ubuntu configuration tools.
<m-c> In my situation, I am happy with the automagically generated configuration, but I want to add a Virtual display mode, to support dual monitors.
<m-c> When I add this line to xorg.conf - the xserver hiccups.  Is there a way to add functionality for dual screens with the Ubuntu toolset?
<m-c> Is editing the xorg.conf still the recommended way to get this type of functionality, or is this not compatible with using the Ubuntu tools
 * m-c reads the wiki.
<m-c> Thanks - the wiki had the details on setting dual screens.
<m-c> receiving errors from glxinfo that /usr/lib/dri/swrast_dri.so is missing (and it is).  Should this library be within the " libgl1-mesa-dri " Ubuntu package?
<m-c> ... or any ideas what swrast means?  :)
<bryce> (I put out a new -psb this morning, to ume ppa)
<bryce> m-c: https://wiki.ubuntu.com/XorgOnTheEdge
<m-c> Yes, a good resource, thank you
<m-c> I think I have this figured out.  Means the driver is failing to a software rendering library.
<robert_> does anyone know when the xserver on ubuntu will be updated to version 1.5 with x86_64 support ? it's to complex for me to build, but i would like to get DRI working. i googled and found that fedora released a pre-release version 1.5 http://fedoraproject.org/wiki/Features/XserverOnePointFive
<bryce> robert_: we're waiting on a dependency or two, but expect it should be ready within a week or two
<robert_> thanks that sounds great (within a week or two)
<bryce> well, don't quote me, that's an optimistic guess
<robert_> yes i know those optimistic guesses, i don't quote only emphasis :D  i hope the radeonhd driver will be working too in a week or two :D
<bryce> why do you use radeonhd rather than -ati?
<robert_> hmm do you think it would be better to use the fglrx or ati drivers?
<bryce> well, ati has been making tons of improvements, and I'm hoping by Intrepid's release to have it good enough for most every usage.  
<robert_> i tested the fglrx driver with my Radeon HD 3650 (RV635) and i get black flicker while starting opengl
<bryce> I know there's cases where newer cards aren't supported by -ati, but am curious if there are any other reasons, so we can try to get those situations addressed
<bryce> -ati from git has support for RV635, so maybe in the next -ati upload we do, that will become an option
<bryce> if you're up for building -ati from git, I'd be interested in hearing your opinion on it with your card
<robert_> what is -ati ? is that a package or the propri driver from ati?
<robert_> do you mean http://wiki.cchtml.com/index.php/Ubuntu_Installation_Guide
<bryce> -ati aka -radeon, the standard open source driver for ATI cards
<bryce> not -fglrx, which is what http://wiki.cchtml.com/index.php/Ubuntu_Installation_Guide talks about
<robert_> git which builds xserver-xorg-video-ati?
<m-c> Sounds like the resolution to my issues is also a newer version of xserver.  This is arriving soon?  Great.
<m-c> I just picked up the same card as robert.  :)
#ubuntu-x 2008-06-17
<bryce> git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
<Q-FUNK> bryce: howdy
<bryce> heya
<Q-FUNK> bryce: for intrepid, simply syncing -nsc and -geode from debian should do it.  since tonight, we have what we need there.
<Q-FUNK> (as long as intrepid's -video-all depends on geode, instead of amd)
<Q-FUNK> fixing hardy still remains an issue.
<Q-FUNK> my PPA has backports in the build queue, but getting them admitted as SRU might be an issue.
<mvo> tjaalton: do you have any snapshot of current drm/mesa? I was told it supports r500 now pretty well and I'm curious to try it
<tjaalton> mvo: no I haven't managed to package those yet, but promised to have a look later today
<mvo> ok, cool
<tjaalton> actually, debian-experimental has drm-snapshot, and mesa 7.1rc1 if you are impatient ;)
<mvo> hm, that sounds promising
<tjaalton> I've got xorg-server halfway done, but it requires the new mesa which in turn requires newer drm..
<mvo> where do you usually put that stuff, in your ppa? or is there a x-force ppa?
<tjaalton> mvo: both exist, but so far I've just uploaded to the distribution. this time might be different though, since the new stable drm (which should be enough for r5xx) is not released yet etc
<tjaalton> hum, maybe I should by upgrading my other laptop to intrepid
<tjaalton> +start
<tjaalton> ouch, 1h40min
<tseliot> ï»¿tjaalton: did you try the driver?
<tjaalton> tseliot: no, not yet
<tjaalton> tseliot: where was it again?
<mvo> tjaalton: if you do that, make sure to install findutils first before you do the upgrade
<mvo> (install/upgrade findutils)
<tjaalton> mvo: oh, thanks for the hint :)
<tseliot> tjaalton: the PPA is here: https://launchpad.net/~lrm-intrepid/+archive
<mvo> (bug #234345
<ubottu> Launchpad bug 234345 in findutils "xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Critical,Confirmed] https://launchpad.net/bugs/234345
<tjaalton> mvo: oh that one..
<mvo> yeah, we have a workaround but its not yet in intrepid
<tjaalton> tseliot: hmm, misleading team name, since nvidia is not in lrm anymore :)
<tseliot> ï»¿tjaalton: its name will remind us of the good old times :-P
<tjaalton> tseliot: the diff looks strange. the whole changelog should be there, right?
<tjaalton> oh, sorry..
<tjaalton> debian.binary
<tseliot> Mario says that it works for him
<tjaalton> cool
<tjaalton> the resulting nvidia-glx doesn't seemt to have an epoch, so what about if you should upgrade the old package which had an epoch?
<tjaalton> hmm, maybe I missed something
<tjaalton> yep, they are there
<tseliot> the current package is epoched
<tseliot> have a look at the debian/rules
<tjaalton> yes, saw that
<tjaalton> I have to try it on my home desktop, since the test machine at work is not powered on
<tjaalton> and that needs to wait a couple of hours due to a birthday party :/
<tjaalton> so, ->
<tseliot> ok
<bdmurray> tjaalton: it looks to me like bug 185311 might be fixed in debian and I've just added that bug watch
<ubottu> Launchpad bug 185311 in libxcb "hardy, locking assertion failure, xorg/libsdl" [High,Confirmed] https://launchpad.net/bugs/185311
<pwnguin> tjaalton: should I close bug #236696?
<ubottu> Launchpad bug 236696 in wacom-tools "Please merge wacom-tools from latest Debian unstable" [Undecided,New] https://launchpad.net/bugs/236696
<tjaalton> bdmurray: yes, it should be closed. sloppy locking was on by default already on hardy, but somehow that bug went unnoticed..
<tjaalton> pwnguin: sure go ahead, I forgot to add the bug closure
<tjaalton> bdmurray: umm ok, I've actually forwarded that one upstream, and they've made a set of patches which would make libxcb to never use locking, but it's not applied to master yet
<tjaalton> but sloppy locking should work in the meantime
<bdmurray> tjaalton: okay, any there any test packages available?
<tjaalton> bdmurray: not that I know of..
<tjaalton> bdmurray: just to be clear; seems that sloppy locking doesn't work around every situation, since people still seem to get them with certain apps
<pwnguin> hence the term sloppy...
<tjaalton> heh, right
<bryce> heya
<tjaalton> hey bryce 
<bryce> tjaalton: hey btw what is the reason for removing lesstif-dev as a dependency for mesa, vs. MIRing lesstif to main?
<pwnguin> hmm. its not good when the kernel guys are happy that their build fails
<bryce> (I just want to make sure the rationale is listed in the changelog)
<tjaalton> bryce: lesstif isn't wanted in main..
<bryce> tjaalton: just because it's ugly&big, or other reasons?
<tjaalton> security risk of some sort I guess
<tjaalton> well, "risk" meaning "work"
<bryce> ok cool
<pwnguin> http://www.ohloh.net/projects/273
<pwnguin> "small team"
<bryce> kees: offhand do you know what the security concerns are around lesstif?  (If not, that's fine, I'll just list it as 'security concerns' for now)
<bryce> heya pwnguin
<bryce> pwnguin: heh.  of course, such could be said about nearly any of the X11 libs ;-)
<bryce> tjaalton: also, are the GLw libs disabled in mesa due to lesstif-dev dependence, or are there other reasons?
<pwnguin> the last release of lesstif was 2 years ago
<tjaalton> bryce: because of that
<kees> bryce: off hand, it's just that it's a large code base without much active development
<bryce> excellent, thanks everyone
<bryce>     - Drop lesstif-dev from Build-Depends since it's a universe component
<bryce>       that Ubuntu doesn't want in main due to security concerns about it
<bryce>       (it's a large codebase without active development - last release >2
<bryce>       yrs ago).
<tjaalton> bryce: merging mesa? I'm weeding out all the unnecessary patches from xserver 1.5.. gonna take a while
<bryce> ok
<bryce> yeah I'm not merging new mesa, just updating us to debian
<bryce> I might have a go at updating xorg after that.  Was looking at it last night.
<tormod> it's a lot of fun all of these mesa/xserver changes... :) I pushed the xorg-edgers repo to 7.1RC and 1.5, but gave up xserver master for a while.
<tormod> and now launchpad went down some seconds before the 45minutes mesa build finished... wonder if it's "frozen" or must be restarted
#ubuntu-x 2008-06-18
<bryce> yep, mesa is mucha fun
<tjaalton> ok, xserver 1.5 should be looking better. many patches deleted, some need forwarding upstream and some need to be forward ported
<tjaalton> umm, getting late. I'll push this tomorrow
<tjaalton> night ->
<bryce> great
<bryce> mesa seems to not be building on amd64 (some pbuilder issue) but looks like it's ok on i386 so far.  I'll push it once it's finished building.
<bryce> mesa's pushed.
<bryce> tjaalton: I've also gone through a preliminary merge for xorg; I'd appreciate a review if you wouldn't mind:  http://people.ubuntu.com/~bryce/Testing/xorg/
<tjaalton> bryce: sure
<tjaalton> bryce: fwiw, I think xfonts-utils could've been synced, since the changes were meant for dapper->hardy upgrades
<tjaalton> same goes to -vmware, a proper fix has been applied upstream :)
<tjaalton> bryce: xorg; I think the x11r6_bin_not_empty_move change can be deleted from templates and preinst
<tjaalton> bryce: is this targeted for 1.5?
<bryce> tjaalton: ah, that wasn't clear to me from the xfonts-utils changelog.  I did notice -vmware is syncable and will do that later
<tjaalton> bryce: sure, great
<tjaalton> xorg; radeonhd should already be in included in video-all
<tjaalton> and x11-common/xserver-xorg change actually reverts the change done in debian
<tjaalton> which is to move stuff from xserver-xorg to x11-common
<bryce> both of those are things I'm curious and not sure about
<tjaalton> hmm let me check that
<tjaalton> radeonhd is listed already though
<bryce> ok
<tjaalton> rules; it should be x11-common instead of xserver-xorg
<bryce> so what should I change?
<tjaalton> leave them as they are in debian?-)
<bryce> uh, but in this latest set of changes debian is moving them back from x11-common to xserver-xorg
<tjaalton> hmm, I don't understand.. I'm looking at the current debian version and the initscript and stuff are in x11-common
<tjaalton> my mistake that I thought there was an actual change in debian. seems that not much has moved
<tjaalton> debconf has, but not the initscript or Xsession etc
<tjaalton> uh, dexconf
<bryce> 'X' as well
<tjaalton> right
<bryce> what I'm unsure of is what this implies for some of the ubuntu-specific changes relating to x11-common
<tjaalton> like the apport script and failsafe?
<bryce> right, and "Add a dependency to xserver-xorg for each binary built to save disk/livecd space."
<tjaalton> that's because we only ship one set of docs
<tjaalton> and the rest is symlinked
<bryce> right, and I changed the paths from .../x11-common/... to .../xorg-server/... - but is that correct?
<tjaalton> xserver-xorg-driver-all could be dropped
<tjaalton> why should those be moved?
<bryce> exactly my question
<tjaalton> hehe
<tjaalton> so, if x11-common is not installed by default then yes, they should be moved
<tjaalton> but it seems that x11-common is installed if you need _any_ of the X libs, so it should be safe to keep them there
<tjaalton> ie. it has many reverse-dependencies, so keeping the changelog etc in x11-common is a safer bet
<bryce> ok
<tjaalton> xserver-xorg is only installed if you have X installed
<tjaalton> btw, there's -12 which has openchrome
<tjaalton> and didn't q-funk want to drop amd from the deps?
<bryce> ah, didn't see -12 yet
<tjaalton> it was released last night :)
<bryce> yeah, I need to doublecheck the amd stuff
<tjaalton> you'll keep the BPX stuff for the time being?
 * bryce nods
<bryce> probably not much longer though.
<bryce> maybe I should chat with Colin about it when we get together in London first.
<tjaalton> ok, so if you plan on moving it, xserver-xorg should C/R x11-common
<tjaalton> but if it gets dropped, maybe keep in x11-common until you come up with a plan
<tjaalton> colin hasn't replied to the hal-script post.. maybe you'll manage to hack it so it actually works :)
<bryce> you might re-email him on that; he recently had a death in the family and was gone for a week and probably fell far behind in email
<tjaalton> oh right.. :/
<tjaalton> when is the sprint scheduled?
<bryce> Jul 14-18
<tjaalton> ok
<tjaalton> I might re-email after I get back on Jun 29th
<tjaalton> after tomorrow I'll be mostly offline, but will check email & irc almost daily
<tjaalton> yay for 3G
<bryce> :-)
<tjaalton> (well, GPRS on rural areas..)
<bryce> think xserver 1.5 can be put in by then?
<tjaalton> it might get released next week, so when I get back things should be in good shape
<tjaalton> regarding mesa & drm too
<bryce> is there more I could do to prep the way for it?
<bryce> Otherwise, I guess now that packaging is pretty much caught up, I'll go back to focusing on -ati bugs a while.
<tjaalton> hmm, I think that the components are still in state of flux, so concentrating on bugwork for a week or two might pay off
<tjaalton> btw, there's a new ati that probably should be merged/synced
<tjaalton> "should be" meaning that it apparently fixes a ton of bugs
<bryce> ok, I'll look at getting that merged in
<bryce> I also really need to get my auto-git builder for -intel (and -ati) up and running
<bryce> maybe I can finally get that going :-)
<tjaalton> heh
<tjaalton> hum, should be enough to sync -ati from experimental. we have no changes
<tjaalton> Q-FUNK: 146_X86EMU-added-blacklist-for-I-O-port-in-0-0xFF-range.patch is not applied upstream and does not even apply on 1.5, so what should we do about it?
<tjaalton> (xorg-server)
<Q-FUNK> tjaalton: they eventually reverted the change and applied a more complex one to match GX2 and LX hardware specifically.
<Q-FUNK> oh... wait.  blacklist
<Q-FUNK> yes, they rejected blacklist.
<Q-FUNK> http://www.x.org/wiki/AMDGeodeDriver
<Q-FUNK> they accepted only 2 out of 3 patches
<tjaalton> ok, so it can be dropped?
<Q-FUNK> yes
<tjaalton> cool
<cody-somerville> Hey
<cody-somerville> Can someone please help me with bug #232122 ?
<ubottu> Launchpad bug 232122 in xfce4 "xfce4 hangs when tried to login again. (dup-of: 232364)" [Undecided,Confirmed] https://launchpad.net/bugs/232122
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed] https://launchpad.net/bugs/232364
<cody-somerville> Or more specifically, bug #232364
<cody-somerville> libxcb hangs waiting on the bilateral socket with X
<cody-somerville> It only occurs intermittently though
<tjaalton> cody-somerville: sounds hairy.. maybe ask the xcb devs?
<cody-somerville> : (
<tjaalton> joy, nvidia dropped support for GF5 from 177.xx
<tseliot> ï»¿tjaalton: Kano told me that there are *only* these flavours:
<tseliot> ï»¿VER_LEGACY_1=71.86.04
<tseliot> # DX7 cards since gf2mx and all DX8 cards
<tseliot> VER_LEGACY_2=96.43.05
<tseliot> # GeForce 5 series
<tseliot> VER_LEGACY_3=173.14.09
<tseliot> and latest is 177.13 which supports the gtx 260/280
<tseliot> tjaalton; I would like to package all the remaining flavours today. I will use our new package as a base rather than waiting for Debian to adopt the latest flavour too
<tseliot> ï»¿tjaalton; objections?
<tjaalton> tseliot: no, go ahead
<tseliot> tjaalton: ok, the new flavour will be nvidia-graphics-drivers-legacy-173xx
<tseliot> (we can change this later)
#ubuntu-x 2008-06-19
<Q-FUNK> how do we solve the nsc+geode situation on Hardy?
<Q-FUNK> I have yet another user confirming that the only way to get this to work on LTSP is to purge the transitional package that contains the symbolic links between geode_drv.so and amd_drv.so
<Q-FUNK> this essentialy requires backporting what I have in my PPA for xserver-xorg-core, -geode and -nsc
<sebner> heya guys. A nvidia update (2.6.26 support) planned in the near future?
<Q-FUNK> is 2.6.26 even out yet?
<Q-FUNK> last night, it was still RC
<sebner> Q-FUNK: so we wait until the final kernel is out?
<tseliot> sebner: an update for the driver in Intrepid or in Hardy?
<sebner> tseliot: intrepid. since the new kernel 2.6.26(rc) is in intrepid only ;)
<tseliot> sebner: I'm working on it
<tseliot> we'll have 4 flavours for the NVIDIA driver
<tseliot> and the lrm will be removed
<sebner> tseliot: great. only the newest has 2.6.26 support I heard. any estimated time?
<tseliot> ï»¿sebner: I've got patches for the other flavours for kernel 2.6.26. I have to make sure that the upgrade from Hardy to Intrepid doesn't cause problems, therefore I'll have to test the new packages carefully
<sebner> tseliot: I see. Thanks for the info =)
<tseliot> the packages, apart from the debian/control files are complete
<sebner> tseliot: Ah cool, you are alberto milone. Didn't know that =) Also used envy. great work!
<tseliot> yes, it's me ;)
<bryce> tjaalton: btw DebianImportFreeze is coming up 1 week from now
<tjaalton> bryce: hi! yes I noticed. that only means more manual labor for us :)
<tjaalton> bryce: btw, I pushed the xorg-server merge yesterday. I dropped some patches that we had for no apparent reason, but we can dissect those again before we upload
<bryce> tjaalton: excellent
<bryce> tjaalton: fortunately we're all caught up with merges except for xorg and xorg-server
<bryce> oh and a new -intel
<tjaalton> yeah
<bryce> do we need to do anything special with -i810 anymore?  e.g. drop something from the archive...?
<tjaalton> drop it...
<tjaalton> the merge is a tad easier after that
<bryce> how do we go about dropping it?
<tjaalton> there should be no reason to keep it any more
<bryce> is there such a thing as a de-MIR?
<pwnguin> heh
<tjaalton> file a bug and subscribe ubuntu-archive
<bryce> ok
<tjaalton> "remove from the archive"
<tjaalton> etc
<tjaalton> (laggy gprs shite)
 * bryce files
<bryce> btw, do we need to do the same for -amd now that -geode is present?
<tjaalton> oh man, this is cool.. listening to the GER-POR from the radio, irc'ing with the laptop and enjoying the bright evening with a carlsberg :P
<tjaalton> *match
<tjaalton> bryce: hum, I'm not sure, q-funk should know better
<bryce> ok
<bryce> what's GER-POR?
<pwnguin> german ... 
<tjaalton> sorry, germany vs. portugal... soccer match :)
<pwnguin> GOAAAAL
<tjaalton> football for us europeans
<tjaalton> ssssh, not yet
<tjaalton> actually, it's 2-1
<pwnguin> so what is the official deal with nvidia on intrepid?
<bryce> ahh
<bryce> pwnguin: hmm?
<tjaalton> pwnguin: it's split from lrm, and held in separate packages
<tjaalton> DKSM
<tjaalton> ftw
<tjaalton> uh
<tjaalton> DKSM..
<tjaalton> wtf
<tjaalton> my eyes hurt me
<tjaalton> was it DKMS?? :)
<pwnguin> sound right
<pwnguin> dell kernel module system
<tseliot> it's DKMS
<tseliot> pwnguin: we have 4 flavours for NVIDIA
<tseliot> and I'm working on them
<tseliot> I have contacted BenC since none of them builds
<pwnguin> did we unwrap modprobe?
<bryce> tjaalton: btw both OOo and Xubuntu are seeing major libxcb-related problems
<bryce> tjaalton: I upstreamed the former; the latter was already upstreamed but it appears the fix for it was incomplete
<bryce> tjaalton: so I'm having them do some re-testing, and then will re-upstream if appropriate
<tseliot> ï»¿pwnguin: I mean, because the kernel is Xen-enabled. BenC will work on that.
<tseliot> ï»¿pwnguin: do you refer to lrm-video?
<pwnguin> Amaranth has a patch
<bryce> lp: #87947, lp #185311, fdo: 16420
<tseliot> ï»¿pwnguin: for what? If it's for Xen, those patches don't work
<ubottu> Launchpad bug 185311 in libxcb "hardy, locking assertion failure, xorg/libsdl" [High,Confirmed] https://launchpad.net/bugs/185311
<tjaalton> tseliot: amaranth had a patch for it.. 
<tjaalton> 03:59 #ubuntu-devel: < Amaranth> tjaalton: with http://www.realistanew.com/random/xen.patch  the 173.14.09 nvidia module will build against the 2.6.26-1  kernel
<pwnguin> tseliot: if theres a bug somewhere, maybe that will be faster than re-explaining evreything to me
<tjaalton> bryce: ok. Maybe try the handoff-patches from March (on xcb-list)
<tseliot> pwnguin: ok, I'll try it now
<tjaalton> don't know if they help or not..
<tjaalton> bryce: with those, it should never fail on locking
<pwnguin> sh: /sbin/lrm-video: not found
<pwnguin> FATAL: Error running install command for nvidia
<bryce> tjaalton: yeah I worked on patching those in yesterday, but they don't apply to our released version, and aren't in git
<bryce> (afaik)
<tjaalton> duh
<bryce> I'll see if calc can validate the debian patch, and if not will see about hammering those patches into libxcb or something
<tjaalton> k, upstream should wake up eventually
<tjaalton> those patches should be merged
<tjaalton> hmm
<tjaalton> there's a tv next door, so maybe I'll go there to see the rest of the match..
<tseliot> ï»¿pwnguin: it's the same patch I had. Sorry but it doesn't work. The patch works in Hardy but it doesn't in Intrepid
<tjaalton> which means that I'll be offline for some time ;)
<tjaalton> see you ->
<bryce> cya tjaalton
<tjaalton> ok, back again :)
<bryce> how'd your team do?
<tjaalton> germany won 3-2, but I didn't really have a favourite
<tjaalton> but I did bet that germany would win the tournament, so..
<tjaalton> hm, time to go to bed. have a nice Midsummer ;) 
<pwnguin> bryce: how would you describe your involvement in inkscape
<pwnguin> ?
<pwnguin> Developer?
<pwnguin> founder?
<bryce> pwnguin: founder
<bryce> pwnguin: I also am fairly involved in organizing releases and qa activities.  I haven't really done much development since joining canonical.
#ubuntu-x 2008-06-20
<pwnguin> bryce: http://jldugger.livejournal.com/7639.html <-- that's why i asked
<bryce> pwnguin: ahh cool
#ubuntu-x 2008-06-21
<pwnguin> tjaalton: you have an opinion on backporting intrepid wacom to LTS?
<pwnguin> or anyone else for that matter
<pwnguin> well at least kees agrees with me
<bryce> pwnguin: I at least wouldn't DISagree ;-)
<pwnguin> cody-somerville: did you ever figure out the process on the other side of the socket?
<cody-somerville> pwnguin, X
<bryce> jcristau, tjaalton: cody and other xubuntu users are seeing a pretty widespread deadlock apparently triggered by a libxcb call in dbus-launch called from the xfce4 scripts.  fdo #16420
<bryce> jcristau, tjaalton: I was hoping you might have some insights or debugging/workaround suggestions
<pwnguin> cody-somerville: what's X up to at that point?
<pwnguin> another select?
<cody-somerville> pwnguin, X is wait4()
<pwnguin> which arguments?
<Q-FUNK> bryce: hiya
<bryce> Q-FUNK: hi
<cody-somerville> pwnguin, I'm not sure
<bryce> Q-FUNK: btw I had a question on if we should remove the -amd source package in intrepid?
<cody-somerville> pwnguin, it just said pwait4() in ...
<cody-somerville> err
<cody-somerville> from, not in
<Q-FUNK> bryce: there's no amd source package.  we only have an -amd transitional package that is provided by -geode.
<bryce> Q-FUNK: ah cool ok
<Q-FUNK> bryce: to my knowledge, everything is now back to normal for Intrepid.  Hardy is what remains unresolved.
<bryce> ok
<Q-FUNK> and unless I'm mistaken, this dragged on long enough that we missed it for hardy.1 already.
<bryce> yep
<bryce> Q-FUNK: do you care to still try to get it in?
<Q-FUNK> we have to. it's an LTS.
<Q-FUNK> and geode is completely broken for the next 5 years, unless we act quickly
<Q-FUNK> well... 3 to 5 years
<bryce> why "quickly" if we've already missed .1 (which I think was effectively missed several weeks ago tbh)
<Q-FUNK> I have sorf-of figured out a way to get hardy users to make this work, but most people are not reading my blog and will simply decide that what used to work in gutsy no longer works, so the hell with ubuntu
<Q-FUNK> it's not for my lack of trying to push this SRU. I was on this issue since even before UDS.
<cody-somerville> There will be another point release
<Q-FUNK> cody-somerville: we all know this.  users won't wait that long.
<Q-FUNK> they'll grab CD #2, install LTSP and notice that it doesn't work for them. 
<Q-FUNK> .1 was a golden opportunity to fix this right after the release.
<Q-FUNK> again, those who are patient enough to google will find my two blog posts on the issue and could fix it.
<cody-somerville> Don't feel bad. Xubuntu users can't login half the time with Hardy. :(
<Q-FUNK> :(
<Q-FUNK> http://q-funk.blogspot.com/2008/06/howto-make-geode-thin-clients-work-on.html
<Q-FUNK> http://q-funk.blogspot.com/2008/06/howto-build-clean-ltsp-boot-image-that.html
<cody-somerville> Q-FUNK, Is your blog on the planet?
<Q-FUNK> no, since I'm not an Ubuntu member.
<Q-FUNK> it's on the debian planet, though
<Q-FUNK> or is an ubuntero a sufficient status to end up on the ubuntu planet?
<cody-somerville> It is limited to Ubuntu Members.
<cody-somerville> However, I'd be happy to blog about your blog :)
<bryce> Q-FUNK: I wish we had taken the time at UDS to sit down and experiment with it.  When I asked about that you seemed pretty optimistic that everything was sorted out, so it's a shame we didn't just prove it and get everything finalized right there and then.
<Q-FUNK> bryce: I really wanted us to sit with ogra and go over this.  ogra was taken 100% by intel sales reps and the rest of us were just jumping from one session to the next.
 * cody-somerville thinks UDS should go back to being longer than a week.
<Q-FUNK> cody-somerville: the sessions are too packed.  there should be plenty of slack between for people to actually hack on the issues they just discussed.
<bryce> Q-FUNK: well if it makes you feel any better, I also feel bad.  I think I put in more energy for -amd during 8.04.1 than I did for any other driver, and I'm disappointed to hear no progress was made
<bryce> anyway, /me -> lunch.  bbiab
<Q-FUNK> bryce: the main issue that prevents 2.9.0-1-ubuntu2.1 from doing what it's intended is that pitti didn't like the idea of backporting the complete solution. he insisted on fitting the framework used for 2.8.0-7.
<Q-FUNK> bryce: yes and it helpped a lot getting the issue heard by Steve and Martin for the SRU
<Q-FUNK> bryce: unfortunately, there's too many bugd and too many SRU to audit, right after the .0 release, and with an UDS to conduct in the midst of it all.
<pwnguin> i have to wonder if ubuntu really has the resources for SRU in practice
<Q-FUNK> I think that the next UDS should be conducted after release+1.1 is done, in the future
<Q-FUNK> pwnguin: it mostly does, but the fact that people who are empowered to review SRU are also canoncal employees going from one plane to the next for their next canonicla event doesn't make this easier.
<Q-FUNK> the same problme happens at debian:  too few people are empowered to review and approve freeze exceptions.
<pwnguin> well i mean, you said the problem was requiring backported patches
<Q-FUNK> and those people usually happen to have several other hats to wear, so their time for any given item is really limitted.
<pwnguin> its a hell of an effort
 * cody-somerville nods.
<Q-FUNK> not if the backport is done and sitting in someone's PPA for weeks.
<Q-FUNK> at that point, all it requires is for someone to review and either ack or nack the backport.
<pwnguin> are we talking about sru or backport here?
<pwnguin> they're different things
<Q-FUNK> both
<Q-FUNK> new upstream and backported package of it from debian, with hardy-specific changes.
<Q-FUNK> SRU for newly suported hardware and important fixes.  backport of the debian packaging, with small changes to compensate for e.g. older dpkg-dev in hardy.
<pwnguin> in related news
<pwnguin> i hate cvs
<Q-FUNK> :)
<Q-FUNK> CVS is showing its age.
<pwnguin> whoever thought independent file versions made sense should be shot
<Q-FUNK> it's a different philosohpy
<Q-FUNK> commit-based, versus file verison based
<pwnguin> well when im trying to see where upstream fixed wacom going crazy bugs
<pwnguin> commit based is what i want
<Q-FUNK> right, thta would be git
<pwnguin> ssh
<pwnguin> you mean bzr ;)
<Q-FUNK> ouch
<Q-FUNK> please gimme my cathedral back!
<pwnguin> ive no allegience to either git or bzr
<pwnguin> but theres a storm a comin
<Q-FUNK> oho
<Q-FUNK> cody-somerville: but, sure, if you wanna blog about the above two posts, please do so :)
<cody-somerville> Q-FUNK, will do :)
<bryce> back
<cody-somerville> wb
<bryce> cody-somerville: I don't know if I got all the deps straight, but I've put together a libx11 with xcb disabled for you.  I'm uploading the debs presently.
<bryce> cody-somerville: they'll be appearing at http://people.ubuntu.com/~bryce/Testing/libx11/
<pwnguin> anyone ever heard of a VTBook?
<pwnguin> its this crazy video card on a PC card
<pwnguin> someone in -laptop went asking about it
<bryce> pwnguin: wild
<pwnguin> http://www.villagetronic.com/ftp/vtbook/Linux/LinuxReadMe.html
<pwnguin> you should forward that to canonical's OEM support salesmen ;)
<bryce> pwnguin: ok, but why?  (I may be dense)
<pwnguin> well, they clearly need help
<pwnguin> the provided driver is a patch to the kernel
<pwnguin> "    *  Fedora Core 1"
<pwnguin>     * Suse 9.1 (Thanks to Gil Spencer for important help)
<bryce> * No kernel patch needed for systems with Kernel 2.6.22 or later
<bryce> but yeah that looks like a painful setup process
<bryce> "    *  Kernel 2.6.10 or newer
<bryce>     Edit the setup-bus.c file in linux-2.6.y/drivers/pci/.
<bryce>     Locate the following definition: #define CARDBUS_MEM_SIZE (32*1024*1024)
<bryce>     Replace it with the following:  #define CARDBUS_MEM_SIZE (128*1024*1024)"
<pwnguin> im checking to see if that's actually in kernel.org right now
<bryce> using the 'trident' driver
<pwnguin> yea
 * bryce loves OEMs that use gfx drivers he has little experience with
<bryce> pwnguin: <wince> yeah I think I'll pass on showing this to the OEM folks ;-) 
<pwnguin> heh
<bryce> although it wouldn't surprise me if with ubuntu it all "just worked" since we have a new enough kernel and it sounds like it works with stock trident and stuff
<pwnguin> i dont own one but ive seen a couple reports of it not just working
<pwnguin> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fe0e5c4d947d34f10002b4cf272f0ebf110305b7
<pwnguin> the commitlog is hilarious at least
<bryce> cody-somerville: hey there's a reply from bart
 * cody-somerville nods.
<cody-somerville> :)
<bryce> ok so like I said in the email I'm starting to think the disable-xcb option is sounding more like the direction we'll need to go, esp. given the mounting evidence and bart's confirmation this pretty much a known issue
<bryce> hopefully over the weekend someone can verify the non-xcb libx11 package I did; if not I'll finish building a xubuntu test rig monday
<bryce> I envision this will be a painful SRU though.
<cody-somerville> Indeed.
<cody-somerville> Can you send off an e-mail to ubuntu-devel and techboard to let them know whats up?
<bryce> sure
<bryce> why techboard?
<cody-somerville> They're supposed to be notified of regressions
<pwnguin> what?
<pwnguin> regressions in what?
<bryce> cody-somerville: "techboard@lists.ubuntu.com" ?
<pwnguin> if techboard is the place to get attention about regressions
<pwnguin> i have some email to send
<cody-somerville> technical-board@lists.ubuntu.com
<bryce> cody-somerville: url for this policy?
<cody-somerville> I'm not looking at it right now
<cody-somerville> but I know they're supposed to be notified of serious regressions
<cody-somerville> and all regressions introduced by SRUs
<pwnguin> microrelease exception?
<pwnguin> https://wiki.ubuntu.com/StableReleaseUpdates
<pwnguin> n the event of a regression, immediately notify the [WWW] Ubuntu Technical Board via email, and ask for help on #ubuntu-devel in making urgent contact with a member of the Board or the SRU team: state the problem, the bug number, and ping "slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, keescook, jdstrand, BenC, dendrobates, davidm". For SRU in universe/multiverse, contact the [WWW] Universe SRU Team team or ask for help on #ubuntu-motu in
<bryce> ahh
<bryce> that doesn't apply in this case - that's for if there is a huge regression due to an SRU release
<bryce> I think that's so people can have a chance to pull the update from the mirrors before it goes out to everyone
<bryce> in this case the issue is already fully deployed
<cody-somerville> I think we should delay the point release
<bryce> cody-somerville: ok I've emailed ubuntu-devel@; you can feel free to forward to techboard and/or request point release delayment as you see fit
<bryce> to be honest, I'd prefer to see my libx11~noxcb package verified first.
<cody-somerville> I'll be sure to test it after I get some sleep :]
<bryce> ok, I'm done too.  have a nice weekend.
#ubuntu-x 2008-06-22
<cody-somerville> bryce, I think I may have found a short term solution for Xubuntu
<cody-somerville> I noticed that gnome-screensaver depends on dbus
<cody-somerville> I had thought that dbus --auto-launch was launched by dbus --sh-syntax --exit-with-session
<cody-somerville> but after reading the man page, I realized that it only occurs when something tries to access dbus and there is no session bus already started
<cody-somerville> So the race is between the two dbus-launch processes, it causes the libxcb problems to rear its teeth.
<jldugger> so throw in a sleep() call ;)
<jldugger> that always fixes race conditions!
<cody-somerville> :D
<cody-somerville> jldugger, I figure I'll just start dbus-launch before gnome-screensaver :)
<cody-somerville> Anyhow, I'm going to go restart X a few more million times to make sure that by commenting out the gnome-screensaver start I've stopped the hangs.
 * cody-somerville waves.
<jldugger> i think i found another xcb casulty
<jldugger> https://bugs.edge.launchpad.net/ubuntu/+source/liferea/+bug/203157
<ubottu> Launchpad bug 203157 in liferea "Liferea uses a lot of CPU at times" [Medium,Confirmed] 
<jldugger> cody-somerville, what did you file that dbus-launch against?
<unggnu> hi all
<unggnu> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/211897
<ubottu> Launchpad bug 211897 in xserver-xorg-video-intel "Xorg crashed with SIGSEGV in xf86RandR12SetRotations()" [Medium,Incomplete] 
<unggnu> It should be marked as wishlist or won't fix and if the first one it should be marked for reporting upstream. Btw. isn't it a Xorg bug?
#ubuntu-x 2009-06-15
<Sarvatt> sheesh, device detection in drivers is such a mess
<Sarvatt> apw: new nouveau kernel isnt working for me :(
<Sarvatt> [   79.549480] nouveau 0000:05:00.0: display fifo hung :(
<Sarvatt> [   79.565710] nouveau 0000:05:00.0: nouveau_fifo_free: freeing fifo 2
<Sarvatt> [   82.565011] [TTM] GPU lockup dectected on engine 2 fence type 0x00000001
<Sarvatt> [   82.566471] nouveau 0000:05:00.0: PFIFO_CACHE_ERROR - Ch 2/7 Mthd 0x1ffc Data 0xffffffff
<Sarvatt> then a few thousand lines repeating :D
<Sarvatt> oh i see, want calling nouveau.modeset=1 for that kernel. guess you cant use it any other what than in KMS with the kernel option :D
<hyperair> hmm i wonder how well geforce4 mx support is in nouveau at the moment O_O
<Sarvatt> looks like it supports every mx :D
<Sarvatt> ugh, wasn't thinking, apw's kms kernel is versioned higher than 9.10 so alot of ati people on karmic probably just got a rude awakening to a non working setup since we dont have the drm for it
<hyperair> Sarvatt: no 3d =(
<Sarvatt> theres 3d!
<hyperair> there is?
<hyperair> but not for the lower models, right?
<Sarvatt> as long as you dont mind glxinfo being the only thing you can run lol
<hyperair> at least the nouveau status matrix didn't show any 3d support at all O_o
<Sarvatt> ahh not sure
<hyperair> bah!
<hyperair> i'll be staying with my old outdated blob for the time being then
<hyperair> no KMS for my desktop =(
<crevette> superm1, hey, I seen bluez has udev manager now http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=03971a2d726bc9a8630b2419508235a2920eb19f
<crevette> thanks for pushing this uptream
<superm1> crevette, yeah, as soon as the udev rules show up to match it, we should be in the clear
<crevette> "in the clear"?
<superm1> ready to disable the init script and switch to ondemand
<crevette> superm1, I don't see any code that hook on udev, so I think the udev rules to start blutoothd is still necessary, but for stopping bluetoothd will stop by itw own
<superm1> crevette, right i'm saying the init script would go away from rc.d
<crevette> superm1, ah you would be extremist ? :)
<crevette> you're true, karmic is for testing so let's test :)
<bryce> morning
<jbarnes> bryce: hi
<Ng> bryce: when's the switch to kms on by default? :D
<bryce> Ng: the kernel team is working on it; iirc they need to implement a whitelist/blacklist before switching it on.  apw may have more info
<Ng> I say switch it on now and start collecting machines for the blacklist ;)
<Ng> but I can say that because a) nobody will whine at me, b) it works for me ;)
<Ng> my laptop has been up for a week now and apart from a couple of userspace things, I'm having a great time
<Ng> at least two suspend/resume cycles a day, no X borkage or kernel borkage that I've noticed
 * hyperair has black screens caused by gnome-screensaver
<tjaalton> it was pain to use 2.6.28 on karmic, because 3g is broken on .30 :)
<bryce> yeah it's quite solid on -intel for me as well.  we've had a few kms bugs in launchpad, but they're either solved now or nothing earth shattering
<tjaalton> it doesn't work too well with the intel snapshot
<bryce> but the blacklist/whitelist stuff is more for catching ! -intel cases
<Ng> hyperair: where it suddenly switches the display off with dpms until you poke a key? I was wondering if that was g-p-m, but either way I'm seeing that
<bryce> so we don't try to do kms on e.g. -nvidia, until it supports it
<hyperair> Ng: that's another bug.
<hyperair> Ng: the one i'm talking about is if close the lid, wait some time, then open it again, the screen won't come back on
<Ng> hyperair: it is, but upstream think it's fixed in gpm 2.27.2
<hyperair> no matter what you do
<Ng> hyperair: ah
<bryce> (xkeyboard-config 1.6 merge uploaded)
<hyperair> +you
<hyperair> Ng: it also happens if i close the lid faster than my notebook can suspend
<apw> bryce, i wanted to check with you that my memory was correct, that the requied X bits to cope with and without KMS are enabled in karmic by default
<Ng> hyperair: ouch. are you sure that's gnome-screensaver's fault? it shouldn't be doing screen on/off stuff, should it?
<hyperair> Ng: i'm really really not sure, but someone on #intel-gfx said so
<Ng> hyperair: I won't pretend to know more than them ;)
<hyperair> Ng: he had slightly different symptoms.. i think just locking the screen for some time would trigger it
<hyperair> Ng: and i'm not willing to try just yet =p
<Ng> heh
<hyperair> ssh works
<hyperair> but you can't chvt or anything
<james_w> <-- one more satisfied KMS user
<bryce> apw: yes should be good to go.  Only -intel will do kms so far, so if you have a whitelist, that's the only one to be whitelisted.  
<apw> no lists right now, just want to make sure that making the default kernel turn it on, and all my combo kernels the same, that userspace will work
<apw> at least for intel
<bryce> yes, there's no other changes on the X side we need for -intel for kms
<bryce> erf, horrible grammar.  hope that made sense.
<Ng> so it should be on for intel for alpha3?
<bryce> Ng: yes
<Ng> \o/
<Ng> I'll test 855GM shortly after that is published :)
<hyperair> bryce: speaking of KMS stuff, are you noticing KMS spitting flames with usplash?
<hyperair> i find it especially fun to stare at a blank screen for 20 odd minutes while waiting for my fsck to complete
<hyperair> starting from when i915 is loaded, ending when X is started
<bryce> hyperair: no I hadn't noticed that
<hyperair> hmm
<hyperair> how strange =\
<maco> hola. there was a wiki page for UXA testing where the graphics chips were laid out in a table and comments could be added. any intention of doing that again but for KMS?
<bryce> maco -> https://wiki.ubuntu.com/X/KernelModeSetting
<maco> bryce, ahead of me as usual....thanks
<Sarvatt> hyperair: got a dmesg handy?
<hyperair> Sarvatt: for the black screen thing?
<Sarvatt> yep
<hyperair> i don't remember seeing anything in dmesg
<hyperair> lemme go poke my syslog
<hyperair> hmm nothing
<hyperair> lemme try reproduce the bug
<Sarvatt> can I see it anyway even if theres no error? :D
<Sarvatt> want to see the order of things and whats getting loaded in your case
<hyperair> Sarvatt: strange, i can't reproduce it any more O_o
<Sarvatt> i'll build you a new gnome-power-manager in a few minutes if you want, it wasnt updated for a long time there so ya got me to look and see it needed to be updated :) i dont see anything since karmic's that would fix your lid problem though
<hyperair> Sarvatt: wait, are we talking about the gnome screensaver one or the usplash one
<Sarvatt> usplash
<hyperair> aah
<Sarvatt> i've been having to build that myself since i need hal enabled in it for things to work right on all my machines
<Sarvatt> (g-p-m)
<hyperair> i see
<hyperair> Sarvatt: anyway i'm not very concerned about the lid problem, since it's mostly intermittent and doesn't occur most of the time
<hyperair> Sarvatt: the usplash bit.. i'm pasting by dmesg, but looks like pastebinit's taking some time O_o
<hyperair> http://pastebin.com/f4639d2c5
<hyperair> there we go
<hyperair> don't mind the whole bunch of iptables stuff at the bottom. i was debugging my router's dhcp server
<hyperair> and then i forgot to turn it off
<hyperair> ....okay suddenly my screen blanked out on me for no apparent reason
<hyperair> and it won't come back on
<hyperair> wtf?
<hyperair> well off i go to restart then
 * hyperair sighs
<Sarvatt> looks like it might be picking your TV to output to until X starts hyperair
<hyperair> that's very strange
<hyperair> oh and hell, i can't seem to get my comp to reboot now =.=
<hyperair> reisub time i guess
<Sarvatt> nevermind [   17.703535] allocated 1280x800 fb: 0x007df000, bo ffff88007d5ed0c0
<Sarvatt> your drm isnt getting initialized until after i915, mine loads before and looks like this
<Sarvatt> oh he isnt here, wish i could turn part messages on on a channel by channel basis :D
<hyperair> i'm back!
<Sarvatt> hyperair: edit your /etc/initramfs-tools/modules and add these on 3 seperate lines in this order
<Sarvatt> intel_agp
<Sarvatt> drm
<Sarvatt> i915
<hyperair> sudo vim /etc/initramfs-tools/modules
<hyperair> oh shit
<Sarvatt> could do i915 modeset=1 instead too
 * hyperair facepalms
<jbarnes> Sarvatt: has the xorg edgers kernel landed in the ppa yet?
<Sarvatt> :D
<hyperair> modeset=1 is in /etc/modprobe.d
<Sarvatt> yeah it is in there, there is no metapackage for it yet though so its an opt-in thing to install it
<jbarnes> Sarvatt: great
<Sarvatt> i saw that bug report from the guy not having fbcon loaded, told him to install the kernel in edgers since it has KMS enabled in the kernel config so fbcon gets linked right
<Sarvatt> hyperair: after you're done you need to update-initramfs too
<hyperair> Sarvatt: yeah i'm running that
<hyperair> Sarvatt: by the way, doesn't i915 automatically pull in drm and intel_agp when loaded?
<cwillu> oh where, oh where did my working suspend go?
<Sarvatt> its so much nicer having i915 built in because you get a high res KMS console like 2 seconds after the boot starts :D
<Sarvatt> but usplash doesnt show the throbber/progress bar that way
<superm1> is it still going to be possible to turn off modesetting if it turns out to be unstable on some of your hardware with i915.modeset=0 once it's fully built in?
<bryce> another question is if we build-in i915, would we have to do that for nouveau and radeon as well?
<tjaalton> I don't think keybuk wants those built in
<bryce> and if so, then how do we handle if say -fglrx or -nvidia needs to unload those modules in order for them to do their thing
<bryce> heya tjaalton
<tjaalton> hi
<bryce> can the module loading be made to occur sooner so we can get the benefit without having to build them in?
<tjaalton> they are not going to be included in the initramfs, because it would slow down booting up
<Sarvatt> superm1: about turning it off, you boot with "nomodeset"
<superm1> Sarvatt, okay good
<Sarvatt> and no we wouldnt have to do it for radeon, thats a seperate option in the staging area on the kernel config and only applies to those
<Sarvatt> i dont think theres any chance in heck nouveau KMS is going to be in karmic, been testing it out the past few days and have it all working but its incompatable with radeon KMS right now and doesnt work at all with KMS disabled
<tjaalton> what happens if you remove the module from the console? :)
<tjaalton> while running kms
<Sarvatt> Duke`: have you tried the updated xserver on xorg-edgers with no xorg.conf to see if it works right?
<Duke`> Sarvatt: not yet, but I have to leave, sorry... I'll try tomorrow if I have time
<Sarvatt> no worries, was just letting you know i updated it and it should be fixed now
#ubuntu-x 2009-06-16
<Sarvatt> darn, it might have been good to mention somewhere like the changelog about the changes to DontZap handling with the updated xkeyboard-config bryce :D
<Sarvatt> should I add it to the wiki maybe for the release notes?
<Sarvatt> just having DontZap in xorg.conf isnt good enough to enable it anymore, need to setxkbmap -option terminate:ctrl_alt_bksp (you can map it to other things now as well and enable/disable in userspace)
<bryce> Sarvatt: erf forgot about that
<bryce> Sarvatt: yeah definitely need to get that documented
<bryce> in fact I wonder if we ought to transition people... check if it is set in xorg.conf and then turn the option on for people
<bryce> hrm
<Sarvatt> thats a really good idea
<james_w> we should make the dontzap package do the right thing as well
<Sarvatt> its a checkbox option in the keyboard layout options now, would we even need the dontzap package anymore?
<Sarvatt> "Key sequence to kill the X server"
<Sarvatt> sent tseliot an email with a heads up about it getting updated in karmic today
<bryce> Sarvatt: thanks
<bryce> yeah the dontzap package becomes redundant
<bryce> but it may still be of benefit in some cases
<bryce> good to email alberto, he can take a look and decide.
<hyperair> Sarvatt: i fell asleep waiting for fsck to finish (god knows why it triggered, i restarted it properly damnit! and i just fscked less than a frigging day ago! stupid ext4 >=( ), but anyway  the stuff you told me to add to modules resulted in the black screen occurring *before* i could even type in my cryptsetup password
<hyperair> cryptroot password i mean
<hyperair> so i had to type it in blindly
<hyperair> heh
<Sarvatt> ah, how about booting with video=fbcon?
<hyperair> Sarvatt: hmm i'll try that. kernel parameter right
<Sarvatt> probably something to do with the whole cryptloop stuff :D
<hyperair> Sarvatt: it doesn't blank out if usplash isn't on, by the way.
<hyperair> if i boot without the 'splash' parameter, it doesn't blank out
<Sarvatt> so I guess KMS has a problem with the cryptloop display stuff...
<hyperair> Sarvatt: it does?
<Sarvatt> apparently? its blacking out and not working under a real drmfb?
<hyperair> Sarvatt: i don't really think so, because if i don't have that, the screen blanks out anyway, but *after* the cryptloop display stuff
<Sarvatt> because you arent using the drmfb until later
<hyperair> well yes, but how would KMS have issues with cryptloop?
<hyperair> it doesn't exactly attempt to display anything, right?
<hyperair> the cryptloop prompt is rendered by usplash
<Sarvatt> doesnt it hook into usplash for the prompt?
<Sarvatt> yeah
<hyperair> as in, it talks to usplash
<hyperair> hmm
<hyperair> so you're saying that the usplash prompt causes problems with it?
<hyperair> but why would it cause problems if it happened before i915 kicked in?
<Sarvatt> because you dont use the drm fb until alot later normally (18 seconds in in your dmesg)
<hyperair> but there aren't any further cryptloop prompts!
<Sarvatt> just using intelfb or uvesafb or whatever it uses until then and it blacks out
<hyperair> hmmm
<hyperair> what does usplash use exactly?
<Sarvatt> actually, looking at my bootcharts
<Sarvatt> it looks like usplash in KMS just plain shuts off right after it starts and leaves the picture up
<hyperair> what?
<hyperair> O_O
<Sarvatt> when i915 is built in and i have a KMS console up at 3 seconds in
<Sarvatt> i should force a fsck and see if it shows the fsck stuff :D
<hyperair> how bizarre O_o
<hyperair> hmm
 * hyperair is beginning to really hate fsck
<hyperair> 20 minutes for one round
<hyperair> ugh
<hyperair> what a pain
<Sarvatt> my bootcharts without KMS have usplash going for a long time, with kms it stops 2 seconds after it starts and i dont get progress bars or anything
<hyperair> i don't even know why my stupid /home loves to trigger fsck
<hyperair> i se
<hyperair> no progress bars eh
<hyperair> then imo we should get usplash fixed before turning on KMS by default
<hyperair> or remove it completely.
<hyperair> no actually newbies have a tendency to think that black screen with scrolling text = spoilt computer
<Sarvatt> probably the cryptloop :D
<hyperair> meh
<Sarvatt> (reason for the fscks i mean)
<hyperair> no, i don't think so
<hyperair> it never had an issue before this
<hyperair> come to think of it, it never managed to unmount root because it was busy at the end of the shutdown cycle
<hyperair> but cryptloop doesn't cache stuff does it
<hyperair> it's pretty much synchronous in that all operations on it are written straight to the disk, unless i'm mistaken
<Sarvatt> ext4 is marked needs fsck until its unmounted..
<Sarvatt> clears the flag when its unmounted cleanly
<hyperair> which means /home is never unmounted cleanly
 * hyperair facepalms
<hyperair> but hey i restarted it normally, surely the kernel should know to unmount all filesystems before shutting down *properly*?!
<Sarvatt> shutdown script trying to unmount / before your cryptloop maybe?
<hyperair> er doesn't it have to unmount / before cryptloop?
<hyperair> either way if / needs fscking, i don't really care
<hyperair> that takes at most 5 minutes
<hyperair> i'm annoyed if /home needs fscking
<hyperair> that takes at least 20 minutes
<hyperair> ugh
<Sarvatt> your cryptloop isnt somewhere on /?
<hyperair> oh yeah it is
<hyperair> it's on /dev/mapper
<hyperair> /something
<Sarvatt> i mean it might be trying to unmount the actual loop device before the file system inside is unmounted so that needs fsck, i had a similar problem with the shutdown scripts doing the kill wifi script before umountnfs by default..
<hyperair> no, you can't do something of that sort. cryptsetup does not allow you to do anything to the underlying block device before unmounting it
<hyperair> and the LVM on top of cryptsetup won't allow that eitehr
<Sarvatt> can you remove the loop module with it mounted?
<hyperair> no i don't think you can
<hyperair> it'll complain that it's "in use"
<hyperair> also, some rounds of REISUB don't trigger an fsck, but some do
<Sarvatt> how about the crypto module?
<hyperair> hmm
<hyperair> i think it would also complain about still being used
<hyperair> lemme try
<hyperair> actually come to think of it... what's the name of the module? O_o
<hyperair> ah nevermind found it
<Sarvatt> maybe add a sync to the shutdown script?
<hyperair> module in use
<hyperair> where is the shutdown script? O_o
<tjaalton> xserver master switched back to zapping by default, so that the shortcut can be configured with xkeyboard-config 1.6
<tjaalton> I'm not sure there's much to migrate, other than documenting it
<tjaalton> note that there's no shortcut defined by default
<tjaalton> so it's effectively still off
<tseliot> bryce: are you still there?
<tseliot> nm
<Ng> bah, rebooted this morning for a new kernel and my laptop wouldn't come out of dpms-off after lunch, had to do sysrq stuff
<hyperair> Ng: that sounds fun. did you by any chance get to fsck in the dark later?
<Ng> hyperair: heh, no, ext4 seemed to be happy just recovering things
<hyperair> Ng: good for you. i had to sit through a 20 minute long fsck, faced with a black screen, because usplash doesn't like KMS.
<Ng> ohh, there's an oops in my logs
<hyperair> or KMS doesn't like usplash
<hyperair> or something
<hyperair> yeah there's always an oops when that happens
<Ng> it's 915 related
<hyperair> i couldn't capture it though, for some reason dmesg > dmesg.txt gave me a bloody blank file
<Ng> which I guess isn't surprising
<Ng> wow, multiple oopses
<hyperair> heh
<superm1> hyperair, dmesg | tee dmesg.txt instead maybe then
<Ng> I think they're all the same, some hung_task kernel thing
<hyperair> superm1: i don't see how that would be any better
<superm1> well if plain ol 'dmesg' doesn't work, then i guess it wouldn't be any better
<hyperair> heh
<Ng> do we want bugs from i915 on the kernel?
<Ng> (I would assume so)
<hyperair> i would think so too
<Ng> huh, the backtrace looks a lot like bug #384865 which is 9.04
<ubottu> Launchpad bug 384865 in linux "kernel oops with intel graphics when screensaver turns screen off" [Undecided,New] https://launchpad.net/bugs/384865
 * Ng facepalms, it's 9.10
<Ng> I guess this should be upstreamed
<hyperair> heh
<Ng> upstreamed and linked
<hyperair> woohoo
<Ng> bit weird having it in the kernel package in ubuntu and the intel video driver in bugs.freedesktop.org, but whatever
<Duke`> Sarvatt: now intel KMS on jaunty works without xorg.conf file!
<hyperair> since when did KMS require a xorg.conf?
<hyperair> wasn't it some kernel module option?
<crevette> hey a
<Duke`> hyperair: previously, xorg server was trying to load i810 module instead of intel driver and failed... so I had to force manually the intel driver in a simple xorg.conf file
<hyperair> i see
<hyperair> great then =p
<jcristau> Duke`: sounds unrelated to kms..
<jcristau> also doesn't sound like a problem, but meh
<crevette> I've a problem with KMS, I boot with grub i915.modeset=1 ,I can see the splash screen but no gdm
<hyperair> that sounds like the opposite of what i get
<tjaalton> bryce: has the nouveau testing been with kms? our snapshot of the driver is quite old too
<Duke`> jcristau: yeah was strange, but it did only when I enabled KMS
<hyperair> i get gdm but i don't get the usplash
<jcristau> Duke`: loading i810 was not the problem then.  loading fbdev might have been.
<crevette> my hardware is described at https://wiki.ubuntu.com/X/KernelModeSetting/ (bmillemathias)
<Duke`> jcristau: ah yes, that was probably that
<Duke`> http://pastebin.com/m20b737fc
<crevette> my Xorg is https://wiki.ubuntu.com/X/KernelModeSetting/
<crevette> my Xorg is http://bmm80.free.fr/misc/X/Xorg.0.log rather
<bryce> (sorry, was in #ubuntu-desktop meeting)
<bryce> tjaalton: not going so good, so far.  Getting black screens on 2 cards, and failsafe mode on the third.
<crevette> hey no problem bryce, I was supposed you were in meeting, irc is low latency by nature
<crevette> :)
<bryce> Ng: for bug reports against the kernel that involve X issues such as KMS, etc. what we're doing is tagging them 'xorg-needs-kernel-fix'
<bryce> Ng: this let's us find the X/kernel bugs more easily in the huge kernel bug pile
<Ng> aha
<Ng> bryce: thanks, added the tag
<crevette> I didn't opened a bug yet, what should I attach as files to the bug (I already have Xorg.0.log)
<crevette> and to which component should I the bug against? (xorg, intel driver, kernel?)
<Sarvatt> thats an xorg-server problem crevette
<Sarvatt> the exact problem just fixed for Duke` :D
<Ng> now I just need to find someone to bribe/pester into fixing the problem :D
<tjaalton> bryce: but is it with kms? would it be different without?
<crevette> Sarvatt, what is the problem I arrived a bit late ... :)
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=daf26a14473563aa7368c93246f483b11e009d23
<crevette> ah yeah, it seems to be that
<crevette> because I see also the failsafe thingy trying to launch X just after and failing also
<crevette> this patch was not sent upstreamN
<jcristau> the patch is a hack
<bryce> tjaalton: yeah this testing was with apw's kms kernel; I need to re-test with the stock kernel and !kms, and also probably should pull newer -nouveau bits
<bryce> tjaalton: but so far the problems are making me lose some confidence on how far we can get with -nouveau this cycle
<Sarvatt> well I got it working fully including 3d via gallium, some changes were needed. you need to drop the dependancy on linux-nouveau-source in the nouveau ddx when you use the KMS kernel, and the KMS kernel doesnt work in non KMS mode for me
<Sarvatt> bryce: were you booting with nouveau.modeset=1 on the grub command line?
<bryce> Sarvatt: no, I assumed the kernel was set up with that by default
<Sarvatt> if i didnt use that it would try to boot in non KMS which wasnt working at all, dmesg flooded with errors and a black screen when x starts
<bryce> ah, perhaps that's what I'm seeing ... trying
<crevette> Sarvatt, so the fix will be available soon
<tjaalton> bryce: ok.. I should try with my 8600GT
<bryce> [    0.000000] Unknown boot option `nouveau.modeset=1': ignoring
<Sarvatt> did you drop the nouveau kernel source from the ddx install bryce?
<bryce> this is with 2.6.30-8-generic #10~kms2-Ubuntu
<Sarvatt> because if you built the kernel module with dkms just installing it normally you'll get the non KMS compatable one
<Sarvatt> do you see symbol version mismatch errors in dmesg? you built an external module thats overriding the KMS compatable one if so
<crevette> is the "i915.modeset=1" boot option supported in the karmic kernel, because I have the same error message than bryce
<Sarvatt> i915 isnt in the initrd by default so it gives the error trying to pass it early
<jcristau> bryce: that message is expected
<jcristau> bryce: just means i915 is not built-in
<bryce> how about "[   25.697743] nouveau: Unknown parameter `modeset'" which appears later?
<tjaalton> or nouveau, in this case
<jcristau> tjaalton: yeah, that :)
<tjaalton> bryce: maybe it's the dkms version Sarvatt mentioned
<bryce> there are no messages in dmesg about mismatched versions
<bryce> fwiw, I didn't build this kernel, this is from apw's package.
<Sarvatt> did you install xserver-xorg-video-nouveau? because if you did it overrided the nouveau kernel module that has KMS support with the one from nouveau-kernel-source
<bryce> ah, that could be; yes I updated -nouveau after installing the kernel.  Will try redoing that
<Sarvatt> unless you rebuilt xserver-xorg-video-nouveau without the linux-nouveau-source dependancy dropped
<Sarvatt> err with it dropped I mean
<Sarvatt> i'll make a ppa with everything right now
<tjaalton> just force purge -source, and remove the module it built
<bryce> nouveau-kernel-source:
<bryce>   Installed: 0.0.11+git20090515-0ubuntu1
<tjaalton> yep, that would suggest that it overrides the module from the kernel
<bryce> tjaalton: but if I try purging it, it also tries to remove -nouveau itself
<bryce> The following packages will be REMOVED:
<bryce>   nouveau-kernel-source* xserver-xorg-video-nouveau*
<bryce> I'll just try reinstalling the kernel over the top first
<tjaalton> that's why I said force purge :)
<tjaalton> or use what Sarvatt will provide
<tjaalton> or build -nouveau without the dep
<Sarvatt> it'll probably take me about 30 minutes to get everything together, will be here though https://edge.launchpad.net/~sarvatt/+archive/nouveau
<bryce> tjaalton: that was with apt-get purge -f nouveau-kernel-source
<tjaalton> dpkg --purge --force-depends nouveau-kernel-source?
<bryce>  * Running DKMS auto installation service for kernel 2.6.30-9-generic                                                  
<bryce>  *  nouveau (0.0.11+git20090515)...                                                                                    nouveau (0.0.11+git20090515): Installing module.
<bryce> ................
<tjaalton> heh
<tjaalton> dropping the dependency should work
<bryce> although I notice from the changelog, that nouveau.modeset=1 is probably unnecessary - * NOUVEAU: Pull in the Nouveau driver and enable KMS by default.
<Sarvatt> ok everything uploaded to the PPA, just gotta wait to be built
<bryce> heya gang65
<gang65> hello bryce
<bryce> tjaalton: http://pastebin.ubuntu.com/197228/
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/nouveau
<tjaalton> bryce: ok, and what happens then on boot?
<bryce> tjaalton: [   22.776767] nouveau 0000:01:00.0: display fifo hung :(
<bryce> heh, smilies in dmesg
<jcristau> progress!
<jcristau> :)
<tjaalton> hehe
<bryce> I had a brownish flash before it went black this time
<Sarvatt> yeah thats without nouveau.modeset=1, i actually add options nouveau modeset=1 to /etc/modprobe.d/nouveau.conf as well
<bryce> alright, from the changelog it sounds like that's not necessary, but easy enough to test
<bryce> SWEET
<bryce> console switched to the tiny fonts
<bryce> wow, login screen is fucked though
<Sarvatt> oh yeah, you also have to add nouveau to xorg.conf
<tjaalton> yeah it tries to use nv
<bryce> mm, think I did that already, lemme check
<bryce>         Driver  "nouveau"
<bryce>         Option  "Randr12" "on"
<bryce> yep
<Sarvatt> its possible whatever driver you're using doesnt work with the kernel nouveau though, they bumped the api around 0605, the one in my PPA should work
<tjaalton> releases ftw
<bryce> ok, well it's a *very* dark screen, but i could make out gdm's login box, so did my credentials and it started the desktop session, however the screen is fully blank (backlight is on, screen is kind of off-black)
<Sarvatt> oops, silly me, uploaded the ddx before the drm was finished building on x64 and lpia
<bryce> [   23.372708] nouveau 0000:01:00.0: Unhandled PFIFO_INTR - 0x00000010
<Sarvatt> i386 is fine though, dont know if you're on x64 or not
<bryce> murphy would have it no other way ;-)
<Sarvatt> rebuilding amd64 now
<Sarvatt> i should make a livecd for this :D
<bryce> well, I need food anyway, so hopefully the amd64 stuff will be there when I get back
<Sarvatt> amd64 or i386 for the livecd?
<Sarvatt> well getting i386 because i dont think the script can handle building a amd64 one on my i386 machine i'm doing it on right now :D
<Sarvatt> so i've gotta add nouveau to xorg.conf, and i'll echo options nouveau modeset=1 to /etc/modprobe.d/nouveau.conf, sure i'm forgetting a step...
<Sarvatt> hmm i force it to EXA and use option noaccel false too on my nouveau kms machine
<Sarvatt> but i think thats why i have problems with nouveau gallium
<Sarvatt> ahh heck, Recommends: still pulls in nouveau-kernel-source, reuploading another with it dropped completely
<Sarvatt> glad i tried it out before building the livecd :D
<Sarvatt> yeah i have to pass nouveau.modeset=1 to grub every time or it wont boot, even with options nouveau modeset=1 in /etc/modprobe.d/nouveau.conf
<Sarvatt> there an easy way to make that the default option on a live cd?
<tjaalton> not sure
<Sarvatt> ok heres logs of everything working http://sarvatt.com/downloads/nouveau-kms.txt
<tjaalton> you've got gallium there too?
<Sarvatt> yep
<Sarvatt> not packaged, built it locally
<tjaalton> ok
<Sarvatt> used ./configure --enable-glx-tls --disable-egl --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
<Sarvatt> then I use LD_LIBRARY_PATH=~/source/mesa-7.6.0~git20090613.18af7c38/lib LIBGL_DRIVERS_PATH=~/source/mesa-7.6.0~git20090613.18af7c38/lib/gallium <program> to run it
<Sarvatt> hate these darn HP bioses, i need to fix the dsdt for every single one i have
<Sarvatt> probably should mention i cant run anything more than glxinfo with gallium :D
<Sarvatt> ahh ok isolinux/gfxboot.cfg you can append things to the command line
<Sarvatt> with no xorg.conf, is there any way to tell xserver to prefer the nouveau driver, or am I going to have to make the xorg.conf only work for nouveau on the livecd?
<tjaalton> not without patching the server
<Sarvatt> can I add multiple device sections and have it go down the list to find a working one?
<tjaalton> hmm yes
<tjaalton> that's what the server does, in practise
<Sarvatt> http://sarvatt.com/downloads/xorg.conf.txt
<Sarvatt> that look ok to you? or do i need screens too
<tjaalton> not sure, have you tried it?
<jcristau> Sarvatt: yeah iirc you need one Screen for each Device
<tjaalton> try running without one, see what the logfile looks like
<jcristau> otherwise it'll just use the first Device
<Sarvatt> i just stepped out for a few minutes and dont have another machine handy to try it, and i'm almost done building the livecd so it'd be a shame to restart x to test it on this
<Sarvatt> would adding screen 0 to each device work possibly?
<Sarvatt> ahh i'm just going to add the nouveau device, if anyone wants to use it on something else they can fix it in failsafe :D
<Sarvatt> sure is fun building the squashfs on an atom cpu, hope my battery lasts
<Sarvatt> building it based on https://edge.launchpad.net/~sarvatt/+archive/xorg-testing so can test xserver 1.6.99.1 too
<Sarvatt> need to update the xserver master hooks,because alot more builds now, just kdrive having problems
<tjaalton> 1.6.99.1?
<tjaalton> I see no such release
<Sarvatt> not released yet, xserver master branch
<Sarvatt> making the liveusb now to see if it works then i'll upload it
<tjaalton> ah, so inventing release numbers then?-)
<Sarvatt> no thats the version it reports
<Sarvatt> no go on the livecd, xorg.conf gets overwritten with a default one on first boot
<Sarvatt> AC_INIT([xorg-server], 1.6.99.1, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)
<tjaalton> Sarvatt: ah, ok
<Sarvatt> cant figure out whats making it recreate a default xorg.conf, hmm
<tjaalton> xserver-xorg.postinst
<tjaalton> casper runs that
<tjaalton> forgot that it's still not fixed in karmic
<Sarvatt> hmm so if i comment the stuff from remove_conffile_prepare () { down to run ()  { out of xserver-xorg.postinst it should keep it?
<tjaalton> maybe
<jcristau> Sarvatt: rm xserver-xorg.postinst might be even better, for the live cd?
<Sarvatt> even easier, will try that
<jcristau> hrm. unless it still does something important. i'd need to check :)
<jcristau> ah, right, it does the ln -s /usr/bin/Xorg /etc/X11/X
<jcristau> but that probably doesn't need to be re-run on the live system
<Sarvatt> yeah theres a link there already, phew
<Sarvatt> ok i have a working livecd now, problem is you need to manually remove splash from the startup line. dont know if i should rebuild it with splash disabled by default or just note that :D
<Sarvatt> ahh i can rebuild it manually without rebuilding the squashfs
#ubuntu-x 2009-06-17
<Sarvatt> nice, gnome display properties shows display names instead of just "Unknown" under KMS now
<virtuald> i activate changes in display properties no more
<virtuald> can't
<virtuald> with radeon-kms ppa
<virtuald> Method "ApplyConfiguration" with signature "" on interface "org.gnome.SettingsDaemon.XRANDR" doesn't exist
<Sarvatt> does xrandr say anything when you run it in terminal?
<virtuald> it works normally i think
<virtuald> xrandr --output DVI-0 --auto set my resolution to 1600x1200 as it should
<Sarvatt> try sudo apt-get update && sudo apt-get instal gnome-desktop on the livecd?
<Sarvatt> install rather
<Sarvatt> https://lists.ubuntu.com/archives//karmic-changes/2009-June/002780.html
<Sarvatt> oh sorry, its gnome-desktop-data
<Sarvatt> 10 minutes left on the nouveau KMS livecd upload
<virtuald> o.o
<Sarvatt> http://sarvatt.com/downloads/xorg-edgers-0.10-nouveaukms-i386.iso
<Sarvatt> radeon KMS merged in linux-2.6 :)
<crevette> hey Sarvatt 
<crevette> thanks for the reply on https://bugs.edge.launchpad.net/bugs/388032 the method I used is described in the wiki KMS page
<ubottu> Launchpad bug 388032 in xserver-xorg-video-intel "[KMS] no display with KMS enabled" [Undecided,New]
<Sarvatt> heyo crevette, ahh thats you?
<crevette> yep
<crevette> still up?
<Sarvatt> yep, i should have looked at your logs more last night, thats a really common problem right now :D we need that bad-fbdev-thats-mine patch for xserver or else everyone using KMS without an xorg.conf has that problem :(
<Sarvatt> actually i'll just put it up for karmic with that patch on edgers, dunno why i didnt do that
<crevette> Sarvatt, I don't know why re you refering to jaunty in https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/388032/comments/4
<ubottu> Launchpad bug 388032 in xorg-server "[KMS] no display with KMS enabled (intel)" [Unknown,Confirmed]
<crevette> I'm using karmic
<Sarvatt> yeah I apologized for that right after
<crevette> :)
<crevette> no problemo
<crevette> I was just confused after; so can I use the i915.modeset=1 on karmic? becasue I don't want to have it loaded automcatically now, as my laptop is also used by my wife. 
<Sarvatt> try adding what I said to /etc/X11/xorg.conf, you might be able to going by your logs.
<Sarvatt> any luck?
<crevette_> Sarvatt, were you talking to me?
<Sarvatt> yeah
<crevette_> sorry I've been disconnected, I can test that tonight once I back to home
<Sarvatt> <Sarvatt> try adding what I said to /etc/X11/xorg.conf, you might be able to going by your logs.
<Sarvatt> ah alrighty
<crevette_> I'm
<Sarvatt> oh boy, libdrm-radeon1 added to mesa/drm master now, i'll leave packaging that till tomorrow so I dont screw something up due to lack of sleep :)
<tjaalton> yeah, the -9 kernel is a disaster :/
<tjaalton> compared to -8 at least
<Ng> for what?
<tjaalton> Ng: blank screen after a while
<tjaalton> intel & kms
<Ng> tjaalton: like a dpms off screensaver event you can cancel with input?
<tjaalton> Ng: right, but in this case I can't
<tjaalton> did you have the same?
<Ng> I've had recoverable, erroneous dpms off events since I installed karmic, and I've had a couple of unrecoverable dpms events which co-incided with suspend/resume since yesterday (which happened to be when I rebooted to get -9, but someone else saw very similar OOPses with -8)
<Ng> I suspect this might be several bugs looking the same, dpms events shouldn't be related to kernel oopses, I would have thought
<Sarvatt> tjaalton: are you on karmic?
<tjaalton> Sarvatt: yep
<tjaalton> no problems with -8
<Sarvatt> gnome-power-manager is horrible about dpms handling right now, there are some fixes upstream not in ours yet
<Sarvatt> ah
<Sarvatt> lets see what was changed between rc8 and release then, hmm
<Ng> yeah we need gpm 2.27.2 afaik
<Ng> but I've not wanted to waste seb's time asking about it, I'm quite sure he has a plan
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c9fb15f60eb517c958dec64dca9357bf62bf2201
<Sarvatt> i've got a deb here of gpm 2.27.2 if you just want to test it out https://edge.launchpad.net/~sarvatt/+archive/ppa/+sourcepub/654048/+listing-archive-extra
<tjaalton> ok thanks
<Ng> aha
<Sarvatt> that commit was between -8 and -9, looks like that might be where the problems coming from
<Ng> talking of gpm, is anyone else seeing a very default gnome looking icon for it?
<tjaalton> the battery with blue on it?
<Ng> yeah
<Ng> it doesn't look like the icon in jaunty, it looks more like a default gnome icon would
<tjaalton> maybe the name got changed
<Sarvatt> i saw something about that in the changelogs i think, patch that changed it didnt apply on the new ones or something
<Ng> although with the sarvatt package I just installed, the icon is /!\ ;)
<Ng> I think because it doesn't understand the state my battery is in. it's not full, but not charging and gpm is telling me it's confused
<Sarvatt> did you restart gpm?
<Ng> yeap
<Sarvatt>   * Drop 04-battery-low-icon-change.patch; it does not apply at all any more,
<Sarvatt>     and wasn't sent upstream.  Icons for 2.26 changed a lot, thus this needs
<Sarvatt>     some more work anyway. This reopens LP #344886 for Karmic.
<ubottu> Launchpad bug 344886 in gnome-power-manager ""Battery low" notification displays wrong icon, when Human theme is selected" [Undecided,Fix released] https://launchpad.net/bugs/344886
<Ng> TI:11:03:42	TH:0x1afcd00	FI:gpm-devicekit.c	FN:gpm_devicekit_get_object_icon,161 - nothing matched, falling back to default icon
<Sarvatt> thats what i was thinking of, maybe it wasnt all of the icons
<Ng> which may be related to:
<Ng> TI:11:03:42	TH:0x1afcd00	FI:gpm-devicekit.c	FN:gpm_devicekit_get_object_summary,275 - in an undefined state we are not charging or discharging and the batteries are also not charged
<Sarvatt> http://git.gnome.org/cgit/gnome-power-manager/commit/?id=651cd63cfd5e1d47bd9c625a904d57e744284292
<Sarvatt> (post 2.27.1 change)
<Sarvatt> hopefully they fix that before the 2.27.2 release
<Ng> huh
<tjaalton> Sarvatt: the new gpm didn't help, it froze just the same
<crevette> is there a way to generate a xorg.conf from the running X configuration for someone without xorg.conf?
<bryce> jbarnes: https://bugs.freedesktop.org/show_bug.cgi?id=22336 seems fairly serious.  Mind taking a look when you get a chance?  Maybe there's already a patch somewhere for that.
<ubottu> Freedesktop bug 22336 in Driver/intel "[i965] GPU hang in i915_gem_retire_work_handler() / finish_task_switch()" [Critical,New]
<Ng> aha, that looks like it might be a dupe of the one I filed yesterday
<jbarnes> bryce: yeah that might be a dupe of the vblank sync bug
<Ng> (but I'd dupe mine to mdz's, since he's way better at it than me ;)
<jbarnes> when we turn off a display there's a chance we'll hang
<jbarnes> yeah looks related
<Ng> that would match with what I've seen, all of the hangs have been related to screensaver/dpms type events
<halfline> crevette: it puts the xorg.conf in /var/log/Xorg.0.log
<crevette> halfline, hey halfline, what are you doing on ubuntu chan ? :thanks for the tips
<halfline> SPYING
<crevette> tsss
<crevette> :)
<crevette> actually mclasen is idling on #ubuntu-desktop :)
 * halfline sees federico1 here too
<crevette> Sarvatt, the fix you adviced in the bug https://bugs.edge.launchpad.net/bugs/388032 fixed the problem
<ubottu> Launchpad bug 388032 in xorg-server "[KMS] no display with KMS enabled (intel)" [Unknown,Confirmed]
<federico1> halfline: hey
<bryce> jbarnes: regarding the vblank sync bug, we pulled in 120_fix_dri2_vblank_syncing_segfault.patch (commit b8e360bf2b77d28559d15a7c0f9c766848eb6ced) to fix that one, which iirc listed a backtrace in Xorg.0.log.  This one is a bit different in that it oops in dmesg.  But is there another patch we need for the vblank bug?
<bryce> jbarnes: I poked around on fdo but didn't spot an obvious open or closed vblank bug that matches these reports; do you have a bug id or patch I should look at?
<tjaalton> Sarvatt thinks it's because of this change that got in after 2.6.30 rc8 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c9fb15f60eb517c958dec64dca9357bf62bf2201
<tjaalton> -8 works fine, -9 doesn't
<tjaalton> at least on my box
<jbarnes> tjaalton: turning of the pipes & plls would cause the vblank counter to stop
<jbarnes> so would leave us open to hangs related to vblank waits (as is done in xv and dri2 now)
<jbarnes> bryce: lemme see...
<tjaalton> jbarnes: ok..
<jbarnes> bryce: I was thinking of this one: https://bugs.freedesktop.org/show_bug.cgi?id=22318
<ubottu> Freedesktop bug 22318 in Driver/intel "kernel oops when laptop screen is switched off" [Normal,Reopened]
<bryce> jbarnes: yeah... anholt unduped it though
<tjaalton> hmm, maybe I should try to get a dump
<jbarnes> bryce: yeah saw that... I'm just guessing it's related to the vblank stuff
<jbarnes> it may not be
<jbarnes> --- a/src/i830_dri.c
<jbarnes> +++ b/src/i830_dri.c
<jbarnes> @@ -299,7 +299,7 @@ I830DRI2CopyRegion(DrawablePtr pDraw, RegionPtr pRegion,
<jbarnes>      ValidateGC(dst, pGC);
<jbarnes>  
<jbarnes>      /* Wait for the scanline to be outside the region to be copied */
<jbarnes> -    if (pixmap_is_scanout(get_drawable_pixmap(dst))) {
<jbarnes> +    if (pixmap_is_scanout(get_drawable_pixmap(dst)) && 0) {
<jbarnes>         BoxPtr box;
<jbarnes>         BoxRec crtcbox;
<jbarnes>         int y1, y2;
<jbarnes> if it's a vblank wait causing the hang that patch would prevent it
<bryce> jbarnes: btw we now have an apport script to collect all this stuff on freezes - https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/388467 - now we just need something in X to trigger it when the gpu hangs and we'll be golden
<ubottu> Launchpad bug 388467 in xorg "apport script to collect information about a gpu hang" [Wishlist,Triaged]
<jbarnes> yay
<bryce> although it seems every time we find a freeze anholt comes up with a unique new way to collect debug info :-P
<Ng> is intel-gpu-dump somewhere nicer than a git tree I have to compile? ;)
<tjaalton> apt-get away
<tjaalton> intel-gpu-tools
<Ng> oh duh, I guess command-not-found doesn't know about it yet, I'm too used to that telling me what to install ;)
<Ng> ta :)
<tjaalton> apt-file works better ;)
<Ng> yeah yeah :)
<bryce> Ng: yeah merged it into karmic a bit ago.  Still lives in universe fwiw.  Doubt that matters tho.
<Sarvatt> heyo tormod, just copyed everything for nouveau KMS over https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
<Sarvatt> oops, radeon-kms ppa out of space
<tormod> hi Sarvatt! these kernels fill them up fast :)
<Sarvatt> could you take a look at this libdrm if you get a chance? https://edge.launchpad.net/~sarvatt/+archive/ati
<tormod> what's that kms6 kernel anyway? I was waiting for a mainline snapshot now :)
<Sarvatt> want to update libdrm with libdrm-radeon1 on edgers so we can bring apw's kernels in with the drm-intel-next stuff in it without breaking ati for everyone using it since its got kms on default :D
<Sarvatt> dunno, he made it 2 days ago, guess its a bit newer than 5
<tormod> seems like the kms6 kernel only added intel support, so maybe not so useful for radeon-kms PPA :P
<Sarvatt> 5 had the intel stuff too!
<tormod> hmm the kms5 and kms6  changelogs look identical
<Sarvatt> theres so many new kernel options in .31 right now, wouldnt be surprised if it'll be awhile till we get one of those :)
<Sarvatt> i dont know, just saw higher number in his PPA and copied it
<tormod> maybe apw changed something without updating the changelog
<tormod> it's strange the ppa is full, it has only 5 packages
<tormod> guess there is a lot of cruft in the file reop
<tormod> *repo
<Sarvatt> its the old 400MB kernel that hasnt been deleted yet
<Sarvatt> just copied it like 15 minutes ago
<tormod> the kms5 ?  there are still some kms1 files also
<tormod> you want to put the kms kernel into xorg-edgers?
<Sarvatt> hmm, maybe it bugged out when you uploaded that one that failed and it didnt ever remove the one previous to that
<Sarvatt> well he's pulling drm-intel-next into it and some people want to use it for that but the whole radeon KMS enabled by default part of it kept me from copying it over, seemed like it might be ok to do it now?
<tormod> I have seen that nomodeset does not work for radeon, is there a way to disable KMS?
<Sarvatt> seems to be a consensus that KMS/DRI2 radeon-rewrite is a crapload more stable than UMS/DRI1 radeon-rewrite is all :D
<crevette> hey Sarvatt
<Sarvatt> heyo!
<tormod> DRI2 seems slower than DRI1 in many situations, which is not surprising
<tormod> first it gets usable, then stable, then they work on performance
<tormod> I would like to have the possibility to test out DRI1 in xorg-edgers for still some time
<tormod> unless it gets too complicated - intel always complicates things :)
<tormod> my biggest problem with DRI2 is that suspend and hibernation is broken
<tormod> s/DRI2/kms I guess
<tjaalton> bryce: are you going to add the new script to 'xorg', or can you wait until I've finished the merge? :)
<Sarvatt> could that be because pm-utils doesnt have the quirk handling for radeon KMS?
<tormod> doesn't it? isn't it just no quirks at all?
<bryce> tjaalton: I can wait
<tjaalton> bryce: won't take long anymore
<tormod> (only the cosmetic no-switch-vt quirk)
<bryce> tjaalton: in fact we cannot use it until apport supports running as root anyway, and won't actually function until we have the trigger stuff from jesse
<tjaalton> bryce: ah, ok
<tormod> Sarvatt: would it be an idea to have intel optimized stuff in ~intel-gfx-testing, or is it too many ppas to maintain?
<Sarvatt> naaaaah too many darn PPAs as it is and that'd just be for the kernel unless we pulled in all the dri2 swapbuffer stuff
<Sarvatt> http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/98smart-kernel-video?id=a79d16300c662080caf1775f1cf68f1be4049716
<Sarvatt> thats what i was referring to, intel needs special handling there that radeon might as well
<Sarvatt> speak of the devil
<Sarvatt> http://cvs.fedoraproject.org/viewvc/rpms/pm-utils/F-11/pm-utils-1.2.2.1-radeon-kms.patch?revision=1.1&view=markup
 * tormod just had a DRI1 crash again
<tormod> Sarvatt: the intel special handling is only for old kernels, right?
<Sarvatt> nah apw is pulling drm-intel-next with fixes that take up to 3 weeks sometimes to make it down to the ubuntu kernel into the radeon KMS kernel
<tormod> if have_kms succeeds the have_smart_intel is not even run
<Sarvatt> #define ABI_XINPUT_VERSION SET_ABI_VERSION(7, 0)
 * Sarvatt cries.
<tormod> I see. so we definitely want a special kernel for intel.
<Sarvatt> 3rd xserver input ABI bump in 2 weeks, think thats my queue to let it settle a bit more before rebuilding all input drivers yet again :D
<Sarvatt> anyway no point updating it now, i was only doing it because of the radeom KMS/intel kernel thing but you're right, it would be better to have dri1 in edgers
<Sarvatt> intel people were asking me about putting a drm-intel-next kernel in edgers is why i was looking at it
<Sarvatt> we've got the intel driver people telling people to use edgers and singing its praises on their blogs now :D
<Sarvatt> did you see this? http://cworth.org/intel/driver_stability/
<bryce> sweet :-)
<jbarnes> yeah I mentioned it in my internal uds status report too
<jbarnes> edgers kicks ass
<tormod> jbarnes: thanks! but of course the -intel stuff is sarvatt's effort
<tjaalton> bryce: ok, xorg merge pushed to git
<bryce> yay
<tjaalton> I've retained the changes to dexconf, although I don't think they hold much value anymore
<tjaalton> the failsafeDexconf needs a surgery too, since all the debconf stuff is gone
<tjaalton> jcristau: looks like the bus_id stuff should be ripped out as well?
#ubuntu-x 2009-06-18
<Sarvatt> jcristau: do you think the bad-fbdev-thats-mine.patch needed for intel KMS without an xorg.conf could be related to this? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=52367847087206b92f18c40d356d36ab9ee89d39
<Sarvatt> guess i could reboot into the ubuntu kernel with video=fbcon on the boot line and no xorg.conf to see if it gives the fbdev FatalError when fbcon is already loaded instead of possibly loaded at that point during startup
<ripps> Hey, I'm on the Xorg-edgers radeon kms cd, and it works pretty good.
<ripps> radeon 9600 pro works pretty nice in dri2 and kms. Performance isn't that bad
<ripps> Although, I haven't tested video or flash yet...
<ripps> Hmm, seems I spoke too soon, most things run fast, but small things, like resizing the users pane in pidgin is very slow.
<ripps> I'm trying to do a ctrl-alt-backspace with some new options in my xorg.conf, but it won't work, even with dontzap --disable... did they change something in karmic?
<ripps> playing a 720p video with xv and skiploopfilter=all seems to work pretty good
<ripps> AccelDFS didn't improve things much, in fact, things might be a little be slower...
<ripps> Flash seems decent with AccelDFS, but Xorg is now spiking between 40-80%  cpu
<ripps> All and all, radeon dri2 kms is impressive, especially considering how young the code is, but there is still alot that needs to be done.
<hyperair> Sarvatt: i noticed the memleak bug is marked as fix released. is it really?
<hyperair> Sarvatt: i still see it, just that i'm able to last for maybe three quarters of a day now before my swap hits 100%
<hyperair> ohoho, this is a commit that's on june 15!
<hyperair> hurry up and fix the amd64 build already =p
<apw> Sarvatt, bryce, do we have a kernel in the x-edgers PPA these days, and if so which one
<bdmurray> bryce: bug 388032 has a patch attached.  Does arsenal look for patches at all?
<ubottu> Launchpad bug 388032 in xorg-server "[KMS] no display with KMS enabled (intel)" [Unknown,Confirmed] https://launchpad.net/bugs/388032
<apw> bryce, about?
<bryce> apw: heya
<bryce> bdmurray: I do have some patch-seeking code but it's unfinished and not automated yet
<bryce> so far I just periodically do manual patch searches now and then
<bryce> bdmurray: ah, actually I'd already seen that patch and have it in a ppa somewhere
<apw> bryce, i just sent you an email on a new kms test kernel which is likely to blammo on you
<bryce> bdmurray: yeah it's the xorg-server package in https://edge.launchpad.net/~bryceharrington/+archive/ppa
<bryce> hmm, probably should move that into a separate ppa...
<bdmurray> bryce: Okay, I wasn't sure since it was still New
<Sarvatt> apw: the problem is that we cant put a kernel with radeon KMS enabled that is a higher version than ubuntu's in edgers yet because the userspace is completely incompatable and it isnt just opt-in being 2.6.30-9.10kms9
<Sarvatt> we have karmic's kernel up for jaunty though
<apw> Sarvatt, ahh.  i could disable it by default if that would help more
<apw> be more useful
<Sarvatt> i dont think its even disableable right now
<Sarvatt> all or nothing yes or no option in staging that doesnt use the KMS code paths if you dont say yes from what i see
<Sarvatt> have you seen that its in linus master now?
<Sarvatt> its really complicated right now, tormods doing some testing to see how we can work it into there with the different combination of packages
<Sarvatt> wish i had an older ati card lying around to test it on
<bryce> Sarvatt: what do you have on hand?
<Sarvatt> hd2400 pro is the only ati i have
<Sarvatt> apw: by the way, you can pull in all of drm-intel-next and the latest radeon KMS stuff (as well as a bunch of drm fixes in general) from the drm-linus branch here if its any easier http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
<apw> Sarvatt, so thats going into .31?
<Sarvatt> yeah it already is in linus' tree
<apw> very nice
<Sarvatt> i'm having some verrrry weird problems with 2.6.31 built 8 hours ago, a ton of segfaults starting up and touchpads arent working on 2 of my machines
<apw> yeah taking pre -rc1 is often asking for pain
<Sarvatt> i'll try out your pae kernel now to see if gem works
<Sarvatt> which patch did you use? the one on patchwork needed some changes i havent seen posted up yet i thought
<johanbr> tapping on ALPS touchpads doesn't work with the Karmic version of xserver-xorg-input-synaptics
<johanbr> but it does work with 1.1.1~git20090510-1ubuntu1~wgrant2 from wgrant's ppa
<johanbr> is this something you're aware of?
<Sarvatt> does it work if you do synclient TapButton1=1 in terminal?
<johanbr> something like that, yes, I don't remember exactly
<johanbr> all the TapButton settings were 0 with the Karmic version
<johanbr> but I could reset them with synclient
<Sarvatt> look at the very last page of man synaptics, tapping is disabled on purpose on touchpads with more than one physical button which is a choice the driver developers made.  ubuntu has a patch that changes that to be enabled by default always which wasnt included in the karmic version by mistake but we really do need some way to enable it correctly in userspace before we drop that..
<johanbr> if I'm reading the man page correctly, couldn't that setting be overridden in the fdi file?
<Sarvatt> yep it can, dont really need the fdi stuff anymore since its all configurable at runtime without any of the shmconfig mess now. can you not enable tapping in gnome mouse settings? the checkbox works fine for me
<johanbr> all the relevant settings there are enabled
<Sarvatt> do you have a touchpad tab in the mouse settings?
<johanbr> yep
<Sarvatt> maybe you have to uncheck and check it again on the karmic driver for some strange reason?
<johanbr> maybe
<johanbr> I'm running the ppa version right now
<Sarvatt> yeah its assuming tapping is enabled even if its not
<Sarvatt> if i turn off tapping with synclient TapButton1=0 then open it it still has the tapping checkbox enabled
<Sarvatt> and its not reenabling it if i toggle it
<Sarvatt> so I guess it needs tapping enabled by default to even work
<Sarvatt> with the tapping enabled patch if I uncheck the box it turns off tapping and turns it back on when i check it again, if i turn off tapping via synclient TapButton1=0 TapButton2=0 TapButton3=0 like the default synaptics driver has without the patch the checkbox does nothing
<johanbr> so the gnome settings just affect how gnome interprets the X events?
<johanbr> they don't actually change the driver settings?
<Sarvatt> sounds like it
<Sarvatt> have you installed gpointing-device-settings?
<johanbr> yep
<Sarvatt> if only it had a enable/disable tap option it'd be perfect
<Sarvatt> it can disable tap and reenable tap fine, but theres no explicit option to turn on tap when its already off
<Sarvatt> wonder if its been updated lately, i compiled this like 3 months ago
<johanbr> setting the driver options sounds like a job for gnome-settings-daemon
<Sarvatt> well it requires a synaptics driver > 1.0 and xserver 1.6 or newer to use the input properties, even jaunty didnt ship with the requirements there.. 
<Sarvatt> wow they just added the touchpad tab upstream in gnome-settings-daemon 3 days ago?
<johanbr> really? it was an out-of-tree patch before?
<Sarvatt> i wonder if all of the userspace requiring tapping enabled by default like this would be a good enough reason for them to consider enabling it default upstream
<Sarvatt> http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e
<johanbr> http://bugzilla.gnome.org/show_bug.cgi?id=578444 blames Ubuntu for that
<ubottu> Gnome bug 578444 in plugins "touchpad support" [Normal,Resolved: fixed]
<Sarvatt> looks like that one will work with synaptics right
<johanbr> I think so
<Sarvatt> well thats good news at least :)
<johanbr> presumably this will be imported into Karmic (with the ubuntu-specific patch dropped)
<Sarvatt> yeah soon as 2.27.4 comes out
<johanbr> alright
<johanbr> so I think I'll stick with the ppa driver until g-s-d 2.27.4 comes out and see if things start working then
<Sarvatt> maybe it would be easier to just ship a custom fdi with xserver-xorg-input-synaptics in debian/ with the tap buttons enabled instead of patching the source to enable it by default there?
<wgrant> Sarvatt: The issue with g-s-d is that it (IIRC) disables tapping by setting MaxTapTime, rather than setting the button map.
#ubuntu-x 2009-06-19
<Sarvatt> yeah they changed it to work with the device properties directly in upstream g-s-d now so it'll all work right even without the patch next update - http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e
<Sarvatt> about all these bugs regarding GEM not working with PAE, should they be reassigned to the kernel?
<Sarvatt> like https://bugs.edge.launchpad.net/bugs/388886
<ubottu> Launchpad bug 388886 in xserver-xorg-video-intel "[G45,DG45ID] No GEM, DRI, XvMC. Busy CPU." [Undecided,New]
<Sarvatt> or just tag it xorg-needs-kernel-fix
<cwillu> what's responsible for turning off the backlight during boot?  (even on a non-kms kernel without quiet and splash on the boot line)
<cwillu> oops, wrong channel
<hyperair> cwillu: it should be when i915 is loaded, isn't it?
<cwillu> does 2.6.29 have kms?
<Ng> hmm, I thought not
<Ng> but perhaps it does, isn't F11 .29?
<hyperair> i'm not sure
<hyperair> i only turned on KMS after upgrading to .30
<hyperair> modinfo i915 and see if it's got a modeset option =\
<cwillu> I don't believe I'm running kms, although I do have i915 loaded
<cwillu> it has the parm, so I'm probably running it then
<cwillu> interesting, because my suspend seems to be working properly
<cwillu> albeit, modesetting seems to be broken :p
 * hyperair grumbles about memory leaks
<hyperair> =(
<apw> bryce, hey did you get to test that GEM/PPA kerenl?
<bryce> apw, only on nv so far, I need to rejigger my box again with an ati card.  will get to that today
<apw> got any intel you could test it on?  both the generic and server.  it has a pae fix for gem applied we could do with testing
<bryce> yeah I've got a i945
<bryce> oh wait, it's busted.  hrm
<bryce> the ati box booted ok with this kernel tho
 * bryce tires of fussing with the i945 and just reinstalls
<bryce> apw, btw, the ati box booted the kernel but no drm
<Sarvatt> booting linux-image-2.6.30-9-server_2.6.30-9.10kms9_i386.deb now
<Sarvatt> apw: PAE kernel works fine on my 945GME
<Sarvatt> http://sarvatt.com/downloads/PAE.txt
<Sarvatt> can ignore the mtrr part, I didnt boot with enable_mtrr_cleanup mtrr_spare_reg_nr=1 thats required for my netbook that time
<apw> Sarvatt, thats excellent news ... will try it on my laptop also as that has 4GB of ram
<apw> oh no i can't as i am 64 bit
<Sarvatt> bryce: the drm thing is to be expected, you would need https://edge.launchpad.net/~xorg-edgers/+archive/radeon-kms since it has KMS enabled for ati
<Sarvatt> apw: odd that I'm not having that build error in i915 when i build it in instead of having it as a module
<jbarnes> bryce: ok patches are out there to detect hangs and send uevents
<jbarnes> and even recover (at least in my limited testing)
<Sarvatt> i dont know any ways to hang the gpu anymore on my machine to test it lol
<bryce> :-)
<Sarvatt> guess i could build a ddx from before the firefox hang fix since that was nice and easy
<jbarnes> Sarvatt: intel-gpu-tools has some hang tests now
<Sarvatt> oh!
<jbarnes> well one that reliably hangs for me
<Sarvatt> ah only resets on 965+?
<jbarnes> right
<jbarnes> so far
<jbarnes> pre-965 is kind enough to tell you to reboot though :)
#ubuntu-x 2009-06-20
<hyperair> ...ugh my notebook won't detect my external monitor properly now
<hyperair> wrong modes
<hyperair> bloody hell
<hyperair> and it won't refresh unless you restart X
<hyperair> blargh
<hyperair> ah looks like it was just a faulty VGA cable
<hyperair> O-o
<Sarvatt> well thats good news -- drm/i915: enable GEM on PAE. agp: switch AGP to use page array instead of unsigned long array are in .31 now
<Sarvatt> hyperair: ahh darnit, theres a new CONFIG_FSNOTIFY in 2.6.31 and if you dont select it CONFIG_INOTIFY_USER is hidden so it was lost in my make oldconfig.. no wonder i was having problems
<hyperair> heh i see
<Sarvatt> no hal support without INOTIFY_USER :D
<hyperair> heh i see
<Sarvatt> just a heads up incase you go build it
<Sarvatt> yay for ccache at least
<hyperair> ccache?
<hyperair> hmm copmiler cache eh
#ubuntu-x 2009-06-21
<Sarvatt> ahh crap, xserver master needs pixman >= 0.15.12 now too
<Sarvatt> oookay, everything but wacom and joystick updated for xinput abi 7 here https://edge.launchpad.net/~sarvatt/+archive/xorg-testing
 * Sarvatt expects to wake up to xinput abi 8 tomorrow after all that :D
<Sarvatt> hmm, some fairly nasty problems with it vs the 0609 one. firefox 3.6 giving a BadWindow (invalid Window parameter) error, and gnome panel themes wont apply.
<Sarvatt> maybe i didnt update pixman properly
<Sarvatt> ah hah, gnome-settings-daemon is failing loading the keyboard plugin, if i strace it everything works right even though it crashes until i interrupt it
<Sarvatt> i take that back, it was the gpointing-device-settings g-s-d plugin not working right with the latest XI2 driver. all fixed now.
<Sarvatt> phew, gnome sure was ugly without themes working :D
<hyperair> heh i can imagine =p
<Unggnu> hi all
<Unggnu> Is there already the X testing live cd with kms and so on?
<hyperair> Sarvatt: i just noticed that with the latest mesa, killing compiz recovers a considerable amount of memory!
<hyperair> it hit 1.4G, and when i killed compiz, it dropped to 0.4
<Sarvatt> hyperair: let me know if you have any luck with the mesa thats building right now, cherry-picked the two compiz memory leak fixes from mesa_7_5_branch into 7.6
<hyperair> Sarvatt: cool =p
<Sarvatt> hopefully it wont take 11 retries to build right on amd64 thistime :D
<hyperair> heheh did it take 11 retries the previous time? =p
<Sarvatt> theres a race in the recursive make install only on amd64 (well sometimes lpia too but not 90% failures like amd64) and only on karmic for some reason. it started around when they changed the osmesa build process and coreutils was upgraded
<Sarvatt> i tried changing it to $(MAKE) -j1 -f debian/rules $(INSTALL_TARGETS) but no luck
<hyperair> hmm strange O_o
<hyperair> this is why recursive make sucks =(
<hyperair> did you bring this issue upstream?
<Sarvatt> if i knew exactly what the problem was i would, it doesnt happen on the jaunty PPAs so i'm not sure exactly what the problem is
<Sarvatt> oh wow built ok that time
<Sarvatt> failed on lpia on the xorg-testing ppa https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+build/1086480/+files/buildlog_ubuntu-karmic-lpia.mesa_7.6.0~git20090621.df70d304-0ubuntu0sarvatt2_FAILEDTOBUILD.txt.gz
<hyperair> oh it built already?
<hyperair> i'll go upgrade then =p
<Sarvatt> and amd64 failed on the radeon-kms ppa, sheesh
<Sarvatt> mutter is sweet, cant wait till its packaged
<Sarvatt> byebye compiz :D
<cwillu> mutter=?
<cwillu> Sarvatt, don't suppose you have any interest in whipping me up a 2.6.30 or 31 with 79f11c19a396e8cea7dad322dcfb46c0a8517fe6 reverted? :)
<cwillu> a comment on http://bugs.freedesktop.org/show_bug.cgi?id=20520 suggests that it may help with suspend + kms
<ubottu> Freedesktop bug 20520 in Driver/intel "[945GM] display freezes a few minutes after resuming" [Critical,New]
<Sarvatt> its metacity with a clutter based opengl compositing backend instead of the crappy xrender one metacity compositing uses
<cwillu> intriguing
<Sarvatt> cwillu, have you tried a kernel before that was applied? i think that was in .30 rc2 or rc4
<Sarvatt> could try the mainline daily kernel for rc2 out
<cwillu> well, 2.6.29's been working for me.  Give me a sec, I'll check if I had a <=rc4 installed
<Sarvatt> err not daily sorry
<Sarvatt> just mainline 2.6.30-rc2
<Sarvatt> finding out what rc it was in now, april 30th would put it around rc5 timeframe
<Sarvatt> but i think it was right after rc5 released so its in rc6
<cwillu> earliest I have installed is rc5, so I'll try an earlier one
 * cwillu downloads the -rc2 mainline
<Sarvatt> cant revert it from master right now at least
<Sarvatt> i dont see that commit in rc5 if you have it
<cwillu> okay
<cwillu> hey, what was the url to that 2.6.31 you had again?
<Sarvatt> http://sarvatt.com/downloads/2.6.31-pre-rc1/
<cwillu> thanks
 * cwillu reboots into rc5
<Sarvatt> any luck cwillu?
<cwillu> mild confusion on vt switching that I just got figured out (fbcon wasn't loaded)
<cwillu> trying a suspend right now
<cwillu> looks good so far
<cwillu> usually it would have locked up by now
<cwillu> (this is -rc2)
<Sarvatt> yeah darn mainline kernels using jaunty's config causing that
<cwillu> yep, rc2 is definitely looking good on the kms suspend front
<cwillu> I'll check that 2.6.31-pre-rc1 as well
<cwillu> yay for having two different suspend bugs :p
<Sarvatt> it was added in rc6 btw so rc5 should be fine too
<cwillu> 2.6.31-pre-rc1 hangs immediately on resume
<cwillu> good ol' working mouse cursor that you can't do anything with :p
<cwillu> give me a sec, I'll check rc5
<Sarvatt> well hopefully something will come of it now that they know that was the problem :)
<Sarvatt> is it 945?
<cwillu> yes
<cwillu> I'll add a 'works for me too' on the bug after I make sure rc5 is good
#ubuntu-x 2010-06-21
<ion> sarvatt: You around?
<kees> hmmm.  SDL applications lock up for me on maverick but not lucid.  did something go wonky?
<RAOF> kees: That's the first I've heard of it, but there are plenty of targets for finger pointing - we've got a new kernel module, a new mesa, a new Xserver, a new intel DDX.
<kees> RAOF: it's really goofy.  surface updates just kind of stop.
#ubuntu-x 2010-06-22
<kees> RAOF: this should never stop animating... http://people.canonical.com/~kees/sdltest.c
<Sarvatt> kees: works fine here on intel and nouveau but i'm using edgers, hmm
 * kees scratches his head
<kees> I'm on 2.6.34-5-generic, since .35 doesn't boot for me.  :(
 * kees will play around.  if other people aren't seeing it, then i'll go try to go digging a bit harder.  thanks for testing!
<Sarvatt> i'm not using stock packages though and dont have the bandwidth at this hotel to downgrade
<ion> sarvatt: Did you notice my message?
<Sarvatt> ion: nope sorry, whats up?
<ion> sarvatt: This should work for all current versions of the driver and hopefully many future versions: http://gist.github.com/raw/445368/6b54c1c04836d3d9d9061cdf0b25c60b8c4c0e38/nvidia_supported
<Sarvatt> oh nice, thanks ion!
<Sarvatt> DEBUG: readme:354 object:577 deletions:0 additions:223
<ion> The README had 354 IDs, nv-kernel.o had 577. From README to nv-kernel.o, there were no IDs removed and 223 added.
<ion> The current thresholds for accepting a symbol as the list from nv-kernel.o are: zero deletions and at most n additions where n is 1.5 times the number of IDs in README.
<ion> Other symbols than the correct list will have hard time meeting those requirements.
<ion> sarvatt: The script will also exit with a non-zero value if no list was found.
<ripps> Sarvatt: why doesn't mesa include a git changelog.gz like xserver does?
<ripps> It'd be useful to know what's been changed.
<RAOF> It does, in mesa-common (from memory)
<ripps> RAOF: I meant the libgl1-mesa updates
<RAOF> Its' in mesa-common.
<ripps> hmmm... there is no mesa-common, or at least there's no docs of it.
<ripps> at least not in xorg-edgers.
<RAOF> Maybe it's mesa-common-dev
<ripps> woo, alot of r300g fixes. It might be time for me to try out gallium again. Maybe it won't be so crashy.
<ripps> nope, still crashes when starting gnome-mplayer
<ripps> crashes compiz
<RAOF> Wow.  VGA hotplug on intel.
<m3ga> i need to fix https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/595342 and i'm willing to put in considerable effort.
<ubot4> Launchpad bug 595342 in xserver-xorg-input-mouse (Ubuntu) "Avago touchscreen detected but not working (affects: 1) (heat: 6)" [Undecided,New]
<m3ga> whats the best plan of attack?
<ripps> Sarvatt RAOF: I have a backtrace of compiz crashing: http://pastebin.com/0neGZ66d
<RAOF> It'd be interesting to get the ??s from libGL resolved - do you have those dbg packages installed?
<ion> raof: One would think any driver that can e.g. fetch EDID could do display hotplug at least by polling if no other means are available.
<RAOF> Yeah, but that requires polling, which tends to require the display hardware to be turned off briefly.
<ion> Oh. I wasnât aware of that.
<RAOF> Also, this LCD apparently doesn't export its EDID over VGA. :/
<ripps> RAOF: I'm installing the -dbg for libGL now
<RAOF> Hm.  Where was that X patch to not hang compiz + dual headâ¦
<ripps> RAOF: 
<ripps> http://pastebin.com/xdHMKT7C
<RAOF> Well, there appears to be plenty of NULL to go around there.
<RAOF> kees: Aaah, interesting.  I can reproduce your problem only with compiz + the 2.11 DDX.  It may have something to do with our patch to stop everything freezing to a halt when using pageflipping to handle syncs.
<kees> RAOF: oh!  I didn't even think to turn off compiz.
<kees> RAOF: up, totally fixed if I get rid of compiz.
<kees> RAOF: shall I open a bug, or is this already tracked somewhere?
<RAOF> I don't think it's tracked anywhere yet.
<RAOF> I'll check whether it also happens on -radeon.
<RAOF> After going for a short walk.  It's time for some exercise and sun to warm me up!
<RAOF> kees: Yup, that's an -intel only problem.
<RAOF> Gah.  It doesn't _really_ need to be getting dark here yet.  It's just lazy.
 * hyperair wonders why rainlendar2 no longer appears with xorg-edgers packages
<RAOF> asac: Good morning?
<hyperair> Sarvatt: aha. your cairo package breaks rainlendar2.
<hyperair> (which isn't in the Ubuntu repos anyway, so sucks to be me =()
<ripps> is anybody else seeing a weird evince rendering issue where it won't scroll the page image?
<ripps> maverick/xorg-edgers
<ripps> Still have bug, even after turning off gallium. Gonna try removing xorg-edgers to see if it's the upstream xorg/drivers causing it.
<RAOF> asac: ping?
<ripps> Okay, removing xorg-edgers fixed the evince problem. That must mean one of the most recent updates broke evince scrolling
<tseliot> Sarvatt, RAOF: the bug which involved having "(EE) DoSwapInterval: cx = (nil), GLX screen = (nil)" in the X log is fixed, isn't it?
 * bryce_ waves
<Sarvatt> heyo bryce_!
<Sarvatt> tseliot: did you see that ion fixed nvidia_supported?
<Sarvatt> <ion> sarvatt: This should work for all current versions of the driver and hopefully many future versions: http://gist.github.com/raw/445368/6b54c1c04836d3d9d9061cdf0b25c60b8c4c0e38/nvidia_supported
<tseliot> Sarvatt: no, I didn't, as I had more urgent oem work to deal with
<tseliot> Sarvatt: are we tracking this in git?
<Sarvatt> nope, not tracking it anywhere thats why I wanted to pass it along since i'm in the process of moving and wont be around much
<tseliot> ah, ok, thanks for the link
<ricotz> Sarvatt, hi, do you have a minute?
<Sarvatt> whats up?
<ricotz> Sarvatt, do you know if there could be a problem shipping gconf 2.31.4 for lucid?
<Sarvatt> i really have no idea about it, just a quick look at git makes it look like it might be a problem though :(
<ricotz> Sarvatt, ok, i was hoping you know it, what commit is bothering you?
<Sarvatt> all of the converting schemas to gsettings stuff
<Sarvatt> is it optional?
<ricotz> Sarvatt, this shouldnt be a problem, this is just a extra backend to use gsetting with gconf
<ricotz> yes it is turned of in maverick, and i enabled it and want to port it to lucid
<Sarvatt> seems like a really major change, sorry I dont know more about it
<ricotz> Sarvatt, thank you, i switched to maverick and it is working, but lucid is another thing
<ion> sarvatt: Did you get my message explaining the DEBUG line?
<Azelphur> Can anyone help me? I keep getting this weird bug where my input lags up, my CPU is at 94% idle, I have plenty of free RAM
<Azelphur> It's really annoying, I have to type very slowly otherwise my text will come out in the wrong order, or just not arrive at al
<Azelphur> for eampl i'm typin tihs sentence at anomral sped
<Azelphur> >.<
<Azelphur> my mouse moves very blocky, like 1 update every second
<Azelphur> narrowing it down, i think its a usb problem, tried replugging my keyboard and it didnt come up again
#ubuntu-x 2010-06-23
<Dr_Jakob> Sarvatt: yo, I just change splitted up the configure option of --with-gallium-intel into --with-gallium-i915 and --with-gallium-i965.
<RAOF> --with-gallium-iwork & --with-gallium-idont? :)
<Dr_Jakob> indeed :)
<rcr> evening all, I have just setup lucid on a acer power 2000, and the video will not resume after suspend. I have tried updating drivers (ubuntu-x-swat ppa) and also the new kernel from proposed but none of it has helped sofar
<rcr> I am not even sure where to look, I have looked at the X.log but didn't see any errors
<rcr> any thoughts would be great
<rcr> video is intel i915
<rcr> Intel Corporation 82946GZ/GL using the i915 driver according to lspci
<kees> RAOF: oh, btw, I opened the SDL+compiz bug as bug 597094
<ubot4> Launchpad bug 597094 in compiz (Ubuntu) "compiz causes SDL surfaces to stop animating (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/597094
<RAOF> kees: Thanks.  I'll see if the patch I think causes that does indeed cause that.
#ubuntu-x 2010-06-24
<bjsnider> Sarvatt, let me know when the code for the nvidia_supported script is finished
<ion> It isnât?
<ion> bjsnider
<bjsnider> the script is finished but its integration into the packaging scripts is not
<bjsnider> because the usage of the script has changed
<bjsnider> the most recent package simply disables the script and adds a hardcoded modaliases file
<bjsnider> ion
<ion> Ah, indeed.
<PhoenixSTF> hi guys
<PhoenixSTF> sorry i dont know where to ask this
<PhoenixSTF> but im having troble with ATI 10.6 flgxr driver instaltion
<PhoenixSTF> after instalation it wont recognize the grafic card, and there is no xorg.conf
<PhoenixSTF> sorry and thanks in advance
<Sarvatt> if anyone comes in with problems with ati 10.6 like that guy did they need to run sudo aticonfig --initial
#ubuntu-x 2010-06-25
<Sarvatt> whoops RAOF your edgers expired, renewed ya :)
<RAOF> Sarvatt: Thanks.  I was going to ping you about that :)
<ripps> Wooo!!! Internet is back.
<tseliot> RAOF, Sarvatt: I'm almost done packaging the new nvidia driver. Did you put the libraries back where they used to be in Mesa?
<bjsnider> tseliot, did you integrate the new nvidia_supported script?
<tseliot> bjsnider: yep
<bjsnider> can you post the relevant section of the rules file somewhere?
<tseliot> bjsnider: I'll commit my changes soon in this branch: http://github.com/tseliot/nvidia-graphics-drivers
<bjsnider> k
<tseliot> bjsnider: ok, pushed (note: this is not final)
<bjsnider> tseliot, where is the code that creates the /dev/nvidiactrl file?
<tseliot> bjsnider: ???
<tseliot> bjsnider: you will only find packaging scripts there
<bjsnider> well, i was looking for the correct settings for that file, i assume it is owned by root:video and that the user must be part of the video group
<tseliot> I wouldn't know
<bjsnider> i have to get hold of someone who has the blob installed right now
<bjsnider> unfortunately it got screwed up thanks to ext4 when i lost power
<bjsnider> i always lose data with ext4 if the system shuts down unexpectedly
<tseliot> :-/
<ion> tseliot: Re: the commit message, itâs in fact the README that is missing IDs (and has been for all releases of the driver). The README is only used by the new script to find the correct symbol from the blob. The resulting list is based on the blob, not the README.
<ion> tseliot: The script traverses through the .rodata symbols until it finds one that correlates to the README list closely enough. Then that list is converted to the modaliases format.
<ion> tseliot: The list from various versions of the blob has consistently had zero ID deletions (compared to README) and almost 100 % additions compared to the number of IDs in the README.
<ion> tseliot: So, currently the thresholds for picking the symbol are: deletions = 0, additions â¤ 1.5Â·n where n is the number of IDs in README.
<tseliot> ion: ah, it seemed weird to me that they removed only some ids. I'll read your changes again
<ion> tseliot: Sarvatt said the IDs README is missing are things like AGP-PCIe bridge chips etc.
<tseliot> ion: aah, that's where I heard that something was removed. I must have mixed things up
 * tseliot changes the changelog
<ion> tseliot: For previous releases of the driver, the blob had two consecutive symbols duplicating the ID list, and that was the heuristic used to find the right symbol. They removed the duplicate and the script stopped working. So now the new heuristic for finding the right symbol is the comparison to the list from README.
<ion> tseliot: If you havenât already done it, i could as well do the changelog change.
<tseliot> ion: I did this but I haven't pushed it yet: http://pastebin.ubuntu.com/455000/
<tseliot> ion: if you want to add a detailed explanation to the changelog, you're welcome to do so
<tseliot> BTW why 1.5Â·n?
<ion> Itâs pretty much an arbitrary number for sanity checking. The number of additions has correlated with the number of total IDs in README, and since it has consistently been *almost* 1.0Â·n, i added a safety buffer of about 50 % in case the number of additions exceeds the number of IDs in README in a future release.
<tseliot> ok, I suspected that but I wanted to be sure
<tseliot> ion: where's your branch on git-hub?
<ion> tseliot: Just pushed to http://github.com/ion1/nvidia-graphics-drivers / git://github.com/ion1/nvidia-graphics-drivers.git
<tseliot> ion: ok, I'll merge from it
<tseliot> merged and pushed. Thanks
<tseliot> the driver works well now
<tseliot> I guess nvidia-173 and nvidia-96 are not installable in maverick, are they?
<tseliot> bjsnider: ^
<ion> Have you considered having just a single source package for all versions of the nvidia driver, btw? Wouldnât that reduce duplication? I made sure the new nvidia_supported script works for all versions, for instance. It could just as well exist in a single source package.
<bjsnider> ion, i added y our script to the older distros and it generated the expected modaliases file
<tseliot> ion: that would make the source package too big with all the installers
<tseliot> also bug tracking would be harder
<ion> Good point
#ubuntu-x 2010-06-26
<ernstp> seems like something hangs when gdm starts to draw with latest xorg-edgers ppa on Lucid
<ernstp> no error messages anywhere though
<Kangarooo> hello Sarvatt . what ackage i need to report for this problem: changing resolution to lower/or 1024x786 makes tty no opening. with higher it opens. the higher the better resolution for tty.
<Kangarooo> Sarvatt: u alive? :)
<Kangarooo> Sarvatt: for the same bug ive mentioned here just now i want to know to waht package i need to report about if i have nvidia? xserver-xorg-video-nv or xserver-xorg-driver-nv
<jcristau> neither
<bjsnider> Kangarooo, go to the nvforums and report the bug to nvidia
<Kangarooo> bjsnider: problem is for linux. when i set resolution in xorg to be larger then 1024x768 then TTY can be opened. the larger Xorg resolution the larger TTY. if smaller in Xorg then 1024 then tty cant be opened.
<Kangarooo> i think TTY still opens but somehow that tty shows too small resolution that comp/monitor can show..
<Kangarooo> *cant show..
<bjsnider> so everybody on all platforms are also having that problem? otherwise it's an nvidia issue
<Kangarooo> bjsnider: no only in linux. couse problem is for TTY(1-6) to show. and other os dont have TTY. so i thought problem maybe is for xorg or tty but in #ubuntu-bugs i was told to try also if its not kernel problem i tryd nomodeset and that didnt change anything for this problem.
#ubuntu-x 2010-06-27
<onryo_> Hello?
<onryo_> this sucks nuts...
<hyperair> okay, this is just plain weird. why  does my notebook only have these weird hard hangs when not on battery?
<hyperair> i mean when not plugged in
#ubuntu-x 2011-06-20
<jussi> Hrm, is there any chance someone could trigger a build of 2.6.39.1 (or the latest one) for natty? I only see oneiric here: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<tjaalton> jussi: it should work on natty too
<jussi> tjaalton: thats what you told me last time, but it didnt (well rc4 didnt)
<tjaalton> ah, ok
<jussi> tjaalton: there isnt a chance it will ruin my machine if I nstall an oneiric kernel? I can just switch back to other natty kernels, right? 
<tjaalton> jussi: right, it shouldn't break anything
<jussi> ok, Ill give it a go
<jussi> Well, the 3.0 kernel didnt install. :(
<jussi> Unpacking linux-headers-3.0.0-0300rc3-generic (from .../linux-headers-3.0.0-0300rc3-generic_3.0.0-0300rc3.201106140913_amd64.deb) ...
<jussi> dpkg: dependency problems prevent configuration of linux-image-3.0.0-0300rc3-generic:
<jussi>  linux-image-3.0.0-0300rc3-generic depends on module-init-tools (>= 3.13-1ubuntu1); however:
<jussi>   Version of module-init-tools on system is 3.12-1ubuntu6.
<tjaalton> ah, right. because of the version number change
<jussi> Ok. SO the 2.6.39.1 is likely to work then? 
<jussi> err, wait, I tried that already. 
 * jussi goes back to actually thinking before typing :)
<jussi> tjaalton: some Kind person has helped :) http://marcin.juszkiewicz.com.pl/2011/06/20/linux-3-0-under-ubuntu-natty-11-04/
<tjaalton> jussi: that's nice
<jussi> So, 3.0 rc3 is fail on this machine. (sadly)
<jussi> BTW, where does the log from ctrl+alt+prtscrn+t go? 
<tjaalton> the kernel log?
<hyperair> hmm so playing wine with snb graphics is horribly slow.
<hyperair> i mean playing games on wine
<Prf_Jakob> So I know this is far in the future, but what mesa version are you planning to use for 11.04?
<Prf_Jakob> Sarvatt, bryceh: ^^
<tjaalton> Prf_Jakob: you mean 12.04, 11.04 is already released :)
<Prf_Jakob> Right
<Prf_Jakob> 7.11 or 7.11 + 1?
<tjaalton> aiui you're aiming 7.12/8.0 in january next year, so probably that
<tjaalton> plus a bugfix point-release
<Prf_Jakob> Cool thanks!
#ubuntu-x 2011-06-21
<ripps> Does anybody have any clue how well the integrated intel graphics on an core i5 2400 is compared to an nvidia gt 240?
<tjaalton> what do you mean?
<tjaalton> it's perfectly fine for a "normal" linux desktop
<tseliot> Sarvatt, tjaalton: didn't we use to strip the OS ABI tag from Mesa's libGL?
<tseliot> this patch: http://sarvatt.com/downloads/patches/100_no_abi_tag.patch
<jcristau> wasn't this made unnecessary by your alternatives stuff?
<tseliot> yes but I'm now reconsidering this as the alternatives system kind of breaks dlopen()
<tseliot> I think we can get both things to work
<jcristau> dlopen("libGL.so.1") should still work...
<tseliot> i.e. libGL.so.1 will be a slave link in /usr/lib and point to either the lib in /usr/lib/mesa/ or the one in  /usr/lib/$driver
<tseliot> right now we don't have any libGL.so.1 in /usr/lib
<jcristau> i know.
<tseliot> only libGL.so is there
<tseliot> I think someone reported a bug about it
<jcristau> so dlopen("/usr/lib/libGL.so.1") won't work.  dlopen("libGL.so.1"), otoh...
<tseliot> ah, I guess the bug report was about apps which specified the full path
<tseliot> yes, that was the case. Thanks jcristau
<jcristau> (the linux libGL ABI spec says it should be in /usr/lib/libGL.so.1 so in theory it should work.  i don't know what apps rely on that part of the spec though)
<tseliot> right
<Amaranth> hrm, I see a mesa update in oneiric, scary
<Sarvatt> very :)
<tjaalton> oh right, now that llvm is in main
<Amaranth> oh, it's not anything mesa 7.11, i'm probably ok
<Amaranth> last time I checked 7.11 stuff still breaks my gles
<Prf_Jakob> Amaranth: bug filed?
<Amaranth> I believe one was filed
<Amaranth> It was something in the build system disabling GLES for intel when using the shared glapi stuff
<Prf_Jakob> Hmm ok
<Amaranth> I spoke to RAOF about it at UDS and he said a bug was filed and he was going to look at it, I believe I found the bug that same day
<Amaranth> Trying to find it again now
<Amaranth> hrm, now I can't find the bug or the gles code in mesa to find the problem again
<Prf_Jakob> Things have changed in that area I think.
<Amaranth> iirc -DFEATURE_ES2 was getting lost when building with --enable-shared-glapi, but only for intel
<Amaranth> I'll have to see if xorg-edgers has a recent looking mesa snapshot to see if the problem is still happening
<Amaranth> Prf_Jakob: Looks like that bug was fixed, I'm on a mesa snapshot from the 16th and have gles2
<Sarvatt> https://launchpad.net/ubuntu/oneiric/+localpackagediffs allowing ia32-libs diff computation and doing it on the fly every time? incoming DoS
<Sarvatt> xserver-xorg-video-ati has taken about 5 minutes to compute so far :(
<bryceh> Sarvatt, I assume it caches the result after doing it once
<bryceh> Sarvatt, out of curiousity what are you looking at in -ati?
<Sarvatt> bryceh: what happened was i clicked calculate diff for ia32-libs which will take a year and probably be 1GB+, switched pages to cancel and tried to get a diff on -ati. turned out i'll have to wait until ia32-libs is done :)
<bryceh> ah
<bryceh> hm, I've several natty -intel bugs marked now as "fixed" due to ickle's dropping of uxa 3d pipeline
<Sarvatt> dont think its worth picking up that commit to SRU?
<bryceh> well I'm thinking about it
<Sarvatt> people using xterm will complain no doubt :)
<bryceh> Sarvatt, what do you think?  I've got it packaged and am going to slam it in a ppa at least
<bryceh> Sarvatt, why's that, does this optimization path solve a problem for them?
#ubuntu-x 2011-06-22
<cdbs> Sarvatt: ping
<cdbs> there by any chance?
<stratis> Hi, I've got an nvidia 8400 Gt (10de:10c3). It was not autodetected by jockey-gtk in my Lucid box. I installed nvidia-current, but I got into a low-graphics mode. Help, please? :)
<stratis> My xorg.0.log: ttp://pastebin.com/UcnpSCSd
<tjaalton> stratis: and xorg.conf?
<stratis> tjaalton: I don't have a xorg.conf
<tjaalton> probably doesn't exist if you installed nvidia by hand, so there's your failure
<stratis> Aaah :)
<stratis> Should I add the pciid somewhere so that jockey-gtk can see the card and auto-detect it?
<stratis> Afaik it's a somewhat rare pciid...
<stratis> (in the meantime - thank you, trying to generate a xorg.conf...)
<tjaalton> nvidia-common probably has the list somewhere, can't check right now
<stratis> Maybe in /usr/share/jockey/modaliases/nvidia-current  - thanks a lot
<stratis> Yup, now jockey auto-detected it, should If file a bug report? And, agaist what, jockey?
<stratis> s/If/I/
<stratis> (rebooting to check if it's working, I'll read the irc logs if someone replies - thanks again)
<alkisg> (I'm helping stratis remotely): probably nvidia-current-modaliases: /usr/share/jockey/modaliases/nvidia-current
<tseliot> RAOF: can you put back versioned breaks on the proprietary drivers in Mesa, please? (using the current versions)
<debfx> virtualbox-guest-x11 doesn't work with the multiarched mesa, but I guess it's a bit late to add a Breaks now
<tjaalton> debfx: fix vbox instead :)
<tjaalton> debfx: how is it broken?
<debfx> heh
<debfx> tjaalton: it tries to load swrast_dri.so but doesn't find it
<jcristau> *vbox* tries to load swrast_dri.so?
<jcristau> that makes 0 sense
<jcristau> which i guess means it's probably true, this being vbox.
<tjaalton> yeah the xserver should know where the drivers are
<tjaalton> debfx: got a logfile?
<jcristau> xserver and libGL, but yeah.
<debfx> tjaalton: yes but there is nothing interesting in it
<debfx> I guess hardcoding the multiarch paths would be a quick fix
<jcristau> hardcoding where?
<debfx> this is the code that loads swrast: http://www.virtualbox.org/browser/trunk/src/VBox/Additions/common/crOpenGL/fakedri_drv.c
<debfx> # define DRI_DEFAULT_DRIVER_DIR
<tjaalton> ahh.. evil
<jcristau> sigh
 * jcristau goes back to pretending vbox doesn't exist
<tjaalton> hehe
<tseliot> O_o
<jcristau> stupid crap...
<tjaalton> \//@todo this could be different...
<tjaalton> uh
<tjaalton> anyway
<tjaalton> escaping in irssi didn't work the way I thought it would :)
<Sarvatt> hmm no more --disable-gallium in mesa
<Sarvatt> oh helps if I read, --with-gallium-drivers= does the same
<ScottK> How do I find enough information about this error (from Xorg.0.log.old): 
<ScottK> Fatal server error:
<ScottK> [ 41896.470] Wrong event type 0.
<ScottK> It's an Intel Sandybridge laptop.
<Sarvatt> ScottK: can you file a bug? I think I see the fix
<Sarvatt> against mesa
<ScottK> Will do.
<cnd> bryceh_, the sun! it's too bright and it stays up too long here!
<cnd> I can't sleep in past 7!
<Sarvatt> ScottK: thanks a bunch, looks like the fix didn't make it to 7.10 stable yet. I just uploaded a fixed mesa to https://launchpad.net/~sarvatt/+archive/orange 
<ScottK> Sarvatt: Filed as Bug #800778.
<ubot4> Launchpad bug 800778 in mesa (Ubuntu) "Unexplained X Crash On Intel Sandybridge (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/800778
 * ScottK tap, taps his fingers waiting for it to build ....
<ScottK> BTW, you might want to delete the old maverick -intel package in that PPA.
<Sarvatt> alrighty, done. that one wasn't important. 
<Sarvatt> Build status
<Sarvatt>  Needs building
<Sarvatt> Start in 16 hours
<Sarvatt> eww..
<ScottK> I'll grab it and build it locally I guess.
<ScottK> Sarvatt: Is this patch risky?  This is my main laptop and the crash is rare.  I'd rather not make it worse ...
<Sarvatt> ScottK: I'd say no
<ScottK> Thanks.
<ScottK> Building locally
<cnd> Sarvatt, would you happen to know how I can test an input module change by running a second X server in a new VT?
<cnd> is there a way to have two gdms?
<ScottK> cnd: I know shadeslayer did it with two kdms for a project neon demo.  You could ask him on #kubuntu-devel how he did it.
<cnd> ScottK, thanks :)
<tjaalton> startx doesn't cut it?
<cnd> tjaalton, just tried startx
<cnd> I think it'll work
<ScottK> Sarvatt: Now that I've got it built locally, any suggestions on which of the bazallion packages mesa builds I need to install?
<jcristau> libgl1-mesa-{dri,glx} most likely
<ScottK> Thanks.
<ScottK> Nothing immediately awful happened, so let's see how this goes ...
<ScottK> Sarvatt and jcristau: Thanks again.
<Sarvatt> dpkg -l | grep mesa, all those except mesa-utils
<ScottK> Thanks.  That picked up a few more.
#ubuntu-x 2011-06-23
<Sarvatt> bryceh: laptop at your front door in case they didn't knock :)
<bryceh> Sarvatt, thanks yep it arrived yesterday.
<Sarvatt> oh whoops, thought it just got delivered
<bryceh> Dutch saw the package and insisted we open it.  I carelessly knicked my thumb with the scissors, and he enjoyed helping put a bandaid on dada.
<bryceh> planning to image it today (along with a couple other older laptops), need to do a usb key
<nigelb> bryceh: ping
<nigelb> bryceh: had you written a wrapper over reportbug that would accept an ubuntu bug # and that would forward to debian?
<nigelb> I don't remember who wrote it :(
<bryceh> nigelb, wasn't me
<bryceh> we typically forward X bugs directly upstream, not to debian
<nigelb> In that case, the next best guess is brian
#ubuntu-x 2011-06-24
<hyperair> meh. mesa is so hard to cross-compile
<hyperair> you have this stupid builtin_compiler thing that needs to be built using the --build compiler, and then chattr +i, make clean to get rid of all the native object files, and make again to finish cross compiling. pfft.
<Sarvatt> hyperair: i'm hoping to have multiarch on natty and oneiric in edgers in the next week so it should be a bit easier
<tseliot> tjaalton, RAOF, Sarvatt, bryceh: do you mind if I upload a new  mesa with versioned breaks on proprietary drivers?
<tseliot> (otherwise my new drivers won't be installable)
<tseliot> hmm... most of you must be on holiday...
<tseliot> the git branch looks a little confusing
<bryceh> tseliot, yes that's fine
<bryceh> tseliot, in fact Sarvatt and I were planning on trying to figure out what needed done tomorrow
<tseliot> bryceh: I guess the last commit was not uploaded even though there's no UNRELEASED word in the changelog
<tseliot> commit a6aaf514c91a593d79e9ae8899798641d52d19de
<tseliot> i.e. Fix !i386 !amd64 builds by only installing i915g there, ie: where it's actually built
<bryceh> could be; I didn't talk with raof about it
<tseliot> bryceh: I'm wondering if it's ok to upload that change if it's not already in
<bryceh> I don't know; perhaps there was more raof needed to do?
<bryceh> could he have uploaded it but it failed to build?
<tseliot> had he uploaded the commit we should've seen at least something in the changelog in git
<tseliot> bryceh: I guess they won't miss i915g on armel anyway ;)
<bryceh> heh
<tseliot> oh, wait there's something in the changelog
<tseliot> bryceh: yes, the change is already in
<tseliot> I'll clean up things in git too
<bryceh> yep.  $ apt-cache policy libgl1-mesa-dri
<bryceh> libgl1-mesa-dri:
<bryceh>   Installed: 7.10.3-0ubuntu3
<bryceh>   Candidate: 7.10.3-0ubuntu3
<bryceh> tseliot, any changes needed for xorg-server?
<tseliot> bryceh: no, I don't think so. All we need is to version the breaks in Mesa (I've tested things here for a few days)
<tseliot> jcristau: I'm getting Permission denied (publickey) when trying to push my commits. Any ideas?
<tseliot> my username is tseliot-guest
<jcristau> check that you're using the right key?
<tseliot> jcristau: I've certainly not changed my key for a while now
<jcristau> when was the last working commit?
<tseliot> jcristau: also, if I try to ssh into alioth.debian.org, it says that remote host identification has changed, so I'm wondering if anything changed there
<tseliot> let me check
<jcristau> yes, something changed there
<jcristau> http://lists.debian.org/debian-devel-announce/2011/05/msg00007.html http://lists.debian.org/debian-devel-announce/2011/05/msg00008.html
<tseliot> jcristau: it was b28a90c9a78f605d521a9ba1cda42f23ad487e10
<jcristau> that's not a date
<tseliot> jcristau: sorry, Thu Dec 2 13:34:35 2010 +0100
<jcristau> yeah, so long before the move
<jcristau> try ssh to vasks.debian.org, see what that tells you
<tseliot> jcristau: still Permission denied (publickey)
<jcristau> then make sure https://alioth.debian.org/account/editsshkeys.php has the key you're trying to use
<jcristau> (and that it's not a dsa key)
<tseliot> jcristau: I've tried that (with RSA) but I'm still getting the same error. Shall I wait a few minutes?
<tjaalton> tseliot: fix the hostname in .git/config
<tjaalton> to git.d.o
<tseliot> tjaalton: I'm using git+ssh://tseliot-guest@git.debian.org/git/pkg-xorg/lib/mesa.git
<tjaalton> ok.. maybe plain ssh then?
<tjaalton> can't check my config
<tseliot> I keep getting the following:
<tseliot> Permission denied (publickey).
<tseliot> fatal: The remote end hung up unexpectedly
<tjaalton> ok, so it's probably not related to the alioth upgrade
<tjaalton> at least the way i thought it was :)
<tseliot> jcristau: I've tried creating a new ssh key and setting my ssh config file to use that but it doesn't seem to solve the problem
 * tseliot is starting to think that debian.org hates him
<jcristau> the cron to sync the keys from the db runs at the hour
<ScottK> Sarvatt: No more crashes since I installed your PPA package.
<tseliot> ok, I'll wait then
<tseliot> jcristau, tjaalton: thanks for your help
<jcristau> if stuff still doesn't work there's always mailto:admin@alioth.d.o or #alioth on oftc
<tseliot> jcristau: it works now, thanks again
<jcristau> ah cool.
<bjsnider> Sarvatt, the 275 blob is still going to be a big problem because of the supported pciid script being broken right?
#ubuntu-x 2011-06-26
<Takyoji> What would be the most practical (and hopefully even automated) approach to regression testing this bug myself to hopefully get it finally resolved? https://bugs.launchpad.net/ubuntu-release-notes/+bug/763688
<ubot4> Launchpad bug 763688 in xserver-xorg-video-intel (openSUSE) (and 2 other projects) "[915GM] S-video output doesn't work in Natty (i386) (affects: 29) (dups: 1) (heat: 150)" [Undecided,New]
<Takyoji> Before myself, and those affected, go neurotic.
#ubuntu-x 2012-06-18
<tjaalton> http://memegenerator.net/Angry-Linus
<mlankhorst> :')
<mlankhorst> http://memegenerator.net/instance/22148640
<JanC> http://memegenerator.net/instance/22173609  ;)
<Cimi> hi guys, in quantal my X kbd layout is not set
<Cimi> and resets after suspend and such stuff..
<tjaalton> blame gnome
<Cimi> tjaalton: known bug?
<tjaalton> no, but sounds like gnome-settings-daemon isn't behaving
<Cimi> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1014656
<ubottu> Launchpad bug 1014656 in gnome-settings-daemon (Ubuntu) "Keyboard layout is not set" [Undecided,New]
<seb128> tjaalton, Cimi: gnome-settings-daemon didn't change since precise
<Cimi> seb128: well, doesn't work
<seb128> Cimi, yeah, I'm just saying
<Cimi> seb128: oh no
<Cimi> seb128: maybe it's ricotz PPA
<tjaalton> hah
<seb128> Cimi, try to ppa purge it?
<Cimi> seb128: trying to get it
<Cimi> ok, was it
<Cimi> I apologize
<seb128> Cimi, no worry, I'm the one who told you to try it to get the new gtk ;-)
<cnd> mlankhorst, where do we stand on getting the fixes in -synaptics 1.6.2 into precise?
<Sarvatt> ricotz: here's hoping this update builds, disabled dricore
<ricotz> Sarvatt, damn mesa :P
<Sarvatt> yeah 8.1 has been a nightmare with all the automakification :(
<ricotz> Sarvatt, i hope it doesnt need a newer wayland ;)
<Sarvatt> oh man
<ricotz> crossing fingers for now
<jcristau> isn't there a --disable-wayland or something?
<ricotz> yes, but we want it
<Sarvatt> jcristau: yeah its an inside joke, every time we manage to get the build fixed something like a newer wayland update is needed
<jcristau> :/
<mlankhorst> cnd: hm I'll ask RAOF about it :)
<cnd> mlankhorst, weren't you preparing srus for it?
<mlankhorst> i wanted to let it sit in quantal a little to watch for regressions, but I think it sat there long enough now :)
<cnd> ok
<bryceh> honestly we probably won't get much testing feedback until after alpha-2
<mlankhorst> bryceh: I know, but it's at least broken in any obvious way..
<bryceh> well, unless something breaks *really* bad ;-)
<mlankhorst> so can we sru it for precise?
<bryceh> mlankhorst, go for it
<bryceh> mlankhorst, keep in mind it'll get an additional couple week's testing as part of the sru process
<bryceh> speaking of releasing things...  for mesa 8.0.3 are we waiting on anything else?  anyone know of a reason not to put it in quantal now?
<mlankhorst> bryceh: yeah, the synaptics corruption I was getting, has that been sru'd yet?
<bryceh> mlankhorst, https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics
<mlankhorst> is that website overloaded? a lot of the time launchpad returns error
<bryceh> mlankhorst, works for me
<bryceh> mlankhorst, however lp does have time out problems.
<mlankhorst> yeah it pops up randomly, quite annoying though
<bryceh> mlankhorst, if it gives you an OOPS ID, you can file bug reports against launchpad and they'll investigate (and sometimes fix)
<bryceh> all they need is the OOPS ID, and maybe a sentence about what you did
<mlankhorst> it's random, eg works fine on reload
<bryceh> mlankhorst, they have some cache filling problems.  E.g. the first time the page isn't in the cache so it gets loaded
<bryceh> however launchpad times out before the load has finished, so oopses
<bryceh> but then you click reload and now it's in the cache so comes right up
<bryceh> :-/
<mlankhorst> yeah..
<bryceh> anyway
<bryceh> is 1.6.0-0ubuntu1~precise1 the version you're expecting to see in precise, or did you need a fix on top of that?  looks like it's been out for a few weeks now
<mlankhorst> 1.6.2 quantal has it minus the version bump
<mlankhorst> eg 1.6.1+something
<bryceh> mlankhorst, ok, what's the bug number?  Did you fill in the SRU details yet?
<mlankhorst> didn't find a form for it :/
<mlankhorst> ill look up the bug number, but brb
<bryceh> https://wiki.ubuntu.com/StableReleaseUpdates
<bryceh> mlankhorst, here's the form I use:  http://paste.ubuntu.com/1047726/
<bryceh> mlankhorst, you'll be filing many, many, many SRUs going forward, so worth bookmarking ;-)
<mlankhorst> bryceh: I mean, where do I send it in
<tjaalton> you modify the bug header
<bryceh> mlankhorst, yeah click the edit button next to the bug description and prepend it in there
<mlankhorst> ah ok, do I need to mark it in any way or just bring it up to the attention of RAOF ?
<bryceh> mlankhorst, when you've finished adding it, and the package has been uploaded to precise-proposed, you then subscribe the 'ubuntu-sru' team to the bug report, so they'll be notified and do a review
<bryceh> after that just follow up with the directions they give
<mlankhorst> regression potential is hard to identify though..
<bryceh> yeah
<bryceh> what I often do is describe what *types* of regressions one might watch for
<mlankhorst> ah k
<mlankhorst> and i bypassed sru for linux now, got the nouveau changes in stable queue :)
 * bryceh nods
<bryceh> that's the best way to do it
<bryceh> bbiab (lunch)
#ubuntu-x 2012-06-19
<bryceh> RAOF, tjaalton: any concerns if I upload the mesa 8.0.3 merge to quantal now?
<RAOF> I'm good with that.
<bryceh> alrighty
<bryceh> up it goes
<tjaalton> bryceh: yeah, thanks
<mlankhorst> hm, does xorg 1.12 have the signal safe stuff?
<jcristau> no
<jcristau> iirc
<tjaalton> not even a point-release?
<tjaalton> hmm was it the security fix or something else?
<tjaalton> got it now, apparently still under testing
<mlankhorst> but yeah updating my laptop now, might as well do a thorough sru of https://bugs.launchpad.net/ubuntu/precise/+source/xserver-xorg-input-synaptics/+bug/941953 and confirm it in quantal first :)
<ubottu> Launchpad bug 941953 in xserver-xorg-input-synaptics (Ubuntu Precise) "Xorg crashed with SIGSEGV in WriteToClient() with buf = 0x100000000 from ProcXIGetProperty()" [High,Triaged]
<mlankhorst> looks like my desk is getting too small already :)
<seb128> mlankhorst, hey
<mlankhorst> hey
<seb128> mlankhorst, how are you?
<mlankhorst> im good, you?
<seb128> mlankhorst, I'm good thanks
<seb128> mlankhorst, is there any reason you are not on #ubuntu-desktop? ;-)
<mlankhorst> woops must have left at one point and never rejoined
<seb128> mlankhorst, ok, Laney is having login issues and we were looking for xorg expertise ;-)
<seb128> is Xephyr segfaulting on precise for others as well?
<tjaalton> how do you use it?
<seb128> tjaalton, Xephyr :1
<seb128> DISPLAY=:1 somecommand
<seb128> rather
<seb128> - Xephyr :1 as my user
<seb128> su testuser
<seb128> DISPLAY=:1 gnome-settings-daemon
<seb128> which leads to a
<seb128> Backtrace:
<seb128> 0: Xephyr (xorg_backtrace+0x37) [0xea1107]
<seb128> 1: Xephyr (0xd02000+0x1a2e8a) [0xea4e8a]
<seb128> 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x25640c]
<seb128> every time
<jcristau> get a debug build and use gdb?
<seb128> no xserver-xephyr-dbgsym and xserver-xorg-core-dbg doesn't include it :-(
<seb128> I guess I will need to rebuild xorg
<seb128> http://pastebin.ubuntu.com/1048865/ is the non debug bt
<tjaalton> I ran xterm inside xephyr, and exiting it caused a similar segfault
<tjaalton> I think we have several of these reported against xserver
<seb128> tjaalton, do you have a number I can track and maybe milestone for 12.04.1? ;-)
<tjaalton> bug 1009629
<ubottu> Launchpad bug 1009629 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in DeliverRawEvent()" [High,Confirmed] https://launchpad.net/bugs/1009629
<seb128> tjaalton, thanks
<jcristau> possibly https://lists.debian.org/debian-x/2012/05/msg00240.html?
<jcristau> sadly no bt in that bug though
<tjaalton> in the lp one? right
<tjaalton> but does look similar
<jcristau> yeah looks the same
<jcristau> there's a revert in 1.12-branch that fixes it
<tjaalton> oh
<jcristau> 58dfb13953af71021317b9d85230b1163198f031
<tjaalton> I'll check it out
<tjaalton> uh, there was an sru to _add_ that code
<tjaalton> seb128: can you reproduce it with -0ubuntu10.1?
<tjaalton> if you can find it..
<seb128> tjaalton, let me try, do I need to downgrade only xserver-xephyr?
<tjaalton> seb128: maybe so, I think the code is builtin
<seb128> tjaalton, https://launchpad.net/ubuntu/+source/xorg-server/2:1.11.4-0ubuntu10.1 has the binaries if you want btw
<tjaalton> yeah I'll try it as well
<seb128> tjaalton, yeah, no segfault with that version
<tjaalton> confirmed
<tjaalton> bad cnd :)
<tjaalton> wonder if there was another fix upstream for the original bug
<seb128> cnd, no cookie for you!
<tjaalton> thanks jcristau for the pointer
<tjaalton> seb128: I added a note to the bug
<seb128> tjaalton, thanks
<seb128> tjaalton, who should be assigned to this bug? we want to make sure that regression is fixed before 12.04.1
<mlankhorst> seb128: pick me?
<seb128> mlankhorst, done, thanks ;-)
<mlankhorst> we'll probably move to 1.13 though
<tjaalton> not for precise
<RAOF> That's *totally* SRUable. No new features at all!
<tjaalton> :)
<mlankhorst> hehehe :P
<tjaalton> maybe the original bug would need to be reopened as well
<tjaalton> bug 968845
<ubottu> Launchpad bug 968845 in xserver-xorg-input-synaptics (Ubuntu Quantal) "bcm5974 touchpad doesn't work after S3 on MacBookAir" [Medium,Fix released] https://launchpad.net/bugs/968845
<seb128> while you guys are around
<seb128> could somebody look at https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/962892
<ubottu> Launchpad bug 962892 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __assert_fail_base() unless clear compiz/unity settings" [High,Triaged]
<seb128> it's getting quite some dups on launchpads and on errors.ubuntu.com
<tjaalton> what a messy bug
<tjaalton> looks like the duplicate bot isn't that helpful there
<tjaalton> some have fglrx loaded, mostly intel though
<mlankhorst> tjaalton: the original report is a assert(0) in intel ddx
<mlankhorst> so ignore the fglrx ones..
<tjaalton> right
<mlankhorst> seb128: I'm going to take a look :)
<seb128> mlankhorst, thanks
<tjaalton> yeah, i'll reboot instead
<seb128> tjaalton, mlankhorst: you can check the reports on errors.ubuntu.com as well they might have useful infos
<seb128> open http://errors.ubuntu.com, entry xserver-xorg-core in the entry and select "month" in the combo
<seb128> it's the first bug listed, if you click on the function you have the list of individual reports
<mlankhorst> 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])
<mlankhorst> specific error seems to be assert(0) when it can't identify the generation of bufmgr_gem->pci_device
<mlankhorst> but it should be recognising it as gen6 if I'm reading it right..
<tjaalton> it's also a hybrid system, like many on the bug
<tjaalton> of the dupes
<mlankhorst> i noticed, but running updates now to test
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/984189 is not hybrid though
<ubottu> Launchpad bug 962892 in xorg-server (Ubuntu) "duplicate for #984189 Xorg crashed with SIGABRT in __assert_fail_base() unless clear compiz/unity settings" [High,Triaged]
<mlankhorst> hm getting a different bug instead
<tjaalton> yeah not all dupes had hybrid
<mlankhorst> some early corruption in xserver-xorg
<mlankhorst> awesome :)
<tjaalton> i've unduped 984189
<tjaalton> looks like another snb crasher, probably fixed already
<mlankhorst> damageRegionProcessPending
<tjaalton> you can repro it?
<mlankhorst> I'm hitting another bug
<mlankhorst> damageRegionProcessPending for some reason
<mlankhorst> I'll see if I can attach valgrind again
 * mlankhorst looks for the signal patches again
<mlankhorst> yay, worth it
<mlankhorst> ==1651==  Address 0xdfdfdfdfdfdfdff7 is not stack'd, malloc'd or (recently) free'd
<tjaalton> i sent three drm/i915 commits to stable@, makes at least my ivb stable :)
<mlankhorst> so it seems my crash is caused by freed memory
<mlankhorst> my X server is called 'exec /usr/bin/valgrind --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" &> /home/mlankhorst/nfs/vg' :)
<mlankhorst> http://pastebin.com/xg2yfXKs
<cnd> tjaalton, seb128, mlankhorst: only Jeremy Huddleston saw the crash on OS X, so I didn't bother with reverting the added patch
<cnd> we will need to cherry-pick a couple of patches that fix it cleanly, IIRC
<seb128> cnd, it happens every time you use Xephyr and close a client
<cnd> fun
<mlankhorst> weird.. I'll try upstart xf86-video-intel
<cnd> mlankhorst, did you chat with RAOF about synaptics?
<tjaalton> cnd: btw, is the precise xserver missing some input fixes from 1.12.x? can't recall what it maps to
<tjaalton> i mean _other_ fixes ;)
<cnd> tjaalton, it maps to 1.12.1 + the patches in debian/patches
<mlankhorst> cnd: ugh some other issues popped up in between, I wanted to reproduce it on this laptop first with valgrind but it dies in a new way I haven't seen before
<cnd> for input
<tjaalton> oh right
<tjaalton> yeah
<mlankhorst> I'll try the other one
<cnd> mlankhorst, do you have a macbook?
<mlankhorst> nope
<cnd> mlankhorst, then there's a low chance you'll be able to reproduce it easily
<cnd> I can only reproduce it on a macbook air
<mlankhorst> cnd: k
<mlankhorst> which issue specifically?
<cnd> mlankhorst, when you close the lid, the screen interacts with the touchpad and causes many dancing touches
<cnd> and then the device is disabled for suspend
<cnd> the touches aren't disposed of properly
<cnd> so on resume, some touches may be "stuck" as active
<mlankhorst> ah k
<seb128> I guess you can probably fake that playing with the lid contact on a normal laptop :p
<mlankhorst> was thinking the same
<mlankhorst> just echo mem > /sys/power/state
<mlankhorst> wait.. why does irssi have tab completion for that?
<Prf_Jakob> So yeah, you guys need to blacklist the AMD SI driver from Unity.
<Prf_Jakob> No cayman
<mlankhorst> hm, just running X with valgrind is providing plenty of amusement..
<mlankhorst> bryceh/RAOF: If we decide to push x 1.12, can we upstream the signal safe patches too and force some testing with valgrind?
<bryceh> mlankhorst, some patches can be upstreamed (and are on my todo list), but a few are not going to be acceptable upstream
<mlankhorst> I mean, I was tracking why i915 was refusing to log in only to notice that upstream added another regression on top :s
<mlankhorst> and seeing how many different bugs in x org are memory based it would be nice to have as feature..
<tjaalton> how do you force testing with valgrind?-)
<mlankhorst> create a shell script  X2 with contents:
<mlankhorst> exec /usr/bin/valgrind --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" &>> /home/mlankhorst/nfs/vg.$(hostname)
<mlankhorst> look for any suspicious read/write errors or crashes
<mlankhorst> bryceh: hm any thoughts on this ? http://pastebin.com/qFpTpMzx
<bryceh>     drawableDamage(pDrawable);
<bryceh> hmm
<mlankhorst> df is my valgrind free-fill
<mlankhorst> but from whatI can tell it should only nuke that drawable if refcount drops to zero, which it did.
<bryceh> I wonder if it's caused by this cast:
<bryceh>     return (char *) (*privates) + key->offset;
<mlankhorst> don't think so, it just looks like that's how it registers private data into it
<bryceh> or something.  the "Invalid read of size 8" errors are complaining about differences in variable sizes
<mlankhorst> I think it's simply reffing the damage after the pixmap was freed, but I don't see how..
<seb128> mlankhorst, I'm not a valgrind expert but --leak-check=full might help to stop where it was freed
<seb128> mlankhorst, not sure if --leak-resolution=high does the same
<seb128> mlankhorst, I just know that the one we listed is on our standard set of flags for desktop debugging
<mlankhorst> seb128: no that's on exit
<seb128> ok
<mlankhorst>        --leak-check=<no|summary|yes|full> [default: summary]
<mlankhorst>            When enabled, search for memory leaks when the client program finishes. If set to summary, it says how many leaks occurred. If set
<mlankhorst>            to full or yes, it also gives details of each individual leak.
<mlankhorst> I need to set --track-origins=yes though
<mlankhorst> more slowdown :)
<bryceh> mlankhorst, yeah not sure what's going on there.  If you got a reproducible case, might chat with ickle
<mlankhorst> bryceh: yeah seems to happen on upstream intel too
<mlankhorst> it's annoying since it blocks login
<mlankhorst> hm just to be sure I'll try without valgrind patch
<mlankhorst> bryceh: hm, at this point I'm not even 100% sure it's intel specific, I'll cut down on other options
<mlankhorst> https://bugs.freedesktop.org/show_bug.cgi?id=51240 added :)
<ubottu> Freedesktop bug 51240 in Driver/intel "[i915] crash in damageRegionProcessPending on login" [Normal,New: ]
<mlankhorst> hm was afraid of that, some changes between x 1.11 and x 1.12
<Sarvatt> mlankhorst: i dont even see that commit in xserver at all
<mlankhorst> Sarvatt: well with the x 1.12 I uploaded to x-staging ppa things work, so I guess there's probably some truth to it
<bryceh> Sarvatt, hey I'm looking at the gpu lockup udev rule.
<bryceh> currently we trigger on ERROR=1 from the kernel.  there is also a RESET=1 which apparently happens later but still prior to the reset
<bryceh> one of the Intel guys suggested moving to RESET=1 might eliminate the false gpu lockups
<Sarvatt> sounds right to me, we did it on ERROR=1 before to grab an intel_gpu_dump of the actual crash before but its automatically captured in debugfs now
<bryceh> right
<bryceh> Sarvatt, ok...  I'll test it on a couple systems but expect to have it in within the week; ping me if you spot anything wonky... I think you tend to notice gpu weirdness before anyone else here :-)
<mlankhorst> night all :)
 * bryceh waves
#ubuntu-x 2012-06-20
<mlankhorst> morning
<RAOF> Aloha!
<mlankhorst> so it seems intel works on x 1.12 but broke on earlier, sigh :S
<tjaalton> broke?
<tjaalton> what broke it
<mlankhorst> crashes on some damage when I try to start it
<mlankhorst> so I'm trying to bisect xserver now for it
<tjaalton> but this is quantal?
<tjaalton> i'm just confused :)
<mlankhorst> im trying to make this one start on precise at least, the x1.12 ppa works on precise
<mlankhorst> so -> bisection time
<mlankhorst>  ah perfect, the part where it bumped video abi still triggers crash
<mlankhorst> hm, I think bisecting kernel is more pleasant than X..
<mlankhorst> oddly enough now the 1.12 version is crashing too, i swear it worked before, but maybe that was without valgrind
<mlankhorst> RAOF: is the osvendorfatalerror needed in the rethrow signals xorg-server patch
<mlankhorst> cnd: ping?
<mlankhorst> interesting.. another valgrind issue
<mlankhorst> victim being radeon on suspend/resume it seems
<cnd> mlankhorst, pong
<mlankhorst> cnd: in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/968845 you mention a xorg-xserver patch that has to be reverted due to another bug
<ubottu> Launchpad bug 968845 in xserver-xorg-input-synaptics (Ubuntu Quantal) "bcm5974 touchpad doesn't work after S3 on MacBookAir" [Medium,Fix released]
<mlankhorst> https://bugs.launchpad.net/ubuntu/precise/+source/xorg-server/+bug/1009629
<ubottu> Launchpad bug 1009629 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGSEGV in DeliverRawEvent()" [High,Triaged]
<cnd> yes?
<mlankhorst> is that x server patch really required for the other bug to be fixed?
<cnd> a fix is required, but there's a new set of patches that fixes it properly
<cnd> see http://cgit.freedesktop.org/xorg/xserver/log/
<cnd> everything from "include: add BUG_RETURN_* macros" to "dix: disable all devices before shutdown" I think
<mlankhorst> ah k
<mlankhorst> does it need any fixes in synaptics as well?
<jcristau> that set wasn't considered suitable for the stable branch though
<mlankhorst> jcristau: hm I am tempted to send in a patch for server that reverts to the old behavior at least, quickly reviewing up to drop client argument reveals no functional change so that part could be skipped..
<cnd> jcristau, why not?
<cnd> is it an abi breaker?
<jcristau> because it's a rabbit hole, aiui
<cnd> mlankhorst, we still need synaptics 1.6.2
<cnd> and we will still need this bug fixed in the server
<cnd> whether it's by backporting all those patches or just creating a smaller patch to do the same thing on our server
<mlankhorst> ok I'm not a xorg dev but looks like we'd need to pick 'dix: return early from DisableDevice if the device is already disabled' onwards only, but freeing sprite when device is disabled looks risky for stable.
<cnd> yeah, the previous patches just may include functionality that is used in these patches
<cnd> we could remove any instances of BUG_RETURN_VAL
<mlankhorst> I'll use my memory corruption for justification of synaptics 1.6.2 then :)
<mlankhorst> those seem functionally identical so yeah could be dropped
<cnd> mlankhorst, I can't tell if the bad patch is supposed to be reverted though
<cnd> or just left as is, with these new fixes on top
<mlankhorst> I'll just check if that git tree has it
<cnd> I'm trying to figure out
<cnd> yeah
<mlankhorst> judging from http://cgit.freedesktop.org/xorg/xserver/commit/?id=4c68f5d395c66f28b56e488cb3cd12f36820357b it was supposed to be kept in
<cnd> yeah
<mlankhorst> I'll test 
<mlankhorst> if Xephyr is broken still on top of those I'll sru the revert patch for now
<mlankhorst> only 1 patch has to be adjusted fortunately
<mlankhorst> cnd: one question though, http://cgit.freedesktop.org/xorg/xserver/commit/?id=e433d1046c222f9d969c2c28a4651ff9097614f4
<mlankhorst> dev->enabled is set last, wouldn't it be possible for DisableDevice to be called twice on same device as result?
<mlankhorst> probably not possible due to semantics, but I thought I'd ask :)
<jcristau> the server is single threaded
<jcristau> and i don't think you get to call disabledevice from a signal handler
<mlankhorst> jcristau: I mean more because of the additional disabledevice call there
<jcristau> ah
<jcristau> stupid me
<jcristau> i don't think the if would fire for both paired devices
<mlankhorst> neither, just wanted to have confirmation from someone who understands the code better :)
 * jcristau shuts up :)
<cnd> mlankhorst, yes, this shouldn't be an issue if I understand things right :)
<cnd> tbh, I don't know all the ins and outs of paired devices and how they are implemented
<cnd> whot is probably the only one who does
<mlankhorst> im guessing one of them has to be sprite owner
<cnd> yeah
<mlankhorst> in either case refreshed those patches on x1.11, seems to fix the Xephyr issue.
<mlankhorst> cnd: can you upload to proposed?
<mlankhorst> or anyone? :)
<cnd> mlankhorst, I can
<cnd> do you have a package ready?
<mlankhorst> yeah it's in xorg-server ubuntu-precise branch
<mlankhorst> brb food
<cnd> mlankhorst, ok, I'll review and upload
<cnd> thanks!
<cnd> mlankhorst, uploaded to precise-proposed
<mlankhorst> thanks :)
<mlankhorst> I added ubuntu-sru to the bug report, do I need to do anything else?
<seb128> mlankhorst, https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<seb128> mlankhorst, basically your bug need "impact", "regression potential" and "test case" in its description
<seb128> mlankhorst, and to be nominated for precise ... what bug number is that?
<mlankhorst> seb128: those are in the bug :) https://bugs.launchpad.net/ubuntu/precise/+source/xorg-server/+bug/1009629
<ubottu> Launchpad bug 1009629 in xorg-server (Ubuntu Precise) "Xorg crashed with SIGSEGV in DeliverRawEvent()" [High,Triaged]
<seb128> mlankhorst, ok, you are all set then
<mlankhorst> perfect, thanks :)
<seb128> mlankhorst, I've put the precise line to fix commited
<seb128> since that got uploaded
<mlankhorst> ah k
<seb128> mlankhorst, you should probably get the fix in quantal as well, or at least in the package vcs for quantal
<mlankhorst> it is
<seb128> mlankhorst, the SRU team likes to make sure issue will be addressed in the devel version as well
<seb128> mlankhorst, ok, then probably put the bug from confirmed to fix commited
<mlankhorst> cnd: can you upload xserver-xorg-input-synaptics ubuntu-precise branch too after I verify it? And maybe upload ubuntu branch to quantal so that version in quantal won't be lower than precise.
<cnd> mlankhorst, sure, just let me know when you're done verifying
<cnd> thanks!
<mlankhorst> I verified it with the quantal package so you can upload that one at least (since it's just a version bump)
<mlankhorst> ok precise one too :)
<mlankhorst> Tomorrow I'm going to take a look at why valgrind is throwing errors at radeon suspend, noticed that when testing synaptics. Hopefully after that my radeon laptop shows up no errors with valgrind any more. :)
<ernstp> looks like the radeon module in no longer included in linux-image from 3.4 builds and on
<ernstp> both precise and mainline
<ernstp> it boots with vesafb and then I can't access the computer when xorg starts actually, still ssh though
<ernstp> I mean qunatal and mainline
<jwi> ernstp: install the *-image-extra-* package
<dupondje> Hi some small question. How about Optimus support in Quantal? Something got in yet or ?
<mlankhorst> >implying support is available upstream
<mlankhorst> ;)
<dupondje> having bumblebee would be a great step imo ...
<jcristau> hahaha
<jcristau> you must be kidding
<mlankhorst> bumblebee is a great step, it's in the wrong direction though..
<dupondje> why ?
<dupondje> bumblebee is not THE solution indeed
<mlankhorst> it's unmaintainable and upstream work is already being done with dmabuf
<dupondje> I just want a solution so I can disable my second vga card
<dupondje> cause in a laptop, its a power drain
<jcristau> why did you buy it then?
<dupondje> because else it works fine :)
<dupondje> its better having a partial solution then nothing no ?
<jcristau> no
<mlankhorst> not if the solution is WRONG :(
<jwi> as long as you don't have to maintain it...
<dupondje> whats the plan for Quantal then ?
<mlankhorst> upstream the prime bits
<dupondje> which will take care of suspending the second vga card ?
<mlankhorst> dupondje: Hopefully, but that hasn't been completed yet :)
<dupondje> where can I follow its status ? :)
<mlankhorst> follow x server commits, especially xrandr related ones currently
<dupondje> ok thanks!
#ubuntu-x 2012-06-21
<scientes> can someone add the modesetting drive to xorg-edgers?
<mlankhorst> hey
<RAOF> Ho!
<scientes> why does one touchscreen i have (multitouch) do scrolling (rubber-banding scrolling) in nautilus, and the other (single-click touchscreen) does selecting in nautilus, on the exact same machine at the same time?
<RAOF> You'll need to describe the situation better.
<RAOF> Fundamentally - because the multitouch one can detect two fingers, so can (and will) do two finger scrolling, whereas that's impossible on the single touch.
<scientes> i'm only using one finger
<scientes> but i see a fundamentally differn' behavior
<scientes> i cannot do a drag-select on the multitouch monitor
<RAOF> Sounds like someone's got a broken driver!
<scientes> basically i want the elastic-scrolling
<scientes> xorg detects it as a touchscreen
<scientes> and the driver is usbtouchscreen.c
<scientes> (the single touch one)
<scientes> let me see on the multitouch
<scientes> hmm i forget how to query udev, its /dev/input/event4
<scientes> I have a multi-seat setup here
<RAOF> Xorg.0.log will tell you what X driver it's using (presumably evdev); udevadm info --name=/dev/input/event4 --query=all will give you the udev info.
<scientes> http://paste.debian.net/175569/
<scientes> yeah the multitouch one has usbhid as driver (isn't that just the general driver, not end driver???)
<scientes> hmm the one that is working fine is full of BUS stanzas....... http://paste.debian.net/175570/
<RAOF> That's the one that's working fine?
<mlankhorst> hey :P
<mlankhorst> morning alll
<RAOF> Good morning again :)
<mlankhorst> RAOF: when do things show up in https://launchpad.net/ubuntu/precise/+queue?queue_state=1 ? Missing synaptics there
<RAOF> Ah, we've managed to get that queue down nicely ;)
<RAOF> mlankhorst: < 30 minutes after a successful upload.
<mlankhorst> my investigative skills tells me that the upload must have failed then
<mlankhorst> cnd?
<RAOF> mlankhorst: What version were you expecting? xserver-xorg-input-synaptics | 1.6.0-0ubuntu1~precise1 | precise-updates | source, amd64, armel, armhf, i386, powerpc is presumably not it?
<mlankhorst> woops, needs version bump
<mlankhorst> that explains, I forgot to push ubuntu-precise :)
<mlankhorst> RAOF: can you upload ubuntu-precise branch of xserver-xorg-input-synaptics? Should be 1.6.2-1ubuntu1~precise1
<RAOF> Sure.
<mlankhorst> btw valgrinding is fun, found another issue with suspend
<mlankhorst> radeon this time
<RAOF> mlankhorst: What 12.04 bugs does that upload fix? It's not clear from the changelog, and it'd make it much easier to review if we had that :)
<mlankhorst> it should be clear if you added -v 1.6.0-0ubuntu1~precise1
<mlankhorst> 1.6.2 is all the patches of 1.6.1-1ubuntu1 rolled into a version bump upstream
<mlankhorst> LP: #941953
<mlankhorst> bug 941953 ?
<ubottu> Launchpad bug 941953 in xserver-xorg-input-synaptics (Ubuntu Precise) "Xorg crashed with SIGSEGV in WriteToClient() with buf = 0x100000000 from ProcXIGetProperty()" [High,Fix released] https://launchpad.net/bugs/941953
 * mlankhorst pokes ubottu 
<RAOF> 941953 972727 are the two bugs it fixes?
<RAOF> Ah, well apart from 972727.
<RAOF> It's still not clear from the top changelog entry why we're doing this; I'm not going to be doing the SRU review, so you want to make it as easy as possible to see what's happening :)
<mlankhorst> yeah the real changelog entry is 1.6.1-1ubuntu1 
<RAOF> mlankhorst: Can I suggest adding something to the most recent changelog entry like âNew upstream version fixes memory corruption, causing crashes (LP: #941953)â; that'll make it obvious why we're doing this.e
<mlankhorst> RAOF: hm true, could you upload the diff to debian/changelog in precise? I'll give it another shot
<RAOF> I'm not sure what you're asking for there, sorry :/
<RAOF> Where do you want the diff uploaded?
<mlankhorst> erm did you upload the package yet or not?
<RAOF> (Also, what diff?) âº
<RAOF> No, I've not yet uploaded the package.
<mlankhorst> ah k then nm :)
<RAOF> I stopped during my regular pre-upload checks to ask you questions ;)
<mlankhorst> RAOF: Shall I just change that version from ~precise1 to ~0quantal to emphasize that is the changelog for quantal and add another 1.6.2-1ubuntu1~precise1 version on top that contains the reasoning for having it in precise? eg referencing bugs in 1.6.1-1ubuntu1
<RAOF> mlankhorst: Nah, I don't think that's necessary.
<RAOF> Incidentally when *are* we uploading 1.6.2 to quantal?
<mlankhorst> oh that should already have been done..
<RAOF> Need a sponsor for that? âº
<mlankhorst> yeah just upload the ubuntu branch :)
<mlankhorst> RAOF: can you check if it looks better now?
<RAOF> Looks much better, thanks.
<RAOF> Urgh, reindenting.
<mlankhorst> yep :S
<RAOF> How much effort would it be to cherry-pick those patches instead?
<mlankhorst> too much, and you would create a new work, now it's just the same version as we have in quantal
<RAOF> Eeeerguh
<RAOF> Uploaded; please make that case on the bug, though.
<RAOF> Now, to the PIZZA!
<jcristau> incidentally when's quantal getting 1.12? :)
<mlankhorst> after alpha2 right?
<mlankhorst> although we might want to upload those xorg-server input patches that are in proposed now before that.
<jcristau> do you guys have info on when fglrx will finally work with 1.12 btw?
<mlankhorst> sigh, forgot how much fglrx lags
<jcristau> i think it's supposed to work now except it's broken on 64bit
<mlankhorst> RAOF: http://pastebin.com/PucL1weS any ideas?
<mlankhorst> hm nm think i understand it
<mlankhorst> randr1.2 thought it was being smart.. naughty
<mlankhorst> and with inspiration from https://lwn.net/Articles/446631/ I found a few alikes :)
<mlankhorst> might explain why someone else complained about suspend crashing
<mlankhorst> bumping video abi in a stable release is not done, right? ;)
<jcristau> correct :)
<mlankhorst> i know, would have been easier to convert something to a static string rather to find out where it's all going wrong
<mlankhorst> http://pastebin.com/Hn3vxDVw
<mlankhorst> that looks ok? Fix valgrind error on suspend
<jcristau> doesn't look crazy to me in any case
<mlankhorst> I'll check with the X devs to be sure, maybe there's a lifetime semantic to preferred mode
<mlankhorst> bryceh: can we upload the new video drivers early?
<Sarvatt> so what to do about x-x-v-ati? quantal needs an update to work with cairo 1.12 and we have that darn 6.14.99. is.really.6.14.4-5ubuntu1?
<Sarvatt> scientes: its up there now
<mlankhorst> Sarvatt: basically what I said ;)
<jcristau> Sarvatt: 7 is coming soon anyway :)
<jcristau> the no-ums branch
<Sarvatt> woohoo
<mlankhorst> and nouveau bumped to 1.0.1 :x
<Sarvatt> poor powerpc
<mlankhorst> what would prevent kms working for powerpc?
<Sarvatt> agp not working for starters
<jcristau> it sometimes works
<jcristau> i know michel has been running on kms for years on his ppc
<Sarvatt> i gave up on my ibook around 2.6.31
<mlankhorst> sounds more like not enough people care then, anyhow
<Sarvatt> yeah needed to explicitly disable agp, and then there were all kinds of mesa problems
<mlankhorst> Sarvatt: it sounds like nobody really cared enough then to really fix it
<jcristau> when they hear the word agp people run away for some reason
<mlankhorst> well now they have no choice :x
<Sarvatt> especially uninorth
<mlankhorst> well looks like google has to pay oracle 0$ http://www.groklaw.net/article.php?story=20120620140533395
<mlankhorst> wonder how you do that..
<bryceh> mlankhorst, yep can upload drivers whenever, assuming the required bits are in place.
<mlankhorst> bryceh: let me check the big 3 just in case
<mlankhorst> intel was uploaded already
<mlankhorst> bryceh: ok ati can be uploaded
<bryceh> alright
<mlankhorst> nouveau might be picked up already due to not having precise changes
<mlankhorst> if so can you sync with 1.0.1 ?
<bryceh> mlankhorst, did you use the tarball from debian or re-roll a new git snapshot?
<bryceh> and if the latter, got a link to the new orig tarball handy?  or shall I roll one locally
<Sarvatt> Prf_Jakob: any reason why enable_fbdev shouldn't default to on in the kernel?
<mlankhorst> bryceh: for ati I don't know, I can't upload directly :)
<mlankhorst> but just use sid
<Prf_Jakob> Sarvatt: theoratically we can handled the kernel driver and the old driver at the same time.
<mlankhorst> the debian tarball will work since it's just a small change compared to debian
<mlankhorst> the only reason we have a custom version was a single patch iirc
<Prf_Jakob> Sarvatt: I have been pushing for it to be turned on by default other devs have been pushing against.
<Prf_Jakob> Sarvatt: going to add a config for it
<bryceh> mlankhorst, are you certain?  looks like debian carries version 6.14.4, whereas we're carrying a git snapshot; is it clear that 6.14.4 is a superset of the git snapshot?
<bryceh> if it is, then we probably ought to adjust the version (ugh) to reflect that
<jcristau> pretty sure a snapshot from december is older than 6.14.4, yes.
<jcristau> seeing how 6.14.4 was from march 29
<mlankhorst> bryceh: hm not 100%, but debian does versioning different..
<bryceh> jcristau, well I'm more thinking if there was a stable 6.14.x branch separate from master.  But that doesn't appear to be the case
<jcristau> right they cut releases from master
<bryceh> also the proposed merge is versioned 1:6.14.99~git20120608.9425c50e-0ubuntu1, suggesting it has an updated git pull
<bryceh> 6.14.4 was from 03-29, but 0608 suggests a pull from current git tip
<jcristau> yeah that looks wrong
<jcristau> should be 6.14.4~really6.14.4 :)
<jcristau> err
<jcristau> 6.14.99~really6.14.4 i mean
 * bryceh nods
<bryceh> yeah the git history looks like it's 6.14.4 plus some cherrypicks from debian
<mlankhorst> ah k i might have screwed up then
<jcristau> it's annoying how they bump the version post release only to decrease it again before the next one
<bryceh> mlankhorst, version numbers in situations like this are always tricky
<bryceh> jcristau, yeah
<bryceh> so...  1:6.14.99~really6.14.4-5ubuntu1 ?  does that look right? or should it be -0ubuntu1?
<jcristau> yeah -0ubuntu1 i think
<bryceh> hmm, one downside is this may make it tougher to go back to the old style git naming if we start doing git snapshots of master again
<bryceh> well, s/tougher/messier/
<jcristau> as i said i expect 7.0 before long for the ums kill
<jcristau> so hopefully it won't be a long term thing
<mlankhorst> bryceh: after that we can go back to debian anyhow, modesetting=1 patch will become useless :>
<bryceh> ah, ok no prob then
<mlankhorst> so we would be synched at 7.0 again
<bryceh> hmm, pbuilder is unhappy
<jcristau> mlankhorst: right
<mlankhorst> it's just for now so that people get no graphical glitches
<mlankhorst> bryceh: do you know someone affected by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/966744 ?
<ubottu> Launchpad bug 966744 in linux (Ubuntu) "Resume from suspend leaves me with black screen or a screen of the desktop before it suspended (though the mouse still moves/changes cursor)" [High,Triaged]
<mlankhorst> suspecting 2:1.11.4-0ubuntu10.4~0notreally1 will help, which is basically valgrind fix
<bryceh> mlankhorst, no I don't
<bryceh> mlankhorst, you might stick that in a precise ppa and request people on that bug give it a test
<mlankhorst> bryceh: well one of the bug reports hint at a xorg crash
<bryceh> -ati uploaded
<mlankhorst> bryceh: ah k do you know what nouveau version is used?
<bryceh> DIST=quantal chet version xserver-xorg-video-nouveau
<bryceh> xserver-xorg-video-nouveau  quantal  1:1.0.1-1
<mlankhorst> ok perfect
<mlankhorst> bryceh: that should fix all glitches then at least :)
<bryceh> mlankhorst, got anything else needing sponsored while I'm at it?
<mlankhorst> I'm going to be playing more with valgrind tbh, it's not that much of a performance hog.
<mlankhorst> but nope got a few things sru'd atm :)
<mlankhorst> bryceh: will we upload x1.12 too?
<bryceh> maybe; we should see what RAOF thinks
<bryceh> he's been handling the xserver transitions the last few cycles, I've assumed this would be on his todo list here too
<mlankhorst> I had a x1.12 ppa in x-staging but drivers are outdated now :)
<tjaalton> my 2 vacation-cents, but maybe the driver uploads should've gone to the ppa until the whole stack got moved to quantal :)
<tjaalton> binary-copied, whatev
<bryceh> tjaalton, mah
<bryceh> er, meh
<tjaalton> i mean, since it's just a lever to pull
<tjaalton> is there anything else holding back 1.12?
<bryceh> tjaalton, -nouveau probably got auto-sync'd.  -ati's gone a long time since last merge, and we pull patches for it frequently enough
<bryceh> tjaalton, we wanted to wait about a month to focus on sru's, and it's been about a month.  figure it could go in any time
<mlankhorst> tjaalton: No, we need to upload drivers now so using quantal is actually _USEFUL_
<mlankhorst> instead of glitching like crazy
<bryceh> but dunno if raof has some master plan for it
<mlankhorst> bryceh: we can't binary copy now at least, would have to set up the ppa again
<tjaalton> uploads are cheap, i know that
<mlankhorst> i mean version conflicts with the x-staging ppa :)
<tjaalton> conflicts?
<tjaalton> the ppa has older versions, sure
<mlankhorst> yeah that's why i said it would have to be redone
<tjaalton> ust jpload the next one there and then copy
<mlankhorst> yeah
<mlankhorst> but I'd need the ok from raof for it
<tjaalton> he should be awake any minute now :)
<tjaalton> i'm not even running quantal so no idea what it looks like atm
<tjaalton> but precise .1 is looking better
<tjaalton> pre-proposed anyway
<mlankhorst> lets upload nouveau to .1 "what could possibly go wrong" ;)
<tjaalton> heh
<mlankhorst> see if they are doing their job by uploading 1.0.0 with the massive memory leak
<bryceh> ahem "they" includes "us" ;-)
<mlankhorst> :D
<mlankhorst> aww responsibility sucks
<bryceh> quite true
<mlankhorst> but no im quite paranoid, uploading to stable freaks me out. :P
<mlankhorst> bryceh: oh btw you can run xorg quite nicely in valgrind with nouveau/r600, it still ends up faster than pandaboard. :)
<Sarvatt> mlankhorst: ever seen http://wiki.debian.org/XStrikeForce/git-usage ?
<mlankhorst> Sarvatt: yeah had to use it for rebasing a few times :)
<mlankhorst> getting xorg-server forwarded to 1.12 iirc
<Sarvatt> good to use that workflow if you mess with the debian branches, dri2proto :P
<mlankhorst> woops
<mlankhorst> what did I mess up?
<Sarvatt> upstream-unstable first then merge that in
<mlankhorst> ah k
<mlankhorst> darn that needs automation badly
<Sarvatt> ChangeLog has to be manually updated too
<mlankhorst> how about I hide in shame, revert that commit tomorrow and redo it properly. :P
<mlankhorst> night
<bryceh> cya
<RAOF> I'm happy to move 1.12 to quantal.
<RAOF> We're not waiting for mesa to settle down?
<mlankhorst> I think we won't have to do mesa yet necessarily, right?
<RAOF> No, we don't.
<mlankhorst> I could probably set up a ppa again tomorrow, but bed time now :)
<RAOF> We might as well upload to quantal-proposed.
<RAOF> Then once everything's built, we can easily copy to quantal.
<mlankhorst> ah sure go for it :)
<mlankhorst> it's just the video drivers needing a bump iirc
<Sarvatt> 817905
<Sarvatt> argh darn yubikey nano goes off every time the laptop is moved
<Sarvatt> RAOF: how's gods and kings?
<RAOF> Not yet played :)
<RAOF> Last night was board gaming; Space Alert and 7 Wonders.
<RAOF> Which I didn't win at, but Sam won both games of 7 Wonders.
<RAOF> Which, if you haven't played it, is an excellent fast 7-player game.
<bryceh> I just checked for bugs since the mesa 8.0.3 upload... nada
<Sarvatt> bryceh: ati and nouveau have both been broken with bad corruption since cairo was uploaded over a month ago and i just heard about it today.. i think a lot of people are sticking to precise :)
 * Sarvatt included
<RAOF> Strangely I haven't noticed that corruption.
<Sarvatt> i mean we knew it was broken from cairo 1.12 going into debian before precise released
<RAOF> And I *have* been nouveauing on and off.
<bryceh> Sarvatt, could well be
<bryceh> I too have been staying on precise, mainly to  stay focused on srus
#ubuntu-x 2012-06-22
<mlankhorst> RAOF: because I did work on debian probably, if if autosynced with debian it got all fixes
<Sarvatt> oh yeah there was a 0614 checkout you did synced before that, didnt realize nouveau didnt have a delta
<bryceh> RAOF, for the 1.12 transition, do you plan to handle all the packaging work, or do you want help with that?  If so, mind making us a todo list?
<RAOF> mlankhorst has already done basically all the work; all I need to do is review and upload. I should be able to do that today.
<bryceh> RAOF, excellent
<mlankhorst> morning
<mlankhorst> RAOF: did you get anywhere with reviewing? :)
<RAOF> mlankhorst: You may note that quantal-proposed contains everything but xf86-video-ati :)
<mlankhorst> ah k
 * RAOF â dinner
<mlankhorst> perfect, I can think about how to synch multiple devices in prime then since nobody is coming forward :)
<mlankhorst> amount of lines of code written today: 0.. :)
<debfx> could you please include virtualbox in the xserver transition? it should work fine with 1.12.
<mlankhorst> debfx: I can't upload, it should have been part of it though. :)
<mlankhorst> RAOF?
<debfx> I haven't actually test built it with q-proposed but it works in Debian.
<RAOF> debfx: Certainly; it should be a part of the transition.
<mlankhorst> gogo :)
<mlankhorst> I have great plans for lockdep, it shall die a horrible death. :P
<idleone> need some help here. I am running Kubuntu+1 and when I try to login via the GUI it takes me right back to the login manager
<mlankhorst> bryceh: Done with work for today, end result: http://pastebin.com/7bmEtyxa
<mlankhorst> :>
<mlankhorst> it's for prime device synchronization, there was so much potential for deadlocks, but I think this is the final solution that works...
<bryceh> mlankhorst, nifty
<mlankhorst> bryceh: yeah it was a headache for today, monday I'll try implementing it
<scientes> can ubuntu look decent on super-high-resolution displays?
#ubuntu-x 2012-06-24
<18VAATKUN> Hey
<18VAATKUN> I would like to report a  bug
<18VAATKUN> resuming after suspending to ram breakes
<mlankhorst> bug 994688
<ubottu> Launchpad bug 994688 in xorg-server (Ubuntu) "Xorg crash" [High,Opinion] https://launchpad.net/bugs/994688
<18VAATKUN> it start happens after updating nvidia driver to the
<18VAATKUN> 302.17
<mlankhorst> oh nvidia one
<18VAATKUN> yea nvidia
<18VAATKUN> 8600mgt 512ram
<18VAATKUN> :P
<mlankhorst> there was one for nvidia too on launchpad
<mlankhorst> https://bugs.launchpad.net/bugs/1008515 ?
<ubottu> Launchpad bug 1008515 in nvidia-graphics-drivers (Ubuntu) "Compiz crash on resume from suspend w/ NVIDIA 302.11 driver" [Undecided,Confirmed]
<18VAATKUN> I dont have compiz 
<18VAATKUN> I have kubuntu 12.04 64
<mlankhorst> does it use the composite extension?
<18VAATKUN> yea
<18VAATKUN> kwin
<18VAATKUN> but actualization is great
<mlankhorst> might stilll be the same bug then
<18VAATKUN> reall time changing and detecting displays with full color and resolution without relogin :D
<mlankhorst> like nouveau had for ages? :p
<18VAATKUN> I've always used nvidia properity driver
<18VAATKUN> and when I connect TV i had to restart x to vave colour
<18VAATKUN> :(
<18VAATKUN> it was annoing
<mlankhorst> seems like it could be the same bug though
<18VAATKUN> I hope and I am waitting for solution :D
<18VAATKUN> what about installations  nouveau
<18VAATKUN> thanks
<penguin42> can someone have a peak at bug 774434 - my suspicion is that it should be assigned to something other than xserver-org-input-evdev, I'm suspecting it's more video rather than input related
<ubottu> Launchpad bug 774434 in Ubuntu "mouse pointer disappears in ubuntu (11.04 onwards...)" [Low,Confirmed] https://launchpad.net/bugs/774434
<toabctl> can someone have a look at https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1017243 ?
<ubottu> Launchpad bug 1017243 in mesa (Ubuntu) "Program received signal SIGBUS, Bus error." [Undecided,New]
#ubuntu-x 2013-06-17
<hyperair> Sarvatt_: okay, i think my gpu hangs are related to multihead. over the weekend my laptop didn't hang, but an hour or so after i plugged it into the monitor at work, it hung again.
<hyperair> and my i915_error_state complains about not being able to allocate memory again.
<hyperair> oh, vm/drop_caches=2 fixed that.
<RAOF> hyperair: Hm, I was maybe noticing something similarish, but I think that got fixed.
<hyperair> RAOF: which one? the gpu hang or the unable to allocate memory issue?
<RAOF> GPU hang.
<hyperair> ah
<hyperair> which component's at fault here?
<hyperair> the i915 kernel module or X?
<RAOF> Hangs are always the kernel's fault :)
<RAOF> But plausibly upgrading either could help.
<hyperair> so the kernel got fixed recently?
<RAOF> I'm not sure; I'm on Saucy, so things are moving fairly quickly.
<hyperair> ah, i see
<hyperair> is saucy running 3.10?
<hyperair> In the past there was also the problem of not having a way to âcloseâ a branch, which means that over time the list of branches could get huge. This was fixed in Mercurial 1.2 which introduced the --close-branch option for hg commit.
<hyperair> oops
<hyperair> http://people.ubuntu.com/~hyperair/i915-error-state
<RAOF> Sorry, I didn't actually do any significant digging into my hangs before they got magically fixed, so your error-state isn't going to mean much to me :(
<hyperair> haha
<hyperair> okay
<mlankhorst> morning
#ubuntu-x 2013-06-19
<seb128> tjaalton, mlankhorst: hey, gentle reminder about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/1180986 from the sponsoring queue (you said you would have a look on monday)
<ubottu> Launchpad bug 1180986 in xserver-xorg-video-mga (Ubuntu) "X Segmentation fault with dual-head config on Matrox G45FMDVP32DB /32MB /DVI /VGA" [Undecided,Confirmed]
<tjaalton> seb128: right. that needs to be fixed on saucy too
<tjaalton> and the patch sent upstream
<seb128> tjaalton, can you do that tomorrow? ;-)
<tjaalton> might do it tonight
<seb128> tjaalton, no such hurry, but thanks ;-)
<mlankhorst> i knew i forgot something monday
<mlankhorst> :X
<tjaalton> you can handle it, no prob :)
#ubuntu-x 2013-06-20
<hyperair> RAOF: hey you mentioned that your X crashes were fixed recently in saucy, right? does your GPU still hang regardless?
 * hyperair is running a 3.10 kernel now, and the GPU still hangs, but it manages to recover on its own.
<RAOF> hyperair: I actually don't know. I know that it no longer hangs the system with multihead.
<hyperair> RAOF: dmesg | grep 'gpu hung'
<hyperair> er grep 'GPU hung'
<RAOF> :)
<hyperair> nothing?
<RAOF> Well, not at the moment, because I've just rebooted after unity-system-compositor hung my GPU :)
<hyperair> heh okay
<hyperair> nice :)
<hyperair> does alt+sysrq+k not help matters?
<RAOF> No, because sysrq+k is one of the disabled sysrq keys.
 * RAOF should really file a bug about that.
<hyperair> yeah you should
<hyperair> i re-enabled mine
<hyperair> i also reenabled the oom killer key, because it really helps when your system's swapping to hell on a dm-crypted swap.
#ubuntu-x 2013-06-21
<RAOF> Prf_Jakob: Hey, your mesa driver should be able to do EGL/GLES/GL on a gbm device, right?
 * RAOF is just wondering whether he's just added Mir support.
<Prf_Jakob> RAOF: you probably did :)
<RAOF> Hurray!
<Prf_Jakob> RAOF: I would have to test, I haven't added dma_buf support tho
<RAOF> Ah, that probably breaks it.
<RAOF> Oh, well. One step closer, anyawy.
<mlankhorst> RAOF: can you approve all the mesa/xxv-intel \0/lts-quantal/lts-raring packages? :-)
#ubuntu-x 2013-06-22
<AlanBell> hi all, I am having a problem on a laptop I have upgraded to saucy from raring
<AlanBell> it fails to load the intel driver so falls back to llvmpipe rendering
<AlanBell> [ 99452.162] (EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xorgMir
<AlanBell> is the error in Xorg.0.log this could be because I was previously messing with Mir PPAs, can you give me some pointers on how to get to a standard setup or get it working some way or other?
<AlanBell> never mind, fixed it. I had xserver-video-intel from the mir ppa, reinstalled that and everything is sweet
<tomreyn> AlanBell: sudo apt-get update && sudo apt-get install apt-show-versions &&  apt-show-versions|grep -v uptodate
<tomreyn> ...lists packages which are not from any known repositories. so if you use this after ppa-purge and after you manually ensure you have no unwanted PPAs active, it tells you what's left to be downgraded
<AlanBell> interesting, thanks
<AlanBell> grep for newer is also instructive
<tomreyn> yes, can be handy. especially since ppa-purge never worked for me.
#ubuntu-x 2013-06-23
<bjsnider> you can also see "local" stuff in synaptic
#ubuntu-x 2014-06-16
<Cimi> hi guys
<Cimi> I keep having this error running compiz
<Cimi> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1311037
<ubottu> Ubuntu bug 1311037 in xserver-xorg-video-intel (Ubuntu) "[mesa] intel_do_flush_locked failed: Invalid argument" [Undecided,New]
<Cimi> after compiz crashes I have to basically reboot my pc
<Cimi> utopic
<tjaalton> upstream replied already that it's a mesa bug
<tjaalton> changed the headline
<tjaalton> actually you're having something else if the machine locks up
<tjaalton> as this was reported by someone else
<Cimi> looks like a kernel issue
<Cimi> works with the trusty kernel
<tjaalton> the lockup, yes could be
<Cimi> tjaalton, compiz crashes after a resume
<Cimi> tjaalton, then only solution is reboot
<Cimi> on a dell vostro v13 (certified laptop iirc, intel only)
#ubuntu-x 2014-06-20
<work_alkisg> Is it possible to downgrade Xorg in 14.04 to the version shipped in 12.04.0, so that all the cards that need XAA are supported?
<jcristau> that's called installing 12.04
<alkisg> jcristau: it's not the same, e.g. 12.04 doesn't support newer CPUs, printers etc
<jcristau> newer cpu but 15 year old gpu?
<alkisg> Yup, sorry, 1000+ schools with that scenario :-/
<jcristau> eww
<alkisg> It's not only the CPU though, we could stay with 12.04 and the -lts-trusty kernel, but we also have printers that are not supported by the older libsane-hpaio, or we want the latest edu* packages, etc...
<alkisg> Anyway, is downgrading xorg possible?
<alkisg> Or it's out of the question?
<tseliot> alkisg: what gpus are we talking about?
<jcristau> alkisg: i don't think it's really reasonable
<jcristau> plus they might be better off with shadowfb than xaa anyway, since a recent cpu is oh so much faster than those gpus
<alkisg> tseliot: many many sis (some of them crashing even with the latest patch for exa), some s3virge, trident...
 * alkisg searches for a list of xaa-only cards to see which of them are found in school labs here...
<tseliot> alkisg: it's probably easier to put libsane and the edu packages in a PPA for Precise, and have the computers use them
<alkisg> Gotcha. Thank you guys, we already have a PPA where we put newer versions of packages, we'll put more packages there
<alkisg> Ah, is the 12.04 with stock xorg + the -lts-trusty kernel a bit reasonable?
<jcristau> that should be fine i would say
<tseliot> yes, it should work
<alkisg> Thanks! :)
<pkern> xorg lts-trusty is in -proposed. Is that already mature enough to be pushable? (/me "accidentially" migrated his fleet to lts-saucy, and that's to be deprecated soonish anyway...)
<Sarvatt> "works for me" but it probably wont go through major testing till closer to the august 7th release :) mlankhorst might know whats holding it up from getting into -updates or if there are any problems with it currently
#ubuntu-x 2015-06-17
<hyperair> where are synaptics bugs and patches sent?
<hyperair> (upstream) that is
<hyperair> ah wait, i found the bugzilla link on launchpad
<hyperair> oh wait it isn't synaptics i'm looking for, it's evdev
<tjaalton> we'll probably switch to libinput for wily
<tjaalton> but bugs.fd.o
<tjaalton> for upstream
#ubuntu-x 2016-06-21
<LocutusOfBorg> tjaalton, hi, you there=
<LocutusOfBorg> ?
<LocutusOfBorg> reporting a mesa issue
<LocutusOfBorg> not sure what changed, but pyqt5 needs a rebuild on top of it
<LocutusOfBorg> https://launchpadlibrarian.net/266772828/buildlog_ubuntu-yakkety-arm64.calibre_2.55.0+dfsg-1build2_BUILDING.txt.gz
<LocutusOfBorg>     from PyQt5.QtWidgets import QStyle  # Gives a nicer error message than import from Qt
<LocutusOfBorg> ImportError: /usr/lib/python2.7/dist-packages/PyQt5/QtGui.aarch64-linux-gnu.so: undefined symbol: _ZTI18QOpenGLTimeMonitor
<LocutusOfBorg> debian/rules:28: recipe for target 'debian/tmp' failed
<LocutusOfBorg> rebuilding pyqt5 and calligre on arm64 fixes the issue
<LocutusOfBorg> not sure what else needs a rebuild
<jcristau> how is a qt bug a mesa issue?
<LocutusOfBorg> good question
<LocutusOfBorg> I excluded qt, because qt in ubuntu didn't have a transition
<jcristau> QOpenGLTimeMonitor and PyQt5/QtGui aren't mesa...
<LocutusOfBorg> what I can say is that a no change rebuild picked up for python3-pyqt5 an additional dependency
<LocutusOfBorg> libgles2-mesa (>= 7.8.1) | libgles2
<LocutusOfBorg> and a diff on the build logs shows "-lGLESv2" added
<LocutusOfBorg> this is why I'm saying mesa is the culprit
<jcristau> that makes no sense whatsoever
<LocutusOfBorg> I know, this is why I'm reporting it here
<LocutusOfBorg> :) I have no clues
<jcristau> no, i'm saying your conclusion that mesa is the culprit makes no sense
<LocutusOfBorg> might be indeed, I'm looking at the debian transition right now
<LocutusOfBorg> I want to see if the same appears there
<tjaalton> there's no new mesa uploads in yak
<tjaalton> 12.0 is still WIP
<LocutusOfBorg> well, looking at both logs I can't find more clues
<LocutusOfBorg> Get:55 http://ftpmaster.internal/ubuntu xenial/main arm64 libegl1-mesa arm64 11.0.8-1ubuntu1 [50.2 kB]
<LocutusOfBorg> Get:58 http://ftpmaster.internal/ubuntu yakkety/main arm64 libegl1-mesa arm64 11.2.1-1ubuntu1 [58.1 kB]
<LocutusOfBorg> I know this doesn't make sense
<jcristau> LocutusOfBorg: qt is broken.
<jcristau> go fix qt?
<LocutusOfBorg> qt from 10ubuntu2 changed to 17ubuntu2
<LocutusOfBorg> lets see the differences
<LocutusOfBorg> I can't fix it
<LocutusOfBorg> damn indeed
<LocutusOfBorg>   * Add arm64 to gles archs.
<LocutusOfBorg> last upload
<LocutusOfBorg> this makes sense
<LocutusOfBorg> thanks
<tjaalton> ha
#ubuntu-x 2016-06-22
<furkan> tjaalton: i just remembered that you have a skylake build :) was wondering if you could confirm something for me... but unrelated to X
<furkan> i tried running a prime95 torture test, and my CPU (i7-6700K) gets throttled to 2.7GHz even though the temperature is in the mid 40s
<furkan> under Windows 10, it goes full blast at 4GHz
<furkan> i'm running Ubuntu 16.04, and it happens both with the stock kernel and 4.7rc4
<RAOF> furkan: Hm. Do you have thermald installed, and if so, have you tried disabling it?
<furkan> RAOF: i do have thermald installed... i just tried disabling it (service thermald stop) and doesn't seem to have made a difference
<furkan> i thought with the "Speed Shift" feature introduced with Skylake, the frequency scaling should be done in hardware
<RAOF> I just recall a bug where thermald would incorrectly limit some xeon processors to low clock states, and wondered whether the same applied here.
<furkan> you know what... i just booted into a live ISO
<furkan> and it's working fine
<furkan> kind of ridiculous, because i just did a clean install like a week ago
<furkan> i didn't touch any of the system configs, but i did install a few packages like lm-sensors to let me monitor the temps
<RAOF> Superb!
<RAOF> The live ISO has thermald installed, right? Stopping thermald might not be enough; it might set the processor into a software-managed state?
<furkan> RAOF: never mind i spoke too soon
<furkan> i just had to let it go for another 10-20 seconds
<furkan> before it throttled down to 2700MHz
<furkan> and yeah thermald is installed on the live ISO
<furkan> i guess it might have something to do with it
<furkan> not sure what to try other than stopping the service though
<furkan> i didn't seem to have the problem before, when i had the Asus "multicore enhancement" feature enabled, which locks all the cores at the turbo frequency
<furkan> but i
<furkan> i'd rather not have that enabled
<furkan> r33nllamashoes
<furkan> sorry wrong window
<furkan> anyway tjaalton i'd appreciate it if you could give prime95 a whirl on your Skylake CPU when you have a chance, and let me know
<RAOF> Time for a password change? :)
<furkan> RAOF: hah, yeah, luckily it wasn't anything important :P
<furkan> i mostly use key-based auth
<furkan> well i have no idea what i did... but it seems to be working fine now
<furkan> i should just give up on computers
#ubuntu-x 2016-06-23
<croepha> im trying to port xserver-xorg to ubuntu-core (snappy) im trying to track down a segfault was hoping someone here would already know the answer... log and gdb session: http://paste.ubuntu.com/17767620/
<croepha> looks like a null pointer for xf86configptr in xf86OutputClassDriverList
<croepha> nevermind, i think ive got it
#ubuntu-x 2016-06-25
<alkisg> In 16.04, when we install the nvidia drivers from software-properties-gtk, are we supposed to get a xorg.conf? I didn't get one, yet Xorg.log says the nvidia module was loaded...
<alkisg> If we don't need a xorg.conf... does that also mean that the nvidia drivers now can cooperate better, i.e. to have them installed even when we don't have nvidia cards? (most useful in ltsp where a single image boots many clients, some with nvidias and some without)
<tjaalton>  no and no
<tjaalton> xserver is patched to try nvidia
<alkisg> Thank you tjaalton :)
#ubuntu-x 2017-06-21
<RAOF> tjaalton: If I push the mesa 17.0.7 SRU to -proposed, will you test this one? :)
<tjaalton> RAOF: yes, I promised that to sil2100 buy he was off and never replied :)
<tjaalton> *but
<tjaalton> also, i guess it was you who asked about the mesa git push, sheesh
<tjaalton> and that egl platform thing I missed
<tjaalton> hope to see those in 17.2 ;)
