#ubuntu-x 2007-06-11
<ubotu> New bug: #87947 in libx11 (main) "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Undecided,Confirmed]  https://launchpad.net/bugs/87947
<ubotu> New bug: #119738 in update-manager (main) "dapper->edgy upgrade fails due to conflict betwen x11-common and opera (dup-of: 67996)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119738
<ubotu> New bug: #119329 in xorg (main) "Can not configure higher display resolution and refresh rate" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119329
<ubotu> New bug: #16429 in Baltix (main) "missing 100 hz refresh rate in the "Screen Resolution Preferences"" [Medium,Confirmed]  https://launchpad.net/bugs/16429
<ubotu> New bug: #45383 in Ubuntu "X crashes after resume in Dapper " [Medium,Needs info]  https://launchpad.net/bugs/45383
<ubotu> New bug: #119811 in xorg (main) "sis driver not support 1280x1024@75 " [Undecided,Unconfirmed]  https://launchpad.net/bugs/119811
<ubotu> New bug: #40398 in xorg (main) "Adding extra graphics cards; kubuntu won't start X11" [Medium,Confirmed]  https://launchpad.net/bugs/40398
<ubotu> New bug: #119894 in xserver-xorg-input-aiptek (universe) "Please sync xserver-xorg-input-aiptek (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/119894
<ubotu> New bug: #9525 in xserver-xorg-video-i810 (main) "i8xx: catch-all for terrible VBE implementations" [Medium,Confirmed]  https://launchpad.net/bugs/9525
<ubotu> New bug: #99411 in libxaw (main) "timidity crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99411
#ubuntu-x 2007-06-12
<ubotu> New bug: #119961 in xorg (main) "Incorrect Rotation result on Screen Resolution with Crestline on Santa Rosa" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119961
<ubotu> New bug: #119966 in mesa (main) "Cube-switch between workspaces doesn't work normally after 3D enabled more than twice" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119966
<ubotu> New bug: #119967 in xorg (main) "Dual-display testing support error on Santa-rosa with Crestline" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119967
<ubotu> New bug: #119975 in xorg (main) "TV output support failure on Santa-rosa with Crestline" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119975
<ubotu> New bug: #119471 in linux-restricted-modules-2.6.20 (restricted) "2.6.20-16-generic cannot modprobe nvidia-glx" [Undecided,Needs info]  https://launchpad.net/bugs/119471
<bryyce> seb128: welcome back!
<seb128> hey bryyce
<seb128> thanks ;)
<tepsipakki> seb128: hey, I was wondering why all those gnome uploads were made by !seb128 :)
<seb128> tepsipakki: I was on holidays for a week ;)
<tepsipakki> sheesh, so long :)
<seb128> hehe
<tepsipakki> I'll be off for 2,5 weeks starting on Thursday.. it's a bit hectic trying to figure out what has to be done before that
<seb128> I've enough mail catching up to do after a week :p
<seb128> brb, restarting to try glib update
<tepsipakki> bryyce: I noticed you marked bug 42553 as bitesize?
<ubotu> Launchpad bug 42553 in xorg "wacom input devices enabled by default, why?" [Medium,Confirmed]  https://launchpad.net/bugs/42553
<bryyce> tepsipakki: yeah...  I hope to take a look at it on bug day.  
<tepsipakki> well, it's trivial to drop wacom support (OOTB), but is it what we want?-)
<bryyce> tepsipakki: I guess that's the big question
<tepsipakki> yeah
<bryyce> I would really like to understand *why* it is hardcoded
<bryyce> obviously it's there for a reason, but why was it decided to hardcode as opposed to other mechanisms?
<tepsipakki> likewise for the synaptics
<bryyce> I have an (old) wacom I could test...
<bryyce> yup
<tepsipakki> what other mechanisms do you mean?
<tepsipakki> debconf?
<bryyce> well, that or xorg input hotplug or something
<tepsipakki> input hotplug would be the ultimate solution, I think
<bryyce> agreed
<bryyce> if 1.4 comes out in time, I think we may have it :-)
<tepsipakki> I don't know where we are atm
<tepsipakki> afaik it isn't necessarily ready at the time :/
<tepsipakki> input-hotplug, that is
<bryyce> yeah probably true
<bryyce> btw, you mentioned that xauth and xinit would be in debian..  I see xauth, but not xinit yet -- http://people.ubuntu.com/~bryce/Xorg/versions_current.html.  Does it go by a different name?
<tepsipakki> it hasn't been uploaded yet, I guess
<bryyce> ahh
<tepsipakki> or, hasn't passed NEW yet
<bryyce> my goal for the next few weeks is to get that right-most column to as close to 100% green as I can get :-)
<tepsipakki> heh
<bryyce> tepsipakki: another thing I've been thinking about, is that it would be somewhat useful to have a regression test or acceptance test of some sort
<bryyce> so when a change is made, there'll be something to run to at least give a sanity check that it doesn't break the whole wold
<bryyce> ok bedtime... ttyl
<tepsipakki> ok, g'nite
<ubotu> New bug: #120029 in linux-restricted-modules-2.6.20 (restricted) "restricted drivers not included in 2.6.20-16-generic" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120029
<ubotu> New bug: #120043 in xserver-xorg-input-mouse (main) "Intermittent mouse flakiness (works on some boots)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120043
<ubotu> New bug: #119944 in xorg (main) "[Gutsy]  Tribe 1 installer gives blank video during boot" [Undecided,Confirmed]  https://launchpad.net/bugs/119944
<ubotu> New bug: #107880 in xorg (main) "X doesn't start even if the safe mode is used! (Ubuntu 7.04)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107880
<ubotu> New bug: #40754 in xorg (main) "hyundai b71a monitor screen resolution and instability" [Medium,Unconfirmed]  https://launchpad.net/bugs/40754
<ubotu> New bug: #119964 in xorg (main) "Can't change pointer acceleration on MacBook trackpad" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119964
<ubotu> New bug: #120099 in xserver-xorg-video-nv (main) "[nv driver]  X server crashes when I run google earth" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120099
#ubuntu-x 2007-06-13
<bryce_> tepsipakki: btw, one thing I'm hoping to work towards with our xorg packaging, is to improve testing
<tepsipakki> yes, you mentioned that briefly..
<tepsipakki> what do you mean by that?
<bryce_> before I started with ubuntu/xorg, I used to maintain a large automated testsuite for nfsv4, and I'm hoping to reuse some of those approaches for xorg
<tepsipakki> testing the code itself?
<bryce_> well, I haven't 100% determined what would serve us best yet
<bryce_> possibly
<bryce_> there's a lot of different ways to test things
<bryce_> the key is to test for things we can actually do stuff about
<bryce_> so like, just running xorg performance tests probably wouldn't gain us much
<bryce_> (although it might not be a bad thing to do)
<bryce_> the particular thing I've been looking at is just plain old "startup" tests
<bryce_> e.g., given a new (proposed) xorg package, install it on a test machine, and try starting xorg on that machine
<tepsipakki> that would need a lot of hardware :)
<bryce_> yup
<tepsipakki> but sounds good
<bryce_> which is why I've been accumulating hardware ;-)
<tepsipakki> heh
<bryce_> I've got 4 working test systems, plus 3 more on the way
<bryce_> (I call test systems 'sut's - Systems Under Test)
<bryce_> anyway, I bring this up because if you know of or can think of other tests that would be worth running, let me know
<bryce_> oh, aside from just having a lot of hardware, it can also be useful to run the same test with different parameters
<bryce_> e.g. on an intel system, testing against -i810 and -intel, or with an ati or nvidia system, testing against both open and binary drivers
<tepsipakki> can't think of anything, but I'll keep that in mind
<bryce_> another thing to think about, is when you manually test something, to try to think, "how could I achieve this same test, but in a completely automated way"
<bryce_> as we go, anything we can script, we can turn into a cheap test for using in the future
<tepsipakki> manual testing don't scale well :) (but OTOH it doesn't need to be run _that_ often)
<bryce_> yup
<bryce_> where automated testing can prove useful is when we're doing a release and want to have as many extra checks as possible
<bryce_> obviously, those checks don't need to be automated, 
<bryce_> but it can eliminate a lot of questions if it's scripted to the extent that it could be 100% automated
<tepsipakki> of course, scripting helps, it's just tricky to write good scripts for that purpose :)
<bryce_> yup
<tepsipakki> I'm wondering if I should create a git branch for our xorg in git.d.o and push the changes one by one..
<bryce_> I think that would be really, really, really useful and a very good idea
<bryce_> I can set up my test system to auto-pull from git when there are changes, and automatically run tests against that
<tepsipakki> the metapackage has most of the changes, rest of the components just use patches so they are pretty trivial to keep for now
<bryce_> I used to run this automated test system for carl worth for doing cairo testing, using exactly that approach
<tepsipakki> jcristau: you awake yet?-)
<tepsipakki> cool
<bryce_> so I was thinking resurrecting that would be handy, so we'd have something at the application level to test
<bryce_> but a lot of what you and I care about is going to be more at the integration/packaging layer
<tepsipakki> upgrades are also nice to test beforehand
<bryce_> another thing I've thought about is hooking this in with vmware, so on a given hardware I can test against feisty as well as gutsy
<bryce_> exactly
<bryce_> I've used this test framework (aka crucible) with xen, but not with vmware
<tepsipakki> ah, build tests
<bryce_> yeah
<tepsipakki> it's silly to upload and then notice that the build fails for whatever reason :)
<bryce_> also, I don't know if we care, but I've done some testing work with cross compilers
<bryce_> honestly, I don't think anyone is going to care if we get errors/warnings on arm, solaris, etc. ;-) but that's something else we could test if we wished
<tepsipakki> I believe debian will test those :)
<bryce_> yup
<tepsipakki> AIUI they are going to keep experimental as close to upstream git master as possible to make testing easier
<bryce_> the thing I've learned with testing is that the key is in reviewing and following up on test results
<bryce_> you can automate all the tests in the world and generate terabytes of results, but if no one follows up on the results, it's all worthless
<tepsipakki> right
<bryce_> so the trick is to try to only run tests that actually matter, that you actually care about
<bryce_> so that's where I can really use your help and advice
<bryce_> just because we *can* run a test, the real question is if we care
<bryce_> anyway, it'll probably be a few weeks before I have anything worthwhile to look at.  But when I do, please be critical - if it looks un-useful to you, say so :-)
<tepsipakki> ok, I will :)
<tepsipakki> testing itself is a gray area for me, but I know how costly it is to leave testing for the end users
<bryce_> cool, well this'll be a good thing to learn.  It's actually a pretty simple thing, it just seems strange and mysterious from the outside
<bryce_> testing mostly is just useful for catching goofs
<bryce_> but we all make goofs from time to time ;-)
<tepsipakki> yep :)
<jcristau> tepsipakki: now i am
<jcristau> (my sleep pattern is kinda fucked up, these days)
<tepsipakki> hehe
<tepsipakki> I was wondering if it makes sense to create a new branch for xorg and to apply the ubuntu changes there one by one
<jcristau> i'm fine with that
<tepsipakki> ok, I've just started with it
<tepsipakki> I guess it's easier to pull changes then
<ubotu> New bug: #20584 in xserver-xorg-video-trident (main) "xv output garbled [not regr] " [Medium,Needs info]  https://launchpad.net/bugs/20584
<ubotu> New bug: #118208 in libxinerama (main) "Context Menu display cutoff" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118208
<ubotu> New bug: #53878 in xorg-server (main) "Screen is distorted for a few seconds at X startup shutdown" [Medium,Needs info]  https://launchpad.net/bugs/53878
<ubotu> New bug: #96213 in xorg (main) "won't install on Dell 640m with 1400x900 screen" [Undecided,Needs info]  https://launchpad.net/bugs/96213
<ubotu> New bug: #42607 in xserver-xorg-video-via (main) "Ubuntu Dapper on VIA EPIA-MS with LVDS; no video after installation" [Medium,Needs info]  https://launchpad.net/bugs/42607
<ubotu> New bug: #45418 in xkbutils (main) "Restart of X gdm and freezing" [Medium,Confirmed]  https://launchpad.net/bugs/45418
<ubotu> New bug: #41404 in xserver-xorg-video-via (main) "OpenGL stuff freezes on AMD64" [Medium,Needs info]  https://launchpad.net/bugs/41404
<ubotu> New bug: #46352 in xresprobe (main) "Panel resolution not detected" [Medium,Needs info]  https://launchpad.net/bugs/46352
<ubotu> New bug: #32152 in linux-restricted-modules-2.6.15 (restricted) "Wireless networking suddenly broken" [Medium,Needs info]  https://launchpad.net/bugs/32152
<ubotu> New bug: #68319 in xorg (main) "Right button and middle click on mouse are swapped" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68319
<ubotu> New bug: #49115 in xresprobe (main) "Max resolution not detected properly for IBM G78" [Undecided,Rejected]  https://launchpad.net/bugs/49115
<ubotu> New bug: #36525 in linux-restricted-modules-2.6.15 (restricted) "bcm43xx Driver only works @ 11Mb/s" [Low,Confirmed]  https://launchpad.net/bugs/36525
<brycerr> tepsipakki, I posted a patch to bug 42553 for conditionalizing wacom in dexconf, with explanation of why we aren't doing it based on mjg59's comments
<ubotu> Launchpad bug 42553 in xorg "wacom input devices enabled by default, why?" [Medium,Confirmed]  https://launchpad.net/bugs/42553
<tepsipakki> brycerr: yeah, uploading with that change would be a regression for some wacom users, so probably not worth it
<tepsipakki> we'll see how the input-hotplug progresses..
<ubotu> New bug: #103497 in linux-restricted-modules-2.6.20 (restricted) "IPW2200 proccess 100% cpu ussage with no configured  network in the area" [Undecided,Needs info]  https://launchpad.net/bugs/103497
<ubotu> New bug: #72705 in linux-restricted-modules-2.6.17 (restricted) "kernel panic, system freeze on shutdown, vmware hangs..." [Medium,Confirmed]  https://launchpad.net/bugs/72705
#ubuntu-x 2007-06-14
<ubotu> New bug: #99287 in libxcb (main) "Opera and Adobe Reader fail to start, error loading libxcb-xlib.so.0 (dup-of: 107732)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99287
<ubotu> New bug: #103230 in libc (universe) "Opera seg fault after libc upgrade (dup-of: 107732)" [Undecided,Confirmed]  https://launchpad.net/bugs/103230
<ubotu> New bug: #120277 in xorg-server (main) "xserver segfault on exit" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120277
<ubotu> New bug: #119244 in Ubuntu "Wake-up from suspend not working, Thinkpad z61m (dup-of: 84991)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119244
<ubotu> New bug: #120288 in linux-restricted-modules-2.6.20 (restricted) "upgrade to 2.6.20-16 causes wireless card not to be recognized" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120288
<ubotu> New bug: #120307 in xorg (main) "x11-common conflicts with 3rd-party packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120307
<ubotu> New bug: #120317 in xorg (main) "xorg.conf xServer error in Gutsy and Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120317
<ubotu> New bug: #120347 in xorg (main) "xorg hang after longer (12h) idle time" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120347
<ubotu> New bug: #79553 in mesa (main) "i915 performance error" [Undecided,Confirmed]  https://launchpad.net/bugs/79553
<ubotu> New bug: #120421 in xorg-server (main) "Random X crash when using beryl" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120421
<bryyce> tepsipakki, how hard do you think it'd be to backport -intel 2.0 to feisty?  would that require backporting xserver 1.3 as well?
<jcristau> it should build with 1.2
<bryyce> ah cool
<bryyce> that's very good news.  Do you know if anyone has already backported it to feisty?
<jcristau> i don't know
<ubotu> New bug: #120444 in xorg (main) "Switch user crash with fglrx driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120444
* Starting logfile irclogs/ubuntu-x.log
#ubuntu-x 2007-06-15
<ubotu> New bug: #120476 in xserver-xorg-video-nv (main) "nv missing rotation option "inverted"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120476
<ubotu> New bug: #120551 in libxrandr (main) "guidance-power-manager libXrandr" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120551
<ubotu> New bug: #120480 in xserver-xorg-video-ati (main) "HUGE Logon Font (dup-of: 107320)" [Undecided,Needs info]  https://launchpad.net/bugs/120480
<ubotu> New bug: #75868 in xserver-xorg-video-ati (main) "Font rendering glitches with radeon, known bug, patch exists (dup-of: 62537)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/75868
<ubotu> New bug: #120624 in xorg (main) "[gutsy]  x11-common (1:7.2-3ubuntu3) failed on apt-get update from feisty to gutsy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120624
#ubuntu-x 2007-06-16
<ubotu> New bug: #120669 in xserver-xorg-video-i810 (main) "No player can play screencasts recorded with Istanbul" [Undecided,Confirmed]  https://launchpad.net/bugs/120669
<ubotu> New bug: #120680 in xserver-xorg-video-ati (main) "font rendering problems on Thinkpad R50" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120680
<ubotu> New bug: #41935 in linux-restricted-modules-2.6.15 (restricted) "Out of date description" [Low,Confirmed]  https://launchpad.net/bugs/41935
#ubuntu-x 2007-06-17
<ubotu> New bug: #120761 in xserver-xorg-video-ati (main) "does not support rs480" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120761
<ubotu> New bug: #43032 in totem (main) "X Windows System error trying to launch totem-xine (dup-of: 35229)" [Medium,Needs info]  https://launchpad.net/bugs/43032
<ubotu> New bug: #43252 in xserver-xorg-video-nv (main) "Driver Bug for nVidia 6800 series Cards" [Medium,Confirmed]  https://launchpad.net/bugs/43252
<ubotu> New bug: #120803 in xorg (main) "Adding ctrl:swapcaps to xorg.conf has no effect" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120803
<ubotu> New bug: #120834 in xserver-xorg-video-intel (main) "intel gm965 freezes with 3d applications" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120834
<ubotu> New bug: #120837 in xorg (main) "When I log out from Ubuntu Feisty I get black screeen" [Undecided,Confirmed]  https://launchpad.net/bugs/120837
<tepsipakki> bryyce: 1.9.94 is in feisty
<tepsipakki> so 2.0.0 is doable
<ubotu> New bug: #120885 in xorg (main) "ATI Radeon 9250 without graphic acceleration on Ubuntu 7.10" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120885
<ubotu> New bug: #120898 in xorg (main) "Adding a generic monitor does not work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120898
#ubuntu-x 2008-06-09
<mvo> tjaalton: hi! out of curiosity, how does the shared reposiotry work that you have with the x strike force? is that a ubuntu branch on top of the general git? do you just maintain the debian/ dir in git, or do you pull the full upstream git repo?
<tjaalton> mvo: hi! it's a branch, so we merge with debian periodically. there has been no need to pull from upstream, since experimental tends to have the latest stuff if not unstable
<tjaalton> mvo: so yes, the full upstream git branches are there
<mvo> tjaalton: ok, thanks! 
<tjaalton> mvo: actually, not every upstream branch is in g.d.o, only those that are used for packages
#ubuntu-x 2008-06-10
<tseliot> tjaalton: I have completed the DKMS part for the nvidia driver (for our new package)
<tseliot> I'm uploading the source
<tseliot> to my webspace
<tjaalton> tseliot: did you use my debdiff as a base?
<tseliot> tjaalton: yes, of course
<tjaalton> cool
<tseliot> I'm working with you, not against you ;)
<tjaalton> just to make sure ;)
<tseliot> I'm reuploading the original too, just to be sure
<tjaalton> could you make a debdiff against my version?
<tseliot> sure
<tjaalton> or any (unified) diff
<tseliot> your debdiff was nvidia-split.debdiff, right?
<tjaalton> yes
<tseliot> tjaalton: here's the debdiff: http://www.albertomilone.com/ubuntu/newlrm/nvidia-dkms.debdiff
<tseliot> Here are the files: http://www.albertomilone.com/ubuntu/newlrm/nvidia-graphics-drivers_169.12.orig.tar.gz
<tseliot> ï»¿http://www.albertomilone.com/ubuntu/newlrm/nvidia-graphics-drivers_169.12-4ubuntu2.diff.gz
<tseliot> ï»¿ï»¿http://www.albertomilone.com/ubuntu/newlrm/nvidia-graphics-drivers_169.12-4ubuntu2.dsc
<tseliot> ï»¿ï»¿ï»¿http://www.albertomilone.com/ubuntu/newlrm/nvidia-graphics-drivers_169.12-4ubuntu2_source.changes
<tjaalton> why have you removed files that doesn't matter being there (debian.binary)? it only makes the diff large
<tjaalton> *don't
<tjaalton> seems like the diff'ed target was unclean, since it had nvidia-kernel/
<tseliot> ok, let me do it again
<tjaalton> but there were a bunch of files you've removed by hand. it should be enough to comment stuff out from rules
<tjaalton> makes it a lot easier to merge in the future
<tseliot> ok
<tjaalton> see, I'm saving your time ;)
<tseliot> it looks like I did a debclean before doing the debdiff
<tseliot> can you get the source from my website?
<tjaalton> hmm don't bump the version since no version has been uploaded
<tjaalton> but yes, I'll get it
<tseliot> ï»¿tjaalton: doing a debdiff with the same version is not possible ;)
<tjaalton> diff -Naur is fine too
<tseliot> next time I'll just do a diff
<tjaalton> umm, did you change the tarball?
<tjaalton> at least the size differs, so it's not built with the tarball from debian
<tseliot> ï»¿tjaalton: honestly, I don't remember the reason why I did it. I'm working on a lot of things and my memory sucks
<tseliot> ï»¿tjaalton: I think I have just regenerated the orig, the code is the same
<tjaalton> you can't touch the tarball :/
<tseliot> i.e. Debian's + yours
<tjaalton> I can't extract the package
<tseliot> I'll reupload the diff done with the original orig file
<tjaalton> because the tarball is not the same as in debian
<tjaalton> cool
<tseliot> try now. If it doesn't work I'll download the orig from debian again
<tseliot> the links to the files are the same in my webspace
<tjaalton> yep, worked this time
<tseliot> ok, great
<tjaalton> yeah, diff is much better
<tseliot> I had to recreate the orig for the lrm-envy, maybe this confused me a bit, I don't know... ;)
<tjaalton> you modified the copyright?
<tjaalton> the ftp url
<tseliot> in which file?
<tjaalton> debian/copyright
<tseliot> no, I guess not
<tseliot> why should I have done such a thing?
<tjaalton> -ftp://download.nvidia.com/XFree86/Linux-x86_64/169.12/NVIDIA-Linux-x86_64-169.12-pkg2.run
<tjaalton> +ftp://download.nvidia.com/XFree86/Linux-x86/169.12/NVIDIA-Linux-x86-169.12-pkg0.run
<tjaalton> you tell me :)
<tjaalton> the same change (pkg2->pkg0) is in several other files
<tseliot> pkg2 is for 64bit while pkg0 is for 32bit
<tjaalton> maybe that's generated
<tseliot> furthermore that file is generated from the .in
<tjaalton> right, so no problem there
<tjaalton> actually, lrm had pkg1 & pkg2.. wonder what's the difference between pkg0 & pkg1
<tseliot> pkg0 doesn't contain the pre-built modules
<tseliot> for SUSE, Redhat, etc.
<tseliot> therefore it's smaller
<tjaalton> ok, so it was a "bug" in lrm
<tseliot> yes, it wasted our bandwidth
<tseliot> pkg0 9.7MB, pkg1 16.8MB :-)
<tjaalton> yep
<tjaalton> you removed n-k-s.NEWS? although it's useless, it shouldn't matter being there and making the diff smaller
<tseliot> I guess I did it. You can put it back
<tjaalton> ok, so I'll merge the rest, and then change the epoch etc. Then testing on hardy
<tseliot> the driver won't be loaded in hardy though. Maybe remove the lrm first
<tjaalton> I know it won't be, but it should work there
<tjaalton> does lrm-common conflict with the new package?
<tjaalton> functionally
<tseliot> it should
<tseliot> and we should get rid of lrm-common anyway
<tjaalton> it's not a problem with the new lrm that'll get in intrepid
<tjaalton> probably won't exist there
<tseliot> but of course it will be a problem if we decide to backport the driver to hardy
<tjaalton> nope
<tjaalton> won't happen
<tseliot> which one won't happen? The problem or the backport?
<tjaalton> backport
<tseliot> ok, then
<tseliot> and users will get the updated drivers through envyng therefore no backport will be needed ;)
<tjaalton> right, I won't take the risk of updating lrm
<tseliot> ok, then
<superm1> tseliot, tjaalton haven't talked to you for a bit, so i wanted to see where you were at w/ dkms support on the nvidia packages?
<tseliot> superm1: this morning I gave tjaalton the part about dkms. However we have yet to work on the control file and on the diversions
<superm1> so likely this stuff won't be ready for intrepid alpha 1 :(
<tseliot> ï»¿superm1: do you need the nvidia driver?
<superm1> tseliot, i was going to do some initial testing on intrepid for some next generation laptops once the alpha came out
<superm1> and some of them contain nvidia, so this seemed appropriate to test at the same time
<tseliot> ï»¿superm1: ok, I'll see what I can do to speed up this process. What's the deadline for the 1st alpha of Intrepid?
<tjaalton> tseliot: you can continue working on the version you gave me (including my comments). I didn't have time to merge it with my tree today, but maybe I can do some testing tomorrow
<tseliot> ï»¿tjaalton: ok ;)
<jcristau> it should be possible to sync libx11 now
<mnemo> in what ubuntu package does the /usr/lib/dri/i965_dri.so file ship?
<jcristau> libgl1-mesa-dri
<jcristau> packages.ubuntu.com would have told you that i think
<tjaalton> dpkg -S foo will tell, or dlocate
<tjaalton> phew, my vdr box decided to overheat right in the middle of an upgrade
<mnemo> excellent thanks... give a man a fish, heh ;)
<tjaalton> no keyboard/monitor.. the kernel booted fine though
<tjaalton> gotta love the robustness of dpkg/apt..
<bryce> heya
<tjaalton> hi
<bryce> I added a notes field to http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<bryce> it can be edited at http://wiki.ubuntu.com/X/PackageNotes
<tjaalton> yep, I saw that, it's useful
<tjaalton> libx11 could be synced, as jcristau pointed out
 * bryce nods
