| tjaalton | bryce: you can upload xorg if you like, I'm going to bed :) | 00:01 |
|---|---|---|
| tjaalton | nvidia 173/177 and fglrx-installer need a rebuild too | 00:02 |
| bryce | alright | 00:06 |
| * bryce uploads xorg. no more displayconfig-gtk | 01:35 | |
| bryce | http://www.cyriak.co.uk/lhc/lhc-webcams.html | 04:26 |
| wgrant | bryce: How does one choose video drivers now if displayconfig-gtk is gone? | 06:33 |
| bryce | wgrant: you don't ;-) | 07:13 |
| wgrant | bryce: How does one choose between nouveau, nv and nvidia? | 07:20 |
| bryce | nouveau is still pre-release | 07:20 |
| bryce | nvidia can be chosen via jockey | 07:20 |
| wgrant | True. | 07:21 |
| bryce | the xorg-options-editor blueprint tseliot's working on will also have a general purpose GUI driver selector | 07:21 |
| bryce | that's not scheduled for upload until jaunty, however he has got most of the code written | 07:22 |
| bryce | I don't think displayconfig-gtk allowed selecting nouveau either, and while it let you pick nvidia, I don't think it got things set up correctly as reliably as jockey does | 07:23 |
| wgrant | xorg.conf is basically going to become a file to select the video driver, isn't it? | 07:23 |
| wgrant | It doesn't seem to be needed for much except that and Virtual now. | 07:24 |
| bryce | actually no; ultimately it will be completely vestigial | 07:24 |
| wgrant | How would one select the video driver? | 07:25 |
| bryce | there's code going in to do auto-fallback of drivers, so specifying the driver should only be needed if you're experimenting | 07:25 |
| wgrant | Ah. | 07:25 |
| bryce | the idea is, if you have nvidia installed, it should of course use that first | 07:25 |
| bryce | if it crashes or otherwise can't be loaded, then xserver should automatically go to nv (or nouvaeu if/when it's released), then vesa, etc. | 07:26 |
| wgrant | Yep. | 07:26 |
| bryce | xorg.conf may be necessary if you wish to override default device options | 07:26 |
| bryce | however long term I think even that is going to go away, with plans to make option setting on the fly possible | 07:27 |
| tjaalton | morning folks | 07:30 |
| tjaalton | eventually there'll be output properties just like there are input properties now | 07:32 |
| tjaalton | was it randr-1.3 stuff, I'm not sure | 07:32 |
| tjaalton | btw, the fallback stuff doesn't work right, at lest for the guy who has an nvidia card which nv doesn't support. the driver fails to use it, but falling back to vesa fails as well | 07:33 |
| tjaalton | might be a bug in nv though | 07:34 |
| tjaalton | I mean, not releasing the device | 07:34 |
| wgrant | Morning tjaalton. | 07:34 |
| tjaalton | wgrant: hey, how's the new synaptics working?-) | 07:34 |
| wgrant | tjaalton: I hear that vertical scrolling is fixed in at least some of the broken devices now. | 07:34 |
| bryce | tjaalton: aha, yeah I expected it'd take a bit more work | 07:35 |
| wgrant | O_o | 07:35 |
| wgrant | an upgrade uninstalled nautilus for me. Nice of it. | 07:35 |
| tjaalton | bryce: yeah, vesa fails with (EE) No devices | 07:35 |
| tjaalton | bryce: I've sent an email to alanc who implemented that, but haven't heard from him | 07:36 |
| tjaalton | I'm hopefully getting a new mb for the laptop today.. tough living without ethernet | 07:37 |
| tjaalton | and all my git stuff is in there | 07:38 |
| wgrant | Ethernet chips don't often die... were you a victim of the firmware overwriting bug? | 07:38 |
| tjaalton | (vista upgrade broke the device, it failed with "NVM checksum error", and IBAUTIL.EXE finished the job) | 07:38 |
| tjaalton | ^^ :) | 07:38 |
| wgrant | Nice! | 07:38 |
| tjaalton | I had to boot to vista because I wanted to clear the airbag error on my car, but couldn't find the cable. so, vista decided to install upgrades which took ~1h | 07:39 |
| tjaalton | after that, no ethernet | 07:40 |
| tjaalton | who needs it anyway | 07:40 |
| tjaalton | I should try VAG-COM with wine, might work now | 07:40 |
| wgrant | Ummmm. | 07:41 |
| wgrant | What does Vista have to do with your car, and why? | 07:41 |
| tjaalton | it has the software | 07:41 |
| wgrant | Your car has a USB port? | 07:42 |
| wgrant | That is mildly scary. | 07:42 |
| tjaalton | no, OBD | 07:42 |
| tjaalton | but I have a rs232-OBD cable | 07:42 |
| tjaalton | hum sorry, that's not what it's called | 07:42 |
| wgrant | Ah. Laptop with RS232. Haven't seen one of them in a while! | 07:42 |
| tjaalton | righ, it was OBD-II | 07:43 |
| tjaalton | neither does my X61 have one, but the dock does :) | 07:43 |
| wgrant | Ahh. | 07:43 |
| tjaalton | don't know if an usb-serial dongle might work with it | 07:44 |
| tjaalton | I'll upload a new mesa with the vblank commit reverted | 07:53 |
| tjaalton | that will do until upstream knows the real fix | 07:54 |
| bryce | tjaalton: arghlgle... as if you needed more reasons to dislike vista | 07:54 |
| bryce | tjaalton: btw I got some oddball build errors on my -intel upload today | 07:55 |
| tjaalton | bryce: yeah.. if only the hw vendors would get their act together and support linux.. logitech and nokia are to blame too.. | 07:55 |
| tjaalton | bryce: but on archs we don't care about? | 07:55 |
| bryce | yeah | 07:55 |
| bryce | like hppa, ppc, etc | 07:55 |
| tjaalton | yep | 07:56 |
| bryce | the error messages were in packaging/changelog stuff, not actually compile errors | 07:56 |
| bryce | ok good, I thought maybe it was an expected error | 07:56 |
| bryce | the other driver builds and xorg went through fine | 07:57 |
| tjaalton | well, I think the problem is that -i810 is an arch: all package | 07:59 |
| tjaalton | so that's why -intel is built on those archs | 07:59 |
| tjaalton | while it should not be | 07:59 |
| tjaalton | dh_installdeb: I have no package to build | 07:59 |
| bryce | ahh | 07:59 |
| tjaalton | so no problem there | 08:00 |
| tjaalton | -i810 will be dropped after lenny I guess | 08:00 |
| bryce | tomorrow I'm going to meet up with slangasek downtown so hopefully can look into that keyboard issue on that | 08:00 |
| tjaalton | I think there are two things mixed up here | 08:00 |
| tjaalton | one is the acpi keys and the other is the media stuff | 08:00 |
| bryce | of course, if you end up solving it between now and then, I definitely wouldn't be unhappy! :-) | 08:00 |
| * bryce nods | 08:01 | |
| tjaalton | gnome key shortcuts probably are still listening some hexcodes, not the 'XF86FOO' that evdev produces | 08:01 |
| bryce | yeah I definitely know the sleep-key-no-work issue I see is completely different from mdz's | 08:01 |
| tjaalton | seb128 said that the patch to g-s-d (or g-c-c, can't remember) should be dropped already | 08:02 |
| tjaalton | btw, whot made a new blog post about the xkb stuff | 08:02 |
| tjaalton | (and happened to credit me, too :) | 08:02 |
| bryce | oh cool | 08:04 |
| tjaalton | that helps a bit in understanding some of this | 08:05 |
| bryce | whot == peter hutterer? | 08:08 |
| bryce | yup | 08:09 |
| tjaalton | yeah | 08:09 |
| tjaalton | uh, so the drirc workaround for the intel hang doesn't seem to work for all, so there are different bugs involved | 09:35 |
| tjaalton | anyway, mesa uploaded | 09:35 |
| wgrant | tjaalton: Hm, it worked for me. | 09:45 |
| tjaalton | wgrant: that's good, I left the bug open to make sure it's not forgotten | 09:45 |
| wgrant | tjaalton: Why did you ask about the two-fingered scrolling a couple of days back? | 09:46 |
| wgrant | (the lack of UI for it, in particular) | 09:46 |
| tjaalton | someone asked for it | 09:46 |
| wgrant | I hope to give us a complete Synaptics GUI for Jaunty. As long as nobody else has it planned. | 09:47 |
| tjaalton | nice, remember to work with gnome upstream ;) | 09:47 |
| wgrant | I guess this can go upstream now it doesn't depend on that hack. | 09:48 |
| tjaalton | yes | 09:48 |
| * wgrant stabs GTK. | 09:58 | |
| wgrant | Stupid flickering. | 09:58 |
| seb128 | wgrant: stab xorg rather | 09:59 |
| wgrant | seb128: So what is actually causing it? | 10:02 |
| seb128 | wgrant: xorg | 10:02 |
| seb128 | let me find you the bug number | 10:02 |
| tjaalton | seb128: well, gtk probing those fills Xorg.0.log.. | 10:03 |
| wgrant | Thanks. | 10:03 |
| tjaalton | those = outputs | 10:03 |
| tjaalton | it shouldn't do that | 10:03 |
| seb128 | http://bugzilla.gnome.org/show_bug.cgi?id=544072 | 10:03 |
| ubottu | Gnome bug 544072 in general "GTK+ calls XRRGetScreenResources() altogether far too frequently" [Major,Unconfirmed] | 10:03 |
| wgrant | Is that why I'm getting hundreds of lines of -intel EDID stuff in logs? | 10:03 |
| wgrant | Aha. | 10:03 |
| seb128 | XRRGetScreenResources() is doing this flickering | 10:03 |
| seb128 | and there is a disagrement upstream on whether gtk should not call it or if should not be as expensive | 10:04 |
| seb128 | I think they are leading to "add a new api less expensive that gtk could use for what is needed" | 10:04 |
| wgrant | GTK lived fine without it until not long ago... | 10:05 |
| seb128 | wgrant: GTK was not xrandr aware until not long ago | 10:16 |
| wgrant | seb128: Why does my UI toolkit need to be XRandR-aware? | 10:30 |
| seb128 | wgrant: to handle screen changes correctly | 10:30 |
| wgrant | I see. | 10:30 |
| seb128 | wgrant: read https://bugs.freedesktop.org/show_bug.cgi?id=16224 | 10:31 |
| ubottu | Freedesktop bug 16224 in Driver/intel "Opening new window causes external monitor to momentarily blank" [Normal,Resolved: notourbug] | 10:31 |
| wgrant | seb128: Right, I saw that earlier. | 10:32 |
| seb128 | I think there was some details about what GTK need there, maybe that's on the list discussion | 10:32 |
| seb128 | but it needs details about the available screens, the geometry etc to optimize screen usage | 10:32 |
| jcristau | seb128: until the lightweight api exists, gtk should revert to just getting the geometry from xinerama... | 10:36 |
| seb128 | jcristau: maybe, I'm not GTK upstream though and I don't want to do that in a distro specific way | 10:41 |
| jcristau | that doesn't make any sense to me | 10:42 |
| seb128 | jcristau: why? | 10:50 |
| jcristau | last i checked the only thing gdk used from randr was the geometry, which it can get from xinerama, without the nasty side-effects | 10:57 |
| jcristau | but even then, the side-effects of XRRGetScreenResources are enough of a reason to not use it every time you start an app | 10:58 |
| seb128 | jcristau: http://bugzilla.gnome.org/show_bug.cgi?id=439588 | 10:59 |
| ubottu | Gnome bug 439588 in gdk "Use XRANDR 1.2 instead of Xinerama when available" [Enhancement,Resolved: fixed] | 10:59 |
| jcristau | hrm. sucks. | 11:00 |
| jcristau | ddc is slow, so in addition to flicker you get a one second xserver hang.. | 11:02 |
| === mvo__ is now known as mvo | ||
| === mvo__ is now known as mvo | ||
| tjaalton | bryce: I'll be at the meeting, need to get home first -> | 15:26 |
| Solarion | crevette: bonjour! | 15:46 |
| Solarion | anyone have an idea why the screen blanking (for screensaver) would cause the system to lock up? | 15:47 |
| Ng | Solarion: it's a known bug, tjaalton has tracked it down to something in Mesa | 15:52 |
| Ng | Solarion: see https://bugs.launchpad.net/bugs/262605 | 15:52 |
| ubottu | Launchpad bug 262605 in mesa "[intrepid] X locks up or crashes when screensaver activates" [High,Confirmed] | 15:52 |
| crevette | salut Solarion | 15:55 |
| Solarion | in other news, metal drawer handles frickin' *hurt* when you whang into them with your knee at high speeds | 15:56 |
| Solarion | rolley-chair + old-style desk = pain | 15:57 |
| Solarion | Ng: thanks,, btw | 15:57 |
| Solarion | any idea when the new mesa will hit? | 15:59 |
| Ng | Solarion: nope | 16:06 |
| tjaalton | Solarion: uploaded already, at least archive.ubuntu.com has it | 16:07 |
| Solarion | tjaalton: when was that? | 16:12 |
| tjaalton | today | 16:12 |
| Solarion | what version would that be? | 16:13 |
| Solarion | ah, 7.1-1ubuntu2, duh. :) | 16:13 |
| * Solarion finishes the transfer before testing | 16:14 | |
| bryce | tjaalton: great thanks | 17:27 |
| tjaalton | bryce: I'll have a chat with pitti about how pm-utils/hal and hotkeys interact | 17:34 |
| tjaalton | that's basically what we decided | 17:34 |
| bryce | yep, saw the log | 17:34 |
| bryce | I'm going to be meeting up with slangasek, so will be able to look at the issue on his system too | 17:34 |
| tjaalton | don't know why xorg is uninstallable on i386/amd64, installed just fine here | 17:35 |
| === mvo__ is now known as mvo | ||
| bryce | heading downtown; be back online in an hour or so | 17:42 |
| mvo | hello! it seems that (for intel) the xserver claims to be able to do direct rendering when a additional server is started via fusa, but when compiz is started, that does not work | 18:38 |
| mvo | is that a know issue? | 18:38 |
| mvo | pitti just told me about it on #ubuntu-devel | 18:39 |
| mvo | didn't it use to not accelerate the additonal xservers, only the first one? | 18:39 |
| tjaalton | so you get a white screen for the second screen? | 18:41 |
| tjaalton | don't know why that is.. | 18:42 |
| mvo | yes | 18:43 |
| mvo | (well, not me, but martin) | 18:43 |
| tjaalton | I tried it myself ~1h ago | 18:43 |
| tjaalton | and saw the saem | 18:43 |
| tjaalton | -me | 18:43 |
| mvo | tjaalton: for hardy (and before) the additional screens were without DRI, no? | 18:44 |
| tjaalton | yep, think so | 18:44 |
| tjaalton | but it does disable it | 18:45 |
| tjaalton | looking at the log.. | 18:45 |
| mvo | I need to test that with my ati to see if that shows it too | 18:45 |
| mvo | thanks! | 18:45 |
| tjaalton | ah | 18:45 |
| tjaalton | (II) GLX: Initialized DRISWRAST GL provider for screen 0 | 18:46 |
| tjaalton | maybe that has something to do with it | 18:46 |
| mvo | meh | 18:46 |
| mvo | indeed | 18:46 |
| mvo | makes me wonder if need to add another hack to the compiz startup script and grep for "OpenGL renderer string: Software Rasterizer" in glxinfo | 18:46 |
| tjaalton | perhaps, doesn't seem like it's able to please compiz | 18:47 |
| * mvo wishes there was a reliable way to ask "is your opengl HW accelerated, xserver" | 18:47 | |
| tjaalton | glxinfo? | 18:48 |
| tjaalton | hm, maybe not | 18:48 |
| mvo | well, that is what I do currently, and it keeps lying at me :) | 18:49 |
| tjaalton | yeah, maybe the swrast-thing lies that it's DRI | 18:57 |
| bryce | back heya | 18:59 |
| tjaalton | hey hey | 19:01 |
| bryce | steve's not arrived yet | 19:04 |
| bryce | tjaalton: so where do we sit with the hotkey bug? I suppose that's the top of my todo list again now | 19:05 |
| tjaalton | bryce: to find out if it's just a mapping thing that can be fixed in pm-utils or whatever should listen to them | 19:06 |
| tjaalton | I'm gathering all the keysyms that I get from the nonworking ones, and see what they should be | 19:06 |
| tjaalton | on my X61 | 19:07 |
| james_w | tseliot: I see you've fixed bug 262906 upstream already. Would it be better to use strptime to produce something like "xorg.conf.20080912201512"? | 19:16 |
| ubottu | Launchpad bug 262906 in screen-resolution-extra "policyui.py crashed with TypeError in setVirtual()" [Undecided,Confirmed] https://launchpad.net/bugs/262906 | 19:16 |
| james_w | rather than "xorg.conf123456.3212" | 19:16 |
| james_w | thanks for fixing it though | 19:16 |
| tseliot | james_w: it creates a backup with the current date (in Python) | 19:17 |
| james_w | tseliot: yeah, but str(time.time()) produces something where the date isn't obvious to the user | 19:18 |
| james_w | if you use strptime they can easily see what date the backup was made on | 19:18 |
| tseliot | james_w: ok | 19:18 |
| tseliot | would you like to fix it and upload it? | 19:19 |
| james_w | I can't upload it | 19:20 |
| james_w | I can provide you with a branch to merge if you like though | 19:20 |
| tseliot | james_w: yes, that would be great since my branch has evolved too much | 19:21 |
| james_w | tseliot: ah, you would like one based on what is in Intrepid? | 19:21 |
| tseliot | james_w: yes, please | 19:21 |
| tseliot | james_w: the one in my bzr branch is meant to work with my patches (in C) | 19:22 |
| tseliot | james_w: isn't my fix in Intrepid already? | 19:23 |
| james_w | tseliot: apart from that, and the intel bug just discussed it seemed to work well though, thanks | 19:23 |
| tseliot | james_w: the one which looks ugly to you, I mean | 19:23 |
| james_w | tseliot: I don't think so, I just hit it, and there don't seem to be any uploads | 19:25 |
| james_w | and I just grabbed the source and it matched revision 4, which is before the fix | 19:25 |
| tseliot | james_w: ok, then I forgot to ask bryce to upload it after the freeze in main | 19:26 |
| tseliot | bryce: can you upload james_w's fix when it's ready, please? | 19:26 |
| james_w | tseliot: I see why you also moved it in to the "try: except:" block that parses the file | 19:27 |
| james_w | tseliot: but it seems like that would leave you without a backup if the file didn't exist | 19:27 |
| tseliot | james_w: why make a backup of a file which doesn't exist? | 19:28 |
| james_w | sorry, if the file doesn't parse | 19:28 |
| tjaalton | bryce: I'll be afk for ~2h | 19:29 |
| tseliot | james_w: let me check the code | 19:29 |
| tseliot | james_w: I could handle the 2 exceptions separately | 19:31 |
| tseliot | i.e. don't make a backup if IOError is caught | 19:31 |
| tseliot | but make a backup | 19:31 |
| james_w | tseliot: I can just add an "os.path.exists:" check first and make the backup | 19:31 |
| tseliot | james_w: yes, sure | 19:32 |
| james_w | tseliot: lp:~james-w/screen-resolution-extra/intrepid if you would like to check it | 19:34 |
| tseliot | james_w: BTW if my patch is accepted there will be no need to set up the screens again on login after setting the virtual resolution | 19:35 |
| * tseliot has a look at the new branch | 19:35 | |
| james_w | yeah, I saw that, it would be pretty cool | 19:35 |
| tseliot | let's cross our fingers | 19:37 |
| tseliot | james_w: ok, the code looks good. There's still something else which I would like to fix but I guess it's enough for now. | 19:41 |
| tseliot | thanks a lot | 19:41 |
| james_w | thank you | 19:41 |
| james_w | can I leave it with you to get that uploaded? | 19:41 |
| bryce | tseliot: sure will do | 19:42 |
| tseliot | bryce: thanks | 19:42 |
| bryce | tseliot, james, got a debdiff or patch or gid id I should pull from? | 19:42 |
| tseliot | bryce: can you take the code from James' branch? https://code.launchpad.net/~james-w/screen-resolution-extra/intrepid | 19:43 |
| james_w | bzr diff -c -1 lp:~james-w/screen-resolution-extra/intrepid | 19:44 |
| james_w | "show me the diff of the last revision in that branch" | 19:44 |
| bryce | http://bazaar.launchpad.net/%7Ejames-w/screen-resolution-extra/intrepid/diff/5 looks good? | 19:44 |
| * tseliot should learn how to do such tricks with bzr... | 19:44 | |
| bryce | hm | 19:45 |
| bryce | $ bzr diff -c -1 lp:~james-w/screen-resolution-extra/intrepid | 19:45 |
| bryce | bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack5 (bzr 1.6)\n' | 19:45 |
| james_w | bryce: are you on hardy?! | 19:45 |
| bryce | oh this is complicated... | 19:46 |
| bryce | my laptops are intrepid, but my main development box (which does builds, file serving, etc.) is hardy | 19:47 |
| james_w | http://jameswestby.net/scratch/fix-backup.diff | 19:47 |
| bryce | also, my mythtv box is hardy, so any machine I have that needs to view mythtv has to be on hardy too (mythtv client/server versions must match) | 19:47 |
| bryce | anyway, TMI. I use heavy chrooting and pbuilder for builds and stuff | 19:48 |
| james_w | yeah, the exclamation mark might have been a bit over the top | 19:49 |
| bryce | anyway, I'm still not 100% sure whether the extra overhead is worth the stability for the build box | 19:50 |
| bryce | but doing builds in chroots seems to have eliminated a lot of build goofs I used to run into | 19:50 |
| bryce | and having nfs go away really crimps my style ;-) | 19:51 |
| * tseliot > bbl | 19:52 | |
| Solarion | tjaalton: the new mesa wfm | 19:59 |
| bryce | james_w, tseliot: uploaded | 20:59 |
| james_w | thanks | 21:00 |
| tseliot | bryce: thanks a lot :-) | 21:00 |
| bryce | tjaalton: so slangasek's problem seems to have been driven by the presence of a ~/.Xmodmap. Since removing that, his keys are working better | 21:46 |
| tjaalton | bryce: oh, nice | 21:47 |
| bryce | tjaalton: also it sounds like pitti's issue more closely resembles mine than mdz's | 21:47 |
| bryce | so it's not sure that anyone has "the same" issue as mdz | 21:47 |
| tjaalton | yeah | 21:53 |
| tjaalton | man, this is confusing.. | 22:03 |
| tjaalton | trying to stay sane with all these scancodes, keycodes, keysymbols etc.. | 22:03 |
| tjaalton | anyway, I get the same keycodes for hibernate and batter, and yes, they don't work for me either | 22:04 |
| tjaalton | eh, batterY | 22:04 |
| tjaalton | the keycode for battery when using kbd is 241, with evdev it's 244 | 22:06 |
| tjaalton | I guess "something" is hardcoded for 244 | 22:07 |
| tjaalton | actually, it's not the driver that matters, but the rules | 22:08 |
| tjaalton | no, it's the model after all | 22:09 |
| tjaalton | if I change rules xfree86->evdev, I get the nice keysym (XF86Foo), but the keycode is the same | 22:10 |
| tjaalton | this all with xec | 22:11 |
| tjaalton | uh, xev | 22:11 |
| tjaalton | hm, no.. changing the model doesn't change keycodes I get.. normal I guess | 22:13 |
| bryce | tjaalton: yeah keyboard troubleshooting is giving me headaches as well | 22:14 |
| bryce | ok, I see 244 for battery, and 213 for hibernate | 22:17 |
| bryce | hibernate maps to XF86Standby, but battery maps to XF86None or whatever | 22:17 |
| tjaalton | yeah battery is NoSymbol | 22:19 |
| bryce | btw, you mentioned that the keyboard not waking up bug is fixed upstream; have we pulled in that fix? If not, should we? | 22:19 |
| bryce | right NoSymbol (it scrolled out of my buffer) | 22:19 |
| tjaalton | yes we have, evdev master uploaded today ;) | 22:19 |
| tjaalton | including device properties | 22:20 |
| bryce | ok cool, I'm just holding off doing an upgrade until I get back home | 22:20 |
| tjaalton | nah, works flawlessly | 22:20 |
| bryce | alright so pitti is seeing the same key id's as me, 213/XF86Standby, and 244/NoSymbol | 22:20 |
| tjaalton | yes, and so am I | 22:20 |
| bryce | on a thinkpad? | 22:20 |
| bryce | lemme check with slangasek | 22:21 |
| tjaalton | there are also a couple of other hotkeys that don't seem to do anything | 22:21 |
| tjaalton | yes | 22:21 |
| tjaalton | and I don't know what they are supposed to do | 22:21 |
| bryce | which ones? | 22:21 |
| tjaalton | keycodes 200 (disable trackpoint, maybe) and 202 (eject?) | 22:22 |
| torkel | 202 is ejecting from dock iirc | 22:23 |
| tjaalton | also, there are functions behind the cursor keys (rew, ff, stop, play/pause), that have never worked | 22:23 |
| tjaalton | torkel: ok, makes sense | 22:23 |
| tjaalton | oh and zoom does nothing (fn-space) | 22:24 |
| torkel | neither does the thinkvantage button | 22:25 |
| tjaalton | yesh | 22:26 |
| tjaalton | -ah | 22:26 |
| tjaalton | damn, typos | 22:26 |
| torkel | or the power button | 22:26 |
| bryce | power button? o_O | 22:26 |
| tjaalton | right, it should open the logout prompt | 22:26 |
| bryce | tjaalton: of those, how many worked under hardy? | 22:27 |
| bryce | i.e., how many are regressed? | 22:27 |
| tjaalton | bryce: can't tell, don't remember :) | 22:27 |
| bryce | ok | 22:27 |
| torkel | bryce: at least mute, screenlock, suspend, hibernate, brightness | 22:28 |
| torkel | never used the other ones :-) | 22:28 |
| bryce | torkel: when you run xev, do those all give keycodes? | 22:28 |
| bryce | (and are they the appropriate keycodes?) | 22:29 |
| torkel | bryce: I get the same keycodes as tjaalton | 22:31 |
| torkel | bryce: I'm on intrepid too | 22:32 |
| tjaalton | the reason why xev doesn't show the radio button or zoom is that the scancode is >255 | 22:32 |
| torkel | radio button == Fn-F5? | 22:33 |
| tjaalton | yes | 22:34 |
| tjaalton | it works | 22:34 |
| bryce | tjaalton: ah interesting | 22:34 |
| torkel | that one works for me. It switches bluetooth on and off | 22:34 |
| tjaalton | yep | 22:35 |
| torkel | is that done in hardware? | 22:35 |
| tjaalton | running evtest on the device shows that there are a lot of scancodes not mapped to anything (in the kernel) | 22:35 |
| tjaalton | or, at least they don't have a fancy name there | 22:36 |
| bryce | I still see nothing from hotkeys via evtest | 22:37 |
| tjaalton | that's normal with evdev, since the driver steals them | 22:38 |
| tjaalton | same thing if you load the evbug module | 22:38 |
| tjaalton | it should print the events on dmesg | 22:38 |
| tjaalton | well, kernel log | 22:39 |
| bryce | tjaalton: slangasek is suggesting that with how fscked up all the acpi stuff is, we ought to have a uds blueprint just for getting all this mess documented as to how things *should* work | 22:39 |
| tjaalton | bryce: no shit :) | 22:39 |
| pwnguin | given that the laptop team is basically dad | 22:40 |
| pwnguin | dead | 22:40 |
| pwnguin | and the one guy who really knew acpi left for redhat | 22:40 |
| torkel | hm, I wonder if there are other bugs involved to. Because if I add Ctrl-Alt-L as shortcut for Lock Screen in gnome-keybinding-properties. It still doesn't lock the screen | 22:43 |
| torkel | same thing with mute | 22:45 |
| tjaalton | ctrl-alt-l works here | 22:46 |
| bryce | tjaalton: ok with evbug loaded, I still see no output for those keys | 22:49 |
| bryce | same with slangasek | 22:49 |
| tjaalton | bryce: just like I said?-) | 22:49 |
| tjaalton | oh.. I was unclear | 22:50 |
| tjaalton | it *should* print event on the log, but can't since the evdev driver steals them | 22:50 |
| tjaalton | events | 22:50 |
| tjaalton | readint thinkpad_acpi.c.. | 22:51 |
| tjaalton | -ing | 22:51 |
| tjaalton | damn, should get some sleep.. | 22:51 |
| bryce | right | 23:00 |
| tjaalton | ok, will continue tommor, night-> | 23:15 |
| bryce | tjaalton: see my latest comments on bug 267682 - slangasek and I think it's a kernel bug | 23:28 |
| ubottu | Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Triaged] https://launchpad.net/bugs/267682 | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!