[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Since chvt works, the problem must be the keymap



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.

Naturally, checking whether you are running the latest version of the
driver and taking a peek at it's change log is matter or course.

Let me know if this makes sense.

Thanks,
cga



Reply to: