Winston <wbe@UBEBLOCK.psr.com.invalid> writes:

The other thing I'd try, just because it's easy, is to remove the
"exec ".

Before doing that, try reading /var/log/Xorg.?.log.old (typically Xorg.0.log.old). A clean shutdown might end like:

[1225319.579] (II) config/devd: kbdmux is enabled, ignoring device ukbd0 [1225319.608] (II) config/devd: ignoring device uhid2
[2332926.247] (II) config/devd: terminating backend...
[2332926.265] (II) UnloadModule: "mouse"
[2332926.265] (II) UnloadModule: "kbd"
[2332926.680] (II) Server terminated successfully (0). Closing log file.

Earlier in the log file, you'll probably find keyboard related messages
such as:

[ 4303.450] (II) config/devd: probing input devices...
[ 4303.450] (II) config/devd: adding input device (null) (/dev/kbdmux)
[ 4303.450] (II) LoadModule: "kbd"
[ 4303.451] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[ 4303.451] (II) Module kbd: vendor="X.Org Foundation"
[ 4303.451] compiled for 1.18.4, module version = 1.9.0
[ 4303.451] Module class: X.Org XInput Driver
[ 4303.451] ABI class: X.Org XInput driver, version 22.1
[ 4303.451] (II) Using input driver 'kbd' for 'kbdmux'
[ 4303.451] (**) kbdmux: always reports core events
[ 4303.451] (**) kbdmux: always reports core events
[ 4303.451] (**) Option "Protocol" "standard"
[ 4303.451] (**) Option "XkbRules" "base"
[ 4303.451] (**) Option "XkbModel" "pc105"
[ 4303.452] (**) Option "XkbLayout" "us"
[ 4303.452] (**) Option "config_info" "devd:kbdmux"
[ 4303.452] (II) XINPUT: Adding extended input device "kbdmux" (type: KEYBOARD, id 6)
[ 4303.452] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[ 4303.452] (II) config/devd: kbdmux is enabled, ignoring device atkbd0

Perhaps your X log file will have something that indicates why your
keyboard stopped working.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Previously, Louis Epstein <le@top.put.com> posted his .xinitrc, which
ended with:

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

I replied:

Ah, okay, that explains it. The foreground command is indeed last and
here is "exec xterm".

So the xterm window named "login" is the one whose end causes X to shut
everything down. Presumably you do that with "exit" or "logout" or
Control+left-mouse-press menu Quit or the like in the "login" window.

So, back to your earlier problem... Have you been ending your X
sessions by having the "login" window exit? Does stopping that way
leave your keyboard working?

Louis Epstein <le@top.put.com> replied:

I had not tried that,but now I did,and yes,it has the same effect of
the screen going blank but for a flashing cursor in the upper left and
the keyboard no longer being read.

Foo. And, IIRC, you said earlier that Ctrl+Alt+F1 and the like to
switch to a different virtual console didn't work at that point either.

Just thought of a possible hack: if you have a USB keyboard, after
things are dead, any chance unplugging the keyboard, waiting a moment,
and plugging it back in gets it working again? Not really a solution,
but perhaps better than rebooting if it works.

The other thing I'd try, just because it's easy, is to remove the
"exec ". By itself, that probably won't help, but it would let you add commands at the end when it's about to quit and write the output to a
file. E.g.,

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
xterm -geometry 80x66+0+0 -name login
(sleep 10; ps aguwx >$HOME/foo; dmesg >>$HOME/foo) &

Using '&' allows the .xinitrc script to finish so X shuts down, (which generally happens pretty quickly) and then 8-9 seconds later records
what's still running and the recent console messages, which maybe will
provide some clue as to what's hung.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

Winston <wbe@UBEBLOCK.psr.com.invalid> writes:

The other thing I'd try, just because it's easy, is to remove the
"exec ".

Before doing that, try reading /var/log/Xorg.?.log.old (typically Xorg.0.log.old). A clean shutdown might end like:

[1225319.579] (II) config/devd: kbdmux is enabled, ignoring device ukbd0 [1225319.608] (II) config/devd: ignoring device uhid2
[2332926.247] (II) config/devd: terminating backend...
[2332926.265] (II) UnloadModule: "mouse"
[2332926.265] (II) UnloadModule: "kbd"
[2332926.680] (II) Server terminated successfully (0). Closing log file.

Earlier in the log file, you'll probably find keyboard related messages
such as:

[ 4303.450] (II) config/devd: probing input devices...
[ 4303.450] (II) config/devd: adding input device (null) (/dev/kbdmux)
[ 4303.450] (II) LoadModule: "kbd"
[ 4303.451] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[ 4303.451] (II) Module kbd: vendor="X.Org Foundation"
[ 4303.451] compiled for 1.18.4, module version = 1.9.0
[ 4303.451] Module class: X.Org XInput Driver
[ 4303.451] ABI class: X.Org XInput driver, version 22.1
[ 4303.451] (II) Using input driver 'kbd' for 'kbdmux'
[ 4303.451] (**) kbdmux: always reports core events
[ 4303.451] (**) kbdmux: always reports core events
[ 4303.451] (**) Option "Protocol" "standard"
[ 4303.451] (**) Option "XkbRules" "base"
[ 4303.451] (**) Option "XkbModel" "pc105"
[ 4303.452] (**) Option "XkbLayout" "us"
[ 4303.452] (**) Option "config_info" "devd:kbdmux"
[ 4303.452] (II) XINPUT: Adding extended input device "kbdmux" (type: KEYBOARD, id 6)
[ 4303.452] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[ 4303.452] (II) config/devd: kbdmux is enabled, ignoring device atkbd0

Perhaps your X log file will have something that indicates why your
keyboard stopped working.
-WBE

Here is a tail -99 /var/log/Xorg.0.log.old:

[ 36993.553] (II) VESA(0): VESA VBE OEM Software Rev: 15.21
[ 36993.553] (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2010, Advanced Micro Devices, Inc.
[ 36993.553] (II) VESA(0): VESA VBE OEM Product: VERDE
[ 36993.553] (II) VESA(0): VESA VBE OEM Product Rev: 01.00
[ 36993.554] (II) VESA(0): virtual address = 0x807600000, VGAbase = 0x8008eb000
physical address = 0xe0000000, size = 16777216
[ 36993.634] (II) VESA(0): Setting up VESA Mode 0x1D4 (1920x1200)
[ 36993.634] (II) VESA(0): VBESetVBEMode failed, mode set without customized refresh.
[ 36993.761] (==) VESA(0): Default visual is TrueColor
[ 36993.762] (==) VESA(0): Backing store enabled
[ 36993.763] (==) VESA(0): DPMS enabled
[ 36993.763] (II) Initializing extension Generic Event Extension
[ 36993.764] (II) Initializing extension SHAPE
[ 36993.764] (II) Initializing extension MIT-SHM
[ 36993.764] (II) Initializing extension XInputExtension
[ 36993.765] (II) Initializing extension XTEST
[ 36993.765] (II) Initializing extension BIG-REQUESTS
[ 36993.765] (II) Initializing extension SYNC
[ 36993.766] (II) Initializing extension XKEYBOARD
[ 36993.767] (II) Initializing extension XC-MISC
[ 36993.767] (II) Initializing extension SECURITY
[ 36993.767] (II) Initializing extension XFIXES
[ 36993.767] (II) Initializing extension RENDER
[ 36993.767] (II) Initializing extension RANDR
[ 36993.768] (II) Initializing extension COMPOSITE
[ 36993.768] (II) Initializing extension DAMAGE
[ 36993.768] (II) Initializing extension MIT-SCREEN-SAVER
[ 36993.769] (II) Initializing extension DOUBLE-BUFFER
[ 36993.769] (II) Initializing extension RECORD
[ 36993.769] (II) Initializing extension DPMS
[ 36993.769] (II) Initializing extension Present
[ 36993.769] (II) Initializing extension DRI3
[ 36993.770] (II) Initializing extension X-Resource
[ 36993.770] (II) Initializing extension XVideo
[ 36993.770] (II) Initializing extension XVideo-MotionCompensation
[ 36993.770] (II) Initializing extension GLX
[ 36993.770] (II) AIGLX: Screen 0 is not DRI2 capable
[ 36994.022] (II) IGLX: Loaded and initialized swrast
[ 36994.022] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 36994.022] (II) Initializing extension XFree86-VidModeExtension
[ 36994.023] (II) Initializing extension XFree86-DGA
[ 36994.023] (II) Initializing extension XFree86-DRI
[ 36994.023] (II) Initializing extension DRI2
[ 36994.146] (II) config/devd: probing input devices...
[ 36994.146] (II) config/devd: adding input device /dev/kbdmux0
[ 36994.146] (II) LoadModule: "kbd"
[ 36994.147] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[ 36994.147] (II) Module kbd: vendor="X.Org Foundation"
[ 36994.147] compiled for 1.20.7, module version = 1.9.0
[ 36994.147] Module class: X.Org XInput Driver
[ 36994.147] ABI class: X.Org XInput driver, version 24.1
[ 36994.147] (II) Using input driver 'kbd' for 'kbdmux0'
[ 36994.147] (**) kbdmux0: always reports core events
[ 36994.147] (**) kbdmux0: always reports core events
[ 36994.147] (**) Option "Protocol" "standard"
[ 36994.147] (**) Option "XkbRules" "base"
[ 36994.147] (**) Option "XkbModel" "pc105"
[ 36994.147] (**) Option "XkbLayout" "us"
[ 36994.147] (**) Option "config_info" "devd:/dev/kbdmux0"
[ 36994.147] (II) XINPUT: Adding extended input device "kbdmux0" (type: KEYBOARD, id 6)
[ 36994.148] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
[ 36994.148] (II) config/devd: kbdmux is enabled, ignoring device kbdmux0
[ 36994.148] (II) config/devd: detected mouse: hwid=0000, model=0000, type=0000, iftype=0004, buttons=10
[ 36994.148] (II) config/devd: adding input device /dev/sysmouse
[ 36994.148] (II) LoadModule: "mouse"
[ 36994.148] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
[ 36994.149] (II) Module mouse: vendor="X.Org Foundation"
[ 36994.149] compiled for 1.20.7, module version = 1.9.3
[ 36994.149] Module class: X.Org XInput Driver
[ 36994.149] ABI class: X.Org XInput driver, version 24.1
[ 36994.149] (II) Using input driver 'mouse' for 'sysmouse'
[ 36994.149] (**) sysmouse: always reports core events
[ 36994.149] (**) Option "Device" "/dev/sysmouse"
[ 36994.149] (==) sysmouse: Protocol: "Auto"
[ 36994.149] (**) sysmouse: always reports core events
[ 36994.149] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50
[ 36994.149] (**) sysmouse: ZAxisMapping: buttons 4 and 5
[ 36994.149] (**) sysmouse: Buttons: 5
[ 36994.149] (**) Option "config_info" "devd:/dev/sysmouse"
[ 36994.149] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7)
[ 36994.149] (**) sysmouse: (accel) keeping acceleration scheme 1
[ 36994.149] (**) sysmouse: (accel) acceleration profile 0
[ 36994.149] (**) sysmouse: (accel) acceleration factor: 2.000
[ 36994.149] (**) sysmouse: (accel) acceleration threshold: 4
[ 36994.149] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[ 36994.149] (II) sysmouse: SetupAuto: protocol is SysMouse
[ 36994.149] (II) config/devd: detected USB HID of unknown type
[ 36994.149] (II) config/devd: [sysctl] usb_id: 0x046d:0xc31d
[ 36994.149] (II) config/devd: [sysctl] vendor: USB, product: Keyboard
[ 36994.149] (II) config/devd: adding input device /dev/uhid0
[ 36994.149] (II) No input driver specified, ignoring this device.
[ 36994.149] (II) This device may have been added with another device file.
[ 36994.149] (EE) config/devd: error 1 adding device /dev/uhid0
[ 36994.149] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[ 36994.149] (WW) config/devd: device /dev/ums0 already opened
[ 37012.636] (II) config/devd: terminating backend...
[ 37012.642] (II) UnloadModule: "mouse"
[ 37012.642] (II) UnloadModule: "kbd"
[ 37012.837] (II) Server terminated successfully (0). Closing log file.


-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

Previously, Louis Epstein <le@top.put.com> posted his .xinitrc, which
ended with:

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

I replied:

Ah, okay, that explains it. The foreground command is indeed last and
here is "exec xterm".

So the xterm window named "login" is the one whose end causes X to shut
everything down. Presumably you do that with "exit" or "logout" or
Control+left-mouse-press menu Quit or the like in the "login" window.

So, back to your earlier problem... Have you been ending your X
sessions by having the "login" window exit? Does stopping that way
leave your keyboard working?

Louis Epstein <le@top.put.com> replied:

I had not tried that,but now I did,and yes,it has the same effect of
the screen going blank but for a flashing cursor in the upper left and
the keyboard no longer being read.

Foo. And, IIRC, you said earlier that Ctrl+Alt+F1 and the like to
switch to a different virtual console didn't work at that point either.

Just thought of a possible hack: if you have a USB keyboard, after
things are dead, any chance unplugging the keyboard, waiting a moment,
and plugging it back in gets it working again? Not really a solution,
but perhaps better than rebooting if it works.

Unplug-replug of the keyboard does NOT make the machine read it
after the exit-hang.

The other thing I'd try, just because it's easy, is to remove the
"exec ". By itself, that probably won't help, but it would let you add commands at the end when it's about to quit and write the output to a
file. E.g.,

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
xterm -geometry 80x66+0+0 -name login
(sleep 10; ps aguwx >$HOME/foo; dmesg >>$HOME/foo) &

Using '&' allows the .xinitrc script to finish so X shuts down, (which generally happens pretty quickly) and then 8-9 seconds later records
what's still running and the recent console messages, which maybe will provide some clue as to what's hung.
-WBE

Will tinker.

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously suggested:

Just thought of a possible hack: if you have a USB keyboard, after
things are dead, any chance unplugging the keyboard, waiting a moment,
and plugging it back in gets it working again? Not really a solution,
but perhaps better than rebooting if it works.

Louis Epstein <le@top.put.com> writes:

Unplug-replug of the keyboard does NOT make the machine read it
after the exit-hang.

That's with a USB keyboard? If it is, and ifyou have a second USB
keyboard, maybe try plugging that in while the first one is plugged in...
-WBE

[After reading your Xorg.0.log.old file, I'm not sure whether your
keyboard is USB or old-style PC-AT plug.]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously posted:

[...] try reading /var/log/Xorg.?.log.old (typically
Xorg.0.log.old). A clean shutdown might end like:

[redacted]

Earlier in the log file, you'll probably find keyboard related
messages such as:

[redacted]

Perhaps your X log file will have something that indicates why your
keyboard stopped working.

Louis Epstein <le@top.put.com> posted in reply:

Here is a tail -99 /var/log/Xorg.0.log.old:

A couple of things catch my eye, but I can't say for sure that they're wrong. They just look odd to me.

[ 36993.553] (II) VESA(0): VESA VBE OEM Software Rev: 15.21
[ 36993.553] (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2010, Advanced Micro Devices, Inc.
[ 36993.553] (II) VESA(0): VESA VBE OEM Product: VERDE
[ 36993.553] (II) VESA(0): VESA VBE OEM Product Rev: 01.00
[ 36993.554] (II) VESA(0): virtual address = 0x807600000, VGAbase = 0x8008eb000
physical address = 0xe0000000, size = 16777216
[ 36993.634] (II) VESA(0): Setting up VESA Mode 0x1D4 (1920x1200)
[ 36993.634] (II) VESA(0): VBESetVBEMode failed, mode set without customized refresh.
[ 36993.761] (==) VESA(0): Default visual is TrueColor
[ 36993.762] (==) VESA(0): Backing store enabled
[ 36993.763] (==) VESA(0): DPMS enabled
[ 36993.763] (II) Initializing extension Generic Event Extension
[ 36993.764] (II) Initializing extension SHAPE
[ 36993.764] (II) Initializing extension MIT-SHM
[ 36993.764] (II) Initializing extension XInputExtension
[ 36993.765] (II) Initializing extension XTEST
[ 36993.765] (II) Initializing extension BIG-REQUESTS
[ 36993.765] (II) Initializing extension SYNC
[ 36993.766] (II) Initializing extension XKEYBOARD
[ 36993.767] (II) Initializing extension XC-MISC
[ 36993.767] (II) Initializing extension SECURITY
[ 36993.767] (II) Initializing extension XFIXES
[ 36993.767] (II) Initializing extension RENDER
[ 36993.767] (II) Initializing extension RANDR
[ 36993.768] (II) Initializing extension COMPOSITE
[ 36993.768] (II) Initializing extension DAMAGE
[ 36993.768] (II) Initializing extension MIT-SCREEN-SAVER
[ 36993.769] (II) Initializing extension DOUBLE-BUFFER
[ 36993.769] (II) Initializing extension RECORD
[ 36993.769] (II) Initializing extension DPMS
[ 36993.769] (II) Initializing extension Present
[ 36993.769] (II) Initializing extension DRI3
[ 36993.770] (II) Initializing extension X-Resource
[ 36993.770] (II) Initializing extension XVideo
[ 36993.770] (II) Initializing extension XVideo-MotionCompensation
[ 36993.770] (II) Initializing extension GLX
[ 36993.770] (II) AIGLX: Screen 0 is not DRI2 capable
[ 36994.022] (II) IGLX: Loaded and initialized swrast
[ 36994.022] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 36994.022] (II) Initializing extension XFree86-VidModeExtension
[ 36994.023] (II) Initializing extension XFree86-DGA
[ 36994.023] (II) Initializing extension XFree86-DRI
[ 36994.023] (II) Initializing extension DRI2
[ 36994.146] (II) config/devd: probing input devices...
[ 36994.146] (II) config/devd: adding input device /dev/kbdmux0

Hmm: yours says kbdmux0 rather than kbdmux.

[ 36994.146] (II) LoadModule: "kbd"
[ 36994.147] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[ 36994.147] (II) Module kbd: vendor="X.Org Foundation"
[ 36994.147] compiled for 1.20.7, module version = 1.9.0
[ 36994.147] Module class: X.Org XInput Driver
[ 36994.147] ABI class: X.Org XInput driver, version 24.1
[ 36994.147] (II) Using input driver 'kbd' for 'kbdmux0'
[ 36994.147] (**) kbdmux0: always reports core events
[ 36994.147] (**) kbdmux0: always reports core events
[ 36994.147] (**) Option "Protocol" "standard"
[ 36994.147] (**) Option "XkbRules" "base"
[ 36994.147] (**) Option "XkbModel" "pc105"
[ 36994.147] (**) Option "XkbLayout" "us"
[ 36994.147] (**) Option "config_info" "devd:/dev/kbdmux0"
[ 36994.147] (II) XINPUT: Adding extended input device "kbdmux0" (type: KEYBOARD, id 6)
[ 36994.148] (II) config/devd: kbdmux is enabled, ignoring device atkbd0

Through here looks OK to me, though maybe I missed something.
What I think I'm seeing is that there's not a USB keyboard.

[ 36994.148] (II) config/devd: kbdmux is enabled, ignoring device kbdmux0

Now that looks strange to me. I'm used to seeing ukbd0 and atkbd0 being ignored, but kbdmux0? Not sure what to make of that.

[ 36994.148] (II) config/devd: detected mouse: hwid=0000, model=0000, type=0000, iftype=0004,
buttons=10
[ 36994.148] (II) config/devd: adding input device /dev/sysmouse
[ 36994.148] (II) LoadModule: "mouse"
[ 36994.148] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
[ 36994.149] (II) Module mouse: vendor="X.Org Foundation"
[ 36994.149] compiled for 1.20.7, module version = 1.9.3
[ 36994.149] Module class: X.Org XInput Driver
[ 36994.149] ABI class: X.Org XInput driver, version 24.1
[ 36994.149] (II) Using input driver 'mouse' for 'sysmouse'
[ 36994.149] (**) sysmouse: always reports core events
[ 36994.149] (**) Option "Device" "/dev/sysmouse"
[ 36994.149] (==) sysmouse: Protocol: "Auto"
[ 36994.149] (**) sysmouse: always reports core events
[ 36994.149] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50
[ 36994.149] (**) sysmouse: ZAxisMapping: buttons 4 and 5
[ 36994.149] (**) sysmouse: Buttons: 5
[ 36994.149] (**) Option "config_info" "devd:/dev/sysmouse"
[ 36994.149] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7)
[ 36994.149] (**) sysmouse: (accel) keeping acceleration scheme 1
[ 36994.149] (**) sysmouse: (accel) acceleration profile 0
[ 36994.149] (**) sysmouse: (accel) acceleration factor: 2.000
[ 36994.149] (**) sysmouse: (accel) acceleration threshold: 4
[ 36994.149] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[ 36994.149] (II) sysmouse: SetupAuto: protocol is SysMouse

[ 36994.149] (II) config/devd: detected USB HID of unknown type
[ 36994.149] (II) config/devd: [sysctl] usb_id: 0x046d:0xc31d
[ 36994.149] (II) config/devd: [sysctl] vendor: USB, product: Keyboard

