[01:41] <LLStarks> yo
[01:56] <bryce> heya LLStarks
[01:57] <LLStarks> karmic kernels are in the repos.
[01:57] <LLStarks> kms disabled by default...
[01:57] <LLStarks> D:
[01:57] <LLStarks> brb
[02:53] <LLStarks> finally got kms to boot to x
[03:23] <bryce> LLStarks: how'd it go?
[03:23] <LLStarks> nice.
[03:23] <LLStarks> plymouth doesn't want to play nice.
[03:27] <bryce> LLStarks: would you mind writing up notes on what you had to do to get it going?  it'd give us a headstart on getting it all enabled and set up by default
[03:27] <LLStarks> i915 modeset=1
[03:27] <LLStarks> in /etc/modules
[03:28] <LLStarks> 2.6.30-1 kernel
[03:28] <bryce> did X pick up the mode properly?
[03:28] <LLStarks> latest edgers ppa drivers
[03:28] <LLStarks> i can't tell. the fb console looked right
[03:28] <LLStarks> but i still saw blinking
[03:28] <LLStarks> also, the boot is 75% done by the time it gets there
[03:29] <LLStarks> *gets to enabling kms
[03:30] <LLStarks> also, the karmic forums mention this: http://ubuntuforums.org/showpost.php?p=7166503&postcount=8
[03:30] <LLStarks> CONFIG_FB_UVESA=y
[03:30] <LLStarks> CONFIG_FB_VESA=y
[03:30] <LLStarks> can't be modules
[03:30] <LLStarks> have to be compiled in
[03:30] <bryce> mm
[03:30] <bryce> yeah those look like kernel config params
[03:30] <LLStarks> sarvatt is doing the intel drivers for the ppa now.
[03:30] <LLStarks> kms enabled.
[03:31] <LLStarks> as opposed to tormo disabling them
[03:31] <bryce> cool
[03:31] <bryce> which ppa?
[03:32] <LLStarks> edgers
[03:32] <bryce> ok
[03:34] <LLStarks> for manual kms. modprobe i915 modeset=1
[03:34] <LLStarks> also, /etc/modprobe.d/i915-kms is now present.
[03:35] <LLStarks> option i915 modeset=1
[03:35] <LLStarks> is the only line
[03:35] <LLStarks> also, the intel team is forcing the issue with uxa-only
[03:35] <LLStarks> latest commits have stripped out exa and xaa
[03:36] <bryce> yeah I know about that
[03:37] <LLStarks> also, xv overlay is gone.
[03:37] <bryce> I'm concerned that's going to paint us into a corner if we want to ship something newer than 2.7
[03:37] <LLStarks> for kms+uxa
[03:37] <bryce> hrm
[03:41] <LLStarks>  and i just froze...
[03:41] <bryce> lovely
[03:42] <LLStarks> bryce. uxa is not ready for karmic as things stand.
[03:42] <LLStarks> btw, is there anyway to unfreeze x if it happens?
[03:42] <bryce> not usually
[03:42] <LLStarks> i'm using exa right now.
[03:42] <bryce> however there have been cases where I've been able to unfreeze by killing the process which causes it
[03:43] <LLStarks> mplayer in my case.
[03:43] <LLStarks> but i don't have a spare machine for ssh
[03:43] <bryce> in one case, that was alarm-clock, in another case you could kill compiz and get back
[03:43] <bryce> in that case unless vt switching works, you're power cycling
[03:44] <LLStarks> what's causing these crippling crashes?
[03:44] <bryce> or play with sysrq combinations
[03:44] <bryce> careful to distinguish between "freeze" and "crash" - different things
[03:44] <bryce> what causes freezes is usually something poked into the GPU improperly
[03:44] <LLStarks> alt+prntscrn+b is the only thing that works
[03:44] <LLStarks> and that reboots.
[03:45] <bryce> I wrote a lengthy guide about freezes in wiki.ubuntu.com/X/Troubleshooting/Freezes if you're interested in the gory details
[03:46] <bryce> also you can install the intel-gpu-dump tools and get gpu dump info that presumably reveals why it froze
[03:46] <bryce> however my experience so far with the tools has been a mixed bag
[13:49] <maco> Know how a few days ago I said X kept doing the thing where it freezes but the mouse still moves? Turned on greedy, and it's perfectly stable now.
[16:53] <jbarnes> bryce: you may be able to just override pScrn->virtualX & Y in preinit instead
[17:43] <bryce> jbarnes: ok
[17:47] <Ng> is there any particular reason not to always make the virtual be its maximum size for that hardware?
[17:48] <jbarnes> Ng: yes, on some hardware it's huge
[17:50] <Ng> so that'd be pointlessly stealing RAM?
[17:50] <Ng> I thought I read somewhere that the maximum on Intel hardware is only 4096x4096 on newer chips
[17:50] <hyperair> Ng: that's a mesa bug
[17:51] <Ng> oh :)
[17:51] <hyperair> Ng: there's a patch floating around that never made it into mesa that bumps up the limiter to 80somethingx80something
[17:51] <Ng> heh
[17:52] <hyperair> eh wait
[17:52] <hyperair> hmm
[17:52] <hyperair> was it 4096 or 2048 now
[17:52] <hyperair> lemme get that patched mesa out and give it a go
[17:53] <Ng> 5120x3200 would be the size of 4 30" monitors by my calculations, so that would seem to my naive guesswork, to be a reasonable maximum at the moment
[17:53] <Ng> (I don't know how you'd connect more than 2 to most intel driven hardware, but at least it means you can arrange them in either axis)
[18:08] <hyperair> LVDS + VGA + HDMI?
[18:08] <hyperair> that's 3
[18:08] <hyperair> i don't see how you could get a fourth
[18:08] <hyperair> wait, does intel even have hdmi?
[18:09] <hyperair> or was HDMI for audio? i can't remember
[18:09] <jcristau> Ng: you can connect more, but you have 2 crtcs, so the rest has to be cloned.
[18:09] <hyperair> bah
[18:18] <hyperair> 2 crtcs?
[18:25] <Ng> I only own three things with intel chips, but none of them have more than 3 connectors
[19:21] <nagappan> hi
[19:21] <nagappan> is there any issue with Ubuntu 9.04 having 2 nVidia card ?
[19:21] <nagappan> the installer doesn't come up, if we have 2 cards
[19:21] <nagappan> it gets struck when the X comes up
[19:21] <nagappan> later, tried removing a card and installed Ubuntu 9.04, after installation, when I plugin the card, the second card is not being detected
[19:22] <nagappan> both the cards are same nVidia chipset
[19:22] <nagappan> I mean the lspci is listing only one card
[19:46] <bryce> nagappan: in general multi-cards is not supported in ubuntu
[19:46] <bryce> nagappan: however in theory the -nvidia driver can do it, but I've never messed with it myself.
[19:47] <nagappan> bryce, ok
[19:55] <nagappan> bryce, I also noticed this in /var/log/messages
[19:55] <nagappan> Apr 28 20:07:53 xerox-1-2-dhcp77 kernel: [   21.552051] Xorg[3413]: segfault at fffffffffffffff8 ip 00007f0804551894 sp 00007fff0c75f280 error 4 in ld-2.9.so[7f0804543000+20000]
[19:56] <bryce> dunno that one
[19:58] <Unggnu> hi all
[19:59] <jcristau> fffffffffffffff8 is a fun address.
[19:59] <Unggnu> Does anyone know a howto to test kms with Jaunty? Karmic doesn't seem to have the new packages.
[19:59] <tseliot> nagappan: maybe try with "sudo nvidia-xconfig --multigpu=On" (type man nvidia-xconfig for further information)
[20:00] <nagappan> tseliot, sure, let me try now, thanks :)
[20:00] <nagappan> bryce, will this be of any use ? http://pastebin.com/d79e70d92 dmesg output
[20:00] <nagappan> I noticed this line
[20:00] <nagappan> [   10.674454] ck804xrom ck804xrom_init_one(): Unable to register resource 0x00000000ffb00000-0x00000000ffffffff - kernel bug?
[20:00] <jcristau> nagappan: in general debugging a blob will be pretty hard.
[20:01] <nagappan> jcristau, ok
[20:01] <jcristau> (read: impossible)
[20:07] <nagappan> tseliot, there is no such option with nvidia-xconfig, atleast on this Ubuntu 9.04 64-bit machine
[20:08] <tseliot> nagappan: "--sli=Auto" should work
[20:08] <nagappan> note, the same card with same configuration is working with Ubuntu studio rt kernel !
[20:08] <nagappan> tseliot, let me check
[20:09] <nagappan> tseliot, option --sli not recognized
[20:09] <tseliot> nagappan: what driver are you using?
[20:09] <nagappan> tseliot, nvidia driver
[20:09] <tseliot> what version
[20:10]  * nagappan checking
[20:10] <nagappan> tseliot, nvidia-installer:  version 1.0.7  (buildmeister@builder58)  Fri Apr 17 00:40:22 PDT 2009
[20:11] <nagappan> tseliot, nvidia-settings:  version 1.0  (buildd@crested)  Sun Feb  1 20:25:37 UTC 2009
[20:11] <tseliot> nagappan: didn't you install it using Ubuntu's repositories?
[20:11] <nagappan> tseliot, no
[20:12] <nagappan> tseliot, I tried with the NVidia installer, let me try with Ubuntu version now
[20:12] <tseliot> nagappan: no, please don't
[20:12] <nagappan> tseliot, :)
[20:12] <tseliot> or you'll break your system
[20:13] <tseliot> sudo sh name_of_the_installer --uninstall
[20:13] <nagappan> tseliot, sure
[20:13] <tseliot> and uninstall the driver from the installer first
[20:13] <nagappan> tseliot, ok
[21:00] <bryce> jbarnes: hrm, i've been poking the virtualX/Y values in preinit but seems to not affect things
[21:00] <bryce> jbarnes: at least, I see no change in xrandr's maximum values
[21:00] <jbarnes> oh hm
[21:06] <tseliot> bryce: what happens?
[21:06] <tseliot> with the virtual values
[21:06] <bryce> tseliot: xrandr reports 1280 1280 (the stock defaults for this hw)
[21:06] <jbarnes> bryce: are you setting it before xf86initialconfiguration gets called?
[21:06] <bryce> instead of 2048 2048 that I'm trying to poke
[21:07] <bryce> jbarnes: I've tried it several places in the function, including up at the top right after i830_kernel_mode_enabled()
[21:07] <jbarnes> looks like you might actually have to poke pScrn->display->virtualX/Y too
[21:07] <bryce> one thing I've found is I can only do the I965 test after about halfway through the routine, otherwise it segfaults, but that's a secondary issue
[21:08] <nagappan> tseliot, sorry was away for lunch, just back, trying now
[21:08] <jbarnes> yeah the pci stuff has to happen first otherwise you won't have a pdev to check
[21:15] <bryce> jbarnes: no go
[21:16] <jbarnes> bryce: arg I guess there's not an easy way to do it
[21:16] <jbarnes> bryce: another way of achieving the same thing might be to round up the memory allocation though in the 965 case
[21:17] <jbarnes> where we allocate the front buffer you could make sure it's at least 2048 wide
[21:17] <bryce> that's in i830_mem.c?
[21:17] <tseliot> i830_allocate_framebuffer ?
[21:17] <jbarnes> wouldn't change the virtual or xrandr output but would affect memory laytout the same way
[21:17] <jbarnes> yeah
[21:34] <mnemo> i've just built mesa with a custom patch that upstream wanted me to try... to install it I tried doing "dpkg -i *.deb" but since all the generated DEBs depend on each other I think they have to be installed in some special order or something... when I do "dpkg -i *.deb" I get this error --> http://pastebin.com/m4337f2a9
[21:34] <jcristau> some are conflicting with each other
[21:34] <jcristau> which makes dpkg -i *.deb sort of a problem
[21:34] <mnemo> ahh, so I should just install a subset then?
[21:34] <jcristau> so, err, don't do that.
[21:35] <mnemo> which ones do I want for DRI radeon?
[21:35] <jcristau> libgl1-mesa-glx and libgl1-mesa-dri
[21:36] <bryce> mnemo: fwiw, I exclude the swx packages when installing mesa
[21:36] <bryce> otherwise it bumps you into software rendering or some such
[21:38] <mnemo> ok and then I have logout and login again?
[21:38] <mnemo> or is there some magic way similar to what modprobe does for kernel?
[21:40] <bryce> I usually restarting gdm (or for the freeze issue do a fresh reboot just to be sure).  dunno if there's a simpler method
[21:42] <jcristau> mnemo: depends what your issue is.  if it's related to aiglx, then you need to restart the X server.  if it's direct rendering, then you don't have anything to do.
[21:43] <mnemo> jcristau: ok, but if its direct rendering and im using compiz I need to restart compiz at least right?
[21:43] <jcristau> compiz doesn't use direct rendering (on dri1 anyway).  so restart X.
[21:44] <mnemo> ok
[21:44] <bryce> jbarnes: yeah setting pScrn->display->virtualX seems to just crash X
[21:44] <jbarnes> ugg
[21:45] <bryce> out of curiosity I printed virtualX/Y throughout the preinit call, and it seems to never change from what I set it, so there isn't something that's resetting it
[21:54] <bryce> whoa
[21:54] <bryce> something I did just did it
[21:54] <bryce> Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2048 x 2048
[22:01] <jbarnes> bryce: heh cool
[22:01] <bryce> narrowing the patch down
[22:02] <bryce> I'd just started randomly moving the display->virtualX stuff at different spots in the routine, and I think I stuck it in a spot where it had the right effect
[22:03] <mnemo> "development by a 1000 monkeys, eventually shit just has to work right"
[22:03] <mnemo> hehe sry :)
[22:03] <bryce> ez true
[22:04] <bryce> cheep cheep
[22:06] <mnemo> bryce: btw I think I managed to screw up my computer in exactly the way you told not to... i mean.. after install *.deb of mesa ... now "glxinfo | g direct" says "NO!"
[22:06] <mnemo> is there anyway around that?
[22:07] <bryce> yeah, I think it is to do a apt-get install -f
[22:07] <bryce> which cleans up the mesa stuff
[22:07] <cshadowrun> bryce your the guy who wrote the reply to the brainstorm on multi monitor support i think, right?
[22:07] <bryce> CShadowRun: probably
[22:07] <CShadowRun> cool, i'm all up for testing (quad screen user \o/)
[22:08] <CShadowRun> been trying to prod gnome into fixing some long-standing multi X screen bugs recently lol
[22:09] <mnemo> Federico Mena-Quintero has done some really nice work on xrandr fixes in GNOME lately as well
[22:10] <mnemo> CShadowRun: what graphics card do you have?
[22:10] <CShadowRun> mnemo i have a pair of 8800GT
[22:10] <CShadowRun> one X screen per card, so 2 twinviews.
[22:11] <bryce> CShadowRun: link to the brainstorm page plz?
[22:11] <CShadowRun> bryce i'll try and find it again, it was a long time ago though
[22:15] <CShadowRun> don't think i can find it, i remember it was in development for intrepid, and that it had about 2000 +'s
[22:15] <CShadowRun> and that there was a reply explaining about xrandr
[22:15] <CShadowRun> and that testers where needed
[22:16] <bryce> well, -nvidia multi-card is completely different
[22:16] <bryce> and afaik is not an xrandr thing
[22:16] <CShadowRun> bryce http://brainstorm.ubuntu.com/idea/206/
[22:17] <CShadowRun> i heard xrandr 1.3 was going to have shared graphics memory which would allow for multi cards?
[22:17] <bryce> yeah
[22:17] <bryce> still, that's orthogonal to -nvidia
[22:18] <CShadowRun> yea, i know theres no support for the nvidia binary driver
[22:18] <CShadowRun> those are the 2 things i'm waiting on :D
[22:19] <CShadowRun> also another thing that wasn't mentioned in the article is alot of software really doesn't work well if you use multiple X screens
[22:19] <CShadowRun> gnome-panel is a good example of that
[22:19]  * bryce nods
[22:20] <CShadowRun> but i been trying to prod the gnome-panel dev into fixing some of that, hopefully
[22:20] <CShadowRun> then i can move from hardy to jaunty \o/
[22:20] <bryce> a lot of the Xinerama style setups seem to have suffered regression now that xrandr is the norm
[22:20] <bryce> good, keep at that
[22:21] <CShadowRun> yea, i'm not using xinerama
[22:21] <CShadowRun> i like the seperation of X screens
[22:22] <CShadowRun> anyway nice talking to you, if you ever need anything tested i have a partition dedicated to testing stuff, so just drop me a line :)
[22:22] <bryce> sure, usually if we need testing I announce to ubuntu-x@lists.ubuntu.com
[22:23] <CShadowRun> cool, sign up for that
[22:23] <mnemo> CShadowRun: https://lists.ubuntu.com/mailman/listinfo/Ubuntu-x
[22:24] <CShadowRun> ty
[22:26] <bryce> ok... moment of truth, time to verify this solves the freeze...
[22:27] <mnemo> /mne keeps fingers crossed
[22:41] <bryce> has passed the 10 min mark, that's a very good sign
[22:43] <bryce> ok, ppa updated.  I'm going to snag some lunch and let this laptop finish its testing
[22:44] <bryce> jbarnes: http://pastebin.ubuntu.com/160964/ - open to suggestions for improvement
[22:45] <jbarnes> bryce: yeah looks like a good hack
[22:46] <mnemo> bryce: i would mention some "workaround" plus some LP bug number in the debug output like you did with that intel i865G bug
[23:11] <bryce> ok
[23:11] <bryce> (still going strong btw)
[23:12] <mnemo> nice
[23:16] <mnemo> hi phoronix :)