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

[First_Law_of_Unix]

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.

It only detects the device itself via terminal, I can see the device name and model, however no buttons or pen stylus are recognized, Antimicro shows no activity both for GUI and terminal.
Only simply shows the device name on Antimicro terminal and on the GUI it shows nothing, not even the device name.

I did some research and it seems that the XP-Pen tablet requires a lockbit signal to unlock it's features or activities. This requires to reverse engineer and dump codes or what not.

T-Dameon mentioned that I'm using an old driver of libwacom, however the github version is updated and happens to support XP-Pen tablets. I'll install the new update and will see what happens.

Thanks.

 

[sidetone]

Go with much of what's on this thread: for the driver module in the base, and the way to allow the permissions. Those parts are important for the now missing next steps.

Webcamd is an alternate way to get the driver permissions accessed. Antimicro somehow bypasses the HID driver permissions, and not all classes of HID devices work on it anyway.

Antimicro is one way for certain HID devices. Since it doesn't work on everything, such as a tablet in your case. Try joytran, which is described on this thread, to see if any input shows. It likely won't fully work, but it will be useful to see terminal output of any movement/key-press input, also in the case that the device may need more drivers because of some lock. The last step(s) would be between Xorg configuration, the rest of webcamd, what T-Daemon wrote about, or an alternate way.

T-Dameon mentioned that I'm using an old driver of libwacom, however the github version is updated and happens to support XP-Pen tablets. I'll install the new update and will see what happens.

I saw that you tried https://wiki.freebsd.org/WacomTablet. Anything like that may need the base module driver loaded and permissions set as prerequisites.

 

[iNOP]

Hello.

I have a keyboard with multimedia keys and did as instructed in the first post.

After booting the system, all settings are applied:
> sysctl hw.usb.usbhid.enable
hw.usb.usbhid.enable: 1
> kldstat | grep usbhid
11 1 0xffffffff82975000 3380 usbhid.ko


But multimedia keys don't work until I issue the command to restart the keyboard:
> usbconfig reset ugen0.0

How to automatically enable multimedia keys?
Thanks in advance

 

[Vladimir Kondratyev]

How to automatically enable multimedia keys?

Just load usbhid from kernel loader rather than from rc script. Add to /boot/loader.conf
usbhid_load="YES"

 

[Andriy]

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:

My personal preference is to add inet(evdev) (or whatever is appropriate) to XKB symbols.

 

[nxjoseph]

Hi. I'm new to FreeBSD.

13.2-RELEASE
FreeBSD desktop.myhome.local 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64

My multimedia keys was not working and I fixed it with your help, thank you. They wasn't being detected by xev until i enable usbhid.

 

[Alexander88207]

I do use the 8BitDo SN30 Pro - Weird and it works halfy with the base system stuff.

The controller map gets found correctly but button presses on stuff like the complete d-pad gets not regonized.

I ended up using multimedia/webcamd for having full functionallity.

If the controller is booting with the system then webcamd and hgame is picking up both the controller which is not what you want.

When using it with webcamd disable loading of hgame or connect the controller after system boot.

 

[sidetone]

Volume controls for sxhkd in FreeBSD 14.0
On FreeBSD 14.0, the syntax of mixer(8) has changed, so it operates differently than in previous versions. To change volume...
mixer vol.mute=^ toggles mute. 1 or 0 can also be used
mixer vol.mute=1 can also be used to mute
mixer vol.mute=0 or the toggle command is needed to unmute
mixer vol=-.03 is a example for decreasing volume.
mixer vol=+.03 an example of increasing volume

This also relates to multimedia hotkeys. In my ~/.config/sxhkd/sxhkdrc for volume:

XF86Audio{Mute,LowerVolume,RaiseVolume}
     mixer vol={0,-.03,+.03}

There's different benefits and disadvantages to using the various ways of muting. The newer way can toggle mute, while, it not showing up on the volume display of osdmixer.


Gamepads on FreeBSD

I do use the 8BitDo SN30 Pro - Weird and it works halfy with the base system stuff.

The controller map gets found correctly but button presses on stuff like the complete d-pad gets not regonized.

I have an 8BitDo controller of a different model, but it has the same basic layout. All keys were recognized with x11/antimicro. While the visual layout on AntiMicro shows a Playstation style controller, the amount of keys and labels almost match the buttons and directional controls of the SNES style (with additional analog sticks) pad, and IIRC, other keys can be manually added. Antimicro is odd, that it doesn't use the device permissions set in either hgame/usbhid and or through multimedia/webcamd. Antimicro can be used to configure for now and learn about, but it can't be the future default, the way it's configured, unless it's fixed to work without bypassing device permissions.

I ended up using multimedia/webcamd for having full functionallity.

If the controller is booting with the system then webcamd and hgame is picking up both the controller which is not what you want.

When using it with webcamd disable loading of hgame or connect the controller after system boot.

If that's what you need to use.

There's a way to set it up full controls without Antimicro, that I saw, but it's too complicated to manually configure that. Not sure if Antimicro was working in conjunction with the hgame driver, as I believe I used Antimicro before these newer drivers were available. I used my 8bitdo controller on a video game before hgame came along.

I believe that in the future, it has to be hgame with the infrastructure FreeBSD comes with, taking improvements or parts from webcamd with lessons from Antimicro and have configurations worked out. hgame and webcamd have in common how device permissions are set.


webcamd came before the newer HID drivers entered FreeBSD, including the I2CHID drivers which were meant for everything except Apple hardware. Webcamd has been a solution to add BSD components around Linux drivers. Also, there's overlap of other drivers in Webcamd and of other newer components within FreeBSD. I believe Webcamd needs to work its parts around the FreeBSD drivers which now exist, and the parts it has replace Linux parts. Antimicro is a GNU/Linux solution, and it somehow bypasses permissions to drivers.

SCUMMVM and SDL have gamepad drivers, that either override the FreeBSD drivers, or work in conjunction with them.

 

[Alexander88207]

There's a way to set it up full controls without Antimicro, that I saw, but it's too complicated to manually configure that.

Well thats what i am doing and its not complicated at all.

Wine and other things like Dolphin can detect the controller by using the SDL library. So you dont need to map stuff at all.

By using webcamd you are using the linux drivers so that most controller will get detected well.

 

[sidetone]

too complicated to manually configure that.

Well thats what i am doing and its not complicated at all.

By using webcamd

I wasn't referring to that. There's a way to set up full controls with hgame running, without Antimicro, webcamd, sdl or scummvm, which I have already mentioned those ways. The complicated way is to manually edit a file for the controls, and know/find the values so the controller, including the directional pad, runs smoothly. Configuring the controls manually by using a file is complicated, that I haven't done that.

I have already mentioned sdl, scummvm and webcamd as working, plus those are more or less automatic. The manual way which was complicated didn't include those. I wouldn't rely on configuring a file manually for typical use, but would set it up in a rudimentary way to learn about it. The values, for instance, the numerical values for the sensitivity of the directional pads and sticks, would be placed in that file.

Using Xorg joystick is one way to manually set it up per file, but that treats it like a mouse, and so does Antimicro. As long as the cursor is over the game, so the pad controls what's within the window, using a gamepad like a mouse in that it has full screen functionality works. I believe there's another way, with using hgame, and with manually editing a configuration file, for controlling the gamepad. Antimicro also produces a configuration file, which can be useful for seeing and copying values, though I only know how to use that file with Antimicro. When using Antimicro, I'll set one analog directional stick to move the mouse cursor, which I can move back over the game window, if it falls off of it.

 

[sidetone]

Update: FreeBSD 14 series still has both uhid and usbhid drivers.

To enable usbhid and its newer drivers, and to disable older drivers of uhid, /boot/loader.conf:

hw.usb.usbhid.enable="1"
usbhid_load="YES"
uhid_load="NO"

While /etc/sysctl.conf can accept hw.usb.usbhid.enable="1", this method doesn't work very well: use loader.conf instead, to load this properly and sooner. This part is still required for FreeBSD 14 series. Loading through /etc/rc.conf can be bypassed by doing this.

Then, x11-drivers/xf86-input-evdev is required for usbhid keyboard drivers to work in Xorg. It's helpful that Ctrl-Alt F# still works to change terminals, even from within X, and additionally that the keyboard works through the terminal console, to install this driver, then restart X. Without this X86 driver, the keyboard still also works in the display manager.

While they keyboard and other HID peripherals worked pretty well by having both sets of drivers installed, the keyboard works better by not having both sets of drivers loaded. The keyboard has additional drivers, like for multimedia keys, through the newer usbhid driver.

While usbhid can also be loaded by compiling it into the kernel, unsure if that replaces enabling usbhid from loader.conf. It's possible that disabling uhid(4) and ukbd(4) in certain cases, like compiling the kernel leaving that out, if a mistake is made in loading usbhid, could make the keyboard unusable, even possibly making a necessary reboot difficult. See usbhid(4) especially, rather than the default usbhid manpage.

 

[bsduck]

This part is still required for FreeBSD 14 series.

Thanks. Do you know if there are plans to make it enabled by default on future releases?

 

[sidetone]

Do you know if there are plans to make it enabled by default on future releases?

When usbhid is enabled, Yubikey (webauth u2f security) is reported to not work, and there's still an open bug report on that: Thread yubikey-security-key-u2f-help-requested.93331 & PR 265528. Yubikey may rely on hidraw(4), according to Thread using-yubikey-otp-with-hid-with-yubikey-fido2-ed25519-sk-for-ssh-does-not-work-properly.88531/#post-614883, which works with uhid rather than usbhid. Does anyone know if there's a USBHID replacement for hidraw, or way for hidraw to work with USBHID?

There's also Thread mouse-in-console-with-usbhid-active.91411 from last December, which says how evdev wasn't called up to work with certain mice, and usbhid doesn't support sysmouse. That thread has a working solution, but don't know if this issue has been improved in base since then. When adjusting my settings yesterday, my mouse worked without needing additional configuration.

usbhid with its newer drivers will have to be the default someday, because it's universal. iichid (i2chid) doesn't work for all devices, namely for Apple products.

 

[nxjoseph]

While usbhid can also be loaded by compiling it into the kernel, unsure if that replaces enabling usbhid from loader.conf. It's possible that disabling uhid(4) and ukbd(4) in certain cases, like compiling the kernel leaving that out, if a mistake is made in loading usbhid, could make the keyboard unusable, even possibly making a necessary reboot difficult. See usbhid(4) especially, rather than the default usbhid manpage.

I had faced with keyboard not working issue but loading hkbd(4) fixed the issue. I don't know the current situation, maybe it's been fixed already.

You can look at PR 279953 for details.

 

[sidetone]

I had faced with keyboard not working issue but loading hkbd(4) fixed the issue. I don't know the current situation, maybe it's been fixed already.

You can look at PR 279953 for details.

For convenience, according to that, the keyboard driver didn't load in single user mode, unless it was compiled into the kernel, or loaded through loader.conf, so the following is also needed:

hkbd_load="YES"

Edit: For expansion of discussion on still occurring issues with enabling USBHID and potentially disabling UHID: Thread show-problems-of-enabling-usbhid-for-modern-drivers.94990. Discussion can continue here, but there's a delay, and more troubleshooting, including in closer real-time, can be done and linked to from there.