[00:19] libv: looks like you managed to stir things up :) [00:22] jcristau: deservedly so too :) [00:22] this is why i am this loved a character [00:22] i do point out where the problem is [00:22] libv, heh [00:23] bryceh: ? [00:23] libv, it makes me wonder if they have a secretary or not. What you're asking for is sort of organization 101 [00:23] bryceh: yeah [00:24] i think bart is secretary? [00:24] jcristau: keithp [00:24] oh [00:24] m [00:24] i know someone who was on the board once :) [00:24] and so i do get some inside info, at least from until a few y ago [00:25] let's say that it's all a bit... interesting [00:25] http://www.x.org/wiki/BoardOfDirectors says keithp's term ended in 2008 [00:25] ah... i think he is still the treasurer then [00:25] something like that [00:26] still, nobody has much of an idea of what is going on [00:26] treasurer but not on the board? how does that work? [00:26] jcristau: there was some construction like that, when someone forgot to do any campaigning and then didn't get voted on the new board [00:27] not sure which year that was [00:28] not sure whether either of you guys know anything of this, but the xfree86-core team got accused of being horribly closed once [00:28] and xorg was going to change all this [00:28] xfree86-core explicitely had nothing to do with money or IP, just was a 90s style project organisation, and people got in after a lot of work on merit only [00:29] Xorg was going to change that, but nobody has any idea about what is happening with the 100-200k usd they have [00:30] well apparently they don't even know how much money they have.. [00:30] yup :) [00:30] fun, isn't it :) [00:30] and then there is this nicol character with his fantastically comical remarks [00:30] i wonder if he even realizes how succinct he is [00:30] yeah he's a lot of fun [00:31] he is like the cuckoo clock in The Pink Panther Strikes Again [00:31] where Clouseau asks "Does your dog bite?" [00:32] jcristau: btw, too bad that you weren't at fosdem [00:32] jcristau: the duck a l'orange at le mirabelle stole my heart [00:32] heh :) [00:33] i was actually at the office on sunday [00:35] and when i had my talk i asked: who built X since modular -- 25 out of 100 hands. Who has built X in the last year or so: 22 out of a 100 hands. Then daniels said something about the build script, and then i asked again: who did this with the build script recently: no hands whatsoever [00:35] and then i explained i haven't done this recently either and instead used your git trees to build debian packages directly :) [00:36] :) [00:37] anholt did one constructive thing though: he told me redhat is already putting libmesa in an .so [00:37] pulled the BS card on everything else, as expected :) [00:41] libv, it's funny because when you file bug reports the bug triagers definitely tell you to go build stuff from git. Maybe not the whole tree but seems like often you end up at least having to do a driver, mesa, libdrm, xserver, etc. [00:42] bryceh: sure, but nobody builds the whole thing anymore, even though from time to time they are almost forced to do so [00:43] i am about to start poking with mesa/dri to see which libdrm version it really depends on, when the drivers are not being built with it [00:43] xserver requirement for instance is just 2.3.0 (Aug 2006) [00:44] this simply because the drivers are not in the same built tree [00:44] s/built/build/ [00:47] bryceh: from my answer, you should probably retain that i do not call for building the whole thing from scratch: i would like to see the ability to build drivers, all parts of it, built against a suitable range of common dependencies [00:48] if this means disabling features and performance: so be it. At least give people the ability to get the basics done without bugs [00:48] as time progresses, these features and performance become available anyway [00:49] i think it's only ubuntu LTS which comes with the 1st version exa today, even debian stable is beyond this [00:51] anyway, i will get larabel to get a real fun and sarcastic survey up on his website once he is back in the states (he is in Koeln atm iirc) [00:52] libv, yeah the hyperfocus on the bleeding edge trips us up from time to time [00:54] bryceh: i was at suse when we were bringing up SLE 11, and we basically got told, with some management from both sides on the phone, to go change our business model by someone who only relatively recently became a driver developer. [00:55] that's how bad it really is. [00:55] heh [00:56] sounds familiar, sadly [00:57] yeah, suse has gregkh telling the same story from inside the company too, also not liked by those parts of the company that try to get a working desktop out [00:58] all just useless discussions where no amount of arguments bring anything :( [00:58] shed paint color arguments [02:53] why do packages like mplayer and vlc, and gst-ffmpeg use shared ffmpeg instead of internal in ubuntu? [02:57] Because internal libraries are harder to maintain. [02:58] bjsnider: In particular, what happens if everything's using internal ffmpeg, and a security flaw is discovered? [02:59] that's an interesting point [03:00] if you go to the mplayer irc channel and tell them you're using shared ffmpeg, 25 people will immediately chime in to tell you you're an idiot [03:00] How do we know what packages are affected? Given that ffmpeg breaks API on occasion, and ABI more frequently, how do we know that dropping in a new ffmpeg version will work? Will we have to backport the fix to a different ffmpeg version for each package using internal ffmpeg? How do we know we've got all the vulnerable packages, etc. [03:00] then if you say that is how it is packaged, it becomes the debian maintainers like siretart that are idiots [03:01] let me ask you this: is siretart an idiot? [03:01] No. [03:01] no, he is definitely not an idiot [03:02] ffmpeg is a curious upstream, really. They don't seem to really care whether what they do is useful for anyone. [03:04] Well, that's not strictly true. But, should you bring up shared libraries, there'll be the guy who claims ELF linkage is braindead-broken, and that he could develop a better library system, and just as soon as he does the world will have ponies. [03:04] I subscribed to the ffmpeg mailing list for a while; it's quite instructive in some ways. There are some very smart coders there. [03:25] bjsnider, in the mplayer community you could say, "The sky is blue", and get called an idiot [03:25] would you like me to tell them that? i'm talking to them right now... [03:25] lol [03:25] "well, you know what bryce harrington said? he said..." [03:30] meh, i don't want to start a flame war, so i'm not going to pass any more messages back and forth [04:02] bjsnider, wanna look at my mouse bug instead? bug #520250 :p [04:02] Launchpad bug 520250 in xorg "steelseries xai laser mouse detected as keyboard, doesn't function" [Undecided,New] https://launchpad.net/bugs/520250 [04:02] i already fixed that bug [04:03] did I file a dupe? [04:03] it was right after i punched out god, beat roger federer in straight sets and singlehandedly won the nba championship [04:03] nice [04:03] all in the same day, i might add [04:04] of course [04:04] fix is in lucid? [04:10] backported to hardy already? [04:12] i created a driver completely from scratch. it is 100% bug free and has features not even present in the device's firmware. [04:12] beautiful! [04:12] * RAOF suspects bjsnider might be talking out an orifice not normally associated with speech. [04:12] I was hoping to be able to write to the lcd on the bottom of the mouse <3 [04:17] actually come to think of it, i can comment on that bug. when you bought it, did you research whether there was a working linux driver for it? [04:19] it claims hid compliancy; been a while since I had a mouse not track at all [04:20] does it work on older kernels/distros? [04:24] can't say that it does [04:25] if it were me, i'd take the hardware back and get something that works [04:26] yes, I'm aware of that [04:26] otherwise you're sitting there hopeing that someone eventually fixes it [04:26] and hope ain't a plan [04:26] that's not a terribly precise summary of my plans :p [04:48] there we go [16:02] What is the name of the program that produces the "Ubuntu is running in low graphics mode" dialog? I want to uninstall it... [16:07] Got it: "x11-common: /etc/gdm/failsafeXServer". Now if only I could disable it without uninstalling x11-common... [16:11] Why does that need to run, anyway? [16:11] # cat /etc/X11/default-display-manager [16:11] /usr/sbin/ldm [16:11] I don't even use gdm... [17:19] alkisg, dpkg-divert is your friend [17:20] cwillu: I was just trying to divert /etc/init/failsafe-x.conf, is that a good idea? [17:20] oh, in that case, don't even divert it, just modify it [17:21] Thanks, I'll try that. [18:08] jcristau, do you know if anyone has looked at autodetection of video devices on the USB bus in the xserver? E.g. displaylink, sisusb, and the like [18:09] no idea [18:11] bryceh: ping [18:12] jcristau, interesting. Not seeing any discussion on the mailing list archive [18:13] verbalshadow, I'm pretty tied up but what do you need? [18:15] bryceh: bad X issue with ati i get white scanlines and a hard lock in lucid [18:15] even remote login fails to get a bt [18:16] verbalshadow, install xorg-edgers and a mainline kernel from kernel team's ppa. If the issue still exists after that, file a bug at bugs.freedesktop.org. If they solve it, post the patch to bugs.launchpad.net and subscribe me to it and we can look at including it. [18:17] verbalshadow, I'm hoping to get new 2.6.33 drm for radeon into lucid, so bugs against the current stuff is not super interesting to me [18:17] bryceh: ok, cool thanks i'll take a stab at that [18:18] verbalshadow, if you're needing workarounds, try: 1) disabling kms, 2) disabling compiz, 3) switching between EXA and XAA [18:18] verbalshadow, btw what's your graphics card? [18:18] we had reports of similar issues on R100/R200 class hw [18:18] i have be using the -7 kernel and that worked until today [18:19] Radeon Xpress 200M [18:20] what changed today? new kernel? [18:20] verbalshadow, if you have time/interest, looking at what piece(s) went in from the -7 to -8 kernel might be interesting [18:20] grabbed all the KDE updates and some gnome stuff as well [18:21] also, maybe this is obvious, but given that you had luck by holding back the kernel, that's a pretty strong clue of a kernel bug, so the kernel team might be more interested in this [18:22] again though, I suspect turning off kms will get things working, and the underlying issue may be solved when we pull newer drm bits into the kernel [18:23] what do i add to the boot line to disable kms? [18:24] verbalshadow, see https://wiki.ubuntu.com/X/KernelModeSetting [18:25] ok [18:25] * bryceh eyeballs the topic ;-) [18:27] bryceh: :P yeah should have look harder, the good news is that i have cnetworkmanager (to easily connect to my wifi) and links installed so i can browse the web [18:51] soo, what are the odds we could get the driver specific drm headers removed from linux-libc-dev? :D adding the replaces: linux-libc-dev in libdrm keeps biting me because linux-libc-dev updates overwrite the libdrm headers [18:56] we either need include/drm/i915_drm.h from libdrm or to backport the overlay stuff into the 2.6.32 kernel to build intel 2.10, they are expecting us to use headers from libdrm upstream though [18:59] or disable the overlay code when you have too old headers [19:02] i kinda feel like having the updated libdrm headers would be better so the driver at least compiles with support for newer features if someone decides to use a newer kernel, since it does do runtime detection of those features and works right if they arent there. just my opinion though and i'll be using xorg-edgers anyway most likely where i can keep that change seperate [19:05] if you're shipping new drm for radeon/nouveau though its going to affect intel, and linux-libc-dev is going to be out of sync anyway [20:02] bryceh: is nouveau's kms already in? [20:04] tseliot, not yet, coming soon [20:04] we got the udev and nouveau-firmware bits in; next up is plymouth and l-b-m [20:04] once those are in I think we can dump the remaining X chunks ourselves pretty easily [20:05] tseliot, how things going in MA? Trust you're not too snowed in? [20:12] bryceh: things are better than the weather forecast predicted [20:12] things are fine [20:18] tseliot, btw I updated the Input Configuration page on the wiki to include docs about udev-based configuration [20:19] bryceh: ah, good [20:21] tseliot: they implemented tag matching stuff that you were suggesting for the xorg.conf.d stuff upstream if ya didn't see it [20:21] Sarvatt, are there some good examples of configuring input (or video) devices using xorg.conf.d? I could docco that while I'm at it. [20:22] where "they" is RH [20:22] Sarvatt: yes, I did the work too but, after seeing that upstream did it, I just reviewed the patch and gave them some feedback [20:22] jcristau: Peter Hutterer. Dan Nicholson also reviewed the patch, as I did [20:22] it was a trivial change [20:23] theres a post on xorg-devel ML where someone brought up the fact removing the note.abi tag from libGL breaks the ordering like you were saying as well, is it a horrible hack to remove that tag so we could leave libgl.so.1 in /usr/lib and not have to have it at /usr/lib/mesa? [20:24] http://lists.x.org/archives/xorg-devel/2010-February/005563.html [20:24] maybe adding that tag to the nvidia binaries would be better. slangasek suggested something similar I guess [20:26] i think the tag could be removed. your libc wouldn't run on a 2.4 kernel anyway. [20:29] jcristau: by disabling TLS? [20:30] no [20:30] we wouldn't have to disable TLS, just remove the tag from getting added from src/mesa/x86/glapi_x86.S [20:31] aah, I see what you mean now [20:31] yes, we could do that [20:36] bryceh: does failsafe mode still use vesa? [20:36] (just asking for debugging purposes) [20:37] yeah [20:37] well src/mesa/x86-64/glapi_x86-64.S would have to have it removed too [20:39] hmm, wonder if its possible to make an xorg.failsafe.conf with both fbdev and vesa (in that order) and have it move on to the second device section if the first fails like how the auto configuration works [20:40] ok [20:40] Sarvatt, my ubuntu 9.10 is freezing. Sometimes everything freezes, can't move mouse etc. have to do hard reset. What can this be? [20:40] i havent been able to work out adding the check for a KMS fb in failsafeXServer [20:41] Sarvatt: what happens with vesa+kms? [20:41] its garbled and doesnt work [20:41] hrm [20:41] is it supposed to do that? [20:42] i think it tries to open up a 800x600 display inside the full rez one because you can partially see things [20:42] Sarvatt: do you mean when either radeon or intel kms modules are already loaded? [20:42] or nouveau yeah [20:42] right [20:42] grep drm /proc/fb [20:42] or some such [20:42] i tried adding a check for inteldrmfb nouveaufb or radeondrmfb to the failsafeXServer script but it didnt work [20:42] so does checking lsmod fail? [20:43] lsmod doesn't tell you what you want to know [20:43] yeah thats what i tried - if [$(grep -q -E '(nouveau|drm)fb' /proc/fb)]; then [20:43] you don't want [$( [20:43] just if grep -q foo; then [20:46] ohhh hmm [20:47] how can I force a failsafeX session again to try it? my old bugs I was abusing to do it before were fixed :) [20:47] break the config [20:49] * Sarvatt switches driver to nouveau and reboots with this - http://pastebin.com/f58621c19 [20:50] why is fbdev better than plain vesa? [20:50] fbdev works with a KMS fb (and full resolution at that) and vesa doesnt [20:50] ach :) [20:52] Sarvatt, did that boot up ok? [20:55] darn it just fails with no screens found if i change the driver, how should i break the xorg.conf? [20:55] bryceh: trying to force a failsafe X session still [20:56] hmm maybe if i just run failsafeXServer directly [20:56] I do "echo 'foobar' >> /etc/X11/xorg.conf" to do testing [20:56] basically, any garbage in xorg.conf should pop it into failsafe mode [20:57] but yeah if you shut down gdm you can run failsafeXServer directly [20:57] right [20:57] keep an eye out for generating stray X processes (do `pkill X` once and a while) [21:05] nope it still uses vesa [21:05] when it tries to start up with vesa I get the grub graphics on the screen at the start all garbled [21:09] Sarvatt: ouch, so it's broken so early in the boot process [21:09] I'm not sure as to whether we want to do something in the initramfs about it [21:10] well grub is using vesa, guessing it just dumps that stuff back up on the screen when you try to use vesa again [21:11] cjwatson would be the right person to ask about it [21:14] changing /etc/X11/xorg.conf.failsafe from vesa to fbdev works great for failsafeX [21:24] might have hit a bug with plymouth while i was screwing around there - [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object [21:32] grep -q -E '(nouveau|drm)fb' /proc/fb && echo yes [21:32] yes -- that works at least, its just how to hook it in the script [22:03] anyone ever say that it's crazy to use plymouth (when its expected to be rewritten for libkms soon) and/or bring in nouveau in when its api is expected to get completely busted around release time for a lts? :D even radeon KMS is sketchy, an opt-in lbm module for it with KMS enabled and the normal one having kms disabled might be a better option [22:06] if you do make a lbm for radeon keep in mind it needs firmware not in linus' tree (non-free license) for r600-700 irq support and doesn't even start up right without the firmware last I checked [22:07] Sarvatt: airlied was advising to either use the 2.6.33 radeon bits or disable kms so i suspect some decision will be mad along those lines for lucid [22:08] yeah I'm trading emails with apw and sconklin on this [22:08] made, even [22:08] yeah I saw that in the radeon 7500 bug [22:09] btw jcristau, did you want to push main: move config_init() after InitInput() to server-1.7-nominations? [22:09] it's in my todo list to get this squared up but I need more info at this point... so if you have opinions shoot them at me and I'll add them to the pot [22:09] Sarvatt: no [22:09] Sarvatt: 1.7 doesn't have the udev stuff so should be fine without it [22:09] ah its related to udev which isnt in 1.7 branch isnt it [22:10] I dont know, airlied was saying radeon wouldn't get loaded right by udev if you had KMS enabled in the kernel config but booted with modeset=0 but we didnt see that in karmic [22:11] hal uses a timer to enable stuff, so it doesn't fire until the main loop. so it's not affected. [22:11] we changed the default module option to modeset=0 there [22:11] ah thanks for the clarification, was just wondering because i'm getting the patch hooks set up for the 1.7.5 release soon [22:16] btw did you see that updated efifb patch jcristau? I *really* need to get kernel-package set up again to build my own kernels [22:16] yeah didn't work either here [22:16] ah darn [22:19] do you use kernel-package to build your kernels? how do you make it add a build an initrd hook if so? [22:19] make; sudo make install modules_install; sudo update-initramfs -c -k $mumble; sudo update-grub [22:22] ah you do it the normal way, i'll just keep using kernel-package and build the initrd myself because i build it on my vps (takes a year on this atom cpu) [22:22] make deb-pkg is supposed to work i thought [22:30] oooh gcc-4.5 is in experimental, I want to try building the kernel with -march=atom [23:13] rebooted into 2.6.33 and nouveau only works at 800px. [23:16] if you mean -13 that's probably because there are no lbm for -13 built yet [23:17] (and I have no idea how to build them myself so no reboots for me ;) ) [23:17] correction: 2.6.32-13-generic [23:17] you can reboot, just choose -12 kernel [23:17] ya, I know