[00:12] <bryce> tjaalton: in #271138 you suggested xserver-xorg should depend on -evdev; I've committed this change, but am not 100% sure that's the correct fix?
[00:21] <wgrant> I think it needs a Really-Really-Really-Recommends.
[00:21] <bryce> heya wgrant
[00:21] <bryce> ideas on #276857?
[00:23] <wgrant> Lovely.
[00:23] <wgrant> I've seen a fair bit of that on ubuntuforums, but I presumed it was the hal race...
[00:35] <bryce> something's going bad in libhal
[00:59] <bryce> yeah looks like inside libhal, one of the dbus calls is not working properly
[00:59] <bryce> so probably not an xorg issue
[07:24] <tjaalton> bryce: shouldn't matter if the kbd-lovers have evdev installed ;)
[07:34] <bryce> tjaalton: referring to #271138?
[07:37] <tjaalton> bryce: yeah
[07:37] <bryce> tjaalton: do you think the change will hurt some users?
[07:38] <tjaalton> bryce: possibly, if they have a stripped-down system with only the essential drivers and no desire to use input-hotplug. but even for them it should work after upgrade, just with evdev
[07:39] <bryce> hrm
[07:40] <tjaalton> and adding AutoAddDevices to serverflags would again make kbd/mouse work if needed
[07:40] <tjaalton> but there should be no need to do that..
[07:42] <tjaalton> but IMO the users who have blindly forced through an upgrade (and don't have input-all/evdev installed) are more important
[07:42]  * bryce nods
[07:42] <bryce> I'm open to suggestions on this one
[07:43] <tjaalton> we discussed it wit jcristau
[07:43] <tjaalton> +h
[07:43] <bryce> ok
[07:46] <bryce> and...?
[07:48] <tjaalton> well, if it needs to depend it, that's the place
[07:49] <tjaalton> but he hasn't given it too much thought yet
[07:49] <tjaalton> it might change for jaunty
[07:49] <bryce> ok, that's fine
[08:39] <mvo_> tjaalton: what is the current best way to make the middle button a scrollwheel? still the fdi stuff from my blog? or is there some cool UI now?
[08:40] <tjaalton> mvo_: I don't know if there is a gui for it, but 'xinput' should work
[08:43] <mvo_> Ng: hi! I think you did the xinput magic for the middle mouse button, do you have the recipt for me? this looks like a cleaner solution
[08:45] <mvo_> hm,  xinput set-int-prop "TPPS/2 IBM TrackPoint" format 8 EmulateWheelButton 2 <- something like this?
=== mvo_ is now known as mvo
[08:53] <wgrant> tjaalton: There's no GUI for that yet, unfortunately.
[08:53]  * wgrant points to Jaunty, as usual.
[08:54] <tjaalton> bad Jaunty ;)
[09:41] <Ng> mvo: sure, just a sec
[09:41] <Ng> hm, bah, i thought I blogged this
[09:42] <Ng> mvo: http://pastebin.com/f43ddc932
[09:42] <Ng> mvo: see also bug 282387
[09:42] <ubottu> Launchpad bug 282387 in evdev "scrollwheel emulation breaks after suspend with 2.6.27-7" [Unknown,In progress] https://launchpad.net/bugs/282387
[09:42] <mvo> thanks Ng!
[09:43] <Ng> mvo: feel free to track down and fix the bug, it's making me very sad ;)
[09:44] <mvo> Ng: I never noticed it with the fdi stuff
[09:44] <mvo> Ng: thanks, it will make me sad as well
[09:44] <mvo> Ng: you put it into you .xsession file?
[09:44]  * mvo wonders if there is a .xsession.d dir
[09:45] <Ng> mvo: I chucked it in a script in my ~/bin/ and call it from the gnome session thingy, but it's not an adequate solution because the properties are lost when the device is removed for suspend
[09:45] <Ng> so I was 
[09:45] <Ng> just running the script manually again on resume
[09:46] <Ng> but atm even that isn't worth doing because it then just doesn't work without restarting X or rebooting
[09:48] <mvo> Ng: thanks for all this input (no pun intended :)
[09:48] <Ng> hehe, np
[09:49] <Ng> fwiw at the suggestion of the upstream input guy (Peter Hutterer) I built the git version of evdev and tried it with that, but that was a giant pile of spectacular fail and I couldn't even get the scroll to work without the suspend/resume problem (I figured our X server is probably sufficiently different to git for that not to work, or I was just building it wrong)
[09:51] <tjaalton> hrm, can't get cups-pdf to work
[09:56] <jcristau> mvo: you can call run-parts from ~/.xsession or ~/.xsessionrc i guess
[09:58] <tjaalton> mm, installing cups-pdf might help
[10:15] <mvo> jcristau: oh, cool! thanks
[11:02] <Q-FUNK>            Bug #287462
[11:02] <ubottu> Launchpad bug 287462 in gnome-settings-daemon "Intrepid: forget left-handed mouse setting after resuming from sleep/hibernation" [Undecided,New] https://launchpad.net/bugs/287462
[11:02] <Q-FUNK> is this an X issue because of the switch to inputdev?
[12:53] <Ng> is there a correct way of handling a monitor which is being detected as 640x3something?
[12:53] <Ng> like, aside from whatever underlying bug there is, or broken EDID, is there a correct way to force it to use 1024x768? The X config tool seems to exist less than it used to ;)
[12:54] <jcristau> Ng: Option "PreferredMode" "1024x768", and maybe add a modeline for it
[12:54] <jcristau> (assuming randr1.2 driver)
[12:56] <Ng> I was hoping there would be an option which didn't involve an xorg.conf, but ok ;)
[12:56] <tjaalton> a proper monitor perhaps?-)
[12:57] <jcristau> how could you force anything without an xorg.conf?
[13:08] <Ng> jcristau: well presumably this could be fixed with xrandr --output VGA --addmode
[13:08] <Ng> but that won't persist
[13:09] <wgrant> g-s-d needs to learn how to do that. Or we need to quirk every monitor.
[13:09] <Ng> wgrant: that would make sense, otherwise the new world order of no xorg.conf quickly fails
[13:09] <wgrant> It shouldn't be difficult to do.
[13:45] <jcristau> Ng: a 5 line xorg.conf for a broken monitor is not too bad imo
[13:47] <wgrant> Especially if we can get screen-resolution-extra to do it with its X-Kit goodness.
[13:48] <Ng> if a tool makes it, sure
[13:49] <Ng> if I have to make it, fail. I have already forgotten most of what I ever knew about X config files ;)
[14:00] <tseliot> wgrant: yes, that would be easy to do. I wonder how it could be done from a GUI though
[14:02] <wgrant> tseliot: "Custom..." in the Resolution dropdown?
[14:03] <tseliot> wgrant: yes, that can be done.
[14:03]  * tseliot would like to rewrite that applet in python with his new python-xcb-randr library
[14:04] <wgrant> That would be nice, but would mean huge permanent divergence from GNOME.
[14:04] <jcristau> that sounds like the opposite of nice :)
[14:04] <Ng> gnome needs to learn to love the python
[14:05] <tseliot> yes, I know but it would be something that both GNOME and KDE could use
[14:05] <tseliot> only the front end would be different
[14:05] <tseliot> jcristau: this is my idea of "nice"
[14:05] <jcristau> i meant the huge diff from upstream
[14:06] <jcristau> i couldn't care less whether it's c or python
[14:06] <wgrant> C is no problem once you get used to it.
[14:06] <tseliot> if upstream doesn't accept my patches to the applet I don't know if I can maintain a patch which is more that 500 lines
[14:07] <tseliot> of course C is not a problem ;)
[14:07] <Ng> C is a huge problem! :)
[14:07] <Ng> I have much better things to do than remember to free memory ;)
[14:07] <tseliot> hehe
[14:08] <jcristau> programming is hard. freeing memory is the least of your worries
[14:08] <tseliot> the right tool for the job
[14:08] <wgrant> I think we should rewrite it using PHP's GTK bindings.
[14:08]  * jcristau kills wgrant 
[14:08] <wgrant> That is surely the right tool.
[14:08] <wgrant> jcristau: Thankyou. I agree.
[14:08] <jcristau> :)
[14:09] <tseliot> wgrant: let's use javascript and qt4 instead
[14:09] <tseliot> :-P
[14:09] <wgrant> No, no. VBScript and Qt4.
[14:09]  * jcristau dies
[14:09] <wgrant> VBScript and raw X11.
[14:09] <wgrant> Anyway, bedtime.
[14:09] <wgrant> We can argue at UDS.
[14:10] <tseliot> right. Good night wgrant
[14:10] <wgrant> Night.
[17:06] <Q-FUNK> re
[17:27] <Ng> hrm, what happened to my brightness keys!
[17:27] <Ng> tjaalton: are yours still working?
[17:30] <Ng> err belay that, my session was hosed => no g-p-m. sorry
[17:35] <bryce> heya
=== steve__ is now known as sbeattie
[20:31] <Q-FUNK> since upgrading to intrepid, left-handed mouse settings in gnome disappear when returning from sleep or hibernate