Those 3 lines look like it didn't properly recognize a USB keyboard.

[ 36994.149] (II) config/devd: adding input device /dev/uhid0
[ 36994.149] (II) No input driver specified, ignoring this device.
[ 36994.149] (II) This device may have been added with another device file.
[ 36994.149] (EE) config/devd: error 1 adding device /dev/uhid0

And this says there was an error. When you're successfully typing in an
X window, are you using a USB keyboard?

[ 36994.149] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[ 36994.149] (WW) config/devd: device /dev/ums0 already opened
[ 37012.636] (II) config/devd: terminating backend...
[ 37012.642] (II) UnloadModule: "mouse"
[ 37012.642] (II) UnloadModule: "kbd"
[ 37012.837] (II) Server terminated successfully (0). Closing log file.

Good: X terminated cleanly, so that's not the problem.

I'm running low on ideas, so I hope the updated xorg-server code fixes
things. :-)

Can you switch virtual consoles while X is still running? If not, check
your xorg.conf for this option:

'man Xorg' says:
Ctrl+Alt+F1...F12
For systems with virtual terminal support, these keystroke
combinations are used to switch to virtual terminals 1 through
12, respectively. This can be disabled with the DontVTSwitch
xorg.conf(5) file option.


Another thing to try would be to run (as root, while X isn't running)

xorg -configure

and compare the xorg.conf file it generates in the current directory
with your xorg.conf. They probably won't match exactly, but the
differences should be sensible.


In a different subset of this thread, Louis wrote:

I have been testing X on the third terminal session (i.e. Ctrl Alt F3)
with xinit openttd (launching a game only if it works correctly)
and the second (Ctrl Alt F2) with startx (launching a window manager
if it works correctly) while reserving the Ctrl Alt F1 session for
a root login that does CLI administrative tasks.
When X hangs I find the Ctrl-Alt commands don't switch sessions now;
formerly they did and I could return to the aborted session and
see the error message described earlier.

Does the keyboard work after exiting if you log in as you on Ctrl Alt F1?
I've never had occasion to try running X from any of the other virtual consoles, so I don't know how well or poorly that works. It sounds like running X from other virtual terminals used to work for you, though.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously posted:

[...] try reading /var/log/Xorg.?.log.old (typically
Xorg.0.log.old). A clean shutdown might end like:

[redacted]

Earlier in the log file, you'll probably find keyboard related
messages such as:

[redacted]

Perhaps your X log file will have something that indicates why your
keyboard stopped working.

Louis Epstein <le@top.put.com> posted in reply:

Here is a tail -99 /var/log/Xorg.0.log.old:

A couple of things catch my eye, but I can't say for sure that they're wrong. They just look odd to me.

[ 36993.553] (II) VESA(0): VESA VBE OEM Software Rev: 15.21
[ 36993.553] (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2010, Advanced Micro Devices, Inc.
[ 36993.553] (II) VESA(0): VESA VBE OEM Product: VERDE
[ 36993.553] (II) VESA(0): VESA VBE OEM Product Rev: 01.00
[ 36993.554] (II) VESA(0): virtual address = 0x807600000, VGAbase = 0x8008eb000
physical address = 0xe0000000, size = 16777216
[ 36993.634] (II) VESA(0): Setting up VESA Mode 0x1D4 (1920x1200)
[ 36993.634] (II) VESA(0): VBESetVBEMode failed, mode set without customized refresh.
[ 36993.761] (==) VESA(0): Default visual is TrueColor
[ 36993.762] (==) VESA(0): Backing store enabled
[ 36993.763] (==) VESA(0): DPMS enabled
[ 36993.763] (II) Initializing extension Generic Event Extension
[ 36993.764] (II) Initializing extension SHAPE
[ 36993.764] (II) Initializing extension MIT-SHM
[ 36993.764] (II) Initializing extension XInputExtension
[ 36993.765] (II) Initializing extension XTEST
[ 36993.765] (II) Initializing extension BIG-REQUESTS
[ 36993.765] (II) Initializing extension SYNC
[ 36993.766] (II) Initializing extension XKEYBOARD
[ 36993.767] (II) Initializing extension XC-MISC
[ 36993.767] (II) Initializing extension SECURITY
[ 36993.767] (II) Initializing extension XFIXES
[ 36993.767] (II) Initializing extension RENDER
[ 36993.767] (II) Initializing extension RANDR
[ 36993.768] (II) Initializing extension COMPOSITE
[ 36993.768] (II) Initializing extension DAMAGE
[ 36993.768] (II) Initializing extension MIT-SCREEN-SAVER
[ 36993.769] (II) Initializing extension DOUBLE-BUFFER
[ 36993.769] (II) Initializing extension RECORD
[ 36993.769] (II) Initializing extension DPMS
[ 36993.769] (II) Initializing extension Present
[ 36993.769] (II) Initializing extension DRI3
[ 36993.770] (II) Initializing extension X-Resource
[ 36993.770] (II) Initializing extension XVideo
[ 36993.770] (II) Initializing extension XVideo-MotionCompensation
[ 36993.770] (II) Initializing extension GLX
[ 36993.770] (II) AIGLX: Screen 0 is not DRI2 capable
[ 36994.022] (II) IGLX: Loaded and initialized swrast
[ 36994.022] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 36994.022] (II) Initializing extension XFree86-VidModeExtension
[ 36994.023] (II) Initializing extension XFree86-DGA
[ 36994.023] (II) Initializing extension XFree86-DRI
[ 36994.023] (II) Initializing extension DRI2
[ 36994.146] (II) config/devd: probing input devices...
[ 36994.146] (II) config/devd: adding input device /dev/kbdmux0

Hmm: yours says kbdmux0 rather than kbdmux.

[ 36994.146] (II) LoadModule: "kbd"
[ 36994.147] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[ 36994.147] (II) Module kbd: vendor="X.Org Foundation"
[ 36994.147] compiled for 1.20.7, module version = 1.9.0
[ 36994.147] Module class: X.Org XInput Driver
[ 36994.147] ABI class: X.Org XInput driver, version 24.1
[ 36994.147] (II) Using input driver 'kbd' for 'kbdmux0'
[ 36994.147] (**) kbdmux0: always reports core events
[ 36994.147] (**) kbdmux0: always reports core events
[ 36994.147] (**) Option "Protocol" "standard"
[ 36994.147] (**) Option "XkbRules" "base"
[ 36994.147] (**) Option "XkbModel" "pc105"
[ 36994.147] (**) Option "XkbLayout" "us"
[ 36994.147] (**) Option "config_info" "devd:/dev/kbdmux0"
[ 36994.147] (II) XINPUT: Adding extended input device "kbdmux0" (type: KEYBOARD, id 6)
[ 36994.148] (II) config/devd: kbdmux is enabled, ignoring device atkbd0

Through here looks OK to me, though maybe I missed something.
What I think I'm seeing is that there's not a USB keyboard.

[ 36994.148] (II) config/devd: kbdmux is enabled, ignoring device kbdmux0

Now that looks strange to me. I'm used to seeing ukbd0 and atkbd0 being ignored, but kbdmux0? Not sure what to make of that.

[ 36994.148] (II) config/devd: detected mouse: hwid=0000, model=0000, type=0000, iftype=0004,
buttons=10
[ 36994.148] (II) config/devd: adding input device /dev/sysmouse
[ 36994.148] (II) LoadModule: "mouse"
[ 36994.148] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
[ 36994.149] (II) Module mouse: vendor="X.Org Foundation"
[ 36994.149] compiled for 1.20.7, module version = 1.9.3
[ 36994.149] Module class: X.Org XInput Driver
[ 36994.149] ABI class: X.Org XInput driver, version 24.1
[ 36994.149] (II) Using input driver 'mouse' for 'sysmouse'
[ 36994.149] (**) sysmouse: always reports core events
[ 36994.149] (**) Option "Device" "/dev/sysmouse"
[ 36994.149] (==) sysmouse: Protocol: "Auto"
[ 36994.149] (**) sysmouse: always reports core events
[ 36994.149] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50
[ 36994.149] (**) sysmouse: ZAxisMapping: buttons 4 and 5
[ 36994.149] (**) sysmouse: Buttons: 5
[ 36994.149] (**) Option "config_info" "devd:/dev/sysmouse"
[ 36994.149] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7)
[ 36994.149] (**) sysmouse: (accel) keeping acceleration scheme 1
[ 36994.149] (**) sysmouse: (accel) acceleration profile 0
[ 36994.149] (**) sysmouse: (accel) acceleration factor: 2.000
[ 36994.149] (**) sysmouse: (accel) acceleration threshold: 4
[ 36994.149] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[ 36994.149] (II) sysmouse: SetupAuto: protocol is SysMouse

[ 36994.149] (II) config/devd: detected USB HID of unknown type
[ 36994.149] (II) config/devd: [sysctl] usb_id: 0x046d:0xc31d
[ 36994.149] (II) config/devd: [sysctl] vendor: USB, product: Keyboard

Those 3 lines look like it didn't properly recognize a USB keyboard.

[ 36994.149] (II) config/devd: adding input device /dev/uhid0
[ 36994.149] (II) No input driver specified, ignoring this device.
[ 36994.149] (II) This device may have been added with another device file. >> [ 36994.149] (EE) config/devd: error 1 adding device /dev/uhid0

And this says there was an error. When you're successfully typing in an
X window, are you using a USB keyboard?

[ 36994.149] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[ 36994.149] (WW) config/devd: device /dev/ums0 already opened
[ 37012.636] (II) config/devd: terminating backend...
[ 37012.642] (II) UnloadModule: "mouse"
[ 37012.642] (II) UnloadModule: "kbd"
[ 37012.837] (II) Server terminated successfully (0). Closing log file.

Good: X terminated cleanly, so that's not the problem.

I'm running low on ideas, so I hope the updated xorg-server code fixes things. :-)

It didn't.

In a different subset of this thread, Louis wrote:

I have been testing X on the third terminal session (i.e. Ctrl Alt F3) >>>> with xinit openttd (launching a game only if it works correctly)
and the second (Ctrl Alt F2) with startx (launching a window manager
if it works correctly) while reserving the Ctrl Alt F1 session for
a root login that does CLI administrative tasks.
When X hangs I find the Ctrl-Alt commands don't switch sessions now;
formerly they did and I could return to the aborted session and
see the error message described earlier.

Does the keyboard work after exiting if you log in as you on Ctrl Alt F1?

Have not tried that.

I've never had occasion to try running X from any of the other virtual consoles, so I don't know how well or poorly that works. It sounds like running X from other virtual terminals used to work for you, though.
-WBE

It did.

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously suggested:

Just thought of a possible hack: if you have a USB keyboard, after
things are dead, any chance unplugging the keyboard, waiting a moment,
and plugging it back in gets it working again? Not really a solution,
but perhaps better than rebooting if it works.

Louis Epstein <le@top.put.com> writes:

Unplug-replug of the keyboard does NOT make the machine read it
after the exit-hang.

That's with a USB keyboard? If it is, and ifyou have a second USB
keyboard, maybe try plugging that in while the first one is plugged in...
-WBE

[After reading your Xorg.0.log.old file, I'm not sure whether your
keyboard is USB or old-style PC-AT plug.]

It's a Logitech Media Keyboard K200 and USB is in the specs.

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously posted:

Louis Epstein <le@top.put.com> posted in reply:

I'm running low on ideas, so I hope the updated xorg-server code fixes things. :-)

Can you switch virtual consoles while X is still running? If not, check
your xorg.conf for this option:

'man Xorg' says:
Ctrl+Alt+F1...F12
For systems with virtual terminal support, these keystroke
combinations are used to switch to virtual terminals 1 through
12, respectively. This can be disabled with the DontVTSwitch
xorg.conf(5) file option.

Another thing to try would be to run (as root, while X isn't running)

xorg -configure

and compare the xorg.conf file it generates in the current directory
with your xorg.conf. They probably won't match exactly, but the
differences should be sensible.

So here's xorg.conf (modified previously by your suggestion of
the vesa over the radeon driver).

Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath "/usr/local/lib/xorg/modules"
FontPath "/usr/local/share/fonts/misc/"
FontPath "/usr/local/share/fonts/TTF/"
FontPath "/usr/local/share/fonts/OTF/"
FontPath "/usr/local/share/fonts/Type1/"
FontPath "/usr/local/share/fonts/100dpi/"
FontPath "/usr/local/share/fonts/75dpi/"
FontPath "/usr/local/share/fonts/TrueType/"
FontPath "/usr/local/share/fonts/adobe-cmaps/"
FontPath "/usr/local/share/fonts/cantarell/"
FontPath "/usr/local/share/fonts/cyrillic/"
FontPath "/usr/local/share/fonts/noto-lite/"
FontPath "/usr/local/share/fonts/std.ja_JP/"
FontPath "/usr/local/share/fonts/std.zh_CN/"
FontPath "/usr/local/share/fonts/dejavu/"
FontPath "/usr/local/share/fonts/encodings/"
FontPath "/usr/local/share/fonts/util/"
EndSection

Section "Module"
Load "glx"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/sysmouse"
Option "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "LA2405x"
EndSection

Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
### <percent>: "<f>%"
### [arg]: arg optional
#Option "Accel" # [<bool>]
#Option "SWcursor" # [<bool>]
#Option "EnablePageFlip" # [<bool>]
#Option "ColorTiling" # [<bool>]
#Option "ColorTiling2D" # [<bool>]
#Option "RenderAccel" # [<bool>]
#Option "SubPixelOrder" # [<str>]
#Option "AccelMethod" # <str>
#Option "ShadowPrimary" # [<bool>]
#Option "EXAVSync" # [<bool>]
#Option "EXAPixmaps" # [<bool>]
#Option "ZaphodHeads" # <str>
#Option "SwapbuffersWait" # [<bool>]
#Option "DeleteUnusedDP12Displays" # [<bool>]
#Option "DRI3" # [<bool>]
#Option "DRI" # <i>
#Option "TearFree" # [<bool>]
Identifier "Card0"
Driver "vesa"
BusID "PCI:3:0:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection



-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

[snip]

Your xorg.conf looks sane to me. I don't see anything that would cause
the keyboard to stop working when X stops.

There's still this issue from a few articles back:

[ 36994.149] (II) config/devd: detected USB HID of unknown type
[ 36994.149] (II) config/devd: [sysctl] usb_id: 0x046d:0xc31d
[ 36994.149] (II) config/devd: [sysctl] vendor: USB, product: Keyboard

Those 3 lines look like it didn't properly recognize a USB keyboard.

[ 36994.149] (II) config/devd: adding input device /dev/uhid0
[ 36994.149] (II) No input driver specified, ignoring this device.
[ 36994.149] (II) This device may have been added with another device file.
[ 36994.149] (EE) config/devd: error 1 adding device /dev/uhid0

And this says there was an error.

Grasping at straws now ...

Does your /etc/rc.conf have the two lines

hald_enable="YES"
dbus_enable="YES"

Yes,albeit in the opposite order...however,I note this content from /usr/ports/UPDATING:

===========
20200220:
AFFECTS: users of x11-servers/xorg-server
AUTHOR: zeising@FreeBSD.org

x11-servers/xorg-server has been updated to 1.20.7.

With this update, xorg-server has switched from using the devd backend to
the udev backend for device configuration on FreeBSD 12 and 13. If you have
issues with input devices, please see the install message for details.

The HAL backend option has been completely removed, as it was deprecated.

If you have problems with input devices, ensure that both x11/libinput and
x11-drivers/xf86-input-libinput are installed. They are installed in the
default configuration, but if you have a custom configuration, they might not
be.

============

Could my problem relate to the "HAL backend option" removal?
My pkg info list does include both libinput and xf86-input-libinput.

? Since things used to work, it probably does.

kbdcontrol(1) looks interesting. Have a look at its man page. Based on
that ...

Do you have /dev/ukbd0 ? Unless you have >1 keyboard plugged in, or

Only 1 keyboard plugged in.

IPMI, I'd expect that to be your Logitech keyboard. If so, an
experiment might be worth trying. At the end of your .xinitrc,

1) change the "exec xterm" on the last line to just "xterm", and
2) add after it:

(sleep 4; ps augwx >/var/tmp/foo; kbdcontrol -a ukbd0 < /dev/kbdmux0) &

and see if that makes any difference. Even if it doesn't, we'll at
least get to see what's running (or hung) by looking at /var/tmp/foo
after rebooting.

If you don't have /dev/ukbd0 even before starting X, then that's
interesting by itself.
-WBE

Will continue to tinker...

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[snip]

Your xorg.conf looks sane to me. I don't see anything that would cause
the keyboard to stop working when X stops.

There's still this issue from a few articles back:

[ 36994.149] (II) config/devd: detected USB HID of unknown type
[ 36994.149] (II) config/devd: [sysctl] usb_id: 0x046d:0xc31d
[ 36994.149] (II) config/devd: [sysctl] vendor: USB, product: Keyboard

Those 3 lines look like it didn't properly recognize a USB keyboard.

[ 36994.149] (II) config/devd: adding input device /dev/uhid0
[ 36994.149] (II) No input driver specified, ignoring this device.
[ 36994.149] (II) This device may have been added with another device file. >>> [ 36994.149] (EE) config/devd: error 1 adding device /dev/uhid0

And this says there was an error.

Grasping at straws now ...

Does your /etc/rc.conf have the two lines

hald_enable="YES"
dbus_enable="YES"

? Since things used to work, it probably does.

kbdcontrol(1) looks interesting. Have a look at its man page. Based on
that ...

Do you have /dev/ukbd0 ? Unless you have >1 keyboard plugged in, or
IPMI, I'd expect that to be your Logitech keyboard. If so, an
experiment might be worth trying. At the end of your .xinitrc,

1) change the "exec xterm" on the last line to just "xterm", and
2) add after it:

(sleep 4; ps augwx >/var/tmp/foo; kbdcontrol -a ukbd0 < /dev/kbdmux0) &

and see if that makes any difference. Even if it doesn't, we'll at
least get to see what's running (or hung) by looking at /var/tmp/foo
after rebooting.

If you don't have /dev/ukbd0 even before starting X, then that's
interesting by itself.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Louis Epstein <le@top.put.com> writes:

...however,I note this content from /usr/ports/UPDATING:

===========
20200220:
AFFECTS: users of x11-servers/xorg-server
AUTHOR: zeising@FreeBSD.org

x11-servers/xorg-server has been updated to 1.20.7.

With this update, xorg-server has switched from using the devd
backend to the udev backend for device configuration on FreeBSD 12
and 13. If you have issues with input devices, please see the
install message for details.

Since (IIRC) you said the system having problems is running 11.4, so I
wouldn't think the devd => udev switch would be an issue for you.

The HAL backend option has been completely removed, as it was deprecated.

If you have problems with input devices, ensure that both
x11/libinput and x11-drivers/xf86-input-libinput are installed.
They are installed in the default configuration, but if you have a
custom configuration, they might not be.

============

Could my problem relate to the "HAL backend option" removal?
My pkg info list does include both libinput and xf86-input-libinput.

I don't know, and I'm so sure of my lack of knowledge on that subject I wouldn't even hazard a guess. :)

I've lost track of what all you've tried. IIRC, in the beginning, using
the radeon driver, you couldn't get X to even start. You also had a
vanishing cursor problem. As part of trying to fix those problems, you
began compiling newer versions from the ports tree, which didn't help.

Did you ever try using the pkg repository default version with just the
radeon => vesa change? Whatever issues X might have on 11.4, I would
hope that the standard default version wouldn't have the kind of
keyboard issues you've had.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

Louis Epstein <le@top.put.com> writes:

...however,I note this content from /usr/ports/UPDATING:

===========
20200220:
AFFECTS: users of x11-servers/xorg-server
AUTHOR: zeising@FreeBSD.org

x11-servers/xorg-server has been updated to 1.20.7.

With this update, xorg-server has switched from using the devd
backend to the udev backend for device configuration on FreeBSD 12
and 13. If you have issues with input devices, please see the
install message for details.

Since (IIRC) you said the system having problems is running 11.4, so I wouldn't think the devd => udev switch would be an issue for you.

the current patch of 11.3 actually...as 11.4 will not be released
until this coming summer.

The HAL backend option has been completely removed, as it was deprecated.

If you have problems with input devices, ensure that both
x11/libinput and x11-drivers/xf86-input-libinput are installed.
They are installed in the default configuration, but if you have a
custom configuration, they might not be.

============

Could my problem relate to the "HAL backend option" removal?
My pkg info list does include both libinput and xf86-input-libinput.

I don't know, and I'm so sure of my lack of knowledge on that subject I wouldn't even hazard a guess. :)

I've lost track of what all you've tried. IIRC, in the beginning, using
the radeon driver, you couldn't get X to even start. You also had a vanishing cursor problem. As part of trying to fix those problems, you
began compiling newer versions from the ports tree, which didn't help.

I update ports periodically via Synth.

Did you ever try using the pkg repository default version with just the radeon => vesa change? Whatever issues X might have on 11.4, I would
hope that the standard default version wouldn't have the kind of
keyboard issues you've had.
-WBE

Version of what,xorg?

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously posted:

