# Sun keyboard and xorg-server 1.20, FreeBSD 12.1, xfce 4.12



## ko56 (May 20, 2020)

Hi,

I can't make the "extra" (left panel) Sun keys work on my Sun keyboard after xorg-server was updated to 1.20.
(This is FreeBSD 12.1p4, with XFCE 4.12.)
I've read a lot of threads about keyboard issues, tried some of the solutions, but no luck.
Here is my keyboard configuration:

```
[ko@wiley ~]$ setxkbmap -print
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)"    };
    xkb_types     { include "complete"    };
    xkb_compat    { include "complete"    };
    xkb_symbols   { include "pc+sun_vndr/us+sun_vndr/gr(simple):2+inet(evdev)+group(menu_toggle)"    };
    xkb_geometry  { include "sun(type6unix)"    };
};
[ko@wiley ~]$
```
Before the upgrade, the "Open", "Front", "Undo", "Cut", "Copy", "Paste" Sun keys used to work. 
Now "xev" shows that "Open", "Undo", and "Front" don't produce any events at all.
And "Copy", "Cut", "Paste" produce XF86WakeUp, XF86Reload, XF86Search, respectively (all wrong).

Any help would be appreciated.


----------



## memreflect (May 20, 2020)

I don't have a Sun keyboard, but xkeyboard-config(7) might help:

```
Model                 Description
...
sun_type7_usb         Sun Type 7 USB
sun_type7_euro_usb    Sun Type 7 USB (European)
sun_type7_unix_usb    Sun Type 7 USB (Unix)
sun_type7_jp_usb      Sun Type 7 USB (Japanese)/Japanese 106-key
sun_type6_usb         Sun Type 6/7 USB
sun_type6_euro_usb    Sun Type 6/7 USB (European)
sun_type6_unix_usb    Sun Type 6 USB (Unix)
sun_type6_jp_usb      Sun Type 6 USB (Japanese)
sun_type6_jp          Sun Type 6 (Japanese)
...
Option               Description
solaris:sun_compat   Sun Key compatibility
```

So you might try `setxkbmap -option solaris:sun_compat` or even switching models using something like `setxkbmap -model sun_type6_usb`.  Other than that, I'm afraid I can't help.

For reference, here's how you can get back to the settings that `setxkbmap -print` displayed:

```
setxkbmap -model sun_type6_unix_usb -layout 'us,gr(simple)' -option -option grp:menu_toggle
```


----------



## ko56 (May 20, 2020)

Thanks for the suggestion.  I made XFCE use the "system defaults" for the keyboard, and put the "setxkbmap" line in my .xsession that starts XFCE.  Added the Solaris compatibility option.
Unfortunately, no luck.   The Sun keys behave (don't behave) as before.


----------



## T-Daemon (May 21, 2020)

Which Sun model is it you have?



ko56 said:


> [ko@wiley ~]$ setxkbmap -print


Please run `setxkbmap -print verbose 10` , post output.



ko56 said:


> And "Copy", "Cut", "Paste" produce XF86WakeUp, XF86Reload, XF86Search, respectively (all wrong).


That can be fixed.


----------



## ko56 (May 21, 2020)

T-Daemon said:


> Which Sun model is it you have?
> Sun Type 6, USB, Unix version
> 
> Please run `setxkbmap -print verbose 10` , post output.
> ...


----------



## T-Daemon (May 21, 2020)

That is not a verbose output of `setxkbmap -print -verbose 10` . It should look like this ( taken from here as example ):

```
$  setxkbmap -print -verbose 10.
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      geniuscomfy
layout:     us,ru
variant:    ,
options:    terminate:ctrl
_alt_bksp,grp:lwin_toggle,grp:rwin_toggle,lv3:ralt_switch_multikey
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us+ru:2+inet(evdev)+group(lwin_toggle)+group(rwin_toggle)+level3(ralt_switch_multikey)
geometry:   pc(pc104)
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)"    };
    xkb_types     { include "complete"    };
    xkb_compat    { include "complete"    };
    xkb_symbols   { include "pc+us+ru:2+inet(evdev)+group(lwin_toggle)+group(rwin_toggle)+level3(ralt_switch_multikey)"    };
    xkb_geometry  { include "pc(pc104)"    };
};
```

Please provide verbose output.


----------



## ko56 (May 21, 2020)

T-Daemon said:


> That is not a verbose output of `setxkbmap -print -verbose 10` . It should look like this ( taken from here as example ):
> 
> ```
> $  setxkbmap -print -verbose 10.
> ...



Sorry, smth. must have  gone wrong.  Here:

```
[ko@wiley ~]$ setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      sun_type6_unix_usb
layout:     us,gr
variant:    ,simple
options:    grp:menu_toggle,solaris:sun_compat,terminate:ctrl_alt_bksp
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+sun_vndr/us+sun_vndr/gr(simple):2+inet(evdev)+group(menu_toggle)+terminate(ctrl_alt_bksp)+sun_vndr/solaris(sun_compat)
geometry:   sun(type6unix)
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)"    };
    xkb_types     { include "complete"    };
    xkb_compat    { include "complete"    };
    xkb_symbols   { include "pc+sun_vndr/us+sun_vndr/gr(simple):2+inet(evdev)+group(menu_toggle)+terminate(ctrl_alt_bksp)+sun_vndr/solaris(sun_compat)"    };
    xkb_geometry  { include "sun(type6unix)"    };
};
[ko@wiley ~]$
```


----------



## sparky2002 (May 21, 2020)

Running with Fvwm and a UNIX-layout Type 7 here, all keys work.

I did notice at some point that MATE seems to ignore some keys, I don't remember wrt Xfce (can't test it right now). If it still doesn't work in Xfce you might want to verify under a simpler WM.

To make it work I only had to add this snippet to xorg's conf (or alternatively, as said above, with setxkbmap) :

```
$ cat /usr/local/share/X11/xorg.conf.d/80-sunkeyboard.conf
Section "InputClass"
    Identifier "Sun Keyboard defaults"
    MatchIsKeyboard "on"

    Option "XkbModel" "sun_type6_usb"
    Option "XkbLayout" "us"
    Option "XkbOptions" "eurosign:e,lv3:ralt_switch,compose:menu"
EndSection
```

EDIT: 
Just restested under Xfce with the (above) current Xorg configuration, and Xfce's Settings Manager→Keyboard→Layout→Keyboard Model set to "Sun Type 7 USB (UNIX)", all keys work and are either caught by Xfce (as per my local shortcuts) or reported by Xev either as "SunXXX",  "XF86yyy" or generic name (e.g. `SunFront`, `XF86Paste`, `Cancel`).


----------



## ko56 (May 22, 2020)

Thanks for doing all this checking.  

I put your 80-sunkeyboard.conf in /usr/local/share/X11/xorg.conf.d, but changed sun_type6_usb to sun_type7_usb. Then I set the keyboard to "Sun Type 7 USB (UNIX)" with XFCE, just like you did.

After I restarted X (logged out of XFCE), I saw that the /usr/local/share/X11/xorg.conf.d/80-sunkeyboard.conf
had disappeared. And when I test with xev, the keys still don't work:

Front -> Nothing
Paste -> XF86Search
Open -> Nothing
Cut -> XF86Reload

Are we running the same xorg-server and XFCE?  Mine are xorg-server-1.20.8, and xfce4.12.


----------



## sparky2002 (May 23, 2020)

> After I restarted X (logged out of XFCE), I saw that the /usr/local/share/X11/xorg.conf.d/80-sunkeyboard.conf had disappeared.



That shouldn't happen. Obviously, if the file is not present, whatever other configuration you have will still apply.

The keys issuing the wrong events is explained by not having the correct keyboard configuration. It's close, but it's not exactly right. That said, I've been using Sun keyboards since the Type 4 (with a custom adapter) and as far as I remember the keycodes haven't changed from one generation to the next.

One difference that I see in your (initial) configuration at the top of this thread is that you're using "gr" symbols (greek, I assume ?) while my configuration is strictly for a US-UNIX layout. I don't see how it would cause your issues, but I have no experience with a dual-layout setup.

As for software versions, I'm using whatever is current in 12.1-RELEASE-p5 at the moment (Xfce 4.14 metapackage, xorg-server 1.20.8_1). Shouldn't make a difference, I've been using this setup since 10.something-RELEASE.


----------



## ko56 (May 23, 2020)

I rebooted, and /usr/local/share/X11/xorg.conf.d is totally empty.

Anyhow, apart from usr/local/share/X11/xorg.conf.d and Xfce 4.12 vs. Xfce 4.14, our configurations seem to be the same: I have a Type 6 keyboard (I also have been using Sun keyboards since type 4), and my Xfce settings say it is a Type 7 USB Unix.  Here is setxkbmap output, I removed the Greek layout option:


```
[ko@wiley ~]$ setxkbmap -print
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)"    };
    xkb_types     { include "complete"    };
    xkb_compat    { include "complete"    };
    xkb_symbols   { include "pc+sun_vndr/us(alt-intl)+inet(evdev)+group(menu_toggle)"    };
    xkb_geometry  { include "sun(type7unix)"    };
};
[ko@wiley ~]$
```
As far as I understand, the /usr/local/share/X11/xorg.conf.d/80-sunkeyboard.conf should not really be necessary.

What else could be different?


----------



## T-Daemon (May 23, 2020)

sparky2002, can you post the output of `setxkbmap -print -verbose 10`, so we can compare with ko56’s . Also attach /var/log/Xorg.0.log.

ko56  please attach your /var/log/Xorg.0.log to your next posting.


----------



## ko56 (May 23, 2020)

Xorg.0.log is 2300 lines, should I still post it?


----------



## tingo (May 23, 2020)

post to a "pastebin" type web site, and post the link here.


----------



## ko56 (May 23, 2020)

I am not totally sure how pastebin works, but I created a paste on pastebin.com.  Does this link https://pastebin.com/index/SepFcgAw make sense?

I am also posting the latest setxkbmap -print -verbose 10


```
[ko@wiley ~]$ setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      sun_type7_unix_usb
layout:     us
variant:    alt-intl
options:    grp:menu_toggle
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+sun_vndr/us(alt-intl)+inet(evdev)+group(menu_toggle)
geometry:   sun(type7unix)
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)"    };
    xkb_types     { include "complete"    };
    xkb_compat    { include "complete"    };
    xkb_symbols   { include "pc+sun_vndr/us(alt-intl)+inet(evdev)+group(menu_toggle)"    };
    xkb_geometry  { include "sun(type7unix)"    };
};
[ko@wiley ~]$
```


----------



## tingo (May 23, 2020)

Yes, that link to pastebin.com works.


----------



## sparky2002 (May 23, 2020)

`$ setxkbmap -print -verbose 10`

```
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      sun_type6_usb
layout:     us
options:    eurosign:e,lv3:ralt_switch,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+sun_vndr/us+inet(evdev)+level3(ralt_switch)+compose(menu)+eurosign(e)
geometry:   sun(type6)
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)"    };
    xkb_types     { include "complete"    };
    xkb_compat    { include "complete"    };
    xkb_symbols   { include "pc+sun_vndr/us+inet(evdev)+level3(ralt_switch)+compose(menu)+eurosign(e)"    };
    xkb_geometry  { include "sun(type6)"    };
};
```

Hope this helps.


----------



## ko56 (May 24, 2020)

One more data point: I tried a different window manager, twm, with the same keyboard settings (Sun Type 7, though I think Type 6 or 7 does not really make a difference), and the problem is still there.


----------



## T-Daemon (May 25, 2020)

I noticed from your Xorg.0.log file, xorg chooses “libinput" as keyboard driver.


```
[ 53423.526] (II) Using input driver 'libinput' for 'AT keyboard'
```

I would have been interested which driver sparky2002’s xorg setup chooses for the keyboard.
sparky2002, if it’s possible, could you please https://pastebin.com ( or similar text storage site ) your Xorg.0.log?

Sorry for the late communication, I couldn't go earlier.


----------



## T-Daemon (May 26, 2020)

Please set in /usr/local/etc/X11/xorg.conf.d/sun-keyboard.conf


```
Section “InputClass”
       Identifier "Sun Type 6 Unix"
       MatchIsKeyboard "on"
       Option     "XkbModel" "sun_type6_usb"
       Option     "XkbLayout" "us,gr(simple)"
       Option     "XkbOptions" "grp:menu_toggle"
