Hi, On 4/25/23 23:09, Jonathan Singer wrote: > The key itself triggers a hardware response both on windows and linux. > It disconnects power from the camera USB module and raises a cover in front > of the camera aperature. The keycode is as far as I know only to notify the > operating system in case it wanted to show a message. > > Is that the kind of use case that would benefit from emitting a KEY_CAMERA? Actually we have SW_CAMERA_LENS_COVER for this and this is what new Dell laptops with a similar feature use. The problem with using a SW for this though is that we should then either: a) Figure out a way to identify models which will report this; or b) register a separate input_dev just for reporting the SW on the first event. This is necessary because unlike keys where only press + release events really matter and if those never happens no harm is done, switches can be acted upon by userspace in both there open and closed state, so the mere presence of an input_device with a SW_CAMERA_LENS_COVER may be acted upon by userspace. E.g. if we by default report SW_CAMERA_LENS_COVER=1 (so lenscover closed) then apps who want to access the camera may ask the user something like: "Your camera is currently unavailable, please press the keyboard combination to enable your camera" which makes no sense to ask on devices without such feature. Note that simply registering a separate input_dev for just reporting SW_CAMERA_LENS_COVER on the first event is a good workaround for this though. We already do the same in other drivers for SW_TABLET_MODE for similar reasons. A second problem is that we would need to be able to tell if we get the 0x1A event because of the camera being enabled or disabled, but perhaps this info is already present in the event_data ? Regards, Hans
