3 ms·
This doesn't contradict what you're saying, but it's worth noting: speaker support on these laptops couldn't be done through Easy Effects, and speakersafetyd do
by mort96 3y ago
This doesn't contradict what you're saying, but it's worth noting: speaker support on these laptops couldn't be done through Easy Effects, and speakersafetyd does way more than just DSP. There is no safety mechanisms built in to the hardware/firmware to prevent blowing out the speakers, so speakersafetyd needs to ensure that stuff doesn't get too hot; and that can't be done with a simple volume cap either, since the speakers sound terrible when driven at a guaranteed safe gain level. You need software with a model of how the speakers behave to monitor sense data and dynamically reduce the volume when the audio would otherwise have made the voice coils dangerously hot.
And the system needs to be fail-safe, so that the speakers don't get blown out if the daemon crashes or hangs.
---
As a separate topic, I disagree that this isn't shippable for distros. Distros already have a bunch of hardware-specific stuff. Libinput, for example, has a hardware database to correctly handle or work around quirks for all sorts of input hardware.
There's absolutely nothing which would prevent Ubuntu from providing speakersafetyd's hardware database, either as an optional package, or, if out-of-the-box Mac support is important, as a package that's installed by default.
- russdill 3y agoI'm picturing various vendors completely switching out speaker packages without changing any DMI strings because they simply don't care
- coffeeling 3y ago> Libinput, for example, has a hardware database to correctly handle or work around quirks for all sorts of input hardware. As a complete aside unrelated to the broader discussion, libinput is my nemesis and it has degraded my user experience of Linux. I hate, hatehatehatehate one finger tap to click. It's a huge misclick generator, and libinput used to have it off by default for good reason. However, libinput gates all actually useful and not very error-prone gestures like two and three finger taps to right and middle click and multifinger swipes behind having one finger tap to click enabled. You either take it all or you get nothing. This is a huge regression from the old Synaptics interface which let the user freely assign different actions to taps with different amounts of fingers. The worst is that it's completely intentional and has been the case for over five years because the old maintainer didn't want to write tests.
- mort96 3y agoI also take issue with parts of libinput... there are things which are relegated to the hardware database which should 100% be config options. I don't mind the idea of having a hw database, but if I as a user disagree with a choice made in the hw database, I should be able to easily change it. It sounds like the "all or nothing" tap to click stuff fits the general vibe of not letting the user configure stuff too much. I also dislike how there's no global libinput config file. I get that it's supposed to be a library, and the user of the library (GNOME, KDE, Sway, whatever) is supposed to expose those options, but in practice, a lot of useful options aren't exposed to the user. GNOME is especially bad about that. There are also weird choices, like: when you press down with two fingers and then move those fingers together (double click and drag), the cursor moves at twice the normal speed. Linux input isn't universally better now than it was a decade ago and that sucks.