Some keys of portable keyboard not responding

john_rambo

john_rambo

keyboard.png

I have been using this portable keyboard under Linux for 3-4 years now. Under FreeBSD all keys are working except the Vol +/- so I can't adjust the volume from a distance. Under Linux when I pressed the volume keys an OSD used to appear which I guess is a part of pulseaudio. Is there a way to make the volume buttons to work under FreeBSD ?
 
you can run xev in your desktop environment and observe if the keycodes are registered. If they are, well then it's only about assigning them to a command/script to raise/lower volume. In FreeBSD, by default we are using the OSS implementation and volume is controlled by mixer command. If you are using pulseaudio, then you'll have to consult the pulseaudio manpage.
 
A user on reddit told me about xev so I launched it using the terminal & then using the Run Application (ALT+F2) . In both cases a GUI Window appeared & no matter which key I pressed both on my portable keyboard or main keyboard there was no response. This is the xev window
xev.png
 
Added hw.usb.usbhid.enable=1 to /boot/loader.conf & did a full reboot but still the volume keys are not working.
 
john_rambo said:
Added hw.usb.usbhid.enable=1 to /boot/loader.conf & did a full reboot but still the volume keys are not working.
Click to expand...
Try iichid. One thing, this keyboard have those proprietary usb dongles, right? Because if it's bt, maybe hw.usb.usbhid.enable=1 will not work for him.
 
How do I use iichid ? I am not that familiar with FreeBSD.
Can I use any of the rest of keys which are working as a substitute for the volume keys ?
I just want the ability to control the volume when I watching Youtube from a distance sitting on my bed.
 
