You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current beep evdev driver in beep-driver-evdev.c opens the well known device /dev/input/by-path/platform-pcspkr-event-spkr by default which is implemented by the pcspkr.ko kernel driver.
Do platforms with gpio-beeper have a similarly well-known device file? If so, the question is whether to have a different driver inside beep for that well-known device, or use the same driver and have it probe a list of device files, and then deciding whether to expect SND_TONE or falling back to SND_BELL.
Also, on non-PC embedded systems (which might be slower than a PC) the sloooooooooooooooooowness of the evdev driver API elaborated on in #6 might be an interesting consideration.
The gpio-beeper driver does not support SND_TONE, but SND_BELL.
So we send SND_BELL instead when SND_TONE is not supported.
Adapted the pull request from Bastian Krause <[email protected]>
from johnath#17 for spkr-beep.
No well-known devices names for those devices are known, so we
cannot try them by default.
Closes: #12
Iterating through a list of well-known devices appears to be
easier than devising a way to hardcode one system specific
device name per system for each conceivable system.
Closes: #12
This appears interesting for the evdev driver: johnath#17
The text was updated successfully, but these errors were encountered: