=== seb128_ is now known as seb128
[09:50] <wgrant> Hmm, I see that there are significant changes to the server's XI property support...
=== torkel__ is now known as torkel
[11:23] <tjaalton> wgrant: what where?
[11:24] <wgrant> tjaalton: Configure/Query gone, more return values... Peter posted the patches to the list a few hours ago.
[11:24] <tjaalton> wgrant: oh right, reading now
[11:27] <wgrant> I wonder if we want those in Intrepid.
[11:27] <wgrant> As otherwise nothing will build post-release.
[11:28] <tjaalton> what do you mean?
[11:29] <wgrant> If we don't have those patches in Intrepid, people building XI-property-using apps on Intrepid will get annoyed.
[11:29] <wgrant> Because the API differs.
[11:30] <tjaalton> oh right
[11:30] <wgrant> And we'll probably be the only people with the ABI we have.
[11:30] <wgrant> *API
[11:30] <tjaalton> well, we also need the rest of the stuff before those can be pushed
[11:30] <tjaalton> but I'll update the server
[11:33] <wgrant> The g-s-d and g-c-c patches will also need alteration since XQueryDeviceProperty vanished.
[11:39] <tjaalton> hum, the patches are for master
[11:39] <tjaalton> hardly surprising, but maybe I'll wait until he backports it for 1.5
[11:44] <wgrant> Ah, right.
[12:05] <tseliot> tjaalton: I have put that fix for the nvidia driver in the postinst instead of the preinst since DKMS removes and adds directories in the postinst. It works well and removes those obsolete directories
[12:07] <tseliot> I have also updated the driver to the latest beta. I'll upload the source and post the links
[12:07] <tjaalton> tseliot: ok, cool
[13:41] <tseliot> tjaalton: the source for the 2 drivers are here: http://albertomilone.com/ubuntu/newlrm/pitti/lista_ia.txt
[13:41] <tseliot> can you upload them, please?
[13:48] <tjaalton> tseliot: done
[13:48] <tseliot> tjaalton: thanks a lot
[13:56] <tjaalton> np
=== superm1 is now known as superm1|away
[15:34] <mvo> tjaalton, tseliot: any idea about the following error: http://rafb.net/p/ElfRoh20.html ?
[15:34] <mvo> this happend after mvg upgraded to intrepid
[15:35] <tseliot> mvo: I haven't written a patch for kernel 2.6.27 since the driver would only build but wouldn't load because of the xorg ABI
[15:36] <tseliot> mvo: are you trying to use the driver with the old xorg and the new kernel?
[15:36] <MvG> tseliot: A patch to make do without asm/semaphore.h?
[15:37] <MvG> Completely upgraded intrepid, kernel and xorg, afaict.
[15:37] <mvo> tseliot: oh, so this nvidia packages does not work on intrepid at all? then I should remove it from update-managers nvidia detection?
[15:38] <tseliot> MvG: usually I can get rid of compilation errors. Making it work with the new xorg ABI is a different thing though
[15:38] <MvG> If there is another nvidia package likely to work instead of that one, you might.
[15:38] <mvo> tseliot: which of the nvidia drivers are affected by this?
[15:38] <MvG> -93 iirc, checking...
[15:38] <tseliot> mvo: I have worked on nvidia-common so that we can blacklist certain drivers and suggest/force the use of open drivers if necessary
[15:39] <MvG> nvidia-glx-96
[15:39] <tseliot> mvo: it's not finished yet since it lacks the support for x-kit
[15:39] <tseliot> mvo: it affects 96 and 71
[15:39] <tseliot> and fglrx
[15:39] <MvG> So you'd suggest switching to open nv drivers for the time being?
[15:40] <tseliot> MvG: yes
[15:40] <MvG> Have you checked whether other distros might have done work migrating to new X abi?
[15:40] <MvG> (As I'm running an nvidia driver on Gentoo testing as well, though probably a different version)
[15:40] <tseliot> MvG: that's something that only NVIDIA can do
[15:41] <jcristau> MvG: that would only be doable if we had the source
[15:41] <MvG> It's in the closed part of the code? Too bad!
[15:41] <tseliot> yep
[15:41] <mvo> tseliot: thanks for this information. should I just wait then for nvidia-common or modify the update-manager code to do something if those drivers are detected
[15:41] <jcristau> MvG: there's pretty much no open part
[15:42] <MvG> jcristau: Well, at least they do have enough iopen source code to be compiuled on the client to cause the compiler errors mentioned in my paste... :-/
[15:42] <jcristau> MvG: that's the kernel part
[15:43] <MvG> jcristau: True. Point taken.
[15:43] <jcristau> which, indeed, has a small sourceful wrapper
[15:43] <tseliot> mvo: I'll preserve nvidia-common's current behaviour so that it doesn't break Jockey and Update Manager
[15:44] <MvG> I guess one could technically tweak the symbol table of the closed source driver in order to replace official X interfaces with compatibility wrappers. I don't know the overhead for this, and neither the legality.
[15:44] <tseliot> mvo: however, when the new nvidia-common is finished you'll have to modify Update Manager a bit so that it can use the new blacklisting functionality
[15:45] <jcristau> MvG: changes are big enough that a compat wrapper would be a lot of work, if at all feasible
[15:45] <tseliot> MvG: the symbol itself is not the main problem. AllocatePrivateScreenIndex is the problem
[15:46] <tseliot> after all we're talking about an ABI which was changed
[15:48] <MvG> I notice that nvidia offers 96.43.07 for download, dated July 16, 2008. Ubuntu installed 96.43.05-0ubuntu10.
[15:49] <MvG> I can see no obvious ChangeLog, though.
[15:49] <tseliot> believe me, if it had solved the problem I would have updated the driver in July.
[15:50] <MvG> OK.
[15:52] <tseliot> tjaalton: did you upload my patch? https://bugs.launchpad.net/bugs/271823
[15:52] <ubottu> Ubuntu bug 271823 in xfree86-driver-synaptics "[intrepid] touchpad less responsive and top/bottom-right corner tapping disabled" [Undecided,Confirmed] 
[15:52] <tseliot> it works for another user too
[15:59] <mvo> tseliot: I'm slightly worried that we currently have 3 (closed source) video drivers that will fail to upgrade and give the user a bad expeience and beta freeze is just three days ahead. I imagine a lot of users will upgrade at beta time and I would really like to transition them autoamatically to free drivers if the closed-source drivers can not be fixed. what do you think about it? I would (naturally) do it in update-manager, but if its done in
[15:59] <mvo>  nvidia-common or via fallbacks somwehre else that is fine with me of course 
[15:59] <mvo> (well, not fail to upgrade but fail to work after the upgrade :)
[16:01] <tseliot> mvo: I was thinking that you could use nvidia-common as a library and pass it the driver which you would like to blacklist
[16:02] <tseliot> mvo: I will try to finish it in time, ok?
[16:03] <tseliot> in time for the freeze, I mean
[16:05] <mvo> tseliot: it seems to me that is "selectDriver()" would just not return the two that do not work, then we are done, or am I missing something?
[16:08] <tseliot> mvo: but if a user is using a driver with the old name scheme that wouldn't be removed and will cause problem during the update
[16:09] <tseliot> s/problem/problems/
[16:10] <tseliot> mvo: I have written a method which returns the driver which should be used in the xorg.conf
[16:10] <mvo> tseliot: how is that called?
[16:10] <tseliot> so that if a driver is blacklisted, a free alternative will be returned
[16:10] <mvo> is that not "selectDriver()" ?
[16:10] <mvo> (because that is what I use in update-manager) 
[16:11] <tseliot> mvo: currently it's filterDrivers() but I haven't uploaded the new release yet
[16:11] <tseliot> mvo: selectDriver() is ok and returns the right package to install
[16:11] <tseliot> I know, filterDrivers sucks as a name
[16:12] <mvo> ok, thanks. so currently it will return nvidia-glx-96 for example but if nvidia-common gets updated it would return xserver-xorg-video-nv ?
[16:12] <mvo> will xorg.conf rewriting (if one exists) be hanlded by nvidia-common then too?
[16:14] <tseliot> mvo: not exactly. You can pass the constructor a dictionary with the proprietary (e.g. nvidia) and the free driver ('nv') for a certain kind of driver together with the version you would like to blacklist (e.g. 96)
[16:14] <tseliot> then filterDrivers() would return either the proprietary (nvidia) or the free (nv) driver
[16:15] <tseliot> while selectDriver() will still return the nvidia package with the new name scheme
[16:16] <mvo> wouldn't it be better to put the blacklist into nvidia-common too? so that we have the information in one place what drivers do not work? otherwise both update-manager and jockey would have to have the blacklist information (two places instead of a single one)
[16:17] <tseliot> but of course if filterDrivers() returns what you passed as the free driver then you shouldn't install the new driver but simply remove the old one (in self.oldpackages)
[16:18] <tseliot> mvo: yes, sure I can do it in nvidia-common. Furthermore I'll add another module so as to deal with the xorg.conf with x-kit
[16:19] <tseliot> but then the debconf message will have to be updated (so that users are informed about what's going to happen)
[16:19] <mvo> tseliot: ok, thanks. keep me updated, I will modify update-manager then to use the new interfaces
[16:20] <tseliot> mvo: ok, I'll work on it and get back to you as soon as it's ready
[16:20] <mvo> tseliot: debconf> I was thinking that we may want to put a custom message in update-manager so that users who do not want to loose desktop effects get a warning before the upgrade about the fact that they will loose the nvidia/fglrx drivers
[16:21] <jcristau> they can has compiz with radeon though, at least on r500
[16:21] <tseliot> mvo: sure, it's a good idea. I was referring to debconf because I was thinking about the users who will dist-upgrade from the command line
=== superm1|away is now known as superm1
[16:22] <mvo> right, its good to have both I think
[16:23] <tseliot> mvo: in any case the proprietary driver should be removed otherwise the open source counterpart won't be able to use mesa properly
[16:23] <mvo> jcristau: yeah, that is very cool (I have a r500 myself and I'm pretty impressed with the new ati)
[16:23] <mvo> tseliot: right
[16:48] <soren> A bit of help? I'm trying to figure out why I don't have any dead keys anymore?
[16:49] <soren> I used to be able to press ´a and get an accented a, but now I just get the accent straight away.
[16:49] <soren> "setxkbmap -print" doesn't say nodeadkeys anywhere.
[18:01] <maco> when compiz is in use and gstreamer's video playback is buggy, is that a gstreamer bug, a compiz bug, or a driver bug?
[18:20] <bryce> morning
[19:38] <tseliot> maco: what do you mean by buggy? Which card/driver do you use? Can you reproduce the problem using xine?
[19:40] <maco> tseliot: not my bug, just triaging. bug 270723  i marked it for xserver-xorg-video-intel but i wanted to check
[19:40] <ubottu> Launchpad bug 270723 in xserver-xorg-video-intel "Movies don't move with Compiz" [Undecided,Incomplete] https://launchpad.net/bugs/270723
[19:42] <jcristau> probably expected if you're using the overlay.
[19:43] <jcristau> the textured adaptor should work fine
[19:43] <tseliot> jcristau: ah, textured video
[19:43] <jcristau> tseliot: hmm?
[19:44] <maco> i assume that's somewhere in totem's preferences? i use totem-xine for better dvd support, so idk how the gstreamer one works
[19:45] <jcristau> maco: what's the first adaptor listed by xvinfo?
[19:45] <tseliot> jcristau: there was an option to tell X (explicitly) to use Textured Video in the xorg.conf
[19:46] <maco> jcristau: should i ask that of the bug reporter?
[19:50] <tseliot> jcristau: aah, we had a patch thanks to which we could enable/disable textured video in ubuntu > Option "TexturedVideo" "true"
[19:51] <tseliot> but it should be used automatically now
[19:55] <tseliot> maco: I have added a comment to the bug report with the instructions to configure gstreamer
[19:55] <tseliot> oh, you have replied too
[19:56] <maco> tseliot: yours is better. i dont know where the settings are and what the options are in totem-gstreamer
[19:57] <maco> though this does make me want to ask what to do about that thing where video goes blue with xine+compiz
[19:59] <tseliot> maco: have a look at what I suggested here: http://ubuntuforums.org/archive/index.php/t-456842.html
[19:59] <tseliot> or here: http://ubuntuforums.org/showthread.php?t=532976
[20:00] <maco> tseliot: alright, thanks
[20:00] <tseliot> maco: thanks for dealing with these bug reports
[20:01] <maco> tseliot: the file you pointed to in that forum post doesn't exist
[20:01] <tseliot> maco: the configuration file?
[20:01] <maco> right
[20:02] <maco> i would assume there's some syntax beyond typing in the word xshm and saving it
[20:05] <tseliot> maco: try with ~/.xine/config
[20:06] <maco> also doesn't exist
[20:06] <maco> er, should say i'm using hardy
[20:06] <maco> in case that makes a difference
[20:08] <tseliot> maco: in Hardy I have both .gnome2/Totem/xine_config and ~/.xine/config
[20:08] <tseliot> but I guess you'll have to install and use (at least once) totem-xine and xine
[20:10] <maco> i do use totem-xine
[20:11] <maco> because gstreamer doesn't do dvd menus
[20:11] <maco> what's the syntax for those files?
[20:12] <tseliot> try .config/totem/xine_config
[20:13] <maco> tseliot: ah yeah that one exists
[20:14] <tseliot> maco: ok, replace #video.driver:auto with video.driver:xshm (yes, without #)
[20:14] <tseliot> and see if it solves the problem
[20:15] <maco> tseliot: thanks. i'll test it when i'm not in class :-X
[20:18] <tseliot> maco: ah, ok, have fun then ;)
[20:18]  * tseliot > off for a bit. Bbl
[20:36] <tjaalton> tseliot: sorry, I'll add it tomorrow
[20:43] <bryce> superm1: I've sorted out that gradient banding problem
[20:44] <bryce> superm1: turned out to be more difficult than I'd bargained for to enable dithering, but it looks pretty good now.  Not perfect, but you really have to look to see the banding now.
[20:44] <superm1> bryce, ah great to hear
[20:49] <bryce> superm1: apparently the registers on this hardware were moved around to make room for the display port stuff
[20:51] <superm1> bryce, so it's a special case of the 3670, or this will help all 3670's?
[20:51] <bryce> all 3670's
[20:52] <superm1> ah very good.  that will help some other platforms coming out too then
[20:53] <bryce> superm1: actually, I'm not sure if 3670 == rv635, or is more or less inclusive, but I structured this patch to target rv620, rv635, rs780, rv770, all of which have the register change as I understand it
[20:54] <bryce> in any case, if the issue crops up again, I know how to fix it better now :-)
[20:54] <superm1> awesome
[20:54] <bryce> however I think it may require a deeper fix to make it perfect - the banding is still there if you look really closely
[20:54] <bryce> most people probably won't care, but hardcore Inkscape users would probably freak out ;-)
[20:55] <superm1> how is the card looking otherwise?
[20:56] <bryce> great, haven't seen any other major problems, although I've not pushed it too hard.  I'll do some power management and xrandr trickery
[21:02] <bryce> runs kinda hot
[21:02] <tseliot> tjaalton: no problem ;)
[21:34] <bryce> patch uploaded
[21:53] <superm1> tseliot, is python-xkit adding Disable "dri2" to xorg.conf?
[21:53] <superm1> when enabled via jockey
[21:54] <tseliot> superm1: yes
[21:54] <tseliot> is it a problem?
[21:54] <superm1> tseliot, yes it causes amdcccle to crash
[21:54] <superm1> because it doesn't think disable is a valid keyword
[21:54] <superm1> is it still necessary that it be there?
[21:55] <tseliot> superm1: no, I can remove it
[21:55] <superm1> tseliot, yes please do
[21:55] <superm1> thanks
[21:55] <tseliot> superm1: I'll have to do that in jockey
[21:56] <superm1> tseliot, i'll file a bug in jockey about it so that pitti is aware of it coming then too
[21:57] <tseliot> superm1: ok, great. BTW that would only require the fglrx handler to be modified
[21:57] <tseliot> superm1: feel free to assign the bug to me
[21:58] <superm1> tseliot, okay will do
[21:58] <tseliot> good
[21:59] <superm1> tseliot, i'm assuming the no reboot dialog popup is affecting all drivers not just fglrx?
[21:59] <superm1> or is there a quirk needed for that too?
[22:00] <tseliot> superm1: it will affect all drivers
[22:00] <superm1> tseliot, okay then i'm sure pitti is aware of that
[22:01] <tseliot> superm1: yes, we have talked about that. I'm working with him on jockey
[22:02] <superm1> other than this dri2 thing, and needing to depend on fglrx-modaliases when it works with xorg 1.5, i dont see any other things standing out as bugs particularly with fglrx and jockey then
[22:04] <tseliot> superm1: great. Furthermore thanks to my recent work jockey removes the fglrx-kernel-source package too
[22:05] <superm1> tseliot, yeah i saw that in the bug mail, but i've not been able to test it since the upload was a FTBFS
[22:06] <tseliot> superm1: you refer to fglrx, right?
[22:07] <superm1> tseliot, no i mean jockey was FTBFS
[22:07] <superm1> the latest upload that pitti sent up
[22:07] <tseliot> I didn't know that
[22:07] <superm1> https://edge.launchpad.net/ubuntu/+source/jockey/0.5~alpha1-0ubuntu3/+build/721114
[22:08] <superm1> pitti should have gotten some build mail about the FTBFS, so he should be aware
[22:09] <tseliot> superm1: I bet he's aware of it. Either way I'll have a look at the code tomorrow.
=== superm1 is now known as superm1|away