<bryce> I'll go ahead and put a request in for it; I was wondering about that
<tjaalton> and, blech.. v4l needs an epoch to be able to sync it
<jcristau> oh?
<tjaalton> should be the last one <knocksonwood>
<jcristau> sigh
<tjaalton> yeah, it was there from the first release
<tjaalton> which is a bit silly
#ubuntu-x 2008-06-11
<tseliot> tjaalton: now that I think about it we'll have to recreate the orig for the nvidia driver since we're going to update the driver to the latest release. I have already filed a SRU for Hardy for the lrm-envy. This is definitely something we want to have in Intrepid ASAP since it also adds "preliminary support for X.Org server 1.5". What do you think?
<tjaalton> tseliot: sure, although 1.5 is not in intrepid yet
<tjaalton> and it might take a few weeks
<tseliot> the driver is future-proof ;)
<tseliot> and we might also take the chance to remove those files which you wanted me to keep
<tseliot> since compatibility with Debian will break anyway
<tjaalton> why?
<tseliot> ï»¿a different orig tarball
<tjaalton> if they are not installed, it's harmless to keep them
<tjaalton> debian will update theirs sooner or later
<tseliot> and their existence might make things a bit more confusing for any potential contributor
<tseliot> not that I think that there will be any ;)
<tjaalton> document it
<tseliot> shall I write something like "the following files are useless"?
<tjaalton> README.Ubuntu or something
<tseliot> ok, I can do it as soon as I'm done with the rest of the package.
<tseliot> I'm reviewing the diversions
<tjaalton> ok
<tseliot> tjaalton: shall I replace the list of the supported cards in the control.in with the new cards or just comment them out and add the new list?
<tseliot> or maybe I should add it to the changelog
<tseliot> also, shall I keep revision ubuntu1 instead of ubuntu2?
<tjaalton> ubuntu1
<tseliot> ok, and about the control.in?
<tjaalton> what do you mean by commenting out?
<tjaalton> add the new cards to the list perhaps
<tseliot> you told me not to remove lines but to comment them out (i.e. put  a # before a line)
<tjaalton> what lines are you talking about?
<tjaalton> unless you comment out the whole package, I don't think it would work in control
<tseliot> read where it says " The following GPU's are supported:"
<tseliot> but yes, I can just add the new cards
<tseliot> to the list
<tjaalton> so, since nvidia-kernel-source is not needed you can either comment or delete it
<tseliot> nvidia-kernel-source = DKMS
<tjaalton> I believe the diff didn't have it
<tseliot> we still need it
<tjaalton> but you know better
<tseliot> I didn't remove it
<tjaalton> ok, maybe it was the broken diff
<tseliot> I will give you the full source once I think it's complete
<tseliot> this might happen today, so that we can test it together
<tjaalton> ah, it was -ia32
<tseliot> right
<tjaalton> n-g-ia32
<tseliot> of course
<tjaalton> so hmm.. commenting out is better in the sense that then you know what has been "removed"
<tseliot> aah, without having to read the diff, you mean
<tjaalton> yes
<tjaalton> well, merge diff against the debian version
<tjaalton> diff.gz doesn't show that
<tjaalton> nice, security updates for the xserver
<jcristau> for some value of 'nice' :)
<kees> url?
<tjaalton> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=shortlog;h=server-1.4-branch
<tjaalton> kees: ^
<jcristau> kees: http://lists.freedesktop.org/archives/xorg/2008-June/036026.html
<tjaalton> oh, that's much better :)
<tjaalton> right, didn't notice the announce
<tjaalton> -ment
<jcristau> kees: it wasn't posted to vendor-sec?
<kees> jcristau: yeah, found it now -- only 2 days lead time.  whee
<kees> (last time we had like a month, weird)
<jcristau> kees: it was reported to xorg long ago...
<jcristau> kees: i guess next time i can cc you when i send mail to team@security.d.o
<kees> jcristau: security@ubuntu.com please, yes.  and bryce, if he's not already on the security.d.o list
<bryce> kees: the cve patches built fine for intrepid and hardy, shall I go ahead and upload both of those, or do you want to do some testing first?
<kees> bryce: I'll leave it to you for intrepid, but for hardy (and the others) they need to go through the -security queue:
<kees> https://wiki.ubuntu.com/SecurityUpdateProcedures
<kees> mostly, if you can create debdiffs, I can start testing.  getting reproducers for the problem, or ways to test the affect code paths would be cool too.  :)
<kees> it might be easiest to open a bug for it
<bryce> yeah  no clue on reproducers
<jcristau> there are some on the upstream bug
<jcristau> but it's still restricted
<jcristau> i'll send it to you
<bryce> kees, hardy debdiff:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.4.1~git20080131-1ubuntu9.2.debdiff
<jcristau> {kees,bryce}@u.c?
<bryce> that should work
<kees> jcristau: security@ubuntu.com for security notices, but yeah
<kees> jcristau: that way jdstrand gets them too
<jcristau> ok
<kees> thx :)
<bryce> intrepid debdiff just for completeness - http://people.ubuntu.com/~bryce/Testing/xorg-server_1.4.1~git20080131-1ubuntu12.debdiff
<kees> bryce: why is it ubuntu9.2 for hardy?
<bryce> ...uploading the intrepid fixes now...
<bryce> kees, there is a 9.1 already in hardy-proposed
<bryce> although I just spotted an error in it
<bryce> feel free to renumber or whatever as appropriate
<kees> bryce: ah, righto.  The debdiff itself needs be applied to ubuntu9 (though 9.2 is the correct version).  And the 9.1 needs to be respun to include the security updates and pushed back to -proposed.  (i.e. -security updates only every build on top of things -updates, as -proposed packages haven't officially cleared QA)
<kees> error spotting in which thing?
<bryce> kees, the patch added in 9.1 for -geode was not actually listed in series (probably my fault)
<bryce> erf, that sounds messy - would you be willing to sort those out while I do the patch backports?
<jcristau> kees: sent
<kees> bryce: sure, I can re-base the hardy debdiff.
<kees> jcristau: thanks
<bryce> kees: cool thanks.  looks like the patches are applying fairly cleanly except for dapper
<jcristau> the patches for dapper shouldn't be too different from etch
<jcristau> and i don't think i had any issues with that, hmm
<bryce> jcristau: there's just one patch that isn't applying - org-xserver-1.4-cve-2008-2360.diff
<bryce> 1 out of 2 hunks FAILED -- saving rejects to file render/glyph.c.rej
<jcristau> oh, ok
<bryce> I'll take a look in a minute
<jcristau> probably the #include <stdint.h>
<bryce> kees, gutsy debdiff:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.3.0.0.dfsg-12ubuntu8.4.debdiff
<bryce> for feisty (only), the debdiff is including a bunch of .gitignore deletion garbage
<kees> cool
<bryce> kees: do you care about these .gitignore bits?  I'm not exactly certain how to exclude those changes... but they're obviously completely harmless, just messy
<kees> bryce: while I like cleanliness, I can live with the mess.  :)  I suspect it's due to .devscript settings for the -I options during the build
<jcristau> or dpkg-source behaviour change
<bryce> ok, feisty debdiff:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.2.0-3ubuntu8.4.debdiff
<bryce>  more ~/.devscripts 
<bryce> # debuild
<bryce> DEBUILD_PRESERVE_ENVVARS="DISPLAY,GNOME_KEYRING_SOCKET,XAUTHORITY"
<bryce> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn"
<bryce> is there something there I could/should change to prevent this issue?
<bryce> e.g. -I.gitignore ?
<kees> see if removing -I.bzr for that debuild makes it go away.  if not, no big deal.  (the bug is that the original released builder didn't use -I.bzr I think)
<kees> oh, .git
<kees> er
<kees> sure, give it a shot.  :P
<jcristau> newer dpkg-source filters out .git and .gitignore by default
<bryce> ok, well I guess let's not worry about it...  it's just feisty that's affected
<tseliot> tjaalton: I've just sent an email with my PPA with the driver to superm1 and CCed you
<bryce> hmm, dapper's xserver uses a different patch system
<bryce> kees, ok here's dapper:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.0.2-0ubuntu10.11.debdiff
<bryce> kees, I think that should be it for the debdiffs.
<kees> bryce: very cool, thanks.
<bryce> the broken dapper patch was a pretty trivial conflict, I don't think it'll affect functionality
<pwnguin> ah, its so hard to remember that the envy guy albert milone uses the screen name tseliot
<tseliot> ï»¿pwnguin: yes, it's me ;)
<bryce> tseliot: so you a poetry fan or is the nick derived from some other source?
<tseliot> bryce: yes, I like poetry and my first exam at the university was on T.S. Eliot
<bryce> ah cool
<tseliot> bryce: so, I received the notification from the spec
<tseliot> cjwatson should approve it, right?
<tseliot> let me rephrase it. We need his approval, right?
<bryce> yes
<tseliot> ok
<bryce> to be honest the whole blueprint approval process is a tad fuzzy for me, but that's how I understand it
<bryce> last time around I don't think my specs got set to Approved, but cj verbally ok'd them so I went ahead and did them.
<bryce> since colin was in for the discussion on this and seemed cool with it, getting it set to approved may be more of just a formality but he often has useful comments
<tseliot> great, this makes things a lot clearer
<tseliot> I'll keep working on it
<bryce> I'm also not sure if they need to be set to Review or Pending Approval...  I'll find out and adjust
<bryce> cool; I still owe you review comments.  it's on my todo list but after a few other things
<tseliot> ok, I wait for your comments then ;)
<kees> jcristau: just as a note, in the ProcShmPutImage fix, should the errorValue be totalHeight instead of totalWidth?
<bryce> tseliot: I've updated the X/OptionsEditor spec a bit with some thoughts based on the mockup.
<tseliot> bryce: great, I'll have a look at the changes tomorrow since it's 00:03 AM here. Good night
<bryce> great, 'night
<jcristau> kees: hrm. probably, yes
#ubuntu-x 2008-06-12
<jcristau> kees: actually, i think it doesn't matter. if width*height overflows, you don't really know if the error value is height or width
<jcristau> so choosing width makes as much sense as the other one
<kees> jcristau: heh, yeah, fair point
<jcristau> kees: you had me worried for a while ;)
<tjaalton> "GEM merging to master"...
<tjaalton> bryce: btw, should we branch xorg/xorg-server for hardy?
<tjaalton> and merge the current branch with experimental
<bryce> perhaps, although I'm not sure if we'll have a lot of changes for the hardy xserver
<bryce> (I also find having to give my password 3x to do a git pull to be irritating, but anyway) :-)
<bryce> merging the current branch with experimental is a good idea
<bryce> at yesterday's meeting, doko and slangasek were talking about giving MoM an ability to do merges of not just Unstable, but also the option of Testing and Experimental.  But I'm guessing that'll be a while.
<tjaalton> put an RSA key there, DSA keys don't work :)
<bryce> well I don't think I can ssh in anyway
<tjaalton> to alioth? you should be able to
<tjaalton> you can add the key from the web interface
<bryce> ah ok
<bryce> last I tried was a couple weeks ago, maybe things have changed
<bryce> yeah it just hangs.  I'll try the web interface
<tjaalton> hmm that's weird, mine keeps asking for the password without a key
<tjaalton> tseliot: I haven't had a chance to look at the package yet :/
<Q-FUNK> howdy
<Q-FUNK> has there been any report of the -intel that just entered hardy-updates disturbing suspend/hibernate?
<Q-FUNK> both pm-utils and -intel received new packages over the last couple of days.
<bryce> heya Q-FUNK
<Q-FUNK> heya :)
<tseliot> ï»¿tjaalton:no problem, superm1 reported a few problems but I haven't had the time to fix them today
<bryce> Q-FUNK: btw yesterday I was looking again at the -geode pci id fix to xserver and noticed the patch wasn't actually enabled
<bryce> Q-FUNK: it's enabled properly on intrepid though.  Have you had a chance to test against intrepid?
<Q-FUNK> hm?!
<Q-FUNK> not enabled?
<Q-FUNK> oh, to x server
<Q-FUNK> yes, it turns out that debian completely skips xf86config and instead uses the pic id provided by each driver
<Q-FUNK> at least, that's how it appears to me
<bryce> sounds right
<Q-FUNK> (others are welcome to correct me if I'm wrong)
<bryce> ok, so the patch in ubuntu9.1 is irrelevant?
<Q-FUNK> probably
<bryce> yeah that sounds right to me
<bryce> ok cool, I'll update the sru request
<Q-FUNK> I haven't entirely figured out whether debian completely skips the content of that file or wheter it complements it with the driver.ids that comes in each chip driver
<Q-FUNK> jcristau probably knows better than me, on that issue
<Q-FUNK> as for the -nsc fix, pitti pointed out that he'd rather have someone figure out a way to revert the Makefile.am patch that generates nsc.ids and replace it with my static list, rather than accept my completely overhauled package
<Q-FUNK> I guess it makes sense.  the delta would be a lot smaller.
<Q-FUNK> whoever manages to do it, we can also contribute it to debian.  it would save bgoglin the trouble of figuring out how to do this on his way back from vacations.
<bryce> Q-FUNK: ok, then sounds like there should be new bugs opened for those two issues
<Q-FUNK> for -geode, though, we pretty much have to move forward and adopt what I have in my PPA as-is.  trying to force-fit the update into the 2.8.0 packaging paradigm won't work.
<Q-FUNK> and we cannot upload this without the fixed -nsc being uploaded first, becuase of the versioned conflit
<bryce> hmm, in that case maybe it just can't be sru'd to hardy at all
<Q-FUNK> pitti tells me that it might be a though case.  however, either we do it or we end up with a broken LTSP in LTS for the next 3 years.
<Q-FUNK> and yes, moving those symbolic links to the transtional -amd package is the only clean way to do this
<bryce> -geode uploaded
<Q-FUNK> erm..... which one?
<bryce> the one in your ppa
<Q-FUNK> if we don't first upload the fixed -nsc, we actually break what little operativity we had
<bryce> I'm doing that one next
<Q-FUNK> the -geode in my PPA depends upon the fixed -nsc having been uploaded first
<bryce> it seemed to build fine
<Q-FUNK> yup, but it deviates from the XSF framework, which is why pitti found it totally unacceptable as an SRU
<bryce> howso does it deviate?
<bryce> ok, -nsc built... uploading
<bryce> ok uploaded
<Q-FUNK> debian has the same reservations about my cdbs-based refactoring, which is why both pitti and bgoglin would prefer simply removing the makefile.am patch and replacing it with a simple install of the static nsc.ids I produced
<kees> bryce: can you confirm on i386 that the DBE-DoS PoC is fixed in intrepid?  so far it's unfixed for me in hardy and gutsy.
<bryce> whoops, you had hardy listed there... need to set that to intrepid
<kees> jcristau: did you confirm that DBE-DoS was fixed in your builds?  I'm still seeing a DoS with it
<bryce> Q-FUNK: ok well once you have that let me know and we can re-upload the fixed version to intrepid
<bryce> kees: unfortunately my intrepid testing box is amd64
<bryce> kees: (at your recommendation ironically enough ;-))
<bryce> ooh, new -ati release
<bryce> erf, first need to finish up the -intel 2.3.1 upload though...
<kees> bryce: sure, but you can run an i386 kvm on it, yes?
<bryce> dunno, I don't have kvm set up on it at all
<bryce> kees: anyway since we're running the same version of xserver, if you can't verify it on hardy it almost certainly is also busted on intrepid.
<kees> bryce: well it seems that the DBE stuff isn't fixed, so I'd like to figure out how to get it fixed.
<kees> bryce, jcristau: err... it seems actually that there was no fix made for the DBE stuff?
<bryce> kees, hrm, I'm not sure what I could do to help there
<bryce> I'm not sure what you mean by 'DBE'.  There isn't a reference to "DBE" in the advisory?
<kees> bryce: yeah, that's what I'm seeing too.  Perhaps it was skipped for now?
<kees> I'll assume so, and get these updates tested for regressions.
<bryce> well, what is DBE?
<kees> everything else looks great in them -- all the PoCs fail now.  :)
<kees> notes in the PoC say: DOUBLE-BUFFER extension
<bryce> ok maybe jcristau knows more
<kees> yeah, I assume it's an unaddressed issue.
<jcristau> kees: the dbe dos wasn't considered a security problem
<kees> jcristau: okay, cool.  it certainly is a DoS though.  ;)  owchy on my VMs
<kees> filled / before I figured out what was going on.  hehe
<jcristau> heh
<jcristau> the fix on master is at http://cgit.freedesktop.org/xorg/xserver/commit/?id=23e71ef71a178505494d4b410f9314acfff81524
<jcristau> but, it won't apply directly on previous versions, and when an attacker has access to your x server you have other problems anyway
<kees> jcristau: yeah, I'm fine with that getting skipped.  :)
#ubuntu-x 2008-06-13
<bryce> is it correct that xserver 1.5 has a required dependency for libpciaccess?
<jcristau> bryce: yes
<bryce> 'k thx
<bryce> filed lp #239614
<ubottu> Launchpad bug 239614 in libpciaccess "main inclusion report for libpciaccess" [High,New] https://launchpad.net/bugs/239614
<tjaalton> bryce: I think we should get a newer mesa (7.0.x) in proposed.. there are a lot of fixes for lockups and crashes
<tjaalton> I'll prepare a diff
<tjaalton> even if it's post .1
<tjaalton> bryce: no need to modify the maintainer address for fakesyncs ;)
<tjaalton> since the version is !ubuntuN
<bryce> tjaalton: re:mesa agreed
<bryce> tjaalton: the ume guys asked me about it too
<seb128> hey bryce
<seb128> bryce: 
<seb128>  [dpkg-source output:] dpkg-source: error: file x11proto-dmx_2.2.2.orig.tar.gz has size 45403 instead of expected 45375 
<seb128>  [dpkg-source output:] dpkg-source: error: file x11proto-bigreqs_1.0.2.orig.tar.gz has size 42386 instead of expected 42493 
<seb128> those syncs a not working
<tjaalton> bryce: I'll upload a new merged version to intrepid soonish, debian pulled stuff from the stable branch that had a lot of 965 fixes
<bryce> seb128: is it just those two packages?
<seb128> yes
<bryce> hmm
<bryce> I put sync requests in for those two packages (#238712, #238713).  I wonder if they got sync'd incorrectly
<seb128> right, that's what I'm telling you
<seb128> the sync didn't work because the orig.tar.gz are different in debian and ubuntu
<seb128> you have to do manual syncs
<bryce> is there any way we can just chuck our orig.tar.gz and go with debians?  it sucks having to fakesync all these proto libs every time
<seb128> no
<bryce> bleah
<seb128> we can't override a published orig.tar.gz
<tjaalton> bryce: convince upstream to release new versions :)
<bryce> why not?
<seb128> because that would break hardy for example
<seb128> the md5sum would not correspond to the hardy checksums,e tc
<tjaalton> the same tarball is shared with multiple releases
<bryce> tjaalton: ahh
<bryce> tjaalton: well upstream hardly ever seems to release new versions of the protos
<tjaalton> right
<bryce> tjaalton: so this sucks
<tjaalton> bryce: yep, but the changes in them aren't that big, so bypassing them isn't a big deal
<seb128> well, debian doesn't do a lot of change to those either
<tjaalton> bigbig
<bryce> I guess but look at http://people.ubuntu.com/~bryce/Xorg/versions_current.html - debian changed like half of them
<bryce> maybe it's mostly administrivia
<bryce> seb128: I'll just fakesync those two then.
<seb128> thanks
<seb128> bryce: somebody will have to do the fake syncs anyway
<seb128> I mean for things on the merge lists
<tjaalton> bryce: right, cleanups etc judging by the changelogs
<seb128> tjaalton is listed for the input ones there
<tjaalton> what where?
<tjaalton> oh
<tjaalton> MoM
<tjaalton> those will be synced along with xserver 1.5
<seb128> tjaalton: http://merges.ubuntu.com/main.html
<tjaalton> seb128: yep
<seb128> when will the 1.5 xserver be available?
<tjaalton> when libdrm 2.3.1 is released
<tjaalton> and mesa 7.1
<bryce> tjaalton: dunno if you saw but I put in the mir req for libpciaccess today
<tjaalton> experimental has 7.1rc, but libdrm is needed for that
<tjaalton> bryce: yes I saw that, it's required as well
<tjaalton> I have to make a travel expense report of the trip to UDS before I leave on vacation, but maybe there's time to merge xserver so it's easier to re-merge when it's ready for upload
<tjaalton> :P
<bryce> tjaalton: I've got an -openchrome merge I'm going to upload
<tjaalton> hardy is now running on all the public workstations here, 229 in total ATM
<bryce> cool
<tjaalton> bryce: ok, it could be synced when the next version is uploaded on debian
<tjaalton> it only lacks the patch to generated the pci-id's list
<tjaalton> -d
<bryce> tjaalton: this -openchrome is the first merging of the ubuntu version and debian version
<bryce> yep
<tjaalton> bryce: right
<tjaalton> well, drop everything else than the patch and it's good :)
<bryce> tjaalton: I'd appreciate your review of it to make sure it's correct
<tjaalton> no problem
<bryce> yeah I did mostly drop everything...  still worth the check tho
<tjaalton> drop the diff somewhere and I'll have a look
<tjaalton> oh, uploaded already :)
<tjaalton> the changelog looks good
<tjaalton> actually you can see the commit diff on debian-x@ and compare :)
<tjaalton> bryce: uh, pulled my (nonexistend) hair off while doing the travel report, so have to postpone the merges to next tuesday
<bryce> tjaalton: bummer... well we can get to them eventually
<tjaalton> bryce: well, I've merged xorg-server now, but have to test which patches are still needed. That'll have to wait until next Tuesday ;)
<Q-FUNK> ok, it seems that bgoglin is about to upload a fixed package for NSC into unstable.
<Q-FUNK> once he's done, we'll just need to sync into intrepid.
<Q-FUNK> as soon as he has uploaded, I'll follow with a -geode that features a versionned Conflicts against older -nsc
<Q-FUNK> in all cases, the only tricky part is how we approach solving hardy issues
#ubuntu-x 2008-06-14
<solarion> there we go
#ubuntu-x 2008-06-15
<pwnguin> bryce: i have a very random question for you. which do you think is faster to render? svg or png?
<bryce> depends on the complexity of the svg
<bryce> pngs have some overhead due to having to decompress them, but aside from that the resultant raster is relatively fast to blit
<bryce> svg supports advanced functionality like filters, gradients, etc. which can be processor intensive for some chipsets
<bryce> however a really trivial one - just some simple shapes of solid colors - could actually render faster
<pwnguin> lets say the eclipse icon level
<pwnguin> a couple circles, some lines and a highlight
<bryce> it might be faster - again though, it depends on a lot of factors so it's best to just try it and measure
<bryce> however for icons, they're so tiny it's usually a moot point one way or the other
<pwnguin> im thinking about making a push to get rid of more svg icons
<pwnguin> err
<pwnguin> its kinda late.
<pwnguin> get rid of png / xpm for svg
<pwnguin> im just trying to look at the angles
<pwnguin> there's complaints that the ubuntu logo is too complex for the screensaver
<bryce> for inkscape, an advantage we saw is that we could put all the icons into a single .svg file, render that whole file in one go, and then slice out the rasters for the icons
<pwnguin> "slice out"
<pwnguin> ah, render high then drop lines
<bryce> some applications have each icon a separate .png file, so turning all that into a single file I/O operation can be quite significant
<bryce> filesystem I/O tends to be a major performance killer, so any optimization which allows you to avoid file I/O at the expense of processor or memory, tends to work out pretty well
<pwnguin> so svgz
<bryce> in theory you could do the same thing with .png's and put them all in the same file and then use offsets to slice out the individual images
<bryce> I know a lot of games do that for instance
<pwnguin> i need to get nussbaum's cluster
<bryce> an advantage with svg is that editing is a lot easier, since you don't have to worry so much about pixel placement, and can really easily scale, copy and paste bits from other icons (file folders, letters, etc.)
<pwnguin> and do an archive query on the size of svg icons
<bryce> of course, raster icons do have their advantages, like if you want to do hinting and optimize for specific sizes/resolutions
<bryce> to me the best argument favoring using svg for icons is that it makes it sooo accessible for artists to contribute
<pwnguin> that's my next question: does anyone actually optimize icons?
<bryce> some time look through inkscape's menus and you'll see there's hardly any menu items that *don't* have icons
<bryce> yeah some people do
<pwnguin> well, how many packages is the relevant question
<bryce> I'd guess all the major ones.  For joe random open source project, they probably don't.
<pwnguin> i mean, i dont really care about the icons in a program
<pwnguin> but the .desktop / launcher icons are branding
<pwnguin> hmm
<pwnguin> maybe its not nessecary to change out the icons, but just make sure they all have a scalable one available
<pwnguin> bryce: well thanks for the input. certainly plenty of detail to go on
<bryce> sure, I'd love to hear how things develop
<bryce> pwnguin: if you're really interested in svg icons, make sure to hang on #inkscape... lotta svg icon fanatics there with lots and lots of advice.  tell folks you work with me on ubuntu-x and they should treat you well :-)
<pwnguin> i dont do all that much work
<pwnguin> more like sophisticated stalking
<bryce> it's appreciated nonetheless :-)
<pwnguin> im thinking of applying for ubuntu membership
<bryce> pwnguin: cool!  :-)  Yeah I think you'd have no trouble
<pwnguin> but i'd need a few people to show up to declare me totally awesome and a super rad dude
<bryce> pwnguin: count me in, just let me know when
<pwnguin> i have no idea
<pwnguin> the next meeting is "undecided"
 * bryce nods
<bryce> I think they go once a month, and the last meeting was a week or two ago
<pwnguin> yea i noticed
<pwnguin> a ton of loco people on the planet
<bryce> in any case, I'll be happy to support you.  If you find out when the meeting is, let me know.
<bryce> pwnguin: do you have plans to go for MOTU?
<pwnguin> sure
<pwnguin> MOTU is kinda wierd
<pwnguin> i dont have wide interests
<pwnguin> everyone says they're more generalists
<pwnguin> plus, im fine with having my work peer reviewed
 * bryce nods
<pwnguin> i do have a ppa
<pwnguin> i guess the way to put it is a square
<bryce> I did Member -> MOTU -> Core Dev, so for me it was a good stepping stone.
<pwnguin> stack ubuntu on the bottom, debian in the middle and upstream at the top
<bryce> it let me get some experience uploading to universe and doing sponsorships, and while I didn't do a ton of MOTU work, it was good preparation
<pwnguin> most of ubuntu is horizontal; I'm more interested in a vertical approach
<pwnguin> my fingerprint reader for example, I follow the ML and the debian team's work
 * bryce nods
<pwnguin> i pulled from debian experimental and some patches on the ML / bugzilla
<pwnguin> thats all been superceded though since thinkfinger was brought into main
<superm1> well and it will be changing for intrepid pwnguin.  fprint is on its way :)
<pwnguin> superm1: i know
<pwnguin> superm1: does anyone actually discuss these things, or do they just do it and hope people notice?
<superm1> pwnguin, i talked to Keybuk about it
#ubuntu-x 2009-06-08
 * DBO pokes bryce 
<hyperair> hmm strange, all of a sudden usplash seems to be interrupted by KMS
<pavel__> hi, i have a trouble with my Intel Graphic Card. Xsserver often crashes during resume from suspend-to-disk if desktop effects are enabled ...
<lesshaste> hi all
<lesshaste> any way to make a mouse button act like a regular keyboard button (concretely I want to have CTRL on mouse 2)? 
 * apw waves to bryce .... how was the kms2 combined kernel?  any test results?
<lesshaste> I found the answer if anyone cares :)
<bryce> apw: heya.  I didn't get all the testing done friday - jaunty x freeze issue stuff ended up sucking up my time.  But I did test it again on -ati and it was ok as expected.  I'm going to get an nvidia card in and complete testing it today.
<apw> bryce, thanks for that ... at least ati still works, so i'll copy that to the KMS one for now
<apw> to the kms ppa to replace the other one, as it has a couple more ati patches than kms1
<Sarvatt> apw: did you say the nouveau KMS wasnt working on that kernel? do you get a drm fb?
<apw> Sarvatt, no not got any hardware to test Nouveau on at all.  Was more asking how testing had gone out there before i propmote that kernel to my KMS ppa
<Sarvatt> ahh i see, i'll try it out in a bit when i get home from work then. the ddx and libdrm to support it are in xorg-edgers, but mesa is going to need gallium packaged for 3d but I can build that locally to test if anything if the other bits are fine
<bryce> apw: on the kernel testing... sort of inconclusive results
<bryce> apw: I tested both with G70 and G86 cards, neither really high perf but both pretty bog standard nvidia cards.  In both cases dmesg shows drm detected the card and initialized nouveau
<bryce> however I could not get X booted in either case (still poking at it though)
<bryce> for the G70, X crashed during init...  I think perhaps there's a drm version mismatch
<bryce> for the G86, X started but is displaying a black screen... I think in this case it is a load detection problem.  Tried both DVI and VGA connectors, same problem.
<bryce> in any case, the kernel booted ok and drm seems to be loading properly according to dmesg, however console font is not changing size and vt switching is no faster than usual
<tormod> bryce can you mirror the kms cd? after hitting phoronix front page, we're getting traffic
<bryce> sure... url?
<Sarvatt> dont want to wait until the rewrite update tormod? im sure i wont hit 1TB in the next day
<tormod> Sarvatt: probably no problem :)
<tormod> bryce anyway, it's on the radeon-kms ppa page
<bryce> ok, downloading
<bryce> downloaded; ppa updated
<tormod> bryce: thanks
<tormod> bryce: if you check bzr, you'll see I updated the build.sh quite a bit
<tormod> made it more generic with a simple infrastructure for config files which can override/build upon each other
<bryce> cool
#ubuntu-x 2009-06-09
<tormod> so a few settings for a standard xorg-edgers cd, then just a few changes for a kms cd
<bryce> btw does this iso include apw's kernel now?
<tormod> or a xserver 1.7 cd which Sarvatt is customizing
<tormod> yes, it has to, if kms should work
<tormod> the build.radeon-kms.conf will d/l everything from the radeon-kms ppa so that will include the kms kernel there
<tormod> basically I turned the build.sh into a generic "make a cd from a ppa" tool
<bryce> heya jbarnes_PDX
<bryce> jbarnes_PDX: a few weeks ago you did something to update priority on a bunch of intel crash/freeze bugs - by chance did you do this with a script?  I'd love to see it, as I'm hoping to do up a launchpad/bugzilla report tool
<jbarnes_PDX> bryce: no, just by hand
<jbarnes_PDX> I'm a pretty manual guy :)
<bryce> jbarnes_PDX: heh
<Ng> how important is the fullscreen window unredirecting thing? Is it actually a massive performance win? I seem to have nothing but problems when I'm doing fullscreen things
<tseliot> Ng: when playing videos, it should fix tearing problems, at least with nvidia.
<Ng> tseliot: ah. the problem I have is that the fullscreen windows rarely seem to stay fullscreen&ontop, other things want to draw over them, so they have to flicker while they redirect
<Ng> e.g. I can never get flash video to go fullscreen
<tseliot> yes, that can be a pain
<tseliot> e.g. notifications can break full screen unredirecting
<Ng> yeah
<hyperair> hmm it seems hal is being deprecated?
<hyperair> in that case how does one go about configuring synaptics?
<jcristau> synclient works
<jcristau> or gpointing-device-settings, or whatever it's called this week
<hyperair> gsynaptics i believe
<hyperair> synclient isn't persistent
<hyperair> and gsynaptics....
<hyperair> er..
<jcristau> gsynaptics is gone
<hyperair> eh?
<hyperair> yeah gpointingwhatever
<hyperair> hmm
<hyperair> let's see if it's any good
<hyperair> but isn't there some desktop agnostic way of configuring it?
<hyperair> xorg.conf doesn't exactly work now due to the whole autodetection thing which causes strange issues
<hyperair> and if hal is deprecated, there goes another means. gpointingwhatever looks more like a hack than anything (setting the options when it's run upon desktop startup i suppose?)
<jcristau> hal still works
<bryce> for now
<jcristau> it may be deprecated, but there's no replacement..
<bryce> jcristau: udev?
<jcristau> meh.
<bryce> *shrug* well that's what I've heard bandied about
<jcristau> even if it's udev, the code to use that in X doesn't exist.
 * bryce nods
<hyperair> and udev is a pain to configure
<hyperair> even harder than hal
<jcristau> oh, that's possible?
<hyperair> er. i don't think it's possible for synaptics
<hyperair> but doesn't the touchpad have some sort of kernel module?
<tjaalton> possible being harder than hal
<hyperair> it is possible then?
<hyperair> doesn't every damn thing revolve around hal? why do we want to deprecate it then?
<tjaalton> I think the goal is for the end user to never need to poke udev rules
<tjaalton> upstream deprecated it
<hyperair> seriously? O_o
<hyperair> in favour of what?
<tjaalton> udev
<jcristau> hyperair: job security.  when you have something that works, deprecate it, and start again.
<tjaalton> hehe
<hyperair> ..
<hyperair> ....~.
<hyperair> shit. ssh session acting up
<hyperair> jcristau: good point.
<hyperair> Sarvatt: is there something wrong with Gallium?
<Sarvatt> it defaults to building a few gallium things, we dont ship it so its just wasting build time, and its basically not working right outside of softpipe right now? if you're asking why its disabled in a hook on edgers..
<bryce> heya Sarvatt
<Sarvatt> heyo!
<bryce> Sarvatt: btw how is the xserver snapshot in your ppa?  Something we could pull into xorg-edgers, or the xi2 stuff still too unstable?
<Sarvatt> works for meâ¢ but as you can see alot of stuff needs to be disabled that I dont know about reenabling, and every input driver rebuilt against it (i only did the few there), only problem I have seen is gimp crashing due to XI2
<Sarvatt> switching away from edgers would be *fun* if people just  blindly updated to the new stuff :D
<Sarvatt> accidentally built that livecd on the ppa page for it with the radeon KMS kernel when it didnt have the supporting drm/mesa/ddx in there, have to fix that up
<bryce> oh yeah driver rebuilds, hmm
<bryce> Sarvatt: think there's going to be any more ABI changes now that xi2 is in?  I didn't spot any obvious discussion either way on the xorg list.
<bryce> with alpha-2 coming up, I'm thinking after that is released would be a good spot to push in the xserver snapshot
<bryce> that'd maximize the amount of time we have for testing it before alpha-3
<bryce> I'd *sort of* like to see it tested in xorg-edgers prior to that, although rebuilding all the drivers for the ppa sounds like a hassle
<bryce> tjaalton: do you have any comments on rolling out xserver?
<Sarvatt> oh nice, the gimp crashes were fixed in the lastest one i uploaded, didnt notice
<hyperair> hmm xi2?
<hyperair> Sarvatt: xorg-edgers's snapshots have xi2 support?
<Sarvatt> no i've been doing it in a seperate PPA
<hyperair> aah i see
<hyperair> how does one activate the xi2 bits anyway?
<hyperair> or would i automatically have separate cursors for my touchpad and mouse?
<tjaalton> bryce: not really, I haven't tried master at all. but I think that the video driver abi hasn't changed, so it's probably just the input drivers that need a rebuild?
<bryce> sounds like it
<tjaalton> which would mean that <gasp> fglrx would continue to work
<bryce> can't be
<bryce> certainly at least the kernel will have changed enough to break it...  :-)
<tjaalton> hehe :)
<tjaalton> #define ABI_VIDEODRV_VERSION	SET_ABI_VERSION(5, 0)
<tjaalton> so it's still at 5
<tjaalton> but that doesn't mean it won't change before the release ;)
<tjaalton> bryce: also, in case you missed, xorg in unstable has stopped shipping the xorg.conf. it's halfway merged already, probably something to upload along the rest when it's done
<Sarvatt> its at 6 now
<tjaalton> INPUTDRV is
<tjaalton> sorry, XINPUT_VERSION
<Sarvatt> oh video I'm sorry
<bryce> tjaalton: how do you feel about not shipping xorg.conf?
<Sarvatt> funny thing is I havent had any luck using the drivers built against 1.6.1.901 on 1.6.99.1 (but I only tested intel), no idea if its due to the dri2proto change or what
<bryce> I sort of feel there's more value to keeping at least a skeleton version of it 
<bryce> I wonder if there's any boot time benefit to running without xorg.conf though
<tjaalton> bryce: I'm ok with it. there are some quirks in dexconf which might need another look
<Ng> interesting situation atm, I just resumed, I have working kb and the mouse moves, but xev reports no motion events, and I can't click on anything (lack ofmotion events is slightly confirmed by a lack of mouse-following focus)
<Ng> no obvious log entries
<virtuald> where do i follow development of the radeon-kms ppa? where's the mailing list?
<Sarvatt> do you guys --enable-config-dbus in xserver for a reason? master builds were broken for awhile after the xi2 merge with that and everyone i talked to said it shouldnt be enabled anyway.. couldnt find anything broken disabling it (it's default to disabled and i cant find any distros enabling it except ubuntu and gentoo), jcristau was saying it was for wacom before that was fixed to work with hal but wacom works fine with it disabled now
<Sarvatt>  http://sarvatt.com/downloads/Xorg.0.log.txt
<tjaalton> Sarvatt: probably no reason to do that anymore. it was only enabled to allow some sort of wacom hotplug at the time
<virtuald> i get no mouse pointer on my second screen :>
<bryce> virtuald: most discussion is here on this channel, but there is also ubuntu-x@lists.ubuntu.com
<virtuald> thanks
<bryce> Sarvatt: maybe tseliot uses the dbus interface for his synaptics configuration stuff?  (But his dbus daemon isn't in Ubuntu yet)
<tjaalton> I think we'll notice ;)
<Sarvatt> i should have gotten bootcharts of it when i was disabling it, it felt like it booted faster disabled
<tjaalton> there should be no need for it
<tjaalton> I hope tseliot uses Xinput in his tool, just like gpointing-blah
 * Ng files a bug :)
<tjaalton> Ng: some app grabbed the focus?
<Ng> tjaalton: hmm, I did have vinagre running across the suspend, which may do something like that, but I killed it from a console
<bryce> tjaalton: perhaps not for configuration, but what about for troubleshooting?
<Ng> man I love vimperator. my browser is just as useful without a mouse as with :D
<tjaalton> bryce: xorg.conf?
<tjaalton> bryce: you can still run dexconf
<Ng> tjaalton: is there any way to reset that kind of thing?
<Ng> (I'm guessing not ;)
<tjaalton> Ng: I'm not sure..
<tjaalton> killing the app probably should release it
<bryce> tjaalton: hmm
<Ng> tjaalton: not so much ;(
<tjaalton> gotta go, bye
<Ng> ooh, it was definitely a grabbing issue, locking the screen and unlocking has restored normality \o/
#ubuntu-x 2009-06-10
<Sarvatt> hmm think i stripped too much out of the livecd that time, kept crashing back to gdm login :P got the iso down to 446MB ripping out printing/scanning stuff though
<wesmo> hi all
<wesmo> When trying to build the latest drm-modules source from https://launchpad.net/~xorg-edgers/+archive/ppa with "sudo module-assistant auto-install drm-modules"; the build fails
<wesmo> the buildlog from /var/cache/modass/drm-modules-source.. is http://pastebin.com/m70a9e8bb
<wesmo> any idea whats wrong?
<crevette> heya
<crevette> when I used KMS this week-end with intel, I had the screen that became black during the boot process and I ws not able to see anything else. I am using plain karmic. What information would you need? (I don't have my laptop here) 
<jcristau> crevette: kernel log for a start
<crevette> jcristau, okay
<crevette> I'll try to test KMS in the coming days to see if it happens again
<jcristau> this is using a stock kernel, not a self-compiled one, right?
<crevette> yep, all stock
<crevette> on https://wiki.ubuntu.com/X/KernelModeSetting you can look for bmillemathias
<jcristau> so it could be misdetecting the connected outputs. and then turning off the lvds.
<crevette> when I trying to switch vt, I was alble to seem some text on the vt5 IIRC
<seb128> on what package do you suggest opening a bug about xorg crashing on jaunty intel when playing some videos?
<seb128> the server or the intel driver rather?
<tjaalton> intel I think. although there probably are dupes in the 300 open bugs ;)
<Ng> the uds spec for karmic xorg plans gives the impression that apart from xserver 1.7, the merges are generally done at this point :o
<Ng> assuming I'm reading that right, that rocks :)
<tjaalton> Ng: we still need a newer mesa, and the nouveau version is obsolete
<Ng> it all seems to be in pretty good shape to me :)
<tjaalton> I'll try to remember that in late September ;)
<jcristau> you're planning on mesa 7.6-ish?
<tjaalton> something like that
<tjaalton> I'd really like to see r6/7xx support in the dri driver, but it's the holiday season soon etc..
<tjaalton> unless it's going to be released as a bug-free driver :)
<Ng> tjaalton: when I start screaming at the last minute because of bugs? ;)
<tjaalton> Ng: gotcha :)
<Ng> hehe
<Ng> I'm running the dev version *way* earlier than usual, so hopefully I'll spot anything sooner :)
<Ng> I normally wait until a month before beta
<jcristau> tjaalton: ah yeah good point.  hopefully r6/7xx will be usable by then.
<jcristau> if it's not, then it'll be usable by squeeze ;)
<tjaalton> jcristau: that's just my hopeful thinkin, fingers crossed
<tjaalton> +g
<XCP2> hi. there's a bug in xorg in the newer versions of ubuntu that has not been fixed. however, there is a PPA on launchpad that apparently fixes the problem (not in clean way, but it's okay for me). Now my question: if I apply this PPA patch and some time later there is an official ubuntu patch for this problem, or any other update to xorg, will and can this newer update still be applied, although I manually changed my xorg some time before?
<jcristau> i guess it depends on the version number in the ppa
<XCP2> jcristau: here's the link. (how would I find out the version number from it?) https://edge.launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill ... it fixes a problem in xorg, which causes xorg to use up 6GB+ memory after a while and take it 3-4 seconds to maximize a single window, each time leaking memory.. 
<XCP2> this bug has actually haunted me and other users for 2 months now, and I finally found this unofficial patch (because the official developers seem to see no reason to fix it)
<jcristau> the description on that ppa doesn't sound like it has anything to do with a memory leak
<XCP2> jcristau: yes, this is misleading, I know. it actually reverts a patch that causes this memory leak.
<XCP2> jcristau: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/351186?comments=all
<ubottu> Launchpad bug 351186 in fglrx-installer "[ubuntu 9.04] slow unminimizing with ati card and desktop effects enabled" [Undecided,Confirmed]
<jcristau> no it doesn't.
<XCP2> jcristau: according to the patch author, it does
<jcristau> *shrug*
<jcristau> anyway yeah, if there's an update in jaunty proper, it will take precedence over this package
<XCP2> so the answer to my original question is 'yes'? I can install this PPA and still have my xorg be properly updated later by ubuntu?
<jcristau> yes
<XCP2> thank you, jcristau. :)
<XCP2> I don't want to be importunately or something, but this bug is known for over 2 months now, it has 3 duplicates, and as you can see a lot of affected users. it really is a very annoying bug which seriously hinders usage of a system. how come this still isn't fixed? I cannot see any information on why it is taking so long.
<Sarvatt> because there are even more people broken and just as annoying by disabling it most likely :) (aka all kubuntu users)
<Sarvatt> just as annoyed*
<XCP2> Sarvatt: please say again? what do you mean? 
<Sarvatt> http://bugs.kde.org/show_bug.cgi?id=170462
<ubottu> KDE bug 170462 in compositing "Video garbage when drawing new object (Comment #54)" [Normal,Resolved: downstream]
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/310228
<ubottu> Launchpad bug 310228 in xorg "patch 107_fedora_dont_backfill_bg_none.patch causes video garbage in KDE 4 (dup-of: 254468)" [Undecided,New]
<ubottu> Launchpad bug 254468 in xorg-server "MASTER: momentary video garbage upon drawing new objects (particularly in KDE)" [High,Confirmed]
<XCP2> oh, I get what you mean... but then again, you can have the patch to the KDE problem AND patch the patch :) it's not like the only solution is to revert the patch.
<jcristau> it's the one that's available today
<jcristau> and since this isn't a high priority thing..
<XCP2> jcristau: no offense, but if you had this problem yourself, you would certainly think otherwise. it is very annoying, my system crashes every so often because xorg becomes a memory hog, and whenever I maximize windows I have to wait for 3-4 seconds. I'd rather have video garbage than this.
<jcristau> XCP2: the no-backfill patch doesn't change memory usage.
<XCP2> jcristau: have you test it yourself? do you have an ATI card?
<jcristau> no, and no
<XCP2> then how do you know? :)
<jcristau> because i've seen the patch?
<XCP2> jcristau: maybe the change in memory usage & behavior is just a side effect, not visible in the code. 
<XCP2> but, that's just a guess.
<XCP2> jcristau: from what I understand, the backfill patch itself leaks memory and therefore applying the no-blackfill patch reverts that behavior.
<jcristau> sounds like a driver bug to me...
<XCP2> maybe, but I used the same official ATI driver on 8.04 & 9.04... on 8.04 it does not happen, on 9.04 it leaks.
<XCP2> still, can be a driver issue, but I think it's rather unlikely.
<lesshaste> any cuda users here?
<jbarnes_PDX> bryce or apw: who should I harass about bluetooth stuff?
<superm1> jbarnes_PDX, what about bluetooth stuff?
<superm1> i happen to touch it a lot, but i dont pretend to know everything about it :)
<jbarnes_PDX> superm1: oh cool
<jbarnes_PDX> with karmic bluetooth bits (gnome-bluetooth & pulse stuff)
<jbarnes_PDX> a2dp *almost* works automatically
<superm1> jbarnes_PDX, that's great to hear!
<superm1> what's the "almost" tho ;)
<jbarnes_PDX> well sometimes it doesn't pair
<jbarnes_PDX> and it also doesn't work with skype (with karmic bits skype no longer lists "pulse" as an option)
<superm1> isn't default equivalent to pulse though?
<jbarnes_PDX> also with the pulse dev chooser I'd expect my headset to show up as a new sink
<jbarnes_PDX> probably should be, but doesn't work
<jbarnes_PDX> and finally, when switching profiles, between a2dp and headset, I need to unpair and pair again, which seems wrong
<jbarnes_PDX> it's cool to be able to listen to music, but I'd like for everything to "just work"
<superm1> yeah i agree, yeah that does seem wrong
<jbarnes_PDX> ideally, I turn on my headset and a dialog pops up "wanna use this?  as a headset or stereo headphones?"
<jbarnes_PDX> and takes care of the rest (making it default in pulse, moving my streams over, etc)
<jbarnes_PDX> I guess I'll chat with marcel about which bits I ought to use, then file bugs in launchpad
<superm1> unfortunately marcel doesn't use an upstream tracker at all
<superm1> he browses launchpad every so often, but doesn't commit to fixing bugs
<jbarnes_PDX> right
<jbarnes_PDX> brb
<superm1> how do you switch profiles on your headset? is it a little switch?
<jbarnes_PDX> superm1: no, pulse lets me choose
<jbarnes_PDX> superm1: but my headset doesn't need to repair afaik
<jbarnes_PDX> my phone can switch profiles pretty easily at least... it doesn't take long
<superm1> ah that's surprising. i didn't realize that the pulse plugin was that feature filled
<crevette> superm1: latest pulseaudio make audio over bluetooth quite easy
<crevette> :)
<superm1> oh hai crevette
<crevette> hey hey superm1
<superm1> do you follow linux-bluetooth@vger?
<crevette> ubuntu-x became the lair for bluetooth discussion ?
<jbarnes_PDX> crevette: yeah it's really close to being nice
<superm1> haha
<jbarnes_PDX> crevette: heh
<crevette> superm1: unfortunately I lack time to
<jbarnes_PDX> probably #ubuntu-desktop would be better?
<crevette> :)
<superm1> crevette, okay well i was gonna let you know, i talked to petr @ redhat, and that ondemand stuff is going upstream
<superm1> so lets wait in ubuntu until it's ready upstream
<crevette> superm1: ah I see you asked that on the IRC chan few days ago
<crevette> ah wonderful
<superm1> i did?  I spoke to him over email i thought..
<crevette> I've opened a but in debian because I was thinking to merge our delta with debian package
<crevette> superm1:you did :)
<superm1> actually i think we can sync to debian
<superm1> i reviewed the delta yesterday, and it looks like everything we have is useless right now delta wise
<crevette> superm1: there is no change to keep on ubuntu side?
<superm1> i just want to test their hid2hci changes
<superm1> hid2hci is where i invested my blood in bluez, so if we sync and that breaks, i think i'll cry
<crevette> my knowledge in blueooth is quite ... low, so as does it does, switching hid devices to another mode?
<crevette> s/so as does it does/so what does it does.
<jbarnes_PDX> I'm not sure
<superm1> some bluetooth devices support a mode that doesn't expose a BT radio, but instead lets a pre-paired keyboard and mouse work 
<jbarnes_PDX> I don't know if it has to renegotiate the link or just tell the dev to switch profiles
<superm1> all "newish" dell devices start up in this mode. i wrote some patches to hid2hci to get them back
<jbarnes_PDX> oh hid devices
<superm1> how its done for different BT chips is proprietary on a vendor by vendor basis
<superm1> generally if you are using a hid device in hid mode and then want to use the hid device in hci mode too, you will have to renegotiate the link
<bryce> jbarnes, heya
<jbarnes_PDX> bryce: howdy
<bryce> btw, I sent a couple bugs upstream yesterday, but interestingly I found that pretty much all the UXA, KMS, 2.6.30, 2.6.99* bugs in our tracker seem to already be upstream near as I can tell
<bryce> so... that's good news... sounds like most everything that's worth caring about at the moment is upstreamed
<jbarnes_PDX> yeah that's great
<bryce> however I still need to do my script thingee to ask everyone to re-test.  gonna work on that today
<jbarnes_PDX> bryce: has a kernel landed in xorg edgers yet?
<bryce> we've got a few kernels bouncing around in ppas, but not in xorg-edgers so far
<bryce> apw has been working on one with nouveau and ati bits merged in
<bryce> jbarnes, is there a particular kernel you think we should pull into xorg-edgers?
<jbarnes_PDX> cool
<Sarvatt> kernel for what?
<bryce> heya Sarvatt
<jbarnes_PDX> bryce: I was hoping for something with drm-intel-next merged into it
<Sarvatt> heyo!
<bryce> ahh
<bryce> I'll try to remember to ask apw if he'd be able to produce one next time I see him
<lesshaste> anyone here got cuda to work?
<bryce> lesshaste: nope
 * apw is just off, if you email me a reminder i'll have a peek tomorrow.  it may be hard to give you just one kernel for all of those on an on going basis if they collide, but i can try it out
