brycetjaalton: hmm still haven't seen the uploads come through; perhaps something is stuck00:55
ubotuNew bug: #188549 in xserver-xorg-driver-nv "Hardy a4: graphics on XPS m1330" [Undecided,New] https://launchpad.net/bugs/18854901:02
ubotuNew bug: #193544 in xserver-xorg-input-synaptics "Synaptics touchpad not detected on MacBook Santa Rosa" [Undecided,New] https://launchpad.net/bugs/19354402:05
ubotuNew bug: #144914 in compiz (main) "putting glxgears below another window when running compiz looks funny (dup-of: 96991)" [Medium,Confirmed] https://launchpad.net/bugs/14491403:26
ubotuNew bug: #148434 in compiz (main) "compiz opengl rendering artefacts (dragging, rotating) (dup-of: 96991)" [Undecided,New] https://launchpad.net/bugs/14843403:46
bryce(yes, I've gone on a dupe spree *grin*)03:46
brycetjaalton: I've set bug 96991 as the master for all the compiz/3d redirected direct rendering issues.03:50
ubotuLaunchpad bug 96991 in xorg-server "3D stuff breaks with Compiz:  Redirected Direct Rendering is needed in DRI" [Wishlist,Triaged] https://launchpad.net/bugs/9699103:50
brycedown to 1377 total bugs03:55
tjaaltonbryce: maybe the archive was frozen already06:10
brycemorning tjaalton06:10
bryceno I think it's a soft "on your honor" freeze06:10
tjaaltonslangasek send an email saying that main is frozen, but it shouldn't have been at the time06:13
brycetjaalton: should we ask slangasek or someone for help?06:13
tjaaltonbryce: I think so06:13
tjaaltonmaybe also with syncing -ati?06:13
brycethere'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 that06:20
tjaaltonoh ok, I'll be there06:21
tjaaltonbryce: 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 script06:35
brycetjaalton: hmm good question.  xorg would be my first guess06:36
brycebut maybe that's more just because I'm less familiar with console-setup06:36
tjaaltonhal upstream has not answered to my questions about the hal-script approach which would make the fdi-file unnecessary06:36
tjaaltonyeah I think xserver-xorg would be the place06:37
brycedid you talk with cjwatson about it last week?06:37
tjaaltonyes, and as a result I sent the email to hal-list..06:38
bryceok, maybe it would be a good thing to bring up at the meeting tonight06:38
bryceI need to get direction as well about the xrandr gui.06:38
bryceI think merging with redhat is the right way to go, but I'm concerned we don't have enough time left06:39
brycehowever with all the bug stuff I did today I feel a *lot* more comfortable about or stability06:40
tjaaltonwell, since it's just a gui, it should be able to touch it late in the release process06:40
brycegetting 965 working was a very important goal, so I'm really glad that all has worked out06:40
tjaaltonI'm concerned about i-h, since there are a number of bugs where I said that "this will be fixed in hardy blahblah" :)06:41
brycewhat's i-h?06:42
bryceoh input-hotplug?06:42
tjaaltonyeah ;)06:42
tjaaltonor i12 from now on :)06:42
tjaaltonmaybe not06:42
bryceyeah, I've got a long list of input issues I've promised people I'd look at, but haven't yet06:42
tjaaltonbryce: I have to go to the swimming hall, but will get back in ~2h07:24
bryceok cool07:25
bryce<cjwatson> bryce: looks like Timo didn't re-sign xorg-server08: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:07
brycetjaalton: so I think if you re-debsign my package and upload it, it should go through08:21
bryceoh, and you may be happy to hear I finally sent in my core-dev app tonight.08:21
bryceseb128: cjwatson and I discussed about xrandr gui plans at the meeting today08:25
bryceseb128: 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 tool08:26
seb128ah, why?08:26
bryceseb128: cjwatson suggested that I ask if you would be able to assist me with this integration08:27
bryceseb128: well, firstly because it seems there is little chance of getting our tool upstream.08:28
bryceseb128: but also because the underlying structure that redhat has put in place is better designed than what I've rushed together08:28
bryceI'm writing a reply to get some additional information; I'll cc you.08:31
bryceseb128: from what it looks like, it will require some integration work to gnome-desktop, gnome-settings-daemon, and gnome-control-center08:41
bryceseb128: I want to find out if they are using a VCS (currently I just wget -r the files, which is a pain)08:41
seb128bryce: better to reply on the list to ask that, I don't know what they are using08:42
brycemaybe we take a snapshot and put into bzr to work on...?08:42
seb128sounds good08:42
bryceyeah, that was my first question in my email08:43
bryceseb128: have you worked with Soeren Sandmann before?08:44
mvohey bryce! thanks for your mail about i965 and compiz08:47
mvowe 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
brycemvo, :-)08:48
* mvo upgrades his i965 system to test08:48
brycemvo, the packages haven't been uploaded quite yet, but should be as soon as tjaalton returns08:49
brycebut I stuck debs up for testing at http://people.ubuntu.com/~bryce/Testing/Greedy/08:49
bryceanyway, got an early meeting tomorrow morning.  g'night08:52
mvogood night08:54
mvobryce: works nicely here bte08:55
mvogreat work!08:55
tjaaltonhmm, I thought that a simple dput -u would've worked, but guess not10:23
tjaaltonyeah, now they got accepted10:31
sorenHow do you figure out which driver to use for input?12:50
tjaaltonsoren: hmm what do you mean=13:01
sorenNot sure how I can explain it better. I've found the answer, thouhg :)13:02
tjaaltonheh, ok13:03
tjaaltonevdev is the one that input-hotplug uses by default, for instance13:04
sorenOk, it seems that my problem is that mdetect is not installed by default anymore. I'm assuming that's intentional somehow?13:05
sorenNo, it seems that won't help me either.13:06
tjaaltonhotplugging input devices, a new feature in xserver 1.4 but not yet used by default13:07
tjaaltonsoren: what problems are you having?13:08
sorenI want to use vmmouse when running inside kvm.13:08
sorenThat solves pretty much everything.13:08
soren...w.r.t. to X pointers, at least.13:09
tjaaltonit's used by default on vmware guests13:09
tjaaltonat least should be13:10
sorenRight, but that depends on a) mdetect being installed when dexconf runs and b) actually running inside vmware (doesn't work with kvm).13:11
tjaaltonxserver-xorg recommends mdetect13:12
sorenWell, on the live cd, it's not installed when I log in.13:12
tjaaltonok, so it's not strong enough13:12
sorenDo you happen to know how fedora does it? They get it right, you see.13:13
tjaaltonnope, no idea13:13
sorenI looked at system-config-display, but ti doesn't say vmmouse anywhere in the source, afaics.13:13
tjaaltonmaybe dexconf could use the same QEMU_KVM hack as for the device driver13:14
tjaaltonto detect that it's running under kvm13:15
sorenWell.. We could, but I think it's a horrible, horrible hack.13:16
tjaaltonindeed :)13:18
sorentjaalton: Oh!13:24
sorentjaalton: You're the one who did the vmmouse detection stuff in dexconf.13:24
tjaaltonwas I13:25
sorenOh, you just merged it.13:25
sorenSorry, it was bryce.13:25
tjaaltonyep, I think it didn't work before, and still doesn't if mdetect isn't installed13:26
sorenbryce: Why bother with the vmmouse_detect thing in dexconf instead of just detecting if the device is there?13:26
tjaaltonand do it in the server?13:30
mvo_tjaalton: will we get xf86-video-ati 6.8.0 (will that work with our xserver)?13:31
tjaaltonmvo_: after alpha5, and yes it works13:31
sorentjaalton: 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 again13:31
tjaaltonmvo_: no, just get the source from debian and build it13:32
tjaaltonmvo_: no 3D though13:32
tjaaltonnot yet anyway ;)13:32
tjaaltonsoren: did you look at vmmouse_detect how it does the detection?13:32
tjaaltonsoren: 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 itself13:34
tjaaltonalthough, in the input-hotplug world I think it should be hal that needs to know that the system is a virtual guest13:35
ubotuNew bug: #193667 in xserver-xorg-video-intel (main) "bad performaces on intel x3100" [Undecided,New] https://launchpad.net/bugs/19366714:01
ubotuNew bug: #193690 in xorg (main) "Xorg + PCI card = INVALID IO ALLOCATION" [Undecided,New] https://launchpad.net/bugs/19369015:09
ubotuNew bug: #192136 in xulrunner-1.9 (main) "Background image when scrolling" [Undecided,Incomplete] https://launchpad.net/bugs/19213615:11
sorentjaalton: 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:16
sorentjaalton: Do you reckon we could do the same?15:33
ubotuNew bug: #193575 in xserver-xorg-input-synaptics "Synaptics touchpad periodically disconnects" [Undecided,New] https://launchpad.net/bugs/19357515:47
sorenbryce: Where did you find the vmmouse_detect code?15:55
brycesoren, mdz passed it along to me from one of the vmware guys iirc15:57
sorenbryce: Ah.16:01
sorenbryce: You wouldn't happen to have a name and an e-mail for that guy?16:01
brycesoren: yeah hang on (sorry was in a conf call with amd)16:56
sorenWhile we're sort of on the subject..16:56
soren16: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
soren16:33:37 < soren> tjaalton: Do you reckon we could do the same?16:57
brycePhilip Langdale16:57
bryceFrom: Philip Langdale <ubuntu.philipl@overt.org>16:57
brycehe's a vmware guy according to mdz, despite the email's url16:58
brycewow, odd16:58
tjaaltonsoren: sounds nice16:59
tjaaltonduh, now we get bugs about intel chips being too slow17:02
brycetjaalton: 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 release17:07
brycetjaalton: but perhaps you and I can talk with colin on the side to work out a better plan17:08
tjaaltonbryce: yeah sure17:08
brycesoren: so regarding the vmmouse configuration, if the current approach isn't working then I'm definitely open to better ideas17:12
brycesoren: 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 solution17:13
tjaaltonbut there's no need to touch the server, if the driver has all the nuts and bolts in it17:14
bryceright...  "xserver and/or the driver"17:14
tjaaltonapparently it just loads another driver (in this case, mouse) if the host system is not a virtual guest17:15
tjaaltonand if we end up using input-hotplug fo hardy, evdev17:15
tjaaltonalthough maybe there's a better way to do it with i-h17:15
tjaaltonhmm I'll try it on my laptop17:16
bryceI wonder if debian has looked at this already?17:16
tjaaltondoesn't look like it17:16
bryceok, well sounds like defaulting to vmmouse is a decent solution.   It'd be interesting to hear debian's opinion17:17
tjaaltonof course17:17
bryceIntrepid Ibex.  mm17:19
ubotuNew 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/19372617:26
tjaaltonyep, wonder what the nickname will be.. intrepid is too long so maybe just ibex17:29
tjaaltonvmmouse works fine on my laptop17:29
tjaaltonhmm actually it doesn't even use it17:30
tjaalton"the core pointer device wasn't specified in explicitly in the layout. using the default mouse configuration". right.17:31
=== mvo__ is now known as mvo
tjaaltonsoren: so, the current code in dexconf has no meaning since it doesn't write a ServerLayout section anymore17:51
tjaaltonthe server should default to vmmouse if we want to use it17:52
jcristaui think if it finds a device with Option CorePointer, it uses that as the mouse device18:03
tjaaltonjcristau: yep, probably so18:25
tjaaltonchanging evdev -> vmmouse from the example fdi-file worked, but now all mouse clicks are doubled18:26
tjaaltonso i-h doesn't like "mouse"18:26
tjaaltonbut I guess that was common knowledge18:27
jcristautjaalton: pretty much, because then you get the events both from /dev/input/mouseN and /dev/input/mice18:50
jcristauor something like that18:50
jcristauwhich sucks18:50
tjaaltonyep, even the movement is doubled :)19:41
tjaaltonand for some reason, i-h on my laptop is party broken, "up" generates "printscr"19:43
tjaaltonmy desktop works fine, same config19:44
* bryce delves back into xrandr gui work19:44
jcristautjaalton: that's a xkbmodel mismatch between evdev and something else afaik19:44
tjaaltonjcristau: normally I would agree, but the gnome kb-layout capplet seems to show correct values (=evdev layout)19:45
jcristauwhat about setxkbmap -print?19:46
tjaaltonor is it perhaps something else then.. need to investigate later19:46
* jcristau doesn't trust gnome19:46
tjaaltonHeroes first :)19:46
tjaaltonjcristau: ok, here's the diff:20:21
tjaalton--- setxkbmap-normal2008-02-20 22:15:02.000000000 +020020:21
tjaalton+++ setxkbmap-ih2008-02-20 22:17:47.000000000 +020020: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:21
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:22
tjaaltongeometry is different20:23
ubotuNew bug: #193793 in mesa (main) "[hardy] X crashes on r300 during f-spot slideshow" [Undecided,New] https://launchpad.net/bugs/19379320:54
ubotuNew bug: #193800 in xdm (universe) "outdated Depends dependency relationships" [Undecided,New] https://launchpad.net/bugs/19380021:11
bryceseb128: I've roughed out a todo list for the xrandr gui work - https://wiki.ubuntu.com/X/DisplayConfig21:53
bryceseb128: when you get a chance please take a look and give me your feedback21:54
seb128bryce: ok21:56
seb128bryce: looks good to me22:07
seb128bryce: I can look at the gtk and gnome* fedora patches tomorrow and give you my opinion on them if that works for you22:08
seb128bryce: is that something we still want for hardy?22:08
seb128ok, will look at that tomorrow then22:09
brycethe gtk patch adds certain new xrandr 1.2 functionality the other code requires22:09
seb128it's getting late now and I don't feel like starting on that now ;-)22:09
bryceseb128: sure, but first a couple questions...22:09
seb128questions are fine22:09
seb128I just don't want to start reading code changes ;-)22:09
bryceseb128: should I go ahead and set up a bzr repo for us and stick this in it for us to work on?22:09
seb128do you think the level of change is important enough to justify a bzr?22:10
bryceseb128: oh, hmm that's my only question :-)22:10
brycewell, 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 vcs22:11
bryceseb128: I assume we'll need to do some work on the code in order to make it fit and look proper22:11
brycewell, we could wait and decide tomorrow if you'd prefer?22:14
seb128sorry was busy with other things22:17
seb128if 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 useful22:18
seb128if we need to write code, which will likely be the case for gnome-control-center I think that's useful22:19
bryceok, yes that's what I suspect to be the case22:19
brycegnome-desktop may also require some additional coding; most of the xrandr logic is implemented there22:19
brycehowever I've not looked at it deeply enough yet22:20
brycebut for now, I could create a branch for gnome-control-center?22:20
bryceok cool22:21
seb128do you want this one to be used for packaging and everything?22:21
seb128or only to hack on that and we can merge with the packaging branch on updates, etc?22:22
bryceI was thinking just for hacking on, to assist in producing patches 22:22
bryceright, the latter22:22
seb128sounds good to me22:24
seb128in which case feel free to set bzr for other things if you need too22:24
bryceok great22:24
seb128that should not impact on normal desktop updates22:24
seb128we can merge changes from the hack bzr to the package one when we want22:24
seb128and keep on doing normal updates in the meantime22:25
brycegreat, thanks22:25
jcristautjaalton: i think the difference in xkb_symbols is what matters here23:44

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!