On Sun, Apr 29, 2007 at 02:10:14PM -0400, cga2000 wrote: > On Sun, Apr 29, 2007 at 12:10:22PM EDT, Florian Kulzer wrote: > > On Sun, Apr 29, 2007 at 11:12:23 -0400, Amy Templeton wrote: > > > Andrew Sackville-West wrote: > > > > maybe you could wrap it in a script that was suid root, > > > > but I don't know about those things either. > > > > > > Fair enough. I guess I should probably find some time to > > > read up on this (I know relevant info. can be found in some > > > manpage I doubtless have installed, and I've seen stuff > > > about SUID on the internet when I was looking for something > > > completely unrelated). I think I'm actually going to just > > > look into making particular commands not need passwords with > > > sudo, since that could be useful in other realms as well and > > > it's something I've heard can be done. > > > > > > > Did we ever do xmodmap -pk | grep VT to confirm those line > > > > up properly? > > > > > > 'fraid so. And they definitely did match what they're > > > supposed to be. So much for a simple solution! > > > > It would be interesting to see which keycodes and keysyms are reported > > if you run "xev", press (and hold) both CTRL and ALT, and then press F1, > > F2, etc. Does xev really display the keycodes for the Fn keys and the > > keysyms "XF86_Switch_VT_n"? Are the hexadecimal keysym values the same > > as the ones that you get with "grep VT /usr/share/X11/XKeysymDB"? > > Another way of looking at it is that _unless I am totally misunderstand > how these things work_ .. the CTRL+Alt.. sequence invokes "X server" > code and the "disconnection" from the VT as Andrew nicely put it, is > eventually processed (in part at least) by your card's driver .. whereas > with "chvt" it is code that lives in the kernel that is invoked. > > Hence a buggy video card driver could cause CTRL+Alt.. to fail on a > system where chvt works.. Regardless of keyboard mapping .. > > The "logic" :-) behind this embarrassing guesswork of mine is that I > have experienced this kind of problem with embedded chips (together with > a slew of other issues) in cases where the driver was clearly described > as immature in the (then) xfree86 doc. > > That's why I suggested .. possibly in another recent thread on a similar > subject .. was it an nvidia card then? .. switching to the VESA driver > just to see if it makes any difference. I don't know enough to answer this, but its certainly painless to try it. A
Attachment:
signature.asc
Description: Digital signature