Created attachment 2063420 [details]
i2c devices

Created attachment 2063421 [details]
spi devices

Created attachment 2063422 [details]
lsusb

Thank you for filing this bug and providing all the logs.

At a first look it looks like the problem is missing powerdown gpio support in the hi556 driver.

I'll look into preparing a patch + a Fedora kernel with that patch after the holidays (I'll be back January 6th, but I'll have a lot of things to go through then).

Created attachment 2063487 [details]
lsmod

I'm afraid it is going to take a little longer before I will get around to looking into this and providing a test kernel.

I'm fully booked this week, so hopefully next week.

Also my initial analysis of a missing powerdown pin support in the hi556 driver is wrong. Looking at this again these lines from the kernel log are the problem:

Dec 21 12:16:59 fedora kernel: int3472-discrete INT3472:01: unknown \_SB.GPI0 pin 83 active-high
Dec 21 12:16:59 fedora kernel: int3472-discrete INT3472:01: GPIO type 0x12 unknown; the sensor may not work

Type 0x12 is a handshake pin, but is unclear yet how to handle this pin. So fixing this is going to be tricky / will likely take a while I'm afraid.

Note to self: This is an Alder Lake machine.

Sorry for being slow in getting back to you. I just finished a patch series to deal with the special handshake signal your laptop seems to need and posted version 1 of this upstream:

https://lore.kernel.org/platform-driver-x86/20250325161340.342192-1-hdegoede@redhat.com/

I've build a test-kernel with these patches, please give this a go:
https://koji.fedoraproject.org/koji/taskinfo?taskID=130775742

Here are some instructions for directly installing a kernel from koji:

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

In the mean time handshake GPIO support has been added to the Fedora kernels and I've just done another Fedora test-kernel build with some extra hi556 fixes for bug 2368506):

https://koji.fedoraproject.org/koji/taskinfo?taskID=133212953

This kernel is ready to download and install now.

