[01:15] nice! [01:19] I guess it was the XvMC stuff that was the problematic one in the end looking at it not just play Xv overlay [01:22] Fortunately, no one cares about XvMC. [01:26] lots of people care if its disabled even if it's basically useless, you'd be surprised how much email I get about noting I disable it in xorg-edgers in the changelog on karmic because of the old libxcb :) [01:29] I'm surprised people care about MPEG2 decoding hand-off so much. I remember watching the gallium XvMC development having trouble with the setup & teardown overhead being more than what it'd take for the cpu to actually just decode the streatm :) [01:31] they probably don't know, they probably just think it'll make their pr0n look better [01:32] were they testing with the right source for it to matter? it makes the most difference with huge interlaced mpg2 videos and the deinterlacing quality is better which is pretty important on a HTPC [01:32] but for like a progressive source it makes almost no difference [01:34] ...The other problem they were running into is that nouveau didn't have a memory manager then, so huge mpeg2 videos would ENOMEM :) [01:36] * bryceh documents quirking in KMS-land - https://wiki.ubuntu.com/X/Quirks [01:39] RAOF, for blacklisting nouveau so it uses -nv, do we just put 'blacklist nouveau' in /etc/modprobe.d/blacklist.conf ? [01:42] does nouveau require blacklisting to use -nv? I still haven't tested that, wifes laptop HDD now says failure imminent so shes back on my nvidia one :( [01:44] anyone familiar with libpciaccess know if pci_device_has_kernel_driver checks if KMS is in use or just if there is a kernel module loaded for the device? [01:47] bryceh: For some reason in my testing -vesa claimed the display rather than -nv unless I manually listed nv in xorg.conf. [01:48] That's certainly a fine way to blacklist nouveau, though. [01:48] ok stuck docs here https://wiki.ubuntu.com/X/KernelModeSetting === rickspencer3_ is now known as rickspencer3 [02:01] tjaalton, ok looks like http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/PkgList/versions_current.html is automatically updating once again [02:02] weird cron issues [02:02] tjaalton, let me know if you spot any troubles, I suspect I won't be watching it too closely henceforth [02:14] wow, death to vga16fb [02:14] turns on the suspend/resume problems I'm having now with the blob go away when I blacklist it again :D [02:14] huh [02:15] did you see the patch on kernel-team@ about it? [02:15] 11 suspends in a row with it blacklisted, second resume hung after removing the blacklist [02:15] nope not yet [02:15] heya rafiyr [02:16] hi [02:16] how are you [02:16] good, just finishing up a few bits before heading up to seattle for the weekend [02:16] (my sister's in a play) [02:17] going for fun? [02:17] that fix on the mailing list wont affect the blob [02:17] take that as a yes [02:17] Sarvatt, ok [02:17] rafiyr, :-) [02:18] I'm heading up to see some family too. [02:18] so its basically, do you want suspend support or do you want a text splash up for 1 second at this point with the blob.. [02:18] Wish I was better at reading code in the car. [02:50] Sarvatt: Oh, sweet. More reasons to hate on vga16fb :) [03:32] bryceh: About the Intel lid quirks - I'm pretty sure I've seen an upstream commit that's basically “Stop using the lid status for lvds, it breaks too often” [03:33] So that particular class of quirks might be easily solved. [03:36] RAOF: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=6e6c822868f113dabe3c33bdd91e883cc28fa11b [03:37] Sarvatt: :) [03:38] FWIW, nouveau also has a variant of that approach. [03:41] i was gonna change that part on the wiki but it was actually talking about other bugs that i think might still need quirks [05:57] bryceh: ok, thanks! [05:57] btw, looks like the autoconfig patch was not guilty for the crash-on-exit bug.. :) [05:58] only happens with MALLOC_PERTURB_ set, and with vanilla xserver [06:49] hmm, trying syncpackage with -sis [06:52] basically it just downloads the source and runs debsign on it, the it's jut a dput away of being "synced" [06:53] *just [06:56] tjaalton, heh [06:57] so that's all it's been all this time? [06:59] bryceh, thanks for the feedback on MT :-) [07:00] ara, sure; hope it helps [07:01] bryceh: yeah, so it's nothing to worry about imo [07:01] if you meant the crasher [07:04] tjaalton, no I meant, that's all we've had to do to sync a package? [07:04] I always assumed it involved more dials and levers [07:04] bryceh: yeah, quite simple :) [07:05] you still need to feed the url to it, and answer 'n' when it asks to use the original signature [07:05] so there are some quirks left [07:05] but I guess those are known and worked on [07:05] +being [07:16] mm [07:21] new synaptics (1.2.2) [09:40] ok, vmmouse and joystick inputclass configs added and uploaded to my ppa, only evtouch to do [09:45] hmm, the tag matching is not properly documented in the xorg.conf manpage, nothing mentioned that the backend needs to set ID_INPUT.tags for MatchTag to work [10:14] tjaalton: is the new mesa release a bug fix release? [10:14] tseliot: yes [10:14] we have a snapshot of that branch already [10:15] tjaalton: ok, so we should just wait for upstream to release it, right? [10:17] tseliot: yep, I'll ping debian-x to upload it, or we can dput it as -0u1 if they're busy [10:19] tjaalton: ok, good [10:19] tseliot: bug 546933 [10:19] Launchpad bug 546933 in xorg-server "FFE: xorg.conf.d/inputclass backport" [Undecided,New] https://launchpad.net/bugs/546933 [10:19] https://edge.launchpad.net/~tjaalton/+archive/test/+packages [10:20] * tseliot has a look [10:21] the build queue is hopelessly long though [10:22] but synaptics and evdev works with the previous set of packages [10:26] lunch -> [14:14] hello [14:14] I'm affected with the following bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/545289 [14:15] Ubuntu bug 545289 in linux "[RV515] XOrg malfunction - open radeon driver (X1450) - graphics flickering all time in lucid 64bit [Needs pll quirk]" [Undecided,Confirmed] [14:15] what does the "pll quirk" stand for, and how is it done? [14:23] is everything on the screen being upside-down and backwards a known bug? [14:23] (lucid) [14:25] (eee 901) [14:25] yes [14:25] wrong libGL [14:25] excellent [14:26] how do I get the right libGL, and which libGL do I have? [14:26] dunno [14:26] probably a poulsbo in it? [14:26] no [14:26] hell no [14:26] :) [14:26] 945GME [14:27] check Xorg.0.log [14:27] or pastebin it [14:27] I can't atm, maybe when I get to work [14:27] what am I looking for in xorg.0.log? [14:28] what it says after loading libglx [14:28] likely nvidia [14:29] solarion: "ldconfig -p | grep GL" and "update-alternatives --display gl_conf" should show what's wrong [14:29] xorg foundation [14:29] indeed [14:29] maybe you switched between drivers by simply changing your xorg.conf. This is not the right way to do it [14:29] glcore is nvidia [14:29] effing nvidia [14:30] no [14:30] I have no xorg.conf [14:30] the entirety of what I did was update yesterday [14:31] how do I set back to mesa? [14:31] please follow this paragraph "Problem: Need to manually review/tweak alternatives settings" here: https://wiki.ubuntu.com/X/Troubleshooting/NvidiaDriverSwitching [14:31] why did it switch on my from just doing an update, though? [14:32] good question [14:32] I'd done *nothing* manually, and I've not selected *any* proprietary drivers [14:32] this is also a pretty fresh install from beta 1 [14:32] check dpkg.log [14:34] what specifically am I looking for? [14:35] oh, 03-23 had update-alternatives --force with GL [14:35] see what it installed [14:35] yes [14:35] nvidia-current seemed to force GL [14:35] nice :) [14:35] 195.36.15 [14:35] -0ubuntu1 [14:35] what pulled it in? [14:36] what pulled in nvidia-current? [14:36] yes [14:36] I've no idea [14:36] as a dependency [14:36] I'm guessing that's an apt thing that I always forget. :) [14:37] apt-cache rdepends [14:37] or use aptitude [14:38] nvidia-glx-185 [14:38] had that installed? [14:38] eh, I'm not sure where this is getting pulled in [14:39] are you aware of that bug? [14:39] http://bugs.freedesktop.org/show_bug.cgi?id=26394 [14:39] Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,New] [14:39] no [14:40] modealiases seems to have pulled in nvidia (first reference in dpkg.log) [14:40] nvidia-173-modealiases [14:40] those are installed by default [14:40] the don't depend on nvidia-current [14:40] they [14:40] oooh [14:40] I think I know what happened. [14:40] hahahahah [14:41] It's when I pulled the packages from my workstation (which has nvidia) [14:41] I'm such an idiot [14:41] proven ;) [14:41] verily [14:41] use pkgsync if you need to do that [14:41] and list nvidia in mayhave [14:42] not heard of pkgsync [14:42] I was using the default tools (synaptic) [14:42] install and see [14:42] lemme kill this effing nvidia driver [14:42] it's a tool to keep a predefined set of packages installed [14:42] nothing more, nothing less [14:42] hmmm [14:43] so if you want to keep the same set of packages, copy the config around [14:43] but keep hw related stuff in mayhave [14:43] too bad that's not more automatic [14:44] what do you mean? [14:44] I mean, hw drivers are clearly hardware-dependent and a separate category from libs, which are separate category of package from apps [14:45] well there aren't too many of them anyway [14:45] too many of which? [14:45] might as well handle them by hand [14:45] hw drivers [14:46] that you need to install [14:46] sure, but it sucks more than it needs to. :) [14:46] wfm [14:46] tseliot, well while you are sorting out that fglrx handler in jockey, there's a few commits that need cherry picking from trunk of jockey to fix some other bugs too [14:46] pitti should be able to point them out if you aren't sure [14:46] until you forget something one day and have to put the pieces back together [14:47] "wfm" isn't an answer to "it sucks more than it has to" [14:47] it was just a suggestion [14:48] I am a big fan of automatic things doing tedious things for me [14:48] like this one. :) [14:48] superm1: maybe we should discuss this with pitti in, say, #ubuntu-desktop? [14:48] Anyhow, thanks a lot for the pointer. I'll check out pkgsync [14:49] * solarion heads to work [14:50] tseliot, sure === Sinnerman is now known as Cobalt === Sinnerman is now known as Cobalt === Sinnerman is now known as Cobalt [17:02] gonna start doing something crazy on edgers - http://sarvatt.com/downloads/patches/exa_backport_to_1.7.6.patch [17:06] buh Applying patches...Patch 111_armel-drv-fallbacks.patch does not exist === Sinnerman is now known as Cobalt === seb128_ is now known as seb128 === radoe_ is now known as radoe [20:08] ton of new tools in intel-gpu-tools now, just uploaded a new one to edgers. intel_error_decode looks nice :) [20:09] wow intel_reg_dumper doesn't hang the system anymore! \o/ [20:53] http://lists.freedesktop.org/archives/xorg/2010-March/049749.html [21:04] hum nvidia announced deprecation of xf86-video-nv [21:06] wow [21:12] wow, so no more 2d source code for newer nvidia chips [21:20] they said that it would be better to use the vesa driver, which is true and beyond question [21:20] didn't say a word about nouveau ;) [21:21] nouveau has a different purpose than nv did [21:21] nv was just for an initial x screen so users could install the blob [21:21] yep [21:21] nouveau is a replacement for the blob [21:22] vesa does better that nv was supposed to be for === Sinnerman is now known as Cobalt [21:50] bjsnider: nv supported dual head. vesa not so much. [21:51] did you need dual-head to install the blob? [21:52] who said i cared about the blob [21:53] nv's purpose is to provide an initial x screen to facilitate installation of das blob [21:53] well that's what nvidia wants it to be, yes [21:53] evening [21:54] anyway, we figured out a patch to the gnome-shell that fixes all nvidia issues