[13:17] <jcristau> hmm. why does your -intel changelog still mention 128_stolen_memory_counting_g4x.patch for 2.5.1? that patch was in 2.4.98.0 already.
[13:33] <tjaalton> checking..
[13:34] <tjaalton> right, it's commented out from series
[13:34] <tjaalton> as is 111
[13:39] <jcristau> ok, so just confusing changelog. thanks for checking :)
[13:43] <tjaalton> np
[15:58] <tseliot> tjaalton or superm1: can you upload the nvidia 177, 173 and 96 to intrepid-proposed (from Jaunty) and put 180 in intrepid-backports? 
[15:59] <tjaalton> tseliot: I've gotta run soon :/
[15:59] <tseliot> tjaalton: thanks anyway
[16:00] <seb128> tseliot: hi, how busy are you? ;-) could you update your 100_load_desired_settings.patch gnome-desktop patch to the current version?
[16:01] <seb128> tseliot: is there any bugzilla bug about that change btw and any discussion about getting that upstream too?
[16:01] <tseliot> seb128: why, what happened? Does the patch fail to build?
[16:01] <tseliot> seb128: I wish upstream could reply to my email :-(
[16:01] <seb128> tseliot: upstream did changes to the logic in this source and I don't fancy trying to understand the logic and the change to update the patch, that's blocking half of the GNOME 2.25 updates
[16:02] <tseliot> seb128: ouch. Ok, where shall I get the source from? Svn or bazaar?
[16:02] <seb128> tseliot: http://ftp.acc.umu.se/pub/GNOME/sources/gnome-desktop/2.25/gnome-desktop-2.25.2.tar.gz
[16:03] <seb128> tseliot: http://svn.gnome.org/viewvc/gnome-desktop/trunk/libgnome-desktop/gnome-rr-config.c?r1=5229&r2=5253 is the upstream change
[16:03]  * tseliot has a look at the diff
[16:03] <seb128> it's probably not too much work but I've a pile of updates and I would like to get most of those done before travelling for uds
[16:04] <seb128> so if I can avoid spending an hour updating a distro patch i've no clue about that would be nice ;-)
[16:04] <seb128> thanks!
[16:06] <seb128> brb
[16:06] <seb128> restarting my session using the new glib
[16:19] <tseliot> seb128: it looks like the removed gnome_rr_config_find() and changed the file a bit. I'll work on it but I don't think I can do it today. Is it a problem?
[16:19] <tseliot> s/the removed/they removed/
[16:20] <seb128> tseliot: I'll look at what other updates I can do, it blocks the nautilus update for example
[16:20] <seb128> tseliot: no real hurry but I wanted to do the 2.25 updates before uds, anyway whenever you can, tomorrow would be nice
[16:20] <tseliot> seb128: otherwise you can (temporarily) remove my 2 patches
[16:21] <tseliot> I'm fine with either choice
[16:21] <seb128> I would prefer getting the patch updated ;-) but I'll consider that tomorrow if I run out of updates I can do
[16:21] <tseliot> ok, good
[16:22] <seb128> and you should open a bug on bugzilla about the patch if upstream doesn't reply to emails
[16:23] <tseliot> seb128: I already did that. Actually I used a bug report which you opened
[16:25] <seb128> hum, ok
[16:26] <tseliot> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=545118
[16:26] <ubottu> Gnome bug 545118 in Screen resolution "should give a clue about why the settings can't be applied sometimes" [Normal,New]
[16:28] <tseliot> superm1: shall I consider it a no? ;)
[16:29] <superm1> huh tseliot ?
[16:30] <tseliot> superm1: can you upload the nvidia 177, 173 and 96 to intrepid-proposed (from Jaunty) and put 180 in intrepid-backports? 
[16:30] <tseliot> superm1: pitti gave me his ACK
[16:31] <tseliot> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/297543
[16:31] <ubottu> Ubuntu bug 297543 in nvidia-graphics-drivers-180 "Update Package: nVidia 180.06" [Undecided,In progress]
[16:31] <superm1> tseliot, not at the moment no sorry.  wouldn't 180 make more sense in -updates since it's NEW anyway?
[16:32] <tseliot> superm1: it's still an alpha
[16:32] <tseliot> and it's no longer in NEW
[16:32] <superm1> tseliot, yeah but it's NEW in intrepid still
[16:33] <superm1> it either get's NEWed into backports or into updates either way
[16:33] <superm1> i suppose backports makes more sense though if you're going to be updating it as more releases come out
[16:33] <tseliot> superm1: if we put an experiment release in -updates without blacklisting it in jockey it will get installed by default instead of the stable release
[16:34] <superm1> well that'd be if you installed the modaliases package
[16:34] <superm1> which it wouldn't be
[16:34] <tseliot> superm1: good point
[16:35] <superm1> anyhow though, you might want to put this into the main sponsors queue for now.  i should have some time tomorrow if no one nabs it
[16:36] <tseliot> superm1: there's no hurry, not for me at least ;)
[17:07] <bryce> morning
[17:37] <superm1> bryce, i was talking to nvidia yesterday; on laptops that have nvidia graphics, they do have a command line interface for nvidia-settings changing displays.  perhaps it would make sense to have the fallback for fn-f8 if RR 1.2 isn't detected to look for that binary and if it finds it try calls there
[17:38] <superm1> at least in the cases that ACPI events aren't generated from fn-f8.  a lot of the new laptops don't do ACPI events, but instead NVIF and a keycode press
[17:41] <bryce> superm1: yeah, what implements fn+f8 currently?
[17:42] <superm1> bryce, well gnome settings daemon is binding it, so i'm guessing it's probably just xrandr --auto
[17:42] <bryce> mm could be
[17:42] <superm1> perhaps a small python app that does this fall back makes more sense
[17:43] <bryce> iirc the ScreenResolution upstream work was going to implement a better binding for that.  dunno if it got implemented
[17:45] <superm1> well nonetheless, whatever binding it ends up going to - at least until NV has the RR1.2, it should fall back
[17:45] <superm1> AMD I think it's less of an issue since they provide atieventsd 
[17:47] <superm1> gah, i'm working on an SRU to re-enable XF86Battery, and it's going to need to touch xkeyboard-config, libx11, gnome-power-manager, and x11proto-core.  just for one hotkey, i wonder if this is worth it..
[17:47] <bryce> superm1: since that's against g-s-d could you talk with seb128 about this?  I suspect he'd like to push that change upstream if possible
[17:48] <seb128> what change?
[17:48] <superm1> sure, seb128 i just mentioned this: 
[17:49] <superm1> i was talking to nvidia yesterday; on laptops that have nvidia graphics, they do have a command line interface for nvidia-settings changing displays.  perhaps it would make sense to have the fallback for fn-f8 if RR 1.2 isn't detected to look for that binary and if it finds it try calls there at least in the cases that ACPI events aren't generated from fn-f8.  a lot of the new laptops don't do ACPI events, but instead NVIF and a keycode press
[17:50] <seb128> right, would be nice to suggest that upstream in any case
[17:50] <superm1> what's the work going on upstream for the fn-f8 binding?
[17:50] <seb128> not having a ton of distro patches makes the job easier for everybody ;-)
[17:51] <seb128> not that I know about
[17:51] <superm1> bryce, what was "<bryce> iirc the ScreenResolution upstream work was going to implement a better binding for that.  dunno if it got implemented" in reference to then?
[17:53] <bryce> superm1: I read in the todo list early on that there was a plan to add support for toggling between different configs in your monitors.xml with the CRT/LCD button (fn+f8 for me)
[17:53] <bryce> superm1: later I saw some cvs entries alluding to the above work being implemented
[17:53] <bryce> I have not seen it in action or know whether the function is complete or usable
[17:54] <seb128> they added fn-f7 code recently
[17:54] <seb128> but I've not seen any change about f8 yet
[17:54] <bryce> seb128: what is fn+f7?
[17:54] <superm1> okay i'm referring to XF86Display being fn-f8, is that what you mean for fn-f7  too?
[17:55] <bryce> yeah
[17:55] <seb128> equivalent of calling xrandr --auto
[17:55] <seb128> I think
[17:55] <bryce> anyway, just worth keeping in mind if talking to upstream - they'll probably expect new ideas to integrate nicely with whatever they're already working on
[17:56] <superm1> okay so lets refer to it as XF86Display from now on, i suppose variations of laptops change where that keycode comes from. 
[20:28] <jcristau> bryce: hrm, isn't your 111_textured_video_option.patch superseded by 24c34f02 in -intel?
[20:29] <tjaalton> jcristau: it's commented out from series like 128
[20:30] <jcristau> tjaalton: https://lists.ubuntu.com/archives/jaunty-changes/2008-December/001476.html
[20:30] <bryce> jcristau: let me look
[20:30] <tjaalton> jcristau: oh..
[20:32] <bryce> hrm, is there a faster way to look up commit id's besides cgit?
[20:32] <tjaalton> git log :)
[20:33] <tjaalton> or diff
[20:34] <tjaalton> right, git diff foo
[20:35] <bryce> git log doesn't show 24c34f02.  git diff 24c34f02 returns a 32,000 line diff ;-)
[20:37] <tjaalton> true, without more options it just shows the diff between your current head and the commit
[20:44] <bryce> jcristau: thanks, uploaded
[20:47] <jcristau> what you want is 'git show', fwiw
[20:48] <bryce> aha, good to know
[21:01] <tjaalton> heh, didn't know about that one
[21:06] <bryce> oh tjaalton, btw meant to tell you...  I finished that sync request script and did all the obvious syncs on the ubuntu-x package page
[21:07] <bryce> tjaalton: however I wanted to ask - there's a bunch that are just rebuilds
[21:07] <bryce> I assumed there wasn't much point to doing them, but is there?  It's easy enough to do.
[21:11] <tjaalton> syncs from experimental?
[21:14]  * bryce nods
[21:15] <tjaalton> ok, so they are harmless to sync anyway
[21:15] <bryce> I was figuring we'd just wait until unstable has a new version and then they'll just autosync
[21:15] <tjaalton> either way is fine
[21:15] <tjaalton> but.. we might need to rebuild them for 1.6
[21:16] <bryce> yeah I figured we may as well wait until the server is updated
[22:26] <wgrant> Do I blame -intel if I can no longer VT switch safely while running Compiz in Jaunty?
[22:26] <wgrant> (if I suspend and resume, I can unlock the screen, but then I just get a cursor and not even magic-sysrq.
[22:30] <superm1> wgrant, i've got a gpm sru that i've put together.  it may help with your earlier issues related to gpm
[22:30] <superm1> wgrant, (and if you're in jaunty, it's coming there too)
[22:32] <bryce> wgrant: likely -intel
[22:32] <bryce> wgrant: I saw similar symptoms in launchpad; might be good to browse and see if you're seeing an issue we already had reported
[22:37] <wgrant> superm1: I'm currently running a custom gpm that prefers xrandr over hal. Other people are running it from my PPA for the same fix.
[22:37] <wgrant> Er, prefers hal over xrandr.
[22:37] <superm1> wgrant, well the fix i put in falls back to hal when xrandr starts failing
[22:38] <wgrant> How do you mean?
[22:38] <wgrant> In my case xrandr doesn't fail.
[22:38] <superm1> well there's two types of failures i saw - one of them was when xrandr claimed it could change the brightness when there was a range of Min: 0 Max: 0.  the other was when one of the calls somewhere would return False
[22:39] <superm1> and this should cover both of those
[22:39] <superm1> so what was it about xrandr that was causing your problem?
[22:39] <wgrant> It claims to work, but it doesn't.
[22:39] <wgrant> It has an obscenely high maximum, and doesn't actually change the brightness.
[22:40] <wgrant> This isn't too bad, because the brightness buttons also work in hardware, but it means brightness applets and automatic dimming fail, and gpm hangs a lot.
[22:41] <superm1> ah that's a worse (and more annoying) problem then too
[22:41] <superm1> what series is your laptop?
[22:41] <wgrant> 630m
[22:42] <wgrant> Quite a few Dells seem to be affected.
[22:42] <superm1> well the series is important though because different ODMs do different series'
[22:42] <superm1> and don't necessarily adhere to Dell's libsmbios spec as closely
[22:42] <superm1> the problems i referred to above affect the studio line and some inspirons
[22:43] <wgrant> AFAICT the problem is unrelated to libsmbios - the problem is -intel is saying that it can do things when it can't.
[22:43] <wgrant> If I make it use libsmbios via hal, it's fine.
[22:43] <superm1> ah okay
[22:44] <superm1> how does -intel determine what it's able to do?
[22:44] <superm1> have you poked around the driver?
[23:19] <wgrant> Sorry, was on the phone.
[23:20] <wgrant> I poked around a bit.
[23:20] <wgrant> But I couldn't do an awful lot, as it was during exams.
[23:20]  * wgrant looks now.
[23:27] <superm1> tbh i've yet to see a useful execution of the backlight support in -intel :)
[23:27]  * wgrant is trying to read that line, but is thwarted by a hung brightness indicator... it'll be a few seconds.
[23:29] <wgrant> I don't see why xrandr should be preferred over hal.
[23:31] <superm1> have you talked to upstream about the possibility of switching it?
[23:32] <jcristau> doesn't the X driver just use sysfs for backlight stuff?
[23:33] <superm1> not necessarily.  it's got this combination support where it will use sysfs or native
[23:40] <wgrant> It'd be really nice if manufacturers just didn't reinvent backlight control.
[23:47] <superm1> well that's why hal is there