[00:55] <bryce> tjaalton: hmm still haven't seen the uploads come through; perhaps something is stuck
[01:02] <ubotu> New bug: #188549 in xserver-xorg-driver-nv "Hardy a4: graphics on XPS m1330" [Undecided,New] https://launchpad.net/bugs/188549
[02:05] <ubotu> New bug: #193544 in xserver-xorg-input-synaptics "Synaptics touchpad not detected on MacBook Santa Rosa" [Undecided,New] https://launchpad.net/bugs/193544
[03:26] <ubotu> New bug: #144914 in compiz (main) "putting glxgears below another window when running compiz looks funny (dup-of: 96991)" [Medium,Confirmed] https://launchpad.net/bugs/144914
[03:46] <ubotu> New bug: #148434 in compiz (main) "compiz opengl rendering artefacts (dragging, rotating) (dup-of: 96991)" [Undecided,New] https://launchpad.net/bugs/148434
[03:46] <bryce> (yes, I've gone on a dupe spree *grin*)
[03:50] <bryce> tjaalton: I've set bug 96991 as the master for all the compiz/3d redirected direct rendering issues.
[03:50] <ubotu> Launchpad bug 96991 in xorg-server "3D stuff breaks with Compiz:  Redirected Direct Rendering is needed in DRI" [Wishlist,Triaged] https://launchpad.net/bugs/96991
[03:55] <bryce> down to 1377 total bugs
[06:10] <tjaalton> bryce: maybe the archive was frozen already
[06:10] <bryce> morning tjaalton
[06:10] <bryce> no I think it's a soft "on your honor" freeze
[06:11] <tjaalton> hmm
[06:13] <tjaalton> slangasek send an email saying that main is frozen, but it shouldn't have been at the time
[06:13] <bryce> tjaalton: should we ask slangasek or someone for help?
[06:13] <tjaalton> bryce: I think so
[06:13] <tjaalton> maybe also with syncing -ati?
[06:15] <bryce> yeah
[06:20] <bryce> there's a platform meeting on #ubuntu-meeting he'll be at in about half an hour; might be good to bump his elbow about these things at the start of that
[06:21] <tjaalton> oh ok, I'll be there
[06:35] <tjaalton> bryce: what should we do with input-hotplug? all this time there has been the possibility to generate an fdi file for it either from xorg.conf or /etc/default/console-setup, but the problem was (and still is) that which package should own the script
[06:36] <bryce> tjaalton: hmm good question.  xorg would be my first guess
[06:36] <bryce> but maybe that's more just because I'm less familiar with console-setup
[06:36] <tjaalton> hal upstream has not answered to my questions about the hal-script approach which would make the fdi-file unnecessary
[06:37] <tjaalton> yeah I think xserver-xorg would be the place
[06:37] <bryce> did you talk with cjwatson about it last week?
[06:38] <tjaalton> yes, and as a result I sent the email to hal-list..
[06:38] <bryce> ok, maybe it would be a good thing to bring up at the meeting tonight
[06:38] <tjaalton> yep
[06:38] <bryce> I need to get direction as well about the xrandr gui.
[06:39] <bryce> I think merging with redhat is the right way to go, but I'm concerned we don't have enough time left
[06:40] <bryce> however with all the bug stuff I did today I feel a *lot* more comfortable about or stability
[06:40] <tjaalton> well, since it's just a gui, it should be able to touch it late in the release process
[06:40] <bryce> getting 965 working was a very important goal, so I'm really glad that all has worked out
[06:41] <tjaalton> I'm concerned about i-h, since there are a number of bugs where I said that "this will be fixed in hardy blahblah" :)
[06:42] <bryce> what's i-h?
[06:42] <bryce> oh input-hotplug?
[06:42] <tjaalton> yeah ;)
[06:42] <tjaalton> or i12 from now on :)
[06:42] <tjaalton> maybe not
[06:42] <bryce> yeah, I've got a long list of input issues I've promised people I'd look at, but haven't yet
[07:24] <tjaalton> bryce: I have to go to the swimming hall, but will get back in ~2h
[07:25] <bryce> ok cool
[08:07] <bryce> <cjwatson> bryce: looks like Timo didn't re-sign xorg-server
[08:07] <bryce> <cjwatson> 07:15:35 WARNING Upload was rejected:
[08:07] <bryce>  07:15:35 WARNING        Signer is not permitted to upload to the component 'main' of file 'xorg-server_1.4.1~git20080131-1ubuntu4.dsc'
[08:21] <bryce> tjaalton: so I think if you re-debsign my package and upload it, it should go through
[08:21] <bryce> oh, and you may be happy to hear I finally sent in my core-dev app tonight.
[08:25] <bryce> seb128: cjwatson and I discussed about xrandr gui plans at the meeting today
[08:26] <bryce> seb128: after giving it thought, the right approach seems to be to drop what I've been working on and instead focus on integrating and finishing the RedHat tool
[08:26] <seb128> ah, why?
[08:27] <bryce> seb128: cjwatson suggested that I ask if you would be able to assist me with this integration
[08:27] <seb128> sure
[08:28] <bryce> seb128: well, firstly because it seems there is little chance of getting our tool upstream.
[08:28] <bryce> seb128: but also because the underlying structure that redhat has put in place is better designed than what I've rushed together
[08:31] <seb128> ok
[08:31] <bryce> I'm writing a reply to get some additional information; I'll cc you.
[08:34] <seb128> ok
[08:39] <bryce> sent
[08:41] <bryce> seb128: from what it looks like, it will require some integration work to gnome-desktop, gnome-settings-daemon, and gnome-control-center
[08:41] <bryce> seb128: I want to find out if they are using a VCS (currently I just wget -r the files, which is a pain)
[08:42] <bryce> http://www.gnome.org/~ssp/randr/
[08:42] <seb128> bryce: better to reply on the list to ask that, I don't know what they are using
[08:42] <bryce> maybe we take a snapshot and put into bzr to work on...?
[08:42] <seb128> sounds good
[08:43] <bryce> yeah, that was my first question in my email
[08:44] <bryce> seb128: have you worked with Soeren Sandmann before?
[08:46] <seb128> no
[08:47] <mvo> hey bryce! thanks for your mail about i965 and compiz
[08:48] <mvo> we removed the blacklist for it a while ago (when exa was enabled), but I'm happy that I don't have to reenable it again :)
[08:48] <bryce> mvo, :-)
[08:48]  * mvo upgrades his i965 system to test
[08:49] <bryce> mvo, the packages haven't been uploaded quite yet, but should be as soon as tjaalton returns
[08:49] <bryce> but I stuck debs up for testing at http://people.ubuntu.com/~bryce/Testing/Greedy/
[08:52] <bryce> anyway, got an early meeting tomorrow morning.  g'night
[08:54] <mvo> good night
[08:55] <mvo> bryce: works nicely here bte
[08:55] <mvo> btw
[08:55] <mvo> great work!
[10:23] <tjaalton> hmm, I thought that a simple dput -u would've worked, but guess not
[10:31] <tjaalton> yeah, now they got accepted
[12:50] <soren> How do you figure out which driver to use for input?
[13:01] <tjaalton> soren: hmm what do you mean=
[13:01] <tjaalton> ?
[13:02] <soren> Not sure how I can explain it better. I've found the answer, thouhg :)
[13:02] <soren> though..
[13:03] <tjaalton> heh, ok
[13:04] <tjaalton> evdev is the one that input-hotplug uses by default, for instance
[13:05] <soren> input-hotplug?
[13:05] <soren> Ok, it seems that my problem is that mdetect is not installed by default anymore. I'm assuming that's intentional somehow?
[13:06] <soren> ..
[13:06] <soren> No, it seems that won't help me either.
[13:07] <tjaalton> hotplugging input devices, a new feature in xserver 1.4 but not yet used by default
[13:08] <tjaalton> soren: what problems are you having?
[13:08] <soren> I want to use vmmouse when running inside kvm.
[13:08] <soren> That solves pretty much everything.
[13:09] <soren> ...w.r.t. to X pointers, at least.
[13:09] <soren> :)
[13:09] <tjaalton> it's used by default on vmware guests
[13:10] <tjaalton> at least should be
[13:11] <soren> Right, but that depends on a) mdetect being installed when dexconf runs and b) actually running inside vmware (doesn't work with kvm).
[13:11] <tjaalton> right
[13:12] <tjaalton> xserver-xorg recommends mdetect
[13:12] <soren> Well, on the live cd, it's not installed when I log in.
[13:12] <tjaalton> ok, so it's not strong enough
[13:13] <soren> Do you happen to know how fedora does it? They get it right, you see.
[13:13] <tjaalton> nope, no idea
[13:13] <soren> I looked at system-config-display, but ti doesn't say vmmouse anywhere in the source, afaics.
[13:14] <tjaalton> maybe dexconf could use the same QEMU_KVM hack as for the device driver
[13:15] <tjaalton> to detect that it's running under kvm
[13:16] <soren> Well.. We could, but I think it's a horrible, horrible hack.
[13:18] <tjaalton> indeed :)
[13:24] <soren> tjaalton: Oh!
[13:24] <soren> tjaalton: You're the one who did the vmmouse detection stuff in dexconf.
[13:25] <tjaalton> was I
[13:25] <tjaalton> hmm
[13:25] <soren> Oh, you just merged it.
[13:25] <soren> Sorry, it was bryce.
[13:26] <tjaalton> yep, I think it didn't work before, and still doesn't if mdetect isn't installed
[13:26] <soren> bryce: Why bother with the vmmouse_detect thing in dexconf instead of just detecting if the device is there?
[13:30] <tjaalton> and do it in the server?
[13:31] <mvo_> tjaalton: will we get xf86-video-ati 6.8.0 (will that work with our xserver)?
[13:31] <tjaalton> mvo_: after alpha5, and yes it works
[13:31] <mvo_> rock!
[13:31] <soren> tjaalton: Well, dexconf is still fine, but I'm guessing the device itself must be identifiable (rather than looking at the environment)
[13:31] <mvo_> any pre-deps available already? I have a r500 and can't wait to switch to radeon again
[13:32] <tjaalton> mvo_: no, just get the source from debian and build it
[13:32] <tjaalton> mvo_: no 3D though
[13:32] <tjaalton> not yet anyway ;)
[13:32] <tjaalton> soren: did you look at vmmouse_detect how it does the detection?
[13:34] <tjaalton> soren: if it really is something generic that the server should support (and not just vmware specific), then I think it would be possible to get it in the server itself
[13:35] <tjaalton> although, in the input-hotplug world I think it should be hal that needs to know that the system is a virtual guest
[14:01] <ubotu> New bug: #193667 in xserver-xorg-video-intel (main) "bad performaces on intel x3100" [Undecided,New] https://launchpad.net/bugs/193667
[15:09] <ubotu> New bug: #193690 in xorg (main) "Xorg + PCI card = INVALID IO ALLOCATION" [Undecided,New] https://launchpad.net/bugs/193690
[15:11] <ubotu> New bug: #192136 in xulrunner-1.9 (main) "Background image when scrolling" [Undecided,Incomplete] https://launchpad.net/bugs/192136
[15:16] <soren> tjaalton: WEll, it turns out that if the vmmouse driver doesn't detect the vmware stuff, it just passes control on to the regular mouse driver. For this very reason, Fedora has actually defaulted to vmmouse for the last couple of releases.
[15:33] <soren> tjaalton: Do you reckon we could do the same?
[15:47] <ubotu> New bug: #193575 in xserver-xorg-input-synaptics "Synaptics touchpad periodically disconnects" [Undecided,New] https://launchpad.net/bugs/193575
[15:55] <soren> bryce: Where did you find the vmmouse_detect code?
[15:57] <bryce> soren, mdz passed it along to me from one of the vmware guys iirc
[16:01] <soren> bryce: Ah.
[16:01] <soren> bryce: You wouldn't happen to have a name and an e-mail for that guy?
[16:56] <bryce> soren: yeah hang on (sorry was in a conf call with amd)
[16:56] <soren> Cool.
[16:56] <soren> While we're sort of on the subject..
[16:57] <soren> 16:16:26 < soren> tjaalton: WEll, it turns out that if the vmmouse driver doesn't detect the vmware stuff, it just passes control on to the regular mouse driver. For this very reason, Fedora has  actually defaulted to vmmouse for the last couple of releases.
[16:57] <soren> 16:33:37 < soren> tjaalton: Do you reckon we could do the same?
[16:57] <bryce> Philip Langdale
[16:57] <bryce> From: Philip Langdale <ubuntu.philipl@overt.org>
[16:58] <bryce> he's a vmware guy according to mdz, despite the email's url
[16:58] <bryce> wow, odd
[16:59] <tjaalton> soren: sounds nice
[17:02] <tjaalton> duh, now we get bugs about intel chips being too slow
[17:03] <bryce> hehe
[17:07] <bryce> tjaalton: I decided to wait on bringing up the input-hotplug issues since I thought it would be more productive if you were there; last time I talked with cjwatson about it he recommended to stick with the current configuration approach for this release
[17:08] <bryce> tjaalton: but perhaps you and I can talk with colin on the side to work out a better plan
[17:08] <tjaalton> bryce: yeah sure
[17:12] <bryce> soren: so regarding the vmmouse configuration, if the current approach isn't working then I'm definitely open to better ideas
[17:13] <bryce> soren: it would be nice to have the input-hotplug stuff squared away before undertaking any things that would take a large effort; defaulting to vmware sounds like it would be simple (assuming it didn't cause other issues); adding support in the xserver to detect it would be more effort but probably the better solution
[17:14] <tjaalton> but there's no need to touch the server, if the driver has all the nuts and bolts in it
[17:14] <bryce> right...  "xserver and/or the driver"
[17:15] <tjaalton> apparently it just loads another driver (in this case, mouse) if the host system is not a virtual guest
[17:15] <tjaalton> and if we end up using input-hotplug fo hardy, evdev
[17:15] <tjaalton> although maybe there's a better way to do it with i-h
[17:16] <tjaalton> hmm I'll try it on my laptop
[17:16] <bryce> I wonder if debian has looked at this already?
[17:16] <tjaalton> doesn't look like it
[17:17] <bryce> ok, well sounds like defaulting to vmmouse is a decent solution.   It'd be interesting to hear debian's opinion
[17:17] <tjaalton> of course
[17:19] <bryce> Intrepid Ibex.  mm
[17:26] <ubotu> New bug: #193726 in xorg-server (main) "package xserver-xorg-core 2:1.4.1~git20080131-1ubuntu2 failed to install/upgrade: falha em buffer_write(fd) (10, ret=-1)rsa" [Undecided,Invalid] https://launchpad.net/bugs/193726
[17:29] <tjaalton> yep, wonder what the nickname will be.. intrepid is too long so maybe just ibex
[17:29] <tjaalton> vmmouse works fine on my laptop
[17:30] <tjaalton> hmm actually it doesn't even use it
[17:31] <tjaalton> "the core pointer device wasn't specified in explicitly in the layout. using the default mouse configuration". right.
=== mvo__ is now known as mvo
[17:51] <tjaalton> soren: so, the current code in dexconf has no meaning since it doesn't write a ServerLayout section anymore
[17:52] <tjaalton> the server should default to vmmouse if we want to use it
[18:03] <jcristau> i think if it finds a device with Option CorePointer, it uses that as the mouse device
[18:25] <tjaalton> jcristau: yep, probably so
[18:26] <tjaalton> changing evdev -> vmmouse from the example fdi-file worked, but now all mouse clicks are doubled
[18:26] <tjaalton> so i-h doesn't like "mouse"
[18:27] <tjaalton> but I guess that was common knowledge
[18:50] <jcristau> tjaalton: pretty much, because then you get the events both from /dev/input/mouseN and /dev/input/mice
[18:50] <jcristau> or something like that
[18:50] <jcristau> which sucks
[19:41] <tjaalton> yep, even the movement is doubled :)
[19:43] <bryce> fun
[19:43] <tjaalton> and for some reason, i-h on my laptop is party broken, "up" generates "printscr"
[19:44] <tjaalton> my desktop works fine, same config
[19:44]  * bryce delves back into xrandr gui work
[19:44] <jcristau> tjaalton: that's a xkbmodel mismatch between evdev and something else afaik
[19:45] <tjaalton> jcristau: normally I would agree, but the gnome kb-layout capplet seems to show correct values (=evdev layout)
[19:46] <jcristau> what about setxkbmap -print?
[19:46] <tjaalton> or is it perhaps something else then.. need to investigate later
[19:46]  * jcristau doesn't trust gnome
[19:46] <tjaalton> hehe
[19:46] <tjaalton> Heroes first :)
[20:21] <tjaalton> jcristau: ok, here's the diff:
[20:21] <tjaalton> --- setxkbmap-normal	2008-02-20 22:15:02.000000000 +0200
[20:21] <tjaalton> +++ setxkbmap-ih	2008-02-20 22:17:47.000000000 +0200
[20:21] <tjaalton> @@ -1,7 +1,7 @@
[20:21] <tjaalton>  xkb_keymap {
[20:21] <tjaalton> -	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
[20:21] <tjaalton> +	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
[20:22] <tjaalton>  	xkb_types     { include "complete"	};
[20:22] <tjaalton>  	xkb_compat    { include "complete"	};
[20:22] <tjaalton> -	xkb_symbols   { include "pc+fi(kotoistus)+level3(ralt_switch)"	};
[20:22] <tjaalton> -	xkb_geometry  { include "pc(pc105)"	};
[20:22] <tjaalton> +	xkb_symbols   { include "pc+fi(kotoistus)+inet(evdev)+level3(ralt_switch)"	};
[20:22] <tjaalton> +	xkb_geometry  { include "pc(pc104)"	};
[20:23] <tjaalton> geometry is different
[20:54] <ubotu> New bug: #193793 in mesa (main) "[hardy] X crashes on r300 during f-spot slideshow" [Undecided,New] https://launchpad.net/bugs/193793
[21:11] <ubotu> New bug: #193800 in xdm (universe) "outdated Depends dependency relationships" [Undecided,New] https://launchpad.net/bugs/193800
[21:53] <bryce> seb128: I've roughed out a todo list for the xrandr gui work - https://wiki.ubuntu.com/X/DisplayConfig
[21:54] <bryce> seb128: when you get a chance please take a look and give me your feedback
[21:56] <seb128> bryce: ok
[22:07] <seb128> bryce: looks good to me
[22:08] <seb128> bryce: I can look at the gtk and gnome* fedora patches tomorrow and give you my opinion on them if that works for you
[22:08] <bryce> ok
[22:08] <seb128> bryce: is that something we still want for hardy?
[22:08] <bryce> yes
[22:09] <seb128> ok, will look at that tomorrow then
[22:09] <bryce> the gtk patch adds certain new xrandr 1.2 functionality the other code requires
[22:09] <seb128> it's getting late now and I don't feel like starting on that now ;-)
[22:09] <bryce> seb128: sure, but first a couple questions...
[22:09] <seb128> sure
[22:09] <seb128> questions are fine
[22:09] <seb128> I just don't want to start reading code changes ;-)
[22:09] <bryce> seb128: should I go ahead and set up a bzr repo for us and stick this in it for us to work on?
[22:10] <seb128> do you think the level of change is important enough to justify a bzr?
[22:10] <bryce> seb128: oh, hmm that's my only question :-)
[22:11] <bryce> well, it seems they don't respond swiftly so if we have patches it may take some time to get them accepted, so it may be easier to manage them in a vcs
[22:11] <bryce> seb128: I assume we'll need to do some work on the code in order to make it fit and look proper
[22:14] <bryce> well, we could wait and decide tomorrow if you'd prefer?
[22:17] <seb128> sorry was busy with other things
[22:18] <seb128> well
[22:18] <seb128> if we do take the redhat patches and only small bug fixing there, which I expect will be the case for gtk, gnome-desktop, gnome-settings-daemon I'm not convinced bzr will be useful
[22:19] <seb128> if we need to write code, which will likely be the case for gnome-control-center I think that's useful
[22:19] <bryce> ok, yes that's what I suspect to be the case
[22:19] <bryce> gnome-desktop may also require some additional coding; most of the xrandr logic is implemented there
[22:20] <bryce> however I've not looked at it deeply enough yet
[22:20] <bryce> but for now, I could create a branch for gnome-control-center?
[22:21] <seb128> sure
[22:21] <bryce> ok cool
[22:21] <seb128> do you want this one to be used for packaging and everything?
[22:22] <seb128> or only to hack on that and we can merge with the packaging branch on updates, etc?
[22:22] <bryce> I was thinking just for hacking on, to assist in producing patches 
[22:22] <bryce> right, the latter
[22:24] <seb128> sounds good to me
[22:24] <seb128> in which case feel free to set bzr for other things if you need too
[22:24] <bryce> ok great
[22:24] <seb128> that should not impact on normal desktop updates
[22:24] <seb128> we can merge changes from the hack bzr to the package one when we want
[22:25] <bryce> yup
[22:25] <seb128> and keep on doing normal updates in the meantime
[22:25] <seb128> cool
[22:25] <seb128> thanks
[22:25] <bryce> great, thanks
[23:44] <jcristau> tjaalton: i think the difference in xkb_symbols is what matters here