Add this line to your rc.conf, (or add the modules if there's already a kld_list there):
Code: 
kld_list="ig4 iicbus iichid"
 
Menelkir said:
or add the modules if there's already a kld_list there
Click to expand...
There's already a kld_list. How exactly do I add the modules ? If I make a mistake while editing this file will the system become unbootable ?

Code: 
cat /etc/rc.conf
zfs_enable="YES"
kld_list="linux linux64 cuse fusefs /boot/modules/i915kms.ko"
linux_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
devfs_enable="YES"
devfs_system_ruleset="devfsrules_common"
dbus_enable="YES"
lightdm_enable="YES"
webcamd_enable="YES"
cupsd_enable="YES"
avahi_daemon_enable="YES"
avahi_dnsconfd_enable="YES"
moused_enable="YES"
ipfw_enable="YES"
firewall_enable="YES"
ifconfig_re0="DHCP"
wlans_rtwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
keymap="us.kbd"
hostname="home"
 
Added kld_list="linux linux64 cuse fusefs /boot/modules/i915kms.ko ig4 iicbus iichid" to /etc/rc.conf & did a reboot. Volume keys are still not working.
 
iichid is not going to help. This is a wireless keyboard, so obviously it cannot be connected via I2C.
Most likely it's connected via USB.
 
Andriy said:
iichid is not going to help. This is a wireless keyboard, so obviously it cannot be connected via I2C.
Most likely it's connected via USB.
Click to expand...
Yes its connect via USB. The lsusb command is not working under FreeBSD otherwise I would have given you the hardware info.
 
Andriy said:
xev reports events in the terminal it's started from, there will be nothing in its window.
Click to expand...
Yes, I just got that idea from reddit. Bad news is while all the other keys are showing activity under xev the volume keys are not showing any activity at all so I guess there is nothing anyone can do to fix this.
 
john_rambo said:
Yes, I just got that idea from reddit. Bad news is while all the other keys are showing activity under xev the volume keys are not showing any activity at all so I guess there is nothing anyone can do to fix this.
Click to expand...
You can check if your system registers the interrupts coming in, via vmstat -i. For me, I can see the keyboard interrupts as irq33: xhci0
Another way is sysctl hw.intrs

If yes, then there's definitely something that can be done. I solved something similar in linux (keys not registering in xev), but unfortunately can't remember the details, it was a long time ago.
 
matt_k said:
You can check if your system registers the interrupts coming in, via vmstat -i. For me, I can see the keyboard interrupts as irq33: xhci0

If yes, then there's definitely something that can be done. I solved something similar in linux (keys not registering in xev), but unfortunately can't remember the details, it was a long time ago.
Click to expand...
When I use the command vmstat -i the commands completes immediately. So I entered the command twice. Once before pressing the volume buttons & then after pressing the volume buttons to compare if there's any difference between the two outputs but I can't spot any difference. This are the outputs

Before pressing volume button on keyboard
Code: 
~> vmstat -i
interrupt                          total       rate
irq1: atkbd0                           8          0
irq9: acpi0                            5          0
cpu0:timer                       6470716        362
cpu1:timer                       4091136        229
cpu2:timer                       4208470        236
cpu3:timer                       4006184        224
irq128: xhci0                    2817994        158
irq129: ahci0                     365310         20
irq131: re0                            1          0
irq133: hdac0                     882518         49
irq134: vgapci0                  2918300        163
Total                           25760642       1443

After pressing volume button on keyboard

Code: 
~> vmstat -i
interrupt                          total       rate
irq1: atkbd0                           8          0
irq9: acpi0                            5          0
cpu0:timer                       6473230        362
cpu1:timer                       4091457        229
cpu2:timer                       4208892        235
cpu3:timer                       4006539        224
irq128: xhci0                    2818745        158
irq129: ahci0                     365707         20
irq131: re0                            1          0
irq133: hdac0                     882518         49
irq134: vgapci0                  2918366        163
Total                           25765468       1441
 
Andriy said:
xev reports events in the terminal it's started from, there will be nothing in its window.
Click to expand...
Those keyboards have a proprietary dongle, some of them act as a usb keyboard, it's difficult to know exactly since they're a proprietary thing. Unless, of course, it's just bluetooth.
 
Menelkir said:
Those keyboards have a proprietary dongle, some of them act as a usb keyboard, it's difficult to know exactly since they're a proprietary thing. Unless, of course, it's just bluetooth.
Click to expand...
This the device info

Code: 
~> usbconfig
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.2: <Realtek 802.11n NIC> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen0.3: <Logitech USB Optical Mouse> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen0.4: <Dell Dell USB Entry Keyboard> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen0.5: <vendor 0x2318 2.4G Composite Devic> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

I know this a stupid question. I am paranoid about security. Is there any security risks in using this proprietary dongle ?
 
john_rambo said:
I know this a stupid question. I am paranoid about security. Is there any security risks in using this proprietary dongle ?
Click to expand...

Usually no since the dongle have a single purpose, but you cannot be 100% sure because it's closed source.
john_rambo said:
ugen0.5: <vendor 0x2318 2.4G Composite Devic> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
Click to expand...

Eh.. this one doesn't act like an USB device, unless I'm looking to the wrong device.
 
Menelkir said:
Usually no since the dongle have a single purpose, but you cannot be 100% sure because it's closed source.


Eh.. this one doesn't act like an USB device, unless I'm looking to the wrong device.
Click to expand...
The command lsusb doesn't work on FreeBSD so I searched the web and found the command usbconfig. Which command under FreeBSD is the equivalent of the lsusb command ?
 
john_rambo said:
The command lsusb doesn't work on FreeBSD so I searched the web and found the command usbconfig. Which command under FreeBSD is the equivalent of the lsusb command ?
Click to expand...
That's usbconfig, there's some parameters you can dump some details from the device (I don't remember exactly the parameters, man have some examples).
 
john_rambo said:
irq128: xhci0 2818745 158
Click to expand...

john_rambo said:
irq129: ahci0 365707 20
Click to expand...

Please observe these two lines and write down the values in the "total" column (2818745 and 365707 in this example)
  1. run vmstat -i again immediately by pressing only the up arrow key and the enter key, press nothing else and write down the two values (in my case, one of those would be off by +8, this number is X from now on)
  2. now press one of the problematic buttons exactly 20x, count the number of presses, run vmstat -i (press nothing else during this step)
  3. had the value in the "total" column increased by (20*X/2)+X? (in my case that would be +88)
  4. if yes, then hurray, it's sending interrupts.
 
You must log in or register to reply here.
Back
Top