| 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:17 |
|---|---|---|
| tjaalton | checking.. | 13:33 |
| tjaalton | right, it's commented out from series | 13:34 |
| tjaalton | as is 111 | 13:34 |
| jcristau | ok, so just confusing changelog. thanks for checking :) | 13:39 |
| tjaalton | np | 13:43 |
| 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:58 |
| tjaalton | tseliot: I've gotta run soon :/ | 15:59 |
| tseliot | tjaalton: thanks anyway | 15:59 |
| seb128 | tseliot: hi, how busy are you? ;-) could you update your 100_load_desired_settings.patch gnome-desktop patch to the current version? | 16:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| seb128 | brb | 16:06 |
| seb128 | restarting my session using the new glib | 16:06 |
| 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:19 |
| 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:20 |
| 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:21 |
| seb128 | and you should open a bug on bugzilla about the patch if upstream doesn't reply to emails | 16:22 |
| tseliot | seb128: I already did that. Actually I used a bug report which you opened | 16:23 |
| seb128 | hum, ok | 16:25 |
| 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:26 |
| tseliot | superm1: shall I consider it a no? ;) | 16:28 |
| superm1 | huh tseliot ? | 16:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| tseliot | superm1: there's no hurry, not for me at least ;) | 16:36 |
| bryce | morning | 17:07 |
| 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:37 |
| 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:38 |
| bryce | superm1: yeah, what implements fn+f8 currently? | 17:41 |
| 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:42 |
| bryce | iirc the ScreenResolution upstream work was going to implement a better binding for that. dunno if it got implemented | 17:43 |
| 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:45 |
| 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:47 |
| seb128 | what change? | 17:48 |
| superm1 | sure, seb128 i just mentioned this: | 17:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| superm1 | okay so lets refer to it as XF86Display from now on, i suppose variations of laptops change where that keycode comes from. | 17:56 |
| jcristau | bryce: hrm, isn't your 111_textured_video_option.patch superseded by 24c34f02 in -intel? | 20:28 |
| tjaalton | jcristau: it's commented out from series like 128 | 20:29 |
| 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:30 |
| bryce | hrm, is there a faster way to look up commit id's besides cgit? | 20:32 |
| tjaalton | git log :) | 20:32 |
| tjaalton | or diff | 20:33 |
| tjaalton | right, git diff foo | 20:34 |
| bryce | git log doesn't show 24c34f02. git diff 24c34f02 returns a 32,000 line diff ;-) | 20:35 |
| tjaalton | true, without more options it just shows the diff between your current head and the commit | 20:37 |
| bryce | jcristau: thanks, uploaded | 20:44 |
| jcristau | what you want is 'git show', fwiw | 20:47 |
| bryce | aha, good to know | 20:48 |
| tjaalton | heh, didn't know about that one | 21:01 |
| 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:06 |
| 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:07 |
| tjaalton | syncs from experimental? | 21:11 |
| * bryce nods | 21:14 | |
| 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:15 |
| bryce | yeah I figured we may as well wait until the server is updated | 21:16 |
| 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:26 |
| 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:30 |
| 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:32 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| superm1 | how does -intel determine what it's able to do? | 22:44 |
| superm1 | have you poked around the driver? | 22:44 |
| wgrant | Sorry, was on the phone. | 23:19 |
| 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:20 | |
| 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:27 | |
| wgrant | I don't see why xrandr should be preferred over hal. | 23:29 |
| superm1 | have you talked to upstream about the possibility of switching it? | 23:31 |
| jcristau | doesn't the X driver just use sysfs for backlight stuff? | 23:32 |
| superm1 | not necessarily. it's got this combination support where it will use sysfs or native | 23:33 |
| wgrant | It'd be really nice if manufacturers just didn't reinvent backlight control. | 23:40 |
| superm1 | well that's why hal is there | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!