Separated out drivers.

[terricain]

Refactored the keyboard driver, the firefly now has its own kernel module. Added simple example of driver based persistence/state, now after you've set the brightness for the first time set_brightness can be read from to report the brightness.

Seperated out some common functionality to razercommon.c and razercommon.h, and by doing so made Kbuild very unhappy, though it hid its unhappiness and eventually I found that the file names needed to be changed for it to link and export symbols properly.

Updated the packaging scripts to handle new files etc..., updated the udev scripts to support the firefly. As finicky as udev is, it works on my machine and its quite cool when it works (no manual binding :) ).

ToDo:

• Statistics. I don't believe the keyboard tracks the number of keypresses, I think the synapse app does that but I'm going to investigate that anyway.
• Add serial number to DBus.
• If keypresses are not stored in the keyboard then I might adapt the daemon to do so.

[lah7]

Statistics. I don't believe the keyboard tracks the number of keypresses, I think the synapse app does that but I'm going to investigate that anyway. If keypresses are not stored in the keyboard then I might adapt the daemon to do so.

By this, are you planning on the total number of keys pressed in one session, or individual keys?

If it's the latter, I wouldn't want that - invasive feature to have. :expressionless:

[terricain]

Well if you want heat maps, distance travelled in terms of key distance etc... you'll need the latter. And in terms of implementation it wouldn't store key sequences so I don't think its invasive, plus it would be optional ;-)

And for that reason I think that's why razer only record it during games.

[lah7]

Good, good, just checking. I'd be worried if the daemon started constantly recording the number of times keys were pressed. An off/on switch would be sufficient, or maybe even activated alongside when Game Mode is turned on?

I don't really know how Razer activates it automatically on Windows games (if it even does that)?

[terricain]

Game mode is an issue currently. As I believe the daemon only listens to the main keyboard device not the alternate one game mode uses (the keyboard technically presents itself as 2 keyboards).

I've been toying with the idea of redoing the daemon, keeping the awesome custom effects part but just doing a massive restructure, and making it multi-threadded.

Yeah I'd like to record individual keys as I'd like to have the metrics like the current Razer app does but I'd definitely do it in as non invasive as possible of course. The way they would be recorded wouldn't be able to be used for any other means, other that the statistics I was going to do.

From what I can tell when I did some digging, Razer has a whole library dedicated to scanning for games, have just installed Minecraft on my VM and will see what it does. On windows it would be trivial to tell when games have started.

[pez2001]

the daemon actually contained a heatmap which i have deactivated at the moment.it was a very early test. but i guess a better place after adding a complete event system is in an effect. removes complexity from the library and makes no sense for other devices like mice,mousemats,etc.

[pez2001]

why again do we need to split the drivers ? i see no gain from it ,but it increases redundancy and multiple places to fix when a single bug is found.i may be wrong ,please give an explanation. (on a side note we probably should share the copyright in razer_common.c :-) it contains the only function im really proud of (crc) [i came up with it without any knowledge except the usb packet dump]

and we should discuss the multi device implementation and what we want to achieve with it.that is my main priority right now. i started by adding multi device functionality to the librazer_chroma part.but since i havent planned for it in the beginning its not a trivial task.

im not a fan of multi threaded code if there is no absolute need for it. the most important thing for me has always been cpu usage, i just hate pretty much every 'support' app of devices for using my precious cpu cycles for advertisment and other totally irrelevant stuff.

but also i want to thank you too for all the hard work and HOURS you two put into this.im still stoked by the cool stuff you added. its the first project in a long time in which im not doing the coding work alone.so please excuse my lack of communication skills. and also as you surely have noticed english is not my mother language (you are welcome to fix all my stupid mistakes i make on a regular basis)

it would be nice to have an #irc room or something to learn a bit more about each other.

best greetings tim

[terricain]

why again do we need to split the drivers

For a few reasons. Yes I agree there is currently a lot redundant code, that we can deal with in subsequent commits. Most importantly separating them out far reduces complexity in the keyboard driver, the less amount of if(device) do this else if(device) do that... the better. With the firefly in a separate driver it doesn't inherit unwanted methods like enable_macro_keys... and too the firefly complexity can be lowered (yes we could add if statements but see above). Also as its in its own file its easier to see in definitive terms / at a glance what the firefly can do, not worrying about if this function works for this device. Another benefit is that each driver is smaller (albeit not by much) and people can pick and choose what one they want, and logically speaking the firefly is not a keyboard so technically shouldn't be embedded in a keyboard driver ;-). Also by separating them out you've simplified the device discovery logic, as now inside of /sys/bus/hid/drivers/ there are 3 folders razerkbd, razermouse, razerfirefly which contain device symlinks inside of them (yes we could use USB vendor product but individual folders for those is so much more pleasing to look at). So yes for now it does contain a fair amount of redundant code but once that's fixed I think the gain in simplicity is warranted. Also if one of the drivers decided to die the others are not effected (I'm a big fan of redundancy me).

share the copyright in razer_common.c

Yeah sure, I do think your CRC is cool, I too was quite impressed by it. By all means add yourself or anyone else to any copyright they are missing from, next commit if your not there and I remember I'll add you.

and we should discuss the multi device implementation

It would be nice to plan this out properly etc... as building it from the start with multidevice support would probably be better and easier (plus now we can ID the devices with serials). As theoretically we should be able to support 2 chroma keyboards being plugged in. We should probably start an issue to do with this, identifying a list of features it must perform.

im not a fan of multi threaded code if there is no absolute need for it.

Ahh see I'm a big fan of writing multithreadded code ;-), but of course this wouldn't be stealing your cycles for advertising. From the quick system design in my head yesterday, If we want custom effects for multiple devices we could make a thread per device and each have their own render loop (in theory it would simplify things if you exclude the multithreadding hassle). Plus another benefit of multithreadding is that if one part dies it doesn't stop execution of the others, so redundancy ;). If your up for it, I think C++ would suit this well, mainly for the object-orientated nature of it (once again big OOP fan) as then we could make a simple plugin architecture where each device is a plugin, and each behaviour of the device is a plugin (that's one idea anyway).

but also i want to thank you too for all the hard work and HOURS you

No problem, we've all worked great and I'm seriously impressed in the rate at which this repository is progressing since I started back in September. We've gone from something not that stable/easy-to-use to near enough a fully functional driver and support applications (which I would say is pretty stable) in a few months. I really like the approach you took to the custom effects, though I must admit I think the main goal for the daemon should be device management which can then provide custom effects.

and also as you surely have noticed english is not my mother language

It hasn't been an issue at all.

you are welcome to fix all my stupid mistakes i make on a regular basis

Same for me ;-).

it would be nice to have an #irc room or something to learn a bit more about each other.

Yeah, we should grab a channel on freenode or something.