| ScottK-laptop | bryce: Is the guidance in https://help.ubuntu.com/community/DebuggingXAutoconfiguration still correct for Intrepid? | 14:10 |
|---|---|---|
| bryce | ScottK-laptop: nope that's all obsolete now | 15:16 |
| ScottK-laptop | bryce: Thanks. I'd appreciate any advice you have onBug 290156 then. | 17:22 |
| ScottK-laptop | It appears that X is getting no display information back and so it sets some parameter beyond what the monitor can take. | 17:23 |
| bryce | ScottK-laptop: for reference, the X troubleshooting page is at wiki.ubuntu.com/X/Troubleshooting | 17:24 |
| bryce | can you post your Xorg.0.log? | 17:24 |
| ScottK-laptop | Yeah. | 17:25 |
| bryce | Xorg.0.log.old as well | 17:25 |
| bryce | (basically we need a log that matches the failed startup) | 17:25 |
| ScottK2 | Both attached to the bug. | 17:28 |
| bryce | hmm | 17:29 |
| ScottK2 | I suspect .old is not the failure | 17:29 |
| bryce | yeah me too | 17:29 |
| ScottK2 | I need to swtch monitors and reboot. | 17:29 |
| bryce | can you reproduce the failure and then collect the Xorg.0.log from it? | 17:29 |
| ScottK2 | Yeah. | 17:29 |
| ScottK2 | It'll be a little bit though. | 17:30 |
| bryce | It'll tell us where it's getting hung up | 17:30 |
| bryce | no prob | 17:30 |
| ScottK2 | I'll ping you when I've got it. | 17:30 |
| bryce | great | 17:30 |
| ScottK2 | Thanks | 17:30 |
| bryce | also, I've updated the help.ubuntu.com page | 17:30 |
| ScottK-laptop | I think there's just barely enough time for it to finish booting and for me to slam the log into the bug. | 17:50 |
| ScottK-laptop | Then I've got to run out. | 17:50 |
| ScottK-laptop | bryce: Bug updated. Back later. | 17:53 |
| ScottK-laptop | bryce: I added get-edid | parse-edid output to the bug. | 19:54 |
| bryce | ScottK-laptop: ok | 19:55 |
| ScottK-laptop | bryce: How am I supposed to run the xrandr tool if I'm in the box via SSH and not in an X session? | 19:55 |
| bryce | did the xrandr stuff work? | 19:55 |
| ScottK-laptop | No | 19:55 |
| tormod | xrandr -d :0 | 19:56 |
| ScottK-laptop | Can't open display | 19:56 |
| ScottK-laptop | OK | 19:56 |
| ScottK-laptop | No protocol specified | 19:56 |
| ScottK-laptop | Can't open display :0 | 19:56 |
| ScottK-laptop | If I do it via vt1, will it work? | 19:56 |
| bryce | ScottK-laptop: you might try putting xhost + into your .xprofile | 19:57 |
| bryce | and set /etc/gdm/gdm.conf to do timed or automatic login | 19:57 |
| ScottK-laptop | This is kdm, so I don't think I have that. | 19:58 |
| bryce | presumably kdm has the equivalent | 19:59 |
| tormod | it's funny though, xrandr -d :0 on vt1 only reports if --verbose is added | 19:59 |
| tormod | oh forget it, I just realized xrandr does not do -q by default any longer... | 20:00 |
| bryce | ScottK-laptop: in any case, I can upstream this now, so will go ahead and do that | 20:03 |
| ScottK-laptop | bryce: Great. Here's hoping for an SRU .... | 20:04 |
| bryce | ScottK-laptop: looks like your monitor's EDID only advertises a single resolution | 20:04 |
| ScottK-laptop | bryce: OK. | 20:05 |
| bryce | ScottK-laptop: I'll let you shepherd an SRU through if you want | 20:05 |
| jcristau | xhost + in .xprofile? seriously? | 20:05 |
| ScottK-laptop | bryce: You give me a patch and I'll do that. | 20:05 |
| bryce | jcristau: unless you have a better way | 20:06 |
| tormod | jcristau: I am sure it's for debugging on a non-networked computer :) | 20:06 |
| jcristau | oh. for debugging. ok :) | 20:06 |
| jcristau | but, setting DISPLAY is simpler... | 20:06 |
| bryce | jcristau: yeah just to get it up once | 20:06 |
| bryce | jcristau: doesn't "-d :0" do the same thing? | 20:07 |
| jcristau | yeah it's the same | 20:07 |
| bryce | I think it's the xauth stuff preventing him from getting in | 20:07 |
| ScottK-laptop | bryce: Any idea why this would be a regression from Hardy? It seems pretty basic. | 20:08 |
| bryce | I guess an alternate would be to run X directly, without using xauth. | 20:08 |
| bryce | ScottK-laptop: nope no idea | 20:08 |
| bryce | ScottK-laptop: I'd guess it to be something special about your monitor | 20:08 |
| ScottK-laptop | bryce: I'm up for simple. It's been long enough I had to mess with this stuff I've forgotten completely about it or it changed. | 20:08 |
| ScottK-laptop | Yeah, well Hitachi is not precisely an obscure brand. | 20:09 |
| ScottK-laptop | bryce: Still get 'Can't open display' with xhost + in .xprofile | 20:16 |
| ScottK-laptop | bryce: What was your other suggestion? | 20:16 |
| bryce | you need to bypass the login screen before the .xprofile stuff comes into play | 20:16 |
| ScottK-laptop | Oh. | 20:16 |
| bryce | so however this is done on kdm, make it so | 20:16 |
| ScottK-laptop | Switch to a vt, login, kill kdm? | 20:17 |
| jcristau | for debugging, just run X, without a dm | 20:20 |
| ScottK-laptop | I tried startx and it went straight to "Display out of range" again | 20:22 |
| ScottK-laptop | I'll work on this more later I guess. | 20:23 |
| chrisccoulson | ping bryce | 21:01 |
| bryce | chrisccoulson: you can ask the question rather than pinging. ;-) | 21:05 |
| chrisccoulson | no problem:) | 21:06 |
| bryce | ScottK-laptop: I've forwarded your issue upstream here: https://bugs.freedesktop.org/show_bug.cgi?id=18276 | 21:06 |
| ubottu | Freedesktop bug 18276 in Server/general "Server picks 2048x1536 for monitor only supporting up to 1600x1200" [Major,New] | 21:06 |
| chrisccoulson | i could use your help with a laptop hotkey related bug report. bug 278839 | 21:06 |
| ubottu | Launchpad bug 278839 in linux "Hotkeys stopped functioning - Dell Inspiron 1420" [Medium,Confirmed] https://launchpad.net/bugs/278839 | 21:06 |
| chrisccoulson | i think there might be more than 1 problem | 21:06 |
| chrisccoulson | for the sleep key, a keypress gets through to the X server, but I don't think it is the right one | 21:07 |
| chrisccoulson | and I'm not really sure which package to assign it too | 21:07 |
| bryce | ok, it's likely not linux, but likely not xorg either | 21:11 |
| bryce | let me finish reading it | 21:11 |
| bryce | (I'm on a 1420 myself at the moment) | 21:11 |
| chrisccoulson | thats good! you might be better placed to work out what is going on:) | 21:11 |
| bryce | not really ;-) | 21:13 |
| bryce | but I've seen another bug report about the multiple key presses | 21:13 |
| bryce | if you search on Inspiron 1420 you should find it | 21:13 |
| chrisccoulson | i saw something else about that after googling too, but i wasn't sure whether it would be related | 21:13 |
| chrisccoulson | certainly for the sleep key, GPM doesn't grab XF86Standby. It grabs XF86Sleep | 21:15 |
| bryce | we definitely need a hotkey-debugging guidebook in wiki | 21:16 |
| bryce | I started drawing one up for X since we get a lot of questions about hotkey issues, however in truth these are very rarely X issues; usually it's something between the kernel and X, like gnome-power-manager, acpid, hotkey-support, hal, etc. | 21:17 |
| wgrant | No - we definitely need to go back to TTYs! They make everything so much easier to debug. | 21:17 |
| bryce | heh | 21:17 |
| bryce | chrisccoulson: fwiw, I've seen on *some* systems gpm does handle the hotkeys, whereas on others, it's handled at the hardware layer | 21:18 |
| bryce | in some cases it's scripts in hotkey-support, although those are getting phased out | 21:18 |
| bryce | gods acpi is a mess | 21:18 |
| chrisccoulson | yeah, i find it all a little confusing | 21:21 |
| chrisccoulson | it might be worth asking the reporter to provide some data from hardy, to do a comparison? | 21:23 |
| bryce | see also #269951 | 21:23 |
| chrisccoulson | the eject key could be a configuration issue, as that is configurable through gnome-settings-daemon | 21:24 |
| chrisccoulson | bug 269951 | 21:24 |
| ubottu | Launchpad bug 269951 in acpi-support "Fn+F1 (XF86Standby) on Inspiron 1420 does not trigger hibernate or sleep" [Undecided,Confirmed] https://launchpad.net/bugs/269951 | 21:24 |
| chrisccoulson | looks similar | 21:25 |
| bryce | chrisccoulson: here we go, here's the bug I was thinkiing about - #264947 | 21:25 |
| chrisccoulson | bug 264947 | 21:25 |
| ubottu | Launchpad bug 264947 in hotkey-setup "fn buttons dim and brighten screen to fast" [Undecided,Confirmed] https://launchpad.net/bugs/264947 | 21:25 |
| bryce | hmm, it's a bit different though | 21:27 |
| chrisccoulson | it is a little | 21:27 |
| chrisccoulson | i think i'm getting slightly confused between kernel keycodes and xkeycodes | 21:27 |
| chrisccoulson | they aren't the same are they? | 21:27 |
| bryce | chrisccoulson: nope | 21:28 |
| bryce | chrisccoulson: I took a stab at trying to describe how all that works - see wiki.ubuntu.com/X/Troubleshooting and look at the 'keyboard doesn't work' section | 21:29 |
| chrisccoulson | thanks, i'll have a look at that | 21:29 |
| chrisccoulson | so, what happens when you press FN+F1 on your laptop? i take it that it still doesn't work? | 21:30 |
| bryce | chrisccoulson: looking at this bug, you seem to have a good view of the steps to debug hotkeys - would you be interested in working with me to make an Intrepid hotkey troubleshooting document? | 21:30 |
| chrisccoulson | yeah, i don't mind doing that | 21:31 |
| bryce | one sec let me test; I think I ended up getting it working | 21:31 |
| chrisccoulson | i'd be interested to see what xkeysym you get when you press FN+F1 | 21:31 |
| bryce | hmm, nope not working at the moment | 21:31 |
| chrisccoulson | and you still see XF86Standby in xev? | 21:32 |
| bryce | KeyRelease event, serial 33, synthetic NO, window 0x3000001, | 21:33 |
| bryce | root 0x7b, subw 0x0, time 536695250, (1248,270), root:(1253,343), | 21:33 |
| bryce | state 0x0, keycode 213 (keysym 0x1008ff10, XF86Standby), same_screen YES, | 21:33 |
| bryce | XLookupString gives 0 bytes: | 21:33 |
| bryce | XFilterEvent returns: False | 21:33 |
| bryce | yep | 21:33 |
| chrisccoulson | i think that is part of the problem. i've had a look through the source for GPM, and it doesn't even try to grab that key | 21:33 |
| chrisccoulson | it grabs XF86Sleep instead | 21:33 |
| bryce | ahh | 21:33 |
| bryce | yeah that could be | 21:34 |
| chrisccoulson | so, i wasn't sure whether GPM shold try to grab XF86Standby, or whether the Xerver should pass XF86Sleep | 21:34 |
| bryce | there's been 2-3 hotkey issues I've looked into recently that boiled down to bad logic in GPM's key handling | 21:35 |
| chrisccoulson | that might be part of the problem then! | 21:35 |
| bryce | when I looked into the code more, I found that the whole section was fairly recently rewritten majorly, and I think a lot of corner cases were ignored | 21:35 |
| chrisccoulson | so it might be a case of GPM needs to look at more keys | 21:36 |
| bryce | I get really suspicious of GPM when you turn it off and the problem goes away | 21:36 |
| chrisccoulson | yeah, that's not good ;) | 21:36 |
| chrisccoulson | the reporters other non-functioning keys might be unrelated. The FN+F3 combination actually produces a null xkeysym for some reason | 21:36 |
| chrisccoulson | i don't know if that is an Xserver issue | 21:37 |
| superm1 | XF86Standby is supposed to represent S3, and XF86Sleep represents S4 I thought | 21:50 |
| superm1 | so GPM should really be listening for both | 21:50 |
| superm1 | but doing the right thing on each | 21:50 |
| superm1 | FN-F1 generally is generally used for S3, so XF86Sleep seems to be right | 21:51 |
| chrisccoulson | hi superm1. i'm starting to think that GPM should be listening to both | 21:58 |
| chrisccoulson | it seems keys are commented out in the GPM source, and there is a comment saying that XF86Sleep "should be configurable" - but I've no idea where | 21:58 |
| chrisccoulson | i'm just wondering whether to propose a patch to make GPM grab XF86Standby | 21:59 |
| superm1 | there is a document that refers to this on hal's freedesktop website i think | 21:59 |
| superm1 | let me see if i can find it | 22:00 |
| chrisccoulson | thanks. if i proposed a patch to GPM, i could map the key either hibernate or sleep, which correspond to S3 and S4 I think don't they? | 22:01 |
| superm1 | yeah they do | 22:03 |
| superm1 | well my bookmark for that document isn't valid anymore and it's not in my awesome bar anymore either. so looking in /usr/share/hal/fdi/information/10freedesktop a little bit, anything that keys the raw code to "sleep" is putting out a "suspend" which means S3 or suspend to ram. anything putting out the raw code to "suspend" is representing S4, or suspend to disk/hibernate | 22:04 |
| chrisccoulson | there is already a callback in GPM for handling the hibernate key, but it seems that it is never called | 22:04 |
| superm1 | so really its up to what the FN-F1 key should really be doing. | 22:05 |
| superm1 | according to the hal fdi file, it should make the machine hibernate | 22:05 |
| chrisccoulson | that make sense. i think that the FN+F1 combination should be hibernate from the bug reports i've seen | 22:05 |
| superm1 | in the past it's done suspend though, which was probably the wrong behavior then | 22:05 |
| jcristau | people still use anything other than suspend? | 22:06 |
| superm1 | i personally never hibernate. it takes way too long to resume | 22:06 |
| chrisccoulson | not me! neither suspend or hibernate work on my desktop;) | 22:06 |
| chrisccoulson | and they haven't done for a long time! | 22:06 |
| superm1 | so the other problem here then is that gnome power manager only has one drop down option | 22:07 |
| superm1 | for "when the suspend button is pressed" | 22:07 |
| superm1 | is that keying off of the keycode FN-F1 is putting out then? | 22:07 |
| chrisccoulson | well, it's not doing anything off the keycode that FN+F1 puts out at the moment, because it doesn't grab it | 22:08 |
| chrisccoulson | i don't have a laptop, but I assume that most models generally only have one sleep key? in the case of the dell 1420, it is FN+F1? | 22:09 |
| chrisccoulson | if that is the case, then it should probably be configured to sleep rather than hibernate shouldn't it? | 22:09 |
| superm1 | well all dell laptops only have one key | 22:12 |
| superm1 | lenovos have two keys | 22:12 |
| superm1 | you can look at the fdi files to see the rest and how many keys they've got | 22:12 |
| chrisccoulson | i'll do that | 22:12 |
| superm1 | i personally think that gpm should be reading off both keys and provide two settings | 22:13 |
| jcristau | my dell laptop has 2 keys :) | 22:13 |
| jcristau | fn+esc and fn+f1 | 22:13 |
| superm1 | oh that's right fn-esc | 22:14 |
| superm1 | consumer laptops don't advertise that key generally | 22:14 |
| jcristau | fn+esc is what i use for suspend | 22:14 |
| chrisccoulson | what xkeysym does FN+ESC produce? | 22:14 |
| superm1 | XF86Sleep | 22:16 |
| chrisccoulson | that makes sense. and that is the key that GPM grabs. | 22:18 |
| superm1 | but the argument here is that GPM should be grabbing both | 22:19 |
| chrisccoulson | i agree. i'll have a chat with tedg tomorrow when i'm less tired | 22:20 |
| chrisccoulson | in the meantime, i'll upload a patched GPM to my PPA which grabs XF86Standby | 22:21 |
| ScottK-laptop | bryce: Subscribed. | 22:49 |
| ScottK-laptop | bryce: If I use the xrandr tool with the working monitor and switch monitors will the setting stick? | 22:49 |
| bryce | xrandr cmdline changes don't stick, but Screen Resolution changes do | 22:50 |
| bryce | oh wait, kde, dah | 22:50 |
| bryce | hrmmm | 22:50 |
| bryce | okay, I don't know kde well enough, but on gnome, the screen resolution tool and gnome-settings-daemon maintain per-user xrandr settings in a file that is invoked on X startup, to keep the changes persistently | 22:51 |
| bryce | I know that KDE has a new xrandr-based GUI screen tool, but don't know anything about how it works. I assume it has some other means of persisting its settings. | 22:51 |
| bryce | worst case, you can place your good xrandr command line string into your .xprofile and that should have basically the same effect | 22:52 |
| ScottK | OK. I'll try something like that. $MIDDLE_CHILD is using said box for homework with the good LCD currently. | 23:01 |
| wgrant | bryce: What do you think about SRUing a fix for bug #280148? | 23:06 |
| ubottu | Launchpad bug 280148 in gnome-settings-daemon "After resume, ALPS touchpad fully functional, but with wrong settings" [Low,In progress] https://launchpad.net/bugs/280148 | 23:06 |
| wgrant | (I have a fix in my PPA) | 23:06 |
| wgrant | And it affects removable mice. | 23:06 |
| wgrant | It's unfortunately a non-trivial diff, but it annoys people... | 23:07 |
| wgrant | Especially left-handers. | 23:07 |
| bryce | wgrant: depends on the patch | 23:09 |
| bryce | wgrant: non-trivial diffs often won't be allowed unless the issue is particularly serious. if it's just an annoyance, that may not be important enough | 23:10 |
| bryce | wgrant: of course if you want to give it a shot, the worst that can happen is it gets denied ;-) | 23:10 |
| wgrant | I'm aware, but it breaks gnome-mouse-properties completely if you hotplug input devices. | 23:11 |
| bryce | wgrant: do you know how to file SRU's? | 23:11 |
| wgrant | I do. | 23:11 |
| wgrant | I've never done a main one before, but I've done far too many for universe. | 23:11 |
| wgrant | And they're similar. | 23:11 |
| bryce | yep | 23:11 |
| ScottK | wgrant: Is it a regression from Hardy? | 23:11 |
| wgrant | http://launchpadlibrarian.net/18883376/gnome-settings-daemon_2.24.0-0ubuntu2_2.24.0-0ubuntu4~wgrant1.diff.gz is the almost-diff. Soyuz is braindead, so that also includes changes from the last primary upload. It basically factors out the actual mouse configuration bits, and calls them in the old callsite, as well as on addition of new input devices. | 23:12 |
| wgrant | ScottK: Yes. | 23:12 |
| wgrant | input-hotplug broke it. | 23:13 |
| bryce | if it can be described as a 'severe regression', or if the patch can be made 'trivial', it may stand a chance of getting accepted by the release team | 23:13 |
| wgrant | As the X devices now disappear and reappear when the actual device does. | 23:13 |
| ScottK | Well regression is a keyword that helps getting it in. | 23:13 |
| wgrant | The patch can't be made trivial - it needs to hook an extra X event. | 23:13 |
| wgrant | Upstream blessing could hopefully be sought soon; all distros will run into this soon. | 23:14 |
| bryce | yes, having a patch that's accepted upstream often counts favorably | 23:14 |
| wgrant | This is what we get for being early adopters :( | 23:15 |
| bryce | wgrant: you can always run it by slangasek first to get an indicator of if it's worth shooting for an SRU | 23:15 |
| bryce | wgrant: yep :-/ | 23:15 |
| wgrant | Yep. | 23:15 |
| bryce | wgrant: the patch doesn't look too bad to me; since that's a GNOME change I don't know that my vote would count, but I'd +1 it if it would | 23:16 |
| bryce | hmm, actually I'd probably prefer seeing this accepted upstream before I formally +1'd it | 23:17 |
| bryce | but really I think you'd need lool or seb128 to give a +1 | 23:17 |
| wgrant | As would I. On both points. | 23:18 |
| === ubott2 is now known as ubottu | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!