Re: which driver to choose for a GPIO connected switch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexander Stein <alexander.stein@xxxxxxxxxxxxxxxxxxxxx> writes:

> On Thursday 24 February 2011, 11:26:21 Ferenc Wagner wrote:
>
>> Alexander Stein <alexander.stein@xxxxxxxxxxxxxxxxxxxxx> writes:
>>
>>> I'm just wondering which existing input driver I can choose to use an
>>> GPIO connected switch. The switch I'm talking about is connected via 3
>>> (interruptable) GPIOs and those GPIOs can be inverted.
>> 
>> How is the switch connected to the three GPIO inputs?
>> 
>>> I think gpio-keys is wrong as they will generate events on each state
>>> change. Note: The switch is likely to bounce
>> 
>> The gpio-keys driver has debouncing support.
>> 
>>> and the current GPIO state might be invalid (all 3 GPIOs are 0).
>> 
>> Why is this state invalid?
>> 
>>> I also think gpio-keys can't make sure only one switch state is currently
>>> present. So I may get a current state 1 on 2 or more GPIOs which is
>>> obviously wrong.
>> 
>> Sorry, I don't understand this.
>> 
>>> My use case is the userspace polls the current switch state if it needs
>>> to know.
>> 
>> EVIOCGKEY or EVIOCGSW ioctl, perhaps?  You can make it three keys or
>> switches in the driver, and put the validation logic into user space...
>> 
>>> Do you have any suggestions which driver to use or even write?
>> 
>> Maybe it's just me, but I think you'd better give a clearer description
>> of your problem to get useful suggestions.
>
> Ok, let's give it a try. I have a sliding switch which has 3 positions, namely 
> run, stop and reset. There can only be one position active at a time. None of 
> them or more at the same time are invalid. At least none active GPIOs is 
> possible due to the mechanical structure.
> Each position has a GPIO connected which affects the mounted pull-down or 
> pull-up. e.g. run GPIO has a pull-down to GND and when the switch goes to run 
> state the GPIO is raised to Vcc. The other positions are similar.

Got it, thanks.

> The problem I have with EV_KEY or EV_SW is they have just binary states. Maybe 
> I just should create a new driver which uses EV_ABS. Or is there already 
> something similar?

I don't know of anything similar, which doesn't mean anything at all.

I'd simply settle for using three gpio_keys switches (one for each
position) and poll all of them simultaneously by EVIOCGSW, filtering out
invalid combinations in user space.  This avoids driver development.

But don't listen to me, wait for the experts to chime in. :)
-- 
Good luck,
Feri.
--
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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux