[00:15] <superm1> bryce, this bug about keys getting "stuck", like eject, brightness, etc.  has it been accounted towards the kernel or X server, do you know?
[00:16] <bryce> bug id?
[00:16] <superm1> lets see there's been a few.  
[00:16] <superm1> i know bug 273468 is one of them
[00:16] <ubottu> Launchpad bug 273468 in ubuntu "No input after setting brightness on Dell Studio 1535" [Undecided,Confirmed] https://launchpad.net/bugs/273468
[00:17] <superm1> it causes gnome power manager to go crazy 
[00:17] <superm1> because the key is "stuck" 
[00:17] <superm1> and actually i think i just answered my own question; if i run "showkey" in a VT, i'm not seeing keyrelease events
[00:17] <superm1> kernel's fault then
[00:18] <superm1> wgrant, ^ that plays into that mess with gnome-power-manager right now
[00:18] <bryce> yeah sounds like an issue mdz was hot on with thinkpads the past few weeks
[00:19] <superm1> Bug 261721
[00:19] <ubottu> Launchpad bug 261721 in linux "X never sees brightness key release events" [High,Triaged] https://launchpad.net/bugs/261721
[00:19] <superm1> that's sounding like the same thing too
[00:19] <bryce> superm1: and yeah we ended up narrowing it down to being a kernel issue.  you could check with  him to see if the kernel folks made progress on it
[00:19] <bryce> superm1: btw I've still been on that dithering bug
[00:20] <bryce> superm1: I've been testing some patches for alex today to try to make it display correctly with no dithering required
[00:20] <superm1> bryce, I'd say don't put too much more at it at the current moment, the drivers are missing enough features still (read acceleration) that it won't be sufficient to use them for shipping at this time
[00:20] <bryce> unfortunately we've not gotten a confirmed patch yet, so may not be able to get this fixed in intrepid. 
[00:20] <bryce> ok cool
[00:21] <superm1> so you priorities are probably better elsewhere atm
[00:21] <bryce> ironically, the bug is much less noticeable with the new desktop image
[00:21] <bryce> ok thanks for letting me know that.  yeah the bugs have been swarming lately...
[00:23] <superm1> suppose that's what happens when release gets close, more and more people get to testing
[00:40] <bryce> yeah
[00:41] <bryce> it gets to feel a bit like being a schoolteacher, with a zillion people asking about a zillion different things :-)
[00:46] <wgrant> superm1: rtg said he probably wouldn't get to it for a few weeks :(
[06:14] <superm1> wgrant, well that's not good.
[06:14] <superm1> wgrant, that means intrepid goes out the door broke with this..
[06:14] <superm1> and god knows if something is wrong with gpm's changes too that amplifies it
[06:14] <superm1> wgrant, do you by chance have a hardy kernel handy that you can try still?
[06:14] <superm1> to make sure the rest of the stack is in order
[06:27] <wgrant> superm1: I don't, no. But I'll have time to debug in about 24 hours.
[06:27] <wgrant> I need to work out how to convince g-p-m not to use XRandR to adjust brightness on this hardware.
[06:28] <superm1> i'm still at a loss why it's using xrandr to do such things
[06:28] <wgrant> I really don't want to see Intrepid broken like this, but I've lacked time over the past couple of weeks.
[06:28] <superm1> or at least trying to
[06:28] <wgrant> XRandR support brightness setting on lots of hardware.
[06:28] <wgrant> My hardware appears to report that it's capable, so X tells g-p-m that it can do it.
[06:28] <wgrant> g-p-m's code quite deliberately prefers XRandR over HAL for this.
[06:28] <superm1> are there any hal settings that can be overridden?
[06:29] <superm1> to change the behavior
[06:29] <superm1> because pretty much any Dell will be affected
[06:29] <wgrant> No, it's hardcoded in g-p-m that it will use XRandR if availab.e
[06:29] <superm1> the keys themselves will always emit either ACPI or SMI events
[06:29] <wgrant> If I reverse that check, it uses HAL and things work much better.
[06:30] <wgrant> This issue is not the key one.
[06:30] <superm1> what's the consequence of reversing the check?
[06:30] <wgrant> It will prefer HAL brightness mechanisms over XRandR ones.
[06:30] <superm1> yeah, so is that really a bad thing?
[06:30] <wgrant> The correct fix it to prevent XRandR from lieing about is abilities.
[06:30] <wgrant> I don't know if it will break on other laptops.
[06:31] <superm1> well in the event a time sensitive fix isn't found, you can just add a patch to check for dell
[06:31] <superm1> and if dell hardware, switch
[06:31] <superm1> if not then follow the normal code path
[06:32] <wgrant> I plan to poke in the X driver code over the weekend.
[07:54] <elmargol> tjaalton: ping
[08:54] <crevette> hello gents
[08:56] <crevette> I have a flat screen for few days, and I wanted to give a try to hot plugging functionality, how I am supposed to be able to  detect it and use it ?
[08:56] <crevette> I can see something wen I run xrander
[08:56] <crevette> and I see it also when I run the xrander GNOME applet
[08:57] <crevette> pressing the switch screen button on my laptop doesn't do anything 
[08:57] <wgrant> crevette: Select the screen, select a resolution, position it, click Apply?
[08:58] <crevette> I pressed apply already but nothing changed
[08:58] <crevette> It is true that I didn't moved it
[08:59] <crevette> I just moved it a few mm and pressing apply make a dialog on my laptop
[08:59] <crevette> I'm checking it
[08:59] <crevette> so it is necessary to mive a few the screen to make it works?
[08:59] <crevette> is it a bug?
[09:00] <crevette> s/mive/move/
[09:00] <crevette> I need to log out and in
[09:02] <crevette> it's kind of work
[09:02] <crevette> the resolution at GDM on my laptop is blurry
[09:03] <crevette> once logged in my sesssion I have the native resolution on my laptop but not on the screen
[09:03] <crevette> however I can see the panel on my laptop :)
[09:03] <crevette> can't
[09:04] <wgrant> crevette: Graphics card model?
[09:05]  * crevette doesn't like to be so negative :)
[09:05] <crevette> laptop: T61 with intel
[09:05] <crevette> screen samsung SyncMaster 206 BW
[09:05] <crevette> connection through VGA
[09:06] <crevette> humm xrander doesn't use the best resolution he can on my screen
[09:07] <wgrant> Set it manually in gnome-display-properties, then?
[09:07] <crevette> yep I was search the name of this capplet :)
[09:07] <crevette> searching
[09:08] <crevette> I'm sure this resolution wasn't proposed first time I used it, just before I logged out
[09:09] <crevette> okay trying again
[09:09] <crevette> see you
[09:09] <crevette> thanks
[09:09] <wgrant> You shouldn't need to restart...
[09:14] <crevette> okay so I can see my mouse pointer on the screen, but no application can be moved over there
[09:15] <crevette> and the resolution seems to be not the one I chose 
[09:15] <crevette> how could I provide an useful bug report for that?
[09:15] <elmargol> is there no way to disable powermixer from the nvidia driver?
[09:15] <elmargol> This anoying powersaving feature freezes my system
[09:16] <crevette> should I open it against ubuntu  or you'd prefer elsewhere
[09:17] <crevette> desactivating the other screen works fine without having to log out 
[09:18] <crevette> bug gnome-display-properties crashed
[09:18] <crevette> :/
[10:07] <mvo> tseliot: could you please have a look at #283905 ?
[10:08] <tseliot> mvo: sure
[10:11] <tseliot> mvo: it's a duplicate of https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/261816
[10:11] <ubottu> Launchpad bug 261816 in linux-restricted-modules-envy-2.6.24 "nvidia: Multiple versions in DKMS" [Medium,In progress] 
[10:11] <tjaalton> elmargol: yes?
[10:12] <elmargol> oh wrong nick sorry
[10:13] <tjaalton> elmargol: np
[10:13] <tseliot> mvo: don't worry, this won't affect dist-upgrades to Intrepid
[10:14] <elmargol> looks like nvidia at 100mhz is to slow for kwin :/
[10:15] <elmargol> Alt Tab has about 10 fps
[10:16] <elmargol> Somehow the nvidia powermixer crashes my system. I have limited nv clock and memory clock to 100 mhz now
[10:16] <elmargol> Maybe this fixes my issues. tseliot if this works i add a comment to the open bugreport
[10:17] <tseliot> elmargol: ok, thanks
[10:17] <elmargol> It is sad that there is no way to disable powermixer
[10:17] <elmargol> I googled about an hour today and there are a lot requests for this
[10:18] <elmargol> by default the linux nvidia drivers runs at the maximum performance mode
[10:19] <elmargol> If you have are running at battery the mhz is limited to medium. if you run on AC there is no limit
[10:20] <elmargol> there seems to be no way to control the fan
[10:20] <elmargol> my GPU runs between 50 and 65°C
[10:21] <elmargol> The fan starts at 66°C
[10:21] <mvo> tseliot: thanks
[10:21] <tseliot> mvo: I'll backport the fix to Hardy
[11:08] <mvo> I want to add a safeguard in InputSection removal in update-manager, should I test for xserver-xorg-core >= 1.5 or is there a better way?
[11:23] <tseliot> mvo: yes, I guess that would be a good way to test it.xserver-xorg-core is epoch'd -> 2:1.5
[11:24] <mvo> tseliot: thanks, will add it
[12:28] <james_w> bug 284042: it sounds like we want this to go, should there be a transition for users?
[12:28] <ubottu> Launchpad bug 284042 in xserver-xorg-video-unichrome "archive removal request: xserver-xorg-video-unichrome is uninstallable." [Undecided,New] https://launchpad.net/bugs/284042
[13:45] <tseliot> james_w, mvo: about bug 284042, maybe we could migrate users from "via" to "vesa"?
[13:45] <ubottu> Launchpad bug 284042 in xserver-xorg-video-unichrome "archive removal request: xserver-xorg-video-unichrome is uninstallable." [Undecided,New] https://launchpad.net/bugs/284042
[13:48] <jcristau> tseliot: openchrome seems more appropriate
[13:50] <tseliot> jcristau: does it support all the graphics cards supported by unichrome?
[13:50] <mvo> jcristau: does unicrome and opencrom cover the same cards? if so, we could solve it in the package with a symlink
[13:50] <jcristau> tseliot: hopefully...
[13:50] <tjaalton> openchrome supports more
[13:50] <jcristau> mvo: symlink is not enough
[13:51] <mvo> jcristau: what else is needed (sorry for my ignorance)
[13:51] <mvo> ?
[13:53] <jcristau> when it loads module foo, the server looks for the fooModuleData symbol
[13:53] <tseliot> ok then we can make "via" a transitional package and replace "via" with "openchrome" (or whatever it is) in the xorg.conf
[13:53] <jcristau> tseliot: i'm doing the latter already
[13:54] <tseliot> jcristau: how?
[13:54] <jcristau> (and even adding this symbol is not always enough, for some reason. it fails for i810/intel)
[13:54] <jcristau> tseliot: xserver-xorg.postinst
[13:55] <tseliot> ok, let me have a look at the source
[13:57] <jcristau> http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=blob;f=debian/xserver-xorg.postinst.in;h=629291e210c0bffbf4bc3dffab8bcf0c446804a5;hb=refs/heads/debian-experimental#l955
[13:57] <tseliot> jcristau: what happens if "Device" is written in lowercase?
[13:57] <jcristau> tseliot: you lose. don't do that. :)
[13:58] <tjaalton> is it even valid?
[13:58] <tseliot> jcristau: I don't but yes, it's valid
[13:58] <tseliot> and I've seen a lot of xorg.conf files like that
[13:58] <jcristau> really?
[13:58] <tseliot> yes, unfortunately
[13:59] <jcristau> i'm mostly interested in handling upgrades for the configs written by dexconf though..
[13:59] <tseliot> mvo: I guess we can do it with X-Kit and we already do with nvidia
[13:59] <jcristau> tseliot: x-kit is Required?
[14:00] <tseliot> jcristau: I'm not blaming it on you. It's just that we have to deal with a lot of different xorg.conf files
[14:00] <tseliot> what do you mean by Required?
[14:00] <tseliot> installed by default?
[14:00] <jcristau> installed everywhere
[14:00] <tseliot> yes, in Ubuntu Intrepid
[14:01] <tseliot> it doesn't depend on anything else other than python
[14:01] <tjaalton> no x-kit here :)
[14:01] <tseliot> tjaalton: python-xkit
[14:01] <jcristau> i don't see why you'd do it there instead of in xserver-xorg, but meh
[14:01] <tjaalton> Priority: optional
[14:02] <tjaalton> tseliot: lool already merged xorg, so we have the same logic in the postinst
[14:02] <jcristau> tjaalton: i didn't mean required in a litteral sense. just depended on by x..
[14:02] <tjaalton> jcristau: ah, ok
[14:03] <tseliot> jcristau: ah, then no, X doesn't depend on it
[14:03] <tjaalton> jockey-common seems to depend on it, not x
[14:04] <tseliot> tjaalton: right
[14:06] <jcristau> ok, so x-kit has no business modifying xorg.conf automatically on upgrades. good. :)
[14:07] <tseliot> no, of course not ;)
[14:10] <tseliot> jcristau: we're using x-kit in Update Manager to migrate some users from "nvidia" to "nv" when the proprietary driver is not compatible with xorg, etc.
[14:10] <jcristau> ok
[14:10] <tjaalton> btw, it's surprisingly common for people to not have -input-all installed (and possibly no evdev), so I think the server should depend on evdev now with input-hotplug
[14:11] <tjaalton> or would xserver-xorg Depends: -input-all | -evdev | -ABI do?
[14:13] <tseliot> jcristau: about lowercase words in the postinst, is it to late to do something like this? "[dD]evice"
[14:13] <tseliot> instead of "Device", I mean
[14:14] <jcristau> bah. i guess i can't do case-insensitive match in sed...
[14:15] <tseliot> jcristau: try this: echo device | sed 's/[dD]/T/'
[14:15] <tseliot> it works
[14:16] <jcristau> yes. but, you still don't match "DeViCe" :)
[14:16] <jcristau> anyway i guess Device/device would be good enough
[14:16] <jcristau> should i do the same for Driver?
[14:16] <tseliot> yes
[14:16] <jcristau> 'Section'?
[14:16] <tseliot> yep
[14:17] <jcristau> ok, thanks
[14:18] <tseliot> jcristau: I know this is ugly but try this: echo deViCe | sed 's/[dD][eE][vV][iI][cC][eE]/Device/'
[14:18] <jcristau> yeah. i don't want to do that :)
[14:18] <tseliot> (just for fun)
[14:18] <tseliot> :-P
[14:23] <tseliot> tjaalton, jcristau: jokes aside now, are you going to make xserver-xorg-video-unichrome a transitional package?
[14:24] <jcristau> i've never shipped -unichrome, so no
[14:25] <tjaalton> it should be just dropped
[14:25] <jcristau> about via, i'm not sure
[14:26] <tseliot> tjaalton: ah, right, openchrome is installed by default
[14:27] <jcristau> hopefully the package manager will get -all installed if you only had -via or -unichrome, but...
[14:28] <tseliot> ok
[14:28] <jcristau> has anyone done some upgrade testing for this?
[14:30] <tjaalton> not me
[14:32] <tseliot> maybe mvo? ^^
[14:51] <jcristau> tjaalton: evdev in master shouldn't crash with joysticks anymore, you'll want to cherry-pick 7243116f
[14:52] <tjaalton> jcristau: thanks
[14:53] <jcristau> (it's the patch i suggested yesterday ;) )
[14:54] <mvo> via and -openchrome>  why not add a transitional package to be certain that people get the right driver?
[14:55] <jcristau> mvo: sounds reasonable to me
[14:56] <mvo> excellent
[19:19] <bryce> wgrant: do you know what the deal is with bug 281308?  It almost sounds like it may be a user issue rather than a real bug, but it's unclear.  Ideas?
[19:19] <ubottu> Launchpad bug 281308 in xorg "xserver-xorg-input being removed on upgrade" [High,Confirmed] https://launchpad.net/bugs/281308
[20:14] <tseliot> bryce, mvo: FYI I have attached Aaron's patch for Compiz: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/269904
[20:14] <ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-177 "Screen refresh problems with nvidia on intrepid" [Medium,Confirmed] 
[20:16] <bryce> tseliot: okay thanks, I'll review it
[20:17] <bryce> hmm
[20:17] <tseliot> ok
[20:20] <bryce> there's a realloc and some changes from single val to arrays, both of which raise some risk of memory errors
[20:20] <bryce> I'll comment on the bug
[20:33] <tseliot> ok, great
[20:34] <bryce> I think this one will need to be mvo's call
[20:34] <tseliot> bryce: BTW do you know where I can find the prototypes of the functions of randr?
[20:34] <bryce> yeah
[20:35] <tseliot> e.g. GetCrtcInfo()
[20:35] <jcristau> tseliot: <X11/extensions/Xrandr.h>
[20:35] <bryce> package should be libxrandr-dev
[20:36] <tseliot> ok, thanks
[21:06] <wgrant> bryce: I'm not sure I know of all of the issue - there might be other circumstances in which it happens than the one I caused.
[21:07] <bryce> wgrant: ideas on what we could do to resolve it?  anything I could do to help?
[21:08] <wgrant> bryce: The main issue is that users are stupid.
[21:08] <wgrant> We just don't stop them from letting apt-get remove half of their system, and I don't think we should.
[21:09] <wgrant> I believe that the main issue was a few hours a week ago during the XInput property transition where apt-get would have wanted to remove most of GNOME, evdev, and synaptics, but there might be other cases
[21:11] <bryce> wgrant: yeah that's how it sounded to me too
[21:12] <bryce> wgrant: okay I'm going to drop it as a release-critical bug.  
[21:13] <wgrant> We maybe could make the dist-upgrader make sure that at least evdev is installed.
[21:14] <bryce> possibly yeah
[21:14] <bryce> ideally, I'd like to see someone reproduce the issue from scratch in a plain vanilla hardy->intrepid upgrade
[21:15] <wgrant> It's not possible.
[21:15] <wgrant> Well, unless they have some strange packages.
[21:15] <wgrant> The whole stack is installable now, so it won't try to remove things.
[21:15] <wgrant> The only Hardy->Intrepid upgrades it hit were during that 3 hours + mirror lag, AFAICT.
[21:17] <milli> bryce: I'm told to come here and ask you about rolling to ver 1.2.3 of xserver-xorg-video-radeonhd at this point.
[21:17] <milli> for 3D support (XVideo, yeah!) on recent ATI chipsets
[21:17] <jcristau> milli: use radeon
[21:18] <milli> jcristau: no worky on R500 / R600 based chipsets
[21:18] <milli> e.g. M56 (what I have)
[21:18] <jcristau> milli: that's not true
[21:18] <milli> a.k.a. X1400
[21:18] <milli> really?
[21:19] <milli> when did that change?
[21:19] <jcristau> 6.9 iirc
[21:19] <jcristau> wgrant: we got reports of aptitude removing most of X on upgrades from etch to lenny, although stuff is installable, i have no idea why.  apt-get does better...
[21:19] <wgrant> jcristau: How odd.
[21:20]  * milli stands corrected
[21:22] <superm1> bryce, it appears to work correctly without that library.  it's gonna take some nasty packaging hacks to make it build right though
[21:22] <superm1> i'll fsck with it a bit 
[21:52] <bryce> wgrant: thanks again.  release task on 281308 is closed
[21:53] <wgrant> bryce: Great! I should probably sort out my RC bugs soon.
[21:54] <bryce> yep
[21:55] <wgrant> First time I've had any.
[21:56] <bryce> cjwatson says if we don't think we'll be able to get to the task by intrepid, that we should drop the release task.  to do that, mark it wontfix, and that will reopen the main task
[21:57] <wgrant> The one that I have right now is quite doable (I have a patch, and I think it makes the logic more correct). And I think I was one of the few who knew about that LP task quirk.
[21:57] <wgrant> It really could be documented better.
[22:44] <bryce> wgrant: yep
[22:54] <wgrant> superm1: Seen Redhat bug #444440?
[22:54] <ubottu> Error: Launchpad bug 444440 could not be found
[22:54] <wgrant> Fedora bug #444440
[22:54] <ubottu> Error: Launchpad bug 444440 could not be found
[22:54] <wgrant> Stupid ubottu.
[22:55] <wgrant> Als, LP bug #271706.
[22:55] <ubottu> Launchpad bug 271706 in linux "Volume control wheel on laptop is sticking in ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/271706