Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 27 12:48
    MasterR8 closed #273
  • Sep 05 16:31
    MasterR8 commented #273
  • Sep 05 16:23
    Sharparam commented #273
  • Sep 05 16:07
    MasterR8 commented #273
  • Sep 03 09:46
    Sharparam commented #273
  • Sep 03 09:44
    Sharparam edited #273
  • Sep 03 09:44
    Sharparam edited #273
  • Sep 03 09:43
    Sharparam milestoned #274
  • Sep 03 09:43
    Sharparam commented #274
  • Sep 03 09:42
    Sharparam labeled #274
  • Sep 03 09:06
    poveden edited #274
  • Sep 03 09:06
    poveden opened #274
  • Aug 15 16:13
    MasterR8 opened #273
  • Aug 12 21:50

    Sharparam on 6.0.0

    Updating the Getting Started Gu… Assuming that v6.0 is not be a … Restore Front Matter and 9 more (compare)

  • Aug 12 21:50
    Sharparam closed #271
  • Aug 12 21:50
    Sharparam edited #271
  • Aug 12 21:46
    leonardoInf commented #271
  • Aug 12 21:46
    leonardoInf commented #271
  • Aug 12 21:46
    leonardoInf commented #271
  • Aug 12 19:13
    codecov-io commented #271
Adrian
@WolfspiritM
@PsychoTea I had no problem Compiling it. Did NuGet restore the colore package as you opened the project or did you compile it yourself? It looks like it's compiled for x64 while you're trying to compile SimonSays for Any CPU. The Colore nuget package should be any cpu not x64
PsychoTea
@PsychoTea
@WolfspiritM That was the problem. I reinstalled from NuGet and it worked, although the code doesn't :P
Nico
@njbmartin
what are you working on @PsychoTea ?
Adrian
@WolfspiritM
@Palid Just tried your SimonSays and it looks nice! However you better need to figure out a way to catch non english Keyboards until (if) Razer (I think it's not Colore's fault) changes the way how they are handled in the SDK. Sadly Colore's Key.Y lights up Z here in germany as Y and Z are switched on german keyboards.
Ryan Hill
@Aurous
So i was wandering if anyone has some example code on the deathadder?
Dariusz Niemczyk
@Palid
@WolfspiritM if I only knew how to verify what keyboard layout it is... IMHO it's about Colore and SDK
when you want to light Z you light Z and don't care about keyboard layout
Adam Hellberg
@Sharparam
@Palid @WolfspiritM the key layout issue will be there until Razer provides a way to detect layouts and even then it will be hundreds of special cases to consider unless they do like sensible developers and put it in the drivers. This issue is in the SDK itself and as such there is nothing we can do to detect it in Colore currently
Brandon Scott
@brandonscott
It's a shame
We are adding a SafeKey check in shortly
Dariusz Niemczyk
@Palid
@Sharparam I thought about the same thing (SDK), but I'm really wondering if it's going to be added any time soon.
Brandon Scott
@brandonscott
@Palid unlikely
Adrian
@WolfspiritM
A workaround for now to find out which layout it is: The System Windows Forms Namespace does have a "InputLanguage.CurrentInputLanguage" which could be used I assume. I've not used it yet for anything, but InputLanguage.CurrentInputLanguage.LayoutName for me returns "German". It's not using the actual Keyboard Layout but the Keyboard Layout definied in Windows.
Adam Hellberg
@Sharparam
@WolfspiritM The current system language doesn't necessarily correspond to the actual physical layout of the keyboard, which is where the problem surfaces
Adrian
@WolfspiritM
@Sharparam It's not the system language it returns. My system is set to english. It's returning the input device configuration and I'd say mostly this is set correctly as Z wouldn't be Z for example. But I agree that the layout you define in windows doesn't mean the hardware does really have that layout. That's why it's a workaround...it'd be better then nothing.
Adam Hellberg
@Sharparam
s/system language/input language/. I know a couple people who remap their caps lock to escape for example.
Adrian
@WolfspiritM
I agree...handling remapped keys would be a way harder problem
Adam Hellberg
@Sharparam
Razer needs to provide a definite (this is important) list of ALL available physical layouts of the keyboard as well as provide a function that accurately returns the physical layout of the keyboard. Otherwise there is no reliable way to even try to handle it.
problem is that since they seem hellbent on putting this workload on the developers, every developer needs to implement their own solution to this since they won't add it natively in the SDK.
Adrian
@WolfspiritM
Or make their SDK light up the correct key no matter what Keyboard Layout...
Adam Hellberg
@Sharparam
people using Colore can use the methods in there of course, but those not using C# and working with the SDK directly will produce hundreds of duplicate methods to do this
Adrian
@WolfspiritM
It's one big flaw I saw in their SDK as I was playing around, that they didn't think of other keyboard layouts. Let's just hope they'll work on it.
Adam Hellberg
@Sharparam
Then you also have to consider that some people may have multiple keyboards plugged in with differing layouts
it's likely a small enough amount to be irrelevant, but still an interesting thought
Adrian
@WolfspiritM
not sure if that'd be so hard for their SDK that is doing the USB part to switch out keys (Y and Z for example) depending on the layout of the device it's sending to. Then it doesn't matter how many keyboards are plugged in
Adam Hellberg
@Sharparam
it's the reason this should be put in the driver so it's as close to the hardware as possible, or firmware even. but they've already released the keyboards so it's a bit late for that
the SDK doesn't (and probably won't for the foreseeable future) provide granular access to specific devices, only to "all <device type here>" so the SDK can't be used to filter devices out
Dariusz Niemczyk
@Palid
@Sharparam tbh from what I'm reading the SDK is a piece of crap.
Adrian
@WolfspiritM
Not really talking about the API part of the SDK...more the backend (driver) part that does the work. The driver knows what layout it is and it could fix this. However...it's totally Razers part to do that
Dariusz Niemczyk
@Palid
Wait. We should have access to the keyboard's product number, or sth.
this way we can at least try doing an ugly fix.
Model number*
Adam Hellberg
@Sharparam
you can query a GUID and get the device type and whether it's connected, not any details about its layout
see: DeviceType struct and Query method on Chroma class
DeviceInfo*
Dariusz Niemczyk
@Palid
Well, we can try with the Model Number then.
Adam Hellberg
@Sharparam
it cannot be queried
we can only get type of device (keyboard, mouse et.c) and whether it's connected
Dariusz Niemczyk
@Palid
@Sharparam you sure that it can't be queried? I'm not talking about SDK now.
Let's just agree that SDK sucks and try different methods. :P
Adam Hellberg
@Sharparam
you could probably start making your own stuff to read USB data, but then you're reverse engineering and breaking rules and shit
Adrian
@WolfspiritM
You could query the USB somehow
Dariusz Niemczyk
@Palid
tbh if Razer would start doing something against 'illegal rev-eng' in this case they would lose a lot of fanbase.
Adrian
@WolfspiritM
Even having the model...I think using InputLanguage.CurrentInputLanguage as an ugly workaround would be easier instead somehow mapping model/guid to region to key
Dariusz Niemczyk
@Palid
but yeah, let's not go into this discussion. :D
@WolfspiritM There's a problem with ugly workarounds: they are ugly and always do a problem in edge cases.
and here the edge case isn't even so edge-like.
Adrian
@WolfspiritM
Querying the USB for a model number is nothing more then a ugly workaround, too...
Dariusz Niemczyk
@Palid
True, but a bit more bulletproof.
Adam Hellberg
@Sharparam
@/all Whoever had issues with exceptions from UnInit can you try using feature/uninit-improvement and see if that fixes the issue?