Make Button Interface `\sys` Device Based

[rhempel]

While I appreciate the ability to use the standad Linux GPIO interface fo reading buttons, it is a total pain that there is not also a /sys interface to get button state.

Currently, we require an ioctl to read the button state from user space, which is fine for scripting languages like Python that have an ioctl library. But it does not help that the only peripheral on the EV3 that requires ioctl calls is the buttons, and for languages like Lua or even bash and awk we need to write a Language binding for ioctl and add it to the binding package.

I can write a button class for /sys that works pretty much like the attribute system we have today, where querying the state simply returns a list of all the pressed buttons.

Comments? Any reason why this is a particularly bad idea?

[dlech]

I don't see a problem with doing things this way. You should update http://www.ev3dev.org/docs/tutorials/using-ev3-buttons/ to explain how to accomplish the same thing without using an ioctl.

[dlech]

Wait a minute. I thought you were saying that there was already a way to do this from /sys. I say, no, don't write a button class because it will only work for the EV3 buttons. Any USB or Bluetooth keypads, keybords, gamepads, etc. will be different. Instead, you should focus on a solution that works for everything.

[dlech]

By the way, proper use of the LCD screen requires ioctls as well.

[rhempel]

Well, the LCD needs IOCTLs now, but maybe we can fix that :-)

Right now the Python API has a nice ButtonBase class that is extended to handle the remote control.

So I'm talking about fixing the EVIO Button class which is just the EV3 front panel.

The other way to do it is to write a little platform (or device) specific daemon than handles the ioctls that we care about through a sys file attribute.

I'm just throwing ideas out here - but the ioctl requirement is something I'd like to get rid of...

[dlech]

The linux input framework is really meant to be event based, which is why there is only an ioctl for this. You can read /dev/input/eventXand it will tell you whenever a key is pressed, no ioctls required. You can monitor this in a background thread and save key states in a variable whenever there is an event.

Another option is to use ev3dev kit. Since is uses gobject introspection, it is designed to be used by pretty much any language (except maybe bash).

[rhempel]

I am trying to make things as easy as possible for people getting into coding that don't think about event based frameworks as easily as "just give me a function call that returns the buttons that are pressed now" :-)

Is a platform specific daemon a reasonable approach for languages that don't support blocking file reads and multithreading?

The goal is to be able to read a file and get a list of buttons that are pressed.

[dlech]

You have a bit of conflict of interests here I think. To get something in /sys, you have to write a kernel driver. A system daemon is user space. But, the buttons/keys (and the framebuffer) are pretty much 100% mainline kernel code, and I know you don't want to touch that.

How many (reasonable) languages actually can't actually bind to C code or make syscalls? bash obviously, but that is borderline not a reasonable language and it is easy enough to write a utility program to check key states.

For example, a quick web search shows 2 different options that should work for Lua.

I'm totally with you that we need something simpler, but we are dealing with the most ancient parts of the linux kernel, so it is not making it easy for us.

[dlech]

Here's an idea. I was considering making a configfs sensor driver for userspace sensor drivers (I was mainly thinking of doing this for mindsensors.com BT sense android app). Basically you have to have a userspace program that sets up the driver via /sys/kernel/config/lego_sensor and then writes data to a sysfs attribute somewhere. This will create a sensor in the usual /sys/class/lego_sensor/.

This could be used for the EV3 buttons. We just create a program that listens to the "EV3 Buttons" input/event device and pushes the information to the "sensor". The users can read the buttons just like a touch sensor. The value0 - value5 attributes would be the 6 buttons.

What do you think?

[rhempel]

Yes, something like that could work - seems a bit roundabout but it's doable. Another option is to have a kernel module specifically for the EV3 buttons that does not interfere with the existing event driven button I/O. It creates a sys entry and responds to reads of the buttons_pressed attribute with a list of pressed buttons. Underneath the attribute read is a function that does the ioctl magic.

I know this is counter to the Linux input event handler, so I'm not suggesting we get rid of that - this is just another, hopefully easy way for button states to be read in a non-event capable language.

[dlech]

I still don't like the idea of doing something "specifically for the EV3 buttons". If we are going to put the effort into it, I think we should do something that works for all linux input devices.

If you are absolutely set on having something in sysfs, I think the most practical (and least amount of work) would be to add a state folder to /sys/class/input/inputX/ that mirrors the existing /sys/class/input/inputX/capabilities/folder except that it returns the current state.

If you want something that is only for EV3, then copy the gpi-keys module and modify it so that it exports key states. However, this won't work for PiStorms or EVB because the buttons on those platforms are not GPIOs.

But, I like the pythonic principal that there should only be one obvious way to do a thing. All of the raspberry pi blogs out there are going to tell you to read input events from /dev/input/eventX, so it seems like we should find a way to make this work for us as well.

[ddemidov]

One point for some universal solution (and against making a kernel module just for EV3 buttons): anything with a USB port may have a USB keyboard connected. It would be nice to be able to work with such keyboards in a generic way. I am aware that our current python API only provides interface to EV3 buttons, but as I understand, the buttons use generic event interface that could work with any kind of input devices.

[rhempel]

I was doing some reading and I think that a userland program that uses libev3dev is the way to go - it does not interfere with the ability to do event driven or ioctls - and I think it gives us the ability to read the EV3 buttons from a file and yet allow the standard button API to still work.

[dlech]

libev3dev

Do you mean libevdev or ev3devKit?

[rhempel]

I mean libevdev :-)

[rhempel]

@dlech, I am coming around to the comment you made here - except that the sensor device should probably return a list of pressed button names instead of one button per value - I'm going to experiment with libevdev to manage processing events using the normal Linux event devices, and then have it write the current state to something in /sys/...

This userland program that runs in the background might also be a handy way to manage the display interface, but that's for later...