| bryce | tjaalton: are you around? Do you have this bug on your X60? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407188 | 01:10 |
|---|---|---|
| ubottu | Debian bug 407188 in acpi-support "Laptop gets stuck after sleep" [Grave,Closed] | 01:10 |
| tjaalton | bryce: yes, but it's a fairly recent regression, and tracked in bug 269884 | 05:28 |
| ubottu | Launchpad bug 269884 in linux "thinkpad x61 intermittently hangs on resume with 2.6.27-3" [High,Triaged] https://launchpad.net/bugs/269884 | 05:28 |
| === superm1|away is now known as superm1 | ||
| Ng | bah, just had an X lockup unlocking the screensaver. I thought that was gone :( | 09:44 |
| tjaalton | my kernel crashed during the session, after a successful resume | 09:45 |
| Ng | erk | 09:46 |
| Ng | I really hope the intel situation settles down at some point soon, there seems to be way too much changing for it to remain remotely stable :/ | 09:47 |
| tjaalton | we need intrepid users ;) | 09:48 |
| Ng | tjaalton: the only people I can encourage to upgrade are all thinkpad users ;) | 10:18 |
| crevette | tjaalton, Ng what do you want to test ? | 10:28 |
| crevette | I'm a thinkpad user in intrepid | 10:28 |
| crevette | s/in/on/ | 10:28 |
| Ng | I don't have anything specific, and I'm running Intrepid on a thinkpad - I meant that I don't know anyone else I can encourage to upgrade for testing purposes, who isn't on basically the same hardware as tjaalton or me ;) | 10:29 |
| Ng | but I would like the X wedge on screensaver unlock to be fixed | 10:30 |
| Ng | tjaalton: do you think this could be the same thing as the vblank thing which crashed it when activating the screensaver? | 10:30 |
| crevette | I had my thinkpad recently, so Iwas always ion intrepid | 10:30 |
| crevette | I just disable splash because irt caused problem | 10:31 |
| Ng | by the point it crashes the display is on, I've typed my password and it's drawn the background, so it's kinda surprising that it gets stuck at all | 10:31 |
| tjaalton | wgrant: see bug 274728, anything missing? | 11:10 |
| ubottu | Launchpad bug 274728 in xserver-xorg-input-synaptics "Update the input properties API to current version" [Undecided,New] https://launchpad.net/bugs/274728 | 11:10 |
| wgrant | tjaalton: The only other things I can think of are g-c-c and g-s-d. | 11:12 |
| tjaalton | wgrant: right, thanks | 11:12 |
| wgrant | tjaalton: Did you also see that somebody replied that the new MaxTapMove default didn't fix multi-finger tapping for them? | 11:13 |
| wgrant | But that my package did... I'm very, very confused. | 11:13 |
| wgrant | Because the MaxTapMove change did fix it for me. | 11:13 |
| tjaalton | wgrant: no, I've ignored synaptics for a couple of days :) | 11:14 |
| wgrant | tjaalton: Probably a good policy. | 11:14 |
| tjaalton | hehe | 11:16 |
| tjaalton | wgrant: I think I found out why some synaptics users got errors from xinput.. the patch for xserver looks incomplete | 11:53 |
| wgrant | tjaalton: Ah, that would do it! RAOF suffers from the problem, if you need a sane tester. | 12:13 |
| wgrant | What's missing? | 12:14 |
| tjaalton | wgrant: I'm not sure though, since the code is a mystery to me :) but it's in Xi/extinit.c. SProcIDispatch doesn't add the same stuff as ProcIDispatch does | 12:14 |
| tjaalton | I'm backporting the changes and noticed that | 12:14 |
| tjaalton | wgrant: hm, same thing with SReplyIDispatch | 12:45 |
| wgrant | tjaalton: I'll be interested to see if this fixes it... do you have an ETA for porting the infrastructure? | 12:46 |
| wgrant | And do we know how those bits were missed? | 12:47 |
| tjaalton | wgrant: inputproto & libxi done, xserver WIP | 12:48 |
| tjaalton | I've asked whot if they were left out on purpose | 12:49 |
| tjaalton | waiting for a reply | 12:49 |
| wgrant | tjaalton: Ah, excellent. I'll fix g-c-c and g-s-d tomorrow. | 12:49 |
| tjaalton | wgrant: it's unclear if they get in beta | 12:50 |
| tjaalton | but.. sooner the better | 12:50 |
| wgrant | True. | 12:50 |
| Kano | hi, which package is used to map the volume and other media keys to the XF86Audio symbols? | 13:30 |
| tjaalton | in gnome? gnome-control-center | 13:44 |
| wgrant | Doesn't that just map them to actions? | 13:45 |
| seb128 | tjaalton: no, GNOME doesn't map keysym to symbols | 13:45 |
| tjaalton | oh right | 13:45 |
| seb128 | that's an xkeyboard-config thing rather | 13:45 |
| tjaalton | I thought he asked about the shortcuts | 13:46 |
| seb128 | the GNOME dialog justs associations actions to those | 13:46 |
| tjaalton | yep | 13:46 |
| tjaalton | trust me, I've looked at x-c enough for the week ;) | 13:46 |
| Kano | well i can do similar things with xmodmap, but where is it done with ubuntu or the lenny | 13:48 |
| tjaalton | it's a complicated issue and no-one has the right answer :) | 13:48 |
| tjaalton | but if the keys produce events, then xkeyboard-config just needs to support them | 13:49 |
| Kano | well they are already supported, just the keys are not mapped by default in etch | 13:52 |
| Kano | xmodmap -e "keycode 160 = XF86AudioMute" -e "keycode 174 = XF86AudioLowerVolume" -e "keycode 176 = XF86AudioRaiseVolume" | 13:53 |
| Kano | these are the audio keys | 13:53 |
| Kano | when i do that with etch the keys work | 13:53 |
| tjaalton | ok | 13:55 |
| Kano | in #nvidia the devs seem to sleep, nobody answered about my problem | 13:56 |
| Kano | i guess they only test with tft... | 13:56 |
| seb128 | tjaalton: btw there is plenty if gnome-control-center keyboard bugs which are probably xkeyboard-config issues and could use a somebody having a clue to triage those | 13:57 |
| Kano | ati x700 (rv410) is pretty bad supported too, but at least there is a pic | 13:57 |
| tjaalton | seb128: ok, now we only need someone having the clue ;) | 13:58 |
| seb128 | tjaalton: you? ;-) | 13:58 |
| tjaalton | <whistle> | 13:58 |
| tjaalton | seb128: I believe all the "error activating XKB configuration" bugs are fixed in intrepid | 14:01 |
| tjaalton | seb128: I'll have a quick look at them | 14:04 |
| seb128 | tjaalton: thanks | 14:04 |
| jcristau | Kano: set the appropriate xkb model and the keys will work | 14:25 |
| Kano | in etch? which one | 14:26 |
| jcristau | the one that maps the keycodes to the right keysym for your keyboard | 14:26 |
| Kano | why is the same config different when using lenny? | 14:27 |
| jcristau | because it's not the same version of stuff | 14:27 |
| jcristau | duh | 14:27 |
| Kano | is it possible to backport it? | 14:28 |
| Ng | hmm, I think it would be nice if X kept more than two log files | 14:39 |
| Ng | if you end up bouncing into failsafe it seems like you can lose the log which might have useful information in it | 14:40 |
| jcristau | failsafe may want to start with a different display number | 14:41 |
| Ng | unless there are lots of vt changing bugs that might make that break more, it sounds sane, but even so i think keeping 5 or 6 would be a good idea | 14:41 |
| Ng | it's not like they're huge files. other stuff in /var/log/will be much bigger and hang around for much longer | 14:41 |
| Ng | (I say this because I just had it wedge on unlocking again and I had to ssh in from my phone to make sure I keep a copy of the log) | 14:42 |
| tjaalton | if it could use syslog (with a nice prefix to distinguish different servers), then it would be trivial to use logrotate | 14:48 |
| tjaalton | and some wrapper to filter the logfile out | 14:48 |
| Ng | tjaalton: I think syslog is too old and broken for that to be much fun ;/ | 15:41 |
| tjaalton | Ng: syslog-ng then?-) | 15:42 |
| Ng | tjaalton: I hate that thing | 15:43 |
| Ng | mainly because it has "-ng" in the name, and so triggers irssi highlighting ;) | 15:43 |
| Ng | but also it's still not all that great | 15:43 |
| tjaalton | heh, ok | 15:43 |
| tjaalton | I liked the syslogd in Tru64 | 15:43 |
| jcristau | i think debian switched to rsyslog as default for lenny. no idea how good it is though. | 15:45 |
| Ng | it is a typical piece of unix idiocy that we have a central logging system that's unused by so many things :/ | 15:45 |
| Ng | because the thing is 800 years old and really stupid ;) | 15:45 |
| === superm1 is now known as superm1|away | ||
| seb128 | did anybody there broke xvfb in intrepid? | 16:30 |
| seb128 | there is some uploads which ftbfs on "Xvfb failed to start" errors now | 16:30 |
| === superm1|away is now known as superm1 | ||
| seb128 | hello, anybody around? | 16:41 |
| mvo | tseliot: I get a debconf note about "obsolete NVIDIA driver" on my system that tells me that I need to install nvidia-glx-177 (also that one is installed already) - is that expected behaviour? | 16:44 |
| tseliot | mvo: yes, we have to deal with the case in which users dist-upgrade from the command line | 16:45 |
| tseliot | I'm always open to better solutions though | 16:45 |
| tseliot | mvo: and of course the debconf warning will bug you only if you have a driver with the old name scheme installed | 16:46 |
| mvo | tseliot: aha, ok. so I just ensure in update-manager that the oldnames get removed? | 16:46 |
| tseliot | e.g. nvidia-glx, nvidia-glx-{new| legacy} | 16:46 |
| tseliot | mvo: yes, right | 16:47 |
| mvo | tseliot: thanks, adding that | 16:48 |
| tseliot | mvo: ok, let me know if you need help with, say, X-Kit or nvidia common | 16:49 |
| mvo | tseliot: I hope its all more or less ready, real-world testing is going to be the important next thing | 16:52 |
| tseliot | yes, right | 17:03 |
| jcristau | seb128: looks like Xvfb gets in an infinite loop trying to open swrast_dri.so which doesn't exist | 17:31 |
| seb128 | jcristau: likely something easy to fix? or should we rather disable the xvfb use for now? | 17:32 |
| jcristau | don't know yet | 17:32 |
| jcristau | seb128: you could pass -extension GLX, or build-dep on libgl1-mesa-dri, to work around it | 17:32 |
| jcristau | hah. the client runs fine, then when it exits Xvfb tries to regen and loops. | 17:37 |
| bryce | 274234 - wow, first evidence of the new failsafe-X usefulness | 17:38 |
| jcristau | seb128: other option, have xvfb-run pass -terminate to Xvfb | 17:39 |
| bryce | Ng: are you testing Intrepid? the new failsafe mode writes its X session to Xorg.failsafe.log now | 17:43 |
| seb128 | bryce: could you look at fixing xvfb-run? it breaks build which are blocker fix for intrepid beta | 17:47 |
| Ng | bryce: that's an exceptionally good point. The thing is I'm sure I've managed to hit a situation on my machine at home where it failed to start X on boot and eventually fell into failsafe, but when I rebooted and it started X properly, the original failure log was lost | 17:48 |
| jcristau | seb128: looks like i tracked it down. not sure what the correct fix is, but. | 17:49 |
| seb128 | jcristau: me neither, and I would prefer to somebody who has a clue about xorg to decide about that ;-) | 17:49 |
| Ng | bryce: will it try failsafe the first time the server fails to start, or could it have tried X a few times before running failsafe-X? | 17:50 |
| seb128 | I mean I would prefer having somebody fixing it rather than applying a workaround | 17:50 |
| bryce | Ng: well if you can reproduce it I can take a look. The change I made was about a week or so ago, so if your machine was running an older Intrepid, it might not have had the new feature | 17:50 |
| Ng | bryce: I'll upgrade the machine over the weekend, but it's really hard to reproduce its problems, they're very random :/ | 17:51 |
| bryce | Ng: gdm normally tries to boot X three times in a row, and invokes failsafe only after that | 17:51 |
| bryce | Ng, failsafe mode can be forcibly triggered by setting your driver to "foobar" | 17:51 |
| jcristau | i'll try to talk to krh | 17:52 |
| Ng | bryce: so if the first run failed and wedged the graphics card such that any further attempts failed for different reasons, you'd lose the original log? | 17:52 |
| bryce | seb128: can it wait until monday? I'm actually off work today and will be going away to the beach for the weekend | 17:52 |
| bryce | Ng: hmm, possibly so | 17:53 |
| Ng | bryce: I'm suspecting that's what happened, it seems to be very unhappy about running X again after it's screwed up once | 17:53 |
| seb128 | bryce: well, that means intrepid will not be installable until monday, bad timing, I'll workaround the issue in the applications using xvfb-run by commenting the calls | 17:53 |
| bryce | Ng: well what you might do is shut down gdm and run it via startx, so it runs just once; then you can reproduce the problem and capture the log directly | 17:54 |
| Ng | bryce: sure, this was more about the potential for losing valuable X logs than the particular brands of madness which infect the X4000 driver ;) | 17:55 |
| Ng | bryce: I think it should rotate them a bit more and keep 5 or 6 :) | 17:55 |
| bryce | hmm | 18:00 |
| bryce | well, this seems like a pretty rare corner case, but probably wouldn't be hard to implement - mind filing a wishlist bug against xorg-server? | 18:01 |
| Ng | ok :) | 18:02 |
| seb128 | jcristau: a build-dep on libgl1-mesa-dri would workaround the xvfb issue for sure? just pondering between doing that or commenting the call ;-) | 18:23 |
| jcristau | yes, it would. as would passing -extension GLX, or -noreset, to Xvfb | 18:25 |
| * seb128 read the xvfb-run manpage | 18:29 | |
| * mvo grumbles about the nvidia driver | 20:24 | |
| tjaalton | bryce: enjoy the beach :) | 22:02 |
| mvo | oh, beach | 22:03 |
| tjaalton | mvo: what now?-) (about nvidia) | 22:04 |
| * mvo wants a beach as well - and icecream! | 22:04 | |
| mvo | tjaalton: it make my life difficult, I think I had both nvidia-glx-new and -177 installed, then I removed -new and I think that caused my kernel module to disappear (but I'm not sure about this, but the X log claimed it could not laod the nvidia module) | 22:05 |
| tjaalton | mvo: urgh | 22:05 |
| mvo | yeah, fglrx does not like me either, I have it removed (but not purged) and when I try to purge it the diverts fall all over | 22:06 |
| mvo | but I'm too tired today to debug it further | 22:06 |
| tseliot | mvo: weird, nvidia-glx-177 conflicts with/replaces nvidia-glx-new | 22:06 |
| tjaalton | nothing a dash of Bowmore couldn't cure | 22:07 |
| mvo | tseliot: strange, maybe it was nvidia-glx-legacy? I can't quite remember, but I can check the logs | 22:07 |
| tjaalton | I'm still struggling with the properties backport for our xserver.. some bits missing | 22:07 |
| tseliot | mvo: it's still weird. Have a look at nvidia-glx-177 Conflicts and Replaces | 22:09 |
| tseliot | http://pastebin.com/d92c28be | 22:10 |
| mvo | hm, right | 22:11 |
| * mvo scrachtes head | 22:11 | |
| mvo | tseliot: aha! I think I have the reason, I purged nvidia-glx-new (when it was already removed) | 22:12 |
| mvo | hm, at least that is my theory | 22:12 |
| tseliot | mvo: and what did that cause? | 22:13 |
| tseliot | or where did it remove the module from? | 22:14 |
| tseliot | mvo: the kernel module is not supposed to be in the lrm any more. Have a look at /var/lib/dkms/nvidia/177.76/2.6.27-4-generic/i686/module/ | 22:15 |
| tseliot | or something similar | 22:15 |
| mvo | I just looked at the postrm of nvidia-glx-new and there is nothing in it that could have caused this afaics - so maybe it was something different. I will try to reporduce it tomorrow or later tonight I think | 22:15 |
| tseliot | ok | 22:18 |
| tjaalton | oh cool, the xorg-server with current properties backported built successfully | 22:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!