Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check SND_TONE support and fall back to SND_BELL? #12

Open
ndim opened this issue Mar 7, 2020 · 2 comments
Open

Check SND_TONE support and fall back to SND_BELL? #12

ndim opened this issue Mar 7, 2020 · 2 comments
Assignees
Milestone

Comments

@ndim
Copy link
Member

ndim commented Mar 7, 2020

This appears interesting for the evdev driver: johnath#17

@ndim ndim self-assigned this Mar 7, 2020
@ndim
Copy link
Member Author

ndim commented Mar 7, 2020

More on Bastian Krause's pull request about falling back to SND_BELL

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.

@ndim
Copy link
Member Author

ndim commented Mar 9, 2020

According to johnath#17 (comment): /dev/input/by-path/platform-gpio-beeper-event

ndim added a commit that referenced this issue Mar 10, 2020
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
ndim added a commit that referenced this issue Mar 10, 2020
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
@ndim ndim added this to the v1.5.0 milestone Sep 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant