Thank you for testing. I went into comparing against qcom-x1e-7.0 and found patches from Bryan O’Donoghue re camera that differ quite a bit on what is on mine. Applied/merged them, 7.1.3-jg-1 is building now.
Sorry for the unnecessary complication. 7455 device tree boots fine (and camera works) Thanks. Do you know if there could potentially be a problem due to it expecting 12 cores (mine has 10) and a touchscreen ?
1 Like
No prob. No, this is no issue with the extra cores. The support for Hamoa is prepared for all binnings of it, 10 and 12 cores. Also, a non-existent touch screen should be no problem - the driver probes and exits when nothing is found.
I’ll keep the Purwa variant of the 5455 in my tree, though.
1 Like
Full guide for installing Ubuntu on the Surface Pro 11 if you’re interested.
3 Likes
Well that didn’t really play out for me. I can’t get my T14s camera to work, even with a “stock” install and 7.0.0-32.32 kernel. Still looking for the root cause.
EDIT: gnome-snapshot works. Even better with privacy-shutter off.
1 Like
I also tested 7.1.37.1.3-jg-0 build just today, internal camera detects and you can view the camera on gnome-snapshot as it’s libcamera/CAMSS but Chrome/Firefox don’t find it unless told to look at pipewire, you set the following:
Firefox (about:config)
media.webrtc.camera.allow-pipewire = true
Chromium/Chrome (chrome://flags):
enable-webrtc-pipewire-camera → Enabled
but it’s listed 22 times /dev/video* etc..
maybe a PipeWire + libcamera binding issue?
Some more details for anyone debugging:
Summary
=== libcamera SPA plugin for pipewire present? ===
/usr/lib/aarch64-linux-gnu/spa-0.2/libcamera
/usr/lib/aarch64-linux-gnu/spa-0.2/libcamera/libspa-libcamera.so
➜ ~ cam --list
[0:57:50.650822956] [45703] INFO Camera camera_manager.cpp:340 libcamera v0.7.0
[0:57:50.816270256] [45706] INFO Camera camera_manager.cpp:223 Adding camera '/base/soc@0/usb@a600000-1.3.1:1.0-413c:c015' for pipeline handler uvcvideo
[0:57:50.817640933] [45706] WARN CameraSensorProperties camera_sensor_properties.cpp:548 No static properties available for 'ov02c10'
[0:57:50.817660099] [45706] WARN CameraSensorProperties camera_sensor_properties.cpp:550 Please consider updating the camera sensor properties database
[0:57:50.817673068] [45706] WARN CameraSensor camera_sensor_legacy.cpp:502 'ov02c10 2-0036': No sensor delays found in static properties. Assuming unverified defaults.
[0:57:50.819335620] [45706] WARN IPAProxy ipa_proxy.cpp:192 Configuration file 'ov02c10.yaml' not found for IPA module 'simple', falling back to '/usr/share/libcamera/ipa/simple/uncalibrated.yaml'
[0:57:50.819368120] [45706] WARN IPASoft soft_simple.cpp:104 IPASoft: Failed to create camera sensor helper for ov02c10
[0:57:50.819604474] [45706] INFO Camera camera_manager.cpp:223 Adding camera '/base/soc@0/cci@ac16000/i2c-bus@1/camera@36' for pipeline handler simple
Available cameras:
1: Internal front camera (/base/soc@0/usb@a600000-1.3.1:1.0-413c:c015)
2: Internal front camera (/base/soc@0/cci@ac16000/i2c-bus@1/camera@36)
➜ ~
One think I noticed is the camera performed better in older 6.x kernel builds (e.g better light etc.. now it’s very grainy and dark, maybe some acceleration not getting triggered
1 Like
[ASUS Vivobook S 15 X1P42100 Ubuntu 26.04]
Can confirm 7.1.3-jg-0 EL1 kernel has the two laptop speakers working and also the HDMI audio channel which was an unexpected bonus. However the 3.5mm headphone jack isn’t working (nor anything on EL2). Thanks for sorting this out.
2 Likes
I applied your ec patch on 7.0.0-34-qcom-x1e kernel and everything works, the driver shows up, improved battery drain, and power led blinks and keyboard backlight turns off during sleep. So, the issue must be related to the jg kernel, even though I still get the improved battery drain with the jg kernel.
@glathe just to let you know the camera still doesn’t work on version 7.0.3-0 on Slim 7X, even with gnome-snapshot and Chrome using pipewire.
2 Likes
Looks like audio on the Surface Pro 11 is still kind of a mess. There’s a repo with some config that makes both speakers work, but only in a mono mode as a workaround for some kernel issue.
I also had to manually edit the matches in that repo’s UCM files, since they only included Microsoft Surface Pro, 11th Edition, not Microsoft Surface Pro with 5G, 11th Edition.
If I’d known how much extra trouble the 5G version was going to give, such as having no devicetree, I would have bought something else. As it turns out, tethering is more cost-efficient than having a whole separate data plan for a tablet.
I haven’t tried the official Ubuntu image lately to see if it’s any better, but the last time I did, I had to copy the ISO contents to a fat32 drive so I could edit the grub config. I had to add terminal_output gfxterm to avoid the automatic reboot and add a line to load a devicetree because stubble didn’t load one automatically.
I hope we can eventually get the devices fully working, and Qualcomm won’t just abandon us by telling us to “go buy an X2 Elite or X3 Elite if you want Linux support.”
I did find one thing that works better on Linux than it does on Windows: video over USB-C (not USB4). I attached a Steam Deck dock with an HDMI display, and on Windows, the computer sees the monitor and tries to display to it, but the monitor displays nothing; on Linux, it displays just fine.
2 Likes
Hi @glathe ,
I’ve tried your fork of the 7.1.2-jg-3-qcom-x1e kernel, and it seems to successfully enable the speakers on the Vivobook S15 with the X1E80100. The “Test Sound” feature is now working.
Is there anything I can do to make sure I don’t accidentally damage the audio hardware when adjusting the volume?
2 Likes
I’d like to add that on my Vivobook S15 with 7.1.3-jg-0-qcom-x1e headphone jack also works, but it sometimes distorts audio making it loud briefly and then back to normal, also volume between channels L/R can be uneven sometimes.
1 Like
The sound distortion and volume change issues are a known issue. There are quite a few fixes in alsa-ucm-conf for this, changing the hifi mode and compander switches to minimize this. These are not upstream (no idea why, they work well). I have a branch on my alsa-ucm-conf fork where they are included.
1 Like
Thanks for the info. I guess I found the change that borks it, not quite sure which way to fix it - it’s the newer camera patches that seem to not hamonize with our configs. Probably staying on the 7.0.0-32 state for this may be safer, on the chance of breaking other laptop’s cameras (which I can’t test).
1 Like
Update on mipi csi cameras: 7.1.3-jg-1 works with camera on my T14s now. The changes may be small from the outside, but it is newly rebased onto sre’s tree (7.1 version) and Ubuntu-Mainline now. And a lot of pruning. To verify I needed to install the T14s from scratch (which is also validated now) with the extended ISO. The normal resolute ISO will crash after installing on 64GB laptops, though (cutmem missing).
on my slim 7x I have these changes to alsa-ucm. fairly sure Step 1 is the important one - changing power amplifier to 0 dB. i can raise volume to 100% and it’s not that loud.
i notice you don’t touch the power amplifier at all in your branch?
# Step 1: Reduce Power Amplifer Volume (Range 0-31, step = 1.5 dB, 12 = +9 dB, 1 = -7.5 dB)
patch_file 1 "/usr/share/alsa/ucm2/codecs/wsa884x/four-speakers/SpeakerSeq.conf" "PA Volume' 12" "PA Volume' 6"
# Step 2: Reduce Digital Volume 1 (Range 0-124, step = 1.5 dB, 58 = -22 dB)
patch_file 2 "/usr/share/alsa/ucm2/codecs/qcom-lpass/wsa-macro/Wsa1SpeakerEnableSeq.conf" "Digital Volume' 68" "Digital Volume' 58"
patch_file 2 "/usr/share/alsa/ucm2/codecs/qcom-lpass/wsa-macro/Wsa2SpeakerEnableSeq.conf" "Digital Volume' 68" "Digital Volume' 58"
# Step 3: Reduce Digital Volume 2
patch_file 3 "/usr/share/alsa/ucm2/codecs/qcom-lpass/wsa-macro/four-speakers/init.conf" "Digital Volume' 84" "Digital Volume' 5"
patch_file 3 "/usr/share/alsa/ucm2/codecs/qcom-lpass/wsa-macro/init.conf" "Digital Volume' 84" "Digital Volume' 5"
2 Likes
Hi guys!
first of all i’m sorry if i’m interrupting a conversation
I am using the acer swift 14 go with the x1p 42100 and the 7.1-rc4-jg-0-qcom-x1e kernel using the DT from the jglathe repo’s sp11_x1p branch (x1-acer-swift-14.dtsi and x1p42100-acer-swift-go14-01.dts). I cannot for the love of god get the GPU to work. I tried the firmware from the windows partition and I tried downloading it from acer/qualcomm both give the same errors:
[ 5.351832] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 5.361969] platform 3d6a000.gmu: [drm:a6xx_gmu_set_oob [msm]] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0
[ 5.433456] adreno 3d00000.gpu: error -22 initializing firmware qcom/x1e80100/ACER/SFG14-01/qcdxkmsuc8380.mbn
mostly this -22 error being the pattern but here is all that i get:
https://nextcloud.keszeglab.hu/s/i3rfLFJHNGFRCeN
With this i am always stuck on software rendering / llvmpipe
If someone has some experience with this or some ideas i would really appreciate it, having the GPU up would greatly help in the future
thanks!
1 Like
Hi @lakatdev , interesting. And interesting choice of tree from my repo. Regardless of that, the error lies in the name of zap shader file that is specified to be loaded… it must be qcdxkmsucpurwa.mbn. The reason for that is that the Acer Swift Go has a Purwa SoC, the firmware package has both files for Hamoa and Purwa SoC. I will correct this in the next build, should be 7.1.3-jg-2 then. I would recommend that version for various other reasons, too.
There is a patch from @tobhe to limit the volume in the driver itself.
Hi @glathe and thanks a lot for your work! I am using 7.1.3-jg-1 on my ASUS VivoBook S15 (x1e78100 version, S5507QA) with LUKS, and here is my feedback:
- nostubble version results in a black screen
- I had to modify https://ratatoskr.run/b4-sent/2025/12/3342024 to match my device id (0x4543) and use a DKMS module to get keyboard keys working (brightness, mic mute, keyboard backlight, but Fn Lock still does not)
- No matter what I do, sound is not working. 2 audible “crack” can be heard after disk decrypt, and log indicates:
[ +0.194996] qcom_q6v5_pas 6800000.remoteproc: Handover signaled, but it already happened
[ +0.285196] qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode
[ +0.001123] wsa884x-codec sdw:1:0:0217:0204:00:1: Bus clash detected
which floods the console. I also hear the crack when switching input source, which (sometimes) makes the speaker work for a few seconds in the test panel (no matter which input source is selected (!), then stops. I tried multiple versions of ucm-alsa, latest version of the firmwares… nothing. But the speakers as well as the 3 display outputs are properly detected!
- camera does not work
Sound is pretty bothering for me, is there a way to sideload a device tree with your kernel? What debugging mechanism would you recommend?
Thanks a lot!
[Microsoft Surface Pro 11 — X1E80100 OLED]
I’ve made some further progress with the internal microphone.
I built a test kernel based on @glathe’s 7.1.3-jg-1 kernel, changing the Denali device-tree property:
qcom,dmic-sample-rate = <4800000> → <2400000>
With the previous 4.8 MHz setting, microphone recordings had continuous feedback/static and were barely usable when enabled. After booting the 2.4 MHz kernel:
- the feedback/static is no longer audible;
- speech recording is dramatically clearer and almost perfect;
- the recording still sounds slightly thin/tinny; and
- I cannot hear any degradation when playing music through the speakers.
I also verified that the running kernel is using the Stubble-embedded DTB and that the live qcom,dmic-sample-rate value is 2400000.
The patch, build details, device-side evidence, and ADR are in this pull request:
A prebuilt test kernel is available here:
Given the improvement and the lack of an audible speaker regression, I’ve adopted 2.4 MHz as the default for my Surface Pro 11 builds. Would you consider carrying this change in the JG tree @glathe?
Sidenote: I will look into removing some of these placeholder input devices
3 Likes