Howto: Enabling multimedia keys, gamepads/joysticks for desktop; usbhid

sidetone

sidetone

Enabling usbhid
usbhid(4) gives the ability to use newer advanced hid drivers. The ability to use usbhid must be turned on from /boot/loader.conf:
Code: 
hw.usb.usbhid.enable="1"
Then, load the driver through /etc/rc.conf:
Code: 
kld_list="usbhid"
Turning this module on from /boot/loader.conf won't work. Once this is turned on, the other drivers will automatically load according to your hardware on the next boot up. This works on FreeBSD 13.1-Beta, so it may have to be tested from FreeBSD 13.0. On future releases of FreeBSD, enabling usbhid ability from loader.conf may likely no longer be necessary.

Multimedia keys
Once usbhid loads on bootup, hcons(4) automatically starts up, provided there's a corresponding hardware device with multimedia keys.

x11/xev works from the Xorg desktop. Get the keycode number with xev. | grep keycode can be used with this. Sometimes it takes pressing a few multimedia keys at a time to get this output through xev(1) (this inconsistency is expected to be improved in the future). With other drivers and previous FreeBSD releases, this didn't produce a keycode for multimedia keys from certain keyboards. Now, it's expected to work with multimedia keys from more keyboards. Other keycode grabbers than xev, especially for the virtual console, don't seem to work for special keys. As of this writing, multimedia keys only work from the X.org desktop. When switching to terminal consoles, these keys don't work there.

Run xmodmap -pke to see conventional entries of keycodes to multimedia and other keyboard functions. See xmodmap(1) for more details. Then, edit ~/.xmodmaprc, for example:
Code: 
keycode 121 = XF86AudioMute
keycode 122 = XF86AudioLowerVolume
keycode 123 = XF86AudioRaiseVolume
keycode 171 = XF86AudioNext
keycode 172 = XF86AudioPlay XF86AudioPause
keycode 173 = XF86AudioPrev
keycode 148 = XF86Calculator
In these examples,"XF86Audio" is part of the name of the keys that would be used in hotkeys for window managers and desktop applications. Audio level controls are typically more specific to commands, for instance mixer(8), through a window manager. Depending on keyboard, some entries like calculator and mail may need the FN key. In my window manager, I associated the calculator with xcalc(1). An entry for a window manager configuration file may include key="XF86AudioMute". Hotkeys of pause/resume, next and previous for the audio application audio/deadbeef can be set through Edit -> Preferences -> Hotkeys.

hsctrl(4) is a driver that works for power on/off keys. hkbd(4) is for i2c keypads.

Game control drivers
Game control drivers compatible with usbhid that have been moved into base of FreeBSD 13.x: hgame(4), ps4dshock(4), xb360gp(4).

 
Thanks!

sidetone said:
… xev. | grep keycode …
Click to expand...

The . might be a typo. This works:

xev | grep keycode


sidetone said:
kld_list="usbhid"
Click to expand...

As superuser:

sysrc kld_list+=usbhid && kldload usbhid
  • less risk of a reader inadvertently creating multiple kld_list lines in rc.conf(5)
  • loads the kernel module
1647756296971.png

sysrc(8) – safely edit system rc files
 
sidetone said:
… On future releases of FreeBSD, enabling usbhid ability from loader.conf may likely no longer be necessary. …
Click to expand...

FreeBSD 14.0-CURRENT

I do find the kernel module loaded without anything specific in loader.conf(5) or rc.conf(5):

Code: 
% date ; uptime
Sun 20 Mar 2022 05:43:05 GMT
 5:43a.m.  up 3 mins, 2 users, load averages: 1.89, 0.54, 0.20
% kldstat
Id Refs Address                Size Name
 1  170 0xffffffff80200000  2f64d08 kernel
 2    3 0xffffffff83165000    8cba0 vboxdrv.ko
 3    1 0xffffffff831f2000     58a8 sysctlinfo.ko
 4    1 0xffffffff831f8000     c528 autofs.ko
 5    1 0xffffffff83205000     67a0 acpi_hp.ko
 6    2 0xffffffff8320c000     7028 acpi_wmi.ko
 7    1 0xffffffff83214000   5c2990 zfs.ko
 8    1 0xffffffff837d7000     b2a0 cuse.ko
 9    1 0xffffffff837e4000     3270 sysctlbyname_improved.ko