For instructions for directly installing a kernel from koji (Fedora's buildsystem) see:

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this kernel a try and if things still do not work please collect new kernel logs using "journalctl -b 0 -k > kernel.txt".

Closing this due to lack of response from reporter.

Note a lot of fixes have landed since, see:

https://hansdegoede.dreamwidth.org/31089.html

so chances are this is already fixed.

Hadn't cc'd myself it appears, so I'm just now seeing this. Will be looking at the kernel 6.17.4-200.fc42.x86_64 next week and will report back.

Created attachment 2110659 [details]
qcam -v

qcam launches but no video

Created attachment 2111237 [details]
kernel log 6.17.4-200.fc42.x86_64

I have upgraded to 6.17.4-200.fc42.x86_64

qcam still does not display video although it does recognize existence of a camera.

Kernel log attached.

@hdegoede please let me know if I need to open a new bug or if you prefer reopening this one

Thank you for testing the latest code. There is no need to open a new bug, since this bug has so far only been about your laptop model it is fine to keep using it.

It looks like the sensor never starts streaming:

"Oct 29 01:40:44 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel: input: HP WMI camera shutter as /devices/virtual/input/input43
Oct 29 01:40:50 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: stream stop time out
Oct 29 01:40:52 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel: intel_ipu6_isys.isys intel_ipu6.isys.40: stream close time out"

The "stream close time out" timeouts come from the CSI receiver waiting for an end-of-frame signal to finish the current frame before stopping which never happens if the stream did not start.

I suspect that we may need a longer delay after driving the handshake signal high. I'll prepare a test-kernel for you for this.

In the mean time here is something else for you to try. Interesting here is the:

"input: HP WMI camera shutter as /devices/virtual/input/input43"

message which suggests that maybe your laptop has some sort of mechanical/electrical shutter ?

Or it could also be an electronic signal to the sensor which disables the sensor. Can you try (after having tried to run qcam at least once) to run:

sudo dnf install evtest
sudo evtest

and then select the "HP WMI camera shutter" device ?

This should show a SW_CAMERA_LENS_COVER switch as part of the input-device which will report a state of 0 / 1, if this is 1 see if there is a Fn + key combo to toggle camera-privacy and see if there then is an event on the input device reporting the SW_CAMERA_LENS_COVER state is now 0.

Then the camera again in qcam with the SW_CAMERA_LENS_COVER=0 state.

If that does not work try rebooting and then try qcam again. After trying qcam again run sudo evtest again and see if SW_CAMERA_LENS_COVER=0 survived the reboot.

If SW_CAMERA_LENS_COVER=0 did not survive the reboot, then reboot again and after reboot first press the camera-privacy toggle key-combo and then try qcam again. After trying qcam again check the state is/was SW_CAMERA_LENS_COVER=0.

If there is no keycombo to change the SW_CAMERA_LENS_COVER state, maybe it will automatically change when you try to stream. In that case keep the evtest command running (after selecting the "HP WMI camera shutter" device) and then try qcam from another terminal. In this case I'm mostly interested in if the SW_CAMERA_LENS_COVER state will switch to 0 while we are trying to stream from the sensor.

I have build a Fedora test kernel with a patch added to increase the delay after driving the handshake signal high to 500 ms (which is quite high):

https://koji.fedoraproject.org/koji/taskinfo?taskID=138535909

You can find instructions for installing a kernel directly from koji (the Fedora build-system) here:

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this kernel a try and see if it works better.

Note also please run the evtest tests on the "HP WMI camera shutter" device from comment 14. Even if this new kernel helps it would still be good to know what that device reports and if the reported value can be changed by a hotkey and/or changes by itself when streaming from the camera.

First, yes there is a special key for the camera privacy cover.

SW_CAMERA_LENS_COVER=0 does not survive a reboot. Upon reboot, sudo evtest does not show a "HP WMI camera shutter" device.

However, when I press the key twice, sudo evtest now does show the "HP WMI camera shutter" device with a state 0.

Next I'll try the test kernel.

(In reply to Hans de Goede from comment #14)
> Thank you for testing the latest code. There is no need to open a new bug,
> since this bug has so far only been about your laptop model it is fine to
> keep using it.
> 
> It looks like the sensor never starts streaming:
> 
> "Oct 29 01:40:44 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel:
> input: HP WMI camera shutter as /devices/virtual/input/input43
> Oct 29 01:40:50 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel:
> intel_ipu6_isys.isys intel_ipu6.isys.40: stream stop time out
> Oct 29 01:40:52 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel:
> intel_ipu6_isys.isys intel_ipu6.isys.40: stream close time out"
> 
> The "stream close time out" timeouts come from the CSI receiver waiting for
> an end-of-frame signal to finish the current frame before stopping which
> never happens if the stream did not start.
> 
> I suspect that we may need a longer delay after driving the handshake signal
> high. I'll prepare a test-kernel for you for this.
> 
> In the mean time here is something else for you to try. Interesting here is
> the:
> 
> "input: HP WMI camera shutter as /devices/virtual/input/input43"
> 
> message which suggests that maybe your laptop has some sort of
> mechanical/electrical shutter ?
> 
> Or it could also be an electronic signal to the sensor which disables the
> sensor. Can you try (after having tried to run qcam at least once) to run:
> 
> sudo dnf install evtest
> sudo evtest
> 
> and then select the "HP WMI camera shutter" device ?
> 
> This should show a SW_CAMERA_LENS_COVER switch as part of the input-device
> which will report a state of 0 / 1, if this is 1 see if there is a Fn + key
> combo to toggle camera-privacy and see if there then is an event on the
> input device reporting the SW_CAMERA_LENS_COVER state is now 0.
> 
> Then the camera again in qcam with the SW_CAMERA_LENS_COVER=0 state.
> 
> If that does not work try rebooting and then try qcam again. After trying
> qcam again run sudo evtest again and see if SW_CAMERA_LENS_COVER=0 survived
> the reboot.
> 
> If SW_CAMERA_LENS_COVER=0 did not survive the reboot, then reboot again and
> after reboot first press the camera-privacy toggle key-combo and then try
> qcam again. After trying qcam again check the state is/was
> SW_CAMERA_LENS_COVER=0.
> 
> If there is no keycombo to change the SW_CAMERA_LENS_COVER state, maybe it
> will automatically change when you try to stream. In that case keep the
> evtest command running (after selecting the "HP WMI camera shutter" device)
> and then try qcam from another terminal. In this case I'm mostly interested
> in if the SW_CAMERA_LENS_COVER state will switch to 0 while we are trying to
> stream from the sensor.

(In reply to John Freed from comment #16)
> First, yes there is a special key for the camera privacy cover.
> 
> SW_CAMERA_LENS_COVER=0 does not survive a reboot. Upon reboot, sudo evtest
> does not show a "HP WMI camera shutter" device.
> 
> However, when I press the key twice, sudo evtest now does show the "HP WMI
> camera shutter" device with a state 0.
> 
> Next I'll try the test kernel.
> 
> (In reply to Hans de Goede from comment #14)
> > Thank you for testing the latest code. There is no need to open a new bug,
> > since this bug has so far only been about your laptop model it is fine to
> > keep using it.
> > 
> > It looks like the sensor never starts streaming:
> > 
> > "Oct 29 01:40:44 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel:
> > input: HP WMI camera shutter as /devices/virtual/input/input43
> > Oct 29 01:40:50 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel:
> > intel_ipu6_isys.isys intel_ipu6.isys.40: stream stop time out
> > Oct 29 01:40:52 2a02-8434-ff40-3701-5013-6430-6b6b-8936.rev.sfr.net kernel:
> > intel_ipu6_isys.isys intel_ipu6.isys.40: stream close time out"
> > 
> > The "stream close time out" timeouts come from the CSI receiver waiting for
> > an end-of-frame signal to finish the current frame before stopping which
> > never happens if the stream did not start.
> > 
> > I suspect that we may need a longer delay after driving the handshake signal
> > high. I'll prepare a test-kernel for you for this.
> > 
> > In the mean time here is something else for you to try. Interesting here is
> > the:
> > 
> > "input: HP WMI camera shutter as /devices/virtual/input/input43"
> > 
> > message which suggests that maybe your laptop has some sort of
> > mechanical/electrical shutter ?
> > 
> > Or it could also be an electronic signal to the sensor which disables the
> > sensor. Can you try (after having tried to run qcam at least once) to run:
> > 
> > sudo dnf install evtest
> > sudo evtest
> > 
> > and then select the "HP WMI camera shutter" device ?
by the way, if I reboot and run evtest by itself, it does not show the camera shutter device. However, if I press the key ONCE, it does show the device, which is now in state 1. Also, there is an LED inside the key that is illuminated when the shutter is in state 1 and dark when it is in state 0.

> > 
> > This should show a SW_CAMERA_LENS_COVER switch as part of the input-device
> > which will report a state of 0 / 1, if this is 1 see if there is a Fn + key
> > combo to toggle camera-privacy and see if there then is an event on the
> > input device reporting the SW_CAMERA_LENS_COVER state is now 0.
> > 
> > Then the camera again in qcam with the SW_CAMERA_LENS_COVER=0 state.
> > 
> > If that does not work try rebooting and then try qcam again. After trying
> > qcam again run sudo evtest again and see if SW_CAMERA_LENS_COVER=0 survived
> > the reboot.
> > 
> > If SW_CAMERA_LENS_COVER=0 did not survive the reboot, then reboot again and
> > after reboot first press the camera-privacy toggle key-combo and then try
> > qcam again. After trying qcam again check the state is/was
> > SW_CAMERA_LENS_COVER=0.
> > 
> > If there is no keycombo to change the SW_CAMERA_LENS_COVER state, maybe it
> > will automatically change when you try to stream. In that case keep the
> > evtest command running (after selecting the "HP WMI camera shutter" device)
> > and then try qcam from another terminal. In this case I'm mostly interested
> > in if the SW_CAMERA_LENS_COVER state will switch to 0 while we are trying to
> > stream from the sensor.

qcam works with the test kernel.

Thanks!

(In reply to John Freed from comment #18)
> qcam works with the test kernel.

Great, thank you for testing. And sorry for being a bit slow to reply (I've just started a new job ...).

As mentioned before I've gone with a 500 ms delay in the test kernel.

If you boot the test kernel and then run:

cat /sys/module/intel_skl_int3472_discrete/parameters/handshake_enable_time

this should say 500.

Testing on other HP laptops has shown that 150 ms is likely enough.

Can you please do the following from a terminal:

echo "options intel_skl_int3472_discrete handshake_enable_time=150" | sudo tee /etc/modprobe.d/int3472_discrete.conf

and then reboot and boot the test kernel again.

Run:

cat /sys/module/intel_skl_int3472_discrete/parameters/handshake_enable_time

and verify that this indeed is 150 ms and then retest the camera.

If the camera works with 150 ms, please reboot into the test kernel a couple (say 5) times and check that the camera works every time.

Once I've confirmation that 150 ms also works for your laptop I'll submit a patch upstream to change the handshake signal delay to 150ms everywhere.

150 ms is apparently too short. Symptom:
1. reboot
2. launch qcam ... no video
3. quit qcam
4. launch qcam ... works fine

I set the timeout to 200 ms and it works fine every time.

Great, thank you.

I'll submit a patch to change the handshake signal related delay to 200 ms upstream soon.

Can also give the gum test page a go in Firefox (with the test kernel) ? For some users with a hi556 sensor on a Dell laptop (bug 2415297) this does not work and I wonder if that is a problem specific to the Dell laptop or just a generic hi556 sensor issue.

See here for GUM test page test instructions:

https://fedoraproject.org/wiki/Changes/IPU6_Camera_support#How_To_Test

Gum test page does not work.

I thought it might have something to do with the v4l2 loopback, which I normally build using kmod. It appears to work fine with the test kernel. However, most programs don't seem to recognize /dev/video0 (including Gum and Zoom).


qcam recognizes the camera as \_SB_.PC00.LNK0


v4l2-ctl --all -d /dev/video0 produces useful information (attached), so it appears that /dev/video0 works at least on some level.

Created attachment 2114978 [details]
v4l2-ctl --all -d /dev/video0

Regarding comment #22

For example, from VLC:

Your input can't be opened:
VLC is unable to open the MRL 'v4l2:///dev/video0'. Check the log for details.

... and the log says ...

[00007f77b80011a0] v4l2 demux error: not a video capture device
[00007f77b80011a0] v4l2 demux error: not a radio tuner device
[00007f77b8003480] v4l2 stream error: not a video capture device

so ... I don't know much about pipewire, but I did a pw-dump. I noticed this line:

       "session.services": "[policy.default-nodes, policy.device.profile, policy.device.routes, bluetooth.audio, api.bluez, midi, audio, policy.linking.standard, video-capture, api.alsa-seq, api.alsa, api.libcamera, bluetooth.midi, policy.linking.role-based]",
 
... and further down, there's a ton of things related to api.alsa.

By contrast, there is exactly zero related to api.libcamera

I removed the v4l2loopback module. The output from ...
$ v4l2-ctl --all -d /dev/video0
... is different (attached).

qcam still works (same as before)

But Gum test page still doesn't work, and vlc gives a slightly different error:

Your input can't be opened:
VLC is unable to open the MRL 'v4l2:///dev/video0'. Check the log for details.

... and this time the log says ...
[00007f1b6c0011a0] v4l2 demux error: cannot get streaming parameters: Inappropriate ioctl for device
libv4l2: error turning on stream: Link has been severed
[00007f1b6c0011a0] v4l2 demux error: cannot start streaming: Link has been severed
[00007f1b6c0011a0] v4l2 demux error: not a radio tuner device
[00007f1b6c003a70] v4l2 stream error: cannot get streaming parameters: Inappropriate ioctl for device
libv4l2: error turning on stream: Link has been severed
[00007f1b6c003a70] v4l2 stream error: cannot start streaming: Link has been severed

Created attachment 2115048 [details]
v4l2-ctl --all -d /dev/video0 without loopback

after removing v4l2loopback module

v4l2-ctl --all -d /dev/video0

OK, I followed the advice on the blog of Jan Grulich. I already had disabled the monitor.v4l2 

Firefox indicated "success" with the Gum test page but in fact I got some flicker and then a white screen.

I was able to feed the camera into OBS Studio using the pipewire (BETA) input stream and then output it using the OBS Virtual Camera.

This worked nearly perfectly. The only problem is that the resolutions are pre-set, so the largest I could choose was 2560x1600. This slightly cuts off the bottom of the camera feed. Not sure if this is an OBS problem or not.

Using this workaround, the Gum test page works fine, as does Zoom.

Regarding comment #28 and the size of the output ... I did a new v4l2-ctl which gave a slightly different output, this time with a width/height of 640/480. This translates to 2560x1920 (if my math is correct) so that probably explains the cutoff at the bottom of the image. There is no option in OBS to override the image size.

I attach the latest v4l2-ctl output and also pw-dump if that helps.

Created attachment 2115087 [details]
latest v4l2-ctl, after disallowing monitor.v4l2 in wireplumber

Created attachment 2115153 [details]
pw-dump

Note that previous outputs from pw-dump had numerous /dev/video devices using api.v4l2. The current version has no api.v4l2 devices and one api.libcamera (see ID 55, 76 and 77).

Created attachment 2115154 [details]
v4l2-ctl --all -d /dev/video32

output related to the OBS Studio virtual camera, /dev/video32, which uses the loopback

Thank you for all the testing.

Things not working out of the box in the gum test page suggests that there is an issue where things do not work when the sensor is run in a resolution lower then its maximum supported resolution, which is what the gum test page will do.

To confirm this can you please run the following qcam commands from a terminal:

"qcam -s width=2560,height=1920"  (this one should work)
"qcam -s width=2560,height=1440"
"qcam -s width=1280,height=960"
"qcam -s width=1280,height=720"

and for each of the modes write down whether it actually shows working video output from the camera or not ?

The first two work fine.

The last two fail (and give more or less the same appearance as the gum test page).

(In reply to John Freed from comment #34)
> The first two work fine.
> 
> The last two fail (and give more or less the same appearance as the gum test
> page).

Great, thank you for testing this. This confirms a hunch of mine that lower-res modes do not work when there is an Intel vision chip between the CPU and the sensor;

And this also seems to confirm that your HP laptop has such a vision chip even though it not being visible in /sys/bus/i2c/devices .

Thanks. I see three camera-related devices in /sys/bus/i2c/devices :

INT3537:00	Camera Sensor HI556 (or hi556 Extension)
OVTI00AB:00	Camera Sensor OG0VA1B
TXNW3643:01	Intel(R) Camera Flash LED

Same symptoms on my HP Spectre Fold 17-cs0013dx (845B7UA), a laptop with (probably) the same sensors. looking forward to use the camera under Fedora 43! :)

We're still trying to figure out why the lower-res modes (which are typically used for video-conferencing) work on some laptop models and not on others:

Can you please run the following command from a terminal:

for i in /sys/bus/acpi/devices/INTC10*; do echo -n "$i "; cat $i/status; done

and copy and paste the output here ?

Note the "cat" part of the command may fail in some cases, this is ok in that case the failure itself tells us what we need to know.

This message is a reminder that Fedora Linux 41 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '41'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 41 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

(In reply to Hans de Goede from comment #38)
> We're still trying to figure out why the lower-res modes (which are
> typically used for video-conferencing) work on some laptop models and not on
> others:
> 
> Can you please run the following command from a terminal:
> 
> for i in /sys/bus/acpi/devices/INTC10*; do echo -n "$i "; cat $i/status; done
> 
> and copy and paste the output here ?
> 
> Note the "cat" part of the command may fail in some cases, this is ok in
> that case the failure itself tells us what we need to know.

/sys/bus/acpi/devices/INTC1001:00 0
/sys/bus/acpi/devices/INTC1041:00 15
/sys/bus/acpi/devices/INTC1046:00 15
/sys/bus/acpi/devices/INTC1046:01 15
/sys/bus/acpi/devices/INTC1046:02 15
/sys/bus/acpi/devices/INTC1049:00 0
/sys/bus/acpi/devices/INTC1055:00 15
/sys/bus/acpi/devices/INTC1061:00 0
/sys/bus/acpi/devices/INTC1070:00 15
/sys/bus/acpi/devices/INTC1092:00 0
/sys/bus/acpi/devices/INTC1099:00 15

Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15.

Fedora Linux 41 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Anything more I can do for testing? Any progress getting this implemented? Still not working in 6.18.13.

I, too, would really like to see the 200 ms handshake signal related delay patched upstream. Is there anything I can do to help?

First of all sorry for dropping the ball on this. I've now submitted a patch upstream extending the post handshake GPIO delay to 200 ms for all sensors:

https://lore.kernel.org/platform-driver-x86/20260818122821.165541-1-johannes.goede@oss.qualcomm.com/

I've also submitted a Fedora kernel PR to get this added to the Fedora 7.1.y kernels:

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4650

Thank you, Hans!

Yes, thank you, Hans!

I had a chinese LLM (on the pi agent) try to fix the camera today. After concluding it's impossible unless there's a kernel update, it says

"Dragonfly Folio G3, RN sessions OVTI08A1 + OVTI00AB; no /dev/v4l-subdev on 7.1.13 or 7.2.5; is the 200 ms handshake patch in the Fedora 7.1.y/7.2.y kernels?"