Talk:Lenovo ThinkPad T14 (AMD) Gen 3

From ArchWiki
Latest comment: 1 September by Ecksor in topic MicLED situation

Hardware error

I'm getting Hardware Error, anyone else? https://gist.github.com/840e0479fbf01d4a81f6e2c14fd321d2

Not sure if it's genuinely a Hardware Error requiring a RMA. Hendry (talk) 06:07, 31 October 2022 (UTC)Reply

Recent amdgpu problems

Recently acquired this machine, experience sporadic screen flickering and hang ups. Cannot find a way to reproduce. Seems to be a common problem:

1) https://gitlab.freedesktop.org/drm/amd/-/issues/2220

2) https://gitlab.freedesktop.org/drm/amd/-/issues/2352

Issue is not solved as of 03 March 2023.

Issue is reported on Phoronix: https://www.phoronix.com/news/AMD-Scatter-Gather-Re-Enabled and using amdgpu.sg_display=0 may be a fix, haven't tested yet.

Happened on 6.2.1-arch1-1.

-- Bakunin (talk) 12:20, 3 March 2023 (UTC)Reply

Secure Boot with user keys

Have anyone tried to install user keys for secure boot on this machine? I'm afraid to brick the device, but would like to use secure boot.

Bakunin (talk) 14:17, 7 March 2023 (UTC)Reply

Addition to 4. Quectel Modem for the use of gpsd.

Can somebody add this, because I'm afraid of doing it wrong - I'm not fluent with the arch wiki syntax.
I have a solution for GPS / gpsd not working.
The Manufacturer or Lenovo only enabled the serial AT port (ttyUSB0) on the Quectel modem.
I joined the Quectel forum to figure out how to enable the other modem ttyUSB ports,
to be able to use GPS /gpsd.

This is the thread to enable GPS / gpsd successfully. But better use the settings described here.
They are more recent and corrected - because there is no need to enable all the ports.
https://forums.quectel.com/t/no-gps-data-at-dev-ttyusb0-or-any-other-ports-qectel-em05-g/22294
This is the manual for it. See page 117 chapter 9.2:
https://www.quectel.com/wp-content/uploads/2022/06/Quectel_EC2xEG2xEG9xEM05_Series_QCFG_AT_Commands_Manual_V1.0.pdf

For a quick start (more recent and better tested version):

sudo minicom -D /dev/ttyUSB0
(when started press "ctrl+a e" to see what you type)

Issue the following command by typing it in then press return:
AT+QCFG="USBCFG",0x2C7C,0x030A,0,1,1,0,1,0,0

Exit minicom with "ctrl+a x"
reboot

After the reboot the ports should be:
/dev/ttyUSB0 (NMEA for GPS/gpsd)
/dev/ttyUSB1 (Modem AT commands)

This setting is permament - no need to do it again after reboot.
To restore to original settings use:
AT+QCFG=“USBCFG”,0x2C7C,0x030A,0,0,1,0,1,0,0

Warning:
Never disable (0) the 3rd of the ports (AT command port)
I have no idea what happens when you disable access to this port.
Worst case - you will not be able to reconfigure your modem anymore.


Thank you.

MicLED situation

On my configuration it was caused by having pulseeffects running as a service at system startup.

Pulseeffects creates a virtual sound monitor device. When micmute key is pressed it switched the mute option on that virtual device instead the real microphone device.

As a result - depending on the order in which the service was started - the micled was either locked in the lit or unlit status. I disabled the pulseeffects service at startup. Now everything is working as supposed regarding the micled. HAL9081 (talk) 06:08, 30 August 2024 (UTC)Reply

I've encountered a similar issue with my new T14s Gen 4 AMD laptop, where the microphone LED would stay on even when muted. After multiple failed attempts to resolve it, I found an older thread on the ALSA project's GitHub discussing this problem for T14 series laptops: Link to Thread.
The community solution was to toggle off the Auto-Mute Mode for the microphone. I did a fresh install of KDE Plasma with Pipewire, installed the alsa-utils package, and followed the updated wiki instructions. After rebooting and toggling the microphone on and off, I observed the LED state changing correctly. Note that you may need to reboot before the fix takes effect.
However, there's a slight caveat: You might need to toggle the microphone state a few times before disabling Auto-Mute Mode. If not, the LED might revert to being on by default after a reboot. The LED state will still work as intended, but the mic's default state may revert to being muted by default. I'm unsure if this is an issue with KDE or Pipewire. To fix this, I toggled the mic on and off, set the volume slider to about mid-way, went into alsamixer, re-toggled Auto-Mute Mode on then off, and then rebooted. Now, the LED properly reflects the microphone's saved state and properly persists across reboots.
If anyone investigating this issue comes across other helpful information, I'd be interested in hearing from you. For now, @Erus Iluvatar has removed all the outdated and non-working fixes from the wiki in favor of this seemingly effective solution. Ecksor (talk) 17:41, 1 September 2024 (UTC)Reply