<apw> bryce, ^^
<bryce> apw: cool, will send an email later today
<lesshaste> bryce, :( did you try?
<Sarvatt> drm-intel-next drm-radeon-merge and newttm for nouveau dont all merge right now :(
<apw> cirtianly i had to work hard to get the latter two to merge last time
<apw> those gem guys need to get their heads together!
<bryce> lesshaste: no, I'm pretty sure no one on this channel has experimented with it, so this may not be the optimal place for discussion on it
<lesshaste> bryce, ah
<lesshaste> bryce, it's very hard to find anyone who has got it working to be honest
<lesshaste> as in so far I have found exactly no one
<bryce> lesshaste: maybe you'll become the definitive source if you write a good blog post on it ;-)
<lesshaste> everything could be solved if there was a package for cuda in a repository
<lesshaste> but I can't find one
<lesshaste> bryce, :)
<Sarvatt> i saw a PPA for cuda a few months ago
<lesshaste> Sarvatt, ooh!!
<lesshaste> I searched for the word cuda but didn't see it
<lesshaste> any idea how to find this?
<crevette> superm1: do you want to package 4.41? or do you prefer me to do it?
<superm1> crevette, after i check debian's package w/ hid2hci on karmic, i think we can just ask debian to do it
<superm1> and sync from them instead
<superm1> did you see anything in the delta from debian that we needed to keep?
<crevette> superm1: when you say "ask debian to do it" you mean slap filippo until he did it?
<crevette> :)
<superm1> exactly
<crevette> let ask to sync on it once debian has it
<lesshaste> Sarvatt, any ideas? I only see things like https://bugs.launchpad.net/ubuntu/+bug/203503
<ubottu> Launchpad bug 203503 in ubuntu "[needs-packaging] cuda packages" [Wishlist,Confirmed]
<Sarvatt> lesshaste: http://forums.nvidia.com/index.php?showtopic=93535 ?
<lesshaste> Sarvatt, thanks.. that's the painful route I have been trying
<lesshaste> you just feel envyng should do this for you
<lesshaste> hmm.. maybe it does secretly
<lesshaste> will check tomorrow
<bryce> Sarvatt: have you had a chance to test the kernel at https://edge.launchpad.net/~apw/+archive/daily ?
<Sarvatt> are you just trying to run cuda apps? because the cuda libs should be installed by the driver, the guide is just for installing the SDK to develop against..
<bryce> I'm thinking of pulling it into xorg-edgers.  I've tested it on several different video cards, and think it could be useful for further KMS work in X.org, but what do you think?
<Sarvatt> i dont think its really compatable with putting in edgers right now because it has radeon KMS enabled by default and the drm/ddx parts arent compatable with the packages on there
<bryce> ok
<Sarvatt> i guess we could start shipping libdrm-radeon1 in libdrm though.. but the ati ddx is kind of a regression from master for non KMS stuff, i'm not sure if it'd require us to start merging radeon-rewrite with master on mesa on top of that too
<Sarvatt> really though, not much point IMO because the KMS stuff has already been presented for proposal in 2.6.31 a few hours ago, hope they clean up the libdrm stuff soon
<lesshaste> bryce, I see you are involved in envyng?
<lesshaste> bryce, where is the #envy channel?
<lesshaste> unless there is another bryce :)
<lesshaste> tseliot, hi
<tseliot> lesshaste: hi
<lesshaste> tseliot, I wanted to ask an envyng question.. if you don't mind
<tseliot> lesshaste: shoot
<lesshaste> I am trying to get cuda to work and have been struggling all day
<lesshaste> envyng installs 173.x I think  hardy
<lesshaste> which doesn't seem compatible with the cuda sdk you can download from nvidia
<lesshaste> but I may have this messed up
<lesshaste> do you think that it's possible to get cuda working with the version of the nvidia driver envyng gives you?
<Sarvatt> yeah thats not compatable, they didnt make the drivers cuda compatable until the 180's
<lesshaste> but envyng does give you a cuda library file
<lesshaste> so I am confused
<tseliot> lesshaste: cuda in 173?
<lesshaste> I went in so many circles today I may have this wrong
<lesshaste> tseliot, so let's scrap my ignorance just ask the key question
<lesshaste> could you please make an envyng version that also installs cuda :)
<lesshaste> as it is killing me
<lesshaste> I installed the later nvidia driver
<lesshaste> but I really can't get cuda to work
<Sarvatt> ahh sorry, i thought it was 180's only for some reason, maybe that was the case on windows or something because thats the only place i've messed with the cuda sdk
<lesshaste> I see http://albertomilone.com/wordpress/?p=148 .. which seems to say to me that envy does provide cuda now
<lesshaste> I am so confused :)
<tseliot> lesshaste: the packages provide cuda. Maybe install the -dev package of the nvidia driver (the -envy flavour)?
<bryce> heya tseliot
<lesshaste> tseliot, ok so once I have installed should I be able to compile the cuda SDK?
<lesshaste> tseliot, because I feel it failed today
<tseliot> hi bryce
<lesshaste> or can envy get  a version of the SDK that works too?
<tseliot> lesshaste: I guess so. Make sure you uninstall the driver that you installed from the nvidia installer first or you'll end up with a mess
<tseliot> lesshaste: Envy doesn't get the SDK
<lesshaste> tseliot, ok.. what's the best way to uninstall the driver from nvidia?
<lesshaste> ah.. maybe nvidia-installer --uninstall
<tseliot> lesshaste: have a look at point B of the FAQ: http://albertomilone.com/envyngfaq.html#B
<lesshaste> tseliot, thanks.. I don't have the computer here now but will try it all tomorrow.. especially compiling the sdk
<lesshaste> tseliot, will you be about at all tomorrow?
<lesshaste> so I can thank you :)
<lesshaste> also, perhaps some words about cuda could be added to the FAQ?
<lesshaste> for dumb people like me
<tseliot> lesshaste: yes, even though it's 21:43 here now and I don't work at this time. But my computer is always on ;)
<lesshaste> tseliot, mine too :)
<lesshaste> it's 20:43 here
<lesshaste> tseliot, the point is that the web is full of detailed instructions for how to get cuda to work in ubuntu and..
<lesshaste> a) they don't work
<lesshaste> and b) they don't mention envyng 
<tseliot> lesshaste: I don't use it, therefore I wouldn't be comfortable with writing instructions for the things that I've never tried
<tseliot> I made sure that the libcuda.so, etc. were provided by the packages
<lesshaste> tseliot, ah ok.. I'll let you know what happens when I try it in that case
<lesshaste> if you are interested
<tseliot> ok
<lesshaste> tseliot, oh yes.. is there really a #envy channel somewhere?
<Sarvatt> http://lkml.org/lkml/2009/6/10/294
<tseliot> lesshaste: no, I don't think there is one. I don't even have the time to maintain envy anymore
<lesshaste> tseliot, ah ok.. there is an irc log https://wiki.ubuntu.com/EnvyNG
<lesshaste> it must be faked :)
<Sarvatt> why dont you just use the binary drivers from nvidia lesshaste? only issue with those is having to reinstall them every kernel upgrade, but how often do you get kernel upgrades still on hardy?
<lesshaste> Sarvatt, well.. let me tell you :)
<lesshaste> Sarvatt, I did exactly that and installed 185.18.08
<lesshaste> I think compiled the SDK as per instructions
<lesshaste> and when I run any cuda sample I get
<Sarvatt> those had a library problem screwing up some mesa things that got fixed in .14 i think
<lesshaste> cutilCheckMsg() CUTIL CUDA error: cudaMalloc failed in file
<lesshaste> <fluidsGL_kernels.cu>, line 49 : initialization error.
<lesshaste> or equivalent
<tseliot> lesshaste: what card are you using?
<lesshaste> Sarvatt, http://www.nvidia.com/object/cuda_get.html offers only 185.18.08 as the latest version
<lesshaste> tseliot, geforce 6200
<Sarvatt> .....
<Sarvatt> you know those dont  support cuda right
<lesshaste> err..
<Sarvatt> 8xxx and up..
<lesshaste> no!!
<lesshaste> I had no idea
<lesshaste> I feel quite depressed now 
<tseliot> Sarvatt: are you sure? He's talking about CUDA not VDPAU
<Sarvatt> yeah positive, even the site he linked shows it requiring 8xxx and up
<Sarvatt> http://www.nvidia.com/object/cuda_learn_products.html
<tseliot> aah, you need the latest driver to use the latest version of CUDA
<Sarvatt> http://en.wikipedia.org/wiki/CUDA
<Sarvatt> The latest drivers all contain the necessary CUDA components. CUDA works with all NVIDIA GPUs from the G8X series onwards, including GeForce, Quadro and the Tesla line.
<lesshaste> well.. what an idiot!!
<tseliot> you're right. I thought it was just VDPAU that required newer cards
<tseliot> problem solved then ;)
<tseliot> well, kind of
 * tseliot > away
<lesshaste> sorry everyone for that
<lesshaste> I wasted quite a lot of time :)
<lesshaste> Sarvatt, thanks
<bryce> Ng: hey, quick question on your 8xx system - does it have an S-Video (TV-out) port?  If so, would you mind testing at some point when it's convenient if it does not work on jaunty, and then test karmic alpha-2 as well?  I'm looking at bug 6270 (currently the lowest-numbered X bug report yay), and wondering if the problem is going to still be a problem with the new stack.
<ubottu> Launchpad bug 6270 in xserver-xorg-video-intel "[i855] no support for TV-Out on 8xx chipsets" [Unknown,Confirmed] https://launchpad.net/bugs/6270
<Ng> bryce: 'fraid not, just LCD and VGA
<bryce> Ng: ok thanks
<lesshaste> what's the easiest way to get a dual head setup in ubuntu?
<lesshaste> basically, what card do I need to buy?
<bryce> lesshaste: I have an ATI X1650 that is quite easy to configure
<bryce> lesshaste: I'd recommend any ATI in the R5xx class
<bryce> be aware that R600 and newer are not supported as well by the open source driver, but 6xx/7xx cards are the most common in stores these days, so it takes some hunting to find a suitable R5xx card
<lesshaste> thanks
<bryce> Intel 945 and 965 are also good choices, but only come on motherboards
<bryce> with nvidia, I've heard good things about 8800 GTS, however pretty much with nvidia you're still limited to the proprietary driver only
<bryce> I've heard 8800 works with -nouveau, and in fact I've put in an order for one in order to check that out.
#ubuntu-x 2009-06-11
<Sarvatt> apw: do you think we could bring the karmic kernel to the jaunty in edgers? that would make packaging easier and everyone using it would be using the kernel most likely anyway
<Sarvatt> cworth mentioned it in his latest blog post and it seems like a good idea to me - http://cworth.org/intel/driver_stability/
<Sarvatt> theres some problems on the intel side using the jaunty config the mainline PPA kernels use and activating KMS, plus it would get rid of the trickery we have to do replacing linux-libc-dev on jaunty for building libdrm
<Sarvatt> is there any trickery needed to build them on a PPA or can we just copy them straight from the archive?
<Sarvatt> hmm i guess LPIA might be a problem
<bryce> what I've heard is that building kernel debs is really not much different than other packages, however I've not given it a try yet myself
<Sarvatt> well, going to copy it over since it'll take a few hours to build so it'll be ready to repackage stuff against it tomorrow morning. hopefully someone will be around to delete it if anyone pops on and has it break things or if it was a bad idea for other reasons :D
<bryce> :-)
<bryce> fwiw, I'm going to be away the next few days.  Going up to Seattle for my sister's graduation
<Sarvatt> ohh, have a good trip! hopefully alpha 2 wont be so bad for bug reports so you wont have to come home to a mess :D
<bryce> hehe
<tjaalton> whee, wacom moving to fd.o
<tjaalton> and apparently getting support for input properties
<pwnguin> tjaalton: orly?
<tjaalton> pwnguin: yep, ping posted on xorg-devel about it
<tjaalton> and about changing the license gpl->mit
<apw> Sarvatt, we would likely want to rebuild it, but otherwise it should be doable.
<Sarvatt> hmm  i see xserver-xorg-video-nv doesnt have any support for 7xxx and newer IGP chipsets in it, anyone know if thats by design or just missing pciids?
<jcristau> hmm?
<tjaalton> Sarvatt: does anyone care?-)
<Sarvatt> well its picking nv on startup for alpha 2 instead of vesa so theres alot of people having problems with it - http://launchpadlibrarian.net/27754976/XorgLog.txt
<tjaalton> we should switch to nouveau instead
<jcristau> Sarvatt: that's fixed by removing xorg.conf
<tjaalton> that too
<jcristau> and yeah, the status of nv looks like nvidia wants people to switch to nouveau
<Sarvatt> thats weird, livecd-rootfs should be deleting and touching an empty xorg.conf looking at the code for that
<tjaalton> yep, our xorg is buggy
<tjaalton> fixed in debian
<Sarvatt> ah i see, fedora-pci-primary.diff
<tjaalton> no, the logic in xserver-xorg.postinst was busted
<jcristau> plus preinst was creating an empty xorg.conf
<tjaalton> yeah
<tjaalton> Sarvatt: what bug # was that?
<Sarvatt> https://bugs.launchpad.net/bugs/385658
<ubottu> Launchpad bug 385658 in xorg-server "karmic alpha2 candidate doesn't boot up on Studio XPS 1340" [Undecided,New]
<tjaalton> thanks, I'll add a bug-closer for that
<tjaalton> Sarvatt: in this case it tried to use the wrong device, so you were right that the patch makes a difference
<jcristau> that bug shows that dexconf was run, somehow
<jcristau> how did that happen?
<superm1> live cd
<superm1> just booted up off the karmic a2 candidate and hit a failure
<superm1> i'd guess that dexconf runs because of casper?
<superm1> casper runs the equivalent of dpkg-reconfigure xserver-xorg
<superm1> and the xserver-xorg postinst runs dexconf
<jcristau> it shouldn't. but maybe karmic a2 had an older version that still did that.
<tjaalton> yeah could be
<tjaalton> it isn't run when doing a preseeded installation
<tjaalton> but a "normal" installation apparently runs it
<superm1> so should dpkg-reconfigure xserver-xorg not be called out by casper anymore then?
<tjaalton> it'll be unnecessary soon
<superm1> just drop the 20xconfig?
<tjaalton> although I'm not sure what bryce thought about it..
<superm1> well what about that problem at hand though. that fallback to vesa? did that ever get submitted upstream? was there a reason they said no?
<jcristau> superm1: in latest sid dpkg-reconfigure xserver-xorg basically doesn't do anything
<superm1> yeah then 20xconfig makes very little sense to keep once next merge happens
<tjaalton> superm1: in this case it matches the G98 device, which nv does support, but the server tries to use the C79 one
<superm1> it's a hybrid device, so i'd guess the one selected is the primary one hooked up to the display
<tjaalton> you never know for sure how the autoconfig logic works ;)
<jcristau> 'not quite always sanely' :)
<tjaalton> once we stop using the .ids files it'll be a lot simpler :)
<tjaalton> and without the conffile
<jcristau> yeah it's mostly the conffile
<superm1> so all .ids are going away then?
<tjaalton> yes
<hyperair> if the .ids go, then how will xorg determine which driver to load?
<tjaalton> the server knows what driver to try
<tjaalton> based on the vendor id
<tjaalton> and if that fails, it'll fall back to whatever is the fallback driver for that platform
<tjaalton> for x86 it's vesa
<tjaalton> but it only works if there's no conffile at all
<tjaalton> even if it's empty, the codepath is different
<hyperair> ah i see
<hyperair> and about x64?
<tjaalton> the same
<tjaalton> but ppc, sparc use something else
<tjaalton> for instance
<tjaalton> well, sparc has wsfb, the rest use fbdev
<Sarvatt> if thats the case, might need to change things here for the livecds? http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/annotate/head%3A/livecd.sh  -- line 477
<jcristau> tjaalton: wsfb is only on solaris iirc
<tjaalton> jcristau: right, for linux it's sunffb
<tjaalton> #elif defined(__sparc__) && !defined(sun) matches[i++] = xnfstrdup("sunffb");
<tjaalton> Sarvatt: uh.. madness
<jcristau> tjaalton: made sense when xserver-xorg.preinst did the same thing :)
<tjaalton> jcristau: hmm yeah, I remember that now
<jcristau> awful hack though
<superm1> tjaalton, well when uEFI comes around with no BIOS compatibility mode, VESA doesn't exist on x86
<superm1> you have to use fbdev
<tjaalton> superm1: heh, ok
<superm1> which unfortunately will be coming sooner than I hope
<tjaalton> oh, when exactly?-)
<superm1> soon enough that i have a roadmap for such things happening
<bdmurray> bryce: bug 357901 looks like an x bug and has a patch even.
<ubottu> Launchpad bug 357901 in ubuntu "xinerama mouse cursor on every screen" [Undecided,Confirmed] https://launchpad.net/bugs/357901
<tjaalton> bdmurray: I'll reassing it to xorg-server
<tjaalton> -sign
<tjaalton> heh, I've done that before
<virtuald> is it possible to choose screen resolutions for radeon kms boot? i have two monitors of different sizes
#ubuntu-x 2009-06-12
<Sarvatt> oh boy, radeon-rewrite merge :D
<Sarvatt> all of these transient build failures in the install part of mesa are really annoying when you've uploaded it to 3 different PPA's and have to retry random ones when it happens :D
<lesshaste> which version of nvidia does envyng for jaunty support?
<tseliot> lesshaste: envyng installs the drivers from Jaunty's repositories
<lesshaste> tseliot: hi
<tseliot> lesshaste: hi
<lesshaste> tseliot: which repository has the binary nvidia drivers?
<lesshaste> in relation to your comment above
<tseliot> lesshaste: Ubuntu's standard (main/restricted) repository
<lesshaste> do you mean nvidia-glx-new-envy ?
<tseliot> lesshaste: no, nvidia-glx-180 etc.
<lesshaste> tseliot: hmm.... for hardy at least there is no such package of even a similar name
<tseliot> lesshaste: that's because things are different in jaunty
<lesshaste> tseliot: ah ok
<lesshaste> thanks
<tseliot> np
<Sarvatt> anyone familiar with the mesa build process here? starting around this commit we've been having build problems on the PPAs on amd64 where it was racy and needed retrying multiple times for it to complete successfully http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_5_branch&id=5df64685892aea4dabee377352888d8eb58e9446
<Sarvatt> here's the failure logs from 2 seperate PPA building the same package https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+build/1074691/+files/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090612.41091087-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz   http://launchpadlibrarian.net/27837181/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090612.41091087-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> woo, huge number of DRI2 commits cherry picked into xserver 1.6 branch 
<Sarvatt> jbarnes: are the fixes in there dependant on dri2proto 2.1?
<jbarnes> yeah
<jbarnes> at least, afaik...
<Sarvatt> glad someone asked for that to be tagged yesterday then
<Sarvatt> question: would things built against the newer dri2proto be portable to things without it? i couldnt use intel 2.7.1 drivers built against xserver 1.6.1.901/dri2proto 1.99.3 on xserver master and i dont know why. just wondering incase that might be the reason before I put everything on edgers before we put 1.7 on there :D
<jbarnes> I'm not sure of all the combos
<jbarnes> you should ask idr
#ubuntu-x 2009-06-13
<Sarvatt> oh good, one of my laptops with synaptics has this problem and it fixed it - http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=61c7bfcdf5acee06f58b246d6615989134719d19
<Sarvatt> ahh, tried to push some pci id patches from xserver-xorg-video-nv upstream and he clarified that the id's I was adding are for agp bridge chips and the actual device gets matched correctly at a different point in the driver
<Sarvatt> but our initialization scripts arent taking that into account so we have to force it up there to work around that
<Sarvatt> that would probably be fixed once we drop the 01_gen_pci_ids.diff like the other drivers huh
<Sarvatt> the pci id returns the result of the agp bridge chip but the id for the actual gpu is called in NVGetPCIXpressChip later on which does match exisiting ones, but our nv.ids is only pulling the gpu id's so we have to (incorrectly) add every gpu behind an agp bridge to the id's to get around that. I imagine theres a heck of alot more missing than the 2 ubuntu has patches for, yuck
<Sarvatt> well, the xf86-video-nv maintainer is saying he's a little worried we're adding agp bridge id's where we are because it would confuse the driver and cause problems. Why dont we just add all agp/pcie bridge chip id's (every agp nvidia card over 6xxx series) under an #if 0 so they get pulled into the nv.ids but dont screw things up and just drop that once gen pci ids is dropped?
<Sarvatt> there are a bunch of nvidia agp cards we're missing id's for and this is a problem I think on karmic right now because we dropped the default to vesa patch so anyone with an agp 6xxx or newer that doesnt match the only 2 agp bridge chip id's we are adding in patches is getting failsafe graphics on boot on the livecds
<Sarvatt> will submit a debdiff in a bit once i get the full list of ids, probably would have the same effect just dropping the id install though? :D
<Sarvatt> http://sarvatt.com/git/cgit.cgi/xf86-video-nv/commit/?id=8004d703d8607602a638c4030d80fdd52421516c
<Sarvatt> lol  i knew it'd happen tormod
<Sarvatt> i built a new mesa and only uploaded it to xorg-testing, opened the page to copy it over and got sucked in to something else and forgot to copy to edgers :)
<tormod> Sarvatt: yes I wondered, the mesa was several hours old ;)
<Sarvatt> well it's a weekend, pretty darn rare to see any mesa commits on weekends :)
#ubuntu-x 2009-06-14
<tjaalton> Sarvatt: let's just default to nouveau and stop worrying about nv :)
<Sarvatt> nv seems so nice and easy to use though, who really uses nouveau or nv outside of the initial install or on a livecd? :D only thing -nv is missing is 8xxx and newer IGP support right now. nouveau is kind of a pain in the butt to get going right, have to disable aiglx and make sure nvidiafb isnt loaded 
<Sarvatt> maybe i'm just blind but i'm looking at the nouveau code and it looks like it supports even less than -nv does on the mobile side, maybe thats why fedora has the 7xxx IGP patch for -nv :D
<tjaalton> the snapshot in karmic is two months old
<tjaalton> i don't think fedora uses nv at all
<tjaalton> since theis server defaults to nouveau
<tjaalton> their, even
<Sarvatt> http://patches.ubuntu.com/x/xserver-xorg-video-nv/extracted/104_geforce_6600gt_9100mg.patch  -- the 9100M G part of that *has* to be bogus, theres more places than just the pci id table you need to edit to add new IGPs
<hyperair> how very strange. i went to bathe and when i came out, my notebook screen blanked out completely
<Duke`> how do I enable KMS for intel? I have kernel 2.6.30-9. Is it still i915.modeset=1 in grub's kernel command line?
<Sarvatt> add options i915 modeset=1 to /etc/modprobe.d/i915.conf
<Duke`> ok, I tried  i915.modeset=1 but Xorg failed to start and then screen all garbled
<Duke`> ah I see, it tried to load i810 driver... :x
<Sarvatt> wow, 731MB of updates since i've turned this machine on last when 2.6.30-5.6 came out :D going to give nouveau KMS a shot now
<Duke`> ok, I still had to create an xorg.conf file and specify "intel" for the driver, because it still wanted to load i810 >_<
<Sarvatt> yuck, lost all my brightness hotkeys on this lappy too and its nvidia so not KMS's fault :D i need to build gnome-power-manager on a PPA with hal enabled again, dont get battery readings on the netbook when its disabled and dont get brightness keys on the other
<Sarvatt> http://pastebin.com/m20b737fc  -- is that how Xorg.0.log is supposed to look with a deleted xorg.conf?
<Duke`> I don't think so, because it fails :D
<Sarvatt> I mean the whole (==) Using default built-in configuration (39 lines)
<Sarvatt> going to delete mine and reboot :)
<Duke`> I think the generated conf is quite correct, it works without KMS
<Duke`> but I wonder why it still tries i810, hasn't this driver been removed?
<Sarvatt> hmm looks like i forgot to make a nouveau-kernel-source package for edgers, trying to build the old nouveau modules for a kernel with it built in :D i should drop the dep on nouveau-kernel-source from it
<Sarvatt> maybe the dkms install will fail because its already built into the kernel
<Sarvatt> so far so good, got a KMS nouveaufb at least. dkms is trying to build the modules though
<Sarvatt> have to manually define nouveau in xorg.conf because it defaults to nv and vesa, ahh
<Sarvatt> apw: everythings working great with your 2.6.30-8.9~kms2 kernel with nouveau KMS. http://sarvatt.com/downloads/nouveau-kms.txt
<Sarvatt> think i might try to start packaging up nouveau gallium now
<apw> Sarvatt, good news.  the later kms kernels don't have nouveau at the moment, its keeps colliding with upstream.  this makes it a pain to get into the same kernel.  should resolve itself onces radeon kms merges.
<apw> probablaly will make separate kernels for kms for the moment
<Sarvatt> sorry it took so long for me to get around to try it!
<Sarvatt> guess i do have some problems with it looking at the logs, everythings working fine though
<Sarvatt> think thats just from having the module on top of it being built in, rebuilding it with relaxed depends now so i can get rid of nouveau-kernel-source
<Sarvatt> thats strange Duke`.. http://sarvatt.com/downloads/Xorg.0.log.txt
<Sarvatt> looks the same at least
 * Sarvatt takes that back, just looked harder
