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

OP
K

ko56

Member

Reaction score: 1
Messages: 29

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

Aspiring Daemon

Reaction score: 372
Messages: 873

UPDATE

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

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.
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.

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.
 
OP
K

ko56

Member

Reaction score: 1
Messages: 29

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:
Code:
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.
 
OP
K

ko56

Member

Reaction score: 1
Messages: 29

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

Aspiring Daemon

Reaction score: 372
Messages: 873

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.
 
OP
K

ko56

Member

Reaction score: 1
Messages: 29

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?
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.
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

Aspiring Daemon

Reaction score: 372
Messages: 873

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
Code:
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.
 
Top