Draft: arm64: dts: imx8mq-librem5: add an input key via the hall sensor
this is mainly an RFC that we could use the hall sensor as an input source.
SW_LID doesn't immediately make sense to me. Is there an input key that could be useful?
how to test:
run sudo eveumu-record
, select the gpio-keys and wait for events. You create the event by placing a permanent magnet near the back side of the phone, the area betwee the buttons(? @eric.kuzmenko or @angus.ainslie or @sebastian.krzyszkowiak would know better where it is).
It's described as a wakeup source so this is an elegant way to wake up the phone from system-suspend too.
Where is a permanent magnet? If you by accident own an X230 thinkpad laptop, the one for the LID is on the bottom side between the speakers. Touch the laptop and phone there and it works :) Other laptops might have one too, just look for it using a piece of metal (screwdriver or sth).
Merge request reports
Activity
I'm not sure we want to use that as an input key. We probably don't want userspace to register activity because of hall sensor input - same about waking up from suspend. As a user I certainly don't want my phone to react to placing it near random magnets unless I explicitly configure it to work this way.
Usually that sensor would be used to detect back cover being taken off, but we don't have a magnet there, so I don't think it's useful to make it do anything by default. Figuring out a way to safely expose it for people who want to play with it would be still nice though.
Well, placing the phone on a magnet is "user input". It is a "switch" type of event. We could think about sending
SW_CAMERA_LENS_COVER
( https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/input-event-codes.h#L912 ) since the lens is quite near there "for now", and go from there. Conceptually that would be a pretty reasonable description.But I agree overall. I'd remove the
wakeup-source
property and just want the hall sensor to be available for playing with it. SW_LID is widely used and thus wrong here.Edited by Martin KepplingerIt's not a lens cover. It would be perfectly valid for userspace to automatically launch camera app when camera lens is uncovered (Maemo did that, for example).
I have a lot of stuff on my desk and randomly placing a phone near something that happens to be a magnet is not "user input". I'm not sure it can be safely exposed as a key event at all without userspace resetting idle timers, unblanking the display etc.
added 15463 commits
-
36af2647...52719a38 - 15462 commits from branch
Librem5:pureos/byzantium
- cd8f89bf - arm64: dts: imx8mq-librem5: add SW_LID key via the hall sensor
-
36af2647...52719a38 - 15462 commits from branch
@nicole.faerber at the correct spot, it works from the front/screen side as well, not only from the back side of the phone.
Awesome! Thanks for double checking! Can one read this from userspace somewhere, like /sys/class/gpio/ or such?
Ah, wait, GPIO key, OK, need to test this...
I think the event type best used will depend on the use case. The use case I had in mind was the wake up when a cover gets opened, that would then probably make sense to tie to something like LID. I am also not sure if this needs to be a keyboard event at all? On PCs this is handled through ACPI which we do not have here so keyboard could be the next logical alternative.
Edited by Nicole Faerber
added 19295 commits
-
cd8f89bf...263c3189 - 19294 commits from branch
Librem5:pureos/byzantium
- befce352 - arm64: dts: imx8mq-librem5: add SW_LID key via the hall sensor
-
cd8f89bf...263c3189 - 19294 commits from branch
added 17825 commits
-
befce352...9ab8729f - 17824 commits from branch
Librem5:pureos/byzantium
- 16ccfb45 - arm64: dts: imx8mq-librem5: add SW_LID key via the hall sensor
-
befce352...9ab8729f - 17824 commits from branch
added 18796 commits
-
16ccfb45...83bab2e2 - 18795 commits from branch
Librem5:pureos/latest
- e8010ecb - arm64: dts: imx8mq-librem5: add SW_LID key via the hall sensor
-
16ccfb45...83bab2e2 - 18795 commits from branch