What sorts of software is in the works?

Discussion in 'Software' started by MuadDirac, Jul 21, 2014.

  1. MuadDirac

    MuadDirac New Member

    I was just curious what AcidFire, or anyone else, had in mind for this. What sorts of things would be in software that would fall outside the scope of the firmware for the boards? I assume configuration software for loading layouts onto the board, but I was wondering what else might be planned.
  2. AcidFire

    AcidFire I Make Stuff Staff Member

    The plan for the desktop software covers a few points:

    1. Configuration - The most obvious bit, and the majority of the software's functionality/purpose. This will not be required to use your layouts, or even build them, but it should definitely make the job easier.
    2. Application Switching - When you are running the desktop software, it'll hotswap your layouts based on what you have set for each application. The cool part is, this means your shifted layer could be different in Photoshop than your regular setting.
    3. Backups - Completely optional, allows for offsite syncing (anonymously of course) of your layouts & settings that you can pull from anywhere. You can also log into the website and manually download your layouts as well.
    4. Layout Browser - Tying the functionality between the backups & configuration portions of the software, you'll be able to share and browse layouts others have shared, and add them to your board.
    5. Layer/Layout Indicator - This isn't a v1 feature, but I'd like something to pop up (in a position of your choosing) on your screen to let you know which layer/layout you're currently using).
  3. Koren

    Koren New Member

    That's interesting... Does the desktop software send a message to the keyboard so that the keyboard send different keycodes, does it re-upload complete layouts in the keyboard on the fly, or does the keyboard always send the same keycodes and the desktop software change them based on the active application?

    I don't really see the last solution working (I can't imagine how to do it correctly), and it's also the less interesting one. So, second solution, I guess? Really curious about this because I would find useful to base the layout on the file extension in the case of a text editor, in the "perfect world" (e.g. I intend to use different layers for .cxx and .tex files, but if the switch can be automatic, it's even more wonderful ^_^)

    Anyway, that's a really great idea. The layer indicator is an interesting and useful one, too.

    Which OS would get full support, btw? That's not the kind of tricks that are easily cross-platform...
  4. AcidFire

    AcidFire I Make Stuff Staff Member

    The aim right now is for the software to notify the keyboard as to which layout should be loaded. However, it doesn't lock it to that layer either, allowing you to switch to another if need be without having to click away from the window.

    As for the different layouts based on the program, I think there might be a better analogy for it. I'd like to implement it more like a playlist, so that the layers that you can shift through are all related to the program you're working on, which I think is along the lines of what you're wanting. Obviously theres going to be a lot of real world testing and feedback, and that's one of the reasons these forums are up ;)

    OS wise, thats a bit more of an interesting discussion. If you had asked me a year ago, Windows would have been the automatic answer, but I've talked with so many people that it's a bit more up in the air right now. Currently, I think the first version of the software may end up being written in Java (yuck I know) to make it a bit more portable between platforms, with the plan to move to something more focused for each platform as time goes on.
  5. pdf

    pdf New Member

    A Java (or other cross-platform language, there are a number to choose from) configurator is probably a good start. What sort of protocol will you be talking to the keyboard over? If you need to talk USB, life is going to suck a little bit because you'll need to rely on libusb bindings for whatever language you choose, and that'll mean shipping platform-specific libs along with the application, so then you've got architecture issues too. It might be easier if you can get the board to expose both a serial and HID device over the USB mux, then you can just talk serial to it, and that will remove some headaches on the software side. Not sure if this is possible with your hardware or not though.

    The desktop integration stuff is pretty much impossible to get done cross-platform. Best bet would be to look at this as a separate project.
  6. Koren

    Koren New Member

    I'm pretty sure that's the case. Arduino boards can expose (Leonardo does it natively) both an HID interface and a virtual COM port. IIRC, AcidfFire's keyboard is based on Atmega 32u4 so I guess it'll work the same.


    (Besides, the libUSB solution wouldn't seem such a problematic solution anyway. It works on Unix world, probably quite easily on OS-X since it's quite close to Unix, and on Windows, I believe I already used it though Cygwin.)

    I also think that most of the desktop stuff is indeed mostly seen as a separate project, and the main objective no is to make the keyboard itself available, and the basic software needed to load the layers in the keyboard. There'll be enough help to cover most of the OS possibilities (I'll probably work on Linux stuff myself since AcidFire will probably cover most of the Windows needs).
  7. pdf

    pdf New Member

    Are you sure they can both work at the same time on the one USB mux? That SE question you linked is contradictory - even though the answer was accepted because it quoted the Arduino example code, the response immediately below that states anecdotally that they can't both work at the same time.

    EDIT: Okay, this suggests that it should indeed work in parallel:

    Bleh, it's still a pretty ugly mess. It definitely can work on OSX/*nix/Win(win32-libusb), but now with the whole libusb->libusbx->libusb fork/merge pain, you can't rely on the system providing a useful version, even on Linux. So, you'll need static libs, for every OS, and then for every architecture, that you want to support (win32/linux/osx/solaris?/*BSD? multiplied by x86/x86_64/arm?). It's a total shambles. Using serial for communication would remove that maintenance nightmare and packaging mess.

    Yeah, I'm on Linux here too, glad to hear someone will be running with this.
  8. Koren

    Koren New Member

    Sorry, I took one of the first reference I found simply to illustrate the idea. I don't know/remember exactly how AcidFire wants to handle this, but usually, you have a lot of possibility available in the way you handle the USB connexion.

    With basic software from Arduino, you have indeed to switch between both behaviors, if I'm not mistaken, if you don't want to work too much on the code. I don't think it's such a problem, though, I'd say that the virtual com port is only really handy during reprogramming, not when you're typing. There's usually enough communication available in the HID K/M protocol to send a couple of simple things to the keyboard during normal operation.

    If it's not enough, there's a second serial port on the chip that can act at the same time as the HID interface (and in fact there's several chips, so there's plently of solutions), but you could need several cables. But in fact, you can go a little farther and make the keyboard work, for example, as a USB hub in which is plug a K/M (HID) and another device that brings a virtual serial communication. I'm wondering whether you could in fact also allow the SD card in the keyboard to be seen as a universal storage device of some sort at the same time, too...

    I wasn't aware it was such a mess (the last time I used libusb was to make a Linux computer communicate with a Namco Universal Train Controller... which was broadcasting itself as an HID device but with so many abnormal things that it was unusable as an HID device, and it was pretty basic stuff).

    I tend to like static linking, too, when I develop, in part because of this kind of issues.

    Believe me, I intend to spend a lot of time on it, since I spend hours a day in front of a computer, and this keyboard should become my primary input method if everything go well. I even developped half a firmware for it just for fun during the summer because I was so excited. ^_^

    I was wondering whether AcidFire would be interested in turning the software tools into an official Debian package, for example, so that it could become quite standard on many distros.
  9. AcidFire

    AcidFire I Make Stuff Staff Member

    We're actually not running a 32u4, it's currently the NXP LPC11U35/37 with the strong possibility of moving to the LPC11U68. We chose this over other ARM offerings primarily because the chip supports onboard ROM profiles for various USB devices including HID, MSC & CDC. You can also define and create composite devices in this manner, which gives us a few different ways of looking at NKRO.

    See above, most definitely possible ;)

    Depending on what it's for, like hardware, this is something I'm a fan of as well. When it has to be rock solid first, static tends to be the way to go in my book.

    I'm very much looking forward to what you guys come up with once I can get hardware out to you :D And I'd love to get an official package for Debian distros, since I'm currently a fan of Ubuntu on the desktop (servers currently run CentOS for stability)
  10. Koren

    Koren New Member

    Oh, I'm sorry, I actually knew that (you talked about rom size) but just forgot about it.

    Then consider it done (assuming it comply with the rules, but I don't see why it wouldn't)... If there's no other taker, four of my friends are Debian developpers or maintainers, and if none of them accept to adopt the package, I'll apply to become a maintainer myself (I've been thinking about that for a long time, would be a great opportunity)
    dshk likes this.
  11. davidaciko

    davidaciko New Member

    Please also provide a tarball for those of us on source-based (Linux) distros. I'd be happy to help with any Linux stuff as needed.

    Sorry I've been gone for so long everyone (it's been crazy here lately). I'll try to reply to stuff later today.

Share This Page