| maxb | Wasn't it already in karmic? | 00:18 |
|---|---|---|
| verbalshadow | didn't seem to work for me, thought there was a PPA it | 00:20 |
| RAOF | Oooh. An upstreaming branch of nouveau appears. | 01:57 |
| === verbalshadow_ is now known as verbalshadow | ||
| tjaalton | RAOF: I think it's upstream already | 05:41 |
| tjaalton | at least Linus tested it and it worked | 05:44 |
| tjaalton | yes, it is merged | 06:41 |
| tjaalton | Sarvatt: what should be done to bugs about edgers packages? | 06:51 |
| RAOF | tjaalton: That was fast - the for-airlied branch was only made 17 hours ago :) | 07:05 |
| RAOF | So, time to update my lucid kernel branch pulling nouveau from linus instead, I guess. | 07:06 |
| verbalshadow_ | how do i tell if my lucid system is using KMS? | 07:45 |
| cwillu | verbalshadow, does switching vt's work, and does it take less than a tenth of a second? | 08:06 |
| tjaalton | only intel does it by default | 08:11 |
| tjaalton | there's a new kernel upload but it's probably not built yet | 08:11 |
| Duke` | I don't know why but for some weeks (or months?) I have no visible cursor with R200/lucid. I have to run xrandr once (without any change) and the cursor come back. | 11:33 |
| tjaalton | damn I hate that system test app which tries to run xrandr on hw that doesn't support it, and then files tons of bugs.. | 12:17 |
| tjaalton | heh, and tons of related bugs filed against checkbox.. no-one seems to care though | 12:21 |
| tormod | tjaalton, bugs in xorg-edgers can be filed in launchpad, but add "xorg-edgers" in the title and subscribe the uploader | 13:00 |
| tormod | Duke`, your missing cursor: with kms? | 13:01 |
| === mac_v_ is now known as mac_v | ||
| Duke` | tormod: yes with KMS | 14:53 |
| Duke`_ | RAAAAHHH SHIETY CONNECTION§§!dfù!:df | 17:20 |
| Duke`_ | I had written a long speech during disconnection ;_; | 17:21 |
| Duke`_ | did you see something of what I said during the last 10 mins? | 17:21 |
| Sarvatt | tormod: ugh, looks like we are gonna have to replace linux-libc-dev again since intel git requires headers from 2.6.33? | 17:34 |
| Duke`_ | http://pastebin.com/m1e7a2212 | 17:35 |
| Sarvatt | ./include/drm/i915_drm.h:#define I915_PARAM_HAS_OVERLAY 7 (in libdrm) and http://launchpadlibrarian.net/36710792/buildlog_ubuntu-lucid-amd64.xserver-xorg-video-intel_2:2.9.99.901%2Bgit20091211.8ecf70ea-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz | 17:35 |
| tormod | Sarvatt, can't believe they unconditionally require 2.6.33 ? must be a bug | 17:36 |
| Sarvatt | they have a patch for 2.6.32... | 17:36 |
| Sarvatt | i think its intentional.. | 17:36 |
| Sarvatt | http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906 | 17:36 |
| tormod | they removed the #ifdefs ... way to go | 17:37 |
| Sarvatt | the person who wrote that obviously doesn't use a debian based distro | 17:37 |
| tormod | "now that 2.4.16 is released..." what about waiting for the kernel to release, grrr | 17:38 |
| Sarvatt | i dont even think the overlay patches are in linus' tree yet? | 17:39 |
| tormod | "this needs at least kernel v2.6.33 to work", well in a few months time | 17:39 |
| Sarvatt | whatever distro he uses must have libdrm headers actually getting installed | 17:40 |
| Sarvatt | too bad we're stuck on 2.6.32 :( | 17:40 |
| tormod | he's probably using his own kernel with his own headers and expects the world to follow :) | 17:41 |
| Sarvatt | pretty safe to say noone using edgers will be using the ancient 2.6.32 4 months from now anyway :D | 17:47 |
| === ripps_ is now known as ripps | ||
| Sarvatt | Duke`: I have the same problem | 17:51 |
| Sarvatt | lots of hangs with execbuff while wedged spamming dmesg | 17:51 |
| Sarvatt | thats on the drm-intel-next kernel though | 17:52 |
| Sarvatt | tormod: going to upload a new libdrm replacing linux-libc-dev and not deleting the headers in the rules I guess, unless you can think of something else to do | 17:55 |
| Sarvatt | could make a hook to revert that commit every time :D | 17:57 |
| tormod | Sarvatt, yes, sounds ok, like we once did. did you try it out locally? | 17:58 |
| tormod | but I can't believe they did this. this will be 2.10 for their Q4 package right? | 18:00 |
| * albert23 got -intel working that way yesterday | 18:00 | |
| albert23 | I think Eric Anholt explains it here: http://marc.info/?l=dri-devel&m=125770698907397&w=2 | 18:01 |
| albert23 | build against latest headers, then run-time detection if the feature is available | 18:01 |
| tormod | albert23, thanks | 18:02 |
| Sarvatt | hmm, someone saying a no change rebuild of nvidia 185.18.36 under lucid works, have to try that out | 18:24 |
| tjaalton | Sarvatt: by using IGNORE_ABI? doesn't help much | 18:32 |
| tjaalton | packaging wise | 18:33 |
| Sarvatt | they said it worked like normal after a rebuild to not remove xorg and bump the abi even though the release notes didnt start saying it supported 1.7 until 190, will have to test it when I get home later but I put it on edgers to rebuild just incase | 18:39 |
| Sarvatt | it sure was fun uploading the blob on a tethered cell connection :D | 18:40 |
| === mac_v_ is now known as mac_v | ||
| === nielsslot_ is now known as nielsslot | ||
| Sarvatt | darn nouveau box _really_ doesn't like being run with the lid closed for days - http://paste.ubuntu.com/340114/ | 19:01 |
| Sarvatt | dlopen: /usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: resVgaShared | 19:13 |
| Sarvatt | nvidia failed to load | 19:13 |
| === _stink__ is now known as _stink_ | ||
| Sarvatt | Why did we move away from the nvidia-glx, nvidia-glx-new, nvidia-glx-legacy naming scheme to the current nvidia-glx-(major version) one thats a major pain to update as often as nvidia bumps the major version? | 20:05 |
| Sarvatt | seems like it would be a good idea to leave a generic version scheme for the trunk then just version all the old legacy ones like they are now | 20:06 |
| Sarvatt | the .in's would work right if we did that too, they seem like a remainder from an old naming scheme since it just bumps the dep versions not the actual package names -- Package: nvidia-glx-185 Depends: nvidia-185-kernel-source (>= #VERSION#), nvidia-185-libvdpau (>= #VERSION#), x11-common (>= 1:7.0.0), ${shlibs:Depends} | 20:10 |
| Sarvatt | strange.. (185.18.36) Package: nvidia-glx-185-dev Depends: nvidia-glx-185 (>= 185.18.31) Conflicts: nvidia-glx-185 (>= 185.18.32) | 20:27 |
| superm1 | personally i dont see why we dont just put all the packages into one big package (say nvidia-$MAJOR_VERSION), and then in the .in, just update that $MAJOR_VERSION if it's a bump | 20:36 |
| superm1 | there's no reason to ever go mix and match some vdpau library here, or kernel source package there | 20:37 |
| superm1 | and it would certainly help if you want to switch from nvidia->nouveaou and what not | 20:37 |
| superm1 | same goes for debian, i think the same type of change would be applicable there | 20:39 |
| tjaalton | the older versions rarely change, so uploading four blobs every time seems a bit excessive | 20:46 |
| tjaalton | I think the latest version should be just n-g-d, without a version | 20:47 |
| tormod | Duke`__, I also lose the cursor sometimes, gets back with console switching or xrandr | 20:50 |
| tormod | just verified now it is not related to compiz | 20:52 |
| Sarvatt | in this case all the old blobs need updating at the same time for the new xserver abi though :( | 20:55 |
| Sarvatt | hmm if we add MAJOR_VERSION like that to debian/upstream_info it wont add the old major version package names to be removed and stuff, will still have to hand edit all those hooks | 21:03 |
| Sarvatt | unversioned package name for the trunk is all i can see doing outside of rewriting all this stuff to pack them all together like that, would be alot easier i'd think to not have a major version in the main package name and leave the old versioned like they are? | 21:06 |
| Sarvatt | thats just if i was doing it though, i'm not good at this stuff :D | 21:07 |
| Sarvatt | or we could just define OLD_MAJORVERSION as well and add like nvidia-$OLD_MAJORVERSION to everything in control and leave the stuff there as well? | 21:12 |
| Sarvatt | oh but that wouldnt account for old old major version packages so that wont work | 21:12 |
| Sarvatt | dont mind me just thinking out loud | 21:13 |
| Sarvatt | all the nvidia legacy drivers have updates for xserver 1.7 so those would be easy to package up right now at least, just editing the versions in debian/upstream_info | 21:24 |
| Sarvatt | oh 71.xx hasn't been updated | 21:25 |
| Sarvatt | ftp://download.nvidia.com/XFree86/Linux-x86/96.43.14/ ftp://download.nvidia.com/XFree86/Linux-x86/173.14.22/ | 21:26 |
| tjaalton | IIRC it newer will be | 21:27 |
| Sarvatt | its a shame the cards that need 71 dont work in nouveau either I believe | 21:29 |
| tjaalton | those are ancient anyway | 21:31 |
| Sarvatt | ah just tnt1, 71 is for tnt1 to geforce2 | 21:31 |
| Sarvatt | hmm libvdpau_trace.so is gone from 195 nvidia drivers | 22:11 |
| Sarvatt | ah its another folder down in usr/lib/vdpau/ now | 22:12 |
| Sarvatt | libvdpau_nvidia too, ugh | 22:21 |
| superm1 | Sarvatt, no dont install them | 22:23 |
| superm1 | there is a NEW library, libvdpau | 22:23 |
| superm1 | so you only need to install libvdpau_nvidia | 22:23 |
| superm1 | and depends on libvdpau | 22:23 |
| Sarvatt | ohh I see | 22:23 |
| superm1 | it's in debian main and ubuntu's NEW queue | 22:24 |
| * Sarvatt backs out alllll the changes in rules he just did | 22:24 | |
| AlanBell | evening all, is there anything I can do to add to the information on bug 428769? | 22:30 |
| ubottu | Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769 | 22:31 |
| AlanBell | I just tried Lucid and it is the same there | 22:31 |
| Sarvatt | so there isnt going to be an nvidia-xx-libvdpau-dev anymore then right? looks like the headers in the seperate libvdpau package now.. I need to find the libvdpau package to see if its got vdpau_x11.h too | 22:45 |
| Sarvatt | yep both headers in there upstream, so i guess we need a transitional nvidia-185-vdpau-dev to depend on libvdpau-dev? | 22:46 |
| tjaalton | why? | 22:47 |
| tjaalton | doubt anything build-depends on that | 22:47 |
| tjaalton | and if so, those should be fixed | 22:47 |
| Sarvatt | dunno, is why i was asking :D | 22:47 |
| tjaalton | ok :) | 22:47 |
| superm1 | mythtv build depended on it | 22:48 |
| superm1 | but it's already got it as libvdpau-dev | nvidia...blah blah | 22:49 |
| Sarvatt | ohh superm1, mind if i copy your libvdpau and nvidia 190 drivers to xorg-edgers? didnt see ya had one in your ppa | 22:57 |
| Sarvatt | just so it builds against the newer xorg and doesnt try to remove it installing it | 22:57 |
| superm1 | Sarvatt, grab the libvdpau from lucid NEW instead of the one in my PPA | 22:58 |
| superm1 | you can grab the 190 if you want though | 22:59 |
| superm1 | grab it from ~mythbuntu/trunk-0.22 instead of ~superm1 | 22:59 |
| superm1 | why not just upload to the archive though instead of edgers? | 22:59 |
| Sarvatt | i'm just a lowly ubuntu member :D | 23:00 |
| tjaalton | tseliot said he was working on it | 23:04 |
| Sarvatt | sheesh your package looks great, the others I was looking at still had nvidia-185-whatever in the dpkg hooks and stuff leaving dangling things everywhere | 23:13 |
| Sarvatt | *almost* made it a day without intel crashing | 23:30 |
| Sarvatt | [76508.606525] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error. and execbuf while wedged in dmesg again, can't use current git stuff with 2.6.32-7 either for some reason | 23:32 |
| Sarvatt | yeah I need to blacklist vga16fb in order to boot with KMS on the ubuntu kernels now | 23:43 |
| Sarvatt | failsafe x comes up with a corrupted screen otherwise | 23:44 |
| Sarvatt | must be a side effect of the forced vga16fb loading on 2.6.32-7 and up | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!