which driver to choose for a GPIO connected switch

which driver to choose for a GPIO connected switch

[Alexander Stein]

Hello,

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.
I think gpio-keys is wrong as they will generate events on each state change.
Note: The switch is likely to bounce and the current GPIO state might be 
invalid (all 3 GPIOs are 0).
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.
My use case is the userspace polls the current switch state if it needs to 
know.
Do you have any suggestions which driver to use or even write?

Best regards,
Alexander

Re: which driver to choose for a GPIO connected switch

[Ferenc Wagner]

Alexander Stein <alexander.stein@systec-electronic.com> 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.

Hi,

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.
-- 
Regards,
Feri.

Re: which driver to choose for a GPIO connected switch

[Alexander Stein]

On Thursday 24 February 2011, 11:26:21 Ferenc Wagner wrote:
> Alexander Stein <alexander.stein@systec-electronic.com> 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.
> 
> Hi,
> 
> 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.
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?

Alexander

Re: which driver to choose for a GPIO connected switch

[Ferenc Wagner]

Alexander Stein <alexander.stein@systec-electronic.com> writes:

> On Thursday 24 February 2011, 11:26:21 Ferenc Wagner wrote:
>
>> Alexander Stein <alexander.stein@systec-electronic.com> 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.