EndSection
```

Furthermore please post output of:

`pkg info | grep xf86-input`


----------



## ko56 (May 26, 2020)

OK, I created this file and restarted the window system. Problem persists, unfortunately.


```
[ko@wiley ~]$ pkg info | grep xf86-input
xf86-input-keyboard-1.9.0_4    X.Org keyboard input driver
xf86-input-libinput-0.29.0     X.Org libinput input driver
xf86-input-mouse-1.9.3_3       X.Org mouse input driver
[ko@wiley ~]$
```


----------



## T-Daemon (May 26, 2020)

Let’s try this:

Attempt 1:
`pkg add xf86-input-evdev`
Restart _xorg_, check keys.


Attempt 2:
If no response from those extra keys, check Xorg.0.log for keyboard driver info line

```
[ …………….] (II) Using input driver ‘…….…’  for 'AT keyboard’.
```

If it’s still ‘libinput’ add driver in /usr/local/etc/X11/xorg.conf.d/sunkeyboard.conf:

```
…..
Driver    "evdev"
…..
```
With the _evdev_ driver check also `xev -events keyboard` , if there is at least a response there.


----------



## ko56 (May 26, 2020)

Attempt 1 failed, attempt 2 also failed. Here is a grep through Xorg.0.log:


```
[ko@wiley /var/log]$ grep 'Using input driver' Xorg.0.log
[    38.537] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[    38.803] (II) Using input driver 'libinput' for 'System mouse'
[    38.805] (II) Using input driver 'libinput' for 'AT keyboard'
[    38.808] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[    38.812] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[ 52618.722] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[ 52618.758] (II) Using input driver 'libinput' for 'System mouse'
[ 52618.760] (II) Using input driver 'libinput' for 'AT keyboard'
[ 52618.763] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[ 52618.767] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[ 52627.394] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[ 52627.429] (II) Using input driver 'libinput' for 'System mouse'
[ 52627.431] (II) Using input driver 'libinput' for 'AT keyboard'
[ 52627.434] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[ 52627.438] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[ 52638.725] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[ 52638.761] (II) Using input driver 'libinput' for 'System mouse'
[ 52638.764] (II) Using input driver 'libinput' for 'AT keyboard'
[ 52638.766] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[ 52638.770] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[ 53036.238] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[ 53036.274] (II) Using input driver 'libinput' for 'System mouse'
[ 53036.277] (II) Using input driver 'libinput' for 'AT keyboard'
[ 53036.280] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[ 53036.283] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[ 53423.487] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[ 53423.523] (II) Using input driver 'libinput' for 'System mouse'
[ 53423.526] (II) Using input driver 'libinput' for 'AT keyboard'
[ 53423.529] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[ 53423.533] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[171420.891] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[221681.944] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[306150.814] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[306150.861] (II) Using input driver 'libinput' for 'System mouse'
[306150.863] (II) Using input driver 'libinput' for 'AT keyboard'
[306150.866] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[306150.869] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[321838.964] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[321839.002] (II) Using input driver 'libinput' for 'System mouse'
[321839.004] (II) Using input driver 'libinput' for 'AT keyboard'
[321839.007] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[321839.010] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[322143.950] (II) Using input driver 'libinput' for 'System keyboard multiplexer'
[322143.988] (II) Using input driver 'libinput' for 'System mouse'
[322143.991] (II) Using input driver 'libinput' for 'AT keyboard'
[322143.993] (II) Using input driver 'libinput' for 'vendor 0x0430 product 0x0005'
[322143.997] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[322474.428] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[322592.965] (II) Using input driver 'libinput' for 'MOSART Semi. 2.4G Wireless Mouse'
[ko@wiley
```

There seems to be something else wrong too because Xorg insists the keyboard is a type 7 not 6 (the difference may not really matter, but "setxkbmap -print" says it's a type 6):


```
[322143.995] (II) event3  - vendor 0x0430 product 0x0005, class 0/0, rev 1.10/2.00, addr 3: device is a keyboard
[322143.995] (II) event3  - vendor 0x0430 product 0x0005, class 0/0, rev 1.10/2.00, addr 3: device removed
[322143.995] (**) Option "config_info" "udev:/dev/input/event3"
[322143.995] (**) Option "xkb_rules" "evdev"
[322143.995] (**) Option "xkb_model" "sun_type7"
[322143.995] (**) Option "xkb_layout" "us"
[322143.996] (II) event3  - vendor 0x0430 product 0x0005, class 0/0, rev 1.10/2.00, addr 3: is tagged by udev as: Keyboard
[322143.996] (II) event3  - vendor 0x0430 product 0x0005, class 0/0, rev 1.10/2.00, addr 3: device is a keyboard
```

Finally, "xmodmap -pk" https://pastebin.com/dl/YNmUUan6 reports weird keycodes that don't agree with what I find in /usr/local/share/X11/xkb/keycodes.


----------



## T-Daemon (May 27, 2020)

Try `pkg install xf86-input-keyboard`. Make sure there are no driver settings in the sunkeyboard.conf, check Xorg.0.log which driver is loaded.


----------



## ko56 (May 28, 2020)

T-Daemon said:


> Try `pkg install xf86-input-keyboard`. Make sure there are no driver settings in the sunkeyboard.conf, check Xorg.0.log which driver is loaded.


`pkg install xf86-input-keyboard` is already installed.  sunkeyboard.conf still has the driver settings you suggested in #22 above.
I am posting my Xorg.0.log, https://pastebin.com/embed/6tNjQAj0.  It seems to me that the system thinks there are *two* keyboards, one associated with /dev/input/event2 and one with /dev/input/event3. Don't know what to make of that.

By the way, thanks for all your help!


----------



## sparky2002 (May 28, 2020)

Sorry, didn't see the message earlier.








						sparky2002 - Pastebin.com
					






					pastebin.com
				




Cleaned-up version concentrating on input (mostly removed nvidia-related junk).


----------



## T-Daemon (May 29, 2020)

ko56, does your keyboard have dip switches on the back as claimed in the linked wiki below? If it does how is it set?





__





						Sun Type 7 - Deskthority wiki
					






					deskthority.net


----------



## ko56 (May 29, 2020)

T-Daemon said:


> ko56, does your keyboard have dip switches on the back as claimed in the linked wiki below? If it does how is it set?
> 
> 
> 
> ...


Mine is a type 6, previous generation from type 7, as shown here https://deskthority.net/wiki/Sun_Type_6. 

There *is* a small panel in the back. Removing it reveals something which may be a DIP switch, can't exactly tell. If it is, the actual switches on it are not accessible, it looks like you have to take the keyboard apart. I would do that, if I knew of a way to test "what comes out" of the keyboard without all the layers of the X software that are on top of it.


----------



## T-Daemon (May 31, 2020)

UPDATE

Sorry for the late response, investigating the problem in detail takes a while.



ko56 said:


> Mine is a type 6, previous generation from type 7


I haven’t forgotten , my suggestion was based on “_As in other Sun keyboards _…” part of the first sentence of that chapter.


ko56 said:


> Removing it reveals something which may be a DIP switch


According to the wiki on type 7 are a set of 5 dip switches ( which "... _define the layout variant_." ). If existent, on type 6 should be similar. I was thinking trying those switches might help getting an event response from those keys.



ko56 said:


> it looks like you have to take the keyboard apart. I would do that, if I knew of a way to test "what comes out" of the keyboard without all the layers of the X software that are on top of it.


If those switches are not accessible easily ( if present ) then you shouldn't touch it.

As I see the problem, _libinput_ doesn’t receive an event from those keys in question. I’m investigating /usr/src/sys/dev/evdev/evdev_utils.c at the moment. That file may need a patch to support the unresponsive keys.

To make sure could you please run as root `libinput debug-events —-verbose —-show-keycodes` and press those keys.


----------



## ko56 (Jun 1, 2020)

What looks like a DIP switch isn't easily accessible, so I'm leaving it alone.

Here is what `libinput debug-events --verbose --show-keycodes` reports, first pair of columns, and what `xev` reports, second pair of columns:

```
Stop    KEY_POWER    116    Xf86PowerOff    124
Again    KEY_SLEEP     142    XF86Sleep    150
Props
Undo
Front
Copy    KEY_WAKEUP   143    XF86Wakeup    151
Open
Paste    KEY_SEARCH    217    XF86Search    225
Find    KEY_BOOKMARKS    156    XF86Favorites    164
Cut    KEY_REFRESH    173    XF86Reload    181
```

The important keys for me are Open, Front, and Undo.


----------



## ko56 (Jun 1, 2020)

I forgot to add that before the update to xorg-server-1.20, at least the Open key was visible to XFCE.  Same keyboard.


----------



## T-Daemon (Jun 6, 2020)

ko56 said:


> I forgot to add that before the update to xorg-server-1.20, at least the Open key was visible to XFCE. Same keyboard.


You haven't, you mentioned it in your first posting.

For the problem, I couldn't make any progress. As I see it, it happens on the evdev level ( /usr/src/sys/dev/evdev ). The keyboard keys don't produce any events. When there is no event no key codes are returned, no keyboard mapping happens. I don't know where to investigate further, also I lack the knowledge to debug the evdev source code.

Those keys of yours returning a wrong function can be remapped, but not the others ( no key codes ). If you need all keys urgent, you could build xorg-server from ports with DEVD enable ( instead of UDEV ), just make sure to pull the right ports tree banch. Package repository quarterly (/etc/pkg/FreeBSD.conf ): svnlite(1) 2020Q2, package repository latest: portsnap(8).

If there is no urgency, I suggest you try at freebsd-x11@freebsd.org mailing list. That list is frequented by developers, familiar with this kind of problem. If you don't get an respons from there after a time you could also try on https://bugs.freebsd.org. Sorry I couldn't be of help.


----------



## sparky2002 (Jun 6, 2020)

> ... with DEVD enable ...



For what it's worth I do have `devd_enable="YES"` in `/etc/rc.conf` (it doesn't seem it was mentioned before).


----------



## ko56 (Jun 7, 2020)

sparky2002 said:


> For what it's worth I do have `devd_enable="YES"` in `/etc/rc.conf` (it doesn't seem it was mentioned before).


I tried that, no effect.
The last thing I tried is logging in just to the console, no X at all.  I remember from a while ago, that many of the Sun keys would produce some "nonsense" characters on the screen. Not any more.  So the issue seems to be independent of X?


T-Daemon said:


> You haven't, you mentioned it in your first posting.
> 
> For the problem, I couldn't make any progress. As I see it, it happens on the evdev level ( /usr/src/sys/dev/evdev ). The keyboard keys don't produce any events. When there is no event no key codes are returned, no keyboard mapping happens. I don't know where to investigate further, also I lack the knowledge to debug the evdev source code.
> 
> ...



Thanks again for all your help.  I will try the lists you suggested.

By the way, the last thing I tried is logging in just to the console, no X at all.  I remember from a while ago, that many of the Sun keys would produce some "nonsense" characters on the screen. Not any more.  So the issue seems to be independent of X?


----------



## T-Daemon (Jun 27, 2020)

SOLUTION here:

To make the 10 extra keys on the left side of the Sun Type 6, USB, Unix version keyboard all work again, one has to set

```
kern.evdev.rcpt_mask=12
```
 in /etc/sysctl.conf.

I was hoping OP would return to his thread to add the solution to the problem after filing a bug report and resolving the problem. He might not thought about it. Others with the same problem finding this thread should know there is a solution. Who's interested what effect the setting has might want to read post #14. To understand demands knowledge about the infrastructure involved.


----------