<Sarvatt> oh i didnt pick my kernel, i thought i was in vesa it was so slow sheesh
<tjaalton> Duke`: have a logfile?
<tjaalton> it only tries i810 if intel fails
<Sarvatt> oh you silly kexec-tools..
<Sarvatt> he posted his log http://pastebin.com/m20b737fc
<Sarvatt> fbdev..
<tjaalton> that's pretty stupid :)
<tjaalton> so is there a livecd to try the nvidia kms?
<tjaalton> I'll try it on my desktop which has a GF8600GT
<Sarvatt> nope, we had some problems with the livecd scripts that we havent fixed yet.. all you need is apw's nouveau kernel+libdrm/ddx off edgers though, it wont really hurt anything to need a livecd unless you're on jaunty/windows or something :) 
<Sarvatt>  if anything you can just grab the drm from edgers (kernel and ddx are both abi 14 so you need the newer drm than karmics), and use the debian/rules get-orig-source for a git checkout of nouveau and drop the depends on linux-nouveau-source. not sure if i should upload a nouveau where it only recommends the kernel source to edgers :D
<tjaalton> hmm ok
<tjaalton> maybe I'l just upgrade to karmic once it's confirmed that the video abi won't change
<Sarvatt> at the rate 1.6 branch is going i'd be surprised if they even decide that or put out a rc1 before october :D
<tjaalton> they still have a couple of days to rc1 according to the schedule
<Sarvatt> http://lists.x.org/archives/xorg-devel/2009-May/000993.html
<tjaalton> oh, a month..
<apw> tjaalton, the nouveau kernel may be MIA right now in my ppa's am pushing an updated one to a new Nouveau specific PPA, which should be built in a couple of hours
<tjaalton> apw: ok, thanks
<Sarvatt> its impossible to figure out where stuff is going straight to ppa.launchpad.net/apw now :D
<tjaalton> looks like the radeon kms will be merged in .31
<Sarvatt> found it!
<Sarvatt> http://ppa.launchpad.net/apw/daily/ubuntu/pool/main/l/linux/
<Sarvatt> 2.6.30-8.9~kms2
<apw> no idea why that is still there :)  but that is the old one
<apw> Sarvatt, i have added titles to the ppa's now at least
<Sarvatt> oops 8.10 sorry
<apw> Sarvatt, ok the updates ATI+Intel is built in: https://edge.launchpad.net/~apw/+archive/daily
<Sarvatt> poor build machines :D
<apw> yep, giving them a workout today
<Sarvatt> oh i'll just binary copy, its going to 2 ppas
<apw> ok
<apw> Sarvatt, ok kmsnouveau is building (an update to the latest tip there) is going on in: https://edge.launchpad.net/~apw/+archive/blue
<apw> should be about 2 hours i'd guess
<Duke`> Sarvatt: we don't have the same xserver version
<Sarvatt> yeah, nor the same kernel, i915 is built in and kms the default so that might be changing things
<Sarvatt> ahhhhh ok its really really important not to install nouveau-kernel-source with the KMS kernel :D
<hyperair> Sarvatt: have you been noticing that when i915 is loaded (with KMS on), usplash disappears, and you see a black screen until X starts?
<Sarvatt> nope
<hyperair> =(
<hyperair> maybe i'm the only one then
<Sarvatt> i have it built into my kernel so its high res the whole way :D
<hyperair> blargh!
<Sarvatt> usplash doesnt work in full rez though, the throbber/progress bar doesnt display
<hyperair> wait a sec, you mean i915 built into the kernel, rather than as a module?
<Sarvatt> yeah
<hyperair> aah i see
<Duke`> resume after suspend to ram froze keyboard, mouse and video
<Duke`> with intel KMS
<Duke`> is it expected?
<Sarvatt> wouldnt surprise me on jaunty, it's pm-utils doesnt have any of the KMS hooks
<Duke`> ok
<Duke`> not really a problem for now, since I have hardware problems with power and suspend (the computer wakes up itself randomly...)
<Sarvatt> ya could just use karmic's pm-utils though, its got the hooks to not flicker when you suspend, and it removes all the video quirks in KMS mode that are probably crashing you :D
<Sarvatt> good to see gallium glxgears almost started to open a window before putting the pc into a gpu reset loop :D
<hyperair> almost huh
<Sarvatt> 9 reboots later i give up on anything outside of glxinfo
<hyperair> heheh
<hyperair> glxinfo actually worked eh
<hyperair> =p
<hyperair> reboots really drive me up the wall
<hyperair> especially those hard locks that screw up the file system enough to force a fsck
<hyperair> it takes almost 20 minutes to fsck my /home
<hyperair> ugh
<hyperair> i just sit around and fall asleep waiting
<hyperair> thank god for gdm sounds
<Sarvatt> wow.. i got 1 hour 14 minutes on my 4.5 hour battery with nouveau KMS
<Sarvatt> any problems with it tormod?
<tormod> the new kms CD works well
<Sarvatt> http://sarvatt.com/downloads/xorg-edgers-0.14kms-i386.iso
#ubuntu-x 2010-06-14
<ripps> :)
<Sarvatt> http://sarvatt.com/downloads/patches/radeon-gallium-default-off.patch
<Sarvatt> there we go, adds support for enabling using radeong_dri.so instead of r300_dri.so with an xorg.conf option, only allows it on supported ones and defaults off
<ripps> tell me when you have everything configured in th PPA. I'll gladly test
<Sarvatt> it'll be awhile before i redo mesa packaging..
<Sarvatt> want to get it to the point where i can use debian/ from git, i've got so many changes
<Sarvatt> it's almost there, just need to figure out all this egl/opengles crap for 7.9
<Sarvatt> gotta think of the best way to remove dri-gallium on upgrade
<Sarvatt> oh guess i could make libgl1-mesa-dri-experimental provide it?
<Sarvatt> hope i'm using xf86ReturnOptValBool correct in that patch
<Sarvatt> whoops, CHIP_FAMILY_R500 doesn't exist
<Sarvatt> oh why did I change that, r500 uses r300
<Sarvatt> dunno where to send the patch to
<Sarvatt> heh just noticed that wacom module had 586 in the vermagic, kind of silly the i386 kernels are still compiled for 586 when the rest of maverick went 686
<Sarvatt> going to update the man for ati and try to upstream that patch
<Sarvatt> ripps: ok uploaded ati with my patch to edgers, you'll have to move /usr/lib/dri-gallium/r300_dri.so to /usr/lib/dri/radeong_dri.so manually though for now
<Sarvatt> ripps: if you could test it sometime that'd be sweet, will send it to the lists if it works - http://sarvatt.com/downloads/patches/radeon-gallium-default-off.patch
<Sarvatt> so swrast and i915 gallium drivers are the only problems now
<Sarvatt> i915 because it has the same name as the classic mesa driver so cant go in /usr/lib/dri as is
<ripps> Sarvatt: sorry, I was out.
<Sarvatt> no worries, not in any rush :) trying to figure out mesa
<ripps> you want me to test the patch? is that patch for -radeon or mesa
<Sarvatt> radeon, it's in xorg-edgers too
<ripps> oh, well I'll just install xorg-edgers then
<Sarvatt> i just haven't uploaded a mesa with radeong_dri.so in it yet
<ripps> Is there an easy way to switch between dri1 and dri2 without rebooting (just restarting Xserver)
<Sarvatt> nope gotta disable/enable KMS
<Sarvatt> guess i could just go the easy route and throw radeong_dri.so  in libgl1-mesa-dri for now and can test by not installing libgl1-mesa-dri-gallium and using the xorg.conf option
<ripps> Sarvatt: shouldn't it be possible to reload the radeon module with a different modeset?
<Sarvatt> you can try but i'm 99% sure it's not going to work
<ripps> Actually, this seems like something switcheroo was designed for
<Sarvatt> switcheroo requires vgaarb which requires KMS I believe
<Sarvatt> uploading mesa now, can just purge libgl1-mesa-dri-gallium once its done building and try the xorg.conf option
<Sarvatt> all of this is going to change in a few weeks, sorry for the trouble while i work out how the heck to do it
<Sarvatt> radeong_dri.so is only in libgl1-mesa-dri right now because of how i build crap, once i resync with git it'll change to libgl1-mesa-dri-experimental
<ripps> switching from dri1 to dri2 worked.
<ripps> let's try the other way around
<Sarvatt> are you moving /usr/lib/dri-gallium/r300_dri.so to /usr/lib/dri/radeong_dri.so to test gallium out?
<johanbr> Xv on Nvidia doesn't seem to be in very good shape in Maverick
<johanbr> cheese says The error was 'BadMatch (invalid parameter attributes)'.
<johanbr>   (Details: serial 77 error_code 8 request_code 133 minor_code 19)
<ripps> Sarvatt: not yet, I'll do that now.
<ripps> It seems I'm unable to unload radeon module with kms, even if there is no X running. Is it because the VT's are using it?
<Sarvatt> fbcon probably
<Sarvatt> its built into the kernel now
<Sarvatt> johanbr: you can thank gtk for that one not nvidia :)
<johanbr> oh :)
<johanbr> is this related to the csd changes?
<Sarvatt> yep
<Sarvatt> if cheese worked at all for me i'd test it but it doesn't see my webcam anymore, only crashed before when the webcam was going
<johanbr> weird...
<johanbr> for what it's worth, empathy video calls also crash :)
<johanbr> but I guess cheese not seeing your webcam is probably kernel-related
<Sarvatt> probably anything using the webcam at all crashes the same way :)
<ripps> Sarvatt: that'll probably have to bring fbcon out of the kernel if Ubuntu ever wants to implement switcheroo.
<Sarvatt> johanbr: try XLIB_SKIP_ARGB_VISUALS=1 cheese in a terminal
<johanbr> yep, that works
<Sarvatt> ripps: whys that? i dont think it unloads any modules, just does some sysfs magic to power down the extra one? like i said it requires vgaarb and only works with kms last i checked
<Sarvatt> johanbr: thats the magic env variable to make everything work in maverick with this csd stuff :D
<ripps> oh, I thought it actually unloaded modules here and there.
<johanbr> Sarvatt, alright... thank you! :)
 * ripps updated wacom-dkms, uses dkms kernelver instead of uname -r
<Sarvatt> i still haven't gone inside to dig out a tablet :(
<Sarvatt> johanbr: you can probably just change it to not use Xv for the webcam in system-preferences-multimedia systems selector too
<Sarvatt> the error was in Xv for me
<johanbr> alright
<johanbr> for some reason "mplayer -vo xv" works, without setting any variables
<Sarvatt> its not displaying it in a gtk window :)
<Sarvatt> i need to figure out what package provides that multimedia systems selector because i dont have it anymore
<Sarvatt> any chance ya could tell me what the actual app is called in the shortcut?
<Sarvatt> ahh looks like its a gstreamer package
<Sarvatt> dpkg says its in gnome-media which i already had installed, installing a bunch of gstreamer stuff fixed it though..
<johanbr> is this gstreamer-properties you're talking about?
<Sarvatt> hmm, libv4l-0 is an empty package, only docs in it
<johanbr> really? seems to contain libraries for me
<johanbr> such as /usr/lib/libv4l1.so.0
<Sarvatt> oh whoops did dpkg -S libv4l-0 instead of dpkg -L
<Sarvatt> darn webcam is dead to the world
<Sarvatt> uvcvideo even stopped getting loaded
<johanbr> hw problem?
<Sarvatt> probably
<Sarvatt> it was just showing a green screen for a few months there, now its dead to the world :)
<ripps> just finished upgrading to xorg-edgers, I see radeong_dri in libgl1-mesa-dri :)
<Sarvatt> yeah remove libgl1-mesa-dri-gallium :)
<Sarvatt> (for now)
<Sarvatt> guess it doesnt matter actually, it wont use r300_dri.so from /usr/lib/dri-gallium if you have the xorg.conf option
<ripps> hmm...
<ripps> OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2
<ripps> still not gallium
<ripps> RADEON(0): [DRI2]   DRI driver: r300
<ripps> Option "Gallium" "True"
<ripps> hmm... not loading radeong_dri
<ripps> oh wait, do I have to wait for a patched xserver?
<ripps> Sarvatt: the gallium patch isn't working. Option "Gallium" "True/False" does nothing. It's still loading only r300_dri
<Sarvatt> ok so my patch is wrong, thanks for the heads up ripps :)
<ripps> the one you gave me earlier worked...
<Sarvatt> yeah its different
<Sarvatt> lessee
<Sarvatt> can you send me your log?
<Sarvatt> there should be other messages
<ripps> Sarvatt: http://pastebin.com/0HSAMZds
<Sarvatt> whats the ati version?
<Sarvatt> i havent looked if it even built
<ripps> (WW) RADEON(0): Option "Gallium" is not used
<Sarvatt> yeah looks like it failed to build?
<Sarvatt> you using ati from today?
<ripps> yes
<Sarvatt> no it built, hmm
<Sarvatt> oh dont tell me
<Sarvatt> i friggin patched it with --dry-run
<ripps> lol
<Sarvatt> new one uploading
<Sarvatt> no patch system so i just patched it manually, but i did a dry-run first to see if it applied to current ati since i made the patch on the 0604 checkout and forgot to apply it for real :(
<ripps> what? no quilt?
<ripps> I can sleep at night without my quilt
<ripps> s/can/can't
<Sarvatt> would have taken 30 seconds to add that but that was still 10x longer than just doing it by hand :)
<Sarvatt> phew though, still a chance the patch might work
<ripps> I try to keep good practices practices ;)
<ripps> s/package/practices
<ripps> okay, it's getting late, I'm constantly mistyping my words
<ripps> Holy! The -radeon in xorg-edgers fixed my XV tearing issue! That has been bugging me for ages
<Sarvatt> hasnt really been any changes that would fix that in quite some time..
<Sarvatt> sure you arent using r300g? :)
<Sarvatt> oh Xv nevermind
<Sarvatt> oh could be the xserver update
<ripps> or maybe it's because I explicitly set radeon.agpmode=8. So it's actually running at fullspeed
<ripps> Although, with my luck that'll me it'll lock my computer up in a few minutes
<Sarvatt> are you using textured video?
<ripps> Sarvatt: that's the only xv radeon kms has
<Sarvatt> new ati should be up there now
<ripps> Sarvatt: OpenGL renderer string: Gallium 0.4 on RV350
<ripps> :)
<Sarvatt> woohoo
<Sarvatt> now to figure out where to send the patch upstream to :)
<ripps> wouldn't dri-devel be a good place?
<ripps> Well, the compiz crashing issue is back.
<Sarvatt> do you have a /usr/lib/dri-gallium/r300_dri.so still?
<Sarvatt> or is it just the same dri1 problem you had before?
<ripps> Sarvatt: I don't know, but it happens whenever I open gnome-mplayer...
<ripps> I don't have a dri-gallium/
<Sarvatt> say anything in ~/.xsession-errors when it happens?
<ripps> I don't know, I already disabled gallium and restarted X
<ripps> I tried to get a backtrace, but it would always say the previous frame is identical and that the stack is corrupt
<ripps> So I'm guessing gallium is screwing something
<Sarvatt> gnome-mplayer doesnt even work here
<ripps> I've been using a wrapper with gnome-mplayer because it incorrectly uses argb with it's video window, making it translucent with the maverick gtk.
<ripps> I know compiz crashes on other programs, but gnome-mplayer is the only one I can get it to crash consistently. You think the argb stuff is what's crashing it?
<ripps> s/can/can't
<Sarvatt> you should be able to figure out why it's crashing pretty easily, just start compiz from a VT with DISPLAY=:0 compiz --replace >/path/to/log.txt 2>&1 
<Sarvatt> i mean is it taking down X or just compiz crashing?
<Sarvatt> if its just compiz it'll say why in that log
<Sarvatt> yeah xserver 1.8.99 for sure isn't ready for edgers :)
<Sarvatt> way too easy to crash this, i forgot how annoying the sigquit when you press enter deal with plymouth was too
<Sarvatt> have to press escape to get off the splash or disable splash entirely to not hang, the xserver always starts on :1
<Sarvatt> not having any luck finding any bugs with compiz on r300g that aren't already fixed, no idea whats up ripps
<Sarvatt> oh! we have a GTK_RGBA_DISABLE_APPS env variable now!
<ripps> Sarvatt: how do you use GTK_RGBA_DISABLE_APPS?
<ripps> is it like a rbga application blacklist?
<Sarvatt> yeah
<Sarvatt> http://git.gnome.org/browse/gtk+/commit/?h=client-side-decorations&id=68a12cf28c12778942690d58d7d83b86286ece52
<Sarvatt> seperate the app names with :
<cwillu_at_work> what's with the xserver-xorg-video-6 package?
<Sarvatt> anyone around that is using edgers on ati?
<Sarvatt> tormod looked over my patch and is saying he thinks the if (info->useGallium && !galliumAllowed) { hunk will still show the using gallium message if it's disabled in xorg.conf or on non R300 cards - http://sarvatt.com/downloads/patches/radeon-gallium-default-off.patch
<Sarvatt> ah yeah he's right
<Sarvatt> RAOF: we going to build mesa in origin/ubuntu against libdrm 2.4.21? want me to add the patch that makes it work if so?
<Sarvatt> RAOF: oh nevermind, I see you already added it :)
<Sarvatt> darnit, radeon doesn't work headless?
<Sarvatt> on the plus side i see my fglrx package in x-updates works fine
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1
<Sarvatt>   libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings
<Sarvatt> on a machine with maverick alpha 1+fglrx installed doing a dist-upgrade
<Sarvatt> nvidia-current..
<bjsnider> you'd have to take provides: xserver-xorg or whatever it is out of the control file
<bjsnider> Provides: ${xviddriver:Provides}
<Sarvatt> think i'm going to do that on the PPA, whenever it finally gets a rebuild in maverick it's going to have the same problem :(
<Sarvatt> aptitude why nvidia-current
<Sarvatt> i   fglrx             Depends  xserver-xorg-core                            
<Sarvatt> p   xserver-xorg-core Depends  xserver-xorg                                 
<Sarvatt> p   xserver-xorg      Depends  xserver-xorg-video-all | xserver-xorg-video-7
<Sarvatt> p   nvidia-current    Provides xserver-xorg-video-7
<Sarvatt> might as well hack around the busted modaliases too since i cant manage to fix the extraction script, will just install the old ones from the last that worked
<Sarvatt> nvidia-current packaging gives me nightmares
<Sarvatt> noticed that it ships 2 tls libs and nvidia-installer does a check to see which to use but we skip that and force everyone to use one specific one?
<Sarvatt> hopefully theres no magic in jockey checking the abi provided in nvidia or something, package built fine and i uploaded it with hardcoded modaliases and no abi
<hyperair> blargh. it seems mainline's vanilla kernel suspends fine, and i did a 12-step bisect of the kernel for nothing >_>
<Sarvatt> \o/ http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-server/xserver-1.8-no-connected-outputs.patch?view=markup
<Sarvatt> even with the abi provides dropped nvidia-current is getting offered 
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1
<Sarvatt>   libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings
<bjsnider> run the why command again
<Sarvatt> can't find a reason now
<Sarvatt> i think it might have something to do with fglrx's hard dependency on xserver-xorg-core
<Sarvatt> oh i must have screwed up the modaliases install, hmm
<Sarvatt> ah nevermind its fine
<Sarvatt> i just have the old ones cus i havent upgraded yet
<Sarvatt> fglrx-installer should be depending on xserver-xorg instead of xserver-xorg-core though..
<Sarvatt> hah, i like the 1:9-12-1 changelog entry in debian - http://packages.debian.org/changelogs/pool/non-free/f/fglrx-driver/fglrx-driver_10-5-1/changelog 
<Sarvatt> if i remove ubuntu-x-swat nvidia-current doesn't get installed, but thats only because the one in the archives breaks xserver-xorg-core
<Sarvatt> hesitant to actually upgrade so i can test out fixes but i need to test this radeon stuff on that machine :(
<Sarvatt> to make it even weirder, dropping ubuntu-x-swat and adding edgers doesn't try to install nvidia-current on dist-upgrade
<RAOF> Sarvatt: That no-connected-outputs patch is in for 1.9 I believe.
<Sarvatt> yeah found it after i fixed up the fedora one to apply :D
<Sarvatt> it works good on 1.8.1.901
<RAOF> I was just going to wait until 1.9; we're going to get that _anyway_.
#ubuntu-x 2010-06-15
<Sarvatt> lol man, I feel like an idiot
<Sarvatt> i've been trying to get that ati gallium patch working right, but every time i changed it i only installed xserver-xorg-video-ati so i wasn't even testing the new changes :)
<Sarvatt> so the little one line change works, here i was rewriting it all
<Sarvatt> yep patch looks good to go, can't seem to break it. sent it to dri-devel and xorg-devel
<m3ga> i'm trying to boot lucid on a tablet device but something during boot screws up the graphics. i've tried booting with 'single' and 'text' on the kernel command line but that doesn't help.
<m3ga> i suspect something in the kernel initialisation is tweaking something it shouldn't.
<m3ga> if i put init=/bin/bash on the command line i get a prompt and can remount the usb-key rw. but i'd like to fix this.
<m3ga> any clues on how to move forward?
<RAOF> m3ga: Try with ânomodesetâ on the kernel command line.  That'll disable kernel modesetting, which should stop the kernel touching your display hardware quite so much.
<m3ga> RAOF: bingo. I have a login prompt. thanks!
<RAOF> m3ga: What hardware is that?  Could you please file a bug?
<m3ga> its a 'hanvon B10' tablet. what package should i log a bug against?
<m3ga> nice tablet btw. 1.3G Celeron. all intel devices. pretty sure the graphics is *not* gma500.
<RAOF> Run âubuntu-bug linuxâ.  That'll file a bug against the kernel, which is the problem here.
<m3ga> cool. will do.
<m3ga> RAOF: false alarm. i was booting the karmic kernel by mistake. the lucid kernel does the right thing even without 'nomodeset'.
<Sarvatt> pretty sure its because it has an lvds without a lid so the old karmic kernel just thought there were no screens, they fixed that in .32
<m3ga> ah, that makes sense
<Sarvatt> i was writing patches for an insane amount of similar chinese knockoff intels with the same problem and was glad they changed the default.. crappy bioses :)
<m3ga> now getting a kernel message '[drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 27'
<m3ga> is that a crappy bios? :-)
<Sarvatt> can just ignore it unless things are broken?
<m3ga> ignoring for now
<m3ga> RAOF: this is the hardware : http://www.hanvon.com/en/products/touchpad/touchpad_B10.html
<Sarvatt> m3ga: can you sudo lspci -vvnn | pastebinit ?
<Sarvatt> just curious, looks like a fun toy :)
<m3ga> Sarvatt: give me half an hour or so
<Sarvatt> most likely the wufu just isnt supported yet without external drivers, vendor id 05E1 prodict id 0100 are the important parts, looking now
<bjsnider> wufu?
<Sarvatt> m3ga: the drivers are pretty nasty, overwrites policykit, disables your sources and makes you only use their mirror in taiwan, and they only have modules for karmic even though it says its for lucid
<Sarvatt> i went over the blobs in the there but it doesnt look like any wifi chipset i know about
<Sarvatt> m3ga: just google 3dsp wifi linux and see if you can find any guides, better off just replacing it with anyther card though :)
<Sarvatt> Thanks a lot for you using our products. We would like to provide source code to you! but it will be very hard to maintain and support due to its complicacy. and I believe the day we open source code will come soon.
<Sarvatt> i like that response :)
<Nafai> Hi guys :)
<Nafai> so something I upgraded in the last couple of days is causing nvidia-settings to segfault on startup
<Nafai> but even after installing the dbgsym package, the gdb backtrace may not be that useful :(
<Nafai> http://gist.github.com/438631 
<bryceh> Nafai, lynx or meerkat?
<Nafai> lynx
<bryceh> alright, couldn't even begin to guess, sorry
<bryceh> I guess, figure out what it was you upgraded and try downgrading it.  ;-)
<Nafai> :)
<Sarvatt>  nvidia-settings --no-config work?
<Nafai> Nope, same problem
<Sarvatt> http://ddebs.ubuntu.com/pool/main/n/nvidia-settings/
<Nafai> already have that installed :(
<Sarvatt> can ya grab debug packages for all of the rest of the depends too and get a bt full?
<Sarvatt> i can't reproduce on stock lucid, got any wacky gtk related ppa's enabled? :)
<Sarvatt> oh
<Sarvatt> ** (nvidia-settings:3303): CRITICAL **: menu_proxy_module_load: assertion `dbusproxy != NULL' failed
<Sarvatt> yep its gtk
<Sarvatt> iget the same segfault it looks like with geany if i have indicator-appmenu open
<Nafai> ah, that probably is it
<Nafai> I can do a ppa purge on that
<Sarvatt> nvidia-settings is open source btw if you want to figure out why - http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/
<m3ga> Sarvatt: what kind of crack must they be smoking to think that replacing the normal sources.list is acceptable?
<Sarvatt> its to stop you from upgrading away from their policykit replac...err rootkit
<m3ga> i'm currently evaluating this for the company i work for. if it works out we'd be buying them in lots of 1000
<m3ga> i'll come back to wifi after i get X working
<Sarvatt> x isnt working?
<Sarvatt> well the touchscreen most likely has problems
<Sarvatt> RAOF: i'm kind of confused by mesa/LLVM
<Sarvatt> i mean, it looks like llvm support is all or nothing
<Sarvatt> i see the llvm symbols in the libs and stuff, but llvm isn't getting pulled in as a dep?
<RAOF> Well, it certainly wanders all through the code.
<RAOF> That seems odd, unless a lot of llvm is inline or something.
<Sarvatt> not to mention it looks like enabling llvm makes the gallium stuff x86/SSE2 only so not really compatible with i686 we have going? i dunno
<RAOF> Really?  Wow.
<RAOF> Well, we could alwaysâ¦ build mesa _yet_ another time :)
<Sarvatt> i enabled llvm in edgers because it was supposed to speed up swtcl chipsets with r300g but i think i'll back that out for sure.. :D
<Sarvatt> i think i hate the nvidia-graphics-drivers build system more than mesa's and it's nothing but shuffling around files...
<superm1> Sarvatt, i thought tseliot spent a lot of time cleaning it up the last cycle
<superm1> what's janky about it now?
<Sarvatt> oh I don't know, the 53 nested variable maze in the rules is fun to maintain when they completely redo the package layout upstream :)
 * Sarvatt tries to figure out what PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE is why its busted on nouveau
<RAOF> Sarvatt: How far through the fun of forward-porting the intel 2.7 DDX to 1.9 did you get?
<Sarvatt> /usr/lib/dri-gallium totally breaks glx over ssh
<Sarvatt> good question, i dont remember
<Sarvatt> let me try to find where i was working on it
<RAOF> Because I was talking to (I think!) ickle in #intel-gfx, and he suggested that an essentially-equivalent task was to add a non-GEM codepath for the current DDX, and that he wasn't averse to participating in such an enterprise.
<Sarvatt> sheesh i've got 2663 directories in my git packaging directory, i know i was working on it in a stupid subdirectory like temp8/ or something too
<RAOF> Yay organisation! :)
<RAOF> Also, there's some more nvidia-graphics-drivers goodness in the xorg apport script now, attempting to detect manually-installed nvidia drivers and grabbing the appropriate logs for forwarding them upstream.  Feel free to suggest improvements.
<Sarvatt> why not just make it run nvidia-bug-report and attach those logs? :)
<RAOF> Because nvidia-bug-report is a little bit evil.  Particularly - it'll always dump the log in the current directory, whatever that might be.  Also, it's less easy to get at the data in nvidia-bug-report.log.gz
<Sarvatt> i can't find anything, guess I didn't do more than 2.8.0 :(
<Sarvatt> or i trashed it already
<Sarvatt> ah i remember now, i was going through the list then i found http://cgit.freedesktop.org/~airlied/xf86-video-intel/ and got caught up messing with that
<RAOF> Is that a 2.2 DDX + patches?
<Sarvatt> yeah from RHEL, backported a crapload of kernel changes for new hardware to UMS
<Sarvatt> i got kind of discouraged about 2.7.1 because I remembered that was the peak of intel driver crappiness :)
<bryceh> peak?
<Sarvatt> yeah jaunty!
<Sarvatt> i mean both EXA and UXA completely blew and it wasn't hardly usable
<bryceh> yep
<RAOF> I don't think I _had_ an intel graphics card for Jaunty.
<Sarvatt> oh jaunty was 2.6
<Sarvatt> http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-14462-8152-19051
<bryceh> right, 2.6.  *shudder*
<RAOF> Right.  Let's crash i965_dri.so and see if I can't get a better backtrace this timeâ¦
<RAOF> Gah.  Alternatively, it could be a bug that only appears when not built with -O0
<bryceh> Sarvatt, mm - http://people.ubuntu.com/~fta/ppa-dashboard/ubuntu-mozilla-daily--ppa.html
<Sarvatt> oh he's been changing that, looked different last i saw it
<Sarvatt> oo he released the source! https://code.edge.launchpad.net/~fta/+junk/ppa-dashboard.trunk
<RAOF> So, gaussian blur on a GM45 does not provide the world's most responsive desktop environment.
<hyperair> 965 doesn't like it either
<Sarvatt> i dont even like any blur with ambiance/radiance RGBA
<hyperair> rather, it doesn't like any kind of blurring.
<RAOF> So, now lets see if using the version built with -O2 segfaults.
<Sarvatt> python-launchpadlib in jaunty doesn't support anonymous login :(
<Sarvatt> http://sarvatt.com/dashboard/
<bryceh> Sarvatt, jaunty?
<bryceh> Sarvatt, might be a newer version in a ppa
<Sarvatt> yeah latest ubuntu I can run on my VPS since upstart doesn't work in openvz
<bryceh> oh bummer
<bryceh> yay lp #589811 is fixed
<ubot4> Launchpad bug 589811 in xorg-server (Ubuntu Maverick) (and 2 other projects) "My email address is in Xorg.0.log so users email me directly for support (affects: 1) (heat: 281)" [High,Fix released] https://launchpad.net/bugs/589811
<Sarvatt> lol
<Sarvatt> i dont even see email that isn't labeled anymore because i've got so much like that, got too trigger happy subscribing to bugs for awhile there too :)
<Sarvatt> dont think i'll get around to refreshing the lcdfilter patch in cairo, 13 hunks failed
<RAOF> Isn't it 1am or somesuch ungodly time where you are?
<Sarvatt> and it doesn't build with gcc-4.5 apparently, boo!
<Sarvatt> 4:31
<Sarvatt> :)
<Sarvatt> debian isn't packaging cairo-perf with this, think i'll add that
<Sarvatt> people are going to complain if i upload cairo without the lcdfilter patch though :(
<Sarvatt> maybe not so much since firefox bundles cairo
<seb128> our firefox bundles the lcdfilter patch though
<seb128> we got lot of complain when we didn't have it
<Sarvatt> yeah thats what I mean, wont be that big a deal since crappy firefox was the big complaint :)
<seb128> lol
<Sarvatt> what was the trick you guys use to regenerate 99_autoreconf.patch?
<hyperair> autoreconf -vfi?
 * hyperair doesn't like autoreconf patches, they're bulky.
<Sarvatt> yeah same here, just all the darn desktop packages use it. i found it in an old log, cdbs-edit-patch
<seb128> Sarvatt, cdbs-edit-patch 99_autoreconf.patch
<seb128> autoreconf
<seb128> rm -r autom4te.cache
<seb128> exit
<seb128> Sarvatt, we are moving to run autoreconf in the rules this cycle
<Sarvatt> so source format 3 packages get their patches applied at source extraction time? this build kept failing because git checkouts don't work since they weren't applying the patches, plus the clean rule completely doesn't actually clean it
<Sarvatt> clean rule does         rm -f *-stamp, stamps are *-stamp-*
<Sarvatt> ok no lcdfilter patch is not an option, this is horrible :)
<maxb> Sarvatt: The (slightly odd to me) convention that bzr-builddeb is encouraging is to keep the *patched* source package under version control
<Sarvatt> oh joy...
<tseliot> Sarvatt: have you tested nvidia 195 with kernel 2.6.35? (note I haven't had the time to test and rebuild the driver yet)
<Sarvatt> no, i've only tested 256.29 but people are saying 195.24 works with a no change rebuild against the new server. i've noticed a bug where nvidia-current was getting installed on non nvidia with a dist-upgrade once it's providing xserver-xorg-video-7 though, i think the only reason it's not happening to people now is because xserver-xorg-core breaks nvidia-current
<Sarvatt> i dropped the provides in x-updates
<tseliot> Sarvatt: I fail to see why that would happen
<Sarvatt> it's easy to test, boot an alpha 1 livecd and sudo apt-get update && sudo apt-get dist-upgrade on non nvidia once it's rebuilt in the archives and it'll offer nvidia-current
<Sarvatt> i cant figure it out either
<Sarvatt> been trying to for weeks
<Sarvatt> it happened when i moved xorg-edgers to 1.8 too
<tseliot> I'll have to check the xserver package then
<Sarvatt> when it's rebuilt i'll boot the livecd and do a simulated install and try to figure it out some more
<Sarvatt> also nvidia_supported no longer works with nvidia-256, i had to hardcode the modaliases from the last working one :(
<tseliot> Sarvatt: another thing: do you know if we have this patch in Maverick? http://bugs.freedesktop.org/attachment.cgi?id=35383
<tseliot> I'll rework nvidia_supported too, as soon as I have some time to look at the nvidia package
<Sarvatt> yes we do
<Sarvatt> there's an ordering issue somewhere screwing up nvidia-current but i am completely stumped about it
<tseliot> ordering issue?
<Sarvatt> yeah the order its trying to resolve packages with dist-upgrade is wacky with xserver-xorg-core having breaks on the old abi's
<tseliot> aah, ok
<Sarvatt> if you have a machine that hasn't updated to xserver 1.8 yet, you can add the x-updates ppa and try a dist-upgrade and see what it offers to see what i'm talking about
<Sarvatt> i just went through it all again yesterday but i guess ya weren't in the channel
<Sarvatt> <Sarvatt> The following NEW packages will be installed:
<Sarvatt> <Sarvatt>   baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1
<Sarvatt> <Sarvatt>   libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings
<Sarvatt> thats on a fresh install of alpha 1 with fglrx installed doing a dist-upgrade
<tseliot> that definitely doesn't look good
<Sarvatt> with x-updates enabled
<Sarvatt> with edgers I pinned it down to xserver-xorg-video-nv being screwed up and if i purged that it stopped trying to offer nvidia-current
<tseliot> how did xserver-xorg-video-nv cause the system to install nvidia-current?
<tseliot> shouldn't it be replaced by nouveau instead?
<tseliot> note: I haven't installed maverick or created any maverick chroot yet
<Sarvatt> hmm
<Sarvatt> i wonder if its because xserver-xorg-video-nv provides xf86-video-driver-riva128 and it thinks that has video abi 6 early in the dependency resolution
<Sarvatt> thats the only thing i can think of, kees had a similar problem earlier where he couldn't upgrade xserver-xorg-core because it thought something was providing xserver-xorg-video-6 still until he purged -nv
<Sarvatt> if you dist upgrade while something provides video-6 the first thing it does is try to remove video-all
<Sarvatt> so xserver-xorg-video-all | xserver-xorg-video-7 can get fulfilled for xserver-xorg
<Sarvatt> i bet thats it actually, i'll test it out today
<tseliot> good, let me know how it goes
<ripps> I'm having trouble using my webcam with any gstreamer based client
<ripps> I have a backtrace, would the fact I'm using xorg-edgers interfere?
<johanbr> ripps, there are apparently xv issues with recent gtk
<johanbr> you can try launching cheese with "XLIB_SKIP_ARGB_VISUALS=1 cheese"
<ripps> johanbr: ah that works. I've got a ton of wrappers for that in my bin/. There needs to be a better way to handle the argb incompatibilities
<johanbr> I'm sure people are working on it
<ripps> I guess I'll create some wrappers for cheese and empathy
<ripps> woot! looks like wacom-dkms successfully worked when upgrading kernel.
<ripps> Let's reboot and see if it really worked.
<ripps> lol, it looks like rbga is being disabled again for gtk
<Sarvatt> kinda funny, I was actually enjoying RGBA themes now :) don't understand why they weren't enabled by default though, the only thing we got from all that seemed to be crashes?
 * Ng wonders if there is any visibility of issues relating to USB input devices locking up
<Ng> I've not seen it myself, but someone mentioned it to me in context of http://ubuntuforums.org/showthread.php?t=1497247
<Sarvatt> Ng: you're evil, i actually read that.. :)
<Ng> how is that evil?
<Ng> I never go to the forums other than when people are talking about issues to me
<Sarvatt> it's scary how much bad info is contained in one thread
<Sarvatt> "my mouse doesn't work" "reinstall nvidia" "intel 8xx is broken change to vesa fix your mouse"
<Sarvatt> noone even gave any details of their hardware :)
<Sarvatt> like is it locking up after suspend, or after multiple plug ins or anything?
<Sarvatt> its almost guaranteed the problem will be in dmesg when it happens
<Sarvatt> Ng: did that flickering screen problem ever get fixed?
<seb128> Sarvatt, "the only thing we got from all that seemed to be crashes?"
<seb128> Sarvatt, we needed to land the change to know about those
<seb128> Sarvatt, we also allow other teams to pick up and land themes etc 
<Ng> Sarvatt: I don't think so, but I've not been paying lots of attention to it
<Sarvatt> oh, I mean the CSD/RGBA stuff was completely transparent to me from a user's perspective, the only thing I noticed with it enabled was the crashes until I found out I could manually enable RGBA in the theme 
<Sarvatt> i think less people would be complaining if they could actually see it in action :)
<Sarvatt> because it shut me up from complaining once i did
<seb128> right
<seb128> well we need both, we need to know about issues and we need to get it used
<seb128> seems to design team doesn't have a theme ready to use yet
<seb128> and we collected technical issues we needed to know about now
<seb128> so we turn it off until we have time to work on those
<seb128> it's likely going to be back on after alpha2
<Sarvatt> i've been using ambiance with rgba and it looks great
 * Sarvatt nods
<Ng> Sarvatt: I'll see if I can get the affected person to check dmesg when it happens and file a bug
<seb128> in practice bratsche does our gtk work and is busy on the appmenu work now
<Sarvatt> poke me if you can, I'll help :)
<seb128> that should land in alpha2 for UNE
<seb128> once that's working he will be back on rgba work
<seb128> then we will enable it again
<seb128> we don't win anything out of crashes right now
<Sarvatt> cairo 1.9.8 checks out good on R600 at least - http://sarvatt.com/downloads/cairo/tests/
<Sarvatt> couldn't run the pdf tests because they need poppler >= 13.2
<Sarvatt> apw: do you know if 586 is going to continue being the default target for the i386 kernel in maverick?
<Sarvatt> i imagine our binutils/gcc using i686 are already making userspace incompatible with the few processors that 586 supports that 686 doesn't
<apw> Sarvatt, i would have thought so
<apw> if it hasn't already of course
<ripps> what exactly is the reason for the switch to i686?
<apw> ripps, as i understand it its time for a clean break so we can take advantage of the newer features
<ripps> apw: what kind of features?
<apw> ripps, we are optimising for h/w that is almost non-existant, the majority case is i686 and above... they are paying a penaltiy for a very very few systems
<apw> and as those systems are very old already and can stay on lucid for 3 years, now was deemed the time to make a change if we were
<apw> but as for the politics, it was not my decision, nor was i present when it was made
<Sarvatt> i for one am super happy about the change :)
<geser> RAOF: do you know if moving glx.h from /usr/include/GL/glx.h to /usr/include/glx.h in maverick was intended? this seems to break some other software which checks for GL/glx.h
<jcristau> sounds like a bug
<geser> then the last mesa upload broke it
<geser> mesa 7.8.1-1ubuntu has it installed in /usr/include/GL/glx.h, the same 7.8.1-2 from Debian experimental but 7.8.1-3ubuntu1 in maverick installs it now in /usr/include/glx.h
<Sarvatt> argh
<Sarvatt> http://sarvatt.com/downloads/mesa-modified-third.txt
<Sarvatt> indeed it does
<Sarvatt> want to yell at me yet jcristau? :)
<jcristau> not unless you insist
<jcristau> shit happens
<Sarvatt> hmm, maybe that wasnt the most recent file list
<Sarvatt> dri.pc is screwed up in origin/ubuntu too
<geser> looks like the changes to mesa-common-dev.install dropped the GL directory:
<geser> -usr/include/GL/gl.h
<geser> +dri/usr/include/GL/gl.h usr/include
<geser> and so on for the other files
<Sarvatt> yeah that should be dri/usr/include/GL/gl.h usr/include/GL :(
<Sarvatt> the merge was all screwed up, didnt fix up the new locations
<Sarvatt> yay more mesa test builds incoming :)
<Sarvatt> ugh, yeah I see why, there was something strange with the build in that other things from debian/tmp/dri needed the extra path in the .install but mesa-common-dev was the exception
<Sarvatt> dri/usr/include/EGL usr/include works for libegl1-mesa-dev but mesa-common-dev needs dri/usr/include/GL/gl.h usr/include/GL
<Sarvatt> adding dri/usr/include/EGL usr/include/EGL to libegl1-mesa-dev made it install to usr/include/EGL/EGL
<Sarvatt> test building to be sure and will fix up the ubuntu branch's bad merge after if noone else gets them :D
<shadeslayer> Sarvatt: bug 594863 regarding the above issue
<ubot4> Launchpad bug 594863 in mesa (Ubuntu) "glx.h moved, causes FTBFS in other packages (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/594863
<Sarvatt> it'll be fixed soon if you didn't read the scrollback :)
<Sarvatt> there's a lot more messed up in the ubuntu package than just glx.h
<RAOF> Gah!
<bryceh> good morning raof
<RAOF> bryceh: Good morning
 * RAOF adds âtest that things can build against itâ to the set of pre-mesa upload checks.
