On Sat, Jan 25, 2003 at 04:01:02PM -0500, Kevin Brosius wrote:
>David Dawes wrote:
>>
>>
>> On Sat, Jan 25, 2003 at 02:42:57PM -0500, Kevin Brosius wrote:
>> >I've upgraded a machine from an early version of 4.2.99 (.1 I think) and
>> >find a couple problems. I am unable to kill the server with
>> >Ctr-Alt-BkSpc as mentioned in several earlier list emails, although this
>> >problem is listed as resolved. Are there changes required in XF86Config
>> >or elsewhere to make this work? I expected XF86Config would be
>> >compatible with earlier versions of 4.2.99.x.
>>
>> It should still work with that keyboard config, and it does for me.
>> There have been some changes to allow the key sequences like this to be
>> redefined via XKB, but Joe added code recently to automatically fall
>> back to the built-in sequences when they're not defined in the XKB maps.
>> None of that should be a problem for a complete 4.2.99.4 installation.
>>
>> I noticed that your log file was also for the mouse auto-detect problem
>> you reported in a separate message. Have you confirmed that the two
>> things are not related (I don't see how they should be, but it's worth
>> checking if you haven't already)?
>>
>
>After changing the mouse protocol, the mouse works, but the server still
>cannot be killed with Ctr-Alt-BkSpc. I seem to have caught the more
>painful bugs, as I was unable to kill the server without a reboot (no
>keyboard sequence response and no mouse exit.)
>
>I thought the core server would terminate on a kill -SIGTERM or restart
>with kill -SUGHUP, but it ignored both of these. It was removed with a
>SIGKILL, however it did not go through the driver shutdown sequence,
>leaving the console unusable.
Those signals should work as you describe, but I often find 'kill
-SEGV' useful to kill the server cleanly when it's "stuck" somewhere :-).
Does the server work correctly other than the key sequence not
working? If it is stuck somewhere, it might explain both why
SIGTERM and SIGHUP didn't do anything and why the terminate key
sequence didn't work.
>> >Here are relevant sections of XF86Config:
>> >
>> >Section "ServerLayout"
>> > Identifier "XFree86 Configured"
>> > Screen 0 "Screen0" 0 0
>> > InputDevice "Mouse0" "CorePointer"
>> > InputDevice "Keyboard0" "CoreKeyboard"
>> >EndSection
>> >
>> >Section "InputDevice"
>> > Identifier "Keyboard0"
>> > Driver "keyboard"
>> >EndSection
>>
>> Try adding the following to your ServerLayout section:
>>
>> Option "HandleSpecialKeys" "Always"
>>
>> and see if that makes a difference. If it does, we'll need to track
>> down why either the XKB map isn't working or it's not falling back
>> correctly to the built-in settings.
>
>This option works, and Ctr-Alt-BkSpc shuts down the server as expected
>with it.
OK, that's useful information.
While checking, I found a problem that would show up when building
with XKB disabled, but that included a build failure. Here's a patch
that fixes that, but I don't know if it'll make any difference to
what you're seeing.
Could you send the 'xmodmap -pk' output? Are you running any
xmodmap script as part of your startx/xdm rc files that might be
re-mapping the BackSpace key?
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
Index: xf86Events.c
===================================================================
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Events.c,v
retrieving revision 3.142
diff -u -r3.142 xf86Events.c
--- xf86Events.c 2003/01/15 03:29:05 3.142
+++ xf86Events.c 2003/01/25 21:17:54
@@ -600,12 +600,11 @@
}
#endif /* defined (__sparc__) */
- if (
#ifdef XKB
- (xf86Info.ddxSpecialKeys == SKWhenNeeded &&
- !xf86Info.ActionKeyBindingsSet) || noXkbExtension ||
+ if ((xf86Info.ddxSpecialKeys == SKWhenNeeded &&
+ !xf86Info.ActionKeyBindingsSet) ||
+ noXkbExtension || xf86Info.ddxSpecialKeys == SKAlways) {
#endif
- xf86Info.ddxSpecialKeys == SKAlways) {
if (!(ModifierDown(ShiftMask)) &&
((ModifierDown(ControlMask | AltMask)) ||
(ModifierDown(ControlMask | AltLangMask))))
