[01:17] <jewsucanuse> hi, what's the quickest way to test glsl rendering?
[02:08] <jewsucanuse> ?
[10:32] <ko2> hello, can you help me with that: http://dpaste.com/285764/
[10:33] <ko2> what could be the error? 1) too old Intel Driver?, 2) Desktop Effects? I have no compiz installed, 3) X-Server-Settings?, 4) ?
[10:34] <ko2> i wanted to update the intel driver from: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/
[10:34] <ko2> But there is no version for hardy. Is there an alternative? I don't want to compile from scratch
[11:00] <ko2> ?
[11:12] <tjaalton> upgrade to lucid
[11:12] <tjaalton> that's an alternative..
[11:15] <ko2> i cannot, i MUST use hardy
[11:16] <tjaalton> the compile the package
[11:16] <tjaalton> +n
[11:17] <ko2> ok, do you think that could make everything better? e.g. in the program i want tot use: if i select the green color and draw, then the pink color draws. 
[11:17] <tjaalton> no idea
[11:17] <tjaalton> note that hardy will be obsoleted next april
[11:18] <ko2> ok
[14:07] <bjsnider> i wonder why he MUST use hardy?
[14:11] <tjaalton> didn't bother to ask
[15:01] <njpatel> I had a question about intel 4500 :
[15:01] <njpatel> actually, two
[15:01] <njpatel> 1. Does the DisplayPort work with ubuntu?
[15:01] <njpatel> 2. Through the displayport and the vga, could it drive two 1920x1080 monitors without causing a fire?
[15:02] <njpatel> also, with some form of 3d performance, game level not required
[15:07] <ko2> hello, i want to update my Intel Graphics driver from https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/ , but there is no Hardy Version. I have Kubuntu Hardy Heron installed
[15:08] <tjaalton> you asked already
[15:08] <tjaalton> upgrade
[15:08] <ko2> yes, but i got no answer, i cannot upgrade
[15:08] <tjaalton> why not?
[15:08] <ko2> i have two usb cameras whose driver only work until hardy heron
[15:08] <ko2> industrial cameras
[15:09] <tjaalton> which ones?
[15:09] <ko2> from IDS, uEye UI-1210-C
[15:10] <tjaalton> sounds weird that they wouldn't work on a newer release. have you verified it?
[15:10] <ko2> i contacted the support and they said that these cameras use a closed source kernel module for the access to usb
[15:10] <ko2> i did not verify 100%
[15:11] <ko2> but i can do, but if the work a bit strange things may happen
[15:11] <tjaalton> boot a livecd and see yourself?
[15:11] <ko2> but what if the work and sometime they do strange things i cannot prove at the moment?
[15:12] <ko2> "what if they work"
[15:13] <tjaalton> then compile  the driver like I said earlier
[15:13] <tjaalton> for hardy
[15:13] <tjaalton> hmm wait
[15:13] <tjaalton> iirc that driver version wouldn't work on hardy, so you're out of luck
[15:13] <tjaalton> since it needs kms
[15:14] <ko2> kms?
[15:14] <tjaalton> kernel mode setting
[15:14] <ko2> kernel module support?
[15:14] <ko2> ok
[15:14] <ko2> hm
[15:14] <ko2> nearly everything worked under UBUNTU hardy, why this little problem with KUBUNTU?
[15:15] <ko2> there are just colors inverted and some little pixels not shown
[15:15] <ko2> does lucid lynx not allow closed source kernel modules to acces the usb?
[15:16] <JanC> ko2: closed source kernel modules to access USB sounds pretty illegal to me  ;)
[15:17] <tjaalton> ko2: you had completely different hw
[15:23] <ko2> illegal? that is what the support told me, but i'll try
[15:23] <ko2> but glxinfo | grep render  tells me good things
[15:23] <ko2> rendering is acitve etc.
[15:26] <tjaalton> it still depends on which driver/hw you have how buggy it is..
[15:49] <bjsnider> tjaalton, aren't you glad you chose to enter into that last conversation?
[15:49] <bjsnider> it was so rewarding
[15:51] <tjaalton> yeah, a great way to start the week :P
[18:02] <tseliot> Sarvatt: what do we use as a fallback in Ubuntu? fbdev or vesa?
[18:02] <tseliot> I think it used to be the latter
[18:03] <Sarvatt> both, vesa fails to load if a KMS driver is loaded and it uses fbdev
[18:04] <tseliot> Sarvatt: ok, last time you mentioned a trick to cause the module to fail, something like radeon=sucks ?
[18:04] <tseliot> on boot, I mean
[18:04] <Sarvatt> yeah radeon.anythinginvalid=1 works
[18:04] <tseliot> ok, so there was a dot, I wasn't just my bad memory
[18:05] <mdeslaur> does our nouveau have 3d support for unity now in natty?
[18:06]  * mdeslaur asks before switching from nvidia back to nouveau
[18:07] <Sarvatt> mdeslaur: if you install libgl1-mesa-dri-experimental
[18:07] <Sarvatt> there's 3D support for older cards (geforce 4 era) in the default package
[18:08] <mdeslaur> Sarvatt: cool, I'll try that...thanks!
[18:19] <cnd> bryceh, do you know what the status of xorg-server in maverick-proposed is?
[18:19] <cnd> I've got a patch I need to get into maverick to fix gesture crashes
[18:19] <cnd> so what should I be doing right now?
[18:20] <cnd> should I based a branch off of maverick or maverick-proposed?
[18:23] <bryceh> cnd, let me check
[18:26] <albert23> cnd: if you do an SRU for xserver, Raof wants to fix bug 651294 in Maverick. Is it possible to combine the 2 in one SRU?
[18:26] <ubot4> Launchpad bug 651294 in xorg-server (Ubuntu) (and 1 other project) "X crash on KDM logout (still - yes, really) (affects: 22) (dups: 4) (heat: 118)" [High,Confirmed] https://launchpad.net/bugs/651294
[18:26] <cnd> albert23, sure
[18:27]  * ScottK looks up.
[18:27] <bryceh> xserver-xorg-core:
[18:27] <bryceh>   Installed: 2:1.9.0-0ubuntu7
[18:27] <bryceh>   Candidate: 2:1.9.0-0ubuntu7.1
[18:27] <albert23> cnd: thanks
[18:28] <bryceh> cnd, so yeah there's something in maverick-proposed, however it appears to not have been committed to git
[18:28] <cnd> bryceh, I thought we were moving to bzr for packaging, seeing as how bzr seems to integrate with git alright
[18:28] <cnd> but besides that, what should I do?
[18:28] <cnd> I've got bug 670016
[18:28] <ubot4> Launchpad bug 670016 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Xorg crashes when performing gesture (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/670016
[18:29] <cnd> It has a patch for xorg-server and xserver-xorg-input-evdev to fix the issue
[18:29] <cnd> and it's tested and ready to go
[18:30] <bryceh> cnd, hmm, well the date on this change is Nov 22nd
[18:30] <bryceh> so it looks like someone needs to fill or kill this out of proposed
[18:30] <bryceh> I think that's the first step
[18:31] <bryceh> (bug #650539)
[18:31] <ubot4> Launchpad bug 650539 in xorg-server (Ubuntu Maverick) (and 6 other projects) "SRU: Launching a Qt app crashes X when using Xinerama (affects: 95) (dups: 10) (heat: 591)" [High,Fix committed] https://launchpad.net/bugs/650539
[18:32] <bryceh> hrm it looks stuck
[18:32] <bryceh> (there's a possible regression)
[18:37] <bryceh> cnd, ok so number your change  2:1.9.0-0ubuntu7.2
[18:38] <cnd> bryceh, should it be based on top of 7.1?
[18:38] <cnd> or is that patch being dropped?
[18:38] <bryceh> cnd, yes
[18:38] <cnd> ok
[18:38] <bryceh> cnd, assume it is being kept
[18:38] <bryceh> (if it isn't, it's not something you'd need to deal with)
[18:42] <mdeslaur> wow, nouveau is absolutely horrific with images.google.com
[18:45] <cnd> bryceh, ok, I've updated the branches linked to the bug as appropriate
[18:45] <cnd> bryceh, what should I do next?
[18:46] <cnd> bryceh, btw, weren't we switching to using launchpad bzr for the X packaging, since bzr seems to have good git support now?
[18:46] <cnd> or was it the other way around? :)
[18:46] <bryceh> oh right, I didn't answer you
[18:47] <bryceh> sorry, yeah we've been discussing that, but we're still using git for xserver
[18:47] <bryceh> on my todo list is to mess around with the bzr<->git support with xkeyboard-config and see if it works as smoothly as advertised
[18:48] <cnd> ahh, that's right
[18:48] <bryceh> but just been too busy with other things so far
[18:48] <cnd> well, I've only updated lp, but if you need me to do some git pushes I can do that
[18:48] <bryceh> right, so the next step is to get the bug report in SRU shape
[18:49] <bryceh> cnd, that'd be great - for most X packages we don't bother setting up a git branch for srus and just push them in, but there's enough stuff for xserver that we've been keeping a branch for all of its changes
[18:49] <cnd> bryceh, ahh right, I can get it in sru shape
[18:49] <bryceh> cnd, clearly we're inconsistent on doing that though, but that's the idea
[18:50] <bryceh> cnd, https://wiki.ubuntu.com/StableReleaseUpdates explains what's needed
[18:51] <cnd> bryceh, currently natty has the same gesture stack as maverick, but natty won't have the gesture stack in the end
[18:51] <bryceh> 650539 is a pretty good example of the level of detail we shoot for in sru's
[18:51] <cnd> should I worry about preparing a natty version?
[18:51] <bryceh> you should either do that, or explain in the sru why/when something else will be fixing it
[18:52] <bryceh> e.g. "This fix will come automatically when we update to foobar 1.2.3"
[18:53] <bryceh> if there's any chance the other fix might conceivably not go in, I'd tend to upload that to the development version to, just to be safe
[19:07] <cnd> bryceh, the bug report is ready for sru
[19:07] <cnd> I'm working on the git sync now
[19:18] <bryceh> cnd, excellent
[19:19] <cnd> bryceh, you want me to push both 7.1 and 7.2 to the debian git repo?
[19:19] <cnd> 7.2 includes my patch for xserver
[19:20] <bryceh> yes
[19:20] <bryceh> cnd, if you can do them as two separate commits, that'd be ideal in case the 7.1 change has to be reverted
[19:20] <bryceh> but no biggie if that's too complicated
[19:20] <cnd> nah, it was easy
[19:21] <cnd> bzr diff -c <revno>
[19:21] <cnd> git apply
[19:21] <cnd> debcommit
[19:21] <bryceh> oh nice
[19:23] <cnd> I even fixed up the author for Alberto's change :)
[19:23] <cnd> bryceh, http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu-maverick
[19:23] <cnd> bryceh, anything else I can do to help?
[19:24] <bryceh> cnd, all that's left is to upload it to -proposed and sub the sru team, and I'll take care of that for you, thanks for doing all the heavy lifting :-)
[19:24] <cnd> great!
[19:24] <cnd> now, back to multitouch work...
[19:26] <cnd> bryceh, if you would, please review my xserver-xorg-input-evdev debian/control change closely
[19:26] <cnd> I want to make sure I got the dependency right
[19:26] <bryceh> ok
[19:37] <bryceh> cnd, what would happen if someone updated to this version of -evdev without upgrading xserver?
[19:37] <cnd> bryceh, probably a crash as soon as they tried to perform a gesture
[19:37] <bryceh> i.e. would it break any worse than already?
[19:37] <cnd> yes
[19:37] <cnd> for example, I've never seen this crash
[19:37] <bryceh> mm ok
[19:37] <cnd> but others see it multiple times a day
[19:38] <cnd> so it would be worse for me :)
[19:38] <bryceh> then I think technically the control file looks correct to me
[19:38] <cnd> ok, thanks
[19:38] <bryceh> but I wonder if it might make the sru process easier if the patch could be done in a way that won't crash regardless of xserver version?
[19:38] <cnd> I don't think there is a way, unless you check the debian package version of the server in the evdev source code
[19:38] <bryceh> iow, there could conceivably be cases where someone wishes to use an older xserver for some random reason...  would be nice to let them continue doing so without having to also pin -evdev
[19:39] <cnd> yeah, I understand why that would be nice, but I'm not sure how we could make that happen
[19:39] <cnd> essentially, the ABI of the xserver is being bumped
[19:39] <cnd> but it's a private ABI that only evdev knows about
[19:39] <cnd> hence why there's no change to the header files of the server
[19:41] <bryceh> cnd, what about some sort of #define in an xserver header, and then mess up -evdev with some #ifdef's ?
[19:41] <bryceh> yeah, I know, fugly
[19:42] <cnd> bryceh, yeah, I'd rather not touch upstream xserver headers
[19:42] <cnd> and I don't want to make the patches more complicated than needed for an sru
[21:26] <bryceh> Sarvatt, hey where is that edid write kernel patch you pointed me at the other week?  I've lost track of it.
[21:33] <Sarvatt> bryceh: http://www.spinics.net/lists/dri-devel/msg00802.html
[21:33] <bryceh> Sarvatt, thanks
[21:49] <Sarvatt> hmm, hd 5xxx acceleration looks to be a bit much to just pull into x-x-v-ati 6.13.2
[21:49] <Sarvatt> we still don't get 3D out of the box on those, just saw a bug on natty about it
[22:23] <bryceh> Sarvatt, yeah what's still needed there?
[22:23] <Sarvatt> ton of commits just after 6.13.2 released
[22:24] <bryceh> I saw that it's marked on the ati features page such that it looks like it'd work, however I was messing around with it on my evergreen card the other day and couldn't get it to do other than software rendering
[22:24] <Sarvatt> just the x-x-v-ati side
[22:24] <Sarvatt> its supported in the kernel and mesa already
[22:26] <bryceh> great, we should pull in the newer -ati then
[23:29] <Milos_SD> Hi
[23:30] <Milos_SD> Can nvidia binary driver cause xserver to use all the memory?
[23:30] <Milos_SD> can that be the nvidia driver memory leak?
[23:35] <bryceh> anything can cause a memory leak
[23:35] <bryceh> however, most typically what causes X to use up memory is usually client applications
[23:37] <bjsnider> he left the room before you said that
[23:37] <bryceh> ah
[23:38] <ion> Well, he displayed more patience than should be required of people. He waited for almost a minute before leaving.
[23:41] <bryceh> ion, heh