[00:06] <apw> bryceh, RAOF, Sarvatt ... i've updated the kernels in the multi-touch PPA, seem to work here on my kit
[00:27] <Nandou> I have a MacBookPro 5,3 and I'm currently trying to install Lucid Lynx beta 1 using the liveCD. I have encountered problems with the nouveau driver and by using the "blacklist=nouveau" boot option the process is going further but instead having "[drm] nouveau 0000:02:00.0: PRAMIN flush timeout" error message while the modules are loaded, I receive it during the init phase. Does anyone have any idea ?
[00:29] <RAOF> You can try adding nouveau.modeset=0 instead of blacklist=nouveau.  I think what's happening there is the nouveau X driver is asking for the kernel to load the nouveau kernel driver, which it can.  The blacklist only stops the driver being loaded automatically.
[00:30] <Nandou> RAOF: okay thank you I will give it a try
[01:00] <Nandou> RAOF: With nouveau.modeset=0 option, I no longer have the nouveau error message but the computer still won't boot ubuntu. The last 2 error messages are : "init: unreadahead-other main process (1259) terminated with status 4" and "b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 8, Type 4, Revision 4" but I believe thoses 2 errors messages shouldn't stop the computer from booting. Am I correct?
[01:01] <RAOF> Right.  Those look just like warnings.
[01:01] <RAOF> Well, and the ureadahead message is the expected behaviour.
[01:01] <RAOF> So, what's happening.  In what way does the computer fail to boot?
[01:03] <Nandou> Nothings happen
[01:03] <Nandou> No blinking cursor, dvd stop spinning
[01:04] <RAOF> What happens before that?
[01:04] <Nandou> I have removed splash and quiet but it stop during the init stage
[01:05] <RAOF> Sometimes it can take a long time to boot.
[01:06] <RAOF> Maybe you could try with “blacklist=vga16fb” as well?
[01:07] <Nandou> Ill try with blacklist=vga16fb
[01:07] <Nandou> It's been stuck on the b43-phy0 line for a while now
[01:07] <RAOF> :/
[01:10] <Nandou> that thing is going to catch fire
[01:11] <Nandou> and there's hope right now!
[01:12] <Nandou> Hum.. maybe not, the screen stays completely black.
[01:29] <Nandou> RAOF: I was finally able to get to the desktop by using : "blacklist=vga16fb nouveau.noaccel=1"
[01:30] <Nandou> Thank you for your help
[01:31] <RAOF> Could you please file a bug?  It'd be helpful to have your hardware details and such recorded.  Running “ubuntu-bug xorg” from a terminal should collect a bunch of useful logs (as long as apport hasn't broken again :()
[01:32] <Nandou> I will as soon as my internet is working ;)
[01:32] <RAOF> Hah!
[03:01] <eggonlea> hi, I'm in.
[03:02]  * NCommander waves to eggonlea 
[03:03]  * eggonlea :)
[03:05] <eggonlea> Hi, we're going to implement mode auto-detection on Dove X driver. Could anybody tell me what's the correct way to read EDID/I2C from x driver? We currently could read that in kernel space LCD driver only. Thanks!
[03:06] <eggonlea> I'm in GMT+8, so please just drop me a message if you see this later. I'll check answer here. :)
[03:08] <bryceh> eggonlea, with KMS enabled drivers, there is a set of code in drm_edid.c which handles reading EDID
[03:08] <bryceh> if your driver is KMS enabled, that's the way to go
[03:08] <eggonlea> bryceh: thanks!
[03:08] <bryceh> if not, there is similar edid parsing code in the xserver which you can hook into
[03:09] <eggonlea> We won't enabled KMS, but just read EDID through I2C directly.
[03:12] <eggonlea> So, if I plug a new VGA monitor, would KMS read the new EDID? And how does Xorg know it should refresh EDID?
[03:13] <bryceh> eggonlea, if you're not enabling KMS then KMS would not be reading the new EDID
[03:13] <bryceh> in the non-KMS case, the EDID is not automatically probed
[03:14] <bryceh> so a client app would need to ask the video driver to re-query the VGA port to retrieve the EDID info
[03:14] <eggonlea> So, how does Xorg know it need to refresh this? Any standard way to notify Xorg about this? Or I could just hack in x driver?
[03:16] <eggonlea> I mean, is Xorg poll'ing this via ioctl, or KMS (or any other kernel driver) posts an event (netlink/udev?)?
[03:19] <bryceh> eggonlea, again, it's not automatically polled
[03:19] <bryceh> the call is too expensive and bogs the system down if that's done
[03:19] <bryceh> eggonlea, there is a libXrandr routine which causes the edid to be re-probed
[03:20] <eggonlea> so, when xorg read new EDID on x86?
[03:20] <bryceh> so if for some reason you wanted it to poll, you could implement a daemon or whatever which makes that call repeatedly
[03:21] <eggonlea> If I change a VGA monitor dynamically, Xorg should know that and refresh usable modes.
[03:21] <eggonlea> bryceh: No, I don't want to poll. But just want to follow the standard way. :)
[03:22] <bryceh> eggonlea, the standard way is to implement KMS support in your driver
[03:23] <bryceh> the kernel is able to discern when a monitor has been attached and can re-gather the edid automatically, and emit an event when this has occurred
[03:24] <eggonlea> Do you mean KMS defines the event as the standard way to notify Xorg?
[03:24] <bryceh> I don't think you're hearing me ;-)
[03:24] <bryceh> If your driver supports KMS, then Xorg does not need to know about EDID.  It's all done internally in the kernel.
[03:24] <bryceh> if your driver does not support KMS, then polling cannot be done
[03:25] <eggonlea> Ah, I see a little bit more, I think.
[03:25] <bryceh> it sounds like what you want is some hybrid system where the kernel detects the monitor and sends a signal, but then the edid probing is done in X.org itself 
[03:25] <bryceh> as far as I know, nothing like that is implemented
[03:26] <eggonlea> So, if I execute xrandr, it would drop into KMS also to read out and print all available modes. right?
[03:28] <bryceh> yes, if the driver in question supports KMS
[03:39] <eggonlea> thanks! I'll take a look into KMS and see how much effort we need to implement it on current FB LCD driver.
[05:21] <Sarvatt> speaking of arm device KMS, whoa.. https://www.codeaurora.org/gitweb/quic/chrome/?p=xwin/xf86-video-msm.git;a=shortlog;h=refs/heads/chromium
[06:13] <Sarvatt> we're going to have 1 extension event to spare once we go to xserver 1.8 with the blob, good thing we disable multibuffer
[06:14] <Sarvatt> got 2 to spare now because dri2 is only using 1
[06:15] <tjaalton> still no decision on the backport ffe :/
[06:52] <Sarvatt> ok backported http://cgit.freedesktop.org/xorg/xserver/commit/?id=711e26466ae04ae93ff4c48d377d83d68a6320e9 to 1.7 branch, lets see if it fixes clutter apps
[08:09] <Sarvatt> no dice
[08:25] <jcristau> Sarvatt: that patch is a fix for the swapbuffers thing which isn't in 1.7
[08:25] <jcristau> afaict
[08:44] <eggonlea> Let me see what's in Sarvatt's URL...
[08:53] <tjaalton> meh, jerrylamos has filed the same crasher five times
[09:05] <bryceh> tjaalton, he's a good sort, amenable to being educated
[09:05] <bryceh> http://www2.bryceharrington.org:8080/X/Graphs/totals.svg is going in a very pleasant direction at the moment
[09:05] <bryceh> good work everyone :-)
[10:36] <tjaalton> bryceh: so the backport ffe is basically ready to go, and pitti concluded that slangasek's concerns were covered, so I'll start pushing the bits to pkg-xorg git
[10:39] <bryceh> tjaalton, will you also be getting all the driver packages updated?
[10:39] <tjaalton> bryceh: sure
[10:39] <bryceh> tjaalton, there is little time remaining for beta2, which is what I'm mostly concerned about
[10:39] <tjaalton> they're all ready
[10:40] <tjaalton> we've only shipped udev rules for ~5 drivers anyway
[10:40] <bryceh> tjaalton, ok... well this gives me the willies a bit, but I trust you
[10:40] <tjaalton> :)
[10:41] <bryceh> logically, it seems to be the correct thing to do
[10:46] <tseliot> tjaalton: I guess we'll need to ship a file in xorg.conf.d/ (or whatever it's called) for touchpads to replace our current quirks
[10:46] <bryceh> hi tseliot
[10:46] <tseliot> hey bryceh
[10:46] <tjaalton> tseliot: that's one way yes. the quirks we had were from debian though
[10:46] <tjaalton> aiui
[10:47] <bryceh> tseliot, btw I've been neglecting the proprietary testing group the last few weeks; would probably be well received to drop them a line and give some encouragement
[10:47] <tjaalton> others were patched in the drivers
[10:47] <tseliot> tjaalton: not the one that I added, which work with my patch
[10:47] <tjaalton> -s
[10:47] <tjaalton> tseliot: ok, maybe it's missing from my tree
[10:47] <tseliot> bryceh: sorry but I'm kind of overbooked at the moment
[10:47] <bryceh> tseliot, I'm just saying...
[10:47] <tseliot> tjaalton: currently it's in the udev rules
[10:48] <tseliot> bryceh: maybe after the beta, we'll see
[10:48] <bryceh> tseliot, I'm also extremely overbooked else I'd have already done it
[10:49] <tseliot> tjaalton: 66-xorg-synaptics.rules (from udev) should simply add a tag and then the xorg.conf file will catch the tag and apply the quirk
[10:50] <tseliot> bryceh: yes, we all are ;)
[10:50] <tjaalton> tseliot: it can also match the vendor string
[10:50] <tjaalton> or product
[10:51] <tseliot> tjaalton: unfortunately that's not enough. What I need for that quirk is ATTR{[dmi/id]product_name}
[10:51] <tjaalton> which the two quirks in udev rules do
[10:51] <tseliot> right
[10:51] <tseliot> are you sure that it can match the product?
[10:52] <tjaalton> MatchProduct
[10:52] <bryceh> tseliot, anyway, the efforts being paid by these volunteers are helping you more than me. ;-)
[10:52] <tjaalton> tseliot: you'll find out before too long ;)
[10:52] <jcristau> tjaalton: that matches the device, not the machine
[10:52] <tjaalton> ah ok
[10:53] <tjaalton> then it needs the tag, yes
[10:53] <bryceh> tseliot, I tend to feel time spent helping volunteers ends up helping you end the long term... who knows you might find a tseliot amongst them.  ;-)
[10:53] <tseliot> bryceh: yes, sure, testing is very welcome, especially with all the new stuff about proprietary drivers
[10:54] <tseliot> bryceh: my point is, fix things now, then ask them to test things ;)
[10:54] <tseliot> and I need to finish step 1
[14:51] <Oxymoron> My screen resolution doesnt get higher than 1280x1024 and proprietary drivers doesnt load if I dont have any xorg.conf file? I have a nVidia 7950 GT card and a 23" widescreen monitor 
[14:58] <tseliot> Oxymoron: how did you install the driver?
[14:59] <Oxymoron> tseliot: Through apt-get install nvidia-current in Kubuntu Lucid and then activate through jokcey and restarted computer
[15:00] <Oxymoron> nvidia-xonfig does seem to brake another thing, which dont make it possible watch video in multimedia players
[15:00] <tseliot> Oxymoron: your Xorg.0.log might have something interesting
[15:00] <tseliot> and dmesg too
[15:01] <Oxymoron> dmesg just show me that 195.36.15 is loaded and no errors, Ill paste the Xorg log one sec
[15:02] <Oxymoron> http://pastebin.com/q27w9JND
[15:05] <Oxymoron> tseliot: 
[15:05] <tjaalton> you need the xorg.conf
[15:06] <Oxymoron> tjaalton: How to create that one without type command nvidia-xconfig? Does anybody of you have one working?
[15:06] <tjaalton> jockey should have created one
[15:06] <Oxymoron> tjaalton: Well it didnt ..
[15:07] <tseliot> Oxymoron: I have just pushed a new release of Jockey which should make it more robust in this sense
[15:07] <tjaalton> check that you don't have it in /etc/X11
[15:07] <tjaalton> maybe failsafe kicked in for some reason
[15:07] <tjaalton> and moved it
[15:07] <tjaalton> though this log is not from failsafe
[15:07] <tjaalton> so maybe not
[15:08] <Oxymoron> tjaalton: I removed it myself to test another thing
[15:08] <tjaalton> eh
[15:08] <Oxymoron> tjaalton: I have backupbs
[15:08] <tseliot> also, please let me have a look at dmesg
[15:08] <Oxymoron> tseliot: Alright one sec
[15:09] <Oxymoron> tseliot: http://pastebin.com/jBxWFiBw
[15:09] <lool> Sarvatt: Hey; I'm afraid I don't have the hardware either (anymore); thanks a lot for fixing things up
[15:09] <lool> Sarvatt: NCommander is working a lot on the dove video drivers these days, please feel free to ping him on this, or you can contact asac for coordination of the merging if you can't reach NCommander 
[15:09] <lool> Sarvatt: We mostly discuss it on #ubuntu-arm though
[15:10] <tseliot> Oxymoron: ok, so it just didn't create a xorg.conf. Please wait until the new jockey is availabl (revision ubuntu6) and try again
[15:10] <tseliot> available
[15:10] <asac> Sarvatt: yeah. the arm xdrivers are better discussed in -arm
[15:12] <Oxymoron> tseliot: Alright, how long do you think it takes? :)
[15:13] <tseliot> the packages will have to be built and then it's a matter of waiting on the servers to get those packages
[15:14] <Oxymoron> tseliot: Whats the new in the new patch btw? :)
[15:15] <tseliot> a few things. Have a look at the log in lucid-changes
[15:21] <Oxymoron> tseliot: Do you have the url?
[15:22] <tseliot> Oxymoron: https://lists.ubuntu.com/archives/lucid-changes/2010-March/009313.html
[15:22] <Oxymoron> tseliot: Thanks :)
[15:23] <tseliot> np
[15:24] <Oxymoron> tseliot: Nice, hopefully could solve some of my problems, hopefully all of them :)
[15:24]  * tseliot nods
[15:25] <Sarvatt> Oxymoron: silly question, but have you tried just deactivating the drivers in jockey, then reactivating them and rebooting?
[15:27] <Oxymoron> Sarvatt: Yes I have ;)
[15:27] <Oxymoron> Sarvatt: Its strange that jockey doesnt create /etc/X11/xorg.conf
[15:57] <Oxymoron> tseliot: Hmm sorry to say, but I installed your patch but it still says that nvidia-current is active but not loaded? :S Could it be that it actually isnt loaded? :P
[15:58] <tjaalton> Oxymoron: you said that you moved the xorg.conf away
[15:58] <tseliot> Oxymoron: you will have to reboot too
[15:58] <Oxymoron> tjaalton: Yes?
[15:58] <Oxymoron> tseliot: I have reboot ;)
[15:58] <tjaalton> Oxymoron: what was in it?
[15:58] <Oxymoron> tjaalton: Ill paste it for ya, wait a sec
[15:59] <Oxymoron> tjaalton: http://pastebin.com/978ENDSv
[15:59] <tjaalton> ok, so it was an upgrade
[16:00] <tjaalton> nevermind then
[16:01] <Oxymoron> tjaalton: What do you mean?
[16:01] <Oxymoron> tjaalton: And thats my backup file, my /etc/X11/xorg.conf doesnt exist because I renamed it to that file to test something
[16:02] <tjaalton> Oxymoron: thought that if it was the jockey-generated version, or from failsafe
[16:02] <Oxymoron> tjaalton: Its from nvidia-xconfig.
[16:02] <Oxymoron> tjaalton: And jockey doesnt generate anything
[16:02] <tjaalton> well the old one should work
[16:03] <Sarvatt> maybe because you already had nvidia-current installed when you activated it in jockey? (not sure how jockey works internally)
[16:03] <tseliot> Oxymoron: can you paste the output of "ls /etc/X11/" please? Also, try to remove nvidia-current
[16:04] <Oxymoron> tseliot: I have removed nvidia-current several times but it doesnt affect anything and yes Ill paste it in one sec
[16:04] <Oxymoron> http://pastebin.com/hdymbNds
[16:06] <Sarvatt> Oxymoron: grep -R NoLogo /etc/X11/
[16:06] <Sarvatt> return anything?
[16:07] <Sarvatt> if so that means jockey did create xorg.conf's at some point in those backup ones
[16:07] <Oxymoron> Sarvatt: http://pastebin.com/c6i7AkY8
[16:09] <Oxymoron> Sarvatt: Should I remove everyone? :D
[16:09] <Sarvatt> Oxymoron: if you wouldn't mind entertaining me, can you try sudo apt-get purge nvidia-current, remove that xorg.conf, and activate nvidia-current straight in jockey this time and then reboot to see if its any different?
[16:09] <Oxymoron> Sarvatt: I have done that like seven billion times already, please not one more time :D I dont want to reboot again
[16:10] <tseliot> Oxymoron: please do what Sarvatt suggests but before you do it, please type "sudo rm /var/log/jockey.log"
[16:10] <tseliot> and past the new /var/log/jockey.log after you do what Sarvatt suggested
[16:10] <tseliot> paste
[16:10] <Oxymoron> alright ...
[16:11] <Sarvatt> Oxymoron: you did *exactly* those steps before?
[16:11] <Oxymoron> Sarvatt: Yes
[16:11] <Oxymoron> Sarvatt: Which xorg.conf did you point on btw?
[16:12] <Oxymoron> If you mean /etc/X11/xorg.conf I have done exactly those steps before
[16:17] <Oxymoron> I will try remove all these backup files, or well I move them ... Does mv -r /etc/X11/xorg.conf.backup* /home/oxymoron/xbackup work?
[16:19] <Oxymoron> Alright, now I have moved them all and will try your steps one last time Sarvatt :)
[16:19] <Oxymoron> tseliot: Then I post /var/log/jockey.log to you when I have rebooted ;)
[16:20] <tseliot> whenever you prefer
[16:21] <Oxymoron> Sarvatt: And jockey cant find nvidia proprietary drivers if nvidia-current isnt installed so I guess that you meant reinstall nvidia-current
[16:24] <Oxymoron> tseliot: Btw, if jockey already is in sudo mode it doesnt rescan if I close app and then start it again? :S How to rescan after isntalled drivers?
[16:25] <tseliot> Oxymoron: close jockey and type "sudo killall jockey-backend"
[16:25] <Sarvatt> Oxymoron: no I didn't mean reinstall nvidia-current, thats what I was trying to have you avoid :D sorry talking between jobs here
[16:26] <Oxymoron> Sarvatt: Well if I remove nvidia-current jockey doesnt find nay drivers? :P
[16:27] <Sarvatt> you're *just* purging nvidia-current? nvidia-current-modaliases is still installed?
[16:28] <Oxymoron> Sarvatt: No I purge nvidia*, nvidia-current-modaliases has never been installed at all? :P
[16:28] <Sarvatt> Oxymoron: I was asking you to type the exact command I said :D you need nvidia-common and nvidia-current-modaliases installed still, dont purge nvidia*
[16:29]  * tseliot nods
[16:29] <Oxymoron> Sarvatt: Well I dont even have nvidia-common or nvidia-current-modalases and it have never been installed? :D
[16:29] <Oxymoron> Dependecy problems? :P
[16:30] <Oxymoron> When I install nvidia-current it only installs that and nvidia-settings
[16:30] <Sarvatt> you removed it by purging nvidia* at some point already
[16:30] <tseliot> they are installed by default. Jockey won't work without them
[16:30] <Sarvatt> just sudo apt-get install nvidia-common
[16:30] <Oxymoron> Sarvatt: No I checked and it didnt removed those, but I have removed those before
[16:30] <Sarvatt> there's your problem I'm sure
[16:30] <Oxymoron> tseliot: They are not isntalled by default for me in Lucid
[16:31] <Oxymoron> Sarvatt: Yes could be ... awesome I asked someone else and he said that I only need nvidia-current .... dOOOoH
[16:31] <Sarvatt> Oxymoron: I can most assuredly guarantee you they are installed by default for everyone and you removed it at some point
[16:32] <Sarvatt> so sudo apt-get install nvidia-common, sudo apt-get purge nvidia-current, remove your xorg.conf, then activate nvidia-current straight in jockey
[16:33] <Oxymoron> If I install nvidia-current it doesnt install nvidia-common?
[16:33] <Sarvatt> nope
[16:33] <Oxymoron> Sarvatt: Well, problem solved I guess xD I do your steps now, I will not trust those guys in #kubuntu or ubuntu+ channel in this case anymore :D
[16:34] <Oxymoron> ubuntu+1
[16:35] <Oxymoron> tseliot: Btw, sudo killall jockey-backend and then open jockey again doesnt work? It doesnt rescan drivers on my system? :S
[16:35] <Oxymoron> tseliot: I guess its cached or doesnt run if sudo for it is open.
[16:35] <Oxymoron> tseliot: Is there any rescan option for jockey backend?
[16:36] <tseliot> Oxymoron: just make sure that "jockey" is not in the output of "ps aux | grep jockey"
[16:36] <tseliot> otherwise just kill any remaining jockey process
[16:37] <tseliot> launching a new jockey-backend will rescan your hardware
[16:37] <Oxymoron> tseliot: ps aux | grep jockey give me one process using jockey but crl+esc doesnt show any process using jokcey? :S
[16:38] <Oxymoron> "oxymoron 12330  0.0  0.0   3336   828 pts/2    S+   17:37   0:00 grep jockey"
[16:38] <tseliot> that's you looking for jockey
[16:38] <tseliot> not a jockey process
[16:38] <tseliot> i.e. jockey is not running
[16:40] <Oxymoron> tseliot: Haha lol xD Seriously that was awkward xD
[16:40] <Oxymoron> tseliot: Well it doesnt work then, bug
[16:40] <Oxymoron> hmm now it searches finally :)
[16:41] <Oxymoron> It took awhile to release cache or something I guess
[16:41] <Oxymoron> And now it Finally found the drivers even that I dont have nvidia-current installed <3 finally!
[16:42] <tseliot> \o/
[16:43] <Oxymoron> I guess all this problem because modaliases and common wasnt installed 
[16:43] <tseliot> Sarvatt: a one line patch should fix bug #539196 and save me from having to maintain 3 different versions of nvidia-settings
[16:43] <Sarvatt> i think everyone using the blob has purged nvidia-* at some point and gotten themselves into that situation, thats why I was asking you to entertain me :)
[16:44] <Sarvatt> tseliot: installing a different xorg.conf for nvidia-173/nvidia-96?
[16:44] <Oxymoron> Sarvatt: Haha alright :D Well I think I have removed it sometime when I should fix something with nvidia before.
[16:44] <tseliot> Sarvatt: no, just patching nvidia-settings so that it doesn't fail if the noscanout property is not provided by the driver
[16:44] <Sarvatt> tseliot: there is a xorg.conf option you can add to fix that on the older drivers but I can't remember which, think it was disabling twinview
[16:45] <Sarvatt> oh sweet
[16:45] <Oxymoron> Sarvatt, tseliot: I will reboot now and if it works, seriously thank you very much! <3 I have been struggling this problem in like a month and no one have been able to help me properly
[16:45] <Oxymoron> I had this problem even in Karmic
[16:46] <Oxymoron> Btw, in jockey I would suggest a reboot button or make it send by dbus an action to reboot like KPackagekit does if reboot is required ;)
[16:46] <Sarvatt> no problem Oxymoron, now ya know and can help people having the same problem :)
[16:46]  * tseliot nods
[16:46] <Oxymoron> Sarvatt: Yes I will certainly do if someone have same problem :)
[16:53] <Oxymoron> Sarvatt, tseliot: Now nVidia driver works, but I still got the same annoying ground problem ... In my mutlimedia players, the video output is transparent and show the image of the window beneath video player.
[16:54] <tseliot> Oxymoron: Xorg.0.log, please
[16:56] <Oxymoron> tseliot: http://pastebin.com/7QiDXrMy
[16:57] <tseliot> either try disabling the 3D effects or ask on Nvidia's forums
[16:57] <tseliot> the driver is enabled now
[16:59] <Oxymoron> tseliot: Yeah I saw that, sweet :) Hopefully I will be able to make video players work :)
[17:00] <Oxymoron> tseliot: Weird, if I remove desktop effects I got a black screen instead of a transparent :P
[17:01] <tseliot> you definitely want to ask nvidia on the nvnews forum about it
[17:03] <Oxymoron> nvnews forum?
[17:06] <bjsnider> Oxymoron, your hardware is old though is it not?
[17:07] <Oxymoron> bjsnider: Its not that for sure, my card has worked before for a month ago it stopped working after some karmic update or something like that. 7950 GT isnt very old, most people here uses like 7300 or something like that. I should not need 8 series or GTX
[17:07] <Sarvatt> Oxymoron: what video player? try changing the output method in it
[17:07] <Oxymoron> bjsnider: But my computer itself has new components :)
[17:07] <Oxymoron> Sarvatt: All of them
[17:08] <Oxymoron> Sarvatt: VLC I tried switch output mode and then that one "work" but not smooth
[17:09] <Oxymoron> Sarvatt: It havent work for a long time now, maybe one month. Nobody know whats the problem it seems, would be real nice if I could solve it.
[17:09] <Sarvatt> find out how KDE picks the default output method and play with that, in gnome its system - preferences - multimedia system selector
[17:10] <Oxymoron> Sarvatt: Phonon and then Xine engine or Gstreamer but I dont know how to change? :S
[17:10] <bjsnider> Oxymoron, my experience is the blob supports the newer chips like g8x and g9x better than the older g7x and so forth
[17:12] <Oxymoron> Shouldnt be the problem I think, have been working smoothly like ages in max effects on
[17:15] <Oxymoron> bjsnider:
[17:23] <desrt> hi.  i'm trying to track down a regression with X on lucid
[17:24] <desrt> the regression has happened between the beta release and the current state of the archive
[17:24] <desrt> it has to do with the X server being unable to allocate sufficient memory to complete an xrandr
[17:26] <Sarvatt> desrt: got a bug#?
[17:27] <desrt> no.  i'm trying to gather some more information
[17:27] <desrt> i'm just wondering if you guys have heard of this issue already
[17:28] <desrt> it comes with this in the xorg log:
[17:28] <Sarvatt> maybe if I can see the logs of what happens, what GPU you  have and such
[17:28] <desrt> (II) intel(0): Allocate new frame buffer 2400x1920 stride 2432
[17:28] <desrt> Fatal server error:
[17:28] <desrt> Failed to submit batchbuffer: No space left on device
[17:28] <desrt> i'll pastebin the log
[17:29] <desrt> i'm just on the livecd now to get a list of package versions from the working config so i can start to play around to see which package is responsible for the regression
[17:29] <tseliot> desrt: is that with the 3d effects on?
[17:29] <desrt> yes and no
[17:30] <Sarvatt> desrt: so it's intel, what specific GPU?
[17:30] <desrt> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
[17:30] <desrt> http://pastebin.org/128694 <- full xorg log
[17:31] <desrt> tseliot: it appears not to matter
[17:32] <Sarvatt> can you pastebin the output of cat /sys/kernel/debug/dri/0/gem_objects after it happens?
[17:32] <desrt> after it happens my system is unusable....
[17:32] <desrt> erm.  maybe ssh will still work.  let me install sshd and try again.
[17:32] <desrt> bbiab.
[17:33]  * Oxymoron wonder if it could be something else than xserver, nvidia driver, codecs or phonon that is the reason video output isnt working
[17:33] <tseliot> desrt: please install mesa-utils and paste the output of "glxinfo -l | grep -i size"
[17:37] <desrt> this is fascinating.
[17:37] <desrt> is it possible that having desktop effects *enabled* could prevent the crash?
[17:38] <tseliot> it's what I was trying to say
[17:38] <desrt> ok.  that might be the case.
[17:39] <desrt> i forgot that i had disabled them (because things were going -really- slow)
[17:39] <desrt> that was at the same time as i was doing the upgrade
[17:39] <desrt> and since turning desktop effects *off* doesn't usually cause problems....
[17:39] <desrt> i just assumed it was the upgrade that broke stuff
[17:39] <bjsnider> Oxymoron, is glxinfo giving you the expected output at this point in time?
[17:40] <Oxymoron> bjsnider: Yes, properly working ;)
[17:41] <bjsnider> and what happens when you try mplayer -vo xv -ao pulse file.avi?
[17:41] <Sarvatt> well I see the same problem as in your log here but that doesn't help any :D  https://bugzilla.redhat.com/show_bug.cgi?id=558632
[17:43] <Oxymoron> bjsnider: That works, the players that dont is DragonPLayer and Kaffeine what I know about.
[17:43] <bjsnider> so xine
[17:43] <Oxymoron> bjsnider: Do you know if its possible to tweak zine someway?
[17:43] <Oxymoron> *xine
[17:43] <bjsnider> Oxymoron, are you one of those unfortunate people that uses kde?
[17:44] <Oxymoron> bjsnider: Yes ...
[17:44] <Oxymoron> bjsnider: Why?
[17:44] <bjsnider> meh
[17:44] <bjsnider> it's not my favourite thing to use
[17:45] <desrt> hmm.  once the X server goes down it seems like userland is dead
[17:45] <desrt> i can ping the machine, but ssh is not responsive
[17:45] <Oxymoron> bjsnider: How come?
[17:46] <bjsnider> well, go read what linus has said about kde4
[17:48] <bjsnider> it's like gilding a turd. it's pretty but it stinks
[17:49] <desrt> desrt@marzipan:/sys/kernel/debug/dri/0$ echo `cat gem_objects `
[17:49] <desrt> 666 objects 31080448 object bytes 7 pinned 13582336 pin bytes 28753920 gtt bytes 234881024 gtt total
[17:50] <Oxymoron> bjsnider: And I tried gstreamer instead of xine same problem consisted with video ... I guess Linux havent tested latest KDE then xD
[17:50] <Oxymoron> Linus*
[17:50] <desrt> tseliot: ^^
[17:51] <Oxymoron> bjsnider: I would say same thing about Ubuntu then but one change, its ugly as hell and stinks as well xD
[17:51] <bjsnider> Oxymoron, what happens at the command line?
[17:51] <Oxymoron> bjsnider: commandline when?
[17:51] <bjsnider> xine
[17:52] <desrt> tseliot: and GL_MAX_TEXTURE_SIZE = 4096  |  GL_MAX_3D_TEXTURE_SIZE = 256  |  GL_ALIASED_POINT_SIZE_RANGE = 1, 255  |  GL_SMOOTH_POINT_SIZE_RANGE = 1, 255  |  GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 2048
[17:52] <Oxymoron> bjsnider: I dont know, I havent tried dragonplayer through command line
[17:53] <Sarvatt> desrt: can you try running the xorg-edgers PPA to see if its any different? If it is I'd suggest starting by looking at changes to src/drmmode_display.c in  xserver-xorg-video-intel between 2.9.1 and master
[17:53] <tseliot> GL_MAX_3D_TEXTURE_SIZE = 256 seems too little to me
[17:53] <bjsnider> Oxymoron, try this: xine file://some/where/foo.avi
[17:54] <desrt> tseliot: it's just a crappy embedded intel chipset on a laptop
[17:54] <Sarvatt> yeah its the same here tseliot 
[17:55] <tseliot> weird, I thought it was more...
[17:55] <Oxymoron> bjsnider: Weird, that works so I guess the problem isnt xine itself ...
[17:55] <bjsnider> whatever
[17:56] <Oxymoron> bjsnider: :'(
[17:56] <tseliot> desrt, Sarvatt: and what's the output of xrandr?
[17:57] <bjsnider> try launching kaffeine from a terminal and then adding a file and playing it using the gui to see if there's any console output
[17:57] <desrt> Screen 0: minimum 320 x 200, current 2400 x 1920, maximum 8192 x 8192
[18:01] <Oxymoron> bjsnider: I got this error repeated: ""
[18:01] <Oxymoron> X Error: BadMatch (invalid parameter attributes) 8
[18:01] <Oxymoron>   Extension:    133 (Uknown extension)
[18:01] <Oxymoron>   Minor opcode: 19 (Unknown request)
[18:01] <Oxymoron>   Resource id:  0x16a
[18:03] <Oxymoron> bjsnider: X conflicts with something maybe?
[18:06] <bjsnider> try googling that
[18:06] <bjsnider> make sure in the settings for both apps that you're using xv as the video output driver
[18:07] <Oxymoron> bjsnider: Do you know how to change video output driver?
[18:08] <bjsnider> i don't use those apps
[18:09] <Oxymoron> bjsnider: I do, but there is no settings in Kaffeine or DragonPLayer to change video output mode xD
[18:10] <Oxymoron> bjsnider: And Google didnt find any useful info about that error btw :P
[18:16] <bjsnider> that looks like a qt error, not specifically having to do with video
[18:16] <bjsnider> try #kubuntu-devel
[18:18] <Oxymoron> bjsnider: Alright, thanks :)
[18:46] <Sarvatt> Oxymoron: thats a XvShmPutImage error in the Xvideo extension, try playing with the Xv settings in nvidia-settings to see if you can get it working?
[18:46] <Sarvatt> doh too late
[18:49] <bjsnider> Sarvatt, that doesn't make a lot of sense because xine at the command line worked
[18:49] <bjsnider> and by default it uses xv
[18:50] <Sarvatt> alot of people have that problem with the blob and xine apparently
[18:50] <bjsnider> is that right?
[18:51] <bjsnider> i wonder if it's all old hardware
[18:56] <bjsnider> i wonder if anybody with vdpau-capable hardware has that problem
[19:13] <Sarvatt> desrt: is your numlock light on your keyboard flashing when it happens?
[19:14] <desrt> i don't know
[19:14] <desrt> the reason that i'm running with external monitors at present is because the cable that connects my laptop's monitor to the base of it broke
[19:14] <desrt> and the keyboard LEDs are part of the monitor assembly
[19:15] <desrt> fwiw, this setup will only be necessary for a few more days until the replacement part arrives
[19:26] <kklimonda> so how is the fadeout/fadein done? I'm stuck with almost black screen now ;)
[19:27] <kklimonda> hmm.. not xgamma..
[19:27] <kklimonda> the cursor looks fine but the rest of the screen is dimm
[19:27] <cnd> bryceh: RAOF: how can I test the latest nouveau in lucid? I'm worried about the userspace abi conflicts
[19:27] <cnd> would the xorg-edgers ppa allow me to try it?
[19:27] <cnd> Sarvatt: ^^ too?
[19:28] <Sarvatt> kklimonda: the gnome-screensaver fadeout? run gnome-screensaver with --debug and see what gamma fade method it's using and its pretty obvious in the source how it happens
[19:29] <Sarvatt> cnd: yeah
[19:29] <cnd> Sarvatt: ok, I'll try it
[19:29] <Sarvatt> cnd: although I haven't updated it to the latest nouveau since they rebased onto 2.6.34 and it needs a lot more stuff like some acpi bits backported too
[19:30] <cnd> hmm...
[19:39] <Sarvatt> desrt: asking what other info would be useful in a bug report about your issue in #intel-gfx
[19:52] <Sarvatt> desrt: can you try grabbing the xserver-xorg-video-intel source, and disable the copyfb patch from the series?
[19:53] <desrt> sure.
[19:56] <Sarvatt> desrt: the problem happens right after startup right? does it work if you dont have it connected at startup and plug it in after?
[19:56] <desrt> the problem comes at login
[19:56] <desrt> due to the gnome settings daemon applying my xrandr settings from gconf
[19:57] <Sarvatt> its fine at the gdm login screen?
[19:57] <desrt> s
[19:57] <desrt> yes
[19:58] <desrt> debuilding the driver with the patch removed
[19:59] <desrt> ok.  new driver is in
[19:59] <desrt> i'll see if i can get any crashes to happen
[20:12] <desrt> no help.
[20:12] <desrt> still getting the crash ~50% of thet ime
[20:21] <tjaalton> bryceh, Sarvatt: xorg-server with the backports uploading..
[20:21] <bryceh> here we go :-)
[20:21] <tjaalton> yep
[20:22] <tjaalton> it works with current drivers, so I'll wait until it's built & published before uploading the drivers
[20:34] <BUGabundo> evening
[20:48] <Sarvatt> tjaalton: woohoo! 
[20:48] <Sarvatt> tjaalton: nice -  Add 14-tone-down-nidr-errors.diff. Use X_INFO instead of X_ERROR.
[20:48] <Sarvatt> I was going to ask if we should downgrade that
[21:06] <Ng> aaaaa
[21:06] <Ng> I just ran sudo lshw and everything went pink
[21:07] <BUGabundo> YAY
[21:07] <BUGabundo> pink of fushia?
[21:07] <Ng> and looked exactly like things did on the brand new Vaio I mentioned the other day
[21:07] <Ng> BUGabundo: I don't know which shade of pink, but it was definitely corrupted
[21:08] <Ng> flipping to a console and back fixed it :/
[21:09] <BUGabundo_diner> Ng: does this help? http://p.bugabundo.net/color-wheel-15
[21:09] <Ng> no ;)
[21:11] <kklimonda> Sarvatt: thanks, code is straightforward but the problem itself isn't :)
[21:13] <Sarvatt> Ng: guessing you're on the 2.6.32-17 kernel?
[21:13] <Sarvatt> that should be fixed in 2.6.32-18
[21:13] <Ng> Sarvatt: aha, I was just preparing to reboot :)
[21:33] <BUGabundo_WC> Ng: damn... I was almost sure it would :\ 
[21:33] <BUGabundo_WC> :)
[21:50] <tjaalton> sigh, xserver failed on armel, some buildd problem apparently
[21:50] <tjaalton> dpkg-deb: building package `xserver-xorg-core-dbgsym' in `../xserver-xorg-core-dbgsym_1.7.6-2ubuntu1_armel.ddeb'.
[21:50] <tjaalton> make: *** [binary-arch] Error 2
[22:26] <apw> Sarvatt, i think you might have been having a look at whether there was a way to influence KMS resolution selection?  :)  if so, hows that going?
[22:36] <tjaalton> looks like it'll take hours before the xserver is published on the main archs, so I'll upload the drivers in the morning..
[22:40] <bryceh> wish it wasn't such a pain in the ass to forward bugs upstream
[22:42] <tjaalton> yeah it could be more straightforward
[22:42] <RAOF> Launchpad still plans to get a “post this upstream” button, right?
[22:43] <bryceh> yeah but who knows if that'll be useful
[23:18] <Sarvatt> desrt: ickle passed along a patch regarding your problem, would you mind trying it out? I uploaded the package here https://edge.launchpad.net/~sarvatt/+archive/bugs
[23:18] <Sarvatt> tjaalton: did the last one even build right on armel?
[23:18] <desrt> Sarvatt: in a bit i'll try
[23:20] <Sarvatt> desrt: thanks :)
[23:22] <Sarvatt> ah darn wait, forgot debian  had a libdrm 2.4.18-3 build dep and forgot to change it
[23:22] <Sarvatt> we've got the overlay stuff in our linux-libc-dev so our libdrm is fine
[23:24] <Sarvatt> ok fixed one uploaded
[23:25] <Sarvatt> apw: I wasn't especially looking into that, whats the problem? video=connector:resolution should work?
[23:27] <Sarvatt> apw: good to see you back too, didn't have anyone to bug about kernel fixes while you were gone and  mailed the list :) we *really* need http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=7b56712ff524ee55e38afaee3954d125f56a6070 applied to the kernel again :D
[23:43] <RAOF> Sarvatt: How quick & easy is it for you to upload a new l-b-m-nouveau to xorg-edgers?  I'd like to get http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=8af36117e23bc36c34d0d25484f7b9de021b51bc in there for testing.
[23:47] <Sarvatt> RAOF: uploading now
[23:48] <RAOF> Sarvatt: You're awesome.
[23:48] <Sarvatt> if my battery doesn't die mid upload and zero out all the files again :D
[23:49] <Sarvatt> RAOF: if you ever have time lbm-nouveau packaging needs some love for the post 2.6.34 upstream rebase :D
[23:50] <Sarvatt> last i checked it failed because it needed some acpi change that touched it in .34 but maybe theres some way to work around that
[23:52] <Sarvatt> think it was http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a19a6ee6cad2b20292a774c2f56ba8039b0fac9c and http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=57e148b6a975980944f4466ccb669b1d02dfc6a1
[23:52] <RAOF> Ok.  Do you have any special-sauce scripts to help you lbm-nouveau?
[23:52] <RAOF> (That aren't already in the source on xorg-edgers?)
[23:52] <Sarvatt> just grab the source of the one in edgers and reuse the packaging :D
[23:53] <Sarvatt> i commented out some of the UPDATE|MUNGE-NOUVEAU stuff that didnt apply to the old 2.6.32 based upstream (just the listsort stuff)
[23:54] <RAOF> Right, yeah.
[23:55] <Sarvatt> not sure how to work around those two commits
[23:55] <Sarvatt> ideally we could just ship a whole darn kernel in there but i dont know how to package it right
[23:57] <RAOF> I think I do; maybe that can be a Easter project.
[23:58] <RAOF> Just shoving in a kernel wholesale would probably work.  We could probably even keep the Ubuntu sauce, now that upstream is based on 2.6.34 which is a descendent of our stuff.