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

[SWM1]

Hello guys and girls! I have an unsolvable problem.  :'( All I need for my Linux audio player is to receive events from the audio keys. But as for me, I cannot solve this with the help of Lazarus. I talked to chatgpt for a long time, but all his suggestions were limited to connecting libraries that Lazarus does not see. I found mpris2.pas written for ovoplayer. But it depends on almost all the player's code. Is it possible to receive events from the audio keys relatively without much effort in my player on Lazarus without unlocking them from use by the operating system? Thank you in advance for your kind help with my question.

[MarkMLl]

What is an "audio key" in this context? If you mean something on a keyboard, does evtest show them (might need sudo)? If evtest doesn't show them, then you probably can't do it without some kernel-level hacking.

MarkMLl

[SWM1]

These are the keys used by media players to control the player's functions and which exist on laptop keyboards or on extended keyboards that are sometimes called media keyboards. If you do not unlock them from system shortcuts, then you can access them only through DBus.

[MarkMLl]

...exist on the keyboard. Fine. Have you tried what I suggested?

MarkMLl

[SWM1]

sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:   Lid Switch
/dev/input/event1:   Power Button
/dev/input/event2:   Sleep Button
/dev/input/event3:   AT Translated Set 2 keyboard
/dev/input/event4:    USB OPTICAL MOUSE
/dev/input/event5:   SEM USB Keyboard
/dev/input/event6:   SEM USB Keyboard Consumer Control
/dev/input/event7:   SEM USB Keyboard System Control
/dev/input/event8:   SynPS/2 Synaptics TouchPad
/dev/input/event9:   Video Bus
/dev/input/event10:   Video Bus
/dev/input/event11:   Asus WMI hotkeys
/dev/input/event12:   ASUS USB2.0 Webcam: ASUS USB2.0
/dev/input/event13:   HDA NVidia HDMI/DP,pcm=3
/dev/input/event14:   HDA NVidia HDMI/DP,pcm=7
/dev/input/event15:   HDA NVidia HDMI/DP,pcm=8
/dev/input/event16:   HDA NVidia HDMI/DP,pcm=9
/dev/input/event17:   HDA Intel PCH Mic
/dev/input/event18:   HDA Intel PCH Headphone
Select the device event number [0-18]: 11
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Asus WMI hotkeys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 140 (KEY_CALC)
    Event code 148 (KEY_PROG1)
    Event code 149 (KEY_PROG2)
    Event code 150 (KEY_WWW)
    Event code 152 (KEY_SCREENLOCK)
    Event code 163 (KEY_NEXTSONG)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 165 (KEY_PREVIOUSSONG)
    Event code 166 (KEY_STOPCD)
    Event code 169 (KEY_PHONE)
    Event code 183 (KEY_F13)
    Event code 185 (KEY_F15)
    Event code 191 (KEY_F21)
    Event code 212 (KEY_CAMERA)
    Event code 215 (KEY_EMAIL)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 226 (KEY_MEDIA)
    Event code 227 (KEY_SWITCHVIDEOMODE)
    Event code 229 (KEY_KBDILLUMDOWN)
    Event code 230 (KEY_KBDILLUMUP)
    Event code 237 (KEY_BLUETOOTH)
    Event code 238 (KEY_WLAN)
    Event code 240 (KEY_UNKNOWN)
    Event code 247 (KEY_RFKILL)
    Event code 248 (KEY_MICMUTE)
    Event code 531 (KEY_TOUCHPAD_ON)
    Event code 560 (KEY_ALS_TOGGLE)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    250
    Repeat code 1 (REP_PERIOD)
      Value     33
Properties:
Testing ... (interrupt to exit)
Event: time 1679154389.169526, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45
Event: time 1679154389.169526, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1679154389.169526, -------------- SYN_REPORT ------------
Event: time 1679154389.169547, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1679154389.169547, -------------- SYN_REPORT ------------
Event: time 1679154393.353030, type 4 (EV_MSC), code 4 (MSC_SCAN), value 30
Event: time 1679154393.353030, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
Event: time 1679154393.353030, -------------- SYN_REPORT ------------
Event: time 1679154393.353059, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
Event: time 1679154393.353059, -------------- SYN_REPORT ------------
^[[23~^[[24~^[[19~^[[20~Event: time 1679154416.937570, type 4 (EV_MSC), code 4 (MSC_SCAN), value 40
Event: time 1679154416.937570, type 1 (EV_KEY), code 165 (KEY_PREVIOUSSONG), value 1
Event: time 1679154416.937570, -------------- SYN_REPORT ------------
Event: time 1679154416.937618, type 1 (EV_KEY), code 165 (KEY_PREVIOUSSONG), value 0
Event: time 1679154416.937618, -------------- SYN_REPORT ------------

[SWM1]

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

[MarkMLl]

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.

HTH.

MarkMLl

[SWM1]

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.

[SWM1]

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

[MarkMLl]

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.


MarkMLl

[SWM1]

No, my laptop's keyboard doesn't work because of USB. I can see the mouse and external keyboard via wireshark, but the laptop keyboard is not on either USB monitor.

[MarkMLl]

Doesn't entirely surprise me, although I've heard that an increasing number of internal devices are implemented as USB. In that case I'm pretty sure that the lowest level you can capture is evtest.

One thing does occur to me, and that is that when I've had problems using Wireshark to capture from devices (that I knew were literally USB devices, i.e. USB mouse-like) in the past it might have been because their data was being intercepted by a kernel module before it reached the module that "TEEd" it to Wireshark. Might have been nothing more complex than a loading-order issue (I've seen stranger things).

If it were a device being hotplugged (i.e. rather than an internal keyboard) you might get some useful hints from dmesg output. Are there any kernel modules loaded that are specific to that laptop, which might be doing "clever" stuff with keyboard events?

In any event, I hope I've pointed you in some interesting directions. One thing I can't comment on unfortunately is DBus: even though it's what you explicitly asked about :-)

MarkMLl

[SWM1]

Thank you for trying to help! But I need a solution not for some exotic device, but my player must work on any hardware, so a private case will not save me. I am saying that the system sees this keyboard and uses it as intended. And even my program sees events from these keys if they are not intercepted by the system as shortcuts. From which I come to the conclusion that Dbus cannot be dispensed with here. And so it turns out that in order to solve a simple problem, you have to work a lot to learn the low-level Dbus level and add it to your program, because I can't use high-level libraries like dbus-glib or GDbus in my project in any way.