[00:59] <bryce> wgrant: draft #0 of a hotkey troubleshooting document - https://wiki.ubuntu.com/Hotkeys
[01:00] <bryce> wgrant: I'm sure it's full of inaccuracies, so please update it if you spot stuff you know is wrong (and don't be shy about deleting unnecessary fluff)
[01:00] <bryce> bbiab
[01:10]  * wgrant considers adding every other package to that list.
[02:17] <bryce> back
[02:19]  * wgrant returns.
[04:20] <ScottK-laptop> bryce: Got it sorted.  I've asked Riddell to check my workaround for sanity.  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/290156/comments/14
[04:20] <ubottu> Launchpad bug 290156 in xorg-server ""Display out of range" after upgrade to Intrepid" [High,Triaged] 
[04:30] <bryce> ScottK-laptop: cool, yes that looks like a solid good workaround
[04:30] <bryce> ScottK-laptop: hopefully we hear from upstream before too long
[04:30] <ScottK-laptop> Yeah.  The best news is I can put the LCD back on my wife's computer before she gets home tomorrow.
[04:31] <bryce> hehe
[04:32] <ScottK-laptop> That was a reasonably popular monitor a few years ago.  It might not hurt to have the GDM workaround documented there too.
[04:37] <superm1> bryce, so within that document i think it'd be preferable to nuke the Part B
[04:37] <superm1> and all references to hotkey-setup
[04:37] <superm1> in preference of doing it all by hal
[04:38] <superm1> I think if the total push is for by hal, it keeps people from mucking in other areas like hotkey-setup when they really shouldn't be
[04:39] <superm1> also along part B, having X with all these different "keyboard options" is going to keep things complicated too since its all with evdev instead now
[04:49] <bryce> superm1: good point; anything in part B that should be kept?
[04:51] <superm1> bryce, no i dont think anything in there would be useful for debugging purposes anymore now that input hotplug is in place
[04:52] <superm1> of course there is always history to the page though if it's determined that that is incorrect
[05:06] <bryce> superm1: updated
[05:08] <superm1> bryce, do you already have a spec to discuss cleanups as a result of input hotplug then too for UDS?
[05:08] <bryce> superm1: no
[05:09] <superm1> bryce, if not, I think it should be squeezed into an existing session (maybe the move all hotkeys to hal that i was proposing as the one i'd drive)
[05:09] <bryce> sure sounds good
[05:10] <bryce> so far the only one I know for sure is slangasek's acpi/hotkey architecture documentation spec
[05:11] <bryce> er s/spec/discussion session/
[05:11] <superm1> when will the list of sessions be posted then?
[05:13] <bryce> dunno yet, I imagine everyone is recovering from the release
[05:13] <superm1> well it seems really weird that there is so much time between release and UDS tbh
[05:14] <superm1> seems like that would be  possibly valuable development time for some of these specs
[05:21] <bryce> gives us time for upstreaming bugs ;-)
[05:38] <wgrant> superm1: I find the lag very unfortunate too.
[05:38] <wgrant> There's a good quarter of the cycle gone.
[05:39] <superm1> well if nothing else it gives a lot of time for SRUs
[05:40] <wgrant> I would have expected this for an LTS.
[16:47] <james_w> "DRM modesetting drivers" <- does that mean GEM?
[16:52] <tjaalton> james_w: where did you read that?
[16:52] <james_w> the plymouth README
[16:53] <tjaalton> ok
[16:53] <james_w> I wondered whether it depended on the fact that Fedora backported GEM
[16:53] <tjaalton> modesetting needs GEM
[16:53] <tjaalton> but that's in 2.6.28rc already
[16:53] <james_w> so it would be likely usable in Jaunty?
[16:53] <tjaalton> yes
[16:53] <james_w> but only for those with supported drivers?
[16:54] <james_w> intel/ATI I believe?
[16:54] <tjaalton> plymouth should fall back to other methods if it's not available
[16:54] <tjaalton> right, intel/ati support it
[16:54] <james_w> yeah, it falls back to text
[16:54] <tjaalton> actually, modesetting might not make it in .28
[16:54] <james_w> so several users would lose graphical boot if we switched.
[16:54] <tjaalton> I'm not sure where things are
[16:54] <tjaalton> is text the only fallback?
[16:55] <james_w> It looks like it
[16:55] <tjaalton> hm, I remember there being others too
[16:55] <james_w> "For systems that don't have DRM mode settings drivers, plymouth falls back to
[16:55] <james_w> text mode.
[16:55] <james_w> "
[16:55] <tjaalton> ok then
[16:57] <bryce> heya tjaalton
[16:57] <tjaalton> hi bryce
[16:59] <james_w> thanks tjaalton 
[16:59] <james_w> hey bryce 
[16:59] <bryce> heya james_w
[17:00] <bryce> hey, since a lot of hotkey bugs have been getting tossed (incorrectly) our way, I drafted the start of a document about it, to try and help spread knowledge about it to more people
[17:00] <bryce> http://wiki.ubuntu.com/Hotkeys
[17:01] <bryce> tjaalton, james_w: when its convenient, could each of you add what you know to that document?
[17:01] <james_w> done :-)
[17:01] <bryce> james_w: excellent thanks :-)
[17:03] <james_w> nice work though, I'll be sure to refer to it when necessary
[17:03] <tjaalton> bryce: ok, reading
[17:24] <tjaalton> wow that's a lot to digest :)
[17:27] <tjaalton> I guess it has more information than my tiny brain does
[17:27] <tjaalton> will need to read it through later ->
[17:35] <bryce> hmm, maybe it should be broken down more.  Last thing I want is for it to be info overload, since then no one will read it
[17:51] <superm1> mvo, in watching a lot of the fglrx bug mail fly by, it's looking like r3XX hardware is no longer supported in the fglrx driver for intrepid.  its not explicitly listed in the modaliases, so jockey won't offer it.  people who were on hardy w/ it, will they be transitioned to the open source driver because of the modaliases thing, or do you need to do anything special?
[17:51] <superm1> bryce, do you think this would be worth release noting?
[17:51] <bryce> superm1: yep, although I'd like to get the document into a bit better shape first
[17:53] <mvo> superm1: sorry, I was not aware of this. update-manager does not look at the modaliases for fglrx 
[17:53] <mvo> superm1: we could have done that (and we still can via a SRU) - it was just not on my radar 
[17:53] <superm1> mvo, neither was I.  i've just noticed the pattern
[17:53] <mvo> ok
[17:55] <mvo> superm1: I can work on a fix for it tomorrow, for now I think we should release note it
[17:55] <superm1> mvo, okay thanks
[17:56] <mvo> "If you run on a r300 based chip and use fglrx use jockey to transition to the free driver before you attempt to upgrade." 
[17:56] <mvo> something like this :)
[17:56] <superm1> yeah
[17:56] <mvo> do you want to add it or shall I ? 
[17:56] <superm1> go ahead.  i'll try to triage these bugs since i've seen the pattern
[18:01] <mvo> do you have a master bug for it to refer to?
[18:09] <mvo> https://wiki.ubuntu.com/IntrepidReleaseNotes?action=diff&rev2=103&rev1=102
[18:09] <mvo> ^-- superm1
[18:10] <superm1> mvo, i'll have one after i triage them.  some have intermingled issues listed
[18:10] <superm1> i'll add it to the release notes once i do
[18:15] <mvo> superm1: exellent, thanks a lot
[18:15] <mvo> superm1: when you have a master, please let me know, I check it out tomorrow
[18:22] <superm1> mvo, okay i've got a master and will be adding a few more bugs to it, bug 284408.  i added tasks for update-manager and release notes too.
[18:22] <ubottu> Launchpad bug 284408 in fglrx-installer "r3xx Hardware does not work with fglrx" [Medium,Triaged] https://launchpad.net/bugs/284408
[18:32] <superm1> bryce, would it be a stretch to try to ask AMD to have an engineer get a LP account to triage these bugs that can't be fixed by us?  like bug 286841
[18:32] <ubottu> Launchpad bug 286841 in fglrx-installer "amdcccle crashed with SIGSEGV in _XSend()" [Undecided,New] https://launchpad.net/bugs/286841
[18:33] <bryce> superm1: I tried to get them to interact with LP directly several times, but no go
[18:34] <bryce> superm1: If you give me a list of bug #'s, I can forward them to them.  No guarantee they'll respond.  They've asked for Top 5 lists in the past, so that would probably be the ideal number
[18:36] <superm1> bryce, well before doing that can you try to get them to commit to a yay/nay on fixing it and maybe providing a tracking number from their internal system when yay?
[18:36] <superm1> bryce, that way they'll have it in the release notes of the driver when they do fix it
[18:36] <superm1> and if they say nay, a canned response saying AMD isn't interested can be put in the bug as won't fix
[18:37] <bryce> well, anything's worth a try, but I'm fairly sure they won't go for any of that
[18:39] <superm1> at least i think that would be the least work on their end but still helpful to give a yay/nay rather than dead silence.
[18:42] <bryce> superm1: why 286841 in particular?  It doesn't look like it's been triaged or prioritized?
[18:44] <superm1> bryce, well that was just one i had opened as an example; it's one of their apps crashing, with no useful way for it to be debugged by us
[18:44] <superm1> they'd have to reconstruct the trace with the debug symbols on their end
[18:44] <bryce> mm
[18:45] <mvo> thanks superm1
[18:45] <mvo> bryce: out of curiosity, do they have a internal bugzilla (or something similar?)
[18:46] <bryce> mvo, yep
[18:46] <mvo> but its so internal, that we can not forward directly?
[18:46] <bryce> correct
[18:46] <mvo> oh well
[18:46] <mvo> thanks
[18:46] <superm1> afaik, whenever they enter an internal bug into it, it's called an EPR, and that's the same number that is given in release notes when they get it closed up
[18:47] <bryce> in fact they typically won't even give me the numbers for the internal bugs
[18:57] <bryce> superm1: ok mail sent
[19:35] <bryce> okay, I've broken up the Hotkeys document into a couple sub-pages.  Same quantity of text, but hopefully that makes it less intimidating to look at and edit
[19:35] <bryce> https://wiki.ubuntu.com/Hotkeys
[19:54] <mvo> superm1: silly question, is there a reason why the fglrx-modalises file is called aliases.override ? (but the nvidia ones don't)?
[20:24] <mvo> superm1: do you think we should show a dialog on upgrade asking for confirmation? or just go ahead and replace fglrx with ati (for r300)? given that the r300 are usually well supported by the free driver
[20:48] <superm1> mvo, i was gonna think just replacing it (and removing the xorg-driver-fglrx package of course) since r300 is so well supported by the free driver
[20:49] <superm1> mvo, silly answer is because that's what it was called in the source package and it was easy to install with the same name
[20:50] <mvo> superm1: thanks 
[20:50] <mvo> superm1: I have a patch ready I think (but no HW to test if it really works)
[20:51] <superm1> mvo, well my own personal home laptop is r300 and not upgraded yet...
[20:51] <superm1> so I can test it if you give me some direction how to make sure it would go
[20:52] <mvo> superm1: oh, cool. you will not have to do a full upgrade, just enough so that the detection code kciks in :)
[20:53] <mvo> currently I recycled some strings in http://paste.ubuntu.com/64289/ - but the text is *bad*
[20:54] <superm1> mvo, okay so if I see a string resembling that I know it kicked in
[20:55] <mvo> superm1: ok, pleae download http://people.ubuntu.com/~mvo/test/intrepid-0.93.33.tar.gz and unpack into some tmp directory like /tmp/foo , and run "sudo ./dist-upgrade" from there
[20:56] <mvo> then it should ask you if fglrx should go 
[20:56] <mvo> it will only work when fglrx is actually used in /etc/X11/xorg.conf
[20:57] <superm1> oh it's going to have to wait a few hours until later i realize.  I don't have fglrx currently enabled (r300 support is nice :)) so i'll have to get to it interactively to enable it and test
[20:57] <superm1> i'll get back to you later on with the results
[20:58] <mvo> superm1: ok, its enough if you edit /etc/X11/xorg.conf so that its there, it does not actually check if its running :)
[20:58] <superm1> oh if that's the case, yeah i'll just make the change to xorg.conf and X forward to run the app
[20:59] <mvo> superm1: no rush, I will probably leave soonish for bed anyway and because this is going via a SRU it will take a couple of days until it hits the archive
[20:59] <mvo> but feedback is very nice, thanks a lot for your help with this!
[21:05] <chrisccoulson> bryce, i got your e-mail about the hotkey troubleshooting wiki. i'll have a look at that over the next couple of days
[21:06] <bryce> chrisccoulson: thanks, and if you can work on improving it, it'd help a lot
[21:06] <chrisccoulson> i'll see what i can do. i did a build of gnome-power-manager last night with support for your non-functioning hotkey
[21:07] <bryce> chrisccoulson: after you've had time time to add your thoughts, then I can shop it around to some other folks (e.g. hal and pm-utils) and try to get their contributions
[21:07] <chrisccoulson> i've uploaded it to my PPA if you want to try it out
[21:08] <bryce> ok cool, link me
[21:09] <chrisccoulson> https://edge.launchpad.net/~chrisccoulson/+archive
[21:09] <superm1> mvo, well w/ fglrx in xorg.conf it made it to the stage that it's fetching packages
[21:09] <superm1> mvo, so should  that message have already come up?
[21:17] <mvo> superm1: yes, it should be there before the final confirmation dialog (the one with 2000 packages are going to be upgraded etc)
[21:18] <mvo> superm1: hrm, if it did not appear for you, could you please email me the output of your "lspci -n" ? mvo (at) ubuntu.com
[21:19] <superm1> mvo, sure
[21:49] <seb128_> bryce: what do you expect applications to do when the xserver says there is insuffisant ressources to play a video?
[21:50] <bryce> seb128_: probably behave similarly as if the system was out of disk space or out of RAM
[21:50] <seb128_> bryce: and how much resources are required to play a video nowadays? go tell users than they videocard is not able to play a video
[21:51] <seb128_> bryce: I think they would laugh in our face if the player was displaying "your videocard is not able to play a video"
[21:51] <bryce> seb128_: well what are you suggesting?
[21:51] <seb128_> that seems an xorg issue to me
[21:52] <bryce> seb128_: and as you'll note, I marked it as such, and linked to the upstream bug #
[21:52] <seb128_> you are really saying that modern graphic cards resources are too limited to play a video on some configs?
[21:52] <seb128_> will, I just don't think that's an application issue
[21:52] <seb128_> what is using the video ressources in a standard ubuntu installation?
[21:53] <bryce> seb128_: so you think crashing in this case is an acceptable application behavior?
[21:53] <seb128_> can we ask them to close some softwares? does it depends of what is on screen?
[21:54] <seb128_> no, but I don't think displaying a "you don't have enough resources to play a video" is going to be much better
[21:54] <seb128_> what could the message suggest them to do to solve the issue?
[21:54] <ScottK> "Go buy a better video card"
[21:54] <ScottK> ;-)
[21:56] <bryce> seb128_: well it looks like using compiz + XAA + Totem is a bad combination.  Turning off Compiz, or switching to EXA sounds like it'd solve it
[21:57] <seb128_> they are not using xaa I think, or is that the default?
[21:57] <bryce> at least for -ati.  For the Me-Too'er with -intel, he probably has some other issue
[21:57] <seb128_> ok
[21:57] <bryce> for -ati it is still the default, since there are potential corruption issues still when EXA is used.  I am investigating switching to EXA by default for Jaunty
[21:57] <seb128_> cool
[21:57] <bryce> for -intel, EXA is the default, but some people still use XAA for whatever reason
[21:58] <seb128_> is there any tools which give the resource usage?
[21:58] <seb128_> ie how much is available and what is using what?
[21:58] <bryce> I think so, hang on
[21:59] <bryce> <bryce> heya, I'm wondering if we should look at changing from XAA to EXA in Jaunty.  Do you have some advice there?
[21:59] <bryce>  from bug reporters who have tried EXA with -ati so far there are still some issues, however others report that by switching it solved even worse issues.  But I'd like to get your thoughts.
[21:59] <bryce> <agd5f> yeah, I'd say definitely.
[21:59] <bryce>  we'll probably make EXA the default in the driver once the EXA glyph cache stuff gets into distros
[22:00] <seb128_> good to know
[22:14] <bryce> seb128_: xrestop can be used to display resource usage
[22:15] <seb128_> bryce: thanks
[22:15] <bryce> seb128_:  xrestop -b | grep -A 15 totem  may be of use
[22:16] <bryce> (from the xrestop man page)