I have a low-level key logger that receives scan codes, without QKeyEvent's since the QApplication doesn't have focus. The scan codes can be converted into key syms using system specific library calls.
Scan codes correspond to Qt's QKeyEvent->nativeScanCode() and key syms correspond to QKeyEvent->nativeVirtualKey(), but Qt's Qt::Key values seems independently mapped. I would like to either take a given Qt::Key and convert to either sym key or scan code, or construct a Qt::Key out of a sym key or scan code, so that I can compare the captured keys with pre-determined Qt::Key's.
I've seen other projects that do this by implementing large, incomplete lookup table ref1 ref2. Surely if Qt is gathering scan codes and constructing QtKey's out of them it must have some internal mapping? I would like some way to avoid duplicating that. Is there any accessible Qt API to construct Qt::Keys from key syms or scan codes, or any non-public API Qt code that could be copied instead of relying on external projects?
Unfortunately, there doesn't seem to be easy way to translate between Qt keys and native key codes.
You can use the same mapping Qt uses for X11. I use this table for QxtGlobalShortcut library.
Original table is from qxcbkeyboard.cpp. The source file contains some functions for converting native key codes for use in Qt. The problem is that the QXcb* classes are not public, and from the looks of the headers, can break between minor Qt releases (so direct use is not advised).
Related
VkImageCreateInfo has the following member:
VkFormat format;
And VkImageViewCreateInfo has the same member.
What I don't understand why you would ever have a different format in the VkImageView from the VkImage needed to create it.
I understand some formats are compatible with one another, but I don't know why you would use one of the alternate formats
The canonical use case and primary original motivation (in D3D10, where this idea originated) is using a single image as either R8G8B8A8_UNORM or R8G8B8A8_SRGB -- either because it holds different content at different times, or because sometimes you want to operate in sRGB-space without linearization.
More generally, it's useful sometimes to have different "types" of content in an image object at different times -- this gives engines a limited form of memory aliasing, and was introduced to graphics APIs several years before full-featured memory aliasing was a thing.
Like a lot of Vulkan, the API is designed to expose what the hardware can do. Memory layout (image) and the interpretation of that memory as data (image view) are different concepts in the hardware, and so the API exposes that. The API exposes it simply because that's how the hardware works and Vulkan is designed to be a thin abstraction; just because the API can do it doesn't mean you need to use it ;)
As you say, in most cases it's not really that useful ...
I think there are some cases where it could be more efficient, for example getting a compute shader to generate integer data for some types of image processing can be more energy efficient than either float computation or manually normalizing integer data to create unorm data. Using aliasing you the compute shader can directly write e.g. uint8 integers and a fragment shader can read the same data as unorm8 data
I have a BLE device with multiple characteristics addressed by default addresses as defined here
Things like Manufacturer Name String, Hardware Revision String, Serial Number String etc.
Using the UUID class I've attempted several different ways to construct a UUID that RxAndroidBle would accept and read from these characteristics.
The one I though would work most was this:
UUID GATT_DSR1_MANUFACTURER_NAME = new UUID(0L, 0x2A29L);
but I just get back onError callbacks.
RxBleConnection.readCharacteristic only accepts UUID or a BluetoothGattCharacteristic which is created with a UUID...
Creating UUIDs
(copied from How to correctly use UUID.fromString method? )
In the BLE specification there are two kinds of UUIDs.
Fully qualified 128 bits long which are usually assigned for a specific vendor of the BLE device for non-standard functionality: UUID.fromString("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx");
Also fully qualified (but defined by standard) UUIDs which have the same prefix and postfix: UUID.fromString("F000xxxx-0451-4000-B000-000000000000"); UUID.fromString("0000xxxx-0000-1000-8000-00805f9b34fb") where xxxx is the place to fill the four characters you get from the SensorTag Bluetooth Core specification. For convenience the standard UUIDs are usually referenced with the four characters identifier.
Your 0x2A29L stands for "2A29" String as the xxxx.
Obtaining BluetoothGattCharacteristic
On Android there is no possibility to create a working BluetoothGattCharacteristic with a UUID. It is still possible to call RxBleConnection.discoverServices() and get it from the result though.
The Firebase Java API specifies that Long is a valid type to pass to setValue(). JavaScript only supports a single number type, the equivalent of Java's "double". So if I insert a number from JavaScript and retrieve it later from Java, am I going to get a Long or a Double? Is it a bad idea to use Longs in any cross-platform Firebase code, seeing as how a JavaScript client has no way of creating this type?
Numbers are slotted into either Longs or Doubles on the server. If the number maps exactly to a Long (i.e. is within the range of Longs, and does not have a decimal point), it will be stored as a Long. Otherwise, it will be stored as a Double.
Javascript does have less precision than Java when it comes to Longs, but if you remain within Javascript's limits, you shouldn't have a problem using Longs cross-platform.
I'm new on Java Card applications. At this moment I would like to store a hash table (dictionary) that contains the configuration of a terminal that reads this type of cards. If the hash table has values, those must be retrieved to the terminal (I think using APDU's right?) but also if there are no values, the terminal must create a "default" initial configuration.
Is it possible to do this? If it is, how? Maybe there is an applet ready for that (like Musclecard for key generation and signing) but I haven't found any.
Any advice? Thanks!
Java Card is pretty limited regarding support for data structures. It has a few basic types such as byte and short and optionally int, which is not used anywhere in the classic API. For those types you can generate two types of transient (RAM) arrays using JCSystem.makeTransientByteArray() and friends. Furthermore, the default byte[], short[] and Object[] created using new are stored in EEPROM.
The Object class in Java Card has been stripped down as well. This means that there is no such thing as hashCode(). If it was present then you would run into problems as the Java SE version of hashCode() returns an integer, which is probably not present. All defined data containers are either smart card or security related (e.g. the APDU and Key classes).
So basically, if you want to create a HashMap - the common type of dictionary on Java SE - then you will have to create it yourself. It is in that case a good idea to define a Hashable interface that classes can implement to act as a key. The structures should be generated in the right type of memory. For the kind of application you specify you probably need persistent memory, which is kind of the default for object instances created using the new key word.
Personally, I would make very sure you need a hashCode() method for your solution. It is probably easier to create an Object array and simply iterate over the elements.
Since there is no hash table in the smart card, you can store the terminal configurations in byte arrays. The smart card only stores the configuration (and optionally protect the data), and the instruction to get stored configuration or to update it shall be sent by terminal via APDU command.
Suggestion 1
Put your configuration in a Linear Fixed EF, if the card supports file system. No applet needs to be created/installed. It's the terminal job to read all records of the file to determine whether a configuration exist or not, and to write configuration into the file using standard APDU (UPDATE RECORD, READ RECORD).
NOTE:
set record length as number of terminal configuration bytes
number of records denotes the number of configurations that can be stored
you can put initial condition to indicate that the record is unused, e.g. 00...00
Suggestion 2
Create your own javacard applet. The applet must handle at least three proprietary APDUs:
Get list of terminal configurations
Update a record of terminal configuration
Delete a record of terminal configuration
NOTE:
You need to handle how to store and return the bytes between APDU format and your storage
I need to create small-mid sized static hash tables from it. Typically, those will have 5-100 entries. When the hash table is created, all keys hashes are known up-front (i.e. the keys are already hashes.) Currently, I create a HashMap, which is I sort the keys so I get O(log n) lookup which 3-5 lookups on average for the sizes I care. Wikipedia claims that a simple hash table with chaining will result in 3 lookups on average for a full table, so that's not yet worth the trouble for me (i.e. taking hash%n as the first entry and doing the chaining.) Given that I know all hashes up-front, it seems to be that there should be an easy way to get a fast, static perfect hash -- but I couldn't find a good pointer how. I.e. amortized O(1) access with no (little?) additional overhead. How should I implement such a static table?
Memory usage is important, so the less I need to store, the better.
Edit: Notice that it's fine if I have have to resolve one collision or so manually. I.e. if I could do some chaining which on average has direct access and worst-case 3 indirections for instance, that's fine. It's not that I need a perfect hash.
For c or c++ you can use gperf
GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.
GNU gperf is highly customizable. There are options for generating C or C++ code, for emitting switch statements or nested ifs instead of a hash table, and for tuning the algorithm employed by gperf.
Small hashes are also possible in C without an external lib using the pre-processor, for example:
swich (hash_string(*p))
{
case HASH_S16("test"):
...
break;
case HASH_S256("An example with a long text!!!!!!!!!!!!!!!!!"):
...
break;
}
Have a look for the code # http://www.heeden.nl/statichashc.htm
You can use Sux4j to generate a minimal perfect hash in Java or C++. (I'm not sure you are using Java, but you mentioned HashMap, so I'm assuming.) For C, you can use the cmph library.