<Sarvatt> did you even merge anything?
<Sarvatt> it doesnt look like you did, weird
<jcristau> i try to debdiff against the previous changes file usually.  but sometimes i don't have that, and sometimes i miss stuff
<RAOF> I use git for that; I diff against debian-experimental and origin/ubuntu.
<Sarvatt> how did you merge?
<RAOF> With git.
<RAOF> You wouldn't have seen it, because I didn't push until just then.
<RAOF> I'll be back in ~15 minutes.  Need to shift to to my brother's house which _isn't_ being rewired today.
<Sarvatt> i mean what commands did you use? whatever you did didn't actually go through?
<Sarvatt> oh ok
<Sarvatt> http://sarvatt.com/downloads/files-five.txt
<Sarvatt> looks right to me
#ubuntu-x 2010-06-16
<Sarvatt> so it was just one little change and git wasnt updated, phew
<Sarvatt> thats test building now so i can look at the package contents
<Sarvatt> hurry up mesa!
<RAOF> Sarvatt: Have you re-pulled mesa and found my merge?
<Sarvatt> yep and fixed it, its just almost done building, i want to make absolutely sure every file is correct :)
<RAOF> It all _looked_ right to me :/
<Sarvatt> RAOF: wasn't your fault, i thought it was more screwed up than it was because you forgot to push :)
<RAOF> Right.
<RAOF> It would have looked like a half-baked 7.8.1-2
<Sarvatt> was my fault for putting the header in the wrong place when i redid the dri build locations, that hadn't been uploaded to debian yet so its all ok
<Sarvatt> we should probably explicitly disable some gallium stuff wasting time getting built, like svga
<RAOF> That's the only thing wasting time, isn't it?  It doesn't take long, and it'd be annoying to maintain another GALLIUM_DISABLED variable :)
<Sarvatt> yeah true :)
<Sarvatt> swrastg
<RAOF> Isn't built?
<RAOF> At least, there 'aint no swrastg_dri.so generated.
<Sarvatt> oh
<Sarvatt> no point enabling radeon and intel if we arent shipping it?
<RAOF> We are shipping it - in egl.
<RAOF> That's also why we're enabling gallium swrast.  It doesn't generate a DRI driver, but it does generate an EGL swrast.
<Sarvatt> ah ok, i was thinking it'd need the dri driver too to be usable for some reason
<Sarvatt> its running make install now, 2 minutes tops
<bjsnider> about how long is it supposed to take do install 25 or so updates after they've been downloaded?
<Sarvatt> debian/libgl1-mesa-glx.prerm  is bogus
<Sarvatt>   update-alternatives --remove gl_conf /usr/lib/GL/ld.so.conf
<Sarvatt> http://sarvatt.com/downloads/files-six.txt
<Sarvatt> file list
<Sarvatt> ok pushed to origin/ubuntu
<RAOF> You know, cairo has an openvg backend.  That might be interesting to play with on a lazy weekend.
<Sarvatt> yeah I fixed that silly problem with the one header rule in that build, debdiff coming up
<RAOF> One header rule?
<Sarvatt> http://sarvatt.com/downloads/merges/mesa/ -- needs sponsor! :)
<Sarvatt> yeah silly mistake
<Sarvatt> drwxr-xr-x root/root         0 2010-06-15 16:18 ./usr/include/Gl/
<Sarvatt> -rw-r--r-- root/root      3463 2010-06-15 16:18 ./usr/include/Gl/glx_mangle.h
<Sarvatt> Gl :)
<Sarvatt> geser: can you sponsor by any chance?
<Sarvatt> http://sarvatt.com/downloads/files-seven.txt is the file list for this one
<Sarvatt> need to figure out how to transition -gallium to -experimental
<Sarvatt> ppa-purge with -gallium installed leaves it installed and will conflict with -experimental
<Sarvatt> RAOF: I thought you fixed up nvidia-current and got it uploaded?
<RAOF> Sarvatt: I did.
<Sarvatt> oh, weird
<Sarvatt> this is a lot nastier than I expected, there was a *huge* debian sync just now and some of the packages that check for GL might have just disabled supported and built anyway :(
<RAOF> :(
<RAOF> That should be fairly easy to check for, though.
<RAOF> Thanks for cleaning this up!
<Sarvatt> quite a few packages all failed with this - 
<Sarvatt> CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
<Sarvatt>   Could NOT find FLTK (missing: FLTK_INCLUDE_DIR)
<Sarvatt> i dont have much more time until i pass out, stopping going through every build to see if its got undefined behavior from no GL and just started checking ftbs
<Sarvatt> so much for fixing up cairo today :(
<Sarvatt> \o/ almost done
<Sarvatt> chrome/chromium do not like cairo 1.9.8 :(
<RAOF> Man, everyone and their dog have a personal cairo branch!
<bjsnider> will the blob build on the .34 kernel yet?
<RAOF> You mean nvidia-current?  Yes.  It's even installable!
<Sarvatt> it works fine on .35 too..
<Sarvatt> 195.24 even
<Sarvatt> RAOF: see any freetype lcdfilter patches in any of them?
<RAOF> Nope, but I was only after master anyway.
<Sarvatt> debian experimental works with no changes if you dont pull from git :)
<Sarvatt> but i had glew problems enabling gl, should be fixed in git
<RAOF> Yup, it is.
<Sarvatt> got the lcdfilter patch refresh
<Sarvatt> ed
<Sarvatt> kinda, need to clean up some fuzz
<Sarvatt> editing patches by hand sucks :)
<Sarvatt> hmm the ubuntu patch in 1.8.10  is actually drastically different than what I was working with
<Sarvatt> yeah scratch the one i was working on, i'll go with the firefox patch :)
<RAOF> :)
<Sarvatt> cairo-perf has some limitations on where it works i didnt know about
<RAOF> Such as?
<seb128> does anybody knows about "unclutter" there or has an opinion on it?
<seb128> Description: hides the cursor in X after a period of inactivity
<seb128> isn't that something xorg should be doing by itself ideally?
<jcristau> no
<seb128> context is bug #16492
<ubot4> Launchpad bug 16492 in gtk+2.0 (Ubuntu Maverick) (and 3 other projects) "Mouse pointer should disappear when keyboard is in use and mouse isn't (affects: 19) (heat: 113)" [High,Triaged] https://launchpad.net/bugs/16492
<seb128> sabdfl asked to review using unclutter in the default installation
<seb128> jcristau, why not?
<jcristau> comment 3 on that bug
<seb128> ok, fair enough
<seb128> so back to the first question, does anybody has an opinion on "unclutter"?
 * jcristau doesn't
<tseliot> I'm starting to think
<tseliot> that it's not such a bad idea
<tseliot> to use unclutter, that is
<tseliot> seb128: do you need a code review or what?
<seb128> tseliot, code review, comments from somebody who has an opinion about what it's doing
<seb128> RAOF, hey
<RAOF> seb128: Ho
 * RAOF missed the start of this discussion
<seb128> bug #16492
<ubot4> Launchpad bug 16492 in gtk+2.0 (Ubuntu Maverick) (and 3 other projects) "Mouse pointer should disappear when keyboard is in use and mouse isn't (affects: 19) (heat: 113)" [High,Triaged] https://launchpad.net/bugs/16492
<seb128> sabdfl asked us to evaluate using "unclutter" in the default installation
<tseliot> RAOF: BTW I uploaded X in lucid-proposed yesterday and cjwatson has just approved it (LP: #563100)
<seb128> I'm trying to gather opinions on it
<RAOF> tseliot: Ah, thanks.  I'll merge your changes into the ubuntu-lucid branch in git.
<tseliot> RAOF: sounds good. Thanks
<tseliot> RAOF: we're going to use xserver 1.8 (not 1.9) in Maverick, right?
<tseliot> seb128: after a quick look at unclutter, the code seems fine even though I'm not used to that coding style
<RAOF> tseliot: We're planning on 1.9 for Maverick
<tseliot> RAOF: ah, good
<RAOF> And mesa 7.9, but that's probably less interesting on the binary driver front :)
<tseliot> yes, that is why I was asking
<RAOF> I sent a mail to the Ubuntu & Debian X lists with an outline of what we'd planned.  It's also on the âGeneral X plansâ blueprint.
<tseliot> I'll have a look at it then, thanks
<tseliot> note: I'm doing more work on open drivers for oem work than on proprietary drivers and it's good to know that we'll have mesa 7.9 :-)
<RAOF> Yay!  Source code!  Decypherable backtraces!
<RAOF> :)
 * tseliot nods
<seb128> tseliot, ok, thanks for the review
<tseliot> np
<RAOF> Of course, now that I've got gdb attached X refuses to segfault.
<tseliot> it makes sense ;)
<helo> upgrading to xorg 1.7.6-2ubuntu7.1 last night is giving me persistent "out of range" errors on my monitor, regardless of whether i use nvidia, nv, or vesa driver
<bjsnider> RAOF, that exact thing happened while i was trying to backtrace gnome-shell. it still crashes when i don't have gdb running.
<Sarvatt> argh
<Sarvatt> dpkg-source: info: using source format `3.0 (quilt)'
<Sarvatt> dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override)
<Sarvatt> hope that doesn't screw up the orig.tar.gz
<Sarvatt> that was when doing debuild -S -sa
<cnd> bryceh: do you know if I build X from git will it run on maverick?
<cnd> I'm interested in knowing if X will work at all, or if it would need patches from our package
<Sarvatt> wonder if i should update cairo on lucid edgers too
<Sarvatt> RAOF: I refreshed the lcdfilter patch btw - http://sarvatt.com/downloads/patches/0001-Refresh-lcdfilter-patch-so-it-applies-to-1.9.8.patch
<bryceh> cnd, should run fine
<bryceh> cnd, Sarvatt actually has the best handle on peculiarities of the upstream git trees
<jg> Sarvatt, RAOF: could I ask one of you to spin me something to try for https://bugs.freedesktop.org/show_bug.cgi?id=28070 (launchpad bug 585651)? The patch has converged to a very small one, and I have a new disk I can try installing onto....
<ubot4> Launchpad bug 585651 in linux (Ubuntu) (and 1 other project) "Cannot install on eDP laptops such as HP Elitebook 2540p or 8440p (affects: 4) (heat: 149)" [High,Confirmed] https://launchpad.net/bugs/585651
<bryceh> cnd, but RAOF and him have landed in maverick pretty much all the pre-reqs needed for the building the latest bits
<ubot4> Freedesktop bug 28070 in Driver/intel "[Arrandale] No output (black) on eDP" [Major,New]
<Sarvatt> jg: no I can't because I need a kernel deb to make you a new livecd, I'm sorry :(
<Sarvatt> cnd: xserver 1.9 will be in edgers in a day or two, if you want to use it now you can add xorg-edgers and then also add my xorg-testing PPA
<Sarvatt> cnd: add both xorg-edgers and https://launchpad.net/~sarvatt/+archive/xorg-testing
<Sarvatt> cnd: plymouth/gdm hate it when the server doesn't support -nr, just a heads up :)
<jg> Sarvatt: If I can generate a kernel deb for you??  I can borrow my daughter's machine, and build it there....
<jg> Sarvatt: or can I put things on flash, and add the kernel deb myself?
<Sarvatt> yeah then I can, making the debs right for ubuntu is pretty tricky though, make deb or make-kpkg wont work with a livecd as it is, you need to adapt the ubuntu kernel build system
<Sarvatt> yeah if you have persistant storage you can just update it there
<jg> Sarvatt: luckily I just bought myself a 4 gig usb key...
<Sarvatt> if drm-intel-next worked i could just use that deb but the people on the bug report say it doesnt
<jg> yeah, I know.  I'm screwed...
<jg> the bug is still being chased by the intel developer.
<Sarvatt> drm-intel-next kernels are available here - http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
<jg> the next time I see keithp I'm going to rib him about this...
<jg> Sarvatt: I'll try the build my own and update a usb key method tomorrow, and see what happens.
<jg> Sarvatt: hmmm... I may have put 32bit Lucid on my kids machine; I need to run 64 bit on my new toy.  Will that get me into trouble building the kernel?
<Sarvatt> yeah, lots :(
<jg> ugh...
<jg> And this machine is running 32 bit, so upgrading it won't have the effect I want....
<Sarvatt> can just use a 32 bit livecd for the testing
<jg> true, but that doesn't get me a machine to carry with me to California next week, sparing me lugging two machines on the plane...
<Sarvatt> if you can convince someone to pull it into drm-intel-next by then that'll work :)
<Sarvatt> i can make ya a livecd with that kernel you can install from
<Sarvatt> jg: which patch do you want to try specifically?
<jg> heh... I can nudge the Intel guy to see if he's figured out why drm-intel-next doesn't work, despite Ajax's similar patch being upstream.
<Sarvatt> need to see if it applies to the most recent lucid kernel
<jg> https://bugs.freedesktop.org/show_bug.cgi?id=28070#c21 seems to be what the doctor ordered, until ykzhao figures out what's wrong with drm-next.
<ubot4> Freedesktop bug 28070 in Driver/intel "[Arrandale] No output (black) on eDP" [Major,New]
<Sarvatt> yeah but there are a bunch of patches in that bug
<Sarvatt> someone was saying either one worked, not sure which you want to try or if you want to try both
<jg> Sarvatt: this started as two patches; one of them sets the refresh speed to max, hardly desirable.  The other is the fix in c21.  The new mystery is why drm-next was having trouble.  I nudged ykzhao in case he's made progress (I think he's in China), and I can't set up to do anything before the morning, anyway.
<Sarvatt> apw: is there any chance you might be willing to build a lucid kernel with http://bugs.freedesktop.org/attachment.cgi?id=35782 applied for possibly including in lucid regarding bug #585651 ?
<ubot4> Launchpad bug 585651 in linux (Ubuntu) (and 1 other project) "Cannot install on eDP laptops such as HP Elitebook 2540p or 8440p (affects: 4) (heat: 149)" [High,Confirmed] https://launchpad.net/bugs/585651
#ubuntu-x 2010-06-17
<Sarvatt> cnd: also you'll need to no change rebuild your video driver, xorg-edgers has newer versions than in the xorg-testing one
<m3ga> i have an un-recognised usb device that according to lsusb -v is a mouse. how do i get X to use it?
<RAOF> You need to get the kernel to present it as an input device; once that's happened, the evdev X driver will pick it up.
<m3ga> there's not shortcut for testing? its a touchscreen device btw
<RAOF> I _think_ you'll need to get the kernel to recognise it before anything interesting will happen.
<m3ga> RAOF: Xorg.0.log is here http://pastebin.org/336855 . avago mouse is detected, but i get not pointer on screen and no mouse like behaviour when i touch the screen (this is a touchscreen device)
<RAOF> Hm.  That looks like it's getting picked up by X correctly.  I'm not sure what the problem is - I've not got much experience with touchscreens.
<m3ga> most touchscreens don't pretend to be a mouse device.
<RAOF> I'm not sure how true that is; from what I can remember, bryceh's touchscreen used kernel uinput + the evdev driver.
<ScottK> It looks to me like GL headers moved from /usr/include/GL to /usr/include/ (e.g. /usr/include/GL/gl.h is now found in /usr/include/gl.h)
<ScottK> Was that on purpose?
<RAOF> ScottK: Not on purpose, and fixed in 7.8.1-3ubuntu2
<ScottK> RAOF: Thanks.
<ScottK> I'll update and try again.
<ScottK> RAOF: Thanks again.  Updating solved the problem.  Way easier than hand editing includes in libqt4-opengl-dev to make a test build work.
<Sarvatt> jcristau: any reason we dont enable composite support in xdpyinfo? just needs a libxcomposite-dev build dep to enable it
<Sarvatt> menus dont work in any of the x apps :(
<jcristau> Sarvatt: go ahead and add it
<Sarvatt> dang, digging through the chrome source leads to some interesting finds, they have a glx and gles rendering backends in the works and a ton of switches http://src.chromium.org/svn/trunk/src/chrome/common/chrome_switches.cc
<Sarvatt> --enable-accelerated-compositing looks interesting :)
<RAOF> gles?  Not openvg?
<tseliot> Sarvatt: what's missing in the nvidia package in x-updates?
<Sarvatt> tseliot: nvidia_supported doesn't work anymore so i hardcoded the modaliases from the last one that worked, the headers all go in /usr/include/nvida-current/whatever so nothing can find them, and the 32 bit compat install is installing all libs instead of just specific ones
<Sarvatt>  dh_install -p$(PKG_driver)  "$(dirname_x86)/*.so*"  "$(PKG_libdir32)" is wrong in it, all .so's are in $(dirname_x86) toplevel now
<Sarvatt> it's probably installing links it doesn't need to too
<tseliot> Sarvatt: as regards the headers, we cannot let each nvidia driver install the same headers in the same place
<Sarvatt> can't just make the directory an alternative either, ah well
<tseliot> right
<Sarvatt> by can't I mean please please please please please don't of course :)
<tseliot> things such as openCL headers should be packaged separately
<tseliot> as they're not specific to nvidia
<Sarvatt> i think you're the only one that can follow the nvidia packaging these days :)
<tseliot> heh
<tseliot> unfortunately ;)
<Sarvatt> i get so lost keeping track which of the 50+ variables in the rules to use in all of the .in's
<tseliot> those variables make sure that we don't have to update each file manually but of course you have to see what they stand for
<tseliot> the work that you did on the package was a big help, I hope to complete it soon
<Sarvatt> what do you think about moving libGL back to /usr/lib? I have nvidia-current, nvidia-173 and mesa all in there with the libGL.so.1 symlink the only thing conflicting. can we just have every package providing it set up an alternative with different priorities?
<Sarvatt> just trying to figure out how to get rid of some of the complexity in the packaging, and drivers direct from the manufacturers would work again :)
<tseliot> yes, that would be fine. libGL.so.1 can be made a slave link of the alternative, I guess
<tseliot> well, "work again" after some effort would be more realistic ;)
<Sarvatt> oh, forgot to ask, but this is bogus isnt it? - update-alternatives --remove gl_conf /usr/lib/GL/ld.so.conf
<Sarvatt> it's in the mesa prerm's
<Sarvatt> there's no /usr/lib/GL
<Sarvatt> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/libgl1-mesa-swx11.prerm;h=36830024245fe6255621ed9be2099f57f01b6b82;hb=refs/heads/ubuntu
<tseliot> no, it's not bogus, it simply tells it to remove the alternative
<tseliot> I think that should be /usr/lib/mesa/ld.so.conf though
<tseliot> I'll check that later
<Sarvatt> yeah thats why I was confused
 * tseliot -> lunch
<Sarvatt> i think we used /usr/lib/GL when you first started doing it
<tseliot> that's likely
<tseliot> bbl
<Sarvatt> see ya
<Kangarooo> Sarvatt: ive put more xcrashes :) https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/587710
<Kangarooo> theres 2 post now with them maybe somwthing new comes up
<Sarvatt> darn, sysprof swears every debug file has a wrong crc, and the 8 I've checked so far are all fine
<Sarvatt> anyone using an up to date edgers that has chromium or chrome installed?
<Sarvatt> i just want to know if opening like 20 or so tabs makes them disappear
<Kangarooo> Sarvatt: will x4500 hdtv interl work on ubuntu?
<Kangarooo>  intel
<Sarvatt> yep it will
<Sarvatt> (famous last words)
<Sarvatt> wow freetype's build system is crazy
<Kangarooo> Sarvatt: did u checked https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/587710 ? i have there added 2 times 5 crashes total 10 and nothing new in ppa. im now looking for new comp. sad that i need to also check if drivers will work since something not right with even more videos since i understand they are beeing removed.. ?
<Sarvatt> your system is just plain messed up Kangarooo, both nvidia and nouveau are crashing the same way
<Sarvatt> argh, darn docbook/sgml stuff!
<Sarvatt> docbook-to-man /opt/source/freetype-2.3.12/debian/freetype-config.man.sgml > /opt/source/freetype-2.3.12/debian/freetype-config.man
<Sarvatt> /usr/bin/nsgmls:/usr/share/sgml/docbook/dtd/4.1/dbcent.mod:53:65:W: cannot generate system identifier for public text "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN"
 * Sarvatt has no idea how to fix that, i have it as far back as 4.2 but no 4.1
<Sarvatt> it's cursing me, couldn't get xorg-docs building a few days ago either :)
<Ng> Sarvatt: istr you asked me if I still see the flickering on intel - yes, it was happening earlier
#ubuntu-x 2010-06-18
<Sarvatt> these weekly binutils really are killer, now linux-tools-2.6.35-4 needs a rebuild and it was just uploaded
<jcristau> why do people keep linking dynamically against libbfd?
<Sarvatt> thats a really good question
<RAOF> Stupid X.  Build faster!
<jg> RAOF: autotools is a big part of the compile time.
<jg> imake was much faster indeed.  Unfortunately, no one maintained/improved it for aeons, and the number of people who could deal with imake had gone down to a few handful of people over the years.
<jg> RAOF: we also went too far with modularization, compounding the autotools slowness; I gather that's getting fixed soon.
<Sarvatt> well I think I learned my lesson about not trying to debug something that happens in a browser
 * Sarvatt squints at the 60 page backtrace
<RAOF> Does Chromium play the turing-complete-type-system game?
<Sarvatt> ahhhhh lovely, everything i've been printing for hours can just be printed to a log with an option :)
<Sarvatt> ... chromium bundles mesa
<RAOF> Woo!
<Sarvatt> oh nice, module-assistant in debian actually works
<RAOF> It doesn't work in Ubuntu?  I guess we don't test it as much.
<hyperair> in ubuntu we use dkms which is a vastly superior system, don't we?
<hyperair> someone should port over dkms to debian and get rid of m-a
<RAOF> Sarvatt: When do we want to move on to Xserver 1.9?  How's it doing in xorg-edgers?
<Sarvatt> yeah sysprof is just using m-a and i wanted to see if i get better info with the module
<Sarvatt> since perf is busted because of binutils
<RAOF> You're profiling chromium?
<Sarvatt> xserver 1.9 is still basically unusable
<RAOF> Good, good.
<Sarvatt> i built it all this morning
<Sarvatt> need to figure out what to do about the bgnr patch
<RAOF> Gah.  I need to kill mutter's grab of the <super> key with a sword.
<Sarvatt> the one airlied sent to the lists breaks the video abi, need to back that out and refresh it
<Sarvatt> gdm and plymouth hate it if your server doesn't support -nr, starts you on :1 and enter sends sigquit again like it did in lucid
<RAOF> Yay!
<Sarvatt> oh and you cant boot it at all if you have plymouth going, forgot that part
<RAOF> Bonus gÃ¼ngefactor.
<Sarvatt> have to press escape to ditch the splash or ditch splash :)
<Sarvatt> the nouveau patch needs refreshing, they moved all of that into another file now but thats easy
<Sarvatt> intel could use updating but i haven't tried it yet since i havent done a 3 branch merge yet and dont want to mess it up :)
<Sarvatt> oh yah and mesa
<Sarvatt> 7.8.2
<Sarvatt> i havent built mesa since the osmesa change, not sure if it needs any changes
<Sarvatt> i dont know if we can do the bgnr without breaking the abi.. :(
<Sarvatt> with 1.7 and 1.8 you could build with the bgnr patches applied to the ddx but not the server, but things fail on 1.9
<Sarvatt> got sysprof and module-assistant here if anyone ever looks for them - https://edge.launchpad.net/~sarvatt/+archive/ppa
<Sarvatt> never seen that before, a -refdbg package?  This package contains the shared library built with --disable-visibility so that it can be used with refdbg, a GObject refcount debugger.
<LLStarks> sarvatt, why does alpha channel break so often?
<Sarvatt> because making things faster involves screwing around with that :)
<Sarvatt> whats screwed up for you now?
<Sarvatt> lemme guess, chromium tabs?
<LLStarks> websites
<LLStarks> games in wine
<LLStarks> black or white splotches where transparency is expected,
<hyperair> meh mutter won't run with nouveau.
 * hyperair goes back to the binary blob
<hyperair> chromim tabs are transparent?
<Sarvatt> they draw an animation thats transparent yeah
<Sarvatt> and end up disappearing altogether for me right now
<Sarvatt> until i close enough to make the favicons on them show back up
<LLStarks> can't tell. they look normal.
<LLStarks> and system-wide rgba looks fine
<Sarvatt> open 20 tabs?
<LLStarks> gray tabs. looks normal.
<Sarvatt> what gpu?
<LLStarks> blue in classic
<LLStarks> 945gm
<Sarvatt> hmm
<LLStarks> is it 945gm or gma950?
<Sarvatt> when did you restart last?
<Sarvatt> yep
<LLStarks> 10 minutes ago
 * hyperair is noticing xxvi suddenly being very stable.
<LLStarks> i heard dri2 swapbuffers landed in the stack
<LLStarks> fullscreen tearing still present <___<
<Sarvatt> intel unstable where?
<Sarvatt> 2.11 does suck :)
<Sarvatt> LLStarks: do you have any other changes in your gtkrc besides rgba enabled?
<Sarvatt> what theme are you using?
<LLStarks> nope
<LLStarks> ambiance
<Sarvatt> same, bah
<LLStarks> but this all started when i decided to do my weekly edgers test
<hyperair> gnome-shell = extreme lagginess on nvidia
<LLStarks> kristian needs push for more 915 gallium
<hyperair> oh yeah, how is gallium3d 965 going?
<RAOF> I hear that fails to wedge the GPU.  Poor showing!
<Sarvatt> hyperair: hasnt been updated in months i dont think
<hyperair> =\
<RAOF> hyperair: 965 status: GPU wedge as soon as something touches it.
<hyperair> RAOF: lol. that sucks =\
<RAOF> Eh.
<LLStarks> 915 gallium is terrible right now. zero compositing support and gnome-panel can't even render properly.
<RAOF> LLStarks: You have a high bar for terrible :)
<LLStarks> eh?
 * RAOF doesn't care _that_ much about OpenGL 2.0 on my GM45, really.
<Sarvatt> odd because it works fine here
<LLStarks> OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20100330 DEVELOPMENT x86/MMX/SSE2
<LLStarks> OpenGL version string: 2.0 Mesa 7.9-devel
<LLStarks> OpenGL shading language version string: 1.20
<RAOF> LLStarks: Well, I mean it doesn't totally freeze your GPU.  If mere rendering errors are terrible, how do you describe i965 gallium? :)
<LLStarks> 965 gallium = 915 gallium?
<hyperair> RAOF: atrocious.
<Sarvatt> LLStarks: you activated stuff pretty much guaranteed to crash you and you complain about crashing? :)
<LLStarks> i test edgers once a week.
 * hyperair tests edgers every day
<RAOF> LLStarks: No; there are two intel gallium DRI drivers (and more classic drivers) - i915 and i965
<Sarvatt> that opengl 2.0 stub stuff is sketchy
<LLStarks> sometimes its stable enough for wide use.
<Sarvatt> edgers is my stable fallback when my newer stuff doesn't work.. lol
<LLStarks> what's wrong with fragment shader and occlusion query?
<Sarvatt> the gpu's dont support them
<hyperair> xxvi and mesa (dri-gem) seem pretty stable at the moment
<Sarvatt> fragment shaders crash me in cairo-gl
<Sarvatt> if you enable it things will try to use it instead of what they do support and screw things up (wine especially)
<hyperair> by the way, i heard some mention about a lcdfilter patch the other day. what's that?
<Sarvatt> hyperair: booted any other distro in the past few years?
<hyperair> Sarvatt: archlinux.
<hyperair> Sarvatt: is it font rendering?
<Sarvatt> yeah
<hyperair> i remember installing a cairo-ubuntu  thing on archlinux
<hyperair> from AUR
<hyperair> after getting a crapload of -ubuntu packages for font rendering, i gave up and came back to ubuntu
<Sarvatt> yep that was it, whole series of foo-ubuntu stuff for fonts
<LLStarks> i recall timo and anholt saying the stubs work on i945
<hyperair> especially since i was on my p4 which took half a day to compile a kernel, let alone openoffice.org
<hyperair> and firefox >_>
<LLStarks> driconf says so as well
<Sarvatt> its lying because you enabled the option to tell it to lie, if wine sees your card has GLSL support it's going to use that code path instead of what the card actually supports, it doesn't really support everything for those extensions
<LLStarks> ah
<LLStarks> at any rate, what are the benefits of transitioning intel to gallium?
<LLStarks> i keep forgetting
<Sarvatt> none? they aren't doing it
<Sarvatt> make phoronix happy?
<hyperair> lol
<LLStarks> tabloid.
<hyperair> isn't gallium3d supposed to have better performance or something?
<hyperair> at least, it seemed like radeon was doing better with gallium3d
<LLStarks> phoronix is never happy.
<Sarvatt> on ati where they dont already have GLSL support in classic and they got it for free switching over
<Sarvatt> thats not the case on intel..
<LLStarks> get vaapi and windows-equivalent 3d performance on 915 and i'll never give this laptop to my sister when i replace it.
<Sarvatt> yeah thats pretty much guaranteed not ever going to happen :)
<Sarvatt> the vaapi part
<LLStarks> okay, then reenable xvmc
<Sarvatt> option "XvMC" "True" in xorg.conf
<Sarvatt> thats been working for over a year
<LLStarks> ah. nice.
<Sarvatt> its just not enabled by default on <965, man intel talks about it
<Sarvatt> oh its disabled on 965 too now it looks like, it was enabled there and not on these for awhile
<LLStarks> can somebody explain the difference between i915, i945gm, and gma950? ddx/dri, chipset, and market name respectively?
<Sarvatt> 915-945 are generation 3 gpu's, theres just no point forking it off to a new kernel driver name for the newer stuff when they had 915 already
<LLStarks> bed.
<apw> RAOF, about?  just wondering where we were at with the i8xx patches, last i looked they were still changing have they settled now
<bjsnider> hyperair, there are a couple of outstanding mutter bugs in the nvidia blob that the gnome guys are pushing them to fix. that's why the nvidia issues on gnome-shell exist
<hyperair> bjsnider: the gnome guys are pushing who to fix?
<bjsnider> pushing nvidia
<hyperair> huh, do they actually budge?
<bjsnider> sure. it's on their list
<hyperair> =O
<Kangarooo> Sarvatt: can u check https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/587710 ? ive posted there a lot crashes already. at least one should give already info whats wrong.. ive already have 1 more. when ill have 4 more ill upload them too. should i remove ppa:bugsbugsbugs or continue with its debugs?
<Kangarooo> and debug without bugsbugsbugs ?
<ion> The version of fglrx in the ubuntu-x-swat/x-updates maveric repo fails here with [atiddxSetup] X version mismatch - detected X.org 7.1.1.901, required X.org 7.5.1.0. Anything i can do?
<Sarvatt> ion: nope, its harddcoded to only work with xserver 1.7
<Sarvatt> ion: they did it really crappily too, it actually works with xserver 1.8 but if the server version is >1.7.x then it refuses to load
<Sarvatt> i'm in the middle of updating it to 10.6 too, but it still doesnt work with the newer xserver
<Sarvatt> if you change the xserver version to 1.7 in configure.ac and rebuild everything it'll work, lol
<ripps> Does anybody here know why libvdpau [amd64] depend on ia32-libs. libvdpau is having problems building because it can't get ia32-libs, because ia32-libs isn't included in main (and from I've heard, is unlikely to get inclusion)
<Sarvatt> hmm, i dont think it should, only lib32vdpau should?
<Sarvatt> what  version ripps?
<Sarvatt> oh guess i need to look at amd64, duh :)
<Sarvatt> maverick has libvdpau 0.4-5
<Sarvatt> go figure packages.ubuntu.com doesnt show maverick now
<Sarvatt> ahh they didnt make a lib32vdpau-dev
<Sarvatt> ion: they'll support xserver 1.8 as soon as we move to 1.9, dont worry :)
<Sarvatt> ati finally fixed 2D performance with 10.6
<shadeslayer> Sarvatt: so it seems :)
<Sarvatt> almost done packaging it
<shadeslayer> now people are in #kubuntu asking how to install the sources :)
<shadeslayer> Sarvatt: w00t
<Sarvatt> just writing up the changelog, darn pdf
<shadeslayer> :P
<shadeslayer> Sarvatt: the packages will be in your PPA ??
<Sarvatt> ubuntu-x-swat/x-updates ppa
<shadeslayer> ah ok :)
<Sarvatt> lol chromium took 8 hours to build and failed to link webkit because 1gb ram + 2gb swap isnt enough
<Sarvatt> uploading the monster fglrx-installer-8.741 now
<shadeslayer> Sarvatt: wow...
<Sarvatt> if anyone uses it i'd appreciate feedback on if it works, didnt find out the 8.731 was broken for a month :)
<shadeslayer> Sarvatt: do you think vdpau will build without ia32-libs?
<shadeslayer> im trying it out now... its fetching the deps
<Sarvatt> they shoved the 32 bit libvdpau dev stuff in libvdpau-dev, it wont work
<shadeslayer> yaeh
<shadeslayer> build failed :P
<shadeslayer> want the logs? xD
<Sarvatt> works  in debian because they dont have libvdpau in main i dont think :(
<shadeslayer> Sarvatt: works in debian because ia32-libs is in main
<Sarvatt> oh! :)
<shadeslayer> its in universe here :P
<shadeslayer> Sarvatt: so how do we fix this>
<shadeslayer> we cant do a MIR.. ia32 wont get into main :D
<Sarvatt> can I see your build log?
<shadeslayer> sure
<shadeslayer> Sarvatt: libvdpau_0.4-5_amd64.build
<Sarvatt> i cant see how to fix it off the top of my head outside of just dropping the 32 bit portion
<shadeslayer> Sarvatt: http://pastebin.com/tALj4g76
<Sarvatt> hmm maybe the i386 build can just install the wrapper
<Sarvatt> and ia32-libs can pull the i386 package in instead
<shadeslayer> Sarvatt: so that it provides the required libs>
<Sarvatt> could just drop the whole lib32vdpau completely for now :)
<shadeslayer> BlackZ: \o
<shadeslayer> Sarvatt: hehe
<shadeslayer> Sarvatt: want me to drop it and post debdiff or are you on it?
<shadeslayer> BlackZ: <Sarvatt> could just drop the whole lib32vdpau completely for now :)
<BlackZ> yes, that could be a solution 
<Sarvatt> hmm this does need to be built differently for the wrapper and .pc to be correct,  stuffing it in ia32-libs wont work :(
<BlackZ> hey Sarvatt 
<BlackZ> shadeslayer: I'm looking at it right now
<shadeslayer> BlackZ: ok..
<shadeslayer> im going to sleep now,its 4 AM :P
<BlackZ> shadeslayer: does it FTBFS only on amd64?
<shadeslayer> BlackZ: yes
<BlackZ> well, have you seen http://launchpadlibrarian.net/49013154/buildlog_ubuntu-maverick-amd64.libvdpau_0.4-4_MANUALDEPWAIT.txt.gz ?
<shadeslayer> not exactly ftbfs... more of dep wait ;)
<Sarvatt> looks like fixing the vdpau wrapper to work with multiple VDPAU_MODULEDIR should be possible though
<BlackZ> also, is there a bug filed for that? 
<shadeslayer> nope
<shadeslayer> ripps: just told us about it :)
<ripps> I noticed it when my amd64 mplayer-build packages failed in one of my ppas
<shadeslayer> BlackZ: anyways im off... and btw the earlier package we talked about? ( qtcreator ) it was a problem with qmake,it was linked against qmake-qt3 whereas it should have been qmake-qt4 :P
<BlackZ> shadeslayer: I'm happy you were able to solve the problem :) 
<ripps> Sarvatt: btw, I uploaded my wacom-source package to revu. I wanted to know if you thought it was good enough for ubuntu inclusion
<BlackZ> ripps: why don't you include it in debian too? 
<ripps> BlackZ: I couldn't find any bug reports for it in debian, so I wasn't certain if they even had the bug
<ripps> I uploaded the same package to debian-mentors, so If somebody wants it, it's there.
<Sarvatt> yeah dropping lib32vdpau for now seems to be the way to go, we didnt even ship it before
<BlackZ> Sarvatt: I noticed 'lib32vdpau1' is not in our repository 
<BlackZ> it should be synced from debian 
<Sarvatt> its built by the libvdpau source package
<Sarvatt> which is in depwait on amd64
<BlackZ> hmmm .. Sarvatt: it build here 
<BlackZ> s/build/builds
<BlackZ> I have amd64 and I have no problems 
<Sarvatt> because you have ia32-libs installed
<BlackZ> hm Sarvatt maybe you're right 
<BlackZ> I should try without it 
<BlackZ> ripps: however, could you file a bug?
<Sarvatt> https://edge.launchpad.net/ubuntu/+source/libvdpau/0.4-5/+build/1790677
<BlackZ> Sarvatt: yeah, I seen that
#ubuntu-x 2010-06-19
<Sarvatt> ripps: just no change rebuild libvdpau on your PPA for now since it'll build fine there :)
<ion> sarvatt: :-)
<Sarvatt> actually it may just be fail in the detection scripts, let me take a look
<Sarvatt> X.org 7.1.1.901, required X.org 7.5.1.0. -- looks like its just failing
<ion> sarvatt: Oh, btw, i made http://heh.fi/tmp/fglrx-installer-abiver.patch earlier, but didnât get around to posting it anywhere since fglrx failed to install on my system at the time due to me not having patches for kernel 2.6.35. I copied the rules to provide xserver-xorg-video-$ABIVER from the nvidia driver packaging verbatim.
<Sarvatt> the one in x-updates failed on 2.6.35? it works fine here!
<ion> No, before i found a package with the patches in the PPA. :-)
<Sarvatt> ion: personally i dont think they should be providing an abi at all since they arent tied to an abi
<Sarvatt> nvidia-current works with multiple video abi's and the packaging only provides one, and it took a week and a half for it to get no change rebuilt against the new abi even though it worked :(
<ion> Ah, ok. Dunno what is the right way to go, i just came up with that when fglrx stopped working after an xorg update in maverick. It would have been nice if that version of the fglrx package had blocked that xorg update.
<Sarvatt> yeah thats true, it probably would be more helpful on ati :)
<Sarvatt> since they take 6 months to update things
<Sarvatt> nvidia supported xserver 1.8 back in november or december
<ion> And the free drivers supported it... pretty much immediately. :-P
<Sarvatt> trying to figure out where it gets that 7.5.1.0 string from
<Sarvatt> ion: do you have an xorg log from a failed boot by any chance?
<Sarvatt> ah its in atiddxSetup from what you pasted, nevermind
<Sarvatt> i've got an fglrx machine now so i can test hex editing the blob to work around it :)
<Sarvatt> doesn't look like its a registry option that can be adjusted but i need to go over some more strings to be sure
<ion> Hehe
<Sarvatt> ya remember if that atiddxSetup error happened after loading a specific module?
<ion> Iâll install fglrx and save the log this time, a moment.
<ion> Iâll have to take a look at making nvidia_supported work again with the new nvidia release at some point. (I contributed the original _supported scripts.)
<Sarvatt> oh really? thank you for doing that, i couldn't work it out
<Sarvatt> my fglrx machine is finally done compiling chromium so i can do it
<ion> Ok, the new nvidia driver no longer has the duplicate PCI ID list, so that heuristic canât be used anymore. Iâll come up with something new.
<ion> Alright
<Sarvatt> ah looks like fglrx-2.6.33.patch isnt needed anymore
<Sarvatt> gotta upload a new version without it
<Sarvatt> darn, that message doesn't even show up for me - http://pastebin.com/At3G7UUY
<Sarvatt> hmm http://sarvatt.com/downloads/xserver.gdb.txt
<ripps> Yo, I'm back.
<ripps> Sarvatt: Since BlackZ not here, I'll tell you. I'd file a bug, but since I don't have amd64, it feel like it's inappropriate. Also, I can't file bugs against ia32-libs because since the package isn't availble for my computer, apport tells me the package doesn't exist.
<Sarvatt> ripps: just upload libvdpau to your PPA to fix it..
<Sarvatt> make it 0.4-5+ripps or something
<ripps> Sarvatt: yeah, that sounds like a good plan. I was just hoping that this could be fixed for everybody, not just me.
<Sarvatt> you're telling me you want me to file the bug because you need ubuntu-bug or something?
<Sarvatt> i can't upload it :)
<ripps> Sarvatt: well, I actually started this in ubuntu-motu. But it got moved over here somehow :P
<ripps> I can't file bugs against ia32-libs, because apport will only let me file bugs against my i386 packages. How do you file bugs manually these days?
<ripps> Did you guys find a fix? you mentioned something about VDPAU_MODULEDIR
<Sarvatt> superm1: any idea what to do about libvdpau-dev needing ia32-libs now and not being in main? as far as I can tell just dropping the lib32vdpau package is fine for now since we never shipped a seperate 32 bit version
<Sarvatt> ripps: no
<superm1> Sarvatt, agree
<superm1> i wish debian would do what we did with putting all the nvidia stuff in a single package
<superm1> seems so much more sensible this way
<Sarvatt> ion: it looks like fglrx 10.6 in x-updates works with xserver 1.8, I was wrong!
<bjsnider> since when does libvdpau-dev require ia32-libs?
<Sarvatt> problem is, jockey's xorg.conf doesn't work
<Sarvatt> ion: http://pastebin.com/2Ti6wMNe
<Sarvatt> BusID "PCI:1:0:0" is required in xorg.conf in fglrx 10.6, ati just mentioned it
<Sarvatt> or whatever the busid is for your system, fun
<ion> Alright. Yay for nerfing autoconfiguration. :-P
<ion> I didnât manage to come up with a future-proof way to scrape PCI IDs from the nvidia driver yet. I tried to find a consistent code path from a non-obfuscated symbol to the list, but failed so far. Perhaps iâll just do another heuristic that may work for a few years and then fail with some future release, requiring yet another new heuristic. :-P
<Sarvatt> they aren't going to add new ones to the old releases, can't we just include all pci ids included in the new ones or does it contain more than it supports?
<ion> New releases add support for new cards with new PCI IDs.
<Sarvatt> yeah, is there no way to dump every pci id in that blob since it only has the ones it works with?
<ion> Thatâs exactly what nvidia_supported does. :-)
<ion> The trick is scraping the data from the blob in a way that doesnâá¹­ require tinkering for every release.
<ion> The previous trick worked a long time, but now they changed stuff and it doesnât work anymore.
<Sarvatt> oh, i thought it was removing some from that list for some reason
<ion> If the data was behind a consistent symbol in the object file, everything would be fine. But itâs behind an obfuscated symbol which changes names on every release.
<Sarvatt> why dont we just pull it from html/supportedchips.html?
<ion> At the point i originally wrote nvidia_supported, the HTML list wasnât maintained properly. In every release, it had major differences to the actual data. I should check if thatâs fixed by now, actually.
<Sarvatt> ahh gotcha, i've been checking it since around 185.35.15 and its been updated every time they add new cards at least
<ion> They were updating it, yes, but it almost seemed as if a human received a list of added and removed PCI IDs and manually updated the HTML for every release, and errors kept creeping up every time :-P. One would think they could just autogenerate the HTML from the source code, but that wasnât a case at least back then.
<ion> the case
<Sarvatt> ahh gotcha, checking how other distros do it now
<ion> Anyhoo, itâs easy enough to modify nvidia_supported to detect the list from the current release and from a number of foture releases as long as they donât change the format again. I donât expect that to happen for a while. I was trying to come up with an almost completely future-proof solution, but that might not happen. And yeah, iâll compare the list from the blob from the newest release to the HTML, perhaps theyâve fixed it.
<Sarvatt> hmm, went to look at nvidia-installer to see how it checks since its open source, and just saw there was a new nvidia release
<Sarvatt> darn, the nvidia 256.35 x86_64 ftp directory has the x86 one in it so i cant package it up yet
<Sarvatt> found it, check_for_nvidia_graphics_devices() - http://cgit.freedesktop.org/~aplattner/nvidia-installer/tree/misc.c?id=19a9146a421689b409588c9505364024378e1dd1
<Sarvatt> gotta run though, will see what it does when i get back :)
<ion> Ok, it only has a list of legacy devices, and anything nVidia && VGA that isnât in it is deemed supported.
<Sarvatt> can we just use 0x04** - 0x0F** or do we have to explicitly define each one?
<Sarvatt> ah nope their other devices are in that namespace too
<ion> In any case, any list that is not directly based on the actual code of the newest release available for each series has a chance of being inaccurate, and nVidiaâs track record hasnât been good with such lists.
<ion> Using such a list would probably work for most users, but then there would be hard-to-verify bug reports from users that just happen to have a card that the list missed.
<superm1> Sarvatt, ion what about taking the approach of what NV installer does and just say everything is supported, and then maintain a blacklist of (earlier) stuff that isn't?  
<superm1> they do announce when they drop support generally, don't they?
<Sarvatt> does jockey understand pci device namespaces?
<Sarvatt> it uses libpciaccess?
<Sarvatt> i mean you need to tell it to restrict it to 10de vendor id's and only look at video devices
<Sarvatt> or is that info in the modalias already? i dont know what everything in pci:v00001002d00009715sv*sd*bc*sc*i* means
<Sarvatt> how would you tell jockey to use everything is what I'm asking basically
<ion> sarvatt: Hereâs the diff from blob to HTML for 256.29, btw: http://gist.github.com/444604#file_list.diff
<ion> From HTML to blob, i mean.
<ion> The blacklist of earlier stuff would still need to be parsed the same way.
<Sarvatt> blob is reporting some false positives then
<ion> Iâd trust the code maintained by coders more than the HTML maintained by documenters. :-P
<Sarvatt> 0cxx is the highest pci id they have for the newest generation gpu's though
<Sarvatt> maybe those other devices are agp-pcie bridge chips, lessee
<Sarvatt> and that would make sense because the actual pci id of the card is hidden behind the bridge chip and not listed on that list i bet
<Sarvatt> same problem i had with extracting pci id's on nv
<superm1> Sarvatt, well i dont think jockey can right now; that would have to be an additional patch to it
<Sarvatt> yep the 02xx ranges in the blob extracted one are indeed bridge chip pci ids that we'd need to add
<Sarvatt> html is definitely out :)
<Sarvatt> 08xx ranges are IGP's
<ion> I wonder if nvidia would put the table (itâs just data: the PCI IDs and some flag bits probably designating each chipâs features) behind a non-obfuscated symbol if we asked nicely? :-)
<Sarvatt> would it be wrong to hack up a postinst to run aticonfig --initial after install for fglrx? ati is insisting its required and something tells me they're not going to fix what they broke making it really be required now
<Sarvatt> heh all of those id's I thought were wrong in your list were all removed in 256.35
<Sarvatt> probably prerelease cards they meant to keep internal
<Sarvatt> the 0Dxx-0Exx ones
<ion> Ok
<Sarvatt> this still works though - objdump --section=.rodata --full-contents --start-address=0x3940 --stop-address="$((0x3940+0x2540))" NVIDIA-Linux-x86-256.35/kernel/nv-kernel.o | sed -nr 's/^ [0-9a-f]+ ([0-9a-f]{2})([0-9a-f]{2})0000.*/\2\1/p' | sort | uniq | grep -vx 0000
<ion> Probably by accident, and you may have a slightly incorrect range.
<ion> Iâll get some sleep soon, but after that iâll try to get around to making the necessary changes to nvidia_supported.
<Sarvatt> there's only a 3k difference in all files combined in .35, pretty much the same thing as .29
<Sarvatt> night!
<ion> Iâll finish this episode of B5 first, though. :-)
<ion> objdump --section=.rodata --syms .../nv-kernel.o | less, and find the one with length near 0x2540 starting near 0x3940, and pass those numbers to the --full-contents snippet to get the correct list. But iâm going to script a bit of heuristics to get the right symbol deterministically.
<ion> To find the symbol starting at 0x3940 in the first place (for 256.29), i just ran objdump --section=.rodata --full-contents .../nv-kernel.o | less and searched for 4200 (a random PCI ID i expected to find, 0x0042 in little-endian order) in an area that looked like a nice list of IDs, picked the offset of the beginning of the list and looked up the matching symbol from --syms.
<ion> sarvatt: nvidia_supported originally accepted multiple versions of nv-kernel.o as parameters and didnât add PCI IDs to older versions that were supported by a newer version. Is that functionality still needed? The script could be simplified by dropping it, since it doesnât seem to be used.
<Sarvatt> i'd drop it personally, it's useful to be able to use the old drivers on newer cards where support overlaps to test stuff
<ion> Alright
<Sarvatt> looks like i'm disappearing for awhile..  it's been fun you guys
<johanbr> Sarvatt, oh! thank you for your all your work
<Duke`> disappearing for awhile !!?
<Sarvatt> yeah bad timing between cutting back on work thinking i was getting another job and having to find a new apartment at the last minute :(
<ion> sarvatt: http://gist.github.com/raw/445368/ab14590fc18aedbf5f10b3b74feddb853f7fbfbc/nvidia_supported
<ion> sarvatt: That should work for all versions of the driver.
<ion> sarvatt: Changed it a bit: http://gist.github.com/raw/445368/6b54c1c04836d3d9d9061cdf0b25c60b8c4c0e38/nvidia_supported
#ubuntu-x 2010-06-20
<hyperair> Sarvatt: xxvi version 2:2.11.901+git20100619.4b7142ba-0ubuntu0sarvatt~lucid segfaults when opening a terminal
 * hyperair is installing dbg symbols to get a trace
#ubuntu-x 2011-06-13
<bjsnider> gord, how much faster is the general usage with sna?
<LLStarks> saarvatt, check the experimental gallium package. it doesn't automatically overwrite the 915 .so file upon installation anymore.
<LLStarks> ack sarvatt
<Sarvatt> LLStarks: it never did, it installs it to /usr/lib/dri-alternates/i915_dri.so which is in the dri searchpath before /usr/lib/dri and empty unless libgl1-mesa-dri-experimental is installed
<LLStarks> i swear it did at one point
<LLStarks> whatever
<LLStarks> thanks
<Sarvatt> lool: hey I missed your message until now. I can't upload it (the other was sponsored), please do upload it :)
<Sarvatt> it does look like a good idea to me
<ksni> is this a support or development channel?
<ksni> the topic doesn't tell much
<ksni> ping.
<highvoltage> ksni: don't you think it will just be more efficient to ask your question rather than just make a contentless ping?
<bryceh> ksni, development
<ksni> not really, if the question is complex enough
<ksni> anyway, my Ubuntu installation on a hard drive, which I recently migrated to a desktop PC, thinks it's still in my laptop and shows the laptop monitor in the configuration screen. how do I get it to move on?
<ksni> along witht the currently connected monitor
<bryce> rm ~/.config/monitors.xml
<bryce> ksni, and that's not a development question
<ksni> I know, but I didn't get any response from #ubuntu until I asked "is anyone here?" after 10 minutes of typing long questions
<bryce> ksni, your penance can be answering 3 other people's question on #ubuntu then ;-)
<ksni> okay
<ksni> but this case first
<bryce> ksni, did you rm ~/.config/monitors.xml ?
<ksni> yes, where should I see change?
<ksni> GNOME display configuration box still "detects" the ghost laptop screen
<bryce> you may have to restart the tool
<ksni> I'm using the graphics thing integrated in a Intel D510MO motherboard
<bryce> ksni, beyond this I need to see Xorg.0.log from you
<ksni> http://paste.servut.us/plain/iyg5
<bryce> ah, one of those laptop mboards upsized to desktop
<bryce> ksni, yeah, common issue for this type of motherboard.  you can try fixing it in X via this - https://wiki.ubuntu.com/X/Quirks#Ignore%20LVDS%20Output%20Quirk, however it's really a kernel bug
<bryce> so for a real fix this is needed:  https://wiki.ubuntu.com/X/Quirks#Intel%20Phantom%20LVDS%20Quirks:%20i915/intel_lvds.c
<ksni> okay, thanks for this
<bryce> the former may only work with KMS turned off, which you can't do anymore with -intel, so YMMV.  That'd be the easiest workaround.
<bryce> ksni, regardless of whether the config option works or not, what you need to do is file a bug against the kernel (ubuntu-bug linux) requesting that LVDS be quirked off for your motherboard.  Point to the second link I gave you.  Contact apw who is one of the kernel developers that hacks on graphics stuff.
<bryce> if the config option works, you can use that as a workaround.  Another possible workaround is to turn it off using the 'xrandr' command line tool
<bryce> xrandr --output LVDS1 --off (see man xrandr for more info)
<bryce> however I think that's pretty much the same as the gui tool so YMMV there.
<ksni> sure, but...
<ksni> Ubuntu uses udev for auto-detecting graphics units and HIDs, does it not? do I lose the automatic detection of changes in hardware by creating /etc/X11/xorg.conf?
<ksni> anyway, thanks for your time
#ubuntu-x 2011-06-14
<bryce> mesa 7.10.3 mmm
 * hyperair pokes Sarvatt for a new sna xxvi. =D
<Sarvatt> oops forgot to hit retry on it, it failed because natty dri2proto hadn't built yet
<Sarvatt> hyperair: sorry, forgot to hit retry after dri2proto updated in edgers, it'll build eventually
<hyperair> oh yay =p
<hyperair> by the way, i haven't seen any artifacts using sna
<hyperair> Sarvatt: and my X uptime is 6 days.
<Sarvatt> oh amd64 already built
<Sarvatt> it works with chrome/chromium? i haven't tried it in a few days
<Sarvatt> well since it was merged really
<hyperair> that i haven't tried.
<hyperair> let's see..
<hyperair> yeah it does
<hyperair> any specific website to load?
<hyperair> google loads fine
<hyperair> the speed dial thing loads fine too
<Sarvatt> everything was broken here
<hyperair> everything loads fine here.
<Sarvatt> guess it'll turn into a "hunt down bugs on specific chipsets" problem then
<hyperair> heh
<hyperair> i'm glad i'm not hit this time. =p
<Sarvatt> http://sarvatt.com/downloads/sna1.png
<hyperair> oh yeha i saw that one
<Sarvatt> still looked like that last i tried on sandybridge
<RAOF> I think it's quite nice that the sna code appears highly generation-specific.
<Sarvatt> trying it out now, lessee
<Sarvatt> nothing refreshed at all anymore without alt-tabbing under gnome-shell and unity
 * Sarvatt pins udev back to 167 before he makes the mistake of upgrading it again
<Sarvatt> yeah looks like the checkout in intel-sna was right before the fix for that landed, will fix it up in the morning
<Sarvatt> actually i'll just patch it in so its at least working, seems to be broken every morning when I update things and fixed in the afternoon.. can only upload one source package a day to launchpad which is a PITA
<ScottK> Why is that?
<RAOF> Upstream git SHAs aren't strictly monotone increasing, so can't be usefully used to disambiguate between different tarballs generated on the same day.
<RAOF> Ie: it's a limitation of the xorg-edgers utility tools.
<Sarvatt> according to launchpad 2.15.0+git20110613.aaaaaaaa-0ubuntu0sarvatt is > 2.15.0+git20110613.ffffffff-0ubuntu0sarvatt
<Sarvatt> it started mid karmic cycle
<Sarvatt> err 0000000 for the first
<ScottK> So just use a per upload of the day serial number in the revision and put the commit hash in debian/changelog.
<ScottK> Using the hash in the revision doesn't actually help.
<RAOF> Yeah, it just requries tooling.
<Sarvatt> not sure I agree, for mesa that'd be like 30-40 commits a day it could be trying to narrow down where the problem is and the changelog isn't saved
<Sarvatt> anyway the once a day limitation isnt that big a deal, just need to add new commits at patches if its urgent
<ScottK> The changelog isn't saved in the package you upload?
<RAOF> You'd include the short SHAsum of the source in the package version.
<RAOF> 7.11+git20110614.1+deadbeef-0ubuntu0~sarvatt1 :)
<ScottK> That'd do it.
<jussi> Morning all. Got a machine here at work that has an "unclickable area". Its a laptop, with ati, and an external screen attached. It makes it fun. :=) 
<jussi> He is just reporting a bug now. 
<RAOF> What sort of âunclickable areaâ?  In the past this has been a compiz stacking bug, where input-only windows get accidentally stacked on top of everything.
<RAOF> Because, hey!  There's nothing so frustrating about X that it can't be made *more* frustrating by clients doing braindead things!
<jussi> RAOF: basically there is a area which doesnt let him click there. If he has a webpage, he can scroll past the area and click the link, but it wont work if the link is in the area.
<jussi> bug 797062
<ubot4> Launchpad bug 797062 in xserver-xorg-input-mouse (Ubuntu) "Can't click with the mouse in a certain area on the screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/797062
<RAOF> Sounds quite like the compiz stacking issue.
<jussi> right, so how do we give you more informaton to make sure its that, and make your life easier? 
<RAOF> If he runs âxpropâ and clicks in the unclickable area, does he get a bunch of information about a window?
<jussi> it just gives 1 line.
<RAOF> Pastebin?
<jussi> he has put it on the bug
<RAOF> Oooh, could you do the same with xwininfo?
<RAOF> Sorry.
<jussi> RAOF: on the bug
<RAOF> Override redirect?  That's a pretty antisocial InputOnly window!
<jussi> hehe
<RAOF> So, he can look up what process has stuck that window there with âxwininfo -allâ, which will include a line like âProcess id: 2723 on host Edâ.  Looking up that pid will uncover the process that's being annoying.
<RAOF> I think at this point it's a bug in that program.  It doesn't appear to be a bug in Compiz - the window manager should never touch OverrideRedirect windows - and it doesn't appear to be an X bug.
<jussi> RAOF: on the bug.
<jussi> RAOF: in which program?  the deadspot is there on any program
<jussi> hehe, he added some artwork for illustration purposes... :D
<RAOF> jussi: Right.  What's happening is that there's an invisible window there.  Which gets all the mouse clicks, and doesn't forward them on.
<jcristau> xkill ftw.
<RAOF> jcristau: Is it possible to grab the PID of the process from a window which doesn't set NET_WM_PID?  I've forgotten :)
<jcristau> probably not easily
<RAOF> I guess it'd be easier with that XRes 1.2 protocol patch set.
<jussi> Ok, he is going to try go back to work now, but if you need something more than whats on the bug, please ask :)
<jcristau> yup, probably
<jcristau> but xkill just requires you to click on the window, not the pid.
<jussi> jcristau: as noted on the bug, that didnt help
<jcristau> ah.
<tjaalton> OOM killer ftw
<jussi> tjaalton: ? 
<tjaalton> my wifes session was somehow messed up, desktopcouch-service was respawning like crazy, and ate all the memory.. of course it killed _my_ session
<jussi> dont you just love his artwork? :D
<RAOF> You might have better luck passing -frame to xkill, but it might also kill the window manager :)
<jussi> https://launchpadlibrarian.net/73495608/Screenshot-1.png - its funny though, that you can drag through the area and it works, but clicking on the area doesnt.
<RAOF> Right.  Because drags take a pointer grab, IIRC.
<tjaalton> hmm wait, it didn't kill my session after all, it was just the "change user" dialog showing up after 20min of swapping
<tjaalton> desktopcouch still taking 100% cpu
<tseliot> RAOF, tjaalton: is multiarch mesa already in Oneiric?
<tjaalton> tseliot: not yet aiui
<RAOF> tseliot: No, not yet.
<tjaalton> btw, should we start uploading this stuff in?
<tjaalton> xserver, xorg etc
<tseliot> tjaalton, RAOF: ok, as I was wondering where I could get it for testing (mainly to test proprietary drivers) and also to know when to upload fglrx and nvidia
<RAOF> Mesa's basically just blocking on https://bugs.launchpad.net/ubuntu/+source/llvm-2.9/+bug/790204 at this point.
<ubot4> Launchpad bug 790204 in llvm-2.9 (Ubuntu) "[MIR] libllvm-2.9 (affects: 1) (heat: 8)" [Undecided,New]
<tjaalton> ah
<tjaalton> forgot about that
<tjaalton> and it also blocks xserver?
<tjaalton> well, mesa that is
<tjaalton> uh, mesa blocks xserver
<tseliot> oh
<RAOF> Well, xserver will need a rebuild after multiarch'd mesa, yes.
<RAOF> tseliot: I'll throw the multiarch'd mesa in my aubergine PPA if you like.
<tseliot> RAOF: yes, please, I was about to ask that
<RAOF> Man, things look quite a lot better with proper font settings and the Ubuntu font now that gnome-tweak-tool works.
<tjaalton> but when do we get a proper theme :)
<RAOF> Yeah.  Does anyone else think that Awdibitititia results in ridiculously huge chrome? :)
<tjaalton> awdiwhat?
<RAOF> Whatever the default theme is.
<tjaalton> ah
<tjaalton> i don't even know where to change the theme
<RAOF> gnome-tweak-tool.
<RAOF> (Although it's got an undeclared dependency on gnome-shell)
<tjaalton> ok, i have the shell already installed, at least it looks nice :)
<tseliot> RAOF: so now that you're working on the new gnome-display app, are you going to change libgnome-desktop too?
<RAOF> Yes.  It needs a bit of work to extend the GnomeRRConfig stuff.
<RAOF> Anything you particularly want done? :)
<tseliot> RAOF: yes, I've found a bug where g-s-d tries to assign the same crtc to more than one output when not in clone mode
<RAOF> That sounds unlikely to work.
<RAOF> âº
<tseliot> I think it's missing a check
<tseliot> yes, as a matter of fact, it doesn't
<tseliot> currently we don't have a way to check that when assigning crtcs
<tseliot> so we should check if 1) we're doing clone mode 2) if so, make sure crtc is not already taken
<tjaalton> grr, the text-scaling slider is utterly useless
<RAOF> tjaalton: *Yes*
<RAOF> Because it's *too hard* to have a frikking *DPI* number, oh no!
<tjaalton> and it changes the scaling in realtime, and the lag is just awful
<RAOF> Even better, if you hold it down then when the widget reflows it changes the setting for you again :)
<RAOF> tseliot: That sounds reasonable.  Do you have a bug in mind?
<tseliot> RAOF: so I guess this would be part of 2) http://pastebin.ubuntu.com/626429/
<tseliot> sure, I have a public bug but it's better explained in a private bug report
<tjaalton> RAOF: exactly..
<tseliot> RAOF: here's the public report: bug #791752
<ubot4> Launchpad bug 791752 in linux (Ubuntu) "Can not toggle Display to External only mode (affects: 2) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/791752
<RAOF> Gah.  Damnit firefox, get your filthy tendrils out of my ram!
<tseliot> :)
<RAOF> I don't like it enough to give it 1.7 GiB of memory :)
<tseliot> hehe
<bryce> no n in dammit.  gotta luv englisch
<RAOF> There is when I spell it, damnit :P
<RAOF> And between that and evolution sucking an approximately equal slice of ram there's quite a lot of ram pressure on my poor little 4GiB system.
 * jcristau hugs mutt
