Search the Community
Showing results for tags 'driver'.
Found 2 results
Just saw a job opening for a Software Engineer at Swiftpoint No idea why Swiftpoint don't promote this within their community. It's likely there are many people who use their products that are in the software profession. These people already have love for the hardware and a desire to make the software better. As great as it is to see some unofficial news on Swiftpoint's software development, I personally I don't agree with the methodology of how they are building their drivers. As @Damir and I talked about in the Driver Features and UI Design post, we'd love to see the driver split into a microservice architecture. Where the UI module is completely separated and made open-source, allowing the community to add features and improve the overall design of the interface. Rant aside, it's good to see that they are putting some focusing on the software. I've said it many times before... the hardware can only be as good as the software.
<Rant> Hi, is there going to be a timeline for the MacOS compatible driver to be released? I understand that The Z works completely independent of the driver (it works on the firmware level, similar to my QMK equipped Ergodox EZ). So, my question will be, is it that hard to release a "configurator interface" that generates some kind of a compiled script that can upload to the MCU of the mouse for MacOS? Even my Ergodox has a MacOS compatible flash utility. I could care less if I need to open a configuration file of some kind, and edit it by hand, and then compile it, then flash it manually - just give me an access to the firmware so that I can modify my Z as I see fit without needing a Windows machine. Just a thought... </Rant> <Suggestion> Rant aside, the mouse is great. I would greatly appreciate if the configuration part of the firmware can be (somewhat) open sourced. The hardware it self is GREAT, the software is VERY WEAK. If only the firmware is partly open, it will alleviate many of my complains... Using QMK as an example, all my needs are everything within the "keyboards/[keyboard_name]/keymaps/[keymap_name]/" directory (or folder). For example, in my case, it would be "keyboards/ergodox_ez/keymaps/damir/" directory. I do not need access to the other directory or files OUTSIDE this scope to configure my keyboard properly, unless I want to do something within the core of QMK, - which most of the time are not needed - like to see how TapDance work. Judging from the "driver" application, I can tell if all it does is to generate some kind of a configuration file, and compile it against something then connect to the MCU, flash the firmware, and reboot/restart/reload the firmware/configuration. Learning QMK made me realize many strengths of the features within the original firmware for the Z. If only I can configure it to my heart content, that would be great. Open sourcing the [parts or all of the] firmware will help the product in so many wonderful ways. Users for Linux systems can have their own configurator. I can generate a web based configurator for the Z - imagine that you can configure a mouse using a web configurator, no need to install anything to configure the product if need be - and should I need to configure it quickly, just connect to the web, make (or change a configuration) save it in the cloud, then download the compiled firmware for later use. I'm pitching you guys an idea. If I were to be in your team, I'd use a fork of NGINX (or NODE.JS) to run a [heavily locked down] local web service that interfaces to a MCU controller/interface/flasher. These are the basic features of this kind of setup: The web service instance will serve a "local copy" of the user's profile created on Swiftpoint's user configuration repository. If the computer is online, then the local instance can connect to the public repository and synchronise. If the user is offline, or does not make use of the online repository, then run the service as local only and store everything in a local SQLite database for easy archive and/or retrieval. By making a public repository of configuration, you easily have a completely community run configuration repository that associates users to configurations, and you can easily manage/index/mine/whatever you want to do to it. The MCU controller/interface/flasher does not change a lot over time. You can patch it separately should there be any problem in the future. The web server part ran in an independent subsystem that you can update quickly should there be a bug or security hole (the beauty of using a publicly used code is this). You can have a multi platform configurator that can have different feature set on different platforms (you can synchronise it should you need it). You can update the "interface" part of the user facing configurator by updating a web based configuration repository template. All these subsystems can run in a very small, very optimised, very small memory footprint, and secure system. Easily patched/update/upgrade/secure in the future. The MCU controller/interface/flasher runs in the background waiting for events from the mouse and the web service (for automatic profile switching based on foreground apps). This should be very small because there is no assets to be loaded within it. Easily patched should there be a problem. The web service part (in my case, a local NGINX instance, or you can have NODE.JS) ran ONLY when the user is viewing the "driver" part is being viewed by the user. The interface it self, since it's working on HTML5 based instance, can be easily updated/overhauled/whatever you want to do VERY EASILY, without "driver" reinstallation even. A "traditional driver update" occurs only if the MCU controller/interface/flasher has any change or the web server is/are updated, other that these events, the update is VERY STREAMLINED. Want to add a feature to the configurator? Modify or add a new template to be synchronised by the end user. Want to port a feature to platforms other than Windows? Port the MCU controller/interface/flasher to that platform. The web service part is already multi-platform capable. The last idea, a big one: Want to make a new product(s)? Use the same stack for the new product(s)... All is well, everyone is happy, you sell many mouse, and be happy. One software stack to rule them all. </Suggestion> Well, just an enthusiastic user pleading to the company that made his favourite product to make his product to be even better... If you guys want to know more, send me an email :) Thank you, Damir.