library fixes to get Adafruit OLED Bonnet working

[BeauSlim]

Got an Adafruit OLED Bonnet for my Pi Zero and your UI looks like the best option for getting a simple menu going. Of course you have a major project going on here and this is a minor thing, but I thought I would give you the option of ignoring it since these little OLED boards might end up being popular. Adafruit is selling them in bundles with Zero Ws.

I had to change luma.core.serial to luma.core.interface.serial in output/drivers/luma_driver.py

I needed to change to pull UP in pi_gpio.py to get the built-in 5-way joystick and 2 buttons working. An option in the config.json would be nice. I'd do a pull request, but I'm just getting into Python and I don't think you'd like my patches. :-)

[CRImier]

Hi! This is great, thank you! I've seen the Adafruit OLED Bonnet before, it's a nice little thing, and it's used in projects like Radiomesh, even! pyLCI was originally meant to be an interface for input&output combos like these, so adding support for this pHAT is a priority.

I don't yet have one, so a pull request would be much appreciated. Barring that, I will see what's the problem with luma.core.interface. imports, and add pull-up/down support to pi_gpio driver. I will also think about adding a config.json option =)

BTW, you might want to map these buttons to KEY_PAGEUP and KEY_PAGEDOWN, navigating the menus is just so much faster! I will be changing page up and down keys to KEY_F3 and KEY_F4, but I will let you know when that is upstreamed (likely, along with a driver for the Bonnet =) )

Could you please share your config.json?

[CRImier]

Also, how did you like the documentation you found along the way? Any places you could point to where it's lacking?

[BeauSlim]

Sorry for the delay. Ok, I'm new to pull requests, but I submitted one for the luma.core "interfaces" issue.

I guess I'll do another pull for the gpio pull-up issue so you can see what fixed things for me and then add an option to the json file for it. Or leave that and I'll submit a proper patch at some point in the hopefully not too distant future when I'm more up to speed on Python.

I changed the extra 2 buttons to page up and down. Yes, that is helpful.

My current /boot/zpui_config.json is

{ "input": [ { "driver":"pi_gpio", "kwargs": { "button_pins":[17, 22, 27, 23, 4, 6, 5] } } ], "output": [ { "driver":"ssd1306", "kwargs": { "hw":"i2c", "address":"0x3c" } } ] }

[CRImier]

Yep, page up and down keys are very, very helpful with big menus and small screens! You changed the mapping in the driver file, right? I assume you did, if so, can you share the modifications? I'm going to add an "adafruit_oled_bonnet" input and output drivers, which would just pass-through options to ssd1306 and pi_gpio drivers, so the config would be less verbose - and I'd also like to add the key mapping changes =)

[CRImier]

So, it seems I also need to implement input UI element switching - since you won't be able to use NumpadCharInput, but only CharArrowKeysInput, and, as NumpadCharInput is currently hard-coded everywhere you can input characters (including, for example, WiFi password entry menu), I need to somehow distinguish between different input drivers and serve limited UI elements to the drivers that don't have additional buttons necessary. For that, I finally need to implement input driver capabilities =) Will open an issue here, or, if I'll have enough time, I'll implement it right away.

[BeauSlim]

Yes, I changed the default_mapping to this:

default_mapping = [ "KEY_UP", "KEY_DOWN", "KEY_LEFT", "KEY_RIGHT", "KEY_KPENTER", "KEY_PAGEUP", "KEY_PAGEDOWN", "KEY_DELETE"]

to match the button order in the .json file above. There is no button that corresponds to the KEY_DELETE entry. Not sure if that is significant/important.

Yes, the joystick-and-2-buttons situation definitely makes text input difficult in general. My primary goal is to get a set of authentication tools to work, including a password manager based on hardpass, OATH OTP, and maybe Fido U2F, so I definitely need a way to input a decently complex password easily. I am playing with putting together an on-screen virtual keyboard.

Before I found ZPUI, I was playing with Adafruit's Retrogame to handle the gpio inputs. It maps gpio buttons to virtual USB keyboard inputs via evdev. It has the side-effect of typing on the console if it isn't hooked, but that can be a good thing. It might be useful if you are looking to move toward a more flexible input framework, funnelling everything through the standard linux user input handling. Retrogame also has some limited "chording" ability and pressing 2 buttons together can send a different character as input.

