[01:22] RAOF: got a nouveau-kernel-source that works on 2.6.32 on a PPA by any chance? [01:22] or does the one in edgers work? [01:24] something tells me this 185.36 nvidia blob isn't new enough to support xserver 1.7+.. [01:29] yep we're gonna need to upgrade the nvidia blob to 190.xx at least for xserver 1.7 === mac_v_ is now known as mac_v [13:16] hi all [13:16] Does anyone know if someone is working on a KMS vesa driver? [13:16] ask ajax on #xorg-devel [13:16] This would make KMS available for everybody, at least without acceleration :) [13:16] thx [13:16] but don't hold your breath [13:17] Isn't it supposed to be the easiest integeration since it has no acceleration? [13:22] Does current fglrx not work with 2.6.32 or is it a problem with the Ubuntu kernel? [13:33] it never is a kernel problem :) [13:34] Because I have read somwhere else that 2.6.32 is supported through fglrx [13:36] I just was interested how fglrx deals with radeon KMS in lucid [13:36] *were [13:37] i guess badly, but then it's fglrx so that was an easy guess [13:38] I don't think the blobs will/can ever support kms [13:39] Yes, I know, I just wanted to know if there is a problem when using radeon and switching to FGLRX [13:39] I am only using FGLRX because of Powerplay [13:40] 2D acceleration is very poor and XV still tears [13:40] I have to use OpenGL video output, this driver is a mess [13:40] but OpenGL doesn't tear only if vsync is forced and no composite is used [14:01] ciao [17:12] unggnu had some good points here though, about fglrx [17:13] proper radeon KMS support needs early loading of radeon, and fglrx does not like radeon I guess [17:13] so it has to decide in early boot whether to for radeon or fglrx [17:14] same thing with nvidia [17:16] don't know how to deal with that.. [17:17] the closed drivers already deal with moving libGL.so.1 and libglx.so away [17:17] they can add radeon.ko and nouveau.ko [17:17] hmm, right [17:18] does fglrx install its own libGL? [17:18] of course [17:18] and diverts the mesa one [17:20] so they should just install a do-not-load-radeon modprobe blacklist then, or move the module but that's difficult since it's at a new place for every kernel [17:21] and blacklist probably don't stop modalias loading [17:22] it does [17:22] wasn't there some talk about a fglrx.ko which could coexist with radeon.ko? [17:23] that's its whole point actually [17:23] also, modinfo radeon|awk '/^filename:/ { print $2 }' [17:23] the point of blacklists? [17:25] jcristau, your command lists the current location of the radeon.ko. but if you upgrade the kernel, fglrx will have to move the new one. [17:25] yes, the point of blacklists is to prevent automatic loading [17:25] true re: the modinfo thingy [17:26] I thought the blacklist was dealt with by modinfo [17:26] modprobe [17:26] yes :) [17:26] udev uses modprobe -b [17:26] oh does it [17:26] which doesn't do anything if the module is blacklisted [17:27] so that's why it is so slow :) [17:29] where does udev do the autoloading? [17:30] /lib/udev/rules.d/80-drivers.rules [17:35] so why does this not load the radeon module? [17:35] do you have CONFIG_DRM_RADEON_KMS=y? [17:35] yes [17:35] dunno then [17:38] sudo modprobe -b pci:v00001002d00005653sv00001025sd00000070bc03sc00i00 [17:38] FATAL: Module pci:v00001002d00005653sv00001025sd00000070bc03sc00i00 not found. [17:39] modinfo radeon should list some modaliases.. [17:39] it does list my card [17:40] maybe check how /lib/modules/`uname -r`/modules.alias is generated [17:41] funny enough my card is in there too [17:42] weird. [17:43] I think the kernel does tell udev about it [17:43] does not [17:47] tormod: udevadm info --export-db shows the modalias? [17:48] yes [17:48] but that is now, after radeon has been loaded "manually" [17:49] oh, it's not there before? [17:49] I don't know :) [17:49] i'll try and see what happens when 2.6.32 hits sid [17:50] week old kernel release, in Debian? :) [17:50] maybe I should try this before loading radeon [17:52] well, we're at -rc8, and 18:18 < CIA-3> waldi * r14741 /dists/trunk/linux-2.6/debian/changelog: debian/changelog: Prepare to release (2.6.32-1). [17:56] brb [18:16] must be something with modprobe's alias resolving [18:27] for instance, modprobe --resolve-alias pci:v00001389d00000002sv*sd*bc*sc*i* -> applicom [18:28] modprobe --resolve-alias pci:v00001002d00005653sv*sd*bc*sc*i* -> (nothing) [18:32] omg plz forget everything I said while I go hiding, I just discovered an old modprobe file I had put there for debugging some stuff months ago... [18:33] hah. [19:04] so many problems with intel now :( this happened 3 times today freezing x - http://paste.ubuntu.com/336069/ [19:08] ok, I have been spreading a fair amount of disinformation about radeon KMS, but the initialisation race can still be a problem. Here, kms can take up to 1.7s to initialise and nothing stops X from starting before it is ready. [19:08] I wish upstart could log events with timestamps [19:09] there isnt a wait after loading it in the initramfs [19:09] ? [19:09] Sarvatt, not for radeon, it is loaded later [19:09] i don't think it should be loaded in the initramfs [19:17] hooks/framebuffer packs in all gpu and agp modules and it waits for fb0, dri/card0 and fbcon to load as well before moving on from what I see, I'm probably misunderstanding though [19:20] looking at initramfs-tools-0.92bubuntu55 which is waaay different than debians [19:22] this is only in use if you boot with video= right? [19:23] uh no [19:31] http://paste.ubuntu.com/336085 [20:10] hi, would bug 491483 be SRUable? [20:10] Launchpad bug 491483 in xorg "Since failsave-x was enabled in karmic it starts if gdm is disabled and kdm is used" [Undecided,Confirmed] https://launchpad.net/bugs/491483 [22:10] yeaaah I give up on attempting to package i915 gallium tonight :D [22:44] hmm... xserver-xorg-video-nouveau: Depends: linux-nouveau-modules which is a virtual package [22:46] did I manage to hit the PPA just while it's being updated? [22:47] (the PPA being xorg-edgers) [22:47] nope, sounds like it was synced with debian instead of ubuntu [22:48] oh [22:49] so the dependency should be on nouveau-kernel-source? [22:49] just checked and the one waiting to build uses linux-nouveau-modules too, i uploaded that 10 hours ago.. [22:49] yeah its linux-nouveau-modules in debian [22:50] i'll upload a new one but it'll be a looong time until it builds at the rate ppa builds are going [22:51] alright [22:51] but I just downloaded the source package, which does have Depends: nouveau-kernel-source in debian/control [22:51] weird [22:52] oh? what version is it? [22:52] are you on karmic or something? [22:52] oh, never mind, wrong version [22:52] I didn't put in the deb-src line for the ppa [22:54] I'll see if I can fix it locally in the meantime... thank you for the help [22:55] no worries, updated source should be up in about 5 minutes if not, just finished uploading it [23:00] hmm, is a xbox 360 controller supposed to use -joystick? shows up as a mouse here [23:06] hmm... the package compiled, but didn't work too well: "drmOpen failed" [23:07] http://pastebin.com/f595ad9b5 [23:12] theres no dri for it [23:13] trying to remember what options i used with it, page i wrote it on has changed :( [23:14] well nouveau needs the drm [23:14] but he didn't paste dmesg, so.. [23:27] ahh maybe he didnt force KMS on with the module option, i remember having that same problem now [23:27] found my old dmesg from it working http://sarvatt.com/downloads/nouveau-kms.txt [23:28] i couldnt start x without KMS but that was like 6 months ago [23:29] same exact gpu though [23:33] well... got a little further... the nouveau kernel module loads fine, but then the system locks hard when gdm starts [23:34] try booting with nouveau.modeset=1 added to grub johanbr [23:34] alright, I'll give that a try, thanks again [23:35] i had the same problem on the same card 6 months ago when I was messing with it, had to use KMS to get it all working [23:36] should probably ship a modprobe.d rule for nouveau with the package [23:37] Sarvatt, johanbr, if the new nouveau dep is wrong, just use my old package [23:37] that dep is most of the change anyway [23:38] I just replaced it with nouveau-kernel-source and rebuilt [23:40] heres what my logs looked like with KMS, when i tried without KMS it got stuck trying to restart gdm constantly http://sarvatt.com/downloads/nouveau-kms.txt [23:41] nvidia didnt have a blob that worked on xserver 1.7 back then after the video abi changed, at least 190.xx and up works now [23:43] i'll try it out right now, purging 195.22 i manually installed [23:47] about to do the same [23:51] i cant even build the kernel module [23:51] /usr/src/linux-headers-2.6.32-6-generic/arch/x86/Makefile:81: stack protector enabled but no compiler support [23:52] think ccache is screwed up on this machine [23:54] nouveau sets a initramfs rebuild trigger before it makes the module? [23:55] then it does it again after the module is built, ah [23:59] yep it aint working right now: http://sarvatt.com/downloads/gallium.txt