On Fri, Mar 08, 2024 at 05:15:48PM +0100, Armin Wolf wrote: > Am 08.03.24 um 09:40 schrieb 艾超: > > > Hi > > > > thanks for your help. > > > > > Is there a way to determine the current state of the camera switch > > without having > > > to wait for an WMI event? > > > > There is no other way to detemine the current state of the camera > > switch without > > > > a WMI event. > > > > > > > If its not possible to determine the current state of the camera > > switch, then your > > > driver has to defer the initialization of the input device until it > > knows the current > > > state of the camera switch. Otherwise the initial switch state > > reported by the > > > input device might be wrong. > > > > > In this case, that means your driver must initialize the input > > device when receiving > > > a valid WMI event for the first time. > > > > > Basically when your driver receives a WMI event, it has to check if > > the input device > > > is already initialized. If this is not the case, then the input > > device is initialized. > > > Please protect this check and the input device initialization with a > > mutex, since WMI > > > event handling is multithreaded. > > > > > > This Camera is a UVC device, and the Carema device is already > > initialized before the WMI > > > > event . Whether the camera switch is on or off, we can used lsusb to > > check the Camera. It depends on which drivers are built-in and which are modules. The fact that on one distribution WMI happens to enumerate after PCI/USB is just a stroke of luck. > > > > This wmi-camera driver only need to report the current state of the > > camera switch. > > > > > > Thanks. > > > > Ai Chao > > > I see, so userspace will notice when the camera is disabled. Since the camera disappears from > the USB bus when the switch is activated, i wonder if SW_CAMERA_LENS_COVER is the right thing > to use in this case after all. > > I CCed the maintainer of the input subsystem so that he can maybe provide some advise. > I for example would, taking the above information above the UVC device into account, say that > KEY_CAMERA_ACCESS_ENABLE/KEY_CAMERA_ACCESS_DISABLE is more suitable. Then userspace has to > keep track of the camera state (through lsusb for example). KEY_CAMERA_ACCESS_ENABLE/KEY_CAMERA_ACCESS_DISABLE is supposed to affect all cameras connected to the system (HUTRR72: "The proposal is to add a set of new Usage IDs to the Consumer Page (0x0C) to control programmatic access to *all* camera devices connected to a computer." - emphasis mine). SW_CAMERA_LENS_COVER is useful when camera is always present but may be covered. If I understand this correctly the camera disappears from the bus and reappears again when enabled. In this case why do you need the key event at all? Are you planning on having a "stub" for the camera so that userspace believes that the camera is always present but may be not operational? Thanks. -- Dmitry
