Hi all, I've been working on a couple of drivers with embedded people in mind. It's a simple proof of concept for a gpio-keys-polled driver and gpio-mouse based driver. It currently implements four gpio pins as 4 keyboard keys and 7 gpio pins as a 3 button mouse. The keypad driver works just fine, the mouse driver is untested but shouldn't have any issues, if there are any, let me know and I'll fix them.
the gpio-keys driver uses gpio 4, 17, 21, 22, which are pins 7,11,13 and 15 respectively on the gpio header to output enter, a, b and c.
the gpio-mouse driver uses gpio 18, 23, 24, 25, 7, 8 and 9 which are pins 12, 16, 18, 22, 26, 24 and 21 respectively on the gpio header to output mouse up, down, left, right, left mouse button, middle mouse button and right mouse button.
see here for the code: http://pastebin.com/Du463RdR
you should replace (after backing up) your arch/arm/mach-bcm2708/bcm2708.c file with the code from pastebin. These drivers will break or be broken by the spi drivers that are floating around currently, so disable them before using this driver.
it needs drivers/input device support/keyboards/polled gpio buttons either built in or as a loadable module, it also needs drivers/input device support/mice/gpio mouse either built in or as a loadable module and it also needs drivers/input device support/event interface built in or as a loadable module, you can enable these in menuconfig. Personally I set everything to built in. They should then register themselves as event devices
in /dev/input (I think).
You'll need to tie the appropriate gpio to 3.3v with a 10k resistor (should be ok, might need lower than that, 1.8/2k maybe) and then attach a button to ground for the gpio-keys and a joystick to the gpio-mouse gpios + 3 buttons. I've commented the code where I've made changes with // Reggie added
We can probably use internal pullups but I don't know how to do that and this way means that the pullups can be removed and the pins reused with minimal effort.
you can also use evtest (sudo apt-get install evtest) to see if the keys/mouse are working, although for the keys you should be able to see them working directly in the console, the should output enter, a, b and c. I guess the mouse will need X if you don't want to install evtest. I haven't looked to see what cpu usage is like, the drivers both use a polling method, I think I set it to a 20ms polling period with a 5ms debounce and no autorepeat on the gpio-keys driver.
It would be possible to implement a fairly decent keyboard built into the pi with the 16 gpio pins, in an 8x8 matrix (see matrix_keypad.c in the sources for more details), as I mention in the comments, this would be pretty wasteful of the i2c/spi pins and other alt functions. so an i2c/spi port expander would be a better implementation if you needed to do a full keyboard.
There are also other examples of using gpio pins in the linux kernel driver sources, such as rotary encoder, leds (working example already in bcm2708.c!!) and also gpio-fan control. It would be nice to implement gpio-keys as an interrupt driven driver, it might not seem particularly practical for a full blown desktop machine but you could quite easily build yourself a nice embedded device with a control interface that you've built entirely to your own custom specifications
It should be relatively simple to implement something like an arduino with the ps2 library, and then convert the data from a mouse/keyboard into pure 'gpio' data that gpio-keys/mouse could use. it also mentions in the gpio-mouse drivers about using a joystick, this would allow you to use arcade sticks, console gamepads, pretty much anything you like to build a custom controller for the pi.
There is so much more to the gpio-keys/gpio-mouse/gpio-fan/gpio-leds and rotary encoder gpio drivers than I can mention, there are numerous different key types (switches, abs, rel axis etc.) that you can set, which you can obviously use in your own apps. or drivers, like a power button for instance. It would be fairly simple to control a whole menu system with just a rotary encoder and a single button, or a midi controller or simple digital sensor inputs to a custom application.
I'll see about getting a proper patch made.