Hi, On 3/6/24 09:17, 艾超 wrote: > Hi > > > >> I would be interested on which devices this driver was tested and is >> expected to work with. > > > > Lenovo A70，it is a Computer integrated machine. > > >>> This looks similar to a switch. >>> Would it be more useful for the user to report a standard switch instead >>> of a key event which needs to be correlated with the sysfs file? > >> I agree, maybe SW_CAMERA_LENS_COVER might be the right thing to use here, >> if those camera states (open/closed) are meant to symbolize camera shutter states. > >> In such a case the initial switch state has to be retrieved, or else the input device >> cannot be registered until the first event is received (similar how the hp-wmi driver >> handles SW_CAMERA_LENS_COVER events). > >> Ai Chao, can you tell us if those two camera states are meant to act like a switch (camera switched off, >> camera switched on) or meant to act like a key (camera button pressed, camera button released)? > > > > The camera button is like a switch. I can used SW_CAMERA_LENS_COVER to report input event , but the OS > > can't to show camera OSD. OS need a key value map to the camera OSD. Please use SW_CAMERA_LENS_COVER in the next version, that really is the correct thing to do here, so that you not only report the event of the camera state changing, but also the actual camera state (on/off) to userspace. This will also allow you to remove the custom sysfs atribute since you are now correctly reporting the value to userspace through the evdev event. As for userspace not responding to SW_CAMERA_LENS_COVER, this is because SW_CAMERA_LENS_COVER is relatively new and we need to add support to userspace for this. SW_CAMERA_LENS_COVER is already used on whole a bunch of Dell laptops for this, so we need to do this anyways. Please file an issue against GNOME, lets say against gnome-settings-daemon for this. Regards, Hans
