#ubuntu-x 2007-01-03
<Ubugtu> New bug: #76866 in gstreamer "No way to get working video with Intel card & AIGLX desktop" [Unknown,Rejected]  https://launchpad.net/bugs/76866
#ubuntu-x 2007-01-04
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #77945 in xkeyboard-config (main) "Windows key producing <Mod4><Hyper> instead of just <Mod4>" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77945
<Ubugtu> New bug: #77948 in mesa (main) "Slow scrolling with aiglx/compiz" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77948
#ubuntu-x 2007-01-05
<Ubugtu> New bug: #78072 in xserver-xorg-video-vesa (main) "Unusable and poor graphical performance with standard Vesa drivers on LiveCD" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78072
<Ubugtu> New bug: #78109 in xorg (main) "dpkg crashing the system" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78109
#ubuntu-x 2007-01-06
<Ubugtu> New bug: #78228 in xserver-xorg-video-ati (main) "External monitor does not work with radion mobility M300" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78228
#ubuntu-x 2007-01-07
<Ubugtu> New bug: #78293 in xorg-server (main) "libraries get stripped even with debug build" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78293
#ubuntu-x 2007-12-31
<ubotu> New bug: #179472 in xorg (main) "Black screen - wrong monitor detection & refresh rate" [Undecided,New] https://launchpad.net/bugs/179472
<ubotu> New bug: #179503 in xorg (main) "Display problems on Dell Inspiron 1100 laptop" [Undecided,New] https://launchpad.net/bugs/179503
<tjaalton> bryce: I'm unduping the dupes from bug 51991
<ubotu> Launchpad bug 51991 in xorg "Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal." [Critical,Confirmed] https://launchpad.net/bugs/51991
<bryce> tjaalton: awesome
<tjaalton> that was originally reported about nvidia, and now the dupes seem to be about intel
<tjaalton> also the bug has gathered a lot of noise
<bryce> tjaalton: sorry I've been so quiet; I've been using my vacation time to focus on helping shepherd the inkscape release along
<tjaalton> heh, no problem
<tjaalton> I've actually been learning to use blender
<bryce> inkscape 0.46's gonna kick butt :-)
<tjaalton> and inkscape too
<tjaalton> can't wait :)
<bryce> yeah, I noticed how popular driver bugs can accumulate unrelated chaff esp. when improperly described
<bryce> I blame the launchpad dupe checker ;-)
<tjaalton> we just should have less bugs for it to check ;)
<bryce> yeah...
<bryce> I hope to spend some good solid time on bug triage when I get back, but already various requests are piling up
<bryce> I need to get a new libdrm and -psb out for the ume folks; I've gotten rather behind at getting that out
<bryce> also apparently there's issues with -amd that are hindering some other embedded folks, edubuntu, etc.  Not sure how I can help but Mark asked me to take a look
<tjaalton> ok
<tjaalton> too bad that libdrm doesn't have regular releases
<bryce> yeah
<bryce> fun fun :-)
<ubotu> New bug: #179571 in xserver-xorg-video-intel (main) "Xorg crashes on desktop switch when playing video with Xv" [Undecided,New] https://launchpad.net/bugs/179571
<ubotu> New bug: #133430 in xrandr "[gutsy] screen resolution rotation does not rotate wacom" [Undecided,Confirmed] https://launchpad.net/bugs/133430
#ubuntu-x 2008-01-01
<ubotu> New bug: #179675 in xorg (main) "Ubuntu LiveCD doesn't start with a "VIA Chrome9 HC" graphic card and, when Ubuntu is installed, it works only with VESA drivers" [Undecided,New] https://launchpad.net/bugs/179675
<ubotu> New bug: #179701 in xserver-xorg-video-savage (main) "xserver-xorg-video-savage is missing savage_dri.so" [Undecided,New] https://launchpad.net/bugs/179701
#ubuntu-x 2008-01-02
<ubotu> New bug: #179797 in xserver-xorg-video-intel (main) "intel GM965 (X3100) no TV-Out (S-Video)" [Undecided,New] https://launchpad.net/bugs/179797
<ubotu> New bug: #179822 in linux-restricted-modules-2.6.24 (restricted) "[hardy] Enabling xinerama crashes X" [Undecided,New] https://launchpad.net/bugs/179822
<ubotu> New bug: #57338 in xorg-server (main) "Graphic mode is broken (dup-of: 57153)" [Medium,Incomplete] https://launchpad.net/bugs/57338
<ubotu> New bug: #179839 in xorg (main) "shift key overflow locks keyboard" [Undecided,New] https://launchpad.net/bugs/179839
<tjaalton> whee, soon all the xorg-server bugs fit on one page (ie. less than 75 bugs) \o/
<ubotu> New bug: #174156 in xorg (main) "mouse pointer disappears in hardy" [Undecided,Incomplete] https://launchpad.net/bugs/174156
<ubotu> New bug: #158482 in xorg (main) "Wrong Live CD resolution" [Undecided,Incomplete] https://launchpad.net/bugs/158482
<ubotu> New bug: #159764 in xorg (main) "kubuntu / xubuntu 7.10 cannot start X, find wrong PCI slot" [Undecided,Incomplete] https://launchpad.net/bugs/159764
<ubotu> New bug: #73606 in xorg (main) "Ubuntu automatically X server configuration" [Wishlist,In progress] https://launchpad.net/bugs/73606
<bryce> tjaalton: whoa, you've been busy!!
<bryce> tjaalton: calc says he's getting a backtrace when enabling xinerama with nvidia which he didn't have pre-break - was there an upload of -nv or lgm recently?
<tjaalton> bryce: lgm? you mean lrm? I've prepared a new lrm with new nvidia & ati, but haven't uploaded it
<tjaalton> there is a bug report about xinerama & nvidia crashing on gutsy, and today someone reported that against hardy
<bryce> yeah sorry lrm
<bryce> ah, bet that's it
<bryce> I've asked calc to file a bug, I'll let you know when he tells me the bug id#
<bryce> I also notice there's a new -ati 6.7.197-1?
<tjaalton> and a sync request, yes
<tjaalton> bug 144777
<ubotu> Launchpad bug 144777 in xorg-server "xinerama xserver crash" [Undecided,New] https://launchpad.net/bugs/144777
<tjaalton> that reporter claims that some patch breaks it
<bryce> ah 
<tjaalton> bug 179822
<ubotu> Launchpad bug 179822 in linux-restricted-modules-2.6.24 "[hardy] Enabling xinerama crashes X" [Undecided,New] https://launchpad.net/bugs/179822
<tjaalton> that's the hardy version
 * bryce passes along
<bryce> hmm, however the backtrace calc posted looks different
<bryce> <calc> Backtrace:
<bryce>  0: /usr/bin/X(xf86SigHandler+0x6a) [0x483d5a]
<bryce>  1: /lib/libc.so.6 [0x2b099b4e6100]
<bryce>  2: /lib/libc.so.6(realloc+0x79) [0x2b099b52bd79]
<bryce>  3: /usr/bin/X(Xrealloc+0x1b) [0x56753b]
<bryce>  4: /usr/bin/X [0x4bdde9]
<bryce>  5: /usr/lib/xorg/modules/drivers//nvidia_drv.so [0x2b099e1ae7a3]
<bryce>  that was the backtrace it gives when enabling xinerama
<tjaalton> ok
<tjaalton> hum, ice cream :) ->
<tjaalton> (and Heroes.. S01E10 or so :P )
<bryce> tjaalton: did you see the dec22 comment here about fglrx incompatibiltiy on hardy?  http://lwn.net/Articles/263048/#Comments
<bryce> I'm assuming that one's fixed already (not enough info to say)
<Q-FUNK> re
<Q-FUNK> bryce: hiya!  it seems that what makes DDC fail with -amd is some new x86 emulator code that crept in since X core 1.3
<bryce> heya Q-FUNK
<Q-FUNK> bryce: various people have been investigating this and noticed some weir redundant bits in the X core code.
<bryce> what needs to be done to fix it?
<Q-FUNK> I'm starting to guess that more and more functionalities that were previously implemented in each driver are slowly being meatballed into more generic features and moved to X core.
<bryce> sounds likely
<Q-FUNK> some BIOS apparently don't like being tempered with twice when polling VBE registers
<Q-FUNK> this is what's been causing the freezes that -amd users on platforms that use General Software BIOS have been experimenting.
<Q-FUNK> the driver probably need to have large parts of it #ifdef'ed to skip them and #include newer X core features instead.
<Q-FUNK> then again, since this used to work mostly OK until Edgy (X core 1.2), there could be some nasty bugs in that new generic x86 emulator inside X core.
<Q-FUNK> bartman has been working on narrowing it down.  there's been a new geode list created on x.org that is very active lately, with several players involved in tracking and fixing this.
<bryce> who will be trying out #ifdeffing stuff?
<Q-FUNK> bartman
<bryce> ah, bartman?
<Q-FUNK> a kernel developer
<bryce> good to hear about the activity
<bryce> is that bart massey?
<Q-FUNK> he's dabbling into X code simply because he has extensive knowledge of things like polling into BIOS registers
<Q-FUNK> Bart Trojanowksi
<jcristau> couldn't it be caused by using x86emu in 1.3 instead of vm86 in 1.2?
<Q-FUNK> http://www.x.org/wiki/AMDGeodeDriver
<bryce> do you need my help with anything in particular with it?  I've been keeping an eye on things from the sidelines but don't know much about driver internals so haven't had much input to share
<Q-FUNK> jcristau: that is the current suspicion, yes
<Q-FUNK> x86emu sems at cause
<jcristau> not related to new code then
<Q-FUNK> http://lists.x.org/mailman/listinfo/xorg-driver-geode
<Q-FUNK> x86emu was already there in 1.2, but not used?
<Q-FUNK> here, the same -amd source code compiles and runs flawlessly against X 1.1, then bugs like unability to use ctrl+alt+Fx to change console creep in in X 1.2, even though it works mostly OK.
<Q-FUNK> by the time we try to build against 1.3, several competing hardware manufacturers reported complete system freeze
<jcristau> Q-FUNK: x86emu has been there forever
<Q-FUNK> bryce: we're mostly trying to figure out what x86emu is trying to do that freeze the system on some BIOS
<jcristau> just unused by default on x86_32
<Q-FUNK> ah. ok
<bryce> tjaalton: seems the ati logo issue is back
<bryce> <brian> bryyce: I installed the fglrx driver and I have some weird watermark on my desktop say "AMD Testing use only Unsupported hardware"
<bryce> <bryyce> brian, was this the version from ubuntu, or downloaded from the ati site?
<bryce> <brian> bryyce: I used restricted-manager to install it so the Ubuntu version
<Q-FUNK> I wonder what x86emu does that make -siliconmotion and -amd fail with X 1.3
<Q-FUNK> jcristau: any particular reason for emulating x86 on real x86 hardware instead of keeping with vm86?
<jcristau> Q-FUNK: it works on x86_64 kernels. vm86 doesn't.
<jcristau> plus, it makes it more likely that x86emu bugs get fixed, which benefits all archs
<Q-FUNK> true, but it leaves users in the dust until this is fixed.
<Q-FUNK> for all we know, -amd bugs are caused by x86emu and our -amd code is fine.
<jcristau> that's certainly possible
<tjaalton> bryce: well, the current lrm has fglrx 7.11 (aka 8.43), which is newer than the previous 8.42. maybe it's just a problem with 2.6.24 instead
<tjaalton> and I don't remember doing anything about the logo :)
<ubotu> New bug: #177829 in linux-restricted-modules-2.6.24 (restricted) "Please update fgrlx to 8.44 aka 7.12" [Undecided,New] https://launchpad.net/bugs/177829
<tjaalton> bryce: I'll upload a new lrm with latest stable nvidia tomorrow. no fglrx update since it seems to have some known issues (as always)
<bryce> ok
<bryce> tjaalton: http://people.ubuntu.com/~bryce/plots-0.1.html
<bryce> been hacking this together today
<tjaalton> cool, please add xorg-server too :)
<bryce> unfortunately xorg-server data hasn't been collected (http://people.ubuntu.com/~brian/complete-graphs/)
<tjaalton> oh right
<bryce> there is also displayconfig-gtk, but graphs for them haven't been generated
<tjaalton> an now that it has less than 70 bugs..
<bryce> I'll bug brian about it later
<tjaalton> I cleaned xorg&xorg-server bugs from crashers that seemed to be driver specific, so that's why -ati/-intel/lrm bug counts have soared :/
<tjaalton> and -nv, obviously
<tjaalton> the launchpad janitor seems to be offline, btw
<tjaalton> there would be 2000 closed bugreports if it ran today
<bryce> ahh, I wondered about that
<bryce> I think I read in the last lp update that the janitor was showing what *would* expire, but wasn't actually doing the expiration
<bryce> I gather they want to implement code to allow projects to opt-in to the expiration stuff
<tjaalton> I guess that's a no-brainer for ubuntu at least..
#ubuntu-x 2008-01-03
<tjaalton> bryce: btw, what do you feel about using openchrome for all via chips by default? I've checked the pci-id's that the driver claims to support, and it's greater than on any of the free via drivers
<bryce> yeah I've been thinking we should switch to openchrome by default
<tjaalton> fedora apparently does that now.. there's a simple patch for the server
<bryce> cool, yeah sounds like a good direction to go
<tjaalton> jcristau: I'd assume that debian would like to get openchrome packaged as well?-)
<ubotu> New bug: #177826 in linux-restricted-modules-2.6.24 (restricted) "Please update nvidia-glx-new to 169.07" [Undecided,In progress] https://launchpad.net/bugs/177826
<ubotu> New bug: #139223 in linux-restricted-modules-2.6.22 "Update to 8.41.7" [Undecided,Fix released] https://launchpad.net/bugs/139223
<bryce> tjaalton: check out the latest - http://people.ubuntu.com/~bryce/plots.html
<tjaalton> "not found"?
<tjaalton> http://people.ubuntu.com/~bryce/Plots/ works better :)
<ubotu> New bug: #180015 in xserver-xorg-video-intel (main) "[Gutsy] X Hard lock-up with X3100 on Vostro 1400 (intel GM965)" [Undecided,New] https://launchpad.net/bugs/180015
<bryce> tjaalton: yeah I moved it
<ubotu> New bug: #121590 in linux-restricted-modules-2.6.24 (restricted) "[wishlist] Provide a lrm-manager parameter which lists disabled modules" [Wishlist,In progress] https://launchpad.net/bugs/121590
<tjaalton> mvo: hey, I've upgraded my new desktop to hardy a week ago, and now compiz window decorations are broken for all windows that are not focused. This is with nvidia-glx-new (100.14 & 169.07), and both 2.6.22 & 2.6.24 kernel. Have you seen something similar? compiz bug list didn't show anything similar
<mvo> tjaalton: hello. I have seens this yesterday too, I currently have no idea what is wrong 
<tjaalton> mvo: ah, good that it's not only my box then :)
<tjaalton> bryce: your merge status page lacks mesa and wacom-tools, those might be worth adding
<jcristau> tjaalton: i suppose we would. though i'm not sure what's the deal with the various via drivers, and i'm not sure i want to know...
<tjaalton> jcristau: heh, can't blame you
<tjaalton> jcristau: it seems though that openchrome is the one that's actually maintained
<ubotu> New bug: #126184 in linux-restricted-modules-2.6.22 "Keep firmware on ABI bumps" [Wishlist,Confirmed] https://launchpad.net/bugs/126184
<ubotu> New bug: #49336 in linux-restricted-modules-2.6.15 (restricted) "Missing source package" [Undecided,Confirmed] https://launchpad.net/bugs/49336
<ubotu> New bug: #179574 in xorg (main) "No display (blank screen) on log out" [Undecided,Confirmed] https://launchpad.net/bugs/179574
<ubotu> New bug: #179553 in xorg (main) "8800GTX NOT SUPPORT " [Undecided,Incomplete] https://launchpad.net/bugs/179553
<ubotu> New bug: #179691 in xorg (main) "touch pad scroll on Toshiba laptop" [Undecided,Confirmed] https://launchpad.net/bugs/179691
<ubotu> New bug: #180010 in xorg (main) "Lenovo Y410 No sound Ubuntu gusty" [Undecided,Incomplete] https://launchpad.net/bugs/180010
<ubotu> New bug: #180168 in linux-restricted-modules-2.6.24 (restricted) "package xorg-driver-fglrx 8.443.1-1 failed to install/upgrade: intentando sobreescribir `/usr/bin/amdcccle', que estÃ¡ tambiÃ©n en el paquete fglrx-amdcccle" [Undecided,New] https://launchpad.net/bugs/180168
<bryce> yeesh, lotta bugs today
<ubotu> New bug: #180185 in linux-restricted-modules-2.6.24 (restricted) "[hardy] gdm screen does not appear until I remove AddARGBVisuals from xorg.conf" [Undecided,New] https://launchpad.net/bugs/180185
<ubotu> New bug: #180191 in xorg (main) "When certain application is open, key combination results in fatal crash of X" [Undecided,New] https://launchpad.net/bugs/180191
<tjaalton> misfiled even
<tjaalton> bryce: hum, vmmouse is in universe, so should the vmmouse_detect work if the driver is not installed?
<bryce> vmmouse_detect doesn't depend on vmmouse
<bryce> vmmouse_detect should return false if the driver is not in use (such as if it is not installed)
<tjaalton> ok, but it doesn't seem to work either
<tjaalton> during installation
<bryce> hrm
<tjaalton> the first sentence of bug 71167 :)
<ubotu> Launchpad bug 71167 in xorg "installer and livecd should detect vmware mouse device and use the right driver" [Low,Triaged] https://launchpad.net/bugs/71167
<tjaalton> sheesh, tormod closed ~20 ati bugs :)
<ubotu> New bug: #180214 in wacom-tools (main) "package xserver-xorg-input-wacom 1:0.7.7.7-0ubuntu2 failed to install/upgrade: trying to overwrite `/usr/share/man/man4/wacom.4x.gz', which is also in package wacom-tools" [Undecided,New] https://launchpad.net/bugs/180214
<tjaalton> damnit, must add an epoch to the replaces/conflicts for wacom
<tjaalton> and done
<keescook> tjaalton: you're quick.  :)
<tjaalton> keescook: I have my moments :)
<tjaalton> but when it comes to post-editing photos (<cough>UDS</cough>)...
<ubotu> New bug: #30743 in xorg (main) "dexconf does not write DisplaySize information in the generated configuration" [Wishlist,Won't fix] https://launchpad.net/bugs/30743
#ubuntu-x 2008-01-04
<ubotu> New bug: #144699 in linux-restricted-modules-2.6.22 "[gutsy] nvidia driver not loaded by default after upgrade" [Undecided,New] https://launchpad.net/bugs/144699
<ubotu> New bug: #48074 in gok (universe) "gok gives an X Window System error (dup-of: 58600)" [Medium,Confirmed] https://launchpad.net/bugs/48074
<ubotu> New bug: #180270 in xorg (main) "Can't disable 640x480" [Undecided,New] https://launchpad.net/bugs/180270
<ubotu> New bug: #180277 in xserver-xorg-video-openchrome (universe) "Please promote openchrome to main" [Undecided,New] https://launchpad.net/bugs/180277
<ubotu> New bug: #180343 in xserver-xorg-video-ati (main) "ATI driver update causes Display Corruption" [Undecided,New] https://launchpad.net/bugs/180343
<ubotu> New bug: #180374 in xserver-xorg-input-synaptics (main) "/dev/input/mice duplicates synaptics communication and makes configuring synaptics impossible" [Undecided,New] https://launchpad.net/bugs/180374
<ubotu> New bug: #179515 in xorg (main) "X crashes while upgrading from Feisty to Gutsy" [Undecided,New] https://launchpad.net/bugs/179515
<ubotu> New bug: #179334 in xorg (main) "[hardy] pointer disappears after display in sleep" [Undecided,New] https://launchpad.net/bugs/179334
<ubotu> New bug: #180398 in xserver-xorg-video-ati (main) "xvideo causes contrast/blocking issues" [Undecided,New] https://launchpad.net/bugs/180398
<tjaalton> bryce: I asked pitti to promote vmmouse and openchrome to main, so we can test them with alpha3
<bryce> ok cool
<bryce> I've done a  pkill -9 fetchmail  - there was some fetchmail process hanging around
<bryce> oops, mischannel :-)
<tjaalton> heh
<tedg> Okay, I upgraded my laptop to Hardy... not good.
<tedg> It seems when ever I have the synaptics driver in my xorg.conf my mouse no longer moves.
<tedg> I've played with it a bunch, but I can't seem to get the two happy together.
<tedg> The only thing that is a little odd is this: "(**) Synaptics Touchpad: doesn't report core events"
<tedg> It seems that, in theory, it should report core events.
<tedg> Or is that done through another interface and the synaptics driver only handles the "extra" events?
<tjaalton> tedg: did you upgrade or install from scratch? I mean is the xorg.conf the same as before?
<tedg> Well, it was.  But the nvidia driver won't load, so I had to switch it to "nv".
<tedg> Other than that it's the same.
<tedg> Oh, I guess I didn't answer the question: upgrade :)
<tjaalton> heh, ok
<tjaalton> I don't have a touchpad on any of the laptops in my possession, so can't help there much :/
<tedg> Yeah, I'm guessing it's a synaptics driver issue.  I think it must be disabling the movement parts of the touchpad.
<tedg> The funny part is that if I comment out "AlwaysCore" I get the touchpad working in a fixed position mode like a tablet.
<tjaalton> the driver hasn't changed much, so probably it just doesn't work right with xserver 1.4
<tjaalton> mjg59 promised to look at it though ;)
<tedg> :)  So, should I file a bug then?
<tjaalton> I think there's a dupe
<tedg> The other thing that's interesting is that when the nvidia driver failed I didn't get any reasonable fallback.
<tjaalton> check the log
<tjaalton> I'd just like to know why it failed :)
<tedg> I got "get-edid is not installed" and that 'does not know how to configure the "shared/default-x-server doesn't exist" X server'
<tedg> It didn't fall back to nv or vesa on it's own.
<tjaalton> oh
<tedg> Oh, the reason it failed is that it couldn't load the kernel driver.
<tedg> Which seems to be because my computer won't boot with the -386 kernel, but only the -generic one, but I'm unsure of what that means.
<tedg> (and why their symbols would be different to the point of not loading the nvidia driver)
<tjaalton> hmm, so it installed the -386 flavor by default?
<tjaalton> ahahaa, failsafeDexconf needs an update (lots of debconf keys gone now) :)
<tedg> I'm guessing, but it does seem to exist in the modules directories... I'm kinda confused on that right now.
<bryce> the get-edid warning is non-harmful.  I need to figure out how to suppress that
<tedg> bryce: I was looking for it, it's not in a supported package -- so that'd be a good thing :)
 * tedg is dying without right click...  must find external mouse...
<tjaalton>     # Discard stderr, which is text data about the card
<tjaalton>     get-edid 2>/dev/null
<tjaalton> before that there is 'is_installed get-edid "retrieve EDID" || return 1'
<tjaalton> bryce: I'll merge xorg/xorg-server/mesa for alpha3, so if you have pending stuff queued up, let me know
<tjaalton> I'll fix failsafeDexconf to always use "xorg" as the xserver, like the real dexconf does
<bryce> ok
<bryce> I don't have anything for mesa; I chucked the work I was doing on it since I never got it working properly
<tjaalton> ok
<ubotu> New bug: #178718 in xorg (main) "Gain root shell when X broken" [Undecided,New] https://launchpad.net/bugs/178718
<ubotu> New bug: #175436 in linux-restricted-modules-2.6.24 (restricted) "Hardy LiveCD fails to identify nVidia 8400M GS on Sony Vaio SZ" [Medium,Triaged] https://launchpad.net/bugs/175436
<tjaalton> hum, no need to merge xorg-server, so I'm done for the day
<tjaalton> bye!
<bryce> cya
 * bryce continues to struggle with libdrm
<bryce> I wish Intel would do their packaging better, it's such a pita
#ubuntu-x 2008-01-05
<ubotu> New bug: #180459 in xserver-xorg-video-i810 (main) "strange opengl artifacts with 945GM/GMS/940GML" [Undecided,New] https://launchpad.net/bugs/180459
<Q-FUNK> http://incoming.debian.org/xserver-xorg-video-amd_2.7.7.4-1_i386.changes
<tjaalton> Q-FUNK: what about that? if you want it in hardy, please file a sync-request
<tjaalton> bryce: I didn't notice there was a patch for bug 151388, committed and uploaded
<ubotu> Launchpad bug 151388 in xorg "failsafeXServer: line 47: [: too many arguments" [Low,Triaged] https://launchpad.net/bugs/151388
<bryce> thanks
<bryce> I got one of the moblin.org guys to say he'll redo the libdrm patch; I think that'll make things much easier.
<bryce> however it sounds like getting -psb functional is still going to require a backport of xserver et al from hardy to gutsy.  I'm hoping that won't be too involved of a project
<tjaalton> so they are still using gutsy?
<bryce> tjaalton: yup
<bryce> tjaalton: apparently they were going to go to hardy, but it sounds like they've decided to stick with gutsy
<Q-FUNK> tjaalton: ther eis no diff. it will be auto-sync'ed.
<tjaalton> no it won't, that time has passed :)
<Q-FUNK> bryce: this one should fix the issue. however, it's probably pointless to introduce it to Gutsy as an update, even though the driver in Gutsy is essentially useless.
<Q-FUNK> tjaalton: already?
<tjaalton> a month ago
<Q-FUNK> ah.  anyhow, the driver currently in the archive flat out doesn't work with X server >= 1.3
<Q-FUNK> so it will have to be sync'ed, especially since most commercial LTSP hardware uses that chipset.
<Q-FUNK> bryce had asked me to let him know once a fix is released.
<tjaalton> sure. if you can file the sync-request, then I'll confirm it
<Q-FUNK> requestsync -s - was it?
<tjaalton> dunno, I don't use it
<tjaalton> ah, no need to use -s
<Q-FUNK> no?
<tjaalton> no, since I'll "sponsor" it
<tjaalton> that would only subscribe universe-sponsors
<Q-FUNK> or main sponsors.
<Q-FUNK> but ok, without option then.
<tjaalton> yeah, it's in main
<Q-FUNK> ah.  the debian changelog server isn't returning anything useful.
<Q-FUNK> sent
<tjaalton> hmm, it added ubuntu-main-sponsors anyway
<Q-FUNK> I think it does that automatically, nowadays, so that the requester doesn't have to guess.
<tjaalton> right
<Q-FUNK> IIRC if someone doesn't have an ubuntu.com or canonical.com address, sponsoring is presumed.
<ubotu> New bug: #180539 in xserver-xorg-video-amd (main) "Please sync xserver-xorg-video-amd 2.7.7.4-1  (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/180539
<Q-FUNK> manually added the changelog
<Q-FUNK> and some comments
<tjaalton> cool
<Q-FUNK> the hardy sync is definitely needed, since this will be an LTS release.
<Q-FUNK> I'm not sure what to do with Gutsy, however.
<Q-FUNK> bryce would need to decide this.
<Q-FUNK> however, most hardware vendors test against stable releases, not unreleased OS.
<ubotu> New bug: #180601 in xorg (main) "Incomplete monitor specification data for Sony CPD-E200" [Undecided,New] https://launchpad.net/bugs/180601
<Q-FUNK> hm
<Q-FUNK> found the exact spot where -amd crashes on X -configure, with strace, but not sure what to make of it
<Q-FUNK> do we have any pastebot for this?
<tjaalton> use pastebin.ubuntu.com or equivalent
<Q-FUNK> http://pastebin.ubuntu.com/3308/
<bryce> Q-FUNK, can you request to have it included in -backports?
<bryce> also, I think it would not be out of the question to try getting it out for gutsy, if it's true that the current driver is useless.
<bryce> so the steps to take for that are to first make sure there is a bug documenting the breakage in gutsy and how the new driver fixes it, and upload the new driver to -proposed
<bryce> that'll allow testing it, and enable others to weigh in with whether it should be put out as an SRU
<Q-FUNK> bryce: I'm waiting to hear report about the backport I just pbuilt, first
<bryce> ok cool
<Q-FUNK> I linked to it from the bug
<ubotu> New bug: #180654 in xserver-xorg-video-ati (main) "rendering artifacts: intermittent vertical lines on right side of round shapes" [Undecided,New] https://launchpad.net/bugs/180654
#ubuntu-x 2008-01-06
<ubotu> New bug: #180742 in xserver-xorg-video-amd (main) "lx800 amd_drv.so(with xorg 1.3) still crashes the screen after ctrl alt BS or in shutdown" [Undecided,New] https://launchpad.net/bugs/180742
<pwnguin> man this is crazy. my user is making hardy crash like 8 out of ten times i log in =(
<pwnguin> http://paste.ubuntu-nl.org/50905/
<tjaalton> bug 175682
<ubotu> Launchpad bug 175682 in gnome-keyring "GNOME rarely starts from GDM in Hardy" [Unknown,Confirmed] https://launchpad.net/bugs/175682
<tjaalton> pwnguin: ^
<tjaalton> gone ->
<tjaalton> actually, g-k doesn't make the xserver crash.. logfile is more useful than .xsession-errors though
<ubotu> New bug: #180770 in xorg-server (main) "xorg crash after nvidia splash screen blacks out and X crashes" [Undecided,New] https://launchpad.net/bugs/180770
<ubotu> New bug: #180802 in xorg-server (main) "Xorg crashed with SIGSEGV in _IO_vfscanf()" [Undecided,New] https://launchpad.net/bugs/180802
<tjaalton> bryce: do you think we should get the discover-free xorg merge in for alpha3?
<tjaalton> it's not out yet (maybe later today)
<tjaalton> without that there isn't much for people to test :)
<tjaalton> jcristau: I noticed that -intel has libI810XvMC in it, but our openchrome puts it in a separate library. what do you prefer if we'd push openchrome to git.d.o?
<tjaalton> openchrome depends on the lib anyway
<jcristau> in a separate package you mean?
<tjaalton> uh, yes :)
<jcristau> i don't think it needs one
<tjaalton> right, if it's not meant for general consumption
<tjaalton> which I don't think it is
<jcristau> i'm not quite sure how xvmc is supposed to work tho
<tjaalton> "This package provides the XVMC libraries used by the xorg driver"
<tjaalton> I'll ask the packager
<jcristau> it looks like libxvmc dlopens the driver
<jcristau> so yeah, no need for a separate package afaics
<jcristau> (from a quick look at libxvmc/src/XvMCWrapper.c)
<ubotu> New bug: #180841 in mesa (main) "glXDestroyContext causes segmentation fault with Via Unichrome graphics" [Undecided,New] https://launchpad.net/bugs/180841
<pwnguin> anyone know if tjaalton thanks
<pwnguin> yikes
<pwnguin> tjaalton: thanks for th elink
<tjaalton> pwnguin: actually, I don't think it's the same bug :)
<pwnguin> me either
<pwnguin> i get a straight up crash
<pwnguin> not a hang
<pwnguin> and a new user fixes the problem
<tjaalton> provide the Xorg.0.log
<pwnguin> shall i file a bug and attach?
<bryce> morning
<tjaalton> hi bryce
<bryce> tjaalton: yes, if there's time to get the discover-free xorg in, I say go for it
<pwnguin> its noon, even in portland
<tjaalton> hehe
<tjaalton> that's what I thought too :)
<tjaalton> pwnguin: put it in pastebin first
<bryce> heh ok so we got up late here ;-)
<tjaalton> luxury
<pwnguin> I should just move to australia
<bryce> was up til 4am working on inkscape
<pwnguin> i seem to live their schedule
<pwnguin> tjaalton: 0.log doesn't have the crash in it =/
<tjaalton> .old
<pwnguin> hmm, a backtrace
<pwnguin> http://paste.ubuntu-nl.org/51001/
<tjaalton> nvidia..
<tjaalton> do you get the same with nv?
<pwnguin> i can try
<pwnguin> but i think so
<pwnguin> i know how you guys like to blame everything on nvidia
<tjaalton> <g>
<tjaalton> a third of all the bugs on x-swat packages are from restricted-modules (>500)
<tjaalton> that backtrace doesn't look like it's nvidia's fault though
<pwnguin> same happened
<tjaalton> then you should get a proper backtrace with gdb
<tjaalton> https://wiki.ubuntu.com/DebuggingXorg
<tjaalton> since it doesn't hang the machine you can use a vt for gdb
<pwnguin> that package doesn't exist
<pwnguin> oh
<pwnguin> seperate repo
<tjaalton> or xserver-xorg-core-dbg
<pwnguin> is there a difference?
<tjaalton> you can install -dbg directly
<tjaalton> otherwise no
<pwnguin> time for breakfast
<bryce> ha, so it _is_ morning!
<pwnguin> you misunderstand. breakfast is whenever you break the fast
<pwnguin> i happened to wake up at 2
<bryce> hrm, well I'm certain it's morning somewhere
<pwnguin> i have a feeling you'll love this
<pwnguin> two backtraces
<pwnguin> one broken pipe and one segfault
<pwnguin> http://paste.ubuntu-nl.org/51014/ http://paste.ubuntu-nl.org/51015/
<pwnguin> broken pipes happen even with the good user, so the second paste is my culprit
<pwnguin> null pointer dereference
<pwnguin> somehow, XkbFindSrvLedInfo returned null
<pwnguin> which causes sli-> to null pointer die
<pwnguin> which is entirely possible
<tjaalton> pwnguin: ok, please file a bug on xorg-server, and attach the backtraces
<pwnguin> okies
<pwnguin> already workin on it ;)
<pwnguin> oh, i love the dupe finder
<pwnguin> Phil Collins causes Nautilus to segfault
<tjaalton> there'll be a new xorg-server snapshot probably tomorrow
<tjaalton> dupe finder?
<pwnguin> on launchpad
<pwnguin> you file a bug, and it suggests possible dupes
<tjaalton> oh right
<tjaalton> similar would be useful for bug triaging
<pwnguin> it helps a bit
<pwnguin> but they either need google level intelligence to figure the algorthim out or smarter users
<pwnguin> xorg-server or xserver-xorg-core?
<pwnguin> does xorg not have their code on some webgit interface?
<tjaalton> yes they do
<pwnguin> im failing to find it by simply browsing their site =(
<tjaalton> http://gitweb.freedesktop.org/
<tjaalton> xorg-server is the source package of xserver-xorg-core
<pwnguin> thanks
<tjaalton> so x-x-core bugs end up in xorg-server queue
<pwnguin> unfortunately, a new pull doesnt appear like it will fix the bug
<tjaalton> maybe not
<tjaalton> then we'll forward it upstream
<tjaalton> you can try searching bugzilla.fd.o if it's reported already
<bryce> tjaalton: brian murray recommends bughelper for dupe finding while triaging
<bryce> I've not looked at it in a while; apparently it's got new docs and stuff so should be easier to use I hope
<tjaalton> bryce: cool, I'll check that out
<ubotu> New bug: #180884 in xorg-server (main) "xkbLEDs causes segfault on login" [Undecided,New] https://launchpad.net/bugs/180884
<IceKiller> http://ubuntuforums.org/showthread.php?t=633068 <--
<IceKiller> the Intel driver + MESA 7.01 shipped with Gutsy is quite buggy with Intel GM965, there are new 'drivers' and was wondering if it was going to be included in the mainstream
<IceKiller> http://www.mesa3d.org/relnotes-7.0.2.html where it mentions among other things that: "Fixed an assortment of i965 driver bugs" && a new Intel driver, version 2.2.0: http://xorg.freedesktop.org/archive/...l-2.2.0.tar.gz
<tjaalton> IceKiller: try hardy alpha2, which has those
<IceKiller> tjaalton k ty :)
<IceKiller> tjaalton anychance they are going to update it in their mainstream
<tjaalton> what do you mean? backports for gutsy?
<IceKiller> yeah
<IceKiller> well included into the 'update' stuff..
<tjaalton> I don't know
<IceKiller> hm k :) tx
<bryce> no probably not
<pwnguin> if you want stuff fixed, test and report the testing versions ;)
<bryce> it's a lot of work to backport significant driver changes, and the effort is better invested into making hardy better
<tjaalton> yeah
<bryce> right; if you want to put in some elbow grease to get patches ported to Gutsy, that would be a great thing!  But I've backported as much for -intel as I'm planning for gutsy
<tjaalton> hum, checked how many new bugs there were reported in 2007.. (re: perriers blog on planet.d.o)
<tjaalton> the first bug-id of 2007 was bug 77587, and the first in 2008 was bug 179627
<ubotu> Launchpad bug 77587 in ivi "Assertion `expr` failed" [Undecided,New] https://launchpad.net/bugs/77587
<ubotu> Launchpad bug 179627 in ubuntu "Laptop battery icon disappears" [Undecided,Invalid] https://launchpad.net/bugs/179627
<tjaalton> but not all of the id's are ubuntu bugs
<tjaalton> don't know how to get reliable data out from it
#ubuntu-x 2008-12-29
<kees> anyone around to talk me through bleeding-edge intel?  I've got stuff from the xorg-edgers PPA installed, but when I forced on UXA, 3d performance dropped by about 60%.
<tjaalton> kees: still around? check the log if DRI is enabled
<tjaalton> hmm, mfb has been disabled and xf1bpp purged from the server sources.. maybe time to let x-x-v-sunbw2 go :)
<kees> tjaalton: yup, dri2 is enabled
<tjaalton> kees: hum, ok. maybe it needs a newer mesa or something
<tjaalton> there is a "2008-q4" branch available, dunno when it's going to be merged to master. maybe that could help
<kees> tjaalton: yeah, I'm reading http://intellinuxgraphics.org/download.html at the moment
<kees> tjaalton: sounds like the ppa libdri2 is a few days behind
<tjaalton> kees: heh, could be
<tormod> I think stuff that came in libdrm after c86d431f is mostly kernel-mode-setting stuff
<tjaalton> kees: which app are you using for testing?
<kees> tjaalton: I'm using tremulous
<kees> tormod: any ideas what I should change/tweak?
<kees> right now the only non-default thing I have set in xorg.conf is to use UXA
<tormod> kees: I have very little hands-on on intel. sitting on one now over Christmas but haven't tested all the edgy stuff.
<tormod> are there any complaints in the log?
<kees> tormod: okay, cool.  I'm happy to be a tester for you :)
<kees> not that I've found
<tormod> well I actually have -intel git master and libdrm from ppa installed, so I am almost on the edge :)
<kees> tormod: though, it seems to load the i915 driver, not i965.
<kees> tormod: where is the git master ppa?  I saw stuff from about 9 days ago on xorg-edgers
<tormod> kees: there's none. I can push it to xorg-edgers.
<kees> cool, yeah
<kees> (WW) intel(0): ESR is 0x00000001, instruction error
<kees> (WW) intel(0): Existing errors found in hardware state.
<kees> that's the only error I can find
<crevette> kees, does tremulous works well for you performance-wise ? because for me is slow as hell somtimes, fps decreases to 3 
<tormod> kees, it's building in the ppa now.
<kees> crevette: with EXA, and all the fancy stuff turned down, I usually stay above 6fps
<kees> tormod: cool
<kees> crevette: normally it's around 15-30, with simple rooms at 90
<kees> crevette: with UXA, it's about 2fps
<crevette> kees, for me I didn't touch anything in xorg so I believe I have no xorg.conf
<crevette> so I wondered if I didn't miss something in my conf (not in a required group, ...)
<kees> crevette: with normal (exa/dri) I just turn all the fancy stuff off in tremulous
<crevette> kees, for 3D performance, I just need to be in video group, right ?
<tormod> crevette: yes
<crevette> okay
<tormod> glxinfo should confirm it's ok
<crevette> yeah, I use dri
<tormod> oh I forgot, nothing builds in Jaunty now, because of a conflicting drm headers in linux-libc-dev ...
<tjaalton> again?
<tjaalton> I thought the kernel header should not be installed until libdrm is fixed
<tormod> last time I added a Replaces: linux-libc-dev (<= 2.6.28-3.4) to libdrm, but now a new kernel is out with the same issue.
<tjaalton> oh right, it was fixed with a Replaces in libdrm
<tormod> I'll drop the versioning in the ppa. and there will be a new libdrm from master git for kees :)
<tormod> last time I tried k-m-s in the ppa I discovered many people were using it :) I hope current libdrm is more backwards compatible.
<tormod> kees, with updated libdrm and -intel, glxgears went up from 800 to 930, but enabling UXA gives 390 - because then I get DRI2 I guess.
<kees> tormod: upstream told me that glxgear isn't a good measure of performance, but yeah, 3d still is way slow.  dang.
<tormod> kees: I know, it's just so handy :)
<tormod> is it faster with EXA for you?
<kees> exa is faster than uxa, but I didn't compare old driver to new driver with exa.  nothing jumped out at me.  I get about 2400 fps with glxgears on exa, and about 900 on uxa
#ubuntu-x 2008-12-30
<pwnguin> as i recall, glxgears is a great test of buffer clearing speed
<Ng> hmm, are there any backports of newer intel drivers to intrepid? istr bryce did some at some point?
<Ng> aha, found em
<Ng> if I have some patches from xorg bugzilla from an intel person and they don't apply to 2.4.1 or 2.5.1, what on earth are they likely to need?!
<tjaalton> Ng: master :)
<Ng> I swear I'm -> <- close to going and buying any kind of nvidia/ati that the computer shops in london have in a fanless form
<tjaalton> hehe
<tjaalton> let me find one for you
<tjaalton> ati of course
<Ng> http://www.yoyotech.co.uk/hightech-radeon-4350-512mb-gddr2-pcie-hdcp-ready-graphics-card-p-1025968.html is the leading contender atm
<Ng> because it's in stock in a shop I can find easily :)
<tjaalton> yeah that looks ok. although there's no 3d-support yet, even though phoronix claims so
<Ng> ehh, really? even with fglrx?
<tjaalton> no I meant the free driver
<Ng> ah
<tjaalton> you might need to use fglrx for one release, and then jaunty+1 should have full support in the free driver stack
<Ng> as much as I love the freedom, I've not been able to watch video from my TV PC for some months now, so I'll accept some proprietary nonsense just to make it work ;)
<Ng> I even looked at mac minis last night, that's how frustrated I am with this ;)
<tjaalton> why don't you use your ps3
<tjaalton> ?
<Ng> I have had to use it, but it's not really the nicest interface for browsing a bunch of media
<Ng> and it doesn't have google earth, which is really very nice at 1920x1080 ;)
<tjaalton> yes the browser could be better
<tjaalton> both media & www
<Ng> I could fix a fair amount of it myself though, you can create custom listing views with mediatomb these days
<tjaalton> I've sorted them in folders, so it works ok. not that many files though, mostly just Fifth/Top Gear seasons :)
<Ng> I'm very bad at sorting out my incoming media folder, it's full of iplayer stuff. browsing it any other way than newest-first is very boring ;)
<tjaalton> heh
<Ng> but generally mediatomb is getting really good :)
<tjaalton> my QNAP has twonky
<Ng> I suppose for completeness sake I should try a jaunty liveCD
<Ng> and I should probably try and pester anholt directly about this on #xorg-devel rather than keep on trying to talk to the slightly unhelpful intel person on the bug
<Ng> hmm, the jaunty driver might actually be working
<Ng> oh, no, there was a resync. bah.
<tjaalton> resync?
<Ng> tjaalton: where the TV resyncs the picture, so blinks to black and back
<Ng> got a radeon now, so I need to figure out fglrx ;)
<tjaalton> hehe
<Ng> it's not going well so far, activate the driver in jockey and I get the X failsafe stuff, but that has unreadably small fonts on my TV ;)
<Ng> it seems to be failing to find a symbol that's in the fglrxdrm xorg module
<Ng> ah, it's because /dev/dri/card0 is missing
<Ng> argh, still with the display blanking. what the deuce?!
<Ng> how... but..
<Ng> how can the motherboard be causing this?! I've tried cables I know work, I've changed graphics chip
<tjaalton> I've no idea..
<Ng> it seems like it ought not to be possible ;)
#ubuntu-x 2008-12-31
<bryce> tjaalton: btw for colin's bug #310857, I am guessing it would be worth-while to have a new xserver git snapshot package to re-test.  There's several changes from ajax in the 1.6 branch for randr-related issues
<ubottu> Launchpad bug 310857 in xserver-xorg-video-intel "[i965] intel driver seems to get stuck in an EDID-fetching loop (dup-of: 307306)" [Undecided,Incomplete] https://launchpad.net/bugs/310857
<ubottu> Launchpad bug 307306 in xorg-server "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [Unknown,Confirmed] https://launchpad.net/bugs/307306
<tjaalton> bryce: yeah
<tjaalton> I'll prepare one
<bryce> fwiw, I dug through the libxrandr changelog between 1.2.3 and 1.2.99.4 (and newer), but didn't see any obvious smoking guns.  I'm thinking it's just that we got a slightly too old xserver for this libxrandr
<tjaalton> it should be the other way around
<tjaalton> the library doesn't need the server :)
<tjaalton> or use
<tjaalton> and the problem only affects some intel chips
<bryce> well, I mean a version incompatibility 
<bryce> yeah I've not reproduced it locally here, however I've only got two intel boxes I can easily test against
<tjaalton> for the newer xserver we also need a newer libxrandr
<tjaalton> well, no. the server doesn't need the lib
<tjaalton> and no driver uses the new stuff
<tjaalton> that's currently in jaunty
 * bryce nods
<tjaalton> I'll disable patch 107 too
<tjaalton> for now
<bryce> tjaalton: good idea
<tjaalton> a final 1.6 within a week? there are still blocker bugs on the list..
<tjaalton> like the fact that having two cards installed you need to use BusID
<tjaalton> eh, no randrproto 1.2.99.4
<tjaalton> so much for updating libxrandr then
<bryce> tjaalton: keith mentioned he wants to try doing quarterly releases
<tjaalton> bryce: of -intel?
<bryce> no, of the xserver
<tjaalton> oh
<bryce> -intel already does quarterly releases since some time
<tjaalton> like 1.x or 1.x.x?
<bryce> 1.x
<tjaalton> ok, sounds like X7.5 won
<tjaalton> duh
<tjaalton> won't have 1.7 then
<tjaalton> but 1.8 or so
<bryce> yup
<tjaalton> I'm not sure what shape MPX etc are in
<bryce> I would imagine they would take the approach of pushing it off to a future release if it's decided not ready for that quarter's release
<tjaalton> hmm, I might have the power to cut a randrproto release myself, but no guts :)
<bryce> hehe
<Ng> what's coherent mode when it's at home, and how do I toggle it? ;)
<tjaalton> no idea, I ment to ask if you found it :)
<Ng> tjaalton: hehe
<Ng> I think it might be a radeon thing, but it's proving pretty hard to find info about
<tjaalton> yeah
<tjaalton> great, the new xserver snapshot changed some xquartz binaries, meaning debuild -S fails
<tjaalton> maybe those could be just removed from debian/ubuntu branches
<Ng> I'm wondering if the ridiculous BIOS in this machine might be to blame, the "Intelligent Tweaking" page has a lot of things set to "Auto" and I have no idea if that means "Automatically pick the official values" or "Automatically try to overclock my hardware"
<Ng> e.g. "Robust Graphics Booster" which claims to increase PCI-E bandwidth and has the options "Auto", "Fast" or "Turbo". How about "Off"? ;)
<tjaalton> yep, bios might be something to check
<Ng> I forced the PCI-E clock to 100MHz and gave the northbridge 100mV more food, will see how it goes
<tjaalton> "robust graphics booster" doesn't sound too robust to me ;)
<Ng> well that's the hilarious thing, when you are changing that setting there's a load of red text that appears and warns you that a bad setting will make your machine explode in a giant fire, or something like that ;)
<tjaalton> hah
<Ng> interesting side problem, the radeon claims to be showing 1920x1080, but an inch or two of picture is missing on the right&bottom
<terli> can I get some help configuring multiple pointers
#ubuntu-x 2009-01-01
<pwnguin> i wasn't aware mpx was in jaunty
<pwnguin> (or xorg main)
<bryce> tjaalton: posted debdiff for #308387.  solved the issue for me, but would appreciate if you took a look at it to assure it's the right change
<tjaalton> bryce: I'd just modify debian/libdrm-dev.install :)
<tjaalton> but the real question is, does -intel build against the kernel headers
<tjaalton> the kernel needs db139d606ea25e0590373d5ce6bfc42ce317a61c from drm-next
<tjaalton> fdo bug #19132
<ubottu> Launchpad bug 19132 in gtk+2.0 "gtk 2.7.3 with cairo doesn't use font rendering settings" [Medium,Fix released] https://launchpad.net/bugs/19132
<bryce> well there are some headers which don't conflict (which I left in the makefile).
<tjaalton> bah, freedesktop bug 19132
<ubottu> Freedesktop bug 19132 in Driver/intel "2.5.99.1 fails to build using drm headers from 2.6.28" [Blocker,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=19132
<bryce> yeah, I didn't try building anything against it (this is an -ati box)
<tjaalton> the goal is to get rid all of them I guess (from libdrm-dev)
<tjaalton> only the userspace headers will remain (intel_bufmgr.h, xf86drm.h)
<tjaalton> oh well, I'll mail the kernel list
<bryce> fair enough; the remainder sounded like maybe obsolete cruft, but didn't want to drop without seeing someone state that explicitly
<bryce> ok
<tjaalton> btw, the new intel needs newer libdrm, but there are reports where X segfaults on start with it, so.. :/
<bryce> dah, such unstable crap
<bryce> I'm peeved...  I bought a dell mini 9 for my dad, and after playing with it with him for all of 4 hours, it locked up 3 times
<tjaalton> :S
<bryce> not sure exactly what is happening, but seems like a kernel lockup
<bryce> the dell mini 9 is an i945 hardy setup, with the lpia kernel and a proprietary wireless driver
<bryce> was really disappointed - if anything it ought to be a showcase of ubuntu/linux/open-source quality, and to have it locking up so much is really frustrating
<tjaalton> yeah that sounds really bad
<bryce> anyway
<bryce> the system I'm trying to get up to jaunty is one I plan to switch to as my main desktop
<bryce> usually I've kept my main desktop to the last released Ubuntu for stability, but I figured I need to dog food more :-)
<tjaalton> hehe
<tjaalton> my desktop is still intrepid, because of the nvidia blob..
<bryce> I had some graphics problems with it before, so was using it just as a build box, but I managed to get those all squared away this week
<tjaalton> you probably heard the news about r6/7xx drm stuff?-)
<bryce> oh yeah
<bryce> and nvidia's new video accel stuff
<bryce> vdpau or whatever
<tjaalton> so within a month the docs should be out and some sort of a DRI driver too..
<tjaalton> I wonder if other drivers will pick vdpau..
<bryce> do -ati and -radeonhd both use the same dri driver in mesa?
<tjaalton> yes, AIUI
<bryce> cool
<bryce> tjaalton: vdpau ain't open source
<tjaalton> hmm
<bryce> and sounds like both Intel and ATI have competing technology solutions for multi-mpeg accel support, so...
<bryce> I think again we're going to get into this annoying situation of having a great proprietary solution for -nvidia, and a less great but open source solution from intel
<tjaalton> I believe there was an announcement on xorg@ about vdpau
<bryce> from nvidia?
<tjaalton> yes
<tjaalton> a couple of months back
<bryce> ah; not spotting it in my mail archive
<tjaalton> me neither, but I'll look closer
<bryce> anyway, sounds like there'll be fragmentation on the video acceleration front to look forward to this next year or so
<tjaalton> here: http://lists.freedesktop.org/archives/xorg/2008-November/040279.html
<tjaalton> so the API is free
<bryce> heh
<tjaalton> yes, too bad that now that nvidia has published vdpau, the other vendors still keep on working on their own stuff..
<tjaalton> NIH ftw!
<bryce> publishing the API != free
<bryce> Microsoft publishes many API's for application developers to use...
<tjaalton> well the copyright notice on the headers does sound like it's free..
<tjaalton> I'd like to hear what the other vendors think of it..
<tjaalton> nothing on the list or IRC so far
 * bryce nods
<bryce> I guess what I mean is that publishing the API is akin to putting the table of contents of a book on a website
<bryce> you couldn't then claim that the book was "available for download from the web"
<bryce> similarly, to really call an API "Free", I'd expect the reference implementation to also be published under a free-ish license
<pwnguin> more importantly, a set of closed drivers conforming to an API will sustain a far slower the rate of change 
<bryce> switching systems... bbiab
<bryce> erf, I can only get -vesa booted.  wtf
<tjaalton> jaunty?
<bryce> yep
<bryce> retesting -ati, brb
<bryce> no go
<bryce> ah well, tomorrow's project
<tseliot> BTW the id of my NVIDIA card (02E2) is no longer in /usr/share/xserver-xorg/pci/nv.ids or anywhere in /usr/share/xserver-xorg/pci/ (in Intrepid)
<tjaalton> so nv doesn't support it
<tseliot> tjaalton: but it's a geforce 7300 and it was supported
<tseliot> and should be supported by nv too
<tjaalton> maybe the .ids parsing code is buggy then
<tseliot> yes, that was my 1st guess
<tjaalton> improvements welcome :)
<tseliot> tjaalton: where's the code? In the source package of nv?
<tjaalton> yes
<tjaalton> there's a patch which modifies a Makefile
<tjaalton> to generate the file
<tseliot> ok, I think I've played with something similar before (for nvidia)
<tjaalton> -nv is a special case because it lists id's in a couple of functions
<tseliot> ok
<tjaalton> so it's possible that the parser is buggy
<tseliot> the ID is missing from the source file. Other ids for 7300 cards are provided but mine
<tseliot> a patch should fix it
<tjaalton> so forcing the driver works?
<tjaalton> IIRC mvo had a similar case
<tjaalton> where the driver didn't list the id, but works if forced
<tseliot> it used to work. I'll test it and if it works, I'll give you a patch
<marijus> hello, how to check if kms is running properly?
<tjaalton> it isn't, period :)
<marijus> ok... :) anyway... a happy new year!
<tjaalton> unless you're running experimental code from upstream..
<marijus> i do...
<tjaalton> ok then
<tseliot> tjaalton: nv works if I force it in the xorg.conf. Shall I give you debdiffs for intrepid and jaunty? Also I'll contact Aaron Plattner
<tjaalton> jaunty is enough, doubt that intrepid will be updated
<tseliot> ok
<tseliot> BTW did you remove that fedora patch from X? The one which caused corruptions on KDE?
<tjaalton> done in git
<tjaalton> but I can't build a source package and upload because some xquartz binaries have been changed, and dpkg-buildpackage barfs because of it
<tseliot> ouch
<tjaalton> so either have to wait for next beta or remove xquartz from the git branch
<tjaalton> since it's osx-specific anyway
#ubuntu-x 2009-01-02
<bryce> tjaalton: btw I tried manually copying the libdrm-dev headers back into /usr/include/drm, but it made no difference; -ati still hangs on X start.
<bryce> surprisingly, vesa actually looks pretty good, although it's a lower res and no dual-head
<tjaalton> bryce: the headers are used only when building the drivers
<tjaalton> or do you mean you rebuilt -ati?
<bryce> ah.  no didn't rebuild it
<tjaalton> shouldn't make a difference
<tjaalton> so it just hangs?
<bryce> yep, I'd had it working fine and dandy with intrepid, then did the upgrade
<bryce> X fails to start, and switching to vts just displays corrupted screens
<bryce> so my next hypothesis is an EXA/XAA problem
<tjaalton> ah, so you can change the vt when it happens?
<tjaalton> is it a r5xx?
<bryce> RV630
<tjaalton> hmm, dunno which generation that is
<tjaalton> if it's DRI capable, try disabling it
<bryce> RV630 [Radeon HD 2600XT]
<tjaalton> ok, it's not that
<tjaalton> maybe it's trying to use the wrong output?
<bryce> bryceharrington.org/files/Xorg.0.log.old
<bryce> I don't think it's a wrong output issue - the card has 2 outputs and I have monitors connected to both.
<tjaalton> heh, ok
<tjaalton> there's a new upstream version in experimental.. try that
<bryce> yeah
<bryce> hmm, this looks suspicious:
<bryce> Output 69 disable success
<bryce> Output 51 disable success
<bryce> Blank CRTC 0 success
<bryce> Disable CRTC 0 success
<bryce> Blank CRTC 1 success
<bryce> Disable CRTC 1 success
<tjaalton> right
<tjaalton> that's why I suspect an initialization issue
<tjaalton> bug 312924 looks similar
<ubottu> Launchpad bug 312924 in xorg "HD3450 configuration fails on reboot in jaunty" [Undecided,Incomplete] https://launchpad.net/bugs/312924
<bryce> yeah
<tjaalton> and bug 311748
<ubottu> Launchpad bug 311748 in xorg "HD3470 AND HD3200 X56TR laptop x doesn't start / black screen" [Undecided,Incomplete] https://launchpad.net/bugs/311748
<tjaalton> I've duped them
<tjaalton> em, the former with the latter
<bryce> great
<bryce> I'm back to work tomorrow, and I think I'll focus the day on sorting out this particular bug (or upstreaming it at least)
<tjaalton> the new upstream version didn't help
<tjaalton> ?
<bryce> right, I'll try that tomorrow first
<tjaalton> ah, ok
<bryce> (today I've been doing shop project stuff, and tonight am installing the new bookcase I made)
<bryce> my wife's excited because I've got a pile of old books out in the main room that will be moved in now, and it'll eliminate clutter she's had to look at
<tjaalton> hehe
<tjaalton> it's -12C outside, so I'll stay in and weed the bugs
<bryce> ouch :-)
<tjaalton> btw, I've changed my contract to 20h/week so I can concentrate on my studies the next two months (at least), so might be that I need to lower my commitment to X/ubuntu for a while :/
<bryce> ah, good to know
<bryce> how'd your tests go btw?
<tjaalton> good practice :)
<tjaalton> next ones the week after next week
<tjaalton> I was just so jetlagged the whole week, and I actually had to skip the first one because I couldn't stay awake for more than 5min
<tjaalton> ..at a time
<bryce> :-/  I was worried something like that'd happen.  Hope your professors were sympathetic
<tjaalton> well they want to get rid of us (slackers), so they have no choice :)
<tjaalton> I'll merge -ati, it can't be worse than the current version :)
<Q-FUNK> howdy!  any chance to get the fix to bug #255991 moved from hardy-proposed to hardy-updates?
<ubottu> Launchpad bug 255991 in xserver-xorg-video-geode "xf86-video-geode: DDC probing broken on GX2/CS5535 since 2.9.0 (patch)" [Undecided,Fix committed] https://launchpad.net/bugs/255991
<tjaalton> Q-FUNK: isn't that something for an archive-admin?
<bryce> yeah, need to talk to pitti or slangasek
<Q-FUNK> tjaalton: I'm not sure.  last time I asked, I was told to test and ensure that it doesn't introduce any regression.
<Q-FUNK> ok
<tseliot> tjaalton: what are you studying?
<tjaalton> tseliot: major in semiconductors & materials in electronics (blech), minor in software engineering & business
<tjaalton> so the courses I have left are real gems, like physics II, inorganic chemistry etc :)
<tseliot> hehe, a lot of fun
<tjaalton> a lot, yes
<tseliot> will it give you the chance to be paid more? How does it work in Finland?
<tjaalton> sure
<tjaalton> if you have a degree it gives you more options
<tseliot> ok, then it's definitely worth the effort
<tjaalton> although there are plenty of experts who have dropped out and made a good living
<tseliot> you already have a job, right?
<tjaalton> sure, had one for ten years now.. one reason why it's been taking so long :)
<tseliot> aah, I thought you started your degree course recently
<tseliot> more recently
<tjaalton> heh
<tseliot> good luck then
<tjaalton> thanks
<tjaalton> bryce: the new ati version didn't help your setup?
<bryce> I've installed it; I'll reboot after I finish fiddling with a few bug reports
<tjaalton> looks like evertjan didn't get the new version yet
<tjaalton> II) Module radeon: vendor="X.Org Foundation" compiled for 1.5.99.3, module version = 6.9.0
<CShadowRun> Hi guys, i was just reading http://blog.qa.ubuntu.com/node/9 and i hear you need testers
<CShadowRun> I have a quad screen setup (2 nVidia 8800GT cards, both dual head) and i currently run 2 X screens to manage it
<CShadowRun> i'd love to help you guys test, so just give me a call :)
<CShadowRun> love the sound of xrandr :)
<bryce> CShadowRun: thanks, welcome to the ubuntu-x team :-)
<bryce> CShadowRun: I assume you're using the -nvidia driver?
<CShadowRun> yup :)
<bryce> what are you interested in testing particularly?
<CShadowRun> well i'd like to see the xrandr stuff for multiple heads
<CShadowRun> because xinerama is a bit crap, and so are multiple X screens lol
<CShadowRun> it's a shame to see multiple X screens fall into a state of disrepair, though
<bryce> heh, well you're sort of stuck, since you're using the -nvidia proprietary binary driver
<CShadowRun> ah
<CShadowRun> well i can always put another installation of ubuntu on one of my drives to test with
<bryce> with -nvidia you first need to wait for them to provide xrandr 1.2 support
<CShadowRun> yea
<CShadowRun> i well, i shall just twiddle my thumbs till it comes along
<CShadowRun> unless theres any better ideas :)
<bryce> CShadowRun: are you using nvidia-graphics-drivers-177?  Do you have jaunty installed?
<bryce> if so, one area you could help is by looking at bugs in https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177
<bryce> some documentation for how to check bug reports is at https://wiki.ubuntu.com/X/Triaging
<bryce> bbl - testing new -ati
<CShadowRun> I can probably load jaunty on one of my spare drives and check out some of those bugs :)
<bryce> tjaalton: yep reverting the EXA patch and going back to XAA solved the issue for me
<tjaalton> bryce: ok, so it was the same bug then
<tjaalton> strange that the patch _looks_ ok
<bryce> I'll need to look it over a bit more
<bryce> there's actually 2 bugs - one is why EXA isn't working (which may or may not be the same issue as graber), and the other is why XAA can't be specified
<tjaalton> it's the same
<tjaalton> I bet EXA works for you if you force it in the conf
<bryce> ok lemme try
<bryce> you're right
<bryce> bryce@chideok:~$ grep XAA /var/log/Xorg.0.log
<bryce> bryce@chideok:~$ grep EXA /var/log/Xorg.0.log
<bryce> (**) RADEON(0): Option "AccelMethod" "EXA"
<bryce> btw, I subbed ubuntu-x to radeontool
<bryce> there's no bugs against it, but I think we should probably get the package up to date with what's in airlied's git tree
<tjaalton> ok
<bryce> aha, found one issue...  setting AccelMode to XAA does not actually turn off useEXA, it ust leaves the default
<bryce> ahaa!!
<bryce> tjaalton: ok I understand what's going wrong
<tjaalton> great :)
<bryce> it *is* an EXA problem
<bryce> graber actually isn't getting EXA (neither am I)
<bryce> (==) RADEON(0): No acceleration support available on R600 yet.
<tjaalton> heh
<bryce> there's logic that prevents considering EXA if CHIP_FAMILY_R600
<bryce> so it forces XAA for that
<bryce> however my patch ignored that and set EXA as the default before that condition was checked
<bryce> so I was forcing EXA on R600 for graber and I, thus exposing the EXA problem
<tjaalton> maybe the other bug should be closed as well then (311748), or marked as dupe of the first?
<bryce> secondarily, there's another problem I mentioned above where specifying XAA doesn't switch you to XAA, only to the default
<bryce> tjaalton: no, I think that's a different problem actually
<tjaalton> ok
<bryce> they are reporting seeing that issue on intrepid, which doesn't have my patch so could not be seeing this problem
<tjaalton> ah
<tjaalton> right
<tjaalton> well, now there's a change it might work
<tjaalton> chance
<bryce> yep
<bryce> hmm
<bryce> interesting; in reading the logic it sounds like even XAA is unsupported on this chipset.  bummer
<tjaalton> well, r6xx only gained acceleration support a couple of days ago :)
<tjaalton> but not something for jaunty..
<bryce> well, basic performance seems fine
<bryce> ok, made a new patch... time to build and test
<bryce>  hrm, the j key on my keyboard is not producing j's reliably... not a good keyboard for development of uanty
<tjaalton> heh
<bryce> ok here we go
<bryce> seems okay
<bryce> I can't test setting XAA though
<bryce> at least, not easily right now
<tjaalton> right
<tjaalton> ship it
<bryce> heh, done
<bryce> hmm, with sufficient firefox windows open, performance issues become evident
<bryce> tjaalton: where'd you see r6xx gaining accel support?  The mainline tree seems to still have it disabled
<tjaalton> bryce: not the -ati driver, but the fuss about the DRM code etc. radeonhd has exa support with the experimental code, probably will land in -ati too after a while
<bryce> ah right
<stgraber> yeah, scrolling pages with the ati driver on r6xx with 1680x1050 as resolution is really a pain :)
<stgraber> for now I'm using my laptop as a server and using my Asus EEE (intel graphic :)) with an external screen ssh-ing my laptop
<bryce> stgraber: I've uploaded a new -ati which should fix the problem you were seeing
<bryce> stgraber: sorry it was my lousy coding that broke it
<stgraber> bryce: no problem, thanks for fixing it :)
#ubuntu-x 2009-01-03
<bryce> tjaalton: ok new radeontool snapshot uploaded
<dennda> Hi. With Intrepid: Is it normal that an Intel X3100 (GMA 965) has no direct rendering because LIBGL_ALWAYS_INDIRECT is set? The compiz effects work out of the box, but another OpenGL application requiring OpenGL 2.1 does not. The performance of compiz is not very fast as well. Any pointers?
<tjaalton> dennda: if you have compiz, then DRI is working
<dennda> tjaalton: Then why does glxinfo state something different?
<dennda> tjaalton: And why does that application report OpenGL 2.1 is not available?
<tjaalton> dunno
<dennda> meh, I guess the latter can be answered with "the card doesn't support OpenGL 2.1"
<tjaalton> well, the driver
<jcristau> if you don't want indirect rendering, why do you set LIBGL_ALWAYS_INDIRECT in the first place?
<dennda> jcristau: I didn't do that manually, of course.
#ubuntu-x 2009-01-04
<tjaalton> yeah, xorg bugs below 200..
<tjaalton> but mainly due to reassigning them to the correct package
<tjaalton> which should be the first thing to do to a bug
#ubuntu-x 2010-01-04
<unggnu> hi all
<unggnu> Wasn't the plan to push everything needed for Nouveau before Alpha 1 to got enough testing data? So what is the plan now? I have reade something about the kernel team but without a ppa it doesn't look like I can test nouveau right now in Lucid
<tjaalton> you should ask the kernel team..
<unggnu> tjaalton: How can I check nouveau then?
<unggnu> under Lucid circumstances of course
<unggnu> :)
<tjaalton> no idea
<unggnu> I just think that testing is important because of LTS and the state of the driver but I guess you all know this :/
<tjaalton> it would still need the bits in the kernel
<tjaalton> and that hasn't happened
<unggnu> According to a newsletter the changes aren't so severe if I recall it right
<unggnu> Radeon looks great though at least with an older card and also with 4870 with some minor issues. :)
<unggnu> tjaalton: Couldn't you push a Kernel with the needed patches with a ppa?
<tjaalton> unggnu: me? no
<unggnu> tjaalton: no, in the X ppa
<unggnu> tjaalton: it was a general you :D
<tjaalton> too much work anyway, we have the kernel team for that
<unggnu> ok
<unggnu> Just kick their ... ;)
<unggnu> If it doesn't work it have to be removed which also needs time so the earlier the better
<unggnu> At least many radeon standby problems should be fixed I guess. Intel KMS should work with overlay again - but I am not sure if this changes were already applied in the 2.6.32 kernel.
<jcristau> they weren't
<unggnu> that's bad and I guess they are too severe for backporting?
<jcristau> no
<unggnu> Ok, lets hope they make it since pre i915 couldn't use kms then
<unggnu> afaik
<jcristau> it could.  just without video.
<unggnu> or no video either way :)
<unggnu> +accelerated
<unggnu> Accelerated video is a basic and more important than 3D and of course KMS imho. Btw. does KMS work with i815? Hasn't Intel dropped support for this chipset?
<jcristau> kms is in the i915 driver.  so i830+
<jcristau> i81[05] is still using ums, xaa, dri1, ...
<tjaalton> hmm so 2.10 will drop support for them
<jcristau> well the 3 of them that still exist.
<unggnu> jcristau: :D When was their release date?
<unggnu> So X will be adaptive in future? Starting without root rights if possible and vice versa?
<jcristau> http://en.wikipedia.org/wiki/Intel_810
<jcristau> 10 years ago
<unggnu> Ok, if vesa still works and if it has kms in the future ... :D
<unggnu> Without enough RAM Ubuntu should be run just fine on P3s. Maybe the Linux Intel graphic guys have more time in the future since the big changes should be done now. :)
<tjaalton> you wish
<unggnu> tjaalton: that's for sure :D
<unggnu> They probably just create zxa or something like that :D
<tjaalton> jcristau: I'll pull in the xorg.conf.d/inputclass stuff for testing, tseliot promised to fix the fallbacks ;)
<unggnu> No response from the Kernel team but I guess it is the time :)
<unggnu> anyway, bye guys :)
<tseliot> tjaalton: do you mean in a PPA, right?
<tjaalton> tseliot: just for git
<tjaalton> for now
<tseliot> tjaalton: in a separate branch, not in our master ubuntu branch, right?
<tjaalton> no, in the master branch
<tjaalton> as separate patches
<tseliot> tjaalton: I was asking as I will have to upload a packaging change in X to get the alternatives stuff to work
<tjaalton> just push it
<tseliot> and I would like to upload that without uploading the other patches
<tseliot> how would it work?
<tjaalton> I haven't pushed anything yet
<tseliot> ok
<tseliot> tjaalton: in this case maybe I don't need to put UNRELEASED in the distro
<tjaalton> if you have no other changes..
<tseliot> no, nothing else
<tjaalton> otherwise use several commits with just one functional change in each
<tjaalton> well, on a second thought I won't be pushing this to the branch
<tseliot> good
<tjaalton> apart from the inputclass commit bumping the ABI, they apply ok
<tseliot> yes, I noticed the input ABI bump
<tseliot> tjaalton: ok, pushed
<tseliot> I can upload it later
<jcristau> tjaalton: the main problem with the fallbacks (besides the fact that the code is a bit painful) is i never figured out what behaviour i wanted.  also i need a screen and a device section for each driver.  and add each screen to the serverlayout.  so do i do that only if there's no serverlayout, or if there's a serverlayout with no screen, or a screen with no device, or a device with no driver, or ...
<tjaalton> jcristau: :/
<jcristau> and when you get to the point in the code where you want to add a few devices/screens, the list of screens in the layout is already allocated so you have to go back to add more
<jcristau> so it needs some sitting down which i wasn't able to do yet :)
<tjaalton> yeah it sounds troublesome
 * tseliot nods
<jneves> hi there - I'm having a strange problem with 9.10 and gdm-2.20 - every time I start, gdm fails (the screen is screwed up so I can't read it) - if I git thru recovery more and do "resume" it works fine
<jneves> anyone has a hint on what I should look at?
<jneves> the closest thing to a clue I have is this on gdm logs: Jan  4 13:20:33 net gdm[1366]: DEBUG: gdm_server_start: Server :0 died during startup!
<jneves> brb
 * jneves found the problem - failsafe is starting before gdm - disabling failsafe "solves" this
<jneves> https://bugs.launchpad.net/ubuntu/+source/gdm-2.20/+bug/491483
<ubottu> Ubuntu bug 491483 in gdm "Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is used. (low graphics mode error)" [High,Fix released]
<superm1> why are you using gdm-2.20 in the first place?
<superm1> i personally don't think it should have ever been introduced to the archive
<superm1> it was introduced so xubuntu didn't need to pull in so much of gnome, but i dont think it got enough testing
<jneves> superm1: because in my case gdm doesn't work
<superm1> jneves, what's your problem with gdm?
<jneves> superm1: groups of users go to different networks depending on their authentication (the change is done by pam)
<jneves> superm1: when I logout from one user, gdm fails in strange ways (the user input box does not appear)
<superm1> jneves, so wouldn't the proper thing to do be file bugs on gdm then for these cases?
<jneves> superm1: yes, but I also need to work around the problem in the meantime
<superm1> gdm-2.20 is gonna need work to  be reworked as an upstart job
<superm1> otherwise failsafe-x will kick in as you found
<jneves> superm1: it's working at the moment
<jneves> superm1: it's not that simple - right know, if you have gdm installed, but choose another dm, failsafe-x does the wrong thing
<jneves> superm1: right now, failsafe-x only works with gdm :(
<superm1> jneves, ah
<jneves> superm1: so, yes this is working around a bug - no, the current situation isn't right either ;)
<Duke`_> ^Â£$@+*!!
<Duke`_> execbuf error WTF?!!1
<schilli> I just installed Lucid today.  Ran into an issue on the Eee 1005hab setting up an external monitor...
<schilli> Works fine mirroring, or with one or the other monitor disabled.  When start taking the external monitor to higher resolutions, things get hairy...
<tjaalton> schilli: poulsbo gfx, not supported properly
<schilli> it is known about and being dealt with?
<tjaalton> known, nothing we can do about
<tjaalton> binary blobs ftw
<schilli> but doing the same thing works fine in Karmic.
<jcristau> then use karmic
<schilli> OK
<schilli> Where, if anywhere, should I be of any use to anyone while messing around and trying things out with Lucid?  
<tjaalton> triaging bugs on lp
<bryyce> heya tjaalton
<tjaalton> bryyce: hi, how was the vacation?
<bryyce> very good, got lots of house/shop projects done (or mostly done)
<bryyce> tjaalton, how things going for you?
<tjaalton> I played a lot of Rock Band (& The Beatles), and read two books :P
<bryyce> nice
<bryyce> I played a lot with my son :-)
<bryyce> hey, I saw some email about libdrm on ubuntu-x
<tjaalton> yep
<bryyce> I'm about to email Intel to get some extra priority on that issue, but are there any recent updates about it?
<maxb> I am finding that _intermittently_ Lucid goes into low graphics mode on first boot, but will then work if you restart gdm. I hypothesize some boot-time race condition that leaves X not knowing about its display devices properly. Can anyone suggest how I would pursue this?
<tjaalton> not on the bug report at least, since dec 31
<bryyce> tjaalton, ok but the issue is still occurring?  Anyone beyond sarvatt seeing it?
<tjaalton> maxb: yes, happens here too, haven't figured out why
<tjaalton> bryyce: yes, apparently it affects 945 chips
<bryyce> tjaalton, also you mentioned setting up a ppa with the new libdrm and mesa; did this get set up?
<tjaalton> though I haven't tried it on my 965
<tjaalton> bryyce: no, not yet
<tjaalton> but I did update libdrm git
<bryyce> ok
<bryyce> I guess this could go into the x-testing ppa:  https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa
<tjaalton> yes
<tjaalton> we probably need to (again) use the drm headers from libdrm instead of the kernel, for the new intel at least
<tjaalton> probably radeon too
<bryyce> yeah
<bryyce> that should be fine for x-testing
<tjaalton> bryyce: btw, since intel 2.10 will drop support for !kms, it also means that it won't "support" i81{0,5} anymore
<bryyce> tjaalton, good grief
<tjaalton> but, who cares
<bryyce> well, I care ;-)
<tjaalton> those are ancient
<tjaalton> bah :)
<bryyce> um, not *so* ancient...
<tjaalton> 10y
<bryyce> is 2.10 == 2009Q4?
<tjaalton> yes, slipped though
<bryyce> hmm
<bryyce> oh apparently I haven't had enough coffee
<bryyce> I thought you wrote i8*{0,5}
<tjaalton> hehe
<bryyce> I'm much less concerned with dropping i810/815 support... those have been more or less dead for a while now
<tjaalton> right
<superm1> well hopefully those gracefully fallback to vesa though rather than just intel driver not working and kicking in failsafe-x
<bryyce> superm1, good idea
 * bryyce adds this to his todo list
<tjaalton> the server will be fixed yes
<tjaalton> not to try intel on those
<bryyce> tjaalton, is someone else already planning on doing that?  If so I'll leave it off my todo
<bryyce> btw, iirc we talked some weeks ago about ideas for improving the xserver autodetection stuff...  did those ideas ever make it into a wiki page?  I've largely forgotten what we talked about specifically
<tjaalton> bryyce: it'll probably happen upstream for 1.8, when 2.10 is released. other than that, I don't know
<bryyce> ok, I'll leave it on my todo list to verify it when we merge 2.10
<tjaalton> bryyce: well, no wiki page exists for that. jcristau mentioned some problems earlier today
<Duke`_> Sarvatt, I got an execbuf error with your commit-reverted packages :-(
<Sarvatt> Duke`: yeah me too, both reverts is still ok though but the other doesn't revert cleanly from 2.4.17 :(
<tjaalton> huh, autosyncs are clearly not happening
<tjaalton> libxcb is still at 1.4-1
<tjaalton> building mesa 7.7 locally
<tjaalton> I was wondering to add ubuntu-test branches to git for stuff like this
<jcristau> tjaalton: iirc jd_ switched libxcb source to 3.0 format, maybe that stopped it?
<tjaalton> jcristau: xcb-proto is synced though, lp supports it now
<jcristau> ok
<bryyce> tjaalton, are you noticing any other broken autosyncs besides libxcb?
<tjaalton> bryyce: no, it's the only one, the others are not in testing yet
<bryyce> ok
<bdmurray> bug 434032 is likely a duplicate of something but I can't remember which bug
<ubottu> Launchpad bug 434032 in xserver-xorg-input-evdev "touchpad click disabled" [Low,New] https://launchpad.net/bugs/434032
<Duke`> damin it
<Duke`> google maps raised execbuf error
<tjaalton> bdmurray: replied to the bug
<bdmurray> tjaalton: okay thanks!
<tjaalton> bryyce: libdrm and mesa uploaded to uploaded to the ubuntu-x ppa
<bryyce> tjaalton, excellent
<tjaalton> sigh, mesa tarball size has tripled
<jcristau> argh indeed.
<jcristau> -rw-r--r-- 1 julien julien  8773112 Dec 29 10:28 ../mesa_7.6.1.orig.tar.gz
<jcristau> -rw-r--r-- 1 julien julien 26176639 Dec 25 16:12 ../mesa_7.7.orig.tar.gz
<jcristau> and 7.7 has the glut sources removed.
<tjaalton> it did?
<tjaalton> I diffstat'ed against rc2
<bryyce> whoa, wtf?
<jcristau> i didn't include MesaGLUT-7.7.tar.gz in my 7.7.orig
<tjaalton> ah ok
<tjaalton> progs/objviewer is  now huge
<jcristau> wtf is this stuff?
<tjaalton> well, 7.6.1 didn't have it
<bryyce> tjaalton, I see libdrm in x-testing but not mesa?
<tjaalton> bryyce: still uploading
<bryyce> aha great
<tjaalton> bryyce: so I was wrong about the i810/815, they still use ums on 2.10 (which was tagged a moment ago)
<bryyce> ahh, ok good
<tjaalton> mesa upload finished
<bryyce> tjaalton, I've emailed Intel about this bug.  I sent them the link to the ppa and asked that they up their priority on it
<tjaalton> bryyce: good
<bryyce> also asked yingying's team to try to reproduce (sometimes that helps get things moving)
<bryyce> would be nice to get comment from developers on it
<tjaalton> yep
<bryyce> maybe now that holidays are over it'll get attention
<tjaalton> hope so
<Sarvatt> thats odd, gdm isn't starting randomly on boot, just getting a login prompt sometimes now. I get a could not create session error every startup for a second or two before it draws the panel when it does boot also
<Sarvatt> running that libdrm 2.4.17/mesa from x-testing now to see how things fare re: execbuff while wedged errors
<bryyce> thanks
<bryyce> Sarvatt, is "could not create session" gdm speak for 'X crashed' perhaps?
#ubuntu-x 2010-01-05
<Sarvatt> guess I had a saved session or something -- Window manager warning: Failed to read saved session file /var/lib/gdm/.config/metacity/sessions/108b2bba67abe815cb1259blahblah
<Sarvatt> tjaalton: progs/objviewer is now huge  -- yeah we're deleting everything in there in edgers, huge chunk of stuff thats not even shipped
<Sarvatt> looks like just adding the inputclass stuff bumps the abi, and it was already bumped to 8 earlier just before 1.7.99.2. probably would be easier to just go with xserver 1.8 than try to backport all those patches, that seems a bit tricky?
<ara> tseliot, feliz aÃ±o!
<tseliot> Â¡Gracias ara! Â¡Feliz aÃ±o nuevo!
<tseliot> ara: no se si te has enterado de que hay drivers Nvidia en mi PPA
<ara> tseliot, I saw something, how do I install them? 
<tseliot> ara: you'll have to install/update all of the packages in my PPA
<ara> tseliot, OK, I will do. How do you want me to report back to you? trough the ubuntu-x mailing list?
<tseliot> ara: and edit your xorg.conf (I haven't uploaded the new jockey yet)
<tseliot> ara: sure, that would be fine
<tjaalton> tseliot: you should mention the ppa on the bug too :)
<tseliot> tjaalton: right
<mvo> what bugnumber is that?
<tjaalton> bug 494166
<ubottu> Launchpad bug 494166 in nvidia-graphics-drivers-96 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166
<mvo> thanks
<ripps> ati kms video playback isn't as good as it used to be. Must be because of the lack of overlay video now. Actually, I find that using gl:yuv=4 is faster and causes less tearing than xv does now.
<ripps> in mplayer, that is.
<tseliot> is that with compiz enabled?
<ara> tseliot, I cannot see lucid packages in your ppa
<tseliot> ara: in this PPA? https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
<ara> tseliot, cool, I was looking at your general ppa
<ara> tseliot, grazie
<tseliot> ara: yes, that's what I figured ;)
<tseliot> de nada
<mvo> is anyone working on bug #494627 ? I got a local build of the nv package now because I was bitten by this error (minus two patches I had to disable)
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress] https://launchpad.net/bugs/494627
<tjaalton> mvo: it works now? what did you do?
<mvo> tjaalton: I meged the git fix and that seems to do the trick, if you don't mind I will upload and you can merge it into git
<mvo> tjaalton: or I send you the debdiff, whatever you want
<tjaalton> mvo: either is fine
<mvo> tjaalton: thanks, I will upload then, let me just tidy up my changelog :)
<tjaalton> I suspect it was the "g80: Add a no-op gamma hook so we don't crash on 1.7 servers" commit?
<mvo> yes
<tjaalton> cool, included in .16
<mvo> yeah, .16 is a bit tricky, needs some tweaking to the quilt patches
<mvo> and I was too lazy^Wbusy for that ;)
<tjaalton> heh, ok
<mvo> but it works too (once the patches are commented out)
<ara> tseliot, successfully running nvidia drivers from your PPA, ta! 
<ara> tseliot, I will report any issues I may find
<tseliot> ara: I'm glad to read that they work for you. Thanks for testing
<bjsnider> tseliot, i wanted to mention the control file description should say that vdpau is supported on geforce 8 or newer, not 7, and the driver itself works on geforce 6 or newer, not 7
<tseliot> bjsnider: let me check what I wrote in the control file
<tseliot> bjsnider: good point. Thanks for reporting, I'll correct it.
<bjsnider> cool
<superm1> tseliot, are those transitional packages actually needed?
<tseliot> superm1: we have the chance to make things work even for upgrades from the command line, so why not?
<superm1> tseliot, right
<superm1> tseliot, well let me put it this way, are that many of them needed?
<tseliot> superm1: what would you like to remove?
<superm1> the 185-modaliases and the 185-kernel-source seem superfluous if the nvidia-185-glx already depends on nvidia-current
<superm1> if someone has the glx package installed it will pull them up to nvidia-current
<tseliot> superm1: but if you remove/update nvidia-glx-185, its kernel-source package won't be removed
<tseliot> and this can cause problems
<tseliot> because the module in that package is named nvidia.ko
<tseliot> and we're now using nvidia-$FLAVOUR with aliases to load the right module
<superm1> Ah right
<superm1> and we dont want to be in conflicts/replaces hell with a list of every variant that's been done as c/r
<superm1> sounds sensible then
<tseliot> right
<superm1> lets see what else do i see, --- nvidia-graphics-drivers-190.53.orig/debian/nvidia-current.postrm.in, it's just a skeleton, is that intended so it's easy to add something to later?
<tseliot> superm1: yes and it allows me to share most of the code between the different flavours
<superm1> cool, sounds good
<tseliot> as it's (mostly) a matter of renaming the same file as nvidia-$FLAVOUR.postrm.in
<tseliot> etc.
<tseliot> the new packaging scripts are thought to make my life (and the life of the ones who will deal with nvidia) a little easier :-)
<tseliot> I'm still simplifying the debian/rules and other files
<bjsnider> tseliot, i was studying the code and am i right in assuming that the only thing i need to change from one minor release to another is the changelog?
<tseliot> superm1: BTW execstack seems to work well when called from the command line but fails with signal 8 (at times) if called from the makefile. Any ideas?
<tseliot> bjsnider: yes, this is correct
<superm1> that's awesome! :)
<tseliot> :-)
<bjsnider> wow, that's going to make my life a whole lot easier
<superm1> tseliot, you'll want to go and swing a bat at kees a little bit about that execstack stuff
<bjsnider> i can't screw things up anymore
<superm1> tseliot, i'm not too sure on it
<tseliot> superm1: sure, I'll talk to him again. Some time ago he mentioned some weird behaviour in execstack...
<superm1> tseliot, do you have a particular example that consistently fails?
<tseliot> bjsnider: yes, things should be much easier to change and maintain
<bjsnider> i already added some .in files and an extra variable to reduce the possible screwups in the old version
<kees> superm1, tseliot: I'd noticed the SIGFPE stuff before when I called it on multiple files at once, so I reworked all my earlier packaging examples to call execstack on one file at a time.
<kees> superm1, tseliot: which build is exploding?
<tseliot> superm1: if I extract an nvidia installer and do this manually it works: find . *.so* | xargs execstack -q
<tseliot> kees: it's the new nvidia and here's what fails if done from the makefile ^^
<kees> tseliot: do xargs -n1 and I bet it'll work.
<tseliot> kees: ok, let me try
<kees> tseliot: I only did the -q calls so I could try to figure out which file was blowing it up originally, but the very act of doing one at a time seemed to solve it.
<tseliot> kees: you already mentioned this to me before, therefore I used a for loop so as to call execstack for each file
<tseliot> I'm rebuilding the packages with n1 as we speak
<tseliot> and it didn't fail. Let's see if the markings were disabled
<tseliot> kees: yes, it looks like that did it
<tseliot> thanks a lot :-)
<superm1> tseliot, have you put any thought into how to make beta drivers available to users with this type of packaging?
<tseliot> kees: it's a bit weird that something like this fails though: http://pastebin.ubuntu.com/351824/
<tseliot> superm1: they would replace -current, I guess
<superm1> it looks like it would probably be a s/nvidia-current/nvidia-195/ in debian/rules or similar and rename the tarball appropriately
<superm1> it would probably be good to mention that in your README.Debian.in 
<superm1> just so people know how to do that in the future
<tseliot> superm1: aah, you mean how to create a new flavour
<superm1> tseliot, yeah
<kees> tseliot: yeah, it's really odd.  I was never able to track it down.  :(
<tseliot> sure, I can and will document it
<superm1> i figure you'll probably want flavours in both directions (old and beta)
<tseliot> kees: well, in that specific case it's just two files and I really don't need the loop ;)
<superm1> especially for PPA's like bjsnider's, so a consistent way of doing them will be good
<tseliot> kees: the xargs -n1 is a real life saver though
<tseliot> superm1: creating a new flavour with digits (e.g. -195) would be ok while using letters would break nvidia-common
<tseliot> I can document this as well
<superm1> Yeah that's good to mention
<tseliot> superm1: also if nvidia-common had to deal with -current vs -195 to recommend a driver for jockey, the former would always win
<superm1> yeah that would be the expected behavior
<bjsnider> what about nvidia-beta, and nvidia-old?
<bjsnider> would that break nvidia-common?
<superm1> bjsnider, the problem with using words like that is what happens when you have multiple old's
<superm1> or multiple betas in different series' at the same time
<bjsnider> no, i wouldn't allow multiple betas
<bjsnider> nvidia doesn't release multiple betas at the same time
<tseliot> bjsnider: yep, that would break it
<tseliot> nvidia-195 or -200 or whatever would be fine though
<bjsnider> tseliot, so if i've got nvidia-200 and nvidia-current, will jockey recommend nvidia-current?
<tseliot> there's really no way (apart from ascii string comparison) to tell which driver is newer/better than the other (when using strings)
<tseliot> bjsnider: yes, that's correct
<tseliot> because nvidia-current = nvidia-1000 and 1000 will always win against versions < 1000
<bjsnider> but would the average user not want to pick nvidia-200 if he sees it there, even with the current one being recommended?
<bjsnider> in other words, it might be good to be able to call it "beta" instead of a number
<bjsnider> or even "nvidia-unstable"
<tseliot> we wouldn't support the beta driver but if you really want to call it beta etc. you can modify nvidia-common and put it in your PPA
<tseliot> just replace self.__driver_aliases = {'current': 1000} with self.__driver_aliases = {'current': 1000, 'beta': 2000}
<tseliot> and so on
<tseliot> this is in nvidiadetector.py
<bjsnider> i'll jot that down
<tseliot> a one line patch would do it
<bjsnider> but i don't see why there should only be one nvidia blob in there for each series of cards
<tseliot> or, even better I could make it possible to put the additional driver in a text file
<tseliot> e.g. beta 2000
<tseliot> current 1000
<tseliot> bjsnider: what do you mean?
<tseliot> if your card is compatible with the driver you can install any of them
<bjsnider> right now the current stable release by nvidia is the 190.53
<tseliot> right
<bjsnider> it breaks sound over hdmi, which worked int he 185. so some people need the 185
<bjsnider> kde people should unquestionably be using the beta 195 driver, which has huge xrender improvements
<bjsnider> and really, ubuntu isn't supporting this driver, nvidia is. you're supporting the packaging scripts, but the driver is pre-built
<bjsnider> if the packaging scripts are bullet-proof, then you just say "go tak to nvidia about this" if someone complains
<tseliot> it should be ok to keep additional drivers in a PPA. The fact that I have the time to work on this depends only on the fact that I'm on team swap which means that I can spend most of my time working for the desktop team (as usually I do OEM stuff)
<tseliot> or, in other words, we lack manpower
<bjsnider> oh, i will keep them in the ppa
<bjsnider> manpower is the only problem?
<superm1> bjsnider, so if the modaliases for any of the beta drivers aren't installed they wont be offered in the first place
<superm1> and since i expect beta drivers will live exclusively in a PPA, none of those modaliases would be installed unless intentionally done by a user
<tseliot> superm1: good point
<tseliot> bjsnider: yes, manpower has been the main problem so far
<bjsnider> as far as packaging multiple drivers is concerned?
<tseliot> yep and for bug triaging too
<superm1> just so long as it's possible to produce beta drivers and have experienced users be able to install (albeit if they need to use command line or synaptic that's fine) i'm happy
<tseliot> superm1: there's still the problem of setting alternatives with a command
<superm1> tseliot, well wouldn't they just be treated as a new flavour though that gets registered in the alternatives system (assuming the same packaging base is used)?
<tseliot> superm1: yes but users would still have to set the alternative that they want to use (as we use Manual mode for alternatives)
<superm1> tseliot, oh in this line of thinking, normally is jockey the one setting that alternative that they want to use?
<tseliot> the alternative would be "installed" but not "set" (as the current one)
<tseliot> superm1: yep
<superm1> tseliot, ah well as long as it's documented somewhere i think that's fine
<tseliot> superm1: and it switches back to the alternative for open drivers when a driver is uninstalled/deactivated
<tseliot> sure
<bjsnider> how do they set it as the current one?
<tseliot> hmm... maybe I should make it switch to the open drivers alternative only if the driver that we're disabling is the one in use
<tseliot> bjsnider: update-alternatives --set gl_conf path_to_the_driver
<tseliot> example: update-alternatives --set gl_conf /usr/lib/standard-x11/ld.so.conf
<tseliot> for open drivers
<tseliot> or
<tseliot> for nvidia-current
<tseliot> update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf and so on
<tseliot> (with sudo)
<bjsnider> yeah but that's in the packaging scripts right?
<tseliot> ?
<tseliot> the debian/rules contains 3 lines (I'm not sure about the readme) which explain what to do to set the alternative
<bjsnider> in other words, users don't have to do this every time they update a driver, it's done for them
<tseliot> of course not. Once you set the alternative to a certain driver in remains such (unless you uninstall that driver)
<tseliot> updates won't alter that
<tseliot> to be honest, I fixed this today ;)
<bjsnider> but if i want to go from the 190 to the 195, say i'm using kde for instance, i would have to use jockey or run the update-alternative commands manually, correct?
<tseliot> yep
<bjsnider> ok. i have to know this when people start sending me emails complaining about it
<tseliot> jockey will work only if after the modaliases are installed
<bjsnider> well, yes i know that much
<bjsnider> but that's a change from the old system
<tseliot> right
<bjsnider> the diversions were done by the packaging scripts and what jockey did was properly mark the xorg.conf file
<tseliot> yep
<bjsnider> so i suppose this is philosophical. you want more people using jockey to handle driver installs
<Sarvatt> [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged :(
<tseliot> bjsnider: true
<tseliot> ouch
<bjsnider> what would theoretically happen if someone were to have the nvidia-current package installed, and then nvidia releases a new driver update, and this person goes to the nvidia site, grabs the nvidia installer and uses it to update the driver?
<tseliot> bjsnider: the nvidia installer will stop
<tseliot> thanks to some hooks that I put in nvidia-common
<tseliot> but I haven't tested yet
<bjsnider> haha, really? that's awesome
<bjsnider> i love that
<tseliot> :-)
<bjsnider> it stops even if they run it with sudo
<tseliot> yep
<bjsnider> is there a message that says "you really don't want to be doing this" or something?
<tseliot> the nvidia installer has supported distro hooks for a while (I requested this feature)
<tseliot> it simply says that the installation failed because of the distro hook
<tseliot> but it's still possible to override the hooks
<tseliot> as the install
<bjsnider> well, the average user wouldn't know that
<tseliot> as the installer has an option for that
<tseliot> right
<bjsnider> and if hte hooks are overridden i suppose he would bork his system
<tseliot> yes, but there's nothing we can do about it
<tseliot> and it's ok, as long as users understand that we don't support such altered systems
<bjsnider> one other thing, about nvidia-settings. what's the deal on the elevated-permissions patch?
<tseliot> we use policykit to save settings in xorg.conf
<tseliot> so that you don't have to run nvidia-settings with sudo
<tseliot> (as you're not supposed to do so)
<bjsnider> right but is there a patch? the bug report just kind of died at some point
<superm1> with the xorg.conf.d stuff that's gonna land, we might need to change what's being written to as well
<tseliot> bjsnider: in the package in my PPA
<tseliot> it requires screen-resolution-extra
<tseliot> (from my PPA)
<bjsnider> xorg.conf.d?
<tseliot> superm1: yes, we might end up either patching nvidia-settings and nvidia-xconfig or, even better, talk to Nvidia about it. The latter is what I plan on doing first
<superm1> tseliot, the sooner the better with how long the delay is until stuff is in stable drivers
<tseliot> superm1: I'll do it soon
<tjaalton> nvidia-settings is open source
<tjaalton> so it can be patched
<tjaalton> but.. is there any need?
<tjaalton> local changes should still live in xorg.conf
<tjaalton> admins can use xorg.conf.d, but I don't think tools should
<tseliot> tjaalton: the problem is that nvidia-settings writes input settings in xorg.conf too
<tseliot> thus overriding what's in xorg.conf.d
<tseliot> e.g. touchpad quirks, etc.
<tjaalton> ok
<tjaalton> yeah it should only touch the device section
 * tseliot -> desktop meeting
<tjaalton> and maybe screen etc for multihead
<tjaalton> superm1: does fglrx in lucid work with server 1.7?
<hggdh_> can someone please have a look at bug 503041, and suggest a possible package?
<ubottu> Launchpad bug 503041 in ubuntu "Mouse lags while copying highlighted text." [Medium,Confirmed] https://launchpad.net/bugs/503041
<superm1> tjaalton, not sure, i've not tested it.
<superm1> i've just been maintaining packaging blow ups that are happening with new versions of the driver
<\vish> FWIW , that ^bug is also present in Lucid... I dont see lags that the user mentions but the mouse pointer does jump .. if you are moving the pointer during copy... oddest user scenario though ;)
<tjaalton> superm1: ok
<tjaalton> hggdh_: can't reproduce it on either
<hggdh_> tjaalton: neither can I, but at least three others (\vish included) can. I am tending to x-x-input*, but I am really not sure
<\vish> tjaalton: it happens only while moving the pointer and doing a keyboard copy... i even wonder how the user triggered it unless looking to find this bug ;)
<Sarvatt> tseliot: do you know if your changes to the inputclass matching are going to bump the input abi again?
<Sarvatt> dont want to rebuild all the drivers against abi 9 if so is why I ask
<tseliot> Sarvatt: we're still discussing the right approach with upstream therefore I'm afraid I can't answer your question
<Sarvatt> gotcha, wasnt sure if adding new matches would be something that guarantees the need for an abi bump or not. thank you very much for working on that by the way, seems silly to expect people to fix things post install with how it is now :)
<Sarvatt> i think its really going to be needed in the touchscreen land as well
<Sarvatt> can you just add matches to subsystem vendor and product id's instead of exporting dmi info though?
<jcristau> i still don't understand why quirky hardware can't be fixed in the hardware driver, but oh well.
<tseliot> Sarvatt: what do you mean? Where are you suggesting to do that?
<tseliot> jcristau: feel free to fix things in the kernel if you like ;)
<Sarvatt> like there is a matchvendor and matchproduct which returns devices product/vendor id, but theres a subsystem vendor and product id specific to the hardware that everything has too that could maybe be used without needing the dmi info
<Sarvatt> 04:00.4 System peripheral [0880]: JMicron Technology Corp. xD Host Controller [197b:2384]
<Sarvatt> 	Subsystem: Acer Incorporated [ALI] Device [1025:015b]
<Sarvatt> the 1025:015b part
<jcristau> tseliot: my touchpads work fine thank you.
<tseliot> ;)
<jcristau> you're the one trying to add ugliness to X and xf86-input-synaptics, so i'm just asking why this needs to be there, and so far not getting an answer
<Sarvatt> ahh have to run, i'll read the logs :)
<tseliot> Sarvatt: as regards touchpads, those details are not enough for quirks
<tseliot> jcristau: why do quirks exist? Same answer
<jcristau> not really no
<bryyce> morning
<Sarvatt> that -nv gamma fix works here, -nv works again. 
<Sarvatt> matching subvendor/product id's seems like it would let the quirks work for multiple oem's rebranding the same machine too, for instance I can use packard bell acer or gateway bios's on this machine and it returns a different manufacturer to DMI even though the pci subsystem id's are still the same acer oem ones, I've got a problem with dmi quirk matches in the kernel for i8042 reset not getting applied because they need the manufacturer to be 
<Sarvatt> acer even though the product is the same AOA150 to dmi. 
<Sarvatt> my keyboard layout is also screwed up because udev does the same, i have to manually go in and change the gateway quirk to match the acer one for this bios
<Sarvatt> the brightness up key gives me Â± unless I change it
<bjsnider> ok, nvidia is now including opencl libs with the 195 driver
<Sarvatt> ahh i see where that line of thinking is wrong, I'm thinking windows where that info is exposed for all devices and OEMs release their own customized drivers for their subsystem id ranges but I dont even see that info for a touchpad on linux
<bjsnider> i've found the reason for the huge file size increase in the 195 nvidia blob. it now includes a file called libnvidia-compiler.so
<Sarvatt> hope I'm doing this right - https://bugs.edge.launchpad.net/gtg/+bug/458545
<ubottu> Ubuntu bug 458545 in xserver-xorg-video-intel "[Needs -intel 2.10] Cairo/Gdk shapes not visible on Intel gpu since Karmic" [High,In progress]
<Sarvatt> i dont know how to nominate it for release for xserver-xorg-video-intel, when I try to nominate it it only lets me for gtg
<Sarvatt> so I haven't subscribed ubuntu-sru to it because of that
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/458545
<ubottu> Ubuntu bug 458545 in xserver-xorg-video-intel "[Needs -intel 2.9.1] Cairo/Gdk shapes not visible on Intel gpu since Karmic" [High,In progress]
<tjaalton> use that url instead
<jcristau> why do the titles disagree? :)
<tjaalton> it was edited in between :)
<Sarvatt> yeah i edited it, saw it said 2.10 when i linked it there
<Sarvatt> but was fixed in 2.9.1
<Sarvatt> thanks tjaalton, i tried changing it to https://bugs.edge.launchpad.net/xserver-xorg-video-intel/+bug/458545 but that didnt work
<ubottu> Ubuntu bug 458545 in xserver-xorg-video-intel "[Needs -intel 2.9.1] Cairo/Gdk shapes not visible on Intel gpu since Karmic" [High,In progress]
<tjaalton> you need to have "ubuntu" in there
<tjaalton> no project named x-x-v-i
#ubuntu-x 2010-01-06
<Sarvatt> i haven't had an execbuff while wedged on this machine for 2 days now using the ubuntu-x stuff, i'm saying this because that usually triggers it soon after :) i have been using 2.6.31-16 though because I need working suspend/resume during the week and the lucid kernel still has the flickering problems post resume
<tjaalton> but you've been able to reproduce it with that kernel?
<Sarvatt> yeah I have had it with this kernel before in the past, but I was using intel 2.9.99x at the time as well, never tried just 2.4.17 + this kernel 
<tjaalton> sounds like they are good to go then
<Sarvatt> i need to build a kernel with the patches attached to that bug to try to get more info for them to figure it out
<tjaalton> to me it sounds like a bad combination of components
<tjaalton> and not a real bug
<Sarvatt> hope so, but its affecting people on gentoo and arch as well at least and only i915-i945 from what I can see
<tjaalton> ok
<Sarvatt> hmm seem to have hit a snag with tseliot's new nvidia packages
<Sarvatt> http://pastebin.com/f12e6f5a4
<Sarvatt> looks like i had a custom /etc/modprobe.d/nvidia.conf with some options I was using before (that were commented out now) that didnt get replaced and screwed things up around line 243
<Sarvatt> getting both of these in jockey too, dont know if thats normal
<Sarvatt> kmod:nvidia_current - nvidia_current (Proprietary, Disabled, Not in use)
<Sarvatt> xorg:nvidia-current - NVIDIA accelerated graphics driver (Proprietary, Disabled, In use)
<bjsnider> jockey is used to do the update-alternatives command
<bjsnider> which is how you get "enabled"
<Sarvatt> yeah pasted the jockey log and those two were listed in jockey-text
<Sarvatt> 2010-01-05 20:40:35,378 WARNING: /sys/module/nvidia_current/drivers does not exist, cannot rebind nvidia_current driver 2010-01-05 20:40:45,377 WARNING: modinfo for module nvidia failed: ERROR: modinfo: could not find module nvidia 2010-01-05 20:40:45,378 ERROR: XorgDriverHandler.enable(): package or module not installed, aborting
<Sarvatt> i get that when i try to enable the xorg:nvidia-current
<bjsnider> dkms status
<bjsnider> should say what driver, if any, is installed
<Sarvatt> nvidia-current, 190.53, 2.6.32-9-generic, x86_64: installed
<Sarvatt> the kmod activates fine its the xorg one that wont, theres 2 seperate entries in jockey
<superm1> i think jockey's nvidia handler might need a patch actually to not list that twice
<superm1> Sarvatt, make sure to let tseliot know about that issue if nvidia.conf exists before starting so that he knows it needs to get cleaned up in the jockey handler
<superm1> or maybe even the packages themselves
<bjsnider> it's telling you whatt he problem is: /sys/module/nvidia_current/drivers does not exist
<Sarvatt> test
<Sarvatt> oh ok message wasnt going through
<Sarvatt>   /sys/module/nvidia/ exists but no nvidia_current, nvidia is listed in lsmod but modinfo doesnt know about nvidia just nvidia-current
<Sarvatt> because it started with a / :)
<superm1> Sarvatt, i want to say that special /etc/modprobe.d/nvidia.conf resolves nvidia to be nvidia-current or something like that
<superm1> which allows you to have multiple nvidia.conf's on your system
<superm1> *nvidia.ko's
<Sarvatt> ahh
<superm1> so if jockey failed to set that config because you had something there, it's gonna cause more pain later
 * Sarvatt tries to figure out how to fix this
<superm1> remove the driver packages and your nvidia.conf and reinstall them i think
<superm1> def something that tseliot will need to account for
<Sarvatt> i'm just not near the box anymore and have to figure out how to use jockey-text to reinstall it because I thought I read manually installing nvidia-current wont set up alternatives right :D
<Sarvatt> ah yeah alias nvidia nvidia-current
<Sarvatt> i purged it and removed the .conf, rebooted, installed through jockey and it failed
<Sarvatt> i think it modprobed before linking the nvidia.conf or something that time
<Sarvatt> so it failed in failsafe mode and gave the error message but its working fine after rebooting
<Sarvatt> nope, using swrast
<Sarvatt> ERROR: XorgDriverHandler.enable(): package or module not installed, aborting
 * Sarvatt wonders if theres some other required package not getting pulled in here
<bryyce> ick
<bjsnider> Sarvatt, sudo update-alternatives --set gl_conf $(ld_so_conf_path)
<bjsnider> sudo ldconfig
<bryyce> heya bjsnider, don't know if we've met.  welcome to ubuntu-x  :-)
<Sarvatt> whats the ld_so_conf_path supposed to be?
<superm1> bryyce, bjsnider is the one maintaining the vdpau PPA with all sorts of newer drivers and stuffs
<bryyce> sweet
<bjsnider> Sarvatt, hold, let me wade through these variables and reconstruct it
<bryyce> ah yes I remember running across that ppa
<bjsnider> yes you did
<bjsnider> i packaged that beta driver that got released because somebody broke an nda with nvidia and you asked me to remove it
<bryyce> oh yeah
<bjsnider> Sarvatt, /usr/lib/nvidia-current/ld.so.conf
<bryyce> thanks again; that was looking like it could have turned into a big political mess but it all worked out well
<bjsnider> no prob
<bjsnider> i didn't leak it though. it appeared on a russian site and people were already installing it. the cat was out of the bag. nvidia should have just let it go
<Sarvatt> not the /etc/ld.so.conf.d/GL.conf that got installed with the xserver update?
<Sarvatt> they both are the same anyway
<bjsnider> that's the command alberto says you need to run to manually enable the driver
<bjsnider> does anybody know anything about opencl?
<bjsnider> i'm trying to figure out of this huge shared library has to do with it
<bjsnider> nvidia has helpfully not documented its existence or purpose at all
<Sarvatt> thats weird, the libglx.so / libdri.so alternatives didnt get set up in the xserver-xorg-core.postinst like they should have
<Sarvatt> Can't call method "slave" on an undefined value at /usr/sbin/update-alternatives line 1017.
<Sarvatt> ah hah
<bjsnider> what is on that line?
<Sarvatt> http://pastebin.com/d73f439a3
<Sarvatt> those slave alternatives arent getting set up here,  ldconfig -p | grep libglx returns nothing
<bjsnider> what is the undefined value?
<Sarvatt> supposed to be generic ones set up i thought and then alternatived out when you switch
<bjsnider> can you cat the script and look at line 1017?
<Sarvatt> lrwxrwxrwx 1 root root 27 2010-01-05 20:55 /usr/lib/xorg/modules/extensions/libglx.so -> /etc/alternatives/libglx.so    lrwxrwxrwx 1 root root 38 2010-01-05 20:55 /etc/alternatives/libglx.so -> /usr/lib/nvidia-current/xorg/libglx.so
<Sarvatt> that looks right but
<Sarvatt> [    0.172246] (II) Loading /usr/lib/xorg/modules/extensions/standard/libglx.so
<Sarvatt> in Xorg.0.log
<bjsnider> standard?
<bjsnider> that path doesn't exist in the postinst script
<bjsnider> Sarvatt, try removing /usr/lib/xorg/modules/extensions/standard/libglx.so
<Sarvatt> hmm I think its here
<Sarvatt>              --slave #LIBDIR#/xorg/modules/extensions/libdri.so libdri.so #LIBDIR#/xorg/modules/extensions/standard/libdri.so \
<Sarvatt>              --slave #LIBDIR#/xorg/modules/extensions/libglx.so libglx.so #NVIDIAEXTENSION#/libglx.so
<Sarvatt> need to look at the full postinst for nvidia-current, i'm just looking at the diff and its missing a bunch of it but libdri.so is getting set up right and libglx.so isnt
<bjsnider> --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/xorg/modules/extensions/standard/libglx.so \
<Sarvatt> --slave #LIBDIR#/xorg/modules/extensions/libglx.so libglx.so #NVIDIAEXTENSION#/xorg/libglx.so is what it should be I think
<Sarvatt> /usr/lib/nvidia-current/xorg/libglx.so
<Sarvatt> thats where it is here
<bjsnider> that file exists?
<Sarvatt> yep
<Sarvatt> its in xorg/ not just nvidia-current/
<Sarvatt> dont know how it worked for anyone if thats the case though
<Sarvatt> i mean the drivers work i just dont get any gl outside of swrast
<bjsnider> it's been working for people as far as i know
<bjsnider> ok, maybe that's it
<bjsnider> maybe nobody but you has tested glx
<Sarvatt> thats just in the nvidia-current.postinst.in, in nvidia-current.postinst it has             --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/nvidia-current/xorg/libglx.so
<bjsnider> ok, well the .in is used to generate the other
<bjsnider> so NVIDIAEXTENSION must be the correct path, ie. /usr/lib/nvidia-current/xorg
<Sarvatt> --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/nvidia-current/xorg/libglx.so is what it is in /var/lib/dpkg/info/nvidia-current.postinst too, so much for that
<Sarvatt> sarvatt@sarvatt-hp:/var/lib/dpkg/info$ ll /usr/lib/xorg/modules/extensions/libglx.so
<Sarvatt> lrwxrwxrwx 1 root root 27 2010-01-05 20:55 /usr/lib/xorg/modules/extensions/libglx.so -> /etc/alternatives/libglx.so
<Sarvatt> sarvatt@sarvatt-hp:/var/lib/dpkg/info$ ll /etc/alternatives/libglx.so 
<Sarvatt> lrwxrwxrwx 1 root root 38 2010-01-05 20:55 /etc/alternatives/libglx.so -> /usr/lib/nvidia-current/xorg/libglx.so
 * Sarvatt is stumped.
<bjsnider> do you still have /usr/lib/xorg/modules/extensions/standard/libglx.so?
<Sarvatt> yep, and the alternatives are switching away /usr/lib/xorg/modules/extensions/libglx.so/libdri.so instead of the ones in standard/
<Sarvatt> if you dont have nvidia-current installed it sets up alternatives for  /usr/lib/xorg/modules/extensions/libglx.so to  /usr/lib/xorg/modules/extensions/standard/libglx.so
<bjsnider> if the alternatives are switching away, why is your system trying to load the standard alternative?
<bjsnider> the standard file should be a link. where does it point to?
<Sarvatt> sarvatt@sarvatt-hp:/var/lib/dpkg/info$ sudo update-alternatives --remove gl_conf /usr/lib/nvidia-current/ld.so.conf 
<Sarvatt> update-alternatives: using /usr/lib/standard-x11/ld.so.conf to provide /etc/ld.so.conf.d/GL.conf (gl_conf) in auto mode.
<Sarvatt> sarvatt@sarvatt-hp:/var/lib/dpkg/info$ sudo update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf 
<Sarvatt> update-alternatives: using /usr/lib/nvidia-current/ld.so.conf to provide /etc/ld.so.conf.d/GL.conf (gl_conf) in manual mode.
<Sarvatt> Can't call method "slave" on an undefined value at /usr/sbin/update-alternatives line 1017.
<Sarvatt> guess i should do some googling on  Can't call method "slave" on an undefined value :)
<bjsnider> i'd like to know what's on that line
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554136
<ubottu> Debian bug 554136 in dpkg "u-a: --set fails with undefined value on non-registered paths" [Normal,Fixed]
<Sarvatt> i updated my update-alternatives with that commits changes and now i get
<Sarvatt> sarvatt@sarvatt-hp:/var/lib/dpkg/info$ sudo update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf
<Sarvatt> update-alternatives: error: alternative /usr/lib/nvidia-current/ld.so.conf for gl_conf not registered, not setting.
<Sarvatt> http://pastebin.ubuntu.com/352132/
<Sarvatt> thats my update-alternatives --display gl_conf output
<Sarvatt> There is only one alternative in link group gl_conf: /usr/lib/standard-x11/ld.so.conf
<Sarvatt> so the alternatives arent getting registered with the nvidia-current.postinst for some reason
<bjsnider> yes, because of that error that points to "line 1017"
<Sarvatt> 2010-01-05 20:55:48 update-alternatives: run with --install /etc/ld.so.conf.d/GL.conf gl_conf /usr/lib/nvidia-current/ld.so.conf 9700 --slave $
<Sarvatt> 2010-01-05 20:55:48 update-alternatives: link group gl_conf updated to point to /usr/lib/nvidia-current/ld.so.conf
<Sarvatt> installing from aptitude instead of through jockey, lets see if this works this time
<Sarvatt>   Selection    Path                                Priority   Status
<Sarvatt> ------------------------------------------------------------
<Sarvatt> * 0            /usr/lib/nvidia-current/ld.so.conf   9700      auto mode
<Sarvatt>   1            /usr/lib/nvidia-current/ld.so.conf   9700      manual mode
<Sarvatt>   2            /usr/lib/standard-x11/ld.so.conf     500       manual mode
<Sarvatt> thats more like it
<Sarvatt> nope still [    0.106192] (II) Loading /usr/lib/xorg/modules/extensions/standard/libglx.so... ah well, enough messing around for tonight :D
<Sarvatt> wonder why it installs the nvidia libglx.so to /usr/lib/xorg/extra-modules as well
<Sarvatt> ah hah
<Sarvatt> i moved /usr/lib/xorg/extensions/modules/standard out of the way and it loads the libglx.so from /usr/lib/xorg/modules/extensions/ like it should which works with the alternatives
<Sarvatt> i guess xserver will look in subdirectories before following a link or something
<Sarvatt> [    0.155733] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
<Sarvatt> [    1.220630] (II) Module glx: vendor="NVIDIA Corporation"
<Sarvatt> so i guess standard/ needs to be moved somewhere else
<Sarvatt> hmm, need to leave libdri.so in standard/ the way it is now, just moving the libglx.so from in there works
<Sarvatt> otherwise i get [    1.324256] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
<Sarvatt> dlopen: /usr/lib/xorg/modules/extensions/libdri.so: cannot open shared object file: No such file or directory
<Sarvatt> anyway, enough messing with it tonight for real, wifes bugging me :D thanks for the help
<bjsnider> nvidia does not change libdri
<mvo> I reopened #494627 because my initial fix is no good, I attached a (trivial) new one - could someone please have a quick look if that makes sense and is upstreamable? it makes my nv system happy again
<tjaalton> mvo: so that fix alone is enough to fix it?
<mvo> tjaalton: yes, that makes it work for me - the fix itself is pretty obvious, but I don't know enough about the background to be 100% sure its the right fix. ie it might be a mandatory function (gamma_set). but I guess even then crashing is not the right approach ;)
<mvo> tjaalton: that diff plus a revert of the stub function and my -nv system is back, the previous patch fixed the crash but colors were all messed up
<tjaalton> mvo: ok, I guess the next step would be to post it upstream for a review then :)
<mvo> (but only after cold restart, reboot was not enough this is why I did not catch it yesterday)
<mvo> tjaalton: ok, cool. I will do that. 
<tjaalton> I mean if there is a chance of regressing other drivers
<tjaalton> http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches
<mvo> oh, nice. I did not know this page
<tjaalton> it's quite fresh
<tjaalton> and new
<tseliot> tjaalton: do you mind if I upload my changes to X from git?
<tjaalton> tseliot: nope
<tseliot> tjaalton: also, it looks like libxvmc (in Ubuntu) is not maintained in git. Shall I simply upload my changes?
<tjaalton> tseliot: there were no ubuntu changes before..
<tjaalton> well, occasionally yes, but
<tjaalton> whatever you prefer
<tseliot> tjaalton: I think these changes are something we'll have to maintain as they are required by the new alternatives system
<tseliot> "we" meaning "I" ;)
<tseliot> tjaalton: (ignore the noise in the changelog which is from my ppa) this is the debdiff: http://pastebin.ubuntu.com/352317/
<jcristau> ewww removing possibly modified.
<jcristau> +conffiles
<tseliot> yes, I know
<tseliot> if you can think of better solutions, I'm all for it
<tseliot> the problem is
<tseliot> that if the file already exists
<jcristau> i'd say alternatives in /etc are a bad idea
<tseliot> the alternative slave won't be installed
<tseliot> it's just a link there
<tseliot> which points to /usr/lib/whatever/realfile
<jcristau> it's still a bad idea.  /etc is the admin's territory.
<tseliot> the use-case would be an admin which sets a different path to libXvMC.so.1 in /etc/X11/XvMCConfig
<jcristau> i guess so.  i have no idea how xvmc works.
<tseliot> jcristau: would it be better to rebuild the package without that path and rely on ld.conf.d to find the library instead?
<jcristau> as i said, i don't know how xvmc works, or what uses this /etc/X11/XvMCConfig
<tseliot> ok
<jcristau> i'm just saying that from a packaging pov, having something in /etc which is managed by alternatives is asking for trouble
<tseliot> I see your point
<tseliot> libXvMCW_la_CFLAGS =				\
<tseliot> 	$(AM_CFLAGS)				\
<tseliot> 	-DXVMC_CONFIGDIR=$(sysconfdir)/X11		\
<tseliot> sysconfdir is what it uses
<tseliot> hmm..
<tseliot> superm1: thoughts on this ^^
<tseliot> ?
<tseliot> jcristau: would it be better if I changed the place where libxvmc looks for settings to /usr/lib/whatever and used alternatives there? (I suspect that admins would be angry either way though)
<jcristau> yes, it's probably better
<tseliot> ok
<bjsnider> tseliot, i found out why the 195 blob is so much bigger than previous blobs
<tseliot> bjsnider: why?
<bjsnider> there is a massive shared library named libnvidia-compiler.so.xxx
<bjsnider> they have also, without documenting it, decided to include the opencl headers/shared libraries
<bjsnider> and i think the aforementioned file has to do with that
<bjsnider> but without any documentation, i can't be sure
<tseliot> aah
<bjsnider> i thought you might know
<bjsnider> it's /usr/lib/libnvidia-compiler.so.xxx.xx
<bjsnider> and there's also a lib32 version
<tseliot> I spent more time making sure that the stack markings on those libraries were disabled
<bjsnider> stack markings?
<tseliot> without noticing what those libraries do ;)
<tseliot> yep
<bjsnider> i don't know what that means
<tseliot> let me find the actual bug report
<tseliot> bug #409456
<ubottu> Launchpad bug 409456 in nvidia-graphics-drivers-96 "upstream compiled binaries built without stack flags" [Medium,Fix released] https://launchpad.net/bugs/409456
<tseliot> see the description
<bjsnider> wel, whatever. is there any way i can look inside the first few lines of that file and see what it's doing at the start?
<tseliot> what file? The proprietary library?
<bjsnider> yep
<tseliot> it's proprietary. It meant for you not to read it ;)
<bjsnider> well, i guess i'll toss it in the legacy build scripts, since everything else in that directory is in there too
<bjsnider> sarvatt had some trouble getting the glx side of the new driver to work last night
<bjsnider> jockey didn't do the update-alternatives successfully
<tseliot> bjsnider: because I haven't uploaded jockey yet
<tseliot> or any other piece of the puzzle
<bjsnider> oh, well that would explain it
<tseliot> tjaalton: I think I'll use a patch (with quilt) instead modifying the package (libxvmc) directly. Would this be better?
<Sarvatt> tseliot: I saw another problem when I was testing out your packages, if someone already has an /etc/modprobe.d/nvidia.conf the new one with the alias wont get linked
<tseliot> Sarvatt: true but how can we check that in advance?
<tseliot> users could even add some random diversion on the kernel module and break things
<Sarvatt> can you just call it something else that people wouldnt normally have?
<tseliot> (just an example)
<tseliot> in theory (unless they are advanced) users wouldn't have an nvidia.conf file in that directory
<Sarvatt> all the tweaking guides tell you to make /etc/modprobe.d/nvidia.conf, i had a custom powermizer setup in there
<tseliot> :-/
<tseliot> shall I get rid of any conf files that mention nvidia in that directory? It seems a bit excessive to me
<Sarvatt> i'll try changing it to link it to /etc/modprobe.d/nvidia-current.conf and put my old nvidia.conf there and see if it works
<tseliot> Sarvatt: wait, what's the content of your .conf file?
<tseliot> or what used to be the content of that file?
<Sarvatt> i deleted it already :( it had some NVreg_RegistryDwords= options to change the default powermizer settings though
<tseliot> Sarvatt: ok and it referred to the nvidia module, not nvidia-current or some other name
<tseliot> so I guess it's just a matter of finding a different name for that link
<Sarvatt> yeah, imagine it would just either ignore those things because it cant find nvidia if the alias one gets loaded before, or load those options then alias it after if it loads the linked one later
<tseliot> we could use something like /etc/modprobe.d/nvidia-graphics-drivers.conf perhaps?
<tseliot> hoping that users won't bother writing names which are this long
<tseliot> ;)
<Sarvatt> yeah thats a pretty safe bet there :)
<Sarvatt> so we'd need an updated jockey for the libglx.so alternative to work? I had to move /usr/lib/xorg/modules/extensions/standard/libglx.so out of the way for things to work right, it was loading that even though the alternative was set up right for /usr/bin/xorg/modules/extensions/libglx.so
<tseliot> you'll need an updated X, jockey, etc.
<tseliot> I'll upload the different pieces soon
<superm1> tseliot, setting up xvmc properly with nvidia is less important these days
<superm1> all the cool kids just use vdpau when they use nvidia
<superm1> so it might not be worth the troubles to configure it anymore and introduce a delta to libxvmc
<tseliot> superm1: something like this wouldn't be big: http://pastebin.ubuntu.com/352410/
<tseliot> it's a quilt patch
<superm1> only worry would be is if there is a lot of documentation that claims people go modify the old location
<tseliot> right, but that path won't be used any longer and we can document that
<superm1> Ok
<tseliot> superm1: is that configuration file used for anything else or only for nvidia, etc.?
<superm1> tseliot, i think it's only ever used when you do something with nvidia xvmc instead
<tseliot> ok, so no one should want to modify it
<tseliot> (in theory)
<superm1> right
<tseliot> ok, good
<jcristau> Sarvatt: are you still running with powersave=0, or did that get fixed?
<Sarvatt> not fixed here without that, only fixed with powersave=0 with that one remove render reclock support commit here, i've just been using 2.6.31 if I need to suspend but other people in one of those bugs said reverting another commit worked without powersave=0
<Sarvatt> trying to find that bug to find the commit now
<Sarvatt> http://bugzilla.kernel.org/show_bug.cgi?id=14781
<ubottu> bugzilla.kernel.org bug 14781 in Video(DRI - Intel) "181a533 is causing severe screen flickering on 965GM" [High,Resolved: patch_already_available]
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=patch;h=cf74ecbbff3e3b45bae61d28d2220f74d853e2f0 still needs powersave=0 here..
<jcristau> Sarvatt: presumably with powersave=0, that patch doesn't change anything?
<Sarvatt> i'm assuming theres more to powersave than render reclock or else it wouldnt make sense that its fixed with powersave=0 and that patch
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=181a5336d6cc836f05507410d66988c483ad0154 is the one people in the kernel bugzilla were saying could be reverted from 2.6.32 to fx it without needing powersave=0
<Sarvatt> powersave AND the remove render reclock commit that doesnt apply to 2.6.32 I mean
<Sarvatt> i havent been able to test it at all, been trying to focus on one bug at a time and thats minor compared to the random crashing here but I imagine it's alot more important to you since you get it at first boot instead of just after resume
<jcristau> i'll try debian's .32 with powersave=0 when i get back to my 945 laptop..
<tjaalton> tjaalton: actually, I think it's more work to update a patch if the packaging changes
<tjaalton> ij
<tjaalton> damn
<tjaalton> "uh"
<tjaalton> oh tseliot went already
<tjaalton> that's why I'm talking to myself
<Sarvatt> i dont understand why .32 with powersave=0 doesn't work unless that remove render reclock support commit is applied too but i'm 100% positive it doesn't here
<Duke`> more and more execbuf errors occuring... :(
<wind-rider> hi
<wind-rider> i was wondering how i could configure my wacom tablet since in lucid there is no Xorg.conf to edit
<wind-rider> can somebody tell me?
<wind-rider> the tablet works, but I would like to set the mouse to relative mode
<bryyce> tjaalton, any chance we'll get -wacom for a3?
<bryyce> tjaalton, er, I mean a2
<tjaalton> bryyce: sure, it only depends if it's based on the (non-available) debian version or a complete fork
<jcristau> no news from ron then?
<bryyce> given that a2 is coming up RSN, if we want it in for a2 does that imply we'd need to do a fork?  What would that entail, just carrying a git snapshot or branch, or...?
<tjaalton> jcristau: not since the latest email
<jcristau> hmm ok
<tjaalton> he said he had some snapshots for a select few to test, and the results weren't too encouraging
<tjaalton> and I asked for one to upload to a ppa first
<tjaalton> bryyce: either 0.10.3 or a newer snapshot
<bryyce> I'm wondering if the results weren't encouraging, is it going to be any worse than the current situation?
<tjaalton> well, apparently it would be worse to let people think there is a working driver available
<tjaalton> that was his reasoning
<bryyce> hah
<bryyce> hrm
<bryyce> well, if it only takes pulling a git snapshot of xf86-input-wacom and there are no other dependencies, it sort of seems like it would at least be moving us in the right direction
<tjaalton> it's just re-inventing the packaging that is pointless. I'd rather have whatever he has now, but the git hasn't been updated for a month (and doesn't have any packaging bits)
<bryyce> oh the packaging needs done too hmm
<bryyce> alright, well guess we can just put in a release note that wacom is totally broken and push it to a3
<wind-rider> tjaalton: do you know how a wacom tabled could be configured on ubuntu lucid?
<Sarvatt> wonder if the 0.10.1 i packaged up in edgers a few months ago even works, time to dig out a tablet
<tjaalton> basically it's pretty similar to any other input driver, but there's xsetwacom and possibly other tools as well
<tjaalton> wind-rider: you don't
<wind-rider> tjaalton: one can't?
<tjaalton> wind-rider: because there is no driver. evdev is used by default, and if it doesn't work.. well too bad.
<bryyce> wind-rider, see what we were just talking about ;-)
 * hyperair wonders if anyone here uses the nvidia 9643 driver
<tjaalton> it has been on the relnotes AIUI
<wind-rider> tjaalton, bryyce: the tablet works, but i do not know how to configure it
<wind-rider> there is pressure support, etc
<jcristau> still no libxcb sync?
<tjaalton> jcristau: no, requested though
<tjaalton> for a manual sync
<tjaalton> wind-rider: so evdev doesn't support such features
<bryyce> tjaalton, I don't see mention of it at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview
<bryyce> I'll add it
<wind-rider> tjaalton: evdev does support pressure support, but no relative / absolute setting?
<tjaalton> wind-rider: I don't know
<Sarvatt> ummm
<Sarvatt> the xf86-input-wacom I packaged up on edgers a few months ago works fine in current lucid
<Sarvatt> just tested with a graphire 3 and an intuos 3
<Sarvatt> http://pastebin.com/f798362b2
<Sarvatt> all it took was some minor build rule adjustments
<wind-rider> tjaalton, Sarvatt, bryyce: http://pastebin.ca/1740737 <--- here is an extract of Xorg.0.log
<wind-rider> it sets the devices to absolute mode, but i'd like to use relative mode for the mouse
<tjaalton> wind-rider: so try with xinput
<jcristau> ooh xf86-input-kbd got pulled from lucid?
<tjaalton> jcristau: yep
<Sarvatt> wind-rider are you using xorg-edgers?
<tjaalton> wanted to go to universe, so no reason to keep it there
<wind-rider> Sarvatt: not yet
<Sarvatt> oh our logs look the same is why i asked
<wind-rider> tjaalton, Sarvatt: i can call xinput set-mode "Wacom Graphire3" RELATIVE, but then I set this mode also for pen and eraser?
<wind-rider> there are no separate pen, eraser and mouse devices
<wind-rider> when calling xinput list
<jcristau> yes.  for that you need a wacom driver.
<tjaalton> surprise, you are not using the wacom driver
<bryyce> I've added a known-issue for this at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview
<wind-rider> ok, now it's clear
<wind-rider> thx for your help
 * bryyce wordsmiths a bit
<jcristau> tjaalton: i'll try to talk to ron on irc, see where things stand..
<tjaalton> bryyce: nice, it's a bit incorrect though. wacom-tools -based driver doesn't work with xserver 1.7, it's not due to the hal removal
<tjaalton> jcristau: thanks, I've seen him too every now and then
<bryyce> tjaalton, better?
<tjaalton> bryyce: yeah, thanks
<bryyce> Sarvatt, I'd be interested in hearing more widespread testing of your wacom edgers package, although I'm hesistant to point people at that from the release notes
<bryyce> if the package is good enough for us to point people to, then we ought to just put it in lucid I suppose.
<Sarvatt> its not working, i am using evdev, sorry about that
<tjaalton> hehe :)
<Sarvatt> looks like I cant rebuild the old wacom-tools thjaeger sent me that was working right on xserver 1.7 now either :(
<Sarvatt> ../../../src/xdrv/xf86Wacom.c:398: error: too few arguments to function âInitValuatorAxisStructâ
<Sarvatt> that was back in july that it was working
<bryyce> I thought about mentioning that "some limited functionality may be available from use of evdev", but then I thought, if they're reading the release note about wacom, they probably already know this.  ;-)
<Sarvatt> he's got a newer one in his PPA but its using hal only and not working either
<Sarvatt> tried making a little udev rule for it but no luck -- http://pastebin.ubuntu.com/352562/
<bryyce> okie doke.  If anyone finds out anything new/interesting about wacom in the next couple days let me know asap, otherwise we'll just check in again on it in a couple weeks
<Sarvatt> is the rule wrong maybe?
<tjaalton> Sarvatt: no, it loaded fine
<tjaalton> preinit failed
<tjaalton> though I guess it should use some callout app like with hal, to init all the devices
<jcristau> try 0.10.3?  also add some ErrorFs in preinit to see why it fails?
#ubuntu-x 2010-01-07
<ara> tseliot, ping
<tseliot> ara: pong
<ara> tseliot, hey!, when I try to activate compiz it gives me an error "desktop effects could not be activated", but I don't get any errors in Xorg.0.log or syslog
<ara> tseliot, any ideas where to look?
<tseliot> ara: what does "glxinfo | grep direct" say?
<ara> tseliot, Error: couldn't find RGB GLX visual or fbconfig
<tseliot> ara: I need the output of "update-alternatives display gl_conf" and your /var/log/Xorg.0.log
<ara> tseliot, alright
<ara> tseliot, http://paste.ubuntu.com/352857/ 
<ara> tseliot, http://paste.ubuntu.com/352859/
<tseliot> ara: did it work when you first tried my packages?
<tseliot> "it" being compiz
<ara> tseliot, no, I just tried it today
<ara> s/no/I hadn't tried before :)
<tseliot> ara: what do "lsmod" and "dmesg" say?
<tseliot> the log looks fine...
<ara> tseliot, http://paste.ubuntu.com/352861/
<ara> tseliot, http://paste.ubuntu.com/352863/
<tseliot> the right kernel module seems to be there too
<tseliot> ara: let's see your xorg.conf
<ara> tseliot, http://paste.ubuntu.com/352866/
<tseliot> ara: and the output of this command: ldd /usr/bin/glxinfo
<ara> tseliot, http://paste.ubuntu.com/352867/
<tseliot> ara: and the output of this command: cat /etc/ld.so.conf.d/GL.conf
<tseliot> if the file is empty then I know what to fix
<tseliot> also see if /usr/lib/nvidia-current/ld.so.conf exists
<ara> ara@sushirider:/var/log$ cat /usr/lib/nvidia-current/ld.so.conf 
<ara> /usr/lib/nvidia-current
<ara> ara@sushirider:/var/log$ cat /etc/ld.so.conf.d/GL.conf 
<ara> /usr/lib/nvidia-current
<tseliot> that's correct too
<tseliot> hmm...
<tseliot> ara: does nvidia-settings work?
<tseliot> or does it only show a limited number of options
<tseliot> ?
<ara> tseliot, it works
<ara> tseliot, but "Fail to query the GLX server vendor."
 * bryyce waves
<tseliot> ara: ok, let's see if glx exists and what it points to (let's pretend that the X log lied)
<tseliot> bryyce: hey
<ara> hey bryyce
<bryyce> NFI why I'm awake at 4:30am
<tseliot> ara: which means that you should check "ls -l /usr/lib/nvidia-current/xorg/libglx.so",  "ls -l /etc/alternatives/libglx.so" and "ls -l /etc/alternatives/libglx.so"
<tseliot> bryyce: :-)
<tjaalton> what about just running glxinfo
<ara> tseliot, those 3 are there
<ara> (with 777 permissions)
<ara> tseliot, http://paste.ubuntu.com/352880/
<tseliot> the 2nd and the 3rd are the same
<tseliot> I meant "ls -l /usr/lib/xorg/modules/extensions/libglx.so"
 * tseliot blames it on the clipboard
 * ara blames Ctrl+C/Ctrl+V
<ara> tseliot, same thing
<ara> ara@sushirider:/var/log$ ls -l /usr/lib/xorg/modules/extensions/libglx.so
<ara> lrwxrwxrwx 1 root root 27 2010-01-05 14:44 /usr/lib/xorg/modules/extensions/libglx.so -> /etc/alternatives/libglx.so
<tseliot> ara: ok, I must be something else then. I'll investigate the problem and let you know
<tseliot> thanks for reporting the problem
<tjaalton> ara: what about the output of glxinfo?
 * tseliot is having a hard time getting Lucid to work on his testing box
 * tseliot -> lunch
<bryyce> you need more boxes ;-)
 * bryyce -> bed
<tjaalton> hmm, compiz-wrapper is no more, and compiz-core doesn't depend on mesa-utils
<tjaalton> ara: install mesa-utils and try again
<jcristau> but it still uses glxinfo?  i thought that would be gone and it'd do the GL calls itself?
<tjaalton> maybe
<tjaalton> compiz works here anyway :)
<tjaalton> but glxinfo is in mesa-utils
<tjaalton> or just running 'compiz --replace' should show the error
<ara> ara@sushirider:/var/log$ compiz --replace
<ara> compiz (core) - Fatal: Root visual is not a GL visual
<ara> compiz (core) - Error: Failed to manage screen: 0
<ara> compiz (core) - Fatal: No manageable screens found on display :0.0
<ara> Launching fallback window manager
<jcristau> glxinfo and xdpyinfo plz?
<ara> ara@sushirider:/var/log$ glxinfo 
<ara> name of display: :0.0
<ara> Error: couldn't find RGB GLX visual or fbconfig
<ara> http://paste.ubuntu.com/352892/
<jcristau> weird.
<soren> ara: You have an nvidia card?
<ara> soren, yes
<soren> ara: And it actually works for you? I thought all nvidia users were screwed by bug #494627.
<ubottu> Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress] https://launchpad.net/bugs/494627
<ara> soren, I am using tseliot's PPA, I am reporting back to him, to try to upload it to Lucid asap :)
<soren> Aha!
<soren> :)
<soren> Perhaps I should do the same.
<soren> Which PPA is this?
<soren> tseliot: You have a whole bunch :)
<soren> proprietary-video-improvements?
<soren> That one seems to have recent stuff in it.
<tjaalton> that's the one
<jcristau> hrm.  the backtrace in 440323 doesn't have libGL symbolsâ¦
<jcristau> also the ext_name is weird
<jcristau> #6  0x00007fa4bc76e7b2 in XextAddDisplay (extinfo=0x17153c0, dpy=0xf1f340, 
<jcristau>     ext_name=0x7fa4ae23a550 "ueryObjectuiv", hooks=0x7fa4ae35c2a0, 
<jcristau>     nevents=17, data=0x0) at ../../src/extutil.c:112
<jcristau> 	dpyinfo = (XExtDisplayInfo *) 0xec0010
<soren> "ueryObjectuiv" :)
<jcristau> and no qt symbols in 419501. bleh.
<jcristau> and 278261 doesn't look like a libxcb bug.
<tjaalton> a new bug triager \o/ :)
<jcristau> i was looking whether your sync request had been processed, and there were 4 bugs in https://launchpad.net/ubuntu/+source/libxcb/+bugs so i figured i'd look :)
<tjaalton> hehe
<jcristau> not going to look at the 292 xorg-server ones ;)
<jcristau> 334264 should probably be closed as fixed in 1.7.x though
<tjaalton> it's rather depressing going through them
<jcristau> (only looked at the title for the Xdmx bug, didn't look at the details)
<tjaalton> I'll ask the reporter to test on a lucid livecd
<jcristau> bah 435686 has no symbols for the server
<jcristau> weird though, caught a signal in EvdevOn
<jcristau> might be the bug fixed in evdev 2.2.6
<tjaalton> yep, asked to verify
<tjaalton> bryyce: btw, what happens when the log time counter hits 99999.999999? :)
<alkisg_> I'm trying Lucid on my laptop with nvidia 8600M GT. Isn't nouveau supposed to be automatically used? I can't even install it:
<alkisg_> xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is not going to be installed
<alkisg_> E: Broken packages
<alkisg_> Any clues?
<tjaalton> it hasn't been updated
<tjaalton> and no, nouveau is not used by default
<alkisg_> tjaalton: so the only solution for nvidia on Lucid for the moment is vesa, right?
<tjaalton> beginning to doubt it will (for lucid=
<tjaalton> today, yes
<alkisg_> Thank you
<bjsnider> tjaalton, the .33 kernel nouveau driver would not be backported to the lucid kernel?
<tjaalton> bjsnider: nothing happened so far
<tjaalton> visible anyway
<bjsnider> and after linus worked so hard to bully red hat into getting it in there
<alkisg_> bjsnider: so if I install .33 I'll get working nouveau drivers? (with all the instability, of course, I don't mind...)
<tjaalton> alkisg_: no
<tjaalton> the ddx will still fail to install
<jcristau> you'll still need the userspace part
<alkisg_> May I ask a last question? I tried passing "xforcevesa" as a kernel parameter, and it only seemed to work some of the times, I didn't get when exactly (was it only on the live CD?)
<alkisg_> Is there any way to specify that I want to use vesa without creating a xorg.conf?
<jcristau> rm xorg.conf
<jcristau> it should fall back to vesa on its onw
<jcristau> ^t
<tjaalton> though it'll use nv and that'll crash
<jcristau> ah
<jcristau> then  uninstall nv, or create xorg.conf
<jcristau> i thought mvo had fixed nv btw?
<tjaalton> or maybe not, but at least the colors are wrong. that's what mvo's patch would fix
<jcristau> ack
<tjaalton> it's not yet in the server
<alkisg_> Yeah nv had some weird green/black colors
<alkisg_> Not usable at all
<mvo> that is a side-effect of my initial crash fix, it fixes the crash, but that is not helpful (because of the colors)
<tjaalton> jcristau: libxcb finally synced (manually)
<jcristau> are you guys going for intel 2.10?
<tjaalton> probably
<tjaalton> we need to install some headers from libdrm again
<mvo> given the amount of complains about the funny colors I guess I should upload a revert -nv and a patched xserver this evening - unless there is feedback on ML that says otherwise- what do you think?
<tjaalton> erm, add to libdrm-dev, and Replace linux-libc-dev
<tjaalton> mvo: I can add it to the server
<tjaalton> and merge it too
<tjaalton> with the new version in sid
<mvo> sounds good
<tjaalton> but first I'd like to know why I always get failsafe (which doesn't work with kms)
<jcristau> i haven't actually tested what i uploaded to sid, i'm running 1.7.99.3-ish atm :/
<tjaalton> hehe
<tjaalton> I believe it works
<tjaalton> will test too
<jcristau> i had been running 1.7.3.901 for a while before though
 * mvo will upload -nv with the reverted patch in a bit
 * sebner waves
<tseliot> sebner: what does "update-alternatives --display gl_conf" say?
<sebner> tseliot: http://pastebin.com/m1ae40c9
<tseliot> sebner: try "sudo sh /bin/nvidia-bug-report.sh" and show me the log that it generates
<sebner> tseliot: http://pastebin.com/m7032eae5
<tseliot> sebner: try with "sudo apt-get install --reinstall nvidia-current" (as it's pointing to the wrong glx file)
<sebner> tseliot: then restart right?
<tseliot> sebner: no, maybe just show me the output of "ls -l /etc/alternatives/libglx.so"
<tseliot> and then restart
<sebner> tseliot: lrwxrwxrwx 1 root root 38 2010-01-07 15:42 /etc/alternatives/libglx.so -> /usr/lib/nvidia-current/xorg/libglx.so
<Sarvatt> [    0.123515] (II) Loading /usr/lib/xorg/modules/extensions/standard/libglx.so
<tseliot> sebner: ok, now restart and then do a "sudo sh /bin/nvidia-bug-report.sh" again and give me the log
<sebner> aye
<tseliot> Sarvatt: yes, that is why I asked him to reinstall the package
<Sarvatt> you've got the same problem I do sebner, moving /usr/lib/xorg/modules/extensions/standard/libglx.so away should fix it
<bjsnider> he's having the same problem sarvatt was
<sebner> heh
<bjsnider> oh, he just said that
<Sarvatt> i reinstalled it 4 times, no luck without manually moving the .so out of the way :(
<bjsnider> wait, i thought aptitude fixed it?
<bjsnider> your last message said aptitude fixed the problem
<Sarvatt> not here
<tseliot> Sarvatt: it means that X looks for libglx.so in subdirectories and ignores the link in /usr/lib/xorg/modules/extensions/
<Sarvatt> yeah thats what I got from it too, and couldn't figure out why
<tseliot> jcristau: does this make sense to you ^^ ?
<sebner> tseliot: http://pastebin.com/m46823125
<tseliot> or, is it a feature? ;)
<Sarvatt> it prefers the actual file even though its in a subdirectory over the link in the main directory
 * sebner uses apt-get :P
<tseliot> right
<tseliot> ok, let me fix that
<jcristau> tseliot: dunno.  should all be in hw/xfree86/loader/ somewhere.
<tseliot> ok
<bjsnider> Sarvatt, i thought it was just that the alternatives hadn't taken effect
<Sarvatt> reinstalling fixed the alternatives but that didnt fix the problem
<Sarvatt> had to move the .so out of the way
<bjsnider> but the .so in the /standard/ path is a link
<Sarvatt> nope thats the actual one that used to be in /usr/lib/xorg/modules/extensions/ before
<afv> hi. resuming after suspend leads me to a gray screen (this started happening in lucid pre-alpha. it was fine before. i'm using nvidia). if i have Rhythmbox playing before suspending, when resuming it continues playing.. i can only go to a tty after doing a Alt+SysRq+R, but always with a gray screen..
<bjsnider> Sarvatt, are you sure about that?
<Sarvatt> yeah 100%
<Sarvatt> libdri.so and libglx.so were just moved there in the xserver packaging
<Sarvatt> work calls :(
<afv> if it helps, Xorg.0.log: http://pastebin.com/d2e13acca
<afv> and pm-suspend.log: http://pastebin.com/d2b126605
<tjaalton> afv: power management with blobs is like gambling
<afv> blobs?
<tjaalton> nvidia
<afv> ah
<tjaalton> binary blob
 * tseliot nods
<bjsnider> someone in another channel was complaining that his ati card under the radeon driver was constantly at full throttle while under fglrx it was dynamic, usually low power mode
<tjaalton> radeon doesn't support that yet
<tseliot> tjaalton: it does but it's highly experimental
<tseliot> ;)
<tjaalton> right
<tseliot> I'll experiment with this when I have to time to create a radeon package with dkms
<afv> hum... "bonobo-activation-server (afv-6617): could not associate with desktop session: Failed to connect to socket /tmp/dbus-zUBPlHkmdZ: Connection refused"
<afv> forget it
<afv> i find nothing special at syslog... http://pastebin.com/d216d2830
<tjaalton> what I tried to say is that there's probably nothing we can do about it
<afv> isn't there a way i can debug it better?
<afv> or.. try with another driver, for example?
<tjaalton> currently there is no other driver that works even that much
<afv> hmm, ok
<afv> thanks then
<afv> brb
<sebner> tseliot: something went really wrong: sebner@ubuntu:~$ glxgears
<sebner> Error: couldn't get an RGB, Double-buffered visual
<tseliot> sebner: what does "sudo sh /bin/nvidia-bug-report.sh" say?
<sebner> tseliot: don't always forget poor /usr/ :P  http://pastebin.com/m28c9838a
<tseliot> sebner: ok, it looks like the right glx is loaded now but dri is not: (EE) Failed to load module "dri" (module does not exist, 0)
<sebner> grrrrr
<tseliot> sebner: which means that I should fix that in nvidia
<sebner> heh
<tseliot> as nvidia still points to the old path
<sebner> I was right
<sebner> nvidia rebuild :P
<tseliot> no more X recompilation should be required
<sebner> heh
 * sebner happy
<sebner> tseliot: baaaaad news, http://pastebin.com/m466a5e34
<sebner> haha, now glx fails again
<sebner> tseliot: maybe reinstall xserver to pick new one up?
<tseliot> sebner: it doesn't hurt to try
<sebner> tseliot: I'm sorry, still b0rken
<tseliot> sebner: ls -l /etc/alternatives/libglx.so
<sebner> tseliot: lrwxrwxrwx 1 root root 31 2010-01-07 17:28 /etc/alternatives/libglx.so -> /usr/lib/standard-x11/libglx.so
<tseliot> sebner: update-alternatives --display gl_conf
<sebner> tseliot: http://pastebin.com/m2e715488
 * tseliot screwed up again
<sebner> heh
<tseliot> I mean, let me check ;)
<tseliot> ok, I overdid
<sebner> haha
<tseliot> switching between desktops with the same screen (with different brightness) is killing my eyes
<sebner> heh
<tseliot> let me fix that
<sebner> :)
<tseliot> sebner: ~proprietaryppa22 should do the right thing
<sebner> tseliot: I'll try :)
<tseliot> thanks
<afv> back. purged nvidia and installed nouveau
<afv> suspend is working :p
<tseliot> yes, that usually works ;)
<tseliot> afv: are you using Lucid?
<tjaalton> kees: how's the libaudit main promotion doing? :)
<tseliot> superm1: speaking of mirs, any progress on the one for libvdpau?
<kees> tjaalton: well... I'd like to get it derooted.
<kees> tjaalton: which requires a fair bit of work/testing.
<kees> tjaalton: at present, it's a postponed workitem for Lucid.  what needs it?
<tjaalton> kees: we've disabled selinux from xserver due to libaudit being in universe
<tjaalton> kees: so, it's just a diff to debian
<kees> tjaalton: ok, I'll try to get it done, but time isn't looking great.
<tjaalton> kees: ok
<sebner> tseliot: here we go again: http://pastebin.com/m13d1ad5a
<tseliot> sebner:  ls -l /etc/alternatives/libglx.so
<sebner> tseliot: lrwxrwxrwx 1 root root 38 2010-01-07 18:12 /etc/alternatives/libglx.so -> /usr/lib/nvidia-current/xorg/libglx.so
<tseliot> sebner: it should work now
<tseliot> does it?
<sebner> tseliot: nope
<sebner> tseliot: Error: couldn't get an RGB, Double-buffered visual
<tseliot> ERROR: Error while querying attribute 'GLXServerVersion' on ubuntu:0.0
<tseliot>        (Unknown Error).
<sebner> tseliot: that means?
<tseliot> sebner: I think it's still using the wrong libGL libraries
<tseliot> sebner: cat /etc/ld.so.conf.d/GL.conf
<sebner> tseliot: /usr/lib/nvidia-current
<tseliot> which is correct
<sebner> hmmm
<sebner> weird
<tseliot> more weirdness
<tseliot> sebner: maybe do a "sudo ldconfig"
<tseliot> and reboot
 * sebner tries
<sebner> tseliot: still the same issue :(
<tseliot> sebner: maybe try to move /usr/lib/libGL.so.1.2 away, then ldconfig and reboot
<tseliot> this shouldn't happen though
<sebner> tseliot: away means .backup is ok?
<tseliot> yes, of course
<sebner> tseliot: seems something is b0rken. still not working
<sebner> This was my 32nd reboot today btw ;)
<jcristau> .backup means it's still visible for ldconfig
<tseliot> oh, I misread your sentence then
<tseliot> I missed the dot
<sebner> ohhh
<tseliot> jcristau: thanks for spotting that. My eyes are way too tired
<sebner> now it's /usr/lib/foobar
<sebner> ^^
<sebner> tseliot: not only yours ^^
<tseliot> sebner: that should be ok
<tseliot> now sudo ldconfig and reboot
<tseliot> maybe ldconfig got lazy or maybe (more likely) I'm doing something wrong in the packaging
<sebner> Number 33 brought me luck
<sebner> *hehehe*
<sebner> working now
<tseliot> sebner: ok, what if you put the library back and type ldconfig -n /usr/lib/nvidia-current
<sebner> tseliot: I'll test later. Now I'm giving my harddrive a break ;)
<tseliot> sebner: ok, no hurry
<sebner> wb tseliot 
<sebner> :)
<sebner> tseliot: is there a difference between ldconfig and sudo ldconfig? No output at all with both
<tseliot> sebner: it should be done with sudo
<sebner> k
<tseliot> did you try the command that I suggested before?
<tseliot> sudo ldconfig -n /usr/lib/nvidia-current
<sebner> tseliot: Guess why I asked :P I haven't rebooted yet though
<tseliot> sebner: aah
<tseliot> ok
<sebner> tseliot: nvm, rebooting now
<tseliot> ok
<sebner> tseliot: working
<tseliot> sebner: ldd /usr/bin/glxinfo
<sebner> tseliot: http://pastebin.com/m646d3d0d
<tseliot> at this point I think that if something else calls ldconfig it can break things unless I move those libraries to a separate directory
<tseliot> sebner: ok, it seems to be ok now
<tseliot> jcristau: opinions on this?
<jcristau> hmm?
<sebner> tseliot: :D, great thanks! Though I would have ~10 reboots instead of ~40 if I had moved the file at the beginning ^^
<tseliot> jcristau: I was thinking of moving libGL*, etc. to a different directory
<tseliot> as currently I have to do ldconfig -n /path/to/the/right/libraries
<tseliot> even though the path is set in /etc/ld.so.conf.d/GL.conf
<tseliot> as ldconfig seems to look in /usr/lib first
<tseliot> and then in whatever path we put in /etc/ld.so.conf.d/GL.conf
<tseliot> sebner: oh, well, you did it for a good cause ;)
<sebner> tseliot: new harddrive then plz :P
<tseliot> heh
<tjaalton> hrm, tseliot didn't add anything to the changelog about moving libglx/libdri
#ubuntu-x 2010-01-08
<bryyce> tjaalton, I see there's some xorg-server changes queued in git; is there a reason they're not uploaded yet?
<Sarvatt> looks like xf86-input-wacom moved to sourceforge git now - http://sourceforge.net/mailarchive/forum.php?thread_name=20100106065734.GA20435%40barra.bne.redhat.com&forum_name=linuxwacom-devel
<Sarvatt> i cant work out the udev rules/xorg.conf entries to get it working for the life of me but people have it working fine with hal even with input abi 9 :(
<bryyce> huh
<Sarvatt> I dont get it but I'm not getting the batchbuffer IO errors with 2.4.17 and mesa 7.7, I must have just been hitting an error that was in 2.4.16 and fixed before 2.4.17 when I was crashing with 2.9.1 before. 
<Sarvatt> other people in that bug were saying they didnt get it with 2.9.1 so I guess its something in the newer ddx making it need the older libdrm not to crash
<Sarvatt> i need it to crash now that i've got a kernel with the better batchbuffer dump built in that ickle was asking for so i'm going back to edgers, no crash with x-testing packages since they were uploaded though
<bryyce> Sarvatt, excellent
<bryyce> sounds like libdrm/mesa can be uploaded now
<bryyce> I'll touch base with timo tomorrow to see if there's anything else to do before uploading (and see if he wants to do it or if I should)
<Sarvatt> i was thinking about it, and is intel 2.10 a good idea for the LTS really? I still see quite alot of bugs with people not able to use KMS, just worried about dropping UMS support entirely
<Sarvatt> thats painful to say because I love my crack versions :D
<bryyce> dunno
<bryyce> there's pros and cons, I don't have a solid opinion
<afv> hi. is anyone using nouveau?
<RAOF> Yup.
<RAOF> Well, not right now, but yes in general.
<afv> i installed it today
<afv> and i'm having this issue with fonts:
 * RAOF is no longer sure how appropriate ânouveau by default" in lucid will be.
<afv> :p
<afv> http://dl.dropbox.com/u/659315/screenshots/fonts_nouveau.png
<Sarvatt> i'm also kind of questioning dropping hal for udev as custom patches that are really different than upstream, and doesnt seem like the whole udev/inputclass stuff will be up to snuff until xserver 1.9 since its in feature freeze now and tseliots changes for udev tags might not make it until then? seems like we're going to need xorg.conf.d for wacom but I probably dont understand the whole situation. i'm not sure if the xorg.conf.d stuff is even
<Sarvatt>  backportable since it bumps the input abi 2 times over 1.7
<RAOF> afv: When you say "installed", what do you mean exactly? :)
<afv> i'm using lucid with 2.6.33
<afv> and using xorg edgers ppa
<RAOF> And what card?  Have you installed the nouveau-firmware package (if you've got a geforce 8 or above?)
<Sarvatt> yeah nouveau really seems lucid+1 too, would be so much easier when its in the actual kernel and it's still so volatile
<afv> it's installed
<bryyce> Sarvatt, yeah I had a bad feeling about dropping hal, and it seems my worry was justified
<afv> 01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
<afv> asus laptop
<RAOF> Sarvatt: Yeah; I'm not confident that we'll be able to do any backporting of kernel fixes, and even their DDX work is more xserver 1.8 focused.
<RAOF> Also, it seems no one in the kernel team is tasked with actually driving it :)
<bjsnider> afv, where did you get the .33 kernel?
<afv> form http://kernel.ubuntu.com/~kernel-ppa/mainline
<afv> from*
<afv> rc2
<RAOF> If you've got the DDX from xorg-edgers then you've also got nouveau-kernel-source, so it doesn't really matter.
<bjsnider> RAOF, what do you mean abou the remark about nouveau by default on lucid?
<RAOF> bjsnider: I'm no longer convinced that it is a good idea.
<bjsnider> surely you can't think the nv ddriver is a better idea...
<Sarvatt> I really do at least
<RAOF> The nv driver doesn't require a kernel module that it will be really difficult to backport fixes to.
<bjsnider> every day there are people who come into +1 and complain that nv has given them a glorious black screen
<RAOF> It would be lovely to give users a non-crap nvidia driver by default, but if we're assuming that they're using the open driver as a stepping-stone to the binary driver, then I don't think nouveau-by-default buys us much except backporting headaches.
<Sarvatt> personally I'd rather vesa be the default over -nv, just need a screen to be able to install the blob through the gui :D
<bjsnider> you mean in the sense that you're not going to be using the .33 kernel?
<RAOF> bjsnider: Right.  But more than that, I don't think using the .33 kernel would buy us much, either; nouveau will continue to be developed against drm-next.
<RAOF> It'd make the lucid release easier, but in a year's time that's not going to be very relevant.
<RAOF> Sarvatt: Is there any hardware that nv drives that vesa doesn't?  That's a nice thought :)
<Sarvatt> and supporting it in a LTS would be a nightmare with how much it changes on a week to week basis
<afv> RAOF, yes, i do have the nouveau-kernel-source installed
<Sarvatt> vesa works on igp's! :D
<bjsnider> then don't change it
<bjsnider> just get a decent build in there and freeze it like that
<RAOF> bjsnider: We can't drop nouveau into main and then not support it.  That's the whole point of main!
<bjsnider> well, then explain to me how fedora is able to get around these issues
<Sarvatt> the changes are going to be too major to backport upstream fixes at some point
<RAOF> By not supporting it.
<Sarvatt> they haven't used nouveau in RHEL?
<RAOF> I don't think so, no.
<RAOF> I could be wrong here, but that would seem crazy.
<bjsnider> but you can't be expected to fix bugs that are not fixed upstream
<bryyce> if lucid is to go by, we'd probably only actively do support/backports to it for a month or so after release
<Sarvatt> yeah thats what I mean by fedora doesn't, fedora doesnt support nouveau for long outside of making people update to new releases :D
<RAOF> I guess it would work if they paid darktama to backport all the fixes to whatever kernel/libdrm/Xserver versions RHEL uses.
<bryyce> for lucid, after alpha-1 we generally only did security fixes and a few random targets of opportunity
<RAOF> bryyce: By "lucid", you mean... Karmic?  Hardy?
<Sarvatt> ya mean hardy bryyce?
<bryyce> ah right, hardy
<bryyce> anyway, I suspect what we (you guys and me) will want to do is put driver updates into a ppa for users that need them
<bryyce> especially with nouveau that'll be a lot less trouble than doing a lot of backporting
<RAOF> Yes.
<bryyce> and I definitely agree that being aggressive about using vesa whereever we're uncertain about nouveau is a dandy idea
<bryyce> open to suggestions on that
<bjsnider> vesa will probably give you a broken screen resolution
<RAOF> ...until you install the binary driver.
<bryyce> bjsnider, yeah but who cares, the user will just use it as a bridge to -nvidia
<RAOF> Which is what we're targetting here.
<bjsnider> what about old junk pre-geforce 6k? they can't use the blob
<bryyce> with -nv they're not getting 3D, which these days is becoming more and more a requirement
<RAOF> Man, I hope we'll be able to turn on nouveau gallium by 10.10; gnome-shell will be an unhappy camper with nv.
<bryyce> bjsnider, well it's not like we'll be deleting -nv, just wouldn't have it as the default
<RAOF> bjsnider: They install one of the *many* legacy versions of nvidia-glx?
<RAOF> We haven't dropped any of our 4 nvidia-glx packages, have we?
<bryyce> not afaik
<bjsnider> i haven't checked
<bjsnider> do they work with the newer x servers?
<RAOF> Fair point.
<bjsnider> or kernels
<bjsnider> has anybody tested that?
<RAOF> afv: I'm about to upload a new nouveau-kernel-source; feel free to try with that.
<bryyce> they are usually brought up to date for newer xservers and kernel
<bjsnider> yes but the 177 for instance wouldn't have been touched for aloooong time now
<bryyce> Nvidia tests, and I've been working with our QA team to get test procedures in place for the binary drivers
<Sarvatt> all but the 96.xx series were updated for xserver 1.7
<bryyce> I think the oldest legacy driver may not have been rebuilt
<Sarvatt> 96.xx is geforce 2 and older i think
<bryyce> retaining -nv for just those oldest ones might make sense
<afv> RAOF, sure, i'll try it. thanks. :)  i'm going also to upgrade from .33 rc2 to rc3
<RAOF> So the cards that the binary driver doesn't work on are also the cards that nouveau has the worst performance on.  Sweet.
<bryyce> but it would be nice if we could stop putting attention on -nv and just focus efforts to supporting -nouveau
<bjsnider> nouveau will get you x-video and stuff like that on an old riva tnt2, and you can't use any of the 177 or later blobs, and there are other showstoppers on the 96/71 blobs
<bjsnider> since nvidia spends a total of 5 minutes a year working on them
<bjsnider> and nv
<RAOF> afv: Kernel upgrades probably won't do much for nouveau; nouveau-kernel-source replaces all the drm infrastructure anyway.
<afv> ok :)
<RAOF> bjsnider: If we really wanted to use novueau as a feature-driver we'd need to make sure it's not slower than vesa on those cards.
<bjsnider> a feature driver? is that what vesa is?
<afv> RAOF, and what about 3d? is the guide at http://nouveau.freedesktop.org/wiki/GalliumHowto ok to follow?
<RAOF> afv: Yeah.  You should get a not-too-shabby compiz experience, if my 7600go is any indication.
<afv> hmm
<afv> i tried that today
<Sarvatt> nv is great for those, its just igp's, newer cards and those hybrid graphics laptops that really melt down with nv from what i've seen
<RAOF> bjsnider: You're suggesting that we use nouveau on the really old cards because nouveau supports interesting features, but on really old cards there's the problem that the acceleration setup time exceeds the actual acceleration, so the driver is slower than no acceleration.
<bjsnider> RAOF, the gnome-shell guys told me in their channel that gnome-panel is not in fact being removed as an option in gnome-3, so don't worry about gallium by 10.10
<Sarvatt> and some agp-pci-e bridge chip nvidia cards
<afv> but there's a "gmake" at the page that i didn't use :s
<afv> where's gmake from?
<afv> i get a "No command 'gmake' found, did you mean:"
<Sarvatt> i really hope to have nouveau gallium packaged in edgers by the time lucid releases, its really nice even now
<afv> that would be really nice
<RAOF> Sarvatt: Apart from the kernel panics, of course.
<afv> lol
<Sarvatt> yeah, i saw alot of commits supposedly fixing gpu hangs under 3d to nouveau a few days ago, at least for nv50
<bjsnider> RAOF, there are a couple of people over in +1 that have riva tnt2 cards i think. perhaps they know already if nouveau is fast enough
<RAOF> bjsnider: Yes.  DanaG is one of them, and he complains that it's much slower than no acceleration.
<Sarvatt> cant imagine using nouveau on one of those, pixmaps + 16mb vram fun
<afv> am i supposed to run glxgears using "$ LD_LIBRARY_PATH="/home/afv/.temp/nouveau/mesa/lib/" LIBGL_DRIVERS_PATH="/home/afv/.temp/nouveau/mesa/lib/gallium" glxgears"?
<afv> for example
<RAOF> afv: Yeah.  I tend to just export those variables and run stuff normally, though.
<afv> ok. but then i get a "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
<afv> "
<RAOF> Funky!
<Sarvatt> yup that looks right, i just set up a bash alias for it -- alias gallium='LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium"'
<afv> nice
<Sarvatt> do you have LIBGL_DEBUG=1 set afv?
<Sarvatt> should only see that if you do
<RAOF> For what it's worth, that guide is a bit old, and doesn't use the same set of configure flags that I use, but looks right.
<bryyce> I gather the main thing that is behind the push for nouveau is to get Ubuntu able to do KMS and show the fancy boot stuff across all the major gfx cards out of the box
<afv> running glxgears: http://pastebin.com/d461e9adf
<afv> Sarvatt, hmm, i don't think so :s
<bryyce> but if we are not confident that nouveau is solid enough for Lucid, then I'd be willing to try pushing back on it.  But we'd really need to make a convincing case
<RAOF> As long as no one wants to actually support it with bug fixes, I think it'll be fine.
<bryyce> yeah like I said, I think most realistically we'll just point people to PPAs
<RAOF> As a piece of snapshot code right now, I think it's a better default nvidia driver than nv.
<bryyce> I could see us pushing backports for a few weeks post-release for any critical issues while it's still reasonably easy to backport stuff
<Sarvatt> still too quirky on my nv86 for me to say that :(
<bjsnider> kms isn't only for boot
<bjsnider> it also does fast vt switching
<Sarvatt> would want to isolate the chips that only work with KMS with nouveau as well, I havent seen a list yet but mine is one of them
<bryyce> bjsnider, yeah I know but that isn't a feature that many beyond us geeks care about ;-)
<RAOF> Yes, but that's a bit irrelevant for nvidia; the binary blob doesn't (and won't, I think) do kms, what we're really trying to support is "nice initial boot until you install the blob"
<bjsnider> nerds
<bjsnider> geeks bite the heads off chickens in a circus
<bryyce> nerds are sour candy that comes in a little box
<RAOF> Because people, quite reasonably, want 3D.  And we *definitely* aren't going to ship that :).
<bjsnider> bryyce, well played, number six.
<Sarvatt> if this was a normal release I would for sure be pushing for it but it being a LTS... I'm happy to use a PPA :D
<RAOF> I've never heard "geek" used in that fashion; in all the usages I've seen, âgeek" is not pajoritive.
<RAOF> Wheras ânerd" is.  Anyway...
<bryyce> yeah
<bryyce> and biting heads off chickens is cool
<bryyce> RAOF, I'll make a note to doublecheck with the kernel team about nouveau, either tomorrow or early next week
<RAOF> Ok.  Thanks.
<RAOF> I'm not sure how I can be helpful there at the moment :)
<Sarvatt> i've got my bets on 2.6.34-rc2 being out before lucid :D
<bryyce> could be
<Sarvatt> and fixes needed for nouveau not being easily backportable to 2.6.32
<bryyce> it's kind of funny (or sad), prior to UDS everyone was saying, "Let's be conservative about what we change in Lucid so we can really make what we have solid"
<bryyce> and then at UDS, day by day we got more and more X changes set as requirements... dropping HAL, nouveau, changing to the new wacom driver, etc.
<RAOF> And now it's all like ânouveau!  kms! puppies!"?
<bryyce> I found it quite frustrating
<Sarvatt> i'm surprised how cracky its being in some areas (like the extreme boot speed aggressiveness causing other problems) and conservative in others (like the kernel version)
<bryyce> yeah
<RAOF> afv: nouveau-kernel-source uploaded; give it half an hour or so and it should be available for you.
<Sarvatt> if we had 4 months i can see it but i was under the assumption things were going to freeze alot earlier
<Sarvatt> half hour?! ppa builds got faster, had to wait 10 hours for the last round of ddx builds
<bryyce> the boot guys really drove hard for a lot of changes that I personally think are biting off a lot to chew
<Sarvatt> oh i think you built a gallium debug module afv
<Sarvatt> i dont get messages like that
<bjsnider> is the kernel team happy with the idea of using the .32 kernel again?
<bryyce> bjsnider, the ones I talked to seemed enthusiastic about it
<RAOF> It's going to be an lts kernel release, isn't it?  And IIRC RedHat will be using it, and suse, so we'll be in good company there.
<afv> hmm, Sarvatt, anyway i can't run compiz..
<Sarvatt> do packages in backports build against other components in backports? because you can almost bet there will be libdrm updates needed to build new nouveau in backports
<afv> RAOF, thanks!
<Sarvatt> afv I use ./configure --enable-glx-tls --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
<RAOF> afv: Does compiz segfault?
<Sarvatt> but i think the configure options have changed since the last time i built it
<Sarvatt> been alot of change in gallium configure flags in mesa master in the past few weeks
<RAOF> Because that's what it was doing for me most recently :)
<afv> nop. i get some weird stuff (like a white but transparent layer over the screen. lol)
<afv> Sarvatt, thanks, i'll use that
<Sarvatt> i think that wiki page had you compile in debug
<afv> compiz: http://pastebin.com/d328aeba1
<Sarvatt> oh nice they updated the wiki
<afv> Sarvatt, hmm, maybe, it does have a "--enable-debug"
<Sarvatt> you can ignore the libtxc_dxtn.so error though, everyone gets that if they dont have it installed and use debug
<Sarvatt> guess i'll package up this libkms next time i update libdrm in edgers
<afv> ok :)
<RAOF> Libkms?
<bjsnider> RAOF, do you know of nouveau has the same power-management issue that radeon has with the kms driver? where the card is constantly at full-throttle?
<afv> rebooting..
<afv> "Preparing to replace nouveau-kernel-source 0.0.15+git20091231-0~10.04~ppa1 (using nouveau-kernel-source_0.0.15+git20100108-0~10.04~ppa1_all.deb) ..."
<RAOF> bjsnider: I haven't noticed it; I seem to get approximately the same (crappy) battery life with nouveau as nvidia.
<Sarvatt> I get ALOT less battery life with nouveau, its always running at full clock speed on my 8400M GS
<afv> brb. i hope :p
<Sarvatt> like 40 minutes vs 1 hour 50 minutes
<RAOF> It's possible that my 7600 just doesn't have any appreciable throttling.
<Sarvatt> yeah mine has 3 power states and its usually at 120mhz with the blob
<RAOF> Maybe mine's stuck on lowest throttle with nouveau :)
<Sarvatt> it probably doesnt lower the voltage at the different speeds on the older cards is my guess
<RAOF> That may well be it.
<bjsnider> Sarvatt, what card do you have?
<Sarvatt> 8400M GS
<bjsnider> how long have you had that laptop?
<Sarvatt> 2 years or so
<bjsnider> wow
<bjsnider> you've far exceeded the lifespan for a bumpgate chip as far as i'm concerned
<Sarvatt> yeah I got this one as a replacement for an older model that went through 3 replacements due to the crappy BGA mounted nvidia chips
<Sarvatt> i havent even really used it in 1.5 years since i got a netbook, its mostly run headless so that might be why :D
<bjsnider> i figure the card in my rig has only lasted 2 years because it always remains at the same temp, because i never turn it off
<bjsnider> ah, i c
<afv> hmm, this was not good :p
<afv> and my apt/cache folder just disappeared :s
<afv> Xorg log: http://pastebin.com/d1e65e6d6
<RAOF> afv: Hows about dmesg; the problem is that nouveau's kernel module hasn't loaded, and the DDX won't work without it.
<RAOF> (In fact, the DDX is about to have the non-KMS codepath removed, too).
<afv> i didn't save dmesg :\
<afv> but i have something like "kernel: [   34.250444] Xorg[4301]: segfault at 18 ip 00000018 sp bffefc5c error 4 in Xorg[8048000+19f000]" at syslog
<RAOF> Yeah.  Everything will break if you don't have the kernel module loaded.
<afv> right
<afv> well, i gotta go now
<afv> will be back later
<afv> thanks for all the help =)
<afv> keep up the good work
<afv> c ya
<RAOF> afv: FWIW I've just got compiz a-runnin' again on my 7600go
<afv> nice :)
<afv> bbl
<RAOF> ...and GPU lockup again.
<bjsnider> it's not a lockup it's an unscheduled lack of complete functionality
<RAOF> No, it's an actual lockup.
<Sarvatt> still no libxcb update.. did it get held up because of the new libxcb-dri2 package maybe?
<wgrant> Can I force radeon/fglrx to POST my card when X starts?
<tjaalton> bryyce: I wanted to be sure that the libdri/libglx stuff is done before uploading it
<tjaalton> I didn't notice that change until tseliot was gone
<bryyce> tjaalton, okay
<tjaalton> and looks like mesa needs to move libGL to somewhere else than /usr/lib for the alternatives to work...
<tjaalton> it's getty uglier every day :/
<tjaalton> getting
<tjaalton> I don't like how everything is changed to cater for nvidia
<bryyce> heh, yeah this is the kinda stuff pitti was worried would happen
<tjaalton> we'd be using this forever, or as long as nvidia ships blobs
<tjaalton> RAOF: I'm pretty sure RHEL6 will have nouveau by default
<tjaalton> but they have the manpower to maintain it
<tjaalton> it would be great if mark did what he said here http://www.markshuttleworth.com/archives/95
<tjaalton> as pointed out by airlied on dri-devel@ during the nouveau discussion..
<tjaalton> oh well, enough ranting, more waking up ;)
<tjaalton> Sarvatt: we wouldn't have to bump the api twice, in fact not at all since the inputclass bump was only for wacom IIRC (and that can be patched in the driver)
<tjaalton> need to check
<tjaalton> yep
<tjaalton> the other abi bump was due to "Add type name argument to CreateNewResourceType"
<bryyce> tjaalton, maybe you should email mark to remind him of that ;-)
<tjaalton> bryyce: really? :)
<tjaalton> it's too late for lucid anyway I think
<bryyce> actually, half the problem is that it's hard to find X.org engineers wanting to come work for us
<tjaalton> yeah
<bryyce> but as a general rule canonical tends to focus resources more to integration and polish than to raw development, especially at the driver level
<tjaalton> but I think it's partly due to the devel community thinking C wouldn't let them continue upstream work, but mostly just distro stuff
<tjaalton> hehe, spot on :)
<bryyce> well and if you think about it, redhat is kind of unique in the amount of upstream development they do
<bryyce> but that is a business strategy they use, that lets them sell themselves to customers
<Sarvatt> oh boy, didnt notice the mesa problem with the PPA nvidia there
<tjaalton> the way I see it is that after some point the organisation needs to contribute more upstream work to be a "valuable player" or something such
<tjaalton> and that's what "the others" think
<Sarvatt> LIBGL_ALWAYS_INDIRECT=1 glxgears/compiz/whatever works but Error: couldn't get an RGB, Double-buffered visual without
<tjaalton> you didn't notice there was no compiz? :)
<Sarvatt> dont use it, nope
<bryyce> tjaalton, it doesn't matter.  They still complain anyway.  Look at how heavily I worked with upstream on QA for -intel this past year, pushed bug reports up, quirks, lots of testing, documentation, and on and on
<tjaalton> bryyce: but you're just one man :)
<bryyce> tjaalton, so?  upstream (well, specifically RedHat) still does not recognize any of that as having contributed any value upstream
<tjaalton> bryyce: my point was that there's only so much one man can do, and that can get lost in the noise
<tjaalton> I know it's not fair to compare to RH
<bryyce> tjaalton, true, it still is quite demotivating to me personally to hear all this.  Makes me want to go work on launchpad or something instead.  ;-)
<tjaalton> haha
<bryyce> heck, we actually have 3 paid people full time on X, and it's still not noticed
<tjaalton> you have?
<bryyce> but redhat's been at this game for a lot longer, I think give canonical time and we'll see
<bryyce> tjaalton, well, we have one kernel guy full time devoted to X (sconklin this release, andy last time), and for lucid alberto is on X 4 out of 5 days
<tjaalton> bryyce: ok, didn't know that
<tjaalton> so if I haven't noticed that, what does it tell ;)
 * tjaalton runs
<bryyce> yeah exactly
<bryyce> well, honestly with us all buried under the deluge of incoming bug reports it's hard to really put time into anything beyond fighting fires
<bryyce> when I'm feeling really cynical I think to myself that if we had more people who could do work upstream, I'd have them sit on the hands of upstream developers so they quit changing all this shit ;-)
<bryyce> of course then I'm sure our own Dx team would come up with some brilliant shit that should be changed upstream...
<tjaalton> hehe :)
<bryyce> and we'd still get ripped because we'd be working on foo, when upstream would rather have us doing bar
<tjaalton> well, with X there should be less chance for that. apps, sure
<bryyce> tjaalton, heh now you've got *me* ranting ;-)
<tjaalton> bryyce: that was to be expected ;)
<tjaalton> aanyway, back to reality. I'll test the inputclass/x.c.d patches skipping the abi bump
<tjaalton> hmm, need to go shoveling. we got maybe 50cm snow already
<bryyce> wow
<tjaalton> and next week I'll be joining the rest of the family in lapland, where there is -35 right now :P
<Sarvatt> got wacom working!
<tjaalton> C
<tjaalton> Sarvatt: ya
<tjaalton> +y
<Sarvatt> http://pastebin.ubuntu.com/353354/
<Sarvatt> woohoo
<Sarvatt> took 2 udev rules
<tjaalton> show 'em
<Sarvatt> needed one to make the input/wacom symlink and another for xserver handling, one sec
<tjaalton> yeah the package always had the first one
<Sarvatt> http://pastebin.ubuntu.com/353356/
<Sarvatt> i'm not using the old packaging, didnt have any luck with the old xserver-xorg-input-wacom.rules file
<tjaalton> do all the buttons work? or xsetwacom?
<Sarvatt> graphires working right, i'm digging out my intuos 3 now to test extra buttons
<Sarvatt> trying to find where i built this wacom, didnt install xsetwacom with the package but it built
<Sarvatt> yeah all looks to be working fine
<Sarvatt> http://pastebin.ubuntu.com/353361/
<Sarvatt> picked up the extra pad of buttons on the intuos and such and they work
<tjaalton> sweet
<tjaalton> could you put the source somewhere, I'll try it on my aiptek/waltop
<Sarvatt> sure one sec
<Sarvatt> this wont work for serial tablets though since they're tty, i saw thjaeger posting patches to try to get it working on the linuxwacom-devel list
<tjaalton> mine is usb
<tjaalton> I suspect it'll fail miserably, but we'll see
<tjaalton> intuos4 was out of stock :/
<tjaalton> and still is
<Sarvatt> http://sarvatt.com/downloads/xserver-xorg-input-wacom_0.10.3+git20100106.tar.gz
<tjaalton> oh man.. intuos4 L up for an auction
<Sarvatt> the packaging is screwy, i just took thjaeger's latest and threw it in a new git checkout, it needs to install xsetwacom and not install the hal stuff on top of needing udev rules
<Sarvatt> L?
<tjaalton> A4 wide size
<Sarvatt> oh nice
<tjaalton> only a few months old, 360e :P
<Sarvatt> this intuos3 4x6 cost way too much
<tjaalton> they are pricey
<superm1> why did tseliot want libvdpau in main?
<superm1> does something in main support building against it?
<Sarvatt> dont think that udev rule is going to work since the vendor doesnt match, looks like the hal fdi file was what let waltop work
<tseliot> superm1: isn't that required by nvidia or is it just for development?
<tjaalton> Sarvatt: I'll fix that part
<superm1> oh you're here
<Sarvatt> ffmpeg or mplayer?
<superm1> tseliot, it's only needed if your application supports vdpau acceleration
<Sarvatt> or gstreamer?
<superm1> which is mostly ffmpeg apps like mplayer and mythtv right now
<superm1> i dont think gstreamer has support yet
<superm1> at least i havent heard of it if it does
<tseliot> superm1: and shouldn't nvidia recommend that package?
<superm1> tseliot, no it shouldnt
<superm1> the apps that use it should
<superm1> had this discussion with some people in debian and with bjsnider 
<superm1> if anything there could maybe be an enhances 
<tseliot> ok, so basic support for vdpau lives in the driver but if you want to use it you'll have to install an additional package
<superm1> well not entirely accurate
<superm1> the basic support to open an implementation lives in the libvdpau package. the nvidia implementation lives in the nvidia package
<superm1> the user wont have to install the second package either
<superm1> it will be a shlibdeps for any package built against libvdpau-dev
<RAOF> Oh, there's some implementation in libvdpau?  I thought it was basically âmake it easy to dynamically load the appropriate library when it's available".
<tseliot> ah
<superm1> the implementation itself doesnt live in libvdpau, no.  
<superm1> support to "open an implementation"
<superm1> so dynamically loading the library is right
<tseliot> ok
<tseliot> superm1: also, any ideas as to why libGL.so.1 provided by nvidia is not loaded before libGL.so.1 provided by mesa? http://pastebin.ubuntu.com/353366/
<Sarvatt> the hal fdi was adding       <match key="info.product" contains_outof="Wacom;WALTOP;WACOM">        <merge key="input.x11_driver" type="string">wacom</merge>, and the udev rules just matched wacom product id's so i dont know that its going to work unless you add your tablets product id to the udev rule?
<tseliot> superm1: the path to the former is in /etc/ld.so.conf.d
<tjaalton> Sarvatt: it doesn't use the kernel module
<superm1> tseliot, hm.  not positive..
<superm1> tseliot, where's the path to the mesa one referenced?
<superm1> also ld.so.conf.d?
<tseliot> superm1: I think our last resort would be to use preload
<superm1> tseliot, ugh that's not a good solution to rely on
<superm1> because every app would have to do that
<tseliot> superm1: no, there's no need to specify /usr/lib as it's automatically picked up
<tjaalton>  /lib and /usr/lib are trusted paths, used by default
<tjaalton> Sarvatt: meaning that the funcionality is limited, but at least pressure sensitivity worked at some point
<tseliot> tjaalton: right
<superm1> tseliot, how does mandriva get around this?
<superm1> i would think the priorities would work out identically
<tseliot> I'm talking to them right now
<tseliot> yes, they should and the same system seems to work well for them
<superm1> are they maybe also using LD_LIBRARY_PATH too?
<tseliot> that would explain it
<tseliot> it looks like they don't
<Sarvatt> does the kernel recognize it as a tablet? imagine that 67-xorg-wacom.rules would pick it up if so since it loads wacom for all ID_INPUT_TABLET
<tjaalton> Sarvatt: haven't tried yet ;)
<tjaalton> Sarvatt: yes it does
<tjaalton> id_input adds ID_INPUT_TABLET=1
<Sarvatt> i cant load wacom without that extra udev rule making the symlink, but maybe thats just because i'm using the wacom module.. the old udev rule only touched things with a wacom product id from what i see
<Sarvatt> and it just matched some extra things that work with it like waltop in the fdi
<tjaalton> Sarvatt: heh, I need a patch from the wacom list to make it work with inputclass
<tjaalton> but lunch first
<Sarvatt> tseliot: if i strace ldconfig it messes with the /usr/lib/nvidia-current stuff before the /usr/lib stuff..
<tjaalton> sweet, InputClass & xorg.conf.d works(tm)
<tjaalton> though it also tries to load drivers for /dev/input/mouse*, which is confusing
<tjaalton> and wacom loaded too, but doesn't do anything :)
<tseliot> nice
<tjaalton> input-events doesn't show any events either
<jcristau> wacom_drv might grab the device
<jcristau> so make sure to test from a vt
<tjaalton> it works for the keyboard though, but I will
<tjaalton> whoa, it _does_ work from a vt
<tjaalton> hmm and I think whot is off by now
<jcristau> evdev doesn't grab so the keyboard is fine, yes
<jcristau> but synaptics and wacom...
<tjaalton> hmm ok
<jcristau> bryyce: i'm not sure counting tseliot as "working on X" is quite accurate, from what i can see he's working on nvidia and fglrx.  which isn't quite the same thing.
<tseliot> jcristau: ???
<tseliot> jcristau: this is only my 1st task
<tseliot> as soon as I'm done with the alternatives system I can spend time on open drivers and X in general
<jcristau> okay then.  we'll see.
<tjaalton> now you woke up the bear ;)
<tseliot> jcristau: were you replying to something that bryyce said? I think I'm missing context here
<jcristau> yes
<JamieBennett> I'm trying to determine if 3D acceleration is available in X so we can either install a 2D or 3D netbook-launcher interface on ARM devices. What's the best way to determine this?
<tseliot> glxinfo | grep direct
<tseliot> (in theory)
<JamieBennett> why in theory?
<tseliot> it should work
<tjaalton> tseliot: yeah I was chatting (ranting) with bryyce about the priorities and upstream contributions :)
<JamieBennett> OK, I'll do some experimenting, thanks
<tjaalton> got upset about the nouveau situation, and how it could be better
<tjaalton> tseliot: btw, is the libglx/libdri change in xserver good to go?
<tseliot> tjaalton: oh, I see. As soon as I finish this I'll be able to work on the input.d class as promised to upstream. I would also like to help with open (graphics) drivers. We'll see
<tjaalton> sure
<tjaalton> and great to hear
<tseliot> tjaalton: yes, those are fine. The nvidia part is required now
<jcristau> (glxinfo|grep direct won't tell you whether stuff is accelerated)
<JamieBennett> jcristau: any other thoughts if thats not it?
<jcristau> look for the renderer string
<tseliot> right, only if you have direct rendering
<JamieBennett> so glxinfo | grep 'renderer string'
<jcristau> tseliot: which you always have.
<tseliot> jcristau: not always
<jcristau> unless you don't have it on purpose, but then you know.
<tseliot> or your system is partially broken
<JamieBennett> jcristau, tseliot: Is there anyway of determining this without glxinfo? We don't have that in our live images.
<tseliot> you can install mesa-utils
<tseliot> which contains glxinfo
<tseliot> tjaalton: I think I'll just move libGL.so* to /usr/lib/standard-x11 (as I did for libglx.so and libdri.so) and use alternatives to point to other that or nvidia or whatever we select
<tseliot> this will make sure that, as it already happens in some linux games (as the Mandriva developer told me), if they dlopen libGL.so.1 directly things will still work
<tjaalton> tseliot: hrm, so the outcome is that in order to be able to select the GL implementation, we had to change three non-blob packages. and irreversibly, most likely
<tseliot> tjaalton: x, mesa, libxvmc (even though the 3rd one could be avoided)
<tseliot> but yes
<tseliot> :-/
<tjaalton> I guess there's no going back, so commit & upload what you need
<tseliot> right, I'm getting mesa from git as we speak
<tseliot> tjaalton, jcristau: do we override configs/linux (in mesa) in the debian/rules?
<tjaalton> tseliot: they are not used since autoconfig
<tseliot> ok
<tseliot> tjaalton: I've found out what sets the ".note.ABI-tag" in mesa that breaks things for us
<tseliot> src/mesa/x86/glapi_x86.S
<tseliot> generated by src/mesa/glapi/gl_x86_asm.py
<tseliot> and the other x86_64 script
<tseliot> the ABI-tag is set if we enable tls
<tseliot> #if defined(GLX_USE_TLS) && defined(__linux__)
<tjaalton> why doesn't mandriva enable it? the only reason why fedora doesn't is selinux
<tjaalton> and that'll change sooner or later
<tseliot> let's what they say
<jcristau> what does that supposedly "break"?
<tseliot> jcristau: well it doesn't really break anything. It simply makes ldconfig believe that the libGL.so.1 in mesa is a completely different library from what other vendors, say nvidia, provide
<tseliot> libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
<tseliot> libGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.1
<tseliot> the first one is from mesa
<tseliot> tjaalton: I've come up with a solution that doesn't suck :-)
<tseliot> tjaalton: i.e. we simply install libGL.so* to /usr/lib/mesa (or whatever) and the file in ld.so.conf.d/ (that we already use) will make ldconfig look for libGL.so* look in the right place
<tseliot> (well, it doesn't suck too much)
<tjaalton> tseliot: ok
<tseliot> tjaalton: so the diff in mesa will be very small
<tjaalton> that's good
<apw> bryyce, hey are we good for alpha-2 to have ATI radeon KMS enabled?
<tjaalton>  it wasn't already?
<tjaalton> apparently not, I thought it was enabled after alpha1 :)
<apw> tjaalton, it was an is enabled since just after alpha-1, just making sure 'you' are ok with it remaining so for an annouced released
<tjaalton> apw: ah, ok
<Sarvatt> pretty sure its almost guaranteed you're not going to have 3d acceleration on any arm platform, we disable egl and stuff in mesa
<tjaalton> hm?
<BUGabundo_work> hi
<BUGabundo_work> bug 504149
<ubottu> Launchpad bug 504149 in xorg "[lucid] after update keyboard and mouse do not work in X" [Low,Won't fix] https://launchpad.net/bugs/504149
<BUGabundo_work> if anyone cares to take a look, and help me save my (and probably many other Lucid user) systems
<tjaalton> why?
<BUGabundo_work> tseliot: ^^^^^^^
<tjaalton> your logs indicate that hal is working normally, so what's wrong?
<BUGabundo_work> tjaalton: no mouse or keyboard in my system
<BUGabundo_work> after upgrades from two days ago
<BUGabundo_work> and yesterday reboot
<BUGabundo_work> touchpad works, actually
<tjaalton> ok, probably due to the faster boot work
<BUGabundo_work> if i stop GDM i can use keyb in TTY
<tjaalton> so, pretty please, dist-upgrade and be done with it
<BUGabundo_work> cant!
<BUGabundo_work> it forces the removal of nvidia driver and kernel
<tjaalton> surely you can live without nvidia for a few days?
<BUGabundo_work> days?
<tjaalton> kernel? no it doesn't
<BUGabundo_work> been like that for 1 month
<tjaalton> yeah, and you updated anyway?
<BUGabundo_work> no
<BUGabundo_work> i never dist-upgrade when _important_ packages are touched
<tjaalton> hehehe
<BUGabundo_work> aptitude safe-upgrade only
<tjaalton> so expect breakage
<BUGabundo_work> i do
<BUGabundo_work> but not being locked out of my own system
<tjaalton> dist-upgrade ftw
<BUGabundo_work> i wouldnt been running +1 for 3 years not expecting breakage
<BUGabundo_work> very funny
<tjaalton> yes it is
<BUGabundo_work> how about packaging proper matching X with close source drivers ?
<tjaalton> I don't understand what you are asking on that bug
<tjaalton> hehe
<BUGabundo_work> that would be funny too
<BUGabundo_work> :\
<tjaalton> yes, I'm laughing
<BUGabundo_work> oh i bet
<BUGabundo_work> i'm laughting too... for not being and ATI user
<tjaalton> bug 494166
<BUGabundo_work> ohh wait... i'm too.. debian unstalbe at work
<ubottu> Launchpad bug 494166 in nvidia-graphics-drivers-96 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166
 * BUGabundo_work subs
<BUGabundo_work> tjaalton: can u assure me the return of my input devices after dist upgrade, and provide a proper downgrade route, in case that fails ?
<tjaalton> the downgrade path is to install karmic
<BUGabundo_work> ahah
<tjaalton> if you desperately need the nvidia
<BUGabundo_work> do that to all your testers
<BUGabundo_work> and be left with a borked final system
<tjaalton> eh?
<BUGabundo_work> no, i dont want nvidia that bad
<BUGabundo_work> i want my mouse and keyb.... *that bad*
<tjaalton> yes, I bet it works
<BUGabundo_work> 100$ and u are on
<BUGabundo_work> i need to pay my new WD
<BUGabundo_work> u can start helping
<tjaalton> since this is the first bug about this..
<tjaalton> and I need a wacom :)
<BUGabundo_work> well, second
<BUGabundo_work> i subbed to that bug
<tjaalton> just because you didn't dist-upgrade
<BUGabundo_work> well... dont break X and ask for the removel of N packages including a kernel image
<tjaalton> what kernel image??
<tjaalton> there's a reason for the video abi conflicts you know
<BUGabundo_work> cant say out of my head
<tjaalton> since your nvidia wouldn't work with 1.7
<BUGabundo_work> i know
<BUGabundo_work> new X
<BUGabundo_work> i know and i understand
<tjaalton> then why do you complain?
<BUGabundo_work> hence the reason i didnt dist-upgrade
<BUGabundo_work> tjaalton: cause it broke my input methods
<tjaalton> no, that's the plumbing
<tjaalton> and we went to udev input handling before alpha1, so hal was never tested nor meant to be used
<BUGabundo_work> i know
<BUGabundo_work> it wasnt there!!
<jcristau> actually it's expected to break, the fdi enabling X i-h was removed from hal
<BUGabundo_work> that's the secondary bug
<BUGabundo_work> seems it was pulled again into my system
<bjsnider> hal was?
<tjaalton> jcristau: oh right, so no way hal can work
<tjaalton> hmm no, running the old version it should
<tjaalton> jcristau: damn, didn't read it well enough :)
<jcristau> tjaalton: might be a good idea to have the new hal Break old xserver-xorg-core just to make sure?
<tjaalton> jcristau: yes, why not
<tjaalton> jcristau: pushed 1.7.4
<jcristau> ok
<tjaalton> bjsnider: hal is needed on some laptops for gnome-power-manager. it will be modified to run only when needed
<bjsnider> oh, cool
<bjsnider> that kind of sucks though, doesn't it? it has to be installed by everybody ony for that one small use-case
<tjaalton> yes
<tjaalton> :)
<bjsnider> gnome-power-manager needs to be slapped around a bit
<tjaalton> BUGabundo_work: so, the way to make hal work again is to go back to the version on karmic
<tjaalton> bjsnider: yeah I think it'll get fixed sooner or later, but not necessarily for lucid
<tjaalton> heh, "All the X drivers need to support XBACKLIGHT before we can turn it off completely"
<tjaalton> https://wiki.ubuntu.com/Halsectomy
<jcristau> why the shouting?
<jcristau> :)
<tjaalton> <g>
<BUGabundo_work> so either downgrade hal, or distupgrade, lose nvidia, what get my self into what hell, until nvidia release 1.7 compatible driver
<BUGabundo_work> ok... at least i have a choise
<bjsnider> does the blob not work with the new x server?
<bjsnider> everybody who's emailed me about it says it does
<tjaalton> bjsnider: which version?
<tjaalton> BUGabundo_work: there is a compatible one available, it's just not packaged yet
<tjaalton> but soon
<bjsnider> 185/190/195
<tjaalton> 190 is on tseliot's ppa
<bjsnider> i packaged all 3 for lucid at one point until yesterday and everybody reported to me that they worked
<tjaalton> oh, the old packaging
<tjaalton> sure
<bjsnider> right, the old packaging
<tjaalton> anyway, gotta go
<kaloss> buenas
<kaloss> mi tarjtea grafica
<kaloss> no acepta los afectos visuales
<jcristau> in english please
<bjsnider> i think he's saying he can't enable visual effects
<tseliot> kaloss: puede depender de varios motivos pero tienes que hablar inglÃ©s
<jcristau> i got that much :)
<kaloss> yes
<kaloss> my efeccts visual
<kaloss> my moptherboard pc chips 955 integrated
<kaloss> :o
<tseliot> kaloss: did you file about report about it?
<kaloss> seen here----> http://paste.ubuntu.com/353541/
<tseliot> heck
<tseliot> I meant to say, did you file a bug report about it?
<tseliot> kaloss: no, unfortunately you won't get 3D effects with a VIA card
<jcristau> ugh via
<jcristau> tough luck.
 * tseliot nods
<jcristau> almost as bad as poulsbo ;)
<tseliot> now you're reading my mind...
<bjsnider> i thought via had opened everything up and hired a couple of the openchrome guys?
<tseliot> no, 3D is still proprietary
<jcristau> i very much doubt "everything"
<bjsnider> aren't they developing a gallium driver?
<tseliot> had they opened everything, things would have been in much better shape now
<tseliot> but even with gallium you can keep it closed
<tseliot> :-/
<bjsnider> well, they're definitely better than they used to be
<bjsnider> which isn't saying much, because there was no place to go but up for them
<tseliot> :-)
<tseliot> tjaalton: I'm rebuilding mesa locally now. If it works, I'll push my changes for X and Mesa to git and we can start uploading things
<tseliot> i.e. patch for X: http://pastebin.ubuntu.com/353554/
<tseliot> patch for mesa: http://pastebin.ubuntu.com/353556/
<tseliot> tjaalton: ok, pushed to git
<tseliot> why shall I use debuild -I".git" -S -sa -v$previousUbuntuVersion ?
<tseliot> the -v part
<jcristau> see dpkg-genchanges(1)
<tseliot> jcristau: aah, ok, it makes sense now
<tseliot> but still -sa shouldn't be required unless is a new upstream release
<tseliot> -S should be enough
<bjsnider> -Sd
<bjsnider> or -S -sd
<bjsnider> i thought
<tseliot> -sd    Forces the exclusion of the original source and includes only the diff.
<tseliot> -S     Specifies that only the source should be uploaded (no binary packages will be included).
<bjsnider> right, so if i'm just changing the build scripts that's what i do
<tseliot> either of them should be ok in this case
<bjsnider> and the ppa build system and my rig both have the same orig tarball, so that's why it wor,s
 * tseliot -> dinner (brb)
<Sarvatt> jcristau: dunno if you saw but the remove render reclock commit went to stable, definitely still needs powersave=0 on top of that here though, i'm still getting flickering after resume without it. still dont understand why powersave=0 doesnt fix it without that commit as well though
<jcristau> Sarvatt: okay.  i think i'll get the debian kernel people to set powersave to 0 by default and call it quits... thanks for the heads up
<Sarvatt> you install a /etc/modprobe.d/intel-kms.conf with the driver, why not just throw it in there?
<Sarvatt> err i915-kms.conf
<jcristau> because it's safe to do in the kernel
<jcristau> and if it's going to be temporary it's better done there
<Sarvatt> true, it breaks <.32 adding it in the modprobe.d/i915-kms.conf
<Sarvatt> i915 doesnt load because of the invalid parameter on 2.6.31 when i add it in there
<jcristau> assuming the intel people get their stuff working in .33 i'd rather not have to clean things up when we bump the kernel
<Sarvatt> i'm glad linus seems to not care about feature freezes for intel and pulls drm-intel-next whenever its ready :D
<Sarvatt> ok i guess its time to drop xserver from xorg-edgers, going to have to put a big warning for people to revert those packages manually at the top and hope people read it :D
<Sarvatt> if I delete it ppa-purge wont revert it though, ugh
<Sarvatt> tjaalton: seems like we could hack together a wacom package that only works for usb devices now doesn't it? I wish thjaeger came on irc, looks like he's working on extending it to work for serial devices using tty instead of just input
<Sarvatt> http://sourceforge.net/mailarchive/forum.php?thread_name=4B42A1BB.6060706%40gmail.com&forum_name=linuxwacom-devel
<Sarvatt> he's sent me patches that do work for the old 0.8.x wacom packages under input abi 7 but that only works with hal
<Sarvatt> i'm an idiot when it comes to udev so I can't figure out why the old udev (non-xorg one) doesn't work but my one that just creates the input/wacom symlink does
<Sarvatt> old udev rules file I mean
<bryyce> apw, yep +1 from me
<tseliot> bryyce, tjaalton: I have uploaded my changes to X and Mesa. I'll upload libxvmc now
<thopiekar-t91> hi
<thopiekar-t91> is there a site on the net that provides new poulsbo drivers
<thopiekar-t91> ?
<thopiekar-t91> I copied fails builds from other repos to my and made them work on my ppa:thopiekar/poulsbo
<thopiekar-t91> http://launchpad.net/~thopiekar/+archive/poulsbo
<tseliot> thopiekar-t91: we don't support poulsbo any more
<thopiekar-t91> is there a alternative..
<jcristau> vesa..
<tseliot> but you will find some unofficial repositories on ubuntuforums.org
<thopiekar-t91> can you at least help me to get it work..
<tseliot> use them at your own risk though
<thopiekar-t91> tseliot: the howtos there are using ubuntu mobiles jaunty ppa but I want to push them to karmic
<thopiekar-t91> jcristau: I think I'm using atm vesa .. it's really eating my battery's energy :/
<tseliot> thopiekar-t91: http://swiss.ubuntuforums.org/showthread.php?t=1253406
<tseliot> feel free to push whatever you like in your ppa
<thopiekar-t91> yes but these packages doesn't work.. ok I will work on it, thank you anyway..
<bryyce> tseliot, with those changes, what's next on the todo for the alternatives stuff?
<tseliot> bryyce: the 3 nvidia flavours (which I'm ready to upload)
<tseliot> then I would like to upload screen-resolution-extra, nvidia-common, nvidia-settings and (when pitti is online) the new jockey
 * bryyce nods
<tseliot> bryyce: screen-resolution-extra is used by nvidia-settings to use policykit
<tseliot> i.e. no more sudo with nvidia-settings
<tseliot> bryyce: I think I'll make some additional changes to the alternatives system but this will be after alpha 2
<Sarvatt> this whole setup breaks being able to use drivers directly from nvidia doesn't it?
<tseliot> Sarvatt: if nvidia-common is installed, the nvidia-installer will stop
<bryyce> Sarvatt, IIUI you would need to uninstall the ubuntu driver, then you could install from upstream
<Sarvatt> ah I purge nvidia* when I use the nvidia drivers
<tseliot> but yes, the nvidia-installer, even if successful  won't work because of the ld.so.conf.d stuff
<Sarvatt> just thought the shuffling of libs might screw it up somehow
<tseliot> and I'll fix this
<tseliot> I was talking to the Mandriva guys about it today
<tseliot> we can cooperate on this
<tseliot> (as we use the same system)
<bryyce> nice
<tseliot> :-)
<Sarvatt> alot of people are using the upstream driver because the distro ones dont work right now (me included) so it might warrant a release note for alpha 2 on how it that doesn't work at the moment
<Sarvatt> is what I was thinking
<tseliot> Sarvatt: it's a good idea
<bjsnider> i think that the 195 driver should be used instead of the 190 for lucid
<tseliot> bjsnider: sure, as soon as it's released as stable
<Sarvatt> 195 will probably be the stable release any time now I'd bet
<Sarvatt> super easy to update with all this work now at least :D
 * tseliot nods
<bjsnider> tseliot, yes but lucid isn't stable so why do you have to package a stable nvidia driver?
<bjsnider> Sarvatt, not super easy. the 195 contains 6 new files that have to be packaged
<tseliot> bjsnider: what if nvidia doesn't release it as stable in time for Lucid's release?
<bjsnider> they will. no question
<tseliot> in general, this is my approach, especially with things that I can't fix
<Sarvatt> actually, 190.53 isn't even a stable release yet is it?
<tseliot> namely proprietary stuff
<tseliot> yes, it was promoted to stable
<tseliot> recently
<bjsnider> tseliot, i just figure, what with those new files, why not put them into the build scripts now while you're working on them as opposed to having to jump back into them knee-deep in a month?
<Sarvatt> ah indeed it is
<bjsnider> plus kde users should be using the 195 since it accelerates xrender for the first time
<tseliot> bjsnider: I can put 195 in a PPA and experiment there
<bjsnider> cool
<bjsnider> there are two shared libs that will have to be execstacked and linked
<bjsnider> and a file that goes in /etc
<bjsnider> 3 opencl headers
<tseliot> now we have this deadline that is alpha 2 and I have to make sure that things work in time for alpha 2, then I can think of the rest
<tseliot> ah, good to know
<bjsnider> i just figured it would be easier on you to do this work while the build scripts are all in your mind as opposed to leaving it for a month and then having to pick it all up again
<Sarvatt> are the headers in a standard place? picked up by the current install globs?
<bjsnider> no
<bjsnider> they are in /usr/lib/CL
<bjsnider> i don't think the installer would pick them up
<bjsnider> i think the installer would pick up /usr/lib/libnvidia-compiler.so.195.xx
<bjsnider> but it would have to be linked in the .links file
<bjsnider> the windows driver is already at 195, and the linux team likes to stay current with that, so they'll be switching as soon as they get the major bugs out of the 195
<Sarvatt> great, nvidia-current-cl nvidia-current-cl-dev packages then..? is there any generic libcl it hooks into?
<tseliot> wait, what?
<bjsnider> i thought we didn't want to split anything off
<tseliot> one will end up in nvidia-current, the rest in nvidia-current-dev I guess
<bjsnider> the two libs would be in nvidia-current, the 3 headers in the dev package
<bryyce> Sarvatt, are we considering that libdrm execbuf bug solved with latest mesa/libdrm?  I see the bug report is still open upstream
<bjsnider> and then there's an /etc file
<tseliot> bjsnider: what's in /etc ?
<Sarvatt> bryyce: I still have the problem with an updated intel ddx but not with 2.9.1
<Sarvatt> but no problem with libdrm/mesa updates without updating the ddx
<bryyce> Sarvatt, weird okay, so as long as we don't upgrade -intel we can go ahead with upgrading libdrm/mesa?
<soren> I've been messing around with my drivers lately (part manually, part from tseliot's restricted-blah-blah ppa, and part ubuntu repositories), and finally the nv driver is working for me, but DRI does not seem to be working. Is this expected, or did I mess something up along the way? (Using the "nv" driver, by the way)
<bjsnider> tseliot, /etc/OpenCL/vendors/nvidia.icd -- it contains this: libcuda.so
<bryyce> tjaalton, ^ is uploading the new libdrm/mesa on your todo list?  If not, should I give it a go?  Would be nice to have done for a2
<Sarvatt> I'm really confident enough to say yes to that after 4 days testing, libdrm 2.4.16 alone had a crashing problem that must have been been fixed in 2.4.17 (there were a few intel bug fixes)
<tseliot> soren: what did you take from my PPA?
<soren> tseliot: Let's put it this way: It's in my sources.list, and apt says I'm all up-to-date.
<tseliot> bjsnider: hmm... I'll ask nvidia about it
<bjsnider> soren, glx isn't working?
<bjsnider> good idea
<soren> bjsnider: Well... 5 minutes ago, glxinfo just gave some error (sorry, I forget the exact error), which was caused by libdri.so was pointing to the nvidia-current one.
<tseliot> soren: /var/log/Xorg.0.log ? and the output of update-alternatives --display gl_conf please
<soren> bjsnider: Now, I do get some useful output, but "direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
<soren> "
<soren> tseliot: gl_conf? What's that?
<Sarvatt> the bug was so severe before i never had over 24 hours uptime with the newer ddx, 4 days *trying* to crash it by repeatedly loading a folder with hundreds of videos and letting it make thumbnails and deleting those thumbnails and repeating when I couldnt last 2 rounds of that before seems like its fine to me
<tseliot> soren: the master link
<soren> Ah, I see.
<bryyce> Sarvatt, ok good to hear
<bryyce> Sarvatt, happen to know if updating libdrm/mesa is on tjaalton's todo list for a2?
<soren> tseliot: Hahah, that's pointing at /usr/lib/nvidia-current/ld.so.conf
<tseliot> soren: type: sudo update-alternatives --set gl_conf /usr/lib/standard-x11/ld.so.conf and then do an ldconfig
<soren> tseliot: As I said: "part manual fiddling" :)
<tseliot> always with sudo
<soren> tseliot: Sure, sure.
<tseliot> soren: when all is in place jockey will deal with that
<Sarvatt> I have no idea :( seems like he wanted to push it ASAP though and the libdrm is blocking alot of other possible updates
<Sarvatt> but I think he wanted to adjust libdrm so it replaces headers again which intel 2.10 needs to build
<soren> tseliot: That did not do the trick. I'll pastebin my xorg.0.log.
<bryyce> ah right
<jcristau> soren: if you still have LIBGL_ALWAYS_INDIRECT set, unset it?
<soren> http://pastebin.com/fbb2dba5
<soren> jcristau: Um... I didn't set anything. Is it an environment variable?
<bryyce> Sarvatt, ok I'll touch base with him when he's around but won't pick at it myself for now
<jcristau> yes
<bjsnider> wow, the nvidia driver package for windows is 105 MB
<soren> jcristau: Oh, wow. It is an environment variable. Where the heck did that come from?
<tseliot> soren: BTW nvidia doesn't provide libdri.so. Even if you select nvidia you will use libdri.so from X11
<Sarvatt> JamieBenett: I'm almost positive you arent going to get accelerated GL on any arm platform in ubuntu right now, they all have proprietary graphics accelerators that would need to interface their opengl ES implementations with egl for acceleration as far as I know
<soren> tseliot: I didn't say all my manual fiddling was sane :)
<tseliot> heh
<soren> Um... What would set LIBGL_ALWAYS_INDIRECT ?
<jcristau> something that's trying to run compiz?
<Sarvatt> any we dont even build mesa with egl support (not that I know that would work with things)
<Sarvatt> i think mythtv sets it too? could be really mistaken there
<jcristau> i'm not ruling out any mythtv stupidity
<Sarvatt> arm 3D acceleration on linux is worse than paulsboro, most use powervr too :(
<soren> jcristau: Ok, if I unset LIBGL_ALWAYS_INDIRECT, glxinfo says "direct rendering: Yes".
<jcristau> (not that "direct rendering: Yes" means anything)
<jcristau> (in terms of gl acceleration, that is)
<Sarvatt> i think if you can get a kernel blob interface up you might be able to get it working with gallium though
<soren> jcristau: I'm learning a lot today. How can I tell whether it's software rendering or not?
<soren> Hahah: OpenGL renderer string: Software Rasterizer
<tseliot> yes, if glx is broken usually you get only errors from glxinfo
<jcristau> soren: right, that.
<soren> jcristau: So what makes the difference here? What provides the drivers for hardware accelerated glx (is that the right terminology)?
<soren> Is that mesa?
<bryyce> soren, yes, for most of the open source drivers
<soren> Fascinating :)
<bryyce> with nv, the developers seem to prefer that users needing gl use -nvidia instead
<bryyce> so gl support for -nv is fairly behind the times
<soren> So when my memory is trying to convince me that I used to have compiz running with nv, it's lying?
<tseliot> you can still use compositing with xrender
<tseliot> with nv
<tseliot> I think I did that with KDE 4 once
<hyperair> huh? you can?
<hyperair> O_O
<tseliot> openGL is much better
<hyperair> hmm
<soren> Oh, well.
<tseliot> you can try that with a Kubuntu live image
<tseliot> note: I'm not suggesting that you do it ;)
<soren> I suppose I'll try to get nvidia working instead.
<tseliot> soren: with my PPA + the new xserver and mesa that will soon arrive directly in Lucid, 3D acceleration should work
<soren> tseliot: update-alternatives --set /usr/lib/nvidia-current/ld.so.conf gl_conf, and then s/nv/nvidia/ in xorg.conf, and I should be golden?
<soren> tseliot: You mean for nvidia or nv?
<tseliot> soren: "update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf" and yes, I was referring to nvidia :-)
<soren> tseliot: Uh, right, sure, that's what I meant (the update-alternatives thing). :)
 * soren is lying.
<soren> I'm actually using --config
<tseliot> :-D
<tseliot> that's easier
<soren> lots
 * soren takes this config for a spin
<soren> tseliot: I get a bunch of "Xlib:  extension "GLX" missing on display ":0.0".", when I run glxinfo now. Xorg.0.log says:
<soren> [    0.034084] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
<soren> dlopen: libGLcore.so.1: cannot open shared object file: No such file or directory
<tseliot> soren: did you do ldconfig and do you have my new x and mesa?
<soren> Everything is up-to-date, but I forgot ldconfig.
 * soren tries
<tseliot> soren: are the new mesa and X already in lucid???
<soren> tseliot: No clue.
<soren> tseliot: Probably not, since you ask that way.
<soren> I was trying to answer your question :)
<soren> apt does not want to install any updates, so I've got whatever's freshest in the archive and/or your ppa.
<tseliot> https://launchpad.net/ubuntu/+source/xorg-server/2:1.7.3.902-1ubuntu2/+build/1436731
<tseliot> https://launchpad.net/ubuntu/+source/mesa/7.6.1~rc3-1ubuntu2/+build/1436737
<tseliot> and the answer seems to be no ;)
 * soren waits another three hours then :)
<soren> tseliot: I'll stop bothering you now. :)
<tseliot> soren: no problem, I'll spend the night waiting for the packages to build ;)
<tjaalton> bryyce: yes, those are ready
<tjaalton> we can munge the headers after a2, if needed
<bryyce> tjaalton, sounds good
<bryyce> tjaalton, ok do libdrm and mesa need anything before they get uploaded, or are they want to go now?
<tjaalton> bryyce: mesa needs to be merged with tseliot's latest change, nothing else
<tjaalton> I've got local 'ubuntu-test' branches for both
<tjaalton> wonder if they would be useful on git.d.o
<tjaalton> for future work
<tseliot> another mesa?
<tjaalton> 7.7 :)
<tseliot> nice
<bryyce> ok
<bryyce> I'll work on some of the other merges
<tjaalton> bryyce: btw, the versions_current lists -amd and -via, both of which are dupes (-geode, -openchrome). those could be filtered out
<bryyce> tjaalton, ok; added to my todo list
<tjaalton> bryyce: thanks
<knittl> hi, i need help with xorg graphics drivers :D
<knittl> everytime i boot i get an error message about ubuntu running in low graphics mode
<knittl> exiting to console and starting gdm works fine though
<tjaalton> so gdm didn't start the first time
<knittl> i get the message with nvidia drivers from tseliot's ppa, with and without xorg.conf and even with drivers apt-get purged
<knittl> tjaalton: probably
<tjaalton> there's some race condition with the booting process on lucid
<tjaalton> it's not a driver bug though
<knittl> ok, so this is a known issue?
<tjaalton> at least to me, since I get it all the time
<knittl> ok :)
<tjaalton> the Xorg.0.log was not updated, neither were the gdm logfiles.. so those would suggest that gdm didn't start at all
<tjaalton> but failsafe did
<tjaalton> and since upstart doesn't log boot msgs...
<knittl> i just tried to reinstall nvidia-current via jockey, but this time i got an error message
<ScislaC> So... haven't asked in a couple weeks and feel it's due. Any chance that we'll get wacom input drivers again in lucid anytime soon? :)
<bryyce> ScislaC, nope
<ScislaC> bryyce: Oh well... I'll just keep holding off on updating. I just feel like I don't help much with testing when I'm not up to date.
<BUGabundo> evening
<tjaalton> we might get something for some ppa though
<BUGabundo> following tjaalton advice i dist upgraded
<BUGabundo> now my lucid is in low grafics mode
<tjaalton> but not in the archive until the debian maintainer is ok with it
<BUGabundo> but at least mouse and keyb work :\
<knittl> hi BUGabundo :D
<BUGabundo> hey knittl 
<BUGabundo> guys any nvidia or nv driver i can use to get proper resulotion ?
<knittl> BUGabundo: just exit to console and type sudo service gdm start
<knittl> i've had the problem for some time now
<tjaalton> BUGabundo: nv doesn't work?
<tjaalton> logfile hen
<tjaalton> then
<BUGabundo> can i install the one in PPA?
<BUGabundo> if so, why isnt it in archive?
<BUGabundo> tjaalton: havent tested NV. thats why i'm asking
<BUGabundo> install nvidia vdpau PPA
<BUGabundo> removed my xserver-xorg
<tjaalton> no you should have -nv installed. if not, install xserver-xorg-video-all
<BUGabundo> let me se
<BUGabundo> tjaalton: no. -video.all is not here
<BUGabundo> so how do u purpose i fix the blog?
<BUGabundo> Pblob
<BUGabundo> installing X takes nvidia (even from PPA)
<tjaalton> use tseliot's ppa
<BUGabundo> why aint that stuff in x-edger PPA or archive yet?
<tjaalton> because it isn't ready
<tjaalton> or wasn't
<BUGabundo> tjaalton: link please?
<BUGabundo> found it
<BUGabundo> err
<BUGabundo> tseliot ppa only has up to karmic
<BUGabundo> no lucid package
<tjaalton> look closed
<tjaalton> closer
<tjaalton> there are many ppa's
 * BUGabundo blames google
<BUGabundo> x-testing ?
<tjaalton> no
<BUGabundo> saw it
<BUGabundo> prop.impor
<BUGabundo> ok. package list update . now what? install blob?
<tjaalton> i guess
<BUGabundo> tjaalton: which one?
<BUGabundo> i dont see a 185 / 190 / 195 
<tjaalton> you also need the latest mesa/xserver from the main archive
<tjaalton> -current
<BUGabundo> tjaalton: which package name, please?
<tjaalton> nvidia-current
<tjaalton> please, not too hard to look at the ppa
<BUGabundo> no such thing in my apt db
<BUGabundo> nor is nvidia-current in that ppa
<tjaalton> sure is
<tjaalton> rest is left as an excercise
<tjaalton> ->
<BUGabundo> i'm sorry
<BUGabundo> i dont see it
<BUGabundo> nor can i find it with aptitude
<BUGabundo> i see nvidia-common
<BUGabundo> and
<BUGabundo> nvidia-graphics
<bjsnider> tjaalton, nvidia-current is not in alberto's ppa. it is call nvidia-graphics-drivers
<BUGabundo> barf
<tjaalton> then what's this: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+files/nvidia-current_190.53-0ubuntu1~proprietaryppa22_amd64.deb
<BUGabundo> no idea
<BUGabundo> need a screenshot of https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+packages ?
<BUGabundo> cause its not there
<tjaalton> what about "view package details"?
<bjsnider> tjaalton, that is created from the nvidia-graphics-drivers package
<tjaalton> bjsnider: yes, I thought he was looking for the binary package
<tjaalton> apt should find it anyway, after an apt-get update..
<BUGabundo> did that
<BUGabundo> nothing
<BUGabundo> prob didnt build for 64bits
<tjaalton> both are there
<BUGabundo> grrr
<BUGabundo> rebooting
<BUGabundo> and trying again
<tjaalton> that won't help apt
<BUGabundo> i know
<BUGabundo> but i'm frustrated
<BUGabundo> ok 
<BUGabundo> sudo gdm stop
<BUGabundo> now looking for the driver
<BUGabundo> http://paste.ubuntu.com/353644/
<BUGabundo> and
<BUGabundo> http://paste.ubuntu.com/353645
<tjaalton> who's alberto-milano?
<tjaalton> ie. the url is wrong..
<BUGabundo> one - too many
<tjaalton> milone, not milaon
<tjaalton> milano
<tjaalton> so, two typos
<BUGabundo> thanks
<BUGabundo> my eyes are terribly tired
<BUGabundo> already put my eye drops
<tjaalton> copypaste ftw
<BUGabundo> lets see if it improbes
<BUGabundo> tjaalton: humm yeah
<BUGabundo> :(
<BUGabundo> i still cant see them
<tseliot> tjaalton: lol
<BUGabundo> tseliot: i'm sorry, but its not funny
<tseliot> BUGabundo: add ppa:albertomilone/proprietary-video-improvements from the Software sources program
<BUGabundo> i understand you work very hard in providing 
<BUGabundo> this package the best u can
<tseliot> I was laughing about my name
<tseliot> or of what became of my name ;)
<BUGabundo> but when it subums an user system like this without proper upgrade path, it suck 
<BUGabundo> ok 
<BUGabundo> i see current
<BUGabundo> but not -graphics
<tseliot> experimental releases are not intended to be used by everyone
<tjaalton> you want current
<tseliot> yep
<BUGabundo> instrallng
<tjaalton> but your main mirror probably doesn't have the needed mesa/xserver
<BUGabundo> tseliot: i've commited myseft 3 years ago to run at least one box in +1
<tjaalton> tseliot: maybe you should add a Depends on those
<tjaalton> for the nvidia*
<BUGabundo> so i can test, and provide good feedback
<BUGabundo> allowing we all to have a good release after 6 monts
<tseliot> tjaalton: aren't transitional packages enough?
<tjaalton> tseliot: no I mean depends on mesa/xserver
<tseliot> note: I haven't uploaded nvidia in Lucid yet
<tjaalton> since 3d doesn't work with the old ones
<bjsnider> that is going in today right?
<tseliot> yep
<tseliot> an archive admin will have to approve nvidia-current though
<bjsnider> yeah, i'm telling everybody to get rid of the ppa versions that use the old package system
<BUGabundo> ok
<BUGabundo> i got -current from PPA
<BUGabundo> do i need to manually choose a mesa too ?
<tseliot> tjaalton: 3d for nvidia doesn't work with those. 3D with open driver does work
<tjaalton> just make sure you have 7.6.1~rc3-1ubuntu2
<tjaalton> tseliot: umm what?
<tjaalton> tseliot: you need the new mesa for the libs to be sorted out, right?
<BUGabundo> tjaalton:  i dont! installing
<BUGabundo> libosmesa6 right?
<tjaalton> -nv never had 3d, and never will
<tjaalton> BUGabundo: no
<BUGabundo> no?
<BUGabundo> all others are dgb or dev
<tjaalton> what you already have installed, just that the version should be that
<tseliot> tjaalton: aah, you mean versioned dependencies on X and mesa
<tjaalton> you don't need to install any new packages
<tjaalton> tseliot: yes
<BUGabundo> rebooting
<tjaalton> BUGabundo: then again, that version isn't published yet, so it's not available
<BUGabundo> lets see how this goes
<BUGabundo> BAHA
<tseliot> 7.6.1~rc3-1ubuntu2 is what you want
<tjaalton> libdrm uploaded
<BUGabundo> waiittt
<BUGabundo> i have 1280*800
<BUGabundo> this darn cpu stuck in PERFORMENCE is killing me
<BUGabundo> compiz doesnt start
<BUGabundo> do u guys need a trace?
<tjaalton> no
<tjaalton> what I said, you need the new mesa, but it's not available yet
<BUGabundo> ok
<BUGabundo> so tommorrow i just remove the PPA
<BUGabundo> and upgrade normaly=
<BUGabundo> ?
<tjaalton> probably so
 * tseliot nods
<BUGabundo> and we are going with nvidia 190?
<tseliot> BUGabundo: temporarily, yes
<BUGabundo> hey, i can change my GPU power mode now :D
<BUGabundo> do u guys need a nvidia-bug-report.sh log ?
<tjaalton> for what?
<BUGabundo> i dunno
<BUGabundo> just trying to help
<BUGabundo> providing what ever my system can pump out
<BUGabundo> so u guys can check for probs *before* hand
<BUGabundo> but since u dont, I thanks you all for your hard work
<BUGabundo> and will now use my laptop to flash my new WDTV 
<bjsnider> it provides nvidia bug report codes that we don't understand mostly
<BUGabundo> with a new oficial rom, so i can see my movies
<BUGabundo> thanks
<tjaalton> mesa 7.7 uploading.. slowly, killing my irc
<soren> tseliot: Yay! It works now. Thanks!
<tseliot> tjaalton: I'm a bit concerned about those dependencies. What shall I depend on? libgl1-mesa-glx ( >= 7.6.1~rc3-1ubuntu2) and xserver-xorg-core (>= 2:1.7.3.902-1ubuntu2) ?
<tseliot> soren: does it already?
<tseliot> maybe mesa was published
<soren> tseliot: I grabbed the binaries from Launchpad.
<tjaalton> tseliot: something like that, yes
<soren> tseliot: No, mesa still isn't published.
<tseliot> aah
<tseliot> ok
<soren> Oh, it was /just/ published.
<soren> It wasn't 10 minutes ago.
<tseliot> tjaalton: by the time nvidia is approved, builds and is published I bet mesa will be on every server in the world
 * tseliot hasn't uploaded nvidia yet
<tjaalton> tseliot: as you wish
<tseliot> ;)
 * tseliot starts uploading nvidia-current
<tjaalton> xorg merged & uploaded
<tseliot> good
<bryyce> \o/
 * tseliot uploading nvidia-173
<Sarvatt> in our mesa 7.7, shouldnt we be bumping the libdrm-dev build-dep version to 2.4.17 because we use libdrm-radeon1?
<tjaalton> well yes, but since it already depends on .15 which isn't available, we should be good
<tjaalton> I mean, .17 will be available and it fails to build with the current .14
<tjaalton> err, doesn't even try to build
<tjaalton> it's in depwait
<Sarvatt> darn flickering after resume, the latest 01-07 2.6.33-999 kernel didnt have the drm-intel-next pull in it it looks like
<bryyce> <vorlon> bryyce: fwiw, the xorg upload for the nvidia colormap fix has also fixed my intel crash-on-lid-close bug :)
<tjaalton> bryyce: whaaat :)
<Sarvatt> how the heck
<Sarvatt> oh maybe it was in 1.7.4
<bjsnider> what does one have to do with another
<tseliot> come on, don't you believe in magic? :-P
<tjaalton> Sarvatt: yes, most likely
<Sarvatt> forgot it was a version bump in the latest upload, i didnt see how just the gamma fix woulda fixed it
<bjsnider> i'll believe it when i can build against its header file
<bryyce> <vorlon> heh, well, my backtrace also had some color-related stuff in it :)
<bryyce> <vorlon>  I think the crash was specifically related to X trying to query the gamma on an output that had been turned off immediately prior
<tjaalton> it would be nice to verify that it's what fixed it, and add that to the mvo's patch. should help getting reviewed/ack'ed upstream
<tseliot> all the nvidia packages are now in Lucid
<tseliot> I'll upload the other pieces tomorrow
<bryyce> tjaalton, *nod*
<bryyce> <vorlon> man, I'm not bisecting over this :)
<tjaalton> hehe
<Sarvatt> you know, tormod had a problem with that exact hunk in xserver for a few months when i was packaging up xorg 7.5 for karmic
 * slangasek metoo!
<slangasek> I have this exact same bug
<slangasek> ;)
<Sarvatt> he was crashing until this commit http://cgit.freedesktop.org/xorg/xserver/commit/?id=75795637c7160f1579dbe81c2d7600e85b1d141f
<Sarvatt> there was a long discussion on the gamma problem there on xorg-devel i think, might be something interesting in there
<Sarvatt> It also contains a fix from Adam Jackson to not crash on xserver 1.7, but please note that it still doesn't work correctly on that release because the server never calls the old-style colormap setup code.
<Sarvatt> redhat still uses nv for some chipsets, wonder if they have any patches for it
<tjaalton> yes, http://lists.x.org/archives/xorg-devel/2009-May/000982.html
<tjaalton> and continued the next month
<Sarvatt> screwing with that hunk might cause regressions on non -nv is all i was thinking, yeah thats the same chipset tormod was having problems with I think
<tjaalton> we'll see
<tjaalton> everyone signing off for the weekend, just the right time to upload a ton of stuff :P
<tjaalton> slangasek: what was your bug # again?
<slangasek> tjaalton: 494680
<Sarvatt> looks like it only affects G80+ cards under -nv too
<tjaalton> thanks
<Sarvatt> shifting G80+ pci ids to use vesa would probably be better if it ends up causing problems. odd i didnt get any email from xorg-devel about that patch
<tjaalton> well slangasek has an intel, and it fixed the lid-closing crasher, so it's not just -nv
<Sarvatt> looks similar slangasek - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554450
<ubottu> Debian bug 554450 in xserver-xorg-video-intel "xserver-xorg-video-intel: server crash on external monitor when using gnome-screensaver" [Normal,Open]
<tjaalton> indeed it does
<Sarvatt> dpms off with multiple monitor related maybe?
<slangasek> all of these keywords seem to apply :)
<Sarvatt> like I know KDE does a dpms off on lid close from tracking down another bug it had awhile back (dont know what you're using)
<Sarvatt> do you have g-p-m set to "do nothing" on lid close?
<Sarvatt> or blank screen?
<Sarvatt> i really dont know how its all connected at the moment but you might want to try disabling activate screensaver when idle in gnome-screensaver and set g-p-m to do nothing on lid close and try it out
<Sarvatt> if it didnt happen when booting with nomodeset would also be good to know
#ubuntu-x 2010-01-09
<Sarvatt> sorry, didnt read the full bug and thought you were the person still having a problem with it :D
<Sarvatt> well thats new, gdm didnt start and dropped me to a login prompt at boot but i got a message that it terminated with exit status 1 this time
<Sarvatt> usually just silently drops me to login most boots
<Sarvatt> no logs of course
<bryyce> hrm
<bryyce> used to be it'd at least left an error msg in the gdm log file
<bryyce> does it not do this anymore?
<tjaalton> mine didn't get that far
<bryyce> xterm merged
<Sarvatt> it touches the /var/log/gdm/:0.log but doesnt update it at all
<Sarvatt> the timestamp is right but the contents are from last boot
<Sarvatt> *when it happens
<slangasek> Sarvatt: g-p-m is configured to 'blank screen' (i.e., 'lock screen'0
<bryyce> heh go figure, I have three test machines, and at the moment none of the 3 are booting
<bryyce> * and I don't remember why
<bryyce> * and vt switching is not working on any of them
<Sarvatt> there was a nasty bug for awhile where dpms off would crash intel with multiple screens and dpms off was getting called in some tricky places, changing those options fixed it for some people back then
<tjaalton> bryyce: if they use kms it's because of failsafe the vt change doesn't work
<bryyce> well I likely was testing kms on them
<Sarvatt> i still have wacky vt switching, alt+fkey works but control+alt+fkey doesnt work to go back to X from a vt
<bryyce> but that was back before holidays
<bryyce> so they've not been updated in a while, maybe I ought to do fresh reinstalls
<bryyce> hm one boots it just shows nothing on the screen
<slangasek> "back before holidays" - so gdm was even more likely to fail on boot-up then :)
<bryyce> indeed
<bryyce> in fact, debugging that problem was the last time I remember having all three systems in use
<Sarvatt> yeah no fedora patch to -nv to work on G80+ of course because they use nouveau for that, and thats the only place mvo's patches are fixing I think
<tjaalton> Sarvatt: the patch for the server?
<bryyce> aha sure enough
<Sarvatt> yeah, -nv just had a fix that stopped the crash on boot but still had the color problems and isnt supposed to work on 1.7 yet, went looking at fedora cvs to see if they were patching it but then i saw it was only a problem on G80 and newer and of course they didnt patch it because they use nouveau :D
<tjaalton> Sarvatt: that one is from upstream .16
<Sarvatt> yeah
<tjaalton> and only the xserver patch was enough to make it work
<tjaalton> but no reason to drop the -nv one since it's upstream anyway
<Sarvatt> the xserver patch doesnt work with nv .16, that commit  breaks it
<tjaalton> so mandriva ships a forked -sis with a 1,4MB patch on top of it, and calls the result sisimedia
<Sarvatt> yeah I have sis in one of my servers I messed around with that on
<tjaalton> too bad that it's the only driver supporting 671/771 chips
<Sarvatt> some sis employee leaked an internal blob
<bryyce> heh
<tjaalton> it's not a blob, but a diff
<Sarvatt> i couldnt even get it working with xserver 1.6 though :(
<Sarvatt> they leaked it as a blob i mean, was blob only for years
<tjaalton> ok
<Sarvatt> intrepid was the last release i could use it under
<Sarvatt> http://ncc-1701a.homelinux.net/~linux-sis/index.php?page=FrontPage
<Sarvatt> backstory on it there
<tjaalton> woohoo, we are again under 2800 bugs
<bryyce> seriously?
<tjaalton> yes, filed some dupes
<bryyce> oh, I read the 8 as a 0
<tjaalton> Sarvatt: uh, what a mess
<tjaalton> bryyce: hah, in your dreams :)
<bryyce> yeah saw you've been busy in the tracker timo :-)
<tjaalton> a drop in the ocean though
<bryyce> tjaalton, yeah I gotta bump up the y-axis on my graphs again :-(
<bryyce> tjaalton, I just closed half the xterm bug reports :-)
<tjaalton> hehe, I noticed that the total count went down ~25 bugs
<bryyce> well I can claim responsibility only for maybe 7 ;-)
<tjaalton> there were several dupes about that sis chip
<tjaalton> 25 bugs is almost 1%
<bryyce> tjaalton, btw, I dunno if I mentioned this but I set up a new report at http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/high-karma-bugs.html
<bryyce> it shows bugs reported by people with over 10k karma
<Sarvatt> oh its the 3D driver that was the blob
<tjaalton> ooh, so few
<JontheEchidna> hi, any clue what would cause the following? http://launchpadlibrarian.net/37629930/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz
<JontheEchidna> (it built fine in pbuilder yesterday)
<bryyce> JontheEchidna, wrong channel, this is just for X.org packaging discussion
<tjaalton> make[3]: *** No rule to make target `/usr/lib/libGL.so', needed by `lib/libkwineffects.so.1.0.0'.  Stop.
<JontheEchidna> well, it seems to be an X related failure :)
<tjaalton> likely due to the mesa change
<bryyce> tjaalton, yeah I have been thinking that looking at *all* bugs is too overwhelming, so looking to slice out saner subsets to focus on more realistic goals
<JontheEchidna> looks like there's a new mesa waiting to be built
<tjaalton> JontheEchidna: that doesn't change anything
<JontheEchidna> ah, right: https://edge.launchpad.net/ubuntu/+source/mesa/7.6.1~rc3-1ubuntu2
<tjaalton> maybe gl.pc needs to be changed
<tjaalton> libdir=/usr/lib
<tjaalton> while it's /usr/lib/mesa now..
<tjaalton> oh well, anything build-depending on libgl1-mesa-dev fails to build now
<tjaalton> including the xserver
<tjaalton> because /usr/lib/libGL.so points nowhere
<bryyce> bugger
<Sarvatt> well good news and bad news and more bad news
<Sarvatt> execbuff while wedged after about an hour uptime with a newer intel :(
<Sarvatt> gl is all kinds of messed up right now until mesa gets published
<Sarvatt> but I think I found why intel isnt booting into gdm
<Sarvatt> i moved /lib/udev/rules.d/40-xserver-xorg-video-intel.rules out of the way and it booted into my desk 6 times in a row
<Sarvatt> desktop*
<bryyce> what's in that file?
<Sarvatt> DRIVER=="i915, "ACTION=="change", ENV{ERROR}==1, PROGRAM="/usr/share/apport/apport-gpu-error-intel.py"
<bryyce> aha yes
<bryyce> ooh maybe this will explain why that's not been working
<Sarvatt> i dont even have that file
<bryyce> I thought that file sounded familiar :-)
<bryyce> hmm, neither do I
<bryyce> however my intel box is booting ok
<bryyce> that file should be provided by xserver-xorg-video-intel
<tjaalton> I do
<bryyce> debian/rules has the command to install it
<bryyce> rules:	install -m 755 debian/apport-gpu-error-intel.py $(CURDIR)/debian/tmp/usr/share/apport
<tjaalton> oh the apport file
<tjaalton> don't have that one
<bryyce> how about /usr/bin/intel_reg_dumper ?
<bryyce> I'm missing that as well
<tjaalton> intel-dbg installs that one
<bryyce> perhaps the apport script just needs added to xserver-xorg-video-intel.install?
<bryyce> I suppose if we do this then intel_reg_dumper ought to move into that as well
<tjaalton> yeah
<Sarvatt> that python script should be installed with intel-gpu-tools shouldnt it? it calls intel_gpu_dump from that package
<bryyce> yeah they definitely go together
<bryyce> what do you guys think, should they be in the -dbg or the normal package?
<tjaalton> -dbg is not on a stock install
<tjaalton> while -intel and i-g-t are
<Sarvatt> wish intel_gpu_dump was always installed for intel since its doesnt gain anything from being in the dbg package
<bryyce> I tend to agree
<tjaalton> it's in i-g-t, not -dbg
<bryyce> ok, I'll add to my todo list to fix this up and move the dump tool into the regular package
<tjaalton> it's installed already, by intel-gpu-tools
<bryyce> what's i-g-t?
<tjaalton> -dbg has intel_reg_dumper
<bryyce> oh right, this got split out
<Sarvatt> i mean intel_gpu_dump doesnt need anything from -dbg, and moving the apport script to dbg wouldnt get much use
<Sarvatt> in intel 2.10 reg_dumper is in i-g-t now too yeah
<tjaalton> hmm? they are separate sources
<bryyce> yeah
<tjaalton> or do you mean 2.10 dropped reg_dumper?
<Sarvatt> wonder why that udev rule is dropping me to a login prompt on boot most times though if thats what it is, would be interested if it fixes it for you tjaalton
<bryyce> so make the driver depend on i-g-t now, and then put the apport script into the base .install?
<Sarvatt> yeah 2.10 dropped intel_reg_dumper from the intel source
<tjaalton> bryyce: it already Recommends it
<bryyce> tjaalton, ok great
<tjaalton> Sarvatt: so gpu_dump replaces it?
<tjaalton> no wait
<tjaalton> it's in i-g-t now
<Sarvatt> yep
<tjaalton> but master, not 1.0.2
<Sarvatt> we'll need to change i-g-t to install it whenever we update intel
<Sarvatt> hmm thought it moved to i-g-t in the one we have and just wasnt getting installed last i checked
<Sarvatt> nope!
<Sarvatt> not in tools/
<tjaalton> the commit was right after the tag
<tjaalton> hmm, mesa glx libdir is /usr/lib/glx, but nothing gets installed there
<tjaalton> changing it to /usr/lib/mesa seems to have helped somewhat
<tjaalton> but gl.pc didn't change
<tjaalton> oh well, too late anyway
<Sarvatt> wonder how much longer mesa is going to take to go out, takes about 45 minutes to build on this thing but I'd like GL back :D
<Sarvatt> compiz starts up and takes control as window manager but doesn't work right now
<Sarvatt> had to vt switch and DISPLAY=:0 metacity --replace
<bryyce> usually takes a couple hours plus or minus a bit
<Sarvatt> maybe libgl1-mesa-swx11 should be updated for /usr/lib/mesa as well?
<Sarvatt> looks like mandriva has hit some bugs with the setup we're moving to where some binaries had RPATH hardcoded
<Sarvatt> http://lists.freedesktop.org/archives/compiz/2008-March/003067.html
<bryyce> x11-xserver-utils merged
<ScottK> Is anyone looking into the current mesa breakage?
<superm1> w/ tseliot's new stuff?
<Sarvatt> it's just broken until its published
<ScottK> So 7.7-0ubuntu1 is the fix?
<Sarvatt> yeah
<ScottK> OK.  That's not so bad.
<Sarvatt> still 30 minutes till amd64 even starts to build :(
<ScottK> Probably worth trying to poke a buildd admin to rescore it.
<Sarvatt> hmm didnt we used to not build libgl1-mesa-swx11-i686 with mesa?
<bryyce> libgl1-mesa-glx-i686 was commented out, is that what you were thinking of?
<bryyce> or libgl1-mesa-dri-i686, that's commented out too
<Sarvatt> yeah must be thinking of those, packages.ubuntu.com says I'm really wrong :)
<Sarvatt> just noticed the intel packaging i do on edgers doesn't have that udev rule in it, but i still had the udev rule hanging around from the ubuntu one
<Sarvatt> oops, didn't think about how I cant use origin/ubuntu for karmic anymore and almost uploaded a new mesa :D
<JontheEchidna> builds still fail with latest mesa: http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt.
<Sarvatt> ScottK: I'm sorry, by "breakage" I didn't know you meant this build breakage, gl was broken everywhere for a few hours there if someone updated in the middle (like I did)
<ScottK> Sarvatt: OK, so waht's the solution?
<tjaalton> Sarvatt: 7.7 is _not_ the solution
<tjaalton> tseliot: hey, the mesa change breaks any build that needs /usr/lib/libGL.so (or gl.pc)
<tseliot> tjaalton: ???
<tseliot> ldconfig should know where libGL.so* is
<tjaalton> but libGL.so points nowhere
<tseliot> let me check
<tjaalton> 06:36 < JontheEchidna> builds still fail with latest mesa:
<tjaalton> http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt.
<tseliot> the link appears to be brokeni
<tseliot> broken
<tjaalton> yes, because libdir wasn't changed
<tjaalton> but that's not enough
<tseliot> no, I mean the URL
<tjaalton> and I said the reason for that
 * tseliot slept less than 5 hours
<tseliot> tjaalton: there's no trace of libGL.so here, only libGL.so.1
<tjaalton> libgl1-mesa-glx-dev
<alkisg> Hi, are the proprietary nvidia drivers currently working for Lucid? I see 185 in jockey, should I go ahead and install it? I have 8600M GT.
<tjaalton> anything that build-depends on that will fail
<tjaalton> or mesa-common-dev, which has the gl.pc
<tjaalton> testing the mesa build again..
<tseliot> tjaalton: so it's just a matter of adding a link, right?
<tseliot> in /usr/lib/mesa
<tseliot> libGL.so -> libGL.so.1
<tjaalton> no links, fixing the config options
<tjaalton> +but rather
 * alkisg tries to install the 185 drivers...
<tseliot> alkisg: no, 185 won't work
<tseliot> nvidia-current should
<tseliot> and please don't use jockey. It doesn't support the new drivers yet
<alkisg> tseliot, I don't see nvidia-current in synaptic... /me googles...
<tjaalton> your mirror doesn't have it yet
<tseliot> alkisg: then I guess you'll have to wait until your mirror gets it
<alkisg> tseliot: ah, thank you, that's it (I'm in Greece)
<alkisg> (and tjaalton :))
<tseliot> tjaalton: $(LIB_DIR) is what we need to set, right?
<tjaalton> tseliot: well, --libdir
<tjaalton> but setting that would install gl{,u}.pc in /usr/lib/mesa/pkgconfig, which is wrong
<tjaalton> that can be fixed in *.install
<tjaalton> but practically, everything libGL* needs to be moved to /usr/lib/mesa
<tseliot> tjaalton: libgl1-mesa-dev.install
<tjaalton> so the changes are not that small in the end
<tjaalton> wonder how many places hardcode /usr/lib/libGL*
<tjaalton> in proprietary apps etc
<tseliot> they can call dlopen() but the Mandriva developer told me that it works
<tjaalton> tseliot: libgl*.install
<tjaalton> but they don't install these in a subdir, right?
<tjaalton> so we are deviating from them
<tseliot> tjaalton: they will install libGL* in a subdir. It's only by chance that things work there
<tseliot> as they didn't enable tls
<tjaalton> http://pastebin.ubuntu.com/353841
 * tseliot reads the diff
<tseliot> tjaalton: it looks good
<tjaalton> tseliot: what package installs the ld.so.conf.d/gl.conf or what's that called?
<tseliot> tjaalton: the xserver installs the /usr/lib/standard-x11/ld.so.conf
<tjaalton> no I mean the one with the libGL path
<tseliot> and /etc/ld.so.conf.d/GL.conf points to it
<tseliot> tjaalton: ldconfig reads /etc/ld.so.conf.d/GL.conf and knows where to find libGL.so
<tjaalton> ok
<tseliot> when you switch to nvidia, GL.conf points to a different conf file which tells ldconfig where it can find the nvidia libGL stuff
<tjaalton> xserver build still failed
<tjaalton> dpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/xserver-xephyr/usr/bin/Xephyr (ELF format: 'elf32-i386'; RPATH: '').
<tseliot> tjaalton: did you do an ldconfig?
<tseliot> or is it still a matter of .pc files?
<tseliot> as I assume that you're testing locally
<tjaalton> I would've thought installing the packages ran ldconfig
<tseliot> tjaalton: yes, but what packages are we talking about?
<tjaalton> the mesa ones
<tseliot> X and nvidia do it
<tjaalton> built locally, installed them and built xserver
<tseliot> maybe should call ldconfig in mesa too
<tseliot> we should
<tjaalton> though I didn't have the newer xserver
<tseliot> tjaalton: what does ldconfig --print | grep GL say?
<tjaalton> installing the xserver didn't run ldconfig
<tjaalton> I have libGL now that I ran ldconfig manually
<tseliot> aah
<tjaalton> so the xserver build should pass now
<tseliot> hopefully ;)
<tseliot> BTW thanks for working on this
<tjaalton> np
<Duke`> I wonder why on my lucid box, when I boot Xorg fails, but when I just restart gdm service, it works well.
<knittl> good morning
<tseliot> my X seems to make the system freeze...
<tseliot> Duke`: that might be a racing problem between KMS and gdm
<tjaalton> I can't get dri working
<tjaalton> anymore
<tseliot> tjaalton: was it really necessary to change --libdir for confflags-dri ?
<knittl> so, i want to give nvidia drivers another try
<knittl> i purged nvidia* yesterday
<tjaalton> tseliot: yes, that's where libGL is built
<knittl> what do i need to install for jockey to work?
<tseliot> knittl: you can't right now. I haven't uploaded the new jockey yet
<knittl> tseliot: ok, so i'll wait
<knittl> but i could install the necessary packages anyway
<knittl> nvidia-common i think it was
<tseliot> tjaalton: can you show me the X log and the output of update-alternatives --display gl_conf please?
<tseliot> knittl: I haven't uploaded the new nvidia-common either
<knittl> ok, then i wait :D
<tseliot> knittl: if you need to install the latest driver, this should work:
<tseliot> install nvidia-current and then type sudo nvidia-xconfig
<knittl> i thought this will not work because of update-alternatives-something jockey does behind the scenes
<knittl> at least i remember bugabandoo saying something about it
<tseliot> knittl: yes as alternatives work in automatic mode without it. And in automatic mode the latest nvidia driver always wins
<tseliot> if you want to install -173 or -96 some manual configuration is required
<knittl> i have a quadro fx 360m here, it uses the latest driver
<tseliot> ok then
<tjaalton> tseliot: that looks normal
<tjaalton> and the x log shows that dri is fine
<tseliot> tjaalton: what does the other command say?
<tseliot> did you upload something that could break evdev recently?
<tseliot> it seems to segfault here
<tjaalton> no
<tjaalton> what hw?
<tseliot> radeon
<tjaalton> I mean input hw
<tseliot> a usb keyboard
<tseliot> and a usb mouse
<tjaalton> put the logfile somewhere
<tseliot> I wish I could enter Recovery mode again
<tseliot> or even ssh into my testing box
<tseliot> :-/
<tjaalton> how do you know it's evdev then?
<tseliot> I managed to boot in Recovery mode before
<tjaalton> kms ftw
<tjaalton> +vesa
<tseliot> now grub starts and ignores my keyboard (i.e. doesn't offer me a menu)
<tseliot> shall I use fbdev if/when I can?
<tjaalton> there's a bug open about that
<tjaalton> fbdev failsafe with kms
<tjaalton> so no dri with the mesa changes
<tjaalton> and I don't really have time for this :)
<tseliot> tjaalton: you didn't give me the output of that command though
<geser> Hi, is it expected that libgl1-mesa-glx in lucid puts their libs in /usr/lib/mesa? as this leaves libgl1-mesa-dev with a broken /usr/lib/libGL.so link
<tjaalton> alternatives? I said it looked ok
<tseliot> tjaalton: and what do you mean by no dri, exactly?
<tjaalton> not completely true though, glxgears seems to be accelerated
<tseliot> geser: tjaalton wrote a fix for that. But yes, the change is intended
<geser> so only the -dev package is currently broken?
<tseliot> tjaalton: are you referring to glxinfo |grep direct?
<tjaalton> tseliot: yes
<tjaalton> and the logfile says DRI is on
<tseliot> tjaalton: anything interesting in dmesg?
<tjaalton> no
<tseliot> tjaalton: did dri work before your last change?
<tjaalton> it works with stock packages
<superm1> tjaalton, how founded is your worry about apps hardcoding to /usr/lib/libGL.so.1 (do you have examples?)?
<tjaalton> superm1: none
<tseliot> tjaalton: stock being 7.7-1ubuntu1 ?
<tjaalton> the one from the archive
<tseliot> ok
<tjaalton> tried a dist-upgrade and stuff works then
<superm1> tseliot, i dont think you can recommend people install from the archive still even before jockey stuff is in place, nvidia-current is still in NEW: https://edge.launchpad.net/ubuntu/lucid/+queue
<tjaalton> tseliot: I don't know, feel free to mess with the links, I've spent too much time on this already
<tseliot> tjaalton: ok
<tseliot> superm1: slangasek told me that he approved them
<superm1> tseliot, oh he only approved the source packages then, still has to approve binaries
<tseliot> d'oh
<tseliot> tjaalton: my filesystem was broken. X starts now
<knittl> ok, x won't startâi guess this is still related to -nv drivers? am i correct?
<tseliot> tjaalton: radeon still seems to fail though (with stock X and mesa). fbdev works
<tjaalton> tseliot: it's a pretty old snapshot
<knittl> how can i use vesa or nouveau?
<tseliot> tjaalton: which used to work with the old mesa and drm. Downgrading mesa didn't help. I'll try downgrading libdrm
<tjaalton> tseliot: the api changed
<tjaalton> so we really need a new snapshot
<tjaalton> tseliot: but, compiz works here again with the new stuff
<tjaalton> double-checked that the -dev packages were correct
<tjaalton> and rebuilt xserver, and works now
<tseliot> tjaalton: what driver are you using? Intel?
<tseliot> tjaalton: also, did you upload your fix?
<tjaalton> intel yes, and didn't upload anything yet
<knittl> The following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is
<knittl> not going to be installed
<tjaalton> knittl: would need a new snapshot
<knittl> tjaalton: ok, so the only way is to use vesa for now?
<tjaalton> or -nv?
<tseliot> tjaalton: please upload the fixes if they work correctly
<tseliot> or push them to git and I'll upload them if you prefer
<knittl> tjaalton: gdm/X won't start, tells me to run in low graphics mode
<tseliot> knittl: try fbdev
<tjaalton> tseliot: I'm just trying to figure out if the xserver needs to be rebuilt or not
<knittl> i nuked my xorg.conf
<tjaalton> knittl: so you're using vesa then
<knittl> tjaalton: but vesa should work?
<tseliot> if that's what you're using
<knittl> how can i find out?
<knittl> or, what is the default without an xorg.conf?
<tjaalton> you are running failsafe == vesa
<knittl> i'm not running anything atm
<tseliot> tjaalton: if Xephyr depended on mesa, then I guess we need to rebuild X against the new mesa
<knittl> i exited to console
<tjaalton> tseliot: uh wait, I didn't have the new glx installed, so no, it doesn't work
<tseliot> tjaalton: do we have a new snapshot of radeon in xorg-edgers with the new api?
<tjaalton> tseliot: I don't know, probably
<tseliot> shipping the alpha in this state wouldn't be ideal
<tjaalton> really? :)
<tseliot> I'll try intel here
<tjaalton> only the radeon api changed
<tjaalton> in libdrm/mesa/ddx
 * tseliot hates grub 2
<tjaalton> ok, signing off.. need to start reading asap ->
<sebner> tseliot: Building gnome-shell gives me: checking for glXCreateContext in -lGL... no   ---> internet tells me (old gnome-games bug): The libglx.so from nvidia binary
<sebner> driver was replaced by xserver upgrade. That was causing this problem.
<tseliot> sebner: we need the fix that tjaalton wrote for that
<tseliot> I'll test things here now
<sebner> tseliot: cool, /me is afraid of rebooting right now so sebner keeps his 3d for now :P
<geser> sebner: libgl1-mesa-dev is currently broken in lucid, so everything which tries to link with -lGL will currently fail
<tseliot> right
<sebner> geser: oh ho! good to know, thx
<tseliot> the fix that I mentioned is supposed to solve that
<sebner> :)
<tseliot> tjaalton: if I try to build with your patch I get this: dh_install: libgl1-mesa-swx11 missing files (usr/lib/mesa/libGL.so.*), aborting
 * tseliot -> lunch
<tseliot> never mind
<wind-rider> tjaalton: ping
<wind-rider> tjaalton: after updating libdrm, X segfaults when using the radeon driver (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505112)
<ubottu> Launchpad bug 505112 in xserver-xorg-video-ati "Segfault at X startup with radeon driver (dup-of: 505095)" [Undecided,Confirmed]
<ubottu> Launchpad bug 505095 in xserver-xorg-video-ati "X don't start in Lucid" [Undecided,New]
<tseliot> wind-rider: the API changed. I'm working on it
<wind-rider> tseliot: ok, great, thx :) i saw tjaalton updated the package at https://lists.ubuntu.com/archives/lucid-changes/2010-January/003025.html
<tseliot> you might want /me nods
<wind-rider> tseliot: so i thought he might know more
<tseliot> stupid keyboard..
<tseliot> wind-rider: thanks for filing the bug report
<tseliot> oh, it's a duplicate
<wind-rider> tseliot: oh, that's fine :) i just confirmed it
<tseliot> ok
<wind-rider> tseliot: and marked a duplicate
<wind-rider> tseliot: it is assigned now at the xserver-xorg-video-ati package, should it be changed?
 * tseliot nods
<tseliot> no
<tseliot> I'll take care of the bug report
<tseliot> thanks
<wind-rider> great :) thx to you!
<sebner> tseliot: my Xserver segfault after reboot ^^
<tseliot> aah, so it was that
<sebner> tseliot: that means?
<tseliot> sebner: never mind I confused you with someone else
<sebner> ah
<sebner> tseliot: me blames the xorg update :P want to see nvida bugreport?
<tseliot> sebner: the above mentioned crash is about radeon
<sebner> tseliot: nvidia blob ~o~
<Duke`> wtf, left computer for 2 hours and found it in kernel panic mode when back
<ScottK> tseliot: What's the plan on mesa?  In Kubuntu we are broken and will stay broken (as in no Alpha 2) until it's fixed.
<tseliot> ScottK: I'm working on it
<sebner> tseliot: nvida blob working again. it's like using windows. doing reboots fixes stuff ^^
<ScottK> tseliot: OK.  Are we talking minutes, hours, or days until it's fixed?
<Sarvatt> ahhah its a race between gdm starting up which needs dbus ready and dbus starting at the same time so its not always ready -- https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/502838
<ubottu> Launchpad bug 502838 in gdm "gdm starts too early, X.org/VTs fail" [High,Incomplete]
<tseliot> ScottK: I've been working on it today. The fact that the other upload of mesa (7.7) broke radeon slowed me down a bit
<tseliot> ASAP is my answer
<tseliot> hopefully today
<ScottK> tseliot: I understand.  Thanks.
<ScottK> tseliot: Based on that, I just sent a status to kubuntu-devel letting people know it may be a while.  I'll quit bugging you and let you focus on getting it fixed ....
<tseliot> ScottK: ah, thanks for sending that email. It was a good idea
<ScottK> That's why I was asking for an estimate.
<tjaalton> tseliot: having problems with -ati?
<tseliot> tjaalton: it looks like the new driver works only with nomodeset
<tjaalton> tseliot: oh
<tseliot> also the patch that you gave me for mesa seems to be wrongly formatted (I guess it's pastebin/browser's fault)
<tjaalton> could be
<tseliot> I changed things manually and I'm building now
<Sarvatt> yeah ati needs updating due to the libdrm-radeon1 api change http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=4b05c47ac657f9a93d76221269761ed64c81f716
<tjaalton> tseliot: try pulling just that commit on top of the current driver
<tseliot> tjaalton: I had taken what's in master but sure I can try that
<tjaalton> maybe the displayport stuff broke something
<tjaalton> btw, add DEB_BUILD_OPTIONS="parallel=2" or such to your session, speeds up the builds a lot
<tjaalton> if you have a multicore cpu
<tjaalton> mesa builds in 15min on my laptop
<Sarvatt> yay this fixes the gdm startup problem here -- http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/186
<tjaalton> wow
<Sarvatt> just a little one liner in /etc/init/gdm.conf
<tjaalton> with the config_init fix from debian there should be even less problems booting up :)
<jcristau> there's still some weird stuff going on, but yes.
<wind-rider> i had some problems before the radeon driver was broken
<wind-rider> kdm or the X server did not start automatically
<wind-rider> i had to log in on a console and run startx
<wind-rider> is that a known problem?
<knittl> wind-rider: yes, it's known
<tjaalton> hard to say without the error msg
<wind-rider> tjaalton: there was no error message
<tjaalton> does kdm use upstart?
<jcristau> in other news, http://ftp-master.debian.org/new/xf86-input-wacom_0.10.3+20100109-1.html
<tjaalton> jcristau: wow!
<wind-rider> i have no idea if kdm uses upstart
<tjaalton> is there a job script in /etc/init ?
<Sarvatt> eww, grabbing the source for kdm pulls in a 70mb package :D
<tseliot> tjaalton: oh, thanks, I have an icore7
<ScottK> tjaalton: kdm does use upstart in Karmic and later.
<tseliot> tjaalton: with your patch: cp: cannot stat `debian/tmp/usr/lib/glx/pkgconfig/dri.pc': No such file or directory
<tseliot> dh_install: cp -a debian/tmp/usr/lib/glx/pkgconfig/dri.pc debian/mesa-common-dev/usr/lib/pkgconfig// returned exit code 1
 * Sarvatt cheers at wacom
<tjaalton> ScottK: so maybe it needs a similar fix as gdm added in the latest upload?
<ScottK> Sigh.  Of course the package that it's part of is currently unbuildable due to mesa ...
<ScottK> tjaalton: Where's the patch?
<Sarvatt>  http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/186
<ScottK> Thanks.
<ScottK> Sarvatt and tjaalton: Looks like it does.  Thanks.
<tjaalton> ScottK: ncie
<tjaalton> *nice
<tjaalton> tseliot: ok, that was an old one then, let me give you the full diff..
<tjaalton> tseliot: http://users.tkk.fi/~tjaalton/foo/mesa.diff
<Sarvatt> where can I get the source for that wacom upload? don't see it on ftp.debian.org
<tjaalton> tseliot: that variable works with most, if not all xorg modules
<Sarvatt> ah got it ftp-master.debian.org, slow today :D
<tjaalton> tseliot: http://users.tkk.fi/~tjaalton/foo/mesa.diff
<tjaalton> but.. installing the resulting libgl1-mesa-glx breaks things
<tjaalton> glxinfo says DRI is used etc, ldconfig finds the libs but apps still fall back to software rendering
<tjaalton> we could sort this out later, and just link whatever is necessary to get the builds rolling again
<tjaalton> ugly, yes..
<tseliot> yes, I know
<tseliot> is that a different patch?
<tseliot> in the same place?
<tjaalton> that's the current git diff
<tjaalton> which builds fine
<tseliot> aah
<ScottK> Sarvatt and tjaalton: It's actually not an immediat problem for kdm, because we still use hal, but I added it anyway as it doesn't hurt to be explicit.
<tseliot> ok
<tjaalton> ScottK: ok
<tseliot> tjaalton: I would like to see what it builds exactly
 * tseliot is building mesa again
<tjaalton> hmm
<tjaalton> oh crap
<tjaalton> I know what's wrong
<wind-rider> ScottK: so it does not solve the problem having to run startx manually?
<ScottK> wind-rider: I don't know for sure.
<ScottK> I doubt it.
<wind-rider> ok
<wind-rider> just to have it clear
<tjaalton> libgl1-mesa-glx has the swx11 version of libGL
<wind-rider> knittl: is it already at launchpad?
<tjaalton> because they are installed in the same prefix
<tjaalton> normally the dri version would be in lib/glx
<tjaalton> tseliot: so, only changing the libdir for swx11 should be enough
<tjaalton> I'll wrap up a new diff
<knittl> wind-rider: yes, but i can't find it right now
<knittl> https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/502838
<ubottu> Launchpad bug 502838 in gdm "gdm starts too early, X.org/VTs fail" [High,Fix released]
<knittl> found it :D
<wind-rider> knittl: ok, i saw that one earlier today :) but it is for gdm
<knittl> oh, are you using kde?
<knittl> but it's probably the same cause
<tseliot> tjaalton: that would make sense ;)
<tseliot> I'm building ati with only the API patch
<tjaalton> so I found out the reason for the different libdir for the dri target :)
<wind-rider> knittl: ScottK changed it in kdm but he thought it would not solve the problem as he says kdm still uses hal there
<knittl> ok, i don't know about kdm. thought it might be helpful anyway
<wind-rider> knittl: ok
<tseliot> tjaalton: -ati is not maintained in git, is it?
<tseliot> as getting only that patch makes it work again with KMS
 * tseliot wonders if the master branch requires a kernel update
<tseliot> or if they just broke the code
<tjaalton> tseliot: no it's not
<tjaalton> great that it works
<tjaalton> cherry-picked the config_init fix
<tseliot> tjaalton: this one? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=36bd69affc996c92c40b7360a7fbaa1a3a46abfd
<tseliot> or are you referring to mesa now?
<tjaalton> no, xserver :)
<Sarvatt> its the libdrm interface to -ati that changed and broke it, no worries about the kernel
<tjaalton> maybe ati master needs libdrm master
<tseliot> tjaalton: ok, I just wanted to make sure that my upload of -ati could begin without problems
<tjaalton> it should
<tseliot> ok
<tjaalton> libdrm doesn't seem to have much ati related post .17
<tseliot> Sarvatt: I know. I was wondering if drm in the kernel had something that we're missing
<Sarvatt> oh shoot, apw was asking if it was ok to turn on radeon KMS by default for a2 and it probably would have been good to mention that ati kms was broken on r600+ with 2.6.32.2 and fixed in 2.6.32.3
<jcristau> Sarvatt: i think they have the fix in the lucid kernel?
 * tseliot has an r600 card and KMS works
<jcristau> Sarvatt: https://lists.ubuntu.com/archives/lucid-changes/2010-January/002876.html seems to have it (the airlied patch)
<tjaalton> yep
<Sarvatt> no linux-meta for that kernel yet but good to see its in there now
<tjaalton> probably not even published yet
<tjaalton> those need to be pushed through the new queue every time
<tjaalton> ah, -10 is published
<tseliot> ok, -ati uploaded
<tseliot> tjaalton: did you upload mesa?
<tjaalton> tseliot: no, still need to test
<tseliot> ok
 * tjaalton does the dri-dance
<tjaalton> works
<tseliot> \o/
<tjaalton> *phew*...
<tseliot> hey we're risking to have an actually functioning alpha 2
<tseliot> :-P
<tjaalton> I need to break it when I get back from the party ;)
<tjaalton> (not)
<tjaalton> keyboards should have breathalysers
<tjaalton> "did I write _that_?"
<tseliot> hey if you don't have time to break it, I definitely can do it for you ;)
<tseliot> :-D
<tjaalton> facebook/putty on a Series60 phone is a killer, literally
<jcristau> hmm i guess i'd need 10 days to break it.  need to have stuff transition to squeeze before it gets autosynced :/
<tseliot> tjaalton: on the e71 ?
<tjaalton> tseliot: yes
<tseliot> oh
 * tseliot wants it on his e71 too
<tjaalton> it's not a good idea to check facebook on the taxi when getting back home :P
<tseliot> heh
<tjaalton> just google, it works very well
<tjaalton> putty that is
<tseliot> will do
<tjaalton> jcristau: I doubt there'll be much stuff to autosync that might risk breaking anything :)
<tjaalton> mesa uploading
<tseliot> :-)
<wind-rider> tjaalton: if mesa and -ati are uploaded, will my X server work again?
<jcristau> tjaalton: i don't think x11-xkb-utils is forked?  so i could break xkbcomp, but people won't let it move to testing if i do that :/
<tseliot> wind-rider: -ati alone should do it. The problem with mesa was visible only if you tried to build something
<wind-rider> tseliot: ok, great :) i
<wind-rider> 'll try it
<wind-rider> tjaalton, tseliot: thx for your work
<tseliot> jcristau: break xkbcomp? Why? Did they change anything interesting?
<tseliot> hey, we break it, we fix it ;)
<tseliot> (and break it again)
<jcristau> tseliot: no.  it was just me trying to see how i could break alpha2
<tseliot> jcristau: too bad. That could have broken the xkbcomp patch that we use to reduce boot time
<wind-rider> bye
<tseliot> oh, well, we'll think of something else
<tjaalton> jcristau: right, x11-xkb-utils is the same in both
<Sarvatt> hmm not having any luck searching launchpad for pixman bugs with asserts that would be fixed by upgrading to pixman 0.16.14. only getting the one result with pixman assert in the title
<wind-rider> ScottK: do you know if one can see a package's build status?
<wind-rider> ScottK: is it somewhere on launchpad?
<ScottK> wind-rider: Yes.  What are you looking for?
<ScottK> tjaalton: mesa FTBFS: https://launchpad.net/ubuntu/+source/mesa/7.7-0ubuntu2/+build/1438098
<dhillon-v10> ScottK, hi, now that I am working on X what would be the first place to get started, triaging some bugs, I read the wiki page so
<ScottK> dhillon-v10: I know very little about X.  I'm the wrong one to ask.
<wind-rider> ScottK: at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505095 is stated that the fix has been committed, but that the package will be only in the repo when it is built
<ubottu> Launchpad bug 505095 in xserver-xorg-video-ati "X don't start in Lucid" [High,Fix released]
<wind-rider> ScottK: i found https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.12.99+git20091125.0061c4db-0ubuntu2
<ScottK> That shows you the build status
<wind-rider> ScottK: and there is stated that the i386 build succeeded, but when trying to upgrade apt-get did not find the new package
<ScottK> Accepted means it's built, but not in the archive.
<ScottK> The archive publisher run starts at :03 each hour and finishes ~:45.
<wind-rider> ok, that clarifies it :) thx
<ScottK> So it should be available in about 45 minutes.
<ScottK> That assumes you pull from archive.ubuntu.com directly.
<ScottK> If you pull from a mirror, then there's additional delay.
<sistpoty> tjaalton, tseliot: aware of the build failure for mesa?
<sistpoty> if so, and you need some help, feel free to ping me
<jcristau> yay hacks for closed drivers.
<sistpoty> jcristau: then make my ati card work with gl :P
<sistpoty> (just kidding, have seen the diff between ubuntu taking the snapshot from svn and debian... didn't find a trivial patch for the texture problem)
<tjaalton> sistpoty, ScottK: sorry, I'm on my phone now, so can't help until tomorrow. if you can come up with a fix, feel free to upload.. :/
<sistpoty> tjaalton: ok, will try
<sistpoty> tjaalton: I'm not too sure if my mesa patch will fix the build failure, but if it does, pretty please clean it up, it's the ugliest patch I ever did for ubuntu, and I'm extremely ashamed of it (just overriding LD_LIBRARY_PATH in debian/rules in a completely nonsense manner)
<sistpoty> oh, no it bails out somewhere else, yuck
 * albert23 just finished a mesa build successfully
<albert23> dh_shlibdeps -s -l/usr/lib/mesa did the trick
<jcristau> albert23: yep, that sounds like it should work
<sistpoty> albert23: I got errors for the r200 driver somewhere (but thanks for the trick, much better than the evil hack I've got)
<sistpoty> radeon_common_context.h:405: error: array type has incomplete element type
<sistpoty> albert23: I'm actuallly inclined to just upload your fix. test-building seems underrated for mesa, I guess
<albert23> That radeon error was fatal for you?
<sistpoty> yes
<albert23> I didn't get that
<sistpoty> (amd64)
<jcristau> old libdrm?
<albert23> so am I
<sistpoty> hm, german mirror problem? (which is not a mirror problem, but a lack of constraints on b-d's)
<jcristau> new mesa should probably build-dep on libdrm-dev >= 2.4.17
<albert23> I have 2.4.17 in the pbuilder
<sistpoty> 2.4.17-0ubuntu1 for libdrm2
<sistpoty> same for libdrm-dev
<sistpoty> interesting, I believe it builds further now... mesa is getting more and more obscure to me :)
<albert23> I have r200 and r300_dri.so in -dri, so the build went ok here
<sistpoty> I'll just wait and see what happnes ;)
<sistpoty> no, still the same error :(
 * sistpoty updates pbuilder (again)
<albert23> given the buildd reached the install target in the previous build, we can assume that error will not happen on the buildd?
<sistpoty> albert23: are you suggesting to just upload the fix from you? (though it still doesn't build for me)?
<albert23> sistpoty: that's up to you. But I think it means the radeon failure is something local for you
<sistpoty> albert23: I doubt it's local but a bug somewhere (however not trivial to investigate)... 
<sistpoty> slangasek: ok with replacing a broken version with a probably broken version?
<sistpoty> albert23: I think I'll just upload it as is, hoping that tjaalton will fix it up tomorrow if it breaks.
<sistpoty> albert23: as the change is really from you, currently I've put "* debian/rules: Fix dh_shlibdeps as proposed by albert32 to fix FTBFS." into changelog
<sistpoty> albert23: anything you'd like to see changed there?
<albert23> sistpoty: my name is Albert Damen, maybe better then an irc nick
<sistpoty> albert23: ok, thanks, couldn't figure this on first glance
<sistpoty> albert23: just uploaded, thanks againg... let's just cross fingers!
 * sistpoty feels dirty though
<albert23> We will know in an hour
<albert23> Armel failed in the same way, so I have some hopes
<sistpoty> hm... mesa should be accepted at least now, very strange
<sistpoty> albert23: case solved, I fetched an outdated source
#ubuntu-x 2010-01-10
<afv> hi
<afv> RAOF, i'm having no problem with nouveau-kernel-source, this time
<afv> but i still do have that font issue
<afv> and by the way, did anyone tried to compile mesa today?
<afv> i'm getting a "nv20_context.c:326: error: âNV20TCL_FOG_MODE_EXP_SIGNEDâ undeclared (first use in this function)"
<RAOF> Hm.  I'd guess that nouveau's been messing with the #defines again.
<RAOF> That'd require a new libdrm, probably.
<afv> (nv20_context.c: In function ânv20_init_hwctxâ)
<afv> hmm ok
<RAOF> afv: Possibly it's time to bounce it up to nouveau's bugtracker?
<afv> do you have a link at hand?
<RAOF> https://bugs.freedesktop.org/
<afv> thanks
<afv> http://bugs.freedesktop.org/show_bug.cgi?id=25974
<ubottu> Freedesktop bug 25974 in Driver/nouveau "Mesa won't compile. Undeclared constants at nv20_context.c." [Normal,New]
<afv> i hope the information provided is enough
<Sarvatt> afv you need an updated libdrm..
<Sarvatt> dont have time to update it right now on edgers, will try to get it up in the morning
<afv> so.. should i close the bug?
<RAOF> afv: Whoops.  I meant bounce the font issue bug up to the nouveau bugtracker :/
<afv> RAOF, ah. ok then
<afv> marked the bug as invalid..
<afv> lol. sorry
<Sarvatt> can you compile your own libdrm from the debian package?
<afv> i can try
<Sarvatt> actually, that commit is self contained, i'll just throw it in as a patch for now and upload it real quick
<afv> thanks
<Sarvatt> lucid right?
<Sarvatt> (dont want to bother with whatever you arent using because i'll just do a git update tomorrow)
<afv> right
<Sarvatt> uploaded
<afv> to the ppa?
<Sarvatt> yeah
<afv> ok. many thanks :)
<Sarvatt> just added http://cgit.freedesktop.org/mesa/drm/patch/?id=5963c023b84daaacb91ae0aa4cf841acff63fd1f
<sistpoty> finallly, fixed mesa uploaded, thanks againg albert23
<sistpoty> !
<afv> Sarvatt, thanks. mesa compiled fine :)
<afv> but this is what happens when trying to run compiz: http://dl.dropbox.com/u/659315/screenshots/compiz_20100110.png
<afv> and i have a "nv40_screen_get_param:56 -  Unknown PIPE_CAP 31" when trying glxgears or compiz
<ScottK> mesa's got further than it did before on i386 ....
<RAOF> afv: Yeah, everyone gets that warning; it doesn't stop compiz from working for me.
<afv> okay
<ScottK> Congratulations albert23.  Thanks for making mesa build.
<afv> RAOF, how many frames do you get running glxgears?
<afv> i'm getting around 490 using gallium and around 700 without it. but.. iirc, not sure, i was getting like 6000 using nvidia blob..
<bjsnider> what memory manager is the nouveau blob using?
<bjsnider> i should sayd hte nouveau driver
<RAOF> bjsnider: ttm.
<RAOF> afv: Something in the order of 500ish, I think.  It's not a good benchmark.
<bjsnider> it uses a pure ttm?
<bjsnider> not a gem-ified ttm?
<bjsnider> i didn't knpow ttm had gone into the kernel
<RAOF> It has; I'm pretty sure it was in 2.6.32, and probably earlier.
<RAOF> radeon has been using it for a while.
<RAOF> Because gem doesn't really cover âmy graphics card has onboard memoryâ :)
<bjsnider> radeon uses a comination of gem and ttm
<RAOF> Yes; as does nouveau.
<ScottK> tjaalton: mesa's not there yet: https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135/+files/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz
<bjsnider> gem doesn't understand dedicated vram, only shared?
<ScottK> That's with the new one too.
<ScottK> Get:5 http://ftpmaster.internal lucid/main libglu1-mesa-dev 7.7-0ubuntu3 [211kB]
<afv> ok, thanks RAOF
<Sarvatt> theres a dangling symlink left behind in /usr/lib now
<Sarvatt> lrwxrwxrwx 1 root root     10 2010-01-08 23:06 /usr/lib/libGL.so -> libGL.so.1
<Sarvatt> ah i see why
<ScottK> Why?
<Sarvatt> well i see a problem maybe, kdebase-workspace is using libglu1-mesa-dev, glu.pc is pointing to /usr/lib but the libglu1-mesa-dev package installs it to /usr/lib/mesa/ 
<Sarvatt> oh bah nevermind
<Sarvatt> libdir=/usr/lib/mesa
<Sarvatt> working on 2 machines with different mesa versions on them because one isnt seeing the update
<ScottK> Fun
<ScottK> Sarvatt: If you can figure out something that doesn't look too crazy, I can upload it.
<tjaalton> ScottK: oh bugger
<tjaalton> I think it should be libgl1-mesa-glx that ships the GL.conf and not the xserver..
<jcristau> that would mean the server has to depend on libgl1-mesa-glx
<jcristau> which is better than the other way around, but still
<tjaalton> fck
<jcristau> this whole thing is screwed up
<tjaalton> you don't say :)
<tjaalton> I like how the stuff is named; /etc/ld.so.conf/GL.conf -> /etc/alternatives/gl_conf -> /usr/lib/standard-x11/ld.so.conf
<tjaalton> somehow I don't want to do anything until tseliot shows up
<tjaalton> s/want to/feel like/
<tjaalton> s/do/doing/
<jcristau> :)
<tjaalton> just moving that conf will be messy
<albert23> can't xserver-xorg-core and libgl1-mesa-glx both provide an alternative for GL.conf?
<tjaalton> why?
<albert23> to prevent the new dependency
<tjaalton> it just lists /usr/lib/mesa, so why should they both do the same
<jcristau> they'd provide dangling symlinks?
<albert23> They can both setup a full alternative for GL.conf?
<tjaalton> I think the ugliness factor has been fulfilled already :)
<jcristau> albert23: the alternative has symlinks to libglx.so and libdri.so as slaves
<albert23> Ah, I see
<albert23> yay: kdebase-workspace-bin_4.3.90-0ubuntu1albert1_amd64.deb built with new mesa
<albert23> that took 2 changes
<albert23> First I added xserver-xorg-core as build-dependency, to get GL.conf installed (would be covered by the change suggested by Tjaalton)
<albert23> Then I had to add export CMAKE_LIBRARY_PATH=/usr/lib/mesa in debian/rules
<albert23> Without that, I got -- Looking for glXChooseVisual in GL - not found
<albert23> and part of the package was not buit, resulting in a dh_install error
<jcristau> changing every GL client to use -L/usr/lib/mesa is not a reasonable
<jcristau> option
<jcristau> moving libGL.so back to /usr/lib would be better imo
<albert23> jcristau: unless there is a way to tell cmake to use pkg-config
<albert23> pkg-config in the build showed the right -L option, but it was not used
<jcristau> no, not unless
<jcristau> not all GL clients use cmake, and not all GL clients are packaged by ubuntu.  that would be asking everyone to change their software because ubuntu decided to break stuff
<jcristau> making 'gcc -lGL foo.c -o foo' not work out of the box is stupid imo
 * ScottK agrees with jcristau
<wind-rider> ScottK: when will it be safe to upgrade mesa? it is available as an update now
<ScottK> wind-rider: The update doesn't fix the problem.
<wind-rider> ScottK: I updated, and now my x-server won't start
<wind-rider> only afterwards i saw the note that it was better not to upgrade
<ScottK> wind-rider: I've no idea.  I'm waiting with you for a proper solution.
<wind-rider> ok
<wind-rider> should i file a bug?
<sebner> wind-rider: I'm sure tseliot is aware of it
<wind-rider> all right
 * sebner has a working Xserver with newest mesa though. The first boot resulted in a segfaulting Xserver indeed
<JontheEchidna> there's bug 505359 already filed anyways
<ubottu> Launchpad bug 505359 in mesa "libgl1-mesa-dev installs a broken link in /usr/lib" [Undecided,New] https://launchpad.net/bugs/505359
<wind-rider> sebner: so i should try to reboot?
<sebner> wind-rider: dunno, as I said /here it didn't work the first boot and no problems since then
<wind-rider> i'll try :)
<wind-rider> see you later
<wind-rider> sebner: you were right, rebooting helped, so i don't need my Live-usbstick anymore :) thx for the hint
<sebner> wind-rider: heh, the windows-way of life 
<wind-rider> sebner: looks like that indeed :P
<hyperair> windows-way?
<woozy_> "reboot until it works"
<wind-rider> i must go
<wind-rider> bye
<sebner> hola hyperair :)
<hyperair> hola sebner =)
<sebner> hyperair: are you already on the agenda for the meeting (speaking about your applications)?
<hyperair> not yet
<hyperair> i'm still thinking which meeting i should choose
<hyperair> one of them will occur at 3am on a friday morning
<sebner> hyperair: heh, so you are ready for the weekend then :P
<hyperair> that'll be the meeting after the next
<hyperair> sebner: so i still have time to think which one i feel like going for =p
<hyperair> sebner: and also to reap more endorsements
<hyperair> =D
<sebner> hyperair: heh, you should mention your interest in non cli packages/sponsoring too though
<hyperair> sebner: didn't i?
<sebner> hyperair: ah right, :) just not good to only have on area standing above all
<jcristau> really?
<sebner> jcristau: depends but in most cases not
<sebner> hyperair: speaking of, where is banshee 1.5.2 ;P
<sebner> hyperair: stopped by transition I suppose?
<hyperair> sebner: yes, that it is.
<sebner> kk
<hyperair> sebner: also, i think you focused too much on the bulleted list of PPAs.
<ripps> Does anybody have any clue how the xf86-input-wacom driver for lucid is coming?
<jcristau> by train
<sebner> hyperair: yeah right
<sebner> hyperair: It's also my personal experience with you though :)
<hyperair> =p
<hyperair> right
<ripps> I believe the new udev xf86-input-wacom driver was released in debian just the other day. So how long until it gets in Ubuntu?
<ripps> Okay, I just pulled the xf86-input-wacom source package from debian and built it with pbuilder. It seems to fix my immediate problems I had with my tablet, unfortunetly, it seem the xsetwacom utility doesn't really work. The names it lists for the stylus/eraser/cursor devices don't actually work when you try to set them.
<ripps> Oh, okay, I figured it out. I has to have the quotes in the actual name sting. Kinda dumb
<jcristau> ripps: blame udev :)
<ripps> Can't it just remove the quotes? What do I have to have the devices called '"Wacom Graphire3"'? Notice the two sets of quotation?
<jcristau> because X gets the device name from udev, and there are quotes
<ripps> hmm... it seems that KeepShape doesn't work anymore, good thing I kept an old script with some manual BottomX BottomY to accomplish the same thing with my screen
<ripps> Huh, TPCButton value is inverted. It's on when I set it to off... now that's a bug
<ripps> Where do I file bugs? or should I wait until it gets into Ubuntu?
<wind-rider> ripps: if you know the package, run: ubuntu-bug <packagename>
<wind-rider> ripps: else, go to bugs.launchpad.net
<al> https://help.ubuntu.com/community/RadeonDriver#Tweaking%20The%20Driver could use a review maybe
<al> i just edited to reflect the default AccelMode change from XAA to EXA, which had a severe negative performance impact on my R350 card
<al> don't know about the other options though
<tjaalton> maybe a time to fix the mesa mess, if only my DNS worked
<tjaalton> still broken, I'll leave mesa for tomorrow..
<bjsnider> there is no fix is there?
#ubuntu-x 2011-01-03
<cnd> bryceh, Sarvatt, what's the status of the latest xorg-server upload?
<bryceh> cnd, heya
<cnd> bryceh, hey, happy new year btw
<bryceh> cnd, there were some various last minute additions to it, which is what we had been worried about
<cnd> ahh
<bryceh> I looked through the patches for several of those things and wasn't too put off, but I'd like to hear opinions from RAOF and Sarvatt first
<cnd> bryceh, do you know what happened with the upload? pitti noted that there was a huge debdiff that seemed wrong
<bryceh> oh, you must be referring to something else
<bryceh> sorry thought you were asking about the new xserver release
<bryceh> cnd, link me?
<cnd> ahh, no, I mean the maverick xserver update
<cnd> one sec on the link
<cnd> bryceh, sorry for the delay: https://bugs.launchpad.net/bugs/670016
<ubot4`> Launchpad bug 670016 in xserver-xorg-input-evdev (Ubuntu Maverick) (and 3 other projects) "Xorg crashes when performing gesture (affects: 1) (heat: 71)" [Undecided,New]
<cnd> at the end of the comments you'll see pitti note the debdiff issues
<cnd> it's entirely possible that I'm the one at fault since I updated the git repo :)
<cnd> I was just wondering if you knew what might have happened
<bryceh> ok looking
<jcristau> looks like it was built from a dirty tree
<bryceh> jcristau, yeah, I found the dirty tree it was built from
<cnd> bryceh, I hope that tree isn't a clean clone from git.debian.org :)
<bryceh> not sure what it was from.  blaming my git skilllessness for now
<bryceh> cnd, reuploaded
<Sarvatt> every time I start getting ready to put xserver 1.10 into the PPA -- <keithp> aaronp: I've got some RandR 1.4 proto changes to propose...
<Sarvatt> got mesa fixed up to use the natty packaging though, will push that in there in tomorrow's update
<bryceh> Sarvatt, heh
<cnd> bryceh, thanks!
<cnd> Sarvatt, did keithp acquiesce?
<Sarvatt> aaronp asked if the abi was frozen to update the nvidia blob and they said nope
<cnd> grr
<cnd> oh, actually, I read that backwards
<cnd> I see that keithp was saying there's changes to be made still
<Sarvatt> bryceh: hmm so we need some way to get the dmesg from the actual crash not after the reboot..
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/694244 looks the same as https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/686388
<ubot4`> Launchpad bug 694244 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup (EIR: 0x00000010) - Invalid GTT entry during Display B Fetch (affects: 1) (heat: 6)" [Medium,Incomplete]
<Sarvatt> that ickle commented on https://bugs.freedesktop.org//show_bug.cgi?id=32396
<ubot4`> Freedesktop bug 32396 in Driver/intel "[i965gm] GPU lockup - Invalid GTT entry during Display B Fetch" [Normal,New]
<Sarvatt> too bad /var/log/dmesg stops after boot is done
<bryceh> Sarvatt, yeah
<Sarvatt> /var/log/kern.log?
<bryceh> Sarvatt, are you sure they're the same?  the gpu dumps look different to me
<bryceh> one seems to involve a bunch of 3D calls, the other doesn't
<Sarvatt> bryceh: they're from the same person and have the same EIR/PGTBL_ERR/INSTDONE, yeah I'm positive
<bryceh> ah, didn't notice it was the same guy
<Sarvatt> compiz was probably doing something at the time of one of the crashes and not the other
<Sarvatt> me neither or I woulda duped it earlier :)
<Sarvatt> 5 bugs, woohoo
<bryceh> for bug #692677 I'm thinking of just dropping the patch... would prefer to actually solve it, but it's not clear looking at the patch what could be wrong with it
<ubot4`> Launchpad bug 692677 in nvidia-settings (Ubuntu) (and 1 other project) "Desktop login to unity leads to hang and compiz crash when X Server Display Confirmation is clicked on (affects: 1) (heat: 394)" [High,Triaged] https://launchpad.net/bugs/692677
<bryceh> lunch first tho... bbiab
<bryceh> Sarvatt, I was thinking next week if we have time it might be useful to do a group walk-thru of all the X bugs marked high priority, and get some movement on them.
<Sarvatt> bryceh: sounds good to me, platform services has a packed schedule and I'm not sure when will be good but will see then
<bryceh> wonder if alberto will be there
<Sarvatt> oh it's nowhere near as packed as I thought https://wiki.canonical.com/PlatformServices/DallasSprint2011
<bryceh> oh good
<bryceh> yeah typically sprints are not nearly so booked, like uds's, but some teams do more structured stuff than others
<bryceh> maybe we could do 1 hr each morning following plenary
<Sarvatt> ohh RAOF is already in texas!
<bryceh> really?
<bryceh> I can't keep track of that boy
<bryceh> vacationing?
<Sarvatt> yeah week vacation before the sprint the wiki says
<bryceh> 694289 and 694381... more of our favorite bug
<bryceh> Sarvatt, have you ever gotten an -nvidia install on a usb key to work?
<Sarvatt> back in karmic/early lucid, didn't try again for a long time there
<marjo> Sarvatt: FYI, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693093
<ubot4`> Launchpad bug 693093 in linux (Ubuntu) (and 1 other project) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 8) (heat: 337)" [High,Confirmed]
<marjo> Sarvatt: thx for your help again
<bryceh> hmm, wonder what changed
<Sarvatt> that really should be an alpha 2 targetted bug but not comfortable adjusting the grub task since cjwatson is particular about those
<bryceh> last commenter on #685017 said he got it working with -nvidia .29
<Sarvatt> huh
<Sarvatt> oh
<Sarvatt> bryceh: i bet they installed from nvidia.com
<Sarvatt> and now that i think about it, when I did have it working I also installed from nvidia.com
<Sarvatt> back when that used to work in karmic/early lucid
<Sarvatt> there's no .29 in x-updates natty
<bryceh> interesting; how do you think that differs?
<Sarvatt> no dkms, no jockey, no update-initramfs
<Sarvatt> no gl
<bryceh> aha
<bryceh> yeah so that points back to not needing initrd updates
<Sarvatt> asked for logs to see whats up
<tormod> happy new year everyone! can anyone give bug 635362 some sponsor love?
<ubot4`> Launchpad bug 635362 in xserver-xorg-video-savage (Ubuntu) (and 1 other project) "Xorg assert failure: X: /usr/include/xorg/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. (affects: 14) (dups: 11) (heat: 138)" [Medium,Triaged] https://launchpad.net/bugs/635362
<bryceh> hiya tormod
<bryceh> tormod, on it
<tormod> bryceh, thanks!
<bryceh> tormod, looks good.  uploaded
<tormod> thanks again
<Sarvatt> http://semiaccurate.com/2011/01/02/sandy-bridge-biggest-disapointment-year/ -- someone should tell him to try any other distro livecd where he won't even get a 2D desktop :)
<bryceh> Sarvatt, hmm, someone should send me one of those sandybridge machines
#ubuntu-x 2011-01-04
<bryceh> Sarvatt, I totally don't mind putting an ati card in it and having a screaming fast non-intel graphics system ;-)
<bryceh> "The only people who care about Linux are elitist neckbeards who intentionally want to make things harder then they need to be."
<bryceh> neckbeards?
<bjsnider> bryceh, it looks like he tried maverick. maybe the problem is the kernel isn't new enough
<bryceh> bjsnider, 3rd paragraph of http://www.phoronix.com/scan.php?page=news_item&px=ODk3MA itemizes what all is needed
<bjsnider> but as charlie points out "...none were available short of building from source on our own. We do not feel this meets any reasonable standard for 'available'."
<bryceh> 5th paragraph addresses that
<bjsnider> yeah but that paragraph is simply saying "it's too hard" which is charlie's point.
<bryceh> bjsnider, you don't think it's too hard?
<bjsnider> that's an understatement. it's more than too hard
<bjsnider> but charlie's saying if it's too hard then drivers cannot be said to be "available"
<bryceh> ah
<bryceh> heh, well that's Intel for you
<bryceh> I'd share that rant...  I hate that they never backport fixes or hardware enablement, so it's a constant game of having to upgrade to latest kernel+libdrm+mesa+-intel+etc. or do messy backporting ourselves and then get accused of shipping frankenkernels or whatnot
<bryceh> -ati is sooo much better about all of this
<bjsnider> i wouldn't know about that
<bjsnider> i'd say nvidia is so much better though
<bryceh> even the proprietary drivers do a good job about being reasonably self-contained, although obviously the binary incompatibilities kill us here and there
<bjsnider> it's so easy to build the blob even i can do it
<bryceh> yep
<bjsnider> charlie wouldn't have an argument if all he was being asked to do was install the latest nvidia driver. but if that was the case he wouldn't be complaining
<bryceh> yeah.  hope it gets some attention to the issue
<bryceh> P67:  http://www.amazon.com/Gigabyte-GA-P67A-UD7-Intel-P67-Atx/dp/B004G60AKO/ref=sr_1_1?ie=UTF8&s=electronics&qid=1294107053&sr=8-1
<bryceh> Sarvatt, what if we had it collect dmesg.0 and dmesg.1.gz from /var/log?
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg - down to 3 bugs again :-)
<bryceh> Sarvatt, in the -ati package in edgers I see you disabled 101_select_between_classic_and_gallium_dri.patch - is that just because of a failure to patch or was there some other problem?
<Sarvatt> bryceh: because it was using an older mesa base that didn't have the right dri driver names to work with that
<Sarvatt> just fixed that with this mornings updates, thats what I meant about a mesa packaging update yesterday
<dbarth> hiya
<dbarth> i'm trying to get a nice backtrace for a dri/r300 issue
<dbarth> i can't figure out which are the right debug packages to add
<dbarth> previously i had libgl1-mesa-dri-dbg but that didn't contain the right symbols (ie no line numbers)
<dbarth> and now i have libgl1-mesa-dri-dbgsym and that doesn't work either
<dbarth> any idea?
<Sarvatt> pastebin your incomplete backtrace? it'll still list the libs you need dbg packages for
<dbarth> ah cool
<dbarth> Sarvatt: it's here:
<dbarth> http://pastebin.ubuntu.com/544957/
<dbarth> i guess bryceh was mostly interested in r300_dri.so and libGL
<dbarth> referring to https://bugs.launchpad.net/unity/+bug/691653
<ubot4`> Launchpad bug 691653 in mesa (Ubuntu) (and 2 other projects) "compiz crashes when using alt-tab (the radeon driver kills it) (affects: 1) (heat: 6)" [Undecided,Incomplete]
<cnd> bryceh, we're trying to plan xi 2.1 landing and development and it's getting more important for us to know when 1.10 will land in natty
<cnd> do you know when that will be?
<cnd> pre-alpha2?
<Sarvatt> dbarth: i'm pretty sure that was fixed on mesa 7.9 branch already, i'm in the middle of another bug at the moment but will look asap
<dbarth> Sarvatt: thanks; let me know as a bug comment maybe if i'm gone later
<bryceh> heya dbarth
<bryceh> cnd, hard to predict xorg's release schedule accurately, but I anticipate we'll get the rc candidate in within the next two weeks
<bryceh> cnd, unless for some reason raof feels we should stick with 1.9.  I anticipate that decision to be made firm next Monday.
<cnd> bryceh, so that's before alpha 2?
<bryceh> cnd, right, alpha 2 is end of feb iirc
<cnd> bryceh, alpha 2 is beginning of feb
<bryceh> cnd, ah, ok anyway I anticipate we'll have it in by end of this month at the absolute latest
<cnd> ok, cool
<cnd> bryceh, who will be doing the patch merge for xorg-server?
<cnd> it sounds like we may want to leave the maverick gesture patches in until alpha 2, and then drop them and pull in xi 2.1 right after alpha 2
<bryceh> cnd, I'm assuming RAOF will since he likes doing that sort of thing
<cnd> heh
<bryceh> but really I think any of us could do it
<cnd> bryceh, ok, once the decision is made on the server version I'll try to sync with RAOF about this
<cnd> thanks!
<bryceh> cnd,  no prob
<bryceh> btw, sounds like RAOF is on vacation this week
<cnd> ahh, good to know :)
<LLStarks> bryceh, any plans for improving legacy intel for natty?
<LLStarks> or still vesa hell?
<bryceh> LLStarks, you mean 8xx?  think we've mostly written it off since it seems to be a moneypit of time
<LLStarks> no shadowfb or whatever was in the pipeline?
<LLStarks> i thought there was a decent solution that barely missed the cut-off window
<LLStarks> unrelated question. is i915 gallium still dead?
<bryceh> far as I know
<bryceh> the intel guys haven't been very favorable towards gallium generally
<Sarvatt> bryceh: btw check #intel-gfx :)
<Sarvatt> thats some timing
<Sarvatt> it looks like fedora 14 is hitting the same r300g problem dbarth is having in bug #691653, https://bugzilla.redhat.com/attachment.cgi?id=464327
<ubot4`> Launchpad bug 691653 in mesa (Ubuntu) (and 2 other projects) "compiz crashes when using alt-tab (the radeon driver kills it) (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/691653
<Sarvatt> better backtrace there, thats from compiz 0.8.6
<bryceh> magic registers for 8xx eh?
<bryceh> Sarvatt, how'd you find that?  What's the bug # to go with that backtrace?
<bjsnider> Sarvatt, do you know if randr support is coming to the blob in natty?
<Sarvatt> googled radeon_r300_winsys_buffer_from_handle, ton of compiz crashes in red hat bugzilla
<bryceh> Sarvatt, ahh
<Sarvatt> none have any useful info in them, just a bunch of reports. i thought i saw something about that crash on 7.9 branch but cant find it if i did
<Sarvatt> bjsnider: doubt it very much but dont know for sure
<bryceh> Sarvatt, ok
<bryceh> if one of the reports looks at all active, might be worth linking to ours
<Sarvatt> none do :(
<bryceh> Sarvatt, oh I see the problem
<bryceh> #0  radeon_r300_winsys_buffer_from_handle (rws=<value optimized out>, whandle=0x7fffe69964b0, stride=0x7fffe69963f4, size=0x7fffe69963f0) at radeon_r300.c:123
<bryceh>         ws = <value optimized out>
<bryceh>         _buf = 0x0
<Sarvatt> https://bugzilla.redhat.com/show_bug.cgi?id=656755 is the best one
<ubot4`> bugzilla.redhat.com bug 656755 in compiz "[abrt] compiz-0.8.6-3.fc14: Process /usr/bin/compiz was killed by signal 11 (SIGSEGV)" [Medium,New]
 * Sarvatt nods
<bryceh>     if (size)
<bryceh>         *size = _buf->base.size;
<bryceh> simple null pointer deref
<Sarvatt> bryceh: ok if i do a bit of tinkering in the wayland ppa?
<Sarvatt> now that mesa in edgers is using natty packaging it can just be copied in there
<Sarvatt> all the fixing you did seems to be in stuff specific to the old packaging where i had extra crap enabled
<bryceh> Sarvatt, sure feel free
<Sarvatt> might as well add wayland to edgers too I guess, its only 2 packages
<Sarvatt> well 3 with cairo, need to figure out whats going on with alf's no glew stuff that went in upstream cairo recently
<bryceh> yeah would love to see it pulled into xorg-edgers
<bryceh> yeah the cairo bits are proving to be the main irritation.  Keeps changing versions and I have to update stuff  8-P
<bryceh> oh btw I don't have the .so files packaged right for the libs.  Maybe you have more packaging-fu than me on how to install the .so.0.0.0 files?
<Sarvatt> _alf probably backported it all to cairo 1.10 branch for linaro
<Sarvatt> what libs?
<bryceh> libxkbcommon
<bryceh> and libwayland
<bryceh> I think it just needs a symlink installed
<bryceh> also I see these errors, which I've not sorted out yet but are on the todo list:
<bryceh> E: wayland: no-shlibs-control-file usr/lib/libwayland-server.so.0.0.0
<bryceh> E: wayland: no-shlibs-control-file usr/lib/libwayland-client.so.0.0.0
<bryceh> E: wayland: postinst-must-call-ldconfig usr/lib/libwayland-server.so.0.0.0
<bryceh> W: wayland: package-name-doesnt-match-sonames libwayland-client0 libwayland-server0
<bryceh> E: wayland: missing-dependency-on-libc needed by ./usr/bin/wayland-compositor and 2 others
<Sarvatt> whoa, its in the natty archives!?
<jcristau> shared libs need to be in their own package
<bryceh> libxkbcommon is, yeah... I uploaded it there a month or two ago
<bryceh> jcristau, ah
<bryceh> jcristau, I knew you'd know ;-)
<jcristau> so one package for libwayland-client.so.0, one for libwayland-server.so.0, and one for the compositor.  at least.
<jcristau> you need that so you can change the package name when the soname changes
<bryceh> ok
<Sarvatt> bryceh: https://launchpad.net/~afrantzis/+archive/cairo-gl
<Sarvatt> alf__ rocks :)
 * Sarvatt always gets his nick wrong since he doesn't hang out here much
<bryceh> Sarvatt, hmm, looks strikingly similar to my cairo-gl package
<bryceh> ooh, hide_glew_symbols.patch looks interesting
<Sarvatt> yeah thats what i was pointing out, sorry
<Sarvatt> he went one better and completely ripped glew out of cairo completely in git
<Sarvatt> just noticed i'm from camaroon now, sweet! http://cgit.freedesktop.org/cairo/commit/?id=7a023a62f7517ad0d54f4d59c99909fadcc05e82
<Sarvatt> so mesa 7.10 is for sure releasing on friday
<bryceh> camaroon?
<Sarvatt> gmail.cm :)
<bryceh> ah
<Sarvatt> got native ubuntu up on a tegra tablet I got last week, looks like I need to bring xserver 1.6 to natty for it since thats the only video abi nvidia supports with tegra :)
<Sarvatt> arm ppas sure would be nice to have
<jcristau> lucky you.
<Sarvatt> i thought their video card blobs were bad, this tegra crap is in a world of its own
#ubuntu-x 2011-01-05
<ScottK> Sarvatt: I've got access to reasonably fast (for arm) hardware, so if you need something built, let me know.
<p3> hi
<p3> anyone around that could help me out with connecting a HP display via DisplayPort?
<p3> using nVidia's latest drivers on Quadro FX 580 graphics card.
<Sarvatt> Anyone around I could bug for xorg-server sponsoring? cjwatson is uploading console-setup with keyboard-config in it -- http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/xorg-server_1.9.0.902-1ubuntu2.debdiff  http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/
<jcristau> yay
<tseliot> Sarvatt:  do you know if we're using something that hides the mouse cursor when we type?
<Sarvatt> nope we ditched that
<Sarvatt> gnome-terminal does it though if thats where you're seeing it
<tseliot> Sarvatt: yes but it also seems to happen in pidgin
<Sarvatt> tseliot: do you have unclutter installed?
<tseliot> unclutter is not installed
<Sarvatt> oops
<tseliot> Sarvatt: the same happens if I open xterm
<tseliot> or gedit
<tseliot> and this is kind of getting in my way as I'm trying to hide the cursor permanently
<Sarvatt> gtk apps can do it afaik, I really dont know how they do it
<tseliot> I guess it's something you have to enable
<tseliot> in each single app
<jcristau> xterm does that too.
<bryceh> Sarvatt, still need anything sponsored?
<Sarvatt> bryceh: nope tseliot got it, thanks though!
<bryceh> excellent
<cnd> darn you Sarvatt!
<cnd> I'm trying to make a new xorg-server package and the keyboard-config change is fowling me up :)
<cnd> fouling even
<Sarvatt> doing it for maverick? sorry man, I hate making changes that screws up backporting like that, it screwed up edgers too :(
<cnd> Sarvatt, do you know when keyboard-configuration will be available?
<cnd> I'm trying to use the ubuntu branch on git.debian.org
<Sarvatt> https://launchpad.net/ubuntu/natty/+source/console-setup/1.57ubuntu1
<Sarvatt> in dep-wait for bdfresize, doh
<cnd> I'll use the ubuntu-maverick branch in the meantime
<cnd> thanks for the info!
<Sarvatt> ahh good call
<Sarvatt> didnt know we had one there for xserver, i was in the middle of making a hook to fix backporting to maverick
<cnd> urgh, the ubuntu-maverick branch still has the udev-product-ids patch
<cnd> Sarvatt, do you know if bdfresize is going to be built soon?
<cnd> maybe I'll just wait till it's done
<Sarvatt> bdfresize is in universe
<Sarvatt> haven't grabbed it to see how its used yet, not sure how thats going to be worked around
<cnd> oh, so it needs a MIR
<cnd> hmm... that doesn't seem to make sense
<cnd> do build deps of main packages have to be in main?
<cnd> I suppose so...
<Sarvatt> yeep :(
<cnd> hmm... what's the easiest way forward...
<cnd> I can make my own xserver packaging branch for now I suppose
<Sarvatt> #ubuntu-devel
<Sarvatt> cnd: it
<Sarvatt> err
<Sarvatt> if its in a ppa and ya cant wait a few hours grab the console-setup source, add ~foo to the version and upload it in the PPA if its for natty, build deps dont have to be in main in a ppa and it'll get overwritten by the fixed one
<Sarvatt> <cjwatson> I got it MIR-approved eons ago - I'll promote it shortly
<Sarvatt> <cjwatson> Sarvatt: ^-
<cnd> hmmm, that's one way forward I suppose
<cnd> or I can just use ubuntu-maverick and drop the udev ids patch :)
<cnd> it's all just for intermediate development
<bryceh> http://finance.yahoo.com/news/NVIDIA-Announces-Project-iw-377729072.html?x=0&.v=1
#ubuntu-x 2011-01-06
<mdeslaur> Is Intel Clarkdale blacklisted for compiz in maverick?
<marjo> apw, Sarvatt: happy new year
<marjo> apw, Sarvatt: please see cjwatson's comment on: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693093
<ubot4`> Launchpad bug 693093 in linux (Ubuntu) (and 1 other project) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 8) (heat: 50)" [High,Confirmed]
<apw> marjo, yep so things work with old grub and not new ... what graphics h/w is this?
<apw> marjo, this probabally means newer grub is leaving the display initiailised differnetly and the kernel is not coping
<marjo> apw: Intel 945GME Express Integrated Graphics Controller (rev 03)
<apw> marjo, as this is intel graphics we need to get an intel_reg_dumper output from both working and not working cases for comparison
<apw> preferably at the same spot, say at gdm just after the drums, remotely logging in to get it
<marjo> apw: please provide specific instructions
<apw> marjo, and as we have just released a new -12 kernel i recon you should test with that
<apw> as for instructions:
<apw> install intel-gpu-tools
<marjo> got it
<apw> run sudo intel_reg_dumper on the old grub and on the new grub
<apw> preferably at the same place
<marjo> apw: how do i do that with the old grub when i can't even get to any ttys?
<apw> marjo, i thought you could hear the drums
<apw> which means the machine is up, so you can login over the network
<marjo> apw: yes, so run it using ssh login, after the drum is heard, right?
<marjo> apw: will do
<apw> marjo, yes in both cases, working and not
<marjo> apw: ack
<apw> then the setup is the same in both cases, so any register differences are likely the problem
<apw> marjo, but do upgrade to -12 beforehand
<marjo> apw: ah yes
<marjo> apw: bad news
 * apw listens
<marjo> apw: with latest grub-1.99~20110104 and kernel-12, kernel-11, i don't even hear drums any more!
<marjo> apw: but i have intel_reg_dumper output for old grub & kernel-12 (which works)
<apw> marjo, ok so boot -11 on both
<marjo> apw: will do
<apw> or whatever kernel works on both
<apw> boots ok on both, not with working graphics obviously
<marjo> apw: ok, i've got two dump files, how do you want them?
<apw> marjo, on the bug please, label them appropriatly with kernel and grub versions in both
<marjo> apw: oh wait; i need to get you -11 and old grub, sorry
<marjo> apw ok attached two intel_reg_dumper outputs
<apw> marjo, will this machine be in dallas next week?
<marjo> apw: yes, it's my "travel netbook"
<apw> marjo, cool then we can look at it some more then
<apw> i think we need to get an intel_reg_dumper before X starts which is somewhat complex to descrive
<apw> marjo, is 1126 the first one which works going back, ie. have you tried the ones in between
<marjo> apw: 1126 was suggested by Sarvatt based on his analysis of when the breakage occurred
<marjo> apw, i.e. before Alpha-1 release, since I confirmed that the Alpha-1 worked, remember?
<apw> maxb, be handy to confirm exactly which version triggers this, the changes between the two grubs may help us understand
 * maxb *blinks*, pays attention
<apw> maxb, soz stupid xchat (or stupid apw)
<apw> marjo, ^^
<maxb> Heh. I have a i945 too :-)
<marjo> apw: what do you want me to look at?!
<apw> marjo, never mind we'll look next week
<marjo> apw: ok thx; i'll bring an extra netbook, for backup 
<apw> cool
<qoelqast> hi
<qoelqast> I got: error setting MTRR when trying to load X, there's only X installed. What does this mean/how to fix?
<bryceh> qoelqast, https://wiki.ubuntu.com/X/Glossary#What%20are%20%22MTRR%22s?
<qoelqast> bryceh:I read something on gentoo wiki, but is there a way to fix that?
<qoelqast> bryceh: cat /proc/mtrr gives outpu: base=0x000000000 (     0MB),size=     128MB, count=1:write-back etc
<qoelqast> Well, I guess the problem isn't X based? I'll try in default channel, thanks
#ubuntu-x 2011-01-07
<bryceh> Sarvatt, btw I noticed the workqueue graph was excluding unity bugs because they're technically already "filed upstream" and were being excluded erroneously.  This bloats up the graph a bit...  http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> I think we need a function in launchpad to differentiate between bugs reported at bugs.freedesktop.org and ones at any other arbitrary upstream
#ubuntu-x 2011-01-08
<dreewill> hi
<dreewill> i  have a question
<dreewill> i filed the bug 700282
<ubot4> Launchpad bug 700282 in xserver-xorg-video-intel (Ubuntu) "[i945gm] GPU lockup 585b0b66 (PGTBL_ER: 0x00000102) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/700282
<dreewill> and the bug occurs almost every time after startup. is it useful to add a report to the existing bug each time it occurs?
#ubuntu-x 2011-01-09
<alex_mayorga1> bryceh: you there?
<alex_mayorga1> bug 696104 here
<ubot4> Launchpad bug 696104 in xserver-xorg-video-nouveau (Ubuntu) "nvidia 320m locks up (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/696104
<alex_mayorga1> I have ssh to the laptop locked out right here, what can I gather?
<alex_mayorga1> no one?
<pcjc2> alex_mayorga1: Sorry - no idea for Nouveau
<pcjc2> Does the Nouveau driver expose anything under /sys/kernel/debug/dri/0 like the Intel one does?
<alex_mayorga1> pcjc2: I do se these on /sys/kernel/debug/dri/0
<alex_mayorga1> bufs     chipset  evict_vram  memory  queues         vbios.rom  vma
<alex_mayorga1> channel  clients  gem_names   name    ttm_page_pool  vm
<pcjc2> bufs, "gem_names" "ttm_page_pool", "vm" "might" be interesting
<pcjc2> pastebin if they are big?
<pcjc2> TBH, I don't know what I'm looking for though
<alex_mayorga1> anyway yo attach them to the bug report from a ssh console?
<pcjc2> not that my LP foo can manage, sorry
<alex_mayorga1> pcjc2: OK, thanks anyway
<pcjc2> you can email additions to bug reports
<pcjc2> but it has been a long time since I used a terminal based email client ;)
<pcjc2> Also, you can access launchpad through a terminal based web-browser, such as "w3m"
<tjaalton> just copy the contents locally, and attach to the bug later
 * pcjc2 missed that rather obvious suggestion ;)
<tjaalton> hehe :)
<pcjc2> Bryce about?
<tjaalton> it's sunday, so probably having quality time off work :)
<Amaranth> tjaalton: probably flying
<alex_mayorga1> pcjc2: there's also a /sys/kernel/debug/dri/64 folder shall I copy that one too?
<pcjc2> I don't think that is as useful
<pcjc2> tjaalton: quality time -> disallowed ;)
<alex_mayorga1> pcjc2: sorry on the slow response, had to go deal with real life :)
<pcjc2> I'm working on something too... _very_ slowly writing a robot for managing bugs using launchpad APi
<alex_mayorga1> pcjc2: sounds like fun
<alex_mayorga1> pcjc2: is that a public project
<pcjc2> bogged down in database design at the moment
<pcjc2> Not currently, but it can be. Nothing fancy mind.. just a hook to retrieve "Closes-bug: lp-12345" messages from git commits and make comments / status updates on bugs
<pcjc2> The tricky bit is that to ensure it works reliably (around LP downtime etc..), I need to have the git hook stuff work into a queue (a sqilte database), and then prod the robot - which will also be run periodically from a cron job
<pcjc2> The tricky bit is the DB design, and deciding just what to do for reverted commits, forced updates etc..
<alex_mayorga1> pcjc2: I see
<alex_mayorga1> OK I've copied the contents of both dri/0 and dri/64 anything else?
<alex_mayorga1> funny enough the lock up stays even when the laptop suspends itself and I resume it :)
<pcjc2> Not sure
<pcjc2> Something is waiting for something -> lock
<pcjc2> Do you have compiz running?
<alex_mayorga1> pcjc2: no as far as I know, anyway to tell from a console if compiz is going
<Amaranth> alex_mayorga1: pgrep compiz
#ubuntu-x 2012-01-03
<Prf_Jakob> Sarvatt, RAOF: Hey
<Prf_Jakob> Looks like we will do the branch/rc-release the comming Friday or Monday.
<ricotz> bryceh, hi :), happy new year
<ricotz> bryceh, do you mind doing a new snapshot of libxkbcommon?
<bryceh> ricotz, certainly, how soon is it needed?
<ricotz> bryceh, wayland-demos for xedgers depends on the latest change, so would be nice if you have some time soon
<bryceh> ricotz, ok thanks; it is on my todo list for doing near term.
<bryceh> I'm planning on working on updating the wayland packages in a few weeks, so would be good to have that dependency in place for that work.
<tjaalton> debian has a snapshot from last week
<tjaalton> though the version numbers are messed up, so it's older than ours
<bryceh> tjaalton, ok I'll check it out.  
<ricotz> tjaalton, oh, then it could be copied with a higher version
<ricotz> bryceh, thanks
<tjaalton> yeah it'll eventually hit 0.1.0 for real :)
<bryceh> tjaalton, do you mean debian has a newer wayland snapshot?  Looks like their libxkbcommon is still  at 0.1.0~0-1 in git?
<tjaalton> bryceh: right, wayland..
<tjaalton> maybe could ask kibi to update libxkbcommon too
<bryceh> mm, not a bad idea
<tjaalton> just asked on #d-x
<bryceh> tjaalton, thanks
<tjaalton> ah, only a handful of new commits to libxkbcommon
<tjaalton> ricotz: do you want it in precise?
<ricotz> tjaalton, libxcbcommon, yes
<ricotz> *libxkbcommon
<tjaalton> ok, uploaded
<bryceh> tjaalton, thanks
<ricotz> tjaalton, thanks!
<tjaalton> bryceh: went all the way :)
<tjaalton> i'll take the heat if the d-exp update is somehow b0rked :)
<tjaalton> haven't used pristine-tar much..
<bryceh> tjaalton, yeah wayland was the first time I encountered doing things that way.  I kinda liked it.
<tjaalton> bryceh: yep, certainly makes sense when doing snapshots
<RAOF> Prf_Jakob: Woot!
<Sarvatt> yeah perfect timing, we'll be locked away in conference rooms in budapest doing precisy things all next week
<Sarvatt> fun on mesa master: sarvatt@kyoko{~/.wine/drive_c/Program Files/Steam}:wine Steam.exe
<Sarvatt> err:module:load_builtin_dll failed to load .so lib for builtin L"OPENGL32.dll": /usr/lib/i386-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb
<Sarvatt> idr posted a patch to fix it at least, waiting for it to build to test it out
<Sarvatt> 1325622754-27575-1-git-send-email-idr@freedesktop.org
<RAOF> Sarvatt: Yeah, link against (a git snapshot of) libxcb-glx like a good boy. :)
<Sarvatt> i wonder if it even compiles yet, it hasn't in a few months or I was doing it wrong
<Sarvatt> months/over a year
<RAOF> libxcb-glx?
<Sarvatt> libxcb
<RAOF> I *presume* it builds; surely there's a piglit test for create_context_profile?
<Sarvatt> http://pastebin.com/ewWC6FNz
<Sarvatt> someone in #dri-devel hitting the exact same issue i did over a year ago
<Sarvatt> cant remember how i worked around it
<bryceh> I've got a blueprint task "Communicate with the release team that we don't put previous point releases where they can't be found"
<bryceh> iirc the problem is that the .1 and .2 releases at http://cdimage.ubuntu.com/releases/ are pointing instead at the .3 release
<bryceh> however, I don't remember why we felt this was an issue, in the context of X updates in the point releases.
<bryceh> anyone else remember what the problem was?
#ubuntu-x 2012-01-04
<RAOF> bryceh: We wanted the original X stack to be available on the CD.  The .3 point release will have Q's X stack on the CD.
<bryceh> RAOF, ah so the task isn't worded correctly
<RAOF> So, if someone has some hardware that doesn't work with Q's X stack, the .3 LiveCD will be useless for them, but they could install from .1 or .2, not pull in the Q stack, and happily use Precise for the full support period.
<bryceh> RAOF, since the P and Q stacks can co-exist in the archive, should they both be included in the .3 LiveCD?  
<bryceh> hmm, I suppose that may not help if the LiveCD doesn't boot to begin with
<RAOF> bryceh: Possibly; there are two obvious problems - (a) cd space, (b) how do you select which X stack?
<bryceh> (a) is probably irrelevant; (b) is a good point.  Presumably it'd need some sort of hook in grub or something.
<bryceh> RAOF, anyway ok thanks, I'll ping the archive guys
<Sarvatt> err, having all stacks coinstallable?
<bryceh> Sarvatt, ?
<Sarvatt> that sounds a bit scary, i was going under the assumption one would replace the other, namespacing the actual binaries isn't gonna happen, alternatives for the whole stack sonds like a nightmare, not going to be able to do anything from grub if its not all coinstallable
<RAOF> Yeah, they're not going to be coinstallable.
<RAOF> But you'd be able to have them all on the CD, at the cost of a little bit of boot-time madness.
<RAOF> I do not suggest that we implement that madness, but it wouldn't be *too* hard.
<RAOF> It would just be utterly untested until we tried to roll out the .3 point release, which doesn't sound like the right time for boot time madness testing :)
<bryceh> well by hook in grub I meant more along the lines of a script that would do the X stack reinstall
<bryceh> but regarding binary package names, I had assumed we *would* need to rename them all.  Can two versions of a binary package exist in the archive with the same name?
<Sarvatt> so just an upstart script querying the dpkg database that adds 1 second to the boot time noone will accept? :P
<Sarvatt> package name differences are a pain in the ass but fine, i was saying renaming the actual binaries isn't going to happen
<Sarvatt> like /usr/lib/x86_64-linux-gnu/dri/i915_dri-q.so or whatever
<Sarvatt> too much stuff depends on exact names
<bryceh> ah right
<bryceh> yeah, agree that'd be too much insanity for too little gain; it's hopefully just a corner case where people will want the older point releases
<Sarvatt> it's already going to be a nightmare making sure the entire stack upgrades right, the breaks: in xserver really screw up apt and no clue why it happens
<Sarvatt> like if one package isn't available or installed outside of the archive (vbox providing an abi virtual package) it tries to remove a ton of X crap and install all the proprietary drivers
<Sarvatt> then we get bugs about inverted screens when booting with compiz after that happens because they are using nvidia libglx
<bryceh> that was an awesome bug
<Sarvatt> i still see that bug on the debian-x mailing lists all the time :(
<bryceh> USB boot sticks with persistence, yay!
<LetoThe2nd> howdy! today's xorg-edgers updates seem to break some things on my box in funny ways ... :)
<LetoThe2nd> first observation: running terminator after the update breaks with: You need to install the python bindings for gobject, gtk and pango to run Terminator.
<LetoThe2nd> second observation: running virtualbox fails with: VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb
<LetoThe2nd> what might be of interest here? configuration is triple head on 2x ati hd5450
<LetoThe2nd> re-installing the stuff out of the ppa didn't fix things... any ideas how to proceed? what might be the source, or where to poke for additional relevant details?
 * LetoThe2nd guesses the channel might be more alive durig US office times :/
<tjaalton> well don't run edgers if you don't know how to handle the downfall
<tjaalton> it's git snaphots from upstream code, anything can go wrong
<LetoThe2nd> tjaalton: i'm not complaining, just trying to report issues. i would do on launchpad if i knew the relevant package.
<tjaalton> report upstream
<ricotz> what is the issue?
<LetoThe2nd> ricotz: todays edgers updates broke things in a way that i don't understand yet.
<ricotz> mesa is currently quite broken
<LetoThe2nd> first observation: running terminator after the update breaks with: You need to install the python bindings for gobject, gtk and pango to run Terminator.
<LetoThe2nd> second observation: running virtualbox fails with: VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb
<tjaalton> don't expect virtualbox to work with unstable upstream code
<ricotz> yes that is known
<LetoThe2nd> tjaalton: until this morning it worked quite well.
<ricotz> this the mesa problem which hopefully resolves itself with the next update
<ricotz> LetoThe2nd, you can revert to the last snapshot and everything should be fine again
<LetoThe2nd> ricotz: have a link to relevant documentation, maybe?
<LetoThe2nd> ricotz: and then just stick with the installed version? or what do you suggest?
<ricotz> LetoThe2nd, you can install the old deb package which might be in your apt cache or you can get it from the ppa page
<LetoThe2nd> ricotz: ah ok, the manual way.
<ricotz> yes
<LetoThe2nd> ricotz: and then just deactivate the updates for now?
<ricotz> yeah, just dont update mesa the other things should be fine 
<LetoThe2nd> ricotz: will give it a try, thanks.
<LetoThe2nd> ricotz: if it's known, i guess nobody cares about reporting somewhere?
<ricotz> LetoThe2nd, this is probably reported already
<LetoThe2nd> ok
<ricotz> like https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/911611
<ubot4> Launchpad bug 911611 in mesa (Ubuntu) "ubuntuone-control-panel-gtk crashed with ImportError in /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py: /usr/lib/i386-linux-gnu/mesa/libGL.so.1: undefined symbol: xcb_glx_set_client_info_2arb (affects: 1) (dups: 1) (heat: 16)" [Undecided,Incomplete]
<ricotz> tjaalton, ^ this is using edgers ppa for sure
<tjaalton> ricotz: ok
<ricotz> Sarvatt, ^ more trouble than i expected ;)
<ricotz> tjaalton, http://sourceforge.net/projects/linuxwacom/files/xf86-input-wacom/ ;)
<tjaalton> ricotz: maybe together with xserver 1.11
<ricotz> tjaalton, you might want to put it in ubuntu-x-swat/x-staging
<tjaalton> yeah, why not
<ricotz> so it is ready for the pocket copy
<tjaalton> right
<LetoThe2nd> ricotz: manually downgrading seems to have fixed it, thanks.
<Sarvatt> LetoThe2nd: yeah I'm trying to get it fixed up but its still broken on mesa master and running into problems with the fix on the lists, will let ya know when its safe to upgrade again
<Sarvatt> looks like idr's latest fix is just broken on osmesa and swx11 mesa build targets, dri builds fine
<ricotz> Sarvatt, hi
<Sarvatt> ricotz: heya
<Sarvatt> v2: Move the AM_CONDIATION outside the case-statement so that it is
<Sarvatt> invoked even for non-GLX builds.  This prevents build failures with
<Sarvatt> osmesa, for example.
<Sarvatt> \o/
<ricotz> Sarvatt, why did you remove the libxcb-glx0-dev build-dep?
<Sarvatt> i did?
<ricotz> the last diff says so :\
<Sarvatt>  linux-libc-dev (>= 2.6.31) [linux-any],
<Sarvatt>  libxcb-glx0-dev,
<ricotz> https://launchpadlibrarian.net/89080372/mesa_7.12.0~git20120103.2ae591bd-0ubuntu0sarvatt4_7.12.0~git20120104.892a2542-0ubuntu0sarvatt.diff.gz
<Sarvatt> it's there in the local checkout i uploaded..
<ricotz> Sarvatt, it isnt in 7.12.0~git20120104.892a2542-0ubuntu0sarvatt 
<ricotz> Sarvatt, havent built it here, just noticed this change
<Sarvatt> ricotz: well its fixed up locally, sorry about that, idr posted a fixed patch to make it build 5 minutes ago so i'll reupload
<ricotz> Sarvatt, nice, thanks
<ricotz> Sarvatt, remember to push the packaging changes ;)
<Sarvatt> yeah yeah
<Sarvatt> i dont have any packaging changes thats why i didnt push
<ricotz> i had a look at some drivers which failed on 1.12
<Sarvatt> doing it by hand
<ricotz> Sarvatt, oh, ok
<ricotz> and you can add sis and cirrus to your script
<Sarvatt> they arent there on purpose, mga too
<Sarvatt> but yeah they can be added back in now
<ricotz> this mean video-all and input-all working on 1.12 ;)
<ricotz> Sarvatt, https://launchpad.net/~ricotz/+archive/unstable/+packages
<Sarvatt> sis cirrus and vmwgfx weren't building against 1.11 at one point
<ricotz> they built fine
<ricotz> oh, vmwgfx i dont even have there
<Sarvatt> cirrus is in there, was just sis missing
<ricotz> openchrome got fixed too
<ricotz> v4l havent seen any fix
<ricotz> ark still used this obsolete/removed symbol
<ricotz> xf86MapDomainMemory
<tormod> hi guys :)
<Sarvatt> heya tormod!!
<Sarvatt> ricotz: yay fixed mesa uploaded now, it actually builds
<Sarvatt> now to fix those hooks..
<ricotz> Sarvatt, good ;), hopefully it works too
<ricotz> even gnome-shell wouldnt built :\
 * tormod is waiting impatiently for xserver 1.12 :)
<ricotz> tormod, you can try it if you want ;)
<tormod> ricotz, from your unstable ppa?
<ricotz> yes
<ricotz> i am running it on intel
<Sarvatt> tormod: that'll be in next week for sure, gonna be locked away in a room in budapest doing it :P
<tormod> it doesn't need updated evdev?
<Sarvatt> if ricotz doesn't want to upload it sooner
<ricotz> tormod, only synaptics making some velocity problems
<ricotz> Sarvatt, i guess not ;)
<Sarvatt> ricotz: we could just copy it out of your ppa..? :P
<ricotz> tormod, you might want to wait for a working mesa :P
<ricotz> Sarvatt, hmm, no, the driver versions are the same
<Sarvatt> copy the server, i'll reupload all drivers
<ricotz> i was copying them from edgers everytime
<Sarvatt> i meant
<ricotz> yeah, these packages would work
<ricotz> and the input stuff
<ricotz> Sarvatt, could upload a vmwgfx package?
<Sarvatt> sorry I meant video-vmware
<ricotz> oh, ok
<ricotz> i guess this isnt even a driver
<ricotz> Sarvatt, so there is no important driver missing then?
<Sarvatt> nvidia/fglrx
<Sarvatt> nope
<Sarvatt> it will suck not having xf86-input-mtrack but might be able to fix that up
<ricotz> openchrome should be update in ubuntu since there were 130 commits
<Sarvatt> yep that just needs some cut and paste love
<Sarvatt> ricotz: talk to the debian maintainer of the driver, i think bryce got crap for sponsoring an update of it for me in ubuntu a few years ago when i was thinking the same thing..
<ricotz> hehe ;)
<jcristau> eww via.
<ricotz> jcristau, i guess you are not the maintainer then :P
<tjaalton> Sarvatt: we're doing 1.11, not 1.12 :)
<jcristau> ricotz: there isn't really a maintainer
<Sarvatt> tjaalton: yeah but edgers wont even take a day and is mostly automated, doubt the 1.11 will take more than 4 :)
<tjaalton> Sarvatt: ah you meant both
<Sarvatt> bryceh_: did you see https://code.launchpad.net/~smspillaz/unity/unity.fix_864784_868120_872625v2 ?
<Sarvatt> http://goo.gl/1e86V indeed
<tjaalton> haha
<bryceh_> Sarvatt, sweet!
<bryceh_> working on http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/blueprint-desktop-p-multi-monitor.html
<bryceh_> so I can keep track of all the mm bugs better
<Sarvatt> oh https://code.launchpad.net/~smspillaz/unity/unity.oem-fixes is the real branch and it was approved \o/
<Prf_Jakob> Sarvatt: hey
<Sarvatt> hiya!
<bryceh_> "oem-fixes"? huh
<Sarvatt> that was a high priority oem bug, blocking release on all kinds of new machines since display switch hotkeys weren't working properly on any system
<ricotz> http://lists.x.org/archives/xorg-devel/2011-December/028091.html -- will this still make it into 1.12 somehow?
<jcristau> maybe
<ricotz> ok
<tjaalton> more stuff to backport then, if we hope to have full opengl-3.0 support for precise?
<ricotz> tjaalton, was this actually targeted?
<tjaalton> ricotz: we'll have mesa 8.0
<jcristau> you'll have gl3 on nvidia and fglrx *hides*
<tjaalton> heh, true
<tjaalton> 4.x even
<ricotz> 4.2 ;)
<jcristau> wonder what's the point of not shipping 1.12 if you backport 80% of it though
<jcristau> anyway...
<tjaalton> beginning to feel the same way :)
<jcristau> maybe input+glx doesn't quite make 80%
<ricotz> nvidia/fglrx are the reasons
<ricotz> and it will probably be released/finished quite late
<bryceh_> 12.04.2 will have the newer X stack
<bryceh_> can afford to be conservative with the 12.04.0 stack
<ricotz> bryceh_, right ;)
<bryceh_> well, more conservative than we'd otherwise need to be
<Sarvatt> frankenserver is still going to need to be supported though, thats not gonna be fun
 * bryceh_ nods
<bryceh_> hey word from archive folks is a preference for making the 12.04.0 images more easily downloadable, so no boot mangling work needed
<Sarvatt> LetoThe2nd: mesa's fixed, safe to update to 7.12.0~git20120104.892a2542-0ubuntu0sarvatt2
<bryceh_> here's where the old point releases are kept - http://old-releases.ubuntu.com/releases/lucid/
<tormod> bryce, are the sources (for e.g. Intrepid) available somewhere?
<jcristau> i assume http://old-releases.ubuntu.com/ubuntu/pool/ has everything
<tormod> jcristau, thanks, yes, looks like it
<tormod> got a request for xorg-edgers packages for Intrepid today :) Some exotic hw that only runs Intrepid but with a xserver 1.5.2 bug. At least he can find the sources there and patch it.
<jcristau> sounds fun.
<bryceh_> tormod, also fairly sure you should be able to get the old versions off launchpad too, with sufficient clicking around
<tormod> from the ppa?
<bryceh_> tormod, no; from e.g. https://launchpad.net/ubuntu/+source/mesa/+publishinghistory
<bryceh_> go to the source package page in launchpad, click 'View full publishing history' then pick out whatever version you want
<bryceh_> should be able to get pretty much any source and binary .deb's you need
<tormod> bryceh_, thanks, yes that works, binaries for those still "published", source even for those "superseded"
<FernandoMiguel> evening
<broder> is it possible to get 3d acceleration working inside vmware vms with precise right now? do i need edgers or something?
<RAOF> broder: I believe you need edgers.  I'm also not sure that precise kernels build the vmware kernel module needed.
<broder> hmm, i'll experiment. looks like vmhgfs (host-guest file system) and vmxnet (paravirtualized network driver) don't build on 3.2, but everything else seems good
<tjaalton> is the drm driver yet out of staging
<RAOF> I *think* it's out of staging?
<RAOF> That should mean that it's enabled.
<tjaalton> maybe i'm confusing it with another driver..
<tjaalton> yeah so it should be.. I'll check
<tjaalton> CONFIG_DRM_VMWGFX=m
<tjaalton> yep
<RAOF> modinfo vmwgfx says hi!
<broder> hmm, didn't get loaded, though
<broder> and unity-2d doesn't seem to launch
<RAOF> On edgers?
<broder> yeah. not sure why yet
<tjaalton> needs multitouch
<broder> :-/
<RAOF> At least unity3D should soon work :)
<broder> well, i need to convince mesa to not use software rendering before that's useful on my vm
<Prf_Jakob> broder: I/We will be interested in hearing about any bugs you run it.
<Prf_Jakob> RAOF: what are you currently packaging of mesa/video-vmware?
<tjaalton> -vmware 11.0.99.901, mesa 7.11
<broder> Prf_Jakob: what am i supposed to have to do to activate the vmwgfx?
<RAOF> Prf_Jakob: In precise, currently nothing; we've got 7.11, and (a) I seem to recall you saying not to bother with that, and (b) the kernel module wasn't available until recently.
<Prf_Jakob> Ok, mesa 7.11 wont work with kernel driver.
<Prf_Jakob> broder: mesa git
<Prf_Jakob> broder: tho glxgears seems to have broken over xmas, so I'm looking into that over right now.
<RAOF> That'll be one of the things we'll enable when switching to the 7.12/8.0 branch.
<broder> Prf_Jakob: xorg-edgers looks like it has a snapshot of 892a2542 - should that be new enough?
<tjaalton> I see the drm driver was enabled already on oneiric
<tjaalton> but doesn't matter since it needed newer mesa
#ubuntu-x 2012-01-05
<Sarvatt> broder: you have to build mesa with --enable-xa, install libxatracker and xatracker.pc, then rebuild xf86-video-vmware master with those installed, its not in edgers yet
<broder> ah, ok
<broder> i'll, uh, probably wait until somebody else has done the hard work for me :)
<Sarvatt> it'll be in the archive next week hopefully :)
<RAOF> We'll get a 7.12/8.0 release branch by then, right? :)
<Sarvatt> Prf_Jakob said friday or monday, intel guys said christmas, hoping so :)
<Prf_Jakob> RAOF: thats mostly up to the intel guys
<Sarvatt> been all kinds of fun shoving crap in the past few days, xcb fun
<Prf_Jakob> we are waiting for them
<Sarvatt> RAOF: huey? :)
<RAOF> Sarvatt: I'll stick it in my suitcase :)
<Sarvatt> having to use vga through a kvm on one of my machines, desperately needs color correction
<tomreyn> hi looks like the latest x-edgers mesa is broken due to a build option change: http://lists.freedesktop.org/archives/mesa-dev/2012-January/016748.html
<tomreyn> causing me to run into this on oneiric amd64: libGL.so: undefined reference to `xcb_glx_set_client_info_arb'
<Sarvatt> tomreyn: update
<Sarvatt> fixed that this morning
<tomreyn> gah sorry
<Sarvatt> mid.gmane.org/20120104204434.68DEF1004B@kemper.freedesktop.org
<Sarvatt> was the fix
<tomreyn> thanks. time to reboot
<tomreyn> yup, looks good now.
<FernandoMiguel> nite
<Prf_Jakob> Sarvatt: Hey, just make sure you have xatracker installed before building video-vmware.
<Prf_Jakob> Also make sure you don't have a old one installed :-/
<robclark> so... any ideas about why I'd be getting memory corruption that seems to center around gnome+libxi if I use ubuntu gnome packages (gnome-session, gnome-settings-daemon, etc) w/ vanilla upstream xorg rebuilt from git (ie. without multitouch patches)?
<robclark> ok, seems to work better of I edit library path so gnome picks up libs from my private build (/usr/local/xorg/lib) rather than /usr/lib/$ARCH/..
<robclark> does seem like there is some problem with some of the libs (libxi) talking to a non ubuntu xserver
<robclark> hmm.. maybe I speak too soon..  startx at least survives, but once running still get lots of things closing unexpectedly..
#ubuntu-x 2012-01-06
<Sarvatt> robclark: so you're hitting utouch issues, it's a deep rabbit hole. things are dependent on the implementation in 1.10 in ubuntu at the moment but it should be fixed in precise very soon if it isn't already (not sure if you're using oneiric or precise)
<Sarvatt> oh heck he's gone already
<RAOF> :)
<Sarvatt> multimonitor fix for unity making each display use a different fbo was mark fix released so im assuming chases fix is in precise now, im still on oneiric all around
<Sarvatt> guess i better upgrade before going to budapest
<Sarvatt> we just got done enabling one oem's ivybridge systems on oneiric and have a new one to do now so still gotta care about oneiric
<Sarvatt> time to upgrade just in time to hit upstart breakage in precise, yay
<RAOF> Oh, yu mean that I get to undo the gnome-settings-daemon thingy now? :)
<bryce> Sarvatt, do you plan to do work on precise?  If not, may as well just hold off until after you get back.  Although, so far precise has been pretty stable.
<Sarvatt> "work on precise"?
<Sarvatt> i've been updating crap every now and then
<Sarvatt> well just libdrm and intel updates so far
<RAOF> There'll be the opportunity for mesa 7.12/8.0 packaging in Budapest, too.
<bryce> RAOF, speaking of which how's xserver?
<RAOF> xserver is bonza.
<RAOF> The remaining blocker is synaptics being a pile of infuriating.
<Sarvatt> budapest is all gonna be precise, im planning on ditching the hwe room to be in the desktop room to get crap done
<bryce> Sarvatt, \o/
<Sarvatt> they'll probably put hwe in the left side of the place with 4 rooms instead of the right side of the conference center with 15+ rooms again
<Sarvatt> no cert going this time we got put with so who  knows
<bryce> Sarvatt, yeah to sprints I usually bring two systems, one with devel so I can test stuff, one with stable so I can get work done.  This time both will have precise loaded
<RAOF> All the touchpads I've got access to teleport the cursor to (0,0) at not-apparently-deterministinc intertvals, and it's not clear to me what level of the stack is blowing up (but my guess is input backport).  Chase is aware of it, and is doing synaptics work, so I'm waiting for that.
<Sarvatt> hmm thats a good point
<Sarvatt> i was just planning on bringing the macbook air
<Sarvatt> better off bringing another
 * RAOF seems to be running out of hardware that works enough to bother to bring to sprints.
<Sarvatt> all my discrete gpu systems are too huge to bring though, hmm
<Sarvatt> 8+lbs each
<Sarvatt> asus g73, dell m4600
<RAOF> This ati/intel hybrid will be making an appearance, as the only non-netbook I have that contains entirely functional hardware :)
<bryce> yeah, I'm going with the thin arrandale and a little netbook.
<bryce> the arrandale's wireless is borked at the moment though
<Sarvatt> cert/oem guys arent going this time so there wont be a plethora of unreleased systems we could nab :(
<RAOF> Oh, balls.
<RAOF> Yes.
<bryce> fortunately I'll probably just be doing libxrandrutils hacking, don't need any special hardware for that
<Sarvatt> my goals are mesa 8.0 in precise, vmwgfx packaging, xserver 1.12 in edgers
<Sarvatt> and of course the xserver 1.11 stuff
<Sarvatt> frankenserver is going to be most of the week
<RAOF> As Sarvatt suggested, we might also want to consider plain xserver 1.12 while we're all in the neighbourhood.
<Sarvatt> i only suggested that to you in PM
<Sarvatt> it has lots of drawbacks
<RAOF> Sarvatt: What other work is necessary on the frankenserver.
<RAOF> ?
<Sarvatt> like, we've distributed to OEMS that we're shipping 1.11, and they are asking intel for 1.11 support for cedarview
<Sarvatt> intel is only shipping xserver 1.9 support in the initial cdv driver
<Sarvatt> xserver 1.9 and mesa 7.9
<Sarvatt> and kernel 3.0
<Sarvatt> such a nightmare
<bryce> yeah we can talk about versions of things.  I've been procrastinating sending out that email about what versions of things we'll be shipping, since it's felt a bit uncertain
<Sarvatt> basically whatever chromeos ships
<RAOF> Heh.  Ok.  Or, we could have a simpler conversation here; it sounds like our previous statements have a larger inertia than I thought :)
<Sarvatt> intel has no plans to support 1.11 for cdv, its all pie in the sky things so we can flip flop still if 1.12 is better :)
<Sarvatt> this was literally last week
<Sarvatt> intel UMG is a nightmare to deal with, poulsbo..
<bryce> Just Say No
 * bryce cracks an egg on a hot frying pan
<Sarvatt> i have been for over a year
<bryce> that's your brain on poulsbo
<Sarvatt> they finally got it last week after detailing in a huge doc about what we've experienced wdealing with them about this
<Sarvatt> opengl support? not happening
<RAOF> That sounds like a *particularly* appealing netbook :)
<Sarvatt> recompile clutter using gles instead, which will require a new architecture like lpia basically
<RAOF> Oh.  I thought linaro already had basically the same problems, and solved them?
<bryce> Sarvatt, you mentioned the oem's were spun up on 1.11; aside from cedarview is there anything else that would impact them if a different version was shipped?
<Sarvatt> "yeah we experienced problems with GL apps too, what we did in meego was recompiled clutter using gles instead of gl (compile time option that requires everything recompiled against the different clutter) for mutter to work in meego"
<Sarvatt> anything using GL hangs the system within 10 seconds
<Sarvatt> nah its only cedarview thats a hot ticket item
<Sarvatt> i'm more worried about breaking fglrx for DX
<RAOF> I *think* linaro have the pluggable clutter gl/gles stuff licked.
<Sarvatt> RAOF: the problem is its a compile time option, clutter using gles is incompatible with clutter compiled using gl
<RAOF> But it occurs to me that you may well be in a better position to know that :)
 * RAOF was pretty sure there was work to make that a run-time option, and that work had landed.
<RAOF> Maybe I'm misremembering my blog postings :)
<Sarvatt> arm doesn't care because they can target gles on that architecture because all the drivers ship gles and gl is an afterthought
<Sarvatt> nope, look at debian/rules in clutter source
<RAOF> Eh.
<Sarvatt> are you thinking of cairo?
<Sarvatt> thats what alf was doing
<Sarvatt> for linaro
<RAOF> That could be it.
<Sarvatt> unity will have gles support in 12.04, but then someone is going to buy a netbook and try to install a game like openarena
<RAOF> Hm.  I might *also* be thinking of run-time switchable wayland/X backends.
<Sarvatt> and the system is going to lock up within 10 seconds
<RAOF> No; they'll get terrible performance with llvmpipe, but we'll just disable GL.
<RAOF> BY HOOK OR BY CROOK!
<Sarvatt> yeah as long as we disable any kind of accelerated 3D support which is perfectly doable
<RAOF> We can't selectively disable OpenGL?
<Sarvatt> then they cat a 10k /var/log/Xorg.0.log in gnome-terminal and it takes 45 seconds to show in the terminal because the 2D "acceleration" is so slow
<Sarvatt> its really bad, thats what i've been dealing with for the past month, sorry to complain :)
<RAOF> What is IRC for if not for venting at hardware madness?
 * RAOF wonders who hardware engineers vent at.
<broder> their fabs
<Sarvatt> the bongs they hit 24/7 for getting clogged up
<bryce> heh
<Sarvatt> i think i'm pulling a ROAF this time
<Sarvatt> havent even packed for budapest yet
<Sarvatt> tseliot isn't coming again btw
<Sarvatt> yet another X team dinner missing someone :)
<bryce> shucks
<Sarvatt> RAOF: what synaptics problem were you hitting?
 * bryce eyes bug 903859
<ubot4> Launchpad bug 903859 in xorg (Ubuntu) "wireless connection is not hooking up after i upgraded to version 12 (affects: 1) (dups: 1) (heat: 11)" [Undecided,New] https://launchpad.net/bugs/903859
<Sarvatt> i just realized, i have no machines that use synaptics
<Sarvatt> dell has been all alps for over a year
<RAOF> Sarvatt: The DDX?  Really?
<Sarvatt> hmm i can use synaptics on the mba and lose all gestures if i really wanted to try it out apparently
<RAOF> Sarvatt: I thought basically all touchpad-like hardware went through xserver-xorg-input-synaptics; my Apple Wireless Trackpad certainly does.
<Sarvatt> RAOF: thats a udev rule change to make it happen
<Sarvatt> evdev should be used
<RAOF> That was true for... 11.04?  But synaptics definitely grew gesture support.
<Sarvatt> hmm
<RAOF> We were having a discussion with Chase for that extent - to what extent are gestures worth a really terrible touchpad experience.
<RAOF> Because evdev makes for a rubbish touchpad DDX.
<Sarvatt> you lose tap to click doing that dont you
<Sarvatt> which is pretty major
<Sarvatt> oh wait thats when you use evdev instead of synaptics
<Sarvatt> and probably why it defaults to synaptics now
<RAOF> Tap to click, two and 3 finger tap, two finger scroll, a bunch of filtering, and proper acceleration.
<RAOF> You can *really* tell when you're using evdev rather than synaptics - your touchpad will feel like it's been posessed by the devil.
<RAOF> Or, with the frankenserver, you can tell when you *are* using synaptics, because your pointer will teleport to (0,0) all the time for no obvious reason.
<RAOF> :)
<Sarvatt> hey someone said that happened even on 1.12
<Sarvatt> i think it was ricotz
<RAOF> That could well be the case.
<RAOF> In all other respects the frankenserver seems to be a perfectly functional backport of the new input stack, so it wouldn't surprise me to find that bugs in the frankenserver are backported from 1.12.
<bryce> we should bring lag bolts to tape on the side of our laptops
<RAOF> What is a lag bolt?
<bryce> http://www.boltdepot.com/Lag_bolts.aspx
<bryce> well obviously any old bolt would do.  "lag bolt" sounds more frankensteiny though.
<bryce> RAOF, hey did you get your OLCP box up and running with ubuntu?
<bryce> I just received mine right before xmas, still haven't even opened it up to install the serial port wires
<RAOF> I've got all the prerequisites, but I haven't actually spend the hour or so required to make it bootable.
<Sarvatt> dont those use marvell?
<Sarvatt> aka dont work post jaunty in ubuntu
<Sarvatt> armv5
<bryce> yeah arm hw
<Sarvatt> we went armv6+ only in karmic
<bryce> dunno if it's armv5 or 6
<Sarvatt> debian armel will work at least
<Sarvatt> i might be wrong but i thought they used the same hardware as sheevaplugs and stuff, marvell cpus that were armv5
<bryce> CPU: Marvell Sheeva ARM (PJ4); 
<bryce> ARMv7 architecture compatible; 
<Sarvatt> oh cool
<Sarvatt> not sure if theres a compatible kernel though
<bryce> Linux Kernel: recent Linux 2.6.xx; Fedora base environment.
<bryce>     The OLPC specific bits of the kernel are pulled from the olpc-2.6 GIT tree on dev.laptop.org: (http://dev.laptop.org/git/olpc-2.6) 
<Sarvatt> but at least userspace supports it if its v6+
<bryce> anyway something to tinker with when I'm bored
<bryce> might have to enlist Dutch in doing some QA work on it ;-)
<Sarvatt> lol
<Sarvatt> i have the perfect system for dutch, if only it was pinetrail and not cedartrail
<bryce> he loved playing with the babysitter's iphone.  wish I still had that xt2 touchscreen laptop
<Sarvatt> well its for elementary schoolers, probably a bit too much for him still :)
<Sarvatt> i keep forgetting how young he really is, he's a big kid :)
<Sarvatt> http://www.cceinfo.com.br/produtos/governo/proj-secre-educ-pe/TabletPC%20-%20EC10IS2
<Sarvatt> one of those, its got a handle and made to take a beating from kids
<bryce> yeah, tho he's coming along.  He can recite the entire alphabet accurately now, names the letters correctly about 50/50, and can count to 20 only missing a few numbers along the way
<bryce> he also has USB plugging in skillz now
<Sarvatt> bryce: so it takes him 3 times to plug it in right, the same as us?
<bryce> Sarvatt, that's right
<Sarvatt> awesome :)
<Prf_Jakob> Sarvatt, bryce, RAOF: How nervous do you guys get if we wait untill middle of next week to cut the branch?
<Prf_Jakob> We are so close of getting GL3 support into softpipe.
<Sarvatt> Prf_Jakob: feb 16th is just the date that makes us nervous :)
<Prf_Jakob> Ok
<Prf_Jakob> Next week it is, lets see if I can pause this release in time.
<Sarvatt> at most it'll take a week to prepare and stage and put out a call for testing before putting it in the archive, can probably skip that last part but its a big change and mesa updates always break something for someone (hi KDE)
<Sarvatt> i wonder if kwin still relies on hardcoded gl version strings that need updating every mesa release still
<bryce> Prf_Jakob, next week would be fine with me
<bryce> I suspect we're going to be too busy with sprint stuff to worry too much about much else
<Prf_Jakob> okay
<Prf_Jakob> Doing it now doesn't give us anything else?
<bryce> Prf_Jakob, it would enable us to potentially do the packaging/testing work at the sprint, which would mean we could get this out to users pretty quick
<bryce> but to be honest there's so many frequent interruptions during sprints that it's hard to do intensive packaging work, at least not without making a lot of errors
<Prf_Jakob> bryce: ok, I think the release will be better of with better GL3 support.
<Prf_Jakob> Is the sprint all week?
<bryce> yes
<bryce> Prf_Jakob, would there be much chance if adding the GL3 support might add regressions?
<Sarvatt> we most likely wont have GL3 support in the archive for precise though, it'd need to go through legal and almost guaranteed that can't happen in this time frame. floating point textures and all
<Prf_Jakob> Sarvatt: oh that crap...
<bryce> (knowing how sometimes many bugs in a software release come from whatever feature got added right before release ;-) )
<Prf_Jakob> bryce: we are getting a lot better at regression testing with piglit, and we are really really close so there isn't much to do.
<Prf_Jakob> I think most of the common code is already there.
<bryce> ok cool
<Prf_Jakob> bryce, Sarvatt: http://lists.freedesktop.org/archives/mesa-dev/2012-January/017026.html
<bryce> *nod*
<FernandoMiguel> evening
#ubuntu-x 2012-01-07
<Sarvatt> RAOF: we're on the same flight from LHR to BUD
<Sarvatt> australia to london then 3 hours back to budapest. silly flight :)
<bryce> Sarvatt, think he's left already?
<FernandoMiguel> evening
#ubuntu-x 2012-01-08
<FernandoMiguel> nite
#ubuntu-x 2013-01-01
<mlankhorst> MORNING
<mlankhorst> -caps
<penguin42> mlankhorst: any thoughts on bug 1043513
<ubottu> bug 1043513 in xserver-xorg-video-cirrus (Ubuntu) "Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine" [Medium,Triaged] https://launchpad.net/bugs/1043513
<mlankhorst> yeah wait until tomorrow
<mlankhorst> still vacation today :-)
<penguin42> mlankhorst: no problem; I'm back at work tomorrow so won't be here; but no problem
#ubuntu-x 2013-01-02
<agrestringere> Got a question, I'm handling a bug about Gnome shell and it doesn't involve either lightdm, compiz or unity, should I encourage the reporter to report this upstream to Gnome's bugzilla directly?
<bjsnider> agrestringere, what is the bug?
<RAOF> agrestringere: If it's an upstream bug it should end up in GNOME's bugzilla, yes.
<agrestringere> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1095106
<ubottu> Ubuntu bug 1095106 in xorg (Ubuntu) "Random display corruption in gnome-shell widgets" [Undecided,New]
<bjsnider> it should be reported to gnome, if they don't know about it
<bjsnider> i might go over to their irc channel and ask
<bjsnider> it's #gnome-shell on gimpnet
<agrestringere> Okay, will do, thanks
<bjsnider> they key players are not around at the moment
<bjsnider> still on vacation i guess
<agrestringere> hold on reconnecting via empathy
<agrestringere> bjsnider, I'll just leave a note on the bug report to file upstream at the project url
<mlankhorst> g'day mates!
<tjaalton> hey mlankhorst
<mlankhorst> heya
 * mlankhorst wonders what to work on
<xnox> mlankhorst: anything -cirrus gets +1 from me ;-)
<mlankhorst> was just rebasing my git tree :P
<mlankhorst> seems there was a GF119 fix, might be able to work on nouveau prime again then
 * bryce waves
<GeoffCh> Hi.  I'm struggling with a laptop display that fails to report its EDID.  apw suggested that I visit here.  I have the EDID override in /lib/firmware/edid/ using drm-kms-helper and it shows up correctly in Xorg.0.log with the 1280x800 modeline that I want.  However, I can't get it to use that modeline.  It only uses DDC gathered modelines that don't include 1280x800.  Am I missing something?
<bryce> GeoffCh, does it show up in xrandr --verbose output?
<bryce> if so, see if setting it via xrandr works.
<GeoffCh> It doesn't show up there.  I end up with a 1360x768 screen that doesn't fit the display.
<bryce> GeoffCh, next check that the edid data showing up in xrandr --verbose matches what you've loaded in.  If not, then doublecheck that you've installed the edid file correctly
<GeoffCh> I should say, the EDID data shows up correctly, but not the modeline I want.
<GeoffCh> If I use xrandr to add and use the 1280x800 modeline I want, the the screen doesn't fit the display then either,  and fits even worse than the 1360x768.
<bryce> GeoffCh, got anything in xorg.conf?
<GeoffCh> No, but I have a saved xorg.conf that I'm not using.  I can go back to using it and change whatever needs changing.
<bryce> GeoffCh, how about your Xorg.0.log?
<GeoffCh> The 1280x800 modeline from my EDID file shows up fine in Xorg.0.log.  It just doesn't match any DDC modelines and never gets used.
<bryce> GeoffCh, odd, not sure.  Shouldn't need to match DDC modelines, I think you can set NoDDC to false to force it to use edid.  hard to guess what the issue is.
<GeoffCh> I can try that, adding it to my saved xorg.conf.  Does the i915 driver recognize NoDDC?
<GeoffCh> Also, setting NoDDC to true sounds more intuitive.
<bryce> yeah Option "NoDDC" true or Option "DDC" false
<bryce> the latter is documented in the intel man page so ought to work
<GeoffCh> OK, thanks bryce, I'll give that a shot and come back here after.
<GeoffCh> bryce, when I set DDC to false, I got the correct modelines (1280x800 etc.) from my EDID file, both in Xorg.0.log and in xrandr.  However, the screen doesn't fit anyway.  It's the same result as adding and using the modeline using xrandr, a worse fit than the 1360x768 screen I got from DDC.  It's like the display just balks at 1280x800, whenever it's also not reporting its EDID.  Thank you for helping.  I guess I'll just live with misfitting
<GeoffCh>  1360x768 for now.
#ubuntu-x 2013-01-03
<agrestringere> Got a question some spam has appeared in the Ubuntu-X bug mail https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/596082/comments/12 ???
<ubottu> Ubuntu bug 596082 in xserver-xorg-video-intel (Ubuntu) "[arrandale] Dell Latitude E6510 unable to use second external vga monitor" [Undecided,Expired]
<RAOF> agrestringere: I think #launchpad is where you want to be.
<mlankhorst> happy newyear RAOF / bryce :P
<RAOF> mlankhorst: Happy new year!
#ubuntu-x 2013-01-04
<bryce> mlankhorst, happy NY to you as well
<GeoffCh> Happy New Era too!  bryce, supposing you got my email:  do you suppose the i915 driver could be mapping my modelines somehow to fit within the (wrong) dimensions of my display?
<bryce> GeoffCh, dunno, I'd have to see logs
<GeoffCh> OK, I can do that.  Xorg.0.log, syslog, xorg.conf, anything else?
<bryce> xrandr --verbose, dmesg
<GeoffCh> OK, sure.  No hurry, I'll email them.
<ricotz> bjsnider, hi
<bjsnider> hi
<ricotz> bjsnider, by any chance did you look into building nvidia blob with 3.8rc2 yet?
<bjsnider> no
<ricotz> ok, thanks
<mlankhorst> sforshee: do you know of other ati cards that might also need the d3 delay increase?
<sforshee> mlankhorst, I only have one other system with an ATI card and it doesn't have hybrid graphics. I haven't seen any issues with that one.
<sforshee> slangasek has a mac mini with radeon, but when I had that one I don't recall seeing any issues either
<mlankhorst> ok so it might be just this laptop then having problems during switcheroo?
<sforshee> perhaps
<ricotz> Sarvatt, hey ;), i see you having fun updating things
<Sarvatt> yeah would have helped if i looked before test building/uploading xserver :)
<ricotz> oh :)
<ricotz> did you dare to think about 1.13.99.901 ;)
<ricotz> i hope someone likes to pick up pixman 0.28.2
<Sarvatt> ricotz: have you tried newer pixman? the glyph cache stuff is supposed to make the nvidia blow up last i looked
<Sarvatt> from 0.27
<Sarvatt> err nvidia blob blow up
<ricotz> no, havent tried it
<ricotz> xserver 1.14rc1 will need it though
<Sarvatt> saw lots of complaints from arch people on the nvidia forums about it
<ricotz> hmm, i see
<Sarvatt> ahh arch backported the commit from xserver master to 1.13, so our 1.13 will be fine
<Sarvatt> but yeah https://bugs.archlinux.org/task/32612
 * bryce waves
<wrouesnel> is there any word on if the radeon drivers are working in the edgers ppa again?
<mlankhorst> was a bit of fallout in linux git lately :P
<wrouesnel> ?
<mlankhorst> Sarvatt: hm does edgers use kernel drm git version?
<agrestringere> Got a quick question for you all: I updated to the Xorg Edgers PPA and the current 3.5 Kernel is having massive problems with my Wifi
<agrestringere> the broadcom sta driver won't even start up
<agrestringere> any advice on how to get this working?
<agrestringere>  Anyone can help with this:  Linux 3.5.0-18-generic #29-Ubuntu , wireless package used is bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu3_amd64.deb
<agrestringere> handling it in #ubuntu room, ignore, thanks...
#ubuntu-x 2013-01-06
<Sarvatt> wrouesnel: how is radeon broken? do you mean fglrx? need more context there
<wrouesnel> Sarvatt: radeon as in the open-source driver
<Sarvatt> its broken for you? what release, what gpu, when did it start being broken?
<Sarvatt> hows it broken, corruption or not working at all?
<wrouesnel> Sarvatt: gpu is a cayman pro [radeon 6950]. the driver was broken on the last update to the xorg-edgers ppa
<wrouesnel> Sarvatt: it's broken in the sense that the framebuffer driver initializes improperly (corrupted output on DVI) and launching Cinnamon (or any window manager that uses opengl) leads to a mangled display.
<wrouesnel> changing settings like color tiling doesn't help at all, and (i'm guessing this is the bug report i put on launchpad) i get a lot of that message in ~/.xsession-errors when I try to start a display manager.
<wrouesnel> launching in 2D mode (i.e. software opengl), things work fine.
<Sarvatt> well you said that before the last update, there was another not long before you asked, but there haven't been any big changes in a few updates so thats weird. might be kernel update related but i'm not sure which release you're on, 12.10 is the only one that gets big kernel updates
<wrouesnel> I can confirm that "*ERROR* Invalid register 0x8040 in CS" is fixed by the kernel patch I linked, but I still get total display corruption / improperly working framebuffer drivers.
<Sarvatt> ah so might be mesa related, gotcha
<wrouesnel> also I was running the kernel from the ppa
<wrouesnel> 3.7.0.7-15 I believe (I since downgraded everything from the ppa so I could have a usable system again).
<Sarvatt> 3.8 will be in there very soon which should have any patch you might have linked in it
<Sarvatt> best to stick with quantal kernels in the meantime
<wrouesnel> yeah my own digging seemed to indicate that there's been a lot of development to radeon/drm that's slated for 3.8
<Sarvatt> sorry about the trouble :(
<wrouesnel> it's fine. I wouldn't run it if I wasn't looking for the learning exercise
<wrouesnel> what i did discover is that apt hates downgrades, but is very happy to "upgrade" to a lower versioned number, which was how I eventually purged the ppa without apt trying to uninstall my entire system.
<Sarvatt> http://people.canonical.com/~apw/3.8-rc2-raring/ is whats going in as soon as blobs get updated to work with it
<Sarvatt> apt tried to screw you over even with xorg-edgers ppa-purge version? i uploaded one there that should be ok
<Sarvatt> ppa-purge 0.2.8+bzr57+edgers1~quantal actually works here
<wrouesnel> hm I may have missed that one. anyway, just pinning the quantal repos to highest priority worked perfectly for me.
#ubuntu-x 2014-01-02
<Mez> hi all, attempting a bit of a strange setup here.  I've 4 monitors, spread across 2 gfx cards.  No matter what I do, I can't get all 4 working (with nvidia, it won't actually turn on the 4th monitor, and with AMD, it either clones the other display on that GFX card, or just displays the background).
<Mez> This is using the open source drivers.  If I try any proprietary drivers, I don't get a GUI whatsoever.
<Mez> I'm using the internal GFX (Intel based) with whatever additional cards I have around, none of them I seem to be able to get working.
<Mez> I'm looking for something that's going to allow me to, in the simplest manner possible, run 4 monitors.
<Mez> If that requires extra GFX cards/whatever, that's fine, I just want to find the simplest, most reliable solution
<Mez> and I guess you guys would be the people to ask.
<tseliot> Mez: there are graphics cards which would allow you to do that. Some AMD and NVIDIA cards have enough connectors and will let you drive 4 displays
#ubuntu-x 2014-01-03
<Dandel> ricotz, the recent packaging changes ( in xorg-edgers ) for nvidia 331.20 on precise breaks install... it does not install the nvidia-331-uvm package ( required since this is the kernel module )
<tseliot> he can reuse the packaging from precise-proposed
<Dandel> tseliot, it looks like the issue is that the nvidia kernel module is not built and set to modprobe at boot
<tseliot> Dandel: does the build fail?
<Dandel> no
<Dandel> the build, using this command works just fine... sudo dkms build -m nvidia -v 331-331.20
<Dandel> and it probes just fine also ( using the nvidia_331 module )
<Dandel> however the module was not loaded at boot ( extremely odd )
<tseliot> Dandel: yes, that's meant to be loaded and used on demand
<tseliot> it's not something that the driver requires
<Dandel> although I did a recent kernel update to linux-image-3.5.0-45-generic ( 3.5.0-45.68~precise1 )  on top of updating the nvidia driver
<Dandel> where I updated the kernel *and* nvidia driver at the same time
<Dandel> hmm... exact update order... Install nvidia-331 ( latest ) then install linux-image-3.5.0-45-generic
<Dandel> so most likely the bug is not t he nvidia driver but the kernel package not attempting to build all dkms modules 
<Dandel> this is based on checking the dpkg.log file
<tseliot> Dandel: make sure the headers for that kernel are installed too
<Dandel> tseliot, They are installed... the particular log i was using is here ( http://paste.ubuntu.com/6685436/ )
<Dandel> line 1096 and 1484 to 1581 are of interest ( nvidia driver update and kernel update )
<Dandel> the tailing portion of the log is after I rebooted.
<Dandel> brb... haft to restart xorg.
<Dandel> tseliot, no go... it's definitely broken.
<Dandel> the only thing even remotely listed is the dmesg log for nvidia is the alsa inputs ( kernel module does not load ).
<Dandel> and xorg.0.log says it can't find the nvidia module
<Dandel> tseliot, I'm forcing a package downgrade to see if that fixes the problem with the nvidia driver. ( from 331.20-0ubuntu8~xedgers~precise1 to 331.20-0ubuntu1~xedgers~precise1 )
<Dandel> hmm... that's annoying... can't use synaptic to purge the nvidia-331 packages... wants to force the install of nvidia-304 ><;
<Dandel> I see... the bumblebee-nvidia package was what caused that 0o'
<tseliot> Dandel: you can use my packages from precise-proposed
<ricotz> Dandel, where is your bumblebee package coming from?
<ricotz> the current bumblebee in trusty doesnt support 331, but precise doesnt even ship a package
<ricotz> therefore there are updated saucy and trusty packages in edgers
<Dandel> ricotz, the bumblebee ppa
<Dandel> to be exact, this ppa ( https://launchpad.net/~bumblebee/+archive/stable )
<Dandel> ricotz, it's somewhat odd since I didn't have any issues until the absolute latest round of updates
<ricotz> Dandel, ok, bumblebee got add to Recommends so it gets pulled in
<Dandel> ricotz, I would also say that the opencl ICD ( and headers ) updates should get pulled into the latest lts.
<ricotz> Dandel, yeah -- tseliot, i don't see a reason to revert the packaging split for precise?
<Dandel> there is little to no reason to avoid including this since it's somewhat dumb to provide opencl headers package ( opencl-headers ) and have nothing to link it to... It is sort of on the order of allowing the opengl dev headers to install but not have any opengl libs.
<tseliot> ricotz: what packaging split?
<ricotz> tseliot, installing the opencl library in separate packages
<tseliot> ricotz: we only do that in 14.04. I don't think I have introduced that change in precise
<ricotz> tseliot, yes, that is why i am wondering what the reason for that was
<Dandel> ricotz, there should be no reason to override the opencl lib. There is a set OpenCL ICD spec that exists where all you need to have is the nvidia driver (or ATI/AMD Driver) and the ocl-icd-libopencl1 package.
<tseliot> ricotz: the packages in precise-proposed don't have that change
<tseliot> ricotz: users might want to use those libraries without having to install the driver
<Dandel> tseliot, where do i find the precise-proposed packages?
<ricotz> tseliot, right, and they cant because the split isnt done for precise
<tseliot> Dandel: in the precise-proposed repository
<ricotz> tseliot, i am asking why it *isnt* done
<ricotz> tseliot, this is most likely just calling for trouble on upgrades
<ricotz> if there are not conflicts defined
<tseliot> ricotz: in 14.04 you can't install all the drivers at the same time, whereas in 12.04 you can. This is why.
<ricotz> hmm, still looks like a (maybe) broken upgrade path
<Dandel> tseliot, does 14.04 enable vdpau on noveau and radeon drivers? ( a critical addition to the driver that was made in the last 6 months )
<tseliot> ricotz: nvidia will be replaced by a new nvidia which will also pull in the other libraries. It didn't break here
<tseliot> Dandel: tjaalton mlankhorst should know about vdpau
<Dandel> tseliot, I already mentioned this a couple of times... It's a new feature in the Mesa 10.0 tree
<tseliot> we'll see then
<Dandel> tseliot, There's also other improvements that also appear in mesa like Opencl ( since Mesa 9.0, it's the gallium state tracker called clover )
<tseliot> I think there was a discussion about opencl in debian
<Dandel> Yea, and it definitely is because Mesa 10.0 added support for OpenCL ICD.
<mlankhorst> it's not enabled for now
<mlankhorst> as soon as it is clear that it becomes an improvement I may enable it, but I'm still reading about way too many vdpau related regressions
<Dandel> mlankhorst, vdpau has some regressions but there is a lot of improvements by having it enabled... particularly for lower power machines.
<Dandel> the only way for some machines to play 1080p video is to have vdpau enabled. A good example of one of these machines is the AMD E-series like the E350 or similar.
<Dandel> also, there is major battery life improvements that can be seen on multiple machines like the amd APU based laptops
<Dandel> hardware accelerated video decoding can easily cause major improvements in battery life for the effected laptops... There is a major difference between 2 hours of battery life and 3 hours of battery life.
<Dandel> mlankhorst, what time period was the regressions listed? ( I know that there was a ton of issues initially, but most of the regressions/problems have been fixed )
<Dandel> mlankhorst, I believe the latest openelec development series ( generic configuration ) uses mesa with vdpau ( a single patch was added to enable vdpau playback with interlaced video )
<Dandel> ricotz, the precise-proposed 331 driver ( nvidia-331-updates ) worked... although it may be a good idea to change nvidia-settings package to have the version number with it ( to help avoid packaging avoid conflicts )
#ubuntu-x 2014-01-04
<mlankhorst> Dandel: nouveau still cannot reclock
<mlankhorst> Dandel: so it's faster to use cpu rendering on nouveau at least
<mlankhorst> and because I don't want people blacklisting nouveau I've disabled it for now
<Dandel> mlankhorst, it should be possible to blindly disable the noveau vdpau state tracker
<Dandel> mlankhorst, linux 3.13 has improved reclocking support in nouveau
<Dandel> mlankhorst, I have a half-way approach... by default the mesa ( and xorg drivers ) don't enable vdpau, but offer the option to install the packages with vdpau via an testing ppa ( similar to xorg-edgers )
<mlankhorst> Dandel: fortunately for you others already have a ppa with vdpau enabled
<mlankhorst> :P
<Dandel> mlankhorst, oh... where is that at?
<mlankhorst> https://launchpad.net/~oibaf/+archive/graphics-drivers/ i think
<mlankhorst> but it breaks if enabled on trusty :p
<Tynach> Hi. I'm not sure if what I'm experiencing is a bug or not. I'm using the xorg-edgers ppa, and the 13.10 kernel, but on Ubuntu 12.04. After I rebooted, nVidia's proprietary driver will no longer load. I don't know if I'm using Nouveau or nv, but the display resolution is correct... But I have no 3D acceleration. nvidia-smi tells me there's an error talking to the nvidia driver.
<Tynach> Jockey says that none of the listed drivers are in use, though several are enabled.
<Tynach> No ideas?
<Dandel> ricotz, I think the xorg edgers ppa needs to be fixed on the nvidia driver ( seeing as how there was another person who ran into the issue I ran into )
#ubuntu-x 2016-01-06
<mamarley> ricotz: So I tried packaging 361.16, but it has a critical bug that causes KDE to fail to start, so I am not uploading it.
<mamarley> I did, of course, complain about it on the forum.  The thread already has two me-toos, to I am pretty sure it is a real issue and I didn't just mispackage something: https://devtalk.nvidia.com/default/topic/908506/linux/many-essential-kde-applications-sddm-krunner-plasmashell-segfault-on-startup-with-361-16/
<ricotz> mamarley, hi, I see, is this only related to KDE or maybe QT5 apps too?
<mamarley> ricotz: Not sure, KDE is the only DE I have installed.  The crash is definitely in the Nvidia driver though; the stacktraces end with "#6  XScreenCount (dpy=0x0) at ../../src/Macros.c:109\n#7  0x00007fe7623640da in glXGetClientString () from /usr/lib/nvidia-361/libGLX.so.0".
<ricotz> mamarley, I wouldn't rule out the packaging problem though
<mamarley> ricotz: I actually tried installing it using the .run file and had the same problem.
<ricotz> was this already confirmed while using the nvidia installer?
<ricotz> ah ok
<mamarley> I figured I had mispackaged it at first too, since they introduced the new glvnd thing.
<mamarley> GL actually works fine though if you do "startx /usr/bin/xterm" and then execute some GL application from there.
<ricotz> on which ubuntu did you ran it?
<mamarley> ricotz: Xenial
<ricotz> maybe even related to the Xserver version, maybe some compat regression
<mamarley> Perhaps.  Two other people confirmed it in the forum though.  One didn't say which distro he/she was using and the other was using Arch.
<ricotz> I am a bit busy currently, did you uploaded the package somewhere else already?
<mamarley> No, I didn't upload it because it was busted.  I can upload them to my staging PPA in a hour or so though.  Hopefully no-one is actually using that.
<ricotz> it is a beta after all, and maybe even only related to KDE
<jcastro> I can give it a shot
<jcastro> I don't use KDE so it shouldn't affect me
<mamarley> jcastro: I don't know for sure that it doesn't affect non-KDE DEs; I haven't tried any others.
<jcastro> I can give it a shot if you want, or we can wait to see what nvidia says
<mamarley> Feel free to try it, but be ready to deal with a busted system.
<jcastro> sure, where's the staging ppa?
<mamarley> https://launchpad.net/~mamarley/+archive/ubuntu/staging
<jcastro> looks like they failed to build
<mamarley> jcastro: Yeah, on everything but Xenial.  I somehow managed to royally screw up the orig.tar.gz.  I am trying to extricate myself from that mess now.
<jcastro> heh
<mamarley> ricotz: Do you have any objection to me going ahead and copying nvidia-settings 361 to the main PPA?
<ricotz> mamarley, looks safe, but there is actually no need to update it given its diff to the previous release
<mamarley> Hahaha, I didn't look at that.  It is literally the same, except for version numbers.  I will copy it anyway though, because otherwise people will probably complain.
<ricotz> mamarley, no, it is a beta
<ricotz> so other people will complain they are forced to upgrade to a beta version ;)
<Sarvatt> i've only seen people complaining about kde, and a few reports it works fine and fixes the steam segfaults on sandybridge in gnome
<jcastro> It might be a good idea to have a "beta" ppa and shove the betas in there and be like "you break it you keep the pieces"
<Sarvatt> plasma 5 specifically
<mamarley> We already don't force or even encourage users to upgrade between major releases.
<mamarley> (If people have 358 installed, they won't be automatically updated to 361)
<ricotz> jcastro, this just concerns the nvidia-settings currently which didnt change
<ricotz> and for the driver itself what mamarley said
<mamarley> ricotz: So are you saying I shouldn't copy it then?
<ricotz> yes, no need to
<mamarley> ricotz: Sorry, I seem to have majorly screwed up.  Somehow, the orig.tar.gz I uploaded for 361.16 had .bin files instead of .run file (I don't understand why though, since I definitely renamed the files before packing the archive).  For reasons beyond logic, Xenial still built.  However, none of the others will work because of complaints about the uploaded file having different contents.
<mamarley> I even tried to create a new staging PPA to get around that problem, but I still get the same error on all uploads after the first one.
<ricotz> mamarley, you *renamed* the files?
<mamarley> ricotz: Yes, they usually come as .run but this time they came as .bin.
<ricotz> the should be *.run as usual
<mamarley> So I renamed them to .run.
<ricotz> the ftp server contains them a .run as always
<mamarley> Hmph, they must have gotten renamed after I downloaded them.  Sneaky.
<ricotz> weird
<mamarley> Anyway, I figured out why they weren't uploading and got them to upload properly, but now everything but Xenial fails with some kind of dpkg-shlibdeps error.
<mamarley> I have been doing this for literally years, you would think that I might be a bit less useless at it than I am.
<ricotz> can give me a link to the proper xenial dsc?
<mamarley> ricotz: https://launchpad.net/~mamarley/+archive/ubuntu/staging-2/+files/nvidia-graphics-drivers-361_361.16-0ubuntu0~gpu16.04.1.dsc
<ricotz> ok, will grab it
<ricotz> bbl
<mamarley> ricotz: So I got wily and vivid fixed, working on Trusty now.
<mamarley> For future reference, the packaging for 361 is exactly the same on Xenial, Wily, and Vivid.
<mamarley> I didn't know that, so I was doing a lot of work I didn't need to do, but I diffed the source and they are definitely the same.
<mamarley> Trusty is actually the same too except for the debian/substvars file.
<mamarley> Trusty is ready now too.  All the drivers are in https://launchpad.net/~mamarley/+archive/ubuntu/staging-2/+packages.
<mamarley> jcastro: If you want to test^
<jcastro> waiting on publication for some of them: https://launchpad.net/~mamarley/+archive/ubuntu/staging-2/+build/8809861
<mamarley> jcastro: Only on Trusty.
<jcastro> yeah I'm on trusty
<mamarley> Sorry :(
<jcastro> I'll just wait, no biggie
<jcastro> mamarley: no issues so far in steam
#ubuntu-x 2016-01-07
<mamarley> More me-toos on the KDE-brokenness issue, but nothing from anyone at NVIDIA yet,
<jcastro> mamarley: CivV won't launch with the new driver for me anyway
<jcastro> everything else seems to work
<ricotz> jcastro, hi, I assume you are running unity7?
<jcastro> no, dedicated steam session on my nvidia machine
<ricotz> ah, alright
<jcastro> how did it work for you? I moved back to 352
<ricotz> haven't updated yet, due those reports, need to get some other work done ;)
<mamarley> Still nothing from NVIDIA on the KDE-crashing bug :(
<jcastro> do you have a link to the forum post/bug for that? I figure I'll put it in the description in case people ask. 
<jcristau> jcastro: https://devtalk.nvidia.com/default/topic/908506/linux/many-essential-kde-applications-sddm-krunner-plasmashell-segfault-on-startup-with-361-16/
<jcristau> was mentioned here earlier
#ubuntu-x 2016-01-08
<ara> hello!
<ara> do you guys know when xserver-xorg-core-lts-wily will be available?
<ara> tjaalton, ^
<tjaalton> ara: along with the rest, within two weeks I hope
<tjaalton> hope you don't need lts-w for cert..
<ara> tjaalton, cool, thanks is there a PPA if I want to try before that?
<tjaalton> yes, ppa:canonical-x/x-staging
<ara> great, will give it a try, because I tried installing wily on my xps 13 (9433) and it was terrible, so I had to return to trusty. I thought it might be a regression in the kernel, but I am now on 4.2 and it works well
<ara> tjaalton, thanks!
<tjaalton> terrible how?
<tjaalton> is it skylake?
<ara> no, it is haswell
<tjaalton> ok
<ara> terrible: sluggish, the cursor hanged every 20 seconds, etc.
<tjaalton> k
<tjaalton> instructions on installing lts-w https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<tjaalton> just replace s/vivid/wily/
<ara> I just tried, and I got these errors: http://pastebin.ubuntu.com/14437229/
<tjaalton> exactly :)
<ara> tjaalton, exactly, what? :)
<ara> tjaalton, how can I fix it?
<tjaalton> use the instructions
<tjaalton> from wiki
<tjaalton> apt gets confused
<ara> tjaalton, I used what it said in the wiki
<tjaalton> oh you had .2 installed? need to revert to stock trusty first
<tjaalton> iirc
<ara> no, I didn't have it... so weird
<tjaalton>  libegl1-mesa-drivers-lts-utopic : Depends: libwayland-egl1-mesa-lts-utopic (= 10.3.2-0ubuntu1~trusty2) but it is not going to be installed
<tjaalton> you have lts-utopic installed
<ara> mmm, no I don't think so
<ara> ara@sushirider:~â« apt-cache policy xserver-xorg-core-lts-utopic
<ara> xserver-xorg-core-lts-utopic:
<ara>   Installed: (none)
<ara>   Candidate: 2:1.16.0-1ubuntu1.2~trusty2
<ara>   Version table:
<ara>      2:1.16.0-1ubuntu1.2~trusty2 0
<ara>         500 http://es.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
<ara>         500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
<tjaalton> libegl1-mesa-drivers-lts-utopic
<ara> nop
<ara> ara@sushirider:~â« apt-cache policy libegl1-mesa-drivers-lts-utopic
<ara> libegl1-mesa-drivers-lts-utopic:
<ara>   Installed: (none)
<ara>   Candidate: 10.3.2-0ubuntu1~trusty2
<ara>   Version table:
<ara>      10.3.2-0ubuntu1~trusty2 0
<ara>         500 http://es.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
<ara>         500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
<tjaalton> add libegl1-mesa-lts-wily to the list
<tjaalton> apt get install command
<ara> tjaalton, no luck :( http://paste.ubuntu.com/14437290/
<tjaalton> oh, test if you have lts-vivid
<tjaalton> or just apt-cache policy xserver-xorg-core
<ara> 100 ara@sushirider:~â« apt-cache policy xserver-xorg-core
<ara> xserver-xorg-core:
<ara>   Installed: 2:1.15.1-0ubuntu2.7
<ara>   Candidate: 2:1.15.1-0ubuntu2.7
<ara>   Version table:
<ara>  *** 2:1.15.1-0ubuntu2.7 0
<ara>         500 http://es.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
<ara>         500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
<ara>         100 /var/lib/dpkg/status
<ara>      2:1.15.1-0ubuntu2 0
<ara>         500 http://es.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
<ara> tjaalton, ^
<tjaalton> ok
<ara> tjaalton, so I guess we don't know how to fix it?
<tjaalton> i'll check it out in a bit, need to fix my car not starting first..
<ara> tjaalton, :)
<tjaalton> (diesel filter frozen)
<mamarley> Is Xenial going to get xorg 1.18?
<tjaalton> likely
<mamarley> Thanks!
<tjaalton> why?
<mamarley> Just curious
<tjaalton> i'll start pushing things to the staging ppa next week
<mamarley> Cool.  No rush, like I said I was just curious.
<tjaalton> nah it's been on the todo-list for a while
<tjaalton> ara: ok, testing the lts-w down/upgrade now
<ara> tjaalton, cool, thanks, let me know
<tjaalton> looks like update from lts-vivid to lts-wily works too, but next I'll see how it's with stock trusty..
<tjaalton> ara: huh, weird... the wiki command works fine here
<ara> tjaalton, weird
<ara> tjaalton, do you have any other ppas enabled?
<tjaalton> no
<tjaalton> this is a fresh install from late-november just for testing this
<tjaalton> although, I used .3 and then downgraded to stock
<ara> tjaalton, weird, weird, this is a very recent reinstallation
<ara> tjaalton, I might try in a vm and will let you know
<tjaalton> looks as if you have some package installed which provides xorg-renamed-package-lts-vivid
<tjaalton> nvidia?
<tjaalton> hum no, that's all-intel
<tjaalton> ara: aptitude search '~Pxorg-renamed-package-lts-vivid'
<tjaalton> + | grep -v ^p
<tjaalton> or just | grep ^i
<ara> tjaalton, nothing installed
<ara> http://paste.ubuntu.com/14438587/
<tjaalton> right
<ara> tjaalton, removing the ubuntu-sdk changed the error message: http://pastebin.ubuntu.com/14438658/
<tjaalton> ara: so add libgbm.. and libgl1.. to the command, what happends?
<ara> tjaalton, http://pastebin.ubuntu.com/14438678/
<ara> tjaalton, this is a pretty new installation (and my HOME folder is in a different partition) so I might just try to reinstall / during the weekend and try then
<tjaalton> ara: but if you had ubuntu-sdk it probably pulled in other -dev bits too
<ara> tjaalton, I apt-get autoremove after it
<tjaalton> you have libgl1-mesa-dev
<ara> tjaalton, removign that one made the installation of your packages work! (or so it seems so far)
<ara> tjaalton, is that expected? that if you have -dev pacakges installed you cannot upgrade the hwe stack?
<tjaalton> should work
<tjaalton> I'll try to replicat
<tjaalton> e
<ara> tjaalton, thanks a lot for your help, I will reboot on the new stack and will let you know if the problems I had on native wily reproduce 
<tjaalton> yeah I get the same error now
<tjaalton> actually I don't, but close
<ara> rebooting now
<tjaalton> got it working, just needed to add libgl1-mesa-glx-lts-wily to the install command
<tjaalton> though it would then remove libgl1-mesa-dev
<ara> tjaalton, in hte new stack now and so far it works well, the issues i had in wily don't reproduce
<ara> tjaalton, I don't know if that's good or bad news :D
<ara> as my goal was to be able to find the cause and be able to move to wily
<tjaalton> heh
<ricotz> mamarley, hi, running 361.16 now, so far so good
<ricotz> with GNOME 3.19+
<mamarley> ricotz: OK, so should I copy it to the main PPA then?
<mamarley> (I would definitely put a warning for KDE users to skip this version.)
<ricotz> mamarley, yeah, I would say it is fine to copy them
<mamarley> ricotz: Awesome, it looks like NVIDIA dropped the driver version suffix from libGL.so and libEGL.so for i386 and amd64 but not armhf...
<mamarley> I'm not sure what to do about that since the links.in template is used for all the architectures.
<mamarley> Oh, and we got a response from Aaron Plattner about the 361.16 KDE krashing.  It is apparently a bug in Qt, but he has put a workaround into libglvnd and it will be in the next 361 release.
 * mamarley wonders if he can compile that himself and swap out the libraries...
#ubuntu-x 2018-01-04
<tjaalton> RAOF: hi, mesa needs some mir love, if you have time ;)
<RAOF> tjaalton: I'll make some time. A nice break from Go.
<tjaalton> hehe
<tjaalton> thanks
<soee_> mamarley: 390.12 beta :)(
<mamarley> ricotz: Shall I work on 390.12 or are you already doing that?
<ricotz> mamarley, I started to look at it, but if you want to do it?
<mamarley> Sure, I can take a stab at it.
<mamarley> I'm hoping they fixed the DRM atomic modesetting stuff for 4.15 compatibility.  I tried to patch 387 for those changes and it was well beyond my ability.
<mamarley> (A minimal patch allows it to compile, but atomic modesetting doesn't work because the associated conftest fails.)
<ricotz> mamarley, seems to build fine with 4.15rc6
<ricotz> if I am back in a few it didnt break too badly ;)
<mamarley> ricotz: Does "[drm] Supports vblank timestamp caching Rev 2 (21.10.2013)." or something of the sort appear in dmesg?
<mamarley> (Oh wait, on second thought, one would need to set "options nvidia_387_drm modeset=1" in /etc/modprobe.d/nvidia-graphics-drivers.conf for that to work anyway.
<ricotz> I am persistently running x11 ;)
<mamarley> ricotz: Anyway, it looks like you already have most of the work for this done, so I guess there isn't any point in me going any farther?
<mamarley> (Or I can do -settings?)
<ricotz> I didnt really look at it, just plain taking the 387 package and throwing it into pbuidler ;)
<ricotz> bionic only
<ricotz> nice that the license stuff is fixed
<mamarley> Definitely.
<mamarley> ricotz: So what do you want me to do?
<ricotz> mamarley, would great if you could look at it properly
<mamarley> OK, I will do that.
<ricotz> like symlinking libnvidia-egl-wayland.so.1.0.1 seems to be obsolete
<ricotz> lrwxrwxrwx   1 root root       30 Jan  4 19:16 libnvidia-egl-wayland.so.1 -> libnvidia-egl-wayland.so.1.0.2
<ricotz> -rw-r--r--   1 root root    31976 Dez 20 16:44 libnvidia-egl-wayland.so.1.0.2
<ricotz> mamarley, thanks
<mamarley> No problem.
<mamarley> So while they did fix the compilation with 4.15, atomic modesetting still doesn't work. :(
<mamarley> ricotz: soee: nvidia-390 and nvidia-settings are uploaded to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages, but the build queue is well and truly jammed, so it is going to be a bit before they actually compile.
<soee> :-)
<mamarley> soee: Not sure if you saw above, but they these compile fine against 4.14.11 and 4.15-rc6, though atomic KMS doesn't work on 4.15-rc6.  I already tried to fix that with 387, but it is well beyond my ability.
<mamarley> (KMS isn't the default though, so unless you go screwing around with /etc/modprobe.d/nvidia-graphics-drivers.conf, you won't see anything different.)
<soee> mamarley: and > 4.14.8 ?
<mamarley> soee: I only tested it with the two versions I named.
<soee> previosu driver version failed to work with kernel 4.14.9 and higher
<soee> ah sorry, 4.14.11
<soee> :D
<ricotz> mamarley, ok, yeah, those are precautions due to meltdown/spectre until the servers are patches
<mamarley> Ah yes, that makes sense.  Wouldn't want anyone screwing around with other builds.
<ricotz> exactly
<ricotz> it has been some time since I build a kernel locally, but today it seemed necessary ;)
<ricotz> make sure to update firefox
<mamarley> I have been self-building kernels for one of my boxes ever since 4.14.3 because of a bugged e1000e patch that causes the interface on that box to not come up.
<ricotz> oh
<mamarley> There is another patch to fix it, but that patch hasn't been included yet. :(
<ricotz> so this is even a mainline issue?
<mamarley> Yes, it affects at least the current 4.14 and 4.15-rc builds.
<ricotz> I see
<mamarley> 2018 was supposed to be better than 2017, but the first thing that happens is that we suddenly find out that almost ever computer is inherently insecure. :(
<mamarley> s/ever/every
<ricotz> especially if the story breaks 5 days early
<soee> :) but hey, only better things can happen now
<mamarley> soee: Like a nuclear war?
<soee> noone wins such war, so no chance for it :)
#ubuntu-x 2018-01-06
<mamarley> ricotz: I have also uploaded new nvidia-340 packages to my staging PPA that contain patches for all kernels up through 4.15.  (No license issues occurred.)
<ricotz> mamarley, nice :)
<ricotz> I assume tseliot will take care of 384.111
