[15:43] <james_w> tseliot: hi, do you have an opinion on bug 296809?
[15:45] <tseliot> james_w: yes, I talked to him and I suggested that we remove nvidia-xconfig since we already include it in the different nvidia-glx-* packages
[15:46] <james_w> oh, cool, I'll do a quick check and "sponsor" it
[15:47] <tseliot> ok, thanks
[19:45] <superm1> so when running xev, what does it mean when you get an extra line "XKeysymToKeycode returns keycode: ###" where ### is a number?  
[19:59] <jcristau> superm1: we get a keycode, run XLookupString, which gives us a keysym. that line is printed if XKeysymToKeycode on that keysym doesn't return the original keycode
[20:02] <superm1> jcristau, but why would that be occurring then?  would that mean that something is wrong with the assignment for keysyms <-> keycodes somewhere?
[20:03] <jcristau> might just mean that you have two keys with the same keysym assigned
[20:04] <jcristau> so not necessarily a problem
[20:04] <superm1> well at least nothing that i've intentionally assigned.  that's occurring for XF86Eject, which is seeming to be indicative of why gnome settings daemon is not reacting to the button press
[20:05] <jcristau>     state 0x0, keycode 170 (keysym 0x1008ff2c, XF86Eject), same_screen YES,
[20:05] <jcristau>     XKeysymToKeycode returns keycode: 169
[20:05] <jcristau> hmm.
[20:06] <superm1> okay so not just me then...
[20:06] <jcristau>     key <I169> {         [       XF86Eject ] };
[20:06] <jcristau>     key <I170> {         [       XF86Eject,       XF86Eject ] };
[20:09] <jcristau> correspond to the following in the kernel:
[20:09] <jcristau> #define KEY_EJECTCD             161
[20:09] <jcristau> #define KEY_EJECTCLOSECD        162
[20:09] <superm1> what's the difference supposed to be though?  I think hal is only providing granularity for one of them
[20:10] <superm1> i'd guess cdroms that have an eject and uneject button?
[20:10] <jcristau> probably
[20:10] <jcristau> X provides only XF86Eject, but the kernel has both
[20:11] <jcristau> g-s-d shouldn't care what the keycode is, though..
[20:11] <superm1> well commenting out /usr/share/X11/xkb/symbols/inet's reference to key <I169> and restarting X makes the eject button work again it appears
[20:11] <jcristau> sounds like a gnome bug then :)
[20:25] <superm1> okay i punted it off to gnome bug 561275 then so those guys can get things in order.  thanks for helping find the culprit jcristau :)
[20:28] <jcristau> np
[20:36] <superm1> ah well the reason that they were caring about the keycodes stands out now; XGrabKey needs to grab a code, can't go off of a sym ( http://tronche.com/gui/x/xlib/input/XGrabKey.html )
[20:37] <superm1> so the fact that XKeysymToKeycode only returns one code will likely be a troublesome problem to solve then
[20:41] <jcristau> ah. right..
[20:47] <jcristau> they should scan the keymap to find all relevant keycodes then
[20:47] <jcristau> i think