[08:42] <tjaalton> bryce: so, about the input.rules.. xorg == base, which means we can drop that part from the script too
[08:43] <tjaalton> since it's already set in 10-keymap.fdi
[08:43] <tjaalton> er, input.xkb.rules that is
[14:38] <tjaalton> bryce: I'm preparing xorg for input-hotplug. Should I nuke failsafe while at it?-)
[15:00] <tjaalton> hmm, I think vmmouse needs to ship it's own fdi file too.. but the question is how to detect it from hal
[15:04] <tjaalton> umm of course not.. it's either evdev or vmmouse that should be used, not both
[15:04] <tjaalton> so the "master" fdi file should be able to distinguish which one to use
[17:24] <james_w> seb128: hey. I see the new g-c-c adds an option to make the status icon configurable. I can't work out from the diff what the default is, do you know?
[17:25] <seb128> james_w: didn't look at this upgrade yet, are you working on it?
[17:25] <james_w> seb128: no, I wasn't
[17:26] <james_w> I can if you like, I have other things to do, and I'm on vacation at the end of the week, so if you can that would be great
[17:26] <seb128> ok, I'll tell you when I look at the update, but upstream closed the bug so I expect it's fixed
[17:26] <james_w> yeah, I was just worried that it defaulted to "on"
[17:26] <seb128> well I planned to do it, was just wondering if you asked because you were working on it
[17:26] <seb128> I don't want to duplicate work there ;-)
[17:27] <seb128> I'll tell you when I give it a try
[17:27] <james_w> ah no, I just saw the release announcement and it reminded me, I forgot to look when the report was closed
[17:27] <seb128> usually I just do the upgrade and look at bugs after running the new version
[17:27] <seb128> that makes easier to know what is fixed or not ;-)
[17:28] <james_w> that's sensible :-)
[17:54] <seb128> james_w: yes, the bug is fixed by default
[17:54] <james_w> seb128: cool, thanks for checking
[19:14] <james_w> hey all, an xserver update came down without the fix I needed so it broke again, can I get a fix cherry-picked from upstream to make sure this doesn't happen again?
[19:15] <james_w> I guess I should have put my local package on hold to protect against this
[19:18] <tjaalton> james_w: which fix?
[19:18] <james_w> I'm just pulling up the bug number, sorry
[19:18] <james_w> I'm on a different system so I don't have it to hand
[19:18] <bryce> tjaalton: shall we flip input-hotplug on?
[19:18] <james_w> hey bryce 
[19:18] <tjaalton> bryce: of course :)
[19:18] <bryce> james_w: heya
[19:19] <tjaalton> bryce: but it's going to happen in hal
[19:19] <tjaalton> so probably next morning when pitti is around again
[19:19] <tjaalton> CET
[19:19] <bryce> james_w: if you can work up a debdiff (and if it doesn't look like it'll cause regressions elsewhere), we can sponsor it
[19:19] <bryce> tjaalton: what do we need to do exactly?
[19:19] <tjaalton> james_w: if it's in 1.5rc6, I'm about to merge it
[19:20] <tjaalton> bryce: add your script there and run it in the hal initscript
[19:20] <tjaalton> then there would be no need to reconfigure anything after console-setup config has been changed
[19:20] <tjaalton> just restart hal
[19:20] <bryce> tjaalton: did you talk with pitti about this?  Is he already going to go ahead with the change, or do we need to send him a request or debdiff or something?
[19:21] <tjaalton> bryce: yes, we discussed about it earlier today
[19:21] <james_w> bug 253021
[19:21] <bryce> ok, so no going into the xorg-server postinst?
[19:21] <tjaalton> nope
[19:21] <james_w> the fix is in xorg-server-1.4.99.906
[19:21] <bryce> hmm
[19:21] <tjaalton> james_w: so it's going to be updated later today or tomorrow
[19:21] <james_w> tjaalton: that works for me, thanks.
[19:23] <bryce> tjaalton: updated script at http://people.ubuntu.com/~bryce/InputHotplug/
[19:26] <tjaalton> bryce: yeah, looks good
[19:26] <bryce> brb *coffee*
[19:46] <bryce> tjaalton: ok are there any other tasks we need to do to prepare for it?  Otherwise I'll focus the day on assembling documentation for it
[19:48] <tjaalton> bryce: the xserver needs one patch to work around a bug in gnome, see freedesktop bug 16364, but I'll include it in the upload
[19:50] <tjaalton> I'm not 100% sure if it's a gnome bug or if it only triggers it, but there's a fresh patch for it in fedora
[19:50] <tjaalton> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-server/xserver-1.5.0-call-SwitchCoreKeyboard-for-first-device.patch?rev=1.1&view=auto
[19:50] <bryce> ok
[19:51] <bryce> looks sensible
[19:51] <bryce> it'll be nice to finally fix that keyboard bug
[19:52] <tjaalton> looks like a hack so it's not the final fix, but should get us moving
[19:53]  * bryce nods
[19:56] <bryce> mm, looks like we need a MIR for xinput.  I'll get that in.
[20:33] <bryce> mir -> #254749
[20:37]  * bryce curses the slow as h3ll ubuntu wiki
[21:25] <bryce> heya federico1
[21:25] <federico1> hey bryce
[21:25]  * federico1 has had zero time to work on the capplet
[21:25] <bryce> same
[21:25] <federico1> but now that we are doing opensuse 11.1, I'll start hacking on it again
[21:25] <bryce> cool
[21:26] <bryce> we're focusing more on input-hotplug for intrepid.
[21:26] <federico1> what plans do you have?  I have these on my to-do list:
[21:26] <federico1> - finish the tray icon.  Make sure it displays the rotation options for tablets / swivel monitors
[21:27] <federico1> - label the monitors with little windows that say "monitor 1", "monitor 2", to correlate them with the drag-the-monitors widget
[21:27] <federico1> - Make sure Fn-F7 does something sane
[21:27] <federico1> - finish the code to detect missing stuff in the X server or xorg.conf, and tell the user what he needs to change
[21:28] <tseliot> ﻿federico1: did you write the Screen Resolution panel?
[21:28] <bryce> we're working on some code for working around the need for putting in the virtual option to xorg.conf
[21:28] <bryce> which may address that last point
[21:28] <tjaalton> bryce: xorg-server git updated. anything else to add?
[21:30] <federico1> tseliot: just little parts of it; bryce and ssp did most of the work
[21:30] <bryce> tjaalton: not afaik
[21:30] <federico1> bryce: oh, how do you do that?
[21:30] <federico1> bryce: the big PITA is that to do it properly, the drivers need to be changed to move around all their buffers in the video card
[21:31] <tseliot> ﻿federico1: yes, as bryce said, we're working on that. I have written X-Kit and a little program which calculates the Virtual resolution and compares tit with the framebuffer
[21:31] <tseliot> and then use PolicyKit to set up the virtual resolution
[21:31] <bryce> federico1: it's a python script tseliot wrote, which you pass the desired screen dimensions, and it checks the xorg.conf settings and updates them (gksu) if needed
[21:31] <federico1> oooh, interesting
[21:31] <federico1> tseliot: where do you have that code?  I'd love to steal it :)
[21:32] <bryce> tseliot: do you have the bzr tree handy?
[21:32]  * federico1 doesn't really feel like writing an xorg.conf parser just right now
[21:32] <tseliot> federico1: I have written a xorg parser for the X-Kit project
[21:32]  * tseliot looks for the address
[21:33] <federico1> tseliot: wow, industrious man :)
[21:33] <tseliot> ;)
[21:33] <tseliot> federico1: my xorgparser is here: https://code.launchpad.net/~albertomilone/xorgparser/main
[21:34] <tseliot> NOTE: I haven't adapted the examples (yet) which therefore do not catch the exceptions which the parser raises
[21:34] <federico1> tseliot: awesome, thanks
[21:35] <federico1> tseliot: does that come with the policykit helper as well?
[21:35] <bryce> federico1: btw we're working to try to consolidate our various tools that need to fiddle with xorg.conf to use that code as the backend, so we only have one thing to maintain
[21:36] <tseliot> ﻿federico1: X-Kit doesn't depend on it, however the Python script which I wrote does use PolicyKit and a GTK Gui which integrates with the Screen Resolution panel
[21:36]  * tseliot looks for the other link
[21:36] <federico1> bryce: yeah, makes sense... I was thinking of adding a policykit helper to opensuse, based on our sax tool to configure X
[21:36] <federico1> changing those config files is scary :)
[21:38] <bryce> yup
[21:38] <bryce> all the hotplug rework is a good opportunity to do some cleanup though
[21:38] <tseliot> ﻿basically the C program should call my program more or less like this (at least in the current alpha): python /usr/share/screen-resolution-extra/policyui.py 0,0:1024x768 1024,0:1280x1024 0,768:1024x768 
[21:39] <tseliot> federico1: the code is not in bzr but you can get it here (the name of the package is screen-resolution-extra): https://launchpad.net/~x-kit/+archive
[21:39] <tseliot> the tarball is there
[21:40] <federico1> sweet
[21:40] <tseliot> federico1: oh and here's a screencast about it: http://www.albertomilone.com/screen_resolution.ogg
[21:41] <federico1> tseliot: thanks; I'll take a look 
[21:41] <federico1> what's the fashionable thing these days to do screencasts?  istanbul?
[21:44] <tseliot> maybe for photos, there are a lot of them on the various planet gnome, etc.
[21:44] <tseliot> all about Guadec, I guess
[21:45] <federico1> no, I mean, what software do you use :)
[21:45] <federico1> to record screencasts
[21:46] <tseliot> gtk-recordMyDesktop
[21:46] <tseliot> it works well
[21:47] <federico1> oooh, I had never seen that
[21:48] <tseliot> it has a very simple GUI and it's extremely easy to use
[21:48]  * federico1 records "how to look for porn effectively"
[21:49]  * tseliot would like to see that screencast
[21:49] <tseliot> :-P
[21:53] <tseliot> federico1: as regards X-Kit or the other program, let me know if there's something that you would like me to change or improve.
[21:56] <federico1> tseliot: thanks :)  I'll check them out soon and see
[21:56] <federico1> wow, this recordmydesktop thing is pretty nice
[21:56] <federico1> totally metro except for the old GtkFileSelection :)
[21:56] <james_w> hey federico1
[21:57] <federico1> hey james_w
[21:57] <james_w> federico1: I was interested by your rpm2git post, I haven't digested it enough yet to know what to make of it though.
[21:57] <federico1> james_w: oh, I just pushed a newer version!
[21:57] <federico1> james_w: I'm going to blog about its use cases
[21:57] <federico1> james_w: I want to use it for two things:
[21:58] <federico1> 1. when fixing a bug, I can rpm2git one of suse's rpms and start hacking in there
[21:58] <federico1> 2. I want to publish all of our distro patches on repositories with upstream's full history, to make it easier for people to see what we are up to
[21:59] <james_w> heh, that's pretty much what I'm working on too, except you could call mine deb2bzr
[22:00] <james_w> I agree it's very useful, it would be great if we could make it even more useful through something like vcs-pkg so that we can share the work
[22:00] <federico1> yeah, vcs-pkg looks pretty holy-grail-ish
[22:00] <james_w> yeah :-)
[22:01] <james_w> I think we need some intermediate steps before we can see how to get there, but it would be great.
[22:01] <james_w> I'm too bogged down in implementation details to contribute much to it at the moment.
[22:01] <federico1> I hope some of the rpath people get involved in vcs-pkg - they have some pretty interesting stuff going on
[22:02] <james_w> yeah, I need to look in to that more, it looks pretty cool
[22:02] <james_w> I think there is at least one person on the mailing list
[22:29] <tjaalton> bryce: hum, need to add a couple of patches for xkb option parsing, otherwise people will be upset. also, the keys in the script are deprecated, see xorg-server/config/x11-input.fdi for the new names :)
[22:33] <tjaalton> heh, fedora has just added fedora-setup-keyboard.. 17min ago
[22:34] <tjaalton> http://cvs.fedoraproject.org/viewcvs/rpms/xorg-x11-server/devel/fedora-setup-keyboard?rev=1.1&view=auto
[22:37] <tjaalton> and that's basically what I tried to do, but it didn't work at all
[22:37] <jcristau> heh
[22:56] <tjaalton> bryce: nevermind about the key names, they are correct after all, and the doc is wrong
[23:00] <tjaalton> bryce: so, the approach by ajax is what we want, although it needs a patching hal to add --direct, but that should be upstream sooner or later
[23:00] <tjaalton> -a
[23:01] <tjaalton> then there is only one configuration file for this stuff. actually, everything should be doable by fdi-files if we wanted to
[23:02] <tjaalton> it's just that the tools should be fixed to support that
[23:02] <tjaalton> tools that modify xorg.conf