| tjaalton | huh, weird.. installed nvidia-glx-177 and it pulled the -rt headers and nothing else | 10:08 |
|---|---|---|
| tjaalton | although nvidia-177-kernel-source depends on linux-headers-generic | linux-headers | 10:09 |
| tseliot | tjaalton: did you have the linux-headers-generic installed? | 10:11 |
| tjaalton | tseliot: no | 10:11 |
| tjaalton | that's what it should've installed | 10:12 |
| tseliot | it might have been linux-headers | 10:13 |
| tseliot | that's the only package which can pull the rt headers | 10:14 |
| tjaalton | right, I was trying to point out that apt should have pulled -headers-generic instead of -rt :) | 10:14 |
| tseliot | could it be that linux-headers-generic had dependency problems and couldn't be installed? | 10:16 |
| tjaalton | I could install it manually | 10:17 |
| * tseliot would like to have something more reliable than depending on linux-headers | 10:19 | |
| tseliot | making linux-image depend on its headers would solve this problem but it would also tick off some users | 10:22 |
| tjaalton | yep | 10:22 |
| tseliot | tjaalton: did you install the driver from Jockey? | 10:24 |
| tjaalton | tseliot: no, apt-get | 10:24 |
| tseliot | aah | 10:24 |
| tseliot | maybe we should talk about this with the kernel team at the UDS, they might have some ideas | 10:28 |
| tjaalton | it's just apt doing tricks | 10:29 |
| tjaalton | and I'm not coming to UDS | 10:30 |
| tjaalton | at least it's very unlikely now | 10:30 |
| tseliot | why? (if you don't mind me asking) | 10:30 |
| tseliot | is it because of sponsorship? | 10:31 |
| tjaalton | missed the deadline because I thought my boss would send me there like before (and I had to cancel the sponsorship then) | 10:31 |
| tjaalton | I've been waiting for a yes/no for a month now | 10:32 |
| tseliot | can't you talk to jcastro? | 10:32 |
| tjaalton | hm, I could | 10:32 |
| tseliot | I think he's the right person to ask | 10:32 |
| tjaalton | yep, done | 10:36 |
| tseliot | good, let me know how it goes | 10:37 |
| tseliot | bryce, mvo: this quick fix solves bug 287062: http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/revision/32 | 13:29 |
| ubottu | Launchpad bug 287062 in gnome-control-center "Screen resolution capplet unnecesarily tries to set virtual resolution" [Undecided,In progress] https://launchpad.net/bugs/287062 | 13:29 |
| mvo | superm1: thanks for your mail, please let me know when you had a chance to test the fglrx on your laptop, I think otherwise we are good for intrepid-proposed | 15:18 |
| tseliot | federico1: I have fixed this bug in the xrandr capplet: | 15:27 |
| tseliot | bug 287062 | 15:27 |
| ubottu | Launchpad bug 287062 in gnome-control-center "Screen resolution capplet unnecesarily tries to set virtual resolution" [Undecided,In progress] https://launchpad.net/bugs/287062 | 15:27 |
| tseliot | with this quick hack: http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/revision/32 | 15:27 |
| tseliot | you might want to have a look at it | 15:28 |
| tjaalton | mvo: can you see why apt chooses linux-headers-2.6.27-3-rt instead of linux-headers-generic when installing nvidia-*-kernel-source | 15:34 |
| tjaalton | mvo: when -k-s depends on linux-headers-generic | linux-headers | 15:34 |
| mvo | tjaalton: that sounds odd, is this rperoduceable? | 15:34 |
| tjaalton | mvo: yes.. | 15:34 |
| tjaalton | trivial to work around though, but still | 15:34 |
| mvo | tjaalton: give me some minutes I will see if it happens in a chroot | 15:36 |
| tjaalton | mvo: ubuntu-desktop recommends l-h-g, but my netboot-installation doesn't seem to pull them by default, so this should not be seen on normal installtions | 15:37 |
| Kano | hi, did you see the 2 new legacy beta drivers | 15:37 |
| Kano | at least 96.x has "Added preliminary support for X.Org server 1.5." | 15:39 |
| superm1 | lol. of course the day of release | 15:44 |
| mvo | tjaalton: it looks like it comes from dkms: Installing linux-headers-2.6.25-2-386 as dep of dkms | 15:44 |
| mvo | (output of apt-get install nvidia-177-kernel-source -o Debug::pkgDepCache::AUtoInstall=true) | 15:45 |
| tseliot | Kano: yep, I'll update them ASAP | 15:45 |
| superm1 | mvo, is that necessarily how they should be resolved though? why isn't linux-headers-generic chosen to resolve? | 15:46 |
| tjaalton | superm1: dkms should depend on l-h-g | l-h like nvidia-k-s | 15:47 |
| mvo | superm1: apt is not very smart when it resolves virtual packages, it just picks the first one that provides the required dependency | 15:47 |
| tjaalton | mvo: thanks, I'll try to figure out how to install recommended packages first :) | 15:47 |
| mvo | tjaalton: --install-recommends | 15:47 |
| mvo | tjaalton: you can also run "sudo apt-get install --fix-policy" | 15:47 |
| tjaalton | mvo: I mean the netboot installer | 15:47 |
| mvo | aha | 15:47 |
| tjaalton | there doesn't seem to be a preseed value to set | 15:48 |
| tjaalton | I'm preseeding pkgsel/include with a _lot_ of packages :) | 15:48 |
| superm1 | tjaalton, mvo but i mean because both nvidia-k-s and dkms are having the dependency, but nvidia-k-s has the harder dependency, shouldn't it resolve it nicer? | 15:48 |
| tjaalton | superm1: maybe so, but doesn't :) | 15:49 |
| tjaalton | phew, 546 new packages to install with --fix-policy | 15:51 |
| federico1 | tseliot: hmm, so is check_required_...() returning a bigger size than needed if you have mirrored screens? | 15:55 |
| tseliot | federico1: yes and I suspect that their ->x ->y are not set to 0 if clone mode is selected | 15:57 |
| tseliot | therefore mine is a quick and dirty hack which works without introducing new regressions | 15:58 |
| tseliot | eventually we may want to fix the actual problem though | 15:58 |
| tseliot | what do you think? | 15:59 |
| tseliot | superm1: what do you suggest that I do? | 16:03 |
| mvo | superm1: the algorithm is pretty simple, it resolves what it find, so if dkms is first and nvidia is later it resolves dkms first | 16:03 |
| mvo | not smart, but simple | 16:03 |
| superm1 | tseliot, about what? | 16:04 |
| tseliot | superm1: about nvidia-k-s, dkms and linux-headers | 16:04 |
| superm1 | mvo, why is this suddenly popping up as an issues then? shouldn't everyone that installs with jockey run into it then? | 16:04 |
| mvo | superm1: I think on most system linux-headers-generic is already installed, so its a non-issue | 16:06 |
| superm1 | ah | 16:06 |
| tseliot | superm1: it used to happen to users of kernel flavours other than -generic (even with jockey) | 16:06 |
| mvo | superm1: so only people with netboot installs or pbuilder chroots see it | 16:06 |
| superm1 | mvo, tseliot i think it's a small enough case then that we don't need to rush and say hurry up SRU a fix etc | 16:07 |
| superm1 | but an SRU to dkms would probably be a good idea then | 16:07 |
| tjaalton | superm1: right, but fix it for jaunty :) | 16:07 |
| superm1 | yeah | 16:07 |
| federico1 | tseliot: I'd rather have the real fix in the code in SVN :) | 16:08 |
| tjaalton | SRU is fine, we don't use intrepid on production systems though, so no rush | 16:08 |
| federico1 | tseliot: it shouldn't be hard to do; just check if the screens are mirrorred, inside that function | 16:08 |
| superm1 | mvo, will you have an update around UDS about the sticky packages idea that was brought up before, where it's at? | 16:08 |
| tseliot | superm1: I would like to make sure that Jockey installs the right headers for Jaunty too | 16:08 |
| federico1 | tseliot: I think ssp fixed the "zero offsets" problem at some point, or maybe it was something related | 16:08 |
| tseliot | federico1: do you mean the sanitize function? If yes, no it doesn't fix this | 16:09 |
| federico1 | tseliot: by the way, did you start the process to get a gnome svn account (or do you have one)? | 16:09 |
| mvo | superm1: I guess its something we need to talk about yes, its nowhere right now, its a challenge to implement and has some bits that needs thinking. but its clear that some sort of new dependencies seems to be required | 16:09 |
| tseliot | federico1: no, how do I do that? | 16:09 |
| superm1 | mvo, okay, well i'm sure we'll have some discussion that will relate to all this driver installation stuff again and it would be best to bring back up and think about those bits then | 16:11 |
| federico1 | tseliot: ah, ok - please read http://live.gnome.org/NewAccounts and follow the instructions. You can put me as the person who vouches for your awesomeness :) | 16:11 |
| tseliot | federico1: ok, thanks, I'll do it :-) | 16:11 |
| tseliot | federico1: it says: Vouchers For GNOME SVN and the ability to install new modules, please select who can vouch for you: | 16:21 |
| tseliot | but then I can only select the gnome module | 16:21 |
| tseliot | shall I write your name in the Comments field? | 16:22 |
| tseliot | federico1: here: https://mango.gnome.org/new_account.php | 16:22 |
| federico1 | tseliot: oh, hmm, I guess it is based on module maintainers now | 17:09 |
| tseliot | federico1: does my snapshot look good to you? | 17:09 |
| federico1 | tseliot: yeah, the image you sent should be fine... put in a little more detail in the comments about what you are doing | 17:10 |
| tseliot | ok | 17:10 |
| tseliot | federico1: something like this? http://pastebin.com/d518361e1 | 17:14 |
| federico1 | tseliot: perfect | 17:14 |
| tseliot | federico1: ok, done | 17:16 |
| bryce | tseliot: rev #32 looks good to me | 17:19 |
| tseliot | bryce: great | 17:20 |
| tseliot | mvo: how about merge from my branch? http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/revision/32 | 17:20 |
| tseliot | s/merge/merging/ | 17:22 |
| mvo | tseliot: is this for intrepid-prooposed? | 17:44 |
| mvo | or jaunty? | 17:44 |
| mvo | tseliot: I assume -proposed, I'm happy to sposnor it | 17:45 |
| bryce | mvo, yeah would be for intrepid-proposed | 17:48 |
| mvo | bryce, tseliot: please add TEST CASE as described in the StableReleaseUpdates wiki page to the report. I merge and sponsor now | 17:49 |
| bryce | I can do that | 17:50 |
| bryce | (the user essentially gave it in the description, but I'll clean it up) | 17:51 |
| mvo | yeah, the descriptions looks very good | 17:51 |
| mvo | it needs to be a) how to reproduce the problem b) how to verify the fix | 17:51 |
| tseliot | bryce: thanks | 17:53 |
| tseliot | mvo: we can use this report: bug 287062 | 17:53 |
| ubottu | Launchpad bug 287062 in gnome-control-center "Screen resolution capplet unnecesarily tries to set virtual resolution" [Undecided,In progress] https://launchpad.net/bugs/287062 | 17:53 |
| mvo | woah, archive.ubuntu.com is not answering at all currently | 17:54 |
| mvo | tseliot: ok | 17:54 |
| bryce | mvo, okay done | 17:57 |
| tseliot | good | 18:03 |
| * tseliot > dinner | 18:03 | |
| bdmurray | bryce: should bug 176061 really be a duplicate? It looks like you were working on it at one point. | 18:19 |
| ubottu | Launchpad bug 176061 in xserver-xorg-video-intel "System do not respond properly after rotate the screen (Weybridge) (dup-of: 132065)" [Medium,In progress] https://launchpad.net/bugs/176061 | 18:19 |
| ubottu | Launchpad bug 132065 in mesa "screen stops refreshing after rotate when running compiz fusion" [Unknown,Confirmed] https://launchpad.net/bugs/132065 | 18:19 |
| bryce | bdmurray: sorry was on conf call with amd. lemme look | 19:12 |
| bdmurray | bryce: thanks, no hurry | 19:12 |
| bryce | bdmurray: looks like the same bug to me (issue only occurs with compiz loaded), but do you have a reason to suspect them as separate bugs? | 19:14 |
| bdmurray | bryce: no, you had marked one as in progress so I was wondering if that should carry over. also they point to different upstream bugs | 19:16 |
| bryce | bdmurray: it looks like the upstream link for the duped bug is incorrect; it describes a performance issue when rotated, with compiz turned off | 19:23 |
| bryce | I don't remember why I set it to In Progress, but it's not something I'm working on currently. | 19:26 |
| bdmurray | alright, thanks for looking at it | 19:26 |
| bdmurray | its independent of the video driver correct? | 19:27 |
| bryce | well, it sounds like it's a bug in mesa | 19:33 |
| bryce | but mesa is composed of a lot of driver-specific code | 19:34 |
| bryce | but from looking at the bug, it does sound like it's a generic mesa problem that presumably affects more than just -intel | 19:35 |
| bryce | tseliot, tjaalton, mvo, superm1: I had a productive discussion with AMD about upstreaming fglrx bugs, and I think we'll be able to tighten up the process. | 20:54 |
| bryce | going forward, they'll work on getting more definitive answers (even if it's Won't Fix) on bugs we send to them. They'll take 5 per 2 weeks. | 20:54 |
| bryce | here's a page to document how to mark fglrx bugs to upstream, and how we'll track upstream's response: https://wiki.ubuntu.com/X/Upstreaming | 20:55 |
| bryce | tseliot, tjaalton, mvo, superm1: So if you find bugs that need to go to AMD, please follow that procedure, and I'll make sure to mention the ones marked to AMD during my calls with them. | 20:56 |
| tseliot | bryce: it's great news. Much better than telling users to file a bug report in AMD's bugzilla | 21:01 |
| * tseliot wishes that something similar could be available for NVIDIA too... | 21:02 | |
| tjaalton | bryce: ok, nice to know | 21:15 |
| wgrant | It's good to know that we have useful communication channels with them | 21:17 |
| bryce | added some links to some handy queries of the bugs - https://wiki.ubuntu.com/X/Upstreaming | 21:21 |
| tseliot | bryce: what do you think about these screenshots? http://www.dummies.com/WileyCDA/DummiesArticle/Mac-OS-X-Tiger-Timesaver-Using-Multiple-Displays.id-3130.html | 22:00 |
| bryce | ah I see where the gui concept came from | 22:02 |
| tseliot | hehe right | 22:02 |
| bryce | having the graphical display on a separate tab from the widgets is probably a good idea - that's one way to squeeze the dialog into a tighter space | 22:02 |
| tseliot | and (in the future) we could have more than 2-3 displays to show there | 22:03 |
| bryce | tseliot: I like it a bit more than our tool, however some of the widgets are not clear to me what they do | 22:03 |
| bryce | right | 22:03 |
| tseliot | I have found this page: http://movielibrary.lynda.com/html/modPage.asp?ID=593&cid=593 | 22:04 |
| tseliot | if you click where it says "Configuring your display with the Displays system preference" | 22:04 |
| tseliot | you will see a nice video of the panel in action | 22:04 |
| tseliot | I think there are some good ideas which we might reuse | 22:05 |
| bryce | yeah, I like the toolbar layout thingee; iirc we got a bug about that | 22:10 |
| bryce | the color management would also be pretty sweet | 22:10 |
| wgrant | Apart from that couple of additional features, that UI is awful. | 22:11 |
| tseliot | wgrant: why? | 22:12 |
| wgrant | tseliot: Why do I have to switch to some other tab to configure the layout of my monitors if I want to change the res as well? | 22:13 |
| tseliot | most users won't have to switch tab | 22:14 |
| wgrant | Why not? | 22:14 |
| tseliot | since they have 1 monitor or since the main monitor is selected by default | 22:14 |
| wgrant | Ah. | 22:14 |
| wgrant | Apart from needing a bit of prettification, I think gnome-display-properties is very good. | 22:15 |
| tseliot | yes, but 1) I'm not talking about gnome-display-properties and 2) I would like to have something more future-proof (try to manage more than 3 displays in that dialog) | 22:17 |
| tseliot | and there are other properties we have access to | 22:17 |
| tseliot | that are not in the mac ui either | 22:18 |
| wgrant | Such as? | 22:18 |
| wgrant | Hmm, I guess panel fitting and TV format might be useful. | 22:20 |
| wgrant | But I can't think of much else. | 22:20 |
| tseliot | I've got a list somewhere (I got it from the output of my library) | 22:20 |
| * tseliot looks in his laptop | 22:21 | |
| wgrant | I see that XRandR 1.3 is getting better property support. | 22:21 |
| tseliot | yep | 22:21 |
| tseliot | panel_fitting, backlight_control, gamma and (for TVs) bottom, right, top, left, tv_format | 22:25 |
| wgrant | Ah, good point. | 22:25 |
| tseliot | putting all this stuff in a usable UI might not be easy though ;) | 22:26 |
| wgrant | Shouldn't backlight_control not be fiddled with by users? | 22:26 |
| tseliot | I haven't seen what values these properties support yet | 22:27 |
| tseliot | therefore I wouldn't know | 22:27 |
| wgrant | BACKLIGHT_CONTROL: combination | 22:27 |
| wgrant | supported: native legacy combination kernel | 22:27 |
| wgrant | That looks fairly hostile and irrelevant to users. | 22:27 |
| tseliot | right | 22:27 |
| tseliot | panel fitting and tv controls can be useful though | 22:29 |
| wgrant | Definitely. | 22:29 |
| wgrant | I wasn't aware that panel fitting was controllable from outside the BIOS until I saw the property while debugging my backlight. | 22:29 |
| tseliot | I'm afraid we can do it only with drivers which support randr 1.2 | 22:30 |
| wgrant | Of course. | 22:30 |
| tseliot | the good thing about the mac ui is that when for example 1.2 is not supported you simply don't show the "arrangement" tab | 22:31 |
| tseliot | currently we show a screen with an "Unknown" label | 22:32 |
| tseliot | ok, a small detail | 22:32 |
| tseliot | s/small/irrelevant/ | 22:32 |
| tseliot | ;) | 22:32 |
| wgrant | Is nvidia going to get moving on 1.2 at any point? | 22:32 |
| tseliot | I wish I knew... | 22:33 |
| tseliot | I doubt it will remain the only driver which doesn't support 1.2 | 22:33 |
| tseliot | maybe when randr supports multiple GPUs | 22:33 |
| * wgrant -> uni | 22:34 | |
| tseliot | bye | 22:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!