Hardware note: IR emitter on ASUS laptops with Sonix 3277:0018 is motion-reactive — linux-enable-ir-emitter is not needed (and may hang the system)
Filing this as a documentation/discoverability issue for the next person whose face auth "works for one frame and then goes black" on an ASUS laptop. I think a short note in the README or a hardware-quirks wiki page would save people hours.
Context
I just spent a long session getting Howdy working on Zorin OS 18 (Ubuntu 24.04 / noble) with an ASUS Vivobook X1607C. The IR camera is a Sonix module with USB ID 3277:0018, exposing two video nodes:
/dev/video0 — RGB FHD webcam/dev/video2 — IR camera, GREY 8-bit, 640x360 @ 30 fps
Identical to the configurations described in boltgolt/howdy#890 and EmixamPP/linux-enable-ir-emitter#195.
Symptom
Howdy enrollment captures a face for the first frame or two, then every subsequent frame is pitch black. Same when running linux-enable-ir-emitter test. Many users in the issues above (ProArt PX13, ProArt H7606WX, Zenbook S16 UM5606, Vivobook X1607C, …) report the exact same behavior.
What's actually happening (empirical data)
I did a controlled v4l2 capture from /dev/video2:
Static capture (5 frames, no motion in front of camera):
| frame |
mean brightness |
| 0 |
44.0 |
| 1–4 |
0.0 |
Capture during gentle hand motion in front of camera (164 frames over ~14 s):
| second |
mean |
max |
| s0 |
42.2 |
201.8 |
| s1 |
75.4 |
253.0 |
| s2 |
43.3 |
253.0 |
| s3 |
62.3 |
253.0 |
| s4 |
79.0 |
252.9 |
| s5 |
33.3 |
109.9 |
Overall: 40 % of frames had brightness > 5; max saturated at 253. The IR LED is not dead — it pulses on motion. Confirmed by @zkurdi45 in linux-enable-ir-emitter#195: if you wave your hand across the camera, the LED blinks, and stops when the hand is removed. ASUS uses the proximity sensor in the IR module to gate the LED for power saving.
Why this matters for Howdy users
When a real user sits down to authenticate, their face entering the frame is the motion that triggers the LED, so Howdy works fine without any UVC hacking. The "broken" feeling comes from running howdy test or linux-enable-ir-emitter while sitting still — the LED sleeps, the feed goes dark, and people assume the camera is broken.
Why linux-enable-ir-emitter should not be the recommended fix on ASUS
The brute-force configure step sends arbitrary UVC extension-unit byte sequences to the chipset to find one that keeps the LED on. On the Sonix 3277:0018 chipset specifically, this wedged the USB bus and froze my system twice, requiring a hard reboot before I tracked down the actual cause. Multiple users in linux-enable-ir-emitter#195 report the configure step never finds a working sequence anyway, because the LED is not chipset-controlled — it's proximity-sensor-controlled.
Suggested action
Ideally a small "Hardware quirks" section in the Howdy README or wiki, with something like:
ASUS laptops with Sonix IR cameras (3277:0018 and similar): the IR emitter is controlled by the laptop's proximity sensor and only fires when motion is detected in front of the camera. Howdy works correctly out of the box — your face entering the frame at auth time triggers the LED. If howdy test shows a black feed, that's expected when no one is in front. Do not run linux-enable-ir-emitter configure on these models — it can hang the USB bus.
Affected hardware (from issue cross-reference):
- ASUS Vivobook X1607C
- ASUS ProArt PX13
- ASUS ProArt H7606WX-DRSE011X
- ASUS Zenbook S16 UM5606
- ASUS Vivobook 16 M3607GA-OLED078X (related)
- Likely most 2023–2026 ASUS laptops with the Sonix module
I've also published a community installer that covers the noble-specific issues (PEP 668, Python 3 imports, V4L2 backend, perms): https://github.com/jatroconis/howdy-noble-setup — happy to fold any guidance from maintainers into either the script or the README.
Bonus: layout note
On many of these laptops the IR LED is physically located in the same bezel cutout as the RGB camera, not in the IR-camera cutout. Covering "the regular camera" with the privacy shutter dims the IR feed even though Howdy never opens the RGB device. Worth mentioning so users don't troubleshoot in the wrong place.
Happy to PR a wiki/README change if helpful.
Hardware note: IR emitter on ASUS laptops with Sonix
3277:0018is motion-reactive —linux-enable-ir-emitteris not needed (and may hang the system)Filing this as a documentation/discoverability issue for the next person whose face auth "works for one frame and then goes black" on an ASUS laptop. I think a short note in the README or a hardware-quirks wiki page would save people hours.
Context
I just spent a long session getting Howdy working on Zorin OS 18 (Ubuntu 24.04 / noble) with an ASUS Vivobook X1607C. The IR camera is a Sonix module with USB ID
3277:0018, exposing two video nodes:/dev/video0— RGB FHD webcam/dev/video2— IR camera,GREY8-bit, 640x360 @ 30 fpsIdentical to the configurations described in boltgolt/howdy#890 and EmixamPP/linux-enable-ir-emitter#195.
Symptom
Howdy enrollment captures a face for the first frame or two, then every subsequent frame is pitch black. Same when running
linux-enable-ir-emitter test. Many users in the issues above (ProArt PX13, ProArt H7606WX, Zenbook S16 UM5606, Vivobook X1607C, …) report the exact same behavior.What's actually happening (empirical data)
I did a controlled v4l2 capture from
/dev/video2:Static capture (5 frames, no motion in front of camera):
Capture during gentle hand motion in front of camera (164 frames over ~14 s):
Overall: 40 % of frames had brightness > 5; max saturated at 253. The IR LED is not dead — it pulses on motion. Confirmed by @zkurdi45 in linux-enable-ir-emitter#195: if you wave your hand across the camera, the LED blinks, and stops when the hand is removed. ASUS uses the proximity sensor in the IR module to gate the LED for power saving.
Why this matters for Howdy users
When a real user sits down to authenticate, their face entering the frame is the motion that triggers the LED, so Howdy works fine without any UVC hacking. The "broken" feeling comes from running
howdy testorlinux-enable-ir-emitterwhile sitting still — the LED sleeps, the feed goes dark, and people assume the camera is broken.Why
linux-enable-ir-emittershould not be the recommended fix on ASUSThe brute-force
configurestep sends arbitrary UVC extension-unit byte sequences to the chipset to find one that keeps the LED on. On the Sonix3277:0018chipset specifically, this wedged the USB bus and froze my system twice, requiring a hard reboot before I tracked down the actual cause. Multiple users in linux-enable-ir-emitter#195 report the configure step never finds a working sequence anyway, because the LED is not chipset-controlled — it's proximity-sensor-controlled.Suggested action
Ideally a small "Hardware quirks" section in the Howdy README or wiki, with something like:
Affected hardware (from issue cross-reference):
I've also published a community installer that covers the noble-specific issues (PEP 668, Python 3 imports, V4L2 backend, perms): https://github.com/jatroconis/howdy-noble-setup — happy to fold any guidance from maintainers into either the script or the README.
Bonus: layout note
On many of these laptops the IR LED is physically located in the same bezel cutout as the RGB camera, not in the IR-camera cutout. Covering "the regular camera" with the privacy shutter dims the IR feed even though Howdy never opens the RGB device. Worth mentioning so users don't troubleshoot in the wrong place.
Happy to PR a wiki/README change if helpful.