IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Use -60 dB as the minimum value of the master volume mixer control.
While the DACs would support ranges down to about -120 dB, such
attenuations are not useful in practice.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HT-Omega Claro halo's ADC is an AK5385 instead of a WM8785, so we
should handle the ADC parameters as we do with the X-Meridian.
Using the code for the wrong ADC does not seem to have any audible
effects, and the Windows driver does it, but it is nonetheless a good
idea to run the AK5385 with an oversampling ratio that is not outside
the documented limits.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The usage and comments make it clear values of 1/0 were intended
rather than -1/0
Noticed by sparse:
sound/pci/pcxhr/pcxhr.h💯20: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:101:22: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:102:24: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:103:21: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:104:25: error: dubious one-bit signed bitfield
sound/pci/pcxhr/pcxhr.h:105:20: error: dubious one-bit signed bitfield
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If the EEPROM was partially overwritten (which seems to happen before the OS is
booted), restore its entire contents by deducing it from the remaining
information.
This does not have any effect on the Linux driver, which works even with
incomplete information in the EEPROM, but it makes other drivers work again.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Under as yet unknown circumstances, the first word of the sound card's
EEPROM gets overwritten. When this has happened, we cannot rely on the
subsystem IDs that the kernel reads from the PCI configuration
registers. Instead, we read the IDs directly from the EEPROM and do the
ID matching manually.
Because the model-specific driver cannot determine the model before
calling oxygen_pci_probe(), that function now gets a get_model()
callback as parameter. The customizing of the model structure, which
was formerly done by the probe() callback, also has moved into
get_model().
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When allocating resources, use a fixed name instead of reading it from
the model structure. This allows us to allocate the resources before
the actual model is known.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Allocate the model-specific data dynamically instead of including it in
the memory block of the card structure. This will allow us to determine
the actual model after the card creation.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move the owner field out of the oxygen_model structure and make it
a parameter of oxygen_pci_probe(), because the actual owner module does
not depend on the card model. Furthermore, moving it out of the model
structure allows us to create the card structure before the actual model
is known.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 7e86c0e6850504ec9516b953f316a47277825e33 ("do not
overwrite EEPROM on Xonar D2/D2X") because it did not actually help with
the problem.
More user reports show that the overwriting of the EEPROM is not
triggered by using this driver but by installing Linux, and that the
installation of any other operating system (even one without any CMI8788
driver) has the same effect. In other words, the presence of this
driver does not have any effect on the occurrence of the error. (So
far, the available evidence seems to point to a BIOS bug.)
Furthermore, it turns out that the EEPROM chip is protected against
stray write commands by the command format and by requiring a separate
write-enable command, so the error scenario in the previous commit (that
SPI writes can be misinterpreted as an EEPROM write command) is not even
theoretically possible.
The mixer control that was removed as a consequence of the previous
commit can only be partially emulated in userspace, which also means it
cannot be seen be the in-kernel OSS API emulation, so it is better to
revert that change.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALC268 can be configured as digital-only, e.g. for HDMI, on some
machines. Allow the parser to set up the digital-only mode.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fixed a typo of || and &&.
As it's in a disabled code section, there is no behavior change, though.
Reported-by: Jörg-Volker Peetz <jvpeetz@web.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Force speaker pin config with model=hp-dv5 model for cases when bios
doesn't set it up properly. All reported hp laptops using model=hp-dv5
model have speaker at pin 0x0d with same config, so it's safe to add
this within hp-dv5 model.
Reference: alsa-devel mailing list thread on
http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014390.html
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 32e176c14d7a425b681ef003c9061001ddb7fc7b.
That commit caused a regression with suspend on Thinkpad SL300.
Reference: kernel bug#12711
http://bugzilla.kernel.org/show_bug.cgi?id=12711
Tested-by: Alexandre Rostovtsev <tetromino@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added the support of multiple digital outputs via auto-probing for
Realtek ALC88x codecs. The multiple outputs are handled as slave
streams, so only one PCM stream (and the corresponding IEC958*
elements) is provided to control both digital outputs.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added the helper function snd_hda_multi_out_dig_cleanup() to clean up
the digital outputs with multi setup. This call is needed in cases
the codec supports multiple digital outputs as slaves. Otherwise the
slave widgets aren't properly cleaned up.
For a single digital output (e.g. in patch_conexant.c), this call isn't
needed.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Force model=auto for Acer AX1700-U3700A with ALC888 codec.
Since Acer devices are handlded as model=acer as default, the auto
parsing has to be specified explicitly.
(Maybe it's better rather to remove this default model=acer handling,
though.)
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Change HP dv7 quirk: although reported to work with hp-m4 model
(https://bugzilla.novell.com/show_bug.cgi?id=445321), the original
report doesn't contain info about testing of internal microphone.
Recently I received a report about internal mic not working
(https://qa.mandriva.com/show_bug.cgi?id=44855#c193), this must be
related with the forced line in on pin 0x0e done with hp-m4 model. Thus
change the current quirk from STAC_HP_M4 to STAC_HP_DV5, later reported
to be fixed on a provided kernel with this change
(https://qa.mandriva.com/show_bug.cgi?id=44855#c196).
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently the HP connector on X200 dock doesn't detect when a HP is connected
nor allows sound to be played using it. This patch fixes the problem by adding
a quirk for this specific model. It's possible that others have the same NID
(0x19) to report when dock HP is connected, but I don't have access to any.
Please Cc me in the reply since I'm not subscribed to alsa-devel@.
Signed-off-by: Aristeu Rozanski <aris@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add STAC_DELL_S14 quirk for new laptop series. Removed un-needed pins
in pin_nids for stac92hd83xxx. Also reorganized connection selection
code for the respective ports per quirk define.
Signed-off-by: Matthew Ranostay <mranostay@embeddedalley.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ASUS W5F needs the fixed codec-slots to probe to override the BIOS
problem.
Tested-by: Giovanni Moser Frainer <giovanni@redix.com.br>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some devices have broken BIOS and they don't set the codec probe-bit
properly after cleared by the driver. This makes the driver skipping
the necessary codec slots.
Since BIOS update isn't always easy, now the semantics of probe_mask
option is changed a bit. When it contains the bit 8 (0x100), the
lower bits are used to probe that slots regardless of codec-probe bits
returned by the hardware.
For example, probe_mask=0x103 will force to probe the codec slot #0
and #1.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After commit "ALSA: hda - Fix restore of pin configs at resume for
STAC/IDT codecs", the introduced stac_save_pin_cfgs function checks
already for pins == NULL case, saving then default pin configs from
machine with stac92xx_save_bios_config_regs. So we can remove the
extra checks when stac927x_brd_tbl[spec->board_config] == NULL.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The devices that have been newly added during reconfig must be
registered. Otherwise they won't be visible to user-space.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Detect multiple digital-out pins in snd_hda_parse_pin_defconfig().
The dig_out_pin and dig_out_type fields become arrays.
The codec parser still doesn't use this multiple pins detection, though.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We found that enabling/disabling HDMI audio pin out at stream start/stop
time will kill the leading 500ms or so sound samples. Avoid this by enabling
pin out once and for ever at module loading time.
The leading ~500ms audio samples will still be lost when switching from
X-channel playback to Y-channel playback where X != Y. However there's no
much we can do about it: the audio infoframe has to change and it looks like
either G45 or YAMAHA requires some time to switch the configuration.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The YAMAHA AV-X1800 requires audio infoframe to include speaker-channel
mapping to play >2 channel HDMI audio. In theory that mapping should be
derived from its speaker configurations contained in its ELD. However we
currently cannot get ELD in console before the KMS functionalities are ready.
This is a more or less general issue at least in the near future. As a
workaround, we propose to allow playback of mult-channel audio when ELD
is not available.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