<bryce> RAOF, we can call it tasmanian english
<RAOF> bryce: Well, there's a subtle difference in pronunciation, too :)
<tjaalton> thunderbird aint that bad either, only 100+ megs RES here
<RAOF> But all my filters are in evolution :(
<tjaalton> bryce: so xdiagnose 0.3 already has the failsafe/apport-stuff on it, so xorg git can enter oneiric?
<RAOF> Oh, whoops.  Probably a good idea to get the buildsystem to actually *build* libgallium if I'm going to link against it.
<tjaalton> ..and there goes desktopcouch berserk, again
<tjaalton> on an idle session
<RAOF> What's still pulling desktopcouch in for you, anyway?  I thought U1 stuff had transitioned away from it.  Because it keeps going beserk :)
<tjaalton> this is natty
<tjaalton> dunno why it's started
<bryce> tjaalton, yep, I have a few things to fix up to get it working properly repackaged with dh_python2 but expect to have that done tomorrow
<bryce> tjaalton, I don't think there's any reason to hold off xorg.
<tjaalton> bryce: ok, I'll upload it today
<tjaalton> also a couple of merges ready
<tjaalton> hmm, uscan doesn't seem to work on libx11
<tjaalton> no, it claims the package is up to date, but I can't find the tarball :)
<RAOF> uscan --download-current-version ?
<tjaalton> yeah, seems to work better with that
<tjaalton> so it checks the git version too..
<sithlord48> what package do i install for hw texture compression on my intel card?
<jcristau> i guess you want http://dri.freedesktop.org/wiki/S3TC
<sithlord48> thats prolly it thx
#ubuntu-x 2011-06-15
<ricotz> tseliot, hello, one day too early ;), 275.09.07 is now considered stable and includes the linux-3.0 fixes
<tseliot> ricotz: yes, I know... I'm working on it
<ricotz> tseliot, alright ;), i just uploaded it to edgers, but i didnt merge the oneiric release
<tseliot> ricotz: I'll upload the package later today
<ricotz> tseliot, ta
<tseliot> np
<raevol> if i installed libtxc-dxtn0 from xorg-edgers do i have S3TC or do i need to recompile my own kernel?
<raevol> apparently it works, 0ad running like a charm...
<raevol> ah though i see 0ad has a nos3tc option set, so mebe not
<raevol> but all i wanted was 0ad so i'm fine :)
<ricotz> raevol, no need for a recompile, the lib is looked up by the application on runtime
<raevol> ok cool
<raevol> wonder if i should enable it in my 0ad cfg then
<raevol> game plays fine though :/
<ricotz> raevol, should work fine if you didnt disabled it in ~/.config/0ad/config/local.cfg
<raevol> yea
<raevol> this is amazing i've never been able to play this before :)
<ricotz> raevol, btw which ppa are you using or svn?
<raevol> xorg-edgers
<raevol> umm
<raevol> the ppa?
<raevol> is there more than one?
<ricotz> raevol, oh i meant for 0ad ;)
<raevol> ah, the .... one on the website D: not svn?
<ricotz> so ppa:wfg/0ad?
<raevol> yea
<ricotz> ok
<raevol> i see you in #0ad ;P
<ricotz> i know ;)
#ubuntu-x 2011-06-16
<RAOF> Oh, arse.  Of course i915 doesn't build on armel.  Bah.
<tseliot> RAOF: is it even useful on armel?
<jcristau> is that a real question?
<tseliot> :)
<tseliot> ever heard of rhetorical questions? ;)
<tjaalton> RAOF: push the branches :)
<RAOF> tjaalton: Done, like a dinner.
<tjaalton> RAOF: xserver too :)
<RAOF> The xserver costs extra.
<tjaalton> we'll see about that in dublin
<tjaalton> oh you actually built the thing
<RAOF> Well, yes.
<RAOF> I needed to, you see.  'Cause of multiarch and stuff :)
<tjaalton> yes, so the pointer barrier patch needed an extra commit
<tjaalton> totally missed that
<RAOF> And there's an extra commit for the crtc-confine stuff, but I wanted to upload mesa and X now.
<RAOF> I once made the mistake of printing out each error compiz ate in the hope of working out why DnD wasn't working.  My terminal wasn't happy.
<Sarvatt> woo, multiarch X/mesa is a fun nightmare to wake up to :)
<tjaalton> a dream come true
<Sarvatt> thought it was getting too easy to update natty and oneiric from the same packaging branches for more than a few weeks :)
<jcristau> as a bonus it broke nvidia and fglrx in sid
<tseliot> heh
<Sarvatt> guess it's time to switch to amd64. ia32-libs mesa was all that was holding me back because using 6 month old stable mesa releases is crazy :)
<Sarvatt> extra fun: wonder if its possible to switch without a reinstall :)
<bjsnider> Sarvatt, are you going to put the 275 blob in x-updates?
<Sarvatt> sure, give me a sec
<Sarvatt> bjsnider: uploaded for natty at least
<bjsnider> Sarvatt, cool
#ubuntu-x 2011-06-17
<RAOF> Hurray!  llvm mir goes through!
<RAOF> That means it's coffee time!
<ScottK> Sarvatt: Cross-grading from one architecture to another is definitely not supported, but that's not quite the same thing as saying it can't be done.
<ScottK> IIRC when Debian dropped arm in favor of armel the migration strategy was 'reinstall'.
<RAOF> ScottK: Cross-grading is actually one of the explicit aims of the multiarch work, isn't it?
<RAOF> Yeah, third user-story on https://wiki.ubuntu.com/MultiarchSpec
<ScottK> Don't think so.
<ScottK> Oh.
<RAOF> Oh, yeah!  PowerPC exists as well! :/
<tjaalton> https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6
<tjaalton> there are typos, and then there are _typos_
<RAOF> Yes!
<RAOF> Oh, armel.  Would it be so hard for you to be just a *little* bit faster?
<tjaalton> wonder how many cores the buildd has..
<RAOF> I think the Canonical porter box has one.
<RAOF> Sarvatt: I can haz xorg-edgers team renewal?
<ach1m> after the upgrade of xorg-edgers today I noticed some graphical glitches http://imageshack.us/clip/my-videos/845/x9r.mp4/
<ach1m> My graphic chip is a g45 (X4500HD) from intel.
<Sarvatt> http://kernel.ubuntu.com/~sarvatt/lp761065/  6-11x performance increase on sandybridge and fixes bug 761065 at the same time? yes please!
<ubot4> Launchpad bug 761065 in xserver-xorg-video-intel (Ubuntu) (and 2 other projects) "[Sandybridge] Spurious "*ERROR* Hangcheck timer elapsed... blt ring idle" messages in dmesg when using compiz (affects: 40) (dups: 3) (heat: 234)" [Medium,Invalid] https://launchpad.net/bugs/761065
<Sarvatt> oh boo, just built 5 kernels and now there's a v2 of the patch :)
<XenoPhoenix> Hi Guys, been directed in here to re-ask my question:
<XenoPhoenix> If KMS is enabled, I have green output on HDMI till I unplug and replug the TV (goes green again if i turn off and on the TV again), disabling modesetting using i915.modeset=0 fixes this issue however it is not a solution as it also disables graphical acceleration. This only occured with natty, no problems before upgrading, Any ideas?
<mdeslaur> is there a tool to see if vdpau support is enabled/working?
<Sarvatt> oops meant to respond here
<Sarvatt> there's a vdpauinfo package, what are you trying to check though?
<Sarvatt> it isn't working on i386 on amd64 unless you install lib32vdpau1 from debian directly
<Sarvatt> its not in ia32-libs and they disabled it from the ubuntu packages for some reason..
<Sarvatt> i'm guessing you want 32 bit flash vdpau on amd64
<Sarvatt> mdeslaur: sorry, meant to ping you as well :)
<mdeslaur> i'm actually running i386
<Sarvatt> https://launchpad.net/~nvidia-vdpau/+archive/ppa/+files/vdpauinfo_0.0.6-1~karmic~nvidiavdpauppa1_i386.deb
<Sarvatt> looks like its not in the archive yet
<mdeslaur> ah, thanks
<Sarvatt> http://cgit.freedesktop.org/~aplattner/vdpauinfo if you want to build it yourself
<mdeslaur> I'm trying to get mythtv to use vdpau to play hidef h264 encoded video
<Sarvatt> http://paste.ubuntu.com/628558/
<mdeslaur> oh, hrm, I think going to metacity instead of compiz made it work :(
<bryce> heh, ouch:  https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1
<Sarvatt> hey now, SNA seems to be working ok on sandybridge with no xserver patch
#ubuntu-x 2011-06-18
<LLStarks> bryce, ubuntu isn't ready for bacon. llanos with discrete gpus apparently are muxless.
<LLStarks> i hope amd is kinder than nvidia for dynamic switching on linux
<cdbs> LLStarks: bryce: Seamless graphic switching of Bacon/Optimus kind is a dream for Linux, as long as X stays under the roof
<cdbs> LLStarks: I doubt if AMD would care that much about Linux, nVidia is usually more serious when it comes to linux and in March nVidia said a clear "NO" for optimus support
<bryce> LLStarks, cdbs: no, look more closely at the diff
<tjaalton> which diff?
<bryce> https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1
<LLStarks> he accidentally the whole OS
<tjaalton> oh, I got the joke, maybe others didn't? :)
<bryce> tjaalton, btw on upgrading to latest I notice xorg didn't pull in xdiagnose; does it need stronger than Recommends?
<tjaalton> actually pasted the same here 15h earlier ;)
<bryce> it came in once I manually installed it
<bryce> oh wait, maybe latest xorg isn't uploaded yet?
<tjaalton> bryce: it is, and it got installed here though
<bryce> hmm
<tjaalton> recommends should be enough
<tjaalton> if your apt is configured to install recommended packages (which is on by default since a couple of years)
<bryce> total defaults on this system, fresh install as of 2 days ago
<tjaalton> ok
<tjaalton> I'll check my logs
<tjaalton> ah I had it installed already
<bryce> tjaalton, also git push your xorg
<bryce> well, at least the files all get installed in the right places when xdiagnose is installed
<tjaalton> hmm, let me check, laggy adsl here
<bryce> I'll need to run through and doublecheck that their hooks are still functioning... but next week
<bryce> thanks again for all your help with transitioning it btw
<tjaalton> np, and sorry if I didn't push it :P
<tjaalton> on my laptop atm, and can't access the main box which is back home
<bryce> it's just fun to bug you about it for a change ;-)
<tjaalton> hehe, I bet :)
<tjaalton> yeah i pushed libx11 and libxi but forgot to push xorg, gah
<tjaalton> doing those at the same time, not cool
<LLStarks> cdbs, wayland or bust for PP
#ubuntu-x 2011-06-19
<cdbs> Sarvatt: ping
<cdbs> Sarvatt: seems like we need to patch up kdebase-workspace for xorg-edgers oneiric again
<cdbs> Sarvatt: KWin segfaults on xorg-edgers
 * cdbs is running oneiric
