[LEDE-DEV] multi-function buttons

[John Crispin]

On 23/02/2017 12:39, Piotr Dymacz wrote:
> Hello,
> 
> 2017-02-20 9:11 GMT+01:00 Mathias Kresin <m at kresin.me>:
>> 19.02.2017 14:31, Piotr Dymacz:
>>  > This is more like offtopic, but there is another one problem with
>>  > similar devices. Lets forget now about "Wi-Fi enabled or not enabled
>>  > by default" issue and assume we have a device which:
>>  > - doesn't have Ethernet interface
>>  > - serial access is not possible or very difficult to get
>>  > - has _only one button_, configured as rfkill (because there must be
>>  > some way to enable Wi-Fi after the flash)
>>  > - is or could be supported in LEDE
>>  >
>>  > What will happen if the user breaks wireless configuration (it
>>  > happens, I know it from experience) in this kind of device? Maybe,
>>  > just by an accident, (s)he configured channel "17" instead of "7",
>>  > saved changes, restarted Wi-Fi and... ended up with a nice
>>  > paperweight.
>>  >
>>  > In this kind of situation, the "rfkill" button is useless (wireless
>>  > configuration is broken, Wi-Fi can't be started). Failsafe mode can be
>>  > enabled but is not accessible. AFAIK, there is no way to perform
>>  > "firstboot"/"factory reset" in this situation.
>>  >
>>  > Of course, this is more like an extreme case (no Ethernet, no serial
>>  > access, only one button), but IMHO it shows that if we want to support
>>  > devices without Ethernet interface, we should make failsafe mode
>>  > working for them.
>>
>> Hey Pepe,
>>
>> let me start a new thread regarding this issues.
>>
>> After I pushed
>> https://git.lede-project.org/bcfbeae79f799cf1087d692e4869589eb20d2080 we had
>> a discussion in IRC because what I've done in the commit wasn't that
>> correct.
>>
>> I've changed the linux,code of the buttons to RF_KILL/0xf7 to have this
>> enable WLAN functionality. But the with that change the send keycode doesn't
>> match any longer what is printed in the case. Means, a WPS button should
>> send the KEY_WPS_BUTTON keycode, a Wifi button should send KEY_WLAN, a Wifi
>> on/off button should send KEY_RFKILL and so on.
> 
> I agree and I think we should keep this as a general rule: if the
> button/switch has a known _single_ function (e.g. it's printed on the
> device enclosure or we know how it works inside the vendor firmware)
> we should assign the same key code in LEDE.
> 
> But, as in the message subject, what should we do with multi-function
> buttons regarding the key code (there is no way to use more than one
> key code in kernel)? Who should decide what key code will send button
> marked as "reset/wps", "wps/reset" or "wifi/reset" (in fact, these are
> existing examples)? Can we maybe agree about some general rule here
> too? Like, we prefer "reset" key code over "wps" and/or "rfkill" etc.?
> Or maybe we should leave this decision for the person who adds device
> support in code?
> 
>> Jonas came up with the idea of interpreting the "wps" button press as
>> "rfkill" in userspace instead of changing the meaning of the buttons in the
>> dts file(s). John and Felix joined the discussion and we agreed that having
>> something configurable in userspace for interpreting the keycodes would be a
>> good idea. It can be extended to have timer based interpretations as well
>> (10sec press do A, 20sec press do B and so on).
> 
> [...]
> 
> I really like the idea of having something configurable. Personally I
> prefer to have it in system config as for LEDs and actually, that kind
> of "configurable user space code" was for long time already in the
> repository and got dropped not that long time ago [1].
> 
> I'm not convinced here only about static role assignments, like
> interpreting "wps" button press as "rfkill". What if the device has
> both buttons, what if it doesn't have the "reset" button? I'm worried
> that this could bring a lot of additional code needed to configure all
> of this in advance (board.d/uci-defaults).
> 
> I was thinking about a slightly different and hopefully more universal approach:
> 1. Keep default functions for known buttons (same as now in /etc/rc.button/*).
> 2. Allow configuration from userspace, with support for timer based handlers.
> 3. Include "wildcard button" support with two interpretation set by default.
> 
> For last point, we could define some general, timer based handlers for
> _any_ button (wildcard), e.g. (take below values only as examples):
> - 15-29s: rfkill
> - 30-...s: factory reset
> 
> IMHO, above two functions are the most important from user perspective
> (there might be more of them).
> 
> With this approach, we are solving two issues at once:
> 1. Wi-Fi can be enabled with any button (no need to change original
> key code) in devices with only Wi-Fi interface and at least one
> button.
> 2. Default settings can be restored with any button (also useful for
> devices with only Wi-Fi interface and broken wireless
> configuration/useless "rfkill" button).
> 
> What I'm not sure about here is should this "wildcard buttons"
> functions be also configurable (and thus, could be also
> disabled/removed) by the user or should we for example keep them as
> last steps, after checking all configured timer based functions for
> "released" action. I see here also problem with overlaying time
> ranges, but we can just assume that it would be up to the user to
> provide correct configuration.
> 
> Last but not least, I would like to have this "wildcard button"
> support inside the failsafe mode, at least for issuing
> "firstboot"/"factory reset". As I wrote in previous mail, this would
> be like a "last resort" for devices with Wi-Fi interface only.
> 
> [1] https://git.lede-project.org/?p=source.git;a=commit;h=0a3d721465e10bdc4237b996756b79ff4d868fe1
> 
> ---
> Cheers,
> Piotr
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

Hi,

i like this approach. i would liek to keep reset as the default, then
have the option of setting an alternate button inside uci on a per board
basis. the alternate function would be triggered by a predefined timeout
5 or 10 s would be good

a uci section could look like this

config button
	option original	reset
	option alternate rfkill
	(option timeout 15)  <-- this is optional and defaults to 5 or 10s if
not set)


	John