10    1 0xffffffff83c64000     4e78 acpi_dock.ko
11    1 0xffffffff83c69000    1c488 geom_eli.ko
12    1 0xffffffff8468f000     3578 fdescfs.ko
13    1 0xffffffff84693000    12db0 fusefs.ko
14    1 0xffffffff846a6000   155c90 radeonkms.ko
15    2 0xffffffff847fc000    7fe40 drm.ko
16    1 0xffffffff8487c000     22d8 iic.ko
17    3 0xffffffff8487f000     a378 linuxkpi_gplv2.ko
18    1 0xffffffff8488a000     2370 lindebugfs.ko
19    1 0xffffffff8488d000     e768 ttm.ko
20    1 0xffffffff8489c000     3258 radeon_TURKS_pfp_bin.ko
21    1 0xffffffff848a0000     3658 radeon_TURKS_me_bin.ko
22    1 0xffffffff848a4000     2cd8 radeon_BTC_rlc_bin.ko
23    1 0xffffffff848a7000     7ef8 radeon_TURKS_mc_bin.ko
24    1 0xffffffff848af000     8138 radeon_TURKS_smc_bin.ko
25    1 0xffffffff848b8000    341f0 radeon_SUMO_uvd_bin.ko
26    1 0xffffffff848ed000     3268 filemon.ko
27    1 0xffffffff848f1000    2de38 linux.ko
28    4 0xffffffff8491f000     af10 linux_common.ko
29    1 0xffffffff8492a000    2b018 linux64.ko
30    1 0xffffffff84956000     2278 pty.ko
31    1 0xffffffff84959000     63bc linprocfs.ko
32    1 0xffffffff84960000     329c linsysfs.ko
33    1 0xffffffff84964000     2258 cpuctl.ko
34    2 0xffffffff84967000     4240 vboxnetflt.ko
35    8 0xffffffff8496c000     abb0 netgraph.ko
36    1 0xffffffff84977000     31f8 ng_ether.ko
37    1 0xffffffff8497b000     55e0 vboxnetadp.ko
38    1 0xffffffff84981000     4d40 ng_ubt.ko
39    2 0xffffffff84986000     a268 ng_hci.ko
40    4 0xffffffff84991000     25c0 ng_bluetooth.ko
41    1 0xffffffff84994000     2280 uhid.ko
42    1 0xffffffff84997000     3280 ums.ko
43    1 0xffffffff8499b000     3340 usbhid.ko
44    1 0xffffffff8499f000     3228 hidbus.ko
45    1 0xffffffff849a3000     23c0 umodem.ko
46    1 0xffffffff849a6000     4d78 ucom.ko
47    1 0xffffffff849ab000     44c0 if_cdce.ko
48    1 0xffffffff849b0000     3190 uether.ko
49    1 0xffffffff849b4000     e280 ng_l2cap.ko
50    1 0xffffffff849c3000    1d018 ng_btsocket.ko
51    1 0xffffffff849e1000     3980 ng_socket.ko
52    1 0xffffffff849e5000     4778 nullfs.ko
53    1 0xffffffff849ea000     2a20 mac_ntpd.ko
% grep usbhid /boot/loader.conf
# hw.usb.usbhid.enable=1
% grep usbhid /etc/rc.conf
# usbhid in kernel? I found it loaded.
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n253861-92e6b4712b5-dirty: Sat Mar 19 02:40:21 GMT 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400053 1400053
%
 
It's not a typo, it's two sentences, one to say use xev alone as a command, and the next sentence that | grep keycode can be added to it. Maybe a semicolon would have been better. However, xev | grep keycode is implied.

The other one is where it should be added to kldlist, but that one is a bit better. Regular users know what to do. For new users, it's better to show them that with a +.

As for 14-CURRENT, anything is unlikely to stay permanent until the next release or STABLE, but this specific adjustment is likely to occur regardless. By future releases or by STABLE, usbhid is likely to be automatically loaded by default, than needing the user to use /boot/loader.conf for it, regardless of CURRENT.


=== === === ===
For some multimedia keys, xev doesn't always give a consistent keycode output. Also, once a program is tied to a multimedia keys, xev doesn't show the proper output. What works well is, holding down a key without an important function (even if it has its own keycode), like the Windows key, then pressing a multimedia key. This works consistently, even when a multimedia key is tied to another program.

Also, a lot of newer drivers are prefixed with an h, as older basic drivers with the old system were often prefixed with a u. ums -> hms; ukbd -> hkbd; wmt -> hmt. Right now, a lot of old drivers are still being used during the transition. A lot of newer drivers work also with iichid, but they also work with a more complete driver of usbhid.

Bluetooth isn't there yet for the usbhid system.
 
Updates:

  • About using USB gamepads/joysticks - post #11
  • Recognition of Bluetooth capable gamepad/joystick over applicable drivers, not usbhid - post #15
  • Antimicro: configuring and using (doesn't require manual dev configuration) - post #18
  • Configuring device permissions and testing gamepad/joystick - post #19
 
Last edited:
Earlier I was struggling to get the usbhid.ko module to work with my ZSA Moonlander Mark I keyboard. Even with that module loaded at boot, the GENERIC kernel from 13.1-RELEASE would use its builtin ukbd.ko module for it instead. Because of this, I wasn't able to use the multimedia keys that I assigned to my Moonlander's media layout.

And this is why I'm here posting how I solved my problem.

By using the handbook on customizing the kernel, I did the "include directive" approach and created a MYKERNEL file to remove ukbd.ko from being builtin by using the following:
Code: 
include         GENERIC
ident           MYKERNEL

nodevice        ukbd

As I was building my new kernel, I set the bootloader to not load ukbd.ko and its related modules while loading the usbhid.ko module by using the following (while hw.usb.usbhid.enable=1 was already used):
Code: 
ukbd_load="NO"
ums_load="NO"
uhid_load="NO"
usbhid_load="YES"

And my multimedia keys finally worked from booting into my newly built custom kernel and having verified it through KDE Plasma.
 
Last edited by a moderator:
Some described their keyboards as behaved differently. Theirs had different behaviors, so they got theirs to work before I got mine to work. Mine didn't work until around the time I wrote this, and more kinds are expected to work now. Mine now doesn't have that issue you described.

u-prefixed drivers still load on my computer shown from kldstat. I have ukbd enabled from my GENERIC KERNCONF. kldload ukbd shows it as already loaded (it's from the kernel itself). Both ums and hms drivers for my mouse showed up for kldstat. I tried disabling ums from loader.conf, but it still loads anyway. I'm able to kldunload both uhid and ums without any issues. I'll try disabling them by building a new kernel and through loader.conf. Maybe that driver in the kernel is causing the other ones to load. Disabling other older usb drivers is the direction the drivers are moving anyway. The old ones are there for redundancy or fallback during the conversion.

I was curious if hcons was loaded, before you tried that. I thought maybe your keyboard called for ukbd, or if you had it loaded unknowingly. But ukbd is a default setting (at this time), and you learned how to adjust the kernel afterwards. It was your keyboard's behavior with ukbd, which was different than mine. That piece of information helps make a few more types of keyboard work.

Updates:
I tried this. hkbd now shows up, but the old usb drivers still load. wmt and devd were calling on the old drivers. hmt is the replacement driver for wmt. Specific autoloading messages show up in my terminal, but not with dmesg. The older drivers are loaded, but don't show up in dmesg either. hcons for my multimedia keys has been working, even along side the older usb drivers.

After loading the replacement drivers and adding devd_enable="NO" to rc.conf.local rc.conf, the old usb drivers stopped loading. Edit: only disable devd for testing or temporary purposes, it needs to stay on.

I'm now using kld_list= in rc.conf to load the newer drivers, except for usbhid required in loader.conf.

I compiled these newer drivers, except usbhid, into the kernel, and everything still works. It's odd, how usbhid is set in loader.conf and loads as shown in kldstat, while dependent modules are compiled into the kernel.

KERNCONF:
Code: 
device  hcons
device  hmt
device  hms
device  hkbd
device  hsctrl

options EVDEV_SUPPORT
device  hconf
device  hid
device  hidbus
device  hidmap
device  evdev
nodevice  ukbd
kldstat shows: usbhid.ko.

Found device usbhid in /usr/src/sys/conf/NOTES! Compiling this last module in works, provided that usbhid="1" stays in loader.conf. This is still needed for my USB mouse and keyboard to function. With or without it, my laptop keyboard and touchpad are still functional.

It would be interesting to see this as the default for future releases. Bluetooth drivers listed at https://freebsdfoundation.org/freebsd-project/resources/networking-basics-wifi-and-bluetooth/ aren't loading the old uhid driver on my computer. Unsure if they're independent or now relying on usbhid. A few Bluetooth drivers mentioned on that list are depreciated or are otherwise not present.
 
Last edited:
Since you mentioned how devd_enable="NO" got the old usb drivers to stop loading, I had a random epiphany and tried grepping for them in /etc by using grep -rn "ukbd" /etc and I found something "interesting" in /etc/devd.conf, starting at line 108:

Code: 
# When a USB keyboard arrives, attach it as the console keyboard.
attach 100 {
        device-name "ukbd0";
        action "service syscons setkeyboard /dev/ukbd0";
};
detach 100 {
        device-name "ukbd0";
        action "service syscons setkeyboard /dev/kbd0";
};

I don't know if configurations like these in that file would be the culprit?
 
Disabling devd, may have been related to an issue that caused DHCP on IPv4 to not work. devd may have been compensating for an obsolete setting which was still used. Related Thread can-the-xf86-input-usbtablet-driver-be-ported-to-freebsd.85376:
Amooti said:
I tried the devd_enable="NO", but, although it enabled usbhid to activate without the older drivers, it also interfered with dhclient and blocked connection to the internet!
Click to expand...
Adding a netmask with a static connection temporarily fixed this. It may have been fixed by adding a netmask with DHCP, but I'm unsure it wasn't supposed to work this way. Thread ipv4-stopped-working-on-freebsd-13-1-release-manually-set-it-to-access-internet.85370

Update:
devd should only be disabled for testing and temporary purposes. The descriptions of devd's actions being disabled were correct. However, I had dbus in mind when I disabled devd. Avoiding use of dbus is a topic discussed on the forum. Disabling devd does cause the behavior described here. Disabling devd allowed ukdb to stop loading, and it caused the problem described. Also setting the netmask was a fix for that problem. The netmask needs to be addressed anyway.

If you need to disable ukbd and related drivers, compile the kernel without them as described in post #7 above.
 
Last edited:
USB (non-Bluetooth) gamepad/joystick
Plug in your USB gamepad or joystick to see hgame(4) loaded through kldstat. I didn't have the relevant hardware to try and test ps4dshock(4) and xb360gp(4). Loading either of these modules also autoloads hgame.

[Removed this section, because it was updated.]

Identifying hardware information
dmesg(8), kldstat(8) and usbconfig(8) give important information on system hardware. lsusb(8), from sysutils/usbutils, can also be used to show USB device data. The following are examples, after plugging in my gamepad through a wired connection to the USB port.

Message from dmesg:
Code: 
ugen0.5: <8Bitdo FC30 Pro 8Bitdo FC30 Pro> at usbus0
usbhid6 on uhub0
usbhid6: <8Bitdo FC30 Pro 8Bitdo FC30 Pro, class 0/0, rev 2.00/0.01, addr 7> on usbus0
hidbus6: <HID bus> on usbhid6
hgame0: <8Bitdo FC30 Pro 8Bitdo FC30 Pro Gamepad> on hidbus6
usbconfig:
Code: 
ugen0.5: <8Bitdo FC30 Pro 8Bitdo FC30 Pro> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (480mA)
lsusb:
Bus /dev/usb Device /dev/ugen0.5: ID 1002:9000
kldstat shows hgame automatically loaded:
13 1 0xffffffff8197a000 21e8 hgame.ko

You can see the same ugen number in many of these display outputs. This information can be used to map game controllers.

Antimicro
For a program that automatically detects gaming controllers and readily receives their inputs, install x11/antimicro. Start antimicro(1) to see if it recognizes your controller and to adjust its mapping. If it stops working, check to see that the gamepad is connected securely.
antimicro.jpg

With Antimicro, /usr/local/etc/devd/ configurations don't have to be set. This program doesn't set its own configuration files in that directory either. Gamepad configuration files are stored in the user's home directory as .joystick.amgp files, and under the .config/antimicro/ subdirectory as .ini files.

In addition, Antimicro was able to display events for some keyboard multimedia keys through keychecker.

https://github.com/AntiMicro/antimicro is Antimicro's homepage. This program uses SDL2. Other SDL game controller mapping programs can also be expected to identify your hardware and identify input strokes.

Alternative methods for mapping controller
Use information from identifying your hardware to edit custom configuration files for game controller mapping.

A common way of manually setting up your controller is by creating a custom .conf file in /usr/local/etc/devd/. Use this directory, rather than /etc/devd/ to prevent it from being overwritten. The default location of these directories is set from devd.conf(5). devfs.rules(5) also needs setting up.

To use your gamepad or joystick as a mouse on the desktop, x11-drivers/xf86-input-joystick can be tried. Using this may require setting up a custom /usr/local/etc/X11/xorg.conf.d/ file, according to joystick(4). xev(1) can be used for seeing this output. Thread howto-gamepad-and-freebsd.18454 has older instructions on using the xf86 joystick driver this way. I've used my gamepad this way before on an older usb system on a previous version of FreeBSD. The xf86-input-joystick driver now works on top of the usbhid infrastructure.

devel/libgamepad is of interest as it is described for BSD to work on libusb and with joy(3) from devel/allegro (https://liballeg.org/).

For SDL, x11/controllermap can also be tried. It identified my gamepad as a joystick, so the installed program testjoystick was relevant. This programs was capable of showing the output of my controller. For what it defines as gamepads, this program is tailored for Xbox style controllers. Output of testjoystick:
joysticktest.jpg

Another program that comes with controllermap shows a visual of an XBox style controller, and it tries to adapt my gamepad keys to that.
 
Last edited:
I tested my gamecontroller by clicking on Controller Mapping. Even though my game controller looks nothing like the one in the image from the screenshot above, it showed that same visual for my gamepad. The Link on that page, with the text Game Controller API goes to https://wiki.libsdl.org/CategoryGameController: its about an API for game controller mapping on SDL.


I'm curious about ps4dshock(4) being needed for any Playstation type of gamepad, even if it's not a dualshock or PS4 style, and about xb360gb for Nintendo controllers. Also, whether controllers that use ps4dshock and xb360gp work on Antimicro, or how well these work.

Do those additional drivers allow the controllers to use their buzz or do something else? For any gamepad that calls on these additional gamepad drivers, what does the hardware show for it from lsusb (from usbutils) and usbconfig.

The Nintendo Switch Horipad doesn't have vibration or motion control on it, according to online specifications.

stratact, does your Nintendo gamepad also load or require xb360gp(4), as shown on kldstat?

From another thread, relating to xb360gp:
derschwarzwelt said:
I emailed Greg, the creator of the xb360gp driver a couple of days ago and he responded. Apparently, the xb360gp driver does not support anything other than wired 360 controllers.
Click to expand...
 
Last edited:
I only see the hgame module being loaded. However, I'll just share my kldstat output if there is anything you can see that is relevant or helpful for your Howto.

Code: 
Id Refs Address                Size Name
 1   88 0xffffffff80200000  1f2f668 kernel
 2    1 0xffffffff82131000    262c0 fusefs.ko
 3    1 0xffffffff82158000   174010 nvidia-modeset.ko
 4    4 0xffffffff822cd000    32610 linux_common.ko
 5    3 0xffffffff82300000    8e8c8 linux.ko
 6    2 0xffffffff8238f000  2b626a8 nvidia.ko
 7    1 0xffffffff84ef2000     6af8 usbhid.ko
 8    8 0xffffffff84ef9000     6d40 hidbus.ko
 9    1 0xffffffff84f00000   5b93a0 zfs.ko
10    1 0xffffffff854ba000     a158 cryptodev.ko
11    1 0xffffffff85c10000     3378 acpi_wmi.ko
12    1 0xffffffff85c14000     21e8 hcons.ko
13    4 0xffffffff85c17000     30a8 hidmap.ko
14    1 0xffffffff85c1b000     83c0 hkbd.ko
15    1 0xffffffff85c24000     21e8 hms.ko
16    1 0xffffffff85c27000     21e8 hsctrl.ko
17    1 0xffffffff85c2a000    87098 if_iwlwifi.ko
18    1 0xffffffff85cb2000     3218 intpm.ko
19    1 0xffffffff85cb6000     2180 smbus.ko
20    1 0xffffffff85cb9000     4d00 ng_ubt.ko
21    3 0xffffffff85cbe000     aac8 netgraph.ko
22    2 0xffffffff85cc9000     a238 ng_hci.ko
23    2 0xffffffff85cd4000     25a8 ng_bluetooth.ko
24    1 0xffffffff85cd7000    1ae78 ext2fs.ko
25    1 0xffffffff85cf2000     4354 geom_linux_lvm.ko
26    1 0xffffffff85cf7000     21e8 hgame.ko
27    1 0xffffffff85cfa000     4700 nullfs.ko
 
Bluetooth recognition of gamepad
Got the computer to recognize the gamepad connected over my Bluetooth dongle, even though this USB dongle showed hardware errors through dmesg. That's as far as these instructions go: not sure if the controls work over the Bluetooth connection yet. In the examples below, my Bluetooth dongle uses ng_ubt(4).

Plugging in my Bluetooth dongle autoloaded the modules:
Code: 
 6    1 0xffffffff8192d000     4d00 ng_ubt.ko
 7    6 0xffffffff81932000     aac8 netgraph.ko
 8    2 0xffffffff8193d000     a238 ng_hci.ko
 9    4 0xffffffff81948000     25a8 ng_bluetooth.ko
10    1 0xffffffff8194b000     e250 ng_l2cap.ko
11    1 0xffffffff8195a000    1bee8 ng_btsocket.ko
12    1 0xffffffff81976000     39c0 ng_socket.ko

/etc/bluetooth/ contains configuration files of hcsecd.conf, hosts and protocols. Some of the commands below require pressing the Wifi/Bluetooth button on the gamepad within a few seconds beforehand. Be sure the gamepad is powered.

Before starting a service, add them to rc.conf, or use onerestart.
service hcsecd start is only required if a device requires pairing (authentication)
service bluetooth start ubt0
On my system, this often had to be entered twice for it to work, because the first time the command gave an error:
/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0

hccontrol -n ubt0hci inquiry
Code: 
Inquiry result, num_responses=1
Inquiry result #0
        BD_ADDR: 01:06:8b:5c:61:07
        Page Scan Rep. Mode: 0x1
        Page Scan Period Mode: 0x2
        Page Scan Mode: 00
        Class: 00:25:04
        Clock offset: 0x7a99
Inquiry complete. Status: No error [00]
The information from BD_ADDR goes into the next line,
hccontrol -n ubt0hci remote_name_request 01:06:8b:5c:61:07
Code: 
BD_ADDR: 01:06:8b:5c:61:07
Name: 8Bitdo FC30 Pro
For create_connection, /etc/bluetooth/hosts can be used.
hccontrol -n ubt0hci create_connection 01:06:8b:5c:61:07
Code: 
BD_ADDR: 01:06:8b:5c:61:07
Connection handle: 42
Encryption mode: Disabled [0]
hccontrol -n ubt0hci read_connection_list
Code: 
Remote BD_ADDR    Handle Type Mode Role Encrypt Pending Queue State
01:06:8b:5c:61:07     42  ACL    0 MAST    NONE       0     0 OPEN

Example /etc/bluetooth/hcsecd.conf:
Code: 
device {
        bdaddr  01:06:8b:5c:61:07;
        name    "gamepad";
        key     nokey;
        pin     nopin;
      }
The Bluetooth instructions from https://freebsdfoundation.org/freebsd-project/resources/networking-basics-wifi-and-bluetooth/ were adapted to my gamepad.

It's great that my gamepad was identified by the computer through the Bluetooth dongle, however, the keypad didn't show up on Antimicro through it. I noticed that the Bluetooth modules autoloaded, but hgame didn't, even after the Blueooth dongle made a connection the gamepad. There weren't further results after loading hgame. ng_hci(4), Netgraph Host Controller Interface, is of interest.

As for Bluetooth dongle drivers, v1.1 works. Some v2 dongles work, and certain Bluetooth audio (Thread using-bluetooth-audio-devices-speaker-headphones-earbuds-with-freebsd.78992) dongles work. There's lack of clarity on which v3 dongles work and how well. There have been varying claims about v4 or BLE dongles on FreeBSD. It has been claimed that documentation hasn't caught up. In the example above, my USB Bluetooth dongle is v3. Despite my hardware showing errors through dmesg when the drivers/modules autoloaded, it was correctly able to find and identify my gamepad.

There are additional Bluetooth drivers and applications in ports which can be found by psearch bluetooth. comms/bluez-firmware is a Bluetooth v1.1 dongle adapter which is used on top of ubtbcmfw(4) and ng_ubt(4) kernel modules. comms/iwmbt-firmware is a driver available in binary form for an Intel Wireless 8260 adapter card with Bluetooth v4 capability. pciconf -lv may be needed for getting information from hardware cards.
 
sidetone said:
Edits: Do those additional drivers allow the controllers to use their buzz or do something else? For any gamepad that calls on these additional gamepad drivers, what does the hardware show for it from lsusb (from usbutils) and usbconfig.

The Nintendo Switch Horipad doesn't have vibration or motion control on it, according to online specifications.

I tested my gamecontroller by clicking on Controller Mapping. Even though my game controller looks nothing like the one in the image from the screenshot above, it showed that same visual for my gamepad. The Link on that page, with the text Game Controller API goes to https://wiki.libsdl.org/CategoryGameController: its about an API for game controller mapping on SDL.
Click to expand...
Ah, forgive me. I took me a while to realize you were asking me this question directly instead of just anyone else. I suppose those "thanks" pings were to get my attention. 😆

From doing a kldstat output comparision of a before and after when plugging in my Horipad (since I rebooted relatively recently), the only the difference was the hgame.ko being loaded. The other drivers listed in my prior post weren't relevant.

Also, I will provide you a dmesg output of when I plugged in my Horipad. Hopefully this might be useful for you:

Code: 
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR
ugen2.3: <HORI CO.,LTD. HORIPAD S> at usbus2
usbhid5 on uhub2
usbhid5: <HORI CO.,LTD. HORIPAD S, class 0/0, rev 2.00/5.72, addr 2> on usbus2
hidbus5: <HID bus> on usbhid5
hgame0: <HORI CO.,LTD. HORIPAD S Gamepad> on hidbus5
 
stratact said:
I took me a while to realize you were asking me this question directly instead of just anyone else. I suppose those "thanks" pings were to get my attention. 😆
Click to expand...
That's an assumption. It was because, from them, I later noticed something that was relevant to something else. I was asking directly for the paragraph that mentioned you. My other question was for anyone whose hardware loaded xb360gb.

I was commenting on your controller and how that program showed the same style on the visual, even though it looks nothing like mine. But it wasn't one that used xb360gp. A comment from elsewhere helped me see that that module was more limited and didn't cover many other Nintendo gamepads.

I added the separation, as the rest was for someone who had a device that had the kinds of controller that loaded that and ps4dshock. I questioned why those two additional modules of xb360 and ps4dshock were needed: if they were for some features. I was curious about the messages from gamepads that needed those 2 modules. That part of the question was to anyone who had those, so I could understand it and it could be documented better. I didn't think u had those. Anyone who has them can conveniently answer that.

This post is also useful as it's an example of a Nintendo gamepad which doesn't use xb360gp. The manufacturer and model is informational. That's an adequate amount of examples and descriptions for Nintendo style game pads that only use hgame and don't use the xb360gp module. Mine is a Nintendo style gamepad too by a different manufacturer for a retro Famicon. Consoles have had 3rd party manufacturers for their systems and retro style products.

I wish I could get my edits right earlier, but I realize things later. Sometimes, I keep learning and I'll slowly make new connections how different things apply. I'll edit that one, and clear it up better.

This post helped me see something, how dmesg has some of the same information that's output of other commands. The module (hgame), model description, for instance. Earlier, I noticed how the same bus was used in a few of those outputs, which helped to keep track of which ones were describing the same pieces of hardware. I'm looking into usbhid-dump(8) (sysutils/usbhid-dump) for outputs of usbhid devices, however, the manpage warns about the potential for streams to cause a loss of control of USB keyboards.

The kldlist showing of modules helped for comparing them to see about Netgraph and Bluetooth.



After comparing several outputs, some drivers directly show they're being used on the newer usbhid. My Bluetooth or Netgraph hardware doesn't show this. On mine, uhid (loaded from /boot/loader.conf) wasn't referenced either from my Bluetooth hardware. Hardware outputs would be useful for Netgraph, Bluetooth, xb360gb and ps4dshock devices. Any other hardware output display can be shown if it's unique. Bluetooth and Netgraph may deserve another thread, more of a problem sovling one to understand and document what's available and how far they can be used.


Edit: anyone reading this thread, please see updates above about devd.
 
Antimicro: configuring and using

Leaving controller functionality enabled
Antimicro must be left on for the game controller to continue to function. This application can be minimized in the system tray: it has options for setting this. Antimicro can be started through .xsession, .xinitrc or your window manager configuration file. Whenever a game controller is unplugged and reconnected, joysticks must be updated from the menu (Update Joysticks), or Antimicro must be restarted. Auto Profile can be set so that the a game controller's detection won't have to be updated after each launch of the application.

Unlocking buttons and directional controls
controllermap.jpg

Using Controller Mapping allowed more functions that are available on my physical gamepad to become visible in the controller map, as long as the controls matched the ones on the visual. Even though my gamepad looked nothing like the one in the picture and it looked simpler, it had nearly all of its controls. Some mappings that don't have an equivalent on the physical controller can be left blank: use your mouse to select another mapping.

For assigning keys, hide empty buttons meant for the controller must not be checked, or otherwise Quick Set will be needed.

Variations of gamepad
My gamepad's buttons are labeled in a different order on the physical controller, than as suggested by the controller visual in the mapping application: for instance, A and B buttons were switched, as well as X and Y buttons. If this is an issue, the visual mapping for these controls that are in different locations on your physical gamepad can be ignored, and these buttons can be compensated for through the mouse and keyboard mapping selection.

Applying controller to desktop and windows
For the controller to be used on the desktop, not limited to within Antimicro: keyboard keys, mouse controls and other functions must be assigned to the controller buttons and sticks.
animation of visual gamepad diagram also showing control being used.gif

By assigning mouse controls, your game controller can be used for your desktop just as a mouse. Controls set to keyboard buttons will remain confined to use in terminals, windows and desktop portions which are in focus (or where the screen cursor is hovering over). A combination of keyboard and mouse controls can be used for a gamepad.

A directional stick can be used for controlling the mouse, while another can be used for scrolling. One way of playing video games, is to assign keyboard arrow keys to a gamepad directional pad or stick. This will basically work on games, even if the game itself won't detect the game controller.

Multiple controller sets of functions for each gamepad configuration file
You can have multiple Antimicro named Sets (tabs) for a single controller map (within the same configuration file) to use it for multiple purposes with different button and axis functions, for example: as a mouse, as a multimedia remote, as a document scroller, for hotkeys, for varying video games set to different keys, for specialized purposes and for any combination. For physical controllers which vary from the controller diagram, another set can be made for each variation for playing games which label buttons to those letters. For applications that don't need an additional axis stick, one can serve for moving the mouse cursor.

Events and keycodes
Once mouse and keyboard controls are mapped to the game controller, xev(1) can be used to show events from the gamepad or joystick.

Assigning multimedia keys to game controller
amhotkeys.jpg

Keyboard multimedia keys can be set up on your gamepad too. The selection of multimedia key assignment may provide a keycode and show an X86 key which may not match the keycode and XF86 key of the device provided by xmodmap -pke. It's easier to select the XF86 key that matches the description in Antimicro's key assigner. Then, find the keycode and XF86 name with xev. Then use the hotkey configuration from your window manager to set that XF86 name (even if it has the wrong description) to the desired command.

Closing remark
It would be interesting to know if the tablet driver hpen(4) which uses usbhid can be used with Antimicro.
 
Identifying Vendor ids, Product ids and other information
Type usbconfig, to identify which ugen number your usb plug is connected to. Then, include that into the next command, for example, usbconfig -d 0.2 -v | grep -iA1 vendor. This will give you the vendor and product ids of your device.

lsusb can also be used, as the two numbers on each side of a colon next to ID contain identifying parts of the Vendor and Product id. Each of these two numbers needs to be prefixed with 0x to get the vendor and product id.

When a USB connection is plugged in, ugen with the bus and device number will usually show up first. From the dmesg(8) log, the drivers used, including driver architecture, will be shown. The name of these drivers will show up again, when the device is disconnected. hgame(4) relies on usbhid(3), hidbus(4) and ugen(4). usbus is related to the USB controller driver.

xb360gp(4) and ps4dshock(4) are modules for specific hardware that automatically load hgame. If your gamepad could be of either of these, check dmesg to see if one loads after plugging it in.

It's possible that a single hardware device can have an additional vendor and product ID depending on the type of connection mode (wired, wireless or specifically Bluetooth) it uses, according to the drivers that mode calls on.

Setting up dev permissions
Set /etc/devfs.rules to:
Code: 
[localrules=10]
add path 'input'   mode 0775 group wheel
add path 'input/*' mode 0660 group wheel
The reference to this section must be included in /etc/rc.conf:
Code: 
devfs_system_ruleset="localrules"
Run service devfs restart for devfs.rules(5) settings to take place. If the section name has been changed, devd(5) needs to be restarted before devfs rules can be applied. Then, check /dev/input/. It's important that the directory itself has execute permissions unlike the contents within it.

Then, create a .conf file in /usr/local/etc/devd/. Any custom name can be used, provided it ends in .conf. In this example, gamepads.conf contains multiple controllers. Additional controller entries have identical values, except for the vendor and product entries.
Code: 
notify 100 {
       match "system"          "USB";
       match "subsystem"       "INTERFACE";
       match "type"            "ATTACH";
       match "vendor" "0x1002";
       match "product" "(0x9000|0x9001)";
       action "chgrp wheel /dev/$cdev; chmod 660 /dev/$cdev";
};
notify 100 {
       match "system"          "USB";
       match "subsystem"       "INTERFACE";
       match "type"            "ATTACH";
       match "vendor" "0x1003";
       match "product" "0x9100";
       action "chgrp wheel /dev/$cdev; chmod 660 /dev/$cdev";
};
After this, run service devd restart. If there's a syntax error, it will give a warning. The controller will have to be reconnected after running this command. Check the permissions within /dev/usb/ to see that they match the intended permissions. If the correct vendor and product number for your device are entered, the permissions for that device will take effect.

If you want to see display of the .conf files being loaded, you can stop devd, then run devd -d. The gamepad can optionally be reconnected here to see additional output. Use CTRL-C to quit this console program, then restart devd as a daemon, and reconnect your gamepad.

Be sure your user belongs to the wheel group.

Unsure if additional configuration is needed for modes, features or basic functionality of gamepads that use either xb360gp or ps4dshock modules.

Testing and using gamepad
This controller's outputs can be tested on emulators/joytran. It displays gamepad events that aren't assigned to keys or mouse controls. My controller is detected and works natively on some games. For other games, Antimicro is needed. For quick testing of configuration changes related to the above instructions, joytran -l can be used to show whether a joystick is detected.

Interestingly, joytran can be tried for basic detection and for identifying events of other types of hid devices: maybe including tablets that use hpen(4).
 
I have a couple of WASD Keyboards (a few years old, not the latest version(s)).

On those keyboards, the multimedia keys are function keys overlayed on top of the Pause, Insert, Delete, Home, End, PgUp and PgDn keys.
The "context menu" key (between the Super and Ctrl keys on the right side) is used to "activate" those multimedia keys (key-combo).

When I press those key combinations while doing xev | grep keycode nothing shows up. Other keys show up as expected.
Both usbhid.ko and hcons.ko are loaded.
These multimedia keys work out-of-the-box on Windows (and Linux).

What blackmagic am I missing?
 
Post the dmesg from hot-plugging it. Even though, you mentioned that hcons is loaded, see if the specific hardware calls the driver(s). It may be good to see other information from dmesg too. Also, use dmesg to see if older drivers are loaded, as uhid and drivers dependent on it can interfere.


Did anything show up with xev without grep? See if any events show up from joytran. My keyboard regular keys and multimedia keys show events in this program. If it doesn't, it could be about /dev/ permissions. My mouse doesn't show anything with this application.

Mine has a few Function keys on top of regular keys too. (Edit: Function keys seem to be separate than Multimedia keys, but they can be Multimedia keys too). After getting xev to work, they all show. My Windows key and Function key work a bit differently when combined with other buttons.

It could be the permissions, which how to adjust those is in the previous thread about joysticks. It could be about if the older drivers are loaded, which interfere.

It may need a combination of instructions from this thread. Some solutions for potential issues are addressed on this thread. There was troubleshooting about uhid and related drivers being automatically loaded, if this is the case.
 
sxhkd to define multimedia keys
This is useful for window managers which don't have their own configuration file, for simpler configuration or for a better program for multimedia key control. Install x11/sxhkd, and edit ~/.config/sxhkd/sxhkdrc. Here's sample code for multimedia volume keys and a few other utility keys:
Code: 
XF86Audio{Mute,LowerVolume,RaiseVolume}
        mixer {0,vol -3, vol +3}
XF86{Calculator,Tools,Search}
        {xcalc,deadbeef,thingylaunch}
xmodmap -pke and xev are helpful finding the desired keys. JWM for instance, has a more complicated way of setting multimedia keys, and sxhkd seems to be better for it.
.jwmrc
Code: 
<Key key="XF86AudioMute">exec:mixer 0</Key>
<Key key="XF86AudioRaiseVolume">exec:mixer vol +3</Key>
<Key key="XF86AudioLowerVolume">exec:mixer vol -3</Key>
Thread howto-jwm-configuration.59265

Turn on sxhkd through .xsession, .xinitrc or other default window manager startup file. Sample code for .xsession:
Code: 
sxhkd & osdmixer d d d d &
bgs -z /f/backgrounds/default.jpg &
#/usr/local/bin/mcwm & exec /usr/local/bin/xterm
exec /usr/local/bin/mywindowmanagerexample
 
I'm having issues to have a USB drawing tablet (XP Pen Star G640) to work on FreeBSD 13.1

I have used the pkg "antimicro" to detect the USB drawing pad, and it does detect it only via terminal, however nothing works.
GIMP is also able to detect the drawing tablet but when ever I use the pen stylus to draw/move the mouse nothing happens.

Thanks for any info.
 
First_Law_of_Unix said:
I'm having issues to have a USB drawing tablet (XP Pen Star G640) to work on FreeBSD 13.1
Click to expand...
I'm not sure if tablets have worked, beyond being recognized or having raw input. If they have worked well enough, it was likely through using the Xorg input driver. It's likely that it would work in a way in addition to much of the way in this thread.

Using the Xorg driver and configuration is is expected to treat the pad like a mouse for use for the whole screen, which would still be good for draw pad purposes. You can try Thread howto-gamepad-and-freebsd.18454 for this method, and continue researching it. It's possible that the base driver would have to be loaded much through the way in this thread, then the xorg driver on top.

First_Law_of_Unix said:
I have used the pkg "antimicro" to detect the USB drawing pad, and it does detect it only via terminal, however nothing works.
Click to expand...
If Antimicro worked fairly well enough, it also requires being kept on in the background. It also requires a little configuration. When you say detect, do you mean it detects the actual device, or it detects moving/pressed inputs? Can you be a little more specific? I may not be able to have an answer, but it may help someone else troubleshoot, or leave a track for others to figure out the next step.

I hope someone figures it out or shows how they did it.


On another topic: above, I made a misinterpretation about Bluetooth. That it has used the libusb subsystem for a while, which the main HID drivers on FreeBSD more recently caught up to with a universal, more modern and different way. I may have made a few minor misinterpretations also. It takes attention to the articles in the FreeBSD Journal about Bluetooth.
 
Last edited:
You must log in or register to reply here.
Back
Top