On Thu, 2013-11-28 at 13:32 +0100, Rafał Miłecki wrote: > 2013/11/28 Hauke Mehrtens <hauke@xxxxxxxxxx>: > > On 11/28/2013 12:48 PM, Rafał Miłecki wrote: > >> This is just a RFC, so be nice to this "patch", please ;) > >> > >> My goal is to add support for buttons on bcm47xx arch. However after > >> analyzing existing database of devices I realized I don't know what code > >> I should assign to some buttons. > >> > >> First of all, older routers often have a "SES" button. SES stands for > >> SecureEasySetup and is Broadcom's proprietary protocol which was later > >> replaced with WPS (Wi-Fi Protected Setup). > >> Btw. WPS appeared to be broken because it's easy to attack it with > >> brutal-force method. > > > > Only a badly implemented WPS pin authentication is vulnerable to the > > brute force attack, as far as I know. > > Oh, indeed, I missed that. Thanks! > > >> I'm not sure if any distribution have any interest > >> in using that buttons, but it still would be nice to have support for > >> them in kernel. One option is to add KEY_SES for this purpose. > >> Is this the right way? It's similar to the KEY_WPS_BUTTON, but I wanted > >> to somehow distinct them. Is there any other option? Should I use > >> KEY_UNKNOWN or BTN_MISC or BTN_n? > > > > I do not think you or someone else plans to implement SecureEasySetup on > > a device running current Linux kernel, why not use the WPS button key > > for for these button. If someone wants to implement this just use the > > WPS button key for that. > > I'm just not sure about possible scenarios. I imagined end-user > pressing SES button router and SES button on a device and complaining > it's not working (because of SES being interpreted as WPS). > > If you guys think we should just use WPS for the SES button, I'm OK with that. Isn't the fact that it returns WPS or SES an implementation detail? Is WPS vs. SES just a software choice, or a hardware one? If it's a hardware one, you'd expect to have other ways to discover whether SES or WPS was requested (because that's the one supported by the hardware). If it's a software choice, then you'd expect the button to one or the other based on the software stack. Or are both possible at the same time, and there are devices with both buttons? Seems that adding a note that other similar "pairing" methods for Wi-Fi could be triggered when the button is used, in input.h would be enough. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