Since (IIRC) you said the system having problems is running 11.4, so
I wouldn't think the devd => udev switch would be an issue for you.

Louis Epstein <le@top.put.com> writes:

the current patch of 11.3 actually...as 11.4 will not be released
until this coming summer.

Oops. 1,$s/11\.4/11.3/g :)

Did you ever try using the pkg repository default version with just
the radeon => vesa change?

Louis Epstein <le@top.put.com> writes:

Version of what,xorg?

If I'm recalling the sequence of events right (and I might not be), you
went down the rabbit hole of building X from the ports tree because the
radeon driver died on the undefined symbol reference during start-up.
Fetching a recent version of the source into the ports tree took you
from the repository version (1.18?) to 1.20.7, but (again, IIRC) didn't
fix the radeon problem, and 1.20.7 is what we've been trying to get
working.

I'm thinking maybe uninstall all the 1.20.7 X stuff that came from the
ports tree, go back to the pkg repository version, and that maybe with
just the xorg.conf change from "radeon" to "vesa" things might work.

Whatever issues X might have on [11.3], I would hope that the
[repository] version wouldn't have the kind of keyboard issues
you've had.

-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously posted:

Since (IIRC) you said the system having problems is running 11.4, so
I wouldn't think the devd => udev switch would be an issue for you.

Louis Epstein <le@top.put.com> writes:

the current patch of 11.3 actually...as 11.4 will not be released
until this coming summer.

Oops. 1,$s/11\.4/11.3/g :)

Did you ever try using the pkg repository default version with just
the radeon => vesa change?

Louis Epstein <le@top.put.com> writes:

Version of what,xorg?

If I'm recalling the sequence of events right (and I might not be), you
went down the rabbit hole of building X from the ports tree because the radeon driver died on the undefined symbol reference during start-up. Fetching a recent version of the source into the ports tree took you
from the repository version (1.18?) to 1.20.7, but (again, IIRC) didn't
fix the radeon problem, and 1.20.7 is what we've been trying to get
working.

You mean the version that was new at the same time as 11.3?
I pkg update with some regularity as well.

I'm thinking maybe uninstall all the 1.20.7 X stuff that came from the
ports tree, go back to the pkg repository version, and that maybe with
just the xorg.conf change from "radeon" to "vesa" things might work.

One thing that has not been fixed with that change is that
Instagram videos haven't played for me for quite a while.

Whatever issues X might have on [11.3], I would hope that the
[repository] version wouldn't have the kind of keyboard issues
you've had.

-WBE

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Winston <wbe@ubeblock.psr.com.invalid>:

Did you ever try using the pkg repository default version with just the radeon => vesa change? Whatever issues X might have on 11.4, I would
hope that the standard default version wouldn't have the kind of
keyboard issues you've had.

There seems to be some misunderstanding here .. the package repository
is just a complete build of the ports tree, and this ports tree has no
relation at all to the version of FreeBSD used. You just have the option
to either always use the most recent pots/packages or a quarterly
snapshot. So, maybe xorg-server 1.18.4 is still in the quarterly
snapshot, but this will change soon: 1.20.7 hit the ports on Feb, 20st.

Of course, trying an older version is still a strategy to nail down an
issue, but it's cumbersome (you have to get the older port version
manually from svn or the git mirror and build it) and not a lasting
solution.

BR, Felix

--
Dipl.-Inform. Felix Palmen <felix@palmen-it.de> ,.//..........
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Louis Epstein <le@top.put.com> writes:

You mean the version that was new at the same time as 11.3?
I pkg update with some regularity as well.

A few minutes ago, I replied:

No, I meant the current pkg repository version you'd get with
pkg install, which ought to work well with 11.3.
I think that's not 1.20.* but an older version of X.

Then I saw Felix's article. :)

As Felix said, the pkg "most recent" repository version indeed isn't
1.18.4 now, but 1.20.7, so I have to modify my suggestion.

First, try the "pkg install" version of 1.20.7. Maybe that'll work
better than the code you built yourself.

If not, my next suggestion would be to save a copy of your latest /var/log/Xorg.0.log from running 1.20.7 for reference, then use the
quarterly snapshot version of the pkg repository to go back to 1.18.4
and see if that version works any better.

If it does, comparing the log files should provide clues about what
changed, and you'd have something that works until you have to upgrade.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously posted:

Did you ever try using the pkg repository default version with just
the radeon => vesa change? Whatever issues X might have on 11.4, I
would hope that the standard default version wouldn't have the kind
of keyboard issues you've had.

felix@palmen-it.de (Felix Palmen) kindly replied:

There seems to be some misunderstanding here .. the package repository
is just a complete build of the ports tree, and this ports tree has no relation at all to the version of FreeBSD used.

You just have the option to either always use the most recent
pots/packages or a quarterly snapshot. So, maybe xorg-server 1.18.4 is
still in the quarterly snapshot, but this will change soon: 1.20.7 hit
the ports on Feb, 20st.

Timing matters, it appears. :)

When last I checked (a few days ago), "pkg rquery %v xorg-server" was
still saying 1.18.4*, but that was also back about the time there was a
problem with the pkg repository so that "pkg update" was failing.
You're right: it's now saying 1.20.7_1.1, so "most recent" snapshot is
no longer a way to go back to 1.18.4, which is what I was suggesting.
It may now be necessary for Louis to tweak the pkg.conf repository URL
to use the quarterly snapshot in order to go back to 1.18.

As to 1.20, I'd still trust the "pkg install" version a little bit more
than one I'd built myself.

Of course, trying an older version is still a strategy to nail down an
issue, [...] and not a lasting solution.

Yes, but if he tries the pkg repository version of 1.20 and that doesn't
work for him, and 1.18 does, it allows him to hold off upgrading until
either he finds something such as a configuration issue that causing the problem or maybe it's a bug that gets fixed in a later version.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously posted:

Since (IIRC) you said the system having problems is running 11.4, so
I wouldn't think the devd => udev switch would be an issue for you.

Louis Epstein <le@top.put.com> writes:

the current patch of 11.3 actually...as 11.4 will not be released
until this coming summer.

to which I replied:

Oops. 1,$s/11\.4/11.3/g :)

Did you ever try using the pkg repository default version with just
the radeon => vesa change?

Louis Epstein <le@top.put.com> writes:

Version of what,xorg?

If I'm recalling the sequence of events right (and I might not be), you
went down the rabbit hole of building X from the ports tree because the
radeon driver died on the undefined symbol reference during start-up.
Fetching a recent version of the source into the ports tree took you
from the repository version (1.18?) to 1.20.7, but (again, IIRC) didn't
fix the radeon problem, and 1.20.7 is what we've been trying to get
working.

Louis Epstein <le@top.put.com> writes:

You mean the version that was new at the same time as 11.3?
I pkg update with some regularity as well.

No, I meant the current pkg repository version you'd get with
pkg install, which ought to work well with 11.3.
I think that's not 1.20.* but an older version of X.

I'm thinking maybe uninstall all the 1.20.7 X stuff that came from the
ports tree, go back to the pkg repository version, and that maybe with
just the xorg.conf change from "radeon" to "vesa" things might work.

One thing that has not been fixed with that change is that
Instagram videos haven't played for me for quite a while.

If other videos play OK and it's only Instagram ones that don't, I would
think that's not an X problem. I would think it more likely that it's a
video decoder, Javascript or URL access issue, in which case it'd be a
browser issue more than an X issue, but that's just going by the odds.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously posted:

Did you ever try using the pkg repository default version with just
the radeon => vesa change? Whatever issues X might have on 11.4, I
would hope that the standard default version wouldn't have the kind
of keyboard issues you've had.

felix@palmen-it.de (Felix Palmen) kindly replied:

There seems to be some misunderstanding here .. the package repository
is just a complete build of the ports tree, and this ports tree has no
relation at all to the version of FreeBSD used.

You just have the option to either always use the most recent
pots/packages or a quarterly snapshot. So, maybe xorg-server 1.18.4 is
still in the quarterly snapshot, but this will change soon: 1.20.7 hit
the ports on Feb, 20st.

Timing matters, it appears. :)

When last I checked (a few days ago), "pkg rquery %v xorg-server" was
still saying 1.18.4*, but that was also back about the time there was a problem with the pkg repository so that "pkg update" was failing.
You're right: it's now saying 1.20.7_1.1, so "most recent" snapshot is
no longer a way to go back to 1.18.4, which is what I was suggesting.
It may now be necessary for Louis to tweak the pkg.conf repository URL
to use the quarterly snapshot in order to go back to 1.18.

As to 1.20, I'd still trust the "pkg install" version a little bit more
than one I'd built myself.

Of course, trying an older version is still a strategy to nail down an
issue, [...] and not a lasting solution.

Yes, but if he tries the pkg repository version of 1.20 and that doesn't
work for him, and 1.18 does, it allows him to hold off upgrading until
either he finds something such as a configuration issue that causing the problem or maybe it's a bug that gets fixed in a later version.
-WBE

Are you saying that synth mis-builds packages?

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously posted:

Since (IIRC) you said the system having problems is running 11.4, so >>>>> I wouldn't think the devd => udev switch would be an issue for you.

Louis Epstein <le@top.put.com> writes:

the current patch of 11.3 actually...as 11.4 will not be released
until this coming summer.

to which I replied:

Oops. 1,$s/11\.4/11.3/g :)

Did you ever try using the pkg repository default version with just
the radeon => vesa change?

Louis Epstein <le@top.put.com> writes:

Version of what,xorg?

If I'm recalling the sequence of events right (and I might not be), you
went down the rabbit hole of building X from the ports tree because the
radeon driver died on the undefined symbol reference during start-up.
Fetching a recent version of the source into the ports tree took you
from the repository version (1.18?) to 1.20.7, but (again, IIRC) didn't
fix the radeon problem, and 1.20.7 is what we've been trying to get
working.

Louis Epstein <le@top.put.com> writes:

You mean the version that was new at the same time as 11.3?
I pkg update with some regularity as well.

No, I meant the current pkg repository version you'd get with
pkg install, which ought to work well with 11.3.
I think that's not 1.20.* but an older version of X.

I'm thinking maybe uninstall all the 1.20.7 X stuff that came from the
ports tree, go back to the pkg repository version, and that maybe with
just the xorg.conf change from "radeon" to "vesa" things might work.

One thing that has not been fixed with that change is that
Instagram videos haven't played for me for quite a while.

If other videos play OK and it's only Instagram ones that don't, I would

Correct,Youtube and Vimeo play fine...

think that's not an X problem. I would think it more likely that it's a video decoder, Javascript or URL access issue, in which case it'd be a browser issue more than an X issue, but that's just going by the odds.
-WBE

Hoping that someone more skilled than I can create a port of
Seamonkey 2.49.5 or 2.51.x to replace the 2.49.4_27 at which
gecko@freebsd stopped maintaining it.

My regular port updates have included some versions of X.265 etc.

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously said:

As to 1.20, I'd still trust the "pkg install" version a little bit
more than one I'd built myself.

to which Louis Epstein <le@top.put.com> replied:

Are you saying that synth mis-builds packages?

No. I've never used it. It was more of a comment on my personal
experiences from many years ago when trying to do things more "by
hand".
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Louis Epstein <le@top.put.com> wrote:

I have lately had a problem with launching X...the system hangs at startx
and if I switch to another terminal session and back an error message appears ending

/usr/local/lib/xorg/modules/drivers/radeon.drv.so: Undefined symbol "exaGetPixmapDriverPrivate"
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

I am told that this bug has been reported for Debian as related to an upgrade of
xserver-xorg-video-radeon-1%3a19.0.1-1_ppc64.deb to xserver-xorg-video-radeon-1%3a19.1.0-1_ppc64.deb

but of course FreeBSD versions have different names.

What's the fix prognosis?

Not using FreeBSD, but it happened to me in OpenBSD when it was using another computer's
IP address (weird but it happened) in my LAN. The problem dissapeared when the other
computer was turned off.
I am not an expert, but it might be in your case.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Louis Epstein <le@top.put.com> writes:

I note that there is a new update-patch for the xorg-server
port that I am now preparing to install...will report whether
or not it makes a difference.

Did you ever solve the "keyboard doesn't work after exiting" problem
you were having?

I just had the displeasure of "upgrading" (and I use that term
reluctantly) from X11 1.18 to 1.20.

At one point during my efforts to get things to work decently, I
experienced something similar to what you described: after exiting,
characters were not echoed and some characters beeped when typed at the
prompt.

In my case, which might not have been your case, about half the
characters "beeped" at me. From many years ago, this looked to me like
"parity bit mishandling", where the high order bit of a character either
is or isn't a parity bit and doesn't match the stty mode. IF YOU COULD
TYPE IT, either "tset" or "reset" would fix the problem. Figure out
which characters don't beep at you, create an alias for tset that uses
only those characters, and then type that name and (usually) a linefeed
(^J), not Return (^M), and it would restore character echo and sanity.

I was luckier than you in one regard, though: CTRL+ALT+F2 worked, and
when I switched back, things were already OK again.

However, this only happened once. The rest of the time, I didn't have
that problem.

The other thing I encountered is that the new VESA driver barely works
at all, and certainly doesn't work as well as the 1.18 one did, or at
least I haven't found a way to get it to do so yet, but that's for
another post.
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Aelius Gallus <aelius@nospam.mail> wrote:

Louis Epstein <le@top.put.com> wrote:

I have lately had a problem with launching X...the system hangs at startx
and if I switch to another terminal session and back an error message appears
ending

/usr/local/lib/xorg/modules/drivers/radeon.drv.so: Undefined symbol "exaGetPixmapDriverPrivate"
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

I am told that this bug has been reported for Debian as related to an upgrade of
xserver-xorg-video-radeon-1%3a19.0.1-1_ppc64.deb to
xserver-xorg-video-radeon-1%3a19.1.0-1_ppc64.deb

but of course FreeBSD versions have different names.

What's the fix prognosis?

Not using FreeBSD, but it happened to me in OpenBSD when it was using another computer's
IP address (weird but it happened) in my LAN. The problem dissapeared when the other
computer was turned off.
I am not an expert, but it might be in your case.

Nothing was newly turned on on the LAN at the time the problem started.

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)