Forum > General

I am developing a SW-AMP audio player project. Help with Dbus, GDbus, mpris!

<< < (2/3) > >>

If i test /dev/input/event3:AT Translated Set 2 keyboard then   Event code 164 (KEY_PLAYPAUSE) not send event.

Let's get the bad news out of the way first. I'm pretty sure that if a particular scancode doesn't show up in evtest you've got a major problem, since the kernel (module/driver) doesn't know how to convert the code coming from the device to one of the standard events. And if it's not translated to a standard event, I'd not expect it to be passed to X11... I'd be surprised if it got to DBus etc. and I'd similarly be surprised if it were available via the HID API since the problem is largely down to parsing the device description metadata and the "quirk" level ** . But it might be worth investigating that, since I believe there's been quite a lot of HID interface work done by members of the FPC community.

I'd strongly suggest that you report the omission of that scancode from that particular device as a kernel bug. In the past I've (reluctantly) been involved in somebody's attempt to get a fancy multibutton mouse working to his satisfaction and once raised a similar omission was fixed relatively quickly.

You might be able to use the BPF-based hack that was introduced relatively recently to override the HID parsing, but this is something I've never tried.

As far as the remainder go, you should find that if you add your normal user to the "input" group you won't need sudo (I checked that earlier in the afternoon). At that point you should be able to hack together a Pascal interface to evlib which I'd expect to be described in C (whereas higher-level APIs are increasingly object-oriented C++).

** You can get at the metadata via the /sys tree, but unless things have been changed relatively recently it's "post-quirks" rather than raw. If the device were USB-interfaced you might have been able to see the raw data using Wireshark: in my experience it works for most (but not all) devices.



I have provided only one code for example. In the eleventh device test, I get events even when excluded from the shortcuts, but in the 3rd device test, I do not receive events from these keys even when excluded from the shortcuts. But in my program I get these codes easily if I exclude them from the system shortcuts. And when they are involved in the system, players compatible with mpris are controlled by these keys.

"if the device were USB-interfaced you might have been able to see the raw data using Wireshark:"
You mean this product:   ?
I used it to intercept network packets.  :o

So some of those devices are actually derivatives of lower-level ones, although I've also seen things that appear as multiple devices and potentially a module could read HID stuff and simulate a device. I've used- and slightly modified- software that does that sort of filtering, but the whole thing is somewhat... fraught.

In any event: I think that's the lowest level available and it's where keyboard-like devices usually appear.

Apropos Wireshark, and noting that it's a /project/ included with most Linux distreaux rather than a /product/, there's a kernel module you can load which exposes USB as a "network-like" interface so it can be monitored. However as I've said, IME it's not 100% reliable.



[0] Message Index

[#] Next page

[*] Previous page

Go to full version