/srv/irclogs.ubuntu.com/2008/11/17/#ubuntu-x.txt

=== crevette_ is now known as crevette
james_wtseliot: hi, do you have an opinion on bug 296809?15:43
ubottuLaunchpad bug 296809 in nvidia-xconfig "Please remove nvidia-xconfig (universe) from the repositories" [Wishlist,New] https://launchpad.net/bugs/29680915:43
tseliotjames_w: yes, I talked to him and I suggested that we remove nvidia-xconfig since we already include it in the different nvidia-glx-* packages15:45
james_woh, cool, I'll do a quick check and "sponsor" it15:46
tseliotok, thanks15:47
superm1so when running xev, what does it mean when you get an extra line "XKeysymToKeycode returns keycode: ###" where ### is a number?  19:45
jcristausuperm1: 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 keycode19:59
superm1jcristau, but why would that be occurring then?  would that mean that something is wrong with the assignment for keysyms <-> keycodes somewhere?20:02
jcristaumight just mean that you have two keys with the same keysym assigned20:03
jcristauso not necessarily a problem20:04
superm1well 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 press20:04
jcristau    state 0x0, keycode 170 (keysym 0x1008ff2c, XF86Eject), same_screen YES,20:05
jcristau    XKeysymToKeycode returns keycode: 16920:05
jcristauhmm.20:05
superm1okay so not just me then...20:06
jcristau    key <I169> {         [       XF86Eject ] };20:06
jcristau    key <I170> {         [       XF86Eject,       XF86Eject ] };20:06
jcristaucorrespond to the following in the kernel:20:09
jcristau#define KEY_EJECTCD             16120:09
jcristau#define KEY_EJECTCLOSECD        16220:09
superm1what's the difference supposed to be though?  I think hal is only providing granularity for one of them20:09
superm1i'd guess cdroms that have an eject and uneject button?20:10
jcristauprobably20:10
jcristauX provides only XF86Eject, but the kernel has both20:10
jcristaug-s-d shouldn't care what the keycode is, though..20:11
superm1well commenting out /usr/share/X11/xkb/symbols/inet's reference to key <I169> and restarting X makes the eject button work again it appears20:11
jcristausounds like a gnome bug then :)20:11
superm1okay 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:25
ubottuGnome bug 561275 in plugins "eject key doesn't work when disks are mounted" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=56127520:25
jcristaunp20:28
superm1ah 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:36
superm1so the fact that XKeysymToKeycode only returns one code will likely be a troublesome problem to solve then20:37
jcristauah. right..20:41
jcristauthey should scan the keymap to find all relevant keycodes then20:47
jcristaui think20:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!