[00:05] <james_w> hey, someone's requested a sync of input-mutouch, to pull in jcristau's Y axis fix, are you ok for this to be synced?
[00:05] <james_w> bug 275650#
[00:05] <ubottu> Launchpad bug 275650 in xserver-xorg-input-mutouch "[UVFe] Please sync xserver-xorg-input-mutouch (1.2.0-2) from Debian unstable (main) - fixes: mutouch driver in hardy is Y axis Inverted" [Medium,Confirmed] https://launchpad.net/bugs/275650
[00:07] <bryce> james_w: got a debdiff?
[00:07] <bryce> brb
[00:09] <james_w> bryce: it's a sync request
[00:11] <bryce> james_w: right - the diff between what we currently have and what's upstream
[00:12] <james_w> ah, give me one moment please
[00:13] <bryce> in any case, I'd not be predisposed to syncing it.  at this late stage in the release cycle we need to take care to do code reviews on changes coming in, for sanity check since there's limited time left for extensive testing
[00:13] <bryce> also, understanding what changed can help if people report seeing regressions
[00:14] <james_w> http://paste.ubuntu.com/55818/
[00:25] <bryce> james_w: thanks.  Yes that looks fine.  +1 from me to sync
[00:25] <james_w> bryce: thanks, I'm just doing a test build/install
[02:34] <wgrant> Should bcm5974 tocuhpads really have SHMConfig on by default?
[07:27] <wgrant> tjaalton: Apart from evdev in your PPA having broken deps (probably due to the xserver-xorg-core shlibs), it all looks good to me. I've got g-c-c and g-s-d working with it all.
[07:27] <wgrant> And it no longer hangs.
[07:28] <wgrant> Which is excellent.
[07:34] <tjaalton> wgrant: goody, so it's upload time
[07:35] <wgrant> wgrant: Just watch out that your new shlibs are correct.
[07:35] <wgrant> They look like they should be good for upload, but I'm not entirely sure.
[07:36] <wgrant> GAAH
[07:36] <tjaalton> wgrant: what's wrong and where?
[07:36] <wgrant> I am obviously doing multiple things.
[07:36] <wgrant> tjaalton: evdev wants xserver-xorg-core 0ubuntu3.
[07:36] <wgrant> Only 0ubuntu2.2 is in your PPA.
[07:36] <wgrant> But 0ubuntu3 for be correct for upload to the primary archive.
[07:37] <tjaalton> yeah, right
[07:37] <tjaalton> it's fixed here
[07:38]  * wgrant loves being able to test changes to input drivers without restarting the X session.
[07:38] <tjaalton> ain't that cool
[07:40] <tjaalton> bryce: around? we've now finished what needs to be done for bug 274728
[07:40] <ubottu> Launchpad bug 274728 in xorg-server "Update the input properties API to current version" [Undecided,In progress] https://launchpad.net/bugs/274728
[07:41] <tjaalton> wgrant: have you contacted seb128?
[07:41] <tjaalton> doesn't seem to be around yet
[07:42] <wgrant> tjaalton: I haven't - I wasn't sure if I would have time to finish everything before the weekend until this morning.
[07:42] <bryce> tjaalton: yep I'm here
[07:43] <bryce> tjaalton: btw I sorted out that brightness key issue mdz had
[07:43] <bryce> turned out to be a gnome-power-manager bug.  I did a patch and posted it to the bug.  Probably needs to be more cleverly thought out, but that's for the GNOME guys to nut out I guess.
[07:44] <tjaalton> bryce: whee
[07:45] <bryce> oh, and the thinkpad-specific aspect (numlock not being able to be turned off) seems to be a kernel issue
[07:45] <wgrant> I need to get my g-p-m bug sorted out, too.
[07:46] <tjaalton> bryce: so, do you ack the uploads? they update the API to the current/"finished" one. If we don't do this, we'd be incompatible with upstream, and backporting properties related stuff from upstream would be more work
[07:46] <tjaalton> bryce: I'd also add some patches to the xserver from upstream 1.5-branch
[07:47] <wgrant> I hope they fix that BadDevice issue that many are having.
[07:47] <bryce> tjaalton: hm, I'd like to see what the diffs are
[07:47] <tjaalton> bryce: http://cgit.freedesktop.org/xorg/xserver/?h=server-1.5-branch
[07:47] <bryce> I don't have anything against it in principle, although it sounds like a significant change so is scary from that perspective
[07:48] <tjaalton> now that the devPrivates-commit was reverted, it should be safe to just sync to head of that branch
[07:48] <tjaalton> there aren't that many commits
[07:48] <tjaalton> 11 after 1.5.1
[07:49] <tjaalton> wgrant: that's properties behaving badly, and hopefully my backport fixes that
[07:49] <wgrant> tjaalton: That's what I was referring to.
[07:49] <tjaalton> wgrant: ah, ok
[07:49] <wgrant> Maybe I can convince RAOF to check it out now...
[07:49] <tjaalton> wgrant: please do, would make me even more comfortable with this :)
[07:50] <bryce> hmm, still looks like a lot to digest
[07:51] <tjaalton> what does? the xkb fixes?
[07:52] <bryce> the 11 changes in the branch... give me a few minutes, still reading
[07:52] <tjaalton> look at the lines changed :)
[07:52] <tjaalton> ok
[07:52] <wgrant> Only the XKB ones are non-trivial.
[07:53] <tjaalton> and those are long-standing bugs
[07:54] <wgrant> Ow. The synaptics driver's logic hurts.
[07:56] <bryce> yeah looks good
[07:56] <tjaalton> bryce: great, thanks
[07:57] <bryce> if you can associate at least some of those changes with bug id's in some bug tracker, that would be much preferred
[07:57] <tjaalton> sure
[07:57] <tjaalton> in fear of the wrath of slangasek ;)
[07:57] <bryce> right
[07:58] <bryce> yeah, the b595b65e change took time to get through but I see it's just a revert of an addition that was made in this same set of patches
[07:58] <tjaalton> yes, ajax said it'd be an ABI change
[07:58] <bryce> let me look at the input properties change
[07:59] <tjaalton> it's on my local tree, let me push to git.d.o first
[07:59] <bryce> er, wait, where's the diff for that
[07:59] <bryce> ah ok
[07:59] <bryce> can you pastebin a diff?
[07:59] <tjaalton> sure
[08:01] <bryce> also, what needs the updated input property stuff exactly?
[08:01] <wgrant> g-c-c, g-s-d and xinput are the only clients at the moment.
[08:01] <bryce> I'm guessing we're not going to be doing a lot of sruing of stuff like after hardy
[08:02] <tjaalton> bryce: http://users.tkk.fi/~tjaalton/dpkg/xserver-prop.diff
[08:02] <wgrant> I presume not.
[08:03] <tjaalton> bryce: the diff looks messy, since the patches were merged to keep my sanity
[08:03] <tjaalton> bryce: but in a nutshell; a couple of functions were deleted
[08:03] <wgrant> And some args changed.
[08:03] <tjaalton> right
[08:04] <wgrant> But those are trivial.
[08:04] <tjaalton> hmm, the patch header is not right anymore
[08:04] <tjaalton> might just as well delete it
[08:04]  * wgrant prepares g-s-d and g-c-c debdiffs.
[08:04] <bryce> "stuff->data"?  someone had a bout of uncreativity there ;-)
[08:04] <wgrant> Hmm. No seb128 to ping.
[08:05] <wgrant> Haha.
[08:05] <tjaalton> heh, that's old though
[08:09] <bryce> what functionality in g-c-c/g-s-d/xinput does it enable?  
[08:09] <wgrant> xinput - properties.
[08:09] <wgrant> g-c-c, g-s-d: Synaptics configuration.
[08:19] <bryce> hum
[08:19] <bryce> well, I see it adds an api for deleting properties, and tweaks how change properties works, but I'm not understanding how this would be required for enabling synaptics configuration or properties in general
[08:20] <wgrant> seb128: Hi. We're currently discussing fixing bug #274728, which will involve a g-s-d and g-c-c upload.
[08:20] <ubottu> Launchpad bug 274728 in gnome-settings-daemon "Update the input properties API to current version" [Low,In progress] https://launchpad.net/bugs/274728
[08:20] <wgrant> bryce: It isn't.
[08:20] <wgrant> bryce: It is required to avoid using an API that never existed in a release.
[08:20] <seb128> wgrant: don't forget to commit to bzr if you upload g-c-c otherwise no objection
[08:20] <wgrant> If we release Intrepid like this, and somebody tries to build something that uses properties (not unlikely, given their newness), they will go WTF when they see that we use an API that was never in a release.
[08:21] <wgrant> seb128: Thanks.
[08:22] <wgrant> And there's something broken with the current Intrepid backport.
[08:22] <tjaalton> bryce: http://lists.freedesktop.org/archives/xorg/2008-September/038758.html
[08:22] <bryce> thanks
[08:22] <tjaalton> the following discussion lead to some minor changes
[08:40] <bryce> tjaalton: alright, I've commented my concerns/review on the bug, and given a +1 on uploading it
[08:41] <tjaalton> bryce: great, thanks
[08:42] <wgrant> Ummm.
[08:42] <wgrant> Just found something strange with the Synaptics driver.
[08:42] <wgrant> Setting properties works.
[08:42] <wgrant> But the change isn't reflected in the properties themselves.
[08:42] <wgrant> So I can disable something using Synaptics Off, and it will disable.
[08:43] <wgrant> But it will show as enabled.
[08:43] <wgrant> Plain evdev is fine.
[08:43] <wgrant> I guess -synaptics doesn't know that it needs to say it's OK now.
[08:44]  * wgrant will look into that after eating.
[08:46] <tjaalton> wgrant: I wonder if this would help.. http://lists.freedesktop.org/archives/xorg/2008-October/039251.html
[08:46] <wgrant> tjaalton: Hmmm, I thought that would more cause it.
[08:46] <wgrant> But I guess we don't have it yet, so it can't be to blame...
[08:47] <wgrant> I guess that would fix the incompleteness, but there is still some buggy driver.
[08:47] <tjaalton> no we don't
[08:48] <tjaalton> anyway, it should be a bug in the current version as well?
[08:48] <wgrant> Ahem.
[08:49] <wgrant> It returns TRUE (1), when it's meant to return Success (0).
[08:49] <tjaalton> the driver?
[08:49] <wgrant> Yes.
[08:49]  * wgrant checks git.
[08:51] <tjaalton> didn't see anything related there
[08:52] <wgrant> All FALSEs were changed to BadMatches.
[08:52] <wgrant> But the TRUE wasn't changed to Success.
[08:52] <wgrant> I'm testbuilding now.
[08:57] <wgrant> Right, that works.
[08:58] <tjaalton> sweet
[09:01] <wgrant> I think I might review the rest of those two diffs, just in case...
[09:03] <wgrant> tjaalton: src/properties.c:507, s/TRUE/Success/
[09:04] <wgrant> I'll poke through the evdev and synaptics patches just to check there's nothing else, and submit to xorg@l.fd.o
[09:04] <tjaalton> wgrant: great, thanks
[09:09] <wgrant> tjaalton: Shouldn't 355e845 be in debian/patches somewhere?
[09:09] <tjaalton> wgrant: no, I pulled it
[09:09] <wgrant> Ah, right.
[09:09] <tjaalton> cherry-picked to be precise
[09:10] <wgrant> I really should learn how to use git properly at some point.
[09:11] <tjaalton> basically you only need a handful of commands
[09:11] <wgrant> I know how to use it locally.
[09:11] <tjaalton> oh, "properly" :)
[09:12] <tjaalton> ok, I'll upload inputproto now
[09:12] <wgrant> To primary?
[09:12] <tjaalton> yes
[09:12] <wgrant> Sounds good.
[09:12] <tjaalton> and libxi, since it b-deps on that so won't build before inputproto
[09:12] <wgrant> Then xi?
[09:12] <wgrant> Right.
[09:13] <wgrant> Then xinput, g-c-c, g-s-d and server in no particular order, then drivers after server.
[09:14] <tjaalton> well, those could be uploaded all together, because we have build-deps
[09:14] <wgrant> True.
[09:20] <bryce> I've filled in the -fglrx section on https://wiki.ubuntu.com/X/Drivers
[09:20] <bryce> (trying to make the best of the sad situation)
[09:21] <wgrant> I added more versioning information to the mess that is X/Config earlier.
[09:21] <bryce> need to get the rest of that page updated
[09:22] <bryce> wgrant: which portions do you think are a mess?
[09:23] <wgrant> bryce: It's a big mess of versions. Some stuff only applies to Intrepid, some only to Hardy and before, and they're almost completely different.
[09:23] <wgrant> Some of the info was also wrong.
[09:24] <tjaalton> peple seem to be confused and believe that no input driver can be configured with xorg.conf anymore, when it's only the ones that hal knows about
[09:25] <wgrant> Which doesn't it know about?
[09:25] <wgrant> wacom?
[09:25] <bryce> maybe we should make it Intrepid-only
[09:25] <wgrant> bryce: An Intrepid-only version would probably be good.
[09:25] <wgrant> But replacing it would be bad.
[09:25] <bryce> why?
[09:26] <wgrant> Or maybe shifting the pre-Intrepid stuff to another page.
[09:26] <wgrant> People still ues Hardy.
[09:26] <wgrant> And will for years.
[09:26] <bryce> I think it should also be broken into separate pages for video configuration vs. input configuration
[09:27] <wgrant> Definitely.
[09:27] <wgrant> It's fairly big and confusing as is, and there's little reason to squish them together.
[09:28] <tjaalton> wgrant: serial devices for instance
[09:28] <tjaalton> I'm wondering if the current wacom hal fdi is useful at all
[09:28] <wgrant> tjaalton: That's what I thought. Hmm.
[09:28] <wgrant> Wouldn't some wacom devices be USB?
[09:28] <tjaalton> since to be able to configure wacom fully, you need to add another fdi file to _not_ load the driver, and use the old xorg.conf you had for ages
[09:29] <wgrant> So hal-detectable?
[09:29] <tjaalton> most attachable are
[09:29] <wgrant> Why not use an fdi file with the appropriate config info?
[09:29] <tjaalton> but tablets tend to be serial onew
[09:29] <tjaalton> -s
[09:29] <tjaalton> wgrant: not possible
[09:30] <tjaalton> since you can only load the driver once, when the old method does that three times
[09:30] <wgrant> Oh.
[09:30] <tjaalton> for the different "devices", stylus, pen etc
[09:30] <wgrant> Wow.
[09:30] <wgrant> That's special.
[09:30] <wgrant> Really special.
[09:30] <tjaalton> the driver is just lacking here
[09:30] <tjaalton> but who knows how long it'll take for them to fix that
[09:31] <tjaalton> bryce: you have an opinion about this?
[09:32] <wgrant> http://www.qeuni.net/f/1/2008/g-s-d_2.24.0-0ubuntu2.diff is the g-s-d debdiff (a segfault fix and some deconfused warnings are also there, which I guess aren't strictly necessary)
[09:32] <bryce> tjaalton: I haven't looked into wacom for a few weeks but I wasn't able to get it configured using i-h; only by disabling it and doing it the old fashioned way with xorg.conf
[09:32] <bryce> tjaalton: so yeah I don't know that the current wacom fdi is of use to anyone
[09:33] <tjaalton> bryce: yeah, maybe I'll drop it then
[09:33] <wgrant> https://code.edge.launchpad.net/~wgrant/gnome-control-center/bug-274728 is the g-c-c change.
[09:34] <bryce> wgrant: anyway if you feel like breaking out / rewriting the intrepid input config stuff, knock yourself out.  I did the current stuff back before we really knew how it would work; perhaps it would have been better to not write at all.  ;-)
[09:34] <wgrant> bryce: I was planning on at least refactoring it when I had time.
[09:35] <bryce> wgrant: great thanks
[09:36] <tseliot> tjaalton: how can you use an fdi file to prevent a driver from loading?
[09:36] <tjaalton> tseliot: use the same logic and leave x11_driver empty
[09:37] <tseliot> aah
[09:38] <tseliot> tjaalton: but you can still set properties, can't you?
[09:39] <tjaalton> tseliot: if the driver is set, yes
[09:39] <tseliot> oh but this would involve adding a section for each device in xorg.conf
[09:39] <tseliot> with the driver
[09:40] <bryce> night
[09:40] <tseliot> good night bryce
[09:40] <tjaalton> night
[09:41] <wgrant> Night bryce.
[09:42] <tseliot> tjaalton: if application has to configure a wacom tablet it should 1) add 3 InputDevice sections to xorg.conf and set the driver 2) customise the fdi file. Is this correct?
[09:42]  * tseliot will buy a wacom tablet for testing sooner or later
[09:43] <tjaalton> tseliot: I'll drop the fdi file from the driver, since it leaves the device partly unconfigured
[09:43] <tjaalton> so you only need to do 1)
[09:44] <bryce> tseliot: msg me your postal address and I'll send you one
[09:44] <tseliot> bryce: really? Thanks a lot :-)
[09:47] <tjaalton> tseliot: is this for intrepid or jaunty?
[09:48] <tseliot> tjaalton: jaunty
[09:52] <tjaalton> tseliot: would be nice if it was backportable to intrepid
[09:52] <tjaalton> to shut up all the wacom-nuts :)
[09:53] <tseliot> tjaalton: we would have to backport the input module of python-xit too
[09:53] <tseliot> but it would be trivial to do so
[10:25] <tjaalton> wgrant: you need a sponsor?
[10:26] <elmargol> still no solution for my nvidia problem. Is there a way to contact a nvidia developer?
[10:26] <tjaalton> elmargol: nvidia-bug-report.sh
[10:27] <elmargol> tjaalton: i have to use the binary drivers for this?
[10:27] <tseliot> elmargol: try here: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
[10:28] <tjaalton> elmargol: you need to have it installed, yes
[10:32] <wgrant> tjaalton: I do - I'm only a MOTU.
[10:33] <tjaalton> wgrant: I can upload g-s-d, but don't know what needs to be done for g-c-c
[10:33] <wgrant> tjaalton: You need to merge my branch into ~ubuntu-core-dev/gnome-control-center/ubuntu
[10:33] <wgrant> And then upload as normal.
[10:34] <wgrant> seb128: Are there instructions for that around?
[10:34] <wgrant> All packages seem to do it differently, and g-c-c is particularly odd.
=== crevette_ is now known as crevette
[10:34] <seb128> mvo: that's for you ;-)
[10:34] <elmargol> http://www.nvnews.net/vbulletin/showthread.php?t=120896
[10:34] <tjaalton> I reviewed the merge
[10:34] <tseliot> maybe you can ask mvo to merge from your branch
[10:34] <seb128> wgrant: my bzr foo is limited, mvo made me use it ;-)
[10:35]  * wgrant knows how to use it in general, but this is a very strange way to do things that I've not seen before.
[10:35] <seb128> I do how to get, pull, push basically
[10:35] <seb128> mvo: do you think you could do that upload? and maybe sneak the patch on bug #159996 too which is waiting for sponsoring? ;-)
[10:35] <ubottu> Launchpad bug 159996 in gnome-control-center "Appearance Preferences offer Visual Effects without installed Compiz" [Low,In progress] https://launchpad.net/bugs/159996
[10:41] <tjaalton> g-s-d uploaded
[10:41] <tjaalton> along with xinput and the drivers, so only g-c-c missing now :)
[10:43] <wgrant> Excellent. Thanks tjaalton.
[10:47] <elmargol> 2.6.27 was released 11 hours ago. This means we get a new kernel now?
[10:47] <elmargol> I think we are using a RC at the moment?
[10:51] <tjaalton> elmargol: uploaded already
[10:51] <tjaalton> rebased to 2.6.27
[10:52] <elmargol> ah cool maybe this fixes my problem
[10:52] <tjaalton> wgrant: hmm, you didn't bump the build-deps on g-s-d / g-c-c?
[10:53] <tjaalton> g-s-d failed to build on lpia
[10:53] <tjaalton> but we can retry it when the new versions have landed
[10:53] <tjaalton> fails on other archs too, of course
[10:55] <tjaalton> wgrant: seems that g-s-d does not directly build-depend on libxi-dev, so there was nothing to bump :)
[11:01] <wgrant> tjaalton: Sorry, forgot to tell you that.
[11:02] <tjaalton> wgrant: no problem, I added it and uploaded a new version
[11:02] <wgrant> Thanks.
[11:02] <tjaalton> g-c-c needs the same?
[11:05] <wgrant> tjaalton: It will probably be uploaded sufficiently late.
[11:05] <tjaalton> k
[11:10] <mvo> wgrant: sure, I can merge that branch
[11:12] <wgrant> libxi-dev is published on most archs, so it should be fine without the build-dep bump in a few minutes.
[11:13] <mvo> wgrant: where is your branch?
[11:14] <wgrant> mvo: It should be visible on your branch page as proposed for merging... but it's lp:~wgrant/gnome-control-center/bug-274728
[11:15] <mvo> wgrant: thanks, merging now
[11:15] <mvo> done
[11:17] <wgrant> mvo: Thanks.
[12:53] <wgrant> mvo: Did you end up uploading g-c-c?
[12:56] <wgrant> It's uninstallable now, and people have already started noticing.
[13:02] <seb128> users are annoying, they are using an unstable version they should wait when something is transitioning and not start making noise
[13:02] <mvo> wgrant: I have not uploaded it yet, I was collecting more changes
[13:02] <mvo> but if it is uninstallable (why?) I can do the upload now
[13:03] <tjaalton> libxi Breaks the current version
[13:03] <wgrant> seb128: True.
[13:03] <tjaalton> libxi6
[13:03] <mvo> seb128: I disagree with the patch for the appearance applet
[13:03] <mvo> seb128: I think it should set the option to insensitive but not hide them
[13:03] <wgrant> Hiding them sounds strange...
[13:04] <mvo> I will put that into the report
[13:04] <seb128> mvo: that's fair enough, I'm not such in such cases, when it's unsensitive users wonder why and how to enable it
[13:05] <seb128> it's done this way for menus to not change the layout dynamically which would be confusing
[13:05] <seb128> mvo: that might be worth pinging mpt just for having his opinion
[13:05] <mvo> seb128: agreed, I will do that
[13:05] <mvo> ideally we would have a "click here to install" box
[13:07] <seb128> mvo: right
[13:09] <mvo> seb128: the gnome-panel upload is now ready too, do you want to review the debdiff or can I just go ahead?
[13:10] <seb128> mvo: you know what you are doing just upload ;-)
[13:10] <mvo> (most of the time :P)
[13:11] <mvo> I just need to add this Vcs-Bzr header, then its ready
[13:27]  * seb128 hugs mvo
[13:29] <wgrant> mvo: Thanks.
[15:28] <tjaalton> jcristau: turns out it's not that simple to add fallback-drivers to non-autoconfig setup, since if there's a conffile present, autoConfigDevice returns only the one matched driver
[15:30] <tjaalton> at least it should be possible to hack listPossibleVideoDrivers not to run videoPtrToDriverList if matchDriverFromFiles succeeds
[15:30] <tjaalton> and if mDFF fails, use vesa
[15:30] <tjaalton> um, if they both fail
[15:30] <tjaalton> no
[15:30] <tjaalton> crap
[15:39] <tjaalton> bah, I give up for the day
[15:40] <tjaalton> ->
[17:04] <mvo> tseliot: your script is still not merged, sorry. I had to do a "emergency" update-maanger upload because there were a lot of people with hangs in u-m
[17:05] <tseliot> mvo: no problem
[17:05] <tseliot> it's not urgent
[17:26] <crevette> heya
[17:30] <crevette> does the xorg-server update include the performance fix ?
[17:31] <crevette> (the underline question, should I restart my session :))
[17:36] <tjaalton> crevette: no, it was dropped upstream
[18:10] <crevette> tjaalton: you mean it was commited or not approved
[18:15] <tjaalton> crevette: committed and reverted
[18:15] <tjaalton> ABI change
[18:15] <crevette> ah 
[18:16] <tjaalton> well, sort of
[18:16] <crevette> so it is not for 1.5 
[18:16] <tjaalton> no
[18:16] <crevette> too bad :/
[18:26] <tjaalton> bryce: btw, the serial-mouse bug.. I think it belongs to casper
[18:28] <bryce> tjaalton: oh?  why's that?
[18:29] <tjaalton> since the livecd is pretty hard to use without a mouse
[18:29] <tjaalton> although there would still be the problem of getting the same information to the installed system
[18:31] <bryce> iirc there was a question on using the approach mandriva or fedora uses for this situation (wiggling mouse or whatever); I take it that's something that could be done entirely within casper?
[18:34] <superm1> is serial mouse really something that is supported on machines in this day and age though?
[18:34] <pwnguin> mm
[18:35] <pwnguin> tabletPC is a serial wacom
[18:35] <tjaalton> superm1: apparently yes, in less-developed countries..
[18:35] <pwnguin> does that count?
[18:35] <superm1> tjaalton, ah i see
[18:35] <tjaalton> superm1: I asked the very same question, and got a response :)
[18:36] <tjaalton> bryce: they have a different way to install the system...
[18:36] <tjaalton> for us the primary way to install is via a live-session
[18:36] <bryce> tjaalton: ah too bad
[18:36] <bryce> well at least that answers that
[18:38] <tjaalton> evand/cjwatson know better how to tackle the issue..
[18:38] <johanbr> I did some further experimenting with the projector I was using (-ati driver). This time it refused to detect *anything*. If I switched to a console, the projector would sync and I could see the console text. When I switched back to X, the projector lost sync.
[22:09] <bryce> hmm, mandriva chose to ship with xorg 7.3 - http://wiki.mandriva.com/en/2009.0_Notes
[23:12] <tseliot> bryce: I don't know how accurate this page is but it says that Mandriva's xorg-server is still 1.4.2: http://distrowatch.com/table.php?distribution=mandriva
[23:13] <bryce> probably about right
[23:13] <bryce> tseliot: I'd been looking to see how they handled the -fglrx / xorg 1.5 issue, and see they've just punted on it
[23:15] <tseliot> bryce: yes, I was curious about their solution too
[23:16] <tseliot> but they couldn't revert the ABI changes (the screenprivateindex thing)
[23:16] <bryce> it sort of makes me wonder what life would be like if we'd also stuck with 1.4.x
[23:17] <tseliot> hmm... I wouldn't know
[23:18] <tseliot> hopefully AMD and NVIDIA will release a "fix" soon
[23:26] <wgrant> We can't let proprietary drivers delay us too much.