On 21 June 2018 at 13:39, Takashi Iwai wrote:
> On Thu, 21 Jun 2018 13:35:21 +0200,
> Damjan Georgievski wrote:
>>
>> > I applied them to Debian's kernel (with slightly modification) and they
>> > are working fine. Via "alsamixer -c 0" I can change "Mic Mute-LED Mode"
>> > to "Follow Capture" and
On Thursday 21 June 2018 13:35:21 Damjan Georgievski wrote:
> > I applied them to Debian's kernel (with slightly modification) and they
> > are working fine. Via "alsamixer -c 0" I can change "Mic Mute-LED Mode"
> > to "Follow Capture" and then led is ON only when microphone is ON.
> > Recording fr
On Thu, 21 Jun 2018 13:35:21 +0200,
Damjan Georgievski wrote:
>
> > I applied them to Debian's kernel (with slightly modification) and they
> > are working fine. Via "alsamixer -c 0" I can change "Mic Mute-LED Mode"
> > to "Follow Capture" and then led is ON only when microphone is ON.
> > Recordi
On Monday 18 June 2018 12:11:44 Pali Rohár wrote:
> On Friday 15 June 2018 20:36:28 Henrique de Moraes Holschuh wrote:
> > On Fri, 15 Jun 2018, Pali Rohár wrote:
> > > means set. What is SHDA doing, I have not figured out. It does not
> >
> > Look at the HDA mixer state, SHDA is likely to be direc
> I applied them to Debian's kernel (with slightly modification) and they
> are working fine. Via "alsamixer -c 0" I can change "Mic Mute-LED Mode"
> to "Follow Capture" and then led is ON only when microphone is ON.
> Recording from microphone is working in both configurations.
hm this is the opp
On Monday 18 June 2018 17:35:18 Takashi Iwai wrote:
> On Mon, 18 Jun 2018 13:26:18 +0200,
> Pali Rohár wrote:
> >
> > On Monday 18 June 2018 13:21:21 Pali Rohár wrote:
> > > Now I see that in Debian backports is some 4.16.12 kernel version. I can
> > > try this one (and later compile one from Linu
On Thu, 21 Jun 2018 13:24:07 +0200,
Pali Rohár wrote:
>
> On Tuesday 19 June 2018 10:42:12 Takashi Iwai wrote:
> > On Tue, 19 Jun 2018 10:37:12 +0200,
> > Pali Rohár wrote:
> > > Interesting is this part:
> > >
> > > $ head /proc/asound/card0/codec#0
> > > Codec: Realtek ALC257
> > > Address: 0
>
On Tuesday 19 June 2018 10:42:12 Takashi Iwai wrote:
> On Tue, 19 Jun 2018 10:37:12 +0200,
> Pali Rohár wrote:
> > Interesting is this part:
> >
> > $ head /proc/asound/card0/codec#0
> > Codec: Realtek ALC257
> > Address: 0
> > AFG Function Id: 0x1 (unsol 1)
> > Vendor Id: 0x10ec0257
> > Subsystem
On Tue, 19 Jun 2018 10:37:12 +0200,
Pali Rohár wrote:
>
> On Monday 18 June 2018 13:21:21 Pali Rohár wrote:
> > On Monday 18 June 2018 12:36:31 Takashi Iwai wrote:
> > > On Mon, 18 Jun 2018 12:28:06 +0200,
> > > Pali Rohár wrote:
> > > >
> > > > On Saturday 16 June 2018 18:02:14 Takashi Iwai wrot
On Monday 18 June 2018 13:21:21 Pali Rohár wrote:
> On Monday 18 June 2018 12:36:31 Takashi Iwai wrote:
> > On Mon, 18 Jun 2018 12:28:06 +0200,
> > Pali Rohár wrote:
> > >
> > > On Saturday 16 June 2018 18:02:14 Takashi Iwai wrote:
> > > > On Sat, 16 Jun 2018 17:43:09 +0200,
> > > > Pali Rohár wro
On Mon, 18 Jun 2018 13:26:18 +0200,
Pali Rohár wrote:
>
> On Monday 18 June 2018 13:21:21 Pali Rohár wrote:
> > Now I see that in Debian backports is some 4.16.12 kernel version. I can
> > try this one (and later compile one from Linus tree).
>
> Tested, this version is working fine and leds work
On Monday 18 June 2018 13:21:21 Pali Rohár wrote:
> Now I see that in Debian backports is some 4.16.12 kernel version. I can
> try this one (and later compile one from Linus tree).
Tested, this version is working fine and leds works as expected. And now
also snd_hda_codec_realtek is loaded.
--
P
On Monday 18 June 2018 12:36:31 Takashi Iwai wrote:
> On Mon, 18 Jun 2018 12:28:06 +0200,
> Pali Rohár wrote:
> >
> > On Saturday 16 June 2018 18:02:14 Takashi Iwai wrote:
> > > On Sat, 16 Jun 2018 17:43:09 +0200,
> > > Pali Rohár wrote:
> > > >
> > > > On Saturday 16 June 2018 09:05:41 Takashi I
On Mon, 18 Jun 2018 12:28:06 +0200,
Pali Rohár wrote:
>
> On Saturday 16 June 2018 18:02:14 Takashi Iwai wrote:
> > On Sat, 16 Jun 2018 17:43:09 +0200,
> > Pali Rohár wrote:
> > >
> > > On Saturday 16 June 2018 09:05:41 Takashi Iwai wrote:
> > > > On Fri, 15 Jun 2018 21:09:59 +0200,
> > > > Pali
On Saturday 16 June 2018 18:02:14 Takashi Iwai wrote:
> On Sat, 16 Jun 2018 17:43:09 +0200,
> Pali Rohár wrote:
> >
> > On Saturday 16 June 2018 09:05:41 Takashi Iwai wrote:
> > > On Fri, 15 Jun 2018 21:09:59 +0200,
> > > Pali Rohár wrote:
> > > >
> > > > On Friday 15 June 2018 14:51:47 Takashi I
On Friday 15 June 2018 20:36:28 Henrique de Moraes Holschuh wrote:
> On Fri, 15 Jun 2018, Pali Rohár wrote:
> > means set. What is SHDA doing, I have not figured out. It does not
>
> Look at the HDA mixer state, SHDA is likely to be directly messing with
> it.
Now I found following email thread b
On Sat, 16 Jun 2018 17:43:09 +0200,
Pali Rohár wrote:
>
> On Saturday 16 June 2018 09:05:41 Takashi Iwai wrote:
> > On Fri, 15 Jun 2018 21:09:59 +0200,
> > Pali Rohár wrote:
> > >
> > > On Friday 15 June 2018 14:51:47 Takashi Iwai wrote:
> > > > On Fri, 08 Jun 2018 13:10:57 +0200,
> > > > Pali Ro
Hi!
> > Question is if we want flexibility or security.
>
> For thinkpad-acpi, it is security by default. Flexibility is allowed as
> *compile*-time (Kconfig) option, and only as long as it defaults to
> secure *and* the help text is very explicit at instructing distros to
> NOT enable this opti
On Saturday 16 June 2018 09:05:41 Takashi Iwai wrote:
> On Fri, 15 Jun 2018 21:09:59 +0200,
> Pali Rohár wrote:
> >
> > On Friday 15 June 2018 14:51:47 Takashi Iwai wrote:
> > > On Fri, 08 Jun 2018 13:10:57 +0200,
> > > Pali Rohár wrote:
> > > >
> > > > Hi! With up-to-date thinkpad_acpi.ko driver
On Sat, 16 Jun 2018, Pavel Machek wrote:
> Question is if we want flexibility or security.
For thinkpad-acpi, it is security by default. Flexibility is allowed as
*compile*-time (Kconfig) option, and only as long as it defaults to
secure *and* the help text is very explicit at instructing distros
Hi!
On Fri 2018-06-15 20:36:28, Henrique de Moraes Holschuh wrote:
> On Fri, 15 Jun 2018, Pali Rohár wrote:
> > This means that kernel should not export any led class device. Or when
> > exported, then "set" operation should always fail.
>
> "not export" is right.
>
> > > 2. Otherwise implement
On Fri, 15 Jun 2018 21:09:59 +0200,
Pali Rohár wrote:
>
> On Friday 15 June 2018 14:51:47 Takashi Iwai wrote:
> > On Fri, 08 Jun 2018 13:10:57 +0200,
> > Pali Rohár wrote:
> > >
> > > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
> > > a strange behavior of LEDs which a
On Fri, 15 Jun 2018, Pali Rohár wrote:
> This means that kernel should not export any led class device. Or when
> exported, then "set" operation should always fail.
"not export" is right.
> > 2. Otherwise implement it in-kernel, so that userspace cannot unmute
> >when the human has activated
On Friday 15 June 2018 14:51:47 Takashi Iwai wrote:
> On Fri, 08 Jun 2018 13:10:57 +0200,
> Pali Rohár wrote:
> >
> > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
> > a strange behavior of LEDs which are integrated into mic mute (Fn+F4)
> > and mute (Fn+F1) keys.
> >
>
On Friday 15 June 2018 09:30:07 Henrique de Moraes Holschuh wrote:
> On Fri, 15 Jun 2018, Pali Rohár wrote:
> > Henrique, any idea why there are no exported led classes for mute and
> > micmute? And how are suppose to be controlled?
>
> I have to look into the code, it was contributed by someone w
On Fri, 08 Jun 2018 13:10:57 +0200,
Pali Rohár wrote:
>
> Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
> a strange behavior of LEDs which are integrated into mic mute (Fn+F4)
> and mute (Fn+F1) keys.
>
> When thinkpad_acpi.ko is not loaded, then mute key is working fin
On Fri, 15 Jun 2018, Pali Rohár wrote:
> Henrique, any idea why there are no exported led classes for mute and
> micmute? And how are suppose to be controlled?
I have to look into the code, it was contributed by someone who had
access to the proper hardware to test it.
But the way *I* would like
On Friday 15 June 2018 13:26:06 Pavel Machek wrote:
> Hi!
>
> > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
> > a strange behavior of LEDs which are integrated into mic mute (Fn+F4)
> > and mute (Fn+F1) keys.
> >
> > When thinkpad_acpi.ko is not loaded, then mute key
Hi!
> Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
> a strange behavior of LEDs which are integrated into mic mute (Fn+F4)
> and mute (Fn+F1) keys.
>
> When thinkpad_acpi.ko is not loaded, then mute key is working fine. When
> pressed, it correctly generates KEY_MUTE o
Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
a strange behavior of LEDs which are integrated into mic mute (Fn+F4)
and mute (Fn+F1) keys.
When thinkpad_acpi.ko is not loaded, then mute key is working fine. When
pressed, it correctly generates KEY_MUTE on AT Translated S
30 matches
Mail list logo
