Hello, 2017-02-20 9:11 GMT+01:00 Mathias Kresin <m...@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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