<cdbs> and I don't have a connection good enough to download 69 MB of source and upload that again, else I would have done it myself on my PPA and asked you to copy the package
 * cdbs g2g
#ubuntu-x 2012-06-11
<scientes> when can i get mesa 8.1 in xorg edgers?
<RAOF> When it consistently builds, I'd guess :)
<scientes> oh i see
<scientes> wait im looking at the log, and it looks like its building just ine
<scientes> https://launchpadlibrarian.net/107031799/buildlog_ubuntu-precise-amd64.mesa_8.1~git20120606.ec19bdd1-0ubuntu0sarvatt~precise_FAILEDTOBUILD.txt.gz
<scientes> i mean, i don't see an actual error there
<scientes> i'll download it and see if i can coax it...
<RAOF> That'd be because mesa builds in parallel; you need to scroll a long way up, where you'll see that it's failing to find main/dispatch.h
<scientes> oh i see
<scientes> well thats an upstream problem
<scientes> there is no dispatch at all is that source package ;)
<scientes> *dispatch.h
<scientes> needs next git version
<scientes> that file is autogenerated
<scientes> where is the software that checks out from git so i can run it locally?
<scientes> cause i just build mesa from git just fine
<scientes> oh nvm found it
<scientes> ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory
<scientes> fffffffffffffffffff
<scientes> guess you cant run two mesa's at the same time
<tjaalton> mlankhorst: re; -rendition sync, no it can't since the tarballs don't match
<mlankhorst> tjaalton: ?
<mlankhorst> tjaalton: no easy way to force it? :s
<tjaalton> no, until there's a new upstream release, which should happen for 1.13 abi
<mlankhorst> ok, I'll just manually do it then.
<tjaalton> it's called a fakesync when you take the new version but use our tarball
<mlankhorst> with the diff applied it's still the new version then?
<tjaalton> the diff is just the changelog entry
<tjaalton> our diff that is
<tjaalton> so you can take the debian version, bump the revision and build a new package by using our orig.tar.gz
<mlankhorst> ok
<mlankhorst> RAOF: xorg 1.12 https://launchpad.net/~ubuntu-x-swat/+archive/x-staging/+packages almost done when openchrome and ati are rebuilt
<mlankhorst> RAOF: seems to work here with nouveau, I'll try nvidia drivers too
<mlankhorst> ok both work
<RAOF> Woot! Thanks
<mlankhorst> RAOF: is this going into quantal or just for testing? :)
<RAOF> mlankhorst: The packages in the PPA? They'll go into quantal once we've decided that the rest of the madness has settled sufficiently.
<mlankhorst> ok :)
<mlankhorst> RAOF: in fact could we not wait too long due or alternatively release xserver-xorg-video-nouveau from git to debian-experimental, and sync it?
<RAOF> Sorry, I don't quite understand what you're saying.
<RAOF> I think the upshot is that you'd like to sync xservzer-xorg-video-nouveau soon :)
<mlankhorst> yeah, I have a fix in debian's git repo too i want to have
<RAOF> What's libdrm like? The newer nouveau will need the newer ABI, right?
<mlankhorst> RAOF: Oh the debian git has a hack for it
<jcristau> ~ private copy of libdrm-nouveau in the ddx
<RAOF> Sweet.
<mlankhorst> bryceh: Every time I want to leave prime alone some new issue pops up ;)
<stgraber> hey there, just a quick question for you. I'm currently working on the LXC auto upgrade testing backend to replace our slow Qemu backend for quite a few tests. Obviously after upgrading a desktop system, X tries to start and fails as the container doesn't have any video hardware.
<stgraber> that's breaking some of our tests as we kind of like having X around. So I was wondering if there's a way of getting X to start but without any hardware or if I should try to dpkg-divert X to Xvfb instead
<stgraber> (I tend to prefer dumping an xorg.conf file in my upgraded system rather than moving binaries around to make the system think Xvfb is X)
<erappleman> bryceh, regarding the plans to use intel sna in quantal, would hwe take priority over that? airlied expects uxa+nouveau prime offloading to be present in quantal's graphics stack
<RAOF> stgraber: Yes! Install xserver-xorg-{video,input}-dummy in your container's xorg.conf and you'll have a wonderfull headless X server.
<stgraber> RAOF: sweet, thanks!
#ubuntu-x 2012-06-12
<bryceh> erappleman, we'll certainly take any and all exposed issues into account.  SNA is certainly far from set in stone at this point.  I'd suggest writing up a summary of the problem to ubuntu-x@ (or an internal list if it's private info) and we can investigate options.
 * RAOF was under the impression that *sna* was the one that'd get hybrid support. If it's in uxa, then that makes it easy to not care very much about sna.
<bryceh> erappleman, aha just noticed you did send something to the list (sorry, have been on vacation since last thursday)
<bryceh> heya RAOF
<RAOF> Hey bryceh!
<Prf_Jakob> Oh right
<Prf_Jakob> bryceh, RAOF: have you guys packaged up the latest vmmouse release for precise?
<RAOF> I presume 12.8 is not the latest vmmouse?
<bryceh> Prf_Jakob, it'd be in edgers or x-updates if it's been packaged, but no I haven't looked into it myself.
<Prf_Jakob> bryceh: ok, its a stabel release to fix a mouse issue.
<bryceh> Prf_Jakob, if there's a bug # on that, and the fix is a straightforward patch,  we can look at doing an SRU of just that fix.
<bryceh> Prf_Jakob, if you give me a bug # I'll take a look when I'm back at work tomorrow
<Prf_Jakob> 996821
<Prf_Jakob> bug 996821
<ubottu> Launchpad bug 996821 in xserver-xorg-input-vmmouse (Ubuntu Precise) "vmmouse 12.8 behaves erratically in when running as a VMware guest" [Medium,Triaged] https://launchpad.net/bugs/996821
<bryceh> Prf_Jakob, got it, and looks straightforward.  On my todo list for tomorrow.
<Prf_Jakob> Thanks
<Prf_Jakob> You arn't putting stable releases into precise?
<bryceh> on a case by case basis
<Prf_Jakob> ok
<bryceh> I will evaluate if we can do the full -vmware release, and if not will at least work to get the specific patch included
<erappleman> bryceh, you'd have to ask airlied why he's going with uxa. sna is wicked fast on sandy bridge and older gens, but there is no stable release with it enabled by default.
<erappleman> i'm not sure if ddx for either intel or nouveau will have the necessary bits, but a fair amount of the new abi has been incorporated in their respective trees
<RAOF> Wicked fast, but wicked fast at rendering corruption unless you use git.
<erappleman> yup
<erappleman> the trapezoid bug was only just fixed days ago
<erappleman> https://bugs.freedesktop.org/show_bug.cgi?id=48630
<ubottu> Freedesktop bug 48630 in Driver/intel "Progress bars and other dynamic elements do not render properly with SNA enabled" [Normal,Resolved: fixed]
<erappleman> raof, it interfered pretty bad with ambiance theme
<tjaalton> bryceh, Prf_Jakob: i think sarvatt uploaded a new version with a fix to -proposed already
<tjaalton> or maybe not
<tjaalton> bryceh: http://geek-news.mtv.com/2012/06/11/eclipse-board-game/?xrs=share_fb
<mlankhorst> morning
<tjaalton> same
<tjaalton> -intel in debian now has a patch to allow choosing sna over uxa from the conffile
<mlankhorst> I saw :)
<RAOF> tjaalton: I'm going to order eclipse :)
<tjaalton> RAOF: cool :)
<tjaalton> I should too
<tjaalton> and then worry about who to play it with
<tjaalton> but in that order
<bryceh> tjaalton, wow, #6
<mlankhorst> bryceh: more playing around with firmware for prime ;)
<tjaalton> [    5.060204] [drm] nouveau 0000:01:00.0: Unsupported chipset 0xffffffff
<tjaalton> that's fun
<tjaalton> bug 1010838, fails to boot with 32bit, amd64 works
<ubottu> Launchpad bug 1010838 in xorg (Ubuntu) "Ubuntu 12.04 has a problem with my nvidia card" [Undecided,New] https://launchpad.net/bugs/1010838
<tjaalton> mlankhorst: ideas about that one?
<mlankhorst> tjaalton: not a nouveau bug most likely
<tjaalton> ok
<mlankhorst> likely system was messed up  before nouveau was even loaded
<tjaalton> moved over to the kernel
<mlankhorst> it's trying to read out first register and it's 0xffffffff
<tjaalton> hmm, what's the kbd combo again to release input grabs?
<tjaalton> ah disabled by default, of course
<chrisccoulson> are the timestamps associated with X events (eg ButtonPress) in a particular unit? (milliseconds?)
<chrisccoulson> never mind, bryceh just answered for me :)
<cnd> RAOF, could you approve the SRU for -evdev?
<cnd> I uploaded it to precise-proposed last week
<bryceh> tjaalton, could you elaborate on what exactly we need to do for bug 949606?
<ubottu> Launchpad bug 949606 in mesa (Ubuntu) "64 bit dev packages should include 32 bit .so library file" [Medium,Triaged] https://launchpad.net/bugs/949606
<bryceh> tjaalton, also who should own bug 943162?  is that tseliot's area due to the alternatives stuff, or someone else?
<ubottu> Launchpad bug 943162 in mesa (Ubuntu) "libgl1-mesa-dev links libGL.so to mesa/libGL.so which conflicts with nvidia's libGL." [Undecided,Confirmed] https://launchpad.net/bugs/943162
<bryceh> RAOF, bug #994878 is a -savage regression due to no longer shipping its DRI1 drivers in mesa.  I'm guessing this is wontfix since we don't package/support that hardware's 3d drivers anymore; is that correct?  or if not should we consider resurrecting them (since they appear to still work)?
<ubottu> Launchpad bug 994878 in mesa (Ubuntu) "glxgears very slow (no DRI1 drivers anymore)" [Undecided,Confirmed] https://launchpad.net/bugs/994878
<RAOF> Didn't Sarvatt / someone in Debian do some work to get the DRI1 drivers from a separate source package?
<RAOF> I really don't think we need to care very much, but if it's easy there's no reason not to do it.
<bryceh> libgl1-mesa-dri-experimental ?
<RAOF> There was a separate source package involved; it's not libgl1-mesa-dri-experimental
<bryceh> oh, libgl1-mesa-dri-legacy probably
<bryceh> https://launchpad.net/~xorg-edgers/+archive/mesa-legacy
<RAOF> tjaalton: Is there anything arch-specific in libgl*-mesa-dev? If not, they can just be marked Multi-Arch: same
#ubuntu-x 2012-06-13
<tjaalton> RAOF: not sure, probably worth checking it out..
<RAOF> tjaalton: Do you remember if anything is happening with dri-legacy in Debian?
<tjaalton> RAOF: I think tormod was the one working on it, no idea if there are plans to get it in wheezy, for example
<tjaalton> hm, could be a bit late for that too
<RAOF> Yeah.
<RAOF> We could push it straight into Quantal, though.
<tjaalton> true
<RAOF> And fix bug #994878
<ubottu> Launchpad bug 994878 in mesa (Ubuntu) "glxgears very slow (no DRI1 drivers anymore)" [Undecided,Won't fix] https://launchpad.net/bugs/994878
<RAOF> :)
<tjaalton> heh, yeah
<tjaalton> my mom has my old thinkpad with savage..
<tjaalton> don't think she'd notice it missing though
<mlankhorst> RAOF: I keep trying to work on other things than prime but new issues popping up, finding out how to do intel swizzling now else tiled acceleration will fail :P
<RAOF> Everyone's happy to unswizzle in their heads, right?
<RAOF> :)
<mlankhorst> except it swaps blocks of 4x4 pixels :(
<mlankhorst> people want shiny glxgears it seems
<mlankhorst> so having odd and even blocks swapped around seems to not make those people happy, also annoying because it's hard to find :)
<RAOF> I presume you've downloaded the 3D engine documentation?
<mlankhorst> RAOF: It's purely nvidia side beign the issue here
<RAOF> Oh, you need to work out how to get *nvidia* to do intel swizzling?
<mlankhorst> yep
<mlankhorst> I now know far more about internal nvidia tiling layout than I cared for
<mlankhorst> first netboot image I made seems to work, wanted to have a bunch for precise/quantal/sid amd64/i386 
<mlankhorst> RAOF: it's so frustrating though, intel's mapping hides tiling on the cpu, so I can verify the y tiling looks *EXACTLY* like I expected it to :p
<RAOF> :)
<mlankhorst> so I fear there might indeed be a tiling mode for it
<mlankhorst> ugh storage mode*
<Prf_Jakob> RAOF: Oh btw, what are your Wayland plans for the next release?
<Prf_Jakob> And what do you guys plan to do about cards with no 3D.
<mlankhorst> what cards don't support at least modesetting?
<Prf_Jakob> We support modesetting but depending on User config not 3D.
<Prf_Jakob> (Ubuntu as a VMware Guest)
<tjaalton> we have llvmpipe as the fallback
<tjaalton> though unity3d is blacklisted there
<tjaalton> or should be
<Prf_Jakob> But you guys are dropping Unity2D?
<Prf_Jakob> Will you guys fix llvmpipe?
<tjaalton> Prf_Jakob: unity should migrate to clutter, which should work better with llvmpipe?
<tjaalton> or do you mean the current performance issues
<kion> Hello everybody I installed the repository "sudo add-apt-repository ppa:ubuntu-x-swat/x-updates" but my nvidia driver is not actualized
<mlankhorst> RAOF: I may not have found the secret to intel tiling yet, but proving mwk wrong is way more fund than I had hoped for today :)
<mlankhorst> or seems not so wrong, just rediscovered something missing
#ubuntu-x 2012-06-14
<mlankhorst> morning
<RAOF> Yo yo!
<mlankhorst> no luck yet, did manage to scan for all storage modes yesterday and rediscovered some missing in the enumeration :P
<mlankhorst> need something else to do for today, any suggestions?
<tjaalton> nouveau bugs? :)
<mlankhorst> I mean, something not nouveau so I can focus my mind on something else then try with fresh view in a few days
<tjaalton> server bugs then
<RAOF> Yeah, server bugs are often good.
<mlankhorst> hm, do we have that evdev and synaptics memory corruption sru'd yet?
<tjaalton> it's not in quantal even
<tjaalton> i think
<mlankhorst> yikes
<tjaalton> no wait
<tjaalton> different thing maybe
<RAOF> What was the synaptics memory corruption?
<RAOF> Dear mesa: kindly build, love, Chris.\
<tjaalton> RAOF: 8.0.3? builds here
<tjaalton> or built
<RAOF> 8.1
<tjaalton> ahh
<tjaalton> no comments
<mlankhorst> RAOF: the one where X dies a slow death, or sudden death on unplug :)
<RAOF> I think the -evdev one which was that got accepted, didn't it?
<tjaalton> was it the silent abi change?
<mlankhorst> yeah might, but basically all patches from xf86-input-synaptics 1.6.2
<tjaalton> or where it looked like one
<RAOF> I *think* it ended up being miscompiled code on i386 under certain circumstances?
<tjaalton> yeah that
<RAOF> tjaalton: Incidentally, do you have any idea what 101_mesa_hidden_glname.patch is *for* ?
<mlankhorst> RAOF: do we have plans to sru synaptics 1.6.3 yet? haven't seen any reports of regressions in quantal with it
<RAOF> It's not on my TODO list; this is something that you could usefully do today, if you wanted :)
<mlankhorst> i want to move synaptics to 1.6.2 first, since it basically is. Only thing lacking is the 2 version changing commits.
<tjaalton> RAOF: looks like we've lost all the history before 8.0-rc2..
<tjaalton> oh it goes way back
<RAOF> tjaalton: The earliest reference I can find to it is in your changelog from 7.1~rc1
<RAOF> Although you don't seem to have known what it did then :)
<tjaalton> neither did kyle mcmartin five years ago
<tjaalton> in 6.5.3-1u1
<tjaalton> so, DEP-3 has a true purpose :P
<mlankhorst> drop it for quantal ? :>
<RAOF> As far as I can tell that would break ABI by hiding a symbol that was previously unhidden.
<RAOF> On the other hand, I have absolutely no idea what anyone would *do* with that symbol.
<tjaalton> http://old-releases.ubuntu.com/ubuntu/pool/main/m/mesa/mesa_6.5.1~20060817-0ubuntu3.diff.gz
<tjaalton> back in the golden days there was no patch-system..
<tjaalton> being used
<tjaalton> ah, not true. but that change was done directly to the source it seems..
<mlankhorst> later than in dapper?
<tjaalton> looks like I put that in a patch Feb 21st '07
<tjaalton> and no comment about why it was there
<tjaalton> mlankhorst: right, it was introduced in edgy
<tjaalton> but reading between the changelog lines..
<tjaalton> might just as well been a temporary hack that remained in the package
<RAOF> It doesn't do anything to x86-64. I think we can probably drop it in quantal and see if anything explodes. I don't think it will.
<tjaalton> yeah
<mlankhorst> well, i ran dapper fine without it ;)
<RAOF> You know what would be *totally awesome*? If make wasn't saying âno target to make dependâ.
<mlankhorst> didn't it use 'makedepend' ? :P
<RAOF> Ah, no.
<RAOF> It turns out that if makedepend doesn't work, it says âNo rule to make target dependâ
<RAOF> Because it's GODDAMNED RIDICULOUS, that's why.
<mlankhorst> RAOF: btw I'm still RE'ing even if to the casual observer it may look like I'm preparing synaptics 1.6.2 (just a version bump, we already have all the patches)
<RAOF> If we've already got all the patches why are we getting the version bump?
<mlankhorst> RAOF: shrug, there will probably be a new release at one point, i need to get my mind off reverse engineering for a bit so I can subconsciously process information and think of things you cant when staring too long :)
<RAOF> Fair enough :)
<mlankhorst> plus it was just merging debian and dropping the patches-that-were-commits series
<RAOF> Fair enough.
<RAOF> Mmm. Hardlinks.
<RAOF> JUST TO MAKE IT MORE DIFFICULT.
<mlankhorst> 'thou shalt not built from tmpfs with package on a real fs'?
<RAOF> No, in this case âbe careful when editing files in ./build/dri, because they're hardlinks to files in ., and different editors will break those hardlinks.
<RAOF> GrrrrAAAAARCGH!
<mlankhorst> I build intree with git anyhow :)
<mlankhorst> mesa make clean is broken enough to justify using git clean instead
<RAOF> Well, you're *required* to build mesa in-tree; out of tree builds are broken.
<RAOF> ...that's retarded.
<mlankhorst> there's another build system you can use too
<mlankhorst> scons iirc
<RAOF> Yeah, but we don't use that. And I'd be surprised if it isn't a bit broken.
<RAOF> So, make can't seem to determine that a rule for main/api_exec_es1.c can be used to make ../../src/mesa/main/api_exec_es1.c
<mlankhorst> I'm pretty sure out of tree shouldn't even be attempted atm unless you want to fix things
<RAOF> That's what I'm doing now; attempting to fix things.
<RAOF> Because we'll probably want 8.1, and that means we'll want out-of-tree to work.
<mlankhorst> hm, where can I see the stable queue for 3.2.21?
<mlankhorst> stable-queue.git doesn't list it
<jcristau> probably not started yet
<RAOF> Oh, man. Out-of-tree builds are so utterly broken.
<tjaalton> mlankhorst: git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
<tjaalton> but nothing there yet
<tjaalton> I'll add some commits though
<mlankhorst> multi arch is funny, took a bit to figure out how to install libdrm2 amd64
<Sarvatt> RAOF: that problem is because of galliumcore
<Sarvatt> RAOF: dget -u -x http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/m/mesa/mesa_8.1~git20120529.f92b2e5e-0ubuntu0sarvatt.dsc , that was the last time mesa built
<Sarvatt> llvmcore was broken because of https://bugs.freedesktop.org/show_bug.cgi?id=49504 , now it fails with https://bugs.freedesktop.org/show_bug.cgi?id=50604
<ubottu> Freedesktop bug 49504 in Mesa core "[Bisected] Mesa master compilation broke when built with --with-llvm-shared-libs" [Normal,New: ]
<ubottu> Freedesktop bug 50604 in Mesa core "[compile error] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory" [Critical,New: ]
<aissen> Sarvatt: is there a reason your cedarview ppa is private ?
<Sarvatt> aissen: i got asked to delete it, the packages are going straight into precise in the next few days though
<aissen> Sarvatt: alright !
<aissen> Sarvatt: I tried it on two different hardware (D2500 and N2600), and I only have a black screen on X startup.
<aissen> Sarvatt: will there be an updated version from the latest code drops ?
<Sarvatt> aissen: if you're using ubuntu you need to remove vt.handoff=7 from the kernel command line to get around that, can do GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub and update-grub to do it
<Sarvatt> sysrq-v works too, or vt switch and stop/start the dm
<aissen> Sarvatt: thanks
<aissen> Sarvatt: the screen is filled with garbage. Even the "kms" side doesn't work, it doesn't seem to find the right refresh rate.
<aissen> Sarvatt: yes, I'm on ubuntu, running precise
<Sarvatt> aissen: unity 2d or gnome fallback session instead of unity or gnome-shell
<Sarvatt> aissen: arent these drivers fun? :P
<aissen> Sarvatt: yeah I love that :-)
<Sarvatt> 2d deceleration, broken GL support, but video acceleration works ok
<aissen> Sarvatt: how can I enable unity 2d ? Isn't the problem at the modesetting level, since the display is already scrambled before X starts ?
<Sarvatt> its scrambled on the lightdm login screen?
<aissen> yes
<Sarvatt> err, thats a new one
<aissen> I could "find" unity 2d choice in lightdm, but I'm guessing this won't help much
<aissen> let me try on the other hardware (D2500) the grub options, I'll tell you if it helps.
<Sarvatt> aissen: are you using your own kernel? you dont have psb_gfx loaded right?
<aissen> Sarvatt: nope, clean precise install.
<aissen> Sarvatt: let me check.
<Sarvatt> did you dkms the kernel patch or something?
<aissen> hum, I installed the dkms package from your ppa - wrong move ?
<aissen> cedarview-drm
<Sarvatt> oh yeah
<Sarvatt> that wont work
<aissen> oh, ok.
<rohan> hello.. anyone here from the x-swat x-updates ppa team?
<mlankhorst> yes?
<rohan> mlankhorst: I was wondering about the 295.59 nvidia driver -- has it been deliberately kept to the 259.3x version due to some issue? 
<mlankhorst> 259?
<rohan> sorry, 295.3x
<mlankhorst> think there were some regressions indeed :)
<rohan> ah.. looks that way, because even the page here http://www.nvidia.com/object/unix.html lists 295.53 as the latest
<rohan> i hope it's resolved soon because the .53 version doesn't support my card
<tjaalton> which is.. ?
<rohan> PCI ID 0fd3 
<rohan> GT 640M LE
<tjaalton> it's up to nvidia to provide that
<rohan> yes, I realise :) I know it's not something x-swat / x-updates can fix :) 
<rohan> It looks like 295.59 was supposed to be a "long-lived branch release".. i can't imagine how they could release it with regressions!
<tjaalton> there was a security fix that broke stuff
<rohan> I see, thank you, tjaalton , mlankhorst 
<rohan> I will wait for the next iteration 
<tjaalton> nvidia-current is at 295.40, nvidia-current-updates at 295.49
<mlankhorst> plus it didn't fix the gaping hole :(
<tjaalton> ah that
<rohan> mlankhorst: which gaping hole? [just curious]
<tjaalton> oh now there should be 295.59
<mlankhorst> rohan: from what i read from the patch, it seems whole io space is open to user
<tjaalton> with support for 640m le
<mlankhorst> now whole io space minus 100kb is
<tjaalton> http://www.nvidia.com/object/linux-display-amd64-295.59-driver.html?ClickID=d2mtm2tsoxksbkobmcnznsx20bn22ytbcymy
<rohan> [10:17] <tjaalton> nvidia-current is at 295.40, nvidia-current-updates at 295.49 ==> are we looking at different repos? I am looking at the x-updates PPA and the version of nvidia-graphics-drivers is 295.53
<tjaalton> ah
<mlankhorst> ftp://download.nvidia.com/XFree86/patches/security/CVE-2012-0946/nvidia-blacklist-register-mapping-290-295.diff
<ubottu> The NVIDIA UNIX driver before 295.40 allows local users to access arbitrary memory locations by leveraging GPU device-node read/write privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0946)
<rohan> yes, but isn't 295.59 the one with the security hole?
<tjaalton> it's the latest of the series..
<mlankhorst> look at that patch.. there is no reason for userspace to map ANY register from the device in that range..
<mlankhorst>      if (IS_REG_OFFSET(nv, NV_VMA_OFFSET(vma), NV_VMA_SIZE(vma)))
<tjaalton> so if they all are affected then yes
<mlankhorst> that whole branch needs to be removed if nvidia cared about security
<tjaalton> is it fixed in 302?-)
<mlankhorst> nope
<tjaalton> heh
<rohan> [10:19] <mlankhorst> now whole io space minus 100kb is ... ?
<rohan> oh you were referring to the patch you linked? 
<mlankhorst> yeah that was their 'fix' turns out userspace needed it so it broke on a few
<rohan> oh this 'fix' is what's holding 295.59 up? 
<rohan> I guess that's also why they removed it from the main download page
<tjaalton> no
<tjaalton> the hole is old
<rohan> yes, but the fix is breaking userspace, like mlankhorst said, right? or am I just not following? 
<mlankhorst> it's in all nvidia drivers ever released up to 295.40, and even there still open. :S
<rohan> so does 295.59 fix it, and by fixing it, cause issues? or were the regressions you mentioned separate?
<mlankhorst> i cant say since i dont look into nvidia drivers
<tjaalton> they tried to fix it in .40, which caused issues, and at least some got fixed later
<tjaalton> aiui
<rohan> ah i see
<rohan> guess my best option atm is just wait, then :) 
<mlankhorst> there's no point in just updating for the sake of updating
<tjaalton> right, but .59 adds support for 640mle..
<tjaalton> and a bunch of other cards
<mlankhorst> that's a valid point :)
<rohan> so should i file a request or just wait?
<tjaalton> tseliot probably has it on his todo-list already
<tseliot> yep
<tjaalton> :)
<rohan> great, thank you :)
#ubuntu-x 2012-06-15
<rohan> hi.. can someone here help me build a debian of the latest nvidia driver?
<rohan> i have to test something for the bumblebee devs
<bjsnider> rohan, i'll be sending that into x-updates pretty soon
<bjsnider> you can just copy it
<rohan> bjsnider: oh awesome :)
<rohan> i'll wait for a heads up from you then
<rohan> i have x-updates repo enabled
<rohan> i want to enable palm detection for my synaptics touchpad
<rohan> what is the correct place to put the config?
<rohan> /user/share/X11/xorg.conf.d ?
<rohan> or /etc/X11/xorg.conf.d?
<RAOF> Or /etc/X11/xorg.conf
<rohan> RAOF: but what is the preferred location?
<RAOF> Anywhere under /etc/ is fine; xorg.conf is simple.
<rohan> i read the man page, but i am not too clear -- is /etc/X11/xorg.conf read first, and then the files under xorg.conf.d and in /etc/ and /usr?
<RAOF>  /etc/X11/xorg.conf is authoritative; anything in there overrides everything else.
<rohan> yes, but is it mutually exclusive? 
<RAOF> Other than that /usr/share/xorg.conf.d is overridden by /etc/X11/xorg.conf.d
<rohan> guess i'll just have to try 
<RAOF> Oh, in case I wasn't clear: Anything in /etc/X11/xorg.conf overrides anything in /etc/X11/xorg.conf.d, which overrides anything in /usr/share/xorg.conf.d.
<RAOF> So xorg.conf â etc/xorg.conf.d â usr/xorg.conf.d is the priority order. Sticking your configuration in /etc/X11/xorg.conf is perfectly reasonable.
<rohan> so just 3 lines having an inputclass and identifier, and endsection, is enough, right?
<rohan> or do i need to put in a prototype xorg.conf which has sections for monitor, graphics card, etc?
<Sarvatt> rohan: http://paste.ubuntu.com/1041775/ as /etc/X11/xorg.conf
<rohan> thank you so much! Sarvatt 
<Sarvatt> rohan: may be easier to just install gpointing-device-settings
<rohan> oh but that's a gnome thing right.. i tried finding the same setting in kubuntu ksynaptics
<rohan> but no luck
<Sarvatt> many more synaptics options in there than the gnome touchpad settings
<rohan> i guess i'll install that utility
<Sarvatt> oh gotcha
<Sarvatt> yeah not sure about synaptiks
<rohan> yeah i hate how gnome thinks i want to scroll only by using edge or two finger .. no way to enable both
<Sarvatt> the guis are all lacking, doesn't help possible synaptics touchpad settings change all the time :( synaptiks in kde is broken with what will be xf86-input-synaptics 1.7 because things were removed
<rohan> ah i see
<rohan> are they expected to have a stable interface?
<Sarvatt> well synaptiks was just unconditionally expecting options to exist, but the huge amount of untested options were making the synaptics driver unmaintainable so they were removed by the maintainer (stuff like circular touchpad support that was only ever used on one laptop 8 years ago)
<Sarvatt> bug #1002736 may be a problem in kde in 12.10
<ubottu> Launchpad bug 1002736 in synaptiks (Ubuntu) "[xorg-edgers] Synaptics driver crashes KDE touchpad control module" [Undecided,Confirmed] https://launchpad.net/bugs/1002736
<bjsnider> what is bumblebee again?
<rohan> it supports hybrid graphic switching on linux
<rohan> http://bumblebee-project.org/
<rohan> which i currently can't use because nvidia 295.53 doesn't support my card [gt 640m le]
<tjaalton> bryceh: please push your xkb-data changes to git :)
<mlankhorst> morning
<RAOF> Good morning!
<RAOF> Woot! We have a functioning system-compositor-scratchpad!
<tjaalton> what's that?
<mlankhorst> i dont know, but we have it
<tjaalton> woot!
<tjaalton> :)
<tjaalton> bryceh: thanks :)
<mlankhorst> i get to debug firmware some more, figure out why accel isn't working on d9
<seb128> hum
<seb128> Xephyr segfaults for me on precise :-(
<seb128> Backtrace:
<seb128> 0: Xephyr (xorg_backtrace+0x37) [0xe3a107]
<seb128> 1: Xephyr (0xc9b000+0x1a2e8a) [0xe3de8a]
<seb128> 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xf3640c]
<mlankhorst> sweet, pandaboard arrived
<bjsnider> RAOF, you're on phoronix's front page again. i guess all the work you do is going to be big news from now on
<Sarvatt> Prf_Jakob: vmware.h needs an #include "compat-api.h" also after the port to the new compat API change
<Sarvatt> ../../src/vmware.h:180:5: warning: implicit declaration of function 'xf86ScreenToScrn' [-Wimplicit-function-declaration]
<Sarvatt> ../../src/vmware.h:180:5: warning: nested extern declaration of 'xf86ScreenToScrn' [-Wnested-externs]
<Sarvatt> ../../src/vmware.h:180:5: warning: return makes pointer from integer without a cast [enabled by default]
<Sarvatt> Function `xf86ScreenToScrn' implicitly converted to pointer at ../../src/vmware.h:180
<Sarvatt> ubuntu buildds wont allow the upload on amd64 with that, adding the include fixes it
<Sarvatt> sent it to xorg-devel at any rate
<Prf_Jakob> Sarvatt: 
<Prf_Jakob> thanks
<Prf_Jakob> Sarvatt: pushed
<Prf_Jakob> Thanks again
<mlankhorst> bryceh: i love how i can tell blob arm drivers work because of graphical glitches :)
<bryceh> mlankhorst, :-)
#ubuntu-x 2012-06-17
<tjaalton> http://www.youtube.com/watch?v=MShbP3OpASA&feature=youtu.be&hd=1&t=48m9s
<tjaalton> oh it was on phoronix too..
<bryceh> tjaalton, :-)
<mlankhorst> highly regarded by many?
<mlankhorst> wat
<bjsnider> linus never engages in overblown rhetoric
<bjsnider> this is an unprecedented outburst
<mlankhorst> I haven't checked what linus said yet because it seems to have troubles streaming that video, but I'll probably agree with it
<bryceh> mlankhorst, it's worth watching.  phoronix has a written summary (and animated gif in the comments)
<tjaalton> didn't know there was going to be a public speech.. would've been there otherwise :/
<bryceh> tjaalton, yeah rare opportunity
<mlankhorst> he tends to not want to give public speeches
<inetpro> good evening
 * inetpro just installed Kubuntu 12.04 on a laptop with nVidia Corporation GT215 [GeForce GTS 360M]
<inetpro> still having the same issues as logged on launchpad at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436
<ubottu> Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] " [Undecided,Confirmed]
<inetpro> in fact not exactly the same, I now can no longer get the nVidia driver installed as I did back then on Oneiric
<inetpro> xserver-xorg-video-nouveau is installed
<inetpro> anyone here willing to help?
<mlankhorst> no sign of nouveau in that dmesg :/
<mlankhorst> and it's late so ill probably sleep soon
<inetpro> mlankhorst: yep and still no sign of it even in the new installation
<mlankhorst> i mean you link a nouveau bug but no sign of you using nouveau..
<inetpro> hmm... how do I ensure that I use the nouveau driver?
<mlankhorst> did you manually install nvidia drivers?
<inetpro> it's an option in Kubuntu after installation where I can install Additional drivers
<inetpro> I tried that after starting the system with nomodeset
<mlankhorst> I need the output from 'dmesg' after you boot without nomodeset..
<inetpro> but that installation fails with many errors in /var/log/jockey.log
<inetpro> I can not read the screen without nomodeset... just black and white blocks all over
<bjsnider> nouveau doesn't work with nomodeset
<inetpro> hang on let me see whether I can get to the console
<bjsnider> http://www.nvnews.net/vbulletin/showthread.php?t=184447
<bryceh>  http://www.nvnews.net/vbulletin/showthread.php?t=184449
 * inetpro is back
<inetpro> can't even get to the console 
<bjsnider> linus sure knows how to stir the pot
<bjsnider> it's not really scientific to have people post "i hate nvidia because of this specific problem i once had"
<bjsnider> why is dch tagging everything for quantal?
<mlankhorst> inetpro: can you ssh?
<mlankhorst> bryceh: I agree with linus only on the video drivers, but yeah linus loves to make grand statements, funny how nvidia can't handle it and how linus already addressed that in his interview
<inetpro> mlankhorst: ok, I got nvidia running properly now
<inetpro> after installing linux-headers-3.2.0-25-generic-pae
<mlankhorst> inetpro: I can't help with nvidia, I can only help with nouveau, so if you can set up ssh :\
<mlankhorst> if not.. dno
<inetpro> unfortunately it's just before midnight here in South Africa
<mlankhorst> same here
<mlankhorst> wel trusten
<inetpro> I'll try to take it further tomorrow evening if time permits
<inetpro> thanks for the help
#ubuntu-x 2013-06-10
<YoBoY> hi, since my last update my unity is slow on its visual effects (alt+tab, dash, â¦) and my computer is over-heating. I can see the last update concerned packages like  randr, mesa, glxâ¦ and also the kernel. Someone can help me to find the problem and fix it ?
<tjaalton> YoBoY: on saucy? upgrade again
<tjaalton> new mesa available
<YoBoY> raring
<tjaalton> ah, running -proposed then?
<mlankhorst> tjaalton: hm, did you upload the fix to -proposed too?
<tjaalton> yes, but not accepted yet
<YoBoY> I'm already on proposed
<tjaalton> right, you got the broken version
<mlankhorst> ah indeed
<tjaalton> so downgrade mesa or wait for the new one to hit proposed
<YoBoY> soon ? ^^"
<mlankhorst> RAOF: ^
<tjaalton> poke #ubuntu-release I guess
<mlankhorst> yeah try that
<YoBoY> how I can downgrade mesa ? (this can help me in the future :p)
<tjaalton> no easy way
<tjaalton> more or less manual
<YoBoY> yesâ¦ didrocks told me that tooâ¦ ^^"
<tjaalton> YoBoY: you have ivybridge?
<YoBoY> something like that yes
<YoBoY> http://www.asus.com/us/Notebooks_Ultrabooks/ASUS_ZENBOOK_UX32VD/#specifications << this computer on i7
<tjaalton> yup, ivb
<YoBoY> :)
<YoBoY> soâ¦ i'm going to poke #ubuntu-release :)
<YoBoY> thanks everyone, it's always good to know this bug have a fix on its way :)
#ubuntu-x 2013-06-11
<seb128> tjaalton, mlankhorst: hey, do you know if there are any know "image corruption issue" with the new intel in saucy? it seems a bit similar to the sna one during raring but easier to trigger
<tjaalton> seb128: I haven't noticed anything
<tjaalton> what hw, what app?
<seb128> i5 (ironlake?), firefox
<seb128> quite similar to the one I pinged you about in raring
<seb128> when you told me to try without sna (iirc)
<seb128> I should perhaps try that again :p
<tjaalton> yeah could be the same/worse
<seb128> :-(
<seb128> do you know if anyone is working on those issues upstream?
<tjaalton> but maybe file a new bug against -intel if it's easier to hit
<tjaalton> ickle should be
<tjaalton> he also monitors the incoming bugs
<seb128> bug on launchpad or fdo?
<tjaalton> lp is fine
<seb128> I've the issue on every second tab opening in firefox
<seb128> on the tab summary grid
<tjaalton> with a screenshot of the corruption in case it's not the same afterall
<seb128> but also in chromium url bars
<tjaalton> ah
<seb128> and some other places
<tjaalton> so it got worse with the -intel update?
<mlankhorst> hm I doubt they would have released a new version if they thought it caused a regression, so just check for bugs
<mlankhorst> or file one :)
<tjaalton> it could be further fallout from copy-on-write support
<tjaalton> which happened in 2.21.7
<tjaalton> raring has .6
 * mlankhorst appears to be hitting some regression with nouveau atm, no fun :/
<seb128> tjaalton, yes, I had it once a day in raring, in saucy I can trigger it in 1 min
<tjaalton> i have occasional corruption with terminator, but not in other apps
<seb128> shrug, got another of those compiz-lock when coming back from guest
<tjaalton> yeah still there :/
<tjaalton> should be traced
<seb128> tjaalton, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1189850 and https://launchpadlibrarian.net/142156716/corruption.png
<ubottu> Launchpad bug 1189850 in xserver-xorg-video-intel (Ubuntu) "saucy has frequent image corruption (intel, sna)" [Undecided,New]
<tjaalton> seb128: thanks
<seb128> tjaalton, it doesn't happen with uxa, I added a comment saying that
<tjaalton> ok
<mlankhorst> finally, isolated those nouveau lockups to a single missing flush :/
<tjaalton> hmm, are new driver uploads pushed to both main repo and staging now?
<tjaalton> I see the same -intel version on both
<tjaalton> guess it's ok, just needs a new bump when copying to the archive
<tjaalton> mlankhorst: you didn't remove test/tearing.mp4 from -intel?
<tjaalton> heh, ppa didn't have the same version.. of course
<bjsnider> tjaalton, is there a way i can test if i'm using sna?
<jcristau> grep -i sna /var/log/Xorg.0.log
<mlankhorst> tjaalton: build fails if I don't remove it, so I remove it everytime
<tjaalton> mlankhorst: so need to remove it from the branch
<mlankhorst> is the file from upstream? if so probably harmlless to keep
<mlankhorst> we have to do the same for libdrm anyway
<tjaalton> still one thing to remember every time
<tjaalton> with libdrm it's different
<mlankhorst> shrug, we could ask upstream about it ;)
<tjaalton> I did
<tjaalton> if it'll get on the tarball for the next release then it's not an issue
#ubuntu-x 2013-06-12
<hyperair> Sarvatt: http://paste.debian.net/9844/ <-- argh!
 * hyperair has reached DISPLAY=:26 already.
<hyperair> at least it doesn't hang the entire kernel now though.
<mlankhorst> good morning!
<hyperair> DISPLAY=:27. yay!
<hyperair> average time to failure of X session: 1 hour.
 * hyperair flips a table
<hyperair> what would i do without alt+sysrq+k
<mlankhorst> debugging the issue or find a better way to reproduce it?
<mlankhorst> :>
#ubuntu-x 2013-06-14
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1066599
<maxiaojun> the solution is pretty clear now
<ubottu> Launchpad bug 1066599 in mesa (Ubuntu) "Wine is unable to detect OSMesa correctly when compiling from source" [Undecided,Confirmed]
<maxiaojun> Mesa needs to build twice: one for OSMesa without --enable-shared-glapi, one for the rest with --enable-shared-glapi
<maxiaojun> separate build is done in Mageia and openSUSE, not done in Arch, Debian, Ubuntu
<maxiaojun> anyone?
<mlankhorst> maxiaojun: worksforme?
<maxiaojun> how do you test it?
<mlankhorst> just checking if it's found in configure
<maxiaojun> using wine?
<maxiaojun> wine's test is simple
<maxiaojun> it checks whether libOSMesa has symbol glAccum
<mlankhorst> yeah and the ubuntu-wine packages have libosmesa, afaict...
<maxiaojun> maybe it just bypass the check
<mlankhorst> no they don't..
<maxiaojun> can you show me source package
<maxiaojun> i don't know how to find source package about a ppa
<maxiaojun> http://paste.ubuntu.com/5748753/
<maxiaojun> gcc foo.c -lOSMesa   -lSM -lICE -lXext -lX11 -lm
<maxiaojun> works for you?
<mlankhorst> https://launchpad.net/~ubuntu-wine/+archive/ppa/+sourcepub/3232603/+listing-archive-extra
<mlankhorst> checking for -lOSMesa... libOSMesa.so.6
<maxiaojun> no
<maxiaojun> there is a waring at the end of configure
<maxiaojun> because Ubuntu's libOSMesa is broken according to wine devs
<maxiaojun> can you run ldd on ubuntu-wine's wine?
<maxiaojun> i'm still downloading the deb
<mlankhorst> it dynamically links against it..
<mlankhorst> but it shows up in strings libgdi32.dll.so
<maxiaojun> ?
<maxiaojun> which file(s) in wine packages links libOSMesa ?
<maxiaojun> i cannot find one in ubuntu-wine's amd64 package
<maxiaojun> and can you pass the test i mentioned before, the compile a file test?
<maxiaojun> broken libOSMesa can break native program also as shown in https://bugs.gentoo.org/show_bug.cgi?id=399813
<ubottu> bugs.gentoo.org bug 399813 in Applications "media-libs/mesa-7.11.2: libOSMesa.so undef. ref to_glapi_*" [Normal,Resolved: fixed]
<maxiaojun> and intuitive for OSMesa -- Off Screen Mesa to use pure software GL implementation
<maxiaojun> rather share GL API with GPU (can GPU access memory?)
<mlankhorst> maxiaojun: are you using binary drivers by any chance?
<maxiaojun> not on this box, but gamers are likely to use binary drivers, right?
<maxiaojun> anyway, can you acknowledge the problem now?
<maxiaojun> ?
<maxiaojun> mlankhorst: ping?
<maxiaojun> mlankhorst: i have to leave now, hope that you can take care of this issue and make Ubuntu better
<seb128> tjaalton, mlankhorst: could you one you review the patch on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/1180986 ?
<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]
<mlankhorst> seb128: I'll look at it on monday, today is a free day for me
<tjaalton> same here :)
<mlankhorst> (and probably commit it upstream if its good)
<seb128> tjaalton, mlankhorst: ok, no hurry, thanks
<seb128> enjoy your w.e!
<mlankhorst> i will, i have a barbecue planned and a horseback ride with my sister in the woods here :D
<Sarvatt> ScottK: I know you don't like the aggressive mesa updates, but you do realize the only real changes in mesa at the moment were to fix kwin specifically right?  the aggressive mesa updates are due to waiting for stable releases and new hardware support that is absolutely needed, would it be preferred to get git snapshots in a few months in advance?
<Sarvatt> aka https://bugs.freedesktop.org/show_bug.cgi?id=61554
<ubottu> Freedesktop bug 61554 in Drivers/DRI/i965 "[ivb] Mesa 9.1 performance regression on KWin's Lanczos shader" [Normal,Resolved: fixed]
<ScottK> Sarvatt: I don't like having kwin developers yelling at us.  Honestly, I know it's not all on one side.
 * Sarvatt wishes mesa did real release candidates
<ScottK> My fundamental problem is that whatever the situation is now, when I hear people say, "Trust us, it'll be fine", I don't.
<ScottK> Nothing personal with you guys.  I know you're trying hard to please everyone.
<Sarvatt> I don't see anything that will change personally but that's probably not much of a reassurance, wayland will always be in main, we do maintain it, mesa needs it, mir is just a plugin the same wayland support in it is and won't affect the wayland side
<Sarvatt> I doubt mlankhorst would ever want to break something he uses primarily also (kubuntu) :)
<ScottK> That's good to know.
<mlankhorst> ScottK: but in those cases it's usually upstream, we are just the packagers, is doing everything at the last possible moment better? it reduces the testing matrix immensely just because 1 specific chip of 1 specific manufacturer has problems
<seb128> ScottK, your email seems to lack a bit of fact checking before posting (or it would be good to include details about the issues)...
<mlankhorst> (I am convinced that if we pushed mesa in raring earlier despite performance issues upstream might have tried harder to fix it, now it looks like upstream doesn't care any more, all solutions suck)
<ScottK> seb128: I don't fact check everything I hear from everyone.
<seb128> ScottK, well, you should maybe hold from direct accusations then
<seb128> ScottK, it's not like it was hard to check if an ubuntu source contains patches from Canonical
<seb128> ScottK, easier to listen the haters I guess...
<ScottK> It's easier to trust in people that are working in the broader FOSS community over groups going and doing their own thing without worrying overmuch about the broader impacts.
<ScottK> It may be 3 years, it may be longer, but I'm pretty convinced nothing not driven by Canonical will survive in Ubuntu.
<seb128> ScottK, easier but maybe not better, there is no Mir patch in that source
<ScottK> Not yet.
<seb128> that's a different topic
<seb128> your email suggest that they are already patches in there breaking things
<ScottK> When quantal was released, kwin was in fact broken.
<seb128> not by mir patches for sure
<seb128> there was no mir at this point of time
<ScottK> No, by Ubuntu being really aggressive about what version of mesa being shipped.
<ScottK> Now the good news about that one is we all worked together and fixed it.
<seb128> right, that's a different topic than "your mir patches breaks our compositor"
<seb128> which is pure invention
<ScottK> Anticipation.
<seb128> ...
<mlankhorst> anyway I'm off, this can wait until monday :-)
<seb128> very constructive
<ScottK> mlankhorst: Have a nice weekend.
<seb128> I'm out of it, no point trolling
<ScottK> I'm not the one that decided that Ubuntu had to go off on it's own on common infrastructure.
<ScottK> What's next, a kernel fork?
<seb128> ScottK, I understand you have concerns, but speculation on what could broke and how, worded in a way that suggests it already happened is a bit disappointing from you
<seb128> that's all I've to say
<ScottK> OK
<seb128> I don't plant to reply/argue/feed the troll
<seb128> ScottK, have a nice w.e anyway
<ScottK> I don't think I'm trolling.  I think I'm expressing reasonable concerns that are (while still in the future) a pretty straight line extrapolation from recent history.
 * seb128 calls it a week as well
<seb128> ScottK, I agree with the concerns, I don't agree with the wrong accusations "
<seb128> Upstream kwin tells us they already see bug reports from Kubuntu users due to" ... changes that don't exist
<seb128> I get that the kwin upstreams hate us
<seb128> and decided to fud us
<seb128> it's just a bit sad that you rely those fud in the discussion
<seb128> you could made your point about the concerns you have without fud
<bjsnider> ScottK, it's the CCLA that causes canonical to be so isolated and "not invented here"-ish
<bjsnider> in my view anyway
<ScottK> bjsnider: It's a huge factor.
<ScottK> KDE was looking for a KDM replacement and although LightDM was the best technical solution available, it got rejected specifically because of that.
<seb128> Qt has a CLA and it doesn't block KDE to use it...
<ScottK> Different situation.
<ScottK> To start with, I don't think any of the various owners of Qt have ever solicited code from KDE developers and then retroactively tried to get a copyright assignment and then thrown the code away when the authors wouldn't agree to what was at the time a VERY poorly written document.
<ScottK> In order not to have regressions, we had to add all the thrown away code back as a distro patch.
<ScottK> Talk about pointless waste of effort.
<seb128_> yeah, not saying that Canonical is perfect, maybe there is a bit too much of history there ... and most people in opensource seems rather happy to behave like hates anyway on those topics
<ScottK> Personally, I won't sign a CLA/copyright assignment for anyone unless it's paid work.  I just avoid contributing to things that require it.
<ogra_> so you never contribute to anything owned by the FSF ?
<ScottK> Or once I wrote a bug report that, instead of including a patch (which would have needed a copyright assignment), I said in text, change line xxx from foo to bar.
<ScottK> ogra_: Not so far.
<JanC> copyright assignment for non-paid work is legally dubious in many countries anyway
<JanC> (and, yes, I know that'snot really required anymore by Canonical)
<seb128> JanC, right, that issue is deprecated with the contributor agreement
<seb128> you just give the right to use your code
<seb128> that doesn't change the ownership of the code or limit your rights in any way
<JanC> well, it doesn't limit you rights, but improves Canonical's rights  ;)
<ScottK> seb128: It changes the issue, but doesn't resolve it.  You still end up having less rights to the code base that you contribute to than Canonical.  Some people think that's problematic.
<ScottK> Personally, I'm not signing any contractual agreements that aren't reviewed by my lawyer and I'm not doing that for stuff I do for free.
<JanC> many countries have contract law provisions that protect individuals against companies by requiring proportionality in such a contract
<JanC> I'm not sure they apply to this sort of contract though
<JanC> in any case, it's a fact that a lot of people object to contributing code to projects that require a CLA or similar contract
<seb128> JanC, ScottK: I've no real issue with whoever does 99% of the work having more work that a side contributor doing 1%
<seb128> it is
<seb128> but, well, companies need to make money in some way, there is only so much you can give away
<JanC> seb128, when puttig it black/white, maybe the 99% contributor is just employees working well-paid 9-5, while the 1% contributor is a volunteer spending all his/her free time on it unpaid; that should put some perspective to who really contributes more  ;)
<JanC> (and I know a lot of you work more hours than you really have too!)
<seb128> JanC, right, I'm just thinking that as somebody owning a business you can't afford to get screwed because you gave contributors rights to block change in your projects
<JanC> contributors can never really block a project
<JanC> as long as it stays open source
<seb128> JanC, not really true, if you need to change the license at some point you need the ack of all the copyright holders
<seb128> or to throw out the code of those who refuse
<JanC> and what's also important: you certainly block contributions by other companies
<seb128> well, you have to decide what line you are walking and what you value most
<seb128> I can understand both side
<seb128> but I can understand why somebody putting millions of dollars in a projects want to keep the ability to change the license if needed
<bjsnider> of course
<bjsnider> that argument is not going to move RMS though
<JanC> I can understand why somebody thinks more control is important when spending money, but I'm not sure that's always the best decision  ;)
<seb128> well, I've no strong feeling either way, I understand some people have and I'm fine with Canonical has a company defining the rules that work for them on the projects they invest in
<ogra_> bjsnider, i wouldnt even want to touch RMS ... why do you think anyone would want to move him ?
<seb128> at this end of the day I still think that Canonical does more that most closed sources companies
<seb128> even if they are not perfect
<seb128> it's "funny" how people blame you for "not giving enough" when you are giving time and money away contributing to opensource projects
<seb128> even if Canonical was closed source company and Mir was closed source
<ogra_> get along with it or don't ... raving about it all the time wont change anything 
<seb128> there would still be value in the testing, patches, etc we do on other opensource projects
<ogra_> yeah
<seb128> yet internet comment makes it like Canonical was just stealing and being evil
<bjsnider> that's eseentially what RMS is telling them
<ogra_> yeah, which is nonsense ... and most half way intelligent people i talk to grasp that
<JanC> Canonical isn't stealing (nobody really has to sign the CLA or whatever other contract), but Canonical is losing contributions because they require it, and that is hurting Ubuntu users
<ogra_> the CLA exists since years ... isnt not like it is something new ... but loud complaints only started to happen very recently 
<ScottK> OTOH, everytime someone suggest I fix Launchpad, I say "Sorry, CLA" and they understand, so it's not like it's all bad.
<seb128> it would hurt Ubuntu users more if Canonical went out of business and stopped funding working on Ubuntu
<ogra_> it didnt hurt the ubuntu users for all these years, why does it now ?
<ScottK> ogra_: It's been highly controversial since it was started.
<JanC> ogra_, that sounds like you were out f toh for years...
<JanC> out of touch
<seb128> seems like users are just dreamer
<ScottK> ogra_: Because it applies to more and more of what's in Ubuntu as Canonical increasingly goes it's own way on things.
<ogra_> ScottK, oh, definitely ... i just dont get why it suddely should be more hurtful than it was 3 years ago
<seb128> "would be good if Canonical was just paying people to do free work even if they don't make money"
<ScottK> ogra_: It sucked the whole time.
<bjsnider> yes, i think RMS is basically against profit
<bjsnider> not that canonical has ever made any profit, but it could happen in the future
<bjsnider> depending on the phone market
<JanC> ogra_, if you are only now hearing it, you have been out of touch with the community for years (sorry if that sounds harsh)
<ogra_> ScottK, yes, but it wasnt a widley promoted topic across news sites etc 
<ogra_> JanC, i dont say i am only now hearing it ... i just say it didnt hurt the users 3 years ago more than it does today
<ogra_> yet people behave like it would
<JanC> it has been hurting people for years
<ScottK> Well, the whole topic of Canonical doing it's own stuff, requiring CLA, etc plays very nicely into the "Canonical doesn't contribute" meme that Red Hat pushes.
<ogra_> JanC, i dont think it has hurt my mom in any way, sorry
<ogra_> and she is a happy ubuntu user
<ScottK> They've been on that for awhile, this stuff just makes it easy for them.
<ogra_> neither three years ago, nor today 
<ogra_> sure
<ogra_> we surely feed enoough trolls with it 
<seb128> well, for sure Canonical doesn't contribute much to RedHat project :p
<ScottK> Also, stuff like sending search results even for local searches (AIUI anyway) to Canonical is troubling.
<seb128> they contribute a lot to Canonical projects though
<ogra_> well, people know about it, it is not like it happens secretly 
<ogra_> and it is an essential bit of unity (not sure you have looked at the smart scopes)
<ScottK> There's just a lot of things that make it easy to say bad things about Canonical and overshadow the good parts.
<ogra_> definitely ...
<ScottK> I haven't, but if I can't do a local search without network access, I'd call that a fundamental design flaw.
<ScottK> I'd breach confidentiality agreements in multiple consulting contracts just to use it, in all likelihood.
<ogra_> the new unity largely integrates the internet in everything ... 
<ScottK> Well, I guess if I wanted Chrome OS, I'd install it.
<JanC> I love internet integration, but only when *I* want it  :p
<ScottK> Maybe it's because I'm old, but I think I will always want a clear distinction between what's local and what's remote.
<JanC> and only with the sites I want it
<seb128> you can do local search, just turn off the option in system settings
<ogra_> JanC, well, its part of the concept ... and its not a hidden fact 
<seb128> JanC, in saucy you can select the sources (sites) in the filters
<JanC> not to mention that the default internet integration is utterly useless for most people
<seb128> that's in the ui
<ogra_> if you dont like the concept, reconfigure it or use something else ... its not like there wouldnt be choice enough
<ScottK> seb128: Only because people screamed.
<ogra_> JanC, not on a tablet or phone ;)
<seb128> ScottK, well, they were right, and we got that option at this end
<JanC> ogra_, my phone doesn't do anything I don't want and I have no tablet
<seb128> so not perfect but not the end of the world either
<ScottK> Actually, for me, Ubuntu Phone would be an interesting option if it did give me more control over what went off the device and what didn't compared to Andriod.
<ogra_> JanC, so you dont have an iphone/android phone then, ok
<ScottK> I do have an Andriod phone and am not happy about this kind of thing.
<seb128> reality is that where 95% of the world is going
<ogra_> well, you surely have ful control about the ubuntu phone as you have about an ubuntu desktop with the free images 
<seb128> e.g new xbox announce this week
<JanC> dn't (although with an Android phone you could configure it properly, I guess)
<seb128> it needs to be always connected
<ogra_> i doubt you will have that much contol on a shipped vendor image
<seb128> the mics are always on
<ogra_> and the kinect too :)
<ogra_> you can power it on with a gesture ... so it needs to constantly monitor the room 
<JanC> my dad is a regular ordinary computer/phone/internet user, and he objects against those things too
<ogra_> what does he use on his phone/computer ?
<JanC> (maybe because he once worked/lived/travelled in countries where that sort of information got abused to hurt & kill people)
<seb128> well, I don't like those either, but reality is that the world is moving there and Ubuntu is still a lot better than Google Apple or Microsoft on those topics
<JanC> sure
<JanC> in any case, that has nothing to do with the CLA issue  ;-)
<tjaalton> flowers, rainbows, ponies, kittens and all that.. :)
<tjaalton> will check the thred next week..
#ubuntu-x 2013-06-15
<Sarvatt> hyperair: has it gotten any better?
<Sarvatt> i started only pushing updates to saucy because there was a period of instability but just updated everything when it seemed stable
<hyperair> Sarvatt: yeah, interestingly my gnome-session reports an uptime of 2 days
<hyperair> Sarvatt: after i cleared i915_error_state, it stopped crashing.
<hyperair> i think the issue just doesn't want to be debugged.
<Sarvatt> transient crap from using git, x-x-v-intel went through a lot of churn in the past 2 weeks :)
<Sarvatt> hopefully whats in there now is stable, thanks for telling me it wasnt
<Sarvatt> "lets reenable stuff known to be broken now that we have a release" "oops back it out because of bug reports", that kinda stuff
<hyperair> haha okay
<hyperair> so what was the stuff that is broken?
<hyperair> oddly enough i don't remember having an xxvi upgrade between my last X crash and starting the new X server.
<hyperair> and i don't think xxvi upgrades that come in during an X session actually get applied until you restatr the X server
<Sarvatt> oh so mesa broke you? nope they don't, just 2.21.8+ was broke
<Sarvatt> n
<hyperair> hmm. i'm not sure really.
<Sarvatt> but that was close to a month
<hyperair> there wasn't any X ugprade before the last X restart. all i recall was clearing i915_error_state
<hyperair> so the buggy code should still be running this time.
<hyperair> oddly enough
<hyperair> speaking of which when i tried to cat i915_error_state prior to clearing it, it complained abuot not being able to allocate memory
<Dandel> fun as always... piglit packaging is broken again... amd64 ( and probably i386 also) lacks the piglit python scripts. ( I don't know what else is missing )
<Dandel> Sarvatt, your fix to "fix" the install directories removed a critical feature... the python scripts themselves.
<Dandel> actually... more accurately, the installer places the scripts at /usr/*.py instead of /usr/lib/piglit/*.py
<Dandel> is it possible the install bug is because "40-piglit-install-directories.patch" is not listed in the patch series file?
<FernandoMiguel> what would be the best way to get WebGL working on Chrome with my Intel HD3000?
#ubuntu-x 2014-06-13
<gQuigs> hoping this is the right place for an xorg-edgers question.. I can't get CUDA to work on my nvidia card with xorg-edgers but it did work when I installed the driver from nvidia directly
<gQuigs>  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1320990  <- reported
<ubottu> Ubuntu bug 1320990 in xorg (Ubuntu) "[xorg-edgers] BOINC can't find CUDA driver with xorg-edgers packages" [Undecided,New]
<gQuigs> anyone have any ideas what to try first?  I have  0 CUDA experience.. :/
#ubuntu-x 2015-06-08
<roadapathy> Hello.
<roadapathy> Does any kind developer have the configuration for compiling MESA on Linux? *hopeful smile*
<roadapathy> I wanted to compile Mesa on Ubuntu Linux for many years now but it never works for me. Yet, I can compile almost everything else just fine.
<Prf_Jakob> How do I boot into text mode on 15.04?
<Prf_Jakob> Especially the ISO/USB installer.
#ubuntu-x 2015-06-09
<RAOF> Prf_Jakob: I think you might need the alternate installer for that.
<Prf_Jakob> Upstart to the rescue!
<Prf_Jakob> init=/sbin/upstart text did the trick
<RAOF> Heh.
<RAOF> I don't think you'll be able to *install* from there. Unless this is a precursor to installing some extra driver and then bringing up X :)
<Prf_Jakob> Well Ubuntu 15.04 fails to boot on my MacBooPro5,1
<Prf_Jakob> X fails to start*
<RAOF> Sigh.
<RAOF> How do they manage to make so many revision-specific problems?
<Prf_Jakob> Oth, X now works perfectly with nouveau on my MacBookAir3,1.
<RAOF> And I've just been at a sprint where at least two people had two different MBP revisions that worked fine.
<Prf_Jakob> Both Mac's use Nvidia GPU's booting under EFI.
<Prf_Jakob> The MBP is one of those dual GPU lappys with two nVidia chips.
<RAOF> Ah, *that* vintage.
<RAOF> I'm fairly sure that there has been an Ubuntu release where they worked :/
<Prf_Jakob> (Even OSX can't switch between without restarting the GUI)
<Prf_Jakob> Yeah (Can't remember if I had to use blobs tho)
<RAOF> Woot! 15.04 successfully brings up this dual-AMD laptop, *and* doesn't panic when it decides to turn one of the GPUs off!
<Prf_Jakob> Always something
<Prf_Jakob> Installing nvidia current on the USB disk.
<Prf_Jakob> Lets see if X starts then
<Prf_Jakob> Oh right, wont start with nouveau module loaded.
<Prf_Jakob> I will look into this some more tomorrow, do you guys want a bug report on this?
<RAOF> Yes, please.
<RAOF> But, obviously, no promises :/
<Prf_Jakob> Fair enough :)
<alkisg> Hi, in Ubuntu 12.04.1, the manpage of xprop mentions that it does support "u" (unicode), but when I  try it, it says "bad format" and I have to use "s" instead. In 12.04.5 (newest xorg) it's supported.
<alkisg> apt-get source x11-utils etc => the code does have support for '8u' there
<alkisg> Would that be a bug in xprop that needs some SRU?
<alkisg> Yup, it looks like "case 'u'" is missing from the function Set_Property(), while it's there in all the rest of the code
<alkisg> https://sources.debian.net/src/x11-utils/7.7%2B3/xprop/ChangeLog/ ==> commit 0d069c0edae83f70ac10fab1a3c04d8197e277c4
<alkisg> Enable setting property of type UTF8_STRING.          Fix "bad format character: u" error for format '8u', e.g.:         xprop -root -f _NET_WM_NAME 8u -set _NET_WM_NAME LG3D
<alkisg> Would it be easy to SRU that to 12.04.1 (x11-utils=7.6+4)? 
<alkisg> The upstream commit is at http://cgit.freedesktop.org/xorg/app/xprop/commit/?id=0d069c0edae83f70ac10fab1a3c04d8197e277c4
<tseliot> work_alkisg: it would be a standard SRU. Feel free to file a bug report against that package (describe the problem and how to reproduce it), and I'll be happy to include the change for you (please ping me when you're done)
#ubuntu-x 2015-06-10
<alkisg> tseliot, thank you very much, I filed LP #1463663 and assigned it to you, I'll be around here, ping me if a bzr branch with the patch is needed
<ubottu> Launchpad bug 1463663 in x11-utils (Ubuntu) "[SRU] Enable setting property of type UTF8_STRING" [Undecided,New] https://launchpad.net/bugs/1463663
#ubuntu-x 2015-06-11
<alkisg> tseliot: hi, thanks, I did file an SRU for that issue and I've assigned it to you, is a debdiff branch necessary? LP #1463663
<ubottu> Launchpad bug 1463663 in x11-utils (Ubuntu) "[SRU] Enable setting property of type UTF8_STRING" [Undecided,New] https://launchpad.net/bugs/1463663
<tseliot> alkisg: not really, the git commit is enough. I'll take care of the rest. Thanks
<alkisg> Thank you :)
<tseliot> alkisg: I've just uploaded the package and subscribed the SRU team. It's up to them now
<alkisg> I'll provide whatever feedback's necessary for the SRU verification. On behalf of LTSP users, thanks again! :)
<tseliot> np
<samuraicat> Xsane was scanning fine but all of a suddens started getting "Error during save: Broken Pipe".
#ubuntu-x 2016-06-13
<soee_> NVIDIA has released the 367.27 Linux driver
<mamarley> soee_: I will package it when I get home in a few minutes.
<soee_> mamarley: thanks :)
<mamarley> Argh, why is this always so much harder than it needs to be.
<mamarley> dpkg-shlibdeps: error: no dependency information found for debian/nvidia-367/usr/lib/nvidia-367/libnvidia-fatbinaryloader.so.367.27 (used by debian/libcuda1-367/usr/lib/x86_64-linux-gnu/libcuda.so.367.27)
#ubuntu-x 2016-06-14
<mamarley> ricotz: I packaged 367.27 in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages but this version introduced a new dependency of the CUDA library on libnvidia-fatbinaryloader, so I had to add something to nvidia-graphics-drivers.shlibs.in to account for that.  Since this is the first time I have fooled around with shlibs, I am not sure I did it right.
<mamarley> Also, the armhf build is still broken due to the moved/removed Vulkan ICD file, but since I don't have an ARM system for testing, I wouldn't be able to test any ARM-specific changes that I made.
<ricotz> mamarley, hi, oh, I have a package here as well, didnt expect you being awake yet ;)
<mamarley> I did it yesterday :)
<ricotz> mamarley, will take care of this armhf thing too
<mamarley> OK, sounds good
<ricotz> mamarley, the shlibs looks right, although I would make a bit stricter
<ricotz> "libnvidia-fatbinaryloader #VERSION# #DRIVERNAME# (>= #VERSION#)"
<mamarley> OK.  This was the first time I had ever messed around with that file, so I was genuinely surprised when I got it to work at all.
<ricotz> I guess "man dh_shlibs"
<ricotz> I guess "man dh-shlibs" helps
<mamarley> Yep, I spent about an hour reading various documentation before I finally did get it to package.
<ricotz> of course deb-shlibs
<ricotz> mamarley, did you look for/into a patch for 4.7 yet?
<ricotz> nvm, will add one
<soee> mamarley: this new driver has also this spand fix ?
<mamarley> soee: The original patch for the NVIDIA driver was discarded.  They decided to go with a patch to snapd itself instead, which makes all of us on the Graphics Drivers team very happy. :)
<soee> :)
<ricotz> mamarley, by any chance are you running the mainline kernels?
<mamarley> ricotz: I am indeed, 4.6.2 currently.
<mamarley> But I tested the driver against the 4.4 kernel from Xenial too.
<ricotz> ah was about to ask about that specific one which doesnt behave here
<ricotz> hmm, must be something wrong here then
<ricotz> did you dare to run 4.7rc3 too already?
<mamarley> No, I haven't tried that one yet.  I usually wait until the stable release for kernels.
<ricotz> I usually wait until rc4 to give it a first try
#ubuntu-x 2016-06-15
<est31> question: will 16.10 get mesa 12?
<tjaalton> yes
<est31> nice
 * est31 will be able to try vulkan
#ubuntu-x 2016-06-18
<mamarley> ricotz: When you originally packaged nvidia-367, what changes did you have to make from 364 to get it to work?  I am wondering because I just got an email from a user asking about nvidia-367 for Trusty and since I didn't do the original packaging I'm not sure what would be best as far as a backport.
#ubuntu-x 2017-06-13
<tjaalton> tset
<tjaalton> uh
<tjaalton> tab-complete fail
<tjaalton> tseliot: https://launchpad.net/~canonical-x/+archive/ubuntu/testing has glvnd
<tjaalton> both the lib and mesa built against it
<tjaalton> for artful
<alkisg> tjaalton: hi, I have another school that reports crashes similar to the previous one: http://termbin.com/rah4
<alkisg> In the previous one, I put the staging PPA, and they report it still gets crashes
<alkisg> Where would I file a bug report? Should I include the crash dump or just xorg.log.old?
<alkisg> Is there a point in testing with the intel driver instead of the modesetting one? Can I test that by just putting "driver intel" in xorg.conf?
<tjaalton> upstream
<tjaalton> the intel driver has a stub config in /usr/share/doc/x-x-v-intel/
<tjaalton> could try newer mesa too, ppa:ubuntu-x-swat/updates
<alkisg> Upstream the in modesetting driver? Thank you tjaalton, will do. :)
<tjaalton> xserver
<alkisg> Ah, ok
<tjaalton> just try newer mesa first
<alkisg> OK, will do
<tseliot> tjaalton: great, thanks!
<tjaalton> tseliot: there seems to be some depedency issue preventing upgrade to it
<tjaalton> +n
<tjaalton> hmm works now
<tseliot> ok, good
#ubuntu-x 2017-06-16
<ricotz> mamarley, hi, better be careful with the first thunderbird 55 beta
<mamarley> ricotz: Anything in particular for which to look out?  Or should I just not install it at all?
<ricotz> mamarley, just a heads up since it will be available shortly and might cause trouble with extensions
<mamarley> Thanks!
<Guest22862> tjaalton (IRC): did you need to push mesa to git?
#ubuntu-x 2017-06-17
<tjaalton> which branch?
#ubuntu-x 2018-06-11
<mamarley> ricotz: Sorry I forgot to mention it earlier, but I packaged 340.107 in https://launchpad.net/~mamarley/+archive/ubuntu/staging on Friday.  It adds support for Xorg 1.20!
<ricotz> mamarley, thanks, I haven't noticed this release yet ;)
#ubuntu-x 2018-06-16
<BillGHero> Anyone on right now?
<BillGHero> Anyone know how to pinpoint the reason why the GUI Gnome desktop suddenly does not come up in a system that was working fine for over two weeks?
<BillGHero> Anyone here know why my kernel's running with nomodeset even though that option does not show up in GRUB or modprobe.d/ ?
#ubuntu-x 2019-06-11
<mamarley> ricotz: I have 430.26 in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages, but I couldn't figure out nvidia-settings.  They changed the way XNVctrl is compiled in a way that requires updates to our patches that dramatically exceed my Makefile-fu.
<ricotz> mamarley, thanks, I will take a look
<ricotz> mamarley, https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+sourcepub/10216255/+listing-archive-extra
<mamarley> ricotz: Cool, thanks!
#ubuntu-x 2019-06-14
<ricotz> tseliot, hi, fyi, there is a nvidia-settings 430 package in the gpu-drivers ppa
<ricotz> original tarballs are located at https://download.nvidia.com/XFree86/nvidia-settings/
<tseliot> ricotz: hi, that's on my todo list
<tseliot> ricotz: does it include my new patch for polkit?
<ricotz> tseliot, if you mean 418.56-0ubuntu2, then yes
<tseliot> yes, whatever is eoan
<tseliot> ricotz: uploaded, thanks :)
#ubuntu-x 2020-06-11
<royalewithcheese>                            ____          ____
<royalewithcheese>                           / --.|        |.-- \
<royalewithcheese>                          /,---||        ||---.\
<royalewithcheese>                         //    ||        ||    \\
<royalewithcheese>                        //     ||        ||     \\
<royalewithcheese>                       // __   ||        ||   __ \\
<Duke``> !
<Duke``> millenium falcon ?
