=== crevette_ is now known as crevette | ||
james_w | tseliot: hi, do you have an opinion on bug 296809? | 15:43 |
---|---|---|
ubottu | Launchpad bug 296809 in nvidia-xconfig "Please remove nvidia-xconfig (universe) from the repositories" [Wishlist,New] https://launchpad.net/bugs/296809 | 15:43 |
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:45 |
james_w | oh, cool, I'll do a quick check and "sponsor" it | 15:46 |
tseliot | ok, thanks | 15:47 |
superm1 | so when running xev, what does it mean when you get an extra line "XKeysymToKeycode returns keycode: ###" where ### is a number? | 19:45 |
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 | 19:59 |
superm1 | jcristau, but why would that be occurring then? would that mean that something is wrong with the assignment for keysyms <-> keycodes somewhere? | 20:02 |
jcristau | might just mean that you have two keys with the same keysym assigned | 20:03 |
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:04 |
jcristau | state 0x0, keycode 170 (keysym 0x1008ff2c, XF86Eject), same_screen YES, | 20:05 |
jcristau | XKeysymToKeycode returns keycode: 169 | 20:05 |
jcristau | hmm. | 20:05 |
superm1 | okay so not just me then... | 20:06 |
jcristau | key <I169> { [ XF86Eject ] }; | 20:06 |
jcristau | key <I170> { [ XF86Eject, XF86Eject ] }; | 20:06 |
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:09 |
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:10 |
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:11 |
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:25 |
ubottu | Gnome bug 561275 in plugins "eject key doesn't work when disks are mounted" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=561275 | 20:25 |
jcristau | np | 20:28 |
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:36 |
superm1 | so the fact that XKeysymToKeycode only returns one code will likely be a troublesome problem to solve then | 20:37 |
jcristau | ah. right.. | 20:41 |
jcristau | they should scan the keymap to find all relevant keycodes then | 20:47 |
jcristau | i think | 20:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!