Totally unrelated: I don't know if you've run into Nerd Fonts before, but they let you display a huge number of glyphs and work great in your menus. You might try the ProFont version, which is a clone of the original (i.e. 1984) Macintosh Monaco font, and the smaller point sizes are proper pixel fonts. I think it looks really great on these small OLED screens. The 2 Ubuntu variations (monospace and proportional) work well, too.

[CRImier]

1. So, the "KEY_KPENTER" thing is definitely something I need to remove from the codebase. It was something that was originally done for compatibility with a USB numpad that I used to develop the very first version of pyLCI, and in retrospect I should've done that with a "special case" mapping in the driver - I wasn't good enough at the whole "planning" thing back then, though. You can safely use "KEY_ENTER", that's how ZeroPhone has been working for over a year now, so it seems to be compatible with the code - and, at some point in the future, "KEY_KPENTER" will be removed so that it doesn't confuse people (and the HID driver will get corresponding backwards compatibility functions)
2. There isn't indeed a button for "KEY_DELETE" - you can map it to whatever and use it as a special callback, I think - right now, there's a multi-context refactoring going on ( #8 ), one of the results of that will be that you'll have an option to instantly switch to an app of your choice by pressing a button, instead of navigating through the menus as it has to be done now =)
3. You saw the hardpass project, right? I just love it for some reason, I drew some inspiration from it while designing the ZeroPhone =) Are you interested in getting a board? I'll have a panel ordered soon, and I could put some hardpass front boards on it.
4. In the beginning, pyLCI input was actually based around evdev - which proved to be more trouble than it was worth. Each driver would create a HID device and send the events through evdev, and then pyLCI would use evdev to catch those events - which was a structure that was too complex for 99% of uses and was prone to various problems - so I went away from it before I released the first usable version of pyLCI. If you want to use a HID device (either a real one or one emulated from GPIOs), you can still use the hid driver, though - it worked well last time I checked =) BTW, ZeroPhone might also move to using hid once the onboard ATMega328P gets a proper kernel driver - then the driver will have to use a HID device for communicating keypresses to ZPUI (as I don't see why a kernel driver would use something other than HID for key events). This might also allow things like full-disk encryption, with the password entered on boot!
5. I changed the default mapping to the one you proposed), replacing KEY_DELETE with KEY_PROG1 - now it's in the ZPUI master branch. Currently, KEY_PROG1 is hard-coded as "MOCP next track", so you could just remove that line from apps/media_apps/mocp/main.py - sometime soon, there'll be a mechanism for apps to expose actions, and for users to map keys on those actions.

Thank you for the font suggestions, much appreciated! I'll have to go through these fonts sometime soon, see if I find anything that looks appealing to me... God knows I don't understand design as well, what's with all these fonts to pick from - I'd rather write a mechanism for users to pick their fonts =D

[monsieurh]

@CRImier May I point your attention towards #26 . I'm proposing such a system to have system-wide keymappings. I can take care of the refactoring after we decided how to do it.

[CRImier]

@monsieurh The PR you're talking about doesn't actually address this problem (as far as I understand from the discussion we had about it, correct me if I'm wrong). This issue is now tracked here: #42

[CRImier]

@BeauSlim I've implemented the "input UI element switching", which will allow you to fully use the Wireless and Scripts apps - it'll be reviewed soon and merged in the devel branch =)

[CRImier]

@BeauSlim BTW, I'd like to add official OLED Bonnet support (complete with documentation and working config.json). It'd be great if you could test the changes once they're finalized.

[BeauSlim]

Absolutely. Just let me know when it's ready and which branch to use.

[CRImier]

Happy to hear it! The input switching is already in the devel branch - it should pick up your device's capabilities from the mapping and pick the right input UI element - in your case, CharArrowKeysInput - allowing you to use arrow keys to enter words. It's slow, but it's already there in case you need to input a WiFi password and you don't have an easier option. To test it, go to Scripts app and pick "Custom command", it should allow you to enter a command with arrow keys. If it doesn't for some weird reason, let me know!

[BeauSlim]

Took me a while to have time to try it. Works fine on a fresh install (as of today) with my OLED Bonnet zpui_config.json. I gave the custom command "date" and received an appropriate output.

FYI, just for kicks, I tested this on the latest re4son kali distro for the Pi Zero W. They claim a performance increase over the Pi foundation's raspbian because it's compiled specifically for the ARM 11/v6 in the Zero, and it actually does appear to be quite a bit faster. For example, I get 20-30% faster fps running luma's perfloop.py benchmark. Interesting.